ai-docs

Choosing the right model

Properties1
tagsmodels, costs, effort, evals

原典: Choosing the right model ／ 日本語版

一行要約

モデルを切り替えるより、effort を調整するほうが良いレバーであることが多い。 その上で、始め方は「効率優先（Haiku 4.5 から上げる）」と「能力優先（Opus 5.5 から下げる）」の2択で、たいていの作業は Opus 5.5 から始める。Opus 5.5 を xhigh / max にしても足りなければ Fable 5.1 に上げる。

要点

評価すべき4つの軸

  • Capabilities — どの機能が必要か
  • Speed — どれだけ速く応答する必要があるか。Opus 5.5 / Opus 5 / Opus 4.8 は fast mode（research preview）に対応し、プレミアム価格で最大 2.5倍の出力速度
  • Cost — 開発と本番の予算
  • Effort — いくつかのモデルは effort パラメータで1つのモデルの中で知能とレイテンシ・コストをトレードオフできる

Tuning effort is often a better lever than switching models.

effort を調整するほうが、モデルを乗り換えるよりも効くレバーであることが多い。

effort の起点はモデルで違う: Fable 5.1 と Opus 5 は既定の high から始め、eval を見て上下させる。Opus 5.5 の既定は medium で、そこから同じように調整する。Opus 4.8 と Opus 4.7 では、high と max の間の xhigh がたいていのコーディングと agentic 用途で最良の設定。

2つの始め方

Option 1: 効率優先（efficiency-first）

  1. Claude Haiku 4.5 で実装を始める
  2. ユースケースを十分にテストする
  3. 性能が要件を満たすか評価する
  4. 能力ギャップがある場合にだけアップグレードする

向く: 初期のプロトタイピング、レイテンシ要件が厳しいアプリ、コスト重視、大量で単純なタスク。

Option 2: 能力優先（capability-first）

  1. Claude Opus 5.5 で実装する
  2. そのモデル向けにプロンプトを最適化する
  3. 性能を評価する
  4. effort を下げる、またはモデルを下げることで効率を上げる
  5. xhigh や max の effort でも、要求の厳しい推論や long-horizon の agentic 作業で eval が足りなければ、Claude Fable 5.1 に移る

向く: 複雑な推論、科学・数学、ニュアンスの理解、正確さがコストに優るアプリ、高度なコーディングと高自律の agentic 作業。

乗り換える前に確かめること: Opus 5.5 は adaptive thinking が常時オン。強制ツール使用（tool_choice の any / tool）、thinking を切る設定、旧 computer_20251124 の computer use を使っている統合は、切り替える前に Opus 5.5 の破壊的変更を読む（thinking / computer-use-tool）。

モデル選択マトリクス

Most workloads start with Claude Opus 5.5.

たいていのワークロードは Claude Opus 5.5 から始まる。

必要なもの始めるモデル用途例
手に入る最高の能力Claude Fable 5.1何時間も走るエージェントのセッション、多段の深い調査、完成した文書・スプレッドシート・スライドまで持っていく分析
複雑な agentic コーディングとエンタープライズ業務Claude Opus 5.5数時間の自律コーディング、大規模リファクタ、複雑なシステム設計、vision 重視のワークフロー、computer use
日常のコーディング・エージェント・業務での速さと能力Claude Sonnet 5.5コード生成、データ分析、コンテンツ作成、視覚理解、agentic なツール使用
最も低いレイテンシと価格（extended thinking つき）Claude Haiku 4.5リアルタイム、大量処理、コスト重視だが推論力が要る、subagent タスク

Fable 5.1 はすべての顧客に開かれた中で最も能力の高いモデルで、Fable 5 を long-running の agentic コーディング・知識労働・調査で強めたもの（入出力の価格は同じで、キャッシュ読み取りは4分の1）。同じ能力の Mythos 5.1 は Project Glasswing の参加者だけが使える。context window・出力上限・価格は、原典ではモデル比較表に移った。

切り替えるかの判断手順

  1. ユースケース固有のベンチマークテストを作る

    having a good evaluation set is the most important step in the process

    良い evaluation セットを持つことが、この過程で最も重要なステップである

  2. 実際のプロンプトとデータでテストする
  3. モデル間で比較する — 応答の正確さ / 応答の品質 / エッジケースの扱い
  4. 性能とコストのトレードオフを秤にかける

モデルを組み合わせる

複数モデルの構成は、安いモデルと frontier のモデルを組にして、トークンの大半を安い単価で払う。よくある形は2つ —— 難しい判断だけを advisor に上げる executor と、大量の作業を安い worker に配る orchestrator。

そのまま使える具体例

判断のフロー:

まず effort を調整してみる（モデル切り替えより良いレバーであることが多い）。それでも足りない / 過剰なら、どちらかの端から始める。

始め方進め方向くもの
効率優先Haiku 4.5 → テスト → 能力ギャップがあればアップグレードプロトタイプ、低レイテンシ、コスト重視、大量・単純
能力優先Opus 5.5 → そのモデル向けにプロンプト最適化 → effort を下げる / モデルを下げる。xhigh / max でも足りなければ Fable 5.1複雑な推論、正確さ > コスト、高自律 agentic

原典で言及されている関連文書

  • effort — モデル切り替えより先に試すレバー
  • develop-tests — 「良い eval セットを持つことがこの過程で最も重要」の具体化
  • thinking — Opus 5.5 で thinking を切れないこと、強制ツール使用の 400

バックリンク