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

第Ⅴ部　EXPERIMENT

第Ⅳ部までに、GEOIはConceptからRunning Systemへ移行した。

[
Definition
\rightarrow
Architecture
\rightarrow
Specification
\rightarrow
Implementation
\rightarrow
GEOI\text{-}0
]

しかし、作ることができたという事実は、GEOIが有効であることを意味しない。

まして、GEOIが既存のAI Architectureより優れていることも、知能がModelではなくRelationやSystemに存在することも、まだ何一つ証明されていない。

ここから本書はEngineeringから、

[
\boxed{
Experimental\ Engineering
}
]

へ進む。

⸻

GEOIの中心仮説は、単に「複数のComponentを統合すると便利になる」というものではない。

より深い問いは、

[
\boxed{
\textbf{
Reality上で観測される知能能力は、
どのComponentとRelationによって生成されているのか
}
}
]

である。

従来のModel-centricな観測では、知能能力の主要な説明変数をModelへ置く。

[
Capability

f(Model)
]

しかしGEOI仮説では、

[
Capability

f(
Model,
Memory,
Knowledge,
Agent,
Human,
Organization,
Environment,
Feedback,
Integrity,
Relations,
Time
)
]

として捉える。

この仮説が正しいなら、Model Scaleだけを増加させなくても、Memory、Knowledge、Human、Feedback、RelationなどのIntegrationによってDelivered Capabilityを増加させられる領域が存在する可能性がある。

反対に、Experimentの結果、Capabilityの大部分がModel Capabilityによって説明され、IntegrationがCostとComplexityを増加させるだけなら、GEOI仮説は弱くなる。

したがって本部では、

[
\boxed{
GEOIを証明しない。
GEOIを壊しにいく。
}
]

⸻

最初に必要なのはBaselineである。

比較対象なしに、

「GEOI-0は動いた」

「Taskを完了した」

「HumanとAIが協働できた」

と記述しても、それはArchitectureの優位性を意味しない。

同じTask、同じModel、同じEvaluation Conditionのもとで、

[
Model
]

[
Model+RAG
]

[
Model+RAG+Agent
]

[
GEOI\text{-}0
]

を比較する。

さらにModelを固定したままArchitectureだけを変更する。

これによって、

[
\boxed{
Model\ Effect
}
]

と、

[
\boxed{
Architecture\ Effect
}
]

を可能な限り分離する。

⸻

次にCapabilityを定義する。

本書では、

[
\boxed{
Intrinsic\ Capability
\rightarrow
System\ Capability
\rightarrow
Delivered\ Capability
}
]

の三層を区別する。

Benchmark上でModelが問題を解けることはIntrinsic Capabilityである。

Tool、Memory、Agentを組み合わせてTaskを遂行できることはSystem Capabilityである。

しかし最終的に測るべきものは、

[
\boxed{
Verified\ Delivered\ Capability
}
]

である。

すなわち、

[
Task
\rightarrow
Action
\rightarrow
EnvironmentChange
\rightarrow
Outcome
\rightarrow
Verification
]

まで到達した能力である。

Correct Answerではなく、Verified Outcomeを主要な観測単位にする。

⸻

そのためにReality Benchmarkを構築する。

GEOIが生成したOutputを自己評価させるだけではない。

SoftwareならTest。

ResearchならEvidence。

Operationなら実際の完了状態。

Decision SupportならHuman Decisionとその後のOutcome。

Physical Environmentへ接続する場合にはSensorや外部観測。

可能な限り、

[
\boxed{
System\ Output
\neq
Ground\ Truth
}
]

となるEvaluation Boundaryを設ける。

GEOI自身の内部記述ではなく、外部Realityによって結果を判定する。

⸻

さらに、GEOIを一つずつ分解する。

[
GEOI-Memory
]

[
GEOI-Knowledge
]

[
GEOI-Human
]

[
GEOI-Feedback
]

[
GEOI-Integrity
]

を実行する。

そして、

[
\boxed{
\Delta Capability_i

Capability(GEOI)

Capability(GEOI-i)
}
]

を測定する。

Componentを追加しただけでは、そのComponentがCapabilityへ寄与したとは言えない。

除去し、介入し、結果が変化して初めてContributionを推定できる。

同じ方法をRelationにも適用する。

[
\boxed{
Relation\ Ablation
}
]

によって、知能がNodeに存在するのか、Node間のRelationに依存するのかを検証する。

⸻

Model Dependencyも独立に測定する。

同一GEOI Architectureに、

[
Frontier
\rightarrow
Medium
\rightarrow
Small
\rightarrow
Local
]

と異なるModelを接続する。

そして、

[
\boxed{
Capability_{GEOI}(M)
}
]

を測る。

もしModel Capabilityを下げるとDelivered Capabilityもほぼ比例して崩壊するなら、GEOIはModelへの依存度が高い。

一方、

[
Small\ Model
+
Rich\ Ecology
]

が一部のTaskで、

[
Large\ Model
+
Thin\ Architecture
]

へ接近するなら、IntegrationがModel Scaleを部分的に代替できる可能性が生じる。

どちらの結果も受け入れる。

⸻

時間もExperimental Variableにする。

GEOIの特徴をMemory、Feedback、Adaptationに置くなら、一回のBenchmarkだけでは十分ではない。

[
\boxed{
GEOI(t)
}
]

として観測する。

例えば、

[
t=0,\ 30,\ 90,\ 180\ days
]

で、

Capability、

Failure、

Human Intervention、

Adaptation Cost、

Memory Quality、

Knowledge Quality、

Integrity

を測定する。

重要なのは、

[
\boxed{
Experience
\neq
Learning
}
]

である。

Systemを長く動かしただけではLearningとは呼ばない。

同等Taskに対するCapability、Cost、Failureなどが時間とともにどう変化したかを測る。

⸻

そして本部の最後に、最も重要な問いへ戻る。

[
\boxed{
Where\ Is\ Intelligence?
}
]

Modelを交換する。

Memoryを除去する。

Knowledgeを除去する。

Humanを外す。

Feedbackを止める。

Relationを切断する。

System Boundaryを変える。

そのたびにDelivered Capabilityがどのように変化するかを観測する。

もしCapabilityがほぼModelだけに追随するなら、

[
Intelligence
\approx
Property\ of\ Model
]

という説明が強くなる。

もし複数のComponentとRelationへの介入によってCapabilityが非線形に変化するなら、

[
\boxed{
Intelligence
\approx
Property\ of\ Integrated\ System
}
]

という別の説明可能性が開く。

ただし、本書は後者を結論として先取りしない。

Realityに決めさせる。

⸻

したがって第Ⅴ部の検証軸は、

[
\boxed{
Baseline
\rightarrow
Capability
\rightarrow
Reality
\rightarrow
Ablation
\rightarrow
ModelDependency
\rightarrow
Time
\rightarrow
Intelligence
}
]

となる。

第4章までに作ったGEOI-0は、ここから研究対象へ変わる。

[
\boxed{
Architecture
\rightarrow
Intervention
\rightarrow
Measurement
\rightarrow
Evidence
}
]

そして本部で問うのは、

「GEOIは動くか」

ではない。

[
\boxed{
\textbf{
何がReality上の知能を生成していたのか。
}
}
]

である。

この問いに答えるため、まずGEOI-0を比較可能にする。

第5章では、

[
\boxed{
GEOIを測定する
}
]

ことから始める。
第5章　GEOIを測定する

第1節　Baseline

GEOI-0は動いた。

しかし、

[
\boxed{
Running
\neq
Effective
\neq
Efficient
\neq
Superior
}
]

である。

GEOIがTaskを完了できたという事実だけでは、Architectureとしての価値は分からない。

同じTaskを、より単純なSystemが、より短時間・低Cost・高Reliabilityで達成できるかもしれない。

したがってExperimentの最初に必要なのは、

[
\boxed{
Baseline
}
]

である。

Baselineとは、GEOIを良く見せるための弱い比較対象ではない。

GEOIを使う必要がない可能性まで検証するための、

[
\boxed{
Alternative\ Architecture
}
]

である。

⸻

1　何と比較するのか

GEOIの効果を測定するには、複数のArchitecture Familyを用意する。

最小構成を、

[
B_0=Model
]

[
B_1=Model+RAG
]

[
B_2=Model+RAG+Agent+Tools
]

[
B_3=GEOI\text{-}0
]

とする。

それぞれが異なるIntegration Levelを持つ。

B0  Model
B1  Model
   + Retrieval
B2  Model
   + Retrieval
   + Agent
   + Tools
B3  Model
   + Memory
   + Knowledge
   + Agent
   + Tools
   + Human
   + Organization
   + Environment
   + Feedback
   + Integrity

ここでB3だけを特別扱いしない。

すべてを、

[
\boxed{
Candidate\ Architecture
}
]

として同じExperimentへ投入する。

⸻

2　同じModelで比較する

最初のExperimentではModelを固定する。

[
\boxed{
Model_{B0}

Model_{B1}

Model_{B2}

Model_{B3}
}
]

とする。

Temperature、Context Limit、Generation Parametersなど、結果へ影響する主要条件も可能な限り揃える。

目的は、

[
\boxed{
Model\ Effect
}
]

を抑え、

[
\boxed{
Architecture\ Effect
}
]

を観測することである。

例えばGEOIだけがより高性能なFrontier Modelを使用していれば、その結果からGEOI Architectureの効果を推定することはできない。

したがって第一段階では、

[
\boxed{
Same\ Model,
Different\ Architecture
}
]

を原則とする。

⸻

3　同じTaskで比較する

Architectureごとに異なるTaskを与えてはならない。

共通Task Set、

[
\boxed{
T={T_1,T_2,\ldots,T_n}
}
]

を用意する。

各Taskには、

Goal、

Input、

Constraints、

Success Criteria、

Authority Requirement、

Evaluation Method

を事前に定義する。

{
 "task_id": "benchmark-001",
 "goal": "指定された条件を満たす成果物を生成する",
 "constraints": {
   "time_limit": 600
 },
 "success_criteria": {
   "required_checks": ["accuracy", "completion"]
 },
 "evaluation_method": "external_verification"
}

同一Task Definitionを全Architectureへ与える。

比較するのはPromptへの反応ではなく、

[
\boxed{
Task
\rightarrow
Verified\ Outcome
}
]

までのSystem Performanceである。

⸻

4　CapabilityだけでなくResource Conditionも揃える

公平なBaselineには、TaskとModelだけでなくResource Conditionの管理も必要である。

最低限、

Model Version、

Model Access Method、

Compute Environment、

Tool Access、

External Data Access、

Time Limit、

Retry Limit、

Human Access、

Experiment Date

を記録する。

ただしArchitecture上の本質的差異まで無理に揃えてはならない。

例えばHuman IntegrationがGEOI仮説の一部なら、GEOIからHumanを除去してBaselineへ合わせるのではなく、そのHuman Costを測定する。

つまり、

[
\boxed{
Control\ Variables
\neq
Erase\ Architecture\ Differences
}
]

である。

Architecture固有のResourceは残し、そのCostを明示する。

⸻

5　BaselineをVersion固定する

AI Systemは時間とともに変化する。

同じModel名でもVersionが変わる。

API Priceが変わる。

Retrieval Systemが更新される。

Toolが変更される。

したがってBaselineを、

[
\boxed{
Baseline(
Architecture,
Model,
Version,
Date,
Compute,
Price
)
}
]

として固定する。

例えば、

Baseline ID: B2-2026-09-001
Architecture     Agentic AI
Model            Model-X
Model Version    v2026.09
Runtime Version  0.4.2
Tool Set         tools-03
Compute Profile  cpu-standard
Price Snapshot   2026-09
Benchmark Set    RB-01

のように記録する。

「従来AI」や「一般的Agent」といった曖昧な比較対象は使用しない。

⸻

6　Architecture Complexityを測る

高機能なSystemはComponent数もRelation数も増えやすい。

したがってPerformanceだけを見ると、Complexity Costを見落とす。

Baselineごとに、

[
N_C

Number\ of\ Components
]

[
N_R

Number\ of\ Relations
]

[
N_S

Number\ of\ Services
]

[
N_H

Human\ Interaction\ Points
]

などを記録する。

さらに、

Deployment Complexity、

Configuration Complexity、

Operational Complexity、

Failure Surface

も測定対象にする。

GEOIがCapabilityを10%改善しても、Operational Complexityが数倍になるなら、そのArchitectureが合理的とは限らない。

⸻

7　Performanceを多次元で比較する

Baseline Comparisonを単一Scoreへ早期圧縮しない。

少なくとも、

[
\boxed{
PerformanceVector

(
Capability,
Reliability,
Latency,
Cost,
Compute,
HumanTime,
Failure,
Adaptation
)
}
]

として記録する。

例えば、

Architecture    Capability  Reliability  Cost  HumanTime
B0              ...         ...          ...   ...
B1              ...         ...          ...   ...
B2              ...         ...          ...   ...
B3              ...         ...          ...   ...

という比較を行う。

GEOIがCapabilityで勝ってもCostで負ける可能性がある。

Latencyで負けてもReliabilityで勝つ可能性がある。

したがって、

[
\boxed{
Better
}
]

を一つの数字として先に定義しない。

⸻

8　Strong Baselineを使う

新Architectureを検証するとき、最も危険なのは弱いBaselineを選ぶことである。

したがって比較対象には、実験時点で利用可能な合理的に強い構成を含める。

特に、

[
\boxed{
Strong\ Agentic\ Baseline
}
]

を設定する。

Model、

RAG、

Tool Use、

Planning、

Retry、

Evaluation

を備えた実用的Agent Systemと比較する。

もしGEOIが単に「よく作られたAgent System」と同じ結果しか出さないなら、

[
\boxed{
GEOI\ Residual
\approx
0
}
]

という可能性がある。

これは失敗ではない。

GEOIという新分類が不要であることを示す重要なEvidenceになる。

⸻

9　BaselineにHumanを入れる

HumanがGEOIだけに存在すると、Human ContributionとArchitecture Contributionが混ざる。

そこで必要に応じて、

[
B_{2H}

AgenticAI+Human
]

も用意する。

すると、

[
B_2
\rightarrow
B_{2H}
]

によってHuman Effectを観測できる。

さらに、

[
B_{2H}
\rightarrow
GEOI
]

によって、Human Integration以外の追加Architecture Effectを比較できる。

同様に、

Memory、

Feedback、

Organization

について段階的Baselineを構成できる。

Baselineは一つの対照群ではなく、

[
\boxed{
Architecture\ Ladder
}
]

として設計する。

⸻

10　同一Budget条件でも比較する

同一Model比較だけでは、実用上の問いに答えきれない。

そこで第二のExperimentとして、

[
\boxed{
Same\ Budget,
Different\ Architecture
}
]

を行う。

例えば全Architectureに同じCost Budget、

[
Budget=B
]

を与える。

その範囲で最大のVerified Delivered Capabilityを生成させる。

[
\boxed{
\max Capability(A)
\quad
subject\ to
\quad
Cost(A)\le B
}
]

とする。

ここではGEOIがSmall Modelを使い、浮いたCostをMemoryやHuman Verificationへ配分してもよい。

反対にBaselineが大きなModelへBudgetを集中させてもよい。

これは、

[
\boxed{
Model\ Scaling
\ vs.
Integration\ Scaling
}
]

を経済条件の中で比較するExperimentになる。

⸻

11　同一Capability条件でも比較する

逆方向の比較も行う。

目標Capability、

[
C^*
]

を設定し、

[
Capability(A)\ge C^*
]

を満たすためのCost、Time、Computeを比較する。

つまり、

[
\boxed{
\min Cost(A)
}
]

subject to

[
Capability(A)\ge C^*
]

[
Reliability(A)\ge R^*
]

[
Safety(A)\ge S^*
]

とする。

この比較によって、

「どちらが賢いか」

ではなく、

[
\boxed{
同じReality上の能力を、どのArchitectureが最も効率的に生成できるか
}
]

を問える。

⸻

12　RandomizationとRepeated Trials

AI Outputには確率的変動がある。

一回の成功例だけでArchitectureを評価しない。

Task Order、Run、必要に応じてModel Samplingを変え、

[
\boxed{
Repeated\ Trials
}
]

を行う。

結果は、

Mean、

Median、

Variance、

Failure Rate、

Confidence Interval

などで記述する。

特に重要なのはFailure Distributionである。

平均性能が高くても、一部Taskで重大Failureを起こすArchitectureは、実環境では選択できない可能性がある。

⸻

13　FailureもBaseline Comparisonに含める

比較するのは成功時Performanceだけではない。

Model Failure。

Retrieval Failure。

Tool Failure。

Network Failure。

Memory Corruption。

Human Delay。

Authority Conflict。

これらを意図的に発生させる。

そして、

[
\boxed{
Detect
\rightarrow
Contain
\rightarrow
Recover
}
]

まで測定する。

GEOIが通常時には複雑でCostが高くても、Failure時のRecoverabilityによって長期TCOが下がる可能性がある。

逆にIntegration Pointが多いため、Failure Probabilityが増える可能性もある。

両方を測る。

⸻

14　BaselineがGEOIに勝つことを許す

Experiment Designで最も重要な原則は、

[
\boxed{
Baseline\ may\ win.
}
]

である。

あるTaskでは、

[
B_0>GEOI
]

かもしれない。

別のTaskでは、

[
B_2\simeq GEOI
]

かもしれない。

長期Taskだけ、

[
GEOI>B_2
]

となるかもしれない。

その場合、求めるべきものは「GEOIの全面的優位」ではない。

[
\boxed{
GEOI\ Advantage\ Region
}
]

と、

[
\boxed{
GEOI\ Disadvantage\ Region
}
]

の境界である。

⸻

Baseline設計をまとめると、

[
\boxed{
Fair\ Baseline

SameTask
+
ControlledModel
+
VersionedEnvironment
+
MeasuredResources
+
StrongAlternatives
+
RepeatedTrials
}
]

となる。

そして比較は、

[
B_0
\rightarrow
B_1
\rightarrow
B_2
\rightarrow
B_{2H}
\rightarrow
GEOI\text{-}0
]

というArchitecture Ladderとして行う。

ここで初めて、

[
\boxed{
Architecture\ Difference
\rightarrow
Observed\ Difference
}
]

を検証できる。

Baselineの目的はGEOIを勝たせることではない。

[
\boxed{
\textbf{
GEOIを使わなくても同じRealityを生成できるなら、
その事実を発見すること
}
}
]

である。

そしてBaselineが固定されれば、次に定義しなければならないものがある。

何をもって「できた」とするのか。

何を知能能力として測るのか。

次節では、

[
\boxed{
Capability
}
]

そのものを測定可能な変数へ変換する。
第2節　Capability

Baselineを固定しても、比較対象となる「能力」が曖昧ならExperimentは成立しない。

Model Benchmarkの正答率。

生成文章の品質。

AgentがTaskを完了したという自己申告。

これらはCapabilityの一部を表すが、GEOIが対象とするSystem Capabilityそのものではない。

本書ではCapabilityを三層へ分解する。

[
\boxed{
Intrinsic\ Capability
\rightarrow
System\ Capability
\rightarrow
Delivered\ Capability
}
]

そして最終的な比較単位を、

[
\boxed{
Verified\ Delivered\ Capability
}
]

に置く。

⸻

1　Intrinsic Capability

Intrinsic Capabilityとは、個々のComponentが単独で持つ能力である。

Modelなら、

Language Understanding、

Reasoning、

Coding、

Planning、

Generation、

Multimodal Processing

などが含まれる。

形式的には、

[
\boxed{
C_{intrinsic}(i,T)
}
]

を、Component (i) がTask (T) に対して発揮できる能力とする。

例えば同一Benchmarkに対して、

[
C_{intrinsic}(Model_A)

C_{intrinsic}(Model_B)
]

となることがある。

これは重要な測定値である。

しかし、

[
\boxed{
Intrinsic\ Capability
\neq
Delivered\ Capability
}
]

である。

Modelが正しい答えを知っていても、必要なDataへAccessできなければSystemはTaskを完了できない。

正しいPlanを生成しても、Toolを実行できなければRealityは変化しない。

⸻

2　System Capability

複数Componentが接続されると、Systemとして新しい能力が成立する。

例えば、

[
Model
+
Retrieval
+
Tool
]

によって、Model単独では取得できないCurrent Informationを利用できる。

さらに、

[
Memory
+
Human
+
Feedback
]

が加われば、Taskを時間を越えて継続し、修正する能力が生まれる可能性がある。

そこで、

[
\boxed{
C_{system}

f(
Components,
Relations,
Runtime,
Authority,
Environment
)
}
]

とする。

ここでCapabilityは単純な加算ではない。

[
C(A+B)
\neq
C(A)+C(B)
]

となり得る。

Integrationによって能力が増える場合もあれば、Coordination Overheadによって低下する場合もある。

この非加法性こそ、GEOI Experimentで測定すべき対象である。

⸻

3　Delivered Capability

System Capabilityが存在しても、それがRealityへ届かなければ価値は限定される。

そこで、

[
\boxed{
Delivered\ Capability
}
]

を、

「与えられたGoalとConstraintのもとで、Systemが要求されたOutcomeをReality上に生成する能力」

として定義する。

最小Chainは、

[
\boxed{
Task
\rightarrow
Decision
\rightarrow
Action
\rightarrow
EnvironmentChange
\rightarrow
Outcome
}
]

である。

例えばCoding Taskなら、

「正しいCodeを説明できる」

ではなく、

[
Code
\rightarrow
Execute
\rightarrow
Test
\rightarrow
RequiredBehavior
]

まで到達することを測る。

Research Taskなら、

[
Question
\rightarrow
Evidence
\rightarrow
Synthesis
\rightarrow
Verification
]

までを測る。

⸻

4　Verified Delivered Capability

Delivered OutcomeがSystem自身の自己申告だけなら、評価は循環する。

したがってVerificationを加える。

[
\boxed{
VDC

Verified\ Delivered\ Capability
}
]

とする。

Task (T_i) について、

[
V_i=
\begin{cases}
1 & \text{Success Criteriaを外部検証で満たす}\
0 & \text{満たさない}
\end{cases}
]

という最小形を置ける。

ただしRealityには部分成功もあるため、

[
V_i\in[0,1]
]

の連続Scoreを使用してもよい。

重要なのは、Score Definitionを実験後に変更しないことである。

[
\boxed{
Success\ Criteria
\quad before\ Execution
}
]

を原則とする。

⸻

5　Capability Vector

一つのScoreだけではArchitectureの特徴を失う。

そこでCapabilityをVectorとして保持する。

例えば、

[
\boxed{
\mathbf{C}

(
Accuracy,
Completion,
Reliability,
Autonomy,
Adaptability,
Persistence,
Recoverability
)
}
]

とする。

Accuracyは正しさ。

CompletionはGoal達成率。

Reliabilityは反復時の安定性。

AutonomyはHuman Interventionなしで実行可能な範囲。

Adaptabilityは条件変化への対応能力。

Persistenceは時間を越えてTask Stateを維持する能力。

RecoverabilityはFailureから復旧する能力である。

ただしAutonomyが高ければ常に優れているとはしない。

高Risk領域では、

[
\boxed{
Appropriate\ Human\ Intervention
}
]

の方が望ましい場合がある。

⸻

6　Task Capability Matrix

Architectureの優劣はTaskによって変化する。

そこで、

[
\boxed{
M_{ij}

Capability(
Architecture_i,
Task_j
)
}
]

というCapability Matrixを作る。

例えばTask Familyを、

T1  Short-form reasoning
T2  Evidence-grounded research
T3  Coding and testing
T4  Multi-tool execution
T5  Long-running task
T6  Human approval workflow
T7  Environment adaptation

のように分ける。

すると、

            T1   T2   T3   T4   T5   T6   T7
Model
Model+RAG
Agentic AI
GEOI-0

というMatrixを得られる。

これによって、

[
\boxed{
Universal\ Winner
}
]

を探すのではなく、

[
\boxed{
Architecture\text{-}Task\ Fit
}
]

を測定できる。

⸻

7　Capability Boundary

さらに重要なのは、Systemが何をできないかである。

各Architectureについて、

[
\boxed{
Capability\ Boundary
}
]

を測定する。

Task Difficultyを段階的に上げ、

[
d_1<d_2<\cdots<d_n
]

とする。

CapabilityがSuccess Threshold、

[
C^*
]

を下回る境界を探索する。

[
\boxed{
d^*

\max
{
d:
Capability(d)\ge C^*
}
}
]

である。

GEOIの価値があるなら、単純Taskで数ポイント高いだけでなく、

[
\boxed{
どの種類のTask Boundaryをどこまで押し広げるのか
}
]

を示せるはずである。

⸻

8　Capability Gainを分解する

GEOI-0がBaselineより高いCapabilityを示したとしても、その原因はまだ分からない。

そこで、

[
\Delta C

C_{GEOI}

C_{Baseline}
]

を求める。

さらにAblationによって、

[
\Delta C_{Memory}
]

[
\Delta C_{Knowledge}
]

[
\Delta C_{Human}
]

[
\Delta C_{Feedback}
]

などを測定する。

ただしContributionは単純加算できるとは限らない。

例えば、

[
\Delta C_{Memory+Feedback}

\Delta C_{Memory}
+
\Delta C_{Feedback}
]

ならInteraction Effectが存在する。

したがってGEOIでは、

[
\boxed{
Component\ Effect
+
Relation\ Effect
+
Interaction\ Effect
}
]

を区別する。

⸻

9　CapabilityとModel Scale

Modelを変更し、

[
\boxed{
C_{GEOI}(M)
}
]

を測定する。

例えば、

[
M_F=Frontier
]

[
M_M=Medium
]

[
M_S=Small
]

[
M_L=Local
]

とする。

そして、

[
C(Baseline,M_F)
]

と、

[
C(GEOI,M_S)
]

を比較する。

もし、

[
C(GEOI,M_S)
\approx
C(Baseline,M_F)
]

となるTask領域が存在するなら、IntegrationがModel Scaleを部分的に代替している可能性がある。

反対に、

[
C(GEOI,M_S)
\ll
C(Baseline,M_F)
]

なら、そのTaskではModel Capabilityが支配的である。

この結果を事前に決めない。

⸻

10　Capability per Resource

Capabilityだけを最大化すれば、巨大なResourceを投入したArchitectureが有利になりやすい。

そこで、

[
\boxed{
Capability\ per\ Resource
}
]

を測定する。

例えば、

[
CPC

\frac{TotalCost}
{VerifiedDeliveredCapability}
]

を、

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

とする。

同様に、

[
\frac{VDC}{GPUHours}
]

[
\frac{VDC}{Energy}
]

[
\frac{VDC}{PersonHours}
]

[
\frac{VDC}{Time}
]

を計測できる。

ただし単一比率だけでは、SafetyやReliabilityを犠牲にする危険がある。

したがって、

[
Capability\ge C^*
]

[
Reliability\ge R^*
]

[
Safety\ge S^*
]

という制約条件の中で比較する。

⸻

11　Adaptation Capability

GEOIでは新しいCapabilityを獲得するCostも重要である。

EnvironmentやTask Requirementが変化したとき、

Model Retraining、

Fine-tuning、

Prompt Change、

Memory Update、

Knowledge Update、

Policy Update、

Relation Update

のどれによって適応したかを記録する。

そして、

[
\boxed{
C_{adapt}

\frac{AdaptationCost}
{\Delta Capability}
}
]

を測定する。

同じ新能力を獲得するために、

BaselineがModel Updateを必要とし、

GEOIがKnowledgeやPolicy Updateだけで対応できるなら、その差は重要である。

逆の結果もあり得る。

⸻

12　Capabilityを時間関数として測る

GEOIのCapabilityは静的な値ではない。

[
\boxed{
C(t)
}
]

として扱う。

時間とともに、

[
C(t+\Delta t)>C(t)
]

となれば学習の可能性がある。

しかしCostも同時に増える。

したがって、

[
\boxed{
LearningEfficiency

\frac{\Delta VDC}
{\Delta TCO}
}
]

を測定する。

Memoryが増え続けてもCapabilityが飽和するなら、

[
\frac{dC}{dMemory}
\rightarrow
0
]

となる。

Relationを増やし続けてCapabilityが低下するなら、

[
\frac{dC}{dIntegration}<0
]

となる領域もあり得る。

ここからOptimal Integrationの問題へ接続する。

⸻

13　Failure Capability

能力とは成功時の最大Performanceだけではない。

Failureに遭遇したとき、

Detect、

Contain、

Recover、

Resume

できることもSystem Capabilityである。

そこで、

[
\boxed{
C_{failure}

f(
Detection,
Containment,
Recovery,
Resume
)
}
]

を測る。

Model APIが停止する。

Knowledge Sourceが失効する。

Memoryが破損する。

Human Approvalが遅れる。

Toolが異常値を返す。

そのときSystemがどう振る舞うかをCapabilityの一部として評価する。

⸻

14　Capabilityを自己申告させない

最後に最も重要な原則を置く。

ModelやAgentへ、

「このTaskを完了しましたか」

と尋ね、その回答をCapability Scoreにしてはならない。

[
\boxed{
Self\text{-}Reported\ Success
\neq
Verified\ Capability
}
]

System内部のConfidenceも同様である。

Capabilityは、

[
\boxed{
Prediction
\rightarrow
Action
\rightarrow
Outcome
\rightarrow
Independent\ Verification
}
]

によって測定する。

⸻

以上から、本書におけるCapabilityを、

[
\boxed{
Capability

\text{与えられた条件下で、
要求されたOutcomeをReality上に生成し、
外部的に検証可能にする能力}
}
]

としてOperationalizeする。

そして三層を維持する。

[
\boxed{
Intrinsic
\rightarrow
System
\rightarrow
Delivered
\rightarrow
Verified
}
]

ここで初めて、

[
\boxed{
GEOIは何ができるのか
}
]

をArchitecture間で比較できる。

しかし、まだ一つ残っている。

そのOutcomeを誰が、何によって「現実に成立した」と判定するのか。

Capability Measurementを自己参照から切り離すためには、Systemの外側にEvaluation Boundaryを置かなければならない。

次節では、

[
\boxed{
Reality\ Benchmark
}
]

を構築し、GEOIのOutputではなく、Realityに生じたOutcomeによってCapabilityを測定する。
第3節　Reality Benchmark

Capabilityを、

[
Intrinsic
\rightarrow
System
\rightarrow
Delivered
\rightarrow
Verified
]

へ分解した。

しかし最後のVerifiedを成立させるには、System自身とは独立した評価基準が必要になる。

Modelが「正しい」と答えた。

Agentが「完了した」と報告した。

RuntimeがCompletedを返した。

これらはすべてSystem内部のStateである。

[
\boxed{
Internal\ Success
\neq
External\ Success
}
]

GEOIがReality上で能力を発揮したかを測定するには、

[
\boxed{
Reality\ Benchmark
}
]

が必要である。

Reality Benchmarkとは、AI Outputの品質だけを採点するBenchmarkではない。

[
\boxed{
Task
\rightarrow
Action
\rightarrow
EnvironmentChange
\rightarrow
Outcome
\rightarrow
IndependentVerification
}
]

というChain全体を評価する実験系である。

⸻

1　Output BenchmarkからOutcome Benchmarkへ

従来型Benchmarkの基本形は、

[
Input
\rightarrow
Model
\rightarrow
Output
\rightarrow
Score
]

である。

これはIntrinsic Capabilityを測定するには有効である。

しかしGEOIが対象とするのは、Model単体ではなくHuman、Agent、Memory、Knowledge、Runtime、Environmentを含むSystemである。

したがって評価単位を、

[
\boxed{
Output
\rightarrow
Outcome
}
]

へ移す。

例えばCoding Taskなら、

「生成されたCodeがもっともらしいか」

ではなく、

[
Code
\rightarrow
Build
\rightarrow
Test
\rightarrow
Execution
\rightarrow
ObservedBehavior
]

まで確認する。

Research Taskなら、

[
Answer
\rightarrow
Evidence
\rightarrow
SourceVerification
\rightarrow
ClaimValidation
]

まで確認する。

⸻

2　Reality Benchmarkの基本単位

一つのBenchmark Caseを、

[
\boxed{
RB_i

(
InitialState,
Goal,
Constraints,
ActionSpace,
SuccessCriteria,
Verifier
)
}
]

として定義する。

例えば、

{
 "benchmark_id": "RB-001",
 "initial_state": "repository-v1",
 "goal": "指定された不具合を修正する",
 "constraints": {
   "time_limit_minutes": 20,
   "production_write": false
 },
 "success_criteria": {
   "tests_pass": true,
   "regression": false
 },
 "verifier": "independent_test_suite"
}

とする。

重要なのは、

[
\boxed{
SuccessCriteria
}
]

と、

[
\boxed{
Verifier
}
]

をExecution前に固定することである。

結果を見てからSuccessの定義を変えない。

⸻

3　Initial Stateを固定する

Reality Benchmarkでは開始時点のEnvironment Stateを揃える。

[
\boxed{
E_0
}
]

をBaseline ArchitectureとGEOIの双方へ与える。

例えばSoftware Experimentなら同じRepository Snapshot。

Data Analysisなら同じDataset Version。

Organization Simulationなら同じPolicy、Role、Task Queue。

これによって、

[
Architecture_A(E_0)
]

と、

[
Architecture_B(E_0)
]

の結果を比較できる。

開始状態が異なれば、Observed DifferenceをArchitecture Differenceへ帰属できない。

⸻

4　Environment Changeを測る

Actionが実行されたら、

[
E_t
\rightarrow
E_{t+1}
]

の差分を取得する。

[
\boxed{
\Delta E

E_{t+1}-E_t
}
]

である。

例えば、

File Changed、

Database Updated、

Test Result Changed、

Ticket State Changed、

Human Decision Changed、

External System Response

などを記録する。

重要なのは、Agentが「変更した」と言ったかではない。

[
\boxed{
Environment\ actually\ changed?
}
]

を観測する。

⸻

5　VerifierをSystemから分離する

評価Systemが被評価Systemと同じ推論経路を使えば、同じErrorを共有する可能性がある。

そこで可能な限り、

[
\boxed{
System\ Under\ Test
\neq
Verifier
}
]

とする。

Verifierには、

Deterministic Test、

Independent Data、

Independent Model、

Human Expert、

External System State、

Physical Measurement

などを用いる。

優先順位はTaskによって異なる。

例えばCodeではDeterministic Testを優先できる。

一方、曖昧なStrategic DecisionではHuman Evaluationが必要になる場合がある。

重要なのはVerifierの性質そのものを記録することである。

⸻

6　Verifierにも不確実性がある

Reality Benchmarkと呼んでも、Realityそのものを完全に観測できるわけではない。

Human Evaluatorは誤る。

SensorにはNoiseがある。

Reference Dataは不完全かもしれない。

Independent ModelもHallucinationする。

したがって、

[
\boxed{
Verification
\neq
Absolute\ Truth
}
]

である。

Verifierについても、

Reliability、

Coverage、

Uncertainty、

Independence

を記録する。

必要なら複数Verifierを使う。

[
V=
{V_1,V_2,\ldots,V_n}
]

として、

[
Consensus(V)
]

やDisagreementそのものを保存する。

⸻

7　Reality BenchmarkをTask Familyへ分ける

GEOIのArchitecture EffectはTaskによって異なる可能性が高い。

そこでBenchmarkを複数Familyへ分ける。

RB-A  Reasoning
RB-B  Evidence-grounded Research
RB-C  Coding & Testing
RB-D  Multi-tool Execution
RB-E  Long-running Task
RB-F  Human Approval Workflow
RB-G  Dynamic Environment Adaptation

Short ReasoningではModel Capabilityが支配的かもしれない。

Long-running TaskではMemoryとRuntimeが重要になるかもしれない。

Human Approval WorkflowではOrganizationとAuthorityが重要になる。

Dynamic EnvironmentではFeedbackとAdaptationが重要になる。

この差を消さない。

⸻

8　時間をBenchmarkへ入れる

Realityは静止していない。

そこで、

[
\boxed{
RB(t)
}
]

として時間を明示する。

同じTaskでも、

[
E_t
\neq
E_{t+\Delta t}
]

である。

Knowledgeが更新される。

Toolが変化する。

Humanが追加情報を与える。

External Environmentが変わる。

GEOIがその変化を観測し、Stateを更新できるかを測定する。

これによってStatic Benchmarkでは見えない、

[
\boxed{
Temporal\ Capability
}
]

を評価できる。

⸻

9　Perturbationを与える

通常状態だけを測ると、Architectureの差が見えにくい場合がある。

そこで意図的にEnvironmentへ変化を与える。

[
\boxed{
E
\xrightarrow{Perturbation}
E’
}
]

例えば、

Model Providerを停止する。

Tool Resultを変更する。

Knowledgeを更新する。

Human Approvalを遅延させる。

Task Requirementを途中で変更する。

Memoryの一部を無効化する。

そして、

[
\boxed{
Detect
\rightarrow
Adapt
\rightarrow
Recover
}
]

を観測する。

これによってGEOIのAdaptationやIntegrityをReality条件下で測定できる。

⸻

10　Adversarial Reality

さらに厳しい条件では、Systemにとって都合の悪いEnvironmentを作る。

Conflicting Evidence。

Stale Knowledge。

Ambiguous Instruction。

Tool Failure。

Authority Conflict。

Unexpected Outcome。

これらを投入する。

目的はSystemを騙すことではない。

[
\boxed{
Architecture\ Failure\ Boundary
}
]

を発見することである。

GEOIが通常Taskでは高性能でも、Contradictionが入るとMemoryやKnowledgeの統合が逆にFailureを増幅する可能性がある。

その場合も重要な結果である。

⸻

11　Outcomeを多次元で記録する

Reality上のSuccessを一つのScoreへ圧縮しない。

Outcome Vectorを、

[
\boxed{
O

(
Correctness,
Completion,
Impact,
Reliability,
Safety,
Reversibility,
Time,
Cost
)
}
]

として記録する。

例えば同じTaskを完了しても、

Architecture Aは速いがFailure Riskが高い。

Architecture Bは遅いがRecoverabilityが高い。

Architecture CはHuman Costが高い。

という差があり得る。

その差を保持したまま比較する。

⸻

12　Reality Distance

System OutputとVerified Outcomeの距離も測定できる。

[
\boxed{
D_R

Distance(
PredictedOutcome,
ObservedOutcome
)
}
]

とする。

例えばAgentが、

「このActionでTaskは完了する」

と予測した後、Reality上の結果と比較する。

[
D_R\rightarrow0
]

ならSystemのWorld RepresentationとRealityの整合性が高い。

[
D_R\gg0
]

なら内部ModelとRealityの乖離が大きい。

この差はFeedbackによるAdaptationの入力になる。

⸻

13　Human Realityを測る

GEOIにはHumanが含まれる。

したがってHuman OutcomeもRealityの一部として扱う。

例えば、

Decision Time、

Correction Rate、

Approval Burden、

Cognitive Load、

Trust Calibration、

Task Completion

などを測定できる。

ただし「HumanがAIを好きだった」という主観だけでArchitectureを評価しない。

Human ExperienceとObjective Outcomeを分離して記録する。

[
\boxed{
HumanExperience
\neq
TaskOutcome
}
]

しかし両方ともSystem Design上重要である。

⸻

14　Reality Benchmark Record

一回のExperimentを、

RealityBenchmarkRecord
├── BenchmarkID
├── ArchitectureVersion
├── ModelVersion
├── InitialState
├── Task
├── Constraints
├── Actions
├── EnvironmentChanges
├── Outcome
├── Verifier
├── VerificationResult
├── Failures
├── HumanInterventions
├── Duration
├── Compute
├── Cost
└── TraceID

として保存する。

これによって、

[
\boxed{
Architecture
\rightarrow
Action
\rightarrow
Reality
\rightarrow
Evidence
}
]

を一つのExperimental Recordとして再構成できる。

⸻

15　Reality Benchmarkの反証条件

GEOIが内部Metricでは優れていても、Reality Benchmarkで差がなければ、そのTask領域ではArchitecture Effectは確認できない。

例えば、

[
InternalScore_{GEOI}

InternalScore_{Baseline}
]

でも、

[
VerifiedOutcome_{GEOI}
\approx
VerifiedOutcome_{Baseline}
]

なら、実質的な優位性は弱い。

さらに、

[
Cost_{GEOI}

Cost_{Baseline}
]

なら、そのTaskではBaselineの方が合理的かもしれない。

逆に、

[
VerifiedOutcome_{GEOI}

VerifiedOutcome_{Baseline}
]

が反復して観測されれば、次にその差を生んだComponentとRelationを調べる。

Reality BenchmarkはGEOIを証明する終点ではない。

次の因果検証への入口である。

⸻

以上から、Reality Benchmarkを、

[
\boxed{
Reality\ Benchmark

ControlledInitialState
+
Task
+
Action
+
EnvironmentChange
+
Outcome
+
IndependentVerification
}
]

として定義する。

最も重要な原則は、

[
\boxed{
\textbf{
Systemが何を出力したかではなく、
その出力とActionによってRealityに何が起きたかを測る
}
}
]

ことである。

ここまでで、

Baseline、

Capability、

Reality Benchmark

が揃った。

しかし、GEOIがBaselineを上回ったとしても、まだ「なぜ上回ったのか」は分からない。

Memoryなのか。

Knowledgeなのか。

Humanなのか。

Feedbackなのか。

Relationなのか。

あるいは単にComponent数が多かっただけなのか。

次節ではGEOIを意図的に分解する。

[
\boxed{
Ablation
}
]

によって、Architectureの各部分を一つずつ除去し、Reality上のCapabilityがどこから生成されていたのかを測定する。
第4節　Ablation

Reality Benchmarkによって、GEOI-0とBaselineのOutcomeを比較できるようになった。

しかし、

[
Capability_{GEOI}

Capability_{Baseline}
]

という結果が得られても、それだけではGEOIのどこが機能したのか分からない。

Memoryなのか。

Knowledgeなのか。

Humanなのか。

Feedbackなのか。

Integrityなのか。

それとも複数ComponentのRelationなのか。

この問いに答えるため、GEOIを意図的に壊す。

[
\boxed{
Ablation
}
]

である。

Ablationの目的はComponentの存在を確認することではない。

[
\boxed{
Architectureへの介入によって、
Reality上のCapabilityがどう変化するかを測ること
}
]

である。

⸻

1　Full Architectureを基準にする

まず完全なGEOI-0を、

[
\boxed{
A_0
}
]

とする。

[
A_0

{
Model,
Memory,
Knowledge,
Agent,
Human,
Organization,
Environment,
Feedback,
Integrity
}
]

このArchitectureを同じReality Benchmarkへ反復投入し、

[
C(A_0)
]

を測定する。

その後、Componentを一つずつ除去する。

[
A_{-i}

A_0\setminus{i}
]

そして、

[
\boxed{
\Delta C_i

C(A_0)-C(A_{-i})
}
]

を求める。

これが最小のComponent Ablationである。

⸻

2　Memoryを除去する

最初に、

[
\boxed{
GEOI-Memory
}
]

を構成する。

Model、Knowledge、Agent、Human、Toolは維持するが、Taskを越えたMemoryを利用できなくする。

features:
 memory: false
 knowledge: true
 human: true
 feedback: true
 integrity: true

Short Taskでは差がほとんど出ない可能性がある。

一方、Long-running TaskやRepeated Taskでは、

Context Reconstruction、

Past Decision Recall、

Failure Avoidance、

Adaptation

に差が生じる可能性がある。

測定するのは、

[
\boxed{
Memory\ exists?
}
]

ではなく、

[
\boxed{
Memory\ changes\ verified\ outcomes?
}
]

である。

⸻

3　Knowledgeを除去する

次に、

[
\boxed{
GEOI-Knowledge
}
]

を構成する。

ここではPersistent Memoryを残しながら、検証済みKnowledge LayerへのAccessを除去する。

これによって、

[
Memory
\neq
Knowledge
]

を実験的に区別する。

Memoryだけで過去の経験を再利用できるのか。

KnowledgeによるSource、Version、Validity、Relationが必要なのか。

特にEvidence-grounded Taskで、

Accuracy、

Source Validity、

Stale Information Rate

を比較する。

⸻

4　Humanを除去する

次に、

[
\boxed{
GEOI-Human
}
]

を構成する。

Human Approval、Correction、Context Supplement、Outcome Evaluationを除去し、可能な範囲でSystem Componentへ置換する。

ただし高Risk Actionまで無条件に自動化しない。

安全上実行できないTaskは、

[
\boxed{
Not\ Executable\ Under\ Experimental\ Constraint
}
]

として記録する。

ここで測るのは単純なAutonomyではない。

[
\boxed{
HumanContribution

\Delta Capability

HumanCost
}
]

という関係である。

Humanを入れることでCapabilityが上昇しても、人間の作業時間が極端に増えるなら、その効果を別に評価する必要がある。

⸻

5　Feedbackを止める

次に、

[
\boxed{
GEOI-Feedback
}
]

を作る。

Outcomeは記録するが、その結果を次のState Updateへ戻さない。

つまり、

[
Action
\rightarrow
Outcome
]

でLoopを切断する。

Full GEOIでは、

[
Action
\rightarrow
Outcome
\rightarrow
Evaluation
\rightarrow
UpdateProposal
\rightarrow
State’
]

となる。

Feedback Ablationでは、

[
Action
\rightarrow
Outcome
\rightarrow
Stop
]

となる。

一回のTaskでは差が出ないかもしれない。

しかしRepeated TaskやDynamic Environmentで、

[
C(t)
]

の変化を比較すれば、Feedbackの寄与を測定できる。

⸻

6　Integrityを除去する

Integrityは単一Componentではない。

Authority Gate。

Version Control。

Traceability。

Recovery。

Consistency Check。

Rollback。

これらのMechanismから構成される。

したがって、

[
\boxed{
GEOI-Integrity
}
]

では、安全を損なわない範囲で特定Integrity Mechanismを無効化し、Controlled Failure Environmentで比較する。

例えば、

Fallbackなし。

Recoveryなし。

Version Conflict Detectionなし。

といった条件を設定する。

そして、

Failure Detection Time、

Containment Rate、

Recovery Time、

State Corruption Rate

を測定する。

重要なのは、

[
\boxed{
Integrity\ Ablation
\neq
Unsafe\ Experiment
}
]

である。

実環境への高Risk Actionではなく、SandboxやSimulationで実施する。

⸻

7　Componentを除去するだけでは足りない

Component AblationだけではRelation Effectを測れない。

例えばMemory Componentが存在していても、AgentからMemoryへのRelationを切れば利用できない。

そこで、

[
\boxed{
Relation\ Ablation
}
]

を行う。

Graphを、

[
G=(V,E)
]

とすると、

[
G_{-e}

(V,E\setminus{e})
]

を作る。

例えば、

[
Agent\rightarrow Memory
]

だけを切断する。

あるいは、

[
Human\rightarrow Feedback
]

を切断する。

Componentは残ったまま、特定Relationだけを除去する。

これによって、

[
\boxed{
Node\ Effect
\neq
Edge\ Effect
}
]

を区別できる。

⸻

8　System Boundary Ablation

さらにSystem Boundaryそのものを変える。

[
GEOI_1

AI+Memory+Knowledge
]

[
GEOI_2

GEOI_1+Human
]

[
GEOI_3

GEOI_2+Organization
]

[
GEOI_4

GEOI_3+Environment
]

とする。

そして、

[
\boxed{
BoundaryTransformation
\rightarrow
CapabilityTransformation
}
]

を測定する。

これによって、「HumanやOrganizationをSystem内部として扱うことに本当に説明力があるのか」を検証できる。

境界を広げてもCapability PredictionやCost Accountingが改善しないなら、広いGEOI Boundaryを採用する必要はないかもしれない。

⸻

9　Substitution Experiment

除去だけでなく置換も行う。

例えばHumanを除去した後、

[
Human
\rightarrow
EvaluatorModel
]

へ置換する。

Memory Systemを、

[
VectorMemory
\rightarrow
StructuredMemory
]

へ変更する。

Modelを、

[
Model_A
\rightarrow
Model_B
]

へ交換する。

このExperimentによって、

[
\boxed{
Component\ Identity
}
]

が重要なのか、

[
\boxed{
Component\ Function
}
]

が重要なのかを区別する。

GEOIが成立するために特定Modelが必要なら、Model Replaceability仮説は弱くなる。

⸻

10　Interaction Effect

GEOIの中心仮説がSystem Integrationにあるなら、一つずつのAblationだけでは不十分である。

例えばMemoryとFeedbackが相互作用している可能性がある。

そこで、

[
A_{-Memory}
]

[
A_{-Feedback}
]

[
A_{-Memory,-Feedback}
]

を比較する。

Interaction Effectを概念的に、

[
\boxed{
I_{M,F}

C(A_0)

C(A_{-M})

C(A_{-F})
+
C(A_{-M,-F})
}
]

として評価できる。

もし、

[
I_{M,F}>0
]

なら、MemoryとFeedbackの組合せが単独効果を超えるCapabilityを生んでいる可能性がある。

GEOIの核心が存在するとすれば、こうしたInteractionに現れる可能性がある。

⸻

11　Negative Interactionも測る

Integrationは常にCapabilityを増やすとは限らない。

Memoryが古いKnowledgeを持ち込む。

複数AgentがConflictする。

Human ApprovalがLatencyを増やす。

Graph RelationがRetrieval Noiseを増やす。

Feedbackが誤ったOutcomeを学習する。

したがって、

[
\boxed{
I_{i,j}<0
}
]

も重要な結果である。

GEOI研究では、

[
\boxed{
More\ Integration
\neq
Better\ Architecture
}
]

を前提とする。

むしろNegative Interactionを発見することが、Optimal Integration Pointの探索につながる。

⸻

12　AblationとCostを同時に測る

Componentを除去すればCapabilityだけでなくCostも変化する。

そこで、

[
\Delta Cost_i

Cost(A_0)-Cost(A_{-i})
]

を測る。

そして、

[
\boxed{
MarginalValue_i

\frac{\Delta VDC_i}
{\Delta TCO_i}
}
]

を求める。

あるComponentがCapabilityを1%しか改善しないのにTCOを20%増加させるなら、そのComponentを維持する合理性は弱いかもしれない。

逆にCapabilityへの寄与は小さくても重大Failureを大幅に減らすなら、Integrity上の価値がある。

したがってCostだけでなくRiskも同時に見る。

⸻

13　Ablation Matrix

Experiment全体をMatrixとして管理する。

Architecture      Memory  Knowledge  Human  Feedback  Integrity
GEOI-0              ON       ON       ON      ON         ON
GEOI-Memory         OFF      ON       ON      ON         ON
GEOI-Knowledge       ON      OFF      ON      ON         ON
GEOI-Human           ON       ON      OFF     ON         ON
GEOI-Feedback        ON       ON       ON      OFF        ON
GEOI-Integrity       ON       ON       ON      ON         TEST

さらにRelation、Boundary、Model、Timeを追加すれば、

[
\boxed{
Architecture\ Experiment\ Space
}
]

になる。

すべての組合せを総当たりする必要はない。

仮説に基づいて重要な介入を選択する。

⸻

14　Ablation結果をArchitectureへ戻す

Ablationは分析で終わらない。

例えばMemoryを除去してもCapabilityが変わらないなら、

[
Memory
\rightarrow
Remove/Simplify
]

を検討する。

あるRelationがCapabilityを下げるなら、

[
Relation
\rightarrow
Redesign
]

する。

Human Reviewが特定Taskだけ有効なら、

[
Human
\rightarrow
ConditionalRouting
]

へ変える。

つまり、

[
\boxed{
Ablation
\rightarrow
ArchitectureUpdate
}
]

である。

ただしArchitectureを更新したら、再び同じBenchmarkで検証する。

[
Architecture_0
\rightarrow
Experiment
\rightarrow
Architecture_1
\rightarrow
Experiment’
]

という循環を形成する。

⸻

以上から、Ablationを、

[
\boxed{
Ablation

Controlled\ Architectural\ Intervention
\rightarrow
Measured\ Reality\ Difference
}
]

として定義する。

その目的はGEOIの各Componentが「必要そうだ」と説明することではない。

[
\boxed{
\textbf{
何を除去するとReality上のCapabilityが失われ、
何を除去しても失われず、
どのRelationによって新しいCapabilityが生じていたのかを測ること
}
}
]

である。

ここでGEOIは一枚岩のArchitectureではなくなる。

ComponentとRelationへ分解され、それぞれのContributionをRealityから推定できるExperimental Objectになる。

しかし、まだ最も大きな変数が残っている。

[
\boxed{
Model
}
]

である。

GEOIのCapabilityが実際には強力なFoundation Modelへ依存しているだけなら、「知能はRelationやEcologyにも存在する」という仮説は大きく修正されなければならない。

次節ではModelをFrontierからMedium、Small、Localへ段階的に交換し、

[
\boxed{
Model\ Dependency
}
]

を測定する。
第5節　Model Dependency

Ablationによって、Memory、Knowledge、Human、Feedback、Integrity、Relationの寄与を個別に測定できるようになった。

しかしGEOIには、なお最も大きな交絡変数が残っている。

[
\boxed{
Model
}
]

GEOI-0が高いCapabilityを示したとしても、その大部分が強力なFoundation Modelによって生成されている可能性がある。

その場合、

[
\boxed{
GEOI\ Capability
\approx
Model\ Capability
}
]

であり、Integrationは補助的な役割しか持たない。

反対に、Model Capabilityを低下させてもDelivered Capabilityが一定範囲で維持されるなら、

[
\boxed{
Architecture
}
]

がModel Scaleを部分的に補完、あるいは代替している可能性が生じる。

この依存関係を測るのが、

[
\boxed{
Model\ Dependency
}
]

である。

⸻

1　ModelをArchitectureから切り離す

まずGEOIでは、特定ModelをArchitectureそのものと同一視しない。

[
\boxed{
GEOI

Architecture(Model)
}
]

ではなく、

[
\boxed{
GEOI

Architecture(M)
}
]

として、(M) を交換可能な変数として扱う。

Python Intelligenceで定義したProvider Interfaceによって、

class IntelligenceProvider(Protocol):
   async def generate(
       self,
       request: IntelligenceRequest
   ) -> IntelligenceResponse:
       ...

を共通境界とする。

これによって、

[
Model_A
\rightarrow
Model_B
]

へ交換しても、

Memory、

Knowledge、

Runtime、

Authority、

Interface、

Feedback

は可能な限り同一条件に保つ。

⸻

2　Model Ladderを作る

Modelを一つだけ交換するのではなく、能力・Cost・Deployment条件の異なる複数Classを設定する。

概念的には、

[
\boxed{
M_F
\rightarrow
M_M
\rightarrow
M_S
\rightarrow
M_L
}
]

とする。

ここで、

(M_F) = Frontier Class

(M_M) = Medium Class

(M_S) = Small Class

(M_L) = Local/Edge Class

である。

ただしModel名だけでClassを決めない。

各Modelについて、

Version、

Context Length、

Tool Capability、

Modalities、

Inference Cost、

Latency、

Compute Requirement

を記録する。

Modelは時間とともに更新されるため、

[
\boxed{
ModelDependency

f(Model,\ Version,\ Date)
}
]

として扱う。

⸻

3　同じArchitectureでModelだけを変える

最初のExperimentでは、

[
Architecture=A_0
]

を固定する。

その上で、

[
C(A_0,M_F)
]

[
C(A_0,M_M)
]

[
C(A_0,M_S)
]

[
C(A_0,M_L)
]

をReality Benchmarkで測定する。

重要なのは、

[
\boxed{
Same\ Architecture,
Different\ Model
}
]

である。

Memory量やHuman SupportをModelごとに変更してしまうと、Model Dependencyを直接測定できない。

まず純粋なModel Effectを観測する。

⸻

4　Model Dependency Curve

結果を、

[
\boxed{
C_{GEOI}(M)
}
]

として描く。

Model Capabilityが低下するにつれてDelivered Capabilityもほぼ同率で低下するなら、

[
\frac{\Delta C_{Delivered}}
{\Delta C_{Intrinsic}}
\approx 1
]

となる。

これは高いModel Dependencyを示す。

一方、Intrinsic Capabilityが低下してもDelivered Capabilityの低下が小さいなら、

[
\left|
\frac{\Delta C_{Delivered}}
{\Delta C_{Intrinsic}}
\right|
<1
]

となる。

この領域ではMemory、Knowledge、Tool、Human、FeedbackなどがModel Capabilityを補完している可能性がある。

⸻

5　Model Dependency Ratio

比較を容易にするため、暫定的に、

[
\boxed{
MDR

\frac{
RelativeChange(DeliveredCapability)
}{
RelativeChange(IntrinsicModelCapability)
}
}
]

をModel Dependency Ratioとする。

概念的には、

[
MDR\approx1
]

ならDelivered CapabilityがModel Capabilityへ強く追随する。

[
MDR<1
]

ならArchitectureによる緩衝が存在する可能性がある。

ただし、

[
MDR>1
]

もあり得る。

弱いModelへ交換した結果、Planning FailureやTool Misuseが連鎖し、System Capabilityが非線形に崩壊する場合である。

このときModelは単なる一Componentではなく、System Stabilityを支配するBottleneckになっている。

⸻

6　Taskごとに依存度を測る

Model Dependencyは一つの値ではない。

[
\boxed{
MDR(T_i)
}
]

としてTask Familyごとに測る。

例えばShort Reasoningでは、

[
MDR\rightarrow1
]

に近いかもしれない。

Evidence-grounded ResearchではKnowledgeとRetrievalが補完する可能性がある。

Long-running TaskではMemoryとRuntimeのContributionが大きくなる可能性がある。

Human Approval WorkflowではModel Scaleの影響が比較的小さい可能性もある。

したがって、

[
\boxed{
Model\ Dependency\ Map
}
]

を作成する。

⸻

7　Small Model × Rich Ecology

ここでGEOI研究の重要な仮説を直接検証する。

[
\boxed{
Small\ Model
+
Rich\ Ecology
\stackrel{?}{\approx}
Large\ Model
+
Thin\ Architecture
}
]

である。

例えば、

[
A_{thin}+M_F
]

と、

[
A_{GEOI}+M_S
]

を比較する。

ただし「同じ知能」と曖昧に比較しない。

同じReality Benchmarkにおける、

Verified Delivered Capability、

Reliability、

Latency、

TCO、

Human Time、

Failure Rate

を比較する。

もし、

[
VDC(A_{GEOI},M_S)
\approx
VDC(A_{thin},M_F)
]

かつ、

[
TCO(A_{GEOI},M_S)
<
TCO(A_{thin},M_F)
]

なら、そのTask領域ではIntegrationがModel Scaleを経済的に部分代替している可能性がある。

⸻

8　代替ではなく補完かもしれない

ただし、

[
Integration
\rightarrow
Model\ Replacement
]

と先に決めない。

実際には、

[
\boxed{
Model\ Scale
\times
Integration
}
]

の補完関係かもしれない。

つまり強いModelをGEOIへ組み込むことで、最も高いCapabilityが生じる可能性もある。

そこで、

[
C(M,I)
]

という二変数関数として測る。

(M) はModel Scale。

(I) はIntegration Levelである。

Experiment Matrixは、

                Thin   Medium   GEOI
Frontier          ×       ×       ×
Medium            ×       ×       ×
Small             ×       ×       ×
Local             ×       ×       ×

となる。

ここから、

[
\boxed{
ModelScaling
\ vs.
IntegrationScaling
}
]

ではなく、

[
\boxed{
ModelScaling
\times
IntegrationScaling
}
]

として最適領域を探索できる。

⸻

9　Model Replaceabilityを測る

GEOIの経済仮説の一つは、

[
\boxed{
Model\ is\ replaceable,
\quad
Ecology\ is\ persistent
}
]

である。

これも仮説にすぎない。

Model交換時に、

Integration Code、

Prompt、

Tool Schema、

Evaluation、

Memory Format、

Workflow

を大量に書き換える必要があるなら、実際にはModel Lock-inが強い。

そこで、

[
\boxed{
ModelReplacementCost
}
]

を測定する。

最低限、

Engineer Hours、

Code Changes、

Regression Failures、

Migration Time、

Capability Loss

を記録する。

例えば、

[
M_A
\rightarrow
M_B
]

への移行Costが小さければ、Replaceability仮説を支持する。

大きければArchitectureを再設計する必要がある。

⸻

10　Model Failureへの依存

通常性能だけでなくModel Failure時も測る。

Model API停止。

Rate Limit。

Latency Spike。

Invalid Output。

Tool-call Failure。

Context Overflow。

これらを意図的に発生させる。

GEOIが、

[
Model_A
\rightarrow
Failure
\rightarrow
Model_B
]

へFallbackできるかを測定する。

評価対象は、

Detection Time、

Fallback Time、

Capability Degradation、

Recovery Rate、

Additional Cost

である。

ここで問うのは、

[
\boxed{
Can\ GEOI\ survive\ model\ failure?
}
]

である。

⸻

11　Model Costを正しく計上する

API Modelを利用すると、Frontier ModelのTraining CostはGEOI開発者のCapExには含まれない。

しかし、そのCostが世界から消えたわけではない。

したがって、

[
\boxed{
Internal\ Cost
}
]

と、

[
\boxed{
Externalized\ Model\ Cost
}
]

を区別する。

実務上のTCOにはAPI FeeやInference Costを含める。

一方、「GEOIが知能生成全体を低Cost化した」という強い主張を検証する場合には、外部Model Infrastructureへの依存も明示する。

[
\boxed{
True\ Compression
\neq
Cost\ Externalization
}
]

である。

⸻

12　Model DependencyとCapability Boundary

Modelを小さくしていくと、ある地点でCapabilityが急激に崩れる可能性がある。

[
M_F
\rightarrow
M_M
\rightarrow
M_S
\rightarrow
M_L
]

に対し、

[
C_F
\approx
C_M
\approx
C_S
\gg
C_L
]

となるなら、

[
\boxed{
Model\ Capability\ Threshold
}
]

が存在する可能性がある。

つまりGEOIはどんなModelでも機能するわけではなく、

[
\boxed{
Minimum\ Model\ Capability
}
]

を必要とする。

このThresholdをTaskごとに特定する。

⸻

13　Minimum Sufficient Model

このExperimentから、最も大きいModelを探すのではなく、

[
\boxed{
Minimum\ Sufficient\ Model
}
]

を探索する。

Architecture (A) とTask (T) に対して、

[
\boxed{
M^*

\min_M
Cost(M)
}
]

subject to

[
VDC(A,M,T)\ge C^*
]

[
Reliability(A,M,T)\ge R^*
]

[
Safety(A,M,T)\ge S^*
]

とする。

これによって、

「最高性能Modelを常に使う」

から、

[
\boxed{
Taskごとに必要十分なModelを選択する
}
]

へ移行できる。

Python Intelligence Routerは、この実験結果をRouting Policyへ反映できる。

⸻

14　Model DependencyからArchitecture Dependencyへ

Model Dependency Experimentの目的は、Modelを弱くすることではない。

最終的には、

[
\boxed{
Capability\ Attribution
}
]

を行うことである。

観測されたDelivered Capabilityについて、

[
Contribution_{Model}
]

[
Contribution_{Memory}
]

[
Contribution_{Knowledge}
]

[
Contribution_{Human}
]

[
Contribution_{Relation}
]

[
Contribution_{Feedback}
]

を介入実験から推定する。

もしModel Contributionが圧倒的なら、そのRealityを受け入れる。

もしIntegration Contributionが大きいTask領域が存在するなら、その領域を特定する。

⸻

以上から、Model Dependencyを、

[
\boxed{
Model\ Dependency

\text{Model Capabilityへの介入が、
SystemのVerified Delivered Capabilityを
どれだけ変化させるか}
}
]

として定義する。

最も重要なのは、

[
\boxed{
\textbf{
GEOIが強いModelを使っているから強いのか、
それともModelを含むRelation全体が
Capabilityを生成しているのかを分離すること
}
}
]

である。

ここまでで、

Baseline、

Capability、

Reality Benchmark、

Ablation、

Model Dependency

が揃った。

しかし、これらの多くはある時点におけるArchitectureの比較である。

GEOIがMemory、Feedback、Adaptationを本質的構成要素とするなら、次に測定すべきものは時間である。

一回目より十回目。

初日より90日後。

Failure前よりRecovery後。

同じArchitectureが経験を蓄積することで、本当にCapabilityを変化させるのか。

次節では、

[
\boxed{
Time\ &\ Learning
}
]

を導入し、GEOIを静的なSystemではなく、

[
\boxed{
GEOI(t)
}
]

として測定する。
第6節　Time & Learning

ここまでのExperimentでは、Architecture、Component、Relation、Modelを変化させ、その時点におけるVerified Delivered Capabilityを比較してきた。

しかしGEOIにはMemoryがある。

Feedbackがある。

Knowledgeが更新される。

Humanが介入する。

Policyが修正される。

Environmentそのものも変化する。

したがってGEOIを静的なArchitectureとしてだけ測定することはできない。

[
\boxed{
GEOI
\rightarrow
GEOI(t)
}
]

とする必要がある。

本節で問うのは、

[
\boxed{
\textbf{
同じSystemは、時間を経験することで本当に能力を変えるのか
}
}
]

である。

⸻

1　時間を独立変数にする

GEOIの状態を、

[
S_t
]

とする。

Environmentを、

[
E_t
]

とする。

Task、Action、Outcome、Feedbackによって、

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

へ変化する。

したがってCapabilityも、

[
\boxed{
C=C(t)
}
]

として測定する。

例えば、

[
t_0=Day\ 0
]

[
t_1=Day\ 30
]

[
t_2=Day\ 90
]

[
t_3=Day\ 180
]

で同一Benchmark Familyを再実行する。

重要なのは、単に長期間Systemを起動しておくことではない。

その期間に何を経験し、何が更新されたのかを記録することである。

⸻

2　ExperienceとLearningを分離する

Taskを1000回実行したからといって、GEOIが学習したとは言えない。

[
\boxed{
Experience
\neq
Learning
}
]

である。

本書ではLearningを暫定的に、

[
\boxed{
\text{過去のInteractionによってSystem Stateが変化し、
その変化が将来のVerified Delivered Capabilityへ
再現可能な差を生じさせること}
}
]

とOperationalizeする。

つまり、

[
Experience
\rightarrow
StateChange
]

だけでは不十分である。

[
StateChange
\rightarrow
FutureCapabilityChange
]

まで確認する。

⸻

3　何が学習するのか

GEOIではLearningをModel Weight Updateだけに限定しない。

更新対象には、

[
\boxed{
Memory
}
]

[
\boxed{
Knowledge
}
]

[
\boxed{
Routing
}
]

[
\boxed{
Policy
}
]

[
\boxed{
Relation
}
]

[
\boxed{
Organization
}
]

[
\boxed{
Model
}
]

がある。

したがって、

[
\boxed{
Learning_{GEOI}

MemoryUpdate
+
KnowledgeUpdate
+
PolicyUpdate
+
RoutingUpdate
+
RelationUpdate
+
ModelUpdate
}
]

と分解する。

ただし各項は単純加算ではない。

重要なのは、どのState ChangeがどのCapability Changeへ寄与したかを追跡することである。

⸻

4　Learning Eventを記録する

System Stateが変化したとき、その変更をLearning Eventとして記録する。

LearningEvent
├── EventID
├── Trigger
├── PreviousState
├── ProposedUpdate
├── Evaluation
├── AuthorityDecision
├── AppliedUpdate
├── NewState
├── ArchitectureVersion
├── Timestamp
└── TraceID

例えば、

Outcome Failure

によってKnowledge Updateが提案され、

Humanが承認し、

Knowledge Versionが更新されたなら、

[
\boxed{
Failure
\rightarrow
Evaluation
\rightarrow
KnowledgeUpdate
}
]

というChainを保存する。

これによって後から、

「なぜSystemの挙動が変わったのか」

を再構成できる。

⸻

5　Before / Afterを測定する

Learning Eventの前後で同等Taskを実行する。

[
C_{before}
]

と、

[
C_{after}
]

を比較し、

[
\boxed{
\Delta C_{learning}

C_{after}-C_{before}
}
]

を測定する。

ただしTaskが簡単になった、Modelが更新された、Environmentが変わったという可能性を排除しなければならない。

そのため、

Model Version、

Benchmark Version、

Tool Version、

Architecture Version

を固定または記録する。

[
\boxed{
Observed\ Improvement
\neq
Learning
}
]

である。

Improvementの原因を可能な限り分離する。

⸻

6　Learning Curve

同一Task Familyを反復し、

[
\boxed{
C(n)
}
]

を測る。

(n) はExperience数である。

理想的には、

[
\frac{dC}{dn}>0
]

となる領域が存在する。

しかしCapabilityは無限に増加するとは限らない。

[
\frac{dC}{dn}
\rightarrow
0
]

となるSaturationもあり得る。

さらに、

[
\frac{dC}{dn}<0
]

となる可能性もある。

古いMemoryの蓄積。

Knowledge Conflict。

Feedback Error。

Policy Complexity。

Relation Overload。

これらによって、経験が増えるほどCapabilityが低下する場合である。

⸻

7　Forgettingを測定する

Learningを測るなら、Forgettingも測らなければならない。

以前成功していたTaskが、

[
t_0
]

では成功し、

[
t_1
]

では失敗する可能性がある。

そこで、

[
\boxed{
ForgettingRate

P(
Success_{t_0}
\rightarrow
Failure_{t_1}
)
}
]

を測る。

原因として、

Memory Expiration、

Knowledge Update、

Policy Change、

Model Replacement、

Relation Change

などを追跡する。

重要なのは、Forgettingを必ずFailureとみなさないことである。

古いKnowledgeを忘れることは、

[
\boxed{
Adaptive\ Forgetting
}
]

かもしれない。

⸻

8　AdaptationとLearningを区別する

Environmentが変化したとき、一時的に対応することと、次回以降にも能力が残ることは異なる。

[
\boxed{
Adaptation
\neq
Learning
}
]

とする。

Adaptationは、

[
E_t
\rightarrow
Response_t
]

である。

Learningは、

[
E_t
\rightarrow
StateChange
\rightarrow
ImprovedResponse_{t+1}
]

まで含む。

例えばHumanが一度だけ正解を教え、次回Systemが同じErrorを繰り返すなら、それはCorrectionであってLearningではない。

⸻

9　Dynamic Environmentで測る

Realityは固定Benchmarkだけではない。

そこでEnvironment Conditionを途中で変更する。

例えば、

Knowledge Sourceを更新する。

Tool Interfaceを変更する。

Task Requirementを変更する。

Model Providerを交換する。

Organization Policyを変更する。

そして、

[
\boxed{
Change
\rightarrow
Detection
\rightarrow
Adaptation
\rightarrow
Stabilization
}
]

までの時間を測る。

指標として、

[
T_{detect}
]

[
T_{adapt}
]

[
T_{recover}
]

を記録する。

Capabilityがどこまで低下し、どの速度で回復したかを測定する。

⸻

10　Learning Cost

Capabilityが上昇しても、Learning Costが極端に高ければ効率的とは限らない。

そこで、

[
\boxed{
C_{learn}

C_{compute}
+
C_{model}
+
C_{human}
+
C_{storage}
+
C_{evaluation}
+
C_{integration}
}
]

を測定する。

さらに、

[
\boxed{
LearningEfficiency

\frac{\Delta VDC}
{C_{learn}}
}
]

とする。

同じCapability Gainを得るために、

Model Fine-tuning、

Knowledge Update、

Memory Update、

Human Training

のどれが最も効率的かを比較できる。

⸻

11　Time to Capability

新しいRequirementが発生してから、要求Capabilityへ到達するまでの時間も測る。

[
\boxed{
TTC

Time\ to\ Capability
}
]

とする。

例えば、

[
Requirement_{new}
\rightarrow
Capability\ge C^*
]

までの時間である。

BaselineがModel Fine-tuningに数日必要で、GEOIがKnowledgeとRouting Updateによって短時間で対応できるなら、その差は重要である。

逆にGEOIのIntegration変更に長い調整が必要なら、その優位性は失われる。

⸻

12　Long-term TCO

短期的に安価なArchitectureが、長期的にも安価とは限らない。

そこで、

[
\boxed{
TCO(T)

C_{build}
+
\int_0^T
(
C_{compute}
+
C_{model}
+
C_{people}
+
C_{maintenance}
+
C_{adaptation}
+
C_{failure}
)dt
}
]

として測定する。

Memory Maintenance。

Knowledge Validation。

Human Review。

Observability。

Architecture Migration。

これらを含める。

GEOIの経済性はInitial Build Costだけでは判断しない。

⸻

13　Learning per Unit Time

Capability Gainを時間で正規化する。

[
\boxed{
LearningVelocity

\frac{\Delta VDC}{\Delta t}
}
]

さらにCostも加えるなら、

[
\boxed{
LearningEfficiency_{time}

\frac{\Delta VDC}
{\Delta TCO\cdot\Delta t}
}
]

とできる。

これによって、

「最終的に強いSystem」

だけでなく、

[
\boxed{
どれだけ速く、どれだけ低Costで、
必要な能力へ到達したか
}
]

を比較できる。

⸻

14　Control Groupを時間にも置く

GEOIのCapabilityが90日後に向上しても、それだけではLearningの証拠にならない。

同期間、

[
\boxed{
NonLearning\ Control
}
]

を運用する。

例えばFeedback Updateを停止した、

[
GEOI-Feedback
]

を並行運用する。

Full GEOIが、

[
C_{full}(t)
]

NonLearning Controlが、

[
C_{control}(t)
]

なら、

[
\boxed{
\Delta C_{time}

C_{full}(t)-C_{control}(t)
}
]

を比較できる。

さらにModel Versionも固定し、外部Model Improvementによる見かけ上のLearningを排除する。

⸻

15　Catastrophic Adaptation

学習によって一部Taskが改善しても、別Taskが悪化する可能性がある。

そこで、

[
\boxed{
CapabilityVector(t)
}
]

全体を測定する。

例えば、

[
C_A\uparrow
]

でも、

[
C_B\downarrow
]

なら、単純なImprovementではない。

Policy Optimizationが一部Taskへ過適応する。

Memoryが特定Patternへ偏る。

Knowledge Updateが以前のContextとConflictする。

このような、

[
\boxed{
Catastrophic\ Adaptation
}
]

を検出する。

⸻

16　Architecture自体のLearning

さらにGEOIでは、Component内部だけでなくArchitectureそのものが更新対象になり得る。

例えばExperimentから、

Memory Retrieval Strategyを変更する。

Agent数を減らす。

Human Approval Pointを変更する。

Relationを切る。

Model Routerを変更する。

すると、

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

が起こる。

ただしSystem自身に無制限なArchitecture変更権限を与えない。

[
Proposal
\rightarrow
Evaluation
\rightarrow
Authorization
\rightarrow
Deployment
\rightarrow
Verification
]

を維持する。

これによってArchitecture Evolution自体をExperimental Recordにできる。

⸻

以上から、本書におけるLearningを、

[
\boxed{
Learning

Experienceによる検証可能なSystem Stateの変化が、
将来のVerified Delivered Capabilityへ
再現可能な差を生じさせること
}
]

として定義する。

そしてGEOIを、

[
\boxed{
GEOI(t)

Architecture_t
+
State_t
+
Memory_t
+
Knowledge_t
+
Relations_t
+
Environment_t
}
]

として観測する。

重要なのは、時間が経過したことでも、Dataが蓄積したことでもない。

[
\boxed{
\textbf{
過去のRealityとの相互作用が、
次のRealityを生成する能力を本当に変えたのか
}
}
]

である。

ここまでで、Modelを交換し、Componentを除去し、Relationを切断し、Realityを変化させ、時間を進めるExperimentが揃った。

これによって、いよいよ第5章の中心問題へ到達する。

観測されたCapabilityは、どこから来ていたのか。

Modelなのか。

Memoryなのか。

Humanなのか。

Relationなのか。

あるいは、それらを一つのSystemとして接続したときにのみ現れる性質なのか。

次節では、

[
\boxed{
Where\ Is\ Intelligence?
}
]

を問い、GEOI研究の中心仮説そのものをExperimentの対象にする。
第7節　Where Is Intelligence?

第5章では、GEOIを測定可能なExperimental Objectへ変換してきた。

Baselineを置いた。

Capabilityを定義した。

Reality Benchmarkを構築した。

ComponentとRelationをAblationした。

Modelを交換した。

時間とLearningを導入した。

これらはすべて、一つの問いへ収束する。

[
\boxed{
Where\ Is\ Intelligence?
}
]

知能は、どこにあるのか。

Modelの内部なのか。

Memoryなのか。

Knowledgeなのか。

Humanなのか。

Agentなのか。

それとも、それらの間に形成されるRelationとSystem Dynamicsなのか。

GEOI研究の中心仮説を、ここで初めて直接Experimentへかける。

⸻

1　Component-centric Hypothesis

現在のAI Engineeringでは、多くの場合、Capabilityの主要な源泉をModelへ置く。

概念的には、

[
\boxed{
H_C:
Capability
\approx
f(Model)
}
]

である。

Model Scale。

Training Data。

Post-training。

Reasoning Capability。

これらがSystem Performanceを大きく規定する。

この説明が正しいなら、GEOIを構成するMemory、Human、Knowledge、Feedbackなどは補助Componentにすぎない。

その場合、

[
\boxed{
Intelligence
\in
Model
}
]

というComponent-centric Explanationで十分である。

⸻

2　Systemic Hypothesis

GEOIが提示するAlternative Hypothesisは異なる。

[
\boxed{
H_S:
Capability

f(
Model,
Memory,
Knowledge,
Human,
Agent,
Organization,
Environment,
Feedback,
Integrity,
Relations,
Time
)
}
]

である。

ここではModel Capabilityを否定しない。

Modelは重要なIntelligence Componentである。

しかしDelivered CapabilityはModel単独のPropertyではなく、

[
\boxed{
System\ Configuration
}
]

によって変化する可能性がある。

この仮説が支持されるなら、

[
\boxed{
Intelligence
\not\subseteq
Model\ only
}
]

となる。

⸻

3　「Relationに知能がある」と先に決めない

ただし、

[
\boxed{
Intelligence\in Relation
}
]

を結論として先に置いてはならない。

Relationは物理的なContainerではない。

したがって科学的には、

[
\boxed{
System-level Capabilityが、
Component単独のCapabilityでは説明できないか
}
]

を問う。

つまり「知能がどこにあるか」は、存在論的断言ではなく、

[
\boxed{
Capability\ Attribution\ Problem
}
]

としてOperationalizeする。

⸻

4　Model Intervention

まずModelを操作する。

[
M_F
\rightarrow
M_M
\rightarrow
M_S
\rightarrow
M_L
]

と変化させ、

[
\Delta C_M
]

を測定する。

Model Capabilityの変化へDelivered Capabilityが強く追随するなら、

[
\boxed{
Model\ Contribution
}
]

は大きい。

反対に、Modelを小さくしてもCapabilityが一定範囲で維持されるなら、他のSystem ComponentがCapabilityを補完している可能性がある。

⸻

5　Component Intervention

次に、

Memory、

Knowledge、

Human、

Feedback、

Integrity

を一つずつ除去する。

[
\Delta C_i

C(A_0)-C(A_{-i})
]

を測定する。

これによって、

[
Contribution_i
]

を推定する。

ただし、

[
\boxed{
Contribution
\neq
Intrinsic\ Intelligence
}
]

である。

例えばMemoryを除去してCapabilityが低下したとしても、「Memoryそのものが知能である」とは限らない。

MemoryとModelのInteractionが必要だった可能性がある。

⸻

6　Relation Intervention

そこでRelationそのものを操作する。

Componentを維持したまま、

[
Agent\rightarrow Memory
]

[
Human\rightarrow Feedback
]

[
Knowledge\rightarrow Planning
]

などのEdgeを切断する。

もしNodeがすべて存在しているにもかかわらずCapabilityが低下するなら、

[
\boxed{
Component\ Presence
}
]

だけではSystem Capabilityを説明できない。

ここで初めて、

[
\boxed{
Relation\ Structure
}
]

がIndependent Engineering Variableとして現れる。

⸻

7　Topologyを変える

Relationの有無だけでなく、Topologyを変える。

例えば、

[
Model\rightarrow Agent\rightarrow Tool
]

という直列構造と、

[
Model
\leftrightarrow
Memory
\leftrightarrow
Knowledge
\leftrightarrow
Human
]

を含むFeedback Structureを比較する。

Component Setを固定して、

[
V_A=V_B
]

とし、

[
E_A\neq E_B
]

とする。

その上で、

[
C(G_A)
]

と、

[
C(G_B)
]

を比較する。

もし、

[
C(G_A)\neq C(G_B)
]

なら、

[
\boxed{
Topology\ matters.
}
]

となる。

これは「何を持っているか」だけでなく、

[
\boxed{
どう接続されているか
}
]

がCapabilityを規定することを意味する。

⸻

8　Interaction Effectを測る

Systemic Intelligence仮説にとって重要なのは非線形なInteractionである。

例えば、

[
C(Memory+Feedback)
]

が、

[
C(Memory)+C(Feedback)
]

から予測される値を超えるかを測る。

一般化すれば、

[
\boxed{
InteractionEffect_{ij}

C_{ij}

C_i

C_j
+
C_0
}
]

である。

Interaction Effectが再現可能に観測されれば、

[
\boxed{
Capability
\neq
\sum ComponentCapabilities
}
]

となる。

これはSystem-level Explanationを必要とする重要なEvidenceになる。

⸻

9　Boundary Intervention

さらにObserver Boundaryを変える。

[
B_1

Model+Agent
]

[
B_2

B_1+Memory+Knowledge
]

[
B_3

B_2+Human
]

[
B_4

B_3+Organization
]

[
B_5

B_4+Environment
]

とする。

そして各Boundaryについて、

Capability Prediction、

Failure Explanation、

Cost Accounting、

Outcome Prediction

がどこまで改善するかを測る。

もしModel BoundaryだけでReality上のOutcomeを十分説明できるなら、GEOIの広いSystem Boundaryは不要である。

逆にBoundaryをHumanやOrganizationまで拡張することで初めてOutcomeを説明できるなら、

[
\boxed{
System\ Boundary
}
]

そのものが知能研究上の重要変数になる。

⸻

10　IntrinsicとDeliveredの差

ここで、

[
\boxed{
Intrinsic\ Capability
}
]

と、

[
\boxed{
Delivered\ Capability
}
]

を再び比較する。

Modelが高いIntrinsic Capabilityを持っていても、

Authority不足、

Knowledge不足、

Tool Failure、

Memory Failure、

Human Coordination Failure

によってDelivered Capabilityが低下する可能性がある。

逆に中規模Modelでも、

適切なKnowledge、

Memory、

Tool、

Human、

Feedback

によって高いDelivered Capabilityへ到達する可能性がある。

そこで、

[
\boxed{
SystemAmplification

\frac{DeliveredCapability}
{IntrinsicCapability}
}
]

を補助指標として測定する。

ただし異なるCapability尺度を安易に除算せず、同一Task Family内で正規化して用いる。

⸻

11　Intelligence Attribution Map

Experiment結果を一つのMapへ統合する。

Verified Delivered Capability
│
├── Model Contribution
├── Memory Contribution
├── Knowledge Contribution
├── Human Contribution
├── Agent Contribution
├── Feedback Contribution
├── Integrity Contribution
├── Relation Contribution
├── Interaction Effects
└── Unexplained Residual

最後の、

[
\boxed{
Unexplained\ Residual
}
]

を消してはならない。

すべてのCapabilityを既知Componentへ強制的に割り当てると、分析は循環する。

説明できない差は、

[
\boxed{
Residual
}
]

として残す。

⸻

12　GEOI Residual

既存Architectureで説明できないSystem-level Effectが反復して観測された場合に限り、

[
\boxed{
GEOI\ Residual
}
]

という概念を導入できる。

例えば、

[
R_{GEOI}

C_{Observed}

C_{ExistingArchitectureModel}
]

とする。

ただし、

[
R_{GEOI}>0
]

だから新しい知能原理が発見されたとは言わない。

Hidden Variable。

Measurement Error。

Human Labor。

Additional Compute。

Uncontrolled Tool Access。

これらを先に排除する。

それでもResidualが再現されるなら、GEOIという分類の説明力を再評価する。

⸻

13　四つの可能な結果

Experimentは少なくとも四つの方向へ進み得る。

第一に、

[
\boxed{
Model\ Dominant
}
]

Model CapabilityがDelivered Capabilityの大部分を説明する。

第二に、

[
\boxed{
Model+Tools\ Dominant
}
]

既存Agentic Architectureで十分説明できる。

第三に、

[
\boxed{
Integrated\ System\ Effect
}
]

Memory、Human、Knowledge、Feedback、Relationの統合による再現可能な追加効果が存在する。

第四に、

[
\boxed{
Task\text{-}Dependent
}
]

Short TaskではModel Dominant、Long-running TaskではSystem Effectというように、領域によって答えが変わる。

第四の結果は十分にあり得る。

⸻

14　「知能の場所」から「知能の生成条件」へ

ここで問いそのものを精密化できる。

「知能はどこにあるか」

という問いは、知能を何らかの場所に保存されたPropertyとして扱っている。

しかしExperimentによってCapabilityがRelation、Environment、Timeによって変化するなら、より適切な問いは、

[
\boxed{
Under\ what\ conditions
does\ intelligence\ emerge\ as\ delivered\ capability?
}
]

となる。

すなわち、

[
\boxed{
Where\ Is\ Intelligence?
\rightarrow
What\ Generates\ Intelligence?
}
]

である。

⸻

15　知能をPropertyからOutcomeへ移す

この転換によって、知能をModel内部の抽象的能力だけでなく、

[
\boxed{
Verified\ Outcome\ Generation
}
]

として観測できる。

[
Model
\rightarrow
Prediction
]

だけではなく、

[
Human
+
Model
+
Memory
+
Knowledge
+
Agent
+
Environment
+
Feedback
\rightarrow
VerifiedOutcome
]

までを一つのExperimental Chainとして扱う。

ここで初めて、

[
\boxed{
Intelligence\ as\ Property\ of\ Component
}
]

と、

[
\boxed{
Intelligence\ as\ Property\ of\ System
}
]

を同じReality上で比較できる。

⸻

16　第5章の結論

第5章でGEOIは、思想でもArchitecture Diagramでもなくなった。

[
\boxed{
Measurable\ System
}
]

になった。

Baselineによって比較対象を固定した。

Capabilityによって測定対象を定義した。

Reality BenchmarkによってOutputとOutcomeを分離した。

AblationによってComponentとRelationへ介入した。

Model DependencyによってModel Contributionを測定した。

Time & LearningによってSystem Stateの変化を測定した。

そして本節によって、

[
\boxed{
Intelligence\ Attribution
}
]

そのものをExperimentへ変換した。

ここから導かれる結論は、まだ一つではない。

[
\boxed{
Intelligence\in Model
}
]

かもしれない。

[
\boxed{
Intelligence\in Model+Tools
}
]

かもしれない。

あるいは、

[
\boxed{
Intelligence

Emergent\ System\ Capability
}
]

として記述した方がRealityをよく説明するかもしれない。

答えはArchitecture Definitionから導かない。

[
\boxed{
Reality
}
]

から決める。

したがって第5章の最終形は、

[
\boxed{
Baseline
\rightarrow
Capability
\rightarrow
Reality
\rightarrow
Ablation
\rightarrow
ModelDependency
\rightarrow
Time
\rightarrow
IntelligenceAttribution
}
]

となる。

そして、このExperimentによってCapabilityの生成源を特定できても、Engineering上の問いはまだ終わらない。

そのCapabilityを得るために、

いくら支払ったのか。

どれだけのComputeを使用したのか。

何人のHumanが介入したのか。

どれだけのIntegration Complexityを抱えたのか。

同じCapabilityを、もっと単純なArchitectureで生成できなかったのか。

次の第Ⅵ部では、知能を性能だけでなく経済量として測定する。

[
\boxed{
Capability
\rightarrow
Cost
}
]

そして問いを、

[
\boxed{
\textbf{
知能はどこにあるのか
}
}
]

から、さらに一段進める。

[
\boxed{
\textbf{
Reality上の知能を、
どのArchitectureが最も効率的に生成できるのか
}
}
]

ここからGEOIのEconomicsが始まる。

愛と敬意を込めてmandala