Claude Codeのモデル使い分け。工程別の割当と切替手順

Claude Codeのモデル使い分けとは、作業の種類ではなく工程ごとにモデルの階層を固定して割り当て、新しいモデルが出たら評価セットで回帰を確認してから工程単位で切り替える運用のことです。

僕はAIVESTという会社を経営しながら、自分でもClaude Codeを触り、毎朝の記事便やコードの監査ワークフローを無人で回しています。検索で出てくるのはモデル一覧・切替コマンド・用途別のおすすめまでで、「何を確認してから切り替えるか」「切り替えない判断」は空白でした。この記事はその空白を、既定の最上位モデルのまま回して利用上限で止まった自社の実記録と、工程ごとにモデルを固定した割当表の現物で埋めます。モデル同士の性能比較はしません。

Claude Codeのモデル使い分けとは。工程に当てる設計の考え方

作業の種類ではなく、工程に当てる

「議事録は下位、提案書は中位、分析は上位」という作業別の早見表は上位記事に揃っています。僕がそれで判断できなかったのは、業務をClaude Codeに載せると、1つの作業が複数の工程に分かれるからです。記事を1本書く便でも、企画・執筆・画像・検証投稿の4工程があり、必要な判断の重さは工程ごとに違います。

モデルは作業に当てるのではなく、工程に当てる。割当を工程単位で固定しておくと、新しいモデルが出たときに「全部を乗り換えるか」ではなく「どの工程を試すか」という小さな問いに変わります。これがこの記事の背骨です。

2026年9月時点の公式モデル階層の見方

Claude Codeの公式ドキュメント「Model configuration」（2026年9月3日確認）では、モデルは名前の別名（エイリアス）で指定します。fable・opus・sonnet・haikuの4階層に加えて、best（使える中で最上位）、opusplan（計画は上位・実行は中位に自動で切り替える）、100万トークンの文脈版があります。同ページの記載では、2026年9月時点でfableはFable 5.1、opusはOpus 5、sonnetはSonnet 5を指し、何も指定しない既定はMax・Teamプレミアム席・Enterprise・APIがOpus 5、ProとTeam標準席がSonnet 5です。

一覧表はこの記事に転載しません。名前と対応は更新されるので、公式ドキュメントを正本にしてください。この記事で使うのは「上位・中位・下位」という階層の関係だけです。階層の関係は世代が変わっても変わりにくいので、割当表を階層で書いておくと、世代交代のたびに書き直さずに済みます。

なぜ全部を最上位モデルで回してはいけないのか。既定のまま回して止まった僕の実記録

記事便はモデル未指定のまま、全工程が最上位で走っていた

自社のブログ記事便は、毎朝9時12分と15時7分に定時起動し、企画・執筆・画像・最終投稿の4工程をサブエージェント（親のセッションから呼び出される子の処理）に分けて回しています。この4工程のどこにもモデルを指定していませんでした。公式ドキュメントの仕様どおり、指定がないサブエージェントは親と同じモデルを継承します。親は既定の最上位モデルで、考えさせる量（effort）も最大の一つ手前のxhighです。つまり、判断せず決定的なスクリプトを順に実行するだけの最終工程まで、最上位モデルが最大級に考えながら走っていました。

2026年8月30〜31日、3便連続で止まった

You've reached your Fable 5 limit. Switch to another model, or manage usage credits at claude.ai/settings/usage to continue.（自社の定時実行ログ・2026年8月30日9時12分便の記録）

同じ文言で、8月30日の9時12分便と15時7分便、8月31日の9時12分便の3便が連続で止まりました。8月26日の朝の便でも1回、同じ止まり方をしています。エラー文言は「別のモデルに切り替えるか」と最初に告げていて、答えは画面に出ていました。それでも僕は工程ごとの割当を作っていなかったので、切り替える先がありませんでした。この記事を書いている9月3日時点の既定は、Fable 5.1の100万トークン文脈版です。

最上位モデルを全工程に当てる設計は、上限に当たった瞬間に全工程が同時に止まります。下位モデルで足りる工程を分けておけば、少なくともその工程は動き続けます。上限に達したときの減速・検知・冗長化の設計はサブスクの利用上限の記事に、料金プランと利用枠の見方はClaude Codeの料金と法人導入の記事に委ねます。

エラー文言を読み返して気づいたのは、上限そのものより「切り替える先を用意していなかった」ことが原因だったということです。割当表は、止まる前に作るものでした。

上位モデルを当てるべき工程はどう見分けるか。判断の重さ×やり直しコスト×検証可能性

機械ゲートで合否が出る工程は、下位モデルで足りる

自社の記事便では、タイトル32字以内・抜粋80〜120字・本文2,500字以上・見出し3本以上・狙いキーワードの含有・内部リンクの実在・画像URLの応答まで、スクリプトが合否を出します。合否が機械で出る工程は、モデルの階層を下げても品質はゲートが守ります。落ちたら差し戻すだけで、上位モデルの「間違えにくさ」に頼る必要がありません。この機械ゲートの作り方はAI記事の品質ゲートの記事に書きました。

ゲートが作れない判断工程にだけ、上位を当てる

企画の選定、原稿の論理の筋、監査での見落としの検出。これらは合否を機械で書けません。判断が重く、間違うと後工程が全部やり直しになり、検証も人かAIの目に頼る。3軸すべてが重い工程が、上位モデルの席です。上位モデルは「難しそうな作業」ではなく「ゲートが作れない工程」に当てる。この順番にすると、上位モデルの席は思ったより少なくなります。

工程×モデルの割当表の作り方。自社ワークフローの現物

セキュリティ監査ワークフローの5工程割当

自社で工程ごとにモデルを固定している現物は、コードベースを自社規約と脆弱性の両面で監査するワークフローです（2026年8月4日版）。監査の中身や検出の観点はここでは書きません。書くのは工程とモデルの割当だけです。

MODEL_DETECT = 'inherit' // 品質の心臓。ここはケチらない（自社ワークフローの制御盤に残したコメント）

検出工程を上位にした理由は、ここで見落とすと後の工程は何もできないからです。判断が重く、やり直しは全便、検証は人の目。3軸すべてが重い。逆に事実照合は「置き換え可能な仮の値か、本物か」を確かめるだけなので、下位モデルでも1票で決まります。

下位モデルの精度不足は、票数とゲートで補う

脆弱性検証を中位にできたのは、1体の判断に頼らず3つのレンズで多数決を取る構造にしたからです。2票が否定すれば棄却し、有効票が2未満なら「未検証」に降格して捨てない。モデルの階層と検証構造はセットで決める。階層を下げるなら、その分の票数かゲートを足します。この考え方はClaude Codeのカスタムスキルの記事で書いたサブエージェント運用の延長です。

台帳に工程別の所要時間と出力量を記録する

割当表を作ったら、工程別の計器を先に置きます。自社のX記事側では、工程ごとに想定所要時間・想定出力文字数・1日の呼出回数を事前に宣言し、毎回の実測（所要ミリ秒・成否・入力文字数・出力文字数）と突合して逸脱を毎朝警告しています。たとえば記事生成工程は所要35分・出力2万字・1日2回、企画起案工程は12分・1万2千字・1回を宣言しています（2026年9月3日時点の宣言値）。9月2日の企画起案の実測は約9分20秒・出力7,893字で、宣言の内側でした。

正直に書くと、この台帳にモデル別の列はまだありません。新しいモデルを試すときに足すのは、この台帳の「モデル」の1列です。列が1つ増えるだけで、前後比較ができるようになります。計器を先に仕込んでから自動化を載せる順番はAI効率化の計測設計の記事に書きました。

Claude Codeで工程ごとにモデルを指定する方法

公式ドキュメント（2026年9月3日確認）に記載のある指定方法は次のとおりです。ここでは名前だけ列挙し、書き方は末尾の付録に置きます。

• セッション中の切替コマンド。その場だけ切り替えるか、既定として保存するかを選べる

• 起動時のオプションと環境変数。定時起動の便に固定の階層を渡すときに使う

• 設定ファイルのモデル項目。何も指定しない便が継承する既定になる

• サブエージェント定義のモデル項目と考えさせる量（effort）の項目。工程ごとの割当はここに書く。指定がなければ親のモデルを継承する

• opusplanという別名。計画は上位、実行は中位に自動で切り替わる

• 考えさせる量（effort）。low・medium・high・xhigh・maxの段階があり、対応する段階はモデルで異なる

• 現在のモデルの確認。/statusコマンドとステータス行

僕の割当表の実装は、ワークフローの制御盤に工程ごとのモデル名を定数として並べ、各工程の呼び出しに渡す形です。割当は設定画面で選ぶものではなく、工程の定義に書き込むものです。

新モデルが出たら何を確認してから切り替えるか。回帰→一部工程→台帳→切替の手順

2026年9月2日（JST）に、Claudeの公式アカウントがFable 5.1を発表し、Claude Codeへの投入を告知しました。公式ドキュメントも、fableの別名がFable 5.1を指すと記載しています（2026年9月3日確認）。性能や使用感は、僕はまだ実測していないので書きません。この記事の時点でFable 5.1は「これから下の手順を回す対象」です。

縮小レビュー（モデル更新後）: ハーネス部品（リトライ・分解手順・防御的指示）を1つずつ無効化して eval を回し、「まだ必要か」を検証する。不要になった scaffolding は外す。ハーネスは育つだけでなく縮む。（自社のハーネス診断スキルの手順書より）

手順6は上位記事に無い視点で、僕が一番大事だと思っている工程です。古いモデルの弱点を補うために足した手順は、新モデルでは邪魔になることがあります。評価セットの作り方と回し方はループエンジニアリングの記事に書きました。

切り替えない判断の根拠。コストと利用上限の観点

手順を回した結果、切り替えないという答えも普通にあります。僕が「戻す」と決める条件は3つです。

• 評価で差が出ない。評価セットの合否が前のモデルと同じなら、上位に変える理由がない

• 上限・費用の消費が増える。同じ便で利用枠の消費が増えるなら、8月末の3便連続停止が再現する。ベンダーやプラン間の費用比較は生成AIの料金比較の記事に、従量課金の予算ガードはAIのランニングコスト管理の記事に委ねます

• 出力の型が変わり、下流の決定的処理が壊れる。自社の記事便は、執筆工程の出力を決められた記法の範囲でスクリプトが変換します。新モデルが記法の外で書くと、本文の質に関係なくゲートで落ちます

切り替えないのは保守ではなく、評価と台帳が「変える理由がない」と言っている状態です。理由が台帳に残っていれば、次のモデルが出たときに同じ手順をもう一度回すだけで済みます。

Claude Codeのモデル使い分けでよくある質問

まとめ。モデルは工程に当て、切替は評価で決める

Claude Codeのモデル使い分けを、自社の割当表と停止の実記録から整理しました。

• モデルは作業ではなく工程に当てる。割当表は階層（上位・中位・下位）で書き、世代交代で書き直さない

• 既定のまま全工程を最上位で回すと、上限で全工程が同時に止まる（2026年8月30〜31日の3便連続停止）

• 判断の重さ×やり直しコスト×検証可能性で採点し、ゲートが作れない判断工程だけ上位。下位・中位は票数とゲートで補う

• 新モデルは評価セットで回帰、1工程だけ試す、台帳で前後比較、残す・戻す・広げる、要らない手順を外す、の順

切り替えるかどうかは、モデルの評判ではなく自分の評価セットと台帳に答えさせるのが、この記事で一番伝えたいことです。自社の業務を工程に分解し、どこに上位を当てるかを一緒に決めたい場合は、AI顧問サービスの内容を確認のうえお問い合わせからご相談ください。

付録。工程ごとにモデルを指定する公式機能の一覧

公式ドキュメント「Model configuration」「Subagents」を2026年9月3日に確認した時点の書き方です。仕様は更新されるので、実行前に公式ページで再確認してください。

出典

公式の仕様は以下を2026年9月3日（JST）に確認しました。3軸の物差し、工程単位の切替、縮小レビューの経営者向けの翻訳、割当表と停止の実記録は、僕の自社運用の記録（定時実行ログ、監査ワークフローの制御盤、コスト台帳と事前宣言、評価セット、ハーネス診断の手順書。いずれも社内記録）に基づく一次情報です。「新しい世代が出たら確認する」「作業で分けてから階層を当てる」という枠組みは下記の上位記事が先に整理していたもので、本記事はそこに「自分の業務で壊れないかを評価セットで確かめる」「一部工程で試して戻す」「切り替えない判断」を足しました。

• Claude Code公式ドキュメント: Model configuration（2026年9月3日確認）: 別名の一覧、プラン別の既定、指定方法の優先順、effortの段階、/statusでの確認

• Claude Code公式ドキュメント: Subagents（2026年9月3日確認）: 定義ファイルのmodel・effort項目、指定がない場合の継承順

• Claude公式アカウントのFable 5.1発表ポスト（x.com）、Claude DevelopersアカウントのClaude Code投入告知ポスト（x.com）（いずれも2026年9月2日JSTに確認。発表の事実のみ参照し、性能の主張は引用していません）

• 上位記事の網羅範囲の確認に参照したもの（リンクは省略）: fixit「Claude の Opus と Sonnet の違い。バージョンに依らない違い」、giftx「Claude Codeのモデル一覧と切り替え方」、next.inc「Claude Code のモデルはどう使い分けるべきか」、zenken「Claudeのモデル選び方ガイド」、hatenabase「Claude全モデル比較ガイド」。本記事は上位が扱っていない「回帰確認の手順」「工程単位の段階導入」「台帳での前後比較」「切り替えない判断」に絞りました