Information Architecture：Conceptual Model・Metadata・Lineageをつなぐ
table定義だけではdataの意味を守れません。業務概念からlogical・physical modelへ落とし、metadataとlineageで生成・変換・利用を追跡します。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Conceptual・Logical・Physical model
- Business・Technical・Operational metadata
- Data lineageと変更影響分析
体験56 · METADATA / LINEAGE（意味と来歴をつなぐ）
table定義（column名と型）さえ揃っていれば、データの意味は十分に伝わるか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のschemaとlineageの例を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
table定義（column名と型）さえ揃っていれば、データの意味は十分に伝わると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
column名と型だけで、その値がどこから来たか分かるでしょうか？
ヒント2を見る
振込金額は、requestから画面表示までどんな経路をたどるでしょうか？
もっと詳しく：この問いで使う専門用語
- Conceptual Modelは、業務の主要概念と関係を技術から独立して表します。
- Metadataは、dataを理解し管理するためのdataです。
- Lineageは、dataの発生源、変換、移動、利用先のつながりです。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Conceptual、Logical、Physical、API modelは目的が違い、相互に追跡できることが重要です。
Metadataは名前と型だけでなく、業務意味、owner、機密性、品質rule、lifecycle、利用状況を含みます。
Data Lineageは値がどこから来てどう変換され、どの報告・判断へ届いたかを説明します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Conceptual Model
業務の主要概念と関係を技術から独立して表します。
関係者が共通言語を持つためです。
Customer、Account、Transfer、Journal、Auditの関係を表します。
Metadata
dataを理解し管理するためのdataです。
列名だけでは意味、責任、機密性、品質を判断できないためです。
account_idの意味、owner、分類、保持期間を記録します。
Lineage
dataの発生源、変換、移動、利用先のつながりです。
誤りの影響、規制報告の根拠、変更impactを説明するためです。
transfer requestからjournal、balance表示、auditまで追跡します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
3段階のData Model
physical tableから業務意味を推測すると、同名異義・暗黙code・nullable理由を誤ります。conceptualからtraceします。
| Model | 表すもの | 例 |
|---|---|---|
| Conceptual | 業務概念と関係 | Customer owns Account; Payment posts Journal |
| Logical | 属性、identifier、cardinality、rule | Payment has amount/currency/status |
| Physical | table、column、type、index、partition | transfer_requests.amount bigint |
| API / Event | 境界で共有するprojection | CreatePaymentResponse、payment.completed |
Metadataはdataを使えるようにするdata
| Metadata | 例 |
|---|---|
| Business | 用語、owner、定義、計算、policy |
| Technical | schema、type、key、lineage、API |
| Operational | freshness、volume、quality result、job status |
| Security | classification、access、masking、retention |
| Governance | approval、exception、issue、certification |
Lineageで事実を逆向きに追う
障害時には逆向きに、source変更がどのreport・API・model・顧客表示へ影響するか追います。column lineageだけでなく、業務ruleと手作業変換も対象です。
- 01経営reportのrisk exposure
- 02集計metricと計算version
- 03warehouse table / pipeline
- 04source application field
- 05business transaction / original event
- 06入力・判断・actor・timestamp
Minibank Lineage演習
教材のrelated codeは小さなlineageです。実運用ではschema・pipeline・dashboard・owner・quality resultまでmachine-readableに結びます。
| 表示・判断 | 追跡経路 |
|---|---|
| 口座残高 | UI→account API→cached_balance→journal集計との照合 |
| 振込完了 | response→transfer→request/OTP→journal→audit |
| Trial Balance | admin UI→aggregation→ledger accounts/lines |
| Integrity Issue | admin UI→check run→detector query→source records |
| Java failureReason | DTO→Gateway→SQLSTATE→PostgreSQL RAISE |
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Conceptual ModelとLineageの考え方を読んだところで、教材内の参照元で実際のschemaとlineageの例を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずAPI向けのschema定義を見て、次にDB側の変換ruleを見ます。同じ金額がどう複数の記録へ伝播するかを確かめましょう。
教材の参照元を確認する — Source Trail ↓API寄りのphysical schema。
src/domain/transaction/schema.tsphysical modelと変換rule。
supabase/migrations/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜtableの物理定義だけでなく、業務概念からの対応関係（lineage）を追える必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Lineage」という言葉を使って書いてみましょう。
ヒント2を見る
物理的なtable定義と業務概念のどちらが先に決まるべきか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Conceptual Model、Metadata、Lineageの3つを使って、データの意味を守る方法を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 物理定義だけでは意味を保証できないと説明できる
- 1つの値が複数の記録へどう伝播するか追跡できると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1ER図だけでData Architectureを表せますか？
不十分です。意味、owner、flow、quality、security、lifecycle、利用先も必要です。
Q2lineageはtable間のcopyだけですか？
違います。計算rule、code version、手動補正、report・AI利用まで含めます。
Q3Minibankでlineageを試す題材は何ですか？
振込金額がrequestからvalidation、journal、残高、audit、画面表示へ届く経路です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- Basel Committee — BCBS 239
risk data aggregationを支えるdata architecture、accuracy、integrity、completeness、timeliness
- The Open Group — TOGAF Standard, 10th Edition
Enterprise Architectureの方法、領域、governance、migration planningの基礎
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/domain/transaction/schema.tsAPI寄りのphysical schema - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/src/main/java/com/minibank/payment/domain/Java domain projection - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/physical modelと変換rule