生成AIモデルの料金を比較する際は、1トークン当たりの単価に注目しがちだ。しかしAnthropicは、個々のタスクを完了するためにかかる総費用である「Cost-per-task」（タスク当たりのコスト）を重視すべきだと説明する。

　高性能なモデルは、入力や出力に使う1トークン当たりの単価が高い。その一方で、ユーザーの意図を早い段階で理解し、少ないやりとりで正しい結果に到達できる可能性がある。何度もプロンプトを修正したり、出力結果を再生成したりする必要がなければ、タスク全体のトークン消費量や処理時間を抑えられる。

　例えば、安価なモデルであれば目的の回答を得るまでに5回のやりとりが必要になる場合がある。一方、高性能なモデルであれば1回で必要な品質を満たすことができるのであれば、後者の方がタスク当たりの総コストは低くなる可能性がある。AIエージェントの場合は、途中で誤った判断をすると、それに続くツール操作や再試行のコストも発生するため、この差はさらに大きくなり得る。

　小型モデルから検証を始めると、期待した結果が出なかった原因が、モデルの能力不足なのか、プロンプトやデータ、システム設計の不備なのかを切り分けにくいという問題もある。まず高性能なモデルで達成可能な品質を確認しておけば、その後にモデルを小型化した際、どの程度まで品質や速度が変化したのかを比較しやすい。

　ただし、全ての用途で高性能モデルを使い続ける必要があるわけではない。要求品質が明確になった後、応答速度や運用量、予算を考慮しながら下位モデルを試し、品質基準を満たす中で最も費用対効果の高いモデルを選ぶ。

Claudeモデルファミリーの特徴

　Anthropicは、Claudeのモデルを主に「Claude Mythos」（以下、Mythos）／「Claude Fable」（以下、Fable）、「Claude Opus」（以下、Opus）、「Claude Sonnet」（以下、Sonnet）、「Claude Haiku」（以下、Haiku）の5クラスに分けている。これらは特定の業種に特化したモデルではなく、処理できる問題の難易度、応答速度、料金などが異なる。

Mythos／Fable（最上位モデル）

　Claudeの中で最も高い能力を持つモデルクラスだ。複雑なコーディング、長時間にわたって動作するAIエージェント、従来のAIでは安定して処理できなかった問題など、難易度の高いタスクを想定している。

　MythosとFableは同じ基盤モデルであるが、想定するユーザーが異なる。Mythosは、サイバーセキュリティや生物学など、軍事・民生の両方に応用され得るデュアルユース領域を扱う認定組織向けだ。一方Fableは、一般のユーザーが安全に利用できるよう追加の安全対策を施したモデルである。両モデルは、安全性を確保するため、データ保持を限定することが利用条件となる。

　Fableは、高度なコーディングや長期実行型のAIエージェント、ナレッジワークに強みを持つ。標準的なベンチマークではOpusと同程度のスコアになる場合でも、実際の業務では創造性、文章表現の深さ、状況を踏まえた判断などで優位性が表れることがある。

Opus（高度な推論モデル）

　複雑な推論を必要とするエンタープライズ業務や、高度なナレッジワークを想定したモデルクラスだ。調査結果の分析や戦略立案、複数の条件を考慮する意思決定支援、複雑なコードの作成などに適する。

　では、FableとOpusの違いは何か。両者は対応する用途が重なるため、表面的には違いが分かりにくい。Anthropicが示す判断方法は、まずOpusを実際のタスクで評価し、要求する品質を安定して満たせるかどうかを確認する。Opusで十分な品質を得られるのであれば、Fableよりも速度や料金の面で有利になる可能性がある。一方、Opusでは安定して処理できないタスクが残る場合は、Fableを選択する。

Sonnet（万能モデル）

　性能、料金、応答速度のバランスを重視した汎用（はんよう）モデルだ。文書の作成や要約、情報抽出、一般的なコーディング、顧客対応など、幅広い業務に利用できる。

　複数のAIエージェントに作業を分担させるシステムを構築する場合は、情報収集や文書作成、結果の確認など、個々の作業を担当するAIモデルとしても適している。一定以上の推論能力を保ちながら、多数の処理を比較的高速かつ低コストで実行できるためだ。

Haiku（高速・最安モデル）

　Claudeの中で最も低コストかつ高速なモデルクラスだ。分類、定型的な情報抽出、単純な文章変換、入力内容の振り分けなど、大量かつ高頻度で発生する処理を想定している。

　1件当たりの処理が比較的単純で、回答の深さよりも応答時間や処理件数が重視される場合、Haikuが有力な選択肢になる。例えば、問い合わせ内容の分類や、文書から特定項目を抽出する処理などだ。

業種ではなく「タスクの難易度」で選ぶ

　Anthropicは、金融業務にはOpus、科学分野にはSonnetといったように、業種や専門分野だけでモデルを使い分ける方法を推奨していない。一方、モデルを選ぶ際の判断基準として、主に4つのポイントを挙げている。

ポイント1．タスクの難易度

　人間が処理しても時間がかかる作業、複数の工程や判断を伴う作業、これまで安定した解決方法がなかった問題には、上位のモデルが適している。

　例えば、受け取った文書を既定のカテゴリーに分類するだけであれば、小型モデルでも対応できる可能性がある。一方、大量の資料を読み込み、複数の条件を比較しながら経営判断の選択肢を提示するタスクでは、OpusやFableなどの高性能モデルが必要になる可能性が高い。

ポイント2．応答速度

　顧客向けのチャットサービスや、画面操作に連動してAIが回答するシステムなどでは、利用者を長時間待たせないことが重要になる。このような高頻度かつ顧客接点に近い用途では、性能と速度を両立しやすいSonnetが選択肢になる。

ポイント3．利用権限や提供条件の制約

　全ての組織やユーザーが、全てのモデルを利用できるとは限らない。例えばMythosは、社会インフラの維持を担う40以上の重要組織に提供を制限するプロジェクト「Project Glasswing」の下、限定した組織にのみ提供される。企業側が、部門や職務、扱うデータの機密度に応じて、利用可能なモデルを制限する場合もある。

ポイント4．コスト

　試験導入時に数十件を処理するだけであれば、高性能モデルの料金は大きな問題にならないこともある。しかし、本番環境で1日数万件の処理を実行する場合は、わずかなタスク単価の差が大きな運用費の差につながる。

　このため、モデルの料金表だけでなく、1件のタスクを完了するまでに必要な入力トークン、出力トークン、再試行回数、処理時間、エラー率などを含めて比較する必要がある。下位モデルでも要求品質を満たせるタスクは下位モデルに任せ、難しい処理だけ上位モデルに振り分ける設計も有効だ。

Effort Levelで品質とコストを調整する

　モデルクラスを選ぶだけでなく、一般提供されている中で最も高性能なモデルから試し、推論に費やす計算量を調整する「Effort Level」（労力レベル）を調整することも重要だ。Effort Levelを高くすれば、モデルがより多くの計算や推論を使って回答を作成するため、複雑な問題への対応力が高まる。ただし、処理時間や料金も増える。

　逆にEffort Levelを低く設定すれば、速度とコストを抑えられる。単純な処理や、厳密な推論を必要としない作業では、上位モデルを低いEffort Levelで利用した方が、小型モデルを高い設定で利用するより効率的な場合がある。

　そのため、モデルの大小だけで性能と料金を比較するのではなく、「モデルクラスとEffort Levelの組み合わせ」で評価することが重要だ。高性能モデルを低いEffort Levelで使う構成、汎用モデルを高いEffort Levelで使う構成などを比較し、実際のタスク単価と品質を確認する。

コストと精度を両立する「アドバイザー戦略」

　全ての処理を高性能なモデルに任せるのではなく、複数のモデルを役割分担させる方法もある。Anthropicが紹介するのが「Advisor Strategy」（アドバイザー戦略）である。

　この方法では、高速で低コストな「worker models」（ワーカーモデル）が主な作業を担う。ワーカーモデルは、計画の作成、コードの生成、情報の整理などを実行する。その上で、判断が難しい場面や、成果物を検証する必要がある場面だけ、より高性能なモデルをアドバイザーとして呼び出すといった具合だ。

　アドバイザーとなったモデル（以下、アドバイザーモデル）は、作業を最初から全て代行するのではなく、ワーカーモデルが作成した計画を確認したり、間違いを指摘したり、改善方法を助言したりする。人間の組織で、担当者が日常的な作業を進め、必要な場面で専門家や上司のレビューを受ける構造に近い。

　Anthropicは、ソフトウェア開発の能力を評価する「SWE-bench Pro」（注1）で、Sonnet 5をワーカーモデル、Fable 5をアドバイザーモデルとして組み合わせた結果について言及している。それによると、全工程をFable 5に任せる場合の63％の料金で、Fable 5単体と比べて10％以内のスコアを記録したという。

※注1：SWE-benchは、ソースコード管理ツールGitHubに存在するIssue（課題）から作られたデータセットを基にしたベンチマーク。SWE-bench Proは、SWE-benchの高難度版ベンチマークだ。

　この構成であれば、定型的な処理はSonnetに任せ、難しい判断や品質確認に限ってFableを利用するという選び方が可能だ。大量のAIエージェントを運用する企業にとって、処理品質を大きく落とさずに運用コストを削減する選択肢となる。

　ただし、アドバイザーモデルを呼び出す条件が曖昧であれば、必要な場面でレビューが実行されなかったり、反対に全ての処理で上位モデルを呼び出してコストが膨らんだりする。信頼度が一定値を下回った場合、作業が規定回数以上失敗した場合、重要なデータを更新する場合など、呼び出し条件を事前に定める必要がある。

標準ベンチマークだけでは差が分からない

　モデルの能力を比較する代表的な方法には、公開されている標準ベンチマークと、企業が独自に作成するカスタム評価がある。

　標準ベンチマークは、あらかじめ正解や評価基準が定められた問題をモデルに解かせ、スコアを比較する方法である。異なるモデルやサービスの性能を大まかに把握する際には役立つ。

　ただし、OpusやFableのような高性能モデルでは、既存の問題の大半に正解できるため、モデル間の差は表れにくくなる。Anthropicはこれを「Saturation」（飽和）と呼ぶ。複数のモデルがいずれも高得点を記録すれば、公開スコアだけを見ても、自社の用途にどのモデルが適しているかを判断できない。

　ベンチマーク上のスコアが近くても、実際の業務では、文章の分かりやすさ、指示への忠実度、例外処理、創造性、長時間の処理における一貫性などに差が生じる可能性がある。

自社の業務を使ったカスタム評価を作る

　Anthropicは、標準ベンチマークだけでなく、自社の実際の業務から作成した「Custom Evals」（カスタム評価）を用いてモデルを検証することを推奨している。

　カスタム評価には、日常的に発生する代表的なタスクだけでなく、現在のツールが失敗しやすい問題、処理に時間がかかっている問題、誤ると業務への影響が大きい問題を含める。例えば、契約書から重要な条件を抽出する業務であれば、一般的な契約書だけでなく、記載方法が例外的な文書や、複数の条件が矛盾している文書も評価対象にする。

　評価基準も、自社の目的に合わせて定める必要がある。単に正解か不正解かだけでなく、必要な項目を漏れなく抽出できたか、根拠を示したか、指定した形式を守ったか、処理時間や費用が基準内に収まったかなどを確認する。

　AIエージェントを評価する場合は、最終的な回答だけでなく、途中で利用したツール、実行回数、誤操作の有無、処理を完了するまでの時間なども評価対象になる。正しい答えを出していても、不要なツール呼び出しを繰り返していれば、本番環境ではコストや安全性の問題につながるからである。

　カスタム評価は、モデルを最初に選ぶときだけでなく、モデルの更新後やプロンプトの変更後にも継続的に実施する。モデルのバージョンアップによって特定のタスクの性能が向上する一方、別のタスクでは出力傾向が変化することもあるためだ。

最上位モデルで基準を作り、段階的に最適化する

　AIモデルの選定に、全ての企業や用途に共通する正解はない。適切なモデルは、タスクの難易度、要求する応答速度、利用可能なモデル、処理件数、1件当たりの価値などによって変わる。

　まず高性能なモデルを使って、対象業務でどの程度の品質を実現できるかを確認する。次に、Effort Levelを調整し、品質を維持できる範囲で処理時間とコストを下げる。その後、SonnetやHaikuなどの下位モデルでも要求品質を満たせるタスクを特定し、段階的に置き換える。

　さらに、単純な処理を低コストなモデルに任せ、重要な判断だけ高性能モデルに確認させるアドバイザー戦略を取り入れることで、品質と費用の両立を図れる。

　重要なのは、トークン単価や公開ベンチマークの順位だけでモデルを決めないことである。実際の業務を使った評価を構築し、タスク単位の品質、速度、コストを継続的に測定する。それが、自社に適したClaudeモデルを選ぶための基本的なアプローチとなる。