データの意味付けは後からでいい AIに聞けば答えが出る時代のデータ管理

一言でいうと

アプリの計測は、全部の機能・画面に意味を付けてから使う、のではなく、
聞かれた(計測したくなった)ものから順に意味が付いていく。
AIが答えを出せる時代、メタデータ管理は「事前の設計」から「事後の蒸留」に変わる。

前提:計測ツールには「事実」しかない

Pendoみたいなプロダクトアナリティクスを入れると、アプリ上のオブジェクトが自動でタグ付けされます:

• Feature:「新規作成ボタン」「共有ダイアログを開いた」…
• Page:「ダッシュボード」「ドキュメント編集画面」…
• Segment:「有料アカウント」「トライアル中」…

これは事実です。「このボタンが押された回数」は分かる。でも——

• 「アクティベーション率どう?」と聞かれても、計測ツールはうちの会社がアクティベーションをどう定義しているか知らない
• 「新規作成ボタン」と「共有ダイアログ」が両方揃って初めてアクティベーション、という関係が、どこにも書かれていない

つまり計測ツールには事実(オブジェクト)はあるが、意味(オブジェクト同士の業務的な関係)が無い。

従来のやり方:事前設計(そして死ぬ)

この「意味」を持たせようとすると、従来はこうでした:

• 指標体系を先に設計する(「アクティベーションとは何か」を決める会議)
• 全Featureに事前に「これは活性化指標」「これは定着指標」とタグ付け
• 使う日が来るのを待つ

結果:コストは莫大、定義はすぐ変わる(先週と今週で「アクティベーション」の中身が違う)、そして付けた分類の大半は一度も使われない。何に意味を付けるべきかを、需要が発生する前に推測しているからです。

考え方を3層に分ける

┌────────────────────────────────────┐
│ ③ 計算値の層(塗るだけ)              │ ← 今週の利用量、KPIの現在値
├────────────────────────────────────┤
│ ② 意味の層(あとから育てる)          │ ← 「アクティベーション」「定着」
├────────────────────────────────────┤
│ ① 事実の層(自動で同期)             │ ← Feature/Page/Segment/利用ログ
└────────────────────────────────────┘

• ①事実:Pendoから同期したFeature/Page/Segmentと利用ログ。自動、コストほぼゼロ。
• ②意味:「アクティベーション」のような業務概念。計測ツールのどこにも書いていない。これが高くつく部分。
• ③計算値:意味の上に数字を塗る(この概念の今週の実績、など)。

ポイントは、高くつく②だけを後払いにすること。

②「意味の層」= タグではなく「コンセプト」

ここが一番の肝なので、少し丁寧に。②で貼るのはタグではありません。両者は根本的に違います。

• タグは「オブジェクトに貼るラベル」。共有ダイアログを開いた → Feature。1対1で、そのオブジェクト単体の属性しか言わない。
• コンセプトは「業務ゴールを中心にした、関連の束」。1つのまとまりに、こう持たせます:

コンセプト「アクティベーション」
├─ 定義   :サインアップ後14日以内に「ドキュメント作成」と「共有」を両方やったアカウントの割合
│                                                        ← チームが合意した文章
├─ 測定対象:新規作成ボタン、共有ダイアログ、ウェルカムツアー   ← Featureへの「関連」
├─ 原因   :オンボーディングフローの変更、流入チャネルの構成変化  ← なぜ動くか
├─ アクション:テンプレートを初回導線に組み込む               ← 動いたら何をするか
└─ 検証済みクエリ:この概念を計算する再現可能なDSL            ← 毎回ブレない計算方法

決定的な違いは、**タグはオブジェクトの属性、コンセプトはオブジェクトとゴール・オブジェクト同士の「関係」**だということ。だから計測ツールの「1カラム」には収まりません — グラフの「辺(エッジ)」なんです。具体的には:

• 1つのコンセプトが複数のFeatureにまたがる(アクティベーション = 作成 + 共有 + ツアー)
• 1つのFeatureが複数のコンセプトに属す(共有ダイアログは「アクティベーション」でもあり「コラボ定着」でもある)
• 属性じゃないから、オブジェクトを見ても意味は分からない。関係を張った人の頭の中と、日々の質問の中にしかない

そして、この「関係として持つ」ことがAIに効きます。「アクティベーション率は?」と聞いたとき、Feature名に"activation"の字が一切入っていない「共有ダイアログ」まで正しく含めて計算できるのは、字面ではなく関係で結んでいるから。タグ(=字面のラベル)では絶対に届かない部分です。

言い換えると——②で「後から価値づけする」とは、オブジェクトに札を貼ることではなく、ゴールを起点にオブジェクト同士の関係を1本ずつ張っていくこと。これが高くつく理由でもあり(関係は自動では分からない)、後払いにできる理由でもあります(聞かれて初めて、どの関係が要るか分かる)。

ストーリー:「アクティベーション」が生まれるまで

Day 1 — PdMがAIに聞く:「新機能のアクティベーションってどうなってる?新機能はXXXとZZZ。アクティベーションとは。。。」
AIが利用ログを見て答える:新規作成して共有まで進んだ人はこれくらい、詰まってるのはこの手前…。

ここで起きたことに注目。「アクティベーション」という概念と、それを測るFeature群の関連が、いま一度導出された。従来ならこの洞察はチャットの流れと一緒に消えます。

Day 2 — その導出を保存する。これが「後からの価値づけ」。上の「コンセプト」の箱がそのまま1つ保存されます。定義も、どのFeature IDで測るかも、原因仮説もアクションも込みで。

Day 30 — 「今週のアクティベーション率は?」
AIはコンセプトを1回引くだけ。検証済みの定義と正しいFeature IDで即答。毎回ゼロから「アクティベーションとは何か」を再解釈しないので、速くて安いし、何より定義がブレない(先週と今週で中身が変わらない)。

Day 90 — 使われていないマイナー機能には、まだ何の意味も付いていない。それでいい。誰も計測したがらなかった=意味付けのコストを払わずに済んだ、という正しい結果です。

なぜ「後から」が成立するのか(3つの理由)

1. 質問が需要を教えてくれる
   何に意味を付けるべきかは、聞かれた順に分かる。事前の指標設計会議は推測でしかない。

2. AIが導出コストを下げた
   意味の候補(定義・該当Feature・原因仮説)はAIが数秒でドラフトできる。しかも過去の質問ログから「このチームは何を気にしているか」を読み取れるので、人間の仕事はレビューして採用するだけ。

3. 固定化そのものに価値がある
   AIは毎回答えを導出できるが、毎回導出するとブレる・遅い・高い。良い導出が出た瞬間に組織の合意としてキャッシュする操作 — それが「価値づけ」の正体。

ただし前提がひとつ:構造だけは先に

意味を後から貼るには、貼り先のIDが安定している必要があります(「共有ダイアログ」のFeature IDが来月も同じものを指す)。だからDay 1にやるのは①事実の層の自動同期だけ。これは安い。高い②は需要が来てから。

一般化:アプリでなくても同じ

やることは全部同じ:事実は同期、意味は質問から蒸留して後付け、数字は塗るだけ。

そして意味の層は構造化データなので、次にAIに聞くときそのままコンテキストとして渡せる。使うほど賢くなるループが回り始めます。