Data QualityとLifecycle：取引から分析・AI・廃棄まで信頼を保つ
data品質は欠損率だけではありません。正確性、完全性、整合性、適時性、一意性、妥当性を業務利用ごとに定義し、生成から共有・分析・保管・廃棄まで管理します。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Data quality dimensionとrule
- Operational dataとAnalyticsの分離
- Retention・Archive・Deletion・Legal hold
体験57 · DATA QUALITY / LIFECYCLE（品質を保ち続ける）
CHECK制約やUNIQUE制約を設定しておけば、データ品質の管理はそれで完成するか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際の制約と分析処理を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
DBにCHECK制約やUNIQUE制約を設定しておけば、データ品質の管理はそれで完成すると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
制約は生成時点の予防ですが、保存後に起きるずれも防げるでしょうか？
ヒント2を見る
分析用の集計は、正式記録と同じ扱いをしてよいでしょうか？
もっと詳しく：この問いで使う専門用語
- Data Quality Dimensionは、用途に必要な品質を測る観点です。
- Data Lifecycleは、dataの作成・利用・共有・保持・archive・削除の全期間です。
- Reconciliationは、独立した記録や集計を突き合わせて差異を検出する統制です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Data Qualityは正確性だけでなく、完全性、一貫性、適時性、一意性、妥当性、traceabilityを用途ごとに定義します。
予防、検知、隔離、訂正、根本原因、再発防止のcontrol loopを持ち、dashboard表示だけで終わらせません。
生成から利用、共有、保管、archive、削除までのlifecycleと、運用data・分析dataの責任分界を設計します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Data Quality Dimension
用途に必要な品質を測る観点です。
『高品質』を検証可能な条件へ変えるためです。
journalの完全性、transferとの一貫性、auditの適時性を測ります。
Data Lifecycle
dataの作成、利用、共有、保持、archive、削除の全期間です。
無期限保有と早すぎる削除の両方のriskを管理するためです。
取引・audit・一時OTPで異なる保持ruleを設けます。
Reconciliation
独立した記録や集計を突き合わせて差異を検出する統制です。
予防controlを抜けた欠落や重複を発見するためです。
transfer、journal、cached balanceを定期照合します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
品質は利用目的に対して定義
品質目標は全data一律ではありません。決済、規制報告、marketing分析で必要水準と修正時間が異なります。
| Dimension | 振込・risk dataの例 |
|---|---|
| Accuracy | 金額・通貨・ownerが原取引と一致 |
| Completeness | materialな口座・取引が欠落しない |
| Consistency | transferとjournalの状態・金額が一致 |
| Timeliness | incidentやrisk判断に間に合う鮮度 |
| Uniqueness | 同一business eventを二重計上しない |
| Validity | 型・範囲・参照・状態遷移がrule内 |
| Traceability | source・変換・owner・時点を説明可能 |
Quality control loop
- 01Critical Data Elementを特定
- 02business ruleと閾値を定義
- 03生成地点で予防control
- 04pipeline・境界・保存後に測定
- 05issueへowner・severity・SLAを付与
- 06root causeをsource processへ戻す
- 07傾向と未解決riskをgovernanceへ報告
OperationalとAnalytics
分析側が業務DBへ重いqueryを直接実行したり、AI出力を正式記録へ直接書き戻したりしない境界を設計します。
| 観点 | Operational / SoR | Analytics / AI |
|---|---|---|
| 目的 | 取引を正しく処理 | 傾向・予測・報告 |
| model | 正規化・強いconstraint | 履歴・集計・feature |
| 更新 | transactional | batch / stream |
| consistency | 強い整合性が中心 | 定義した遅延と再計算 |
| access | 業務最小権限 | purpose・masking・sandbox |
| 訂正 | reversal / append | versioned recomputation |
Lifecycleと廃棄
LedgerやAuditはappend-onlyでも無期限保有を自動的に意味しません。法令・契約・privacy・証拠要件を整理し、削除不能性と保持責任を両立させます。
- Collection：目的・同意・最小化
- Use：許可目的・access・masking
- Share：recipient・contract・cross-border
- Retain：法令・契約・監査・業務の期間
- Archive：検索性・immutability・復元
- Legal hold：通常削除を停止
- Delete / Anonymize：primary・backup・copy・indexを対象
- Evidence：誰が何をいつ廃棄したか
Minibank Quality Controls
- CHECK・UNIQUE・FKでvalidityとuniquenessを予防
- transactionでtransferとjournalのconsistencyを保つ
- reconciliationで保存後の差異を検知
- auditでtraceabilityを確保
- testでnegative・concurrency・rollbackを検証
- 正式なretention・archive・deletion policyは未整備として区別
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Data Quality DimensionとReconciliationの考え方を読んだところで、教材内の参照元で実際の制約と分析処理を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずDB制約が何を予防しているかを見て、次に分析用の集計が別の派生であることを見ます。
教材の参照元を確認する — Source Trail ↓data constraintとreconciliation。
supabase/migrations/operational dataからの分析projection。
src/lib/analytics/monthlySummary.ts - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜData Qualityは生成時点の予防だけでなく、保存後の照合（Reconciliation）も必要なのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「予防」と「検知」という2つの言葉を使って書いてみましょう。
ヒント2を見る
Reconciliationが何を見つけるためのものか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Data Quality Dimension、Data Lifecycle、Reconciliationの3つを使って、data品質を発生源から利用先まで守る方法を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 予防だけでは保存後の差異を検知できないと説明できる
- 分析用dataは正式記録とは別の派生だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1constraintがあればData Qualityは十分ですか？
十分ではありません。意味、完全性、時間、外部整合、手動処理も検査します。
Q2分析用data lakeを新しいSoRにしてよいですか？
用途と統制なしにはできません。source、変換、鮮度、訂正経路を明確にします。
Q3差異を検出した後に必要なことは何ですか？
影響隔離、owner通知、統制された訂正、原因分析、再発防止、証拠保存です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- Basel Committee — BCBS 239
risk data aggregationを支えるdata architecture、accuracy、integrity、completeness、timeliness
- 金融庁 — 金融機関のITガバナンスに関する論点・プラクティス
経営戦略、IT戦略、DX戦略、次世代architecture、投資・risk・人材の統合
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/data constraintとreconciliation - 現在の実装 — CURRENT IMPLEMENTATION
src/lib/analytics/monthlySummary.tsoperational dataからの分析projection - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/integrity/quality issueの表示