AIは企業の文脈を覚え始めるーー個人の業務記憶から「企業経営Embedding」へーーGenspark「AI Workspace 6.0」を起点として

＜２０２６年８月２４日以前のコンテンツ一覧はこちら＞

＜昨年２月ごろ触ったGensparkが１年半たってとてつもなく進化したようなので、そこを起点として過去記事と接続した記事を作成してもらいました。要は毎日会社、組織に通勤してPCに文字を打ち込み資料を作成し、メールを送信受信して、業務を成功失敗した記録が企業価値へと繋がっていく可能性があるということになりそうです。＞

＜本文＞

生成AIをめぐる競争では、これまでモデル性能が大きな比較軸だった。

2026年の企業向けAIを見ると、それに加えて、そのAIが企業固有の現在状態・関係・過去の判断・利用可能な権限をどこまで正確に扱えるかが、製品設計上の重要な論点になっている。

ここで「モデル性能」と「企業Context」は二者択一ではない。高性能なモデルであっても、現在の社内状況や利用権限を与えられていなければ企業固有の仕事は進めにくい。一方、豊富なContextがあっても、モデルやToolの能力が不足していれば十分な仕事はできない。

その変化を考えるきっかけの一つになったのが、Gensparkが2026年7月に発表した「AI Workspace 6.0」である。[1]

AI Workspace 6.0を構成する機能の一つがSecondBrainであり、Genspark自身はこれを「memory layer（記憶層）」と位置付けている。[1] メール、会議、チャット、文書、接続したアプリ、Genspark上のプロジェクトなどを持続的なContextへまとめ、AIが利用者の仕事の背景を繰り返し利用できるようにする仕組みである。

本稿でSecondBrainを取り上げるのは、特定製品を企業全体へ拡張すべきだと主張するためではない。個人単位で蓄積される業務Contextを、企業利用ではどのように扱うべきかという問いを分かりやすく示す一例だからである。

企業では、Contextの範囲は一直線の階層だけでは表せない。

個人
↔ 案件・プロジェクト
↔ チーム・職能
↔ 部門・地域・法人
↔ 全社

のように複数のScopeが重なり、ある情報は上位Scopeへ共有され、別の情報は個人または案件内に留まる。

したがって、ここで考えたいのは社員一人ひとりの記憶を中央へ集約することではない。利用目的、時点、出典、Access Permissionを付けたまま、必要な文脈だけを必要なScopeで利用することである。

そのような企業の機械利用可能な状態表現を、本稿では作業概念としてここでは、企業経営Embeddingと呼ぶ。

1　企業AIで重要なのはモデル性能だけでなく「その会社の事情」である

企業AIで必要なのは、一般知識だけではない。

例えばAIに「A社向けの提案を見直して」と頼んだとする。

実務では、過去の提案、担当者、先方の決裁者、失注理由、現在の粗利率、値引き上限、在庫、生産能力、法務上の制約、経営上の顧客位置付けなどが必要になる。

一般的なLLMが、こうした最新かつ社内固有で、しかも今回利用してよい情報を当然に保持していると仮定することはできない。

したがって企業AIの課題は、モデルの知能に、企業固有の現在Contextをどう接続するかにある。

今回の62事例版と88件版でも、organizational memory、institutional memory、enterprise memory、context graph、context fabricなど、企業固有Contextを独立した論点として扱う公開資料が複数確認できた。

ここから言えるのは「モデル競争がContext競争へ置き換わった」ということではない。

モデル性能に加えて、企業固有Contextの品質・鮮度・範囲・権限が、企業AIの性能を左右する追加の変数になっている

ということである。

2　個人の業務記憶と企業記憶は同一ではない

企業経営Embeddingを考えるうえで、まず分けるべきものがある。

個人Memoryの総和 = 企業Memoryではない。

一人の社員の業務Contextには、本人だけに届いたメール、人事上の相談、未決定の検討事項、顧客との非公開のやり取り、個人的なメモ、失効した情報などが混在する。

しかも企業の情報共有は、

個人 → チーム → 部門 → 企業

という一方向だけではない。

案件限定のContext、地域限定のContext、特定法人に限定されたContext、職能横断で共有するContextなどがあり、ある情報は複数Scopeに属し、別の情報は上位Scopeへ移さない方がよい。

したがって企業Memoryは、分散したContextにScope・Purpose・Time・Source・Permissionを付け、必要な仕事のときだけ適切な組合せで利用する構造として考える方が精密である。

ここでの「緩くつなぐ」とは、共有量を増やすことではない。

共有してよいものだけを、共有してよい目的と時点に限定して接続すること

を意味する。

3　企業経営Embeddingとは何か

本稿でいう企業経営Embeddingは、狭義の機械学習用Vector Embeddingそのものではない。

作業上の定義は、企業の現在状態、内部・外部の関係性、現在利用可能な知識や意思決定傾向を、AIが機械利用できる形で表現し、過去のManagement Trajectoryを参照しながら更新できる状態である。

ここでは、

• Enterprise Management Embedding：現在の仕事に利用できる企業状態表現

• Management Trajectory：過去の状態・判断・実行・結果を時系列で保持する履歴

として区別する。

領域主な情報財務売上、利益、原価、資金、債権、債務顧客CRM、商談、契約、購買履歴、問い合わせ商品商品構成、価格、設計、品質SCM需要、調達、在庫、生産、物流人事組織、職歴、スキル、人員配置業務稟議、申請、承認、例外処理会話メール、会議、チャット知識文書、規程、マニュアル、ノウハウ判断採用した案、却下した案、その理由外部環境市場、競合、規制、取引先

ただし、これらの金額、契約、Identity、権限、在庫数量などの正本までEmbeddingへ置き換えるわけではない。

正本はERP、CRM、IAM、契約管理、各種System of Recordに残る。

企業経営Embeddingは、それらの正本と履歴を参照し、「今この企業はどのような状態にあり、何と何が関係し、どの履歴が今回の仕事に関係するか」をAIが利用できるようにする上位の状態表現である。

4　ここでいうEmbeddingは一つのVector DBを意味しない

企業を表現するには、文章を数値Vectorへ変換するだけでは足りない。

企業には、

• 人・顧客・製品・契約などの関係

• 組織変更・価格変更・承認者変更などの時間

• 受注済み・承認待ち・製造中などの状態

• 採用案・却下案・判断理由などの意思決定

• Tool実行・例外・失敗などの実行履歴

がある。

したがって本稿でいう企業経営Embeddingは、一つの巨大Vectorや一つのDatabaseを指さない。

例えば、

Vector Embedding
＋ Knowledge Graph
＋ Ontology
＋ Business Entity
＋ Event Log
＋ Workflow State
＋ Decision Memory
＋ Execution Trace

などを組み合わせて、必要時に状態を構成することが考えられる。

重要なのは、これらが必ず一つの物理Systemとして存在する必要もないことである。

一部はSystem of Recordにあり、一部はGraphにあり、一部はEvent Logにあり、実行時にContext Compilerが必要な状態を組み立てる構成でもよい。

したがって「企業経営Embedding」は製品コンポーネント名というより、複数の正本・履歴・関係表現から得られる機械利用可能な企業状態をまとめて呼ぶ作業概念である。

5　複数の公開資料では、近い論点に別々の名前が使われている

今回、全世界、中国、韓国、台湾、欧州、北米、南米、豪州、アジア、中東、アフリカ、日本、東欧、ロシアという14の分析区分を設けた。

調査資料は二層に分けている。

第一層は、企業・組織の公式資料や一次資料を中心に構成した62事例版である。本稿内ではこれを「正典アトラス」と呼ぶが、ここでいう正典とは本稿で個別企業・製品の事実確認を優先するcanonical reference setという意味であり、その記述が第三者によってすべて独立検証済みという意味ではない。

第二層は、その周辺の記事、論考、地域メディア、研究資料などを広く集めた88件版である。最新版では、採用78件、補助のみ7件、除外3件として管理している。

両アトラスは独立した150件の観測ではない。同じ企業や同じテーマが両方に含まれており、同名の組織・媒体だけでも29件の重複がある。

したがって本稿では、62事例版：個別企業・製品の事実確認と88件版：用語、論点、地域的な広がりの探索と役割を分け、件数を単純加算しない。

また、いずれも世界市場全体を統計的に代表する無作為標本ではない。類似概念を比較するための目的抽出サンプルである。14区分も排他的な地域統計ではなく、「アジア」と「中国・韓国・台湾・日本」のように地理的重複を含む。

この限定の下では、「企業経営Embedding」という名称自体は一般的でないが、その構成要素に近い議論は複数地域の公開資料で確認できると評価できる。

Organizational Memory。Institutional Memory。Enterprise Memory。Context Graph。Context Fabric。Business Knowledge Fabric。Operational Context。Digital Twin。Digital Thread。Context Engine。Digital Brain。

これらが同一概念だという意味ではない。

本稿は、企業固有の状態・関係・履歴をAIのContextとして扱うという共通部分を抽出して比較している。

6　Microsoftは「Data・Memory・Inference」と整理している

この方向を非常に分かりやすく示すのがMicrosoftのWork IQである。

MicrosoftはWork IQを、Data・Memory・Inferenceという三つの層で説明している。[2]

Dataは、ファイル、メール、会議、チャット、業務システムなどのSignalsをつなぎ、組織で仕事がどのように行われているかを捉える。

Memoryは、人やチームがどのように仕事をするのかを、タスク、アプリケーション、セッションをまたいで持続的に理解する。

Inferenceは、そのContextとモデル、Skill、Toolを組み合わせ、Agentが推論し、実際のActionへ進める。

さらにMicrosoftは、そのActionをControl Planeによって観測・統制可能にする構造を説明している。[2]

従来なら、Data → AIだった。

Work IQでは、Data → Memory → Inference → Actionとなる。

企業データを検索するだけでなく、企業や人の仕事について持続的なContextを形成する方向へ一段進んでいる。

7　Atlassianは「AI that knows your business」と表現する

Atlassianはさらに直接的である。

2026年7月の記事タイトルは、AI that knows your businessである。[3]

AIは文章を書ける。障害を分類できる。Backlogを整理できる。

しかし、その会社のArchitectureも、Teamも、Customerも知らなければ、本当に良い仕事はできない。

そこでAtlassianが前面に出しているのがTeamwork Graphである。

人、チーム、目標、仕事、Decision、各種SaaS上の活動を接続し、会社がどう動いているかを示す、更新され続ける権限対応のMapとして人間とAI Agentが利用する。

AtlassianはTeamwork Graphを「organizational memory」と明記している。[3][4]

さらに重要なのは、Graphが一方的な中央集約を意味していない点である。

Atlassianは既存のPermission boundaryを維持しながら、Agentが必要なContextへアクセスする構造を強調している。[3]

これは、個人やチームの文脈を企業レベルへ「緩く」つなぐという考え方に近い。

8　Celonisは業務をDigital Twinとして表現する

欧州企業の一例として、CelonisはContext Modelをdynamic, real-time digital twin of operationsと説明している。[6]

Celonisの説明では、現在の業務状態だけでなく、そこへ至るStep、Interaction、Decisionの履歴までContextに含む。[6][7]

Process Data、Business Knowledge、Decision Intelligenceを組み合わせ、AI Agentが現在のOperationsとその背景を理解できるようにする構造である。

ここから確認できるのは、Celonisという具体例では、企業Operationsを「現在状態＋そこへ至る履歴」として扱っているということである。

これを「欧州全体が同じ方向へ進んでいる」と一般化するには、別途地域全体を代表する調査が必要である。

9　現在状態とManagement Trajectoryを分けて考える

企業の現在状態だけでは、なぜその状態になったのかは分からない。

例えば、

原材料価格が上昇した。
経営会議で対応策を検討した。
値上げ案を作った。
重要顧客の離脱を懸念して見送った。
代替仕入先を探索した。
半年後に原価が下がった。

という履歴があるとする。

これを、

企業状態 t0
↓
意思決定
↓
実行
↓
市場・顧客・業務の反応
↓
結果
↓
企業状態 t1

という時系列で記録したものを、本稿ではManagement Trajectoryと呼ぶ。

ここで重要なのは、EmbeddingとTrajectoryの優劣ではない。

• Enterprise Management Embedding：現在の利用可能な状態表現

• Management Trajectory：その状態へ至った履歴

という役割分担である。

現在状態だけでは理由が欠ける。履歴だけでは現在の正本状態が分からない。

両方を区別して接続することが重要である。

10　TCSはBusiness Knowledge Fabricと呼ぶ

インド企業TCSの例では、Agentic AIを企業業務へ適用するための概念としてBusiness Knowledge Fabric（BKF）が提示されている。[8]

TCSは、Industry Context、Enterprise Context、System Context、Process Contextなどを、企業固有DataやDomain knowledgeとともにAgentへ供給する構造を説明している。[8]

これは本稿の企業経営Embeddingと同一ではない。

しかし、汎用モデルだけでは企業固有Contextが不足するため、企業・業界・Processに固有のContextを別層で供給するという問題設定は近い。

したがってTCSは、企業経営Embeddingという作業概念を比較する際の一つの具体例として位置付けられる。

11　世界の議論を八つの問いとして整理する

62事例版と88件版を比較すると、企業AIを考える際の論点は、直線的な「発展段階」よりも八つの問いとして整理する方が整合的である。

問い確認することData何が正本で、どこから取得した情報かMeaningEntity・関係・Business上の意味をどう表すかMemory何をSessionを越えて保持するかTrajectory状態・判断・実行・結果がどう変化したかSelection今回どのContextがRelevant / Current / Valid / Permitted-to-useかActionAgentがどのTool・Workflow・Systemへ作用するかAuthority今回そのActionを実行してよいかEvidence何を参照し、何を実行し、結果がどうなったかを後から確認できるか

これは順番に一度だけ通過するPipelineではない。

Rights、Provenance、Time、ValidityはData取得時からMemory、Context選択、Action、Evidenceまで横断して効く。

EvidenceはOutcomeを記録し、その一部が検証を経て次のStateやTrajectoryへ戻る。

また、後段で導入するContext Compilerは、この表のSelectionを担う役割として位置付けられる。

したがって本稿の構造は、Data → Meaning → Memory → Trajectory → Action → Authority → Evidenceという一直線より、状態と履歴を保持し、仕事ごとにContextを選び、権限を別判定し、結果を再び状態へ戻す循環として理解する方が正確である。

12　企業AIは会社固有の「経験則」を扱うようになる

Management Trajectoryが蓄積されれば、企業固有のパターンを分析できる可能性がある。

例えば、「原材料価格が一定水準以上上昇した局面で、過去には値上げより先に調達先分散を行った」といった履歴である。

ただし、ここで得られるのはまず観測されたパターンであり、因果法則ではない。

件数が少ないかもしれない。市場環境、経営者、規制、顧客構成など別の変数が影響しているかもしれない。

したがって企業AIが扱う「経験則」は、過去の類似局面を探すための参考情報として利用し、今回も同じActionを採るべきだという規則や因果関係とは分けなければならない。

企業経営Embeddingは、過去を未来へコピーする仕組みではなく、現在の判断材料を増やす仕組みとして扱う方が安全である。

13　これは「業務考古学」の逆でもある

古い企業SystemをAI化するとき、CodeやDataは残っていても、

なぜこの仕様なのか。
なぜこの顧客だけ例外なのか。
誰が何を根拠に決めたのか。

が失われていることがある。

そこで古いCode、Document、Email、担当者への聞き取りからIntentを復元する。これを本稿では比喩的に業務考古学と呼んでいる。

企業経営EmbeddingにManagement TrajectoryとEvidenceを組み合わせれば、

Intent
↓
Constraints
↓
Decision
↓
Action
↓
Artifact
↓
Execution Trace
↓
Evidence
↓
Outcome

の一部を、後から発掘するのではなく、発生時から残せる可能性がある。

ただし、すべての会話や思考過程を保存すべきだという意味ではない。

保存対象、保持期間、権利、機密性、将来の利用目的を決めたうえで、将来説明する必要がある判断と実行を選んで記録する必要がある。

したがって「業務考古学の逆」は、完全記録ではなく、説明可能性を将来へ引き継ぐ設計を指す比喩である。

14　ERPの位置付けも少し変わる

ERPは企業に巨大な革命を起こした。

それまで部門ごとに分散していた会計、販売、購買、生産、在庫などを共通基盤へ統合した。

ERPは、取引、残高、計画、在庫、受発注、業務状態などをSystem of Recordとして記録してきた。

企業経営Embeddingが重ねようとするのは、それらの正本データを置き換えることではなく、そこへ判断理由、関係性、履歴、再利用可能なContextを加えることである。

企業が今どういう状態なのか。
なぜそうなったのか。
どのContextを使って次の判断をするのか。

である。

したがって将来の企業基盤は、System of Recordの上に、本稿で便宜的にEnterprise State SystemやEnterprise Memory Systemと呼べる層を持つようになるかもしれない。

ERP、CRM、SCM、PLMが不要になるわけではない。

むしろ、それらを企業の意味や履歴として束ねる層が加わる。

このとき、金額、契約条件、Identity、権限、在庫数量などの正本を企業経営Embedding側で推定値へ置き換えてはいけない。System of Recordを正本として参照し、その周辺の意味・関係・履歴をContextとして加えるという境界が必要である。

15　会社を理解していることと、会社を代表できることは違う

企業経営Embeddingが豊かになるほど、AIは企業の過去の行動パターンを詳しく理解できる。

しかし、「この会社では通常こうする」という推定と、「今回このActionを実行してよい」というAuthorityは別である。

本稿では、この外部Effect直前の権限確認層を便宜的にHGL（Human Gate Layer）と呼ぶ。

Enterprise Management Embedding
↓
Enterprise Agent
↓
HGL / Authority
↓
Corporate Action

という分離で考える。

ここでHGLという名前は、すべてのActionを毎回人間が手作業で承認するという意味ではない。

Identity、Delegation、Authorization、対象範囲、金額上限、有効期限などのPolicyによって自動Allow / Denyできるものもあり、Human Approvalが必要な条件ではAsk / Stopへ移すというGateである。

HGLは本稿上の概念名であり、一般に確立した標準名称ではない。

重要なのは名称ではなく、Contextから推定した企業の行動傾向を、実行権限の代用にしないことである。

16　Evidence Ledgerは企業記憶の原材料になり得る

AIが企業を代表してActionするなら、「何をしたか」だけでは十分ではない。

少なくとも、

• どのSourceを参照したか

• どのPolicyを評価したか

• どのDelegation / Authorizationを確認したか

• どのToolを実行したか

• 誰が承認したか

• 実際に何が起きたか

• 結果がSuccess / Failure / Partial Completion / Timeout / Cancellation等のどれだったか

を後から追える必要がある。

本稿では、こうした証跡をまとめてEvidence Ledgerと呼ぶ。

ここで注意すべきなのは、AIが生成した「なぜそう考えたか」という説明と、実際のEvidenceは同一ではないことである。

AIの説明は補助情報にはなるが、Source、Policy evaluation、Tool call、Approval、System responseなどの実記録に置き換わるものではない。

また、Evidence Ledgerに記録されたものが自動的に企業Memoryになるわけでもない。

出典、正確性、権利、失効、結果評価を検証したものだけが、次の企業状態やManagement Trajectoryを更新する原材料になり得る。

17　企業Memoryには「覚える仕組み」と「整理する仕組み」が必要になる

企業Memoryは、多ければ多いほどよいとは限らない。

企業の情報は常に変化しているからである。

昨年の組織図。失効した価格表。終了した契約。廃止された規程。異動した承認者。改正前の法律。検討したが採用されなかった企画。訂正前の議事録。AIが生成した後に修正された説明。

こうした情報にも歴史的価値はある。

問題は、歴史的には正しい情報と、現在の業務で有効な情報を区別せず利用してしまうことである。

例えば、「田中氏は購買部長である」という情報が2025年には正しくても、2026年に異動していれば、現在の承認判断にはそのまま利用できない。

企業Memoryでは、いつの情報なのか、どこから得たのか、現在も有効なのか、何の目的で利用できるのか、誰が利用できるのか、まで管理する必要がある。

さらにAI自身が生成した情報をMemoryへ保存する場合には、

AI生成
↓
Memoryへ保存
↓
別のAIが参照
↓
新しいAI生成
↓
再びMemoryへ保存

という循環にも注意が必要である。

最初の小さな誤りが繰り返し参照されれば、長期間残る可能性がある。

そこで企業Memoryには、Time、Source、Provenance、Validity Scope、Confidenceに加え、誰がその情報を閲覧・利用できるかを示すAccess metadataが必要になる。

過去に誰がどの権限を持っていたかというAuthority履歴を保存することはできるが、それは「今回このActionを実行してよい」という実行許可そのものではない。実行時のAuthorityは15章のHGLで改めて判定する。

さらに将来的には、本稿で便宜的にCorporate Memory GCと呼べるような仕組みも考えられる。

これは単純に古い情報を削除するという意味ではない。

現在の業務では利用しない。歴史資料として保存する。誤りが確認されたので隔離する。新しい情報で置き換える。権限変更によって参照範囲を変える。

といったMemoryのライフサイクル管理である。

AI時代の企業では、何を覚えるかと同じくらい、記憶をどう整理し、更新し、適切に使い分けるかが重要になる。

18　Context Compilerという新しい層

企業が大量のMemoryを持つようになったとしても、それを毎回すべてLLMへ渡すことはできない。

必要なのは、今この瞬間、この仕事に必要なContextだけを組み立てることである。

そこで本稿では、この役割を便宜的にContext Compilerと呼んで考える。これは一般に確立した製品カテゴリ名ではなく、検索、Graph query、Policy、Metadata filter、RAGなど複数の機能に分散して実装されてもよい概念的な役割である。

例えば購買契約を更新するAgentなら、対象契約、現在価格、最新在庫、需要予測、取引先信用情報、購買規程、承認権限、現在時点などを選ぶ。

10年前の組織図も、別事業部の議事録も必要ない。

しかもContext Compilerは、情報の関連性だけを見ればよいわけではない。

Relevantか。
Currentか。
Validか。
Permitted-to-useか。

を同時に見る必要がある。

ここでいうPermissionはそのContextを参照・利用してよいかという情報アクセス上の条件であり、外部Actionを実行してよいかというAuthorityとは分ける。後者は実行直前にHGLで判定する。

優れた企業AIは、「全部知っているAI」ではなく、「今必要なことを、正しい時間・出典・権限付きで利用できるAI」になる。

19　Contextの可搬性も企業IT戦略の論点になる

LLMは、技術、価格、性能、契約条件に応じて変更できる場合がある。

一方、長期間蓄積した意思決定履歴、顧客関係、例外処理、Process history、Agentの実行履歴、Business Entity間の関係は、別のPlatformへ移す際に変換・再構築が必要になる可能性がある。

Atlassianは2026年8月の株主向け説明で、モデルの知能は市場から調達できる一方、企業Contextは構築が難しいという自社の戦略認識を示している。[5]

これはAtlassian自身の企業戦略上の主張であり、市場全体でContext Lock-inがModel Lock-inより強いことを独立に証明するデータではない。

それでも、企業Contextについて、

• Exportできるか

• Entity / Relationshipを移植できるか

• Provenanceを保持できるか

• Decision historyを移せるか

• Agent実行履歴を別基盤で再利用できるか

を確認する必要性はある。

したがって本稿での結論は、

Context Lock-inが必ずModel Lock-inを上回る

ではなく、

Contextの可搬性と移行コストが、企業IT戦略の独立した論点になり得る

という範囲に留める。

20　ここまで考えると、以前の「倒産企業データ」の議論がつながる

ここで、この問題を別の方向から見てみたい。

以前、倒産した企業が残した大量の内部Dataに、AI時代には新しい資産価値が生まれる可能性について考えた。

象徴的なのがSpirit Airlinesの事例である。

2026年8月、破産手続き中のSpirit Airlinesの内部Business Dataについて、Googleによる1000万ドルの購入案が進められていると報じられた。GoogleはProduct developmentやAI ModelのTrainingへの利用を想定している。[9]

報道では、対象に従業員Email、Microsoft TeamsのMessage、Spreadsheet、Calendar、Marketing関連Data、Productivity Data、Operations Dataなどが含まれるとされる。[9][11]

ただし2026年8月29日時点では、裁判所の審理は9月9日に延期されており、取引は最終承認前である。また、Spiritの客室乗務員を代表するAssociation of Flight Attendants-CWA（AFA-CWA）が、従業員Dataの扱いをめぐって異議を申し立てている。[10][11]

このニュースだけを見ると、倒産企業に残された大量Dataが取引対象になったという話に見える。

しかし企業経営Embeddingという視点からは、この取引を別の角度から読むこともできる。

以下はGoogleが購入理由として明示した内容ではなく、本稿の分析上の仮説である。

企業内部のEmailやChat、Spreadsheet、Calendar等を相互に関連付けられるなら、個々の文書だけでなく、相談、依頼、検討、判断、実行、修正、結果といった企業活動の一部を再構成できる可能性がある。

したがって、こうした内部Dataは、権利処理とデータ品質の条件を満たす範囲で、その企業のManagement Trajectoryを後から分析する材料になり得る。

21　倒産企業の記録にはFailure Trajectoryを分析できる可能性がある

倒産企業の内部記録からは、結果だけでなく、そこへ至る判断・実行・警告の履歴を分析できる可能性がある。

例えば、

いつ問題が認識されたのか。
誰が何を提案したのか。
何を採用し、何を採用しなかったのか。
その後、どの状態変化が起きたのか。

という履歴である。

本稿では、このような履歴をFailure Management Trajectoryと呼ぶ。

ただし、倒産企業の内部記録が「倒産原因の完全な記録」になるわけではない。

内部記録そのものが不完全かもしれない。倒産という結果を知った後に過去の警告だけを重要視するhindsight biasも起こり得る。また、市場環境、金利、競争、規制、偶発的出来事など外部要因もある。

したがってFailure Trajectoryの役割は、倒産原因を自動的に決定することではなく、時系列に沿って検証可能な仮説を作ることである。

これは成功企業のTrajectoryにも同じであり、成功結果から特定の意思決定を単純に成功原因と断定してはいけない。

22　法人や事業が終了した後にも企業経験は残り得る――Corporate Afterlife

企業が破産したり、法人として活動を終了したとしても、判断、交渉、設計変更、価格決定、顧客対応、成功、失敗、例外処理などの記録そのものが直ちに消えるわけではない。

それらが機械可読な形で残り、かつ利用ごとに必要な権利・契約・Privacy等の条件を満たすなら、企業が蓄積した経験の一部は、その後も利用される可能性がある。

本稿では、この状態を概念的にCorporate Afterlifeと呼ぶ。

これは一般に確立した法的・会計的な用語でも、「企業がAIとして生き続ける」という意味でもない。

破産、清算、事業停止、事業譲渡などによって従来の企業活動が縮小・終了した後も、適法な権利処理が行われたData・Knowledge・Experienceの一部が、破産手続、事業承継、研究、AI学習などで再利用され得る状態を説明するための本稿上の概念である。

Spirit Airlinesの事例も、2026年8月29日時点では法人消滅後の事例ではなく、破産手続中のデータ資産処分をめぐる事例として位置付けるのが正確である。[9][10]

つまり、企業活動の縮小・終了と、企業経験の利用可能性の終了は必ずしも同じではないということである。

23　発想を活動中の企業へ戻す

倒産企業のDataを考えたときの問いは、

だった。

この観察から、活動中の企業について一つの仮説を立てることはできる。

ただし、これは「企業はできるだけ多くのMemoryを残すべきだ」という結論ではない。

記録・保存にはCost、Privacy、Security、Legal、運用負荷がある。

したがって対象は、将来の説明・再利用価値＞ 保存・Governance・権利処理のCostとRiskが期待できる範囲に限定する必要がある。

活動中の企業では、

業務活動
→ Source / Time / Rightsを付けて必要な記録を残す
→ Management Trajectoryを更新
→ 現在状態を更新
→ 必要時にContextとして利用

という循環を作ることが考えられる。

重要なのは、個人のMemoryを会社が丸ごと所有することではない。

残すべき企業経験を選び、残さない情報や失効させる情報も明示的に設計することである。

24　M&AではCorporate Memoryも評価対象になるかもしれない

ここまで来るとM&Aの考え方も変わる。

現在は、不動産、設備、特許、ブランド、顧客、契約、人材、収益力などを評価する。

しかし将来、Corporate Memoryも重要な評価対象になる可能性がある。

例えば同じ売上100億円の会社が二つある。

A社では20年間のDecision、Action、Success、Failure、Exceptionが時間軸で整理され、Source、Authority metadata、Outcomeまで追跡できる。

B社では同じ経験がEmail、Excel、退職した担当者の頭の中に散在している。

AI時代の組織資産として考えれば、この二社は同じではない。

将来的には、既存の財務・法務・技術・人事DDの中で、またはその横断評価として、Corporate Memory DDと呼べる観点が加わる可能性もある。これは現時点で一般化されたDD分類ではなく、本稿の仮説である。

ただし、これはMemoryの「量」を評価するものではない。

どれだけ多く保存しているかより、権利処理され、出典が明確で、時間が管理され、再利用可能な形になっているかの方が重要になる。

25　「のれん」そのものではなく、無形能力の一部が観測しやすくなる

ここで論じる企業Memoryと、会計上の「のれん」は同一ではない。

企業Memoryが観測・分析可能になっても、それだけで会計上の資産認識、測定、のれんの個別認識が成立するわけではない。

本稿が指摘するのは、顧客関係、Process knowledge、意思決定履歴、組織能力など、これまで人間の説明に依存していた企業能力の一部が、

Customer Relationship Graph。
Supplier Relationship Graph。
Decision Memory。
Process Trajectory。
Organizational Knowledge。
Success / Failure History。

のような形で観測しやすくなる可能性である。

観測可能になることと、経済価値を測定できることも別である。

したがって、ここから言えるのは、企業の無形能力の一部が、機械可読な履歴として分析対象になり得るというところまでである。

「のれんが機械可読になる」と断定するのではなく、従来の無形能力を説明する証拠が増える可能性として扱うのが適切である。

26　企業記憶を誰が、どの条件で利用できるのか

企業MemoryのGovernanceは、「誰が所有するか」という一問だけでは整理できない。

企業が管理するSystemに保存されていても、

• 誰が閲覧できるか

• 何の目的で利用できるか

• 別目的へ再利用できるか

• どこまで保持できるか

• 第三者へ移転できるか

• 退職・異動・契約終了後にどう扱うか

は別々の問題である。

実際の法的要件は、法域、情報類型、契約、守秘義務、知的財産、労務・Privacy等によって異なるため、個別案件では要検証である。

Spirit Airlinesの事例でも、AFA-CWAが従業員Dataの扱いに異議を申し立てており、Business Dataの取引可能性と、その中に含まれる個人・労務関連情報の扱いが同一ではないことを示している。[10][11]

本稿では法的結論を一律に示すのではなく、Governance上の確認項目として、

Source / Provenance
＋ Time
＋ Rights / Contract
＋ Purpose
＋ Validity Scope
＋ Access Permission
＋ Retention

を各Contextに結び付ける。

技術的に取得できることは、法的・契約的・組織的に利用してよいことを意味しない。

企業経営Embeddingは、誰の文脈を、誰が、何の目的で、いつまで、どのScopeで利用できるかを保持したまま企業経験を再利用する仕組みとして設計する必要がある。

27　企業AIの想定される全体構造

ここまでの議論を一つにつなぐと、本稿の概念モデルは次のように整理できる。

System of Record / Event Log / 文書 / 会話 / Agent実行記録
↓
Time・Source・Provenance・Rights・Scopeを付与
↓
Enterprise State ＋ Scoped Memory ＋ Management Trajectory
↓
（この機械利用可能な企業状態を本稿では企業経営Embeddingと総称）
↓
Context Compiler
Relevant / Current / Valid / Permitted-to-use を仕事ごとに選択
↓
Enterprise Agent
↓
HGL / Action Authority
Identity・Delegation・Authorization・Limit・Expiration・Human Approval
↓
Corporate Action / External Effect
↓
Evidence Ledger ＋ Outcome / State change
↓
検証後にEnterprise State / Management Trajectoryを更新
↺

ここで、企業経営Embeddingは必ず一つの物理Systemとして実装される必要はない。

複数のSystem of Record、Graph、Event Log、Memory、Policy Storeから得られる機械利用可能な企業状態の総称である。

また、RightsやProvenanceは最初に一度だけ確認して終わるものではない。

Contextを選ぶときにも、Actionするときにも、Evidenceを再利用するときにも効く横断的な属性である。

この構造で重要なのは、

理解
≠ Context利用許可
≠ Action実行権限
≠ 実行結果の証明

を分離することである。

企業AIは「全部知っている巨大な企業脳」を目指す必要はない。

むしろ、正本を壊さず、履歴を残し、必要なContextだけを選び、Action権限を別に判定し、結果を証拠として戻す循環の方が、企業システムとして精密である。

おわりに　AIの競争軸に「企業の経験をどう引き継ぐか」が加わる

企業経営Embeddingという言葉自体は、一般的な製品名でも標準用語でもない。

本稿内の62事例版と88件版から確認できるのは、複数の企業・研究・地域資料で、

Enterprise Memory。
Organizational Memory。
Work IQ。
Teamwork Graph。
Context Model。
Context Fabric。
Business Knowledge Fabric。
Digital Twin。

など、企業固有ContextをAIへ与えるための異なる構造が現れていることである。

一方、この資料群は目的抽出サンプルであり、両アトラスには重複もある。

したがって、世界が企業経営Embeddingという一つのArchitectureへ収束しているとまでは言えない。

より限定的に言えば、企業AIでは、モデル性能だけでなく、企業固有の状態・履歴・関係・権限・Evidenceをどう扱うかが独立した設計問題になっているということである。

GensparkのSecondBrainは個人の仕事のContextを持続させる一例である。[1]

MicrosoftのWork IQはData・Memory・Inferenceを統合している。[2]

AtlassianのTeamwork Graphは組織ContextとPermission-awareなGraphを扱う。[3][4]

CelonisのContext ModelはOperationsの現在状態と、その背景となる履歴をDigital Twinとして扱う。[6][7]

TCSはBusiness Knowledge Fabricとして企業・業界・Process ContextをAgentへ供給する。[8]

Spirit Airlinesの事例は、破産手続中の企業Business DataがAI用途を含む取引対象になり得ることを示すが、それだけで倒産企業Data市場の一般性やManagement Trajectoryの市場価格を証明するものではない。[9][10]

ここから本稿が提示する仮説は、

Corporate Data Asset
→ Corporate Memory Asset
→ Management Trajectory
→ Enterprise Management Embedding

という企業経験の構造化が、将来の企業AIにとって重要になる可能性である。

Corporate Afterlife、Corporate Memory DD、Context Lock-inなどは、その仮説から派生する将来論であり、現時点の確立した市場慣行ではない。

したがってAIの競争軸は、

「最も高性能なModelを誰が利用するか」

だけではなく、

「自社の正本・履歴・関係・権限を壊さず、必要な経験をどれだけ正確に次の仕事へ引き継げるか」

という方向にも広がっていく可能性がある。

付属アトラスの位置付け

本稿には二つの比較アトラスを付属資料として用いる。

• 62事例版：本稿内の正典アトラス
  企業・組織の公式資料や一次資料を中心に、製品・構想・実装を比較する。個別企業・製品の事実確認ではこちらを優先する。ただし「正典」は本稿内のcanonical reference setという意味で、第三者による真実認定を意味しない。

• 88件版：補助記事アトラス
  世界各地域の記事、論考、公式解説、研究資料を広く収録し、用語や論点の広がりを見るために使用する。2026年8月29日の最新版では、採用78件、補助のみ7件、除外3件として管理している。

両アトラスには同一企業・同一テーマの重複があるため、62＋88＝150件の独立観測とは扱わない。

この二層化によって、

個別事実の確認に使う資料 と 議論の広がりを探索する資料

を分離する。

参考資料

1. Genspark, “Introducing Genspark AI Workspace 6.0,” 2026-07-20
   https://www.genspark.ai/blog/genspark-ai-workspace-6

2. Microsoft Learn, “Work IQ MCP overview”
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/use-work-iq

3. Atlassian, “AI that knows your business,” 2026-07-07
   https://www.atlassian.com/blog/company-news/closing-the-ai-context-gap

4. Atlassian, “Atlassian Teamwork Graph: The context engine behind your AI—everywhere,” 2026-05-06
   https://www.atlassian.com/blog/company-news/teamwork-graph-team-26

5. Atlassian, “Our Q4 FY26 letter to shareholders,” 2026-08-06
   https://www.atlassian.com/blog/announcements/shareholder-letter-q4fy26

6. Celonis, “The Celonis Context Model”
   https://www.celonis.com/platform/context-model

7. Celonis, “Finally Enterprise AI gets the context it needs to succeed, Celonis:NEXT 2026”
   https://www.celonis.com/blog/finally-enterprise-ai-gets-the-context-it-needs-to-succeed-celonis-next-2026

8. TCS, “Agentic AI and Business Knowledge Fabric for BPS Transformation”
   https://www.tcs.com/insights/blogs/agentic-ai-business-knowledge-fabric-bps-transformation

9. Reuters, “Google to buy Spirit Airlines business data for $10 million,” 2026-08-17
   https://www.reuters.com/legal/litigation/google-buy-spirit-airlines-business-data-10-million-2026-08-17/

10. Reuters, “US court delays hearing on Google's purchase of Spirit Airlines data as union objects,” 2026-08-19
    https://www.reuters.com/legal/litigation/us-court-delays-hearing-googles-purchase-spirit-airlines-data-union-objects-2026-08-19/

11. WIRED, “Spirit Airlines Wants to Sell Its Data to Google. Former Flight Attendants Are Freaked Out,” 2026-08
    https://www.wired.com/story/spirit-airlines-wants-to-sell-its-data-to-google-former-flight-attendants-are-freaked-out