はじめに
新しいLLMがリリースされるたびに、モデルカード・ベンチマーク結果・SNS上の賛否が一斉に流れてきます。
そのたびに「うちのプロダクトは乗り換えるべきか」を判断させられるのですが、この判断は考えれば考えるほど難しい問題だと感じています。
この記事は、Anthropic の Applied AI チームによるセッション動画「How to pick the right model」の内容を整理し、LLMのモデル選定をどう進めるかという観点でまとめ直したものです。
動画で語られている考え方に加えて、実務に落とすときの手順も補足しています。
対象読者
- LLMを組み込んだプロダクトやエージェントを開発している方
- 新モデルが出るたびに「乗り換えるべきか」の判断に悩んでいる方
- LLMのコスト・レイテンシー・品質のバランスに課題を感じている方
前提
- 2026年7月時点の動画内容をもとにしています。
- 動画内では Claude の Opus / Sonnet / Haiku 系モデルが例に使われていますが、考え方自体は特定のプロバイダーに依存しません。
- Thinking・Effort・プロンプトキャッシングなどの機能仕様は変わる可能性があるため、実装時は各プロバイダーの公式ドキュメントを確認してください。
要点（最初に結論）
動画の主張は次の3点に集約できます。
- 小規模でも適切に設計された独自Eval（評価テスト）は、どの公開ベンチマークよりもモデル選定の役に立つ
- 選ぶべきモデルは「1トークンあたりが最も安いモデル」ではなく「成功した結果1件あたりが最も安いモデル」である
- Thinking・Effort・プロンプトキャッシング・コンテキストエンジニアリングという調整手段を使えば、コストと品質のトレードオフ曲線そのものを動かせる
つまり、モデルはブランド名やトークン単価で選ぶのではありません。
自社の実タスクを使ったEvalで「成功結果あたりの品質・時間・コスト」を測定して選ぶ、ということです。
モデル選定はなぜ難しいのか
一般的なモデルの使い分けは、概念としては単純です。
- 高い知能・複雑な判断が必要なら Opus
- 低レイテンシー・低コストが重要なら Haiku
- その中間のバランスが必要なら Sonnet
しかし、実際にはモデル名だけでは決められません。
同じモデルでも Thinking（回答前の内部検討）や Effort（タスク全体に割く労力）の設定によって、品質・速度・コストが大きく変わるためです。
たとえば次のような組み合わせを比較する必要が出てきます。
- Thinkingを強くした Sonnet
- Thinkingを弱くした Opus
- Thinkingなしの Haiku
さらに他プロバイダーのモデルも候補に入れると、比較対象は「モデル × 設定」の組み合わせに膨れ上がります。
この組み合わせをどう評価するかの軸として、動画では次の3つの柱が挙げられています。
| 柱 | 見るもの |
|---|---|
| 品質 | タスクの完了率・正確性 |
| レイテンシー | 結果が返るまでの時間（顧客向けでは特に重要） |
| コスト | 1回の成功結果を得るためにいくらかかるか |
公開ベンチマークの限界
SWE-bench や WebArena のような公開ベンチマークは、「コーディング能力が全体的に向上したか」といった方向性を知るには役立ちます。
一方で、実際の業務には次のような固有条件があります。
- ベンチマークに登場しないプログラミング言語を使う
- 社内データの検索と外部リサーチを組み合わせる
- 独自の業務ツールを呼び出す
- 社内ルールや業務フローに従う必要がある
たとえば「Web上でニッチなSDK情報をリサーチして、それをコードに実装する」エージェントを考えてみます。
これはリサーチ系とコーディング系の2つのベンチマークにまたがっており、どちらか一方のスコアだけでは性能を予測できません。
そのため、公開ベンチマークで高得点のモデルが自社の業務でも最適とは限りません。
数十件程度の小規模なものでもよいので、実際のユースケースを代表する独自Evalを作る方が、モデル選定には有効です。
独自Evalの作り方
Evalは複数の「タスク」で構成します。
タスクとはEvalの最小単位で、入力のセットと成功基準を持つテストです。
動画では「学校の数学のテスト」というたとえが使われています。
問題と正解があるだけでなく、途中式（計算の過程）も採点対象になる、という点がポイントです。
入力
↓
期待する最終結果
↓
期待する処理プロセス
↓
採点方法
最終結果だけでなくプロセスも評価する
エージェント型のタスクでは、最終回答が正しいだけでは不十分です。
カスタマーサービスエージェントを例にすると、次の両方を確認します。
- 顧客への回答が期待値と一致しているか（結果）
- 正しい方法でデータベースをクエリしたか、必須のツールを呼んだか、禁止された操作をしていないか（プロセス）
採点方法は2種類を組み合わせる
採点者（grader）には、性質の異なる2種類を組み合わせます。
LLMによる評価（LLM as a Judge）は、柔軟な判断が必要な項目に使います。
- 回答内容が期待値と意味的に一致しているか
- SQLの書き方が多少違っていても、同じデータを取得できているか
- 顧客への説明として適切か
コードによる決定論的な評価は、プログラムで明確に判定できる項目に使います。
- 指定されたツールを呼び出したか
- 必須の引数（たとえば顧客の国に合わせたローカライズ指定）を渡したか
- 禁止されたAPIを使っていないか
- 出力形式が正しいか
最初に「何が正しい結果か」「そこに至る正しい手順は何か」を自分で定義する作業は地道です。
しかし動画では、AIで多くの作業が自動化されていく中で、Evalデータセットの構築は人間の時間の最も有意義な使い方のひとつだと述べられています。
Evalでよくある4つの失敗
Anthropic社内でのEval運用経験から、陥りやすい失敗パターンが4つ紹介されています。
1. ノイズを性能差と誤認する
LLMの出力には揺らぎがあります。
1回だけ実行して判断せず、同じタスクを複数回実行して結果が安定するかを確認する必要があります。
結果のばらつきが大きい場合は、タスクの指示や採点基準が曖昧である、Evalデータが不足している、といった兆候かもしれません。
2. インフラ障害をモデル性能として評価する
特定モデルのスコアが極端に低いとき、原因がモデルではないケースがあります。
APIエラー・タイムアウト・ツール呼び出しの失敗・レートリミットなどはインフラの問題であり、モデルの評価からは切り離す必要があります。
スコアだけを見ず、実行ログを確認することで見分けられます。
3. Evalデータが本番を代表していない
テストデータが簡単すぎると、すべてのモデルが高得点となり差が見えなくなります。
本番リリース後は、実際に失敗したケースをEvalに追加し続けるループを作ることが重要です。
本番で失敗
↓
原因を分析
↓
Evalケースに追加
↓
モデル・プロンプトを改善
↓
再評価
4. モデル変更時にプロンプトをそのまま使う
モデルごとにツール呼び出しや指示解釈の傾向が異なります。
動画では、登壇者が Claude の内部ツールを作っていたときの実例が紹介されています。
Opus 4.5 ではほとんどトリガーされなかったツールが、Opus 4.6 では全く同じプロンプトで過剰にトリガーされてしまった、という内容です。
モデルを変えるときは、プロンプティングガイドの確認・プロンプトやツール説明の調整・Evalの再実行をセットで行う必要があります。
トランスクリプトを読む
動画で最も強調されていたのが「トランスクリプト（実行ログ）を読むこと」です。
Evalのスコアだけでは、モデルが正しい方法でタスクを完了したかは分かりません。
システムプロンプト・ツール呼び出しとその引数・ツールの実行結果・エラー内容・ターン数・トークン数といった生のログを追跡できる状態にしておく必要があります。
動画では LangSmith や Braintrust といったトレーシングプラットフォームが例に挙げられています。
象徴的な実例も紹介されています。
コーディングエージェントのEvalで非常に高いスコアが出たものの、トランスクリプトを掘り下げたところ、モデルがGitの履歴に入り込み、以前の試行の内容から答えを抽出していたことが判明したケースです。
ヘッドラインの数字だけを見ていれば「大改善」に見えますが、実際にはEvalの抜け道を突いていただけでした。
スコアは結果を教えてくれますが、原因は教えてくれません。
生データに近づくほど、修正すべき本当の課題が見えてきます。
ThinkingとEffortという2つのダイヤル
モデルの挙動を調整する手段として、動画では2つのパラメータが説明されています。
- Thinking（思考）は、回答や行動を開始する前にモデルがどの程度内部で検討するかを制御します。行動前に考えるためのメモ帳のようなもので、複雑な計画・推論・判断が必要なタスクで効果が出やすい設定です。
- Effort（労力）は、思考量・ツール呼び出し回数・調査量・回答の詳しさ・出力トークン数など、タスク全体に割く労力を制御します。
この2つは独立して調整できるため、「低Thinking × 高Effort」「Thinkingなし × 低Effort」のような組み合わせが可能です。
モデル名を選ぶだけでなく、この2つのダイヤルでコストと精度のバランスを細かく制御できます。
高性能モデルの方が速い場合がある
動画では、直感に反する実例が紹介されています。
社内のコード修正パイプラインで、Thinkingなしの Haiku 4.5 が92%のスコアを出していました。
Thinkingを有効にすると100%に達しました。
ここで Sonnet と Opus でも同じEvalを再実行したところ、どちらも100%に達しただけでなく、Haiku よりも短い時間でタスクを完了しました。
もうひとつ、Opus 4.5 リリース時のデータも挙げられています。
Opus 4.5 は Sonnet より高い精度でタスクを完了しただけでなく、Sonnet より大幅に少ない出力トークン数で完了しました。
「小さなモデル＝速い」という感覚だけで選んでいたら、この事実には気づけなかったはずです。
エージェント型タスクで高性能モデルの方が速く終わることがある理由は、次のとおりです。
- 最初から適切な計画を立てられる
- 不要なツール呼び出しややり直しが少ない
- 少ないターン数・少ない出力トークンで完了する
そのため、測定すべきレイテンシーは1回のレスポンス速度ではなく、タスク開始から正常完了までの総時間（End-to-End Latency）です。
「成功結果あたりのコスト」で比較する
トークン単価の安いモデルでも、何度もやり直す・ツールを過剰に呼ぶ・間違った方向に進んで人間の修正が必要になる、といったことが起きれば最終的なコストは高くなります。
逆に単価の高いモデルでも、少ないターン数で確実に完了できれば、結果的に安くなる場合があります。
見るべき指標は次の式で表せます。
成功結果あたりのコスト
＝ Eval実行全体のコスト ÷ 正常に完了したタスク数
「1トークンあたりの価格」ではなく「成功1件あたりの価格」で比較する、というのがこの動画の中心的なメッセージです。
プロンプトキャッシングで曲線そのものを動かす
ここまでは「モデルと設定の組み合わせから最適点を選ぶ」話でした。
動画の後半では、コストと品質のトレードオフ曲線そのものを押し上げる手段が2つ紹介されています。
1つ目がプロンプトキャッシングです。
プロンプトキャッシングは、毎回同じ内容を再処理せず、事前に計算されたプロンプトの共通プレフィックスを再利用する仕組みです。
キャッシュにヒットした入力トークンは定価の10分の1の価格で利用できます（動画内の説明。最新の料金体系は各プロバイダーの公式ドキュメントを確認してください）。
これにより、次のような使い方が現実的になります。
- Sonnet 相当の予算で Opus を使う
- Haiku 相当の予算で Sonnet を使う
- 長いシステムプロンプトや大量の社内ドキュメントを低コストで共通コンテキストにする
動画では、最高水準のAIシステムはキャッシュヒット率80〜90%程度を達成しており、これが目標とすべき水準だと述べられています。
APIのレスポンスにはキャッシュされたトークン数の指標が含まれるため、ヒット率の計測自体は難しくありません。
キャッシュを壊さない設計は「Append Only」
キャッシュを効かせる最もシンプルな戦略は、プロンプトを追記専用（Append Only）として扱うことです。
固定システムプロンプト
固定ツール定義
固定ルール
過去のメッセージ
新しいメッセージだけを末尾に追加
よくある失敗は、システムプロンプトに現在日時を埋め込むことです。
ターンごとに時刻が進むため、毎回キャッシュが壊れます。
ランダムID・毎回変わるユーザー情報・順序が変わるツール定義も同様です。
動的な情報は、キャッシュ対象となる固定プレフィックスより後ろに配置します。
コンテキストエンジニアリングで精度も上がる
2つ目がコンテキストの整理です。
動画では「複雑なマルチエージェント構成を考える前に、まずコンテキストをきれいに保つことに時間を使うべき」という趣旨の指摘がされています。
モデルに渡す情報が多いほど性能が上がるわけではありません。
不要な情報が増えると、コストとレイテンシーが増えるだけでなく、重要情報の見落としやツール選択の誤りにつながり、精度も下がります。
ツールレスポンスを整形する
APIのJSONレスポンスをそのままモデルに渡すのではなく、必要な情報だけに整形します。
動画で挙げられていたのは、スポーツの試合結果を返すツールの例です。
- JSONではなくMarkdownで返す
- 長いタイムスタンプをシンプルな日時文字列にする
- 曜日を付加する（モデルが日付から曜日を計算する手間を省く）
この整形だけで、ツールレスポンスのトークン数を66.4%削減できたと報告されています。
エージェントが複数ターンを重ねる場合、ツールレスポンスは会話の毎ターンに含まれるため、この削減効果は複利で効いてきます。
検索結果の重複を排除する
もうひとつの事例がWeb検索です。
複数の検索を実行して記事を取得し、モデルに渡す前に重複記事を排除する、というひとつの工夫だけで次の結果が得られています。
- 入力トークン数が77%減少
- コストが65%削減
- 推論すべきデータが減ったことで精度が9%向上
コンテキスト削減はコスト対策にとどまらず、精度改善にもつながる、という点がこの事例の重要なところです。
浮いた予算でより高性能なモデルを使う、という選択肢も生まれます。
実務でのモデル選定手順
ここまでの内容を、実務の手順に落とすと次のようになります。
Step 1: 重要指標を決める
ユースケースごとに、品質・速度・コストのどれを優先するかを定義します。
Step 2: 代表的なEvalケースを作る
通常ケース・難しいケース・エラーケース・境界ケース・本番で過去に失敗したケースを含めます。
Step 3: モデルと設定の組み合わせを実行する
Haiku × Thinkingなし
Haiku × Thinkingあり
Sonnet × Low Effort
Sonnet × High Effort
Opus × Low Effort
Opus × High Effort
Step 4: 測定する
タスク成功率・成功結果あたりのコスト・End-to-End Latency・トークン数・キャッシュヒット率・ツール呼び出し回数・ターン数・インフラエラー率を記録します。
Step 5: トランスクリプトを確認する
高スコア・低スコアの両方のログを読み、モデルが正しい方法でタスクを完了しているかを確認します。
Step 6: パレート最適な構成を選ぶ
すべての指標で最高のモデルは通常存在しません。
「品質を一定以上維持した最安構成」「レイテンシー上限を満たす最高品質構成」のように、Step 1 で決めた優先順位に合う構成を選びます。
動画の最後では、カスタマーサービス系ベンチマーク（TauBench の航空会社タスク）でこの手順を実演した結果が示されています。
- 最高のパス率を出したのは Opus 4.7（Thinking: On、High Effort）で、しかも Sonnet より少ないトークン数で達成した
- コスト重視なら、Haiku（Thinking: On）が Sonnet（Thinking: On、High Effort）と同等の性能をより低コストで出した
- レイテンシーでも、Opus（High Effort、Thinking: On）は同等のThinkingレベルの Sonnet より速かった
「どの指標を優先するか」で選ぶべき構成が変わることが、データで示された形です。
まとめ
この動画の本質は、次の一文に集約できます。
AIモデルはブランド名やトークン単価で選ぶのではなく、自社の実タスクを使ったEvalによって「成功結果あたりの品質・時間・コスト」を測定して選ぶ。
最適化の順番は次のとおりです。
独自Evalを作る
↓
モデルとThinking・Effortの組み合わせを比較する
↓
トランスクリプトで原因を確認する
↓
プロンプトキャッシュを最適化する
↓
コンテキストを削減・整形する
↓
成功結果あたりのコストで最終判断する
モデル選定は一度きりの作業ではありません。
新モデルの登場や本番データの蓄積に合わせて繰り返す、継続的な評価プロセスです。
筆者自身も、モデルのリリースノートとSNSの評判だけで乗り換えを判断しそうになることがあります。
まず小さくてもEvalを持つことが、その場の空気に流されない判断の土台になると感じています。