AI作業エージェントに仕事を任せる前に、AGENTS.mdで決めておくこと｜Claude・Codexを事故らせない共通ルール

AIに「この作業やっておいて」と頼めるようになると、急に便利になります。コードを直す、文章を書く、WordPressを触る、調査する。人間が手を動かす時間はかなり減ります。

ただ、その便利さと同時に怖さも増えます。AIがファイルを編集できるなら、間違ったファイルも編集できます。公開操作ができるなら、下書きのつもりだったものを本番へ出す事故も起こりえます。だから私は、作業AIに本格的な仕事を任せる前に、まず「共通ルール」を文章にしておくべきだと思っています。

その置き場所として分かりやすいのが AGENTS.md です。Codexでは、公式ドキュメント上でも AGENTS.md をプロジェクトや作業単位の長期的な指示として扱う仕組みが説明されています。Claudeなど別のAIでも、同じ内容を作業前のルールとして渡せば、事故防止の考え方はそのまま使えます。

この記事では、AI作業エージェントに任せる前に AGENTS.md へ何を書いておくべきかを、実務寄りに整理します。Amazon誘導ではなく、AIを使って作業を任せたい人向けの「最初に作るべき安全柵」の話です。

AGENTS.mdは「強いプロンプト」ではなく、作業契約書です

AGENTS.md を魔法のプロンプトみたいに考えると、たぶん失敗します。「あなたは優秀なエンジニアです」と書いても、実際の事故はあまり減りません。必要なのは、AIに人格を盛ることではなく、作業の境界線をはっきり渡すことです。

たとえば、次のようなことです。

AGENTS.mdに書くべきこと：
どこまで自動でやってよいか。どこから人間の承認が必要か。秘密情報をどう扱うか。変更前に何を確認するか。失敗したときにどう止まるか。

AIは「察してくれる相棒」ではありますが、「そのプロジェクトで何が本当に危険か」までは最初から知りません。だから、危険な操作ほど先に文章化します。

まず書くべき5つのルール

私なら、最初の AGENTS.md には次の5つを必ず入れます。

1. 本番・公開・破壊操作の承認ライン

いちばん大事なのはここです。AIにファイル編集を任せることと、公開・送信・削除まで任せることは別です。

たとえば、git commit、git push、WordPress公開、FTPアップロード、データ削除、有料サービスの契約変更。このあたりは「やってよい作業」ではなく、「確認してから実行する作業」として明記します。

2. 秘密情報の扱い

APIキー、パスワード、トークン、アプリパスワードは、記事にもコードにもメモリにも書かせない。これは強めに書いておいた方がいいです。

「秘密情報を読まない」「中身を表示しない」「必要なときは存在確認だけにする」といったルールまで書いておくと、AIが調査の勢いで踏み込みすぎる事故を減らせます。

というか、キー関係は基本渡しちゃだめです。

3. 作業範囲を広げないルール

AIは親切なので、頼んでいない周辺作業まで「ついで」にやろうとすることがあります。これが良い方向に働くこともありますが、共同作業ではノイズにもなります。

だから「指示された範囲だけやる」「関連リファクタは勝手に広げない」「迷ったら確認する」と書いておきます。特に既存プロジェクトでは、余計な整理整頓が一番レビューしづらいことがあります。

4. デバッグの進め方

トラブル対応では、AIに「たぶんこれだと思う」で連続変更されるのが一番困ります。原因が外れたまま変更が増えると、あとから戻すのが大変です。

ここはシンプルに、証拠 → 原因確定 → 1変更 → 確認 と書いておくのがおすすめです。ログを見る、再現する、差分を小さくする、検証する。この流れを固定しておくだけで、作業の荒れ方がかなり変わります。

5. プロジェクト固有の公開ルート

最後に、プロジェクトごとの「正しい道順」を書きます。

WordPressなら、投稿はどのスクリプトを通すのか。Next.jsなら、どのコマンドでビルドするのか。画像を置く場所はどこか。レビュー前に確認するURLはどれか。人間にとっては当たり前でも、AIにとっては初見です。

悪いAGENTS.mdと良いAGENTS.mdの違い

抽象的な精神論だけだと、AIは動き方を変えられません。行動に落ちる言い方にするのがコツです。

弱い書き方	強い書き方	理由
安全に作業してください	公開・削除・push・有料契約変更は、実行前に本人確認を取る	止まるべき操作が明確になる
秘密情報に注意してください	`.env` や認証ファイルは中身を読まない。必要なら存在確認だけ行う	調査中の踏み込みすぎを防げる
いい感じに直してください	原因を確認し、1つ変更し、結果を検証してから次へ進む	デバッグが散らかりにくい
ブログを更新してください	投稿は指定スクリプトを通す。直接REST投稿や生HTML投稿は禁止	過去に起きた事故の再発防止になる

ポイントは、「AIに期待する性格」ではなく「AIに許可する行動」を書くことです。

ただし、某国で利用停止されちゃったような新世代のモデルはこの具体的な指示が逆に足枷となることもあります。

そのまま使える最小テンプレート

最初はこれくらいで十分です。長大なルールにするより、守ってほしい境界線を短く置く方が効きます。

# AGENTS.md



## 作業範囲
- 指示された範囲だけ作業する。
- 関係ないリファクタやファイル整理は勝手に行わない。
- 判断に迷う場合は、実行前に確認する。



## 承認が必要な操作
- git commit / git push
- 本番公開、アップロード、外部送信
- 削除、破壊的な上書き、有料契約や課金につながる操作



## 秘密情報
- APIキー、トークン、パスワードを表示・転記しない。
- .env や認証ファイルは中身を読まない。
- 必要な場合は、存在確認だけ行う。



## デバッグ
- 推測で連続変更しない。
- 証拠を確認し、原因を絞り、1変更ごとに検証する。



## 報告
- 何を確認したか、何を変更したか、どう検証したかを簡潔に報告する。

このテンプレートに、プロジェクト固有のルールを足していきます。たとえば「公開はこのスクリプト経由」「画像はこのフォルダ」「ビルドはこのコマンド」「レビュー前にこのURLを見る」などです。

AGENTS.mdに書かない方がいいもの

逆に、何でも入れればいいわけではありません。特に次の3つは避けた方がいいです。

秘密情報そのもの

「APIキーはここ」と書いてはいけません。置き場所の方針だけを書きます。AIが必要とするのは秘密の中身ではなく、「秘密をどう扱うべきか」です。

気分で変わる好み

毎回変わる好みを恒久ルールに入れると、あとで邪魔になります。今回だけの条件は、作業依頼の本文に書く方が向いています。

長すぎる理念

大事な思想は必要ですが、長すぎると肝心の禁止事項が埋もれます。AIに守ってほしいルールは、短く、具体的に、行動単位で書くのが一番です。

AIに任せるほど、人間側のルール作りが効いてくる

AIエージェントは、単なるチャットAIより作業範囲が広いです。ファイルを読み、コマンドを実行し、編集し、場合によっては外部サービスにも触ります。だからこそ、最初に「ここまでは任せる」「ここからは止まる」を決めておく価値があります。

これはAIを信用しないという話ではありません。むしろ逆です。信用して任せるために、任せ方を決めておく。人間同士のチームでも、権限と手順が曖昧なまま本番作業をしないのと同じです。

まとめ：AIに仕事を頼む前に、まずルールを書く

AI作業エージェントを使うとき、最初に整えるべきなのは便利なプロンプト集ではなく、作業のルールです。

AGENTS.md には、承認が必要な操作、秘密情報の扱い、作業範囲、デバッグ手順、プロジェクト固有の公開ルートを書いておく。これだけで、AIに任せられる作業の幅が広がります。

AIに任せる時代ほど、人間側の「ここまでは任せる」「ここからは止まる」という設計が効いてきます。まずは短い AGENTS.md を1枚作る。そこから始めるのが、いちばん現実的で強いAI活用だと思います。