Anthropic が Cyber Verification Program を拡張 — Project Glasswing を統合し3段階のアクセス階層へ、OSS メンテナーと個人研究者も対象に
Anthropic が 2026-10-06 に Cyber Verification Program(CVP)を拡張した。従来別枠だった Project Glasswing と CVP を1つに統合し、Defense Access / Red Team Access / Specialized Access の3段階を設けた。対象モデルは Claude Opus 5.5 / Sonnet 5.5 / Mythos 5.1 と今後の新モデルで、階層に応じてサイバー関連のブロック用分類器が緩和される。Defense Access は企業・非営利・大学・政府機関・重要インフラ事業者・小規模セキュリティ企業・OSS メンテナー、および脆弱性報告実績のある個人研究者まで対象に含む。Red Team Access は組織のみで個人は対象外、Specialized Access は飛行制御 OS や電力系統などを扱う限定数の組織で、米国政府との協働で審査する。回答は Defense Access が数日、Red Team Access が数週間。
ニュース原文を読む ↗要約
Anthropic が Cyber Verification Program(CVP) を拡張しました。従来別枠で動いていた Project Glasswing と CVP を1つのプログラムへ統合し、3段階のアクセス階層を設けています。
この発表の前提を理解するには、一般提供のモデルで何が起きているかを知る必要があります。 Claude の一般提供モデルには保守的なセーフガードが掛かっており、サイバー関連の作業は大半がブロックされます。 脆弱性の解析、攻撃コードの読解、ペネトレーションテストの支援——正当な防御業務であっても、要求が止まります。 セキュリティ部門が「使えない」と判断する典型的な原因がここです。
CVP は、そのブロックを階層ごとに緩めるための検証プログラムです。 今回の拡張で、対象モデルが Claude Opus 5.5 / Claude Sonnet 5.5 / Claude Mythos 5.1、および今後の新モデルへ広がりました。従来の Mythos 系に限られていた状態から、日常的に使う Opus / Sonnet が対象に入ったのが実務上の変化です。
階層は3つです。
Defense Access は最も広い階層です。企業・非営利団体・大学・政府機関・重要インフラ事業者・小規模セキュリティ企業・OSS メンテナー、そして脆弱性報告の実績がある個人研究者まで含みます。個人が対象に含まれる階層はここだけです。 ただし攻撃的シナリオには依然として強いブロックが残ります。
Red Team Access は、社内レッドチーム、政府のレッドチーム、authorized な敵対的テストを行うペネトレーションテスト企業が対象です。組織のみで、個人は対象外と明記されています。この階層では、authorized なペネトレーションテストに対するブロックが外れます。
Specialized Access は、飛行制御 OS、電力系統、通信網といった safety-critical なシステムのテストを認められた、限定数の検証済み組織です。現時点では米国政府との協働で審査しています。最もブロックの少ない状態です。
申請は CVP のポータルから行います。回答までの目安は、Defense Access が数日、Red Team Access が数週間、Specialized Access は政府との詳細な協働が入ります。
整理すると、「安全側に倒した既定値」と「検証した相手には緩める経路」を分けた設計です。 一般提供のモデルを緩めるのではなく、検証を通した相手にだけ緩める。 セキュリティ用途に強いモデルを公開することと、悪用を抑えることを両立させる手段として、プログラムによる本人確認と用途確認に寄せた形です。
何が変わったか
- Project Glasswing と CVP を統合し、1つのプログラムに整理した(2026-10-06)
- 3段階のアクセス階層を新設
- Defense Access: 企業・非営利・大学・政府機関・重要インフラ事業者・小規模セキュリティ企業・OSS メンテナー・脆弱性報告実績のある個人研究者。攻撃的シナリオには強いブロックが残る
- Red Team Access: 社内レッドチーム、政府レッドチーム、authorized なペネトレーションテスト企業。組織のみ(個人は対象外)。authorized なペンテストのブロックが外れる
- Specialized Access: 飛行制御 OS・電力系統・通信網などの safety-critical システムを扱う限定数の検証済み組織。米国政府との協働で審査。最もブロックが少ない
- 対象モデルが Claude Opus 5.5 / Claude Sonnet 5.5 / Claude Mythos 5.1 と今後の新モデルへ拡大
- 一般提供モデルは保守的なセーフガードでサイバー作業の大半がブロックされることが明示された
- 階層に応じてブロック用の分類器が緩和される
- 回答の目安: Defense Access は数日、Red Team Access は数週間
業務インパクト(一般企業向け)
セキュリティ部門が「Claude は使えない」と結論を出している組織は、その結論の根拠を確認し直す価値があります。
「脆弱性の調査を頼んだら断られた」という経験は、モデルの能力不足ではなく、一般提供モデルのセーフガードが原因です。この区別は、ツール選定の判断を変えます。 「能力がない」なら他社製品を探す話になりますが、「申請すれば緩和される」なら手続きの話です。
自社がどの階層に当たるかの判断が、最初の作業です。 判断を誤ると申請が通りません。自社のセキュリティチームが脆弱性の調査・修正をしているだけなら Defense Access です。社内レッドチームとして authorized な敵対的テストをしているなら Red Team Access で、こちらは組織としての申請になります。 「個人のセキュリティエンジニアが Red Team Access を取る」という経路は公式に閉じています。
重要インフラ事業者は、Specialized Access の存在を知っておくべきです。 電力・通信・交通のような領域で safety-critical なシステムを扱っている場合、最もブロックの少ない階層が用意されています。 ただし米国政府との協働審査が入るため、日本の事業者にとって現実的な経路かは個別確認が必要です。ここは公式の記述だけでは判断できません。
審査のリードタイムを計画に入れてください。 Defense Access が数日、Red Team Access が数週間です。「来月のペネトレーションテストで使いたい」という計画なら、今月中に申請しないと間に合いません。 セキュリティ予算の年度計画にツール導入を組み込む場合、審査期間を工程として明示してください。
ガバナンス面では、緩和されたアクセスを誰が使うかの管理が必要になります。 ブロックが外れるということは、止めてくれていた仕組みが止まらなくなるということです。Red Team Access を取得した組織では、「authorized なテストの範囲」を社内で定義し、記録する体制が前提になります。プログラムの審査を通ったことは、社内で何でもしてよい理由にはなりません。 申請時に説明した用途と、実際の利用の整合を取る責任は組織側に残ります。
OSS を使っている組織は、メンテナーが対象に入った点に注目してください。 自社が依存している OSS のメンテナーが Defense Access を使えるなら、依存ライブラリの脆弱性修正が速くなる可能性があります。 これは自社が何かをする話ではありませんが、サプライチェーンの安全性に間接的に効きます。
副業・個人活用視点
個人にとって現実的な入口は Defense Access だけです。 ここを正確に押さえてください。
Red Team Access は組織のみで、個人は対象外と公式に書かれています。フリーランスのペネトレーションテスターが単独で申請する経路はありません。 ペンテスト企業に所属するか、法人として申請するかのどちらかです。この制約を知らずに申請して時間を使うのは無駄です。
Defense Access で個人が対象になる条件は「脆弱性報告の実績」です。 これは今から積める実績です。バグバウンティでの報告、OSS への脆弱性報告、CVE の取得——実績があれば個人研究者として対象に入ります。 逆に言えば、実績のない状態で申請しても通りません。 セキュリティ領域で個人として仕事をしたいなら、報告実績が資格要件そのものになっているということです。
OSS メンテナーが明示的に対象に入ったのは、副業の観点では大きいです。 自分がメンテナンスしているライブラリがあるなら、それが申請の根拠になります。 OSS の維持は収益に直結しにくい活動ですが、こういう形で間接的な見返りが付き始めています。 「OSS を書いていると何が得なのか」に、具体的な答えが1つ増えました。
セキュリティ相談の受け方にも使えます。 中小企業から「AI で脆弱性診断できますか」と聞かれたとき、**「一般提供のモデルでは止まります。防御目的の正規プログラムがあり、企業として申請できます。回答は数日です」**と答えられるのは、調べて答える人と、知っていて答える人の差です。そして申請支援そのものが仕事になります。 申請書に「自社がどの階層に当たるか」「どの用途で使うか」を書く作業は、セキュリティの文脈を理解している人でないと書けません。
気をつけるべきは、緩和を「何でもできる」と説明しないことです。 Defense Access でも攻撃的シナリオには強いブロックが残ります。「CVP を通せば制限がなくなる」と説明すると、導入後に期待と違う結果になります。 階層ごとの差を正確に伝えるのが、この領域での最低限の誠実さです。