Technology Architecture：Platform ServiceとRuntime Topologyを設計する
Technology Architectureはserver一覧ではありません。Applicationが必要とするcompute、network、identity、storage、database、delivery、observabilityを再利用可能なplatform serviceとして設計します。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Logical technology serviceとphysical resource
- Runtime・Deployment・Network topology
- Platform Engineeringと標準化
体験58 · PLATFORM / TOPOLOGY（基盤を製品として作る）
『PostgreSQLを使っている』と分かれば、Technology Architectureとしては十分か確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のruntimeと依存を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
『PostgreSQLを使っている』と分かれば、Technology Architectureとしては十分な情報だと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
製品名だけで、region・冗長化・監視・ownerは分かるでしょうか？
ヒント2を見る
Next.jsとJavaは、同じruntimeで動いているでしょうか？
もっと詳しく：この問いで使う専門用語
- Deployment Topologyは、componentをどの環境、zone、nodeへ配置するかです。
- Platform as a Productは、共通基盤を利用者・roadmap・SLO・supportを持つproductとして運営する考えです。
- Blast Radiusは、1つの障害や誤変更が影響する範囲です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Technology Architectureは製品一覧ではなく、runtime、network、identity、data、delivery、observability、operationsの構造です。
論理構成、platform構成、deployment、network、runtime、運用構成を分けると、責任と障害影響を正しく説明できます。
Platformを内部productとして標準化し、利用teamが安全なdefault、self-service、support、透明なSLOを使える状態を目指します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Deployment Topology
componentをどの環境、zone、nodeへ配置するかです。
latency、capacity、障害範囲、復旧を評価するためです。
Browser、Next.js、Java、Supabase/PostgreSQLの配置と経路を表します。
Platform as a Product
共通基盤を利用者、roadmap、SLO、supportを持つproductとして運営する考えです。
標準を強制文書でなく使いやすい能力として提供するためです。
認証、logging、CI、service templateを再利用可能にします。
Blast Radius
1つの障害や誤変更が影響する範囲です。
隔離、冗長化、段階releaseの設計基準になるためです。
Payment Service停止が参照機能やlegacy経路へ波及するか確認します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
Application要求をTechnology Serviceへ翻訳
| Application要求 | Technology Service | 具体例 |
|---|---|---|
| HTTPを受ける | Ingress / Routing | DNS、CDN、WAF、load balancer |
| codeを実行 | Compute Runtime | Node、JVM、container、serverless |
| identityを確認 | Identity / Key | OIDC、MFA、KMS、HSM |
| 状態を保存 | Database / Storage | PostgreSQL、object storage、backup |
| 非同期連携 | Messaging | queue、stream、dead letter |
| 変更を配布 | Delivery | artifact registry、CI/CD、policy |
| 状態を知る | Observability | metric、log、trace、audit |
LogicalとPhysicalを分ける
『PostgreSQLを使う』だけでは、region、HA、backup、connection、patch、暗号化、監視、ownerが未定です。
| View | 問い |
|---|---|
| Logical | どのtechnology capabilityが必要か |
| Product | どのservice / softwareで実現するか |
| Deployment | artifactをどこへ何個配置するか |
| Network | zone・route・trust boundaryはどうか |
| Runtime | request時にどのinstanceとdependencyを通るか |
| Operations | 誰がmonitor・patch・recoverするか |
Platform as a Product
- Golden path：安全なservice雛形とpipeline
- Self-service：環境、secret、database、observabilityを申請可能
- Guardrail：policy as code、image・dependency・network control
- Paved road：標準内なら速く、例外は明示review
- SLO：platform自体のavailability・lead time・support
- Feedback：developer experienceとincidentから改善
Minibank Technology Topology
実際のhosting region、冗長構成、network segmentation、backup、secret rotation、WAF、SIEMはrepositoryだけでは完全に確認できません。architecture inventoryはcode外のcloud設定も含めます。
- 01Browser
- 02Next.js Node runtime
- 03Spring Boot JVM（追加経路）
- 04Supabase edge / Auth / PostgREST
- 05PostgreSQL schemas and functions
- 06Ledger / Audit / Reconciliation storage
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Deployment TopologyとPlatform as a Productの考え方を読んだところで、教材内の参照元で実際のruntimeと依存を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずNext.js側のruntime依存を見て、次にSupabaseが担う複数のTechnology Serviceを見ます。
教材の参照元を確認する — Source Trail ↓Node / Next.js technology dependencies。
package.jsonSupabase local technology configuration。
supabase/config.toml - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜTechnology Architectureでは、製品名だけでなくregion・冗長化・監視・ownerまで明確にする必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Deployment Topology」という言葉を使って書いてみましょう。
ヒント2を見る
1つのproviderに複数のTechnology Serviceが集約される影響を考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Deployment Topology、Platform as a Product、Blast Radiusの3つを使って、Technology Architectureが製品一覧ではない理由を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 製品名だけでは責任・障害範囲が分からないと説明できる
- 1つのproviderへ複数のTechnology Serviceが集約されていると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1cloud製品名を並べればTechnology Architectureですか？
違います。責任、接続、identity、data、capacity、障害、運用、lifecycleを表します。
Q2共通platformは利用を義務化すれば成功しますか？
成功しません。安全なdefault、利用体験、support、feedback、価値測定が必要です。
Q3Minibankのtopologyで不足しやすい情報は何ですか？
環境分離、secret境界、zone、capacity、egress、監視、backup・restore責任です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- The Open Group — ArchiMate and TOGAF
Business・Application・Data・Technologyを横断して可視化する考え方
- 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
package.jsonNode / Next.js technology dependencies - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/pom.xmlJava / Spring runtime dependencies - 現在の実装 — CURRENT IMPLEMENTATION
supabase/config.tomlSupabase local technology configuration