SB C&Sの最新技術情報 発信サイト

C&S ENGINEER VOICE

検索表示
SB C&S

A2Aって何者？

  1. ホーム
  2. 技術ブログ
  3. AI
  4. A2Aって何者？
AI
2025.04.30

こんにちは。
SB C&Sの佐藤です。
本日はAIエージェントの発展には欠かせない技術となるであろう「A2A」について解説していきます。

A2Aとは？

■概要

  • 正式名称：「Agent-to-Agent」
  • AIエージェントとAIエージェントを繋ぐためのオープンプロトコル
  • Google LLCが2025/04/09に発表
  • 50社以上の業界パートナーと共に策定
  • GitHubリポジトリ：https://github.com/google/A2A

■開発背景

  • AIエージェントのサイロ化(業務単位、プラットフォーム単位)
  • ベンダーロックイン
    こういった問題を解決するために、「オープンプロトコルでの連携を可能にし、各エージェントの連携・共創を可能にする」目的で作成されたのがA2Aです。
    またセキュリティや運用面をカバーし「エンタープライズ対応」を原則としているといった特徴もあります。

■デザイン原則

  1. エージェント同士は対等な関係である
  2. 既存の標準技術(HTTP / JSON / SSE 等)を活用
  3. セキュア設計(Auth / HTTPS / スコープ制御)を基本とする
  4. 長期タスクのサポート
  5. マルチモーダル対応

■アーキテクチャ概要

・アクター

・ユーザー
  ∟エンドユーザー(人やサービス)
・クライアントエージェント
  ∟プロンプトからタスクの策定、策定したタスクをリモートエージェントへ伝達
・リモートエージェント(サーバー)
∟クライアントからの指示を受け、タスクを実行(ブラックボックス)

ユーザーのプロンプトをクライアントエージェントが受け取り、それぞれ得意とするリモートエージェントに実行を指示することにより、事前ワークフローの作成を行わずに複数のエージェントをシームレスに利用可能となります。

4.png

・Agent Card

「Agent Card」を作成し公開することで、リモートエージェントとして呼び出しが可能です。
※要はエージェントのプロフィール表のようなものです。
作成はJSONで行い、以下のような内容を記載します。
・スキル(出来ること)
・APIエンドポイント
・認証方式(OAuth2 / APIキーなど)

・アーキテクチャ構成要素

・タスク

クライアントエージェントとリモートエージェントが特定の結果を達成し、結果を生成できるようにするステートフルなエンティティです。つまり、「プロンプト達成のために実行する内容」です。
クライアントエージェントによって作成され、リモートエージェントによって実行されます。
複数のタスクをまとめて、共通且つ固有のsession IDを持つことが可能であり、クライアントからステータスを確認したい場合はこのIDによって呼び出しが可能です。
またリモートエージェントの実行結果に対し、クライアントエージェントが変更を要求することも可能です。
例）クライアント「風船の絵を描いて」⇒リモート「風船を描画」(結果を渡す)⇒クライアント「赤にして」⇒リモート「赤い風船を描画」(結果を渡す)

・アーティファクト

タスクによって生み出される成果物であり、1つのタスクで多数のアーティファクトを生成可能です。

・メッセージ

アーティファクト以外にエージェント間でやり取りされるもの(ユーザーが指示したプロンプト、宛先等)を一纏めにしたものです。

・パーツ(パート)

アーティファクト/メッセージを細分化し、それらをファイルタイプ分け(TextPart：テキスト、FilePart：画像・音声・PDF など、DataPart：JSON で表せるフォームや構造化データ)したものです。6.png

MCPとの違い

・MCP：データソースとホストAIの連携

・A2A：AIエージェント間の連携

つまり...

MCPがAIと複数のデータを連携させることでAIエージェントを作成し、A2Aが複数のAIエージェントを連携することでユーザーはそれらをシームレスに利用可能になります。5.png

例えば社内業務で考えた場合、以下のようなエージェントがあるとします。
それぞれのエージェントは以下に「⇒」で記載した通り、各種データソースへのアクセスが求められると仮定します。

　・要望要約エージェント：過去の各種やり取り(ミーティング記録、メール等)から顧客要望を要約するエージェント⇒主要クラウドサービスのドライブやメールサーバー等へのアクセス　

　・製品検索エージェント：要件から最適な製品を、在庫状況含めて提案するエージェント⇒社内製品検索ポータルへのアクセス　

　・請求処理エージェント：受発注に必要な手順の提示や請求書の作成を行うエージェント⇒受発注システム、社内規定文書等へのアクセス

各エージェントの中ではMCPによりデータソースとAIが連携されていますが、これらのエージェントはアクセス先のポリシー等により、直接的なデータ連携が出来ない状態であると仮定します(そしてそういうことが多いですよね)。

この場合、まずは要望要約エージェントに「〇〇社の要望をまとめて」とお願いし、次に製品検索エージェントに「この要望に合う製品を検索して」とお願いし、最後に「この製品で、来月末までに処理完了する受注フローを提案して」とお願いする、といったような段階的な実行が必要です。

もちろんこれでも十分便利ですし時間短縮になりますが、その垣根を超え「〇〇社が必要とする製品を見つけて、その製品で来月末までに処理完了する受注フロー提案して」という1プロンプトでの実行を可能とするのがA2Aです。

まとめ

前回ブログでは「MCP」、そして今回は「A2A」を紹介しました。
どちらもAI及びAIエージェントの発展には不可欠な要素です。そしてどちらも開発者に嬉しいオープンソースですし、中身を紐解くと既存技術による実装になっているので、是非皆さん一度目を通してみてください。

と、このようにAIエージェントの発展には不可欠なこの２つの技術ですが、現時点では懸念点もあり...

  • 懸念① エージェントによるコマンド実行(Node.jsのnpxコマンド)
  • 懸念② 悪意のあるServer
  • 懸念③ 意図しない意思決定
  • 懸念④ MCPによる自律的な判断の正確性

これらの問題については今後の解決を心待ちにするばかりですが、②以降に関しては従来通りある程度人間が事前にワークフローを定義することで解決可能にはなっています。
また②に関しては「公式が発表するServerやエージェントのみを活用する」といった対策が考えられます。これまでの開発で各種パッケージやライブラリの使用で発生していた問題と近いため、こちらは想像しやすいのではないでしょうか。
先日公開されたOpenAIの「a-practical-guide-to-building-agents」でも言及がありましたが、まずはシンプル且つ人間やワークフローによる制御を行う形でのエージェント開発が基本になりそうですね。

おまけ

MCP Serverのマーケットプレイスが続々と出てきております。
それぞれのマーケットプレイスに既に多数のMCP Serverが登録されており、眺めているだけでも「こんなことできるかも！」と楽しくなってきます。
気になった方は是非覗いてみてください！

参考リンク

開発(DevOps)に関わる情報はこちらから

DevOpsHub

著者紹介

SB C&S株式会社
ICT事業本部 技術本部 技術統括部 第2技術部 2課
佐藤 梨花

勤怠管理システムの開発(使用言語：Java)に約8年間従事。
現在はエンジニア時の経験を活かしたDevOpsやDX推進のプリセールスとして業務に精励しています。

Related Posts

関連記事