はじめに

株式会社LegalOn Technologiesでアナリティクスエンジニアをしている鈴木です。

データ活用の現場では、メタデータの品質が分析や開発の効率を大きく左右します。特に、データベースのカラム定義（description）は、データの意味や使い方を理解する上で重要な役割を果たしています。

今回は、Gemini（生成AI）を活用してBigQueryのテーブルdescriptionを半自動補完する取り組みについてご紹介します。この施策により、データの可視性・可読性が向上し、チーム全体のデータ活用効率が改善されました。

現在の環境

現在のデータウェアハウスを取り巻く環境は以下の構成となっています。

1. BigQuery上のデータマートを効率的にデータモデリングするツールとしてdbtを採用している
2. dbtにより、dl（データレイク）・dwh（データウェアハウス）・dm（データマート）の3段構成でのデータモデリングをしている
3. dbtで扱うデータパイプラインの一部にプロダクトのDBデータがある
4. dbt-osmosisを利用し、sourceからメタデータを伝搬している

解決したい課題とその背景

当社のデータマートには、プロダクトのDBからDatastream（Google Cloudのデータレプリケーションサービス）を介してBigQueryに連携されているデータがあります。

この連携において、以下の2つの重要な課題に直面していました。

1. メタデータの同期の問題
   • Datastreamを使った同期では、同期元のテーブルにあるdescriptionがBigQueryへ同期されません。その結果、データ分析や開発時に、各カラムの意味や用途を理解するのに余分な時間とリソースが必要となっていました。
2. メタデータの品質の問題
   • プロダクトのテーブルにおけるカラムの情報自体が網羅的でなく、スキーマファイル上の情報の粒度にもばらつきがある状態でした。これにより、データの解釈が属人化し、以下のようなチーム間でのコミュニケーションにも支障をきたすことがありました。
     • 「ライセンス」という名称に対してサービスライセンス・ユーザーライセンスの2種類が存在し、どちらのライセンスのデータなのかが特定できない
3. メタデータを管理する量の問題
   • テーブルとカラムのdescriptionの総量は2,000件を超えるため、DBのスキーマファイルや設計資料、実装を読み解き、適切なdescriptionの整備を人手で行うには膨大な時間がかかってしまう状況でした。

課題解決の方法

この課題を解決するため、Vertex AI のGeminiとグラウンディングにVertex AI Searchを活用し、DBのスキーマファイル情報からBigQuery上のdescriptionを半自動補完するシステムを構築しました。

システム構成

「グラウンディングの更新」と「description更新」の2つを行う構成となっています。

1. グラウンディング更新

グラウンディングとは、Geminiにコンテキストを与えるためのデータソースとなる部分です。

スキーマファイルはGitHubリポジトリ上で管理されており、リポジトリをcloneしてVertex AI Searchで使えるように整形し、GCS（Google Cloud Storage）上に保存します。

その後、GCSをVertex AI Searchに同期します。

2. description更新

BigQueryへのdescription反映は、dbt上で管理されるmodelのymlファイルを通してデータマートへ反映する流れとなっています。

Geminiによる反映は以下の流れで対応しました。

1. Geminiでcsv出力
   • グラウンディング＋プロンプトによってdescription付き情報を生成
2. description付きcsvをdbtのsources.ymlへ書き出す
   • csvをパースし、sources.ymlへ書き出すようにします
3. dbt-osmosisでデータマートへdescriptionを伝搬
   • sources.ymlの情報をdwh, dmのmodelのdescriptionに伝搬します
4. dbt build実行によりBigQueryへ書き出し
   • 最後にdbt buildにてBigQueryへ書き出します

工夫したポイント

1. Geminiを採用した理由
   • BigQueryを含めデータエンジニアリングのプラットフォームはGoogle Cloudを中心としています。

     そのため、他の生成AIサービスより敷居が低く費用も抑えられるためGeminiを採用しました。

2. descriptionの長さ調整
   • スキーマファイル上のdescriptionは文字数が長い場合もあり、BigQuery上での文字数としては問題無いものの、Looker上のlabelに転用したい場合に長すぎて不向きなケースがあります。

     以下の例のようにlabel部分に当たる情報と詳細情報の2種類に分けて扱えるようデリミタを設けてdescriptionを出すようにしています。

     • プリンシパルID:access level を設定する user_id or user_group_id

精度調整のための工夫

Geminiの精度を向上するためには、いくつか工夫が必要でした。

以下に詳細を説明します。

1. グラウンディングを採用した理由
   • スキーマファイルをGeminiへ都度プロンプトとしていれるという方法もありましたが、スキーマファイルが巨大な場合Geminiのインプットトークン上限を超えてしまう可能性があるため、トークン制限に掛からないグラウンディングを採用しました。
2. グラウンディングにVertex AI Searchを採用した理由
   • RAG Engineという選択肢もありましたが、より手軽に利用できるVertex AI Searchを採用しました。
3. description情報がスキーマファイルに無い場合の対策
   • プロンプト内でカラム説明が無い場合にも補完するよう指示を加える事でdescriptionの欠落を軽減するようにしています。
4. 精度をevaluationで担保
   • 精度を保つ事は大事ですが、どのように精度を保つか自体が課題になります。
   • GeminiにはGen AI Evaluation Serviceが用意されており、これを組み込む事で精度を数値として管理できるようになります。
   • 組み込むポイントとしてグラウンディング更新時にevaluationを通すようにして、精度の劣化を検知するようにしています。
   • evaluationにはいくつかの評価の仕組みがありますが、今回はある程度の表記揺れは許容範囲と考え bleu（BiLingual Evaluation Understudy）を採用しました。

結果もしくは得られたもの

1. 作業時間の短縮
   • descriptionの数に比例して作業は多くなる傾向でしたが、グラウンディング更新とdescription更新のコマンド2つだけで済み、1分以内にはdescription補完作業を行う事ができました。
2. 低コストでの実現
   • Google Cloud内の他のサービスのコストの占める割合と比較しても1%未満に収まる程度の低コストとなっており、費用対効果の高さが実感できています。
3. Gemini を作業改善の仕組みとして取り入れる手本になった
   • プロンプトの管理やコードへの組み込みをどのように行うかわかり、今後の展開に繋げられる事例となりました。

考察および今後の展開

今回はDBだけを対象としていたり、スキーマファイルだけをグラウンディング時に参照していますが、今後は設計資料やプロダクトのコード等もメタデータの情報源となります。

Vertex AI Searchによるグラウンディングは実装時の手軽さから採用しましたが、生成AI分野は日進月歩で進化を続けています。最近ではMCP Serverを活用する手法なども登場し、より簡易的な仕組みで高い精度を実現できるようになってきています。

今後も新しい技術を積極的に取り入れながら、効率的かつ効果的な仕組みづくりに取り組んでいきたいと考えています。

まとめ

今回、Geminiを活用してBigQueryのテーブルカラムのdescriptionを半自動補完する仕組みを構築し、データの可視性と保守性を向上させることができました。

プロダクトのDBスキーマ情報を効果的に活用し、グラウンディングとプロンプトの組み合わせにより、より良いデータドキュメンテーションの実現に近づくことができています。

今後も技術の進化を取り入れながら、より効率的で正確なメタデータ管理を目指していきます。

謝辞

本ブログの実装は、データエンジニアリングチームのメンバーやプロダクトの協力によって実現できています。ここに感謝の意を表します。

仲間募集

アナリティクスエンジニアの採用枠を現在オープンしています、ご興味ある方のご応募お待ちしております。