一行要約
モデルを切り替えるより、effort を調整するほうが良いレバーであることが多い。 その上で、始め方は「効率優先（Haiku から上げる）」と「能力優先（Opus から下げる）」の2択。
要点
評価すべき4つの軸
- Capabilities — どの機能が必要か
- Speed — どれだけ速く応答する必要があるか。Opus 5 と Opus 4.8 は fast mode（research preview）に対応し、プレミアム価格で最大 2.5倍の出力速度
- Cost — 開発と本番の予算
- Effort — 最近の Opus / Sonnet は effort パラメータで1つのモデルの中で知能とレイテンシ・コストをトレードオフできる
Tuning effort is often a better lever than switching models. effort を調整するほうが、モデルを乗り換えるよりも効くレバーであることが多い。
2つの始め方
Option 1: 効率優先（efficiency-first）
- Claude Haiku 4.5 で実装を始める
- ユースケースを十分にテストする
- 性能が要件を満たすか評価する
- 能力ギャップがある場合にだけアップグレードする
向く: 初期のプロトタイピング、レイテンシ要件が厳しいアプリ、コスト重視、大量で単純なタスク。
Option 2: 能力優先（capability-first）
- Claude Opus 5 で実装する
- そのモデル向けにプロンプトを最適化する
- 性能を評価する
- effort を下げる、またはモデルを下げることで効率を上げる
向く: 複雑な推論、科学・数学、ニュアンスの理解、正確さがコストに優るアプリ、高度なコーディングと高自律の agentic 作業。
モデル選択マトリクス
| 必要なもの | 始めるモデル | 用途例 |
|---|---|---|
| 最高の能力 | Claude Fable 5 | 長時間走るエージェント、深い推論、long-horizon の agentic タスク、高度な研究 |
| 複雑な agentic コーディングとエンタープライズ業務 | Claude Opus 5 | 数時間の自律コーディング、大規模リファクタ、複雑なシステム設計、vision 重視のワークフロー、computer use |
| スケールする frontier 知能（コーディング / エージェント / 業務フロー向け） | Claude Sonnet 5 | コード生成、データ分析、コンテンツ作成、視覚理解、agentic なツール使用 |
| 最も経済的な価格での準 frontier 性能と高速さ | Claude Haiku 4.5 | リアルタイム、大量処理、コスト重視だが推論力が要る、subagent タスク |
主要モデルの位置づけ（2026-08-10 時点）
| モデル | context / 出力 | 価格（100万トークンあたり） |
|---|---|---|
| Claude Opus 5 | 1M（既定）/ 最大 128k 出力 | 入力 $5 / 出力 $25 |
| Claude Fable 5 / Mythos 5 | 1M（既定）/ 最大 128k 出力、adaptive thinking 常時オン | 入力 $10 / 出力 $50 |
Claude Opus 5 is a step-change improvement over Claude Opus 4.8, strong on deep reasoning, agentic and long-horizon tasks, and test-time compute scaling. Claude Opus 5 は Claude Opus 4.8 からの段階的な飛躍であり、深い推論、エージェント的で長期にわたるタスク、そして test-time compute のスケーリングに強い。
effort の既定: Opus 5 と Opus 4.8 は Claude Code と Messages API の両方で high が既定。Opus 5 は既定から始めて最も要求の厳しい作業で xhigh に上げる。Opus 4.8 はコーディング・高自律作業・最も知能を要するタスクで xhigh を使う。
切り替えるかの判断手順
- ユースケース固有のベンチマークテストを作る
having a good evaluation set is the most important step in the process 良い evaluation セットを持つことが、この過程で最も重要なステップである
- 実際のプロンプトとデータでテストする
- モデル間で比較する — 応答の正確さ / 応答の品質 / エッジケースの扱い
- 性能とコストのトレードオフを秤にかける
そのまま使える具体例
判断のフロー:
まず effort を調整してみる（モデル切り替えより良いレバーであることが多い）
↓ それでも足りない / 過剰
効率優先で始める場合:
Haiku 4.5 → テスト → 能力ギャップがあればアップグレード
向く: プロトタイプ、低レイテンシ、コスト重視、大量・単純
能力優先で始める場合:
Opus 5 → そのモデル向けにプロンプト最適化 → effort を下げる / モデルを下げる
向く: 複雑な推論、正確さ > コスト、高自律 agenticsubagent のモデル指定（単純な subagent は Haiku）:
---
name: explore
description: Fast, read-only agent for searching codebases
model: haiku
---原典で言及されている関連文書
- effort — モデル切り替えより先に試すレバー
- develop-tests — 「良い eval セットを持つことがこの過程で最も重要」の具体化
- prompting-claude-opus-5 — Opus 5 向けのプロンプト最適化
- sub-agents — subagent に安いモデルを割り当てる
- context-windows — 1M context のモデル一覧