この記事は Google Cloud Japan Advent Calendar 2025の4日目の記事です。
はじめに
こんにちは。Google CloudカスタマーエンジニアのSoheiです。
2025年の秋、Dataplex Universal Catalog (以下Dataplex) でも複数の機能アップデートがありました。その中から「データエージェントのためのメタデータカタログ」実現に関する機能をご紹介致します。
※「データエージェント」というのは、ここでは「BigQueryを操作するAIエージェント」くらいの意味です
データ分析者（人間）にとってテーブルや列の説明といったメタデータが大切なように、データエージェントにとってもメタデータは大切です。質の高いデータエージェントを実現するためには、質の高いメタデータが必要です。
本記事を読んで、「データエージェントのためのメタデータカタログ」とはどういうものか、より具体的なイメージを持って頂ければ幸いです。
アップデートその１：「データ分析情報の生成」がAPIから実行可能に
BigQueryとDataplexの連携機能「データ分析情報の生成」がAPIから実行可能となりました。具体的には、Dataplex のデータスキャン API に、新しいスキャンタイプ「DATA_DOCUMENTATION」が登場しました。
前提知識：メタデータ自動生成機能のDataplex データスキャン
BigQueryやCloud Storageといったデータソースをスキャンし、統計情報等のメタデータを生成するDataplexの機能です。データスキャンにはいくつかのtypeがありますが、今回関係するのは2つです。
-
データプロファイルスキャン (
type = DATA_PROFILE) NULL率、ユニーク値の数、最小/最大値、分布などデータの傾向を抽出します。 -
分析情報の生成 (
type = DATA_DOCUMENTATION) テーブルや列の説明（Description）や、推奨する分析クエリを自動生成します。
ポイントは、分析情報の生成を実行する前にデータプロファイルスキャンを実行しておくことです。 分析情報の生成は、データプロファイルスキャンの結果を参照してテーブルや列の説明を生成する事ができるからです。そうでない場合、列名のみから説明文を生成します。
APIでデータ分析情報を生成する方法
事前準備: gcurl エイリアスの設定
APIの実行には認証トークンが必要です。gcloud コマンドで取得したトークンを使って curl を実行するエイリアス（gcurl）を.bashrc等に定義しておくと便利です。
alias gcurl='curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"'
ステップ1: データスキャンの作成
どのテーブルをスキャンするかの定義（データスキャン）を作成します。
# === 変数を設定 ===
PROJECT_ID="my-project-id"
LOCATION="asia-northeast1" # BigQueryテーブルと同じリージョン
DATASCAN_ID="my-scan-01" # 任意のスキャンID
DATASET_ID="target_dataset"
TABLE_ID="target_table"
# =================
gcurl -X POST https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/dataScans?dataScanId=DATASCAN_ID
-d '{ "data": { "resource": "//bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID" }, "executionSpec": { "trigger":{ "onDemand":{} } }, "type":"DATA_DOCUMENTATION", "dataDocumentationSpec":{}}'
ステップ2: データスキャンの実行
ステップ1で指定したDATASCAN_IDを利用して、:run エンドポイントを呼び出し、スキャンを実行します。
gcurl -X POST https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/dataScans/DATASCAN_ID:run
レスポンスに含まれる name（projects/.../dataScans/.../jobs/...）から、末尾のジョブID を控えておきます。
ステップ3: 実行状況の確認
スキャンは非同期で実行されます。ステップ2で取得したジョブID を使い、ジョブのステータスを確認します。
# ステップ2で取得した Job ID を設定
JOB_ID="job-id-from-previous-step"
gcurl -X GET https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/dataScans/DATASCAN_ID/jobs/JOB_ID"
レスポンスの state が SUCCEEDED になればスキャンは完了です。
ステップ4: スキャン結果の確認
API経由で生成された情報を確認できます
gcurl -X get https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/dataScans/DATASCAN_ID?view=FULL
ステップ5: BigQueryスタジオでの確認と反映
Webコンソールの「分析情報」タブにスキャン結果を表示させるためには、対象テーブルに以下のラベルを付与する必要があります
- dataplex-data-documentation-published-scan:DATASCAN_ID
- dataplex-data-documentation-published-project:PROJECT_ID
- dataplex-data-documentation-published-location:LOCATION
ラベル付与はbqコマンド等で実行可能です
また、実際のテーブルスキーマに反映させたい場合は、手動で「スキーマに取り込む」ボタンを押す必要があります。 生成内容による意図しない上書きを防ぐためのUXだと考えられます。
アップデートその2：生成されるテーブルや列の説明文の言語を指定できるように
「データ分析情報の生成」によって生成される「テーブルや列の説明」を、日本語として生成することが可能になりました。
テーブルや列の説明を日本語で生成する方法
ややトリッキーですが「分析情報の生成」対象テーブルの「説明」に、事前にLLMへの指示を記載しておきます。具体的に、日本語で生成したい場合は「Generate table & column description in Japanese language」と記載します。
以下が生成結果です。event_nameの説明に「例」があるのはデータプロファイルスキャンを事前に実施した為と考えられます。
アップデートその3：生成したデータ分析情報をdataplexで公開可能に
生成した分析情報をDataplexのDesciptionsおよびQueriesアスペクト（タグのようなもの）で公開することが可能になりました。あくまでDataplexへの公開で、BigQuery上の説明が上書きされるわけではありません。現時点ではWebコンソール上の「分析情報」メニューから「生成して公開」を選択することにより実現可能です。
Queriesについては、いわゆるゴールデンクエリとしての運用も想定しています。そのため生成されたクエリの書き換えや、新しいクエリの追加も可能です。「Source」を「USER」とすることでレビュー済みのクエリであることを明示することが可能です。
Dataplexで公開されたメタデータはGoogle Cloudが提供する1st partyエージェント（Data Engineering AgentやConversational Analytics AgentやData Science Agent）だけでなく、APIを通じて3rd partyエージェントも利用可能です。
まとめ
これらの機能アップデートを見ると、「Dataplexがデータからメタデータの雛形を自動生成し、必要に応じて人間が（ときにエージェントと相談しながら）修正し、APIを通じて多数のエージェントが参照する」という将来像がなんとなく見えてきます。
また、メタデータはエージェントだけでなく人間が利用することも勿論可能です。運用を引き継いだDWHのテーブル定義が分からないという悩みを抱えている方も多いでしょう。その場合、まずはデータスキャンを利用したデータ把握を始めてみるのも良いと思います。
API経由で利用可能になり、テーブルや列の説明の自動生成が日本語にも対応したことで、メンテナンスコストが大幅に下がりました。
構築当初はテーブル定義をしっかり記述していたものの、運用を重ねるなかでカラムが増えたり、データの性質が変化したりしてしまい、ドキュメントが追いついていないテーブルも世の中には多数あると感じます。
いまデータを利用している人たちの為に、また今後データを利用するエージェントの為にも、これを機にテーブル・列の説明を始めとしたメタデータを継続的にメンテナンスしていくことを目指してはいかがでしょうか！
Discussion