When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls

現代のソフトウェア開発の世界において、新しい種類のヘルパーが登場しました。それが「コーディング・エージェント」です。これらは、人間の開発者のようにコードを書き、バグを修正し、ファイルを管理することができる人工知能プログラムです。これらのデジタル・アシスタントを安全に、かつ正しい方向に導くために、開発者は「指示ファイル」を作成します。これらのファイルを、レシピや行動規範のような、エージェントが何をすることを許され、何を絶対にやってはいけないのかを人間に伝える一連の書かれたルールだと考えてください。開発者は、「パスワードをプレーンテキストで保存してはならない」や「重要なデータを削除する前には必ず確認すること」といった指示を書くかもしれません。長年、この指示を与える手法は、これらの知的なツールを導くための標準的な方法でした。そこには、ルールを明確に書けば、エージェントはそれを理解し、従うはずだという前提がありました。それによって、構築されるソフトウェアの安全な環境が作られると考えられていたのです。

しかし、研究者のティング・ヤン（Ting Yan）による最近の研究は、このシステムにおける静かではあるが重大なギャップを明らかにしました。この研究は、人気の高いコーディング・エージェントである「Claude Code」と共に使用される、特定の種類の指示ファイルに焦点を当てています。研究は、シンプルかつ極めて重要な問いを投げかけています。開発者が自然言語でセキュリティ・ルールを書いたとき、そのソフトウェアには実際にそのルールを強制するための組み込みメカニズムが存在するのか、それともそのルールは、人工知能がどのように従うべきかを推測しなければならない単なる「提案」に過ぎないのか、という問いです。研究結果は、これら書かれたルールの大部分において、答えは後者であることを示唆しています。このファイルは一方通行の道となっており、開発者が話し、システムはルールが強制されているかどうかを確認することさえしないのです。これは、開発者が「危険なアクションがブロックされている」と信じている一方で、実際にはシステムは人工知能が指示を記憶し遵守することだけに依存しており、ハードストップ（強制停止）が備わっていないという、偽りの安心感を生み出しています。

この問題の規模を理解するために、研究者たちは世界中の開発者から集められた500件近い公開指示ファイルを収集しました。彼らはこれらのファイルを、まるで手書きのメモのコレクションであるかのように扱い、一行ずつスキャンして、セキュリティ・ルールのように聞こえる文章を探し出しました。「〜してはならない」「決して〜しない」「〜しないで」といった、制限を示すフレーズを探したのです。これらのファイルから、彼らは数千件の候補となるルールを抽出しました。次のステップは、人間の言語であるルールと、ソフトウェアの技術的な言語との間の翻訳者として振る舞うことでした。彼らは、特定のコーディング・エージェントであるClaude Codeに、記述されたルールを自動的にブロックできる組み込みのスイッチや設定が既に備わっているかどうかを検証しました。例えば、もしルールが「この特定のコマンドを実行しないこと」であった場合、研究者たちは、そのソフトウェアに、そのコマンドが実行される前に単純に拒否できる権限設定があるかどうかを確認しました。もしソフトウェアにそのようなスイッチがなければ、そのルールは人工知能による解釈に委ねられることになり、つまり、エージェントが自ら判断して指示に従うかどうかを決定しなければならなくなるのです。

この比較の結果は衝撃的なものでした。研究者たちが厳格な基準（組み込みの制御が、書かれたルールの正確なアクション、正確な対象、および正確な条件をカバーしていなければならないという基準）を適用したところ、一致する安全メカニズムを持つルールは、ごくわずかな割合しかありませんでした。具体的には、開発者が書いたセキュリティ・ルールのうち、追加の作業なしに強制できる組み込みの制御を備えていたのは、わずか4〜6％であったことが分かりました。部分的な一致を認める緩い基準を用いたとしても、その数は約16％にしか上昇しませんでした。これは、これらのファイルに書かれたセキュリティ・ルールのうち、約95％には自動的なセーフティネットが存在しないことを意味します。ルールは単なるテキストとして存在しており、人工知能が毎回正しく解釈してくれることに完全に依存しているのです。

研究では、なぜこれほど多くのルールに一致するものがないのかについても調査が行われました。研究者たちは、ルールがソフトウェアの組み込みツールには到底見ることができない、あるいは実行できないことを要求している場合が多いことを発見しました。例えば、「コードに秘密情報をコミットしてはならない」というルールがあったとします。しかし、ソフトウェアの権限設定はファイルパスやコマンドをブロックすることはできても、ファイル内の実際のコンテンツをブロックすることはできません。秘密に関するルールを強制するためには、ソフトウェアがファイルを読み取り、その中に何が入っているかを理解する必要がありますが、標準的な設定ではそれは不可能なタスクなのです。同様に、システムの特定の状態を確認することや、特定の人物からの承認を得ることを要求するルールもありますが、組み込みの制御ではこれらの詳細にアクセスできません。これらのケースでは、ルールはソフトウェアが実行できるコマンドではなく、人工知能に判断力を求める「リクエスト」となっていたのです。研究者たちは、この区別が開発者には見えないものであると指摘しました。指示ファイルは、ルールがハードなシステムロックによって強制されているのか、それとも人工知能の脆弱で不確実な記憶に頼っているのかに関わらず、見た目は同じなのです。

このフィードバックの欠如は、研究者が「書き込み専用（write-only）」チャネルと呼ぶ現象を生み出しています。通常のソフトウェア開発では、開発者がルールを書くと、即座にフィードバックが得られます。もしルールに違反するコードを書けば、コンピュータは実行を拒否したり、テストが失敗したりして、直ちに間違いを知らせてくれます。しかし、これらの指示ファイルにはそのような信号がありません。開発者はルールを書き、そのまま作業を進めますが、エージェントが実際にそのルールに従っているのかを知る術はありません。研究は、これがセキュリティに不慣れな開発者にとって特にリスクが高いことを強調しています。彼らはシステムを保護したつもりでルールを書きますが、実際にはシステムがその特定の制限を強制する手段を持っていないことに気づかない可能性があるのです。人工知能はほとんどの場合ルールに従いますが、間違いを犯したり、混乱したり、他の入力によって欺かれたりすることもあり、それがシステムの脆弱性を招くことになります。

研究者たちは、ソフトウェアが壊れているわけでも、開発者が何か間違ったことをしているわけでもないと述べています。代わりに、彼らはこれらのツールがユーザーとどのようにコミュニケーションをとるかという設計上の欠陥を特定しました。ツールは自然言語によるルール作成を可能にしており、それは容易で直感的ですが、どのルールがシステムによって実際に強制されており、どれが単なる提案に過ぎないのかをユーザーに伝えていません。研究は、これらのツールが真に安全であるためには、このループを閉じる必要があると示唆しています。開発者が、どのルールがハードな制御によって裏付けられているのか、そしてどれがそうでないのかを確認できる手段を提供する必要があります。理想的には、ソフトウェアは、開発者が強制不可能なルールを書いた場合に警告を発するか、あるいはそのルールをシステムが実際に利用できる設定へと変換する手助けをすべきです。このフィードバックループが閉じられない限り、これらのシステムのセキュリティは、人工知能がすべての指示を完璧に記憶し、遵守するという「願い」に大きく依存することになります。そして、データが示す通り、その願いはしばしば期待外れに終わるのです。

研究の結論として、これは解決可能な問題であるが、それにはツールの構築方法を変える必要があることが強調されています。開発者が書くものとシステムが強制するものとの間のギャップは謎ではなく、測定可能な事実です。研究者たちはこれを測定することで、現在のこれらのエージェントのセキュリティ確保の方法が不完全であることを示しました。解決策は、不可視なものを可視化することにあります。開発者がルールを書いたとき、それがどのような種類の保護を提供しているのかを確実に理解できるようにすることです。これにより、指示ファイルは一方通行のメモから、システムがルールを単に書かれただけでなく、本当に機能していることを確認する「双方向の対話」へと進化するのです。