Fable 5は「設計にだけ」置く｜Claude Codeのフェーズ別モデル割当

Claude Fable 5はAnthropicの最上位モデルです。使えば強いのは分かっている。ただ、セッション全部をFableで回すかというと、それは違います。ファイルを探すのも、テストを流し直すのも、typoを直すのも全部Fable、というのは単に高いだけです。

かといって「高いから使わない」も間違いで、設計を間違えたときのやり直しコストは、Fableとの単価差より遥かに大きい。

答えは置き場所の問題です。Claude Codeはメインループとサブエージェントで別々のモデルを指定できるので、Fableを「設計」というピンポイントに置いて、実装はSonnet、レビューはOpus、調査はHaikuに振り分けられます。この記事では、私たちが実際に使っているその割当を例に、どこに何を書けばそうなるのかを設定ファイル単位で解説します。

対象はClaude Code v2.1系です。

なぜFableを「設計だけ」に置くのか

判断基準は一つ、やり直しコストが高いフェーズかどうかです。

設計は1回のタスクで数回しか呼ばれませんが、そのアウトプットが実装全体の量を決めます。方針を間違えれば書いたコードをまるごと捨てることになる。一方で実装は延々と往復し、トークン消費の大半をここが占めます。

つまり単価の高いモデルを、呼び出し回数の少ないフェーズに置くのは、思ったほど高くつきません。逆に往復回数が最も多いフェーズのモデル選択が総額に一番効きます。「Fableは高いから使わない」ではなく「Fableは往復の少ないところにだけ置く」が、素直な答えになります。

同じ理屈で、レビューにはOpusを置いています。見落とすと本番で踏むフェーズなので、実装より上位の視点でチェックさせる価値があります。逆に「このシンボルがどのファイルにあるか」を調べるだけの調査は、間違えてもすぐ気付けるのでHaikuで足ります。

以下、これを実際の設定に落とします。

全体像：設定箇所は2つだけ

「フェーズ別にモデルを割り当てる」というのは、要するにフェーズをサブエージェントに切り出して、そのエージェント定義ファイルにモデルを書くということです。メインループ側でフェーズごとにモデルを切り替える機能はありません（/model での手動切替はできますが、自動ではありません）。

設定1：メインループのモデル

.claude/settings.json（プロジェクト単位）または ~/.claude/settings.json（ユーザー単位）に書きます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "sonnet",
  "effortLevel": "high"
}

メインループが担当するのは、あなたとの対話、調査の起点、実装、検証、レビュー指摘の反映といった「作業の本体」です。ここは往復回数が最も多く、トークン消費も最も大きくなるため、上位モデルを置くとコストが素直に効いてきます。私たちはSonnetを置いています。

effortLevel は思考の深さと全体のトークン消費を制御する値で、low / medium / high / xhigh / max を取ります。省略時は high です。

設定2：サブエージェントのモデル

.claude/agents/<name>.md を作り、YAML frontmatterに設定を書きます。本文がそのエージェントへのシステムプロンプトになります。

---
name: architect
description: 実装方針・アーキテクチャの設計を行う。コードは書かず、設計案と根拠を返す。
model: fable
effort: xhigh
tools: Read, Grep, Glob, Bash
permissionMode: plan
---

あなたはこのリポジトリの設計担当です。

与えられた要件に対して、既存コードの構造を読み取った上で、
実装方針を2〜3案提示し、それぞれのトレードオフと推奨案を返してください。

コードの変更は行いません。成果物は設計判断とその根拠です。

置き場所は2種類あり、プロジェクト固有のエージェントは <repo>/.claude/agents/、どのプロジェクトでも使うものは ~/.claude/agents/ に置きます。

frontmatterで指定できるもの

description は軽視されがちですが、親セッションはこの一文を見て委譲先を決めます。「何ができるか」だけでなく「何を渡せばいいか」まで書いておくと、委譲の精度が上がります。

呼び出し方：自動で選ばれる / 明示で指名する

内部的には、メインループがAgentツールに subagent_type としてエージェント名を渡すことで起動します。

Agent(subagent_type: "architect", prompt: "…")

ただしこれはClaudeが内部で組み立てる呼び出しであって、あなたがターミナルに打つものではありません。実際の使い方は次の2通りです。

1. 自動で選ばせる（普段はこれ）

メインループが各エージェントの description を読んで、いま必要な役割はどれかを判断し、勝手に委譲します。あなたは「認証まわりを設計してから実装して」と書くだけです。

裏返すと、description の質がそのまま委譲精度になります。「設計を行う」だけだと呼ばれるべき場面で呼ばれません。何をするか、何を渡せばいいか、どういうときに呼ばないかまで書いておくと安定します。

2. 明示的に指名する

プロンプトに @agent-<エージェント名> と書くと、そのエージェントを直接指名できます。

@agent-architect 認証フローの設計案を出して

行頭でも文中でも構いません。自然言語で「architectで設計して」と書いても大抵は通りますが、確実に効くのはメンション記法の方です。

使い分けとしては、日常運用は自動に任せ、確度が要る場面だけ明示します。たとえば「レビューを完了条件に数える」ようなケースで自動委譲を当てにすると、レビューが走らないまま完了扱いになる事故が起きます。ここは指名すべきところです。

どちらの経路でも、起動されるのはfrontmatterの設定に従ったまっさらな別セッションです。親セッションのモデル・権限・会話履歴は引き継ぎません。

なお、エージェントの作成・管理用だった /agents コマンドは削除されています。.claude/agents/ 配下のファイルを直接編集するか、Claudeに「こういうサブエージェントを作って」と頼んでください。

実際の割当例

私たちのプロジェクトでは次のように割り当てています。

Fableが出てくるのは architect の1行だけです。実装系のエージェント（backend-implementer など）は書き換え量が多く往復も多いのでSonnet、レビュー系は「実装より上位の視点」が要るのでOpus、という配置になっています。

落とし穴

ここからが実際に踏んだところです。設定を書いただけでは意図どおりに動かないケースがいくつかあります。

1. モデルを変えるだけでは「書かない」を保証できない

architect や code-reviewer を read-only にしたいとき、モデル指定は何の役にも立ちません。強制しているのは tools と permissionMode の方です。

さらに注意が必要なのは、tools に Bash を含めた時点で、ツール一覧だけでは read-only にならないという点です。Bashからは rm でもリダイレクトでも実行できます。実際に書き込みを止めているのは permissionMode: plan の方なので、両方をセットで指定してください。ツール制限は「使える道具を絞る」ためのもので、「破壊操作を止める」ものではありません。

2. 親セッションの権限が上書きしうる

Agentツールのドキュメントには「サブエージェントは親セッションのpermission modeを継承し、エージェント定義のfrontmatterがそれを上書きしうる」とあります。裏を返すと、書き込み権限を持ったターンからread-onlyエージェントを起動したとき、期待どおりのread-onlyセッションになる保証は薄いということです。

運用としては、レビューや設計を「独立した検証」として完了条件に数えたいなら、実装ターンからそのまま生やさず、フレッシュなセッションとして起動するか、親側をread-onlyに切り替えたターンから起動する、というルールを置いています。

3. サブエージェントは親の会話を知らない

フレッシュセッションなので、親がそれまでに調べたことも決めたことも見えていません。「さっきの方針でレビューして」は通じません。

したがって渡すプロンプトは自己完結したブリーフである必要があります。対象ファイルのパス、守るべき不変条件、報告フォーマット。これを毎回書くのは面倒ですが、書かないと「何を見ればいいか探すところから始める」ぶんだけ遅く、かつ的外れになります。

4. fork だけは例外

例外的に、subagent_type: "fork" は親の会話コンテキストをそのまま引き継ぎます。ただしその代わり、モデルは親から継承され、呼び出し時のmodel指定は無視されます（forkの定義自体が model: "inherit" になっています）。「親の文脈を引き継ぎつつ、別のモデルでレビューさせる」はできません。文脈かモデル切替か、どちらかです。

5. 呼び出し時のmodel指定はfrontmatterより優先

Agentツールには model パラメータがあり、これを渡すとエージェント定義のfrontmatterより優先されます。定義側で opus を指定していても、呼び出し側で sonnet を渡せばSonnetで動きます。

エージェント定義に書いたつもりのモデルで動いていないときは、呼び出し側で上書きしていないかを先に疑ってください。

6. effortが効かないモデルがある

effort はモデル側の対応が前提の設定です。Haiku 4.5はeffortをサポートしていません（Claude APIでも、Haiku 4.5 / Sonnet 4.5 に effort を渡すとエラーになります）。

つまり model: haiku のエージェントに effort: medium と書いても、その行は効きません。Claude Code側は未対応モデルを記録して黙って無視するので、エラーで気付くこともありません。書いてあるから効いている、とは限らないという例です。

Haiku 4.5はコンテキストウィンドウも200Kで、Fable 5 / Opus 5 / Sonnet 5 の1Mとは桁が違います。「大量のファイルを読ませる調査」を安いからとHaikuに投げると、途中で入り切らなくなります。Haikuに向くのは狭く決まった読み取りです。

コストの考え方

現時点の第一者APIの公開価格（100万トークンあたり）は次のとおりです。

Claude Codeをサブスクリプションで使っている場合は直接この金額を払うわけではありませんが、モデル間の相対的な重さの目安にはなります。設計にFableを置くのはSonnetの3倍強、調査をHaikuに落とすのはSonnetの1/3という感覚です。

冒頭の「Fableは往復の少ないところにだけ置く」を金額で見ると、こうなります。設計で数回×Fableと、実装で数十回×Sonnetでは、後者の方が総額を支配します。Fableの単価は、そのフェーズの呼び出し回数と掛け算になって初めて意味を持つので、往復数を見ずに単価だけで避けるのは判断を誤ります。総額に一番効くのは、往復回数が最も多いメインループのモデル選択です。

effort も同様にトークン消費に直結します。xhigh や max は思考トークンを大きく使うので、レビューや設計のように「1回あたりの正しさ」が支配的なフェーズに限定し、機械的な作業では low / medium に落とす、という切り分けが素直です。設計にFableを置くなら xhigh まで上げる価値がありますが、その組み合わせを実装フェーズまで広げると一気に効いてきます。

この構成が効くケース・効かないケース

効くのは、設計・実装・レビューが明確に分かれる規模のタスクです。複数ファイルにまたがる機能追加、リファクタリング、仕様が固まっていない機能の立ち上げ。ここでは設計の質が実装のやり直し量を決めるので、設計に重いモデルを置く価値が出ます。

効かないのは、typo修正や1行の設定変更のように、フェーズが分かれないタスクです。この場合、サブエージェントを起動するオーバーヘッド（フレッシュセッションが文脈を組み立て直すコスト）の方が、モデル差による品質向上を上回ります。何でもかんでも委譲すると、単に遅くて高くなります。

委譲するかどうかの判断基準は、**「そのフェーズの成果物が、親のコンテキストなしで書けるブリーフから作れるか」**です。作れないなら、委譲は向いていません。

まとめ

• モデル割当の設定箇所は2つ。メインループは .claude/settings.json の model / effortLevel、サブエージェントは .claude/agents/<name>.md のfrontmatter
• 呼び出しは、メインループが description を見て自動委譲するか、@agent-<名前> で明示指名するかの2通り。確度が要る場面は指名する
• サブエージェントは親の会話コンテキストを引き継がないフレッシュセッションとして起動する。ブリーフは自己完結させる
• read-onlyを担保したいなら model ではなく tools と permissionMode を指定する。Bash を許可している以上、実際に書き込みを止めているのは permissionMode: plan の方
• fork は親コンテキストを継承する代わりにモデル指定が無視される。文脈とモデル切替は両立しない
• effort はモデル側の対応が前提。Haiku 4.5では書いても効かない
• Fableは「高いから使わない」ではなく「往復の少ないフェーズにだけ置く」。単価は呼び出し回数と掛け算になって初めて効く
• やり直しコストが高いフェーズ（設計・レビュー）に重いモデルを、往復回数が多いフェーズ（実装）に中量モデルを、間違えてもすぐ気付けるフェーズ（調査）に軽量モデルを置く

まずは architect（Fable）と code-reviewer（Opus）の2つだけ作ってみるのが始めやすいと思います。この2つは「実装より上位の視点でチェックする」という役割が明確で、read-onlyに閉じられるぶん事故も起きにくく、かつ呼び出し回数が少ないので上位モデルを置いても総額が跳ねないためです。