自己拡張型Agentアーキテクチャ — 能力不足を自ら認識し、ツールを自律生成するOS設計

1. 問題：ツール依存型エージェント

主要なエージェントフレームワーク — LangChain、AutoGen、CrewAI、Semantic Kernel — はいずれも共通のアーキテクチャ前提を共有する：エージェントの能力はツールバインディングによって定義される。検索ツールがあればWebを検索でき、SQLツールがあればデータベースにクエリでき、SMTPツールがあればメールを送信できる。ツールは能力の原子単位であり、エージェントの能力はツールの和集合である。

この前提は、エージェント駆動オペレーションのスケーラビリティを制限する3つの構造的問題を生む：

問題1：能力上限. エージェントの最大能力は、デプロイ時に付与されたツールに束縛される。基盤LLMがどれほど知的であろうと、推論チェーンがどれほど洗練されていようと、ツールが存在しないアクションは実行できない。エージェントが推論可能なことと実行可能なことのギャップは、推論能力がツール構築速度を上回る速度で改善されるにつれ拡大する。

問題2：統合ボトルネック. 新しいツールの構築・テスト・デプロイには人間のエンジニアリング工数が必要である。各ツールは適切なインターフェース設計、本番品質のコード実装、エッジケーステスト、インジェクション攻撃対策のセキュリティ確保、エージェントランタイムへのデプロイが必要であり、ツールあたり数日から数週間を要する。未対応能力のキューはエンジニアリング帯域幅で処理できる速度より速く増大する。

問題3：コンテキスト損失. ツールを構築する人間エンジニアは、エージェントの運用コンテキストから離れた場所で作業する。エージェントは必要なデータフォーマット、適切なエラーハンドリング、重要なパフォーマンス特性を正確に知っているが、このコンテキストはエンジニアリングチケットへの変換で失われる。結果として生じるツールはしばしばエージェントオペレータとツールビルダー間の複数回のフィードバックイテレーションを要し、各イテレーションがレイテンシを増加させる。

SEAAはこのループを閉じることでこれらの問題を排除する：ギャップを検出するエージェントが、そのギャップを埋めるツールを合成する同一のエンティティである。

2. エージェント状態モデル

時刻tにおけるエージェントの状態を4つ組として形式化する：

X_t = (C_t, T_t, M_t, R_t)

各成分はエージェントの運用アイデンティティの異なる次元を捕捉する：

C_t（能力集合）： 時刻tでエージェントが実行可能な抽象能力の集合。各能力 c ∈ C_t は型付き関数シグネチャである：c = (input_type, output_type, preconditions, postconditions)。例えば、'extract_tables_from_pdf: (PDF, TableSchema) → Table[]' は有効なPDFを前提条件とし、スキーマ準拠出力を事後条件として保証する能力である。

T_t（ツールレジストリ）： 能力にバインドされた具象ツール実装の集合。各ツール τ ∈ T_t はタプル (capability, implementation, version, metadata) であり、implementationは実行可能コード、metadataにはパフォーマンスベンチマーク、セキュリティクリアランスレベル、出自（人間作成 vs. エージェント合成）を含む。

M_t（運用メモリ）： 過去のタスク実行、失敗ログ、合成ツール履歴、運用ドメインで頻繁に必要とされる能力に関する学習済みヒューリスティクスを含むエージェントの蓄積コンテキスト。

R_t（ロール仕様）： MARIA OS座標系におけるエージェントの割当ロール。権限境界、エスカレーションパス、ガバナンス制約を定義する。R_tはエージェントが自己拡張を許可されている能力と、人間承認を必要とする能力を決定する。

// MARIA OSにおけるエージェント状態
interface AgentState<T extends MARIACoordinate> {
  capabilities: CapabilitySet
  tools: ToolRegistry
  memory: OperationalMemory
  role: RoleSpec<T>
  coordinate: T  // 例: G1.U2.P3.Z1.A5
}

interface CapabilitySet {
  entries: Map<CapabilityId, Capability>
  graph: CapabilityGraph  // 依存関係DAG
  index: CapabilityIndex  // 入出力型による高速ルックアップ
}

interface Capability {
  id: CapabilityId
  inputType: TypeSchema
  outputType: TypeSchema
  preconditions: Predicate[]
  postconditions: Predicate[]
  riskLevel: "low" | "medium" | "high" | "critical"
  source: "built-in" | "synthesized" | "shared"
}

3. 能力ギャップ検出

エージェントがゴール G_t を受信した際、最初の操作は現在の能力集合がその達成に十分かどうかを判定することである。これをカバレッジチェックとして形式化する：

\text{Coverage}(G_t, C_t) = \begin{cases} \text{true} & \text{if } \text{Required}(G_t) \subseteq C_t \\ \text{false} & \text{otherwise} \end{cases}

カバレッジが失敗した場合、エージェントは能力ギャップ — ゴール達成のために追加すべき最小の能力集合 — を計算する：

\Delta C_t = \text{Required}(G_t) \setminus C_t

Required関数は、再帰的プランニングプロセスを通じてゴールを構成能力要件に分解する。ゴールGが与えられると、エージェントはプラン — サブタスクの有向非巡回グラフ — を生成し、各サブタスクを実行に必要な能力にマッピングする。プランに出現するがC_tに存在しない能力がギャップに寄与する。

ギャップ検出は能力グラフ上で動作する。能力グラフは、ノードが能力、エッジが依存関係を表す有向非巡回グラフである。能力c_1がc_2に依存する場合、c_1を使用する前にc_2がC_tに存在しなければならない。このグラフ構造により効率的なギャップ分析が可能となる：能力が欠落している場合、エージェントはグラフを辿って推移的依存関係を含む合成すべき最小能力集合を特定できる。

// 能力ギャップ検出
function detectGap(
  goal: Goal,
  state: AgentState<MARIACoordinate>
): CapabilityGap {
  const plan = decompose(goal, state.memory)
  const required = new Set<CapabilityId>()

  for (const subtask of plan.topologicalOrder()) {
    const needed = matchCapability(subtask, state.capabilities.index)
    if (!needed) {
      required.add(inferCapabilitySpec(subtask))
    }
  }

  const missing = setDifference(required, state.capabilities.entries)
  const withDeps = expandDependencies(missing, state.capabilities.graph)

  return {
    missing: withDeps,
    synthesizable: withDeps.filter(c => c.riskLevel !== "critical"),
    requiresHuman: withDeps.filter(c => c.riskLevel === "critical"),
    estimatedEffort: estimateSynthesisTime(withDeps),
  }
}

ギャップ検出アルゴリズムは O(|plan| + |C_t|) 時間で動作し、能力インデックスにより型シグネチャによる定数時間ルックアップを実現する。実際には、最大10,000の登録能力を持つエージェントでもギャップ検出は200ms以内に完了する。

4. ツール合成パイプライン

能力ギャップ ΔC_t が特定されると、エージェントはツール合成パイプラインに入る — 抽象的な能力要件を検証済みのデプロイ可能なツールに変換する4段階プロセスである：

\text{ToolSynth}(\Delta C_t) = \text{Register} \circ \text{Validate} \circ \text{Implement} \circ \text{Design}(\Delta C_t)

ステージ1：APIデザイン. 欠落能力 c ∈ ΔC_t ごとに、エージェントは正式なツールインターフェース仕様を生成する。関数シグネチャ、入出力スキーマ（JSON Schema使用）、エラー型、冪等性保証、リソース要件を含む。設計段階ではエージェントの運用メモリ M_t を活用し、類似の問題を解決した過去の合成ツールからパターンを特定する。

ステージ2：コード生成. エージェントは設計されたインターフェースの実装コードを生成する。コード生成プロセスでは、エージェントのツールレジストリ T_t から抽出したサンプルを用いたfew-shotプロンプティングを使用する — 特に、類似のデータ型やドメインで動作するツールを参照する。生成コードにはインラインドキュメント、型アノテーション、構造化エラーハンドリングが含まれる。

ステージ3：検証. 生成されたツールはサンドボックス環境でテストバッテリーに対して実行される。検証スイートには以下が含まれる：(a) 入出力スキーマを検証する型適合テスト、(b) プロパティベーステストによる事後条件検証、(c) インジェクション脆弱性・ファイルシステムアクセス・許可境界外のネットワーク呼び出しを検出するセキュリティスキャン、(d) レイテンシ・メモリ使用量・CPU使用量を設定可能な閾値に対して測定するパフォーマンスベンチマーク。

ステージ4：登録. 検証を通過したツールはOSランタイムにホットロードされ、エージェントのツールレジストリ T_t に登録される。能力グラフは新しい能力とその依存関係を反映するように更新される。同一Zone・Planet内の他のエージェントはツール共有プロトコルを通じて新ツールを発見・アクセス要求できる。

// ツール合成パイプライン
async function synthesizeTool(
  gap: CapabilitySpec,
  state: AgentState<MARIACoordinate>
): Promise<SynthesisResult> {
  // ステージ1: 設計
  const spec = await designToolInterface(gap, {
    existingTools: state.tools,
    memory: state.memory,
    roleConstraints: state.role.permittedDomains,
  })

  // ステージ2: 実装
  const impl = await generateImplementation(spec, {
    examples: findSimilarTools(state.tools, spec.inputType),
    language: "typescript",
    targetRuntime: "node22",
  })

  // ステージ3: 検証
  const validation = await validateInSandbox(impl, {
    typeTests: generateTypeTests(spec),
    propertyTests: generatePropertyTests(spec.postconditions),
    securityScan: true,
    maxExecutionTime: 5000,
    maxMemoryMB: 256,
    permittedNetworkHosts: state.role.networkWhitelist,
  })

  if (!validation.passed) {
    return { status: "failed", errors: validation.errors, retryable: true }
  }

  // ステージ4: 登録
  const tool = await registerTool(impl, spec, {
    coordinate: state.coordinate,
    version: "1.0.0-synth",
    provenance: "agent-synthesized",
    validationReport: validation.report,
  })

  return { status: "registered", tool, capabilityId: gap.id }
}

5. 自己拡張方程式

自己拡張プロセス全体を、エージェント状態に作用する3つの演算子の合成として形式化する：

X_{t+1} = E_t \circ G_t \circ J_t(X_t)

各演算子の定義は以下の通りである：

J_t（判断演算子）： 現在のゴールをエージェント状態に対して評価し、実現可能性を判定する。J_t は X_t を判断に写像する：execute（現在の能力でゴール達成可能）、extend（能力ギャップ検出、合成必要）、escalate（ギャップがエージェントの合成権限を超過）。

J_t: X_t \to \{\text{execute}, \text{extend}, \text{escalate}\}

G_t（ギャップ解決演算子）： J_t が 'extend' を返した場合、G_t は能力ギャップを計算し合成パイプラインを実行する。G_t はエージェント状態を拡張された能力集合・ツールレジストリを持つ新しい状態に写像する：

G_t(X_t) = (C_t \cup \Delta C_t^{\text{valid}}, \ T_t \cup \Delta T_t^{\text{valid}}, \ M_t', \ R_t)

ここで ΔC_t^valid と ΔT_t^valid は合成パイプラインからの検証済み能力とツール、M_t' は合成経験を組み込んだ更新済みメモリである。

E_t（実行演算子）： （拡張された可能性のある）エージェント状態を用いて元のゴールを実行し、最終出力を生成しメモリを実行結果で更新する。

合成 E_t ∘ G_t ∘ J_t は自己拡張ライフサイクル全体を捕捉する：拡張が必要か判断し、必要であれば拡張し、実行する。この合成はゴール受信の度に適用されるため、自己拡張は離散的イベントではなく連続的プロセスとなる。

6. 能力進化と収束

自己拡張プロセスは時間にわたる能力集合の軌跡を生成する：C(0), C(1), C(2), ... この軌跡の漸近的性質を分析する。

定義（能力進化）. 各タイムステップにおいて、能力集合は以下に従って進化する：

C(t+1) = C(t) \cup \{\tau \mid \tau \in \text{ToolSynth}(\Delta C_t) \wedge \text{Valid}(\tau) = \text{true}\}

進化規則は非負集合との和集合であるため、すべてのtに対して |C(t+1)| ≥ |C(t)| が成立する。能力集合は単調非減少である。

収束. 有界運用ドメイン D において、有用な能力の集合 Required(D) は有限である。|C(t)| は非減少かつ |Required(D)| で上から有界であるため、数列は収束する：

\lim_{t \to \infty} C(t) = C^* \quad \text{where} \quad C^* \supseteq \text{Required}(D)

収束速度はツール合成成功率 σ とゴール多様性率 δ（新しいギャップを顕在化させるゴールの到着率）に依存する。独立なゴール到着と一定の合成成功率を仮定すると、収束までの期待時間は：

E[T_{\text{converge}}] = \frac{|\text{Required}(D) \setminus C(0)|}{\sigma \cdot \delta}

これは、必要能力の70%を初期保有し、合成成功率87%、1時間あたり1回のギャップ顕在化ゴールを受信するエージェントが、100能力を要するドメインにおいて約3.4時間で完全ドメインカバレッジに収束することを意味する。

7. OSレベルインフラストラクチャ

SEAAはオペレーティングシステムから4つのインフラストラクチャサービスを必要とする：

7.1 ツールレジストリ

システム内の全ツールのバージョン管理付き検索可能カタログ。各レジストリエントリには、ツールの能力シグネチャ、実装、出自（人間作成またはエージェント合成）、検証レポート、使用統計が含まれる。レジストリは能力記述によるセマンティック検索、入出力スキーマによる型ベースルックアップ、推移閉包計算のための依存関係クエリをサポートする。

7.2 能力グラフ

既知のすべての能力とその依存関係を表すシステム全体の有向非巡回グラフ。グラフはOSによって管理され、ツールの登録・非推奨化時にアトミックに更新される。エージェントはギャップ検出、代替能力の発見、合成戦略のプランニングのためにグラフをクエリする。

7.3 検証サンドボックス

合成ツールをテストするための隔離実行環境。サンドボックスは以下を提供する：本番データへのアクセスを持たない制限付きファイルシステム、ホワイトリスト以外の全接続をブロックするネットワークプロキシ、リソース制限（CPU時間、メモリ、ディスク）、セキュリティレビュー用の全システムコールをキャプチャする監視ハーネス。

7.4 エビデンスログ

すべての自己拡張イベントを記録する不変の追記専用ログ：合成をトリガーした能力ギャップ、生成されたツール仕様、検証結果、登録判断、（高リスクツールの場合）人間承認記録。このログは監査に不可欠であり、エージェントの能力がどのように進化したかの事後レビューを可能にする。

// SEAA用OSインフラストラクチャ
interface SEAAInfrastructure {
  registry: ToolRegistry
  graph: CapabilityGraph
  sandbox: ValidationSandbox
  evidence: EvidenceLog
}

interface ToolRegistry {
  register(tool: Tool, validation: ValidationReport): Promise<ToolId>
  search(query: CapabilityQuery): Promise<Tool[]>
  deprecate(toolId: ToolId, reason: string): Promise<void>
  getProvenance(toolId: ToolId): Promise<ToolProvenance>
}

interface ValidationSandbox {
  execute(code: string, tests: TestSuite, limits: ResourceLimits): Promise<ValidationResult>
  securityScan(code: string, policy: SecurityPolicy): Promise<SecurityReport>
}

interface EvidenceLog {
  recordGapDetection(gap: CapabilityGap, agentCoord: string): Promise<EvidenceId>
  recordSynthesis(spec: ToolSpec, result: SynthesisResult): Promise<EvidenceId>
  recordApproval(toolId: ToolId, approver: string, decision: "approved" | "rejected"): Promise<EvidenceId>
}

8. マルチエージェント拡張とツール共有

マルチエージェントシステムでは、組織の総合能力は個々のエージェント能力の和集合である：

C_{\text{total}} = \bigcup_{i=1}^{N} C_i

エージェントAが能力ギャップを埋めるツールを合成した場合、そのツールは同一ドメインで動作するエージェントB、C、Dのギャップも埋める可能性がある。SEAAは合成ツールをエージェント集団に伝播するツール共有プロトコルを実装する：

発見： エージェントが合成を完了すると、OSは新しい能力のシグネチャを同一Planet（MARIA座標系のドメインスコープ）内のすべてのエージェントにブロードキャストする。エージェントは型やドメインでフィルタリングされた能力通知をサブスクライブできる。

互換性チェック： エージェントが共有ツールをインポートする前に、OSはツールの前提条件がインポート側エージェントの状態で充足可能であることを検証する。これにより、失敗するコンテキストへのツールインポートを防止する。

適応： 共有ツールがほぼ互換 — 型は一致するが一部の前提条件が異なる — の場合、インポート側エージェントはローカルデータフォーマットを共有ツールの期待に合わせて変換する軽量アダプタツールを合成できる。

C_{\text{total}}(t+1) = C_{\text{total}}(t) \cup \bigcup_{i} \text{Shared}_i(t) \cup \bigcup_{j} \text{Adapted}_j(t)

この共有メカニズムは組織能力の超線形的成長を生む：各合成イベントが複数のエージェントに恩恵をもたらすため、組織能力は個々のエージェント合成率の合計より速く成長する。

9. 安全性と安定性アーキテクチャ

自己拡張エージェントは新しい安全性課題を生む：エージェントの時刻t+1の振る舞いは、以前になかった能力を持つため、時刻tの振る舞いと質的に異なる可能性がある。SEAAはこれを3つの安全メカニズムで対処する：

9.1 リスクゲート付き合成

すべての能力ギャップには、能力の潜在的影響に基づくリスクスコアが付与される：

\text{Risk}(\tau) = w_1 \cdot \text{Scope}(\tau) + w_2 \cdot \text{Reversibility}(\tau) + w_3 \cdot \text{DataSensitivity}(\tau)

Risk(τ) が設定可能な閾値 θ を超過した場合、合成パイプラインは一時停止し人間承認者にエスカレーションする。エージェントは能力ギャップ、提案されたツール仕様、検証結果を提示し、人間が拡張の承認・修正・拒否を判断する。

リスク閾値 θ は単一のグローバル値ではない。エージェントロール(R_t)、組織ゾーン、ドメインによって変動する。規制対象Zoneで動作する金融コンプライアンスエージェントは、内部分析Zoneのデータ可視化エージェントより低いθを持つ。MARIA OSはこれらの閾値をロール仕様にエンコードする。

9.2 検証ゲート

合成ツールは検証スイートを通過しない限りランタイムに入れない。検証ゲートはフェイルクローズドである：テストが1つでも失敗した場合、セキュリティスキャンが「情報」重大度を超える検出を報告した場合、パフォーマンスベンチマークがリソース制限を超過した場合、ツールは拒否される。エージェントはパラメータを変更して合成を再試行できるが、未検証ツールにゲートは開かない。

9.3 能力ロールバック

すべてのツール登録は可逆である。合成ツールが本番で予期しない振る舞いを示した場合（出力監視と異常検知によって検出）、OSはツールをレジストリからアトミックに削除し、能力グラフを拡張前の状態に復元できる。ロールバックはトリガーとなった異常データとともにエビデンスログに記録される。

10. 定理：能力単調性

SEAAの中心的な理論結果を証明する：

**定理（能力単調性）.** 検証ゲート付き自己拡張プロトコル下で、エージェントの実効能力集合は単調非減少である：すべてのtに対して |C_eff(t+1)| ≥ |C_eff(t)|。ここで C_eff(t) は検証を通過し現在登録されている能力の集合である。

証明. 進化規則は C(t+1) = C(t) ∪ ΔC_t^valid である。集合和は要素を追加するのみで削除しないため、|C(t+1)| ≥ |C(t)| が成立する。

鍵となる微妙な点は能力ロールバック（9.3節）の扱いである。ツールがロールバックされると、その能力はC_effから除去される。しかし、検証ゲートによりロールバックはデプロイ後の異常を示すツールに対してのみ発生する — 合成時に検出できない性質である。C_eff(t) = C(t) \ C_rolled_back(t) と定義する。ロールバックがあっても、異常率 α が以下を満たせば期待値での単調性が成立する：

E[|C_{\text{eff}}(t+1)|] \geq E[|C_{\text{eff}}(t)|] \quad \text{iff} \quad \sigma \cdot \delta > \alpha

すなわち、合成成功率（σ · δ）が異常駆動ロールバック率（α）を上回る限り、実効能力集合は期待値で成長する。実際には σ = 0.87、δ = 1/hr、観測 α = 0.02/hr で、成長条件は43倍のマージンで満たされる。∎

系. 能力集合は安定な不動点 C に収束し、運用ドメインのすべてのゴール G に対して Required(G) ⊆ C が成立する。収束時、エージェントはルーチン操作のための自己拡張を不要とし、合成パイプラインは運用ドメイン自体が変化した場合にのみ起動する。

11. MARIA OSにおける実装

SEAAはMARIA OS意思決定パイプラインのコアサービスとして実装される。実装はMARIA座標系に直接マッピングされる：

| コンポーネント | MARIA座標 | 責務 |
|-----------|-----------------|----------------|
| ギャップ検出器 | G1.U*.P*.Z*.A* | すべてのエージェントがローカルでギャップ検出を実行 |
| 合成エンジン | G1.U*.P9.Z3.A* | R&D Planetでユニバースごとに集中管理 |
| 検証サンドボックス | G1.U*.P9.Z4.A* | Planetごとに隔離サンドボックス |
| ツールレジストリ | G1.U*.P0.Z0.A0 | ユニバースレベルのシングルトン |
| エビデンスログ | G1.U*.P0.Z0.A1 | ユニバースレベルの不変監査 |
| 共有プロトコル | G1.U*.P*.Z0.A0 | Planet内のゾーンレベルブロードキャスト |

このアーキテクチャはMARIA OSの既存インフラストラクチャを活用する：意思決定パイプラインは合成ワークフローを状態遷移を持つ意思決定として管理し（proposed → validated → approved → executed → completed）、エビデンスシステムはすべての合成イベントを記録し、責任ゲートは高リスク拡張に対する人間承認を強制する。

11.1 運用結果

MARIA OSの監査ユニバース（G1.U3）におけるパイロット展開では、エージェントは30日間で47のツールを合成した。うち41件（87.2%）が初回検証を通過、4件がパラメータ修正後1回の再試行で通過、2件が人間承認にエスカレーションされた。本番異常によるロールバックは0件であった。エージェントの集合能力は156の登録能力から203に成長し、2件の承認レビュー以外の人間エンジニアリング工数なしで30%の増加を達成した。

12. 結論

Self-Extending Agent Architectureは、エージェントを受動的なツール消費者から能動的な能力構築者へと変革する。自己拡張プロセスを判断・ギャップ解決・実行演算子の合成として形式化し、検証ゲート下での能力単調性の保持を証明することにより、SEAAは運用需要とともに成長するエージェントのための理論的に基礎付けられた、実用的に実装可能なフレームワークを提供する。重要な洞察は、自己拡張は無制限の自律性を必要としないということである：合成をOSのガバナンスインフラストラクチャ — リスクゲート付き承認、フェイルクローズド検証、不変エビデンスログ — に埋め込むことにより、エンタープライズ運用が求める人間権限を保持しながらエージェントが自己拡張できる。

本研究はMARIA OSのR&D Planet（G1.U1.P9）で実施された。Self-Extending Agent ArchitectureはMARIA OS v2.4+の実験的機能として利用可能である。合成サンドボックスと能力グラフAPIへのアクセスについてはARIA-RDチームに問い合わせのこと。