2026-08-17 公開 ／ AI活用

AIに開発を手伝わせて1年、いちばん効いたのは「指示」ではなく「ルールを文書に固定すること」だった

Webツールもアプリもサーバーの運用も、だいたい AI に手伝わせています。1年やって分かったのは、プロンプトを上手く書く努力より、守らせたいルールを文書に書いて毎回読ませることのほうが効くということでした。理由と、実際にどう書いているかを整理します。

なぜ「毎回の指示」では足りないのか

AI に作業を頼むと、その場では正しく動きます。問題は次の日です。前回の会話は残っていません。「バックアップは公開領域の外に取る」と前回伝えていても、次の作業では伝えていない状態から始まります。

これは記憶力の話に見えますが、実務上は「毎回同じ注意を口で言い続ける役」を自分が担うことになるという話です。そして人間の側が忘れます。私は忘れました。

そこで、守らせたいことをプロジェクトのルール文書に書いて、作業のたびに必ず読まれる状態にしました。会話ではなく、ファイルに固定する。これで「言い忘れ」という失敗の経路が消えます。

効いた書き方1: 禁止だけでなく、代わりに何をするかを書く

最初に書いたルールは、こういう形でした。

• ❌「ファイルを消さないこと」

これはあまり効きませんでした。禁止だけを書くと、禁止に触れない別のやり方を探してくるので、こちらの意図から外れることがあります。書き換えたのはこの形です。

• ✅「削除はしない。まず対象の中身を確認して報告する。削除が必要な場合は、まとめて消さずファイル単位で提案する」

禁止と代替行動をセットで書くと、迷ったときの行き先が決まります。禁止だけだと、行き先を自分で探すことになります。

効いた書き方2: 事故った理由を、ルールの隣に残す

これがいちばん効きました。ルールに理由が書いていないと、状況が少し変わったときに「これは当てはまらない」と判断されます。そして大抵は当てはまります。

たとえば「作業前にサーバー側の最新版を取得してから編集する」というルールを、こう書いています。

理由が書いてあると、「今回は急ぎだから飛ばそう」という判断が起きにくくなります。飛ばした結果がすでに書いてあるからです。これは AI に対してだけでなく、半年後の自分に対しても同じ効果がありました。

実際、私のルール文書はほとんどの行に「いつ、何が起きたか」が付いています。一般論として書かれたルールは守られず、事故の記録として書かれたルールは守られる、というのがこの1年の実感です。

効いた書き方3: 判断の分かれ目に「どちらが正か」を書く

ドキュメントが複数あると、必ず食い違います。片方が古いまま残るからです。そこで、食い違ったときにどちらを信じるかを、あらかじめ書いておきます。

「AとBで記述が食い違ったら、Bを正とする」の1行があるだけで、矛盾を見つけたときに止まらずに進めます。これが無いと、毎回こちらに確認が来ます。確認が来るのは丁寧ですが、頻度が高いと結局こちらが判断し続けることになります。

逆効果だった書き方

1. 「良くして」「最適化して」と頼む

範囲を決めずに改善を頼むと、変更量が多くなりすぎて、どの変更がどの意図なのか追えなくなります。私は一度これで全部戻しました。触ってよい範囲と、触ってはいけない範囲を先に書くほうが、結果的に速いです。

2. 原因の推測を伝えてしまう

「たぶんタッチイベントの処理が原因だと思う」と伝えると、その仮説の上で調査が進みます。仮説が外れていると、外れた方向に深く進みます。

症状だけを渡すほうが良い結果になりました。「長押しすると文字が選択されて操作が効かなくなる」のように、見えている現象をそのまま書く。切り分けを自分で先にやると、切り分けの誤りごと引き継がれます。

3. ルールを増やし続ける

気づいたことを足し続けると、文書が長くなって、重要な行が埋まります。私は一度これで肥大させました。今は「事故が起きたら足す、起きていない心配では足さない」という基準にしています。予防のつもりで書いた行は、実害のある行の可読性を下げるだけでした。

ルール文書を公開しない理由（ここは注意点）

この手の記事では「実際のルール文書をそのまま公開します」という形が読まれるのですが、私はこれをやりません。

運用のルール文書には、サーバーのアドレス、内部のディレクトリ構成、定期実行の中身、接続方法といったそのまま攻撃の手がかりになる情報が集まります。便利な文書であるほど、そうなります。

なので公開するときは、構造だけを説明して固有の値は書かないという形にしています。この記事もそうしています。読む側にとっては物足りないかもしれませんが、「実物を貼る」以外の方法で伝わる部分は、実は思っていたより多いというのがやってみた感想です。手順の形と理由が分かれば、値は各自の環境のものに置き換えられます。

持ち帰れること

• 毎回言う内容は、会話ではなくファイルに書く。言い忘れという失敗経路が消えます
• 禁止と代替行動をセットで書く。禁止だけだと行き先を探されます
• ルールの隣に事故の記録を置く。理由の無いルールは、状況が変わると適用外と判断されます
• 症状で渡す。原因の推測は渡さない。切り分けの誤りが引き継がれます
• 予防で行を増やさない。実害のあった行の可読性が落ちます

まとめると、この1年でやったことは「AIへの指示を上手くする」ではなく、「自分の運用ルールを、他人が読んで実行できる形に書き直す」作業でした。副産物として、自分の作業も安定しました。