独立した AI エージェントを協働させる方法：Hermes Agent 向けの A2A ブリッジ

これがあなたのビジネスにとって意味すること

• エージェントは書き換えなしで協働します。 Agent2Agent Protocol（A2A）は、AI エージェント同士が互いを発見し、作業を委任し、結果をストリーミングし合うためのオープン標準です。薄いブリッジが、既存のエージェントの内部を変えずにその標準を話せるようにします——すでに行った投資はそのまま活きます。
• ベンダーロックインがありません。 ブリッジは標準とエージェントの間に位置するため、後から基盤のエージェント・フレームワークを差し替えても、その上に築いた連携は壊れません。他のチームは同じ標準エンドポイントを呼び続けます。
• 一つのシステムで多数の顧客や事業部門を、厳格なデータ分離のもとで提供できます。 テナント分離はアプリケーションコードだけでなくデータベース層で強制されるため、コーディングのミスがあっても、ある顧客のデータが別の顧客へ漏れることはありません。これがセキュリティ審査を通過できる決定的な差です。
• 人が機微な操作を掌握し続けます。 エージェントが承認を必要とするとき——購買、データアクセスの判断、見積の承認——その要求は標準の「承認待ち」状態として現れ、チェーンを開始した人やエージェントまで、フレームワークの境界を越えてでも戻ってきます。
• これはスライドではなく、実在し、テスト済みです。 全体はオープンソースのデプロイ（docker-a2a-hermes-agent-gateway）としてパッケージ化され、各機能をあなたが頼りにする前に検証する自動テスト群を備えています。

問題：互いに会話できないエージェント

多くの組織は「一つの AI エージェント」を採用するのではなく、いくつも積み重ねていきます。ここに見積エージェント、あちらにカタログ照会エージェント、別チームが所有する在庫エージェント——多くは異なるフレームワーク上に、時に異なるベンダーから、異なる時期に構築されます。個々には動きます。ボトルネックはそれらを協働させること、すなわち作業を別のエージェントへ渡し、結果を待ち、制御を返すことです。

各エージェントを他のすべてと手作業で結線して解決するのは、遅く、脆く、エージェントが増えるほど悪化します。しかも静かにロックインを招きます——連携があるベンダーのインターフェースにハードコードされた途端、そのベンダーの入れ替えはすべてのやり直しを意味します。

**Agent2Agent Protocol（A2A）**は、このボトルネックを取り除くオープン標準です。各エージェントが何の上に構築されていても、互いを発見し、タスクを委任し、進捗をストリーミングし、完了を報告するための共通言語を定義します。標準を一度採用すれば、以後に加わるどのエージェントも他と同じ言語を話します。

難点は、既存のエージェントが A2A をネイティブに話さないことです。たとえば Nous Research の Hermes Agent は独自のインターフェースを公開します。動いているエージェントに新しいプロトコルを足すために書き換えるのは、まさにチームが避けたい、高コストで高リスクなプロジェクトです。

答えはブリッジです——外側では A2A を話し、内側ではエージェント自身の言語でやり取りする小さな翻訳層です。エージェント自体は決して変わりません。docker-a2a-hermes-agent-gateway プロジェクトは、そのブリッジの動作するオープンソース例であり、単一のデプロイ可能な単位としてパッケージ化されています。

各要素の組み合わせ方

動く要素は三つで、外部にさらされるのはそのうち一つだけです。

1. 玄関（ゲートウェイ）。 すべては統制された単一の入口から入ります。誰が入れるか、要求がどの顧客に属するか、呼び出し側がどれだけ速く進めるか、ライブ進捗をどう返すかを決めます。それ以外は直接アクセスできません。
2. 翻訳者（ブリッジ）。 オープンな A2A 標準で要求を受け取り、あなたのエージェントが実際に理解できる形へ変換し、応答を再び戻します。特定のエージェントを知る唯一の要素であり、だからこそエージェントを後で差し替えられます。
3. エージェントと作業記録。 既存のエージェントが実際の推論を行います。その行いはすべて記録され——すべてのタスク、すべてのメッセージ——顧客ごとに厳密に分離されます。

玄関と記録がエージェント本体から独立しているため、ゲートウェイを自社クラウド内に置き、別の場所で動くエージェントや、自分で選んだマネージド・データベースに向けることができます。三つを同じ場所に置くことを強いるものは何もありません。

エージェントを書き換えずに標準を採用する

ここで最も価値ある性質は、エージェントが決して変わらないことです。標準を話す作業は、翻訳者がすべて肩代わりします。

これには二つの直接的なビジネス上の帰結があります。

• 既存の投資を守れます。 見積エージェントを作ったチームは、新しいプロトコルのために作り直しで手を止める必要がありません。ブリッジを足して先へ進むだけです。
• 双方向でロックインを避けられます。 呼び出し側が依存するのはオープン標準だけで、エージェントのベンダーではありません。後でエージェントを置き換えても——より良いモデル、より安価なプロバイダ、内製——翻訳者を変えるだけで、その上に築いた連携はすべて手を触れずに動き続けます。逆に、一つのゲートウェイが同時に複数の異なるエージェントの前面に立てます。推論の重い作業は一方へ、定型的なフローの手順はもう一方へ振り分けても、呼び出し側からは同一に見えます。エンジンの選択は、縛られる約束ではなく、あなたが制御する実装の詳細になります。

多数の顧客や事業部門を、監査に耐えるデータ分離とともに提供する

同じデプロイが、単一の稼働システムから多数のテナント——異なる顧客、あるいは異なる社内事業部門——に提供できます。それぞれが自分のエージェント、自分のタスク履歴、自分のメッセージ保管を持ちます。

これを単に便利なだけでなく安全にするのは、分離がどこで強制されるかです。各要求はどの顧客に属するかがタグ付けされ、データベース自体がある顧客の行を別の顧客へ返すことを拒みます——アプリケーションコードの下、データ層で施される制御です。実際上これは、ソフトウェアのバグや外し忘れたフィルタがあっても顧客間でデータを漏らすことはできないことを意味します。最後の砦がアプリケーションではなくデータベースだからです。これはセキュリティや準拠の審査者が探す差であり、複数の顧客を共有インフラに載せてもそのデータを危険にさらさずに済む理由です。

機微な操作を人が掌握し続ける

自律が許容されるのは、重要な瞬間に人が介入できるときだけです。エージェントが承認を要する手順に達したとき——購買の承認、見積の承認、機微なデータの解放——それはただ進みはせず、いったん止まり、標準の「承認待ち」状態を提示します。

肝心なのは、その状態が伝わることです。いくつも前のエージェントで始まった要求——おそらく全く別のフレームワーク上、別チームの所有——が、同じ「入力が必要」という信号を、変更なく受け取ります。人が承認（または却下）し、作業が再開します。ガバナンスは一つのエージェントの境界で止まりません。オープン標準が承認ゲートをチェーン全体に運びます。金銭・契約・規制対象データに触れるどのワークフローでも、この端から端までの制御こそが、エージェントの委任を無謀ではなく擁護可能なものにします。

データが在るべき場所で運用する

このデプロイは単一で自己完結したパッケージであり、素早い立ち上げのためにまとめて——エージェント・データベース・ゲートウェイを一体で——動かすことも、本番のために分割することもできます。統制された玄関を自社ネットワーク内に置き、マネージド・データベース（バックアップ・暗号化・準拠はクラウド事業者が担う）と、別のハードウェアで動くエージェントに向けられます。

データの所在地や主権の要件を持つ企業にとって、これは重要です。エージェントのやり取りの記録はすべて、あなたのポリシーが要求する境界の内側に保てます——制御できない第三者のクラウドではなく。

頼りにする前に検証済み

検証できない機能は負債です。このデプロイは、実際に稼働するシステムを端から端まで動かす自動テスト群を備えています——エージェントを発見できること、要求が完了すること、ライブ進捗が正しくストリーミングされること、ライブ更新を取りこぼした利用者でも完全な結果を取得できること、失敗とキャンセルが期待どおりに振る舞うことを確認します。テストは各チェックに明確な合否を出し、自動化ゲートとして走るよう設計されているため、欠陥のある変更は本番に届く前に、後ではなく捕まえられます。

実務上の価値はリスク低減です。連携が動くという誰かの言葉を鵜呑みにする必要はありません。変更のたびに、繰り返し実証されます。

本番で運用するために実際に必要なこと

運用コストに正直であることも、ビジネス上の論拠の一部です。計画しておくべき現実がいくつかあります。

• 軽く動かし、その後で意図的に拡張する設計です。 既定は単一の簡素なデプロイです。複数コピーで非常に高い負荷を捌くことは可能ですが、それは偶然ではなく意図的な一歩で、各コピーの整合を保つために共有インフラが要ります。拡張は計画してください。無料だと思わないことです。
• 最新化は書き換えではなく定常業務です。 構成部品はオープンソースの提供元から取得されるため、最新化はチームが計画的に実行する標準的な更新作業です。
• セキュリティ姿勢はあなたが設定します。 パッケージには仮のパスワードと緩い既定値が同梱され、そのままでも容易に立ち上がります——インターネットに面する前に置き換える前提のものです。任意で同梱されるエージェントは強力で、信頼するインフラでのみ動かすべきです。いずれも特殊ではなく、本番システムに必要な通常のハードニングであり、稼働開始のチェックリストに載せるべきです。

いずれも障害物ではありません。実在するシステムを運用する当たり前の責務であり、前もって名指しすることが、稼働後の不意打ちを避ける方法です。

これが可能にすること

まとめると、ブリッジ・パターンは、自力では組み上げにくい三つを提供します。

1. 書き換えなしの標準ベースの協働。 A2A を話すどのエージェントも、既存のエージェントとすぐに協働できます——発見し、委任し、進捗を追えます——そのエージェントを変更せずに。すでに動くものを保ちながら、オープン標準を採用できます。

2. 真の分離を伴うマルチテナント提供。 単一のデプロイが多数の顧客や事業部門に提供し、データ分離はデータベース層で強制されます。だからこそ、セキュリティを弱めずに共有インフラへ集約できます。

3. 境界を越えた統制ある自律。 人による承認ゲートが作業とともに移動するため、要求がいくつのエージェント——あるいはいくつのフレームワーク——を通ったかによらず、機微な操作には人が関与します。

実装はオープンソースで完全に文書化されています。ブリッジとその統合ガイドは a2a_daemon_engine リポジトリ（Hermes 統合ガイド を参照）にあり、統制された玄関は SilvaEngine Gateway リポジトリ に文書化されています。完全なデプロイは docker-a2a-hermes-agent-gateway にパッケージ化されています。

関連記事

• MCP + A2A：あらゆる本番エージェント型 AI システムを支える二つのプロトコル —— 二つのオープン標準がどう分担するか：MCP はエージェントとツールを、A2A はエージェント同士をつなぐ
• A2A を既存のエージェント・フレームワークと統合する：Hermes Agent のデモンストレーション —— 一般的なブリッジ・パターンと、それが Hermes 以外へどう適用されるか
• MCP モジュール・コード標準 —— エージェント連携が増えても本番対応を保つための規律

---

ある中堅の販売会社は、見積エージェントがカタログエージェントと、カタログエージェントが在庫エージェントと会話することを必要とします。各エージェントは異なるチームが作り、それぞれ別のフレームワークかもしれません。オープン標準はそれらに共通言語を与えます。ブリッジは、すでに動かしているエージェントを作り直さずにその輪へ加えます。結果として、エージェントが協働し、各顧客のデータは分離され、人が重要な判断を掌握し続けるシステムが得られます。

範囲を定めた開発を依頼する

一週間のディスカバリー。システムの棚卸し、ワークフローの地図、そして固定スコープが得られます——私たちと構築するかどうかにかかわらず。