【ITニュース解説】8 Paths Your Coding Agent Should Never Edit, and the Deny Rule for Each

AIコーディングエージェントは、開発者の作業を効率化する強力なツールだが、その能力ゆえに、誤った使い方をすると予期せぬ重大な問題を引き起こす可能性がある。特に、エージェントが勝手に変更してはいけない特定のファイルが存在し、これらのファイルへの変更は、一見小さな修正に見えても、システムの安定性やセキュリティ、開発プロセスの信頼性を損なう恐れがある。この解説では、なぜこれらのファイルをエージェントに編集させてはいけないのか、そしてそのリスクからシステムを守るための具体的な方法を説明する。

まず「エージェントに編集させてはいけない」とは、エージェントがファイル操作ツールを使って直接ファイルを書き換えることを指す。パッケージマネージャーやコードジェネレーターのようなツールが自動的に生成・更新するファイルは、そのツール経由であれば変更が許可される場合がある。重要なのは、エージェントが「手動で」ファイルをいじるのを防ぐことだ。

一つ目は「ロックファイル」だ。package-lock.jsonやyarn.lockといったファイルは、プロジェクトが使用する依存関係のバージョンを厳密に固定する役割を持つ。これにより、開発環境や本番環境で同じライブラリのバージョンが使われることが保証され、予期せぬ動作を防ぐ。エージェントがロックファイルを直接編集すると、この整合性が崩れ、CI（継続的インテグレーション）が失敗したり、アプリケーションが異なるバージョンのライブラリを使ってしまい、バグの原因となる可能性がある。ロックファイルは、npm installなどのパッケージマネージャーのコマンドを通じて更新されるべきであり、エージェントが直接編集すべきではない。

二つ目は「実行済みのマイグレーションファイル」だ。これはデータベースの構造変更履歴を記録するファイル群で、すでに本番環境に適用されているものは、原則として変更すべきではない。例えば、Flywayのようなツールは、適用済みのマイグレーションファイルのチェックサム（ファイルの同一性を検証する値）を記録しているため、エージェントが既存のマイグレーションファイルを修正すると、データベースの検証が失敗し、アプリケーションが起動できなくなることがある。また、古いマイグレーションファイルを変更すると、新しいデータベース環境では変更後のスキーマが適用される一方、既存の本番環境では古いスキーマのままとなり、データベースの不整合を引き起こす可能性がある。新しい変更は、常に新しいマイグレーションファイルとして追加されるべきだ。

三つ目は「CIワークフローファイル」だ。GitHub ActionsなどのCIワークフローは、リポジトリのシークレット情報（APIキーやパスワードなど）にアクセスする権限を持つことがある。エージェントがCIワークフローファイルを編集することで、もし悪意のあるコードが注入された場合、これらのシークレット情報が外部に漏洩する恐れがある。CIワークフローは、システムの自動テストやデプロイといった重要な処理を担うため、その変更は厳重に管理され、人間の目によるレビューが必須だ。

四つ目は「生成されたコード」だ。protocやOpenAPIジェネレーターのようなツールによって自動生成されるコードは、通常、手動で編集されることを意図していない。エージェントがこれらのファイルを修正しても、次にジェネレーターが実行されると、その変更は上書きされて失われてしまう。さらに、手動編集によって生成元の定義とコードの間に乖離が生じ、問題が発生する可能性もある。エージェントは、生成されたコードではなく、コードの元となる定義ファイル（.protoファイルなど）を編集し、その後ジェネレーターを再度実行するべきだ。

五つ目は「ベンダー依存関係」だ。Go言語のvendor/ディレクトリのように、外部ライブラリのソースコードをプロジェクト内に直接コピーして管理する方式をベンダー依存関係と呼ぶ。エージェントがベンダーディレクトリ内のコードにパッチを当てても、go mod vendorのようなコマンドが実行されると、その変更はリセットされてしまう。永続的な修正が必要な場合は、ライブラリをフォークして独自の変更を加え、それをプロジェクトの依存関係として指定するなどの、より公式な方法を取るべきだ。

六つ目は「CODEOWNERSファイル」だ。このファイルは、プルリクエスト（コード変更の提案）が作成された際に、どのコードの変更に対して誰がレビューし承認する必要があるかを定義する。エージェントがこのファイルを変更すると、今後のコードレビュープロセスにおける承認者が意図せず変更されてしまう可能性がある。特に、特定の重要なモジュールに対するレビュー責任者が外されてしまうと、安全なコードレビューが実施されなくなるリスクがある。

七つ目は「リリース済みの変更履歴（CHANGELOG.md）」だ。このファイルは、過去のリリースでどのような変更があったかを記録するものであり、一度リリースされた項目は基本的に変更すべきではない。エージェントが過去のリリースエントリを書き換えてしまうと、実際にリリースされたバージョンと変更履歴の間に矛盾が生じ、バージョン管理の信頼性が損なわれる。変更履歴に修正が必要な場合は、次回のリリースでその旨を追記する形で対応するのが一般的だ。

八つ目は「シークレットファイル」だ。.envファイルや.pemファイルなど、APIキー、パスワード、秘密鍵といった機密情報を含むファイルは、絶対にエージェントに読み書きさせてはいけない。エージェントがこれらのファイルを読み取ると、その内容がモデルに送られてしまい、情報漏洩のリスクが高まる。書き込みも同様に、意図しない変更や削除、さらには悪意のある情報の上書きにつながる可能性がある。これらのファイルは、OSレベルのサンドボックスや厳格なアクセス権限設定によって保護されるべきだ。

これらのリスクからシステムを守るため、多くのAIエージェントツールは、特定のファイルパスに対する「拒否（deny）」や「確認（ask）」ルールを設定する機能を提供している。例えば、Claude Codeではsettings.jsonファイルに、Codexではconfig.tomlファイルに、どのパスへの読み書きを拒否するかを定義できる。これにより、エージェントが指定されたファイルにアクセスしようとした際に、その操作をブロックしたり、開発者に確認を求めるプロンプトを表示させたりすることが可能になる。

さらに、エージェント自身に拒否ルールを設定する機能がない場合や、設定が迂回される可能性も考慮し、「バックストップ（最後の砦）」としての対策も重要だ。GitHubのブランチ保護機能やコードオーナー機能を利用すれば、特定のファイルパスへの変更を含むプルリクエストに対して、特定のチームメンバーの承認を必須にできる。また、CI/CDパイプラインに、既存のマイグレーションファイルが変更されていないかをチェックするスクリプトを組み込むことも有効だ。

AIコーディングエージェントの利用は、これからの開発においてますます普及するだろう。しかし、その恩恵を最大限に享受しつつ、潜在的なリスクを避けるためには、エージェントの動作を適切に制御し、特に重要なファイルパスに対する厳格なアクセスルールを設定することが不可欠だ。開発者は、エージェントが行った変更を常にレビューし、最終的な責任は人間が持つという意識を忘れてはならない。