Claude Code、そのまま使っていませんか？ モデルと effort の使い分けを AI に任せる環境構築プロンプト【完全版】

Claude Code を使い始めて少し慣れてくると、だいたい同じところで手が止まります。
「Opus と Sonnet と Haiku、どれをどの effort で使えばいいの？」という問題です。

全部を一番賢いモデルで回せば質は出ますが、使用量の上限にすぐ届きます。
かといって作業のたびに自分でモデルを切り替えるのは面倒ですし、どこで切り替えるのが正解なのかも分かりません。

私はこの数か月、毎日 Claude Code でスマホアプリやゲームを作りながら、この使い分けを試行錯誤してきました。
今は「どのモデルに、どの effort で、どの作業をさせるか」を Claude 自身が判断して振り分ける環境で動かしています。
余っている他社 AI の定額プランも「外部レーン」としてつなぎ、全体で作業を分担させています。

この記事では、その環境の考え方と、自分の PC に同じ環境を作るための「環境構築プロンプト」を紹介します。
プロンプトは Claude Code に貼り付けるだけで、エージェントの定義・ルール・hook までを Claude が作ってくれます。

何も設定しないと、何が起きているか

最初に、私が自分の使い方を測って驚いた数字を出します。

ある時点までの会話記録 64 セッション分を集計したところ、委任(サブエージェント)の呼び出しは次のようになっていました。

• general-purpose(組み込み): 754 回

• Explore(組み込み): 622 回

• 自分で作った安いモデルのエージェント: 98 回(全体の約 6%)

組み込みのエージェントは、モデルを指定しないと親のモデルを引き継ぎます。
つまり「安いモデルに任せているつもり」の委任の 9 割以上が、実はメインと同じ一番高いモデルで走っていました。

もう一つ大事なのが、Claude Code の料金の中身です。
Claude Code のトークンは、大半が「キャッシュ読み」(毎ターン、それまでの会話をもう一度読み込む分)です。
会話が長くなるほど、1 ターンごとの読み込みが重くなります。

公式の料金表(2026-09-23 時点)から、キャッシュ読み 15 万・書き 5 千・新規入力 1 千・出力 3 千という典型的な 1 ターンを計算すると、次のくらいの差があります。

• Opus 5.5: 約 $0.119

• Sonnet 5.5: 約 $0.060

• Haiku 5.5(サブエージェント・文脈 3 万程度): 約 $0.0025

同じ作業でも、どのモデルに回すかで数十倍の差が出ます。
ただし、安いモデルに何でも任せると質が落ちます。
問題は「どれを安いモデルに回してよいか」の線引きです。

この環境で変わったこと

線引きをルールにして Claude に守らせるようにしてから、次のように変わりました。

• 決まった手順の作業(ビルド・ストアへの提出など)を Sonnet のセッションで回すようにした。実測では、Opus のセッションは 16 本でキャッシュ読みが 9 億 3300 万トークン、Sonnet のセッションは 62 本で 8200 万トークン。1 セッションあたりのキャッシュ読みは約 44 分の 1 になった

• 同じアプリのビルドを Haiku と Sonnet のセッションで 1 回ずつ流したところ、どちらも成功し、報告も正しかった。費用は Haiku が $0.044、Sonnet が $0.30 で、約 7 分の 1(サンプルは 1 回だけです)

• 委任のたびに「どの役割を、どのモデルで」が 1 行で表示されるので、高いモデルで無駄に回っている作業にすぐ気づける

• 仕様が決まった大きな実装を外部の AI に書かせ、Claude は指示書と検品だけにしたところ、Claude 側の費用は 1 件 $1.5〜12 で済んだ。自分で書いた場合の見込みは $8〜15

数字は私の使い方で測ったものです。
作業の内容が違えば、同じ割合にはなりません。
ただ「何も設定しない状態」から変えると差が出る、という方向は多くの人に当てはまると思います。

全体像

この環境は、次の 4 つでできています。

1. 役割ごとのエージェント 5 つ: 調査・実装・重い実装・ビルドとテスト・機械的な大量処理。それぞれモデルと effort を固定してある

2. 振り分けのルール: CLAUDE.md に「どの作業を誰に回すか」の表と、委任の作法を書いてある

3. 振り分けを忘れさせない hook: 会話が長くなったり要約(compact)されたりしても、振り分けのカードを定期的に Claude に渡し直す。委任の回数とモデルも毎ターン表示する

4. 外部レーン(任意): ChatGPT など、他社 AI の定額プランの余った枠に調査や実装を回し、Claude は判定に専念する

メインの Claude(一番賢いモデル)は設計と判断と最終チェックだけを受け持ち、手を動かす作業は安いモデルや外部に流れる形です。

ここから先の有料部分では、次の内容を書いています。

• 振り分けの線引きの考え方(なぜその作業は安いモデルでよいのか)

• 質が足りない時の「effort の段階上げ」のルール

• 外部レーンのつなぎ方と、外部の中でのモデルの分け方、やってはいけない設定

• 環境構築プロンプトの全文(貼り付けるだけで構築できます)

• 追加のプロンプト: Claude の書く日本語から「AI っぽさ」を抜く仕組みを入れる

• 実際に運用してハマったところと、その対策

線引きの考え方: 5 つの原則

1. 判断は高いモデル、作業は安いモデル

設計・画面のデザイン・文言・原因の分からないバグの切り分けは、メインの一番賢いモデルが自分でやります。
ここを安いモデルに回すと、もっともらしいが的外れな結論が返ってきて、確かめ直す手間の方が高くつきます。

一方、仕様が決まった後の実装・ビルド・テスト・大量のファイル処理は、判断の余地が少ない作業です。
ここを安いモデルに回します。

2. 安いモデルに回してよいのは「結果が後で確かめられる」作業だけ

これが一番大事な線引きです。
安いモデルの失敗は、エラーではなく「もっともらしいが不完全な報告」として返ってきます。
ビルドが通ったか、テストが通ったか、検索で何件見つかったか、のように後から機械的に確かめられる作業なら、失敗しても気づけます。
文章の質や判定の正しさのように、確かめるのに同じくらいの賢さが要る作業は、安いモデルに回しません。

3. エージェントにはモデルと effort を固定する

冒頭の数字のとおり、組み込みのエージェントは親のモデルを引き継ぎます。
安く回したい作業は、モデルと effort を書き込んだ自作のエージェントに回します。
モデルは正式な ID で書きます(opus のような略称は使いません)。
略称の行き先は Claude Code の版で変わるからです。
私のサーバーでは Claude Code が少し古く、haiku と書いた所でまだ一つ前の Haiku が動いていました。

4. 小さな作業は委任しない

委任には固定費があります。
指示書を書き、起動し、返ってきた報告を確かめる分のトークンです。
私の環境では、変更が 300 行未満の実装はメインが直接やった方が安い、という結論になりました。
190 行前後の実装 4 件を委任した時、指示書と確認にかかったメイン側の費用が、自分で書いた場合の見積もりを上回っていたためです。

5. セッションの途中でモデルを変えない

モデルと effort は、キャッシュの鍵の一部です。
途中で切り替えると、その直後に会話全体をキャッシュ無しで読み直すので、会話が長いほど高くつきます。
切り替えたくなったら、それが新しいセッションを開く合図です。
深く考えさせたいのが 1 ターンだけなら、プロンプトに ultrathink と書けば、キャッシュを保ったままそのターンだけ深くなります。

役割の分担

• メイン(Opus 5.5 / medium): 設計・UI・文言・原因調査・成果物の最終判定・300 行未満の修正

• research(Sonnet 5.5 / 既定): 調査・コードの探索・Web 調査。文章の質を見る役もここ

• impl(Sonnet 5.5 / high): 仕様が確定した大きな実装

• impl-heavy(Opus 5.5 / medium): 判断の重い設計を伴う改修、impl で詰まった実装

• ops(Haiku 5.5 / medium): ビルド・テスト・動作確認。コードは直さない

• bulk(Haiku 5.5 / low): 手順が決まった機械的な大量処理。判断しない

モデル名は執筆時点のものです。
環境構築プロンプトは、その時点の最新モデルを公式ドキュメントで確かめてから当てはめるように書いてあります。

各エージェントには「迷ったら勝手に決めず、状況と選択肢と推奨を報告して止まる」「報告は要点とファイルのパスだけ。全文を貼らない」と書いてあります。
後者は地味ですが効きます。
委任先がログやファイルの全文を報告に貼ると、それがメインの会話に積もり、以後の毎ターンのキャッシュ読みを太らせるからです。

質が足りない時の「effort の段階上げ」

Haiku で質が足りなかった時は、モデルを Haiku のまま、effort を 1 段ずつ上げてやり直します(low → medium → high → xhigh → max)。
max でも足りない時だけ Sonnet に上げます。

外部のベンチマーク(Artificial Analysis、2026-10-13 取得)では、Haiku 5.5 を low から max まで全部やり直した費用の合計が、Sonnet 5.5 の medium 1 回とほぼ同じでした。
費用の面では損をしにくい上り方です。

ただし例外があります。
道具を何十回も使う長い作業では、Haiku の effort を上げても届きませんでした。
私のゲームのプレイテスト(AI にゲームを 7 日目まで遊ばせて詰まる所を報告させる作業)では、Haiku は high・xhigh・max のどれも 2〜3 日目で止まり、Sonnet は low で 7 日目まで届きました。
こういう種類の作業は、最初から Sonnet を出発点にしています。
同じ種類の委任で上の段が続けて要ったら、次からはその段から始める、というのもルールに入れています。

振り分けを忘れさせない仕組み

CLAUDE.md にルールを書いただけでは、会話が長くなると効きが落ちます。
特に、会話が要約(compact)された直後は、細かいルールが抜けやすくなります。

そこで hook を 2 つ使っています。

• compact の直後: 振り分け表を 10 行ほどに縮めた「振り分けカード」を Claude に渡し直す

• プロンプトを送るたび: 直前のターンの所要時間と、委任の回数・モデルを 1 行にまとめて渡す。8 回に 1 回は振り分けカードも付ける

応答の最後に、こんな 1 行が出るようになります。

[turn-stats] 所要 4分05秒 / 委任 2 回(research=Sonnet 5.5, ops=Haiku 5.5)

さらに、委任する直前には必ず次のような 1 行を出させています。

🤖 ops → Haiku 5.5 (medium): Android のデバッグビルドを回して成否を報告

これで「今の作業はどのモデルで動いたか」が毎回目に入ります。
高いモデルで回す必要の無い作業に気づけるのは、この表示のおかげです。

外部レーン: 余っている他社 AI の枠を使う

ChatGPT など、他社 AI の定額プランを契約していて枠が余っているなら、Claude の使用量をさらに減らせます。
私は OpenAI の Codex CLI(ChatGPT の定額プランでログインして使う)を外部レーンとしてつないでいます。

役割は次のとおりです。

• 調査・探し物: 外部レーンを読み取り専用で起動し、結論だけを受け取る。結論はメインが確かめる

• 仕様が確定した実装: 本体とは別のフォルダで外部レーンに実装させ、差分をメインが読んで判定してから取り込む

外部が「手を動かす係」、Claude が「判定する係」になる形です。
Claude の使用量が一番かかる実装の往復を、外部の定額枠に肩代わりさせられます。

外部のレーンが 2 つ以上あるなら、レビューは実装したのとは別のレーンにさせます。
同じモデルだと、同じ所を見落としやすいからです。
今の私は外部レーンが 1 つなので、実装とは別に起動してレビューさせています。
合格するまで外部だけで往復させ、メインは指摘された箇所と危ない箇所だけを読みます。

Claude の Haiku に回していた探し物や機械的な大量処理も、定額の枠が残っている間は外部レーンを先にしています。
Haiku に残すのは、鍵や通信が要るビルド、エミュレータやブラウザの操作など、外部の作業用フォルダからは触れない仕事だけです。

外部レーンの中でも、モデルを分ける

Codex では、ChatGPT の定額プランの中で複数のモデルを選べます。
私は 2026-10-23 に GPT-6.1 Sol を足して、次のように分けました。

• GPT-6.1 Sol(effort medium): 実装・レビュー・調べ物・コードの差分の判定

• GPT-6 Luna(effort xhigh): 手順の決まった大量処理・翻訳の下訳・プレイテストの検品役

Sol を入れた理由は、外部のベンチマークの数字です(Artificial Analysis の Intelligence Index、2026-10-23 取得)。
Sol は medium で 48、high で 50 でした。
Opus 5.5 の medium(51)に近く、Sonnet 5.5 の high(47)を上回ります。
それまで使っていた Luna は、max でも 38 でした。

effort は、最初は high を既定にするつもりでした。
そこで、受け入れ条件が 33 項目ある同じ仕様の実装を、medium と high で 1 本ずつ書かせて比べました。
結果はどちらも 33 項目すべて合格で、既にあった機能を壊した所もありませんでした。
所要時間は 13 分台でほぼ同じ、Codex の 5 時間の枠の減り方もどちらも 12% ほどで、読み込んだ量は medium の方が 3 割ほど少なかったです。
差が出なかったので、既定は medium にしています。

上げ方は、Claude のエージェントと同じです。
やり直しの時と、広告・課金・保存データに触る変更、差分が大きい時は high に上げます。
それでも駄目なら xhigh、その次は Claude の impl-heavy(Opus)に戻します。

定額の枠は、画像生成など他の使い道とも共有です。
そこで、5 時間の枠が 60% を超えたら、レビューと調べ物は自動で Luna に落とすようにしました。
80% を超えた時は警告を出すだけで、実装は勝手に落としません。
待つか、Claude の impl に回すかを、その場で決めます。

コードの差分の判定も、Claude の Sonnet から Sol に移しました。
Sonnet に残したのは、記事やストア文など文章の質を見る役と、外部のエンジン同士を比べる時の審判です。
審判まで Sol にすると、Sol 自身が比べられる側に入ってしまうからです。

注意点が 3 つあります。

1つ目は、API キーを環境変数に入れないことです。
OPENAI_API_KEY などを設定すると、定額プランではなく従量課金で動くことがあります。

2つ目は、新しいツールを入れたら、裏で呼ばれるモデルまで確かめることです。
私が以前に試したツールでは、メインのモデルを無料のものに指定していても、会話のタイトル付けのような小さな処理だけ別の有料モデルに投げる設定になっていました。

3つ目は、無料の枠を使う時は、入力が学習に使われることがある点です。
私は以前、無料で使える外部のモデルを先頭のレーンにしていましたが、それは学習への利用に同意する代わりの無料枠でした。
外部に渡すのはコピーした作業用のフォルダだけにして、鍵や個人情報の入った場所は読ませません。
無料枠はある日突然終わることもあります(私が使っていた枠も終わりました)。
消える前提で、消えたら次のレーンか Claude に戻る作りにしておきます。

環境構築プロンプト

以下を Claude Code に丸ごと貼り付けてください。
Claude が手順 1 から順に進め、選択が必要な所では止まって質問してきます。
作業の前に既存の設定をバックアップするので、元に戻すこともできます。