TL;DR：三日前、私は「難度を定数・モデルの能力を変数として扱う」と書いた。この判断は今も変わらないが、見落としがあった。変わるのはモデルだけでなく、モデル間の協調方式も変わる。Anthropic の advisor 策略はこの層をちょうど補う。安価なモデルを主ドライバーとし、重要な判断点でだけ高価なモデルを顧問として呼び出す。公式ベンチマークによれば、最高性能モデルに近い品質を約六割のコストで達成できる。この記事は、前の記事で見落とした第二の変数を補うものだ。
昨日、X で Anthropic の公式投稿を目にした。その中に一枚の図があって、これが面白かった。安価なモデルがメインフローを処理し、重要な判断が必要なときだけ、より強くより高価なモデルを呼んでアドバイスをもらう。大半の token は安価なモデルのレートで処理される。
その図をしばらく見ていた。三日前に自分が公開したばかりの記事を、ちょうど突いていたからだ。
その記事のタイトルは〈難度を定数として扱う〉。私はそこで、モデル分配器にモデル名を直書きするべきではないと主張した。モデルの能力はシステム全体の中で最も変化しやすい要素だからだ。難度の分類を安定した層として保ち、「どのロールにどのモデルを使うか」は日付付きのバインディングテーブルとして切り出す。モデルが更新されたらそのテーブルだけ直す。
この主張は今も正しいと思っている。
だがその図を見て気づいた。前の記事でも、私は同じ過ちを犯していた。ただし間違いはモデルの層にあったのではなく、その上にある協調方式の層にあった。
advisor 策略とは何か：安価なモデルに運転させ、高価なモデルは交差点でだけ動かす
まず、その図の背景にあるものを説明したい。
Anthropic は四月に advisor tool という機能をリリースし、最近 Fable 5 も顧問として使えるようにした。仕組みはこうだ。安価で速いモデル（Sonnet か Haiku）が executor として最初から最後までタスクを担う。ツールを呼び出し、結果を読み込み、一歩ずつ答えに近づく。
executor が自分では判断しきれない場面に当たったとき、初めてより強い advisor に相談する。
advisor はコンテキスト全体を把握しているが、タスクを引き継ぐわけではない。返すのは一段の計画、一つの修正案、あるいは「止まれ」というシグナルだけだ。その後は executor が続きを走る。
つまり advisor はツールに触れないし、ユーザーへの最終的な回答を直接生成することもない。重要な瞬間にだけ方向を示す。
コストが下がる理由は一つの細部にある。顧問が一度に返すのは約 400 から 700 token の提案で、一つのタスク全体を通じて呼ばれるのもほぼ一回だけ。それ以外はすべて安価な executor のレートで処理される。
計算すると、大半の token は安価なレートを通り、本当にコストの高い判断力は重要な場面にだけ現れる。
私が見落としていた第二の協調方式：分解か、それとも相談か
ここに、当時気づけなかった分岐点がある。
分岐は「どのモデルを使うか」ではない。タスクを「下に分解する」べきか、それとも「上に相談する」べきかという問いだ。
〈難度を定数として扱う〉でモデル分配を論じていたとき、私の頭にあった協調方式は一種類だけだった。総合調整者が大きなタスクを小さなブロックに分解し、難度に応じて異なるモデルに割り振り、最後に検証と統合を行う。
これはトップダウンの orchestrator-workers だ。Anthropic の agent 設計ガイドに明確に書かれており、私もそれを引用して論拠としていた。
advisor 策略はその逆を行く。
Anthropic 自身の言葉を借りれば、「一般的なサブエージェントのパターン（大きな orchestrator がタスクを分解して小さな worker に分配する）を反転させた」ものだ。advisor では、安価なモデルが自ら走り、必要なときだけより強いモデルに上向きで相談する。
事前の分解も、worker pool も、スケジューリングロジックも要らない。
orchestrator は高価なモデルを上位に置いて指揮させる。advisor は安価なモデル自身に走らせ、最高級の知性は必要なときだけ借りてくる。
どちらも正しい。違いはタスクの形だ。
分割・並列化できて、難度にばらつきがあり、最後に強い頭脳が結果をまとめる必要があるタスクにはトップダウン分解が向く。
長い単一フローで、大半のステップは定型的だが、少数の判断点が結果を決定するタスクには、安価なモデルがメインドライバーとして走り続け、必要なときだけ強いモデルに相談する形が向く。
私は「マルチモデル分配」をまるで前者の一形態だけであるかのように書いていた。
公式データ：なぜ第二意見はコストと品質を同時に改善できるのか
直感的には、より強いモデルを追加で使えば必ずコストが上がると思うだろう。
だが特定のタスク形状においては、数字が逆を示す。
📊 重要なデータ
- Sonnet に Opus 顧問を組み合わせ：SWE-bench Multilingual で Sonnet 単独より 2.7 点高く、一問あたりコストは 11.9% 低下。
- Sonnet 5 に Fable 5 顧問を組み合わせ：Fable 単独のスコアの約 92% を獲得し、コストは約 63%。
- Haiku に Opus 顧問を組み合わせ：BrowseComp で 19.7% から 41.2% へ、ほぼ倍増。
なぜコストと品質を同時に改善できるのか。
正しい位置に置かれた第二意見が、安価なモデルの迷走による無駄を防ぐからだ。誤った方向に進んだり、同じ誤りを繰り返したりすると、ツール呼び出しが行き止まりの道に費やされる。品質と token が一緒に失われていく。
節約は二重になる。
だから Anthropic の推奨は実践的だ。自分の評価セットで三つのグループを走らせてほしい。安価なモデル単独、安価なモデルに顧問あり、最高性能モデル単独。感覚ではなく、自分のタスク種別における本当の境界を計測する。
本当の誤り：私は「協調方式」も不変の定数として扱っていた
自分自身に話を戻す。
前の記事の核心にある規律は一文で言えた。変わるものを、めったに更新されないルールに溶接してはならない。
モデル名を抽出して日付付きのバインディングテーブルに入れた。このステップは正しかった。
だがより上の層で、まったく同じことをやっていた。「協調方式」を不変の定数として暗黙に扱っていたのだ。
モデルの能力はきちんと変数として扱った。だが協調方式は黙って書き固めた。しかも協調方式はモデルより上流にある。
記事の全体が「マルチモデル分配とは高価な頭脳がトップダウンで指揮すること」という前提を置いてから、その前提の下でどのロールにどのモデルを割り当てるかを議論していた。
バインディングの層はよく考えた。協調方式の層は見落とした。なぜなら実際には、異なる問題には異なる協調方式が必要になるからだ。
この盲点は、v1 のバインディングテーブルにコストの地雷を埋め込んでいた。
当時最も高価だった Fable 5 を「総合調整者」のポジションに置いた。毎ターン呼ばれる位置だ。「高価なモデルを上位に置いて指揮させる」を信じているなら、この配置は自然に見える。
しかし advisor の協調方式を知ると、これが最もコストを燃やす配置だと分かる。
最も高価なモデルを、出現頻度が最も高いポジションに置いてはならない。
後でこれを修正した。Fable 5 を常駐の総合調整者から、重要な場面でだけ一度呼ばれる顧問に降ろした。
私が防ごうとしていたのはモデルが強くなることだった。本当に防げていなかったのは、協調方式が増えることだった。
モデルだけでなく、協調方式も確認する
〈難度を定数として扱う〉の中で最も力を入れて設計したのは、定期的な確認の仕組みだった。新しいモデルが出たら代表的なタスクセットを再実行し、あるロールをより安価なモデルに降ろせるかを確かめる。
この仕組みが確認するのは「モデルが変わったか」だ。だが今振り返ると、一つ問いが足りなかった。協調方式は変わっていないか？
元の確認機制が見ていたのは一つのことだけ（このロールは今どのモデルにバインドすべきか）だった。
だがより上流にある問いを問うことはなかった。私が前提にしている協調方式は、今も唯一の選択肢か？
モデルが強くなれば評価セットに痕跡が残るので捕捉できる。だがより効率的なやり方は、バインディングテーブルに自動で現れない。自分で見に行くしかない。
advisor 策略は四月にリリースされていた。私が一枚の図から気づいたのは七月だ。その三か月の間、分配器はモデルを一つも誤ってバインドしていなかった。
協調方式の選択肢が一つ欠けていただけで、私は何も気づかなかった。
だから今は確認の仕組みを二層に分けている。
下の層は変わらない。新しいモデルが出たらバインディングを再校正する。
上に一層加えた。定期的に問う。原本の分配前提を丸ごと描き直すような、新しい協調方式が登場していないか？
ルールに書き込むべきなのは、特定のモデル名ではなく、この一文だ。
協調方式を先に選び、それからモデルを選ぶ。
分解・並列化できて難度に差があるタスクには orchestrator-workers。単一スレッドで長く、少数の判断点が勝負を決めるタスクには executor-advisor。
これは、前の記事で最初のステップに置くべきだったのに、丸ごと抜け落ちていたものだ。
これもまた、「知性と秩序」という問いをめぐって私がずっと回り続けている同じ問題でもある。能力が急速に変化するとき、どうすれば持ちこたえる秩序を設計できるか。
〈難度を定数として扱う〉の結びにこう書いた。家を建てるついでに、非常口も一緒に建てておく。
三日後に気づいた。本当に確認すべきだったのはモデルテーブルではなく、協調方式についての自分の前提だった。
難度を定数として扱っておきながら、問うことを忘れていた。他に何を、暫定的に定数と誤認しているだろうか？
出典
本記事で述べた仕組みとデータは、Anthropic の公式資料に基づいている。
- Anthropic Developers（X 投稿）：本記事の冒頭で触れた、きっかけとなった advisor 策略の図の投稿。
- Anthropic、The advisor strategy：advisor 策略の定義、「orchestrator-workers を反転させた」という表現の出典、Sonnet に Opus 顧問を組み合わせた SWE-bench Multilingual および BrowseComp の実測値。
- Anthropic、Advisor tool（Claude Platform Docs） および Claude Code Docs：advisor tool の動作、モデルペアリングのルール、バージョンとプラットフォームの制約。
- Anthropic、Building Effective Agents：orchestrator-workers というトップダウン分解の workflow パターン。
- Anthropic、Claude Fable 5 および Platform 料金：Fable 5 の位置づけと Opus に対する価格差。
💬 コメント
読み込み中...