AI安全性のためのドリフト検知とモデル劣化監査—後付け不能な評価手続き「素数重力」
- kanna qed
- 4 日前
- 読了時間: 10分
AI安全性評価は説明をしても実際に再現可能な評価手続き(検算可能なプロトコル)として残していないと、後から無限にこじつけやすい。従来の説明資料やガバナンス要求では、同一入力に対して常に同じ結論が得られるよう保証されず、後付け最適化(結果を見てから評価基準を変えること)を防げない。そこで提案する素数重力は、評価プロトコルそのものを数学的に固定する仕組みである。具体的には、評価結果を有限回の算術(整数の符号化+相互素な法での並列記録)に落とし込み、中国剰余定理(CRT)で一意復元して単一の整数結論に結びつける。これにより、監査台帳と検算手続きで第三者が評価結果を再生成でき、後から手続きを変えられなくなる。

素数重力:AI安全性において、ドリフト検知を“再現不能な運用”から救う数学的プロトコル
本稿の主語は「モデルの内部」ではなく「安全性評価プロトコル」である。ここでいう安全性は、(i) 同一入力(同一データ同定)から (ii) 同一の評価計算が再実行され、(iii) 同一の監査結論(OK/NG)が第三者により再生成される性質として定義する。
再現可能とは、評価に必要な入力同定(データ識別子・期間・抽出規則)、評価窓(window)、閾値ポリシー(threshold policy)、丸め規約(rounding convention)、実行環境(version)を固定し、それらが台帳(ledger)から一意に復元できることを指す。
後付け不能とは、結果を見た後に window / threshold / rounding を変更して結論を取り換える操作が、台帳の整合性検算(Verify)により必ず検出されることを指す。有限射程とは、根拠として許容する計算範囲(窓、対象指標、符号化の法集合)が事前に確定し、追加理由を無限に参照して結論を延命できないことを指す。
以後、「素数重力」とは、この三要件(再現可能・後付け不能・有限射程)を、最小の算術プロトコルとして同時に満たす結論固定機構を指す。
1. AI安全性が壊れる典型パターン:理由の“無限先送り”
AI安全性評価ではしばしば「説明文はあるが検算可能でない」状況が生じる。たとえば、説明責任を果たすために Model Cards や Datasheets のような文書が用意されるが[4][5]、それらはあくまで構造化された説明フォーマットであって、同一入力で同一結果を返す手続きの固定にはならない。また、問題が起きると「モデルの内部がブラックボックスだ」「そもそも学習データに問題があったのではないか」と説明がモデル内部や学習過程に押し戻されてしまうことが多い。結果として説明資料は増えても、同一入力→同一結論の関係を第三者が再現できない。一般に、同じ構造化入力で同じ出力を返す決定システムでない限り、再現性も監査可能性も保てない[3]。一方で、「後付け最適化」すなわち検証結果を見てから閾値や評価窓を恣意的に変更する行為も大きな課題である。これらが積み重なると、透明性のように見えても再現性のない説明ショーに陥り、安全性評価の信頼性が失われる。
脅威モデル:後付け最適化と評価条件すり替え
想定する攻撃者は、(i) 結果を見た後に window を変更する者、(ii) 閾値を変更する者、(iii) 丸め規約・前処理を変更する者、(iv) 良いケースのみを選別して提示する者である。これらは「説明資料が存在する」状況でも実務上頻発する。問題は悪意の有無ではなく、手続きが固定されない限り、検証が未来へ分岐し続ける構造にある。
本方式が防ぐのは、上記の後付け操作による結論の差し替えである。台帳に window / threshold / rounding / 入力同定 / 実行環境を焼き付け、Verify により同一計算の再生成性を強制することで、差し替えは必ず検出される。
一方で本方式は、(a) 学習データ自体の妥当性、(b) 倫理的妥当性、(c) モデル内部表現の解釈可能性、を直接の保証対象にしない。保証対象はあくまで「安全性判定プロトコルの固定」と「第三者検算可能性」である。
2. なぜ“重力”が必要か:判断・根拠・検証を一点に引き寄せる
評価において「重力」が必要なのは、判断(結論)とその根拠・検証手続きを一体化し、説明を発散や後戻りさせないためである。本稿で扱う用語を定義すると:
出力(output): 評価の結論。
根拠(reason): 評価に寄与した要素の内訳。
検算(verification): 結論を機械的に検証できる評価手続き。
重力がないと、説明は個別の要素に分散しやすく、評価手続きが組織ごと・状況ごとでバラつく。すると、結論を検証する際に「ここまでが説明の範囲」という境界が曖昧になり、結局検証を未来に先送りしてしまう。具体的には、手続きに分岐が生じて異なる評価窓や閾値が混在したり、根拠説明が複数存在したりする。これを避けるには、評価プロトコル全体に重力点を設定し、再現可能な評価手続きとなるよう検算可能な形で固定しなければならない。
3. 素数が“重力点”になれる理由(新規性のコア)
素数の集合(互いに素な法の集合)には次のような性質がある。まず、素数は1と自分自身以外に割り切れない分解不能な単位であり[9]、評価プロトコルの最小単位に適している。また、素数の組み合わせは外部規約に依存しにくく、台帳(監査証跡)上で選定プロセスを記録できる。さらに素数は有限個列挙できるため、評価の射程を有限に制限できる。
ζ構造による有限化:無限寄与を“止められる形”へ変換する
素数を安全性評価に持ち込む目的は、素数そのものの神秘性ではなく、寄与の無限先送りを「有限で止まる形」に押し込む点にある。ζ構造(明示公式の系)を介すると、離散要因(素数側)と連続的振る舞い(周波数側)が分離され、評価は「主項+誤差」という形に分解される。ここで重要なのは、誤差を含めた評価射程を事前に固定できることである。
本稿では、(i) 評価窓を有限区間として定義し、(ii) その区間内の寄与だけを根拠として採用し、(iii) 区間外の寄与を誤差として扱う規約を台帳に固定する。これにより、追加の理由(追加区間、追加特徴、追加検証)への無限先送りは、規約違反として検出可能になる。
この有限化を「算術的に固定」する手段が素数重力である。すなわち、有限窓で得た局所評価を整数符号へ写像し、互いに素な法集合上で同時に記録し、中国剰余により一意復元することで、結論を単一の整合整数として固定する。
4. 直結点:素数重力がAI安全性にもたらす3つの効果
説明射程が固定される: 検証範囲(使用データの窓や閾値・丸め規約など)が評価プロトコルで決定され、どこまでが根拠かが明確になる。
評価が再現可能になる: 第三者が同一の入力から同一の結論を生成できるように検算プロトコルが定められる。
後付け最適化が構造的にできない: 閾値や評価窓の設定、丸め規約などが証明書に組み込まれるため、結果を見てから手続きを変えることが不可能になる。
これらにより、単に「説明文を載せた」だけの手続きではなく、数理的に完全に検算可能な枠組みとして安全性評価が成立する。
5. 先行研究・規格の到達点と未充足:素数重力が埋める一点
先行の到達点は大きく五群に整理できる。 (1) 文書化の標準化: Model Cards / Datasheets は、用途・前提・測定・注意点を共有する書式を与えた。 (2) 組織ガバナンス: NIST AI RMF / ISO/IEC 42001 は、リスク管理と統制の要求を与えた。 (3) 規制要請: EU AI Act は、高リスク用途を中心に記録・技術文書・監督の枠を要求する。 (4) 研究再現性文化: NeurIPS checklist 等は、再現性開示の促進に寄与した。 (5) 計算証明: Proof-of-Learning 等は、計算過程の正しさを証明する方向を切り開いた。
未充足は共通して一つである。すなわち「安全性判定のプロトコル自体」を、有限射程で固定し、第三者が同一結論を再生成・検算でき、結果を見た後に window / threshold / rounding を差し替えられない形で拘束する最小形式が、これらには明示されない。
素数重力の突破点はここにある。透明性を説明文の厚みとして扱わず、ガバナンスを運用努力の多寡として扱わず、評価そのものを「有限射程・再生成可能・後付け不能」な算術プロトコルとして固定する。主語はモデルではなくプロトコルであり、成果物は資料ではなく検算可能な台帳である。
6. 実装レイヤ(設計原理→手順)
評価対象の有限窓を定義する: モデル入力や過去観測の期間など、評価根拠とするデータの範囲を決める。
局所評価を整数符号へ: モデルや統計評価の結果を丸め規約を含めて整数に符号化する(例:閾値越え=1、以下=0など)。
互いに素な法集合で並列記録: 取得した整数をいくつかの異なる素数(または互いに素な法)で割った余りとして並列に記録する。
中国剰余で一意復元: これらの余りから中国剰余定理を使って元の整数を一意に復元し、全体として整合性のある結論値を得る。
台帳(監査証跡)への記録: 入力の識別子、定義した窓・閾値・丸め規約・結果などを含む監査ログを台帳に記録し、第三者が同じ手順で検算できるようにする。
規格・法要求を満たす最小アーティファクト:台帳フィールドへの射影
NIST/ISO/EU が要求するのは、説明そのものではなく「管理可能性」と「追跡可能性」である。本方式では、それを台帳の必須フィールドとして具体化する。
必須フィールド(最小)
Input-ID: データ同定(ハッシュ、取得規則、期間)
Window-Spec: 評価窓(開始・終了・抽出条件)
Metric-Spec: 評価指標(定義式、集計規約)
Threshold-Policy: 閾値と判定規則(固定値、更新禁止の宣言)
Rounding-Convention: 丸め規約(外向き丸め等、桁数、型)
Moduli-Set: 互いに素な法集合(選定規約を含む)
Residues: 局所評価の符号(法ごとの記録)
CRT-Result: 一意復元された整合整数
Decision: 監査結論(OK/NG)と根拠参照
Verifier-Version: Verify 実装と実行環境の同定
この射影により、要求(should)ではなく、検算可能な成果物(artifact)として監査準備が完結する。
最小スキーマ:Certificate と Ledger
証明書(certificate)は「固定された評価プロトコル」を指し、台帳(ledger)は「そのプロトコルに基づく実行の痕跡」を指す。最小構成は次である。
Certificate(固定物)
dataset_id, dataset_hash
model_id, model_hash
window_spec(start/end, sampling, filters)
metric_spec(定義、集計、欠損処理)
threshold_policy(値、判定規則、更新禁止)
rounding_convention(外向き丸め、桁数、型)
moduli_set(互いに素な法の列、選定規約)
verifier_version
Ledger(実行物)
run_id, timestamp
input_hash(実データの同定)
residues[m_i](各法での局所評価符号)
crt_result(整合整数)
decision(OK/NG)
verify_digest(検算ハッシュ)
Verify:第三者検算プロトコル(要点のみ)
Verify の入力は (Certificate, Ledger) とする。Verify は次を順に検査する。
Input-ID 検査: ledger の input_hash が certificate の dataset_id / window_spec に整合すること
規約検査: threshold_policy / rounding_convention / moduli_set が certificate と一致すること
再計算検査: 同一入力から residues を再計算し、ledger 記録と一致すること
CRT 検査: residues と moduli_set から crt_result を再構成し一致すること
判定検査: crt_result と threshold_policy から decision を再生成し一致すること
この Verify により、結果を見た後の window / threshold / rounding 差し替えは必ず不一致として検出される。
7. 検証可能性チェックリスト
[ ] 同一の入力データに対し、同一の結論が再生成できるか(結果再現性)
[ ] 窓・閾値・丸め規約が技術的に固定されているか(説明射程の固定)
[ ] 後から「望ましい結果だけ」を選べない構造になっているか(後付け最適化防止)
[ ] 監査ログだけで第三者が検算できるか(独立した検証可能性)
ケーススタディ:ドリフト検知を「監査証跡+後付け不能」で固定する
目的は、時系列予測における分布変化(regime shift)を検知したという結論を、後から取り換えられない形で残すことである。典型的な失敗は、検知率が悪いと window をずらし、閾値を調整し、最も都合のよい結果だけを報告することである。
本方式では、(i) 評価窓(例:直近28日を calibration、次の7日を test)を certificate に固定し、(ii) 指標(例:MAE の上方逸脱)と閾値(例:基準平均との差の整数符号が T を超えたら NG)を固定し、(iii) 外向き丸め規約を固定する。各日の局所評価を互いに素な法集合で residues として記録し、CRT により整合整数を得て decision を確定する。
第三者は同一入力(同一データ同定)から residues を再計算し、CRT と判定を再生成できる。window / threshold / rounding の差し替えは Verify で必ず失敗する。ここで得られるのは「説明の文章」ではなく「監査結論の再生成可能性」である。
脚注(本文参照番号)
[1] NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", NIST.AI.100-1, 2023.
[2] ISO/IEC, "ISO/IEC 42001:2023 Artificial intelligence — Management system", 2023.
[3] European Union, "Regulation (EU) 2024/1689 (Artificial Intelligence Act)", 2024.
[4] Mitchell, M. et al., "Model Cards for Model Reporting", FAccT 2019, DOI: 10.1145/3287560.3287596.
[5] Gebru, T. et al., "Datasheets for Datasets", Communications of the ACM, 2021, DOI: 10.1145/3458723.
[6] NeurIPS, "NeurIPS Paper Checklist Guidelines", (public guide).
[7] Jia, H. et al., "Proof-of-Learning: Definitions and Practice", IEEE Symposium on Security and Privacy, 2021, DOI: 10.1109/SP40001.2021.00106.
[8] Chen, B.-J. et al., "ZKML: An Optimizing System for ML Inference in Zero-Knowledge Proofs," EuroSys, 2024.



コメント