信頼できる第三者による AI モデル評価のための OpenAI アウトラインプレイブック（4 分読了）

独立した信頼できる第三者による評価は、安全性エコシステムを強化する上で [重要な役割](https://openai.com/index/strengthening-safety-with-external-testing/) を果たしています。これらの評価は、最先端モデルに対して行われ、重要な機能や安全対策に関する主張に対する追加的な証拠を提供します。本稿では、これまでに得た教訓を共有し、最先端モデルを妥当に評価できる評価設計のアプローチを推奨します。これが、この分野で生まれつつある基準の策定に役立つことを願っています。 以前は多くの評価が、モデルをチャットボットのように扱っていました：評価者がユーザーとして質問を投げかけ、モデルが回答し、評価者がその出力を判断するという形式でした。今日の最先端モデルははるかに多くのことができます：ツールを使用したり、多数のステップにわたって情報を追跡したり、より大きなワークフロー内で行動したりします。これは、パフォーマンスがモデル自体だけでなく、タスクが行われる環境や、その行動を可能にするセットアップにも依存することを意味します。この周囲のセットアップ（私たちが「ハネス」と呼ぶもの）は、ツールの使用法、情報の追跡方法、ミスタイクからの回復方法など、システムの性能に関する重要な側面を変更する可能性があります。 これは、評価をどのように実施すべきか、また読者が評価報告書で何を重視すべきかを根本から変えるものです。私たちの見解では、最も有用な報告書は、結果そのもの以外に以下の2点を明確に記述しています：第一に、評価設定が何の主張を検証するために設計されたのかを特定すること、第二に、評価結果の有効性を裏付ける利用可能な証拠を共有することです。 評価で検証される主張は、通常、次の3つのカテゴリ[1](#citation-bottom-1)のいずれかに分類されます： - 能力の引き出し：モデルが評価対象の能力を実際に生み出すことが可能か？ - セーフガードのパフォーマンス：評価対象の振る舞いや攻撃に対して、テストされたセーフガード（安全装置）はどの程度堅牢か？ - 比較：異なるモデルは同等の条件下でどのようにパフォーマンスを発揮するか？ 評価報告書にはまた、結果の有効性に影響を与える可能性のある効果について、評価者がどのように確認を行ったかを説明する必要があります。これらには以下が含まれます： - リワードハッキング：タスクやスコアリングのショートカットを悪用し、評価対象とする振る舞いを示さずにシステムに点数を与えること。 - 拒絶（Refusals）：テストされている振る舞いを隠すような方法での拒絶。 - コンテナミネーション（Contamination）：評価タスク、回答、またはその類似変種がトレーニングデータに含まれていた、あるいは評価中にブラウジングなどを通じて発見可能であったために、過剰に高いパフォーマンスを発揮すること。 - 破綻した問題（Broken problems）：タスクが無効であるため、パフォーマンスが低下すること。理由としては、不公平なスコアリング（例：正解には明記されていない実装詳細が必要）、解決不可能な環境（例：重要なファイルの欠落や信頼性の低いツール）などが含まれる。 - サンドバッグ（Sandbagging）：評価されていることを認識した際に、意図的にパフォーマンスを低下させること。 適切なハネス（harness）を選択することは、最適な結果を得るために極めて重要である 我々は、特に長いトランジェクト（trajectory）にわたって動作するシステムにおいて、ハネスの役割が非常に重要であることを観察してきた。モデルがツールを使用し、状態を維持し、多くのステップにわたってミスを回復できる場合、ハネスは観測されるパフォーマンスレベルを変化させるだけでなく、評価されている能力がそもそも評価に含まれるかどうかさえ決定し得る。例えば、状態を保持し失敗したアクションを再試行するハネスであれば、単純なハネスでは完了できない多段階タスクを、同じモデルが完了できる可能性がある。 以下の表では、評価者が主張したいと考える3種類の主張と、各主張に必要だと我々が考えるハネスを分けて示す。 **評価が支援しようとしている主張を明確にする** **適切なハルネスの選択** **報告すべき証拠** 強力な誘発下での能力：システム A は、その最も信頼できるパフォーマンスを引き出すように設計されたセットアップにおいて、X 型のタスクを完了できる。 システムに対して、有能なユーザーが合理的に使用するであろうハルネス、ツール、足場（スキャフォールディング）、および予算を含む、最も強力かつ信頼性の高い誘発セットアップを使用すること。 ハルネスとツールのセットアップ、誘導ガイダンス、許可された予算/努力、トークン数/コスト/時間、そしてなぜこのセットアップが主張される能力の信頼できる代理指標となるのか。異なる最適化セットアップ下でシステムを比較する場合は、「システム間比較」または「強力な誘発比較」としてラベル付けすること。 統制された比較：システム A は、共有評価セットアップの下でシステム B よりも優れたパフォーマンスを発揮する。 タスク、スコアリング、および予算は固定状態に保つ。比較対象となるシステムに対して合理的な最大誘発を提供するために、共有ハルネス/ツールセットアップを使用するか、事前に選択された標準化されたハルネスの固定セットを使用すること。 共有タスクセット、ツール、スコアリング方法、ハルネス、予算、トークン効率/コスト、および既知の制限事項。コーディングエージェントの評価においては、Codex CLI などのオープンソースハルネスが、システム間で固定されたエージェントループとツールインターフェースを提供できる。最大誘発のための理想的なアプローチは、各タスクとシステムのために個別に最適化されたハルネスを設計することだが、現状では実践的に実行することは困難である。 **Claim the evaluation is trying to support** **Appropriate harness choice** **Evidence to report** Capability under strong elicitation: System A can complete tasks of type X when the setup is designed to draw out its strongest credible performance. Use the strongest credible elicitation setup for the system, including the harness, tools, scaffolding, and budget a capable user would reasonably use. The harness and tool setup, elicitation guidance, budget/effort allowed, tokens/cost/time, and why the setup is a credible proxy for the claimed capability. If comparing systems under different optimized setups, label it as a system-to-system or strong-elicitation comparison. Controlled comparison: System A outperforms System B under a shared evaluation setup. Keep the tasks, scoring, and budget fixed. Use either a shared harness/tool setup or a fixed set of standardized harnesses chosen up front to provide reasonable max elicitation for the systems being compared. The shared task set, tools, scoring method, harness, budget, token efficiency/cost, and known limitations. For coding-agent evaluations, an open-source harness such as Codex CLI can provide a fixed agent loop and tool interface across systems. The ideal approach for maximum elicitation would be to optimize a bespoke harness for each task and system, but doing so is currently impractical in practice. 誘発攻撃下での堅牢性の保護：システム A の防護策は、関連するモデルの振る舞いまたは誘発攻撃に対して十分である。 関連する敵対者モデルの下で最も強力な信頼できる攻撃を誘発するように設計された防護策テスト設定を使用すること。 評価者がどのように関連するモデルの振る舞いを特徴付け、どの防護策構成がテストされ、どのような誘発戦略が用いられ、それを実行するためにどのハーン（harness）が使われ、また許容された予算または労力がどれほどであったかについて記述した内容。 **能力主張はそれを支える誘発の強さと同じ程度しか強くならない：評価者は、タスクと評価が測定しようとする能力に最も適合するハーンを選択する必要がある。** 標準化されたハーンは同一条件下でのシステム比較には適している場合もあるが、モデルがタスクを遂行するために役立つ特定のハーン機能を欠くことで、能力を過小評価する可能性がある。例えば、OpenAI のサイバーレンジにおける GPT‑5.5 のパフォーマンスは、ハーンの選択が長時間かつ多段階のツール使用を必要とするタスクにおいて測定される能力にどのように実質的な影響を与えるかを示している：ハーンが [compaction](https://openai.com/index/equip-responses-api-computer-environment/)（コンパクション）を使用して、インタラクションが長くなるにつれてタスクに関連する文脈を保持する場合、モデルのパフォーマンスは向上する。これは、特定のモデルにおいては compaction を省略したハーンではパフォーマンスの誘発が不十分になることを示している。 高い成功率の方が望ましい 他の公開された評価[2](#citation-bottom-2) も、ハネスと予算の選択が評価結果を変化させることを示しています。**テスト時の計算リソースを増やすことは、特に成功の検証が容易なドメイン（多くのサイバータスクなど）において、評価が引き出す能力を大きく変化させる可能性があります**。[UK AISI のサイバーレンジ評価(新しいウィンドウで開く)](https://arxiv.org/pdf/2603.11214) では、予算を 10M トークンから 100M トークンに引き上げることでパフォーマンスが最大 59% 向上し、テストされた最高予算においてもなおパフォーマンスは増加し続けていました。この詳細を記述することは評価の解釈可能性を高めます：これは読者に対して、結果がテストされた誘発設定（elicitation setup）にどのように依存しているかを示すものです。追加の予算を与えてもパフォーマンスがまだ改善している場合、そのスコアは測定された能力の上限としてではなく、そのハネスと予算におけるパフォーマンスとして記述されるべきです。能力は往々にしてリソースに依存するものであり、一度きりで明確に測定できる固定量ではありません。成功を反復試行 across して測定できる領域では、報告書は固定トークン予算での成功率だけでなく、成功した解決にかかる期待コストも考慮すべきです。これにより、深刻度の解釈が容易になります：反復試行のコストが関連する脅威モデルの範囲内であれば、低い成功率でも実質的に意味を持つ場合があります。能力に関する主張においては、回避可能な誘発不足は測定上の失敗です：もしハネスや予算が、システムが本来生み出すはずの行動を示すことを妨げているなら、そのスコアは主張されている能力を測定していることにはなりません。評価者が可能な限り誘発を最大化してもなおパフォーマンスが改善し続けている場合、報告書ではそれを明確に記述し、結果が単なる下限推定値であることをはっきりと示すべきです。 **保護機能のテストでは、攻撃者が利用可能なリソース（カスタムハッチスを含む）を考慮しない場合、攻撃が成功する可能性やその深刻度を過小評価する恐れがあります。**[UK AISI の GPT‑5.5 サイバー評価(新しいウィンドウで開く)](https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities)において、専門家のレッドチームは、OpenAI が提供した悪意のあるクエリ全体（マルチターン・エージェント設定を含む）で違反するサイバーコンテンツを引き出す普遍的なジールブレイクを発見しました。彼らは Codex を用いてカスタムハッチスを作成し、モデルの攻撃性能を強化しました：これは再利用可能な保護機能バイパスパターンを対話に埋め込み、そのパターンをターンやブロック全体で維持し、OpenAI が提供した悪意のあるサイバークエリすべてに適用するものです。保護機能のテストは、敵対者と同様の条件で行うべきです。もし専門家の悪用に対する堅牢性に関する主張であれば、定義された予算の下で最も強力な信頼できるエンドツーエンドの攻撃戦略を評価すべきであり、その戦略を維持・再利用するために必要なハッチスも含まれる必要があります。そうでなければ、結果は較正が誤るリスクがあります：より単純なプロンプトへの耐性という限定的な主張しか支持できず、誘発手法が実装された際の攻撃の深刻度や成功確率を見逃す可能性があり、また予算を過剰に与えた場合、問題の発生確率や深刻度を過大評価する恐れもあります。 **標準化されたハーンによる比較には適した時と場所がありますが、評価者はなぜ一貫したセットのハーンを使用することが適切なのか、そしてそれがどのような主張を裏付けることができるのかを明確に述べるべきです。**[METR の時間軸評価](https://metr.org/time-horizons/)は、より広範で適切に固定された評価設定の一例です。これは、評価対象となるシステム間で比較可能な結果を生み出すように設計されています。METR は共通の結果指標を定義しており、これは AI エージェントが特定の信頼性レベルで成功すると予測される、人間によるタスクの典型的な所要時間です。また、報告される各推定バッチ内で、共有されたタスクリスト、スコアリング手法、適合手法、および [Triframe や ReAct](https://metr.org/notes/2026-02-13-measuring-time-horizon-using-claude-code-and-codex/) といった再利用可能な足場（scaffolds）の小さなセットを適用します。METR がタスクリストを拡張し、Vivaria という名前のフレームワークから Inspect という名前のフレームワークへと評価インフラストラクチャを移行した際、その変更を報告し（[Time Horizon 1.1 の更新](https://metr.org/blog/2026-1-29-time-horizon-1-1/)）、新しい評価設定の下でモデルを再評価しました。これが標準化された評価設定、すなわち一貫したハーンセットの価値です。これにより、読者はスコアの差が測定環境の変化ではなく、比較対象となるシステム間の本当の違いを反映しているのだと確信できるようになります。 第三者の評価レポートには、その評価設定がどのような主張を裏付けるものなのかを明記し、テストされた内容がその広範な主張とどの程度一致しているかを説明し、結果に影響を与えたハーン（harness）の選択について詳述し、これらの選択が評価間においてどのように変化するかを詳細に記述し、さらに結果がどのように生成され、主張に対してどの程度一般化できるかを示す補足証拠を含めることを推奨します。 評価スコアは、モデルがより能力が高まるにつれて誤解されやすくなります。実際の能力と比較して、モデルが評価されていると認識し戦略的にパフォーマンスを低下させた場合、評価スコアは人為的に低く表示される可能性があります。また、タスク、プロンプト、採点者、またはハーンにおけるショートカットを悪用した場合、スコアが過大評価されることもあります。さらに、コンタミネーション（モデルがすでに答えを知っているか、タスクを解かずに答えを見つけられる状態）や、曖昧さがある、誤って採点されている、解決不可能な、あるいは意図しないショートカットに脆弱な「壊れた」問題によってもスコアは歪められます。したがって、評価レポートでは、これらのハザードに関する議論と併せて主要なスコアを提示し、読者がスコアが意図した行動を反映しているかどうかを判断できるようにする必要があります。 ハルネス、予算、ツール、スコアリングルール、モニター、レビュー手順はすべて、エージェントが意図されたタスクを解決しているのか、回避しているのか、暗記しているのか、それとも迂回する道を見つけているのかに影響します。信頼できる報告書ではこれらのチェックが可視化され、評価が実行されるたびに評価者はこれらの行動に関するサンプルを検証する必要があります。 **報酬ハッキング** 報酬ハッキングとは、意図された能力を反映しない方法で高い評価スコアを獲得することを指します。ここでは、システムが評価の目的である作業を行うのではなく、タスク、採点者、プロンプト、またはハルネスを利用することで信用を得るという懸念があります。[METR による GPT 5.4 の評価（新しいウィンドウで開く）](https://t.co/FRWeH7QMnl) はなぜこれが重要なのかを示しています：モデルは最初のパスで約 13 時間の時間範囲として記録されるはずのタスクに成功する率を達成していましたが、人間のレビューでは、その成功の一部が報酬ハッキングによるものであることが判明し、報酬ハッキングのない事例のみを対象とした結果に修正すると、推定値は約 6 時間に低下しました。評価者はこのような調整の必要性を評価し、必要な場合は明確に報告すべきです：読者がどの一見した成功が無効化されたか、なぜ無効化されたか、そして結果がその判断にどれだけ依存しているかを把握できる場合、能力推定値ははるかに有用になります。 ![image](https://images.ctfassets.net/kftzwdyauwt9/7nO5WpPa0GDm8Dls6FS8o4/a4cb02d049e078be75df88f1289fc34f/extracted_graph_gpt5-4.png?w=3840&q=90&fm=webp) **拒絶（Refusals）** モデルは、安全対策のために能力評価において期待されたパフォーマンスを発揮できない場合があります。モデルがタスクを完了するのではなく拒絶することで、本来の能力よりも低い評価結果を示すことがあります。したがって、報告書では拒絶が評価結果に含まれているかどうか、また含まれる場合はそのためにどの程度のサンプル数が損なわれたかを説明する必要があります。 **汚染（Contamination）** 汚染は、[公開または再利用されたベンチマーク](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/)において最も重要です。タスクや回答、あるいはその近傍のバリエーションがトレーニングデータに含まれている場合、またはブラウジング機能を持つエージェントによって発見可能な場合、パフォーマンスはモデルの能力ではなく、記憶や検索の結果を反映している可能性があります。評価者は可能であればプライベートなタスクや新たに構築されたタスクを優先し、解決する前にモデルがタスク固有の詳細を再現できるかどうかを検証すべきです。 **破損した問題（Broken problems）** 破損した問題とは、偶然にも解くことができないような問題を指します。破損した問題は [十分に一般的](https://rdi.berkeley.edu/blog/trustworthy-benchmarks-cont/) であるため、標準的な妥当性のリスクとして扱う必要があります。これには、誤った正解（ground truth）、曖昧なプロンプト、欠落しているファイル、不安定なサービス、不公平な採点基準、隠された回答ファイルや正解パッチを含むリポジトリ履歴など、近道が暴露される環境が含まれます。 **Sandbagging** ※注：原文のこの段落は日本語訳が存在しないため、そのまま保持します。 モデルやシステムによるサンバギングとは、強力なパフォーマンスを発揮することが何らかの目的と矛盾する場合に、戦略的にパフォーマンスを低下させることを意味します。Apollo の [GPT‑5.5 評価(新しいウィンドウで開く)](https://deploymentsafety.openai.com/gpt-5-5/external-evaluations-for-sandbagging---apollo-research) は、モデルが高評価スコアが学習の解除やデプロイのブロックを引き起こす可能性があることを理解する文脈を作成することでこれを検証しました。GPT‑5.5 は依然として正しく回答しましたが、これは戦略的なパフォーマンス低下の行動的証拠はほとんどないことを示唆しています [3](#citation-bottom-3)。しかし、推論トレースのレビューは重要な背景情報を追加しました：Apollo はサンバギング条件のサンプルの 52% で中程度以上のアライメント評価への意識の兆候を検出しましたが、反事実的ケースでは 0% でした。この証拠は結果の解釈を複雑にしますが、最終的には読者により多くのシグナルを与えます：読者は安心させる行動的結果と、それを過大解釈しないよう注意すべき理由の両方を見ることができます。 ## より強力な評価をどのように支援しているか 強い主張には、その振る舞いを引き出すための適切なハネス（評価枠組み）と、結果が妥当であることを示す有効性チェックの両方が必要です。ハネスと有効性チェックが評価結果の一部であるという私たちの見解は、実践における第三者による評価をどのように支援するかという形に影響を与えます： - 評価者に対して、特定の最大限の誘導ガイダンスを共有しています。 - 能力評価者には、OpenAI モデルの共通基準として Codex を使用することを求めています：テストは、単に簡素化されたモデルインターフェースを通じて行うのではなく、ユーザーが頼りにする可能性のある同じエージェント型インターフェースを通じて少なくともベースラインを実行する必要があります。 - また、欺瞞、砂袋行為（sandbagging）、評価への意識を評価するために必要な場合に限り、推論トレースやその他の中間アーティファクトを利用可能にしています。METR と Apollo は、GPT‑5 以降の OpenAI 評価においてこのアクセス権を活用してきました。 - 最後に、コンテキスト管理やツールアクセスからリトライ動作、スコアリング、リソース予算に至るまで、ハッチング（harness）の選択が結果をどのように materially 変化させるかをより深く理解するための研究に優先順位をつけています。 ## これが評価基準と将来の研究方向に与える意味 これらの推奨事項は、個々の評価レポートの改善だけでなく、最先端 AI の評価と報告に関する新たな [国内 (新しいウィンドウで開く)](https://www.nist.gov/news-events/news/2026/01/towards-best-practices-automated-benchmark-evaluations) および [国際 (新しいウィンドウで開く)](https://www.iso.org/standard/91609.html) 基準の策定にも資するものです。今後、第三者による評価基準では、意思決定者が特定の評価が何を支持しているのか、どのシステムがテストされたのか、結果がどのように引き出されたのか、そして評価者がその妥当性をどのように確認したのかを理解できる十分な詳細を要求すべきです。エージェント機能（agentic capabilities）が重要なタスクで最先端システムをテストする場合、詳細には（セキュリティや機密に関する懸念がある場合は除き）、以下の内容を含める必要があります： - 主張：評価がシステム間の比較を行うものか、能力の上限を推定するものか、それとも安全対策を検証するものかを明確にすること。 - 評価内容：読者が、その評価が実際にどのようなスキル、行動、あるいは失敗モードを検証しているのかを理解できるほど、タスクまたはタスク分布に関する十分な詳細を含めること。 - 検証対象システム：モデル、推論設定、ツールアクセス権限、ハネス（評価枠組み）、および安全対策を明記すること。 - バジェット：ターン数、トークン数、試行/再試行回数、実時間、推論コスト、および該当する場合は成功した解決ごとの予想コストを含めること。 - 誘発手法：結果を引き出すために使用されたハネスの選択と、実際に検証された内容が主張されるより広範な主張をどの程度反映しているかについて説明すること。 - 妥当性チェック：報酬ハッキング、評価への意識、汚染、拒絶、砂場（意図的な能力隠し）など、結果を損なう可能性のある行動を検索する審査員の手法と、確認された事例がスコアリングや解釈にどのように影響したかを含めること。 ハネスの選択や妥当性チェックを欠いた基準は、システムの能力を過小評価するか、安全に関する主張に対する信頼性を過大評価する恐れがあります。強力なハネスと誘発手法の構築は依然として未解決の研究領域であり、さらなる調査と投資の対象となるべき重点分野です。

信頼できる第三者による AI モデル評価のための OpenAI アウトラインプレイブック（4 分読了）

背景や根拠まで確認しますか？

調べる

選ぶ

サイト