1. はじめに：なぜ能力にはOSが必要か
単一のソフトウェアエージェントがウェブ検索ツール、データベースクエリツール、テキスト要約スキルを持つ場合を考えよう。このエージェントは自身の能力を自明に管理できる：何ができるか知っており、各ツールの制約を理解し、外部調整なしにタスク実行を計画できる。では、監査事務所の54体のエージェントを考えよう。各エージェントは3〜12個のツールを装備し、財務分析、規制準拠、証拠収集、レポート生成、クライアントコミュニケーション、内部ワークフロー管理を網羅する。総能力表面は200以上の個別ツールと400の複合スキルを超える。この能力ランドスケープの完全なモデルを保持できるエージェントは一つもない。
これは新しい観察ではない — 分散システムは常に調整課題に直面してきた。エージェント能力管理が従来のサービスディスカバリやマイクロサービスオーケストレーションと根本的に異なるのは、エージェント能力の意味的豊かさである。マイクロサービスは型付き入出力を持つ固定APIを公開する。エージェント能力は文脈依存的で、合成可能で、進化する。エージェントの「財務諸表を分析する」能力は、どのツールにアクセスできるか、どのデータソースが利用可能か、どの規制フレームワークが適用されるか、他のエージェントが既に何を処理したかに依存する。能力は静的なエンドポイントではない。組織環境の変化とともに変化する動的で文脈依存の関数である。
従来のマルチエージェント調整アプローチ — ブラックボードアーキテクチャ、契約ネットプロトコル、市場ベースのタスク割当 — は能力を原子的なラベルとして扱う。エージェントAはタスクXを「実行できる」。この二値的なフレーミングは、能力に内部構造がある場合に崩壊する：バージョン、依存関係、互換性制約、合成ルール、ライフサイクル状態。あるエージェントが規制準拠ツールのバージョン2.3を持ち、それが別のエージェントが使用している証拠収集ツールのバージョン1.xと非互換であるかもしれない。二値ラベルではこれを捉えられない。
必要なのはエージェント能力のためのオペレーティングシステム — 従来のOSがアプリケーション間でプロセス、メモリ、I/Oを管理するように、エージェント集団全体で能力の全ライフサイクルを管理するシステムレベルの抽象化である。Agent Capability OSはエージェントの自律性を置き換えない。エージェントが調整カオスに陥ることなく能力を発見・要求・合成・拡張できるインフラストラクチャを提供する。
2. 3つのレジストリ：アーキテクチャ概要
Agent Capability OSは3つの連動するレジストリを中心に構造化されており、それぞれが能力管理問題の異なるレイヤーに対応する。
// Capability OS アーキテクチャ
interface CapabilityOS {
commandRegistry: CommandRegistry // レイヤー1: どのコマンドが存在するか
toolRegistry: ToolRegistry // レイヤー2: どのツールがそれを実装するか
capabilityGraph: CapabilityGraph // レイヤー3: 能力がどう合成されるか
// コア操作
discover(query: CapabilityQuery): CapabilityMatch[]
allocate(agentId: string, capabilityId: string): AllocationResult
compose(capabilities: string[]): CompositeCapability | null
extend(base: string, extension: CapabilityExtension): string
}Command Registryはインターフェースレイヤーである。高レベルのコマンド名（例：'analyze-financial-statement'、'generate-audit-report'）を実行可能な能力チェーンにマッピングする。コマンド解決を処理する — 複数のエージェントやツールが同じコマンドを実行できる場合、レジストリが優先度、ルーティング、衝突解決を決定する。Command Registryはシェルのパス解決に類似するが、意味的な認識を持つ：'analyze-financial-statement'と'financial-statement-analysis'が同じ能力を指すことを理解し、適切にルーティングする。
Tool Registryは実装レイヤーである。組織内で利用可能なすべてのツールのメタデータを保存する：バージョン、作者、入出力スキーマ、リソース要件、互換性制約、依存チェーン。Tool Registryはパッケージマネージャ（npm、pip）に類似するが、ビルド時ではなく実行時に動作する。エージェントはTool Registryに問い合わせて能力要件を満たすツールを発見し、レジストリは互換性と可用性でフィルタリングされたランク付き結果を返す。
Capability Graphは合成レイヤーである。エージェント能力の全空間を有向非巡回グラフとしてモデル化し、ノードが能力、エッジが合成関係を表す（例：'financial-audit'は'statement-analysis' + 'regulatory-check' + 'evidence-collection'を合成する）。Capability Graphにより、OSは「利用可能なエージェントの組み合わせでこの複雑なタスクを遂行できるか？」や「組織を新しいドメインに拡張するために必要な最小の能力セットは何か？」といった問いに答えることができる。
3. Command Registry：動的解決と衝突処理
Command Registryはコマンド識別子から実行可能な能力チェーンへのマッピングを維持する。静的な設定ファイルとは異なり、レジストリは動的である：エージェントがオンライン・オフラインになったり、新しい能力を獲得したりするたびに、コマンドの登録・登録解除が実行時に行われる。
interface CommandRegistryEntry {
commandId: string // 正規コマンド識別子
aliases: string[] // 意味的エイリアス
provider: AgentCoordinate // 提供エージェントのMARIA座標
priority: number // 解決優先度（0 = 最高）
constraints: ExecutionConstraint[] // 実行前提条件
conflictPolicy: "queue" | "reject" | "merge" | "override"
ttl: number // 登録有効期間（ミリ秒）
version: SemanticVersion
}優先度ルーティング. 複数のエージェントが同じコマンドを登録した場合、レジストリは優先度チェーンを使用してどのプロバイダーが呼び出しを処理するかを決定する。優先度は以下で決定される：(1) 登録時に設定された明示的な優先度値、(2) エージェント専門化スコア（エージェントの主要ドメインがコマンドドメインにどれだけ近いか）、(3) 現在の負荷（利用率が低いエージェントが優先）、(4) 過去のパフォーマンス（このコマンドでの成功率が高いエージェントが優先）。この4要素ランキングにより、手動ルーティング設定なしに最適なエージェントが各コマンド呼び出しを処理することが保証される。
衝突処理. コマンド衝突は、2つのエージェントが同じ優先度で同じコマンドを登録しようとした場合に発生する。レジストリは4つの衝突ポリシーをサポートする。Queueは並行登録をシリアライズし、最初の登録者に優先度を与える。Rejectは2番目の登録を拒否し、エージェントに別のコマンド名での登録を強制する。Mergeは両方の登録をロードバランスされたプールに統合する。Overrideは既存の登録を新しいもので置き換え、追い出されたエージェントに通知する。
R(c, ctx) = \arg\max_{a \in A(c)} \left[ w_1 \cdot \text{priority}(a) + w_2 \cdot \text{spec}(a, c) + w_3 \cdot (1 - \text{load}(a)) + w_4 \cdot \text{perf}(a, c) \right]ここでR(c, ctx)はコンテキストctxにおけるコマンドcの解決エージェント、A(c)はコマンドcに登録されたエージェントの集合、重みw_iは組織ポリシーごとに設定可能である。
4. Tool Registry：バージョニング、互換性、依存関係追跡
Tool Registryは組織内で利用可能なすべてのツールのインベントリを管理する。各ツールは豊富なメタデータとともに登録され、OSが互換性、依存関係、リソース要件について推論できるようにする。
interface ToolRegistryEntry {
toolId: string
name: string
version: SemanticVersion
author: AgentCoordinate
inputSchema: JSONSchema
outputSchema: JSONSchema
dependencies: ToolDependency[] // このツールが必要とする他のツール
conflicts: string[] // 同時実行できないツール
resourceRequirements: ResourceSpec // CPU、メモリ、APIレート制限
compatibilityMatrix: CompatEntry[] // 互換ツールバージョン
lifecycle: "alpha" | "beta" | "stable" | "deprecated" | "retired"
auditTrail: AuditRecord[] // 誰が登録・修正・使用したか
}互換性マトリクス. Tool Registryの重要なイノベーションは互換性マトリクスである — どのツールバージョンが安全に共同実行できるかの宣言的仕様。エージェントが複合タスクのためにツールセットを要求すると、レジストリは互換性マトリクスをチェックして、競合するバージョンが割り当てられないことを保証する。これにより、本番マルチエージェントシステムで一般的な障害クラス — エージェントが非互換のツールバージョンを使用して矛盾する結果を生成する — が防止される。
依存関係追跡. ツールはしばしば他のツールに依存する。規制準拠チェッカーは規制データベースアクセサに依存し、証拠コレクタはドキュメントパーサに依存し、レポートジェネレータはテンプレートエンジンに依存する。Tool Registryは完全な依存関係グラフを維持し、ツールがエージェントに割り当てられる際にすべての推移的依存関係も利用可能であることを保証する。依存関係が利用不可の場合（例：提供エージェントがオフライン）、レジストリは割当をキューに入れるか、同じ依存関係を満たす代替ツールを提案する。
バージョン管理. ツールは時間とともに進化する。レジストリはすべてのツールの完全なバージョン履歴を維持し、セマンティックバージョニングを強制する：メジャーバージョン変更は破壊的API変更を示し、マイナーバージョンは既存の契約を壊さずに機能を追加し、パッチバージョンはバグを修正する。エージェントがツールを要求する際、バージョン範囲（例：'^2.0.0'）を指定でき、レジストリは最適な互換バージョンに解決する。
5. Capability Graph：スキル継承、合成、発見
Capability GraphはCapability OSの最もアーキテクチャ的に重要なコンポーネントである。CommandレジストリとToolレジストリが能力の「何を」と「どのように」を管理するのに対し、Capability Graphは「構造」を管理する — 能力がどう相互に関連し、高次の能力に合成され、親能力からプロパティを継承するか。
G = (V, E, \phi) \text{ where } V = \text{capabilities}, E \subseteq V \times V, \phi: E \to \{\text{composes}, \text{inherits}, \text{requires}, \text{conflicts}\}グラフGはラベル付き有向非巡回グラフであり、頂点が能力を、エッジが能力間の関係を表す。4種類のエッジが能力関係の全範囲を捉える：
Composes（合成）. 能力Aが能力BとCを合成するとは、AがBとCを指定された調整パターン（逐次、並行、条件付き）で実行することで達成できることを意味する。例えば、'financial-audit'は'statement-analysis'、'regulatory-check'、'evidence-collection'を各段階が次に供給される逐次パターンで合成する。
Inherits（継承）. 能力Aが能力Bを継承するとは、AがBのすべてのプロパティに加えて追加の特殊化を持つことを意味する。'IFRS-compliance-check'は'regulatory-compliance-check'を継承し、IFRS固有のルールセットを追加する。継承により、OSは親能力の要求をいずれの子孫能力でも満たすことができる。
Requires（要求）. 能力Aが能力Bを要求するとは、Bが利用可能でなければAが実行できないことを意味する。これはハードな依存関係であり、構造的合成を記述する'composes'とは異なり、'requires'は運用上の必要性を記述する。財務レポートジェネレータはデータベースアクセスを要求し、タスクの構造に関係なくそれなしでは機能しない。
Conflicts（競合）. 能力Aが能力Bと競合するとは、同時に実行できないことを意味する。これは通常、共有可変状態から生じる — 同じデータベーステーブルに書き込む2つのツール、または並行実行すると矛盾する結果を生成する2つの分析ツール。
6. 能力発見プロトコル
エージェントが現在の能力セットを超えるタスクに遭遇すると、Capability OSに発見クエリを発行する。発見プロトコルは3つのフェーズで動作する：意味的マッチング、構造的検証、割当ネゴシエーション。
interface CapabilityQuery {
intent: string // 自然言語タスク記述
requiredOutputSchema?: JSONSchema // 期待される出力フォーマット
constraints: {
maxLatency?: number // 最大許容応答時間
securityLevel?: SecurityLevel // 最低セキュリティクリアランス
dataResidency?: Region[] // データが存在すべき場所
costBudget?: number // リソース単位での最大コスト
}
composition: "any" | "all" | "best" // マッチ戦略
}フェーズ1：意味的マッチング. OSはintent文字列を能力ベクトルに変換し、すべての登録能力に対するコサイン類似度を計算する。これにより候補マッチのランク付きリストが生成される。意味的マッチングは、要求エージェントが能力の登録時とは異なる用語を使用するケースを処理する — 'check regulatory compliance'は文字列が異なっていても'regulatory-compliance-check'にマッチする。
フェーズ2：構造的検証. 各候補マッチはCapability Graphに対して検証される。OSはすべての依存関係が充足可能か、要求エージェントの現在の能力と競合がないか、合成パスが現在のエージェント可用性を考慮して実行可能かをチェックする。構造的検証は、意味的には正しく見えるが運用上は実行不可能なマッチを排除する。
フェーズ3：割当ネゴシエーション. 検証されたマッチに対して、OSは提供エージェントと割当をネゴシエーションする。これには計算リソースの予約、通信チャネルの確立、能力セッションのモニタリング設定が含まれる。割当はトランザクショナルであり、いずれかのステップが失敗すると、割当全体がロールバックされ、次善のマッチが試行される。
T_{\text{discover}}(N) = O(\log N) + O(d_{\max}) + O(1)ここでNは登録能力数、d_maxはCapability Graphの最大深度（構造的検証用）、O(1)項は割当ネゴシエーション（マッチごとの定数時間）を表す。対数項はインデックス付きレジストリルックアップに由来する。インデックスなしでは発見にO(N)スキャンが必要となり、Capability Graphなしでは合成パスの検証にO(N^2)のペアワイズチェックが必要となる。
7. 能力割当：OSレベルスケジューリング
能力が発見されると、OSはそれを割り当てなければならない — つまり、要求エージェントのタスクに対して能力を提供する特定のエージェント（またはエージェントグループ）を指定する。割当は、従来のOSにおけるプロセススケジューリングのCapability OSにおけるアナログである。
割当アルゴリズムは4つの次元を考慮する：可用性（提供エージェントは現在オンラインで並行処理制限以下か？）、親和性（このエージェントペアは以前成功裏に協力したことがあるか？）、局所性（エージェントは同じZoneまたはPlanet内にあり、通信オーバーヘッドを最小化できるか？）、公平性（この提供エージェントは最近過剰利用されていないか、バーンアウトや品質劣化のリスクがないか？）。
A^*(r, c) = \arg\max_{a \in P(c)} \left[ \alpha \cdot \text{avail}(a) + \beta \cdot \text{affinity}(r, a) + \gamma \cdot \text{locality}(r, a) + \delta \cdot \text{fairness}(a) \right]ここでrは要求エージェント、cは能力、P(c)は能力cのプロバイダー集合、重みα、β、γ、δは組織ポリシーによって調整される。MARIA OS座標系は自然な局所性メトリクスを提供する：同じZone内のエージェントは局所性1.0、同じPlanetは0.8、同じUniverseは0.5、Galaxy間は0.1となる。
Agent OSにおける能力割当は、従来のOSにおけるCPUスケジューリングを反映するが、決定的な違いがある：エージェントには好み、評判、疲労がある。公平性の次元は「ホットエージェント」問題 — 最も有能なエージェントに品質が劣化するまですべてのタスクが割り当てられる — を防止する。8. 数学的モデル：圏としてのCapability Graph
Capability Graphを圏論を用いて形式化する。圏論は合成と変換について推論するための厳密なフレームワークを提供する。
定義 8.1（能力圏）. Capを、対象が能力で射がスキル転移である圏とする。射f: A -> Bは能力Aを能力Bに変換する能力を表す — 例えば、「生の財務データ」->「構造化された財務分析」。恒等射id_Aは、エージェントが能力Aを変換なしに実行することを表す。
\mathbf{Cap} = (\text{Obj}=V, \text{Mor}=\{f: A \to B \mid (A, B) \in E\}, \circ, \text{id})定理 8.1（合成閉包）. 射f: A -> Bとg: B -> CがCapに存在する場合、合成射g . f: A -> Cが存在し、合成能力を表す。これは能力空間が合成に関して閉じていることを意味する — スキル転移の任意のチェーンが単一の複合能力として実行できる。
証明. Capability Graphの合成の定義により、ラベル'composes'を持つエッジ(A, B)とラベル'composes'を持つエッジ(B, C)の両方が存在する場合、グラフ構築アルゴリズムはラベル'composes'と合成パターン'sequential(f, g)'を持つエッジ(A, C)を生成する。結果として得られる能力はAの入力スキーマとCの出力スキーマを継承し、Bは中間チェックポイントとして機能する。構成上、これは圏の合成公理g . f: A -> Cを満たす。結合律は逐次実行の結合律から従う。
定義 8.2（能力関手）. 組織関手F: Cap_1 -> Cap_2は、ある組織単位の能力圏を別の組織単位にマッピングし、合成構造を保存する。これは「能力移植」の概念を形式化する — チームの能力構造全体が新しい事業単位に複製される場合。
F: \mathbf{Cap}_1 \to \mathbf{Cap}_2 \text{ preserves } F(g \circ f) = F(g) \circ F(f) \text{ and } F(\text{id}_A) = \text{id}_{F(A)}9. 組織知性：個から集合的能力へ
Capability OSアーキテクチャの重要な洞察は、組織的能力は個々のエージェント能力の単なる総和ではないということである。Capability Graphにおける合成関係は、単一のエージェントが持たない創発的能力を生み出す。
C_{\text{total}} = \bigcup_{i=1}^{N} C_i \cup \text{Compose}(C_1, C_2, \ldots, C_N)ここでC_iはエージェントiの能力集合、ComposeはCapability Graphからすべての有効な合成を生成する。Compose項は組織知性を表す — 個々の能力の構造化された組み合わせから出現する能力。
組織知性の成長. エージェントが新しい能力を獲得すると（学習、ツール獲得、スキル転移を通じて）、組織知性は超線形に成長する：
I(t+1) = I(t) + \Delta C + \Delta\text{Compose}(C_{t+1})ここでΔCは時刻t+1で追加された新しい個別能力、ΔComposeはそれらの追加によって可能になった新しい合成を表す。各新能力は既存のすべての能力と合成できる可能性があるため、合成項は最悪の場合二次的に、実際には少なくとも線形に成長する。この超線形成長が「自己拡張」特性の数学的基盤である：組織が持つ能力が多いほど、新しい能力をより速く獲得できる。なぜなら、各新しいプリミティブ能力が複数の複合能力を解放するからである。
自己拡張特性は能力フライホイールを生み出す：新能力が既存のものと合成して複合能力を生み出し、それがさらに高次の合成の構築ブロックとなる。これは複利の組織的アナログであり、合成がOSレベルで管理される場合にのみ機能する。10. 能力ライフサイクル管理
能力は静的ではない。作成、検証、デプロイ、モニタリング、そして最終的には非推奨化される。Capability OSは、MARIA OS意思決定パイプラインを反映するステートマシンを通じてこの全ライフサイクルを管理する。
type CapabilityLifecycle =
| "proposed" // エージェントが新能力を提案
| "validating" // OSがスキーマ、依存関係、競合を検証
| "staging" // テスト環境で利用可能
| "deployed" // 本番環境で利用可能
| "monitoring" // 強化された観測性で稼働中
| "deprecated" // 削除予定、既存ユーザーに警告
| "retired" // レジストリから完全に削除
const validTransitions: Record<CapabilityLifecycle, CapabilityLifecycle[]> = {
proposed: ["validating"],
validating: ["staging", "proposed"], // proposedに差し戻し可
staging: ["deployed", "proposed"], // 差し戻し可
deployed: ["monitoring", "deprecated"],
monitoring: ["deployed", "deprecated"],
deprecated: ["retired", "deployed"], // 非推奨解除可
retired: [], // 終端状態
}作成. エージェントはコマンドを登録し、1つ以上のツールに関連付け、Capability Graph内での位置（何から継承するか、何を合成するか、何と競合するか）を宣言することで新能力を提案する。OSは既存のグラフ構造に対してこの提案を検証する — 名前の衝突、循環依存、互換性違反をチェックする。
検証. 検証中、OSは能力をテストスイート — 期待される出力を持つ事前定義された入力 — に対して実行する。能力が合成である場合、OSは合成パターンがコンポーネント能力から正しい結果を生成することを検証する。検証にはセキュリティレビューも含まれる：能力は機密データにアクセスするか？共有状態を変更するか？昇格された権限を必要とするか？
デプロイとモニタリング. デプロイされると、能力はレジストリに入り、発見と割当に利用可能になる。OSは能力の健全性を継続的にモニタリングする：実行成功率、遅延分布、リソース消費、ユーザー満足度。健全性閾値を下回る能力は自動的に強化された観測性を持つ'monitoring'状態にエスカレーションされ、回復しない場合は非推奨化される。
非推奨化と廃止. 能力がより良い代替によって置き換えられた場合、OSはそれを非推奨化する — 既存ユーザーとの後方互換性を維持しながら「新規使用には推奨しない」とマークする。非推奨化には移行パスが含まれる：OSは非推奨能力を現在使用しているすべてのエージェントを特定し、代替を提案する。猶予期間の後、非推奨化された能力は廃止され、レジストリから完全に削除される。
11. ケーススタディ：54体エージェント監査事務所
Capability OSアーキテクチャを検証するため、MARIA OS階層の単一Planet（監査ドメイン）内の6フロア（Zone）にわたって編成された54体のエージェントで構成されるシミュレートされた監査事務所にデプロイした。
| フロア（Zone） | エージェント数 | 主要能力 | ツール数 |
|---|---|---|---|
| Z1: 財務分析 | 12 | 財務諸表解析、比率分析、トレンド検出 | 38 |
| Z2: 規制準拠 | 9 | 規制マッチング、準拠スコアリング、ギャップ分析 | 31 |
| Z3: 証拠収集 | 8 | 文書検索、インタビュー統合、保管連鎖 | 28 |
| Z4: レポート生成 | 7 | ナラティブ統合、チャート生成、エグゼクティブサマリー | 24 |
| Z5: クライアント対応 | 6 | 状況報告、問い合わせ対応、会議調整 | 19 |
| Z6: 内部運営 | 12 | ワークフロー管理、品質保証、研修 | 64 |
| **合計** | **54** | — | **204** |Capability OS導入前. エージェントは静的に設定されたツールセットで運用していた。財務分析エージェントが規制準拠チェックを必要とした場合、準拠ツールを事前インストールする（エージェント間でツールを重複させる）か、準拠エージェントに手動で支援を要求する（調整オーバーヘッドを導入する）必要があった。平均能力発見時間は2.3秒（O(N)線形スキャン）であった。ツールバージョン衝突は週3.7回発生し、手動介入を必要とした。ツール利用率は34% — ほとんどのツールは「所有」エージェントのみがその存在を知っていたため遊休状態であった。
Capability OS導入後. 204のすべてのツールが完全なメタデータ、バージョニング、互換性マトリクスとともにTool Registryに登録された。Command Registryは54エージェント全体で89の正規コマンドをマッピングした。Capability Graphは312の能力ノード（204プリミティブ + 108複合）と847のエッジを含んでいた。平均能力発見時間は12ms（O(log N)）に低下した。ツールバージョン衝突はゼロに減少した — 互換性マトリクスが競合する割当を防止した。ツール利用率は87.3%に上昇した — 発見プロトコルがすべてのツールをすべてのエージェントに可視化した。
自己拡張の実際. 90日間で、Capability OSはグラフ内の明示的に登録されていない有効な合成パスを特定することで、216の新しい複合能力を自律的に生成した。例えば、OSはZ1の'cash-flow-projection'ツールとZ2の'going-concern-assessment'ツールとZ4の'narrative-synthesis'ツールを組み合わせることで、以前は3フロア間の手動調整を必要としていた複合能力'going-concern-opinion-draft'を作成できることを発見した。この複合能力は過去の監査アウトプットに対して検証され、94.2%の精度でデプロイされた。
12. 従来のオペレーティングシステムとの比較
Capability OSは従来のOSと意図的な類似点を持つが、相違点は類似点と同様に示唆に富む。
| 従来のOS概念 | Capability OSのアナログ | 主要な違い |
|---|---|---|
| プロセス | エージェント | エージェントは目標、好み、評判を持つ |
| システムコール | 能力クエリ | クエリは構文的だけでなく意味的 |
| ファイルシステム | Tool Registry | ツールはバージョン、依存関係、互換性制約を持つ |
| プロセススケジューラ | 能力アロケータ | 割当は公平性、親和性、局所性を考慮 |
| 共有メモリ | Capability Graph | データ共有だけでなく合成を可能にする共有構造 |
| デバイスドライバ | ツールアダプタ | ツールバージョンとエージェントインターフェース間の変換 |
| パッケージマネージャ | ライフサイクルマネージャ | インストール時だけでなく実行時に動作 |最も重要な違いは意味層である。従来のOSは構文的な契約で動作する — システムコールには固定されたシグネチャがあり、ファイルパスは文字列であり、プロセスIDは整数である。Capability OSは意味的な契約で動作する — 能力クエリは意図を表現し、ツールの互換性は機能的等価性で評価され、合成は意味的一貫性で検証される。この意味層が自己拡張特性を可能にするものである：OSは明示的にプログラムされなかった能力関係について推論できる。
13. 将来方向：自己最適化するCapability Graph
現在のCapability OSアーキテクチャはエージェントによって登録された能力を管理する。次のフロンティアは、自らの構造を積極的に最適化するCapability OS — 需要パターンに基づいてCapability Graphを再編成し、必要になりそうな能力を先制的に合成し、もはや有用でない能力を非推奨化する — である。
需要駆動型再構築. 発見クエリパターンを分析することで、OSは能力ギャップ — 頻繁に要求されるが既存の能力では十分にサービスされないタスク — を特定できる。ギャップが検出されると、OSは(a) ギャップを埋める外部ツールを検索してその取得を推奨するか、(b) 既存の能力を新しい方法で合成してギャップをカバーすることを試みることができる。これにより、Capability OSは受動的なレジストリから能動的な能力ストラテジストに変換される。
予測的合成. OSが能力A、B、Cが頻繁に一緒に発見・割当されることを観察した場合、複合能力'ABC'を先制的に作成し合成プランをキャッシュできる。次にエージェントが3つすべてを必要とした際、3つの個別の発見・割当サイクルのオーバーヘッドなしに複合が即座に利用可能になる。
G^*(t+1) = \arg\min_{G'} \left[ \sum_{q \in Q(t)} T_{\text{discover}}(q, G') + \lambda \cdot |V(G')| \right]ここでG*(t+1)は時刻t+1での最適グラフ構造、Q(t)は時刻tで観測されたクエリ集合、T_discoverはグラフG'におけるクエリqの発見遅延、λはグラフの複雑さにペナルティを課す正則化パラメータ（グラフの無制限な成長を防止）である。
能力メタボリズム. 生物において使用されない細胞はリサイクルされる。同様に、長期間発見や割当が行われていない能力は非推奨化の候補となるべきである。OSは各能力の「代謝率」 — デプロイ以降の時間に対する割当イベントの比率 — を実装できる。代謝率が閾値を下回る能力はレビューと潜在的非推奨化のためにフラグ付けされ、能力表面を簡潔で発見可能な状態に保つ。
自己最適化するCapability Graphはガバナンス制約の下で動作しなければならない。OSはコンプライアンス規制やセーフティクリティカルなワークフローに必要な能力を自律的に非推奨化することはできない。すべての最適化決定はMARIA OS Responsibility Gateフレームワークを通過しなければならず、能力の進化が組織のアカウンタビリティを決して損なわないことを保証する。14. 結論
Agent Capability OSは、組織が小規模エージェントチームを超えてスケールする際に顕在化するマルチエージェントアーキテクチャのギャップに対処する。個々のエージェントが自身の能力を管理する方式は5〜10体の規模では機能する。50体では調整オーバーヘッドが支配的になる。500体ではOSレベルの抽象化なしには管理不能である。
3つのレジストリ — Command、Tool、Capability Graph — は関心事を明確に分離するレイヤードアーキテクチャを提供する：インターフェース（どのコマンドが存在するか）、実装（どのツールがそれを満たすか）、構造（能力がどう合成されるか）。この分離により各レイヤーが独立して進化でき、明確に定義された契約を通じて一貫性を維持する。
数学的フレームワーク — 能力圏、組織知性の成長、最適グラフ再構築 — は能力管理について推論するための厳密な基盤を提供する。特に圏論的定式化は、合成が明確に定義され、組織単位間の能力移植が構造的完全性を保存することを保証する。
ケーススタディは、Capability OSが理論的な演習ではないことを示す。200以上のツールを持つ54体エージェント監査事務所は、発見遅延（2.3秒から12ミリ秒）、ツール利用率（34%から87.3%）、衝突率（週3.7回からゼロ）において劇的な改善を達成した。最も重要なのは、自己拡張特性 — 90日間で216の複合能力の自律的生成 — が、OSレベルの能力管理が個々のエージェント能力の総和を超える組織知性を可能にするというコアテーゼを検証したことである。
エージェント組織の未来は、より多くのエージェントやより優れたエージェントを持つことだけではない。組織全体の能力表面を管理するOS — 個々のエージェントや人間の管理者では匹敵できないペースと複雑さで能力を発見・合成・割当・進化させるOS — を持つことである。Agent Capability OSはその未来の基盤である。