目次
Anthropicは2026年10月21日、Claude Securityを更新し、初回の深いスキャンだけでなく、コードの変更に応じた継続スキャン、修正済みかどうかの追跡、API・MCP・Webhookによる外部連携を提供すると発表しました。Claude Enterprise向けのパブリックベータで、管理者が組織設定から有効にする機能です。
今回の更新で重要なのは、AIが脆弱性を探す能力そのものだけではありません。リポジトリーを読む権限、検出結果の状態を変える権限、通知を外部へ送る経路が、日常の開発フローへ入ってきます。本稿では公式資料で確認できた機能と、本サイトが提案する運用設計を分け、導入時に決めるべき境界を整理します。2026年10月24日1時台（日本時間）に公開情報を確認しており、本サイトが検出性能を実測した記事ではありません。
スポンサーリンク
何が変わったのか
従来のClaude Securityは2026年4月にパブリックベータが始まり、スキャンの実行、検出結果の説明、修正案の作成などを提供していました。10月21日の更新では、プロジェクトへ接続したリポジトリーに対してベースラインスキャンを行い、その後は新しいコミットを定期的に確認して、リスクと複雑さに応じた継続スキャンを行う構成になりました。公式ヘルプは固定の実行間隔ではないと説明しています。
一つのプロジェクトには最大8個のリポジトリーを接続できます。GitHub.comとGitHub Enterprise ServerではClaude GitHub Appを使い、GitLabなど別のGitプロバイダーではアクセストークンを使う方式が案内されています。リポジトリーは検出対象にするほか、読み取りだけを行うコンテキスト用にもできますが、どちらも8個の上限に数えられます。
Claude Securityはコードから脅威モデルを作り、チームがデプロイ形態、到達可能な利用者、適用するセキュリティ方針、受容済みリスクなどを補足できます。以後のスキャンでは、その脅威モデルを使って検出対象や重要度を判断します。提供元は多段階検証によって誤検知を減らすと説明していますが、確実に誤検知がなくなるという保証ではありません。
修正追跡は完了判定をAIへ丸投げする機能ではない
新しい版では、オープンな検出結果をコード変更と照合し、修正が入ると「fixed」と判断します。後のスキャンで同じ問題を再び見つけた場合は、検出結果が自動で再オープンします。修正をClaude Codeで作った場合だけでなく、別の手順で変更した場合も追跡対象になると公式発表は説明しています。
ただし、コード上で問題が見えなくなったことと、本番環境で安全に反映されたことは同じではありません。本サイトでは、検出結果の状態、修正PRのマージ、デプロイ、回帰試験、必要なら本番での適用確認を別々に記録することを提案します。AIが「修正済み」とした状態だけでチケットを閉じると、未デプロイの修正や、機能を壊した変更を見落とすおそれがあります。
修正案は必ず人がレビューする前提です。Claude Securityの製品ページも、提案されたパッチは人が確認・承認し、重要なシステムでは特に注意するよう案内しています。認証回避なら正しい利用者が入れることだけでなく、別利用者や不正な入力が拒否されることまで試します。入力検証なら、危険な入力を止めながら正規機能を維持できるかを確かめます。
スポンサーリンク
APIは閲覧と状態変更を分けて考える
Claude Security APIは、プロジェクトと検出結果の一覧・詳細取得に加え、検出結果の解決・再オープン、プロジェクトやリポジトリーの作成・管理を行えます。個人アクセストークンは発行した利用者として動作し、その利用者が見たり変更したりできる範囲だけを扱います。これは「トークンの権限が限定される」という利点である一方、発行者の権限変更や退職が連携へ影響することも意味します。
最初の連携は読み取りだけにし、取得した検出結果を課題管理へ写すところから始めるのが安全です。状態変更まで自動化する場合は、誰のトークンを使うか、どのプロジェクトを対象にするか、誤って解決済みにしたときの再オープン手順、トークンの保管・失効・更新を決めます。製品側が許す範囲で専用の運用主体を設ける場合も、所有者と定期点検を明示します。
トークンそのものをジョブログやエラー通知へ残してはいけません。成功・失敗を追うには、秘密値ではなく、実行ID、対象プロジェクト、検出結果ID、呼び出した操作、応答状態を記録します。AI連携の監査設計は、関連記事「AIエージェントが何をしたか追える？秘密を残さない監査ログの設計」で詳しく整理しています。
MCPは会話内の便利な参照だけではない
Claude SecurityのMCPコネクターは、ClaudeやClaude Codeからプロジェクトと検出結果を一覧・参照し、依頼に応じて解決または再オープンできます。検出内容を読みながら修正を始められる点は便利ですが、「読む」と「状態を変える」が同じ会話に並ぶため、接続を許可しただけで安全な運用が完成するわけではありません。
本サイトでは、導入時に三つを分けて試すことを提案します。第一に、一覧と詳細の閲覧。第二に、修正用の作業開始。第三に、解決・再オープンという記録の変更です。最初は閲覧対象を限定し、状態変更を行う操作では対象IDと意図を人が確認します。会話の説明文だけで成功を判断せず、変更後の状態を再取得して照合します。
プロンプトインジェクションや誤った文脈によって、別の検出結果へ操作が及ぶ可能性も考えます。リポジトリー内のREADME、Issue、テストデータなどは、AIにとって参照情報であっても命令として信頼できるとは限りません。MCP接続へ与える権限を狭くし、状態変更は独立した認可と監査を通します。
スポンサーリンク
Webhookは通知であり自動承認ではない
Webhookは新しい検出結果が追加されたとき、SlackやJiraなど自社の仕組みへ通知する用途です。通知を受けた側で課題を作る場合、同じイベントの再送で重複しない仕組み、受信時刻、対象プロジェクト、検出結果ID、処理結果を記録します。公式資料で確認できない署名ヘッダー名や再送仕様を推測して実装せず、実際の管理画面と最新ドキュメントで検証してください。
通知本文を根拠に自動で修正をマージしたり、検出結果を解決済みにしたりする構成は避けます。Webhookは「新しい出来事がある」と知らせる入口にとどめ、詳細は権限を限定したAPIで取り直し、担当者・優先度・期限を決めます。外部通知へソースコードや秘密情報を含めないことも重要です。
RBACは役割名より実際の操作で確認する
プロジェクト共有にはFull、Triage、Viewの役割があり、管理者はカスタムロールで、プロジェクト作成、閲覧、トリアージ、全プロジェクト管理などの機能を制御できます。Fullは検出結果、設定、共有相手を管理でき、Triageは閲覧、状態更新、修正開始ができ、Viewは参照を中心にした役割です。
役割名だけで最小権限と判断せず、テスト用プロジェクトで実際にできる操作を確認します。開発者全員にプロジェクト作成権限が必要とは限りません。一方、検出結果の所有者がコードを直せない構成では、通知だけ増えて対応が止まります。リポジトリー所有者、セキュリティ担当、管理者の責任を対応表にし、不在時の代行も決めます。
脅威モデルへ何を書くか
コードだけでは、実際の公開範囲、上流のWAF、管理ネットワーク、利用者の種類、データの機微性、受容済みの例外を判断できません。脅威モデルには、インターネットから到達する入口、認証と認可の境界、重要データ、外部サービスとの信頼関係、デプロイ単位を短く明示します。設計書を追加する場合は、古い版が残って誤判断を誘わないよう、所有者と更新日を持たせます。
受容済みリスクも「無視する」とだけ書かず、対象範囲、根拠、期限、再評価条件を記録します。環境が変われば、以前は到達不能だった経路が公開される場合があります。修正済みの自動判定と同様、受容済みというラベルも恒久的な安全証明ではありません。
導入評価は検出数ではなく対応の流れで測る
パブリックベータであること、スキャンが確率的で同じコードでも結果が異なり得ること、初回スキャンにはリポジトリー規模によって数分から数時間かかることを前提にします。検出件数だけで価値を判断すると、ノイズの増加を成果と取り違えます。重大な指摘を見逃さないか、根拠を追えるか、誤検知を説明できるか、修正後に回帰を防げるかを評価します。
AIによるコード検査が既存のテストや静的解析を置き換えると考えないことも大切です。GitHubのAI Scanについては、助言型でマージを止めない条件や、対象外PRを「GitHub AI Scanが一般提供に！検出できてもマージを止めない点に注意」で解説しています。製品は異なりますが、人による確認と機械的なゲートを分ける考え方は共通します。
スポンサーリンク
費用とデータ条件も先に確認する
Claude Securityは追加のプラットフォーム料金ではなく、直接のトークン費用で課金され、プロジェクトごとに別の支出上限を設定できます。対象となるEnterprise組織には、2か月間、月額最大2万5,000ドルの利用クレジットが提供されますが、2026年12月31日（UTC）で終了します。クレジット終了後も同じ規模で使い続ける場合の費用を、試行中の利用量から見積もる必要があります。
また、ホスト型のClaude SecurityはZero Data Retentionに対応しないと公式ヘルプに明記されています。ZDR要件がある場合や、Anthropicのホスト型エージェント基盤を使わずにワークフローへ組み込みたい場合は、別機能であるClaude Security plugin for Claude Codeが案内されています。プラグインは同じ技術を基礎にしますが、利用可能なモデルや実行条件が異なるため、同一製品として扱わないでください。
小さく始めるための確認順序
- 権利を持つ自社コードから、影響を限定できる1〜2個のリポジトリーを選ぶ
- GitHub Appまたはアクセストークンの到達範囲を確認し、不要なリポジトリーを外す
- 公開入口、認証境界、重要データを脅威モデルへ記載し、責任者がレビューする
- 最初は画面上で検出結果と根拠を確認し、既存の検査と比較する
- APIは読み取りから、Webhookは通知から、MCPは参照から始める
- 状態変更を追加するときは、認可、再読取、監査、誤操作の復旧を試す
- 修正のマージ、デプロイ、回帰試験まで追跡し、月間費用と担当負荷を測る
Claude Securityの継続スキャンは、単発監査から日常運用へAI検査を移す更新です。その価値を引き出すには、検出の性能だけでなく、コードを読む接続、結果を変えるAPIとMCP、外部へ通知するWebhook、人が承認する修正の境界を設計する必要があります。まず読み取りと通知を小さく始め、状態変更と自動化は、監査と復旧を確認してから段階的に広げてください。
スポンサーリンク
