AI製品「公称能力 vs 実効能力」辞典

ベンダーのモデル表・製品ページにある context window、tool、connector、Copilot/agent 等の公称能力と、特定の組織・plan・region・surface・identity・policy・quota・runtimeで実際に業務へ投入できる実効能力を分離して記録する。

EA-012は「公称能力が実効能力になるまでに何のgateを通るか」を扱う。EA-011のベンチマーク実験室は各gate通過後の品質・失敗包絡を測る試験機構として参照し、両者を一つの総合scoreへ潰さない。

本稿の8層gate taxonomy、状態遷移、CAPABILITY_RECORD は PROPOSAL / INFERENCE であり、provider仕様そのものではない。

• モデルまたはproviderが公称する能力と、製品surface・契約・組織設定を通過した実効能力をどう分離して記録するか。
• context window・tool use・connector/retrievalについて、「仕様上受理できる」「利用権がある」「実行できる」「業務品質を満たす」をどう区別するか。
• rate limit・spend cap・admin policy・license・identity/permission等は、名目上の機能をどの段階で実効不能または実効縮小させるか。

• 公称能力は単一層ではない。 MODEL_CAPABILITY → API/SERVICE_EXPOSURE → PRODUCT_SURFACE → ENTITLEMENT → ORG_POLICY → IDENTITY/PERMISSION → RUNTIME/CAPACITY → WORKLOAD_ACCEPTANCE を分離する。これはPROPOSAL / INFERENCEであり、provider標準そのものではない。
• context windowと実効利用品質を同一視しない。 入力を受理できる上限と、window内の情報を均等・頑健に検索・推論できることは別である。「1M context対応」だけから「1M全域を同品質に推論可能」と書かない。
• service limitはmodel capabilityとは別の実効制約である。 rate/quota/spend/usage tierと持続throughputを分離して記録する。
• 「機能が存在する」と「そのtenant/userが利用できる」は別である。 plan/license、admin setting、identity/permission等を個別gateとして扱う。
• 実効能力は二値ではない。 ADVERTISED → SPECIFIED → EXPOSED → ENTITLED → AUTHORIZED → EXECUTABLE → OBSERVED → ACCEPTED を状態遷移候補とし、UNSUPPORTED / HIDDEN / BLOCKED_POLICY / QUOTA_LIMITED / DEGRADED / UNVERIFIED を失敗・未確定状態として保持する（PROPOSAL）。
• 成功した1回の呼出しは業務受入れの証明ではない。 sustained throughput、retry、quota exhaustion、latency、cost、auditability、data permission、業務golden setでの品質を別に確認する。
• EA-011との境界を維持する。 EA-012はcapability inventory / gate chain、EA-011は品質・失敗包絡の測定を担う。

• public docsは特定tenantのlicense assignment、rollout、region、admin policy、connector permission、private preview、contract exceptionを証明しない。
• 最大context、最大rate、usage tierをminimum SLAや持続性能と同一視しない。
• long-context研究を全製品・全version・全taskへ一般化しない。「公称context長だけから実効利用品質を推定できない」という範囲で使う。
• UI surfaceとAPI surface、consumer planとenterprise plan、previewとGAは独立して変化し得る。
• connector/retrieval対応でもidentity permissionがなければdata visibilityは空・限定になり得る。model capability不足と誤分類しない。
• quota内でもprovider-side transient capacity、latency、tool outage、downstream dependencyでeffective capabilityは一時的に縮退し得る。

model ID/revision / API or product surface / plan-license / billing-usage tier / region-residency / preview-rollout / admin policy / identity and data permission / connector-tool compatibility / network-egress / rate-quota-spend cap / content-file-message limits / downstream service availability / governance approval.

• CAPABILITY_ID
• PROVIDER / PRODUCT / SURFACE
• MODEL_ID_OR_RUNTIME_REVISION
• NOMINAL_SPEC
• CLAIM_SOURCE + LAST_VERIFIED
• REQUIRED_GATES
• CURRENT_AVAILABILITY_STATUS
• OBSERVED_STATE
• TEST_METHOD / TEST_ARTIFACT
• FAILURE_STATE
• COST_OR_QUOTA_BOUNDARY
• ACCEPTANCE_STATUS
• RECHECK_TRIGGER / EXPIRY

Provider比較表は機能の○×だけで表さず、各cellが SPECIFIED / ENTITLED / AUTHORIZED / OBSERVED / ACCEPTED / UNKNOWN のどこまで到達したかを記録する。

以下は後続Work向けTEST_PROFILEであり、すべて未実施。

• feature exposureをsecurity/governance approvalと同一視しない。tool/connectorのdata pathと権限境界を別途確認する。
• identity/permission不足を「AI性能不足」、oversharingを「高性能retrieval」と誤認しない。
• plan/licenseによりaudit、admin control、retention等の運用面も変わり得るため、capability recordにgovernance surfaceを含める。
• rate limit、spend cap、tool課金、long-context単価は、技術的に実行可能でも業務上のACCEPTEDを否定し得る。
• preview/rollout driftが大きい項目はPRODUCT_VOLATILEとし、公開直前・大規模release・契約変更時に再検証する。

「ベンダーが公称する能力は、モデルまたはサービスが対応する技術的範囲を示す。特定組織での実効能力は、製品面、契約・plan、地域、管理設定、identity/permission、tool/data、runtime capacity、quota/cost、業務受入試験を通過した範囲に限る。」

「大きなcontext windowは、その長さの入力を扱える仕様を示すが、window内の全情報を同じ精度で検索・推論できることまでは保証しない。長文利用品質は対象taskと実データで別途評価する。」

• enterprise契約で個別調整されたprivate limits / private preview / rollout cohort。
• provider内部routingや自動model selectionが表面上のmodel名と実処理をどこまで変えるか。
• 特定tenantのadmin settings、license assignment、connector permission、region-specific availability。
• 公称capacityとピーク時間帯の持続capacity差。
• implementation acceptance。

Canonical packet COMM-012-EA0012 と独立監査修正、同ID rescue bindingがdurably locatableになったため、研究の再実施は不要。以後は実装・repository tests・release readbackを行う。UNKNOWNはtenant固有事項と未実施TEST_PROFILEとして残す。