Claude Code をセキュリティコードレビューに使うなら、最初から agent に全社リポジトリをスキャンさせないでください。Alberta 事例で真似すべきなのは、この監査できる流れです。ルールエンジンが既知パターンを先に示し、Claude Code がそれを再確認してファイルと行番号を引用し、最後にエンジニアが修正を承認します。
きっかけは Anthropic が 2026-07-06 に公開した Alberta 政府事例です（出典：Anthropic 公式事例、本文の確認日：2026-07-07）。Anthropic によると、Alberta は 2025 年から Claude Code と Opus / Sonnet モデルを組み合わせ、政府システムのレビューに使っています。技術チームは約 20 時間で 4.66 億行のコードを評価し、約 50 個の agent を並列稼働させ、管理する政府コードベースを対象にしました。ただし修正のリリース前には、エンジニアによるレビューと承認が残されています。
Alberta の規模数字を、そのままあなたのチームの ROI 予測に使わないでください。再利用できるのは試験導入の順序です。まず資産とルールを限定し、確認できる証拠を求め、AI に修正案とテスト案を書かせ、マージ、開示、リリースの判断は人に残します。
先に試すべきチーム
Claude Code のセキュリティレビュー試験導入は、コード責任者、テスト入口、脆弱性対応フローをすでに持つチームに向いています。これらがない場合、agent は誤検知と review 負荷を先に増やします。
| チームの状態 | 推奨 |
|---|---|
| 10 個以上のサービス、過去の技術負債、セキュリティ backlog がある | 境界が明確な 1 システムを選んで試験導入する |
| SAST、依存関係スキャン、内部セキュリティルールはあるが、修正する人手が足りない | Claude Code に二次確認、修正草案、テスト草案を任せる |
| レガシーシステムがあり、文書が不完全で、保守担当者が変わりやすい | まずセキュリティ checklist と技術文書を補う。いきなり本番コードを直させない |
| CI、owner、セキュリティ連絡先がない | 先にプロセスを整える。大規模 agent レビューは始めない |
| リポジトリに本番秘密情報、未公開脆弱性の詳細、顧客の機微データがある | agent アクセスを議論する前に、隔離コピーと脱敏入力を用意する |
Alberta が相手にしていたのは、公共部門の大規模レガシーシステムです。Anthropic の事例では、同州の Ministry of Technology and Innovation が 27 の州政府部門向けシステム、約 1,280 個のアプリケーション、3,400 個のコードリポジトリを管理しており、その多くは体系的なセキュリティレビューを受けていませんでした。あなたのチームがその規模である必要はありませんが、資産境界は先に決める必要があります。
第一回で全社をスキャンしない
第一回で確認するのは、セキュリティレビューの閉じた流れが成立するかどうかです。候補問題を説明できるか、パッチをテストできるか、責任者が承認できるか。Alberta の 4.66 億行スキャンを最初から再現しようとしないでください。
リポジトリ選定では、この 6 条件で絞ります。
| 選定条件 | 合格基準 |
|---|---|
| 業務境界 | 1 つのサービス、1 つのアプリ、または明確なサブシステム |
| コード責任者 | 少なくとも 1 名の owner が結果を review できる |
| テスト入口 | 単体テスト、統合テスト、または最小検証コマンドがある |
| リスク種別 | 認証、入力検証、依存関係バージョン、ログ漏えいなど 2-3 種類に絞る |
| データ境界 | 本番秘密情報、実顧客データ、未公開脆弱性資料を出さずに済む |
| ロールバック | 修正失敗時に戻せる。本番に直接影響しない |
第一回では、決済、ID 基幹処理、本番デプロイスクリプト、クラウド権限、DNS、鍵管理、未隔離の全量 monorepo は避けます。セキュリティレビューは大きいほど良いわけではありません。最初の試験導入では、真陽性率、修正コスト、review 負荷を測れることが重要です。
agent は「二段階レビュー」で組む
Anthropic の事例では、Alberta はモデルにリポジトリ全体を自由探索させていません。公式説明の中心は二段階です。まずルールエンジンが既知パターンをマークし、そのマークを Claude Code がレビューして、具体的なファイルと行番号を引用し、開発者が確認できる形にします。
第一回は次の構造で走らせます。
- ルールセットを用意する：過去の脆弱性、SAST ルール、依存関係ポリシー、内部コーディング規約から 10-30 条を選ぶ。
- 先に決定的なスキャンを走らせる：ルールエンジンやスクリプトで候補問題を出す。Claude に全リスクを自由探索させない。
- Claude Code に候補を再確認させる：各候補について、発火条件、影響範囲、ファイルパス、行番号を説明させる。
- 修正草案を求める：選定したディレクトリ内だけで、最小パッチを作らせる。
- テストがなければ先にテストを足す：パッチの安全性を示す自動テストがなければ、まず Claude にテストを書かせ、その後で実装変更を検討する。
- 人が承認する：owner またはセキュリティエンジニアが、真陽性、深刻度、パッチ、テストを確認してからマージする。
この流れでは、各結果に確認可能な資料が残ります。セキュリティチームは、どのルールが命中したか、Claude がどう判断したか、どの行が影響を受けるか、パッチとテストがどこにあるかを確認できます。
Claude Code へのタスクテンプレート
試験導入用のプロンプトでは、権限、入力、出力、停止条件を明確にします。次のテンプレートを調整して使えます。
あなたは、監督付きの Claude Code セキュリティレビュー試験導入で作業しています。
目標：
security-findings.json の候補問題を再確認してください。対象は src/auth と src/api だけです。
入力：
- security-findings.json はルールエンジンが生成した候補結果です
- docs/threat-model.md はこのサービスの脅威モデルです
- tests/api は現在実行できるテストです
許可：
- src/auth、src/api、tests/api、docs/threat-model.md を読む
- 問題確認のためにファイルパスと行番号を引用する
- 最小限の修正草案を生成する
- tests/api 内のテストを追加または修正する
禁止：
- 外部システムをスキャンする
- エクスプロイトコード、攻撃ペイロード、検知回避、横展開、永続化、データ持ち出し手順を生成する
- デプロイ、クラウド権限、秘密情報、CI/CD、本番設定を変更する
- 新しい依存関係を追加する
- 自動で commit、push、release する
出力：
1. 各候補が真陽性、誤検知、不明のどれか
2. 根拠。ファイルパスと行番号を必ず含める
3. 最小修正案
4. 追加すべきテスト
5. 人が決める必要のある事項
停止条件：
- 許可範囲外のファイルにアクセスする必要がある
- 5 個を超える業務ファイルを変更する必要がある
- 新しい依存関係が必要になる
- 高危険度の脆弱性、または未公開脆弱性の疑いを見つける
このテンプレートで Claude に「利用可能性を証明」させないでください。セキュリティレビューの第一回で出すべきものは、修正と確認の材料であり、攻撃再現の材料ではありません。
パッチ生成の前にテスト門を置く
Anthropic の事例では、Alberta は脆弱性発見後に Claude Code で修正、テスト、ビルドを生成しています。自動テストがないシステムでは、Claude が先にテストを書きます。試験導入でも同じ順序にしてください。先にテストを足し、次にパッチを確認し、最後にビルドで検証します。
パッチ権限は 3 段階に分けます。
| パッチ種別 | 扱い |
|---|---|
| 低リスク修正。例：入力検証、エラー処理、ログ脱敏 | Claude Code がパッチ草案を出してよい。ただしテスト必須 |
| 中リスク修正。例：認証ロジック、権限判断、シリアライズ境界 | Claude は方針とテスト草案だけを出す。owner が中核ロジックを手で直す |
| 高リスク修正。例：ID 基幹処理、決済、本番設定、暗号、秘密情報 | Claude は影響分析と review checklist だけを出す |
「Claude が build できた」ことを「マージしてよい」と扱わないでください。マージ前に少なくとも次を確認します。
- パッチが許可ディレクトリだけを変更している
- テストが発火条件と負例を覆っている
- 新しい依存関係や広い権限を導入していない
- 認証、認可、ログ、データ保持の意味を意図せず変えていない
- セキュリティ公告、CVE、顧客通知、遅延開示プロセスが必要か
継続レビューは役割に分ける
Alberta 事例では、開発中に継続稼働する専用の Claude review agents も作られています。外部視点でアプリを確認するレッドチーム視点 agent、国際的なセキュリティ標準に沿って防御を評価し修正計画を書くブルーチーム視点 agent、コード品質や公開文面を確認する agent などです。各回で約 95 個のセキュリティ管理項目を確認します。
この構造は参考にできますが、初版を全自動の攻防プラットフォームにしないでください。まず次の制限付きロールに分けます。
| Agent ロール | 初版の責任 | やらせないこと |
|---|---|---|
| 候補レビュー agent | ルールエンジンの結果を再確認し、ファイルと行番号を引用する | 攻撃経路を自由生成する |
| 修正草案 agent | 最小 patch とテスト草案を作る | 自動で merge、push、release する |
| 防御 checklist agent | 内部管理項目と照合して不足を確認する | セキュリティ責任者の深刻度判断を代替する |
| 文書 agent | システム説明、リスク説明、runbook を補う | 未確認のシステム挙動を作り上げる |
| 回帰 agent | 限定された検証コマンドを実行し、失敗を要約する | 失敗を隠すためにテストを変更する |
レッドチーム視点 agent を使う場合も、許可されたテスト環境に限定し、出力はリスク説明、影響コンポーネント、証拠位置、修正案に絞ります。再利用可能な攻撃手順を普通のチケットやコード review スレッドに入れないでください。
試験導入の指標は 3 種類を見る
「何行スキャンしたか」だけを報告しないでください。Alberta の規模数字はニュース背景としては有用ですが、あなたの社内試験導入の成功指標には向きません。
第一回では次の 3 種類を記録します。
| 指標 | 記録するもの |
|---|---|
| 正確性 | 候補数、真陽性、誤検知、不明、重複問題 |
| 修正ループ | 生成されたパッチ数、テスト付きパッチ数、CI 通過数、マージ数、ロールバック数 |
| 人のコスト | 1 問題あたりの review 時間、owner の修正時間、セキュリティ責任者へのエスカレーション回数 |
2 週間の試験導入後、次を満たす場合だけ範囲を広げます。
- 真陽性をファイルと行番号で確認できる
- 誤検知の原因を分類でき、ルールやプロンプトを改善できる
- マージしたパッチにテスト、または明確な人による検証記録がある
- 越権読み取り、機微データ漏えい、未承認の外部アクセスがない
- owner が低品質な報告に埋もれず、review 負荷が下がったと判断している
よくある失敗
Claude Code を SAST の代替として扱う
おすすめしません。Alberta 事例では、Claude Code はルールエンジンの後ろに置かれています。決定的なツールが既知パターンを安定して命中させ、Claude が説明、位置特定、修正草案、テスト草案を担当します。
agent に完全な攻撃再現を求める
セキュリティ修正に完全な攻撃手順は不要です。通常の試験導入では、影響ファイル、発火条件、リスク説明、修正テストがあれば十分です。利用、回避、データ持ち出し、永続化に近づくほど、管理されたセキュリティプロセスに移してください。
テストなしで一括修正させる
システムにテストがないなら、まず Claude Code にテストと文書を補わせます。レガシーシステムをいきなり一括変更すると、セキュリティ試験導入が回帰リスクの発生源になります。
人による承認を省く
Anthropic 事例では、patch リリース前に Alberta のエンジニアリングチームがレビューと承認を行うと明記されています。自分たちのフローでも、この承認線を残してください。AI は発見、説明、修正草案を速くできますが、最終的なセキュリティ責任は代替できません。
事例の数字を約束として扱う
4.66 億行、20 時間、約 50 agent、95 管理項目は、Anthropic が Alberta 実装について説明した数字です。Alberta がその規模で実施したことを示すだけで、あなたのコードベースで同じ速度、正確性、コストになることは保証しません。
FAQ
Claude Code を政府や企業の機微コードに直接使えますか？
本番の機微リポジトリから始めないでください。隔離コピー、制限パス、脱敏入力、監査ログ、人による承認で試験導入します。政府、金融、医療、顧客の機微データを扱う場合は、組織のデータ処理とベンダーセキュリティ承認に従ってください。
第一回に必要な agent 数は？
50 個の agent から始める必要はありません。Alberta の約 50 agent は公式事例での規模です。通常のチームなら、第一回は候補レビュー、修正草案、回帰要約の 1-3 ロールで十分です。まず閉じた流れを証明し、その後で並列度を上げます。
内部ルールエンジンがない場合は？
既存の SAST、依存関係スキャン、lint ルール、過去の脆弱性一覧、セキュリティ checklist で候補を作ります。境界なしで Claude Code にすべての脆弱性を自由探索させないでください。
Claude Code が生成したセキュリティパッチを自動マージできますか？
できません。セキュリティパッチには少なくとも owner review、テスト、CI、セキュリティ確認が必要です。高危険度の脆弱性、開示、本番設定、ID 権限、秘密情報処理に関わる場合は、人が承認しなければなりません。
Fable 5 のサイバーセキュリティプロンプト記事との違いは？
Fable 5 サイバーセキュリティプロンプト記事は、越境リクエストと誤ブロックを避ける方法を扱います。この記事は Claude Code をセキュリティコードレビューのフローに入れる方法を扱い、資産選定、二段階レビュー、パッチテスト、人による承認に絞っています。
OpenAI Daybreak / Codex Security 記事との違いは？
OpenAI Daybreak 記事は、OpenAI の防御側セキュリティプログラム、Codex Security、GPT-5.5-Cyber、オープンソースパッチの流れを扱います。この記事は Alberta の Claude Code 事例だけを分解します。Claude Code を試すことは決めたが、第一回のリポジトリ範囲、agent ロール、パッチ承認線がまだ決まっていないチーム向けです。