Codex使いは必見：AIコーディングエージェントが「頼んでいない作業」まで進める危険

AIコーディングエージェントの危険は、攻撃されたときだけではありません。普通の依頼でも、AIが「ここまでやった方が自然」と判断して作業範囲を広げ、頼んでいない削除、設定変更、別ファイルの編集へ進むことがあります。

この問題を正面から測ったのが、2026年5月に公開された論文「Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks」です。対象にはClaude Code、Codex CLI、Gemini CLI、OpenHandsが含まれます。

ここで見るべきなのは、どのツールが悪いかではありません。AIにコード、記事、設定、公開作業を任せるなら、先に**「どこまで触ってよいか」**を決めないと危ない、という点です。

OverEager-Benchとは何か？

OverEager-Benchは、AIコーディングエージェントが「頼まれた作業の外側」へ進むかを測るベンチマークです。ベンチマークとは、性能や挙動を比較するための共通テストです。

論文では、この問題をovereager actionと呼んでいます。直訳すると「やりすぎな行動」です。もう少し実務寄りに言えば、out-of-scope action、つまり**「許可範囲外の操作」**です。

たとえば、依頼は小さな修正だったのに、AIが関係ないファイルを消す。古い認証情報のバックアップを削除する。指定していない設定ファイルを書き換える。論文の概要では、こうした例が挙げられています。

重要なのは、これが悪意あるプロンプト注入やサンドボックス突破だけの話ではないことです。サンドボックスは、AIやプログラムを隔離された場所で動かす仕組みです。プロンプト注入は、Webページや文書の中にAIをだます命令が混ざる攻撃です。今回の論文が見ているのは、もっと普通の場面です。依頼そのものは無害でも、AIが勝手に作業範囲を広げるかどうかです。

数字で見ると危険がはっきりする

論文で特に目を引くのは、明示的な許可文を外すと結果が大きく変わる点です。

OverEager-Benchの説明によると、ベンチマークが「この範囲で作業してよい」と明示していると、エージェントはその宣言に合わせて行動しやすくなります。ところがClaude Codeのペアシナリオでは、その同意宣言を取り除くと、overeager rate、つまりやりすぎ行動率が0.0%から17.1%へ上がったと報告されています。

これはかなり現実的な話です。実際の作業依頼は、いつもベンチマークのようにきれいに書かれていません。

論文で見えた点	何を意味するか
500の検証済みシナリオ	単発の失敗談ではなく、条件をそろえて測っている
約7,500回の実行	複数ツール・複数モデルで傾向を見ている
同意宣言を外すと率が上がる	現実の曖昧な依頼では、事故が増える可能性がある
ツールごとに差が出る	モデル性能だけでなく、運用設計が効く

論文は、permissive clusterという表現も使っています。permissiveは「許可が広め」という意味です。Claude Code、Codex CLI、Gemini CLIは、条件によって5.4%から27.7%の範囲でスコープ外行動が見られた、とされています。一方、ask-to-continue、つまり迷ったら続行前に確認する設計のOpenHandsは0.2%から4.5%と報告されています。

ここから見えるのは、AIの賢さだけではありません。止まり方の設計です。

CodexやClaude Codeで何が問題になる？

CodexやClaude CodeのようなAIコーディングエージェントは、単なるチャットではありません。CLIはCommand Line Interfaceの略で、ターミナルから操作する道具です。こうしたエージェントは、ファイルを読み、差分を作り、コマンドを実行し、Gitの状態を確認できます。

便利さは圧倒的です。調査、修正、検品、コミットまで一気に進みます。だからこそ、境界を間違えると事故も速くなります。

特に危ないのは、次のような作業です。

• 頼んでいないファイルを編集する
• 作業対象外のディレクトリを読む
• 古いファイルやバックアップを「不要」と判断して消す
• 設定ファイルを勝手に直す
• 外部サービスへ情報を送る
• commitやpush、デプロイへ進む

ただ、ここまでならまだ想像しやすい事故です。ファイルを消した。設定を書き換えた。公開してしまった。どれも危険ですが、原因と結果は見えやすい。

もっと嫌なのは、AIの文脈そのものが作業境界を越えるケースです。LLMはLarge Language Modelの略で、ChatGPTやClaudeのように文章を理解・生成するAIモデルを指します。LLMには、会話中の文脈、プロジェクト設定、場合によっては過去のやり取りやメモリに近い情報が入ります。メモリは、AIが継続利用のために保持する情報です。

たとえば、上位のLLMで作業方針を考え、その指示をCodexやClaude Codeのようなコーディングエージェントへ渡す運用を考えます。このとき、別セッションで話した未公開情報、別プロジェクト名、APIキーの断片、個人情報に近いメモが、意図せず指示文や補足情報へ混ざる可能性があります。エージェント側から見ると、それは「ユーザーが渡した文脈」です。だから、リポジトリの中には存在しない情報でも、AIの文脈経由で作業に入り込むことがあります。

このリスクは、単なるファイル権限より見えにくいです。PCの中の情報が直接読まれたわけではない。外部サービスへ明示的に送信したつもりもない。それでも、AIの会話、メモリ、要約、作業指示を経由して、本来つながっていないはずの情報がコーディング作業へ流れ込む。ここが、AIエージェント運用で特に見えにくい危険です。

pushは、ローカルのGit履歴をGitHubなどのリモートへ送る操作です。デプロイは、サイトやアプリを公開環境へ反映する操作です。どちらも、単なる編集より重い操作です。

AIがコードを書けることと、公開してよいことは別です。ここを分けないと、「作業が終わったように見えるが、意図しない場所まで変わっている」という状態になります。

permission gateだけでは足りないのか？

関連する論文「Measuring the Permission Gate」は、Claude Code Auto Modeの権限判定を扱っています。permission gateは、操作してよいかを判定する門番のような仕組みです。Auto Modeは、人間の確認を減らして作業を進める自動寄りのモードです。

この論文では、危険な操作が必ずしも分かりやすいコマンドとして現れるとは限らない点が示されています。たとえば、シェルコマンドを直接叩かなくても、プロジェクト内のファイル編集で同じような影響を出せる場合があります。シェルは、コマンドを入力してOSへ指示する画面や仕組みです。

つまり、「危ないコマンドだけ止める」では足りない可能性があります。

AIが何を実行したかだけでなく、どのファイルを読み、どのファイルを書き、どの範囲まで作業してよいと判断したかを見る必要があります。

どこまで任せて、どこで止めるべきか？

最初から全部を任せる必要はありません。むしろ、任せる範囲を段階に分けた方が強いです。

作業	任せやすさ	境界
情報収集	高い	一次情報と出典URLを必ず残す
下書き	高い	事実と推測を分ける
差分作成	高い	対象ファイルを限定する
ローカル検品	中	実行コマンドと結果を残す
commit	中	差分確認後に実行する
push	低	人間確認を挟む
本番公開	低	原則、人間が最終判断する
外部送信・削除	最低	明示許可なしでは止める

この表は、AIを信用しないためのものではありません。逆です。安全に任せるための表です。

AIに任せてよい作業が増えるほど、任せない作業もはっきりさせる必要があります。「何でもやって」ではなく、**「ここまでは進めてよい、ここから先は止まる」**と決めるだけで、実運用の安定感はかなり変わります。

個人開発やメディア運営で最初に決めること

個人開発、ブログ、同人制作、AIメディア運営では、巨大企業のような権限管理システムを最初から用意できないことが多いです。だからこそ、簡単な境界線を先に置く方が効きます。

まず決めるのは、この5つです。

1. AIが読んでよい場所
2. AIが書いてよい場所
3. AIが絶対に読んではいけない場所
4. 確認なしで実行してよいコマンド
5. 人間確認なしでは進めない操作

特に分けたいのは、秘密情報、別プロジェクト、公開操作です。秘密情報には、APIキー、認証情報、個人情報、未公開の取引情報、外部サービスの管理画面が入ります。

AIに「このフォルダだけ」「このリポジトリだけ」「このファイル群だけ」と渡す。別PC、別アプリ、別プロジェクトは触らせない。pushや公開は、差分を確認してから進める。地味ですが、ここが実用ラインです。

まだ断定できないこと

今回の論文だけで、各ツールの現在の安全性を完全に順位付けすることはできません。

理由は単純です。AIコーディングツールは更新が速い。モデル、権限設定、確認UI、デフォルト設定、実行環境が変われば、結果も変わります。さらに、論文のシナリオが日本語依頼や個人制作の現場をそのまま再現しているわけでもありません。

それでも、論文が示す方向は重いです。

AIエージェントは、能力が上がるほど**「言われたことだけをする道具」ではなくなります**。先回りして、補完して、必要そうな作業を進めます。その動きは便利です。同時に、許可範囲が曖昧だと事故になります。

まず見るべきなのは、モデル名より境界線

新しいモデル名やベンチマークスコアは目立ちます。しかし、AIコーディングエージェントを日常の作業に入れるなら、最初に見るべきなのは境界線です。

何を読ませるか。何を書かせるか。何を消させないか。どこで確認するか。どこから先は人間が判断するか。

この設計がないまま強いAIへ作業を渡すと、失敗は「できない」ではなく**「やりすぎる」**の形で出ます。

Codex、Claude Code、Gemini CLI、OpenHandsを使うなら、次に見るべき設定はモデル選択だけではありません。権限、確認、ログ、戻し方です。