はじめに

この記事は STORES Advent Calendar 2025 の10日目の記事です。

こんにちは、STORES でデータアナリストをしているyougaiです。

STORES ではデータの民主化を進めており、誰でも BigQuery や Metabase などのBIツールを触ることができます。また、最近では社内向けにデータ分析AIエージェントツールを提供しており、人・AIどちらにとっても、テーブル・カラムがなにを意味するのかを表すメタデータ（今回は主に BigQuery のdescription/カラム説明）の重要性が上がっています。

STORES にはデータエンジニアも在籍していますが、データアナリストもデータ基盤の改修を行います。汎用的な役割を持たせたwarehouse層から特定の用途や誰でも使いやすい用途に加工したmart層への集計部分を作成・改修することが多いです。

特にこのmart層の作成・改修において、スピード重視で対応を行った結果、メタデータが入っていないカラムが多くあり、「いつか記載しなきゃ」と後回しになっていました。

そこで、「Devin」を使って、データ基盤のメタデータ拡充を行なった話を紹介します。

メタデータのカバレッジを計測

まずは現状把握です。メタデータがどれだけ記載されているかを確認します。

私たちは dbt のスキーマファイルにメタデータを記載し、それを BigQuery に反映させています。そのため、BigQuery の INFORMATION_SCHEMA を使うことでカラムの Description を取得できます。

SELECT
  table_schema,
  table_name,
  column_name,
  description
FROM
  -- 実行環境のリージョンに合わせて指定（例: region-asia-northeast1）
  `region-{region}`.INFORMATION_SCHEMA.COLUMN_FIELD_PATHS

さらに、dbt のincrementalモデルで、毎日のデータセットごとのメタデータ記載率を記録し、Metabase にて時系列で「メタデータの拡充が進んでいるか」を可視化しています。

{{
  config(
    materialized="incremental",
    incremental_strategy = 'insert_overwrite',
    partition_by={
      'field': 'record_date',
      'data_type': 'date',
    },
    on_schema_change='sync_all_columns',
    cluster_by=["dataset"]
  )
}}

SELECT
  CURRENT_DATE('Asia/Tokyo') AS record_date,
  table_schema AS dataset,
  COUNT(*) AS column_count,
  COUNTIF(description <> '') AS description_filled_column_count,
  COUNTIF(description <> '') / COUNT(*) AS description_filled_column_ratio
FROM
  -- 実行環境のリージョンに合わせて指定（例: region-asia-northeast1）
  `region-{region}`.INFORMATION_SCHEMA.COLUMN_FIELD_PATHS
GROUP BY ALL

「メタデータがただ記載されているだけでなく、正しく記載されていること」が真のゴールではありますが、日々の活動の成果が可視化されることはモチベーションになりますし、どの領域のカバレッジが悪いかを把握するのに役立ちます。

Devin への指示

Devin と Slack を連携し、Slack から Devin にメンションする形で、タスクを依頼しています。

Devin への依頼プロンプトは、1テーブルのみか・特定の目的のテーブル群か・データセット全体かなどによって使い分けますが、例えば、以下のようなプロンプトを使っています。

@Devin
{データ基盤のGithub リポジトリ名} リポジトリで以下の修正を行う PR を作成してください。

# 修正対象
mart層のレジに関するdbtテーブルスキーマ（ファイル名パターン: _mrt_regi__*.yml）

# 修正内容
以下の GitHub リポジトリ（リテールのアプリケーション実装）やwarehouse層のdbtテーブルスキーマを参照し、各テーブルのカラム定義（column description）を日本語で記述してください。
{対象のGithub リポジトリURL}

# 要件
- 可能な限り、実装コードやコメントからカラムの意味を正確に読み取ること
- 誤訳や一般的すぎる説明を避け、ドメインの文脈に沿った内容にする
- 列挙型（enum）、定数、状態コード、フラグなどで値の意味が実装から判明する場合は、当該カラムの description 内に「値 → 意味」の対応を明記すること
  - 例：0=未精算, 1=精算済み, 2=取消 など
- スキーマに未定義のカラムは追加しない（既存の定義の補完のみ）
- YAMLファイルとして構文エラーが起きないように注意
- ファイルの命名やファイル構成は変更しないこと

STORES では Rails で書かれたプロダクトが多いので、今までは対象のテーブルに相当するモデルを都度見に行くという作業を行なっていました。リポジトリへのアクセス権を持つ Devin がそれを代替してくれるのは非常にありがたいです。

作成されたPRをレビューし、内容に過不足があれば、Slack 上で追加情報を与えながら修正を指示します。最近は、Devin が作ったPRに対して Claude にレビュー・加筆修正させるフローも試しています。

なぜ Devin か

Slack でメンションし、GitHub のPR作成まで完結してくれるのは、やはり楽です。

とりあえず Devin に依頼し、手が空いたらPRを確認。出来がイマイチな時もありますが、そういうときはクローズし、渡す情報や対象テーブルを見直して再度依頼する、というトライ＆エラーも簡単です。

また通常のPRではデータ本部内のメンバーのレビューを通す必要がありますが、データ本部では「Devin を第3のエンジニアとして扱い、Devin への依頼者がPRをレビューしてマージすることを良しとする」という運用にしています。（もちろん内容に自信がないときはメンバーにレビューをお願いしています）

「自分のタイミングで進められる」という点が、後回しになりがちなドキュメント整備に取り組むハードルを下げてくれています。

注意点

運用する中で見えてきた注意点もあります。

渡す情報が広すぎたり曖昧だったり、あるいは多くのテーブルを一度に埋めようとすると、「それはカラム名からのみ推測しただけでは？」という内容になることがあります。そういうときは、渡す情報を具体的にする、対象のテーブルを減らすといった工夫で精度が上がります。

また、Claude によるレビュー・加筆修正を行なっていますが、現状 Claude の方が賢いと感じることが多いです。「Devin に土台を作成してもらいつつ、PR上で Claude にレビューしてもらう」という体制が、現時点でのベターな解だと感じています。

終わりに

今回はデータ本部内での Devin の利用例を紹介しました。

メタデータ拡充だけでなく、SQL の修正なども Devin を通じて行なっています。「手元で書いたこの SQL のロジック、warehouse層や mart層に反映した方がいいけど、今時間がないし後回しにしよう...」としていたタスクが、Devin を使うことでサクッと消化できるようになりました。

まだ、社内向けのデータ分析AIエージェントツールの回答精度が上がったと実感できるレベルにはできていないので、今後もこの活動を継続的に行なっていきたいと思います。

STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

データ基盤のメタデータ拡充をDevinに任せる

はじめに

メタデータのカバレッジを計測

Devin への指示

なぜ Devin か

注意点

終わりに