エージェント機能 OS: 自己拡張エージェント アーキテクチャの 3 つの柱としてのコマンド レジストリ、ツール レジストリ、および機能グラフ

1. はじめに: 機能に OS が必要な理由

Web 検索ツール、データベース クエリ ツール、およびテキスト要約スキルを備えた単一のソフトウェア エージェントを考えてみましょう。このエージェントは、自分自身の機能を簡単に管理できます。つまり、自分に何ができるかを理解し、各ツールの制約を理解し、外部調整なしでタスクの実行を計画できます。ここで、監査事務所に 54 人のエージェントがおり、各エージェントが 3 ～ 12 個のツールを備えており、財務分析、規制遵守、証拠収集、レポート作成、クライアントとのコミュニケーション、および内部ワークフロー管理を一括してカバーしているとします。合計の機能面は 200 の個別のツールと 400 の複合スキルを超えています。この機能ランドスケープの完全なモデルを保持できるエージェントは 1 人もいません。

これは新しい観察ではありません。分散システムは常に調整の課題に直面しています。エージェント機能管理が従来のサービス ディスカバリやマイクロサービス オーケストレーションと根本的に異なるのは、エージェント機能の セマンティックな豊富さです。マイクロサービスは、型指定された入力と出力を備えた固定 API を公開します。エージェントの機能は状況に応じて構成可能であり、進化します。エージェントが「財務諸表を分析」できるかどうかは、どのツールにアクセスできるか、どのデータ ソースが利用できるか、どのような規制枠組みが適用されるか、および他のエージェントがすでに処理した内容によって決まります。機能は静的なエンドポイントではありません。これらは動的でコンテキストに依存する機能であり、組織環境の変化に応じて変化します。

マルチエージェント調整に対する従来のアプローチ (ブラックボード アーキテクチャ、契約ネット プロトコル、市場ベースのタスク割り当て) は、機能を原子ラベルとして扱います。エージェント A はタスク X を「実行できる」。機能に内部構造 (バージョン、依存関係、互換性制約、構成ルール、ライフサイクル状態) がある場合、このバイナリ フレームワークは正確に崩壊します。エージェントが使用している規制遵守ツールのバージョン 2.3 は、別のエージェントが使用している証拠収集ツールのバージョン 1.x と互換性がない可能性があります。これを捕捉するバイナリ ラベルはありません。

私たちは、必要なのはエージェント機能のためのオペレーティング システムであると主張します。これは、従来の OS がアプリケーション全体のプロセス、メモリ、および I/O を管理するのと同じように、エージェント集団全体の機能のライフサイクル全体を管理するシステム レベルの抽象化です。エージェント機能 OS はエージェントの自律性に取って代わるものではありません。これは、エージェントが調整の混乱に陥ることなく機能を発見、要求、構成、拡張できるインフラストラクチャを提供します。

2. 3 つのレジストリ: アーキテクチャの概要

Agent Capability OS は、連動する 3 つのレジストリを中心に構造化されており、それぞれが機能管理問題の個別の層に対応します。

// Capability OS Architecture
interface CapabilityOS {
  commandRegistry: CommandRegistry    // Layer 1: What commands exist
  toolRegistry: ToolRegistry          // Layer 2: What tools implement them
  capabilityGraph: CapabilityGraph    // Layer 3: How capabilities compose

  // Core operations
  discover(query: CapabilityQuery): CapabilityMatch[]
  allocate(agentId: string, capabilityId: string): AllocationResult
  compose(capabilities: string[]): CompositeCapability | null
  extend(base: string, extension: CapabilityExtension): string
}

コマンド レジストリはインターフェイス層です。これは、高レベルのコマンド名 (「analyze-financial-statement」、「generate-audit-report」など) を実行可能な機能チェーンにマップします。コマンド解決を処理します。複数のエージェントまたはツールが同じコマンドを実行できる場合、レジストリは優先順位、ルーティング、競合解決を決定します。コマンド レジストリはシェルの PATH 解決に似ていますが、意味論的な認識を持っています。つまり、「analyze-financial-statement」と「financial-statement-analysis」が同じ機能を参照し、それに応じてルートを参照していることを理解します。

ツール レジストリは実装層です。組織内で利用可能なすべてのツールに関するメタデータ (バージョン、作成者、入出力スキーマ、リソース要件、互換性制約、依存関係チェーンなど) が保存されます。ツール レジストリはパッケージ マネージャー (npm、pip) に似ていますが、ビルド時ではなく実行時に動作します。エージェントはツール レジストリにクエリを実行して、どのツールが機能要件を満たすことができるかを検出します。レジストリは、互換性と可用性によってフィルタリングされたランク付けされた結果を返します。

能力グラフ は構成レイヤーです。これは、エージェントの機能の全空間を有向非循環グラフとしてモデル化します。ノードは機能、エッジは構成関係を表します (たとえば、「財務監査」は「声明分析」+「規制チェック」+「証拠収集」を構成します)。ケイパビリティ グラフを使用すると、OS は「利用可能なエージェントを任意に組み合わせてこの複雑なタスクを実行できるか?」などの質問に答えることができます。 「組織を新しい領域に拡張するために必要な最小限の機能セットは何ですか?」

3. コマンド レジストリ: 動的解決と競合処理

コマンド レジストリは、コマンド識別子から実行可能な機能チェーンへのマッピングを維持します。静的な構成ファイルとは異なり、レジストリは動的です。エージェントは、コマンドがオンラインになったり、オフラインになったり、新しい機能を取得したりするときに、実行時にコマンドを登録および登録解除します。

interface CommandRegistryEntry {
  commandId: string                    // Canonical command identifier
  aliases: string[]                    // Semantic aliases
  provider: AgentCoordinate            // MARIA coordinate of providing agent
  priority: number                     // Resolution priority (0 = highest)
  constraints: ExecutionConstraint[]   // Preconditions for execution
  conflictPolicy: "queue" | "reject" | "merge" | "override"
  ttl: number                         // Registration time-to-live in ms
  version: SemanticVersion
}

interface CommandResolution {
  resolve(command: string, context: ExecutionContext): ResolvedCommand
  resolveAll(command: string): ResolvedCommand[]  // All providers
  registerConflictHandler(handler: ConflictHandler): void
}

優先ルーティング。 複数のエージェントが同じコマンドを登録する場合、レジストリは優先チェーンを使用して、どのプロバイダーが呼び出しを処理するかを決定します。優先順位は、(1) 登録時に設定された明示的な優先順位値、(2) エージェントの特化スコア (エージェントのプライマリ ドメインがコマンド ドメインとどの程度一致するか)、(3) 現在の負荷 (使用率が低いエージェントが優先される)、(4) 過去のパフォーマンス (このコマンドの成功率が高いエージェントが優先される) によって決定されます。この 4 要素のランキングにより、手動のルーティング構成を必要とせずに、最も適切なエージェントが各コマンド呼び出しを処理することが保証されます。

競合処理 コマンドの競合は、2 つのエージェントが同じコマンドを同じ優先順位で登録しようとすると発生します。レジストリは 4 つの競合ポリシーをサポートしています。 キュー は同時登録をシリアル化し、最初の登録者を優先します。 拒否 は 2 番目の登録を拒否し、エージェントに別のコマンド名での登録を強制します。 マージ は、両方の登録を負荷分散されたプールに結合します。 上書き は、既存の登録を新しい登録に置き換えて、移動されたエージェントに通知します。競合ポリシーの選択はコマンドごとに設定され、組織のガバナンス ルールによって上書きできます。

ここで、R(c, ctx) はコンテキスト ctx 内のコマンド c の解決されたエージェント、A(c) はコマンド c に登録されたエージェントのセット、重み w_i は組織ポリシーごとに構成可能です。

4. ツール レジストリ: バージョン管理、互換性、依存関係の追跡

ツール レジストリは、組織内で利用可能なすべてのツールのインベントリを管理します。各ツールには、OS が互換性、依存関係、リソース要件を判断できる豊富なメタデータが登録されています。

interface ToolRegistryEntry {
  toolId: string
  name: string
  version: SemanticVersion
  author: AgentCoordinate
  inputSchema: JSONSchema
  outputSchema: JSONSchema
  dependencies: ToolDependency[]       // Other tools this tool requires
  conflicts: string[]                  // Tools that cannot co-execute
  resourceRequirements: ResourceSpec   // CPU, memory, API rate limits
  compatibilityMatrix: CompatEntry[]   // Compatible tool versions
  lifecycle: "alpha" | "beta" | "stable" | "deprecated" | "retired"
  auditTrail: AuditRecord[]           // Who registered, modified, used
}

interface CompatEntry {
  toolId: string
  minVersion: SemanticVersion
  maxVersion: SemanticVersion
  status: "compatible" | "degraded" | "incompatible"
}

互換性マトリックス ツール レジストリの重要な革新は、互換性マトリックスです。これは、どのツールのバージョンが安全に同時実行できるかについての宣言的な仕様です。エージェントが複合タスク用のツールのセットを要求すると、レジストリは互換性マトリックスをチェックして、競合するバージョンが割り当てられていないことを確認します。これにより、エージェントが互換性のないツール バージョンを使用し、一貫性のない結果が生成される、運用マルチエージェント システムでよくある種類の障害が防止されます。

依存関係の追跡。 ツールは他のツールに依存することがよくあります。規制遵守チェッカーは規制データベース アクセサーに依存します。証拠収集者は文書パーサーに依存します。レポート ジェネレーターはテンプレート エンジンに依存します。ツール レジストリは完全な依存関係グラフを維持し、ツールがエージェントに割り当てられるときに、すべての推移的な依存関係も利用できるようにします。依存関係が利用できない場合 (提供エージェントがオフラインであるなど)、レジストリは割り当てをキューに入れるか、同じ依存関係を満たす代替ツールを提案します。

バージョン管理 ツールは時間の経過とともに進化します。レジストリはすべてのツールの完全なバージョン履歴を維持し、セマンティック バージョニングを強制します。メジャー バージョンの変更は API の重大な変更を示し、マイナー バージョンは既存の契約を破ることなく機能を追加し、パッチ バージョンはバグを修正します。エージェントがツールを要求する場合、バージョン範囲 (例: '^2.0.0') を指定でき、レジストリは最も互換性のあるバージョンに解決されます。

5. 能力グラフ: スキルの継承、構成、発見

ケイパビリティ グラフは、ケイパビリティ OS のアーキテクチャ的に最も重要なコンポーネントです。コマンド レジストリとツール レジストリが機能の「内容」と「方法」を管理するのに対し、機能グラフは機能がどのように相互に関連し、より高次の機能に構成され、親機能からプロパティを継承するかという「構造」を管理します。

グラフ G はラベル付きの有向非巡回グラフであり、頂点は機能を表し、辺はそれらの間の関係を表します。 4 つのエッジ タイプは、機能関係の全範囲をキャプチャします。

構成します。 機能 A が機能 B と C を構成するということは、指定された調整パターン (順次、並列、または条件付き) で B と C を実行することによって A を実現できることを意味します。たとえば、「財務監査」は、「ステートメント分析」、「規制チェック」、および「証拠収集」を、各段階が次の段階にフィードされる連続パターンで構成します。

継承。 機能 A が機能 B から継承するということは、A が B のすべてのプロパティと追加の特殊化を所有していることを意味します。 「IFRS-compliance-check」は「regulatory-compliance-check」を継承し、IFRS 固有のルール セットを追加します。継承により、OS は子孫の機能を使用して親の機能に対する要求を満たすことができます。

必須。 機能 A には機能 B が必要ということは、B が利用可能でなければ A を実行できないことを意味します。これは厳密な依存関係です。構造的な構成を記述する「composes」とは異なり、「requires」は操作上の必要性を記述します。財務レポート ジェネレーターにはデータベース アクセスが必要です。タスクがどのように構成されているかに関係なく、それなしでは機能しません。

競合。 機能 A が機能 B と競合するということは、それらを同時に実行できないことを意味します。これは通常、共有された可変状態、つまり同じデータベース テーブルに書き込む 2 つのツール、または並列実行時に矛盾した結果を生成する 2 つの分析ツールから発生します。

6. 能力発見プロトコル

エージェントは、現在の機能セットを超えるタスクに遭遇すると、機能 OS に検出クエリを発行します。ディスカバリ プロトコルは、セマンティック マッチング、構造検証、割り当てネゴシエーションの 3 つのフェーズで動作します。

interface CapabilityQuery {
  intent: string                       // Natural language task description
  requiredOutputSchema?: JSONSchema    // Expected output format
  constraints: {
    maxLatency?: number                // Maximum acceptable response time
    securityLevel?: SecurityLevel      // Minimum security clearance
    dataResidency?: Region[]           // Where data must stay
    costBudget?: number                // Maximum cost in resource units
  }
  composition: "any" | "all" | "best"  // Match strategy
}

interface CapabilityMatch {
  capabilityId: string
  provider: AgentCoordinate
  confidence: number                   // 0-1 semantic match confidence
  estimatedLatency: number
  estimatedCost: number
  alternativePaths: CapabilityPath[]   // Composite alternatives
}

フェーズ 1: セマンティック マッチング。 OS はインテント文字列を機能ベクトルに変換し、登録されているすべての機能に対してコサイン類似度を計算します。これにより、一致候補のランク付けされたリストが生成されます。セマンティック マッチングは、要求側エージェントが機能の登録時とは異なる用語を使用する場合を処理します。つまり、文字列が異なっていても、「規制遵守のチェック」は「規制遵守チェック」と一致します。

フェーズ 2: 構造の検証。 各候補の一致が能力グラフに対して検証されます。 OS は、すべての依存関係が満たされていること、要求側エージェントの現在の機能との競合が存在しないこと、および現在のエージェントの可用性を考慮して合成パス (一致が複合機能の場合) が実行可能であることをチェックします。構造検証により、意味的には正しいように見えても、操作上実行不可能な一致が排除されます。

フェーズ 3: 割り当てのネゴシエーション。 検証された一致の場合、OS は提供エージェントと割り当てをネゴシエートします。これには、計算リソースの予約、通信チャネルの確立、機能セッションの監視の設定が含まれます。割り当てはトランザクションです。いずれかのステップが失敗した場合、割り当て全体がロールバックされ、次に最適な一致が試行されます。

ここで、N は登録された機能の数、d_max は機能グラフの最大深さ (構造検証用)、O(1) 項は割り当てネゴシエーション (一致ごとの一定時間) を表します。対数項は、インデックス付きレジストリ検索から得られます。インデックス付けがなければ、検出には O(N) 回のスキャンが必要になり、能力グラフがなければ、構成パスの検証には O(N^2) 回のペアごとのチェックが必要になります。

7. 機能の割り当て: OS レベルのスケジューリング

機能が検出されると、OS はそれを割り当てる必要があります。つまり、特定のエージェント (またはエージェント グループ) を割り当てて、要求側エージェントのタスクに機能を提供する必要があります。割り当ては、Capability OS の従来のオペレーティング システムにおけるプロセス スケジューリングに相当します。

割り当てアルゴリズムでは、可用性 (提供エージェントは現在オンラインで同時実行制限を下回っていますか?)、アフィニティ (このエージェント ペアは以前に正常に連携していましたか?)、局所性 (エージェントは同じゾーンまたはプラネットにあり、通信オーバーヘッドを最小限に抑えていますか?)、公平性 (この提供エージェントは最近過剰に使用されており、バーンアウトや品質低下の危険がありますか?) の 4 つの側面が考慮されます。

ここで、r は要求側エージェント、c は機能、P(c) は機能 c のプロバイダーのセット、重みのアルファ、ベータ、ガンマ、デルタは組織のポリシーによって調整されます。 MARIA OS 座標系は、自然な局所性メトリックを提供します。同じゾーン内のエージェントは、局所性 1.0、同じ惑星 0.8、同じ宇宙 0.5、および銀河間 0.1 を持ちます。

Capability allocation in the Agent OS mirrors CPU scheduling in traditional operating systems, but with a crucial difference: agents have preferences, reputation, and fatigue. The fairness dimension prevents the 'hot agent' problem where the most capable agent is allocated every task until its quality degrades.

8. 数学モデル: カテゴリとしての能力グラフ

私たちは圏論を使用して能力グラフを形式化し、合成と変換について推論するための厳密なフレームワークを提供します。

定義 8.1 (能力カテゴリ)。 Cap を、オブジェクトが能力で射がスキル伝達であるカテゴリとする。射 f: A -> B は、機能 A を機能 B に変換する能力を表します。たとえば、「生の財務データ」 -> 「構造化財務分析」です。恒等射 id_A は、変換なしで機能 A を実行するエージェントを表します。

定理 8.1 (合成閉包) 射 f: A -> B および g: B -> C が Cap に存在する場合、合成射は g です。 f: A -> C が存在し、合成された機能を表します。これは、能力空間が合成下で閉じられていることを意味します。スキル伝達の連鎖は、単一の複合能力として実行できます。

証明 能力グラフの構成の定義により、ラベル「構成」を持つエッジ (A, B) とラベル「構成」を持つエッジ (B, C) の両方が存在する場合、グラフ構築アルゴリズムはラベル「構成」と構成パターン「sequential(f, g)」を持つエッジ (A, C) を生成します。結果として得られる機能は、A の入力スキーマと C の出力スキーマを継承し、B が中間チェックポイントとして機能します。構造上、これはカテゴリー合成公理 g を満たします。 f: A -> C。結合性は、順次実行の結合性から生じます。

定義 8.2 (能力ファンクター)。 組織ファンクター F: Cap_1 -> Cap_2 は、構成構造を維持しながら、ある組織単位の能力カテゴリを別の組織単位にマップします。これは、チームの能力構造全体が新しい事業単位に複製されるときの「能力移植」という考え方を形式化したものです。

9. 組織のインテリジェンス: 個人の能力から集団の能力へ

Capability OS アーキテクチャに関する重要な洞察は、組織の能力が単に個々のエージェントの能力の合計ではないということです。能力グラフの構成関係により、単一のエージェントが所有しない新たな能力が作成されます。

ここで、C_i はエージェント i の機能セットであり、Compose は機能グラフからすべての有効な構成を生成します。 Compose という用語は、組織のインテリジェンス、つまり個々の能力の構造化された組み合わせから生まれる能力を表します。

組織のインテリジェンスの成長 エージェントが（学習、ツールの習得、またはスキルの伝達を通じて）新しい能力を獲得すると、組織のインテリジェンスは超直線的に成長します。

ここで、Delta C は時間 t+1 に追加された新しい個別の機能を表し、Delta Compose はそれらの追加によって有効になった新しい構成を表します。新しい機能はそれぞれ既存の機能と合成できる可能性があるため、合成項は最悪の場合は 2 次関数的に、実際には少なくとも線形的に増加します。この超線形成長は「自己拡張」特性の数学的基礎です。新しい基本的な機能がそれぞれ複数の複合的な機能を解放するため、組織が持つ機能が増えれば増えるほど、新しい機能をより早く獲得できるようになります。

The self-extension property creates a capability flywheel: new capabilities compose with existing ones to create composite capabilities, which in turn serve as building blocks for even higher-order compositions. This is the organizational analog of compound interest — and it only works when composition is managed at the OS level.

10. 機能ライフサイクル管理

機能は静的ではありません。これらは作成、検証、展開、監視され、最終的には非推奨になります。 Capability OS は、MARIA OS 意思決定パイプラインを反映するステート マシンを通じてこのライフサイクル全体を管理します。

type CapabilityLifecycle =
  | "proposed"      // Agent proposes a new capability
  | "validating"    // OS validates schema, dependencies, conflicts
  | "staging"       // Capability available in test environment
  | "deployed"      // Capability available in production
  | "monitoring"    // Active with enhanced observability
  | "deprecated"    // Marked for removal, existing users warned
  | "retired"       // Fully removed from registry

const validTransitions: Record<CapabilityLifecycle, CapabilityLifecycle[]> = {
  proposed:   ["validating"],
  validating: ["staging", "proposed"],      // Can reject back to proposed
  staging:    ["deployed", "proposed"],      // Can reject back
  deployed:   ["monitoring", "deprecated"],
  monitoring: ["deployed", "deprecated"],
  deprecated: ["retired", "deployed"],       // Can un-deprecate
  retired:    [],                            // Terminal state
}

作成。 エージェントは、コマンドを登録し、それを 1 つ以上のツールに関連付け、機能グラフ内での位置 (継承元、構成内容、競合内容) を宣言することによって、新しい機能を提案します。 OS は、この提案を既存のグラフ構造に対して検証し、名前の競合、循環依存関係、互換性違反をチェックします。

検証。 検証中、OS はテスト スイート (事前定義された入力と予期される出力) に対して機能を実行します。機能が合成の場合、OS は合成パターンがコンポーネントの機能から正しい結果を生成することを検証します。検証にはセキュリティ レビューも含まれます。つまり、その機能は機密データにアクセスしますか?共有状態は変更されますか?昇格された権限が必要ですか?

展開と監視。展開されると、機能はレジストリに登録され、検出と割り当てに使用できるようになります。 OS は、実行成功率、遅延分布、リソース消費、ユーザー満足度などの機能の健全性を継続的に監視します。正常性のしきい値を下回る機能は、監視可能性が強化された「監視」状態に自動的に昇格され、回復しない場合は非推奨になります。

非推奨と廃止。 ある機能がより優れた代替品に置き換えられると、OS はその機能を非推奨にし、既存のユーザーに対する下位互換性を維持しながら、その機能を「新規使用には推奨されない」とマークします。非推奨には移行パスが含まれます。OS は、現在非推奨の機能を使用しているすべてのエージェントを識別し、置き換えを提案します。猶予期間が経過すると、非推奨の機能は廃止され、レジストリから完全に削除されます。

11. ケーススタディ: 54 エージェント監査室

Capability OS アーキテクチャを検証するために、MARIA OS 階層の単一のプラネット (監査ドメイン) 内の 6 つのフロア (ゾーン) にまたがって組織された 54 のエージェントで構成されるシミュレートされた監査オフィスにそれを導入しました。

Capability OS 以前。 エージェントは静的に構成されたツール セットを使用して動作していました。財務分析エージェントが法規制順守チェックを必要とする場合、コンプライアンス ツールを事前にインストールするか (エージェント間で複製する)、コンプライアンス エージェントに手動で支援を要求する必要がありました (調整のオーバーヘッドが発生します)。平均機能検出時間は 2.3 秒でした (O(N) リニア スキャン)。ツールのバージョンの競合は週に 3.7 回発生し、手動による介入が必要でした。ツールの使用率は 34% でした。ツールの存在を「所有」エージェントだけが知っていたため、ほとんどのツールはアイドル状態のままでした。

Capability OS 以降。 204 個のツールすべてが、完全なメタデータ、バージョン管理、および互換性マトリックスとともにツール レジストリに登録されました。コマンド レジストリは、54 のエージェントすべてにわたって 89 の正規コマンドをマッピングしました。能力グラフには、847 個のエッジを持つ 312 個の能力ノード (204 個のプリミティブ + 108 個のコンポジット) が含まれていました。平均機能検出時間は 12 ミリ秒 (O(log N)) に短縮されました。ツール バージョンの競合はゼロになりました。互換性マトリックスにより、割り当ての競合が防止されました。ツールの使用率は 87.3% に上昇しました。検出プロトコルにより、すべてのツールがすべてのエージェントに表示されるようになりました。

動作中の自己拡張。 90 日間にわたって、Capability OS は、明示的に登録されていないグラフ内の有効な構成パスを識別することにより、216 の新しい複合機能を自律的に生成しました。たとえば、OS は、Z1 の「キャッシュ フロー予測」ツールと、Z2 の「継続企業の評価」ツールおよび Z4 の「ナラティブ合成」ツールを組み合わせることで、以前は 3 つのフロアにわたる手動調整が必要だった複合的な「継続企業の意見草案」機能が作成されることを発見しました。この複合機能は、過去の監査出力に対して検証され、94.2% の精度で導入されました。

12. 従来のオペレーティングシステムとの比較

Capability OS は従来のオペレーティング システムと意図的に類似点を描きますが、その違いは類似点と同じくらい有益です。

最も重要な違いは セマンティック レイヤー です。従来のオペレーティング システムは構文規約に基づいて動作します。システム コールには固定の署名があり、ファイル パスは文字列、プロセス ID は整数です。 Capability OS はセマンティック コントラクトに基づいて動作します。ケーパビリティ クエリは意図を表現し、ツールの互換性は機能の同等性によって評価され、構成はセマンティックな一貫性によって検証されます。このセマンティック層は自己拡張特性を可能にするものであり、OS は明示的にプログラムされていない機能関係について推論することができます。

13. 将来の方向性: 自己最適化能力グラフ

現在の Capability OS アーキテクチャは、エージェントによって登録された機能を管理します。次のフロンティアは、自身の構造を積極的に最適化するケイパビリティ OS です。つまり、需要パターンに基づいてケイパビリティ グラフを再編成し、必要になる可能性が高い機能を先制して構成し、役に立たなくなった機能を廃止します。

需要主導型の再構築。 検出クエリ パターンを分析することで、OS は機能のギャップ、つまり頻繁に要求されるが既存の機能では十分に対応できないタスクを特定できます。ギャップが検出されると、OS は、(a) ギャップを埋める外部ツールを検索し、その取得を推奨するか、(b) ギャップをカバーする新しい方法で既存の機能を構成しようとします。これにより、Capability OS が受動的なレジストリから能動的な機能ストラテジストに変わります。

予測合成。 機能 A、B、および C が頻繁に検出され、一緒に割り当てられていることを OS が観察した場合、複合機能「ABC」を事前に作成し、合成プランをキャッシュできます。次回エージェントが 3 つすべてを必要とするときは、3 つの個別の検出割り当てサイクルのオーバーヘッドなしで、コンポジットがすぐに使用可能になります。

ここで、G*(t+1) は時間 t+1 での最適なグラフ構造、Q(t) は時間 t で観察されたクエリのセット、T_discover はグラフ G' 内のクエリ q の検出レイテンシ、lambda はグラフの複雑さにペナルティを与える正則化パラメータです (グラフが際限なく増大するのを防ぎます)。

能力の代謝。 生物では、使用されない細胞はリサイクルされます。同様に、長期間にわたって発見または割り当てられていない機能は、非推奨の候補となります。 OS は、各機能の「代謝率」、つまり展開後の時間に対する割り当てイベントの比率を実装できます。代謝率がしきい値を下回る機能には、レビューおよび非推奨の可能性のフラグが立てられ、機能の表面が無駄がなく、発見しやすい状態に保たれます。

Self-optimizing capability graphs must operate under governance constraints. The OS cannot autonomously deprecate capabilities that are required by compliance regulations or safety-critical workflows. All optimization decisions must pass through the MARIA OS Responsibility Gate framework, ensuring that capability evolution never compromises organizational accountability.

14. 結論

Agent Capability OS は、組織が小規模なエージェント チームを超えて拡大するにつれて重要になるマルチエージェント アーキテクチャのギャップに対処します。独自の機能を管理する個々のエージェントは、5 ～ 10 人のエージェントの規模で動作します。エージェントが 50 人になると、調整のオーバーヘッドが大きくなります。エージェントが 500 個になると、OS レベルの抽象化なしではシステムを管理できなくなります。

3 つのレジストリ (コマンド、ツール、機能グラフ) は、インターフェイス (どのようなコマンドが存在するか)、実装 (どのツールがそれらを実現するか)、および構造 (機能がどのように構成されるか) という懸念事項を明確に分離する階層化されたアーキテクチャを提供します。この分離により、明確に定義された契約を通じて一貫性を維持しながら、各層が独立して進化することが可能になります。

数学的フレームワーク (能力カテゴリー、組織インテリジェンスの成長、最適なグラフ再構成) は、能力管理について推論するための厳密な基盤を提供します。特に、カテゴリー理論の定式化により、構成が明確に定義され、組織単位間の機能移植によって構造的完全性が維持されることが保証されます。

このケーススタディは、Capability OS が理論上の演習ではないことを示しています。 200 以上のツールを備えた 54 人のエージェントからなる監査オフィスは、検出遅延 (2.3 秒から 12 ミリ秒)、ツール使用率 (34% から 87.3%)、および競合率 (週あたり 3.7 件からゼロ) において劇的な改善を達成しました。最も重要なことは、自己拡張特性 (90 日間にわたる 216 の複合機能の自律生成) によって、OS レベルの機能管理により、個々のエージェントの機能の合計を超える組織インテリジェンスが可能になるという中心的な理論が検証されることです。

代理店組織の将来は、単により多くの代理店やより優れた代理店を抱えることではありません。それは、組織全体の機能面を管理するオペレーティング システムを持つこと、つまり、個々のエージェントや人間の管理者が太刀打ちできないようなペースと複雑さで機能を発見、構成、割り当て、進化させることです。 Agent Capability OS はその未来の基盤です。