タスクと予算に合ったモデルを選ぶ

役立つ考え方：まずタスクの特性、次にモデル

実際には、モデル名を見る前に、LLMのワークロードを次の五つの軸で分類しています。

「どのモデルが最も賢いか？」ではなく、「どのような失敗のリスクを、費用をかけて減らそうとしているのか？」と考えるようになると、モデル選びはずっと簡単になります。

たとえば、次のように考えます。

• パスワードリセットに関する要約システムには、一貫性と低コストが必要です。
• コード移行アシスタントには、推論とツールの使用が必要です。
• 契約書の差分比較ツールには、長いコンテキストだけでなく、慎重な出典の明示も必要です。
• 顧客対応エージェントには、ベンチマークでの最高性能よりも、レイテンシーの予測可能性が必要です。
• データを補完するバッチ処理パイプラインでは、応答の洗練度よりも、費用あたりのスループットが重視されることがあります。

不適切なモデルは、技術的に不適切とは限りません。経済的に不適切なのです。

実践的なモデルの段階構成

ほとんどの本番システムで、私は次の段階構成を使っています。

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"}
    ]
)

トレードオフとなるのは、エンジニアリング上の責任です。ホスト型の最先端モデルでは、容量、パッチ適用、量子化方式の選択、カーネルレベルの性能改善を他者が担います。オープンモデルでは、それが自分たちの仕事になります。

オープンウェイトモデルは、ワークロードが安定している場合に非常に適しています。一方、プロダクトが毎週変化し、モデル提供にかかる直接的なコストよりもプロンプトの品質が重要な場合には、適合度が下がります。

低コストモデルを優先し、必要に応じてエスカレーションするルーティング

優れたルーターはランキング表ではありません。リスクを制御するシステムです。

本番環境で使いやすいパターンを紹介します：

1. 対応できるはずのモデルのうち、最も安価なものを試す。
2. 出力を機械的に検証する。
3. 観測可能な基準だけに基づいて、適切に調整された自己チェックをモデルに求める。
4. 検証に失敗した場合、確信度が低い場合、またはリスクが高い場合にエスカレーションする。
5. 後で調整できるように、選択した経路と結果をログに記録する。

ルーターの例：

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とは、許容できる待ち時間でユーザーを正しい結果へ導くものです。

対話型システムでは、私はレイテンシの許容範囲を基準に考えます：

時間のかかる推論を、状況を伝えないままスピナーの背後に隠してはいけません。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のような長文コンテキストを使います。プロンプトに情報を大量に詰め込む標準的な戦略として使うべきではありません。
• ワークロードの安定性、プライバシー、スループット、デプロイの制御という観点から、推論を自ら運用する妥当性がある場合は、オープンウェイトモデルを使います。
• 不正な出力、根拠の弱さ、ツールの失敗、リスクの高い操作、不確実性といった明確なエスカレーション条件を設け、低コストのモデルから始めるルーティングを構築します。
• トークンあたりや呼び出しあたりのコストではなく、成功したタスクあたりのコストを測定します。
• 切迫した状況でもデバッグできる程度に、ルーターをシンプルに保ちます。
• モデル選択は、一度きりのベンダー選定ではなく、エンジニアリング上の制御手段として扱います。