AIによる脅威に、AIで対抗する - Google Cloud Next Tokyo 26 参加レポート

下津裕生 - Nomura Research Institute, Ltd.

はじめに

こんにちは、NRIの下津です。パブリッククラウド運営サービス「QUMOA」にてGoogle Cloudを中心とした開発・運用業務に携わっています。
2026年7月には、複数の Google Cloud プロジェクトにガバナンスを効かせながら効率的に管理する「マルチプロジェクト管理サービス」をリリースしました。2026年7月30日・31日に東京ビッグサイトで開催された「 Google Cloud Next Tokyo 26」（以下、Next Tokyo 26）に参加してきました。会場入口には「革新的なアイデアを、AIで実現しよう。」というメッセージが掲げられていました。数多くのセッションが並ぶ中、私は普段の業務との関係から、AIとセキュリティに関するセッションを中心に回りました。
本記事では、そこで見聞きしたことと、AI時代のセキュリティについて改めて体感したことをお伝えします。なお、本文中で触れる機能の提供状況は、いずれもセッション当日の発表内容に基づくものです。

Google Cloud Next Tokyo 26 とは

Next Tokyo 26 は、Google Cloud が主催する国内最大級のカンファレンスです。今年は2026年7月30日・31日の2日間、東京ビッグサイト南展示棟にて、基調講演と多数の技術セッション、パートナー各社の出展という構成で開催されました。
全体を通じて印象的だったのは、AIエージェントの話題が「試してみる」段階から「本番の業務で動かす」段階へ明確に移っていたことです。そして本番投入を成立させる条件としてのセキュリティが繰り返し語られていました。

攻撃側の速度が、人間の運用速度を追い越していた

初日の基調講演では、Gemini Enterpriseを用いた業務革新と効率化について説明がありました。加えて、セキュリティの観点についても説明があり、AI時代のサイバーセキュリティを3つの論点で整理するところから始まりました。「攻撃者もAIを駆使」「悪用されるまで1.6日」「AIによる自律的な対抗」です。

また、セッション「AIエージェントによる自律型防御と次世代セキュリティ運用の未来」（ Google Cloud ）では、脆弱性が公表される前から攻撃が始まっているという話が印象的でした。Mandiant（ Google Cloud ）の「M-Trends 2026」レポートから引用された数字として、脆弱性の公開から悪用されるまでの期間が中央値でマイナス7日、つまりパッチが提供される前に攻撃が始まっていることを示す、という説明がありました。

攻撃側がAIをどう使っているかについては、次のような整理が示されていました。

未知の脆弱性をAIが発見し、エクスプロイト（攻撃コード）の作成を高速に実行する
脆弱性が公表されると、わずか数分後にAIを利用して攻撃が開始される
フロンティアAIのような高機能なモデルを使わなくても、ツール（ハーネス）を併用することで高い攻撃力が実現できる

脆弱性情報やパッチが出てから対応を始めるという従来の運用では、そもそも間に合わないタイミングが存在するということになります。これはよく言われている「AIを業務に使うとセキュリティが心配」という文脈とは別の問題だと感じました。攻撃側がAIで速度を上げているのであれば、AIをまだ使っていない組織にも影響が及びます。防御側にとってのAI活用は、選択肢というより前提条件に近づいているのだと感じました。

AIで守る側の、現実的な話

では守る側はどうするのか。
基調講演と同セッションの両方で示されていたのが Google AI Threat Defense です。CodeMender、Wiz Cloud、Wiz Code、Google SecOps、Mandiant Consultingを中心とした、AI時代の脆弱性対応アプローチとして紹介されていました。

流れは4段階です。

準備：外部からの疑似攻撃で攻撃経路を特定し、優先順位をつける
スキャン：静的スキャンとAIによる深いスキャンの併用
修復：修正コードの自動生成と適用
監視：環境とパイプラインの継続監視、逸脱の検知

個人的にもっとも収穫だったのは、AIによる防御が理想論として語られていなかったところです。発表スライドには「ハイブリッドな対応の推奨」として、AIモデルベースの脆弱性スキャン・修正は強力だが、コストや速度、偽陽性の観点から、従来型の SAST/DAST ツールとの併用が望ましい、と明記されていました。
AIを運用に組み込む話は、ともすると「全部AIがやってくれる」という期待に流れがちです。そうではなく、どこをAIに任せ、どこを従来手法で押さえるか。コストと偽陽性という現実的な制約を挙げたうえで併用を勧める姿勢に、納得感がありました。
効果についても具体的な説明がありました。Google 自らの実証として、月間数万件の脅威レポートをAIエージェントが自動精査し、脅威の緩和時間を90%以上短縮したという内容です。

CodeMender ― 脆弱性を見つけて直すAIエージェント

Google AI Threat Defense の4段階のうちスキャンと修復の中核を担っているのが、基調講演や同セッションで紹介されていた CodeMender です。Google DeepMind が開発した、脆弱性を自動で検出・修正するAIエージェントで、パブリックプレビューとして提供が案内されていました。

セッションのデモで印象的だったのは、検出した箇所を実際にコンパイルして動かし、攻撃コードで本当に悪用できるかを確かめたうえで修正していた点です。
静的な解析で「怪しい」と指摘するだけでなく、悪用可能性まで検証してから直す。偽陽性への対処を、AIエージェント自身の動作の中に組み込んでいる形です。先の「ハイブリッドな対応の推奨」と合わせて、AIをどう現実の運用に載せるかがよく考えられていると感じました。CodeMenderの公式ドキュメントを確認すると、この動作は設計として明示されています。公式ドキュメントには「検証中、CodeMender は概念実証（PoC）の脆弱性利用型不正プログラムを生成して実行し（デフォルトのサンドボックス内）、問題が本当に悪用可能かどうかを確認します」と記載されており、デモで見た挙動が設計として明示されていました。なお、PoC の実行を省いて静的な検証のみを行うフラグも用意されており、実行環境の制約に応じて使い分けられるようになっています。

また、既定ではターミナルでの確認を経ずにファイルを変更したりシェルコマンドを実行したりはしない、とも明記されていました。人間の確認を挟むことが初期状態になっています。
CI/CD パイプラインのような非対話的な環境では、この確認をスキップするフラグも用意されています。ただしドキュメントでは、分離された環境で実行する場合に限るよう注意が添えられていました。

おわりに

Next Tokyo 26 で体感したのは、攻撃側の速度が人間の運用速度を追い越しており、防御側もAIを使わざるを得なくなっているということです。
ただし「全部AIに任せる」ではなく、どこをAIに任せてどこを従来手法で押さえるか、その設計が問われる段階に入っていると感じました。CodeMender のデフォルト設定に人間の確認が組み込まれていたのも、同じ考え方の表れだと思います。「AI活用を進めたいが、統制に不安がある」という声は、会場でも数多く耳にしました。冒頭でご紹介した「マルチプロジェクト管理サービス」も、複数の Google Cloud プロジェクトにガバナンスを効かせながら、利用部門が安全に使える環境を用意することを目的としたものです。同じ課題をお持ちの方にとって、本記事が解決策を考える材料になれば幸いです。