再構築ではなく改造：レガシーエンタープライズサービスを変革するエージェンティックオーバーレイ

この記事で表明された意見は著者個人の見解であり、Ciscoの見解ではありません。

長年にわたり、エンタープライズアーキテクチャはREST APIとマイクロサービスを中心としてきました。これらのシステムは安定しており、十分にテストされ、本番環境に深く組み込まれています。しかし、それらはエージェント間通信（A2A）のために設計されていません。A2Aは、構造化メッセージを通じて協調、推論、調整を行う自律エージェントのための新興標準です。共通のエージェントプロトコルがなかったため、これまでのアーキテクチャは機能していましたが、現在では多くの既存エージェントがA2Aフレームワークの外側にあります。今日の課題は、従来のサービスにA2Aを追加することだけではありません。これらのRESTベースのエージェントを標準化されたエージェント間世界に持ち込む必要もあります。

AWSと著者の技術協力により、実用的なソリューションであるエージェンティックオーバーレイを提案します。エージェンティックオーバーレイは薄いラッパー層であり、従来のRESTベースのサービスをA2A対話に参加できるエージェントに変換します。また、REST APIをモデルコンテキストプロトコル（MCP）と互換性のあるツールとして公開します。これらを組み合わせることで、企業はビジネスロジックの書き換え、コードの複製、並行インフラの運用なしに、既存のRESTサービスにA2A機能を追加できます。既存のサービスをエージェントとして再利用することで、インフラ内のエージェント乱立を削減します。リファレンスアーキテクチャとサンプルコードを提供し、エージェンティックオーバーレイの構築方法を示します。

背景：RESTとA2Aの比較

REST APIは、決定論的なクライアント-サーバー統合のために設計されています。クライアントは明確に定義されたエンドポイントを呼び出し、パラメータを渡し、HTTPセマンティクスに従ったステートレスなリクエスト-レスポンスフローで予測可能な応答を受け取ります。これにより、RESTは明確な契約、強力な互換性、運用の単純さを備えたビジネス機能（作成、読み取り、更新、削除など）の公開に優れています。

A2Aは、自律エージェント間の相互運用性のために設計されています。エージェントはメタデータ（エージェントカードなど）を通じて相互に発見し、能力を交渉し、構造化メッセージ（多くの場合JSON-RPC）を交換してマルチステップタスクを調整します。RESTが安定したサービスインターフェースと直接実行を最適化するのに対し、A2Aは推論駆動の調整、タスク指向のメッセージング、エージェントコラボレーションを最適化します。結果として、孤立したエンドポイントを呼び出すのではなく、複数のサービスにわたってアクションを計画、委任、構成できるシステムが実現します。

エージェンティックシステムへの移行における課題

REST APIとエージェンティックシステムは直交するパラダイムに基づいており、企業が既存のサービスを標準化されたエージェンティック通信に移行することを困難にしています。しかし、企業は大規模な見直しなしに両方を使用する必要があります。A2Aによる新しいエージェント通信はエンタープライズシステムに調整モデルをもたらしますが、既存のエンタープライズシステムと並行してエージェンティックインフラを展開・運用する必要があるため、採用は遅れています。この並行運用は運用の複雑さとコストを増大させ、AIの効果的な採用に対する障壁となっています。

A2Aが標準化される前、企業はエージェントをRESTベースまたはプロプライエタリなサービスとして展開することが一般的でした。これらは、リクエスト-レスポンスエンドポイントにエージェント固有のロジックが埋め込まれた従来のAPIとして扱われていました。その結果、今日の多くの既存エージェントはA2Aネイティブではなく、新しい移行課題が生じています。つまり、コアロジックを書き換えることなく、これらのエージェントを標準化されたA2Aプロトコルで相互運用可能にすることです。

ソリューションアプローチ

このセクションでは、レガシーエンタープライズシステムにエージェンティック機能を追加するためのいくつかの異なるアプローチを議論し、エージェンティックオーバーレイを使用するアプローチと比較します。

独立したRESTとA2Aスタックの維持：1つのアプローチは、同じ機能を公開するための2つの並行した方法を開発・維持することです。これは、2組のエンドポイント、認証・検証・エラーマッピングの2つの実装、2つのデプロイパイプライン、二重の観測可能性作業、および高い不整合リスクを意味します。長期的には、コストと運用の複雑さが増加します。

分離されたスタックだが共有されるビジネスロジック：既存のエンドポイントをリファクタリングすることは、現在のREST APIコード構造（場合によっては動作）を変更し、A2Aなどの新しいインターフェースで再利用できるようにすることを意味します。外部のRESTパスが同じままであっても、リファクタリングはリグレッション、動作のドリフト、および大きなテスト負荷を導入する可能性があります。

コアアイデア：エージェンティックオーバーレイ

エージェンティックオーバーレイは、RESTベースのサービスがA2A通信に参加できるようにする薄いラッパー層です。このオーバーレイは、エージェントメッセージをRESTペイロードに変換し、その逆も行います。RESTエンドポイントをエージェントタスクまたはツールとして公開します。最も重要なのは、A2Aは新しいAPIではなく、既存のAPIへの新しいインターフェースであることです。基礎となるRESTサービスは変更されません。

アプリケーション内にエージェンティックオーバーレイを追加する場合、2組のエンドポイント（/api/v2/...と/a2a/...）がありますが、デプロイパイプラインは1つだけです。従来のREST APIエンドポイントは、コアビジネスロジックを書き換えることなくエージェンティックエンドポイントに変換できます。同じホストとポートに新しいルートを追加しますが、増加するトラフィックを処理するためにシステムをスケーリングする必要があるかもしれません。エージェントスキル自体をルーティングに適用でき、別のMCPサーバーは必要ありません。このアプローチは、既存のサービスをエージェントとして再利用することで、インフラ内のエージェント乱立を削減します。このデザインパターンは、意図分類やルーティングなど、限られた機能範囲でRESTベースとエージェンティックの両方の機能を必要とするスーパーバイザーエージェントに適しています。

エージェンティックオーバーレイの実装例

概念実証として、このセクションでは、Flaskを使用したレガシーなRESTベースの計算機サービスを、オーバーレイを使用してエージェンティックシステムに移植する方法を示します。オーバーレイには、標準のA2Aコンポーネント（エージェントカード、エージェントメッセージエンドポイント、能力、スキル、ヘルスチェックなど）を追加します。また、エージェントメッセージをREST APIメッセージに変換し、エージェントからREST呼び出しを発行するメッセージ変換デザインパターンを導入します。A2Aメッセージ変換ワークフローは以下の通りです：

1. JSON-RPC 2.0リクエストを受信。
2. A2AタスクをRESTエンドポイントにマッピング。
3. 認証ヘッダーを転送。
4. 内部でRESTエンドポイントを呼び出し。
5. RESTレスポンスをJSON-RPC形式に変換。

ステップ0：リクエスト-レスポンス形式：RESTとA2Aプロトコルのリクエスト-レスポンス形式を比較します。例えば、REST計算機リクエストは{"operation": "add", "operands": [5, 3]}、A2AリクエストはJSON-RPCメッセージにカプセル化されます。レスポンスでは、RESTは{"result": 8}を返し、A2Aは構造化されたJSON-RPCレスポンスを返します。

ステップ1：エージェントのセットアップ：ウェルノウンエージェントカードとロードされたエージェントスキルを持つ計算機エージェントの例を作成します。build_agent_card関数はエージェントカードを動的に構築します。

ステップ2：内部REST呼び出しの実装：HTTPリクエストを介して内部RESTエンドポイントを呼び出し、ミドルウェア、デコレータ、ヘッダーが適切に実行されることを保証します。この実装は、薄いレイヤーを通じてレガシーRESTサービスをA2A互換エージェントに変換し、既存のビジネスロジックを変更しない方法を示しています。