1. ツールの依存関係の問題
すべてのエージェント フレームワークには基本的な制約が課せられます。つまり、エージェントはツールで許可されることしか実行できません。この制約はエージェント アーキテクチャに深く組み込まれているため、疑問視されることはほとんどありません。 LangChain では、エージェントを「LLM とツール」として定義しています。 AutoGen エージェントは、ツールを介したアクションを通じて通信します。 CrewAI は、役割設定の一部としてツールをエージェントに割り当てます。ツールはインフラストラクチャとして扱われます。これは、エージェントの前に存在し、エージェントが使用するだけで作成することはありません。
この設計では、静的な依存関係チェーンが作成されます。
Traditional Tool Chain (Static)
================================
Human Engineer → Tool Design → Implementation → Testing → Deployment → Agent Binding
↑ |
└────────────────── feedback (days/weeks) ──────────────────────────────┘
Self-Extending Tool Chain (Dynamic)
====================================
Agent → Gap Detection → Tool Design → Implementation → Sandbox Validation → Registration
↑ |
└──────────────────── feedback (minutes) ──────────────────────────────────────┘静的チェーンには、エンタープライズ規模のエージェント操作にとって 3 つの致命的な特性があります。
線形スケーリング。 新しい機能ごとに専用のエンジニアリング作業が必要です。 10 のドメインにわたる 100 のエージェントがそれぞれ 5 つのドメイン固有のツールを必要とする場合、500 のエンジニアリング プロジェクトになります。エージェントではなくエンジニアリング チームがボトルネックになります。
コンテキストの蒸発。 ツールを必要とするエージェントは、正確なデータ形式、エラー条件、およびパフォーマンス要件を理解しています。ただし、このコンテキストはチケットに変換され、エージェントを操作したことのないエンジニアによって解釈され、実装に再エンコードされる必要があります。各翻訳ステップでは忠実度が失われます。
時間的な不一致。 エージェントはミリ秒のタイムスケールで動作します。エンジニアリングは週単位で行われます。バッチ処理の実行中にエージェントが午前 2 時にギャップを検出すると、そのギャップは営業時間まで埋められず、営業時間以降は数日続くこともよくあります。エージェントの運用価値はギャップが続くごとに低下します。
2. フェーズ 1: ツールの発見
ツール検出は、エージェントがツールセットに機能が欠落していることを識別するプロセスです。これは受動的なプロセスではなく、タスク計画中に能動的な内省が必要です。
エージェントはタスクを受け取ると、実行プラン、つまりすべてが成功した場合に目的の出力を生成する操作のシーケンス (または DAG) を生成します。プラン内の各操作はツールにマップされます。マッピングが失敗した場合、つまり操作に対応するツールがない場合、エージェントはツールのギャップを発見したことになります。
検出プロセスは、登録されているすべての機能とその型署名のシステム全体のインデックスである 機能グラフ 上で動作します。エージェントは、必要な入出力タイプと必要な操作のセマンティック記述を使用してグラフをクエリします。クエリは次の 3 つの結果のいずれかを返します。
完全一致: 必要な機能に正確に一致するツールが存在します。検出イベントは生成されません。
部分一致: 必要な入力タイプのスーパーセットまたはサブセットを処理するツール、または必要な出力タイプのスーパーセットまたはサブセットを生成するツールが存在します。エージェントはこのツールをアダプターとともに使用できる可能性があります。あるいは、特殊なバージョンを合成する必要がある場合もあります。
一致しません: システム内のツールが必要な機能を処理していません。これにより、完全合成イベントがトリガーされます。
// Tool Discovery Engine
interface DiscoveryResult {
status: "exact" | "partial" | "none"
existingTools: Tool[] // exact or partial matches
gap: CapabilitySpec | null // null if exact match found
adaptationPath: AdaptationSpec | null // non-null if partial match
synthesisRequired: boolean
}
async function discoverTool(
operation: PlannedOperation,
graph: CapabilityGraph,
agent: AgentState<MARIACoordinate>
): Promise<DiscoveryResult> {
// Query by type signature
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,
}
}
}
// Semantic search as fallback
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 である必要がある」)
- 事後条件: 実行後に保持する必要があるアサーション (例: 「出力テーブルがスキーマに準拠している」)
- エラー分類: 予想される故障モードとそのエラー タイプの列挙
- リソース境界: 最大実行時間、メモリ使用量、およびネットワーク アクセス要件
- 冪等性の保証: 同じ入力での呼び出しの繰り返しが同じ出力を生成するかどうか
// Generated Interface Specification
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
}
// Example: OCR Table Extraction Tool Spec
const ocrTableSpec: ToolSpec = {
name: "extract-tables-from-scanned-pdf",
version: "1.0.0",
description: "Extract tabular data from scanned PDF invoices using OCR",
signature: {
input: { type: "object", properties: {
pdf: { type: "string", format: "binary", description: "PDF file content" },
schema: { "$ref": "#/definitions/TableSchema" },
language: { type: "string", enum: ["en", "ja"], default: "en" }
}, required: ["pdf", "schema"] },
output: { type: "array", items: { "$ref": "#/definitions/ExtractedTable" } }
},
preconditions: [
{ assertion: "pdf.isValid()", message: "Input must be a valid PDF" },
{ assertion: "pdf.pageCount <= 100", message: "PDF must have <= 100 pages" }
],
postconditions: [
{ assertion: "output.every(t => t.conformsTo(schema))", message: "All tables conform to schema" },
{ assertion: "output.every(t => t.confidence >= 0.7)", message: "OCR confidence >= 70%" }
],
errors: [
{ code: "INVALID_PDF", message: "Input is not a valid PDF file" },
{ code: "OCR_FAILURE", message: "OCR engine failed to process page" },
{ code: "NO_TABLES_FOUND", message: "No tabular content detected" }
],
resourceBounds: { maxExecutionMs: 30000, maxMemoryMB: 512, networkAccess: "none", fileSystemAccess: "scoped-write" },
idempotent: true,
pureFunction: true,
}3.2 実装の生成
エージェントは、インターフェイス仕様をプロンプト コンテキストとして使用して実装コードを生成します。生成プロセスでは、構造化されたアプローチが使用されます。
1. 依存関係の分析: 実装で利用できる既存のツールとライブラリを特定します。エージェントは、ツール レジストリを検索して、構成要素として機能する部分一致を探します。 2. 少数ショットのサンプル: 構造テンプレートとして機能する、同様のタイプ シグネチャを持つツールの 3 ～ 5 個の実装をレジストリから取得します。 3. コード生成: 完全な型アノテーション、仕様内のすべてのエラー タイプのエラー処理、およびインライン ドキュメントを備えた実装を生成します。 4. テスト生成: (a) 各入力タイプの組み合わせのハッピー パス、(b) 各前提条件の境界条件、(c) 各エラー タイプのエラー パス、(d) 事後条件のプロパティ ベースのテストをカバーするテスト スイートを生成します。
重要な洞察は、エージェントがこのツールが「なぜ」必要なのか、そして「どのように」使用されるのかについて完全なコンテキストを持っているということです。このコンテキストにより、エンジニアが受け売りの説明に基づいて構築した汎用ツールとは異なり、運用要件に正確に合わせた実装が生成されます。
4. フェーズ 3: ツールの検証
合成されたツールは、検証フェーズを通過せずに実稼働ランタイムに入りません。このフェーズは、アーキテクチャにおけるセーフティクリティカルなゲートです。フェールクローズされており、障害が発生すると拒否されます。
検証は、サンドボックス内で並行して実行される 4 つの独立したチェックで構成されます。
4.1 機能の正確性
生成されたテスト スイートは実装に対して実行されます。テストには、個々の関数の単体テスト、エンドツーエンドのパイプラインの統合テスト、ランダム入力を生成して事後条件が保持されていることを検証するプロパティベースのテストが含まれます。合格のしきい値は 100% です。テストが 1 回失敗すると、ツールは拒否されます。
4.2 セキュリティスキャン
静的分析パスは、生成されたコードをスキャンしてセキュリティの脆弱性を探します。
- インジェクション ベクトル: サニタイズなしで SQL、シェル コマンド、またはファイル パスへの文字列補間を検出
- 不正アクセス: 許可された範囲外のファイルシステムの読み取り/書き込み、ホワイトリストに登録されていないホストへのネットワーク接続、または環境変数へのアクセスの検出
- リソースの不正使用: 境界のないループ、深さ制限のない再帰呼び出し、またはリソース境界を超えるメモリ割り当ての検出
- データ漏洩: 予想される出力チャネルをバイパスする、入力からネットワーク出力へのデータ フローの検出
// Security Scanning Pipeline
interface SecurityScanResult {
passed: boolean
findings: SecurityFinding[]
riskScore: number // 0.0 (safe) to 1.0 (critical)
}
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[] = []
// Static analysis
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」と宣言されている場合のネットワーク接続) は、テスト結果に関係なく拒否をトリガーします。
The validation sandbox is a hard security boundary, not a soft suggestion. It runs in an isolated container with no access to production data, production network, or production credentials. The sandbox filesystem is ephemeral and destroyed after each validation run. This isolation is critical: synthesized code is untrusted code until it passes validation.5. フェーズ 4: ツールの登録
4 つの検証チェックすべてに合格したツールは、OS ランタイムに登録できます。登録は単純なファイルのコピーではなく、複数のシステム コンポーネントをアトミックに更新する構造化されたプロセスです。
5.1 レジストリ エントリ。 ツールは、その仕様、実装、検証レポート、および来歴メタデータとともにシステム全体のツール レジストリに追加されます。来歴レコードには、ツールを合成したエージェント (MARIA 座標によって識別される)、合成をトリガーした機能ギャップ、タイムスタンプ、検証レポートのハッシュが含まれます。
5.2 能力グラフの更新。 システムの能力グラフが更新され、新しい能力ノードとその依存関係エッジが含まれます。この更新はアトミックです。つまり、グラフは中間の不整合を生じることなく、登録前の状態から登録後の状態に遷移します。
5.3 ホットロード。 ツール実装は、再起動を必要とせずにエージェントのランタイムにロードされます。エージェントは、最初に機能ギャップを引き起こしたタスクに対して新しいツールの使用をすぐに開始できます。このホットロード メカニズムは重要です。検出から登録までのパイプライン全体は、バックグラウンド プロセスとしてではなく、単一のタスク実行内で動作するように設計されています。
5.4 通知ブロードキャスト。 OS は、同じ Planet スコープ内のすべてのエージェントにツール登録イベントをブロードキャストします。他のエージェントは、共有プロトコルを通じてツールを検出してインポートできます。
// Tool Registration Process
async function registerTool(
implementation: ToolImplementation,
spec: ToolSpec,
validation: ValidationReport,
agent: AgentState<MARIACoordinate>,
infrastructure: SEAAInfrastructure
): Promise<RegisteredTool> {
// Atomic transaction
return await infrastructure.registry.transaction(async (tx) => {
// 1. Create registry entry
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. Update capability graph
await infrastructure.graph.addCapability({
id: entry.id,
inputType: spec.signature.input,
outputType: spec.signature.output,
dependencies: implementation.dependencies,
})
// 3. Hot-load into agent runtime
await agent.tools.load(entry.id, implementation)
// 4. Broadcast to Planet scope
await infrastructure.registry.broadcast({
type: "tool-registered",
toolId: entry.id,
capability: spec.name,
scope: agent.coordinate.toPlanetScope(),
})
// 5. Record evidence
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/時間、σ = 0.87、σ_retry = 0.93、および p_retry = 0.8 の場合、生成速度は 1 時間あたり約 0.19 ツール、またはエージェント 1 日あたり 1.6 ツールになります。
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% に達することを意味します。
Quality convergence is driven by the agent's operational memory. Each synthesis attempt — successful or failed — is recorded with its specification, implementation, validation results, and any error details. The agent uses this history as few-shot context for future syntheses, learning patterns like 'PDF processing tools need explicit encoding handling' or 'database tools must handle connection timeouts.' This is not generic LLM improvement — it is domain-specific, agent-specific learning.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.2 倍です。
8. マルチエージェントツールの共有
エージェントがツールを合成するとき、そのツールが満たす機能は、多くの場合、同じドメイン内で動作する他のエージェントによって必要とされます。 MARIA OS は、スコープを絞った検出のために階層座標系を活用するツール共有プロトコルを実装しています。
ゾーンレベルの共有 (例: G1.U3.P2.Z1.*): 同じ操作ゾーン内のすべてのエージェントは、ツール登録通知を自動的に受信します。ゾーン レベルのエージェントは同じデータ型とワークフローで動作するため、ゾーン レベルで合成されたツールは通常、高い互換性があります。
プラネットレベルの共有 (例: G1.U3.P2..): ツールはドメイン全体にブロードキャストされます。異なるゾーンのエージェントがツールを使用するにはタイプ アダプターが必要になる場合がありますが、セマンティック機能が関係します。
ユニバース レベルの共有 (例: G1.U3...*): クロスドメイン ツールの共有。このツールの仕様はユニバース全体の機能インデックスに公開されていますが、採用するには明示的な互換性検証が必要です。
共有プロトコルには、エージェントが共有ツールをインポートできるようにする前に、タイプの互換性、前提条件の充足性、リソース バインドの一貫性を検証する 互換性チェッカー が含まれています。ツールが「ほぼ」互換性がある場合 (セマンティクスは一致しているが、型の詳細が一部異なる場合)、インポート エージェントは、共有ツールのインターフェイスに一致するようにローカル データ形式を変換する軽量の アダプター ツールを合成できます。
9. ケーススタディ: 監査エージェントが実行時に OCR 抽出ツールを作成する
このセクションでは、MARIA OS の Audit Universe (G1.U3) からの実際の展開シナリオについて説明します。
コンテキスト 監査エージェント G1.U3.P2.Z1.A3 は、四半期監査のために 2,400 件のサプライヤー請求書のバッチを処理していました。このエージェントは、PDF テキストの抽出、金額検証、発注書との相互参照のためのツールを備えていました。ただし、請求書のうち 340 件はスキャンされた文書 (写真または FAX で送信された紙の請求書を PDF として保存したもの) であり、抽出可能なテキスト レイヤーは含まれていませんでした。
検出 (T+0 ミリ秒)。 エージェントが最初にスキャンした請求書を処理しようとしたとき、PDF テキスト抽出ツールは空の結果を返しました。エージェントの計画には、「請求書フィールドの抽出」操作が含まれていました。 「PDF からの画像ベースのテキスト抽出」について機能グラフをクエリすると、完全一致は返されず、部分一致が 1 つ返されました (互換性のない出力タイプを持つ汎用画像キャプション ツール)。 Discovery はギャップを記録しました。
合成 (T+180 ミリ秒から T+8 分)。 エージェントは、入力タイプ (PDF バイナリ + TableSchema) と出力タイプ (ExtractedTable[]) を使用して「extract-tables-from-scanned-pdf」のツール仕様を生成しました。このエージェントは、既存の PDF テキスト抽出ツールと画像処理ユーティリティを構成要素として使用して、(1) 各 PDF ページを画像にラスタライズし、(2) Tesseract ライブラリ バインディングを使用して OCR を適用し、(3) グリッド線検出を使用してテーブル境界を検出し、(4) セルの内容を抽出して提供されたスキーマにマッピングし、(5) 抽出された各値の信頼スコアを計算する実装を生成しました。
検証 (T+8 分 ～ T+11 分)。 サンドボックスは、50 個のテスト請求書 (テンプレート データからエージェントによって生成された) に対してテスト スイートを実行しました。結果: 48/50 のテストに合格しました (96%)。 2 つの失敗は、ページが回転された特殊なケースでした。エージェントは、ローテーション検出を処理するように実装を自動的に調整し、テストを再実行し (50/50 パス)、検出結果なしでセキュリティ スキャンに合格しました。
登録 (T+11 分から T+12 分)。 ツールが登録され、ホットロードされ、エージェントが処理を再開しました。スキャンされた 340 枚の請求書は 94.2% の抽出信頼性で 47 分で処理されました。その後、このツールはゾーンレベルの共有を通じて監査ユニバース内の他の 6 つのエージェントに採用されました。
| Phase | Duration | Key Metric |
|-------|----------|------------|
| Discovery | 180ms | Gap identified via capability graph query |
| Synthesis | 7m 48s | 1 spec + 1 implementation + 1 test suite generated |
| Validation | 3m 12s | 50/50 tests, 0 security findings, within resource bounds |
| Registration | 48s | Hot-loaded, graph updated, 6 sharing notifications sent |
| **Total** | **12m 18s** | **Compared to 2-week engineering estimate** |10. 安全アーキテクチャ
自己拡張エージェントは、アーキテクチャ レベルで対処する必要がある新たな安全性の問題を引き起こします。
10.1 許可の境界
各エージェントの役割仕様 (R_t) は、エージェントがツールを合成できる範囲を定義します。監査エージェントはデータ抽出ツールを合成できますが、財務記録を変更するツールを合成することはできません。営業エージェントは CRM 統合ツールを合成できますが、HR データにアクセスするツールを合成することはできません。これらの境界は検証サンドボックスによって強制されます。エージェントの許可された範囲外のリソースにアクセスしようとする合成コードは、セキュリティ スキャン フェーズで拒否されます。
10.2 ロールバックメカニズム
すべてのツールの登録は元に戻すことができます。 OS は、ツールをアトミックに削除し、機能グラフを登録前の状態に戻すことを可能にするロールバック ログを維持します。ロールバックは、(a) 運用メトリクスが検証ベンチマークから乖離した場合の自動異常検出、(b) 人間によるオペレーターのレビュー、または (c) 登録されたツールが依存するツール自体がロールバックされる場合のカスケード依存関係の障害によってトリガーされます。
10.3 人間によるエスカレーション
エージェントのリスクしきい値を超えるツールは人間の承認にエスカレーションされます。エスカレーション リクエストには、機能ギャップの説明、合成されたツール仕様、実装コード、および完全な検証レポートが含まれます。人間は、承認 (ツールが登録される)、変更 (更新された制約でツールが再合成される)、または拒否 (ギャップは埋められないままになり、代替アプローチが検討される) することができます。
11. 比較: 従来型ツール チェーンと自己拡張型ツール チェーン
| Dimension | Traditional | Self-Extending |
|-----------|-------------|----------------|
| Tool creation time | Days to weeks | Minutes |
| Context fidelity | Low (ticket-mediated) | High (agent-direct) |
| Scaling model | Linear (1 engineer per tool) | Superlinear (sharing amplification) |
| 24/7 availability | No (business hours) | Yes (autonomous) |
| Validation rigor | Varies by team | Standardized (fail-closed sandbox) |
| Audit trail | Partial (tickets, PRs) | Complete (evidence log) |
| Rollback capability | Manual deployment | Atomic OS-level |
| Cross-agent reuse | Ad hoc | Protocol-driven sharing |
| Cost per tool | $2K-$15K engineering | ~$0.12 compute |
| Capability growth | Linear | Exponential (convergent) |特にコストの差は顕著です。従来のツール開発には、エンジニアの給与、コード レビュー、QA テスト、導入エンジニアリング、およびメンテナンスのオーバーヘッドが伴います。自己拡張ツールの合成にかかる費用は、LLM 推論、サンドボックス実行、および検証のためのコンピューティング リソースのみです。現在の API 価格では、合成ツールあたり約 0.12 ドルです。
12. 結論
独自のツールを作成するエージェントは、エージェント アーキテクチャに関する考え方の根本的な変化を表しています。このツールは、エージェントが動作する前にプロビジョニングする必要があるインフラストラクチャではなくなりました。これは、エージェントが運用ワークフローの自然な一部として生成する成果物です。 4 段階のアーキテクチャ (検出、合成、検証、登録) は、この自己拡張のための構造化された安全で監査可能なプロセスを提供します。エンジニアリング上の重要な洞察は、安全のためにエージェントのツール作成能力を制限する必要はないということです。作成されたすべてのツールが運用システムに影響を与える前に、厳格なフェールクローズ検証ゲートを確実に通過する必要があります。 MARIA OS 内では、このアーキテクチャはすでに運用されており、監査ユニバースのエージェントが毎日ツールを合成および共有し、人間のエンジニアリング チームができない速度で組織能力を構築しています。一致する可能性があります。
The Tool Discovery, Synthesis, Validation, and Registration APIs are available in MARIA OS v2.4+ under the Self-Extending Agent feature flag. The validation sandbox requires Node.js 22 and Docker for container isolation. See the ARIA-RD-01 technical reference for integration details.