7月14日、AWSが「Multi-cloud lakehouse architecture on AWS for Agentic AI, Part 1: Architecture and best practices」と題した記事を公開した。この記事では、エージェント型AIを動かすためのマルチクラウド・レイクハウスアーキテクチャをAWS上に構築するための設計アプローチとベストプラクティスについて詳しく紹介されている。
なぜ今、AIエージェントに「統合データ基盤」が必要なのか
AIエージェントは、情報を取得するだけでなく、推論し、計画し、自律的に行動する。そのために必要なのは「全社データへのリアルタイムかつ一貫したアクセス」だ。ところが多くのエンタープライズでは、データがオンプレミスのRDBMS、複数クラウドのデータウェアハウス、SaaSアプリ（Salesforce、SAP、Zendesk等）に分散している。
AWSはこの記事で、断片化したデータ基盤の上に立ち上げたAIイニシアチブは、将来的に作り直しを迫られるリスクがあると強く警告している。今統一データアクセス層を確立した組織だけが、エージェント型AIをスケールできるという主張だ。
アーキテクチャの核心：「カタログファースト」アプローチ
本記事が提示するアーキテクチャの肝は、統合メタデータカタログを起点にすることだ。データ製品に対して整備されたメタデータカタログが存在する場合、その上にコンテキスト層を構築し、AIエージェントが1か所から全データのコンテキストを発見できるようにする。これにより、すべてのリクエストが集中管理されたカタログとコンテキスト層を経由するため、ガバナンスと監査の一元化が実現する。
メタデータカタログが整備されていないデータソース（半構造化・非構造化データや、REST API経由のサードパーティデータ等）については、**Model Context Protocol（MCP）サーバー**を定義してコンテキスト層に直接オンボードする方式を採用する。
アーキテクチャ全体は4部構成のシリーズで公開予定で、本記事（Part 1）は設計方針とトレードオフの解説にあたる。
データアクセスの3つのパターン
1. Icebergカタログフェデレーション
AWS Glue Data CatalogがIceberg REST Catalog API仕様を実装しており、Databricks、Snowflake等のIceberg互換カタログとシームレスにフェデレーションできる。データを移動させずに、カタログ越しにメタデータを統合できる点がポイントだ。ただしこの方式はIcebergテーブルにのみ対応する。
2. クエリフェデレーション
Google BigQuery、Azure SQL、Salesforceといった外部プラットフォームに対して、データをレプリケーションせずにクロスクラウドで直接クエリを発行できる。柔軟性は高いが、デフォルトではパブリックインターネット経由となるため、データ量によっては遅延が発生する。
3. AWS Interconnect – multicloud（注目）
2025年のre:Inventで発表され、その後GAとなった**AWS Interconnect – multicloudは、AWSと他クラウド間にプライベートで高速なネットワーク接続**を提供するマネージドサービスだ。元記事公開時点ではGCPとの接続がサポートされており、AzureおよびOCIへの対応も予定されている（最新の対応状況は公式ページを参照されたい）。
設定は3ステップのみ：①対象クラウドプロバイダーを指定、②相手側のリージョンを選択、③必要な帯域を選択。AWS側ではDirect Connect Gatewayが必要で、GCP側ではGoogle Cloud Routerを用意する。これによりSparkジョブ（EMR on EKS等）がGCPのデータをプライベート接続経由でインジェスト・変換できるようになる。
ただしクエリエンジンやジョブをカスタマーVPC内に置く必要がある点は設計時に注意が必要だ。
レイクハウスの基盤：Apache Icebergを選ぶ理由
本アーキテクチャは**Apache Iceberg**をオープンテーブルフォーマットの標準として採用している。AWSはIcebergを「AWS対他プラットフォームの選択ではなく、相互運用性の選択」と位置づけている。
主な特徴：
- ベンダーロックインの排除：AWS、Databricks、Snowflake等で共通利用可能
- ACIDトランザクション：完全なトランザクション整合性
- タイムトラベルとスキーマ進化：バージョン管理とスキーマ変更への柔軟な対応
- パフォーマンス最適化：隠しパーティショニング、パーティション進化、メタデータ管理
なお、レイクハウスストレージはIceberg形式に限定されず、Apache HudiやDelta Lakeといった他のオープンテーブルフォーマットも利用可能だ。
データインジェストの選択肢
データをAWS上のレイクハウスに取り込む方法として、以下が示されている：
- Zero-ETL：AWSおよび非AWSソースからS3ベースのデータレイクまたはAmazon Redshiftへシームレスに読み込む
- ETL（バッチ・ストリーム）：Apache SparkやApache Flinkを使ったパイプライン設計。Amazon EMR（EC2・Serverless・EKS）、AWS Glue等のマネージドサービスを選択できる。AWS Glueには数百種類のJDBC・SaaSコネクタが用意されている
- AWS Outposts対応：S3 on OutpostsのデータはAWS DataSync経由でリージョンS3に同期するか、EMR on Outpostsでジョブを実行してそのままリージョンS3に書き込む
全体像：4層の統合アーキテクチャ
本アーキテクチャは以下の4層で構成される：
- データインジェスト層：Zero-ETL、バッチ・ストリーム処理、AWS Interconnect経由のマルチクラウド接続
- 集中メタデータカタログ層：AWS上のデータおよび非AWSデータのメタデータをクエリ・カタログフェデレーションで統合
- コンテキスト層：オントロジーとビジネスセマンティクスを持つナレッジグラフを構築し、AIエージェントにリッチなコンテキストを提供
- コンサンプション層：Amazon SageMaker AI（機械学習）、Amazon Bedrock AgentCore（生成AI）等を含む分析・AI開発環境
このうち、コンテキスト層はエージェントAIの文脈で特に重要な役割を担う。ナレッジグラフとは、エンティティ（顧客・製品・取引等）とその関係性をグラフ構造で表現したデータモデルであり、単純なテーブル結合では表現しにくい「意味的なつながり」をAIエージェントが利用できる形で保持する。オントロジー（概念の定義と階層構造）とビジネスセマンティクス（「売上」「顧客」といった業務概念の定義）を加えることで、AIエージェントはデータの意味を理解した上で推論・判断を行えるようになる。カタログがデータの「在り処」を示すとすれば、コンテキスト層はデータの「意味と文脈」を提供する層だ。
また、コンサンプション層に登場するAmazon Bedrock AgentCoreは、生成AIエージェントの実行基盤として2025年に発表されたAWSのマネージドサービスだ。エージェントのメモリ管理・ツール呼び出し・セッション管理といった実行環境をフルマネージドで提供し、開発者がエージェントロジックの実装に集中できるよう設計されている。詳細はAmazon Bedrock AgentCore公式ページを参照されたい。
詳細はMulti-cloud lakehouse architecture on AWS for Agentic AI, Part 1: Architecture and best practicesを参照していただきたい。
