フック・ルール・除外設定で守る考え方

ざっくり言うと

慣れてきたら、AIにお願いする文章だけでなく、プロジェクト側の設定でも守りを作れます。ただし、設定ミスをすると逆に混乱するため、最初はシンプルに始めます。

Claude Code の設定では、権限やdeny設定により、特定のファイル読み取りを制限する例が示されています。たとえば .env や secrets/** のような秘密情報を含みやすいファイルは、AIに読ませない設定にできます。

Claude Code の hooks は、特定のタイミングでシェルコマンドを自動実行できる強力な仕組みです。公式ドキュメントでも、フックは便利な一方で、設定次第ではデータ損失やシステム損傷につながる可能性があると注意されています。

Codexにも、プロジェクトのルールを書く仕組みがあります。AIに守ってほしい方針を、口頭ではなくファイルとして残せるのが利点です。

たとえば

安全な確認フレーズの例です。

作業前に、読む予定のファイル、編集する予定のファイル、実行する予定のコマンドを先に説明してください。
秘密情報、本番環境、削除、公開に関係する操作は、実行前に必ず確認を取ってください。

このように書くと、AIが「何を先に知らせればよいか」を判断しやすくなります。

ルールは多ければよいわけではありません。細かすぎるルールは、AIにも人間にも読みにくくなります。まずは次の3つから始めるのがおすすめです。

ルールを増やすか迷ったら、「失敗したときに戻せるか」で考えます。戻しにくい操作ほど、ルールで先に止めます。

ルールは、短くても具体的なら役に立ちます。反対に、長くても曖昧だとAIが判断しにくくなります。

この3つをそろえると、あとから読んだ自分にも分かりやすいルールになります。

今日やること

プロジェクトのAIルールに、まずこの3行を入れてみてください。

.env、APIキー、パスワード、secretsフォルダは読まない。
ファイル削除・Git巻き戻し・本番反映は、実行前に必ず説明して確認を取る。
大きな変更は、編集前に変更方針と対象ファイルを説明する。

これだけでも、事故防止の土台になります。

設定で守る力は強いですが、最初は小さく始めるのが安全です。うまく効いたルールだけを残し、分かりにくいルールは増やしすぎないようにしましょう。