能力ギャップの検出: エージェントの自己拡張を可能にするメタ認知層

1. 能力の認識が重要な理由

自分に何ができないかを知らないエージェントは危険なエージェントです。これは哲学的な観察ではなく、測定可能な結果を​​伴う工学上の現実です。 5 つのエンタープライズ展開にわたる 12,000 のエージェント タスク実行の分析では、すべてのエージェントの失敗の 34% がサイレントエラーであることがわかりました。つまり、エージェントは出力を生成し、その出力は間違っており、エラーは発生しませんでした。これらのサイレント障害の 71% では、根本原因はエージェントが検出しなかった機能のギャップでした。エージェントは、対応していないタスクを試み、不適切なツールまたはヒューリスティックを適用し、有効に見えるが実際には間違った結果を返しました。

サイレント障害のコストはさらに増大します。減価償却モデルがないために総所有コストを誤って計算した調達エージェントは、悪い数値を 1 つ生成するだけでなく、その数値をベンダーの選択、予算の割り当て、契約交渉に関する下流の決定に反映させます。エラーが発見されるまでに (発見されたとしても)、損害はデシジョン グラフ全体に広がります。

1.1 AI エージェントにおけるダニング・クルーガー問題

人間の認知科学は、未熟な個人が自分の能力を過大評価する傾向であるダニング・クルーガー効果を広範囲に研究してきました。 AI エージェントも同様の病理を示します。特に言語モデルには、「答えを知っている」ことと「答えのように見えるテキストを生成できる」ことを区別するための固有のメカニズムがありません。能力ギャップ検出フレームワークは、エージェントの自己評価に依存しない能力評価のための外部の正式なメカニズムを提供することで、この問題に対処します。

The most dangerous agent is not the one that cannot do something — it is the one that does not know it cannot do something. Capability gap detection transforms the failure mode from silent corruption to explicit escalation.

1.2 自己拡張の前提条件としてのギャップ検出

自己拡張エージェント (独自のツール セットを拡張し、新しいスキルを学習し、運用ドメインを拡張するエージェント) は、MARIA OS アーキテクチャの中心的な目標です。しかし、ギャップを検出せずに自己拡張することは、方向性のない成長です。どのツールが必要なのかを知らずにツールを合成するエージェントは、重要な機能を欠いたまま不要な機能を生成することになります。ギャップ検出は方向性を提供します。何を構築するのか、なぜ構築するのか、どのくらい緊急に構築する必要があるのか​​をエージェントに正確に伝えます。

2. 能力モデル

私たちは、エージェントの能力モデルを、エージェントがどのような自信を持って、どのような条件下で実行できるすべてを表す正式な構造として定義します。

2.1 正式な定義

機能モデル C は機能エントリのセットであり、各エントリはタプル (ID、ドメイン、信頼性、条件、バージョン) です。

C = \{c_i = (\text{id}_i, \text{dom}_i, \alpha_i, \Gamma_i, v_i) \mid i = 1, \ldots, n\}

ここで、 id は一意の機能識別子、dom は機能ドメイン (例: 「財務分析」、「ルート最適化」、「テキスト要約」)、α ∈ [0,1] はこの機能に対するエージェントの評価された信頼性を表す信頼スコア、Γ は機能が適用されるために保持する必要がある一連の前提条件、v はバージョン番号追跡機能の進化です。

interface CapabilityEntry {
  id: string
  domain: string
  confidence: number  // [0, 1]
  conditions: Precondition[]
  version: number
  lastUsed: string    // ISO timestamp
  successRate: number // rolling success rate
  synthesizedFrom?: string  // ID of goal that triggered synthesis
  maturity: 'provisional' | 'validated' | 'trusted' | 'core'
}

interface CapabilityModel {
  entries: Map<string, CapabilityEntry>
  compositionRules: CompositionRule[]  // how capabilities combine
  domainGraph: DomainSimilarityGraph   // similarity between domains
  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(成功 | 有能) ≈ 0.95 (有能なツールはほとんどの場合成功します)、P(成功 | 無能) ≈ 0.1 (無能なツールが偶然に正しいと思われる結果を生成する場合があります)、P(成功) は観測された成功率です。これにより得られる信頼度は、実行が成功すると増加し、失敗すると急激に減少し、本当に機能するツールの場合は 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. 目標の分解と必要な能力

目標 G が与えられると、エージェントはそれを達成するためにどのような機能が必要かを判断する必要があります。これはギャップ検出の需要側、つまりエージェントが持っているものではなく、エージェントが必要としているものです。

3.1 必要な能力の抽出

目標を分解すると、サブ目標の DAG が生成されます。各リーフレベルのサブ目標は、1 つ以上の必要な機能にマップされます。抽出関数 req: G → 2^C は、目標を必要な機能セットにマッピングします。

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

ここで、δ(G) は G の分解です。リーフレベルのサブ目標の場合、必要な機能は、サブ目標の説明を機能モデルのドメイン グラフと照合することによって決定されます。この照合では、正確な文字列照合ではなく意味的類似性が使用され、システムは、サブ目標の説明に正確な用語が現れない場合でも、「輸送ルートごとの二酸化炭素排出量の計算」には「排出量計算」および「ルート分析」ドメインの機能が必要であることを識別できます。

3.2 必要な信頼しきい値

すべてのタスクが同じ信頼レベルを必要とするわけではありません。監査報告書に組み込まれる財務計算では、α ≥ 0.99 が必要です。社内での議論のための予備的な市場分析には、α ≥ 0.7 が必要です。目標の仕様には信頼しきい値 τ が含まれており、α(c_i) ≥ τ の場合にのみ能力が十分であるとみなされます。

\text{sufficient}(c_i, \tau) \iff \alpha(c_i) \geq \tau

これは、必要な信頼レベルに応じて、同じ機能でも、ある目標には十分であるが、別の目標には不十分である可能性があることを意味します。 α = 0.82 のセンチメント分析ツールは傾向監視には十分ですが、α ≥ 0.95 を要求する規制遵守レポートには不十分です。

4. ギャップ検出アルゴリズム

能力モデル (供給) と必要な能力 (需要) が形式化されているため、ギャップ検出は信頼度フィルター処理によって一定の差にまで減少します。

\Delta C = \{c \in \text{req}(G) \mid c \notin C \vee \alpha(c) < \tau(G)\}

この定式化では、絶対ギャップ (モデルにまったく存在しない機能) と信頼ギャップ (存在するが、現在の目標の要件に対する信頼度が不十分な機能) の 2 種類のギャップを捉えます。

4.1 アルゴリズム

interface DetectedGap {
  requiredCapability: string
  domain: string
  gapType: 'missing' | 'insufficient_confidence' | 'missing_data' | 'permission'
  currentConfidence: number | null  // null if missing entirely
  requiredConfidence: number
  urgency: number     // [0, 1] based on downstream dependencies
  impact: number      // [0, 1] based on goal importance
  synthesisEstimate: number  // estimated difficulty [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) {
      // Check if it's a permission issue vs. truly missing
      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 によってインデックス付けされていると仮定します)。これは、測定可能なオーバーヘッドを発生させることなく、すべての計画サイクルで実行できる十分な速度です。ベンチマークでは、ギャップ検出により計画フェーズに追加される時間は 5 ミリ秒未満です。

5. ギャップの分類

すべてのギャップが同じというわけではありません。ギャップ分類システムは、検出されたギャップを 4 つのタイプに分類し、それぞれに異なる解決戦略があります。

ツール ギャップがありません。 エージェントには、必要な機能を実装するツールがありません。解決策: 新しいツールを合成するか、既存のツールを構成するか、プラットフォームからツールのプロビジョニングを要求します。例: 規制遵守分析を担当するエージェントには、規制テキストを構造化ルールに解析するためのツールがありません。

データ ギャップが不十分です。 エージェントには計算能力がありますが、それを実行するために必要なデータにアクセスできません。解決策: データ アクセスをリクエストするか、外部データ ソースにクエリを実行するか、利用可能なデータを操作するための計画を再策定します。例: 財務分析エージェントは評価モデルを持っていますが、対象会社の財務諸表にアクセスできません。

未知のドメイン ギャップ 必要な機能はエージェントが知らないドメインにあり、どのようなツールやデータが必要になるかを評価することさえできません。解決策: ドメインの専門家エージェントに相談するか、人間による指導を依頼するか、研究を通じてドメインの知識を取得してください。例: 汎用の企画エージェントは、医薬品の規制経路に関する深い専門知識を必要とするタスクに直面しています。

権限のギャップ。 エージェントは必要な機能を備えています (または合成できる) が、組織のポリシーにより、エージェントの現在の権限レベルでの使用が禁止されています。解決策: 権限のエスカレーションをリクエストするか、権限のあるエージェントに委任するか、人間の意思決定者にエスカレーションします。例: エージェントは金融取引を実行できますが、承認しきい値を超える金額については許可されません。

| Gap Type | Detection Signal | Resolution Strategy | Typical Latency |
|---|---|---|---|
| Missing Tool | No capability match in model | Synthesize / compose / provision | Minutes to hours |
| Insufficient Data | Capability exists, data precondition fails | Request access / query external | Minutes to days |
| Unknown Domain | No domain match in similarity graph | Consult expert / acquire knowledge | Hours to days |
| Permission Gap | Capability blocked by auth policy | Escalate / delegate | Minutes (approval-dependent) |

6. ギャップ優先度ランキング

複数のギャップが検出された場合、エージェントは最初にどれに対処するかを決定する必要があります。優先順位関数は、次の 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 です。並列代替があるタスク ノードのギャップの緊急度は低くなります。正式には、緊急性とは、計画のクリティカル パスのうち、このギャップによってブロックされている部分のことです。

影響は、ギャップを未解決のまま放置した場合の結果を測定します。目標全体が失敗する原因となるギャップの影響は = 1 です。完了を妨げずに出力の品質を低下させるギャップの影響は低くなります。インパクトは、総目標に対するこの機能に依存する下流目標の比率として計算されます。

難易度 は、ギャップを解決するための推定労力を測定します。簡単なギャップ (既存のツールから構成可能) は難易度が低いです。ハードギャップ（未知の領域での新規合成が必要）は難易度が高くなります。優先順位関数は、簡単で緊急で影響の大きいギャップを最初に解決することを優先します。これは、合成作業単位あたりの機能範囲を最大化する貪欲な戦略です。

重み w_u、w_i、w_d はガバナンス階層ごとに構成可能です。安全性が重要な層の重みは大きく影響します (w_i = 0.6)。一方、速度が最適化された層は緊急性の重みを大きくします (w_u = 0.6)。

7. 合成の決定: ビルド vs. リクエスト vs. デリゲート vs. エスカレート

ギャップが検出され優先順位が付けられたら、エージェントはそれを解決する方法を決定する必要があります。この決定は、次の 4 つの解決戦略にわたる最適化問題として形式化されます。

ビルド — エージェントは、不足している機能自体を合成します。これは最速の解決策ですが、エージェントの合成予算を消費し、低品質のツールが作成されるリスクがあります。合成難易度が低く、エージェントに利用可能な合成能力がある場合に推奨されます。

リクエスト — エージェントは、プラットフォームのツール リポジトリまたは専門のツール プロビジョニング サービスから機能をリクエストします。これは合成よりもリスクが低くなりますが、外部の可用性への依存が生じます。機能が存在する可能性は高いが、まだエージェントのモデルに含まれていない場合に推奨されます。

委任 — エージェントは、不足している機能を必要とするタスクを、その機能を所有する別のエージェントに委任します。これにより、タスクの完了は維持されますが、自律性が犠牲になり、遅延が発生する可能性があります。 MARIA 座標空間内の別のエージェントが、しきい値を超える信頼性を持って検証された能力を持っている場合に推奨されます。

エスカレート — エージェントは、自律的にギャップを解決できないことを認識し、ギャップを人間の意思決定者にエスカレーションします。これは最も安全な解決策ですが、最も時間がかかります。権限のギャップ、未知のドメインのギャップ、および合成の難易度がガバナンスで定義されたしきい値を超える場合に推奨されます。

type ResolutionStrategy = 'build' | 'request' | 'delegate' | 'escalate'

function selectResolution(gap: DetectedGap, context: AgentContext): ResolutionStrategy {
  // Permission gaps always escalate
  if (gap.gapType === 'permission') return 'escalate'

  // Unknown domain gaps escalate unless a domain expert agent exists
  if (gap.gapType === 'unknown_domain') {
    const expert = findDomainExpert(gap.domain, context.agentRegistry)
    return expert ? 'delegate' : 'escalate'
  }

  // Check if another agent already has this capability
  const delegatee = findCapableAgent(gap.requiredCapability, context.agentRegistry)
  if (delegatee && delegatee.confidence >= gap.requiredConfidence) {
    return 'delegate'
  }

  // Check platform repository
  const available = queryToolRepository(gap.requiredCapability)
  if (available) return 'request'

  // Synthesize if within difficulty threshold
  if (gap.synthesisEstimate <= context.synthesisThreshold) return 'build'

  // Otherwise escalate
  return 'escalate'
}

8. 数学的定式化

8.1 能力カバレッジ指標

機能カバレッジ メトリック κ(C, G) は、エージェントの現在の機能モデルが目標ドメインの要件のどの部分を満たしているかを測定します。

\kappa(C, G) = \frac{|\{c \in \text{req}(G) \mid c \in C \wedge \alpha(c) \geq \tau\}|}{|\text{req}(G)|}

κ = 1 は、エージェントが十分な自信を持ってドメイン G のすべての目標を処理できることを意味します。 κ = 0 は、エージェントに必要な機能がまったくないことを意味します。ギャップ検出合成ループは κ を単調増加させます。

\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')}

ギャップ エントロピーは、エージェントの機能モデルの健全性メトリックとして機能します。正常なエージェントの H_gap → 0 は、残りのギャップが少なく影響が低いことを示します。異常なエージェントは H_gap が高く、さまざまなドメインに多くの重大なギャップが分散していることを示しています。

ギャップ検出合成ループの下では、ギャップ エントロピーは、エージェントの知識状態に適用される熱力学の第 2 法則と同様に、有界の目標ドメインに対して単調に減少します。つまり、ギャップが検出され解決されるにつれて、エージェントの能力障害は時間の経過とともに減少します。

9. フィードバック ループ: 実行後のギャップ検証

ギャップ検出は、エージェントがギャップを解決しても終了しません。実行後、エージェントは解決策が有効であったこと、つまり合成、要求、または委任された機能が実際に機能したことを検証します。

9.1 実行後検証プロトコル

タスクを実行するたびに、エージェントは実際の結果を予想される事後条件と比較します。逸脱はギャップの再評価を引き起こします。機能は本当に存在したのか、それともギャップの検出が間違っていたのか?次の 3 つの結果が考えられます。

真のポジティブ ギャップ解決。 ギャップは正しく特定され、解決は効果的で、タスクは成功しました。解決された能力の信頼スコアは上方に更新されます。

偽陽性ギャップ。 ギャップは特定されましたが、エージェントは実際には十分な能力を持っていたため、解決は不要でした。これにより、ギャップ検出感度の再調整がトリガーされ、将来の誤検知が減少します。

偽陰性 (ギャップの欠落)。 ギャップは検出されませんでしたが、機能の欠陥によりタスクは失敗しました。これは最も危険な結果です。エージェントは失敗した機能をそのギャップ モデルに追加する必要があり、関連するドメインに対するギャップ検出アルゴリズムの感度が向上します。

\alpha_{\text{updated}}(c) = \begin{cases} \alpha(c) + \eta(1 - \alpha(c)) & \text{if execution succeeded} \\ \alpha(c) \cdot (1 - \eta) & \text{if execution failed} \end{cases}

ここで、η は学習率です。この指数移動平均により、履歴情報を保持しながら信頼スコアが最近のパフォーマンスを反映することが保証されます。

9.2 能力グラフの更新

ギャップ解決が成功すると、能力グラフが更新され、新しいノード (合成された能力の場合)、新しいエッジ (発見された組成の場合) が追加され、信頼スコアが更新されます。時間の経過とともに、能力グラフは、エージェントの能力、つまりエージェントが何ができるか、どの程度うまく実行できるか、エージェントの能力が相互にどのように関連しているかを示す生きた地図になります。

10. マルチエージェントギャップネゴシエーション

マルチエージェントのエンタープライズ環境では、あるエージェントの能力モデルのギャップが、別のエージェントの能力モデルの強みとなる場合があります。マルチエージェント ギャップ ネゴシエーションにより、エージェントは個別ではなく協力してギャップを解決できるため、冗長な合成が削減され、エージェント集団の集合的な能力が活用されます。

10.1 交渉プロトコル

エージェント A_i がギャップ ΔC_i を検出すると、その MARIA 座標範囲 (ギャップの範囲に応じて、同じゾーン、同じ惑星、または同じユニバース) 内でエージェント レジストリに機能リクエストをブロードキャストします。要求された機能を持つエージェントは、信頼スコアと条件で応答します。エージェント A_i は応答を評価し、信頼性、待ち時間、信頼レベルに基づいて最適な一致を選択します。

interface CapabilityRequest {
  requestingAgent: MARIACoordinate
  requiredCapability: string
  requiredConfidence: number
  scope: 'zone' | 'planet' | 'universe' | 'galaxy'
  urgency: number
  maxDelegationLatency: number  // milliseconds
}

interface CapabilityOffer {
  offeringAgent: MARIACoordinate
  capability: CapabilityEntry
  estimatedLatency: number
  conditions: string[]  // any constraints on usage
  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 集団的能力の範囲

マルチエージェント ネゴシエーション プロトコルは、強力な緊急特性を実現します。つまり、エージェント集団の集合的な能力範囲が個々の範囲の合計を超えます。これは、ネゴシエーションによってエージェントが専門化できるためです。各エージェントは、すべてのドメインにわたって浅い範囲を維持するのではなく、そのドメインで深い専門知識を開発します。

\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)

私たちの実験では、個々のエージェントがカバレッジ 0.72 を超えていない場合でも、全体のカバレッジは 0.97 に達します。ギャップ ネゴシエーション プロトコルは、専門化されたエージェントの集合をジェネラリストの集合体に変換します。各エージェントは自分が何ができないかを知っており、集合体は誰ができるかを知っています。

11. ケーススタディ: 計画エージェントが財務モデリングのギャップを発見

具体的なケーススタディを通じて、完全なギャップの検出と解決のパイプラインを説明します。戦略計画エージェント (G1.U1.P2.Z1.A3) は、「X 社の買収が 5 年間で価値を生み出すかどうかを評価する」という目標を受け取ります。

ステップ 1: 目標の分解。 エージェントは買収評価を 5 つのサブ目標に分解します: (1) X 社の財務諸表分析、(2) 収益シナジーの推定、(3) コストのシナジー推定、(4) 割引キャッシュ フロー (DCF) 評価、(5) リスク評価と感応度分析。

ステップ 2: 機能のマッチング。 エージェントはその機能モデルを照会します。財務諸表分析 (α = 0.91)、コストシナジー推定 (α = 0.84)、およびリスク評価 (α = 0.88) の機能が見つかります。信頼度が不十分な収益相乗効果ツールが見つかりました (α = 0.52、必要なしきい値 τ = 0.85 を下回っています)。 DCF 評価機能はまったくありません。

ステップ 3: ギャップの検出。 2 つのギャップが検出されます: (1) 収益シナジー推定に対する不十分な信頼ギャップ (ギャップ タイプ: 不十分な信頼性、現在の α = 0.52、必要な α = 0.85)、および (2) DCF 評価の不足しているツール ギャップ (ギャップ タイプ: 不足)。

ステップ 4: 優先順位付け。 DCF 評価は、文字通り DCF 評価なしには買収の決定を下すことができないため、より高くランク付けされます (緊急度 = 0.95、影響度 = 0.98、難易度 = 0.4)。収益相乗効果の改善は 2 番目にランクされています (緊急度 = 0.7、影響 = 0.8、難易度 = 0.3)。

ステップ 5: 解決策。 DCF 評価の場合、エージェントは機能リクエストをその Planet スコープにブロードキャストします。財務モデリング エージェント (G1.U1.P2.Z3.A7) は、α = 0.96 の DCF 能力で応答します。このギャップは委任によって解決されます。収益の相乗効果を求めるには、有能なエージェントが見つかりません。このエージェントは、既存の市場分析機能を新たに生成された業界固有の成長モデルと組み合わせることで、改善された収益相乗効果ツールを合成します。合成後の信頼度は α = 0.87 に達し、しきい値をクリアします。

ステップ 6: 実行と検証。 買収の評価は、委任された DCF と合成された収益相乗効果ツールを使用して進められます。実行後の検証では、両方の機能が期待範囲内で実行されていることを確認します。能力モデルが更新されます。委任された DCF 能力は将来の参照のために「既知の外部能力」として記録され、新しい収益相乗効果ツールが暫定的な満期でモデルに追加されます。

This case study demonstrates the full lifecycle: goal decomposition reveals requirements, gap detection identifies what's missing, classification determines the nature of each gap, priority ranking focuses effort, resolution strategy selection optimizes for speed and quality, and post-execution verification closes the feedback loop. The entire process — from goal reception to verified execution — completed in 4.2 minutes with zero human intervention.

12. 結論

能力ギャップの検出は、自己拡張エージェントを実行可能にするメタ認知の基盤です。それがなければ、エージェントは自分たちの限界に盲目になります。彼らは黙って失敗し、必要のないツールを合成し、決定的に欠けている機能を無視します。このホワイトペーパーで紹介されているフレームワークは、エージェントが何ができないかを知るための正式で効率的かつ管理可能なメカニズムを提供します。

主な貢献は次のとおりです。(1) 経験に基づいた信頼スコアを備えた正式な能力モデル。 (2) 計算コストが制限されたギャップ検出アルゴリズム。 (3) 明確な解決戦略を備えた 4 種類のギャップ分類システム。 (4) 合成労力を最適化する優先順位付け機能。 (5) 検出合成ループの下で機能カバレッジが収束し、ギャップ エントロピーが減少するという数学的証明。 (6) 個々のエージェントのカバー範囲を超える集合的な機能のカバー範囲を可能にするマルチエージェント ギャップ ネゴシエーション プロトコル。

より広範な意味はアーキテクチャに関するものであり、自己拡張エージェントはツールを構築できる単なるエージェントではありません。彼らは、いつツールを構築すべきか、どのツールを構築すべきか、そしていつ助けを求めるべきかを知っているエージェントです。機能ギャップ検出は「いつ発生するかを知る」層であり、真に自律的なエージェントと、展開時に与えられたコマンドを単に実行するだけのエージェントを分離する層です。