AIに守らせたいルールを、指示書からコードに移した。二度止められた

私は副業の発信をAIと一緒に運用していて、絶対に守ると決めたルールがいくつかある。たとえば「投稿の最後の一言は自分で書く。AIには書かせない」。

以前はそれを、AIへの指示書に「そうしてほしい」と書いていた。今はコードで弾いている。この記事は、そのチェックを作った話と、そのチェックに二度止められた話だ。二度目は誤検知だった。うまくいった話だけでは半分なので、両方書く。

きっかけ

運用の記録更新は、ファイル3つを書き換えるだけの1分の作業だった。その1分で、実際にミスが起きた。2026年7月28日に更新を忘れ、使い終わったネタが在庫のまま見えて、同じネタの下書きを二度作りかけた。1分の作業でも、人は忘れるし間違える。そしてAIも、指示書に書いたルールを毎回確実に守るとは限らない。

実際にやったこと

Claude Code の PostToolUse フック(ファイル書き込みなどのツール実行後に任意のスクリプトを走らせる仕組み)を使って、ファイルを保存した直後に Python スクリプト(97行)が検証を走らせるようにした。検証は4項目。

1. ファイル名が決めた形式(日付+タイトル)か
2. 投稿ファイルの状態が「投稿済み」なら、自分で書くと決めた一言が実際に埋まっているか
3. ネタの出典欄に URL か「実践」の記載があるか
4. 状態欄の値が、決めた4つの語のどれかか

違反すると exit code 2 でエラーが返り、その理由がAI側に渡って修正を促す。公式ドキュメントで確認した仕様として、PostToolUse は書き込みの後に走るため処理自体は止められない(事前に止めたいなら PreToolUse を使う)。また、ブロック扱いになるのは exit 2 のみで、exit 1 は無視される。この辺りは作る前に知っておくと迷わない。

起きたこと(1回目: 正しい検知)

作ったのは7月23日の夜。次に思い出したのは7日後だった。

7月30日の朝、記録更新の作業中に、AIが状態欄へ「使用済み」と書いた。決めてある値は「未使用・下書き済み・投稿済み・アーカイブ」の4つで、「使用済み」はどれでもない。保存した直後にエラーが返り、書き直しになった。

私はこのチェックを作ったこと自体を忘れていた。ファイルの日付を見て思い出した。作成は7月23日20時33分、以来一度も直していない。指示は忘れられる。人もAIも忘れる。コードは忘れず、毎回同じ判定をする。 これを実際に体験した瞬間だった。

起きたこと(2回目: 誤検知)

その翌日の7月31日の夜、同じスクリプトが今度は誤って止めてきた。

翌日分の下書きの状態欄を「下書き」に直したら、「状態が『投稿済み』なのに、一言が空です」というエラーが返った。状態には下書きと書いてある。意味が分からず、数分詰まった。

原因を調べる

判定の正規表現がこう書かれていた。

elif re.search(r"^\s*-\s*状態:.*投稿済み", content, re.M) and ...:

状態: のあとが .*投稿済み なので、状態の値ではなく行全体を見ている。同じ行の後ろに書いた補足文「公開確認後に『投稿済み』へ更新する」の3文字に反応していた。

さらに調べると、この欠陥は前日にできたものではなかった。以前のファイルにも同じ書き方の行はあったが、別の条件が先に満たされていたため表に出ていなかっただけ。欠陥は作成時から存在していて、条件が揃った日に初めて見えた。

修正

同日中に直した。かかったのは調査・修正・検証あわせて約45分。

1. 状態判定を値だけに限定(状態:\s*投稿済み)
2. ついでに見つけた検証漏れ2点(投稿側の状態値検証がなかった/複数案あるとき不採用案の記入でも通ってしまう)も修正
3. 既存の32ファイル(投稿14・ネタ18)に対して修正前後の判定を比較し、退行ゼロを確認。誤検知パターンを含む5ケースの挙動テストも作った

分かったこと

事実: 正しい検知1回、誤検知1回。誤検知の原因は雑に書いた正規表現で、作成時から潜在していた。

解釈:

• 「コードは間違えない」は半分だけ正しい。コードは書いたとおりに間違える。仕組みに何を教えたかが、そのまま出る
• チェックが通っている間は、チェック自体の正しさを確認する機会がない。欠陥は、条件が揃うまで静かに潜伏する
• それでも指示書よりコードが良い。指示は守られたかどうかすら分からないが、コードは判定の根拠を調べられるし、直せば直る

次からどうするか

判定条件を書いたら、通るケースだけでなく、落ちるはずのケースも最低一度は流す。 今回の誤検知は、作成時に「わざと違反したファイル」を通していれば、その場で見つかっていた。

この習慣は後日、このサイト自体の公開ガード(承認なしでは記事を公開できないCI)を作ったときに実践した。わざと破ってみたら、本当に穴が見つかった。その一部始終はこちらの記事に書いた。

同じことをする人へのポイント

• 「毎回必ず守りたいルール」が指示書に書いてあるなら、それはコード化の候補。判定できる形に言い換えられるかを試すとよい
• 小さく始められる。私の場合は97行のスクリプトと4項目で、実害のあったミス(値の誤記入・更新漏れ)を機械が拾う範囲に入れた
• ガードは作った直後に、わざと違反して赤くなるのを見る。それまでガードは「あるはず」でしかない
• 誤検知は起きるものとして扱う。止められたら、まずルール側とデータ側のどちらが正しいかを確認する習慣にする

なお、指示書側を減らした話はAIへの指示書を72%削った記録に書いた。減らした指示と、コードにした指示は対になっている。

この記事は、運営者自身の実践記録に基づいています。