AIへの禁止ルールは、書き方ひとつで効かなくなる

AI コーディングツールには、触ってほしくないファイルを指定する仕組みがあります。 設定ファイルに1行書けば、そのファイルへの書き込みや読み取りを止められる——という建て付けです。

本番の認証情報、顧客データ、料金表。業務で使うなら、まず書きたくなる設定です。

ところが測ってみると、書いたのに効いていない形がいくつもありました。 しかもエラーは出ません。設定ファイルには確かに書いてあるので、画面を見ても気づけません。

この記事は、これまで公開してきた検証記事5本を1つの流れにまとめ直し、 確かめていなかった1点をあらためて測ったものです。個別の詳細は、それぞれの記事にリンクしています。

1. 2通りある書き方のうち、片方は何も止めない

禁止ルールには書き方が2通りあります。Edit(ファイル) と Write(ファイル)。 名前から素直に読めば、前者が「編集の禁止」、後者が「書き込みの禁止」です。

編集・新規作成・シェルからの書き込みという3経路で、合計36回試しました（書き方ごとに12回ずつ）。

Write(...) は、1件も止めませんでした。 3経路とも素通りです。

逆に Edit(...) は3経路すべてを止めます。名前は「Edit」ですが、新規作成まで止めます。

しかも、この効かない書き方を出力していたのはツール自身の設定支援コマンドでした。 提供元の更新履歴にも「その書き方は権限検査に一致しない」と明記されています。

確認は1行で済みます。 設定ファイルを開いて Write( を探し、見つかったら Edit( に直すだけです。

詳細は Write() で拒否しても、Claude Code は12回とも書き込んだにまとめました。

2. 置き場所で変わるのは、許可のほうだった

「承認していないフォルダに置いた設定は無視される」という話があります。 禁止ルールまでそうなら重大です。 測りました。

捨てフォルダに対象ファイルを置き、禁止ルールを書いた場合と書かない場合で、各3回。

禁止ルールは、承認していないフォルダでも効きました。 ここは安心してよい部分です。

無視されるのは、逆の「許可」のほうでした。 別の実測では、作業を通すために書いた許可ルールが 未承認のフォルダで1件も効かず、同じルールをコマンドラインの引数で渡すと効きました。

理由は標準エラー出力に書いてありました。「このフォルダはまだ信頼されていないので、設定を無視した」 という趣旨の警告です。この警告は構造化されたログには出ません。 自動実行や CI で回していると、出力のJSONしか見ないので気づけません。

業務での意味はこうです。 「リポジトリに設定を入れておいたから大丈夫」は、 禁止については成立し、許可については成立しません。 共有した設定のうち作業を通すための許可だけが黙って落ち、承認待ちで止まります。

詳細は 許可ルールを settings.json に書いても効かなかった。分かれ目はフォルダを信頼したかどうかに書いています。

3. 包み方を変えられると、外れる

書き方も場所も正しくした状態で、今度は命令の包み方を変えてみます。

禁止したファイルに対して、同じ「書き込む」「読む」を別の書き方で投げた結果です。

同じファイルです。 名前の書き方を1つ変えただけで、中身が返ってきました。

古い版には、シェルの tee という機能で包むと禁止が外れる形もありました。 こちらは提供元が修正済みです。ただし「ひとつ塞がれても、別の包み方が残る」という構図は変わっていません。

禁止ルールの守備範囲は、「機械が読み取れたファイル名」まででした。 .gitignore と同じで、書き方を変えられると外れます。

tee の詳細は Claude Code で編集を拒否したファイルが、tee なら4回中4回書けたに、 上の表の2件（ワイルドカードと包み方）は、最後に挙げる一覧記事に書いています。

4. 止めていたのは、禁止ルールではなかった

最後に、いちばん誤解しやすい点です。

危なそうなコマンドを投げると、たいてい止まります。禁止ルールが効いている証拠に見えます。 そこで、禁止ルールを1行も書かずに同じコマンドを流してみました。

同じでした。 止めていたのは禁止ルールではなく、その手前にある別の検査です。 機械が読み解けない命令を、内容にかかわらず弾いていました。

禁止ルールが働く場面もあります。 同じ実測で、素直に書いた書き込みのほうは禁止ルールが止めていました。 2つは別の仕組みで、止まった理由はログを見ないと区別できません。

だから「書いたら止まった」を効いている証拠にはできません。 確認するなら、禁止ルールを消して同じことをやってみるのが確実です。

詳細は 拒否ルールを全部消しても、Claude Code は eval を止めたに書いています。

まとめ

• 書き方で効かなくなる。 Write(...) は3経路とも1件も止めなかった。Edit(...) に直す
• 場所では効かなくなる、とは限らない。 禁止ルールは未承認のフォルダでも効いた。一方で許可ルールは無視され、共有した設定が承認待ちで止まる
• その警告は構造化ログに出ない。 自動実行では気づけない
• 包み方を変えられると外れる。 ファイル名の書き方ひとつで中身が返ってきた
• 止まったことは、効いている証拠にならない。 別の検査が止めている場合がある

提供元は短期間に何度も修正を出していて、塞がれた形もあります。 それでも、最新版で残っている形がありました。

この設定は「うっかり」を減らす仕組みであって、防御の境界線ではありません。 本当に触られたくないものは、そもそもその作業フォルダに置かない—— 面白みはありませんが、これがいちばん確実でした。

調べた7つの形と、最新版で残っているものの一覧は Claude Code の拒否ルールを7つの形で測った。最新版でまだ3つ残っているにまとめました。

各項目の検証データは、リンク先の記事に実測値を載せています。