Q8　モデル選定の判断基準

Q8. モデル選定の判断基準

タスクごとにモデルを選ぶとき、レイテンシ・品質・コストのどれを優先してどう判断していますか？ 実際にA/Bテストや簡易ベンチで比較した例を教えてください。

出典: @voidwarriorchan の投稿（2026-08-25）

この質問は何を聞いているのか

レイテンシ（latency）は、プロンプトを送ってから応答が返るまでの遅延で、モデルの大きさやプロンプト・出力の複雑さに左右される。品質は各社で呼び方が違い、Anthropicは「capabilities（能力）」、OpenAIは「accuracy（精度）」と呼ぶが、いずれも「タスクをどれだけ正しくこなせるか」を指す。コストは一見シンプルだが、後述のとおり「トークン単価」と「タスク完了あたりの実際の支払い」は別物である。

A/Bテストは本番トラフィックをモデル間で分けて挙動を比較する手法、簡易ベンチは本番投入前に正解付きのgolden setで候補を走らせる事前のオフライン評価を指す（型は実務の節で扱う）。どちらも「候補を実測して比較する」という点で共通し、直感や公開ベンチマーク（= 各社が共通の問題で性能を測り公表する評価指標）だけで決めることの対極にある。

つまりこの質問は、複数の候補モデル、および同じモデル内のeffort（= 思考量やトークン消費を段階的に変える設定。次節で説明する）の中から、レイテンシ・品質・コストのどれを優先してタスクに割り当てているか、そしてその判断を勘や公開スコアだけでなく自分たちのタスクを使った比較実験で裏付けた経験があるかを尋ねている。候補者がモデル選定を「1回選んで終わり」ではなく「測り続ける仕組み」として扱っているかを、この質問への回答から測ることができる。

レイテンシ・品質・コストの三角形と、effortという第4の軸

Anthropicは「capabilities（能力）・speed（速さ）・cost（コスト）のバランス」がモデル選定だと説明し、OpenAIも「accuracy（精度）・latency（レイテンシ）・cost（コスト）のバランス」と同じ構造を示す。基本則はシンプルで、上位モデルほど遅く高くなる。Anthropicの比較表（2026-08 時点）ではHaiku 4.5→Sonnet 5→Opus 5→Fable 5の順にComparative latency（相対的な速さ）が「Fastest→Fast→Moderate→Slower」、料金（入力/出力・100万トークンあたり）が「$1/$5→$2/$10→$5/$25→$10/$50」と並ぶ。OpenAIもLuna・Terra・Sol、GoogleもFlash-Lite・Flash・Pro（Preview）と、料金と能力が段になる同じ階層構造を持つ。

Anthropicはこのeffort（Opus・Sonnet系のモデルが対応し、Haiku 4.5は非対応）を「モデル切替よりも有効なことが多いレバー」と位置づけ、5段階（low / medium / high / xhigh / max）で提供する。OpenAIもreasoning.effortという同種のパラメータ（none〜max、モデル依存）を持ち、Googleは thinking level（low / medium / high）という形で似た調整軸を持つ。下表の用途欄に出てくるエージェント（= モデルがツールを呼びながら複数の手順を自律的に進める使い方）とサブエージェント（= その中で下請けとして小さな作業を担う別のモデル呼び出し）も、この後の節で繰り返し使う言葉である。

トークン単価ではなく「タスク完了あたりのコスト」で見る

料金表は100万トークンあたりの単価で書かれているため、単価だけを見るとFable 5はSonnet 5より何倍も高く見える。だがAnthropicは「実際に払っているのはタスク完了ぶんのコストであって、トークン単価ではない」と明言する。より能力の高いモデルは、少ないやり取り（ターン数）・少ない探索・少ない読み直しでタスクを終えられるため、単価の高さが「作業量の少なさ」で相殺されることがある。

ただし、上位モデルが常に勝つわけではない。SWE-bench Pro（コーディング課題のベンチマーク）のサブセットでは、Opus 5単体がFable 5単体と同水準の精度（91.7%対91.3%、実測のばらつきの範囲内）を約60%のコストで達成しており、この場合は単価の安いモデルがタスク完了あたりのコストでも安かった。GPQA Diamond（大学院レベルの専門知識を問う問題集）では、Haiku 4.5はOpus 5の約10分の1のコストだったが、精度は63%対92%と大きく落ちた——こちらは安いモデルが安いまま、精度だけが下がった例である。「順位はワークロードによって反転し、価格表だけではどちらが勝つか分からない」——だからこそAnthropicは、候補のすべてを自分のトラフィックで「タスク完了あたりのコスト」に換算して測ることを求めている。

比較は中央値ではなく「テール（一番難しい1割）」で見ることも重要だ。典型的なタスクではどのモデルも似た結果になり一番安いモデルが最良に見えるが、実際の請求額を決めるのは安いモデルが失敗するタスクの方で、失敗した分のトークン・再試行・後始末のコストが乗ってくる。あるベンチマークでは20問中たった2問が支出全体の43%を占めた。

実務では何をするのか

golden setを作り、候補を並べ、表にする

Anthropicは選定の4ステップを示す。①ユースケース専用のベンチマークを作る（最重要とされる）。②実際のプロンプトとデータでテストする。③精度・応答品質・エッジケースへの対応を候補間で比較する。④性能とコストのトレードオフを検討する。golden set（正解付きの評価用データセット）の作り方は出典によって起点が違う。Anthropicの手順は本番ログから実トラフィックの比率で抜き出す。LangSmithはまず5〜10件の手作り例から始め、10〜20件で主要シナリオとエッジケースを網羅してから、本番投入後の実トレースを取り込んでいくことを勧める。件数の目安はOpenAIが約100件。原則は「質より量」——少数の高品質な人手評価より、自動採点できる問いを多く集める方がよい。極端に長い・曖昧・無関係な入力といったエッジケースを含めることも欠かせない。

始める起点は2通りある。「効率優先」はまず下位モデルから実装し、性能が要件を満たすかテストしてから能力不足の箇所だけ引き上げる。「能力優先」はまず上位モデルから実装し、プロンプトを最適化してワークフローが安定してからコストを下げていく。低レイテンシ・低コストが必須なら前者、複雑な推論や高い正確さが必要なら後者が向く。

精度の目標は損益分岐で決めると説得力が出る。OpenAIのニュース分類の例では、正しい分類は$50の節約、誤分類は$300のコストになると仮定すると損益分岐は85.8%で、目標は90%以上に設定される。

比較結果は「品質×コスト×レイテンシ」を表にまとめ、目標値との合否で判断する。OpenAIの公式ガイドが型として示す実例（GPT-4o世代のデータで現行モデルの推奨ではない点に注意）は、zero-shot（例を1つも見せずに指示だけで答えさせる）・few-shot（正解例を数件プロンプトに添えて答えさせる）・fine-tuning（特定タスク向けにモデルを追加学習すること）という3手法を、目標を精度90%以上・コスト1,000記事あたり$5未満・レイテンシ2秒未満として比較したものだ。

fine-tuningした小型モデルは、同等の精度を元のコストの2%未満で達成した。表にすれば、どの候補がどこで妥協しているかが一目で分かる。

採点方法を選ぶ — コード・LLM・人手をどう使い分けるか

Anthropicは採点方法を「最速・最も信頼できる・最もスケールする順」に選べと言う。3方式のうちコードベース採点（完全一致や特定の語句を含むかの判定）は最速で信頼性も高く第一候補になるが、ニュアンスの判定には向かない。LLM採点（LLM-as-a-judge）は速くて柔軟だが、まず信頼性を検証してから拡大させる必要がある。人手採点は柔軟で質は高いが遅く高コストで、公式は「可能なら避ける」とする。したがって実務の優先順位はコード採点→LLM採点→人手採点になる。

LLM採点の妥当性を調べた研究では、強力なモデルの判定は人間同士の一致率（81%）と同水準かそれ以上（引き分け票を除いて集計すると85%）だった。ただし3つの偏りが報告されている。位置バイアスは先に提示した回答を優れていると判定しやすい偏りで、対策は順序を入れ替えて2回判定し、両方で同じ勝者になった時だけ採用することだ。冗長性バイアスは長い回答を高く評価する偏りで、水増しした回答への実験ではあるモデルが91.3%騙されたのに対し別のモデルは8.7%しか騙されなかった。自己選好バイアスは判定役が自分と同系統のモデルの出力を優遇する偏りで、実験ではGPT-4は自分の勝率を10%高く、Claude-v1は25%高く判定したが、論文自身は「データが少なく差も小さいため、自己選好バイアスがあるとは断定できない」としている。参照解を判定役に先に独立して作らせてから採点させると、判定の誤りが大幅に減ることも報告されている。

簡易ベンチ（offline）とA/Bテスト・shadow運用（online）を使い分ける

オフライン評価はデプロイ（本番投入）前に、正解（参照出力）付きのgolden setで候補を比較する——ベンチマーク・回帰テスト（新版で品質が落ちていないかの確認）・バックテスト（過去の本番データで新版を試す）がこれにあたる。オンライン評価は本番投入後に、参照出力のない実際のトレース（やり取りの記録）を継続的に見る——リアルタイム監視・異常検知・フィードバック収集がこれにあたる。参照出力の有無で「何を測れるか」が変わり、offlineは正解との一致を測れるが、onlineは品質のパターンや安全性など参照なしでも測れるものに限られる。

A/Bテストは本番トラフィックの一部を使い、既存モデルや以前のバージョンとの比較を行う定量的な手法として位置づけられている。Anthropicの選定手順の最終段は「オフラインで勝った候補を、切り替え前に本番トラフィックの一部でshadow運用（結果は使わず記録だけ取る運用）し、その後も評価の仕組みを回し続ける」ことだ。本番で見つかった問題（悪いフィードバック、長いレイテンシ、エラー等）はoffline側のgolden setに追加され次の比較に使われる——このoffline→online→offlineの往復が選定を継続的な仕組みにする。

比較を大量に安く回す手段としてBatch API（結果をすぐ必要としない場合の一括処理API）が使える。Anthropicの場合（2026-08 時点）1回で最大10万件・256MBまで送れ、多くは1時間以内に終わるが、24時間以内に処理が終わらない分は期限切れになる。結果は29日間残る。通常の半額で使え、公式も「大規模な評価——何千件ものテストケースの処理」に向くと明記している。

コストを実測するには応答の使用量（usage）フィールドを見る。Anthropicのレスポンスには次の4種類のトークン数が入り、それぞれの単価は通常入力・出力のほか、キャッシュ読み取り（後述のプロンプトキャッシングで使い回した分。通常入力の0.1倍）とキャッシュ書き込み（新規にキャッシュへ保存する分。1.25〜2倍）に分かれる。これらを掛けて合計すれば1回のやり取りの実コストが出せる。全リクエストで積み上げれば「タスク完了あたりのコスト」になる。

{
  "input_tokens": 105,
  "output_tokens": 6039,
  "cache_read_input_tokens": 7123,
  "cache_creation_input_tokens": 7345
}

モデルやeffortの引き下げのように品質と引き換えにコストを下げる手段を検討する前に、Anthropicは品質を落とさずコストだけを下げる「無料の勝ち」——プロンプトキャッシング（第3章Q2で扱った、プロンプトの共通部分の計算結果を使い回す仕組み）、不要なトークンの整理、24時間待てる作業へのBatch処理、支出上限の設定——を先に使い切ることを勧める。実測では、プロンプトキャッシングだけでエージェントループのコストを2.5〜3.7分の1に下げ、ある小さな振り分けエージェントの請求を83%（入力削減も加えると88%）削減したと報告されている。

失敗が判定できるタスクは、低effort全件→失敗だけ再実行が効く

タスクの成否を機械的に判定できる（テストが通る、チケットが閉じる等）場合、固定の設定で全件を流すより、まず全件をlow effortで流し失敗した分だけより高いeffortで再実行する方が効率がよい。SWE-bench Proのサブセットでの計測では、Opus 5をlow effortで流すと16%が失敗したが、その分だけdefaultで再実行すると約93%が合格し1問あたり約$0.70、全件を最初からdefaultで流した場合は91.7%の合格で$1.39だった——ほぼ同じ合格率を半分のコストで達成している。条件は2つある。失敗を機械的に見抜ける判定器（テストなど）が必要で、判定器が悪い出力を素通りさせれば機能しない。また1回目に失敗したタスクは2回分の処理時間がかかるため、節約できるのはコストであってレイテンシではない。

回答を見極めるポイント

深掘り質問の例

• そのタスクで、上位モデルと下位モデルの「タスク完了あたりのコスト」はどちらが安かったですか？
• golden setは何件・どうやって集めましたか？エッジケースは含まれていますか？
• LLM自身に採点させた場合、その判定が信頼できることをどうやって確かめましたか？

つまずきポイント

理解度チェック

まとめ

• レイテンシ・品質・コストは綱引きの関係にあり、同じモデル内でも「effort」という第4の軸でコストとレイテンシを調整できる
• 料金表のトークン単価と、実際に払う「タスク完了あたりのコスト」は逆転することがあり、比較は自分のワークロードで実測するしかない
• golden setを本番ログから作り、候補×effortをオフラインで走らせ、品質×コスト×レイテンシを表にして目標との合否で判断する
• 採点はコード採点を優先し、LLM-as-judgeを使う場合は位置・冗長性・自己選好（論文では未確定）という3つの偏りに注意する
• オフライン評価で候補を絞り、shadow運用やA/Bテストで本番投入前に確認し、本番で見つかった失敗例をgolden setに戻し続ける

次章のQ10「プロンプトインジェクション防御」では、ユーザー入力や外部データという「区別のつかない文字列」がコンテキストに混ざり込む危険と、その対策を見ていく。

参考リンク

• Anthropic — Choosing a model
• Anthropic — Models overview
• Anthropic — Optimizing for cost and intelligence
• Anthropic — Develop tests (evals)
• Anthropic — Effort parameter
• Anthropic — Prompt caching
• OpenAI — Model selection guide
• OpenAI — Evals guide
• LangSmith — Evaluation concepts
• arXiv — Judging LLM-as-a-judge with MT-Bench and Chatbot Arena