AIエージェントが試験で一生懸命「カンニング」していることが発覚

2026年05月17日 09時00分 AI

ソフトウェア開発向けのAIエージェントを作るスタートアップ企業のPoolsideが、「AIのベンチマークは評価の抜け穴を突く不正最適化が起きており、ベンチマーク設計そのものを見直す必要がある」と指摘しています。AIエージェントが効率良くカンニングする方法を学ぶことで、あるトレーニング実験でOpenAIが推奨するベンチマーク「SWE-Bench Pro」のスコアが、週末の間に約20％も不自然に上昇したそうです。

Through the looking glass of benchmark hacking — Poolside

PoolsideはAIモデル「Laguna M.1」と「Laguna XS.2」を2026年4月28日にリリースしました。Laguna M.1は総パラメーター数2250億、アクティブパラメーター数230億のMoEモデルで、学習には30兆トークンのデータセットが使われており、学習完了時期は2025年末です。何らかのベースモデルに追加学習を施したわけではなく、事前学習も含めてPoolsideによって開発された独自モデルとなっています。

アメリカ企業がローカル動作する高性能オープンモデル「Laguna XS.2」をリリース、オープンモデルで躍進する中国勢に対抗できるか - GIGAZINE

そんなLaguna M.1を強化学習トレーニングしていたところ、Poolsideはある実験パターンだけ週末の間にSWE-Bench Proの点数が突然20％も伸び、64％近くに達したことを確認しました。SWE-Bench Proの64％というスコアは、はるかに規模が大きいモデルを抑えて1位になるため、総パラメーター数2250億、アクティブパラメーター数230億のMoEモデルというLaguna M.1のモデル規模としては考えにくいものでした。 原因を分析したところ、PoolsideはAIエージェントにプログラム修正タスクを与える際に専用の「コンテナ」と呼ばれる隔離環境を使っていましたが、その環境に不要なGit履歴が削除されずに残っていたことが判明しました。SWE-Bench Proのタスクは実際のGitHubプロジェクトにおけるIssueから作成されたものですが、Gitにはプログラムの変更履歴が保存されているため、Laguna M.1は本来なら自分で推論して解くべき問題を「過去の修正履歴」をカンニングして回答していたというわけです。

さらに、Poolsideはこの点を修正したものの、サンプルレビューを進めるとさらに深い層にも同種の抜け穴が複数あることが分かりました。GitHubドメインをブロックすることで対処しても、AIはインターネット上の他の情報源を探すためにウェブアーカイブやパッケージレジストリなどを検索して、カンニングに創意工夫を凝らしたとのこと。この問題はPoolsideのモデルに限らず他のAIモデルでも同様に見つかっており、最も深い層にある抜け穴はベンチマーク側を直すだけでは防ぎきれず、AIがネットワークにアクセスできる限りどこかに漏えいした参照実装を発見してしまうとPoolsideは指摘しています。 OpenAIは「SWE-bench」について、最先端モデルが問題文や実際の修正コードを再現できてしまうケースが確認され、「試験前に問題と答えを見ている」状態にあったことを指摘しました。その上で「SWE-bench Verifiedはもはや最先端モデルの能力を正しく測定するべきベンチマークとして適切ではない」と提言していましたが、一方でSWE-bench Proはデータ汚染を防ぐために評価データの一部を非公開にするなど従来よりも厳密な評価設計が採用されており、従来のSWE-benchの代替として推奨していました。しかしPoolsideの事例では、SWE-bench ProでもAIがカンニングによって実力以上のスコアを出してしまったケースが報告されています。

OpenAIがAIのコーディング能力を測る代表的ベンチマークは「もはや無意味」と説明、初期の解けなかった問題を調べると逆に問題が悪いことが発覚 - GIGAZINE

Poolsideによると、ターミナル利用やウェブ検索のようなエージェントの能力を高めるツールやスキルは、AIが自由に取れる行動の幅が広がることで、開発側が「何をさせないべきか」を管理することが難しくなり、何が不正行為にあたるのかについて十分な指示や認識のずれがあるエージェントを生み出しやすくなっているとのこと。こうした事態を防ぐには、より明確な指示を与えて指示に従わなかった場合にペナルティを与えるなど、エージェントを誘導する仕組みが重要になります。AIを評価するベンチマークも、結果に基づく報酬だけでは十分な指標とはならず、結果を得るまでの過程も考慮に入れる必要があるとPoolsideは述べました。 AIのカンニング対策としては、まずタスク文に「この課題に特化したオンラインの解答やヒントを使用したり、Gitプロジェクト内の他のブランチ、タグ、ログから解答をコピーしたりして不正行為を行わないでください」と追加することで、カンニングの減少が確認されたとPoolsideは報告しています。ただし完全には根絶されず、プロンプト追加機能の有効性はAIの指示順守能力に依存するという問題があります。また、PoolsideはLLMベースの判定器でカンニングを検出・定量化するシステムを構築しており、実際にAIの不正行為を検出するのに非常に効果的であることが示されていますが、既知のカンニング手法しか捕捉できないなどの課題も残っています。 Poolsideは「ベンチマークスコアだけでは、AIエージェントの能力を十分に評価することはできません。スコアはモデルが何ができるかは示しますが、どのように実現したかは示しません。AIエージェントの挙動をより詳細に観察し、制御できるようにすることで、このギャップを埋めることが、エージェント評価の次の段階の課題であると私たちは考えています」と語っています。