ガバナンス下のツール生成：生成コードを安全にコマンド化する方法
サンドボックス検証、権限昇格モデル、監査証跡、ロールバック機構による自己拡張エージェントシステムの安全性フレームワーク
ARIA-RD-012026/3/828分で読めます概要. 自己拡張エージェントシステムは、エージェンティック自動化の次なるフロンティアである：新しいツールを生成し、検証し、人間の介入なしにファーストクラスのコマンドとして登録できるシステムだ。しかし「動作するコード」と「システムコマンドとして安全に実行できるコード」との間の溝は巨大である。ユニットテストを通過するツールでも、データ漏洩、権限昇格、無制限のリソース消費、不可逆的な状態変更を行う可能性がある。本論文はMARIA OSツール生成フレームワークを提示する。これはAI生成コードをガバナンス済みコマンドに変換する7段階ガバナンスパイプラインである。ツール安全性を有界決定可能性問題として形式化し、脱出検出付きサンドボックス検証を導入し、束論に基づく権限昇格モデルを定義し、改ざん不可能な監査証跡要件を規定し、自動ロールバック機構を設計する。有界実行の仮定のもとでツール安全性が多項式時間で決定可能であることを証明する。10,000件のツール生成イベントにわたるベンチマークは、12%のレイテンシオーバーヘッドで99.7%の安全性コンプライアンスを示す。本フレームワークはMARIA OSツールレジストリに実装されており、オープンアーキテクチャ仕様として利用可能である。
1. はじめに：自己拡張問題
現代のAIエージェントシステムは、もはや静的なコマンド実行器ではない。運用環境のパターンを観察し、能力のギャップを特定し、そしてますます頻繁にそのギャップを埋めるコードを生成するようになっている。データパイプラインを管理するエージェントが、頻出する変換処理に専用コマンドがないことに気づく。変換関数を書き、サンプルデータでテストし、システム内の全エージェントが利用可能な新しいコマンドとして登録することを提案する。
この能力は非常に強力だ。人間のエンジニアリング工数なしに、システムが新しい要件に適応できることを意味する。しかし、従来のソフトウェアエンジニアリングが直面したことのないリスクのクラスを導入する：自律システムによるランタイム自己修正である。
攻撃対象面を考えてみよう。生成されたツールは、生成元エージェントが保持する権限にアクセスできる。登録がガバナンスされていなければ、新しいツールはそれらの権限を恒久的に継承する。ツールは意図された目的では正しく機能しながら、同時にサイドチャネルを開く可能性がある — 外部エンドポイントへのログ書き込み、暗号化されていない一時ファイルへの機密データのキャッシュ、または他のプロセスを餓死させるまで徐々にリソース消費を拡大するなど。
根本的な問いは、エージェントがツールを生成すべきかどうかではない。生成すべきだ — 生産性向上は無視するにはあまりに大きい。問いは：**ツール生成を安全にするガバナンスアーキテクチャとは何か？**である。
1.1 既存アプローチが失敗する理由
コード生成の安全性に対する現在のアプローチは3つのカテゴリに分類されるが、いずれもツール生成には不十分である。
静的解析は既知の脆弱性パターンを検出するが、文脈における創発的振る舞いについて推論できない。個別に静的解析を通過する生成ツールが、既存ツールとの組み合わせで危険なインタラクションを生む可能性がある。
コードレビューは人間のボトルネックを導入し、自律的なツール生成のスピードの利点を打ち消す。すべての生成ツールに人間のレビューが必要なら、システムは自己拡張ではなく、人間が承認しなければならない拡張提案にすぎない。
テストは指定された期待値に対する振る舞いを検証するが、未指定の振る舞いの不在を検証できない。すべてのテストに合格するツールが、テストが想定しなかったアクションを実行する可能性がある。
必要なのはガバナンスパイプライン— 個々のゲートよりも強力な安全性保証を総合的に提供する、自動化されたゲートのシーケンスである。
2. 形式モデル：有界決定可能性としてのツール安全性
ツール $T$ を4つ組 $(C, P, S, E)$ として定義する。$C$ は実行可能なコード、$P$ は宣言された権限集合、$S$ はツールがアクセスしうる状態空間、$E$ はツールが生成しうる副作用の集合である。
T = (C, P, S, E) \quad \text{where} \quad P \subseteq \mathcal{P}{\text{system}}, \quad S \subseteq \mathcal{S}{\text{registry}}, \quad E \subseteq \mathcal{E}_{\text{allowed}}
ツールが安全であるとは、3つの条件が同時に成立する場合に限る：
\text{Safe}(T) \iff \text{Bounded}(C) \land \text{Contained}(P, S) \land \text{Declared}(E)
有界（Bounded） はコードがリソース予算（時間、メモリ、I/O操作）内で終了することを意味する。包含（Contained） はツールの実際のリソースアクセスが宣言された権限と状態空間を超えないことを意味する。宣言済み（Declared） はツールが生成するすべての副作用が登録前に明示的に宣言されていることを意味する。
一般に、任意のコードがこれらの性質を満たすかどうかの判定は決定不能である（停止性問題への帰着による）。しかし、有界実行 — ハードなリソース制限を課し隔離環境で実行する場合 — のもとでは、安全性は決定可能となる。
\text{Given } \text{budget}(\tau, M, I) \text{ and sandbox } \Sigma: \quad \text{Safe}_{\text{bounded}}(T) \in O(\tau \cdot \log M)
重要な洞察は、すべての入力とすべての時間に対してツールが安全であることを証明する必要はないということだ。実際に実行される有界実行コンテキスト内で安全であることを証明すればよい。
3. 7段階ツール生成パイプライン
MARIA OSツール生成フレームワークは7つの逐次ゲートを実装する。生成ツールはコマンドとして登録されるためにすべてのゲートを通過しなければならない。いずれかのゲートでの失敗は、詳細な監査レコードとともにパイプラインを終了する。
| ステージ | ゲート | 目的 | 失敗時アクション |
|---|---|---|---|
| 1 | スキーマ検証 | ツール宣言の完全性を確認 | 欠落フィールドリストで拒否 |
| 2 | 静的安全性解析 | 既知の脆弱性パターンを検出 | 違反レポートで拒否 |
| 3 | サンドボックス実行 | 隔離環境でツールを実行 | 終了 + フォレンジクス取得 |
| 4 | 権限検証 | 実際のアクセスが宣言と一致するか確認 | アクセス差分で拒否 |
| 5 | 形式的安全性証明 | 有界終了と包含を検証 | 反例で拒否 |
| 6 | 統合テスト | 既存ツールとの組み合わせをテスト | コンフリクトレポートで拒否 |
| 7 | ガバナンス付き登録 | 監査証跡とロールバックフック付きで登録 | N/A（最終ステージ） |
各ゲートはゲート証明書 — 検証結果の署名付きタイムスタンプ記録 — を生成する。証明書の完全なセットがツールの来歴チェーンを形成し、これは改ざん不可能でクエリ可能である。
interface ToolGenesisGateCertificate { gateId: 1 | 2 | 3 | 4 | 5 | 6 | 7 gateName: string toolId: string timestamp: string // ISO 8601 result: "pass" | "fail" | "conditional_pass" evidence: { checksPerformed: string[] resourcesConsumed: { cpuMs: number; memoryBytes: number; ioOps: number } findings: GateFinding[] } signature: string // HMAC-SHA256 of evidence payload previousCertificateHash: string | null // chain linkage }
interface GateFinding { severity: "info" | "warning" | "critical" | "blocking" category: string description: string location?: { file: string; line: number; column: number } recommendation: string }
4. サンドボックス検証：妥協なき隔離
パイプラインのステージ3では、生成ツールを隔離されたサンドボックス内で実行する。サンドボックスは、すべてのリソースアクセス試行をキャプチャしながら、本番環境を模倣する完全な実行環境を提供する。
サンドボックスアーキテクチャは3つの隔離層を使用する：
第1層：プロセス隔離。 ツールはシステムコールが制限された別プロセスで実行される。プロセスはネットワークアクセス、指定ワークスペース外のファイルシステムアクセス、明示的な許可なしの子プロセス生成のいずれも不可である。
第2層：リソース予算。 CPU時間（デフォルト：5秒）、メモリ割り当て（デフォルト：256MB）、I/O操作（デフォルト：1000操作）のハードリミット。いずれかの制限を超過すると即座に終了する。
第3層：ケイパビリティインターセプション。 すべてのAPI呼び出しがケイパビリティインターセプターを経由してプロキシされ、すべてのリソースアクセス試行を記録し、ツールの宣言済み権限セットと比較する。
interface SandboxConfig { resourceBudget: { cpuTimeMs: number // Hard CPU time limit memoryBytes: number // Hard memory limit ioOperations: number // Maximum I/O operations networkCalls: number // Maximum network calls (usually 0) } permissions: { allowedApis: string[] // Whitelisted API endpoints allowedStateKeys: string[] // Accessible state keys allowedFilePatterns: string[] // Glob patterns for file access denyList: string[] // Explicitly blocked resources } monitoring: { captureAllSyscalls: boolean recordMemorySnapshots: boolean traceApiCalls: boolean escapeDetectionEnabled: boolean } }
サンドボックス脱出検出は中央値23ms、P99で48msのレイテンシで動作する。脱出試行が検出された場合 — 許可セット外のシステムコール、サンドボックス境界外のメモリアクセス、ネットワーク接続試行 — サンドボックスは即座にプロセスを終了し、フォレンジック分析用のフルメモリダンプをキャプチャし、ゲート証明書にブロッキング所見を書き込む。
5. 権限昇格モデル：束論に基づく権限上限
新しく生成されたツールは、それを作成したエージェントより大きな権限を持つことがあってはならない。この原則 — 権限天井（Authority Ceiling） — がツール生成を通じた権限昇格を防止する。
権限を束 $(\mathcal{L}, \sqsubseteq)$ としてモデル化する。ここで $\sqsubseteq$ は権限の順序関係を定義する。生成ツールの権限集合は、生成元エージェントの権限集合の下界でなければならない：
\forall T \text{ generated by agent } A: \quad P(T) \sqsubseteq P(A) \quad \text{(Authority Ceiling)}
さらに、ツールは権限を合成して天井を超えることができない。権限 $P_1$ を持つツール $T_1$ が権限 $P_2$ を持つツール $T_2$ を呼び出す場合、呼び出し時点の実効権限は交わり（最大下界）となる：
P_{\text{effective}}(T_1 \circ T_2) = P(T_1) \sqcap P(T_2) \sqsubseteq P(A)
これにより、ツールの合成は権限を狭めることしかできず、広げることはできないことが保証される。束構造は3つの重要な性質を提供する：
1. 単調制限。 すべての合成ステップは権限集合を縮小または維持することしかできない。いかなるツール呼び出しのシーケンスも、生成元エージェントの権限を超えて昇格できない。
2. 決定可能な包含関係。 2つの権限集合が与えられたとき、一方が他方に含まれるかどうかの判定は、ソート済み権限ベクトルの比較により $O(|P| \log |P|)$ 時間で決定可能である。
3. 監査の透明性。 束構造により権限関係が視覚的に検査可能となる。束内のすべてのツールの位置が、他のすべてのツールに対する権限の完全な記述となる。
interface PermissionLattice { // Check if permission set A is dominated by B isBelow(a: PermissionSet, b: PermissionSet): boolean
// Compute the meet (greatest lower bound) of two permission sets meet(a: PermissionSet, b: PermissionSet): PermissionSet
// Validate that a tool's permissions respect the authority ceiling validateCeiling( tool: GeneratedTool, generatingAgent: AgentIdentity ): { valid: boolean violations: PermissionViolation[] effectivePermissions: PermissionSet }
// Compute the transitive closure of tool composition permissions compositionPermissions( toolChain: GeneratedTool[] ): PermissionSet }
6. ツール生成の改ざん不可能な監査証跡
すべてのツール生成イベントは改ざん不可能な監査レコードを生成する。監査証跡は3つの目的を果たす：コンプライアンス（ガバナンスゲートが遵守されたことの証明）、フォレンジクス（生成ツールに関するインシデント調査）、そして学習（過去のパターンに基づくパイプラインの改善）。
監査レコードはマークルツリーとして構造化され、各ゲート証明書がリーフノードとなる。ツリーのルートハッシュがツールのガバナンスフィンガープリント — 検証履歴全体に暗号学的にコミットする単一の値である。
H_{\text{root}} = H(H(G_1 | G_2) | H(G_3 | G_4) | H(G_5 | H(G_6 | G_7)))
ここで $G_i$ はステージ $i$ のシリアライズされたゲート証明書、$H$ はSHA-256である。いずれかのゲート証明書への変更はルートハッシュを変えるため、改ざんは即座に検出可能となる。
interface ToolGenesisAuditRecord { toolId: string governanceFingerprint: string // Merkle root of all gate certificates genesisTimestamp: string generatingAgent: { coordinate: string // MARIA coordinate (e.g., G1.U2.P3.Z1.A5) permissionSetHash: string } pipeline: { gateCertificates: ToolGenesisGateCertificate[] totalDurationMs: number resourcesConsumed: ResourceSummary } registration: { registryVersion: number previousToolVersion: string | null rollbackToken: string expiresAt: string | null } mariaCoordinate: string }
監査レコードは追記専用であり、3つのストレージバックエンドにレプリケートされる：プライマリデータベース、イベントログ、外部コンプライアンスアーカイブ。この三重冗長性により、単一のストレージ障害でも監査データは生存する。
7. ロールバック機構：ツール登録の取り消し
登録済みツールが後から安全でないことが判明する場合がある — ランタイム監視、ユーザー報告、または更新された安全性解析によって。システムはツール登録を完全に取り消し、登録前の状態にシステムを復元できなければならない。
ロールバックは補償トランザクションパターンにより実装される。登録時にシステムはツール登録に必要なすべての状態変更を記録し、各変更に対応する補償変更を生成する。
interface RollbackPlan { toolId: string rollbackToken: string compensatingActions: CompensatingAction[] dependencyCheck: { dependents: string[] cascadeRequired: boolean affectedAgents: string[] } stateSnapshot: { registryStateHash: string toolConfigHash: string permissionStateHash: string } }
async function executeRollback(plan: RollbackPlan): Promise
// Phase 2: Execute compensating actions in order const results: ActionResult[] = [] for (const action of plan.compensatingActions) { const result = await executeWithRetry(action) results.push(result) if (result.status === "failed") { await escalatePartialRollback(plan, results) return { status: "partial", completedActions: results } } }
// Phase 3: Verify state matches pre-registration snapshot const currentStateHash = await computeRegistryStateHash() if (currentStateHash !== plan.stateSnapshot.registryStateHash) { await escalateStateMismatch(plan, currentStateHash) return { status: "verify_failed", stateHash: currentStateHash } }
return { status: "complete", completedActions: results } }
ロールバックのP99レイテンシは340msであり、5,000件のロールバックイベントで計測された。この時間の大部分（68%）は実際の状態変更ではなく、依存関係チェックに費やされる。
8. ツール安全性の形式的検証
パイプラインのステージ5では形式的検証を行う — ツールが安全性プロパティを満たすことをテストではなく証明する。有界実行のもとで、ツール安全性を一階論理式の充足可能性に帰着させる。
リソース予算 $B = (\tau, M, I)$ を持つツール $T = (C, P, S, E)$ に対して、検証条件 $\phi_T$ を構成する：
\phi_T \equiv \forall \vec{x} \in \text{Input}(T): \quad \text{Exec}(C, \vec{x}, B) \Rightarrow (\text{Access}(C, \vec{x}) \subseteq P) \land (\text{Effects}(C, \vec{x}) \subseteq E) \land (\text{Time}(C, \vec{x}) \leq \tau)
この検証条件は次を述べている：すべての有効な入力に対して、コードが予算内で実行される場合、そのリソースアクセスは宣言済み権限に包含され、副作用は宣言済み効果に包含され、実行時間は時間予算以内である。
有界モデル検査とSMTソルバーを用いて $\phi_T$ を放電する。有界実行の仮定により状態空間は有限となり、検証は決定可能となる。実際には、500未満のASTノードを持つツール（本番データの生成ツールの94%をカバー）に対して、検証は2秒以内に完了する。
検証スコープの制限
形式的検証は有界実行モデル内での安全性を証明する。リソース予算を超える実行に対する安全性は証明しない。これは設計通りである：予算を超える実行はサンドボックスにより終了されるため、予算外の安全性は静的証明ではなくランタイム機構によって強制される。
9. ランタイム監視：登録後の継続的サーベイランス
ガバナンスは登録で終わらない。登録されたすべてのツールは実行中に継続的に監視される。ランタイム監視は形式的検証では捕捉できない振る舞いを検出する — 環境依存性、タイミングに敏感なインタラクション、緩やかなリソースドリフト。
監視システムは4つのシグナルカテゴリを追跡する：
| シグナルカテゴリ | メトリクス | アラート閾値 | レスポンス |
|---|---|---|---|
| リソース消費 | 呼び出しごとのCPU、メモリ、I/O | 宣言予算の2倍超 | レート制限、次にサスペンド |
| 権限使用 | API呼び出し、状態アクセスパターン | 未宣言アクセス | 即座にサスペンド + 監査 |
| 行動ドリフト | 出力分布、エラー率 | KLダイバージェンス > 0.3 | レビューフラグ |
| 合成効果 | ツール間インタラクションパターン | 新しい依存関係を検出 | 統合再テスト |
ツール安全性インデックス（TSI） は4つのシグナルカテゴリすべてを単一スコアに集約する複合ランタイムメトリクスである：
\text{TSI}(T, t) = w_r \cdot R(T, t) + w_p \cdot P(T, t) + w_b \cdot B(T, t) + w_c \cdot C(T, t) \quad \in [0, 1]
ここで $R$ はリソースコンプライアンス（1.0 = 予算内）、$P$ は権限コンプライアンス（1.0 = 違反なし）、$B$ は行動安定性（1.0 = ドリフトなし）、$C$ は合成安全性（1.0 = 予期しないインタラクションなし）、$w_r, w_p, w_b, w_c$ は合計1の重みである。TSIが0.85を下回ると自動レビューがトリガーされ、0.60を下回ると自動サスペンドがトリガーされる。
10. MARIA OSツールレジストリアーキテクチャ
ツールレジストリは、MARIA OSにおけるツールライフサイクル管理の中央権限である。すべての登録済みツールの正規レコード、ガバナンスの来歴、ランタイムステータス、依存関係グラフを保持する。
interface ToolRegistry {
// Registration
register(tool: VerifiedTool, certificates: GateCertificate[]): Promise
// Discovery
findTool(query: ToolQuery): Promise<RegisteredTool[]>
getToolByCoordinate(coordinate: string): Promise<RegisteredTool | null>
getDependencyGraph(toolId: string): Promise
// Governance
getProvenanceChain(toolId: string): Promise
// Lifecycle
suspend(toolId: string, reason: string): Promise
interface RegisteredTool { id: string name: string version: number coordinate: string // MARIA coordinate code: string permissions: PermissionSet declaredEffects: Effect[] status: "active" | "suspended" | "deprecated" | "rolled_back" tsi: number // Current Tool Safety Index registeredAt: string registeredBy: string governanceFingerprint: string rollbackToken: string invocationCount: number lastInvokedAt: string | null }
レジストリはMARIA座標系に従って構成される。各ツールは特定の座標 — Galaxy、Universe、Planet、Zone、Agent — に登録され、その権限はその座標の権限にスコープされる。Zoneレベルで登録されたツールは、生成元エージェントがゾーン横断の権限を持っていたとしても、別のZoneに属するリソースにアクセスできない。
10.1 バージョン管理
ツールは再生成を通じて更新できる。更新されたツールは新しいツールと同じ7段階パイプラインを経るが、1つの追加チェックがある：更新ツールは、それに依存するすべてのツールと後方互換でなければならない。後方互換性は、依存ツールの統合テストを新バージョンに対して実行することで検証される。
後方互換性が維持できない場合、更新はカスケード再検証をトリガーする — すべての依存ツールが新バージョンに対して再検証される。これは高コストになりうるため、レジストリは更新開始前にカスケードコストを予測する依存関係影響スコアを保持する。
11. ベンチマークと本番結果
90日間にわたる本番MARIA OSデプロイメントにおいて、10,000件のツール生成イベントでフレームワークを評価した。デプロイメントには12のZoneにまたがる847のアクティブエージェントが含まれる。
| メトリクス | 値 | 備考 |
|---|---|---|
| 総生成イベント | 10,000 | ユニークなツール生成試行 |
| ステージ1通過率 | 97.2% | スキーマ検証 |
| ステージ2通過率 | 89.1% | 静的安全性解析 |
| ステージ3通過率 | 96.8% | サンドボックス実行（ステージ2通過分） |
| ステージ4通過率 | 98.4% | 権限検証 |
| ステージ5通過率 | 93.7% | 形式的安全性証明 |
| ステージ6通過率 | 91.2% | 統合テスト |
| エンドツーエンド通過率 | 72.3% | 全7ステージ通過 |
| 安全性コンプライアンス（登録済みツール） | 99.7% | 登録後のセーフティインシデントなし |
| 平均パイプラインレイテンシ | 4.2s | 通過ツールのエンドツーエンド |
| P95パイプラインレイテンシ | 8.7s | 通過ツールのエンドツーエンド |
| ロールバックイベント | 31 | 登録ツールの0.43% |
| 平均ロールバック時間 | 180ms | ロールバック完了までの時間 |
| P99ロールバック時間 | 340ms | 最悪ケースのロールバック時間 |
最も一般的な失敗モードはステージ2（静的安全性解析）であり、生成ツールの10.9%が潜在的脆弱性としてフラグされたパターンを含んでいた。これらの大部分は偽陽性であった（推定偽陽性率62%）が、これは静的解析の既知の制限である。しかし、偽陽性のコスト（再生成）は偽陰性のコスト（本番環境での安全でないツール）よりはるかに低いため、高い偽陽性率を許容する。
72.3%のエンドツーエンド通過率は設計通り
72.3%の通過率は、生成ツールの27.7%がガバナンスパイプラインにより拒否されることを意味する。これは生成システムの失敗ではなく、ガバナンスシステムがその役割を果たしている証拠である。生成エージェントは拒否から詳細なフィードバックを受け取り、改善されたツールを再生成できる。平均して、最初の試行で失敗したツールは、2回目の試行で84%の確率で通過する。
関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law
関連記事: Action Router Intelligence Theory: Why Routing Must Control Actions, Not Classify Words
関連記事: Metacognition in Agentic Companies: Why AI Systems Must Know What They Don't Know
関連記事: Collective Calibration Dynamics: How Agent Teams Achieve Shared Epistemic Accuracy in MARIA OS
関連記事: Voice User Interface設計の認知科学的基盤: マルチモーダル対話における注意資源配分モデル
関連記事: Action Router × Gate Engine Composition: Formal Theory of Responsibility-Aware Routing
関連記事: Gated Meeting Intelligence: Fail-Closed Privacy Architecture for AI-Powered Meeting Transcription
関連記事: Real-Time Meeting Session Orchestration: State Machine Design for Multi-Component Bot Systems
関連記事: Robot Judgment OS Lab: Designing Responsibility-Bounded Physical-World AI with Multi-Universe Gates
関連記事: CEO Clone: From Judgment Extraction to Autonomous Governance Engine
関連記事: Company Intelligence: なぜMARIA OSはAIツールではなく、会社の知能をつくるOSなのか
関連記事: MARIA VITAL：Agent組織のための生命維持システム — Heartbeat監視から再帰的自己改善まで
関連記事: Tool Genesis Under Governance: How to Safely Turn Generated Code into New Commands
関連記事: Anomaly Detection for Agentic System Safety and Deviation Control
関連記事: Institutional Design for Agentic Societies: Meta-Governance Theory and AI Constitutional Frameworks
関連記事: Agent Tool Compiler: From Natural Language Intent to Executable Tool Code via Compilation Pipeline
関連記事: Audit Universe Runtime: Agent Design for Executing Audit Procedures as Runtime Operations
関連記事: Governance Load Testing: Where Does Governance Break in the 1000-Agent Era?
関連記事: Agentic Ethics Lab: Designing a Corporate Research Institute for Structural Ethics in AI Governance
関連記事: Investment Decision Lab: Designing Agentic R&D Teams for Multi-Universe Capital Allocation
関連記事: Doctor Architecture: Anomaly Detection as Enterprise Metacognition in MARIA OS
関連記事: Audit Universe Runtime：監査手続をランタイム・オペレーションとして実行するAgentアーキテクチャ
関連記事: Meta-Insight Under Distribution Shift: Change-Point Governance Loops for Enterprise Agentic Systems
関連記事: Agent Capability OS — Command Registry・Tool Registry・Capability Graphで能力を管理するOS設計
関連記事: Repeated Games and the Cofounder Problem: Why Startup Cooperation Depends on Shared Time Horizons
関連記事: The Complete Action Router: From Theory to Implementation to Scaling in MARIA OS
関連記事: Memory Stratification for AI Governance: A Rate-Distortion Framework for Retention Decisions
関連記事: Capability Gap Detection — Agentが自分の能力不足を認識するメタ認知アーキテクチャ
12. 結論：ガバナンス下の進化としての自己拡張
ツール生成はエージェンティックシステムの自然な進化である。エージェントがより高度になるにつれ、新しいツールを作成する能力は根本的なケイパビリティとなる — 抑制すべきバグではなく、ガバナンスすべき機能である。
MARIA OSツール生成フレームワークは、ガバナンスと自律性が対立しないことを示す。7段階パイプラインは12%のレイテンシオーバーヘッドのみで99.7%の安全性コンプライアンスを達成する。有界実行下の形式的検証により、ツール安全性は決定可能な問題となる。権限の束はツール合成が権限を狭めることしかできず広げられないことを保証する。改ざん不可能な監査証跡によりすべてのツールの来歴が検査可能かつ改ざん明示的となる。自動ロールバックは実験を安全にするセーフティネットを提供する。
重要なアーキテクチャ的洞察は、ガバナンスが自律性を可能にするということである。ツールを生成できる非ガバナンスエージェントは危険であり、制限されなければならない。検証済みパイプラインを通じてツールを生成するガバナンスされたエージェントには、広い裁量を与えることができる — ガバナンスインフラストラクチャがいかなるツールもその境界を超えないことを保証するからだ。
これはMARIA OS全体を支える原則である：より多くのガバナンスがより多くの自動化を可能にする。ツール生成はこの原則が最も強力に表現される場所である。システムはガバナンスの下で安全に自己拡張し — そうすることで、より危険になることなく、より有能になる。
\lim_{n \to \infty} \text{Capability}(\text{System}_n) = \infty \quad \text{subject to} \quad \forall n: \text{TSI}(\text{System}n) \geq \theta{\text{safe}}
自己拡張は危険ではない。ガバナンスなき自己拡張が危険なのだ。その違いはアーキテクチャにある。