上の 1 枚に記事全体が入っています。ファイルを選ぶ軸、3 本それぞれの安全境界、ツール名の代わりに何を申告させるか、の 3 つが要点です。
docs/ の下に監査プロンプトが 10 本ありました。中身の 9 割は同じ文章で、違うのは冒頭の数行と、想定している AI ツールの名前だけ。不変条件を 1 つ足すたびに、同じ段落を全ファイルへ貼って回っていました。
先に結論だけ書きます。
- 分ける軸を「どの AI で動かすか」から「何を監査するか」へ変えた
- 結果、正典は
audit_app.md/audit_server.md/audit_doc_vs_impl.mdの 3 本になった - ツール名やモデル名の代わりに、その場で使える能力（capability）をプロンプト側に申告させることにした
ツール別に切っていた監査プロンプト集の話
自作で ai-audit-prompts というプロンプト集を公開しています。AI 支援開発の品質を担保するための、監査・レビュー用プロンプト集です。
- 何ができるかの紹介ページ: https://ishizakahiroshi.com/work.html?id=ai-audit-prompts
- リポジトリ（Star をいただけると励みになります）: https://github.com/ishizakahiroshi/ai-audit-prompts
インストールするものはありません。実行コードもビルド成果物も入っていないので、clone して対象に合う 1 本を AI へ貼るだけです。
git clone https://github.com/ishizakahiroshi/ai-audit-prompts
起動の仕方は Windows / macOS / Linux で変わりません。AI 側にこう頼みます。
<repo>/docs/audit_app.md のprompt全文を使って監査して。
DB区分: 自動
強度: ミッド
スコープ: 調査まで
確認: あり
この話には前があります。監査で出た finding が「直したのか、直っていないのか」分からなくなり、結果報告 md を対応の作業ハブに作り替えたのが直前の回でした。
前回の記事: AIコード監査の「修正済み」が分からない。findingをC管理にして結果報告を作業ハブにした
最初は「ツールごとに best な書き方が違う」と思っていた
v0.1.0 は 4 本でした。Claude Code 版と Codex CLI 版、それぞれに DB あり / なしの 2 種類。
理由はもっともらしかった。並列でサブエージェントを撒けるツールと、1 つのコンテキストで深く考えるツールでは、指示の書き方を変えたほうが結果が良い。実際そう感じていました。
そこから、Fable 5 対応で 2 本増え、サーバー診断で 3 本増え、資料突合で 1 本増えた。ツール軸 × 監査対象軸の掛け算なので、片方の軸が伸びるともう片方の本数ぶん増えます。
掛け算の表を、毎回ぜんぶ手で埋めていた
破綻に気づいたのは、機能追加ではなく CHANGELOG を書いているときでした。
- v0.3.0: 全 6 プロンプト + 正本に grounded progress claims を追加
- v0.5.0: 全 9 プロンプト + 正本 2 ファイルにスコアリング規約を展開
- v0.7.0: 全 9 プロンプト + 正本 2 ファイルに実行前確認ゲートを追加
「全 N プロンプトへ展開」という同じ言い回しが、リリースのたびに出てくる。追加したい規約はいつも 1 個なのに、書き込む先が毎回 6 だったり 9 だったりする。しかも展開漏れは目視でしか見つからない。
このとき自分がやっていたのは設計ではなく、掛け算の表の手入力でした。
上の図のとおり、旧構成はファイルの選択軸に「どの AI で動かすか」が入っていました。新構成では選ぶのは監査対象だけで、DB 区分やセキュリティ profile はファイルではなく引数に落ちます。ツールの違いは、選択軸ではなく実行時の申告項目になりました。
モデルが増えるたびに、ファイルが増える設計だった
もっと嫌だったのはこちらです。
v0.3.0 で claude_fable5_audit_db_app.md を claude_fable_audit_db_app.md にリネームしています。Fable 6 が出たときに全部改名し直したくなかったからです。バージョン番号を外して延命したわけですが、これは対症療法でした。ファイル名にツール名が残っている限り、ツールが増えれば本数も増える。
手元で常用している AI CLI は、いまは 6 つあります。この設計のままなら、新しいモデルや CLI が来るたびに「これはどのファイルを使えばいいですか」という問いが発生し、そのたびに本数を増やすか、増やさない言い訳を README に書くことになります。
そもそも、製品名から能力は決まりません。同じモデルでも CLI なら shell が使えて Web UI なら使えない。並列エージェントが撒けるかどうかも、モデルではなく実行環境の話です。ファイル名にツール名を書くのは、決まらないものを決まったことにする行為でした。
分けるべきだったのは、安全境界のほうだった
では何が本当に違ったのか。3 本に統合してみると、はっきりしました。安全境界です。
| 対象 | 正典 | 既定の安全境界 |
|---|---|---|
| app / リポジトリ / ソース | audit_app.md |
既定は調査のみ。明示スコープと承認があるときだけ最小修正 |
| 管理下サーバー / VPS | audit_server.md |
完全 read-only。対策の適用は人間 |
| 資料と実装の突合 | audit_doc_vs_impl.md |
資料も実装も UI も完全非変更。修正は提言だけ |
サーバー診断がコード監査と違うのは「Codex か Claude か」ではなく、状態を一切変えてはいけないという一点です。資料突合も同じで、資料と実装のどちらも触らない前提が守れるかどうかがすべて。ツール軸で切っていたときは、この一番大事な違いがファイル名のどこにも出ていませんでした。
いま routing は target → DB/profile → capability の順に解決します。判定できないときの既定は app です。
ツール名を書かせるのをやめて、できることを申告させた
代わりにプロンプト側でやらせているのが、capability の記録です。ファイル検索、read-only コマンド、テスト実行、Web の一次情報、並列エージェント、独立 verifier、ファイル編集について、yes / no / unknown と根拠を残させます。
効くのは、能力が足りないときの振る舞いを能力ごとに書けることです。
- 並列と独立 verifier がある: 探索と検証を別のコンテキストに分ける
- 並列だけある: 探索を lead 出しに限定し、統合役が読み直す
- 並列がない: 直列で二巡して反証する
finding を確定させる条件は、どの経路でも下げません。下げる代わりに「未検証」と書かせます。この形にしてから、新しいモデルが来ても正典を足す理由がなくなりました。増えるのは申告される能力の組み合わせだけで、ファイルは 3 本のままです。
ついでに、自分でつけた通知表を外した
副産物として、レポート冒頭の「総合 100 点満点」を既定から外しました。2 か月前に自分で足した機能です。
点数は一目で伝わるのですが、分母が監査の走査範囲に依存するので、範囲を狭めるほど点が上がってしまう。既定は coverage、evidence、候補検証率、未調査、residual risk の表示にして、点数は明示要求されたときだけ、分母と未調査の扱いを定義したうえで参考値として出すようにしました。
確定 finding ≠ 適用済み修正 も明文化しています。監査判定、対応状況、検証状態は別々に追跡する。ここは前回の記事で作った C 管理の続きです。
旧パスは消さずに alias にした
統合のコミットは 27 ファイル変更、1748 行追加、4875 行削除でした。差分の大半は削除です。
旧パスは削除せず、frontmatter に後継の相対パスと引数だけを持つ短い alias にしました。監査本文は持たせません。
# [Deprecated] claude_fable_audit_db_app.md
後継の audit_app.md 全文を使い、DB区分は「あり」を指定してください。
自分のリポジトリの中だけを見れば消してよいのですが、どこかのプロジェクトの設定に旧パスが直書きされていた場合、消すと「ファイルが無い」で終わります。移行案内が出るほうがまだ親切なので、1 回の移行リリースぶんだけ残します。削除は consumer の移行確認を条件にした別プランでやります。
docs/ 直下の公開 Markdown は現在 22 本で、内訳は正典 3 本、移行用 alias 14 本（統合前にあった 10 パスと、tool 名を含まない generic な 4 パス）、routing と invariants と index が 5 本です。alias は自動選択にも推奨一覧にも正典数にも含めません。
ai-audit-prompts はこんなときに刺さります
- AI に書かせたコードを、そのまま業務へ入れるのが怖い人
- 「監査して」と頼んだらソースが書き換わっていた経験がある人
- 使う AI CLI が複数あって、ツールごとにプロンプトを作り分けるのに疲れた人
- 説明会資料やマニュアルの記載が、今の実装と合っているか確かめたい人
clone して 1 本貼るだけで試せます。インストールも設定ファイルも要りません。
- 紹介ページ（スクショと機能一覧）: https://ishizakahiroshi.com/work.html?id=ai-audit-prompts
- リポジトリ（Issue / PR 歓迎）: https://github.com/ishizakahiroshi/ai-audit-prompts
Star をいただけると開発の励みになります。使ってみて「ここが不便」があれば、Issue でも X の DM でも大歓迎です。
あわせて読みたい
- 「監査して」と頼んだら、コードが書き換わっていた（今回維持した「既定は調査まで」という安全境界を決めた回です）
- 監査結果の先頭に、通知表をつけた（今回この 100 点満点を既定から外しました。足した理由と外した理由の両方が並びます）
- 指示を、書きすぎていた。AIコード監査プロンプトを「ループ設計」でやり直した話（ファイル名からバージョン番号を外した回。今回の統合の伏線でした）
おわりに
ツール別に作り分けていた 2 か月半は、無駄ではなかったと思っています。3 本ぶんの差分を実際に書いてみないと、「違うのはツールではなく安全境界だ」とは気づけませんでした。
ただ、掛け算の表を手で埋めている感覚が出てきたら、それはもう軸を間違えているサインです。次に何かを足したくなったとき、ファイルを増やす前に「これは選択軸か、引数か」を一度考える。小さく、それだけを習慣にしていきます。
📎 図解版・関連リンクをまとめたページがあります:
https://ishizakahiroshi.com/articles/2026/2026-08-23_audit-prompts-tool-to-target/
※ ヘッダー画像とインフォグラフィックは AI（画像生成）で作成しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。