見出し画像

「この MAU、退会ユーザー含んでますか？」をなくす — dbt × AI で構築する指標メタデータ基盤

Smuch

皆さん、こんにちは。コミューンData TeamのAnalytics Engineer、Shangです。
Communeの開発では、日々増え続けるダッシュボード指標の「意味」と「正しさ」をどう維持するかが、チームの長年の課題でした。本記事では、その課題に対して私たちが実践しているアプローチを共有します。

TL;DR
ダッシュボードの指標が増えるほど、「この数値の定義は？」という QA が膨れ上がり、データチームの工数を圧迫します。指標定義は SQL・スプレッドシート・口頭に分散し、属人化と暗黙知がメンテナンスを困難にします。さらに BI ツール上の計算フィールドは dbt だけでは管理しきれません。

本記事では、dbt モデルに付随する構造化された指標定義ファイル `*_semantic.yml` を導入し、BI 側メタデータとの FULL JOIN による自動整合性検証、AI Skill による定義の半自動生成を組み合わせることで、これらの課題を解決したアプローチを紹介します。

 
TL;DR

この記事の対象読者

  • dbt でデータ基盤を運用しており、指標定義の管理に課題を感じているデータエンジニア / アナリティクスエンジニア

  • BI ダッシュボードの指標に関する QA 対応に工数を割かれているデータチーム

  • データプロダクトの属人化を解消し、セルフサービス化を進めたいマネージャー / リーダー


背景

データ基盤が成長するにつれ、BI ツール上に表示される指標の数は数百〜数千に膨れ上がります。 しかし「この数値は何を意味するのか？」「どう計算されているのか？」という問いに即座に答えられるチームは多くありません。

私たちの SaaS プロダクトでも、dbt で管理する mart レイヤーのテーブルが増加し、ダッシュボード上の指標定義がコード・ドキュメント・口頭説明に分散するという課題に直面しました。

「MAU」ひとつとっても定義は曖昧

たとえば、ダッシュボードに「MAU（月間アクティブユーザー数）」という指標が表示されているとします。ビジネス側から「この MAU はどう計算されていますか？」と聞かれたとき、データエンジニアでも即答できないケースが少なくありません。

  • 退会済みユーザーは含むのか？

    • 退会前の月にアクティビティがあった場合、その月の MAU に含めるかどうか

  • 管理者アカウントは除外されているか？

    • テスト用の管理者アカウントが混入していると、数値が実態より膨らむ

  • ユーザーの状態はいつ時点のものか？

    • 「現在退会済み」のユーザーを遡って除外するのか、それとも当時の状態で判定するのか（SCD Type 2 のどのスナップショットを使うか）

  • 「アクティブ」の定義は？

    • ログインだけで良いのか、投稿やコメントなどのアクションが必要なのか

  • 分析除外フラグのあるユーザーは？

    • 不正アカウントや特殊用途のアカウントなど、分析対象から除外すべきユーザーの扱い

これらの条件の組み合わせ次第で、同じ「MAU」でも数値は大きく変わります。実際に、フィルター条件の違いだけで MAU が 20〜30% ずれることもありました。

ダッシュボードが増えるほど QA が膨れ上がる

ダッシュボードの数が増え、テーブルごとに数十の指標が並ぶようになると、ビジネス側からの問い合わせも比例して増加します。

「この"投稿ユーザー数"は削除済みの投稿も含んでいますか？」 「"申し込み数"はキャンセル済みも含みますか？」

一つひとつは単純な質問ですが、回答するためには SQL を読み、WHERE 句のフィルター条件を確認し、JOIN 先のテーブルの仕様を調べる必要があります。指標が数百を超えると、このような QA 対応だけで相当な工数が消費されます。

属人化と暗黙知 — データプロダクトの最大のリスク

さらに深刻なのは、これらの「指標の裏にあるビジネスロジック」が特定の担当者の頭の中にしか存在しないという問題です。

  • 属人化: 「あの指標の定義は○○さんに聞けばわかる」という状態。担当者が異動・退職すると、指標の正確な意味を知る人がいなくなる

  • 暗黙知の蓄積: 「退会ユーザーは MAU から除外する」「管理者アカウントはカウントしない」といったルールが口頭やチャットの断片に散在し、体系的に記録されていない

  • メンテナンス不能: ドキュメントがあっても SQL と乖離していれば意味がない。しかしドキュメントと SQL を手動で同期し続けるのは現実的でない

結果として、データプロダクトは作った人にしか維持できないものになりがちです。

BI ツール上の計算フィールド — dbt だけでは管理しきれない指標

もうひとつ見落としがちな問題があります。ダッシュボードに表示される指標のすべてが dbt の mart テーブルから直接来ているわけではありません。
データアナリスト（以下、DA）がダッシュボードを構築する過程で、BI ツール上に計算フィールド（Calculated Field） を作成することがあります。

# BI ツール上で定義される計算フィールドの例
継続率 = 翌月アクティブユーザー数 / 当月アクティブユーザー数
平均投稿数 = 投稿数 / アクティブユーザー数
加重エンゲージメントスコア = (投稿数 * 3 + コメント数 * 2 + リアクション数 * 1) / ユーザー数

これらの計算フィールドは dbt のモデルには存在せず、BI ツール内部にのみ定義されているため：

  • dbt の schema YML や SQL からは把握できない

  • dbt 側の mart テーブルのカラム定義だけ見ても、ダッシュボード上の指標一覧と一致しない

  • 計算フィールドの変更履歴は BI ツール内にしか残らず、Git 管理されない(BI as codeは除外)

「BigQuery 用の MCP（Model Context Protocol）サーバーがあれば、テーブルのメタデータを AI に渡して解決できるのでは？」と思われるかもしれません。確かに BigQuery MCP サーバーを使えば、dbt が生成したテーブルのカラム名・型・description を AI エージェントに参照させることは可能です。しかし、dbt の schema YML に書かれている情報だけでは、指標定義の暗黙知は解消できません。

たとえば、schema YML の description に "月間アクティブユーザー数" とだけ書かれていた場合、以下の問いには答えられません：

  • 退会済みユーザーは含むのか？（→ filters.withdrawal の情報が必要）

  • 管理者アカウントは除外されているか？（→ filters.administrator の情報が必要）

  • 集計期間は直近 2 年か、全期間か？（→ metadata.collection_period の情報が必要）

  • この指標はどのビジネス文脈で使われるのか？（→ definition.business の情報が必要）

これらは SQL を読めば推測できる部分もありますが、ビジネス上の意図やフィルター条件の「なぜ」は SQL には書かれていません。BigQuery MCP はテーブルの物理的なメタデータへのアクセス手段としては有用ですが、指標の暗黙知を形式知にするためには、それを補完するセマンティックレイヤー（意味的な定義層） が不可欠です。

この課題に対応するには、BI ツール側のメタデータも構造的に取得する必要があります。近年は BI as Code のアプローチが広がっており、BI ツールのダッシュボード定義をコードとしてエクスポートする仕組みが利用可能です（詳細は後述の「BI as Code」セクションを参照）。

本記事で紹介するセマンティック定義では、この BI 側メタデータを活用し、dbt 管理外の指標も含めた整合性検証 を実現しています。

課題の整理

課題の整理

解決策

  • _semantic.yml — dbt モデルに付随する指標定義ドキュメント を導入しました。

用語に関する注記: 本稿で「セマンティックレイヤー」「セマンティック定義」と呼んでいるのは、指標のビジネス定義・技術定義・フィルター条件を記載した独自のメタデータ YAML ファイルです。dbt Cloud が提供する Semantic Layer（MetricFlow / semantic_models）とは異なる仕組みです。

対象範囲 — BI プロダクトが直接参照する mart モデルのみ

  • `_semantic.yml` の管理対象は、ダッシュボード等の BI プロダクトが直接参照する mart レイヤーのモデルに限定しています。

```mermaid
flowchart TB
    subgraph Out["対象外"]
        Src["staging<br>（生データ取り込み）"]
        Dwh["warehouse<br>（中間変換）"]
    end

    subgraph In["対象"]
        Mart["mart<br>（BI 直接参照）"]
    end

    subgraph BI["BI プロダクト"]
        Dash["ダッシュボード"]
    end

    Src --> Dwh --> Mart --> Dash

    style In fill:#e8f5e9,stroke:#4caf50
    style Out fill:#f5f5f5,stroke:#bdbdbd
```
対象範囲

この範囲限定は意図的なものです。

  • staging や warehouse の全モデルまで定義を書こうとすると、メンテナンスコストが爆発し本末転倒になります。

  • 「ビジネスユーザーが目にする指標」に絞ることで、管理対象を現実的なサイズに保ちつつ、最も効果の高いレイヤーにリソースを集中させています。

設計思想

  • dbt モデルと同じディレクトリに配置し、コードと定義を近接させる

  • BI ツール側メタデータと `display_name` × `model_name` で JOIN し、整合性を自動検証

  • Claude Code Skill（AI コード生成）で SQL を分析し、定義ファイルを半自動生成

ファイル構造

version: 2

metadata:
  model_name: "target_dbt_model"

defaults:                    # ファイル内全メトリクス共通のデフォルト値
  filters:
    general: "含"          # 一般ユーザー
    administrator: "除"    # 管理者
    withdrawal: "含"       # 退会ユーザー
  time_grain: "daily"
  metadata:                # ※ トップレベルの metadata（モデル情報）とは別。ここは defaults 配下の共通メタデータ
    update_frequency: "日次"
    collection_period: "直近2年"

metrics_documentation:
  - name: "dau"                               # Column ID（英数字スネークケース、ファイル内一意）
    display_name: "アクティブユーザー数"         # BI ツール表示名（ファイル内一意、JOIN キー）
    definition:
      business: "指定期間内にログインしたユーザーの総数"
      technical: "action_date が当日の user_id を COUNT DISTINCT"
      detail: |
        対象ユーザーのフィルター条件や
        集計上の注意事項をここに記載
    specification:
      data_source: "user_activity"

ポイント

ポイント

`display_name`と `model_name` は JOIN キー として機能し、不一致は後述の整合性チェックで自動検出されます。

全体フロー

```mermaid
flowchart TB
    subgraph Input["① 入力ソース"]
        SQL["dbt SQL モデル"]
        Schema["schema YML"]
        CSV["指標マスタ CSV<br>（オプション）"]
    end

    subgraph Generate["② セマンティック定義 生成"]
        Analyze["SQL 分析<br>JOIN / WHERE / 集計ロジック"]
        Merge["情報統合<br>SQL + YML + CSV"]
        Validate["一意性チェック<br>name / display_name"]
        Write["*_semantic.yml 書き込み"]
    end

    subgraph Export["③ エクスポート"]
        GA["CI/CD パイプライン<br>（Push / スケジュール実行）"]
        CSVOut["CSV 生成"]
        DWH["CSV を BigQuery へ<br>アップロード"]
    end

    subgraph Verify["④ 整合性検証"]
        Join["BI メタデータと FULL JOIN<br>display_name × model_name"]
        Status["metric_status 判定"]
        OK["ok: 正常マッチ"]
        NotInBI["not_found_from_bi:<br>定義はあるが BI 側にない → 調査・是正"]
        NotInSemantic["not_found_from_semantic:<br>BI 側にあるが定義がない → 追加"]
    end

    SQL --> Analyze
    Schema --> Analyze
    CSV --> Merge
    Analyze --> Merge
    Merge --> Validate
    Validate --> Write

    Write --> GA
    GA --> CSVOut
    CSVOut --> DWH

    DWH --> Join
    Join --> Status
    Status --> OK
    Status --> NotInBI
    Status --> NotInSemantic

    NotInBI -->|フィードバック| Write
    NotInSemantic -->|フィードバック| Write
```

整合性の自動検証

BI ツール側のメタデータと `*_semantic.yml`を `display_name` × `model_name`で FULL JOIN するモデルを用意し、以下の 3 ステータスで整合性を判定します。

整合性の自動検証

`not_found_from_bi` は「BI 側に表示がない＝不要」とは限りません。ダッシュボードの整理で一時的に非表示にしただけで、別画面で使われている場合もあります。機械的に削除せず、原因を確認したうえで対応を判断してください。

この仕組みにより、BI ツールとセマンティック定義の乖離を日次で検出し、継続的に指標品質を維持できます。

BI as Code — BI 側メタデータを活用した指標定義の是正

背景で述べたとおり、dbt 管理外の BI 計算フィールドを含めた整合性検証には、BI ツール側のメタデータが不可欠です。ここでは、そのメタデータを取得・活用する具体的な方法を説明します。

BI as Code とは

近年、BI ツールのダッシュボード定義をコードとしてエクスポート・管理するアプローチが広がっています。

BI as Code

これらのメタデータをパースすることで、BI ツール上にどんな指標が存在し、どのテーブルに紐付いているかをプログラム的に把握できます。

具体的な是正フロー

BI 側メタデータからセマンティック定義を是正する流れを示します。

```mermaid
flowchart TB
    subgraph BI["BI ツール"]
        TML["ダッシュボード定義<br>（TML / LookML 等）"]
    end

    subgraph Parse["メタデータ抽出"]
        Extract["指標一覧を抽出<br>・表示名<br>・紐付けテーブル<br>・計算フィールドの有無"]
    end

    subgraph DWH["データウェアハウス"]
        Master["BI メタデータテーブル<br>（指標名 × テーブル名）"]
    end

    subgraph Join["整合性チェック"]
        FullJoin["FULL JOIN<br>display_name × model_name"]
    end

    subgraph Semantic["セマンティック定義"]
        YML["*_semantic.yml"]
    end

    subgraph Action["是正アクション"]
        Add["不足 → 定義を追加"]
        Remove["余剰 → 調査のうえ是正"]
        Fix["不一致 → 表示名を修正"]
    end

    TML --> Extract
    Extract --> Master
    Master --> FullJoin
    YML --> FullJoin
    FullJoin --> Add
    FullJoin --> Remove
    FullJoin --> Fix
    Add --> YML
    Remove --> YML
    Fix --> YML
```

BI メタデータが教えてくれること

前述の `metric_status`（整合性の自動検証を参照）を通じて、BI メタデータは具体的に 3 つの問題を教えてくれます。

BI メタデータが教えてくれること

維持サイクル — BI メタデータを起点とした運用

BI メタデータを定期的に取り込むことで、以下の維持サイクルが回ります。

```mermaid
flowchart TB
    A["日次バッチ<br>metric_status を算出"] --> B["スプレッドシートに自動反映<br>不整合指標の一覧"]
    B --> C["週次 Slack 通知<br>当番担当者にメンション"]
    C --> D["当番が AI Skill で是正<br>定義追加・削除・表示名修正"]
    D --> E["PR 作成・レビュー"]
    E --> F["main マージ"]
    F --> A
```

具体的な運用フロー

このサイクルは 3 つのレイヤーで自動化されています。

1. 日次：不整合の自動検出とスプレッドシート連携

前述の「データ処理パイプライン」で生成された `metric_status`（日次バッチジョブ）のうち、`not_found_from_bi` / `not_found_from_semantic` のステータスを持つ指標がスプレッドシートに自動反映されます。スプレッドシートにはテーブル名・指標表示名・ステータスが一覧化されるため、現時点で何件の不整合があるかが常に可視化されています。

2. 週次：Slack 通知と当番制

毎週決まったタイミングで、不整合件数のサマリーが Slack チャンネルに通知されます。通知にはその週の当番担当者へのメンションが含まれており、対応漏れを防ぎます。

当番はデータチーム内でローテーションし、特定の人に負荷が集中しない仕組みです。

週次：Slack 通知と当番制

3. 当番対応：AI Skill で是正

当番担当者はスプレッドシートから不整合リストをコピーし、AI Skill に貼り付けるだけで一括是正できます（具体的な手順は後述の「ユースケース 3: metric_status による一括是正」を参照）。Skill がステータスに応じて定義の追加・コメントアウトを行います。当番は変更内容を確認・コミットし、PR を作成してレビュー・マージすれば対応完了です。

なぜこの運用が回るのか

  • 起点が自動：人が不整合を探す必要がない。バッチ→スプレッドシート→Slack まで自動で流れる

  • 対応が軽い：AI Skill が是正の実作業を担うため、当番の作業は「リスト貼り付け→レビュー→マージ」の数分で完了

  • 負荷が分散：ローテーションにより属人化しない。また、全員が Skill の使い方を覚える機会になり、チーム全体のメンテナンス能力が底上げされる

AI Skill（Claude Code）による定義の生成と維持

Claude Code Skill とは

Claude Code は Anthropic が提供する AI コーディングアシスタントの CLI ツールです。その中の Skill 機能を使うと、特定のタスクに特化したプロンプトとガイドラインをパッケージ化し、スラッシュコマンドで呼び出せるようになります。

本プロジェクトでは、セマンティック定義の生成・更新に特化した Skill `/generate-semantic-yml` を構築しました。

Skill の実装構成

Skill は以下の 2 ファイルで構成されます。

.claude/
  skills/
    generate-semantic-yml/
      SKILL.md          # Skill 定義（手順・ルール・出力フォーマット）
docs/
  semantic_metric_guide.md  # 指標定義ガイド（命名規則・フィールド仕様）
Skill の実装構成

重要なのは、Skill 自体がコードではなく Markdown で書かれたプロンプトである点です。プログラミング不要で、ルールの追加や修正は Markdown を編集するだけで即座に反映されます。

使い方 — 3 つのユースケース

ユースケース 1: 新規モデルの定義生成

新しい mart モデルを追加した際、モデル名またはファイルパスを指定するだけで定義を生成します。

/generate-semantic-yml kpi_daily_summary

Skill は以下のステップを自動で実行します：

```mermaid
flowchart TB
    A["モデル名を受け取る"] --> B["SQL ファイルを検索"]
    B --> C["SQL を分析<br>JOIN / WHERE / 集計"]
    C --> D["schema YML を読み込み<br>カラム名・description"]
    D --> E["既存 semantic.yml を確認<br>新規 or 更新を判断"]
    E --> F["定義案を生成<br>ユーザーに提示"]
    F --> G["確認後ファイルに書き込み"]
```

AI は SQL の JOIN/ WHERE 条件からフィルターロジックを、集計関数（COUNT DISTINCT/ SUM/ AVG等）から計算方法を自動的に読み取り、構造化された定義に変換します。

ユースケース 2: ディレクトリ一括生成

ディレクトリパスを指定すると、配下の全 SQL モデルに対して一括で定義を生成します。

/generate-semantic-yml models/mart/external/analytics/

新規プロジェクトの立ち上げ時や、大量のモデルに一度に定義を追加したい場合に有効です。対象モデルの一覧が提示され、ユーザーが確認してから処理が進みます。

ユースケース 3: metric_status による一括是正

BI メタデータとの整合性チェックで検出された不整合リストを貼り付けると、Skill がステータスに応じた修正を一括実行します。

/generate-semantic-yml

# 以下を貼り付け:
# metric_status | table_name | metric_display_name
# not_found_from_semantic | user_kpi | 新規登録ユーザー数
# not_found_from_bi | user_kpi | 旧指標名（廃止済み）
metric_status による一括是正

生成例

SELECT
  date,
  COUNT(DISTINCT user_id) AS dau,
  COUNT(DISTINCT CASE WHEN action_type = 'post' THEN user_id END) AS post_user_cnt
FROM user_activity
WHERE is_active = TRUE
  AND is_admin = FALSE
GROUP BY date

AI が分析する内容:

AI が分析する内容

生成される定義:

metrics_documentation:
  - name: "dau"
    display_name: "アクティブユーザー数"
    definition:
      business: "指定期間内にアクティビティを行ったユニークユーザー数"
      technical: "is_active = TRUE かつ is_admin = FALSE の user_id を COUNT DISTINCT"
    specification:
      data_source: "user_activity"

  - name: "post_user_cnt"
    display_name: "投稿ユーザー数"
    definition:
      business: "指定期間内に投稿アクションを行ったユニークユーザー数"
      technical: "action_type = 'post' の user_id を COUNT DISTINCT"
    specification:
      data_source: "user_activity"

なぜ Skill が維持コストを下げるのか

従来の指標定義管理と Skill ベースの管理を比較します。

なぜ Skill が維持コストを下げるのか

特に重要なのは、Skill にルール（ガイドライン）が組み込まれている点です。命名規則、defaults の継承ルール、name / display_name の一意性チェックなど、従来は「知っている人にしかできない」作業が Skill に封入されているため、誰が実行しても同じ品質の出力が得られます。これは属人化の解消に直結します。

Skill のカスタマイズ性

Skill は Markdown ベースのプロンプトなので、組織固有のルール追加が容易です。

# SKILL.md に追加するルールの例

## 組織固有ルール
- display_name は「〜数」で終わる場合、英語の name は `_cnt` サフィックスを使用
- filters の deletion_condition は、削除系イベントがある指標には必ず記載
- detail フィールドには、関連するダッシュボード名を含める

ルールを追加・変更した時点から、以後のすべての生成に反映されます。コードの修正やデプロイは不要です。

データ処理パイプライン

```mermaid
flowchart TB
    A["*_semantic.yml（Git 管理）"] -->|main マージ時| B["CI/CD パイプライン"]
    B --> C["CSV 生成"]
    C --> D["CSV を BigQuery へアップロード"]
    D -->|翌日バッチ| E["Staging モデル"]
    E --> F["指標カタログ（整合性検証）"]
    F -->|BI メタデータと JOIN| G["metric_status レポート"]
```

  • `_semantic.yml` の変更は main ブランチへのマージ時に CI/CD で自動処理され、翌日のバッチ実行で整合性検証まで完了します。

今後の展望 — 人がデータに集中できる世界へ

現状の活用

現時点で `*_semantic.yml`は人間向けドキュメントであると同時に、AI エージェントのナレッジベースとしても機能しています。

現状の活用

この構造化されたメタデータが蓄積されることで、さらに多くの自動化が可能になると考えています。

Phase 1: QA の自動化 — 問い合わせゼロを目指す

現状、指標に関する質問はデータチームへの Slack や口頭での問い合わせが起点です。この導線自体を変え、ユーザーが自分で答えにたどり着ける仕組みを目指します。

```mermaid
flowchart TB
    subgraph Current["現状"]
        Q1["ビジネスユーザー<br>『この数値の定義は？』"] -->|Slack / 口頭| DE1["データエンジニア"]
        DE1 -->|SQL を調査| A1["回答<br>（数時間〜数日）"]
    end

    subgraph Future["今後"]
        Q2["ビジネスユーザー<br>『この数値の定義は？』"] -->|チャットで質問| Bot["QA エージェント"]
        Bot -->|semantic.yml を検索| A2["即時回答<br>（根拠付き）"]
        Bot -->|回答不能な場合のみ| DE2["データエンジニア<br>へエスカレーション"]
    end
```

たとえば「MAU に退会ユーザーは含まれていますか？」という質問に対して、QA エージェントは `*_semantic.yml`の `filters.withdrawal: "含"`を参照し、根拠付きで即座に回答できます。エージェントが回答できない未定義の指標だけが人間にエスカレーションされるため、データチームは QA 対応から解放され、本来の分析・モデリング業務に集中できます。

さらに重要なのは、エスカレーションを経て人間が回答した内容をナレッジとして蓄積し、QA エージェントの知識を継続的に成長させるフィードバックループです。

```mermaid
flowchart TB
    Q["ユーザーの質問"] --> Agent["QA エージェント"]
    Agent -->|定義あり| A1["即時回答<br>（semantic.yml を引用）"]
    Agent -->|定義なし| Esc["データエンジニアへ<br>エスカレーション"]
    Esc --> Human["人間が調査・回答"]
    Human --> Update["回答内容を<br>*_semantic.yml に反映"]
    Update -->|次回から自動回答| Agent
```
QA の自動化 — 問い合わせゼロを目指す

つまり、QA エージェントは使えば使うほど賢くなる仕組みです。エスカレーションの件数は時間とともに減少し、最終的には「定義されていない指標」＝「まだ誰にも聞かれたことがない指標」だけになります。暗黙知が一方通行で消費されるのではなく、形式知として蓄積・再利用されるエコシステムが構築されます。

Phase 2: 定義の自動同期 — 変更検知から定義更新まで

現在は Skill を手動で実行して定義を更新していますが、今後は以下のような自動化が考えられます。

定義の自動同期

これにより、「定義の更新を忘れる」という人的ミスを大幅に減らし、セマンティック定義を常に最新の状態に近づけることができます。

Phase 3: データプロダクトのセルフサービス化

セマンティック定義がメタデータ基盤として成熟すると、さらに上位の自動化が現実的になります。

  • 自然言語でのデータ探索: 「先月のアクティブユーザー数を部門別に見せて」→ エージェントがセマンティック定義から適切な指標・テーブルを特定し、クエリを生成

  • 指標の影響分析: あるテーブルのカラムを変更したとき、影響を受ける指標を定義ファイルから自動特定し、下流への影響範囲を可視化

  • オンボーディングの自動化: 新しいメンバーが「売上関連の指標を一覧で見たい」と聞けば、セマンティック定義を横断検索して関連指標のカタログを即座に提示

```mermaid
flowchart BT
    S["*_semantic.yml<br>セマンティック定義"] --> QA["QA エージェント<br>指標の質問に即時回答"]
    S --> Sync["自動同期<br>SQL 変更 → 定義更新"]
    S --> Explore["データ探索<br>自然言語 → クエリ生成"]
    S --> Impact["影響分析<br>カラム変更 → 下流指標特定"]
    S --> Onboard["オンボーディング<br>関連指標のカタログ提示"]

    QA --> Goal["データチームが<br>本来の業務に集中"]
    Sync --> Goal
    Explore --> Goal
    Impact --> Goal
    Onboard --> Goal
```

最終的に目指すのは、データチームが QA 対応やドキュメント管理に追われるのではなく、ビジネスに価値を生む分析・モデリングに集中できる環境です。セマンティック定義は、そのための土台となるメタデータ基盤です。

まとめ

まとめ

セマンティック定義は「ドキュメントを書く」という作業ではなく、「データプロダクトにメタデータというインフラを敷設する」行為です。この基盤が整うほど、人は繰り返しの QA 対応から解放され、データそのものに向き合う時間が増えていきます。

Communeについて

他の記事を読む


いいなと思ったら応援しよう！