Agentic AIアプリケーションを開発する際に、AWSのアーキテクチャ観点で考慮する箇所の整理

Agentic AIアプリケーションの構成イメージ

Agentic AIアプリケーションの構成を一般的に考えてみたいと思います。ネットワークのレイヤーに着目してみると、プロトコルスタックとデータの流れという二つの観点で見ることができます。

プロトコルスタックに注目すると、OSI参照モデルでいうレイヤー7（アプリケーション層）までの部分と、その上のAgentic AIが利用するプロンプトやコンテキストといったデータの流れがあります。これまではアプリケーション層までの考慮が必要でしたが、プロンプトインジェクションやLLMに個人情報を入力してしまうといった行動に対しては、アプリケーション層だけでは制御しきれないため、最近ではAIガードレールやAgentic AI向けの認証認可の機能を持った製品が出てきています。本コラムではこのAI向けのプロンプトやコンテキストやオーケストレーションを担うレイヤーのことを、意味を持つネットワーク層として「セマンティックネットワーク層」ということにします。IEEEやISOなどで正式に定められた用語ではないため、ここだけの用語となりますが、今後このような議論が本格化してくると思われます。

また、データの流れに着目してみるとエッジからバックエンドまでの流れは、おおむねこのような形に見えており、ネットワークやアーキテクチャの観点では各層をつなぐ部分（赤字で記載の箇所）における考慮が必要となります。

AWSを利用する場合、これらの構成はAmazon Bedrockなどのマネージドサービスを利用することが多くなるため、各層の中にあるリソース、IPアドレスやTCP/IPの部分を細かく意識することは少ないかもしれませんが、セキュリティ要求レベルの高いAgentic AIアプリケーションを作る場合、IAM認証やVPCエンドポイントの使用など設計的に考慮する必要が出てきますので、一つひとつ考慮してみたいと思います。

Agentic AIアプリケーションの開発をご検討の際は、NTT東日本のクラウドエンジニアへぜひご相談ください。

Agentic AIアプリケーションにおける各層の考慮事項

では、Agentic AIアプリケーションを構築する際に、アーキテクチャ観点でどのような考慮が必要か、セマンティックネットワーク層と、アプリケーション層以下で考慮してみたいと思います。ここで紹介したサービスの詳細には触れませんが、どこで何をする、ということの理解になれば幸いです。

共通

全ての層に共通部分となりますが、ネットワーク観点では、適切なIPアドレス設計やセキュリティグループの設定といった基本的な部分は変わりません。また必要なリソースだけが接続できるよう、リソースポリシーを設定して必要なリソースだけが接続できるような設定を行って、最小権限のポリシーを保持する必要があります。

エッジ層

エッジ層の役割は、アプリケーションにそもそもトラフィックを届けるかどうかの制御を担っています。したがってアプリケーション層以下はDDoS対策や、キャッシュ戦略といったこれまでの対策とは変わらず、AWSで実装する場合はCloudFrontやAWS WAFといったこれまでの製品が利用可能です。AI Botの対策にAIのWebクローラーを防止するBot Controlのルールなども有効に利用できます。

セマンティックネットワーク層は現在では有効な対策がないように見えますが、今後個人情報をはじめとする機微情報が入力されていたらマスクする、などの対策が出てくると予想しますので、これらが可能であればインターフェースとして導入しておくとよいでしょう。

フロントエンド層・API層・ユーザー認証層

ここは主にユーザーからの入力を制御する役割を担います。アプリケーション層以下においては、こちらもこれまでと同様の対策となりますが、エッジ層からの通信に限るよう、CloudFrontのVPCオリジンや、OACを利用したアクセス制御、Cognitoなどユーザー認証の導入を検討します。

また、次の制御層への呼び出しを閉域で行うために、VPC内部にこうしたフロントエンドやAPI層を配置し、AWS PrivateLinkを使用して閉域から制御層を呼び出す、といったことも可能です。

また、ストリーミングのレスポンスが必要なのか、バッチ処理で構わないのかといった要件を確認し、WebSocketやREST APIなどのプロトコル、フロントエンドのインフラストラクチャー（静的Webサイト、アクティブなアプリケーションetc）を決定します。このあたりはこれまでのアプリケーションの際のインフラストラクチャー構成の決定とあまり変わりありませんが、出力をどう受け取るかによって決定が必要となります。

セマンティックネットワーク層はユーザー認証が中心となりますが、Agentic AIを使うために接続してきたユーザーがどのような属性を持っているか（役職・所属組織など）、といった情報を追加で管理できるようにします。これは次の制御層で利用します。

制御層・セッション層・LLM層・エージェント認証層

バックエンドの処理で根幹になる部分です。エージェントとしての振る舞いを定義し、必要に応じて必要なリソースを読み・書きしますので、アプリケーション層以下では接続元や接続先を最小限に設定します。AWSの場合はIAMポリシーやリソースポリシーで制御します。

セマンティックネットワーク層では、制御層でLLMを呼び出すことになるので個人情報や機微情報についてはここでフィルタやマスクすることが大事です。AWSではBedrock Guardrailsが使用可能です。また、エージェント認証層においてはエージェントがどのようなツールを利用可能か、ユーザー属性に応じて処理することになるので、こちらも呼び出せるようにしておきます。

外部接続層・RAG接続

Agentic AIアプリケーションが使えるツールやデータベース、SaaSやほかのAIエージェントとの接続制御を行います。こちらもアプリケーション層まではネットワークのフィルタリングやDNS Firewall、接続先の外部ツールでのアクセスリストやエージェントのリソースベースの認証を行うようにします。AWSではAgentCore Gatewayを使ったツール一覧の設定、Agent Registryを使った組織単位での外部接続の許可・不許可の設定を行います。また、外部ツールのAPIキーの保管も安全な場所で行うようにします。また、外部ネットワークを使用する際には、セキュリティ要件に応じて安全な経路を使用するよう、ネットワークの設計を行う必要もあります。

セマンティックネットワーク層においては、ユーザーの属性に応じたABACベースでの認証（例：人事情報のデータソースには管理職のタグの付いたユーザーのみ許可する）を、AWSではBedrock AgentCore Policy、Verified Permissionsや、Bedrock AgentCore Gateway Interceptorを使って行います。それぞれのサービスの使い分けについて本コラムでは解説を行いませんが、技術要件やガバナンスの制約などの条件に応じて使い分けを行います。

監視・オブザーバビリティ

監視やオブザーバビリティについてもアプリケーション層以下とセマンティックネットワーク層で分けて考えることができます。アプリケーション層以下では、これまでと同様にインフラストラクチャーやアプリケーション層の正常性や、APMによる性能を観察しますが、セマンティックネットワーク層はそれに加えて出力の正確性や公平性といった観点が必要になってきます。AWSではCloudWatch GenAI Observability、Bedrockのモデル呼び出し記録ログ、アクセスログのS3保管、Bedrock AgentCoreを使用している場合はBedrock AgentCore Observabilityなどを使用します。

Agentic AIアプリケーションの開発をご検討の際は、NTT東日本のクラウドエンジニアへぜひご相談ください。

AWSでのリファレンスアーキテクチャ

では、最後にこれらが考慮されたAWSのリファレンスアーキテクチャを一つご紹介します。ただし、これが絶対正解というわけではなく今後のサービスアップデートや技術要件に応じて変わる可能性がありますので、参考までに見ていただけると助かります。

また、Agentic AIアプリケーションのアーキテクチャを実現するツールとしてAWS公式からもFAST（Fullstack AgentCore Solution Template）が用意されているので、ここから必要な要件に応じて追加や改修をするのもよいかもしれません。

https://github.com/awslabs/fullstack-solution-template-for-agentcore

まとめ

今回は、Agentic AIアプリケーションのアーキテクチャの考慮事項について簡単に解説しました。変化の激しい領域ではありますが、自前のAgentic AIアプリケーションをAWSで作りたい、という場合に参考になれば幸いです。

NTT 東日本では、AWSの構築保守だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供を行っております。

経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください！

• Amazon Web Services（AWS）およびその他のAWS 商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。