読み込み中

どのモデルをいつ使うか

レッスン 110 分
読み込み中

どのモデルをいつ使うか

Claudeのモデルは能力、速度、コストにおいて異なりますが、どのモデルがタスクに適しているかを推測する必要はありません。なぜなら、それを測定できるからです。このレッスンでは、架空のエンジニアリングコンサルティング会社であるMeridianの例に沿って、1つのプロンプトで50件のプロジェクトレポートから3つの項目を抽出する方法を紹介します。

このビデオのデモは2026年8月に収録されました。Claude Haiku 4.5、Claude Sonnet 5、Claude Opus 5で実行されています。新しいモデルでは結果が異なります。各レッスンのデモはそれぞれ別のeval実行であるため、そのスコアとコストは他のレッスンのものとは一致しません。

タスクに使うClaudeのモデルを選ぶとき、あなたはおそらく直感や同僚の言葉に頼っているでしょう。Claudeのモデルは確かに能力、速度、コストにおいて異なりますが、公開されている比較結果があなたの特定のプロンプトを見たことは一度もないため、どのモデルがあなたのタスクでどう動作するかを教えてくれるものはありません。選び方は、各モデルがあなたのタスクをどれだけの頻度で正しくこなすかを測定し、その後で初めて各モデルのコストを見ることです。

これは壁の上まで届くはしごを買うのによく似ています。価格を見る前に、まず壁の高さを調べます。短すぎるはしごはどんな価格であっても役に立たないからです。推測ではどのはしごが届くかはわかりませんので、実際に測定し、届くものの中から一番安いものを買います。壁が高ければ、より長いはしごが必要で、たとえコストが高くても、それが正しい選択になります。

モデルに関しては、この測定はevalによって行われます。evalとは、すべてのモデルで実行する一連のケースのことです。各ケースは、あなたのプロンプトが受け取る1つの入力と、期待される答えで構成されており、どのモデルも実行する前に人間がその答えを入力から書き起こします。各実行は、モデルが何件のケースを正しくこなしたかでスコアが付けられます。

このレッスンはMeridianの例に沿って進みます。Meridianは毎月、Markdown形式の50件のプロジェクトレポートを受け取り、1つのプロンプトでそれぞれから3つの項目、つまりプロジェクトID、スケジュールのステータス、最大のリスクを抽出します。Meridianのケースはその月の50件のレポートであり、まだわかっていないのはどのモデルがそのプロンプトを実行すべきかということです。

Meridianはこれを5つのステップで解決します。あなた自身のプロンプトでも同じ手順に従うことができます。

  1. モデルがどれだけ正確である必要があるかを決める
  2. 同じケースで各モデルを評価する
  3. 1回の呼び出しにかかるコストを計算する
  4. 完了したタスクあたりのコストでモデルを比較する
  5. 必要な精度を最低コストで満たすモデルを選ぶ

モデルがどれだけ正確である必要があるかを決める

これは壁の高さに相当し、何かのコストを見る前に決めておきます。精度の下限とは、モデルを採用する前にクリアしなければならない、ケースを正しくこなす割合のことです。この下限を決めるには、1つの誤答がどれだけのコストをもたらすかを計算してください。コストが高くなるほど、下限は高くする必要があります。

Meridianの場合、誤答が出ると誰かが手作業でそのレポートを確認する必要があり、それにはおよそ5分かかります。同社のエンジニアは月に5件程度のそうした確認なら対応できるため、50件中5件、つまり10%がその限度となり、Meridianの下限は90%になります。

別のタスクでは下限がはるかに高くなることもあります。たとえば1つの誤答が1,000ドルのコストをもたらす場合、おそらくそれが顧客に届いてしまったからでしょう。その場合、下限は100%になり、モデルのコストはほとんど問題になりません。

同じケースで各モデルを評価する

下限は、それに対してモデルを測定するまでは単なる数字に過ぎません。すべてのモデルを同じケース、同じプロンプトで実行し、ある実行から次の実行で変わるのはモデルだけになるようにしてください。 Meridianは50件のレポートを1つのプロンプトで3つのモデル、すなわちClaude Haiku 4.5、Claude Sonnet 5、Claude Opus 5に通しました。

Meridianのスクリプトは、各項目を期待される答えと照合します。プロジェクトIDとスケジュールのステータスは完全に一致する必要がありますが、最大のリスクは1文で表現されるため、スクリプトはより緩やかに比較し、言い回しのわずかな違いは許容します。各ケースは1つのタスクであり、Meridianにとってはそれは1件のレポートから3つの項目を抽出することを意味します。モデルが3つすべての項目を正しく得た場合にのみ、そのタスクは完了とみなされます。

50件のケースのうち、30件は典型的なレポート、10件は複数のプロジェクトを同時に扱うもの、残り10件はリスクに関するセクションがないものです。下の表は、各モデルのスコアをこの3種類ごとに分解したものです。

モデル典型的複数プロジェクトリスク記載なし総合
Haiku 4.590%100%50%84%
Sonnet 5100%100%100%100%
Opus 5100%100%100%100%

同じプロンプトと90%の下限の下で、各モデルがレポートの種類別に正しく処理できた割合

Sonnet 5とOpus 5はどちらも50件すべて正解しました。Haiku 4.5は50件中42件正解で、これは84%にあたるため、このタスクとこのプロンプトでは下限をクリアしていません。

1回の呼び出しにかかるコストを計算する

2つのモデルが下限をクリアしたところで、コストが関係してきます。課金はトークン単位で行われます。トークンとはモデルが処理するテキストの断片であり、Messages APIからのすべてのレスポンスには、課金対象となる正確なトークン数を保持するusageブロックが含まれています。以下の例は、Meridianのものとほぼ同じ規模のSonnet 5の呼び出しを示す一例で、入力トークンが780、出力トークンが41です。

json
"usage": {
  "input_tokens": 780,
  "output_tokens": 41
}

これらのカウントは、テキストから見積もるのではなく、各モデルのusageから読み取ってください。モデルのトークナイザーとは、テキストをトークンに分割する部分のことで、すべてのモデルが同じものを使っているわけではありません。そのため、同じテキストでもモデルによってトークン数が異なることがあります。Sonnet 5とOpus 5は同じテキストに対しておよそ30%多くのトークンを生成する新しいトークナイザーを使用しており、Haiku 4.5は以前のものを使用しています。

入力トークンと出力トークンにはそれぞれ別々の料率があり、いずれも100万トークンあたりで示されます。下の表は、Meridianがevalを実行した2026年8月時点で公開されていた3つのモデルの料率を示しており、Claudeの料金ページには現在適用されている料率が掲載されています。

モデル入力出力
Haiku 4.5$1$5
Sonnet 5$2$10
Opus 5$5$25

2026年8月時点で公開されていた、各モデルの100万入力トークンおよび100万出力トークンあたりの料率

1回の呼び出しのコストは、入力トークン数に入力料率を掛けたものに、出力トークン数に出力料率を掛けたものを加えたものです。 この例はSonnet 5の呼び出しなので、上の表のSonnet 5の料率を使用します。

text
780 input tokens  × $2 per million  = $0.0016
 41 output tokens × $10 per million = $0.0004
                              total = $0.0020

完了したタスクあたりのコストでモデルを比較する

1回の実行における全呼び出しのコストを合計したものを、実行コストと呼びます。実行コストをそのモデルが完了したタスクの数で割ると、完了したタスクあたりのコストが得られます。これがモデルを比較するための指標です。

呼び出し数ではなく、完了したタスク数で割ります。これは、タスクを誤った場合も含め、すべての呼び出しに課金が発生するためです。つまり、あるモデルの誤答は、そのモデルが実際に完了した各タスクのコストに上乗せされます。

モデル完了数実行コスト完了タスクあたりのコスト
Haiku 4.550件中42件$0.0380$0.0009
Sonnet 550件中50件$0.0984$0.0020
Opus 550件中50件$0.2323$0.0046

2026年8月時点の料率における、50件のケースの実行コストと完了タスクあたりのコスト

必要な精度を最低コストで満たすモデルを選ぶ

下限によってどのモデルが候補になるかが決まり、その中から完了タスクあたりのコストが最も低いものを選びます。 Sonnet 5とOpus 5はいずれも50件中50件正解しており、完了タスクあたりのコストはそれぞれ$0.0020と$0.0046なので、このタスクではMeridianはSonnet 5を選びます。Haiku 4.5の$0.0009は表の中で最も低い数字ですが、下限をクリアしていないため候補にはなりません。

より難しいタスクでは、最も能力の高いモデルだけが下限をクリアすることもあり、その場合はそれが正しい選択になります。各結果は、evalで使用したプロンプトとケースにも結びついています。プロンプトやケースを変更すれば、適切なモデルも変わる可能性があるため、どちらかを変更するたびにevalを再実行してください。

このevalはレイテンシを測定していません。ユーザーが回答を待つようなシステムであれば、ここでスコアを測定したのと同様に、自分自身のケースでレスポンスの時間を計測してください。

evalの実行コストを下げる

これら5つのステップによってモデルが決まりますが、eval自体のコストをさらに下げる方法がもう1つあります。evalの回答を待っている人は誰もいないため、リクエストを非同期で処理するBatch APIを通して送ることができます。Batch APIは、同じモデルを入力トークンと出力トークンの半額で実行します。

モデルを比較する際は、1つの比較の中でバッチ料率と標準料率を混在させないでください。すべてのモデルのコストをバッチ料率で計算するか、すべてのモデルのコストを標準料率で計算するかのどちらかにしてください。

まとめ

  1. 誤答が自分にどれだけのコストをもたらすかから、まず精度の下限を設定する。
  2. すべてのモデルに同じケースを与え、下限をクリアしないモデルは除外する。
  3. 各呼び出しのコストをusageブロックから取得し、実行コストをそのモデルが完了したタスクの数で割る。
  4. 下限をクリアした候補の中から、完了タスクあたりのコストが最も低いものを選ぶ。