日本銀行 Digital Twin 二部作⸻第1冊『日本銀行 Digital Twin』――政策委員会・全局室研究所・支店・事務所・法令・業務・システムを統合する中央銀行アーキテクチャ（第6回）（第5章　Dynamic Organization――縦割りを維持したまま横断する）

第5章　Dynamic Organization

――縦割りを維持したまま横断する

第1節　Functional Organization

日本銀行Digital TwinのOrganization Architectureは、ここまで一貫して、

[
\boxed{
Stable\ Vertical
}
]

を基礎としてきた。

政策委員会室。

検査室。

企画局。

金融機構局。

決済機構局。

金融市場局。

調査統計局。

国際局。

発券局。

業務局。

システム情報局。

情報サービス局。

総務人事局。

文書局。

金融研究所。

これら15局室研究所は、それぞれ異なる所掌、専門性、責任、Authority、Institutional Memoryを持つ。

したがって、本書が目指すのは、

[
\boxed{
Vertical\ Organization\ の解体
}
]

ではない。

むしろ、

[
\boxed{
Functional\ Organization\ として
専門性を維持しながら、
必要な時だけ横断的に接続できる構造
}
]

である。

⸻

Functional Organizationとは何か

Functional Organizationとは、組織を専門機能ごとに分ける構造である。

金融政策。

金融システム。

決済。

市場。

統計。

国際。

発券。

IT。

研究。

それぞれに専門的Capabilityを集中させる。

日本銀行の現在の局室研究所体制は、この考え方と高い親和性を持つ。

Digital Twinでは、この現実の組織構造を、

[
\boxed{
Function
\rightarrow
Department
\rightarrow
Capability
}
]

として記述する。

⸻

Functional Boundary

各局には、

[
\boxed{
Functional\ Boundary
}
]

がある。

例えば、

企画局は金融政策企画。

金融市場局は市場調節・市場実務。

金融機構局は金融システム。

決済機構局は決済・業務継続。

を中心に担う。

このBoundaryを消さない。

なぜなら、

[
Boundary
]

は分断の原因であると同時に、

[
\boxed{
責任の明確化
}
]

の源泉でもあるからである。

⸻

SiloとModuleの違い

縦割り組織には二つの状態がある。

一つは、

[
\boxed{
Silo
}
]

である。

情報が閉じる。

他部門と接続できない。

同じDataを重複保有する。

全体Processが見えない。

もう一つは、

[
\boxed{
Module
}
]

である。

専門性を保持する。

責任境界が明確である。

Interfaceが定義されている。

他Moduleと安全に接続できる。

本書が目指すのは、

[
\boxed{
Silo
\rightarrow
Module
}
]

への転換である。

⸻

Functional Module

各局を、

FunctionalModule
├── module_id
├── mandate
├── capabilities
├── responsibilities
├── authority
├── data_domains
├── business_processes
├── systems
├── interfaces
└── institutional_memory

として記述する。

これにより、その局が、

何を担うのか。

何を担わないのか。

どのDataをOwnerとして持つのか。

どのProcessに参加するのか。

が明確になる。

⸻

Primary Function

一つの局が多数の業務を持っていても、

[
\boxed{
Primary\ Function
}
]

を定義する。

例えば、

企画局であれば、

[
MonetaryPolicyDesign
]

金融市場局であれば、

[
MarketOperations
]

というように、Architecture上の中心Capabilityを置く。

これにより、全行横断ProjectでもPrimary Ownershipが曖昧になりにくい。

⸻

Supporting Function

一方で、一つのCapabilityが複数局にまたがる場合、

[
SupportingFunction
]

を定義する。

例えば金融政策では、

調査統計局。

国際局。

金融市場局。

金融機構局。

がSupporting Moduleになる。

したがって、

[
\boxed{
PrimaryOwner
+
SupportingModules
}
]

という関係になる。

⸻

Functional Organizationの強み

Functional Organizationの第一の強みは、

[
\boxed{
専門性の蓄積
}
]

である。

中央銀行業務は高度に専門化している。

市場調節。

決済。

統計。

発券。

国際金融。

システム。

これらを頻繁に組み替えると、Knowledgeが散逸する。

Stable Functionがあるからこそ、

[
InstitutionalMemory
]

を蓄積できる。

⸻

第二の強み――責任

第二の強みは、

[
\boxed{
Accountability
}
]

である。

誰がそのDomainの品質を担保するのか。

誰がDataを管理するのか。

誰がProcessを改善するのか。

が明確になる。

⸻

第三の強み――Control

第三の強みは、

[
\boxed{
Control
}
]

である。

Functionが明確であれば、

Access。

Approval。

Audit。

Segregation of Duties。

を設計しやすい。

高信頼Institutionでは重要である。

⸻

第四の強み――Resilience

Functional Moduleが分離されていれば、

一つのModuleで障害が起きても全体へ波及しにくい。

つまり、

[
\boxed{
Fault\ Isolation
}
]

を持つ。

組織面でもSoftware面でも同じである。

⸻

Functional Organizationの弱点

しかしFunctional Organizationには弱点もある。

課題が局境界を越える場合である。

例えば、

CBDC。

Cybersecurity。

Climate Risk。

巨大災害。

金融危機。

AI Governance。

これらは単一局では完結しない。

⸻

Cross-domain Problem

こうした課題を、

[
\boxed{
CrossDomainProblem
}
]

と定義する。

CrossDomainProblem
├── problem_id
├── affected_domains
├── required_capabilities
├── primary_owner
├── urgency
├── uncertainty
└── coordination_need

とする。

Functional Organizationが弱いのは、こうしたProblemに直面したときである。

⸻

Functional Organizationを捨てない

そこで多くの組織改革では、

「縦割りをなくそう」

となる。

しかし、それでは専門性と責任まで失う可能性がある。

したがって本書では、

[
\boxed{
FunctionalOrganization
+
DynamicHorizontal
}
]

を採用する。

⸻

PermanentとTemporary

Functional Organizationは、

[
\boxed{
Permanent
}
]

である。

一方、横断ProjectやTask Forceは、

[
\boxed{
Temporary
}
]

である。

この違いを明確にする。

⸻

Permanent Function

Permanent Functionは、

長期的に必要。

責任が継続。

Knowledgeを蓄積。

する。

したがって局室研究所へ置く。

⸻

Temporary Coordination

Temporary Coordinationは、

課題発生時だけ必要。

複数Capabilityを接続。

目的達成後に終了。

する。

したがってProject / Task Forceとして組成する。

⸻

Functionを人事異動と混同しない

人は異動する。

しかしFunctionは残る。

したがって、

[
Person
\neq
Function
]

である。

Digital Twinでは、

[
Person
\rightarrow
Role
\rightarrow
FunctionalModule
]

として接続する。

⸻

Capability Registry

Functional Organizationを横断可能にする鍵は、

[
\boxed{
Capability\ Registry
}
]

である。

各局が何をできるのかを登録する。

例えば、

Macro Modeling。

Legal Review。

Settlement Design。

Cybersecurity。

Regional Analysis。

International Coordination。

などである。

⸻

Capabilityを探せる組織

従来は、

「誰に相談すればよいか」

を人間の経験で探す。

Digital Twinでは、

[
Problem
\rightarrow
RequiredCapability
\rightarrow
OwningModule
\rightarrow
AvailableRole
]

と辿れる。

つまり、

[
\boxed{
Searchable\ Organization
}
]

になる。

⸻

Organizational API

各局には、Softwareだけでなく組織上のInterfaceも定義できる。

例えば、

何を依頼できるか。

どのDataを提供するか。

どのApprovalが必要か。

Response Timeはどの程度か。

である。

これを、

[
\boxed{
Organizational\ API
}
]

と考えることができる。

⸻

APIは人間関係を置き換えない

ただし、

[
OrganizationalAPI
]

は人間の協働を消すものではない。

むしろ、

「どこまでが正式なResponsibilityか」

を明確にするためのArchitectureである。

⸻

Functional Data Ownership

Data OwnershipもFunctionに沿わせる。

市場Data。

統計Data。

人事Data。

System Data。

それぞれPrimary Ownerを持つ。

他局はAPI / Data Contract経由で使う。

これによって、

[
\boxed{
Data\ Duplication
}
]

を減らす。

⸻

Functional System Ownership

Systemについても、

[
System
\rightarrow
OwningFunction
]

を持つ。

誰がBusiness Ownerなのか。

誰がTechnical Ownerなのか。

を分ける。

⸻

Business OwnerとTechnical Owner

例えばある分析Systemについて、

Business Ownerは調査統計局。

Technical Ownerはシステム情報局。

という構造があり得る。

したがって、

[
\boxed{
BusinessOwnership
\neq
TechnicalOwnership
}
]

である。

⸻

Dual Ownership

Digital Twinでは、

SystemOwnership
├── system_id
├── business_owner
├── technical_owner
├── data_owner
├── security_owner
└── continuity_owner

として記述する。

これによって責任の抜けを防ぐ。

⸻

Functional Metrics

各Functionは、単なる組織名ではなくCapabilityとして評価できる。

Quality。

Timeliness。

Resilience。

Knowledge Depth。

Interoperability。

などである。

⸻

KPIだけにしない

ただしFunctionを単純な数値KPIだけで評価しない。

例えば金融政策企画の質を一つのScoreにはできない。

そこで、

[
\boxed{
Capability\ Health
}
]

として多面的に見る。

⸻

Capability Health

CapabilityHealth
├── staffing
├── expertise
├── process_maturity
├── data_quality
├── system_health
├── continuity
└── dependency_risk

とする。

これにより、組織が表面上存在していてもCapabilityが弱っている状態を検出できる。

⸻

Functional Dependency

各Functionは完全に独立していない。

例えば企画局は、

調査統計局のData。

国際局のGlobal Context。

金融市場局のMarket State。

に依存する。

したがって、

[
\boxed{
Functional\ Dependency\ Graph
}
]

を作る。

⸻

Dependency Risk

もし一つのCapabilityが停止したとき、

どのFunctionが影響を受けるかを追跡する。

例えば、

Regional Dataが停止。

Global Market Feedが停止。

Core Systemが停止。

した場合である。

⸻

Bottleneck

Dependency Graphから、

[
\boxed{
Organizational\ Bottleneck
}
]

も発見できる。

一つのCapabilityへ依存が集中している場合、

人員増強。

System改善。

Backup Capability。

などを検討できる。

⸻

Functional Redundancy

Critical Functionについては、

[
\boxed{
Functional\ Redundancy
}
]

を設計することもできる。

一つのRoleしか知識を持たない状態を避ける。

これは人材面のSingle Point of Failureを防ぐ。

⸻

Succession

総務人事局Twinと接続して、

Critical Functionごとに、

Primary Role。

Backup Role。

Successor Capability。

を管理する。

⸻

Crisis時にもFunctionを消さない

危機時にはTask Forceを作る。

しかし、元のFunctional Ownershipは消さない。

例えばCyber Crisis Teamを作っても、

Security CapabilityのOwner。

決済CapabilityのOwner。

Market CapabilityのOwner。

は各局に残る。

⸻

Task ForceはFunctionを借りる

したがってTask Forceは、

[
\boxed{
Borrowed\ Capabilities
}
]

で構成される。

Permanent FunctionからCapabilityを一時的に接続する。

これによって、Project終了後にKnowledgeを返しやすくなる。

⸻

Functional OrganizationとAI

AI導入でも同じである。

中央AI部門がすべてのAIを作るArchitectureにはしない。

各FunctionがDomain Expertiseを持つ。

共通AI Platformだけ中央で提供する。

つまり、

[
\boxed{
DomainAIOwnership
+
SharedAIPlatform
}
]

である。

⸻

AI Center of Excellenceとの関係

共通StandardやSecurity、Model Governanceを支援する横断的なCenter的機能は有効である。

しかし各Domainの判断を奪わない。

[
CentralStandard
+
LocalOwnership
]

を維持する。

⸻

Functional OrganizationとFuture Readiness

未来のCapabilityを作る場合も、

新技術が出たから新局を作る、

とは限らない。

まず、

既存Functionへ吸収可能か。

Temporary Projectでよいか。

Permanent Functionが必要か。

を判断する。

⸻

Build / Buy / Partner / Project

新Capabilityについて、

[
Build
]

[
Buy
]

[
Partner
]

[
TemporaryProject
]

[
PermanentOrganization
]

を比較する。

この判断もFuture Readiness Architectureへ接続する。

⸻

Organizational Change Threshold

Temporary Projectが長期間続き、

重要Capabilityが恒常化した場合には、

[
\boxed{
Permanent\ Function\ Candidate
}
]

となる。

Digital Twinは、

Project期間。

Workload。

Dependency。

Strategic Importance。

を観測し、組織改編の検討材料を提供できる。

⸻

ProjectからFunctionへ

したがって、

[
TemporaryCapability
\rightarrow
RepeatedUse
\rightarrow
PermanentNeed
\rightarrow
FunctionalOrganization
]

というTransitionがあり得る。

逆に、不要になったFunctionを縮小することもある。

⸻

OrganizationもState Machineである

Functional Organizationそのものも固定物ではない。

[
Proposed
\rightarrow
Temporary
\rightarrow
Established
\rightarrow
Modified
\rightarrow
Retired
]

というLifecycleを持つ。

⸻

Stableとは変わらないことではない

本書でいうStable Verticalは、

[
\boxed{
Never\ Change
}
]

ではない。

必要な変化をGovernedに行う。

責任とKnowledgeを失わない。

という意味である。

⸻

Functional Organizationの最小式

ここまでを圧縮すると、

[
\boxed{
FunctionalOrganization

Specialization
+
Ownership
+
Authority
+
Capability
+
Memory
}
]

である。

これにInterfaceを加えると、

[
\boxed{
StableFunction
+
ExplicitInterface
}
]

となる。

⸻

Dynamic Organizationへの入口

Functional Organizationは日本銀行の平時の基礎構造になる。

しかし、現実の課題はFunction単位では現れない。

金融政策と市場。

決済とCyber。

気候と金融システム。

CBDCと法制度。

のように複数Domainを横断する。

したがって、

[
\boxed{
FunctionalOrganization
\rightarrow
CrossFunctionalOrganization
}
]

という第二の構造が必要になる。

ただし前者を破壊しない。

⸻

Stable VerticalからDynamic Horizontalへ

ここまでの最小構造は、

[
\boxed{
Stable\ Vertical

Permanent\ Functional\ Organization
}
]

である。

そして次に、

[
\boxed{
Dynamic\ Horizontal

Temporary\ Cross\text{-}functional\ Connection
}
]

を加える。

次節では、複数局室研究所が一つの課題に対してCapabilityを持ち寄る、

[
\boxed{
Cross\text{-}functional\ Project
}
]

を記述する。

そこで日本銀行Digital Twinは、

[
\boxed{
組織図に従って動くだけのInstitution
}
]

から、

[
\boxed{
課題に応じて必要なCapabilityを動的に組成できるInstitution
}
]

へ進む。
第2節　Cross-functional Project

Functional Organizationは、専門性と責任を保持するために必要である。

しかし、現実の課題は、必ずしも組織図に沿って発生しない。

CBDC。

サイバーセキュリティ。

気候変動。

巨大災害。

金融危機。

AI Governance。

こうした課題は、一つの局だけでは完結しない。

したがって、日本銀行Digital Twinには、

[
\boxed{
Cross\text{-}functional\ Project
}
]

という第二の組織構造が必要になる。

これはStable Verticalを壊すものではない。

むしろ、

[
\boxed{
Permanent\ Functional\ Organization
+
Temporary\ Cross\text{-}functional\ Connection
}
]

という形で、両者を重ねる。

────────

Projectは組織改編ではない

横断課題が発生するたびに、新しい局を作る必要はない。

一時的な課題に恒久組織で対応すると、組織が増殖する。

逆に、既存局だけに閉じ込めると、必要なCapabilityが接続されない。

そこで、

[
\boxed{
Project
\neq
Permanent\ Organization
}
]

とする。

Projectは、特定の目的、期間、成果物を持つTemporary Organizationである。

────────

Project Object

Digital Twinでは、Projectそのものを第一級Objectとして扱う。

```text id="cfp1"
CrossFunctionalProject
├── project_id
├── purpose
├── problem_statement
├── executive_sponsor
├── primary_owner
├── participating_modules
├── required_capabilities
├── authority_scope
├── deliverables
├── milestones
├── start_date
├── end_condition
├── risks
└── knowledge_return_plan
```

とする。

これにより、単なる「関係者会議」ではなく、明確なInstitutional Structureになる。

────────

Problemから始める

Projectは、

[
Department
]

から始めない。

まず、

[
\boxed{
Problem
}
]

を定義する。

例えば、

「CBDCに関する技術・制度・経済・運用上の検証を行う」

「重大なCyber Riskに対する全行的Resilienceを強化する」

というように、解くべき課題を先に置く。

────────

Problem → Capability

次に、

その課題を解くために何が必要かを分解する。

[
Problem
\rightarrow
RequiredCapabilities
]

である。

例えばCBDCなら、

Payment Design。

Legal Review。

Monetary Analysis。

Financial Stability Analysis。

Cybersecurity。

System Architecture。

International Coordination。

Public Communication。

が必要になる可能性がある。

────────

Capability → Module

その後で、

[
Capability
\rightarrow
OwningModule
]

を辿る。

すると、

決済機構局。

企画局。

金融機構局。

システム情報局。

国際局。

政策委員会室。

情報サービス局。

などが接続される。

つまり、

[
\boxed{
Problem
\rightarrow
Capability
\rightarrow
Module
}
]

である。

────────

人を先に集めない

従来型Projectでは、

「関係ありそうな人を集める」

ところから始まりやすい。

しかしDigital Twinでは、

まずCapabilityを定義する。

その後、

[
Capability
\rightarrow
Role
\rightarrow
Person
]

へ進む。

この順序によって、個人的人脈への依存を減らせる。

────────

Primary Owner

複数局が参加しても、

[
\boxed{
Primary\ Owner
}
]

は明確にする。

全員がOwnerでは、実質的に誰もOwnerではなくなる。

したがって、

[
Collaboration
\neq
Diffuse\ Responsibility
]

である。

────────

Executive Sponsor

Projectには、必要に応じてExecutive Sponsorを置く。

Sponsorは、

Projectの目的。

組織間調整。

重要なEscalation。

を支える。

ただし、Sponsorが各局の専門的Authorityを吸収するわけではない。

────────

Authority Matrix

Cross-functional Projectで最も重要なのは、

[
\boxed{
Authority\ Matrix
}
]

である。

誰が何を決められるかを明示する。

例えば、

```text id="cfp2"
ProjectAuthority
├── project_decision
├── project_manager
├── executive_sponsor
├── source_module_authority
├── policy_board_reserved_matters
└── escalation_path
```

とする。

────────

Project AuthorityとInstitutional Authority

ProjectにはProject内部のDecision Authorityがある。

しかし、

[
\boxed{
ProjectAuthority
\neq
InstitutionalAuthority
}
]

である。

例えば、Projectが金融政策を変更することはできない。

Projectが法令上の政策委員会Authorityを取得することもない。

Reserved Mattersは明確に分離する。

────────

Reserved Matters

例えば、

政策委員会議決。

重要なInstitutional Change。

特定の法的承認。

などは、

[
\boxed{
Reserved\ Authority
}
]

としてProject外に残す。

これにより、横断化によってGovernanceが曖昧になるのを防ぐ。

────────

Project Charter

Project開始時には、

[
\boxed{
Project\ Charter
}
]

を作る。

目的。

Scope。

参加Module。

Authority。

成果物。

期間。

Risk。

終了条件。

を定義する。

────────

Scope

特に重要なのが、

[
\boxed{
In\ Scope
/
Out\ of\ Scope
}
]

である。

横断Projectは、範囲が無限に広がりやすい。

したがって、何をしないかも明示する。

────────

Deliverable

Projectは「検討すること」を目的にしない。

Architecture。

Report。

Prototype。

Policy Option。

Sandbox。

Operational Procedure。

など、成果物を定義する。

────────

Milestone

長期Projectでは、

[
Milestone_1
\rightarrow
Milestone_2
\rightarrow
Milestone_3
]

を設定する。

各Milestoneで、

成果。

Risk。

必要Capability。

を再評価する。

────────

Project State Machine

Digital Twinでは、

[
Proposed
\rightarrow
Approved
\rightarrow
Active
\rightarrow
Review
\rightarrow
Completed
]

というState Machineを持たせる。

さらに、

[
Paused
]

[
Cancelled
]

も保持する。

────────

Temporary Organization Graph

Project期間中だけ、

[
\boxed{
Temporary\ Organization\ Graph
}
]

を生成する。

例えば、

```text id="cfp3"
Project
├── PolicyBoardOffice
├── MonetaryAffairs
├── PaymentSettlement
├── FinancialSystem
├── InformationSystems
└── International
```

という横断Graphである。

Projectが終われば、このGraphは閉じる。

────────

Permanent Moduleは残る

Project期間中でも、

参加者は元のFunctional ModuleとのRelationを失わない。

したがって、

[
Person
\rightarrow
PermanentRole
]

と、

[
Person
\rightarrow
TemporaryProjectRole
]

を同時に持つ。

────────

Dual Role

例えば、

```text id="cfp4"
TemporaryRoleAssignment
├── person_id
├── permanent_role
├── project_role
├── allocation_ratio
├── start_date
└── end_date
```

とする。

これによって、本務とProject業務の競合を可視化できる。

────────

Capacity Constraint

横断Projectを増やしすぎると、各局の本務が弱くなる。

したがって、

[
\boxed{
Human\ Capacity
}
]

を制約として扱う。

一人を無限のProjectへ参加させない。

────────

Resource Planning

Projectには、

人材。

予算。

System。

Data。

Facility。

Vendor。

が必要になる。

これを、

[
\boxed{
Project\ Resource\ Graph
}
]

として管理する。

────────

Capability Allocation

必要Capabilityが不足している場合、

Training。

External Partner。

Temporary Staffing。

Technical Investment。

などを検討する。

したがってProjectはCapability Gapの検出機能にもなる。

────────

Data Sharing

Cross-functional Projectでは、複数局のDataを横断利用することがある。

しかし、

[
\boxed{
Project
\neq
Unlimited\ Data\ Access
}
]

である。

Data Ownerは維持する。

Projectには必要な範囲だけAccessを与える。

────────

Project Data Space

必要に応じて、

[
\boxed{
Project\ Data\ Space
}
]

を作る。

各局から必要なDataをContractに基づいて提供する。

Project終了時には、

Retention。

Archive。

Deletion。

を処理する。

────────

Project Knowledge Space

Documentや議論もProject-specific Knowledgeとして保持する。

ただし、Project終了後に孤立した共有Folderとして残さない。

最終的にPermanent Institutional Memoryへ戻す。

────────

Knowledge Return

Project終了時には、

[
\boxed{
Knowledge\ Return
}
]

を必須にする。

成果物。

Decision。

Model。

Code。

Data Definition。

Failure。

Lesson。

をPermanent Moduleへ移管する。

────────

Projectが知識を奪わない

優秀な人材がProjectへ移動し、終了後にKnowledgeが消える構造を避ける。

したがって、

[
TemporaryProject
\rightarrow
PermanentCapabilityIncrease
]

を目指す。

────────

APIで接続するProject

横断Projectだからといって、各局Systemを密結合させない。

必要な連携は、

API。

Event。

Data Contract。

で行う。

つまりProjectも、

[
\boxed{
Loosely\ Coupled
}
]

で設計する。

────────

Project-specific Integration

Project期間中だけ必要なIntegrationもある。

その場合、

Temporary API。

Temporary Event Subscription。

Temporary Access Role。

を設定し、終了時に削除する。

────────

Expiring Permissions

これは特に重要である。

Projectが終わった後もAccess権限だけ残る状態を防ぐ。

したがって、

[
\boxed{
Time\text{-}bounded\ Permission
}
]

を原則とする。

────────

Cross-functional AI

ProjectにはProject-specific AI Agentを配置することもできる。

例えばCBDC Project Agentなら、

関連法令。

Research。

決済設計。

International Papers。

を検索する。

ただし、

[ AgentScope

ProjectScope
]

に限定する。

────────

Project Agentは常設しない

Project終了時に、

Memory。

Access。

Tool Permission。

をReviewし、必要がなければ停止する。

AI AgentもTemporary Organizationの一部として扱う。

────────

Project Digital Twin

さらに、

[
\boxed{
ProjectTwin
}
]

を持たせることができる。

Projectの、

Current State。

Milestone。

Risk。

Dependency。

Capability。

をリアルタイムに近い形で把握する。

────────

Project Health

例えば、

```text id="cfp5"
ProjectHealth
├── schedule
├── budget
├── capability_gap
├── unresolved_risks
├── decision_latency
├── dependency_status
└── deliverable_status
```

として管理する。

────────

Project Risk

Cross-functional Projectでは、

Technical Risk。

Legal Risk。

Operational Risk。

Policy Risk。

Reputational Risk。

Coordination Risk。

がある。

これらを一つのRisk Registerへ接続する。

────────

Escalation

Project内部で解決できない問題は、

[
Project
\rightarrow
ExecutiveSponsor
\rightarrow
InstitutionalAuthority
]

へEscalateする。

必要なら政策委員会へ上げる。

────────

Decision Log

横断Projectでは「誰が決めたのか」が曖昧になりやすい。

したがって、

[
\boxed{
Project\ Decision\ Log
}
]

を必須にする。

```text id="cfp6"
ProjectDecision
├── decision_id
├── subject
├── authority
├── participants
├── decided_at
├── rationale_record
└── downstream_actions
```

とする。

────────

Cross-functional ProjectとTask Force

ここでProjectとTask Forceを分ける。

Cross-functional Projectは、

比較的明確な目的。

成果物。

期間。

計画。

を持つ。

一方Task Forceは、より緊急性・不確実性が高い課題へ対応する。

したがって、

[
\boxed{
Project
\neq
TaskForce
}
]

である。

────────

Projectは計画的横断

Cross-functional Projectは、

[
\boxed{
Planned\ Horizontal
}
]

と考えることができる。

Task Forceは次節で、

[
\boxed{
Rapid\ Horizontal
}
]

として記述する。

────────

横断Projectの代表例

本書のArchitecture上、横断Projectに向くテーマとしては、

CBDC実証。

全行的AI Governance。

大規模System Modernization。

Data Platform。

Climate-related Analytical Framework。

Digital Public Information。

などが考えられる。

ただし、実際にどのProjectを設置するかは日本銀行自身のGovernanceによって決まる。

────────

Project乱立を防ぐ

Cross-functionalが有効だからといって、何でもProject化してはならない。

恒常業務はFunctional Organizationへ置く。

軽微な調整なら通常の業務調整でよい。

Projectが必要なのは、

[
\boxed{
MultipleCapabilities
+
DefinedOutcome
+
TemporaryNeed
}
]

が存在する場合である。

────────

Project Creation Rule

例えば、

```text id="cfp7"
CreateProjectWhen
├── crosses_multiple_modules
├── requires_defined_deliverable
├── has_material_dependency
├── needs temporary governance
└── cannot_be_handled_by_normal_process
```

とする。

────────

Project Closure

Projectは開始よりも終了が重要である。

終了条件を満たしたら、

Closure Review。

Knowledge Transfer。

Access Revocation。

Asset Transfer。

Outcome Evaluation。

を行う。

────────

Projectを永久化しない

一時組織が目的を失ったまま残ることを防ぐ。

必要なCapabilityが恒常化したなら、

Permanent Functionへ昇格する。

不要なら終了する。

────────

Project → Institution

したがって、Projectの最終経路は二つある。

[
Project
\rightarrow
Close
]

または、

[
Project
\rightarrow
PermanentCapability
]

である。

────────

Cross-functional Projectの最小式

ここまでを圧縮すると、

[ \boxed{ CrossFunctionalProject

Problem
+
Capabilities
+
TemporaryRoles
+
Governance
+
Deliverables
+
KnowledgeReturn
}
]

となる。

そして、

[
\boxed{
StableVertical
+
PlannedHorizontal
}
]

というOrganization Architectureが成立する。

────────

縦割りを越えるとは何か

縦割りを越えるとは、局の境界を消すことではない。

必要な時だけ、

[
Capability_A
+
Capability_B
+
Capability_C
]

を一時的に接続することである。

終了したら、CapabilityとKnowledgeを元の組織へ戻す。

これによって、

[
\boxed{
Specialization
+
Integration
}
]

を同時に保てる。

────────

Cross-functional ProjectからTask Forceへ

しかし、すべての横断課題にProjectを立ち上げる時間があるわけではない。

金融危機。

大規模なCyber Incident。

巨大災害。

決済障害。

世界市場の急変。

こうした課題では、通常のProject Governanceより速い組成が必要になる。

そこで次節では、

[
\boxed{
Task\ Force
}
]

を記述する。

Cross-functional Projectが計画的にCapabilityを接続する仕組みであるなら、

Task Forceは、

[
\boxed{
不確実性と緊急性の高い状況で、
必要なCapabilityとAuthorityを短時間で接続する
Dynamic\ Organization
}
]

なのである。
第3節　Task Force

Cross-functional Projectが計画的な横断組織だとすれば、Task Forceはより緊急性と不確実性の高い状況に対応するためのDynamic Organizationである。

金融市場の急変。

大規模な決済障害。

サイバー攻撃。

巨大災害。

金融機関の重大なStress。

国際金融危機。

こうしたEventは、通常の組織階層やProject立ち上げ手続を待たない。

必要なのは、

[
\boxed{
必要なCapabilityを、
必要なAuthorityの下で、
短時間に接続すること
}
]

である。

しかし、速さを優先するからといって、Governanceを消してはならない。

本書におけるTask Forceは、

[
\boxed{
Rapid
+
Temporary
+
Governed
}
]

な横断組織である。

────────

Task Forceは危機対策本部と同義ではない

最初に区別する。

Task Forceは、必ずしも大規模危機だけに設置されるものではない。

緊急に複数局の専門能力を集める必要がある課題にも使える。

したがって、

[
\boxed{
TaskForce
\neq
CrisisHeadquarters
}
]

である。

一方、重大危機ではTask ForceがCrisis Governanceの一部になることがある。

つまり、

[
TaskForce
\subseteq
DynamicOrganization
]

である。

────────

Projectとの違い

Cross-functional Projectは、

目的を定義する。

計画を作る。

Milestoneを設定する。

成果物を作る。

という比較的計画的な構造を持つ。

一方Task Forceは、

[
\boxed{
Uncertainty
+
Urgency
}
]

が高い。

したがって、

[ Project

PlannedHorizontal
]

[ TaskForce

RapidHorizontal
]

と整理できる。

────────

Task Force Object

Digital Twinでは、Task Forceそのものを第一級Objectとして扱う。

```text id="tf1"
TaskForce
├── taskforce_id
├── trigger_event
├── mission
├── activation_authority
├── lead_role
├── participating_modules
├── required_capabilities
├── authority_scope
├── operating_mode
├── communication_channel
├── start_time
├── review_time
├── deactivation_condition
└── archive_reference
```

とする。

────────

Triggerから始まる

Task Forceの起点は、

[
\boxed{
Trigger
}
]

である。

例えば、

MarketStressDetected。

PaymentSystemIncident。

MajorCyberIncident。

RegionalDisaster。

FinancialInstitutionStress。

GlobalShock。

などである。

したがって、

[
Event
\rightarrow
Assessment
\rightarrow
TaskForceActivation
]

というFlowになる。

────────

自動起動しない

Digital Twinが重大Eventを検出しても、

Task ForceをAIが勝手に設置するArchitectureにはしない。

AIは、

[
ActivationRecommendation
]

を出せる。

しかし、

[ \boxed{ ActivationAuthority

Human/InstitutionalRole
}
]

である。

────────

Activation Threshold

Task Forceを乱立させないため、

[
\boxed{
ActivationThreshold
}
]

を持つ。

例えば、

複数Moduleへの影響。

高い緊急性。

通常Processでは対応困難。

重大なOperational / Financial Risk。

などである。

────────

Severity

EventにはSeverityを持たせる。

例えば、

[
S0
]

Normal。

[
S1
]

Elevated。

[
S2
]

Major。

[
S3
]

Critical。

といった分類が考えられる。

Task Forceの規模やAuthorityはSeverityに応じて変える。

────────

Missionを一文で固定する

Task Forceは、緊急時ほどScopeが拡散しやすい。

したがって、

[
\boxed{
Mission
}
]

を短く明確にする。

例えば、

「主要決済機能を安定化し、通常運用へ復旧する」

「金融市場の急変が金融システムへ与える影響を評価し、必要な対応案を提示する」

とする。

────────

Capability Assembly

Task Forceは人名から作らない。

必要なCapabilityから作る。

例えばサイバー障害なら、

Cybersecurity。

Payment Operations。

System Operations。

Business Continuity。

Legal / Compliance。

Public Communication。

Financial Stability。

などを抽出する。

そして、

[
Capability
\rightarrow
Module
\rightarrow
AvailableRole
]

を辿る。

────────

Rapid Capability Assembly

これを、

[
\boxed{
Rapid\ Capability\ Assembly
}
]

とする。

通常時にCapability Registryが整備されているからこそ、危機時に短時間で適切なRoleを集められる。

────────

Lead Role

Task Forceには必ず、

[
\boxed{
LeadRole
}
]

を置く。

複数局が参加しても、

誰が全体を統括するかを明確にする。

ただしLead Roleが各局の法定Authorityを吸収するわけではない。

────────

Authority Map

Task Forceでは、

[
\boxed{
Authority\ Map
}
]

が特に重要になる。

どこまでTask Force内部で決定できるのか。

どの事項はExecutiveへ上げるのか。

どの事項は政策委員会のReserved Matterなのか。

を明示する。

────────

Fast Decision Path

危機時には通常より短いDecision Pathが必要になる場合がある。

例えば、

[
Detect
\rightarrow
Assess
\rightarrow
Approve
\rightarrow
Act
]

とする。

しかし、

[
\boxed{
ShorterProcess
\neq
NoControl
}
]

である。

────────

Pre-authorized Emergency Actions

一部のActionについては、平時にあらかじめ緊急時のAuthorityを定義しておくことができる。

例えば、

特定Systemの隔離。

特定Serviceの停止。

Fallback Processへの切替。

などである。

これを、

[
\boxed{
Pre\text{-}authorized\ Emergency\ Action
}
]

とする。

────────

Emergency Authorityは限定する

緊急Authorityには、

Scope。

Duration。

Trigger。

Audit。

を必ず付ける。

例えば、

```text id="tf2"
EmergencyAuthority
├── authority_type
├── holder_role
├── trigger
├── scope
├── valid_from
├── expires_at
└── review_required
```

とする。

永続的Authorityにしない。

────────

War RoomではなくShared State

Task Forceというと、関係者が一室に集まるWar Room型を想像しやすい。

しかしDigital Twinでは、物理的な会議室より、

[
\boxed{
Shared\ Operational\ State
}
]

が重要になる。

何が起きているか。

何が分かっているか。

何が未解決か。

誰が何を担当しているか。

を同じStateとして共有する。

────────

Incident State

例えば、

```text id="tf3"
IncidentState
├── incident_id
├── severity
├── affected_functions
├── affected_nodes
├── known_facts
├── hypotheses
├── unresolved_questions
├── actions
├── owners
└── current_status
```

とする。

────────

FactとHypothesisを分離する

危機時ほど誤情報が増える。

したがって、

[
\boxed{
KnownFact
\neq
Hypothesis
}
]

を明確にする。

確認済み情報。

未確認情報。

推定。

を同じ欄に置かない。

────────

Time-stamped State

危機時のStateは高速に変わる。

したがって、

[
IncidentState(t)
]

として保持する。

何時何分時点の情報なのかを明示する。

────────

Situation Board

Task Force Interfaceには、

Current Situation。

Impact。

Critical Risks。

Actions。

Owners。

Decision Needed。

を表示する。

大量のDashboardではなく、

[
\boxed{
Actionable\ Situation\ Board
}
]

にする。

────────

Decision Needed

特に、

[
\boxed{
What\ needs\ a\ decision\ now?
}
]

を明示する。

情報を見るだけでなく、Decision Bottleneckを可視化する。

────────

Communication Channel

Task Forceには専用のCommunication Channelを持たせることができる。

ただし、会話履歴だけでInstitutional Recordを残さない。

重要Decisionは正式なDecision Logへ移す。

────────

Chat ≠ Record

したがって、

[
\boxed{
Operational\ Communication
\neq
Authoritative\ Record
}
]

である。

危機対応Chatが消えても、DecisionとActionは正式記録として残る。

────────

Task Board

Actionは、

```text id="tf4"
TaskForceAction
├── action_id
├── description
├── owner
├── authority
├── priority
├── deadline
├── status
└── verification
```

として管理する。

────────

Parallel Work

Task Forceの強みは、

[
\boxed{
Parallelization
}
]

である。

一つの組織階層で順番に処理するのではなく、

市場。

System。

決済。

Communication。

Risk。

を並行して進める。

────────

Dependency Management

しかし並列化すると、Action間のDependencyが重要になる。

例えば、

System Recovery前に業務再開できない。

Legal Review前に特定公表ができない。

という関係である。

したがって、

[
Action_A
\rightarrow
Action_B
]

をGraphとして保持する。

────────

Crisis Event Bus

Task Forceは既存のInstitutional Event Busを利用する。

ただし危機時には、

Priority。

Frequency。

Subscriber。

を変更する。

つまり、

[
\boxed{
CrisisEventRouting
}
]

を使う。

────────

情報を全部流さない

危機時ほど情報量が増える。

すべてを全員へ流すと、逆に対応が遅くなる。

したがって、

[
Role
+
Priority
+
NeedToKnow
]

に応じてRoutingする。

────────

Decision Latency

Task Forceでは、

[
\boxed{
DecisionLatency
}
]

を測る。

重大なDecisionがどこで止まっているかを可視化する。

ただし速度だけをKPIにしない。

正確性とAuthorityを同時に見る。

────────

AIの役割

AIはTask Forceで有用である。

大量Event整理。

類似Incident検索。

状況要約。

Dependency抽出。

Scenario生成。

を支援できる。

しかし、

[
AI
\neq
IncidentCommander
]

である。

────────

Crisis AI Agent

例えば、

```text id="tf5"
CrisisSupportAgent
├── retrieve_relevant_procedures
├── summarize_events
├── map_dependencies
├── generate_scenarios
├── identify_missing_information
└── no_emergency_authority
```

とする。

────────

AIが不確実性を埋めない

危機時に分からないことが多い場合、

AIがもっともらしい補完をすると危険である。

したがって、

[
\boxed{
Unknown
}
]

を明示する設計にする。

────────

Simulationとの接続

Task ForceはSimulation Engineも利用できる。

例えば、

この障害が2時間続いたら。

市場Shockがさらに拡大したら。

特定地域が通信断になったら。

どうなるかをSimulationする。

────────

Rapid Simulation

ただし危機時に精緻な長期Modelだけを使っていては遅い。

そこで、

[
\boxed{
Fast\ Approximate\ Model
}
]

と、

[
DetailedModel
]

を使い分ける。

必要な精度と時間をTrade-offする。

────────

Crisis Mode Model Governance

危機時でも、未承認Modelを自由にProduction Decisionへ使わない。

ただし、Experimental Modelを参考情報として表示することはできる。

その場合、

[
\boxed{
Experimental
}
]

と明示する。

────────

External Institutionsとの接続

重大Task Forceでは、外部Institutionも関係する。

政府。

金融庁。

金融機関。

決済Infrastructure。

外国中央銀行。

などである。

このとき、

[
InternalTaskForce
\neq
ExternalJointAuthority
]

を維持する。

────────

External Coordination Interface

外部組織との連携は、

[
\boxed{
ExternalCoordinationInterface
}
]

として定義する。

誰が連絡窓口か。

何を共有できるか。

どのAuthorityに基づくか。

を明確にする。

────────

Crisis Information Boundary

危機時ほど情報共有が重要になる一方、機密性も高い。

したがって、

[
\boxed{
Share\ Necessary,
Protect\ Sensitive
}
]

を徹底する。

────────

Cyber Task Force

例えばCyber Incidentでは、

システム情報局。

決済機構局。

業務局。

情報サービス局。

政策委員会室。

必要に応じて金融市場・金融機構。

などを接続する可能性がある。

重要なのは、組織名ではなくCapabilityから構成することである。

────────

Financial Crisis Task Force

金融危機では、

金融機構。

金融市場。

企画。

決済。

国際。

調査統計。

などが接続される可能性がある。

ここでも、

[
Problem
\rightarrow
Capabilities
]

で組成する。

────────

Disaster Task Force

巨大災害では、

被災支店。

決済機構。

発券。

業務。

システム情報。

総務人事。

文書。

などが重要になる。

地域Networkと本店を同時に扱う。

────────

Task Force Topologyは異なる

つまり、

[ \boxed{ TaskForceTopology

IncidentSpecific
}
]

である。

固定メンバーの万能Task Forceを一つ作るのではない。

Incidentに応じて組み替える。

────────

Reconfiguration

状況が変われば、参加Capabilityも変更する。

例えば当初はSystem障害だったものが、市場Stressへ波及すれば金融市場局・金融機構局の関与が強くなる。

したがって、

[
TaskForce(t)
]

もDynamicである。

────────

Shift Handover

長時間危機では、人間は交代する。

したがって、

[
\boxed{
Role\ Handover
}
]

を設計する。

Current Situation。

Open Actions。

Decision Pending。

Risk。

を次の担当へ引き継ぐ。

────────

人に依存しない継続性

一人のExpertが離席するとTask Forceが止まる構造を避ける。

KnowledgeとCurrent Stateを共有する。

これもDigital Twinの価値である。

────────

Recovery Phase

危機が落ち着いたら、

[
Crisis
\rightarrow
Recovery
]

へ移行する。

Task ForceのMissionも、

Containment。

Stabilization。

Recovery。

へ変わる。

────────

Exit Criteria

Task Forceは終了条件を最初から持つ。

例えば、

Critical Function復旧。

重大Risk低下。

通常Processへ移管可能。

などである。

────────

Deactivation

終了時には、

[
\boxed{
Deactivation
}
]

を正式に行う。

Temporary Authority。

Temporary Access。

Emergency Channels。

を解除する。

────────

Accessを残さない

危機時に付与した特別Permissionが平時に残ることを防ぐ。

[
CrisisPermission
\rightarrow
Expire
]

を原則とする。

────────

After Action Review

Task Force終了後には、

[
\boxed{
After\ Action\ Review
}
]

を行う。

何が起きたか。

何が機能したか。

何が遅れたか。

何が不足したか。

を検証する。

────────

BlameではなくSystem Learning

Reviewの目的は単純な責任追及ではない。

Process。

Capability。

System。

Governance。

を改善することである。

もちろんAccountabilityは残す。

しかし、

[
\boxed{
Learning
}
]

へ接続する。

────────

Incident Knowledge Return

Task Forceの知識は、

Permanent Module。

BCP。

Simulation Scenario。

Training。

へ戻す。

つまり、

[
Incident
\rightarrow
TaskForce
\rightarrow
Learning
\rightarrow
StableOrganization
]

となる。

────────

Crisis Scenario Library

経験したIncidentは、

[
\boxed{
Scenario\ Library
}
]

へ追加する。

次回の訓練やSimulationで利用する。

これによって危機対応能力が累積する。

────────

Exercise

実際の危機だけでTask Forceを検証するのは遅い。

そこで、

[
\boxed{
Tabletop
+
Simulation\ Exercise
}
]

を行う。

Cyber。

災害。

市場危機。

決済障害。

などを仮想的に発生させる。

────────

Digital Twinを訓練環境にする

Digital Twinを使えば、

現実のProductionへ影響を与えず、

[
\boxed{
Institutional\ Exercise\ Sandbox
}
]

を作れる。

これはTask Force Capabilityを継続的に検証する重要な用途になる。

────────

Task Force Readiness

通常時にも、

[
\boxed{
TaskForceReadiness
}
]

を測る。

必要Capabilityは揃っているか。

連絡経路は最新か。

Backup Roleはいるか。

Playbookは有効か。

を確認する。

────────

Task Forceの最小式

ここまでを圧縮すると、

[ \boxed{ TaskForce

Trigger
+
RapidCapabilityAssembly
+
TemporaryAuthority
+
SharedState
+
FastDecision
+
Recovery
+
Learning
}
]

となる。

────────

ProjectとTask Force

これでDynamic Organizationには二つの横断形態が揃った。

Cross-functional Projectは、

[
\boxed{
Planned\ Horizontal
}
]

Task Forceは、

[
\boxed{
Rapid\ Horizontal
}
]

である。

両者の下には、

[
\boxed{
Stable\ Vertical
}
]

が残り続ける。

────────

Dynamic Organizationの基本形

したがって、

[
\boxed{
StableVertical
+
PlannedHorizontal
+
RapidHorizontal
}
]

が、日本銀行Digital TwinにおけるDynamic Organizationの基本構造となる。

次節では、この構造を具体的な長期横断テーマへ適用する。

対象は、

[
\boxed{
CBDC
}
]

である。

CBDCは、決済だけの問題ではない。

法制度。

金融政策。

金融システム。

サイバー。

技術。

現金。

国際協力。

プライバシー。

を横断する。

したがって、日本銀行Digital TwinにおけるDynamic Organizationを具体化する最も適したCaseの一つとなる。
第4節　CBDC

CBDC――中央銀行デジタル通貨――は、日本銀行の中でも典型的なCross-domain Themeである。

それは決済機構局だけの課題ではない。

通貨。

金融政策。

金融システム。

決済。

サイバーセキュリティ。

法制度。

プライバシー。

現金との関係。

国際連携。

システム。

利用者Interface。

これらすべてが接続する。

したがって、CBDCをDigital Twin上で扱うときに重要なのは、

[
\boxed{
CBDC\ System
}
]

をいきなり設計することではない。

まず、

[
\boxed{
CBDC\ Institutional\ Problem
}
]

を分解することである。

────────

CBDCは単なる「デジタル円」ではない

CBDCを、

[
Cash
\rightarrow
Digital
]

という単純な置換として理解すると、本質を見失う。

現金には、

匿名性。

オフライン性。

物理的保有。

広い受容性。

災害時Resilience。

という性質がある。

預金には、

金融機関Balance Sheet。

Credit Creation。

Payment Services。

という性質がある。

中央銀行当座預金にも独自の制度的役割がある。

したがってCBDCは、新しいMoney Formを既存の通貨・金融・決済構造へどう追加するかという問題である。

[
\boxed{
CBDC
\neq
Cash\ Replacement
}
]

である。

────────

現在のCBDC研究との接続

日本銀行はCBDCについて、概念実証を経てPilot Programを進めている。

したがって本書では、CBDCを遠い未来の仮説として扱わない。

[
\boxed{
Existing\ Experiment
\rightarrow
Institutional\ Digital\ Twin
}
]

として接続する。

ただし、

実験。

技術検証。

制度検討。

発行Decision。

は明確に分離する。

[
\boxed{
Experiment
\neq
IssuanceDecision
}
]

である。

────────

CBDC Project

Digital Twin上では、CBDCをCross-functional Projectとして表現する。

```text id="cbdc1"
CBDCProject
├── mission
├── policy_questions
├── legal_questions
├── payment_design
├── monetary_implications
├── financial_stability
├── privacy
├── cybersecurity
├── technology
├── cash_relation
├── international_relation
├── experimentation
└── governance
```

CBDC Projectは一つの新しい局ではない。

必要なCapabilityを各局から接続するTemporary Organizationである。

────────

Primary Owner

CBDCの中心Capabilityは、決済制度と決済Infrastructureに強く関係する。

したがってArchitecture上は、

[
\boxed{
Payment\ Settlement
}
]

をPrimary Domainとして置くことが自然である。

しかしPrimary Ownerが全Authorityを持つわけではない。

CBDCには複数のReserved Matterがある。

────────

Capability Map

CBDCに必要となるCapabilityを分解すると、

[
PaymentDesign
]

[
LegalReview
]

[
MonetaryPolicyAnalysis
]

[
FinancialStabilityAnalysis
]

[
CyberSecurity
]

[
SystemArchitecture
]

[
CashOperations
]

[
InternationalCoordination
]

[
PublicCommunication
]

[
Research
]

などが現れる。

つまり、

[
\boxed{
CBDC
\rightarrow
CapabilityNetwork
}
]

である。

────────

Module Map

これを既存組織へ対応させると、

決済機構局。

企画局。

金融機構局。

システム情報局。

発券局。

国際局。

政策委員会室。

情報サービス局。

金融研究所。

などが接続する。

したがって、

[ \boxed{ CBDCProject

Temporary\ Cross\text{-}module\ Network
}
]

となる。

────────

CBDCと政策委員会

CBDCの研究・実験を行うことと、制度導入を決定することは異なる。

Digital Twinでは、

[
Research
]

[
Experiment
]

[
PolicyOption
]

[
InstitutionalDecision
]

を分離する。

AIやProject Teamが、

[
\boxed{
CBDCIssuanceDecision
}
]

を行うことはない。

────────

CBDC State Machine

CBDC Projectは、例えば、

[
Research
\rightarrow
ProofOfConcept
\rightarrow
Pilot
\rightarrow
Evaluation
\rightarrow
PolicyOption
]

というStateを持つ。

その先に、

[
PossibleInstitutionalDecision
]

がある。

この境界を明確にする。

────────

Design Dimensions

CBDCのDesignには複数軸がある。

例えば、

Retail / Wholesale。

Account-based / Token-like。

Online / Offline。

Direct / Intermediated。

Privacy Level。

Holding Limit。

Interest-bearing / Non-interest-bearing。

などである。

したがって、一つの完成形を前提にしない。

────────

Design Space

Digital Twinでは、

[
\boxed{
CBDC\ Design\ Space
}
]

を持つ。

```text id="cbdc2"
CBDCDesign
├── access_model
├── distribution_model
├── settlement_model
├── offline_capability
├── privacy_model
├── holding_rules
├── remuneration
├── identity_model
├── resilience_model
└── interoperability
```

として複数案を比較する。

────────

Policy OptionではなくDesign Option

この段階では、

[
Option_A
]

[
Option_B
]

[
Option_C
]

をDesign Optionとして比較する。

AIが一つを「最適」と決めない。

────────

決済との関係

CBDCはPayment Infrastructureへ直接関係する。

したがって、

[
CBDCTransaction
]

[
Settlement
]

[
Liquidity
]

[
Participant
]

をModel化する。

しかし実際のProduction Systemの非公開構造を推測して再現しない。

Reference Architectureとして扱う。

────────

Payment State Machine

例えば、

```text id="cbdc3"
CBDCPayment
├── initiated
├── authenticated
├── validated
├── authorized
├── settled
├── rejected
└── reversed_if_applicable
```

というLifecycleをSimulationできる。

────────

Intermediation

CBDCでは、民間金融機関等がどのような役割を持つかも重要である。

したがって、

[
CentralBank
]

[
Intermediary
]

[
User
]

を別Nodeとして持つ。

一つの巨大な中央銀行Retail Systemにすることを前提にしない。

────────

金融機関との関係

CBDC保有が銀行預金へ与える影響は、金融システム上の重要論点である。

例えば、

[
Deposits
\rightarrow
CBDC
]

への資金移動が大きくなれば、金融機関Fundingへ影響する可能性がある。

したがって、

[
\boxed{
CBDC
\leftrightarrow
BankFunding
}
]

をSimulationする。

────────

Stress Scenario

平時だけでなく、

金融不安時に預金からCBDCへ急速に資金が移るScenarioも考える。

[
Stress
\rightarrow
DepositOutflow
\rightarrow
CBDCHolding
\rightarrow
BankLiquidity
]

という連鎖である。

これを金融機構局Twinと接続する。

────────

Holding Limit

このようなRiskへのDesign Optionとして、

Holding Limit。

Tiered Remuneration。

などが考えられる。

Digital Twinでは、これらをPolicy Proposalではなく、

[
\boxed{
Scenario\ Parameters
}
]

として扱う。

────────

金融政策との関係

CBDCが利息を持つか。

保有制限を持つか。

現金・預金とどう代替するか。

によって、金融政策Transmissionに影響し得る。

したがって、

[
CBDCDesign
\rightarrow
MonetaryTransmission
]

を企画局Twinへ接続する。

────────

ただしCBDCを政策手段と決めつけない

CBDCを導入すれば新しい金融政策手段になる、と自動的に仮定しない。

Designによって意味が大きく変わる。

したがって、

[
\boxed{
CBDCDesign
\rightarrow
PolicyImplication
}
]

として検証する。

────────

現金との関係

CBDCを設計するとき、発券局Twinが重要になる。

現金需要。

銀行券流通。

災害時利用。

高齢者やDigital Access。

などとのRelationを考える。

[
\boxed{
CBDC
+
Cash
}
]

という共存Scenarioを基本に置く。

────────

Cash Replacement Scenario

完全置換。

部分代替。

補完。

など複数Scenarioを計算する。

しかし、Digital Twin上で現金廃止を前提にはしない。

────────

Offline CBDC

災害や通信障害を考えると、

[
\boxed{
Offline\ Capability
}
]

は重要な検証項目となる。

ただしOffline Paymentは、

Double Spending。

Device Security。

Reconciliation。

など新しいRiskを生む。

────────

Offline State

例えば、

[
Online
]

[
OfflineLocal
]

[
Reconnecting
]

[
Reconciled
]

というStateを設計し、Simulationする。

────────

Cybersecurity

CBDCはCritical Infrastructureになり得る。

したがって、

[
\boxed{
Security\ by\ Design
}
]

が不可欠である。

Identity。

Authentication。

Cryptography。

Endpoint Security。

Fraud Detection。

Network Security。

Key Management。

Recovery。

を扱う。

────────

CybersecurityとPrivacyは同じではない

Securityを強めるほど全Transactionを中央で可視化する、という単純な設計にはしない。

[
\boxed{
Security
\neq
Surveillance
}
]

である。

Privacyは独立したDesign Requirementとして扱う。

────────

Privacy

CBDCでは、

誰が何を知る必要があるか。

を明確にする。

中央銀行。

仲介機関。

利用者。

法執行等の制度的要請。

それぞれを分離する。

────────

Data Minimization

基本原則として、

[
\boxed{
Minimum\ Necessary\ Data
}
]

を採用する。

決済成立に不要なPersonal Dataを集めない。

Digital Currencyだからすべてを観測可能にする、というArchitectureにはしない。

────────

Privacy Model

```text id="cbdc4"
CBDCPrivacyModel
├── identity_requirements
├── transaction_visibility
├── intermediary_visibility
├── central_bank_visibility
├── retention
├── lawful_access
└── audit
```

として比較する。

────────

Legal Architecture

CBDC導入には、技術だけでなく法制度が関係する。

したがって、

[
CBDCRequirement
\rightarrow
LegalQuestion
\rightarrow
LegalReview
]

を政策委員会室等のLegal Capabilityへ接続する。

法解釈をAIが確定しない。

────────

Law Gap

Digital Twinでは、

現行制度で可能なこと。

法改正が必要な可能性があること。

未確定なこと。

を分ける。

[
\boxed{
CurrentLaw
+
LegalGap
+
OpenQuestion
}
]

である。

────────

International Interoperability

CBDCは国内だけの問題ではない。

各国がCBDCを検討・実験する場合、

Cross-border Payment。

FX。

AML/CFT等の制度。

Technical Standard。

Data Sovereignty。

が関係する。

国際局Twinと海外拠点を通じて、

[
\boxed{
CrossBorderCBDCScenario
}
]

を検証する。

────────

CBDC Federation

将来、複数中央銀行がCBDCを持つ場合でも、

一つの世界通貨Systemへ統合する必要はない。

[
\boxed{
Sovereign\ Systems
+
Interoperability
}
]

として設計する。

────────

Interoperability Contract

例えば、

```text id="cbdc5"
CrossBorderInterface
├── jurisdiction
├── currency
├── settlement_rule
├── identity_rule
├── message_standard
├── fx_process
└── legal_boundary
```

を比較できる。

────────

Technology Neutrality

CBDC Projectでは、特定Technologyを最初から前提にしない。

Blockchain。

Distributed Ledger。

Centralized Database。

Hardware Secure Element。

などは手段である。

したがって、

[
\boxed{
Requirement
\rightarrow
Architecture
\rightarrow
Technology
}
]

の順で選ぶ。

────────

Blockchainを目的にしない

CBDCだからBlockchainを使う、とは限らない。

必要なのは、

Performance。

Resilience。

Security。

Privacy。

Auditability。

Offline Capability。

である。

TechnologyはそのRequirementsから選ぶ。

────────

28言語との関係

第2冊では、CBDC Sandboxの各Capabilityに応じて必要言語を選ぶ。

例えば、

Rust。

Go。

TypeScript。

SQL。

必要に応じて形式検証系言語。

などが候補になり得る。

しかし28言語をすべて使わない。

[
\boxed{
Minimum\ Best\text{-}fit\ Languages
}
]

を維持する。

────────

CBDC Sandbox

CBDCはProductionへ直接接続せず、

[
\boxed{
CBDC\ Sandbox
}
]

で実験する。

Synthetic Users。

Synthetic Banks。

Synthetic Transactions。

を使う。

────────

Synthetic Economy

さらに、金融機関Fundingや消費行動への影響を見るため、

[
\boxed{
Synthetic\ Economy
}
]

を使うことができる。

実在個人の取引履歴を必要としない。

────────

Pilot Twin

Pilot ProgramをDigital Twinへ接続すると、

[
ExperimentState
]

[
TechnicalResult
]

[
OperationalFinding
]

[
InstitutionalQuestion
]

を同じGraphへ保存できる。

────────

Experiment ≠ Production

Pilotで動いたからといって、

[
\boxed{
ProductionReady
}
]

とは限らない。

Scale。

Security。

Resilience。

Law。

Governance。

Public Acceptance。

などの追加評価が必要になる。

────────

Scenario Matrix

CBDCでは複数Design × 複数Scenarioを比較する。

例えば、

[
Design_i
\times
Scenario_j
]

である。

Scenarioには、

Normal Use。

Mass Adoption。

Low Adoption。

Financial Stress。

Cyber Incident。

Disaster。

Offline Operation。

を含められる。

────────

CBDC Impact Matrix

```text id="cbdc6"
CBDCImpact
├── payment_efficiency
├── financial_stability
├── monetary_policy
├── privacy
├── cyber_risk
├── cash_demand
├── financial_inclusion
├── resilience
└── implementation_cost
```

として評価する。

────────

一つのScoreへ圧縮しない

CBDCには複数Objectiveがある。

したがって、

[
\boxed{
Multi\text{-}objective\ Evaluation
}
]

とする。

「総合点82点だから導入」という判断にはしない。

────────

Human-centered Interface

CBDCが一般利用者を想定する場合、技術的性能だけでは不十分である。

高齢者。

障害者。

Digital Deviceを持たない人。

災害時。

外国人。

など、異なる利用Contextを考える必要がある。

────────

Accessibility

したがって、

[
\boxed{
Accessibility
}
]

をCBDC Design Requirementとして含める。

使える人だけが使える通貨Infrastructureにしない。

────────

Public Communication

CBDCは社会的影響が大きいため、情報サービス局の役割も重要になる。

何が決まっているのか。

何が実験段階なのか。

何がまだ決まっていないのか。

を明確に伝える。

[
\boxed{
Research
\neq
Decision
}
]

をCommunicationでも維持する。

────────

Public Feedback

必要に応じて外部Stakeholderの意見を収集する場合、

それを、

[
\boxed{
ExternalInput
}
]

としてProjectへ接続する。

しかしPublic OpinionそのものをPolicy Authorityにはしない。

────────

Governance Record

CBDC Projectでは、

Design Change。

Experiment Result。

Risk Finding。

Decision。

を全て記録する。

これにより、

[
\boxed{
Why\ did\ this\ design\ evolve?
}
]

を後から追跡できる。

────────

CBDC Knowledge Graph

最終的には、

[
CBDC
]

を中心に、

Law。

Technology。

Payment。

Financial Stability。

Research。

International Standards。

Experiments。

を接続したKnowledge Graphができる。

────────

Dynamic OrganizationとしてのCBDC

CBDC Projectが示す最も重要な点は、Technologyではない。

組織Architectureである。

一つの局がすべてを所有するのではない。

複数Capabilityを接続する。

しかしAuthorityとResponsibilityは明確にする。

つまり、

[
\boxed{
CrossFunctional
+
Governed
+
Temporary
}
]

である。

────────

恒常化するCapability

CBDC Projectが長期化し、一部Capabilityが恒常的に必要になれば、

そのCapabilityだけをPermanent Organizationへ戻す、あるいは恒常化することを検討できる。

つまり、

[
Project
\rightarrow
Learning
\rightarrow
PermanentCapability
]

である。

────────

CBDC Projectの最小式

ここまでを圧縮すると、

[ \boxed{ CBDCProject

Money
+
Payment
+
Law
+
Technology
+
FinancialStability
+
Privacy
+
Security
+
International
}
]

となる。

しかしそれ以上に重要なのは、

[ \boxed{ CBDC

Cross\text{-}functional\ Institutional\ Experiment
}
]

として扱うことである。

────────

CBDCが示すDynamic Organization

CBDCを通じて、日本銀行Digital TwinのDynamic Organizationは具体化する。

決済機構局の専門性は残る。

企画局の専門性も残る。

金融機構局も、システム情報局も、国際局も残る。

しかしProject期間中だけ、それらが一つのProblemの周囲へ接続される。

[
\boxed{
Stable\ Vertical
+
Dynamic\ Horizontal
}
]

である。

次節では、この構造をさらに、単一Projectでは捉えにくい複合Riskへ広げる。

対象は、

[
\boxed{
気候
+
Cyber
+
危機対応
}
]

である。

これらは時間軸、発生速度、影響領域が異なる。

それでも、中央銀行全体を横断するRiskとして、一つのDynamic Organization Architectureの中で記述しなければならない。
第5節　気候・サイバー・危機対応

日本銀行が直面する横断課題の中でも、

[
\boxed{
気候変動
+
Cyber
+
危機対応
}
]

は、CBDCとは異なる性質を持つ。

CBDCは、ある程度Projectとして設計できる。

一方、

気候変動は長期的で、影響が徐々に累積する。

Cyber Riskは高速で、突然顕在化する。

金融危機や巨大災害は、複数のSystemを同時に変化させる。

つまり、

[
\boxed{
Slow\ Risk
+
Fast\ Risk
+
Compound\ Crisis
}
]

を同じInstitutional Architectureで扱わなければならない。

ここで必要になるのが、

[
\boxed{
Adaptive\ Dynamic\ Organization
}
]

である。

────────

三つのRiskは時間軸が違う

まず、三つを同じRiskとして扱わない。

気候変動は、

[
Years
\rightarrow
Decades
]

で進行する。

Cyber Incidentは、

[
Seconds
\rightarrow
Hours
]

で発生する。

金融危機や災害は、

[
Minutes
\rightarrow
Years
]

にわたって影響する場合がある。

したがって、

[
\boxed{
One\ Risk\ Runtime
}
]

ではなく、

[
\boxed{
Multi\text{-}time\ Risk\ Architecture
}
]

を採用する。

────────

気候変動――Slow-moving Systemic Risk

気候変動を、日本銀行Digital Twin上では単なる環境テーマとして扱わない。

経済。

企業。

金融機関。

資産価格。

エネルギー。

地域。

国際金融。

へ波及し得る、

[
\boxed{
Slow\text{-}moving\ Systemic\ Risk
}
]

として位置づける。

────────

Climate Riskの二層

まず、

[
\boxed{
Physical\ Risk
}
]

と、

[
\boxed{
Transition\ Risk
}
]

を分ける。

Physical Riskは、

洪水。

台風。

高潮。

猛暑。

干ばつ。

などの物理的影響である。

Transition Riskは、

エネルギー転換。

規制変更。

技術変化。

需要構造変化。

などによる経済・金融上の影響である。

────────

Climate State

Digital Twinでは、

```text id="climate1"
ClimateRiskState
├── physical_risk
├── transition_risk
├── regional_exposure
├── sector_exposure
├── financial_exposure
├── scenario
└── time_horizon
```

として扱う。

────────

地域との接続

気候Riskは全国一様ではない。

沿岸地域。

豪雨Riskが高い地域。

農業地域。

エネルギー多消費産業集積地。

では影響が異なる。

したがって、

[
\boxed{
ClimateRisk(region,t)
}
]

を32支店・14国内事務所のRegional Twinへ接続する。

────────

金融機関との接続

企業や不動産へのClimate Exposureは、

融資。

担保。

保険。

資産価格。

を通じて金融機関へ伝播し得る。

したがって、

[
ClimateShock
\rightarrow
Firm
\rightarrow
Asset
\rightarrow
FinancialInstitution
]

というGraphを持つ。

金融機構局Twinと接続する。

────────

Climate Scenario

気候変動では一点Forecastより、

[
\boxed{
Long\text{-}horizon\ Scenario
}
]

が重要になる。

例えば、

秩序ある移行。

遅延移行。

高いPhysical Risk。

など複数Scenarioを比較する。

────────

気候を金融政策に直結させない

気候変動が重要だからといって、

[
ClimateMetric
\rightarrow
PolicyDecision
]

と直接結ばない。

経済・物価・金融システムへのTransmissionを通じて評価する。

────────

Climate Coordination

気候は、

国際局。

金融機構局。

調査統計局。

企画局。

支店。

金融研究所。

など複数Moduleを横断する。

したがって、

[
\boxed{
Climate\ Cross\text{-}functional\ Network
}
]

として扱う。

恒常的な専門CapabilityとTemporary Projectを組み合わせる。

────────

Cyber――Fast-moving Operational Risk

Cyber Riskは気候と正反対の時間を持つ。

攻撃は瞬間的に発生し得る。

したがって、

[
\boxed{
Fast\text{-}moving\ Operational\ Risk
}
]

として扱う。

対象は、

System。

Network。

Endpoint。

Identity。

Data。

Vendor。

AI。

決済Infrastructure。

などである。

────────

Cyber Risk State

```text id="cyber1"
CyberRiskState
├── threat
├── vulnerability
├── asset
├── exposure
├── incident_state
├── operational_impact
└── containment_state
```

として記述する。

────────

ThreatとIncidentを分ける

脅威があることと、Incidentが起きたことは違う。

[
Threat
\neq
Incident
]

である。

さらに、

[
Alert
\neq
ConfirmedCompromise
]

も維持する。

────────

Cyber Architecture

Cyber対応には、

[
Detect
\rightarrow
Contain
\rightarrow
Eradicate
\rightarrow
Recover
\rightarrow
Learn
]

というLifecycleを持たせる。

────────

Cyberはシステム情報局だけの課題ではない

システム情報局は中心Capabilityを持つ。

しかし重大Incidentでは、

決済機構局。

業務局。

金融市場局。

情報サービス局。

政策委員会室。

総務人事局。

なども関係する。

したがって、

[ \boxed{ CyberSecurity

Technical
+
Operational
+
Governance
+
Communication
}
]

である。

────────

Cyber Task Force

重大Incidentでは、

[
\boxed{
Cyber\ Task\ Force
}
]

を組成する。

Primary Technical Lead。

Operational Lead。

Communication Lead。

Legal / Compliance。

Executive Sponsor。

を明確にする。

────────

Cyber Authority

Cyber Incidentで重要なのは、

誰がSystemを隔離できるか。

誰がServiceを止められるか。

誰がFallbackへ切り替えられるか。

である。

したがって、

[
\boxed{
Predefined\ Emergency\ Authority
}
]

を持つ。

────────

Kill SwitchとSafe Isolation

一部Systemでは、

[
\boxed{
Safe\ Isolation
}
]

が必要になる。

疑わしいSystemをNetworkから切り離す。

ただし、Isolation自体が決済や市場業務を停止させる可能性がある。

したがって、

[
SecurityRisk
\leftrightarrow
OperationalRisk
]

を比較する。

────────

Cyber Resilience

目的は攻撃を100％防ぐことではない。

[
\boxed{
Prevent
+
Detect
+
Recover
}
]

である。

必ず突破され得る前提でResilienceを設計する。

────────

Vendor / Supply Chain Risk

Cyber Riskは内部だけではない。

Cloud Provider。

Software Vendor。

Hardware。

外部Data Provider。

などへの依存がある。

したがって、

[
\boxed{
CyberSupplyChainGraph
}
]

を持つ。

────────

AI Security

AI導入によって、

Prompt Injection。

Data Leakage。

Model Manipulation。

Tool Abuse。

など新しいRiskも増える。

したがって、

[
CyberArchitecture
]

と、

[
AIArchitecture
]

を接続する。

────────

危機対応――Compound Risk

中央銀行の危機は、一つのRiskだけでは終わらない。

例えば、

巨大地震。

停電。

通信障害。

現金需要急増。

決済障害。

市場Stress。

が同時に発生する可能性がある。

したがって、

[
\boxed{
Compound\ Crisis
}
]

を前提にする。

────────

Crisis State

Digital Twinでは、

```text id="crisis1"
CrisisState
├── trigger_events
├── severity
├── affected_regions
├── affected_functions
├── market_state
├── financial_system_state
├── payment_state
├── cash_state
├── system_state
├── workforce_state
└── external_dependencies
```

として統合する。

────────

一つの危機Dashboardに全部入れない

危機時に必要なのは情報量ではなく優先順位である。

したがって、

[
\boxed{
Critical\ State
}
]

だけを上位に出す。

Current Situation。

Critical Dependencies。

Immediate Decisions。

Recovery Status。

を中心とする。

────────

Crisis Topology

危機時には組織Networkそのものが変わる。

通常時：

[
StableVertical
]

危機時：

[
StableVertical
+
TaskForce
+
ExternalCoordination
]

となる。

つまり、

[
\boxed{
OrganizationTopology(t)
}
]

である。

────────

Crisis CommandとInstitutional Authority

危機対応を効率化するために、指揮系統を明確にする。

しかし、

[
CrisisCommander
]

が無制限Authorityを持つわけではない。

法令・規程でReservedされたAuthorityは残る。

────────

Decision Rights

危機時には、

[
\boxed{
Decision\ Rights
}
]

を事前定義する。

誰が、

Systemを止める。

支店業務を代替する。

現金供給を調整する。

外部機関へ連絡する。

Public Communicationを出す。

を決められるか。

────────

Decision Latency

危機対応では時間そのものがRiskになる。

したがって、

[
\boxed{
Time\ to\ Decision
}
]

を観測する。

しかし、速いだけのDecisionを目指さない。

[
Fast
+
Authorized
+
Traceable
]

が必要になる。

────────

Crisis Playbook

代表的な危機について、

[
\boxed{
Playbook
}
]

を持たせる。

Cyber Incident。

Payment Failure。

Market Shock。

Earthquake。

Pandemic。

などである。

────────

Playbookを固定しすぎない

現実の危機はPlaybook通りには起きない。

したがって、

[ Playbook

Default\ Response
]

であり、

[
Reality
]

に応じて調整する。

────────

Scenario Library

過去事例とSimulationを、

[
\boxed{
Crisis\ Scenario\ Library
}
]

として蓄積する。

これにより、未知の危機でも類似構造を検索できる。

────────

Compound Scenario

例えば、

[
Earthquake
+
CyberAttack
+
LiquidityStress
]

のような複合Scenarioを作る。

Digital Twinの価値は、単一Risk Modelを越えて複数Domainを接続できることにある。

────────

Regional Crisis

災害では地域差が極めて大きい。

したがって、

[
BranchTwin
+
DomesticOfficeTwin
]

をCrisis Architectureへ直接接続する。

各地域の、

Facility。

Cash。

System。

Workforce。

Economic Impact。

を観測する。

────────

Cash as Resilience

通信や決済が制約される危機では、現金の役割が高まる。

したがって発券局・支店のCash Stateを、

[
\boxed{
Resilience\ Asset
}
]

として扱う。

CBDCなどDigital Moneyだけを前提にしない。

────────

Human Resilience

危機時には人材も制約される。

出勤不能。

交代。

疲労。

長時間対応。

がある。

したがって、

[
\boxed{
Human\ Capacity
}
]

をCritical Resourceとして扱う。

────────

Shift Rotation

長期危機では、

Role Handover。

Backup Role。

Shift Rotation。

をDigital Twinで管理する。

Institutional Memoryを個人の記憶だけに依存させない。

────────

External Coordination

危機時には、

政府。

金融庁。

金融機関。

決済・清算機関。

地方公共団体。

外国中央銀行。

国際機関。

とのCoordinationが増える。

したがって、

[
\boxed{
Crisis\ External\ Network
}
]

を動的に形成する。

────────

情報共有の境界

危機だからといって、すべての情報をすべての外部機関へ共有するわけではない。

[
NeedToKnow
+
LegalBasis
+
Purpose
]

に基づいて共有する。

────────

Public Communication

金融危機や大規模障害では、CommunicationそのものがInstitutional Actionになる。

誤解。

不安。

噂。

が市場や社会へ影響する可能性がある。

したがって、

[
\boxed{
Crisis\ Communication
}
]

をRisk Responseの一部として扱う。

────────

Authoritative Communication

危機時ほど、

何が正式情報なのか。

何が未確認なのか。

を明確にする。

AI生成文をそのままPublic Statementにしない。

Human Approvalを通す。

────────

ClimateとCrisisの接続

気候変動はSlow Riskだが、最終的には、

豪雨。

洪水。

台風。

などのAcute Crisisとして現れる。

したがって、

[
ClimateScenario
\rightarrow
RegionalCrisisScenario
]

を接続する。

────────

CyberとFinancial Crisisの接続

Cyber Incidentも、単なるIT障害では終わらない。

決済停止。

市場不安。

Liquidity Stress。

へ波及する可能性がある。

したがって、

[
Cyber
\rightarrow
Operations
\rightarrow
Finance
]

をSimulationする。

────────

Riskの連鎖

ここで三つを統合すると、

[
\boxed{
Risk
\rightarrow
Propagation
\rightarrow
InstitutionalResponse
}
]

という共通構造が見える。

Riskの種類は違う。

しかしArchitectureは共通化できる。

────────

Common Risk Object

例えば、

```text id="risk1"
RiskEvent
├── risk_type
├── trigger
├── probability_or_plausibility
├── impact
├── velocity
├── time_horizon
├── affected_domains
├── dependencies
└── response_mode
```

とする。

────────

Risk Velocity

特に重要なのが、

[
\boxed{
Velocity
}
]

である。

気候RiskはSlow。

CyberはFast。

金融市場ShockはVery Fast。

これによって必要なResponse Architectureを変える。

────────

Risk Horizon × Velocity

したがって、

[ \boxed{ Risk

Impact
+
Horizon
+
Velocity
+
Interdependence
}
]

として扱う。

単一Risk Scoreへ圧縮しない。

────────

Dynamic Organization Selection

Riskの性質に応じて、

通常Function。

Cross-functional Project。

Task Force。

のどれを使うか決める。

例えば、

長期Climate Research。

→ Project。

重大Cyber Incident。

→ Task Force。

通常のSystem改善。

→ Functional Organization。

となる。

────────

Organization Routing

つまり、

[
Problem
\rightarrow
Urgency
\rightarrow
Uncertainty
\rightarrow
RequiredCapabilities
\rightarrow
OrganizationMode
]

である。

────────

AIの役割

AIは、

Risk Detection。

Scenario Generation。

Event Summarization。

Dependency Mapping。

Historical Retrieval。

を支援できる。

しかし、

[
\boxed{
AI\ RiskScore
\neq
Institutional\ CrisisDeclaration
}
]

である。

────────

Autonomous Crisis Declarationをしない

AIがSeverityを推定しても、Crisis Modeへの移行はAuthorized Roleが決める。

これはHuman-authoritative Architectureの重要な境界である。

────────

Continuous Monitoring

気候、Cyber、Operational Riskの一部は、

[
\boxed{
Continuous\ Monitoring
}
]

が可能になる。

しかしAlertを大量に出しても意味がない。

────────

Signal-to-Noise

したがって、

[
\boxed{
Signal\ Quality
}
]

を評価する。

False Positive。

False Negative。

Alert Fatigue。

を監視する。

────────

Resilience Metrics

Resilienceを、

「障害が起きなかったか」

だけでは測らない。

Detect Time。

Decision Time。

Containment Time。

Recovery Time。

Fallback Success。

Learning Completion。

を測る。

────────

Recoveryだけで終わらない

危機対応の最終Stateは、

[
Recovered
]

ではない。

[
\boxed{
Learned
}
]

まで進む。

────────

After Action Review

各危機後に、

何が起きたか。

どのControlが機能したか。

どこにBottleneckがあったか。

を検証する。

そして、

Process。

Playbook。

System。

Capability。

へFeedbackする。

────────

Organizational Learningへの接続

これによって、

[
Crisis
\rightarrow
Review
\rightarrow
Learning
\rightarrow
CapabilityImprovement
]

という循環が成立する。

次節のOrganizational Learningへ直接つながる。

────────

気候・サイバー・危機対応の最小式

ここまでを圧縮すると、

[ \boxed{ RiskArchitecture

Observe
+
Assess
+
Simulate
+
Respond
+
Recover
+
Learn
}
]

となる。

さらに組織Architectureとしては、

[
\boxed{
StableVertical
+
CrossFunctionalProject
+
TaskForce
}
]

をRiskの時間軸と速度に応じて使い分ける。

────────

Dynamic Organizationの核心

気候変動では、長期的なCapabilityを育てる。

Cyberでは、秒単位の対応Capabilityを持つ。

金融危機や災害では、多数のModuleを短時間に接続する。

しかし、どの場合でも、

[
\boxed{
Law
+
Authority
+
Responsibility
}
]

は維持される。

これがDynamic Organizationの核心である。

────────

次のOrganizational Learningへ

Projectは終了する。

Task Forceも解散する。

危機もいつかRecoveryへ移る。

しかし、そこで得られたKnowledgeが消えれば、Institutionは同じ問題を繰り返す。

したがって次に必要なのは、

[
\boxed{
Organizational\ Learning
}
]

である。

次節では、

Project。

Task Force。

Simulation。

Incident。

Decision。

の結果を、Stable Verticalへ戻し、

[
\boxed{
経験が消えず、次のCapabilityへ変わる仕組み
}
]

を記述する。
第6節　Organizational Learning

Dynamic Organizationの目的は、ProjectやTask Forceを作ることではない。

本当に重要なのは、

[
\boxed{
経験を次の能力へ変えること
}
]

である。

Cross-functional Projectが終わる。

Task Forceが解散する。

危機が収束する。

Simulationが完了する。

しかし、その成果、失敗、判断、例外、発見が個人や一時的な共有Folderに残ったまま消えてしまえば、Institutionは学習しない。

したがって、日本銀行Digital Twinには、

[
\boxed{
Organizational\ Learning
}
]

というFeedback Architectureが必要になる。

────────

学習するのはAIではなくInstitutionである

最初に区別する。

[
MachineLearning
]

と、

[
OrganizationalLearning
]

は同じではない。

Machine LearningはModelがDataからPatternを更新する。

Organizational Learningは、

人間。

Process。

Rule。

Model。

System。

Capability。

Organization。

が経験から更新されることである。

したがって、

[
\boxed{
OrganizationalLearning



ModelRetraining
}
]

である。

────────

Learning Loop

最小構造は、

[
\boxed{
Experience
\rightarrow
Review
\rightarrow
Knowledge
\rightarrow
Change
\rightarrow
Verification
}
]

である。

さらに実務へ戻すと、

[
Action
\rightarrow
Outcome
\rightarrow
Learning
\rightarrow
UpdatedCapability
\rightarrow
NextAction
]

という循環になる。

────────

何から学ぶのか

Institutionが学ぶSourceは多い。

Policy Decision。

Project。

Task Force。

Incident。

Audit Finding。

Inspection。

Simulation。

Model Error。

Regional Observation。

Research。

External Institution。

これらを、

[
\boxed{
LearningSource
}
]

として統合する。

────────

Learning Record

例えば、

```text
LearningRecord
├── learning_id
├── source_type
├── source_reference
├── observation
├── root_cause
├── lesson
├── affected_capabilities
├── recommended_change
├── owner
├── verification
└── status
```

とする。

単なる「振り返りメモ」にしない。

────────

LessonとFactを分ける

あるIncidentから得られたLessonは、

[
Fact
]

そのものではない。

解釈である。

したがって、

[
\boxed{
ObservedOutcome
\neq
Lesson
}
]

を維持する。

まず何が起きたかを記録する。

その後で、なぜ起きたか、何を変えるべきかを分析する。

────────

After Action Review

ProjectやTask Force終了後には、

[
\boxed{
After\ Action\ Review
}
]

を行う。

何を目指したか。

何が起きたか。

何がうまくいったか。

何が想定と違ったか。

何を次回変えるべきか。

を整理する。

────────

BlameからStructureへ

Organizational Learningで重要なのは、個人の失敗だけへ還元しないことである。

問題の原因が、

Process。

Authority。

Data。

System。

Capability。

Communication。

にある可能性もある。

したがって、

[
\boxed{
PersonError
\rightarrow
SystemicContext
}
]

まで見る。

もちろんAccountabilityは維持する。

しかし、再発防止にはStructureの理解が必要になる。

────────

Root Cause Analysis

例えば、

```text
RootCause
├── human_factor
├── process_gap
├── control_gap
├── data_gap
├── system_gap
├── model_gap
├── governance_gap
└── external_dependency
```

として複数要因を扱う。

一つの原因へ無理に圧縮しない。

────────

Project Learning

Cross-functional Projectからは、

新しいCapability。

新しいData Contract。

新しいSystem。

新しいOperational Practice。

が生まれる。

これをPermanent Organizationへ戻す。

[
\boxed{
Project
\rightarrow
PermanentCapability
}
]

である。

────────

Task Force Learning

Task Forceからは、

危機時Decision Path。

Communication。

Fallback。

Authority。

Dependency。

について多くのLearningが得られる。

これらは、

Playbook。

Training。

BCP。

System Design。

へ戻す。

────────

Simulation Learning

SimulationもLearning Sourceである。

Scenarioを実行した結果、

どのCapabilityが弱いか。

どのDependencyが集中しているか。

どのRecoveryが遅いか。

を検出する。

つまり、

[
Simulation
\rightarrow
CapabilityImprovement
]

である。

────────

Realityが最大の検証者

ただしSimulationだけでは不十分である。

最終的には、

[
\boxed{
Observed\ Reality
}
]

との比較が必要になる。

予想したOutcome。

実際のOutcome。

の差を見る。

────────

Prediction Errorだけではない

差があった場合、

Modelが悪かったとは限らない。

Dataが改定された。

External Shockが発生した。

Policy Transmissionが変化した。

Structureが変わった。

可能性もある。

したがって、

[
\boxed{
Error
\rightarrow
Diagnosis
}
]

を行う。

────────

Model Learning

Modelについては、

Performance。

Drift。

Assumption Failure。

を検証する。

必要なら、

Recalibrate。

Retrain。

Replace。

Retire。

を行う。

────────

Process Learning

Business Processについては、

Bottleneck。

Exception。

Approval Delay。

Duplicate Work。

を分析する。

必要なら、

[
Process_v1
\rightarrow
Process_v2
]

へ更新する。

────────

Rule Learning

規程やControlについても、運用実態から課題が見つかることがある。

ただしSystemが勝手にRuleを書き換えない。

[
\boxed{
Learning
\rightarrow
RuleChangeProposal
}
]

までである。

正式な改正はAuthority Processを通る。

────────

Organization Learning

同じ横断Projectが繰り返される場合、

それは一時課題ではなくPermanent Capabilityになっている可能性がある。

例えば、

[
RepeatedProject
\rightarrow
PermanentNeed
]

なら、

組織配置を見直す材料になる。

────────

DynamicからStableへ戻す

これがDynamic Organizationの重要な循環である。

[
StableVertical
\rightarrow
DynamicHorizontal
\rightarrow
Learning
\rightarrow
UpdatedStableVertical
]

となる。

Dynamic OrganizationはStable Organizationの外側にあるのではない。

Stable Structureを進化させるFeedback Mechanismである。

────────

Knowledge Return

ProjectやTask Forceで得られたKnowledgeは、

Document。

Data。

Code。

Model。

Decision。

Lesson。

としてInstitutional Memoryへ戻す。

これを、

[
\boxed{
Knowledge\ Return\ Protocol
}
]

とする。

────────

Knowledge Owner

戻されたKnowledgeにはOwnerを決める。

誰が更新するのか。

誰がCurrent Versionを管理するのか。

誰が古くなったか判断するのか。

を明確にする。

────────

Learning Backlog

すべての改善を即時実施できるとは限らない。

そこで、

[
\boxed{
Learning\ Backlog
}
]

を持つ。

```text
LearningBacklog
├── item
├── priority
├── owner
├── affected_capability
├── expected_value
├── implementation_cost
├── target_date
└── status
```

として管理する。

────────

優先順位

改善項目は、

Risk Reduction。

Institutional Importance。

Frequency。

Cost。

Urgency。

で優先順位をつける。

ただし単一Scoreへ過剰に圧縮しない。

────────

Learning Debt

改善項目を長期間放置すると、

[
\boxed{
Learning\ Debt
}
]

が蓄積する。

既知の弱点。

繰り返すIncident。

古いProcess。

未更新Model。

が残る。

Digital Twinではこれを可視化する。

────────

再発を見る

同じFindingやIncidentが繰り返される場合、

[
\boxed{
RecurringPattern
}
]

として検出する。

一回の偶発事象ではなくStructural Problemかもしれない。

────────

Cross-module Learning

ある局で得られたLessonが、他局にも有効な場合がある。

例えば、

Cyber Incidentで得たAccess Control上のLesson。

支店災害対応で得たCommunication上のLesson。

これを、

[
\boxed{
Cross\text{-}module\ Learning
}
]

として共有する。

────────

ただしContextを消さない

他局へLessonを移す場合も、

[
Context
]

を保持する。

ある局で有効だった改善が、別局でも同じとは限らない。

したがって、

[
TransferableLesson
\neq
UniversalRule
]

である。

────────

Learning Graph

最終的には、

[
\boxed{
Learning\ Graph
}
]

を形成できる。

[
Incident
\rightarrow
Lesson
\rightarrow
ProcessChange
\rightarrow
Capability
]

[
Project
\rightarrow
Knowledge
\rightarrow
Training
\rightarrow
Role
]

[
ModelFailure
\rightarrow
ModelChange
\rightarrow
DecisionSupport
]

と接続する。

────────

Institutional Memoryとの統合

Organizational Learningは、Document / Knowledge Architectureと統合される。

過去のLessonを検索できる。

類似Incidentを検索できる。

過去の改修理由を確認できる。

これによって、

[
\boxed{
Memory
\rightarrow
Operational\ Reuse
}
]

が成立する。

────────

Training

LearningをDocumentに保存するだけでは不十分である。

人間のCapabilityへ戻す必要がある。

そこで、

[
\boxed{
Training
}
]

へ接続する。

────────

Role-based Training

すべての職員へ同じTrainingを行わない。

Risk。

Role。

Capability。

に応じて、

[
Learning
\rightarrow
RequiredRoles
\rightarrow
Training
]

とする。

────────

Exercise

危機対応のLessonは、

Tabletop Exercise。

Simulation Exercise。

へ戻す。

次回の危機前に検証する。

────────

Exercise → Learning → Exercise

これによって、

[
\boxed{
Exercise
\rightarrow
Learning
\rightarrow
UpdatedExercise
}
]

という循環ができる。

実際の危機だけを学習機会にしない。

────────

AIによるLearning Support

AIは、

過去Incident検索。

Recurring Pattern抽出。

Lesson候補整理。

Knowledge Linkage。

を支援できる。

しかし、

[
\boxed{
AI
\neq
Final\ RootCauseAuthority
}
]

である。

原因分析や制度変更にはHuman Reviewを残す。

────────

AI自身も学習対象になる

AI ArchitectureもOrganizational Learningの対象である。

どのAgentが役立ったか。

どこでHallucinationしたか。

どのPromptが不安定だったか。

どのTool Permissionが広すぎたか。

を検証する。

────────

Model Retrainingを自動化しすぎない

新しいDataが入ったからといって、AI Modelを自動でProduction更新するとは限らない。

[
Retrain
\rightarrow
Validate
\rightarrow
Approve
\rightarrow
Deploy
]

を維持する。

────────

Human Learning

Institutional Learningは、人間の経験知も含む。

しかし経験知を属人化したままにはしない。

Mentoring。

Training。

Documentation。

Role Handover。

を使う。

────────

Tacit Knowledge

すべてを完全なDocumentへ変換できるわけではない。

そこで、

[
\boxed{
Tacit\ Knowledge
}
]

の存在を前提にする。

人から人へ継承すべきKnowledgeもある。

Digital Twinは、その継承が必要なCapabilityを可視化する。

────────

Succession Risk

重要Capabilityが一人に集中している場合、

[
\boxed{
Knowledge\ Concentration\ Risk
}
]

となる。

総務人事局Twinと接続して、Backup RoleやSuccessionを設計する。

────────

External Learning

日本銀行の学習Sourceは内部だけではない。

外国中央銀行。

国際機関。

大学。

市場。

技術Community。

からも学ぶ。

したがって、

[
\boxed{
External\ Learning\ Network
}
]

を持つ。

────────

外部事例をそのまま移植しない

他国中央銀行で成功した方法が、日本銀行にそのまま適用できるとは限らない。

制度。

法律。

市場構造。

組織。

が異なる。

したがって、

[
ExternalPractice
\rightarrow
ContextualEvaluation
\rightarrow
PossibleAdoption
]

とする。

────────

Learning Velocity

Institutionがどれだけ速く学べるかも重要になる。

Incident発生からLesson抽出まで。

Lessonから改善実装まで。

改善からVerificationまで。

の時間を測る。

これを、

[
\boxed{
Learning\ Velocity
}
]

とする。

────────

速ければよいわけではない

急いで改善すると、新たなRiskを生むこともある。

したがって、

[
Speed
+
Validation
]

を両立する。

────────

Continuous Improvement

Organizational Learningが定着すると、

大規模改革を繰り返すだけではなく、

[
\boxed{
Continuous\ Improvement
}
]

が可能になる。

小さなProcess改善。

Data品質改善。

Model更新。

Training更新。

を継続する。

────────

Continuous LearningとInstitutional Stability

中央銀行では、変化し続けること自体が目的ではない。

必要なのは、

[
\boxed{
Stable\ Core
+
Continuous\ Learning
}
]

である。

法的・制度的安定性を保持しながら、能力を改善する。

────────

Learning Governance

学習にもGovernanceが必要である。

誰がLessonを承認するか。

誰がProcess変更を決めるか。

誰がModel更新を承認するか。

を明確にする。

学習を理由に、Authorityを迂回しない。

────────

Change Proposal

したがって、

[
Learning
]

から直接、

[
Change
]

へ飛ばない。

[
\boxed{
Learning
\rightarrow
ChangeProposal
\rightarrow
AuthorityReview
\rightarrow
Implementation
}
]

となる。

────────

Verification

改善した後には、

本当に改善されたかを確認する。

これを、

[
\boxed{
Closed\text{-}loop\ Learning
}
]

とする。

改善したつもりで終わらない。

────────

Learning Closure

例えば、

```text
LearningClosure
├── change_implemented
├── verification_method
├── verification_result
├── residual_risk
└── closed_at
```

として記録する。

────────

Organizational Learningの最小式

ここまでを圧縮すると、

[ \boxed{ OrganizationalLearning

Experience
+
Review
+
Knowledge
+
Change
+
Verification
}
]

となる。

さらにDynamic Organizationとの関係では、

[
\boxed{
DynamicHorizontal
\rightarrow
Learning
\rightarrow
UpdatedStableVertical
}
]

となる。

────────

学習する中央銀行

このArchitectureが実装されると、日本銀行は単に過去の記録を保存するInstitutionではなくなる。

Projectから学ぶ。

危機から学ぶ。

Simulationから学ぶ。

地域から学ぶ。

世界から学ぶ。

Model Errorから学ぶ。

そして、その学習を、

Process。

Capability。

System。

Human。

へ戻す。

これが、

[
\boxed{
Learning\ Institution
}
]

としての中央銀行である。

────────

第5章の最終統合へ

ここまでで、

Functional Organization。

Cross-functional Project。

Task Force。

CBDC。

気候・Cyber・危機対応。

Organizational Learning。

が揃った。

次節では、これらを一つのOrganization Principleとして統合する。

それが、

[
\boxed{
Stable\ Vertical
\times
Dynamic\ Horizontal
}
]

である。

日本銀行の縦割りを壊さない。

しかし、課題が局境界を越えたときには、必要なCapabilityを横断的に組成する。

そして経験を再びStable Verticalへ戻す。

その循環によって、日本銀行Digital TwinのDynamic Organization Architectureが完成する。
第7節　Stable Vertical × Dynamic Horizontal

ここまで、第5章では日本銀行の組織を二つの異なる構造として記述してきた。

一つは、

[
\boxed{
Stable\ Vertical
}
]

である。

政策委員会室。

検査室。

企画局。

金融機構局。

決済機構局。

金融市場局。

調査統計局。

国際局。

発券局。

業務局。

システム情報局。

情報サービス局。

総務人事局。

文書局。

金融研究所。

これらPermanent Functional Modulesが、専門性、責任、Authority、Institutional Memoryを保持する。

もう一つは、

[
\boxed{
Dynamic\ Horizontal
}
]

である。

Cross-functional Project。

Task Force。

CBDC Project。

気候対応。

Cyber対応。

危機対応。

こうした横断構造が、課題に応じて複数ModuleのCapabilityを一時的に接続する。

この二つは対立するものではない。

むしろ、日本銀行Digital TwinにおけるOrganization Architectureは、

[
\boxed{
Stable\ Vertical
\times
Dynamic\ Horizontal
}
]

によって完成する。

────────

Stableだけでは足りない

Stable Verticalには大きな強みがある。

専門性が蓄積する。

責任が明確になる。

Authorityが追跡できる。

人材を育てられる。

Knowledgeが蓄積する。

Controlを設計しやすい。

しかしStable Verticalだけでは、組織境界を越えるProblemへの対応が弱くなりやすい。

CBDC。

Cyber。

気候。

金融危機。

巨大災害。

AI Governance。

こうした課題は、

[
Department_A
]

だけでは完結しない。

────────

Dynamicだけでも足りない

一方、すべてをProject型にすればよいわけでもない。

常に人員を組み替える。

ProjectごとにAuthorityを作る。

Knowledgeが一時組織へ分散する。

責任の所在が曖昧になる。

その結果、

[
\boxed{
Institutional\ Instability
}
]

を生む可能性がある。

中央銀行のような高信頼Institutionでは、これは大きなRiskになる。

────────

二層組織

したがって、組織を二層として設計する。

第一層は、

[
\boxed{
Permanent\ Functional\ Layer
}
]

第二層は、

[
\boxed{
Temporary\ Problem\ Layer
}
]

である。

Permanent Layerは組織を保持する。

Temporary Layerは課題に応じて組成される。

────────

Organization Matrix

概念的には、

[ \boxed{ Organization

Function
\times
Problem
}
]

となる。

縦軸にはFunction。

横軸にはProject / Risk / Crisis。

を置く。

例えば、

```text id="svdh1"
                CBDC   Cyber   Climate   Crisis
Policy             ●      ○        ●        ●
FinancialSystem    ●      ●        ●        ●
Payments           ●      ●        ○        ●
Markets            ○      ●        ○        ●
International      ●      ○        ●        ●
Systems            ●      ●        ○        ●
Research           ●      ○        ●        ○
```

のようなMatrixを持つことができる。

○や●は固定ではない。

Problemごとに必要Capabilityを割り当てる。

────────

DepartmentではなくCapabilityで横断する

このMatrixの核心は、

[
Department
\rightarrow
Project
]

を直接つなぐことではない。

まず、

[
Problem
\rightarrow
Capability
]

を定義することである。

その後、

[
Capability
\rightarrow
OwningModule
]

へ辿る。

したがって、

[
\boxed{
Problem
\rightarrow
Capability
\rightarrow
Module
\rightarrow
Role
}
]

がDynamic Horizontal生成の基本Algorithmになる。

────────

Organization Compiler

Digital Twin上では、この構造を一種の、

[
\boxed{
Organization\ Compiler
}
]

として考えることができる。

入力はProblemである。

例えば、

```text id="svdh2"
Input:
   major_payment_cyber_incident
```

そこから、

Required Capabilitiesを抽出する。

Cybersecurity。

Payment Operations。

Business Continuity。

Legal Review。

Communication。

Financial Stability。

そして、

ModuleとRoleを割り当てる。

最終的に、

[
\boxed{
TemporaryOrganization
}
]

を生成する。

────────

AIは組織を勝手に作らない

AIは、

必要Capability候補を抽出する。

過去の類似Projectを検索する。

人員Capacityを分析する。

ことはできる。

しかし、

[
AI
\rightarrow
OrganizationActivation
]

とはしない。

Cross-functional ProjectやTask Forceの設置には、適切なHuman Authorityを要求する。

────────

Permanent Role × Temporary Role

Dynamic Horizontalでは、人間が二つのRoleを持つ。

一つは、

[
PermanentRole
]

もう一つは、

[
TemporaryRole
]

である。

例えば、

金融市場局の職員でありながら、

Financial Crisis Task ForceのMemberでもある。

したがって、

```text id="svdh3"
RoleAssignment
├── permanent_role
├── temporary_role
├── authority_scope
├── allocation
├── start_time
└── end_time
```

として管理する。

────────

Authorityを二重化しない

二つのRoleを持つからといって、Authorityを曖昧にしない。

Permanent Roleとして決定できること。

Project Roleとして決定できること。

Reserved Matter。

を分ける。

[
\boxed{
RoleMultiplicity
\neq
AuthorityAmbiguity
}
]

である。

────────

Stable VerticalはDomain Ownershipを保持する

Dynamic ProjectへDataや人材を提供しても、

Domain OwnershipはPermanent Moduleに残る。

例えばCBDC Projectが決済Dataを使っても、

決済DataのOwnerは決済機構局側に残る。

したがって、

[
\boxed{
TemporaryUse
\neq
OwnershipTransfer
}
]

である。

────────

Dynamic HorizontalはInterfaceを使う

Projectが必要だからといって、各局のDatabaseへ直接接続しない。

API。

Event。

Data Contract。

Knowledge API。

を使う。

つまり、

[
\boxed{
Dynamic\ Horizontal
\text{ is built on }
Stable\ Interfaces
}
]

である。

────────

Stable Interfaceが横断性を高める

一見するとBoundaryが少ない方が柔軟に見える。

しかし実際には、明確なInterfaceがある方が組み替えやすい。

どのCapabilityが利用できるか。

どのDataが取得できるか。

どのApprovalが必要か。

が明確だからである。

したがって、

[
\boxed{
Clear\ Boundary
\rightarrow
Fast\ Composition
}
]

となる。

────────

Dynamic Topology

Permanent Organizationは比較的安定している。

しかし横断Networkは時間によって変わる。

したがって、

[
\boxed{
DynamicTopology(t)
}
]

を保持する。

Project開始。

参加Module追加。

Task Force拡大。

Recovery移行。

終了。

という変化を記録する。

────────

Organization State

例えば、

```text id="svdh4"
DynamicOrganizationState
├── active_projects
├── active_taskforces
├── participating_modules
├── temporary_roles
├── temporary_authorities
├── dependencies
├── capability_load
└── current_phase
```

を持つ。

────────

横断組織の負荷を見る

複数Projectが同時に走ると、同じCapabilityへ需要が集中する。

例えば、

Cybersecurity。

Legal Review。

Data Engineering。

が多くのProjectで必要になることがある。

そこで、

[
\boxed{
Capability\ Load
}
]

を観測する。

────────

Organizational Contention

あるCapabilityについて、

[
Demand



Capacity
]

になれば、

[
\boxed{
Organizational\ Contention
}
]

が起きる。

これを早期に検出する。

────────

Capability Bottleneck

繰り返しBottleneckになるCapabilityは、

単にProject管理の問題ではない。

Permanent Organization側のCapability不足かもしれない。

したがって、

[
RepeatedBottleneck
\rightarrow
CapabilityInvestmentCandidate
]

とする。

────────

Dynamic HorizontalがFuture Readinessを教える

この意味で、横断Projectは将来必要なCapabilityを発見するSensorでもある。

どのCapabilityが頻繁に必要になるのか。

どのSkillが不足するのか。

どのSystemが共通依存になるのか。

を観測できる。

────────

TemporaryからPermanentへ

例えば、あるTemporary Capabilityが、

複数年。

複数Project。

高いCriticality。

を持つようになれば、

[
\boxed{
PermanentCapabilityCandidate
}
]

になる。

つまり、

[
DynamicHorizontal
\rightarrow
Evidence
\rightarrow
StableVerticalChange
]

というFeedbackが成立する。

────────

PermanentからDynamicへ

逆方向もある。

Stable Verticalに蓄積された、

Knowledge。

人材。

System。

Capability。

がDynamic Horizontalへ供給される。

したがって、

[
\boxed{
Stable
\leftrightarrow
Dynamic
}
]

は双方向である。

────────

Learning Loop

この全体を循環として書くと、

[
\boxed{
StableVertical
\rightarrow
DynamicHorizontal
\rightarrow
Experience
\rightarrow
Learning
\rightarrow
UpdatedStableVertical
}
]

となる。

これは第5章全体の核心である。

────────

Projectは例外ではない

Cross-functional ProjectやTask Forceを「通常組織の外側の例外」と考えない。

Digital Twinでは、

[
\boxed{
DynamicOrganization
}
]

を最初からArchitectureの正式な一部として持つ。

通常時には休眠する。

必要なときにActivateする。

────────

Organization Modes

日本銀行Digital Twinは、少なくとも、

[
\boxed{
FunctionalMode
}
]

[
\boxed{
ProjectMode
}
]

[
\boxed{
TaskForceMode
}
]

[
\boxed{
CrisisMode
}
]

を持つ。

同じInstitutionが状況に応じてOrganization Modeを変える。

────────

Mode Transition

例えば、

```text id="svdh5"
FUNCTIONAL
  ↓
PROJECT
  ↓
TASK_FORCE
  ↓
CRISIS
  ↓
RECOVERY
  ↓
FUNCTIONAL
```

というTransitionもあり得る。

ただし必ずこの順に進むわけではない。

────────

Escalation

通常業務で処理できるならFunctional Mode。

複数局で計画的に扱うならProject Mode。

緊急性が高まればTask Force。

重大危機ならCrisis Mode。

というように、

[
\boxed{
Problem\ Severity
\rightarrow
Organization\ Mode
}
]

を選ぶ。

────────

De-escalation

重要なのはEscalationだけではない。

危機が収束したら、

Crisis。

Task Force。

Project。

通常組織。

へ戻す。

[
\boxed{
Dynamic\ Organization
\text{ must be reversible}
}
]

である。

────────

Temporary Authorityを回収する

De-escalation時には、

Temporary Role。

Emergency Authority。

Special Access。

Project Data Space。

を閉じる。

これによって平時のGovernanceへ戻る。

────────

Stable Vertical × Dynamic Horizontal × Human Authority

ここまでの二軸に、もう一つ重要な軸がある。

[
\boxed{
Human\ Authority
}
]

である。

Stable VerticalにもHuman Authorityがある。

Dynamic HorizontalにもTemporary Governanceがある。

しかし、どちらも法令・Institutional Authorityの内側にある。

したがって、

[
\boxed{
StableVertical
\times
DynamicHorizontal
\subset
HumanAuthoritativeInstitution
}
]

となる。

────────

AI時代にこの構造が重要になる理由

AIはModule間の情報境界を非常に低くする。

検索すれば他局のKnowledgeを瞬時に参照できる。

Agent同士も接続できる。

その結果、

[
\boxed{
InformationBoundary
}
]

が薄くなる。

しかし、

[
\boxed{
AuthorityBoundary
}
]

まで薄くしてはいけない。

────────

Semantic IntegrationとInstitutional Separation

したがってAI時代の理想は、

[
\boxed{
Semantically\ Integrated
+
Institutionally\ Governed
}
]

である。

Knowledgeは横断できる。

Dataも必要な範囲で接続できる。

しかしOwnershipとAuthorityは残る。

────────

Agentic Organization

将来、各ModuleにAI Agentが配置されると、

Market Agent。

Policy Agent。

Regional Agent。

Global Agent。

Risk Agent。

がProject単位で協調する可能性がある。

しかし、

[
AgentNetwork
]

はDynamic HorizontalのMachine Layerにすぎない。

────────

Agent Organization ≠ Institutional Organization

Agentが協調して結論を出しても、

それは、

[
\boxed{
Machine\ Coordination
}
]

である。

Institutional DecisionにはHuman Authorityが必要になる。

────────

Digital Twinが可能にするOrganization Visibility

Stable Vertical × Dynamic HorizontalをDigital Twinにすると、現在の組織状態を一つのGraphとして見られる。

どのProjectが動いているか。

どの局が参加しているか。

どのCapabilityが不足しているか。

どこに負荷が集中しているか。

どのAuthorityが付与されているか。

どのProjectが終了すべきか。

を可視化できる。

────────

Organization Digital Twin

ここで初めて、

[
\boxed{
Organization\ Digital\ Twin
}
]

が完成する。

単なる組織図ではない。

現在動いているFunctional Organization。

Temporary Project。

Task Force。

Role。

Capability。

Authority。

を時間軸で表現する。

────────

Future Organization Simulation

さらに、

「このProjectを追加したらどうなるか」

「Cyber Capabilityを増強したらどうなるか」

「このFunctionを別局へ移したらどうなるか」

をSimulationできる。

つまり、

[
\boxed{
Organization\ Simulation
}
]

が可能になる。

────────

Reorganization before Reorganization

組織改編を実際に行う前に、

Virtual Organization上で影響を検証する。

人員。

Capability。

Process。

Data Ownership。

System Dependency。

を比較する。

これにより、

[
\boxed{
Reorganization
\rightarrow
Simulation
\rightarrow
Implementation
}
]

という経路を作れる。

────────

Stable Vertical × Dynamic Horizontalの最小式

ここまでを圧縮すると、

[ \boxed{ StableVertical

PermanentFunction
+
DomainOwnership
+
Authority
+
Memory
}
]

である。

[ \boxed{ DynamicHorizontal

Problem
+
TemporaryCapabilityComposition
+
TemporaryGovernance
}
]

である。

そして両者を接続すると、

[ \boxed{ AdaptiveOrganization

StableVertical
\times
DynamicHorizontal
+
Learning
}
]

となる。

────────

第5章の到達点

第5章では、日本銀行の組織を、固定された組織図から動的なArchitectureへ拡張した。

Functional Organizationで専門性を保持した。

Cross-functional Projectで計画的横断を可能にした。

Task Forceで緊急横断を可能にした。

CBDCで長期横断テーマを具体化した。

気候・Cyber・危機対応で異なるRisk速度に対応した。

Organizational Learningで経験をStable Organizationへ戻した。

そして本節で、

[
\boxed{
Stable\ Vertical
\times
Dynamic\ Horizontal
}
]

として統合した。

────────

安定しながら変わる中央銀行

このArchitectureが意味するのは、

「柔軟な組織」

という抽象論ではない。

制度的な軸を維持する。

専門性を維持する。

責任を維持する。

しかし課題に応じて必要なCapabilityを接続する。

そして終了後に元へ戻す。

つまり、

[
\boxed{
Stable\ Enough\ to\ Govern
+
Dynamic\ Enough\ to\ Adapt
}
]

という中央銀行Architectureである。

────────

Dynamic OrganizationからFuture Readinessへ

しかし、ここまでのDynamic Organizationは、主として、

[
\boxed{
現在発生したProblemにどう対応するか
}
]

を扱ってきた。

次に問うべきなのは、

まだ問題が顕在化していない段階で、

未来に必要なCapabilityをどう先回りして設計するか。

である。

AI。

量子計算。

新しい決済。

人口構造。

気候変動。

地政学。

金融構造。

未来は現在の組織図を待ってくれない。

そこで次章では、

[
\boxed{
Future\ Readiness
}
]

へ進む。

Future Pullを完全に現文明のArchitectureへ翻訳し、

[
TargetState
\rightarrow
Backcasting
\rightarrow
Gap
\rightarrow
Capability
\rightarrow
Roadmap
]

として、日本銀行が未来を予言するのではなく、

[
\boxed{
未来の変化に備えられるInstitution
}
]

になるための設計を記述する。