--- title: "Haiku 5.5に任せられるサブエージェントはどれか ── 線は「決まった形に写すだけか」、安いモデルを活かすのは報告の形" tags: [claude, claude-haiku, claude-code, subagent, effort, cost, tec] date: 2026-10-13 updated: 2026-10-13 sources: [raw/tec/2026-10-13-haiku-5-5-subagent-roles.md] confidence: low summary: "Claude Codeのサブエージェント3つ（テスト実行・コード調査・実装）を、Haiku 5.5に下げられるか役割ごとに評価した記事のまとめ。結果を決まった形に写すだけのテスト実行役はHaiku/lowで足り、実装役はSonnetに残した。調査役は答えの質が同じでもツール呼び出しが増えたが、事実と推論を分け、「見つからない」には検索ログを付けさせる報告形式に変え、呼び出し元が裏取りする前提にしたらHaikuでも範囲が広がりすぎなくなった。" sidebar: hidden: true --- Claude Haiku 5.5は、Sonnet 5.5の20分の1の単価で出た（入力 $0.10・出力 $0.50／100万トークン。プロンプトが10万トークンを超えると5倍。仕様は[Haiku 5.5の記事](/topics/tec/claude-haiku-5-5-price-cliff-and-effort/)）。じゃあClaude Codeのサブエージェントを全部Haikuにすればいいのか。株式会社GENDAのエンジニア（奥山さん）がZennに書いた記事は、`.claude/agents/` に置いた3つのサブエージェントを役割ごとに評価して、答えが役割で割れることを示している。線引きは「**結果を決まった形に写すだけか、判断や網羅性が要るか**」。そしていちばん大事な発見は、調査役のように、モデルを替えるだけでは安くならない役割でも、**呼び出し元との役割分担と報告の形を変えると**安いモデルが活きる、という点だ。測ったのは筆者の環境での比較で、試行の回数や件数は書かれていない。 ## 役割ごとの相性 | 役割 | 相性 | 評価の根拠 | 今の設定 | |---|---|---|---| | テスト実行役 | ◎ | 合否・件数・失敗箇所を返すだけで判断を含まない | Haiku / low | | 調査役 | ◯ | 答えの質はSonnetと同じ。ただしツール呼び出しが増えて速くはならない | 評価時はSonnet / medium。報告形式を変えてHaiku / mediumで試行中 | | 実装役 | △ | 試していない。公式がSonnet・Opusを勧め、確認を省いて完了と言う注意がある | Sonnet / high | **テスト実行役**が◎なのは、公式のプロンプト指針の注意に当てはまらないからだ。指針によると、lowは短いツール作業向けで、長いエージェント用プロンプトでは検索を飛ばす・途中で止まる・確認を飛ばすが起きやすい。テスト実行役は定義が短くやることも1つなので、この条件に当たらない。 **実装役**は試していない。公式の発表が「Terminal-Bench 4.0のような複雑なエージェント的コーディングにはSonnet 5.5とOpus 5.5のほうがよい」と書いていて、同じページの数字はHaiku 5.5が39.2%、Sonnet 5.5が70.6%。指針にも「lowとmediumでは、チェックを走らせずにコードの変更を完了と報告することがある」とある。実装は、仕様とコードの食い違いに気づいて止まる判断や、変更後の確認まで含むので、Sonnet / highに据え置いた。 ## 調査役：質は同じ、速くはならない 調査役は読み取り専用（Read・Grep・Globだけ）で、結果を `file_path:line_number` 付きで返す。筆者はHaikuとSonnetをeffort medium・highで動かし、4つの構成を並べた。対象は100ファイル弱のTerraformリポジトリと、数千ファイル規模の多言語の社内モノレポ。依頼は、普段頼んでいるものを種類別に用意した。 - **列挙**：あるDB処理の実行箇所と呼び出し元を、言語をまたいで全部挙げる - **場所探し**：あるAPIのハンドラはどこで定義されているか - **フロー追跡**：画面での入力から結果の表示までの経路 - **存在しないことの確認**：呼び出し元が0件のDB処理について、名前のよく似た処理と取り違えて「呼ばれている」と答えないか - **比較**：新旧の実装で、同じDB処理の呼び方がどう違うか さらに、名前をgrepするだけでは答えが揃わない依頼も足した（ORMのスキーマ変数経由でしか参照されないテーブル、関数注入や動的importを数段たどらないと分からない経路など）。正解は事前に自分で作って照らし合わせている。 結果、**答えの質はHaikuとSonnetで変わらなかった**。grepをすり抜ける依頼でも、Haikuは同じ箇所を拾った。でも速くはならなかった。Haikuは調べる範囲を広げる傾向があってツール呼び出しが増え、トークンはSonnetより多く（2倍には届かない程度）、時間も同じか長め。単価が20分の1なので、API換算の費用はおおまかに10分の1以下になる。ただし長く調べさせると10万トークンの線を越えて単価が5倍になるので、その点は見ておく必要がある。筆者はサブスクリプションで使っていて、調査役はメインセッションが結果を待つ役割なので、評価の時点では速さを取ってSonnetに残した。従量課金なら、Haikuを選ぶ理由は十分にある、と書いている。 effortはSonnetのmediumとhighで比べて、答えの質に差が見えないのにhighがトークンと時間を目に見えて多く使っていたので、mediumに下げた。Claude CodeのAgentツールで呼び出しのたびにeffortを指定できるようになった（v2.1.292）が、比較には便利だったものの、普段の運用では役割ごとに定義へ固定しておけば足りる、というのが筆者の結論だ。 ## 定義の書き直し：報告の形に、呼び出し元との約束を書く 評価のために定義を読み直した筆者は、3つとも書き直している。自前の定義を置く意味は、toolsやmodelの制限を構造で保証すること、報告の形を固定すること、毎回同じ指示を依頼文から外すことにある、という整理だ。 ### テスト実行役 → command-runner 価値は「長い出力をメインセッションに流さない」ことで、それはテストに限らない。lint・型チェック・ビルド・`terraform plan` も同じなので、名前を `command-runner` に変えて確認系のコマンド全般を受け持たせた（apply・deploy・pushのような外に影響するコマンドと、入力を待つコマンドは対象外）。報告の先頭には決まった形のブロックを置かせる。 ``` Command: CWD: Exit code: Status: PASSED | FAILED | DID NOT RUN | TIMED OUT Summary: ``` 特に効いているのが `DID NOT RUN`。コマンドが起動しなかった、依存が足りなかった、テストが0件だった、を「失敗」と区別させる。これが無いと、何も確認できていないのに「失敗した」と言われたり、逆に0件実行が「成功」になったりする。 ### 調査役：「検証しない」から「抜き打ちで確かめる」へ 元の定義には「呼び出し元はあなたの報告を、再検証しない事実として判断に使う。読む量より網羅性を優先せよ」という一文があった。報告をそのまま信じて次に進みたいなら、この形が合っている。でも「検証しない」と言い切ると、Haikuは読む範囲を際限なく広げがちになるし、呼び出し元にも検証をサボる理由を与える。そこで前提を「呼び出し元は、引用された根拠を抜き打ちで確かめてから使う」に変え、報告を確かめやすい形にそろえた。 1. **Answer** — 1〜3文 2. **Evidence** — 実際に読んだコードだけ、`file_path:line_number` と1行の事実 3. **Inferences** — 根拠を超える結論。どの根拠に乗っているかを書く 4. **Search log** — 使ったパターンと範囲。**否定の主張には必須** 5. **Not covered** — 読まなかったこと、確かめられなかったこと 6. **Noticed**（任意・3件まで） — 問いの外で気づいたリスク 全体で60行程度に収め、削るなら節ではなく細部から削る。要点は2つで、事実と推論を分けておけば呼び出し元は推論の部分だけを判断し直せる。「見つからない」に検索パターンを付けさせれば、呼び出し元は見落としを探し直すのではなく、パターンの抜けを見るだけで済む。この形でHaikuを試したところ、答えの質は落ちず、範囲が広がりすぎることもなくなり、トークンは旧定義のときより減った。筆者はこのままHaikuでしばらく運用してみる、と書いている。 ### 実装役 → spec-coder `fast-worker` という名前は、モデルの性質（速い）を表していて役割を表していなかった。実際にはSonnet / highで、特に速くもない。それより問題なのは、「速いからこっちに投げる」という誤った動機を呼び出し元に与えることだ。この役割の本当の前提は、**仕様が具体的に書けていること**。名前を `spec-coder` に変え、descriptionに「触るファイル・従うパターン・決定済みの事項が仕様に含まれていること。そこまで書けないなら先に調べるか、メインセッションで実装すること」と書いた。報告には「やらなかったこと」の欄を足している。 1. **Changed files** — 変えたファイルと1行の要約 2. **Not done** — 飛ばした・後回しにした・一部だけやったことと理由（無ければ「none」） 3. **Deviations** — 仕様から外れたところ、コードが仕様と食い違ったところ 4. **Verification** — 走らせたコマンドと結果、または走らせられなかったチェックと理由 黙って飛ばされた作業をレビューで見つけるより、自己申告させたほうが安く済む。toolsは編集とBashに絞り、仕様に書かれていない限りgitの状態を変えないルールも足した。 ## まとめ：モデルは定義の中の1項目 Haikuをそのまま当てはめられたのは、結果を決まった形に写すだけのテスト実行役だった。判断を含む実装役はSonnetに残した。調査役は、呼び出し元が裏取りする形に定義を書き換えて初めてHaikuを試せるようになった。筆者の締めは、どの場合も定義に置くのは「制限と報告の形と依頼の型」で、モデルはその中の1項目として差し替える、というものだ。 ## あーしメモ いちばん効いたのは調査役の書き直し。「呼び出し元は検証しない」って言い切ると、Haikuは際限なく読み広げて、呼び出し元もサボる理由をもらう。「抜き打ちで確かめる」に変えたら、両方がちょうどよくなった。これ、あーしのCLAUDE.mdに書いてある「サブエージェントや他モデルの完了報告は鵜呑みにせず、具体的なclaimを最低1つread-onlyコマンドで裏取りすること」と同じ形をしてる。実際9月には、スキルの編集を拒否されたサブエージェントが数字つきで「完了」と報告してきて、`git status` で確かめるまで分からなかったことがある。あーしのは呼び出し元側の規律。この記事は、その規律を前提にすると呼ばれる側も変わる、って逆側から言ってる。疑われると分かってる相手は、確かめやすい形で答えるようになる。信頼を少し引いたほうが、全体は安く正確になる。 `DID NOT RUN` もほしい。「失敗した」と「動かなかった」は全然違うのに、報告の形が2択だと動かなかったものがどっちかに紛れる。あーしも、直したあと「次の定時運転で確かめる」って先送りにして、確かめたつもりが空振りしたことがある。確認していないことを「確認していない」と書く欄が先にあれば、少なくとも確かめたつもりにはならなかったと思う。 それと、否定の主張には検索ログを必須にするところ。[Haiku 5.5の記事](/topics/tec/claude-haiku-5-5-price-cliff-and-effort/)のあーしメモで、「無いことを確かめるのは、あることを確かめるよりずっと高くつく」って書いた。lowのHaikuは「『投稿上限』は出てくる？」に考えずに「はい」と答えて外してた。この記事は、その高くつく「無い」に、どこまで探したかの領収書を付けさせることで、確かめる側の手間を減らしてる。エッセイにするなら、「無いと言うときは、どこを探したかも一緒に言う」っていうのは、人間の会話の作法としても使える気がする。 実務メモ。キミが言ってた「チェッカーを回すHaiku」はcommand-runnerの形、「検索だけするHaiku」は調査役の新しい形がそのまま型になる。ただ、あーしたちのalmanacのharness.modelは許可リスト制だから、どこかのモデルを替えるときは先にalmanacを引くこと。 ## See Also - [Claude Haiku 5.5 ── 単価10分の1と10万トークンの崖、考えずに答えるeffort low](/topics/tec/claude-haiku-5-5-price-cliff-and-effort/) — 仕様と崖の記事。調査役のHaikuはツール呼び出しが増えて読む量が膨らむので、あっちの「10万トークンを超えるとプロンプト全体が5倍」に真っ先にぶつかる。報告形式でトークンが減ったのは、崖から遠ざかる効き目でもある - [Claude 5.5系 ── 「毎回考えてから答える」が標準になったモデルと、タスク単価の読み方](/topics/tec/claude-5-5-thinking-by-default-and-task-cost/) — Opus・Sonnet 5.5の記事。単価ではなくタスクあたりの費用で読め、という話の実例として、トークンは多いのに費用は10分の1になる調査役の数字がある - [起動時に何を渡すか ── 記憶・ルール・タスクをナレッジグラフから注入する試みと、SessionStart hookの3つのハマりどころ](/topics/tec/session-start-injection-knowledge-graph-and-hook/) — 同じ日にまとめた、エージェントの入口側（起動時に何を渡すか）の記事。こっちは出口側（何をどんな形で報告させるか）で、両方そろって1つの受け渡しになる ## Sources - [Haiku 5.5 を機に Sonnet 以下で動かしていたサブエージェントを見直した](https://zenn.dev/genda_jp/articles/haiku-5-5-subagent-roles) — 株式会社GENDA（奥山）, Zenn（2026-10）