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<RollbackResult> {
// Phase 1: Dependency check
if (plan.dependencyCheck.cascadeRequired) {
const cascadeApproval = await requestCascadeApproval(plan)
if (!cascadeApproval.approved) {
return { status: "blocked", reason: "cascade_not_approved" }
}
}
// 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<RegistrationResult>
deregister(toolId: string, reason: string): Promise<DeregistrationResult>
// Discovery
findTool(query: ToolQuery): Promise<RegisteredTool[]>
getToolByCoordinate(coordinate: string): Promise<RegisteredTool | null>
getDependencyGraph(toolId: string): Promise<DependencyGraph>
// Governance
getProvenanceChain(toolId: string): Promise<ToolGenesisAuditRecord>
getSafetyIndex(toolId: string): Promise<number>
getPermissionBounds(toolId: string): Promise<PermissionSet>
// Lifecycle
suspend(toolId: string, reason: string): Promise<void>
resume(toolId: string, approval: ApprovalRecord): Promise<void>
rollback(toolId: string, rollbackToken: string): Promise<RollbackResult>
}
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%の通過率は、生成ツールの27.7%がガバナンスパイプラインにより拒否されることを意味する。これは生成システムの失敗ではなく、ガバナンスシステムがその役割を果たしている証拠である。生成エージェントは拒否から詳細なフィードバックを受け取り、改善されたツールを再生成できる。平均して、最初の試行で失敗したツールは、2回目の試行で84%の確率で通過する。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}}自己拡張は危険ではない。ガバナンスなき自己拡張が危険なのだ。その違いはアーキテクチャにある。