この記事はアイスタイル Advent Calendar 2025 3日目の記事です。

はじめに

istyleのデータ分析システム部に所属しているやす（@YASU11552288）です！

弊社は、化粧品に関する口コミを集めるウェブサイト @cosmeや、化粧品店・ECである@cosme STORE・@cosme SHOPPING の運営をしており、美容業界に対しプラットフォームビジネスとしてToB & ToC向けにソリューション・サービスを展開しています。
その中心となるのが、各種IDで紐づけられた日本最大級の美容に関するデータになります。

この巨大で多種多様なデータを価値化するために、私たちのチームでは、ディメンショナルモデリングによるデータ基盤の整備を進めており、一部のユーザーにも展開し始めています。しかし、データ基盤を整備してもユーザーへの浸透が必要になり、その効果が証明されるまでに時間がかかると思いました。

そこで「人間が使うのを待つのではなく、AIエージェントに 仮想ユーザー としてデータを使い倒させれば、短期間でデータ構造を評価できるのではないか？」と考えました。

データ基盤における「テスト」の難しさ

システム開発には、単体・結合・性能テストなど、明確なテスト手法があります。しかし、データ基盤において「そのデータ構造が、ビジネスにとって本当に意味のある構造になっているか」という曖昧性を含む内容をテストするのは、難しいと思います。

例えば、「データが入っているか」「型が合っているか」は自動化できても
「そのテーブル定義で、ユーザーが直感的に分析できるか？」は、これまで人間が実際に使ってみて、修正していくしかありませんでした。

私たちは、この 「データ構造の意味のテスト」 をAIエージェントを使うことで、システマチックに自動化できるのではないかと考えました。

本記事では、AIエージェントを「人間が利用する回答生成マシーン」としてだけでなく、 「データモデリングの評価器」 として利用する、現在進行系の検証プロジェクトについて紹介します。

1. 検証の目的

検証のゴールは、DWH整備（ディメンショナルモデリング）によって、データ抽出の効率や精度がどう変わるかを定量化することです。
※ 今回は分析の手前のデータの見つけやすさ・取り出しやすさについてのみスコープを絞っています。

比較対象は以下の2つです。

整備BEFORE (Raw Data)：正規化されたテーブルが散在している状態
整備AFTER (Dim/Fact)：ビジネス用語でカラム定義され、スタースキーマ化された状態

人間がSQLを書く場合、AFTERの方が書きやすいのは直感的にわかります。これをAIエージェントに行わせることで、「コスト（トークン数）」「正確性」「速度」の差を数値化し、データ整備の成果を早期に可視化しようという試みです。

2. アーキテクチャと技術スタック

検証の実装には、以下の技術を採用しています。

LLM：Gemini 2.5 Pro
Framework：Google Agent Development Kit (ADK)
DWH環境：BigQuery

エージェントシステムの構築自体はGoogleがデータサイエンティストエージェントのサンプルを提供しているため、スムーズに実装できました。

むしろ後述する「テスト設計」の方に工数の大半を割いています。

3. 評価データセット：「正解」を作る泥臭い作業

評価には、難易度別に分けた20問の質問セットを用意しました。
過去一年間のデータアナリストが対応した案件を参考に単純抽出（レベル1）から、ドリルダウンのような要因分析（レベル4）までを定義しています。

レベル	目的	質問内容
1	リスト抽出：（WHERE句相当）	2025年12月に発売された商品名をデータから抽出してください
～
4	要因分析・ドリルダウン	新規入会した会員のLTV（顧客生涯価値）は、通常期間の入会者と比較して高いですか？

テストを行う以上、正解のSQLと結果が必要です。過去に実際にあった事例を基にしていますが、今回は純粋な「データ抽出能力」を見たいので、複雑なビジネスコンテキストは削ぎ落とし、各難易度レベルに振り分け直しました。

そして、その正解SQLは人間が書きました…大変ですw

AIの性能を測るために、人間が必死に20問のSQLを書き下ろす…。
非常に泥臭い作業ですが、この工程なしには正確な定量評価はできないので、頑張りどころです！

4. 評価ロジック：SQLの一致ではなく「集合」の一致

現在、評価スクリプトで実装を進めている判定ロジックは以下の通りです。
生成されたSQLと正解SQLの文字列比較は行いません（同じ結果でも書き方は無数にあるため）。

判定基準①：BigQueryで実行された結果データ（DataFrame）同士を比較し、行数・列数が一致していること　※行・列の順序は無視する
判定基準②：結果の値が（ほぼ）一致していること

順序不同のリスト比較など、集合としてデータが合っているかを判定することで、AIのアプローチの柔軟性を許容しつつ、結果の正確性を担保します。

5. 今後の展望

現在、検証のためのエージェントシステム実装とテストデータの準備が完了しました。
これから実際にこの基盤を回し、「Rawデータ vs ディメンショナルモデリング」の定量比較を行います。

整備されたデータを使うことで、AIのトークン消費量（＝コスト）やリトライ回数が劇的に減るはずです。もしこれが証明できれば、データ整備の現状に対し、 「AI活用のためにこそ、データ整備が必要だ」 という強力な投資根拠が得られます。

データカタログへの応用

この検証が進むと、データカタログの作り方も変わると考えています。

これまでのデータカタログ構築は、アプリケーション側で作られたテーブル定義書（DDL）を機械的に流し込む作業になりがちでしたが、それでは 「システム的に正しい」カタログにはなっても、「分析に使える」カタログにはなりません。

AIエージェントによる検証を行うことで、以下のようなフィードバックが早期に得られると考えています。

メタデータの過不足の検知：
- 「AIがこの結合キーを見つけられなかった」＝「人間も迷う」。それは、カラムの説明文が足りないのか、リレーション定義が不明瞭なのかを教えてくれます。
網羅性の確認：
- エージェント視点：厳密なロジックでデータがつながっているか
- ユーザー視点：ビジネス用語として直感的に理解できるカラム名になっているか

エージェントがスムーズに回答できるデータ構造を目指すことで、結果的に 「AIにも人間にも優しい、品質の高いデータカタログ」 の要件定義ができるようになります。

最後に

検証完了次第、続報をお届けできればと思います。
今回の検証を考えるにあたって、AIエージェントを単なる「検索ツール」としてではなく、「データモデリングの評価器」 として捉えるようになりました。

SQLがエラーなく走るか（構文チェック）
正しいデータが返ってくるか（ロジックチェック）
そして、データ構造が使いやすいか（意味チェック）

この「3つ目のテスト」をCI/CDに組み込めるようになった時、データエンジニアの価値提供がより向上するのではないかと考えています。