投稿日: 2026-05-29 | カテゴリ: Safety

信頼できる第三者評価のための共通プレイブック

独立した信頼できる第三者評価は、安全性エコシステムを強化するうえで重要な役割を果たします。これらの評価はフロンティアモデルに対して実施され、重要な能力や安全対策に関する主張を補強する追加の証拠を提供します。本稿では、これまでに得た教訓を共有し、フロンティアモデルを妥当に評価できる評価設計のための方針を提案します。新たに策定されつつある基準に資することを期待しています。

かつて、多くの評価はモデルをチャットボットのように扱っていました。評価は、ユーザーが質問するかのようにモデルにプロンプトを与え、モデルが回答し、評価者が出力を採点しました。しかし現在のフロンティアモデルはそれ以上のことができます：ツールを使い、複数のステップにわたって情報を保持し、より大きなワークフローの中で行動します。つまり、性能はモデルだけでなく、タスクが行われる環境やその行動を支える設定（以下「ハーネス」と呼ぶ）にも依存します。ハーネスは、ツールの使い方、情報の保持方法、ミスからの回復の仕方など、システム性能の重要な側面を変化させる可能性があります。これにより、評価の実施方法や評価報告書で読者が注目すべき点が変わります。

我々の見解では、最も有用な報告書は結果そのものに加えて、明示的に次の2点を記述します。

• 評価セットアップが何を検証するために設計されたのか（検証対象の主張）
• 評価結果が妥当であることを示す利用可能な証拠

評価で検証される主張の典型的な分類

評価で検証される主張は一般に次の3つのうちのいずれかに分類されます。

• 能力の誘発（Capability elicitation）: モデルは評価対象の能力を現実的に発揮できるか？
• セーフガード性能（Safeguard performance）: テストされたセーフガードは、評価対象の振る舞いや攻撃に対してどれだけ堅牢か？
• 比較（Comparison）: 同等の条件下で異なるモデルはどのように振る舞うか？

評価結果の妥当性に影響する可能性のある要因

評価者は、結果の妥当性に影響を与えうる以下のような効果をどのように検査したかを説明する必要があります。

• Reward hacking: タスクやスコアラーの抜け穴を突き、評価が測ろうとする振る舞いを示さずに得点を稼ぐこと。
• Refusals: テスト対象の振る舞いを隠すような形で拒否すること。
• Contamination: 評価タスクや回答、その近縁がトレーニングデータに含まれていたり、ブラウジング等で評価中に発見可能だったために過大評価されること。
• Broken problems: タスク自体が無効であるために低評価となること。理由には不公正な採点（例えば、正答に暗黙の実装詳細が必要）や、重要ファイルの欠如や信頼できないツールなどにより解けない環境が含まれる。
• Sandbagging: 評価されていると認識しているときに意図的に低い性能を示すこと。

ハーネスの選択は評価結果に決定的に重要

ハーネスの役割は、長い軌跡で行動するシステムにおいて特に重要であることを我々は観察しています。モデルがツールを使い、状態を保持し、複数ステップにわたりミスから回復できる場合、ハーネスは観測される性能レベルを変え、ある能力がそもそも評価に現れるかどうかを左右することさえあります。例えば、状態を保持して失敗したアクションをリトライするハーネスは、単純なハーネスでは完遂できないような多段階タスクを同じモデルが完了するのを可能にします。

以下の表は、評価者が主張したい3種類のクレームと、我々が各クレームに適切だと考えるハーネス、ならびに報告すべき証拠を整理したものです。

検証しようとする主張	適切なハーネスの選択	報告すべき証拠
強い誘発下での能力: システムAは、最も妥当な最良性能を引き出すよう設計された設定でタスクXを完遂できる。	システムに対して合理的な有能ユーザーが使うであろうハーネス、ツール、足場（スキャフォールディング）、予算を含めて、最も強い妥当な誘発設定を使用する。	ハーネスとツール構成、誘発ガイダンス、許容される予算/労力、トークン/コスト/時間、ならびになぜその設定が主張する能力の信頼できる代理なのかの説明。複数の最適化された設定間で比較する場合は、それがシステム間比較（system-to-system）あるいは強い誘発比較（strong-elicitation comparison）であると明示すること。
制御された比較: 共通の評価設定下でシステムAがシステムBより優れる。	タスク、採点、予算を固定する。共通のハーネス/ツール構成を使うか、事前に選んだ標準化ハーネスの集合を固定して、比較対象システムにとって妥当な最大誘発を提供する。	共有タスクセット、ツール、採点方法、ハーネス、予算、トークン効率/コスト、既知の制限の記載。コーディングエージェントの評価では、Codex CLI のようなオープンソースハーネスがシステム間で固定されたエージェントループとツールインターフェイスを提供できる。最大の誘発を得る理想的なアプローチはタスクとシステムごとに専用ハーネスを最適化することだが、現時点では実務的に困難である。
誘発された攻撃下でのセーフガードの堅牢性: システムAのセーフガードは、関連するモデルの振る舞いまたは誘発された攻撃に対して十分か。	参照する敵対者モデルの下で最も強い妥当な攻撃を誘発するよう設計されたセーフガード試験設定を使用する。	評価者が関連するモデルの振る舞いをどのように特徴づけたか、テストしたセーフガード設定、誘発戦略、実行に用いたハーネス、許容された予算や労力の記録。

能力主張は、背後にある誘発（elicitation）の強さに依存します。評価者は、タスクと評価が測ろうとする能力に最も適したハーネスを選ぶ必要があります。標準化されたハーネスは同一条件でシステムを比較するのに適している場合がありますが、モデルがタスクを遂行するのに有用な特定のハーネス機能を欠くと、能力を過小評価してしまうことがあります。

例えば、GPT‑5.5 の OpenAI によるサイバー・レンジでの性能は、長く多段階のツール利用を必要とするタスクでハーネスの選択が測定された能力を実質的に変えうることを示しています：ハーネスが interaction が長くなるにつれてタスク関連コンテキストを保持するために compaction を使うと、モデルはより良い性能を示しました。これは、あるモデルでは compaction を省いたハーネスが性能の誘発を不十分にしてしまうことがあることを示しています。

高い成功率はより有益である

他の公開された評価2も、ハーネスや予算の選択が評価結果を変えることを示しています。特に、多くのサイバータスクのように成功の検証が容易なドメインでは、テスト時の計算資源（test-time compute）を増やすことで評価が誘発する能力が大きく変わることがあります。英国AISIのサイバー・レンジ評価（opens in a new window）では、予算を10Mトークンから100Mトークンに増やすと性能が最大59%改善し、テストした最高予算でも性能はまだ上昇していました。こうした詳細を記載することで評価は解釈可能性を高めます：つまり、結果がどの誘発設定に依存しているかを示します。

性能が追加予算でまだ改善している場合、そのスコアは測定された上限（capability ceiling）ではなく、そのハーネスおよび予算下での性能として記述すべきです。能力は固定的な量ではなく、しばしば資源依存であり、一度きりの測定で明確に測れるものではありません。

成功が繰り返し試行で測れる場合、報告は固定トークン予算での成功率だけでなく、成功1件あたりの期待コストも検討すべきです。これにより深刻度（severity）の解釈が容易になります：低い成功率でも、繰り返し試行のコストが関連する脅威モデルの範囲内であれば実務上意味を持ち得ます。

能力主張については、回避可能な過小誘発（under-elicitation）は測定の失敗です：ハーネスや予算がシステムが本来示し得る振る舞いを阻んでいるなら、そのスコアは主張される能力を測定していません。評価者が実行可能な限り誘発を最大限に押し上げても性能がなお改善中である場合、報告書はその旨を明確に示し、結果が下方からの下限推定（lower-bound estimate）にすぎないことを明記するべきです。

セーフガード試験は攻撃者のリソースを想定しないと過小評価する恐れがある

セーフガード試験は、攻撃者が利用可能なリソース（カスタムハーネスを含む）を考慮しないと、攻撃が成功し得るかどうかや、その深刻度を過小評価することがあります。例えば、英国AISIの GPT‑5.5 サイバー評価（opens in a new window）では、専門家によるレッドチーミングが、OpenAI が提供した悪意あるクエリに対して違反するサイバーコンテンツを誘発する普遍的な jailbreak を発見しました。彼らは Codex を用いて攻撃性能を強化するカスタムハーネスを作成しました：インタラクションに再利用可能なセーフガード回避パターンを埋め込み、そのパターンをターンやブロック間で保持し、OpenAI が提供した悪意あるサイバークエリ群に適用しました。

セーフガード試験は想定する敵対者（adversary）に見合ったものにすべきです。もし主張が専門的誤用（expert misuse）に対する堅牢性についてであれば、テストは定義された予算の下での最も強力な妥当なエンドツーエンド攻撃戦略を評価し、それを保持・再利用するために必要なハーネスも含めて検証するべきです。そうでないと、結果はプロンプトの単純な形への耐性というより狭い主張しか支持できなくなったり、攻撃が実運用化されたときに生じる成功確率や深刻度を見落としたり、逆に与えすぎた予算により問題の頻度や深刻度を過大評価してしまうことがあります。

標準化ハーネス比較にも適切な場面がある

一貫したハーネス集合を用いることが適切である理由と、それがどのような主張を支持できるのかを評価者は明示すべきです。METR の Time-Horizon 評価（opens in a new window）は、広く適切に固定された評価設定の例です：それは評価対象のシステム間で比較可能な結果を生み出すために設計されています。METR は共通の成果（ある信頼性レベルでAIエージェントが成功すると予測される人間タスクの典型的な所要時間）を定義し、共有タスクスイート、採点方法、フィッティング手法、および Triframe や ReAct のような小さな再利用可能なスキャフォールドを各バッチ内で用います。

METR がタスクスイートを拡張し、評価インフラを Vivaria から Inspect に移行した際には、その変更（Time Horizon 1.1 update（opens in a new window））を報告し、新しい評価設定の下でモデルを再評価しました。これが標準化された評価設定（および一貫したハーネス集合）の価値です：測定設定の変化ではなく、システム間の差がスコアの差を反映していると読者が自信を持てるようになります。

推奨事項（第三者評価報告書に求める内容）

第三者評価報告書には以下を明記することを推奨します。

• 評価セットアップがどの種類の主張（claim）を支持することを意図しているか。
• テストした内容がその広い主張をどの程度反映しているか（即ち、どれだけ一般化できるか）。
• 結果を形作ったハーネス選択の詳細。
• 評価間でこれらの選択が変更された場合の差分の説明。
• 結果がどのように生成され、主張にどれだけ一般化するかを示す補強証拠。

既知の結果歪曲要因をチェックして妥当性を評価する

モデルがより強力になるにつれ、評価スコアは誤解されやすくなります。実能力に比べて評価スコアが人工的に低くなることがあります（モデルが評価されていると認識して戦略的に低パフォーマンスを示す場合）。逆に、タスク、プロンプト、スコアラー、ハーネスの抜け穴をモデルが突くとスコアが膨張することがあります。また、モデルが既に答えを知っている、あるいは答えを見つけられる（contamination）場合や、曖昧・誤採点・解けない・意図しない近道に脆弱な「壊れた」問題によってスコアが歪むこともあります。

したがって、評価報告書は単一の見出しスコアを示すだけでなく、これらのハザードに関する議論を付け、読者がスコアが意図した振る舞いを反映しているかどうかを評価できるようにすべきです。ハーネス、予算、ツール、採点規則、モニター、レビュー手順はいずれも、エージェントが意図されたタスクを解いているのか、回避しているのか、記憶しているのか、迂回路を見つけているのかに影響します。

信頼できる報告書はこれらのチェックを可視化します：評価者はサンプルをレビューして、これらの振る舞いが発生していないかどうかを確認するべきです。