CodeRabbitがClaude Marketplaceに登場！Learn more
Atsushi Nakatsugawa
July 09, 2026
1 min read
Security at AI Speed: You Can’t Fix What You Can’t Detect and Understandの意訳です。
2つのトレンドが、ソフトウェアのセキュリティを作り変えつつあります。
1つ目は、いまやAIがコードの大半を書いており、そのコードのうち脆弱なものが増えているということです。New Relicの2026 State of AI Codingレポートでは、技術リーダーの3分の2が、毎週生成されるコードの51%〜75%AIが、AIの生成したコードをリファクタしたものだと答え、62%が自分たちのチームは1行ずつの検証をせずにそれをリリースすることが多いと答えました。Veracodeが幅広いコーディングタスクにわたってAIモデルをテストしたところ、それらが生み出したコードは45%のケースで既知のセキュリティ脆弱性を持ち込んでおり、より新しく、より大きなモデルでも結果は変わりませんでした。
2つ目のトレンドは、AnthropicのMythosのような最先端のAIモデルが、かつてない速さでソフトウェアのバグを見つけていることです。これは同時に、攻撃者が脆弱性を突く前の助けにもなります。Wall Street Journalの記事によれば、8年前はバグが公に開示されてから攻撃までの平均期間は847日でした。昨年、それは23日に縮まりました。今年は、そのほとんどが1日以内に突かれており、この変化はZero-Day Clockで追跡されています。
これらすべてが意味するのは、より多くのセキュリティ上の欠陥がAIの生成したコードに入り込む一方で、より速い攻撃が生まれているということです。だからこそ、コードのセキュリティはいまこそかつてないほど注目に値します。
その最も明確な兆候が、パターンベースのセキュリティツールには見えない、新しい種類の攻撃です。2026年6月、Tenet Securityの研究者たちは、Agentjackingを説明しました。これは、攻撃者が、標的のSentryに送られる偽のエラー報告の中に指示を隠しておき、開発者がAIエージェントに「未解決のSentryの課題を修正して」と頼むと、エージェントが開発者のフルの権限で攻撃者のコードを実行してしまう、というものです。これは、広く使われているAIコーディングアシスタントに対して85%の確率で成功しました。しかも、この連鎖の中のすべてのアクションが認可されたものだったため、EDRやWAF、ファイアウォールもすり抜けてしまいました。
スキャナが照合できるような、従来型の悪意あるものは何もありません。それがAI時代のセキュリティリスクの姿です。プロンプトインジェクション、汚染されたコンテキスト、安全でないAIの出力、そしてファイルやサービスをまたぐビジネスロジックの欠陥。これらはどれも、パターンのルールに書き込まれていませんでした。そのルールがまだ存在しないからです。
私たちは、これを顧客から2つの異なる形で聞いています。急成長中のSaaS企業のDevSecOpsチームにいるスタッフセキュリティエンジニアは、最大の懸念はAIを活用した脆弱性管理で後れを取ることだと語ってくれました。従来のパターンベースのSASTはまるごと1つの種類の問題を見逃しており、彼らは、AIを活用したセキュリティツールが、既存のスキャナが完全に見逃していた指摘を浮かび上がらせるのを目にしていたのです。
さらに、あるAIネイティブなスタートアップのエンジニアリングリーダーは、同じ問題の生成する側について語ってくれました。彼は、コードレビューと並んでAIによるセキュリティレビューを望んでいました。彼の言葉を借りれば、機械が生成したコードは「たくさんの興味深いものを」生み出すからです。彼にとって、コード品質のレビューだけでは十分ではありませんでした。コードのセキュリティが、同じ1回のパスの一部である必要があったのです。
どちらのチームも、異なる方向から同じギャップを指し示しています。AIはより多くのコードを、より速く、そして新しい種類のリスクとともに生成しています。ルールベースの世界のために作られたツールは、そのコンテキストを理解したり、そのペースについていったりするようには設計されていませんでした。
次世代のセキュリティツールは、根本からエージェント的である必要があります。既知のパターンを照合するだけでなく、エージェントは、シニアエンジニアやセキュリティレビュアーがするようにコードベースを探索し、推論すべきです。認証と認可がどこで行われるのかを理解し、信頼できない入力をファイルやサービスをまたいで追跡し、意図について推論して、意図的なプロダクト上の判断を本物のセキュリティ上の欠陥と見分けるべきです。
そうやってこそ、どんなルールも予期しなかった問題を捉えられ、そして誤検知を除外できるのです。そして、その推論が変更そのものに対して直接行われるため、問題はコードがすでにリリースされた後に、定期スキャンで数週間後に見つかるのではなく、マージ前のPRの中で浮かび上がらせられます。
検出は、仕事の半分にすぎません。捉えるのが最も難しい脅威、たとえばagentjackingのフロー、連鎖したロジックの欠陥、壊れた認可の経路などは、理解するのも最も難しいことが多いのです。曖昧なアラートは、開発者にこう問わせたまま放置します。これは本物か?到達可能なのか?どうやって突かれるのか?何を変えればいいのか?と。
開発者が理解できない指摘は、無視され、却下され、バックログに埋もれていきます。さらに悪いことに、それらは本番環境へと入り込んでいきます。一方、役に立つ指摘は、脅威、その経路、突かれやすさ、そして修正を説明してくれます。
だからこそ、推論と説明可能性は一緒であるべきなのです。コードベース全体にわたるエージェント的な推論は、確度の高いセキュリティ脆弱性を捉えるのに役立ちます。その同じコンテキストに根ざした説明可能性は、それぞれの指摘を、開発者が信頼し、対応し、自信を持ってリリースできる修正へと変えてくれます。
AIはより脆弱なコードを書いており、ハッカーはより優れたツールを使って弱点を見つけ、突いています。これは、より多くのリスク、そして従来のセキュリティレビューが追いつけないほど速く動く、より新しい種類のリスクを意味します。Salt Securityの調査によれば、セキュリティリーダーの10人に9人がAIの生成したコードのセキュリティリスクを懸念しているのも、驚くには当たりません。
検出の速さは重要であり、そして説明可能性こそが、それを対応可能なものにします。今後、先を行き続けるチームとは、コードのセキュリティレビューのツールが未知の脅威について推論し、それが公になる前に開発者が問題を直し、明確に説明できる、そんなチームでしょう。
