コマンドレスAIアーキテクチャ — Goal駆動型Agentが事前定義なしに自律実行するOS設計

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

今日の主要なエージェントフレームワーク — LangChain、AutoGPT、CrewAI、Microsoft Autogen — はすべて同じ根本的前提で動作する。エージェントは事前定義されたコマンドセット（ツール、関数、API）から選択して行動する。エージェントの能力はコマンドレジストリによって制約される。レジストリに50のツールがあれば、エージェントは50のことができる。タスクが51番目の能力を必要とする場合、エージェントは失敗するか、回避策を幻覚する。

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

1.1 新規要件に対する脆弱性

サプライチェーンロジスティクスの最適化を任された計画エージェントを考えよう。そのコマンドレジストリにはルート計算、在庫照会、コスト推定のツールが含まれている。新しい要件が発生する — エージェントはルートごとの炭素排出量を考慮しなければならない。コマンド束縛型エージェントには炭素計算ツールがない。続行できない。エンジニアがツールを実装し、登録し、テストし、再デプロイしなければならない。要件と能力の間のレイテンシは数日から数週間で測定される。

これはエッジケースではなく、エンタープライズAIの通常の動作条件である。ビジネス要件は継続的に進化する。規制環境は変化する。市場状況は変わる。新しい能力ごとに人間のエンジニアリング工数を必要とするエージェントアーキテクチャは、それが奉仕するビジネスのペースについていけないアーキテクチャである。

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

あらゆる必要な能力を予期できたとしても、コマンドレジストリアプローチは組み合わせ問題に直面する。実世界のタスクは個々のツールだけでなく、条件分岐を伴う特定の順序でのツールの合成を必要とする。Nツールのレジストリはo(N!)の可能な実行順序を意味する。すべての有効な合成を事前定義することは計算困難である。エージェントは実行時に合成を発見しなければならない — しかし合成を発見できるなら、ツール自体も発見できるのではないか？

コマンドレスアーキテクチャの核心にある洞察：エージェントがすでにツールの合成方法を計画しているなら、ツールの作成方法も計画できるはずである。計画とツール生成は、異なる抽象度で適用される同一の認知操作である。

2. Goal駆動アーキテクチャ

コマンドレスアーキテクチャは、コマンド実行ループをGoal-Plan-Executeループに置き換える。作業の基本単位はコマンドではなくGoalである。Goalは望ましい最終状態の宣言的仕様であり、オプションの制約条件、品質基準、および責任メタデータを含む。

アーキテクチャは4つのフェーズで動作する：

フェーズ1 — Goal受信. エージェントは人間の主体、別のエージェント、またはガバナンストリガーからGoal Gを受け取る。Goalには自然言語での説明、利用可能な場合の形式的成功基準、制約境界、および責任割当（どのMARIA座標が説明責任を負うか）が含まれる。

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

フェーズ3 — 能力マッチング. 各リーフレベルのサブゴールg_iについて、エージェントはその能力モデルCに問い合わせ、g_iを達成するために必要なツールを保有しているかを判定する。ギャップが検出された場合（必要な能力が利用可能な能力を超える場合）、エージェントはTool合成フェーズに入る。

フェーズ4 — 実行. エージェントはPlanを実行し、DAGをトポロジカル順序で走査し、成功基準に対する実行を監視し、実行結果が期待から逸脱した場合にPlanを適応させる。

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の間で発生する。エージェントが必要な能力の欠如を発見したとき、失敗やエスカレーションではなく、能力を生成する。これが、コマンドレスAgentを先行するすべてのアーキテクチャから区別する自己拡張特性である。

3. 計画の生成: 階層分解

Plan生成はGoalを実行可能な戦略に変換するプロセスである。コマンドレスアーキテクチャでは、Planは形式的構造、バージョン履歴、およびガバナンスメタデータを持つファーストクラスオブジェクトである。

3.1 計画の構造

Plan 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'
}

3.2 依存関係グラフの構築

分解アルゴリズムは反復的精緻化を通じて依存関係グラフを構築する。ルートGoalから出発し、各サブゴールは他のサブゴールへの依存関係について分析される。依存関係はハード（後続の開始前に完了する必要がある）またはソフト（望ましい順序だが厳密には不要）に分類される。アルゴリズムは、すべてのリーフノードが既知の能力またはTool合成をトリガーする能力ギャップにマッピングされた時点で終了する。

Planツリーの深度はGoalの複雑度の対数で制約される。Goal複雑度|G|を完了に必要な異なる能力タイプの数と定義する。分解アルゴリズムは各レベルで能力スコープを半分にすることで、深度O(log |G|)のツリーを生成する。

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

3.3 Planバリデーション

実行前に、生成されたすべてのPlanはバリデーションゲートを通過する。バリデータは3つの性質を検証する：(1) 完全性 — 必要なすべての能力が少なくとも1つのタスクノードでカバーされている。(2) 整合性 — 矛盾する事後条件を生成するタスクノードが存在しない。(3) 実現可能性 — リソース推定が割り当てられた予算を超えない。バリデーションに失敗したPlanは診断情報とともに分解フェーズに返され、反復的精緻化が可能になる。

4. 動的ツールの生成

Plan生成が能力ギャップ — 必要な能力がエージェントのToolインベントリに存在しないタスクノード — を特定した場合、エージェントはTool合成プロトコルに入る。これがコマンドレスアーキテクチャの最も急進的な要素である：エージェントは必要なToolを自ら作成する。

4.1 合成プロトコル

Tool合成は4段階のプロトコルに従う。第一に、エージェントは欠落しているToolの仕様を形式化する：入力スキーマ、出力スキーマ、行動契約（Toolが何をすべきか）、制約境界（Toolが何をしてはならないか）。第二に、エージェントは類似ツール — 部分的な入出力シグネチャや行動特性を共有する既存ツール — をナレッジベースから検索する。第三に、既存ツールの合成、類似ツールの適応、または仕様からのコード生成により候補実装を生成する。第四に、候補は行動契約に対する自動テストを受け、失敗した候補は拒否され再生成される。

interface ToolSynthesisRequest {
  requiredBy: TaskNode
  inputSchema: JSONSchema
  outputSchema: JSONSchema
  behavioralContract: {
    description: string
    testCases: TestCase[]
    constraints: string[]
  }
  analogousTools: Tool[]
  maxSynthesisAttempts: number
  governanceGate: GateConfig  // リスクが閾値を超える場合は承認が必要
}

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)  // 人間にエスカレーション
}

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

無制限のTool生成は危険である。任意のToolを作成できるエージェントは、セキュリティポリシーに違反するTool、権限のないデータにアクセスするTool、不可逆的なアクションを実行するToolを作成できる。コマンドレスアーキテクチャは、階層化されたガバナンス制御を通じてこれに対処する。

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

ガバナンスなきTool合成は、説明責任なき能力生成である。合成されたすべてのToolは、リスクが評価できない場合に人間のレビューをデフォルトとするFail-Closedゲートを通過しなければならない。原則：合成の自由度が増すほど、より多くのガバナンスインフラが必要になる。

5. 実行エンジン：適応を伴うPlan実行

実行エンジンはPlan DAGをトポロジカル順序で走査し、各タスクノードを割り当てられたToolで実行し、結果を収集し、依存関係エッジで定義されたデータ契約を介して後続ノードに出力を供給する。

5.1 ロールバックとリトライ

タスクノードが失敗した場合、実行エンジンはノードのロールバック戦略を参照する。障害が一時的（ネットワークタイムアウト、レート制限）の場合、エンジンは指数バックオフでリトライする。障害が構造的（不正なTool動作、無効な仮定）の場合、エンジンは完了済みの依存ノードをロールバックし、サブPlanを再計画のために分解フェーズに返す。ロールバックは制限される：各ノードはカスケードする取り消し操作を防ぐための最大ロールバック深度を指定する。

5.2 適応的再計画

実行エンジンはPlan実行中を通じて不変条件を監視する。不変条件が違反された場合 — 例えば、累積コストが予算を超過した、中間結果が期待範囲から逸脱した — エンジンは実行を一時停止し、適応的再計画をトリガーする。再計画フェーズは現在の実行状態、違反された不変条件、および残りのPlanを受け取り、新しい情報を考慮した修正Planを生成する。

6. 数学的フレームワーク

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

6.1 ゴールスペース G

Goal空間Gは半順序集合（poset）であり、順序関係はGoal包摂を表す。g_1 ≤ g_2はg_2の達成がg_1の達成を含意する場合に成立する。Goalは複雑度測度|g|を持ち、完了に必要な異なる能力タイプの最小数として定義される。

(G, \leq) \text{ where } g_1 \leq g_2 \iff g_2\text{の達成が}g_1\text{の達成を含意する}

6.2 計画空間 P

Plan空間Pはタスクノード上のすべての有効なDAGの集合である。Plan pは以下の場合にのみ有効である：非巡回であること、すべてのリーフノードが現在のTool空間内の能力または合成要求にマッピングされること、すべての前提条件-事後条件チェーンが整合的であること。

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

Tool空間Tは合成演算を備えた集合である。2つのTool t_1, t_2はt_1の出力スキーマがt_2の入力スキーマと互換性がある場合に合成可能(t_1 ; t_2)である。初期Tool空間T_0はエージェントのプリロードされたToolインベントリである。各計画サイクルでTool合成が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はGoalをPlanに写像する。能力マッチング関数μ: P → 2^CはPlanを必要な能力集合に写像する。合成関数σ: 2^C \ C → Tは能力ギャップを新しいToolに写像する。δ、μ、σの合成がGoalからToolへの完全なパイプラインを定義する。

\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 Goal契約がAPI仕様を置き換える

従来のアーキテクチャでは、エージェント間通信はAPI仕様 — 送信者と受信者の両方が適合しなければならない固定スキーマ — によって仲介される。MARIA OSでは、エージェントはGoal契約を通じて通信する：送信者が受信者に達成してほしいことの宣言的記述と成功基準である。受信者は新しいToolの合成を含む利用可能な任意の手段でGoalを達成する自由がある。

7.3 エビデンスベースのTool昇格

動的に合成されたToolは使用制限付きの「暫定」状態で開始する。Toolが正しい動作のエビデンスを蓄積するにつれて — 成功した実行、合格したテスト、ガバナンスレビュー — 成熟度レベルを昇格する：暫定→検証済み→信頼済み→コア。コアToolはプリロードされたToolと区別がつかない。

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. 比較：コマンドベース vs. Goalベース Agent

| 次元 | コマンドベースAgent | GoalベースAgent (MARIA OS) |
|---|---|---|
| 能力境界 | デプロイ時に固定 | 実行時に拡張 |
| 新規タスク対応 | 失敗または幻覚 | 分解・合成・実行 |
| 適応レイテンシ | 数日（エンジニアリング必要） | 数分（自律合成） |
| 合成発見 | 事前定義ワークフロー | 実行時Plan生成 |
| 監査証跡 | コマンド実行ログ | Goal→Plan→Tool→実行トレース |
| ガバナンスモデル | コマンドごとの権限 | リスクスコア付き合成ゲート |
| スケーラビリティ | コマンド数に対して線形 | Goal複雑度に対して対数的 |
| エージェント間通信 | API呼び出し | Goal契約 |
| 失敗モード | サイレントな不能 | 明示的ギャップ検出+エスカレーション |
| Toolエコシステム成長 | 手動追加 | 有機的+エビデンスベース昇格 |

9. 再帰的計画：PlanがPlanを生成しToolを生成する

コマンドレスアーキテクチャの最も強力な特性は再帰的計画である。Planはサブplanの生成を目的とするタスクノードを含むことができる。サブplanはToolの合成を目的とするタスクノードを含むことができる。これにより、GoalからPlanへ、サブplanへ、Toolへの3レベルの再帰が生まれ、コマンド束縛型アーキテクチャでは不可能な創発的問題解決能力が実現する。

9.1 再帰を通じた創発

新市場参入を任された戦略計画エージェントを考えよう。トップレベルのPlanは市場分析、競合評価、規制レビュー、Go-To-Market戦略に分解される。市場分析のサブゴールは独自のPlanを生成し、ターゲット市場の言語でのソーシャルメディア感情分析ツールが必要であることを発見する。エージェントは特定の言語コンテキストに適応した感情分析ツールを合成する。このToolは元のレジストリにはなかった。エンジニアは必要性を予期していなかった。エージェントの再帰的計画能力が創発的コンピテンスを生み出した。

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

9.2 再帰の制限

無制限の再帰は無制限のTool生成と同様に危険である。アーキテクチャは2つのレベルで再帰深度制限を強制する：Plan分解深度（タスクが直接実行可能でなければならない最大DAG深度）と合成深度（Tool合成内のTool合成チェーンの最大数）。デフォルト制限はPlan分解が5、合成深度が2である。

10. 監査証跡：コマンドレス世界でのガバナンス

コマンドレスアーキテクチャに対する一般的な反論は、それが統制不能であるということである。エージェントが任意のToolを生成できるなら、何をしているかをどう監査するのか？ MARIA OSの答えは、コマンドレスアーキテクチャは実際にはコマンドベースアーキテクチャよりも統制しやすいということである。なぜなら、すべてのToolがその完全な来歴を持つからである。

コマンドベースアーキテクチャでは監査証跡は「Agent XがパラメータZでコマンドYを実行した」である。何が起こったかはわかるが、なぜかはわからない。コマンドレスアーキテクチャでは監査証跡は「Agent XがGoal Gを受け取り、Plan Pに分解し、能力ギャップΔCを検出し、ギャップを埋めるためにTool Tを合成し、行動契約Bに対してTをテストし、Plan P内でTを実行した」である。何を、なぜ、どのように、どのガバナンス制御のもとで行ったかがわかる。

すべての監査レコードは起点となるGoalにリンクし、ビジネス意図から技術的実行までの途切れないチェーンを作成する。このチェーンがコマンドレスシステムにおける説明責任の基盤である。

11. 収束：Goal駆動型AgentはTool空間を安定化させる

動的Tool生成に対する自然な懸念は際限ない成長である。Tool空間は無制限に拡大するのか？ 合理的な仮定のもとでTool空間が収束することを証明する。

定理（Tool空間収束）. Gを有限の能力要件|C_req|を持つ有界Goal領域とする。T_kをk回の計画サイクル後のTool空間とする。このとき、すべてのk > Kに対して|T_{k+1} \ T_k| = 0となるKが存在する。すなわち、Tool空間は安定化する。

C_{\text{req}} = \bigcup_{g \in G} \text{required}(g), \quad |C_{\text{req}}| < \infty \implies \exists K: \forall k > K, \; T_{k+1} = T_k

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

収束率は遭遇するGoalの多様性に依存する。Goalが新規性の降順（最も新しいものから）で到着する場合、収束は最速である。GoalがGから一様ランダムに到着する場合、期待収束時間は期待値|C_req| · H(|C_req|)のクーポンコレクター分布に従う。

E[K] = |C_{\text{req}}| \cdot H_{|C_{\text{req}}|} = O(|C_{\text{req}}| \log |C_{\text{req}}|)

11.1 収束後のダイナミクス

収束後、Tool空間は静的にはならない。Toolは使用フィードバックを通じて継続的に精緻化される：高い失敗率のToolは再生成され、重複する能力を持つToolは統合され、長期間使用されていないToolは非推奨となる。この収束後のメンテナンスにより、Goal分布が時間の経過とともにシフトしても、Tool空間は健全で効率的な状態を維持する。

12. 結論

コマンドレスアーキテクチャは、AIエージェント設計の考え方における根本的な転換を表す。コマンドレジストリをGoal分解と動的Tool合成に置き換えることで、マシン速度で新しい要件に適応し、完全な監査証跡を維持し、人間のエンジニアリング工数なしに安定したToolエコシステムに収束するエージェントを実現する。MARIA OSの実装は、このアーキテクチャが単に理論的ではなく、実用的で、統制可能であり、エンタープライズAIワークロードに対してコマンド束縛型アプローチより測定可能に優れていることを実証する。重要な洞察は直感に反する：エージェントにより多くの自由（Toolを生成する能力）を与えることで、実際にはより統制しやすくなる。なぜなら、生成されたすべてのToolは、コマンドレジストリToolにはない来歴を持つからである。コマンドレスの世界では、問いは「エージェントはどのコマンドを持っているか？」から「エージェントはどのGoalを達成できるか？」へと移行する — そしてその答えは、我々が設定するガバナンス境界によってのみ制限される。