Amazon Web Services ブログ
【開催報告】AWS Summit Japan 2026 — 「AI ペルソナ達がビジネス課題解決を加速する」バーチャル AI エキスパート
AWS Summit Japan 2026 の流通小売・消費財・飲食ブースにて、私たちは「バーチャル AI エキスパート」と題したプロトタイプを展示しました。
「AI が進化しても、ビジネスの意思決定にはまだまだ手間がかかっていませんか？」
これは展示で来場者の方にお伝えした最初の問いかけです。市場調査、技術選定、設計案……判断に必要な情報を集めるだけで時間が過ぎていく。複数の専門家の視点を揃えたいけれど全員集めるのは大変。AI に聞いてもハルシネーションが心配で結局自分で確認し直す―-―。
実際に90% の企業が生成 AI ツールを導入済みでありながら、本番環境まで到達したのは 44%——理由は人材不足、コスト懸念、そしてモデルのハルシネーションリスクです (AWS Generative AI Adoption Index 2025)。2026 年の IDC 調査でもこの傾向は変わらず、スキル不足（55%）が最大の実装障壁として報告されています (IDC, 2026)。
バーチャル AI エキスパートは、これらの課題に対して 「複数の AI ペルソナが専門家チームとして自律的に調査・分析・議論し、あなたは最終判断だけすればよい」 というコンセプトの体験を提供するシステムです。
AI Expert display
デモの流れ
まず議論したいビジネステーマを声で伝えます。「OMO戦略の最初の一歩」「流行の押し活にあわせた施策」——お題は自由です。次に、議論に参加させる AI ペルソナを選びます。CEO 視点、IT Director 視点、店舗マネージャー視点、顧客価値視点……それぞれ異なる専門性と立場を持つペルソナが「バーチャル専門家チーム」を構成します。
テーマとメンバーが決まると、各ペルソナが一斉にリサーチを開始。CEO は市場規模と競合を調べ、IT部長 は技術的実現性を検証し、店長は現場オペレーションの制約を洗い出す。それぞれが独立に調査した結果を持ち寄り、多角的な議論が始まります。モデレーターのペルソナが議論を取りまとめ、改善役のレッドチームが厳しい指摘を入れます。ペルソナ同士が互いの見解に反論し補強し合う過程はリアルタイムで画面に可視化されます。
議論が収束すると成果物が出力されます。エグゼクティブサマリー、各ペルソナの分析詳細、アーキテクチャ案やコスト試算、そして PoC やイメージアップに使えるサンプルアプリケーションまでデプロイされます——「数分の対話」で「数週間かかっていた意思決定の下準備」が完了します。
開発体制とプロセス
4 名の SA（Solutions Architect）で日常的な業務と並行して AI Coding Agent の Kiro を活用し、約 3 週間のスプリントで設計から開発までを完了させました。システム開発において AI と開発者が効果的にコラボレーションするためのメソドロジーである AI-DLC（AI Development Life Cycle）を使い、AI を交えたチームの対話で要件をまとめ、PACT コントラクト（ユニット間インターフェース定義）を先に決めてから並行開発する方式を採用しています。それでは、ここからは各ユニットでどのように考え、工夫して開発したかをご紹介していきます。
開発ユニット構成
技術要素
technical stack
Unit1: エージェントの思考を “見せる” —— フロントエンド
Unit1 は、来場者が直接触れる唯一のユニット——システムの「顔」です。バーチャル AI エキスパートの体験価値は「複数の専門家がチームで議論している様子が”見える”こと」にあります。裏側でどれだけ高度なマルチエージェントが動いていても、それが来場者に伝わらなければデモとしての価値は半減します。Unit1 の使命は、Unit2（オーケストレーター）から流れてくるエージェントの思考・調査・議論の過程を、リアルタイムに、直感的に可視化することでした。
- 3D アバター表示 —— 来場者との対話の”顔”となる VRM の 3D モデルを 1 体表示（司会役）。リップシンクで話しかけられる相手としての存在感を出す。※ アバターはペルソナごとに切り替わるものではない
- カード型 UI（Research / Discussion パネル）で「ペルソナ」を可視化 —— 各 AI ペルソナ（CEO / IT Director / 店舗マネージャー / 顧客価値 / Red Team … ＋ 司会のモデレーター）の調査結果（findings）や議論の発言を、ペルソナ単位のカードとしてストリーミング表示し、「今どのペルソナが発言・調査しているか」を一目でわかるように。ペルソナの視覚表現はアバターではなく、このカード UI が担う
- 音声入出力 —— Nova 2 Sonic とのリアルタイム音声対話のフロント側ハンドリング（マイク入力・音声再生・リップシンク）
- オペレーター向けコントロールパレット —— 会場でスタッフがデモを操作するための操作盤
- Web UI 全体 —— テーマ選択・ペルソナ選択から、最終成果物（エグゼクティブサマリー / 詳細 / Next Step、PDF・PPTX ダウンロード）閲覧までの一連の体験
アバターの切り替えも好評でした
技術スタック
フロントエンドは CloudFront + S3 で配信する SPA として構築しました。
- React + TypeScript (strict) + Vite —— ビルド／開発サーバーは Vite
- Three.js + @pixiv/three-vrm —— アバターは単なる 2D 画像ではなく VRM の 3D モデル。Three.js で描画し、姿勢・口形状・視線をリアルタイム制御
- framer-motion —— カードやパネルの UI アニメーション ／ lucide-react —— アイコン
- CSS Modules + CSS カスタムプロパティ —— スタイリング（外部 UI フレームワークは不使用）
- 状態管理は外部ライブラリを使わず自作 —— Redux/Zustand 等は入れず、WorkflowStateMachine（純粋な switch/case の状態マシン）を React のカスタムフックでラップ
コードは責務ごとに features/（connection / workflow / voice / vrm / control-palette / idle）と hooks/・components/・lib/ に分割しています。
AG-UI プロトコルによるイベント駆動 UI
UI の描画は、基本的にすべて AG-UI プロトコルのイベントを起点に更新されます。RUN_STARTED / STEP_STARTED / TEXT_MESSAGE_* / TOOL_CALL_* / CUSTOM / RUN_FINISHED といったイベントを受信し、自作の WorkflowStateMachine にディスパッチしてフェーズ（idle → research → discussion → decision → result → completed）を遷移させ、対応する UI（司会役アバターの状態、ペルソナカードの追加、ステータス表示）に反映します。フローの真実（source of truth）は常に Unit2 側にあり、フロントは「今の状態を描く」ことに専念できます。
苦労した点・工夫
1. WebSocket と SSE が別 MicroVM に振り分けられる問題（→ WS 一本化）
当初のプロト構成では、Unit2
との通信を 2 系統に分けていました。
画像：
ところが AgentCore Runtime へデプロイして実機確認を始めたところ、ローカル（localhost）では再現しなかった問題にぶつかりました。/invocations（SSE）と /ws（WebSocket）のリクエストが、それぞれ別々の MicroVM に振り分けられてしまうのです。
Started server process ［349］ ← /invocations を受ける MicroVM Started server process ［350］ ← /ws を受ける MicroVM ［SSE］ /invocations start: pid=349, queue_id=...393872 ［WS］ connected: pid=350, queue_id=...809232 ← queue が別物
Unit2 側で agui_queue を session_id に紐づけて管理していても、MicroVM が異なるとキューが共有されない。結果、/ws で受けたイベントを登録しても /invocations 側に送出されず、フロントに AG-UI イベントが返ってこないという事象が起きました。
解決策：通信を /ws（WebSocket）に一本化。SSE で流していた AG-UI イベントも WebSocket メッセージ（type: "agui_event"）に載せて配信するよう変更し、MicroVM 分割の影響を受けない構成にしました。SSE クライアント（useAgentStream / AguiClient）は「WebSocket 統合により不要」として @deprecated にしました。
2. SPA での認証 —— SigV4 presigned URL（Cognito Identity Pool 経由）
フロントエンドが CloudFront + S3 の SPA で動くため、SigV4 の素直な適用ができません（JavaScript 側に恒久的な認証情報を置けない）。当初は「Cognito ユーザープール＋トークン発行 Lambda で JWT を発行し、Sec-WebSocket-Protocol に載せる」案を検討しましたが、最終的にはより素直な SigV4 presigned URL 方式に落ち着きました。
- Cognito Identity Pool（Basic/Classic フロー）で未認証の一時 AWS クレデンシャルを取得。GetId → GetOpenIdToken → STS AssumeRoleWithWebIdentity の2ステップ。
- ※ bedrock-agentcore は Enhanced フローのセッションポリシーでブロックされるため、Classic フローで IAM ロール権限をそのまま取得する。
- AgentCore Runtime の WSS エンドポイント（
wss://bedrock-agentcore.{region}.amazonaws.com/runtimes/{arn}/ws）を SigV4 presign（X-Amzn-Bedrock-AgentCore-Runtime-Session-Idをクエリ付与）。 new WebSocket(presignedUrl)でそのまま接続。来場者ログインは不要。ローカルはws://localhost:8080に認証なし接続、環境変数の有無で自動切替。
3. Nova Sonic のタイムアウト対策（無音 PCM キープアライブ）
Nova Sonic（BidiAgent）は 55 秒以内に音声バイトまたはインタラクティブコンテンツを受信しないとタイムアウトします。来場者が黙っている時間帯でも接続を維持するため、無音 PCM を定期的に送信してキープアライブする実装を入れました。
4. ペルソナの発話表現 —— 音声ではなくテキスト＋イラストのダイナミック表示
複数のペルソナが発言する様子をフロントエンドでどう表現するかは、何度も検討を重ねたポイントです。当初は「各ペルソナに音声で発話させる」案もありましたが、次の理由で却下しました。
- Nova 2 Sonic で用意できる音声パターンが少ない —— ペルソナごとに声を作り分けるのが難しい
- 従来のテキスト読み上げ（TTS）approach ではラグが生じ、インタラクティブさを欠く
- ペルソナの発話完了を待つ時間が、思いのほか長く感じる —— デモのテンポが悪くなる
代わりに、テキストとイラスト（ペルソナカード）の組み合わせで、表示がダイナミックに入れ替わる UI 表現を採用しました。「誰が今話しているか」をカードの切り替えとイラストで直感的に見せることで、音声を待たずにテンポよく議論の流れを追え、デモ体験者を退屈させない工夫としています。（司会役アバターの音声は来場者との対話に専念させ、ペルソナ間の議論はこの視覚表現に寄せる、という役割分担です。）
5. 並列調査を「できた順」に賑やかに見せる
当初、各ペルソナの findings は全員分が揃うまで待ってから表示していたため、画面が長時間沈黙していました。デモとしては致命的です。
- 各ペルソナの調査を並列実行した上で、完成したペルソナから順次カードを表示
- 並列ストリーミングのため、WorkflowStateMachine 内に message_id → ペルソナ名 のマップ（messagePersonaMap）を持ち、どの delta がどのカードに追記されるべきかを判別
- TOOL_CALL_* イベントを拾って「今どのペルソナが」「どのツールで」調べているかを表示（personaToolHistory / personaToolCount）
- 音声が黙っている間も画面上のイベントが賑やかで退屈しない体験に
6. 3D アバターとリップシンク
対話の司会役として表示する VRM の 3D モデル（アバター）は、来場者に「話しかけられる相手」としての存在感を持たせるために作り込みました。前述のとおりアバターは司会役の 1 体で、各ペルソナ（CEO / IT Director …）はカード UI 側で表現しています。
- リップシンク：LipSyncController が Nova Sonic の音声出力（AudioOutputManager）を解析し、VRM の口形状（表情モーフ）を音声再生に同期。アバター切替時にも SceneManager へ再接続
7. 会場運用のためのコントロールパレット
会場のスタッフがデモを操作できるよう、画面右のグロー付き丸ボタンから開く操作盤を用意しました。
- トップ：デモスタート（挨拶送信）／アプリリセット／手動再接続／履歴削除／マイク ON/OFF／入力欄 ON/OFF／トランスクリプト（字幕）ON/OFF
- 定型文：「こんにちは」「ひとつめで〜よっつめで」「今どんな状況？」「はい」「いいえ」などのワンタップ送信
- アバター設定：アバター切替・回転・左右位置調整（実装済み。ライト調整は検討の末に削除）
会場の騒音レベルが読めなかったため、騒音がひどい場合はマイクを無効化し、定型文ボタン送信で進行できるフォールバック運用を用意。切断時は 2 秒後に自動再接続します。
8. 対象デバイス（縦型ホログラムディスプレイ）と実機確認
メイン展示は Proto Luma（2160×3840）の縦型ホログラムディスプレイ。ほかに小型の Proto M2（1080×1920） や PC ブラウザ（開発・デバッグ用）にも対応できるよう画面を設計しました。
苦労したのは実機とのギャップです。レスポンシブデザインで作ったつもりでも、いざ実機で確認するとレイアウトが崩れることが多く、当初は手を焼きました。転機になったのは、4K のモバイルディスプレイを縦置きにすると Proto の縦長・高解像度をかなり近くシミュレーションできると分かってからで、そこからは手元で崩れを潰せるようになり開発がスムーズに進みました。
それでも、Proto のホログラムディスプレイは発色具合や、重なり合った半透明要素の見え方が独特で、手元のディスプレイでは再現しきれません。この部分は最後まで実機確認 → 再デプロイを何度も繰り返して詰めていきました。
やりたかったけどあきらめた点
- アバターは女性のみ・声も共通。展示版では選択できるアバターが女性のみで、Nova Sonic の声も全ペルソナ共通です。男性アバター対応やアバターごとの声の作り分けは見送りました。
- Proto 本来のアバターのようなホログラム感（立体感）の再現。Proto 本来のアバターはスタジオでライティングして影をつけて撮影した写真を AI で動かしており立体的に見えています。VRM 版でもアバターの影の表現などにより立体感をある程度再現できるはずであると考えており、継続的に改善に取り組んでいきます。
振り返り
AG-UI プロトコルにより「エージェント → UI 間の通信」がきれいに分離されたことで、フロントエンドはバックエンドの実装変更の影響をほぼ受けずに開発を進められました。UI は「AG-UI イベントをどう描くか」だけに集中でき、状態管理もシンプルな自作の状態マシン1つに閉じ込められたことが、4 人並行開発の中で Unit1 を安定して仕上げられた大きな要因です。
一方で、ローカルとクラウド（AgentCore Runtime）で挙動が変わる——WebSocket/SSE の MicroVM 分割——という、分散環境・マネージドサービスならではの落とし穴にもぶつかりました。加えて、開発用 PC と Proto のホログラムディスプレイ上での見え方の違いにも悩まされました。「まず実機にデプロイして、実データ・実ログで確認する」ことの重要性を痛感した開発でもありました。
来場者の反応でも「マルチエージェントのプロセスが可視化されていること」への驚きの声を多くいただき、3D アバターとカード型 UI による可視化がデモ全体の体験価値に直結したことを実感しています。
Unit2: 「話す」と「考える」を同時に回す —— オーケストレータの設計
Unit2 はシステムの中枢であるオーケストレータです。来場者との音声対話を受け持ちつつ、背後にいるリサーチエージェント（Unit3）や議論エージェント（Unit4）を A2A プロトコルで呼び出し、その進捗を AG-UI イベントとしてフロントエンド（Unit1）にリアルタイム配信します。
Unit間の連携
技術選定
Nova 2 Sonic: 自然な音声対話
サミットのブースで来場者にテキスト入力を求めるのは非現実的です。Speech-to-Speech モデルである Nova Sonic を採用することで、発話の途中でも自然なタイミングで割り込み（バージイン）ができる体験を実現しました。
Nova 2 Sonic は正式には日本語対応が完了していない段階でしたが、十分に会話可能なクオリティがありました。会場の騒音レベルは未知数だったため、フォールバックとして UI からのタッチ操作も用意しています。
A2A: エージェント間通信の標準化
4名での分業開発において、各 Unit を独立したサービスとして開発・デプロイできる構成が必須でした。A2A プロトコルにより Unit 間のインターフェースが JSON-RPC 2.0 で標準化され、通信仕様をゼロから設計する工数を大幅に削減できています。AgentCore Runtime にデプロイすると、エンドポイント管理・SigV4 認証・スケーリングも自動で提供されます。
AG-UI: マルチエージェントの可視化
「裏で AI が何をしているかわからない」状態はデモとして体験が悪い。AG-UI プロトコルで各エージェントの思考・ツール使用・議論の進行をフロントエンドにストリーミングし、来場者が「今、CEO が市場データを調べている」「IT 部長が技術実現性を検証中」と視覚的に追える体験を目指しました。
全体アーキテクチャ
苦労した点・工夫した点
A2A → AG-UI の変換レイヤー
AG-UI はフロントエンドとオーケストレータの間のプロトコルであり、オーケストレータの向こう側にいるサブエージェントのイベントを自動中継する仕組みはありません。Unit3/Unit4 から A2A で返ってくるストリーミングイベントを、Unit2 側で AG-UI 形式に「詰め直し」てフロントに転送する変換レイヤーを自前で実装する必要がありました。
A2A の artifact_id パターンをパースしてペルソナ切替・ツール使用・議論結果を識別し、それぞれ対応する AG-UI イベントに変換しています。設計としてはやや泥臭いですが、現時点のプロトコル仕様上の制約として妥当な判断でした。
音声対話と長時間タスクの共存
リサーチ（数十秒）や議論（数分）が走っている間、Sonic に進捗を音声で中間報告させたいという理想がありました。しかし BiDi セッション中にテキストで進捗を注入すると、モデルがユーザー発話として解釈し、予期しない応答を生成してしまいます。
最終的には、進捗表示は画面（AG-UI 経由）に集中させ、音声はユーザーとの対話に専念させるという役割分担に落ち着きました。フロントエンド側でリアルタイムにイベントが可視化されるため、音声が黙っている間も退屈しない体験になっています。来場者が話しかければ Sonic は応答するので、完全に無音になるわけでもありません。
プロンプトだけでのフロー制御の限界
「テーマ選択 → リサーチ → 議論」という段階的フローをプロンプトだけで安定させるのは困難でした。コード側でステップゲートを実装し、ツールが正しい順序でしか呼べないようガードレールを設けるハイブリッドアプローチを取っています。
開発プロセス
PoC 駆動の仕様策定
Unit2 は全 Unit との結節点であるため、まず Proto リポジトリで PoC を複数回実装し、実際に動かしながらインターフェース仕様書を策定しました。この仕様書自体もコーディングエージェントとの対話で作成しています。
コーディングエージェント全員活用
チーム全員がコーディングエージェントを使っていたため、仕様変更や手戻りが発生しても修正の時間的コストが小さいのが大きなメリットでした。一方で、エージェントのコンテキストウィンドウが埋まってくると外部リファレンスの参照を怠り、場当たり的な推測で修正を繰り返す悪循環に陥りがちで、「まず公式ドキュメントを確認して」と都度指示する必要があったのが課題です。
タイムライン
PoC 着手（5/24）から本番デモ（6/24）まで約1ヶ月。PoC を約10日で2回回して仕様を固め、本番リポジトリに移植してから約2週間で完成しました。
来場者の反応から
- PoC アプリが実際に完成する点に多くの方が関心を示した
- マルチエージェント概念は昨年より自然に受容されており、特段の説明なく理解いただけた
- 実在人物のペルソナを再現して壁打ち相手にしたい（上司、取引先…）という声を複数いただいた
Unit3: 視点の数だけ調査がある —— マルチペルソナ並列リサーチ
Unit3 は、選ばれた複数の AI ペルソナが それぞれの専門家の視点で並行してリサーチを行い、調査結果（findings）を返すユニットです。同じテーマでも「経営者は競合戦略を、店舗運営部長は現場オペレーションを、IT部長は技術実現性を」と、役割ごとに異なる情報源・着眼点で調べます。findings は Unit2 経由で Unit4（議論）に渡り、多角的なディスカッションの土台になります。議論そのものは Unit4 での対応とし、Unit3 は「調査専門」に役割を絞りました。この線引きが技術選定をシンプルにしてくれました。
技術選定
- A2A Server として実装：Unit2 から A2A（JSON-RPC 2.0）で呼ばれる構成。各 Unit を独立に開発・デプロイでき、AgentCore Runtime にそのまま載せられます
- ペルソナごとに異なる情報源：CEO は Amazon Bedrock AgentCore Gateway の Web Search（2026-06-17 GA、Streamable HTTP MCP + IAM/SigV4）で実 Web 検索、IT部長は AWS Knowledge MCP、店舗運営部長・CFO は Bedrock Knowledge Base（社内文書想定）と、役割に応じた道具を割り当て。「複数のデータソースを使い分けるマルチエージェント」を見せる狙いです
- ベクトルストアに S3 Vectors：OpenSearch Serverless の固定費に対し、ストレージ課金中心でPoC向き。少量ダミー・低頻度クエリという展示要件に最適でした
ペルソナ達の調査結果報告
設計判断: 調査は「協調」ではなく「独立並列」
マルチエージェントというと Strands の Swarm/Graph で「エージェント同士が会話しながら協調する」構成を想像しますが、Unit3 の調査は違いました。各ペルソナの調査は 互いに独立（社長の調査と店舗運営部長の調査は会話しない）で完了し、その後の議論のための準備としました。
ペルソナへのツール割り当ては2段構えとしています。立ち上げ時にコードが役割に応じた道具箱だけを渡し（役割外の調査を防ぐ）、実行時にどれをいつ呼ぶかは Strands の agentic loop に委ねます。
苦労した点・工夫した点
a2a-sdk のバージョンの違い：結合仕様が要求する a2a-sdk 1.1.0 と、Strands の ［a2a］ extra が要求する 0.3.x 系が非互換でした。解決策は「Strands は Agent + MCP のエンジンとしてだけ使い、A2A サーバー層は 1.1.0 を生で書く」。加えて 1.1.0 特有の API 差分（Task の事前 enqueue、streaming 受信の分岐方法）にもいくつか足を取られました。
Web 検索の乱発を抑える検索制限プロンプト：AgentCore Web Search Gateway への切り替え時に、LLM が同義クエリで何度も検索を投げる問題に直面しました。プロンプトで「検索回数最大4回」「1回あたり maxResults ≥ 20」「同義クエリ禁止」を明示することで、必要十分な情報量を短い時間で集められるようになりました。
「それっぽい回答」を信じない検証：LLM は失敗しても、もっともらしい URL や数字を捏造します。findings に入った URL が本物か、サーバーログの実際の HTTP アクセスと突き合わせて裏取りしました。IT部長の調査でも実在の AWS 公式ドキュメントが引用されていることを確認しています。
なお、調査結果は完了したペルソナから順に画面へ流す方式で、遅いペルソナに引きずられないテンポにしています。
やりたかったけどあきらめた点
- ペルソナ別音声の作り分け：現状は全員同じ声
- 社内ナレッジの本格活用：GraphRAG で過去実績や社内文書を深く取り込む構想はあったが、KB データ整備の時間が足りずダミー最小構成での実証にとどめた
- SharePoint MCP 連携：CFO が社内文書を直接引く案は認証設定のハードルで Bedrock KB のダミー代替に落とした
振り返り
A2A インターフェースは固定、中身だけ差し替え —— Bedrock 直叩き → Strands Agent 化 → MCP 追加 → 複数ペルソナ並列化 → AgentCore Web Search 移行と段階的に進化させても findings のフォーマットと A2A の形を変えなかったので、Unit2 との結合に影響を出さずに済みました。また、AgentCore Web Search Gateway のツール名（websearch___WebSearch）や AWS Knowledge MCP のツール名（aws___search_documentation）などドキュメントでは分からない点は疎通スクリプトで実際に叩いて確認し、「まず動かして実データを見る」を徹底したのが安定につながりました。
Unit4: ペルソナが議論し、反論させ、合意に導く — AI ディスカッション
Unit4 は、Unit3（リサーチ）が各ペルソナの視点で収集した調査結果を受け取り、複数の AI ペルソナが会議室で議論するかのようにディスカッションを行い、最終的な結論と報告資料＆PoCアプリケーションを生成するユニットです。人間の会議で言えば「ファシリテーターが参加者を順番に指名し、論点を深掘りしながら合意形成を導く」プロセスを、AI エージェントとして再現しています。
設計判断：Round-Robin か Swarm か
マルチペルソナの議論をどう制御するか。大きく2つの方式を検討しました。ひとつは各ペルソナが自律的に発言タイミングを判断する Swarm 方式、もうひとつはファシリテーター Agent が各ペルソナを順番に指名する Round-Robin 方式です。Swarm はマルチエージェントの強みを活かし、同時に複数のペルソナが考えを発言し、実際の人間の議論に近い作りに見えます。一方で、Round-Robin は各ペルソナに均等な発言権が渡りますが、直列の処理になるので時間もかかり、議論の流れが予測可能でダイナミックな議論が生まれないかもという懸念がありました。
しかし、実際に試してみると「それまでの会話の流れを踏まえて発言させる」「見ている人が議論の流れを理解して割り込める様にする」といったことを考えると、Round-Robin がこのユースケースでは適していることが分かりました。
苦労した点：モデレーターとレッドチーム
もう一つの設計判断はモデレータとレッドチームを追加したことでした。当初は順番に発言をして、代表ペルソナが議論をまとめて資料作成に進める方式でした。しかし、議論の質を高めるために反対意見や議論の穴を指摘する「Redteam」という役割を追加してドライに厳しい指摘をする役割を入れると、今度は指摘が厳しすぎて毎回議論が完了とならずに「再議論」を繰り返す様になってしまいました。そこで、モデレータという役割を追加して彼／彼女には司会と資料作成の分担を指示させると同時に、指摘に対して「不備があっても進める／進めない」という意思決定をさせることにしました。同様に、レッドチームも厳しい指摘だけでなく改善案も出す様にすることで建設的な議論が進み結論がまとまる様になりました。人間の会議と同じことが起きていますね。
設計判断：ペルソナの分離レベル
複数のペルソナを扱うにあたって、ペルソナごとに実行環境（AgentCore Runtime）を作るか、一つの実行環境の中で共存させるかという判断もありました。当初は、Amazon Bedrock AgentCore Harness も公開されており、自然言語のみで Agent やツールを柔軟に定義できることからペルソナ毎の環境を作ることも考えていました。しかし、今回は散発的に各ペルソナが発話するのではなく、ラウンドロビンで制御した議論を行い成果物をまとめる一定のサイクルとなるため、一つのランタイムでプログラム制御で実装することでオーバーヘッドが少なくなると判断しました。
実際のユースケースで、例えば既存の「採用エージェント」「出店計画エージェント」のような独立して複雑な処理を行う様なエージェントと組み合わせて議論させる様な場面では、メモリ／コンピュート／ツールとそれぞれのエージェントに必要なリソースを使う方式の方が適している場合もあるかと思います。
苦労した点：Quick による PoC アプリの同時生成
カバー画像を作成し、項目レベルのテンプレートに合わせて各エージェントがパワポ風のHTMLとチャートやグラフを作成することはOSSのライブラリを使うことで比較的簡単に実現できましたが、議論の結果に合わせたPoCアプリを同時生成させるかには悩みどころがありました。Amazon Quick で自然言語からアプリケーションを NoCode ツールの様に開発してくれる機能が Preview で公開されていたのですが、それには Agent が叩ける API の口が存在していなかったからです。
そこで、AgentCore Browser の機能を使って Agent にブラウザ操作をさせて Amazon Quick にログインしウェブの機能を使って議論の結果をPOSTする実装をしました。APIが用意された環境では Agent は強力ですが、そうでないシステムとの連携ではこの様なワークアラウンドを考える必要があります。デモの中では見えない、「議論からイメージ画像作成のプロンプトを作る単発の推論」、「議論の結果からカバー画像を作成する推論」、「ブラウザを操作して議事録からアプリを作成するエージェント」なども裏で連携して動いています。
ペルソナ達が作成したサンプルアプリ
やりたかったけどあきらめた点
まずナレッジベースを活用した議論として、GraphRAG で社内情報、過去の実績、外部のナレッジベースを取り込み、議論の根拠をより具体的にする構想がありましたが、3週間のスプリント内では断念しました。
議論に対する割り込みや成果物の自動ブラッシュアップも先送りとなりました。議論の途中で、「そこは深掘りしなくて良い」「ここを考えてほしい」といった割り込みや、一度作った資料を改善させることも仕組み的には可能ですが、デモの１サイクルを短く収めるために省略しました。
まとめ
AWS Summit Japan 2026 の 2 日間で、多くの来場者の方にバーチャル AI エキスパートをご体験いただきました。最も反響が大きかったのは「AI が議論する」という体験そのものです。単なる Q&A ではなく、複数の視点が交わり「考えが深まっていくプロセス」が目の前で可視化される——来場者からは「すごい壁打ちができるということですね」「社長に見せたら、やるって言いそう」といった声をいただきました。音声対話による没入感、そしてアーキテクチャ図やコスト試算まで含んだ「持ち帰れる」成果物が出る点にも驚きの反応が多かったです。
技術的な振り返り
今回の開発で得た最大の学びは、A2A と AG-UI という 2 つのプロトコルの有効性です。A2A が「マルチエージェント間の通信」を、AG-UI が「エージェント → UI 間の通信」を標準化したことで、4 人が異なる Unit を独立に開発しながら最後にスムーズに結合できました。PACT コントラクトを先行して定義したことがこの並行開発を支えた大きな要因です。また Strands の様なエージェント開発フレームワークに対応した AgentCore Runtime によって AI Agent に適したスケーリングできるインフラが用意されていることも大きな利点でした。
今後の展望
展示はプロトタイプとしての実証でしたが、今後はナレッジベースを活用した社内情報に基づく議論、ペルソナの動的追加・削除、成果物の反復ブラッシュアップ、そしてお客様環境へのデプロイ簡素化を進めていきます。
会場でいただいた質問
- Q: ペルソナはカスタマイズできるか？ — はい。専門領域、許可するツール、口調など全て設定が可能です。（社内の承認者や現場リーダーなど自社特有のペルソナ設定をイメージされる声が多く聞かれました。）
- Q: 社内データを接続できるか？ — ペルソナが使用するツールとしての MCP や Bedrock Knowledge Bases のデータソースから接続可能です。
- Q: 実際のシステムとして使えるか？販売／提供されているか？ — この仕組み自体はコンセプトの参考展示で、このソリューション自体は OSS としては公開されていません。しかし、技術的には AgentCore Runtime など AWS サービスと OSS のライブラリで構築していますので、みなさまの環境でも同等のものを構築いただけます。
- Q: ハルシネーションはどう防いでいるか？ — Web サーチ、ナレッジベースによる事実の根拠づけ、ペルソナによる相互指摘によって低減しています。