Managed Agentsへ相談役を一席だけ置く

結論：advisorは仕事を分担するagentではなく、primary threadの戦略相談役

読者の具体的な困りごとは、強いmodelを全工程へ使うと費用が増え、低cost modelだけでは設計や停止判断の品質が不安なのに、相談役の役割と証跡を説明できないことです。この記事を読むと、advisorを使う業務、executorとのmodel pair、plaintextかredactedか、失敗時に続行するかを判断できます。

次の行動：相談が必要な判断を「開始前」「行き詰まり」「完了前」の三場面から一つ選び、その判断をadvisorなしで進めてよい条件も書いてください。

Managed Agents advisorの提供条件と動き

2026年8月11日時点ではManaged Agentsのmultiagent rosterへ{"type":"advisor","model":"..."}を追加します。Managed Agents APIはmanaged-agents-2026-04-01 beta headerを使います。一つのrosterにadvisorは最大一件で、reserved nameはanthropic.advisorです。同名の通常agentを登録すると400 validation errorになります。

primary threadが相談すると、platformはanthropic.advisorというthreadを作り、sessionのcontextから助言を生成します。典型的にはthread created、running、message received、idle、terminatedのeventが流れます。ただしadvice deliveryがidleやterminatedより必ず先に届く保証はありません。終了eventだけを見て助言取得済みと判定せず、agent.thread_message_receivedを確認します。

advisorはlist_agentsに表示されず、send_to_agentでも呼べません。roster agentやchild threadからは相談できず、primary threadだけが使えます。advisor threadはconcurrent-thread limitの外側ですが、tokenはadvisor modelの料金で請求され、session全体のusageへ含まれます。

advisor・subagent・Messages API toolを6軸で比較する

1. 目的：advisorは戦略助言、subagentは独立contextでの実作業、Messages API advisor toolは一つのMessages request内でexecutorを補助します。
2. 呼べるthread：Managed Agents advisorはprimary限定です。subagentはcoordinatorがtaskを委譲し、follow-upも送れます。
3. 設定数：advisorはrosterに一つだけです。通常agentは最大20 unique agentsを列挙でき、同じagentを複数回呼べます。
4. control：Managed Agents advisor entryにはmax_uses、max_tokens、cachingがありません。Messages API toolにはこれらのcontrolがあります。
5. 見える結果：Opus 5、Fable 5、Mythos 5の助言はclientにはredactedで、agentだけが全文を読みます。Opus 4.8ならplaintextをevent streamで確認できます。
6. 失敗：advisor相談のrate limit、timeout、interruptはturn全体をfailさせず、executorはgeneric notice後に続行します。必須reviewならclient側のgateが必要です。

最も強いmodelを置けば常に正解ではありません。redacted結果では助言本文を監査できず、相談回数にもentry側のhard capがありません。監査可能性が優先ならplaintext model、能力が優先ならredacted modelを選び、usageと最終成果物の差で評価します。

advisorを設定する7手順

1. advisorが必要な業務を、長いcoding、multi-step research、重大design reviewなど計画品質が結果を左右するtaskへ限定します。単純Q&Aや全turnが最上位能力を要するtaskは外します。
2. executorのmodel、平均token、成功率、human review時間をbaselineとして20件測ります。改善前の数字がなければadvisorの価値を説明できません。
3. rosterへadvisor entryを一件追加します。advisor modelはexecutorと同等以上のcapabilityが必要で、不正なpairはagent保存時に400になります。
4. system promptへ相談場面を明示します。例は「主要design決定前」「二回同じerrorが続いた時」「最終成果物の提出前」です。曖昧な「必要なら相談」はcall率がtaskごとに揺れます。
5. test sessionを作り、advisor threadのcreated、message received、terminated、usageを保存します。redacted modelでは本文ではなく、相談発生、model、token、時刻、後続変更を証跡にします。
6. advisor失敗を注入し、executorが続行することを確認します。高risk taskでは相談失敗を検知したclientが成果物をHOLDし、人間reviewへ送るようにします。
7. baselineとadvisorありを、正答率、手戻り、総token、elapsed time、人間確認時間で比較し、採用・限定採用・見送りを決めます。

agent定義のrosterは作成・更新時にsnapshotされます。参照agentの新versionは自動反映されないため、advisor以外のrosterも更新する場合はcoordinator versionを明示してrelease記録を残してください。advisorを外す時はentryを削除し、唯一のentryならmultiagent: nullへ戻します。

費用・監査・停止のチェックリスト

• 相談が価値を持つ判断を三つ以内に限定した
• executorとadvisorのmodel pairが公式compatibility内である
• plaintextとredactedの監査差を承認した
• advisor相談数をsession eventから集計する
• advisor tokenをsession usageへ含めて予算化する
• 相談失敗時のcontinue・HOLDをtask riskで分ける
• advisorのadvice delivery eventを終了eventと分けて待つ
• 相談後に何が変わったかfinal reportへ残す
• baselineなしの品質向上主張をしない
• 月次で利用継続またはroster削除を判断する

Managed Agents entryでは相談回数や出力tokenを直接制限できません。費用を止めるにはsession全体のbudget、client側のevent監視、system promptの相談条件を組み合わせます。session budgetへ到達すれば新しいmodel requestは始まりませんが、実行中request分は上限を少し超える可能性があります。

また、advisorが全文を読めることは、別の外部modelへdataを送る意味ではなくAnthropic内のserver-side相談ですが、model inference geography、保持、vault、tool resultのdata分類はsession全体として確認します。相談役を追加しても、executorのpermissionやtool accessがadvisorへ移るわけではありません。

よくある質問と次の行動

roster設定、thread event、制限はAnthropic公式Multiagent orchestration、model pair、result variant、料金controlの違いは公式Advisor tool、Managed Agentsの基本条件は公式Overviewで公開直前にも確認してください。

費用停止はManaged Agents Session budgets、運用手順の正本化はGitHub Skills、判断証跡はClaude Code監査logへつなげます。Miraigentの無料診断では、相談場面、model pair、budget、human gateを一枚に整理します。