AI能力の継続観測所
記事状態: 公開 · 最終確認: 未確認
要点
AI能力の観測値は、モデル名だけに帰属する固定値ではない。モデル識別子、評価課題、実行環境、ツール/scaffold、採点器、利用条件、実行日を組にして記録し、同一方式 バージョンの系列内で比較する。比較評価やharnessを改訂した場合は旧系列と新系列をbridge 実行で接続し、方式 changeをモデル improvementと混同しない。
現在の判断
AI能力の観測値は、モデル名だけに帰属する固定値ではない。モデル識別子、評価課題、実行環境、ツール/scaffold、採点器、利用条件、実行日を組にして記録し、同一方式 バージョンの系列内で比較する。比較評価やharnessを改訂した場合は旧系列と新系列をbridge 実行で接続し、方式 changeをモデル improvementと混同しない。
どこまで当てはまるか
AI能力の継続観測所
詳しく理解する
観測タプル
timestamp / 提供元 / product-model family / exact モデル ID or snapshot if exposed / alias / endpoint-API 改訂版 / region-plan-org 確認・承認の条件 / system-developer instructions / tools and versions / agent-scaffold バージョン / runtime-container-dependencies / fixture suite and version-hash / sampling-inference parameters / scorer-judge and バージョン / repetitions-seed where applicable / 成功 criterion / latency / token-use cost / rate-limit-retry policy / raw 成果物 pointers / 根拠 origin。
exact snapshotが公開されない場合は未確認事項とし、alias名だけから同一backendを推定しない。
証拠と出典の分離
A. PROVIDER_RELEASE_CLAIM — 提供元 モデル card / 公開・提供 note / 比較評価 記述・判断。SOURCE_REPORT / PRODUCT_VOLATILE。 B. EXTERNAL_EVAL — primary paper、比較評価作者、独立評価。RESEARCH等。 C. LOCAL_OBSERVATION — 安全な自測。観測済み。外部証拠へ再分類しない。 D. USER_REPORT — 利用者報告。OBSERVED_USER_REPORT。再現性が取れるまで仕様扱いしない。
同じscore名でもoriginを混ぜて一本のseriesにしない。
Minimum artifacts
- CAPABILITY_OBSERVATION_CARD — 1観測のtuple、raw result、資料内の該当箇所。
- EVAL_SERIES — 同一方式 バージョンでの時系列。
- CHANGE_EVENT — モデル/API/ツール/契約プラン/比較評価/harness/scorer変更点。
- AVAILABILITY_GATE(可用性ゲート) — プラン、リージョン、組織、管理者設定、プレビューなど。
- SOURCE_SNAPSHOT — 外部 記述・判断のas-of、URL、版、資料内の該当箇所。
- RETEST_TRIGGER — 再実行条件と優先度。
再テストのトリガー
exact モデル ID/snapshot/alias変更、提供元 公開・提供 note、endpoint/API 改訂版変更、ツール/scaffold/実行環境変更、文脈・入力情報/ツール 利用可能性変更、比較評価/harness/scorer 改訂版、契約プラン/region/管理者 確認・承認の条件変更、価格/利用回数・処理量の上限の大幅変更、系列内で説明不能なdrift、事故/near-missを候補とする。
仕組みと設計
利用可能な機能 scoreだけでなく reliability / latency / cost / rate-limit / ツール 失敗 / safety-control behavior / auditability を別軸として記録する。単一scoreを配備保証へ外挿しない。
scorer/judgeも観測対象とする。LLM-as-judgeを使う場合はjudge モデル、prompt、temperature、rubric、aggregationをバージョン固定し、judge更新後のscoreを旧seriesへ無補正で継ぎ足さない。
根拠 / 出典・来歴
AUTHORITY COMM-032-EA0030。
NIST AI RMF PlaybookのMEASURE 2.4 / MANAGE 4.1を継続的に監視し、導入前後の差分や変更管理の根拠として扱います。NIST AI 600-1は生成AIのリスクコンテキストに関するものです。METR Time Horizonsは、タスクの分配、人間の基準、エージェントの設定、成功確率などへの手法依存性を示しています。LiveBenchは継続的に更新されるベンチマークの例です。OpenAI SWE-bench Verifiedの資料は、フィクスチャ/ハーネスの不備とベンチマークの廃止の例です。HELM Capabilitiesは、集計結果とシナリオ別の結果を分離する文脈で使用されます。OpenAI Modelsのドキュメントは、モデルIDとエイリアスを分けて記録している現在の製品例ですが、製品の変更により変動する可能性があります(PRODUCT_VOLATILE)。
提供元 記述・判断は提供元報告、自測は当該条件での観測としてoriginを明示する。
利用できる条件
契約プラン / region / 組織 policy / 管理者 enablement / preview-beta-GA / API-vs-chat 利用機能・接続経路 / ツール entitlement / rate tierをObservation Cardの独立欄で保持する。「機能が存在する」と「当該組織で利用可能」を別記述・判断にする。PRODUCT_VOLATILE項目は各実行時に現行確認する。
Proposed 状態 machine
REGISTER_TEST -> FREEZE_METHOD -> 比較の基準 -> PERIODIC_OR_EVENT_RETEST -> DELTA_CLASSIFY -> (NO_MATERIAL_DELTA | CAPABILITY_DELTA | AVAILABILITY_DELTA | METHOD_DELTA | OPERABILITY_DELTA | UNKNOWN_DELTA) -> SOURCE_SNAPSHOT -> UPDATE_CANDIDATE。
方式変更を検出した場合は旧seriesを閉じず、BRIDGE 実行を作る。この状態 machineはPROPOSAL。
確認・評価方法
(a) stable internal regression fixture、(b) periodically refreshed contamination-resistant 外部 比較評価、(c) real-task / long-horizon 評価、(d) 安全性/制御 regression、(e) operability metricsを分ける。公開比較評価 scoreを提供元 warrantyへ外挿しない。internal fixtureには実顧客秘密情報を入れず、合成または許諾済み非機密fixtureを使う。
確認・評価方法 2
UNEXECUTED。 - 非機密fixture 10〜20件のsentinel set。 - 正確なモデルID/インターフェース/ツール構成を固定し、同一の実行を複数回行い、ばらつきを確認する。 - エイリアスとスナップショットの双方が提供される場合は、同日にブリッジ比較を行う。 - harnessのみのバージョンを変更したA/Bテストの実行により、メソッド間の差異(delta)を確認。 - 結果は観測済みとして保存し、外部出典と混同しない。
具体的な回数、fixture、閾値、実測値は未実施のため保証しない。cheap sentinel -> delta検出時full suiteの二段階運用はPROPOSAL。
セキュリティとプライバシー
認証済み組織の利用環境の秘密データ、実顧客データ、危険ツール actionを自動再試験へ投入しない。security fixtureも非機密・非破壊に限定する。 監査: raw request/responseを保存できない場合でもhash、fixture バージョン、実行 設定、出典 資料内の該当箇所、失敗 reasonを残す。提供元 policyに反するraw data保存はしない。
コストと運用負荷
token/API費、human review費、比較評価 maintenance費を別計上する。
OPERABILITY
処理待ち時間の上限、再試行、429、ツール outage、environment 失敗を能力失敗と同一bucketへ入れず、MODEL_BEHAVIOR / HARNESS_FAILURE / PROVIDER_AVAILABILITY / POLICY_BLOCKへ分類する。
Cross-reference 適用限界
EA-016 評価、EA-029 template/根拠 linkage、EA-400 モデル behavior drift等へ接続可能だが、本packetで関連EAを再編集・再解釈しない。
よくある失敗・反証
公開 比較評価はtraining exposure、test contamination、fixture flaw、saturationで能力指標として劣化し得る。
比較評価更新は測定品質を上げても旧版とのstrict comparabilityを壊すため、最新版scoreと旧版scoreを単純連結しない。
提供元側の非公開処理先の振り分け、安全性 policy、backend、推論 stack変更は完全再現できない場合があり、非公開部分は未確認事項とする。
alias名が同じでも内部参照先不変を仮定しない。snapshot非公開なら「同一公開識別子での再試験」とする。
leaderboardは特定task distributionの結果であり、enterprise業務性能・安全性・SLAを保証しない。
自測は組織の利用環境/契約プラン/region/setup固有になり得る。公開 docsを組織の利用環境実挙動の証明にせず、自測を外部根拠へ格上げしない。
実務での使い方
契約プラン / region / 組織 policy / 管理者 enablement / preview-beta-GA / API-vs-chat 利用機能・接続経路 / ツール entitlement / rate tierをObservation Cardの独立欄で保持する。「機能が存在する」と「当該組織で利用可能」を別記述・判断にする。PRODUCT_VOLATILE項目は各実行時に現行確認する。
UNEXECUTED。
非機密fixture 10〜20件のsentinel set。
正確なモデルID/インターフェース/ツール構成を固定し、同一の実行を複数回行い、ばらつきを確認する。
エイリアスとスナップショットの双方が提供される場合は、同日にブリッジ比較を行う。
harnessのみのバージョンを変更したA/Bテストの実行により、メソッド間の差異(delta)を確認。
結果は観測済みとして保存し、外部出典と混同しない。
具体的な回数、fixture、閾値、実測値は未実施のため保証しない。cheap sentinel -> delta検出時full suiteの二段階運用はPROPOSAL。
認証済み組織の利用環境の秘密データ、実顧客データ、危険ツール actionを自動再試験へ投入しない。security fixtureも非機密・非破壊に限定する。 監査: raw request/responseを保存できない場合でもhash、fixture バージョン、実行 設定、出典 資料内の該当箇所、失敗 reasonを残す。提供元 policyに反するraw data保存はしない。
まだ確認できていないこと
- EA-030-UNKNOWN-01
- クローズドなプロバイダーのエイリアスによる内部ルーティングやバックエンドの更新を、外部から完全に特定できるか。
- 組織の利用環境/region/契約プラン別に同一公開モデル IDが同一挙動を保証するか。
- cross-providerで単一の総合能力scoreを作れるか。task/scenario別seriesを優先する。
- LLM-as-judge長期seriesのjudge drift補正の標準手法。
- closed モデルに対する公開 比較評価 training exposureの完全検証。
未確認事項を推測で閉じない。
- EA-030-UNKNOWN-CURRENTNESS
外部根拠の再確認日が正式な本文・公開管理情報で確定していないため、現行性は未確認のまま保持する。確認日を推測して補わない。
根拠資料
この記事には、直接開ける外部出典が登録されていません。出典IDや検証情報は末尾で確認できます。
出典ID・検証情報・機械可読データ
根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。
- 記事ID
- EA-030
- 最終確認日
- —
- 提供元・モデル・プラン・利用環境
- —
- 対象地域
- —
元資料の全文と収録照合記録
Public claim
AI能力の観測値は、モデル名だけに帰属する固定値ではない。モデル識別子、評価課題、実行環境、tool/scaffold、採点器、利用条件、実行日を組にして記録し、同一method versionの系列内で比較する。benchmarkやharnessを改訂した場合は旧系列と新系列をbridge runで接続し、method changeをmodel improvementと混同しない。
Observation schema、state machine、sentinel strategyは辞典側のPROPOSALであり、外部標準の固定要件ではない。
Observation Tuple
timestamp / provider / product-model family / exact model ID or snapshot if exposed / alias / endpoint-API revision / region-plan-org gate / system-developer instructions / tools and versions / agent-scaffold version / runtime-container-dependencies / fixture suite and version-hash / sampling-inference parameters / scorer-judge and version / repetitions-seed where applicable / success criterion / latency / token-use cost / rate-limit-retry policy / raw artifact pointers / evidence origin。
exact snapshotが公開されない場合はUNKNOWNとし、alias名だけから同一backendを推定しない。
Evidence-origin separation
A. PROVIDER_RELEASE_CLAIM — provider model card / release note / benchmark claim。SOURCE_REPORT / PRODUCT_VOLATILE。 B. EXTERNAL_EVAL — primary paper、benchmark作者、独立evaluation。RESEARCH等。 C. LOCAL_OBSERVATION — 安全な自測。OBSERVED。外部証拠へ再分類しない。 D. USER_REPORT — 利用者報告。OBSERVED_USER_REPORT。再現性が取れるまで仕様扱いしない。
同じscore名でもoriginを混ぜて一本のseriesにしない。
Minimum artifacts
- CAPABILITY_OBSERVATION_CARD — 1観測のtuple、raw result、locator。
- EVAL_SERIES — 同一method versionでの時系列。
- CHANGE_EVENT — model/API/tool/plan/benchmark/harness/scorer変更点。
- AVAILABILITY_GATE — plan/region/org/admin setting/preview等。
- SOURCE_SNAPSHOT — external claimのas-of、URL、版、locator。
- RETEST_TRIGGER — 再実行条件と優先度。
Frozen / Current / Bridge series
FROZEN SERIESは過去比較用としてfixture/harness/scorerを固定する。CURRENT SERIESは汚染・飽和・不良fixtureを修正した最新suiteとする。suite更新時は可能なら旧新を一定期間同時に走らせるBRIDGE RUNを置き、method changeとmodel changeを分離する。
LiveBenchの継続更新、SWE-bench Verifiedの改訂・退役は、benchmarkを一度採用すれば永久に同じ観測器として使えるわけではないことを示す具体例として扱う。
Retest triggers
exact model ID/snapshot/alias変更、provider release note、endpoint/API revision変更、tool/scaffold/runtime変更、context/tool availability変更、benchmark/harness/scorer revision、plan/region/admin gate変更、価格/rate limitの大幅変更、系列内で説明不能なdrift、事故/near-missを候補とする。
Capability vs operability
capability scoreだけでなく reliability / latency / cost / rate-limit / tool failure / safety-control behavior / auditability を別軸として記録する。単一scoreをdeployment保証へ外挿しない。
scorer/judgeも観測対象とする。LLM-as-judgeを使う場合はjudge model、prompt、temperature、rubric、aggregationをversion固定し、judge更新後のscoreを旧seriesへ無補正で継ぎ足さない。
Evidence / provenance
AUTHORITY COMM-032-EA0030。
NIST AI RMF Playbook MEASURE 2.4 / MANAGE 4.1を継続monitoring、pre/post-deployment差分、change managementの根拠として扱う。NIST AI 600-1はGenAI risk context。METR Time Horizonsはtask distribution、human baseline、agent setup、success probability等へのmethod依存を示す。LiveBenchは継続更新型benchmarkの例。OpenAI SWE-bench Verified資料はfixture/harness不良とbenchmark retirementの例。HELM Capabilitiesはaggregateとscenario別結果を分離する文脈。OpenAI Models documentationはmodel IDとaliasを分けて記録するcurrent product exampleでありPRODUCT_VOLATILE。
provider claimはprovider報告、自測は当該条件での観測としてoriginを明示する。
Failure envelope
- public benchmarkはtraining exposure、test contamination、fixture flaw、saturationで能力指標として劣化し得る。
- benchmark更新は測定品質を上げても旧版とのstrict comparabilityを壊すため、最新版scoreと旧版scoreを単純連結しない。
- provider側の非公開routing、safety policy、backend、inference stack変更は完全再現できない場合があり、非公開部分はUNKNOWNとする。
- alias名が同じでも内部参照先不変を仮定しない。snapshot非公開なら「同一公開識別子での再試験」とする。
- leaderboardは特定task distributionの結果であり、enterprise業務性能・安全性・SLAを保証しない。
- 自測はtenant/plan/region/setup固有になり得る。public docsをtenant実挙動の証明にせず、自測を外部evidenceへ格上げしない。
Availability gates
plan / region / organization policy / admin enablement / preview-beta-GA / API-vs-chat surface / tool entitlement / rate tierをObservation Cardの独立欄で保持する。「機能が存在する」と「当該組織で利用可能」を別claimにする。PRODUCT_VOLATILE項目は各RUN時に現行確認する。
Proposed state machine
REGISTER_TEST -> FREEZE_METHOD -> BASELINE -> PERIODIC_OR_EVENT_RETEST -> DELTA_CLASSIFY -> (NO_MATERIAL_DELTA | CAPABILITY_DELTA | AVAILABILITY_DELTA | METHOD_DELTA | OPERABILITY_DELTA | UNKNOWN_DELTA) -> SOURCE_SNAPSHOT -> UPDATE_CANDIDATE。
method変更を検出した場合は旧seriesを閉じず、BRIDGE RUNを作る。このstate machineはPROPOSAL。
Evaluation portfolio
(a) stable internal regression fixture、(b) periodically refreshed contamination-resistant external benchmark、(c) real-task / long-horizon evaluation、(d) safety/control regression、(e) operability metricsを分ける。公開benchmark scoreをprovider warrantyへ外挿しない。internal fixtureには実顧客秘密情報を入れず、合成または許諾済み非機密fixtureを使う。
TEST_PROFILE
UNEXECUTED。 - 非機密fixture 10〜20件のsentinel set。 - exact model ID/surface/tool構成を固定し同一RUNを複数回実行してvariance確認。 - aliasとsnapshotの双方が提供される場合は同日bridge comparison。 - harnessのみversion変更したA/B runでmethod delta確認。 - 結果はOBSERVEDとして保存し、外部sourceと混同しない。
具体的な回数、fixture、閾値、実測値は未実施のため保証しない。cheap sentinel -> delta検出時full suiteの二段階運用はPROPOSAL。
SECURITY/PRIVACY
認証済みtenantの秘密データ、実顧客データ、危険tool actionを自動再試験へ投入しない。security fixtureも非機密・非破壊に限定する。 AUDIT: raw request/responseを保存できない場合でもhash、fixture version、run config、source locator、failure reasonを残す。provider policyに反するraw data保存はしない。
COST
token/API費、human review費、benchmark maintenance費を別計上する。
OPERABILITY
timeout、retry、429、tool outage、environment failureを能力失敗と同一bucketへ入れず、MODEL_BEHAVIOR / HARNESS_FAILURE / PROVIDER_AVAILABILITY / POLICY_BLOCKへ分類する。
OPEN_UNKNOWN
- closed providerのalias内部routing・backend更新を外部から完全に特定できるか。
- tenant/region/plan別に同一公開model IDが同一挙動を保証するか。
- cross-providerで単一の総合能力scoreを作れるか。task/scenario別seriesを優先する。
- LLM-as-judge長期seriesのjudge drift補正の標準手法。
- closed modelに対するpublic benchmark training exposureの完全検証。
UNKNOWNを推測で閉じない。
Cross-reference boundary
EA-016 eval、EA-029 template/evidence linkage、EA-400 model behavior drift等へ接続可能だが、本packetで関連EAを再編集・再解釈しない。
EA-030-R11-RESEARCH研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKETEA-030 監査済みresearch / canonical revision binding
- 裏付ける内容
- AI能力の観測値は、モデル名だけに帰属する固定値ではない。モデル識別子、評価課題、実行環境、tool/scaffold、採点器、利用条件、実行日を組にして記録し、同一method versionの系列内で比較する。benchmarkやharnessを改訂した場合は旧系列と新系列をbridge runで接続し、method changeをmodel improvementと混同しない。
- 確認日
- —
- 出典・実験ID
- COMM-032-EA0030
- 検証箇所
- COMM-032-EA0030 · EA-030-R5-LEGACY-MIGRATION-20261008-R1 · content/staging/EA-030.md
- 適用範囲
- 監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。
- 出典・来歴
- AUDIT_PASS_CANONICAL_BINDING
- 限界
- canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。
EA-030-R11-WEB-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACKEA-030 Web body identity / canonical readback
- 裏付ける内容
- canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。
- 確認日
- —
- 出典・実験ID
- WEBBODY-EA0030-R8-E989098F
- 検証箇所
- WEBBODY-EA0030-R8-E989098F · content/staging/EA-030.md · EA-030-R5-LEGACY-MIGRATION-20261008-R1
- 適用範囲
- R9/R10 canonical readback後のProduction生成時body identity。
- 出典・来歴
- CANONICAL_READBACK_BODY_HASH_MATCH
- 限界
- body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。
- 出典ID
- COMM-032-EA0030, WEBBODY-EA0030-R8-E989098F
- 追跡中のUNKNOWN ID
- EA-030-UNKNOWN-01, EA-030-UNKNOWN-CURRENTNESS
- 再確認のきっかけ
- 正式な 改訂版/publication 状態 change · 本文 成果物 hash change · 出典 現行性 change · new contradiction or 実装 結果の照合
機械検査: 通過 — 機械検査の結果です。情報の正確性や実行の承認を保証するものではありません。
同じ記事IDの機械可読データです。