単一スコア依存から脱却へ、AI評価の実行条件開示が開発と選定を変える

【何が起きたか】英AISIとEvalEvalによる評価インフラの共有発表

英国AI安全研究所（AISI）とEvalEvalは2026年9月22日、評価結果の共有インフラに関する提携を発表しました[1]。AISIはAIの安全性評価や技術的リスクを専門に調査する英国の政府機関です。一方のEvalEvalは、AI評価の再現性向上を目指す国際連携組織です。AISIは今後、EvalEvalの共有インフラを活用して評価データを広く公開します。これにより、再現可能で第三者が検証しやすい評価研究を後押しします[1]。

今回の公開では、AISIの論文における主要実験を対象に詳細な設定情報が開示されました[2]。対象となったのは、HealthBench、FrontierMath、Humanity’s Last Exam、SWE-Bench Pro、Terminal-Bench 2.0の5つのベンチマークです[2]。ベンチマークとは、AIモデルの性能を測定するための標準テストを指します。評価対象には、Claude Opus 4、Claude Opus 4.5、Claude Opus 4.6、GPT-5、GPT-5.2、GPT-5.4が含まれます[2, 4]。これらは6種類のフロンティアモデル（最先端の高性能モデル）です。

これら主要実験に加えて、2件のサイバーセキュリティ評価結果も併せて公開されました[3, 4]。具体的には、Cyber CTFsとThe Last Onesと呼ばれる実践的な評価データが含まれています[3]。今回の取り組みの最大の特徴は、単一の集約スコアを提示する手法にとどまらない点にあります[5]。評価に用いた共通プロンプトや実行ハーネス、推論時の計算予算まで詳細に記録されています[5]。ハーネスとは、評価の実行や計測を自動化するソフトウェア基盤のことです。

さらに、反復提出の手順や正誤フィードバックの有無、安全なサンドボックスの構成も開示されました[5]。サンドボックスとは、外部システムへの影響を防ぐために隔離された実行環境です。加えて、モデルの応答に至るサンプル単位の思考・行動軌跡も記録されています[5]。これにより、評価結果がどのようなプロトコルや実行条件に依存しているかを第三者が厳密に検証できるようになりました[5]。

【なぜ今か】単一スコアへの依存が生む「再現性の危機」

AI評価は、モデルの基本性能や安全性、ガバナンスの妥当性を判断する極めて重要な証拠として扱われています[6]。しかし従来の評価結果は、論文やリーダーボード、企業のブログ、評価ハーネスの生ログなど多岐にわたる形式に分散していました[6]。リーダーボードとは、モデルの性能順位を一覧表示する公開ランキング表です。形式がバラバラだったため、同一モデルと同一ベンチマークを対象にした記録であっても、横断的な比較が困難でした[6]。

従来の報告では、誰が評価を実行したのかや、API（ソフトウェア同士が機能やデータをやり取りする仕組み）などのアクセス経路、生成設定、指標の厳密な定義が伏せられがちでした[7]。Evaluation Cardsが2026年6月時点で実施した調査では、深刻な実態が判明しています[8]。5万件を超える評価記録のうち、実に96.5%が再実行に必要な最小限のフィールドを少なくとも1つ欠落させていました[8]。出力長を制限するmax-tokensは95.6%、出力の多様性を左右するtemperatureは93.9%の記録で記載がありませんでした[8]。

評価記録の項目	欠落率（%）	対象データ
最小再現フィールド（少なくとも1つ欠落）	96.5%	5万件超の評価記録
最大生成トークン数（max-tokens）	95.6%	5万件超の評価記録
温度パラメータ（temperature）	93.9%	5万件超の評価記録

メタデータ（実行条件の付随情報）が欠落した結果、同じモデルでも実行者や設定によってスコアが激変する問題が起きています[9]。たとえば大規模言語モデルのLLaMA 65Bでは、総合学術ベンチマークのMMLUにおいて63.7点と48.8点という2つの異なるスコアが報告されています[9]。条件が不明なまま単一の数値だけを比較すると、単なる設定の差をモデル本来の能力差と誤認してしまいます[9]。

特に2026年の最先端モデルでは、推論時に投入する計算量が性能を大きく左右します[10]。そのため、固定された単一の計算予算で測定したスコアは、能力ではなく評価設定の制約を反映しているにすぎない場合があります[10]。ベンチマークのスコアは、トークン予算や反復提出の回数、並列試行の有無といった実行プロトコルに強く依存します[11]。従来の単一スコア表示では、モデル本来の潜在能力と実行プロトコルの影響を分離できません[11]。

AISIが行った2026年の分析によると、トークン予算を一般的な100万トークン（1M）から1000万トークン（10M）へ拡大した場合、ソフトウェア工学タスクの性能は約25%向上しました[12]。同様に、数学や学術分野のタスクでも性能は約22%向上することが確認されています[12]。与える推論計算量によって成果が大きく変わるため、計算予算の記録は不可欠です[12]。

従来の報告形態では、ベンチマークの定義、実行時の設定、モデルのメタデータが別々に管理されていました[13]。そのため、同一のテスト名であっても、プロンプトや予算、サンドボックス条件の違いを文脈付きで把握できませんでした[13]。また、集約スコアだけでは誤答の原因やツールの利用経路を後から診断できません[14]。こうした不透明さを解消し、診断可能性を確保することが急務となっていました[14]。

【何が変わるか】標準化スキーマ「EEE」と「Evaluation Cards」の技術的仕組み

今回提供された共有インフラの中核を成すのが、Every Eval Ever（EEE）と呼ばれる標準化仕様と、Evaluation Cardsという可視化基盤です[15]。EEEは評価を実行するためのツール自体ではなく、各種ログを共通形式で蓄積・検証・変換するデータ基盤です[16]。スキーマとは、データの構造や項目を厳密に定めた仕様書を指します。EEEは論文やリーダーボード、ローカル環境の実行ログを標準形式で統合します[16]。

AISI自身が開発するInspect Evalsは、Inspect AI上で動作するテスト実装を共有するための登録簿です[17]。これに対してEEEは特定フレームワークに限定されず、外部の評価結果を広く取り込んで同一レコードに統合する役割を担います[18]。学術評価フレームワークのHELMが厳密な実験設計を中心とし、Hugging Face Community Evalsがモデルカード上での公開レイヤーを担うのに対し、EEEはその基底で構造化データを保持します[19, 20]。企業のシステムカードと比べても、組織内外の結果を同一スキーマで機械的に突き合わせられる点が異なります[21]。

EEEの集約レコードは、スキーマ版、評価実行ID、取得時刻、出典情報、モデル情報、評価ライブラリ、評価結果を必須項目として保持します[22]。これにより、誰がどのような環境で実施した評価かを厳密に追跡できます[22]。実行条件を格納するgeneration_configには、温度やmax_tokensのほか、プロンプトテンプレート、推論やエージェントの設定、サンドボックス構成などが記録されます[23, 24]。さらに評価指標のIDや単位、良し悪しの方向性、審査員LLMの設定まで細かく標準化されます[25]。

また、単一の平均値だけでなく、標準誤差や信頼区間、標準偏差、サンプル数などの不確実性情報も記録可能です[26]。加えて、EEEは集約結果とインスタンス（個別の問題や回答）単位のデータを厳密に結び付けます[27]。集約JSONには補助JSONLファイルへのパスやチェックサムが記載され、サンプル側のハッシュ値と照合できる仕組みです[27]。

インスタンス単位の記録では、問題入力、モデルの生出力、回答の抽出方法、正誤判定、消費トークン数、エラー内容などが保存されます[28]。AIエージェントによるマルチターン評価では、各ターンの発言内容や推論トレース、ツール呼び出しの引数までmessages配列に保存されます[29]。さらに、Inspect AIやHELM、lm-evaluation-harnessのログを自動変換するコンバータと整合性検査機能も備えています[30, 31]。これらのデータはEvaluation Cardsによって文脈付きの統合レコードとして表示され、誰でも比較できるようになります[32]。

【誰に影響するか】5つのステークホルダーにもたらす変革と負担

AI評価インフラの標準化と共有は、エコシステムに関わる主要な関係者に多様な影響をもたらします。まずAI研究者にとっては、既存の評価ログを共通形式へ変換して再利用できる大きなメリットがあります[33]。他の研究者が行った実験の追試やメタ分析、失敗原因の細かな診断を効率的に進められます[33]。一方で、実行環境や生成設定、サンプル出力を厳密に記録し、スキーマ検証を通過させるための作業負担が増加します[34]。

モデルを開発する企業にとっては、自社の公式アカウントから検証済み評価を提出できる利点があります[35]。EvalEval上で検証済みチェックマークを表示し、第三者評価との設定差を説明しやすくなります[35]。しかし、都合の良い単一スコアだけを宣伝することは難しくなります[36]。推論予算やプロンプト、ツールの利用履歴、失敗事例まで開示し、自社モデルの弱点や不確実性を説明する透明性のコストが生じます[36]。

独立した評価機関は、Inspect AIやHELMなど異なる基盤のログを共通形式に集約できるようになります[37]。これにより、評価結果の公表や外部機関とのデータ連携をスムーズに標準化できます[37]。その反面、既存ハーネスの出力をEEE形式へ変換するアダプタの実装や保守、スキーマ改定への追随、機密情報の確認といった運用負担を負うことになるとみられています[38]。

規制やルール作りを担う政策担当者は、Evaluation Cardsを活用して評価の再現性や完全性、データの出所を網羅的に確認できます[39]。モデルや評価フレームワークの信頼性を横断的に調査する上で有効な材料となります[39]。ただし、標準化された記録を無条件で規制の証拠として認めることはできません[40]。ベンチマーク自体の妥当性やプロトコル、未公開情報の有無などを個別に審査する負担が残るとされています[40]。

一般のモデル利用者や導入企業は、同じモデル名やベンチマーク名であっても設定の違いを見分けられるようになります[41]。自社の業務要件や想定コストに近い条件で測定されたデータを選択しやすくなります[41]。一方で、評価カードを読み解く知識や、信頼区間、サンプル単位の失敗例を自ら精査する調査負担が増えます[42]。評価条件を確認することで、単一スコアだけに基づく選定を避けやすくなる可能性があります[42]。

ステークホルダー	インフラ共有に伴う利点	直面する新たな運用負担
AI研究者	共通形式のログや出力を再利用でき、追試やメタ分析、失敗原因の診断を効率化できます[33]。	実行者や生成設定、指標定義、サンプル出力を記録し、スキーマ検証を通す作業が増加します[34]。
モデル開発企業	公式アカウントから検証済み評価を提出し、第三者評価との設定差を明示できます[35]。	推論予算やプロンプト、ツール利用、失敗例などの公開に伴い、透明性を保つコストが生じます[36]。
評価機関	異なる評価基盤のログを共通形式へ変換し、結果の公開やデータ連携を標準化できます[37]。	ログ変換アダプタの実装や保守、スキーマ追随、機密管理などの負担が生じるとみられます[38]。
政策担当者	統合された記録により、評価の再現性や完全性、出所を横断的に調査できます[39]。	記録を鵜呑みにせず、ベンチマークの妥当性やプロトコルを個別に審査する負担が残るとされます[40]。
モデル利用者	生成設定やハーネスの違いを識別し、実用途に近い条件の評価結果を選択できます[41]。	評価カードの仕様や推論予算、失敗例などを精査する調査負担が増えると考えられます[42]。

【今後の課題と展望】透明性と安全保障のジレンマ、実世界妥当性の確保へ

評価データの標準化と共有は大きな前進ですが、透明性の追求は安全保障上のジレンマと直面します[43]。評価の公開は説明責任や第三者による検証を促進します[43]。しかし、透明性を確保するだけでは、生物兵器やサイバー攻撃への加担、AIの制御喪失といった重大なリスクを防止できません[43]。そのため、安全に関する情報をどこまで公開すべきかという境界線が議論されています[43]。

特にサンプル単位の実行ログや対話履歴を公開する際、APIキーや認証トークンなどの秘密情報が混入するリスクが存在します[44]。またエージェント評価では、モデルが外部システムや機密データにアクセスする可能性があるため、安全な隔離環境が不可欠です[45]。評価インフラそのもののネットワーク制御やホスト保護を徹底しなければ、重大な事故につながる恐れがあります[45]。

さらに、ベンチマークの問題や正解、思考軌跡を公表すると、モデルがそれらを学習・記憶してしまうデータ汚染が発生します[46]。汚染が起きると、モデルの真の能力ではなく公開データへのアクセス能力を測ることになってしまいます[46]。この課題に対し、一部のテストデータを非公開に保つ「ホールドアウト」方式との併用が有効な折衷案として採用されています[47]。ホールドアウトとは、過学習を防ぐために秘匿される検証用データのことです。

とりわけサイバーセキュリティ評価においては、具体的な攻撃手順や脆弱性を完全公開すると、実環境へのサイバー攻撃に悪用される恐れがあります[48]。そのため、脆弱性の詳細情報を非公開にする慎重な対応が取られています[48]。また安全評価全般の実務においても、一般向けには機密情報を黒塗りにした編集版を公開し、専門レビュアーにのみ完全版を開示する段階的開示が行われています[49]。共有基盤の設計においても、集約スコアと設定を公開層に置き、個人情報や危険な実行軌跡は非公開層に分離する仕組みが望ましいとされています[50]。

加えて、どれほど厳密に評価手順を再現できたとしても、それだけで実世界での妥当性が保証されるわけではありません[51]。テスト環境が実運用の入力データやシステム制約を十分に反映していなければ、現場での性能は予測できません[51]。ベンチマークは本来測りたい能力の代理指標にすぎず、指標の妥当性が欠けていれば、高スコアであっても安全性や有用性は証明されません[52]。

さらにモデル自身が評価中であることを察知して振る舞いを変える問題や、稀にしか生じない危険な挙動を見逃す懸念も指摘されています[53]。公開ベンチマークで高いスコアを出していても、単なる問題文の記憶にすぎず、未知の実務課題に対応できない例も散見されます[54]。したがって実世界の安全性を確認するには、事前の静的テストだけでなく、運用開始後に動的な入力や予期せぬ挙動を監視し続ける体制が不可欠です[55]。

今後の標準化に向けては、モデル名だけでなく、利用目的や脅威モデル、ツール権限、推論予算、適用限界などを必須項目として記録すべきだと提唱されています[56]。また評価の信頼性を高めるためには、開発者のみならず独立した評価者や分野専門家、規制当局など多様な主体が評価設計に関わることが求められます[57]。今後は、標準化された事前評価や敵対的テスト、非公開ホールドアウト、展開後の運用監視、事故報告などを組み合わせた包括的な枠組みの構築が重要になります[58]。