AIコーディングの脆弱性対策3層設計

AIが書いたコードは誰がレビューするのか

Codex・Claude Codeを使うと、数百行のコードが数秒で生成される。スピードは上がるが、脆弱性が混入するリスクも同じ速度で増える。人間が全差分を目視するのは現実的でなく、かといって本番環境に無審査で流すのは論外だ。

必要なのは「AIが書いたコードをAIが検査する」レイヤーを設計に組み込むことだ。ここでは3つのツールを組み合わせて、個人〜小中規模チームが再現できる最小構成を整理する。

deepsecでリポジトリ全体を定期スキャンする

deepsecは、Vercel LabsがApache 2.0で公開したOSSで、コーディングエージェントを脆弱性スキャナーとして動かすハーネスだ。既存の大規模リポジトリをオンデマンドで全量レビューすることに最適化されている。

セットアップは4コマンドで完了する

リポジトリルートでnpx deepsec initを実行すると.deepsec/が生成される。続けてcd .deepsec && pnpm installでインストール完了。その後、.deepsec/data/<id>/INFO.mdにプロジェクト固有の文脈（認証ヘルパー名・ミドルウェア名など）を50〜100行で記述する。ここに汎用的なカテゴリ説明を詰め込むと信号が薄まるため、CWEの一般カテゴリは書かない。

スキャン→調査→再検証の3ステップ

pnpm deepsec scanでファイルを収集し、pnpm deepsec processでAI調査を走らせる。途中でクォータ不足や中断が起きても、同じコマンドを再実行すると解析済みファイルをスキップして続きから処理する。任意でpnpm deepsec revalidateを実行すると誤検知率が下がり、最後にpnpm deepsec export --format md-dir --out ./findingsでMarkdownに出力できる。

PR差分だけを対象にするprocess --diffモードと、軽量モデルでP0/P1/P2に振り分けるtriageも用意されており、コストを抑えながら継続運用できる。

コストとセキュリティモデルに注意する

大規模コードベースのフルスキャンは、数千ドルから数万ドル規模のAPI費用になる可能性があるとドキュメントに明記されている。分散実行オプション（pnpm deepsec sandbox process --sandboxes 10 --concurrency 4）を使うとVercel SandboxのmicroVMに並列分散できるが、事前のコスト試算は欠かせない。

セキュリティ面では、deepsecはフルシェルアクセスを持つコーディングエージェントとして扱うことが求められる。サンドボックス実行時、エージェントのAPIキーはサンドボックス外から注入され、ワーカーからの外部ネットワーク送信はエージェントホストのみに制限される設計になっている。

Copilot /security-reviewでコミット前に止める

2026年7月14日にパブリックプレビューとして公開されたCopilotの/security-reviewは、作業中の変更をその場でスキャンする機能だ。Copilot Free・Pro・Business・Enterpriseすべてで利用できる。

検出対象はインジェクション脆弱性・XSS・安全でないデータ取り扱い・パストラバーサル・弱い暗号化の5カテゴリ。結果は重大度と信頼度でスコアリングされ、Copilot内でそのまま修正提案を適用できる。GitHub code scanningやDependabotとは補完関係にあり、本番到達前のローカル変更に対する軽量な最終チェックとして機能する。

deepsecがリポジトリ全量の定期スキャンに向くのに対し、/security-reviewは差分単位の即時フィードバックに向く。両者を組み合わせると、「書いた直後に止める」「週次で全体を確認する」という2段構えになる。

AIエージェントにシークレットをどう渡すか

セキュリティスキャンで脆弱性を検出しても、シークレットが平文で.envに置かれていれば意味がない。AIエージェントがローカル環境でコードを実行する際、シークレットの扱いが最大の盲点になる。

estieの木村氏が公開したdocker-valsは、docker compose upの起動時にAWS SSMや1Password・Vaultからシークレットを動的取得してコンテナへ環境変数として注入するDocker CLIプラグインだ。平文の.envファイルも手動コピペも不要になる。

compose.yamlに書くだけで動く

compose.yamlにprovider: type: valsのサービスを追加し、options.envにDB_PASSWORD=ref+awsssm:///app-dev/db_passwordのようなURIを並べる。アプリ側のサービスがdepends_on: secretsを指定すれば、起動順序の制御も自動だ。vals形式はref+<backend>://...でAWS SSM・Vault・1Passwordに対応する。

実行にはDocker Compose v5.2.0以降が必要で、Docker Desktop 4.81.0に同バージョンが含まれている。インストールはcurl -fsSL https://raw.githubusercontent.com/estie-inc/docker-vals/main/install.sh | shの1行だ。プラグイン本体はGoで200行ほどの薄い実装で、valsライブラリを内包しているため別途インストールは不要。

3ツールを組み合わせた実践設計の考え方

3つのツールはそれぞれ異なる時点で機能する。docker-valsはエージェントが動く前の「シークレット管理」、/security-reviewはコード生成直後の「差分チェック」、deepsecは定期的な「全量監査」だ。この3層をつなぐと、AIエージェントが書いたコードが本番に到達するまでの経路に検査ポイントが生まれる。

コスト面では、/security-reviewは既存のCopilotプランに含まれるため追加費用ゼロ。deepsecのフルスキャンは規模によって高額になるため、まずprocess --diffのPRモードから始め、月次でフルスキャンに切り替えるのが現実的な導入順序だ。docker-valsはGoの200行プラグインで、既存のAWS SSOセッションやopセッションをそのまま使えるため、新たな認証情報管理コストが発生しない。

導入の判断基準

AIエージェントを使って週に数百行以上のコードを生成しているなら、この3層のうち少なくとも/security-reviewとdocker-valsは今すぐ導入できる。どちらも既存フローへの変更が最小で、設定コストが低い。deepsecのフルスキャンは、リポジトリが数万行を超えてきた段階か、セキュリティ監査を外部委託するコストと比較して検討するのが適切だ。

逆に、AIエージェントを使わず人間が全差分をレビューできている規模なら、3層すべてを今すぐ揃える必要はない。ただし、エージェント活用の比率が上がるほど人間レビューのカバレッジは下がる。その転換点が来る前に設計を決めておくことが、後からの改修コストを最も下げる。

まとめ

deepsecで全量を監査し、/security-reviewで差分を即時検査し、docker-valsでシークレットを動的注入する。この3層を組み合わせることで、AIエージェントが書いたコードを人間のレビューなしに本番へ流すリスクを構造的に減らせる。まず手をつけるなら、シークレットが.envに平文で書かれているかどうかを確認し、そうであればdocker-valsの導入を最初の一手にするとよい。