Google Cloud · Field note

Knowledge Catalog の設計判断 ── Gemini・MCP・BigQuery を貫くコンテキストエンジンの使い方

2026-04-10 に改称した Knowledge Catalog のメタデータモデル (Entry / Aspect Type / Data Products)、MCP によるエージェント統合、旧 Data Catalog 廃止対応、BigQuery ネイティブメタデータの自動取り込みと追加レイヤーを整理します。

Google Cloud Knowledge Catalog Dataplex BigQuery Gemini データガバナンス 中級
Published
Read
18 min
Author
tgeas
目次
  1. Knowledge Catalog の現在地 ── 「カタログ」から「コンテキストエンジン」への改称が意味すること
  2. メタデータモデルの刷新 ── Aspect Type・Entry・Data Products が組み変えた設計図
  3. AI エージェントにコンテキストを渡す ── MCP とセマンティック検索が変えるデータ活用の接点
  4. 請求と制約の地図 ── Discovery 無料枠とプレミアム処理の境界線
  5. BigQuery メタデータの上に何を積むか ── 自動取り込みの範囲と Aspect で補う層
  6. まとめ ── メタデータ設計を AI 基盤の第一歩に据える
  7. 参考文献

Knowledge Catalog をデータカタログとして眺めるか、AI エージェントのコンテキスト基盤として眺めるかで、設計の優先順位は変わります。本記事では、2026-04-10 の改称が示す製品の現在地、Entry / Aspect Type によるメタデータモデルの刷新、Gemini 連携と MCP によるエージェント統合の仕組みを順に整理します。BigQuery ネイティブメタデータが Knowledge Catalog にどう取り込まれ、その上にどんな層を足すか、料金設計で踏みやすい落とし穴、旧 Data Catalog 廃止期限を踏まえた移行優先度も合わせて扱います。これらを踏まえ、自社のメタデータ設計が AI 活用のボトルネックになっていないかを点検しましょう。

Knowledge Catalog の現在地 ── 「カタログ」から「コンテキストエンジン」への改称が意味すること

Knowledge Catalog は 2026-04-10 に「Dataplex Universal Catalog」から改称した Google Cloud のデータカタログです。公式の製品定義では「Gemini-powered data catalog that provides universal business context and governance for your entire data estate」と説明されており、Google Cloud 公式ブログは “universal context engine for your enterprise” という表現を使っています。

改称が単なるブランド変更でない理由は、製品が解くべき課題の定義が変わったからです。従来のデータカタログが「資産の発見・検索」を中心に設計されていたのに対し、Knowledge Catalog は「AI エージェントが即座に参照できるコンテキストを整備する基盤」として位置付けられています。

ここで注意が必要な命名の一貫性です。製品名は「Knowledge Catalog」ですが、API・SDK・IAM・SKU の識別子はすべて dataplex のままです。ドキュメント URL も cloud.google.com/dataplex/... を使います。

この二重構造は、移行期に設定ミスや権限設定エラーを引き起こしやすいです。実装時は識別子として「Dataplex」を使い、表示名として「Knowledge Catalog」を使うと整理しやすいです。

製品は 3 つの柱で機能しています。Aggregation (メタデータの自動収集)、Enrichment (Gemini による自然言語注釈の生成)、Search (セマンティック検索) の組み合わせが、単なるカタログと異なる点です。

自動メタデータ収集の対応状況は、BigQuery・AlloyDB・Spanner・Cloud SQL が GA 済みです。Firestore と Looker は Preview 段階のため、本番利用は仕様変更を見込んだ設計が必要です。

旧 Data Catalog は 2025-02-03 に deprecated が宣言され、2026-06-01 にシャットダウン されます。この期限は相当に近く、旧 Data Catalog を本番で使っている場合は移行を優先する必要があります。

メタデータモデルの刷新 ── Aspect Type・Entry・Data Products が組み変えた設計図

Knowledge Catalog のメタデータモデルは、旧 Data Catalog から構造的に刷新されています。まず各要素を整理します。

Entry はデータアセット 1 件を表す基本単位です。BigQuery のテーブル 1 つ、ビュー 1 つがそれぞれ Entry として表現されます。Entry Group は Entry の入れ物であり、アクセス制御の単位でもあります。Aspect は Entry に付与する関連メタデータフィールドの集合で、旧 Data Catalog の「Tag」に相当します。Aspect Type は Aspect の再利用可能なテンプレートであり、旧 Data Catalog の「Tag Template」に相当します。Entry Type は新しく追加された概念で、Entry 作成時に必須の Aspect を強制するテンプレートです。Data Products は関連する Entry をビジネス目線でパッケージ化する単位です (GA 済み)。

旧 Data Catalog との主な違いを整理します。

観点旧 Data CatalogKnowledge Catalog
AI 活用なしGemini で自動コンテキスト生成
メタデータ構造タグ (フラット)アスペクト (ネスト・配列・マップ対応)
AI エージェント対応なしMCP 経由で対応
自動化限定的プロファイリング・品質スキャン・ガバナンス統合
ライフサイクル2026-06-01 シャットダウン現行

Aspect の構造的な柔軟性が、旧 Tag との最大の差分です。旧 Tag はキーとバリューのフラットな構造でしたが、Aspect はネスト・配列・マップをサポートします。これにより、データ品質スコアの履歴や複数のオーナー情報を 1 つの Aspect に収められます。

設計上の重要な制約が 1 つあります。Aspect Type は Entry と同一ロケーションか、global で定義する必要があります。 異なるリージョンに分散した Aspect Type を 1 つの Entry に付与することはできません。この制約を見落として、asia-northeast1 の Entry に us-central1 の Aspect Type を付与しようとすると、エラーが発生します。

グローバル展開が前提の設計では、Aspect Type を global に置くか、リージョンごとに Aspect Type を複製するかを事前に決めておく必要があります。どちらを選ぶかは、管理コストとリージョン境界での権限設計によって判断してください。

Data Products は Entry をビジネス文脈でパッケージ化する仕組みです。「販売分析用データセット」のように複数テーブルをまとめて 1 つのデータ製品として公開できます。ただし、1 プロジェクト / リージョンあたりの上限は 50 個 です。規模の大きな組織では早い段階でこの上限を意識した設計が必要です。

旧 Data Catalog では「プライベートタグ」として非公開のメタデータを付与できましたが、Knowledge Catalog の Aspect にはプライベートタグに相当する機能がありません。移行時にプライベートタグを使っていた場合は、Aspect としてパブリック化するか、別の管理手段を検討する必要があります。アクセス制御を厳密に維持したい場合は、Entry Group ごとに IAM を設計するか、機微なメタデータを Secret Manager に外出しして Aspect から参照する選択肢があります。

AI エージェントにコンテキストを渡す ── MCP とセマンティック検索が変えるデータ活用の接点

Knowledge Catalog が「コンテキストエンジン」を名乗る根拠は、MCP (Model Context Protocol) 統合にあります。AI エージェントがデータを活用しようとするとき、名前が似た複数のテーブルから正しいものを選べなければ、確実に間違った回答を返します。

公式は “reasoning without context is just a guess” と表現しています (Google Cloud Next ‘26 基調講演)。

Knowledge Catalog のリモート MCP サーバーは https://dataplex.googleapis.com/mcp で提供されており、Gemini CLI・Gemini Code Assist・Claude Desktop・Claude Code・Cline・Cursor・VS Code・Windsurf など主要な AI ツールから接続できます。ローカル開発環境向けには MCP Toolbox も用意されています。

MCP Toolbox 経由で LLM に公開される主要ツールは 4 つです。リモート MCP サーバー全体ではデータプロダクト管理用ツールなども提供されています。

  • search_entries — データアセットの検索
  • lookup_entry — スキーマ・所有情報の取得
  • search_aspect_types — ガバナンス分類の検索
  • lookup_context — 事前整形済みのリッチなメタデータセットの取得

この中で特に重要なのが lookup_context です。エージェントがテーブル名を受け取った後、スキーマ・所有者・ビジネス用語・品質スコアをまとめて取得できるため、プロンプトに個別情報を埋め込むより効率的にコンテキストを渡せます。

最短で動かすなら、Claude Code の ~/.claude.json に以下のような MCP サーバー定義を追加します (概念的な設定例です。詳細は 公式 MCP セットアップガイド を参照してください)。

{
  "mcpServers": {
    "knowledge-catalog": {
      "url": "https://dataplex.googleapis.com/mcp"
    }
  }
}

エージェントが呼び出す Google アカウント (またはサービスアカウント) には、検索とエントリ参照のために roles/dataplex.catalogViewer を最低限付与しておきます。Aspect Type を含むガバナンス分類まで参照させたい場合は roles/dataplex.metadataReader を追加します。

セマンティック検索は Google Search と同等の技術を用いた実装で GA 済みです。アクセス制御と連動しているため、権限のないユーザーが検索結果から機密データを発見することを防げます。

Looker 連携では、LookML が「セマンティックグラフ」として Knowledge Catalog に取り込まれます。これにより Looker のビジネス定義 (ディメンション・メジャーの意味) が BigQuery measures と統合され、エージェントがビジネス文脈を把握した上でデータを参照できる構造になります。

ただし、Looker のメタデータ自動カタログ化は現時点で Preview 段階です。Looker のリネージュについても制約があり、BigQuery ソースのみ・オブジェクトレベルのみ・最大 8 時間の遅延があります。

Looker を使った AI エージェント対応については、Looker Conversational Analytics の仕組みと設計判断 で詳しく整理しています。

Gemini Enterprise ユーザー向けには Deep Research Agent との統合が Google Cloud Next ‘26 で発表されましたが、こちらも Preview 段階です。Preview 機能を本番ワークフローに組み込む際は、GA 後に仕様が変わる可能性を考慮した設計が必要です。

請求と制約の地図 ── Discovery 無料枠とプレミアム処理の境界線

Knowledge Catalog の料金は、処理の種類によって無料と有料が明確に分かれています。

Standard Processing はメタデータの発見 (Discovery) に使われる処理カテゴリです。月 100 DCU-hour (Data Compute Unit) まで無料枠があります。東京リージョン (asia-northeast1) の単価は $0.076976 / DCU-hour、Premium Processing は $0.114181 / DCU-hour です (出典: Knowledge Catalog 料金、2026-05-05 確認)。us-central1 と比べると、東京リージョンは Standard / Premium ともにおよそ 28% 高い水準です (us-central1 は Standard $0.060、Premium $0.089)。

東京リージョンを起点とした試算として、無料枠 100 DCU-hour を超えて月 500 DCU-hour 利用する場合、Standard Processing で超過分 400 DCU-hour × $0.076976 = 約 31 USD (約 4,900 円)、Premium Processing は無料枠なしのため 500 DCU-hour × $0.114181 = 約 57 USD (約 9,100 円) が目安になります (1 USD = 160 円換算、2026-05-05 確認)。Premium 機能を全テーブルに無差別に適用すると想定外の請求につながりやすいため、対象を絞った設計が前提です。

Premium Processing はリネージュ追跡・データ品質スキャン・プロファイリングに使われる処理カテゴリです。こちらは無料枠がありません。Premium Processing を有効にする機能をデフォルトで全テーブルに適用すると、想定外の請求が発生します。初期設定では対象テーブルを限定することを推奨します。

無料で使える機能も存在します。lake / zone / asset のセットアップ、セキュリティポリシーの伝播は無料です。

API のクォータも把握しておく必要があります。

  • エントリ・アスペクトの読み取り: 6,000 リクエスト / プロジェクト / リージョン / 分
  • エントリ・アスペクトの書き込み: 1,500 リクエスト / プロジェクト / リージョン / 分
  • 検索リクエスト: 1,200 リクエスト / プロジェクト / 分

MCP 経由で AI エージェントが頻繁にメタデータを参照する構成では、検索リクエストのクォータに注意が必要です。エージェントが複数の会話セッションを並列に処理する場合、1,200 req / 分の上限に達する可能性があります。エージェント側でのキャッシュ設計やリクエストの集約を検討してください。

リネージュの保持期間は 30 日間 です。30 日を超えたリネージュデータは削除されます。監査や規制対応でリネージュを長期保存する必要がある場合は、外部ストレージへのエクスポートを別途設計する必要があります。

列レベルのリネージュにも制約があります。以下のケースでは、列レベルではなくテーブルレベルにサイレントフォールバックします。

  • load jobs と routines
  • external tables (upstream)
  • 1 ジョブあたり 1,500 列リンク超

この挙動はドキュメントに記載されていますが、実際にフォールバックが発生してもエラーは出ないため、列レベルリネージュの精度に依存した分析は事前に検証することを推奨します。

BigQuery メタデータの上に何を積むか ── 自動取り込みの範囲と Aspect で補う層

BigQuery ネイティブメタデータと Knowledge Catalog は、「どちらかを選ぶ」関係ではありません。BigQuery の datasets・tables・views・カラム説明・ラベルは Knowledge Catalog に自動的に取り込まれ、Knowledge Catalog の検索やリネージュからそのまま参照できます (出典: BigQuery × Knowledge Catalog)。設計判断は「両者を比較する」ことではなく、自動取り込みされる層の上にどんな追加レイヤーを積むかになります。

メタデータの構造を 3 層で整理します。

レイヤー担当含まれるもの
ネイティブメタデータBigQuerydatasets / tables / views / カラム説明 / ラベル / ポリシータグ
自動取り込み層BigQuery → Knowledge Catalogdatasets / tables / views / 説明 / ラベルが Knowledge Catalog で参照可能になる (ポリシータグは BigQuery 側で管理が継続)
追加レイヤーKnowledge CatalogAspect (ownership / quality / SLA / 規制区分)、Data Products、セマンティック検索、Gemini による自動注釈、MCP 経由の AI エージェント連携

ポリシータグは例外です。列レベルアクセス制御に使う BigQuery のポリシータグは Knowledge Catalog に取り込まれず、BigQuery 側での管理が継続します。アクセス制御を BigQuery のポリシータグで完結させてきた構成は、そのまま動き続けます。

追加レイヤーを実装するかどうかは、自動取り込み層で足りるかどうかで判断できます。自動取り込み層で足りるケースは、データが BigQuery に集中しており、テーブル説明とラベルだけで意思疎通が成立しており、AI エージェントへのコンテキスト提供も現時点で必要ない場合です。Knowledge Catalog は有効化するだけでよく、Aspect Type の設計コストは発生しません。

追加レイヤーを積むべきケースは、(1) AlloyDB・Spanner・Cloud SQL・Looker・サードパーティツールをまたいでメタデータを横断管理したい、(2) Gemini や Claude などの AI エージェントにメタデータを渡して自然言語クエリの精度を上げたい、(3) ownership や品質スコアのような構造化メタデータを Aspect でテーブルごとに付与したい、のいずれかが該当する場合です。

旧 Data Catalog は別の流れで扱います。2026-06-01 のシャットダウンに向けて移行が必要な場合は、Tag Template → Aspect Type、Tag → Aspect の対応関係を先にマッピングし、プライベートタグの扱いを決めてから作業を進めると安全です。詳細は 移行ガイド を参照してください。

サードパーティ統合 (Atlan・Collibra・Datahub・Ab Initio・Anomalo) は、追加レイヤーの一部として位置付けられます。既存のデータガバナンスツールを導入している場合、Knowledge Catalog のコネクタで連携するか、Knowledge Catalog を中心に統合するかの判断が必要です。

まとめ ── メタデータ設計を AI 基盤の第一歩に据える

Knowledge Catalog は、Gemini・BigQuery・Looker を横断するメタデータを「AI エージェントが即座に参照できるコンテキスト」として整備する基盤であり、その設計の質が企業の AI 活用全体のボトルネックを決めます。

MCP 統合によって AI エージェントはメタデータに直接アクセスできるようになりましたが、Entry / Aspect Type の設計が粗ければ、エージェントが参照するコンテキストも粗くなります。

優先度別に整理すると、まず旧 Data Catalog の廃止期限 (2026-06-01) を確認し、移行が必要ならすぐに着手してください。次に、BigQuery の自動取り込み層だけで足りるのか、Aspect・Data Products・サードパーティ連携といった追加レイヤーを積むべきかを判断することで、Knowledge Catalog の導入範囲が決まります。AI エージェントへのコンテキスト提供を本番で必要とするなら、MCP 接続の前に Aspect Type の設計と Aspect の整備を先行させることが、投資対効果を高める順序です。

Preview 機能 (Looker 自動カタログ化・検証済みクエリ・Smart Storage・Deep Research Agent 統合) は将来の中心になる可能性が高い領域ですが、本番採用は GA を待つか、フォールバック設計を前提にした実装を推奨します。

参考文献

Author
tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。