【2025年版】【図解】メタデータ管理とは？｜用語集とイベント定義をゼロから作る10ステップ

朝の定例で「アクティブは昨日比−3%」と誰かが言い、別の誰かが「それ、閲覧だけも入ってます？」と返す——途端に空気が止まって会議が延びる。原因は難しい分析ではなく、言葉の意味が人によって違うことです。
結論：メタデータ管理とは、用語の意味・計算式・イベント名を“最新版ひとつ”に揃え、誰が見ても同じ数字になる状態を作る運用です。

意思決定と価値づくりの全体像は課題解決型PdM 完全ガイド／価値提供型PdMの設計図で土台から確認できます。

1. なぜ今すぐ必要？（ねらい→やり方→失敗と直し方）

ねらいは「同じ言葉で同じ判断」を再現すること。やり方は、用語集（データ辞書）とイベント定義を作り、命名規約と変更フローで維持すること。失敗は、BIツールの見た目調整から入ってしまうこと。直すなら、まず“言葉と式”を1箇所に固定し、全てのダッシュボードをそこへ紐づけます。

2. まず押さえる3要素：用語集／イベント定義／命名規約

土台はこの3つ。特にイベント定義は「Aha（初回価値）」「翌日活性（D1）」の2本を最初に確定すると運用が一気に回ります。

• 用語集（データ辞書）：言葉の意味と計算式の“最新版”。
• イベント定義：どの操作がどのイベント名で記録されるかの契約。
• 命名規約：snake_case/kebab-case、接頭辞、過去形の扱いなど統一ルール。

3. 用語集テンプレ（コピペOK：Notion/スプレッドシート）

まずは20語から。PdMが読む前提で“体験ベースの説明”にします。SQLが書けなくても読める形に。

【列構成】
用語｜説明（ユーザー体験）｜計算式/SQLの要約｜イベント/列名｜責任（R/A/C/I）｜施行日｜最終更新

【例】
Aha達成率｜初回の“価値が出た瞬間”を体験した割合｜save_success を1回以上記録したユーザー/当日利用ユーザー｜event=save_success｜PdM=R Data=A Eng=C CS=I｜2025-09-01｜2025-09-01
翌日活性（D1）｜Aha翌日に“直行”で戻った割合｜Aha達成翌日に resume_opened を記録/当該Aha達成ユーザー｜event=resume_opened｜PdM=R Data=A Eng=C CS=I｜2025-09-01｜2025-09-01
TTV P50｜初回起動→Aha達成までの中央値｜percentile_50(timestamp(save_success)-timestamp(first_open))｜first_open/save_success｜PdM=R Data=A Eng=C CS=I｜2025-09-01｜2025-09-01

4. イベント定義ひな形（そのまま貼るだけ）

イベントは“体験の境目”で切るのがコツ。クリックではなく価値の発生（保存成功など）で定義します。

【イベント定義（最小セット）】
name: save_success
desc: 初回価値の達成（例：保存が成功し成功トースト表示）
props: { content_type, template_id, source("web","app"), plan }
rules:
  - 同一セッション内の連続成功は1回に集約
  - 成功トースト表示と同時に発火（失敗時は発火させない）

name: resume_opened
desc: Ahaの翌日に“直行”で再開した
props: { deeplink("continue"), from_notification(bool) }
rules:
  - Aha当日の再来は含めない（翌日00:00以降）
  - 直行導線（ボタン/通知リンク）経由のみを母数にする

name: first_open
desc: 初回起動のタイムスタンプ
props: { platform, version }
rules:
  - webは初回cookie/ログイン時刻、appは初回インストール/初回起動

5. 命名規約（最小の決め方）

命名の揺れは再発の元。最初にルールを書いておくと、データ追加のたびに迷いが消えます。

• イベント名：過去形の動詞＋成果（例：save_success）。
• プロパティ：スネークケース、単位を含めない（elapsed_sec など例外のみ）。
• カテゴリ：onboarding_* のように接頭辞でまとまる粒度に。

6. 変更フロー（申請→レビュー→承認→反映→告知）

定義は変わり続けます。大事なのは“正しく早く変えられる道”。テンプレはこれで足ります。

【申請フォーム項目】
対象用語/イベント｜現行定義｜変更案｜理由（不整合/品質/計測追加）｜影響範囲（ダッシュボード/PRD）｜希望施行日｜担当

【告知テンプレ（Slack #release-data）】
対象：Aha達成率（save_success）
変更：連続成功の重複を集約
施行：2025-09-05 00:00
影響：Aha達成率 −1.2pp 程度（過去比較は施行日で分割）

7. 10ステップ導入ロードマップ（ゼロから）

大掛かりなDWHや専用ツールは後回し。まずは“回る最小”を形にします。1〜3は今日中に可能です。

1. 用語集シートを作成（列は「用語/説明/式/イベント/責任/施行日/最終更新」）。
2. Aha、翌日活性、TTVの3語だけ先に埋める。
3. イベント定義3本（first_open/save_success/resume_opened）を確定。
4. 命名規約を1ページで明文化（イベント名/プロパティ/カテゴリ）。
5. 変更フローの申請フォームをNotion/Googleフォームで用意。
6. Slackに #release-data を作成、告知テンプレをピン留め。
7. ダッシュボードの計算式を用語集の式に差し替え（参照リンクで紐付け）。
8. PRD断片に「定義カードの版のみ採用」を明記。
9. 週次で“差分（+pp/−分）”の読み上げ→撤退/継続/新規の入替をログ化。
10. 施行日を境にグラフを分割表示し、巻き戻りを防止。

8. よくある落とし穴と回避策

現場で必ず出る“つまずき”に先回りしておきます。迷ったら「定義カードに戻る」が合言葉です。

• クリックをAhaにしてしまう：価値の発生（保存成功など）で定義する。
• 翌日活性の母数が日によって違う：「Aha翌日の直行のみ」を母数に固定。
• 施行日が曖昧：定義カードに必ず施行日を記録、グラフ分割は必須。
• PRDに定義が未反映：PRDレビューのチェック項目に「定義カードURL」を追加。

Aha→TTV→翌日活性の並べ方はKPI設計と運用ガイドが最短です。

9. 会議10分台本＆Slack定型文（読み上げで終われる）

説明会をやめ、判定会に。差分で言い切り、変更は“施行日つき”で告知します。

【会議10分台本】
[00-02] 先週差分：Aha +pp／TTV −分／翌日活性 +pp（施行日またぎは分割）
[02-05] 定義変更の報告（対象・理由・影響・施行日）
[05-08] PRD断片の更新（定義カードURLを追記）
[08-10] 撤退/継続/新規の入替宣言（5行ログに記録）

【Slack定型文】
定義カードを更新：Aha達成率（重複集約）。施行=9/5。
今週KR：Aha +5pp／TTV −2分／翌日活性 +4pp。撤退条件はAha +3pp未満×TTV悪化。

10. 今日から使える“完成チェックリスト”

この5つが揃っていれば、メタデータ管理は回り始めています。足りない項目から埋めましょう。

□ 用語集（20語）は最新版が1つに集約されている
□ イベント定義（first_open/save_success/resume_opened）が合意済み
□ 命名規約があり、新規データ追加時に参照されている
□ 変更フロー（申請→承認→施行→告知）が実行された実績がある
□ ダッシュボードは“用語集の式”を参照し、施行日で分割されている

FAQ（見えるブロック）

Q. 専用のデータカタログツールがないと始められませんか？

A. いいえ。まずはNotion/スプレッドシートで十分。重要なのは“最新版が1つ”という運用です。

Q. Ahaの定義がチームで議論になります。

A. 体験ベースの文（例：「保存が成功し成功トーストが表示された瞬間」）で先に合意し、SQLは後追いで構いません。

Q. 定義を変えると過去比較が壊れます。

A. 施行日でグラフを分割し、「前後は別系列」として扱います。告知テンプレで影響幅を明記してください。