インフラ

Dataplexとは?機能・料金・Knowledge Catalog改称を実装目線で解説【2026年版】

Dataplexは、Google Cloud上に散らばったデータを移動させずに一元管理し、メタデータ・データ品質・アクセスポリシーを横断的に扱うデータガバナンス基盤です。BigQueryやCloud Storageに分散したデータへ、統一した検索・分類・品質チェックの仕組みをかぶせられる点が中心的な性格です。この記事では、Dataplexの構成要素(エントリ・アスペクト・レイク)、データディスカバリ・データ品質・リネージといった主要機能、DCU(Data Compute Unit)ベースの料金、そして2026年4月にKnowledge Catalogへ改称された背景まで、実装者がつまずきやすい点を軸に整理します。どの規模の組織で導入価値が出て、どこからは過剰投資になるのかも、条件付きで言い切ります。

まとめ:Dataplexはデータを動かさず統治するGoogle Cloudのガバナンス層

Dataplexの本質は「データを移動せず、その場(in-place)で統治する」点にあります。BigQueryのデータセットやCloud StorageのバケットをDataplexの管理下に登録すると、技術メタデータの自動収集、データ品質スコアの算出、データリネージ(来歴)の追跡、機密情報の分類を一括で回せる点が特徴です。データを別基盤へ移すETLを組む前段として、まず「どこに何があり、誰が使えるか」を揃える役割を担います。

2026年4月10日に、後継である「Dataplex Universal Catalog」はさらに「Knowledge Catalog」へ改称されました。ただしAPI・クライアントライブラリ・CLI・IAMの識別子は据え置きで、コード上は引き続きdataplexとして扱えます。名称が示す方向性は、人が使う「台帳」から、AIエージェントが仕事の前に意味を確認しに来る「辞書」へという役割転換です。導入判断では、BigQuery中心にデータが分散し複数チームでガバナンスが崩れている組織ほど効果が出やすく、単一プロジェクトの数テーブルなら過剰になります。

Dataplexの定義とデータファブリック・データメッシュとの位置づけ

Dataplexは、Google Cloudが提供するインテリジェントなデータファブリックです。データファブリックとは、物理的に分散したデータストアの上に論理的な管理レイヤーをかぶせ、横断的な検索・ガバナンス・品質管理を実現する設計思想を指します。Dataplexはこれをマネージドサービスとして提供し、利用者はインフラ運用を抱え込まずに統治の仕組みだけを手にできます。

データを移動しないin-place管理というDataplexの設計思想

従来のデータ統合は、複数のソースからデータウェアハウスへ集約するETLが主流でした。Dataplexは異なる立場を取り、データをBigQueryやCloud Storageに置いたまま、メタデータとポリシーの層だけを統一します。データセットの実体は動かさないため、大規模データの二重保管コストや移送時間が発生しません。データ基盤全体の考え方についてはデータウェアハウス(DWH)の仕組みと製品比較も併せて押さえておくと、集約型とファブリック型の違いを理解しやすくなります。

データメッシュを支える論理的なデータ統治レイヤーとしての位置づけ

Dataplexはデータメッシュのアーキテクチャと親和します。データメッシュは、データの所有をドメイン(部門)ごとに分散させつつ、全社で統一したガバナンスを効かせる考え方です。Dataplexはドメインごとのデータを論理的な単位でまとめ、共通のポリシーテンプレートやアクセス制御を横断適用できます。データを中央集権的に移さないまま、部門の自律性と全社統制を両立させる土台になります。

Dataplexの構成要素とメタデータモデル(エントリとアスペクト)

Dataplexを設計・実装するうえで最初に理解すべきは、メタデータをどう表現するかというデータモデルです。初期のデータ組織化(レイク・ゾーン・アセット)と、Universal Catalog以降のメタデータ構造(エントリ・アスペクト)は役割が異なります。

レイク・ゾーン・アセットで構成するデータ組織化の3階層の考え方

データ組織化の階層は、上位からレイク(lake)→ゾーン(zone)→アセット(asset)の3層です。レイクは論理的なデータの束、ゾーンはその中の区分(生データ用・整形済み用など)、アセットはGCSバケットやBigQueryデータセットと1対1で紐づく実体への参照です。この階層設定と、アクセスポリシーの適用・伝播そのものは、Google Cloudのドキュメント上でも無料枠として扱われます。課金はこの上で走らせる処理(スキャンやプロファイル)に対して発生します。

エントリとアスペクトで拡張するメタデータモデルの5つの構成要素

Universal Catalog以降のメタデータは、次の要素で構成されます。旧Data Catalogのタグテンプレートは、アスペクトタイプへ引き継がれました。

構成要素 役割 実装上の位置づけ
エントリ(Entry) 個々のデータ資産(例:BigQueryテーブル) カタログ検索・参照の最小単位
アスペクト(Aspect) エントリに付与するメタデータ項目の集合 技術・ビジネス両面の属性を格納
アスペクトタイプ(Aspect Type) アスペクトの再利用テンプレート 旧Data Catalogタグテンプレートの後継
エントリタイプ(Entry Type) 必須メタデータ標準を強制する型 メタデータ品質の標準化に使う
エントリリンク(Entry Link) 資産間の関係(対称/非対称) 資産どうしの依存・派生を表現

この構造により、テーブル名やスキーマといった技術メタデータに加え、「所管部門」「機密区分」「用途」といったビジネスメタデータを一貫した型で載せられます。エントリタイプで必須項目を縛れば、カタログの空欄放置を仕組みで防げます。

Dataplexがメタデータを収集できる対応データソースの範囲

Dataplexは、Google Cloud内の広い範囲からメタデータを自動収集します。対応ソースはBigQuery、Dataform、Dataproc Metastore、Vertex AIのモデル・データセット、Cloud SQL、AlloyDB、Cloud Spanner、Bigtable、Pub/Subなどにおよび、Looker連携はプレビュー扱い(2026年時点)です。機械学習の特徴量まで見通したい場合は、Vertex AI Feature Storeの仕組みと2026年の改称情報を押さえておくと、モデル資産とデータ資産をまたいだ統治像を描きやすくなります。

Dataplexの主要機能:ディスカバリ・品質・リネージ・プロファイル

Dataplexの価値は、登録した資産に対して回せる4系統の自動処理に集約されます。いずれも設定した範囲とスケジュールで走り、課金もここに紐づきます。

データディスカバリと自然言語によるセマンティック検索の仕組み

ディスカバリスキャンは、Cloud Storage上のファイル(PDF等の非構造化データを含む)やテーブルを走査し、スキーマやパーティション構造を推定してエントリ化します。加えて、AIを用いた自然言語のセマンティック検索により、「顧客の購買履歴が入っているテーブル」といった意図ベースの検索が、事前のメタデータ整備なしでも成立しやすくなります。手作業のカタログ登録に依存しない探索は、実務の初速を上げる要素です。

データ品質スキャンとデータプロファイリングによる品質の可視化

データ品質(DQ)スキャンは、NULL率・一意性・値域といったルールを定義し、テーブルごとに品質スコアを算出します。データプロファイリングは、列単位で最小・最大・分布・カーディナリティなどの統計を自動で抽出する機能です。両者を定期実行すれば、下流の分析やモデル学習に流す前の段階で、劣化したデータを検知できます。ルールはテンプレート化して複数テーブルへ展開できるため、品質チェックの属人化を避けられます。

データリネージによるデータ来歴の可視化とPIIの流れの自動追跡

データリネージは、あるテーブルがどのソースから、どの変換を経て生成されたかを自動でグラフ化します。個人情報(PII)を含む機密データが、どの資産へ流れ、どこで変換されたかを追える点は、コンプライアンス対応で効く部分です。障害時の影響範囲特定にも使え、「この元テーブルを止めると、どのダッシュボードが壊れるか」を事前に把握できます。BigQueryやDataformの処理は自動でリネージに反映されます。

ビジネスグロッサリとデータプロダクトによる用語と提供の標準化

ビジネスグロッサリは、社内用語(例:「有効顧客」の定義)を辞書化し、エントリに紐づけます。用語の解釈揺れが、指標の食い違いを生む現場では、この統一が効果を発揮します。データプロダクトは、統治されたデータを「利用可能な製品」として束ね、提供側と利用側の契約を明確にする、管理から提供へと運用の重心を移す考え方です。

Dataplexの料金体系とDCU従量課金・無料になる範囲の整理

Dataplex(Knowledge Catalog)の課金は、pay-as-you-goの従量制です。設計段階で「何が無料で、何が課金対象か」を切り分けておかないと、想定外の請求につながります。

DCU(Data Compute Unit)で計量される処理

スキャンやプロファイルなどの処理は、DCU(Data Compute Unit)で計量され、standardとpremiumの処理ティアで単価が分かれます。一方、データ組織化(レイク・ゾーン・アセットのセットアップ)と、セキュリティポリシーの適用・伝播は、ドキュメント上で無料として案内されています。つまり「箱を作り、権限を配る」ところまでは費用がかからず、「中身を走査・分析する」処理から課金が始まる構造です。

DCU課金が膨らむ典型パターンとスキャン範囲の絞り込みの勘所

費用が読めなくなる代表例は、全バケット・全テーブルへディスカバリスキャンやプロファイルをフルスキャン設定し、高頻度スケジュールで回してしまうケースです。DCU消費はスキャン対象量と頻度に比例するため、初期はスコープを主要データセットへ絞り、スキャン間隔を実運用に足る最小頻度から始めるのが安全です。品質ルールも、まず優先度の高い列に限定し、効果を見て拡張する順序を推奨します。

2026年のKnowledge Catalog改称とエージェント時代のコンテキスト基盤

Dataplexは名称を段階的に変えてきました。単体サービスのDataplexが、Data Catalogを統合して「Dataplex Universal Catalog」となり、2026年4月10日に「Knowledge Catalog」へ改称されました。改称後もAPI・CLI・IAMの識別子は変わらず、既存の実装やData Catalogから移行した資産(カスタムエントリ・グロッサリ・エントリグループ)はそのまま参照できます。

台帳から辞書へ:AIエージェントへ共有コンテキストを提供する基盤

改称が示すのは、役割の転換です。従来の「社内データがどこに何があるかを一覧する帳簿」から、「AIエージェントが仕事の前にデータの意味を確認しに来る辞書」への進化です。Context APIとMCP(Model Context Protocol)ツールが実装され、Google純正エージェントだけでなく自作エージェントからも、同じセマンティクスへアクセスできます。組織で統一した定義に基づくエージェント運用の土台となる仕組みです。関連する知識フォーマットの標準化については、Google Cloudが2026年6月に公開したOpen Knowledge Format(OKF)と併読すると、カタログとエージェントの接続像が具体化します。

実運用での効果:Bloomberg Mediaのエージェント事例

公開事例では、Bloomberg MediaがKnowledge Gap Agent(KGA)を構築し、エージェントの誤答から得た組織知をカタログへ自動で書き戻すループを実装しました。この設計でSQL精度が63%向上し、20テーブルで102件のusage noteが自動生成されたと報告されています。カタログを人手で埋める運用から、エージェントの利用実態がカタログを育てる運用へと反転させた点が特徴です。三大クラウドのどの基盤で同種の統治を組むか迷う段階なら、AWS・Google Cloud・Azureの特徴と使い分けから入ると判断材料が揃います。

Dataplexを採用すべき企業と過剰投資で見送るべき場面の判断

Dataplexは万能ではありません。導入効果は、データの分散度・チーム数・コンプライアンス要件で大きく変わります。ここでは条件付きで判断を示します。

Dataplexの採用価値が高い組織とデータ分散の条件パターン

次のいずれかに当てはまる組織は、導入価値が高いと判断できます。BigQueryを中心にデータが複数プロジェクト・複数チームへ分散し、誰がどのデータを使えるかが把握しきれていない状態。PIIを含むデータの来歴を監査で説明する義務がある状態。部門ごとにデータを持たせつつ全社統制を効かせるデータメッシュを志向する状態。これらでは、in-place統治とリネージ自動化の効果が、DCU課金を上回りやすくなります。

Dataplexを見送るべき場面と過剰投資になる失敗パターン

逆に、次の場合は見送りか、機能を絞った限定導入にとどめるのが妥当です。データが単一BigQueryプロジェクトのわずかなテーブルにとどまるならDataplexの統治レイヤーは過剰で、BigQuery標準のIAMと情報スキーマで足ります。データの大半がGoogle Cloud外(オンプレミスや他クラウド)にあるなら、メタデータ収集の対象が薄く旨味が出にくい構成です。DCU課金の見積もりが立たないうちに全社フルスキャンから始めるのは、費用対効果を測る前にコストだけが先行する失敗パターンで、避けるべきです。まずは1ドメイン・主要データセットで効果を検証し、段階拡張する導入設計を推奨します。Google Cloudでのデータ基盤設計やガバナンス整備を外部と進めたい場合は、Google Cloudを含むインフラ構築・データ基盤の相談窓口で構成案から検討できます。

よくある質問

Dataplex(現Knowledge Catalog)について、実装・導入検討で頻出する質問に答えます。

DataplexとData Catalogの違いは何ですか?

Data Catalogは単体のメタデータ管理サービスでしたが、Dataplex Universal Catalog(現Knowledge Catalog)へ統合されました。現在はData Catalogのカスタムエントリ・グロッサリ・エントリグループがKnowledge Catalog側で参照でき、旧タグテンプレートはアスペクトタイプへ引き継がれています。新規に始めるならKnowledge Catalog側の構成要素で設計します。

Dataplexは無料で使えますか?

データ組織化(レイク・ゾーン・アセットの構成)と、セキュリティポリシーの適用・伝播は無料枠として案内されています。一方、データディスカバリ・データ品質スキャン・データプロファイリングなどの処理はDCU(Data Compute Unit)ベースの従量課金です。無料の範囲で箱と権限を整え、走らせる処理から費用が発生すると理解すると見積もりを立てやすくなります。

DataplexとBigQueryはどう連携しますか?

DataplexはBigQueryのデータセットをアセットとして登録し、テーブルの技術メタデータを自動収集します。データはBigQueryに置いたまま管理するin-place方式のため、移送は発生しません。BigQuery上の変換はデータリネージへ自動反映され、品質スキャンもBigQueryテーブルに対して直接実行できます。

Knowledge Catalogへの改称で既存の実装は影響を受けますか?

2026年4月10日の改称後も、API・クライアントライブラリ・CLI・IAMの識別子は据え置きです。コード上は引き続きdataplexとして扱えるため、名称変更に伴うプログラム改修は基本的に発生しません。変わったのは呼称と、AIエージェント向けコンテキスト基盤という役割の打ち出し方です。

データメッシュとDataplexはどう関係しますか?

データメッシュは、データ所有を部門ごとに分散させつつ全社ガバナンスを効かせる考え方です。Dataplexはデータを移動させないまま論理的な単位でまとめ、共通ポリシーを横断適用できるため、データメッシュの統治レイヤーとして機能します。部門の自律性と全社統制の両立を、基盤側から支えます。

関連記事

資料請求

RELATED POSTS 関連記事