『大和総研』――1953年から2050年へ、リサーチ・コンサルティング・金融システム・企業システム・ヘルステック・AIを接続する次世代AI完全実装コード大全（第2回）（第Ⅰ部　History 第1章　KnowledgeとComputation――1953年から2026年まで、大和総研は何を蓄積したのか）

第Ⅰ部　History

1953年から2026年まで、大和総研はいかに形成されたのか

大和総研の歴史を、1989年8月1日の会社設立から始めるだけでは、その企業構造を十分に理解できない。

現在の大和総研につながる二つのCapabilityは、それより36年前の1953年、大和証券に設けられた調査部と機械計算部にまで遡る。

一方は、経済・金融・社会を観測し、意味を抽出するための組織だった。

もう一方は、情報を処理し、業務を計算可能にするための組織だった。

現代の言葉へ翻訳すれば、

Knowledge × Computation

である。

この二つの流れは、その後それぞれResearchとInformation Technologyとして専門化し、組織を形成し、1989年に大和総研として統合される。

したがって1989年は、すべてが始まった年ではない。

蓄積されてきたKnowledgeとComputationが、一つの企業Architectureとして接続された年である。

⸻

その後の歴史も一直線ではない。

2008年には組織が分化する。

Research・ConsultingとSystemは、それぞれの専門性と事業構造を深めていく。

そして2021年には再び統合される。

この変化を、

1953 → 1989 → 2008 → 2021 → 2026

という五つの時点で読むと、大和総研の企業史に一つの特徴が見えてくる。

それは、単純な事業拡大ではない。

分化と統合を繰り返しながらCapabilityを蓄積してきた歴史である。

ResearchはResearchのままではなかった。

Computationは機械計算のままではなかった。

Information ProcessingはSoftware Engineeringへ進み、Data Center、Cloud、Cybersecurityへ拡張した。

Researchも経済分析から金融、政策、社会、Sustainability、Data、AIへ観測領域を広げた。

Consultingが加わり、Knowledgeを企業のDecisionへ翻訳するCapabilityも形成された。

そして2026年には、AI、AX、Cloud、AI Trust、Web3、AI-driven Developmentという新しいTechnologyが、既存のCapabilityへ入り始めている。

⸻

ここで重要なのは、AIによって大和総研が突然別の企業になったわけではないということである。

むしろAIは、1953年以来存在してきた二つの流れを、より直接的に接続するTechnologyとして見ることができる。

Research ReportをAIが読み取る。

Economic DataをAIが解析する。

人間行動をAgentとしてSimulationする。

Consulting Knowledgeを検索する。

System Specificationを理解する。

Codeを生成する。

Legacy Softwareを解析・変換する。

Testを生成し、結果を検証する。

KnowledgeとComputationの境界が再び変化している。

したがって企業史は、

Knowledge → Computation → Digital → Intelligence

というTechnologyの進化としても読むことができる。

⸻

しかし本部では、現在から過去へ都合よく意味を投影しない。

1953年の機械計算部を「AIの始まり」と呼ぶことはしない。

1989年の統合を、現在のAI戦略を予見した出来事として扱うこともしない。

それぞれの時代には、それぞれのTechnology、制度、Market、経営上のRequirementがあった。

まず当時のFactを確認する。

そのうえで、

何が継承されたのか。

何が変化したのか。

何が失われ、何が再統合されたのか。

を分析する。

Historyを物語へ変えるのではなく、CapabilityのState Transitionとして読む。

⸻

そのため、本部では企業史そのものをMachine-readableにする。

例えば、

Organization

Business

Technology

Person

Product

System

Event

Time

というEntityを置く。

1953年にOrganizationが生成される。

1975年、1982年、1983年に新しい法人・機能が形成される。

1989年に複数組織が統合される。

2008年に分化する。

2021年に再統合する。

2026年に新しいOrganizationやTechnology Capabilityが追加される。

すると企業史は文章だけではなく、

Node + Relation + Event + Time

として表現できる。

これは第6節で構築するHistory Knowledge Graphへ接続する。

⸻

さらに本部の時間は、2026年で止まらない。

過去からは、

1953 → 1989 → 2008 → 2021 → 2026

と進む。

しかし同時に2050年からRequirementを引く。

1953 → 2026 ← 2050

である。

過去から見れば、2026年は70年以上のCapability蓄積の結果である。

2050年から見れば、2026年は次のArchitectureを選択できる現在地点である。

この二方向の時間を重ねることで、企業史は単なる「過去の記録」ではなくなる。

過去に何を蓄積したのかを知ることは、未来に何を再利用できるのかを知ることでもある。

⸻

第Ⅰ部では、まず1953年の二つの起点へ戻る。

そこから1989年の統合、2008年の分化、2021年の再統合を経て、2026年のAI・AX・Cloud・Trustへ進む。

そして最後に、その全履歴をKnowledge Graphへ変換する。

本書においてHistoryは、保存されるArchiveではない。

次のSystemが参照できるEnterprise Memoryである。

大和総研が何者であるかを理解するためには、現在の組織図を見るだけでは足りない。

現在の一つひとつのCapabilityが、

どこから来たのか。

それを追跡する必要がある。

第Ⅰ部は、その長い系譜を1953年から再構成する。
第1章　KnowledgeとComputation

――1953年から2026年まで、大和総研は何を蓄積したのか

第1節　1953年――調査部と機械計算部

大和総研の企業史を遡ると、1989年より前に一つの重要な地点が現れる。

1953年。

この年、大和証券に調査部と機械計算部が設置された。

現在の大和総研という企業はまだ存在していない。生成AIもCloudもInternetもない。Computerが企業活動の標準的Infrastructureになるよりはるか以前である。

しかし、この二つの組織を現在の言葉へ翻訳すると、大和総研を70年以上にわたって貫く二つのCapabilityが見えてくる。

Knowledge

と

Computation

である。

一方は、世界を理解する。

もう一方は、世界を計算可能にする。

2026年の大和総研を構成するResearch、Consulting、System、Data、AIというCapabilityは、この二つの系譜が長い時間をかけて分化し、拡張され、再接続されたものとして読むことができる。

⸻

調査部――情報をKnowledgeへ変える

証券会社にとって、調査は周辺的な業務ではない。

企業。

産業。

金融市場。

金利。

為替。

景気。

政策。

これらを理解できなければ、金融市場で起きている変化を意味のある形で捉えることができない。

しかし、Dataが存在することと、Knowledgeが存在することは同じではない。

価格が動いた。

企業業績が変化した。

政策が変更された。

金利が変わった。

それらはObservationである。

Researchには、その背後にあるRelationを考え、

「なぜ起きたのか」

「何を意味するのか」

を記述する役割がある。

そのOperationを抽象化すれば、

Observe → Collect → Analyze → Interpret → Communicate

となる。

観測する。

集める。

分析する。

意味を与える。

他者が利用可能な形へ変換する。

これがKnowledge Generationの基本構造である。

1953年の調査部は、後の大和証券経済研究所、大和総研、そして2026年の調査本部へつながっていくResearchの系譜の起点となった。

⸻

機械計算部――情報をComputationへ変える

同じ1953年に設置されたもう一つの組織が、機械計算部である。

こちらが扱う問題は異なる。

大量の情報をどう処理するのか。

取引や業務をどう正確に計算するのか。

人間の手作業をどのように機械処理へ移すのか。

情報をどの形式で表現すれば機械が処理できるのか。

そこでは、

Reality → Representation → Computation → Output

という変換が必要になる。

現実の取引や業務を、そのまま機械へ入れることはできない。

数字、記号、Record、Ruleとして表現する。

処理手順を定義する。

機械に計算させる。

結果を再び人間の業務へ戻す。

この基本構造は、Technologyが変化しても消えていない。

2026年のSoftware Engineeringでも、

Business Reality → Requirement → Data Model → Logic → Code → Runtime

という変換が行われる。

Technologyは機械計算からComputer、Database、Network、Cloud、AIへ変化した。

しかし根底には一貫して、

現実を計算可能なRepresentationへ翻訳する

というOperationが存在する。

⸻

二つの時間

1953年に生まれた二つの組織は、異なる時間を動かしていたと考えることもできる。

調査部は、

世界を理解する時間

を動かす。

機械計算部は、

世界を処理する時間

を動かす。

Researchでは、観測されたRealityから意味を抽出する。

Computationでは、Realityを形式化し、一定のRuleに従ってStateを変化させる。

したがって両者は、

Reality → Knowledge

と、

Reality → Computation

という異なるTranslationを担っていた。

この二つが後に接続される。

KnowledgeがSystem Requirementになる。

RuleがSoftwareになる。

DataがAnalysisへ戻る。

Systemから生成されたDataが新しいResearchを可能にする。

そこから、

Knowledge ↔ Computation

という循環が形成されていく。

⸻

1970年代から1980年代へ

1953年の二つのCapabilityは、その後、組織としてさらに専門化していく。

1975年には大和コンピューターサービスが設立される。

1982年には大和証券経済研究所が設立される。

1983年には大和システムサービスが設立される。

この流れを見ると、KnowledgeとComputationがそれぞれ独立した専門Capabilityへ成長していったことが分かる。

Researchは専門的な調査研究Organizationへ発展する。

Computationは企業Systemを構築・運用するInformation Technologyへ発展する。

1953年には一つの証券会社内部の部門だったCapabilityが、30年余りをかけて独立したOrganizationとBusinessへ変化した。

そして1989年、この複数の系譜が再び一つになる。

大和証券経済研究所。

大和コンピューターサービス。

大和システムサービス。

これらが統合され、株式会社大和総研が成立する。

したがって1989年を理解するためには、1953年から始まる36年間を見る必要がある。

1989年はゼロからの創業ではない。

蓄積されたCapabilityのIntegrationだったのである。

⸻

Knowledgeは蓄積される

では、Research Organizationは何を蓄積するのか。

Reportだけではない。

経済をどう観測するか。

どのDataを使うか。

どの指標を組み合わせるか。

市場変化をどう解釈するか。

政策をどの制度Contextで読むか。

過去のScenarioと結果をどう比較するか。

つまり蓄積されるのは、

Document + Data + Method + Context + Judgment

である。

これはOrganizationとしてのKnowledgeである。

しかし、その多くは長い間、人間の頭脳、Document、File、Databaseなど異なる場所に分散して保持されてきた。

2026年のAI時代から1953年を見ると、この蓄積を新しい形式で再利用できる可能性が見えてくる。

Research HistoryをKnowledge Graphへ変える。

過去のReportをVector化する。

Data SourceをLineageとして保持する。

Economic EventとResearch Interpretationを時間軸で接続する。

すると70年以上にわたるResearchは、単なるArchiveではなくMachine-readableなEnterprise Memoryへ変換できる。

⸻

Computationも蓄積される

System側にも同様の蓄積がある。

Program。

Data Model。

Business Rule。

Architecture。

Interface。

Test。

Operational Procedure。

Incident Response。

Security Control。

制度変更への対応。

Legacy Systemには、単に古いCodeが残っているのではない。

長年のBusiness RequirementとOperational Knowledgeが埋め込まれている。

だからLegacy Modernizationは単なるCode Conversionではない。

古いSoftwareの中から、

Business Knowledgeを失わずに新しいArchitectureへ移す

作業である。

大和総研がAI Agentを用いたSmartransでCode Analysis、Conversion、Verificationへ取り組んでいることも、この長期的なComputationの蓄積という文脈で読むことができる。

Softwareは消耗品であると同時に、Knowledge Assetでもある。

⸻

1953年と2026年を接続する

2026年には、1953年には存在しなかったTechnologyが揃っている。

Cloud。

Knowledge Graph。

Vector Database。

Machine Learning。

Large Language Model。

AI Agent。

Generative AI。

しかし、これらを使って解こうとしている問題の一部は、1953年にすでに存在していた二つの問いの延長上にある。

世界をどう理解するのか。

理解した世界をどう計算可能にするのか。

Researchは、

Knowledge → Digital Knowledge → Machine-readable Knowledge

へ進む。

Computationは、

Mechanical Processing → Information Processing → Software → Cloud → AI Runtime

へ進む。

そしてAIによって、二つの流れの境界が再び薄くなる。

LLMはDocumentを読み、Knowledgeを扱う。

AI AgentはKnowledgeを参照しながらSoftwareを操作する。

Coding AgentはRequirementをCodeへ翻訳する。

Simulation AgentはModelを実行し、結果をResearcherへ返す。

つまり、

Knowledge → Computation → Knowledge

というLoopをMachine自身が部分的に実行できるようになり始めた。

⸻

ただし、ここから「1953年にAI企業が始まった」と結論づけることはできない。

それは歴史を現在から逆算した物語にしてしまう。

1953年の調査部はResearchを行うために存在した。

機械計算部は当時必要だった計算・情報処理を担うために存在した。

重要なのは、当時の目的を後から書き換えることではない。

異なる時代に形成されたCapabilityの連続性を確認することである。

その意味で1953年は、大和総研のAI史の起点ではない。

より基底にある、

KnowledgeとComputationの二重系譜の起点

である。

⸻

本書では、この二つを最後まで保持する。

Researchだけを高度化しない。

Systemだけを高度化しない。

KnowledgeをMachine-readableにし、Computationへ渡す。

Computationから生成されたDataをKnowledgeへ戻す。

HumanとAIがその循環を共同で動かす。

その最小構造は、

Observe → Understand → Represent → Compute → Implement → Observe

となる。

1953年、大和証券の内部に調査部と機械計算部が置かれた。

一方は世界を知ろうとした。

もう一方は世界を処理可能な形へ変えようとした。

その二つのCapabilityが、組織を変え、Technologyを変え、分化と統合を繰り返しながら2026年まで蓄積されてきた。

大和総研の歴史を動かし始めたのは、巨大なAIでもCloudでもなかった。

調べること。

そして、

計算すること。

その二つだった。
第2節　1989年――大和総研の成立

1953年に生まれた二つの流れは、36年をかけてそれぞれ専門化した。

一方には、経済・金融・産業を調査するKnowledgeの系譜があった。

もう一方には、証券業務を情報処理し、Systemとして動かすComputationの系譜があった。

そして1989年8月1日。

大和証券経済研究所、大和コンピューターサービス、大和システムサービスの三社が統合され、株式会社大和総研が成立した。

この出来事を単なる三社合併として見るだけでは、大和総研という企業の特徴を捉えきれない。

統合されたのは法人だけではない。

ResearchとInformation Technologyという、異なるKnowledge Production Systemだったからである。

1989年は、大和総研にとって会社設立の年であると同時に、

Knowledge × Computation

が一つの企業Architectureへ統合された年だった。

⸻

三つの組織が持っていたもの

統合前の三社は、それぞれ異なる役割を担っていた。

大和証券経済研究所はResearchを担う。

大和コンピューターサービスはComputerによる情報処理の系譜を持つ。

大和システムサービスはSystemの開発・運用へつながるCapabilityを持つ。

これを現在のTechnology Languageへ翻訳すれば、

Research / Data Processing / Software & Operation

という三層に近い。

もちろん1989年当時、このような現在の用語で企業が設計されていたわけではない。

しかしCapabilityとして見るなら、大和総研の内部には設立時点から、

世界を観測する能力。

情報を処理する能力。

業務をSystemとして実装する能力。

が同居することになった。

この組み合わせが重要である。

⸻

一般にResearchとSystemでは、扱う対象も仕事の時間も異なる。

Researchは、不確実なRealityを観測する。

複数のDataから意味を抽出し、仮説を立て、変化を解釈する。

一方、Systemでは曖昧なままProductionを動かすことはできない。

Requirementを定義する。

Dataを構造化する。

RuleをLogicへ変える。

SoftwareをTestする。

Operationを安定させる。

つまり、

Research = 不確実な世界からKnowledgeを生成する

のに対して、

System = KnowledgeとRuleを実行可能な形式へ変換する

という違いがある。

1989年の大和総研は、この異なる二つのOperationを一企業の内部に持つことになった。

⸻

シンクタンクとSystem Integratorの境界

ここから、大和総研を一つのCategoryへ分類することの難しさが始まる。

シンクタンクなのか。

IT企業なのか。

System Integratorなのか。

後にConsultingも大きなCapabilityとなるため、さらに境界は曖昧になる。

しかし、この曖昧さは企業Identityの欠如ではない。

むしろ構造そのものが複合的なのである。

Researchだけなら、

Reality → Knowledge

で終わることができる。

Systemだけなら、

Requirement → Software → Operation

を中心にできる。

両方を持つ企業では、その間を接続できる。

Reality
→ Research
→ Knowledge
→ Requirement
→ System
→ Operation
→ New Reality

である。

後の大和総研を理解するうえで、このLoopは重要になる。

⸻

例えば金融制度が変化した場合を考える。

制度変更を分析する。

市場や金融機関への影響を理解する。

業務Requirementへ翻訳する。

Systemを変更する。

新しい制度に対応したServiceが顧客へ提供される。

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

そのDataが再び市場や経済の観測対象になる。

KnowledgeとSystemは、完全に別々の世界ではない。

社会の変化を挟んで循環している。

1989年の統合は、その循環を企業内部に保持できる構造を形成したと分析できる。

⸻

1989年というTechnologyの境界

1989年という時点にも意味がある。

企業情報処理は、すでに単純な機械計算の段階を越えていた。

Computerは企業活動の重要なInfrastructureとなり、金融業務では大量の取引や顧客情報をSystemで処理することが不可欠になっていた。

金融市場も高度化する。

商品が増える。

取引が高速化する。

Network化が進む。

Data量が増える。

金融とInformation TechnologyのRelationは強くなる。

したがって、大和総研の成立は単なる組織再編ではなく、

Finance × Information Technology

が急速に深く接続されていく時代の中で起きた。

Researchも同様である。

経済や金融市場を理解するためには、より多くのDataを処理する必要がある。

Knowledge ProductionそのものがComputationへ近づいていく。

ここで1953年に別々の部門として置かれた二つの能力が、一つの企業へ収束した。

⸻

Knowledgeを企業Capabilityへ変える

1989年の統合によって生まれたもう一つの重要なものは、Organizational Memoryである。

Knowledgeは個人だけに蓄積されるものではない。

Research Method。

Economic Data。

Industry Knowledge。

Financial Domain Knowledge。

System Specification。

Business Rule。

Source Code。

Operational Procedure。

Customer Requirement。

Project Experience。

これらがOrganization内部へ蓄積される。

個々のResearcherやEngineerが持つTacit Knowledgeも、Project、Document、System、Processを通じて企業Knowledgeの一部になる。

すると企業の価値は、

People

だけではなく、

People + Knowledge + System + Process

として形成される。

大和総研のその後の歴史は、この蓄積を拡大する過程でもある。

⸻

そして金融Systemでは、蓄積の効果が特に大きい。

証券業務には大量のDomain Knowledgeが存在する。

Order。

Execution。

Account。

Balance。

Settlement。

Custody。

Accounting。

Compliance。

Regulation。

これらを正しくSoftwareへ変換するには、金融KnowledgeとSystem Engineeringの双方が必要になる。

制度が変わるたびにSystemも変化する。

Systemが更新されるたびに、新しいOperational Knowledgeが蓄積される。

したがって、

Finance Knowledge → Software → Operation → New Knowledge

という循環が長期間継続する。

この蓄積が、後の金融System Platformや外部金融機関向けServiceへ展開するための基盤となっていく。

⸻

Consultingが生まれる空間

ResearchとSystemの間には、もう一つの領域がある。

Decisionである。

Researchによって世界を理解しても、企業が何をするべきかは自動的には決まらない。

Systemを構築する前には、どのBusiness Processを採用するのか、どのInvestmentを行うのか、どのOrganizationをつくるのかを決めなければならない。

つまり、

Knowledge → Decision → Implementation

という中間層が必要になる。

ここにConsultingが位置する。

後の大和総研でResearch・Consulting・Systemという三つのCapabilityが明確になっていくのは、偶然ではない。

構造的に見れば、

ResearchがUnderstandを担い、

ConsultingがDesign / Decideを担い、

SystemがImplement / Operateを担う。

1989年の統合は、この三層構造が形成される企業的な土台をつくった。

⸻

統合は完成ではない

ただし、1989年に三社が一つになったからといって、すべてのCapabilityが完全に融合したわけではない。

法人を統合することと、Knowledgeを統合することは異なる。

Organizationを一つにすることと、Business Modelを一つにすることも異なる。

ResearchにはResearchの専門性がある。

SystemにはSystemのEngineering Cultureがある。

CustomerもRevenue Modelも人材構成も異なる。

異質なCapabilityを一つの会社に持つことは、Synergyを生む可能性と同時に、複雑性も生む。

その後、大和総研は成長しながら、この複雑性と向き合うことになる。

そして2008年には、再び組織を分化させる。

つまり企業史は、

Integration → Completion

ではない。

Integration → Specialization → Reconfiguration

と進む。

1989年は最終形ではなく、一つのState Transitionだった。

⸻

2026年から振り返ると、この意味はさらに明確になる。

現在のAIはResearchとSystemの境界を再び変え始めている。

LLMはDocumentを読む。

AIはEconomic Dataを分析する。

AgentはScenarioを生成する。

Coding AgentはSpecificationからCodeを生成する。

AI AgentはLegacy Systemを解析し、変換し、Testする。

KnowledgeとSoftwareの間をMachineが移動できるようになり始めた。

しかし、そのためにはDomain Knowledgeが必要である。

Financial Knowledge。

Economic Knowledge。

Corporate Knowledge。

System Knowledge。

Operational Knowledge。

AIだけを導入しても、この蓄積は自動的には生成されない。

その意味で1989年以降に蓄積されたEnterprise Knowledgeは、AI時代に新しい価値を持つ可能性がある。

⸻

本書では1989年を、単なる「大和総研設立」として記録しない。

Machine-readableにすれば、一つの重要なIntegration Eventとして表現する。

1953
├─ Research Capability
└─ Computation Capability
       ↓ specialization
1975–1983
├─ Daiwa Computer Service
├─ Daiwa Securities Research Institute
└─ Daiwa System Service
       ↓ integration
1989
└─ Daiwa Institute of Research
  ├─ Knowledge
  ├─ Computation
  └─ System Capability

ここから企業史は次のPhaseへ入る。

一つになったCapabilityは成長し、専門性を深め、事業として拡大する。

そして規模と複雑性が増した結果、再び分化する。

1953年がKnowledgeとComputationの起点だったとすれば、

1989年は、

KnowledgeとComputationを企業として統合した起点

である。

世界を理解する能力と、世界をSystemとして処理する能力。

大和総研という企業は、この二つを同じOrganizationの内部へ置くところから成立した。

そして、その統合が完成ではなかったからこそ、次の2008年が必要になる。
第3節　2008年――分化

1989年、大和総研は大和証券経済研究所、大和コンピューターサービス、大和システムサービスの統合によって成立した。

Knowledge × Computation

を一つの企業内部に持つ構造が形成されたのである。

しかし、統合されたCapabilityは、その後同じ形のまま拡大したわけではない。

Researchは専門化する。

Consultingが成長する。

金融Systemは巨大化する。

大和証券グループ内部のITと、外部顧客へ提供するSystem Businessでは、Customer、Requirement、Risk、Revenue Modelが異なる。

一つの企業の内部に蓄積されたCapabilityが大きくなるほど、Organizationには別の設計が必要になる。

その転換点が2008年だった。

この年、大和総研は持株会社体制へ移行し、機能・事業を分化させる。

ここで重要なのは、2008年を1989年の「逆」として理解しないことである。

1989年が統合で、2008年が単純な解体だったのではない。

2008年は、

Integrationによって成長したCapabilityを、専門性と事業特性に応じて再配置したState Transition

だった。

⸻

統合の次に起きる分化

企業はCapabilityを統合すると、Synergyを得られる。

Researchで得たKnowledgeをConsultingへ利用する。

金融Domain KnowledgeをSystem Developmentへ利用する。

System Operationから得られる知見を次のServiceへ戻す。

しかし同時に、異なるCapabilityを一つのManagement Unitとして扱うComplexityも増大する。

ResearchにはResearchの評価軸がある。

ConsultingにはProject型Businessの構造がある。

Systemには大規模開発・運用、Quality、Security、Availabilityという異なるRequirementがある。

特に金融Systemでは、Softwareが単なる社内支援Toolではない。

金融Serviceそのものを成立させるProduction Infrastructureになる。

Systemの停止や誤処理は、実際の顧客や取引へ到達する。

そのため、

Knowledge Quality

と

Production Quality

では、同じ「Quality」という言葉でも意味が異なる。

ResearchではEvidence、Logic、Interpretationが重要になる。

SystemではRequirement、Correctness、Availability、Security、Operationが重要になる。

Capabilityが成熟するほど、この違いは大きくなる。

分化は、その違いをOrganizationへ反映する方法でもある。

⸻

2008年の三層構造

2008年、大和総研は持株会社体制へ移行する。

その後の構造は、大きく、

大和総研ホールディングス

大和総研

大和総研ビジネス・イノベーション

という複数法人によって形成される。

ここで、Research・ConsultingとSystem Businessは、より明確に異なる事業単位として展開されていく。

この分化をCapability Architectureとして単純化すれば、

Integrated Capability
→ Specialized Organizations

である。

一つのOrganizationに保持されていたKnowledgeを捨てるのではない。

むしろ、それぞれを深くする。

Researchを深くする。

Consultingを深くする。

金融ITを深くする。

外部向けSystem Businessを深くする。

Management Structureも、それに対応して変化する。

2008年は、統合企業が専門化のPhaseへ入った年として読むことができる。

⸻

なぜSystemは分化するのか

System BusinessにはScaleがある。

一つのApplicationをつくるだけではない。

複数のCustomer。

複数のProject。

複数のTechnology。

Development Partner。

Data Center。

Network。

Security。

Operation。

Maintenance。

制度変更。

Legacy Modernization。

これらを長期間管理する必要がある。

特に金融領域では、

Build

よりも、

Build + Operate + Change

が重要になる。

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

Marketが変わる。

法律が変わる。

金融制度が変わる。

Customer Requirementが変わる。

Technologyが変わる。

Security Threatが変わる。

したがってSystem Businessは、

Continuous Runtime Business

として成長する。

この性質は、ResearchやConsultingとは異なるOrganization Designを要求する。

2008年の分化は、大和総研内部でSystem Capabilityが十分な規模と専門性を持つBusinessへ成長したことの裏返しでもあった。

⸻

外部市場へ向かうCapability

もう一つ重要なのは、大和証券グループ内部で蓄積したSystem Knowledgeを、外部顧客へ展開する方向である。

金融機関向けSystem。

一般企業向けSolution。

IT Infrastructure。

Outsourcing。

それぞれでは、大和証券固有のRequirementだけを扱うのではない。

複数顧客に共通するProblemを発見し、

共通化できるFunctionを抽出し、

再利用可能なArchitectureへ変える必要がある。

ここでSystem Developmentは、

Individual Project

から、

Reusable Capability

へ進む。

金融Systemであれば、

Customer-specific Knowledge
→ Common Domain Knowledge
→ Standardization
→ Shared Platform

という変換が可能になる。

後のFinancial Plateなどに見られるPlatform型Businessを理解するうえでも、この視点は重要である。

大和証券グループのProduction Environmentで蓄積するCapabilityと、外部市場へ展開するCapability。

両者は同一ではないが、Knowledgeを共有できる。

この二重構造が、大和総研のSystem Businessを形成していく。

⸻

Researchも外へ広がる

分化はSystemだけの話ではない。

Researchもまた、より広い観測Scaleへ向かう。

日本経済。

Global Economy。

金融・資本市場。

政策。

財政。

社会保障。

企業。

Sustainability。

Research Organizationが扱う対象は拡張していく。

2009年にはNew YorkとLondonにResearch拠点が設けられ、世界から日本を見るObservation Capabilityも強化されていく。

ここでは、

Japan → World

ではなく、

World → Japan

という観測方向が加わる。

Global Economyの変化を観測し、それが日本のEconomy、Finance、Companyへどのように到達するかを分析する。

ResearchそのものがMulti-scale化していく。

⸻

分化によってKnowledgeはどうなるのか

しかしOrganizationを分けると、新しい問題が生まれる。

Knowledge Fragmentationである。

ResearcherはResearch Knowledgeを蓄積する。

ConsultantはClient ProjectのKnowledgeを蓄積する。

EngineerはSystem Knowledgeを蓄積する。

OperatorはProduction Knowledgeを蓄積する。

それぞれの専門性は深くなる。

一方で、

Researchで得たKnowledgeがSystemへ届かない。

Systemで得たDataがResearchへ戻らない。

Consultingで生まれたDecision Logicが再利用されない。

同じCustomerを異なるOrganizationが異なるData Modelで理解する。

という問題が起こり得る。

これは大和総研だけに固有の問題ではない。

専門化した大企業が一般に直面するArchitecture上の問題である。

Specialization increases depth.
Specialization also increases boundaries.

専門化はDepthを生む。

同時にBoundaryを生む。

このTrade-offをどう扱うかが、次の企業Architectureの課題になる。

⸻

OrganizationとKnowledgeを分けて考える

ここで重要な原則が得られる。

Organizationを分けることと、Knowledgeまで分断することは同じではない。

異なるOrganizationが存在しても、共通Identityを持つことはできる。

共通Data Definitionを持てる。

APIで接続できる。

Eventを共有できる。

Knowledge GraphでRelationを保持できる。

2026年のTechnologyから見れば、

Organizational Separation ≠ Information Separation

である。

むしろ、専門Organizationを保持したままDataとKnowledgeを接続することが可能になる。

これは後に本書で構築するDigital Twin Architectureの重要な原則となる。

⸻

分化は失敗ではない

2021年に再統合が行われたという結果だけを知っていると、2008年の分化を一時的な遠回りとして理解しやすい。

しかし、その読み方では企業史の重要な部分を失う。

分化した期間に、それぞれのCapabilityは専門性を蓄積した。

Research。

Consulting。

Financial System。

Enterprise System。

Infrastructure。

Outsourcing。

Data。

それぞれが異なるCustomer、Project、Technology、Operationを経験する。

その蓄積がなければ、後の再統合も単なる1989年への回帰になってしまう。

しかし2021年の統合は、1989年と同じ状態へ戻ったわけではない。

より多くのCapabilityを持った状態で統合された。

したがって企業史は、

Integration → Separation → Reintegration

という単純な往復ではなく、

Integration → Specialization → Reintegration at a Higher Capability Level

として読む方が正確である。

⸻

Machine-readableに表現すれば、2008年は一つのSplit Eventになる。

1989
Integrated DIR
├─ Research
├─ Consulting
└─ System
       ↓ growth / specialization
2008
Group Structure
├─ Holding / Management
├─ Research & Consulting
└─ System / Business Innovation
       ↓ independent capability accumulation
2008–2021
├─ Deeper Research Knowledge
├─ Deeper Consulting Knowledge
├─ Deeper Financial IT
├─ Deeper Enterprise IT
├─ Infrastructure
└─ External Business

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

Split前後で、どのCapabilityがどこへ移動し、何を蓄積したかである。

企業史をKnowledge Graphにするときも、法人名だけをNodeにしては足りない。

Organization × Capability × Business × Technology × Time

を接続する必要がある。

⸻

2008年は、大和総研が一つであることをやめた年としてだけ見るべきではない。

一つの内部に存在していたCapabilityが、それぞれの専門領域で深く成長するために、Organization Structureを変えた年である。

1989年には、

KnowledgeとComputationを統合した。

2008年には、

統合されたCapabilityを分化させた。

そして分化した13年間の蓄積を経て、2021年にもう一度問いが現れる。

Research。

Consulting。

System。

Data。

Technology。

これらを、再び一つの企業として接続する意味は何か。

次の統合は、1989年へ戻るためのものではない。

分化によって獲得した専門性を保持したまま、もう一度接続するための統合となる。
第4節　2021年――再統合

2008年、大和総研は分化した。

Research・ConsultingとSystemは、それぞれのOrganizationとBusinessの中で専門性を深めていった。

そして13年後の2021年。

大和総研ホールディングス、大和総研、大和総研ビジネス・イノベーションの三社が合併し、株式会社大和総研として再統合された。

1989年に続く、もう一つのIntegrationである。

しかし2021年の再統合を、2008年以前への回帰として理解してはならない。

13年間の分化によって、各Capabilityは以前より大きく、深く、複雑になっていた。

Research。

Consulting。

Financial System。

Enterprise System。

Infrastructure。

Data。

Outsourcing。

そしてDigital Technology。

2021年に統合されたのは、1989年と同じCapabilityではない。

専門化によって拡張された複数のCapabilityだった。

したがって2021年は、

Reintegration at a Higher Capability Level

として読む必要がある。

⸻

分化したものを、なぜ再び接続するのか

専門化には大きな利点がある。

ResearcherはResearchへ集中できる。

ConsultantはCorporate Decisionへ集中できる。

EngineerはSystem Developmentへ集中できる。

Infrastructure SpecialistはProduction Environmentへ集中できる。

それぞれのDomain Knowledgeが深くなる。

しかし社会や企業が直面するProblemは、反対方向へ進んでいた。

複雑になったのである。

例えば企業のDigital Transformationは、Systemだけの問題ではない。

Business Strategyが必要になる。

Organization改革が必要になる。

Data Architectureが必要になる。

Cloudが必要になる。

Securityが必要になる。

Human Capitalが必要になる。

そしてTechnology InvestmentをCorporate Valueへ接続する必要がある。

つまりClientのProblemそのものが、

Strategy × Organization × Data × Technology × System

へ拡張する。

専門Capabilityを個別に提供するだけでは、Problem全体を扱いにくくなる。

⸻

金融も同様である。

金融制度を理解する。

Marketを分析する。

Customer Behaviorを理解する。

Business Processを設計する。

Regulationへ対応する。

Systemを構築する。

Cybersecurityを維持する。

Dataを分析する。

Digital Serviceを改善する。

これらは別々の専門領域である。

しかし顧客から見れば、一つのFinancial Serviceとして動かなければならない。

社会が統合されたProblemを持つなら、企業側にも専門性を保持しながら接続するCapabilityが必要になる。

2021年の再統合は、そのためのOrganization Architectureとして読むことができる。

⸻

Research・Consulting・Systemを再び一つへ

再統合後の大和総研が公式に強みとして示すのが、

Research

Consulting

System

の連携である。

この三つは、単なるService Portfolioではない。

一つのProblem Solving Processとして接続できる。

Researchは、

What is happening?

を扱う。

Consultingは、

What should we do?

を扱う。

Systemは、

How do we implement and operate it?

を扱う。

したがって、

Observe → Understand → Design → Implement → Operate

という連続したOperationになる。

2021年の再統合によって、このOperationを同一企業内部で再び構成するOrganization上の条件が整えられた。

⸻

ここで大和総研のMissionにある「提案・実行」という言葉が重要になる。

シンクタンクであれば、提言まででも役割は成立する。

Consultingであれば、StrategyやTransformation Planの策定までを中心にすることもできる。

しかし「実行」まで含めるなら、System Capabilityの意味が変わる。

分析する。

提案する。

設計する。

Softwareを構築する。

Productionで動かす。

継続的に更新する。

つまり、

Knowledge → Proposal → Implementation → Runtime

まで到達する。

2021年の再統合によって、「提案」と「実行」を一つの企業内部で接続できる構造が再び強くなる。

⸻

1989年と2021年は何が違うのか

二つのIntegrationを比較すると、大和総研の変化が見える。

1989年に統合された中心は、

Research + Computer / System

だった。

2021年には、その間に多くのCapabilityが形成されている。

Consulting。

Financial Platform。

Enterprise Solution。

Data Analytics。

Cloud。

Security。

Outsourcing。

Health-related System。

Digital Transformation。

つまり、

1989
Knowledge × Computation

から、

2021
Research × Consulting × System × Data × Digital

へ拡張している。

同じ「統合」でも、その内部状態は異なる。

企業史を法人の統合・分割だけで見ると、この違いを捉えられない。

見るべきなのはCapability Stateである。

⸻

再統合の後にAIが来る

そして2021年という時点は、Technology史の観点からも重要だった。

その直後、生成AIが急速に社会実装される。

Large Language Model。

Generative AI。

RAG。

Coding Agent。

AI Agent。

Multimodal Model。

これらのTechnologyは、従来別々だったKnowledge WorkとSoftware Engineeringの境界を変え始める。

Documentを読むAI。

Reportを書くAI。

Dataを分析するAI。

Scenarioを生成するAI。

Requirementを整理するAI。

Codeを書くAI。

TestするAI。

System Operationを支援するAI。

つまり2021年にOrganizationとして再統合されたResearch・Consulting・Systemの間を、数年後にはAIがTechnologyとして横断し始める。

これは重要な時間的連続である。

ただし、2021年の再統合が生成AIの到来を予測して行われた、と解釈する必要はない。

そうではなく、

再統合された企業Architectureと、その後急速に発展したAI Technologyの相性が高い

のである。

⸻

AIは第四の箱ではない

ここから2026年の大和総研の特徴が見えてくる。

AIを独立した第四事業として、

Research / Consulting / System / AI

と並べるだけでは十分ではない。

AIはむしろ、

Research × AI

Consulting × AI

System × AI

として既存Capabilityへ浸透する。

Researchでは、Data Analysis、Report Generation、Economic Agent Simulationへ使われる。

Consultingでは、Knowledge Retrieval、Corporate Data Analysis、Scenario Generationへ拡張できる。

Systemでは、Coding Agent、Legacy Modernization、Testing、Operation Supportへ入る。

Infrastructureでは、AIを安全にProductionで利用するためのTrust Architectureが必要になる。

つまりAIは、2021年に再接続されたCapability間をさらに接続するHorizontal Technologyとして位置づけられる。

⸻

法人統合からKnowledge統合へ

しかし、ここには次の課題がある。

三社を一法人へ統合しても、Knowledgeが自動的に統合されるわけではない。

Research ReportはResearchのRepositoryにある。

Consulting KnowledgeはProject Documentにある。

System KnowledgeはSpecificationやSource Codeにある。

Operation KnowledgeはRunbookやLogにある。

Customer Dataは個別Systemにある。

Security上、接続してはならないDataも存在する。

したがって次に必要になるのは、単純なData Centralizationではない。

Governed Knowledge Integrationである。

何を共有できるのか。

誰がアクセスできるのか。

どのSourceがAuthoritativeなのか。

どこから生成されたDataなのか。

AIが何を参照してよいのか。

どのOperationにはHuman Approvalが必要なのか。

これらをArchitectureとして定義する必要がある。

⸻

2021年の再統合を2026年から見ると、

Legal Integration

の次に、

Data Integration

Knowledge Integration

AI Integration

という課題が続いていることが分かる。

企業を一つにする。

Dataを接続する。

KnowledgeをMachine-readableにする。

AIが安全に利用できるようにする。

そして複数Capabilityを一つのRuntimeとして動かす。

再統合は終了点ではなく、この長いIntegration Processの一段階なのである。

⸻

再統合された企業をMachine-readableにする

本書では、2021年を一つのMerge Eventとして記述する。

2008
Specialized Group Structure
├─ Holding / Management
├─ Research & Consulting
└─ System / Business Innovation
       ↓ capability accumulation
2008–2021
├─ Research
├─ Consulting
├─ Financial System
├─ Enterprise System
├─ Infrastructure
├─ Data
└─ Digital Capability
       ↓ reintegration
2021
Daiwa Institute of Research
├─ Research
├─ Consulting
├─ System
├─ Data
└─ Digital
       ↓ AI expansion
2021–2026
Research × Consulting × System × AI

この表現で重要なのは、2008年以前へ戻っていないことである。

Stateは、

A → B → A

ではない。

A → B → C

である。

分化を通じて蓄積されたCapabilityを保持したまま、新しい統合状態へ移った。

⸻

そして、このState Transitionは大和総研の企業史全体を読むための重要なPatternを示す。

1953年。

KnowledgeとComputationが二つの起点として生まれる。

1989年。

それらが企業として統合される。

2008年。

統合されたCapabilityが専門化のために分化する。

2021年。

専門化によって蓄積されたCapabilityが再統合される。

そして2026年。

AI、AX、Cloud、Trustという新しいTechnology Layerが、その統合構造へ入り始める。

したがって、

1953
Knowledge + Computation

↓

1989
Integration

↓

2008
Specialization

↓

2021
Reintegration

↓

2026
Intelligence

という企業史が見えてくる。

2021年に大和総研は、過去へ戻ったのではない。

分化によって深くなったKnowledgeを持ったまま、次のTechnologyを受け入れられる一つのOrganizationへ再構成された。

そのわずか数年後、生成AIがKnowledgeとComputationの境界そのものを変え始める。

2021年の再統合は、その意味で、1953年から続いてきた二つの流れがIntelligenceの時代へ入る直前の企業Architectureだったのである。
第5節　2026年――AI・AX・Cloud・Trust

2021年、大和総研は再統合された。

その5年後の2026年、大和総研のOrganizationには次の変化が現れている。

AI。

AX。

Cloud。

Trust。

これらは独立した四つの流行語ではない。

Research・Consulting・Systemという既存Capabilityが、生成AI時代のEnterprise Architectureへ移行する過程で必要になった四つの要素として読むことができる。

2026年4月1日の組織改正では、フロンティア研究開発センターにWeb3ビジネス開発室が新設され、CoE推進室はイノベーション企画部へ改称された。企業システム事業本部にはAX本部が新設され、大和証券システム本部には価値創造推進室が置かれた。基盤ソリューション本部では、基盤システム開発第一部がクラウド基盤開発部へ、第二部がAIトラスト基盤開発部へ改称された。

組織図そのものに、

AI-driven Transformation

Cloud Infrastructure

AI Trust

Innovation

が現れ始めている。

これは、大和総研の企業史における次のState Transitionである。

⸻

AI――KnowledgeとComputationの再接続

AIは、大和総研にとって突然現れた第四の事業ではない。

2026年の大和総研では、AIに関するCapabilityが複数のOrganizationへ分散している。

フロンティア研究開発センターでは、AI・Data Science・先端Technologyを研究し、Businessへ接続する。

企業システム事業本部では、AXという形でAIを企業Transformationへ接続する。

大和証券システム本部では、生成AIを実際の金融BusinessやSystem Developmentへ適用する。

基盤ソリューション本部では、AIを安全に動かすためのTrust Infrastructureが必要になる。

HealthTechでは、DataとAIを健康・予防へ利用する。

Researchでは、生成AIが経済分析やSimulationそのものへ入り始めている。

したがって2026年のAIは、

AI Department

ではなく、

AI as Horizontal Capability

として理解する方が正確である。

⸻

その象徴的な事例の一つが、生成AI Agentによる経済Simulationである。

大和総研は、個人調査Dataから約2,500のPersonaを構成し、経済指標などを与えながら生成AIに物価見通しを回答させる研究を行っている。

ここでAIが扱っているのは、単純な文章生成ではない。

Individual Agent → Collective Response → Macro Indicator

というMicroからMacroへのSimulationである。

一人ひとりの異なる属性を持つAgentを生成し、その集合から社会経済的な状態を観測する。

これはResearchのOperationを、

Analyze the past

だけから、

Simulate possible states

へ拡張する可能性を示す。

ResearchとComputationが、AIによって再び直接接続され始めている。

⸻

AX――AIをTransformationへ変える

しかしAI Modelを利用するだけでは、企業は変わらない。

Chatbotを導入する。

Documentを要約する。

Codeを生成する。

それだけでは局所的なProductivity Improvementにとどまる可能性がある。

必要なのは、

Business ProcessそのものをAI前提で再設計すること

である。

2026年、大和総研は企業システム事業本部にAX本部を新設した。

AXを本書では、単なるAI導入ではなく、

AI Transformation

として読む。

業務を分解する。

人間が行うOperationを特定する。

AIが支援できるOperationを特定する。

Data Accessを設計する。

Agentへ与えるAuthorityを定義する。

Human Approval Pointを設定する。

Systemへ接続する。

実行結果をMonitorする。

そしてBusiness Processそのものを更新する。

つまり、

AI Adoption → Process Redesign → System Integration → Organizational Transformation

である。

AIをToolとして使う段階から、企業Architectureへ組み込む段階への移行である。

⸻

AI駆動開発――Software Engineeringそのものを変える

AXはBusiness側だけで起きるものではない。

Software Engineering自身もAIによって変化する。

2026年の大和総研では、Coding AgentをRequirements、Design、Implementation、Testingへ適用するAI駆動開発が進められている。

従来のSoftware Developmentは、

Human → Specification → Code

を基本としていた。

AI Agentが入ると、

Human ↔ AI Agent → Software

へ変化する。

人間はすべてのCodeを直接書く存在から、

Requirementを定義する。

Architectureを判断する。

AI OutputをReviewする。

Riskを評価する。

ProductionへのDeploymentを承認する。

という役割へ移る。

これは単なるCoding Automationではない。

Software Production Modelの変更である。

⸻

そのさらに具体的な事例がSmartransである。

Smartransでは、AI Agentを利用してLegacy Systemを解析し、Codeを変換し、検証を繰り返す。

既存Code。

Dependency。

Business Logic。

Test Data。

新旧Systemの整合性。

これらを扱いながらModernizationを進める。

ここで重要なのは、生成AIがCodeを書けることではない。

Legacy System内部に蓄積されたBusiness Knowledgeを失わずに、新しいTechnologyへ移行する必要があることである。

したがって、

Legacy Code → Analysis → Transformation → Verification → Modernized System

というLoopになる。

2026年には、このAI Agentによる反復的なCode Conversionと新旧整合性検証に関する技術が特許化されている。

KnowledgeがAlgorithmになり、

AlgorithmがSoftwareになり、

SoftwareがIntellectual Propertyになる。

これは、

Project Knowledge → Reusable Software Asset

への転換を示す重要な事例である。

⸻

Cloud――AI時代の実行基盤

AIが企業Capabilityになれば、その実行場所が必要になる。

ここでCloudの意味が変わる。

Cloudは単にServerを外部Data Centerへ移すTechnologyではない。

Compute。

Storage。

Database。

Network。

Identity。

Security。

Observability。

AI Model。

API。

Event。

これらをSoftwareとして組み合わせる実行基盤である。

大和総研はAWS、Google Cloud、Microsoft Azure、Oracle Cloudなど複数のCloud EcosystemとのCapabilityを持ち、2025年にはMulti-cloudとBusiness Resilienceを支援するD-Suiteを開始している。

2026年には基盤ソリューション本部にクラウド基盤開発部という名称が明示された。

これはInfrastructureが、

Physical Infrastructure

から、

Programmable Infrastructure

へ移行していることを示す。

本書ではこの方向をさらに進め、

Infrastructure as Code

として扱う。

NetworkもSecurity PolicyもCompute Environmentも、可能な範囲でCodeとしてVersion管理する。

System ArchitectureとInfrastructure Architectureを分離しない。

⸻

Trust――AIをProductionへ入れる条件

そして2026年を特徴づける最も重要な言葉の一つが、Trustである。

生成AIのPrototypeをつくることと、金融・企業・HealthcareのProductionでAIを動かすことは同じではない。

Productionでは、

誰が利用しているのか。

どのDataへAccessできるのか。

どのModelを利用したのか。

何を出力したのか。

その出力を誰が承認したのか。

問題が起きた場合に停止できるのか。

過去のOperationをAuditできるのか。

を管理しなければならない。

したがってAI Runtimeには、

**Identity

* Authentication
* Authorization
* Data Governance
* Privacy
* Security
* Monitoring
* Audit
* Human Approval
* Rollback**

が必要になる。

2026年に基盤ソリューション本部の組織名称としてAIトラスト基盤開発部が現れたことは象徴的である。

AIの価値がModelの性能だけでは決まらない時代へ入っている。

AI Capability × Trust

によって初めてEnterprise Productionへ接続できる。

⸻

この考え方は、大和総研がすでに整備してきたAI Governanceとも接続する。

AI倫理ガイドライン。

AI倫理委員会。

Privacy。

Security。

Transparency。

Accountability。

Human-centered AI。

Human Judgment。

これらをPolicy Documentだけで終わらせてはならない。

本書では、

Policy → Architecture → Code → Runtime

へ翻訳する。

例えば「人間が重要な判断へ関与する」という原則があるなら、それを文章として記載するだけではない。

System ArchitectureにHuman Approval Nodeを置く。

Execution APIはApproval Tokenがなければ実行できない。

AgentのActionをAudit Logへ保存する。

権限外のData Accessを拒否する。

異常が発生すればRollbackする。

GovernanceをSoftwareとして実装する。

それがTrust Architectureである。

⸻

AI・AX・Cloud・Trustは一つの構造である

ここまでの四つを接続すると、2026年の変化が見えてくる。

AIがIntelligenceを生成する。

AXがそのIntelligenceをBusiness Processへ組み込む。

Cloudが実行基盤を提供する。

Trustが安全性・権限・責任を保持する。

すなわち、

AI
↓
AX
↓
Cloud
↓
Trust

ではない。

実際には、

AI × AX × Cloud × Trust

である。

どれか一つだけではEnterprise AIは成立しない。

高性能なAIがあってもBusiness Processへ接続されなければ価値は限定される。

AXを進めてもExecution InfrastructureがなければScaleしない。

CloudがあってもTrustがなければ高影響領域へ安全に展開できない。

TrustだけあってもIntelligenceを生むAIがなければTransformationは起きない。

四つは相互依存している。

⸻

1953年から2026年へ

ここで70年以上の時間を再び接続する。

1953年。

Knowledge + Computation

1989年。

Integration

2008年。

Specialization

2021年。

Reintegration

2026年。

AI + AX + Cloud + Trust

である。

しかし最後の四つも、それまでの歴史から切断されたものではない。

AIはKnowledgeとComputationを接続する。

AXはKnowledgeをBusiness Operationへ変える。

CloudはComputationをScaleさせる。

TrustはSystemを社会の中で安全に動かす。

したがって2026年は、

Knowledge × Computation

が、

Intelligence × Transformation × Runtime × Trust

へ拡張した状態として読むことができる。

⸻

そして次の問いが生まれる。

70年以上にわたるResearch Report。

Economic Data。

Consulting Knowledge。

Financial Domain Knowledge。

System Specification。

Source Code。

Operational Knowledge。

AI Model。

これらは、大和総研という企業の中に大量に蓄積されている。

しかし、蓄積されていることと、接続されていることは同じではない。

AI時代に本当に重要なのは、これらをMachineが安全に利用できるEnterprise Memoryへ変換できるかどうかである。

そのためには、企業史そのものからMachine-readableにする必要がある。

どのOrganizationがいつ存在したのか。

どのCapabilityがどこから生まれたのか。

どのSystemがどのBusinessを支えたのか。

どのTechnologyがいつ導入されたのか。

どの統合と分化を経て現在に到達したのか。

それを、

Node + Relation + Event + Time

として記述する。

2026年、大和総研はAIを使い始めた会社なのではない。

1953年以来蓄積してきたKnowledgeとComputationを、AI・AX・Cloud・Trustによって新しいEnterprise Architectureへ翻訳できる地点に到達した会社として見ることができる。

次に必要なのは、その70年以上の時間を、Machineが読めるKnowledgeへ変えることである。
第6節　企業史をKnowledge Graphにする

企業史は、通常、文章として保存される。

1953年に何が起きたのか。

1989年にどの会社が統合されたのか。

2008年になぜ組織が分化したのか。

2021年に何が再統合されたのか。

2026年にどのOrganizationが新設されたのか。

人間が読むのであれば、年表と文章で十分である。

しかし本書の目的は、大和総研の歴史を説明することだけではない。

70年以上にわたって蓄積された企業史を、後のAI、Simulation、Digital Twinが利用できるMachine-readable Enterprise Memoryへ変換する。

そのために必要になるのが、

Knowledge Graph

である。

⸻

年表からGraphへ

単純な企業年表は、時間順にEventを並べる。

1953  調査部・機械計算部
1975  大和コンピューターサービス
1982  大和証券経済研究所
1983  大和システムサービス
1989  大和総研
2008  分化
2021  再統合
2026  AI・AX・Cloud・Trust

これはHistoryを理解するには有効である。

しかしMachineが、

「2026年のAI Capabilityは、過去のどのCapabilityと接続しているのか」

「1989年の統合対象は何だったのか」

「2008年の分化後、System CapabilityはどのOrganizationへ移ったのか」

と問われても、年表だけではRelationが十分に記述されていない。

必要なのは、

何が存在し、何と何が関係し、いつその関係が変化したのか

を表現することである。

そこで企業史を、

Node + Edge + Event + Time

へ分解する。

⸻

Node――企業史を構成する存在

最初にEntityを定義する。

例えば、

Company

Organization

Person

Capability

Business

Product

System

Technology

Document

Event

Time

である。

「大和総研」はCompany Nodeになる。

「調査本部」はOrganization Nodeになる。

「Research」はCapability Nodeになる。

「Financial Plate」はProduct / System Nodeとして表現できる。

「AI」はTechnology Nodeである。

「2021年の三社合併」はEvent Nodeになる。

重要なのは、文章の中で同じ対象を毎回別の言葉として扱わないことである。

それぞれに一意のEntity IDを与える。

するとMachineは、複数Documentに登場する「大和総研」が同一Entityであることを追跡できる。

⸻

Edge――Relationを記述する

NodeだけではKnowledgeにならない。

重要なのはRelationである。

例えば、

Daiwa Institute of Research
   HAS_CAPABILITY
Research

と記述する。

さらに、

Research
   ORIGINATES_FROM
Research Department_1953

と接続する。

System側も、

System Capability
   ORIGINATES_FROM
Mechanical Calculation Department_1953

と記述できる。

1989年については、

DSRI ─┐
DCC  ─┼─ MERGED_INTO → DIR
DSS  ─┘

となる。

こうすると「1989年に大和総研へ統合されたOrganizationは何か」というQueryへMachineが回答できる。

企業史が文章からQueryable Knowledgeへ変わる。

⸻

Event――変化そのものをEntityにする

企業史では、存在だけでなく変化が重要である。

設立。

統合。

分割。

新設。

廃止。

改称。

移管。

Product Launch。

Technology Adoption。

これらを単なる文章ではなくEventとして保持する。

例えば2021年の再統合は、

Event:
 type: MERGER
 date: 2021
 inputs:
   - Daiwa Institute of Research Holdings
   - Daiwa Institute of Research
   - Daiwa Institute of Research Business Innovation
 output:
   - Daiwa Institute of Research

と表現できる。

2026年4月1日の組織改正も、

CREATE  AX Headquarters
CREATE  Web3 Business Development Office
CREATE  Value Creation Promotion Office
RENAME  CoE Promotion Office
    -> Innovation Planning Department
RENAME  Infrastructure System Development Dept. 1
    -> Cloud Infrastructure Development Department
RENAME  Infrastructure System Development Dept. 2
    -> AI Trust Infrastructure Development Department

というState Transitionとして保持できる。

Historyとは、固定されたOrganization Chartの集合ではない。

Organization StateがEventによって変化する過程なのである。

⸻

Time――「現在」を上書きしない

企業Data Architectureで頻繁に起きる問題が、現在の状態だけを保存して過去を失うことである。

Departmentが改称された。

DatabaseのDepartment Nameを新名称へ書き換える。

すると、過去のDocumentに記載されていた旧OrganizationとのRelationが分からなくなる。

Digital Twinでは、この方法を採らない。

例えばOrganizationに、

valid_from

valid_to

を持たせる。

すると、

Organization A
valid_from: 2021-04-01
valid_to:   2026-03-31
Organization B
valid_from: 2026-04-01
valid_to:   NULL

のように表現できる。

現在Stateを更新しながら、過去Stateを消さない。

これによって、

2024年時点の大和総研のOrganizationを再構成する

というQueryが可能になる。

企業史はArchiveではなく、Temporal Data Modelになる。

⸻

CapabilityはOrganizationと分離する

さらに重要なのは、

Organization ≠ Capability

という原則である。

Organizationは変わる。

Department Nameも変わる。

法人も統合・分割される。

しかしCapabilityは、別のOrganizationへ継承されることがある。

1953年の機械計算部は2026年には存在しない。

しかしComputationのCapabilityが消えたわけではない。

Information Processing。

System Development。

Cloud。

AI Runtime。

へ変化している。

したがってGraphでは、

Mechanical Computation
       ↓ EVOLVES_INTO
Information Processing
       ↓
System Engineering
       ↓
Cloud Computing
       ↓
AI Runtime

のようにCapability EvolutionをOrganization Historyとは別に記述する。

これによって、

会社の名前ではなく、能力の系譜

を追跡できる。

これは2050 Future Pullで特に重要になる。

2050年に現在と同じOrganizationが存在する保証はない。

しかし必要なCapabilityは議論できるからである。

⸻

FactとAnalysisを分離する

ただし、ここで重大な問題がある。

「1953年の機械計算部が2026年のAI Runtimeへ進化した」という表現は、公式資料にそのまま書かれているFactではない。

本書によるAnalysisである。

したがってKnowledge Graphでも両者を混ぜない。

例えば、

Statement
type: FACT
source: official_history

と、

Statement
type: ANALYSIS
author: book_model

を区別する。

さらに、

FACT

INFERENCE

SCENARIO

RECOMMENDATION

というKnowledge Typeを持たせる。

するとAIは、

「これは一次資料で確認されたFactか」

「本書による構造分析か」

「2050年Scenarioか」

を区別できる。

生成AI時代には、この区別が極めて重要になる。

もっともらしい文章と、確認されたFactは同じではない。

⸻

SourceとLineageをGraphに残す

すべてのFactにはSourceを持たせる。

Corporate Website。

Organization Reform Document。

Financial Statement。

Research Report。

Press Release。

Patent Information。

Product Documentation。

さらに、

source_id

published_at

retrieved_at

valid_from

valid_to

version

authority

を保持する。

例えば、

Fact
├─ SUBJECT: AX Headquarters
├─ PREDICATE: CREATED_ON
├─ OBJECT: 2026-04-01
└─ SOURCE: Organization Reform 2026-03-19

とする。

これによってAIが回答するとき、

「AX本部はいつ新設されたか」

だけでなく、

「そのFactは何を根拠としているか」

まで返せる。

AnswerだけではなくEvidenceを返すAI

を設計できる。

⸻

SQLとGraphを組み合わせる

すべてをGraph Databaseへ入れる必要はない。

Company ID。

Organization ID。

Date。

Financial Data。

Employee Count。

Revenue。

これらはRelational Databaseで管理した方が扱いやすい。

一方、

Organization AがOrganization Bへ統合された。

PersonがOrganizationへ所属した。

ProductがCapabilityを利用する。

SystemがBusinessを支える。

TechnologyがProductへ実装される。

という多対多RelationはGraphに向いている。

したがって、

SQL = Authoritative State

Graph = Relation

という役割分担を基本とする。

さらに文章そのものはVector Storeへ保持する。

Vector = Semantic Memory

である。

つまり、

SQL + Knowledge Graph + Vector

の三層を組み合わせる。

⸻

最小Schemaを実装する

この段階では、まだ巨大なSystemは必要ない。

最小構造から始める。

from dataclasses import dataclass
from datetime import date
from enum import Enum
class KnowledgeType(Enum):
   FACT = "fact"
   ANALYSIS = "analysis"
   SCENARIO = "scenario"
   RECOMMENDATION = "recommendation"
@dataclass
class Entity:
   entity_id: str
   entity_type: str
   name: str
@dataclass
class Relation:
   subject_id: str
   predicate: str
   object_id: str
   valid_from: date | None = None
   valid_to: date | None = None
   knowledge_type: KnowledgeType = KnowledgeType.FACT
   source_id: str | None = None

この小さなModelだけでも、

誰が。

何と。

どのようなRelationを持ち。

いつ有効で。

それがFactなのかAnalysisなのか。

Sourceは何か。

を保持できる。

ここから企業史を一つずつGraphへ変換していく。

⸻

例えば1953年から2026年までを概念的に登録する。

history = [
   ("1953_research", "ORIGIN_OF", "research_capability"),
   ("1953_computation", "ORIGIN_OF", "computation_capability"),
   ("1989_dir", "INTEGRATES", "research_capability"),
   ("1989_dir", "INTEGRATES", "computation_capability"),
   ("2008_split", "TRANSFORMS", "1989_dir"),
   ("2021_reintegration", "REINTEGRATES", "specialized_capabilities"),
   ("2026_ai", "EXTENDS", "research_capability"),
   ("2026_ax", "EXTENDS", "consulting_system_capability"),
   ("2026_cloud", "EXTENDS", "infrastructure_capability"),
   ("2026_trust", "GOVERNS", "ai_runtime"),
]

ここで注意すべきなのは、これがそのままFact Databaseではないことである。

ORIGIN_OFやEXTENDSには本書のAnalysisが含まれる。

だからKnowledge TypeとSourceを付与する。

Codeの段階でもFactとInterpretationを混ぜない。

⸻

GraphがAIのEnterprise Memoryになる

Knowledge Graphが構築されると、LLMの役割も変わる。

LLMだけに企業史を記憶させる必要がなくなる。

AI AgentはQueryする。

GraphからEntityとRelationを取得する。

SQLからAuthoritative Dataを取得する。

Vector Storeから関連Documentを検索する。

Sourceを確認する。

そのうえで回答を生成する。

つまり、

Question
→ Entity Resolution
→ Graph Retrieval
→ SQL Retrieval
→ Document Retrieval
→ Evidence
→ LLM
→ Answer

というArchitectureになる。

AIのMemoryをModel Parameterだけに依存させない。

Enterprise Memoryを外部化する。

これはResearch、Consulting、Systemすべてへ拡張できる。

⸻

そして企業史Knowledge Graphは、単なる過去の検索Systemでは終わらない。

「現在のCloud Capabilityは、どの歴史的Capabilityから形成されたか」

「金融Systemに関連するOrganizationは過去30年間でどう変化したか」

「AIとResearchが接続されたEventは何か」

といったQueryが可能になる。

さらに2050 Future Pullを加えれば、

「2050年に必要なCapabilityのうち、2026年時点ですでに存在するものは何か」

をGraph上で比較できる。

ここでHistoryはFuture Architectureへ接続される。

⸻

1953年。

1989年。

2008年。

2021年。

2026年。

これらを年表として並べるだけなら、過去である。

しかし、

Entity

Relation

Event

Time

Source

Knowledge Type

へ変換すれば、それはMachineが利用可能なStateになる。

大和総研が70年以上にわたって蓄積してきたものは、建物や法人やSystemだけではない。

Research Method。

Financial Knowledge。

Business Rule。

Software。

Architecture。

Operational Experience。

Organizationそのものの変化。

それらすべてがEnterprise Memoryである。

企業史をKnowledge Graphにするとは、過去を保存することではない。

過去を、現在のAIと未来のSystemが再利用可能なKnowledgeへ変換することである。

そしてこのGraphに、次の節で2050年から引かれるRequirementを重ねる。

時間はそこで、

1953 → 2026

という一方向から、

1953 → 2026 ← 2050

という二方向のArchitectureへ変わる。
第7節　1953→2026←2050

大和総研の企業史を一本の時間軸として描けば、

1953 → 1989 → 2008 → 2021 → 2026

となる。

調査部と機械計算部。

大和総研の成立。

分化。

再統合。

AI・AX・Cloud・Trust。

これは過去から現在へ流れる時間である。

しかし、本書は2026年を終点にしない。

反対側に2050年を置く。

1953 → 2026 ← 2050

過去からはCapabilityが流れ込む。

未来からはRequirementを引く。

二つの時間が交差する地点として、2026年の大和総研を記述する。

⸻

過去から来るもの

1953年から2026年へ流れているのは、単なる年数ではない。

Accumulated Capabilityである。

1953年には、

Knowledge + Computation

という二つの起点があった。

そこからResearchが発達する。

Computer ProcessingがSystem Engineeringへ変わる。

Consultingが形成される。

Financial Domain Knowledgeが蓄積される。

Enterprise Systemが拡大する。

Infrastructureが高度化する。

Data Analyticsが加わる。

Cloudが加わる。

AIが加わる。

この変化をTechnologyの系譜として圧縮すれば、

Knowledge
→ Digital Knowledge
→ Machine-readable Knowledge
→ Intelligence

と、

Computation
→ Information Processing
→ Software
→ Cloud
→ AI Runtime

という二つの流れになる。

2026年は、この二本が再び強く接近している地点である。

⸻

LLMは文章を読む。

Knowledge Graphを参照する。

Dataを分析する。

Codeを書く。

AI Agentは複数のToolを利用し、SystemへActionを要求できる。

つまりKnowledgeを扱うMachineと、Computationを実行するMachineが同じArchitecture内部へ入り始めている。

1953年には人間のResearcherと計算機械の間に明確な境界があった。

2026年には、

Human ↔ Knowledge ↔ AI ↔ Software ↔ Reality

という新しい接続が形成され始めている。

だからこそ、過去70年以上に蓄積されたKnowledgeの価値も変わる。

人間だけが読むArchiveだったものを、AIも利用できるEnterprise Memoryへ変換できるからである。

⸻

未来から来るもの

一方、2050年から2026年へ流すものはFactではない。

Requirementである。

2050年の大和総研がどのような会社名を持ち、どのOrganization Structureを持ち、売上高がいくらになっているかを、本書は予測しない。

代わりに問う。

2050年の社会経済を支えるためには、どのようなCapabilityが必要になる可能性が高いのか。

人口構造が変化する。

社会保障が変化する。

ClimateとEnergyのConstraintが続く。

金融市場はさらにDigital化する。

企業はAIをOperationへ組み込む。

Cybersecurityの重要性は高まる。

HumanとAIのResponsibility Boundaryが問題になる。

複数のAI Agentが企業Systemの一部になる可能性がある。

この複数Scenarioから、共通するRequirementを抽出する。

Continuous Observation

Machine-readable Knowledge

Simulation

Decision Support

Interoperability

Trusted AI Runtime

Human Authority

である。

未来を当てるのではない。

未来の複数状態に耐え得るCapabilityを探す。

⸻

2026年を比較地点にする

すると2026年を見る方法が変わる。

通常の企業分析では、

「大和総研は現在何をしているか」

を調べる。

本書では、そこに二つのQueryを追加する。

そのCapabilityはどこから来たのか。

そして、

2050年のRequirementに対して何が不足しているのか。

例えばResearchを見る。

1953年から蓄積されてきたEconomic Research Capabilityがある。

2026年には生成AIを利用した経済Simulationまで現れている。

2050年からはContinuous Economic IntelligenceというRequirementを引く。

すると、

**Historical Capability

* Current Technology
   − Future Requirement
   = Architecture Gap**

という比較ができる。

未来から現在を見る目的は、このGapを発見することである。

⸻

Consultingでも同じである。

過去からは企業価値、資本政策、Governance、M&A、Human CapitalなどのKnowledgeが流れ込む。

2026年にはDataとAIが企業Decisionへ入り始めている。

2050年からは、変化するCorporate Stateを継続的に観測し、複数Scenarioを比較するCapabilityが要求される可能性がある。

すると、

Point-in-time Consulting

から、

Continuous Decision Intelligence

へ拡張する余地が見える。

これは2050年の大和総研が必ずそのBusinessを行うという意味ではない。

Capability Requirementから導かれるArchitecture上の可能性である。

⸻

Systemではさらに明確になる。

過去からは、金融System、Enterprise System、Infrastructure、Operationという巨大なProduction Knowledgeが流れ込む。

2026年にはCloud、AI駆動開発、Smartrans、AI Trustが加わっている。

2050年からは、AI Agent自身がProduction ComponentになるScenarioを置くことができる。

するとSystemは、

Application + Data + Infrastructure

だけでは足りない。

そこへ、

Model + Knowledge + Agent + Policy + Human Authority

を加える必要がある。

2026年のAIトラスト基盤という方向は、そのRequirementへ接続可能な現在のCapabilityとして読むことができる。

⸻

二つの時間をGraphへ重ねる

前節で構築したHistory Knowledge Graphには、過去のFactが入る。

そこへFuture Requirementを別のKnowledge Typeとして追加する。

例えば、

1953_CAPABILITY
  KNOWLEDGE
  COMPUTATION
       ↓ historical evolution
2026_CAPABILITY
  RESEARCH
  CONSULTING
  SYSTEM
  AI
  CLOUD
  TRUST
       ↑ requirement mapping
2050_REQUIREMENT
  CONTINUOUS_INTELLIGENCE
  SIMULATION
  MACHINE_READABLE_KNOWLEDGE
  INTEROPERABILITY
  TRUSTED_RUNTIME
  HUMAN_AUTHORITY

ここで1953側のEdgeはHistorical FactやAnalysisによって構成される。

2050側のEdgeはScenarioとRequirementである。

両者を同じTruthとして扱わない。

Past = Evidence-constrained

Future = Scenario-constrained

とする。

そして2026年だけが、実際に観測可能なCurrent Stateとして両者の間に置かれる。

⸻

この構造を形式化すると、

[
C_{2026}=f(H_{1953:2026})
]

と表現できる。

現在Capability (C_{2026}) は、1953年から2026年までのHistory (H) の結果として存在する。

一方、未来からは、

[
R_{2050}=g(S_{2050})
]

とする。

2050年の複数Scenario (S) からRequirement (R) を抽出する。

そして、

[
G=C_{2026}\leftrightarrow R_{2050}
]

としてCurrent CapabilityとFuture Requirementを比較し、Gap (G) を特定する。

このGapが、

Architecture Requirement

になる。

未来論をSoftware Engineeringへ翻訳する境界がここにある。

⸻

GapからArchitectureへ

例えば、2050 Requirementとして「複数Agentによる継続的なEconomic Simulation」が必要だとする。

2026年にはEconomic ResearchとAI Agent Simulationの研究が存在する。

しかしProduction Levelで継続的に動かすには、

Data Pipeline。

Entity Resolution。

Knowledge Graph。

Simulation Engine。

Model Registry。

Agent Identity。

Authorization。

Audit。

Human Review。

が必要になる。

つまり、

Future Requirement
− Current Capability
= Missing Components

である。

Missing Componentを明確にすれば、未来の議論を具体的なEngineering Taskへ変換できる。

この瞬間、2050年は抽象的な未来ではなくなる。

Backlogになる。

⸻

過去もArchitecture Requirementになる

同時に、過去側からもRequirementが生まれる。

70年以上のKnowledgeをAIが利用するなら、過去のDocumentをDigitizeするだけでは足りない。

Sourceを保持する。

Versionを管理する。

Organizationの変遷を追跡する。

古い用語と現在の用語を接続する。

Legacy SystemのBusiness Logicを抽出する。

失われたContextを可能な範囲で復元する。

つまり、

History → Enterprise Memory Requirement

が生まれる。

未来からだけでなく、過去からもArchitectureが要求される。

だから2026年は二方向から挟まれる。

Past Capability → 2026 ← Future Requirement

である。

⸻

2026年はTransition Stateである

この見方をすると、2026年を「完成した現在」として扱う必要がなくなる。

2026年はStateである。

次のStateへ移行可能な現在状態である。

1953年の機械計算部が現在存在しないように、2026年のOrganization Structureが2050年まで固定される保証もない。

AX本部。

AIトラスト基盤開発部。

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

これらも永続する名称である必要はない。

重要なのはOrganization Nameではなく、その内部に形成されているCapabilityである。

だから本書では、

Organization → Capability → Architecture

の順に抽象度を上げる。

Organizationは変わる。

Capabilityは継承される。

ArchitectureはCapabilityを次のStateへ移す。

⸻

1953年から受け取り、2050年から要求する

ここまでの第1章を一つに圧縮すると、大和総研のHistoryは次のように表現できる。

1953

Knowledge + Computation

↓

1989

Integration

↓

2008

Specialization

↓

2021

Reintegration

↓

2026

AI × AX × Cloud × Trust

そして反対側から、

2050

Continuous Intelligence
Simulation
Machine-readable Knowledge
Interoperability
Trusted Runtime
Human Authority

↓

2026

となる。

したがって本書の時間Architectureは、

[
\boxed{
1953 \rightarrow 2026 \leftarrow 2050
}
]

である。

⸻

しかし二つの矢印は、2026年で衝突するためにあるのではない。

ここで接続される。

過去から受け取ったKnowledgeをMachine-readableにする。

蓄積されたSystem KnowledgeをReusable Assetへ変える。

ResearchをContinuous Intelligenceへ拡張する。

ConsultingをSimulationと接続する。

Production SystemへAI Agentを安全に組み込む。

Cloudへ実行基盤を置く。

TrustによってAuthorityとResponsibilityを保持する。

そして実装結果から再び学習する。

すると、

History → Current State → Architecture → Implementation → New State

という次の時間が始まる。

⸻

第1章で確認したのは、大和総研が何をしてきたかだけではない。

何を蓄積してきたかである。

Research Knowledge。

Financial Knowledge。

Corporate Knowledge。

Software。

Infrastructure。

Operational Experience。

Organization。

Data。

そして、それらを分化し、再統合してきた経験そのもの。

これらはすべて、2026年から次のStateを設計するときのInitial Conditionになる。

未来は過去の単純な延長ではない。

しかし未来を実装するためのResourceは、現在に存在しなければ使えない。

だから、未来を見る前に過去を読む必要があった。

そして過去を読んだ後には、現在から未来を予測するのではなく、未来側から現在に不足しているものを問う。

1953から、何を受け取ったのか。

2050から、何を要求されるのか。

その二つの問いが交差する2026年から、次の第Ⅱ部では大和総研の最も古いCapabilityの一つへ入る。

Research。

世界を観測し、日本を理解するというOperationである。

愛と敬意を込めてmandala