Knowledge Catalog のコンテキスト セットを使用すると、データスキーマ、セマンティック定義、検証済みのクエリパターンを、ドメイン固有の限定されたナレッジ コンテナにパッケージ化できます。このターゲットを絞ったドメイン知識により、Gemini Enterprise やカスタム エージェントなどの自律型 AI アプリケーションが確実にグラウンディングされ、高い精度で動作できるようになります。
このドキュメントは、コンテキスト セットが AI エージェントのドメイン知識をどのように構造化するかを理解したいデータ アーキテクト、ガバナンス リード、AI エンジニアを対象としています。
コンテキスト セットとは
コンテキスト セットは、特定の分析ドメインと AI エージェントのセマンティック情報とデータアセット参照の自己完結型のコレクションをパッケージ化する、特別な Knowledge Catalog エントリ グループ（メタデータ レコードの論理コンテナ）です。
このコンテナ内では、ナレッジはエントリに整理されます。エントリは、個々のビジネス コンセプト、ドキュメント、データアセットを表します。これらのエントリは、アスペクトで拡充されます。アスペクトは、ビジネス用語、SQL テンプレート、Markdown ドキュメントなどの特定の詳細を格納するモジュラー メタデータ属性です。
エージェントにエンタープライズ カタログ全体を検索させると、レイテンシが発生し、プロンプト トークンが無駄になり、ハルシネーションが発生するリスクがあります。コンテキスト セットを使用すると、エージェントが参照できる、ドメイン スコープの密閉されたナレッジ コンテナを確立できます。
コンテキスト セットは管理コンテナとして機能するため、プロジェクトのオーナー権限でメタデータを整理し、権限を個別に構成することなく、バンドルされたすべてのエントリに Identity and Access Management（IAM）アクセス制御ポリシーを一度に適用できます。エントリ グループ、エントリ、アスペクトの詳細については、メタデータ管理についてをご覧ください。
AI エージェントのグラウンディング要件
組織が自律型 AI エージェント（Gemini Enterprise、Antigravity、カスタム Agent Development Kit エージェントなど）をデプロイしてデータ ワークフローをオーケストレートし、分析を生成する際、エージェントには信頼性の高いグラウンディングが必要です。
- セマンティック定義: 特定の列または指標がビジネス用語で何を意味するか。
- 検証済みのクエリパターン: ドメイン エキスパートは、これらのテーブルをどのようにクエリして結合しましたか？
- 運用ルール: このデータを管理するビジネス ポリシー、例外条件、標準作業手順書（SOP）は何ですか？
推奨されるコンテキスト セットの命名パターン
次のアーキテクチャ図は、4 つのコア論理命名規則がエントリ グループの境界内で連携して、ダウンストリーム AI アプリケーションをグラウンディングする方法を示しています。
コンテキスト セットが機能するために、すべてのタイプのエントリが厳密に必要になるわけではありませんが、次の論理的な命名規則を使用してエントリを整理することをおすすめします。これらの命名規則を使用すると、人間と自律エージェントが知識を一貫して検出して解釈できるようになります。
| 命名パターン | エントリタイプ | 説明と目的 | アタッチされたアスペクト |
|---|---|---|---|
ビジネス コンセプト concepts_<id> |
generic |
ビジネス用語集の用語、指標の定義、頭字語、計算式。 | glossary-term-aspect、contacts。 |
ドキュメント documents_<path> |
document |
ナラティブ コンテキスト、標準作業手順書（SOP）、オンボーディング Wiki、外部ドキュメントへのポインタ。 | Document、overview（リッチテキスト マークダウンとリンク）。 |
クエリ テンプレート query-templates_<path> |
query-template |
事前検証済みのパラメータ化された SQL クエリ テンプレート、高頻度の結合ロジック、実行パターン。 | query-template（sources、intent、nlQuery、parameters、query などのフィールドが含まれます）。 |
セマンティック モデル semantic-models_<id> |
semantic-model、semantic-entity、semantic-metric |
正式なリレーショナル モデル、エンティティ定義、ディメンション階層、メジャー。 | semantic-model、semantic-entity、semantic-metric。 |
ビジネス コンセプト
ビジネス コンセプト エントリ（concepts_* 命名規則を使用した汎用タイプのエントリ）は、標準化されたビジネス用語、ドメイン指標、頭字語、計算式（glossary-term-aspect）を定義します。
主な機能は次のとおりです。
- 用語の整合性: ビジネス ユニットと分析チーム間で用語の曖昧さを排除します。
- KPI の数式: ドメイン固有の重要業績評価指標（KPI）の数式とロジックを提供します。
- 組織のオーナー権限: 関連付けられたガバナンス アスペクト（
contacts）を通じて、明確な組織のオーナー権限を確立します。
たとえば、e コマースのコンテキスト セット内で、concepts_net_items_sold のエントリは、販売された純ユニット数の正確な計算を指定します。エージェントが「販売された商品の純数」を求めるプロンプトを受け取ると、SQL ロジックを考案するのではなく、コンセプト エントリを参照して検証済みの計算を適用します。
リソース表現の例:
name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/concepts_net_items_sold
entryType: generic
aspects:
dataplex-types.global.glossary-term-aspect:
definition: "Calculates the absolute number of items sold minus customer returns in a given time period."
ドキュメント
ドキュメント エントリ（documents_* 命名規則を使用したドキュメント タイプのエントリ）には、構造化されたマークダウン（Document、overview）でナラティブと手続き型のコンテキストが保存されます。
主な機能は次のとおりです。
- 標準作業手順書（SOP）: SOP、ランブック チェックリスト、オンボーディング ガイドをカタログ内に直接キャプチャします。
- コンプライアンス ポリシー: コンプライアンス ポリシー、規制上の制約（GDPR や HIPAA の取り扱いルールなど）、例外基準を文書化します。
- 外部リファレンス Wiki: ソース URI ポインタ（
overviewリンク）を介して外部のライブ Wiki（Google ドキュメント、Atlassian Confluence、Notion、GitHub など）を参照します。
たとえば、アパレルのコンテキスト セットには、標準の返品率を計算する際に、最終販売と輸送中に破損した商品を除外する方法をエージェントに指示する documents_return_policy_rules が含まれています。
リソース表現の例:
name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/documents_return_policy_rules
entryType: document
aspects:
dataplex-types.global.overview:
content: "## Return Policy Rules\nItems marked FINAL_SALE or DAMAGED_IN_TRANSIT are excluded from return rates..."
クエリ テンプレート
クエリ テンプレート エントリ（query-templates_* 命名規則を使用した query-template タイプのエントリ）には、一般的な自然言語分析インテントにマッピングされた、人間が検証したパラメータ化された SQL クエリが含まれています（query-template アスペクトを使用）。
主な機能は次のとおりです。
- 事前検証済みのクエリ: 頻度の高いビジネス上の質問に対して、事前検証済みの結合パス、フィルタ条件、集計パターンを保存します。
- ランタイムのパラメータ化: 動的なエージェント実行のために、ランタイム パラメータの置換（
@start_date、@region、@limitなど）をサポートします。 - エラー防止: ハルシネーションによるテーブル結合や SQL 言語の構文エラーを防止します。
たとえば、エージェントがパフォーマンスの高いアカウントに関する質問に回答する必要がある場合、query-templates_sales_top_accounts_by_arr を照合し、リクエストされた期間を検証済みの SQL テンプレートに代入します。
リソース表現の例:
name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/query-templates_top_categories_by_season
entryType: query-template
aspects:
dataplex-types.global.query-template:
intent: "Which e-commerce product categories performed best this season?"
query: "SELECT category, SUM(revenue) FROM sales WHERE season = @season GROUP BY category ORDER BY 2 DESC LIMIT @limit"
parameters:
- name: "season"
type: "STRING"
- name: "limit"
type: "INTEGER"
セマンティック モデル
セマンティック モデル エントリ（semantic-models_* 命名規則を使用する semantic-model、semantic-entity、semantic-metric エントリタイプを使用）は、正規化されたテーブル全体でリレーショナル構造、ディメンション階層、集計メジャーを形式化します。
主な機能は次のとおりです。
リレーショナル定義: 主キー、外部キー、結合カーディナリティ（1 対多の、多対多の関係など）を定義します。
ビジネス ディメンションのマッピング: 元の基盤となる列をビジネス ディメンション、時間粒度、再利用可能なメジャーにマッピングします。
エージェント ガイダンス: 正確なクエリ テンプレートが存在しない場合に、複雑なマルチテーブル分析クエリを組み立てる際に自律エージェントをガイドします。
基盤となる複雑さを抽象化する: ソース データセット内の機械的なテーブル接続のみをドキュメント化する未加工のスキーマ結合エントリリンクとは異なり、セマンティック モデルは論理ビジネスレイヤで動作し、AI エージェントが誤った ER 図のトラバーサルをハルシネーションしないようにします。
たとえば、アパレル コンテキスト セットでは、semantic-models_apparel_sales_model を使用して、warehouses、shipments、line_items がスタースキーマのファクト テーブルとディメンション テーブル間でどのように結合されるかを定義します。
リソース表現の例:
name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/semantic-models_apparel_sales_model
entryType: semantic-model
aspects:
dataplex-types.global.semantic-model:
entities:
- name: "products"
- name: "orders"
relationships:
- sourceEntity: "orders"
foreignKey: "product_id"
targetEntity: "products"
primaryKey: "id"
type: "MANY_TO_ONE"
例: オンライン衣料品店のコンテキスト セット
4 つの命名規則がどのように連携するかを示すために、オンライン衣料品小売業者が店舗のマーチャンダイザー向けに AI アシスタントをデプロイする例を考えてみましょう。境界づけられたコンテキストがない場合、エージェントは未加工のステージング テーブルをクエリしたり、顧客の返品を差し引かずに人気商品を誤ってカウントしたりする可能性があります。
エージェントをグラウンディングするために、データ スチュワードは online-apparel-store という名前のコンテキスト セットを作成します。
EntryGroup: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store
(EntryGroup.type = "context-set")
│
├── concepts_* (Business concepts)
│ ├── concepts_net_items_sold
│ │ Formula: SUM(orders.quantity) - SUM(returns.quantity)
│ └── concepts_bestseller
│ Definition: Any clothing item with >= 500 net units sold within a 30-day window
│
├── documents_* (Documents and SOPs)
│ ├── documents_return_policy_rules
│ │ Markdown SOP: Exclude items marked 'FINAL_SALE' or 'DAMAGED_IN_TRANSIT' from standard return rates
│ └── documents_size_chart_guide
│ Markdown guide: Sizing conversions across US, UK, and EU clothing labels
│
├── query-templates_* (Golden SQL queries)
│ └── query-templates_top_categories_by_season
│ Verified SQL template with parameters: @season, @limit
│
└── semantic-models_* (Semantic models)
└── semantic-models_apparel_sales_model
Join keys: orders.product_id = products.product_id (many-to-one)
orders.order_id = returns.order_id (one-to-many)
エージェントがプロンプトを解決する方法
商品担当者がエージェントに「破損した返品を除いた、冬用ジャケットのベストセラー スタイル トップ 5 は何ですか？」と尋ねると、エージェントは設定されたコンテキストを通じてプロンプトを解決します。
クエリ テンプレートの検索: エージェントは
query-templates_*を確認し、query-templates_top_categories_by_seasonと一致させ、@season = 'Winter'と@limit = 5を置き換えます。コンセプトの検証: エージェントは
concepts_net_items_soldとconcepts_bestsellerを検査して、返品された商品が注文合計数から差し引かれることを確認します。SOP ルールの適用: エージェントは
documents_return_policy_rulesを読み取り、フィルタ条件WHERE return_reason != 'DAMAGED_IN_TRANSIT'を追加します。スキーマと結合の検証:
semantic-models_apparel_sales_modelとリンクされた@bigqueryテーブルを使用して、エージェントは検証済みの外部キーを使用してstore.orders、store.products、store.returnsを結合し、SQL クエリを実行します。
アーキテクチャ機能
コンテキスト セットは、エンタープライズ データ環境にいくつかのコア機能を提供します。
密閉された実行境界: コンテキストをキュレートされたアセットとセマンティック エントリのセットにバインドすることで、エージェントは密閉されたサンドボックス内で動作します。これにより、カタログの余分なノイズが排除され、決定論的な評価が保証され、トークンの使用量が最小限に抑えられます。
高速アップロードと一括インデックス登録: チームは、コンセプト、クエリ、ドキュメントのセットを 1 つのアトミック オペレーションとしてアップロードしてインデックス登録できます。これにより、継続的インテグレーションと継続的デプロイ（CI/CD）パイプラインと統合できます。
ゼロコピー パッケージング: コンテキスト セットは、基盤となるデータ ストレージをコピーまたは移動することなく、パッケージのメタデータと関係を設定します。これにより、冗長なストレージ費用とデータ同期の遅延を回避できます。
エージェント コンサルト パターン
ダウンストリーム エージェントは、Model Context Protocol（MCP）または直接 Knowledge Catalog API を介してコンテキスト セットを使用します。詳細については、Catalog API を使用してデータ コンテキストを取得するをご覧ください。レスポンスのレイテンシを最適化し、トークンの消費を最小限に抑えるため、エージェントは 3 階層のコンサルト階層に従います。
クエリ テンプレートのマッチング: エージェントは
query-templates_*を検索します。検証済みのテンプレートがユーザーのインテントと一致する場合、エージェントはクエリをパラメータ化して直接実行します。これにより、クエリエラーのリスクがほぼゼロになり、最速のレスポンスが得られます。セマンティック モデルの組み立て: 一致するクエリ テンプレートがない場合、エージェントは
semantic-models_*を評価してエンティティの関係を理解し、マルチテーブル SQL ステートメントを作成します。ドキュメントとコンセプトのコンサルト: 曖昧なエッジケース（会計カレンダーの締め切りや異議申し立ての除外など）の場合、エージェントは
concepts_*とdocuments_*を読み、ビジネスルールを適用します。
生成 AI アプリケーションでのコンテキストの消費
生成 AI アプリケーションは、キュレートされたコンテキスト セットを使用して、エンタープライズ ドメインのセマンティクスを理解し、複雑なスキーマをナビゲートして、ハルシネーションのない信頼性の高い SQL を生成します。アプリケーションは通常、次の 2 つの主なパターンでこれらのコンテキスト セットを使用します。
動的なコンテキスト検出: 会話型またはセルフサービスの分析環境では、ユーザーは自然言語でアドホックな質問をします。アプリケーションは、ユーザーの意図を動的に評価して、Knowledge Catalog から最も関連性の高いコンテキスト セットを特定して取得し、取得したドメイン知識をアクティブなプロンプトに挿入します。
事前構成済みのコンテキスト セット: 専用エージェント アプリケーションの場合、リソース URI を指定して、明示的なコンテキスト セット参照でエージェントを事前構成できます。専用のコンテキスト セットをバインドすると、決定論的なグラウンディングが提供され、すべてのインタラクションで認定されたビジネス定義が使用され、ランタイム検索のオーバーヘッドが発生しません。繰り返し行われる拡充ワークフローによってコンテキスト セットが時間の経過とともに改良されるため、エージェントは品質の向上を自動的に継承します。
これらの拡充機能と自己学習機能を最適化するには、Gemini Enterprise アプリケーションで Gemini 3.8 Flash 以降のモデルを指定することをおすすめします。モデルの選択手順の詳細については、Agent Studio でエージェントを設計するの「フロービルダーを使用してエージェントを作成する」セクションをご覧ください。
コンテキスト セットと関連する構成要素の比較
アーキテクチャに適したメタデータ構造を選択するには、Knowledge Catalog のコンテキスト セットと関連するプラットフォーム機能の比較をご覧ください。
コンテキスト セットとコンテキスト グラフの比較
コンテキスト グラフとコンテキスト セットは、Knowledge Studio アーキテクチャで異なる役割を持つ 2 つの別個の構成要素です。
コンテキスト グラフ: 組織全体にわたる、ライブで包括的なセマンティック トポロジ。基盤となるデータアセット、ビジネス用語集の用語、インタラクション トレースをリンクします。このオープン グラフは、Explore インターフェースでインタラクティブに探索して走査できます。
コンテキスト セット: 境界が定められた、リージョン別の、キュレートされたパッケージング ユニット。ドメイン知識の特定のサブセットを抽出して、エントリ グループ（
type="context-set"）に完全にパッケージ化します。これにより、ダウンストリーム AI エージェントは Model Context Protocol（MCP）を介してクエリを実行できます。コンテキスト セットは、より広範なコンテキスト グラフ内で、まとまりのある高密度のサブグラフとして機能します。
Knowledge Catalog コンテキスト セットとデータベース コンテキスト セットの比較
Knowledge Catalog と Google Cloud運用データベースの両方で、生成 AI モデルをグラウンディングするキュレートされた情報を指すために、コンテキスト セットという用語が使用されています。
どちらのバリエーションも、同じ基盤アーキテクチャを共有しています。つまり、Knowledge Catalog コンテキスト セット（type="context-set" を含む拡張可能なエントリ グループ）としてネイティブに保存され、標準の Knowledge Catalog API を使用します。ただし、ターゲットとするエンタープライズ データスタックのレイヤは異なります。
- データベース コンテキスト セット（QueryData）: 運用トランザクション データベース（AlloyDB for PostgreSQL、Cloud SQL、Spanner など）を処理するように構築されています。これらのコンテキスト セットは、SQL 構成用に高度に最適化されています。これらは、ゴールデン クエリ テンプレート、スキーマ メタデータ、フィルタリング ファセットをバンドルしたもので、専用のコンテキスト エンジニアリング エージェントが評価して、運用ランタイムでの自然言語から SQL（NL2SQL）への変換を改善します。
- Knowledge Catalog コンテキスト セット（Knowledge Studio）: 分析データセット（BigQuery、データレイクハウス、Knowledge Catalog データ プロダクトなど）を処理するために構築されています。これらのコンテキスト セットは、ビジネス コンセプト、Markdown ドキュメント Wiki、セマンティック モデルなど、複数の命名規則にわたる幅広いマルチモーダルな知識をパッケージ化します。これらは Knowledge Studio のエンリッチメント ワークフローを使用してキュレートされ、Model Context Protocol（MCP）を介してダウンストリームの分析エージェントに提供されます。
コンテキスト セットとデータ プロダクトの比較
コンテキスト セットが Knowledge Catalog のデータ プロダクトとどのように相互作用するかを理解すると、明確なデータと AI ガバナンスの境界を確立できます。
データ プロダクトは基盤となるリソースを管理する: データ プロダクトは、BigQuery テーブル、バケット、ストリームなどの具体的なリソースを安全にバンドルし、データ共有、データ コントラクト、データプレーン アクセス制御のプライマリ ユニットを確立します。
コンテキスト セットは会話セマンティクスをバンドルする: コンテキスト セットはデータアクセスを許可しません。代わりに、AI エージェントと人間がデータを理解するために必要なコンセプト、クエリ テンプレート、ドキュメントなどのドメイン知識をバンドルします。データ スチュワードは、プロダクトの
additional_context参照で宣言することで、コンテキスト セットをデータ プロダクトにリンクできます。
エンタープライズ セキュリティとガバナンス
コンテキスト セットは、 Google Cloud のセキュリティとガバナンス管理と統合され、企業の機密メタデータを保護します。
コンテキスト セットの IAM ロール: コンテキスト セットには機密性の高いセマンティック情報が含まれていることが多いため、アクセスは
context-setエントリ グループに直接適用される IAM ロールによって管理されます。これにより、キュレートされたナレッジを地理的リージョンとドメインの所有権別に整理し、ドメイン管理者に変更権限を付与し、使用する AI エージェントに読み取り権限を付与できます。コンテキスト セットを作成するには、dataplex.entryGroups.setIamPolicyIAM 権限が必要です。この権限は、コンテキスト セットの作成時にオーナー権限を自動的に付与するために必要です。この権限は、Dataplex Catalog 管理者（roles/dataplex.catalogAdmin）や Dataplex エントリ グループ オーナー（roles/dataplex.entryGroupOwner）などの事前定義ロールを介して取得できます。ゼロコピーの基盤となるデータ セキュリティ: エージェントにコンテキスト セットへのアクセス権を付与すると、エージェントはセマンティック メタデータとクエリ テンプレートを読み取ることができますが、基盤となるテーブルのアクセス制御をバイパスすることはできません。BigQuery に対して SQL クエリを実行したり、Cloud Storage のファイルを読み取ったりするには、クエリを実行する ID に、基盤となるリソースに対する必要なデータプレーン IAM 権限が付与されている必要があります。
人間参加型のガバナンス: 自律的な Knowledge Studio の拡充タスクが運用ログから新しいコンセプト、SOP、クエリ テンプレートを抽出すると、提案はレビュー可能な変更リクエストとしてステージングされます。データ スチュワードは、本番環境のコンテキスト セットへの変更を承認する前に、差分の比較と評価スコアを検査します。プロポーザルの審査の詳細については、リクエストを管理するをご覧ください。
ユーザー管理の実行 ID: コンテキスト セットにデータを入力する自動エンリッチメント タスクは、サービス アカウント トークン作成者ロール（
roles/iam.serviceAccountTokenCreator）を介して Dataplex サービス エージェントがサービス アカウントの権限借用を行ったユーザー管理のサービス アカウントで実行されます。
プレビューのスコープと境界
プレビュー期間中、コンテキスト セットは次の境界内で動作します。
リージョン スコープ: リージョン データアセットにリンクされたグローバル コンテキスト セットはサポートされていません。コンテキスト セットは、パッケージ化するアセットのリージョン境界と一致している必要があります。
作成インターフェースと使用インターフェース: Google Cloud コンソールの Knowledge Studio コンテナを使用してコンテキスト セットを作成し、標準の Knowledge Catalog 管理エントリ グループと論理的に区別できます。コンテキスト セットは、Knowledge Studio のエンリッチメント ワークフローを通じて自動的に入力できます。ダウンストリーム AI エージェントは、Knowledge Catalog API（
ListEntriesとLookupEntry）と Model Context Protocol（MCP）を使用して、コンテキスト セットをプログラムで検出してクエリできます。詳細については、MCP サーバーについてをご覧ください。課金: Knowledge Catalog では、コンテキスト セット エントリ グループの作成に対して個別のスタンドアロン SKU は課金されません。
共有割り当て: コンテキスト セットは、基本的に特殊なエントリ グループ（
type="context-set"）であるため、標準の Knowledge Catalog エントリ グループと同じリソース割り当てを消費して共有します。
次のステップ
Knowledge Studio の概要
Knowledge Studio インターフェースを使用して、リッチデータ コンテキストをオーケストレートし、コンテキスト セットを構築して、AI エージェントをグラウンディングする方法を学びます。
Catalog API を使用してデータ コンテキストを取得する
`ListEntries` API と `LookupEntry` API を使用して、生成 AI の推論用のコンテキスト セットをプログラムで検出して取得します。