クラウドサービス

Knowledge Catalog（旧Dataplex Universal Catalog）

BigQueryやCloud Storageのデータを動かさず、エントリ、アスペクト、品質、リネージを横断検索できるKnowledge Catalog。

中級セキュリティ運用上の優秀性
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. データを移さずメタデータと品質情報を横断索引する。
  2. アスペクトとリネージで分析用コンテキストを補強する。
  3. カタログIAMと元データIAMを分け、メタデータ保存量を管理する。

解決する課題

  • Cloud Storage と BigQuery などに散在するデータ資産を、置き場所を横断して発見したい
  • 「どこに何があるか」を組織横断で検索・発見できるようにし、データのサイロ化を防ぎたい
  • 所有者・機密区分・用途などの構造化メタデータを、共通の型で横断管理したい
  • データの鮮度・品質・リネージ（来歴）を継続的に把握し、信頼できるデータだけを使いたい
  • データを移動・コピーせず、元の場所に置いたままガバナンスを効かせたい

主要概念と用語

  • Knowledge Catalog: Dataplex Universal Catalog から改称された現行名称。API 名や gcloud dataplex など一部の技術識別子には旧名称が残る
  • エントリ (Entry): テーブルやモデルなど、1件のデータ資産を表すメタデータ。対応サービスから自動収集されるシステムエントリと、利用者が登録する独自エントリがある
  • エントリグループ (Entry Group): エントリを整理し、IAM を付与する単位。独自エントリの登録元やシステム境界に合わせて設計する
  • エントリタイプ (Entry Type): エントリの構造と必須アスペクトを定義する型。型はリージョン資源で、独自資産の一貫した登録に使う
  • アスペクト / アスペクトタイプ: エントリへ付ける構造化メタデータと、そのスキーマ定義。所有者、機密区分、用途などを機械可読にする
  • 自動取り込み: BigQuery など対応する Google Cloud 資源の技術メタデータをカタログへ取り込む仕組み。データ本体は元サービスに残る
  • データ品質スキャン (Data Quality): 列の充足率・一意性・許容値などのルールを定義し、テーブルに対して継続的に検証するジョブ
  • データプロファイリング (Data Profiling): 列ごとの分布・最小最大・NULL 比率などの統計を自動算出し、データの性質を把握する機能
  • データリネージ (Lineage): テーブルやジョブの間でデータがどう生成・変換されたかの来歴を、上流から下流へ追跡する機能

仕様・制限・クォータ

  • Knowledge Catalog はメタデータを管理するサービスで、専用クラスタは不要。データ本体をカタログへコピーせず、元のサービスに置いたまま索引する
  • エントリ、エントリグループ、エントリタイプ、アスペクトタイプ、検索 API にはクォータがある。上限値は変更され得るため、導入時に公式クォータを確認する
  • エントリタイプやアスペクトタイプはリージョン資源であり、型を複数プロジェクト横断で一覧取得する操作は非対応。命名規約と配布手順を別途管理する
  • 旧 Dataplex のレイク・ゾーン・アセット・エンティティは Knowledge Catalog のエントリとして登録できず、そこへ付けたメタデータも引き継がれない。同名 API が残っていても、現行カタログの階層として扱わない
  • 管理者権限で組織全体を無条件に検索する専用の管理者検索はない。検索範囲と呼び出し元のカタログ権限を設計する
  • 旧 Data Catalog は 2026年6月1日から段階的な停止が始まっている。既存タグや API クライアントは Knowledge Catalog のアスペクトと API へ移行し、旧 API を新規設計へ持ち込まない

内部の仕組み

横にスクロール

BigQueryやCloud Storageの資産からメタデータ・品質・リネージを収集し、Knowledge Catalogのエントリとアスペクトへ統合して、IAMで絞った検索結果を利用者やAIへ渡す経路を示す図
データ本体は移動せず、鮮度のあるメタデータと権限付きコンテキストを検索利用者へ届ける

Knowledge Catalog はデータ本体ではなくメタデータを取り込むサービスです。対応する Google Cloud 資源の技術メタデータはシステムエントリとして収集され、独自資産はエントリタイプに従って登録します。データ本体は BigQuery や Cloud Storage などの元サービスに残ります。

エントリには、説明や所有者などのアスペクトを付けます。アスペクトタイプを先に定義することで、部署ごとに表記が揺れるのを防ぎ、検索・自動判定・AI 利用へ同じ構造化情報を渡せます。エントリグループは登録元や責任境界を整理し、カタログ IAM を付与する単位になります。

品質スキャンとプロファイリングの結果、リネージ、用語などを資産のメタデータへ結び付けると、検索結果から信頼性や影響範囲まで判断できます。ただし、エントリを閲覧できることは元データを読めることを意味しません。カタログ IAM と BigQuery / Cloud Storage 側の IAM は別々に検証します。

旧 Data Catalog から移行する

Dataplex Universal Catalog の名称変更後も API 名や gcloud dataplex は残ります。一方、旧 Data Catalog は 2026年6月1日から段階的停止中です。タグテンプレートはアスペクトタイプへ、クライアントと Terraform は Knowledge Catalog 側へ移し、アップグレード後の検索・更新を実利用者の権限で再検証します。

検索と利用許可を分ける

カタログは「どこに何があるか」を見つける索引です。元データの権限を自動で付与する仕組みではないため、検索結果から利用申請へ進み、資産側 IAM で承認する経路まで設計します。

設計パターン / ベストプラクティス

  • エントリグループを登録元や責任境界で分け、グループ単位の IAM と運用担当を一致させる
  • 独自資産はエントリタイプ、組織共通の意味はアスペクトタイプで定義し、必須項目と版管理を標準化する
  • カタログにはアスペクトで意味付けを行い、機密区分やオーナー、用途を機械可読に残して検索性とガバナンスを両立させる
  • 重要テーブルには品質スキャンを定期実行し、合格したデータだけを下流が参照する運用にして「信頼できるデータ」を担保する
  • カタログ閲覧権限と元データ閲覧権限を分け、検索後のアクセス申請経路を用意する

運用・監視

  • 品質スキャンの合格 / 不合格の結果を監視し、不合格時には通知やパイプライン停止につなげて、汚れたデータの下流流入を防ぐ
  • プロファイル結果のNULL 比率や分布の急変を、データ異常の早期検知シグナルとして扱う
  • 自動取り込み対象の最終更新時刻と欠落を確認し、検索結果の陳腐化を検知する
  • リネージで影響範囲を可視化し、上流テーブルの変更時に下流への波及を事前に把握する
  • 独自エントリとアスペクトの更新失敗を監査ログで追い、所有者が空欄の重要資産を定期的に是正する

コスト

機能カテゴリ課金の考え方コストを抑える指針
カタログのメタデータ保存保存するメタデータ量に応じた従量不要な独自エントリとアスペクトを整理
資源管理 / 検索作成・管理と検索API、画面検索は無料クォータ内で必要な検索を行う
品質 / リネージ処理プレミアム処理と関連サービスで別途課金重要な対象と実行頻度に絞る
データ本体の保存Cloud Storage / BigQuery 側で別途課金ストレージ層の最適化はそちらで行う
検索回数ではなく保存量を測る

カタログ資源の作成・管理と検索 API は無料ですが、メタデータの保存量には料金が発生します。品質スキャンやリネージ処理、BigQuery と Cloud Storage の利用料は別枠なので、料金項目を混ぜずに見積もります。

セキュリティ

  • カタログのエントリ、グループ、型、アスペクトには IAM を最小権限で付与する。メタデータの閲覧・更新権限と元データの利用権限を混同しない
  • データ本体は Cloud Storage / BigQuery 側の暗号化と IAM に従う。カタログは元データへのアクセス権を自動で付与しない
  • カタログに機密区分のアスペクトを付け、どのデータが個人情報や機密かを横断的に識別する。Sensitive Data Protection（旧 DLP）と組み合わせると検出を自動化できる
  • 外部流出対策として VPC Service Controls を併用し、サービス境界を越えたメタデータ・データの持ち出しを防ぐ
アンチパターン

カタログで機密区分を付けただけで、元データも保護されたと判断してはいけません。検索・メタデータ更新はカタログ IAM、実データの読み書きは BigQuery / Cloud Storage の IAM でそれぞれテストします。

Well-Architected の観点

  • セキュリティ: データを移動せずに分類と機密検出を横断適用できる。カタログと元データの IAM、VPC Service Controls を別々に検証する
  • 運用上の優秀性: メタデータ収集・品質スキャン・リネージを自動化し、データの状態を継続的に観測できる。手作業のカタログ整備や品質チェックから解放され、信頼できるデータを安定供給する運用に寄せられる

試験で問われるポイント

頻出
  • Knowledge Catalog はデータを移動・コピーせず、各資産のメタデータを横断検索するカタログである点
  • エントリ・エントリグループ・エントリタイプ・アスペクトタイプの役割と、カタログ IAM と元データ IAM が別である点
  • データの発見（カタログ検索）・品質スキャン・プロファイリング・リネージという主要機能の役割の区別
  • 横断的な検索・発見が必要なら Knowledge Catalog、分析クエリの実行は BigQuery、という役割分担
  • 旧レイク・ゾーン・アセットを現行カタログの階層として扱わず、移行時は対応しない資源とメタデータを確認する点

関連サービス・比較

観点GCP（Knowledge Catalog）AWS（Glue Data Catalog）
主目的データ資産の発見とメタデータ管理メタデータの登録と検索
メタデータ索引エントリとアスペクトデータベース、テーブル、分類
元データ権限BigQuery / Storage側で別管理S3 / Lake Formation等で別管理
管理対象Google Cloud資産と独自資産AWS資産と外部資産
データ品質 / プロファイル品質スキャン・プロファイリングを内蔵Glue Data Quality 等を併用
データ移動移動せず元の場所のまま管理原則 S3 上のデータをそのまま管理

ハンズオン / CLI例

# 1) 利用できるエントリタイプとアスペクトタイプを確認
gcloud dataplex entry-types list \
  --location=asia-northeast1 \
  --project=MY_PROJECT

gcloud dataplex aspect-types list \
  --location=asia-northeast1 \
  --project=MY_PROJECT

# 2) 独自エントリを整理するエントリグループを確認
gcloud dataplex entry-groups list \
  --location=asia-northeast1 \
  --project=MY_PROJECT

# 3) 利用者と同じプロジェクト範囲でカタログを検索
gcloud dataplex entries search 'sales' \
  --project=MY_PROJECT \
  --scope=projects/MY_PROJECT

Google Cloud Service

Knowledge Catalog（旧Dataplex Universal Catalog）を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

分析

比較で見る軸

クラウド: Google Cloud / カテゴリ: 分析 / 難易度: intermediate

導入後に効く点

アスペクトとリネージで分析用コンテキストを補強する。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Google Cloud
カテゴリ
分析
難易度
intermediate
関連資格
—
設計柱
security / operational

判断チェックリスト

  • 自社の用途が「分析 / security」に近いか確認する。
  • 強みである「データを移さずメタデータと品質情報を横断索引する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

分析securityoperational
参考: 公式ドキュメント