claude code の model x effort 使い分け
effort 使い分け
まずは effort の使い分け。
effort パラメータは、タスクに応じた「推論の深さ（思考トークン量）」を制御する。上位3レベルの具体的な違いは以下の通り。
| Effortレベル | 推論の深さ・特徴 | 主な用途・適したタスク | コスト・実行時間 | 備考・注意点 |
|---|---|---|---|---|
| high |
標準的な推論 既存コードとの整合性を適度に考慮し、効率よく解答を生成。 |
通常のコーディング バグ修正 小・中規模な機能追加 |
標準的 | 日常的な開発作業の多くはこれで十分対応可能。レスポンス速度と品質のバランスに優れる。 |
| xhigh |
深めの推論high と max の中間に位置し、自律的なコーディング向けに調整。 |
設計判断を含む実装 複雑なリファクタリング 複数ファイルの影響分析 |
high より高コスト長めの処理時間 |
コーディング作業における推奨の起点。 エラーハンドリングなど細部まで踏み込んだ設計を提案する。 |
| max |
最大推論（一点集中） 思考トークンを上限まで使い、様々なアプローチを徹底的に比較・検討。 |
アーキテクチャの抜本的見直し 原因不明な複雑なバグ調査 最難関のタスク |
最大コスト 非常に長い処理時間 |
深読みしすぎて過剰設計（オーバーエンジニアリング）になるリスクがある。 セッション限定の設定であり、設定ファイル等への保存は不可。 |
model x effort
model x effort の使い分け。日常開発の8〜9割は高速・低コストなSonnetでカバーし、アーキテクチャ設計や難解なバグ調査のみOpusに切り替えるのが最適な運用。
| モデル + Effort | 役割と用途 | メリットと具体的な活用例 |
|---|---|---|
| Sonnet + high |
日常の高速なアシスタント 定型的なコード生成、Lint修正、単純なテスト追加、単一リソースの追加 |
圧倒的なスピードと低コスト。 AWS CLIコマンドの生成や、既存のGoコードへのシンプルな関数追加などに最適。 |
| Sonnet + xhigh |
自律コーディングの主軸 複数ファイルにまたがる機能実装、中規模のロジック変更、周辺コードを考慮した改修 |
速度と推論のベストバランス。 Goでの既存APIエンドポイント拡張や、既存のTerraformモジュールを踏まえた構成変更などを任せる。 |
| Opus + xhigh |
設計・アーキテクチャ顧問 ゼロベースでの設計、複雑なリファクタリング、コンポーネント間の依存関係の整理 |
高度な推論力による品質の担保。 Dockerと連動するMCPサーバーの新規設計や、Aurora PostgreSQLのメジャーアップデート手順の策定など。 |
| Opus + max |
最後の切り札（スポット利用） 原因不明のクリティカルなバグ調査、どうしても解決できないアーキテクチャ上の壁 |
あらゆるアプローチを徹底網羅。 どうしても特定できないインフラの障害調査など、他の組み合わせで手詰まりになった場合のみに限定。 |
Claude プラン選び
「毎日何回使うか」よりも「コードベースをどれだけ深く広く探索させるか」を基準にするのが、最も無駄のない選択になる。
-
Proプランで十分なケース
- 単一ファイル内のPHPからGoへのリファクタリング、特定のAWS CLIコマンドの生成、エラーログの単発調査など。使用頻度が高くても、1回あたりの探索範囲が狭ければProの枠内で綺麗に収まる。
-
Maxプランが必要なケース
- リポジトリ全体を横断するようなアーキテクチャの変更や、未知の複雑なバグ調査など。