AIへの指示書に書いても、AIは確率でしか守ってくれない — 守らせたいルールは仕組みに落とす

うちでは以前、AIへの指示書が太りすぎて読まれなくなり、分離とCIで行数を抑えたことがある。

でも、行数を抑えても残る問題がある。指示書に書いたルールを、AIが確率でしか守ってくれないことだ。

「お願い」は、確率でしか効かない

指示書に「秘密情報はコードに書くな」と書く。たいていは守る。でも、たまに守らない。文脈が長くなったとき、急いでいるとき、別の指示と競合したとき——重要度の判定がぶれて、すり抜ける。

これは叱れば直る類のものではない。指示書というのは本質的にお願いで、AIはそれを「必ず」ではなく「だいたい」で読む。人間の新人に口頭で「気をつけてね」と言うのと同じで、効くけれど、確率でしか効かない。

問題は、ルールの中に「確率で守られては困るもの」が混ざっていることだ。秘密情報の露出、顧客名の掲載、権限のバイパス。これらは10回に1回すり抜けただけで事故になる。お願いに置いておいてはいけない種類のルールだ。

守れないと事故になるルールは、機械に移す

そこで、ルールを「守れなかったときの困り具合」で二層に分けた。

• 守れなくても許容できるもの → 指示書に残す（お願い・メモ）
• 守れないと事故になるもの → 機械に移す（CI・フック）

うちで実際にこの移し替えをやったのが、このJournal自身だ。記事はmarkdownを置くと静的生成で公開される仕組みで、指示書には秘密情報を出すなと書いてあった。だが公開前チェックは人力のチェックリストで、クライアント実名という観点は明文化すらされていなかった。記事の本文と内部のネタ帳に残っていた実名が、公開ページにそのまま流れ込んだ。お願いは、書いても確率でしか効かないうえに、そもそも書き漏れる。

いまは公開物のビルドコマンドに禁止語スキャンを一段挟んでいる。記事本文にも生成物にも、承諾を得ていないクライアント名が一箇所でも残っていれば、ビルドが失敗して公開されない。新しいクライアントと契約したら禁止語リストに実名を足す、という運用ルールとセットだ。

書いておけば「だいたい守る」だったものが、機械に移すと「必ず引っかかる」に変わる。確率が確定に変わる。この非対称性が全部だ。

ただし、機械で「落とす」のは確定NGだけ

ここが二つ目の線引きだった。機械に移すルールを、さらに二段階に分けている。

• 確定的にNG → CIで赤にして物理的に止める
• たぶんNG・要判断 → 指摘を返すだけで、止めない

なんでもCIで赤にすればいいわけではない。判断の要るルールまで機械で落とすと、偽陽性が出たときに困る。AIは「赤を消さなきゃ」と関係ないところまで書き換え始めるし、人は赤に慣れて警告そのものを無視するようになる。止める力は、誤検知がほぼ出ないルールにだけ使える。

だから、CIで落とすのは禁止語スキャンのような文字列照合で判定しきれるものに絞った。一方、「この記事は"やってみた"で終わっていて、読者に判断基準を渡せていないのでは？」のような疑いは、機械には判定しきれない。公開前ゲートはエラーと警告を分け、警告は表示するだけで止めない。ツール側でも同じ形にしていて、スキルを直す依頼が来た時点で、フックが「カタログの再生成を忘れるな」と一言差し込むだけにしている。直すか流すかは、指摘を受けた側が判断する。

機械にできるのは「機械で判定しきれるものを止める」ことと「怪しいものに気づかせる」ことまで。判断そのものは機械に渡さない。

心がけを、仕組みに翻訳する

この設計は、うちがずっと言っている「意志に頼るな、構造に頼れ」の、AI相手での実装そのものだった。

「クライアント名に気をつけよう」は意志だ。人間でもAIでも、意志は疲れるし、確率でしか効かない。同じルールを機械に書き直すと、それは構造になる。疲れないし、確率が確定に変わる。

大事なのは、全部を機械にしないことだ。お願いで足りるものはお願いに置く（そのほうが柔らかいし、直すのも早い）。機械に移すのは「確率で守られては困る」ものだけ。そしてその中でも、確定的NGだけをCIで止め、グレーは指摘に留める。

指示書は「お願い」でいい。ただし、守れないと事故になるルールだけは、お願いではなく仕組みに書く。この線引きが引けると、AIに任せられる範囲が一段広がる。