Claude Code の model と effort、結局どう使い分ける？タスクタイプ別の判断軸

「迷ったら Opus にしておく」「念のため effort は max」。そう決めて毎回同じ設定で動かしている人は多い。私もしばらくそうだった。だがある日、月の請求を見て気づいた。コストが想定より膨らんでいたのは、モデル選択そのものではなく 「タスクに対して model と effort のレベルが過剰だった」 場面が続いていたからだった。

Claude Code には現在 8 種類のモデル alias と 5+1 段階の effort、それに /fast と subagent・skill 単位の上書きまである。組み合わせは数十通り。「全部 max」も「Opus 常用」も、最適解からは離れている。本稿は、過去に書いた effort 解説記事の続編として、モデルと effort をどう組み合わせて選ぶか の判断軸を整理する。

まずは「何が選べるか」を頭に入れる

判断する前に、選択肢の全体像を確認しておく。公式の model-config ドキュメントから、モデル alias の整理:

default がプランやプロバイダで何に解決されるかは、知っておくと事故を防げる。Anthropic API や Max では Opus 4.8、Claude Platform on AWS では Opus 4.7、Pro では Sonnet 4.6、Bedrock / Vertex / Foundry では Sonnet 4.5。Bedrock 経由で default のまま動かすと、知らないうちに 2 世代古いモデルで運用されることになる。

effort は別の軸だ。Opus 4.8 と Opus 4.7 が low / medium / high / xhigh / max の 5 段階、Opus 4.6 と Sonnet 4.6 は low / medium / high / max の 4 段階。デフォルトは Opus 4.8 / Opus 4.6 / Sonnet 4.6 が high、Opus 4.7 が xhigh。さらに、ultracode を選ぶと xhigh 相当を送りつつ dynamic workflows が自動起動する。これは 5/29 の ultracode 記事 で詳しく扱った。

公式ドキュメントは効果について重要な注記をしている。「effort スケールはモデルごとに較正されているため、同じ level 名でもモデル間で値の意味は同じではない」。Sonnet 4.6 の high と Opus 4.8 の high は別の値だ。「Opus で高 effort なら安心」という大雑把な感覚は、実はモデル間では成り立たない。

sonnet + high が日常の基本である理由

ほとんどのコーディングタスクの最適解は sonnet + high だ。公式コストドキュメントにはこう書いてある。「Sonnet はほとんどのコーディングタスクを十分にこなせて、Opus より安い。複雑なアーキテクチャ判断や多段の推論にだけ Opus を予約せよ」。

私の運用も同じだ。1日のセッションの 8 割が sonnet + high で済む。残りの 1〜2 割で opus に切り替える場面は、大規模リファクタの設計判断、原因が見えないバグの仮説出し、新規機能の API 設計などだ。max を使うのは月に数回。max は overthinking のリスクを公式が認めており、すべて max にすれば質が上がるとは限らない。

Haiku の使いどころは subagent。テスト実行・ログ要約・grep ヘルパーなど機械的なタスクを subagent に切り出し、その frontmatter で model: haiku と固定する。これで「気づかないうちに subagent が Opus を消費している」事故を防げる。

subagent と skill で model × effort を「静的に固定」する

メインセッションの /model と /effort は実行時の切替だが、subagent と skill の frontmatter は 静的な固定 ができる。これがチーム運用の本命になる。

例えば、設計レビュー専門の subagent を Opus + max effort に固定する場合:

---
name: architecture-reviewer
description: Reviews architecture decisions and suggests alternatives
model: opus
effort: max
tools: [Read, Grep, Glob]
---

あなたはアーキテクチャレビュー専門の subagent です。
設計の選択肢を複数提示し、トレードオフを明示してください。

ログフィルタや簡易集計の subagent は Haiku に固定する:

---
name: log-filter
description: Filters log output for errors and summarizes findings
model: haiku
effort: low
tools: [Bash, Read]
---

ログを受け取り、ERROR と WARN のみ抽出して短く要約してください。

これで、メインセッションが Opus で動いていても、log-filter が呼ばれた瞬間に Haiku に切り替わる。subagent 内のモデル解決は公式仕様では「環境変数 CLAUDE_CODE_SUBAGENT_MODEL → 起動時パラメータ → frontmatter → メインセッション」の順で評価される。frontmatter で固定しておけば、メインセッション側の設定変更に左右されない。

skill も同様に frontmatter で model と effort を上書きできる。違いは「skill の上書きはそのターンだけ有効」で、次プロンプトでは session 設定に戻る点。「重い skill だけ Opus に上げたい」場面で使える。

fast mode は別軸——Anthropic API 限定、Opus 限定

/fast を効率化と勘違いしている人を時々見るが、公式の定義は明確だ。「Fast mode は Claude Opus 用の高速設定で、モデルを最大 2.5 倍速くする代わりに、トークン単価が高い」。

価格は無視できない差がある:

Opus 4.7 と 4.6 の fast mode は標準価格の数倍だ。fast mode には見落としやすい制約がある。

まず Opus 限定で、Sonnet や Haiku では使えない。Anthropic API とサブスク限定でもあり、Bedrock / Vertex / Foundry / Claude Platform on AWS では利用不可だ。サブスクリプション契約では usage credits 経由のみで、plan の rate limit には含まれない。

特に見落としやすいのが「mid-conversation で /fast を切ったときのコスト」。公式の説明によると、会話の途中で fast に切り替えると、それまでの会話全体の uncached input が fast 価格で再計算される。「終盤だけ速くしたい」つもりで切ると、長く溜めた context 全体に fast 価格が適用される。fast を使うなら セッション開始時から ON にする のが正解だ。

Team や Enterprise では admin が enable しないと使えない。組織で運用するなら、まず admin 設定を確認する。

タスクタイプ別の推奨組み合わせ

タスク種別ごとの推奨組み合わせを表にまとめた。あくまで出発点なので、タスクの複雑度・チームのコスト制約・対象コードベースのサイズに応じて調整してほしい。

opusplan は plan モードの間だけ opus、実行に入った瞬間 sonnet に自動で落ちる仕組みで、設計と実装のコスト最適化が一度に効く。ただし opusplan には 1M context の自動アップグレードは適用されない点には注意してほしい。

コスト削減で先に手をつけるべき順序

公式コストドキュメントが挙げる施策を効果の大きい順に見ていくと、まず効くのはモデル切替だ。Sonnet 中心にして Opus は意思決定だけ、Haiku は subagent に回すだけで、1日のコスト差が最大数倍になる。

次いでコンテキストの能動的管理。/clear・/compact・CLAUDE.md の軽量化をセットで意識する。subagent への verbose op 委譲（テスト実行・ログ解析を subagent 隔離）も早めに着手したい。

effort を下げるのはその後で十分だ。low / medium を routine 作業に割り当てる。残りは MCP server 削減（未使用 server 無効化）、preprocessing hooks（10,000 行のログを grep で数百行に絞る）、プロンプトの具体化（曖昧な指示は広域スキャンを誘発してコストが膨らむ）の順で手をつける。

公式が示す目安では、エンタープライズ平均が $13/dev/day、月 $150〜250/dev、90% のユーザーは $30/day 以下に収まる。これを大きく超えるなら、まずモデル切替と effort 下げから手をつけると効果が出やすい。

Bedrock や Vertex 経由の場合は、Claude Code がメトリクスを送らないため、別途 LiteLLM のような gateway を挟まないと per-key のコストが追えない。コスト削減の施策に入る前に、追跡の仕組みを先に整備しておく。

ありがちな失敗パターン

私と周囲で観察された失敗例を集約しておく。導入で触れた「全部 max」「Opus 常用」の他にも、見落としやすいものがある。

subagent に model 指定なしで動かすと、メインセッションの model を継承する。subagent が Opus を消費していた、という事故は frontmatter で固定すれば防げる。Bedrock 運用で fast mode を期待するのも間違いで、対応していない。Bedrock での latency 改善は effort を下げる方向で対応する。

mid-conversation で /fast を切り替えると会話全体に fast 価格が再適用される。fast を使うならセッション開始時から ON にする。plan mode を opus 単独で長時間動かすと opus[1m] の自動アップグレードが効かない場合がある。複雑タスクは opusplan を検討してほしい。

CLAUDE.md に詳細手順を書き込むとセッション起動時から全文が context に乗る。skill 化して on-demand にするのが正解だ。Bedrock で Haiku を有効化し忘れると background タスクが primary model にフォールバックして、月数百円のはずが数千円に跳ねるケースがある（Bedrock 記事参照）。

それぞれは小さな見落としだが、組み合わさるとコストが想定の数倍になる。

まとめ

「迷ったら全部 max・全部 Opus」は安全策に見えて、実際は最も高コストな選択肢だ。日常の 8 割は sonnet + high で動かし、設計判断と詰まったデバッグだけ opus に上げ、機械的タスクは subagent 経由で haiku に流す。この型を一度作ると、迷う時間も請求も両方下がった。

今日のセッションで試すなら、/model sonnet と /effort high をデフォルトに据えることから始めてほしい。1 つでも subagent を .claude/agents/.md に切り出して、frontmatter に model: と effort: を書いておく。次のセッションから「気づかないうちに Opus が走っていた」が消える。

dynamic workflows まで踏み込みたい人は、5/30 の Dynamic Workflows 記事 と合わせて読むと、subagent 固定の威力がさらに見えてくるはずだ。