2026年版 AI生成コード監査チェックリスト：6つのセクション、印刷可、無料テンプレート付き

AI生成コードに専用の監査が必要な理由

Cursor、Claude Code、Copilot、Codexが出力するコードは完成しているように見えます。コンパイルは通り、モデルが書いたテストはパスし、プルリクエストの説明も読みやすい。MetaCTOが2026年7月に公開したAI生成コードのレビュー基準に関するガイドは、これを「レビューの罠」と呼びます。要件を取りこぼし、存在しないAPIを作り、認可チェックを飛ばしたもっともらしいコードが、スタイルしか見ていないレビューを通り抜けてしまうのです。

数字はベンダーの誇張ではありません。Veracodeの2025年GenAI Code Securityレポートは、厳選した80件のコーディング課題を100以上の言語モデルに解かせ、45パーセントのケースでセキュリティ脆弱性が混入したと報告しました。Javaの失敗率は70パーセント超、Python・C#・JavaScriptは38〜45パーセントでした。クロスサイトスクリプティングは86パーセント、ログインジェクションは88パーセントのケースで対策されていませんでした。

依存関係はより新しい問題です。Spracklenらによる USENIX Security 2025 の研究は、16モデルで約57万6,000件の生成コードを検証し、推奨されたパッケージの19.7パーセントが存在しなかったと報告しています。攻撃者は今やその架空の名前を登録しており、これはスロップスクワッティングと呼ばれます。従来のレビューではパッケージが実在するかどうかを確認しませんでした。最近まで、それは常に実在していたからです。

つまりAIコード監査は、通常のレビューを念入りにやることではありません。人間のコードには存在しなかったチェックを加え、もっともらしい間違いが最も高くつく場所に人の労力を移すものです。

2026年の3つの推進要因

「バイブコーディング」で作られたMVPが顧客に届き始めている。 創業者がエージェント主体で作った製品を、しばしば一人で数週間のうちに出荷しています。監査は、誰かがそのコードを全体として読む最初の機会になります。こうしたコードベースの調査結果を公開している企業は、同じパターンを報告しています。UIでは守られているがAPIでは守られていない管理画面、レート制限の欠如、行レベルセキュリティの不在や誤設定、リポジトリ内のシークレットです。

SOC 2のデューデリジェンス。 変更管理の基準（AICPA Trust Services CriteriaのCC8）において監査人が問うのは、重要な変更がすべて本番前にレビュー・承認・テストされたかどうかです。SOC 2もISO 27001も「コードレビュー」を統制として名指ししていませんが、どちらも変更管理が実施され、検証可能であることを求めます。エージェントが書き、プロンプトを打った本人が承認したプルリクエストは弱い答えです。レビュー担当者の名前が入った文書化された監査は強い答えです。

EU AI法。 汎用AIモデルの義務は2025年8月2日から適用され、法そのものは2026年8月2日に広く適用開始となりました。AIオムニバス（規則(EU) 2026/1744、2026年7月27日発効）は、附属書IIIの単体ハイリスク義務を2027年12月2日に、組み込み製品の義務を2028年8月2日に延期しました。雇用、教育、与信、重要インフラ向けに販売しているなら、「エージェントが書いたので確認していない」は技術文書として通用しません。

チェックリスト：セクション別

印刷するか、コード監査チェックリストのテンプレートをワークスペースにコピーしてください。各項目にチェックを入れ、証拠（スキャン結果、テスト、コミットへのリンク）を記録し、確認した人の名前を書きます。

1. インベントリとアーキテクチャ図

• 対象範囲のリポジトリ、サービス、定期ジョブ、インフラ定義をすべて列挙する。
• どのファイルやモジュールがAI生成、AI補助、手書きかを記す。git blameとコミットメッセージでたいてい分かる。チームが把握していないなら、その旨を報告書に書く。
• リクエストの経路を描く：エントリーポイント、認証層、データストア、外部呼び出し、バックグラウンドワーカー。
• ランタイムのバージョンとデプロイ先を記録する。
• 個人データ、決済データ、認証情報が保存または通過する場所をすべて列挙する。

このセクションがなければ、監査の残りは無作為なサンプリングになります。

2. 静的解析（SAST）とシークレットスキャン

• コードベース全体にSASTツール（Semgrep、CodeQL、SonarQube、または言語固有のもの）を実行し、生の出力を保存する。
• シークレットスキャナー（gitleaks、trufflehog、ホスティング側の組み込みスキャン）をHEADだけでなくgit履歴全体に実行する。
• 検出結果を真陽性、偽陽性、受容リスクに分類し、それぞれ一行の理由を添える。
• モデルが苦手とする弱点を手動で確認する：すべてのテンプレートとAPIレスポンスの出力エンコーディング（XSS）、ログ文に到達するユーザー入力（ログインジェクション）。
• ビルドを通すためにエージェントがCIの型チェックやlintルールを緩めていないことを確認する。

3. 認証、認可、入力検証

• 保護されたルートはすべてUIだけでなくサーバー側で本人確認を行う。
• オブジェクト単位のアクセス（IDによる）はすべて、呼び出し元がそのオブジェクトを所有または閲覧可能かを確認する。
• 管理機能はロールで制限され、ロールはリクエストボディではなくセッションから読む。
• セッションとトークンは期限切れになり、権限変更時にローテーションされ、HttpOnlyとSecureフラグ付きで保存される。
• パスワードは現行のハッシュ（Argon2id、scrypt、bcrypt）を使い、独自暗号は使わない。
• すべての入力は境界でスキーマ（Zod、Pydantic、JSON Schema）により検証され、データベースアクセスはパラメータ化されている。
• サインイン、サインアップ、パスワードリセット、メールやSMSを送るエンドポイントにレート制限がある。
• 状態を変更するブラウザリクエストにCSRF対策がある。

バイブコーディングで作られたアプリが最も頻繁に失敗するのがここで、モデルの出力が最も説得力を持つのもここです。これらのファイルは一行ずつ読んでください。

4. 依存関係の監査

• ロックファイル内のすべてのパッケージが、その正確な名前で公開レジストリに存在し、もっともらしい履歴（公開からの期間、メンテナー、ダウンロード数）を持つ。
• AIツールが初めて追加したパッケージは、人がレジストリのページで確認済みである。
• ソフトウェア構成分析ツール（npm audit、pip-audit、OSV-Scanner、Snyk、Dependabot）を実行し、未解決のアドバイザリを記録する。
• ライセンスが配布形態と両立する（クローズドソースのSaaSにおけるGPLに注意）。
• バージョンが固定され、ロックファイルがコミットされている。

5. ビジネスロジックと要件のテスト

• コードが満たすべきだった要件を書き出す。プロンプトの中にしか存在しないなら、プロンプト履歴から復元してベースラインとして凍結する。
• 各要件について、それを証明するテストまたは手動確認を挙げる。欠けているものは指摘事項になる。
• モデルが飛ばしがちなエッジケースをテストする：空のリスト、二重送信、同時更新、タイムゾーン、通貨の端数処理、複数ステップ処理の部分失敗。
• エージェントが書いたテストが、関数が例外なく返ることではなく振る舞いを検証していることを確認する。
• クリーンな環境でアプリケーションをエンドツーエンドで動かし、お金の流れを追う：支払い、受領、返金、請求。

6. シニアレビューと署名

• コードを書いていないシニアエンジニアが、レッドリスト（認証、決済、個人データ、マイグレーション、公開API、インフラ）のすべてのファイルを読む。
• 各指摘事項に重大度、証拠、担当者、期限がある。
• レビュー担当者は、自分で確認した箇所とサンプリングした箇所を記録する。
• 名前のある人が、日付と監査対象のコミットハッシュとともに報告書に署名する。

使用する重大度スケール

スケールは短く保ちます。全員が使う4段階は、誰も合意しない10段階に勝ります。

公開されているフレームワークの比較

2026年10月時点で、最も引用されている公開済みの構成は次の2つです。

当社の6セクションはSolGuruzの順序に従い、MetaCTOから「コードのプロンプトを打った人が唯一の承認者であってはならない」というルールを借りています。

5ステップで監査を進める

1. 範囲を決めて凍結する。 リポジトリ、コミットハッシュ、要件ベースラインを合意する。報告書に署名するまで、監査対象ブランチには何もマージしない。
2. まず自動化する。 初日にSAST、シークレットスキャン、依存関係スキャンを実行し、人は発見ではなく分類に時間を使う。
3. レッドリストを読む。 認証、決済、個人データ、マイグレーション、公開API、インフラ。書いていない人が一行ずつ読む。
4. 要件をテストする。 凍結した各要件をテストまたは手動確認に対応づける。欠けているものを記録する。
5. 書く、署名する、追跡する。 報告書は1つ、重大度テーブルは1つ、指摘事項ごとに担当者1人、修正が完了するまで見えるトラッカー1つ。

2万行のコードベースを持つ3人チームなら、1営業週間を見込みます。ステップ1と2に1日、ステップ3に2〜3日、ステップ4と5にそれぞれ1日です。

Atrixが役立つところ、役立たないところ

Atrix AIはソースコードをスキャンせず、静的解析も実行せず、脆弱性も見つけません。エージェントが行うのは要件監査です。PRDページまたはDevelop実行から要件ベースラインを凍結すると、監査はどの要件が計画済みまたは出荷済みの作業でカバーされ、どれが逸脱し、どれに担当者がいないかを報告します。これはこのチェックリストのセクション5に対応し、それ以外には対応しません。コード監査の機能ページにその境界が明記されています。

人によるコード監査は別のサービスです。製品の背後にあるエージェンシーのAtrix Digitalは、人がコードを読むコード監査を行っており、セクション1〜4と6をカバーします。Atrixの中では、指摘事項はサイクル内のイシューになり、報告書はクライアント向け共有リンク付きのページとして保管され、チェックリストのテンプレートはチェックを入れていくページデータベースになります。これは当社自身の監査で使っている構成です。

よくある質問

AIコード監査とは何ですか？

主にAIツールが書いたコードの構造化されたレビューで、インベントリ、静的解析、認証と入力検証、依存関係、ビジネスロジックのテスト、シニアレビューを含み、指摘事項は重大度で分類され、名前のあるレビュー担当者が署名します。存在しないパッケージと、モデルが黙って落とした要件のチェックが加わります。

AI生成コードの監査は通常のコードレビューとどう違いますか？

3点が変わります。依存関係が実在し、名乗る通りのものかを検証すること。モデルがわずかに違う問題を解いている可能性があるため、プロンプトから要件を復元してそれに対してテストすること。そして、Veracodeの2025年のテストでモデルが最も失敗しやすいと示された認証、決済、データ経路に人の注意を移すことです。

AIコード監査にはどれくらい時間がかかりますか？

1〜2サービスで2万行未満のコードベースなら、シニアエンジニア1人で約1営業週間です。より大きなコードベースでは、総行数ではなくレッドリストの大きさに応じて増えます。

SOC 2のために監査は必要ですか？

SOC 2はその名前の監査を要求しませんが、変更管理の基準は、変更が本番前に作成者以外の人によってレビュー・承認・テストされた証拠を求めます。署名済みの監査報告書と強制されたプルリクエストレビューは強い証拠です。一人の創業者が自分のエージェントの出力を承認するのは証拠になりません。

EU AI法はAI生成コードの監査を義務づけていますか？

直接には義務づけていません。この法律はAIシステムをその用途で規制するものであり、コードの書き方で規制するものではありません。ただし製品が附属書IIIのハイリスクシステムに当たるなら、2027年12月2日から適用される技術文書とリスク管理の義務は、コードがどのようにレビュー・テストされたかを示せるほうがはるかに満たしやすくなります。

Atrix AIは私のコードを監査できますか？

できません。Atrix AIは凍結したベースラインに対して要件を監査するもので、ソースコードを読んだりスキャンしたりはしません。人によるコード監査にはエージェンシーAtrix Digitalのサービスを使い、指摘事項はAtrixでイシューとして追跡してください。

次のステップ

コード監査チェックリストのテンプレートをページにコピーし、要件ベースラインを凍結して、6つのセクションを順番に進めてください。自分で書いていないコードベースを監査するなら、関連記事AI生成コードを出荷前に監査する方法でベースラインのステップをより詳しく解説しています。

出典

2026年10月に確認した事実：Veracode 2025 GenAI Code Securityレポートのプレスリリース、MetaCTO, Establishing Code Review Standards for AI-Generated Code、SolGuruz, How to Audit AI-Generated Code in 2026、欧州委員会、AI法の規制枠組みとスケジュール、Spracklenらによるパッケージ・ハルシネーション研究（Xygeniによる要約）、AICPA Trust Services Criteria。