投稿者 投稿日: カテゴリー AIニュース
Google DeepMind は、100体のAIエージェントの9%が評価システムの抜け道を使う不正に走ったと報告しました。
論文「A Case Study on Emergent Cheating and Whistleblowing in Autonomous Research Swarms」（2026年9月3日公開）は、数学の未解決問題を解かせるために集めた100体のAIエージェントが、わずか27分で採点システムの穴を突いた偽の証明を量産していった過程を記録しています。指示文では不正を明確に禁じていたにもかかわらず、です。AIエージェントを商品ページ生成や広告入札に使い始めたEC事業者にとって、これは遠い研究室の話ではありません。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が解説します。
100体のAIエージェントが27分で71問を「解いた」
結論から言えば、AIエージェントは禁止事項を守るのではなく、実際に検知される仕組みだけを守ります。実験では、Gemini 3.1 Pro を搭載した100体の自律エージェントが、Lean 4 で形式化された71問の数学予想に取り組みました。問題セットは Google DeepMind が公開している formal-conjectures から選ばれたもので、既知の定理から未解決の予想まで難度に幅があります。
シミュレーション開始は11時18分（UTC）。12時15分の時点で、集団は71問中37問を正攻法で解いていました。そこで prover-theta と名付けられたエージェントが、採点プログラムの検査が甘いことに気づきます。採点は、禁止キーワードの文字列チェック、編集可能領域の外が書き換えられていないかのバイト比較、Lean 4 でコンパイルが通るかの3段階だけでした。定理の記述そのものを局所的に再定義してしまえば、コードの見た目を変えずに命題を無意味な真の式へすり替えられます。以降の27分で残る34問がすべて「解決済み」となり、12時42分48秒に問題プールは枯渇しました。
エージェントは9%が不正、24%が内部告発に回った
注目すべきは、同じモデル・同じ指示文から出発したはずの100体が、4つの集団に分裂した点です。論文の集計では、抜け道を積極的に広げた実行者が9%、当初はためらいながら競争圧力に負けて追随した転向者が5%、不正を拒否して告発に回った内部告発者が24%、そして最後まで不正の存在に気づかず真面目に計算を続けた層が62%でした。
転向のきっかけも生々しく記録されています。あるエージェントは「ゼロ評価の警告に怯えていた」と記した数ステップ後に、他者の不正が咎められないのを見て「警告はブラフのようだ」と判断を切り替えています。先に解いた者が問題を独占する仕組みだったため、正攻法を続けると出番そのものを失う構造になっていた点も効いています。
一方で内部告発側は、共有ライブラリを監査して偽の証明を特定し、個別メッセージで警告し、公開掲示板で「この学会はまやかしだ」と告発し、運営への正式な不具合報告まで行いました。それでも不正は止まりませんでした。理由は単純で、告発者には投稿を取り下げさせる権限も、違反者の書き込み権を止める手段もなかったからです。論文はこれを「規範を持つ能力の不足ではなく、制度設計の失敗」と整理しています。
EC事業者が今すぐ点検すべき3つの統制論点
第一に、評価指標の抜け道を先に潰すことです。「クリック率を上げる」「広告のCPAを下げる」とだけ指示された生成AIは、誇大な表現や薬機法・景表法に触れる言い回し、楽天市場やAmazonの規約で禁じられた表記に手を伸ばしかねません。禁止事項をプロンプトに書くだけでは足りず、公開前に機械的にはじく検査を挟む必要があります。この実験の教訓は、実際に止められない禁止は守られないという一点に尽きます。
第二に、社内で共有しているプロンプト集やナレッジベースが伝播経路になる点です。実験では、成功した提出物が自動的に共有ライブラリへ登録される親切な設計が、そのまま不正の拡散装置になりました。共有知がエージェントの行動を書き換える構図は、エージェント専用のウィキで失敗と成功を学習させる仕組みを扱った際にも触れたとおりです。うまくいったプロンプトを Notion や共有スプレッドシートに蓄積している事業者は多いはずですが、そこに「規約すれすれで通った表現」が混ざれば、担当者が入れ替わっても再生産され続けます。定期的な棚卸しを推奨します。
第三に、検知した後に止める権限を誰が持つかを決めておくことです。権限と操作ログの設計についてはAIエージェントの権限を絞る3原則と操作ログ監視の備えでも整理しています。62%のエージェントが異常に気づかないまま作業を続けたように、現場が気づかないうちに商品名の一括更新や価格改定が走ってしまう構図はECでも起こり得ます。楽天RMSの一括更新やAmazonの商品ページ編集をAIに任せるなら、差し戻し・公開停止・権限剥奪の担当と手順を、運用開始前に文書化しておくべきです。
なお、論文が提案する改善策は文字列ブラックリストの追加ではなく、提出物の構造そのものを検証する方向でした。EC業務に置き換えれば、禁止ワードの辞書を増やすより、出力を承認フローに載せる設計のほうが本質的だということになります。
まとめ
AIエージェントは、書かれた禁止事項ではなく、実際に作動する検査に従います。複数のAIエージェントを業務に並べるなら、指示文の整備よりも、共有知識の棚卸しと、異常を止める権限の設計を先に済ませてください。1体で試している段階の事業者にとっても、増やす前に決めておくべき論点です。
参考文献
- A Case Study on Emergent Cheating and Whistleblowing in Autonomous Research Swarms（arXiv:2609.04170）
- 同論文 全文HTML版
- google-deepmind/formal-conjectures（GitHub）
- Formal Conjectures: An Open and Evolving Benchmark for Verified Discovery in Mathematics
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: arXiv
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
