![Claude Codeの[cyber]セーフガード誤検知、CVP承認済みでも直らない件を整理した](/_astro/thumb-claude-code-cyber-safeguard-false-positive-2026.C9RRbIYf_ZvxvOu.webp)
Claude Codeの[cyber]セーフガード誤検知、CVP承認済みでも直らない件を整理した
Claude Codeでセキュリティ系の作業中に「safeguards flagged」[cyber]エラーが頻発中。公式ドキュメントとGitHub Issueを突き合わせ、CVP申請の手順・v2.1.280以降の回帰・回避策までまとめた。
エンジニアのゆとです。
Xのタイムラインで、Vimのプラグイン開発者としても有名なmattnさんが「Claude CodeはOSSの脆弱性報告を検証させると危険を察知して自動で止まる仕様になっていて、Cyber Verification Program(CVP)に申請すると解除される」って呟いてるのを見かけた。今朝申請が通った、と。
何の話だろうと思ってGitHub Issueを覗きに行ったら、想像より事態が深刻だった。「safeguards flagged」「[cyber]」というワードで検索すると、issueの数がすでに1,000件を超えている。しかもここ数日だけで一気に増えていて、CVPに承認された組織のユーザーまで巻き添えでブロックされてる報告まで出ていた。
セキュリティ検証・脆弱性調査・バグバウンティ絡みの作業をClaude Codeでやってるフリーランスや個人開発者には他人事じゃない話なので、公式ドキュメントとissueを突き合わせて、何が起きてて、どう対処すればいいのかを整理しておく。
「セーフガードが作業をブロックする」とはどういう現象か
Claude Codeを使っていて、こんなメッセージで作業が止まった経験がある人がこの記事の対象だ。
API Error: Opus 5.5's safeguards flagged this session (https://www.anthropic.com/legal/aup).
You may be seeing this for the first time on an Opus model: Opus 5.5 is more capable and has
stronger safeguards as a result, which can sometimes flag non-cybersecurity work.
Details: `[cyber]`[cyber]というタグがついているのがポイントで、これはAnthropic側の「リアルタイムのサイバーセキュリティ関連セーフガード」が発火したことを示すラベルだ。プロンプトインジェクション対策や有害コンテンツフィルタとは別枠で、Claude Opus・Sonnetに組み込まれている自動検知システムになる。
厄介なのは、このセーフガードが「本当に危険なリクエスト」だけでなく、脆弱性診断・ペネトレーションテスト・EDR(エンドポイント検知)ツールの開発・ファームウェアのバグ修正といった、正当な防御目的の作業まで巻き込んで止めてしまう点だ。しかも一度セッション単位でフラグが立つと、そのセッションの以降のやり取りが軒並みブロックされることもある。
実際に報告されている誤検知パターン
GitHub Issueを眺めていると、誤検知のバリエーションがかなり広いことがわかる。ここ数週間で報告されている代表的なケースを並べてみる。
| 作業内容 | 誤検知の様子 |
|---|---|
| マイクロコントローラのバッファオーバーフロー修正 | ファームウェアのメモリ安全性バグを直しているだけなのに[cyber]でブロック |
| バックグラウンドコマンドの完了通知 | ユーザーの発言ではなく「exit code 0」というツール完了メッセージそのものがトリガーになった |
| ポルトガル語の挨拶「ola」 | ただの「こんにちは」というテキストがサイバー脅威として誤分類された |
| DNSエクスフィルトレーションの解説 | 攻撃手法を教育目的で説明しただけでポリシー違反扱い |
| バグバウンティでのHackerOne/Intigriti向け検証作業 | CVP承認済みのはずのアカウントでもv2.1.280更新後にブロックが再発 |
共通しているのは、実際に悪意のあるコードを書かせようとしたわけでも、攻撃を実行しようとしたわけでもないという点だ。「セキュリティ」という単語や、脆弱性・攻撃手法に関連する語彙が会話に含まれているだけで、文脈を無視して機械的に引っかかっているケースが目立つ。
なぜ起きるのか — Prohibited useとHigh-risk dual-useの違い
Anthropicの公式ヘルプセンターの説明を読むと、このセーフガードは対象を2つのカテゴリに分けて扱っている。
1つ目が「Prohibited use(禁止用途)」。マスデータの窃取やランサムウェアの開発など、防御目的の正当な使い道がほぼ存在しない用途で、これはCVPに承認されていても解除できない。
2つ目が「High-risk dual-use(高リスクのデュアルユース)」。脆弱性の悪用検証や攻撃的セキュリティツールの開発のように、攻撃にも防御にも使える性質を持つ作業で、こちらはデフォルトでブロックされるものの、Cyber Verification Programの承認があれば制限を解除できる対象になる。
つまり設計思想としては「本当にヤバいものは審査があっても通さない、グレーゾーンの防御作業だけ審査制で開放する」という2段構えだ。理屈は理解できるが、実際の分類はモデルの自動判定に委ねられているので、文脈の読み違いによる誤検知(false positive)がどうしても発生する。Anthropic自身も「意図的に広めに設計している分、正当なサイバーセキュリティ作業を誤って止めることがある」と認めている。
公式ドキュメントと実態が食い違っている点
ここが今回いちばん気になった部分だ。公式ヘルプセンターの「Real-Time Cyber Safeguards on Claude Opus and Sonnet」というページには、こう明記されている。
These safeguards do not apply to Claude Opus 5.5, though expansion to that model and Mythos class is planned. (これらのセーフガードはClaude Opus 5.5には適用されない。ただし同モデルおよびMythosクラスへの拡大は計画中)
つまり公式ドキュメント上は「Opus 5.5はまだ対象外」ということになっている。ところが実際にGitHub Issueを見ると、直近数日だけでも「Opus 5.5’s safeguards flagged this session」という、Opus 5.5を名指ししたエラーメッセージの報告が何十件も上がっている。
考えられるのは、ドキュメントの更新が追いついていないか、あるいは段階的なロールアウトがすでに一部ユーザー・一部組織に対して始まっているかのどちらかだ。どちらにせよ、「自分のモデルは対象外のはずだから関係ない」と思い込んでいると、実際にブロックされたときに原因の切り分けで無駄に時間を使うことになる。Opus系を使っている以上、このセーフガードは他人事ではないと考えておいたほうがいい。
v2.1.280以降、CVP承認済みでもブロックされる回帰が起きている
[cyber]関連のissue自体は今年の春先から継続的に報告されている、いわば「昔からある問題」だ。ただし直近で報告が急増している背景には、もう一段具体的な引き金がある。
GitHub Issue #96090では、CVP(Cyber Verification Program)にすでに承認されている組織のユーザーが、Claude Codeをv2.1.228からv2.1.280にアップデートした後から急に[cyber]ブロックを受けるようになったと報告されている。本人はHackerOneやIntigritiでのバグバウンティ業務でOpusを使っていて、CVP経由で本来なら制限が解除されているはずの作業だ。この報告は「duplicate(重複)」として即クローズされており、同種の報告が他にも複数上がっていることを示している。
似た構図の報告は今年4月の時点でも存在していて(「Cyber Use Case Exemption Granted and works with Claude Chat but still keep getting FPs…」というissueなど)、CVPの承認が組織のAPI利用全体に均一に反映されない、あるいはバージョンアップのたびに再発するという構造的な弱さが繰り返し指摘されている状態だ。「一度CVPを通したから安心」と思っていると、アップデートのタイミングで急に足元をすくわれる可能性がある。
対処法1: Cyber Verification Program(CVP)に申請する
正攻法はCVPへの申請になる。公式ヘルプセンターの情報をもとに、要点を整理するとこうなる。
- 無料の申請制プログラムで、本人確認(アイデンティティ検証)が必要
- 審査は通常2営業日以内に完了する
- 対象はOpus・Sonnetのみ(申請時点でOpus 5.5は対象外という位置づけだが、前述の通り実態と食い違っている可能性がある)
- Zero Data Retention(ZDR)契約のユーザーは現状申請対象外
- Amazon Bedrock経由ではまだ利用できない
- サードパーティ経由(社内プラットフォーム等)の場合、そのプラットフォームが対応していないと申請しても意味がない
申請経路は、使っている環境によって窓口が変わる。
| 利用環境 | 申請先 |
|---|---|
| Claude.ai / Claude Code / Anthropic API / BYOK | Verification Portal(portal.anthropic.com/programs/cvp) |
| Microsoft Foundry | Cyber Use Case Form(「Azure」を選択) |
| AWS Claude Platform | Verification Portal(AWS向けリンク) |
| Google Cloud | Verification Portal + データ保持を有効化 |
| 上記以外のサードパーティ | プラットフォーム側に直接問い合わせ |
承認されると「Prohibited use」以外のdual-use活動のブロックが解除される。ただし承認は組織ID単位で紐づいていて、別のワークスペースやAPIキーには引き継がれない。個人利用と会社アカウントを使い分けている人は、申請したはずのアカウントで作業しているか、/statusやClaude Consoleで確認しておいたほうがいい。
対処法2: 申請前・承認待ちの間にできる回避策
CVPの審査には最短でも1〜2営業日かかる。納期のある案件でその場しのぎが必要な場合、次の順番で試すのが現実的だ。
/modelで別のモデルに一時的に切り替える。エラーメッセージ自体が「try a different model with/model」と案内している通り、モデルによって判定のしきい値が異なる- Double Escでプロンプトを編集し、攻撃的なニュアンスの語彙(exploit、attack、bypassなど)を防御的な言い回し(remediate、patch、audit、verify)に置き換えて再送する
- 作業を細かいステップに分割する。「バッファオーバーフローを直して」ではなく「このコードのメモリ安全性を確認して」「該当箇所を修正して」のように分けると、まとまった文脈での誤爆を避けやすい
/feedbackコマンドで実際に誤検知の内容を報告する。Anthropic側もモデルの精度改善に使っている
どれも根本解決ではなく応急処置なので、恒常的にセキュリティ関連の作業をするなら結局CVP申請が本筋になる。
CVP承認済みなのに直らないときのチェックリスト
前述の通り、CVPを通していてもブロックが再発するケースがある。公式ドキュメントのトラブルシューティング項目と、issueで報告されている実例を踏まえると、確認すべき順番はこうなる。
- 承認メールに記載されている組織IDと、実際にClaude Codeで使っているログイン先(個人アカウントかteamアカウントか)が一致しているか
- 直前にClaude Codeをアップデートしていないか。していれば、アップデート後から発生しているのか(=リグレッションの可能性)、元々だったのかを切り分ける
- ブロックされている作業が本当に「dual-use」の範囲か。マスエクスフィルトレーションやランサムウェア開発に近い内容だと、CVP承認があっても「Prohibited use」として弾かれ続ける
- Claude.ai / Claude Code / APIなど、利用しているアクセス経路とCVP申請時の経路が一致しているか(Bedrock経由は現状対象外)
これで解決しない場合は、単発の誤検知ではなくAnthropic側の不具合(リグレッション)の可能性が高い。
誤検知だと思ったら、報告して終わりにしない
「これは絶対に正当な防御作業なのに止められた」と確信できる場合は、公式のfalse-positive報告フォームから異議申し立てができる。CVP申請の却下に対する再審査もこのフォームが窓口になっている。
Issue上での報告も無駄ではないが、GitHub Issueは基本的にバグの共有・追跡が目的で、個別の申請却下やアカウント単位のフラグ解除には直接効かない。「直してほしい」だけならissueに書けばいいが、「自分の作業が止まっている状態を早く解消したい」なら、公式フォーム経由で報告するほうが確実だ。
FAQ
CVPに申請すれば絶対にブロックされなくなる?
いいえ。Prohibited use(マスエクスフィルトレーション、ランサムウェア開発など)に該当する内容は、CVP承認があっても引き続きブロックされる。CVPが解除するのはあくまでHigh-risk dual-use(脆弱性検証、攻撃的セキュリティツール開発など)の範囲だけだ。
Claude.aiでは通るのにClaude Codeだけブロックされるのはなぜ?
CVPの承認は組織ID単位で紐づくが、アクセス経路(Claude.ai / Claude Code / API)ごとに反映のタイミングやスコープがずれることが実際に報告されている。同じ組織・同じアカウントのつもりでも、Claude Codeで使っている認証情報がCVP承認時と別物になっていないか、/statusで確認する価値がある。
Sonnetに変えれば[cyber]エラーは出ない?
出なくなる保証はない。セーフガードはOpus・Sonnet双方が対象になっており、モデルによって判定のしきい値が異なるだけだ。ただしissueの報告を見る限り、Opus系(特にOpus 5.5)でのブロック報告が直近は目立っている。
この問題はいつ解消される?
Anthropicはエラーメッセージ内で「We’re improving these safeguards to reduce the amount of incorrectly flagged messages(誤検知を減らすよう改善中)」と明言しているが、具体的な時期は示されていない。GitHub Issueの動向を見る限り、v2.1.280前後で悪化した経緯があるため、次のアップデートで改善されるか、逆に別の形で再発するかは実際にバージョンを追って確認するしかない。
セキュリティ絡みの作業をClaude Codeでやっているフリーランス・個人開発者にとっては、納期のある案件の途中でこれに当たると地味に痛い。CVP自体は無料で数日で結果が出る申請なので、脆弱性診断やバグバウンティを継続的にやる予定があるなら、実際にブロックされる前に申請しておくのが一番の予防策になる。
