AIによるコード監査：何を確認し、いつ実施すべきか

問いは1つではなく2つ

監査は2つの異なる問いに答えるものですが、多くのツールはそのうち1つしか問いません。

1. 合意したものを作ったか？ プロダクトには、どこかに書き留められた要件があります。それらはすべて実装されているでしょうか。いつの間にか変わったものはないでしょうか。誰も判断していないのに削られたものはないでしょうか。
2. 顧客に出しても安全か？ あるアカウントから別のアカウントのデータが見えないか。リポジトリにシークレットが含まれていないか。決済のリトライで二重請求が起きないか。

注目を集めやすいのは2つ目の問いです。セキュリティの不備は損失が大きく、世間の目にも触れるからです。1つ目の問いは見落とされがちですが、小規模なプロダクトでは、想定外の問題の多くがここに潜んでいます。顧客に約束したのに作られなかった機能や、成果物が「合格」するように承認後に書き換えられた要件などです。

1つ目の問いに必要なもの

存在しない要件や、誰もテストできない要件に照らして成果物を確認することはできません。そのため、監査の前半は、ずっと前に行われた作業に依存します。

• キー付きの要件：REQ-014 のように、決して変わらないキーを持たせ、作業をそこまでさかのぼって追跡できるようにします。
• 受け入れ基準：それぞれの要件について、稼働中のプロダクトでどのように確認するかを定めます。
• 凍結されたバージョン：合意した内容を凍結したものです。承認後も要件を編集できるなら、「要件」に対する監査は、その時点で要件に書かれている内容に対する監査にすぎません。

これらがそろえば、確認作業はシンプルです。すべてのMust要件に完了した作業がひも付いているか。各受け入れチェックが本番のプロダクトで合格するか。承認後に変更された要件は、変更前と変更後の文言とともにフラグが立てられているか。削除された要件は、消されるのではなく意思決定として記録されているか。

2つ目の問いに必要なもの

小規模なWebアプリやモバイルアプリであれば、実践的なセキュリティと信頼性のチェックは次の6つの領域をカバーします。

• アクセス制御。 非公開データを扱うすべてのルートでセッションを確認していること。管理者向けの操作では、サインインしているかだけでなくロールを確認していること。URL内のIDを書き換えても、別のアカウントのレコードにアクセスできないこと。小規模なプロダクトで見つかる深刻な指摘の大半はここにあります。
• シークレット。 リポジトリやその履歴にキーやトークンが含まれていないこと。公開用の環境変数を通じてサーバー側のシークレットがブラウザに露出していないこと。漏洩した認証情報はローテーション済みであること。
• 依存関係。 npm audit や OSV などの実際のアドバイザリデータベースで既知の脆弱性情報を確認し、アドバイザリIDを記録していること。
• 入力の取り扱い。 パラメータ化クエリを使うこと、ユーザー入力に対して動的なコード実行をしないこと、出力をエスケープすること、アップロードを検証すること、ユーザーが指定したURLへのサーバー側からのリクエストを制限すること。
• お金の流れ。 決済処理が冪等であること、Webhookの署名を検証していること、金額をサーバー側で計算していること、同時リクエストでクレジットや返金が二重に使われないこと。
• 運用。 エラーが誰かの見ているモニタリングに届くこと、バックアップが存在し復元を試したことがあること、マイグレーションがそれを必要とするコードより先に適用されていること。

そして、忘れがちなもう1つのチェックがあります。本番で公開されていることです。チーム外の誰もアクセスできないものの監査は、完了したとはいえません。

AIが役立つところ

AIは監査において、特定の場面で確かに役立ちます。

• 大規模なコードベースを素早く読み、どこを見るべきかを示すこと。すべてのルートハンドラ、価格を計算しているすべての箇所、URLを取得しているすべての呼び出しなどです。
• トリアージ。 長い指摘リストを、金銭的損失やデータ露出につながるものから順に並べること。
• すでに確認された指摘について、再現手順と修正案を書くこと。
• 修正を担当する人に、その人のコードに即して指摘を説明すること。

AIが邪魔になるところ

失敗パターンは、モデルの意見だけで構成された監査です。「このコードは安全ですか？」と尋ねられたモデルは、自信に満ちたリストを出してきます。その一部は正しく、一部はもっともらしいが間違っており、しかもすべてが同じ体裁で書かれています。検証できない指摘は、指摘がないよりも悪いものです。追いかけるのに時間がかかるうえ、チームにレポートを無視する癖をつけてしまいます。

そのため、AIを活用した監査のルールはシンプルです。

• 証拠がなければ、なかったことと同じ。 すべての指摘には、場所（ファイルと行、またはルート）、問題を示す証拠、再現手順が必要です。証拠がなければ、指摘として扱いません。
• 指摘は印象ではなくチェックから生まれる。 依存関係のアドバイザリは記憶ではなくアドバイザリデータベースから得ます。アクセス制御の指摘は、実際にIDを書き換えて何が起きるかを確認して得ます。
• 一貫した識別子。 各指摘にフィンガープリントを付け、監査を再実行したときに、新たな長文を生み出すのではなく、何が修正されたかがわかるようにします。
• 気分ではなく判定を。 未解決のCriticalやHighの指摘がなく、プロダクトが本番公開されていれば監査は合格です。そうでなければ、もう一度繰り返します。

監査が必要なタイミング

小規模なチームに継続的な監査プログラムは必要ありません。必要なのは、答えが重要になるタイミングでの監査です。

• 一般公開やアプリストアへの申請の前。 アクセス制御の穴を低コストで見つけられる最後のタイミングです。
• 外部に依頼した作業が戻ってきたとき。 業務委託先、制作会社、あるいはコーディングエージェントが、あなたの要件に沿って何かを作った場合です。まさに「合意したものを受け取れたか」に答えが必要な場面です。
• デューデリジェンスの前、または他の人のコードベースを引き継ぐとき。
• 認証、決済、データアクセスに大きな変更を加えた後。

これらのタイミングの合間であれば、もっと軽い習慣で十分です。要件にキーを付けておき、コミットやプルリクエストでそのキーを参照し、お金の流れに変更があるたびに再確認しましょう。

Atrix AIが担う範囲と担わない範囲

範囲をはっきりさせておきます。Atrix AIはコードをスキャンしたり解析したりしません。上記のセキュリティと信頼性のチェックは、手作業で、あるいは紹介したツールを使って、または信頼できるレビュアーに依頼して、ご自身で実施していただくものです。Atrix AIが担うのは、監査のうちワークスペースが誠実に答えられる部分と、それ以外の部分にまつわる記録管理です。

1つ目の問い：合意したものを作ったか？ Atrix AIでは、要件を承認し、番号付きのベースラインとして凍結します。ベースラインには、各要件の正確な文言と、PRDおよび元のドキュメントが、その時点の状態で保存されます。そのうえで要件監査が、ベースライン内の要件ごとに、作業が存在するか、進行中か、完了しているかを示し、凍結後に文言が変わった要件や削除された要件、凍結後に編集されたドキュメントにフラグを立てます。ベースラインに含まれる要件は削除できず、Won't とマークすることしかできないため、何かが黙って消えることはありません。すべての状態は、モデルの意見ではなくあなたの記録から算出されます。

トレーサビリティ。 要件には恒久的なキーが付きます。コーディングエージェントに開発を引き継ぐ際、Develop モードのハンドオーバーバンドルにはドキュメントとキーが含まれ、コミットやプルリクエストでキーを参照するよう求めます。これにより、監査担当者は作業を、それが何のためのものだったかまでさかのぼって追跡できます。AIエージェントは要件の下書きと作業の計画を行い、何を合意とするかは人が決めます。

指摘事項の管理。 監査で見つかった各指摘は、影響を受ける要件と同じプロジェクト内に、優先度付きのイシューとして記録できます。また、作業がひも付いていない承認済みの要件をイシューに分解することもできます。監査の後半はAtrixの外で行われますが、その結果をスプレッドシートで管理する必要はありません。

チェックそのものには、無料コード監査チェックリストをご活用ください。各行に重大度、場所、証拠、再現手順、修正案を記録できる指摘ログも含まれています。

まとめ

役に立つコード監査は、まず合意済みでテスト可能な要件に照らして成果物を確認し、次にそれが安全で本番公開されていることを確認します。AIは、読む・順位付けする・説明するといった作業を速くしてくれます。しかし、AIだけを根拠に指摘を出してはいけません。検証可能な要件から始めれば、監査の残りの部分はずっと楽になります。