AI生成コードをリリース前に監査する方法：3人チームのための5ステップ

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

AIが書いたコードは、人が書いたコードとは違うパターンで壊れます。要件を誤解した人は、たいてい痕跡を残します。コメント、チャットでの質問、妙な変数名などです。エージェントは自信に満ちた整形済みのコードを生成し、それはコンパイルが通り、自分で書いたテストにも合格し、それでも間違ったことをしている場合があります。

2026年10月時点で、問題を示す数字が2つあります。

• Veracodeの「2025 GenAI Code Security Report」（2025年7月30日公開）は、100を超える大規模言語モデルに80件のコーディング課題を解かせ、生成コードの45%にセキュリティ脆弱性が混入していたと報告しました。関連する課題のうち、クロスサイトスクリプティングへの対策に失敗したのが86%、ログインジェクションが88%で、Javaの失敗率は70%を超えました。
• Stack Overflowの「2025 Developer Survey」（回答者49,000人超、2025年7月29日公開）では、開発者の80%がAIツールを使う一方、その正確さへの信頼は29%まで下がりました。最大の不満として45%が挙げたのは「ほぼ正しいが完全ではないAIの解決策」で、66%が「ほぼ正しい」AIコードの修正に以前より時間を使っていると答えています。

したがって監査すべき失敗モードは2つです。スコープのずれ（頼んだものと違うものを作った）と、静かな不安全さ（頼んだものを、情報が漏れる形で作った）です。プルリクエストの差分レビューはどちらも確実には捉えられません。レビュアーはエージェントが見せることにしたコードを、うろ覚えの要件と照らして読んでいるからです。

ステップ1：要件ベースラインを凍結する

チャットの記録にしか存在しない要件に対してコードを監査することはできません。監査の前に、コードがやるべきだったことを短い宣言文の番号付きリストとして書き出し、凍結します。

良いベースラインの行はこのようなものです。

• R-07 未ログインの訪問者が /app/* を開くと /sign-in にリダイレクトされ、ログイン後に元のURLへ戻される。
• R-12 請求書を支払済みにできるのはワークスペースのオーナーまたは管理者のみ。
• R-15 Stripeのwebhookペイロードは署名が検証できない限り拒否される。

悪い行は「認証をきちんと扱う」です。動いているプロダクトを見てその行が満たされているか判断できないなら、できるようになるまで書き直してください。

CursorやClaude Codeで1週間かけて作った機能なら、ベースラインは通常15〜40行です。PRD、課題の説明、エージェントに渡したプロンプトから拾います。そして編集をやめます。要件ベースラインの意義は固定された参照点であることで、次のステップが交渉ではなく比較になるためです。

Atrixでは、Develop実行がブリーフを要件リストに変え、それをプロダクトのベースラインとして凍結します。Atrixを使っていなくても、番号付きのMarkdownファイルをリポジトリにコミットすれば同じ役割を果たします。大事なのは、書かれていて、番号が振られ、日付があることです。

ステップ2：実装とベースラインの差分を取る

次に、ベースラインを1行ずつ辿り、各要件を3つの状態のいずれかに分類します。

これはコードだけでなく、動いているプロダクトを開いて行ってください。エージェントは requireAdmin という関数を書いておいて、あるルートでだけそれを呼ばない、ということが得意です。

特に探すべきものが3つあります。

1. 通すために書き換えられたテスト。 差分の中で、変更されたアサーション、削除されたテストケース、新しい skip や only マーカーを探します。私たちの経験では、これがエージェントが失敗タスクを閉じる最も多いやり方です。
2. エージェントが再解釈した要件。 「ログイン後にリダイレクト」が「ダッシュボードにリダイレクト」になり、「オーナーまたは管理者」が「ログイン済みの任意のメンバー」になります。コードはきれいで、間違っています。
3. 誰も頼んでいない追加の挙動。 エージェントは機能を足します。そのひとつひとつが未レビューの攻撃面です。ベースラインに加えてレビューするか、削除するかのどちらかです。

ここがAtrixが自動化する部分です。Atrix AIの要件監査は、凍結したベースラインをチームがワークスペースで計画・構築したものと比較し、要件ごとのカバー率とずれを報告します。限界をはっきり言っておきます。監査するのは要件であって、ソースコードではありません。リポジトリは読まず、静的解析も実行せず、脆弱性も見つけません。答えるのは「言ったとおりのものを作ったか」というステップ2の問いであり、ステップ3〜5には関与しません。

ステップ3：リポジトリ全体に静的解析を実行する

静的アプリケーションセキュリティテスト（SAST）は最も安いステップで、かつチームが飛ばしがちなステップです。差分だけでなくリポジトリ全体に実行してください。エージェントの変更が、以前は安全だったコードに新しい経路で到達できるようにしてしまうことがあるからです。

2026年10月時点で、小さなチームの大半は次の3つのツールでカバーできます。

価格は2026年10月に各ベンダーの料金ページで確認したもので、頻繁に変わります。

スキャンはCIで実行し、すべてのプルリクエストで走るようにし、初回の結果は手作業で仕分けします。初回はノイズが多いと想定してください。目的はクリーンな基準状態に到達し、次にエージェントが書いた変更で新しい検出だけが表示されるようにすることです。

SASTがAI生成コードで捉えられるもの：インジェクション（SQL、コマンド、ログ）、出力エンコードの欠如、ハードコードされたシークレット、安全でない乱数、既知の脆弱性を持つ依存関係。捉えられないもの：あるルートでの認可チェックの欠如、署名のないペイロードを信頼するwebhookハンドラー、クライアント側で計算された価格。これらはステップ4の対象です。

ステップ4：認証と決済の経路を人の目で確認する

ベースラインを開いたまま、人が最初から最後まで読みます。

1. データを変更するすべてのルート。 それぞれについて、呼び出し元が誰で何を許可されているかを確認している行を探します。その行が見つからなければ、存在しません。
2. セッションとトークンの扱い。 セッションがどこで作られ、どれだけ生存し、サインアウトとパスワード変更でどう無効化されるか。
3. webhookとコールバック。 パース前の署名検証。リトライ時の冪等性。
4. お金。 価格、合計、割引がどこで計算されるか。ブラウザで計算されサーバーがそれを信じているものはすべて指摘事項です。
5. シークレットと設定。 差分からAPIキー、接続文字列、トークンをgrepします。エージェントは人より頻繁にサンプルキーをコードに貼り付けます。

機能規模の変更なら2〜4時間を見込んでください。レビュアーはエージェントに指示した本人であってはいけません。書き手が自分の原稿を校正すべきでないのと同じ理由です。

GitHub連携を使っていれば、このレビューから起票した課題は要件とプルリクエストにリンクされるので、「R-12 部分的：管理者は支払済みにできるがオーナーはできない」が担当者付きで追跡される項目になり、流れて消えるコメントにはなりません。

ステップ5：指摘事項を書き出し、順番に直す

各指摘を4つのフィールドを持つ課題として記録します。対応する要件、深刻度、ファイルと行、修正内容です。この規模なら深刻度は単純です。

• Critical： 未認証またはテナント越えのデータアクセス、あるいは金額の計算ミス。リリース前に修正。
• High： ログイン済みユーザーでなければ悪用できないセキュリティ欠陥。同じスプリント内で修正。
• Medium： ユーザーが遭遇するエッジケースの欠落。スケジュールに入れる。
• Low： スタイル、デッドコード、重複ロジック。まとめて対応。

CriticalとHighの項目を現在のサイクルに入れ、クローズしたら監査をもう一度実行します。2回目はベースラインとスキャンが既にあるので速く、新しい作業は変更された行を読み直すことだけです。

CursorやClaude Codeでこれを楽にするツール

エージェントが作業中にベースラインを目の前に置いていると、監査は安くなります。私たちがやっていることが3つあります。

• プロンプトだけでなくベースラインをエージェントに渡す。 Cursor連携またはClaude連携を使うと、エージェントはAtrixのMCPサーバー経由で要件ページと課題を読めるので、実装の基準にする番号付きリストが、監査の基準にするリストと同じものになります。
• プルリクエストで対応関係を求める。 エージェントの指示に「この変更が実装する要件IDを列挙する」というルールを入れると、ステップ2が探索ではなく確認になります。
• PRを開く前にエージェントにSASTを実行させる。 Semgrepはローカルで数秒で動きます。エージェントが検出結果を見れば、大半は自分で直します。

これらはステップ3と4の代わりにはなりません。短くするだけです。

3人チームなら、エージェントで作った機能の最初の完全な監査には1日ほどかかります。2回目は、ベースラインのプロセスとスキャナーが整っているので半分で済みます。

よくある質問

要件監査とコード監査の違いは何ですか？

要件監査は、作ったものが作るはずだったもののリストと一致しているかを確認します。要件ごとのカバー率とずれです。コード監査は、コード自体が正しく、安全で、保守可能かを確認します。静的解析、依存関係のレビュー、機微な経路の人による読解です。AI生成コードには両方が必要で、それぞれ上記のステップ2とステップ3〜4にあたります。Atrix AIは前者を行います。後者はSASTと人です。Atrixのエージェンシー部門であるAtrix Digitalは、人によるコード監査をサービスとして提供しています。

AIツールでAI生成コードを監査できますか？

部分的には。SASTツールの中には仕分けにモデルを使うものもあり、パターンレベルの欠陥はよく捉えます。最初のモデルの出力を2つ目のモデルがレビューすれば、ロジックの誤りもいくらか見つかりますが、認可やビジネスルールに関する盲点は最初のモデルと共有しています。2026年10月時点で、私たちはAIレビューをステップ4の人のレビューの前段フィルターとして扱っており、代替とは見なしていません。

自分が作っていない「vibe coding」のアプリはどう監査しますか？

それでもステップ1から始めます。プロダクト自体を画面ごとに見て、アプリがやるべきことを書き出し、番号を振ります。次にリポジトリ全体にSASTを実行し、データやお金を変更するすべてのルートを読みます。要件が一度も書かれていないので、自分で作ったコードよりベースラインに時間がかかると見込んでください。

どのくらいの頻度で監査すべきですか？

機能ごとに、有料ユーザーに届く前に行い、CriticalとHighの指摘がクローズしたらもう一度行います。毎週リリースするチームなら、毎週短い監査、サイクルごとに完全な監査です。

小さなチームはどのSASTツールを選ぶべきですか？

SemgrepのFree Editionは2026年10月時点で最大10人のコントリビューターと10個のプライベートリポジトリをカバーし、ローカルでもCIでも動き、最も始めやすい選択です。コードがGitHubにあり、既にCode Securityを支払っているなら、CodeQLのプルリクエスト統合が最も摩擦の少ない選択肢です。どれかひとつを選び、すべてのプルリクエストで実行してください。どれを選ぶかより、実行することのほうが重要です。

次のステップ

まずベースラインを書いてください。Atrix AIの要件監査はすべてのプランでそれに対して実行でき、以前の記事AIを使ったコード監査では、小さなチームに完全な監査が必要なときと軽い監査で十分なときを解説しています。

出典

Veracode 2025 GenAI Code Security Report プレスリリース、2025年7月30日。Stack Overflow 2025 Developer Survey 結果、2025年7月29日。価格は2026年10月にSemgrepの料金ページ、GitHub Advanced Security、GitHubの課金ドキュメント、Snykのプランで確認しました。