Knowledge Catalog の検索について

Knowledge Catalog（以前の Dataplex Universal Catalog）の検索を使用して、セマンティック マッチング、キーワード、構造化述語を含む自然言語クエリを使用して、組織全体のリソースを検出します。

ユースケース

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

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

    クエリの例

    • 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

Knowledge Catalog 検索に必要な Identity and Access Management ロールの詳細については、Knowledge Catalog IAM ロールをご覧ください。

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

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

検索での再現率の上限

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

リコールの損失の原因

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

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

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

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

リコールに関する問題を解決したり、完全なメタデータを取得したりするには、目的に合った方法を選択します。

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

次のステップ