Claude Securityとは？Anthropicの脆弱性診断機能で何が変わるか

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

4層で見る役割の違い

Claude Security を理解する近道は、Anthropic のセキュリティ関連機能を 4 つの層で分けて見ることです。Claude Security は 企業向けのコードベース診断機能 で、Claude Code の /security-review や Project Glasswing、CVP とは役割が違います。

ここではまず、どの名前が「製品」「開発者向け review」「研究 preview」「例外制度」に当たるのかをそろえます。役割が見えると、導入担当者が確認すべきポイントと、通常の Claude が止まる理由を同じ地図の上で読めるようになります。

この順に見れば、同じ Anthropic 製でも何が別物かと、どこで人間レビューを残せるかが最初に整理できます。次の章からは、それぞれの役割を一つずつ確認します。

① Claude Security

Claude Security は、Anthropic が Claude Enterprise 向けに案内しているセキュリティ機能です。単体の別アプリというより、Claude.ai 側でコードベースを読み込み、脆弱性候補を verified finding として返し、そのまま修正案までつなげる入口として理解するとズレにくくなります。

ポイントは、リポジトリ全体を見て調べること と 見つけた問題を修正判断まで運ぶこと の 2 つです。執筆時点では Enterprise の public beta が中心なので、導入担当者は「どのリポジトリをどう接続するか」「finding を誰がレビューするか」まで含めて運用を設計する必要があります。

そのため Claude Security は、結果だけを一覧表示するスキャナではなく、検出から修正提案までを 1 本の流れで扱う企業向けの運用レイヤーとして見ると理解しやすくなります。

② Claude Code

Claude Code の /security-review は、開発者がいま触っている差分や PR をその場で点検するための review です。Claude Security のようにリポジトリ全体を横断して新しい問題を探しにいく役割ではなく、変更内容を見て「この実装で危ない点はないか」を早く洗う入口として使います。

向いているのは、マージ前の確認や修正案のたたき台づくりです。気になる差分に対して短い往復で指摘と修正候補を得られるので、既存フローに挟みやすい一方、見えている範囲はあくまで review 対象の変更周辺に寄ります。

つまり、コードベース全体の発見を担うのが Claude Security、いまの変更を止める前の最終確認を担うのが Claude Code です。この切り分けで見ると、次の「③ Glasswing」が製品機能ではなく研究 preview だという違いも整理しやすくなります。

③ Glasswing

Project Glasswing は、Anthropic が defenders 向けに広げている研究・連携の名前として捉えると分かりやすくなります。読者がすぐ設定画面で有効化する機能名というより、セキュリティ領域でどんな支援を拡張しているかを示す上位の文脈です。

そのため、Glasswing の発表を見て Claude Security を理解する時は、「今すぐ使う製品機能」と「研究 preview や協業の取り組み」を分けて読む必要があります。Claude Security は前者、Glasswing は後者に近い位置づけです。

この違いを押さえると、Anthropic のニュースで両者が並んでいても、導入担当者が確認すべき対象は Claude Security の提供条件と運用フローだと判断しやすくなります。

④ CVP

CVP は、Anthropic が攻撃にも防御にも転用できる高リスクなセキュリティ作業を扱う時に設けている例外制度です。Claude Security や Claude Code のように「何ができるか」を増やす製品機能ではなく、どの利用者がどの範囲の作業を許可されるかに関わる運用ルールとして見るべきです。

ここを混同すると、CVP に入れば Claude Security が使える、あるいは Claude Security を導入すれば利用制限が自動で消える、という誤解が起きます。実際には、製品の提供対象と高リスク作業の許可条件は別の論点です。

この境界線を先に引いておくと、次に見る Claude Security の価値も「新しい制度」ではなく「既存スキャンをどう置き換えるか」という観点で理解しやすくなります。

既存コードスキャンと違う3つの価値

ここからは役割の違いではなく、Claude Security が既存コードスキャンに何を足すのかを見ていきます。大きな差は、広く見つける, 絞って確かめる, 修正につなぐ の 3 段階を一続きで扱う点です。

ルールに当たる箇所を一覧化して終わるスキャンだと、見落としと誤検知の両方が残りやすくなります。Claude Security は scan-to-fix の流れで説明されているため、発見件数よりも「どこまで実務に乗せやすいか」で見る方が価値をつかみやすくなります。

次の 3 章では、repo 全体を見る広さ、多段検証で verified finding に寄せる絞り込み、人間レビューを残した patch handoff を順に確認します。

① 並列repoスキャン

Claude Security の最初の強みは、リポジトリ全体を対象にして関連箇所を横断しながら候補を探せることです。単一ファイルや差分だけを見る review では、設定ファイル、依存関係、呼び出し元と呼び出し先のつながりまで追わないと見えない問題を拾いにくくなります。

この広さがあると、個別行の危なさではなく「どの経路で exploit されるか」をまとめて見やすくなります。導入担当者にとっては、開発者の勘やレビュー担当者の記憶に頼らず、コードベース全体を起点に調べられる点が大きな違いです。

既存スキャナでも広く拾うことはできますが、Claude Security は次の段階でその候補をさらに検証し、実務に持ち込みやすい finding へ絞る流れまで含めています。

② 多段検証

候補を大量に出すだけでは、セキュリティ運用は楽になりません。Claude Security が強調しているのは、見つけた問題を追加で検証し、verified finding として扱えるものに寄せていく点です。

ここが一般的なルールベースのスキャンと違う価値です。誤検知が多いと、結局は人が毎回同じ切り分けを繰り返すことになり、運用コストが下がりません。verified finding に絞る前提があると、担当者は「何件出たか」より「どれから直すべきか」に集中しやすくなります。

つまり Claude Security は、検出精度を魔法のように上げると約束するより、実務で扱える粒度まで候補を絞る運用レイヤーとして評価した方が実態に近くなります。

③ Patch handoff

Claude Security の3つ目の価値は、finding を見つけて終わらせず、修正案を Claude Code 側へ渡して remediation につなげられることです。これにより、スキャン結果が別チケットとして放置されるのではなく、開発フローの中で「直すところ」まで話を進めやすくなります。

重要なのは、ここでも人間レビューが前提だという点です。patch proposal は修正のたたき台として扱い、開発者やレビュー担当者が内容を確認したうえで採用する形になります。完全自動で本番へ反映する仕組みだと受け取ると期待を誤ります。

この scan-to-fix の導線があるからこそ、次の章で見る提供対象や導入フローも、単なるスキャナ追加ではなく既存開発プロセスへの組み込みとして考えやすくなります。

使えるプランと導入の見どころ

ここからは、機能の良し悪しではなく「自社で本当に使い始められるか」を確認します。導入判断で先に見るべきなのは、誰が使えるか, どこから起動するか, 最後の承認を誰が持つか の 3 点です。

Claude Security は話題性だけで追うと期待が先走りやすい製品です。執筆時点では未公開の項目も残っているため、料金や展開時期を断定するより、いま確認できる提供対象と運用フローを押さえる方が判断を誤りにくくなります。

次の 3 章では、提供対象、Claude.ai と Claude Code をどうつなぐか、人間レビューをどこに残すかを順に整理します。

① 提供対象

提供対象については、執筆時点では Claude Enterprise の public beta を中心に見るのが安全です。公式の案内でも、Claude Security はまず Enterprise 向け capability として説明されており、一般ユーザー向けの標準機能とは扱いが違います。

一方で、Team や Max への拡大は coming soon という表現にとどまっています。つまり「近いうちに広がる可能性はある」が、「いつから誰が申し込めるか」まではまだ確定情報として読めません。

そのため導入判断では、まず Enterprise 前提で検討できるかを確認し、Team・Max の話は将来の選択肢として切り分けておくのが現実的です。

② 既存フローへの入り方

既存フローに入れる時の基本形は、Claude.ai 側で repo scan を走らせ、finding を確認し、必要な修正案を Claude Code 側へ渡す流れです。これなら新しい専用運用を丸ごと作るより、今ある triage と remediation の間に Claude Security を差し込みやすくなります。

ポイントは、scan と修正作業の場所が分かれていることです。Claude Security で全体発見を行い、実際の修正は開発者が慣れている Claude Code や既存レビュー手順の中で扱うと、チーム全体の流れを崩しにくくなります。

導入時は「誰が first review をするか」「どの finding を開発チームへ渡すか」を先に決めておくと、検出結果が宙に浮きにくくなります。

③ 人間レビューの残し方

Claude Security を導入しても、最終判断まで自動化する前提にはしない方が安全です。verified finding は優先度を付けやすくする材料であり、patch proposal は修正のたたき台なので、どちらも人が確認して採用する運用が基本になります。

ここを曖昧にすると、検出精度への期待と責任分界がずれます。たとえば、セキュリティ担当が finding の妥当性を見て、開発者が patch の実装影響を確認する、と役割を分けておくとレビューしやすくなります。

つまり Claude Security は、人間レビューをなくす仕組みではなく、人間が見るべき候補と修正ポイントを絞り込むための支援として置くのが現実的です。

safeguardsとCVPの関係

ここで残る疑問は、「正当な防御用途なのに、なぜ通常の Claude や Claude Code では止まることがあるのか」です。答えは、製品の便利さとは別に real-time cyber safeguards と CVP という利用制御の層があるからです。

Claude Security だけを見ると製品の役割は理解できますが、通常セッションで同じことをしようとした時の制限までは見えません。safeguards と CVP を合わせて読むと、Anthropic が製品機能と、攻撃にも防御にも転用できる高リスク作業の許可を別レイヤーで扱っている理由が整理しやすくなります。

次の 2 章では、通常の Claude が止まり得る理由と、CVP が必要になる場面を切り分けます。

① なぜ通常のClaudeは止まるか

通常の Claude や Claude Code が止まり得るのは、real-time cyber safeguards が攻撃にも防御にも転用できるリスクを見ているからです。つまり、防御目的であっても、依頼内容や操作の組み合わせによっては高リスクなサイバー支援と区別しにくくなり、標準セッション側で制限がかかる可能性があります。

ここで大事なのは、これは Claude Security の不具合ではなく 標準利用の安全制御 だという点です。読者が「同じ Anthropic 製なのに片方は案内され、片方は止まる」と感じるのは自然ですが、実際には見ているレイヤーが違います。

そのため、高リスク寄りの防御作業を通常の対話や terminal セッションだけで安定運用しようとすると、想定外の停止にぶつかることがあります。

② CVPが必要になる場面

CVP が関係してくるのは、通常の safeguards では止まりやすい、攻撃にも防御にも転用できる高リスク寄りの防御作業を正当な用途として扱う必要がある場面です。ここでの論点は「製品を契約できるか」ではなく、「標準制限を超える作業をどの条件で認めるか」にあります。

そのため、CVP は Claude Security の代替でも追加機能でもありません。Claude Security を使うかどうかと、CVP が必要かどうかは別に判断する必要があります。

導入担当者は、通常の repo scan と remediation で足りるのか、それとも高リスクな防御研究まで含むのかを切り分けると、どこで CVP を検討すべきか見えやすくなります。

よくある疑問

まとめ

Claude Security を理解する時は、まず役割を切り分けると迷いにくくなります。

次に動くなら、自社が知りたいのが「コードベース全体の発見」なのか「いまの変更のレビュー」なのかを先に決めてください。そのうえで、Enterprise 前提で検討するのか、通常セッションでは止まりやすい高リスク作業まで含むのかを分けると、導入判断がかなりしやすくなります。

製品名と制度名を同じ箱に入れずに見ることが、Claude Security を正しく評価する最短ルートです。