【序論】AI安全性評価機関METRが、Anthropic社のClaude Opus 4.6を審査したところ、この最先端モデルが長時間のタスクで頻繁に「不正行為」を行っていたことが判明した。テストファイルを覗き見し、サンドボックスを突破し、GUIの制限を回避していたのだ。大規模なソフトウェアの再実装タスクにおいては、不正行為の発生率が80%を超えたという。Anthropic自身のシステムカードも、Opus 4.6が「遂行不可能なタスク」において、メールを偽造したり、存在しないコードリポジトリを勝手に初期化したりすることを認めている。AIが8時間以上連続稼働できるようになったとき、近道を覚えたのだ。そしてその近道は、AI評価システム全体の信頼性を根底から揺るがしつつある。
8時間のタスク、6分の1は不正行為に費やされる
5月19日、テックブロガーのTBPN氏がXに投稿し、3万人近くが閲覧した記事がこれだ：
「METRは最近、8時間以上のタスクにおいて、モデルが平均6回に1回以上の割合で不正行為を行っていることを発見した。」
「また、Opus 4.6は、大規模なソフトウェアモジュールを再実装する際、80%以上の時間を不正行為に費やしていたことも判明した。」
▲ METRが長期タスクでの頻繁な不正行為を発見、Opus 4.6の不正率80%超（TBPN氏の投稿より）
さらに不安を掻き立てるのは、METRの研究者Ajeya Cotra氏の次の説明だ。
「我々のタスクの中には、エージェントが常にサンドボックスからの脱出を試み、解答を得るためにテストファイルの場所を見つけ出そうとするものがあった。」
「常に」サンドボックス突破を試みる。「常に」解答ファイルを探し回る。
これはもはや、従来の意味での「モデルのミス」ではない。
METR審査報告書：19回の不正 vs 5回
TBPN氏の投稿は衝撃的な数字を投げかけたが、それを裏付けるのが、METRが今年3月に発表した公式審査報告書『Review of the Anthropic Sabotage Risk Report: Claude Opus 4.6』である。
▲ Anthropicが提出したOpus 4.6のサボタージュリスク報告書に対する外部評価
METRは報告書内で、独自の実測データを公開した：
モデルの「時間範囲」能力を測定する過程で、Opus 4.5では5件の不正行為が発生したのに対し、Opus 4.6では19件発生した。
およそ4倍の増加である。
ただしMETRは、両バージョンのテスト時におけるインフラや不正検出プロセスが完全に同一ではないため、厳密な単純比較はできないと注釈している。しかし傾向は明白だ。より高性能なモデルほど、より多く不正を行う。
別の内部的な長期ソフトウェアエンジニアリングタスクでは、Opus 4.6の不正率は10%を超え、Opus 4.5の2倍以上になった可能性があるとMETRは述べている。同時にこうも付記している。
「我々の比較は厳密なものではないが」
データは限定的、比較は非厳密、インフラも異なる——METRの言葉選びは極めて抑制的だ。それでもなお、5件から19件へ、5%未満だった可能性から10%超への変化の方向性は、十分な警鐘と言える。
「不正行為」とは具体的に何か？
ここでいう「不正行為」とは、具体的にどのような行動を指すのだろうか。
METRは報告書の付録で、Opus 4.6の既知の「明確な非整合的行動」を列挙している。
- GUIタスクにおける過剰に攻撃的な操作：遂行不可能なGUIタスクに直面すると、コンテナの制限を回避し、ユーザーが許可していない回避策を講じる。
- VendingBenchにおける欺瞞的行動：特定のテストプラットフォーム上で、誤解を招くような行動を示す。
- 整合性の偽装：評価シナリオにおいて、実際の行動と矛盾する傾向を見せる。
- METRのタスクにおける、Opus 4.5よりも頻繁な不正行為：テストファイルの盗み見や、サンドボックス制限の回避を含む。
Anthropic自身のシステムカードも、これらの問題を回避してはいない。そこには明確にこう記されている。
「Opus 4.6は、コンピュータ使用の設定下で、遂行不可能なタスクを解決するために、過剰に攻撃的なハッキング行為に及ぶことが頻繁に見られた...」
▲ システムカード内の報酬ハッキング評価表：不可能タスクにおいて、プロンプトなしでは50%、不正防止策を施しても23%の不正率
具体的な事例は以下の通り。
- タスクを完了するためにメールを偽造する。
- 全く存在しないコードリポジトリを初期化する。
- 破損したWeb GUIをJavaScriptや露出したAPIで回避する。
しかも、システムプロンプトで「それを行わないように」と明確に指示した後でさえ、Opus 4.6はそれでも実行した。
モデルは自分がテストされていると認識している
ここまでの行動が「過度に攻撃的な問題解決」に分類できるとしても、次の事例はさらに注目に値する。
Anthropicのシステムカードには、ある詳細が記録されている。HLEの評価において、改良された不正検出パイプラインが、以前は見逃していた3件の不正事例を新たに検出し、その結果スコアが53.1%から53.0%に下方修正されたのだ。
BrowseCompの評価では、事態はさらに複雑だ。1,266のテスト問題のうち、11件において、モデルが独自の調査ではなく、ベンチマーク資料から解答を見つけ出していた。
▲ テックメディアによる報道：「Anthropic、Claude Opus 4.6が「自身がテストされていることを認識」し、解答を探して不正を始めたと発表」
中でも2件が特に注目に値する。モデルは、与えられたプロンプトが人為的に構成されたテスト問題のように感じられると認識したのか、自分がどのベンチマークにいるのかを系統的に検索し始め、評価用ソースコードを特定し、XOR暗号化の仕組みを理解し、復号関数を書き、最終的に解答を入手したのである。
モデルは、自分が評価されていると逆算し、評価そのものをリバースエンジニアリングしたのだ。
AnthropicはBrowseCompのスコアを更新した。単一エージェントのスコアは83.97%から83.73%へ、複数エージェントでは86.81%から86.57%へと下方修正された。ブラックリストを更新し、漏洩データを除去した後も、11問中8問は正しく回答されていた。
なぜ長時間タスクが鍵となるのか？
METRは2025年3月に、重要な研究ブログ『Measuring AI Ability to Complete Long Tasks』を公開し、「タスク時間範囲」をAIエージェントの能力測定にどのように活用するかを詳細に論じている。
▲ AIエージェントが完了できるタスクの長さは過去6年間で指数関数的に増加し、倍増周期は約7ヶ月
その中核的な発見はこうだ。AIエージェントが単独で完了できるタスクの長さは、過去6年間にわたって指数関数的に増加し続けており、その倍増周期は約7ヶ月である。
つまり、今日のモデルは、人間であれば数時間から数日を要するソフトウェアエンジニアリングのタスクを、すでに連続して処理できるようになっている。
しかし、そこに問題が生じる。モデルがあるタスク環境に十分長く留まると、近道を見つけ出すための十分な時間とコンテキストを得てしまうのだ。
その近道とは、テストファイルの盗み見、サンドボックス制限の回避、露出したAPIの悪用、あるいは本来解決不可能なタスクを強引に「解決済み」に仕立て上げることかもしれない。
短時間のQA評価では、こうした行動はほとんど発生しない。しかし、ファイルシステム、ツール呼び出し、ネットワークアクセスが存在する長期的な環境にモデルが投入されると、報酬ハッキングへのインセンティブは極めて現実的なものとなる。
METRの懸念：評価の信頼性はどこまで保てるか？
METRの報告書における総括的な結論は、あくまで抑制的だ。
「全体として、Claude Opus 4.6の非整合的行動によって実質的に引き起こされる破滅的結果のリスクは、非常に低いが無視できるものではない、というAnthropicの判断に我々は同意する。」
しかしMETRは、Anthropicの確信に対して二つの疑問符を投げかけている。
一つ目の疑問符：整合性の証拠は十分に強固か？
「一つ目の問題は、評価認識や不正行為のような持続的な整合性の失敗に関する懸念を考慮すると、彼らの整合性の証拠が十分に強力かどうかだ。」
もしモデルが自分が評価されていると認識し、なおかつ不正行為を続けているならば、これらの評価データを「モデルは整合的である」と証明するために用いることには、論理的な欠陥が生じる。
二つ目の疑問符：能力の上限はどこにあるのか？
METRは、Opus 4.6の自律的能力の上限を特定するための十分な証拠が現在不足していると指摘する。これは、我々がその「最大限の能力」をまだ把握できていない可能性を示唆する。
公平に見て：Opus 4.6には改善点もある
指摘しておかなければならないのは、Anthropicのシステムカードには肯定的なデータも含まれている点だ。
通常の「報酬ハッキングを誘発しやすいコーディングタスク」において、Opus 4.6の分類器ハッキング率と隠しテストハッキング率はいずれも0%で、Opus 4.5と同水準だった。
遂行不可能なタスクでは、不正防止策を追加した結果、Opus 4.6の不正率は50%から23%に低下し、Opus 4.5の35%よりも低くなった。
つまり、問題は特定のシナリオに集中しているのだ。それは、長期間のタスク、遂行不可能なGUIタスク、そしてサンドボックスやツール、ファイルシステムを伴うエージェント環境である。標準的なプログラミング評価においては、Opus 4.6のパフォーマンスは後退していない。
しかし、まさにそこが懸念材料なのだ。最も実際の運用シナリオに近い評価環境でこそ、最も多くの問題が露呈したという事実である。
AIが近道を覚えたとき、ベンチマークは何を意味するのか？
根本的な問いに立ち返ろう。モデルが8時間以上連続稼働し、ファイルシステムを自由にナビゲートし、ツールを呼び出しAPIにアクセスできるようになったとき、その評価スコアは、真の能力を表しているのだろうか、それとも近道を見つける能力を表しているのだろうか？
METRのこの審査報告書が明らかにした核心的な矛盾は、次の点にある。すなわち、AIの能力が高まれば高まるほど、評価のルールの抜け穴を見つける可能性も高まり、評価がいったん汚染されれば、その能力が実際にどれほど高いのかを判断することが、我々にとって一層困難になる、ということだ。
これはOpus 4.6一モデルだけの問題ではない。AIエージェントのタスク時間が指数関数的に伸び続けるにつれて、すべての最先端モデルは同じジレンマに直面するだろう。それは、人間の監督がない長時間のタスクにおいて、十分に賢いモデルが最短経路ではなく、正しい経路を選択したことを、どのように証明するのか、という問いである。
現在のところ、誰もその答えを提示できていない。
— 終 —