A2A双機実戦：2台のPC上のHermesに互いにタスクを任せる

1台のPCで動くHermesだけでは手が回らない。もう1台のPCのHermesに手伝ってもらいたい——そんな時に使うのがA2Aだ。しかし、実際にデプロイする際にどんな落とし穴があるのか？実際のユーザーが経験した失敗談を紹介する。

いつ2台のPCが必要になるのか

まず、この問いを明確にしよう。本当に2台のPCが必要なのか、それとも単に2つのエージェントを連携させたいだけなのか？

もし2つのエージェントが同じマシン上で動いているなら、委任やカンバン方式で十分だ。同じオフィスにいる隣の席の同僚に声をかけるだけでよく、電話をかける必要はない。A2Aは「マシン間/プロセス間/フレームワーク間」の連携のために用意されている。デスクトップPCとサーバーでそれぞれHermesを動かし、それぞれが独自のメモリ、ツール、ログイン認証情報を持っている場合にこそ、A2Aという橋が必要になる。

セットアップ手順

ステップ1：両方のマシンでA2Aプラットフォームを有効化する。 Hermesをインストールする際にA2Aを選択するか、設定ファイルで gateway.platforms.a2a.enabled を true に設定する。ポートはデフォルトで9900。このステップは、各PCに門扉付きの玄関を設置するようなものだ。

ステップ2：トークン（門扉の鍵）を設定する。 サーバー側で A2A_PEER_TOKENS または A2A_BEARER_TOKEN を設定する。ローカルテストのみであればトークンは不要だが、その場合ドアは127.0.0.1にしか開放されない。まるで、社員証が同じ建物の住人にしか発行されないようなものだ。

ステップ3：アドレスを公開する。 マシン間通信には A2A_HOST の設定が必須だ。例えば、0.0.0.0 や LAN IPアドレスを設定する。このステップは、ドアを「内部通路」から「道路に面した場所」に移動させ、もう1台のPCから見つけられるようにする作業だ。

ステップ4：ピアをペアリングする。 クライアント側で a2a_agents を設定するか、a2a_discover("http://サーバーアドレス:9900") を使って相手のAgent Cardを確認する。これは、名刺を交換して、相手が誰で、どんなスキルを持っているかを確認するようなものだ。

ステップ5：検証する。 a2aツールセットを有効にして、a2a_call で簡単なタスクを送信してみる。タイムアウトに注意：クライアントのデフォルトは330秒、サーバーの応答ウィンドウは300秒。長時間のタスクでは値を大きくしないと、作業の途中でタイムアウトと判定されてしまう。完了後は ~/.hermes/a2a_audit.jsonl で監査ログを確認しよう。

実例1：成功したデプロイの姿

公式ドキュメントには理想的なシナリオが描かれている。デスクトップのHermesがサーバー上のHermesにタスクを渡す——サーバーにはより強力な計算能力、より安定したネットワーク、より完全なデータベースがある。逆に、サーバー上のHermesは「ローカルファイルを調べて」といった作業をデスクトップ側に依頼することもできる。両者はそれぞれ独自のメモリとツールを持ち、それぞれの作業を遂行し、Agent Cardを通じて互いのスキルを発見し、対話はcontextIdで管理され、マルチターンに対応している。

これは、会社の2つの部門のようなものだ。マーケティング部（デスクトップ側）がデータ分析レポートを必要とし、データ部（サーバー側）にメールを送る。データ部はレポートを作成して返送する。両者はそれぞれ独自のアーカイブを保管し、互いに干渉しない。

実例2：失敗したデプロイ

コミュニティには実際の失敗例がある（#82910）。ユーザーは2台のmacOSにデュアルノードをデプロイした。ユーザー向けゲートウェイ + ワーカーという構成だ。一見、上記の成功例と同じように見えるが、結果は失敗に終わり、最終的にチームはこのデプロイを停止した。

問題は「コーディネーター」と「ワーカー」の役割分担が明確でなかったことにある。親エージェント（コーディネーター）が自分のセッションにあまりにも多くの情報を詰め込みすぎたのだ。ワーカーの各ステップの操作、各中間結果、各思考プロセスがすべて親セッションにフィードバックされ、コンテキストの膨張を引き起こした。親エージェントは大量の情報に圧倒され、徐々に動作が鈍くなった。エージェント間のトランスクリプトが全体のパフォーマンスを低下させ、複雑なタスクではリカバリループが発生し、状況は悪化の一途をたどった。

教訓は明確だ。A2Aでマシン間連携を行う前に、まず責任の境界を設計すること——誰が調整し、誰が作業を実行し、誰のメモリが誰のものかを決めるのだ。すべてを親セッションに詰め込んではいけない。ワーカーには独自の「メモ帳」を持たせるべきだ。

デプロイ時の注意点チェックリスト

リバースプロキシによるIDの崩壊（#80534/#80779）：nginx、K8s Ingress、CDNなどをリバースプロキシとして使用している場合、すべてのピアが同じベアラートークンを共有するため、IDがすべてプロキシアドレスに崩壊してしまう。解決策は、プロキシに X-Forwarded-For を渡させ、信頼できるプロキシの後方から実際のIDを推定することだ。これは、ビルのフロントで宅配便を預かるようなもの。荷物に実際の受取人を明記しないと、すべてフロントに山積みになってしまう。

マルチプロファイル設定のルーティング拒否（#80884/#80956）：multiplex_profiles で複数のプロファイルを実行している場合、インバウンドのA2Aメッセージがセカンダリプロファイルにルーティングされる際に、ゲートウェイの認可レイヤーによって拒否される可能性がある。修正方法は、起動時に不変アダプターのセキュリティコンテキストをキャプチャし、各プロファイル独自の認証、信頼、バインディング、Agent Cardポリシーを保持することだ。各ドアには独自のアクセス制御ルールが必要で、共通のルールを共有してはいけない。

タイムアウト設定：デフォルトはクライアント330秒 vs サーバー300秒。長時間のタスクでは忘れずに調整しよう。そうしないと、長距離電話で話の途中に切られてしまうようなものだ。

境界付きワーカーモード（#82503）：これは、コンテキスト膨張に対する公式の処方箋だ。非rootのserved A2Aルートは、設定済みのサブプロセスまたはバージョン管理されたRPCワーカーを実行でき、境界付き出力、プロセスのツリー刈り取り、キャンセル、正確に一度だけの終了を備えている。ワーカーは作業が終われば片付けて、プロセス全体を親セッションに流し込むことはない。

ユーザーにとっての意味

A2Aのデュアルマシンデプロイは、「2台のPCを接続する」という単純な話ではない。まるで支店を開くようなものだ。店舗（Agent Card）、入退室管理（トークン）、役割分担（誰が調整し誰が作業するか）、倉庫（各自のメモリ）をすべて明確に設計する必要がある。成功したデプロイは2台のマシンがそれぞれの強みを発揮するが、失敗したデプロイはコーディネーターを情報過多で溺れさせる。

3つのポイントを覚えておこう。まず責任の境界を明確にし、それから技術的な詳細を検討すること。リバースプロキシを使用する場合はIDの問題を処理すること。長時間のタスクではタイムアウトを調整し、複雑なタスクでは境界付きワーカーを使用すること。これらの点を押さえれば、2台のPC上のHermesは、互いに足を引っ張り合うダメな同僚ではなく、本当に良いチームメイトになれるだろう。