データ分析のための「保持設計」完全ガイド：まず粒度と期限を決めよう

リード文：分析できるデータ基盤を作るには、保存先より先に「何をどの粒度で、どれくらいの期間、どの目的で保持するか」を決めるのが最短ルートです。

データ保持設計の主役（最初にここだけ押さえる）

データ保持設計を一言でいうと、「未来の意思決定に使える形で、コストとリスクを管理しながらデータを残す設計」です。冷蔵庫の作り置きに例えるとわかりやすく、全部を同じ容器で同じ日数保存すると、腐るもの・使えないもの・場所を取るものが混ざって破綻します。分析データも同じで、イベントログ・集計済み指標・個人情報を同じ扱いにすると、いずれ「重い・高い・危ない」の三重苦になります。

この設計でできることは次の3つです。第一に、再分析できる粒度を残せること。第二に、不要データを期限で削除できること。第三に、監査や説明責任に耐えることです。

動機

「とりあえず全部保存しておけば後で使えるはず」と考えて始めた基盤が、半年後にクエリが遅く、ストレージ費用が高く、誰も定義を説明できない状態になるのはよくある話です。逆に集計値しか残していないと、分析軸を変えたいときに打ち手がなくなります。つまり問題は保存量ではなく、保存の設計不在です。

仮説

うまく回るチームは、技術選定より前に次の4層を明確に分けています。

1. 生データ層（Raw）
2. 正規化層（Clean）
3. 集計層（Mart）
4. 公開層（BI/API）

この4層ごとに「保持期間」「更新頻度」「削除ルール」「アクセス権」を固定すれば、分析速度と統制を両立できるはずです。

検証：保持設計は「目的→粒度→期限→責任」の順で決める

結論から言うと、先にストレージ製品を選ぶのではなく、次の順序で決めると失敗しにくいです。

1) 目的を固定する

最初に「このデータで何を判断するか」を1文で定義します。例：

• 施策別のCVR改善を週次で判断する
• 解約予兆を30日以内に検知する
• 障害兆候を5分単位で監視する

目的が曖昧なままでは、必要粒度も保持期間も決まりません。

2) 粒度を分ける（イベントと集計を混ぜない）

分析用途では、少なくとも次の2種類を分離します。

• イベント粒度（明細）：再集計や探索分析の源泉。柔軟性は高いが重い
• 集計粒度（日次・週次）：ダッシュボード向け。高速で安いが再利用性は低い

ここで「後で困る」の多くは、明細を捨てすぎるか、逆に明細を無期限保存してしまうかのどちらかです。

3) 保持期間をレイヤー別に決める

保持期間は一律ではなく、再分析価値と法務・コストで分けるのが定石です。

レイヤー	主用途	推奨保持期間の目安	注意点
Raw（生ログ）	再処理・監査	90日〜1年	個人識別子の暗号化・マスキングを前提にする
Clean（整形済み）	分析基盤の再現性	1年〜3年	スキーマ変更履歴を残す
Mart（集計）	KPI監視・意思決定	3年〜5年	指標定義（Metric定義書）をセットで管理
監査ログ	操作追跡	1年〜7年（規制依存）	法令・業界基準に合わせて別管理

上の期間はあくまで初期値で、実際は業界規制・契約要件で最終決定してください。

4) 削除を「手動運用」にしない

「削除ルールはあるが誰も実行していない」は事故の入口です。保持は保存だけでなく削除まで含めて完成です。最低でも以下を自動化します。

• パーティション単位のTTL削除
• コールドストレージへの自動アーカイブ
• 削除実行ログ（いつ、何を、誰の承認で）

5) メタデータを先に作る

データ本体より先に、次のメタデータを管理すると分析チームの生産性が上がります。

• データ辞書（列名、意味、型、欠損定義）
• Lineage（どこから来てどこで使われるか）
• オーナー（障害時に誰が責任を持つか）
• 品質SLO（遅延、欠損率、重複率）

6) DWH / DM / マスターは「履歴の持ち方」を最初に決める

分析で後から困る代表例が、「現在値しかないマスター」です。たとえば顧客ランクや組織所属が更新で上書きされると、過去売上を「当時のランク・当時の所属」で再現できません。ここは最初に、どの単位で履歴を持つかを固定する必要があります。

実務では、次の3レベルを分けて考えると運用しやすくなります。

• DWH（統合層）: 変更履歴を保つ一次保管。再現性を優先する
• DM（利用層）: 目的別に最適化した配信テーブル。速度を優先する
• マスター管理（基準値）: コード体系・属性の正本。意味の一貫性を優先する

履歴管理の方式は、最低でも次のどれを採るか明示しましょう。

方式	向いている対象	長所	注意点
SCD Type 1（上書き）	誤記修正など過去差分が不要な属性	実装が単純、容量が小さい	過去時点の再現は不可
SCD Type 2（履歴行追加）	顧客ランク、所属、価格帯など時点再現が必要な属性	当時の状態を再現可能	JOIN条件（有効期間）の設計が必須
SCD Type 3（列追加）	直近の前状態だけ追えればよい属性	参照が高速	長期履歴には不向き

さらに、時系列の事故を防ぐには「2つの時刻」を分けるのが重要です。業務発生時刻（event_time）とDWH反映時刻（load_time）を別管理すると、遅延到着データや再処理時に整合性を保ちやすくなります。これは料理でいうと「食材を買った日」と「冷蔵庫に入れた日」を分けて記録する感覚です。

DWH・DM・マスター履歴管理の設計テンプレート

履歴管理をチームで統一するために、次のテンプレートを最初に合意しておくと迷いません。

1. エンティティごとの履歴要否
   例：顧客=要履歴、商品カテゴリ=要履歴、都道府県コード=原則不要
2. キー戦略
   業務キー（自然キー）とサロゲートキーを分離し、DM配信時はサロゲートキーJOINを基本にする
3. 有効期間カラム
   valid_from / valid_to / is_current を標準化する
4. 削除の扱い
   物理削除ではなく論理削除フラグを持ち、監査要件に応じて保持期限を定義する
5. 再処理ポリシー
   遅延データ到着時に「差分反映」か「期間再計算」かを業務単位で定める
6. DM配信ルール
   「最新スナップショットDM」と「時点再現DM」を分離して提供する

この6点が合意できると、分析側は「今の値を見るクエリ」と「当時の値で比較するクエリ」を安全に使い分けられます。

結果

保持設計をレイヤーで分離すると、次の変化が出やすくなります。

• クエリ速度：明細と集計の分離でBIクエリが安定
• コスト：古い明細を段階的にアーカイブし、ホット領域を圧縮
• 信頼性：定義書とLineageがあるため、数字の説明ができる
• 監査対応：削除証跡とアクセスログで説明責任を果たせる

考察

データ保持で最も重要なのは、「何を保存するか」より「何を捨てるかを設計する勇気」です。全部残す方針は一見安全ですが、実務ではノイズとコストを増やし、分析速度を下げます。逆に捨てすぎると学習も改善も止まります。だからこそ、層ごとに価値と期限を定義し、定期的に見直す運用が必要です。

加えて、DWH・DM・マスター管理では「履歴がないこと」自体が将来の負債になります。将来の比較分析や監査で必要になるのは、最新値ではなく「その時点で正しかった値」です。したがって、保持戦略と履歴戦略は別物ではなく、同じ設計書で同時に管理するのが実務的です。

💡 活用事例

例えばサブスク型サービスでは、プロダクトチームが「継続率の低下理由」を追う際、イベント明細が30日しかないと季節性の分析ができません。そこでRawを365日保持、Martを5年保持に変えたところ、前年同月比較が可能になり、キャンペーン効果の見誤りを減らせます。

また、B2B SaaSで監査要求が厳しい企業では、分析用テーブルとは別に監査ログを分離し、アクセス履歴を長期保管する構成が有効です。分析者の操作負荷を増やさず、監査部門の要件を満たせるため、部門間の衝突が減ります。

🔥 ハマりポイント（落とし穴と回避策）

最初の落とし穴は「ストレージが安いから無期限保存でも平気」という思い込みです。症状は、クエリ遅延と権限管理の崩壊。原因は、データ温度（ホット/コールド）を分けていないこと。対処法は、TTLとアーカイブを最初から設計することです。

次の落とし穴は「匿名化したから個人情報ではない」という過信です。症状は、別データとの突合で再識別リスクが生まれること。原因は、識別子管理の不備。対処法は、疑似匿名化キーのローテーションとアクセス制御の強化です。

三つ目は「KPI定義を口頭で共有している」状態です。症状は、同じ売上でも部署ごとに数字が違うこと。原因は、指標定義の未文書化。対処法は、Metric定義書をリポジトリ管理し、変更時レビューを必須化することです。

🚀 取り込み方（導入ステップ）

明日から始めるなら、大きく作り込む前に小さく固定しましょう。

• 今日（5分）: 主要KPIを3つ選び、それぞれに「必要粒度」と「必要保持期間」を1行で定義する
• 今週: Raw/Clean/Martの3層を分けた最小データフローを1本作り、TTL削除を1テーブルで試す
• 今月: データ辞書・Lineage・オーナー情報を整備し、運用レビュー（毎月）を定例化する

✅ 要点まとめ

データ分析のための保持設計は、保存先選定より先に設計すべき業務ルールです。ポイントは、目的を定義し、粒度を分け、保持期間を層別に決め、削除まで自動化すること。さらにメタデータ管理をセットにすると、分析スピード・コスト・監査対応を同時に改善できます。

参考文献

• DAMA-DMBOK（データマネジメント標準）
• NIST Privacy Framework
• ISO/IEC 27001 / 27701
• 各クラウドDWH（BigQuery / Snowflake / Redshift）公式ドキュメントのデータライフサイクル設計ガイド