監査プロンプトをAIツール別に持つのをやめた。10本を対象別3本へ統合した設計

docs の下に監査プロンプトが 10 本ありました。中身の 9 割は同じ文章で、違うのは想定している AI ツールの名前だけ。不変条件を 1 つ足すたびに、同じ段落を全ファイルへ貼って回っていました。

この記事のテーマ

ファイルを選ぶ軸を「どの AI ツールで動かすか」から「何を監査するか」へ移した話です。結果として正典は audit_app.md / audit_server.md / audit_doc_vs_impl.md の 3 本になり、DB 区分やセキュリティ profile はファイルではなく引数へ落ちました。統合のコミットは 27 ファイル変更、1748 行追加、4875 行削除で、差分の大半は削除です。

ツール別に切っていた当時の理屈は通っていました。並列でサブエージェントを撒けるツールと 1 つのコンテキストで深く考えるツールでは、指示の書き方を変えたほうが結果が良い。実際そう感じていました。破綻に気づいたのは機能追加ではなく CHANGELOG を書いているときで、「全 N プロンプトへ展開」という同じ言い回しがリリースのたびに出てくることに気づいてからです。

3 本に畳んでみて分かったのは、本当に違っていたのは安全境界だったということです。app は既定で調査のみ、サーバー診断は完全 read-only、資料と実装の突合は資料も実装も非変更。ツール軸で切っていたときは、この一番大事な違いがファイル名のどこにも出ていませんでした。

ツール名の代わりに書かせているのは capability です。ファイル検索、read-only コマンド、テスト実行、Web の一次情報、並列エージェント、独立 verifier、ファイル編集について yes / no / unknown と根拠を残させ、能力が足りないときは finding の確定条件を下げる代わりに「未検証」と書かせます。この形にしてから、新しいモデルや CLI が来ても正典を足す理由がなくなりました。

記事全体の要約。選択軸の移動、3 本それぞれの安全境界、ツール名の代わりに何を申告させるかを 1 枚にまとめています。

左が旧構成で、ファイルの選択軸に「どの AI で動かすか」が入っていました。右が新構成で、選ぶのは監査対象だけ。ツールの違いは選択軸ではなく実行時の申告項目になりました。