Source: https://aiprimetech.io/ja/blog/choosing-the-right-model-cost/ 2026年21日（6月） · 6分 · API # タスクと予算に合ったモデルを選ぶ A 著者 [AI Prime Tech](https://aiprimetech.io/ja/) · AI支援による執筆 火曜日の午前9:17時、サポートチケットの要約システムは、ダッシュボード上では「正常」に見えました。成功率は99.4%、p95レイテンシーは3秒未満で、キューの滞留もありませんでした。しかし、請求額は別の状況を示していました。次のようなチケットを要約するために、Opusクラスの費用をかけていたのです。 ``` { "subject": "Can I reset my password?", "messages": 3, "language": "en", "attachments": 0 } ``` これは推論の問題ではありません。1Mのコンテキストの問題でもありません。言語の問題とすら、ほとんど呼べないものです。 解決策は「どこでも最も安いモデルを使う」ことではありませんでした。それでは、返金をめぐる紛争、複雑に入り組んだバグレポート、コンプライアンス上の配慮が必要なエスカレーションに直面した途端に破綻します。解決策はルーティングでした。低コストのモデルから始め、信頼度を測定し、タスクが実際に必要とする場合にだけ上位モデルへ切り替えるのです。 適切なモデルを選ぶには、「最高のAIモデル」を探すことよりも、地味でも信頼できる判断の仕組みを構築することが重要です。 - このタスクには何が必要か？ - モデルの誤りはどの程度まで許容できるか？ - どれだけのコンテキストが必要か？ - ユーザーはどの程度のレイテンシーまで許容できるか？ - 再試行やエスカレーションの経路はどうなっているか？ このように考えると、Haiku、Sonnet、Opus、Fable、GPT、Gemini、そしてオープンウェイトモデルには、それぞれ確かな役割があります。 ## 役立つ考え方：まずタスクの特性、次にモデル 実際には、モデル名を見る前に、LLMのワークロードを次の五つの軸で分類しています。 | タスクの特性 | 例 | 最初に選ぶモデル | 上位モデルに切り替える条件 | 単純な変換 | 書き換え、分類、短いテキストの要約 | Haikuクラスまたは小規模なオープンモデル | 出力形式が不正、または信頼度が低い場合 | 構造化抽出 | 請求書、チケット、ログの解析 | Haiku/Sonnet、または制約を設定したオープンモデル | フィールドが曖昧、または重要度の高いレコードの場合 | プロダクトでの推論 | エージェントの計画立案、デバッグ、複数ステップのサポート | Sonnet/GPT/Geminiクラス | ツールの失敗、矛盾、信頼度の低さがある場合 | 深い分析 | アーキテクチャレビュー、法的な観点を含むポリシー比較、複雑なコードの推論 | Opus/GPT-5.5/Gemini 3 | 失敗時の影響が大きい場合は、通常ここから始める | 膨大なコンテキストの統合 | リポジトリ全体、大規模な会話記録アーカイブ、長いドキュメント | Fable 5または長いコンテキストに対応したモデル | 検索後に、特定の箇所について精密な推論が必要な場合 | 大量処理・プライベート環境／オフライン環境 | モデレーションの事前フィルター、埋め込み関連の分類、社内バッチ処理 | オープンウェイトのLlama/Qwen/DeepSeek/MiniMax/Kimi | 例外的なケース、規制対象の判断 「どのモデルが最も賢いか？」ではなく、「どのような失敗のリスクを、費用をかけて減らそうとしているのか？」と考えるようになると、モデル選びはずっと簡単になります。 たとえば、次のように考えます。 - パスワードリセットに関する要約システムには、一貫性と低コストが必要です。 - コード移行アシスタントには、推論とツールの使用が必要です。 - 契約書の差分比較ツールには、長いコンテキストだけでなく、慎重な出典の明示も必要です。 - 顧客対応エージェントには、ベンチマークでの最高性能よりも、レイテンシーの予測可能性が必要です。 - データを補完するバッチ処理パイプラインでは、応答の洗練度よりも、費用あたりのスループットが重視されることがあります。 不適切なモデルは、技術的に不適切とは限りません。経済的に不適切なのです。 ## 実践的なモデルの段階構成 ほとんどの本番システムで、私は次の段階構成を使っています。 ### Haikuクラスのモデル：低コストで高速な言語処理の標準選択 Haikuクラスのモデルは、初期処理に優れています。回答が短く、入力が整っていて、出力形式が制約されているタスクに使用しています。 適した用途： - チケットへのタグ付け - 短い要約 - 感情分類 - メール件名の正規化 - FAQのマッチング - 単純なJSON抽出 - 低リスクのモデレーション用事前フィルター 低コストの一次分類器向けプロンプト例： ``` { "model": "claude-haiku-4.5", "temperature": 0, "max_tokens": 120, "response_format": { "type": "json" }, "messages": [ { "role": "system", "content": "Classify the support ticket. Return only valid JSON." }, { "role": "user", "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge." } ] } ``` 期待される出力： ``` { "category": "billing", "urgency": "medium", "needs_human": true, "reason": "Refund dispute involving payment status" } ``` よくある落とし穴は、低コストモデルに推論と完璧な形式での出力を一度で求めることです。モデルがときどき無効なJSONを出力しても、すぐにOpusへ切り替えないでください。まずタスクを絞り込みます： - 設定する項目： temperature: 0 - JSONスキーマまたはツール呼び出しを使う - 指示の範囲を絞る - 分類と説明を分ける - 出力を検証し、一度再試行する 本番環境の多くのタスクでは、Haikuクラスで一度再試行しても、最先端の推論モデルを標準で使うより低コストかつ高速です。 ## Sonnetクラスのモデル：実際のプロダクトロジックを支える主力 対話型のプロダクト機能では、私はたいていSonnetクラスのモデルを選びます。推論に十分な能力があり、ツール利用でも十分に安定し、ユーザー向けのフローでも通常は十分な速度を備えています。 適した用途： - カスタマーサポートの返信文の作成 - ツールを使うエージェント型ワークフロー - コードの説明と軽度のリファクタリング - 複数のステップを伴う文書の質疑応答 - 営業やカスタマーサクセス向けのコパイロットワークフロー - 整理されていない入力からの構造化データ抽出 実際には、Sonnetは「ルーティングについてあまり深く考えたくない」ときの最適な選択肢になることがよくあります。新機能に組み込めるモデルの階層が一つだけなら、ここから始めてください。 例：注文、ポリシー、過去のチケットを確認できるサポートエージェント。 ``` SYSTEM = """ You are a support resolution assistant. Use tools before making claims about orders, refunds, or account state. If policy is ambiguous, say what is ambiguous and escalate. Return: - summary - recommended_action - customer_reply - escalate: true/false """ request = { "model": "claude-sonnet-4.6", "temperature": 0.2, "max_tokens": 900, "tools": [ {"name": "get_order", "description": "Fetch order state"}, {"name": "get_refund_policy", "description": "Fetch current refund rules"}, {"name": "search_prior_tickets", "description": "Search customer history"} ], "messages": [ {"role": "system", "content": SYSTEM}, {"role": "user", "content": "Customer says they returned item A but were charged again."} ] } ``` この種のワークフローを本番環境で実行すると、実際には何が起きるのでしょうか。失敗の大半は「モデルの能力が低い」ことによるものではありません。統合上の問題によるものです。 - ツールが古い状態を返す。 - モデルに無関係なコンテキストを与えすぎる。 - ポリシー文書に矛盾した記述がある。 - ツール呼び出しに失敗しても、エージェントが処理を続けられる。 - プロンプトが内部分析と顧客向けの文章を、区別せずに両方求めている。 Sonnetクラスのモデルには、ある程度の混乱から立て直せるだけの知能がありますが、明確なツールの入出力仕様が不要になるわけではありません。 ## Opusクラスのモデル：高価でも、ミスより安く済む場合がある Opusクラスのモデルは、不適切な回答のコストが推論コストを上回るタスクに適しています。 私は次のような場合にOpusを選びます： - 入力が曖昧で、判断の影響が大きい - 相互に影響する制約が多い - ユーザーが深い推論を期待している - タスクにコード、ポリシー、アーキテクチャのトレードオフが関わる - 低コストモデルでの試行に失敗すると、人の時間を無駄にする 例： - データベース移行計画のレビュー - 本番環境のインシデントの時系列分析 - 人によるレビューのための、複雑な法務関連ポリシーの比較の作成 - 複数のサービスにまたがるエージェントの障害のデバッグ - 自動化された操作が安全かどうかの評価 私は「重要」なタスクすべてにOpusを使うわけではありません。重要性と難しさは別のものです。百万件のパスワードリセットのチケットはユーザーにとって重要ですが、一件ずつは難しくありません。一方、微妙な問題を含むデータ削除の移行は、一件だけでも重要かつ難しい場合があります。 有用なパターンは「不確実な場合にエスカレーションする」ことです： ``` def choose_model(task): if task["context_tokens"] > 700_000: return "fable-5" if task["risk"] == "high" and task["requires_reasoning"]: return "claude-opus-4.8" if task["requires_tools"] or task["multi_step"]: return "claude-sonnet-4.6" return "claude-haiku-4.5" ``` これは意図的にシンプルにしています。ルーターは、チームが午前2時でもデバッグできるほど単純であるべきです。 ## Fable 5と1Mのコンテキスト：検索が課題となる場合に使う 長いコンテキストを扱えるモデルは、検索に関する開発作業を大幅に減らせるため魅力的です。Fable 5の1Mのコンテキストウィンドウにより、文書全体のレビュー、膨大な会話記録の統合、大規模なリポジトリの調査、複数ファイルにまたがるポリシー分析など、直接試せることが変わります。 ただし、長いコンテキストは万能ではありません。 1Mトークンのウィンドウは、「関連する事実がどこにあるかわからない」ことが難しさの原因である場合に役立ちます。しかし、モデルが百万トークン全体にわたって完璧に推論できることを保証するものではなく、無関係なコンテキストが無料になるわけでもありません。長いプロンプトには依然として費用がかかり、レイテンシが増え、注意が分散する可能性があります。 私は次のような場合にFableのような長いコンテキストを使います： - コーパス内の情報が密接に関連しており、単純な分割では対応できない - 詳細を一つ見落とす損失が、追加のコンテキストの費用より大きい - ユーザーが応答の遅さを許容できる - 周辺の生の資料を確認することがタスクに役立つ 大規模な文書レビュー向けのアーキテクチャ例： ``` User request -> lightweight classifier -> retrieve obvious relevant sections -> if confidence high: Sonnet answer with citations/quotes from chunks -> if confidence low or query is global: Fable 5 over full document set -> optional Opus review for high-risk final answer ``` このハイブリッド方式は、「常にすべてをコンテキストに詰め込む」方法よりも有効です。実際には、長いコンテキストを扱えるモデルは、検索結果の信頼性が低い場合の代替手段として最も価値があります。 ## オープンウェイトモデル：制御、コスト、スループット Llama、Qwen、DeepSeek、MiniMax、Kimiなどのオープンウェイトモデルは、単なる「安価な代替品」ではありません。運用面での選択肢です。 次のものが必要な場合に適しています： - ローカル環境またはVPCへのデプロイ - 予測可能な大量バッチ処理のコスト - ファインチューニングまたは蒸留 - 独自の推論最適化 - データの保存地域の制御 - 初期構築後の極めて低い限界費用 特に、範囲が限定された反復タスクに適しています。たとえば、vLLMで提供するQwenやLlamaの派生モデルは、プロンプトの長さと出力形式を制御すれば、分類、抽出、内部データの拡充を高いスループットで処理できます。 ローカルでモデルを提供する構成例： ``` vllm serve Qwen/Qwen3-14B \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 ``` 続いて、OpenAI互換のクライアントから呼び出します： ``` from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="local" ) result = client.chat.completions.create( model="Qwen/Qwen3-14B", temperature=0, messages=[ {"role": "system", "content": "Return valid JSON only."}, {"role": "user", "content": "Classify: user cannot access invoice PDF"} ] ) ``` トレードオフとなるのは、エンジニアリング上の責任です。ホスト型の最先端モデルでは、容量、パッチ適用、量子化方式の選択、カーネルレベルの性能改善を他者が担います。オープンモデルでは、それが自分たちの仕事になります。 オープンウェイトモデルは、ワークロードが安定している場合に非常に適しています。一方、プロダクトが毎週変化し、モデル提供にかかる直接的なコストよりもプロンプトの品質が重要な場合には、適合度が下がります。 ## 低コストモデルを優先し、必要に応じてエスカレーションするルーティング 優れたルーターはランキング表ではありません。リスクを制御するシステムです。 本番環境で使いやすいパターンを紹介します： - 対応できるはずのモデルのうち、最も安価なものを試す。 - 出力を機械的に検証する。 - 観測可能な基準だけに基づいて、適切に調整された自己チェックをモデルに求める。 - 検証に失敗した場合、確信度が低い場合、またはリスクが高い場合にエスカレーションする。 - 後で調整できるように、選択した経路と結果をログに記録する。 ルーターの例： ``` def run_with_escalation(task, input_text): first_model = pick_first_model(task) response = call_model( model=first_model, input=input_text, schema=task["schema"], temperature=0 ) validation = validate(response, task["schema"]) if not validation.ok: return call_model( model="claude-sonnet-4.6", input=input_text, schema=task["schema"], temperature=0 ) if task["risk"] == "high" and response.get("needs_review"): return call_model( model="claude-opus-4.8", input=input_text, schema=task["schema"], temperature=0 ) return response ``` 重要なのは、エスカレーションを感覚ではなく、測定可能なシグナルに基づいて行うことです。 有用なエスカレーションのシグナル： - 無効なJSON - 必須フィールドの欠落 - 矛盾した回答 - ツール呼び出しの失敗 - 検索で得られた根拠が弱い - ユーザーが取り消せない操作を求めている - 入力が通常の長さを超えている - モデルが不確実性を明示している - 分類器が法律、医療、セキュリティ、金融に関する内容を検出する 数値スコアとして「モデルの確信度」だけを使うことは避けてください。LLMの確信度は、較正された確率ではありません。ただし、具体的なチェックに限定すれば依然として役立ちます。「どの程度自信がありますか？」よりも、「入力には回答に必要な情報が十分に含まれていましたか？」のほうが適切です。 ## レイテンシ、価格、ユーザー体験 最速のモデルが常に最良のUXを提供するとは限りません。最良のUXとは、許容できる待ち時間でユーザーを正しい結果へ導くものです。 対話型システムでは、私はレイテンシの許容範囲を基準に考えます： | 体験 | 許容時間の目安 | モデル戦略 | オートコンプリートまたはインライン支援 | 体感で100～500ミリ秒 | 小規模モデル／オープンモデル、ストリーミング、積極的なキャッシュ活用 | チャットの応答 | 1～5秒 | ストリーミング対応のHaiku/Sonnetクラス | エージェントによるツールワークフロー | 5～20秒 | Sonnetクラス、ツールの並列実行、進捗通知 | 深い分析 | 30～180秒 | Opus/Fable/GPT/Geminiクラス、非同期ジョブ | バッチ処理 | 数分から数時間 | オープンウェイトモデル、またはホスト型の最安料金プラン 時間のかかる推論を、状況を伝えないままスピナーの背後に隠してはいけません。OpusやFableのジョブに90秒かかるなら、分析タスクであることを明示してください。 ``` Analyzing 184 files... ✓ Indexed repository structure ✓ Found 12 migration scripts ✓ Checking rollback safety ``` システムが目に見える形で作業しているため、ユーザーの受け止め方が変わります。 また、可能な限りストリーミングを使ってください。ストリーミングは完了までの総時間を短縮しませんが、チャットや文章の下書きのワークフローでは、体感待ち時間を大幅に改善します。 ## タスク別の具体的な選択 現時点で私ならどう選ぶか、具体例を紹介します。 ### サポートチケットのトリアージ まずHaikuを使います。 - 入力：短いチケット本文 - 出力：カテゴリ、緊急度、振り分け先のキュー - 請求に関する異議、怒っている顧客への対応、ポリシーが曖昧な場合はSonnetに引き継ぎます - しきい値を超える返金は人間が確認します これは、低コストのモデルから始める典型的なワークフローです。 ### 顧客対応サポートエージェント Sonnetを使います。 - ツールの使用が必要 - 口調の調整が必要 - ポリシーへの対応が必要 - 適切で円滑なエスカレーションが必要 Haikuは前処理にのみ使います。リスクの高い案件では、監督役による確認にOpusを使います。 ### コードレビューアシスタント 通常のPRレビューにはSonnetを使います。アーキテクチャに関わる変更、並行処理、セキュリティ、データ移行、微妙な正しさの検証にはOpusを使います。 よくある間違いは、最初からリポジトリ全体を入力することです。まず差分、依存関係グラフ、関連する周辺ファイルから始めてください。変更が多くの領域にまたがる場合にのみ、Fableや別の長文コンテキストモデルに切り替えます。 ### 長い契約書やポリシーの比較 対象が限定された質問には、検索とSonnetを組み合わせて使います。「これらの文書全体にある矛盾をすべて見つける」のように、全体を対象とする質問にはFable 5を使います。 出力が実際の法的判断やコンプライアンス上の判断に影響する場合、モデルは分析の準備に使い、判断そのものは任せないでください。 ### 大量データのエンリッチメント 処理量が多く、タスクが安定している場合は、オープンウェイトモデルを使います。 例： - 企業名の正規化 - 業種タグの抽出 - インバウンドリードの分類 - 社内向けの短い要約の生成 毎晩バッチを実行し、サンプルを検証して、例外的なケースはホスト型モデルに引き継ぎます。 ### 大規模アーカイブを対象とする調査アシスタント 必要なコンテキスト長と推論能力に応じて、Gemini 3、GPT-5.5、Opus、Fableを使います。クエリが明らかに単純でない限り、私なら低コストのモデルから始めません。調査の失敗は表面化しないことが多く、モデルが重要な文書を見落としたまま、もっともらしい回答を出してしまいます。 ## 自分をごまかさない予算管理 予算を超過する最も簡単な方法は、再試行、人間による修正、ワークフローの失敗を無視して、呼び出し単位のコストを最適化することです。 タスクの種類とモデルごとに、次の指標を追跡してください。 - 入力トークン - 出力トークン数 - レイテンシのp50/p95 - 検証失敗率 - エスカレーション率 - 人間による判断の上書き率 - ユーザーによる再試行率 - 呼び出しあたりのコストではなく、成功したタスクあたりのコスト 最後の指標は重要です。再試行を三回必要とし、それでも手動レビューが発生する安価なモデルは、Sonnetより高くつくことがあります。不適切な移行を防ぐOpusの呼び出しが、その週で最もコストを抑える判断になることもあります。 Claude、GPT、Geminiの各ファミリーへのAPIアクセスを提供するAI Prime Techのようなマルチモデルゲートウェイを使う場合、主な利点はベンダーを選べることだけではありません。モデルのクラスをまたいだルーティングと測定を容易にできる点にあります。ただし、難しいのは依然としてタスクの設計です。 ## 実践上のポイント - まずタスクの性質を見極めます。変換、抽出、推論、長文コンテキストの統合、バッチでのエンリッチメントのどれに当たるかを考えてください。 - 機械的に検証でき、制約が明確な作業を低コストかつ高速に処理するには、Haikuクラスのモデルを使います。 - 推論、ツール、ユーザー向けの品質が必要な製品機能では、Sonnetクラスのモデルを標準として使います。 - 間違いの代償が大きい場合、曖昧さが大きい場合、深い推論が重要な場合は、Opusクラスのモデルを使います。 - 検索の不確実性が主な問題である場合は、Fable 5のような長文コンテキストを使います。プロンプトに情報を大量に詰め込む標準的な戦略として使うべきではありません。 - ワークロードの安定性、プライバシー、スループット、デプロイの制御という観点から、推論を自ら運用する妥当性がある場合は、オープンウェイトモデルを使います。 - 不正な出力、根拠の弱さ、ツールの失敗、リスクの高い操作、不確実性といった明確なエスカレーション条件を設け、低コストのモデルから始めるルーティングを構築します。 - トークンあたりや呼び出しあたりのコストではなく、成功したタスクあたりのコストを測定します。 - 切迫した状況でもデバッグできる程度に、ルーターをシンプルに保ちます。 - モデル選択は、一度きりのベンダー選定ではなく、エンジニアリング上の制御手段として扱います。 [モデル](/ja/blog/tag/models/)[API](/ja/blog/tag/api/) A [AI Prime Tech](https://aiprimetech.io/ja/) このブログはAI Prime Techが公開しています。記事の草稿はAIの支援を受けて作成されています。モデルID、料金、制限など、バージョンによって異なる詳細については、利用の判断に用いる前に公式ドキュメントで確認してください。 Claude APIをより低価格で利用 Claude Opus 5.5、Sonnet 5、Haiku 4.5、Fable 5.1に加え、GPT-6のモデルを、単一のAPIキーで利用できます。従量課金制で、サブスクリプションは不要です。 [APIキーを取得 →](/register) AI Prime Techは独立したサードパーティのAPIゲートウェイです。Claude™およびAnthropic®はAnthropic, PBCの商標です。提携や推奨を示唆するものではありません。