SaaS・IT

【2026年最新】Claude Code×SAST脆弱性自動修正ガイド

SASTツールの警告をClaude Codeに渡し、検出から修正までを自動化する実践ワークフロー。Semgrep/CodeQL/Bandit連携、導入事例、失敗パターン4選。

【2026年最新】Claude Code×SAST脆弱性自動修正ガイド

結論：Claude CodeとSASTを組み合わせた脆弱性自動修正は、「検出をSAST、人間がレビューできる最小差分の作成をClaude Code、合否判定を再スキャンとテスト」に分けると実務に乗せやすくなります。

  • 要点1：SASTは検出器として使い、Claude Codeには1件ずつ原因分析、修正、テスト追加、再スキャンまでを依頼します。
  • 要点2：Claude Codeの権限モード、settings.json、hooks、非対話実行、GitHub Actions、MCPは公式ドキュメントで確認できる機能だけを使います。
  • 要点3：自動修正は自動マージではありません。秘密情報の読み取り禁止、外部送信禁止、危険コマンドのdeny、レビュー必須のルールを先に置きます。

対象読者：Claude Codeをセキュリティレビュー、SAST運用、CI改善に使いたい開発者、SRE、セキュリティ担当、EM。

今日やること：まずは既存リポジトリでSAST結果をJSONまたはSARIFに出し、Claude Codeに「1件だけ」修正計画を作らせてください。

記事区分：実装パターン解説。本記事は特定企業の実測事例ではなく、SAST運用でよく使う構成をClaude Code向けに一般化したガイドです。工数削減率や検出率のような成果数値は、環境差が大きく誤解を招きやすいため断定しません。

「SASTの指摘をClaude Codeで全部直せますか？」という質問は、Claude Code導入時によく出ます。正直に言うと、全部を一括で直す設計はおすすめしません。SASTの指摘には、本当に危険なもの、設定で抑制すべきもの、フレームワーク側で吸収済みのもの、テストを書かないと判断できないものが混ざるからです。

一方で、SASTの出力をきれいに分解し、Claude Codeに「この1件の根本原因を説明して、最小差分で直して、再発テストを追加して」と依頼すると、かなり実務的なレビュー補助になります。この記事では、Semgrep、CodeQL、npm auditのような静的解析・依存関係監査の結果を入口にして、Claude Codeで安全に自動修正へ寄せる流れを、設定例とプロンプトつきで整理します。

Claude Code×SAST自動修正でできること・できないこと

最初に境界線を引きます。Claude Codeは、コードを読み、ファイルを編集し、テストやスキャンコマンドを実行し、差分を説明するエージェントとして使えます。公式ドキュメント上も、権限ルール、権限モード、hooks、非対話実行、GitHub Actions、MCP、CLAUDE.mdによる永続指示といった仕組みが用意されています。

ただし、Claude CodeはSASTエンジンそのものではありません。脆弱性の検出責任はSASTに置き、Claude Codeには検出結果の読解、修正案の作成、コード変更、テスト追加、再スキャン補助を担当させるのが現実的です。

領域 Claude Codeに任せやすいこと 人間が握るべきこと
SAST結果の整理 JSON/SARIFの要約、該当ファイルと関数の特定、修正優先度の仮説作成 本番影響、規制影響、脆弱性受容の判断
コード修正 入力検証、エスケープ、認可チェック、依存関係更新の候補差分 仕様変更の承認、互換性判断、セキュリティ例外の承認
検証 単体テスト追加、再スキャン、差分説明 レビュー、侵入テスト、リリース可否

関連する全体像は、既存記事のClaude Codeセキュリティ脆弱性対応ワークフローと、チーム設定に寄せたClaude Codeエンタープライズセキュリティチェックリストもあわせて読むと整理しやすいです。

推奨アーキテクチャ：検出、分解、修正、再スキャン、レビュー

SAST自動修正の構成は、最初から大きな自動化を作るより、5段階に分けたほうが事故が少なくなります。ポイントは「Claude Codeが触ってよい範囲」と「人間が承認する範囲」を混ぜないことです。

ステップ 入力 Claude Codeの役割 終了条件
1. SAST実行 Semgrep、CodeQL、依存関係監査など 原則なし。既存ツールで結果を出す JSONまたはSARIFが生成されている
2. 指摘分解 SAST結果ファイル 1件ずつ、該当箇所、データフロー、影響範囲を読む 修正対象が1つに絞られている
3. 修正計画 該当ファイル、テスト、既存規約 plan modeで差分方針を提示する 人間が方針を承認している
4. 最小差分 承認済み計画 コードとテストを編集し、必要なコマンドを実行する テストと再スキャンが通る、または残課題が明記される
5. レビュー 差分、テスト結果、SAST再実行結果 レビュー観点を整理する 人間がマージ可否を判断する

この流れにすると、Claude Codeは「セキュリティ判断者」ではなく「レビュー可能な修正候補を作る実装者」として扱えます。ここを間違えると、SASTの誤検知を無理やり消すだけの差分になりがちです。

最小構成：SAST結果をファイル化してClaude Codeに読ませる

まずはCIに入れる前に、ローカルでSAST結果をファイルに落とします。Semgrepの公式ドキュメントでは、semgrep ciの結果をJSONやSARIFに出力できます。npmの公式ドキュメントでは、npm audit --jsonやnpm audit fix --dry-run --jsonが確認できます。CodeQLは、データベース解析の結果をSARIFなどで出力できます。

mkdir -p .sast

# Semgrep: JSONとSARIFを残す
semgrep ci --json --json-output .sast/semgrep.json
semgrep ci --sarif --sarif-output .sast/semgrep.sarif

# npm依存関係監査: まずは自動更新せずJSONだけ見る
npm audit --json > .sast/npm-audit.json
npm audit fix --dry-run --json > .sast/npm-audit-dry-run.json

CodeQLを使う場合は、既存のCIでCodeQLデータベースを作成している前提なら、解析結果をSARIFとして保存します。言語やビルド方式によりコマンドは変わるため、ここでは概念例に留めます。

mkdir -p .sast

# 例: 既存のCodeQL databaseを解析しSARIFに出す
codeql database analyze .codeql-db \
  --format=sarifv2.1.0 \
  --output=.sast/codeql.sarif

この時点では、Claude Codeに「全件直して」とは言いません。最初のプロンプトは、修正ではなく分類です。

SAST結果を分類してください。

対象ファイル:
- .sast/semgrep.json
- .sast/npm-audit.json

やってほしいこと:
1. high/critical相当の指摘を優先してください。
2. 同一原因の重複指摘はまとめてください。
3. まず修正対象を1件だけ選び、その理由を説明してください。
4. 修正はまだ行わず、影響範囲と検証方法だけ提示してください。

制約:
- 推測した点は必ず「仮定」と明記してください。
- 数字と固有名詞は、根拠となるファイル名や行番号を添えてください。
- 不足している情報があれば、最初に質問してから作業を開始してください。

Claude Codeの権限設計：plan mode、deny、askを先に置く

SAST修正では、Claude Codeに読み取り、編集、コマンド実行を許可する場面があります。だからこそ、最初に権限を絞ります。Claude Code公式ドキュメントでは、権限モードとしてdefault、acceptEdits、plan、auto、dontAsk、bypassPermissionsが説明されています。SAST修正の初期運用では、まずplanで調査と計画だけをさせるのが扱いやすいです。

プロジェクトに置く例です。実際の許可範囲は、リポジトリの言語、テストコマンド、社内規程に合わせて調整してください。

{
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(semgrep ci *)",
      "Bash(npm test *)",
      "Bash(npm run test *)",
      "Bash(npm audit *)"
    ],
    "ask": [
      "Edit(/src/**)",
      "Edit(/tests/**)",
      "Write(/tests/**)",
      "Bash(npm install *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(./.aws/**)",
      "Bash(git push *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "WebFetch"
    ]
  }
}

ポイントは3つです。第一に、.envや秘密情報ディレクトリを読ませないこと。第二に、git pushをClaude Code側で実行させないこと。第三に、ネットワーク送信を必要最小限にすることです。公式ドキュメントでも、BashでのURL制限は壊れやすく、curlやwgetのようなネットワークツールはdenyし、必要な場合はより明示的なWebFetch権限やhooksを組み合わせる方針が示されています。

なお、bypassPermissionsや--dangerously-skip-permissionsは、SAST自動修正の通常運用では使わない前提にしてください。公式ドキュメントでも、このモードは保護を提供しないこと、隔離されたコンテナやVM向けであることが説明されています。

CLAUDE.mdにセキュリティ修正の作法を書いておく

Claude Codeは、CLAUDE.mdや.claude/rules/からプロジェクトの指示を読みます。公式ドキュメントでは、CLAUDE.mdは「毎回説明し直したくない事実や規約」を置く場所として説明されています。ただし、CLAUDE.mdは強制境界ではありません。危険操作のブロックは権限ルールやhooksで行い、CLAUDE.mdは作業品質をそろえるために使います。

# Security fix policy

このリポジトリでSAST指摘を修正する場合は、以下を守る。

1. 1回の変更で扱うSAST指摘は原則1種類に絞る。
2. 指摘を消すためだけのコメントアウト、ルール抑制、テスト削除は禁止。
3. 修正前に、該当する入力経路、信頼境界、既存テストを確認する。
4. 修正後に、単体テストまたは回帰テストを追加する。
5. SAST再実行結果とテスト結果を最後に要約する。
6. 仕様判断、脆弱性受容、例外登録は人間のレビュー待ちにする。
7. 仮定した点は必ず「仮定」と明記する。
8. 不足している情報があれば、最初に質問してから作業を開始する。

このようなルールを置くと、毎回のプロンプトが短くなります。特に「指摘を消すためだけの抑制禁止」は重要です。SAST運用で一番まずいのは、根本原因が残ったまま、検出だけが消える状態だからです。

実務手順：1件だけ直すClaude Codeプロンプト

ここからは、実際の作業手順です。最初の修正対象を1件に絞ったら、Claude Codeには次のように依頼します。修正前に必ず計画を出させ、承認してから編集へ進む形にします。

プロンプト1：SAST指摘の根本原因を読む

.sast/semgrep.json の指摘のうち、最初に直すべき1件を選んでください。

条件:
- severity、到達可能性、ユーザー入力との距離、修正範囲の小ささを見てください。
- 修正はまだしないでください。
- 該当ファイル、関数、データフロー、既存テストの有無を確認してください。

出力形式:
1. 選んだ指摘
2. 根本原因
3. 攻撃成立の前提
4. 最小修正方針
5. 追加すべきテスト
6. 不明点

仮定した点は必ず「仮定」と明記してください。
不足している情報があれば、最初に質問してから作業を開始してください。

プロンプト2：修正計画だけを作る

選んだSAST指摘について、修正計画を作ってください。

制約:
- まだファイル編集はしないでください。
- 既存APIの互換性を壊さない方針を優先してください。
- セキュリティ挙動を守るテストを最低1つ提案してください。
- SAST指摘を抑制するだけの変更は避けてください。

計画に含めるもの:
- 変更対象ファイル
- 変更理由
- 追加または更新するテスト
- 実行する検証コマンド
- 残るリスク

数字と固有名詞は、根拠となるファイル名や行番号を添えてください。

プロンプト3：最小差分で修正する

上の計画を承認します。最小差分で修正してください。

作業ルール:
- 1つのSAST指摘だけを対象にしてください。
- 関連しないリファクタリングはしないでください。
- 修正とテスト追加を分けて説明してください。
- テスト削除、認可チェック削除、SASTルール抑制は禁止です。

修正後に実行すること:
- 変更ファイルに関係する単体テスト
- SASTの再実行
- git diffの要約

最後に、レビュー担当者が見るべき観点を箇条書きで出してください。

プロンプト4：テスト観点を強化する

今回の脆弱性修正について、テストが十分かレビューしてください。

確認したいこと:
- 正常系だけでなく、悪意ある入力のテストがあるか
- 境界値、空文字、null、不正な型を見ているか
- 認可や所有者チェックがある場合、別ユーザーのアクセスを拒否しているか
- SAST指摘が消えても、仕様上のリスクが残っていないか

不足があれば、テスト追加案を出し、必要なら実装してください。
仮定した点は必ず「仮定」と明記してください。

プロンプト5：レビュー用サマリーを作る

この差分をセキュリティレビュー向けに要約してください。

含めるもの:
- 修正したSAST指摘
- 根本原因
- 修正内容
- 追加したテスト
- 実行した検証コマンドと結果
- 残るリスク
- レビュー担当者に確認してほしい点

注意:
- 「完全に安全」と断定しないでください。
- 根拠のない成果数値を書かないでください。
- 仕様判断が必要な点は「レビュー待ち」と明記してください。

この5つを使うだけでも、SAST指摘の読み飛ばしはかなり減ります。Claude Codeにいきなり編集させるのではなく、「読む、計画する、直す、検証する、説明する」を分けるのがコツです。

hooksで再スキャンと危険操作ブロックを自動化する

Claude Codeのhooksは、セッション中のライフサイクルやツール実行に反応して、コマンド、HTTP、MCPツール、プロンプト、エージェントを実行できる仕組みです。公式ドキュメントでは、PreToolUse、PostToolUse、Stopなどのイベントが説明されています。SAST運用では、主に2種類のhooksが使いやすいです。

  • PreToolUse：危険なBashコマンドや禁止ファイルアクセスを事前に止める。
  • PostToolUse：編集後にlint、test、SASTの軽量再実行を促す、または結果ファイルを更新する。

例として、Claude CodeがEditまたはWriteを使ったあとに、軽量チェックを走らせるhookを置きます。実際にはリポジトリのテスト時間に合わせ、差分対象だけを見るスクリプトにしてください。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/sast-after-edit.sh",
            "timeout": 120,
            "statusMessage": "Running targeted SAST check"
          }
        ]
      }
    ]
  }
}
#!/usr/bin/env bash
set -euo pipefail

mkdir -p .sast

if command -v semgrep >/dev/null 2>&1; then
  semgrep ci --json --json-output .sast/semgrep-after-edit.json || true
fi

if [ -f package.json ]; then
  npm test -- --runInBand || true
fi

注意点があります。公式ドキュメントでは、コマンドhooksはユーザー権限で実行されるため、シェルスクリプト自体を安全に保つ必要があります。hooksに何でも入れると、Claude Codeではなくhooksが事故の入口になります。最初は読み取り中心、短いタイムアウト、ネットワークなしで始めるのがよいです。

hooks全体の設計は、既存記事のClaude Code hooks自動化ガイドにも整理されています。

CIで回す場合：非対話実行とGitHub Actionsは「PR限定」にする

Claude Codeは、claude -pで非対話実行できます。公式ドキュメントでは、--allowedTools、--output-format、--permission-modeなどを組み合わせたスクリプト運用が説明されています。GitHub Actionsについても、anthropics/claude-code-action@v1を使ったPRやIssueでの自動化が紹介されています。

ただし、SAST自動修正をCIで使う場合は、最初から自動マージにしないでください。推奨は、手動実行またはPR限定で、Claude Codeに差分候補とレビューコメントを作らせる形です。

name: sast-claude-autofix

on:
  workflow_dispatch:
  pull_request:
    types: [opened, synchronize]

jobs:
  sast-claude:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      issues: write

    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Run Semgrep
        run: |
          mkdir -p .sast
          semgrep ci --json --json-output .sast/semgrep.json || true

      - name: Ask Claude Code for a fix plan
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            .sast/semgrep.json を読んで、high/critical相当の指摘を1件だけ選んでください。
            まだ修正はせず、最小修正計画、追加テスト、検証コマンド、残るリスクをPRコメント向けにまとめてください。
            仮定した点は必ず「仮定」と明記してください。
          claude_args: "--permission-mode dontAsk --allowedTools Read,Bash(git diff *),Bash(git status *)"

この例は「修正計画の作成」に留めています。修正まで任せる場合も、ブランチ作成、コミット、PR作成、レビュー必須のルールを別途設計してください。Claude Code Actionの公式ドキュメントでも、GitHub App、APIキーsecret、ワークフロー設定、権限の考慮が説明されています。企業リポジトリでは、pull_request_targetのような権限が強いイベントを使う前に、必ずセキュリティレビューを通してください。

CI全体のClaude Code活用は、Claude Code CI/CDパイプライン自動化ガイドと、品質メトリクスに寄せたClaude Code品質メトリクス自動修正ガイドが近いテーマです。

MCPを使う場合：チケットやSAST管理画面は読み取り優先にする

MCPを使うと、Claude Codeは外部ツールやデータソースと接続できます。公式ドキュメントでは、Issue tracker、監視データ、データベース、デザインツールなどの例が紹介されています。SAST運用でMCPを使うなら、次のような用途が考えられます。

  • SAST管理ツールのチケットを読む。
  • 過去の脆弱性対応チケットから、同種修正のパターンを探す。
  • セキュリティレビューのチェックリストを読み込む。
  • PR番号、Issue番号、修正対象ブランチを同期する。

ただし、MCPは便利な反面、外部コンテンツを取り込むためプロンプトインジェクションのリスクがあります。公式ドキュメントでも、外部コンテンツを取得するサーバーは信頼性を確認するよう注意されています。SAST自動修正でMCPを入れるなら、最初は読み取り専用、社内ホスト限定、書き込み系ツールはaskまたはdenyにするのが無難です。

{
  "permissions": {
    "ask": [
      "mcp__github__create_*",
      "mcp__jira__create_*",
      "mcp__jira__update_*"
    ],
    "deny": [
      "mcp__*__delete*",
      "mcp__*__remove*"
    ]
  }
}

MCPの実践設計は、既存記事のClaude Code MCP実践ガイドも参照してください。

修正対象別の具体例：入力検証、認可、依存関係

SAST指摘には種類があります。Claude Codeに修正を依頼するときは、指摘タイプごとに「期待する修正の形」を明示すると、余計な変更が入りにくくなります。

例1：入力検証不足

APIのクエリパラメータやフォーム入力が、そのままファイルパス、SQL、テンプレート、コマンドに渡っているタイプです。Claude Codeには、既存フレームワークのバリデーション機構を優先して使わせます。

このSAST指摘は入力検証不足です。

修正方針:
- 既存のバリデーションライブラリやフレームワーク機能を優先してください。
- 独自正規表現を追加する場合は、許可リスト方式にしてください。
- 危険入力を拒否するテストを追加してください。
- エラーメッセージに秘密情報や内部パスを出さないでください。

修正後:
- 対象テストを実行してください。
- SASTを再実行してください。
- 仕様変更がある場合はレビュー待ちとして明記してください。

例2：認可チェック不足

認証済みユーザーであっても、他人のリソースにアクセスできてしまうタイプです。これはYMYL領域にも関わりやすいため、「修正できた」と断定せず、レビュー観点を残します。

このSAST指摘は認可チェック不足の可能性があります。

作業:
- 既存の認可ヘルパー、policy、middlewareを探してください。
- 同じリソース種別で使われている認可パターンに合わせてください。
- 別ユーザーのリソースアクセスが拒否されるテストを追加してください。
- 管理者、所有者、ゲストなどのロール差分を確認してください。

禁止:
- 認可チェックをコメントアウトしない。
- テストを削除しない。
- 仕様判断をClaude Codeだけで確定しない。

不足している情報があれば、最初に質問してから作業を開始してください。

例3：依存関係の脆弱性

依存関係の修正では、npm audit fixをいきなり本実行する前に、dry-runのJSONを読ませます。メジャーアップデートが入る場合、互換性確認が必要です。

.sast/npm-audit-dry-run.json を読んで、依存関係更新案を評価してください。

確認項目:
- どのパッケージが更新されるか
- lockfileだけの変更か、package.jsonも変わるか
- メジャーバージョン更新が含まれるか
- 既存テストで影響を確認できるか
- 代替案として直接依存の更新、間接依存の解消、保留があり得るか

まだ npm audit fix は実行しないでください。
仮定した点は必ず「仮定」と明記してください。

依存関係の修正は、コード修正よりも影響範囲が見えにくいことがあります。Claude Codeに「パッケージを上げて」とだけ言うのではなく、lockfile差分、破壊的変更、テスト範囲を明示させてから進めるのが安全です。

【要注意】よくある失敗パターンと回避策

失敗1：SAST指摘を全件まとめて直させる

❌「SASTの指摘を全部直して」

⭕「high相当の指摘を1件だけ選び、修正計画を出して。承認後に最小差分で直して」

なぜ重要か：複数の脆弱性タイプを一括で扱うと、差分が大きくなり、レビュー不能になります。SAST運用では、指摘単位または原因単位で小さく直すほうが安全です。

失敗2：検出を消すことをゴールにする

❌「Semgrepのエラーが消えればOK」

⭕「根本原因を直し、悪意ある入力のテストを追加し、再スキャンで指摘が消えたことを確認する」

なぜ重要か：SASTルールの抑制やコメントアウトだけで検出を消すと、本来のリスクが残ることがあります。Claude Codeには、テストと説明までセットで依頼します。

失敗3：Claude Codeに秘密情報を読ませる

❌「本番環境の.envも読んで原因を調べて」

⭕「Read(./.env)やRead(./secrets/**)をdenyし、必要な設定値はダミー名で共有する」

なぜ重要か：SAST修正では、認証、認可、外部API、DB接続の周辺を読むことがあります。秘密情報を読ませない設計を先に置かないと、修正作業の途中で不要な露出が起きます。

失敗4：CIで自動マージまで走らせる

❌「SAST修正PRはClaude Codeが自動でマージ」

⭕「Claude Codeは修正候補とレビューサマリーを作る。マージは人間の承認後」

なぜ重要か：セキュリティ修正は、動けばよいわけではありません。互換性、仕様、監査ログ、顧客影響を確認する必要があります。自動化の終点はマージではなく、レビュー可能な差分です。

導入ロードマップ：1週間、1か月、3か月で広げる

いきなり全リポジトリにClaude Code自動修正を入れる必要はありません。小さく始めて、権限とレビューを固めながら広げます。

期間 やること 成功条件
1週間 1リポジトリでSAST結果をJSON化し、Claude Codeに分類だけさせる 修正対象を1件に絞れる。秘密情報を読まない設定がある
1か月 入力検証、認可、依存関係の3カテゴリでプロンプトとテスト方針を作る 小さなPR単位で、人間がレビューできる差分になる
3か月 CIで計画作成、PRコメント、再スキャン結果要約を自動化する 自動修正ではなく、レビュー支援としてチーム運用に定着する

評価指標も、最初はシンプルで十分です。「SAST指摘が何件減ったか」だけでなく、「レビューで差し戻された理由」「テストが追加された割合」「抑制で逃げた指摘の数」「例外承認の理由」を見ます。Claude Codeの使い方自体を改善するなら、既存記事のClaude Code権限設計チームガイドも参考になります。

FAQ：Claude Code×SAST自動修正でよくある質問

Q1. Claude CodeだけでSASTの代わりになりますか？

なりません。Claude Codeはコード読解、修正案作成、テスト追加、再スキャン補助に向いていますが、検出器としてはSASTツールを使う設計にしてください。検出、修正、レビューの責務を分けることが重要です。

Q2. SAST指摘は何件ずつClaude Codeに渡すべきですか？

最初は1件ずつです。同一原因の重複指摘であればまとめてもよいですが、SQL injection、XSS、認可漏れ、依存関係更新を同じプロンプトで直させるのは避けてください。

Q3. --dangerously-skip-permissionsを使うと速くなりますか？

許可プロンプトは減りますが、SAST自動修正の通常運用ではおすすめしません。公式ドキュメントでも、bypassPermissionsは保護を提供しないことが説明されています。隔離されたコンテナやVM以外では、plan mode、acceptEdits、dontAsk、明示的なallow/denyで設計するほうが安全です。

Q4. hooksでSASTを毎回走らせるべきですか？

小さなリポジトリなら可能ですが、大きなリポジトリでは重くなります。最初は編集後に対象テストだけ、または軽量Semgrepだけを走らせ、フルスキャンはCIに回すのが現実的です。hooks自体もユーザー権限で動くため、短く安全なスクリプトにしてください。

Q5. SASTの誤検知はClaude Codeに抑制させてもよいですか？

抑制は最後の手段です。Claude Codeには、まず根本原因、到達可能性、既存の安全策、テストでの確認方法を説明させてください。抑制する場合は、理由、期限、レビュー者、再確認条件をコメントやチケットに残すべきです。

Q6. MCPでSAST管理ツールにつないでもよいですか？

可能ですが、最初は読み取り専用にしてください。外部コンテンツを取り込むMCPサーバーにはプロンプトインジェクションのリスクがあります。書き込み系ツール、削除系ツール、外部送信系ツールはaskまたはdenyにするのが安全です。

Q7. 依存関係の脆弱性は自動でnpm audit fixしてよいですか？

まずdry-runを見ます。メジャーバージョン更新やlockfileの大きな差分がある場合は、互換性確認が必要です。Claude Codeには、更新内容、破壊的変更の可能性、必要テストを説明させてから進めてください。

Q8. セキュリティレビュー担当者は何を見ればよいですか？

最低限、根本原因が消えているか、テストが脆弱性シナリオを覆っているか、SAST抑制で逃げていないか、秘密情報や外部送信が発生していないか、仕様判断が残っていないかを確認してください。AIは補助ツールであり、最終判断者ではありません。

参考・出典

まとめ：今日から始める3つのアクション

  1. 今日やること：既存リポジトリでsemgrep ci --jsonまたは利用中SASTのJSON/SARIF出力を作り、Claude Codeに分類だけ依頼する。
  2. 今週中：.claude/settings.jsonに秘密情報のdeny、git pushのdeny、初期planモードを設定し、1件だけ修正する流れを試す。
  3. 今月中：hooksまたはCIで、再スキャン結果、テスト結果、レビューサマリーをPRに残す運用へ広げる。

SAST自動修正のゴールは、AIにセキュリティ判断を丸投げすることではありません。レビュー可能な最小差分を速く作り、テストと再スキャンで確認し、人間が判断する流れを安定させることです。Claude Codeは、その「実装と検証の往復」を短くする道具として使うのが一番現実的です。

次回予告：次の記事では、SAST結果をSARIFからPRコメントへ変換し、Claude Codeの修正サマリーとレビュー観点を自動で貼る実装パターンを扱います。

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。

Claude Codeのチーム導入、セキュリティレビュー設計、SAST運用への組み込みについてのご質問は、お問い合わせフォームからどうぞ。

あわせて読みたい

Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、AI開発ツール導入の失敗を減らせます。

導入を相談する

Related Cases

Claude Codeでモノリス分割・マイクロサービス移行【2026年最新】
SaaS・IT

Claude Codeでモノリス分割・マイクロサービス移行【2026年最新】

Claude Codeでモノリスの依存関係を可視化し、Strangler Figパターンで段階的にマイクロサービス化する手順をコード例付きで解説（想定シナリオ）。

読む
【2026年最新】旅行代理店Claude Code活用5ステップ
SaaS・IT

【2026年最新】旅行代理店Claude Code活用5ステップ

旅行代理店 Claude Codeで行程表・見積書・旅行条件書の作成負担を減らす設計を、法令確認と5ステップで解説。

読む
【2026年最新】引越し業Claude Code実務7選
SaaS・IT

【2026年最新】引越し業Claude Code実務7選

引越し業 Claude Codeで訪問見積書、作業指示書、繁忙期の配車・シフト調整を効率化する実装手順を解説。

読む