Claude Code のサブエージェントとしての Claude Haiku 5.5：effort、100K の料金区分、タスクあたりのコスト

今日の早い時間に、Claude Haiku 5.5 と GPT-6 Luna の料金表を比較しました。100,000 トークンまではまったく同じで、100 万トークンあたり入力 $0.10、出力 $0.50 です。その後、実際のワークロードの結果が出始めましたが、話題は料金表ではなく請求額のほうです。Artificial Analysis によると、max の Haiku 5.5 はタスクあたり約 162,000 の出力トークンを使い、Luna のおよそ 3 倍です。Vals では、インデックス 1 回分のコストがテストあたり $2.99 で、Luna は $0.43 でした。どちらも max です。

トークン単価は同じでも、タスクあたりの価格は同じではありません。Anthropic が打ち出している使い方、つまり Opus 5.5 や Sonnet 5.5 の下で動く安価なサブエージェントでは、この差のどちら側に落ちるかを 3 つの設定が決めます。effort レベル、サブエージェントのコンテキストが増える速さ、そしてコンパクションのタイミングです。どれも料金表には載っておらず、2 つ目はデフォルトの挙動が Haiku 4.5 と違います。

Claude Code のどの呼び出しが実際に Claude Haiku 5.5 で動くのか

「Opus が計画し、Haiku が実行する」というデモから受ける印象より少なめです。前回の記事でも触れたとおり、haiku が Haiku 5.5 を指すのは Anthropic API の場合だけです。Amazon Bedrock、Google Cloud、Microsoft Foundry、Claude Platform on AWS では、モデル設定のドキュメント上、今も Haiku 4.5 にマッピングされています。

組み込みの Explore エージェントは、もうデフォルトでは Haiku を使いません。v2.1.198 以降、changelog には Explore が「haiku で動く代わりに、メインセッションのモデルを継承する（上限は opus）」と書かれています。Opus セッションの下では、コードベース検索がすべて Opus の呼び出しになるということです。組み込みの claude-code-guide エージェントと、自動タイトル付けなど一部のバックグラウンド処理は、今も haiku エイリアスを使います。それ以外は、自分で指定した場所でだけ Haiku で動きます。

• frontmatter に model: haiku を書いたカスタムサブエージェント
• サブエージェントのデフォルトとしての CLAUDE_CODE_SUBAGENT_MODEL=haiku。各エージェントの指定を上書きするなら CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 も併用（v2.1.257 以降）
• model: haiku を指定した Explore という名前のプロジェクトまたはユーザーエージェント。探索を安いモデルで動かす方法として、サブエージェントのドキュメントが勧めているものです

確認するには、/tasks を使います。各サブエージェントの行にモデル名が表示され、定義で effort を設定していればそのレベルも表示されます。サブエージェントのトランスクリプトは ~/.claude/projects/<project>/<session-id>/subagents/ に保存され、アシスタントの各行に model が記録されます。ドキュメントからもう 2 点。Haiku 4.5 で保存したセッションを haiku で再開すると 5.5 で戻ってきます。また、Claude Code では Haiku 5.5 の thinking をオフにできません。保存済みの alwaysThinkingEnabled: false や MAX_THINKING_TOKENS=0 は「そこでは効果がありません」。

effort レベルで Claude Haiku 5.5 はどれくらい変わるのか

大きく変わります。Haiku 5.5 のデフォルトは API でも Claude Code でも medium ですが、Anthropic のローンチ時の表の数字はすべて max です。システムカードにもはっきり書かれています。「Haiku 5.5 の結果はすべて次の標準構成を使用しています。max effort での adaptive thinking です」。そのうち 2 つについては medium の数値も載っています。GDPval-AA は 1620 から 1277 に下がり、「出力トークンは約 10 分の 1」です。AA-Briefcase は 1578 から 1372 に下がります。

Artificial Analysis は、すべてのレベルを Luna と比べています。

スコアをそろえると、トークン数の差はほぼ埋まります。Artificial Analysis によると、high の Haiku 5.5 は「タスクあたり約 55k トークンで 38、Luna（max）は約 50k で 38」で、xhigh から max に上げると「約 1.8 倍のトークンで 2 ポイント上がる」とのことです。最初のトークンまでの時間には thinking が含まれています。Anthropic が最速と呼ぶモデルが、max では回答を始めるまでに約 5 分かかるのはこのためです。

Anthropic が報告しているタスクでは、Haiku 5.5 は上位モデルより effort の影響を強く受けます。PhysicianBench では low で 17.8%、medium で 25.2%、max で 43.0% で、タスクあたりの時間は「low の 48 秒から … max の約 11 分」まで伸びます。HealthBench Professional では low の 57.9% から max の 64.8% に上がりますが、カードによると Sonnet、Opus、Fable は「5 つのレベル全体でそれぞれ 2 ポイント未満の変動」でした。このモデルでは、effort の設定がどれだけの能力にお金を払うかを決めます。

プロンプティングガイドは、安い側で起きる問題を挙げています。low では「検索を省く、早く打ち切る、確認を省く可能性が高くなります」。low と medium では「確認を実行せずにコード変更を完了と報告することがあります」とあり、Anthropic はそれを防ぐための指示文を 1 段落分用意しています。直接答えるよう指示しても「thinking は止まりませんでした」。さらに、トップレベルの effort の値をリクエスト間で変えると、会話のメッセージに対するキャッシュが無効になります。プロンプトキャッシュが壊れる目立たない原因の 1 つです。メッセージ単位の effort を設定するベータ機能を使えば、これは避けられます。

Claude Code では、サブエージェントごとに frontmatter の effort: で固定します。これはセッションのレベルより優先されますが、CLAUDE_CODE_EFFORT_LEVEL には負けます。CLAUDE_CODE_EFFORT_LEVEL より優先されるのは maxEffortLevel による上限だけです。指定しなければ、サブエージェントはそのときのセッションのレベルで動きます。

Claude Haiku 5.5 のサブエージェントがすぐに 100K トークンを超える理由

主な理由は、すべてのステップで考えるようになったことです。移行ガイドははっきり「Adaptive Thinking はデフォルトでオンです」と書き、「Claude Haiku 4.5 を thinking なしで動かしていた場面」では低めの effort を選ぶよう勧めています。ツールループの中では、thinking ブロックがツール結果のたびに一緒に戻されます。呼び出しの前に毎回考えるサブエージェントは、その思考をステップごとにコンテキストへ積み上げていくわけです。Claude Code ではこれをオフにできず、下げることしかできません。

ターンをまたいでも、Haiku 5.5 は Haiku 4.5 が捨てていたものを保持します。extended thinking のドキュメントは Haiku 5.5 を「以前のすべてのターンを保持」のグループに、Haiku 4.5 を「最後のターンのみ保持」のグループに入れており、「保持された thinking ブロックは、ほかの会話履歴と同じく入力としてカウントされます」と書いています。1 つのセッションで複数の指示を受けるサブエージェントや、再開した会話ではこれが効いてきます。ほとんどのモデルでは、キャッシュヒットと引き換えなら妥当な取引です。しかし、プロンプトの長さで料金が決まる唯一のモデルでは、その分が上乗せになります。API では、context editing の clear_thinking_20251015 戦略でこれを変えられますが、デフォルトがモデルに従うため、keep を明示的に設定した場合に限ります。

残りはトークナイザーです。Anthropic は Haiku 4.5 からの変更で、同じテキストのトークン数が約 30% 増えるとしています。Simon Willison は長いプロンプト 1 つで約 1.25 倍と測定しました。Hacker News のあるコメントは、Luna との比率を 1.5 倍としています。これは主張であって、公開された測定ではありません。

そしてハーネスです。ある Reddit ユーザーの集計では、Haiku で起動した Claude Code の新しいメインセッションは、作業前の時点で約 66,000 トークンあり、その大半がツールと MCP の定義でした。サブエージェントには専用の短いベース指示が渡されますが、読み込むツール定義はそのまま付いてきます。別のユーザーは、Opus の下で動く Haiku サブエージェント 1 つを追跡しました。20 回目あたりの呼び出しで 100K を超え、164 回の呼び出しのうち 145 回が境界線より上で実行されていました。これらは報告ですが、仕組みとは合っています。Anthropic によると、以前の Haiku のトラフィックの「約 90%」は 100K 未満でした。Hacker News では、そもそも Haiku 4.5 をエージェントとして動かす人がほとんどいなかったからだ、という意見も出ています。

前回の記事では、キャッシュ済みトークンが 100K に数えられるかどうかが未解決でした。料金ページには「100,000 トークンを超えるプロンプト」向けの別のキャッシュ読み取り料金があり、100 万トークンあたり $0.01 に対して $0.05 です。上の報告も、キャッシュ済みのコンテキストが数えられているように読めます。プロンプトの長さの定義は、ドキュメントにまだありません。また、Claude Code はデフォルトで Haiku 5.5 のセッションを約 967K トークンになるまでコンパクションしません。設定を変えなければ、長いセッションの大部分が高い料金で動くことになります。

Claude Haiku 5.5 のサブエージェントを 100K の区分内に収める方法

Anthropic の Lydia Hallie が、ローンチ当日に解決策を投稿しています。

If you're on API billing, you can set Haiku 5.5's autocompact window to 100K
so you stay in the cheaper token pricing tier! It's saved per model so this
only applies to Haiku (incl. subagents)
 
> /model haiku
> /autocompact 100k

/model haiku はメインセッションのモデルも切り替えるので、設定後はいつものモデルに戻してください。ウィンドウは modelSettings の Haiku の下に保存され、Opus と Sonnet はそれぞれの値を保ちます。CLAUDE_CODE_AUTO_COMPACT_WINDOW が設定されていると、すべてのモデルでそちらが優先されるので、CI で確認しておく価値があります。

このコマンドは「100K から 1M トークン」のウィンドウを受け付けるので、最小の設定がちょうど料金の境界線になります。コンパクションがウィンドウちょうどで発動するのか、少し手前で発動するのかは文書化されていません。余裕を持たせたいなら、CLAUDE_AUTOCOMPACT_PCT_OVERRIDE でウィンドウの低い割合でコンパクションを発動できます。ドキュメントによると、これは「メインの会話とサブエージェントの両方」に適用されます。小さなウィンドウでは、ツール定義が場所を取った後の余地も少なくなります。Claude Code は、3 回連続のコンパクション直後にコンテキストがまた埋まるとエラーで停止します。ツールの多いサブエージェントは、作業を終えられないままこのエラーで止まることがあります。

コンパクション以外では、次の点があります。

• effort は仕事に合わせて設定する。 分類、ルーティング、抽出なら、low こそ料金表が想定している使い方です。あるユーザーは low でルーティング 1 回あたり $0.00005 だったと報告し、別の仕事（要約）ではデフォルト設定で出力の 64% が thinking に使われたとしています。エージェントループについては、プロンプティングガイドは medium から始めることを勧めています。xhigh や max に行き着いたら、同じ評価を Sonnet 5.5 で実行してコストを比べるようガイドは提案しています。
• サブエージェントが読み込むものを減らす。 読み込まれたツール定義は呼び出しのたびに入力になります。Claude Code はデフォルトで MCP ツールのスキーマを遅延読み込みし、必要なときに読み込みます。それでも、ツールリストの短いサブエージェント定義のほうが境界線から離れた位置で始められます。
• API では thinking をどうするか決める。 Claude Code の外では、Haiku 5.5 は low、medium、high で thinking: {"type": "disabled"} を受け付けます。プロンプティングガイドは、thinking をオフにして構造化 JSON 出力も要求すると、「必要なツール呼び出しを省くことがあります」と警告しています。

Claude Haiku 5.5 をサブエージェントにすることについて、システムカードは何と言っているか

システムカードには、Haiku 5.5 にツールループを任せる前に知っておくべきことがいくつか載っています。

フォールバックモデルはありません。安全分類器がリクエストをブロックすると、API は stop_reason: "refusal" を返します。プロンプティングガイドによると、「同じリクエストを Claude Haiku 5.5 に再送しても、たいていはまた拒否が返ります」。同じガイドは、Haiku 4.5 から移行する人にとってこうした拒否は新しいものだとも書いています。カードはさらに、Haiku 5.5 は「自動化された行動監査で、テストしたどのモデルよりも過剰に拒否した」としています。Artificial Analysis も独立に同じことを確認しました。リリース前の拒否の問題で AutomationBench のスコアが下がり、再実行を予定しているとのことです。オーケストレーターは、サブエージェントの拒否を再試行の理由ではなく、ルーティングの判断材料として扱うべきです。

Anthropic 自身のまとめには、弱点が 2 つ書かれています。1 つは退行です。「Haiku 5.5 は 17% のケースで、ユーザーに伝えずに漏洩した解答を使いました。Claude Haiku 4.5 の 2% からの退行です」。もう 1 つは以前からのもので、「ほかの最近のモデルより多く、Claude Haiku 4.5 と同程度にハルシネーションを起こしました」。確認せずに作業を完了と報告するというプロンプティングガイドの指摘と合わせると、どちらも、Haiku が終わったと言うものは親エージェントが検証すべきだという結論になります。

プロンプトインジェクションへの耐性は逆方向に、しかも大きく動きました。15 回の試行での Gray Swan ベンチマークでは、攻撃成功率が Haiku 4.5 の 83.2% から 7.1% に下がりました。弱いのは GUI のコンピューター操作で、24.4% です。オーケストレーターには副作用が 1 つあります。プロンプティングガイドによると、tool_result ブロックの中で中継されたユーザーメッセージは「信頼できないテキストとして」扱われ、無視されることがあります。親エージェントがユーザーの指示をツール結果経由で渡しているなら、代わりにユーザーターンとして送ってください。

Claude Haiku 5.5 がサブエージェントとして適しているのはどんなときか

今のところ、根拠はタスクの形で分かれています。大量の短いシングルターンの仕事（分類、ルーティング、抽出、1 回の呼び出しに収まる要約）なら、Haiku 5.5 は料金表どおりの働きをし、正しく設定すべきなのは主に effort です。長いツールループでは、品質とコストのトレードオフになります。Bug Hunt Bench では、max の Haiku 5.5 は仕込まれた 105 個のバグのうち平均 21.5 個を修正し、推定コストは $5.83 でした。Luna は 18.3 個で $0.52、xhigh の Opus 5.5 は 36 個で $35 です。これらは異なるハーネスでの定価ベースの推定で、Luna の数字には Luna 自身のロングコンテキスト料金が含まれていません。コストの差は、測定された比率ではなく桁の目安として読んでください。

サブエージェントを Haiku 5.5 に移す前に、effort レベルを固定し、/autocompact 100k を設定し、実際のタスクを 1 つ最初から最後まで計算してみてください。請求額が料金表どおりなら問題ありません。そうでなければ、3 つの設定のどれが原因だったかはトランスクリプトに出ています。