Google Cloud Data Catalog廃止、Knowledge Catalog移行の実務手順

Google CloudのメタデータカタログサービスであるData Catalog（テーブルやファイルを横断検索し、タグで分類情報を付けるサービス）は、2026年6月1日から段階的なシャットダウンに入っている[1][2]。後継は、同年4月10日にDataplex Universal Catalogから改称したKnowledge Catalogである[2]。

移行で形が変わるのは、タグテンプレート、カスタムエントリ、IAM権限の3つだ。公開設定のタグやカスタムエントリは読み取り専用でKnowledge Catalogに自動で反映されるが、書き込みの正本を移すアップグレードについて、公式の移行ガイドは「アップグレード操作は不可逆である」と警告している[3]。しかもアップグレードはテンプレート単位で行い、そのテンプレートを使うタグがすべて一緒に移る[3]。戻せない操作に入る前に、どのテンプレートを公開に変え、どの権限を付け直し、どの順番で上げるかを決めておく必要がある。

予備知識

• メタデータカタログ: テーブルやファイルがどこにあり、誰が管理しているかを一元的に検索・管理する仕組み
• タグテンプレートとタグ: 「機密区分」「データオーナー」のような項目の組を定義したひな型がタグテンプレートで、これを使ってテーブルや列に付けた値がタグ
• エントリグループ: 関連するエントリ（データ資産の登録単位）をまとめる入れ物。IAMの付与先にもなる
• アスペクトタイプとアスペクト: Knowledge Catalogでタグテンプレートとタグに相当するもの
• IAM（Identity and Access Management）: 誰がどのリソースに何の操作を許可されるかを制御するGoogle Cloudの権限管理機能

タグテンプレートやビジネスグロッサリーの再設計を場当たり的にせず、データガバナンスの標準的な知識体系に沿って進めたい担当者に。

データマネジメント知識体系ガイド 第二版 改定新版

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

Data Catalogは何がいつ止まるのか

Data Catalogと周辺機能の終了は、次の5つの日付で進んできた[1]。

6月5日付のリリースノートは「2026年6月1日から、Data Catalogサービスは段階的なシャットダウンを開始する。この日以降、Data Catalog APIの中断や完全なアクセス不能が起こり得る」と書き、Knowledge Catalog側は影響を受けずに動くとしている[2]。どのAPIからいつ止まるかは、リリースノートには示されていない。今日動いているタグ付けの処理が来週も動く保証はない、ということになる。

非公開タグを公開に切り替えるか、アスペクトタイプの権限を誰に渡すかといった判断を、データスチュワードの役割と統制活動の枠組みから決め直したい担当者に。

成果を生む攻めのデータガバナンス データを経営資産に変える仕組みづくり

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

Knowledge Catalogへの移行で何が変わるのか

Knowledge Catalogは改称とともに、受け身のメタデータ台帳から、AIエージェントに業務の文脈を渡すコンテキストグラフへと位置づけを変えた[5]。一方で、API、クライアントライブラリ、CLI、IAMの名前はDataplexのまま変わっていない[2][5]。Google Cloud Japanの公式アカウントも、5月12日にこの位置づけを日本語で告知している。

Dataplex が Knowledge Catalog へ進化
→ goo.gle/4ffVkTS

データアセット全体でコンテキストを統合し、管理の行き届いた信頼できる情報源に一元化。継続的なデータ拡充機能を実際に作業する環境に提供し、高精度で安全なデータ取得によるエージェントの活用を拡大します。
#GoogleCloudNext

— Google Cloud Japan (@googlecloud_jp) 元投稿を見る

Data Catalogの資産の一部は、Knowledge Catalogに自動で現れる。カスタムエントリグループ、エントリ、タグ、公開タグテンプレートは、読み取り専用のリソースとして参照できる[3]。ただし準備フェーズを終えるまでは、公開タグテンプレートとタグの一部がKnowledge Catalogの検索に出ないことがある[3]。タグテンプレートはグローバルなアスペクトタイプ、タグはオプションのアスペクト、カスタムエントリはGenericEntryTypeのエントリになる[3]。個別のエントリタイプを前提にした検索条件やダッシュボードは、結果が変わらないかを確かめておく。

例外は非公開タグテンプレートで、Knowledge Catalogには非公開のアスペクトという概念がないため、公開に変えるまで反映されない[3]。非公開タグはテンプレートとエントリの両方に閲覧権限を持つ人にしか見えないが、公開にするとエントリを閲覧できる人全員に見える[6]。移行ガイドも、公開前にテンプレートの構造とメタデータが公開タグとして見えてよいかを確認するよう求めている[3]。

IAMは対象と条件を分けて読む必要がある。Data Catalogのタグテンプレートとエントリグループに対応するアスペクトタイプとカスタムエントリグループは、元のIAM権限を引き継がない[3]。ただし、Data CatalogのIAMロールをプロジェクト以上の階層で付与していれば、必要なKnowledge Catalogの権限は自動で含まれる[3]。手作業の設定が要るのは、カスタムロールを使っている場合と、特定のテンプレートやエントリグループにロールを直接付与している場合である[3]。対象はメタデータ側（アスペクトタイプとエントリグループ）の権限で、BigQueryのテーブル本体へのアクセス権ではない。列レベルのアクセス制御に使うポリシータグとその分類（タクソノミー）は、廃止の対象外である[3]。

クラウドをまたぐカタログ

GCP「borderless Lakehouse」、脱ETLのマルチクラウド分析基盤

SnowflakeとBigQueryを事業部ごとに使い分け、両者をまたぐデータ統合基盤の刷新を検討している数千人規模企業のデータ基盤担当者は、部門横断の分析を行うたびにETL（Extract-Transform-Load、データを抽出・変[…]

公式の移行手順と、戻せなくなる境目

移行ガイドは作業を2段階に分ける。準備フェーズ（非公開テンプレートの公開化、IAMの設定）の間はData Catalogが正本のままで、アップグレードフェーズ（既定UIの切り替え、アップグレード、プログラム側の更新）で正本がKnowledge Catalogへ移る[3]。この5つの作業に参照箇所の棚卸しと試験を加えると、順番は次のようになる。

1. 非公開タグテンプレートを洗い出し、構造と中身を確かめてから公開に変える[3]。
2. タグやカスタムエントリを読み書きしているクエリ、BI、パイプライン、API・Terraform・gcloudの処理を洗い出す。7で書き換える対象になる。
3. カスタムロールかリソース単位の付与を使っている場合、伝播したアスペクトタイプとエントリグループに権限を付ける。APIではaspectTypes.setIamPolicyとentryGroups.setIamPolicyを使う[3]。権限の対応は公式の対応表にある[7]。
4. 既定のカタログUIをKnowledge Catalogに切り替える。組織単位なら組織管理者が設定する。通常は一方向の操作だが、例外として戻すこともできる[3]。
5. Data Catalog側でテンプレートを新しく作れる場合は、検証用に作ったテンプレートでアップグレードを試す。本番のタグが使っているテンプレートで試すと、上げた時点でそのテンプレートを使う全タグが戻せなくなる[3]。
6. 本番のタグテンプレートとカスタムエントリグループを1つずつアップグレードする。テンプレートを上げるとそれを使う全タグが、エントリグループを上げると配下の全エントリが一緒に上がり、戻せない[3]。
7. API、クライアントライブラリ、Terraform、gcloudの処理を書き換える。タグを書き込む処理はテンプレートの、カスタムエントリを取り込む処理はエントリグループのアップグレードと時期を合わせる[3]。Knowledge CatalogはカスタムエントリとアスペクトのTerraform管理に対応していないため、その部分はマネージド接続のパイプラインかメタデータインポートAPIへ移す[3]。

監査で移行の経緯を説明する組織は、3で付けた権限と、6で上げたテンプレート・エントリグループの一覧を日時とともに残す。Data Catalog上のビジネスグロッサリーは、これとは別に、スクリプトで一括移行する手順が用意されている[8]。

カタログ権限の総点検

Databricks MANAGE権限の仕様変更、既存付与の総点検を

全社のデータ分析基盤としてDatabricksを使い、部門ごとにアクセス権限を細かく分けて運用してきた数千人規模企業のデータガバナンス担当者は、Unity Catalog（Databricksのデータ資産を横断的に管理・統制する仕組み）上[…]

日本語ドキュメントと国内のデータ所在で確かめること

日本語のドキュメントで期限を確かめている組織は、日付を取り違えている可能性がある。非推奨ページの日本語版は、Data CatalogとData Catalog上のビジネスグロッサリーの提供終了日を「2026 年 1 月 30 日」と表示し、製品名もDataplex Universal Catalogのままである[9]。英語版はどちらも2026年6月1日で[1]、1月30日は2025年2月の非推奨発表の時点の日付だ[4]。日本語版を根拠に移行計画や監査資料へ期限を書いていれば、実際より約4か月早い日付が残っている。

移行ガイドも日本語版のほうが古く、英語版にないオプトインの手順が残っている。期限と手順は英語版（URLの末尾に?hl=en）で確かめる。

もう1つは、メタデータの定義が置かれる場所である。Data Catalogのタグテンプレートはリージョン単位のリソースだが、Knowledge Catalogではグローバルなアスペクトタイプとして反映され、定義はすべてのGoogle Cloudリージョンに複製される[3]。タグとテンプレートのリージョンをまたぐ参照を保つための設計である[3]。東京や大阪のリージョンにテンプレートを作り、メタデータを国内に置く前提で運用してきた組織は、テンプレートの定義（フィールドのID・表示名・型、列挙型なら選択肢）[6]に、国外へ出したくない情報がないかを確かめる必要がある。公開テンプレートは自動で反映されるため[3]、対象はこれから公開に変えるテンプレートだけではない。

まとめ

Data Catalogは2026年6月1日から段階的シャットダウンに入っており、どのAPIがいつ止まるかは示されていない[2]。公開設定のタグやカスタムエントリは読み取り専用でKnowledge Catalogに自動で反映されるが、書き込みを移すアップグレードは不可逆で、テンプレートを1つ上げればそれを使う全タグが一緒に移る[3]。IAMの手作業が要るのはカスタムロールかリソース単位の付与を使っている場合で、BigQueryのポリシータグは廃止の対象外である[3]。

手を付ける順番は、非公開テンプレートとリソース単位のIAM付与の一覧を作り、テンプレートごとにタグを書き込んでいる処理を対応づけるところから始まる。その対応表があれば、処理の切り替えとテンプレートのアップグレードを同じ日に1つずつ進められ、戻せない操作の影響をテンプレート1つ分に収められる。

よくある質問（FAQ）

Q. Data Catalogはもう使えなくなっているのか。
A. 2026年6月1日から段階的シャットダウンに入り、Data Catalog APIの中断や完全なアクセス不能が起こり得る状態にある[2]。

Q. Knowledge Catalogへの移行は自動で行われるのか。
A. 読み取り専用で参照できるところまでは自動である。カスタムエントリグループ、エントリ、タグ、公開タグテンプレートは、自動で読み取り専用のリソースとして反映される[3]。非公開テンプレートの公開化、カスタムロールやリソース単位の権限の設定、書き込みを移すアップグレード、API・クライアントライブラリ・Terraform・gcloudの処理の書き換えは利用者の作業になる[3]。ただし準備フェーズを終えるまでは、公開タグテンプレートとタグの一部が検索に出ないことがある[3]。

Q. アップグレード後にData Catalogへ戻せるか。
A. 戻せない。アップグレードは不可逆で、上げたタグテンプレートとエントリグループはData Catalog側で更新できなくなる[3]。Data Catalog側で削除はでき、削除してもKnowledge Catalog側には影響しない[3]。

Q. BigQueryの列レベルのアクセス制御も移行が必要か。
A. 列レベルのアクセス制御に使うポリシータグとその分類は、廃止の対象外である[3]。ただし、Knowledge Catalogの検索では、policytagやpolicytagidの条件でポリシータグを探すことはできない[11]。

出典