
はじめに
カミナシの認証認可チームのmanaty(@manaty0226)です。今年もラスベガスにて12月1日から12月5日まで開催されているre:Inventに参加しています。この記事では、初日に参加したAIエージェントに関する以下の2つのセッションについて記載します。
- Building Scalable, Self-Orchestrating AI Workflows with A2A and MCP (DEV415)
- Hands-on multi-tenant agents: Inside tenant-aware agentic systems (SAS403-R)
AIエージェントのコレオグラフィとA2Aプロトコル
1つめのセッション(Building Scalable, Self-Orchestrating AI Workflows with A2A and MCP)では、タスクを自律的に実行するAIエージェントにおいて、supervisorとworkerの2つの役割に分離したAIエージェントを協働させてタスクを完結するコレオグラフィパターンと、それを支えるA2A(Agento-to-Agent)プロトコル、およびコレオグラフィパターンにおける論点について話されました。
A2Aプロトコルは、AIエージェントが互いを発見し、エージェントが実行できる能力や入出力の条件を知り、互いの内部状態やメモリ、ツールを隠蔽したまま呼び出し合って自身が任されたタスクを完遂するためのプロトコルです。例えば、以下のようなAgent Cardというデータモデルが定義されており、どんな能力があるのか情報を取得することができます。
{ "protocolVersion": "0.3.0", "name": "Research Assistant Agent", "description": "AI agent for academic research and fact-checking", "supportedInterfaces": [ { "url": "https://research-agent.example.com/a2a/v1", "protocolBinding": "HTTP+JSON" } ], "capabilities": { "streaming": false, "pushNotifications": false, "extensions": [ { "uri": "https://standards.org/extensions/citations/v1", "description": "Provides citation formatting and source verification", "required": false }, { "uri": "https://example.com/extensions/geolocation/v1", "description": "Location-based search capabilities", "required": false } ] }, "defaultInputModes": ["text/plain"], "defaultOutputModes": ["text/plain"], "skills": [ { "id": "academic-research", "name": "Academic Research Assistant", "description": "Provides research assistance with citations and source verification", "tags": ["research", "citations", "academic"], "examples": ["Find peer-reviewed articles on climate change"], "inputModes": ["text/plain"], "outputModes": ["text/plain"] } ] }
実際のサービスで求められる複雑なタスクには、モノリシックな1つのエージェントを作成するのではなく、ドメインごとにAIエージェントワーカーを作成し、それらのワーカーをA2Aプロトコルで連携して実行するのがプラクティスのようです。私にはコレオグラフィというよりオーケストレーション のように見えましたが、全体を司るエージェントは各タスクを実行するエージェントの動作詳細や終了判定に関与しなかったり、タスク実行エージェント同士で自律的に協調する可能性があるのでコレオグラフィと呼んでいるのでしょうか。

一方で、小さく分割したAIエージェントをA2Aプロトコルで連携して動かすのは複雑性も高くなります。また、エージェントのモデル選択によって安定性や正確性だけでなくコストも大きく変わってきます。そこで、人間から入力を受け付けて複雑なタスクを分解するsupervisorとworkerという役割で分解して、モデル選択や実行時の終了条件判定などを調整します。私たちが普段利用するコーディングエージェントでも、タスク計画を立てるのは高度なモデルで、実際にタスクを実行するのは安価なモデルだったりするので、このように分解してエージェントを使ったサービスを構築するのはイメージしやすいですね。


また、RISENフレームワークと呼ばれる、「Role」、「Instruction」、「Step」、「Expectations」、「Narrowing」の5つの章で分割して指示するプロンプトテクニックや、AIエージェントから呼び出されるコンポーネントの冪等性を確保することにより、決定論的な動きに近づけることが重要というのも面白く重要な視点だと思いました。AIエージェントから呼び出される個別のツールとしてのAPIにおいても、何度もリトライされてもきちんと同じ結果を返したり、逆に送金処理のような何度も実行されては問題のある処理は冪等キーなどを設定しておく必要があります。冪等性はこれまでも分散システムにおいて重要なポイントではありましたが、エージェントの終了判定はタスク全体とユーザーへの応答を踏まえた全体的な判断であったりするので、こうした基礎的な考え方がしっかり実装されていることがより重要になってきたと感じました。

マルチテナントAIエージェントの構築
2つめのセッション(Hands-on multi-tenant agents: Inside tenant-aware agentic systems)では、組織ごとのテクニカルサポートを支援するマルチテナントなAIエージェントをワークショップ形式で実際に構築しました。 ワークショップでは、Amazon Bedrock Knowledge Baseを使ったマルチテナントなナレッジベースの構築から始まり、マルチエージェントによるタスクの実行、テナントごとの粒度の細かい権限管理の方法やテナントごとのコスト管理まで広く扱っています。

まずは、ナレッジベースを作成してマルチエージェントが実行されるところまでをハンズオンしました。ナレッジベースに存在する問題に対しては、以下のようにナレッジーベースサブエージェントが呼び出されて解決法が示されます。

一方で、ナレッジベースに存在しないエラーの場合、ログを確認するサブエージェントと、コードを生成するサブエージェントを動かして解決策を自ら生成します。このように、複数のサブエージェントが状況にあわせて問い合わせタスクを完了していきます。ただ、何度も実行してみると回答が毎回微妙に違っており、微妙な解決策も提示されたりします。もし実際の問い合わせエージェントがこのような動作であれば、ユーザーは期待する解決策に近いものが出るまで何度も同じ質問を繰り返すでしょう。そうすると、ユーザーの体験劣化だけでなくAIエージェントのコストも心配になります。先のセッションでも強調されていた決定論的なコレオグラフィの重要性をワークショップで実際に感じることができました。


また、ABAC(Attribute Based Access Control)を使ってS3に格納されているデータの誤った呼び出しを防ぐマルチテナント分離も実装しました。こちらはS3のリソースポリシーを利用したもので、書籍「マルチテナントSaaSアーキテクチャの構築」でも言及されているリソース側での権限制御です。その場でワークショップインストラクターの方に聞いたところ、Amazon Bedrock Knowledge Basesで1つのナレッジベースにマルチテナントなデータを入れた場合は、元データのメタデータをもとに呼び出し時に応答情報を分けるのみでS3のリソースポリシーのようなリソース側での厳格な権限分離制御はできないようでした。その一方で、AWSアカウントあたりに作成可能なナレッジベースの数もそれほど多くないようで、今のところアプリケーション側でしっかり制御する必要があるようです。
※アカウントあたりのナレッジベース数について正確なクオータを見つけることができませんでした。過去のユーザーの投稿で50が上限という記述を見つけましたが、ワークショップ内で聞いた話ではもう少し大きかったと思います。
Amazon Bedrock Knowledge Base -Limit of 50 Knowledge Base

おわりに
re:Invent初日はAIエージェントについてブレイクアウトセッションとワークショップを通して学ぶことができました。狙ったわけではないですが、同じような技術的話題についてブレイクアウトセッションで概要を掴み、ワークショップで実践する流れができるとそれぞれのセッションの理解度が深まりますね。まだ始まったばかりのre:Invent明日以降も楽しんで学びたいと思います。
カミナシではラスベガスでもポケモンカードショップに行くことを忘れないソフトウェアエンジニアを募集しています。興味がある方はカジュアル面談からご連絡ください!
