コンテキスト セットの概要

Knowledge Catalog のコンテキスト セットを使用すると、データスキーマ、セマンティック定義、検証済みのクエリパターンを、ドメイン固有の限定されたナレッジ コンテナにパッケージ化できます。これらのコンテナを使用すると、Gemini Enterprise やカスタム エージェントなどの自律型 AI アプリケーションを、検証済みのドメイン知識でグラウンディングできます。

このドキュメントは、コンテキスト セットが AI エージェントのドメイン知識をどのように構造化するかを理解したいデータ アーキテクト、ガバナンス リード、AI エンジニアを対象としています。コンテキスト セットをすぐに作成して入力するには、コンテキスト セットを管理するをご覧ください。

コンテキスト セットとは

コンテキスト セットは、メタデータ エントリとナレッジ ドキュメントの論理コンテナである、特別な Knowledge Catalog エントリ グループ（type="context-set"）です。各コンテキスト セットは、特定の分析ドメインと AI エージェントのセマンティック情報とデータアセット参照の自己完結型のコレクションをパッケージ化します。

このコンテナ内では、ナレッジはエントリに整理されます。エントリは、個々のビジネス コンセプト、データアセット、またはガイドライン、How-to、参考資料などのドキュメントを表します。これらのエントリは、アスペクトで拡充されます。アスペクトは、ビジネス用語、SQL テンプレート、Markdown ドキュメントなどの特定の詳細を格納するモジュラー メタデータ属性です。

次の図は、AI エージェントがコンテキスト セット（ルート インデックス、ドメイン エントリ、アスペクト、参照されるデータアセットなど）をクエリする方法を示しています。

エージェントにエンタープライズ カタログ全体を検索させると、レイテンシが発生し、プロンプト トークンが無駄になり、ハルシネーションが発生するリスクがあります。コンテキスト セットを使用すると、エージェントが高精度で参照できる、ドメイン スコープの密閉されたナレッジ コンテナを確立できます。

コンテキスト セットは管理コンテナとして機能するため、プロジェクト オーナー権限でメタデータを整理し、権限を個別に構成することなく、バンドルされたすべてのエントリに Identity and Access Management（IAM）アクセス制御ポリシーを一度に適用できます。エントリ グループ、エントリ、アスペクトの詳細については、メタデータ管理についてをご覧ください。

AI エージェントのグラウンディング要件

組織が自律型 AI エージェント（Gemini Enterprise、Antigravity、カスタム Agent Development Kit エージェントなど）をデプロイしてデータ ワークフローをオーケストレートし、分析を生成する際、エージェントには信頼性の高いグラウンディングが必要です。

• セマンティック定義: 特定の列または指標がビジネス用語で何を意味するか。
• 検証済みのクエリパターン: ドメイン エキスパートは、これらのテーブルをどのようにクエリして結合しましたか？
• 運用ルール: このデータを管理するビジネス ポリシー、例外条件、標準作業手順書（SOP）は何ですか？

コンテキスト セットにデータを入力する方法

コンテキスト セットのエントリにデータを入力するには、スキーマ、クエリログ、ナレッジ シグナルを分析する自律型エンリッチメント タスクを実行します。詳細については、拡充タスクを作成するをご覧ください。

コンテキスト セットは特殊なエントリ グループ（type="context-set"）であるため、Google Cloud CLI、クライアント ライブラリ、または Dataplex API を使用して、エントリをプログラムで作成および更新することもできます。詳細については、エントリを管理してカスタムソースを取り込むをご覧ください。

コンテキスト セットのエントリタイプと構造

コンテキスト セットのエントリは、ドキュメント（projects/dataplex-types/locations/global/entryTypes/document）またはクエリ テンプレート（projects/dataplex-types/locations/global/entryTypes/query-template）のシステム エントリタイプ、階層エントリ ID、保存するナレッジに基づくメタデータ アスペクトを使用します。以降のセクションでは、エントリの構造と、AI エージェントをグラウンディングするコア エントリ カテゴリについて説明します。

自動拡充エージェントのエントリ構造

拡充タスクがコンテキスト セットにデータを入力すると、拡充エージェントは、ドキュメント システム エントリタイプ（projects/dataplex-types/locations/global/entryTypes/document）と、必須の document アスペクトと overview アスペクトを使用して、生成されたエントリを作成します。エージェントは、生成されたエントリをスラッシュ区切り（/）のエントリ ID を使用して段階的な開示階層に整理し、document.type フィールドを使用して各エントリのロールを区別します。

次の図は、拡充されたコンテキスト セット（thelook-context）が agents ルート インデックス（context-set）の下にエントリを整理する方法を示しています。ナビゲーション ディレクトリ階層（knowledge-base-index）は、テーブル コンテキスト エントリ（table-context、SQL クエリ数が付加されている）を assets/bigquery/cymbal-style/thelook/* の下にグループ化し、ドメインガイド（knowledge-base）とビジネス用語（concept）を documents/* の下にグループ化します。

エンリッチメント タスクによって生成された Document エントリに加えて、コンテキスト セットには、Google Cloud CLI、クライアント ライブラリ、または Dataplex API を使用してプログラムで作成されたスタンドアロンのクエリ テンプレート（projects/dataplex-types/locations/global/entryTypes/query-template）エントリを含めることができます。認定済みのクエリ テンプレート エントリを含むコンテキスト セットで拡充タスクが実行されると、拡充エージェントはそれらのエントリを変更または削除せずに保持します。詳細については、このドキュメントのクエリ テンプレートのセクションをご覧ください。

データアセット

データアセット エントリ（assets/bigquery/PROJECT_ID/DATASET_ID/TABLE_ID の document.type: "table-context"）は、BigQuery の物理テーブルの説明を上書きすることなく、特定のテーブルのドメイン固有の手順、列の注意事項、結合ヒント、検証済みの SQL の例をキャプチャします。各データアセット エントリは、有向 reference エントリリンク（projects/dataplex-types/locations/global/entryLinkTypes/reference）を介してターゲット カタログ アセットにリンクされます。

リソース表現の例:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/assets/bigquery/cymbal-style/store/orders
entryType: projects/dataplex-types/locations/global/entryTypes/document
aspects:
  dataplex-types.global.document:
    type: "table-context"
  dataplex-types.global.overview:
    content: "## Orders table context\nJoin `store.orders` to `store.returns` on `order_id` when calculating net sales..."

ビジネス コンセプト

ビジネス コンセプト エントリ（documents/concepts/CONCEPT_ID の document.type: "concept"）は、標準化されたビジネス用語、ドメイン指標、頭字語、計算式を定義します。

主な機能は次のとおりです。

• 用語の整合性: ビジネス ユニットと分析チーム間で用語の曖昧さを排除します。
• KPI の数式: ドメイン固有の重要業績評価指標（KPI）の数式とロジックを提供します。
• ターゲット アセットのリンク: reference エントリリンクを使用して関連するテーブルにリンクし、エージェントがコンセプトの適用場所を把握できるようにします。

たとえば、e コマース コンテキスト セット内の documents/concepts/net-items-sold のエントリは、販売された純単位の正確な計算を指定します。エージェントは、「販売された商品の純数」を求めるプロンプトを受け取ると、SQL ロジックを考案するのではなく、コンセプト エントリを参照して検証済みの計算を適用します。

リソース表現の例:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/documents/concepts/net-items-sold
entryType: projects/dataplex-types/locations/global/entryTypes/document
aspects:
  dataplex-types.global.document:
    type: "concept"
  dataplex-types.global.overview:
    content: "Calculates the absolute number of items sold minus customer returns in a given time period."

ドキュメントと自己学習ルール

ドキュメント エントリ（documents/* の下の document.type: "knowledge-base" または "learning"）には、構造化された Markdown（document と overview のアスペクト）で、ナラティブと手続き型のコンテキストが保存されます。

主な機能は次のとおりです。

• 標準作業手順書（SOP）: SOP、ランブック チェックリスト、オンボーディング ガイドをカタログ内に直接キャプチャします。
• コンプライアンス ポリシー: コンプライアンス ポリシー、規制上の制約（GDPR や HIPAA の取り扱いルールなど）、例外基準を文書化します。
• エージェントの自己学習: ダウンストリーム エージェントの会話トレースから抽出された暗黙のルールと曖昧性除去（documents/learnings/LEARNING_SLUG）をキャプチャします。

たとえば、アパレル コンテキスト セットには、標準の返品率を計算する際に、最終販売と輸送中に破損した商品をエージェントが除外する方法を指示する documents/policies/return-policy-rules が含まれています。

リソース表現の例:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/documents/policies/return-policy-rules
entryType: projects/dataplex-types/locations/global/entryTypes/document
aspects:
  dataplex-types.global.document:
    type: "knowledge-base"
  dataplex-types.global.overview:
    content: "## Return Policy Rules\nItems marked FINAL_SALE or DAMAGED_IN_TRANSIT are excluded from return rates..."

クエリ テンプレート

また、queries アスペクトをデータアセット エントリにアタッチしたり、コンテキスト セットに専用のクエリ テンプレート（projects/dataplex-types/locations/global/entryTypes/query-template）エントリをプログラムで作成して、自然言語の質問にマッピングされた検証済みのパラメータ化された SQL クエリを保存することもできます（dataplex-types.global.query-template アスペクト）。

主な機能は次のとおりです。

• 事前検証済みのクエリ: 分析用の intent と自然言語の質問の例（nlQuery）にマッピングされた、検証済みの結合パス、フィルタ条件、集計パターンを保存します。
• ランタイム パラメータ化: 動的エージェント実行のために、説明とサンプル値（sampleValues）を含む型付きパラメータ プレースホルダ（@season や @limit など）をサポートします。
• マルチエンジン サポート: ターゲット sourceType（BIGQUERY、SPANNER、ALLOYDB、CLOUD_SQL、LOOKER など）と、オプションの sourceDialect（GOOGLE_SQL、POSTGRESQL、MYSQL、LOOKER_QUERY）を指定します。

リソース表現の例:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/queries/top-categories-by-season
entryType: projects/dataplex-types/locations/global/entryTypes/query-template
aspects:
  dataplex-types.global.query-template:
    intent: "Identify top-performing product categories by revenue for a given season."
    nlQuery: "Which ecommerce product categories performed best in winter?"
    query: "SELECT category, SUM(revenue) FROM store.orders WHERE fiscal_season = @season GROUP BY category ORDER BY 2 DESC LIMIT @limit"
    sourceType: "BIGQUERY"
    sourceDialect: "GOOGLE_SQL"
    parameters:
      - name: "season"
        type: "STRING"
        sampleValues:
          - "WINTER"
      - name: "limit"
        type: "NUMBER"
        sampleValues:
          - "5"

例: オンライン衣料品店のコンテキスト セット

コンテキスト セットのエントリがどのように連携するかを示すために、オンライン衣料品小売業者が店舗のマーチャンダイザー向けに AI アシスタントをデプロイする例を考えてみましょう。境界づけられたコンテキストがない場合、エージェントは未加工のステージング テーブルをクエリしたり、顧客の返品を差し引かずに人気商品を誤ってカウントしたりする可能性があります。

エージェントをグラウンディングするために、データ スチュワードは online-apparel-store という名前のコンテキスト セットを作成して拡充します。

EntryGroup: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store
(EntryGroup.type = "context-set")
│
├── agents (document.type = "context-set")
│     Root directory index for AI agents consulting the context set
│
├── assets/bigquery/cymbal-style/store/* (document.type = "table-context")
│   ├── assets/bigquery/cymbal-style/store/orders
│   │     Linked using entryLinkTypes/reference -> @bigquery .../tables/orders
│   ├── assets/bigquery/cymbal-style/store/products
│   │     Linked using entryLinkTypes/reference -> @bigquery .../tables/products
│   └── assets/bigquery/cymbal-style/store/returns
│         Linked using entryLinkTypes/reference -> @bigquery .../tables/returns
│
├── documents/concepts/* (document.type = "concept")
│   ├── documents/concepts/net-items-sold
│   │     Formula: SUM(orders.quantity) - SUM(returns.quantity)
│   └── documents/concepts/bestseller
│         Definition: Any clothing item with >= 500 net units sold within a 30-day window
│
├── documents/policies/* (document.type = "knowledge-base")
│   └── documents/policies/return-policy-rules
│         Markdown SOP: Exclude items marked 'FINAL_SALE' or 'DAMAGED_IN_TRANSIT' from standard return rates
│
└── documents/learnings/* (document.type = "learning")
    └── documents/learnings/winter-season-date-filter
          Learned rule: Filter winter season queries using fiscal_season = 'WINTER'

エージェントがプロンプトを解決する方法

マーチャンダイザーがエージェントに「破損した返品を除いた、冬用ジャケットのベストセラー スタイル トップ 5 は何ですか？」と尋ねると、エージェントは設定されたコンテキストを通じてプロンプトを解決します。

1. ルート インデックスとコンセプト ルックアップ: エージェントは agents ルート インデックスを読み取り、documents/concepts/net-items-sold と documents/concepts/bestseller を検査して、返品された商品が注文合計数量から差し引かれる必要があることを確認します。

2. SOP と学習の適用: エージェントは documents/policies/return-policy-rules と documents/learnings/winter-season-date-filter を読み取り、フィルタ条件 WHERE return_reason != 'DAMAGED_IN_TRANSIT' と fiscal_season = 'WINTER' を追加します。

3. テーブル コンテキストと結合の検証: assets/bigquery/cymbal-style/store/* のデータアセット エントリと、基盤となる @bigquery テーブルへの reference エントリリンクを使用して、エージェントは検証済みの外部キーを使用して store.orders、store.products、store.returns を結合し、SQL クエリを実行します。

アーキテクチャ機能

コンテキスト セットは、エンタープライズ データ環境にいくつかのコア機能を提供します。

• 密閉された実行境界: コンテキストをキュレートされたアセットとセマンティック エントリのセットにバインドすることで、エージェントは密閉されたサンドボックス内で動作します。この境界により、無関係なカタログ ノイズが排除され、決定論的な評価が保証され、トークンの使用量が最小限に抑えられます。

• 高速アップロードと一括インデックス登録: チームは、コンセプト、クエリ、ドキュメントのセットを単一のアトミック オペレーションとしてアップロードしてインデックス登録できます。これにより、継続的インテグレーションとデプロイ（CI / CD）パイプラインと統合できます。

• ゼロコピー パッケージング: Context は、基盤となるデータ ストレージをコピーまたは移動することなく、パッケージのメタデータと関係を設定します。これにより、冗長なストレージ費用とデータ同期の遅延を回避できます。

エージェントのコンサルト パターン

ダウンストリーム エージェントは、Model Context Protocol（MCP）または直接 Knowledge Catalog API を介してコンテキスト セットを使用します。詳細については、データアセットのコンテキストを取得するをご覧ください。

レスポンスのレイテンシを最適化し、トークンの消費を最小限に抑えるため、エージェントは段階的な情報開示のコンサルト階層に従います。

1. ルート インデックスと検索語句の照合プロセス: エージェントは、agents ルート インデックスと、データアセット エントリにアタッチされている queries アスペクトを検査します。検証済みの SQL の例がユーザーの意図と一致する場合、エージェントはクエリを適応させて直接実行します。この一致により、クエリエラーのリスクを最小限に抑えながら、迅速なレスポンスが得られます。

2. テーブル コンテキストとスキーマ アセンブリ: 一致する正確なクエリ例がない場合、エージェントはデータアセット エントリ（assets/*）とその schema アスペクトを読み取り、エンティティの関係を理解して、マルチテーブル SQL ステートメントを構築します。

3. ドキュメントとコンセプトのコンサルト: 曖昧なエッジケース（会計カレンダーのカットオフや異議申し立ての除外など）の場合、エージェントはコンセプト（documents/concepts/*）、学習（documents/learnings/*）、ナレッジベース（documents/*）のエントリを読み取り、ビジネスルールを適用します。コンテキスト セット エントリの定義がビジネス用語集の用語の定義と競合する場合、コンシューマ エージェントはコンテキスト セットの定義を優先します。

生成 AI アプリケーションでのコンテキストの消費

生成 AI アプリケーションは、キュレートされたコンテキスト セットを使用して、エンタープライズ ドメインのセマンティクスを理解し、複雑なスキーマをナビゲートして、ハルシネーションのない信頼性の高い SQL を生成します。アプリケーションは通常、次の 2 つの主なパターンでこれらのコンテキスト セットを使用します。

• 動的なコンテキスト検出: 会話型またはセルフサービスの分析環境では、ユーザーは自然言語でアドホックな質問をします。アプリケーションは、ユーザーの意図を動的に評価して、Knowledge Catalog から最も関連性の高いコンテキスト セットを特定して取得し、取得したドメイン知識をアクティブなプロンプトに挿入します。

  Gemini Enterprise アプリケーションを Knowledge Catalog コンテキストでグラウンディングするには、Gemini Enterprise アプリケーションで連携クエリモードの BigQuery データコネクタを構成し、Gemini Enterprise アシスタントの設定で [Knowledge Catalog を有効にする] の切り替えがオンになっていることを確認します。詳細については、BigQuery に接続すると Knowledge Catalog に接続するをご覧ください。

  ユーザーが類似したテーブルを持つ複数の Google Cloud プロジェクトにアクセスできる場合は、カスタムスキルまたは Gemini Enterprise の [追加の LLM システム指示] フィールドで、ターゲット プロジェクト ID とデータセット名を指定して、クエリの対象を目的のデータセットに限定します。詳細については、アシスタントを構成するをご覧ください。

• 事前構成されたコンテキスト セット: 専用エージェント アプリケーションの場合、エージェントのシステム指示またはツール構成でエントリ グループ リソース名（projects/PROJECT_ID/locations/LOCATION/entryGroups/CONTEXT_SET_ID）を指定することで、明示的なコンテキスト セット参照を使用してエージェントを事前構成できます。エージェントは entries/agents ルート インデックスを読み取り、ListEntries、LookupEntry、lookupContext を使用して、そのコンテキスト セットから直接エントリを取得できます。これにより、広範なカタログ検索のオーバーヘッドを回避できます。エージェントは、定期的な拡充ワークフローによってコンテキスト セットが時間の経過とともに改良されるため、品質の向上を自動的に継承します。

  これらの拡充機能と自己学習機能を最適化するには、Gemini Enterprise アプリケーションで Gemini 3.8 Flash 以降のモデルを指定することをおすすめします。モデル選択の手順については、Agent Studio でエージェントを設計するの「フロービルダーを使用してエージェントを作成する」セクションをご覧ください。

コンテキスト セットと関連する構成要素の比較

アーキテクチャに適したメタデータ構造を選択するには、Knowledge Catalog のコンテキスト セットと関連するプラットフォーム機能を比較します。

コンテキスト セットとコンテキスト グラフの比較

コンテキスト グラフとコンテキスト セットは、Knowledge Studio アーキテクチャで異なる役割を持つ 2 つの別個の構成要素です。

• コンテキスト グラフ: 組織全体にわたる、ライブで包括的なセマンティック トポロジ。基盤となるデータアセット、ビジネス用語集の用語、インタラクション トレースをリンクします。このオープン グラフは、Knowledge Studio でインタラクティブに探索して走査できます。詳細については、Knowledge Studio でデータアセットを探索するをご覧ください。

• コンテキスト セット: 境界が定められた、キュレートされたパッケージング ユニット。ドメイン知識の特定のサブセットを抽出してエントリ グループ（type="context-set"）に密閉パッケージ化し、ダウンストリーム AI エージェントが Model Context Protocol（MCP）を介してクエリできるようにします。コンテキスト セットは、より広範なコンテキスト グラフ内で、まとまりのある高密度のサブグラフとして機能します。詳細については、Knowledge Catalog の 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 ロールによって管理されます。このコントロールを使用すると、キュレートされたナレッジを地理的リージョンとドメインの所有権別に整理できます。詳細については、コンテキスト セットを管理するの「必要なロール」セクションをご覧ください。

• ゼロコピーの基盤となるデータ セキュリティ: エージェントにコンテキスト セットへのアクセス権を付与すると、エージェントはセマンティック メタデータとクエリ テンプレートを読み取ることができますが、基盤となるテーブルのアクセス制御をバイパスすることはできません。BigQuery に対して SQL クエリを実行したり、Cloud Storage のファイルを読み取ったりするには、クエリを実行する ID が、基盤となるリソースに対して必要なデータプレーン IAM 権限を保持している必要があります。

• 人間参加型のガバナンス: 自律的な Knowledge Studio の拡充タスクが運用ログから新しいコンセプト、SOP、クエリ テンプレートを抽出すると、提案はレビュー可能な変更リクエストとしてステージングされます。データ スチュワードは、本番環境のコンテキスト セットへの変更を承認する前に、差分の比較と評価スコアを検査します。提案の審査の詳細については、拡充提案を評価して承認するをご覧ください。

• ユーザー管理の実行 ID: コンテキスト セットにデータを入力する自動拡充タスクは、サービス アカウント トークン作成者（roles/iam.serviceAccountTokenCreator）ロールを介して Dataplex サービス エージェントが権限を借用したユーザー管理のサービス アカウントで実行されます。

プレビューの範囲と境界

プレビュー期間中、コンテキスト セットは次の境界内で動作します。

• リージョン スコープ: 単一リージョンのコンテキスト セット（us-central1 など）は、パッケージ化するアセットのリージョンと一致している必要があります。マルチリージョン（us や eu など）と global コンテキスト セットは、互換性のあるリージョン間でアセットを参照できます。マルチリージョンまたは global コンテキスト セットの拡充タスクを構成する場合は、タスクに単一の実行リージョンを選択します。

• コンテキスト セットごとに 1 つの拡充タスク: 各コンテキスト セットは、1 つの拡充タスクでのみ拡充できます。

• クロスコンテキスト セット参照: あるコンテキスト セットのエントリのサブセットを別のコンテキスト セット内で参照することはサポートされていません。

• 作成インターフェースと使用インターフェース: コンテキスト セットは、 Google Cloud コンソールの Knowledge Studio で作成および管理できます。また、エントリ グループ（type="context-set"）としてプログラムで作成および管理することもできます。コンテキスト セットは、Knowledge Studio のエンリッチメント ワークフローを使用するか、エントリをプログラムで管理することで入力します。ダウンストリーム AI エージェントは、Knowledge Catalog API（ListEntries と LookupEntry）と Model Context Protocol（MCP）を使用して、コンテキスト セットをプログラムで検出してクエリできます。詳細については、ナレッジ カタログの MCP サーバーについてをご覧ください。

• 共有割り当て: コンテキスト セットは、基本的に特殊なエントリ グループ（type="context-set"）であるため、標準の Knowledge Catalog エントリ グループと同じリソース割り当てを消費して共有します。詳細については、割り当てと上限をご覧ください。

料金

コンテキスト セットは、標準の Knowledge Catalog エントリ グループ、カスタム エントリ、アスペクトとして保存されます。空のコンテキスト セット エントリ グループまたは未承認の拡充バッチ変更リクエストには、メタデータ ストレージ料金は発生しません。コンテキスト セットにエントリが作成されると（たとえば、拡充変更リクエストを承認した場合や、エントリを直接作成した場合）、エントリ グループをホストするプロジェクトに標準の Knowledge Catalog メタデータ ストレージ料金が適用されます。

プレビュー期間中は、拡充タスクの実行と、未承認の一括変更リクエストのステージングは無料で提供されます。拡充タスクで、ナレッジ シグナルまたは評価セット用の Cloud Storage バケットや、自己学習用の BigQuery エージェント分析トレース テーブルなど、オプションの顧客管理リソースを使用する場合、BigQuery クエリ処理や Cloud Storage ステージングの読み取りと書き込みなどの標準の使用料金がプロジェクトに適用されます。

次のステップ