
こんにちは。NRIの平井です。AWS・Azureの技術支援を担当しています。
ここ1〜2年の間に、生成AIの活用は徐々に一般化し、「AIを試してみる」段階から「実際の業務へ適用する」段階へ移行しています。これに呼応するように、AWSのAI関連サービスも急速な進化を遂げてきました。
その一つに、「エージェント」があります。AIで考えたことをタスクとして実際に実行するエージェントを使いこなせるかは、今後のクラウド活用においても鍵となる技術だと考えられます。
そこで私たち、パブリッククラウド運営サービスを行うQUMOAチームでは、Amazon Bedrockエージェントを活用し、実際の業務にどのように適用できるかを検証するプロジェクトを立ち上げました。
本記事では、エージェント構築の経験とその過程で得られた知見を中心に、マルチエージェント環境の設計・開発・構築について解説します。AIエージェントの導入を検討されている方々の参考になれば幸いです。
Amazon Bedrock エージェントとは
まず、AIエージェントとは何かについて簡単に説明します。
AIエージェントは、人工知能技術を活用して、自律的に目標を達成する知的なシステムです。環境を理解するという「認識」を経た後に、「学習」という経験から改善するよう考えます。そのうえで、最適な選択をとるよう「判断」を下し、実際にタスクとして「行動」するまで実施するところが特徴です。

それをAWSのマネージドなサービスで提供しているのが「Amazon Bedrockエージェント」です。こちらは、Amazon Bedrock(以下、Bedrock)の基盤モデルを活用して特定のタスクを実行するAIアシスタントを構築できるサービスです。エージェントが実行できるAPI操作を定義でき、社内文書などの独自データを参照可能な知識ベース連携機能も備えています。また、複数ターンの会話の文脈を保持する機能や、テキストだけでなく画像による入力認識、プロンプトの作成、テンプレートのバージョン管理なども可能です。
以上で紹介した機能を組み合わせることで、単なる質問回答だけでなく、実際のシステム操作をインターラクティブに行えるエージェントを構築することができます。
ちなみに、AIエージェントはAWS StepFunctionやAmazon ECSを使って構築することも可能です。これらはAWSのマネージドなサービスでない分、開発柔軟性や予測可能性などはBedrockのエージェントよりも高いかもしれませんが、今回は迅速に使えることを最優先としてBedrockを採用しました。
マルチエージェントなアプローチ
前述したように、エージェントは複数の機能・タスクを組み合わせることで、その威力が発揮されます。そのため、一問一答だけでは解決できないような課題に対して、複数のエージェントを組み合わせる「マルチエージェント」の活用が活発になることでしょう。
マルチエージェントなアプローチを採用すると、次のような特徴が得られます。
関心の分離
各エージェントが特定の専門領域に集中でき、それぞれが得意なタスクに特化できます。
モジュール性
複雑な問題を小さな単位に分割でき、全体に影響を与えずに個別の改善が可能です。
多様性
複数の視点からの処理により、より質の高い結果が得られ、AI特有の幻覚やバイアスを軽減できます。
再利用性
一度作ったエージェントを他のシステムでも再利用でき、LangGraphやAutoGenなどのツールでエコシステムを簡単に構築できます。
また、マルチエージェントシステムの設計では、下図のように協調方式と計画タイプの選択が重要となります。

協調方式には以下4つがあり、どのようにエージェント同士を関連付けるか検討する必要があります。
- 協調型: エージェント同士が協力して目標達成
- 競争型: 複数の解決策から最良のものを選択
- 混合型: 協調と競争を組み合わせたアプローチ
- 階層型: 指揮系統を持ち、上位エージェントが下位を管理
計画タイプにも以下2つがあるので、これらの特徴と組み合わせから最適なアプローチを選択することが求められます。
- CPDE: 中央で計画、各エージェントで実行
- DPDE: 計画も実行も各エージェントが分散して担当
マルチエージェント環境の構築については、適用したいタスクや業務に対してどのような方針・戦略をとるかを予め定めておくことで、エージェントをより効果的に開発/実用することに活かされます。
マルチエージェント環境の設計と実装
それでは、今回設計したマルチエージェント環境について解説します。題材として、「QUMOAで行っている社内のセキュリティガイドラインに準拠したAWSアカウントの作成」という業務を、マルチエージェントで実行できるように環境構築しました。

申込書やヒアリングシート記載の情報をリクエストとして受け付けて、AWS AppSyncを経由して司令塔役のエージェントに伝達するという流れで設計しています。

この司令塔役のエージェントはSupervisor Agentと呼ばれたりします。Supervisor AgentはBedrockと連携し、リクエスト分析、アカウント作成、セキュリティ設定といった、タスク実行に特化したエージェント(Collaborator Agentと呼ばれる)に処理を振り分けます。

各Collaborator AgentはそれぞれBedrockのナレッジベース、Lambda Functions、Organizations APIなどと連携して必要な処理を実行します。この構成により、Supervisor Agentがユーザーとの対話を担当し、タスクの種類に応じてCollaborator Agentに処理を振り分ける流れを実現しています。
マルチエージェントアプローチを選択した理由
AWSアカウント作成プロセスの自動化にあたり、最終的に階層型の協調方式と集中型計画分散型実行(CPDE)のアプローチを採用しました。
背景としては、「AWSアカウント作成」というタスクには多様なステップがあり、一つのエージェントではカバーしきれない専門性が求められます。リクエスト分析、アカウント作成、セキュリティ設定など、それぞれの領域に特化したエージェントを準備することで、各タスクの精度を高めることができます。
開発効率の観点からも、各エージェントそれぞれの専門領域に集中した開発が実現できるため、機能単位で分けて並行開発できるメリットは大きいです。新たな要件やエラーが発生した場合でも、関連するエージェントのみを修正すればよいため、メンテナンス性にも優れています。
検討段階では単一の万能エージェントを準備して、「一つのエージェントの方がシンプルで会話の文脈も保持しやすいのでは」という側面もありましたが、実装のしやすさという観点で、専門性と堅牢性を優先させたマルチエージェントのアプローチは有効的でした。
マルチエージェント環境構築に関するおすすめノウハウ
ここからは、特に検討した設計や、開発にあたって取り入れた工夫などについてご紹介します。
エージェント間の連携設計
エージェント間の連携には、BedrockのMulti-agent collaboration機能と自前実装の2つのアプローチを検討しました。Multi-agent collaboration機能は、2024年のre:Inventで発表された機能で、個別に他エージェント呼び出しを制御する仕組みを作る必要が無くなりました。

一方で、Bedrockのエージェント以外のエージェントを呼び出せないという制約(2025年3月時点)などもあり、柔軟性が高い自前実装も一部取り込みました。エージェント間のコンテキスト共有には標準化されたJSON構造を定義したことで、一貫した情報伝達を実現しています。
ツールとエージェントの分離による開発効率化
開発効率を高めるために、ツールとエージェントは分離しました。エージェントはプロンプトとユーザー対話を担当し、システム操作は分離されたツールとして実装することで、開発の並行化と責任の明確化をしています。
このように分離したことで、未実装のツールをモックに置き換えてエージェント開発を先行させることができました。
プロンプトエンジニアリングの工夫
マルチエージェント環境でのプロンプト設計では、各エージェントの役割の明確化が重要です。各プロンプトの冒頭で担当範囲を明示し、エージェントが担当外の質問に答えるリスクを低減しました。
また、入出力形式の構造化、エラー処理方法の明確化、代表的な対話例の組み込みなどを行い、エージェントの応答精度を高めました。構造化された入出力の定義の例として、アカウント作成用のエージェントでは以下を定義しています。
【入力情報】
- アカウント名: 文字列(最大32文字)
- 所属部門: 開発/検証/本番のいずれか
- 利用目的: 文字列
【出力情報】
- アカウントID: 12桁の数字
- 作成ステータス: 成功/失敗
- エラー内容: エラーの場合のみ
プロンプト設計における課題として、エージェントがときに「おせっかい」になり過ぎることがありました。例えば、司令塔であるSupervisor AgentがCollaborator Agentの仕事まで引き受けようと暴走するケースです。これに対しては、「あなたはXXXのタスクは担当せず、YYYエージェントに引き継いでください」という明示的な制約をプロンプトに追加することで対処しました。
さいごに
マルチエージェントアプローチによる自動化システムの構築は、いざ試しに動かしてみないと分からない点だらけで、技術的な挑戦も多くなるかと思います。今回は、「単一の万能エージェント」ではなく、それぞれ専門分野を持ったエージェントを連携させることで、より柔軟で堅牢なシステムとなりましたが、必ずしもすべてのケースに適しているとは限りません。エージェントを業務で活用したい場合は、まずは現行プロセスの徹底分析からスタートし、段階的な実装を心がけながら構築することをおすすめします。
本ブログが、皆様のエージェント活用の一助となれば幸いです。
お問い合わせ
atlax では、ソリューション・サービス全般に関するご相談やお問い合わせを承っております。
関連リンク・トピックス
・atlax / クラウドの取り組み / AWS(Amazon Web Services)
・2025/03/12 JAWS DAYS 2025登壇&参加レポート
・2024/12/26 EKS運用におけるコスト削減活動のご紹介
-

採用情報
NRIの IT基盤サービスでは、キャリア採用を実施しています。様々な職種で募集しておりますので、ご興味を持たれた方は キャリア採用ページも ぜひご覧ください。
※ 記載された会社名 および ロゴ、製品名などは、該当する各社の登録商標または商標です。
※ アマゾン ウェブ サービス、Amazon Web Services、AWS および ロゴは、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
※ Microsoft、Azure は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
※ Google Cloud、Looker、BigQuery および Chromebook は、Google LLC の商標です。
※ Oracle、Java、MySQL および NetSuite は、Oracle Corporation、その子会社および関連会社の米国およびその他の国における登録商標です。NetSuite は、クラウド・コンピューティングの新時代を切り開いたクラウド・カンパニーです。

お問い合わせ