コマンドレス AI アーキテクチャ: 事前定義されたコマンドを使用せずに独自のツールを生成する目標主導型エージェント

1. コマンドパラダイムの問題

現在の主要なエージェント フレームワーク (LangChain、AutoGPT、CrewAI、Microsoft Autogen) はすべて、同じ基本的な前提に基づいて動作します。つまり、エージェントは、事前に定義された一連のコマンド (ツール、関数、API) から選択して動作します。エージェントの機能は、そのコマンド レジストリによって制限されます。レジストリに 50 のツールが含まれている場合、エージェントは 50 のことを実行できます。タスクに 51 番目の機能が必要な場合、エージェントは失敗するか、回避策を幻覚します。

この設計上の選択は、プログラムが既知のインターフェイスに対する関数呼び出しで構成される従来のソフトウェア アーキテクチャから直接継承されたものです。決定的で予測可能なワークロードに適しています。企業が実際にエージェントに実行させる必要がある種類の制限のない適応型タスクでは、壊滅的に失敗します。

1.1 新しい要件の下での脆性

サプライチェーンの物流を最適化する任務を負った計画エージェントを考えてみましょう。そのコマンド レジストリには、ルート計算、インベントリ クエリ、およびコスト見積もりの​​ためのツールが含まれています。新しい要件が生じます。エージェントはルートごとの炭素排出量を考慮する必要があります。コマンドバインドされたエージェントには炭素計算ツールがありません。続行できません。エンジニアはツールを実装し、登録し、テストし、再デプロイする必要があります。要件と機能の間の待ち時間は、数日または数週間で測定されます。

これは特別なケースではなく、エンタープライズ AI の通常の動作条件です。ビジネス要件は継続的に進化します。規制環境は変化します。市場の状況は変化します。新しい機能を追加するたびに人間工学的な労力を必要とするエージェント アーキテクチャは、サービスを提供するビジネスに追いつくことができないアーキテクチャです。

1.2 コマンドの組み合わせ爆発

たとえ必要な機能をすべて予測できたとしても、コマンド レジストリのアプローチは組み合わせの問題に直面します。現実世界のタスクには、個々のツールだけでなく、条件分岐を備えた特定のシーケンスでのツールの組み合わせも必要です。 N 個のツールのレジストリは、O(N!) 個の可能な実行順序を意味します。すべての有効な構成を事前に定義するのは困難です。エージェントは実行時にコンポジションを検出する必要があります。しかし、エージェントがコンポジションを検出できるのであれば、なぜツール自体を検出できないのでしょうか?

The insight at the heart of command-less architecture: if agents are already planning how to compose tools, they should also be able to plan how to create tools. Planning and tool generation are the same cognitive operation applied at different abstraction levels.

2. 目標主導型アーキテクチャ

コマンドレス アーキテクチャでは、コマンド実行ループが目標計画実行ループに置き換えられます。仕事の基本単位は命令ではなく目標です。目標は、オプションの制約、品質基準、説明責任メタデータを伴う、望ましい最終状態の宣言的仕様です。

アーキテクチャは 4 つのフェーズで動作します。

フェーズ 1 — 目標の受信。 エージェントは、人間のプリンシパル、別のエージェント、またはガバナンス トリガーから目標 G を受信します。目標には、自然言語による説明、利用可能な場合は正式な成功基準、制約の境界、および責任の割り当て (MARIA が調整して説明責任を負う) が含まれます。

フェーズ 2 — 分解。 エージェントは G をサブゴール {g_1, g_2, ..., g_m} の有向非巡回グラフ (DAG) に分解します。エッジは依存関係を表します。各サブゴールはその親の制約境界を継承しますが、分解プロセスから派生した追加の制約を持つ場合があります。

フェーズ 3 — 能力のマッチング。 リーフレベルのサブ目標 g_i ごとに、エージェントはその能力モデル C をクエリして、g_i を達成するために必要なツールを所有しているかどうかを判断します。ギャップが検出された場合 (必要な機能が利用可能な機能を超えている)、エージェントはツール合成フェーズに入ります。

フェーズ 4 — 実行。 エージェントは計画を実行し、トポロジ順に DAG を走査し、成功基準に照らして実行を監視し、実行結果が期待と異なる場合は計画を適応させます。

G \xrightarrow{\text{decompose}} \text{DAG}(g_1, g_2, \ldots, g_m) \xrightarrow{\text{match}} \Delta C \xrightarrow{\text{synthesize}} T' \xrightarrow{\text{execute}} R

コマンド駆動型アーキテクチャからの重大な逸脱は、フェーズ 3 とフェーズ 4 の間で発生します。エージェントは、必要な機能が不足していることを発見しても、失敗したりエスカレーションしたりせず、機能を生成します。これは、コマンドレス エージェントを以前のすべてのアーキテクチャと区別する自己拡張特性です。

3. 計画の生成: 階層型タスクの分解

計画の作成は、目標を実行可能な戦略に変換するプロセスです。コマンドレス アーキテクチャでは、プランは正式な構造、バージョン履歴、ガバナンス メタデータを備えたファーストクラスのオブジェクトです。

3.1 計画の構造

プラン P はタプル (N、E、pre、post、inv) です。N はタスク ノードのセット、E は依存関係エッジのセット、pre は各ノードを必要な状態にマッピングする事前条件関数、post は各ノードを期待される出力状態にマッピングする事後条件関数、inv は実行全体を通じて保持する必要があるプロパティを定義する不変関数です。

interface Plan {
  id: string
  goalId: string
  nodes: TaskNode[]
  edges: DependencyEdge[]
  preconditions: Map<string, Condition>
  postconditions: Map<string, Condition>
  invariants: Condition[]
  version: number
  generatedBy: MARIACoordinate
  auditTrail: PlanDecisionLog[]
}

interface TaskNode {
  id: string
  description: string
  requiredCapabilities: Capability[]
  estimatedCost: ResourceEstimate
  rollbackStrategy: RollbackPlan | null
  status: 'pending' | 'active' | 'completed' | 'failed' | 'rolled_back'
}

interface DependencyEdge {
  from: string  // TaskNode id
  to: string    // TaskNode id
  type: 'hard' | 'soft'  // hard = must complete; soft = preferred
  dataFlow?: DataContract   // schema of data passed between nodes
}

3.2 依存関係グラフの構築

分解アルゴリズムは、反復改良を通じて依存関係グラフを構築します。ルート目標から開始して、各サブ目標が他のサブ目標との依存関係について分析されます。依存関係は、ハード (後続が開始する前に完了する必要がある) またはソフト (優先される順序だが厳密には必須ではない) に分類されます。すべてのリーフ ノードが既知の機能またはツール合成をトリガーする機能ギャップにマップされると、アルゴリズムは終了します。

プラン ツリーの深さは、目標の複雑さに対して対数的に制限されます。目標の複雑さを定義します |G|完了するために必要な個別の機能タイプの数として。分解アルゴリズムは、各レベルで機能範囲を半分にすることにより、深さ O(log |G|) のツリーを生成します。これにより、必要な機能が数十ある複合目標であっても、管理しやすい計画構造が得られます。

\text{depth}(P) \leq \lceil \log_2 |G| \rceil + 1

3.3 計画の検証

実行前に、生成されたすべてのプランは検証ゲートを通過します。バリデーターは 3 つのプロパティをチェックします。(1) 完全性 — 必要なすべての機能が少なくとも 1 つのタスク ノードでカバーされています。 (2) 一貫性 — 2 つのタスク ノードが矛盾する事後条件を生成しないこと。 (3) 実現可能性 — リソースの見積もりは、割り当てられた予算を超えません。検証に失敗した計画は、診断情報とともに分解フェーズに戻されるため、反復的な改善が可能になります。

4. 動的なツールの生成

計画の生成で機能ギャップ (必要な機能がエージェントのツール インベントリに存在しないタスク ノード) が特定されると、エージェントはツール合成プロトコルに入ります。これはコマンドレス アーキテクチャの最も根本的な要素です。エージェントが必要なツールを作成します。

4.1 合成プロトコル

ツールの合成は 4 段階のプロトコルに従います。まず、エージェントは不足しているツールの仕様、つまり入力スキーマ、出力スキーマ、動作規約 (ツールが実行しなければならないこと)、および制約境界 (ツールが実行してはいけないこと) を形式化します。次に、エージェントはそのナレッジ ベースで類似ツール、つまり部分的な入力/出力署名や動作特性を共有する既存のツールを検索します。 3 番目に、エージェントは既存のツールを構成するか、類似ツールを適応させるか、仕様からコードを生成することによって、実装候補を生成します。第 4 に、候補者は行動契約に対する自動テストを受け、不合格となった候補者は拒否され、再生成されます。

interface ToolSynthesisRequest {
  requiredBy: TaskNode
  inputSchema: JSONSchema
  outputSchema: JSONSchema
  behavioralContract: {
    description: string
    testCases: TestCase[]
    constraints: string[]
  }
  analogousTools: Tool[]
  maxSynthesisAttempts: number
  governanceGate: GateConfig  // requires approval if risk > threshold
}

async function synthesizeTool(req: ToolSynthesisRequest): Promise<Tool> {
  for (let attempt = 0; attempt < req.maxSynthesisAttempts; attempt++) {
    const candidate = await generateCandidate(req)
    const testResults = await runBehavioralTests(candidate, req.behavioralContract)
    if (testResults.allPassed) {
      await registerTool(candidate, req.requiredBy)
      await logSynthesisDecision(candidate, req, testResults)
      return candidate
    }
    await logFailedAttempt(candidate, testResults, attempt)
  }
  throw new SynthesisFailure(req)  // escalate to human
}

4.2 合成に関するガバナンス制御

無制限にツールを生成することは危険です。任意のツールを作成できるエージェントは、セキュリティ ポリシーに違反したり、未承認のデータにアクセスしたり、元に戻せないアクションを実行したりするツールを作成できます。コマンドレス アーキテクチャは、階層化されたガバナンス制御を通じてこれに対処します。

合成されたすべてのツールには、その機能に基づいてリスク スコアが割り当てられます。データを読み取るツールはリスクが低く、データを読み取るツールはリスクが低くなります。データを書き込むツールは中リスクです。外部システムとやり取りしたり、金融取引を実行したりするツールはリスクが高くなります。高リスクのツールは登録前に人間の承認が必要です。リスク レベルに関係なく、すべての合成ツールは、その完全な仕様、生成の根拠、テスト結果、およびそれらを作成したエージェントの MARIA 座標とともにログに記録されます。

Tool synthesis without governance is capability generation without accountability. Every synthesized tool must pass through a Fail-Closed Gate that defaults to human review when risk cannot be assessed. The principle: more synthesis freedom requires more governance infrastructure.

5. 実行エンジン: 適応を伴う実行計画

実行エンジンは、プラン DAG をトポロジ順に走査し、割り当てられたツールを使用して各タスク ノードを実行し、結果を収集し、依存関係エッジで定義されたデータ コントラクトを介して依存ノードに出力を供給します。

5.1 ロールバックと再試行

タスク ノードが失敗すると、実行エンジンはノードのロールバック戦略を参照します。障害が一時的なもの (ネットワーク タイムアウト、レート制限) の場合、エンジンは指数バックオフで再試行します。障害が構造的なものである場合 (不適切なツール動作、無効な仮定)、エンジンは完了した依存ノードをロールバックし、再計画のためにサブプランを分解フェーズに戻します。ロールバックは制限されています。各ノードは、カスケードの元に戻す操作を防ぐために最大のロールバックの深さを指定します。

5.2 適応的な再計画

実行エンジンは、プランの実行全体にわたって不変条件を監視します。不変条件に違反した場合 (たとえば、累積コストが予算を超えた場合、または中間結果が予想範囲から逸脱した場合)、エンジンは実行を一時停止し、適応的な再計画をトリガーします。再計画フェーズでは、現在の実行状態、違反した不変条件、および残りの計画を受け取り、新しい情報を考慮した修正計画を作成します。これにより、適応がエージェントの自律性の範囲内であれば、エージェントは人間の介入なしに実行時の予期せぬ事態に適応することができます。

6. 数学的枠組み

3 つの数学的空間とそれらの間の射を介してコマンドレス アーキテクチャを形式化します。

6.1 ゴールスペースG

目標空間 G は、部分的に順序付けされたセット (ポーズセット) であり、順序関係は目標包含を表します: g_2 の達成が g_1 の達成を意味する場合、g_1 ≤ g_2。目標には複雑さの尺度があります |g|完了に必要な個別の機能タイプの最小数として定義されます。

(G, \leq) \text{ where } g_1 \leq g_2 \iff \text{achieving } g_2 \text{ implies achieving } g_1

6.2 スペース P の計画

計画空間 P は、タスク ノード上のすべての有効な DAG のセットです。プラン p は、それが非巡回であり、すべてのリーフ ノードが現在のツール スペース内の機能または合成リクエストにマップされ、すべての事前条件と事後条件のチェーンが一貫している場合にのみ有効です。

P = \{ p = (N, E) \mid \text{acyclic}(p) \wedge \forall n \in \text{leaves}(p): \text{cap}(n) \subseteq C \cup S \}

6.3 ツールスペース T

ツールスペースＴは、合成操作を備えたセットである。 t_1 の出力スキーマが t_2 の入力スキーマと互換性がある場合、2 つのツール t_1、t_2 を構成できます (t_1 ; t_2)。初期ツール空間 T_0 は、エージェントの事前ロードされたツール インベントリです。各計画サイクルで、ツール合成により新しい要素が T に追加され、T_{k+1} = T_k ∪ synth(k) が生成されます。

T_{k+1} = T_k \cup \text{synth}(\Delta C_k), \quad |\text{synth}(\Delta C_k)| \leq |\Delta C_k|

6.4 射影

分解関数 δ: G → P は、目標を計画にマッピングします。能力マッチング関数 μ: P → 2^C は、計画を必要な能力セットにマッピングします。合成関数 σ: 2^C \ C → T は、機能のギャップを新しいツールにマッピングします。 δ、μ、σ の構成により、目標からツールまでの完全なパイプラインが定義されます。

\delta: G \to P, \quad \mu: P \to 2^C, \quad \sigma: 2^C \setminus C \to T

重要な定理は、これらの射は構成可能であり、その構成によりガバナンスの不変量が保存されるということです。つまり、σ ∘ μ ∘ δ の画像内のすべてのツールは、元の目的に戻る完全な来歴チェーンを保持します。

7. MARIA OS におけるコマンドレス OS 設計

MARIA OS は、従来のコマンド レジストリを置き換える 3 つのアーキテクチャ上の決定を通じて、コマンドレス アーキテクチャを実装します。

7.1 コマンド レジストリを機能グラフで置き換える

MARIA OS は、登録されたコマンドのフラット リストの代わりに、機能グラフ (ノードが機能であり、エッジが構成関係、類似関係、派生関係を表す有向グラフ) を維持します。エージェントが機能を必要とする場合、正確なコマンド名ではなく、最も近い一致をグラフに照会します。これにより、あいまいマッチングが可能になります。「炭素排出量の計算」を必要とするエージェントは、近くの機能として「エネルギーコストの推定」を見つけて、それを適応させる可能性があります。

7.2 API仕様を目標コントラクトに置き換える

従来のアーキテクチャでは、エージェント間の通信は API 仕様 (送信者と受信者の両方が準拠する必要がある固定スキーマ) によって仲介されます。 MARIA OS では、エージェントは目標コントラクトを通じて通信します。これは、送信者が受信者に達成してもらいたいことを成功基準とともに宣言するものです。受信者は、新しいツールの合成など、利用可能なあらゆる手段を通じて自由に目標を達成できます。

7.3 証拠に基づいたツールのプロモーション

動的に合成されたツールは、使用が制限された「暫定」状態で開始されます。ツールは正しい動作の証拠 (実行の成功、テストの合格、ガバナンス レビュー) を蓄積するため、暫定→検証済み→信頼済み→コアという成熟度レベルを通じて昇格されます。コアツールは、プリロードされたツールと区別がつきません。これにより、品質基準を維持しながらツール スペースを有機的に拡張できます。

type ToolMaturity = 'provisional' | 'validated' | 'trusted' | 'core'

interface ToolPromotionCriteria {
  provisional_to_validated: {
    minSuccessfulExecutions: 10
    minDistinctContexts: 3
    maxFailureRate: 0.05
  }
  validated_to_trusted: {
    minSuccessfulExecutions: 100
    humanReviewPassed: true
    securityAuditPassed: true
  }
  trusted_to_core: {
    minSuccessfulExecutions: 1000
    minAge: '30d'
    governanceBoardApproval: true
  }
}

8. 比較: コマンドベースのエージェントと目標ベースのエージェント

| Dimension | Command-Based Agent | Goal-Based Agent (MARIA OS) |
|---|---|---|
| Capability Boundary | Fixed at deployment | Expands at runtime |
| Novel Task Handling | Fails or hallucinates | Decomposes, synthesizes, executes |
| Adaptation Latency | Days (requires engineering) | Minutes (autonomous synthesis) |
| Composition Discovery | Pre-defined workflows | Runtime plan generation |
| Audit Trail | Command execution logs | Goal → Plan → Tool → Execution traces |
| Governance Model | Permission per command | Risk-scored synthesis gates |
| Scalability | Linear in command count | Logarithmic in goal complexity |
| Inter-Agent Communication | API calls | Goal contracts |
| Failure Mode | Silent inability | Explicit gap detection + escalation |
| Tool Ecosystem Growth | Manual addition | Organic + evidence-based promotion |

9. 再帰的計画: ツールを生成する計画を生成する計画

コマンドレス アーキテクチャの最も強力な特性は、再帰的な計画です。プランには、サブプランを生成することを目的とするタスク ノードを含めることができます。サブプランには、ツールを合成することを目的とするタスク ノードを含めることができます。これにより、3 レベルの再帰 (目標から計画、サブ計画、ツールへ) が作成され、コマンド中心のアーキテクチャでは不可能な緊急の問題解決機能が可能になります。

9.1 再帰による創発

新しい市場への参入を任務とする戦略計画エージェントを考えてみましょう。最上位の計画は、市場分析、競合評価、規制レビュー、市場開拓戦略に分かれています。市場分析のサブ目標は独自の計画を生成し、ターゲット市場の言語でソーシャル メディアのセンチメントを分析するツールが必要であることを発見します。エージェントは、特定の言語コンテキストに適応した感情分析ツールを合成します。このツールは元のレジストリにありませんでした。エンジニアは誰もその必要性を予想していませんでした。エージェントの再帰的計画能力により、創発的な能力が生み出されました。

\text{RecPlan}(G) = \delta(G) \cup \bigcup_{g_i \in \text{leaves}(\delta(G))} \text{RecPlan}(g_i)

9.2 再帰限界

無制限の再帰は、無制限のツール生成と同じくらい危険です。このアーキテクチャでは、プラン分解の深さ (タスクが直接実行可能になるまでの DAG の最大深さ) と合成の深さ (ツール合成チェーン内のツール合成チェーンの最大数) の 2 つのレベルで再帰の深さ制限が適用されます。デフォルトの制限は、プラン分解の場合は 5、合成の深さの場合は 2 です。これらの制限は、信頼レベルとガバナンス層に基づいてエージェントごとに調整できます。

10. 証拠の軌跡: コマンドのない世界におけるガバナンス

コマンドレス アーキテクチャに対する一般的な反対意見は、それが管理不可能であるというものです。エージェントが任意のツールを生成できる場合、エージェントの動作をどのように監査すればよいでしょうか。 MARIA OS の答えは、すべてのツールにはその完全な起源があるため、コマンドレス アーキテクチャのほうが実際にはコマンド ベースのアーキテクチャよりも管理しやすいということです。

コマンドベースのアーキテクチャでは、監査証跡は次のようになります。「エージェント X はパラメータ Z を使用してコマンド Y を実行しました。」これにより、何が起こったのかがわかりますが、理由はわかりません。コマンドレス アーキテクチャでは、監査証跡は次のようになります。「エージェント X は目標 G を受け取り、それをプラン P に分解し、能力ギャップ ΔC を検出し、ギャップを埋めるためにツール T を合成し、行動契約 B に対して T をテストし、プラン P 内で T を実行しました。」これにより、ガバナンスが何を、なぜ、どのように、どのように制御するのかがわかります。

interface CommandlessAuditRecord {
  goalId: string
  goalDescription: string
  planId: string
  planVersion: number
  taskNodeId: string
  capabilityGap: Capability[] | null
  synthesizedTool: {
    toolId: string
    specification: ToolSpec
    testResults: TestResult[]
    riskScore: number
    approvalStatus: 'auto' | 'human_approved'
  } | null
  executionResult: {
    status: 'success' | 'failure' | 'rolled_back'
    outputs: Record<string, unknown>
    duration: number
    resourcesConsumed: ResourceMetrics
  }
  responsibleCoordinate: string  // MARIA coordinate
  timestamp: string
}

すべての監査記録は元の目標にリンクし、ビジネス上の意図から技術的な実行までの切れ目のないチェーンを作成します。この連鎖は、コマンドレス システムにおける説明責任の基礎です。責任は目標から計画、ツール、実行へと流れ、すべてのリンクで MARIA 座標によって誰が移行を承認したかが特定されます。

11. コンバージェンス: 目標主導型エージェントはツールスペースを安定させる

動的なツールの生成に関する当然の懸念は、暴走する成長です。ツールの領域は際限なく拡大するのでしょうか?合理的な仮定の下では、ツール空間が収束することを証明します。

定理 (ツール空間収束) G を有限能力要件 |C_req| を持つ有界目標領域とする。 T_k を k 計画サイクル後のツール空間とします。この場合、すべての k > K について |T_{k+1} \ T_k| となるような K が存在します。 = 0。つまり、工具空間が安定します。

\text{Let } C_{\text{req}} = \bigcup_{g \in G} \text{required}(g). \text{ Since } |C_{\text{req}}| < \infty \text{ and each synthesis adds at least one element of } C_{\text{req}} \text{ to } T, \text{ after at most } |C_{\text{req}}| \text{ cycles, } C_{\text{req}} \subseteq T.

証明スケッチ。 有界目標領域 G に必要な機能セット C_req は有限です。機能ギャップに遭遇した各計画サイクルでは、C_req \ T_k の少なくとも 1 つの要素をカバーする少なくとも 1 つのツールが合成されます。 C_req は有限であり、各サイクルでギャップが少なくとも 1 要素ずつ減少するため、最大でも |C_req| の後はギャップが減少します。サイクルすると、ギャップは空になります。その時点以降、G の新しい目標はツール合成を必要としないため、T は安定します。

収束率は、遭遇する目標の多様性によって異なります。新規性が低い順に目標が到達すると (最も新規性が高いものから)、収束が最も速くなります。ゴールが G から一様にランダムに到着する場合、期待される収束時間は、期待値 |C_req| のクーポン コレクター分布に従います。 · H(|C_req|)、H は高調波数です。

E[K] = |C_{\text{req}}| \cdot H_{|C_{\text{req}}|} = |C_{\text{req}}| \sum_{i=1}^{|C_{\text{req}}|} \frac{1}{i} = O(|C_{\text{req}}| \log |C_{\text{req}}|})

11.1 収束後のダイナミクス

収束後、ツール空間は静的になりません。ツールは使用状況のフィードバックを通じて改良され続けます。故障率の高いツールは再生成され、重複する機能を持つツールは統合され、長期間使用されなかったツールは廃止されます。このコンバージェンス後のメンテナンスにより、時間の経過とともに目標の分布が変化しても、ツール スペースが健全かつ効率的に維持されることが保証されます。

したがって、コマンドレス アーキテクチャは、驚くべき特性を達成します。つまり、事前定義されたコマンドがない状態で開始され、目標駆動合成を通じてツール空間が有機的に拡大し、安定した適切に管理されたツール エコシステム、つまり設計者が予想した目標ではなく、エージェントが実際に遭遇する目標に正確に適応するエコシステムに収束します。

12. 結論

コマンドレス アーキテクチャは、AI エージェントの設計に関する考え方の根本的な変化を表しています。コマンド レジストリを目標分解と動的なツール合成に置き換えることにより、エージェントがマシンの速度で新しい要件に適応し、完全な監査証跡を維持し、人的エンジニアリングの労力を必要とせずに安定したツール エコシステムに収束できるようになります。 MARIA OS の実装は、このアーキテクチャが単なる理論的なものではなく、実際的で管理可能であり、エンタープライズ AI ワークロードに対するコマンド バウンドのアプローチよりも明らかに優れていることを示しています。重要な洞察は直観に反するものです。エージェントにより自由度 (ツールを生成する能力) を与えると、実際には管理しやすくなります。生成されたすべてのツールには、コマンド レジストリ ツールにはない出所があるからです。コマンドのない世界では、質問は「エージェントがどのようなコマンドを持っているか?」から変わります。 「エージェントはどのような目標を達成できるのか」成し遂げる？' — そしてその答えは、私たちが設定することを選択したガバナンスの境界によってのみ制限されます。