AI News HubLIVE
サイト内リライト8 分で読了

AWSで最新のデータメッシュ戦略を用いたエージェンティックAIアプリケーションの構築

この記事では、AWS上でガバナンスが効いたサーバーレスデータメッシュを構築し、プロダクション環境のエージェンティックAIに必要な安全でスケーラブルなデータ基盤を提供する方法を紹介します。

ソースAWS Machine Learning Blog著者: Venkata Sistla

カスタマーサービスエージェントが自律的に注文データベースを照会し、返品ポリシーを取得し、回答を統合する場合、組織全体の複数のデータソースへのガバナンスが効いたアクセスが必要です。最新のデータメッシュ上でエージェンティックAIアプリケーションを構築するには、データインタラクションチェーンのすべてのレイヤーで細粒度のアクセス制御を実施する必要があります。データベーススキーマを自律的に発見し、SQLクエリを構築し、複数のデータソースからデータを統合するAIエージェントは、検索拡張生成(RAG)向けに構築された単一チェックポイントモデルでは対処できないガバナンスのギャップを露呈します。組織は、ツールの発見からクエリ実行、応答合成に至るまで制御を必要とします。

以前の記事「AWSサーバーレスデータレイクでセキュアなRAGアプリケーションを構築する」では、ビジネスドメインやセキュリティ分類などのメタデータを使用してベクトル検索結果をフィルタリングすることで、RAGに細粒度アクセス制御(FGAC)を適用する方法を示しました。このアプローチは、RAGのデータインタラクションが単純(事前構築されたベクトルインデックスからチャンクを取得し、メタデータでフィルタリングして結果を提示する)であったため、有効でした。

この記事では、AWS上でガバナンスが効いたサーバーレスデータメッシュを構築し、プロダクション環境のエージェンティックAIに必要な安全でスケーラブルなデータ基盤を提供する方法を紹介します。このアーキテクチャは、元の設計から3つの主要な変更を加えています:

  • Amazon OpenSearch ServerlessをAmazon S3 Vectorsに置き換え、コスト最適化された知識ベースを実現。中程度のクエリ頻度ワークロードでは、専用ベクトルデータベースソリューションと比較してベクトルストレージとクエリコストを最大90%削減できます。
  • 汎用Amazon Simple Storage Service(Amazon S3)を、AWS Lake FormationでガバナンスされるAmazon S3 Tables(Apache Iceberg内蔵サポート)に置き換え、自己管理型Icebergテーブルと比較して1秒あたりのトランザクション数が最大10倍向上し、行、列、セルレベルのセキュリティを実現します。
  • データメッシュをModel Context Protocol(MCP)ツールとしてAgentCore Gatewayを介して公開し、AWS Lambdaバックエンドのインターセプターを使用してエージェントからツールへの呼び出しごとに確定的なアクセス制御を実現します。

前提条件 このアーキテクチャを実装するには、以下が必要です:

  • 管理者アクセス権を持つAWSアカウント。
  • IAMロール、ポリシー、Lambda関数、S3 Tablesテーブルバケット、Amazon Athenaワークグループ、Lake Formation設定を作成するためのAWS Identity and Access Management(IAM)権限。
  • AWS Lake Formationの概念(データレイク管理者、LFタグ、データフィルター)に関する知識。
  • Amazon Bedrockが有効化され、モデルアクセスが設定されたアカウント。
  • アカウントでAmazon Bedrock AgentCoreアクセスが設定されていること。
  • AWS CLI v2がインストールおよび設定されていること。

アーキテクチャ概要 以下の図は、カスタマーリクエストからガバナンスが効いたデータアクセス、そして戻るまでのエンドツーエンドフローを示しています。各レイヤーは独自の承認制御を実施するため、単一障害点が未承認データを公開することはありません。アーキテクチャ図は4つのレイヤーで構成されています:エージェントレイヤー(AgentCore RuntimeとLangGraphエージェント)、ゲートウェイレイヤー(リクエストインターセプターとレスポンスインターセプター)、ツールレイヤー(4つのLambdaバックエンドMCPツール:get_user_tables、get_schema、run_query、kb_search)、そしてガバナンスデータメッシュ(S3 Tables、Athena、Lake Formation、S3 Vectors)。矢印は、カスタマーからエージェントを経由してガバナンスが効いたデータソースへのデータフローを示しています。

  • エージェントレイヤー – カスタマーはAgentCore Runtimeと対話します。これは、セキュアなサーバーレスホスティング環境で、エージェントを分離されたマイクロVM環境にデプロイし、セッション分離を提供します。エージェントはLangGraphフレームワーク内で実行され、MCPClientクラスを介してMCPツールと統合します。
  • ゲートウェイレイヤー – ゲートウェイには、JSON Web Token(JWT)検証とスコープ強制を実行するリクエストインターセプター、ツールフィルタリング、データ編集、監査ログを処理するレスポンスインターセプター、およびAgentCore PolicyとBedrock Guardrailsが含まれます。これらは、すべてのツール呼び出しの入力と出力をリアルタイムで評価し、プロンプトインジェクション、有害コンテンツ、機密情報の露出を防ぎます。
  • ツールレイヤー – 4つのLambdaバックエンドMCPツール(get_user_tables、get_schema、run_query、kb_search)がガバナンスが効いたデータアクセスを提供します。
  • ガバナンスデータメッシュ – S3 Tables(Iceberg)はAWS Glueデータカタログ(s3tablescatalog)に登録され、Amazon Athenaはワークグループコスト制御を備え、Lake Formationは行/列/セルレベルのセキュリティを強制し、S3 VectorsはAmazon Bedrock Knowledge Basesを強化します。

なぜエージェンティックAIに新しいガバナンスモデルが必要か RAGアーキテクチャは、単一のチェックポイント(メタデータフィルタリングされたベクトル検索)でガバナンスを実施していました。このアプローチはRAGワークロードに適していました。エージェンティックパターンは追加のステップを導入し、各ステップが独自の承認決定を必要とするマルチステップチェーンを作り出します。RAGでは、システムは検索時に1つの事前構築ベクトルインデックスをメタデータフィルターで照会します。エージェンティックAIでは、システムは存在するテーブルを発見し、スキーマを理解し、SQLを構築し、ベクトルストアから取得し、結果を統合します。

単一の検索境界におけるメタデータフィルターでは、この5ステップのチェーンをガバナンスできません。ベクトルデータベースは定期的に権限を同期するため、失効が即座に反映されません。エージェントが自律的にデータを処理する場合、これは許容できないギャップです。ロール階層、属性ベースのアクセス、行レベルフィルターなどの複雑なID権限は、ベクトルチャンク上の単純なメタデータキーと値のペアとして表現できません。

これらの制限により、各データアクセスレイヤーでネイティブに承認が実施される、ガバナンスが効いたデータメッシュアーキテクチャへの移行が促進されます。

ガバナンスが効いたサーバーレスデータメッシュの構築 データメッシュは、データ所有権をドメインチームに分散化する一方、ガバナンスと発見可能性を集中化します。AWSでは、ドメインチームがデータ製品をエンドツーエンドで所有し、AWS Glueデータカタログが集中メタデータ発見を提供し、Lake Formationがデータベース、テーブル、列、行、セルにわたって許可を付与/取り消しのセマンティクスで実施します。

各プロデューサードメインは独自のAWSアカウントに存在します。プロデューサーは、中央ガバナンスアカウント(組織全体の権威あるAWS GlueデータカタログとLake Formation権限ポリシーをホストする専用AWSアカウント)にデータ製品を登録します。データはLake Formationのクロスアカウント共有を通じて共有されます。データはコピーされず、メタデータのみがコンシューマーカタログのリソースリンクを通じてリンクされます。クエリ時に、Lake Formationは権限を検証し、一時的な認証情報をクエリエンジンに発行します。タグベースのアクセス制御(LF-TBAC)はこれを動的に拡張します。管理者は、リソースにLFタグ(classification=PIIやdepartment=customer_serviceなど)を割り当て、それらのタグに基づいて権限を付与します。

以下のサブセクションでは、このメッシュの2つのデータレイヤーを実装する方法を説明します。最初に、構造化データ(注文記録、顧客プロファイル)向けのトランザクションIcebergテーブルをLake Formationの行と列のセキュリティでガバナンスします。次に、非構造化知識(ポリシー、FAQ)向けのベクトルストアについて説明し、セマンティック検索を強化します。

トランザクションデータ向けのApache Icebergを備えたS3 Tables カスタマーサービスエージェントのために、注文管理ドメインチームはAmazon S3 Tablesを使用して注文データと顧客データを公開します。S3 Tablesは、Apache Icebergを内蔵サポートする最初のクラウドオブジェクトストレージであり、汎用S3バケット上の自己管理型Icebergテーブルと比較して1秒あたりのトランザクション数が最大10倍向上します。圧縮、スナップショット管理、未参照ファイルの削除を自動的に処理します。

S3 TablesはAmazon SageMaker Lakehouseと統合され、AWS Glueデータカタログを設定し、Lake Formationを通じてアクセスを統合します。3つのデータ製品(customer_orders、customer_profiles、interaction_history)はAmazon Athenaからクエリ可能で、Lake Formation権限でガバナンスされ、S3 Tablesによって自動的に圧縮されます。

Lake Formationのデータフィルターは行レベルのセキュリティを実施するため、エージェントは認証された顧客に属するレコードのみにアクセスできます。customer_ordersのデータフィルターは、行フィルター式customer_id = :customer_idを使用して、エージェントがSQLをどのように構築しても、すべてのクエリを現在の顧客のレコードに制限します。run_query Lambda関数は、Athenaにクエリを送信する前に、認証された顧客のIDをセッションパラメーターとして注入します。列レベルのセキュリティは、payment_methodやbilling_addressなどの機密フィールドをクエリ結果から完全に隠します。

Amazon S3 Vectorsを使用した知識ベースの構築 構造化データだけでは不十分です。顧客は、セマンティック検索機能を必要とする非構造化知識(製品マニュアル、返品ポリシー、FAQ、トラブルシューティングガイド)から回答を得る必要があります。

Amazon S3 Vectorsは、完全サーバーレスサービスとしてネイティブのベクトルストレージとクエリサポートを提供します。インデックスあたり最大20億ベクトルをサポートし、強力な書き込み整合性を提供するため、新しく追加されたベクトルは即座にクエリ可能です。

S3 Vectorsのコストメリット Amazon Bedrockの知識ベース機能を使用するお客様は、S3 Vectorsをベクトルストアとして選択することで、中程度のクエリ頻度ワークロードにおいて専用ベクトルデータベースソリューションと比較してコストを最大90%削減できます。1秒あたりのクエリ数(QPS)が高く、1桁ミリ秒のレイテンシが必要なワークロードには、Amazon OpenSearch Serverlessの方が適しています。AWSは、S3 Vectorsのパフォーマンスプロファイルを超えるワークロードのために、S3 VectorsからAmazon OpenSearch Serverlessコレクションへのシングルステップエクスポートを提供しています。

S3 Vectorsは、フィルタリング可能なメタデータ(文字列、数値、ブール値、リスト型で$eq、$ne、$gt、$in、$and、$orなどの演算子をサポート)と、結果とともに返されるより大きなコンテキストデータ用のフィルタリング不可能なメタデータをサポートします。このユースケースでは、ドキュメントはproduct_categoryやdocument_typeなどのフィルタリング可能なメタデータキーとともに保存され、ターゲットを絞ったセマンティック検索をサポートします。次の例は、電子製品の返品ポリシーのみを取得するメタデータフィルターを示しています:

{"$and": [{"product_category": {"$eq": "electronics"}}, {"document_type": {"$eq": "return_policy"}}]}

AgentCore Gatewayによるデータメッシュの公開 ガバナンスが効いたデータメッシュと知識ベースが整ったら、次の課題は、これらを安全で発見可能かつ標準化された方法でAIエージェントに公開することです。このセクションでは、これを可能にするツール、インターセプター、ID伝播パターンについて説明します。

AgentCore Gatewayは、AIエージェントがツールに接続する方法を管理するための集中レイヤーを提供します。認証、可観測性、ポリシー適用を単一のエンドポイントに統合します。ゲートウェイは、Lambda関数、API、既存のMCPサーバーをMCP互換ツールに変換し、プロトコル変換、インバウンドOAuth認証、アウトバウンドクレデンシャル管理を提供します。エージェントは、ストリーミング可能なHTTPトランスポートとOAuth Bearerトークンを介して接続します。

4つのコアデータツール 4つのLambdaバックエンドMCPツールが、ゲートウェイを介してガバナンスが効いたデータアクセスを提供します。get_user_tablesは、Lake Formation権限でフィルタリングされたAWS Glueデータカタログをクエリし、許可されたテーブルを返します。get_schemaは、指定されたテーブルの列名、型、説明を取得します。run_queryは、読み取り専用許可リストに対してSQLを検証し、行レベルフィルタリングのために顧客IDを注入し、Athenaを通じてバイトスキャンコスト制限付きで実行します。kb_searchは、Amazon BedrockのKnowledge Basesに対してメタデータフィルタリングされたセマンティック検索を実行します。

Amazon Bedrock Managed Knowledge Baseのローンチにより、知識ベースはAgentCore Gatewayのネイティブな事前構築ターゲットタイプとして利用可能になりました。これにより、カスタムLambda関数なしでゲートウェイを介して知識ベースを公開できます。ゲートウェイは自動的にIAMロールを生成し、組み込みの可観測性と評価メトリクスを提供し、AgentCore Policyを介してポリシーを適用します。このアーキテクチャでは、ゲートウェイインターセプターがツールレベルで細粒度の認証とメタデータフィルタリングをどのように実施するかを示すために、カスタムLambdaバックエンドのkb_searchツールを使用しています。