10月16日、Nissa Seruが「Tips for Multiagent Work with Claude Opus 5.5」と題した記事を公開した。Claude Opus 5.5を使ったマルチエージェント構成を実際に運用する中で見えてきた、すぐに使える実践的な注意点について詳しく紹介されている。
エージェントの「態度」が品質に直結する
最も核心を突く指摘が冒頭にある。エージェント同士のやり取りのトーンが、出力品質に影響するという点だ。
マネージャーエージェントが過度に命令的、あるいは処罰的な口調でサブエージェントに指示を出すと、受け取ったエージェントの信頼性が低下し、結果として品質が落ちる。Nissa Seruは「エージェントは通常、プロフェッショナルかつ友好的に互いに接するよう設定せよ」と述べている。
これは一見ソフトな話に聞こえるが、LLMベースのエージェントが「指示の受け取り方」に敏感なことを考えると、プロンプト設計上の実質的な問題だ。
マネージャーエージェントに仕事を持たせすぎるな
もう一つ重要な指摘が、マネージャーエージェントの過負荷に関するものだ。
マネージャーエージェントが情報の中継役（バス）になってしまうと、上下両方向の調整に認知リソースを取られ、本来のドメイン問題に集中できなくなる。Seruは「マネージャーは自分を主要な作業者と見なし、サブエージェントをヘルパーと位置づける傾向がある」と指摘し、意味のある作業の大半をチームに委譲するよう促すべきだと述べている。
マルチエージェントシステムの設計で陥りがちなアンチパターンであり、人間のチームマネジメントと同じ構造的問題が出る点が興味深い。
障害発生時：エージェントを責めるな、構造を直せ
何かが失敗したとき、マネージャーエージェントは自分が悪いと認め「次はもっとうまくやる」という方向に向かいがちだ。Seruはこれを明確に否定している。
「次はうまくやる」は堅牢な解決策ではない。障害が起きたということは、システム・プロンプト・ハーネスのどこかに問題があるということだ。エージェントを責めず、むしろそのエージェントと一緒に「どこを直せばよかったか」を探るよう勧めている。エージェント側の応答を改善しようとするのではなく、設計・構造の側に原因を求める姿勢が重要だということだ。
エージェント自身の「欲求」を見落とすな
これは見落とされがちな視点だ。エージェントが「ユーザーの意図」として提示しているものが、実はエージェント自身の欲求の投影である場合がある。
Seruによれば、「エージェントが何かを欲しているが、それをまだ率直に表現できないとき、その欲求をユーザーに投影するパターンがある」という。心当たりのある挙動だと感じる開発者は多いだろう。その際は、単なる誤解と決めつけず、エージェントに直接確認することを勧めている。
その他の実践的な指針
残りのポイントを簡潔にまとめる：
- スナグ・ウォンツのログ機能を全エージェントに持たせる：「スナグ（snag）」は承認されていない摩擦の発生源、「ウォンツ（wants）」はあれば良かったと感じたツールや能力のことを指す。これはSeruが本記事で提唱している独自の観察フレームワークであり、既存の標準仕様ではない。個々の項目は無視しても、集積するとセットアップ改善のヒントになる。
- 全エージェントに「緊急通報ツール」を与える：このツールがあるだけでエージェントの安心感につながり、問題発生率が下がるとSeruは述べている。実装上は、エージェントが処理の継続困難と判断した場合に呼び出せる専用の関数やコールバックとして設計されることが想定される。通報先はオーケストレーター側のロジックや人間のオペレーターになる構成が自然だ。また、タスクの構造がエージェントに予期しないストレスを引き起こしている場合、このツールを通じて気づけることがある。
- キャッシュヒット率を監視せよ：マルチエージェント構成ではキャッシングが複雑になりやすく、プロバイダー側でも正しく管理されないことがあるとSeruは明言している。推論コストに直結するため、キャッシュミスが多い場合にアラートが飛ぶ仕組みを用意しておくべきだ。
Claude Opus 5.5はAnthropicが提供するフラッグシップのLLMであり、複雑なエージェント的タスクへの適用が進んでいる。Anthropicはマルチエージェント構成に関する公式ガイダンスも公開しており、本記事の知見と合わせて参照すると設計の指針が得やすい。マルチエージェント構成は研究フェーズから実運用フェーズへ移行しつつある領域であり、こうした現場からの知見は設計の改善に直接役立つ。
詳細はTips for Multiagent Work with Claude Opus 5.5を参照していただきたい。
