AnthropicがClaude Codeに新たなモデル連携パターンを導入しました。
SonnetやHaikuを実行役（Executor）として使い、判断に迷った場面だけOpusに相談する。
これが「Advisor」パターンです。
Redditでもこの機能が話題になっていました。
賛否を含めた興味深い議論が交わされています。
本記事では、その議論を踏まえつつ、この仕組みの意義を整理してみます。
従来のOpusPlanとの違い
Claude Codeには以前から「OpusPlan」という機能がありました。
Opusが計画を立て、Sonnetがその計画に沿って実装を進める仕組みです。
つまり、Opusが「上司」として全体を指揮するモデルでした。
今回のAdvisorパターンは、この関係を逆転させています。
主役はあくまでSonnetやHaikuです。
普段の処理はこれらの軽量モデルが担当します。
そして、自力では判断が難しいと感じたときだけOpusに助言を求めるのです。
いわば「困ったときに電話できる先輩」のような存在として、Opusを配置する発想と言えるでしょう。
Reddit上のあるコメントでは、この違いを「制御の反転（Inversion of Control）」と表現していました。
OpusPlanではOpusが実行をSonnetに委譲します。
一方、Advisorパターンでは実行側のSonnetが深い判断をOpusに委譲する。
方向が真逆なのです。
GPT-5のルーターとの比較
この仕組みを見て、OpenAIのGPT-5との類似性を指摘する声もありました。
GPT-5は内部で複数の推論レベルを持っているとされています。
そして、隠れたルーターモデルがクエリの難易度に応じて振り分けを行っているようです。
ただし、両者には重要な違いがあります。
GPT-5のルーティングはブラックボックスです。
ユーザーからは制御できません。
一方、AnthropicのAdvisorパターンでは、開発者がモデル選択の判断プロセスに関与できる余地がある。
実務で使う立場からすると、この透明性の差は小さくないでしょう。
あるRedditユーザーは、さらに踏み込んだ提案もしていました。
Haikuがルーティングまで担当し、自力で対応できなければSonnetへ、それでも難しければOpusへとエスカレーションする仕組みです。
こうなれば、さらに使い勝手が良くなるかもしれません。
「ドリフト」問題は解決されるのか
興味深い反論も出ていました。
LLMには「ドリフト」と呼ばれる現象があります。
長い対話の中で、モデルが元の指示や方針から徐々にずれていく傾向のことです。
この議論を提起したユーザーは、ドリフトを「普遍的な定数」だと主張していました。
人間だって同じです。
「もっと手早くやろう」「近道がないか」と考えてしまう。
それを防ぐために、マニュアルや上司のチェックといった外部のハーネスが存在します。
LLMのドリフトも同様で、モデル内部の改善では根本的に解決できないという論理です。
これに対して反論もありました。
「では科学者や開発者がドリフト対策に取り組むこと自体が間違いなのか？」と。
ドリフトが完全には排除できないとしても、軽減する努力には価値があるはずです。
人間の組織マネジメントにおいても、同じことが言えるでしょう。
コスト削減効果への疑問
Anthropicは「Opus相当の知性を低コストで」と謳っています。
しかし、公式発表によるとコスト削減幅は約12%程度とのこと。
「コストのほんの一部で」という表現に対して、やや誇張ではないかという指摘もRedditでは見られました。
また、Maxプラン（月額200ドル）の利用者からも声が上がっています。
Opusへの通常のプロンプト1回で、4時間の利用制限の大部分を消費してしまうというのです。
Advisorパターンがこの制限の中でどう機能するのか。
実際のユーザーにとっては切実な問題でしょう。
マルチエージェントワークフローとしての位置づけ
既にマルチエージェントワークフローを構築している開発者からは、別の視点もありました。
「これは以前から自前でやっていたことだ」という声です。
複数のモデルを組み合わせ、得意分野に応じてタスクを振り分ける手法自体は新しくありません。
しかし、プラットフォーム側が公式にサポートする点には価値があります。
モデル選択の複雑さを抽象化してくれるからです。
すべての開発者がマルチエージェントのオーケストレーションを自前で構築できるわけではありません。
まとめ
Advisorパターンは、AIエージェント開発におけるモデル連携の一つの方向性を示しています。
すべてを最高性能のモデルに任せるのではなく、軽量モデルを主軸に据える。
そして、必要なときだけ上位モデルを呼び出す。
この考え方は、コストと性能のバランスを取る上で理にかなっています。
一方で、検証すべき点も残っています。
実際のコスト削減効果、ドリフトへの耐性、既存のOpusPlanとの使い分けなどです。
新しい仕組みに飛びつく前に、自分のユースケースに本当に合っているかを見極めることが大切でしょう。
この分野は変化が速く、数ヶ月後にはまた違ったアプローチが主流になっているかもしれません。
重要なのは、個々のパターンの優劣を議論することよりも、なぜそのパターンが生まれたのかという背景を理解しておくことではないでしょうか。
