公開2026.07.27更新2026.10.24 Google Cloud

Knowledge Catalog（旧Dataplex）とは：機能・料金・自己学習型コンテキスト強化とgcloud手順を実装目線で解説【2026年版】

Dataplexは、Google Cloud上に散らばったデータを移動させずに一元管理し、メタデータ・データ品質・アクセスポリシーを横断的に扱うデータガバナンス基盤です。BigQueryやCloud Storageに分散したデータへ、統一した検索・分類・品質チェックの仕組みをかぶせられる点が中心的な性格といえます。この記事では、Dataplexの構成要素（エントリ・アスペクト・レイク）、データディスカバリ・データ品質・リネージといった主要機能、DCU（Data Compute Unit）ベースの料金、2026年4月にKnowledge Catalogへ改称された背景を整理します。あわせて、gcloudでカタログを検索し、YAMLで書いた品質ルールをスキャンとして実行するところまで、コピーして動かせる形で示しました。どの規模の組織で導入価値が出て、どこからは過剰投資になるのかも、条件付きで言い切ります。2026年10月22日にプレビューとして発表された自己学習型コンテキスト強化とKnowledge Studioについても、仕組み・承認の流れ・プレビュー段階の制約・エージェントから読む方法を追記しました。

まとめ：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中心にデータが分散し複数チームでガバナンスが崩れている組織ほど効果が出やすく、単一プロジェクトの数テーブルなら過剰になります。

2026年10月22日には、Knowledge Catalogに自己学習型コンテキスト強化（self-learning context enrichment）がプレビューで加わりました。エージェントと利用者の対話記録から定義の欠落や古い説明を見つけ、テーブルの説明・結合関係・ゴールデンクエリの修正案を出す機能です。提案はデータスチュワードの承認を経て公開される設計で、プレビュー中はCMEKやVPC Service Controlsに対応していません。規制データを扱う本番環境では一般提供を待ち、検証用のプロジェクトで精度を測るところから始めるのが妥当です。

費用面では、標準処理に月100DCU時間の無料枠があり、レイク・ゾーン・アセットの構成と権限の伝播は無料です。課金が本格化するのはリネージ・データ品質・プロファイリングといったプレミアム処理で、ここを主要テーブルに絞れば小さく始められます。

Dataplexとは何か：データファブリック・データメッシュとの位置づけ

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

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

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

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

Dataplexはデータメッシュのアーキテクチャと親和します。データメッシュは、データの所有をドメイン（部門）ごとに分散させつつ、全社で統一したガバナンスを効かせる考え方で、設計原則はデータメッシュとは？4原則とデータプロダクトの設計、データレイク・ファブリックとの違いにまとめています。Dataplexはドメインごとのデータを論理的な単位でまとめ、共通のポリシーテンプレートやアクセス制御を横断適用できる設計です。2026年9月7日には、企業内のリソースを論理的に束ねる「データドメイン」がプレビューで加わりました。データを中央集権的に移さないまま、部門の自律性と全社統制を両立させる土台になります。

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

Dataplexを設計・実装するうえで最初に理解すべきは、メタデータをどう表現するかというデータモデルです。初期のデータ組織化（レイク・ゾーン・アセット）と、Universal Catalog以降のメタデータ構造（エントリ・アスペクト）は役割が異なります。そもそもデータカタログが何を解決する道具なのかを先に押さえたい場合は、データカタログの意味とメタデータ管理の仕組みから読むと、以降の用語が頭に入りやすくなります。

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

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

エントリとアスペクトで拡張するメタデータモデルの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年時点）です。2026年9月には、dbt Cloudのジョブ実行からメタデータを取り込む機能がGAとなり、BigQuery Graphのメタデータ自動取り込みもプレビューで始まっています（いずれもリリースノートの9月分に記載）。機械学習の特徴量まで見通したい場合は、Vertex AI Feature Storeの仕組みと2026年の改称情報を押さえておくと、モデル資産とデータ資産をまたいだ統治像を描きやすくなります。

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

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

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

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

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

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

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

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

データリネージの公式解説によると、Data Lineage API（datalineage.googleapis.com）を有効にすると、BigQueryのコピー・ロード・クエリジョブ、Dataflow、Cloud Data Fusion、Managed Airflow、Vertex AI Pipelinesなどが自動でリネージを報告します。注意したいのは保持期間で、リネージ情報はシステム上に30日間しか残りません。監査で1年分の来歴を示す必要があるなら、定期的に別テーブルへ書き出す設計を最初から組み込んでおきます。

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

ビジネスグロッサリは、社内用語（例：「有効顧客」の定義）を辞書化し、エントリに紐づける機能です。用語の解釈揺れが、指標の食い違いを生む現場では、この統一が効果を発揮します。データプロダクトは、統治されたデータを「利用可能な製品」として束ね、提供側と利用側の契約を明確にする考え方で、管理から提供へと運用の重心を移すものといえます。2026年10月5日には、データプロダクトにLooker (Google Cloud core) のダッシュボード・Explore・LookMLモデルなどを含められるようになり、一般提供（GA）としてリリースノートに載りました。BIの成果物までデータプロダクトとして束ねられるため、指標の定義と表示先を同じ単位で配れます。用語の定義をBIツールの外で一元化する考え方は、セマンティックレイヤーの仕組みと会話型AI時代の導入判断で比べています。

gcloudでDataplexのAPIを有効化しカタログ検索を試す手順

概念を押さえたら、手元のプロジェクトで実際に触ってみるのが理解の近道です。ここではCloud ShellかgcloudをインストールしたPCを前提に、APIの有効化からカタログ検索までを最短で通します。BigQueryにテーブルが1つでもあれば、技術メタデータは自動で取り込まれているため、事前の登録作業は要りません。BigQuery自体の仕組みはBigQueryの仕組み・料金・できないことで整理しています。

必要なAPIの有効化とサービスアカウントへのロール付与を済ませる

カタログと品質スキャンにはDataplex API、リネージにはData Lineage APIを使います。品質スキャンはKnowledge Catalogのサービスアカウントが対象テーブルを読むため、データ品質スキャンの公式手順に沿ってBigQueryの閲覧ロールを付けておきます。

# プロジェクトを指定してAPIを有効化する
gcloud config set project PROJECT_ID
gcloud services enable dataplex.googleapis.com datalineage.googleapis.com

# プロジェクト番号を取得し、サービスアカウントへBigQuery閲覧ロールを付与する
PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-dataplex.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataViewer"

結果をBigQueryのテーブルへ書き出す場合は、書き出し先データセットに対してroles/bigquery.dataEditorも必要になります。Cloud Storage上の外部テーブルを対象にするならroles/storage.objectViewerを加えます。

gcloudのentries searchとREST APIでテーブルを探す

検索はgcloudのentries searchコマンドか、searchEntriesメソッドで行えます。検索の公式ドキュメントでは、semantic-searchフラグを付けた自然言語検索の例が示されています。

# 自然言語でエントリを検索する（セマンティック検索）
gcloud dataplex entries search "注文と顧客の履歴が入ったテーブル" \
  --project=PROJECT_ID \
  --semantic-search

# 同じ検索をREST APIで呼ぶ（LOCATIONは global や us-central1 など）
curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION:searchEntries?query=orders&semanticSearch=true"

自作のエージェントやバッチからカタログを引くときは、REST版を使うと認証と結果の扱いを既存コードに合わせやすくなります。検索で目的のテーブルが上位に出ない場合は、説明文やアスペクトが空のままになっている可能性が高いと考えてください。

YAMLでデータ品質ルールを定義しgcloudでスキャンを実行する

データ品質スキャンは、ルールを書いた仕様ファイルを用意し、gcloudでスキャンを作って走らせる流れです。コンソールでも同じことができますが、ファイルで管理すればレビューと再現がしやすく、TerraformやCIに載せる前段にもなります。

NULL・一意性・値域の3ルールを書いたデータ品質仕様ファイルの例

次のYAMLは、公式手順の例をもとに、取引IDの一意性・金額の非NULL・割引率の値域を検査する仕様です。samplingPercentで対象行を半分に絞っており、スキャン量を抑えたい初期導入でそのまま使えます。

# dq-spec.yaml：データ品質スキャンの仕様ファイル
rules:
  - uniquenessExpectation: {}
    column: transaction_id
  - nonNullExpectation: {}
    column: amount
    threshold: 1
  - rangeExpectation:
      minValue: '0'
      maxValue: '100'
    column: discount_pct
samplingPercent: 50

thresholdは合格とみなす行の割合で、1は全行が条件を満たす必要があることを意味します。特定期間の行だけを見たいときは、rowFilterにSQLのWHERE句と同じ書式で条件を足せます。

datascans createとrunでスキャンを作り結果を確認する

仕様ファイルができたら、gcloud dataplex datascans create data-quality のリファレンスに沿って、対象テーブルをリソース名で指定します。scheduleにcron式を渡せば定期実行、付けなければ手動実行のスキャンになります。

# スキャンを作成する（毎日3時に定期実行）
gcloud dataplex datascans create data-quality orders-dq \
  --project=PROJECT_ID \
  --location=asia-northeast1 \
  --data-source-resource="//bigquery.googleapis.com/projects/PROJECT_ID/datasets/sales/tables/orders" \
  --data-quality-spec-file=dq-spec.yaml \
  --schedule="0 3 * * *"

# 待たずに1回走らせる
gcloud dataplex datascans run orders-dq --location=asia-northeast1

# ジョブ一覧からJOB_IDを取り、ルールごとの合否を表示する
gcloud dataplex datascans jobs list --datascan=orders-dq --location=asia-northeast1
gcloud dataplex datascans jobs describe JOB_ID \
  --datascan=orders-dq --location=asia-northeast1 --view=FULL

jobs describeにview=FULLを付けると、ルール単位の合格・不合格と通過率が返ります。この出力をBigQueryへ書き出しておけば、品質スコアの推移をダッシュボードで追えます。

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

Dataplex（Knowledge Catalog）の課金は、pay-as-you-goの従量制です。設計段階で「何が無料で、何が課金対象か」を切り分けておかないと、想定外の請求につながります。以下の数値は2026年9月時点で公式の料金ページに掲載されている内容です。

DCU（Data Compute Unit）で計量される標準処理とプレミアム処理

スキャンやプロファイルなどの処理は、DCU（Data Compute Unit）で計量され、standardとpremiumの処理ティアで単価が分かれます。標準処理はデータディスカバリを、プレミアム処理はデータリネージ・データ品質・データプロファイリングを受け持つ区分です。料金ページの計算例では1DCU時間あたり0.089ドル、メタデータストレージは1GiBあたり月2.00ドルで試算されています。

区分	対象	無料の範囲
データ組織化	レイク・ゾーン・アセット	無料
ポリシー適用・伝播	アクセス権の配布	無料
標準処理	データディスカバリ	月100DCU時間まで無料
プレミアム処理	リネージ・品質・プロファイル	無料枠なし
メタデータ保管	カスタムのメタデータ	自動取り込み分は無料

つまり「箱を作り、権限を配る」ところまでは費用がかからず、「中身を走査・分析する」処理から課金が始まる構造です。BigQueryなどから自動で取り込まれる技術メタデータの保管も無料と明記されています。

BigQueryやDataflow側の請求として現れる処理に気をつける

見落としやすいのが、Dataplexの明細に出てこない費用です。料金ページによると、ディスカバリスキャン、定期のデータ品質・取り込みタスク、Cloud SQLやLookerのマネージドコネクタは、裏でCloud Storage・BigQuery・Dataflow・Cloud Schedulerなどのジョブを起動します。これらはそれぞれのサービスの料金として請求されるため、Dataplexの請求額だけを見て安いと判断すると実態を読み違えます。予算アラートはプロジェクト全体に掛けておくのが安全です。

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

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

Knowledge Catalogへの改称とData Catalog段階停止への対応

Dataplexは名称を段階的に変えてきました。単体サービスのDataplexが、Data Catalogを統合して「Dataplex Universal Catalog」となり、2026年4月10日に「Knowledge Catalog」へ改称されています。改称後もAPI・CLI・IAMの識別子は変わらず、既存の実装やData Catalogから移行した資産（カスタムエントリ・グロッサリ・エントリグループ）はそのまま参照できます。ドキュメントのURLも dataplex から knowledge-catalog のパスへ移りましたが、旧URLは新URLへ転送される状態です（2026年9月時点）。

Data Catalogの段階停止と移行先リソースの対応関係を押さえる

リリースノートには、2026年6月1日からData Catalogが段階的な停止に入り、APIが中断または利用不能になる可能性があると記されています。まだData CatalogのAPIを呼んでいるコードがあれば、優先して置き換える対象です。対応関係は移行ガイドに次のとおり示されています。

Data Catalog	Knowledge Catalog
タグテンプレート	アスペクトタイプ（グローバル）
タグ	オプションのアスペクト
エントリグループ	エントリグループ
カスタムエントリ	汎用エントリタイプのエントリ

Data Catalogのタグテンプレートはリージョン単位のリソースでしたが、Knowledge Catalog側ではグローバルなアスペクトタイプとして見えるようになります。タグを書き込むバッチを持っている場合は、書き込み先をアスペクトへ移し、読み取り側のクエリも同時に切り替える計画を立ててください。

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

改称が示すのは、役割の転換です。従来の「社内データがどこに何があるかを一覧する帳簿」から、「AIエージェントが仕事の前にデータの意味を確認しに来る辞書」への移行を意味します。2026年6月4日にはエージェント向けに整形済みのコンテキストを返すlookupContextメソッドがプレビューで加わり、5月27日にはデータリネージのリモートMCP（Model Context Protocol）サーバーもプレビュー提供が始まりました。Google純正エージェントだけでなく自作エージェントからも、同じセマンティクスへアクセスできます。関連する知識フォーマットの標準化については、Google Cloudが2026年6月に公開したOpen Knowledge Format（OKF）と併読すると、カタログとエージェントの接続像が具体化します。この方向は、10月22日の自己学習型コンテキスト強化で一段進みました。辞書の中身を人手だけで書き足すのではなく、エージェントの使われ方から書き直す段階に入っています（次章で詳しく扱います）。

実運用での効果：Bloomberg MediaのData Access AI Agent

2026年4月23日のKnowledge Catalog紹介の公式ブログでは、Bloomberg MediaのCTOが、全社のメタデータとビジネス文脈をKnowledge Catalogに集約したうえで社内向けの「Data Access AI Agent」を立ち上げたと述べています。利用者はデータレイクを直感的に探索でき、複雑な業務上の問いをAIが即座に文章で答える形にしたという内容です。ブログは精度の改善幅といった数値までは示していないため、効果を見積もる際は自社のPoCで回答の正答率を測る前提で計画します。三大クラウドのどの基盤で同種の統治を組むか迷う段階なら、AWS・Google Cloud・Azureの特徴と使い分けから入ると判断材料が揃います。

自己学習型コンテキスト強化でKnowledge Catalogの定義を育てる手順

2026年10月22日のGoogle Cloud公式ブログで、自己学習型コンテキスト強化と、作り直されたKnowledge Studioがプレビューとして発表されました。ブログによると、利用できる顧客は今後数週間で順次広がる予定です。前章で触れた「台帳から辞書へ」の転換を、人手の整備だけに頼らず回すための仕組みと位置づけられます。ここでは、仕組み・承認の流れ・プレビュー段階の制約・エージェント側から読む方法の順に整理します。

対話トレースから定義の欠落を拾う自己学習型コンテキスト強化の仕組み

従来のKnowledge Catalogにも、Geminiでテーブルや列の説明文を生成するエンリッチメント機能がありました。今回の自己学習型は、それを「使われ方から学ぶ」方向へ広げたものです。ブログで説明されている処理は、次の5段階に分けて読めます。

段階	処理の中身
接続	構造化データと非構造化データの両方へつなぐ
抽出	手順書や業務文書から定義を拾い、表と結び付ける
提案	説明文・結合関係・ゴールデンクエリの案を出す
変化の検知	実行ごとに古い定義を外し、矛盾をレビューへ回す
対話からの学習	エージェントの対話記録から欠落を見つけて直す

非構造化データの取り込み元として、ブログはCloud Storage・Google Workspace・GitHub・Confluence・SharePointを挙げています。提案される内容は、業務上の定義、テーブルと列の説明、結合関係、ゴールデンクエリ、タスク別のエージェント向け指示で、どの提案にも根拠となったソースの引用と信頼度スコアが付きます。

「自己学習」の中心は最後の段階です。BigQueryの会話型分析や、Geminiエージェント・自作エージェントの対話トレースを分析し、曖昧な列の参照、根拠のない指標、定義の欠落、利用者が同じ質問を言い換えている状況といった兆候を拾います。そのうえで正しい答えの出どころを探し、修正案を作る流れです。トレース内の個人情報はマスキングでき、顧客データをモデルの学習に使わないこともブログに明記されています。BigQuery側のデータエージェントの構成はBigQuery Conversational Analyticsのデータエージェントの構成と回答精度で扱っており、そこで回答精度を左右するとしたコンテキスト整備を、カタログ側で半自動にする機能と読むと関係がつかめます。

ブログには、エージェントの精度が約4倍、レイテンシが最大33%減、トークン使用量が最大75%減という数値が載っています。ただしこれはGoogleの社内ベンチマークで、名前の付いた顧客事例は示されていません。自社の質問セットで正答率とトークン量を測ってから効果を見積もる前提で扱います。

コンテキストセットと変更リクエストで提案を承認してから公開する

Knowledge Studioの公式ドキュメント（2026年10月22日更新）によると、画面は「New chat」「Context sets」「Enrichments」の3つで構成されます。New chatは自然言語でデータを探り、コンテキストグラフをたどる画面、Context setsはコンテキストセットの作成と管理、Enrichmentsはメタデータ生成の自動化・評価用ベンチマークの設定・変更リクエストのレビューを受け持ちます。

コンテキストセットは、意味情報とデータ資産への参照を束ねた、範囲の決まった入れ物です。実体はtypeがcontext-setのエントリグループで、前述のエントリとアスペクトのモデルの上に載っています。エージェントがカタログ全体を際限なく検索するのを防ぎ、ハルシネーションとトークン消費を減らすのが狙いです。注意点として、リージョンの資産を束ねるグローバルなコンテキストセットは作れず、束ねる資産のリージョン境界に合わせる必要があります。Open Knowledge Format（OKF）のバンドルをコンテキストセットとして取り込み、OKFとして書き出すこともできるとブログは説明しています。

自動化の単位は、ドキュメント上で次の3つに分かれています。

用語	意味
エンリッチメントタスク	対象のセット・入力元・評価基準を決めた設定
エンリッチメントジョブ	タスクを動かす裏側の処理
エンリッチメントラン	ある時点の1回の実行。変更リクエストを生む

ランが生成した提案は、変更リクエストとしてデータスチュワードがレビューします。ブログによると、自動公開のオンとオフはいつでも切り替えられ、信頼度85%以上は自動承認するといったしきい値も設定できます。しきい値を下回る提案や、削除のような影響の大きい変更は変更リクエストに回り、承認・編集・却下の判断を待つ仕組みです。独自の評価セットで更新をエンドツーエンドに試せ、すべての変更は出どころとともに記録され、元に戻せます。導入初期は自動公開を切り、変更リクエストを全件レビューして提案の傾向をつかんでから、しきい値を上げ下げする運用が安全です。エージェントへ渡す文脈そのものを設計対象にする考え方は、コンテキストエンジニアリングとプロンプトエンジニアリングの違いと4つの実装手法で整理しています。

プレビュー段階の制約：gcloud未対応・CMEK非対応と課金の見え方

Knowledge Studioはゲート付きのプレビューで、コンテキストグラフの表示、コンテキストセットの作成、エンリッチメントの実行には、組織単位で利用許可を申請する必要があります。プレビュー中の管理はコンソールが中心で、タスク管理用のREST APIとgcloudコマンドは提供されていません。品質スキャンのようにコードで構成を管理したいチームは、この点を前提に計画を立てます。

本番投入の判断で見落とせないのが、セキュリティとコンプライアンスの制約です。ドキュメントには、プレビュー段階では次の項目に対応しないと書かれています（2026年10月時点）。

Assured Workloadsの規制（FedRAMP・CJIS・IL4／IL5・HIPAA）
データ所在地（データレジデンシー）の保証
顧客管理の暗号鍵（CMEK）。暗号化はGoogle管理の鍵で行われる
VPC Service Controls
Access Transparencyのログへの記録

エンリッチメントタスクは利用者が管理するサービスアカウントで動き、Dataplexのサービスエージェントがそのアカウントになりすますために、サービスアカウントトークン作成者のロールを使います。準備は次のように進めます。

# エンリッチメントを実行させるサービスアカウントを作る
gcloud iam service-accounts create kc-enrichment --project=PROJECT_ID

# Dataplexのサービスエージェントに、このアカウントを偽装する権限を与える
PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
gcloud iam service-accounts add-iam-policy-binding \
  kc-enrichment@PROJECT_ID.iam.gserviceaccount.com \
  --member="serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-dataplex.iam.gserviceaccount.com" \
  --role="roles/iam.serviceAccountTokenCreator"

対象資産を読むためにこのアカウントへ付けるロールは、ドキュメントの前提条件のページで確認してから付与します。課金面では、Knowledge Studio専用のSKUはなく、Gemini Reasoning Engine・BigQuery・Cloud Storageなど裏で使うリソースの料金として請求されます。前述のDCU課金と同じく、Knowledge Catalogの明細だけを見ていると費用を読み違える構造です。Knowledge Studioではタスクごとのスケジュール・結果・トークン使用量・実行時間を追えるため、試験運用ではこの値を週単位で記録しておくと、本番の費用見積もりに使えます。

エージェント側はListEntriesとLookupEntryでコンテキストセットを読む

整備したコンテキストセットを使う側の入口は、カタログの既存APIです。ドキュメントによると、下流のエージェントはListEntriesとLookupEntryのCatalog API、またはMCPでコンテキストセットを照会でき、LangChainやADKから使う例も示されています。タスク管理はコンソール中心でも、読み出しは従来のAPIで書けるということです。ListEntriesはgcloud dataplex entries listから、LookupEntryはlookupEntryのRESTリファレンスにあるGETリクエストで呼べます。

# コンテキストセット（エントリグループ）に含まれるエントリを一覧する
gcloud dataplex entries list \
  --project=PROJECT_ID \
  --location=LOCATION \
  --entry-group=CONTEXT_SET_ID

# 1件のエントリを、付与済みのアスペクトを含めて取得する
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION:lookupEntry?entry=projects/PROJECT_ID/locations/LOCATION/entryGroups/CONTEXT_SET_ID/entries/ENTRY_ID&view=FULL"

自作エージェントに組み込むなら、質問を受けたらまず該当するコンテキストセットのエントリを引き、説明文・結合関係・ゴールデンクエリをプロンプトへ渡してからSQLを生成させる順序にします。カタログ全体を検索させるより対象が絞られるため、トークン量と取り違えを減らしやすくなります。自己学習の提案が承認されると、同じ呼び出しで新しい定義が返るようになり、エージェント側のコードを書き換えずに回答の質を上げられる点が、この構成の利点です。

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

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

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

次のいずれかに当てはまる組織は、導入価値が高いと判断できます。BigQueryを中心にデータが複数プロジェクト・複数チームへ分散し、誰がどのデータを使えるかが把握しきれていない状態。PIIを含むデータの来歴を監査で説明する義務がある状態。部門ごとにデータを持たせつつ全社統制を効かせるデータメッシュを志向する状態。これらでは、in-place統治とリネージ自動化の効果が、DCU課金を上回りやすくなります。社内のAIエージェントにBigQueryを引かせる計画がある組織も、カタログの説明文とグロッサリが回答精度を左右するため、先に整備しておく価値があるケースです。すでに会話型分析や自作エージェントを社内で動かしていて、対話トレースが溜まっている組織は、自己学習型コンテキスト強化の効果が出やすい条件にも当てはまります。

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

逆に、次の場合は見送りか、機能を絞った限定導入にとどめるのが妥当です。データが単一BigQueryプロジェクトのわずかなテーブルにとどまるならDataplexの統治レイヤーは過剰で、BigQuery標準のIAMと情報スキーマで足ります。データの大半がGoogle Cloud外（オンプレミスや他クラウド）にあるなら、メタデータ収集の対象が薄く旨味が出にくくなります。その場合はOSSのメタデータ基盤DataHubの構成と採用判断のように、クラウドをまたいで取り込めるカタログを比べる方が筋がよく、AWS中心ならAWS Lake Formationの権限管理と料金が対になる選択肢です。DCU課金の見積もりが立たないうちに全社フルスキャンから始めるのは、費用対効果を測る前にコストだけが先行する失敗パターンで、避けるべきです。まずは1ドメイン・主要データセットで効果を検証し、段階拡張する導入設計を推奨します。自己学習型コンテキスト強化については、CMEK・VPC Service Controls・データ所在地の保証を要件に含む環境では、プレビューの間は本番データへ向けないと決めておく方針です。エージェントをまだ動かしていない組織も、学習の材料になる対話トレースが無いため、先に説明文とグロッサリを人手で整えるほうが成果につながります。

BigQueryを軸にしたデータ分析基盤の設計と、カタログ・品質ルール・リネージの整備を外部と進めたい場合は、データ分析基盤構築・MLOps構築支援で現状の棚卸しから相談できます。Google Cloudのプロジェクト構成やネットワークから見直すなら、Google Cloudを含むインフラ構築・データ基盤の相談窓口で構成案から検討できます。

よくある質問

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

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

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

Dataplexは無料で使えますか？

データ組織化（レイク・ゾーン・アセットの構成）と、セキュリティポリシーの適用・伝播は無料と案内されています。データディスカバリを受け持つ標準処理には月100DCU時間の無料枠があり、一方でデータ品質スキャン・データプロファイリング・リネージのプレミアム処理は無料枠のない従量課金です。無料の範囲で箱と権限を整え、走らせる処理から費用が発生すると理解すると見積もりを立てやすくなります。

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

BigQueryのテーブルの技術メタデータは自動でカタログに取り込まれ、データはBigQueryに置いたまま管理するin-place方式のため移送は発生しません。BigQuery上の変換はData Lineage APIを有効にするとリネージへ自動反映され、品質スキャンもBigQueryテーブルをリソース名で指定して直接実行できます。

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

2026年4月10日の改称後も、API・クライアントライブラリ・CLI・IAMの識別子は据え置きです。gcloud dataplexコマンドやdataplex.googleapis.comのエンドポイントはそのまま使えるため、名称変更に伴うプログラム改修は基本的に発生しません。影響が出るのは、段階停止に入ったData CatalogのAPIを直接呼んでいるコードのほうです。2026年10月にプレビューで加わった自己学習型コンテキスト強化も、エージェントからはListEntriesやLookupEntryといった既存のAPIで読む形のため、呼び出し側の改修は小さく済みます。

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

データメッシュは、データ所有を部門ごとに分散させつつ全社ガバナンスを効かせる考え方です。Dataplexはデータを移動させないまま論理的な単位でまとめ、共通ポリシーを横断適用できるため、データメッシュの統治レイヤーとして機能します。2026年9月にプレビューで加わったデータドメインを使えば、部門単位の区切りをカタログ上でも表現できます。