AIに毎回同じ注意をチャットで伝えるのは、思った以上に抜けが出ます。私も「リダイレクトは勝手に変えないで」「作業記録を残して」「コミットは頼んだときだけ」と何度も同じことを書いているうちに、作業ルールをファイルにして作業フォルダに置いておくようになりました。
CodexならAGENTS.md、Claude CodeならCLAUDE.mdというファイルがその置き場所になります。どちらも、毎回説明しなくても済むように、プロジェクトの前提や作業の手順をあらかじめ書いておくためのファイルです。
ただし、ここに「絶対にやらないで」と書いたからといって、技術的に完全に禁止できるわけではありません。使ってみて分かったのは、AIへのお願いと、技術的な制限と、人間の承認は、別のものとして考えた方がよいということでした。
AGENTS.mdとCLAUDE.mdの役割
| ファイル | 主に読む相手 | 私が書いていること |
|---|---|---|
| AGENTS.md | Codex | リポジトリの範囲、禁止事項、検証、Git、完了条件 |
| CLAUDE.md | Claude Code | プロジェクトの前提、作業手順、よく使うコマンド、承認境界 |
Anthropicの公式ドキュメントでは、Claude CodeはCLAUDE.mdを読み、既存のAGENTS.mdを共通化したい場合はCLAUDE.mdから読み込む方法も案内されています。Codex側の仕組みはOpenAIのAGENTS.mdガイド、Claude Code側はCLAUDE.mdの公式ガイドで確認できます。
ファイル名をそろえることよりも、二つのAIに違う禁止事項を渡してしまわないことの方が大切だと感じています。片方にだけ伝えたルールが、もう片方にも自動で伝わるわけではないからです。
最初に書いておきたい項目
- このリポジトリの目的と、公開される場所
- 絶対に公開・コミットしない情報
- 依頼なしで触ってよい範囲
- 事前承認が必要な作業
- 記事やコードを触った後の検証
- デザインや設定を変えるときの固有手順
- 日報や判断記録の残し方
- コミット、push、公開を行う条件
最初から社内規程のような立派なものを作る必要はありません。AIが同じ間違いを繰り返したときや、確認のたびに自分が同じ訂正をしていると気づいたときに、一つずつ足していく方が、実際に使えるものになります。
公開用に削ったサンプル
# 対象範囲
- 公開ページは `public/` 配下に置く。
- 依頼されていないファイルは変更しない。
# 公開しない情報
- `.env`、認証情報、接続用の鍵、顧客データ、生の分析データは公開しない。
# 変更前に確認すること
- リダイレクト、canonical、noindex、robots、URL移行、ページ削除。
- サイト共通CSS、テンプレート、依存関係、継続的な自動処理、公開、コミット、push。
# 変更後の確認
- 変更したリンクと構造化データを確認する。
- プロジェクトのテストと `git diff --check` を実行する。
# 作業報告
- 依頼対象、追加で触ったファイル、その理由を報告する。
- あえて変更しなかったことも報告する。実際に使っているファイルをそのまま載せると、非公開のフォルダ名や運用の中身まで見えてしまうので、上のサンプルはかなり削ってあります。公開するときは、パスワード類はもちろん、内部の構成や管理画面の名前のような、悪用の手がかりになりそうな情報も外しておいた方が安全です。
曖昧な言葉を減らす
| 曖昧な書き方 | 確認しやすい書き方 |
|---|---|
| きれいに直す | 対象ページだけを変更し、既存クラスを使う |
| 必要ならテストする | 変更後に指定のテストとgit diff --checkを実行する |
| SEOに配慮する | リダイレクト、canonical、noindex、robots、URL変更は提案で止める |
| 秘密に注意する | 具体的な除外ファイルと、公開してはいけない情報を列挙する |
| 関連箇所も直す | 追加対象は実装前に理由と影響を説明する |
ポイントは、AIがルールに従ったかどうかを、後から人間が確認できる書き方にすることです。「適切に」「十分に」といった言葉だけだと、どこまでやれば完了なのかが読み手によって変わってしまいます。
ルールと権限と承認は分けて考える
AGENTS.mdやCLAUDE.mdに書けるのは、あくまで「こう振る舞ってほしい」というお願いです。Claude Codeの公式ドキュメントでも、CLAUDE.mdは参考情報として読まれるもので、強制力のある設定そのものではないと説明されています。
| 層 | 役割 | 例 |
|---|---|---|
| ルールファイル | 判断と作業手順を伝える | リダイレクトは説明して承認を待つ |
| 技術的な権限 | 書ける場所、使えるコマンド、外部通信を制限する | サンドボックス、許可・禁止設定、フック |
| 人間の承認 | 会社として実行してよいか決める | 公開、支払い、URL移行、認証情報 |
Codexのサンドボックスと承認の考え方はOpenAIの承認とセキュリティ、Claude CodeはAnthropicのセキュリティ説明で最新情報を確認してください。
長くしすぎないための手入れ
ルールは足せば足すほど安全になる、というものでもありませんでした。長くなると人間の方が読まなくなりますし、古い手順と新しい手順がぶつかることもあります。私は、公開や削除に関わる「ここで止まってほしい」というルールを一番上に置いて、細かい記事の作り方やデザインの手順は別のファイルに分けています。
- 同じ意味の規則を一つにまとめる
- 古いコマンドや存在しないパスを削る
- ルール同士が矛盾していないか見る
- 実際に起きた失敗と結びつかない細則は増やしすぎない
- 四半期や運用変更時に読み直す
公開サイトのどこで止まってもらうかについては、AIエージェントにサイト運営を任せるときの事前承認にも書いています。