AgentConnect：Claude CodeやCodexをチームと同じスレッドで動かすオープンソースのマルチエージェント基盤

解決しようとしている課題

AgentConnectは、Apache-2.0ライセンスで公開されているオープンソースのプラットフォームです。人間と複数のAIエージェントが、チームがすでに使っている会話やワークフローの中で一緒に働けるようにすることを目指しています。READMEの冒頭では「Claude Tagのオープンソース版マルチエージェント代替」と自己紹介し、キャッチコピーは「@ any agent」です。仕事が行われる場所で、エージェントがチームと、そしてエージェント同士で並んで働き、学び続ける、という考え方です。

背景には身近な問題があります。多くのコーディングエージェントは、いまも個人のターミナルの中で動く個人用ツールです。同僚はエージェントが何をしているか見られず、セッションを引き継げず、出力をレビューできません。エージェントが貯めた文脈も一台のノートPCに残ります。その結果、どのチームもメッセージチャンネル、cronジョブ、認証情報の扱い、文脈のつなぎ込みといった同じ接着コードを書くことになります。AgentConnectはその接着部分をプラットフォームにしようという提案です。

中核アーキテクチャ：三つのコンポーネントと二つの面

READMEのアーキテクチャ説明によると、構成要素は三つです。 一つ目はDaemonです。Daemonが持つACP（Agent Client Protocol）接続の上で、割り当てられたエージェントを実行します。ワークスペースとセッション状態を管理し、各チャットプラットフォームへの直接接続とスケジュールを維持し、モデルプロバイダへの通信も自分から直接送ります。 二つ目はRelayで、これは任意です。コールバック方式の入口とWebチャットを受け付け、集中管理されるMCPとOpenConnectorへのアクセスを中継し、メッセージを担当のDaemonへ直接転送します。永続的な保存は行いません。 三つ目はControl PlaneとWeb UIです。認証、設定、配置、権限、メタデータ、可観測性を担当します。明示的に承認された組織のナレッジとスキルの改訂版は保存しますが、それ以外は必要に応じてDaemonへの限定的な読み取りを中継します。

設計の要点は、データ面と制御面の分離です。プラットフォームのライブメッセージとACPの更新ストリームは、DaemonとRelayの経路に留まります。承認済みの組織ナレッジと容量が限られたスキルバンドルを除き、Control Planeが持つのは調整用のメタデータだけで、メッセージ本文、添付ファイル、保留中のDream提案、ACPセッションストリームは保存しません。READMEは障害時の挙動も明記しています。Control Planeが一時的に使えなくなっても、確立済みのセッションとDaemonローカルのスケジュールは動き続け、新しい割り当てと設定変更だけが再接続後に再開します。実用的な障害モデルです。

技術的な要点その1：ACPによるランタイム中立

AgentConnectは特定のエージェントランタイムに依存しません。Claude Code、Codex、Grok Build、DeepSeek、Pi、その他のACP互換ランタイムを並べて動かせます。各エージェントのランタイム、モデル、ワークスペース、ツール、実行マシンは個別に設定できます。READMEによれば、どれか一つを入れ替えても、その周りのワークフローを作り直す必要はありません。

ACPは共通のコンセントのような役割を果たします。Daemonがすべてのエージェントと同じプロトコルで話すため、ルーティング、権限、記憶といった上位の仕組みをツールごとに作り分けずに済みます。すでに複数のコーディングエージェントを併用しているチームにとっては、ツールごとにチャットボットを接続するより保守しやすい構成です。

技術的な要点その2：DecisionsとJevによるルーティング

もう一つの注目点は、Jev（TypeSafe）が支える再利用可能なDecisionsです。エージェントがいつ応答するか、新しい会話をどの専門エージェントに渡すか、新しいセッションにどのランタイムとモデルを使うか、という三つを決めます。

READMEには具体例があります。サポートの振り分けでは、新しい問い合わせをJevが適切な専門家へ回し、人とエージェントが同じスレッドで調査し、修正と検証の過程が最初から最後まで見えます。カスタムのコードレビューでは、新しいGitHubのプルリクエストごとにJevがレビュアーを選び、レビューセッションごとにランタイムとモデルを選びます。一般、アーキテクチャ、セキュリティなどのレビュアーは、それぞれ独自の指示、リポジトリ権限、ツール、サンドボックスポリシーを持てます。

つまり「誰がやるか」と「何でやるか」の間に、設定可能なポリシー層を置いたことになります。ルールをボットのスクリプトに埋め込む必要がありません。

記憶、ナレッジ、境界

各エージェントは自分の記憶とスキルを持ちます。レビュー済みのKnowledgeを公開すれば、すべてのエージェントが必要なときに検索できます。

導入ガイドにはMem0の任意設定も登場します。境界の面では、各エージェントとセッションを誰が見られるか、どのリポジトリとツールを使えるか、どの他エージェントを呼べるかを指定できます。作業の開始点は、メッセージ、Issue、プルリクエスト、Webhook、スケジュールのいずれかです。

デプロイ

セルフホストの経路は二つあります。最短はDockerで、リポジトリをクローンしてdocker compose up -d --pull alwaysを実行すると、Webコンソール、Control Plane、Relay、PostgreSQLが起動します。localhost:3000を開き、コンソールからDaemonを追加し、生成されたコマンドを実行して最初のエージェントを作ります。既定の構成は127.0.0.1だけで待ち受け、評価用の認証なしモードで動きます。

クラスタ向けには、リリースごとに同じバージョン番号で公式Helmチャートが公開されます（oci://ghcr.io/agentconnect-md/charts/agentconnect）。ループバックの8091番ポートで動くSetup Serverは、Logtoによるブラウザ認証、GitHub、Slack、Google、Lark/Feishuのアプリ、プリセットエージェントの挙動を設定します。リポジトリにはセットアップ用スキルも同梱され、Claude CodeやCodexが対話形式で導入を案内します。開発にはNode 24.12.0以上とpnpm 11が必要です。

エコシステムへの影響

開発者にとっての価値は、エージェントを個人のターミナルからチームの共有空間へ移せることです。同じSlackスレッドで、人がエージェントの作業を引き継ぎ、レビューし、修正できます。

企業にとっては、Apache-2.0とセルフホストの組み合わせにより、エージェントの実行とワークスペースを自社運用の環境に置けます。複数のランタイムを併用できるため、単一のモデル提供元への依存も下がります。

限界と今後の論点

はっきり述べておくべき点として、READMEにはベンチマーク、遅延、コストの数値が載っていません。そのため本稿は性能についての主張をしません。評価時に確認したい点は次のとおりです。

第一に、既定の構成は認証なしの評価モードです。本番では認証、公開URL、Linuxサンドボックスの要件を整える必要があります。第二に、エージェントが他のエージェントを呼ぶ構成はコストと誤動作の影響範囲を広げるため、権限境界と呼び出しグラフの設計が欠かせません。第三に、Decisionsは外部コンポーネントであるJevに依存するため、成熟度と代替可能性を別途確認すべきです。第四に、READMEはClaude Tag自体を詳しく説明していないため、比較は公式資料で確かめる必要があります。

展望

マルチエージェントでの作業が当たり前になれば、ボトルネックは個々のエージェントの能力から、ルーティング、権限、記憶、可観測性といった組織レベルの問題に移ります。AgentConnectはその層に、オープンソース、セルフホスト、ランタイム中立という形で賭けています。

標準になれるかどうかは、ACPエコシステムの広がりと、セキュリティとコスト管理の実践が育つかにかかっています。現時点でも、チームが試して自分の証拠で判断する価値のある参照実装です。