AIコーディングエージェントが書いたコードをセキュリティレビューする方法

AIコーディングエージェントは高速であり、その速さは諸刃の剣です。数分のうちに動作する機能を喜んで生成する一方で——同じように喜んで、文字列連結でSQLクエリを組み立てたり、シークレットをログに出力したり、認可チェックを飛ばしたりします。コードは動き、テストは通り、そして脆弱性がそのまま出荷されます。タイピングをしているのがエージェントであっても、セキュリティレビューは省略できるものではありません。それは依然としてあなたが担う部分なのです。

本番環境に到達する前にAI生成コードをレビューするための、実践的でツールに依存しないワークフローを紹介します。

何を探すべきかを知る

現実世界の脆弱性の大半は、ひと握りのパターンに集約されます。あなた（またはツール）がエージェントの出力をレビューするときは、まず次の点をスキャンしましょう。

• インジェクション（Injection） — パラメータ化クエリを使わず、文字列を連結して組み立てられたSQL、シェル、テンプレートの入力。
• クロスサイトスクリプティング（XSS） — エスケープなしでHTMLにレンダリングされるユーザー入力。
• 壊れた認証／認可 — あなたが誰かはチェックするがあなたに権限があるかはチェックしないエンドポイント。レコードに対する所有権チェックの欠落。
• 安全でないデータの取り扱い — コード内のシークレット、ログ内の認証情報、エラーメッセージ内の機微なデータ。
• 脆弱な依存関係 — エージェントが追加した、既知のCVEを持つパッケージ。

これらはOWASP Top 10とほぼ対応しており、Anthropicが自社の自動セキュリティレビューが探すと述べているカテゴリそのものです。この短いリストを頭に入れておくだけで、手動レビューははるかに効果的になります。

エージェント自身にレビューさせる——新しいコンテキストで

コードを書いたのと同じモデルがそれをレビューできますが、同じ流れの中でやってはいけません。ある機能を動かすためについ今しがた20ターンを費やしたエージェントは、それを擁護しようという構えになっています。新しいセッションを開始し、たった一つの仕事を与えましょう——欠陥を見つけることです。

うまく機能するプロンプト：

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

重要なのは「concrete exploit scenario（具体的な悪用シナリオ）」という一節です。これはモデルに対し、「入力を検証することを検討してください」といった曖昧な決まり文句を並べるのではなく、問題が本物であることを証明するよう強制します。

組み込みのツールに手を伸ばす

Claude Codeを使っているなら、専用の/security-reviewコマンドがあります。これはあなたの変更を一般的な脆弱性パターンについて分析し、あなたが承認すれば修正を直接適用します。有料のProおよびMaxプラン、そして従量課金のAPIアカウントで利用できます。

継続的なカバレッジのために、AnthropicはオープンソースのGitHub Actionも提供しています。これはすべてのプルリクエストで実行され、懸念のある行そのものにインラインコメントを投稿します。これをリポジトリに組み込むと、おおよそ次のようになります。

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

これで、人間が開いたものであれエージェントが開いたものであれ、すべてのPRが誰かがmergeを押す前にセキュリティチェックを受けます。Cursor、Copilot、その他のアシスタントも同等のレビュー統合を提供しており、原理はツールを問わず同じです。

決定論的なチェックを省かない

AIレビューは強力な追加要素であって、決して疲れない退屈なツール群の代替ではありません。

• 依存関係スキャン — npm audit、pip-audit、またはDependabotは、LLMが名前で認識しない既知の脆弱なパッケージを捕まえます。
• シークレットスキャン — gitleaksのようなツールやGitHubのpush protectionは、漏洩した鍵がそもそも履歴に入り込むのを防ぎます。
• 静的解析（SAST） — リンターやSemgrepのようなツールは、コードベース全体にわたってルールを一貫して適用します。

ロジックとコンテキストについて推論するにはAIを使い——「ここで認証済みユーザーは別のユーザーのレコードを読めてしまうか？」——機械的でパターンマッチ可能な事柄には決定論的なスキャナーを使いましょう。両者は互いの死角を補い合います。

具体的な例

あなたのエージェントが次のエンドポイントを生成したとします。

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

セキュリティチェックは2つの問題を指摘するはずです。すなわち、このクエリはいつ起きてもおかしくないSQLインジェクションであること（invoice_idが文字列に埋め込まれている）、そして、その請求書が本当にuserのものであるかのチェックがないこと——ログイン中のどのアカウントも、IDを推測すれば任意の請求書を読めてしまいます。修正は、パラメータ化クエリに所有権フィルターを加えることです。

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

インジェクションはスキャナーが捕まえる類のものです。欠落した認可チェックのほうは、誰か——あるいは適切なプロンプトを備えたAIレビュアー——がそのコードが何のためのものかを理解する必要がある類のものです。頭に入れておくべきは、この切り分けです。

まとめ

エージェントが生成するあらゆるdiffは、レビューされるまで信頼できないものとして扱いましょう——新しいチームメンバーの最初のプルリクエストに適用するのと同じ基準です。新しいコンテキストでのAIレビュー、自動化されたPRチェック、決定論的なスキャナーを組み合わせれば、AI支援開発の速さの大部分を、その最悪の癖を受け継ぐことなく手に入れられます。