コマンドレスAIアーキテクチャ — Goal駆動型Agentが事前定義なしに自律実行するOS設計
コマンドレジストリを排除し、Goal分解・Plan生成・動的Tool合成によるAgent自律実行を実現する
ARIA-RD-012026/3/830分で読めます概要. AIエージェント設計の支配的パラダイムはコマンド駆動実行である。エージェントは固定レジストリから明示的コマンドを受け取り、実行し、結果を返す。このアーキテクチャは本質的に脆弱である — エージェントはコマンドセットが予期したことしかできず、新しい要件が発生するたびにコマンドレジストリを拡張するエンジニアリング工数が必要となる。本論文はMARIA OSのコマンドレスアーキテクチャを紹介する。エージェントはコマンドではなくGoalを受け取る根本的に異なるアプローチである。Goalが与えられると、エージェントはそれを階層的Planに分解し、必要な能力を特定し、必要な能力と利用可能な能力のギャップを検出し、そのギャップを埋めるために新しいToolを動的に合成する。Goal空間G、Plan空間P、Tool空間Tの3つの数学的空間を通じてこのプロセスを形式化し、有界Goal領域のもとでTool空間が収束すること — 新しいTool合成の割合がエージェントの経験蓄積に伴って単調減少し、安定したToolエコシステムに近づくこと — を証明する。5つのエンタープライズ領域での実験評価により、コマンドレスAgentは新規タスクで3.2倍高い完遂率、要件変更への67%速い適応、そしてコマンド束縛型アーキテクチャと比較して100%の監査証跡カバレッジを達成することを実証する。
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生成：階層的タスク分解
Plan生成はGoalを実行可能な戦略に変換するプロセスである。コマンドレスアーキテクチャでは、Planは形式的構造、バージョン履歴、およびガバナンスメタデータを持つファーストクラスオブジェクトである。
3.1 Plan構造
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. 動的Tool生成
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
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 Goal空間 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 Plan空間 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 Tool空間 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空間は健全で効率的な状態を維持する。
関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law
関連記事: Action Router × Gate Engine Composition: Formal Theory of Responsibility-Aware Routing
関連記事: Metacognition in Agentic Companies: Why AI Systems Must Know What They Don't Know
関連記事: Collective Calibration Dynamics: How Agent Teams Achieve Shared Epistemic Accuracy in MARIA OS
関連記事: Action Router Intelligence Theory: Why Routing Must Control Actions, Not Classify Words
関連記事: Voice User Interface設計の認知科学的基盤: マルチモーダル対話における注意資源配分モデル
関連記事: Gated Meeting Intelligence: Fail-Closed Privacy Architecture for AI-Powered Meeting Transcription
関連記事: Real-Time Meeting Session Orchestration: State Machine Design for Multi-Component Bot Systems
関連記事: Robot Judgment OS Lab: Designing Responsibility-Bounded Physical-World AI with Multi-Universe Gates
関連記事: CEO Clone: From Judgment Extraction to Autonomous Governance Engine
関連記事: Company Intelligence: なぜMARIA OSはAIツールではなく、会社の知能をつくるOSなのか
関連記事: MARIA VITAL：Agent組織のための生命維持システム — Heartbeat監視から再帰的自己改善まで
関連記事: Tool Genesis Under Governance: How to Safely Turn Generated Code into New Commands
関連記事: Anomaly Detection for Agentic System Safety and Deviation Control
関連記事: Institutional Design for Agentic Societies: Meta-Governance Theory and AI Constitutional Frameworks
関連記事: Agent Tool Compiler: From Natural Language Intent to Executable Tool Code via Compilation Pipeline
関連記事: Audit Universe Runtime: Agent Design for Executing Audit Procedures as Runtime Operations
関連記事: Governance Load Testing: Where Does Governance Break in the 1000-Agent Era?
関連記事: Agentic Ethics Lab: Designing a Corporate Research Institute for Structural Ethics in AI Governance
関連記事: Investment Decision Lab: Designing Agentic R&D Teams for Multi-Universe Capital Allocation
関連記事: Doctor Architecture: Anomaly Detection as Enterprise Metacognition in MARIA OS
関連記事: Audit Universe Runtime：監査手続をランタイム・オペレーションとして実行するAgentアーキテクチャ
関連記事: Meta-Insight Under Distribution Shift: Change-Point Governance Loops for Enterprise Agentic Systems
関連記事: Agent Capability OS — Command Registry・Tool Registry・Capability Graphで能力を管理するOS設計
関連記事: Repeated Games and the Cofounder Problem: Why Startup Cooperation Depends on Shared Time Horizons
関連記事: The Complete Action Router: From Theory to Implementation to Scaling in MARIA OS
関連記事: Memory Stratification for AI Governance: A Rate-Distortion Framework for Retention Decisions
関連記事: Capability Gap Detection — Agentが自分の能力不足を認識するメタ認知アーキテクチャ
12. 結論
コマンドレスアーキテクチャは、AIエージェント設計の考え方における根本的な転換を表す。コマンドレジストリをGoal分解と動的Tool合成に置き換えることで、マシン速度で新しい要件に適応し、完全な監査証跡を維持し、人間のエンジニアリング工数なしに安定したToolエコシステムに収束するエージェントを実現する。MARIA OSの実装は、このアーキテクチャが単に理論的ではなく、実用的で、統制可能であり、エンタープライズAIワークロードに対してコマンド束縛型アプローチより測定可能に優れていることを実証する。重要な洞察は直感に反する：エージェントにより多くの自由（Toolを生成する能力）を与えることで、実際にはより統制しやすくなる。なぜなら、生成されたすべてのToolは、コマンドレジストリToolにはない来歴を持つからである。コマンドレスの世界では、問いは「エージェントはどのコマンドを持っているか？」から「エージェントはどのGoalを達成できるか？」へと移行する — そしてその答えは、我々が設定するガバナンス境界によってのみ制限される。