Knowledge Catalog の検索について

Knowledge Catalog（旧称: Dataplex Universal Catalog）の検索では、セマンティック マッチング、キーワード、構造化述語を使用した自然言語クエリを使用して、組織全体のリソースを検出できます。特定のデータアセットを検索したり、システム間で関連するメタデータを探索したり、プログラムによるワークフローや Agentic Workflows のスコープ付き結果を取得したりできます。

ユースケース

次のリストに、一般的な検索のユースケース、説明、クエリの例を示します。

  • ターゲットを絞ったアセット検索: アセット名、列、説明に関連するキーワードを検索して、特定のアセットを見つけます。

    クエリの例

    • retail_transactions_2026
    • customer_id
    • column:customer_id

  • 幅広いデータ検出: 自由形式の自然言語クエリまたはキーワード クエリを使用して、組織全体で関連するアセットを特定します。

    クエリの例

    • quarterly financial reports
    • ad campaign click through rates tables
    • server health metrics
    • audit logs system=bigquery

  • ワークフローのスコープ付きアセットの取得: プロジェクトなどの特定のコンテナ内のアセット、またはタイプやシステムなどの特定のプロパティを持つアセットを列挙します。このアプローチは、プログラマティック ワークフローとエージェント ワークフローでよく使用されます。

    クエリの例

    • type=table projectid:banking-prod aspect:classification.tier=PII
    • system=spanner projectid:inventory-service (parent=marketing_analytics OR parent=finance_analytics)

仕組み

検索では、Knowledge Catalog で管理されているデータアセットのすべてのコンテキストが自動的にインデックスに登録されます。これには次のものが含まれます。

  • BigQuery や Cloud SQL などの Google Cloud データソースから自動的に取り込まれたメタデータ
  • コネクタと統合を介して取り込むリソースのコンテキスト
  • リソース用に作成する追加のコンテキスト。たとえば、ビジネス コンテキストを表したり、データのセマンティクスを記述したりします。コンテキストは、アスペクトまたはリンクされたビジネス用語の形式でキャプチャされることもあります。

クエリを処理する際、検索ではセマンティック マッチングとキーワード マッチングの組み合わせが適用されます。次の表に、Knowledge Catalog 検索で使用できるクエリタイプ、説明、サンプルクエリを示します。

クエリの形式 使用量 例
単一キーワード アセット名、説明、スキーマなどのメタデータ要素全体で完全一致と部分文字列一致を行う場合。 prd_fin_invoices_fct_v02
部分キーワードとトークン化されたフラグメント メタデータ コンテンツ全体で部分文字列を照合し、略語、区切られた単語、命名バリエーションを含むリソースを検索します。 fin transactions 2026（prd_fin_transactions_fy2026_raw と一致）
自然言語クエリ 名前や列の完全一致を必要とせずに、セマンティック マッチングを使用します。 customer churn prediction features
構造化述語 フリーテキスト クエリと明示的な述語フィルタを組み合わせて、検索結果を絞り込みます。 audit logs system=bigquery
拡張構文 特定のスコープに絞り込んだ、正確な検索。拡張構文は、エージェント型およびプログラム型のユースケースで最もよく使用されます。詳細については、検索構文をご覧ください。 (system:bigquery OR system:spanner) AND column:credit_card_number aspect:classification.tier=PII -projectid:sandbox-project

Knowledge Catalog で検索にアクセスするには、次の方法があります。

検索範囲

Knowledge Catalog の検索結果には、ソースシステム内の対応するリソースに対する権限が適用されます。

たとえば、オブジェクトに対する BigQuery メタデータの読み取りアクセス権を持っている場合、そのオブジェクトは Knowledge Catalog の検索結果に表示されます。BigQuery テーブルにアクセスできるものの、そのテーブルを含むデータセットへのアクセス権がない場合でも、テーブルは Knowledge Catalog の検索で想定どおりに表示されます。

デフォルトでは、検索の範囲は組織に限定されています。検索結果には、検索対象のプロジェクトと同じ組織のリソースのみが含まれます。

検索結果には、検索が実行されるプロジェクトと同じ VPC Service Controls 境界に属するリソースのみが含まれます。Google Cloud コンソールを使用する場合、これはコンソールで選択したプロジェクトです。

プロジェクトの VPC Service Controls 境界内のリソースを超えて検索結果の範囲を広げるには、VPC Service Controls の上り（内向き）と下り（外向き）のルールを使用します。これらのルールにより、組織全体で限定公開かつ効率的なデータ交換が可能になります。上り（内向き）ルールと下り（外向き）ルールは、Google Cloud コンソール、JSON ファイル、YAML ファイルのいずれかを使用して構成できます。次の YAML の例と VPC Service Controls のドキュメントを参照して、ルールを特定の要件に合わせて調整します。

egressPolicies:
  - egressFrom:
      identityType: ANY_USER_ACCOUNT
    egressTo:
      # Specify which resources should be present in the search results. In this example,
      # BigQuery.
      operations:
      - methodSelectors:
        - method: '*'
        serviceName: bigquery.googleapis.com
      # Specify project ids under which the search is performed.
      resources:
      - projects/SEARCH_PROJECT_ID
ingressPolicies:
  - ingressFrom:
      identityType: ANY_USER_ACCOUNT
      sources:
      - accessLevel: '*'
    ingressTo:
      # Specify which resources should be present in the search results. In this example,
      # BigQuery.
      operations:
      - methodSelectors:
        - method: '*'
        serviceName: bigquery.googleapis.com
      # Specify project ids to expose in search results.
      resources:
      - projects/INGRESS_PROJECT_ID

ナレッジ カタログ検索に必要な Identity and Access Management ロールの詳細については、ナレッジ カタログ IAM ロールをご覧ください。

VPC Service Controls を使用して環境ごとに検索結果を分離する

開発環境、テスト環境、本番環境などの環境間で Knowledge Catalog の検索結果を分離するには、各環境に個別の VPC Service Controls 境界を構成します。データアセットを含むプロジェクトと、検索の実行に使用されるプロジェクトの両方を、対応する環境の境界に割り当てます。特定の境界内のプロジェクトから実行された検索では、同じ境界内にあるアセットの結果のみが返されます。

検索での再現率の上限

Knowledge Catalog の検索は、網羅的なインベントリ取得ではなく、探索的な検出に最適化されているため、検索クエリは完全な再現率を保証するものではありません。クエリで一致する結果が省略されることがあり、クエリを繰り返すと返される結果が異なることがあります。

再現率低下の原因

検索時に、Knowledge Catalog は 600 個の制限（権限評価ルール）のアクセス制御制限に対して権限を動的にチェックします。アクセス チェックがこの上限を超えると、検索を高速に保つために、システムはチェックを早期に停止します。その場合、検索で一致するアセットが除外されることがあります。

次のいずれかの条件に該当する場合、この上限に達する可能性が高くなります。

  • 数百の個々のリソースに直接割り当てられた IAM ロール。
  • 個々のリソースへのアクセス権を付与する複数の Google グループのメンバー。
  • 数百の個々のリソースに直接アクセス権が付与されている Google グループのメンバー。

再現率の制限と結果の欠落を解決する

再現率の問題を解決する、または完全なメタデータを取得するには、目的に合った方法を選択します。

  • 検索結果が見つからない、または一致しない問題を解決するには: アクセス チェックの合計数を減らして、600 の制限を下回るようにします。必要なリソースにのみアクセス権を付与し、権限が不要なリソースまたは Google グループからアクセス権を削除します。個々のリソースではなく、プロジェクト レベルまたはフォルダレベルでロールを付与することもできます。
  • 完全で保証されたメタデータ インベントリを取得するには: 検索を使用しないでください。代わりに、メタデータを Cloud Storage にエクスポートし、BigQuery でデータセット全体をクエリします。

次のステップ