2026年2月20日、セキュリティ関連の株が一斉に売られた。CrowdStrike、Okta、Cloudflare、Palo Alto Networks——軒並み8〜10%の下落。JFrogにいたっては約25%の下落だ。理由はたった一つ、Anthropicが「Claude Code Security」を発表したからだ。
AIが脆弱性を見つける。それだけのことで、なぜセキュリティ企業の株がこれほど売られたのか。この記事では、Claude Code Securityが実際に何をやってのけたかを解説し、バイブコーディングで開発をしている人間が何を意識すべきかを伝える。
何が起きたのか
2026年2月20日、AnthropicはClaude Code Securityを発表した。EnterpriseおよびTeamプラン向けの限定リサーチプレビューとして提供が始まり、OSSのメンテナーには優先的なアクセスが提供される。
発表と同時に公開されたリサーチが衝撃的だった。Claude Opus 4.6を用いてOSSコードベースから500件以上の重大なゼロデイ脆弱性を発見したというのだ。数十年間、専門家のコードレビューをくぐり抜け続けてきたバグが含まれていた。
ゼロデイとは何か
「ゼロデイ」という言葉を整理しよう。ソフトウェアには必ずバグがある。問題は「そのバグが誰に知られているか」だ。
- 開発者が知っていて修正済み → 問題なし
- 開発者が知っていてパッチを準備中 → 使えるが対処可能
- 誰も知らない（あるいは攻撃者だけが知っている） → ゼロデイ脆弱性
「ゼロデイ」の名前の由来は「修正のための猶予期間がゼロ」だ。開発者が気づいていないうちに攻撃者だけが知っている状態は、防御側にとって最悪の状況になる。対処できない穴で攻撃される。今回Claudeが発見したのは、まさにその「誰も気づいていなかった穴」が500件超だ。
従来のツールとは何が違うのか
セキュリティツールの世界に「SAST（静的解析ツール）」というものがある。コードを実行せずに問題を探す仕組みで、Semgrepなどがその代表例だ。
SASTの動き方は「手配書チェック」に近い。警備員が入場者全員を手配書のリストと照合する。リストに載っている手口の犯罪者は止められる。しかし、リストにない新しい手口を使ってきた人間は素通りしてしまう。
SASTはあらかじめ定義されたルールに従って「既知の危険なパターン」を検出する。strcpyは危険、SQLを直接組み立てるのは危険、といった具合に。ルールにないパターンには対応できない。
Claude Code Securityは違う。コード全体を「人間のセキュリティ研究者のように推論」する。
- コンポーネント間の相互作用を理解する
- データフローをファイルを横断して追跡する
- ビジネスロジックの欠陥を検出する
さらに「多段階検証（Adversarial Verification）」という仕組みを使って、自分の発見を自ら反証しようとする。「本当にこれは脆弱性か？」と自問することで偽陽性（本当は問題ないのに問題と判定する誤り）を減らす。
ただし、正直に言っておく。Semgrepの独立評価では、Claude Codeは46件の脆弱性を報告したが真陽性率は14%、偽陽性率は86%だった。専門家の結論は「置き換え」ではなく「SASTの上に推論レイヤーを追加する」という使い方だ。
実際にどう見つけたか——3つの具体例
抽象的な話だけでは実感が湧かないと思うので、具体的な発見事例を見ていこう。
① CGIF——「圧縮は必ず小さくなる」という思い込み
CGIFはGIFファイルを扱うライブラリだ。その中に「ヒープバッファオーバーフロー」と呼ばれる脆弱性があった。
LZWという圧縮アルゴリズムを使っているこのライブラリには、「圧縮後のデータは必ず圧縮前より小さい」という暗黙の前提があった。直感的には正しそうに見える。ファイルを圧縮したら小さくなるはずだ、と。
しかし例外がある。LZWのシンボルテーブルが満杯になり、クリアトークンが挿入される特定の条件下では、出力サイズが入力を超えることがある。その状況を想定せずバッファを確保していたため、オーバーフローが発生する。この「ほぼ起きない、でも起きる」シナリオは、カバレッジ100%のファジング（大量のランダム入力でテストする手法）でも検出できなかった。Claudeは仕様を理解した上でその想定外を考えた。
// ❌ CGIFの脆弱なコード（概念）
// 「圧縮後サイズ ≤ 圧縮前サイズ」という誤った前提で確保
char compressed_buf[input_size];
lzw_compress(input, compressed_buf); // 特定条件でバッファを超過する
// ✅ 正しい実装
// 最悪ケースのバッファサイズを計算してから確保する
size_t max_compressed = calculate_max_lzw_output_size(input_size);
char *compressed_buf = malloc(max_compressed);
lzw_compress(input, compressed_buf, max_compressed);
② GhostScript——「修理記録を読んで推測する」
GhostScriptはPDFやPostScriptを処理するライブラリで、多くのシステムで使われている。ここで見つかった脆弱性の発見方法が特にユニークだった。
Claudeは、通常のファジングや手動解析ではなく、Gitのコミット履歴を読んだ。そこに「スタックバウンズチェックの追加」というコミットがあった。
自動車の修理記録に「ブレーキを強化した」と書いてあったら、「修理前はブレーキが弱かった」と推論できる。そして、同じ設計の他の箇所にも同じ弱点があるはずだ、と。Claudeはそれをやった。「このコミットが修正した問題の前後に、類似の問題が周辺コードに残っていないか」を推論し、バウンズチェックが欠落した別のコードパスを発見した。悪意あるPDF文書によって悪用可能な脆弱性だった。
③ OpenSC——「3回連続の連結は危険」
OpenSCはスマートカードを扱うユーティリティだ。発見された脆弱性は「連続したstrcatによるバッファオーバーフロー」だ。
strcatはC言語で文字列を結合する関数で、長さチェックをしない危険な関数として知られている。SASTであれば単体のstrcatを見て警告を出す。しかしOpenSCのケースは、3つのstrcatが連続して使われており、その組み合わせの文脈を理解しないと脆弱性として認識できなかった。
// ❌ OpenSCの脆弱なコード（概念）
// 3連続のstrcat——SASTは「危険な関数」と警告するが、組み合わせの文脈は読めない
char url[256];
strcat(url, base_path);
strcat(url, user_input); // user_inputが長すぎると…
strcat(url, extension); // ここでバッファオーバーフローが発生する
// ✅ 安全な実装
char url[256];
// snprintfはサイズを指定するため、オーバーフローが起きない
snprintf(url, sizeof(url), "%s%s%s", base_path, user_input, extension);
ファジングでこのコードパスに到達することは困難だった。Claudeは「危険な関数の使われ方」をコードベース全体で検索し、3連続という文脈でその危険性を判断した。こちらもメンテナーによって修正済みだ。
なぜセキュリティ株が暴落したのか
- CrowdStrike（CRWD）: 約 -8〜10%
- Okta（OKTA）: 約 -9%
- Cloudflare（NET）: 約 -8〜10%
- Palo Alto Networks（PANW）: 約 -10%以上
- JFrog: 約 -25%（最大の下落）
- Global X Cybersecurity ETF: -3.8%
市場の懸念はシンプルだ。「AIが脆弱性を自動で見つけられるなら、人間のセキュリティ専門家が要らなくなるのではないか」「脆弱性スキャンを製品として売っている会社のビジネスが崩壊するのでは」という連想だ。
しかし、アナリストの評価は異なった。Barclaysは「不合理な売り込み（illogical）」と評し、CrowdStrike・SailPoint・Cloudflare・Palo Alto Networksのビジネスとは直接競合しないと主張した。Jefferiesのアナリストも「短期的な逆風はあるが、サイバーセキュリティはAIから最終的に恩恵を受ける」と述べた。Morningstarもこの見方を支持している。
CrowdStrike CEO の George Kurtz は LinkedIn で自社の競合優位性を主張した。直接 Claude に「CrowdStrike の代替になるか」と質問したところ「ならない」と回答したことも報告している。
医師免許を取れるAIが登場したからといって、病院が不要になるわけではない。市場の反応はそれに近い過剰反応だった、というのが専門家の見立てだ。
攻守は表裏一体だ
Claude Code Securityには、解決困難な矛盾がある。脆弱性を「発見する推論力」は、「攻撃者が悪用する際の推論力」と同じだ。防御側にも攻撃側にも使えるツールを出すことへの懸念は当然ある。
Anthropicは最新モデルに新たな安全制御を追加し、悪用の試みをリアルタイムで検知する仕組みを組み込んだと説明している。
しかし、それと同時にもう一つの事実も存在する。AIが生成するコードには脆弱性が含まれやすい。AIが守る側になる一方で、AIが生み出すコードが新たな攻撃対象を増やしている。Enkrypt AIのCSO、Merritt Baerはこう指摘している。「本当の転換点はパターンマッチングから仮説生成へのシフトだ。これは発見能力の段階的な向上であり、同様に強力な人間的・技術的コントロールを求める」。
バイブコーダーが知っておくべきこと
バイブコーディングでアプリを作っている人間にとって、この話は他人事ではない。
まず確認しておこう。AIが生成するコードは脆弱性を含む可能性が高い。AIは機能を動かすことに最適化されていて、セキュリティの考慮は後回しになりやすい。「動いた！」で終わらせると、穴が残ったままになる。
Claude Code Securityが「守る側のAI」として機能するのは歓迎すべきことだ。しかし現時点では、EnterpriseおよびTeamプラン向けの限定リサーチプレビューであり、誰でもすぐに使えるわけではない。攻撃者もAIを持つ時代に、防御側が今すぐできることは変わらない。
- コードレビューを人間が行う: AIが書いたコードをそのままマージしない
- 既存のSASTツールを使う: 完璧ではないが、ルールベースの検出は今も有効だ
- 依存ライブラリを最新に保つ: CGIFやOpenSCの脆弱性のように、ライブラリ側の問題も存在する
- 「動いた」で終わらせない: セキュリティは機能開発と並行して考える
Claude Code Securityが発見したような深い脆弱性は、ほとんどのバイブコーダーが自分では気づけない種類のものだ。このツールはまだ限定提供中だが、それを待つよりも基本的なセキュリティ習慣の方が今すぐ役に立つ。
終わりに
築50年のビルを耐震診断にかけたら、欠陥が500件見つかった。「今まで問題がなかった」のではなく、「今まで気づかれていなかっただけ」だ。
Claude Code Securityが示したのは、AIが「別の目」を持つ存在として機能し始めたという事実だ。人間のセキュリティ研究者が何週間もかける調査を——コードを読んで、コミット履歴を解釈して、仮説を立てて、反証する——という形で自動化した。
セキュリティ株の暴落は過剰反応かもしれない。しかし「AIが守る側に立てる」という事実は本物だ。そして同時に、「AIが生み出すコードは脆弱かもしれない」という矛盾もまた本物だ。
バイブコーディングの時代に「コードを書かなくていい」は現実に近づいている。しかし「セキュリティを考えなくていい」は、まだ来ていない。