自作の監査プロンプト集 ai-audit-prompts を「2026年の最新トレンドに追随しているか」で総点検し、AIエージェントのworkflowで更新しました。結論だけ先に書きます。

9日前に全項目確認したはずのpinned基準が、再確認したら1本古くなっていた（OpenSSF OSPS Baseline の新版が公開4日後の時点で未反映。https://baseline.openssf.org/ ）
9つの切り口の並列調査で修正案132件を生成し、事実性と規約適合の2レンズで敵対検証してから適用した。内訳はそのまま採用31 / 修正して採用91 / 棄却10
実在しない事故名を根拠にした修正案が1件、コマンド挙動の誤説明が1件、2レンズが別々に検出した。片方のレンズだけなら通っていた
エージェントは通算58体、トークンは2回の実行あわせて約885万。途中で利用上限に当たり19体が連続停止したが、resumeで完走

この記事は、その手順と落とし穴の記録です。

対象の監査プロンプト集

何ができるかの紹介ページ: https://ishizakahiroshi.com/work.html?id=ai-audit-prompts
リポジトリ（Star をいただけると励みになります）: https://github.com/ishizakahiroshi/ai-audit-prompts

AIに書かせたコードや作業を安全に取り込むための、貼り付け用の監査プロンプト集です。使い方はリポジトリを clone して、docs 配下の正典プロンプト全文を、使っているAIエージェントへ貼るだけです。特定のAI製品には依存させていません。インストールや設定ファイルもありません。

docs/
  audit_app.md                 アプリ／ソースコード監査の正典
  audit_server.md              管理下サーバー診断の正典（完全read-only）
  audit_doc_vs_impl.md         資料と実装の突合の正典（完全非変更）
  README_invariants*.md        共通契約の正本（app / server）
  README_activation.md         「対象」で正典を選ぶrouting

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

きっかけ: 「最新に対応してる?」に即答できなかった

プロンプト集には、監査の拠り所にするセキュリティ基準を名前・版・URLで固定（pin）した一覧があります。9日前に全項目を一次情報で確認済みでした。

それでも即答を避けて再確認したら、OpenSSF OSPS Baseline に新版が出ていました。こちらの確認5日後に公開されたものです。確認から9日、公開から4日で「最新」の看板が嘘になる。この速度を人力で追うのは無理だと判断して、更新そのものをAIのworkflowに任せることにしました。

全体の流れ

1. Research   9つの切り口で並列調査（各エージェントは一次情報のURL取得が必須）
2. Critic     調査の抜けを探す完全性批評（不足領域を追加調査）
3. Gap        現行プロンプトと突き合わせて修正案132件を生成
4. Verify     修正案を6件ずつ22組に束ね、各組を2レンズで敵対検証
5. Apply      生き残った案を人間が適用し、機械検査（文書構造check・secrets scan）で締める

切り口は、pinned基準の現行版、AIコーディングエージェント設定への攻撃、ソフトウェア供給網、脆弱性情報源、Web/アプリ、サーバー堅牢化、資料と実装の突合、AI監査手法、規制と国内情報源、の9つです。

修正案は「そのまま適用できる形」で出させる

散文の提案は受け取りません。全エージェントにJSON Schemaを渡し、置換対象の現文と修正後の完成文を持つ構造で返させます。

id: audit_app-17
file: docs/audit_app.md
change_type: modify        # add / modify / remove
current_text: "<置換対象の現文をそのまま>"
proposed_text: "<修正後の完成文>"
rationale: "<なぜ必要か>"
sources: ["https://<一次情報のURL>"]
priority: high             # high / medium / low

current_text を実文と完全一致で書かせるのがポイントです。一致しなければ適用時に必ず失敗するので、「それっぽいが当てられない提案」がこの時点で detect できます。

2レンズの敵対検証

修正案をそのまま採用すると、もっともらしい誤りが混ざります。そこで役割の違う2種類の検証エージェントに、それぞれ「反証」を試みさせました。

事実性レンズ: 修正案が引く版数・日付・URL・事故名・CVEを、その場で再fetchして裏取りする。確認できなければ落とす
規約適合レンズ: プロンプト集側の決まり（特定製品名を正典に入れない、日付や版を本文へ焼き込まない、read-only契約を弱めない、冗長な重複を作らない）との衝突を探す

判定は keep / modify / drop の3値で、modify には修正済みの完成文を返させます。実際に落ちたもの、直されたものの例です。

実在しない事故名が根拠に混ざっていた。検索で痕跡ゼロ。事実性レンズが drop
あるコマンドのdry-run挙動の説明が一次資料と食い違っていた。事実性レンズが正しい表現に modify
ベンダー中立であるべき正典に特定製品のモード名が紛れた。規約適合レンズが一般語へ modify
「2026-XX-XX時点で最新」を本文に焼き込む案。陳腐化するので規約適合レンズが日付の置き場を直した

132件の判定は keep 31 / modify 91 / drop 10 でした。7割は無修正では通っていません。

修正案1件ごとに2レンズが独立に反証し、どちらかが drop すれば採用しない、modify は完成文ごと差し替える、という流れです。

運用の学び

resumeは「失敗した分だけ」再実行ではない。使ったworkflow基盤のキャッシュは先頭からの無変更prefixだけで、最初の失敗地点より後は成功済みでも再実行される。再実行された検証エージェントは編集後の作業ツリーを読むので、判定が「既に反映済みなので重複」へ変わる。今回はそれが重複提案8件の正しい棄却として働いたが、逆向きに壊れることもある
検証と適用を並走させるなら、検証対象のファイルと編集中のファイルを分ける。分けないと上の現象が予測不能になる
検証フェーズのエージェント数は起動前に見積もる。22組×2レンズ=44体が利用上限に届き、19体が連続停止した。resumeで完走できたが、budgetガードを入れておくべきだった
pinは確認日と更新手順をセットで持たせる。今回から一覧に確認日を明記し、更新時の同期手順をリポジトリの運用ルールに残した

検証フェーズの実際の風景は、だいたいこの挿絵のとおりです。1件ずつの赤入れが夜通し続きました。

今回プロンプト集に増えた観点（抜粋）

2025〜2026年に顕在化した攻撃・実務の変化から、監査観点をいくつも足しました。抜粋です。

リポジトリ内のAIコーディングエージェント設定（instruction file・hook・MCP定義・auto-approve設定）を、AI機能の有無に関係なく常時監査する。隠しUnicodeやHTMLコメント経由の命令注入、追跡されたAIセッションログの混入も見る
依存パッケージのinstall時ポリシー（lifecycle scriptの遮断、新版のcooldown）、publish経路がOIDCか長期トークンか、AI由来の実在しないパッケージ名（slopsquatting）の登録日照合
サーバー診断に、ホスト上の資格情報でバックアップを消せるか、公開面に露出したAI推論サービスやMCPサーバー、self-hosted runnerの見覚えのない登録痕跡
却下にも証拠を要求する対称な evidence contract（「複数エージェントの合意」を証拠にしない）

全文はリポジトリの docs 配下にあります。

おわりに

「最新に対応しているか」への正直な答えは、「今日の時点では対応している。ただし9日後は分からない」です。だから確認日を書き、調べる・直す・疑うをAIに任せられる形を整えました。決めるところだけが人間の仕事として残ります。

ai-audit-prompts はこんなときに刺さります

AIにコードを書かせているが、レビュー観点が場当たりになっている
AIに監査を頼んだら勝手にコードを直された経験があり、read-onlyの契約が欲しい
監査報告が「概ね問題なし」で終わり、何を確認して何を確認していないのか分からない
自分の管理サーバーを、状態を一切変えずに点検させたい

心当たりがあれば、リポジトリを clone して docs のプロンプトを貼るだけで試せます。インストールや設定ファイルは不要です。

紹介ページ（スクショと機能一覧）: https://ishizakahiroshi.com/work.html?id=ai-audit-prompts
リポジトリ（Issue / PR 歓迎）: https://github.com/ishizakahiroshi/ai-audit-prompts

Star をいただけると開発の励みになります。使ってみて「ここが不便」があれば、Issue でも X の DM でも大歓迎です。