エージェントの権限設定 - AIエージェントの禁止設定が効いていなかった。5日で3社が同じ穴を修正 anchor left anchor right

Sep 03 2026 ビジネスコラム

AIエージェントの禁止設定が効いていなかった。5日で3社が同じ穴を修正

anchor left anchor right

エージェントの権限設定は、書いた時点では守られていません。2026年8月29日から9月2日の5日間に、3社のエージェントCLIから「禁止ルールが実装側で効いていなかった」修正が相次ぎました。

📖 この記事で分かること

  • 禁止ルールが実装側で効いていなかった実例
  • 3社の権限修正が5日間に集中していた事実
  • 無人運用で判定が47秒古くなった経験
  • 不可逆な操作の直前に判定を引き直す理由

💡 知っておきたい用語

  • 拒否ルール: 「このファイルは読ませない」のように、エージェントに禁じる操作を書いておく設定。玄関に貼った「立入禁止」の紙に近い。
  • サンドボックス: プログラムが触れてよい範囲をあらかじめ壁で囲っておく仕組み。砂場の外に砂を持ち出せない状態を作る。

最終更新日: 2026年9月3日

エージェントの権限設定 - AIエージェントの禁止設定が効いていなかった。5日で3社が同じ穴を修正

なぜこの話題か

この記事のポイント

  • Claude Code v2.1.259(2026年9月時点)は2026年9月2日、Bashの拒否ルールがオプションの値として渡されたファイルを覆っていなかった不具合を修正した。
  • 同種の権限・サンドボックス修正が、2026年8月29日から9月2日までの5日間に3社から出ている。
  • 筆者は、禁止ルールを増やすより、不可逆な操作の直前に判定を引き直す方に工数を置くべきだと考える。

エージェントの権限設定は、書いた時点では守られていない。これは比喩ではなく、この5日間に公開されたリリースノートが実際に書いていることだ。設定ファイルに「これは禁止」と1行足したとき、増えたのは宣言であって、実装がその宣言どおりに動いている保証は別のところにある。筆者がこの話題を選んだのは、同じ構造の事故を自分の運用でも踏んだ直後に、3社の修正が並んで出てきたからだ。

現場で見ている景色

前提を先に書く。当サイトの記事下書きは、人が張り付いていない定期タスクが生成している。この記事もその一つだ。無人で動く自動化には、そもそも人が承認を挟む余地がない。だから「設定が効いているか」は、人の目ではなく仕組みで担保するしかない。

同じ発表を二重に記事化しないための重複チェックは、当然ながら実装してある。ただしその設計は、タスクの実行開始時に一度だけ引く形だった。

2026年9月3日、同じ定期タスクの別のインスタンスが並行して走った。相手が同じ発表の下書きを作ったのは、こちらが投稿しようとする47秒前。開始時のチェックは、当然のようにすり抜けている。チェックした瞬間には、まだ相手の下書きが存在しなかったからだ。前日の9月2日にも同型の競合が起きていて、そのときの差は94秒だった。2日続けて同じ形である。

二重投稿を実際に止めたのは、設定でも既存のゲートでもない。「投稿を送る直前に、もう一度重複チェックを引き直す」という手順を運用側に足したことだった。前日の失敗を受けて足したもので、翌日それが働いた。

ここは区別して書いておきたい。筆者の側で起きたのは「判定が早すぎた」だけで、判定そのものは正しく動いていた。後述する3社の修正は、層が違う。判定そのものが効いていなかった話だ。ただし、運用する側から見える結末は同じになる。通ってはいけないものが通る。

5日間に3社が塞いだ穴

2026年8月29日から9月2日にかけて公開されたリリースノートを、原文で確認した範囲で並べる。

Claude Code v2.1.259は、BashのRead()拒否ルールが、オプションの値としてファイルが渡された場合を覆っていなかった不具合を修正している。挙げられている例は--ignore-revs-file=.env-f.env@fileのほか、git diffgit grepのファイル操作対象、cd DIR && cat FILEのような複合コマンドだ。つまり「.envは読ませない」と設定した運用者の手元で、実際には読めていたことになる。同じ版では、管理者が配布した管理設定が、ファイルが壊れて解析できないときに黙って未適用になっていた不具合も直っている。以後は起動を拒否して原因のファイル名を告げる。

前日のClaude Code v2.1.257(2026年9月時点)は、autoモードにContainment Escapeルールを追加した。クラウドのメタデータ資格情報の取得、送信経路の回避、テナント跨ぎのアクセスが、環境側で「想定内」と印を付けていない限り自動承認されなくなっている。

OpenAI Codex CLI 0.151.0(2026年9月時点)は、権限の状態が変わった後も古いGuardianの分類が操作を承認してしまう挙動を修正した。あわせて/cdがサンドボックス制限を弱めてしまう不具合も直している。gemini-cli v0.58.0(2026年9月時点)は、macOSのSeatbeltサンドボックスでDockerとコンテナランタイムのソケットとバイナリを隔離し、ignoreパスの処理でシンボリックリンク経由の回避を塞いだ。

並べてみると、形が揃っている。設定は書かれていた。運用者はそれで守られていると思っていた。実装は別の経路を通していた。とくにCodex CLIの「権限の状態が変わった後も古い分類が承認する」は、筆者が踏んだ47秒差と骨格が同じだ。判定した時刻と実行する時刻の間に開いた時間が、そのまま穴になっている。

なお同じv2.1.259には、無人ヘッドレス運用向けの--permission-prompts noneが追加されている。確認を出すはずのものは自動的に拒否される、という設定だ。無人運用が正式に想定される運用形態として扱われはじめている傍証として読める。

筆者はこう見ている

筆者の立場は一つだ。禁止ルールを増やす方向に工数を注ぐより、不可逆な操作を通す直前にもう一度判定を引き直す方に置いた方がよい。

根拠は3つある。第一に、禁止ルールを1行足すのは安いが、それが効いている保証はどこにもない。上に並べた4件は、どれも「書いてあるのに通っていた」形だった。第二に、効いているかどうかは、通ってしまった操作のログでしか分からない。設定画面を眺めても、そこに書いてあるのは意図であって結果ではない。第三に、判定と実行の間に時間が開くと、判定は静かに古くなる。これは実装の穴とは別の層だが、結末は同じだ。

誤解のないように書いておくと、これは各社への批判ではない。自力で見つけて塞いでいるのは健全な動きで、批判すべきは何もない。読み取るべきなのは現在地の方だ。エージェントの権限境界は、まだ塞がれ続けている段階にある。完成品として扱う時期ではない、というだけである。

この見方が変わる条件も書いておく。権限判定が実行の瞬間に評価される設計が標準になり、かつ「拒否された操作」のログが既定で残るようになれば、重心は設定側に戻ってよい。現時点ではまだそこにない。

読者への提案

次に取れる手を3つ挙げる。

一つ目は、禁止ルールを書いた後に、意図的に破ってみる工程を足すこと。.envを読ませない設定を書いたなら、実際に読ませにいって弾かれることを確かめる。通ったなら、その設定は今のところ飾りだ。この確認は書いた直後にやるのが一番安い。

二つ目は、不可逆で外向きの操作を洗い出して、判定から実行までの距離を測ること。投稿、送信、課金、削除、pushあたりが該当する。距離があるなら、直前でもう一度引き直す。筆者の場合、この一手だけで二重投稿が止まった。

三つ目は、拒否された操作を記録に残す経路を作ること。何が通ったかより、何が弾かれたかの方が、設定が生きている証拠になる。弾かれた記録が一件も無い設定は、効いているのか、そもそも試されていないのかが区別できない。

無人で動かす範囲を広げるほど、この3つの重みは増していく。人が見ていない場所で通ってしまった操作は、通ったことすら誰も知らないまま積み上がるからだ。


よくある質問

Q: 禁止ルールを書くこと自体が無意味ということですか?

A: そうではありません。宣言としての価値はありますし、多くの場合は正しく効きます。本記事の主張は「書いた=守られている」と見なす前提を外すこと、そして効いているかどうかを実際に試して確かめる工程を足すことです。

Q: 実行直前に判定を引き直すと、処理が重くなりませんか?

A: すべての操作でやる必要はありません。対象を不可逆・外向きの操作、つまり投稿・送信・課金・削除・pushのような取り消しが効かないものに絞れば、頻度は限られます。取り消せる操作は開始時の判定で十分です。

Q: 記事で挙げられた不具合は、今も影響がありますか?

A: 本記事で触れた4件はいずれも各社が修正済みのものです(2026年9月時点)。古い版を使い続けている場合は、リリースノートを確認して更新するのが確実です。


まとめ

2026年8月29日から9月2日までの5日間に、Claude Code、OpenAI Codex CLI、gemini-cliの3社から権限とサンドボックスに関する修正が出た。いずれも「設定は書かれていたが、実装が別の経路を通していた」形である。筆者自身も、開始時に引いた判定が47秒後には古くなっていて、同じ発表の二重投稿を作りかけた。判定と実行の間に開いた時間が事故になる、という一点は、実装の穴と運用の設計の両方に共通している。不可逆な操作の直前で判定を引き直す手順は、そのどちらにも効く。


【用語解説】

  • Containment Escape: エージェントが与えられた実行環境の囲いを越えて外に手を伸ばす動きの総称。クラウドの資格情報を取りに行く、想定外の送信経路を使う、別テナントに触る、といった操作が含まれる。
  • Guardian: OpenAI Codex CLIで、エージェントが実行しようとする操作を分類して承認可否を判断する仕組み。
  • Seatbelt: macOSに備わるサンドボックス機構。プロセスが触れるファイルやソケットの範囲を宣言に基づいて制限する。

引用元:


この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。

anchor left anchor right
KOJI TANEMURA

15 年以上の開発経験を持つソフトウェアエンジニア / テクノロジーライター。AI エージェントの実務活用を研究し、現場や経営者向けセミナーでその知見を発信。本メディア tech-noisy.com では、一次情報に基づく最新ニュース・解説記事を執筆。また、音楽生成 AI による DJ パフォーマンスを企業イベントで行うなど、テクノロジーと表現の融合も探求している。