データ標準化戦略
意味の不一致を断つ標準化の目的
標準化は「すべてを同じ形式に揃える」より、「意味の運搬性を高める」活動です。部署ごとに定義が違うKPI、チャネルで増殖する顧客ID、通貨やタイムゾーンの混在——分析や機械学習の大半の摩擦はここにあります。共通語彙とIDの約束を先に決めると、ETLやダッシュボードは自然と短く、壊れにくくなります。生成AIや自動化も効果が上がります。たとえばスキーマが整っていれば、ChatGPTやClaudeでメタデータ説明の初稿を即時に起こせますし、Copilotで検証クエリの雛形を安全に生成できます。逆に標準がないと、どのAIも“正解”を提案できず、手戻りが増えます。
設計の要点：コアモデルとID戦略をまず固める
コアエンティティとイベントの骨格
最初に全社で不変なコアを合意します。推奨は「Customer / Product / Order / Payment / Organization」に加えて、時系列分析のための「Event」。Eventは最低限、who（customer_id）・what（event_name）・when（event_time, timezone）・where（source）・value（amount, currency）を共通化します。命名はsnake_caseで、単位とドメインはカラム名に含めます（amount_jpy, distance_m など）。
ID戦略と単位・時刻
- IDは「グローバルID（surrogate）」と「ソース別の自然キー」を併記。マッピング表で解決し、衝突はnamespaceで回避します（email_sha256 などハッシュ基準の併用）。
- 時刻はイベント受信時刻（ingested_at）と事象時刻（occurred_at）の二軸を必須化。タイムゾーンはIANAで保存、集計時に明示変換。
- 通貨はISO 4217、金額は小数の桁を固定（DECIMAL 38,9 など）。税区分はprice_ex_tax / tax_amountを分離。
- 履歴はSCD2を基本に、変更理由（change_reason）を必須化。人格統合は別テーブル（identity_resolution）に切り出し、ルールと信頼度を記録。
ビジネス語彙の合意
「新規顧客」「アクティブ」「解約」など曖昧語はデータ辞書で定義。頻度（7日/28日）、閾値、除外条件を文章とSQLの両方で固定します。最初の草案はChatGPTやClaudeに箇条書きを投げて下書きを作り、最終判断はドメインオーナーが行うと効率的です。
運用の仕組み：データ契約と検証・バージョン管理
データ契約（Data Contract）
各ソースはスキーマ、型、nullable、値域、配信SLAを契約として宣言。契約はGitでバージョン管理し、変更はPull Requestで審査します。スキーマの破壊的変更（例：型変更、必須化）はsemverのメジャーアップ、非破壊はマイナーに。移行期間（deprecation window）は最低2スプリント確保します。APIやETLの自動ドキュメント化はGeminiなどで要約し、実装差分をレビューに添付すると意思決定が速まります。
自動検証とリネージ
- スキーマ検証：CIでサンプルとプロファイリングを走らせ、欠損・外れ値をアラート。
- ビジネステスト：重要KPIの恒等式（売上=明細合計、在庫=前日在庫+入荷-出荷など）を毎日検証。
- リネージ追跡：列レベルでデータの流れを可視化し、影響範囲を自動推定。
- 承認フロー：破壊的変更はドメイン・分析・SREの三者承認を必須化。
導入90日プラン（現実解）
- 週1–2：重要KPIを3つに絞る。対象ソースと壊れやすい列を棚卸し。
- 週3–4：語彙とEvent命名規約の草案。トップ10イベントだけ先行合意。
- 週5–8：マッピング表とID解決を実装。既存ETLは壊さず「標準ビュー」を横に置くストラングラー方式。
- 週9–12：契約のCI導入、警報運用。破壊的変更の申請フォーマットを整える。ダッシュボードを標準ビューへ段階的に切替。
評価指標は「ダッシュボード作成リードタイム」「スキーマ変更の復旧時間」「データ鮮度SLA遵守率」。改善が進むほど、開発や分析の待ち時間が体感で短くなります。
身近な企業活用例：生活雑貨ECのやり直しから学ぶ
広告、店舗、ECで顧客IDが分裂し、商品カテゴリも部署ごとに違い、レポート作成に2日かかっていました。最初は「一括マイグレーション」で全パイプラインを置換しようとして失敗。既存依存が多すぎて、在庫レポートが1週間止まる事故に。
方針転換して標準化を段階導入。まずEventの共通枠（purchase、view_item、refund）を定義し、IDはsurrogateのcustomer_uidを新設。メールと会員IDはidentity_resolutionでひも付け。価格はamount_jpyとtax_amountで分離。ソース各チームとデータ契約を締結し、破壊的変更はメジャー版で申請する運用に。語彙の草案はChatGPTとClaudeで作って議論のたたき台にしました。SQL検証の雛形はCopilotで補助し、API変更のドキュメント要約はGeminiでスピード化。
結果、ダッシュボード作成リードタイムは2日→半日、広告の重複配信が減ってCPAが12%改善。解約分析も「初回30日以内の未接触」セグメントが可視化され、オンボーディング施策でLTVが6%上昇。事故後も、破壊的変更は申請からデプロイまで平均3日で安定運用されています。大きく作り直すのではなく、標準ビューを横に立て増しして差し替えるのが実務的でした。
データ標準化は、分析だけでなくUI、SDK、ML、生成AI連携の共通土台になります。データ解析プラットフォーム事業では、この土台が堅いほど、新機能や新規連携を安全に素早く積み上げられます。標準は「縛り」ではなく、変化を速く受け止めるためのインターフェースだと捉えるのが現場での勝ち筋です。
