AIコード監査レポートのテンプレート（クライアントが期待するもの）

AI生成コードの監査レポートは7つの部分で構成します。エグゼクティブサマリー、監査範囲と除外事項、監査の方法、深刻度テーブル、証拠と修正方法を添えた指摘ごとの項目、担当者と期日を定めた是正計画、そして承認（サインオフ）です。クライアントが対価を払うのは指摘に対してですが、レポートの評価は「あなたに電話せずに動けるかどうか」で決まります。

この記事は、AI生成コードの監査を販売するエージェンシーやスタジオ、そしてその報告書を受け取る側の創業者に向けて書いています。以下の構成は、セキュリティテスターがすでに使っている公開された慣習、つまりOWASP Web Security Testing Guideのレポート章とCVSS v4.0の深刻度スケールに従い、いまクライアントが実際に相談してくるケース、つまり数週間でCursor、Claude Code、Copilotがほぼ書き上げ、中身を誰も正確に把握していないコードベースに当てはめたものです。

AIコード監査レポートは何のためにあるか

コード監査レポートは同時に3つの役割を果たします。技術に詳しくない買い手に、その製品をリリース・販売・資金調達に使って安全かを伝える。エンジニアに、何をどの順番で直すべきかを正確に伝える。そして後日の再レビュー担当者、投資家の技術アドバイザー、SOC 2の監査人が照合できる記録を残す。

AI生成コードが変えるのは重点であって、形式ではありません。私たちがよく目にする欠陥は、OWASP Top 10:2025が上位に挙げるものと同じです。アクセス制御の不備、セキュリティ設定ミス、誰も意図して選んでいない依存関係によるサプライチェーンの問題。それに加えて、生成コード特有の問題があります。デモの経路では動くのにエッジケースでは何もしない機能、そして機能を作らせたプロンプトに書かれていなかったために実装されなかった要件です。

したがって良いレポートは、1つではなく2つの問いに答えます。コードは安全か。そして、コードは依頼されたとおりに動くか。後者は要件監査であり、クライアントはたいていそれを頼むべきだと知りません。

クライアントが期待する7つのセクション

OWASP Web Security Testing Guideは、セキュリティテストのレポートに4つのトップレベルセクション（Introduction、Executive Summary、Findings、Appendices）を推奨しています。広く使われているLenny Zeltserの評価レポートテンプレートは、同じ内容を8つに分けています。私たちは7つにしています。コード監査は攻撃のされ方だけでなく、コードが何をするかも扱う必要があるからです。

セクション	読む人	含めるべき内容
1. エグゼクティブサマリー	創業者、投資家、買い手	1段落の結論、深刻度別の件数、3つのテーマ、チームがうまくやっていること
2. 範囲と除外事項	全員	リポジトリ、コミット、環境、日付、見なかったものとその理由
3. 方法	エンジニア、監査人	ツールとバージョン、使ったチェックリスト、深刻度モデル、生成コードの特定方法
4. 深刻度テーブル	全員	指摘ごとに1行：ID、タイトル、深刻度、状態
5. 指摘事項	エンジニア	指摘ごとに1項目：証拠、影響、再現手順、修正方法
6. 是正計画	エンジニアリングリード、クライアント側PM	順序付けた修正、担当者、目標日、検証手順
7. 承認	双方	誰が監査し、誰が受理したか、再テストの条件、秘密保持

順序が重要です。経営層は1ページ目とテーブルを読みます。エンジニアはまっすぐセクション5へ向かいます。どちらかが探し回らなければならないなら、そのレポートは役目を果たしていません。

1. エグゼクティブサマリー

最後に書き、半ページに収めます。何を監査したかを1文で、結論を1文で（「2件のクリティカルな指摘が修正されるまで、このアプリケーションは有料顧客向けに提供できる状態ではない」）、次に深刻度別の件数、次に指摘の大半を説明する2〜3のテーマ。コードベースがうまくやっていることを1つ挙げてください。残りの内容の信頼性が上がります。ここにペイロード、CVE番号、ツール名は書きません。

2. 範囲と除外事項

監査した各リポジトリとコミットハッシュ、ブランチ、アクセスできた環境、日付を列挙します。次に除外事項を理由付きで：サードパーティサービス、見えなかったインフラ、範囲外のモバイルアプリ、クライアントが触らないよう求めたもの。範囲に含めたものしか書かない範囲セクションは、それ以外すべてに対する保証として読まれます。

AI生成コードの場合、出自について1行加えます。コードベースのどれくらいが生成されたとクライアントが考えているか、どのツールで、マージ前に人間がレビューしたか。正確に検証することはできないので、クライアントの申告として書きます。

3. 方法

ツールとそのバージョン（SASTスキャナー、依存関係監査、シークレットスキャナー）、従った手動レビューのチェックリスト、深刻度モデルを明記します。レビュー中にAIアシスタントを使ったなら、そのことと、何を許可したかを書きます。参照した標準を挙げます。カテゴリー名にはOWASP Top 10:2025、深刻度にはCVSS v4.0の定性スケール、クライアントが検証レベルの名前を必要とするならOWASP ASVS 5.0.0。後日別の会社を雇ったクライアントが、2つのレポートを比較できるようにするためです。

4. 深刻度テーブル

指摘ごとに1行。私たちはCVSS v4.0の定性バンドを使います。公開されていて、誰も異論を唱えないからです。Criticalはスコア9.0〜10.0、Highは7.0〜8.9、Mediumは4.0〜6.9、Lowは0.1〜3.9。脆弱性ではないが後でチームの負担になるもの、たとえばテストスイートの欠如やメンテナンスされていない依存関係には、Informationalレベルを追加します。

ID	指摘	カテゴリー	深刻度	状態
F-01	認証済みの任意のユーザーが `/api/invoices/:id` 経由で任意のワークスペースの請求書を読める	Broken Access Control	Critical	未対応
F-02	Stripeのwebhookが署名なしのイベントを受け付ける	Software or Data Integrity Failures	High	未対応
F-03	既知のアドバイザリがある依存関係が14件、メンテナー不在が2件	Software Supply Chain Failures	Medium	未対応
F-04	パスワードリセットトークンが失効しない	Authentication Failures	Medium	未対応
F-05	仕様にあるエクスポート機能が実装されていない	要件の欠落	Informational	未対応

上の行は形式を示す例であり、実際の案件の指摘ではありません。3列目のカテゴリーはOWASP Top 10:2025の名称なので、クライアントが自分で調べられます。

5. 証拠付きの指摘事項

すべての指摘に、毎回同じ項目を同じ順序で付けます。WSTGが列挙しているのは、参照ID、タイトル、発生可能性、影響、リスク評価、問題の説明と悪用方法、段階的な是正手順、そして任意で開発者が修正を確認できるcurlコマンドなどの再現可能な成果物です。私たちはAI生成コード向けに2項目を加えています。

どこから来たか。 ファイルと行、そして同じパターンが他にもあるか。生成コードは自分のミスを複製します。テナントIDの未検証が1か所なら、たいてい5か所あります。
なぜ起きたと考えられるか。 責任を問うためではなく、修正がコードだけでなくプロンプトやテンプレートにあることが多いからです。「指示にマルチテナントの言及がなかったため、ルートハンドラーがワークスペースのスコープなしで生成された」と書けば、チームは同じバグを作り続けないための方法が分かります。

証拠とは、クライアントのエンジニアが実行できるものです。スキャナー結果のスクリーンショットは証拠ではありません。別テナントのデータを返したリクエストが証拠です。

6. 是正計画

指摘を作業に変換します。深刻度順に、次にその修正が他の指摘をいくつ閉じるかの順に並べます。それぞれにクライアント側の担当者、目標日、検証手順（「付録Bの2テナントスクリプトでF-01を再テスト」）を付けます。今すぐ直す、リリース前に直す、四半期内に直すを区別します。期日のない計画はただのリストです。

7. 承認

誰が監査を行い、どんな資格を持つか。クライアント側の誰がいつレポートを受理したか。料金にどの再テストが含まれるか。レポートの有効期限（私たちは日付ではなくコミットで示します）、そして秘密保持の条件。クライアントが第三者にレポートを見せるなら、どの版かを明示します。ほとんどの買い手に必要なのはエグゼクティブサマリーと深刻度テーブルであり、再現手順ではありません。

コピーして使えるMarkdownの骨組み

ドキュメントツールに貼り付けて埋めてください。貼り付け先ページの見出しと衝突しないよう、セクションのラベルは太字で書いています。

**監査レポート：<製品名>**
バージョン1.0 · <日付> · <監査会社>が<クライアント>向けに作成 · 秘密情報

**1. エグゼクティブサマリー**
範囲を1文で。結論を1文で。
指摘：Critical <n>件、High <n>件、Medium <n>件、Low <n>件、Informational <n>件。
テーマ：(1) ... (2) ... (3) ...
うまくいっている点：...

**2. 範囲と除外事項**
リポジトリとコミット：<repo>@<sha>
環境：...
期間：<開始>〜<終了>
出自（クライアント申告）：約<x>%を<ツール>で生成、レビュー者 ...
範囲外：...（理由）

**3. 方法**
ツールとバージョン：...
チェックリスト：<リンク>
深刻度モデル：CVSS v4.0 定性スケール + Informational
レビュー中のAI利用：あり/なし、用途 ...

**4. 深刻度テーブル**
| ID | 指摘 | カテゴリー（OWASP Top 10:2025） | 深刻度 | 状態 |

**5. 指摘事項**
F-01 <タイトル>
深刻度：... 発生可能性：... 影響：...
場所：<ファイル:行>、他に ...
説明：...
証拠（再現可能）：...
なぜ起きたと考えられるか：...
修正：手順1、手順2 ...
参考：...

**6. 是正計画**
| 順序 | 指摘 | 担当者 | 目標日 | 検証 |

**7. 承認**
監査者：... 受理者：... 日付：...
再テストの範囲：... 有効なコミット：...

ホストされているコード監査チェックリストのテンプレートはレビュー側の相棒です。セクション5に書くものが手元にできる前に、順に確認していくリストです。

レポートを作る5つのステップ

始める前に範囲を書面で確定する。 コミットハッシュ、環境、除外事項。クライアントに送り、返答をもらいます。レポートのすべてはここを参照します。
自動のパスを先に走らせ、トリアージする。 SAST、依存関係監査、シークレットスキャン。返ってくるものの大半はノイズです。レポートには手作業で確認したものだけを載せ、スキャナーの出力は付録に回します。
チェックリストに沿って手動レビューをする。 認証、すべてのルートの認可、入力処理、決済とwebhook、データのエクスポートと削除、バックグラウンドジョブ。AI生成コードなら、クライアントが持っていればプロンプト、テンプレート、ルールファイルも読みます。見つかるパターンの説明になります。
コードだけでなく要件も監査する。 PRDや元のブリーフを取り出し、要件を1つずつ列挙して、実装済み・一部・未実装を付けます。生成されたコードベースはハッピーパスは完成していて、プロンプトが触れなかったものはすべて欠けていることがよくあります。欠落は、クライアントが顧客に約束した内容に応じてInformational以上として深刻度テーブルに載せます。
指摘、次に計画、最後にサマリーを書く。 この順序で。サマリーは指摘の圧縮です。先に書くと、自分の思い込みのサマリーになります。

Atrixでの進め方

私たちはレポートをWordファイルではなくAtrixのページとして書きます。レポートと是正作業は隣り合って存在する必要があるからです。ページには7つのセクションを置き、是正計画の各行はサイクル内のイシューとして、担当者、期日、検証手順を説明欄に持たせます。エンジニアがF-01を閉じると計画が更新され、再テストは誰かの受信箱のリマインダーではなく、2つ目のイシューになります。

クライアントにはページの共有リンクを渡すので、常に最新版を読め、コメントは1つのスレッドにまとまります。バージョン履歴で、ドラフトと受理版の間に何が変わったかが分かります。案件が終わったら、Markdownエクスポートでクライアント自身が所有できるファイルを渡します。

はっきり述べておくべき限界が1つあります。AtrixのAIエージェントはコードをスキャンしません。その監査機能は要件監査であり、凍結した要件ベースラインに対して何が作られたかを照合し、カバレッジと乖離を報告します。それは上記のステップ4であり、役に立ちます。ステップ2と3、つまりスキャナーと、認証や決済の経路を人間が読む作業は、あなたのSASTツールとレビュアーの頭の中で行われます。クライアントがソフトウェアではなく私たちによる人間のコード監査を望むなら、それは製品ではなくエージェンシーの仕事です。レビューでAIが役立つ場面と誤らせる場面については、AIを使ったコード監査への私たちの考え方をご覧ください。

よくある質問

AIコード監査レポートには何を含めるべきですか？

7つのセクションです。エグゼクティブサマリー、範囲と除外事項、方法、深刻度テーブル、再現可能な証拠と修正を添えた指摘ごとの項目、担当者と期日のある是正計画、承認。AI生成コードの場合は、範囲に出自を、指摘に要件カバレッジの確認を加えます。

コード監査レポートの深刻度スケールは何を使うべきですか？

クライアントがレポートを比較できるよう、公開されたものを使います。FIRSTが公開するCVSS v4.0の定性スケールでは、9.0〜10.0がCritical、7.0〜8.9がHigh、4.0〜6.9がMedium、0.1〜3.9がLowです。テストの欠如や未実装の要件など、脆弱性ではない指摘のためにInformationalレベルを追加します。

コード監査レポートはどれくらいの長さが適切ですか？

指摘が必要とする分だけで、それ以上は不要です。小規模SaaSの2週間の監査なら、半ページのエグゼクティブサマリー、1ページの深刻度テーブル、各半ページの指摘項目が5〜20件になるのが一般的です。スキャナーの出力や生のツールログは本文ではなく付録に入れます。

クライアントには完全版を渡すべきですか、要約だけで良いですか？

両方を別の文書として渡します。完全版はクライアントのエンジニアリングリードへ。エグゼクティブサマリーと深刻度テーブルだけで再現手順のない短縮版は、買い手、投資家、監査人に転送できるものです。

AIコード監査はペネトレーションテストの代わりになりますか？

なりません。コード監査はソースを読み、ペネトレーションテストは稼働中のシステムを攻撃します。見つかるものは重なりつつも異なります。SOC 2を求める買い手の多くは直近12か月以内のペネトレーションテストを求めます。コード監査はその前に行い、テストで見つかるものを減らすためのものです。

AIコード監査は通常のコード監査と何が違いますか？

形式は同じです。重点が、間違ったアクセス制御ではなく欠けているアクセス制御、誰も選んでいない依存関係、多くのファイルに繰り返されるパターン、プロンプトに書かれていなかったため実装されなかった要件へ移ります。レポートには、コードのどれくらいが生成されたかを記し、セキュリティに加えて要件も確認すべきです。

次のステップ

セクション5を書く前に、ホストされているコード監査チェックリストを順に確認してください。そしてエージェンシーがAtrixでクライアント業務を進める方法で、レポートをページに、修正をイシューに、クライアントを共有リンクに置く運用を見てください。ページとホワイトボードでは、共同編集、バージョン履歴、Markdownエクスポートを説明しています。

出典

レポート構成と指摘の項目：OWASP Web Security Testing Guide, Reporting Structure、Lenny Zeltserのセキュリティ評価レポートテンプレート。深刻度バンド：CVSS v4.0 仕様書, FIRST、表22。カテゴリー名：OWASP Top 10:2025。検証レベル：OWASP ASVS 5.0.0、2025年5月30日公開。いずれも2026年10月に確認。

AIコード監査レポートのテンプレート：有償の監査が必ず納めるべきセクション