AIエージェントのコスト計算：Haiku が Sonnet に勝つとき（勝たないとき）

目次

2026年6月更新。

要点： Sonnet ではなく Claude Haiku を選べば呼び出しあたりのコストを一桁下げられますが、それはタスクが Haiku の低い成功率を許容できる場合に限ります。重要な指標は成功した結果あたりのコスト — 呼び出しコストにリトライと人手による後始末を加えたもの — であって、トークンあたりの表示価格ではありません。私はタスクごとにルーティングしており、判断を要する処理は Sonnet に残しつつ、高ボリュームのステップの相当な割合を Haiku で動かしています。

運用者の視点： 私は100以上のエージェントを運用しており、推論は実際の費目です。しかし、すべてを最安のモデルに押し込んで「節約した」つもりが、リトライ・エスカレーション・怒った顧客という形でコストを払うチームを何度も見てきました。コスト計算はファネル全体を測ってはじめて成立します。

最も安いモデルとは、トークンあたりの単価が最も低いモデルではありません。仕事を正しく終わらせるための総コストが最も低いモデルです。これらは別々の数字であり、その差こそが、エージェントのコスト判断の多くが誤る場所です。

トークンの経済性を、率直に言うと

Anthropic は Claude を100万トークン単位で課金し、入力と出力は別々に請求され、出力は入力の数倍のコストがかかります。正確な数字は時とともに変わるので、Anthropic の最新価格を確認してください — ただし判断を動かすのは構造です：

• Haiku は安価で高速な階層 — ファミリー内で群を抜いてトークンあたりのコストが低い。
• Sonnet は中間 — Haiku よりは明らかに高く、Opus よりは明らかに安い。
• Opus は最も難しい推論のためのプレミアム階層。

ここから二つのことが導かれます。第一に、生成タスクでは出力トークンがコストを支配するため、冗長なモデルは同じトークン単価でもより高くつきます。第二に、Haiku と Sonnet のトークン単価の差は、高ボリュームのステップでは間違いなく請求額に表れるほど大きいということです。これが Haiku を選ぶ根拠です。次に、選ばない根拠を。

本当に重要な指標：成功した結果あたりのコスト

呼び出しあたりのコストは見栄えだけの数字です。私が実際に使っている式はこちらです：

成功あたりのコスト = (呼び出しコスト × 試行回数) + 後始末コスト
                     ÷ 成功率

ここで 試行回数 はリトライを織り込み、後始末コスト はすり抜けた失敗を人間が修正する期待コストです。これが比較に何をもたらすか見てください。

Haiku が呼び出しあたり Sonnet の約10分の1のコストだとします。あるタスクで Haiku が80%、Sonnet が98%成功するなら、呼び出しあたりの節約は莫大に見えます。しかし、Haiku の失敗ごとにリトライが1回発生し、10回に1回は実費のかかる人間がなお必要なら、後始末の項がトークンの節約を飲み込みかねません。リスクが低く高ボリュームのタスクでは、計算は圧倒的に Haiku に有利です。失敗すれば誤った顧客にメールが飛ぶようなタスクでは、完全に逆転しうるのです。

この判断は、モデルごとの成功率を測らずには下せません — それこそ評価ハーネスが与えてくれるものです。同じ評価セットを両モデルに対して走らせ、同じ物差しで成功率を読み取ってください。

Haiku が決定的に勝つ場面

タスクが狭く、構造化され、検証可能なとき、Haiku が正解です：

• 分類とルーティング — 「この受信メッセージは予約か、苦情か、スパムか？」三つのバケツ、検証が容易、絶えず動く。一日中 Haiku で。
• スキーマに基づく抽出 — テキストから日付・名前・金額を取り出し、Zod で検証する。出力がパースできれば、ほぼ確実に正しい。
• 短いリライトと整形 — トーンの調整、良いと分かっている入力の要約、データの正規化。
• 一次フィルタリング — Haiku がトリアージし、曖昧なケースだけが Sonnet にエスカレートされる。これが最もレバレッジの高いパターンです。

共通する筋：Haiku のミスのコストは低く、ミスは安く検出できる。検証が安く、リスクが低いとき、安いモデルが勝ちます。

Sonnet がその価格に見合う場面

タスクがオープンエンド、多段階、または間違えると高くつくとき、Sonnet（時には Opus）は価値があります：

• マルチツールのエージェントループで、一つの誤ったツール呼び出しが連鎖する場合。高い推論の信頼性はステップを通じて積み上がります — マルチエージェント・オーケストレーションで扱うオーケストレーションのパターンは、モデルが筋を見失わないことに依存しています。
• 顧客向けの生成で、悪い出力がリトライだけでなく信頼を損なう場合。
• 検証そのものが難しいあらゆるもの。 出力が正しいかを安く判定できないなら、頻繁に間違えるモデルを使う余裕はありません。

ここでの失敗はリトライ1回では済みません — 返金、解約する顧客、あるいは私の時間がかかります。それに比べれば、トークンあたりの割増は端数の誤差です。

私が実際に出荷しているルーティングのルール

エージェントごとに一つのモデルを選ぶことはしません。エージェント内でタスクごとにルーティングし、たいていは安価な分類器がどの下流モデルが処理を担うかを決めます：

function pickModel(task: Task): string {
  // 安価・検証可能・高ボリューム → Haiku
  if (task.type === "classify" || task.type === "extract") {
    return "claude-haiku";
  }
  // オープンエンドまたは顧客向け → Sonnet
  if (task.customerFacing || task.steps > 2) {
    return "claude-sonnet";
  }
  return "claude-sonnet"; // デフォルトは安全な選択
}

ここには二つの原則が刻まれています。デフォルトは安全なモデルに、安いモデルではなく — コストは動くベースラインから下げて最適化するもので、壊れた状態から信頼性を上げていくものではありません。そしてエスカレートせよ、賭けるな：簡単な80%を Haiku に任せ、難しい20%を Sonnet に渡す。このハイブリッドは、どちらか一方のモデルだけですべてを動かすのにほぼ常に勝ります。

さらに上乗せできるプロンプトキャッシングもあります：システムプロンプトが大きく再利用される場合、キャッシングは階層にかかわらず入力コストを大幅に削減し、時には Sonnet を十分に安くして Haiku の問いそのものを無意味にします。

自分のスタックからの具体例

高ボリュームの受信トリアージのステップを例にとります。何千回も動き、タスクは三分類で、ミスしてもアイテムがレビューキューに落ちるだけ — 検出が安く、リスクが低い。これは教科書どおりの Haiku タスクであり、Sonnet から外したことで、重要な結果に測定可能な悪影響を与えずに、そのステップのコストを目に見えて下げられました。

次に、実際の顧客への返信を起草するステップを取り上げます。ボリュームは低く、オープンエンドで、悪い下書きが出れば信頼を損ないます。これは Sonnet のままにします。同じエージェント、二つのモデル、リスクでルーティング。私はAIエージェントが本当に機能しているかをどう測るかで述べているやり方で、両方の実行あたりコストと成功指標を見ています — そして、評価が「安いモデルでも成功率を維持できる」と告げてはじめて、そのステップを一段下げます。

よくある質問

実務上、Claude Haiku は常に Sonnet より安いですか？

トークンあたりでは、はい — 大きな差で。成功した結果あたりでは、常にではありません。Haiku の低い成功率がリトライと人手による後始末を招くと、ミスの検出や修正にコストがかかるタスクでは、総コストが Sonnet を上回ることがあります。

あるタスクで Haiku と Sonnet をどう選び分けますか？

タスクを二つの軸で採点します：出力がどれだけ検証可能か、そしてミスがどれだけ高くつくか。検証が安く、低リスクで高ボリュームの仕事は Haiku へ；オープンエンド、顧客向け、または検証が難しい仕事は Sonnet へ。エージェントごとではなく、タスクごとにルーティングします。

追うべき唯一のコスト指標は何ですか？

成功した結果あたりのコスト — 呼び出しコスト掛ける試行回数に期待後始末コストを足し、成功率で割ったもの。呼び出しあたりの価格だけではリトライと人間の時間が隠れてしまい、そこで安いモデルが知らぬ間に高くつきます。

一つのエージェントで両方のモデルを使えますか？

はい、たいていはそうすべきです。最も強力なパターンは、安価な一次処理（Haiku が分類またはフィルタ）が曖昧なケースだけを Sonnet にエスカレートするものです。このハイブリッドは、単一の階層ですべてを動かすのに通常は勝ります。