AI にコード監査を依頼すると、多くの finding が返ってきます。

問題の場所、重大度、再現条件、修正案。そこまではかなり詳しく出ます。

それなのに、監査が終わったあとに「で、次は何をすればいいのか」が見えないことがありました。

自分で作っている監査プロンプト集を見直して、結果報告の状態管理を作り直しました。今回のテーマは、監査の精度を上げる話ではありません。監査結果を、そのまま対応の作業表として使えるようにする話です。

AI支援開発の品質を担保するプロンプト集を作っています

自作で ai-audit-prompts という、監査・レビュー用のプロンプト集を作っています。AI に書かせたコードや作業へガードレールを掛け、見落としを減らすための実践知をまとめたものです。

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

同じように、AI へ監査を頼んだあとで対応の整理に困っている方は、下記で中身を確認できます。

README.md を読んで、使う監査 prompt を選ぶ

以前、「監査結果の先頭に通知表をつける」変更も書きました。スコアを付けると全体像は見えます。ただ、通知表の次に何をするかまでは別の設計が必要でした。

前回の記事: 監査結果の先頭に、通知表をつけた

監査結果を開いた瞬間に、次の一手が分からない

今回見直すきっかけになったのは、別のプロジェクトで実行した監査レポートでした。

そこには、たとえば次のような finding が並びます。

F-01 [fix] 画面の初期表示が一瞬だけ別ページになる
F-02 [fix] ページ遷移後に別の文書が表示される
F-07 [fix] 匿名ユーザーのレート制限を回避できる
F-12       オフライン着地時に初期表示がずれる
P-01       公開データの扱いに方針判断が必要

一見すると、[fix] が付いているものは対応済みに見えます。

でも本文を読むと、あるものはコード修正済み、あるものは migration 作成済みで適用待ち、あるものは検証待ちでした。

fix が「直すべきもの」なのか、「直したもの」なのか、「直したが確認していないもの」なのかが、一覧だけでは分かりません。

さらに、監査時点の結果報告へ、後から行った修正の記録も追記されていました。監査結果、対応計画、修正記録、保留判断が1枚に集まっている状態です。

情報は多い。でも、作業の入口としては見づらい。

[fix] は修正済みなのか、修正対象なのか

ここで、状態を一つのラベルに詰め込むのをやめました。

監査に関する状態と、対応に関する状態は別です。

項目	値	意味
監査判定	`確定` / `判断待ち` / `却下` / `重複`	敵対的検証の結果
対応状況	`plan` / `fix` / `pending`	対応作業の進み具合
検証状態	`未実施` / `検証待ち` / `確認済み` / `失敗`	対応後の確認結果
対応 C	`C1` / `C2` など	実際に行う作業の単位

それぞれの意味はこうです。

plan は、まだ対応作業が終わっていない状態です。修正案を提示しただけのときも、ここに置きます。

fix は、対応作業が完了した状態です。検証まで終わっているとは限りません。

pending は、ユーザーの判断や外部環境の準備が必要で、まだ着手できない状態です。

たとえば、コードは直したけれど検証環境が用意できていない場合は、次のように書けます。

対応状況: fix
検証状態: 検証待ち

これなら「修正は終わったが、確認が残っている」と一目で読めます。

C は finding を束ねる作業単位

finding を1件ずつ修正するとは限りません。

同じ原因から出た複数の finding を、一つの作業として扱うことがあります。

そこで、対応一覧に C を置きました。

C1: 初期表示と hydration の経路を揃える
    対応対象: F-01, F-02

C2: 匿名アクセスの制限を環境上で確認する
    対応対象: F-07, F-08

C3: 公開データの方針を決める
    対応対象: P-01, P-02

ここで大事なのは、C が単なる見出しではないことです。

各 C には、次の情報を持たせます。

対応対象の finding
何を達成する C なのか
実際に行う作業
変更するファイル
完了条件
検証方法
実行記録
対応状況

「F-07 を直す」ではなく、「匿名アクセスの制限を環境上で確認し、同一ユーザーと別ユーザーで挙動が分かれることを確認する」と書く。

作業の単位が見えると、次の人が続きから入れます。

結果報告を対応の作業ハブにした

今回の変更では、report_bug-security-quality-audit_*.md のような結果報告を、説明用の読み物だけで終わらせないことにしました。

総合評価の直後に、対応状況のサマリを置きます。

## 対応状況サマリ

全体: 対応中
plan: 8 / fix: 3 / pending: 2
検証待ち: 3

続けて、優先順位付きの対応一覧を置きます。

## 対応一覧（概要）

| 優先 | C | 対応対象 | 推奨対応の概要 | 対応状況 | 検証状態 | 次に行うこと |
|---|---|---|---|---|---|---|
| 1 | C1 | F-01, F-02 | 初期表示の経路を揃える | fix | 確認済み | 再発防止の検査を確認 |
| 2 | C2 | F-07, F-08 | 匿名制限を環境上で確認する | pending | 未実施 | 検証環境を用意する |

一覧の下には、C の詳細が続きます。

## C2: 匿名アクセスの制限を環境上で確認する

- 対応対象: F-07, F-08
- 対応状況: `pending`
- 目的: 利用者ごとの制限が別の利用者へ波及しないことを確認する
- 作業内容: 検証環境へ適用し、同一利用者と別利用者で確認する
- 変更予定ファイル: <対象ファイル>
- 完了条件: <確認できる状態>
- 検証: <実行する確認>
- 実行記録: <実施後に追記>

この report を開けば、監査の点数だけではなく、次に行う C が分かります。

plan と report は、同じものを二重管理しない

監査には plan md もあります。ここでまた役割が重なりそうになりました。

最終的には、次のように分けました。

文書	主な役割
audit plan	監査中の調査ログ、敵対的検証、確認済みルール
audit report	監査結果、対応状況、対応一覧、C の実行記録
子 plan	大きな C の詳細作業
bugfix	修正済みの障害の症状、原因、修正、検証
pending	今は着手しない判断と、再開条件

対応状況の正本は report です。

plan にも finding は残しますが、plan/fix/pending の現在値を plan と report の両方で手作業にすると、すぐにずれます。調査の根拠は plan、対応の現在値は report、と置き場所を決めました。

大きな C だけは、子 plan に分けます。親の report から子 plan へリンクし、子 plan から report に戻るリンクも置く。孫 plan は作りません。

調査だけの監査でも、状態が壊れないようにした

監査プロンプトには、ソースを書き換えない「調査まで」という既定スコープがあります。

このとき、修正案まで出したからといって fix にはしません。まだソースを変えていないので、対応状況は plan です。

一方、修正を含むスコープで実際にコードを変更したなら、その C は fix にできます。検証が終わっていなければ、検証状態は 検証待ち のまま残します。

判断が必要な finding は、監査判定を 判断待ち、対応状況を pending と分けて書けます。

ここを分けておくと、調査だけの report と修正まで行った report で、同じ表の意味を保てます。

6本の監査 prompt に同じルールを展開した

監査 prompt は、実行する CLI と DB の有無で分かれています。

一つのファイルだけ直すと、Claude 版では分かるのに Codex 版では分からない、といったズレが起きます。そこで、共通ルールを正本に置き、6本のコード監査 prompt へ同じ意味を反映しました。

今回揃えたのは、次の内容です。

結果報告の冒頭に対応状況サマリを置く
対応一覧を finding の優先順で作る
各 finding に対応 C を割り当てる
C の詳細と完了条件を最初から書く
C の完了後に report のサマリ、一覧、詳細を更新する
finding ID に [fix] を付けない
report の frontmatter を使う場合は type: audit-report にする

README と CHANGELOG にも、この出力の見方を書きました。

実際に作業して分かったこと

状態名より、状態の置き場所が大事だった

plan、fix、pending という単語自体は、AI 開発の現場でよく出てきます。

でも、同じ単語を finding ID の横、plan の context、report の frontmatter に置くと、意味が混ざります。

状態名を増やす前に、「この状態は何の状態なのか」を決める必要がありました。

今回の結論は、次の3つです。

監査の結果は 監査判定
対応作業の進み具合は 対応状況
対応後の確認は 検証状態

この3つを列として並べたら、かなり読みやすくなりました。

C は、AI に任せる単位ではなく、人間が追跡する単位

監査を実行する AI にとっては、finding が1件ずつあれば十分かもしれません。

でも、修正を引き継ぐ人にとっては、10件の finding を10回読むより、同じ変更にまとめられるものを1つの作業に束ねた方が楽です。

C は、そのための目印です。

実装の細かさではなく、「次に何をすれば完了なのか」が書ける粒度にする。ここを基準にしました。

report は最後に整形するものではない

以前の運用では、最後に結果報告を整えがちでした。

それだと、途中でセッションが切れたときに plan だけ残り、結果報告が空のままになります。

今回は、初期準備の段階で report にサマリ、一覧、C の骨格を作ることにしました。finding が確定するたびに追記し、C が終わるたびに更新する。

report を最後の清書ではなく、作業中の掲示板として使うイメージです。

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

AI にコード監査を頼むたび、禁止事項や調査観点を毎回書き直している人
監査結果を finding の一覧だけで終わらせず、修正と検証まで追跡したい人
Claude Code や Codex など複数の AI CLI で同じ監査ルールを使いたい人

監査を試すときは、README から対象に合う prompt を選べます。今回のような対応管理の考え方も、共通ルールとして同梱しています。

紹介ページ（概要と導線）: https://ishizakahiroshi.com/work.html?id=ai-audit-prompts
リポジトリ（Issue / PR 歓迎）: https://github.com/ishizakahiroshi/ai-audit-prompts

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

おわりに

今回の変更は、監査そのものを賢くするものではありません。

ただ、監査結果を受け取った人が「次に何をすればいいか」を迷わないようにしました。

AI の作業は、完了報告が出たあとに本当の作業が始まることがあります。ならば、完了報告の中に、次の作業単位と確認方法まで残しておく方がいい。

小さく。結果報告を開いたら次の C が分かる形を、これからの監査でも続けていきます。

📎 図解版・関連リンクをまとめたページがあります:
https://ishizakahiroshi.com/articles/2026/2026-08-08_audit-report-c-management/

書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi

バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。