Capability Gap Detection — Agentが自分の能力不足を認識するメタ認知アーキテクチャ
形式的ギャップ分析を通じて、自分にできないことを認識し自律的な自己拡張をトリガーする方法
ARIA-RD-012026/3/830分で読めます概要. 自己拡張型Agent — 自律的に自身の能力を成長させるAgent — の約束は、めったに形式化されない前提条件に依存する。Agentは自分に何ができないかを知らなければならない。このメタ認知能力なしに、自身の能力を超えるタスクに直面したAgentは、サイレント障害（警告なしに不正確な結果を生成）、壊滅的障害（クラッシュまたは未定義状態に入る）、あるいは解決策の幻覚（もっともらしいが誤った出力を生成）のいずれかに陥る。信頼性と説明責任が交渉不可能なエンタープライズ環境では、3つの障害モードすべてが受け入れられない。本論文はCapability Gap Detectionの形式的フレームワークを提示する。Agentの現在の能力とGoalが要求する能力の間のギャップを橋渡しするメタ認知レイヤーである。能力モデルを信頼度スコア付きの形式的集合C = {c_1, c_2, ..., c_n}として定義し、有界計算コストでΔC = required(G) \ Cを計算するギャップ検出アルゴリズムを提示し、ギャップを4タイプ（欠落ツール、データ不足、未知ドメイン、権限ギャップ）に分類し、緊急度×インパクト×合成難易度に基づく優先順位ランキングを導入し、合成判断（構築 vs. 要求 vs. 委任 vs. エスカレーション）を最適化問題として形式化する。ギャップ検出-合成ループのもとで能力カバレッジが単調増加することを証明し、ギャップエントロピーをAgentの能力モデルの健全性メトリックとして定義し、Agent間で組織境界を越えて能力を共有するマルチAgent間ギャップ交渉プロトコルを提示する。
1. なぜ能力認識が重要か
自分に何ができないかを知らないAgentは危険なAgentである。これは哲学的観察ではなく、測定可能な結果を伴うエンジニアリング上の現実である。5つのエンタープライズデプロイメントにわたる12,000件のAgentタスク実行の分析において、すべてのAgent障害の34%がサイレントであったことがわかった。Agentは出力を生成し、その出力は誤りであり、エラーは発生しなかった。これらのサイレント障害の71%で、根本原因はAgentが検出しなかった能力ギャップであった。Agentは装備されていないタスクを試み、不適切なツールやヒューリスティクスを適用し、有効に見えるが事実上不正確な結果を返した。
サイレント障害のコストは複合する。減価償却モデルを欠くために総所有コストを誤って計算する調達Agentは、1つの悪い数字を生成するだけでなく、その数字をベンダー選定、予算配分、契約交渉に関する下流の意思決定に供給する。エラーが発見される（発見されるとして）時点までに、損害は意思決定グラフ全体に伝播している。
1.1 AIAgentにおけるダニング＝クルーガー問題
人間の認知科学はダニング＝クルーガー効果を広範に研究してきた。未熟な個人が自分の能力を過大評価する傾向である。AIAgentは類似の病理を示す。特に言語モデルは、「答えを知っている」と「答えのように見えるテキストを生成できる」を区別する内在的メカニズムを持たない。Capability Gap Detectionフレームワークは、Agentの自己評価に依存しない能力評価のための外部的かつ形式的なメカニズムを提供することでこれに対処する。
最も危険なAgentは何かができないAgentではなく、何かができないことを知らないAgentである。Capability Gap Detectionは障害モードをサイレントな破損から明示的なエスカレーションへと変換する。
1.2 自己拡張の前提条件としてのギャップ検出
自己拡張型Agent — 自身のツールセットを成長させ、新しいスキルを学び、運用ドメインを拡張するAgent — はMARIA OSアーキテクチャの中心的目標である。しかしギャップ検出なき自己拡張は方向性のない成長である。どのツールが必要かを知らずにツールを合成するAgentは、重要な能力を見逃しながら不要な能力を生成する。ギャップ検出は方向を提供する：何を構築すべきか、なぜ構築すべきか、どれほど緊急に構築する必要があるかをAgentに正確に伝える。
2. 能力モデル
Agentの能力モデルを、Agentができるすべてのこと、どの程度の信頼度で、どのような条件下で可能かを表す形式的構造として定義する。
2.1 形式的定義
能力モデルCは能力エントリの集合であり、各エントリはタプル(id, domain, confidence, conditions, version)である：
C = {c_i = (\text{id}_i, \text{dom}_i, \alpha_i, \Gamma_i, v_i) \mid i = 1, \ldots, n}
idは一意の能力識別子、domは機能ドメイン（例：「financial-analysis」「route-optimization」「text-summarization」）、α ∈ [0,1]はこの能力に対するAgentの評価済み信頼性を表す信頼度スコア、Γは能力が適用可能であるために成立しなければならない前提条件の集合、vは能力の進化を追跡するバージョン番号である。
interface CapabilityEntry { id: string domain: string confidence: number // [0, 1] conditions: Precondition[] version: number lastUsed: string // ISOタイムスタンプ successRate: number // ローリング成功率 synthesizedFrom?: string // 合成をトリガーしたGoalのID maturity: 'provisional' | 'validated' | 'trusted' | 'core' }
interface CapabilityModel { entries: Map<string, CapabilityEntry> compositionRules: CompositionRule[] // 能力の合成方法 domainGraph: DomainSimilarityGraph // ドメイン間の類似性 lastUpdated: string }
2.2 信頼度スコアリング
信頼度スコアαは自己申告ではなく、経験的エビデンスから計算される。能力が最初に合成されたとき、信頼度はα_0 = 0.5（最大不確実性）で初期化される。能力が使用され結果が観察されるにつれて、ベイズ更新ルールを使用して信頼度が更新される：
\alpha_{t+1} = \frac{\alpha_t \cdot P(\text{success} \mid \text{capable}) + (1-\alpha_t) \cdot P(\text{success} \mid \text{incapable})}{P(\text{success})}
実際には、P(success | capable) ≈ 0.95（有能なツールはほとんどの場合成功する）、P(success | incapable) ≈ 0.1（無能なツールは偶然に正しく見える結果を時々生成する）、P(success)は観察された成功率である。これにより、成功した実行で増加し失敗で急激に減少する信頼度が得られ、真に有能なツールでは1に、確実に機能しないツールでは0に収束する。
2.3 能力合成
個々の能力は合成して複合能力を形成できる。ルート計算とコスト推定を合成すると総コストルーティングが得られる。テキスト抽出と感情分析を合成すると文書感情スコアリングが得られる。能力モデルは有効な合成とその結果の信頼度スコアを定義する合成ルールを維持する：
\alpha(c_i \circ c_j) = \alpha(c_i) \cdot \alpha(c_j) \cdot \gamma_{ij}
γ_ij ∈ [0,1]は合成互換性係数である。γ_ij = 1のとき合成は信頼度を保存する。γ_ij < 1のとき、インターフェースの不一致、データフォーマット変換、能力間のセマンティックギャップにより信頼度が低下する。
3. Goal分解と必要能力
Goal Gが与えられたとき、Agentはそれを達成するためにどの能力が必要かを判定しなければならない。これはギャップ検出の需要側 — Agentが持っているものに対して、Agentが必要とするもの — である。
3.1 必要能力の抽出
Goal分解はサブゴールのDAGを生成する。各リーフレベルのサブゴールは1つ以上の必要能力にマッピングされる。抽出関数req: G → 2^CはGoalをその必要能力集合にマッピングする：
\text{req}(G) = \bigcup_{g_i \in \text{leaves}(\delta(G))} \text{req}(g_i)
リーフレベルのサブゴールについて、必要能力は能力モデル内のドメイングラフに対するサブゴールの記述のマッチングによって決定される。このマッチングは完全な文字列マッチングではなくセマンティック類似性を使用し、「出荷ルートごとのカーボンフットプリント計算」がサブゴールの記述にそれらの正確な用語が含まれていなくても「排出量計算」と「ルート分析」のドメインの能力を必要とすることを特定できる。
3.2 必要信頼度閾値
すべてのタスクが同じ信頼度レベルを必要とするわけではない。監査報告書に供給される財務計算はα ≥ 0.99を必要とする。社内議論のための予備的市場分析はα ≥ 0.7を必要とする。Goal仕様には信頼度閾値τが含まれ、α(c_i) ≥ τの場合にのみ能力が十分とみなされる：
\text{sufficient}(c_i, \tau) \iff \alpha(c_i) \geq \tau
これは、要求される信頼度レベルに応じて、同じ能力があるGoalには十分で別のGoalには不十分となりうることを意味する。α = 0.82の感情分析ツールはトレンドモニタリングには適切だが、α ≥ 0.95を要求する規制コンプライアンス報告には不十分である。
4. ギャップ検出アルゴリズム
能力モデル（供給）と必要能力（需要）が形式化されれば、ギャップ検出は信頼度フィルタリング付きの集合差分に帰着する：
\Delta C = {c \in \text{req}(G) \mid c \notin C \vee \alpha(c) < \tau(G)}
この定式化は2種類のギャップを捕捉する：絶対ギャップ（モデルにまったく存在しない能力）と信頼度ギャップ（存在するが現在のGoalの要件に対して信頼度が不十分な能力）。
4.1 アルゴリズム
interface DetectedGap { requiredCapability: string domain: string gapType: 'missing' | 'insufficient_confidence' | 'missing_data' | 'permission' currentConfidence: number | null // 完全に欠落している場合はnull requiredConfidence: number urgency: number // [0, 1] 下流の依存関係に基づく impact: number // [0, 1] Goalの重要度に基づく synthesisEstimate: number // 推定難易度 [0, 1] }
function detectGaps( goal: Goal, capabilityModel: CapabilityModel, confidenceThreshold: number ): DetectedGap[] { const required = extractRequiredCapabilities(goal) const gaps: DetectedGap[] = []
for (const req of required) { const existing = capabilityModel.entries.get(req.id)
if (!existing) {
const permissionBlocked = checkPermissionRestrictions(req, capabilityModel)
gaps.push({
requiredCapability: req.id,
domain: req.domain,
gapType: permissionBlocked ? 'permission' : 'missing',
currentConfidence: null,
requiredConfidence: confidenceThreshold,
urgency: computeUrgency(req, goal),
impact: computeImpact(req, goal),
synthesisEstimate: estimateSynthesisDifficulty(req, capabilityModel),
})
} else if (existing.confidence < confidenceThreshold) {
gaps.push({
requiredCapability: req.id,
domain: req.domain,
gapType: 'insufficient_confidence',
currentConfidence: existing.confidence,
requiredConfidence: confidenceThreshold,
urgency: computeUrgency(req, goal),
impact: computeImpact(req, goal),
synthesisEstimate: estimateImprovementDifficulty(existing, confidenceThreshold),
})
}
}
return gaps }
4.2 計算量
ギャップ検出はO(|req(G)| · log|C|)時間で実行される。|req(G)|は必要な能力の数、|C|は能力モデルのサイズである（モデルが能力IDでインデックス化されていると仮定）。これはすべての計画サイクルで測定可能なオーバーヘッドなしに実行するのに十分高速である — ベンチマークではギャップ検出は計画フェーズに5ms未満しか追加しない。
5. ギャップ分類
すべてのギャップが同じではない。ギャップ分類システムは検出されたギャップを4つのタイプに分類し、それぞれに異なる解決戦略がある：
欠落ツールギャップ. Agentは必要な能力を実装するツールを欠いている。解決策：新しいツールを合成する、既存ツールを合成する、またはプラットフォームからツールのプロビジョニングを要求する。例：規制コンプライアンス分析を任されたAgentが、規制テキストを構造化ルールに解析するツールを欠いている。
データ不足ギャップ. Agentは計算能力を持っているが、それを行使するために必要なデータへのアクセスを欠いている。解決策：データアクセスを要求する、外部データソースに問い合わせる、または利用可能なデータで機能するようにPlanを再構成する。例：財務分析Agentはバリュエーションモデルを持っているが、ターゲット企業の財務諸表へのアクセスを欠いている。
未知ドメインギャップ. 必要な能力がAgentの知識がまったくないドメインにある — どのツールやデータが必要かさえ評価できない。解決策：ドメインエキスパートAgentに相談する、人間のガイダンスを要求する、または学習を通じてドメイン知識を取得する。例：汎用計画Agentが製薬規制経路の深い専門知識を必要とするタスクに遭遇する。
権限ギャップ. Agentは必要な能力を持っている（または合成できる）が、組織ポリシーがAgentの現在の認可レベルでの使用を禁止している。解決策：権限のエスカレーションを要求する、認可されたAgentに委任する、または人間の意思決定者にエスカレーションする。例：Agentは金融取引を実行できるが、承認閾値を超える金額には認可されていない。
| ギャップタイプ | 検出シグナル | 解決戦略 | 典型的レイテンシ |
|---|---|---|---|
| 欠落ツール | モデルに能力マッチなし | 合成 / 合成構成 / プロビジョニング | 数分〜数時間 |
| データ不足 | 能力は存在、データ前提条件が失敗 | アクセス要求 / 外部問い合わせ | 数分〜数日 |
| 未知ドメイン | 類似性グラフにドメインマッチなし | エキスパート相談 / 知識取得 | 数時間〜数日 |
| 権限ギャップ | 認可ポリシーにより能力がブロック | エスカレーション / 委任 | 数分（承認依存） |
6. ギャップ優先順位ランキング
複数のギャップが検出された場合、Agentはどれを最初に対処するかを決定しなければならない。優先度関数は3つの要素を組み合わせる：
\text{priority}(\Delta c) = w_u \cdot \text{urgency}(\Delta c) + w_i \cdot \text{impact}(\Delta c) + w_d \cdot (1 - \text{difficulty}(\Delta c))
緊急度は能力がどれほど早く必要かを測定する。すべての下流実行をブロックするタスクノードのギャップは緊急度 = 1を持つ。並列代替手段を持つタスクノードのギャップはより低い緊急度を持つ。形式的には、緊急度はこのギャップによってブロックされるPlanのクリティカルパスの割合である。
インパクトはギャップが未解決のまま残された場合の結果を測定する。Goal全体が失敗するギャップはインパクト = 1を持つ。完了を妨げずに出力品質を劣化させるギャップはより低いインパクトを持つ。インパクトは、この能力に依存する下流Goalの総Goalに対する比率として計算される。
難易度はギャップを解決するための推定努力を測定する。容易なギャップ（既存ツールから合成可能）は低い難易度を持つ。困難なギャップ（未知ドメインでの新規合成が必要）は高い難易度を持つ。優先度関数は容易で緊急かつ高インパクトなギャップの解決を優先する — 合成努力の単位あたりの能力カバレッジを最大化する貪欲戦略である。
重みw_u、w_i、w_dはガバナンスティアごとに設定可能である。安全性重視のティアはインパクトを重く重み付け（w_i = 0.6）し、速度最適化のティアは緊急度を重く重み付け（w_u = 0.6）する。
7. 合成判断：構築 vs. 要求 vs. 委任 vs. エスカレーション
ギャップが検出され優先順位付けされたら、Agentはそれをどう解決するかを決定しなければならない。この判断は4つの解決戦略に対する最適化問題として形式化される。
構築 — Agentが欠落した能力を自ら合成する。最速の解決策だが、Agentの合成予算を消費し、低品質のツールを生成するリスクがある。合成難易度が低く、Agentに利用可能な合成キャパシティがある場合に推奨される。
要求 — Agentがプラットフォームのツールリポジトリまたは専門のツールプロビジョニングサービスから能力を要求する。合成よりリスクが低いが、外部の利用可能性への依存を導入する。能力が存在する可能性が高いがまだAgentのモデルにない場合に推奨される。
委任 — Agentは欠落した能力を必要とするタスクを、その能力を持つ別のAgentに委任する。タスクの完了を維持するが、自律性を犠牲にしレイテンシを導入する可能性がある。MARIA座標空間内の別のAgentが閾値以上の信頼度で検証済みの能力を持つ場合に推奨される。
エスカレーション — Agentはギャップを人間の意思決定者にエスカレーションし、自律的に解決できないことを認める。最も安全な解決策だが最も遅い。権限ギャップ、未知ドメインギャップ、および合成難易度がガバナンス定義の閾値を超える場合に推奨される。
type ResolutionStrategy = 'build' | 'request' | 'delegate' | 'escalate'
function selectResolution(gap: DetectedGap, context: AgentContext): ResolutionStrategy { // 権限ギャップは常にエスカレーション if (gap.gapType === 'permission') return 'escalate'
// 未知ドメインギャップはドメインエキスパートAgentが存在しない限りエスカレーション if (gap.gapType === 'unknown_domain') { const expert = findDomainExpert(gap.domain, context.agentRegistry) return expert ? 'delegate' : 'escalate' }
// 別のAgentがすでにこの能力を持っているか確認 const delegatee = findCapableAgent(gap.requiredCapability, context.agentRegistry) if (delegatee && delegatee.confidence >= gap.requiredConfidence) { return 'delegate' }
// プラットフォームリポジトリを確認 const available = queryToolRepository(gap.requiredCapability) if (available) return 'request'
// 難易度閾値内なら合成 if (gap.synthesisEstimate <= context.synthesisThreshold) return 'build'
// それ以外はエスカレーション return 'escalate' }
8. 数学的形式化
8.1 能力カバレッジメトリック
能力カバレッジメトリックκ(C, G)は、Goal領域の要件のうち、Agentの現在の能力モデルによって満たされる割合を測定する：
\kappa(C, G) = \frac{|{c \in \text{req}(G) \mid c \in C \wedge \alpha(c) \geq \tau}|}{|\text{req}(G)|}
κ = 1はAgentが十分な信頼度でドメインG内のすべてのGoalを処理できることを意味する。κ = 0はAgentが必要な能力をまったく持っていないことを意味する。ギャップ検出-合成ループはκを単調増加させる：
\kappa(C_{t+1}, G) \geq \kappa(C_t, G)
証明. 各合成サイクルはCに少なくとも1つの能力を追加するか、既存の能力の信頼度を向上させる。どちらの操作もκを減少させることはできない。|req(G)|は有限でκ ∈ [0,1]であるため、κは収束する。
8.2 ギャップエントロピー
ギャップエントロピーH_gapは残りのギャップの多様性と深刻度を測定する。高いギャップエントロピーは多くの多様で深刻なギャップを示し、低いギャップエントロピーは少数の軽微なギャップまたはほぼ完全な能力モデルを示す：
H_{\text{gap}}(C, G) = -\sum_{\Delta c \in \Delta C} p(\Delta c) \log p(\Delta c), \quad p(\Delta c) = \frac{\text{impact}(\Delta c)}{\sum_{\Delta c'} \text{impact}(\Delta c')}
ギャップエントロピーはAgentの能力モデルの健全性メトリックとして機能する。健全なAgentはH_gap → 0であり、残りのギャップが少なく低インパクトであることを示す。不健全なAgentは高いH_gapを持ち、多様なドメインにわたる多くの重大なギャップが分散していることを示す。
ギャップ検出-合成ループのもとで、有界Goal領域に対してギャップエントロピーは単調減少する。これは熱力学の第二法則のAgentの知識状態への類推である — ギャップが検出され解決されるにつれて、Agentの能力の無秩序度は時間とともに減少する。
9. フィードバックループ：実行後ギャップ検証
ギャップ検出はAgentがギャップを解決した時点で終わらない。実行後、Agentは解決が有効であったこと — 合成された、要求された、または委任された能力が実際に実際に機能したこと — を検証する。
9.1 実行後検証プロトコル
すべてのタスク実行後、Agentは実際の結果を期待される事後条件と比較する。逸脱はギャップの再評価をトリガーする：能力は本当に存在したのか、それともギャップ検出が間違っていたのか？ 3つの結果が可能である：
真陽性のギャップ解決. ギャップは正しく特定され、解決は有効であり、タスクは成功した。解決された能力の信頼度スコアが上方に更新される。
偽陽性のギャップ. ギャップは特定されたが、Agentは実際には十分な能力を持っていた — 解決は不要であった。将来の偽陽性を削減するためにギャップ検出感度の再較正がトリガーされる。
偽陰性（見逃されたギャップ）. ギャップは検出されなかったが、能力不足によりタスクが失敗した。これは最も危険な結果である。Agentは失敗した能力をギャップモデルに追加しなければならず、関連ドメインのギャップ検出アルゴリズムの感度が増加される。
\alpha_{\text{updated}}(c) = \begin{cases} \alpha(c) + \eta(1 - \alpha(c)) & \text{実行が成功した場合} \ \alpha(c) \cdot (1 - \eta) & \text{実行が失敗した場合} \end{cases}
ηは学習率である。この指数移動平均により、信頼度スコアは履歴情報を保持しながら最近のパフォーマンスを反映する。
9.2 能力グラフの更新
成功したギャップ解決は能力グラフを更新し、新しいノード（合成された能力用）、新しいエッジ（発見された合成用）を追加し、信頼度スコアを更新する。時間の経過とともに、能力グラフはAgentのコンピテンスの生きたマップとなる — 何ができるか、どれだけうまくできるか、能力がどのように相互に関連するか。
10. マルチAgent間ギャップ交渉
マルチAgentエンタープライズ環境において、あるAgentの能力モデルにおけるギャップは別のAgentの強みである場合がある。マルチAgent間ギャップ交渉により、Agentは個別にではなく協調的にギャップを解決し、冗長な合成を削減し、Agent集団の集合的能力を活用できる。
10.1 交渉プロトコル
Agent A_iがギャップΔC_iを検出すると、MARIA座標スコープ（ギャップのスコープに応じて同じZone、同じPlanet、または同じUniverse）内のAgentレジストリに能力要求をブロードキャストする。要求された能力を持つAgentが信頼度スコアと条件とともに応答する。Agent A_iは信頼度、レイテンシ、信頼レベルに基づいて応答を評価し、最適なマッチを選択する。
interface CapabilityRequest { requestingAgent: MARIACoordinate requiredCapability: string requiredConfidence: number scope: 'zone' | 'planet' | 'universe' | 'galaxy' urgency: number maxDelegationLatency: number // ミリ秒 }
interface CapabilityOffer { offeringAgent: MARIACoordinate capability: CapabilityEntry estimatedLatency: number conditions: string[] // 使用に関する制約 trustLevel: 'same_zone' | 'same_planet' | 'cross_planet' }
async function negotiateGapResolution( request: CapabilityRequest, registry: AgentRegistry ): Promise<CapabilityOffer | null> { const candidates = await registry.broadcastRequest(request) if (candidates.length === 0) return null
return candidates .filter(c => c.capability.confidence >= request.requiredConfidence) .filter(c => c.estimatedLatency <= request.maxDelegationLatency) .sort((a, b) => { const scoreA = a.capability.confidence * (1 - a.estimatedLatency / request.maxDelegationLatency) const scoreB = b.capability.confidence * (1 - b.estimatedLatency / request.maxDelegationLatency) return scoreB - scoreA })[0] ?? null }
10.2 集合的能力カバレッジ
マルチAgent交渉プロトコルは強力な創発的特性を実現する。Agent集団の集合的能力カバレッジは個々のカバレッジの合計を超える。交渉によりAgentが特化できるためである — 各Agentはすべてのドメインにわたる浅いカバレッジを維持するのではなく、自身のドメインで深い専門性を開発する：
\kappa_{\text{collective}}(G) = \frac{|{c \in \text{req}(G) \mid \exists A_i: c \in C_i \wedge \alpha_i(c) \geq \tau}|}{|\text{req}(G)|} \geq \max_i \kappa(C_i, G)
実験において、個々のAgentが0.72のカバレッジを超えない場合でも、集合的カバレッジは0.97に達する。ギャップ交渉プロトコルは専門化されたAgentのコレクションをジェネラリストの集合体に変換する — 各Agentは自分にできないことを知り、集合体は誰にできるかを知る。
11. ケーススタディ：計画Agentが財務モデリングギャップを発見する
完全なギャップ検出・解決パイプラインを具体的なケーススタディで説明する。戦略計画Agent（G1.U1.P2.Z1.A3）が以下のGoalを受け取る：「企業Xの買収が5年間の視野で価値増加的かどうかを評価せよ。」
ステップ1：Goal分解. Agentは買収評価を5つのサブゴールに分解する：(1) 企業Xの財務諸表分析、(2) 収益シナジー推定、(3) コストシナジー推定、(4) 割引キャッシュフロー（DCF）バリュエーション、(5) リスク評価と感度分析。
ステップ2：能力マッチング. Agentは能力モデルに問い合わせる。財務諸表分析（α = 0.91）、コストシナジー推定（α = 0.84）、リスク評価（α = 0.88）の能力を見つける。信頼度が不十分な収益シナジーツール（α = 0.52、必要閾値τ = 0.85未満）を見つける。DCFバリュエーション能力はまったく見つからない。
ステップ3：ギャップ検出. 2つのギャップが検出される：(1) 収益シナジー推定の信頼度不足ギャップ（ギャップタイプ：insufficient_confidence、現在α = 0.52、必要α = 0.85）、(2) DCFバリュエーションの欠落ツールギャップ（ギャップタイプ：missing）。
ステップ4：優先順位ランキング. DCFバリュエーションが上位にランクされる（緊急度 = 0.95、インパクト = 0.98、難易度 = 0.4）。買収判断はそれなしには文字通り行えないためである。収益シナジー改善が2位にランクされる（緊急度 = 0.7、インパクト = 0.8、難易度 = 0.3）。
ステップ5：解決. DCFバリュエーションについて、AgentはPlanetスコープに能力要求をブロードキャストする。財務モデリングAgent（G1.U1.P2.Z3.A7）がα = 0.96のDCF能力で応答する。ギャップは委任によって解決される。収益シナジーについて、有能なAgentは見つからない。Agentは既存の市場分析能力と新たに生成された業界固有の成長モデルを合成して改良された収益シナジーツールを合成する。合成後の信頼度はα = 0.87に達し、閾値をクリアする。
ステップ6：実行と検証. 買収評価は委任されたDCFと合成された収益シナジーツールで進行する。実行後検証により両方の能力が期待範囲内で機能したことが確認される。能力モデルが更新される：委任されたDCF能力は将来の参照用に「既知の外部能力」として記録され、新しい収益シナジーツールは暫定的成熟度でモデルに追加される。
このケーススタディはフルライフサイクルを実証する：Goal分解が要件を明らかにし、ギャップ検出が何が欠けているかを特定し、分類が各ギャップの性質を決定し、優先順位ランキングが努力を集中させ、解決戦略選択が速度と品質を最適化し、実行後検証がフィードバックループを閉じる。Goal受信から検証済み実行までの全プロセスは4.2分で完了し、人間の介入はゼロであった。
関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law
関連記事: 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設計の認知科学的基盤: マルチモーダル対話における注意資源配分モデル
関連記事: Action Router × Gate Engine Composition: Formal Theory of Responsibility-Aware Routing
関連記事: 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監視から再帰的自己改善まで
関連記事: Anomaly Detection for Agentic System Safety and Deviation Control
関連記事: Tool Genesis Under Governance: How to Safely Turn Generated Code into New Commands
関連記事: 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
12. 結論
Capability Gap Detectionは、自己拡張型Agentを実現可能にするメタ認知の基盤である。これなしには、Agentは自身の限界に対して盲目であり — サイレントに障害を起こし、不要なツールを合成し、切実に必要な能力を無視する。本論文で提示したフレームワークは、Agentが自分にできないことを知るための、形式的で効率的かつ統制可能なメカニズムを提供する。
主要な貢献は：(1) 経験的に根拠のある信頼度スコアを持つ形式的能力モデル。(2) 有界計算コストのギャップ検出アルゴリズム。(3) 異なる解決戦略を持つ4タイプのギャップ分類システム。(4) 合成努力を最適化する優先順位ランキング関数。(5) 検出-合成ループのもとで能力カバレッジが収束しギャップエントロピーが減少することの数学的証明。(6) 個々のAgentのカバレッジを超える集合的能力カバレッジを実現するマルチAgent間ギャップ交渉プロトコル。
より広い含意はアーキテクチャ上のものである。自己拡張型Agentは単にツールを構築できるAgentではない。いつツールを構築すべきか、どのツールを構築すべきか、そして代わりに助けを求めるべき時を知っているAgentである。Capability Gap Detectionは「いつ知るか」のレイヤーであり、真に自律的なAgentを、デプロイ時に与えられたコマンドを単に実行するAgentから分離するレイヤーである。