こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。
2026 年 6 月の AWS Summit New York City で、AWS Context という新サービスが発表されました。
一言でいうと、組織内に散らばるデータの関係性を自動的にナレッジグラフへマッピングし、AI エージェントがそのグラフを検索して「ガバナンスの効いたデータ関係・ビジネスルール・ドメイン知識」を実行時に参照できるようにするサービスです。ステータスは Coming soon で、記事執筆時点（2026 年 7 月）ではまだ利用できません。
まだ触れないサービスをなぜ取り上げるかというと、この発表が「エージェントに社内知識をどう渡すか」という、いま多くのチームが個別の RAG パイプラインで苦労している問題に対する、AWS としての回答だからです。
この記事では、次のことを整理します。
- なぜエージェントに「組織のナレッジグラフ」が必要なのか
- AWS Context が提供する機能と、その土台になっている技術
- 同時発表された Glue Data Catalog や S3 の新機能との関係
- 現時点で分かっていないこと
背景: エージェントは「渡されたコンテキストの分」しか賢くなれない
発表ブログの冒頭に、こんな一文があります。「エージェントの賢さは、推論に使えるコンテキストで決まる」。
生成 AI エージェントを業務に投入しようとすると、モデルの性能そのものより先に、別の問題にぶつかります。エージェントに参照させたいコンテキストが、データレイク、データウェアハウス、レイクハウス、データベース、ストリームに散在していて、さらに「どのテーブルとどのテーブルを結合すべきか」「この指標の正式な定義は何か」といった知識は、そもそも文書化されずに担当者の頭の中にある、という状況です。
これまでの定石は、エージェントやアプリケーションごとに RAG（検索拡張生成）のパイプラインを組むことでした。ただこのアプローチには構造的な弱点があります。
- 知識がエージェントごとに分断される。あるエージェント向けに整備した「正しい結合パス」や「ビジネス用語の定義」を、別のエージェントは知らない
- ガバナンスが個別対応になる。エージェントごとに「どのデータへアクセスできるか」「何を参照したか」を管理する仕組みを作り込む必要がある
- パイプラインの構築・維持コストがかかる
エージェントの判断を信頼するには、正しいデータ関係とビジネスルールに、安全な方法でアクセスさせる必要があります。AWS Context はここを「組織で共有する 1 つのコンテキストレイヤー」として解決しようとしています。
AWS Context とは
AWS Context がやることは大きく 2 つです。
1 つめは、ナレッジグラフの自動構築です。既存のデータをまたいで関係性を自動的にマッピングし、グラフとして保持します。AWS Glue Data Catalog、Amazon SageMaker Unified Studio、AWS Lake Formation がこのグラフと統合され、AI の支援による自動追加と、手動キュレーションによる明示的な追加の両方でコンテキストを育てていけます。
2 つめは、agentic search です。組織内の AI エージェントは、この検索を通じてデータ関係・ビジネスルール・ドメイン知識に実行時にアクセスします。
自動構築といっても、推論された関係がそのまま使われるわけではありません。データスチュワードやキュレーターがコンソールからグラフを管理し、推論された関係をレビューして本番に昇格させたり、ビジネス定義や利用ルールといったドメイン固有の知識を付与したりできます。「機械が推論し、人間が承認して意味を足す」という運用が想定されています。
土台になっているのは、Amazon Quick を支えているナレッジグラフ技術です。Quick では数十万のユーザーが日常的にナレッジグラフとやり取りしており、そのグラフは 1 日に数百万リクエストを処理しています。AWS Context はこれを「個人のナレッジグラフ」から「組織のナレッジグラフ」へ拡張するものだと説明されています。既存の Quick ユーザーへの恩恵も明言されていて、AWS Context を有効化すると Quick のエージェントがクロスシステムの関係やビジネスルールを含む、より広い企業ナレッジグラフへアクセスできるようになります。
利用者側の運用負担についても触れられています。プロビジョニングすべきインフラはなく、retrieval パイプラインを構築する必要もなく、マネジメントコンソールから数クリックで使い始められる、とのことです。
ここからは、発表ブログが挙げている 3 つの特徴を見ていきます。
特徴 1: 使われるほど賢くなるグラフ
AWS Context は、エージェントの利用状況から学習します。エージェントがグラフをクエリするたびに、どのソースが正しい結果を出したか、どの結合パスが使われたか、どのキュレーション済みルールが適用されたかを観察し、実際の利用実績でソースをランク付けします。
面白いのは、その学習が組織全体に共有される点です。あるエージェントが正しい結合パスを発見したり、スキーマの曖昧さを解決したりすると、人間が再キュレーションしなくても、他のエージェントがその知見を利用できるようになります。エージェントに使われるほどグラフが賢くなり、その恩恵が全エージェントに波及する、という設計です。
個別 RAG の「エージェント A のために整備した知識をエージェント B は知らない」という分断への、直接の回答といえます。
特徴 2: Apache Iceberg で開かれたコンテキスト
「コンテキストを 1 か所に集める」と聞くと、ロックインを心配する方もいるはずです。この点について発表ブログは Open and portable by design（設計としてオープンで移植可能）という節を立てて説明しています。
AWS Context は、構造化・非構造化ソースから集めた主要なメタデータを、Apache Iceberg 形式で Amazon S3 Tables に公開します。つまりコンテキストレイヤーの主要な中身が、オープンなテーブルフォーマットで手元に置かれるということです。Amazon Athena、Amazon Redshift、Apache Spark など Iceberg 互換のエンジンでクエリできますし、監査や移行、下流システムの構築にも使えます。
エージェント側のアクセス経路も特定のフレームワークに閉じていません。agentic search API と MCP ツールが提供され、Amazon Bedrock AgentCore 上のエージェントでも、Amazon EKS にデプロイしたエージェントでも、MCP 互換のフレームワークで動くエージェントでも接続できます。さらに、AWS 外のコンテキストを同じグラフに取り込めるよう、サードパーティカタログとの接続も設計に含まれています。
特徴 3: アイデンティティを継承するガバナンス
エージェントを本番投入するときに必ず問われるのが、「このエージェントはどのデータに手が届くのか」「何にアクセスしたか証明できるのか」という 2 点です。
AWS Context では、すべてのクエリがアイデンティティ認識型です。各呼び出しは、呼び出し元ユーザーの IAM と AWS Lake Formation の権限を継承する設計になっており、エージェントは自分のアイデンティティに認可された関係しか参照・トラバースできません。
アクセスがアイデンティティ経由で行われるため、すべてのやり取りが監査可能です。セキュリティ・コンプライアンスのチームは、既に使っている統制の仕組みのまま「エージェントが何に、誰の権限でアクセスしたか」を検証できます。エージェント用に別のガバナンス基盤を作るのではなく、既存の IAM / Lake Formation の統制をそのまま伸ばす、という方向性です。
同時発表から見える全体像
AWS Context は単発の発表ではなく、「コンテキスト」をテーマにした一連の発表の中心に置かれています。同じブログで、次の 2 つも発表されました。
1 つは、AWS Glue Data Catalog の Business Context と Semantic Search（プレビュー）です。Glue のテーブル・ビュー・列にビジネス上の説明、用語集、カスタムメタデータを付与できるようになり、新しい Glue Search API でビジネス上の意味からデータを検索できます。あわせてプレビューされた skill assets は、S3・git リポジトリ・wiki などに置いたファイル（AI スキルやランブックなど）への URI 参照をデータ資産に関連付ける新しいアセットタイプで、「このデータはどの粒度で、どんなフィルタを掛けてから集計すべきか」といった使い方の知識をエージェントが段階的に取得できるようにします。
もう 1 つは、Amazon S3 Annotations の一般提供開始です。S3 オブジェクトに最大 1 GB のリッチなコンテキストを直接付与できます。バケットで annotation tables を有効化すると、アノテーションが自動的にマネージドな Iceberg テーブルへ流れ、S3 Metadata 経由でクエリ可能になります。
発表ブログは「Context is the data lake for AI agents（コンテキストは AI エージェントにとってのデータレイクである）」という言葉で締められています。オブジェクト単位（S3 Annotations）、カタログ単位（Glue Business Context）、組織横断（AWS Context）と、レイヤーごとにコンテキストを蓄積する場所を用意し、それを Iceberg という開いたフォーマットで束ねる。かつてデータレイクを整備したのと同じ要領で、エージェント時代の「コンテキストレイク」を整備しようとしている、と読めます。
現時点で分かっていないこと
AWS Context は Coming soon であり、記事執筆時点（2026 年 7 月）では次の情報が公開されていません。
- 料金体系
- 対応リージョン（東京・大阪リージョンで使えるかも不明です）
- プレビューや GA の時期
- API 仕様や詳細ドキュメント
このあたりは今後の続報を待つ必要があります。
まとめ
AWS Context の発表内容を整理しました。ポイントを振り返ります。
- 組織のデータ関係を自動でナレッジグラフ化し、AI エージェントが agentic search で実行時に参照できるサービス（Coming soon）
- Amazon Quick で実績のあるグラフ技術を、個人から組織のスケールに拡張したもの
- エージェントの利用から学習し、知見が組織内の全エージェントに共有される
- コンテキストは Apache Iceberg 形式で S3 Tables に公開され、ロックインされにくい設計
- クエリは呼び出しユーザーの IAM / Lake Formation 権限を継承し、監査可能
エージェントごとに RAG パイプラインを積み上げる段階から、組織で共有するコンテキストレイヤーを整備する段階へ。発表から読み取れるのはそういう転換です。裏を返すと、Glue Data Catalog や Lake Formation でデータガバナンスを整備してきた組織ほど、その資産がそのままエージェントのガバナンスとして機能することになります。リリースに先立って自社のデータカタログと権限設計を棚卸ししておくのが、いまできる準備といえそうです。
参考
- Context intelligence for your data and AI agents at scale | AWS Machine Learning Blog
- Top announcements of the AWS Summit in New York, 2026 | AWS News Blog
針生 泰有(執筆記事の一覧)
2026 Japan AWS Top Engineer（AI/ML Data Engineer）
サーバーワークスでAI活用推進を担当
