『大和総研』――1953年から2050年へ、リサーチ・コンサルティング・金融システム・企業システム・ヘルステック・AIを接続する次世代AI完全実装コード大全（第5回）（第Ⅳ部　System 第4章　知をRealityへ変える――金融・企業・ヘルステック・基盤をProductionで動かす）

第Ⅳ部　System

Researchは、RealityをKnowledgeへ変えた。

Consultingは、KnowledgeをDecisionへ変えた。

しかし、DecisionだけではRealityは変わらない。

金融取引を成立させる。

顧客口座を管理する。

注文を処理する。

決済する。

企業業務を動かす。

健康保険業務を支える。

Dataを保存する。

Cloudを運用する。

Securityを維持する。

AIをProductionで動かす。

これらは、StrategyでもRecommendationでもない。

実行され続けるSystemである。

大和総研を理解するうえで、このLayerは決定的に重要である。

[
\boxed{
Knowledge
\rightarrow
Decision
\rightarrow
System
\rightarrow
Reality
}
]

第Ⅳ部では、大和総研を「知を生み出す企業」から、「知をProductionへ実装する企業」へ視点移動する。

⸻

大和総研のSystem Businessは、単なるSoftware Developmentではない。

2026年の実際の組織には、金融システム事業本部、企業システム事業本部、ヘルステック本部、基盤ソリューション本部が存在する。金融システム事業本部には大和証券システム本部が置かれ、企業システム事業本部にはAX本部が新設された。基盤ソリューション本部では、CloudとAI Trustを明示した組織再編も進んでいる。

ここに現れているのは、

Applicationだけではなく、Business・Data・Infrastructure・Security・Operationまで扱うSystem Capability

である。

SystemはCodeを書いた時点で完成しない。

Requirementを定義する。

Architectureを設計する。

Developmentする。

Testする。

Releaseする。

Productionで動かす。

Monitorする。

障害へ対応する。

Securityを更新する。

制度変更へ追随する。

そして次のRequirementへ戻る。

Requirement
   ↓
Architecture
   ↓
Development
   ↓
Test
   ↓
Production
   ↓
Operation
   ↓
Monitoring
   ↓
Change
   ↺

SystemとはProductではなく、Continuous Runtimeなのである。

⸻

とりわけ金融では、この意味が強い。

証券取引は、画面上のButtonだけで成立しているのではない。

Customer。

Account。

Order。

Execution。

Position。

Settlement。

Asset。

Cash。

Compliance。

Accounting。

Market。

これらが一貫して接続されなければならない。

一つのTransactionが、

[
Order
\rightarrow
Execution
\rightarrow
Settlement
\rightarrow
Record
]

として正しくState Transitionする。

金融Systemとは、金融という制度的RealityをSoftwareとして実行するArchitectureである。

大和総研は、大和証券グループのProduction Environmentを支えるだけでなく、Financial Plateをはじめとする金融機関向けSolutionを外部へ展開してきた。

ここでは、

Internal Knowledge
→ Standardization
→ Platform
→ External Capability

という別の生成経路が見えてくる。

⸻

企業Systemでは、さらに対象が広がる。

Customer Management。

Data Analysis。

Business Process。

Cloud。

Digital Transformation。

AI。

System Modernization。

企業の業務そのものがSoftwareへ埋め込まれている現在、企業TransformationとSystem Transformationを分離することは難しい。

Consultingで設計したDecisionが、

Strategy
  ↓
Business Requirement
  ↓
Process
  ↓
System Requirement
  ↓
Software
  ↓
Operation

としてRealityへ到達する。

2026年にAX本部が設けられたことも、この境界変化を象徴する。

AIを導入するだけではなく、AIを前提としてBusiness Process、Software Development、Organization、Operationを再設計する必要が生じている。

⸻

大和総研のSystem Capabilityは金融だけでもない。

HealthTechという別の社会基盤領域を持つ。

長年にわたって健康保険組合向けSystem・Serviceを蓄積し、現在ではHealth Data、Analytics、AIを接続する領域まで拡張している。

ここでは、

[
Social\ Insurance
\rightarrow
Health\ Data
\rightarrow
Analytics
\rightarrow
HealthTech
]

という流れが形成される。

金融SystemがCapitalとTransactionを扱うなら、HealthTechは社会保険とHealth Dataを扱う。

対象は異なる。

しかし共通するものがある。

大量のData。

制度。

Privacy。

Security。

Mission-critical Operation。

長期間のSystem Maintenance。

社会から要求されるTrust。

つまり大和総研には、

Financial Infrastructure

と

Social Infrastructure

をProductionで運用してきたCapabilityが蓄積されている。

⸻

その下にはInfrastructureがある。

Applicationだけを見ていてはSystem全体は理解できない。

Application
    ↓
Data
    ↓
Middleware
    ↓
Cloud / Infrastructure
    ↓
Network
    ↓
Security
    ↓
Operation

AI時代には、さらに、

Model
Agent
Vector
Knowledge
Policy
Identity
Audit

が加わる。

したがって次世代Systemは、

[
Application
+
Data
+
Cloud
+
AI
+
Security
+
Governance
+
Operation
]

として設計しなければならない。

Cloudは単なるHosting先ではない。

InfrastructureをProgrammableにし、System変更の速度、Resilience、Scalabilityを変えるRuntime Layerである。

⸻

そしてSystemにはTrustが必要である。

動けばよいわけではない。

正しい人だけがAccessできるか。

Dataは保護されているか。

変更履歴を追跡できるか。

障害を検知できるか。

Rollbackできるか。

AI Modelが更新されたとき影響を確認できるか。

Agentが許可されていないActionを実行しないか。

System Architectureそのものに、

Identity
→ Authorization
→ Execution
→ Monitoring
→ Audit

を埋め込む必要がある。

Governanceは第Ⅲ部だけの概念ではない。

Productionへ到達した瞬間、GovernanceはCodeとInfrastructureになる。

⸻

ここでResearch、Consulting、SystemのRelationが完成する。

Researchが制度変更を観測する。

ConsultingがBusiness Impactを分析する。

企業がDecisionする。

System Requirementへ翻訳される。

Softwareが変更される。

ProductionへDeployされる。

CustomerのRealityが変わる。

そこから新しいDataが生成される。

[
\boxed{
Research
\rightarrow
Consulting
\rightarrow
System
\rightarrow
Reality
\rightarrow
Data
\rightarrow
Research
}
]

これは抽象的な循環ではない。

Policy、金融制度、企業業務、System変更が接続される実務上のLoopである。

⸻

2050年からこのSystem Capabilityを見ると、Requirementはさらに広がる。

Financial Systemは、AI Agentと人間が共同で利用する。

Enterprise Systemは、Software Agent同士が連携する。

Cloudは複数環境を横断する。

Dataは企業境界を越えて接続される。

RegulationはよりMachine-readableになる可能性がある。

Cybersecurityは継続的な前提条件になる。

AI ModelそのものがProduction Componentになる。

それでも必要な原則は変わらない。

Correctness。
Availability。
Security。
Traceability。
Interoperability。
Human Authority。

未来のSystemほど、速さだけではなくTrustが重要になる。

⸻

第Ⅳ部では、大和総研が実際に持つSystem Capabilityを、Productionという観点から分解する。

金融システム事業本部。

Financial Platform。

企業システム事業本部。

ヘルステック本部。

基盤ソリューション本部。

Mission-Critical Runtime。

そして2050 Trusted Infrastructure。

生成軸は、

[
\boxed{
Requirement
\rightarrow
Architecture
\rightarrow
Code
\rightarrow
Production
\rightarrow
Operation
\rightarrow
Trust
}
]

である。

Researchは世界を理解する。

Consultingは何を選ぶかを設計する。

Systemは、その選択を実際に動かす。

ここから本書は、KnowledgeとDecisionの世界から、Software、Data、Cloud、Securityが絶えず実行される世界へ入る。

知をRealityへ変える。
第4章　知をRealityへ変える

――金融・企業・ヘルステック・基盤をProductionで動かす

第1節　金融システム事業本部

金融は、情報によって動いている。

顧客が注文する。

市場で約定する。

残高が変わる。

資金が移動する。

証券が受け渡される。

会計記録が更新される。

法令に基づく確認が行われる。

その一つひとつがDataとして記録され、SystemによってState Transitionされる。

したがって金融Systemは、金融Businessを支える裏方ではない。

金融というRealityそのものを実行するInfrastructureである。

大和総研の金融システム事業本部は、このProduction Layerを担う中核Capabilityの一つである。

[
\boxed{
Financial\ Rule
\rightarrow
System\ Requirement
\rightarrow
Code
\rightarrow
Transaction
\rightarrow
Financial\ Reality
}
]

⸻

金融をSoftwareへ翻訳する

金融には大量のRuleが存在する。

商品条件。

取引Rule。

口座管理。

決済。

会計。

税制。

Compliance。

Customer Protection。

Risk Management。

Regulation。

Systemはこれらを実行可能な形式へ翻訳しなければならない。

例えば証券取引なら、

Customer
  ↓
Account
  ↓
Order
  ↓
Execution
  ↓
Settlement
  ↓
Position / Balance
  ↓
Accounting / Record

というState Transitionが存在する。

一つでも整合しなければ、取引Realityそのものが壊れる。

金融System Engineeringの本質は、画面をつくることではない。

制度・商品・業務を、矛盾なく継続実行できるSoftwareへ変換することである。

⸻

大和証券というProduction Environment

大和総研の金融System Capabilityを理解するうえで重要なのが、大和証券グループとのRelationである。

大和総研は、大和証券で顧客や社員が実際に利用するSystemの企画、設計、開発、保守・運用を担う。

Online Trading。

Retail。

Wholesale。

CRM。

Data。

System Infrastructure。

Digital Service。

これらは実験環境ではない。

Productionで動き続ける。

そのため、

Business Knowledge × Financial Knowledge × System Engineering × Operation

が必要になる。

例えばOnline Tradingでは、顧客Interfaceだけではなく、その背後に注文、商品、残高、取引、Backend Systemとの接続がある。

一つのServiceの背後に複数Systemが存在する。

⸻

大和証券システム本部

2026年の組織では、金融システム事業本部の中に大和証券システム本部が置かれている。

Retail Front。

Retail Core。

Wholesale Front。

Wholesale Core。

DX System。

System Infrastructure Design。

そして2026年には価値創造推進室が新設された。

この構造は、大和証券のBusinessとSystemが密接に結びついていることを示している。

System Engineerが扱うのはTechnologyだけではない。

Financial Product。

Business Process。

Regulation。

Customer Experience。

Operation。

これらを同時に理解しなければならない。

金融SystemにおけるDomain Knowledgeは、Architectureの一部なのである。

⸻

PolicyがSystemへ到達する

ResearchとSystemのConnectionが最も明確に見えるのが制度変更である。

例えば税制や金融制度が変更される。

Researchが制度を分析する。

Business側が影響を整理する。

System Requirementが定義される。

Applicationが変更される。

ProductionへReleaseされる。

顧客が新しい制度を利用できるようになる。

[
Policy
\rightarrow
Interpretation
\rightarrow
Business\ Rule
\rightarrow
Requirement
\rightarrow
System
\rightarrow
Customer
]

新NISA対応は、この構造を理解する具体例になる。

制度は法律・政策文書の中だけで成立するのではない。

最終的には金融機関のProcessとSystemへ実装され、顧客が利用できる状態になって初めて社会Realityへ到達する。

PolicyをSoftwareへ翻訳する。

金融Systemには、この能力が必要である。

⸻

Mission-Criticalという条件

金融SystemにはAvailabilityが要求される。

しかし「止めない」だけでは足りない。

正しく動かなければならない。

Securityが必要である。

Data Integrityが必要である。

Recoveryできなければならない。

変更を安全に行わなければならない。

したがってMission-Critical Runtimeは、

[
Reliability
+
Availability
+
Security
+
Integrity
+
Recoverability
]

によって成立する。

そしてSystemは一度完成して終わらない。

制度変更。

商品追加。

Market Change。

Security Update。

Infrastructure Renewal。

Technology Modernization。

によって継続的に変化する。

Mission-Criticalとは、変えないことではない。

動かし続けながら、安全に変え続けるCapabilityである。

⸻

約19,000台を変える

大和証券グループにおけるZero Trust環境への移行は、このScaleを理解する例になる。

約12,000台のPCと約7,000台のSmartphoneという大規模なDevice Environmentを対象に、新しいSecurity Architectureへの移行が進められた。

先行する約500人規模のPilotを経て、大規模展開へ移る。

ここで必要なのはTechnology導入だけではない。

Identity。

Device。

Network。

Application。

Security Policy。

Employee Operation。

Support。

Migration。

を同時に設計する必要がある。

Identity
  ↓
Device
  ↓
Access Policy
  ↓
Application
  ↓
Data
  ↓
Monitoring

System Transformationとは、Technology ReplacementではなくOperating ModelのTransitionである。

⸻

内部Systemから金融Platformへ

大和総研の金融System Capabilityは、大和証券だけに閉じていない。

外部金融機関向けにもSystem Solutionを展開してきた。

ここで重要になるのが、

Internal Knowledge → Standardization → Platform

という流れである。

一社向けに蓄積した金融業務Knowledgeを、そのまま別企業へコピーするのではない。

共通化できるBusiness Ruleを抽出する。

Data Modelを標準化する。

共通FunctionをSoftware Assetにする。

Customer-specific Requirementを分離する。

すると、

Individual Project
     ↓
Domain Knowledge
     ↓
Standardization
     ↓
Reusable Software
     ↓
Financial Platform

というTransformationが成立する。

これは受託開発とは異なるScaleの作り方である。

⸻

Financial Plate

その代表的な系譜がFinancial Plateである。

証券Businessに必要なFront、Middle、Back、Management領域を支えるSolution群として展開されてきた。

Internet Trading。

営業支援。

基幹Back Office。

Data Management。

電子帳票。

制度対応。

それぞれが独立Productであると同時に、金融業務全体を構成するComponentでもある。

金融SystemのKnowledgeが、

Project Knowledge

から、

Reusable Financial Asset

へ変わっている。

次節で詳しく見るFinancial Platformの起点である。

⸻

Financial Ontology

金融Systemを次世代Architectureへ変換するには、金融RealityそのものをMachine-readableに記述する必要がある。

Customer
Account
Product
Order
Execution
Position
Cash
Asset
Settlement
Fee
Tax
Risk
Compliance
Document
Event
Time

そしてRelationを持たせる。

Customer ── OWNS ──> Account
Account ── HOLDS ──> Asset
Customer ── SUBMITS ──> Order
Order ── RESULTS_IN ──> Execution
Execution ── CHANGES ──> Position
Execution ── REQUIRES ──> Settlement
Rule ── GOVERNS ──> Transaction

これがFinancial Digital Twinの基礎になる。

金融をApplication単位ではなく、Financial Reality Graphとして記述する。

⸻

TransactionをEventとして扱う

金融SystemではEventが重要である。

注文が発生した。

約定した。

入金された。

Settlementが完了した。

Customer Informationが変更された。

Risk Thresholdを超えた。

これらをEventとして扱えば、

Event
 ↓
Validation
 ↓
State Transition
 ↓
New Financial State

というArchitectureを構築できる。

Current Stateだけでなく、なぜそのStateになったのかを追跡できる。

金融ではTraceabilityがTrustにつながる。

⸻

AIは金融Systemの外側にいない

AIもProduction Financial Systemへ入り始めている。

Customer Support。

CRM。

Compliance。

AML。

Investment Support。

Software Development。

Knowledge Search。

しかしMission-Critical SystemへAIを接続する場合、LLMの自由なGenerationをそのままTransaction Executionへ接続することはできない。

必要なのは、

AI Agent
  ↓
Recommendation / Request
  ↓
Policy Check
  ↓
Human / Rule Approval
  ↓
Deterministic Transaction System
  ↓
Audit

という境界である。

Generative IntelligenceとDeterministic Runtimeを分離する。

AIはPossible Actionを生成できる。

金融SystemはAuthorized Actionだけを実行する。

⸻

Legacyは過去ではなくKnowledgeである

金融機関には長期間運用されてきたSystemが存在する。

それを単純に「古いTechnology」と見るだけでは不十分である。

Legacy Systemには、

Business Rule。

Regulatory Interpretation。

Exception Handling。

Operational Knowledge。

過去の変更履歴。

が埋め込まれている。

つまりLegacy Codeは、

Executable Business Memory

でもある。

だからModernizationでは、古いCodeを新しいCodeへ変換するだけでは足りない。

Knowledgeを失わずにArchitectureを更新する必要がある。

後に扱うSmartransやAI駆動開発が重要になる理由もここにある。

⸻

2050年から金融Systemを見る

2050年から逆算すると、金融Infrastructureにはさらに高いInteroperabilityが必要になる。

人間とAI Agentが同じ金融Serviceを利用する。

複数AgentがTransactionを準備する。

RegulationがMachine-readableになる領域が広がる。

Financial Dataが複数Platformを横断する。

Identityがより重要になる。

Cyber Riskは常時存在する。

それでも基本原則は変わらない。

誰が、何を、どのAuthorityで、いつ実行したのか。

金融Systemはそれを証明できなければならない。

したがって2050 Financial Runtimeの中心は、

[
\boxed{
Financial\ Intelligence
+
Deterministic\ Execution
+
Trust
}
]

となる。

⸻

金融システム事業本部は、大和総研の中でKnowledgeを最も直接的にTransactionへ変える場所の一つである。

Researchが制度を理解する。

Consultingが選択肢を設計する。

SystemがBusiness Ruleへ翻訳する。

CodeがProductionで実行される。

その結果としてCustomer Account、Asset、Cash、TransactionというFinancial Realityが変化する。

[
\boxed{
Knowledge
\rightarrow
Rule
\rightarrow
Code
\rightarrow
Transaction
\rightarrow
Reality
}
]

そして、このCapabilityを一社の個別Systemから複数金融機関が利用できるAssetへ変換すると、次のScaleが現れる。

Financial Platform。
第2節　Financial Platform

金融Systemを一社ごとにつくり続けるだけでは、KnowledgeはProjectの中に閉じる。

しかし金融業務には、企業ごとの差異と同時に、大きな共通構造がある。

Customer。

Account。

Product。

Order。

Execution。

Settlement。

Asset。

Cash。

Compliance。

Accounting。

これらの基本EntityとBusiness Ruleには再利用可能な部分が存在する。

個別Projectから共通知識を抽出し、標準化し、Software Assetとして実装する。

そこにFinancial Platformが生まれる。

[
\boxed{
Project
\rightarrow
Domain\ Knowledge
\rightarrow
Standardization
\rightarrow
Software\ Asset
\rightarrow
Platform
}
]

大和総研の金融System Businessを理解するには、この「個別開発から共通基盤へ」というScale Transformationを見る必要がある。

⸻

SONARからFinancial Plateへ

大和総研の金融Platformには、長い蓄積がある。

証券会社向け共同利用型Back-office Systemの系譜を持ち、2008年にはFinancial Plateを開始した。

重要なのはProduct Nameそのものではない。

長期間の金融System Developmentによって蓄積された、

業務Process。

Financial Product。

Transaction。

Settlement。

Account Management。

制度対応。

Data Management。

Operation。

というDomain Knowledgeが、再利用可能なSoftwareへ変換されてきたことである。

これは、

金融業務KnowledgeのSoftware Asset化

である。

⸻

FrontからBackまでを接続する

金融機関のSystemは一枚ではない。

Customer Interfaceがある。

営業支援がある。

注文・取引がある。

Back Officeがある。

Data Managementがある。

帳票がある。

Complianceがある。

Financial PlateのSolution群も、こうした複数Layerを対象としてきた。

例えば、

Financial Plate/WB4。

Financial Plate/SFA。

Financial Plate/SNR。

Financial Plate/EPM2。

Financial Plate/LBX。

などである。

機能は異なるが、全体として見れば、

Customer
  ↓
Front
  ↓
Sales / Order
  ↓
Core Processing
  ↓
Settlement / Balance
  ↓
Data / Management
  ↓
Document / Compliance

という金融Business Chainを構成する。

Platformとは、一つの巨大Applicationを意味するのではない。

共通Domain Modelによって複数Capabilityを接続できることが重要なのである。

⸻

SharedとCustomizedを分離する

金融機関には共通要件がある。

しかしすべてが同じではない。

商品構成。

営業Model。

Customer Segment。

Internal Process。

Risk Policy。

External System。

Brand。

これらは各社で異なる。

したがってPlatform Architectureでは、

Common Core

と

Customer-specific Extension

を分離する。

Financial Platform
     │
     ├─ Common Domain
     ├─ Common Data Model
     ├─ Common Business Rules
     ├─ Common Security
     └─ Common Operations
             │
             ├─ Customer A Extension
             ├─ Customer B Extension
             └─ Customer C Extension

共通化しすぎればCustomer Requirementへ対応できない。

個別化しすぎればPlatformのScale Benefitが消える。

Platform Engineeringの核心は、どこを共通化し、どこを分離するかにある。

⸻

NISA Cloudが示すもの

制度対応もPlatform化できる。

NISAのような制度では、多くの金融機関に共通するRequirementが生じる。

制度を各社がゼロから解釈し、同じ種類のFunctionを個別に構築すれば、社会全体で重複Costが発生する。

共通化可能な部分をCloud Serviceとして提供すれば、

Policy / Regulation
       ↓
Common Interpretation
       ↓
Standard Requirement
       ↓
Shared Software
       ↓
Multiple Financial Institutions

という構造をつくれる。

大和総研のNISA Cloudは、この方向を具体的に示す。

さらに重要なのは、特定の基幹System全体を採用しなくても、必要なCapabilityを独立して利用できる構造である。

PlatformはMonolithではなく、Composable Capabilityへ向かう。

⸻

PlatformはKnowledgeの圧縮である

PlatformをTechnologyだけで見ると、本質を見失う。

長年のProjectで発生した無数のRequirementを、そのまま保持することはできない。

共通部分を抽出する。

Exceptionを整理する。

Business RuleをFormalizeする。

Data Modelを定義する。

Interfaceを標準化する。

つまりPlatformとは、

大量のDomain ExperienceをSoftware Architectureへ圧縮したもの

でもある。

[
Experience
\rightarrow
Pattern
\rightarrow
Rule
\rightarrow
Component
\rightarrow
Platform
]

ここに人月型Businessとは異なる資産形成が生まれる。

⸻

Financial Ontologyを共通言語にする

次世代Financial Platformでは、Applicationの共通化だけでは足りない。

金融Entityそのものを共通言語として定義する必要がある。

Person
Institution
Customer
Account
Product
Order
Execution
Position
Asset
Cash
Settlement
Fee
Tax
Document
Risk
Rule
Event
Time

例えば「Customer」という言葉でも、営業System、口座System、Compliance Systemでは異なるRepresentationを持つことがある。

それらを完全に一つのTableへ統合する必要はない。

しかし、

同じRealityの異なるRepresentationであること

を識別できなければならない。

OntologyがSystem間のSemantic Layerになる。

⸻

APIによってCapabilityを分離する

PlatformをComposableにするにはInterfaceが必要である。

Customer API
Account API
Order API
Position API
Settlement API
Document API
Compliance API
Identity API

それぞれのCapabilityを明確なContractで接続する。

するとFront-endを変更しても、Core System全体を書き換える必要がなくなる。

新しいAI Agentを追加する場合も、Databaseへ直接Accessさせるのではなく、許可されたAPIを通じてCapabilityを利用させることができる。

PlatformはSystemを増やすArchitectureではない。

変更の影響範囲を制御するArchitectureである。

⸻

Event Architecture

金融ではStateだけでなくChangeも重要である。

Order Created。

Execution Completed。

Settlement Completed。

Account Updated。

Document Issued。

Risk Detected。

これらをEventとして共有すれば、複数Systemを疎結合に接続できる。

Financial Event
     ↓
Event Bus
┌────┼─────┬─────┐
Risk  CRM  Accounting  Analytics

一つのEventを複数Capabilityが利用する。

これによって金融Platformは、Applicationの集合からEvent-driven Financial Runtimeへ近づく。

⸻

Authoritative Stateを守る

ただし、複数SystemやAI Agentが接続されるほど、

何が正式なStateなのか

が重要になる。

AIが生成したCustomer Summary。

Analytical Data Mart。

Vector Database。

Simulation Result。

これらを正式なAccount BalanceやTransaction Recordと混同してはならない。

そこでDataを分離する。

Authoritative
Observed
Derived
Predicted
Simulated
Generated

Financial Platformでは、Account、Transaction、Position、SettlementなどのAuthoritative Stateを明確にする。

AIはそれを参照できる。

分析できる。

しかし勝手に書き換えることはできない。

⸻

PlatformとCloud

CloudはFinancial PlatformのDelivery Modelも変える。

Infrastructureを共通化する。

EnvironmentをCodeで構築する。

Capacityを調整する。

Monitoringを標準化する。

Security Controlを共通化する。

Recoveryを設計する。

しかし金融では、

Cloud = 無条件のPublic Cloud化

ではない。

Requirementに応じてArchitectureを選ぶ必要がある。

Data Sensitivity。

Latency。

Availability。

Regulation。

Legacy Dependency。

Cost。

Operational Capability。

を比較する。

Cloudは目的ではなく、Platformを継続的に進化させるためのTechnology Optionである。

⸻

AIをPlatformへ接続する

AI時代のFinancial Platformには、新しい利用主体が加わる。

人間だけではない。

AI Agentである。

例えば営業支援Agentが、

Customer Profileを読む。

取引履歴を確認する。

Market Informationを取得する。

適切なInformationを営業担当者へ提示する。

しかしAgentが自由に取引を実行してよいわけではない。

AI Agent
  ↓
Approved API
  ↓
Policy Engine
  ↓
Authorization
  ↓
Financial Capability
  ↓
Audit

AgentにDatabase Accessを与えるのではなく、Governed Capabilityを与える。

これがAgent-ready Financial Platformの基本になる。

⸻

PlatformをAI Assetへ拡張する

Platform化できるのはTransaction Functionだけではない。

AML Model。

Risk Detection。

Customer Classification。

Knowledge Search。

Document Processing。

Code Migration。

AI Agent Skill。

これらも適切なGovernanceのもとでReusable Assetにできる。

すると金融Platformは、

[
Software\ Platform
\rightarrow
Data\ Platform
\rightarrow
AI\ Platform
]

へ拡張する。

重要なのはAI Modelを大量に置くことではない。

金融Domain KnowledgeとAI Capabilityを、安全に再利用できることである。

⸻

Platform BusinessのScale

個別受託開発では、基本的にProjectごとに人と時間が必要になる。

Platformでは、一度FormalizeしたCapabilityを複数Customerへ展開できる。

概念的には、

[
Value

People
\times
Knowledge
\times
Software
\times
Reuse
]

となる。

これは人を不要にする式ではない。

人間のDomain Knowledgeを、一度きりのProjectからReusable Assetへ変えることである。

大和総研が持つ金融業務Knowledge、System Engineering、Production Operationの蓄積は、このAsset化と相性がよい。

⸻

2050 Financial Platform

2050年から逆算すると、Financial Platformはさらに抽象化される。

Customerは人間だけではない。

企業AI Agentが金融Serviceを利用する可能性がある。

Regulationの一部はMachine-readableになる。

複数金融機関のServiceをSoftwareが組み合わせる。

Digital Assetや新しいSettlement Architectureが加わる可能性もある。

しかし、どのTechnologyが主流になるかは固定しない。

不変に近いRequirementを残す。

Identity
Authority
Transaction Integrity
Interoperability
Traceability
Security
Auditability
Recoverability

2050 Financial Platformとは特定Technologyの名前ではない。

金融Capabilityを安全に組み合わせられるTrusted Runtimeである。

⸻

大和総研のFinancial Platformは、金融Systemの蓄積を一社の個別SystemからReusable Capabilityへ変換する構造として読むことができる。

[
\boxed{
Financial\ Knowledge
\rightarrow
Standardization
\rightarrow
Software\ Asset
\rightarrow
Platform
\rightarrow
Financial\ Runtime
}
]

そして、このTransformationは金融だけに限定されない。

企業活動にも、共通化できるProcess、Data、Cloud、AI Capabilityが存在する。

金融という高度に制度化された領域で培われたSystem Engineeringを、より広いEnterprise Realityへ接続すると何が起こるのか。

次節では対象を金融機関から企業全体へ広げる。

企業システム事業本部。
第3節　企業システム事業本部

企業のRealityも、Softwareによって動いている。

顧客を管理する。

商品を販売する。

Dataを集める。

業務を処理する。

経営状態を把握する。

社員が情報へAccessする。

取引先と接続する。

AIを利用する。

現在の企業活動では、Business ProcessとInformation Systemを完全に切り離すことが難しい。

したがって企業Transformationは、

Business Transformation

であると同時に、

System Transformation

でもある。

大和総研の企業システム事業本部は、この境界を扱う。

[
\boxed{
Business
\rightarrow
Process
\rightarrow
Data
\rightarrow
System
\rightarrow
Operation
}
]

⸻

金融SystemからEnterprise Systemへ

前節まで扱った金融Systemには、明確なTransaction Structureがあった。

Order。

Execution。

Settlement。

Account。

Asset。

企業Systemでは対象がさらに広い。

Customer。

Sales。

Product。

Contract。

Employee。

Project。

Procurement。

Accounting。

Document。

Knowledge。

Data。

System。

企業ごとにBusiness Modelが異なるため、共通化できる部分と個別性の境界も複雑になる。

ここで必要になるのは、単にSoftwareを開発する能力ではない。

企業業務をSystem Architectureへ翻訳するCapabilityである。

⸻

Business Requirementから始める

System DevelopmentをTechnologyから始めると、本来の目的を失いやすい。

Cloudを使う。

AIを使う。

Data Lakeをつくる。

新しいFrameworkへ移行する。

これらはTechnology ChoiceであってBusiness Objectiveではない。

最初に必要なのは、

何を変えたいのか

である。

Business Objective
      ↓
Business Process
      ↓
Requirement
      ↓
Architecture
      ↓
Technology
      ↓
Implementation

売上を伸ばす。

Customer Experienceを改善する。

業務時間を減らす。

Dataを統合する。

System変更を速くする。

Riskを低減する。

目的によってArchitectureは変わる。

Enterprise System Engineeringとは、Business RequirementをTechnologyへ翻訳するOperationなのである。

⸻

企業システム事業本部のCapability

2026年の企業システム事業本部には、Digital SolutionやData Solutionなど、企業のDigital Transformationを支えるCapabilityが置かれている。

そして2026年4月には、AX本部が新設された。

この変化は重要である。

AIが独立した実験Technologyから、企業BusinessとSystemを再設計するTechnologyへ移行し始めたことを示している。

従来のDXが、

[
Analog
\rightarrow
Digital
]

だけではなく、

[
Human\ Process
\rightarrow
Human + AI\ Process
]

へ拡張する。

AI導入そのものではなく、AIを前提として企業Operationを再設計することがAXの中心課題になる。

⸻

AXはAI導入ではない

例えば社内へ生成AIを導入する。

Employeeが文章を要約する。

Draftを作成する。

情報を検索する。

それだけでもProductivityは向上する可能性がある。

しかしAXはさらに深い。

現在のProcessを分解する。

Business Process
├─ Observe
├─ Search
├─ Analyze
├─ Generate
├─ Review
├─ Decide
├─ Execute
└─ Monitor

どこをAIが支援できるか。

どこをAgent化できるか。

どこにHuman Reviewが必要か。

どのDecision Authorityを人間へ残すか。

を再設計する。

つまり、

AI Adoption → Process Redesign → System Integration → Organizational Transformation

である。

⸻

Dataが企業Systemを横断する

企業Systemの大きな問題の一つは、DataがApplicationごとに分断されることである。

CRMにCustomer Dataがある。

ERPにTransaction Dataがある。

HR SystemにEmployee Dataがある。

Project Management SystemにProject Dataがある。

Document StorageにKnowledgeがある。

これらが接続されなければ、企業全体のStateを理解できない。

CRM ───────┐
ERP ───────┤
HR ────────┤
Project ───┼──> Enterprise Data
Documents ─┤
External ──┘

しかし、すべてを一つのDatabaseへコピーする必要もない。

必要なのは、

Data Federation + Common Semantics + Governance

である。

前章で設計したCorporate Digital Twinへ接続する基盤になる。

⸻

Enterprise Ontology

そこで企業Realityを共通Entityとして記述する。

Company
Organization
Person
Customer
Supplier
Product
Service
Contract
Project
Asset
Capital
Process
System
Data
Decision
Risk
Event
Time

SystemごとのSchemaを破壊して一つにするのではない。

それぞれのRepresentationが、現実世界のどのEntityを表しているかを接続する。

例えば、

CRMのCustomer。

Billing SystemのCustomer。

Support SystemのCustomer。

が同じEntityを参照していることを識別する。

このSemantic Layerが、Enterprise AIにとって極めて重要になる。

⸻

AIにはContextが必要である

生成AIをEnterpriseへ導入すると、すぐにKnowledge Searchの問題が現れる。

社内規程。

Product Manual。

Project Document。

Customer Information。

System Specification。

Past Decision。

これらをLLMが利用できなければ、一般Knowledgeしか持たないAIになる。

しかしDocumentをVector Databaseへ入れるだけでも足りない。

誰が、どのKnowledgeを、どの目的で利用できるか

が必要になる。

User / Agent
    ↓
Identity
    ↓
Authorization
    ↓
Approved Knowledge
    ↓
Retrieval
    ↓
AI Response

Enterprise AIは、Knowledge RetrievalとAccess Controlを同時に設計しなければならない。

⸻

System IntegrationからAgent Integrationへ

従来のEnterprise Architectureでは、System同士をAPIで接続してきた。

これからはAgentもSystem利用主体になる。

例えばSales Agentが、

CRMを読む。

Inventoryを確認する。

Product Knowledgeを検索する。

Proposal Draftを生成する。

しかしContractを確定するにはHuman Approvalが必要かもしれない。

AI Agent
  ↓
Enterprise API
  ↓
Policy Engine
  ↓
Business System
  ↓
Human Approval
  ↓
Execution

ここで重要なのは、AI AgentにDatabaseへの無制限Accessを与えないことである。

AgentにはCapability単位のPermissionを与える。

Enterprise Systemは、人間だけでなくAI Agentも利用するRuntimeへ変化する。

⸻

AI駆動開発

AIはSystemの利用者になるだけではない。

SystemをつくるProcessにも入る。

Requirement整理。

Design Support。

Code Generation。

Test Generation。

Code Review。

Migration。

Documentation。

大和総研でも2026年にはCoding Agentを利用したAI駆動開発の取り組みが進んでいる。

これによってSoftware Developmentは、

Human Requirement
      ↓
Human + AI Design
      ↓
AI-assisted Implementation
      ↓
Automated Test
      ↓
Human Verification
      ↓
Production

へ変化する。

ただし生成速度だけを上げればよいわけではない。

生成されるCodeが増えるほど、Architecture、Testing、Security、Traceabilityの重要性も増す。

⸻

Legacy Modernization

企業Systemには長年蓄積されたLegacyがある。

Legacy CodeはTechnology Debtである一方、Business Knowledgeでもある。

そこには、

業務Rule。

例外処理。

Data Structure。

外部Interface。

制度対応。

過去のDecision。

が埋め込まれている。

したがってModernizationは、

[
Old\ Code
\rightarrow
New\ Code
]

だけではない。

[
Legacy\ Knowledge
\rightarrow
Explicit\ Knowledge
\rightarrow
Modern\ Architecture
]

でなければならない。

この課題に対する大和総研の具体的なAI Assetが、後に扱うSmartransである。

⸻

Enterprise SystemをDigital Twinへ接続する

企業システム事業本部のCapabilityを第Ⅲ部と接続すると、Corporate Digital TwinがProductionへ近づく。

Consulting側では、

Strategy。

Capital。

Governance。

Human Capital。

を記述した。

System側では、

Process。

Application。

Data。

Infrastructure。

Event。

を持つ。

二つを接続すると、

Strategy
  ↓
Business
  ↓
Process
  ↓
System
  ↓
Data
  ↓
Event
  ↓
Observed Outcome

となる。

StrategyがSystemへ到達し、SystemからRealityのDataが戻る。

これによってCorporate Digital TwinはConsulting ModelからOperational Twinへ拡張する。

⸻

BuildだけでなくOperateを見る

Enterprise Systemの価値はRelease時点では決まらない。

実際に利用されるか。

安定して動くか。

Business Outcomeへつながるか。

変更に追随できるか。

Securityを維持できるか。

が重要になる。

したがって、

[
Build
\rightarrow
Run
\rightarrow
Observe
\rightarrow
Improve
]

までを一つのLifecycleとして見る。

AI時代にはModel DriftやAgent BehaviorもMonitoring対象になる。

Application Monitoringだけではなく、Intelligence Monitoringが必要になる。

⸻

Enterprise ArchitectureをHuman-authoritativeにする

AIが企業Processへ深く入るほど、Authority設計が重要になる。

例えば、

AIがInvoiceを分類する。

AIがContract Riskを抽出する。

AIがCustomer ResponseをDraftする。

AI AgentがPurchase Requestを作成する。

これらは影響度が異なる。

したがってActionを分類する。

Observe
Recommend
Draft
Request
Approve
Execute

AIにどこまで許可するかをCapabilityごとに設定する。

High-impact Actionでは、

AI → Recommendation → Human Approval → Execution

を維持する。

GovernanceをSystem Architectureへ埋め込む。

⸻

2050 Enterprise Runtime

2050年から逆算すると、企業SystemはApplicationの集合からさらに変化する。

Human。

AI Agent。

Software Service。

External Platform。

Device。

が同じEnterprise Runtimeへ参加する。

必要になるのは、一つのSuper Applicationではない。

Identity
Ontology
Data
API
Event
Agent
Policy
Audit
Simulation

によって異なるCapabilityを安全に接続できるArchitectureである。

Application-centric Enterpriseから、

Capability-centric Enterprise

への移行である。

⸻

企業システム事業本部は、企業のStrategyをSoftwareへ変換する場所である。

Business RequirementをProcessへ落とす。

ProcessをSystemへ翻訳する。

Dataを接続する。

Cloudへ展開する。

AIを組み込む。

Productionで運用する。

そしてOutcomeを再びDataとして取得する。

[
\boxed{
Strategy
\rightarrow
Process
\rightarrow
System
\rightarrow
Runtime
\rightarrow
Enterprise\ Reality
}
]

金融Systemで蓄積されたMission-Critical Engineeringは、ここでより広いEnterprise Realityへ展開される。

そして大和総研には、もう一つ異なるRealityを長期間Systemとして扱ってきた領域がある。

企業のCapitalでもTransactionでもない。

人間の健康と社会保険である。

次節では、

ヘルステック本部。
第4節　ヘルステック本部

金融SystemがCapitalとTransactionを扱い、企業SystemがBusiness Processを扱うなら、ヘルステックが扱うのは、さらに人間に近いRealityである。

健康保険。

健診。

医療費。

保健事業。

健康状態。

生活習慣。

企業のHuman Capital。

ここではDataの向こう側に、常に一人の人間がいる。

したがってHealthTechは、単なるHealthcare ITではない。

制度・Data・Technology・人間を接続する社会Infrastructureとして設計する必要がある。

[
\boxed{
Social\ Insurance
\rightarrow
Health\ Data
\rightarrow
Analytics
\rightarrow
Support
\rightarrow
Human\ Reality
}
]

⸻

約半世紀のSystem Knowledge

大和総研のHealthTech Capabilityは、生成AIとともに突然生まれたものではない。

健康保険領域では約半世紀にわたるSystem・業務Knowledgeの蓄積があり、2025年4月時点で約450の健康保険組合と契約する規模へ広がっている。

ここで重要なのは契約数だけではない。

健康保険という制度を長期間Systemとして運用することで、

加入者。

事業所。

資格。

給付。

健診。

医療費。

保健事業。

制度変更。

というDomain Knowledgeが蓄積されてきたことである。

金融Systemと同じく、制度KnowledgeがSoftwareへ埋め込まれている。

⸻

Social InsuranceをSystemとして実行する

健康保険制度も、法律や規程だけではRealityにならない。

加入資格を管理する。

Dataを受け取る。

給付業務を行う。

健診結果を管理する。

保健事業を実施する。

制度変更へ対応する。

その一つひとつがOperational Systemとして動かなければならない。

Policy / Regulation
       ↓
Insurance Rule
       ↓
Business Process
       ↓
System
       ↓
Operation
       ↓
Insured Person

つまりヘルステック本部も、

Rule → Requirement → System → Reality

という第Ⅳ部の基本構造を持つ。

対象が金融から社会保険へ変わっただけではない。

人間に関するDataを扱うため、PrivacyとPurposeがさらに重要になる。

⸻

DataのScale

健康Dataの価値は、一件のRecordだけから生まれるわけではない。

大和総研は700万人を超える規模のHealth Dataを分析・Reportへ活用してきた。

このScaleになると、

個人。

企業。

健康保険組合。

Population。

という複数の観測Scaleが現れる。

Person
  ↓
Organization
  ↓
Health Insurance Society
  ↓
Population

ただしAggregate KnowledgeとIndividual Judgmentは区別しなければならない。

集団に見られるPatternが、一人の人間について必ず成立するわけではない。

[
Population\ Pattern \neq Individual\ Truth
]

これはHealth AIの基本境界になる。

⸻

KOSMOからHearbitへ

HealthTechの進化を見ると、Systemの役割が変化していることが分かる。

従来の健康保険業務を支えるSystemやServiceに加え、Data Analysis、健康経営、保健事業支援へ対象が広がってきた。

2025年10月にはHearbitが開始され、2026年にはAIを利用した分析支援機能であるHearbit Viewへ展開している。

ここに、

[
Administrative\ System
\rightarrow
Data\ Platform
\rightarrow
Health\ Intelligence
]

という進化を見ることができる。

Systemが記録を保持するだけではなく、Dataから次のActionを考えるためのInfrastructureへ変わる。

⸻

Health DataをHuman Capitalへ接続する

この領域は第Ⅲ部のHuman Capitalとも接続する。

企業にとってEmployee Healthは福利厚生だけの問題ではない。

Workforce Sustainability。

Absence。

Productivity。

Engagement。

Retention。

Human Capital Risk。

などとRelationを持つ。

しかし、ここでも単純化してはならない。

健康状態を直接Productivity Scoreへ変換し、人間を評価するArchitectureは危険である。

必要なのは、

Health Program
     ↓
Population-level Health State
     ↓
Organizational Condition
     ↓
Human Capital Strategy

という適切なScaleでの接続である。

健康Dataを人事評価Dataへ短絡させない。

HealthTechとHuman Capital Managementの接続には、明確なPurpose Boundaryが必要になる。

⸻

Predictive AI

大和総研では、同意を得た大和証券グループのHealth Dataなどを利用し、生活習慣病の初期段階に関する将来Riskを予測するAIの開発も進められている。

ここでAIは、

Current Dataから、

Possible Future Health State

を推定する。

Consented Health Data
       ↓
Feature / Model
       ↓
Risk Estimation
       ↓
Possible Intervention
       ↓
Human / Professional Action

重要なのはPredictionそのものではない。

PredictionをどのようなSupportへ接続するかである。

AIが「未来を決定する」のではない。

可能性を早く観測し、本人や専門家が選択できる余地を広げる。

⸻

PredictionとDiagnosisを分離する

Health AIでは、この境界を厳密にする必要がある。

Risk Prediction。

Population Analysis。

Recommendation Support。

Medical Diagnosis。

Treatment Decision。

これらは同じではない。

AI ModelがRiskを推定したからといって、それをDiagnosisとして扱ってはならない。

[
Prediction \neq Diagnosis
]

さらに、

[
AI\ Output \neq Human\ Identity
]

である。

AI Outputは一つのEvidenceとして扱う。

必要な領域では医療専門職や本人の判断へ接続する。

AI → Evidence → Human Interpretation → Action

というHuman-authoritative Architectureを維持する。

⸻

ConsentをArchitectureにする

Health Dataでは、Consentを利用規約の一文だけで扱ってはならない。

誰が同意したのか。

何の目的への同意か。

どのDataか。

いつからいつまで有効か。

撤回されたか。

をMachine-readableに管理する必要がある。

Consent
├─ subject
├─ purpose
├─ data_scope
├─ granted_at
├─ expires_at
├─ withdrawn_at
└─ status

そしてData Access時に、

Request
  ↓
Identity
  ↓
Purpose
  ↓
Consent / Legal Basis
  ↓
Authorization
  ↓
Data Access
  ↓
Audit

を確認する。

PrivacyをPolicyからRuntimeへ変える。

⸻

Authoritative Health Data

HealthTechでも、Dataの種類を混同してはならない。

健診結果。

医療費Data。

本人入力Data。

AIによる推定。

Population Statistics。

Simulation Result。

これらはAuthorityが異なる。

そこで、

Observed
Authoritative
Self-reported
Derived
Predicted
Simulated

を区別する。

AI PredictionをObserved Factとして保存しない。

SimulationをActual Health Stateとして扱わない。

これは第Ⅱ部のEconomic Intelligence、第Ⅲ部のCorporate Digital Twinと同じ原則である。

RealityとRepresentationを分離する。

⸻

Health Knowledge Graph

HealthTechを次世代Architectureへ変換するには、RecordをRelationとして扱う必要がある。

Person
Health Insurance Society
Organization
Health Check
Health Indicator
Program
Claim
Provider
Consent
Risk Model
Prediction
Intervention
Event
Time

例えば、

Person ── HAS ──> HealthCheck
HealthCheck ── CONTAINS ──> Indicator
Person ── PARTICIPATES_IN ──> Program
Model ── GENERATES ──> Prediction
Prediction ── BASED_ON ──> Dataset
Consent ── AUTHORIZES ──> Purpose

とRelationを持たせる。

ただしGraph化できるからといって、すべての情報を全利用者へ接続するわけではない。

Graph RelationとAccess Permissionは別Layerである。

⸻

Population Simulation

HealthTechと第Ⅱ部の2,500人Simulationを接続すると、別の可能性が見える。

個人を完全に再現するのではなく、Population-levelで複数Scenarioを比較する。

例えば、

健康支援Program A。

Program B。

No Intervention。

について、

参加率。

健康指標。

Cost。

Long-term Risk。

などのPossible Outcomeを比較する。

Population State
     ↓
Intervention Scenarios
 A       B       C
 ↓       ↓       ↓
Possible Population States

これは診断AIではない。

Policy・Program DesignのためのSimulationである。

HealthTechがConsultingと接続する領域でもある。

⸻

Financial Infrastructureとの共通構造

金融とHealthTechは、表面的には異なる。

しかしSystem Architectureでは共通点が多い。

制度がある。

Sensitive Dataがある。

Identityがある。

長期間のRecordがある。

Mission-critical Operationがある。

制度変更がある。

Securityが必要である。

Auditが必要である。

したがって大和総研の中には、

Financial Infrastructure
       │
       ├─ Identity
       ├─ Data
       ├─ Rule
       ├─ Security
       ├─ Operation
       └─ Audit
       │
Social Insurance Infrastructure

という共通Capabilityが存在する。

Domainは違っても、Trusted System EngineeringというCoreが共有される。

⸻

2050 Health Intelligence

2050年から逆算すると、HealthTechに必要なのは巨大な「健康AI」一つではない。

本人。

企業。

健康保険組合。

医療・保健専門職。

制度。

AI。

それぞれのAuthorityを保ったまま、必要なDataだけを接続できるArchitectureである。

[
\boxed{
Health\ Intelligence

Data
+
Consent
+
Analytics
+
Prediction
+
Human\ Authority
+
Trust
}
]

健康を完全に予測することが目的ではない。

より早くRiskを観測する。

より多くのOptionを比較する。

より適切なSupportへ接続する。

そして本人の選択可能性を維持する。

⸻

ヘルステック本部を見ると、大和総研のSystem Capabilityが金融や企業ITだけではないことが分かる。

制度を理解する。

大量Dataを扱う。

Privacyを守る。

AIでPossible Stateを分析する。

人間の判断へ戻す。

Productionで継続運用する。

この構造は、

[
\boxed{
Rule
\rightarrow
Data
\rightarrow
Intelligence
\rightarrow
Human\ Action
\rightarrow
Reality
}
]

と表現できる。

そして金融System、企業System、HealthTechのすべてをProductionで動かすには、その下に共通するRuntimeが必要になる。

Cloud。

Network。

Security。

Identity。

Data Platform。

AI Trust。

Operation。

次節では、それらを支えるLayerへ降りる。

基盤ソリューション本部。
第5節　基盤ソリューション本部

Applicationは、それだけでは動かない。

金融System。

Enterprise System。

HealthTech。

AI Agent。

それらの下には、Compute、Storage、Network、Identity、Security、Cloud、Monitoring、Operationが存在する。

利用者から見えにくい。

しかし、このLayerが止まれば上にあるすべてのServiceが止まる。

基盤とは、Systemの下に置かれたTechnologyではない。

Systemが継続してRealityとして存在するためのRuntimeである。

[
\boxed{
Application
\rightarrow
Platform
\rightarrow
Infrastructure
\rightarrow
Operation
}
]

大和総研の基盤ソリューション本部は、この最下層に近いProduction Capabilityを担う。

⸻

InfrastructureをBusinessから切り離さない

InfrastructureはServerやNetworkを管理する部門だと理解されやすい。

しかしMission-Critical Systemでは、Infrastructure DesignがBusiness Capabilityそのものを制約する。

Availability。

Latency。

Scalability。

Security。

Recovery。

Data Residency。

Cost。

Change Speed。

これらはBusiness Requirementである。

例えば金融取引Systemなら、障害時にどこまでRecoveryできるかはTechnologyだけの問題ではない。

どれだけのTransaction Lossを許容できるのか。

どの時間内に復旧する必要があるのか。

というBusiness Decisionから始まる。

したがって、

Business Requirement
       ↓
Service Level
       ↓
Architecture
       ↓
Infrastructure
       ↓
Operation

となる。

InfrastructureはBusiness Requirementの物理的・計算的実装である。

⸻

2026年のCloudとAI Trust

2026年4月の大和総研の組織改編では、基盤ソリューション本部の組織名称にも重要な変化が現れた。

基盤システム開発第一部はクラウド基盤開発部へ。

基盤システム開発第二部はAIトラスト基盤開発部へ。

これは単なる名称変更として見るより、System Infrastructureに必要なCapabilityがどこへ向かっているかを示すものとして読める。

[
Infrastructure
\rightarrow
Cloud
+
AI\ Trust
]

CloudによってInfrastructureはProgrammableになる。

AIによってApplicationの振る舞いはProbabilisticになる。

その二つをProductionで扱うため、InfrastructureとTrustを同時に設計する必要が生じている。

⸻

Cloudは場所ではない

Cloudを「自社Data Centerから外部Data Centerへ移すこと」とだけ理解すると本質を見失う。

Cloudの重要な変化は、InfrastructureをSoftwareとして操作できることである。

Networkを定義する。

ComputeをProvisionする。

Databaseを構築する。

Policyを設定する。

Monitoringを展開する。

環境を再現する。

つまり、

[
Physical\ Infrastructure
\rightarrow
Programmable\ Infrastructure
]

である。

Infrastructure as Codeを使えば、Environment DefinitionそのものをVersion Controlできる。

Architecture
   ↓
Infrastructure Code
   ↓
Review
   ↓
Deploy
   ↓
Cloud Environment
   ↓
Monitor

Infrastructure ChangeにもSoftware Engineeringの原則を適用できる。

⸻

Multi-CloudというReality

企業Systemは一つのCloudだけで完結するとは限らない。

AWS。

Google Cloud。

Microsoft Azure。

Oracle Cloud。

Private Environment。

On-premises。

SaaS。

既存Legacy。

それぞれに異なるRequirementがある。

大和総研は複数Cloud VendorとのPartner Capabilityを持ち、2025年にはMulti-cloudやBusiness Resilienceを支援するD-Suiteを開始している。

重要なのはCloudの数を増やすことではない。

異なるEnvironmentを、

Governance可能な一つのEnterprise Architecture

として扱うことである。

⸻

Multi-CloudはComplexityも増やす

Multi-cloudにはBenefitがある。

しかし同時にComplexityも増える。

Identity Modelが異なる。

Security Policyが異なる。

Loggingが異なる。

Networkが異なる。

Cost Modelが異なる。

Operational Skillも異なる。

したがって、

Cloud A ──┐
Cloud B ──┤
Cloud C ──┼──> Common Governance
On-Prem ──┤
SaaS ─────┘

というControl Planeが必要になる。

Cloud Freedomだけでなく、Cloud Governanceが必要なのである。

⸻

Identityを中心に置く

従来のEnterprise SecurityではNetwork Boundaryが重要だった。

しかしCloud、Mobile、Remote Work、SaaS、AI Agentが広がると、「社内Networkにいるから安全」という前提は成立しにくくなる。

そこで中心になるのがIdentityである。

Identity
  ↓
Authentication
  ↓
Authorization
  ↓
Resource
  ↓
Action
  ↓
Audit

誰なのか。

何を許可されているのか。

どのDeviceか。

どのContextか。

何を実行したのか。

を継続的に確認する。

前節で見た大規模Zero Trust移行も、このArchitecture Transformationとして理解できる。

⸻

Human IdentityからAgent Identityへ

AI AgentがEnterprise Systemへ参加すると、Identityの対象も増える。

人間。

Application。

Service Account。

Device。

AI Agent。

すべてがAction主体になる。

そこで、

Actor
├─ Human
├─ Service
├─ Device
└─ AI Agent

としてIdentityを管理する必要がある。

AI Agentにも、

誰のために動いているのか。

どのCapabilityを利用できるのか。

どのDataへAccessできるのか。

どの時間だけ有効か。

を定義する。

Agent Identityは次世代Infrastructureの基本要素になる。

⸻

AI Trustとは何か

AI Trustを「AIを安全に使いましょう」という抽象的なPrincipleで終わらせてはならない。

Production Architectureへ分解する。

AI Trust
├─ Model Registry
├─ Data Lineage
├─ Prompt / Agent Version
├─ Identity
├─ Authorization
├─ Content Control
├─ Human Approval
├─ Monitoring
├─ Audit
├─ Incident Response
└─ Rollback

どのModelを使ったか。

どのDataを参照したか。

誰がAgentを実行したか。

何を生成したか。

何を実行したか。

誰が承認したか。

を追跡できるようにする。

TrustをDocumentationではなくRuntime Propertyへ変える。

⸻

ProbabilisticとDeterministicを分離する

AI Systemの難しさは、従来のSoftwareと異なる振る舞いを持つことにある。

通常のBusiness Ruleなら、

同じInputに対して同じLogicを実行できる。

生成AIではOutputが確率的になる。

そこで、

Probabilistic Intelligence

と

Deterministic Execution

を分離する。

AI
↓
Interpret / Generate / Recommend
↓
Policy
↓
Human / Rule Approval
↓
Deterministic System
↓
Execution

AIが考えるLayerと、正式なStateを変更するLayerを分ける。

金融、Human Capital、HealthTechなどHigh-impact領域では特に重要になる。

⸻

Data Infrastructure

AI時代の基盤はComputeだけではない。

Data Infrastructureが必要になる。

Transactional Database。

Data Warehouse。

Object Storage。

Knowledge Graph。

Vector Store。

Event Stream。

Model Store。

これらは目的が異なる。

SQL
 → Authoritative State
Graph
 → Relation
Vector
 → Semantic Memory
Object
 → Large / Raw Data
Event
 → State Change
Model Registry
 → AI Model State

一つのDatabaseですべてを解決しようとしない。

Realityの性質に応じてData Architectureを分け、それらをGovernanceで接続する。

⸻

Observability

Production Systemでは、動いているだけでは足りない。

何が起きているかを観測できなければならない。

Metrics。

Logs。

Traces。

Events。

Security Alerts。

Model Output。

Agent Action。

これらを接続する。

Runtime
 ↓
Metrics / Logs / Traces
 ↓
Detection
 ↓
Diagnosis
 ↓
Response
 ↓
Learning

AI時代にはさらに、

Model Drift。

Retrieval Quality。

Hallucination Rate。

Agent Failure。

Unauthorized Tool Attempt。

Human Override。

などもMonitoring対象になる。

ObservabilityはSystem自身のResearch Capabilityとも言える。

⸻

Resilience

Mission-Critical Infrastructureでは、障害を完全にゼロにするという前提では設計できない。

Hardwareは故障する。

Software Bugは起こる。

Networkは切れる。

Cloud Serviceにも障害は起こる。

Cyberattackもある。

人間もMistakeする。

したがって重要なのは、

Failureを前提としてRecoveryできること

である。

Backup。

Redundancy。

Failover。

Disaster Recovery。

Incident Response。

Rollback。

Business Continuity。

を設計する。

[
Trust
\neq
Never\ Fail
]

である。

[
Trust

Prevent
+
Detect
+
Contain
+
Recover
+
Learn
]

と捉える方が現実的である。

⸻

InfrastructureもKnowledge Assetになる

Infrastructure ArchitectureもProjectごとにゼロからつくる必要はない。

Network Pattern。

Security Control。

Cloud Landing Zone。

Identity Pattern。

Monitoring。

CI/CD。

Backup。

AI Governance。

これらをReusable Assetにする。

Project Experience
     ↓
Architecture Pattern
     ↓
Infrastructure Code
     ↓
Reusable Platform
     ↓
Next Project

ここでも、

People × Knowledge × Software × Reuse

というPlatform Scaleが働く。

Infrastructure KnowledgeがCodeになる。

⸻

2050 Trusted Infrastructure

2050年のInfrastructureがどのHardware、Cloud、Compute Architectureを使っているかは確定できない。

Quantum Computingが特定用途へ入る可能性もある。

Edge AIが広がる可能性もある。

新しいDistributed Architectureも現れるだろう。

しかしRequirementは比較的安定している。

Identity
Security
Availability
Integrity
Interoperability
Observability
Auditability
Recoverability
Human Authority

Technologyを固定するのではなく、Requirementを固定する。

これがFuture PullによるInfrastructure Designである。

⸻

基盤ソリューション本部は、大和総研のSystem Capabilityの最下層にあるSupporting Functionではない。

金融System。

Enterprise System。

HealthTech。

AI。

それらをRealityとして存在させ続けるExecution Foundationである。

[
\boxed{
Cloud
+
Data
+
Identity
+
Security
+
AI\ Trust
+
Observability
+
Operation

Trusted\ Runtime
}
]

Applicationが変わっても、Systemが守らなければならないものがある。

正しく実行されること。

必要なときに利用できること。

不正なActionを防ぐこと。

何が起きたか追跡できること。

障害から戻れること。

安全に変更できること。

次節では、金融・企業・HealthTech・基盤を横断して、大和総研が長年Productionで蓄積してきたこのCapabilityそのものを取り出す。

Mission-Critical Runtime。
第6節　Mission-Critical Runtime

Mission-Critical Systemとは、単に「重要なSystem」ではない。

止まればBusinessが止まる。

誤ればTransactionが壊れる。

Dataが失われれば過去を復元できない。

Securityが破られれば顧客や社会へ影響する。

制度変更へ対応できなければServiceを継続できない。

金融、社会保険、企業基幹業務のような領域では、SoftwareはBusinessを支える道具ではなく、Businessが成立する条件そのものになっている。

したがってMission-Criticalの本質は、

絶対に止まらないSystemをつくること

ではない。

[
\boxed{
Correctly\ Operate
+
Safely\ Change
+
Rapidly\ Recover
}
]

を継続することである。

大和総研がSystem Businessで蓄積してきた核心Capabilityの一つが、このRuntime Engineeringである。

⸻

BuildではなくRuntimeを見る

System Developmentでは、完成やReleaseが一つの区切りになる。

しかしProductionでは、Releaseした瞬間から次の時間が始まる。

Design
 ↓
Build
 ↓
Test
 ↓
Release
 ↓
Operate
 ↓
Monitor
 ↓
Change
 ↓
Release
 ↺

Systemは動き続ける。

Customerが利用する。

Transactionが発生する。

Dataが蓄積する。

障害が起きる。

Business Requirementが変わる。

Regulationが変わる。

Security Threatが変わる。

Mission-Critical Engineeringとは、このContinuous State Transitionを安全に管理することである。

⸻

Correctness

第一の条件はCorrectnessである。

金融取引なら、注文と約定が正しく対応する。

残高が正しい。

Settlementが正しい。

健康保険Systemなら、資格や給付に関するStateが正しく管理される。

企業Systemなら、Business Ruleが意図どおり実行される。

つまり、

[
Input
+
Rule
\rightarrow
Correct\ State\ Transition
]

でなければならない。

Availabilityが高くても、間違った処理を高速で続けるSystemには価値がない。

Mission-Critical Runtimeでは、正しく動くことが可用性より先にある。

⸻

Availability

次にAvailabilityがある。

利用者が必要とするときにSystemへAccessできる。

しかしAvailabilityは単一Serverの稼働率ではない。

Application。

Database。

Network。

Identity。

External Service。

Operation。

それらを含むEnd-to-EndのServiceとして見る必要がある。

User
↓
Identity
↓
Network
↓
Application
↓
Database
↓
External Dependency

どこか一つが停止すれば、利用者から見たServiceは停止する。

したがってAvailabilityはArchitecture全体のPropertyである。

⸻

Integrity

Mission-Critical RuntimeではData Integrityも不可欠である。

Systemが復旧しても、Transaction Stateが壊れていれば復旧とは言えない。

誰が何を実行したか。

どの順序でStateが変化したか。

どのRecordがAuthoritativeか。

を追跡できなければならない。

そこで、

Event
 ↓
Validation
 ↓
Transaction
 ↓
State Change
 ↓
Audit Record

という構造を持つ。

Systemの現在Stateだけではなく、そこへ至った履歴を保持する。

⸻

Security

金融、HealthTech、Enterprise SystemではSecurityは追加機能ではない。

Identity。

Authentication。

Authorization。

Encryption。

Network Control。

Secret Management。

Vulnerability Management。

Monitoring。

Incident Response。

Audit。

をArchitectureへ組み込む。

最小構造は、

Actor
 ↓
Identity
 ↓
Authentication
 ↓
Authorization
 ↓
Action
 ↓
Audit

となる。

「Systemへ入れるか」だけではなく、

誰が何を実行できるのか

まで制御する。

⸻

Failureを前提にする

どれほど優れたSystemでもFailure Probabilityをゼロにはできない。

Hardware Failure。

Software Defect。

Human Error。

Network Failure。

Cyberattack。

External Service Failure。

Natural Disaster。

したがって、

[
Trust \neq Failure\ Zero
]

である。

重要なのは、

[
\boxed{
Prevent
\rightarrow
Detect
\rightarrow
Contain
\rightarrow
Recover
\rightarrow
Learn
}
]

というLoopである。

障害を防ぐ。

早く検知する。

影響を局所化する。

復旧する。

原因を分析する。

次のArchitectureへ反映する。

Resilienceは、Failureを認めたうえで設計される。

⸻

Recoveryを数値で定義する

「早く復旧する」ではRequirementとして曖昧である。

どのServiceをどの時間で戻すのか。

どこまでData Lossを許容できるのか。

Business Impactはどれほどか。

を定義する必要がある。

RTO。

RPO。

Service Level。

Business Criticality。

を接続する。

Business Criticality
       ↓
Recovery Requirement
       ↓
Architecture
       ↓
Backup / Replication / Failover

TechnologyからRecoveryを決めるのではない。

Business RequirementからArchitectureを決める。

⸻

Safe Change

Mission-Critical Runtimeで最も難しいことの一つは、動いているSystemを変えることである。

止めないために変えない、という選択は長期的には成立しない。

Regulationが変わる。

Businessが変わる。

Technologyが変わる。

Security Requirementが変わる。

したがって必要なのは、

StabilityとChangeabilityの両立

である。

Change
↓
Review
↓
Test
↓
Approval
↓
Deploy
↓
Observe
↓
Rollback if needed

変更そのものをGovernanceする。

Mission-Criticalとは、固定されたSystemではない。

安全に進化できるSystemである。

⸻

TestをRuntime Architectureへ入れる

TestもDevelopment終盤だけのProcessではない。

Unit Test。

Integration Test。

Regression Test。

Security Test。

Performance Test。

Failover Test。

Disaster Recovery Test。

そしてAI時代には、

Model Evaluation。

Agent Evaluation。

Prompt Regression。

Tool-use Test。

も加わる。

Code / Model / Policy
       ↓
Automated Verification
       ↓
Human Review
       ↓
Controlled Deployment

Productionへ入る前に、可能な限りFailureを検出する。

そしてProductionでもMonitoringを継続する。

⸻

Observability

Runtimeを制御するには、Runtimeを観測できなければならない。

Metrics。

Logs。

Traces。

Events。

Security Alerts。

Business KPI。

これらを接続する。

Runtime
 ↓
Telemetry
 ↓
Detection
 ↓
Diagnosis
 ↓
Action

Application Errorだけを見るのではない。

Business Stateも見る。

例えばSystemは正常でも、Transaction Failure Rateが異常に増えているかもしれない。

Technical ObservabilityとBusiness Observabilityを接続する。

⸻

Operation Knowledge

長期間運用されるSystemには、Documentだけでは表現しきれないKnowledgeが蓄積する。

このAlertは何を意味するのか。

この障害にはどのProcedureを使うのか。

どのSystemにDependencyがあるのか。

どの変更が過去に問題を起こしたのか。

誰へEscalationするのか。

これらはOperational Knowledgeである。

Incident
  ↓
Diagnosis
  ↓
Response
  ↓
Outcome
  ↓
Runbook / Knowledge

運用経験をKnowledgeへ変え、次のIncidentへ再利用する。

Mission-Critical Runtimeは、運用するほど学習する。

⸻

AIをOperationへ入れる

AI Agentは、このOperational Knowledgeを利用できる。

Logを読む。

類似Incidentを検索する。

Dependency Graphを確認する。

原因候補を提示する。

Runbookを提案する。

しかしHigh-impact Actionでは自律Executionを制限する。

Incident
  ↓
Operations Agent
  ↓
Evidence / Diagnosis
  ↓
Recommended Action
  ↓
Human Approval
  ↓
Execution
  ↓
Audit

AIはMean Time to Understandを短縮できる。

しかしProduction Authorityは別Layerとして設計する。

⸻

AIそのものがMission-Criticalになる

さらに重要なのは、AIがSystemの外部ToolではなくProduction Componentになることである。

すると従来のMonitoringだけでは足りない。

Model Version。

Data Lineage。

Retrieval Quality。

Prompt Version。

Agent Action。

Tool Call。

Human Override。

Model Drift。

を観測する必要がある。

AI Runtime
├─ Model
├─ Knowledge
├─ Agent
├─ Tool
├─ Policy
├─ Human Approval
└─ Audit

AI ReliabilityをApplication Reliabilityの中へ統合する。

⸻

Deterministic Coreを守る

AIが高度化しても、Mission-Critical SystemのすべてをProbabilisticにする必要はない。

Transaction。

Accounting。

Authorization。

Settlement。

Authoritative Record Update。

これらにはDeterministic Logicが適している領域が残る。

したがって、

Probabilistic Layer
AI / Prediction / Generation / Simulation
               ↓
Governance Boundary
               ↓
Deterministic Core
Transaction / Rule / State / Record

と分離する。

AIは理解し、予測し、生成する。

Core SystemはAuthorized State Transitionを確実に実行する。

この境界がTrustをつくる。

⸻

Legacy ModernizationとMission-Critical

Mission-Critical SystemをModernizeする場合、最大のRiskは「新しいTechnologyへ変えること」そのものではない。

既存Systemが持つBusiness Knowledgeを失うことである。

だからMigrationでは、

Current Behaviorを理解する。

Dependencyを解析する。

Business Ruleを抽出する。

新旧結果を比較する。

段階的に移行する。

Rollback可能にする。

必要がある。

[
Legacy
\rightarrow
Understand
\rightarrow
Transform
\rightarrow
Verify
\rightarrow
Transition
]

SmartransのようなAI-assisted Migrationが重要になるのも、このVerificationを含むからである。

⸻

RuntimeをAsset化する

Mission-Critical Capabilityも個別Projectだけに閉じる必要はない。

Monitoring Pattern。

Security Control。

Deployment Pipeline。

Recovery Pattern。

Runbook。

Policy。

Infrastructure Code。

AI Governance。

これらをReusable Assetにする。

Operational Experience
       ↓
Pattern
       ↓
Code / Policy / Runbook
       ↓
Reusable Runtime Asset

System Engineeringの経験そのものがSoftware Assetへ変わる。

⸻

2050 Mission-Critical Runtime

2050年には、Systemを利用する主体がさらに増える。

Human。

AI Agent。

Software Service。

Robot。

Device。

External Platform。

それらが同じRuntimeへ接続する。

しかしMission-CriticalのRequirementは変わらない。

Correctness
Availability
Integrity
Security
Traceability
Recoverability
Changeability
Human Authority

むしろAI Agentが増えるほど、誰が何を実行したかを証明する必要性は高まる。

⸻

大和総研のSystem Capabilityを金融、企業、HealthTech、基盤へ分けて見てきた。

しかしProductionの最下層では、共通する一つのOperationへ収束する。

正しく動かす。

安全に変える。

異常を観測する。

障害から戻す。

履歴を残す。

経験から学ぶ。

それがMission-Critical Runtimeである。

[
\boxed{
Build
\rightarrow
Run
\rightarrow
Observe
\rightarrow
Recover
\rightarrow
Learn
\rightarrow
Change
}
]

1953年の機械計算部から始まったComputationは、2026年には金融・企業・社会保険・Cloud・AIをProductionで動かすRuntimeへ拡張した。

では2050年、そのRuntimeは何を信頼の根拠として動くのか。

次節では第Ⅳ部を統合し、未来から必要条件を逆算する。

2050 Trusted Infrastructure。
第7節　2050 Trusted Infrastructure

2050年のInfrastructureを正確に予測することはできない。

現在主流のCloud Architectureがそのまま残っているとは限らない。

AI Modelは変わる。

Compute Architectureも変わる。

Networkも変わる。

Quantum Computingが特定領域へ実装される可能性もある。

Edge AI、Robotics、Digital Asset、新しいIdentity Architectureが広がっているかもしれない。

したがって本書は、2050年のTechnology Stackを固定しない。

固定するのは、未来の社会Infrastructureが満たさなければならないRequirementである。

[
\boxed{
Future\ Technology\ is\ uncertain.
\quad
Trust\ Requirements\ remain.
}
]

2050 Trusted Infrastructureとは未来Technologyの予想図ではない。

未来から現在へ引き戻されたTrustの設計条件である。

⸻

Infrastructureの利用主体が変わる

2026年のEnterprise Systemは、基本的に人間を中心として設計されている。

人間がLoginする。

人間がApplicationを操作する。

人間がTransactionを開始する。

2050年には、この前提そのものが変わる可能性が高い。

Human。

AI Agent。

Software Service。

Robot。

Device。

External Platform。

複数のActorが同じInfrastructureへ参加する。

Trusted Runtime
├─ Human
├─ AI Agent
├─ Software Service
├─ Device
├─ Robot
└─ External Platform

そこで最初に問われるのは、

誰がActionを起こしたのか

である。

Identityは人間だけの概念ではなくなる。

⸻

IdentityからAuthorityへ

Identityが分かっても、それだけではActionを許可できない。

何を実行できるのか。

どのDataへAccessできるのか。

誰の代理なのか。

どの目的なのか。

いつまでAuthorityがあるのか。

を定義する必要がある。

[
Identity
\rightarrow
Authority
\rightarrow
Action
]

例えばAI Agentなら、

Agent Identity
     ↓
Principal
     ↓
Purpose
     ↓
Permission
     ↓
Allowed Tools
     ↓
Execution Boundary

を持たせる。

Agentが賢いからAuthorityを与えるのではない。

AuthorityはGovernanceによって明示的に付与される。

これは2050 Infrastructureの中心原則になる。

⸻

Machine Identity

人間にはEmployee IDやCustomer IDがある。

2050 RuntimeではMachineにも同じ精度のIdentityが必要になる。

Model。

Agent。

API。

Service。

Device。

Data Pipeline。

それぞれを識別する。

どのAgent VersionがActionしたか。

どのModelを利用したか。

どのToolを呼び出したか。

どのPolicyが適用されたか。

を追跡する。

Human Identity
Machine Identity
Agent Identity
Service Identity
Device Identity

これらを一つのTrust Architectureで扱う。

⸻

DataにはAuthorityがある

2050年にはData量が増えるだけではない。

生成Dataが急増する。

Observed Data。

Authoritative Data。

Derived Data。

Predicted Data。

Simulated Data。

AI-generated Data。

これらを混同すると、Realityそのものを誤認する。

したがってDataには、

Source
Timestamp
Version
Authority
Lineage
Confidence
Purpose

を持たせる。

そして、

[
Observed
\neq
Predicted
\neq
Simulated
\neq
Generated
]

をSystem Levelで維持する。

AI時代のTrustは、「正しいDataだけを持つ」ことではなく、Dataが何者であるかを識別できることから始まる。

⸻

Authoritative State

金融ではAccount Balanceがある。

企業では正式なContractやAccounting Recordがある。

HealthTechでは制度上のRecordがある。

これらはAIが生成したSummaryとはAuthorityが違う。

したがって2050 Runtimeでも、

Authoritative State

を明確にする必要がある。

Reality
 ↓
Authoritative Record
 ↓
Derived Representation
 ↓
AI Interpretation
 ↓
Simulation

AI Interpretationがどれほど高度になっても、Authoritative Recordを無制御に上書きさせない。

IntelligenceとAuthorityを分離する。

⸻

Probabilistic IntelligenceとDeterministic Execution

これは第Ⅳ部を貫く重要原則である。

AIはProbabilisticである。

金融TransactionやAccounting Stateの更新にはDeterministicなExecutionが必要な領域がある。

そこで2050 Trusted Infrastructureを、

[
\boxed{
Probabilistic\ Intelligence
+
Governance\ Boundary
+
Deterministic\ Execution
}
]

として設計する。

AI / Agent
  ↓
Interpret
Predict
Generate
Simulate
  ↓
Policy / Approval
  ↓
Deterministic Runtime
  ↓
Authoritative State Change

AIが可能性を生成する。

SystemがAuthorityを確認する。

正式なRuntimeがRealityを変更する。

⸻

Human Authority

AI Agentが高度化しても、すべてのDecision AuthorityをMachineへ移す必要はない。

特に、

Capital。

Health。

Employment。

Legal Rights。

High-impact Financial Action。

Corporate Governance。

Public Policy。

などでは、人間のAuthorityをArchitectureへ残す。

[
AI
\rightarrow
Evidence
\rightarrow
Simulation
\rightarrow
Recommendation
\rightarrow
Human\ Decision
\rightarrow
Execution
]

Human-in-the-loopを一時的なAI性能不足への対策として扱わない。

Human AuthorityをGovernance Requirementとして設計する。

⸻

Auditability

複数Agentが連続的にActionする世界では、最終結果だけを保存しても不十分である。

なぜその結果になったのかを追跡できなければならない。

Evidence
  ↓
Model
  ↓
Agent Reasoning / Tool Use
  ↓
Recommendation
  ↓
Approval
  ↓
Execution
  ↓
Outcome

このLineageを保持する。

すべての内部推論を保存するという意味ではない。

重要なのは、Decisionを再構成するために必要なEvidence、Model、Version、Action、Approval、Outcomeを残すことである。

⸻

Securityは境界からRelationへ

2050年には、System Boundaryはさらに曖昧になる。

Cloud。

Edge。

Mobile。

External API。

AI Agent。

Partner Platform。

Device。

が接続される。

したがってSecurityは、

Inside / Outside

という単純な境界では設計しにくい。

Actor
↕
Identity
↕
Policy
↕
Resource
↕
Action
↕
Context

RelationごとにTrustを評価する。

Zero Trust Architectureは、その方向への重要な中間形態として理解できる。

⸻

Interoperability

2050年のInfrastructureでは、一社ですべてを所有することはさらに難しくなる。

金融機関。

企業。

政府。

Healthcare。

Cloud Provider。

Data Provider。

AI Provider。

External Platform。

が接続する。

そこで必要なのがInteroperabilityである。

しかしAPIがあるだけでは足りない。

同じ言葉が同じ意味を持つ必要がある。

[
Technical\ Interoperability
+
Semantic\ Interoperability
]

が必要になる。

ここで第Ⅵ部で構築するOntologyとKnowledge Graphが重要になる。

⸻

Event-driven Society

2050 Runtimeでは、Periodic BatchだけではなくEventによるState Updateがさらに増える。

Market Event。

Policy Change。

Transaction。

Cyber Incident。

Company Event。

Health Program Event。

Supply Chain Event。

AI Agent Action。

それらが発生すると、関係するSystemが反応する。

Event
 ↓
Interpret
 ↓
Policy
 ↓
Action
 ↓
State Transition
 ↓
New Event

社会InfrastructureそのものがEvent-driven Runtimeへ近づく。

⸻

SimulationとProductionを分離する

AIとDigital Twinが高度化すると、SimulationとRealityの境界管理が重要になる。

Simulation Environmentでは多数のScenarioを試せる。

Production EnvironmentではAuthorized Actionだけを実行する。

Production State
     ↓
Digital Twin
     ↓
Scenario A / B / C / D
     ↓
Evaluation
     ↓
Human Decision
     ↓
Authorized Production Change

SimulationをRealityと混同しない。

しかしRealityを変える前にSimulationできる能力を持つ。

これが2050 Infrastructureの重要なCapabilityになる。

⸻

Resilienceは社会Capabilityになる

Infrastructureが社会へ深く浸透するほど、System Failureは企業内部の問題ではなくなる。

金融。

Healthcare。

Supply Chain。

Public Service。

Communication。

AI Infrastructure。

それらが相互依存する。

したがってResilienceも個別Systemだけではなく、

System-of-Systems

として考える必要がある。

[
Local\ Resilience
\rightarrow
Enterprise\ Resilience
\rightarrow
Societal\ Resilience
]

Dependencyを可視化し、Failure PropagationをSimulationし、Recovery Priorityを設計する。

⸻

地球・世界・日本・大和総研

ここで本書のScale Axisへ戻る。

Earth
 ↕
World
 ↕
Japan
 ↕
Daiwa Institute of Research
 ↕
Organization
 ↕
System
 ↕
Data
 ↕
Person / Agent

ClimateやEnergyの変化はInfrastructureへ影響する。

GeopoliticsはSupply ChainやCybersecurityへ影響する。

Global TechnologyはJapanのSystem Architectureを変える。

Japanの制度変更は金融・企業・HealthTech Systemへ実装される。

一つのApplicationだけを最適化しても、全体のTrustは保証できない。

2050 Trusted InfrastructureはScaleを横断してDependencyを理解するArchitectureでなければならない。

⸻

Technologyを固定しないArchitecture

2050年にPython、Rust、TypeScript、Go、SQLが現在と同じ位置にある保証はない。

Cloud Providerも変わる。

AI Model Architectureも変わる。

だからTechnologyそのものをArchitectureの中心へ置かない。

Requirement
  ↓
Capability
  ↓
Interface
  ↓
Technology Selection

Technologyは交換可能にする。

RequirementとCapabilityを長寿命にする。

本書のImplementationでも、

Capability → Best Technology

という原則を採用する。

⸻

2050から2026年へ戻る

Future Pullの目的は未来を描いて終わることではない。

2050年のRequirementから2026年のGapを見つけることである。

必要になるのは、

Authoritative Data。

Temporal Data Model。

Identity。

Fine-grained Authorization。

Knowledge Graph。

Vector Intelligence。

Event Architecture。

Digital Twin。

Simulation Engine。

Agent Runtime。

Model Governance。

Audit。

Human Approval。

Observability。

Rollback。

である。

これらは2050年まで待って構築するものではない。

多くは2026年から段階的に実装できる。

[
2050\ Requirement
\rightarrow
2026\ Gap
\rightarrow
Architecture
\rightarrow
Implementation
]

これがFuture Pullである。

⸻

第Ⅳ部で見てきた金融、企業、HealthTech、基盤は、別々のSystem Businessに見える。

しかし深層では共通している。

制度やBusiness Ruleを理解する。

Dataへ翻訳する。

Architectureを設計する。

Codeへ変える。

Productionで実行する。

Securityを維持する。

Stateを観測する。

障害からRecoveryする。

変更を安全に反映する。

そして学習する。

[
\boxed{
Understand
\rightarrow
Implement
\rightarrow
Operate
\rightarrow
Trust
\rightarrow
Learn
}
]

1953年に始まったComputationは、2026年には金融・企業・社会保険・Cloudを支えるMission-Critical Runtimeへ拡張した。

2050年に必要なのは、その延長としての巨大なSystemではない。

人間、AI Agent、企業、制度、Data、Platformが接続されても、AuthorityとRealityの境界を失わないInfrastructureである。

それを本書では、

[
\boxed{
2050\ Trusted\ Infrastructure
}
]

と呼ぶ。

そして、このInfrastructureの上で次に動き始めるものがある。

観測する。

理解する。

予測する。

生成する。

Simulationする。

Softwareを書く。

AgentとしてActionする。

第Ⅴ部では、Systemの上に形成されつつある新しいEnterprise Capabilityへ進む。

AI。

愛と敬意を込めてmandala