『大和総研』――1953年から2050年へ、リサーチ・コンサルティング・金融システム・企業システム・ヘルステック・AIを接続する次世代AI完全実装コード大全（第4回）（第Ⅲ部　Consulting 第3章　知を意思決定へ変える――企業価値・資本・Governance・Human Capitalを実装する）

第Ⅲ部　Consulting

Researchは、Realityを観測し、DataをEvidenceへ変え、Economic Intelligenceを形成する。

しかし、Knowledgeが生成されただけでは企業は変わらない。

経営にはDecisionが必要になる。

どこへCapitalを配分するのか。

どのBusinessを伸ばすのか。

どのBusinessから撤退するのか。

Governanceをどう設計するのか。

Human Capitalへ何を投資するのか。

M&Aを実行するのか。

Corporate Structureをどう組み替えるのか。

Technologyをどこへ導入するのか。

Researchが、

Reality → Knowledge

を担うなら、Consultingは、

Knowledge → Decision

を担う。

本書ではConsultingを、Adviceを提供するBusinessとしてだけ捉えない。

企業が持つ複雑なRealityを記述し、複数の選択肢を設計し、EvidenceとScenarioを比較しながら、実行可能なDecisionへ翻訳するOperationとして捉える。

⸻

大和総研のConsultingには、資本市場との接点がある。

経営Vision。

中期経営計画。

財務・資本政策。

Governance。

Sustainability。

Human Capital Management。

株主Engagement。

M&A。

企業・株式価値評価。

組織再編。

これらは独立したThemeではない。

中心にあるのは、

Corporate Valueをどのように持続的に形成するか

という問いである。

企業価値は一つのFinancial Indicatorだけでは決まらない。

Strategy。

Capital。

Business Portfolio。

Governance。

People。

Technology。

Risk。

Stakeholder。

Time。

それらのRelationから形成される。

したがってConsultingも、個別課題への助言から、企業全体のRelationを扱うArchitectureへ拡張して考える必要がある。

⸻

ResearchとConsultingの境界も固定的ではない。

Researchが外部環境を観測する。

Consultingが企業内部を観測する。

Market Environment。

Industry Structure。

Policy。

Technology。

Competitor。

Company Strategy。

Financial State。

Organization。

Human Capital。

これらを接続すると、

External Reality × Internal Reality

からDecisionを設計できる。

例えば金利環境が変わる。

資本Costが変わる。

企業価値評価が変わる。

Capital Allocationの条件が変化する。

それがM&A、Investment、Shareholder Return、Business Portfolioへ接続する。

Researchが生成したKnowledgeは、ConsultingによってEnterprise Decisionへ翻訳される。

⸻

しかし、2026年以降のConsultingには新しいRequirementが生じている。

企業のStateが変化する速度が速くなっているからである。

年に一度のStrategy Reviewだけでは足りない。

Marketが変わる。

Technologyが変わる。

Regulationが変わる。

Human Capitalが変化する。

Cyber Riskが変わる。

AIによってBusiness Modelそのものが再設計される。

この環境では、

Point-in-time Consulting

から、

Continuous Decision Support

への拡張が必要になる。

これはConsultantをSoftwareへ置き換えることではない。

Consulting KnowledgeをData、Model、Simulation、AI Agentへ接続し、人間の意思決定を継続的に支援できるようにすることである。

⸻

その中心に置くのがCorporate Digital Twinである。

ただし、企業を完全に複製するという意味ではない。

Strategy。

Business。

Capital。

Organization。

People。

Asset。

Risk。

System。

Data。

Event。

をMachine-readableなRelationとして記述し、現在StateとPossible Stateを比較できるようにする。

例えば、

Company
├─ Strategy
├─ Business Portfolio
├─ Capital
├─ Governance
├─ Human Capital
├─ Technology
├─ Risk
└─ Performance

という構造を持つ。

そこへExternal Realityを接続する。

Economy
Market
Policy
Industry
Technology
      ↓
   Company

するとConsultingは、静的な企業分析ではなく、

External Change → Company Exposure → Scenario → Decision

を扱うSystemへ変わる。

⸻

AIもこの領域へ入る。

Corporate Disclosureを読む。

Financial Dataを分析する。

Peer Companyを比較する。

Governance Structureを整理する。

Human Capital Dataを解析する。

M&A Candidateを探索する。

Scenarioを生成する。

Board MeetingのためのEvidence Packageを準備する。

AI Consultant Agentは、Consultantの一部Taskを高速化できる。

しかし企業経営には価値判断がある。

GrowthとStability。

Short TermとLong Term。

ShareholderとEmployee。

InvestmentとReturn。

RiskとOpportunity。

これらに単一のObjective Functionは存在しない。

したがって本書のConsulting Architectureでも、

AI → Evidence → Scenario → Recommendation → Human Decision

を維持する。

AIはDecisionを代行するのではなく、Decision Spaceを広げる。

⸻

第Ⅲ部では、大和総研の実際のコンサルティング能力を起点に、企業意思決定をMachine-readableなArchitectureへ翻訳していく。

コンサルティング本部から始める。

企業価値をRelationとして記述する。

GovernanceをSystemとして捉える。

Human CapitalをDataへ接続する。

Corporate Digital Twinを構築する。

AI Consultant Agentを設計する。

そして2050年から、Decision Intelligenceに必要なCapabilityを逆算する。

生成軸は、

[
\boxed{
Knowledge
\rightarrow
Scenario
\rightarrow
Option
\rightarrow
Decision
\rightarrow
Implementation
}
]

である。

Researchが「何が起きているのか」を問うなら、

Consultingが問うのは、

「それを踏まえて、何を選ぶのか」

である。

そして、そのDecisionが本当にRealityを変えるためには、次のSystemへ接続されなければならない。

第Ⅲ部は、KnowledgeとImplementationの間に存在する、

Decision Architecture

を記述する。
第3章　知を意思決定へ変える

――企業価値・資本・Governance・Human Capitalを実装する

第1節　コンサルティング本部

大和総研のコンサルティング本部は、ResearchとSystemの間に位置する。

ただし、それは単なる組織図上の中間という意味ではない。

Researchによって得られた外部環境のKnowledgeと、企業が内部に持つStrategy、Capital、Organization、People、Dataを接続し、

「何を選択するのか」

を設計する場所である。

ResearchがRealityをKnowledgeへ変換するなら、ConsultingはKnowledgeをDecisionへ変換する。

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

この第二の変換が、コンサルティング本部の本質である。

⸻

Consultingを助言業としてだけ見ない

Consultingという言葉からは、経営者へAdviceを提示する仕事が想像されやすい。

しかし実際の企業意思決定はもっと複雑である。

現在Stateを把握する。

外部環境を分析する。

経営課題を定義する。

複数のOptionを設計する。

Financial Impactを計算する。

Riskを評価する。

Stakeholderへの影響を見る。

Implementation Requirementを整理する。

そのうえで経営者がDecisionする。

したがってConsultingは、

Observe
  ↓
Diagnose
  ↓
Design
  ↓
Compare
  ↓
Recommend
  ↓
Decide
  ↓
Implement

というDecision Processを支援するOperationとして理解できる。

Consultantが価値を持つのは「答えを知っている」からではない。

複雑な企業Realityを、意思決定可能なStructureへ変換するCapabilityを持つからである。

⸻

大和総研のConsulting領域

2026年の大和総研が公表するConsulting Serviceは、企業経営の複数Layerへ広がっている。

Management Policyでは、

経営Vision。

中期経営計画。

経営改革・業務改革。

Governance Strategy。

Financial Strategyでは、

財務・資本政策。

株主Engagement。

IR・SR。

M&A。

企業・株式価値評価。

組織再編。

Non-financial Strategyでは、

Governance。

Sustainability。

Human Capital Management。

Data Analysis。

さらにGlobal領域やResearchと接続する。

一見すると異なるServiceの集合に見える。

しかし、その中心には一つの問いがある。

企業は限られたResourceをどのように配置し、将来のCorporate Valueへ変換するのか。

⸻

Capital Marketから企業を見る

大和総研のConsultingを理解するうえで重要なのが、Capital Marketとの接続である。

企業はProductやServiceを提供するBusiness Entityであると同時に、Capitalを調達し、投資し、Returnを生み出すEconomic Entityでもある。

したがって、

Strategy

と

Capital

を分離することはできない。

新規Businessへ投資する。

M&Aを行う。

Non-core Businessを売却する。

Share Buybackを実施する。

Dividend Policyを変更する。

Holding Companyへ移行する。

これらはすべて、

Capital Allocation

の問題でもある。

Consultingは、

Strategy
  ↓
Business Portfolio
  ↓
Capital Allocation
  ↓
Investment / M&A / Return
  ↓
Corporate Value

というRelationを扱う。

この視点によって、経営StrategyとFinancial Strategyが接続される。

⸻

企業価値を一つの数字へ圧縮しない

Corporate ValueはValuationによって数値化できる。

しかし企業そのものを一つのValuation Numberへ圧縮することはできない。

将来Cash Flow。

Cost of Capital。

Growth。

Business Portfolio。

Competitive Advantage。

Governance。

Human Capital。

Technology。

Risk。

Sustainability。

これらが相互作用する。

したがって本書では企業価値を、

[
Corporate\ Value

f(
Strategy,
Capital,
Business,
Governance,
Human,
Technology,
Risk,
Time
)
]

として扱う。

重要なのは、この式を一つの固定Modelとして計算することではない。

Corporate Valueが複数のStateとRelationから形成されることをArchitectureへ反映することである。

⸻

M&AはDecision Architectureの縮図である

M&Aを見るとConsultingの構造がよく分かる。

Targetを探索する。

Strategic Fitを分析する。

企業価値を評価する。

Due Diligenceを行う。

Deal Structureを設計する。

Negotiationを支援する。

Executionする。

Closingする。

その後にPMIがある。

つまり、

Search
→ Analyze
→ Value
→ Decide
→ Execute
→ Integrate

という一連のProcessである。

大和総研のConsultingは、StrategyやValuationだけでなく、M&Aや組織再編を含む企業Transformationへ接続している。

KnowledgeをReportとして終わらせず、DecisionとImplementationへ近づける領域である。

⸻

Governanceも企業Architectureである

Governanceも規則集ではない。

Board。

Management。

Shareholder。

Employee。

Audit。

Risk Management。

Internal Control。

それぞれのAuthorityとResponsibilityを定義するSystemである。

誰がProposalを出すのか。

誰がDecisionするのか。

誰がApproveするのか。

誰がExecuteするのか。

誰がMonitorするのか。

これはSoftware ArchitectureにおけるAuthorizationにも似ている。

Proposal
  ↓
Review
  ↓
Decision
  ↓
Approval
  ↓
Execution
  ↓
Monitoring

企業のGovernanceをMachine-readableにするなら、Organization Chartだけでは足りない。

Authority Graph

が必要になる。

Consulting Knowledgeは、ここでもArchitectureへ翻訳できる。

⸻

Human Capitalを経営へ接続する

企業価値を形成するのはFinancial Capitalだけではない。

人間がStrategyをつくり、Technologyを使い、顧客とのRelationを形成し、Businessを運営する。

そのためHuman Capital Managementは、人事部門だけの問題ではなくCorporate Strategyの一部になる。

大和総研のConsultingでもHuman Capitalを経営Strategyへ接続し、Data Analysisと組み合わせる領域が形成されている。

例えば、

Skill。

Experience。

Engagement。

Mobility。

Training。

Recruitment。

Retention。

Productivity。

をDataとして扱う。

しかし重要なのは「人間を数値化する」ことではない。

人に関するDataを、経営Decisionへどこまで適切に接続できるか

である。

人間をScoreへ圧縮するArchitectureではなく、組織Capabilityを理解するためのDataとして扱う必要がある。

⸻

Consulting KnowledgeをMachine-readableにする

Consultingには大量のKnowledgeが蓄積される。

Industry Knowledge。

Financial Model。

Valuation Method。

Governance Pattern。

M&A Process。

Human Capital Framework。

過去Project。

Client-specific Context。

これらがDocumentの中だけに残れば、再利用には限界がある。

そこで、

Company
Strategy
Business
Capital
Asset
Governance
Organization
Person
Skill
Risk
Technology
Market
Stakeholder
Decision
Event
Time

をEntityとして定義する。

そして、

Company ── OWNS ── Business
Company ── ALLOCATES ── Capital
Business ── GENERATES ── CashFlow
Board ── APPROVES ── Decision
Person ── HAS ── Skill
Risk ── AFFECTS ── CorporateValue
Technology ── TRANSFORMS ── Business

というRelationを持たせる。

するとConsulting Knowledgeは、過去のPresentation Fileの集合からEnterprise Knowledge Graphへ変わる。

⸻

ResearchとConsultingを接続する

ここで第Ⅱ部とのConnectionが生まれる。

Researchは、

Economy。

Market。

Policy。

Technology。

Industry。

を観測していた。

Consultingは、

Company。

Strategy。

Capital。

Governance。

Human Capital。

を観測する。

二つを接続すると、

External Reality
Economy / Market / Policy / Technology
                ↓
             Company
                ↓
Strategy / Capital / Governance / Human

となる。

例えばInterest Rateが変化する。

ResearchがMacro Impactを分析する。

Consultingが企業のCost of CapitalとCapital Allocationへの影響を分析する。

経営者がInvestmentやM&Aを再検討する。

Economic IntelligenceがEnterprise Decisionへ到達する。

これがResearchとConsultingを同じ企業が持つ意味の一つである。

⸻

AI Consultant Agent

2026年以降、このProcessにもAIが入る。

AIがCorporate Disclosureを読む。

Financial Dataを取得する。

Peer Comparisonを行う。

過去Project Knowledgeを検索する。

Scenarioを生成する。

Valuation Modelを実行する。

Board向けEvidenceを整理する。

概念的には、

Client Question
     ↓
Consulting Agent
     ↓
Research / Financial / Governance / Human Data
     ↓
Scenario & Evidence
     ↓
Consultant Review
     ↓
Management Decision

となる。

しかしAI ConsultantがCEOの代わりに経営Decisionを行うわけではない。

Consultantもまた、経営者の代わりに企業の目的を決定する存在ではない。

最終的なAuthorityは企業側に残る。

AI → Evidence → Scenario → Consultant → Management

というResponsibility Chainを維持する。

⸻

Point ConsultingからContinuous Decision Intelligenceへ

2050年から見ると、さらに次のRequirementが現れる。

企業RealityはConsulting Projectの開始日と終了日に合わせて変化しない。

Marketは変わり続ける。

Capital Costも変わる。

Competitorも動く。

Technologyも進化する。

Organizationも変化する。

したがって将来的には、

Point-in-time Consulting

から、

Continuous Decision Intelligence

への拡張可能性がある。

企業Stateを継続的に観測する。

External Realityと接続する。

ScenarioをSimulationする。

Decision Optionを更新する。

人間が判断する。

Consultingが一回のProjectではなく、継続的なDecision Architectureへ拡張する。

⸻

コンサルティング本部は、大和総研の中でKnowledgeを企業のDecisionへ近づけるCapabilityである。

Researchが世界を理解する。

Consultingが企業の選択肢へ翻訳する。

Systemがその選択をRealityで動かす。

[
\boxed{
Research
\rightarrow
Knowledge
\rightarrow
Consulting
\rightarrow
Decision
\rightarrow
System
}
]

この流れの中心にあるのがCorporate Valueである。

では企業価値とは、実際には何から構成されるのか。

Financial Valueだけなのか。

Capital、Business、Governance、Human、Technology、Risk、Timeをどのように一つのEnterprise Modelへ接続するのか。

次節では、その中心概念をMachine-readableなStructureへ変換する。

企業価値を記述する。
第2節　企業価値を記述する

企業価値は、一つの数字ではない。

株価。

時価総額。

Enterprise Value。

DCFによるValuation。

ROE。

ROIC。

PBR。

これらは企業を理解する重要なIndicatorである。しかし、どれも企業そのものではない。

企業とは、Capital、Business、People、Technology、Customer、Governance、Riskが時間の中で相互作用するSystemである。

したがって企業価値を理解するには、Valueを計算するだけではなく、

ValueがどのようなStructureから生成されているか

を記述する必要がある。

⸻

PriceとValueを分ける

最初に区別するべきなのは、

[
Price \neq Value
]

である。

Market Priceは、その時点の市場参加者による評価として重要である。

しかし企業の将来Cash Flow、Asset、Technology、Human Capital、Competitive Positionが完全に一つのPriceへ反映されているとは限らない。

一方、Valuation ModelもRealityそのものではない。

DCFなら、

Revenue Growth。

Operating Margin。

Investment。

Cash Flow。

Cost of Capital。

Terminal Value。

などのAssumptionによって結果が変わる。

したがって本書では、

Market Price

Accounting Value

Model-based Value

Strategic Value

を区別したまま接続する。

一つの「正しい企業価値」をAIに決めさせるArchitectureにはしない。

⸻

企業価値をDriverへ分解する

企業価値をMachine-readableにするには、まずValue Driverへ分解する。

Corporate Value
├─ Revenue
├─ Profitability
├─ Growth
├─ Capital Efficiency
├─ Cost of Capital
├─ Business Portfolio
├─ Competitive Advantage
├─ Governance
├─ Human Capital
├─ Technology
├─ Risk
└─ Time

例えばROICが低下している。

その原因は一つとは限らない。

Marginが低下したのか。

Assetが増えたのか。

過剰投資なのか。

新規Businessへの先行投資なのか。

M&A後のIntegration途上なのか。

同じ数値でも意味は異なる。

したがって、

Indicator → Driver → Cause → Decision

までRelationを辿る必要がある。

⸻

Capital Allocationを中心に置く

経営者が企業価値へ働きかける重要なOperationの一つがCapital Allocationである。

企業が生み出したCashを、

既存Businessへ再投資する。

新規Businessへ投資する。

R&Dへ使う。

Human Capitalへ投資する。

M&Aへ使う。

Debtを返済する。

Dividendとして還元する。

Share Buybackを行う。

どの選択にもOpportunity Costがある。

したがって、

Cash Generation
     ↓
Capital Allocation
     ├─ Existing Business
     ├─ Growth Investment
     ├─ R&D / Technology
     ├─ Human Capital
     ├─ M&A
     ├─ Debt Reduction
     └─ Shareholder Return

というArchitectureが必要になる。

Corporate Value Consultingとは、Valueを評価するだけではなく、

CapitalをどのPossible Futureへ配分するか

を設計する仕事でもある。

⸻

Business Portfolioを記述する

企業全体の平均値だけを見ると、内部構造が消える。

成長Business。

成熟Business。

高収益Business。

低収益Business。

Strategic Business。

Non-core Business。

それぞれのStateは異なる。

そこでCompanyをBusiness Portfolioへ分解する。

Company
├─ Business A
│    ├─ Revenue
│    ├─ Profit
│    ├─ Capital
│    ├─ Growth
│    └─ Risk
├─ Business B
└─ Business C

さらにBusiness間のRelationを見る。

共通Customerがいるのか。

Technologyを共有しているのか。

Dataを共有できるのか。

Supply Chainが共通なのか。

Brand Synergyがあるのか。

単独では低収益でも、別Businessの競争力を支えている可能性がある。

Portfolio Managementには、数字だけでなくRelationが必要になる。

⸻

Intangible Valueを接続する

現代企業では、Balance Sheetだけでは捉えにくいValue Sourceが大きくなっている。

Human Capital。

Software。

Data。

Patent。

Brand。

Customer Relationship。

Organizational Knowledge。

AI Model。

Business Process。

これらの一部は会計上Assetとして認識されず、あるいは経済的価値とBook Valueが大きく異なる。

だからといって、すべてを無理に金額換算する必要はない。

重要なのは、

Intangible Asset → Capability → Business Outcome

というRelationを記述することである。

例えば、

Employee Skill
     ↓
Engineering Capability
     ↓
Product Quality
     ↓
Customer Retention
     ↓
Future Cash Flow

と接続する。

Human CapitalやTechnologyを、単なるNon-financial KPIとして企業価値の外側へ置かない。

⸻

GovernanceはValue Creationの条件である

企業価値は、Strategyが優れているだけでは形成されない。

誰がDecisionするのか。

Capital Allocationを誰が監督するのか。

Conflict of Interestをどう管理するのか。

Riskを誰がMonitorするのか。

BoardがManagementへどのようなOversightを行うのか。

Governanceが必要になる。

したがって、

Strategy → Decision → Execution → Monitoring

を支えるControl ArchitectureとしてGovernanceを記述する。

Governanceは企業価値へ直接足し算される数字ではない。

しかしValue Creationが継続するためのSystem Conditionである。

⸻

RiskをValueの外へ置かない

Riskも企業価値と分離できない。

Market Risk。

Credit Risk。

Operational Risk。

Cyber Risk。

Geopolitical Risk。

Climate Risk。

Legal Risk。

Human Capital Risk。

AI / Model Risk。

Supply-chain Risk。

重要なのはRiskを一覧化することだけではない。

どのBusinessへ影響するのか。

どのAssetへ影響するのか。

どのCash Flowへ到達するのか。

どのControlが存在するのか。

をRelationとして記述する。

Risk
↓
Exposure
↓
Business
↓
Cash Flow
↓
Corporate Value

これによってRisk ManagementとCorporate Value Managementを接続できる。

⸻

Timeを企業価値へ入れる

企業価値にはTimeがある。

今日のProfitを最大化するDecisionが、長期Valueを最大化するとは限らない。

R&D。

Human Capital。

System Modernization。

New Business。

これらは短期的にはCostとして現れながら、将来Capabilityを形成する場合がある。

したがって、

Current Earnings

と

Future Capability

を同じ時間軸で見る必要がある。

本書では企業を、

[
State_t
\xrightarrow{Decision_t}
State_{t+1}
]

として扱う。

経営とは、現在Stateから次のStateへのTransitionを選択するOperationでもある。

Corporate Valueは静止した数字ではなく、State Transitionの結果として形成され続けるValueなのである。

⸻

Enterprise Knowledge Graph

ここまでをGraphへ翻訳すると、企業価値の構造が見えてくる。

Company
├─ OWNS ─────────> Business
├─ EMPLOYS ──────> Person
├─ OPERATES ─────> System
├─ HOLDS ────────> Asset
└─ FACES ────────> Risk
Business
├─ GENERATES ────> CashFlow
├─ USES ─────────> Capital
├─ DEPENDS_ON ───> Capability
└─ SERVES ───────> Customer
Capability
├─ DEPENDS_ON ───> HumanCapital
├─ DEPENDS_ON ───> Technology
└─ AFFECTS ──────> CompetitivePosition
Decision
├─ ALLOCATES ────> Capital
└─ CHANGES ──────> EnterpriseState

企業価値は、このGraph全体から生まれる。

ValuationはGraphの一部をFinancial ModelへProjectionしたものとして位置づけられる。

⸻

Corporate Value Digital Model

このArchitectureがあれば、ConsultingはCurrent Stateの診断からScenario比較へ進める。

例えば100億円のCapitalがある。

Scenario Aでは既存Businessへ投資する。

Scenario BではM&Aを行う。

Scenario CではAI・System Modernizationへ投資する。

Scenario DではShareholder Returnへ配分する。

それぞれについて、

Growth。

Cash Flow。

ROIC。

Risk。

Human Capability。

Technology Capability。

Future Optionality。

を比較する。

Current State
     ↓
Decision Options
A   B   C   D
↓   ↓   ↓   ↓
Possible Enterprise States
     ↓
Value / Risk / Capability

これがCorporate Digital Twinへつながる基本構造になる。

未来を一つに予測するのではない。

Decisionによって企業のPossible Stateがどう変化するかを比較する。

⸻

AIは企業価値を決定しない

AIはこのArchitectureを大きく支援できる。

Financial Statementを解析する。

Peer Companyを比較する。

Capital Efficiencyを計算する。

DisclosureからRiskを抽出する。

M&A Scenarioを生成する。

Valuationを複数条件で計算する。

過去Decisionとの類似性を検索する。

しかし、

「この企業の正しい価値は8,250億円である」

とAIが最終決定するSystemにはしない。

ModelによってValueは変わる。

Assumptionによって変わる。

Stakeholderによって重視するValueも異なる。

したがって、

AI → Model → Scenario → Evidence → Consultant → Management

というArchitectureを維持する。

⸻

企業価値を記述するということ

企業価値を記述するとは、企業を一つの数字へ変換することではない。

企業が、

何を持ち、

何を生み出し、

何に依存し、

どのRiskを抱え、

誰がDecisionし、

Capitalをどこへ配分し、

どのStateへ移行しようとしているのか。

そのStructureを記述することである。

最小形にすれば、

[
\boxed{
Corporate\ Value

Capital
\times
Capability
\times
Decision
\times
Time
}
]

となる。

これは会計式ではない。

企業価値を生み出すRelationを示すArchitectureである。

そして、この中でDecisionが正当に行われ続けるためには、Authority、Responsibility、Oversightを設計しなければならない。

企業価値の次に現れるのは、企業を動かすDecision Systemである。

次節では、

GovernanceをSystemとして見る。
第3節　GovernanceをSystemとして見る

Governanceは、規則の集合ではない。

取締役会を設置する。

社外取締役を選任する。

委員会を設ける。

Internal Controlを整備する。

Disclosureを行う。

これらは重要である。しかし制度や組織を配置しただけで、Governanceが機能するとは限らない。

企業では毎日、無数のDecisionが行われている。

誰が提案するのか。

誰が情報を見ることができるのか。

誰が審査するのか。

誰が決定するのか。

誰が承認するのか。

誰が実行するのか。

誰が結果を監視するのか。

問題が起きたとき、誰が停止できるのか。

Governanceの本質は、このAuthorityとResponsibilityのArchitectureにある。

したがって本書では、

[
\boxed{
Governance = Decision\ Control\ System
}
]

として記述する。

⸻

Organization ChartだけではGovernanceは見えない

企業にはOrganization Chartがある。

しかしOrganization Chartから分かるのは、主として組織の所属関係である。

Governanceに必要なのは、それだけではない。

例えば大型Investmentを行う場合、

Business UnitがProposalを作成する。

FinanceがFinancial Impactを検証する。

Risk ManagementがRiskを確認する。

Legalが法的問題を確認する。

Management Meetingが審議する。

Boardが承認する。

Execution Teamが実行する。

Auditが事後検証する。

つまり必要なのは、

Organization Graph

だけではなく、

Authority Graph

である。

Proposal
  ↓
Review
  ↓
Risk Check
  ↓
Decision
  ↓
Approval
  ↓
Execution
  ↓
Monitoring
  ↓
Audit

Governanceとは、このFlowが正しく動く条件を設計することである。

⸻

DecisionをEntityにする

GovernanceをMachine-readableにするなら、DecisionそのものをData Modelへ入れる必要がある。

Decision
├─ decision_id
├─ subject
├─ proposer
├─ decision_authority
├─ approver
├─ amount
├─ risk_level
├─ evidence
├─ alternatives
├─ decided_at
├─ effective_from
└─ status

さらに、

Person ── PROPOSES ── Decision
Committee ── REVIEWS ── Decision
Board ── APPROVES ── Decision
Decision ── ALLOCATES ── Capital
Decision ── CHANGES ── Business
Risk ── AFFECTS ── Decision

というRelationを持たせる。

これによってGovernanceは、「規程に何が書かれているか」だけでなく、

実際に誰が何を決定したのか

まで追跡できる。

⸻

AuthorityとAccessを接続する

GovernanceはCybersecurityとも接続する。

ある人が組織上Decision Authorityを持っていても、System上で必要以上のAccess権限を持つべきではない。

逆に、System上で実行可能だからといって、その人にBusiness Authorityがあるとは限らない。

したがって、

Organizational Authority

と

Digital Authorization

を接続する必要がある。

例えば、

Role
↓
Authority
↓
Permission
↓
Action
↓
Audit Log

とする。

Boardが承認したCapital Allocationと、実際にSystemでExecutionされたTransactionを接続できれば、

Decision → Execution

のTraceabilityが成立する。

Governanceが制度論からRuntimeへ接続される瞬間である。

⸻

Segregation of Duties

Governanceでは、一人がすべてを実行できないようにすることも重要である。

提案者。

審査者。

承認者。

実行者。

監査者。

を必要に応じて分離する。

これはSegregation of Dutiesである。

Software Architectureとして表現すれば、

PROPOSE
  ≠
APPROVE
  ≠
EXECUTE
  ≠
AUDIT

となる。

高額なInvestment。

M&A。

重要なSystem Change。

Sensitive Data Access。

AI ModelのProduction Deployment。

影響が大きいOperationほど、複数のControl Pointを持たせる。

Governance PrincipleをCodeへ翻訳できる。

⸻

Boardへ届くInformationを設計する

GovernanceのQualityは、Authorityだけでは決まらない。

Decision MakerへどのInformationが届くかによっても変わる。

Boardが大量の資料を受け取っても、重要なRiskやAlternativeが見えなければ良いDecisionにはならない。

必要なのは、

Information Architecture

である。

例えば重要Decisionについて、

Decision Package
├─ Current State
├─ Objective
├─ Evidence
├─ Alternatives
├─ Financial Impact
├─ Risk
├─ Stakeholder Impact
├─ Scenario
├─ Assumptions
└─ Recommendation

を一つのEvidence Packageとして構成する。

Consultingは、このDecision Packageを設計するCapabilityでもある。

⸻

GovernanceとCorporate Value

Governanceは企業価値の外側にあるCompliance Costではない。

Capital AllocationのQualityに影響する。

Risk Takingに影響する。

Management Accountabilityに影響する。

ShareholderとのRelationに影響する。

企業のLong-term Strategyにも影響する。

したがって、

Governance
    ↓
Decision Quality
    ↓
Capital Allocation
    ↓
Business State
    ↓
Corporate Value

というRelationを持つ。

ただし「Governanceを強化すれば企業価値が必ず上がる」という単純な因果関係ではない。

過剰なControlはDecision Speedを低下させる場合もある。

必要なのは、

Control × Speed × Accountability

のBalanceである。

⸻

AI時代のGovernance

生成AIとAI Agentは、Governanceに新しい問題を持ち込む。

AIがReportを生成する。

AIがRiskを検出する。

AIがInvestment Optionを比較する。

AI AgentがSystemへActionを要求する。

ここで、

AIが提案したこと

と

企業が決定したこと

を混同してはならない。

本書では明確に分離する。

AI Proposal
    ↓
Evidence
    ↓
Human Review
    ↓
Human Decision
    ↓
Authorized Execution

AIにはProposal Authorityを与えられる。

Analysis Authorityも与えられる。

しかし高影響領域のDecision AuthorityやExecution Authorityは別に設計する。

これがHuman-authoritative Architectureである。

⸻

AI Governanceを企業Governanceへ埋め込む

AI Governanceを別冊のEthics Guidelineとして置くだけでは不十分である。

AIがEnterprise Runtimeへ入るなら、GovernanceもRuntimeへ入れなければならない。

必要になるのは、

Model Registry。

Data Lineage。

Prompt / Agent Version。

Identity。

Authorization。

Human Approval。

Monitoring。

Audit Log。

Rollback。

Incident Management。

である。

例えばAI Agentが重要なActionを要求した場合、

Agent Request
     ↓
Identity Check
     ↓
Policy Check
     ↓
Risk Classification
     ↓
Human Approval
     ↓
Execution
     ↓
Audit

というControl Flowを通す。

Governanceを文章からExecutable Policyへ変える。

⸻

RuleをCodeへ翻訳する

この考え方を進めれば、企業規程の一部をMachine-readable Policyとして表現できる。

例えば、

IF
   decision.amount > approval_threshold
OR
   decision.risk_level == "HIGH"
THEN
   require(board_approval)
   require(independent_review)
   enable(audit_logging)

というRuleを持たせる。

もちろん、すべてのGovernance RuleをCode化できるわけではない。

経営判断には曖昧性がある。

例外がある。

Contextがある。

だから、

Machine-enforceable Rule

と

Human Judgment Rule

を分離する。

Code化できる部分だけを確実にExecutionする。

⸻

Governance Digital Twin

Corporate Digital TwinへGovernanceを入れると、企業のDecision StructureをSimulationできる可能性が生まれる。

例えば新規Investment Proposalを置く。

現在のAuthority Structureでは、何段階のApprovalが必要か。

どこにBottleneckがあるか。

どのRisk Controlが働くか。

誰にInformationが届くか。

Decisionまでどれだけ時間がかかるか。

を分析する。

するとGovernance Consultingは、

制度を設計する

だけでなく、

Decision FlowをSimulationする

領域へ拡張する。

将来的には、

Current Governance State。

Alternative Governance State。

を比較し、

Speed。

Control。

Accountability。

Risk。

への影響を見ることができる。

⸻

GovernanceをContinuousにする

Governanceは年一回のBoard Evaluationだけで存在するものではない。

企業では毎日Decisionが行われる。

したがって2050年から見ると、GovernanceもContinuous Intelligenceへ接続される。

Decisionが蓄積される。

Execution結果が蓄積される。

Risk Eventが発生する。

Outcomeが観測される。

過去DecisionとOutcomeのRelationを分析する。

Decision
  ↓
Execution
  ↓
Outcome
  ↓
Measurement
  ↓
Governance Learning
  ↓
Next Decision

Governance自身がLearning Loopを持つ。

⸻

GovernanceをSystemとして見ると、企業経営の姿が変わる。

BoardやCommitteeは単なる組織ではない。

Decision Nodeである。

規程はDocumentだけではない。

Policyである。

Approvalは手続きだけではない。

State TransitionのAuthorizationである。

Auditは事後確認だけではない。

DecisionとExecutionを接続するTraceabilityである。

したがって、

[
\boxed{
Governance

Authority
+
Information
+
Decision
+
Control
+
Audit
}
]

となる。

そして企業のDecision Systemを実際に動かしているのは、制度だけではない。

その内部には人間がいる。

どのSkillを持つ人がいるのか。

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

誰がどの仕事を担っているのか。

どのInvestmentによって組織能力が変化するのか。

次節では、企業価値とGovernanceを人間側から接続する。

Human CapitalをDataへ接続する。
第4節　Human CapitalをDataへ接続する

企業は人によって動いている。

Strategyを考える。

顧客と話す。

Researchする。

Softwareを書く。

Machineを動かす。

Riskを判断する。

Organizationをつくる。

AIを使う。

そして最終的にDecisionする。

したがってCorporate Valueを記述するなら、Financial CapitalやTechnologyだけでなく、Human Capitalを企業Architectureへ入れなければならない。

しかし、人間をDataへ接続することには慎重さが必要である。

人間はDataではない。

[
\boxed{
Person \neq Data
}
]

Dataとして記述できるのは、人間そのものではなく、その人に関して特定の目的と条件のもとで観測された情報である。

この境界からHuman Capital Intelligenceを設計する。

⸻

Human Capitalは人数ではない

企業のHuman CapitalをEmployee Countだけで把握することはできない。

同じ1,000人のOrganizationでも、持っているCapabilityは異なる。

Skill。

Experience。

Knowledge。

Role。

Qualification。

Leadership。

Collaboration。

Learning。

Mobility。

これらの組み合わせによって、企業が実行できることが変わる。

したがってHuman Capitalを、

Headcount

から、

Capability Structure

へ拡張して見る。

Organization
├─ Person
├─ Role
├─ Skill
├─ Experience
├─ Knowledge
├─ Team
├─ Project
└─ Learning

重要なのは「何人いるか」だけではない。

どのCapabilityが、どこに存在しているか

である。

⸻

StrategyとHuman Capitalを接続する

Human Capital Managementが経営になるのは、People Dataを収集したときではない。

Strategyと接続されたときである。

例えば企業がAI Businessを拡大すると決める。

必要になるのは、

Data Scientist。

Software Engineer。

Domain Expert。

Security Specialist。

AI Governance。

Product Manager。

だけとは限らない。

既存EmployeeのAI Literacy。

Business Processの再設計。

ManagerのDecision Capability。

組織間Collaboration。

も必要になる。

したがって、

Strategy
  ↓
Required Capability
  ↓
Current Capability
  ↓
Capability Gap
  ↓
Build / Hire / Partner / Automate

という構造になる。

Human Capital Strategyとは、採用計画ではない。

Future StrategyとCurrent CapabilityのGapを埋めるArchitectureである。

⸻

SkillをGraphにする

このStructureをMachine-readableにするには、PersonとSkillのRelationを記述する。

Person ── HAS_SKILL ── Skill
Person ── HAS_ROLE ── Role
Person ── WORKS_ON ── Project
Project ── REQUIRES ── Skill
Role ── REQUIRES ── Capability
Training ── DEVELOPS ── Skill
Strategy ── REQUIRES ── Capability

すると、

「このStrategyを実行するCapabilityは社内のどこに存在するか」

「どのSkillが不足しているか」

「どのProjectでKnowledgeが形成されたか」

を探索できる。

これは従来のEmployee Masterとは異なる。

Human Capital Knowledge Graphである。

⸻

Skillは固定属性ではない

ただしSkillをPersonへ固定的なLabelとして貼ってはならない。

Skillは変化する。

学習する。

Projectを経験する。

Technologyが陳腐化する。

Roleが変わる。

したがって、

Person
 ↓
Skill State(t)
 ↓
Learning / Experience
 ↓
Skill State(t+1)

としてTimeを持たせる。

「Python Skillあり」というBooleanだけでは足りない。

どのContextで使ったのか。

いつ使ったのか。

どの程度のEvidenceがあるのか。

どのVersionのTechnologyか。

を必要に応じて保持する。

Human CapitalはStatic Master Dataではない。

Dynamic Capability Stateである。

⸻

Data AnalyticsとConsulting

大和総研のHuman Capital Consultingでは、人材・組織に関する経営課題をData Analysisと接続する領域がある。

ここに大和総研の構造的特徴が現れる。

Consultingだけではない。

Data Science Capabilityを持っている。

Systemを実装できる。

したがって、

Consulting Question
→ Human Data
→ Analysis
→ Decision
→ System

まで接続できる可能性がある。

例えば離職率を分析するだけではなく、

どのOrganizationで変化しているか。

どのRoleで発生しているか。

どのSkillが流出しているか。

Business Strategyへどのような影響があり得るか。

までRelationを辿る。

⸻

Correlationを人事判断に直結させない

People Analyticsには大きなRiskもある。

例えば、ある属性と離職率にCorrelationが見つかったとする。

それだけで、その属性を持つIndividualを「離職Riskが高い人」と決めるべきではない。

[
Correlation \neq Individual\ Truth
]

である。

Aggregate AnalysisとIndividual Decisionを区別する必要がある。

採用。

配置。

昇進。

評価。

報酬。

退職。

これらは人間の人生へ直接影響するHigh-impact Decisionである。

したがってAIやAlgorithmによるScoreを、そのままDecisionへ接続しない。

Analysis → Evidence → Human Review → Decision

を維持する。

⸻

Consent・Purpose・Access

Human Capital DataにはSensitiveな情報が含まれ得る。

したがってTechnologyより先に、

何のために使うのか

を定義する必要がある。

Purpose Limitation。

Data Minimization。

Consentが必要な領域ではConsent。

Role-based Access。

Retention Policy。

Audit。

Deletion。

をArchitectureへ入れる。

概念的には、

Human Data
  ↓
Purpose Check
  ↓
Authorization
  ↓
Approved Analysis
  ↓
Human Review
  ↓
Audit

となる。

「取得できるDataだから使う」のではない。

正当な目的のために必要なDataだけを使う。

Human Capital Intelligenceの信頼性は、この境界によって決まる。

⸻

Human CapitalとCorporate Valueを接続する

Human Capitalを企業価値へ接続するとき、単純な因果関係を置いてはならない。

Trainingを増やせばCorporate Valueが上がる。

Engagement Scoreが高ければProfitが増える。

という単純な式ではない。

間にはCapabilityが存在する。

例えば、

Learning Investment
      ↓
Skill Development
      ↓
Engineering Capability
      ↓
Product / Process Improvement
      ↓
Customer / Productivity Outcome
      ↓
Financial Outcome

という経路を仮説として置く。

そしてDataで検証する。

つまりHuman Capital KPIを企業価値へ直接結びつけるのではなく、

Investment → Capability → Business Outcome → Value

というRelationを見る。

⸻

AI時代には仕事そのものが変わる

生成AIの導入によって、Human Capital Managementの問いも変化する。

「何人必要か」だけでは足りない。

どのTaskを人間が行うのか。

どのTaskをAIが支援するのか。

どのTaskをAutomationするのか。

どのDecisionはHuman Authorityとして残すのか。

を設計する必要がある。

Work
├─ Human-only
├─ Human + AI
├─ AI-assisted
└─ Automatable

しかし目的は人間を可能な限りAIへ置き換えることではない。

必要なのは、

Human Capability × Machine Capability

の再設計である。

⸻

AIによって生まれる新しいCapability

AI時代には専門家の構造も変わる。

EconomistがAIを使う。

ConsultantがSimulationを使う。

EngineerがCoding Agentを使う。

ManagerがDecision Support Agentを使う。

すると必要なのはAI Specialistだけではない。

AIを自分のDomainへ統合できるDomain Expert

である。

大和総研自身でも、PythonやData Analysisを学ぶ社内人材育成の取り組みが進められてきた。

これはHuman Capital Architectureとして重要である。

少数のDeep Specialistだけでなく、

**Few Deep Experts

* Many AI-capable Domain Experts**

という構造を形成する。

AI Capabilityを一部門へ閉じ込めない。

⸻

Human Capital Digital Model

Corporate Digital TwinへHuman Capitalを接続すると、Strategy実行可能性をSimulationできるようになる。

例えば2050へ向けて新しいBusiness Capabilityが必要だとする。

Required Skillsを定義する。

Current Skillsとの差を見る。

そして複数Optionを比較する。

Future Strategy
     ↓
Required Capability
     ↓
Capability Gap
     ↓
┌────┼─────┬────────┐
Build Hire Partner Automate
└────┼─────┴────────┘
     ↓
Possible Organization State

TrainingにはTimeがかかる。

HiringにはMarket Constraintがある。

PartneringにはDependencyが生まれる。

AutomationにはTechnology Riskがある。

それぞれを比較する。

これによってHuman Capital Consultingは、現在のEmployee AnalysisからFuture Capability Designへ拡張する。

⸻

AI AgentとHuman Capital

AI Agentは、このArchitectureを探索するInterfaceにもなり得る。

例えば経営者が問う。

「三年後にAI-based Financial Serviceを展開するために、どのCapabilityが不足しているか。」

Agentは、

Strategy。

Project。

Skill。

Role。

Training。

Recruitment。

External Labor Market。

を探索する。

そして、

Required Capability
Current Capability
Gap
Evidence
Build Option
Hire Option
Partner Option
Risk

を提示する。

しかしAgentがIndividualの採用・昇進・解雇を自律決定するArchitectureにはしない。

AIはOrganization Capabilityを理解するために使う。

人間をAlgorithmによって一方向に分類するために使わない。

⸻

人をDataへ圧縮しない

Human CapitalをDataへ接続すると、企業はこれまで見えなかったStructureを観測できる。

どのCapabilityが存在するか。

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

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

どのStrategyが実行可能か。

どこへLearning Investmentを行うべきか。

しかし、そのために人間そのものをScoreへ圧縮してはならない。

Human Capital Intelligenceの最小原則は、

[
\boxed{
Person

Data\ Representation
}
]

である。

Dataは人間を理解するための一つのRepresentationにすぎない。

⸻

企業価値を記述した。

GovernanceをDecision Systemとして記述した。

Human CapitalをDynamic Capabilityとして接続した。

ここまで来ると、企業は単なるFinancial Statementの集合ではなくなる。

Strategy。

Business。

Capital。

Governance。

People。

Technology。

Risk。

System。

Data。

それらが時間の中で変化するEnterprise Stateとして見えてくる。

次に必要なのは、この全体を一つのSimulation Architectureへ統合することである。

現在の企業を完全に複製するのではない。

Decisionによって次の企業Stateがどう変わり得るかを比較可能にする。

次節では、

Corporate Digital Twin。
第5節　Corporate Digital Twin

企業を一つのModelとして記述できるだろうか。

Financial Statementだけでは足りない。

Organization Chartだけでも足りない。

Business Portfolio、Capital、Governance、Human Capital、Technology、System、Data、Risk、Customer、Marketまで含めなければ、企業がどのように動いているかは見えてこない。

さらに企業は静止していない。

投資する。

採用する。

M&Aを行う。

Systemを更新する。

Businessを売却する。

AIを導入する。

そのたびにEnterprise Stateは変化する。

そこで必要になるのがCorporate Digital Twinである。

ただし本書では、企業を完全に複製するTwinを意味しない。

[
\boxed{
Corporate\ Digital\ Twin

Observable\ Enterprise\ State
+
Relation
+
Simulation
+
Validation
}
]

現在の企業をMachine-readableに記述し、Decisionによって生じ得る複数のFuture Stateを比較するArchitectureである。

⸻

CompanyをEntityの集合へ分解する

最初に企業を一つのNodeとして扱うことをやめる。

Company
├─ Strategy
├─ Business
├─ Capital
├─ Asset
├─ Governance
├─ Organization
├─ Person
├─ Capability
├─ Technology
├─ System
├─ Data
├─ Customer
├─ Risk
└─ Event

そしてRelationを持たせる。

Company ── OWNS ──> Business
Business ── USES ──> Capital
Business ── REQUIRES ──> Capability
Capability ── DEPENDS_ON ──> Person
Capability ── DEPENDS_ON ──> Technology
Organization ── OPERATES ──> System
System ── PROCESSES ──> Data
Decision ── CHANGES ──> EnterpriseState
Risk ── AFFECTS ──> Business

これによって企業はDocumentの集合からEnterprise Graphへ変わる。

⸻

Current Stateをつくる

Digital Twinの第一段階はSimulationではない。

現在Stateを可能な範囲で正確に記述することである。

Revenue。

Profit。

Capital。

Business Portfolio。

Organization。

Headcount。

Skill。

System。

Asset。

Risk。

Decision。

これらをTime付きで保持する。

[
State_t

{
Business,
Capital,
Human,
Technology,
Governance,
Risk,
System
}_t
]

重要なのは、すべてをReal-timeにすることではない。

Financial DataはQuarterlyかもしれない。

Organization DataはEvent-drivenで変化する。

Market Dataは高Frequencyである。

Human Capital Dataは適切なPurposeとFrequencyで更新する。

各Realityの変化速度に合わせてStateを同期する。

⸻

External Realityを接続する

企業は閉じたSystemではない。

Economy。

Interest Rate。

Exchange Rate。

Commodity。

Policy。

Regulation。

Technology。

Competitor。

Labor Market。

Climate。

これらの外部Stateによって企業のPossible Stateは変化する。

したがって第Ⅱ部で構築したEconomic IntelligenceをCorporate Digital Twinへ接続する。

Earth / World / Japan
       ↓
Economy / Market / Policy
       ↓
Industry / Technology
       ↓
Company

これによってResearchとConsultingがData Architecture上でも接続される。

例えば金利上昇というEconomic Eventを、その企業のDebt、Investment、Valuation、M&A Strategyへ伝播させることができる。

⸻

DecisionをState Transitionとして扱う

Corporate Digital Twinで最も重要なのは、Decisionである。

企業経営とは、Current Stateを別のStateへ移すOperationだからである。

[
State_t
\xrightarrow{Decision}
State_{t+1}
]

例えば100億円のCapitalを保有する企業がある。

Option Aは既存Businessへ投資する。

Option BはM&Aを行う。

Option CはAI Transformationへ投資する。

Option DはShareholder Returnへ配分する。

すると、

Current State
    ↓
Decision Space
┌────┼────┬────┐
A    B    C    D
↓    ↓    ↓    ↓
Possible State A
Possible State B
Possible State C
Possible State D

が生成される。

Consultingの中心が、Recommendationの作成からPossible Enterprise Stateの比較へ拡張する。

⸻

Digital TwinはForecastではない

ここでForecastとの違いを明確にする。

Forecastは、

「何が起きそうか」

を推定する。

Digital TwinによるSimulationは、

「この条件とDecisionなら、何が起こり得るか」

を比較する。

したがってInputにはAssumptionが必要になる。

Market Growth。

Interest Rate。

Exchange Rate。

Technology Adoption。

Investment Amount。

Hiring。

M&A Synergy。

Cost Reduction。

複数のAssumptionを変えながら結果を見る。

目的は未来を一つに固定することではない。

Decision Spaceを可視化することである。

⸻

Financial Modelだけでは足りない

従来のCorporate SimulationでもFinancial Modelは存在した。

Revenueを変える。

Marginを変える。

Investmentを変える。

Cash Flowを計算する。

Corporate Digital Twinはそこから対象を拡張する。

例えばAI Investmentを行う。

短期的にはCostが増える。

Systemが変更される。

EmployeeのWork Designが変わる。

Skill Requirementが変わる。

Productivityが変化する可能性がある。

Operational Riskも変わる。

最終的にFinancial Outcomeへ到達する。

AI Investment
    ↓
Technology Capability
    ↓
Process Change
    ↓
Human Capability
    ↓
Productivity / Service
    ↓
Financial Outcome

Financial StateとOperational Stateを接続する。

これがDigital Twin化の重要な意味である。

⸻

GovernanceもTwinへ入れる

Decisionがどれほど魅力的でも、Governance上実行できなければRealityにはならない。

誰にAuthorityがあるか。

どのApprovalが必要か。

どのRisk Reviewが必要か。

どのRegulationに従うか。

そこで前節までのGovernance GraphをTwinへ接続する。

Decision
  ↓
Authority Check
  ↓
Risk / Compliance
  ↓
Approval
  ↓
Execution

これによって、

Economically Attractive

と

Organizationally Executable

を区別できる。

Corporate Digital Twinは企業価値計算機ではない。

企業が実際にState Transitionできる条件まで扱う。

⸻

Human CapitalもTwinへ入れる

Strategyを実行できるかどうかはHuman Capabilityにも依存する。

例えば新しいDigital Businessを開始したい。

Capitalはある。

Marketもある。

しかし必要なEngineering Capabilityがない。

この場合、Financial Modelだけなら「投資可能」と判定してしまうかもしれない。

Corporate Digital Twinでは、

Strategy → Required Capability → Current Capability → Gap

を見る。

そして、

Build。

Hire。

Partner。

Automate。

というOptionを比較する。

企業のPossible Stateを、MoneyだけでなくExecution Capabilityから評価する。

⸻

Twin Architecture

実装上は、一つの巨大Databaseですべてを管理する必要はない。

Authoritative SQL
     │
     ├── Financial State
     ├── Organization
     ├── System
     └── Decision
     │
Knowledge Graph
     │
     └── Enterprise Relations
     │
Vector Store
     │
     └── Documents / Reports / Policies
     │
Event Stream
     │
     └── State Changes
     │
Simulation Engine
     │
     └── Possible States

SQLはState。

GraphはRelation。

VectorはSemantic Knowledge。

EventはChange。

Simulation EngineはPossible State。

それぞれをAPIで接続する。

Digital TwinはDatabase ProductではなくArchitectureである。

⸻

EventによってTwinを更新する

企業StateはEventによって変化する。

M&Aを実行した。

Organizationを変更した。

CEOが交代した。

新ProductをLaunchした。

SystemをMigrationした。

Cyber Incidentが発生した。

Regulationが変わった。

これらをEventとして取得する。

Event
 ↓
Affected Entities
 ↓
State Transition
 ↓
Twin Update

Current Stateを上書きするだけではなく、過去Stateを保存する。

すると、

Before Decision

と

After Decision

を比較できる。

Corporate Digital TwinがEnterprise Memoryにもなる。

⸻

Realityとの差を測る

Simulationは必ず外れる。

したがって重要なのは、外れないModelをつくることではなく、誤差を観測できるArchitectureをつくることである。

Simulation
   ↓
Predicted State
   ↓
Actual State
   ↓
Difference
   ↓
Model Review

どのAssumptionが間違っていたか。

どのRelationが弱かったか。

どのEventを見落としたか。

を検証する。

Digital Twinは完成品ではない。

Realityとの差から更新され続けるModelである。

⸻

AI Consultant Agentとの接続

Corporate Digital Twinがあれば、AI Consultant Agentの役割も変わる。

単にDocumentを検索してAdviceを書くのではない。

Current Enterprise Stateを読む。

External Realityを取得する。

Constraintを確認する。

複数のDecision Optionを生成する。

Simulation Engineを呼び出す。

結果を比較する。

Evidenceを整理する。

Consultantへ提示する。

Management Question
      ↓
AI Consultant Agent
      ↓
Corporate Digital Twin
      ↓
Scenario Simulation
      ↓
Evidence Package
      ↓
Consultant
      ↓
Management Decision

AIが企業経営を自動化するのではない。

企業を考えるための計算可能な空間を提供する。

⸻

ConsultingがSoftwareになるということ

ここまで進むと、Consultingの一部はSoftwareとして継続的に動く。

Market Dataが更新される。

Company Dataが更新される。

Twin Stateが変わる。

Riskが変化する。

Scenarioが再計算される。

Consultantが確認する。

Clientへ新しいDecision Optionが提示される。

つまり、

Project → Report → End

ではなく、

Observe → Update → Simulate → Advise → Decide → Observe

というLoopになる。

これはConsultantを不要にすることではない。

ConsultantのKnowledgeをContinuous Runtimeへ拡張することである。

⸻

Corporate Digital Twinの価値は、企業を完全に複製することにはない。

企業について知っていることをMachine-readableにする。

Relationを記述する。

Current Stateを保持する。

Decision Optionを生成する。

Possible Stateを比較する。

Realityとの差を検証する。

そのLoopを継続する。

最小構造は、

[
\boxed{
Enterprise\ State
\rightarrow
Decision
\rightarrow
Possible\ State
\rightarrow
Reality
\rightarrow
Learning
}
]

となる。

そして、このTwinを人間が毎回手作業で操作する必要はない。

Dataを取得し、Knowledgeを探索し、Scenarioを組み立て、Simulationを実行するAI Agentを接続できる。

次節では、Consulting KnowledgeとCorporate Digital Twinの上で動く新しいInterfaceを設計する。

AI Consultant Agent。
第6節　AI Consultant Agent

ConsultingにAI Agentを導入すると、何が変わるのか。

最も単純な使い方は、資料を検索し、要約し、PresentationのDraftをつくらせることである。

しかし、それだけなら生成AIによるProductivity Improvementにとどまる。

本書で設計するAI Consultant Agentは、さらに一段深い。

Research Knowledge。

Corporate Data。

Financial Model。

Governance。

Human Capital。

Corporate Digital Twin。

これらをToolとして利用し、経営課題を複数のTaskへ分解し、EvidenceとScenarioを組み立てる。

つまり、

[
\boxed{
AI\ Consultant\ Agent

Reasoning
+
Enterprise\ Knowledge
+
Tools
+
Simulation
+
Governance
}
]

である。

⸻

ChatbotからAgentへ

ChatbotはQuestionに回答する。

AgentはGoalを受け取り、その達成に必要なTaskを組み立てる。

例えば経営者が問う。

「三年間でROICを改善するには、どの選択肢があるか。」

単純なLLMなら一般論を生成できる。

AI Consultant Agentは異なる。

Current Financial Stateを取得する。

Business Portfolioを確認する。

Capital Allocationを分析する。

Peer Companyを比較する。

Cost of Capitalを見る。

低収益Businessを特定する。

Investment Planを確認する。

複数Scenarioを生成する。

Corporate Digital TwinでSimulationする。

Evidenceをまとめる。

Consultantへ提示する。

Management Question
       ↓
Task Planning
       ↓
Data / Research / Enterprise Knowledge
       ↓
Analysis
       ↓
Simulation
       ↓
Evidence Package
       ↓
Consultant Review

Agentは文章生成器ではない。

Consulting WorkflowのOrchestratorになる。

⸻

一つの巨大Agentにしない

ただし、すべてを一つのAI Agentへ任せるArchitectureはRiskが大きい。

Finance。

Strategy。

Governance。

Human Capital。

M&A。

Technology。

それぞれ必要なData、Method、Authorityが異なる。

そこでCapabilityごとにAgentを分ける。

Orchestrator Agent
     │
     ├─ Research Agent
     ├─ Financial Agent
     ├─ Strategy Agent
     ├─ M&A Agent
     ├─ Governance Agent
     ├─ Human Capital Agent
     ├─ Technology Agent
     └─ Simulation Agent

Research AgentはExternal Realityを見る。

Financial AgentはFinancial StatementとValuationを扱う。

Governance AgentはAuthorityとControlを見る。

Human Capital AgentはCapability Gapを分析する。

Simulation AgentはPossible Stateを比較する。

専門性をAgent Architectureへ反映する。

⸻

AgentにはToolを使わせる

LLMの内部KnowledgeだけでConsultingを行わせてはならない。

企業Dataは変化する。

Market Dataも変わる。

制度も変わる。

さらに重要な計算には再現性が必要である。

そこでAgentはToolを利用する。

AI Agent
├─ SQL
├─ Knowledge Graph
├─ Vector Search
├─ Financial Model
├─ Valuation Engine
├─ Scenario Engine
├─ Corporate Digital Twin
└─ Approved External Sources

数値はSQLから取得する。

RelationはGraphから取得する。

DocumentはVector Searchで探す。

Valuationは検証済みModelで計算する。

ScenarioはSimulation Engineで実行する。

LLMは、それらを自然言語から操作するInterfaceになる。

⸻

Evidence-first Architecture

Consulting Agentで最も重要なのは、流暢な回答ではない。

Evidenceへ戻れることである。

Agentが、

「Business Aから撤退する選択肢を検討すべきである」

と提示したなら、

なぜそう考えたのか。

どのFinancial Dataを使ったのか。

どのMarket Assumptionか。

どのRiskを考慮したのか。

どのSimulation結果か。

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

したがってOutputを、

Recommendation
├─ Evidence
├─ Source
├─ Assumption
├─ Model
├─ Scenario
├─ Uncertainty
└─ Alternative

として構造化する。

Answer-firstではなくEvidence-firstである。

⸻

Recommendationを一つにしない

企業経営にはObjectiveが複数存在する。

Growth。

Profitability。

Capital Efficiency。

Stability。

Employee Development。

Customer Value。

Sustainability。

Risk Reduction。

これらを一つのObjective Functionへ完全に圧縮することはできない。

したがってAI Consultant Agentには、唯一の「最適解」を要求しない。

例えば、

Option A — Growth Priority

Option B — Capital Efficiency Priority

Option C — Resilience Priority

を生成する。

それぞれについて、

Expected Return。

Capital Requirement。

Risk。

Human Capability。

Execution Time。

Reversibility。

を比較する。

AIの仕事はBest Answerを決めることではない。

Decision Spaceを構造化することである。

⸻

Counterfactualを扱う

Consultingでは、

「このDecisionを実行したらどうなるか」

だけでなく、

「実行しなかったらどうなるか」

も重要である。

そこでCounterfactualを扱う。

例えばSystem Modernizationについて、

Scenario A
Modernize Now
Scenario B
Modernize Gradually
Scenario C
Do Nothing

を比較する。

Do NothingもDecision Optionである。

Current Costだけでなく、

Future Maintenance Cost。

Security Risk。

Talent Availability。

Technology Debt。

Business Opportunity。

まで含めて比較する。

AI Consultant Agentは、DecisionのOpportunity Costを可視化する。

⸻

M&A Agent

M&AはAgentic Consultingと相性のよい領域の一つである。

大量のCompany Informationを探索する。

Candidateを抽出する。

Strategic Fitを見る。

Financial Dataを比較する。

Valuation Rangeを計算する。

Synergy Hypothesisを生成する。

Riskを整理する。

ただし、

Candidate Discovery

と

Acquisition Decision

は分離する。

M&A Agent
   ↓
Candidate Space
   ↓
Evidence / Valuation / Risk
   ↓
Consultant Review
   ↓
Management / Board

Agentは探索範囲を広げる。

最終的なDeal Decisionは人間が行う。

⸻

Human Capital Agent

Human Capitalでも同じである。

AI Agentは、

Future Strategy。

Required Capability。

Current Skill。

Project Experience。

Training。

Recruitment Market。

を接続できる。

そして、

Build。

Hire。

Partner。

Automate。

というOptionを提示する。

しかしIndividualについて、

採用する。

昇進させる。

配置転換する。

解雇する。

といったHigh-impact Decisionを自律実行させない。

Human Capital Agentは、

Organization Capability Intelligence

として使う。

PersonをAlgorithmic Decisionへ圧縮しない。

⸻

Governance Agent

Governance Agentは、Decision Processそのものを確認する。

このDecisionには誰のApprovalが必要か。

Conflict of Interestはないか。

必要なRisk Reviewは完了しているか。

Board Decisionが必要か。

Regulatory Requirementはあるか。

をMachine-readable Policyから確認する。

Proposed Action
     ↓
Governance Agent
     ↓
Authority Check
Policy Check
Risk Check
     ↓
Required Approval

ここでAgent自身にApproval Authorityを持たせる必要はない。

Governance Agentは、Controlを実行可能にする支援Agentである。

⸻

AgentをGovernanceする

AI Consultant Agent自身もGovernance対象になる。

誰がAgentを起動したか。

どのClient DataへAccessしたか。

どのToolを使用したか。

どのModel Versionだったか。

何を生成したか。

誰がReviewしたか。

を記録する。

さらにToolごとにPermissionを制御する。

Agent Identity
     ↓
Authorization
     ↓
Approved Tool
     ↓
Approved Data
     ↓
Action
     ↓
Audit Log

Agentだから自由にSystemを横断できる、というArchitectureにはしない。

人間以上に明確なAccess Boundaryを設定する。

⸻

Client Dataを学習資産と混同しない

Consulting AIでは、もう一つ重要な境界がある。

Client-specific KnowledgeとReusable Consulting Knowledgeである。

あるClientから得たConfidential Dataを、別Clientへの回答へ流用してはならない。

したがって、

Public Knowledge
Internal Reusable Knowledge
Client A Private Knowledge
Client B Private Knowledge

をAccess Controlによって分離する。

どのKnowledgeが再利用可能か。

どのKnowledgeがClient Boundary内に留まるか。

をArchitectureとして管理する。

Consulting KnowledgeをAsset化することと、Confidentialityを破ることは全く別である。

⸻

Consultantの仕事はどう変わるか

AgentがData収集、比較、初期分析、Simulationを担うようになると、Consultantの役割は上流へ移る。

Information CollectionからQuestion Designへ。

Manual AnalysisからModel Selectionへ。

Slide ProductionからInterpretationへ。

Single RecommendationからTrade-off Designへ。

そして最も重要なのが、

Client Contextを理解すること

である。

同じFinancial Stateでも、企業によって選択は異なる。

History。

Culture。

Management Philosophy。

Risk Appetite。

Employee。

Customer。

Stakeholder。

これらは完全にData化できない。

Agentic Consultingの時代ほど、人間のContextual Judgmentが重要になる。

⸻

Consulting KnowledgeをSoftware Assetへ

AI Consultant Agentが継続的に利用されると、Consulting Knowledgeの蓄積方法も変わる。

優れたFramework。

Valuation Model。

Industry Ontology。

Governance Rule。

Scenario Template。

Diagnostic Logic。

これらをDocumentとして保存するだけでなく、

Reusable Consulting Asset

として実装できる。

Consulting Experience
      ↓
Knowledge
      ↓
Formalization
      ↓
Model / Rule / Agent Skill
      ↓
Reusable Asset
      ↓
Next Engagement

ただしClient固有Dataは分離する。

蓄積するのは、再利用可能なMethodとCapabilityである。

これによってConsultingは、

People × Project Time

だけに依存するBusinessから、

People × Knowledge × Software × AI

へ拡張できる。

⸻

Point ConsultingからContinuous Agentへ

Corporate Digital TwinとAI Consultant Agentを接続すると、ConsultingはProject期間だけ動くものではなくなる。

Marketが変化する。

Twinが更新される。

Agentが重要なState Changeを検出する。

Scenarioを再計算する。

ConsultantへAlertする。

ConsultantがClientと検討する。

Decisionが行われる。

その結果が再びTwinへ戻る。

Observe
 ↓
Detect
 ↓
Simulate
 ↓
Advise
 ↓
Human Decide
 ↓
Implement
 ↓
Measure
 ↓
Learn

ConsultingがContinuous Learning Loopへ変わる。

⸻

AI Consultant Agentは、ConsultantをSoftwareへ置き換える仕組みではない。

Research、Data、Model、Corporate Digital Twin、Simulationを人間のConsulting Capabilityへ接続するRuntimeである。

最小構造は、

[
\boxed{
AI
\rightarrow
Evidence
\rightarrow
Scenario
\rightarrow
Consultant
\rightarrow
Management
}
]

となる。

このArchitectureによって、大和総研のResearch KnowledgeとConsulting Knowledgeは、継続的なDecision Supportへ接続できる。

そして2050年から見ると、その先にはさらに大きな変化がある。

Consultingそのものが、一回のProjectから企業の継続的な意思決定基盤へ変わる可能性である。

次節では第Ⅲ部を統合し、そのRequirementを定義する。

2050 Decision Intelligence。
第7節　2050 Decision Intelligence

2050年のConsultingは、どのような姿になっているのか。

本書はそれを予言しない。

2050年というFuture Pointを置き、企業がその時代にも意思決定を続けるために必要となるCapabilityを逆算する。

Technologyは変わる。

AI Modelも変わる。

企業組織も変わる。

大和総研という法人や組織構造が、現在と同じ形で存在する保証もない。

それでも変わりにくいRequirementがある。

企業はRealityを観測しなければならない。

選択肢を比較しなければならない。

不確実性の中でDecisionしなければならない。

実行しなければならない。

結果から学習しなければならない。

2050 Decision Intelligenceとは、この一連のOperationを継続的に支えるArchitectureである。

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

⸻

ConsultingからDecision Intelligenceへ

従来型Consultingの基本単位はProjectである。

課題を定義する。

Dataを集める。

分析する。

Recommendationを提示する。

経営者が判断する。

Projectが終了する。

しかし企業RealityはProject終了後も変化し続ける。

Marketが変わる。

Interest Rateが変わる。

Technologyが変わる。

Regulationが変わる。

Competitorが動く。

Organizationが変わる。

Human Capabilityが変化する。

したがって2050から逆算すると、

Point-in-time Consulting

だけではなく、

Continuous Decision Intelligence

が必要になる。

Project
 ↓
Recommendation
 ↓
End

から、

Observe
 ↓
Update
 ↓
Simulate
 ↓
Advise
 ↓
Decide
 ↓
Measure
 ↓
Learn
 ↺

への転換である。

⸻

Decision Intelligenceの対象は企業全体である

Decision Intelligenceは経営Dashboardではない。

Financial KPIを表示するだけでもない。

対象になるのはEnterprise Stateそのものである。

Enterprise State
├─ Strategy
├─ Business
├─ Capital
├─ Governance
├─ Organization
├─ Human Capital
├─ Technology
├─ System
├─ Data
├─ Customer
├─ Risk
└─ External Environment

企業内部だけでも足りない。

第Ⅱ部で構築したEconomic Intelligenceを接続する。

[
Earth
\leftrightarrow
World
\leftrightarrow
Japan
\leftrightarrow
Industry
\leftrightarrow
Company
]

2050 Decision Intelligenceは、企業を外部Realityから切り離して考えない。

外部Stateの変化が企業へどう伝播するかを観測する。

⸻

Current StateからPossible Stateへ

経営者が必要としているのは、現在の説明だけではない。

「次に何を選択できるか」である。

そこでDecision Intelligenceは、

Current State

と

Possible State

を分離する。

例えば、

Current Enterprise State
         ↓
    Decision Space
  ┌────┼────┬────┐
  A    B    C    D
  ↓    ↓    ↓    ↓
Possible States

を生成する。

M&Aする。

自社投資する。

Partneringする。

撤退する。

AI Transformationを進める。

何もしない。

それぞれについて、

Return。

Risk。

Capital。

Time。

Human Capability。

Technology Requirement。

Reversibility。

Stakeholder Impact。

を比較する。

Decision Intelligenceの目的は未来を当てることではない。

選択可能な未来の構造を見えるようにすることである。

⸻

Scenario Spaceを維持する

2050年ほど先になると、Single Forecastの信頼性は低くなる。

したがって未来を一点へ固定しない。

Scenario Space
├─ Growth
├─ Stagnation
├─ Inflation
├─ Technology Acceleration
├─ Geopolitical Fragmentation
├─ Resource Constraint
└─ Regulatory Transformation

各Scenarioの中でEnterprise Stateがどう変わるかを見る。

さらにScenario同士を組み合わせる。

AIが急速に進歩する一方でEnergy Constraintが強まる可能性もある。

人口構造が変化する中でCapital Market Structureが変わる可能性もある。

未来は一変数ではない。

したがってDecision IntelligenceにはMulti-dimensional Scenario Engineが必要になる。

⸻

Corporate Digital Twinが計算空間になる

前節までに構築したCorporate Digital Twinは、Decision IntelligenceのSimulation Spaceになる。

現在Stateを保持する。

External Realityを接続する。

Decisionを入力する。

Possible Stateを生成する。

Realityとの差を検証する。

[
State_t
+
External_t
+
Decision_t
\xrightarrow{Simulation}
Possible\ State_{t+1}
]

そして実際のStateが観測されたら、

[
Possible\ State_{t+1}
\leftrightarrow
Actual\ State_{t+1}
]

を比較する。

差がLearningになる。

Digital Twinは未来を映す鏡ではない。

Decisionを検証するための計算空間である。

⸻

Multi-Agent Decision Architecture

2050 Decision Intelligenceを一つの巨大AIへ委ねる必要はない。

むしろCapabilityを分離する。

Decision Intelligence
       │
       ├─ Economic Agent
       ├─ Market Agent
       ├─ Strategy Agent
       ├─ Financial Agent
       ├─ Governance Agent
       ├─ Human Capital Agent
       ├─ Technology Agent
       ├─ Risk Agent
       └─ Simulation Agent

各Agentは異なるDataとModelを使う。

Financial Agentが高Returnと判断しても、Risk Agentが重大なExposureを検出するかもしれない。

Strategy Agentが魅力的と判断しても、Human Capital AgentがExecution Gapを示すかもしれない。

一つのAIが「正解」を生成するのではない。

複数の観測点を衝突させる。

そのDifference自体がDecision Evidenceになる。

⸻

AIの判断と人間の判断を分離する

2050年にAI Capabilityがどれほど向上しても、企業経営にはValue Judgmentが残る。

GrowthかStabilityか。

短期Returnか長期Investmentか。

効率性かResilienceか。

AutomationかEmploymentか。

Shareholder ReturnかFuture Capabilityか。

これらはDataだけから一意に決まらない。

したがってArchitectureは、

AI Observation
     ↓
Evidence
     ↓
Simulation
     ↓
Options
     ↓
Human Deliberation
     ↓
Human Decision
     ↓
Authorized Execution

とする。

Human AuthorityはAIの性能不足を補う暫定措置ではない。

Objectiveそのものを誰が決めるのかというGovernance Requirementである。

⸻

Decision Lineageを残す

2050 Decision Intelligenceでは、結果だけでなくDecisionの履歴が重要になる。

なぜそのDecisionをしたのか。

どのDataを見たのか。

どのModelを使ったのか。

どのScenarioを比較したのか。

AIは何を提案したのか。

誰が最終判断したのか。

何が実行されたのか。

結果はどうだったのか。

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

Evidence
  ↓
Model
  ↓
Scenario
  ↓
Recommendation
  ↓
Decision
  ↓
Execution
  ↓
Outcome

企業は、自分自身のDecision Historyから学習できる。

これはCorporate Memoryの中核になる。

⸻

Decision Qualityを学習する

Decision Intelligenceの価値は、Recommendationの数では測れない。

重要なのはDecision Qualityである。

しかしOutcomeが悪かったからDecisionも悪かったとは限らない。

不確実な環境では、合理的なDecisionでも悪い結果になることがある。

逆もある。

したがって、

Decision Process

と

Outcome

を分離して評価する。

当時利用可能だったEvidenceは何か。

Alternativeは検討されたか。

Riskは認識されていたか。

Assumptionは妥当だったか。

Governance Processは機能したか。

を振り返る。

これによって企業はOutcomeだけではなく、意思決定能力そのものを学習するOrganizationになる。

⸻

Consulting AssetがRuntimeになる

大和総研が長年蓄積してきたConsulting Knowledgeも、このArchitectureでは形を変える。

Framework。

Industry Knowledge。

Valuation Method。

Governance Pattern。

M&A Process。

Human Capital Method。

Scenario Model。

これらをDocumentだけで保存しない。

Consulting Knowledge
      ↓
Formalization
      ↓
Ontology / Model / Rule
      ↓
Agent Skill
      ↓
Decision Runtime

へ変換する。

Client-specific Confidential Dataは分離しながら、再利用可能なMethodをSoftware Assetへ変える。

Consulting Knowledgeが人から人へ伝承されるだけでなく、Machine-executable Capabilityとして蓄積される。

⸻

Research・Consulting・Systemが閉じる

ここで大和総研の三つのCapabilityが一つのLoopになる。

ResearchがExternal Realityを観測する。

ConsultingがDecision Spaceを設計する。

SystemがDecisionをProductionへ実装する。

そしてSystemから新しいDataが生まれる。

そのDataをResearchが再び観測する。

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

Decision Intelligenceは、このLoopの中央に位置する。

KnowledgeとImplementationを接続するIntelligenceである。

⸻

2050から2026年へ戻る

2050 Decision Intelligenceを成立させるために必要なものを、2026年へ戻してみる。

必要なのは、

Authoritative Enterprise Data。

Temporal Data Model。

Enterprise Knowledge Graph。

Research Knowledge。

Corporate Digital Twin。

Scenario Engine。

Simulation Engine。

AI Agent Runtime。

Identity。

Authorization。

Human Approval。

Audit。

Model Governance。

Decision Lineage。

である。

これらは2050年になって突然構築するものではない。

2026年から一つずつMachine-readableにしていく必要がある。

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

Future PullがEngineering Backlogへ変わる。

⸻

2050 Decision Intelligenceとは、AIが経営者に代わって企業を運営する未来ではない。

企業について観測できるものを接続する。

現在Stateを理解する。

複数のPossible StateをSimulationする。

Evidenceを保持する。

Trade-offを可視化する。

人間がDecisionする。

結果を観測する。

そして次のDecisionへ学習を戻す。

その最小構造は、

[
\boxed{
Knowledge
\rightarrow
Possible\ States
\rightarrow
Human\ Decision
\rightarrow
Reality
\rightarrow
Learning
}
]

である。

第Ⅱ部で大和総研は、日本を観測する企業としてEconomic Intelligenceへ到達した。

第Ⅲ部では、そのKnowledgeを企業のDecisionへ接続した。

しかしDecisionは、実行されなければRealityを変えない。

StrategyもCapital AllocationもGovernanceも、最終的にはProcess、Application、Database、Network、Cloud、SecurityというPhysicalな実行系へ到達する。

KnowledgeをDecisionへ変えた次に必要なのは、

DecisionをRealityへ変えること

である。

次の第Ⅳ部では、大和総研のもう一つの巨大なCapabilityへ入る。

System。

愛と敬意を込めてmandala