『大和総研』――1953年から2050年へ、リサーチ・コンサルティング・金融システム・企業システム・ヘルステック・AIを接続する次世代AI完全実装コード大全（第6回）（第Ⅴ部　AI 第5章　AIを企業能力へ変える――研究からAgentic Software Engineeringまで）

第Ⅴ部　AI

Researchは、RealityをKnowledgeへ変えた。

Consultingは、KnowledgeをDecisionへ変えた。

Systemは、DecisionをProductionで動くRealityへ変えた。

ではAIは何を変えるのか。

AIは、これら三つの上に新しい第四の事業を追加するTechnologyではない。

2026年の大和総研では、AIはすでにResearch、Consulting、金融System、Enterprise System、HealthTech、Software Development、Infrastructureへ横断的に入り始めている。

したがって本書ではAIを一つの部門としてではなく、

企業Capabilityそのものを書き換える横断Layer

として捉える。

[
\boxed{
Research
+
Consulting
+
System
\xrightarrow{AI}
Intelligent\ Enterprise
}
]

⸻

AI以前にも、大和総研はDataを分析していた。

経済を予測していた。

金融市場をModel化していた。

不正取引を検知していた。

Softwareを開発していた。

Systemを運用していた。

AIによって変わるのは、これらが突然始まることではない。

観測・理解・生成・Simulation・実装の速度とScaleが変わることである。

大和総研のAI Capabilityは、

[
Social\ Science
+
Financial\ Domain
+
Data\ Science
+
System\ Engineering
+
Production\ Environment
]

の交点に形成されている。

ここに、この企業がAIを扱うときの構造的特徴がある。

⸻

AIの進化を、単なるModel性能の向上として見るだけでは不十分である。

企業Capabilityとして見れば、次のように拡張してきたと整理できる。

Predict
  ↓
Detect
  ↓
Understand
  ↓
Generate
  ↓
Simulate
  ↓
Act
  ↓
Verify

Predictは未来のStateを推定する。

Detectは異常やPatternを発見する。

Understandは大量のInformationを構造化する。

Generateは文章、Code、Scenarioを生成する。

SimulateはPossible Stateを比較する。

ActではAgentがToolやSystemを利用する。

Verifyでは結果をRealityと比較する。

AIはPrediction Engineから、Realityへ接続されるRuntime Componentへ変わり始めている。

⸻

大和総研では、この変化が複数の場所で同時に起きている。

調査では、生成AIをResearch Processへ組み込み、Economistによる検証と組み合わせる。

約2,500人のPersonaを用いた経済Simulationでは、個人LevelのResponseからMacro Indicatorを生成する試みまで進んでいる。

金融では、Prediction、AML、不正検知、Customer Support、CRMなどへAIが接続される。

HealthTechでは、Health Dataから将来Riskを分析する。

Enterprise SystemではCoding Agentを利用したAI駆動開発が進む。

Legacy ModernizationではSmartransがCode解析、変換、VerificationへAI Agentを適用する。

AIは一つの研究室に閉じていない。

企業全体のValue Chainへ分散している。

⸻

その中で重要な役割を持つのが、フロンティア研究開発センターである。

先端Technologyを研究するだけではない。

AI。

Data Science。

Generative AI。

Web3。

Software Engineering。

新しいTechnologyを、実際のBusiness Capabilityへ変換する境界に位置する。

2026年にはWeb3ビジネス開発室が新設され、CoE推進室はイノベーション企画部へ改称された。

一方で企業システム事業本部にはAX本部、基盤ソリューション本部にはAIトラスト基盤開発部が置かれている。

この組織配置が示すのは、

Research AI
Business AI
Development AI
Production AI
Trust AI

が分離された世界ではなく、相互接続される世界である。

⸻

AIを企業能力へ変えるには、Modelだけでは足りない。

Dataが必要である。

Domain Knowledgeが必要である。

Toolが必要である。

APIが必要である。

Production Systemが必要である。

Identityが必要である。

Governanceが必要である。

そして人間が必要である。

したがってEnterprise AIの最小構造は、

[
\boxed{
Model
+
Data
+
Knowledge
+
Tool
+
System
+
Governance
+
Human
}
]

となる。

最も高性能なModelを導入した企業が、最も高いAI Capabilityを持つとは限らない。

AIをRealityへ接続できる企業が強い。

⸻

ここでDataとKnowledgeを区別する必要がある。

企業には大量のDataがある。

しかしAIが必要とするのはDataだけではない。

制度。

Business Rule。

System Specification。

Research Report。

過去のDecision。

Operational Knowledge。

Client Context。

これらをMachine-readableにする必要がある。

Structured Data
     +
Documents
     +
Knowledge Graph
     +
Vector Memory
     +
Business Rules
     +
Event History
         ↓
Enterprise Intelligence

第Ⅵ部で構築するKnowledge GraphとVector Intelligenceは、このために存在する。

⸻

生成AIによって、Software Developmentも変わる。

従来は、

Human → Code → Software

だった。

これからは、

Human
  ↓
Requirement
  ↓
AI Agent
  ↓
Design / Code / Test
  ↓
Human Verification
  ↓
Software

となる。

しかし、Code Generationが高速化するほどVerificationの重要性は高まる。

大量のCodeを生成できても、それが正しいBusiness Ruleを実装している保証はない。

だから大和総研のようにMission-Critical Systemを扱う企業では、

GenerateとVerifyを一体化すること

が重要になる。

⸻

Smartransは、この構造を象徴する。

Legacy CodeをAIで変換するだけではない。

既存Codeを解析する。

Dependencyを理解する。

新しいCodeへ変換する。

Test Dataを生成する。

新旧Systemの結果を比較する。

必要なら再変換する。

つまり、

[
Understand
\rightarrow
Generate
\rightarrow
Verify
\rightarrow
Regenerate
]

というLoopである。

AIを「一度答えるModel」から、結果を検証しながら仕事を進めるAgentへ変えている。

⸻

ここからAgentic Software Engineeringが現れる。

一つのAgentがすべてを行う必要はない。

Requirement Agent
Architecture Agent
Coding Agent
Testing Agent
Security Agent
Migration Agent
Operations Agent

それぞれが専門Capabilityを持ち、人間と協働する。

しかしAgentが増えるほど、自由にActionさせることはできない。

どのRepositoryへAccessできるか。

どのToolを利用できるか。

ProductionへDeployできるか。

誰のApprovalが必要か。

を定義する。

Agentic Architectureは、同時にGovernance Architectureである。

⸻

AI Governanceも独立した倫理文書ではない。

大和総研はAI倫理ガイドラインとAI倫理委員会を整備し、人間中心、Transparency、Accountability、Privacy、Security、GovernanceなどをAI利用の原則としている。

しかしProduction AIでは、PrincipleをCodeへ落とす必要がある。

AI Principle
    ↓
Policy
    ↓
Architecture
    ↓
Control
    ↓
Runtime
    ↓
Audit

例えばHuman-centered AIなら、High-impact DecisionにHuman Approvalを入れる。

Transparencyなら、SourceとModel Versionを保持する。

Securityなら、IdentityとAuthorizationを実装する。

Accountabilityなら、Audit Trailを残す。

AI GovernanceをExecutableにする。

⸻

そしてAIは、人間を単純に置き換えるTechnologyとして設計しない。

Researcher。

Consultant。

Engineer。

Operator。

Data Scientist。

Business Professional。

それぞれの仕事を、

Human Only
Human + AI
AI-assisted
Agent-executable
Human-authorized

へ分解する。

AIが得意なOperationをMachineへ移す。

人間はQuestion、Context、Trade-off、Responsibility、Decisionを担う。

この分業は固定されない。

AI Capabilityの変化とともに継続的に再設計される。

⸻

2050年から逆算すると、AIはさらにSystemへ埋め込まれている可能性が高い。

しかし重要なのはModel名ではない。

必要なのは、

Observe。
Understand。
Generate。
Simulate。
Act。
Verify。
Learn。

というCapabilityである。

それを安全に接続する。

[
AI
\rightarrow
Evidence
\rightarrow
Simulation
\rightarrow
Recommendation
\rightarrow
Human\ Decision
\rightarrow
Authorized\ Execution
\rightarrow
Reality
\rightarrow
Learning
]

このLoopが、AIを単なるProductivity ToolからEnterprise Intelligenceへ変える。

⸻

第Ⅴ部では、大和総研のAI Capabilityを、研究からProductionまで一つの連続したArchitectureとして読み解く。

フロンティア研究開発センター。

Predict・Detect・Understand。

Generate・Simulate。

Smartrans。

AI駆動開発。

AI Governance。

そして2050 Agentic Enterprise。

生成軸は、

[
\boxed{
Predict
\rightarrow
Understand
\rightarrow
Generate
\rightarrow
Simulate
\rightarrow
Act
\rightarrow
Verify
\rightarrow
Learn
}
]

である。

1953年に分かれていたKnowledgeとComputationは、AIによって再び近づいている。

しかし今回は、Knowledgeを計算するだけではない。

KnowledgeからPossible Stateを生成し、Softwareをつくり、Systemへ接続し、その結果をRealityによって再検証できる。

大和総研にとってAIの核心は、AIそのものを研究することではない。

AIを企業能力へ変えること。
第5章　AIを企業能力へ変える

――研究からAgentic Software Engineeringまで

第1節　フロンティア研究開発センター

先端技術を研究することと、企業能力へ変えることは同じではない。

新しいAI Modelを評価する。

Algorithmを検証する。

Prototypeをつくる。

論文を読む。

それだけならResearchで終わる。

企業に必要なのは、その先である。

TechnologyをBusiness Requirementへ接続する。

実際のDataで検証する。

Systemへ組み込む。

SecurityとGovernanceを設計する。

Productionで動かす。

再利用可能なAssetへ変える。

大和総研のフロンティア研究開発センターは、この境界に位置する。

[
\boxed{
Technology
\rightarrow
Research
\rightarrow
Validation
\rightarrow
Business
\rightarrow
Production
}
]

その役割は、未来Technologyを眺めることではない。

未来Capabilityを現在の企業へ実装可能な形に翻訳することである。

⸻

R&DとBusinessの間

先端Technologyには不確実性がある。

性能が高くてもCostが合わないことがある。

Prototypeでは動いてもProductionでは安定しないことがある。

一般Benchmarkでは優れていても、実際のBusiness Dataでは既存手法に負けることもある。

したがってTechnology Adoptionには段階が必要になる。

Explore
  ↓
Experiment
  ↓
Evaluate
  ↓
Prototype
  ↓
Business Validation
  ↓
Production
  ↓
Scale

フロンティア研究開発センターは、このTransformationを担う。

Research LabとSystem Integratorの中間ではない。

ResearchをProductionへ接続するTranslation Layerとして理解する方が正確である。

⸻

Predictから始まったAI Capability

大和総研では、生成AI以前からMachine Learningを金融・Business領域へ適用してきた。

株価や為替に関するPrediction。

不公正取引のDetection。

AML。

Customer Analysis。

Data Analytics。

この段階でAIの主要Operationは、

[
Data
\rightarrow
Pattern
\rightarrow
Prediction
]

だった。

しかし生成AIの登場によって扱える対象が拡張した。

文章。

Code。

Knowledge。

Scenario。

Conversation。

Software Requirement。

AIはStructured Dataだけでなく、企業に蓄積されたUnstructured Knowledgeへ入り始めた。

⸻

ModelではなくProblemから始める

AI Projectで起こりやすい誤りは、

「最新Modelをどこへ使えるか」

から考えることである。

順序は逆でなければならない。

Problem
  ↓
Requirement
  ↓
Data
  ↓
Candidate Methods
  ↓
Validation
  ↓
Model Selection

Deep Learningが最適とは限らない。

Generative AIが最適とも限らない。

Traditional Machine Learning。

Statistical Model。

Rule-based System。

Optimization。

LLM。

複数手法を比較する。

大和総研のTechnology Selectionで重要なのは、最新性ではなく実Dataに対する適合性である。

⸻

TSFMが示すEngineering Culture

この考え方を象徴するのが、Time Series Foundation Modelを含む時系列分析への姿勢である。

新しいFoundation Modelが登場しても、特定のBusiness Dataでは適切に設計された従来手法が上回ることがある。

これはAIの限界ではない。

Engineeringの基本である。

[
Newest\ Model
\neq
Best\ Model
]

必要なのは、

[
Problem
+
Data
+
Method
+
Validation
]

の整合である。

AI研究企業に必要なのは、Modelへの信仰ではなくModel Selection Capabilityである。

⸻

Data ScienceをBusinessへ接続する

Data Scienceの価値はAccuracyだけでは決まらない。

例えば高精度なPrediction Modelができても、

PredictionがBusiness Processへ入らない。

利用者が理解できない。

Actionへ接続できない。

運用Costが高すぎる。

Data更新に追随できない。

ならProduction Capabilityにはならない。

そこで、

Data
 ↓
Model
 ↓
Prediction
 ↓
Interpretation
 ↓
Business Action
 ↓
Outcome

までを見る。

AI OutputではなくBusiness OutcomeまでをArchitectureに含める。

⸻

金融AI

金融は大和総研のAI Capabilityが早く蓄積されたDomainの一つである。

Prediction。

不公正取引Detection。

AML/CFT。

Customer Support。

CRM。

Knowledge Search。

生成AI。

金融ではAI精度だけでなく、

False Positive。

Explainability。

Latency。

Security。

Audit。

Human Review。

などが同時に問題になる。

したがってFinancial AIは、

[
Model\ Performance
+
Domain\ Knowledge
+
Production\ Engineering
+
Governance
]

によって成立する。

⸻

Health AI

HealthTechでは条件がさらに変わる。

扱うDataが人間に近い。

Privacy Sensitivityが高い。

Population PatternとIndividual Realityを分離しなければならない。

大和総研では、同意を得たHealth Dataを用いた生活習慣病Riskの予測など、AIとHealthTechを接続する研究開発も進められている。

ここでも、

Consent
  ↓
Data
  ↓
Model
  ↓
Prediction
  ↓
Human Interpretation
  ↓
Support

というBoundaryが必要になる。

AI ResearchがDomain Governanceと分離できないことを示す例である。

⸻

Generative AIという転換

生成AIによる最大の変化は、AIが「予測するModel」から「生成するInterface」へ広がったことである。

Text。

Code。

Query。

Scenario。

Explanation。

Software。

これによって、

[
Predict
\rightarrow
Generate
]

が加わった。

さらにTool Useが可能になると、

[
Generate
\rightarrow
Act
]

へ進む。

AIはInformationを返すだけではなく、Systemを利用する主体になり始める。

ここからAI Agentが生まれる。

⸻

AI Agent

Agentを単なるChatbotと区別する。

Chatbotは基本的に、

[
Question
\rightarrow
Answer
]

である。

Agentは、

Goal
↓
Plan
↓
Retrieve
↓
Reason
↓
Use Tool
↓
Observe Result
↓
Revise
↓
Complete

というLoopを持つ。

企業利用ではさらに、

Identity。

Permission。

Policy。

Audit。

Human Approval。

が必要になる。

したがってEnterprise Agentは、

[
Reasoning
+
Knowledge
+
Tools
+
Governance
]

として設計する。

⸻

ResearchからAgent Skillへ

ここでResearchの成果物そのものが変わる。

従来ならReport。

Model。

Prototype。

だった。

これからは、

Ontology。

Evaluation Dataset。

Prompt Pattern。

Tool。

API。

Agent Skill。

Policy。

Workflow。

などもResearch Assetになる。

Research Knowledge
      ↓
Formalization
      ↓
Model / Rule / Tool
      ↓
Agent Skill
      ↓
Reusable Capability

Knowledgeを人間が読むDocumentだけでなく、Machineが実行できるCapabilityへ変換する。

⸻

Software Engineeringとの融合

生成AIはSoftware Developmentそのものも研究対象にした。

Requirementを整理する。

Architectureを提案する。

Codeを書く。

Testを生成する。

Documentationを書く。

Legacy Codeを理解する。

Migrationする。

これによって、

AI Research

と

Software Engineering

の境界が薄くなる。

大和総研がMission-Critical Systemを持つことは、この領域で重要な意味を持つ。

生成したCodeをDemoで終わらせず、Production Requirementで検証できるからである。

⸻

SmartransというAsset化

Smartransは、この接続を具体化した例である。

AI AgentがLegacy Codeを解析する。

Dependencyを把握する。

新しいTechnologyへ変換する。

Test Dataを生成する。

新旧結果を比較する。

必要なら再変換する。

[
Analyze
\rightarrow
Transform
\rightarrow
Test
\rightarrow
Compare
\rightarrow
Refine
]

ここではAI Researchが直接Software Engineering Capabilityへ変換されている。

さらに再利用可能なService、Architecture、知的財産へ展開すれば、

[
Research
\rightarrow
Algorithm
\rightarrow
Software
\rightarrow
IP
\rightarrow
Business\ Asset
]

となる。

R&DがCost CenterではなくCapability Generatorになる。

⸻

2026年の組織変化

2026年4月、フロンティア研究開発センターにはWeb3ビジネス開発室が新設され、CoE推進室はイノベーション企画部へ改称された。

ここから読み取れるのは、先端技術の対象がAIだけに閉じていないことである。

AI。

Data。

Software Engineering。

Web3。

Cloud。

新しいComputeやInterface。

Technology Option Spaceは変化し続ける。

重要なのは特定Technologyへ企業全体を固定することではない。

[
Requirement
\rightarrow
Capability
\rightarrow
Best\ Technology
]

という選択能力を持つことである。

⸻

R&Dを全社へ循環させる

研究成果が研究部門に閉じれば、Enterprise Capabilityにはならない。

Frontier R&D
    ↓
Research
    ↓
Consulting
    ↓
Financial Systems
    ↓
Enterprise Systems
    ↓
HealthTech
    ↓
Infrastructure
    ↓
Production Feedback
    ↺

金融で得たKnowledgeが研究へ戻る。

HealthTechで得たRequirementがModel Researchへ戻る。

Productionで起きたFailureが次のArchitectureへ戻る。

企業全体がExperimentとLearningの循環を持つ。

⸻

人材もCapabilityになる

AI CapabilityをModelだけで保持することはできない。

Data Scientist。

Engineer。

Researcher。

Consultant。

Domain Expert。

Operator。

それぞれがAIを理解する必要がある。

大和総研では社内人材育成の取り組みとしてSouken Labなどを通じ、PythonやData Analysis、Model構築を学ぶ仕組みも展開してきた。

ここで重要なのは、全社員をAI Researcherにすることではない。

[
Deep\ AI\ Specialists
+
AI\text{-}capable\ Domain\ Experts
]

という組み合わせをつくることである。

⸻

2050 Future Capability Generator

2050年にどのTechnologyがFrontierになっているかは分からない。

現在のGenerative AIが別のArchitectureへ置き換わっている可能性もある。

だからフロンティア研究開発センターの未来価値を、特定Technologyで定義しない。

必要なのは、

Observe Technology
       ↓
Understand
       ↓
Experiment
       ↓
Validate
       ↓
Formalize
       ↓
Implement
       ↓
Scale
       ↓
Learn

というCapabilityである。

未来Technologyを発見する組織ではなく、

未来Technologyを企業能力へ変換し続ける組織

として捉える。

⸻

フロンティア研究開発センターは、大和総研のAIを一つのTechnologyからEnterprise Capabilityへ変える起点である。

Researchする。

比較する。

検証する。

Businessへ翻訳する。

Softwareへ変える。

Productionで確かめる。

Asset化する。

そして全社へ循環させる。

[
\boxed{
Research
\rightarrow
Validation
\rightarrow
Implementation
\rightarrow
Production
\rightarrow
Reusable\ Capability
}
]

この循環を分解すると、AIが企業の中で何をできるようになってきたのかが見えてくる。

最初のCapabilityは、未来を当てることだけではない。

観測したDataからPatternを見つけ、異常を捉え、複雑なRealityを理解可能な形へ変えることである。

次節では、AIの基礎Operationを三つに分解する。

Predict・Detect・Understand。
第2節　Predict・Detect・Understand

AIの企業利用は、生成AIから始まったわけではない。

企業が長く求めてきたのは、Dataの中から未来や異常や構造を読み取る能力だった。

何が起こる可能性が高いのか。

何が通常と異なるのか。

大量のDataは何を意味しているのか。

この三つを、本書では、

[
\boxed{
Predict
;+;
Detect
;+;
Understand
}
]

として整理する。

PredictはPossible Futureを推定する。

Detectは変化や異常を発見する。

UnderstandはDataとContextを結びつけ、人間が判断可能なKnowledgeへ変換する。

生成AIやAI Agentへ進む前に、大和総研のAI Capabilityにはこの基礎層がある。

⸻

Predict――未来を一点ではなく分布として見る

Predictionとは未来を当てることではない。

現在までのDataとModelから、将来Stateについて条件付きの推定を行うことである。

[
P(Y_{t+1}\mid X_{\leq t},M)
]

ここで重要なのは、PredictionがRealityそのものではないことである。

Observed。

Estimated。

Forecast。

Scenario。

これらを区別する。

Observed Data
    ↓
Model
    ↓
Prediction
    ↓
Uncertainty
    ↓
Human Interpretation

優れたPrediction Systemは、数字を一つ返すだけではない。

その数字が何を前提としているかを示す。

⸻

金融市場をPredictする

大和総研は生成AI以前から、株価・為替など金融市場へのMachine Learning適用を研究してきた。

金融市場はPredictionにとって難しい対象である。

Market Structureが変わる。

Policyが変わる。

参加者が学習する。

External Shockが起こる。

過去に有効だったRelationが将来も維持されるとは限らない。

つまり、

[
Historical\ Fit
\neq
Future\ Accuracy
]

である。

したがって金融AIでは、Model精度だけでなく、

Data Period。

Market Regime。

Feature Stability。

Out-of-sample Performance。

Model Drift。

を継続的に確認する必要がある。

⸻

Economic Prediction

Researchで扱ったEconomic IntelligenceにもPredictが存在する。

GDP。

Inflation。

Employment。

Consumption。

Interest Rate。

Exchange Rate。

企業収益。

しかしMacro Economyでは、多数のVariableが相互依存する。

そこで一点Forecastだけでなく、

Baseline
Optimistic
Adverse
Policy Scenario
External Shock Scenario

という複数Possible Stateを扱う。

Predictionは次第にSimulationへ近づく。

Predictが「何が起こりそうか」を問うなら、Simulationは「条件を変えたら何が起こり得るか」を問う。

⸻

Health RiskをPredictする

HealthTechでもPredictionが使われる。

現在のHealth Dataから、将来のRiskを推定する。

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

しかし、

[
Risk\ Prediction
\neq
Diagnosis
]

である。

Predictionは可能性であり、本人の未来を確定するものではない。

だからOutputは、

Current Data
    ↓
Risk Model
    ↓
Probability / Risk Level
    ↓
Explanation
    ↓
Human / Professional Interpretation

として扱う。

Predictionの目的は人間を分類することではなく、早く観測し、選択可能なActionを増やすことにある。

⸻

Detect――見えていなかった変化を発見する

Predictが未来を見るOperationなら、Detectは現在のDataに潜むSignalを見つけるOperationである。

異常。

不正。

変化点。

Rare Pattern。

Risk Signal。

金融では特に重要である。

不公正取引。

AML/CFT。

異常Transaction。

Cybersecurity。

大量のNormal Dataの中から、注意すべき少数のEventを抽出する。

[
Large\ Event\ Space
\rightarrow
Candidate\ Risk\ Events
]

これがDetectである。

⸻

False Positiveという問題

Detectionでは、見逃しを減らせばよいわけではない。

すべてを「怪しい」と判定すれば、Detection Systemとして機能しない。

False Negativeを減らす。

同時にFalse Positiveも制御する。

[
Precision
\leftrightarrow
Recall
]

というTrade-offがある。

特にAMLやComplianceでは、AI OutputをそのままFinal Judgmentにしない。

Transaction
    ↓
Detection Model
    ↓
Risk Signal
    ↓
Human Investigation
    ↓
Decision

AIはInvestigation Spaceを絞る。

Authorityは適切な人間・Processへ残す。

⸻

PatternとMeaningは違う

AIはPatternを見つけられる。

しかしPatternが見つかったことと、そのMeaningを理解したことは同じではない。

二つのVariableが相関している。

あるCustomer Groupに特徴がある。

あるTransaction Patternが異常に見える。

それだけでは原因は分からない。

[
Correlation
\neq
Causality
]

そこで第三のOperation、Understandが必要になる。

⸻

Understand――Contextへ戻す

Understandとは、AIが人間と同じ意味で世界を理解したと断言することではない。

Enterprise Architecture上は、

DataをContext、Relation、Evidenceへ接続し、人間が判断できるRepresentationへ変えること

として定義する方が安全である。

Data
↓
Pattern
↓
Relation
↓
Context
↓
Evidence
↓
Interpretation

PredictionやDetectionのOutputを、Domain Knowledgeへ戻す。

ここでResearcher、Consultant、Financial Expert、EngineerのKnowledgeが重要になる。

⸻

LLMがUnderstandを拡張した

従来のAIはStructured Dataを得意としていた。

生成AIは、企業に大量に存在するUnstructured InformationへAccess可能なInterfaceをつくった。

Research Report。

Regulation。

Manual。

Specification。

Minutes。

Email。

FAQ。

Source Code。

これらをSemanticに検索し、関連情報をまとめ、Questionへ応答できる。

しかしLLMの内部Knowledgeだけに依存すれば、企業固有のRealityから離れる。

そこで、

[
LLM
+
Authoritative\ Data
+
Enterprise\ Knowledge
]

が必要になる。

⸻

RetrievalによってKnowledgeへ接続する

Enterprise AIではRetrievalが重要になる。

Question
  ↓
Intent
  ↓
Retrieve
  ├─ SQL
  ├─ Knowledge Graph
  └─ Vector Search
  ↓
Evidence
  ↓
LLM
  ↓
Response

SQLはAuthoritative Stateを取る。

Knowledge GraphはRelationを取る。

Vector SearchはSemanticに近いDocumentを取る。

それぞれ役割が違う。

この三つを使い分けることで、LLMを企業KnowledgeへGroundする。

⸻

Contextual Knowledge Search

大和総研が外部企業向けに取り組む生成AI・Knowledge Searchでも、この問題が現れる。

金融や決済のような専門Domainでは、一般LLMだけでは専門用語、社内Knowledge、独自Processを正確に扱えない。

必要なのは、

General Intelligence + Domain Context

である。

ただしRetrievalしたDocumentが存在するから正しいとは限らない。

古い可能性がある。

Authorityが低い可能性がある。

利用者にAccess権がない可能性もある。

したがってKnowledgeには、

Source
Authority
Timestamp
Version
Access Policy

を持たせる。

⸻

ExplainではなくEvidenceを返す

AIが流暢なExplanationを生成しても、それだけでTrustworthyとは言えない。

必要なのは、

「なぜそう言ったか」

をEvidenceへ戻せることである。

AI Output
  ↓
Evidence
  ├─ Data
  ├─ Source Document
  ├─ Model
  ├─ Rule
  └─ Assumption

説明文の説得力ではなく、Evidence Traceabilityを持つ。

これはResearch AIにもConsulting AIにもFinancial AIにも共通する。

⸻

Predict・Detect・Understandを接続する

三つのOperationは独立していない。

例えば金融Riskなら、

Detectが異常Transactionを見つける。

Understandが過去の取引、Customer、RuleとのRelationを整理する。

Predictが将来Riskを推定する。

Detect
 ↓
Understand
 ↓
Predict
 ↓
Human Decision

逆の順序もある。

PredictionがRiskを示す。

Detectionが関連Eventを探す。

Understandが背景を説明する。

AI Capabilityは単一Modelではなく、複数OperationのCompositionになる。

⸻

Multi-Model Architecture

だからEnterprise AIでは、一つの巨大Modelですべてを解決する必要はない。

Time-series Model。

Classification Model。

Anomaly Detection。

Graph Algorithm。

Optimization。

LLM。

Rule Engine。

それぞれに得意領域がある。

Problem
 ↓
Router
 ├─ Statistical Model
 ├─ Machine Learning
 ├─ Graph
 ├─ LLM
 ├─ Optimization
 └─ Rule Engine

Requirementに応じて最適なMethodを選ぶ。

Newest ModelではなくBest Capability。

これはフロンティア研究開発センターのModel Selection原則とも一致する。

⸻

AccuracyからDecision Valueへ

AI Modelの評価をAccuracyだけで終わらせない。

企業では、

PredictionがDecisionを改善したか。

DetectionがInvestigationを効率化したか。

Knowledge Searchが調査時間を短縮したか。

Riskが減ったか。

Customer Experienceが改善したか。

を見る必要がある。

[
Model\ Metric
\rightarrow
Operational\ Metric
\rightarrow
Business\ Outcome
]

AIを研究成果から企業Capabilityへ変えるための重要なTranslationである。

⸻

Continuous Learning

Realityは変わる。

Market Regimeが変わる。

Customer Behaviorが変わる。

Regulationが変わる。

Languageが変わる。

したがってModelも永続的には固定できない。

Observe
 ↓
Predict / Detect / Understand
 ↓
Human Action
 ↓
Outcome
 ↓
Evaluation
 ↓
Model / Rule Update
 ↺

AI SystemはDeployして完成するProductではない。

継続的にRealityとの差を測るLearning Systemである。

⸻

2050 Intelligence Layer

2050年から見ると、Predict・Detect・Understandは独立Applicationではなく、Enterprise Runtimeの基礎Capabilityになっている可能性が高い。

金融SystemがTransactionを処理すると同時にRiskをDetectする。

企業SystemがBusiness StateをUnderstandする。

HealthTechがPossible RiskをPredictする。

Research Systemが経済変化をDetectする。

Enterprise Event
     ↓
Detect
     ↓
Understand
     ↓
Predict
     ↓
Possible Action

AIが後付けされたSystemから、Intelligenceを内蔵したSystemへ変わる。

⸻

大和総研のAI Capabilityを生成AIだけから見ると、その蓄積の一部しか見えない。

金融市場をPredictする。

不正やRiskをDetectする。

DataとDocumentをContextへ接続してUnderstandする。

この三つが、生成AI以前から現在までをつなぐ基礎層である。

[
\boxed{
Predict
+
Detect
+
Understand

Observation\ Intelligence
}
]

しかしAIは、観測したRealityを説明するだけでは終わらなくなった。

文章を生成する。

Codeを生成する。

Scenarioを生成する。

そして、まだ起きていないPossible StateをSimulationする。

AIはObservationからGenerationへ進む。

次節では、その相転換点を扱う。

Generate・Simulate。
第3節　Generate・Simulate

Predict・Detect・Understandが、すでに存在するDataから未来・異常・構造を読むOperationだとすれば、GenerateとSimulateは、その先へ進む。

まだ存在しない文章をつくる。

まだ存在しないCodeを書く。

まだ存在しないScenarioを構成する。

まだ起きていないPossible Stateを比較する。

AIは観測装置から、可能性を生成する装置へ変わり始めた。

[
\boxed{
Observe
\rightarrow
Understand
\rightarrow
Generate
\rightarrow
Simulate
}
]

ここで重要なのは、GenerateされたものをRealityと混同しないことである。

AIがつくるのは、Realityそのものではない。

Candidate。

Draft。

Hypothesis。

Scenario。

Possible State。

である。

⸻

Generate――既存Knowledgeから新しいRepresentationをつくる

生成AIの基本Operationは、

[
Context
+
Instruction
\rightarrow
Generated\ Output
]

である。

文章。

要約。

説明。

Report Draft。

Query。

Code。

Test。

Scenario。

これまで人間が一つずつ作成していたRepresentationを高速に生成できる。

しかし生成能力の本質は「文章がうまいこと」ではない。

Knowledgeを別の形式へ翻訳できることにある。

例えば、

Data
 ↓
Analysis
 ↓
Natural Language Report

だけではない。

Business Requirement
       ↓
Specification
       ↓
Code
       ↓
Test

というTranslationにも使える。

生成AIは、Representation間の変換Engineとして企業の各Layerへ入る。

⸻

Research ReportをGenerateする

大和総研では、2023年にChatGPTをResearch Report作成Processへ組み込む実証が行われた。

AI Modelによって算出した指標や分析材料をもとに生成AIがDraftを作成し、Economistが内容を検証し、分析を追加する。

このProcessではReport作成時間が約半分まで短縮されたと報告されている。

重要なのは、

[
AI\ Generates
\quad
Human\ Verifies
]

という構造である。

AIがEconomistを置き換えたのではない。

Draft GenerationをMachineへ移し、人間がInterpretation、Causality、Context、Responsibilityへ集中する。

⸻

GenerationとEvidenceを接続する

生成AIの弱点は、流暢な文章を生成できることと、事実であることが一致しない点にある。

したがってEnterprise Generationでは、

Question / Task
     ↓
Retrieve Evidence
     ↓
Generate
     ↓
Citation / Provenance
     ↓
Human Verification

とする。

生成物には、

Source。

Timestamp。

Model Version。

Assumption。

Confidence。

を接続する。

Generationを自由作文からEvidence-grounded Generationへ変える。

⸻

CodeをGenerateする

企業にとって、生成AIの影響が特に大きい領域がSoftware Developmentである。

RequirementからCodeを生成する。

Legacy Codeを説明する。

Test Caseをつくる。

SQLを書く。

API Definitionを生成する。

Documentationを更新する。

これによってSoftware Engineeringの生産速度は大きく変わる可能性がある。

しかし、

[
Generated\ Code
\neq
Correct\ Software
]

である。

生成速度が上がるほど、ArchitectureとVerificationが重要になる。

⸻

GenerateからVerifyへ

Mission-Critical Softwareでは、AIがCodeを生成して終わることはできない。

Generate
  ↓
Compile
  ↓
Static Analysis
  ↓
Test
  ↓
Security Check
  ↓
Behavior Comparison
  ↓
Human Review

生成されたCodeを複数の方法で検証する。

この構造は、後に扱うSmartransやAI駆動開発へ直接つながる。

AI Software Engineeringの核心は、

Generate faster

ではなく、

Generate and Verify repeatedly

である。

⸻

ScenarioをGenerateする

Consultingでは、Generationの対象は文章だけではない。

企業が取り得るOptionそのものを生成できる。

例えば、

投資を増やす。

事業を売却する。

M&Aを行う。

Capital Allocationを変える。

Organizationを変更する。

AI導入を進める。

何もしない。

複数のOptionを生成する。

Current State
     ↓
Decision Question
     ↓
Option Generation
  ├─ A
  ├─ B
  ├─ C
  └─ Do Nothing

AIはAnswerを一つ返すのではなく、Decision Spaceを広げるために使える。

⸻

Simulate――生成した可能性を時間へ展開する

GenerateがCandidateをつくるOperationなら、Simulateは、そのCandidateをReality Modelの上で動かすOperationである。

[
State_t
+
Action
+
External\ Condition
\rightarrow
Possible\ State_{t+1}
]

例えば企業が新しいInvestmentを行った場合、

Revenue。

Cash Flow。

Capital Efficiency。

Human Resource。

Risk。

System Load。

などがどう変化する可能性があるかを見る。

Simulationは未来を確定するのではない。

条件付きのPossible Stateを生成する。

⸻

ForecastとSimulationの違い

ForecastとSimulationは似ているが、問いが違う。

Forecastは、

このまま進んだら何が起こりそうか。

Simulationは、

条件を変えたら何が起こり得るか。

である。

Forecast:
Current State
  ↓
Likely Future
Simulation:
Current State
  + Decision A/B/C
  ↓
Multiple Possible Futures

Decision Intelligenceでは後者が重要になる。

企業は未来を当てたいのではなく、選択したActionによって何が変わるかを知りたいからである。

⸻

2,500人からMacroを生成する

大和総研が2026年に行った生成AI Agent Simulationは、この方向を具体的に示す。

個人調査Dataなどをもとに約2,500人のPersonaを構成し、それぞれに経済状況を提示してInflation Expectationなどを生成させる。

そして個々のResponseを集約し、Macro Indicatorとして比較する。

[
Micro\ Agents
\rightarrow
Individual\ Responses
\rightarrow
Aggregation
\rightarrow
Macro\ Indicator
]

報告では、生成された期待Inflationと内閣府の指標との相関が、全期間で0.83、ModelのKnowledge Cutoff後でも0.62となった。

ここでAIはReportを生成しているのではない。

Synthetic Populationを通じて経済反応をSimulationしている。

⸻

Agent数が多ければよいわけではない

しかし、2,500 Agentを使ったからRealityを再現できたとは限らない。

Persona Definition。

Prompt。

Model。

Aggregation Method。

External Condition。

Interaction Structure。

によって結果は変わる。

[
More\ Agents
\neq
More\ Reality
]

重要なのは、

どのDataからPersonaをつくったか。

どのAssumptionを置いたか。

どのRealityと比較したか。

を明示することである。

Simulation QualityはAgent数ではなく、Model StructureとValidationによって決まる。

⸻

Interactionを加える

現在のPersona Simulationをさらに発展させると、人間同士のRelationをModelへ入れる必要がある。

消費者は孤立してDecisionしていない。

企業。

Media。

Financial Market。

Government。

Household。

Social Network。

が相互作用する。

Household Agents
      ↕
Company Agents
      ↕
Financial Agents
      ↕
Government Agent
      ↕
External World

一つのAgentが他のAgentのActionを観測し、その結果によってBehaviorを変える。

ここからMulti-Agent Simulationが現れる。

⸻

Economic Digital Twinとの境界

この方向をEconomic Digital Twinと呼ぶことは可能だが、言葉を拡大しすぎてはならない。

Realityの完全Replicaではない。

むしろ、

[
Observed\ State
+
Model
+
Agents
+
Scenario
\rightarrow
Possible\ State
]

というSimulation Environmentである。

Digital Twinの価値はRealityと同じになることではない。

Realityとの差を計測しながら更新できることにある。

⸻

Corporate Simulation

同じ構造は企業にも適用できる。

Corporate Digital Twin上で、

Investment Scenario。

M&A Scenario。

Capital Allocation Scenario。

Organization Scenario。

AI Adoption Scenario。

を比較する。

Enterprise State
     ↓
Scenario Generator
     ↓
Simulation Engine
     ↓
Possible Enterprise States
     ↓
Decision Comparison

Research AIが経済をSimulationし、Consulting AIが企業DecisionをSimulationする。

二つを接続すると、

External Economy × Internal Enterprise

のScenario Analysisが可能になる。

⸻

System Simulation

System LayerでもSimulationは重要である。

新しいArchitectureへ移行した場合。

Trafficが急増した場合。

Cloud RegionがFailureした場合。

Cyberattackが発生した場合。

AI Agentが大量にToolを呼び出した場合。

Productionへ変更を入れる前にPossible Behaviorを確認する。

[
Change
\rightarrow
Simulation
\rightarrow
Verification
\rightarrow
Production
]

第Ⅳ部で扱ったMission-Critical Runtimeへ、Simulationが安全装置として接続される。

⸻

Synthetic Data

SimulationとGenerationの交点にはSynthetic Dataがある。

実Dataが不足する。

Privacy上そのまま使えない。

Rare Eventが少なすぎる。

こうした場合、条件を制御したSynthetic Dataを生成してTestやModel Trainingへ利用できる。

ただし、

[
Synthetic\ Data
\neq
Observed\ Data
]

である。

MetadataとLineageで明確に区別する。

Synthetic DataがRealityへ紛れ込まないArchitectureが必要になる。

⸻

Counterfactual

Simulationの強力な用途がCounterfactualである。

「あのDecisionをしなかったらどうなっていたか。」

「Interest Rateが異なったらどうなるか。」

「Investmentを半年遅らせたらどうなるか。」

実際には一つのRealityしか観測できない。

Simulationでは、

Actual State
  ├─ Action A → Possible State A
  ├─ Action B → Possible State B
  └─ No Action → Possible State C

と比較できる。

もちろんCounterfactualはFactではない。

しかしDecisionを考えるための重要なAnalysis Spaceになる。

⸻

GenerateとSimulateを分離する

GenerationとSimulationは混同しやすい。

生成AIが「将来はこうなる」と文章を書いたからといって、それはSimulationではない。

Simulationには、

State。

Variable。

Rule。

Relation。

Time。

External Condition。

Evaluation。

が必要になる。

したがって、

[
Narrative\ Generation
\neq
Simulation
]

である。

LLMはScenarioをGenerateできる。

Simulation EngineはそのScenarioをModel上で評価する。

この分離が重要になる。

⸻

Multi-Model Simulation

高度なSimulationではLLM一つですべてを計算する必要はない。

LLM
 → Narrative / Agent Behavior
Econometric Model
 → Macro Dynamics
Optimization
 → Resource Allocation
Graph Model
 → Network Effects
Rules
 → Regulation / Constraints
Numerical Model
 → Quantitative Dynamics

複数Modelを組み合わせる。

AIはSimulation全体をOrchestrateする役割も持てる。

これがMulti-Agent・Multi-Model Architectureへつながる。

⸻

GenerationにAuthorityを与えすぎない

生成AIが大量のOption、Code、Recommendationを作れるようになるほど、Authority Boundaryが重要になる。

Generate。

Simulate。

Recommend。

Approve。

Execute。

を分離する。

Generate
  ↓
Simulate
  ↓
Evaluate
  ↓
Recommend
  ↓
Human Decide
  ↓
Authorized Execute

生成できることと、実行してよいことは別である。

この原則は金融、企業、HealthTech、Software Developmentすべてに共通する。

⸻

Generate・Simulate・Verify

AIが企業能力になるためには、GenerationとSimulationの後にRealityによるVerificationが必要になる。

Generate
  ↓
Simulate
  ↓
Decide
  ↓
Implement
  ↓
Observe Reality
  ↓
Compare
  ↓
Learn

Predictionが外れればModelを修正する。

SimulationとRealityがずれればAssumptionを修正する。

Generated CodeにDefectがあればDevelopment Processを修正する。

AIは生成して終わらない。

Realityとの差によって学習する。

⸻

2050 Generative Enterprise

2050年から見ると、企業は固定されたPlanを年に一度作るだけではなく、継続的にPossible Stateを生成している可能性がある。

Economic Scenario。

Market Scenario。

Corporate Scenario。

System Scenario。

Risk Scenario。

それらをAgentが生成し、Simulation Engineで比較し、人間がDecisionする。

[
\boxed{
Current\ Reality
\rightarrow
Possible\ Realities
\rightarrow
Human\ Choice
\rightarrow
New\ Reality
}
]

この構造では、AIの価値はAnswerを返すことではない。

選択可能な未来空間を広げることにある。

⸻

大和総研のAIは、Predict・Detect・Understandから、Generate・Simulateへ進み始めている。

Research Reportを生成する。

Codeを生成する。

Personaを生成する。

Scenarioを生成する。

Possible StateをSimulationする。

しかし、その核心はGeneration量ではない。

[
\boxed{
Generate
+
Simulate
+
Verify
}
]

という循環である。

そして、この循環が最も直接的にSoftware Engineeringへ実装された一つの例がある。

Legacy Systemを理解し、Codeを変換し、新旧の結果を比較し、再び変換する。

次節では、大和総研のAIがResearchからSoftware Assetへ変わった具体例を扱う。

Smartrans。
第4節　Smartrans

AIが企業能力になる瞬間は、Modelが高性能になったときではない。

実際の業務Problemを解き、繰り返し利用できるSoftware Assetになったときである。

大和総研のSmartransは、その意味で重要な事例である。

対象は、Legacy System Modernization。

長期間運用されてきたSystemを理解し、新しいTechnologyへ移行し、その結果が正しいかを検証する。

ここではAIは文章を生成するだけではない。

Codeを読む。

Dependencyを解析する。

Codeを変換する。

Testを生成する。

新旧Systemの挙動を比較する。

必要なら修正する。

[
\boxed{
Understand
\rightarrow
Transform
\rightarrow
Verify
\rightarrow
Refine
}
]

Smartransは、生成AIをSoftware Transformation Runtimeへ変換する試みである。

⸻

LegacyはCodeだけではない

Legacy Systemという言葉には、「古いTechnology」という印象がある。

しかしMission-Critical Systemでは、Legacy Codeの内部に数十年分のBusiness Knowledgeが埋め込まれている。

Business Rule。

Exception Handling。

Data Structure。

Interface。

Operational Constraint。

Regulatory Interpretation。

過去の改修。

一見すると不要に見える処理にも、理由が存在することがある。

したがってModernizationは、

[
Old\ Code
\rightarrow
New\ Code
]

という単純変換では成立しない。

必要なのは、

[
Legacy\ System
\rightarrow
Knowledge\ Extraction
\rightarrow
Architecture\ Transformation
\rightarrow
Behavior\ Verification
]

である。

Code Migrationとは、企業MemoryのMigrationでもある。

⸻

最大のProblemは「理解」である

大規模System Modernizationでは、新しいCodeを書くことだけが難しいのではない。

むしろ既存Systemを正しく理解することが難しい。

何百万行ものCode。

複雑なDependency。

古いDocument。

担当者の異動。

複数世代のTechnology。

Business RuleとImplementation Detailの混在。

これらによって、

Existing System
    ↓
What does it actually do?

という問いそのものが難しくなる。

生成AIの重要なCapabilityは、このUnderstanding Costを下げられる可能性にある。

⸻

CodeをKnowledgeとして読む

Smartransでは、Legacy Codeを単なる文字列として扱うのではなく、変換対象となる構造として解析する。

例えば、

Module。

Function。

Variable。

Call Relation。

Data Dependency。

External Interface。

Control Flow。

を抽出する。

Source Code
   ↓
Parsing / Analysis
   ↓
Dependency Structure
   ↓
Transformation Context

ここでAIは、Code Generationの前にCode Understandingへ使われる。

Generateより先にUnderstandがある。

これはMission-Critical Modernizationでは極めて重要である。

⸻

Any-to-Anyという考え方

Legacy Modernizationでは、一つのProgramming Languageから一つのLanguageへ移すだけとは限らない。

旧来LanguageからJavaへ。

JavaからCloud-native Architectureへ。

古いFrameworkから新しいFrameworkへ。

Database Access方式を変える。

Architecture Patternそのものを変える。

Smartransが目指す方向は、こうしたTransformationを固定的な一対一Converterではなく、生成AIを利用したAny-to-Any Conversionとして扱うことである。

[
Source\ Representation
\rightarrow
Target\ Representation
]

ただし自由なTranslationではない。

Target Requirementへ適合させる必要がある。

⸻

TranslationではなくTransformation

Programming Languageだけを置換してもModernizationにはならない。

例えば古いArchitectureをそのまま新しいLanguageへ写せば、Technical Debtを新しいTechnologyへ移しただけになる可能性がある。

そこで重要になるのが、

Syntax Conversion
       ↓
Architecture Adaptation
       ↓
Optimization
       ↓
Maintainability
       ↓
Verification

である。

2026年のSmartransでは、対象LanguageやArchitectureへのOptimization、Maintainability、Readabilityまで含めた品質Controlの強化が進められている。

これはCode TranslationからSoftware Transformationへの拡張である。

⸻

Generateだけでは危険である

生成AIはCodeを高速に生成できる。

しかしMission-Critical Systemで最も重要なのは、生成速度ではない。

正しさである。

[
Generated\ Code
\neq
Equivalent\ System
]

見た目のLogicが似ていても、Edge Caseで異なる可能性がある。

Decimal Precision。

Date Processing。

Transaction Boundary。

Exception Behavior。

Data Ordering。

Null Handling。

こうした差異がBusiness Realityを変えてしまう。

だからMigration AIでは、GenerationとVerificationを分離できない。

⸻

新旧Systemを比較する

Smartransの特徴的な考え方は、新しいCodeを生成した後に、既存Systemと結果を比較することにある。

Input Data
  ├──────────────┐
  ↓              ↓
Current System   New System
  ↓              ↓
Output A         Output B
  └──────┬───────┘
         ↓
     Compare

AとBが一致するか。

違うならなぜ違うか。

AI Agentが原因を分析する。

Codeを修正する。

再度Testする。

[
Transform
\rightarrow
Execute
\rightarrow
Compare
\rightarrow
Correct
\rightarrow
Re-execute
]

ここでAIは一回のGeneratorではなく、Verification Loopを回すAgentになる。

⸻

Test Dataも生成する

Migration Verificationでは、何をTestするかも難しい。

Normal Caseだけでは不十分である。

Boundary Value。

Rare Case。

Error Case。

Historical Exception。

Large Data。

こうしたTest Spaceを広げる必要がある。

生成AIを使えば、SpecificationやExisting CodeからTest Candidateを生成できる。

Legacy Behavior
     ↓
Test Condition Generation
     ↓
Input Dataset
     ↓
Current / New Execution
     ↓
Comparison

GenerationがVerificationを支える。

⸻

全件比較という考え方

大規模Data Processing Systemでは、Samplingだけでなく新旧結果を大量に比較できることが大きな意味を持つ。

2026年に公表されたKDDIの大規模Data System Modernization事例でも、AIによるCode Conversionだけではなく、Optimization、Verification、新旧System間の全件比較が重視されている。

ここにSmartransの核心が現れる。

AIがCodeを書くことより、AIを使ってTransformationの正しさを検証できること。

これはMission-Critical AI Engineeringの方向を示している。

⸻

Agentic Migration

このProcessをAgent単位へ分解すると、SmartransはAgentic Software Engineeringへ近づく。

Analysis Agent
     ↓
Dependency Agent
     ↓
Conversion Agent
     ↓
Test Generation Agent
     ↓
Execution Agent
     ↓
Comparison Agent
     ↓
Correction Agent

実装上は必ずしも物理的に別Agentである必要はない。

重要なのは、Migrationを複数Operationへ分解し、それぞれをAIがToolを使いながら反復できることにある。

⸻

Human Engineerは消えない

このArchitectureでも、人間の役割は残る。

Target Architectureを決める。

Business Requirementを確認する。

Transformation Ruleを承認する。

重要な差分を判断する。

Production移行を決定する。

AI Agentが大量のCodeを変換できるほど、人間はより上位のArchitectureとRiskへ集中する。

[
AI
\rightarrow
Transformation
\rightarrow
Evidence
\rightarrow
Engineer\ Review
\rightarrow
Authorized\ Migration
]

Human AuthorityをMigration Processへ残す。

⸻

Patentが意味するもの

Smartransでは、AI AgentによるCode Conversionと、新旧System間の整合性を繰り返し検証する仕組みに関して特許化も進んでいる。

ここで重要なのは特許そのものだけではない。

Research成果が、

[
Idea
\rightarrow
Algorithm
\rightarrow
Software
\rightarrow
IP
]

へ変化していることである。

AI Researchを一回のProject Knowledgeで終わらせず、再利用可能な企業Assetへ変える。

これがR&DとBusinessを接続する一つの形である。

⸻

ProjectからStandard Assetへ

さらに大きな変化は、Smartransを個別Migration Projectだけに閉じず、Planning、Development、Operation・Maintenanceまで再利用可能な標準Assetへ広げようとしている点にある。

Migration Project
     ↓
Reusable Method
     ↓
Reusable Tool
     ↓
Reusable Agent
     ↓
Standard Asset

このTransformationが成立すれば、System Integration BusinessのScale構造も変わる。

従来はProjectごとに大量のHuman Effortが必要だった。

AI Asset化によって、過去のProject Knowledgeを次のProjectへ持ち越せる。

⸻

人月からAssetへ

Software Businessでは長く、

[
Revenue
\approx
People
\times
Project\ Time
]

という構造が強かった。

しかしAIによって、

[
People
\times
Knowledge
\times
Software
\times
Reuse
]

へ拡張できる可能性がある。

人間を減らすという意味ではない。

一人のEngineerが持つKnowledgeをSoftwareへFormalizeし、複数Projectで再利用するという意味である。

Smartransはこの変化を具体的に示す。

⸻

SpecificationをMachine-readableにする

Modernizationを継続するには、CodeだけでなくSpecificationもMachine-readableにする必要がある。

Business Rule。

Data Definition。

Architecture Constraint。

Configuration。

Test Condition。

Migration Decision。

これらを構造化する。

Specification
  ├─ Requirement
  ├─ Rule
  ├─ Data
  ├─ Interface
  ├─ Constraint
  ├─ Test
  └─ Decision

すると、次のMaintenanceでAI AgentがContextとして利用できる。

Modernizationによって新しいCodeを得るだけでなく、次のAI Maintenanceに耐えるKnowledge Structureを残す。

⸻

Code Knowledge Graph

Legacy System理解をさらに発展させると、Source CodeをGraphとして扱える。

Module
├─ CALLS → Function
├─ READS → Table
├─ WRITES → Table
├─ IMPLEMENTS → Rule
├─ DEPENDS_ON → Library
└─ EXPOSES → API

ここへBusiness RequirementやIncident Historyを接続する。

すると、

[
Code
+
Business
+
Data
+
Operation
]

が一つのSoftware Knowledge Graphになる。

AI AgentはCodeだけでなく、Systemが企業の中で何を意味するのかを理解しやすくなる。

⸻

Digital Twin of Software

さらに進めれば、Migration前にSoftware SystemそのもののDigital Representationを持つことができる。

Current Architecture。

Dependency。

Data Flow。

Runtime Behavior。

Performance。

Failure History。

Change History。

これらを観測する。

Production System
      ↓
Software Twin
      ↓
Transformation Scenario
      ↓
Simulation / Test
      ↓
Migration Decision

Corporate Digital Twinの内部にSoftware Twinが存在する構造である。

⸻

SmartransとMission-Critical Runtime

Smartransは第Ⅴ部のAIだけの話ではない。

第Ⅳ部で扱ったMission-Critical Runtimeと直接つながる。

Mission-Critical Systemでは、

「新しいSystemをつくれるか」

より、

「現在動いているSystemを壊さずに変えられるか」

が重要になる。

したがって、

[
Mission\ Criticality
+
AI\ Generation
+
Verification
]

が一体化する必要がある。

Smartransは、AIによるGenerationをMission-Critical Engineeringへ接続するための一つの実装形である。

⸻

2050 Autonomous Modernization

2050年には、Software Systemが現在より継続的にModernizeされている可能性がある。

Library更新。

Security対応。

Language Migration。

Architecture変更。

Cloud変更。

Performance Optimization。

AI Agentが常時Dependencyを観測し、変更候補を生成し、Testし、Differenceを提示する。

Observe Software
     ↓
Detect Technical Debt
     ↓
Generate Transformation
     ↓
Test
     ↓
Simulate
     ↓
Human Approval
     ↓
Deploy
     ↓
Observe

完全自律Migrationを前提にする必要はない。

重要なのは、Modernizationを数年に一度の巨大Projectから、Continuous Software Evolutionへ変えられることである。

⸻

Smartransが示しているのは、生成AIの価値がCode Generationだけではないということである。

既存SystemをUnderstandする。

TransformationをDesignする。

CodeをGenerateする。

新旧SystemをCompareする。

DifferenceをDetectする。

再びGenerateする。

そして人間がMigrationをAuthorizeする。

[
\boxed{
Understand
\rightarrow
Generate
\rightarrow
Verify
\rightarrow
Correct
\rightarrow
Learn
}
]

このLoopが成立すると、AIはDeveloperを補助するToolから、Software Engineering Processそのものへ組み込まれたAgentへ変わる。

そしてSmartransだけが例外ではない。

Requirement、Design、Implementation、TestingというSoftware Development全体にも、同じTransformationが広がり始めている。

次節では、大和総研のSoftware Engineeringそのものがどのように変わるのかを見る。

AI駆動開発。
第5節　AI駆動開発

Software Developmentは、長く人間が中心となる工程だった。

Requirementを読む。

設計する。

Codeを書く。

Testする。

Reviewする。

修正する。

Deployする。

この流れに生成AIが入ると、変わるのはCoding速度だけではない。

Software Development Processそのものが再設計される。

[
\boxed{
Human\ Development
\rightarrow
Human + AI\ Development
\rightarrow
Agentic\ Software\ Engineering
}
]

大和総研でも2026年には、Coding Agentを利用し、Requirement整理、Design、Implementation、TestingまでAIを組み込むAI駆動開発が進められている。

重要なのは「AIにCodeを書かせること」ではない。

Software Engineering全体をAIと人間の協働Processへ変えることである。

⸻

Coding Agentは入口にすぎない

生成AIによるSoftware Developmentというと、Code Generationが最も分かりやすい。

自然言語で指示する。

Codeが生成される。

しかしEnterprise Systemでは、その前後に多数の工程がある。

Requirement
  ↓
Analysis
  ↓
Architecture
  ↓
Design
  ↓
Implementation
  ↓
Test
  ↓
Security Review
  ↓
Deployment
  ↓
Operation

Codingはこの一部でしかない。

本当に大きなTransformationは、このLifecycle全体へAIを配置することで起こる。

⸻

RequirementをAI-readableにする

AI駆動開発では、Requirementの品質がさらに重要になる。

曖昧なRequirementを入力すれば、AIは曖昧なSoftwareを高速に生成する。

だからRequirementを、

Actor。

Goal。

Input。

Output。

Business Rule。

Constraint。

Exception。

Acceptance Criteria。

として構造化する。

Requirement
├─ Actor
├─ Objective
├─ Rule
├─ Data
├─ Constraint
├─ Exception
└─ Acceptance Test

Requirement Documentを人間だけが読む文章から、HumanとAI Agentが共有できるSpecificationへ変える。

これがAI駆動開発の第一歩である。

⸻

Architectureは人間の役割として重要になる

AIがCodeを大量に生成できるほど、Architectureの重要性は高まる。

どのComponentへ分けるか。

どのDataをAuthoritativeにするか。

どこをAPIで接続するか。

どのActionにHuman Approvalが必要か。

Security Boundaryをどこへ置くか。

これらを誤れば、局所的に正しいCodeを大量に生成しても、全体Systemは壊れる。

[
Code\ Quality
\not\Rightarrow
Architecture\ Quality
]

したがってAI駆動開発では、人間のEngineerはCodingから解放されるだけではなく、より上位のSystem DesignとTrade-off Decisionへ移る。

⸻

Design Agent

AIはArchitecture Decisionそのものを自動確定するのではなく、設計Optionを生成するために使える。

例えば、

Monolith。

Microservices。

Event-driven。

Batch。

Streaming。

SQL。

Graph。

Vector。

Cloud-native。

複数Optionを比較する。

Requirement
  ↓
Design Agent
  ↓
Architecture Options
  ├─ A
  ├─ B
  └─ C
  ↓
Trade-off Analysis
  ↓
Human Decision

AIはDesign Spaceを広げる。

人間はBusiness、Cost、Risk、Operationを踏まえて選択する。

⸻

Implementation Agent

ImplementationではAIの効果が直接現れる。

Boilerplate Code。

API。

Database Access。

Test。

Migration Script。

Documentation。

を生成する。

しかし生成CodeはCandidateである。

正式なProduction Codeになるには、

Generated Code
     ↓
Compile
     ↓
Static Analysis
     ↓
Test
     ↓
Security Scan
     ↓
Review
     ↓
Merge

というGateを通す。

AI GenerationをSoftware Supply Chainの中へ組み込む。

⸻

Testを先に書ける

AI駆動開発の重要な方向は、Code GenerationよりTest Generationにある。

RequirementからAcceptance Testを生成する。

DesignからIntegration Testをつくる。

Existing CodeからRegression Testをつくる。

Edge Caseを探索する。

すると、

[
Requirement
\rightarrow
Test
\rightarrow
Implementation
]

という流れを強化できる。

AIがCodeを書く速度を上げるだけでなく、Verification Coverageを広げることができる。

⸻

GenerateとVerifyを競わせる

同じAIが生成したCodeを、同じContextだけで評価するとBiasが残る。

そこで役割を分離する。

Coding Agent
     ↓
Generated Code
     ↓
Testing Agent
     ↓
Security Agent
     ↓
Review Agent
     ↓
Human Engineer

一つのAgentへ全Authorityを集中させない。

複数の視点から検証する。

これはMulti-Agent ArchitectureのSoftware Engineering版である。

⸻

AIがPull Requestを作る世界

開発単位も変わる。

Issueを読む。

Repositoryを探索する。

関連Codeを特定する。

変更する。

Testする。

Documentationを更新する。

Pull Requestを生成する。

ここまでをAgentが担当できる。

Issue
 ↓
Agent Plan
 ↓
Repository Analysis
 ↓
Code Change
 ↓
Test
 ↓
Pull Request
 ↓
Human Review

人間はすべてのKey Strokeを書くのではなく、Change Setの意味とRiskをReviewする主体になる。

⸻

RepositoryがKnowledge Baseになる

AI AgentがSoftwareを変更するには、Repositoryの構造を理解できなければならない。

Codeだけでは足りない。

Architecture Decision Record。

API Specification。

Data Schema。

Business Rule。

Test。

Incident History。

Runbook。

これらを接続する。

[
Repository

Code
+
Specification
+
Test
+
Architecture
+
Operational\ Knowledge
]

Software RepositoryそのものがEnterprise Knowledge Baseへ変わる。

⸻

LegacyとNew Developmentを同じLoopへ入れる

AI駆動開発はGreenfieldだけに適用するものではない。

Existing Systemを理解する。

新しいRequirementとの差を分析する。

変更範囲を特定する。

Codeを修正する。

Regression Testする。

このLoopは前節のSmartransと連続する。

Existing System
     ↓
Understand
     ↓
Change Requirement
     ↓
Generate Modification
     ↓
Verify
     ↓
Release

Migration AIとDevelopment AIが、同じAgentic Software Engineeringへ収束する。

⸻

Security by Design

AIがCode Generationを高速化すると、Security Riskも高速に生成され得る。

したがってSecurityを最後にReviewするのでは遅い。

Dependency Scan。

Secret Detection。

Static Analysis。

Authorization Check。

Infrastructure Policy。

Threat Modeling。

をPipelineへ入れる。

Generate
 ↓
Security Checks
 ↓
Test
 ↓
Policy Gate
 ↓
Deploy

Securityを人間の注意力だけに依存させず、ArchitectureとAutomationへ埋め込む。

⸻

AI AgentにもIdentityを与える

Coding AgentがRepositoryへAccessするなら、Agent自身にもIdentityが必要である。

どのRepositoryを読めるか。

どのBranchへ書けるか。

SecretへAccessできるか。

Production Deployできるか。

を定義する。

Agent Identity
     ↓
Repository Permission
     ↓
Tool Permission
     ↓
Action
     ↓
Audit Log

AI Agentを「便利な外部Tool」として扱うのではなく、Enterprise System上のActorとして扱う。

⸻

Productionへの自動Deployを分離する

Codeを生成できることと、ProductionへDeployしてよいことは別である。

High-impact Systemでは、

[
Generate
\neq
Authorize
]

である。

AI Generates Change
      ↓
Automated Verification
      ↓
Human / Policy Approval
      ↓
Controlled Deployment
      ↓
Production

Mission-Critical Runtimeで確立したAuthority BoundaryをSoftware Developmentにも適用する。

⸻

Development Dataを学習可能なAssetにする

Software Developmentでは大量のKnowledgeが発生する。

Issue。

Requirement。

Commit。

Pull Request。

Review Comment。

Test Failure。

Incident。

Rollback。

これらをEventとして保存すれば、開発Processそのものを学習できる。

Requirement
  ↓
Commit
  ↓
Review
  ↓
Test
  ↓
Deployment
  ↓
Incident / Outcome

どの種類の変更がDefectを生みやすいか。

どのArchitectureがChange Costを下げたか。

どのAgent Outputが修正されたか。

を分析できる。

Software EngineeringがData-drivenになる。

⸻

Developer Productivityだけを目的にしない

AI駆動開発の評価を「一人あたり何行Codeを書けたか」で測るべきではない。

Code量が増えても、Maintenance Costが増えれば意味がない。

見るべきなのは、

Delivery Lead Time。

Defect Rate。

Change Failure Rate。

Recovery Time。

Security Incident。

Maintainability。

Business Outcome。

である。

[
Developer\ Speed
\rightarrow
Software\ Delivery\ Quality
\rightarrow
Business\ Value
]

AI導入をProduction Outcomeへ接続する。

⸻

人間のSkillも変わる

AI駆動開発ではEngineerの価値が消えるのではない。

必要Skillが変わる。

Code Syntaxを知る。

だけでは足りない。

RequirementをFormalizeする。

Architectureを判断する。

AI Outputを評価する。

Securityを理解する。

Test Strategyを設計する。

Business Contextを理解する。

複数AgentをOrchestrateする。

人間は実装者からEngineering Authorityへ比重を移す。

⸻

Multi-Agent Software Factory

Software Development全体をCapabilityへ分解すると、次のArchitectureが見える。

Orchestrator
  ├─ Requirement Agent
  ├─ Architecture Agent
  ├─ Coding Agent
  ├─ Testing Agent
  ├─ Security Agent
  ├─ Migration Agent
  ├─ Documentation Agent
  └─ Operations Agent

これらがRepository、CI/CD、Test Environment、Knowledge BaseをToolとして利用する。

人間はArchitecture、Priority、Risk、Approvalを担う。

これがAgentic Software Engineeringの基本形になる。

⸻

Software DevelopmentからSoftware Runtimeへ

AI駆動開発が進むと、DevelopmentとOperationの境界も薄くなる。

ProductionでErrorをDetectする。

Operations Agentが原因を分析する。

Coding Agentが修正Candidateをつくる。

Test AgentがVerificationする。

人間が承認する。

Releaseする。

Production Event
     ↓
Diagnose
     ↓
Generate Fix
     ↓
Verify
     ↓
Approve
     ↓
Deploy
     ↓
Observe

DevOpsが、AIによってContinuous Learning Runtimeへ拡張する。

⸻

2050 Continuous Software Engineering

2050年から逆算すると、Softwareは「完成して長期間使うもの」から、継続的に再構成されるものへさらに近づく。

Business Ruleが変わる。

Regulationが変わる。

Security Riskが変わる。

AgentがRequirement Changeを検出する。

変更案を生成する。

Simulationする。

Testする。

Human Authorityを通してDeployする。

[
\boxed{
Observe
\rightarrow
Understand
\rightarrow
Generate
\rightarrow
Verify
\rightarrow
Authorize
\rightarrow
Deploy
\rightarrow
Learn
}
]

Software DevelopmentそのものがRuntimeになる。

⸻

大和総研にとってAI駆動開発の意味は、EngineerをAIへ置き換えることではない。

Research、Consulting、金融、Enterprise、HealthTechで蓄積したDomain Knowledgeを、より速くSoftwareへ変換できるようにすることである。

[
Knowledge
\rightarrow
Requirement
\rightarrow
AI\ Assisted\ Engineering
\rightarrow
Verified\ Software
\rightarrow
Production
]

SmartransがLegacy TransformationをAgent化するなら、AI駆動開発はSoftware Lifecycle全体をAgent化する。

しかしAgentがRequirementを読み、Codeを書き、Toolを使い、Productionへ近づくほど、次の問いが避けられなくなる。

誰がAIのActionを許可し、何をTrustの根拠とするのか。

次節では、AIを企業能力へ変えるための制御Architectureを扱う。

AI Governance。
第6節　AI Governance

AIが分析するだけなら、誤りは分析上のRiskとして管理できる。

AIが文章を生成する。

Codeを書く。

Customerへ回答する。

Toolを呼び出す。

Systemを変更する。

Business Processを実行する。

AIがRealityへ近づくほど、Governanceの意味は変わる。

GovernanceはAI利用を抑制するための外部規則ではない。

AIを安全にProductionへ接続するためのArchitectureである。

[
\boxed{
AI\ Capability
+
AI\ Governance

Deployable\ Enterprise\ Intelligence
}
]

AIのCapabilityだけを高めても、企業能力にはならない。

Trustworthyに使える範囲を同時に広げる必要がある。

⸻

PrincipleからRuntimeへ

大和総研はAI倫理ガイドラインを策定し、AI倫理委員会を設置している。

その原則には、社会・経済への貢献、人間中心、TransparencyとAccountability、適切な利用と人材育成、法令・Privacy、SecurityとMonitoring、Governanceなどが含まれる。

これらはAI利用の上位原則である。

しかしEnterprise AIでは、Principleを掲げるだけでは足りない。

[
Principle
\rightarrow
Policy
\rightarrow
Architecture
\rightarrow
Control
\rightarrow
Runtime
\rightarrow
Audit
]

まで翻訳する必要がある。

AI GovernanceをDocumentからExecutable Systemへ変える。

⸻

AI Inventory

最初に必要なのは、企業の中で何のAIが動いているかを知ることである。

Model。

Agent。

AI Application。

External AI Service。

Dataset。

Knowledge Base。

Tool。

それらをInventoryとして管理する。

AI Asset
├─ Owner
├─ Purpose
├─ Model
├─ Version
├─ Data
├─ Knowledge Source
├─ Tools
├─ Risk Class
└─ Deployment State

管理対象が見えなければGovernanceは成立しない。

⸻

Risk-based Governance

すべてのAIへ同じControlを適用する必要はない。

社内文章の要約と、大規模な金融Transactionに関係するAgentではRiskが違う。

そこで、

[
Risk

Impact
\times
Likelihood
\times
Irreversibility
]

という考え方でControl Levelを変える。

例えば、

Low Impact
 → Automated Use
Medium Impact
 → Monitoring / Review
High Impact
 → Human Approval
Critical
 → Strict Authorization / Dual Control

AIの自律性をModel性能だけで決めない。

Actionの影響と可逆性によって決める。

⸻

Human-centeredをArchitectureにする

「人間中心」という原則を実装するなら、人間を単に最後の画面へ置くだけでは足りない。

誰がDecision Authorityを持つのか。

どの段階で介入できるのか。

AI Recommendationを拒否できるのか。

Actionを停止できるのか。

Rollbackできるのか。

を設計する。

AI
↓
Evidence
↓
Recommendation
↓
Human Decision
↓
Authorized Execution
↓
Outcome

Human-in-the-loopをUI上のButtonではなく、Authority Architectureとして定義する。

⸻

AI OutputとFactを分離する

生成AIは、もっともらしいOutputを生成できる。

したがって、

[
Generated
\neq
Authoritative
]

をSystem Levelで維持する。

Dataを、

Observed。

Authoritative。

Derived。

Predicted。

Simulated。

Generated。

へ分類する。

AIが生成したExplanationが、正式なAccounting RecordやCustomer Recordを自動的に上書きしてはならない。

Intelligence LayerとAuthoritative Stateを分離する。

⸻

Grounding

AI Governanceの重要な技術要素がGroundingである。

企業AIを一般Modelの内部Knowledgeだけに依存させない。

User Request
    ↓
Authorization
    ↓
Retrieve
    ├─ Authoritative Data
    ├─ Knowledge Graph
    └─ Approved Documents
    ↓
Model
    ↓
Grounded Output

どのSourceを利用したかを記録する。

SourceのAuthorityとVersionも管理する。

これによってAI OutputをEvidenceへ戻せる。

⸻

Hallucinationをゼロと仮定しない

生成AIの誤りを完全になくすことをArchitectureの前提にしてはならない。

必要なのは、

[
AI\ Can\ Fail
]

を前提にSystemを設計することである。

Source Citation。

Confidence。

Rule Validation。

Cross-check。

Human Review。

Tool Result Verification。

などを組み合わせる。

これはMission-Critical Runtimeで、

[
System\ Can\ Fail
]

を前提にRecoveryを設計したことと同じである。

⸻

Model Governance

ModelにはLifecycleがある。

Develop
 ↓
Evaluate
 ↓
Approve
 ↓
Deploy
 ↓
Monitor
 ↓
Update
 ↓
Retire

どのModelを使っているか。

どのVersionか。

どのEvaluationを通過したか。

誰がApproveしたか。

いつ更新されたか。

を記録する。

ModelをSoftware Componentと同じようにConfiguration-managed Assetとして扱う。

⸻

Data Governance

AIの品質はModelだけでは決まらない。

DataのSource。

Quality。

Freshness。

Permission。

Purpose。

Lineage。

が重要になる。

特にPersonal DataやHealth Dataでは、

Data
↓
Consent
↓
Purpose
↓
Access Policy
↓
Processing
↓
Retention / Deletion

まで設計する。

Consentを一度取得したDocumentとして扱うのではなく、Machine-readableなPolicyへ変える。

⸻

Agent Governance

AI AgentがToolを利用するようになると、新しいGovernance Layerが必要になる。

AgentにはIdentityを与える。

Authorityを定義する。

利用可能なToolを限定する。

Action Limitを設定する。

Agent
├─ Identity
├─ Principal
├─ Purpose
├─ Permission
├─ Tool Allowlist
├─ Resource Limit
└─ Approval Policy

Agentが「考えたから実行できる」のではない。

System側がAuthorityを検証して初めてActionできる。

⸻

Delegated Authority

Agentは多くの場合、人間やOrganizationの代理として動く。

そこで、

[
Principal
\rightarrow
Delegated\ Authority
\rightarrow
Agent
]

を明示する。

誰の代理か。

何の目的か。

どこまで許可されているか。

いつまで有効か。

をTokenやPolicyとして持たせる。

AI Agent時代のIdentity Managementは、人間だけを管理するIAMからHuman + Machine Authority Managementへ拡張する。

⸻

Tool Useを制御する

LLMが回答するだけなら、主なRiskはInformationである。

AgentがToolを使えばPhysicalまたはDigital Realityを変更できる。

Email送信。

Database更新。

Code変更。

Cloud Resource作成。

Financial Action。

そこでTool Callの前にPolicy Enforcement Pointを置く。

Agent Request
    ↓
Identity Check
    ↓
Policy Check
    ↓
Risk Evaluation
    ↓
Approval
    ↓
Tool Execution

ReasoningとExecutionの間にGovernance Boundaryを置く。

⸻

ProbabilisticとDeterministicを分離する

AIはProbabilisticである。

正式なTransactionやState UpdateにはDeterministicなControlが必要な領域がある。

したがって、

Probabilistic Layer
AI / Agent / Recommendation
         ↓
Governance Boundary
         ↓
Deterministic Layer
Rule / Transaction / State Change

と分離する。

これは金融だけでなく、企業System、HealthTech、Software Deploymentにも共通する。

⸻

AI Software Supply Chain

AI駆動開発では、Governance対象がModelからCodeへ広がる。

どのAgentがCodeを生成したか。

どのModel Versionだったか。

どのDependencyを追加したか。

どのTestを通過したか。

誰がReviewしたか。

を追跡する。

[
Requirement
\rightarrow
Agent
\rightarrow
Code
\rightarrow
Test
\rightarrow
Approval
\rightarrow
Deployment
]

Software Supply ChainとAI Governanceが一体化する。

⸻

PromptとAgentもVersion管理する

Enterprise AIではModel Versionだけを記録しても再現できない。

Prompt。

System Instruction。

Retrieval Configuration。

Knowledge Base。

Agent Workflow。

Tool Definition。

Policy。

がOutputを変える。

したがって、

Runtime Version
=
Model
+ Prompt
+ Knowledge
+ Agent
+ Tool
+ Policy

として管理する。

AI Runtime全体をVersionableにする。

⸻

Monitoring

Production AIはDeployして終わらない。

Accuracy。

Latency。

Cost。

Error。

Hallucination。

Retrieval Quality。

Model Drift。

Agent Failure。

Unauthorized Tool Attempt。

Human Override。

を観測する。

AI Runtime
   ↓
Telemetry
   ↓
Evaluation
   ↓
Alert
   ↓
Human / Automated Response

AI Governanceは事前審査だけではない。

Continuous Monitoringである。

⸻

Decision Lineage

AIがDecision Processへ入るほど、結果だけでなく過程のEvidenceを残す必要がある。

Evidence
  ↓
Model / Agent
  ↓
Recommendation
  ↓
Human Approval
  ↓
Action
  ↓
Outcome

Source。

Version。

Authority。

Action。

Approval。

Outcome。

を接続する。

これをDecision Lineageとして保持する。

内部推論を無制限に保存するのではない。

Decisionを検証するために必要なEvidenceを残す。

⸻

IncidentとRollback

AIにもIncident Responseが必要である。

Modelの異常。

Data Problem。

Knowledge Baseの誤更新。

Prompt Injection。

Unauthorized Tool Use。

Agent Loop。

Cost Explosion。

問題を検知したら、

Detect
↓
Contain
↓
Disable
↓
Rollback
↓
Investigate
↓
Recover
↓
Learn

へ進む。

TrustとはFailureが起きないことではない。

Failureから制御可能に回復できることである。

⸻

Governanceを開発速度の敵にしない

GovernanceがすべてManual Approvalになれば、AI導入速度は低下する。

だからControlもSoftware化する。

Policy as Code。

Automated Evaluation。

Automated Security Check。

Model Registry。

Audit Logging。

Risk-based Approval。

を使う。

[
Governance
\rightarrow
Executable\ Governance
]

とする。

安全性とSpeedを対立させず、Standardized Controlによって両方を高める。

⸻

AI EthicsからAI Engineeringへ

AI Ethicsは不要になるのではない。

むしろEngineeringへ翻訳される。

Human-centered
→ Human Authority
Transparency
→ Provenance / Traceability
Privacy
→ Consent / Access Control
Security
→ Identity / Policy / Monitoring
Accountability
→ Audit / Decision Lineage
Safety
→ Evaluation / Rollback

PrincipleがArchitectureになる。

ArchitectureがCodeになる。

CodeがRuntimeになる。

ここまで到達して初めてGovernanceが実行される。

⸻

大和総研の構造的条件

大和総研には、AI Governanceを抽象論だけで終わらせにくい条件がある。

金融System。

企業System。

HealthTech。

Cloud Infrastructure。

AI Research。

Software Development。

Production Operation。

これらが一つの企業Capabilityとして存在する。

AI倫理ガイドラインというPrincipleと、Mission-Critical RuntimeというEngineeringを接続できる。

[
AI\ Principle
+
Production\ Engineering
\rightarrow
Trusted\ AI\ Runtime
]

ここが重要である。

⸻

2050 AI Governance

2050年には、一つの人間が一つのAIを使うだけではなく、多数のAgentが相互に仕事をする可能性がある。

Human
 ↓
Personal / Enterprise Agent
 ↓
Specialist Agents
 ↓
External Agents
 ↓
Enterprise Systems

この世界では、すべてのActionを人間が一件ずつ確認することはできない。

だからHuman AuthorityとFull Manual Controlを区別する。

人間が、

Policy。

Authority。

Risk Boundary。

Objective。

を定義し、その範囲内でAgentが動く。

High-impact Actionだけを人間へEscalateする。

[
Human\ Authority
\neq
Human\ Micromanagement
]

である。

⸻

2050 Agentic Enterpriseに必要なのは、最も自律的なAIではない。

最も制御可能な自律性である。

誰が。

何の目的で。

どのDataを使い。

どのModelで。

どのAuthorityによって。

何を実行し。

Realityをどう変え。

結果がどうなったか。

を追跡できる。

[
\boxed{
Identity
+
Authority
+
Evidence
+
Control
+
Audit
+
Recovery
+
Human\ Authority
}
]

これがAI GovernanceのRuntime Architectureである。

大和総研のAIは、PredictからGenerateへ、GenerateからAgentへ進んできた。

次に問われるのは、そのAgentが企業の一部として継続的に働くとき、Organizationそのものがどう変わるかである。

Research Agent。

Consulting Agent。

Development Agent。

Operations Agent。

複数のAIが、人間、Data、Systemと協働する。

第5章の最後では、その2050年のRequirement Spaceから2026年の大和総研を逆に見る。

2050 Agentic Enterprise。
第7節　2050 Agentic Enterprise

2050年のAI Modelを予測する必要はない。

現在のLLMが残っているかもしれない。

まったく異なるArchitectureへ移行しているかもしれない。

ComputeもInterfaceも変わる。

しかし、企業に必要となるCapabilityは逆算できる。

観測する。

理解する。

生成する。

Simulationする。

実行する。

検証する。

学習する。

この一連のOperationを、人間と複数のAI Agentが継続的に実行する企業。

本書では、そのArchitectureを、

[
\boxed{
2050\ Agentic\ Enterprise
}
]

と呼ぶ。

これは「AIが会社を経営する」という予測ではない。

2050年の企業環境から2026年のArchitecture Requirementを導くFuture Pullである。

⸻

SoftwareからActorへ

従来のEnterprise Softwareは、人間が操作するToolとして設計されてきた。

Human
 ↓
Application
 ↓
Database

Agentic Enterpriseでは、この関係が変わる。

AIがContextを読み、Goalを受け取り、必要なKnowledgeを取得し、Toolを選び、Action Candidateを生成する。

Human
 ↕
AI Agent
 ↕
Knowledge / Data
 ↕
Enterprise Systems

Softwareは受動的なInterfaceだけではなくなる。

企業Systemの内部に、限定されたAuthorityを持つMachine Actorが加わる。

⸻

一つの巨大AIではない

企業全体を一つのAIへ任せるArchitectureは現実的ではない。

Research。

Consulting。

Finance。

Software Development。

HealthTech。

Security。

Operations。

それぞれKnowledge、Risk、Authorityが違う。

したがって2050 Agentic Enterpriseは、専門Capabilityを持つ複数AgentのNetworkとして考える。

Enterprise Orchestrator
├─ Research Agent
├─ Economic Simulation Agent
├─ Consulting Agent
├─ Financial Agent
├─ Development Agent
├─ Migration Agent
├─ Security Agent
├─ HealthTech Agent
└─ Operations Agent

重要なのはAgent数ではない。

Capabilityの分離とAuthorityの分離である。

⸻

Research Agent

Research Agentは大量のDataとDocumentを継続的に観測する。

Economic Indicator。

Market Data。

Policy。

Regulation。

Corporate Disclosure。

Technology。

Global Event。

変化をDetectし、Knowledge Graphを更新し、ResearcherへEvidenceを提示する。

Observe
 ↓
Detect Change
 ↓
Retrieve Context
 ↓
Analyze
 ↓
Generate Hypothesis
 ↓
Researcher Verification

Researchは定期Reportの作成だけから、Continuous Observationへ拡張する。

⸻

Economic Simulation Agent

Research AgentがRealityを観測するだけではない。

Scenarioを生成する。

Interest Rateが変わったらどうなるか。

Inflation Expectationが変化したらどうなるか。

Household Behaviorが変わったらどうなるか。

約2,500人のPersonaを用いた2026年の生成AI Agent Simulationは、この方向への初期的な実証として読むことができる。

将来Architectureでは、

[
Micro\ Agents
\rightarrow
Interaction
\rightarrow
Macro\ State
]

をSimulationし、Observed Realityとの差を継続的に検証する。

⸻

Consulting Agent

Consulting AgentはAnswerを決めるAIではない。

Decision Spaceを構造化する。

Enterprise State
     ↓
Decision Question
     ↓
Option Generation
     ↓
Simulation
     ↓
Trade-off
     ↓
Recommendation
     ↓
Human Decision

Capital Allocation。

M&A。

Governance。

Human Capital。

Business Transformation。

複数のPossible Stateを比較する。

Consultantは資料作成者から、Question、Model、Trade-off、Decisionを設計する主体へ比重を移す。

⸻

Development Agent

DecisionがSystem Changeを必要とすれば、Development Agentへ接続する。

Requirementを読む。

Repositoryを解析する。

Codeを生成する。

Testする。

Pull Requestを作る。

しかしProductionへのAuthorityは別にする。

Requirement
  ↓
Development Agent
  ↓
Code / Test
  ↓
Verification
  ↓
Human Approval
  ↓
Deployment

AI駆動開発が企業Runtimeの一部になる。

⸻

Migration Agent

既存Systemも継続的に変わる。

Dependency。

Security Risk。

Technical Debt。

Technology Lifecycle。

を観測する。

Smartransで見た、

[
Understand
\rightarrow
Transform
\rightarrow
Verify
]

をContinuousに回す。

Software Modernizationは数年に一度の巨大Projectから、継続的なSoftware Evolutionへ近づく。

⸻

Operations Agent

ProductionではOperations AgentがSystem Stateを観測する。

Latency。

Error。

Transaction。

Security Event。

Infrastructure。

AI Behavior。

異常をDetectすると、原因Candidateを生成する。

Production
  ↓
Observe
  ↓
Detect
  ↓
Diagnose
  ↓
Recommend Recovery
  ↓
Authorize
  ↓
Recover

High-impact RecoveryにはHuman Approvalを残す。

AIがOperationsを完全に置き換えるのではなく、Recoveryまでの時間を短縮する。

⸻

Agent同士が仕事を渡す

Agentic Enterpriseの特徴は、一つのAgentの能力ではない。

Agent間のWorkflowである。

例えばPolicy Changeが起きたとする。

Policy Event
   ↓
Research Agent
   ↓
Impact Analysis
   ↓
Consulting Agent
   ↓
Business Requirement
   ↓
Development Agent
   ↓
System Change
   ↓
Testing Agent
   ↓
Human Approval
   ↓
Production

これは大和総研がすでに人間中心で持っている、

[
Policy
\rightarrow
Research
\rightarrow
Requirement
\rightarrow
System
\rightarrow
Reality
]

というCapabilityをMachine-readableにすることでもある。

⸻

Agent間通信には意味が必要になる

複数Agentを接続しても、同じ言葉を異なる意味で使えば協働できない。

Customerとは誰か。

Companyとは何か。

Policyとは何か。

Accountとは何か。

Systemとは何か。

同じEntityを共有する必要がある。

したがってAgentic Enterpriseの下には、

Enterprise Ontology

が必要になる。

Person
Organization
Company
Economy
Market
Policy
System
Data
Event
Time

第Ⅵ部で構築するReality OntologyとKnowledge Graphは、Agent間の共通言語になる。

⸻

Shared Memory

AgentにはMemoryも必要になる。

しかし、すべてをVector Databaseへ保存すればよいわけではない。

正式なStateはSQL。

RelationはGraph。

Semantic KnowledgeはVector。

大量DocumentはObject Storage。

EventはEvent Store。

Authoritative Memory → SQL
Relational Memory    → Graph
Semantic Memory      → Vector
Document Memory      → Object
Temporal Memory      → Event

Memoryを目的別に分離する。

Agentが「覚えていること」と企業が「正式に知っていること」を混同しない。

⸻

Enterprise State

Agentが仕事をするには、現在の企業Stateを理解する必要がある。

しかし企業のRealityは一つのDatabaseにはない。

Finance。

Customer。

Human Capital。

System。

Project。

Contract。

Risk。

External Economy。

これらをRelationとして接続する。

[
Enterprise\ State_t

f(
Finance,
Customer,
People,
System,
Risk,
External\ Reality
)
]

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

⸻

Event-driven Agentic Enterprise

Agentを常時動かすために、人間が毎回Promptを入力する必要はない。

EventをTriggerにできる。

Market Change。

Policy Change。

Cyber Incident。

Customer Event。

System Failure。

Data Update。

Event
↓
Relevant Agent
↓
Interpret
↓
Action Candidate
↓
Policy
↓
Execution / Escalation

企業はPrompt-drivenからEvent-drivenへ拡張する。

⸻

Agentに無制限のAuthorityを与えない

Agentic Enterpriseで最も重要なのは、自律性の最大化ではない。

Authority Boundaryである。

Agentごとに、

Identity。

Principal。

Purpose。

Permission。

Allowed Tool。

Resource Limit。

Approval Requirement。

を定義する。

[
Agent
+
Unlimited\ Authority

Uncontrolled\ Risk
]

だから、

[
Agent
+
Bounded\ Authority
+
Audit

Deployable\ Autonomy
]

とする。

⸻

Human AuthorityとMachine Autonomy

人間がすべてのAgent Actionを一件ずつ承認すればScaleしない。

逆にすべてを自動化すればGovernanceを失う。

そこでActionをRiskで分類する。

Observe
  → Autonomous
Analyze
  → Autonomous
Draft
  → Autonomous
Recommend
  → Autonomous
Low-risk Execute
  → Policy-authorized
High-impact Execute
  → Human-authorized

人間はMicromanagementするのではない。

Objective、Policy、Authority、Exceptionを管理する。

[
\boxed{
Human\ Authority
\neq
Human\ Micromanagement
}
]

である。

⸻

Agentを評価する

EmployeeにはPerformance Evaluationがある。

SoftwareにはTestがある。

Agentにも継続的Evaluationが必要になる。

Accuracy。

Task Completion。

Tool Selection。

Policy Compliance。

Cost。

Latency。

Error。

Human Override Rate。

Business Outcome。

を観測する。

Agent Action
   ↓
Outcome
   ↓
Evaluation
   ↓
Feedback
   ↓
Policy / Model / Workflow Update

AgentをDeployして終わりにしない。

⸻

Agent EconomyではなくEnterprise Governance

Agent同士が直接Serviceを利用し、Transactionする世界も考えられる。

しかし企業では自由なAgent Economyをそのまま導入する必要はない。

Budget。

Procurement Rule。

Contract。

Identity。

Accounting。

Authorization。

を維持する。

AI AgentがCloud Resourceを購入する場合でも、そのActionは企業のFinancial Controlへ接続される。

Machine ActionもCorporate Governanceの外には出ない。

⸻

Organization ChartからCapability Graphへ

Agentic EnterpriseではOrganizationの見方も変わる。

従来は、

Division
 ↓
Department
 ↓
Team
 ↓
Person

だった。

これに、

Capability
├─ Human
├─ Agent
├─ Data
├─ System
└─ Policy

というGraphが重なる。

同じCapabilityを複数部門、人間、Agentが共有する。

Organization Chartだけでは企業の実行能力を表現できなくなる。

⸻

大和総研をCapability Graphとして見る

2026年の大和総研をこの視点で見ると、

調査本部。

コンサルティング本部。

金融システム事業本部。

企業システム事業本部。

ヘルステック本部。

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

フロンティア研究開発センター。

は単なる組織単位ではなく、異なるCapability Nodeとして読める。

Observe
 → Research
Decide
 → Consulting
Implement
 → System
Operate
 → Infrastructure
Experiment
 → Frontier R&D
Augment
 → AI
Govern
 → Management / Human Authority

2050 Future Pullで必要なのは、これらを一つの巨大部門へ統合することではない。

Capability間をMachine-readableに接続することである。

⸻

2026年のGap

そのためには現在の企業KnowledgeをAgentが利用できる形へ変える必要がある。

Documentだけでは足りない。

Dataだけでも足りない。

必要なのは、

Ontology
+
Authoritative Data
+
Knowledge Graph
+
Vector Knowledge
+
Event History
+
API / Tools
+
Identity
+
Policy

である。

ここに2026年から2050年へ向かうArchitecture Gapがある。

⸻

2050から2026年へ

Future Pullすると、次のRequirementが残る。

Continuous Observation。

Machine-readable Knowledge。

Simulation。

Agent Interoperability。

Authoritative State。

Identity。

Bounded Authority。

Human Approval。

Auditability。

Recoverability。

Continuous Learning。

これらは特定の2050 Technologyへ依存しない。

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

として現在へ戻すことができる。

⸻

大和総研の可能性

大和総研には、Agentic Enterpriseを考えるうえで特徴的なCapabilityの連鎖がすでに存在する。

Researchが社会と経済を観測する。

ConsultingがDecisionへ翻訳する。

SystemがSoftwareへ変える。

Mission-Critical RuntimeがProductionで動かす。

Frontier R&DがAIを研究する。

SmartransがTransformationをSoftware Assetへ変える。

AI GovernanceがAuthority Boundaryをつくる。

これらを接続すると、

[
\boxed{
Observe
\rightarrow
Understand
\rightarrow
Simulate
\rightarrow
Decide
\rightarrow
Implement
\rightarrow
Operate
\rightarrow
Verify
\rightarrow
Learn
}
]

という一つのEnterprise Loopが現れる。

⸻

AIが企業能力になるとは、AIを全社員へ配布することではない。

AI Departmentを大きくすることでもない。

Modelを大量に保有することでもない。

企業が持つKnowledge、Decision、Software、Operationを、人間とAI Agentが共有できるArchitectureへ変えることである。

そのためには、AIの次にDataとRealityを設計しなければならない。

Agentは何をPersonとして認識するのか。

Companyとは何か。

Marketとは何か。

Policyとは何か。

どのDataがAuthoritativeなのか。

Entity同士はどうRelationしているのか。

時間とEventをどう保持するのか。

これらが定義されなければ、Agentは企業のRealityを理解できない。

したがって第Ⅴ部の到達点は、AIではない。

AIが動くためのMachine-readable Realityである。

次の第Ⅵ部では、大和総研が観測し、分析し、実装してきた地球・世界・日本・企業・System・Data・人を、一つのArchitectureへ翻訳する。

[
\boxed{
AI
\rightarrow
Architecture
\rightarrow
Digital\ Twin
}
]

第Ⅵ部　Architecture――大和総研 Digital Twin。

愛と敬意を込めてmandala