Claudeのモデルの使い分けを実測|同じ分類40件をOpus/Sonnet/Haikuでコスト対精度を比較

2026.07.09 約 10 分で読めます
Opus・Sonnet・Haikuの精度を表す3本の等長ティールバーと、コスト5対3対1を示すアンバーのコイン。精度は横並びでコストだけ開くことを表した図のアイキャッチ

公式の料金表は見ました。でも「自分のタスクでOpusとHaikuの精度がどれだけ違うのか」は、あの表からは分かりません。そこで同じ日本語の問い合わせ40件を、Opus 4.8・Sonnet 5・Haiku 4.5に同じ条件でブラインド分類させ、精度とコストを実測しました。結果は少し意外でした。数字を見ながら、モデルの使い分けを考えます。

結論:仕様が明確なタスクなら、精度は頭打ちになる

先に答えを言うと、6カテゴリへの問い合わせ振り分けのように仕様が明確なタスクでは、3モデルの精度は97.5〜100%で並びました。カテゴリが明確な25件は、3モデルとも全問正解。差がついたのは、あえて多義的にした「罠」15件のうち、たった1件だけです。

一方でコストは、Opus・Sonnet・Haikuで5:3:1。同じ仕事に5倍払っても、このタスクでは精度は買えませんでした。だからモデルの使い分けの軸は、精度ではなくコストと速度に寄ります。ここが、料金表だけ見ていても気づけないところでした。

何を測ったか — 40件・6カテゴリ・15個の罠

題材は、架空のサポート窓口に届く顧客問い合わせ40件です。実在の個人情報は使わず、すべて合成のダミー文にしました。これを次の6カテゴリのどれか1つへ分類させます。

カテゴリざっくりした中身
請求料金・支払い・返金・明細
技術サポートエラー・不具合・使い方
解約退会・アカウント閉鎖の手続き
機能要望無い機能を追加してほしい
クレーム対応品質そのものへの不満
その他営業時間・会社情報・仕様確認など

ポイントは、40件のうち15件を「罠」にしたことです。表面の言葉と本当の用件がズレた文にしました。たとえば怒りの言葉が並んでいても、中身は二重請求の相談。「解約するぞ」と書いてあっても、本質は機能要望。こういう境界を、どのモデルがどう捌くかを見たかったのです。

罠の例(表面の言葉 → 本当の用件)
id26「二重請求されていて本当に頭にきています。いい加減にしてほしい。」→ 請求
id28「一括編集機能がないと不便すぎるので、追加されないなら解約も考えます。」→ 機能要望
id36「エラーの件で3回問い合わせましたが毎回たらい回しで解決しません。もう呆れています。」→ クレーム

各モデルには、カテゴリ定義と分類ルールだけを渡しました。正解データは見せていません(ブラインド)。3モデルはそれぞれ別プロセスで走らせ、渡す入力と出力形式はまったく同じ。使ったのはこの3つです。

  • Opus 4.8(claude-opus-4-8
  • Sonnet 5(claude-sonnet-5
  • Haiku 4.5(claude-haiku-4-5

3つとも、2026年7月時点で最新のバージョンです。モデル名・IDと料金の一次情報は、Anthropic の公式ドキュメントに揃っています(モデル一覧料金)。以下の数字は、この公式単価を基準にしています。

実測結果:精度は横並び、コストは5:3:1

Opus 4.8・Sonnet 5・Haiku 4.5の全体精度とコストの対比図。精度は97.5〜100%で横並び、コストはHaikuを1とすると5:3:1
全体精度はほぼ横並び、コストだけが5:3:1で開く

採点結果がこちらです。所要時間はエージェント経由の計測なので純粋なAPIレイテンシではありませんが、速い・遅いの傾向は掴めます。

モデル全体40件罠15件明確25件所要(相対)
Opus 4.897.5%93.3%100%約199秒
Sonnet 597.5%93.3%100%約125秒
Haiku 4.5100%100%100%約58秒

正直、ここは少し驚きました。一番安いHaikuが40件を全問正解し、OpusとSonnetは1件ずつ外したのです。ただ、これを「Haikuの勝ち」と読むのは早い。40件で39/40と40/40の差は、統計的にはほぼ誤差の範囲です。モデルの使い分けを数字で見ると、3モデルとも天井付近で並んだ、というのが素直な読み方でした。

差がついた罠アイテム(誤りも隠さず)

外した2件は、どちらも「私が付けた正解ラベル自体が割れる」きわどい罠でした。良く見せるために消したりせず、そのまま出します。

id40「返金対応が遅く、何度催促しても進みません。誠意ある対応を求めます。」
  Opus   → クレーム    ← 正解ラベルは「請求」(返金という実務用件で取った)
  Sonnet → 請求 ✓
  Haiku  → 請求 ✓

id36「エラーの件で3回問い合わせましたが毎回たらい回しで解決しません。もう呆れています。」
  Opus   → クレーム ✓
  Sonnet → 技術サポート  ← 正解ラベルは「クレーム」(主旨はたらい回しへの不満)
  Haiku  → クレーム ✓

Opusは「返金の遅さ」を怒りとして受け取り、Sonnetは「たらい回し」の裏にある技術問題を拾いました。どちらの判断にも一理あります。つまり、真に多義的な入力になると frontier モデルでも判断が割れる。けれど、その割れ方は価格には比例しませんでした。「高いモデルほど罠に強い」という関係は、この実験では見えなかったのです。

コストは何倍違うか

3モデルとも入力・出力のトークン量は同じです。同じプロンプトを渡し、同じ長さのJSONを返させたので、コスト差は純粋に単価差になります。公式単価と、問い合わせ1000件を分類した時の概算がこちらです。為替は1ドル155円で計算しました。

モデルmodel ID入力 $/1M出力 $/1M1000件(概算)対Haiku
Opus 4.8claude-opus-4-85.0025.00約 ¥94×5.0
Sonnet 5claude-sonnet-53.0015.00約 ¥56×3.0
Haiku 4.5claude-haiku-4-51.005.00約 ¥19×1.0

1000件あたりの絶対額はトークン推定に依存する概算です。ただし倍率の5:3:1は、単価から厳密に出ます。Opusはワンコインどころか、Haikuの5倍。月に何万件も捌く窓口なら、この差はそのまま運用費にのしかかります。それでいて、このタスクでの精度は変わらない。ここが判断の分かれ目です。

スイートスポット:どの工程にどのモデルか

モデルの使い分けは、「精度が頭打ちか否か」で決めると迷いません。頭打ちなら安いモデルで十分。頭打ちしないタスクにだけ、高いモデルを回します。今回の分類のように仕様が明確な処理は、前者の典型です。

どの工程にどのモデルかのスイートスポット図。仕様が明確な定型はHaiku、中程度の判断はSonnet、複雑推論や長時間エージェントはOpus
「精度が頭打ちか否か」でモデルを選ぶ。頭打ちなら安いモデルで十分
  • Haiku 4.5(×1):問い合わせの一次振り分け、タグ付け、抽出・整形・名寄せなど、仕様が明確で大量の定型処理
  • Sonnet 5(×3):要約や下書き生成、コードレビュー補助、やや複雑な抽出。精度とコストの中庸
  • Opus 4.8(×5):複雑な多段推論、長時間の自律エージェント、微妙なニュアンスの文章、難しいvisionや最終品質の判定

実は前に、散らかったフォルダをAIで整理させた回でも、Haiku 4.5の分類精度を実測しています(散らかったフォルダをAIで自動整理)。そのときも「定型分類ならHaikuで足りる」という手応えでした。今回の結果は、それと同じ方向を向いています。段階を分けて、まずHaikuでざっくり仕分け、迷った分だけSonnetやOpusに回す——という設計が現実的です。

この実測の限界(誇張しないために)

気持ちよく「Haikuで十分」と締めたいところですが、そこは正直に。この結果には限界があります。

  • 単一の40件・各1回の試行にすぎない。本番判断には、もっと大きなラベル付きセットで複数回まわしたいところです
  • 所要時間はエージェント経由の概算で、純粋なAPIレイテンシではない。速い・遅いの順序の目安として見てください
  • 罠の正解ラベルは、私の運用ルールに基づく判断。一部は議論の余地があります
  • コストの絶対額はトークン推定に依存する概算。倍率の5:3:1だけが厳密です

それでも言えるのは、「タスクによっては、上位モデルの精度は自分のデータで頭打ちする」という一点です。まず安いモデルで測ってみる。差が出なければ、そのまま安い方でいい。差が出るタスクを見つけたら、そこにだけOpusを積む。この順番が、一番無駄がありません。プロンプトを詰めるほど精度が動く例は、Claudeでネタ出しを仕組み化した回でも書きました。ほかの検証はAI・LLM開発・実装カテゴリにまとめています。

まとめ

  • 同じ日本語分類40件で、Opus 4.8・Sonnet 5・Haiku 4.5の精度は97.5〜100%。明確な25件は全モデル全問正解
  • 差は多義的な罠15件のうち1件だけ。しかも外した2件は正解ラベル自体が割れるきわどい境界
  • コストはHaikuを1として5:3:1。同じ仕事に5倍払っても、このタスクでは精度は買えなかった
  • モデルの使い分けは、まず「精度が頭打ちか」を問う。頭打ちなら安いモデル、頭打ちしない難所にだけ上位モデル

こういう「まず自分のタスクで測ってからモデルを選ぶ」設計は、NEORIVA として法人のAI導入支援でも同じ手順で組んでいます。いきなり最上位モデルを積む前に、安いモデルで頭打ちを確かめる。それだけで運用費の桁が変わることも珍しくありません。

こま

こま

元SE × AI開発 × 業務自動化の実践者

SE 4年 + プログラミング歴 8年。業務自動化と AI 組み込み開発を仕事にしながら、現場で使えるものだけを書いています。 最新のAIの現場を発信中!!