1. ツール依存問題
すべてのエージェントフレームワークは根本的な制約を課す：エージェントはツールが許す範囲のことしかできない。この制約はエージェントアーキテクチャに深く埋め込まれており、めったに疑問視されない。LangChainはエージェントを「LLM＋ツール」と定義する。AutoGenエージェントはツールを介したアクションで通信する。CrewAIはロール設定の一部としてエージェントにツールを割り当てる。ツールはインフラストラクチャとして扱われる — エージェントの前に存在し、エージェントが消費するが決して生成しないもの。
この設計は静的な依存チェーンを生む：
従来型ツールチェーン（静的）
================================
人間エンジニア → ツール設計 → 実装 → テスト → デプロイ → エージェントバインディング
↑ |
└────────────────── フィードバック（数日〜数週間）─────────────────┘
自己拡張型ツールチェーン（動的）
====================================
Agent → ギャップ検出 → ツール設計 → 実装 → サンドボックス検証 → 登録
↑ |
└──────────────────── フィードバック（数分）─────────────────────┘静的チェーンには、エンタープライズ規模のエージェント運用にとって致命的な3つの特性がある：
線形スケーリング. 新しい能力ごとに専用のエンジニアリング工数が必要である。10ドメインの100エージェントがそれぞれ5つのドメイン固有ツールを必要とすれば、500のエンジニアリングプロジェクトとなる。エージェントではなくエンジニアリングチームがボトルネックとなる。
コンテキスト蒸発. ツールを必要とするエージェントは、正確なデータフォーマット、エラー条件、パフォーマンス要件を理解している。しかしこのコンテキストはチケットに翻訳され、エージェントを操作したことのないエンジニアが解釈し、実装に再エンコードされなければならない。各翻訳ステップで忠実度が失われる。
時間的ミスマッチ. エージェントはミリ秒タイムスケールで動作する。エンジニアリングは週タイムスケールで動作する。エージェントがバッチ処理中の午前2時にギャップを検出した場合、ギャップは営業時間まで — しばしばそれ以降数日間 — 埋められないままとなる。ギャップが持続する毎秒、エージェントの運用価値が劣化する。
2. フェーズ1：ツールディスカバリ
ツールディスカバリは、エージェントがツールセットに能力が欠落していることを特定するプロセスである。これは受動的なプロセスではなく、タスクプランニング中の能動的な内省を必要とする。
エージェントがタスクを受信すると、実行プランを生成する：すべて成功すれば所望の出力を生成する操作のシーケンス（またはDAG）である。プラン内の各操作はツールにマッピングされる。マッピングが失敗した場合 — 操作に対応するツールがない場合 — エージェントはツールギャップを発見したことになる。
ディスカバリプロセスは能力グラフ上で動作する。すべての登録済み能力とその型シグネチャのシステム全体のインデックスである。エージェントは必要な入出力型と操作のセマンティック記述でグラフをクエリする。クエリは3つの結果のいずれかを返す：
完全一致： 必要な能力に正確に一致するツールが存在する。ディスカバリイベントは生成されない。
部分一致： 必要な入力型のスーパーセットまたはサブセットを処理するツール、または必要な出力型のスーパーセットまたはサブセットを生成するツールが存在する。エージェントはアダプタ付きでこのツールを使用できる可能性があるか、特殊化バージョンの合成が必要かもしれない。
一致なし： システム内に必要な能力を処理するツールがない。完全合成イベントがトリガーされる。
// ツールディスカバリエンジン
interface DiscoveryResult {
status: "exact" | "partial" | "none"
existingTools: Tool[]
gap: CapabilitySpec | null
adaptationPath: AdaptationSpec | null
synthesisRequired: boolean
}
async function discoverTool(
operation: PlannedOperation,
graph: CapabilityGraph,
agent: AgentState<MARIACoordinate>
): Promise<DiscoveryResult> {
// 型シグネチャによるクエリ
const typeMatches = graph.queryBySignature(
operation.inputType,
operation.outputType
)
if (typeMatches.exact.length > 0) {
return {
status: "exact",
existingTools: typeMatches.exact,
gap: null,
adaptationPath: null,
synthesisRequired: false,
}
}
if (typeMatches.partial.length > 0) {
const adaptation = computeAdaptation(
typeMatches.partial[0],
operation
)
if (adaptation.feasible) {
return {
status: "partial",
existingTools: typeMatches.partial,
gap: adaptation.residualGap,
adaptationPath: adaptation,
synthesisRequired: !adaptation.adapterOnly,
}
}
}
// フォールバックとしてのセマンティック検索
const semanticMatches = await graph.semanticSearch(
operation.description,
{ limit: 5, minSimilarity: 0.85 }
)
if (semanticMatches.length > 0) {
return {
status: "partial",
existingTools: semanticMatches,
gap: inferGapFromSemanticMatch(semanticMatches[0], operation),
adaptationPath: null,
synthesisRequired: true,
}
}
return {
status: "none",
existingTools: [],
gap: operationToCapabilitySpec(operation),
adaptationPath: null,
synthesisRequired: true,
}
}ディスカバリイベントはエージェントのMARIA座標、ディスカバリをトリガーした操作、クエリパラメータ、結果とともにエビデンスシステムに記録される。このログにより、組織全体の能力ギャップのシステムレベル分析が可能になる — 例えば「監査ユニバースのエージェントはPDFテーブル抽出を頻繁に必要とするが、ツールが存在しない」といったパターンの特定。
3. フェーズ2：ツール合成
ツール合成は、抽象的な能力仕様を具体的な実行可能コードに変換する。合成プロセスは構造化パイプラインに従う：自然言語要件 → インターフェース仕様 → 実装 → テストスイート。
3.1 インターフェース仕様
最初のステップは能力ギャップを正式なインターフェース仕様に変換する。仕様には以下が含まれる：
- 関数シグネチャ：入力型、出力型、ジェネリックパラメータ
- 前提条件：実行前に成立すべきアサーション（例：「入力ファイルは有効なPDFでなければならない」）
- 事後条件：実行後に成立すべきアサーション（例：「出力テーブルはスキーマに準拠する」）
- エラー分類：予期される障害モードとそのエラー型の列挙
- リソース制約：最大実行時間、メモリ使用量、ネットワークアクセス要件
- 冪等性保証：同一入力での繰り返し呼び出しが同一出力を生成するかどうか
// 生成されたインターフェース仕様
interface ToolSpec {
name: string
version: string
description: string
signature: {
input: JSONSchema
output: JSONSchema
generics?: GenericParam[]
}
preconditions: Predicate[]
postconditions: Predicate[]
errors: ErrorType[]
resourceBounds: {
maxExecutionMs: number
maxMemoryMB: number
networkAccess: "none" | "whitelist" | "unrestricted"
fileSystemAccess: "none" | "read-only" | "scoped-write"
}
idempotent: boolean
pureFunction: boolean
}
// 例：OCRテーブル抽出ツール仕様
const ocrTableSpec: ToolSpec = {
name: "extract-tables-from-scanned-pdf",
version: "1.0.0",
description: "OCRを使用してスキャン済みPDF請求書から表形式データを抽出",
signature: {
input: { type: "object", properties: {
pdf: { type: "string", format: "binary", description: "PDFファイルコンテンツ" },
schema: { "$ref": "#/definitions/TableSchema" },
language: { type: "string", enum: ["en", "ja"], default: "ja" }
}, required: ["pdf", "schema"] },
output: { type: "array", items: { "$ref": "#/definitions/ExtractedTable" } }
},
preconditions: [
{ assertion: "pdf.isValid()", message: "入力は有効なPDFでなければならない" },
{ assertion: "pdf.pageCount <= 100", message: "PDFは100ページ以下でなければならない" }
],
postconditions: [
{ assertion: "output.every(t => t.conformsTo(schema))", message: "全テーブルがスキーマに準拠" },
{ assertion: "output.every(t => t.confidence >= 0.7)", message: "OCR信頼度 >= 70%" }
],
errors: [
{ code: "INVALID_PDF", message: "入力は有効なPDFファイルではない" },
{ code: "OCR_FAILURE", message: "OCRエンジンがページの処理に失敗" },
{ code: "NO_TABLES_FOUND", message: "表形式コンテンツが検出されなかった" }
],
resourceBounds: { maxExecutionMs: 30000, maxMemoryMB: 512, networkAccess: "none", fileSystemAccess: "scoped-write" },
idempotent: true,
pureFunction: true,
}3.2 実装生成
エージェントはインターフェース仕様をプロンプトコンテキストとして使用し、実装コードを生成する。生成プロセスは構造化アプローチに従う：
1. 依存関係分析：実装が活用できる既存ツールとライブラリを特定する。エージェントはツールレジストリで構成要素として機能しうる部分一致を検索する。 2. Few-shotエグゼンプラー：レジストリから類似の型シグネチャを持つ3〜5のツール実装を構造テンプレートとして取得する。 3. コード生成：完全な型アノテーション、仕様内の各エラー型に対するエラーハンドリング、インラインドキュメント付きの実装を生成する。 4. テスト生成：以下をカバーするテストスイートを生成する：(a) 各入力型組み合わせのハッピーパス、(b) 各前提条件の境界条件、(c) 各エラー型のエラーパス、(d) 事後条件のプロパティベーステスト。
重要な洞察は、エージェントがこのツールがなぜ必要でどのように使われるかの完全なコンテキストを持っているということである。このコンテキストは、二次情報から作業するエンジニアが構築する汎用ツールとは異なり、運用要件に正確に調整された実装を生成する。
4. フェーズ3：ツール検証
合成ツールは検証フェーズを通過しない限り本番ランタイムに入れない。このフェーズはアーキテクチャにおける安全性クリティカルなゲートであり — フェイルクローズドである。いかなる失敗も拒否に帰結する。
検証はサンドボックス内で並行実行される4つの独立チェックで構成される：
4.1 機能の正確性
生成されたテストスイートが実装に対して実行される。テストには個別関数のユニットテスト、エンドツーエンドパイプラインの統合テスト、ランダム入力を生成して事後条件の成立を検証するプロパティベーステストが含まれる。合格閾値は100% — 1つのテスト失敗でツールは拒否される。
4.2 セキュリティスキャン
静的解析パスが生成コードのセキュリティ脆弱性をスキャンする：
- インジェクションベクター：サニタイゼーションなしのSQL、シェルコマンド、ファイルパスへの文字列補間の検出
- 不正アクセス：許可スコープ外のファイルシステム読み書き、非ホワイトリストホストへのネットワーク接続、環境変数アクセスの検出
- リソース乱用：無限ループ、深度制限なしの再帰呼び出し、リソース制約を超えるメモリ割り当ての検出
- データ流出：期待される出力チャネルをバイパスする入力からネットワーク出力へのデータフローの検出
// セキュリティスキャンパイプライン
interface SecurityScanResult {
passed: boolean
findings: SecurityFinding[]
riskScore: number // 0.0（安全）〜 1.0（クリティカル）
}
interface SecurityFinding {
severity: "info" | "low" | "medium" | "high" | "critical"
category: "injection" | "access" | "resource" | "exfiltration" | "dependency"
location: { file: string; line: number; column: number }
description: string
remediation: string
}
async function securityScan(
code: string,
spec: ToolSpec,
policy: SecurityPolicy
): Promise<SecurityScanResult> {
const findings: SecurityFinding[] = []
// 静的解析
findings.push(...await analyzeInjectionVectors(code))
findings.push(...await analyzeFileSystemAccess(code, spec.resourceBounds))
findings.push(...await analyzeNetworkAccess(code, spec.resourceBounds))
findings.push(...await analyzeResourceUsage(code, spec.resourceBounds))
findings.push(...await analyzeDependencies(code, policy.allowedDependencies))
const maxSeverity = Math.max(...findings.map(f => severityScore(f.severity)), 0)
const passed = maxSeverity < severityScore(policy.rejectThreshold)
return {
passed,
findings,
riskScore: maxSeverity,
}
}4.3 パフォーマンスベンチマーク
ツールはベンチマークデータセットに対して実行され、レイテンシ、スループット、メモリ消費量、CPU使用量を測定する。結果は仕様で宣言されたリソース制約と比較される。いずれかの制約を超過するツールは拒否される。
4.4 振る舞い監視
サンドボックス実行中、すべてのシステムコールが記録される：ファイルオープン、ネットワーク接続、プロセス生成、メモリ割り当て。このトレースは仕様から導出された期待振る舞いプロファイルと比較される。予期しないシステムコール — 例えば仕様が 'networkAccess: none' を宣言しているのにネットワーク接続が発生 — はテスト結果に関係なく拒否をトリガーする。
検証サンドボックスはソフトな提案ではなく、ハードなセキュリティ境界である。本番データ、本番ネットワーク、本番クレデンシャルへのアクセスを持たない隔離コンテナで実行される。サンドボックスファイルシステムはエフェメラルであり、各検証実行後に破棄される。この隔離は不可欠である：合成コードは検証を通過するまで信頼されないコードである。5. フェーズ4：ツール登録
4つの検証チェックをすべて通過したツールは、OSランタイムへの登録対象となる。登録は単純なファイルコピーではなく、複数のシステムコンポーネントをアトミックに更新する構造化プロセスである：
5.1 レジストリエントリ. ツールはシステム全体のツールレジストリに仕様、実装、検証レポート、出自メタデータとともに追加される。出自レコードには以下が含まれる：ツールを合成したエージェント（MARIA座標で識別）、合成をトリガーした能力ギャップ、タイムスタンプ、検証レポートのハッシュ。
5.2 能力グラフ更新. システムの能力グラフが新しい能力ノードとその依存関係エッジを含むように更新される。この更新はアトミックである — グラフは登録前の状態から登録後の状態へ中間的な不整合なしに遷移する。
5.3 ホットローディング. ツール実装は再起動なしでエージェントのランタイムにロードされる。エージェントは能力ギャップを最初にトリガーしたタスクのために新ツールを直ちに使用開始できる。このホットローディングメカニズムは不可欠である：Discovery-to-Registrationパイプライン全体がバックグラウンドプロセスとしてではなく、単一タスク実行内で動作するよう設計されている。
5.4 通知ブロードキャスト. OSは同一Planetスコープ内のすべてのエージェントにツール登録イベントをブロードキャストする。他のエージェントは共有プロトコルを通じてツールを発見・インポートできる。
// ツール登録プロセス
async function registerTool(
implementation: ToolImplementation,
spec: ToolSpec,
validation: ValidationReport,
agent: AgentState<MARIACoordinate>,
infrastructure: SEAAInfrastructure
): Promise<RegisteredTool> {
// アトミックトランザクション
return await infrastructure.registry.transaction(async (tx) => {
// 1. レジストリエントリ作成
const entry = await tx.insert("tools", {
name: spec.name,
version: spec.version,
spec: JSON.stringify(spec),
implementation: implementation.code,
validationReport: JSON.stringify(validation),
provenance: {
synthesizedBy: agent.coordinate,
synthesizedAt: new Date().toISOString(),
gapTrigger: spec.description,
validationHash: hash(validation),
},
status: "active",
})
// 2. 能力グラフ更新
await infrastructure.graph.addCapability({
id: entry.id,
inputType: spec.signature.input,
outputType: spec.signature.output,
dependencies: implementation.dependencies,
})
// 3. エージェントランタイムへのホットロード
await agent.tools.load(entry.id, implementation)
// 4. Planetスコープへのブロードキャスト
await infrastructure.registry.broadcast({
type: "tool-registered",
toolId: entry.id,
capability: spec.name,
scope: agent.coordinate.toPlanetScope(),
})
// 5. エビデンス記録
await infrastructure.evidence.record({
type: "tool-registration",
agentCoordinate: agent.coordinate,
toolId: entry.id,
validationSummary: validation.summary,
})
return entry
})
}6. ツールライフサイクル管理
登録済みツールは静的なアーティファクトではない。バージョニング、監視、非推奨化、置換を含むライフサイクルを持つ：
バージョニング. 各ツールにはセマンティックバージョンがある。エージェントが既存ツールの改善版を合成した場合 — パフォーマンス向上、入力サポート拡大、エッジケース障害の削減 — 新バージョンは旧バージョンと並行して登録される。能力グラフはバージョンクエリをサポートし、エージェントが要件に最適なバージョンを選択できる。
ランタイム監視. すべてのツール呼び出しが監視される：実行時間、メモリ使用量、エラー率、出力品質（事後条件に対して測定）。これらのメトリクスは集約され検証ベンチマークと比較される。ツールの本番メトリクスが検証メトリクスから大幅に乖離した場合 — 例えば本番エラー率がサンドボックスエラー率の10倍 — 異常アラートが生成される。
非推奨化. ツールは以下の場合に非推奨化できる：優れた代替が利用可能な場合、基礎能力が不要になった場合、セキュリティ脆弱性が発見された場合。非推奨化されたツールは監査目的でレジストリに残るが、能力グラフクエリからは除外される。
置換. ツールが非推奨化されると、OSは自動置換合成をトリガーできる。元ツールの仕様が起点となり、非推奨化理由が改善のコンテキストを提供する。
7. 数学的モデル
7.1 ツール生成率
λ をエージェントが能力ギャップに遭遇する率（単位時間あたりのギャップ数）、σ を合成が初回試行で有効なツールを生成する確率とする。期待ツール生成率は：
R_{\text{gen}} = \lambda \cdot \sigma + \lambda \cdot (1 - \sigma) \cdot \sigma_{\text{retry}} \cdot p_{\text{retry}}ここで σ_retry は再試行時の成功確率（エージェントが初回失敗から学習するため通常σより高い）、p_retry はエスカレーションではなく再試行を試みる確率である。実際には λ = 0.2/hr、σ = 0.87、σ_retry = 0.93、p_retry = 0.8 で、生成率は約0.19 tools/hrまたは1.6 tools/agent-dayとなる。
7.2 品質収束
ツール品質 Q をテスト合格率、セキュリティスキャンスコア、パフォーマンスベンチマーク準拠を組み込んだ [0, 1] の複合スコアとして定義する。品質をエージェントの合成経験 n（過去に合成したツール数）の関数としてモデル化する：
Q(n) = Q_{\max} - (Q_{\max} - Q_0) \cdot e^{-\beta n}ここで Q_0 は初期品質（初回合成試行）、Q_max は漸近的最大品質、β は学習率である。実験的に Q_0 ≈ 0.72、Q_max ≈ 0.94、β ≈ 0.12 である。これは20回の合成イテレーション後にツール品質が理論的最大値の93%に達することを意味する。
品質収束はエージェントの運用メモリによって駆動される。各合成試行 — 成功・失敗を問わず — は仕様、実装、検証結果、エラー詳細とともに記録される。エージェントはこの履歴をfuture合成のfew-shotコンテキストとして使用し、「PDF処理ツールは明示的なエンコーディング処理が必要」や「データベースツールはコネクションタイムアウトを処理すべき」といったパターンを学習する。これは汎用LLM改善ではなく、ドメイン固有・エージェント固有の学習である。7.3 組織能力の成長
N エージェントのマルチエージェントシステムにおいて、組織能力成長率は個別合成とクロスエージェント共有の両方に依存する。α を共有採用率（共有ツールが他エージェントに採用される確率）とする：
\frac{d|C_{\text{org}}|}{dt} = N \cdot R_{\text{gen}} \cdot (1 + \alpha \cdot (N - 1) \cdot \gamma)ここで γ は互換性係数（適応なしでツールが互換であるエージェントの割合）。因子 (1 + α(N-1)γ) は共有増幅率 — ツール共有が実効生成率を増加させる乗数 — である。N = 15エージェント、α = 0.68、γ = 0.31 のデプロイメントでは、共有増幅率は3.2xである。
8. マルチエージェントツール共有
エージェントがツールを合成した場合、それが埋める能力は同じドメインで動作する他のエージェントにも必要とされることが多い。MARIA OSは階層座標系を活用したスコープ付きディスカバリのためのツール共有プロトコルを実装する：
ゾーンレベル共有（例：G1.U3.P2.Z1.*）：同一運用ゾーン内のすべてのエージェントがツール登録通知を自動受信する。ゾーンレベルで合成されたツールは、ゾーンレベルエージェントが同一データ型とワークフローで動作するため、通常高い互換性を持つ。
プラネットレベル共有（例：G1.U3.P2..）：ツールはドメイン全体にブロードキャストされる。異なるゾーンのエージェントはツール使用に型アダプタが必要な場合があるが、セマンティック能力は関連性がある。
ユニバースレベル共有（例：G1.U3...*）：クロスドメインツール共有。ツールの仕様はユニバース全体の能力インデックスに公開されるが、採用には明示的な互換性検証が必要である。
9. ケーススタディ：監査エージェントが実行時にOCR抽出ツールを生成
本節では、MARIA OSの監査ユニバース（G1.U3）での実デプロイメントシナリオを記述する。
コンテキスト. 監査エージェント G1.U3.P2.Z1.A3 は四半期監査のために2,400件のサプライヤー請求書バッチを処理していた。エージェントはPDFテキスト抽出、金額検証、発注書との照合ツールを持っていた。しかし340件の請求書はスキャン文書 — 紙の請求書を写真撮影またはFAXしてPDFとして保存 — であり、抽出可能なテキストレイヤーを含んでいなかった。
ディスカバリ（T+0ms）. エージェントが最初のスキャン請求書を処理しようとした際、PDFテキスト抽出ツールは空の結果を返した。エージェントのプランには「請求書フィールド抽出」操作が含まれていた。能力グラフで「PDFからの画像ベーステキスト抽出」をクエリした結果、完全一致はなく、1つの部分一致（互換性のない出力型を持つ汎用画像キャプションツール）が返された。ディスカバリがギャップをログした。
合成（T+180ms〜T+8min）. エージェントは入力型（PDFバイナリ + TableSchema）と出力型（ExtractedTable[]）の 'extract-tables-from-scanned-pdf' ツール仕様を生成した。既存のPDFテキスト抽出ツールと画像処理ユーティリティを構成要素として使用し、以下を行う実装を生成した：(1) 各PDFページを画像にラスタライズ、(2) Tesseractライブラリバインディングを使用したOCR適用、(3) グリッドライン検出によるテーブル境界検出、(4) セルコンテンツの抽出と提供スキーマへのマッピング、(5) 各抽出値の信頼度スコア計算。
検証（T+8min〜T+11min）. サンドボックスがテストスイートを50件のテスト請求書（エージェントがテンプレートデータから生成）に対して実行した。結果：48/50テスト合格（96%）。2件の失敗は回転ページのエッジケースであった。エージェントは自動的に回転検出を処理するよう実装を改良し、テストを再実行（50/50合格）、セキュリティスキャンを検出ゼロで通過した。
登録（T+11min〜T+12min）. ツールは登録・ホットロードされ、エージェントは処理を再開した。340件のスキャン請求書は94.2%の抽出信頼度で47分で処理された。ツールはその後ゾーンレベル共有を通じて監査ユニバースの6つの他エージェントに採用された。
| フェーズ | 所要時間 | 主要メトリク |
|-------|----------|------------|
| ディスカバリ | 180ms | 能力グラフクエリによるギャップ特定 |
| 合成 | 7分48秒 | 1仕様 + 1実装 + 1テストスイート生成 |
| 検証 | 3分12秒 | 50/50テスト、0セキュリティ検出、リソース制約内 |
| 登録 | 48秒 | ホットロード、グラフ更新、6件の共有通知送信 |
| **合計** | **12分18秒** | **2週間のエンジニアリング見積もりとの比較** |10. 安全性アーキテクチャ
自己拡張エージェントはアーキテクチャレベルで対処すべき新しい安全性の懸念を導入する：
10.1 権限境界
各エージェントのロール仕様（R_t）はツール合成が許可されるスコープを定義する。監査エージェントはデータ抽出ツールを合成できるが、財務記録を変更するツールは合成できない。営業エージェントはCRM統合ツールを合成できるが、HRデータにアクセスするツールは合成できない。これらの境界は検証サンドボックスによって強制される：エージェントの許可スコープ外のリソースにアクセスしようとする合成コードはセキュリティスキャンフェーズで拒否される。
10.2 ロールバックメカニズム
すべてのツール登録は可逆である。OSはツールのアトミック削除と能力グラフの登録前状態への復帰を可能にするロールバックログを維持する。ロールバックは以下によってトリガーされる：(a) 本番メトリクスが検証ベンチマークから乖離した際の自動異常検知、(b) 人間オペレータレビュー、(c) 登録ツールが依存するツール自体がロールバックされた際のカスケード依存関係障害。
11. 比較：従来型 vs 自己拡張型ツールチェーン
| 次元 | 従来型 | 自己拡張型 |
|-----------|-------------|----------------|
| ツール作成時間 | 数日〜数週間 | 数分 |
| コンテキスト忠実度 | 低（チケット媒介） | 高（エージェント直接） |
| スケーリングモデル | 線形（ツールあたり1エンジニア） | 超線形（共有増幅） |
| 24/7可用性 | なし（営業時間） | あり（自律） |
| 検証厳密度 | チームにより変動 | 標準化（フェイルクローズドサンドボックス） |
| 監査証跡 | 部分的（チケット、PR） | 完全（エビデンスログ） |
| ロールバック能力 | 手動デプロイメント | アトミックOSレベル |
| クロスエージェント再利用 | アドホック | プロトコル駆動共有 |
| ツールあたりコスト | $2K〜$15Kエンジニアリング | 〜$0.12コンピュート |
| 能力成長 | 線形 | 指数的（収束的） |コスト差は特に顕著である。従来のツール開発にはエンジニア人件費、コードレビュー、QAテスト、デプロイメントエンジニアリング、保守オーバーヘッドが含まれる。自己拡張型ツール合成にはLLM推論、サンドボックス実行、検証のコンピュートリソースのみが必要であり、現行API料金で合成ツールあたり約$0.12である。
12. 結論
自らツールを書くエージェントは、エージェントアーキテクチャの考え方における根本的な転換を表す。ツールはもはやエージェントが動作する前にプロビジョニングされなければならないインフラストラクチャではなく、エージェントが運用ワークフローの自然な一部として生成するアーティファクトである。4フェーズアーキテクチャ — Discovery, Synthesis, Validation, Registration — はこの自己拡張のための構造化された、安全な、監査可能なプロセスを提供する。重要なエンジニアリング上の洞察は、安全性はエージェントのツール作成能力の制限を必要としないということである；作成されたすべてのツールが本番システムに影響を与える前に厳格なフェイルクローズド検証ゲートを通過することを確保することを必要とする。MARIA OS内では、このアーキテクチャはすでに運用中であり、監査ユニバースのエージェントは日々ツールを合成・共有し、人間のエンジニアリングチームでは追いつけない速度で組織能力を構築している。
Tool Discovery, Synthesis, Validation, Registration APIはMARIA OS v2.4+のSelf-Extending Agent機能フラグ下で利用可能である。検証サンドボックスにはNode.js 22とコンテナ隔離用のDockerが必要である。統合の詳細についてはARIA-RD-01テクニカルリファレンスを参照のこと。