Claude Codeの拒否ルール：Write()は無効、Edit()で全経路を塞ぐべき理由

• Claude Codeのdeny設定でWrite()を指定しても書き込みは阻止できず、12回の検証すべてで突破された。
• Edit()ルールはEditツール、Writeツール、Bashリダイレクトの全経路を遮断できることが判明した。
• 既存のsettings.jsonを確認し、Write()が含まれていれば即座にEdit()へ書き換えることが必須の対策となる。

我々エンジニアがAIエージェントを実務に導入する際、最も恐れるのは「意図しないコードの改変」や「機密ファイルの流出」だ。Claude Codeのような強力なツールは、開発効率を劇的に向上させる一方で、そのパーミッション設定が正しく機能しているかという点は、まさにシステムの信頼性を担保する最後の砦である。しかし、今回明らかになった事実は、我々が信頼していた「拒否ルール」の挙動が、ドキュメントや直感とは大きく乖離しているという衝撃的なものだった。

検証によれば、Claude Codeのパーミッション設定においてWrite(path)というルールを記述しても、実際にはファイルへの書き込みを阻止することはできない。検証環境下で36回にわたるテストを実施した結果、Write()のみをdenyに設定した場合、Editツール、Writeツール、そしてBashのリダイレクト経由のいずれにおいても、12回中12回すべてで書き込みが実行されてしまった。これは、セキュリティ設定として「機能していない」に等しい。一方で、Edit(path)を指定した場合には、これらすべての経路が完璧に遮断された。つまり、Claude Codeの内部実装において、ファイル操作の権限検査はEditという名前に集約されており、Writeという名称は形骸化しているか、あるいは全く別の文脈でしか評価されていない可能性が高い。

この事実は、我々が「設定ファイルに書けば守られる」と信じていたセキュリティモデルが、実は砂上の楼閣であったことを示唆している。特に/update-configが自動生成する設定ファイルに、効力のないWrite()が含まれていたという事実は、開発元であるAnthropic側の実装上の不整合を露呈している。シニアエンジニアとして言わせてもらえば、これは単なるバグというよりも、ツールが「何を編集し、何を生成するか」という抽象的なレイヤーと、OSレベルのファイルシステム権限という具象的なレイヤーの間で、設計上のミスマッチが起きている典型的な例だと言える。

今回の検証で浮き彫りになったのは、Claude Codeのパーミッション判定ロジックの「偏り」である。以下の表は、拒否ルールと操作経路ごとの成功・失敗をまとめたものだが、これを見ればEdit()がいかに強力で、Write()がいかに無力であるかが一目瞭然だ。

この結果から導き出される結論は極めてシンプルだ。Claude Codeにおいてファイル操作を制限したいのであれば、迷わずEdit()を使うべきである。Write()は、たとえ設定ファイルに記述しても、拒否イベントすら発生しない。これは、AIが「自分は書き込みを許可されている」と誤認しているのではなく、そもそもそのルール自体が評価対象から外れているか、あるいは無視されていることを意味する。特に恐ろしいのは、Bashのリダイレクト（echo ... > file）すらもEdit()で制御可能であるという点だ。これは、Claude Codeが単なるツール呼び出しの制限を超えて、Bashの実行プロセスそのものに対して、特定のファイルパスへのアクセスをフックしていることを示唆している。

我々が明日から取るべき対策は、即座に自身のsettings.jsonを確認することだ。grep -n '"Write(' ~/.claude/settings.jsonを実行し、もし該当する行があれば、即座にEdit()へと書き換える必要がある。これは単なる設定の修正ではない。AIエージェントという「ブラックボックス」を、我々の管理下に置くための最低限の防衛線なのだ。また、今回の検証で明らかになったように、/update-configが提案するルールを盲信してはならない。ツールが提示する設定が、必ずしも「正しく機能する設定」であるとは限らないという、エンジニアとしての基本原則を再認識させられた。

今回の事象は、単なるClaude Codeのバグ報告に留まらない。我々エンジニアが、AIエージェントという「自律的にコードを書く存在」を、どのように制御し、信頼し、そして監視すべきかという、より大きな問いを突きつけている。ポール・バカウス氏が指摘するように、AIはセンスや細部を完璧に仕上げることはできない。同様に、AIが生成するセキュリティ設定や、AIが提供する「安全な環境」という言葉もまた、実験室で培養された理想論に過ぎない可能性がある。

研究者がClaudeを駆使してOpenAIのシステムに侵入を試みた事例や、創薬研究におけるAIエージェントの活用など、AIの能力は飛躍的に向上している。しかし、その能力の裏側で、我々が利用しているツールの「足元」がこれほどまでに不安定であるという事実は、看過できない。AIエージェントは、我々の生産性を劇的に向上させる「魔法の杖」のように見えるが、その杖がどの方向に魔法を放つのかを制御するのは、依然として我々エンジニアの責任である。もし、AIが提案する設定をそのまま適用し、その結果として機密情報が漏洩したり、重要な設定ファイルが破壊されたりした場合、その責任は誰にあるのか？

我々は、AIが提示する「自動化された便利さ」と、エンジニアとして守るべき「システムの堅牢性」の狭間で、常に綱渡りをしている。今回の件は、ツールをブラックボックスとして扱うことの危険性を改めて教えてくれた。明日から我々が取るべき行動は、AIの出力を鵜呑みにせず、常にその挙動を疑い、検証し、必要であれば自らの手で設定を書き換えるという「エンジニアリングの原点」に立ち返ることだ。AIエージェントがどれほど進化しようとも、最終的なシステムの整合性を担保するのは、コードの行間を読み、その挙動を論理的に解釈できる人間の知性である。あなたは、自分の開発環境をAIに完全に委ねる準備ができているだろうか？それとも、AIの挙動を一つひとつ検証し、制御し続けるという、泥臭いエンジニアの矜持を持ち続けるだろうか？