『GEOI完全開発』――Generative Ecology Organism Integrity――人間・AI・Agent・記憶・知識・組織・環境を接続する生成生態系統合体の設計・技術仕様・全実装コードと、Realityから最適知能アーキテクチャを発見するEngineering Science（第2回）（第Ⅰ部　DEFINITION 第1章　GEOIを定義する）

第Ⅰ部　DEFINITION

序章では、GEOIをAI・AGI・ASIとは異なるArchitecture仮説として位置づけ、既存システムとの境界と、その分類自体を反証対象に置いた。

ここからは、その仮説を実装可能な定義へ変換する。

GEOIを、

[
\boxed{
Generative\ Ecology\ Organism\ Integrity
}
]

あるいは「生成生態系統合体」と呼ぶだけでは、まだEngineering Objectにはならない。

必要なのは、

[
\boxed{
Concept
\rightarrow
Definition
\rightarrow
Operational\ Definition
}
]

への変換である。

何を一つのSystemとして観測するのか。

何をComponentとするのか。

Component間のRelationをどのように表現するのか。

作用結果をどのようにFeedbackとして戻すのか。

Feedbackによって何がAdaptationするのか。

そして、変化し続けるSystemがどのようにIntegrityを維持するのか。

第Ⅰ部では、この六つの問いを順に分解する。

[
\boxed{
System
\rightarrow
Component
\rightarrow
Relation
\rightarrow
Feedback
\rightarrow
Adaptation
\rightarrow
Integrity
}
]

そして最後に、それらを観測可能な条件へ統合する。

重要なのは、定義によってGEOIを成立させないことである。

例えば「複数のAIが接続されている」「人間が参加している」「Memoryを持っている」という個別条件だけでは、GEOIとは判定しない。

本書が必要とするのは、構成要素の存在ではなく、それらが時間の中でどのような因果構造を形成しているかである。

[
\boxed{
Components
\rightarrow
Relations
\rightarrow
Interaction
\rightarrow
Feedback
\rightarrow
Adaptation
\rightarrow
System_{t+1}
}
]

したがってGEOIは静的な構成図としてではなく、

[
\boxed{
GEOI(t)
}
]

として定義される。

さらに、この定義は後続章のArchitecture、Technical Specification、Repository、Code、Experimentへ直接翻訳できなければならない。

定義された概念がDatabase SchemaにもAPIにもRuntimeにもEvaluationにも変換できないなら、それは本書における工学的定義として不十分である。

同時に、

[
\boxed{
Necessary\ Conditions
\neq
Sufficient\ Conditions
}
]

を維持する。

System、Component、Relation、Feedback、Adaptation、IntegrityはGEOIを成立させる候補条件である。しかし、それらを備えたすべてのシステムをGEOIと呼べるとはまだ決めない。

十分条件は実装と比較実験によって絞り込まれる。

したがって第Ⅰ部の目的は、GEOIを言葉によって固定することではない。

[
\boxed{
\textbf{
GEOIという仮説を、
コードによって実装でき、
測定によって判定でき、
Realityによって否定できる定義へ変換すること
}
}
]

である。

概念から実装へ進む最初の境界が、DEFINITIONである。
第1章　GEOIを定義する

第1節　System

GEOIを定義する最初の単位は、AIでもAgentでも人間でもない。

[
\boxed{
System
}
]

である。

なぜならGEOIが検証しようとしているのは、個々の構成要素がどれほど高性能かではなく、それらが相互作用したときに、全体としてどのような能力、状態変化、失敗、適応が生じるかだからである。

したがってGEOIの最初の問いは、

[
\boxed{
\text{何を一つのSystemとして観測するのか}
}
]

となる。

この問いに答えなければ、CapabilityもCostもFeedbackもIntegrityも測定できない。

⸻

1　Systemとは何か

本書ではSystemを、相互作用する複数の構成要素からなり、一定のBoundaryの内部で状態を持ち、Environmentから入力を受け、内部処理を経て作用し、その結果によって次の状態へ遷移する対象として扱う。

最小表現は、

[
\boxed{
S_t
\xrightarrow{Input,\ Operation}
S_{t+1}
}
]

である。

ただし、GEOIでは外部環境との相互作用を明示する必要がある。

[
\boxed{
(S_t,E_t)
\xrightarrow{Interaction}
(S_{t+1},E_{t+1})
}
]

ここで、

[
S_t=System\ State
]

[
E_t=Environment\ State
]

である。

SystemはEnvironmentを観測する。

Systemが行動する。

行動によってEnvironmentが変化する。

変化したEnvironmentが再びSystemへ入力される。

したがって、

[
\boxed{
System
\leftrightarrow
Environment
}
]

という閉じた相互作用を観測対象にする。

GEOIは単なる情報処理装置ではなく、この循環内部に存在する動的Systemとして定義される。

⸻

2　System Boundaryを置く

Systemを定義するにはBoundaryが必要である。

例えば企業内GEOIを研究する場合、

AIモデルだけをSystemとするのか。

AIとAgentまで含めるのか。

MemoryとKnowledge Baseまで含めるのか。

従業員を含めるのか。

組織構造を含めるのか。

顧客を含めるのか。

外部CloudやFoundation Model Providerを含めるのか。

System Boundaryの位置によって、同じ現象の説明が変わる。

[
\boxed{
Observation

f(System\ Boundary)
}
]

だからである。

例えば外部AI APIをBoundary外へ置けば、その利用料金はOperating Costとして見える。

しかしProvider側のTraining ComputeまでBoundaryを広げれば、System全体の資源消費は異なる。

同様に、人間をBoundary外へ置けば「自律的AI」に見える処理でも、実際には大量のHuman Operationによって成立している可能性がある。

したがって本書では、

[
\boxed{
Boundary\ Assumption
}
]

をすべての主要実験で明示する。

Boundaryを隠した比較は行わない。

⸻

3　GEOIはOpen Systemである

GEOIは原則としてClosed Systemではない。

外部から情報、資源、要求、制約、環境変化を受け取り、外部へ作用する。

したがって、

[
\boxed{
GEOI

Open\ Dynamic\ System
}
]

として扱う。

入力には、

Data、

Human Request、

Sensor Observation、

External Event、

Knowledge Update、

Resource Availability

などが存在し得る。

出力も単なるTextではない。

Decision、

Action、

Software Change、

Organizational Action、

Physical Action、

Environment Change

などを含む。

そのため、

[
Input
\rightarrow
Output
]

ではなく、

[
\boxed{
Observe
\rightarrow
Interpret
\rightarrow
Decide
\rightarrow
Act
\rightarrow
Outcome
\rightarrow
Observe’
}
]

として記述する方がGEOIに適している。

このLoopが時間方向へ継続することで、

[
GEOI_t
\rightarrow
GEOI_{t+1}
\rightarrow
GEOI_{t+2}
\rightarrow\cdots
]

というSystem Historyが形成される。

⸻

4　System Stateを分解する

GEOIの状態をModel Stateだけで表現することはできない。

候補的には、

[
\boxed{
S_t=
(
M_t,
Mem_t,
K_t,
R_t,
A_t,
O_t,
P_t,
E_t
)
}
]

と記述できる。

ここで、

(M_t) はModel State、

(Mem_t) はMemory State、

(K_t) はKnowledge State、

(R_t) はRelation State、

(A_t) はAgent State、

(O_t) はOrganization State、

(P_t) はPolicy・Authority State、

(E_t) は観測されたEnvironment Stateを表す。

重要なのは、GEOIの状態が単一の場所に保存される必要はないことである。

一部はModelにある。

一部はDatabaseにある。

一部はKnowledge Graphにある。

一部は人間にある。

一部は組織制度にある。

一部は物理環境そのものにある。

したがって、

[
\boxed{
System\ State
\neq
Database\ State
\neq
Model\ State
}
]

である。

GEOIを測定するには、この分散した状態をどこまで観測可能にするかが重要になる。

⸻

5　System-level Capability

GEOIで評価するCapabilityも、Component Capabilityと区別する。

モデル単体の能力を、

[
C_M
]

とする。

Agentの能力を、

[
C_A
]

とする。

人間の能力を、

[
C_H
]

とする。

しかしSystem Capabilityを、

[
C_S=C_M+C_A+C_H
]

と単純加算することはできない。

構成要素間には補完、重複、競合、阻害が存在するからである。

したがって、

[
\boxed{
C_S

f(
Components,
Relations,
Coordination,
Environment,
Feedback,
Time
)
}
]

と考える。

優秀なComponentを増やしても、Coordinationが悪ければSystem Capabilityは低下し得る。

逆に個々のComponentが限定的でも、役割分担と関係構造が適切なら、高いSystem Capabilityを形成する可能性がある。

この非加法性こそ、Systemを独立した観測単位にする理由である。

⸻

6　System Failureも全体で測る

同じことはFailureにも当てはまる。

各Componentが正常でも、System全体が失敗することがある。

例えば、

Modelは正しい。

Memoryも正しい。

Knowledgeも正しい。

Agentも仕様どおり動いた。

しかしAuthority設計が誤っていたため、実行してはいけないActionが実行された。

これは、

[
\boxed{
Component\ Success
+
Component\ Success
+\cdots
\not\Rightarrow
System\ Success
}
]

を意味する。

逆に、一つのComponentが故障しても、FallbackやHuman OverrideによってSystem Outcomeを維持できる場合がある。

[
\boxed{
Component\ Failure
\not\Rightarrow
System\ Failure
}
]

である。

したがってGEOIでは、

Reliability、

Resilience、

Recovery、

Traceability

をSystem Levelで測定する。

Integrityが必要になる理由もここにある。

⸻

7　GEOIのSystem条件

以上から、本書におけるGEOIのSystemを暫定的に次のように定義する。

[
\boxed{
GEOI\ System

\text{複数の異質なComponentがRelationによって接続され、}
\atop
\text{Environmentを観測し、内部状態に基づいて作用し、}
\atop
\text{そのOutcomeをFeedbackとして受け取りながら、}
\atop
\text{時間とともにSystem Stateを変化させるOpen Dynamic System}
}
]

ただし、この定義だけではGEOIは成立しない。

通常のEnterprise System、Multi-Agent System、Cyber-Physical Systemにも、この条件を満たすものが存在するからである。

したがってSystemは、

[
\boxed{
Necessary\ Candidate
}
]

であって、

[
\boxed{
Sufficient\ Condition
}
]

ではない。

ここから、

[
System
\rightarrow
Component
\rightarrow
Relation
\rightarrow
Feedback
\rightarrow
Adaptation
\rightarrow
Integrity
]

と条件を追加し、最終的にOperational Definitionへ到達する。

最初にSystemを置く理由は明確である。

本書が知りたいのは、

[
\boxed{
\textbf{最も賢いComponentは何か}
}
]

だけではない。

問うのは、

[
\boxed{
\textbf{
どのBoundaryの中に、
どのComponentを配置し、
どのRelationで接続したとき、
Reality上で最も有効な知能Systemが成立するのか
}
}
]

である。

GEOIの最小単位は、知能そのものではない。

[
\boxed{\textbf{知能が生成され、作用し、検証されるSystem}}
]

なのである。
第2節　Component

Systemを定義したなら、次にその内部を分解する必要がある。

GEOIは一つの巨大な知能主体を前提としない。異なる能力、状態、権限、役割を持つ複数の構成要素が、一つのSystem Boundaryの内部で相互作用するArchitectureとして出発する。

その最小の設計単位を、本書では、

[
\boxed{
Component
}
]

と呼ぶ。

重要なのは、ComponentをAIだけに限定しないことである。

[
\boxed{
Component
\in
{
Human,
Model,
Agent,
Memory,
Knowledge,
Organization,
Tool,
Runtime,
Environment\ Interface,\ldots
}
}
]

GEOIでは、これらを最初から同一のものとして扱うのではない。

むしろ異質性を保持したまま、それぞれが何を担当し、何を知り、何を実行でき、他のComponentとどのように接続されるかを明示する。

⸻

1　ComponentはSystemの部分である

Componentは、System Boundary内部で一定の機能または状態を担う識別可能な単位である。

Systemを、

[
S={C_1,C_2,\ldots,C_n}
]

と単純化すると、

[
C_i
]

がComponentに相当する。

しかしGEOIでは、Componentの集合だけではSystemを説明できない。

[
\boxed{
System
\neq
\sum_i C_i
}
]

だからである。

同じComponentを持つ二つのSystemでも、接続方法、権限、情報流、Feedback、実行順序が異なれば、System Behaviorは異なる。

したがってComponentはGEOIの必要な構成単位ではあるが、GEOIの能力そのものではない。

Componentを定義する目的は、全体を分割することではなく、

[
\boxed{
\text{どの能力と状態が、どこに存在するのか}
}
]

を追跡可能にすることである。

⸻

2　HumanもComponentである

GEOIでは、人間を単なるUserとしてSystem外部へ置かない場合がある。

人間は、

目的設定、

判断、

承認、

専門知識、

例外処理、

価値判断、

責任、

創造、

環境認識

などを担う。

したがって、

[
\boxed{
Human
\in
Components(GEOI)
}
]

となり得る。

ただし、人間をComponentと呼ぶことは、人間を機械部品へ還元することを意味しない。

工学上必要なのは、人間のすべてをモデル化することではなく、

[
\boxed{
Human\text{-}System\ Interaction
}
]

に関係する状態と権限を明示することである。

例えば、

誰が最終承認者か。

どの情報を閲覧できるか。

どのActionを停止できるか。

どの判断をAIへ委任できるか。

どこでHuman Overrideが発生するか。

これらをArchitectureへ組み込む。

人間を暗黙の外部作業者として隠さないことは、CapabilityとCostを正確に測定するうえでも重要である。

⸻

3　ModelとAgentを分離する

GEOIではModelとAgentを同一視しない。

Modelは主として、

[
Input
\rightarrow
Inference
\rightarrow
Output
]

を担うIntelligence Componentである。

一方Agentは、

[
Observe
\rightarrow
Reason
\rightarrow
Plan
\rightarrow
Tool\ Use
\rightarrow
Action
]

という実行Loopを管理する。

したがって、

[
\boxed{
Model\neq Agent
}
]

である。

一つのAgentが複数Modelを利用してもよい。

[
Agent_A
\rightarrow
{Model_1,Model_2,Model_3}
]

逆に複数Agentが一つのModelを共有してもよい。

[
{Agent_1,Agent_2,Agent_3}
\rightarrow
Model_A
]

この分離によって、Modelを交換してもAgent Logicを保持したり、Agent Architectureを変更してもModelを固定したりできる。

これは後のAblationやModel Dependency実験に不可欠である。

⸻

4　MemoryとKnowledgeを分離する

MemoryとKnowledgeも同一ではない。

Memoryは、Systemが経験した過去の状態、Interaction、Decision、Outcomeなどを保持する。

[
\boxed{
Memory

Recorded\ System\ History
}
]

一方Knowledgeは、Systemが判断に利用する構造化・非構造化された外部または内部の知識資源である。

[
\boxed{
Knowledge

Information\ available\ for\ reasoning\ and\ action
}
]

例えば、

「昨日この顧客と何を話したか」

はMemoryに近い。

「この製品の仕様は何か」

はKnowledgeに近い。

両者を分離することで、

[
Experience
\rightarrow
Memory
]

と、

[
Evidence
\rightarrow
Knowledge
]

を異なる更新経路として管理できる。

さらに、

[
Memory
\rightarrow
Knowledge
]

への変換には検証が必要になる場合がある。

一度経験したことが、そのまま一般的知識になるとは限らないからである。

⸻

5　Organizationも実装対象になる

GEOIにおいてOrganizationは背景ではない。

企業、研究組織、行政、医療機関などでは、同じAIと同じDataを利用していても、権限構造とProcessが異なればOutcomeは変化する。

Organization Componentには、

Role、

Authority、

Responsibility、

Policy、

Approval Flow、

Resource Allocation

などが含まれる。

例えば、

[
Agent
\rightarrow
Action
]

ではなく、

[
Agent
\rightarrow
Proposal
\rightarrow
Human\ Approval
\rightarrow
Action
]

とするかもしれない。

高リスク操作では、

[
AI\ Decision
\neq
Execution\ Authority
]

と明示的に分離する。

このようにOrganizationをArchitecture内部へ入れることで、AI Governanceを外付けの規則ではなく、Runtimeで強制可能な構造へ翻訳できる。

⸻

6　ComponentにはInterfaceが必要である

Componentが存在するだけでは相互作用できない。

各Componentには、

[
\boxed{
Interface
}
]

が必要になる。

Component (C_i) を、

[
\boxed{
C_i=
(State_i,
Capability_i,
Interface_i,
Authority_i)
}
]

として暫定的に表現できる。

Stateは、そのComponentが現在保持している状態。

Capabilityは、実行可能な処理。

Interfaceは、他Componentとの入出力方法。

Authorityは、実行を許可された範囲である。

例えばAgentがDatabaseへアクセスできるとしても、

Read、

Write、

Delete

は異なるAuthorityである。

人間についても、

Observe、

Approve、

Override、

Configure

などを分離できる。

これによって、

[
\boxed{
Can\ Do
\neq
May\ Do
}
]

をArchitectureとして表現できる。

能力と権限を分離することは、GEOIのIntegrityに直結する。

⸻

7　Componentは交換可能でなければならないのか

GEOIの重要な研究仮説の一つは、少なくとも一部のComponentを交換可能にできることである。

例えば、

[
Model_A
\rightarrow
Model_B
]

としても、

[
Memory,\ Knowledge,\ Relations,\ Authority,\ History
]

を保持する。

そのときSystem Capabilityがどこまで維持されるかを測定する。

同様に、

[
Agent_A\rightarrow Agent_B
]

[
VectorDB_A\rightarrow VectorDB_B
]

[
Cloud_A\rightarrow Cloud_B
]

などの置換可能性を検証できる。

ただし、すべてを完全に交換可能にすること自体を目的にはしない。

交換可能性を高めるための抽象化が、性能低下やIntegration Costを生む可能性があるからである。

したがって、

[
\boxed{
Replaceability
\leftrightarrow
Performance
\leftrightarrow
Integration\ Cost
}
]

のTrade-offを測定する。

GEOIにおけるComponent設計とは、部品を増やすことではない。

[
\boxed{
\textbf{
知能・記憶・知識・行動・権限・責任が
System内部のどこに存在しているのかを、
交換・測定・検証可能な単位へ分解すること
}
}
]

である。

この分解によって初めて、後に問うことができる。

モデルを除いたら何が失われるのか。

Memoryを除いたら何が失われるのか。

人間を除いたら何が失われるのか。

Organizationを変更したら何が変わるのか。

そして、

[
\boxed{
\textbf{
観測されたSystem Capabilityのうち、
どのComponentが、どれだけ寄与していたのか。
}
}
]

Componentを定義することは、GEOIを部品へ解体することではない。

それは、次に扱う、

[
\boxed{
Relation
}
]

によって、部分がどのように一つのSystem Capabilityへ変換されるのかを測定するための準備なのである。
第3節　Relation

Componentを定義しただけでは、GEOIは成立しない。

Human、Model、Agent、Memory、Knowledge、Organization、Tool、Runtimeが同じSystem Boundaryの内部に存在していても、相互作用しなければ、それらは単なる集合である。

したがってGEOIの次の基本単位は、

[
\boxed{
Relation
}
]

である。

本書におけるRelationとは、抽象的な「つながり」を意味しない。二つ以上のComponentの間で、情報、状態、権限、要求、資源、作用、結果などがどのように伝達されるかを規定する、観測・実装可能な関係である。

GEOIの中心仮説の一つは、System CapabilityがComponent Capabilityだけでは決まらず、Relationの構造によって変化するというものである。

[
\boxed{
System\ Capability

f(
Components,
Relations
)
}
]

ここから、「知能はComponentだけに存在するのか、それともRelationにも存在するのか」という本書の中心的な実験問題が始まる。

⸻

1　集合からNetworkへ

Component集合を、

[
V={C_1,C_2,\ldots,C_n}
]

とする。

Componentが存在するだけなら、これは単なる集合である。

ここにRelationを加える。

[
E={R_{ij}}
]

すると、

[
\boxed{
G=(V,E)
}
]

というNetworkとしてSystemを記述できる。

しかし、すべてのRelationが同じ意味を持つわけではない。

例えば、

[
Human\rightarrow Agent
]

というEdgeは、Instructionかもしれない。

[
Agent\rightarrow Database
]

はQueryかもしれない。

[
Organization\rightarrow Agent
]

はAuthorityかもしれない。

[
Environment\rightarrow Sensor
]

はObservationかもしれない。

したがってRelationは、

[
\boxed{
R_{ij}

(Type,\ Direction,\ Protocol,\ Authority,\ State)
}
]

のような属性を持つ。

単に「接続されているか」ではなく、

[
\boxed{
\text{誰が、誰に、何を、どの条件で、どの方向へ渡せるのか}
}
]

まで定義する必要がある。

⸻

2　Relationには種類がある

GEOIでは少なくとも複数種類のRelationを区別する。

Information Relationは、情報がどこからどこへ流れるかを表す。

[
Knowledge\rightarrow Agent
]

Memory Relationは、経験の記録・検索・更新を表す。

[
Agent\leftrightarrow Memory
]

Authority Relationは、誰が誰に何を許可できるかを表す。

[
Human\rightarrow Agent
]

Execution Relationは、どのComponentが現実のActionを実行できるかを表す。

[
Agent\rightarrow Tool
]

Observation Relationは、Environmentの状態をどこが取得するかを表す。

[
Environment\rightarrow Sensor\rightarrow System
]

Feedback Relationは、Actionの結果が次のDecisionへ戻る経路を表す。

[
Outcome\rightarrow Memory\rightarrow Decision’
]

この区別がなければ、NetworkのEdge数だけを数えてもSystemの意味は分からない。

したがって、

[
\boxed{
Relation\ Quantity
\neq
Relation\ Quality
}
]

である。

⸻

3　Relationは方向を持つ

GEOIではDirectionも重要である。

例えば、

[
Agent\rightarrow Human
]

と、

[
Human\rightarrow Agent
]

は異なる。

前者は提案や報告であり、後者は指示や承認かもしれない。

同様に、

[
Model\rightarrow Memory
]

への無制限な書込みを許すArchitectureと、

[
Model
\rightarrow
Candidate\ Memory
\rightarrow
Verification
\rightarrow
Memory
]

というArchitectureでは、長期的なSystem Stateが大きく異なる。

したがってRelationは、

[
\boxed{
Directed
}
]

である場合が多い。

双方向Relationであっても、

[
R_{ij}\neq R_{ji}
]

となり得る。

情報の流れ、権限、信頼、責任は必ずしも対称ではないからである。

⸻

4　Relationは時間とともに変化する

GEOIのRelationを固定Graphとして扱うだけでも不十分である。

人間が役割を変更する。

Agentが追加される。

Modelが交換される。

Knowledge Sourceの信頼性が低下する。

APIが停止する。

Security Policyが変更される。

あるAgentの権限が縮小される。

したがって、

[
\boxed{
G_t=(V_t,E_t)
}
]

としてRelation Graph自体が時間変化する。

さらに、

[
\boxed{
R_{ij}(t)
}
]

を考える必要がある。

これはGEOIにおけるAdaptationの重要な候補になる。

適応とはModel Weightを更新することだけではない。

[
\boxed{
Relation_t
\rightarrow
Relation_{t+1}
}
]

もSystem Learningになり得る。

例えば、特定のTaskでModel Aの失敗率が高ければ、Routing RelationをModel Bへ変更する。

あるAgentの誤操作が増えればAuthority Relationを縮小する。

特定のHuman Expertが高い精度を示せば、その領域のEscalation Relationを変更する。

GEOIは、このRelation Updateを明示的なSystem State Transitionとして扱う。

⸻

5　RelationはCapabilityを増やすとは限らない

接続を増やせばSystemが賢くなる、という前提は置かない。

Relationが増加すれば、

Communication Cost、

Coordination Cost、

Latency、

Conflict、

Security Surface、

Failure Propagation

も増加し得る。

概念的には、

[
C_{integration}

f(
|V|,
|E|,
Heterogeneity,
ChangeRate,
Coordination
)
]

となる。

したがって、

[
\boxed{
More\ Relations
\not\Rightarrow
More\ Capability
}
]

である。

重要なのは、

[
\boxed{
Marginal\ Relation\ Benefit
}
]

と、

[
\boxed{
Marginal\ Relation\ Cost
}
]

を比較することである。

ある点を超えると、

[
Marginal\ Cost

Marginal\ Capability
]

になる可能性がある。

この境界は、後に第6章でOptimal Integration Pointとして測定する。

GEOIは最大接続Architectureではない。

[
\boxed{
\textbf{必要なCapabilityを生成するための最適なRelation Architecture}
}
]

を探索する。

⸻

6　Relationの寄与を実験する

RelationがSystem Capabilityへ本当に寄与しているなら、その寄与は介入によって観測できなければならない。

同じComponent集合を固定する。

[
V_A=V_B
]

そのうえでRelationだけを変更する。

[
E_A\neq E_B
]

そして、

[
Capability(G_A)
]

と、

[
Capability(G_B)
]

を比較する。

もし、

[
\boxed{
V_A=V_B,\quad
E_A\neq E_B,\quad
Capability_A\neq Capability_B
}
]

が再現可能に観測されるなら、Capability差の一部をRelation Architectureへ帰属できる可能性が生まれる。

さらにRelation Ablationを行う。

[
GEOI-R_{Human,Agent}
]

[
GEOI-R_{Agent,Memory}
]

[
GEOI-R_{Outcome,Feedback}
]

などを比較する。

これによって、

[
\boxed{
\Delta C_{R_{ij}}

C(GEOI)

C(GEOI-R_{ij})
}
]

を測定できる。

「関係が重要である」という主張を、初めて実験可能な命題へ変換できる。

⸻

7　知能はRelationに存在するのか

ここで本書の最も重要な問いの一つへ到達する。

従来の単純化された見方では、

[
\boxed{
Intelligence
\in
Model
}
]

と考えることができる。

GEOIは、これを否定するのではない。

モデル内部に高度なCapabilityが存在することは前提として認める。

しかし、それだけでReality上の知能を説明できるかを問う。

対立する候補仮説は、

[
\boxed{
Delivered\ Intelligence
\in
Relations(
Model,
Human,
Memory,
Knowledge,
Agent,
Organization,
Environment
)
}
]

である。

より慎重には、

[
\boxed{
Delivered\ Intelligence

f(
Component\ Capability,
Relation\ Architecture,
Environment,
Time
)
}
]

と表現できる。

この式が正しいなら、知能開発の最適化問題も変化する。

[
\boxed{
\text{Componentを巨大化する}
}
]

だけではなく、

[
\boxed{
\text{Component間のRelationを最適化する}
}
]

という独立したEngineering Variableが現れる。

しかし、この仮説もRealityによって否定可能である。

Relationを変更してもCapabilityがほとんど変化しないなら、Relationの説明力は小さい。

Integration Costだけが増加するなら、複雑なGEOI Architectureは不要である。

逆に同一ComponentでもRelation Architectureを変えることで、Capability、Cost、Reliability、Adaptationに大きな差が再現されるなら、RelationはGEOIの中心的設計対象となる。

したがってGEOIにおけるRelationとは、思想的な「つながり」ではない。

[
\boxed{
\textbf{
Component間で情報・権限・作用・状態を伝達し、
System Behaviorを変化させる、
方向・種類・条件・時間を持った実装可能な関係
}
}
]

である。

そして、このRelationが一方向の伝達で終わらず、Actionの結果をSystemへ戻し始めたとき、

[
\boxed{
Relation
\rightarrow
Feedback
}
]

が成立する。

GEOIはここから、接続されたSystemから、結果によって自らの次状態を変えるSystemへ移行する。
第4節　Feedback

RelationによってComponentが接続されても、情報と作用が一方向に流れるだけなら、Systemは過去の結果から自らを変えることができない。

GEOIが静的な統合Systemから動的なSystemへ移る境界が、

[
\boxed{
Feedback
}
]

である。

本書におけるFeedbackとは、Systemが行ったDecisionやActionの結果を観測し、その情報を再びSystem内部へ戻す因果経路を指す。

最小構造は、

[
\boxed{
State_t
\rightarrow
Decision_t
\rightarrow
Action_t
\rightarrow
Outcome_{t+1}
\rightarrow
Observation_{t+1}
}
]

である。

そしてObservationが次のDecisionへ影響するとき、

[
\boxed{
Observation_{t+1}
\rightarrow
Decision_{t+1}
}
]

Loopが閉じる。

GEOIにとって重要なのは、出力を生成したことではない。

出力の結果を知り、その結果を次の状態へ戻せることである。

⸻

1　OutputとFeedbackは異なる

AIシステムが回答を生成しても、それだけではFeedbackは成立しない。

例えば、

[
Input
\rightarrow
Model
\rightarrow
Output
]

では、SystemはOutputの後に何が起きたかを知らない。

生成されたコードが動いたのか。

提案が採用されたのか。

判断が正しかったのか。

顧客が満足したのか。

Environmentがどのように変化したのか。

これらを観測しなければ、次のDecisionを修正できない。

したがって、

[
\boxed{
Output\neq Outcome
}
]

であり、

[
\boxed{
Outcome\neq Feedback
}
]

でもある。

Outcomeが発生し、それが観測され、System内部へ戻され、次の処理に利用可能になって初めてFeedbackが成立する。

[
\boxed{
Output
\rightarrow
Outcome
\rightarrow
Observation
\rightarrow
Feedback
}
]

この区別はGEOIのOperational Definitionに不可欠である。

⸻

2　Feedback Loopを閉じる

Feedbackの基本構造はControl Systemとして記述できる。

目的状態を、

[
r_t
]

観測された状態を、

[
y_t
]

とする。

その差、

[
e_t=r_t-y_t
]

を評価し、次のActionを変更する。

[
\boxed{
Error
\rightarrow
Correction
\rightarrow
New\ Action
}
]

である。

しかしGEOIでは、単一の制御量だけを扱うとは限らない。

例えば企業Systemでは、

Accuracy、

Latency、

Cost、

Customer Outcome、

Risk、

Human Approval、

System Reliability

など複数の指標が同時に存在する。

したがって、

[
\boxed{
Feedback_t

f(
Outcome,
Goal,
Constraint,
Risk,
Human\ Evaluation,
Environment
)
}
]

となる。

GEOIは、単純な正解・不正解だけではなく、多変量のFeedbackを処理する必要がある。

⸻

3　Feedbackには複数の時間尺度がある

すべてのFeedbackが同じ速度で戻るわけではない。

ミリ秒単位では、Runtime ErrorやLatencyが返る。

秒・分単位では、Tool ExecutionやTask Resultが返る。

日単位では、Human Reviewや業務Outcomeが観測される。

月・年単位では、組織Performanceや長期的なEnvironment Changeが現れる。

したがって、

[
\boxed{
Feedback

{
F_{\mathrm{ms}},
F_{\mathrm{s}},
F_{\mathrm{day}},
F_{\mathrm{month}},
F_{\mathrm{year}}
}
}
]

のような複数時間尺度を持ち得る。

短期Feedbackだけを最適化すると、長期Outcomeを悪化させる可能性がある。

例えば処理速度を最大化した結果、Human Reviewが省略され、長期的なFailure Costが増えることもある。

したがってGEOIでは、

[
\boxed{
Local\ Optimization
\neq
System\ Optimization
}
]

を前提とする。

Feedback Architectureは時間軸を持たなければならない。

⸻

4　Human Feedbackも一つのComponent Relationである

GEOIではHuman Feedbackを特別な外部処理として扱わない。

人間もSystem Boundary内部のComponentである場合、

[
AI
\rightarrow
Human
\rightarrow
Evaluation
\rightarrow
System
]

というRelationとして記述できる。

人間は、

Approve、

Reject、

Correct、

Rank、

Explain、

Override

などのFeedbackを与える。

しかしHuman Feedbackも常に正しいとは限らない。

評価者間で意見が異なる。

専門性に差がある。

疲労や認知バイアスがある。

組織上の利害が影響する。

したがって、

[
\boxed{
Human\ Feedback
\neq
Ground\ Truth
}
]

である。

GEOIではHuman FeedbackもSource、Confidence、Authority、Contextを持つ観測値として管理する。

これは人間の価値を下げるためではない。

人間の判断を、どこで、なぜ、どの権限でSystemへ反映したのか追跡可能にするためである。

⸻

5　Feedbackの品質を測る

Feedbackが存在しても、品質が低ければSystemを悪化させる。

誤ったOutcomeを成功として記録する。

観測が遅すぎる。

原因と結果を誤って結びつける。

一部の指標だけを最適化する。

Feedback Dataが改ざんされる。

このような場合、

[
\boxed{
Feedback
\rightarrow
Maladaptation
}
]

が起こり得る。

したがってFeedbackには、

Accuracy、

Latency、

Coverage、

Attribution、

Reliability、

Traceability

が必要になる。

概念的には、

[
\boxed{
Q_F

f(
Accuracy,
Latency,
Coverage,
Attribution,
Reliability,
Traceability
)
}
]

としてFeedback Qualityを評価できる。

特にAttributionは重要である。

Outcomeが改善したとしても、それがModel、Human、Memory、Relation、Environmentのどの変化によるものか分からなければ、Systemは誤った更新を行う可能性がある。

⸻

6　FeedbackとLearningを混同しない

Feedbackを受け取っただけでは、Systemが学習したことにはならない。

[
\boxed{
Feedback\neq Learning
}
]

である。

例えば失敗をLogへ保存しても、次回の行動が変わらなければSystem Behaviorは同じである。

Feedbackが、

Memory Update、

Knowledge Update、

Policy Update、

Relation Update、

Routing Update、

Model Update

などへ変換されて初めて、次のSystem Stateが変化する。

[
\boxed{
Feedback
\rightarrow
Update
\rightarrow
Behavioral\ Change
}
]

この過程が次節で扱うAdaptationである。

したがって、

[
Feedback
\rightarrow
Adaptation
]

の間には、EvaluationとUpdate Ruleが必要になる。

何を変えるのか。

誰が変更を許可するのか。

変更後に性能が悪化した場合、戻せるのか。

ここからFeedbackはIntegrityとも接続する。

⸻

7　FeedbackによってSystemは時間を持つ

Feedbackを持たないSystemでは、一回ごとの処理が独立している。

しかしFeedbackが閉じると、過去のOutcomeが未来のDecisionへ影響する。

[
\boxed{
Past\ Outcome
\rightarrow
Present\ State
\rightarrow
Future\ Action
}
]

ここでGEOIは履歴を持つ。

同じInputであっても、過去の経験が異なれば異なるActionを選択する可能性が生まれる。

したがって、

[
GEOI_t
\neq
GEOI_{t+1}
]

となり得る。

この時間性は、GEOIを単なるModel WrapperやWorkflowから区別する候補条件の一つになる。

しかしFeedback Loopを持つ既存Systemは多数存在する。

したがってFeedbackだけでもGEOIの十分条件にはならない。

本書で重要なのは、

[
\boxed{
Feedback
\rightarrow
Measurable\ System\ Change
}
]

が存在するかである。

そのため後の実験ではFeedbackを切断し、

[
GEOI_{closed-loop}
]

と、

[
GEOI_{open-loop}
]

を比較する。

もし両者の長期Capability、Failure、Cost、Adaptationに差がなければ、Feedbackの寄与は小さい。

逆にFeedbackを閉じることで、同じComponentとModelでもSystem Outcomeが継続的に改善するなら、その寄与を測定できる。

GEOIにおけるFeedbackとは、単なる利用者評価でも、ログ保存でもない。

[
\boxed{
\textbf{
SystemのActionがRealityに生んだOutcomeを観測し、
その差分を次のSystem Stateへ戻す因果Loop
}
}
]

である。

RelationによってSystemは接続される。

Feedbackによって、その接続は循環になる。

そして、その循環がSystem自身の状態を変更し始めたとき、

[
\boxed{
Feedback
\rightarrow
Adaptation
}
]

が成立する。

GEOIはここから、結果を受け取るSystemから、結果によって自らを変えるSystemへ進む。
第5節　Adaptation

FeedbackによってOutcomeがSystemへ戻っても、それだけではGEOIは変化しない。

失敗を記録する。

成功を評価する。

Environmentの変化を検知する。

人間から修正を受ける。

それらの情報が蓄積されても、次の判断と行動が変わらなければ、Systemは同じ構造を反復する。

FeedbackをSystem Stateの変化へ変換する過程が、

[
\boxed{
Adaptation
}
]

である。

本書におけるAdaptationとは、観測されたOutcomeやEnvironment Changeに応じて、System内部の状態、選択、関係、Policy、Knowledge、Memory、または構成そのものを変更し、将来のBehaviorを変化させる能力をいう。

最小構造は、

[
\boxed{
Feedback_t
\rightarrow
Update_t
\rightarrow
System_{t+1}
}
]

である。

GEOIが時間の中で同じSystemのままではなく、経験によって異なるSystemへ移行するための条件がAdaptationである。

⸻

1　AdaptationとLearningは同一ではない

AIにおいてLearningという語は、Model Parametersの更新を意味することが多い。

例えば、

[
\theta_t
\rightarrow
\theta_{t+1}
]

というWeight Updateである。

しかしGEOIでは、Modelを更新しなくてもSystem Behaviorを変えることができる。

例えば、

[
Memory_t\rightarrow Memory_{t+1}
]

[
Knowledge_t\rightarrow Knowledge_{t+1}
]

[
Policy_t\rightarrow Policy_{t+1}
]

[
Relation_t\rightarrow Relation_{t+1}
]

[
Routing_t\rightarrow Routing_{t+1}
]

といった変化がある。

したがって、

[
\boxed{
Model\ Learning
\subset
Possible\ Adaptation(GEOI)
}
]

である。

GEOIにおけるAdaptationは、Model Weightより広いSystem Stateの更新を対象にする。

⸻

2　何が適応するのか

GEOIのAdaptation対象は一つではない。

第一はMemory Adaptationである。

成功、失敗、判断、Interaction、Outcomeを記録し、次回の処理で利用可能にする。

第二はKnowledge Adaptationである。

新しいEvidenceを追加し、古いKnowledgeを更新し、矛盾や信頼性を管理する。

第三はPolicy Adaptationである。

失敗率、Risk、Human Evaluationなどに応じてDecision RuleやExecution Conditionを変更する。

第四はRelation Adaptationである。

どのAgentがどのModelを使用するか、どのKnowledge Sourceへ接続するか、どこでHuman Approvalを要求するかを変更する。

第五はComponent Adaptationである。

Model、Agent、Tool、Databaseなどを追加、交換、停止する。

第六はOrganization Adaptationである。

Role、Authority、Responsibility、Workflowそのものを変更する。

したがって、

[
\boxed{
Adaptation

f(
Memory,
Knowledge,
Policy,
Relation,
Component,
Organization
)
}
]

として扱う。

GEOIの学習対象は、モデルだけではなくArchitectureそのものへ拡張される。

⸻

3　Adaptationには速度がある

すべての更新を同じ速度で行う必要はない。

Memoryは秒単位で更新できる。

Routingは分・時間単位で変更できる。

Knowledge Baseは日単位で検証・更新されるかもしれない。

Organization Policyは週・月単位で変更される。

Model Trainingはさらに長い時間を必要とする場合がある。

したがって、

[
\boxed{
Adaptation

{
A_{fast},
A_{medium},
A_{slow}
}
}
]

という複数時間尺度を持つ。

この違いは重要である。

すべてをModel Retrainingで解決しようとすれば、CostとTimeが大きくなる可能性がある。

一方、すべてを即時Memory Updateで処理すれば、誤情報や局所的な失敗をSystem全体へ固定してしまう危険がある。

したがって、

[
\boxed{
Update\ Type

f(
Evidence,
Risk,
Reversibility,
Time\ Scale
)
}
]

として、何をどの速度で更新するかを設計する必要がある。

⸻

4　適応は改善とは限らない

Systemが変化したからといって、改善したとは限らない。

[
\boxed{
Adaptation
\neq
Improvement
}
]

である。

誤ったFeedbackからMemoryを更新する。

一時的なEnvironment Changeに過剰適応する。

局所的なKPIを改善するためにSystem全体を悪化させる。

Agentが誤った経験を一般化する。

Knowledge Driftが蓄積する。

こうした変化は、

[
\boxed{
Maladaptation
}
]

である。

したがって更新前後を、

[
S_t
\rightarrow
S_{t+1}
]

として保存し、

[
Capability(S_{t+1}),
\quad
Reliability(S_{t+1}),
\quad
Cost(S_{t+1}),
\quad
Integrity(S_{t+1})
]

を再評価する必要がある。

改善が確認できなければ、

[
\boxed{
Rollback:
S_{t+1}\rightarrow S_t
}
]

を可能にする。

Adaptationは無制限な自己変更ではなく、観測・評価・承認・回復可能性を伴うState Transitionとして実装されなければならない。

⸻

5　誰がSystemを変更できるのか

AdaptationにはAuthorityの問題が必ず生じる。

Agentが自分自身のPolicyを書き換えてよいのか。

Modelが長期Memoryへ自由に書き込んでよいのか。

SystemがHuman Approval Ruleを自動的に削除してよいのか。

新しいToolを自律的に接続してよいのか。

したがって、

[
\boxed{
Can\ Adapt
\neq
May\ Adapt
}
]

である。

GEOIでは変更対象ごとに、

Propose、

Evaluate、

Authorize、

Deploy、

Observe、

Rollback

を分離する。

基本Loopは、

[
\boxed{
Propose
\rightarrow
Evaluate
\rightarrow
Authorize
\rightarrow
Deploy
\rightarrow
Observe
}
]

となる。

さらに結果を次の改善へ戻せば、

[
\boxed{
Improve
\rightarrow
Evaluate
\rightarrow
Authorize
\rightarrow
Deploy
\rightarrow
Observe
\rightarrow
Improve’
}
]

というRecursive Improvement Runtimeが形成される。

ただし、Recursiveであることと無制限なSelf-modificationは同義ではない。

むしろ変更権限と検証条件を明示することが、GEOIにおけるAdaptationの前提となる。

⸻

6　Adaptation Costを測定する

GEOIの重要な仮説の一つは、System-level Adaptationによって新しいCapabilityを獲得する費用を圧縮できる可能性である。

モデル中心Architectureでは、新しい能力を得るために、

Retraining、

Fine-tuning、

Post-training

などが必要になる場合がある。

GEOIでは、

Memory Update、

Knowledge Update、

Tool Addition、

Relation Change、

Policy Change

だけで対応できる領域が存在する可能性がある。

そこで、

[
\boxed{
Cost_{adapt}

\frac{
Cost\ required\ for\ adaptation
}{
Verified\ Capability\ Gain
}
}
]

を測定する。

さらに、

[
Time_{adapt},
\quad
Compute_{adapt},
\quad
HumanEffort_{adapt}
]

も記録する。

もしSystem-level Adaptationが同等のCapability Gainをより少ない資源で実現できるなら、GEOIの経済的価値を支持する証拠になる。

逆にIntegration維持費やHuman Operationが大きければ、その優位性は消える。

⸻

7　AdaptationによってGEOIは自分自身を変更する

Adaptationを最も広く捉えると、GEOIが変更する対象はTask Solutionだけではなく、自らのArchitectureへ到達する。

初期状態を、

[
Architecture_0
]

とする。

RealityからFeedbackを得る。

その結果、

[
Architecture_0
\xrightarrow{Feedback}
Architecture_1
]

へ移行する。

さらに、

[
Architecture_1
\xrightarrow{Feedback’}
Architecture_2
]

へ進む。

したがって、

[
\boxed{
Architecture_t
\rightarrow
Architecture_{t+1}
}
]

そのものがAdaptation対象になる。

ここまで到達すると、本書の最終目標であるArchitecture Discovery Runtimeへ接続する。

しかし、Architectureを変更できるSystemは同時に、自らを破壊することもできる。

Relationを変更しすぎる。

Memoryを汚染する。

Authorityを失う。

局所最適化によって全体目的を破壊する。

変更履歴を追跡できなくなる。

したがってAdaptationが高度になるほど、次の条件が重要になる。

[
\boxed{
\textbf{変わる能力と、全体性を失わない能力を同時に持つこと}
}
]

前者がAdaptationであり、後者がIntegrityである。

GEOIは固定されているから安定するSystemではない。

また、自由に変化するから知的なSystemでもない。

求めるのは、

[
\boxed{
Stable\ enough\ to\ persist
\quad+\quad
Adaptive\ enough\ to\ change
}
]

という動的な両立である。

したがって本書におけるAdaptationとは、

[
\boxed{
\textbf{
Feedbackを受けてMemory・Knowledge・Policy・Relation・Component・Organization等を
検証可能かつ追跡可能な方法で変更し、
将来のSystem Behaviorを変化させる能力
}
}
]

である。

FeedbackによってGEOIは結果を知る。

AdaptationによってGEOIは結果から変わる。

そして、その変化の中でもSystemとしての一貫性、権限、追跡可能性、回復可能性を維持できるか。

次に問うのは、

[
\boxed{
Integrity
}
]

である。
第6節　Integrity

AdaptationによってSystemが変化できるようになると、次の問題が生じる。

変化し続けながら、それでも一つのSystemとして成立し続けられるのか。

Modelが交換される。

Memoryが更新される。

Knowledgeが修正される。

Agentが追加される。

Relationが組み替えられる。

Authorityが変更される。

Environmentも変化する。

それでもSystemは、目的、権限、状態、履歴、責任、回復可能性を失わずに動作できる必要がある。

この条件を本書では、

[
\boxed{
Integrity
}
]

と呼ぶ。

Integrityは「誠実さ」という倫理的意味だけを指す語ではない。GEOIでは、変化・障害・競合・不確実性の中でもSystem全体の整合性と運用可能性を維持する工学的性質として扱う。

[
\boxed{
Integrity

\text{System wholeness maintained under change and failure}
}
]

GEOIにおいて、生成と適応だけでは不十分である。

[
\boxed{
Adaptation
+
Integrity
}
]

が同時に成立して初めて、Systemは変化しながら存続できる。

⸻

1　Integrityは単一の指標ではない

Integrityを一つの数値だけで表現することは難しい。

本書では候補的に、

[
\boxed{
I

f(
Consistency,
Resilience,
Recoverability,
Traceability,
Authority,
Coherence
)
}
]

として分解する。

Consistencyは、System内部の状態や規則が重大な矛盾を起こしていないか。

Resilienceは、一部Componentが故障してもSystem全体の機能を維持できるか。

Recoverabilityは、失敗後に安全な状態へ戻れるか。

Traceabilityは、何が、いつ、誰によって、なぜ変更されたか追跡できるか。

Authorityは、ActionとSystem Changeが正当な権限の範囲内で実行されているか。

Coherenceは、局所的なComponentの行動がSystem全体の目的や制約と著しく乖離していないか。

これらは独立ではない。

TraceabilityがなければRecoverabilityは難しくなる。

Authorityが崩れればConsistencyも維持できない。

Resilienceを高めるための冗長化が、逆にCoherenceを低下させることもある。

したがってIntegrityそのものもSystem-level Propertyとして測定する。

⸻

2　Consistency――状態の矛盾を管理する

GEOIには複数のMemory、Knowledge Source、Agent、Human、Databaseが存在し得る。

そのため、異なるComponentが異なる状態を保持する可能性がある。

例えば、

[
Knowledge_A:x=1
]

である一方、

[
Knowledge_B:x=2
]

かもしれない。

重要なのは、分散Systemに完全な一致を常時要求することではない。

必要なのは、

[
\boxed{
\text{矛盾が存在することを検出し、その扱いを決定できること}
}
]

である。

Source、

Timestamp、

Version、

Confidence、

Authority

を保持し、

[
Conflict
\rightarrow
Detection
\rightarrow
Resolution
]

という経路を設計する。

GEOIにおけるConsistencyとは、すべてを同じ状態へ強制することではなく、状態差を管理可能にすることである。

⸻

3　Resilience――部分故障から全体を守る

複雑なSystemではFailureをゼロにはできない。

Model APIが停止する。

Databaseが応答しない。

Agentが異常Loopへ入る。

Networkが切断される。

Human Operatorが不在になる。

Knowledge Sourceが誤っている。

したがって設計目標は、

[
Failure=0
]

ではなく、

[
\boxed{
Component\ Failure
\not\Rightarrow
System\ Failure
}
]

へ移る。

例えば、

[
Model_A\ Failure
\rightarrow
Model_B
]

[
Agent\ Failure
\rightarrow
Isolation
]

[
Database\ Failure
\rightarrow
ReadOnly\ Mode
]

[
Automation\ Failure
\rightarrow
Human\ Escalation
]

といったFallbackを持たせる。

ここで測定するのは、正常時の最高性能だけではない。

[
\boxed{
Integrity\ under\ Failure
}
]

である。

GEOIが複雑になるほど、この指標の重要性は高くなる。

⸻

4　Recoverability――変化を戻せること

Adaptationには失敗が含まれる。

新しいPolicyが性能を悪化させる。

Memory Updateが誤っている。

Model Replacementによって品質が低下する。

Relation変更が予期しないFailureを発生させる。

したがって、変更前の状態を保持し、

[
S_t
\rightarrow
S_{t+1}
]

の結果が悪ければ、

[
\boxed{
S_{t+1}
\rightarrow
S_t
}
]

へ戻せる必要がある。

これは単純なSoftware Version Rollbackだけではない。

Model Version、

Prompt、

Policy、

Memory、

Knowledge、

Relation Graph、

Authority、

Configuration

など、System Stateを構成する複数要素を対象にする。

したがってGEOIでは、

[
\boxed{
Change
\rightarrow
Version
\rightarrow
Evaluate
\rightarrow
Keep\ or\ Rollback
}
]

を基本構造とする。

「変われること」と「戻れること」は一対である。

⸻

5　TraceabilityとAuthority

GEOIがRealityへ作用するほど、

[
\boxed{
Who\ did\ what,\ when,\ why,\ under\ whose\ authority?
}
]

を答えられる必要がある。

AgentがActionを実行したとしても、その原因はAgentだけとは限らない。

Human Request、

Model Output、

Knowledge Retrieval、

Memory、

Policy、

Tool Call

が連鎖している可能性がある。

したがって、

[
\boxed{
Decision
\rightarrow
Evidence
\rightarrow
Actor
\rightarrow
Authority
\rightarrow
Action
\rightarrow
Outcome
}
]

を追跡可能にする。

同時に、

[
\boxed{
Capability
\neq
Authority
}
]

を維持する。

技術的に実行可能なActionであっても、許可されていなければ実行してはならない。

特にSystem自身がAdaptationする場合、

[
\boxed{
Self\text{-}Modification\ Capability
\neq
Self\text{-}Modification\ Authority
}
]

である。

変更を提案するComponentと、承認するComponentと、DeployするComponentを分離することで、単一Componentの誤作動がSystem全体へ直結することを防ぐ。

⸻

6　Coherence――局所知能と全体知能

GEOIでは複数のAgentやHumanが、それぞれ異なる局所目的を持つ可能性がある。

例えばAgent Aは速度を最適化し、Agent Bは精度を最適化し、OrganizationはCostを抑え、HumanはRiskを最小化しようとする。

各Componentが局所的には合理的でも、

[
\boxed{
Local\ Optimum
\not\Rightarrow
System\ Optimum
}
]

である。

したがってGEOIには、局所的なActionがSystem全体のGoal、Constraint、Riskと整合しているかを確認する機構が必要になる。

概念的には、

[
Action_i
\rightarrow
System\ Constraint
\rightarrow
Authorize/Reject
]

である。

Coherenceとは、すべてのComponentが同じ考えを持つことではない。

異なる目的や知識を保持しながらも、System全体を破壊する相互作用を制御できることである。

つまり、

[
\boxed{
Diversity
+
Coordination
}
]

を維持する性質である。

⸻

7　IntegrityはGEOIの制約条件である

ここまでで、GEOIは、

[
System
\rightarrow
Component
\rightarrow
Relation
\rightarrow
Feedback
\rightarrow
Adaptation
]

と展開してきた。

しかし、この系列だけを最大化すると危険な方向へ進む。

Componentを増やす。

Relationを増やす。

Feedbackを高速化する。

Adaptationを自動化する。

Systemを自己変更可能にする。

それだけでは複雑性とFailure Surfaceも増大する。

そこでIntegrityが、

[
\boxed{
Constraint
}
]

として働く。

GEOIの設計問題は、

[
\max Capability
]

ではない。

より正確には、

[
\boxed{
\max Capability
}
]

subject to

[
Integrity\geq I^*
]

[
Reliability\geq R^*
]

[
Risk\leq Risk^*
]

[
Cost\leq C^*
]

という制約付き最適化問題になる。

したがってIntegrityは、GEOIへ後から追加するSafety Layerではない。

[
\boxed{
Integrity
\in
Architecture
}
]

である。

そしてIntegrityもまた、宣言ではなく実験されなければならない。

Componentを停止する。

Networkを切断する。

矛盾したKnowledgeを投入する。

誤ったMemoryを混入させる。

Authority違反を試みる。

不良UpdateをDeployする。

そのときSystemが、

Detect、

Contain、

Recover、

Trace

できるかを測定する。

[
\boxed{
Failure
\rightarrow
Detection
\rightarrow
Containment
\rightarrow
Recovery
\rightarrow
Learning
}
]

このLoopが成立するなら、Integrityは観測可能なEngineering Propertyになる。

GEOIにおけるIntegrityとは、

[
\boxed{
\textbf{
Systemが変化・故障・矛盾・競合にさらされても、
状態・権限・履歴・機能の整合性を管理し、
必要なら回復しながら、
一つのSystemとして動作を継続できる能力
}
}
]

である。

ここまでで、

[
\boxed{
System
+
Component
+
Relation
+
Feedback
+
Adaptation
+
Integrity
}
]

というGEOIの候補条件が揃った。

しかし、まだこれは概念定義である。

次に必要なのは、この六つの概念を、

[
\boxed{
Exists?
\quad
Measured?
\quad
Passed?
}
]

と判定できる条件へ変換することである。

GEOIという言葉を、Architecture、Code、Experiment、Realityへ接続する。

その境界が、

[
\boxed{
Operational\ Definition
}
]

である。
第7節　Operational Definition

ここまでGEOIを、

[
System
\rightarrow
Component
\rightarrow
Relation
\rightarrow
Feedback
\rightarrow
Adaptation
\rightarrow
Integrity
]

という六つの要素へ分解してきた。

しかし、概念を精密に説明できることと、その対象がReality上に存在することを判定できることは異なる。

「統合されている」

「適応している」

「生態系である」

「Integrityを持つ」

という記述だけでは、Engineering Scienceの対象にはならない。

必要なのは、

[
\boxed{
Concept
\rightarrow
Observable\ Variable
\rightarrow
Measurement
\rightarrow
Decision
}
]

への変換である。

これがOperational Definitionである。

本節では、「何を満たせばGEOIと判定するのか」を暫定的に固定する。

ただし、この定義そのものも最終真理ではない。

後続するArchitecture、Implementation、Experimentによって修正され得る、

[
\boxed{
GEOI\ Operational\ Definition\ v0
}
]

として出発する。

⸻

1　概念定義から操作的定義へ

概念上のGEOIを、

[
GEOI_{concept}
]

とする。

それをそのまま実験することはできない。

そこで、

[
\boxed{
GEOI_{concept}
\rightarrow
GEOI_{operational}
}
]

へ翻訳する。

本書では候補的に、

[
\boxed{
GEOI_{operational}

(S,C,R,F,A,I)
}
]

と置く。

ここで、

(S) = System
(C) = Component
(R) = Relation
(F) = Feedback
(A) = Adaptation
(I) = Integrity

である。

重要なのは、これらを単なる名詞として置かないことである。

各変数について、

[
\boxed{
Existence
+
Observability
+
Intervention
+
Measurement
}
]

を要求する。

つまり「存在すると説明できる」だけでなく、観測でき、必要なら操作し、その結果の差を測定できなければならない。

⸻

2　System条件

第一条件は、System Boundaryが明示されていることである。

[
\boxed{
S:
Boundary\ is\ explicitly\ defined
}
]

何をSystem内部とし、何をEnvironmentとするのか。

どのHuman、Model、Agent、Memory、Knowledge、Organization、Tool、Infrastructureを含むのか。

外部Foundation Model APIをどこまで含めるのか。

これらを記録する。

さらに、

[
S_t
\rightarrow
S_{t+1}
]

としてSystem Stateを時間方向に観測できる必要がある。

したがってSystem条件は、

[
\boxed{
Boundary
+
State
+
Environment
+
Time
}
]

によって操作化する。

Boundaryが定義されず、状態変化も追跡できない対象は、本書のGEOI実験対象とはしない。

⸻

3　ComponentとRelation条件

第二条件は、主要Componentが識別可能であることである。

各Componentを、

[
C_i=
(State_i,Capability_i,Interface_i,Authority_i)
]

として記述する。

少なくとも、

何を保持しているか。

何ができるか。

何と通信できるか。

何を実行する権限があるか。

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

さらにRelationについて、

[
R_{ij}

(Type,Direction,Protocol,Authority,State)
]

を記録する。

これによって、

[
\boxed{
Who
\rightarrow
What
\rightarrow
Whom
\rightarrow
Under\ What\ Condition
}
]

を追跡可能にする。

重要なのは、ComponentとRelationを独立に変更できることである。

同じComponent集合のままRelationだけを変更し、

[
V_A=V_B,\qquad E_A\neq E_B
]

としてSystem Capabilityが変化するかを検証できる。

ここで初めて、Relationの寄与を因果的に検討できる。

⸻

4　FeedbackとAdaptation条件

第三条件は、SystemのActionがReality上に生んだOutcomeを観測し、それがSystemへ戻ることである。

[
\boxed{
Action
\rightarrow
Outcome
\rightarrow
Observation
\rightarrow
Feedback
}
]

単にLogが存在するだけでは十分ではない。

Feedbackが次のSystem Stateへ影響する必要がある。

[
\boxed{
Feedback_t
\rightarrow
Update_t
\rightarrow
S_{t+1}
}
]

さらに、

[
Behavior(S_{t+1})
\neq
Behavior(S_t)
]

となる変化を観測する。

Adaptation対象はModel Weightに限定しない。

[
{
Memory,
Knowledge,
Policy,
Relation,
Routing,
Component,
Organization,
Model
}
]

のいずれかが更新され、その更新によって将来のBehaviorが変化すれば、System-level Adaptationの候補とする。

ただし変化しただけでは成功ではない。

[
\boxed{
Adaptation
\neq
Improvement
}
]

である。

更新前後のCapability、Cost、Reliability、Risk、Integrityを比較する。

⸻

5　Integrity条件

第四条件は、変化とFailureの中でSystem-level Integrityを測定できることである。

候補指標を、

[
\boxed{
I=
f(
Consistency,
Resilience,
Recoverability,
Traceability,
Authority,
Coherence
)
}
]

とする。

例えば実験では、

Component Failure、

Network Failure、

Conflicting Knowledge、

Memory Corruption、

Unauthorized Action、

Failed Update

を意図的に発生させる。

そのとき、

[
Failure
\rightarrow
Detection
\rightarrow
Containment
\rightarrow
Recovery
]

が成立するかを測る。

さらに、

誰がActionを実行したか。

どのModelが関与したか。

どのKnowledgeを参照したか。

誰が承認したか。

どのVersionがDeployされていたか。

を再構成できることを要求する。

したがって、

[
\boxed{
Integrity\ must\ be\ observable\ under\ failure
}
]

を本書の基本原則とする。

正常時だけ成立するIntegrityは、十分なIntegrityとはみなさない。

⸻

6　GEOI判定を二値化しすぎない

ここで注意が必要である。

六条件を一つでも満たさなければ「非GEOI」、すべて満たせば「完全GEOI」と直ちに二値分類すると、研究対象を先に定義へ合わせる危険がある。

そこで本書では、まず各条件を独立に測定する。

[
\boxed{
GEOI\ Profile

(S,C,R,F,A,I)
}
]

例えば、

[
(1.0,1.0,0.8,0.7,0.4,0.9)
]

のようなProfileを持つSystemが存在し得る。

ただし数値化方法は後続のExperimentで定義し、ここでは固定しない。

重要なのは、

[
\boxed{
GEOI\ is\ not\ assumed\ to\ be\ binary
}
]

ということである。

これによって、

AI Agent、

Multi-Agent System、

Enterprise System、

Digital Twin、

Cyber-Physical System

なども同じ測定空間へ配置できる。

その結果、既存ArchitectureとGEOIの間に実質的な境界が存在しない可能性も検証できる。

もし、

[
GEOI\ Residual\approx0
]

なら、新しい分類を維持する必要はない。

⸻

7　GEOI Operational Definition v0

以上から、本書における暫定的な操作的定義を次のように置く。

[
\boxed{
\begin{aligned}
GEOI_{v0}=;&
\text{明示されたSystem Boundaryの内部で、}\
&
\text{複数の異質なComponentが識別可能なRelationによって接続され、}\
&
\text{Environmentを観測してActionを実行し、}\
&
\text{そのOutcomeをFeedbackとしてSystemへ戻し、}\
&
\text{Feedbackに基づいて将来のSystem StateまたはBehaviorを変更し、}\
&
\text{その変化とFailureの中でもIntegrityを測定・維持・回復できる}\
&
\text{Open Dynamic System}
\end{aligned}
}
]

ただし、この定義を満たしただけでGEOIという新分類の必要性が証明されたわけではない。

ここで定義したのは、

[
\boxed{
Candidate\ Engineering\ Object
}
]

である。

次に検証しなければならないのは、

このArchitectureが本当に構築できるのか。

既存Architectureと何が異なるのか。

RelationはCapabilityへ寄与するのか。

Feedbackは長期Performanceを改善するのか。

Adaptation Costは圧縮されるのか。

Integrityは複雑性の増大に耐えられるのか。

そして、

[
\boxed{
Cost\ per\ Verified\ Delivered\ Capability
}
]

は既存Architectureより改善するのか、である。

ここで第Ⅰ部の役割が終わる。

GEOIは、抽象的な名称から、

[
\boxed{
System
+
Component
+
Relation
+
Feedback
+
Adaptation
+
Integrity
}
]

という検証可能な候補構造へ変換された。

しかし定義だけではSystemは動かない。

次に必要なのは、このOperational Definitionを実際の構造へ配置することである。

どこにBoundaryを置くのか。

どこにIntelligenceを置くのか。

MemoryとKnowledgeをどう配置するのか。

AgentとOrganizationをどう接続するのか。

Environmentとどう閉Loopを形成するのか。

そしてSystem全体をどのArchitectureとして統合するのか。

[
\boxed{
Definition
\rightarrow
Architecture
}
]

ここからGEOIは、「何であるか」という問いを離れ、

[
\boxed{
\textbf{どのように設計すれば、その条件をReality上で成立させられるのか}
}
]

というEngineeringの領域へ入る。

愛と敬意を込めてmandala