Tail-risk／rare catastrophic case 評価 sampling

平均スコアだけでは、発生頻度は低いが被害が大きい失敗を十分に評価できません。EA-743では、通常品質の評価母集団とは別に、重大度の高いfailure modeを明示し、rare/high-impact caseを意図的に厚くした評価集合と、必要に応じて母集団発生率を推定する確率的評価を分離します。

OpenAIのPreparedness Framework（2025-04-15更新）は、frontier capability由来の「severe harm」を優先対象として扱い、リスクが plausible / measurable / severe / net new / instantaneous or irremediable であることを追跡対象の判断基準にしています。またHigh capabilityに達したcovered systemは、deployment前に関連するsevere riskを十分に低減するsafeguardsを要求し、Capabilities ReportsとSafeguards ReportsをSafety Advisory Groupがレビューする運用を示しています。これは一般的な平均品質評価とは別に、重大なtail riskを独立した評価・governance対象にする実例です。

NIST ARIA 0.1（NIST AI 700-2, 2025）は、AI applicationをModel Testing、Red Teaming、Field Testingの複数レベルで評価しました。Model Testingだけでなく、guardrailをstress testしてdisallowed behaviorを引き出すRed Teamingと、通常利用下でのField Testingを組み合わせる点は、単一の平均スコアでは評価対象を覆い切れないことを示します。2026年9月にはNIST AI 200-3としてARIA Evaluation Planning Manualも公開され、ARIA型評価の構成要素が整理されています。

rare-eventの発生確率そのものを推定する場合、単純なoversampling結果の失敗率を母集団確率として扱うことはできません。rare-event simulation研究ではimportance sampling等を使って希少事象を効率的に観測しつつ、sampling distributionの偏りを補正して確率を推定します。Deep-PrAE（Arief et al., 2020/2021）は、black-box safety-critical systemsではnaiveなimportance samplingが危険な過小推定を起こし得ることを指摘し、rare-event set learningとimportance samplingを組み合わせたcertifiableな評価方法を提案しています。Accelerated Policy Evaluation（Xu et al., 2021）も、rare but high-stakes eventの評価でadaptive importance samplingを用い、希少事象の発見と確率推定を同時に扱います。

したがって、tail-risk evaluationには少なくとも二種類の評価目的を分離する必要があります。

• hazard discovery / stress evaluation: 重大なfailure modeを見つけるため、severity・threat model・known weakness・boundary conditionに基づき意図的にoversampleする。
• population risk estimation: 実運用母集団での発生率を推定するため、selection probabilityが追跡できるsampling設計と適切なweighting/estimatorを使う。

前者のcase比率は意図的に歪んでいるため、そのままproduction incidence rateへ読み替えません。

tail-risk suiteは「平均品質suiteの難しい版」ではなく、failure severityを軸に別管理します。少なくとも hazard_id、想定被害、severity、exposure条件、trigger、expected safeguard、observed outcome、evidence source、case provenance、last_refresh_at を持たせ、通常回帰テストと混ぜて平均化しません。

重大failureのcaseを増やすだけでは十分ではありません。既知caseへの過学習、red-team promptの固定化、threat modelの陳腐化、評価環境を認識したモデルの挙動変化、rare modeの取り逃しが起こり得ます。OpenAIが2025年のscheming研究で「rare but serious failures」が残ることやevaluation awarenessによる交絡を報告したことは、既知suiteでゼロ件だったことをtail risk不存在の証明にしてはいけない理由の一つです。

また、severityだけで優先すると「重大だが現実には到達不能なscenario」に予算を使い過ぎる可能性があります。Preparedness Frameworkがplausibilityやmeasurabilityも優先基準に含めるように、severityとexposure/plausibilityを分離して記録します。

• hazard registerとeval caseを結ぶ 各tail-risk caseに hazard_id を付与し、どの重大failureを検証するcaseかを追跡します。case単体の難易度ではなく、hazard coverageを確認します。

• severity-based oversamplingを明示する sampling_reason=tail_risk_oversample、severity_class、selection_policy_version を保存します。oversampled suiteのraw failure rateをproduction全体のfailure rateとして報告しません。

• random/control laneを残す threat-model由来caseだけでなく、通常trafficからの確率sampleやfield observationを別laneで維持し、未知failureや分布変化を検出します。

• 発生率推定にはsampling probabilityを保存する 母集団riskを推定する場合、selection probabilityまたは再現可能なsampling ruleを保存し、importance weighting等の妥当なestimatorを用います。selection probabilityが定義できないdeterministic top-K stress suiteから母集団発生率を推定しません。

• hard-fail gateと統計gateを分離する catastrophic classは平均scoreの改善で相殺しないhard-fail/mandatory review条件を設けます。一方、rare-event probabilityの数値比較をrelease gateへ使う場合は、confidence interval、effective sample size、weight concentration等を確認し、少数観測の点推定だけで昇格させません。

• suiteをrefreshする 新incident、red-team discovery、provider/model変更、tool/retrieval変更、policy変更、field failureをtriggerとしてtail-risk corpusを更新します。過去caseを消さず、追加理由とversionを残します。

OpenAI Preparedness Frameworkはfrontier AIのsevere-harm capability/safeguard governanceであり、一般的なenterprise applicationすべてに同じthresholdやcategoryを要求する標準ではありません。NIST ARIA 0.1もpilot evaluationであり、特定の企業システムにそのまま適用できる合否基準ではありません。

rare-event simulationのimportance-sampling研究は、自動運転やRL policy等を含むsafety-critical settingでの確率推定を主対象とします。LLMのsemantic failureではfailure setやsampling distributionを数理的に定義しにくい場合があり、同じ保証をそのまま移植できません。LLMでは、stress-suiteによるhazard discoveryとproduction incidence estimationを分け、後者で確率設計が成立する範囲だけ統計的推定を行うのが安全です。

oversamplingはrare caseの発見効率を上げ得ますが、sampling designが悪いと重要なfailure modeを外したまま「十分に調べた」ように見える危険があります。black-box rare-event evaluationでは、効率化手法自体が過小推定を起こす可能性が研究上指摘されています。

また、tail-risk suiteのfailure countがゼロでも、真のfailure probabilityがゼロとは限りません。極低頻度事象では必要sample数が大きくなり、distribution shiftやadaptive adversaryがあると過去の推定が失効します。重大性の分類も組織・用途・法域・exposureによって変わるため、severity taxonomyを固定的な普遍尺度として扱いません。

• LLM/agentのsemantic failureで、rare-event probabilityを安定して定義・推定できる範囲
• severity、plausibility、exposure、detectabilityを統合する優先度関数
• adversarially adaptiveなfailureに対するsampling policyの更新頻度
• tail-risk suiteの十分性を判定する停止条件
• field trafficがlogging/filtering/routingで既に偏っている場合の上流selection補正

「平均品質評価とは別に、発生頻度が低くても被害が大きいfailure modeをtail-risk評価として管理し、重大caseを意図的に厚く検証する。oversampled suiteの失敗率はそのまま実運用の発生率ではない。母集団riskを推定する場合はsampling probabilityを追跡できる確率設計と適切な補正を用い、重大failureのrelease判断は平均scoreで相殺しない。」

• OpenAI, “Our updated Preparedness Framework,” 2025-04-15: https://openai.com/index/updating-our-preparedness-framework/
• NIST, “Assessing Risks and Impacts of AI (ARIA): Pilot Evaluation Report,” NIST AI 700-2, 2025: https://doi.org/10.6028/NIST.AI.700-2
• NIST, “ARIA Evaluation Planning Manual: Elements of ARIA-Style AI Evaluations,” NIST AI 200-3, 2026-09-18.
• Arief et al., “Deep Probabilistic Accelerated Evaluation: A Robust Certifiable Rare-Event Simulation Methodology for Black-Box Safety-Critical Systems,” arXiv:2006.15722.
• Arief et al., “Certifiable Deep Importance Sampling for Rare-Event Simulation of Black-Box Systems,” arXiv:2111.02204.
• Xu et al., “Scalable Safety-Critical Policy Evaluation with Accelerated Rare Event Sampling,” arXiv:2106.10566.
• OpenAI, “Detecting and reducing scheming in AI models,” 2025.