Claude Fable 5のアドバイザーパターン入門｜Sonnet 5実行役が要所だけ相談しトークン代を抑える

アドバイザーパターン——安くて速い「実行役」モデルに、高性能な「相談役」モデルをオンデマンドで持たせる、この役割分担の設計が、いま Claude を使う開発者の間で注目されている。「AIエージェントの品質は上げたい、でもトークンコストは抑えたい」という綱引きに、第三の答えを与えるからだ。いちばん賢いモデルを全部の作業に使えば品質は上がるが料金は跳ね上がり、逆に安いモデルだけで回せば料金は下がるが設計判断のような難所で頭打ちになる。この二択に対して、Anthropicの開発者向け公式アカウント @ClaudeDevs が、米国時間2026年7月7日に短い投稿で示した使い方——それがアドバイザーパターンだ。

投稿の要点はこうだ——「Fable 5をアドバイザー（advisor）として使う。実行役（Sonnet 5）がFable 5に助言を求める。大半のトークンは、安いほうの実行役レートで課金される」。添付図には、毎ターン回る実行役（Sonnet 5）から相談役（Fable 5）へ「Tool call」の矢印が伸び、相談役から「Sends advice」で助言が返る様子が描かれている。この記事では、この一言に凝縮されたパターンの中身を日本語で噛み砕く。「なぜ料金が下がるのか」「実行役と相談役に何を任せるのか」「Anthropic公式のツールとしてどう実装されているのか」を、公式の価格表とツール仕様という一次情報を軸に、今日から試せる粒度まで降りていく。

いま注目される「アドバイザーパターン」— @ClaudeDevsが示した使い方

まず発信元を押さえておく。@ClaudeDevs は Anthropic が運営する、開発者向けの公式アカウントだ（プロフィールに「Official updates for developers building with @ClaudeAI」とある）。つまり、モデルとツールを作っている当事者が、公式の立場から「自分たちが頻繁に使っているパターン」として共有した、という位置づけになる。個人の一開発者が思いつきで薦めたのではなく、作り手が実運用で使っている使い方だからこそ、参考にする価値がある。

投稿の原文は短い。要約すると「Fable 5 とよく使うパターンがいくつかある。ひとつは Fable 5 を『アドバイザー』として使うこと。実行役（Sonnet 5）が Fable 5 に助言を求める。大半のトークンは、より安い実行役のレートで課金される」というものだ。ここで鍵になる登場人物が2つある。実行役（executor） と 相談役（advisor） だ。

Fable 5 をアドバイザーとして使う。実行役（Sonnet 5）が Fable 5 に助言を求める。大半のトークンは、より安い実行役のレートで課金される。
原文：“Use Fable 5 as an ‘advisor.’ An executor (Sonnet 5) calls Fable 5 for guidance. Most tokens are billed at the lower executor rate.”（@ClaudeDevs, 2026-07-07）

この背景には、Anthropic のモデルラインナップの広がりがある。いまや同社のモデルは、最も高性能な Fable 5、Opus 級の主力 Opus 4.8、速度と知能のバランスに優れた Sonnet 5、最速の Haiku 4.5 と、能力と価格の異なる層が揃っている。Fable 5 は同社が「最も高性能な、広く提供するモデル」と位置づけるモデルで、長時間の自律的な作業と最も要求の厳しい推論に向く（詳しくは Claude Fable 5 とは何かをまとめた解説 を参照）。層が増えたということは、「どのモデルを、どの作業に割り当てるか」という設計の余地が生まれた、ということでもある。アドバイザーパターンは、その割り当ての具体的な一手だ。

なぜいまこの話が響くのか。エージェントを長時間・自律的に走らせる使い方が広がり、「1回のプロンプトに最適な文を書く」よりも「ループを回し続ける仕組みを設計する」ことへ関心が移ってきたからだ（この流れ自体は Claude Code のループ設計入門 で整理した）。ループを長く回すほどトークン消費は積み上がる。だからこそ「どのモデルに、どれだけの物量を流すか」というコスト設計が、品質と同じくらい重要になる。アドバイザーパターンは、この「回し続ける時代」のコスト設計として理にかなっている。

アドバイザーパターンとは — 実行役と相談役を分ける

アドバイザーパターンの骨格は、驚くほどシンプルだ。1つのエージェントに、役割の違う2つのモデルを持たせる。ひとつは毎ターン走る 実行役（executor）、もうひとつは要所だけ呼ばれる 相談役（advisor） である。実行役は安くて速いモデル（例：Sonnet 5）、相談役はそのタスクで最も賢いモデル（例：Fable 5）を割り当てる。

料理の現場にたとえると分かりやすい。実行役は、仕込みから盛り付けまで手を動かし続ける 調理担当 だ。ほとんどの工程は自分で判断して進める。相談役は、店の奥にいる 料理長 にあたる。普段は出てこないが、「このソースの方向性で合っているか」「この食材の組み合わせは成立するか」といった、味の核心にかかわる判断のときだけ、調理担当が相談に行く。料理長は毎皿には触らないが、要所の判断だけを与えて全体の質を底上げする。実行役と相談役の関係は、これに近い。

@ClaudeDevs の添付図は、この関係を的確に描いている。左に 実行役（Sonnet 5） の箱があり、そこに「Main loop（メインループ）」と「Runs every turn（毎ターン走る）」というラベルが付き、自分自身へ戻る矢印が回っている。右に 相談役（Fable 5） の箱があり、「On-demand（オンデマンド）」とある。両者をつなぐのは2本の矢印だ——実行役から相談役へ「Tool call（ツールコール）」、相談役から実行役へ「Sends advice（助言を返す）」。実行役が主役として回り続け、相談役は呼ばれたときだけ顔を出す。この非対称性が、このパターンの核心である。

ここで、なぜ「2つに分ける」ことに意味があるのかを、両極端と並べて確かめておく。

表の要点は右端の行だ。全部を最上位モデルにすると、単純な物量作業にまで高い単価がかかる。全部を安いモデルにすると、設計判断のような難所で品質が頭打ちになる。アドバイザーパターンは、その中間ではなく 「良いとこ取り」を狙う——物量は安いモデルに流し、賢さが要る要所だけ最上位モデルに相談する。難所が「時々」混じるタイプの長時間作業ほど、この配分が効いてくる。

なぜトークン代が下がるのか — 課金の内訳を分解する

このパターンの経済性は、「エージェントが1回のループで生む仕事の内訳」を見ると腑に落ちる。長時間のエージェント作業を分解すると、その大半は 物量は多いが高度な判断は要らない作業 だ——ファイルを読む、コマンドを走らせる、修正を当てる、テストを回す、また少し直す。この繰り返しがトークン消費の大部分を占める。一方で、少量だが難しい判断 は要所に散在する——「この設計方針で合っているか」「なぜ詰まったのか」「次にどの一手を打つか」。この2種類は、量も、必要な賢さも、まるで違う。

アドバイザーパターンは、この2種類を 別々のモデルに振り分ける。物量の多い作業は安い実行役へ、少量の難しい判断は高い相談役へ。相談役が呼ばれるのは要所だけなので、相談役のトークンは全体のごく一部にとどまる。だから、請求の内訳は自然と 安い実行役のレートに寄る。@ClaudeDevs の「大半のトークンは安い実行役レートで課金される」という一文は、まさにこの構造を指している。

具体的な価格差を押さえておこう。Anthropic の公式価格（1リクエストではなく100万トークンあたり）は次の通りだ。

標準価格で見ると、Fable 5 の出力単価（$50）は Sonnet 5 の出力単価（$15）の 約3.3倍 だ。Sonnet 5 には導入価格（2026年8月31日まで入力$2・出力$10）があり、これを基準にすると差は約5倍まで開く。つまり、もし全作業を Fable 5 で回していたなら、その物量部分を Sonnet 5 に移すだけで、その分の単価が3分の1前後に下がる計算になる。相談役として Fable 5 に払う高単価は、要所のわずかなトークンにしか乗らない。

ごく単純な数値でイメージを掴んでおこう。あくまで説明のための仮定だが、あるタスクで生成トークンの9割が物量作業、1割が相談だったとする。全部を Fable 5（出力$50）で回すと、この配分は関係なく全量が$50レートで課金される。これをアドバイザーパターンにして、物量の9割を Sonnet 5（出力$15）へ、相談の1割だけ Fable 5 に残すと、加重平均の単価は「$15×0.9＋$50×0.1」で約$18.5 に下がる。同じ仕事量でも、単価の平均が$50から$18.5へ、およそ6割落ちる計算になる。もちろん実際の比率はタスク次第だが、「物量をどれだけ安い側に寄せられるか」が節約幅を決める、という関係ははっきりしている。

もう少し直感的に言えば、「賢さの単価」を、賢さが本当に要る場所にだけ払う ということだ。物量作業に最上位モデルの単価を払うのは、料理長に皿洗いをさせて時給を払うようなものだ。皿洗いは調理担当に任せ、料理長には味の判断だけを頼む。同じ人件費でも、どこに高い時給を割り当てるかで総額は大きく変わる。トークン課金も、これと同じ発想で最適化できる。

Anthropic公式の「Advisorツール」— パターンを製品化した仕組み

アドバイザーパターンは、自分で実装することもできる——実行役のモデルに「相談役に助言を求める」ツールを1つ持たせ、そのツールが呼ばれたら相談役のモデルを別途叩いて、返ってきた助言を実行役に渡す。@ClaudeDevs の図の「Tool call」「Sends advice」は、まさにこの往復を描いている。

ただし Anthropic は、この実行役／相談役の分担を API の『Advisor（アドバイザー）ツール』 としても製品化している（本記事執筆時点でベータ）。仕組みはこうだ——リクエストの最上位に指定する model が 実行役、ツール定義の中に書く model が 相談役 になる。実行役が生成を進める途中で、方針の相談が必要になると相談役が呼ばれ、戦略的な助言が返る。トークン生成の大部分は実行役が担い、相談役は計画づくりのために参照される。自前でツールコールの往復を組まなくても、この分担が1つのツールとして扱えるようになっている。

このツールには、守るべき組み合わせのルールがある。相談役のモデルは、実行役のモデルと同等以上の能力でなければならない。実行役より弱いモデルを相談役に据える逆転した組み合わせは、エラーとして弾かれる。理屈は明快だ——相談役は「より賢い立場から助言する」役なので、実行役より賢くなければ相談する意味がない。@ClaudeDevs の例（実行役 Sonnet 5／相談役 Fable 5）は、この「相談役のほうが賢い」条件をきちんと満たしている。

利用できる環境には現時点で制約がある。このツールは Claude の API（第一者）と Claude Platform on AWS ではベータとして使えるが、Amazon Bedrock・Google Vertex AI・Microsoft Foundry といった一部のクラウド経由では提供されていない。そうした環境では、前述のとおり 実行役から相談役の API を自前のツールコールとして呼ぶ 形で、同じ役割分担を組み立てればよい。パターンの本質は「実行役が要所で相談役に助言を求める」という往復にあり、それを公式ツールで実現するか自前で組むかは、実装上の選択にすぎない。

なお、Fable 5 を相談役に据える場合は、Fable 5 特有の性質もいくつか押さえておきたい。Fable 5 は常に思考（thinking）がオンで、生の思考過程は返らず要約だけが得られること、安全分類器によって特定領域の要求が拒否されることがあること、そして価格が Opus 4.8 の2倍であることなどだ（この辺りは Claude Fable 5 とMythos 5 の入門解説 にまとめている）。相談役は要所でしか呼ばれないとはいえ、1回の助言が高価であることは変わらないので、「本当に相談が要る場面」を絞る設計が効いてくる。

実行役に任せること・相談役に投げること

パターンの効果は、結局「何を実行役に任せ、何を相談役に投げるか」の線引きで決まる。ここを曖昧にすると、相談役を呼びすぎてコストが膨らむか、逆に相談役を使わなさすぎて品質が頭打ちになる。両者の持ち場を、もう一段具体的に整理しておく。

実行役に任せるのは、手を動かす作業の本体 だ。ファイルを開いて中身を読む、指示に沿ってコードを書き換える、テストやビルドを走らせて結果を確かめる、失敗したらもう一度直す——こうした「経路がある程度見えている作業」は、速くて安い実行役が得意とする領域だ。ここに賢さの最上位は要らない。むしろ、素直に手を動かして反復してくれる速さのほうが効く。

相談役に投げるのは、立ち止まって考えるべき判断 だ。「このアーキテクチャで進めていいか」「同じエラーで3回詰まっているが、根本原因はどこか」「実装した変更を、別の視点でレビューしてほしい」——こうした「一手間違えると後戻りが大きい」局面こそ、最も賢いモデルの出番になる。とりわけ、実行役が自分で書いたコードを実行役自身にレビューさせると、生成時の思い込みをそのまま引きずりやすい。新しい文脈から判断する相談役にレビューを任せると、素の目でコードを読めるという利点もある。この「作る主体と評価する主体を分ける」考え方は、ループ設計における generator と evaluator の分離とも重なる（詳しくは Claude Code のループ設計入門 を参照）。

大事なのは、この線引きが タスクによって変わる ことだ。難所が少ない定型作業なら、相談役はほとんど呼ばれず、実行役だけでほぼ完結する。逆に、新規性が高く判断の連続するタスクなら、相談役の出番は増える。固定のルールを暗記するのではなく、「いま直面しているのは、手を動かす作業か、立ち止まる判断か」を都度見分ける——その仕分けの感覚こそが、このパターンを使いこなす勘所になる。

ケースで見る：大規模リファクタの1周を追う

抽象論だけでは掴みにくいので、ひとつのタスクを1周ずつ追ってみる。たとえば「あるモジュール群を新しい API に一括で移行する」大規模リファクタを、アドバイザーパターンで進める場面を考える。

1. 観測（実行役）：実行役の Sonnet 5 が、移行対象のファイル群を読み、旧 API の使われ方をひととおり把握する。ここは物量が多いが、判断は要らない
   
2. 実行（実行役）：機械的に置き換えられる箇所から、実行役が淡々と書き換えていく。テストを走らせ、通ればそのまま次のファイルへ進む。この反復が作業時間の大半を占める
   
3. 相談（相談役）：途中で「旧 API のこの引数は新 API に対応物がなく、挙動が変わりうる」という判断の分かれ目に出くわす。ここで初めて、実行役がツールコールで相談役の Fable 5 に「この非互換をどう吸収すべきか」と助言を求める
   
4. 助言（相談役）：相談役が、互換レイヤーを挟む案とインターフェースを変える案の得失を返す。実行役はその助言を受けて方針を決め、また手を動かす作業に戻る
   
5. 検証（実行役）：一通り移行し終えたら、実行役がテスト全体を回して緑を確認する。最後にもう一度、相談役に「移行漏れや退行のリスクが残っていないか」をレビューさせる、という使い方もできる

この1周で相談役が呼ばれたのは、手順3と、最後のレビューの2回だけだ。手順1・2・5の物量作業はすべて安い実行役が担っている。だからこのタスク全体で見ても、Fable 5 に高単価を払うのは「非互換の判断」と「最終レビュー」という要所だけに絞られ、残りの大部分は Sonnet 5 の安いレートで回る。もしこの移行を丸ごと Fable 5 で走らせていたら、機械的な置き換えの物量にまで最上位の単価がかかっていたはずだ。「賢さが要る2回」と「手を動かす大多数」を別のモデルに振り分ける——アドバイザーパターンの効き目は、この1周を追うと具体的に見えてくる。

日本の開発現場でアドバイザーパターンをどう使うか

ここまでの仕組みを、日本の開発チームがどう取り入れるか。結論から言えば、まずは難所が”時々”混じる長時間タスクから試すのがよい。1往復で終わる短い作業に持ち込んでも、相談役を挟む手間とレイテンシだけが増えて割に合わない。効くのは、物量が多く、その中に設計判断のような難所が点在する作業だ。

具体的な入口としては、次のような割り当てが考えられる。大規模なコード移行では、実行役が機械的な書き換えを延々と進め、移行方針や互換性の判断が要る節目だけ相談役に相談する。長時間の自律的なコーディングでは、実行役が実装と検証を回し、「詰まったとき」「大きな設計判断のとき」だけ相談役を呼ぶ。バグ調査では、実行役がログ収集と再現を担い、原因の仮説立てと切り分けの方針を相談役に投げる。いずれも「手を動かす本体は安いモデル、方向を決める要所は賢いモデル」という同じ骨格だ。

導入にあたっては、いきなり本番の大規模タスクに適用しない ことをすすめたい。まずは小さなタスクで、相談役が「いつ・どれくらいの頻度で」呼ばれるかを観察するとよい。呼び出しが多すぎればコストが想定を超えるし、少なすぎれば品質面のメリットが出ない。Anthropic 公式ツールを使う場合でも、自前でツールコールを組む場合でも、使用量（トークンの内訳）を可視化しながら、相談役を呼ぶ条件を少しずつ調整していくのが安全だ。コストと品質のちょうどいい配分は、タスクの性質によって変わるので、一度で決め打ちにせず、試走で手触りを掴むのが定石になる。

もうひとつ、誠実に付け加えておきたい制約がある。アドバイザーパターンは万能の節約術ではない。難所が連続するタスクでは相談役の出番が増え、単独で Fable 5 を使うのと料金が近づいていく。また、モデルをまたいで相談させる分だけ、実装の複雑さやレイテンシは増える。「安いモデルを主役に、賢いモデルを助言役に」という発想が効くのは、あくまで 作業の大半が物量で、賢さが要る部分が一部に偏っている ときだ。自分のタスクがその形になっているかを、着手前に一度見極めたい。この見極めさえできれば、アドバイザーパターンは「品質を諦めずにコストを下げる」現実的な選択肢になる。

他のモデル使い分けパターンとの違い

アドバイザーパターンは、いくつかある モデル使い分け の設計のひとつだ。能力と価格の異なるモデルが揃ったことで、「1つのタスクを複数モデルで分担する」やり方が現実的になった。アドバイザーパターンの立ち位置を掴むために、近い発想の他のパターンと並べておく。どれも狙いは共通で、「賢さの単価を、賢さが要る場所にだけ払う」ことにある。違うのは、どちらを主役に置くかだ。

サブエージェント委譲 は、賢い司令塔モデルが主役として推論を担い、探索や並列処理といった物量作業を、安いモデルのサブエージェントに切り出す。Anthropic のエージェント設計ガイドでも、メインループを1つのモデルに保ちつつ、コストを抑えたいサブタスクだけ安いモデルのサブエージェントに投げる手法が紹介されている。アドバイザーパターンはこれと 主客が逆 だ——主役は安い実行役で、賢いモデルはあくまで助言役にとどまる。だからこそ「大半のトークンが安いレートで課金される」構図になる。

エスカレーション は、まず安いモデルで進め、行き詰まったら賢いモデルに引き上げる、段階的な使い分けだ。アドバイザーパターンは、引き上げて主役を交代させるのではなく、安いモデルを主役に据えたまま賢いモデルに「相談だけ」する点が異なる。実行役はループの運転席に座り続け、相談役は助手席から要所で口を出す、というイメージに近い。

技術的にも、この「主役を交代させない」ことには利点がある。会話の途中でモデルを切り替えると、それまで積み上げたプロンプトキャッシュ（同じ前置きを再利用してコストと遅延を下げる仕組み）が無効になる。アドバイザーパターンでは、実行役のメインループは同じモデルのまま走り続け、相談役は別枠のツールコールとして呼ばれる。だから実行役側のキャッシュは生き残りやすく、トークンコストの面でも素直だ。モデル使い分けを設計するときは、こうした「切り替えのコスト」まで含めて、どのパターンが自分のタスクに合うかを見極めたい。

まとめ — 賢さは要所に、物量は安いモデルに

@ClaudeDevs が示したアドバイザーパターンは、「最強モデルを全部に使うと高い」「安いモデルだけだと要所で頭打ち」という二択に、第三の答えを与えるものだった。安くて速い実行役（Sonnet 5）が毎ターンの物量作業を回し、高性能な相談役（Fable 5）は要所でツールコールに応じて助言を返す。相談役の出番は少ないので、請求の大半は安い実行役のレートに寄る——これが「大半のトークンは安い実行役レートで課金される」という一言の中身だ。

このパターンの本質は、「賢さの単価」を、賢さが本当に要る場所にだけ払う という配分の思想にある。物量作業に最上位モデルの単価を払うのは、賢さを持て余す。逆に、難所を安いモデルだけで押し切ろうとすると、堂々巡りでかえってトークンを浪費する。実行役と相談役の線引き——「手を動かす作業か、立ち止まる判断か」——を見極めることが、そのままコストと品質の両立につながる。

Anthropic がこの分担を Advisor ツールとして製品化していることは、これが思いつきの節約術ではなく、作り手自身が実運用で使っている設計であることを裏づけている。モデルの層が増え、エージェントを長時間回す使い方が広がったいま、「どのモデルに、どれだけの物量を流すか」というコスト設計は、品質の設計と同じくらい重要になった。難所が時々混じる長時間タスクを抱えているなら、まず小さなスライスで、実行役に Sonnet 5、相談役に Fable 5 を割り当てて走らせてみる。相談役が要所だけ顔を出し、残りが安く回っていく様子を一度見れば、「賢さは要所に、物量は安いモデルに」という配分が、抽象論ではなく手触りのある実感に変わるはずだ。

参照ソース

・@ClaudeDevs — 「Fable 5 をアドバイザーに使う」投稿（Anthropic公式・開発者向け, 2026-07-07）
・Introducing Claude Fable 5 and Claude Mythos 5（Anthropic公式, 2026-06-09）
・Tool use overview（Claude Docs）
・Pricing（Claude Docs）
・Claude Fable 5 とMythos 5 入門（AI Heartland 解説）
・Claude Code のループ設計入門（AI Heartland 解説）
・Claude for Open Source 解説（AI Heartland 解説）