Claude Managed Agents のアドバイザーは、セッションの主スレッドがターンの途中で自分と同等以上の性能のモデルに戦略的な助言を求められる仕組みです(2026 年 8 月時点)。
📖 この記事で分かること
- Managed Agentsに追加されたアドバイザーの設定方法
- エージェントとアドバイザーの性能の上下関係の制約
- 助言が伏せ字になるモデルと読めるモデルの違い
- 相談回数を抑える手段が無いという費用面の注意
💡 知っておきたい用語
- アドバイザー: エージェントが作業の途中で「これでいいか」と相談できる、自分と同格以上の相談役モデル。部下に作業を振るのではなく、上司に判断を仰ぐ側の仕組み
最終更新日: 2026年8月9日
▶ 公式ページ
- Give the session an advisor(Claude Platform ドキュメント)
- Advisor tool(Claude Platform ドキュメント)
- Claude Platform リリースノート(Claude Platform)

Claude Managed Agents にアドバイザーが載った
この記事のポイント
- Anthropicが2026年8月7日、Claude Managed Agentsにアドバイザーを追加しました(2026年8月時点)。
- セッションの主スレッドが、ターンの途中で同等以上の性能のモデルに助言を求められます。
- Claude Opus 5(2026年8月時点)をアドバイザーにすると、助言の中身はクライアント側に届きません。
Anthropicは2026年8月7日、Claude Managed Agentsのセッションに「アドバイザー」を設定できるようにしました。セッションの主スレッドが、ターンの途中で戦略的な助言を求められる相手です。方針を立てる、行き詰まりから抜ける、仕上げ前に成果物を点検する、といった場面が想定されています。
マルチエージェント構成の委譲は通常、コーディネーターが下位のエージェントに作業を振る方向に働きます。アドバイザーはその逆で、自分と同格か、それより高性能なモデルに判断を仰ぎます。
なお、Messages API【エーピーアイ】側のサーバツールとしてのアドバイザーは2026年3月にパブリックベータで先行提供されていました。8月7日に新しくなったのは、これがManaged Agents側にエージェント設定の一項目として載った点です。ツール定義ではなく設定で与える形になり、助言の届き方も変わりました。
設定は2つのフィールドだけ、ただし性能の上下関係に制約がある
設定はエージェントのmultiagent.agentsロスターに1件追加するだけです。フィールドはtypeとmodelの2つしかありません。
{"type": "advisor", "model": "claude-opus-5"}
ロスターに置けるアドバイザーは最大1件です。このエントリは予約名anthropic.advisorを占有するため、同じ名前のメンバーを同時に列挙すると400バリデーションエラーになります。
モデルの組み合わせには制約があります。アドバイザーは最低でもClaude Sonnet 4.6以上の性能が必要で、かつエージェント自身のモデルがアドバイザーより高性能であってはいけません。同等同士のペアは許可されており、Claude Opus 4.7とClaude Opus 4.8は互いに助言できます。不正なペアはエージェントの保存時点で400バリデーションエラーとして弾かれます。
アドバイザーはロスター上のエージェントとしては扱われません。コーディネーターのlist_agentsツールからは見えず、send_to_agentで送ることもできません。相談できるのはセッションの主スレッドだけで、ロスター上の他のエージェントは相談できない仕様です。
助言が読めるかどうかは、選んだモデルで決まる
実務でいちばん効くのはここです。助言の中身をクライアント側で読めるかどうかが、アドバイザーに選んだモデルによって変わります。
Claude Opus 5、Claude Fable 5、Claude Mythos 5をアドバイザーにすると、結果は伏せ字の変種になります。クライアントに届くのは[{"type": "redacted"}]というプレースホルダだけで、助言の本文は表示されません。エージェント本体はサーバ側で全文を読んで動くため、動作自体には影響しません。読めないのは運用者側です。
助言のテキストをイベントストリーム上で確認したい場合は、アドバイザーにClaude Opus 4.8を選びます。こちらは平文の変種を返します。なお、アドバイザーの思考過程はどのモデルを選んでも表面化しません。
動作の流れも押さえておく価値があります。相談ごとにanthropic.advisorという名前のスレッドがプラットフォーム側で生成され、終わると自分で終了します。助言はagent.thread_message_receivedイベントとして主スレッドに届きます。相談の入力はエージェントではなくプラットフォームが組み立てるため、agent.tool_useイベントは発生せず、agent.thread_message_sentもセッションのイベントストリームには現れません。
到着順にも注意が必要です。助言の配送が、アドバイザースレッドのidleやterminatedのイベントより先に届く保証はありません。これらのイベントを「助言はもう届いた」という合図として扱うと取りこぼします。
相談が失敗したり中断したりしても、エージェントのターン自体は失敗しません。失敗した旨の一般的な通知が入ったあと、エージェントは処理を続けます。
費用は抑えにくく、可観測性とのトレードオフが残る
相談はアドバイザーモデルのレートで課金され、そのトークンはアドバイザースレッドの使用量とセッション全体の使用量の両方に計上されます。アドバイザー側のプロンプトキャッシュは自動で動き、設定項目はありません。
ここでManaged Agents版とMessages API版の差が効いてきます。Messages APIのアドバイザーツールにはmax_uses、max_tokens、cachingのフィールドがありますが、Managed Agentsのロスター項目にはいずれもありません。つまり相談の回数や1回あたりの出力量を、この機能自体では抑えられません。費用の歯止めは、同日に追加されたセッション予算のような別の手段に頼ることになります。
アドバイザースレッドは、セッションの同時スレッド上限である最大25の対象外です。スレッド一覧には、主スレッドをparent_thread_idとする形で現れます。
8月7日のClaude Platformの更新は、このアドバイザーを含めて4件でした。ほかはセッション単位のドル建て上限を設けるセッション予算、推論の実行地域を指定するinference_geo、マウントしたリポジトリのルートの.claude/skillsからスキルを自動検出する機能です。
編集部の見方
編集部は、Managed Agentsでアドバイザーを試すなら、最初に置くべきはClaude Opus 5ではなくClaude Opus 4.8だと考えます。
- 根拠1: Opus 5、Fable 5、Mythos 5は伏せ字の変種を返し、クライアントには
[{"type": "redacted"}]しか届きません。助言がエージェントの判断をどう変えたのかを、運用者が後から検証できなくなります。 - 根拠2: Managed Agentsのロスター項目には
max_usesが無く、相談回数を機能側で止められません。中身が読めず回数も抑えられない組み合わせは、費用が伸びたときに理由を説明できません。 - 根拠3: 相談はアドバイザーモデルのレートで課金され、セッション全体の使用量に積み上がります。最上位モデルを常時相談役に置く構成は、単価の面でも慎重に始める価値があります。
この見方が変わる条件は、伏せ字の変種でも助言の要約やメタ情報がイベントに載るようになった場合です。検証の手がかりが残るなら、最初から最上位モデルを相談役に置く判断に傾きます。
よくある質問
Q: エージェントより高性能なモデルをアドバイザーにしないといけませんか
A: 同等でも構いません。エージェント自身のモデルがアドバイザーより高性能でなければよく、Claude Opus 4.7とClaude Opus 4.8のような同格のペアは互いに助言できます。ただしアドバイザーはClaude Sonnet 4.6以上の性能が必要です。
Q: 助言の内容をログに残せますか
A: アドバイザーに選んだモデル次第です。Claude Opus 4.8なら平文で届きます。Claude Opus 5、Claude Fable 5、Claude Mythos 5は伏せ字の変種になり、クライアント側からは本文を読めません。
Q: 相談の回数に上限を設定できますか
A: Managed Agentsのロスター項目にはmax_usesがないため、この機能単体では設定できません。Messages API側のアドバイザーツールにはmax_usesがあります。
まとめ
Anthropicは2026年8月7日、Claude Managed Agentsのセッションに同等以上の性能のモデルを相談役として置けるようにしました。設定はtypeとmodelの2フィールドのみで、ロスターに1件だけ追加できます。実務上の分かれ目は、アドバイザーに選ぶモデルによって助言がクライアントから読めるかどうかが変わる点と、相談回数を機能側で制限する手段が無い点です。安いモデルで大量に回して要所だけ格上に相談する構成は組みやすくなりましたが、費用と検証可能性の設計は利用者側に残されています。
Managed Agentsの経営判断への影響については、以下の記事もあわせてどうぞ:
【用語解説】
- 主スレッド: セッションの中心となる会話の流れ。アドバイザーに相談できるのはこの主スレッドだけで、下位のエージェントからは相談できません
- ロスター: エージェントが誰に仕事を振れるかを列挙した名簿にあたる設定。アドバイザーもこの名簿の一項目として登録します
- バリデーションエラー: 設定内容が仕様に反しているときに、保存の時点で拒否される種類のエラー。今回は不正なモデルの組み合わせや予約名の衝突で発生します
引用元:
- [1] Give the session an advisor(Claude Platform ドキュメント)
- [2] Advisor tool(Claude Platform ドキュメント)
- [3] Claude Platform release notes(Claude Platform)
この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。
Previous Post
Codex CLIのfull-autoが非推奨に。既存スクリプトは書き換えが必要
Next Post
生成AIニュースまとめ 先週【2026年8月3日(月)〜8月9日(日)】のAI公式発表を5分でチェック
15 年以上の開発経験を持つソフトウェアエンジニア / テクノロジーライター。AI エージェントの実務活用を研究し、現場や経営者向けセミナーでその知見を発信。本メディア tech-noisy.com では、一次情報に基づく最新ニュース・解説記事を執筆。また、音楽生成 AI による DJ パフォーマンスを企業イベントで行うなど、テクノロジーと表現の融合も探求している。