はじめに
こんにちは、GMOメディアでデータ系業務を担当してるホリノと申します。
本記事では、Gemini APIを活用してメタデータのドキュメント化を自動化した取り組みを紹介します。
背景
まずは今回紹介する取り組みの前提となる、データカタログというものから紹介します。
データカタログとは・・組織内の膨大なデータを整理し、検索・利用を容易にするためのメタデータの一元管理システムです。
このテーブルにはこんなのが入ってるよ、こう使うよ、こんな中身をしてるよ。的な情報をまとめておくものです。前提として、そんな管理システムのアプリケーションを、データ活用で協働するチームへ提供した背景があります。
本当はGoogleさんが早くに提供してくれると思いあえて作っていなかったのですが、毎日の作業に耐えられず先に作ってしまったものになります
（GCPよりすでに似たような機能はリリース済み😂）
スケールの課題
データカタログの導入により、これまで非エンジニアには明らかにされていなかったテーブル群の情報が明らかになったわけですから、素直に「わかりやすい」という反応は得られました。それまでのなかなか情報を得られなかった状態から、使えるモノが可視化されただけでも大きな前進でした。
しかし、新たな課題が浮上しました：
- 週1,2個ペースで新しいデータマートが作成される
- 各テーブルには複数のカラムが存在する
- 説明が空欄のままだと、せっかくのデータカタログが機能しない
つまり手動でのメンテナンスが追いつかず、ドキュメント化の自動化が必要になりました。
システムアーキテクチャ
設計思想：YAML中心のメタデータ管理
今回構築したシステムは、YAMLファイルをメタデータの信頼できる唯一の情報源とする設計になっています。
BigQuery（実テーブル）
↓ 差分検知
YAMLファイル（メタデータ管理）
↓ 読み込み
Streamlit（データカタログ表示）
YAMLファイルには以下のような情報を格納します：
schemas:
dataset_name:
table_name:
description: 説明
period_month: '12'
use_cases:
primary: 日付単位でログを確認する
notes: ''
columns:
date:
description: 日付
type: date
is_partition: true
column1:
description: カラム1
type: string
is_partition: false
tags:
service: service_name
domain: service
time: daily
このYAMLには、BigQueryのdescriptionだけでなく、データ保持期間、利用用途、タグ情報など、Streamlitでの検索・フィルタリングに必要な情報も含まれています。
全体の処理フロー
システムは毎日のバッチ処理として動作し、以下の3ステップで実行しています：
【ステップ1】YAML生成
1. BigQuery INFORMATION_SCHEMA取得
2. 既存YAMLと差分比較
3. 新規テーブルをYAMLに追加（description: "TODO: 要入力"）
【ステップ2】AI自動生成
1. TODO項目を埋めるよう指示
2. Gemini APIでTODO: 要入力を変換
【ステップ3】品質チェック
1. 生成済みの説明を検証
2. 問題検出（TODOが残ってないか、バグってないかなど）
3. より厳格なプロンプトで再生成
実装のポイント
1. Context Cacheの活用
Gemini APIのContext Cache機能を使って、YAMLファイル全体をキャッシュしています。
def create_context_cache_for_yaml(yaml_content: str) -> str:
"""YAMLファイル用のContext Cacheを作成"""
system_instruction = f"""
ここにコンテキストキャッシュを生成してくださいという旨の指示を書く
"""
cached_content = caching.CachedContent.create(
model_name="gemini-2.5-flash",
contents=[yaml_content],
system_instruction=system_instruction,
ttl=timedelta(hours=1),
)
return cached_content.name
Context Cacheを使う理由：
- YAMLファイル全体（10万文字以上）を毎回送信するとコストが高い
- 既存の説明文のスタイルをAIに学習させることで、文体の一貫性を保てる
- 同じファイル内の類似テーブル・カラムを参照できる
2. 品質チェック機構
ほんとにAIに作らせて大丈夫なの？と思いましたが、当然一定の確率でまちがえます・・実運用では大体10回に1回くらい期待と異なる出力が発生してました。
初期段階では繰り返し検証を行い、よくあるバグパターンを再生成するときに読み込ませ、ミスを発見して再生成する仕組みを入れています。
ぶっちゃけ、間違えてても、本当に使われているなら誰かがこれ違うよ！って気づきます。 ので、その時に直せば⭕️
3. 人間によるチェック
これはSlackにAIが登録した情報がわかるように通知させています。
データマートを設計した翌日の朝、AIがこういうテーブルだと思ったのでこんな感じで説明を生成してみたよ。という通知が来るので、問題なければそのまま見逃します。問題があれば、手で修正を行なっています。変なバグは基本起こらないので普段はAIを信じて、文脈的にまちがえているパターンは都度修正しています。
運用してみて
費用対効果
コスト面：
Gemini 2.5 Flashなので非常に安価で、月数百円内のコストで運用できています。
削減工数：
大体月に2,3時間は楽してる気がします。
数字だけ見ると小さく見えますが、実際には
- 作業を後回しにして溜まる問題の解消
- 作業中断によるコンテキストスイッチの削減
などなど、こんな作業は私がやる必要があまりないので自動化したい案件でした。
今後の展望
技術的成功と組織課題
本システムにより、データ基盤の整備という技術的な課題は解決しました：
- データカタログで情報を可視化
- メタデータのドキュメント化を自動化
- 非エンジニアがアクセスできる環境を構築
しかし、組織全体でのデータ活用という観点では、まだ課題が残っています
- データを「見る人」「活用できる人」が限られている
- データリテラシーの向上が必要
- 「データが使える状態」≠「データが使われる状態」
次のステップ
技術だけでは解決しない組織課題に対して、以下の取り組みを検討しています：
データ活用文化の醸成：
より直感的なUI/UX：
継続的な改善：
データ活用を組織に根付かせるには、技術基盤の整備と人材育成・文化醸成の両輪が必要です。今回のシステムは前者の一歩ですが、引き続き後者にも継続的に取り組んでいきます。
おわりに
AIを活用したメタデータの自動ドキュメント化システムについて紹介しました。
シンプルな仕組みですが、以下のポイントを押さえることで実用的なシステムになりました：
- Context Cacheで既存スタイルを学習
- 品質チェック機構で精度を担保
- YAML中心設計でメンテナンス性を確保
今回は実務をAI化してみた！な話でした。
Googleさんのドキュメント自動化を待てず実装してしまったものになりますが、本当は実際の活用事例から自動的に更新をかけ続けてくれるものであると、なお良いですね！
この記事が同じような課題を抱えている方の参考になれば幸いです。
Discussion