Claude Fable 5がGoogle Cloudで一般提供開始。エージェント構築の新たな基盤を考察
Anthropicの最新モデル「Claude Fable 5」が、Google Cloud上で一般提供を開始した。このモデルは複雑な多段階推論や高度なコード生成を得意とし、長期間にわたって自律的に動作するエージェントの構築に適している。クラウドAIの基盤に何が起きているのかを読み解く。
Claude Fable 5の登場とその戦略的な位置付け
Anthropicのモデル群には、Haiku（軽量高速）、Sonnet（バランス）、Opus（超高性能）がある。今回登場したFableシリーズは、これらのニックネームとは明らかに異なる文脈を持つ。筆者の見解では、Fableは「物語（ストーリー）の生成」、つまり長文脈の一貫性維持や、複雑なオーケストレーションを必要とするエージェントタスクに特化した系統と位置付けられる。
このモデルは単に速度や知識量を競うだけでなく、「どれだけ複雑な仕事を最後までやり遂げられるか」を重視している。特に、長期稼働エージェントとしての使用が強く想定されている点が、他のモデルとの差別化要因だ。
Fable 5は、単発のレスポンスを返すだけではない。途中で文脈を見失ったり、指示を忘れたりする問題を大幅に低減し、ソフトウェア開発や分析業務といった長時間の集中を要するタスクで真価を発揮する。
Fable 5の主要な能力と想定されるユースケース
Google Cloudの公式発表とAnthropicのリリースノートから、Fable 5の中核的な機能強化点を読み解くと、以下の3つに集約される。
複雑な多段階推論と高度なコード生成
Fable 5は、数学的推論やコード生成ベンチマークで大幅な性能向上を達成している。これは単にコードを出力するだけでなく、既存のリポジトリ全体を理解し、アーキテクチャレベルの提案ができることを示す。典型的な「次のトークン予測」を超え、人間のソフトウェアアーキテクトのように数手先を読む能力が強化された。
長期稼働エージェントの実現
多くのLLMは文脈が長くなると応答精度が落ちる。Fable 5は「長時間にわたって自律的にツールを使い、タスクを完了させる」というエージェント動作に最適化されている。カスタマーサポートの自動化、継続的なデータ収集、IT運用の自動化など、数時間から数日単位で動くAIエージェント基盤として機能する。
深いマルチモーダル文書分析
テキストだけでなく、PDF内のグラフ、パワーポイントの図表、画像内のテキストまでを横断的に理解する能力が向上した。これにより、企業内に散在する非構造化データの分析ハードルが大幅に下がる。数百ページの契約書や仕様書を読み込ませ、瞬時に要約や矛盾点の洗い出しを行うといった使い方が視野に入る。
これらの能力は、もはや「優秀なアシスタント」ではなく「自立したチームメンバー」という表現が近い。開発現場ではコードレビューを完全自動化し、法務部門では契約書の精査を任せられる。人間が最終判断する仕事の質とスピードが、根本から変わる可能性をはらんでいる。
Google CloudのAgent Platformがもたらす実用性
モデル単体の性能もさることながら、今回の発表で注目すべきはGoogle Cloudの「Agent Platform」上で提供される点だ。これは単なるAPIゲートウェイではない。エージェントの構築、テスト、デプロイ、監視までを垂直統合した基盤である。
具体的には、Googleが持つエンタープライズグレードのセキュリティ（IAM、VPC Service Controls）、Vertex AIのMLOps機能（モデル評価、メタデータ管理）、そしてCloud RunやBigQueryといった周辺サービスとの統合がシームレスに行える。Fable 5のような高度なモデルを「安全に」「堅牢に」本番環境で動かすために必要なピースがあらかじめ揃っている。
ここで重要なのは、強力なモデルを手に入れることと、それをビジネスで使いこなすことの間にあるギャップが、Agent Platformによって埋められる点だ。認証基盤や監査ログが整っていない状態でAIエージェントに重要な業務を任せることは難しい。Google Cloudのプレゼンスは、企業のAI導入における「最後の1マイル」を解決する。
開発者が今日から試すべき3つのアプローチ
Fable 5とAgent Platformが利用可能になったことで、Web制作やシステム開発の現場で即座に試せる実験領域が広がった。筆者の視点から、特に費用対効果が高いと想定される3つのシナリオを提示する。
コードレビューの完全自動化プロトタイプ
GitHub連携をトリガーに、Fable 5がPull Request全体を解析する。コーディング規約のチェックだけでなく、コードの脆弱性、パフォーマンス劣化リスク、過去の類似実装との矛盾点までを自然言語でレビューコメントする。人間のレビューアは、Fable 5が出した指摘が正しいかどうかの最終判断だけに集中できる。
非構造化ドキュメントのデータベース化
クライアントから提供された古い仕様書のPDF、競合分析のスライド、展示会で撮影したホワイトボードの写真などをまとめてFable 5に投入する。モデルはこれらを横断的に解析し、共通する要求定義や矛盾する記述を抽出して構造化データとして出力する。データベースに格納することで、後続の検索やレポート作成が自動化される。
社内向け「なんでも調査エージェント」の起案
定型的なリサーチ業務をエージェント化する。例えば「3ヶ月以内に更新された特定分野の法改正情報を、週次で一覧化してSlackに投げる」といったタスクをFable 5に任せる。モデルが自律的にGoogle検索や社内Wikiを巡回し、複数ステップの推論を経て最終的なサマリーを生成するPoCは、数日あれば構築可能だ。
このアプローチによって、人間の工数は「クリエイティブな問題解決」と「AIの提案に対する最終的な意思決定」に集中できるようになる。
この記事のポイント
- Anthropicの最新モデルClaude Fable 5は、複雑な推論と長期稼働エージェントに特化してGoogle Cloud上で一般提供が開始された
- 高いコード生成能力と深いマルチモーダル分析を持ち、単なるテキスト生成を超えたタスクの自動化が可能になった
- Google CloudのAgent Platformとの統合により、エンタープライズレベルのセキュリティと運用基盤が整備されている
- 人間はAIの最終判断に集中する働き方へシフトするため、コードレビューや文書分析のプロトタイプを早期に試す価値がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google Cloud、AlloyDB向けリモートMCPサーバーがGA。AIエージェントとDBの安全な統合を実現
Google CloudがAlloyDB向けのリモートMCP（Model Context Protocol）サーバーの一般提供を発表した。これまでローカル開発が中心だったMCPだが、本番環境での運用に耐えるフルマネージドな仕組みとして登場した。AIエージェントが企業のオペレーショナルデータベースに直接アクセスし、安全にクエリを実行できるようになる。
この記事では、リモートMCPサーバーが解決する技術的課題と、AlloyDBを基盤にしたエージェントアプリケーションの構築方法を解説する。データの鮮度、セキュリティ、運用負荷のバランスを取るアーキテクチャを具体的に示す。
リモートMCPとは何か（ローカルMCPとの違い）
MCP（Model Context Protocol）とは、大規模言語モデル（LLM）が外部のデータソースやツールと安全に通信するためのオープン標準プロトコルだ。Anthropicが提唱し、現在では多くのAIエージェントフレームワークで採用されている。従来は開発者のローカルマシン上で動作する「ローカルMCPサーバー」が主流だった。
ローカルMCPサーバーは標準入出力（stdio）を使ってプロセス間通信を行う。これは開発段階では手軽だが、本番環境に持ち込むと途端に問題が顕在化する。複数のエージェントインスタンスが同時にデータベースへアクセスする場合、プロセス管理が複雑化し、ネットワーク越しのセキュリティ確保も難しくなる。
リモートMCPサーバーは、これらの課題をHTTPエンドポイント経由で解決する。Google Cloudのマネージドインフラ上で動作し、OAuth 2.0ベアラートークンによる認証とIAM（Identity and Access Management）によるきめ細かな権限制御を提供する。エージェント開発者はインフラ管理から解放され、クエリ実行に集中できる。
なぜAlloyDBと組み合わせるのか
AlloyDBはGoogle CloudのフルマネージドPostgreSQL互換データベースだ。標準PostgreSQLと比較して、ベクトル検索では最大6倍高速、フィルタ付きクエリでは最大10倍高速というパフォーマンスを備える。ScaNNインデックスを使えば100億ベクトル規模まで拡張でき、AIエージェントのRAG（検索拡張生成）ワークロードに最適化されている。
さらにAlloyDBには、データベース内で直接埋め込みベクトルを生成するAI Functionsや、Gemini Enterprise Platformモデルを使った検索結果のリランキング機能が組み込まれている。エージェントがデータベースにクエリを投げるだけで、最新のオペレーショナルデータに基づいた回答を得られる。データの鮮度を保つためのETLパイプラインが不要になるケースも多い。
リモートMCPサーバーが解決する5つの本番課題
Google Cloudブログの発表によると、リモートMCPサーバーは単なる通信方式の変更にとどまらない。本番環境でAIエージェントを運用するチームが直面する、以下の5つの課題を包括的に解決する設計になっている。
特に注目すべきはIAMによる権限制御だ。従来のデータベース接続では、共有パスワードやAPIキーを使うことが多かった。しかしリモートMCPでは、エージェントごとに特定のテーブルやビューへのアクセス権をIAMで付与できる。読み取り専用のSQL実行ツールを選択すれば、エージェントが誤ってデータを削除するリスクを根本から排除できる。
Model Armorによるプロンプトセキュリティ
リモートMCPサーバーは、Google CloudのModel Armorと統合されている。Model Armorはプロンプトとレスポンスの両方をスクリーニングし、プロンプトインジェクション攻撃や機密データの意図しない流出を防ぐ。エージェントのサービスアカウントが広範なデータベース権限を持っていても、Model Armorがデータの出し方をフィルタリングする仕組みだ。
たとえば、エージェントが顧客のクレジットカード番号を含むカラムにアクセスできる権限を持っていたとしても、Model Armorがレスポンスからその情報を除去できる。これは「権限はあるが出力は制限する」という新しいセキュリティモデルであり、ゼロトラストの考え方をAIエージェントに適用した形だ。
エージェントから見たAlloyDBの強み
リモートMCPサーバーは接続の仕組みを提供するが、その先にあるデータベース自体の性能も重要だ。AlloyDBはエージェントアプリケーションに特化したいくつかの特徴を持つ。
まず、ベクトル検索性能だ。ScaNNインデックスを使うと、標準PostgreSQLの最大6倍の速度でベクトルクエリを実行できる。100億ベクトルまでスケールするため、大規模なRAGアプリケーションでもパフォーマンスが劣化しない。フィルタ条件付きのベクトル検索では最大10倍高速化される。これは「直近30日以内のドキュメントから類似検索」のような実用的なクエリで差が出る。
次に、ハイブリッド検索とリランキングだ。RUM（RUMインデックス / Row Usage Matrix）を使った全文検索とベクトル検索の組み合わせや、Reciprocal Rank Fusionによる結果の融合が可能だ。さらにGemini Enterprise Platformモデルを使ったインテリジェントなリランキングにより、エージェントは最も関連性の高い情報を優先的に取得できる。
また、AlloyDBのAI Functionsはデータベース内部で埋め込みを生成する。外部の埋め込みAPIを呼び出す必要がなく、数百万件の埋め込みを効率的に生成できる。Lakehouse Federationを使えば、BigQueryの分析データやIcebergテーブルのアーカイブデータにも、同じPostgreSQLインターフェースから透過的にアクセスできる。
AIエージェントにとって重要なのは「データの鮮度」と「アクセスの容易さ」だ。AlloyDBのリアルタイム埋め込み生成とLakehouse Federationの組み合わせにより、エージェントは最新のオペレーショナルデータと過去の分析データを区別なく扱える。配送車両の位置情報のような刻々と変化するデータでも、クエリを発行した瞬間の状態を取得できる。
実際の導入手順とデモの流れ
Google Cloudは今回のGA発表にあわせて、Codelab（ハンズオン形式のチュートリアル）を公開した。導入手順は以下の4ステップに整理されている。
接続が確立すると、エージェントは自動的にデータベースのスキーマを把握する。テーブル名やカラム名をイントロスペクションクエリで取得し、ユーザーの質問に応じて適切なJOINや集計クエリを組み立てられる。たとえば「過去24時間で最も遅延が発生している配送ルートは？」という質問に対して、エージェントが配送テーブルと車両テーブルをJOINし、リアルタイムの位置情報と組み合わせて回答する。
AIエージェントが実行できる操作の範囲
リモートMCPサーバー経由でエージェントが実行できる操作は、単なるSELECTクエリにとどまらない。AlloyDBのツールセットを使うと、以下のような運用操作も可能になる。
- データのエクスポートとインポート
- バックアップの作成とリストア
- クラスタの設定更新
- AI Functionsを使ったテキストのランキング（AI.RANK()）
もちろん、これらの操作はIAM権限の範囲内でのみ実行される。読み取り専用のSQLツールを選択していれば、データ定義や変更を伴う操作はブロックされる。本番環境での安全な運用を第一に設計されている点が重要だ。
導入時に検討すべきポイント
リモートMCPサーバーのGAは、AIエージェントとデータベースの統合を大きく前進させる。しかし導入にあたっては、いくつかの点を事前に検討する必要がある。
まず、コスト構造の把握だ。AlloyDB自体がエンタープライズ向けのプレミアムデータベースであり、さらにMCPサーバーの利用にもGoogle Cloudの料金が発生する。30日間の無料トライアルが提供されているので、まずは小規模なクラスタで検証し、ワークロードに応じたコストを見積もることを推奨する。
次に、IAMポリシーの設計だ。エージェントに必要最小限の権限を付与する「最小権限の原則」を徹底する必要がある。テーブル単位、カラム単位でのアクセス制御が可能だが、データベースの規模が大きくなるとポリシー管理が複雑化する。事前にアクセス制御のルールを整理しておくことが重要だ。
最後に、プロンプト設計の重要性も変わらない。MCPサーバーがデータへのアクセスを提供しても、エージェントが適切なクエリを生成できるかどうかはプロンプトの質に依存する。スキーマの説明やクエリの方針をプロンプトに含めることで、より正確な結果を得られる。
この記事のポイント
- AlloyDB向けリモートMCPサーバーがGAとなり、HTTPエンドポイント経由でAIエージェントが安全にデータベースへアクセス可能になった
- IAMによるテーブル単位の権限制御と、Model Armorによるプロンプトセキュリティで本番運用に耐える設計
- AlloyDBのベクトル検索性能とAI Functionsの組み合わせにより、RAGアプリケーションの構築が効率化される
- 30日間の無料トライアルとCodelabが提供されており、小規模な検証から始められる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google SREが語る、エージェントAIで変わる運用の新常識
GoogleがSRE（Site Reliability Engineering）にエージェントAIを本格導入し、運用の自動化レベルを引き上げている。異常検知やインシデント管理、信頼性設計といった領域で、AIエージェントが「力の倍増器」として機能し始めたのだ。
この取り組みは、2026年5月に公開されたホワイトペーパー「AI in SRE Practice」で詳細に語られている。本記事ではその核心にある5つの重点領域と、Googleが定めた7つの設計原則を整理しながら、エージェントAIがSREにもたらす変化を読み解く。
なぜ今、SREにエージェントAIなのか
GoogleがSREの概念を提唱してから20年以上が経つ。その間、信頼性を担保すべきシステムは幾重にも複雑化した。マイクロサービス化による分散配置の拡大、クラウド製品群の機能爆発、そしてAIコード生成によるソースコード量の急増。それぞれが単独でも運用負荷を押し上げる要因だが、これらが同時に進行している点が問題を大きくしている。
SREチームは従来、サービスレベル指標（SLI）やサービスレベル目標（SLO）に基づく静的な閾値監視で信頼性を守ってきた。しかし、多様な顧客ワークロードを扱うGoogle Cloudのような製品では、一律の閾値で異常を捉えきれないケースが増えている。そこで注目されるのが、AIによる異常検知とエージェント型の自律対応だ。
エラーレート ＞ 1% でアラート
このデモが示すように、AIエージェントは単に閾値を超えたかどうかではなく、平常時の振る舞いパターンからの逸脱を捉える。これにより、多様なワークロードが混在する環境でも、真に対処すべき異常だけを抽出できる確度が高まる。
SRE AIがカバーする5つの重点領域
Google SREチームは、ソフトウェア開発ライフサイクル（SDLC）全体を見渡し、AIエージェントが価値を発揮できる領域を5つに整理した。いずれも従来のSREプラクティスを補完し、人間の意思決定を加速させることを狙いとしている。
信頼性設計への組み込み
従来、SREは設計段階から信頼性を織り込むため、ポリシー策定やランブック（運用手順書）の整備に多くの時間を割いてきた。AIエージェントはこのプロセスを効率化する。具体的には、過去のインシデントから得た知見を基にランブックを自動生成し、本番環境に近い構成に対して信頼性リスクを事前検出する。人間のレビューは高リスクな変更に絞られ、トイル（労苦）の大幅な削減が見込めるという。
異常検知とアラート処理
この領域はエージェントAIの導入効果が最も顕著に表れる部分だ。Google SREは、TimesFMのような時系列予測モデルを使い、過去の正常パターンから逸脱する動きをAIが検知する仕組みを採用している。異常が検知されると、専用のアラート処理エージェントが起動し、関連情報の集約やコンテキスト付与を自動実行する。その後、自律型のアラートハンドラが可能な範囲で一次対応まで完遂する。
このパイプラインにより、人間のSREが対応すべきアラート件数そのものを減らせる。大事なのは、エージェントがどのデータをどう評価したのか、一貫して透明性を保つ設計になっている点だ。本番状態に意図しない変更を加えないための制御機構も当然組み込まれている。
インシデント管理の高度化
GoogleにはIMAG（Incident Management at Google）という確立されたインシデント管理プロセスがある。SRE AIはその上にエージェント型のオーケストレーション層を追加する形で実装されている。
- チャットや動画、追跡ドキュメントなどインシデント中に発生するコミュニケーションを集約・要約
- 担当者交代時のハンドオフドキュメントを自動生成
- ポストモーテム（障害分析書）のドラフトを自動作成し、品質向上と工数削減に貢献
- 社内外向けのインシデント報告の管理
これらは一見地味だが、大規模インシデントでは情報の混乱が復旧遅延の最大要因になる。エージェントが情報整理を肩代わりすることで、SREは本質的な判断と対応に集中できる。
インシデント調査の自律化
AIエージェントは監視データ（ログ、メトリクス、トレース）に加え、システムトポロジや依存関係情報を使い、ドメイン知識を獲得した上で調査を開始する。ランブックのナビゲーション、アラート参照、異常検知、インサイト抽出といった個別の機能エージェントと連携しながら、仮説形成から緩和策の提案までを行う。状況によっては自律的な緩和実行も視野に入れている。
インサイトとリスク管理
AIエージェントが継続的に学習し続けるための仕組みとして、Google SREは「AI Insights」というシステムを開発した。これは過去の全インシデントを分析し、構造化された知見を抽出する。Geminiの埋め込みモデルとベクターデータベースを活用し、各インシデントにリスクカテゴリを自動付与する。これにより、エージェントは将来の調査時により精度の高い緩和策を提案でき、人間のSREも優先的に対処すべき領域を俯瞰できる。
このように複数のエージェントが役割分担しながら、一つのインシデントに対して協調的に動作する。単一の巨大なAIではなく、目的別に分割されたエージェント群が連携する設計思想がGoogle SREの特徴だ。
エージェント導入に先立つ7つの設計原則
Google SREはエージェントAIを闇雲に導入したわけではない。顧客への約束を守りながら信頼性を向上させるため、以下の7つの高レベル原則を定めている。
- 既存の自動化が機能している領域は、ビジネス要件を満たしている限り無理に置き換えない。
- 新しいAIシステムは、既存および将来のポリシーと手順に準拠すること。
- SRE AIエージェントは、人間と同等のセキュリティ・安全性・プライバシー要件を満たすこと。
- エージェントは強力なアイデンティティを持ち、ロールベースで権限が割り当てられること。
- エージェント自体に高い信頼性SLOを設定し、自動または手動のバックアップ手段を明確に用意すること。
- エージェントは実行したアクションの理由と、検討し却下した選択肢を説明できなければならない。ブラックボックス自動化より透明性を重視する。
- 事業継続計画にAI障害時のコンティンジェンシーを含めること。
とりわけ6番目の「説明可能性」は、SREという領域において極めて重要だ。なぜそのインシデントが発生し、なぜその緩和策を選んだのか。説明できない自動化は、ポストモーテム文化と相性が悪い。GoogleがエージェントAIに対して透明性を強く要求しているのは、SREの根本思想である「非難しない文化」と「学習する組織」をAI時代にも維持するためといえる。
この対比は、単なる技術選定の話ではない。SREの運用文化そのものをどう進化させるかという問いに直結している。
SRE AIを支えるGoogleの基盤技術
これらのエージェント群は、個別の新規プロジェクトとして開発されたものではない。Googleが長年培ってきたインフラストラクチャの上に構築されている。主要な構成要素は次のとおりだ。
- Gemini — 基盤モデル。SREチームは社内データでファインチューニングしたカスタムGeminiモデルも併用。
- Gemini Enterprise Agent Platform（旧Vertex AI） — エージェント開発のためのフルAIスタック。
- Agent Development Kit（ADK） — エージェント構築の開発プラットフォーム。
- MCPサーバー — 標準のGoogle APIインフラ上で動作し、外部顧客向けMCPサポートにも使われるものと同一基盤。
- BigQuery / ベクターデータベース — AI Insightsシステムのデータ基盤。Gemini埋め込みモデルと連携。
- 標準Observabilityインフラ — 監視、ログ、トレーシング。
特筆すべきは、これらの技術がすでにGoogle Cloudの顧客向けにも提供されている点だ。ホワイトペーパーで語られているSRE AIのアーキテクチャは、決してGoogle内部だけの秘伝のたれではなく、クラウド利用者にとっても参照可能な設計パターンとして公開されている。
SRE AIが目指す先
Google SREチームは、SRE AIが達成すべき目標として、次の5つを掲げている。
- 退屈で反復的な運用からエンジニアを解放する
- 意思決定と実行の質と速度を向上させる
- これまで対処できなかった問題の予防・検知・緩和を可能にする
- 信頼性向上に向けた自律的なフィードバックループを形成する
- 全体的な運用コストを削減する
これらは一見するとAI導入の一般的な利点に見える。しかしGoogle SREが強調するのは、単なる効率化ではない。AIが複雑さを増幅させた側面があるからこそ、同じAIを使って複雑さを制御するという考え方だ。SRE AIの本質は「AIがもたらした運用課題を、AI自身の力で解決する」逆説的なアプローチにある。
Googleは以前から自律システムを本番運用してきた実績を持つ。しかし現在のAIベースの自律システムは、非決定的な振る舞いをする点で従来と大きく異なる。この性質を正しく理解し制御するために、自律レベルのトラッキング手法も開発されている。詳細はホワイトペーパー「AI in SRE Practice: Moving Beyond Automation at Google」に譲るが、決定論的自動化からエージェントAIへの移行は、SREという分野にとって20年来の転換点になる可能性を秘めている。
この記事のポイント
- Google SREはAIエージェントを「力の倍増器」と位置づけ、運用の自動化レベルを次の段階へ引き上げている
- 静的な閾値監視からAIによる異常検知への移行は、多様なワークロードに対応するための不可避な進化である
- 7つの設計原則のなかでも「説明可能性」の重視は、SRE文化との整合性を保つ上でとりわけ重要だ
- SRE AIの構成要素はGoogle Cloudの顧客向け技術スタックと地続きであり、外部組織も同様のアーキテクチャを参照できる
- 決定論的自動化からエージェントAIへの移行は、SREの根本的な運用思想を再定義する可能性がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google AI Threat Defense発表、AIで脆弱性を自動修正する次世代セキュリティ
Google Cloudは2026年5月27日、AIを活用したセキュリティプラットフォーム「Google AI Threat Defense」を発表した。このシステムは脆弱性のスキャンから修正までを自律的に実行し、攻撃者が悪用する前に防御を固めることを目的としている。
AIの進化に伴い、攻撃者は従来の手作業による対策では追いつけないスピードで脆弱性を悪用するようになった。AI Threat DefenseはWiz、CodeMender、Gemini、Mandiantの各テクノロジーを統合し、組織が機械的な速度で脅威に対抗できる環境を提供する。
AI Threat Defenseが目指す次世代セキュリティ
近年、サイバー攻撃の高速化が顕著だ。従来は数週間かけて実施されていた攻撃が、AIエージェントの支援により数時間〜1日程度で完了するケースが増えている。防御側もこのスピードに追随する必要があり、人手による脆弱性管理やパッチ適用だけでは限界がある。
Google Cloud Blogの記事では、単一のAIモデルですべての脆弱性を捕捉することは難しく、コストと性能のバランスを取るために軽量なモデルと最先端のモデルを組み合わせて使うマルチモデル戦略が有効だと説明している。AI Threat Defenseは、ジェネレーティブAIの推論能力とコード生成能力を核に据えた自動防御システムとして、この考え方を具現化したものだ。
上の比較は、従来型の反応的なセキュリティ運用と、AI Threat Defenseがもたらす自律的な運用の差を端的に表している。プロセス全体が機械速度で回ることで、攻撃者が脆弱性を悪用する「タイムウィンドウ」を最小化できる点が最大の強みだ。
4つのコンポーネントが支える統合防御
AI Threat Defenseは、単一の製品ではなく、複数のクラウドセキュリティ技術を組み合わせた統合プラットフォームだ。基盤にはGoogleのジェネレーティブAIモデル「Gemini」の推論エンジンがあり、周辺にクラウドセキュリティの可視化を担うWiz、コード修正を自動化するCodeMender、そして現場のサイバー攻撃対策ノウハウを持つMandiantが配置される。
Wizによる可視化とリスク優先付け
WizはアプリケーションやAPI、ID、設定、ビジネスロジックなど、クラウド環境のあらゆる要素を継続的に可視化し、実際に悪用可能な攻撃パスをマッピングする。従来の攻撃面管理（ASM）を超え、AIペネトレーションテストエージェントが複雑な連鎖リスクを自動検証する。この結果、ただの脆弱性リストではなく、事業リスクを反映した優先順位付きの修復計画が出力される。
CodeMenderによる自律的なコード修正
CodeMenderはGeminiのコード生成力を活用し、開発者のIDEやCLIに直接パッチ候補を提示する。脆弱なコードの置換、レガシーコードのメモリ安全な言語への書き換え、ライブラリ依存関係の調整までをカバーし、修正後の自動テスト生成も行う。これにより、パッチの生成から検証までの時間が大幅に短縮される。
Geminiの推論とマルチモデル戦略
AI Threat DefenseはGemini Enterprise Agent Platform上で複数の最先端モデルを動かし、モデルごとに得意なタスク（アプリケーションロジック分析、クラウド設定監査、バイナリ解析など）に割り当てる。軽量モデルで広くスキャンし、フロンティアモデルを最高リスク領域に集中させることで、コスト効率と検出範囲の両立を実現している。
Mandiantの現場知見と運用ガイダンス
Mandiantはこれまでに蓄積したサイバー攻撃の最前線知識を、AI駆動の修復プロセスに注入する。重大な脆弱性が一気に表面化した場合の対応戦略や、旧式システムの安全な停止方法、AI生成パッチをエンジニアリングチームに負荷をかけずに展開するノウハウなど、実践的なガイダンスが提供される。
脅威対策の4段階フレームワーク
AI Threat Defenseの運用は「準備（Prepare）」「スキャンと優先順位付け（Scan and prioritize）」「修正（Remediate）」「監視（Monitor）」の4段階で構成される。各ステップがシームレスに連携し、攻撃者が悪用するスピードに追いつくための機械的なワークフローを形成する。
このフレームワークでは、各段階が独立しているのではなく、リアルタイムのリスク情報に基づいてループする。たとえば監視中に新たな暴露経路が見つかれば、即座にスキャンへ戻り、自動的にパッチが生成される。
STEP 1 準備（Prepare）
まず重要なのは、攻撃対象領域を最小化することだ。インターネットから直接到達可能なセンシティブな資産や、信頼できない経路で露出しているサービスを特定し、パッチの有無にかかわらず接続経路そのものを削減する。同時に、各チームの責任範囲とエスカレーションフローを明確化し、次の脆弱性が発見されたときに即応できる体制を整える。
STEP 2 スキャンと優先順位付け（Scan and prioritize）
この段階では、AIによる多層的な分析が行われる。軽量モデルで全資産を継続的にウォッチしつつ、インターネット向けアプリケーションや認証機能などビジネスクリティカルな部分にはフロンティアモデルを用いた深掘りスキャンを実施する。Wizのリアルタイムコンテキストと連携し、単なるコード上の欠陥ではなく「実際に攻撃可能か」という観点で優先度が決定される。
STEP 3 修正（Remediate）
特定された脆弱性は、CodeMenderによって自動的に修正案が生成される。開発者はIDE上でパッチ候補を確認し、承認するだけでよい。また、ライブラリの変更が他のコンポーネントに与える影響も分析され、複数リポジトリにまたがる安全なロールアウトが支援される。修正後には自動テストが走り、パッチの有効性を検証する仕組みも組み込まれている。
STEP 4 監視（Monitor）
最後の監視フェーズでは、Google Security Operationsが提供するエージェント型SOC機能を活用し、ネットワーク、ID、アプリケーションのテレメトリを横断的に分析する。AIが不審な挙動を自律的に検出し、場合によっては自動で封じ込めアクションを発動する。また、日次でビルド・署名されたハードニング済みコンテナイメージを用いることで、基盤自体のセキュリティも維持される。
実践導入とパートナーエコシステム
AI Threat Defenseは、単にツールを導入するだけでは機能しない。クラウドアーキテクチャに適したセキュリティ設計と、既存の開発パイプラインへの組み込みが必要になる。そのため、Google CloudはAccenture、Deloitte、PwC、Netenrich、TENEX.AIなどのパートナー企業と協業し、導入から継続的な管理、カスタムワークフローの構築までを支援する体制を整えている。
パートナー企業の役割
各パートナーは、顧客固有のクラウド構成を評価し、AI駆動のセキュリティ運用を定着させるためのハーネス（カスタム連携基盤）を開発する。これにより、組織ごとのコンプライアンス要件や運用ポリシーに合わせたきめ細かな防御が可能になる。
Google自身のセキュリティ実績
Google Cloudは、このプラットフォームを自らのセキュリティ運用実績の上に構築している。同社は10年以上にわたり、Titanチップによるハードウェア保護やZero Trustアーキテクチャの先駆的導入を進めてきた。現在も毎分数千万件のスパムを自動ブロックし、数十億のユーザーを保護している。こうしたノウハウが、AI Threat Defenseの設計思想に深く反映されている。
この記事のポイント
- AI攻撃の高速化に対抗するため、Google Cloudが自律型防御プラットフォーム「AI Threat Defense」を発表
- Wiz、CodeMender、Gemini、Mandiantの4要素を統合し、脆弱性の可視化からパッチ適用までを機械速度で自動化
- 従来の人間主導のプロセスでは数週間かかっていた対応が、数分〜数時間に短縮される見込み
- 「準備→スキャン→修正→監視」の4段階フレームワークで、攻撃者が悪用する前に防御を完了させる
- パートナー企業による実装支援と既存の開発パイプラインへの統合が、導入の鍵を握る
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google APIキーを守る3つの基本手順、悪用と高額請求のリスクを下げる
Google Geminiを含むAIサービスやGoogle Cloud APIを利用する上で、APIキーの安全な管理は避けて通れない課題だ。適切な対策を怠ると、キーの漏洩や悪用により、高額な請求やプロジェクト環境の侵害を引き起こす可能性がある。
APIキーは「使うのは簡単だが、安全でない方法で使うのも同じくらい簡単」とGoogle Cloud Blogの著者Leonid Yankulin氏は指摘する。この記事では、Googleが提供するAPIキーのリスクを大幅に下げるための、すぐに実践できる具体的な手順を解説する。
これらの対策の多くは、Googleに限らず他のサービスで発行されるAPIキーやプロダクトトークンにも応用可能だ。個人開発者から組織の管理者まで、キーの取り扱いを見直すきっかけにしてほしい。
Step 1. 新しいAPIキーは「隔離」と「制限」が大前提
APIキーを作成する際、最初からセキュリティを考慮しておくことで、後々のトラブルを未然に防げる。「とりあえず作成」して放置されている無制限のキーが、組織における最大のリスク要因の一つだ。
キーは専用プロジェクトで作成する
新しいAPIキーを生成する最初のルールは、他の目的に使っていない独立したGoogle Cloudプロジェクト内で作成すること。これにより、仮にキーが漏洩しても、被害がそのプロジェクトのリソースに限定される。
プロジェクトを分けることは、問題発生時の原因特定と影響範囲の調査を大幅に容易にする。本番環境と同じプロジェクトで実験用のAPIキーを発行するといった行為は避けるべきだ。
API制限で「できること」を絞る
APIキーを作成する際、デフォルトではAPI制限がかかっていない。これは、そのキーが有効化されているすべてのサービスにアクセスできる状態を意味する。Google Cloud Blogの著者は「制限のないキーを絶対に作るな」と強調する。
API制限を設定することで、キーがアクセスできるサービスを特定のAPIだけに絞り込める。たとえば、AI Studioで利用するなら「Gemini API」のみ、地図機能だけが必要なら「Maps API」だけに制限する。漏洩時の攻撃範囲を最小化する考え方だ。
注意すべき副次的なポイントとして、AI StudioやFirebaseなど間接的なUIからキーを作成した場合、意図しないAPI群が自動で許可されているケースがある。Firebase経由で作ったキーは24ものAPI（DatastoreやFirestore、Cloud SQLなど）へのアクセスが許可されるため、不要なものは手動で外す必要がある。
制限したいAPIが一覧に表示されない場合は、そのAPIが対象プロジェクトで有効化されていない可能性が高い。APIライブラリから事前に有効化しておく必要がある。
アプリケーション制限で「使う場所」を縛る
API制限が「どのサービスを使えるか」を制御するのに対し、アプリケーション制限は「どのアプリからキーを使えるか」を制御する。こちらも併用することで、セキュリティは飛躍的に高まる。
たとえばAI Studio専用のキーなら、許可するウェブサイトを aistudio.google.com に限定すれば、他のスクリプトや自動化ツールから大量のトークンを消費されるリスクを防げる。指定できる制限タイプは以下の4種類だ。
- ウェブサイト、許可するURLのリストを指定
- サービス（IPアドレス）、IPv4やIPv6アドレス、サブネットマスクで指定
- iOSアプリ、バンドルIDで指定
- Androidアプリ、パッケージ名と証明書フィンガープリントのペアで指定
注意点として、1つのキーに設定できるアプリケーション制限タイプは1種類だけ。複数のアプリ種別で利用する場合は、それぞれ専用のAPIキーを発行する。キーをアプリごとに分けておけば、利用状況の監視や侵害発生時の調査も容易になる。
ウェブサイト
https://aistudio.google.com自動化スクリプトからの呼び出し、不明なIPアドレスからのリクエスト、許可リストにないWebサイト
Step 2. APIキーは「誰でも使える」前提で保管する
APIキーの最大の特性は、特定の個人アカウントと紐づかない点にある。Google Cloud Blogの記事で「誰でも使える」と強調されているように、キー文字列を知っていれば誰でもその権限でAPIを呼び出せる。保管の安全性の重要性はAPI制限と同等だ。
「APIキーを絶対に、見えやすい場所に保存してはいけない」という基本ルールはシンプルだが、実際の開発現場ではしばしば破られている。ソースコードへのハードコードや、Gitリポジトリへの平文でのコミットは典型的なミスだ。
自社アプリケーションではSecret Managerを使う
Google Cloudを利用しているなら、Secret Manager（シークレットマネージャー）のような専用の機密情報管理サービスにキーを格納するのが鉄則だ。Secret Managerを使えば、APIキーをCloud RunやGKEの実行環境に安全に注入できる。
さらに保護レベルを上げたい場合は、キーを環境変数に渡すのではなく、アプリケーションコード内でSecret Managerから直接読み取る方式も選択肢になる。これによりランタイムメモリへの露出時間をさらに短縮できる。
外部アプリケーションではキーの取り扱いを事前調査する
サードパーティ製のツールやサービスにAPIキーを入力する場合、そのアプリケーションがキーをどのように保管し、通信しているかを確認する必要がある。
Webアプリケーションであれば、ブラウザの開発者ツールを使ってトラフィックを調査し、キーが暗号化されていない通信経路で送信されていないかを確認する。「Google AI Studioは暗号化されたローカルストレージを使用し、TLS暗号化チャネル経由でのみキーを送信する」とYankulin氏は具体例を挙げている。こうした設計を満たしていないツールへのキー提供は避けるべきだ。
異常を検知したら「即削除」、調査の手順も把握する
どんなに対策を施しても、キーが侵害される可能性はゼロにはできない。迅速な初動対応が被害を最小化する鍵を握る。Yankulin氏は「クレジットカードを無くしたときと同じように、まずキーを削除すること」と述べている。
Cloudコンソール、または gcloud services api-keys delete コマンドで即座にキーを無効化する。誤報だったと判明した場合でも、削除から30日以内であれば undelete コマンドで復元が可能だ。
侵害されたキーを特定する2段階調査
どのAPIキーが侵害されたか不明な場合は、以下の2段階で調査を進める。
第一段階、組織またはプロジェクト内のすべてのAPIキーを洗い出す。Cloudコンソールの「Asset Inventory」でリソースタイプを apikeys.Key に絞り込む方法と、gcloud services api-keys list コマンドを使う方法がある。組織全体を横断検索する場合は gcloud asset search-all-resources コマンドでJSON出力をフィルタリングする。
第二段階、API消費量のグラフを確認する。Cloud Monitoringの指標 serviceruntime.googleapis.com/api/request_count を使い、credential_id ラベルで特定のAPIキーIDに絞り込む。リクエスト数が異常に急増している場合、そのキーが悪用されている可能性が高い。
APIキーIDは、Cloudコンソールの「Credentials」ページでキーを選択した際のURL（/key/[KEY_ID] 部分）から、または gcloud services api-keys list --format='value(displayName,uid)' コマンドで確認できる。
1時間あたり数千リクエスト。日次グラフはなだらかで安定した波形
1時間あたり数十万リクエストに急増。短時間で不自然なスパイクが出現
Step 3. 日常的な「APIキー衛生管理」を習慣化する
エンジニアだけの話ではない。クラウドをかじり始めたばかりの個人ユーザーも、今すぐAPIキーの「衛生管理」を始めるべきだ。放置されたキーは、知らぬ間に悪用の温床となる。
Yankulin氏が推奨する即時実行すべきアクションは以下の5つだ。
- 自分が保有するすべてのAPIキーを洗い出す
- 使っていないキー、見覚えのないキーはすべて削除する（30日以内なら復元可能）
- 残すキーは、利用するAPIだけに制限し、可能ならクライアントも絞り込む
- 組織の管理者は
apikeys.googleapis.com/Keyの組織ポリシーを設定し、キーの乱立と制限設定の抜けを防ぐ - 定期的なキーのローテーション（再発行と差し替え）を検討する。ただし、既存キーを削除する前に、すべての利用箇所を特定して新しいキーに更新する周到さが必要だ
キーローテーションの際に「既存キーがどこで使われているのか把握しきれていない」という問題に直面するケースは多い。日頃からキーの利用箇所をドキュメント化しておくこと、そして新しいキーの発行時点から適切な制限をかけておくことが、結果的にローテーションのハードルを下げる。
この記事のポイント
- APIキーは「誰でも使える」クレデンシャル。見える場所に保管しないことが大前提
- 新規キー作成時は、API制限とアプリケーション制限を両方設定して攻撃の範囲を狭める
- 保管にはSecret Managerなど専用の機密情報管理サービスを使い、コードへのハードコードを避ける
- 使っていないキーや制限のないキーは即座に削除し、組織ポリシーで乱立を防ぐ
- 侵害が疑われる場合はクレジットカードと同じ感覚で「まず削除」。監視データで異常を検知する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GKE Agent Sandboxが一般提供開始。エージェント向け基盤Agent Substrateも発表
Google Cloudが2026年5月20日、エージェント実行環境「GKE Agent Sandbox」の一般提供（GA）を開始した。合わせて、超大量エージェントの高密度実行を目指す新たなOSSプロジェクト「Agent Substrate」を発表している。
2025年11月のKubeCon NAでプレビューが公開されて以降、Agent Sandbox上のサンドボックス数は5か月足らずで16倍以上に成長した。LangchainやLovableといった顧客がすでに数百万単位のエージェントを本番環境で動作させている。
自律的にコードを実行するAIエージェントにとって、インフラの安全性と起動速度は実用化の鍵となる。今回のGAで安定版APIが提供され、エージェント実行基盤としての成熟度が一段と上がった。
GKE Agent Sandbox GAの主要な機能強化点
GKE Agent SandboxはKubernetes上に構築されたOSSの実行環境だ。AIエージェントが信頼できないコードを安全かつ高速に実行するための基盤として設計されている。今回のGAでは、実運用で課題となるアイドル状態の効率化と、起動レイテンシの低減に焦点が当てられた。
Pod Snapshotによるアイドルリソースの削減
エージェントのワークロードは、短いバースト的な処理の後に長いアイドル時間が続くという特徴を持つ。従来のようにアイドル中もPodを起動したままにしておくと、コンピュートリソースを無駄に消費してしまう。
GKE Agent SandboxはPod Snapshot機能と統合されている。アイドル状態のエージェントワークロードを一時停止（サスペンド）し、リクエストが来たときに数秒で再開できる。Google Cloudの発表によれば、この仕組みで不要なコンピュートコストを大幅に削減できるという。
Pod Snapshotの最大の利点は、エージェントワークロード特有の「使うときだけ高速に起動したい」という要求に応えられる点だ。サスペンド状態からの復帰は数秒で完了するため、ユーザーの待ち時間を最小限に抑えられる。
ウォームプールによる低レイテンシプロビジョニング
エージェントのリクエストが来るたびに新しいサンドボックスを作成すると、コールドスタートによる数秒の遅延が発生する。この遅延はエージェントの応答性を損ない、ユーザー体験を悪化させる要因となる。
GKE Agent Sandboxは、サンドボックスAPIにウォームプールを統合した。あらかじめ準備されたサンドボックスレプリカをプールしておき、リクエスト発生時に即座に割り当てる仕組みだ。これにより、1クラスタあたり毎秒300のサンドボックスを割り当て可能で、割り当ての90パーセントが200ミリ秒以内に完了する。
ウォームプールのコスト最適化も考慮されている。プール内のレプリカは常時稼働しているが、スタンバイキャパシティバッファと統合することで、一部のサンドボックスをサスペンド状態で待機させられる。ウォームプールが枯渇した際には、この「コールドプール」から素早く補充され、大幅なコスト削減につながる。
gVisorとネットワークポリシーによる強固な隔離
セキュリティ面では、gVisorをネイティブサポートし、デフォルト拒否のKubernetesネットワークポリシーを採用している。gVisorはユーザースペースで動作するカーネルであり、ホストOSから隔離された環境を提供する。コンテナ内のプロセスがホストカーネルに直接アクセスできないため、悪意あるコード実行のリスクを大幅に低減できる。
さらにKata ContainersのようなOSSサンドボックスにも対応するプラグイン可能なインターフェースを備えている。利用者は自社のセキュリティ要件に合わせてカーネル隔離レベルを選択できる。
コンピュートの選択肢も広がった。Google Cloud独自のAxionプロセッサ上でAgent Sandboxを実行すると、同等のハイパースケーラークラウドプロバイダと比較して最大30パーセント優れた価格性能比を達成すると発表されている。
Agent Substrateがもたらす次の変革
エージェントワークロードは今後、数千万から数億インスタンス規模へとスケールアップしていく。同時に、人間の操作やイベントを待つアイドル時間もますます長くなる。カーネルとネットワークの隔離を維持しながら高密度にスケジュールするのは、既存のKubernetesコントロールプレーンでは限界が近づいている。
この課題に対してGoogle Cloudが発表したのが、新たなOSSプロジェクト「Agent Substrate」だ。
Kubernetesの限界を超える最小限のコントロールプレーン
Agent Substrateは、Agent Sandboxの安全なランタイムとSnapshot機能を中核に据えつつ、Kubernetesの制約を部分的に回避する最小限のコントロールプレーンを組み合わせる。標準のKubernetesが数千の長時間稼働サービスを扱うのに最適化されているのに対し、Agent Substrateは数百万単位のサブ秒ツール呼び出しの「チャタリング」に耐えられるよう設計されている。
新たな抽象化レイヤーを導入し、Kubernetes上で稼働するコンピュートキャパシティに対して、エージェントをリアルタイムに乗せたり外したりする。Google Cloudの発表では、従来のコントロールプレーンでは処理しきれない高頻度の短命ワークロードに対して、レイテンシを低減しつつスケールと効率を最適化できるとしている。
Agent Substrateの目標は、現在のコンピュートインフラの限界を押し広げることにある。一例として、エージェントの状態とスケジューリングが協調して動作するようデータの局所性をスケジューラの中核に組み込む構想も示された。オーバーヘッドを1ミリ秒単位で削り取るため、あらゆる可能性を探求する姿勢が打ち出されている。
Agent HarnessやAgent Executorとの関係
Agent Substrateは、単独で動作するものではなく、エージェントエコシステム全体の基盤レイヤーとして位置づけられている。Agent HarnessやAgent Runtime、さらにはGoogle Cloudが別途発表している分散エージェントランタイム「Agent Executor」プロジェクトを支える役割を担う。
Google Cloudのブログ記事では、Agent Substrateを「エージェントネイティブなインフラストラクチャの次の章」と表現している。Kubernetesが登場初期に多様なコントリビューターの知見を集めて成功したように、エージェントインフラも同じ転換点にあるという認識が示された。
この記事のポイント
- GKE Agent Sandboxが一般提供開始。安定版APIでエージェント実行の本番運用に対応
- Pod Snapshotでアイドル時のリソース消費を抑え、リクエスト時に数秒で復元可能
- ウォームプールにより毎秒300サンドボックスをサブ秒で割り当て。コスト最適化も統合
- 新OSSプロジェクトAgent Substrateは数百万規模の短命ワークロードに特化した設計
- Axionプロセッサ利用時に最大30パーセントの価格性能比向上を達成
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google Cloud、AI脅威レポートで攻撃者によるゼロデイ発見・自律型マルウェアの実態を公開
Google Cloudの脅威インテリジェンスグループGTIGが2026年5月、最新のAI脅威トラッカー報告を公開した。今回の報告では、攻撃者がAIを悪用してゼロデイ脆弱性を発見した初めての事例が確認され、また自律的に動作するマルウェア「PROMPTSPY」の詳細な分析結果が示された。
報告書はAIに関する脅威を「ツールとしてのAI」と「標的としてのAI」の2軸で整理。攻撃者は脆弱性発見の自動化や防御回避コードの生成だけでなく、AIの開発エコシステム自体を狙ったサプライチェーン攻撃も活発化しているという。本記事では、この報告書の重要ポイントを実務者向けにわかりやすく解説する。
AIが攻撃ツールに ゼロデイ発見から自律型マルウェアまで
- 脆弱性発見の自動化とゼロデイエクスプロイト開発
- マルウェアコードの生成や難読化による検知回避
- 攻撃ライフサイクルの自律実行（PROMPTSPY等）
- OpenClawスキルへの悪意あるコード混入
- LiteLLMやGitHubリポジトリへのサプライチェーン攻撃
- AI APIキーやクラウド認証情報の窃取
今回の報告では、攻撃者が生成AIを業務効率化ツールとして悪用する段階から、攻撃そのものの中核に組み込むフェーズへと急速に移行している実態が浮き彫りになった。
AIがゼロデイを発見 犯罪グループが初の成功事例
GTIGの観測によると、ある犯罪グループが広く使われているオープンソースのシステム管理ツールを標的に、二要素認証（2FA）をバイパスするゼロデイ脆弱性を開発した。このエクスプロイトには、AIが生成したとみられる強い痕跡が残っており、GTIGが初めて「AIによるゼロデイ開発」を確認した事例となった。ベンダーへの責任ある開示を通じて、大規模な悪用を未然に防げたという。
コードを解析すると、詳細なドキュメント文字列や幻覚（ハルシネーション）で誤ったCVSSスコアが付与されているなど、LLMが出力する典型的な「教科書的Python記法」が随所に見られた。これは従来のファジングや静的解析ツールでは検出できないタイプの脆弱性だ。LLMは開発者が暗黙的にハードコードした「信頼前提」を読み解いて、2FA実装の矛盾を突くことができる。
- メモリ破損や入力値不備の検出に強い
- 開発者の「暗黙の信頼」に気づけない
- 大規模コードベースでは誤検知が多い
- コードの文脈を読み取り、意図と実装の矛盾を特定
- 2FAバイパスのような高次ロジックの欠陥を検出可能
- 人間のセキュリティ研究者に近い推論を実現
この能力差が、従来の防御策では防ぎきれない新たな脅威を生み出している。報告書は、攻撃者がAIを「専門家レベルの増幅器」として活用し始めたと警告する。
防御回避を自動化するAI生成のデコイコード
GTIGは、ロシアに関連するとみられる侵入活動の中で、AIが生成したデコイ（囮）コードを大量に含むマルウェア「CANFAIL」と「LONGSTREAM」を確認した。CANFAILのソースには「このコードブロックは使用されない」といったLLM特有の解説コメントが含まれており、攻撃者が意図的に無害に見せかけるためのダミー機能を要求した形跡がある。
LONGSTREAMでは、システムのサマータイム設定を32回も照会するといった、意味のない繰り返し処理が組み込まれていた。これらは振る舞い検知をかく乱し、セキュリティ製品による分析を遅らせる目的がある。AIが難読化ツールとして悪用され、マルウェアが動的に自己変形する方向へ進んでいることを示す事例だ。
PROMPTSPYにみる自律型マルウェアの脅威
Androidバックドア「PROMPTSPY」は、AIを攻撃の中核に据えた自律型マルウェアとして注目されている。ESETが初めて報告したこのマルウェアは、Gemini APIを用いて端末の画面情報を取得し、ユーザーの操作を必要とせずに不正なタップやスワイプを実行する。GTIGの追加分析によって、当初知られていた以上の拡張性と防御機能を持つことが判明した。
Accessibility APIで画面のUI階層をXML形式で取得
Gemini APIにXMLを送り、動的に生成された目標に沿った操作を指示
JSONで戻された座標とアクション種別（CLICK、SWIPE）をもとにジェスチャーをシミュレート
アンインストールボタンに透明オーバーレイを被せてタップを無効化。FCMで遠隔再起動も可能
また、PROMPTSPYは被害者の生体認証（PINやパターン）を記録して再現する機能を持ち、遠隔からデバイスへの再侵入を可能にする。C2サーバやAPIキーを動的に切り替える仕組みも備えており、防御側のブロックを回避する設計思想が随所に見られる。Googleは既に関連アカウントを無効化し、Google Play Protectで既知の亜種を自動検出できるようにしている。
AIを利用した情報工作とLLMへの大規模アクセス
情報工作の領域でもAIの悪用は進んでいる。親ロシアキャンペーン「Operation Overload」では、AIで合成された音声を使って実在のジャーナリストを装う偽動画が拡散された。こうしたコンテンツは、正規メディアの信用を乗っ取る手口として使われる。
一方で、攻撃者はLLMのプレミアム機能を不正に利用するため、アカウント登録と即時解約を自動化するスクリプトや、複数アカウントを束ねる中継サービスを駆使している。UNC6201やUNC5673といった中国関連の攻撃グループは、こうした手法で大量のAPIアクセスを確保し、不正利用の痕跡を分散させていた。LLM提供事業者は、ネットワーク情報を分析してアグリゲーターを特定し、悪用を阻止する対策を強化しつつある。
AI自身が標的に サプライチェーン攻撃の実態
AIモデルそのものは依然として直接の侵害には強いが、モデルを動かす周辺のソフトウェア部品（ライブラリ、APIコネクタ、スキル設定ファイル）が新たな侵入口になっている。GTIGはこの状況を、SAIF（Secure AI Framework）のリスク分類でいう「安全でない統合コンポーネント（IIC）」と「不正な動作（RA）」に該当すると指摘する。
オープンソースのAIエコシステムが狙われる
2026年2月には、AIエージェントプラットフォーム「OpenClaw」のスキルマーケットプレイスに、悪意あるコードを仕込んだパッケージが流通していることがVirusTotalの調査で明らかになった。OpenClawは実行に高い権限を必要とするため、トロイの木馬化されたスキルをインストールしたユーザーの環境で任意のコードが実行される恐れがある。その後、OpenClawはClawHubにVirusTotalの自動スキャンを統合し、悪意あるパッケージを検出する仕組みを導入した。
TeamPCPによるLiteLLMやGitHubリポジトリへの侵害
犯罪グループ「TeamPCP（UNC6780）」は、2026年3月に複数のGitHubリポジトリをサプライチェーン攻撃で侵害したことを公言した。標的には、複数のLLMプロバイダを統合するAIゲートウェイ「LiteLLM」や、脆弱性スキャナ「Trivy」「Checkmarx」などが含まれている。被害組織のビルド環境からはAWSキーやGitHubトークンといったクラウド認証情報が窃取され、ランサムウェアグループとの連携によって金銭目的の恐喝に利用された。
この事例が示すのは、AI関連の依存関係が侵害された場合、攻撃者は単にAIシステムを操作するだけでなく、そこから企業ネットワーク全体へ横展開できるというリスクだ。LiteLLMのような広く使われるライブラリを経由して、多数の組織のAI APIシークレットが流出する可能性がある。
企業に求められるAI脅威への対策
Googleは自社の防御策として、Geminiの悪用アカウントの無効化、AIエージェント「Big Sleep」による未知の脆弱性探索、そして「CodeMender」による脆弱性の自動修正など、AIを守りに使う取り組みを進めている。同時に、業界全体での対策フレームワークとしてSAIFを提唱し、CoSAI（Coalition for Secure AI）を通じてパートナーとの連携を強化している。
実務者が今すぐ着手できる対策としては、以下の点が重要だ。まず、AI関連のオープンソースライブラリやスキルパッケージを導入する際には、提供元の信頼性とコードの挙動を必ず確認する。APIキーやクラウド認証情報は短い有効期限と最小権限で管理し、定期的にローテーションする。さらに、AIを利用するアカウントには多要素認証を適用し、不審なAPI呼び出しを検知する監視体制を整えることが有効だ。
この記事のポイント
- GTIGが2026年5月に発表した報告で、AIによるゼロデイエクスプロイト開発が初確認された
- 攻撃者はAIを使ってマルウェアの難読化や自律的な操作を実現し、攻撃の効率を飛躍的に高めている
- PROMPTSPYのような自律型マルウェアは、人間の介在なしに端末を操作し、防御を回避する仕組みを備える
- AIエコシステムを狙ったサプライチェーン攻撃が急増し、APIキーや認証情報の大量窃取が現実の脅威となっている
- 企業はAI関連の依存コンポーネントの厳格な管理と、APIアクセスの監視強化でリスクを軽減すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験