TL;DR: マルチエージェントシステムに「実行」上の問題があるわけではありません。問題は「協調（コーディネーション）」です。私は、他のすべてのエージェントの上に乗る gatekeeper（関門）レイヤーである Nexus を作りました。チケットを作成できるのは Nexus だけです。
ソフトウェア工学のタスクに向けてマルチエージェントシステムを作り始めたとき、最初はアーキテクチャが明白に思えました。セキュリティ、信頼性、テストカバレッジ、パフォーマンスなどの領域ごとに専門のエージェントを作ります。コードベースを渡して、動かすだけです。
しかし問題はすぐに出てきました。
エージェントはそれぞれ個別には正しかったのです。たとえば、CISO エージェントは本物の脆弱性を見つけ、パッチを提案しました。SRE エージェントも同じ影響を受けるコンポーネントを特定し、その問題のクラス全体を根本的に取り除くようなアーキテクチャ変更を提案しました。どちらの提案も妥当でしたが、互いに存在を知りません。結果として、同じファイルに対して矛盾する変更を出荷してしまう可能性がありました。
これは問題の「簡単な」バージョンです。
より難しいバージョンは、局所的には最適でも、全体としては破壊的なエージェントです。あるエージェントは依存関係のアップグレードを提案します。アップグレード自体は良い内容です。でも CI パイプラインは赤で、ステージングではブロックされた循環依存が発生しており、CTO は非重要な変更を保留する指示を出しています。ところが、そのエージェントはそれを何も知りません。ただ古くなった依存が見えているだけです。
私はエージェントの品質問題に取り組んでいたわけではありません。エージェントはちゃんと仕事をしていました。問題は協調（コーディネーション）です。誰かが「それらの仕事を実行すべきか」を判断する存在がいなかったのです。
これはオーケストレーションの問題ではありません。オーケストレーションは、何をやるべきかを知ったうえで、それを割り当てます。これらのエージェントは、独立して作業を発見しているのです。
設計上の決定：拒否権を持つ 1 つのエージェント
私は Nexus を、他のすべてのエージェントの上にある実行（エグゼクティブ）レイヤーとして構築しました。ルールはシンプルです。チケットを作成できるのは Nexus だけ。ほかのすべてのエージェントは作業を見つけ出し、その根拠を提示します。Nexus が、「やる価値があるか」「適切なタイミングでか」「正しい理由でか」を判断します。
Nexus が、実行パイプラインに何かが入る前に最初に問うコアな問いはこれです：これを、適切なタイミングで、適切な理由で実行すべきか？
Nexus は、この仕組みを成立させるためにいくつかのことを行います：
エージェント間レビュー。 CISO エージェントと SRE エージェントが同じコンポーネントに触れる作業を両方提案した場合、Nexus は単にどちらかを選びません。両者を統合し、より狭いパッチは却下し、セキュリティ要件をアーキテクチャチケットに統合し、さらに CISO エージェントを必須のレビュアーとして追加します。1 つのチケット、2 つの矛盾するチケットではありません。
時間的判断。 ここは最も正しくするのに手間がかかりました。Nexus はシステム状態を追跡します。CI の健全性、進行中のインシデント、エラーバジェット、戦略的な指示です。同じ提案でも、通常運用時に承認されるものが、インシデント対応モードのときは延期されます。同じ提案でも答えが変わる。正しさよりも文脈が重要です。
拒否は二値ではない。 コア原則と根本的に衝突する提案は、そもそも完全に殺します。問題は妥当だが実行計画がまずい提案は、提案元のエージェントに差し戻し、具体的なフィードバックを添えて「再提出」させます。提案が無言で黙って捨てられることはありません。
衝突検出と組織的なメモリ。 エージェントは、提案が触れるファイル、ルート、コンポーネントにタグを付けます。Nexus はテキストの類似度だけでなく、実際のオーバーラップを評価します。そして承認、却下、修正のすべてが、Nexus がチームの価値観として学習する内容にフィードバックされます。時間が経つほど精度が上がっていきます。ゆっくりですが、ちゃんと。
Nexus に提出されるすべての提案は、何かが移動する前に Decision Brief（意思決定ブリーフ）形式に従わなければなりません：
- Problem statement（ユーザーへの害 / ビジネスリスク）
- Evidence（メトリクス、インシデント、頻度）
- Proposed change（何を、具体的に）
- Alternatives considered（検討した代替案）
- Risks（セキュリティ、信頼性、正しさ、UX）
- Dependencies / prerequisites（依存関係 / 前提条件）
- Effort estimate（おおまかな工数見積もりのオーダー）
- Measurement plan（成功をどう判断するか）
- Rollout / rollback plan（段階導入 / 巻き戻し計画）
- Required reviewers（どのエージェントが承認サインを出す必要があるか）
ブリーフがなければチケットなし。
提案が通ったとき、チケットはこういう見た目になります：
Phase 1.3: 状態マシンの公開（パブリッシュ）用 決定的オフラインテスト
pending
task · ux-designer · 3/21/2026, 11:36:32 PM
公開（publishing）のコア状態マシンを、モックアダプタを使って検証するための決定的なオフラインテストスイートを書きます。
Acceptance Criteria：
1. オフライン実行：テストスイートは、外部のソーシャルメディアネットワークに接続することなく、完全にオフラインで実行できること。
2. 線形の状態遷移：テストは、公開ジョブのライフサイクルを Pending -> Publishing -> Success（または Failed）へと、明示的に正確な形でアサートすること。
3. 状況の可視化（UX ガードレール）：中間状態および最終状態が、データベースに曖昧さなく永続化されることをテストで証明すること。これにより、ユーザー向けダッシュボードが常に正確なリアルタイムのシステム状況を表示できることを保証します（「ゴースト」や「詰まった」UI 状態を防止する）。
4. モック連携：MockPlatformAdapter を使って、ハッピーパスと想定されるエラーパスの両方を決定的にトリガーし、検証できること。
Review Gates：
- QA レビュー：CI のフレーク（揺らぎ）を防ぐため、テストの決定性を検証すること。
- UX/Product レビュー：失敗状態に、UI 上で明確で実行可能なエラーメッセージを表示するのに十分な文脈が含まれていることを検証すること。
Risks & Mitigations（リスクと対策）：
- リスク：モックアダプタの挙動が、実際の API の現実からズレる。
- 対策：モックのロジックは意図的に無駄がない（素朴な）ものに保ち、公式のプラットフォーム API ドキュメントに厳密に対応させること。
Stop Conditions（停止条件）：
- 状態マシンがデッドロック／孤児化（オーファン）した場合、またはモックアダプタが基本的な状態遷移をシミュレートするのに過度に複雑さが必要になった場合は、人間にエスカレーションして停止する。
Fallback（フォールバック）：モックアダプタで必要なすべての状態遷移を正確にシミュレートできない場合、ローカルの HTTP スタブツール（例：WireMock）にフォールバックし、API 契約に対してネットワークレベルのレスポンスをシミュレートします。
オープンソースにした理由
正直に言うと、ゲートキーパーのアーキテクチャは、私が最もフィードバックをもらいたい部分です。マルチエージェント協調の問題は現実のもので、私が見てきた多くの実装では、これをまるごと後回しにしてしまっています。意思決定レイヤーをオープンに出して、人々がどう扱うのかを見たかったのです。これについてより多くのフィードバックが得られれば、その分だけ改善が早まり、より良いものへ進化していきます。
リポジトリはこちら：https://github.com/PermaShipAI/nexus
ローカルで動き、ローカルモデルや Anthropic、OpenAI、Gemini の API に対応しています。
もしマルチエージェントシステムを作っていて協調の壁にぶつかっているなら、Issue を立てるかコメントしてください。みんながどんなエッジケースに遭遇しているのか、心から気になっています。
