AnthropicがClaude Code Securityを発表。業界にとって朗報である理由
0 分で読めます
要約：慌てる必要はありません。新しいClaude Code Securityは、業界の進む方向を明確に裏付けています。アプリケーションセキュリティの重要性を示す、強力なシグナルです。全体像を知りたい方は、同僚の記事をご覧ください。この記事では、もう少し深く掘り下げます。
Anthropicは、コードベースをAIでスキャンしてセキュリティ脆弱性を検出し、修正パッチを提案する新機能Claude Code Securityを発表しました。最近のセキュリティ業界の動向を追っている方なら、すでにさまざまな反応を目にしたことでしょう。サイバーセキュリティ関連株は下落。評論家たちは、セキュリティベンダーの終わりの始まりだと主張しています。特に拡散した投稿では、AnthropicがAppSec業界を丸ごと食い物にしたとまで言われました。
その熱狂はよくわかります。デモは見事です。Opus 4.6は、オープンソースのコードベースから、専門家によるレビューを受けながらも何十年も見つからなかったバグを含む、未知のゼロデイ脆弱性を500件以上発見しました。CGIFライブラリでは、ClaudeがLZW圧縮アルゴリズムを推論してヒープバッファオーバーフローを発見。従来のカバレッジガイド型ファジングでは、コードカバレッジが100%でも検出できなかった問題です。これは大きな進歩です。
しかし、話題の論評は木を見て森を見ずです。実際のところ、「AIがセキュリティツールに取って代わる」という話よりも、はるかに複雑で興味深い現実があります。
反応が見落としたこと、そしてアーキテクチャが裏付けたこと
主流の見方はこうです。「Anthropicが脆弱性を見つけるAIを開発した。だから従来のセキュリティツールは時代遅れだ」。これは、「優れた火災報知器を開発したから、消防署はもう必要ない」と言うようなものです。
脆弱性の発見は重要です。しかし、難しいのはそこではありません。
もう一度言います。後ろの席の皆さんにも聞こえるように。脆弱性を見つけることは、これまで難題ではありませんでした。
AppSecチームを夜も眠れなくさせ、何年も解消されないバックログや「次のスプリントで対応します」というやりとりを生む、本当に難しいのは脆弱性を修正することです。しかも、大規模に、何百ものリポジトリにわたって、何も壊さずに。開発者が猛スピードで新機能をリリースする中で、自分が書いていないコードや選んでいないライブラリ、詳しいとは限らない言語を扱いながらです。
セキュリティチームで働いたことがある方なら、よくご存じでしょう。ワークフローはおおむね次のようになります。
セキュリティツールが脆弱性を検出
セキュリティチームが検出結果をトリアージし、優先順位を付ける
セキュリティチームがチケットを作成し、開発者に割り当てる
開発者が3スプリント後にチケットを確認する
開発者が脆弱性とその背景を理解しようとする
開発者が修正を試み、その過程で別の問題を持ち込むこともある
セキュリティチームが再スキャンし、同じことを繰り返す
このサイクルがAppSecの専門家を疲弊させ、開発者を苛立たせます。AIを活用するかどうかにかかわらず、スキャンの精度を高めても、この根本的なループは解消されません。結局、開発者の仕事を増やすだけです。
Claude Code Securityは、非常に優れたテクノロジーだと思います。しかし、これはスキャンと検出のツールです。問題を見つけ、パッチを提案します。それ自体に価値があるのは間違いありませんが、シニアエンジニアやAppSecの専門家が問うべきなのは、スキャンの後に何が起きるのか、ということです。
誰も語らない皮肉な事実
話題の論評でほとんど触れられていないことがあります。脆弱性を見つけているAIモデルは、同時に脆弱性も生み出しているのです。
このデータは深刻です。ETH Zurich、UC Berkeley、INSAITによるベンチマークBaxBenchは、セキュリティが重要なバックエンドのコーディングタスクにおけるLLMの性能を評価しています。その結果、最も優れたモデルでさえ、生成した解決策の62%が誤っているか、セキュリティ脆弱性を含んでいました。最も高い性能を示したAnthropicのClaude Opus 4.5でさえ、セキュリティに関する特別な指示がなければ、安全で正確なコードを生成できたのは56%にとどまりました。
CodeRabbitの分析でも同様の傾向が見られます。AI生成コードは、人間が書いたコードに比べて、XSS脆弱性を持ち込む可能性が2.74倍、安全でないオブジェクト参照を持ち込む可能性が1.91倍高く、セキュリティ上の問題が全体的に見つかる可能性も1.57倍高くなっています。
少し立ち止まって考えてみましょう。オープンソースコードからゼロデイを500件見つけられるAIモデルがある一方、生成するコードのほぼ半分に脆弱性を持ち込むAIモデルもあります。同じテクノロジーが、問題であると同時に解決策の一部でもあるのです。これは矛盾ではなく、現状そのものです。つまり、真剣にセキュリティに取り組むなら、この方程式の両面を考慮する必要があります。
ツール自身が同時に生み出している問題を、スキャンだけで解決することはできません。脆弱性の発生をその場で防ぎ、すり抜けたものを検知して自動修正し、プロセス全体をエンタープライズ規模で管理するシステムが必要です。それはスキャナーではなく、プラットフォームです。
実際に必要なアーキテクチャとは
セキュリティツールを最新の開発ワークフローにどう組み込むべきか、考えてみましょう。本質的な洞察は、アーキテクチャの問題にあります。
現在、一般的なエンタープライズ環境のセキュリティインフラは、おおむね次のようになっています。
ボトルネックは、常にステップ6以降にありました。そこで開発の速度が落ちます。平均修復時間（MTTR）が数時間から数週間、数か月へと膨らみます。さらに、AI支援コーディングによって、PR数が作成者1人あたり20%増加しているため（Cortexの2026年Engineering Benchmarkによる）、バックログはこれまで以上の速さで増えています。コードが増えればバグも増えます。セキュリティエンジニアの人数が同じ（または減少する）ままバグが増えれば、対応待ちの列はますます長くなります。
しかし、市場の反応が見落としているとしても、Anthropicの発表が正しく捉えている点があります。AIは検出だけでなく、修正のループにも組み込むべきです。画期的なのは「AIが脆弱性を見つけられる」ことではありません。優れたスキャナーは何年も前からそれを実現してきました。画期的なのは、「AIがコードを十分に推論し、脆弱性を修正できる」ことです。これは、Snykが取り組んできた考え方そのものです。
最善のセキュリティはAIと決定論的分析を組み合わせる
私たちが開発してきたものを紹介する前に、ひとつ明確にしておきたいことがあります。これは「決定論的分析かAIか」という議論ではありません。その捉え方では本質を見誤ります。
AIの（拡張された）推論は、特定の分野で驚くほど優れています。Opus 4.6によるゼロデイの発見がその証拠です。LZW圧縮を概念レベルで理解し、ヒープバッファオーバーフローを見つける。そこには、従来のスキャナーにはできない、コード全体を捉える理解力が求められます。複雑なビジネスロジックの欠陥、アクセス制御の不備、複数ファイルにまたがる認証バイパスなども、AIの推論が真価を発揮する領域です。
しかし、AIの推論には、よく知られた限界もあります。幻覚を起こし、実際は安全なパラメーター化クエリを誤って解釈して、「重大なSQLインジェクション」と自信満々に指摘することがあります。大規模なコードベースを分析する際に注意が散漫になったり、コンテキストウィンドウを使い切ったりして、明白な問題を見逃すこともあります。セキュリティの文脈では、どちらの失敗も高くつきます。誤検知が続けば開発者の信頼が損なわれ、検出結果を無視するようになります。一方、見逃しがあれば、本物の脆弱性が本番環境に残ります。
データフロー分析、汚染追跡、シンボリック実行、厳選された脆弱性データベースとのパターン照合などの決定論的分析は、これとは逆の特性を持ちます。新たなゼロデイを発見することはできません。しかし、UserController.javaの47行目にSQLインジェクションがあると示す場合、その検出結果にはソースからシンクまでの具体的なデータフロートレースが裏付けとしてあります。再現可能で、説明でき、検証可能です。分析が確率的ではなく機械的に行われるため、信頼性も高くなります。
そして、あまり知られていないことがあります。Snykでは、この2つのアプローチは別々に進めているわけではありません。セキュリティ研究チームは生成AIを積極的に活用し、新たな脆弱性パターンを発見しています。実際の問題が見つかれば、その知見を決定論的な検出ルールに落とし込み、プラットフォーム全体に展開します。つまり、AIの創造的な発見力を、高速で信頼性が高く、実行コストの低い検出に変換し、すべてのSnykのお客様に自動的に提供できるのです。毎回のスキャンで計算コストを負担したり、幻覚のリスクを受け入れたりすることなく、AI研究の知見を活用できます。両方の長所を取り入れるアプローチです。AIが一度難しい発見作業を行い、その後は決定論的分析によって、保護対象のすべてのコードベースで同じパターンを確実に大規模検出します。
正解は、どちらか一方を選ぶことではありません。正解は、組み合わせることです。AIの推論が得意とする、新たな脆弱性の発見、複雑なロジックのバグ、ファイル横断分析にはAIを活用します。既知の脆弱性パターン、サプライチェーンのリスク、監査可能な証跡が必要なコンプライアンス上重要な検出など、決定論的分析がそれを得意とする領域では、決定論的分析を活用します。そして修正の段階でもAIを活用します。十分に理解され、信頼性の高い検出結果に基づいて修正を生成することは、まさにLLMが得意とする作業だからです。
そして、全体をつなぐ重要な点があります。この多層化が重要なのは、検出だけではありません。修正にも不可欠です。Claude Code Securityがパッチを生成すると、そのパッチはAI生成コードです。AI生成コードに何が起きるかは、すでに見てきました。BaxBenchによると安全でない割合は62%、Veracodeでは45%です。つまり、AIが脆弱性を見つけた後、その修正自体が新たな脆弱性を持ち込む確率は五分五分です。マージ前に提案された修正を再スキャンする決定論的な検証ステップがなければ、自分たちの修正パイプラインでモグラ叩きをすることになります。AIの推論＋決定論的検証＋AIによる修正＋決定論的な再検証という多層アプローチは、見栄えのよいアーキテクチャ図にとどまりません。これがあって初めて、計算上も成り立つのです。
このアーキテクチャは、エンタープライズ規模で機能します。私たちはまさにこれを開発してきました。
Snykが実現する、両方の長所を活かしたアプローチ
Snyk Studioでの取り組みを追っている方なら、Claude Code Securityのアーキテクチャビジョンが、私たちが提供してきたものと驚くほどよく似ていることに気づくでしょう。違いは、私たちがスキャンだけでなく、パイプライン全体に取り組んできたこと。そして、コードレベルの分析をはるかに超える範囲をカバーするプラットフォーム上に構築してきたことです。
Snyk Studio：作業を中断させないセキュリティ
Snyk Studioは、Claude Code、Cursor、Gemini CLI、Clineなど、開発者がすでに利用しているAIコーディングツールにセキュリティインテリジェンスを直接組み込みます。これにより、次の2つの重要なユースケースを実現します。
着想の段階からセキュアに – 開発者がAIコーディングアシスタントを使ってコードを書くと、Snyk Studioのガードレールディレクティブが、安全でないコードを開発者が提案を受け入れる前に自動で検出します。AIアシスタントは新しいコードに対してsnyk_code_scanを実行し、セキュリティ上の問題が見つかれば、その場で修正します。チケットも、コンテキストの切り替えも、3スプリントの遅れもありません。BaxBenchのデータが示すAI生成コードのセキュリティを考えれば、これは選択肢ではなく必須です。
大規模な修正 – 既存の脆弱性のバックログには、Snyk Studioが/snyk-fixのような修正ディレクティブを提供します。スキャン、トリアージ、修正、検証という一連のサイクルを、1つのコマンドに集約できます。
ここで検出を担うのは、Snykの決定論的分析エンジンです。信頼度の高い検出結果に基づいて、AI修正レイヤーが迷うことなく対処できます。修正はLLMが生成します。両者の強みを組み合わせられます。
コードの先へ：プラットフォームの全容
Claude Code Securityとの比較から明らかになるのは、ソースコードのスキャンは大きな課題の一部にすぎないということです。どれほど高性能でも、単一のシグナルしか扱えないスキャナーでエンタープライズのセキュリティプログラムを運用するのは、体温計だけで患者を診断しようとするようなものです。
同じプラットフォームで複数の種類のスキャン結果を得られる場合を考えてみましょう。SASTエンジンがコントローラーメソッドの潜在的なSQLインジェクションを検出します。DASTエンジンが独立して、同じエンドポイントが実行時に悪用可能であることを確認します。SCAエンジンは、使用中のORMライブラリに、特定のエッジケースでパラメーター化を回避する既知のCVEがあることを特定します。それぞれの検出結果から、個別に分かることもあります。しかし同じプラットフォーム上で相関分析すれば、何が起きているのか、なぜなのか、そして何を優先して修正すべきかが正確に分かります。
これが、私たちがAI Security Fabricについて語るときの意味です。単一のツールでも、単一種類のスキャンでもありません。ソフトウェアサプライチェーン全体のあらゆるセキュリティシグナルを連携させる、適応型システムです。SnykはSASTとDASTの検出結果を自動的に相関させ、Snyk Codeが特定したコードレベルの問題と、Snyk API & Webが発見した実行時の脆弱性を結び付けて、悪用可能な欠陥の原因となっているコードの行を特定します。個別のツールをつなぎ合わせるだけでは実現できません。SAST、SCA、コンテナスキャン、Infrastructure as Code分析、DAST、APIセキュリティのすべてが同じファブリックに集約され、同じ優先順位付け・修正エンジンに連携することで得られる、アーキテクチャ上の優位性です。
さらに、セキュリティチームが実際にプログラムを運用するためのエンタープライズレイヤーもあります。数千のリポジトリにまたがるリスクを集約する一元化されたダッシュボード、ポリシー・アズ・コードによるガバナンス、CI/CDパイプラインとの連携、そして6種類ものベンダーダッシュボードをつなぎ合わせなくても、CISOが「リスクへの曝露状況は？」と、エンジニアリング担当VPが「MTTRは改善傾向にあるか？」と答えられるレポート機能です。どれほど優れたコードスキャナーでも、こうした問いには答えられません。答えられるのはセキュリティファブリックです。
Evo：AIスタック自体を保護
さらに、Claude Code Securityがまったく対応していないセキュリティ領域があります。それは、AIインフラの保護です。
Evo by Snykは、AIネイティブな開発環境向けに特化して設計された、エージェント型セキュリティオーケストレーションシステムです。コードからライブ脅威モデルを自動構築し、プロンプトインジェクションなどのリスクを検出するAI脅威モデリングを備えています。また、モデルやエージェントに対して継続的に敵対的テストを行うAIレッドチーミングも備えています。適応型の攻撃者をシミュレーションし、検証可能なエクスプロイト実証の証拠を生成します。さらにAI-SPM（ソフトウェアポスチャ管理）により、「シャドーAI」を含め、組織全体でどのAIモデル、データセット、フレームワーク、ツールが稼働しているかを正確に把握できます。そして、開発環境のMCPサーバーとスキルなど、あらゆるツールチェーンを可視化し、リアルタイムのガードレールを適用するエージェントスキャンも含まれています。
2026年1月、私たちの調査チームは、AIエージェントのエコシステムを標的とした初の大規模なサプライチェーン攻撃として、ClawHubで数百件の悪意あるスキルを発見しました。どれほど高度なコードレベルのスキャナーでも、この種の脅威には対応できません。まったく異なる攻撃対象領域であり、専用に設計されたツールが必要です。
これは業界にとっての追い風
今回の発表がセキュリティ業界にとって何を意味するのか、率直な見解をお伝えします。これは追い風です。
世界有数の資金力と技術力を持つAI企業Anthropicは、最先端モデルで何を開発できるかを検討し、セキュリティスキャンと修正のツールを開発することを選びました。これは偶然ではありません。AIネイティブでエージェント型のセキュリティワークフローを開発者ツールに直接組み込むという、業界の進む方向が正しいことを示しています。
これは、Snyk StudioとSnykプラットフォーム全体の根底にある考え方と同じです。目指すのは、脆弱性のトリアージに使う、より優れたダッシュボードを作ることではありません。見栄えのよいレポートや、より詳細な深刻度スコアを生成することでもありません。目指すのは、開発者の作業の流れを妨げず、脆弱性の発生地点にできる限り近いところで、できる限り多くの脆弱性を自動的に修正することです。
すべてのバグを自動修正できるわけではありません。アーキテクチャの変更が必要なものもあれば、ビジネスロジック上のトレードオフについて人間の判断が必要なものもあります。しかし、チームが日々直面する一般的な脆弱性パターンの大半は、Jiraチケットを起票して3スプリント待つ必要がないはずです。
目指しているのは、それだけです。
Anthropicがこの分野に投資しているという事実は、私たちが正しいものを作ってきたことを示しています。これらのツールは互いを補完します。Claude Code Securityは深く掘り下げた新規のゼロデイ脆弱性の発見に、Snykのプラットフォームは、企業が大規模なセキュリティプログラムを運用するために必要な、全領域をカバーする、決定論的分析とAIを組み合わせた予防から修正までのパイプラインに対応します。
問われていたのは、「AIをセキュリティに活用すべきか？」ではありません。常に問われていたのは、「信頼性、包括性、エンタープライズ対応を備えた形で、どう構築するか？」です。その答えには、AIによる推論と決定論的分析の両方を組み合わせ、開発者ツールに組み込み、AIサプライチェーン自体を含めたソフトウェアサプライチェーン全体をカバーするプラットフォームで支えることが必要です。
この記事があなたに意味すること
シニアエンジニアまたはAppSecの専門家の方に、実践的なアドバイスをお伝えします。
サイバーセキュリティ株の売りは過剰反応です。市場が反応しているのは、アーキテクチャではなく見出しです。脆弱性の発見はセキュリティプログラムに不可欠ですが、それだけでは不十分です。本当の価値は修正のループにあります。その実現には、既存ツールとの深い連携、信頼できる多層的な検出、そしてエンタープライズ規模で運用できる能力が必要です。
Claude Code Securityを試してみてください。ぜひ試してみてください。オープンソースコードをメンテナンスしている方や、新規のゼロデイ脆弱性の発見が重要なプロジェクトに取り組んでいる方なら、リサーチプレビューを試す価値があります。Opus 4.6がGhostScriptとCGIFで実現したことは、実に革新的です。
ただし、セキュリティプログラムの基盤には、個別ツールではなくプラットフォームを選びましょう。日常的なAppSec運用には、数百に及ぶ既知の脆弱性パターン、サプライチェーンリスク、コンテナの設定ミス、IaCのドリフト、AIモデルのガバナンスに対応するフルスタックが必要です。信頼できる決定論的検出とAIによる推論が必要です。開発の初期段階での予防と大規模な自動修正が必要です。セキュリティの監視、ダッシュボード、エンタープライズガバナンスも欠かせません。そして今後は、AIツール自体の保護もますます重要になります。
それを実現するのがSnykです。Claude Codeを含む、開発者がすでに使っているAIコーディングアシスタントを活用し、開発の初期段階で脆弱性を防ぎ、既存の脆弱性を大規模に修正できる、セキュリティに配慮したエージェントへと変えます。さらに、コード、依存関係、コンテナ、インフラ、API、AIスタックをカバーするプラットフォーム上で実現します。
実際に試してみましょう
この考え方を評価する一番簡単な方法は、実際に試すことです。Snyk Studioは無料で、セットアップは数分で完了します。まずは次の方法をお試しください。
すでにClaude Codeを利用している方（Anthropicが発表したばかりの内容を考えると、利用している方も多いでしょう）は、Claude Codeインテグレーションガイドに沿って、Snyk Studioを既存のワークフローに接続できます。約5分で、ターミナル上で決定論的スキャンと修正コマンド/snyk-fixを使えるようになります。
Secure at Inceptionのガードレールや修正ディレクティブを含め、ディレクティブの仕組みを知りたい方は、ディレクティブのドキュメントをご覧ください。ディレクティブはカスタマイズできるため、チーム固有の技術スタックやリスク許容度に合わせて調整できます。
プラットフォームの全体像を知りたい方は、Snyk Studioの製品ページが出発点として最適です。AIセキュリティについてはEvoをご覧ください。
AppSecの未来は、より優れたスキャナーの開発ではありません。開発者の作業を遅らせることなく、AIスタックを含む攻撃対象領域全体で、検出から修正までのループを自動的に、そして大規模に完結させることです。Anthropicが今、この方向に多額の投資をしているという事実は、業界が本当の効果を生み出すポイントを見定めたことを示しています。そしてSnykを使えば、その効果を今日から活用できます。
eBook
シフトレフトから開発の初期段階でのセキュリティ確保へ：AI時代におけるAppSecの進化
コードを書き始める段階からセキュリティに取り組むべき理由をご紹介します。Snyk Studioが提供するインテリジェンス、自動化、ガードレールによってAIコーディングを管理し、イノベーションにセキュリティを組み込む方法をご覧ください。