Claude Codeのモデル使い分け｜作業種別×effortの配分計画の実例

モデルの選択と effort（推論にどれだけ考えさせるか）は、混同されやすいが独立した2つの軸である。モデルは能力の上限を、effort はその上限をどれだけ引き出すかを決める。結論から言えば、この2軸は別々に設計し、作業種別ごとに既定を決めて成果物へ書き出しておくのがよい。本稿は筆者が実運用している配分計画の実物を用いて、その設計と運用を整理する。

2軸を独立に設計する — まず effort、次にモデル

モデル名（opus・sonnet・haiku・fable）と effort の段階（low〜xhigh）は変化が速い。本稿の記述は 2026-07-16 時点、Claude Code v2.1.211 で確認した。

2軸を独立に扱う利点は、出力が期待に届かないときの切り分けにある。原因は大きく二つに分かれる。出力が浅い・詰めが甘い・考慮漏れが多いなら、それは考える量が足りない effort 不足である。一方、そもそも前提を取り違える・設計を誤る・込み入った依存を追い切れないなら、能力の上限に達している モデル不足である。前者は同じモデルのまま effort を上げれば済み、後者はモデルを上げないと解けない。

だから調整には順序がある。迷ったら effort → モデルの順に上げる——この順序は筆者の各プロジェクトの配分計画に共通する原則である。まず深く考えさせて足りるかを見て、それでも判断を誤り続けるならモデルを上げる。実運用の規則としては、本ワークストリームの計画に「同一タスク2回失敗で effort → モデルの順に1段上げる」と明記している。常態化したら既定表を見直す。昇格・降格の規約そのものは別記事で単独に扱う。

作業種別ごとに既定を決める

2軸をその都度勘で決めると判断がぶれる。そこで作業種別ごとに既定を先に決めておく。指針となるのは一つの配分原則である。本ワークストリームの配分計画は、冒頭にこう書いている。

配分原則: 推論コストは判断の不可逆性・影響度に比例させる。
設計・レビュー・ゲートに厚く、確定済み実装・定型作業に薄く。

この原則をフェーズ別に落とすと次のようになる。

| フェーズ | 作業内容 | 推奨モデル | effort | 備考 |
| Phase 0a | リポジトリ適応設計 | fable（または opus） | high | 既存アーキテクチャとの整合は Type 1 判断。失敗は全体に波及 |
| Track B | 必須ページ・スニペット・sitemap 実装 | sonnet | medium | 雛形差し込み中心の定型実装 |
| Track A Phase 2 | 記事本文生成 | opus（article-writer） | high | 文章品質が審査結果に直結 |
| 記事ゲート | レビュー・受入判定 | opus（article-reviewer） | high | 生成と検証の分離。writer と別コンテキスト |
| 横断 | デバッグ（原因不明） | opus | xhigh | 原因特定後の修正は sonnet ＋ medium へ降格 |
# … 全9行のうち5行を抜粋（Track A Phase 0/1、Phase 2 のコード例検証、コミット整形の4行を省略）

上端の設計・適応（Phase 0a）とレビュー・ゲートは厚く、確定済みの定型実装（Track B）は薄い。デバッグは原因が読めないうちだけ最上位に振り、原因を特定したら sonnet ＋ medium へ降格する——高い推論を「原因特定」という影響度の高い局面にだけ集中させる考え方である。

サブエージェントには固有の注意がある。model を指定しないサブエージェントは、呼び出し元セッションのモデルを継承する。 上位モデルで作業中に、うっかり探索用の使い捨てエージェントまで上位モデルで走らせると無駄が出る。だから探索・列挙役は明示的に固定する。本ワークストリームの content-scanner はこう定めている。

| content-scanner | haiku | 探索・列挙。大量・使い捨て。継承させない |
# … サブエージェント表全3行のうち1行を抜粋（article-writer=opus・article-reviewer=opus を省略）

継承の罠を避けるため、サブエージェントの model は frontmatter で必ず明示する（役割別の設計そのものは別記事で扱う）。

配分を成果物として同梱する

この配分表は、頭の中に置くのではなくファイルに書き出している。置き場所は docs/hub-articles/model-plan.md で、実装より先に生成するスキャフォールドの一部である。成果物にする理由は三つある。

第一に揮発の管理。モデル名も effort の仕様も変化が速い。計画の冒頭に確認日を持たせておけば、鮮度を運用できる。本計画のヘッダはこうなっている。

最終確認日: 2026-07-13（モデル名・effort 仕様は変化が速い。3ヶ月経過したら公式ドキュメントで再確認）

第二に実績の還元。配分は一度決めて終わりではない。エスカレーションが常態化したら既定を書き換え、その理由を変更履歴表に残す。判断がデータで裏取りされ、次の判断の根拠になる。

第三に複製。スキャフォールドの一部だから、次のプロジェクトの立ち上げ時に骨格ごとコピーされる。実際、セッションログビューワのプロジェクトと、CMS を自作している未公開プロジェクトにも、同じ配分原則の一文・フェーズ別表・model 指定・最終確認日・変更履歴表を持つ model-plan.md が同梱されている——3つのプロジェクトで同じ型が回っている。計画をコードと同じ成果物として扱う考え方は、スキャフォールド駆動の一部として別記事で扱っている。

逼迫時に何から下げるか

使用量が逼迫したとき、全体を一律に下げるのは筋が悪い。影響度の低いものから削る。本ワークストリームの計画は運用規則にこう定めている。

使用量逼迫時: 下げるのは Track B 実装・定型（Type 2）から。Phase 0a/1 とレビューの品質は最後まで守る

削ってよいのは確定済みの実装・定型作業である。契約や設計が固まった後の実装は、判断がほとんど残っておらず、下位モデルでも仕上がりが大きく崩れない。逆に、最後まで守るのは設計・適応の判断とゲートのレビューである。ここを削ると、誤った前提のまま安いコストで大量のコードを生み、あとで高くつく。CMS を自作している未公開プロジェクトの計画は、この考え方を「安く作って高く壊さない」と一言で表している。優先して守る順序を平時に決めておくからこそ、いざ逼迫したときに迷わず削れる。ゲートの品質を守る姿勢は、フェーズを刻んで承認を挟む運用と対になっている。

よくある質問

常に最上位モデル・最高 effort にすればよいのでは。 品質だけを見ればそうだが、コストと速度の代償が大きい。判断の余地がない定型作業まで深く考えさせても、仕上がりはほとんど変わらずに時間と使用量だけが増える。効かせどころを絞るのが配分の目的である（速度差・料金は実測していないため定性で述べている）。

モデルを切り替えたら effort の設定が消えた。 これは実運用で繰り返し踏んだ注意点で、3つのプロジェクトの計画すべてに書き残してある。haiku は effort 非対応で、haiku を経由してモデルを切り替えると effort 設定が消え、そのまま復元されない。モデルを切り替えた後は effort を確認するのが安全である。なお実物の計画には「xhigh は opus 系のみ対応」との記述もあり、effort の上限はモデルによって差がある（いずれも 2026-07-16 時点の確認）。

まとめ

Claude Code のモデル使い分けは、モデル（能力の上限）と effort（考える深さ）を独立した2軸として設計するのが出発点である。迷ったら effort → モデルの順に上げ、作業種別ごとの既定は「推論コストを判断の不可逆性・影響度に比例させる」原則で決める。設計・レビュー・ゲートに厚く、確定済みの実装・定型に薄く。そしてその配分表を頭の中ではなく成果物として書き出し、確認日で鮮度を保ち、実績を変更履歴に還元する——これが配分を運用可能にする要点だと考えている。