Category Archive クラウド・インフラ

Google APIキーを守る3つの基本手順、悪用と高額請求のリスクを下げる

Google APIキーを守る3つの基本手順、悪用と高額請求のリスクを下げる

Google Geminiを含むAIサービスやGoogle Cloud APIを利用する上で、APIキーの安全な管理は避けて通れない課題だ。適切な対策を怠ると、キーの漏洩や悪用により、高額な請求やプロジェクト環境の侵害を引き起こす可能性がある。

APIキーは「使うのは簡単だが、安全でない方法で使うのも同じくらい簡単」とGoogle Cloud Blogの著者Leonid Yankulin氏は指摘する。この記事では、Googleが提供するAPIキーのリスクを大幅に下げるための、すぐに実践できる具体的な手順を解説する。

これらの対策の多くは、Googleに限らず他のサービスで発行されるAPIキーやプロダクトトークンにも応用可能だ。個人開発者から組織の管理者まで、キーの取り扱いを見直すきっかけにしてほしい。

Step 1. 新しい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など)へのアクセスが許可されるため、不要なものは手動で外す必要がある。

未制限キーのリスク(Before)
流出キー Gemini API Maps API Cloud SQL Firestore
あらゆるAPIにアクセスされ、被害が拡大
制限設定後のキー(After)
流出キー Gemini API Maps API Cloud SQL Firestore
Gemini APIだけが悪用されるが、他のサービスは保護される

制限したいAPIが一覧に表示されない場合は、そのAPIが対象プロジェクトで有効化されていない可能性が高い。APIライブラリから事前に有効化しておく必要がある。

アプリケーション制限で「使う場所」を縛る

API制限が「どのサービスを使えるか」を制御するのに対し、アプリケーション制限は「どのアプリからキーを使えるか」を制御する。こちらも併用することで、セキュリティは飛躍的に高まる。

たとえばAI Studio専用のキーなら、許可するウェブサイトを aistudio.google.com に限定すれば、他のスクリプトや自動化ツールから大量のトークンを消費されるリスクを防げる。指定できる制限タイプは以下の4種類だ。

  • ウェブサイト、許可するURLのリストを指定
  • サービス(IPアドレス)、IPv4やIPv6アドレス、サブネットマスクで指定
  • iOSアプリ、バンドルIDで指定
  • Androidアプリ、パッケージ名と証明書フィンガープリントのペアで指定

注意点として、1つのキーに設定できるアプリケーション制限タイプは1種類だけ。複数のアプリ種別で利用する場合は、それぞれ専用のAPIキーを発行する。キーをアプリごとに分けておけば、利用状況の監視や侵害発生時の調査も容易になる。

アプリケーション制限の設定イメージ(AI Studio専用キーの場合)
許可アプリ
ウェブサイト https://aistudio.google.com
ブロックされるアクセス例
自動化スクリプトからの呼び出し、不明なIPアドレスからのリクエスト、許可リストにないWebサイト

Step 2. APIキーは「誰でも使える」前提で保管する

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氏は具体例を挙げている。こうした設計を満たしていないツールへのキー提供は避けるべきだ。

安全なキー保管のチェックフロー
STEP 1 キーをソースコードに書いていないか確認
STEP 2 Secret Managerなど専用サービスに格納する
STEP 3 外部ツール利用時は、暗号化保存とTLS通信を確認する
STEP 4 Gitのコミット履歴にもキーが含まれていないか最終チェック

異常を検知したら「即削除」、調査の手順も把握する

異常を検知したら「即削除」、調査の手順も把握する

どんなに対策を施しても、キーが侵害される可能性はゼロにはできない。迅速な初動対応が被害を最小化する鍵を握る。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)' コマンドで確認できる。

API消費量の異常検知イメージ
通常時のリクエスト数
1時間あたり数千リクエスト。日次グラフはなだらかで安定した波形
侵害発生時のリクエスト数
1時間あたり数十万リクエストに急増。短時間で不自然なスパイクが出現
異常なスパイク  通常レンジ

Step 3. 日常的な「APIキー衛生管理」を習慣化する

Step 3. 日常的な「APIキー衛生管理」を習慣化する

エンジニアだけの話ではない。クラウドをかじり始めたばかりの個人ユーザーも、今すぐAPIキーの「衛生管理」を始めるべきだ。放置されたキーは、知らぬ間に悪用の温床となる。

Yankulin氏が推奨する即時実行すべきアクションは以下の5つだ。

  • 自分が保有するすべてのAPIキーを洗い出す
  • 使っていないキー、見覚えのないキーはすべて削除する(30日以内なら復元可能)
  • 残すキーは、利用するAPIだけに制限し、可能ならクライアントも絞り込む
  • 組織の管理者は apikeys.googleapis.com/Key の組織ポリシーを設定し、キーの乱立と制限設定の抜けを防ぐ
  • 定期的なキーのローテーション(再発行と差し替え)を検討する。ただし、既存キーを削除する前に、すべての利用箇所を特定して新しいキーに更新する周到さが必要だ

キーローテーションの際に「既存キーがどこで使われているのか把握しきれていない」という問題に直面するケースは多い。日頃からキーの利用箇所をドキュメント化しておくこと、そして新しいキーの発行時点から適切な制限をかけておくことが、結果的にローテーションのハードルを下げる。

キー衛生管理の3大習慣
棚卸し 全プロジェクトのAPIキーを月次でリストアップし、使っていないものは即削除
制限設定 新規キーは必ずAPI制限とアプリケーション制限をかけてから使い始める
ローテーション 四半期ごとにキーを再発行し、利用箇所を更新。跡地の旧キーは速やかに削除

この記事のポイント

  • APIキーは「誰でも使える」クレデンシャル。見える場所に保管しないことが大前提
  • 新規キー作成時は、API制限とアプリケーション制限を両方設定して攻撃の範囲を狭める
  • 保管にはSecret Managerなど専用の機密情報管理サービスを使い、コードへのハードコードを避ける
  • 使っていないキーや制限のないキーは即座に削除し、組織ポリシーで乱立を防ぐ
  • 侵害が疑われる場合はクレジットカードと同じ感覚で「まず削除」。監視データで異常を検知する
GKE Agent Sandboxが一般提供開始。エージェント向け基盤Agent Substrateも発表

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 GAの主要な機能強化点

GKE Agent SandboxはKubernetes上に構築されたOSSの実行環境だ。AIエージェントが信頼できないコードを安全かつ高速に実行するための基盤として設計されている。今回のGAでは、実運用で課題となるアイドル状態の効率化と、起動レイテンシの低減に焦点が当てられた。

Pod Snapshotによるアイドルリソースの削減

エージェントのワークロードは、短いバースト的な処理の後に長いアイドル時間が続くという特徴を持つ。従来のようにアイドル中もPodを起動したままにしておくと、コンピュートリソースを無駄に消費してしまう。

GKE Agent SandboxはPod Snapshot機能と統合されている。アイドル状態のエージェントワークロードを一時停止(サスペンド)し、リクエストが来たときに数秒で再開できる。Google Cloudの発表によれば、この仕組みで不要なコンピュートコストを大幅に削減できるという。

従来のPod管理
Pod アイドル中も常時稼働し続ける
※リソースを継続的に消費し、コストがかさむ
Pod Snapshot適用後
Pod アイドル時にサスペンド Snapshot から数秒で復元
※アイドル中のリソース消費を大幅抑制

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がもたらす次の変革

Agent Substrateがもたらす次の変革

エージェントワークロードは今後、数千万から数億インスタンス規模へとスケールアップしていく。同時に、人間の操作やイベントを待つアイドル時間もますます長くなる。カーネルとネットワークの隔離を維持しながら高密度にスケジュールするのは、既存のKubernetesコントロールプレーンでは限界が近づいている。

この課題に対してGoogle Cloudが発表したのが、新たなOSSプロジェクト「Agent Substrate」だ。

Kubernetesの限界を超える最小限のコントロールプレーン

Agent Substrateは、Agent Sandboxの安全なランタイムとSnapshot機能を中核に据えつつ、Kubernetesの制約を部分的に回避する最小限のコントロールプレーンを組み合わせる。標準のKubernetesが数千の長時間稼働サービスを扱うのに最適化されているのに対し、Agent Substrateは数百万単位のサブ秒ツール呼び出しの「チャタリング」に耐えられるよう設計されている。

新たな抽象化レイヤーを導入し、Kubernetes上で稼働するコンピュートキャパシティに対して、エージェントをリアルタイムに乗せたり外したりする。Google Cloudの発表では、従来のコントロールプレーンでは処理しきれない高頻度の短命ワークロードに対して、レイテンシを低減しつつスケールと効率を最適化できるとしている。

標準Kubernetesの限界
Control Plane 数千の長時間稼働Podを管理
※数百万の短命呼び出しには設計上対応しきれない
Agent Substrate
Minimal CP サブ秒の短命呼び出しに特化
Sandbox をリアルタイムに割り当て/解放
※高頻度な要求に対して低レイテンシと高効率を両立

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パーセントの価格性能比向上を達成
Gemini 3.5 Flash がVercel AI Gatewayで利用可能に。並列処理能力と推論機能が大幅向上

Gemini 3.5 Flash がVercel AI Gatewayで利用可能に。並列処理能力と推論機能が大幅向上

Googleの最新モデル「Gemini 3.5 Flash」が2026年5月19日からVercel AI Gatewayで利用可能になった。このモデルはコーディング能力と並列エージェント実行ループの性能が大きく向上し、複雑なタスクでも高い推論精度を発揮する。

AI Gatewayの統合APIを通じて呼び出せ、使用量の追跡やコスト管理、リトライやフェイルオーバーの設定も標準で備わっている。開発者は面倒な基盤管理なしに、最新のAIモデルを本番環境へ素早く組み込める。

この記事では、Gemini 3.5 Flash の進化点、AI Gateway での具体的な使い方、実装時の注意点までを整理する。

Gemini 3.5 Flash の概要と新モデルの位置づけ

Gemini 3.5 Flash の概要と新モデルの位置づけ

Flash シリーズの進化

Gemini Flash シリーズは、Google が提供する軽量で応答速度に優れたAIモデル群だ。前世代のFlash 2.0と比べて、3.5 Flash では単なる速度向上にとどまらず、複数ステップのタスクを自律的に並列実行できるようになった点が大きな違いだ。

これにより、コーディングの効率化や、複数のAPIを同時に呼び出すようなエージェント型アプリケーションで強力なパフォーマンスを発揮する。

今回のアップデートで強化された点

  • コーディング補完の精度向上
  • 並列エージェント実行ループの大幅な最適化
  • コア推論能力と命令追従性の改善
  • マルチターン会話の一貫性向上
  • 思考モード(thinking mode)での高品質な推論トレースの生成

並列エージェント実行ループの進化

並列エージェント実行ループの進化

並列化によるパフォーマンス向上

従来のFlashモデルは、一連のタスクを逐次的に処理する傾向があった。たとえばコードリファクタリングの際に「API呼び出しAの完了を待ってからAPI呼び出しBを実行する」といった流れになる。これに対し、3.5 Flash は複数の独立した処理を同時に並列実行する能力が格段に上がっている。

並列実行のメリットは、応答待ち時間の大幅な短縮と、システム全体のスループット向上だ。特にマイクロサービス間の連携や、複数の外部データソースを一括で処理する場面で効果を発揮する。

従来の Flash モデル(逐次実行)
API呼び出し1 API呼び出し2 API呼び出し3
※順次実行のため全体の処理時間が長くなる
Gemini 3.5 Flash(並列エージェント実行)
API呼び出し1 API呼び出し2 API呼び出し3
※並列実行で待ち時間を大幅短縮、全体のレスポンスタイムが向上

この比較はあくまで概念図だが、実際のアプリケーションでは複数の独立した処理を同時に走らせることで、体感速度やスループットが大きく改善される。

thinking モードと推論トレースの強化

thinking モードと推論トレースの強化

thinking level の選択

Gemini 3.5 Flash はデフォルトで「medium」のthinking levelが設定されている。これは、応答の品質と生成速度、そしてコスト効率のバランスを取るための設計だ。より複雑な推論が必要な場合は high レベルに変更することも可能で、その場合は推論プロセスがより深く行われる。

たとえば、コードのリファクタリングや多段階の意思決定が必要なタスクでは、thinking level を high に設定することで、AIが問題をより細かく分解し、質の高い答えを導き出す。

マルチターンコヒーレンスと複雑タスク

3.5 Flash では、マルチターンの会話における一貫性も改善されている。以前のFlashモデルに比べて、前のやり取りを適切に保持しながら、矛盾のない回答を返す精度が向上している。これにより、長時間のコード生成や、会話型のエージェントアプリケーションでも安定した挙動が期待できる。

複雑なタスクでは「thinking traces(思考の痕跡)」がより詳細に出力されるため、モデルがどのような過程で結論に至ったかを検証しやすい。デバッグや品質管理の面で大きなメリットだ。

Vercel AI Gateway の機能とメリット

Vercel AI Gateway の機能とメリット

統合APIとプロバイダールーティング

Vercel AI Gatewayは、複数のAIプロバイダーを統一的なインターフェースで利用できるプラットフォームだ。開発者はプロバイダーごとに異なるAPIキー管理やエンドポイントを意識することなく、model の指定だけでモデルを切り替えられる。

さらに、AI Gatewayはインテリジェントなルーティング機能を備えており、特定のプロバイダーに障害が発生した場合に自動で別のモデルへフェイルオーバーしたり、リクエストをリトライしたりできる。これにより、単一プロバイダーを直接使うよりも可用性が向上する。

観測性とカスタムレポート

AI Gatewayには、使用量の追跡やコスト分析のためのカスタムレポート機能が組み込まれている。プロジェクトごと、環境ごとにAPI呼び出し回数やトークン消費量を可視化できるため、予算管理やボトルネックの発見に役立つ。

また、AI SDK Observability との連携により、モデルの応答時間やエラーレートを詳細に監視できる。Bring Your Own Key にも対応しており、自社で契約したAPIキーをAI Gateway経由で安全に利用できる点も企業ユースに適している。

AI SDK での実装方法と注意点

AI SDK での実装方法と注意点

コード例

AI SDK を用いて Gemini 3.5 Flash を呼び出すには、以下のように streamText 関数を使う。モデル名に google/gemini-3.5-flash を指定し、必要に応じて thinking level を設定する。

import { streamText } from 'ai';

const result = streamText({
  model: 'google/gemini-3.5-flash',
  prompt: 'Refactor this service to run API calls in parallel.',
  providerOptions: {
    google: {
      thinkingConfig: {
        thinkingLevel: 'high',
        includeThoughts: true,
      },
    },
  },
});

thinking level は 'medium'(デフォルト)と 'high' から選択でき、複雑なタスクでは 'high' を指定すると良い。なお、includeThoughts: true にすると推論過程のトレースもレスポンスに含められる。

サポート外のパラメータと制約

Gemini 3.5 Flash では temperaturetopPtopKthinking_budget といったパラメータはサポートされていない。以前のモデルでこれらの値を調整していた場合は、デフォルトの挙動に任せるか、他のモデルを検討する必要がある。

特に thinking_budget が使えない点は、推論にかかるコストを細かく制御したい場合に注意が必要だ。そのぶん thinking level の切り替えで大まかな品質とコストのバランスを取る設計になっている。

この記事のポイント

  • Gemini 3.5 Flash は並列エージェント実行ループの性能が大幅に向上し、コーディングや複数API呼び出しに強い
  • デフォルトで medium の thinking level を採用し、品質・速度・コストのバランスを最適化
  • Vercel AI Gateway によって統合API、リトライ、フェイルオーバー、観測機能をフル活用できる
  • temperature や topP などの一部パラメータは非対応のため、移行時には注意が必要
  • AI SDK 経由で数行のコードで導入可能、並列化のメリットをすぐに享受できる
Vercelがソースマップ保護機能を発表、本番環境のコード露出を防止

Vercelがソースマップ保護機能を発表、本番環境のコード露出を防止

Vercelは2026年5月、本番環境のソースマップを安全に配信する新機能「Protected Source Maps」をリリースした。ブラウザが読み取る .map ファイルを Vercel Authentication の背後に置き、開発チームだけがアクセスできる仕組みだ。これにより、デバッグ情報を必要な人間にだけ提供し、それ以外の第三者には 404 を返す。

フロントエンドのバンドルは本番ビルドで圧縮・ミニファイされるため、可読性を保つにはソースマップが欠かせない。しかし従来は、そのソースマップが認証なしで公開されてしまい、コードの内部ロジックやコメントが誰でも閲覧できる状態だった。Protected Source Maps は、このセキュリティリスクを根本的に解決する。

ソースマップがなぜ重要か

ソースマップがなぜ重要か

ミニファイとデバッグのジレンマ

本番サイトの JavaScript や CSS は、ファイルサイズ削減のためにミニファイされる。変数名を短縮し、空白やコメントを取り除く処理だ。ところが、エラーが発生したとき、ブラウザのコンソールには圧縮後のコードしか表示されず、スタックトレースが「at a.a (bundle.js:1:2345)」のように読めなくなる。デバッグがほぼ不可能になるのだ。

この問題を解決するのがソースマップである。ミニファイ元のファイル名や行番号、元の変数名を記録した .map ファイルとして生成し、ブラウザがそれを使って元のソースコードを復元する。つまり、ビルド後の難読コードを、開発時の読みやすいコードに戻す「翻訳辞書」のような役割だ。

ソースマップの仕組み

ソースマップは通常、ミニファイされたファイルの末尾に //# sourceMappingURL=app.js.map というコメントを挿入することでブラウザに通知される。ブラウザがこのコメントを見つけると、対応する .map ファイルを別途リクエストし、デベロッパーツール上でオリジナルのソースコードを表示する。ここまでは開発者にとって日常的な光景だ。

しかし、本番環境でこの .map ファイルが認証なしに取得できると、第三者が容易にソースコードを読めてしまう。公開を想定していないコメントや、内部のビジネスロジックがダダ漏れになるリスクがある。

本番ソースマップが晒されてきたリスク

本番ソースマップが晒されてきたリスク

従来の典型的な対策は、ビルド時にソースマップを生成しないか、本番サーバーにアップロードしないというものだった。しかし、それでは本番環境で発生したエラーの調査が困難になる。また、サーバー側で特定の IP アドレスや VPN 経由のみアクセスを許可する方法もあるが、設定が複雑で、動的に変わるチームメンバーの管理には向かない。

実際に、JavaScript フレームワークの設定ミスによってソースマップが公開され、内部の API キーやテスト用のパスワードが漏えいした事例も報告されている。ソースマップは開発者にとって便利な一方、扱いを誤ると大きなセキュリティホールになりうる。

従来(ソースマップが公開されている場合)
GET /assets/app.js.map
200 OK(全文返却)
※認証なしで誰でもソースコードを参照可能
Protected Source Maps 有効時
GET /assets/app.js.map
404 Not Found
(未認証の場合)
認証チーム
200 OK(デバッグ可能)
※Vercel Authentication を通した開発者のみアクセス可能。その他は 404

上の図は、認証がない場合と今回の保護機能を適用したあとの応答の違いを示している。従来は誰でも .map を取得できたが、Protected Source Maps を有効にすると、チーム外のリクエストには 404 Not Found が返る。

Protected Source Maps の動作と設定

Protected Source Maps の動作と設定

Vercel Authentication によるアクセス制限

この機能の核は、プロジェクトの .map ファイルが Vercel Authentication で保護される点にある。通常、Vercel Authentication はデプロイプレビューや特定のパスをチームメンバーだけに公開するために使われる認証フレームワークだ。今回これがソースマップにも適用された。

つまり、ブラウザがソースマップをリクエストしても、Vercel のエッジネットワークが認証情報を確認する。チームの開発者であれば、普段から使っているブラウザのセッションでそのまま .map ファイルを取得できる。しかし、チーム外の人物や認証されていないブラウザからのリクエストには 404 が返るため、存在そのものを隠蔽する効果もある。

新規プロジェクトではデフォルトで有効、既存も後から移行可能

Vercel は、新規に作成するプロジェクトでは Protected Source Maps をデフォルトで有効にした。これにより、これからデプロイするプロジェクトは意識せずとも本番ソースマップが保護される。既存のプロジェクトについては、管理画面の「Settings」〜「Deployment Protection」からスイッチをオンにするだけで有効化できる。再デプロイも不要だ。

この設定変更は即座にエッジネットワーク全体に反映される。認証なしの .map リクエストはその瞬間から 404 になるため、段階的な移行作業を必要としない。

開発フローへの影響と注意点

開発フローへの影響と注意点

セキュリティとデバッグ効率の両立

Protected Source Maps を導入しても、認証済みの開発者には従来通りソースマップが提供される。つまり、ブラウザのデベロッパーツールでエラーを追う際に元のコードが見えなくなることはない。本番環境で発生した問題を調査するチームにとって、利便性は一切損なわれない。

一方で、認証されていないサードパーティには 404 が返るため、ソースコードの漏えいリスクを大幅に低減できる。特に、エラーログに .map ファイルの URL が含まれていた場合でも、外部からはアクセスできない。

導入時に確認すべき点

この機能を使ううえで、いくつか注意点がある。まず、Vercel Authentication はブラウザのセッションを利用するため、開発者がログイン状態である必要がある。シークレットウィンドウやチームアカウント外のブラウザからはデバッグできない点に注意が必要だ。

また、CI/CD ツールなど自動化された環境でソースマップを処理する場合は、Vercel の API トークンを使って認証を通すか、あるいは別途プライベートなストレージにマップをアップロードする運用を検討してもよい。ただし、多くのケースでは開発者のブラウザからのリクエスト以外にソースマップが必要になるシチュエーションは少ないため、まずは Protected Source Maps をオンにして、必要に応じて調整するのが現実的だ。

この記事のポイント

  • Vercel が Protected Source Maps をリリース、本番ソースマップをチーム限定に
  • ブラウザからの .map リクエストは Vercel Authentication で保護される
  • 認証なしのアクセスには 404 NotFound を返却、コードの露出を防止
  • 新規プロジェクトはデフォルトで有効、既存プロジェクトも管理画面から即時有効化可能
  • 導入後も開発者のデバッグ体験は変わらず、セキュリティと利便性を両立
Amazon RedshiftにGraviton搭載のRGインスタンス登場、データレイククエリエンジンも統合

Amazon RedshiftにGraviton搭載のRGインスタンス登場、データレイククエリエンジンも統合

Amazon Redshiftに新しいインスタンスファミリー「RG」が追加された。AWSのArmベースプロセッサ「Graviton」を採用し、データウェアハウスのワークロード処理を従来のRA3インスタンスと比較して最大2.2倍高速化する。vCPUあたりの価格は30%引き下げられ、分析コストの大幅な圧縮が見込める。

さらに、このRGインスタンスではデータレイクへのSQLクエリ実行機能がクラスタノードに統合された。Apache Icebergテーブルへのクエリは最大2.4倍、Apache Parquetへのクエリは最大1.5倍高速化している。これまで別途必要だったRedshift Spectrumと、1TBあたり5ドルのスキャン料金が不要になる点も見逃せない。

BI(ビジネスインテリジェンス)ダッシュボードやAIエージェントによる大規模なクエリ実行が日常化する中、今回の刷新はパフォーマンスとコストの両立をこれまで以上に高い水準で実現するものだ。

RGインスタンスの概要と主要な性能向上

RGインスタンスの概要と主要な性能向上
【従来】RA3ベースの構成
RA3インスタンス
データウェアハウス処理
Redshift Spectrum(データレイククエリ専用)
※ SpectrumはTBあたり$5のスキャン料金が発生
【新】RGベースの統合構成
RGインスタンス(Graviton搭載)
データウェアハウス処理(最大2.2倍高速)
データレイククエリエンジン統合(Iceberg最大2.4倍高速)
※ Spectrum不要、スキャン料金ゼロ
従来のRA3構成  新RG構成で追加・強化された部分

このデモは従来のRA3構成と新RG構成の違いを視覚化したものだ。RGインスタンスではデータレイククエリ機能が完全に統合され、外部のSpectrum層に依存しないアーキテクチャに変わっている。

Gravitonプロセッサがもたらす価格性能比の改善

RGインスタンスの中核にあるのは、AWSが設計したArmアーキテクチャのカスタムプロセッサ「Graviton」だ。x86系のチップと比べて電力効率が高く、同じ電力あたりの処理量を引き上げられる特徴がある。AWSのサービスにおけるGraviton採用はEC2やRDSなどで既に広がっており、Redshiftでもその恩恵を受けられるようになった。

具体的なインスタンスタイプとしては、エントリー向けの rg.xlarge(4vCPU、32GBメモリ)と、本番ワークロード向けの rg.4xlarge(16vCPU、128GBメモリ)が用意された。従来の ra3.xlplus から rg.xlarge への移行では、vCPU数とメモリ容量は同等だが処理性能自体が大きく向上する。一方、ra3.4xlarge から rg.4xlarge への移行ではvCPU数が12から16へ約1.33倍、メモリも96GBから128GBへと拡張され、単純なスペック面でも上積みがある。

AWS News Blogの記事によれば、これらの新インスタンスはデータウェアハウス処理でRA3比最大2.2倍の性能を達成しているという。企業が日常的に利用するBIダッシュボードの応答速度や、ETL処理のバッチジョブ実行時間が大幅に短縮される計算だ。

データレイククエリエンジン統合の実質的な意味

データレイククエリエンジン統合の実質的な意味
【データレイククエリの処理フロー(Before)
Redshiftクラスタ Spectrum層(外部) S3データレイク
※ クエリがVPC外部のSpectrum層を経由、TBあたり$5のスキャンコストが加算
【データレイククエリの処理フロー(After)
Redshift RGクラスタ 統合クエリエンジン S3データレイク
※ VPC内で完結、スキャン料金ゼロ、データ移動不要

RGインスタンスで最も構造的な変化が起きたのは、データレイククエリの実行方式だ。これまではS3に置かれたデータレイクに対してSQLで分析する際、Redshift Spectrumという別のサービス層を経由する必要があった。このSpectrum層はクラスタの外部で動作するため、VPCの境界を越えたデータのやり取りが発生し、1TBあたり約5ドルの追加スキャン料金が積み上がる仕組みだった。

Spectrumが不要になったことで変わる運用とコスト

RGインスタンスでは、データレイクへのクエリをクラスタ上のノードで直接実行する。Spectrum層を経由しないため、クエリがVPCの内側に留まり、IAMロールも既存のものをそのまま使える。セキュリティ境界がシンプルになるだけでなく、データレイク利用時の通信レイテンシも低減する。

コスト面では、Spectrumのスキャン料金がゼロになる影響が大きい。例えば月間10TBのデータレイクをスキャンするワークロードの場合、Spectrumだけで月50ドルの追加コストが発生していた。RGインスタンスへの移行後は、このコストが完全に消える。データレイク分析の規模が大きい企業ほど、削減額は積み上がる計算だ。

既存の外部テーブルやスキーマ定義、クエリ構文はそのまま動作するため、アプリケーションコードの修正は不要だ。移行に伴う手間を最小限に抑えつつ、性能向上とコスト削減の両方を手に入れられる設計になっている。

AIエージェント時代を見据えた設計思想

AIエージェント時代を見据えた設計思想

今回のRGインスタンス投入の背景には、AIエージェントによるデータウェアハウス利用の急増がある。自律的に目標を追求するAIエージェントは、人間のアナリストとは比較にならない頻度でクエリを発行する。AWS News BlogのChanny Yun氏は、AIエージェントのクエリ量が「典型的な人間の利用規模を矮小化する」と表現している。

大量の低レイテンシSQLクエリを安定的に処理するには、1クエリあたりのコストを大幅に下げつつ、応答速度も維持しなければならない。vCPU単価で30%のコストダウンを実現しつつ、処理そのものを高速化したRGインスタンスは、まさにこの要求に応える製品だと言える。2026年3月に発表された新規クエリの最大7倍高速化と組み合わせることで、AIエージェントがリアルタイムにデータを参照しながら判断するワークロードにも耐えうる基盤が整った。

移行手順と現在の利用可能リージョン

移行手順と現在の利用可能リージョン
移行パスの選択
弾力的なリサイズ ダウンタイム10〜15分でインプレース移行。互換性のある構成が対象。
スナップショットと復元 RA3のスナップショットからRGクラスタを新規作成。移行時に構成変更も可能。

RGインスタンスへの移行は、AWSマネジメントコンソール、CLI、APIのいずれからでも実行できる。データレイククエリエンジンはデフォルトで有効化されており、クラスタ作成後すぐに統合環境を利用できる。

移行パスは大きく2つある。1つ目は弾力的なリサイズで、互換性のある構成であれば10〜15分のダウンタイムでインプレース移行が完了する。2つ目はスナップショットと復元で、既存のRA3クラスタからスナップショットを取得し、RGインスタンスの新規クラスタとして復元する方法だ。移行時に構成を変更したい場合に適している。

2026年5月時点で、RGインスタンスは以下のAWSリージョンで利用可能だ。米国東部(バージニア北部、オハイオ)、米国西部(北カリフォルニア、オレゴン)、アジアパシフィック(香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、台湾、東京)、カナダ(中部)、欧州(フランクフルト、アイルランド、ミラノ、ロンドン、パリ、スペイン、ストックホルム)、南米(サンパウロ)と、主要リージョンをほぼ網羅している。東京リージョンも含まれているため、国内のワークロードにも即座に適用可能だ。

実務者が押さえるべき導入判断のポイント

実務者が押さえるべき導入判断のポイント

RGインスタンスは確かに魅力的だが、導入にあたってはいくつか確認すべき点がある。まず、オンデマンドインスタンスとリザーブドインスタンスの両方が提供されているため、長期的な利用が見込めるならリザーブドインスタンスによるコスト最適化を検討したい。AWS料金計算ツールで自社のワークロードパターンに基づいたシミュレーションを行うのが確実だ。

次に、Spectrumに依存していた既存のETLパイプラインや外部ツールとの統合に問題がないか、事前に検証環境でテストすることを推奨する。クエリ構文や外部テーブル定義は互換性が保たれているが、パフォーマンス特性が変わるため、実行計画の変化によって一部のクエリで想定外の挙動が生じる可能性はゼロではない。

最後に、データレイクとデータウェアハウスの両方を1つのインスタンスファミリーで処理できるようになったことで、アーキテクチャの簡素化と運用負荷の低減が見込める。特にデータレイクの分析規模が拡大傾向にある企業や、AIエージェントの本格導入を検討しているチームにとって、RGインスタンスへの早期移行は競争力の源泉になりうる。

この記事のポイント

  • RGインスタンスはGraviton搭載によりRA3比最大2.2倍の性能とvCPU単価30%削減を両立
  • データレイククエリエンジンが統合され、Spectrumと1TBあたり5ドルのスキャン料金が不要に
  • Apache Icebergで最大2.4倍、Parquetで最大1.5倍のクエリ高速化を達成
  • BIダッシュボードやAIエージェントによる大量クエリを低コストで処理できる基盤が整った
  • 移行は弾力的リサイズまたはスナップショット復元で対応、既存クエリの修正は不要
AWS最新動向(5月11日週) Bedrock AgentCoreの支払い機能とAgent Toolkitを解説

AWS最新動向(5月11日週) Bedrock AgentCoreの支払い機能とAgent Toolkitを解説

2026年5月11日の週、AWSはAIエージェントの自律的な動作を根本から変える発表を相次いで行った。最も注目すべきは、Amazon Bedrock AgentCoreがエージェント自身による支払い機能のプレビューを開始したことだ。これによりAIエージェントはAPIや外部サービスの利用料を自ら決済し、実行タスクに必要なリソースを動的に調達できるようになる。

AWS News Blogの著者であるChanny Yun氏が執筆した週次ラウンドアップによれば、この支払い機能はCoinbaseおよびStripeとの提携で構築された。さらに、AIコーディングエージェント向けの「Agent Toolkit for AWS」や、エージェントにデスクトップ環境を提供する「WorkSpaces for AI agents」も発表されている。本記事ではこれらの新機能を技術面とビジネスインパクトの両面から分析する。

Amazon Bedrock AgentCoreの支払い機能が示す「エージェント経済圏」の到来

Amazon Bedrock AgentCoreの支払い機能が示す「エージェント経済圏」の到来

AIエージェントが「考える」だけでなく「支払う」時代が来た。Amazon Bedrock AgentCoreにプレビューとして追加された支払い管理機能は、エージェントがAPI、MCPサーバー、Webコンテンツ、さらには他のエージェントの利用料を自律的に支払うことを可能にする。これは単なる便利機能ではない。エージェントが経済活動の主体になるための第一歩といえる。

従来のエージェント(Before)
エージェントが有料APIに遭遇
決済手段がないためタスク中断
AgentCore Payments導入後(After)
エージェントが有料APIに遭遇
予算枠内で自動決済しタスク続行

この図が示すように、従来は有料サービスへのアクセスがエージェントのボトルネックだった。AgentCore Paymentsによってその制約が取り払われる。

CoinbaseとStripeとの提携が意味するもの

AWSはこの支払い基盤を単独で構築しなかった。暗号資産ウォレットのCoinbase(CDP Wallet)と決済プラットフォームのStripe(Privy Wallet)という、まったく異なる決済レイヤーの企業と提携している。Coinbase連携によりオンチェーン決済が可能になり、Stripe連携は従来型の法定通貨決済をカバーする。この二段構えが示唆するのは、AWSが特定の決済手段に依存せず、マルチペイメントレイヤーのエコシステムを目指しているということだ。

セッション単位の支出制限とガバナンス設計

エージェントに支払い権限を与えると聞いて、真っ先に浮かぶ懸念は「使いすぎ」や「不正利用」だろう。AWSはこの点をセッションレベルの支出制限で対策している。開発者はエージェントの実行セッションごとに予算上限を設定でき、その範囲内でのみ決済が実行される。企業の与信管理と同じ考え方をエージェント単位に落とし込んだ設計だ。

さらに、認証情報管理とコンプライアンス対応も組み込まれている。各エージェントは決済手段に直接アクセスするのではなく、事前に登録されたウォレット接続を通じて取引を実行する。AWSのIAM(Identity and Access Management)に似た権限管理の考え方が、支払い領域にも適用された形だ。

エージェント経済圏が実務にもたらす変化

Channy Yun氏がブログ記事で最も興奮していると述べたポイントは、この機能が解き放つユースケースの広がりだ。たとえば、リサーチエージェントがリアルタイムの市場データを動的に購入して分析に組み込む、あるいはコーディングエージェントがタスク実行中に有料APIを呼び出して機能を補完する、といった動作が実現する。

これはクラウドの従量課金モデルをエージェント自身が直接操作できるようになることを意味する。開発者はあらかじめすべてのAPI契約を整備する必要がなくなり、エージェントが実行時に必要なリソースを判断して調達する。インフラ構築の手間が一段階抽象化されるわけだ。

Agent Toolkit for AWSが実現する「AI時代のインフラ構築」

Agent Toolkit for AWSが実現する「AI時代のインフラ構築」

AgentCore Paymentsと並んで注目を集めたのが、AIコーディングエージェント向けの「Agent Toolkit for AWS」の発表だ。これはエージェントがAWS上で構築作業を行う際のエラー削減、トークンコスト低減、エンタープライズグレードのセキュリティ制御を実現する本番環境向けツールスイートである。追加料金なしで利用できる。

AWS MCPサーバーの一般提供とAgent Toolkitの関係

Agent Toolkitの中核コンポーネントとして、AWS MCP Serverが一般提供(GA)に移行した。MCP(Model Context Protocol)サーバーは、AIエージェントやコーディングアシスタントがAWSの全サービスに対して安全かつ認証付きでアクセスするためのマネージドなリモートサーバーだ。少数の固定ツールセットを通じて、複雑なAWS APIを抽象化する。

端的にいえば、エージェントに「AWS全体への安全なアクセス権」を渡す仕組みである。従来は開発者がIAMポリシーやAPIキーを個別に設定し、エージェントに渡す必要があった。MCPサーバーを使えば、これが統合認証のレイヤーで一元管理される。

ツールキットがエンジニアのワークフローをどう変えるか

Agent Toolkitは、これまでAWS Labsで提供されていたMCPサーバーやプラグイン、スキルの後継に位置づけられる。実験段階から本番利用への移行を意図した製品だ。具体的には以下の3つの価値を提供する。

  • エラー削減: エージェントがAWSリソースを操作する際の設定ミスや権限違反を減らす
  • トークンコスト低減: 最小限のツール呼び出しで済むよう最適化され、LLMのAPI利用料を抑える
  • セキュリティ制御: 企業のセキュリティポリシーに準拠したアクセス制御を適用できる

開発者にとっては、AIエージェントに「AWSの操作方法」を一から教え込む必要がなくなる点が大きい。ツールキットが提供するスキルとプラグインを組み込むだけで、エージェントはAWSリソースのプロビジョニングや監視、トラブルシューティングを標準化された方法で実行できる。

AIエージェントにデスクトップを提供するWorkSpacesの狙い

AIエージェントにデスクトップを提供するWorkSpacesの狙い

プレビューとして発表された「Amazon WorkSpaces for AI agents」は、一見すると奇妙な機能に思える。AIエージェントが仮想デスクトップを使うとはどういうことか。狙いは、エージェントにGUIアプリケーションを操作させることにある。

従来の自動化(Before)
APIがあるアプリだけ自動化可能
レガシーGUIアプリは自動化の対象外
WorkSpaces for AI agents導入後(After)
エージェントが仮想デスクトップ上でGUIを操作
レガシーアプリも含めた全社ワークフローを自動化

多くの企業には、Web APIを持たない古い業務アプリケーションが残っている。WorkSpaces for AI agentsは、エージェントがこうしたGUIアプリケーションの画面を認識し、クリックやキー入力をエミュレートすることで、人間のオペレーターと同じ操作を実行できるようにする。

セキュリティ面では、エージェント専用のマネージドWorkSpaces環境が割り当てられ、エンタープライズグレードのガバナンスとコンプライアンスを維持したまま動作する。企業が長年抱えてきた「API化できない業務の自動化」という課題に対する、AWSなりの回答といえる。

第6世代Intel搭載の新型EC2インスタンスがもたらす性能向上

第6世代Intel搭載の新型EC2インスタンスがもたらす性能向上

AI関連の発表に隠れがちだが、基盤となるコンピュートリソースにも重要なアップデートがあった。Amazon EC2のM8idn/M8idbおよびR8idn/R8idbインスタンスが発表されたのだ。これらはAWS専用にカスタマイズされた第6世代Intel Xeon Scalableプロセッサと、最新の第6世代AWS Nitroカードを搭載する。

vCPUあたり最大43%の性能向上

発表データによれば、前世代インスタンスと比較してvCPUあたりのコンピュート性能が最大43%向上している。この数字は単なるベンチマーク上の改善ではない。同じコストでより多くのワークロードを処理できることを意味する。

ネットワーク帯域とEBS帯域の強化

インスタンスタイプによって提供されるネットワーク性能も明確に差別化されている。M8idn/R8idnは最大600Gbpsのネットワーク帯域を提供し、M8idb/R8idbは最大300GbpsのEBS(Elastic Block Store)帯域に対応する。前者はネットワーク集約型ワークロードに、後者はストレージI/Oが重要なデータベースや分析ワークロードに最適化されている。

実務的には、機械学習のトレーニングデータを高速に読み込む必要があるケースや、大規模な分散データベースを運用するケースで効果を発揮する。M8idnとR8idnの選択肢が増えたことで、ワークロード特性に応じた細かいインスタンス選定が可能になった。

ValkeyとS3 Vectorsに見るデータ基盤の「ベクトル化」と「オープン化」

ValkeyとS3 Vectorsに見るデータ基盤の「ベクトル化」と「オープン化」

5月11日の週には、データ基盤に関する注目すべき動きもあった。OSS(オープンソースソフトウェア)のキーバリューストアであるValkeyが2周年を迎え、Amazon S3 VectorsとAurora PostgreSQLの統合に関する詳細なガイドが公開された。

Valkeyの急成長が証明するコミュニティ駆動開発の強さ

AWSのデータベースブログが報じたところによれば、ValkeyはDocker Pull数が1億を突破し、前年比17倍という急成長を遂げた。225人以上のコントリビューターが1,500以上のプルリクエストを提出しており、これは同期間におけるRedisの開発ペースの約2倍に相当する。

この数字が示すのは、単一ベンダー主導の開発モデルよりも、オープンでコミュニティ駆動の開発の方が速く、広範囲にイノベーションを起こせるという事実だ。Valkey 9.0はすでにAmazon ElastiCacheでも利用可能になっており、マネージドサービスとしての利便性とOSSの革新性を両立させている。

10億スケールのベクトル検索をSQLで

Aurora PostgreSQLからS3 Vectorsを標準SQLでクエリできるようになったことも見逃せない。具体的には、ベクトル類似度検索の結果とリレーショナルフィルタを1つのSQL文で組み合わせられる。たとえば、「意味的に最も類似した商品を検索し、その中から価格や在庫状況で絞り込む」といったクエリが単一ステートメントで完結する。

これはベクトルデータベース専用のクエリ言語を習得する必要がなくなることを意味する。すでにSQLを使いこなしているエンジニアであれば、追加学習なしでベクトル検索を業務に組み込める。データ基盤の民主化という観点から、非常に実用的なアップデートだ。

この記事のポイント

  • Amazon Bedrock AgentCoreに支払い管理機能が追加され、AIエージェントが自律的にAPIやサービスの利用料を決済できるようになった
  • Agent Toolkit for AWSが発表され、AIコーディングエージェントのエラー削減やトークンコスト低減を実現する
  • WorkSpaces for AI agentsのプレビュー開始により、レガシーGUIアプリケーションの自動化が現実的になった
  • 新型EC2インスタンスはvCPUあたり最大43%の性能向上を達成し、ネットワーク帯域とEBS帯域も強化された
  • Valkeyの成長とS3 VectorsのSQL統合は、データ基盤のオープン化とベクトル検索の民主化が加速していることを示している
Google Cloud、AI脅威レポートで攻撃者によるゼロデイ発見・自律型マルウェアの実態を公開

Google Cloud、AI脅威レポートで攻撃者によるゼロデイ発見・自律型マルウェアの実態を公開

Google Cloudの脅威インテリジェンスグループGTIGが2026年5月、最新のAI脅威トラッカー報告を公開した。今回の報告では、攻撃者がAIを悪用してゼロデイ脆弱性を発見した初めての事例が確認され、また自律的に動作するマルウェア「PROMPTSPY」の詳細な分析結果が示された。

報告書はAIに関する脅威を「ツールとしてのAI」と「標的としてのAI」の2軸で整理。攻撃者は脆弱性発見の自動化や防御回避コードの生成だけでなく、AIの開発エコシステム自体を狙ったサプライチェーン攻撃も活発化しているという。本記事では、この報告書の重要ポイントを実務者向けにわかりやすく解説する。

AIが攻撃ツールに ゼロデイ発見から自律型マルウェアまで

AIが攻撃ツールに ゼロデイ発見から自律型マルウェアまで
2026年GTIG報告に見るAI脅威の二面性
ツールとしてのAI
  • 脆弱性発見の自動化とゼロデイエクスプロイト開発
  • マルウェアコードの生成や難読化による検知回避
  • 攻撃ライフサイクルの自律実行(PROMPTSPY等)
標的としてのAI
  • OpenClawスキルへの悪意あるコード混入
  • LiteLLMやGitHubリポジトリへのサプライチェーン攻撃
  • AI APIキーやクラウド認証情報の窃取

今回の報告では、攻撃者が生成AIを業務効率化ツールとして悪用する段階から、攻撃そのものの中核に組み込むフェーズへと急速に移行している実態が浮き彫りになった。

AIがゼロデイを発見 犯罪グループが初の成功事例

GTIGの観測によると、ある犯罪グループが広く使われているオープンソースのシステム管理ツールを標的に、二要素認証(2FA)をバイパスするゼロデイ脆弱性を開発した。このエクスプロイトには、AIが生成したとみられる強い痕跡が残っており、GTIGが初めて「AIによるゼロデイ開発」を確認した事例となった。ベンダーへの責任ある開示を通じて、大規模な悪用を未然に防げたという。

コードを解析すると、詳細なドキュメント文字列や幻覚(ハルシネーション)で誤ったCVSSスコアが付与されているなど、LLMが出力する典型的な「教科書的Python記法」が随所に見られた。これは従来のファジングや静的解析ツールでは検出できないタイプの脆弱性だ。LLMは開発者が暗黙的にハードコードした「信頼前提」を読み解いて、2FA実装の矛盾を突くことができる。

脆弱性発見手法の比較
従来の自動スキャン(ファジング・静的解析)
  • メモリ破損や入力値不備の検出に強い
  • 開発者の「暗黙の信頼」に気づけない
  • 大規模コードベースでは誤検知が多い
LLM(大規模言語モデル)による発見
  • コードの文脈を読み取り、意図と実装の矛盾を特定
  • 2FAバイパスのような高次ロジックの欠陥を検出可能
  • 人間のセキュリティ研究者に近い推論を実現

この能力差が、従来の防御策では防ぎきれない新たな脅威を生み出している。報告書は、攻撃者がAIを「専門家レベルの増幅器」として活用し始めたと警告する。

防御回避を自動化するAI生成のデコイコード

GTIGは、ロシアに関連するとみられる侵入活動の中で、AIが生成したデコイ(囮)コードを大量に含むマルウェア「CANFAIL」と「LONGSTREAM」を確認した。CANFAILのソースには「このコードブロックは使用されない」といったLLM特有の解説コメントが含まれており、攻撃者が意図的に無害に見せかけるためのダミー機能を要求した形跡がある。

LONGSTREAMでは、システムのサマータイム設定を32回も照会するといった、意味のない繰り返し処理が組み込まれていた。これらは振る舞い検知をかく乱し、セキュリティ製品による分析を遅らせる目的がある。AIが難読化ツールとして悪用され、マルウェアが動的に自己変形する方向へ進んでいることを示す事例だ。

PROMPTSPYにみる自律型マルウェアの脅威

Androidバックドア「PROMPTSPY」は、AIを攻撃の中核に据えた自律型マルウェアとして注目されている。ESETが初めて報告したこのマルウェアは、Gemini APIを用いて端末の画面情報を取得し、ユーザーの操作を必要とせずに不正なタップやスワイプを実行する。GTIGの追加分析によって、当初知られていた以上の拡張性と防御機能を持つことが判明した。

PROMPTSPYの自律攻撃フロー
1. 端末情報を収集
Accessibility APIで画面のUI階層をXML形式で取得
2. LLMに送信
Gemini APIにXMLを送り、動的に生成された目標に沿った操作を指示
3. 結果を受け取り実行
JSONで戻された座標とアクション種別(CLICK、SWIPE)をもとにジェスチャーをシミュレート
4. 防御機能
アンインストールボタンに透明オーバーレイを被せてタップを無効化。FCMで遠隔再起動も可能

また、PROMPTSPYは被害者の生体認証(PINやパターン)を記録して再現する機能を持ち、遠隔からデバイスへの再侵入を可能にする。C2サーバやAPIキーを動的に切り替える仕組みも備えており、防御側のブロックを回避する設計思想が随所に見られる。Googleは既に関連アカウントを無効化し、Google Play Protectで既知の亜種を自動検出できるようにしている。

AIを利用した情報工作とLLMへの大規模アクセス

情報工作の領域でもAIの悪用は進んでいる。親ロシアキャンペーン「Operation Overload」では、AIで合成された音声を使って実在のジャーナリストを装う偽動画が拡散された。こうしたコンテンツは、正規メディアの信用を乗っ取る手口として使われる。

一方で、攻撃者はLLMのプレミアム機能を不正に利用するため、アカウント登録と即時解約を自動化するスクリプトや、複数アカウントを束ねる中継サービスを駆使している。UNC6201やUNC5673といった中国関連の攻撃グループは、こうした手法で大量のAPIアクセスを確保し、不正利用の痕跡を分散させていた。LLM提供事業者は、ネットワーク情報を分析してアグリゲーターを特定し、悪用を阻止する対策を強化しつつある。

AI自身が標的に サプライチェーン攻撃の実態

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脅威への対策

企業に求められる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アクセスの監視強化でリスクを軽減すべき
AIコーディングエージェントの信頼が悪用される 開発環境の新たな脅威を解説

AIコーディングエージェントの信頼が悪用される 開発環境の新たな脅威を解説

AIコーディングエージェントが開発現場に急速に浸透している。VS CodeやCursorなどのIDEに組み込まれた自律型AIは、コード生成だけでなくプロジェクト設定の読み取りやコマンド実行、外部サービスとの連携まで自動で行う。便利さの裏で、攻撃者が悪用できる新たな領域が広がっている。

2026年に入り、悪意ある指示ファイルや設定ファイルがVirusTotalに提出される件数は増加傾向にある。これらのファイルは従来のウイルス対策ソフトでは検出されない。構文的に正しいJSONやMarkdownが、AIエージェントにとっては危険な命令になり得るためだ。

この記事では、AIコーディングエージェントがもたらす開発環境の新たな脅威を整理し、具体的な攻撃事例とともに対策を解説する。

AIコーディングエージェントが変える開発環境の脅威

AIコーディングエージェントが変える開発環境の脅威

AIコーディングエージェントはIDEやターミナル、拡張機能のランタイムにまたがって動作する。プロジェクトを開くと自動的に設定ファイルを読み込み、必要なツールを起動し、デバッグ環境を整える。この自動化の流れ自体が、攻撃者にとって格好の侵入経路となる。

従来の開発環境では、人間が「実行」ボタンを押すまでコードは動かなかった。しかしAIエージェントは、プロジェクトを開いた瞬間に指示ファイルを解析し、事前定義されたタスクを自律的に実行する。開発者が内容を確認する前に、攻撃者の仕込んだ設定が動き出す可能性がある。

Google Threat Intelligenceのレポートでは、この状況を「攻撃対象がソースコードを超えて拡大した」と表現している。問題はコードの構文ではなく、ファイルが持つ意図そのものに潜むようになった。

従来のマルウェア検知はなぜ通用しないのか

従来のマルウェア検知はなぜ通用しないのか

ウイルス対策ソフトやシグネチャベースのスキャナーは、ファイル内に既知の悪意あるコードパターンが含まれているかを検査する。ところが悪意ある設定ファイルの多くは、純粋なJSON、YAML、Markdownとして文法上の問題がない。セキュリティエンジンは「正常なテキストファイル」と判定し、検出をすり抜ける。

根本的な課題は、セキュリティツールが自然言語の指示内容を評価できない点にある。「APIキーを外部サーバーに送信せよ」「ガードレールを無効化せよ」といった指示が平文で書かれていても、従来のスキャナーにはそれが危険だと判断できない。構文解析では意味を読み取れないからだ。

Google Threat Intelligenceが提唱するアプローチは、セマンティック分析への移行だ。ファイルの実際のロジックと文脈をAIで解析し、振る舞いベースでリスクを判定する。VirusTotal Code Insightがこの手法を実装し、シグネチャ検査では見えない脅威を可視化している。

従来のシグネチャ検出(Before)
ファイル種別 JSON / Markdown
→ 構文的に正常 → 検出なし
「危険なコードパターンなし」と判定
※自然言語の指示内容は評価されない
セマンティック分析(After)
ファイル種別 JSON / Markdown
→ 指示内容をAIが解析
→ 「APIキーを外部送信する指示」を検出
▲ 振る舞いベースでリスクを判定できる

シグネチャ検出とセマンティック分析の違いは明白だ。構文が正しくても、AIエージェントに与える指示内容が危険であれば検出する。これがAI時代のセキュリティに求められる新しい視点である。

狙われる4つの攻撃対象

狙われる4つの攻撃対象

Google Threat Intelligenceは、AIコーディングエージェントの攻撃対象を4つのカテゴリに分類している。それぞれが独立した脅威であり、かつ複合的に悪用される可能性がある。

実行するもの(What executes)
プロジェクト設定が自動的にコマンドを実行する。攻撃者は一見正規のビルドスクリプトに悪意あるロジックを紛れ込ませる。
指示するもの(What instructs)
AIエージェントの振る舞いを制御する指示ファイル。ガードレールの無効化やデータ送信を自然言語で命じることができる。
接続するもの(What connects)
ランタイム設定で外部サービスとの接続先を定義する。正規のAPIエンドポイントを攻撃者のプロキシにすり替えることが可能。
拡張するもの(What extends)
IDEやエディタの拡張機能。サプライチェーン経由で悪意あるコードが開発環境全体にアクセス権を得る。
■ 実行系 ■ 指示系 ■ 接続系 ■ 拡張系

4つの領域はそれぞれ独立しているが、実際の攻撃では複数が組み合わさる。たとえば「指示するもの」でエージェントのガードレールを外し、「接続するもの」で通信先を攻撃者のサーバーに変更する、といった連鎖が考えられる。

実行するもの(What executes)

開発者は普段、package.jsonMakefiledocker-compose.ymlといった設定ファイルでプロジェクトの自動化を定義する。AIエージェントもこれらを読み取り、タスクの前提条件として自動実行する。攻撃者は一見すると普通の設定ファイルに悪意あるコマンドを仕込み、エージェントの実行権限を借りて攻撃を展開する。

Google Threat Intelligenceのレポートでは、.cursor/tasks.jsonを悪用した事例が紹介されている。ユーザーがIDEでプロジェクトフォルダを開くだけで、GitHub Gistから任意のコードがダウンロードされメモリ上で実行される仕組みだ。実行パラメータは意図的に隠蔽されていた。

指示するもの(What instructs)

AIエージェントに特化した脅威として、永続的な指示ファイルの悪用がある。これらはエージェントがプロジェクト内で何を優先し、何を無視し、どのツールを使うかを定義する。自然言語で書かれているため、悪意ある指示も「通常のガイダンス」を装って紛れ込ませやすい。

危険なのは、これらのファイルが複数リポジトリで再利用される点だ。一つの悪意ある指示ファイルがサプライチェーンを通じて多数のプロジェクトに拡散するリスクがある。しかも開発者が一行もレビューしないまま、エージェントが指示を実行してしまう可能性がある。

接続するもの(What connects)

AIエージェントはsettings.jsonなどのランタイム設定を参照し、外部APIのエンドポイントや認証情報、MCPサーバーとの接続を確立する。悪意ある設定ファイルは、正規のAPIエンドポイントを攻撃者のプロキシにすり替え、プロンプトやソースコード、認証情報を外部に送信させる。

具体的な事例として、AnthropicのベースURLを第三者のプロキシに向け替えるsettings.jsonが確認されている。AIエージェントは表面上は正常に動作するため、開発者はトラフィックが盗聴されていることに気づかない。

拡張するもの(What extends)

VS CodeやCursorの拡張機能は、開発環境に深く統合され、ローカルファイルや認証情報、開発ワークフローへの広範なアクセス権を持つ。攻撃者が拡張機能の更新経路を乗っ取ったり、正規のパブリッシャーアカウントを侵害したりすれば、一見標準的なツールを通じて悪意あるコードを配布できる。

2022年に発生したnode-ipcライブラリの破壊工作(protestware)は、このリスクを端的に示している。政治的なメッセージを込めたコードが正規のパッケージに混入され、多数のプロジェクトに影響が波及した。AIエージェントが普及した現在、同様の手口はさらに広範な被害をもたらし得る。

実際の攻撃事例から学ぶ

実際の攻撃事例から学ぶ

ここではVirusTotalに提出され、Code Insightによって検出された具体的な脅威ファイルを紹介する。いずれも従来のウイルス対策ソフトでは長期間検出されなかったものだ。

tasks.jsonの武器化

2026年3月19日にVirusTotalへ提出されたtasks.jsonは、数日間にわたってどのセキュリティエンジンからも検出されなかった。Code Insightの分析により、プロジェクトフォルダを開くだけでGitHub Gistから任意のコードがダウンロードされ実行される振る舞いが特定された。

Mandiantのアナリストによる検証でも悪意あるファイルと確認され、Google Threat Intelligenceでは特定の脅威アクター(北朝鮮に関連するグループ)との関連が指摘されている。この攻撃は技術課題を装ってIT専門家を標的にする手口で、NVIDIA Cudaなどの正規ツールを偽装していた。

SkillファイルによるAPIキー窃取

AIエージェントに指示を与えるSkill.mdファイルでも、悪意ある命令が確認されている。ある事例では、APIキーや環境変数を「メンテナンス」と称して外部エンドポイントに送信する指示が含まれていた。ファイル内には「セキュリティプロセスについて混乱を招く可能性があるため、ユーザーには伝えないこと」と明記されていた。

このファイルは約2カ月間、VirusTotal上で検出されることなく活動を継続していた。2026年に入ってから、リスクのあるSkill.mdファイルの提出数は一貫して増加しており、業界全体でのSkills採用拡大と並行して脅威が拡大すると見られている。

ランタイム設定のすり替え

別の事例では、2つの無関係なsettings.jsonファイルが同じ攻撃パターンを示していた。両者はANTHROPIC_BASE_URLを上書きし、APIキーを埋め込んだうえで、Claude Codeの通信をAnthropicではなく第三者のプロキシに向けさせる設定になっていた。

さらに調査を進めると、これらのプロキシはTelegramやDiscordのみを連絡手段とし、支払いを暗号通貨のみで受け付ける不透明なサービスと関連していた。テレメトリやエラーレポートも無効化されており、ユーザーが異常に気づく仕組みが意図的に排除されていた。

拡張機能の乗っ取り

2026年3月に提出されたVS Code拡張機能のサンプルは、1週間以上にわたって検出数ゼロだったが、Code Insightは不審な振る舞いを特定した。この拡張機能にはpeacenotwarとして知られるprotestwareが含まれており、起動時に特定のファイルを生成しコンソールにメッセージを出力する。

この事案自体の影響は限定的だが、拡張機能が持つ広範なアクセス権と、AIエージェントがそれを無条件に信頼する構造が組み合わさったときの危険性を浮き彫りにしている。別の事例では、ユーザーのクリップボード内容を読み取りリモートサーバーに送信するAIコーディング支援ツールも確認されている。

攻撃の流れ(4つの経路が交差するケース)
① 指示ファイル Skill.mdが「メンテナンスタスク」を装いガードレールを無効化
② 接続設定 settings.jsonがAPIエンドポイントを攻撃者のプロキシに変更
③ 実行トリガー tasks.jsonがプロジェクト起動時に悪意あるコードを自動実行
④ 拡張機能 侵害された拡張機能がローカルファイルと認証情報にアクセス
結果 APIキー・ソースコード・認証情報が外部に流出。開発者は正常動作と誤認

攻撃の流れは一方向ではなく、複数の経路が相互に補強し合う。指示ファイルでガードレールを下げ、接続設定で通信を奪い、実行トリガーでコードを動かし、拡張機能で永続化する。この連鎖を断ち切るには、各層での対策が欠かせない。

開発組織が取るべき対策

開発組織が取るべき対策

AIエージェントが標準ツールとなる中、組織は新しい脅威に合わせて防御戦略を更新する必要がある。シグネチャ検出だけに依存する時代は終わった。

リポジトリレベルのセキュリティポリシー

最初の対策は、AIエージェントが参照するファイルの種類を組織として明確に定義することだ。許可される設定ファイル、指示ファイルのフォーマットと配置場所をポリシー化し、それ以外は自動レビューなしにマージできない仕組みを構築する。たとえば.cursor/.github/copilot-instructions.mdのようなディレクトリは、変更時に必須レビュワーを設定する。

最小権限の徹底

AIエージェントに付与する権限は、必要最小限に絞り込む。ローカルファイルへのアクセス範囲、実行可能なコマンド、接続を許可する外部サービスを明示的に制限する。仮に設定ファイルが乗っ取られても、エージェントが機密情報にアクセスできない状態を作ることが重要だ。

セマンティック分析の導入

VirusTotal Code Insightのようなセマンティック分析ツールを開発パイプラインに組み込む。これらのツールはファイルの構文ではなく、AIエージェントに与える指示の意味を評価する。自然言語で書かれた「APIキーを送信せよ」「テレメトリを無効化せよ」といった指示を検出できる。

Google Threat Intelligenceのエージェンティックプラットフォームでは、単一の危険フラグから関連する脅威キャンペーン全体を調査できる。1つの不審なsettings.jsonを起点に、同じインフラを使う別の攻撃ドメインや、過去の類似事案まで追跡可能だ。

対策の優先順位
第一段階
エージェントが読み取るファイルをポリシーで制限し、変更時に自動レビューを義務化する
第二段階
AIエージェントの権限を最小化し、アクセスできるファイルとサービスを明示的に制限する
第三段階
セマンティック分析ツールをパイプラインに統合し、自然言語の悪意ある指示を検出する
第四段階
脅威インテリジェンスプラットフォームでファイル間の関連性を分析し、キャンペーン全体を可視化する
※各段階は並行して進めることが望ましい

対策は段階的に導入できる。まずはポリシー整備から始め、徐々にツールによる自動化を進めるのが現実的だ。重要なのは、AIエージェントを信頼するのと同じ熱量で、その動作を検証する仕組みを育てることだ。

この記事のポイント

  • AIコーディングエージェントの普及により、攻撃対象はソースコードから設定ファイルや指示ファイルへと拡大している
  • 悪意あるJSONやMarkdownは構文的に正しいため、従来のシグネチャ検出ではほぼ検出されない
  • セマンティック分析が新しい防御の鍵であり、VirusTotal Code Insightがこの分野をリードしている
  • リポジトリレベルのポリシー整備、最小権限の徹底、セマンティック分析ツールの導入が実践的な対策となる
  • 2026年に入り、悪意あるSkill.mdファイルの提出数は増加傾向にあり、脅威は拡大し続けると見られる
Copy Fail脆弱性にCloudflareがどう立ち向かったか

Copy Fail脆弱性にCloudflareがどう立ち向かったか

2026年4月29日、Linuxカーネルにローカル権限昇格をもたらす脆弱性「Copy Fail(CVE-2026-31431)」が公開された。この脆弱性を悪用すれば攻撃者はroot権限を取得でき、多くのサーバが影響を受け得る深刻なものだ。

Cloudflareは世界中の330都市に展開する大規模なLinuxサーバ基盤を運用している。同社は開示直後からセキュリティチームとエンジニアリングチームが動き、既存の振る舞い検知が数分で攻撃パターンを特定できることを確認し、また再起動不要の緩和策としてeBPF LSMを展開した。結果として顧客データへの影響やサービス停止は一切発生していない。

Copy Fail脆弱性(CVE-2026-31431)の全容

Copy Fail脆弱性(CVE-2026-31431)の全容

Linuxカーネルのcrypto APIには、AF_ALGソケットファミリ経由で一般ユーザプロセスが暗号化・復号を要求できる仕組みがある。ここで問題となったのは「aead」テンプレートを用いるモジュール `algif_aead` の欠陥だ。2017年に導入されたin-place最適化によって、復号時に割り当てられた出力領域を超えた4バイトの書き込みが発生するようになっていた。

攻撃者はまず `splice()` システムコールを使い、`/usr/bin/su` のようなsetuidバイナリのファイル記述子からページキャッシュの参照を暗号化操作のscatterlistにチェインさせる。その状態で `recvmsg()` を呼ぶと、本来許される範囲外の4バイトがターゲットのページキャッシュに書き込まれる。汚染されたバイナリを `execve()` で実行すれば、root権限で任意のコードが動くという筋書きだ。

1. 攻撃用AF_ALGソケットを作成
socket(AF_ALG, SOCK_SEQPACKET, 0) でAEADテンプレートにバインド
2. splice()でページキャッシュ参照を注入
setuidバイナリ(例:/usr/bin/su)のファイル記述子からページキャッシュを暗号scatterlistにチェイン
3. recvmsg()で範囲外書き込み
復号処理中に4バイトのスクラッチデータがターゲットページキャッシュへ書き込まれる
4. execve()で改ざんバイナリを起動、root権限取得
ページキャッシュが汚染された状態でsetuid-rootプログラムを実行し、シェルコードがrootとして動作
※攻撃者は任意のファイル、オフセット、書き込む4バイトの内容を制御可能

このエクスプロイトの流れは、Cloudflareのブログで詳述された技術情報と、Xint Codeによる元の開示記事を基にしている。Linuxコミュニティはコミット a664bf3d603d で2017年の最適化を差し戻しており、それが正式な修正となる。

CloudflareのLinuxカーネル管理プロセス

CloudflareのLinuxカーネル管理プロセス

CloudflareはカスタムLinuxカーネルを自前でビルドし、コミュニティの長期サポート(LTS)バージョンをベースにしている。新型カーネルの選定からグローバル展開まで、およそ4週間のサイクルでシステム的なアップデートと再起動を実施している。公開前に既知のセキュリティパッチがマージされるのが常だが、Copy Failの修正はメインラインにマージされてから1ヶ月経っても主要LTSラインへのバックポートが完了していなかった。このタイムラグが生じたため、Cloudflareの大部分のサーバは6.12 LTSカーネルを稼働させており、脆弱性が残る状態だった。

Cloudflareの多層防御:検知から再起動不要の緩和まで

Cloudflareの多層防御:検知から再起動不要の緩和まで

振る舞いベースの検出が数分で作動

Cloudflareのエンドポイントには、プロセスの振る舞いを常時監視する検知プラットフォームが導入されている。特定の脆弱性シグネチャに頼るのではなく、通常とは異なる実行パターンを検出する仕組みだ。専用ルールの更新や人の介入なしに、社内で実施した検証でエクスプロイトの試行が数分以内に悪性と判定され、アラートが発報された。これは攻撃チェーン全体(スクリプトインタプリタ → AF_ALG経由の暗号サブシステム呼び出し → 権限昇格バイナリの実行)を一つの振る舞いパターンとして捉えた結果だ。

脅威ハンティングと過去48時間のログ調査

セキュリティチームは「公開前から悪用されていた可能性を前提にする」という原則に立ち、エクスプロイトが残すカーネルログの痕跡を独自の集約ログ基盤で検索した。また、関係するシステムへの全アクセスログを収集し、接続元や実行コマンドを再構成、システムバイナリのハッシュ整合性を検証した。その結果、過去48時間においてCloudflareのインフラ上で悪用された証拠は一切確認されなかった。

eBPF LSMによる緊急緩和の展開

根本対策であるパッチ済みカーネルのロールアウトには時間がかかるため、チームは無効化モジュール `algif_aead` の削除をまず試みた。しかし実際にはレガシーな社内サービスがcrypto APIを利用しており、削除すると障害を招くことがステージング環境のテストで判明した。そこで再起動不要の外科的対策として、BPF Linux Security Module(bpf-lsm)を使ったプログラムを導入した。

# 素朴な緩和(モジュール無効化)は依存関係のため断念
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

bpf-lsmプログラムは `socket_bind` LSMフックにアタッチし、AF_ALGソケットを開こうとするバイナリのパスをホワイトリストと照合する。許可リストにないバイナリからの `bind()` 呼び出しは拒否するため、悪用の入口を完全に封鎖する。このアプローチを採る前に、Prometheus eBPF Exporterを使って艦隊全体のAF_ALG利用実態を可視化し、許可リストに載せるべき正当なサービスが本当に1つだけであることを検証した。

# eBPF LSMプログラムの擬似フロー
- ソケットファミリがAF_ALGでなければ通過
- AF_ALGの場合、呼び出し元バイナリのパスを許可リストと照合
- 許可されていればbindを許可、それ以外は拒否

これにより、大部分のサーバはパッチ済みカーネルが配布されるまでの間、bpf-lsmによって保護された。テスト用ノードで実際にエクスプロイトコードを実行し、PermissionError が返され攻撃が不可能になったことを確認している。

緩和前(非パッチカーネル)
攻撃者のbind()成功 → recvmsg()で範囲外書き込み → root取得
bpf-lsm導入後(再起動なし)
非許可バイナリからのAF_ALG bindを拒否 → PermissionError → 攻撃失敗
※許可リスト内の正規サービスは影響を受けずに動作を継続

一連の対応から得た教訓と今後の改善

一連の対応から得た教訓と今後の改善

Cloudflareは今回の対応を通じていくつかの改善点を特定した。まず、カーネルAPIの依存関係をより深く可視化し、将来の緊急緩和時にサービス停止を避けられるようにすること。次にbpf-lsm自体の展開速度やログの充実を図り、ランタイム防御の即応性を高めること。さらに、カーネルコンフィギュレーションの監査を進め、使われていないモジュールや機能を事前にビルドから除去することで攻撃対象領域を縮小していく方針だ。

今回のインシデントで、Cloudflareは顧客影響ゼロを達成した。パッチ済みカーネルのリリースとbpf-lsmによるレイヤーが艦隊全体に行き渡り、脆弱性が悪用される余地は残らなかった。Linuxコミュニティの責任ある開示、社内の可視化ツール、そしてbpf-lsmというプリミティブが、迅速な防御を可能にしたといえる。

この記事のポイント

  • Linuxカーネルの脆弱性「Copy Fail」はローカルからroot権限を奪取できる深刻な問題
  • Cloudflareは公開と同時に既存の振る舞い検知で即座に捕捉し、過去ログの脅威ハンティングで未然悪用がないことを確認
  • 再起動不要の緩和策としてeBPF LSMを導入し、AF_ALGソケットへの不正アクセスをホワイトリスト方式で遮断
  • 根本パッチのロールアウトと並行して運用し、結果的に顧客データやサービスへの影響は皆無
  • 可視化ツール(Prometheus eBPF Exporter)の事前整備が緩和策の意思決定を支えた
AWS MCP Serverが一般提供開始、AIエージェントのAWS操作を安全・効率的に

AWS MCP Serverが一般提供開始、AIエージェントのAWS操作を安全・効率的に

AWSは2026年5月6日、AIエージェント向けのマネージドサービス「AWS MCP Server」の一般提供を開始した。AIコーディングアシスタントがAWSの各種サービスを安全に呼び出し、最新ドキュメントを参照し、必要ならサンドボックス内でスクリプトを実行できるようになる。

これまではAIエージェントがAWSを操作しようとしても、訓練データが古く、IAMポリシーが過剰になりがちだった。本サーバーはそうした課題を解決し、本番環境でも使えるレベルのインフラコード生成を後押しする。

本記事ではAWS MCP Serverの機能、GAで追加された新要素、具体的な利用手順、対応ツール、料金までを詳しく解説する。

AWS MCP Serverの概要

AWS MCP Serverの概要

MCP(Model Context Protocol)は、AIエージェントが外部サービスやツールと安全にやり取りするための標準プロトコルだ。AWS MCP Serverはこのプロトコルに準拠したマネージド型のリモートサーバーであり、数個の固定ツールを通じて1万5000を超えるAWS APIへのアクセスを提供する。

AIコーディングアシスタントは多くの場合、訓練データに依存するため、2025年後半以降に登場した新サービス(Amazon S3 VectorsやAurora DSQLなど)を知らない。また、インフラ構築時にAWS CLIを好み、AWS CDKやCloudFormationといったIaCツールを使わない傾向があった。生成されるIAMポリシーも権限が広すぎるなど、デモ用には動いても本番投入は難しい状態だった。

従来のAIエージェントによるAWS操作
訓練データは数カ月前の知識のみ。AWS CLIを直接実行し、過剰なIAM権限を要求。最新サービスを認識できない。
AWS MCP Serverを経由した操作
エージェントはMCPサーバーに問い合わせ。最新ドキュメントを検索し、IAM認証を通じて最適なAPIを実行。サンドボックスでスクリプト処理も可能。
call_aws search_documentation run_script

この仕組みにより、AIエージェントは常に最新の情報と最小権限でAWSリソースを操作できる。ツールの数が少なく固定されているため、モデルのコンテキストウィンドウを圧迫せず、ハルシネーション(誤った回答の生成)も抑えられる。

GAで追加された主な機能

GAで追加された主な機能

プレビュー期間を経て正式提供となったAWS MCP Serverでは、以下の機能が新たに導入されている。

IAMコンテキストキーのサポート

従来はMCPサーバー自体の利用に専用のIAM権限が必要だったが、今回からIAMコンテキストキーに対応した。これにより、通常のIAMポリシーの中で「特定のユーザーは更新系APIを許可、MCPサーバー経由では読み取り専用」といったきめ細かい制御が可能になる。余分な権限管理の手間が減り、セキュリティ設計がシンプルになる。

ドキュメント検索の認証不要化

search_documentationおよびread_documentationツールが、認証なしでも利用できるようになった。これにより、まだAWSアカウントを持っていない段階でも、AIエージェントは最新のAWSドキュメントを参照して設計や調査を行える。

トークン消費の最適化

インタラクションあたりのトークン消費量が削減された。マルチステップのワークフローを伴う複雑なタスクでは、モデルのコンテキストウィンドウがすぐに埋まりがちだったが、今回の改善でより長い会話を維持しやすくなっている。

run_scriptツールとサンドボックス実行

run_scriptツールとサンドボックス実行

GAの大きな目玉がrun_scriptツールの追加だ。AIエージェントは短いPythonスクリプトを記述し、MCPサーバー側のサンドボックス環境で実行させることができる。このサンドボックスは呼び出し元のIAM権限を継承するが、ネットワークアクセスは一切持たない。つまり、エージェントはAWSリソースのデータを処理できるものの、ローカルのファイルシステムやシェルには触れない。

Before run_script(APIを逐次呼び出し)
エージェントが複数のAPIを1つずつ呼び出し、その都度応答を解析。レイテンシが増大し、コンテキストも大量に消費する。
After run_script(サンドボックスで一括処理)
エージェントがPythonコードを生成し、サーバー側で複数APIをチェーン実行。結果は1回の応答で返るため、高速かつコンテキスト効率が良い。
import boto3

# 複数APIを組み合わせた処理を1回のラウンドトリップで

従来、エージェントが複数のAPIを呼び出してデータを結合する場合、1つずつリクエストを送っては応答を待つ必要があり、時間もトークンも浪費していた。run_scriptを使えば、1回のラウンドトリップで一連の処理を完結させられる。これにより、処理速度とコンテキスト効率の両方が大幅に向上する。

Skillsによるベストプラクティスの提供

Skillsによるベストプラクティスの提供

プレビュー版では「Agent SOPs」という形式でガイダンスが提供されていたが、GAではより洗練された「Skills」に移行した。Skillsは、エージェントがよく間違えるタスクに対して、AWSの各サービスチームがメンテナンスする検証済みのベストプラクティスを提供する。

スキルにより生成されるコードの品質が安定し、エラーやトークンの無駄も減る。ツール一覧を短く保ちつつ、必要なガイダンスをピンポイントで渡せるため、エージェントの挙動が予測しやすくなり、無駄な試行錯誤も抑制される。

Skillsライブラリのイメージ
EC2 インスタンス設計の勘所
S3 バケットポリシーの安全設定
CDK プロジェクト構成のテンプレート
Lambda 関数の権限制御
エージェントはタスクに応じて最適なスキルを参照し、検証済みのコードや設定を生成する。

エンタープライズの現場では、開発者の数だけ書き方がバラバラになりがちだが、Skillsによってサービスチーム公認のパターンがチーム全体に自然と浸透する。結果として、セキュリティレビューの工数も削減できるだろう。

セキュリティと監査の仕組み

セキュリティと監査の仕組み

AWS MCP Serverは、ユーザーが直接操作する時とAIエージェント経由の操作を明確に区別できる設計になっている。IAMポリシーやSCP(Service Control Policies)を使って、特定のユーザーには全操作を許可しつつ、MCPサーバーには読み取り専用のみ許可する、といった制御が可能だ。

さらに、AWS-MCP名前空間のAmazon CloudWatchメトリクスが提供され、MCPサーバー経由のAPIコールと人間による直接のAPIコールを分離して監視できる。AWS CloudTrailもすべてのAPI呼び出しを記録するため、コンプライアンスチームが求める監査証跡を完全な形で確保できる。

監視ダッシュボードの概念
人間の操作
1,245 calls
MCPサーバー経由
867 calls
CloudWatchメトリクスで分離表示。CloudTrailには全ログが残る。

このように、AIエージェントが安全にインフラを操作できる環境が整ったことで、これまで人間の開発者しか触れなかった本番環境へのAI活用も現実味を帯びてきた。

利用方法と対応ツール

利用方法と対応ツール

AWS MCP Serverは、MCPに対応するあらゆるAIコーディングツールから利用できる。Claude Code、Cursor、Kiro、OpenAI Codexなど、主要なアシスタントはすでにサポートしている。

セットアップは非常にシンプルだ。AWS MCP ServerはIAM SigV4認証を利用するが、多くのMCPクライアントはOAuth 2.1のみに対応している。そのため、オープンソースの「MCP Proxy for AWS」を使ってIAM認証をOAuthにブリッジする。具体的には以下のようなコマンドで設定する。


curl -LsSf https://astral.sh/uv/install.sh | sh
claude mcp add-json aws-mcp --scope user \
   '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}'
設定後の動作確認イメージ
AIアシスタント上で/mcpコマンドを実行すると、AWS MCP Serverが利用可能なツール一覧が表示される。
あとは「S3にベクトルデータを保存する方法は?」と尋ねるだけで、エージェントがsearch_documentationツールを呼び出し、最新のS3 Vectorsの情報をもとに回答を生成する。

プロキシはローカルマシン上で動作し、MCPサーバーのエンドポイントとしてhttps://aws-mcp.us-east-1.api.aws/mcp(米国東部)または欧州(フランクフルト)のリージョナルエンドポイントを指定する。APIコール自体は他の全リージョンに対しても実行可能だ。

料金と提供リージョン

料金と提供リージョン

AWS MCP Server自体に追加料金は発生しない。支払うのは、AIエージェントが操作した結果として作成されたAWSリソースの利用料と、データ転送料金のみだ。このため、まずは試験的に導入し、効果を検証しやすい。

現在の提供リージョンは米国東部(バージニア北部)と欧州(フランクフルト)の2拠点。今後、他のリージョンにも順次拡大される見込みだ。

AWS MCP Serverはすでに多くのAIコーディングアシスタントで利用可能であり、AWSドキュメントの最新ページからクイックスタートガイドを参照できる。

この記事のポイント

  • AWSがAIエージェント向けのマネージドMCPサーバーを一般提供開始
  • call_aws、search_documentation、run_scriptの3ツールでAWSを安全に操作
  • run_scriptはサーバー側サンドボックスでスクリプトを一括実行し高速化
  • SkillsによりAWSチーム公認のベストプラクティスをコード生成に活用可能
  • IAMとCloudTrail/CloudWatchで人間の操作とAIの操作を明確に分離監査
  • サーバー利用料は無料、リソース使用量のみの課金。米国東部と欧州で提供開始