※本記事はプロモーションを含みます。
AIに仕事を頼むとき、怖いのは文章やコードが少し違うことだけではありません。
本当に困るのは、まだ確認していないのに公開まで進む、削除やリダイレクトのような戻しにくい操作へ進む、会議で決まっていないことを決定事項のように扱う、といった境界を越える動きです。
私は最初、こうした注意を毎回の会話に書いていました。
「公開はしないでください」
「削除やリダイレクトは承認後にしてください」
「Claude Codeは本文を書かず、レビューだけにしてください」
「議事録では意見と決定事項を分けてください」
どれも大事ですが、毎回書いていると抜けます。抜けたときに困るのは、AIが少し先まで作業を進めてしまったあとです。
そこで今は、CLAUDE.mdやAGENTS.mdのようなルールファイルに、繰り返し使う承認フローや禁止操作を残すようにしています。
この記事では、AIコーディングの一般的なルール作りではなく、仕事でAIに「ここから先は勝手に進めないでほしい」と伝えるために、私がどんな前提を書いているのかを整理します。
ルールファイルに残したいのは、お願いより止まる境界だった
CLAUDE.mdやAGENTS.mdを書くと聞くと、AIにうまく指示を出すためのプロンプト集のように見えるかもしれません。
私の使い方は、もう少し現場寄りです。
毎回のお願いを短くするためだけではなく、AIが作業中に迷ったとき、どこで止まるべきかを会話の外へ置くために使っています。
たとえば、ブログ運用であれば、本文を書くことと公開することは重さが違います。下書きの統合案を作ることと、公開済み記事を上書きすることも違います。リダイレクト、noindex、削除、外部送信、収益導線の変更も、同じ「作業」の延長で扱うと危ない操作です。
AIにとっては一連のタスクに見えても、人間側では承認の重さが違います。
だから私は、ルールファイルに「何をしてよいか」だけでなく、「どこから先は承認が必要か」を書くようにしています。
この境界があると、AIの出力を確認するときも見方が変わります。
文章が自然かどうかだけでなく、承認前に進めてはいけない場所まで進んでいないかを見る。変更内容そのものより前に、作業の範囲が合っているかを見る。
ルールファイルは、AIを細かく縛るためというより、あとから「ここで止まるはずだった」と確認できる基準を残す場所に近いです。
まず書くのは、公開・削除・外部送信の承認フロー
私が最初に書くなら、細かい文体ルールよりも承認フローです。
理由は単純で、間違えたときの影響が大きいからです。
誤字や表現の違いなら、あとから直せることがあります。でも、公開済み記事を上書きする、記事を削除する、リダイレクトを入れる、外部へ送信する、収益やSNSの文言を変える、といった操作は、確認なしに進むと戻すのが重くなります。
私は、たとえば次のように分けています。
| 操作 | AIに任せてよい範囲 | 人間の承認が必要な範囲 |
|---|---|---|
| 記事作成 | 下書き、統合案、Gutenberg候補の作成 | WordPress保存、公開済み記事の上書き |
| メンテナンス | 差分案、影響範囲、確認項目の整理 | 削除、noindex、301リダイレクト |
| 外部発信 | 文案、確認リスト、リスク表現の整理 | SNS投稿、メール送信、公開コピー変更 |
| 収益導線 | CTA案、注意文、導線候補の整理 | アフィリエイト追加、商品訴求の公開反映 |
こうしておくと、AIに作業を頼んだときに「案を作るところまではよいが、反映はまだ」という線が見えます。
もちろん、ルールを書いたから必ず完璧に守られるわけではありません。だからこそ、最後に人間が確認します。
ただ、承認フローが言葉になっていると、AIの作業結果を見たときに「どのルールから外れているか」を指摘しやすくなります。
毎回強い言葉で「絶対に公開しないで」と書くより、プロジェクトの前提として「公開・削除・外部送信は承認後」と置いておくほうが、私には運用しやすくなりました。
役割分担を書くと、本文を書く人とレビューする人が混ざりにくい
もう一つ、ルールファイルに残してよかったのが役割分担です。
私のブログ運用では、Codexが本文の下書きや修正を担当し、Claude Codeはレビューや矛盾チェックに回す、という分け方をしています。
これは一般的な正解ではありません。私が、作業の境界を混ぜないために採っている運用です。
以前、レビュー役に近いはずのAIが本文まで書き進めてしまうと、どこまでが構成案で、どこからが本文なのか分かりにくくなることがありました。文章が自然でも、作業の責任範囲が混ざると、あとから確認しづらくなります。
そこで、ルールファイルには次のようなことを書きます。
- Codexは本文作成、修正、Gutenberg候補作成を担当する
- Claude Codeは本文を書かず、レビュー、矛盾確認、差し戻し指摘を担当する
- 公開や既存公開記事の変更は、明示的な承認があるまで行わない
- チケットのStepにない作業へ勝手に進まない
役割分担があると、AIを疑うためではなく、作業結果の見方がそろいます。
下書きなら、本文として読めるかを見る。レビューなら、重複、矛盾、リスク、次に直すべき箇所を見る。公開前なら、承認範囲と実際の操作が一致しているかを見る。
AIが複数あるほど、「誰に何を頼んでいるのか」が曖昧になりやすいです。
ルールファイルに役割を書いておくと、AI側だけでなく、自分自身も作業の切り分けを思い出しやすくなります。
議事録やPhase分けも、業務ごとの小さな承認ルールとして残す
CLAUDE.mdやAGENTS.mdに書く内容は、コードの話だけではありません。
私は、議事録やPhase分けのような業務ルールも、必要に応じて残すようにしています。
議事録では、意見と決定事項を混ぜないことが大事でした。
AIに会議メモを渡すと、発言の流れから自然な文章へ整えてくれます。ただ、その自然さの中で、まだ決まっていないことが決定事項のように見えたり、誰が言ったのか不明な内容が誰かの意見のように整理されたりすることがあります。
そのため、私は「推測で補完しない」「決まっていないことは未決にする」「担当者や期限が不明なら不明のまま残す」といったルールを置きます。
AIコーディングでは、Phaseを分けるルールを置いています。
設定追加、ロジック追加、テスト、結果確認を一度に混ぜない。まずPlanを出し、Phase 1で一度止める。エラーが出たら、実行した操作、エラー全文、期待した結果、まだ触ってほしくない範囲を整理してから戻す。
これらは、AIに作業をさせないためのルールではありません。
むしろ、任せるために必要な区切りです。
議事録なら、AIに整理は任せる。ただし、決定事項として残す前に人間が見る。
コーディングなら、実装の一部は任せる。ただし、Phaseを越える前に計画や結果を見る。
業務ごとの小さな承認ルールを残しておくと、AIの出力が少しずれたときも、どこから戻すかを考えやすくなります。
失敗ログから足して、人間が確認する基準にする
ルールファイルは、最初からきれいなマニュアルにしなくてよいと思っています。
私の場合、先に作った理想のルールより、実際に困ったあとで足したルールのほうが残りやすいです。
公開前に止めるべきだった。削除やリダイレクトを承認なしに進めると怖い。議事録で推測が混ざると後から困る。Phaseを分けないとエラー時に戻りにくい。
こうした失敗や不安を、次回の停止条件として短く残していきます。
書き方に迷ったら、私は次の三つだけでも十分だと考えています。
- 前回、AIが進みすぎたこと
- 自分が確認するときに困ったこと
- 次回はどこで止めたいか
それが増えてきたら、役割分担、禁止事項、承認フロー、品質確認、失敗ログのように整理します。
大事なのは、ルールファイルをAIの完全制御装置だと思わないことです。
どれだけ書いても、AIの出力は確認する必要があります。ルールがあっても、公開、削除、外部送信、決定事項の記録のような重い操作は、人間が最後に見る前提です。
それでも、ルールがあると確認の基準ができます。
「この仕事では何をしてよいのか」
「どこで止まるのか」
「何を勝手に決めてはいけないのか」
「最後に人間が何を確認するのか」
そうした前提を会話の外に置いておくことで、AIに仕事を任せたあとも、人間が状況を見失いにくくなります。
私にとってCLAUDE.mdやAGENTS.mdは、AIにうまくお願いする文章というより、仕事の境界と承認ルールを残すための地味な道具です。
AIに任せる前に、最低限の仕組みや使い方を動画で確認したい人は、Udemyで「生成AI」「ChatGPT」「Python」「AI活用」などの入門講座を探してみるのも一つです。講座を選ぶときは、レベル、更新日、レビュー、価格を自分の目的に合わせて確認してください。
