ネットワーキング

AI インフラストラクチャとオーケストレーションに関する最新情報

Tue, 20 Oct 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 10 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

9 月はスケーラビリティ月間です。世界がエージェントフリートの急増に備えるなか、Google はそのニーズに迅速かつ適切に対応できるように AI インフラストラクチャとオーケストレーションサービスを強化するとともに、ワークロードの分離とセキュリティを維持し、コストを抑えています。今回の記事では、Google Cloud のコンピューティング、ネットワーク、ストレージ、オーケストレーションのサービス全体でこれらの機能強化がどのように現れているかに加えて、お客様が Google Cloud AI インフラストラクチャを使用する新しい方法、Google の戦略に対するサードパーティの業界検証をご紹介します。

プロダクト、テクノロジー、ツールに関する最新情報

Google Kubernetes Engine の更新: GKE チームはプラットフォームのスケーラビリティの向上に全力を注いでいます。9 月には、さまざまな形や規模で改善が行われました。

新機能: エージェントワークロードに、より高密度の実行ランタイムが必要ですか？新しいオープンソースの GKE Agent Substrate は、標準的なコンテナランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。また Agent Substrate は、ネイティブのゼロトラストカーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。
プロダクトの最新情報: GKE にゼロへのスケーリング機能が組み込まれました。ワークロードをスケールダウンするために複雑なコンポーネントを構成する必要はありません。AutoscalingMetric を使用した HPA と KEP-2021 のサポートにより、その作業はすぐに自動的に行われます。詳細については、こちらのブログ記事をお読みください。
プロダクトの最新情報: さらに、GKE HPA（前述の AutoscalingMetric を使用）では、標準指標に加えてカスタム PromQL 指標に基づいてスケールアップとスケールダウンを行えるようになりました。これにより、ビジネスにとって意味のある独自の条件に従ってワークロードをトリガーできます。詳しくはこちらをご覧ください。
新機能: もう一つのスケーラビリティ機能は GKE Pod スナップショットです。これは、CPU や GPU のメモリを含むワークロードの実行状態を保存し、オンデマンドで復元できるようにするものです。内部テストによると、GKE Pod スナップショットにより、AI 推論の起動時間を最大 89% 短縮できます。詳しくはこちらをご覧ください。
新しい移行ツール: 最後に、コンテナワークロードを AWS EKS から GKE に移行したいと考えていたものの、困難で摩擦の多いエンジニアリング作業を恐れていた方のために、GKE エージェント型移行をリリースしました。これは、不安定なアドホックプロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェントプラグインです。エージェントスキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを GKE ランディングゾーンに直接変換します。オンボーディングガイドを確認して利用を開始しましょう。
機能の更新: 強化学習（RL）と評価のワークロードは非常に複雑です。標準的なエージェント RL ループでは、LLM ポリシーが GPU 上でコードスニペットなどのアクションを生成し、分離された CPU サンドボックス内で実行して報酬シグナルを観察します。しかし、このループをスケールアップして数万の並列ロールアウトをサポートしようとすると、アクセラレータのアイドル状態、イメージのカーディナリティ、コントロールプレーンの飽和など、インフラストラクチャのボトルネックが発生します。そこで、RL 向けに最適化された GKE Agent Sandbox に加えて、Agent Sandbox RL オーケストレーション SDK、一般的な RL ジムやハーネスとのネイティブ連携機能を開発しました。すべて一般提供が開始されています。詳しくはこちらをご覧ください。

ストレージの最新情報: AI は大量のデータをトレーニングして作成します。そのデータは、ブロックストレージシステム、ファイルシステム、オブジェクトストア、データベースのいずれかに保存する必要があります。この重要なレイヤがエージェントの要求に対応できるよう、ストレージポートフォリオの強化を発表しました。

プロダクトの最新情報: Filestore エージェントボリュームは、エージェントワークロード向けに高パフォーマンスで柔軟な永続ファイルストレージを提供します。GKE Agent Substrate および GKE Agent Sandbox との緊密なインテグレーションにより、Filestore エージェントボリュームは、分離された専用ファイルワークスペースを GKE Agent Sandbox にミリ秒単位で自動的に割り当て、アタッチします。プレビュー版へのアクセスはこちらからリクエストできます。
新しいプロダクト: 生成 AI と RAG のデータレイヤ（Milvus、Pinecone、Qdrant、Vespa、Redis、インメモリコンテキストキャッシュなど）を実行している場合は、M4N ファミリーの VMをご覧ください。一般提供が開始されたこれらの VM は、主要なハイパースケーラーの中でコアあたりの IOPS とスループットが最高です。M4N インスタンスは、Google Cloud のカスタム Titanium オフロードアーキテクチャおよび Hyperdisk Extreme と組み合わせることで、ホストあたり合計で最大 25,000 MiB/秒（25 GiB/秒）のストレージスループットと最大 100 万 IOPS を実現します。
新しいプロダクト: もう一つの新しい Compute Engine プロダクトである Z4D の一般提供が開始され、AI / ML のトレーニングおよび推論ワークロード向けの強力なストレージソリューションとしてご利用いただけるようになりました。ベアメタルインスタンスとして構成すると、Z4D はエージェント型マイクロ VM に必要な大容量のローカル SSD（LSSD）と低レイテンシの両方を提供するため、ホストごとに数千の分離されたサンドボックスをネイティブのパフォーマンスと効率で実行できます。Z4D マシンの詳細はこちらでご確認ください。
プロダクトの最新情報: 現在の AI トレーニングや推論のパイプラインは、ほとんどのストレージ管理システムが対応できないほどのスピードでデータを作成するため、ストレージ資産を把握しようとするチームにとって課題となっています。Storage Intelligence アドバイザーの新バージョンでは、「バケットには何が入っているか？」という疑問の答えが簡単にわかり、予期しない変更をすばやく特定できます。さらに、強化されたバッチオペレーションにより、バケット全体にわたる一括変更、たとえば、ストレージクラスの移動、古いデータや一時データの一括削除、メタデータ、タグ付け、保持、暗号化の変更の適用などを自動化できます。Storage Intelligence アドバイザーの最新情報については、こちらをご覧ください。
新しいプロダクト: 最後に、AlloyDB for PostgreSQL の新バージョンは、Google の先駆的なインフラストラクチャである Colossus 分散ファイルシステムと Jupiter ネットワークを統合し、エージェントの時代における妥協のない新しいデータベースアーキテクチャを実現します。

実践ガイドとハウツー

ハウツー: 世界中に分散している GPU と TPU を、単一のエントリポイントの背後にある単一のプールとして動作させたいとお考えの場合は、こちらのブログ記事でその方法をご確認いただけます。エッジでは、マルチクラスタ GKE Inference Gateway が、グローバルなマルチリージョントラフィック分配と高可用性を担います。その下では、LLM-d ルーターが、使用率を高く維持するための複雑なメモリ認識型スケジューリングアルゴリズムを処理します。このアーキテクチャは、ランタイム、モデル、アクセラレータに依存しないように意図的に設計されており、テストでは、マルチクラスタ GKE Inference Gateway を介してトラフィックをルーティングしたところ、オーバーヘッドは 1% 未満でした。
ガイド: AI モデルのトレーニングや推論に TPU 上の GKE を使用されているか、使用される予定ですか？巨大な大規模言語モデル（LLM）のトレーニングや、高スループットの推論サービングの実行には、Cloud TPU や Cloud GPU などの特殊な AI ハードウェアへの多額の投資が必要です。費用対効果を最大化するには、GKE のワークロードライフサイクル指標を理解する必要があります。この詳細なガイドでは、不透明なクラスタの動作を実用的なテレメトリーに変換する方法を説明します。

お客様とパートナーに関する最新情報

GKE のお客様: ゲームのスタートアップである SeaVerse がマルチテナントワークロードに GKE Agent Sandbox を利用している理由と、このプラットフォームによってインフラストラクチャ費用を 60% 削減できた経緯をご覧ください。

調査、レポート、詳細解説

また、Google は Gartner と Forrester の 3 つの主要なアナリストレポートでリーダーに選出され、プロダクトまたは戦略のいずれかで最高スコアを獲得しました。

Google、「The Forrester Wave™: Public Cloud Platforms, Q3 2026」でリーダーに選出: クラウドプロバイダの中で最高の総合スコアを獲得しました。
Google、2026 年 Gartner® Magic Quadrant™ で戦略的クラウドプラットフォームサービス部門のリーダーに選出: 評価対象となったすべてのベンダーの中で、「ビジョンの完全性」において最高評価を獲得しました。
Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出: 評価対象となった全ベンダーの中で「実行能力」において最高評価を獲得しました。
Google Cloud は、世界中の GPU プロバイダの信頼性、パフォーマンス、サポート、料金、セキュリティを評価する最新の SemiAnalysis ClusterMax 3.0 レポートでゴールド評価を獲得しました。詳しくは、レポート全文をご覧ください。

2026 年 8 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: Filestore は Google Cloud がファーストパーティとして提供するセキュアでスケーラブルな NFS ファイルサービスであり、AI やエージェントワークフロー向けのストレージプラットフォームとして人気を集めています。このたび、Google の基盤となる分散ストレージシステムである Colossus 上に直接構築された新しいバックエンドストレージレイヤが追加され、これらのタスクにさらに適したサービスとなりました。この新しいバックエンドでは、ストレージ容量とは別に IOPS をプロビジョニングでき、GKE と緊密に統合されています。AI 環境では、いわゆるエージェントスウォーム（多数のエージェントからなる大規模なグループで、共通のデータセットに対して読み取りと書き込みを行う必要がある）を、パフォーマンスを低下させることなく処理できます。詳しくは、ブログ投稿をご覧ください。
新機能: gVisor サンドボックスを GKE 上の分散 Ray クラスタで利用できるようになりました。Anyscale との提携により、gVisor を分散 Ray クラスタに直接組み込むことができる、Ray 向けの試験運用版ライブラリを導入しました。gVisor は Google のオープンソースアプリケーションカーネルであり、通常のコンテナよりも強力な分離機能を持ち、起動時間が短く、メモリオーバーヘッドが少ない軽量な環境を提供します。GKE でこれらのサンドボックス機能を試すには、Ray サンドボックスユーザーガイドをご覧ください。
プロダクトの最新情報: 費用はあまりかけたくないけれど、パーソナル AI エージェントを実行するための高性能で使いやすいインフラストラクチャをお探しという方に朗報です。新しい Cloud Run インスタンスは、Cloud Run 上の専用のシングルトンコンピューティングランタイムであり、エージェントがアイドル状態になってもシャットダウンされません。さらに、1 個の vCPU と 1 GiB のメモリを備えた Cloud Run インスタンスを 30 日間連続で実行しても、費用は 5.70 ドルしかかかりません。

実践ガイド、ドキュメント、ハウツー

入門ガイド: Model Context Protocol（MCP）に関する最新情報: 2026-07-28 仕様で、プロトコルコアは「完全にステートレスになりました。handshake はなくなり、initialize / initialized handshake（SEP-2575）と論理的な Mcp-Session-Id ヘッダー（SEP-2567）は完全に削除されました。代わりに、すべてのリクエストが自己記述型で独立したものになりました。」最新の MCP 仕様の変更点と、さらに重要なその実装方法について詳しくは、こちらの Google for Developers のブログ記事をご覧ください。
ガイド: 従来のネットワークロードバランシング手法では、リアルタイム AI システムをうまく扱いきれない場合があります。「バックエンドは、今までのように個別のリクエストを処理するのではなく、継続的なライブ双方向ストリームを管理する必要があります。音声チャンク、文字起こし、モデル出力、合成音声が同時にやり取りされる、絶え間ないストリームを処理するからです。」ここにユーザーへの対応が追加されると、状況はさらに悪化します。「サーバーは、現在処理中の音声生成を即座に停止して、コンテキストを更新し、場合によっては新しいツールをトリガーして、別の回答の作成を開始する必要があります。また、これを接続を切断することなく行わなくてはなりません。」AI 時代における負荷管理の新しいアプローチについては、セッション対応のロードバランシングによるリアルタイム AI エージェントのスケーリングをご覧ください。
ハウツー: さまざまな GPU アクセラレータが混在する場合でも、GKE 上に弾力性のあるスケーラブルな LLM 推論プラットフォームを構築する方法を学びます。ここで提案するアーキテクチャでは、Capacity Advisor と Compute Advisor に加え、Run:ai Model Streamer や、並列ダウンロード機能を備えた GCSFuse などの高性能ストレージを組み合わせて使用します。詳しくは、こちらをご覧ください。
ドキュメント: GPU や TPU を搭載したホストの問題は、ライブマイグレーションを使用して更新することができないためにメンテナンスが困難であることです。この新しいドキュメントページでは、トレーニングワークロードと推論ワークロードのダウンタイムをどれだけ許容できるかに応じて、アクセラレータ搭載ホストを更新する方法を説明します。
ドキュメント: Advanced Compute Images（ACI）は AI / ML および HPC インフラストラクチャ用の標準化されたイメージスタックであり、独自のカスタムイメージを手動で構築する必要はありません。この新しいドキュメントページでは、Google Cloud CLI、コンソール、または SchedMD の Slurm ワークロードマネージャーを使用して ACI イメージを作成する方法を説明します。
ガイド: AI ワークロードは、設計の難しさ、リソース消費の激しさ、そしてバースト性があることで知られています。これらはスケーリングのボトルネックを招くだけでなく、十分に活用されない（または誤用される）コンピューティングリソースを大量に発生させる原因にもなります。新しいブログ投稿では、Google Cloud で動的な容量管理を実現する 3 つの主な方法について説明します。その 3 つの方法は以下のとおりです。1）計画的なダウンタイムに備えて容量をスケジュールする、2）計画外のダウンタイムに備えて自動フォールバック容量を確保しておく、3）GKE のコアオーケストレーション機能を利用してリソース割り当てを自動化する。

お客様とパートナーに関する最新情報

ビジネスオーケストレーションソフトウェアプロバイダの UiPath は、急激に変動するワークロードに対処し、費用の予測可能性を高めたいと考えていました。これを実現するために、同社は分離された複数のクラスタで構成されていたインフラストラクチャを再設計し、トレーニング用の A3 VM インスタンス（NVIDIA H100 GPU）と推論用の G4 VM インスタンス（NVIDIA RTX PRO 6000 Blackwell Server Edition GPU）の両方を含む共有 Google Cloud GPU フリートへと移行しました。同社のアーキテクチャについて詳しくは、こちらをご覧ください。
AI 開発の加速に注力する最先端の AI 研究所である Mirendil は、モデルの事前トレーニングとトレーニング後のアプリケーションをサポートするために、TPU と NVIDIA GPU の両方を備えた AI Hypercomputer を使用することを発表しました。
小売業向け CRM プロバイダの Replenit は、BigQuery、Gemini Enterprise Agent Platform、Cloud TPU で実行するオープンソースの Gemma モデルを使用して、Google Cloud で AI 意思決定エンジンを構築しました。同社では、この組み合わせにより、以前のクラウドプロバイダと比較してパイプライン費用が 90% 削減されたとしています。詳しくは、事例紹介の全文をご覧ください。
Malachyte は、Bigtable、Managed Service for Apache Kafka、Pub/Sub、Compute Engine、そして GKE を基盤として、AI を活用した e コマースレコメンデーションプラットフォームを構築しました。こちらのブログ記事で、これらがどのように連携するかをご覧ください。

2026 年 7 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: Google Cloud Managed Lustre の一般提供が開始されました。4 種類のパフォーマンスティアがあり、容量 1 TiB あたり 125 MB/秒、250 MB/秒、500 MB/秒、1,000 MB/秒のスループットを選択できます。ストレージ容量は最大 8 PB までスケールアップ可能です。Managed Lustre ソリューションは DDN の EXAScaler を活用しており、DDN が数十年にわたって培ってきた高パフォーマンスストレージ界をリードする技術と、Google Cloud のクラウドインフラストラクチャに関する専門知識を組み合わせています。
プロダクトの最新情報: C4N ネットワーク / ストレージ最適化 VM の一般提供を開始しました。C4N は、データ転送のボトルネックを解消するために構築された、Google 初のネットワークとブロックストレージに最適化された VM シリーズです。第 5 世代 Intel Xeon スケーラブルプロセッサを搭載し、Google の Titanium オフロードハードウェア上に構築された C4N は、400 Gbps のネットワーク帯域幅と 9,500 万パケット/秒（95 MPPS）の処理速度を実現します。また、Hyperdisk Extreme と組み合わせた場合のブロックストレージスループットは最大 25 GiB/秒に達します。
新機能: GKE Dataplane V2 が、ネットワークポリシー適用下で最大 15,000 ノードまでサポートできるようになりました（一般提供）。これにより、標準の GKE クラスタ上で、ネットワークポリシーの適用を完全に維持したまま、最大 15,000 ノードまでのスケールアップが可能になります。大企業や AI / ML を活用するお客様の膨大なインフラストラクチャニーズに対応する機能です。
新機能: llm-d が協調型タイムスライスに対応しました。強化学習（RL）ワークロードで、独立した RL ジョブを共有の物理ハードウェアにインターリーブして実行できるようになりました。これにより、モデルの収束や精度に影響を与えることなく、アクセラレータの総デューティサイクルをベースラインの約 40% から最大 70% まで引き上げることが可能です。
新しい AI セキュリティツール: GKE 上の AI サプライチェーンの保護、AI ワークロードの安全なデプロイ、シャドー AI の削減をお考えですか？Google は k8s-aibom をオープンソース化しました。これは、コンテナクラスタを継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning 部品構成表（ML-BOM）を生成する、軽量で特権を必要としない Kubernetes コントローラです。k8s-aibom プロジェクトをチェックして、ぜひ開発にご参加ください。

実践ガイドとハウツー

入門ガイド: 7 月 27 日、Google は Moonshot AI の 2.8 兆パラメータのオープンウェイトモデルである Kimi K3 の「Day 0 サポート」を発表しました。モデルのウェイト公開と同時にサポートを開始し、即日の利用を可能にしました。Model Garden、カスタムオーケストレーション、llm-d レシピを使用した GKE など、選択したデプロイ手法に合わせて Google Cloud で Kimi K3 を評価して試験運用するための詳細な手順をこのガイドでご確認いただけます。
入門ガイド: Google Kubernetes Engine（GKE）マネージド DRANET は、GPU と TPU の両方に対応しています。この実装を使用するための構成には、標準クラスタ（ユーザーが完全に制御可能）や Autopilot クラスタ（Google によって複雑な構成が自動的に行われる）など、いくつか選択肢があります。詳細については、ハンズオンラボ TPU を使用する GKE Autopilot クラスタ、GKE マネージド DRANET、Gemma 4 でご確認いただけます。
入門ガイド: GPU ではなく TPU で Ray を実行する方法を学べます。全 2 回シリーズのパート 1 では、TPU スライスについて説明します（ヒント: Ray は TPU スライスを、スケジュール設定可能なアクセラレータの一種として認識します）。続くパート 2 では、Ray のさまざまな AI ライブラリについて説明します。
入門ガイド: 新しいマイクロベンチマークスイートを使用して、サンプルワークロードにおける TPU の性能を評価します。このスイートを活用することで、デバイスが理論上のパフォーマンス仕様を達成しているかを正確に測定できるほか、特定の性能ギャップやアーキテクチャ固有のボトルネックを特定することも可能です。詳細はこちらでご確認いただけます。
入門ガイド: 予算を圧迫することなく、エージェントをスケールしましょう。GKE Agent Sandbox と Pod スナップショットを活用して固定のコンピューティングリソース内でより多くのエージェントを安全に集約する方法を、GKE オーケストレーションの観点から解説します。パフォーマンス重視かコスト重視かを問わず、エージェントの効率を最大化するための適切な最適化方法を解説します。
技術ブループリント: Ironwood における Mistral 3 Large 推論の最適化について詳細に解説します。こちらのブログ記事では、Google のあるチームが Google の Ironwood（TPU v7x）で Mistral 3 Large MoE モデルの推論を最適化し、パフォーマンスを 1.5 倍向上させた方法について説明しています。具体的には、ハイブリッドシャーディングの導入、線形 VPU 合計からツリーリダクションへの置き換え、GMM / MLA カーネルの最適化、非同期スケジューリングの採用によって、これを実現しました。その結果、ベンチマーク精度を維持したまま、スループットを最大 48% 向上させるという成果を収めました。ブログの全文はこちらでご覧ください。

調査、レポート、詳細解説

レポート: Google は、初めて発表された GartnerⓇ Magic Quadrant™ の AI インフラストラクチャ部門において、リーダーに選出され、「実行能力」で最高位、「ビジョンの完全性」で最も先進的との評価を獲得しました。Gartner は、Google 独自の拡張可能なコンピューティング、統合された AI Hypercomputer アーキテクチャ、AI コンピューティング容量の規模を主な強みとして挙げています。レポートはこちらからダウンロードしてお読みいただけます。
レポート: Google は先ごろ、「AI インフラストラクチャの現状」レポートの作成にあたり、1,400 人を超える IT 部門の上級リーダーを対象に調査を実施しました。その結果、AI に対する構想とインフラストラクチャの実態との隔たりが広がっているという明確な傾向が浮かび上がりました。実際、83% の組織が、本番運用に対応できるエージェント型 AI を支えるには、インフラストラクチャのアップグレードが必要だと回答しています。この調査について紹介したブログ記事では、エージェント型アプリケーションがシステムに求める要件に合わせてインフラストラクチャを整備することで、試験導入から本番運用への移行を進めやすくなることを説明しています。

2026 年 6 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: AI で使用される機密データの保護は、先進的でセキュアなクラウドインフラストラクチャを実現するうえで欠かせない要素です。Confidential Computing は、ハードウェアベースの高信頼実行環境（TEE）で使用中のデータを暗号で保護し、データの完全性を検証可能にする技術です。このたびこの技術が、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載したアクセラレータ最適化型 G4 マシンシリーズで提供開始されました。Confidential G4 VMs と Confidential G4 GKE Nodes をぜひ使ってみてください。
デベロッパー向けリソース: 新設された TPU デベロッパーハブは、モデルの作成者、最適化担当者、デベロッパーが Google Cloud TPU のパフォーマンスを最大限に引き出す方法を学ぶための場所です。詳細については、こちらのブログ記事をご覧ください。
新プロダクト: 新しい OpenTelemetry ベースの TPU AI テレメトリーコレクタエージェントを使用して、AI ワークロードをスケールしましょう。このたび初めて、高忠実度の TPU ハードウェアテレメトリーを、Google Cloud Monitoring、Google Managed Prometheus、または独自のセルフホスト型 Grafana スタックにルーティングできるようになりました。

実践ガイドとハウツー

入門ガイド: TPU、Cloud Storage FUSE、動的リソース割り当て（DRA）を使用して、GKE Inference Gateway で実行される AI 推論ワークロードで高可用性を実現する方法を学べます。こちらのブログ記事で概要を紹介しています。また、技術的な詳細についてはハンズオン Codelab でご確認いただけます。
入門ガイド: Model Context Protocol（MCP）を使用して、AI エージェントを Cloud Storage の非構造化データに接続できることをご存じですか？こちらのブログ記事では 3 つのお客様事例に基づく導入のメリットと、具体的な実装方法を解説しています。フルマネージドサービスにすべきか、詳細なカスタマイズと管理が可能なセルフマネージドローカルサーバーにすべきかを判断する方法もご紹介しています。

調査、レポート、詳細解説

レポート: 第三者機関によるベンチマークレポートにおいて、GKE Inference Gateway は他社の主要マネージド Kubernetes サービスを凌駕するパフォーマンスを記録しました。具体的には、スループットは 15.7% 高く、待ち時間は 92.8% 短く、トークン間のレイテンシは 62.6% 低いという結果でした。このパフォーマンスの鍵は、接頭辞キャッシュの使用にあります。長く繰り返し使用されるプロンプトの接頭辞に対応する KV キャッシュ（アクティベーション状態）を保存することで、LLM のパフォーマンスを最適化しています。詳しくは、こちらのブログ記事をご覧ください。
アーキテクチャの詳細解説: 今回は TPU と GKE におけるコールドスタート問題を深堀りし、Run:ai Model Streamer がどのようにその状況を変えられるかについて解説します。

お客様とパートナーに関する最新情報

お客様の成功事例: Pager Health は、GKE、BigQuery、Cloud SQL、Gemini Enterprise Agent Platform を活用して運用の断片化を解消し、人々の生活に大きな変化をもたらすシンプルかつパーソナライズされた医療体験を米国で展開しています。
お客様の成功事例: カスタマーレビュープラットフォームの Trustpilot は、A100 GPU 搭載のコスト最適化済み A2 VM 上で Dataflow と Gemini Enterprise Agent Platform を活用して、大規模なストリーミングパイプラインを構築しました。ファインチューニングされた Gemma モデルや、同プラットフォームが管理する最適化版 vLLM を採用しています。

2026 年 5 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: GKE Agent Sandbox の一般提供が開始されました。
新しいオープンソースプロジェクト: Agent Substrate は、エージェントインフラストラクチャの密度を限界まで高めることを目指す、新しいオープンソースプロジェクトです。
新機能: Google AI Edge Portal は、オンデバイス ML を大規模にテストしてベンチマーク評価するためのソリューションです。このたび、オンデバイス LLM のベンチマークとデバッグに対応しました。詳しくはこちらをご覧ください。
プロダクトの詳細解説: AI ワークロード向けの新しい高性能ストレージサービスファミリーである Cloud Storage Rapid について詳しく説明しました。リリース時点でご利用いただけるサービスには、高パフォーマンスのゾーンオブジェクトストレージサービスである Rapid Bucket（旧称: Rapid Storage）と、オンデマンドで読み取りを高速化して既存バケットのワークロードのコンピューティングとデータをコロケーションする Rapid Cache（旧称: Anywhere Cache）が含まれます。

調査、レポート、詳細解説

アーキテクチャの詳細解説: Google グローバルインフラストラクチャ担当バイスプレジデントの Bikash Koley とエンジニアリングフェローの Arjun Singh が、AI ワークロードがネットワークインフラストラクチャにもたらす課題の概要を説明し、AI ワークロードをより適切にサポートするためにデータセンターファブリック、WAN、グローバルネットワークに施した大幅な機能強化をご紹介します。
アーキテクチャの詳細解説: TPU で最先端の AI モデルを開発するために、インスタンスレベルの信頼性モデルを廃止し、新しいクラスタレベルの信頼性モデルを公開しました。

お客様とパートナーに関する最新情報

お客様の成功事例: ビジュアルメディアプロバイダの Imgix は、NVIDIA RTX PRO 6000 Blackwell GPU 搭載の G4 VM を備えた AI Hypercomputer を活用して、80 億を超える画像や動画を配信しています。

- Google Cloud ブログ編集者、Alex Barrett

AI 推論モデル提供のためのネットワーキング - GKE のみ、およびその他すべてのバックエンド

Tue, 20 Oct 2026 01:30:00 +0000

※この投稿は米国時間 2026 年 10 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

企業や個人の開発者は、複数の AI 推論モデルを頻繁に実行しています。適切なアーキテクチャを使用することで、モデルの呼び出し方法を簡素化すると同時に、一元化されたガバナンスを提供できます。この投稿では、ネットワークにおける AI 推論モデルの提供に焦点を当てた 2 つのリファレンスアーキテクチャについて説明します。1 つは Google Kubernetes Engine（GKE）用、もう 1 つはその他のすべてのバックエンドタイプ用です。まず、後ほど紹介するリファレンスアーキテクチャの共通点について説明します。次に、GKE バックエンドのアーキテクチャに固有のコンポーネントについて説明し、最後に、すべてのバックエンドタイプに共通するアーキテクチャの要素を確認します。

エントリポイント

推論呼び出しのフロントエンドとして機能する、高い安定性、セキュリティ、信頼性を持つエントリポイントの背後にモデルのデプロイを公開できます。このエントリポイントは、ポリシー、セキュリティ、ロジックを適用できる制御ゾーンとしても機能します。Cloud ロードバランサと推論ゲートウェイはどちらもエントリポイント機能を提供します。これらのタイプのエンドポイントは、TLS によるセキュアな接続の終端、API 管理コンポーネントとの統合、Service Extensions による機能の拡張、Model Armor の機能を活用したセキュリティ強化が可能です。

設計における共通サービス

どちらのリファレンス設計でも、次のサービスを使用します。

Private Service Connect 推論エンドポイント: 消費者の Virtual Private Cloud（VPC）ネットワーク内にエントリポイントを固定します。トラフィックはプライベート内部 IP アドレスに到達するため、推論呼び出しはプライベートネットワーク内に保持されます。
Apigee API Management（省略可）: Apigee Extension Processor コールアウトを介して統合され、リクエストがコンピューティングリソースに到達する前に、クライアント ID の検証、レート制限、割り当ての適用を処理します。
Model Armor: インライン AI 安全性チェックポイントとして機能し、プロンプトインジェクションや機密データの漏洩がないか、プロンプトと出力補完をスクリーニングします。

GKE のみで提供される設計パターン

このセクションでは、GKE のみのバックエンド設計に焦点を当てます。エンドツーエンドのコンセプトを完全に理解するには、アーキテクチャに関するドキュメント GKE での AI 推論モデル提供のためのネットワーキングをすべてお読みください。設計パターンは、次の図に基づいています。

前のセクションで特定した共通サービスに加えて、GKE の設計では次のコンポーネントを使用します。

GKE Inference Gateway: 内部アプリケーションロードバランサ（gke-l7-rilb）としてデプロイされます。受信リクエストのペイロードを解析し、HTTPRoute ルールを評価して、適切なモデル提供ターゲットにクエリを転送する、特殊な内向きエンジンとして機能します。
推論プール: 同じモデルのレプリカを含む論理グループ。Gateway はプロンプトを受け取ると、HTTPRoute ルールを評価し、モデル識別子に基づいて適切な推論プールを選択します。プールには初期サイズがあり、動的に自動スケーリングされるように構成できます。
モデルレプリカセット: シングルノードまたはマルチノードの GPU または TPU ノードプールにデプロイされた個々のモデルレプリカ（推論サーバーインスタンス）。レプリカセットは、これらのモデルレプリカの均一なグループを表します。

GKE のトラフィックフローの例

この GKE ベースのアーキテクチャを使用してバックエンドモデルを呼び出すクライアントアプリケーションは、次のようなフローをたどります。

内向き: コンシューマー VPC 内のクライアントアプリケーションが、ローカルの Private Service Connect エンドポイントに対して OpenAI 互換の API 呼び出しを発行し、リージョン内部アプリケーションロードバランサを使用して GKE Inference Gateway に直接ルーティングします。
ペイロード検査: Gateway は、リクエスト本文で指定されたターゲットモデルパラメータを読み取り、HTTP ヘッダーに追加します。
コントロールプレーンの検証: Apigee が使用されている場合、クライアントの認証情報と割り当てがチェックされます。Model Armor がプロンプトをスクリーニングし、ポリシー違反やデータ漏洩がないかを確認します。
バックエンドの選択: Gateway は HTTPRoute マッピングを評価してターゲットプールを特定し、プレフィックスキャッシュ共有コンテキストを照合して、リアルタイムの Prometheus データに基づいて最も負荷の低い GPU または TPU レプリカにルーティングします。
外向き: レプリカが推論ワークロードを実行します。出力トークンは Model Armor を通過して最終的なレスポンス検証が行われ、その後、プライベート接続を介してストリーミングで送り返されます。

すべてのバックエンドで提供される設計パターン

このセクションでは、推論に使用できる複数のバックエンドタイプに焦点を当て、次の図に示すアーキテクチャの概要を説明します。エンドツーエンドのコンセプトを完全に理解するには、アーキテクチャに関するドキュメントすべてのバックエンドでの AI 推論モデル提供のためのネットワーキングをすべてお読みください。

GKE、Cloud Run、Agent Platform、オンプレミスデータセンター、外部クラウドなどの混合環境にまたがるアーキテクチャでは、次のコンポーネントが追加で使用されます。

リージョン内部アプリケーションロードバランサ: ルーティングロジック、SSL 終端、Service Extensions コールアウトを管理する、中央のレイヤ 7 ルーティングプロキシとして機能します。
推論ペイロードプロセッサ（Service Extensions）: これは、GKE Inference Gateway で使用される本文ベースのルーティングに似ていますが、アプリケーションロードバランサでこの機能を有効にするには、Service Extensions が必要です。軽量の Cloud Run コールアウトが、受信した OpenAI API リクエストの JSON 本文を検査し、ターゲットモデル識別子を抽出して、URL マップによるルーティングを実行するために X-Gateway-Model-Name ヘッダーを書き込みます。
ネットワークエンドポイントグループ（NEG）: 書き込まれたモデルヘッダーに基づいて、異種バックエンドへの柔軟なルーティングを実現します。

すべてのバックエンドのトラフィックフローの例

このアーキテクチャを使用してバックエンドモデルを呼び出すクライアントアプリケーションは、次のようなフローをたどります。

プライベート内向き: クライアントアプリケーションは、プライベート IP アドレス空間を介して Private Service Connect エンドポイントをターゲットにします。リージョン内部アプリケーションロードバランサがリクエストを受信します。
モデル名の抽出: ロードバランサは、ペイロードを Cloud Run 本文ベースのルーターコールアウトに送信します。このコールアウトは、JSON ペイロードを検査して X-Gateway-Model-Name ヘッダーを挿入します。
ポリシーと安全性の適用: リクエストは Apigee に渡されて ID と割り当てが検証され、その後 Model Armor に渡されて機密データが削除され、悪意のあるプロンプトがブロックされます。
NEG ルーティング: ロードバランサの URL マップがモデルヘッダーを検査し、一致するバックエンド NEG（Agent Platform、GKE、Cloud Run、ハイブリッド、インターネット）にリクエストを転送します。
プライベート配信: ターゲットバックエンドがモデルプロンプトを実行し、Model Armor が補完をスクリーニングして、結果が内向きパスに沿ってプライベートに返されます。

次のステップ

Google Cloud での AI ワークロードの構築について詳しくは、以下をご覧ください。

ドキュメントセット: エージェント型 AI アーキテクチャガイド
アーキテクチャセンター: Google Cloud におけるマルチエージェントプライベートネットワーキングパターン
ドキュメント: Gemini Enterprise Agent Platform のネットワーキングアクセスの概要

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

Google Cloud の U4 コンピューティングのご紹介: 超低レイテンシ取引を実現

Sun, 18 Oct 2026 16:30:00 +0000

※この投稿は米国時間 2026 年 10 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

資本市場における運用の成功は、安定したパフォーマンスと低レイテンシにかかっています。パケットのタイミングがわずかに変動するだけで、キューの優先順位や取引の実行順序が左右されるためです。同時に、取引所と市場参加者の双方が、従来のオンプレミスデータセンターにおいて厳しさを増す制約に直面しています。その内容は、電力や物理的なラックスペースの制限から、ハードウェア調達サイクルの長期化まで多岐にわたります。グローバルな資本市場では、物理的なコロケーションが持つ「スピードと、動作の確実性」に、クラウドの「動的なスケーラビリティと自動化」を融合させたソリューションがますます求められています。

Google Cloud Next ‘26 では、Ultra Low Latency（ULL）Solution の一般提供を発表しました。このソリューションは、クラウドで実行される高頻度取引ワークフローにて、超低レイテンシのネットワークと優れたアジリティを実現します。ULL Solution には、新しい U4 マシンファミリーも含まれており、こちらも一般提供が開始されています。

ULL Solution は、次の 3 つのインフラストラクチャ基盤で構成されています。

ハードウェアレベルのネットワーキング: スケーラブルなハードウェアベースのマルチキャストデータ配信によって、信頼性の高いマーケットデータフィードを実現します。
高度なネットワーキングオブザーバビリティ: ハードウェアレベルのタイミング精度で動的なネットワークトラフィックをキャプチャします。プライマリトラフィックのパフォーマンスに影響を与えることなく、確実な監査、マーケットリプレイ、そして厳密な取引検証を可能にします。
確実な動作を実現するハイパフォーマンスコンピューティング: 極めて低いレイテンシが要求される実行レイヤを、常に予測可能かつ一貫した時間で処理します。

ULL Solution のコンピューティング、ストレージ、ネットワーキング、オブザーバビリティを組み合わせることで、金融取引所や市場参加者は、以下のような数多くの技術的メリットを享受できます。

ベアメタルパフォーマンス: 専用のベアメタルコンピューティングにより、物理ホストリソースに直接アクセスできるため、ジッターを最小限に抑え、マーケットデータフィードや注文ルーティングにおいて、ブレのない低レイテンシでの実行を実現します。
高パフォーマンスのストレージオプション: ローカル Titanium SSD がホスト上でリアルタイムのトランザクションとティックロギングを処理し、スケーラブルな Google Cloud Hyperdisk が永続的なマーケットデータのアーカイブと分析を補完します。
物理的なトラフィックの分離: ULL トレーディングファブリックの冗長 A/B マルチキャストマーケットフィードには、2 つの独立した専用 Titanium アダプターを介してアクセスします。一方、3 つ目の独立した Titanium アダプターは、テレメトリーと管理をオフロードし、Google Cloud サービスへのアクセスを提供します。
ハードウェアアクセラレーションによるマルチキャスト配信: ULL ネットワークアーキテクチャは、ハードウェアレベルのマルチキャストフィード取り込みをサポートしています。これにより、市場参加者は従来のハイパーバイザーレベルの仮想スイッチをバイパスし、高スループットのマーケットデータを低レイテンシの取引アプリケーションに直接ストリーミングできます。
パケット処理の高速化: OpenOnload と DPDK のサポートにより、アプリケーションコードの変更を最小限に抑えながら、Linux ユーザー空間ネットワーキングによる予測可能なユニキャストおよびマルチキャストパケット処理を実現します。
高精度なタイミングと UTC 同期: Google Cloud の Firefly クロック同期システムとの統合により、10 ナノ秒未満のネットワークレベルのタイムスタンプを常に実現し、金融取引所の規制要件である「100 マイクロ秒未満」を大きく上回る精度での UTC 同期を可能にします。
組み込みのテレメトリー: 24 時間 365 日の低レイテンシパケットキャプチャと、規制遵守やリアルタイム解析に向けたシームレスなアウトオブバンドパケットブローカリングにより、主要トラフィックのパフォーマンスに影響を与えることなく、高度な可視性を確保します。
24 時間 365 日市場に対応: 本番環境ワークロードをライブ取引専用のプライマリゾーンに分離し、日常的なメンテナンスや認定テストは更新およびテスト用のセカンダリゾーンで行うことで、24 時間体制で継続的に取引に対応できる設計となっています。

ULL Solution のコンピューティングは、新しい U4 マシンファミリーによって提供されます。このファミリーは、3 つの特化型マシンシリーズを通じて、ブレのないパフォーマンスと超低レイテンシのコンピューティングを実現します。具体的には、3 つの物理 NIC を備えたデュアルソケットのベアメタルインスタンス（取引所運営者向けの U4P、市場参加者向けの U4C）と、運営者、参加者、サービス提供者向けの U4S 高パフォーマンス VM がラインナップされています。

マシンシリーズ	CPU プラットフォーム	CPU コア	メモリ	NIC	ストレージオプション
U4P （ベアメタル）	Intel 第 5 世代 Xeon（Emerald Rapids）	物理コア: 120	512 GB / 768 GB	物理 NIC: 3（標準 1 + ULL 2）	ローカル Titanium SSD（12 TiB）、Hyperdisk
U4C （ベアメタル）	Intel 第 5 世代 Xeon（Emerald Rapids）	物理コア: 120	512 GB または 768 GB	物理 NIC: 3（標準 1 + ULL 2）	ローカル Titanium SSD（12 TiB）、Hyperdisk
U4S （VM）	Intel 第 6 世代 Xeon（Granite Rapids）	vCPU: 2～288	最大 2,232 GB	マルチ vNIC（最大 200 Gbps）	ローカル Titanium SSD（18 TiB）、Hyperdisk

Google が U4 マシンファミリーを開発したのは、世界で最も厳しい技術要件が求められる市場が Google Cloud 上でシステムを稼働させ、クラウドサービスとスケーラビリティのメリットを享受できるようにするためです。その一例が、CME Group との継続的なパートナーシップです。これを通じて、上場デリバティブ市場を Google Cloud に移行しています。同プロジェクトにおいて、U4C と U4P のベアメタルインスタンスは、物理コロケーションに直接接続する場合と同等のレイテンシを達成し、予測可能な低レイテンシのクロック精度と、ネイティブなハードウェアマルチキャストフィードの取り込みを実現します。このアーキテクチャは、取引所の基幹システムや取引戦略を、金融市場が求めるスピード、一貫性、そして制御性を備えたクラウド環境で十分に稼働できることを実証しています。

「世界をリードするデリバティブ取引所をクラウドへ移行するには、パフォーマンス、レイテンシ、そして信頼性のすべてにおいて一切の妥協が許されません。Google Cloud の Ultra Low Latency Solution と U4 インスタンスファミリーは、金融市場インフラストラクチャの歴史におけるブレークスルーを象徴するものです。動作の確実性に優れた超低レイテンシのネットワーキングと、専用のベアメタルコンピューティングをクラウドのメリットと組み合わせることで、市場参加者は、従来のコロケーションと同等のスピードとクラウドのアジリティを活かして、マーケットデータの取り込みから取引の執行までを迅速に行うことが可能になります。」- CME Group、マーケットエンジニアリング担当マネージングディレクター、Pearce Peck-Walden 氏

Google Cloud クラウドネイティブなインフラストラクチャを活用

ULL Solution は、一部のプライベート Google Cloud リージョンで提供されており、トレーディングチームは、迅速な自動リソースプロビジョニング、オンデマンドの容量スケーリング、動的なフリート管理といった、クラウドインフラストラクチャならではのメリットを最大限に活用できます。トレーディングチームは、隔離された専用の ULL ネットワーク上で超低レイテンシの取引を実行できるだけでなく、独立したネットワークインターフェースを介して、データストリームを BigQuery や Gemini Enterprise などの Google Cloud サービスにオフロードできます。

ティックツートレードのワークフローの管理や、リアルタイムの市場データを処理する取引所参加者にとって、マイクロ秒単位のわずかな変動も死活問題となります。ベアメタルインスタンスである U4P および U4C マシンシリーズは、レイテンシに極めて敏感な実行レイヤにおいて、仮想化によるオーバーヘッドを一切発生させません。これらのベアメタルインスタンスは、Google Cloud の Titanium オフロードシステムアーキテクチャを活用することで、ホストリソースへの直接アクセスを可能にします。Compute Engine インスタンスでは、標準の Google Cloud API を介した専用ハードウェアのプロビジョニング、Infrastructure as Code によるデプロイのオーケストレーション、Cloud Next Generation Firewall（NGFW）ポリシーの適用、豊富なテレメトリーの収集を行うことができます。

U4S VM シリーズは、取引前のリスク検証やリアルタイム解析といった用途において、これらのベアメタルサービスを補完する役割を果たします。U4P インスタンスや U4C インスタンスと並行してデプロイされるこれらの VM は、取引アーキテクチャ全体のトランジットホップを短縮すると同時に、2〜288 vCPU の弾力的なスケーリングと、最大 100 Gbps のネットワーク帯域幅を提供します。

「U4 インスタンスのテストを通じて、Google Cloud が、極めて高い処理能力が求められる当社の取引所取引ワークロードに必要な低レイテンシと動作の確実性を備えていることが実証されました。ベアメタルと VM の両方のオプションが用意されていることで、費用対効果を評価し、それぞれの取引戦略に最適なインフラストラクチャを柔軟に選択できるようになります。」 - Prime Trading、EVP / CTO、Corbin Kidd 氏

「ティックツートレードのパフォーマンス検証において、U4C ベアメタルインスタンスは卓越した処理速度を示し、クラウドコンピューティングと超低レイテンシネットワーキングの組み合わせが、マイクロ秒単位の過酷な取引需要にも余裕を持って対応できることを実証しました。しかし、U4 シリーズの真の強みは、単なる処理スピードではなく、構造的な「動作の確実性」にあります。Google Cloud の U4 ベアメタルファミリーのストレステストを行ったところ、パフォーマンス曲線はほぼ完全に平坦なままでした。これは、これらのクラウドコンピューティング設計が、市場参加者が求める極めて厳格な「動作の確実性」を十分に提供できるレベルに達したことを裏付けています。」- 28Stone、エクスペリエンスモダナイゼーション担当グローバル責任者、Christopher Wilson 氏

将来を見据えると、この低レイテンシアーキテクチャはアルゴリズム取引の強固な基盤となり、企業はリアルタイムの市場データを AI 駆動の取引モデルに直接取り込めるようになります。

取引ワークロードのストレージと配置

U4 ファミリーは、Google Cloud のストレージオプションとプレースメントポリシーをサポートしており、トレーディングチームが取引データを高速に記録し、マシン間におけるネットワークレイテンシの極小化できるようにします。

高速ロギング用のローカル Titanium SSD: 取引の実行パフォーマンスを損なうことなく、リアルタイムの取引ロギングやデータのキャッシュ保存を行うために、U4P と U4C は最大 12 TiB の直接接続された NVMe SSD を提供し、U4S VM は最大 18 TiB までスケールアップできます。
データアーカイブ用の Hyperdisk: 過去の市場データ、バックテストモデル、コンプライアンス監査用アーカイブの保管に対応するため、すべての U4 シリーズで Hyperdisk Balanced および Hyperdisk Extreme ボリュームをアタッチでき、インスタンスあたり最大 32 ボリューム、512 TiB までスケールアップできます。
プレースメントポリシー: 物理的なネットワークホップを削減するために、コンパクトプレースメントポリシーでは、関連するマシンをデータセンター内の近接した場所に配置します。一方、スプレッドプレースメントポリシーでは、レジリエンスを高めるために、マシンを別々のラックに配置します。

ULL Solution を使ってみる

ULL Solution により、金融取引所の運営者、取引所参加者、取引サービス提供者は、現在求められるスピードと信頼性で取引を行えるだけでなく、進化し続ける AI やインフラストラクチャの機能を活用し、未来の取引を見据えて自社のビジネスを優位に位置付けることができます。ULL Solution は、一部の Google Cloud リージョンでご利用いただけます。詳細については、一般公開ドキュメントをご覧いただき、Google のチームにアクセスをリクエストしてください。

- Google Cloud、プロダクトマネージャー、Disha Chopra

- Google Cloud、プロダクトマネージャー、Yarden Halperin

AI ワークロードのコンピューティングを柔軟に選択できるよう Google Cloud ネットワーキングがサポート

Fri, 02 Oct 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 9 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

AI ワークロード用のリソース、特にアクセラレータの可用性は、業界全体で課題となる可能性があります。特定のタイプのアクセラレータを中心に構築されている場合、AI ワークロードのデプロイが遅くなる可能性があります。フルイドコンピューティングというコンセプトにより、ユースケースに適合する利用可能なリソースに基づき、複数のオプションを使用して AI デプロイを設計することが可能になります。

このブログ投稿では、Google Cloud ネットワーキングが AI ワークロードをどのようにサポートしているかを紹介するとともに、アクセラレータ（GPU または TPU）を選択する際の考慮事項について説明します。バックエンドのネットワーキングコンポーネント構成は、それぞれで完全に同じではないためです。

リソースオプション

AI デプロイで実現したいタスクを決定したら、次に重要な要素は、それを実行する実際のハードウェアです。この場合、プライベート LLM の推論を実行する必要があり、ターゲットは A4 VM（a4-highgpu-8g）で利用可能な NVIDIA B200 GPU ファミリーです。

これで、達成したいことと、利用可能なコンピューティングオプションは特定できました。しかし、「本当にそれが利用できるのか」という課題があります。

リソースにアクセスするには、次のような方法があります。

Dynamic Workload Scheduler（Flex Start VM）: 必要なアクセラレータノードがすべて同時に利用可能になるまでワークロードをキューに入れ、それらをまとめてプロビジョニングし、最大 7 日間プリエンプト不可で実行します。
Dynamic Workload Scheduler（カレンダーモード）: 1～90 日前にアクセラレータ容量を予約でき、開始時間と終了時間が保証されるため、スケジュールされた事前トレーニングの実行やベンチマークに最適です。
将来の予約: 将来の特定の日付から、指定したゾーンで確約されたハードウェアへのアクセスを保証します。
フレックス予約: 短期契約により、複数年のロックインなしで、希少なアクセラレータノードを確保できます。
動的なノード自動プロビジョニングと ComputeClasses: Google Kubernetes Engine（GKE）では、ComputeClasses 内にマルチファミリーフォールバックリストを定義することで、プライマリプールがリージョンの制約に直面した場合に、クラスタが代替アクセラレータタイプのプロビジョニングを自動的に試行できます。
Spot VM: フォールトトレラントなチェックポイント付きバッチジョブ向けに、余剰コンピューティングを大幅な割引価格で提供します。

詳しくは、ブログ投稿 コンピューティングリソースの不足を防止する: GKE リソースの入手可能性に関する実践ガイド をご覧ください。

ネットワーキングの選択肢

アクセラレータのネットワーキングコンポーネントは選択内容によって異なるため、標準ネットワーキング、高速 GPU ネットワーキング（TCPX / TCPXO と RoCEv2）、TPU ネットワーキング、Cloud Run の 4 つの構成について説明します。

標準ネットワーキング

サポートされているアクセラレータ: NVIDIA T4（N1 シリーズ）、NVIDIA L4（G2 シリーズ）、NVIDIA A100（A2 マシンシリーズのシングルノードとマルチノード）、Cloud TPU v3、 Cloud TPU v5e（単一ホスト / スタンドアロンスライス）。
アーキテクチャ: ノードは、標準の TCP / IP を介して Google Virtual NIC（gVNIC）を使用し、プライマリ Virtual Private Cloud（VPC）ネットワーク経由で通信します。
ワークロードの適合性: Google Cloud コンピューティング環境間で簡単に移植できます。標準の VPC ルーティングとネットワークポリシーを使用し、分散データの前処理、パイプラインステージの分離、独立した推論レプリカ、コンピュータビジョンワークロードをサポートします。

高速 GPU ネットワーキング（TCPX / TCPXO、RoCEv2）

分散トレーニングとマルチノード推論には、膨大なパラメータ交換と集団通信を処理するための特殊なマルチレールネットワークファブリックが必要です。

GPUDirect-TCPX ファブリックと GPUDirect-TCPXO ファブリック

サポートされているアクセラレータ: NVIDIA H100（4 レールの A3 High VM）と NVIDIA H100 Mega（8 レールの A3 Mega VM）。
アーキテクチャ: カスタムの GPUDirect-TCPX（4 つの専用 VPC）と GPUDirect-TCPXO（8 つの専用 VPC）オフロードエンジンを使用して、ネイティブ RDMA ハードウェアを必要とせずに、標準のイーサネットインフラストラクチャ上で高スループットのマルチレール GPU 通信を実現します。
デプロイブループリント: これらのマルチ VPC トポロジは、Cluster Toolkit の事前構築済みブループリントを使用するなど、さまざまな方法でデプロイできます。

RoCEv2 ファブリック（VM とベアメタル）

サポートされているアクセラレータ: NVIDIA H200（A3 Ultra VM）、NVIDIA B200（A4 VM）、NVIDIA GB200 NVL72（A4X VM）、NVIDIA GB300（A4X Max ベアメタル）。
ゾーンネットワークプロファイル: RoCEv2 は、専用のゾーンネットワークプロファイルに接続された専用の RDMA VPC 上で動作します。VM インスタンス（A3 Ultra、A4、A4X）は ZONE-vpc-roce プロファイルを使用し、ベアメタルインスタンス（A4X Max など）は専用の ZONE-vpc-roce-metal ベアメタルプロファイルを使用します。
レール整列型ファブリック: この専用 VPC は GPU 通信用に厳密に分離されており、アクセラレータ NIC に直接マッピングされたサブネットが含まれています。バックエンドはレール整列型で、ジャンボフレーム（MTU 8896）をサポートし、レール間の干渉を最小限に抑えながら、ノンブロッキングのマルチテラビット帯域幅を実現します。
GKE Dynamic Resource Allocation Network（DRANET）による自動配線: これらの GPU を GKE にデプロイする場合、GKE マネージド DRANET を使用して、追加のネットワークを自動的にプロビジョニングし、RDMA ネットワークインターフェースを GPU にマッピングするドライバを割り当てることができます。これらは、標準の Kubernetes リソースクレームを使用して、ワークロード Pod に直接割り当てて使用できます。
ターンキーデプロイ: RDMA VPC、MTU チューニング、DRA ドライバなど、このエンドツーエンドのスタック全体を、Cluster Toolkit の自動化されたブループリントを使用してデプロイできます。

TPU ネットワーキング

サポートされているアクセラレータ: Cloud TPU v4、Cloud TPU v5p、Cloud TPU v5e（マルチホスト Pod スライス）、Cloud TPU v6e（Trillium）、TPU7x（Ironwood）。
チップ間相互接続（ICI）: TPU Pod またはスライス内では、チップは 2D または 3D トーラスメッシュで構成された専用の超低レイテンシ光リンクを介して直接通信し、従来のネットワークスタックを完全にバイパスします。
光回線スイッチ（OCS）: TPU v4 と TPU v5p の SuperPod では、ソフトウェアで再構成可能な OCS ユニットが物理ネットワークトポロジを動的に変更し、障害のあるトレイを迂回して、手動でケーブルを再接続することなく、カスタムサイズのアクセラレータスライスをプロビジョニングします。
マルチ NIC アーキテクチャ（TPU v6e 以降）: 以前の TPU 世代は、スライス内の ICI とホストトラフィック用の単一 NIC に依存していましたが、Cloud TPU v6e（Trillium）と TPU7x には、ネイティブのマルチ NIC アーキテクチャが導入されています。このアーキテクチャでは、ワーカーノードが標準の Kubernetes 管理トラフィックをプライマリ VPC に分離し、高スループットの TPU データとクロススライス通信用に構成されたセカンダリ専用 VPC を使用します。
TPU デプロイ用の DRANET: これらの TPU を GKE にデプロイする場合、GKE マネージド DRANET を使用して、追加のネットワークを自動的にプロビジョニングし、TPU 通信用にドライバを割り当てることができます。これらは、標準の Kubernetes リソースクレームを使用して、ワークロード Pod に直接割り当てて使用できます。
データセンターネットワーク（DCN）マルチスライス: 個々の TPU スライスを超えてスケールするモデルの場合、Cloud TPU マルチスライスは、これらの専用マルチ NIC パスを利用し、Google の高速 Jupiter データセンターネットワークを介して複数の独立した ICI メッシュを接続します。

Cloud Run

サポートされているアクセラレータ: Cloud Run GPU サービスの NVIDIA L4（G2 シリーズ）と NVIDIA RTX PRO 6000（Blackwell）。
ダイレクト VPC 下り（外向き）: ダイレクト VPC 下り（外向き）を介して 1 分未満で IP を割り当てることで、サーバーレスコンテナをプライベート VPC ネットワークに直接バインドします。これにより、公共のインターネットを経由したり、レガシーコネクタ VM を必要としたりすることなく、内部データレイク、データベース、プライベート API にセキュアかつ低レイテンシでアクセスできます。

まとめ

Google Cloud のネットワーキングオプションは、さまざまなアクセラレータタイプをサポートしています。フルイドコンピューティングを使用する場合、ワークロードのパフォーマンスが最適化されるベストな設計をサポートするようネットワーク設定を調整できます。

次のステップ

Google Cloud AI インフラストラクチャとネットワーキングアーキテクチャについて詳しくは、以下のリソースをご覧ください。

ブログ記事: AI インフラストラクチャの動的容量管理
チュートリアル: フルイドコンピューティングを使用して GKE 上にエラスティックでスケーラブルな LLM 推論プラットフォームを構築する方法
ブログ記事: Google Cloud ネットワーキングが AI ワークロードをサポートする仕組み

ご質問やご意見がございましたら、LinkedIn 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

Airtel、2026 年インディアンプレミアリーグのクリケット中継を完璧に配信

Fri, 18 Sep 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 9 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

インディアンプレミアリーグ（IPL）の何百万人もの熱狂的なファンにとって、クリケットのライブ配信を完璧な状態で視聴できることは絶対条件です。世界最大規模の同時視聴者数を誇るリーグのテレビ放送を制作する Airtel にとって、パケットのドロップやバッファリングは、決してあってはならないことです。

IPL 2026 のシーズン中、Airtel は Google Cloud と提携して、このデジタル配信に対応しました。このストリーミングインフラストラクチャが 74 試合にわたって配信した外向きデータは数百ペタバイトに及びます。決勝戦だけで数百億件のリクエストが処理され、ピーク時の外向きトラフィックは数 Tbps に達しました。

このような同時接続数の急増に対応して動画を配信するには、ローカル化を徹底追及したエッジアーキテクチャと、プロアクティブな運用モニタリングを組み合わせる必要があります。

IPL 2026 の目標は、同時接続数の急増やネットワークの状況にかかわらず、インド全土のクリケットファンに、スタジアムにいるかのようなスムーズな視聴体験を提供することでした。Airtel は、Google Cloud と提携して Media CDN を使用することで、ローカルエッジへの近接性と優れたキャッシュ効率を実現できました。そして、これを試合当日のプロアクティブなリアルタイムモニタリングと組み合わせることで、最初から最後まで信頼性の高いブロードキャスト体験を提供できました。

同時接続数とエッジ効率を考慮した設計

スポーツのライブ配信における主な課題の一つは、トラフィックの急増をシームレスに処理し、ストリーミングのパフォーマンスを低下させたり、バックエンドの配信元に過剰な負荷をかけたりしないことです。最終オーバーは何百万人もの視聴者が同時に視聴します。1 ミリ秒が勝負を分けるため、この点が特に重要となります。

Airtel は、インドの多様な ISP 環境にわたってコンテンツ配信を高速化するために、Google Cloud の Media CDN を利用しました。Google の広範なグローバルエッジネットワークを活用することで、エンドユーザーに物理的に近いエッジロケーションから視聴者のリクエストを処理できるようになります。この徹底したローカル化が、ブロードキャストの成功の礎となりました。インド国内からローカル配信されたトーナメントのトラフィックは 99.9% にも及びます。

この効率的なアーキテクチャにより、ネットワークホップが最小限に抑えられ、トランジットの輻輳が軽減されました。その結果、全 74 試合にわたりインフラストラクチャと視聴者エクスペリエンスの指標が大幅に向上しました。

優れたキャッシュ効率: キャッシュヒット率が全体的に 98% を超えました。大量の視聴者トラフィック負荷をエッジで効果的に吸収することで、プレーオフの視聴者数がピークに達したときでも、配信元サーバー / 動画プラットフォームに対する需要は最小限に抑えられました。
一貫した超低レイテンシ: Airtel はトーナメント中に 300 ミリ秒未満の p99 レイテンシを維持しました。その結果、ストリーミング開始までの時間が短縮され、試合の重要な場面でのバッファリングのリスクが最小限に抑えられました。

運用準備のためのプロアクティブな戦略

インテリジェントなバックエンドアーキテクチャの維持は、Airtel の IPL ストリーミング戦略において極めて重要なことでしたが、それだけでは不十分でした。全 74 試合連続で一発勝負のライブ配信を行うには、入念な運用準備と、試合当日のプロアクティブな対応も必要でした。

Airtel と Google Cloud は、最初の試合が始まるずっと前に潜在的なボトルネックを特定する必要があることを認識し、緊密に統合された運用サポートモデルを確立しました。

トーナメント前のサポート準備状況の確認: 開幕戦のかなり前に、共同エンジニアリングチームが包括的なサポート準備状況の確認を実施しました。チームは、トラフィック予測の監査、マニフェスト構成の確認、フェイルオーバーメカニズムの検証を早期に実施することで、クライアントが堅牢な準備態勢を整えられるようサポートし、結果的にトーナメント中の運用上の摩擦を軽減しました。
Monitoring as a Service（MaaS）: チームは、Media CDN 上の MaaS を通じて継続的かつプロアクティブなテレメトリーモニタリングを維持しました。リアルタイムのオブザーバビリティにより、異常が視聴者の再生に影響を与える前にネットワークの変化を早期に検出して軽減できました。
試合日と週末の専用サポート: スポーツのライブ配信は通常の営業時間内に行われるとは限らないため、Airtel はすべての試合を対象とした包括的なモニタリングプロトコルを確立しました。週末の重大な試合や、命運をかけたプレーオフのステージでは、Google Cloud のテクニカルアカウントマネジメントチームと MaaS チームが Airtel のエンジニアリングチームと緊密に連携して、専任でリアルタイムのイベントサポートを提供しました。

優れたライブ配信のためのブループリント

Airtel が IPL 2026 のストリーミングに成功したことで、膨大な同時接続数への対応には、アーキテクチャ、エッジのローカル化、運用ガバナンスにわたる統合戦略が不可欠であると実証されました。Airtel は、98% 以上のキャッシュヒット率、99.9% のローカル配信、試合当日のプロアクティブなモニタリングを組み合わせることで、大規模なライブスポーツ放送のベンチマークを達成しました。

このデプロイメントは、同時接続数が多いイベント向けにライブメディア配信をスケールする際の技術アーキテクチャと運用戦略の全体像を示します。ライブ配信とエッジ配信の最適化について詳しくは、Media CDN のデベロッパー向けドキュメントをご覧ください。

-Hitesh Bhatia, Assistant Vice President and Head of Engineering, Airtel Digital

-Anand Vijayan, Senior Product Manager, Media CDN, Google Cloud

Uber がクラウド移行を妨げることなくネットワークの信頼性を向上させた方法

Wed, 09 Sep 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 8 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

Uber には、サービスを展開している都市との共通点が数多くあります。どちらも常に変化と成長を続けており、混雑や無秩序な拡大を防ぐために、それに伴うトラフィックを慎重に管理する必要があります。

Uber は、拡大するネットワークを管理するために技術戦略を絶えず進化させてきました。こうした綿密な計画と継続的な進化が、プラットフォーム全体のアプリケーショントラフィックの円滑な運用を支えています。最終的には、いつでもシームレスに動作する信頼性の高い大規模なプラットフォームを維持することが、ユーザーの信頼を維持する鍵となります。

この取り組みにおける重要なソリューションの一つが、Cloud Interconnect 上の Application Awareness です。ハイブリッドネットワーク全体でアプリケーションの優先順位付けを行う業界初のツールである Cloud Interconnect 上の Application Awareness は、Uber が重要なトラフィックを優先し、ネットワークの輻輳が発生した場合でもビジネスの継続性を確保するのに役立っています。

Uber は、Cloud Interconnect 上の Application Awareness の初期設計パートナーとして、この機能が Uber のグローバル規模の運用ニーズを満たすものとなるよう貢献しました。これにより、Uber の日々の業務が改善されただけでなく、切り替え時のサービス中断のリスクを抑えられるという確信を得たことで、Google Cloud への移行を自信を持って進められるようになりました。

この投稿では、Uber が最も求めていた機能とその理由、Cloud Interconnect 上の Application Awareness の内部の仕組み、そしてそれが他の組織にもどのように役立つかについて説明します。

重要なトラフィックの優先順位付け

分散型、ハイブリッド、またはマルチクラウドのアプリケーションをグローバル規模で移行する場合、ネットワークの信頼性が最大の懸念事項となります。どんなに意義のある移行であっても、稼働中のサービスを中断させてしまうようでは、その価値は損なわれてしまいます。Uber のような組織にとって、台頭する AI ユースケースを含む大規模なデータ分析ワークロードを支えるための膨大なデータ転送は、ネットワークリンクを飽和状態にし、重要なアプリケーショントラフィックの信頼性を損なうリスクを招きかねません。

標準的なクラウド接続手法では、企業は通常、膨大なインフラストラクチャのニーズを満たすために、単純に帯域幅をオーバープロビジョニングするという方法をとります。しかし、昨今のハイブリッドクラウドの需要と、Uber のような組織の規模を考えると、ピーク時の使用量に合わせてネットワーク容量をオーバープロビジョニングすることは、費用がかかりすぎるうえ、信頼性も低い場合があります。

最先端の AI イノベーションを統合すると、オーバープロビジョニングの欠点がさらに拡大します。Uber は、ネットワークを混雑させることなく、ビジネスクリティカルなアプリケーションのパフォーマンスを保護しながら、大量のデータ転送に対応できるシステムを必要としています。

Cloud Interconnect の Application Awareness が備える 4 つの主要機能（トラフィック処理、輻輳対応、レイテンシ管理、コスト効率）を活用することで、Uber は最新の技術スタックに不可欠なネットワークの最適化を実現しました。

Uber は限定公開プレビューの段階からこの機能の導入を開始しました。まずはアリゾナ州フェニックスとバージニア州アッシュバーンの Google Cloud Interconnect から着手し、その後インフラ全体へと展開を広げました。Cloud Interconnect 上の Application Awareness により、Uber は DSCP マーキングや構成済みのキューイングプロファイルを活用して、エンドユーザーのアプリケーショントラフィックを分類し、緊急性の低いデータよりも優先的に処理できるようになります。

次の表では、Cloud Interconnect 上の Application Awareness の 4 つの主な機能、従来の方式との違い、そして Uber のような組織の運用継続性の向上にどのように役立つかについて説明しています。

機能	標準的な接続ソリューション	Cloud Interconnect 上の Application Awareness
トラフィックの処理	すべてのトラフィックが平等に扱われる（先入れ先出し）	トラフィックを 6 つの異なるトラフィッククラスに分類
輻輳対応	バースト時に優先度の高いアプリケーショントラフィックがドロップされる可能性がある	ビジネスクリティカルなトラフィックは、厳密な優先度ポリシーまたは帯域幅共有ポリシーによって保護される
レイテンシ管理	優先度の高いアプリケーションのレイテンシが予測不能	時間的制約のあるワークロードに対して、予測可能かつ一貫した低レイテンシを実現
コスト効率	ピークを吸収するために高額なオーバープロビジョニングが必要	効率的な帯域幅利用と TCO の削減

Uber の事例の要点

Uber にとって、Cloud Interconnect 上の Application Awareness を導入し、ネットワーク上のビジネスクリティカルなトラフィックに優先順位を付けられることの価値は、すぐに目に見える形で現れました。この取り組みを通じて、Uber は、同様のハイブリッドクラウドの課題を抱える他の企業が再現できるブループリントも作成しました。このブループリントの主要な要素は次のとおりです。

ビジネス継続性の確保: Uber は、トラフィック量の多い大規模なイベントが発生した際に、優先すべきアプリケーショントラフィックをリアルタイムに決定できます。これにより、計画的か不測の事態かを問わず、極端な負荷が発生するような状況下でも、ミッションクリティカルなアプリケーションの稼働を維持できます。Uber の経営陣は、Cloud Interconnect 上の Application Awareness はグローバルな事業運営に重要であると述べています。
帯域幅の効率的な利用: 輻輳を防ぐために帯域幅を盲目的にオーバープロビジョニングするのではなく、Application Awareness により、Uber は予想されるネットワーク帯域幅のニーズに合わせて、既存の Cloud Interconnect 容量をより有効に活用できるようになりました。その結果、ネットワークインフラストラクチャの総所有コストが削減されています。
ワークロード移行の障害を排除: 重要なアプリケーションをネットワークの輻輳から保護することで、Uber は重要なワークロードを Google Cloud に移行し、その過程で運用上のオーバーヘッドを大幅に削減できました。

「Cloud Interconnect 上の Application Awareness は、より戦略的なワークロードの Google Cloud 移行を実現する鍵となりました。世界規模で需要が急増する際にも、サービスの信頼性を維持するうえで不可欠な役割を果たしています。トラフィックにインテリジェントに優先順位を付けることで、優先度の高いサービスを保護し、インフラストラクチャの効率を高め、総所有コストを削減できます。これは単なる機能の導入にとどまりません。当社のビジネスに不可欠なソリューションを共に創り上げた、両社の深いエンジニアリングパートナーシップの賜物です。」– Uber、エンジニアリングディレクター、Harry Liu 氏

AI とそれ以外のネットワークの信頼性を確保

クラウドベースの AI モデル、分散アプリケーション、データ分析を統合する企業が増えるにつれ、それに伴う大量のデータ転送に対応する準備を整えることが、ビジネス上の必須事項となっています。しかし、その一方で、重要なアプリケーションの信頼性を決して損なわないようにする必要もあります。

Uber は、Cloud Interconnect 上の Application Awareness を使用することで、ビジネスクリティカルなトラフィックを保護するために単に帯域幅をオーバープロビジョニングするのではなく、最新のハイブリッドクラウド戦略やマルチクラウド戦略を採用するために必要な安定性を構築することが不可欠なステップであることを実証しました。

Cloud Interconnect が組織にもたらすメリットについて詳しくは、さまざまな業界における Cloud Interconnect の可能性に関するブログをご覧ください。さらに詳しく知りたい場合は、Google のネットワーキングと業界のエキスパートがサポートいたします。

- Uber、上級エンジニア、Jean He 氏

- Google Cloud、プリンシパルアーキテクト、Gopinath Balakrishnan

Fault Injection Testing で復元力テスト戦略を簡素化

Wed, 09 Sep 2026 00:30:00 +0000

※この投稿は米国時間 2026 年 8 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

データベースの障害やネットワークパスの不調が発生しても、ミッションクリティカルなクラウドサービスはオンラインの状態を維持し続けなければなりません。しかし、現代の分散システムは複雑化しており、高可用性の確保はますます困難になっています。

障害発生時にも可用性と信頼性を維持できるよう、Fault Injection Testing のプレビュー版をリリースいたしました。Fault Injection Testing は、開発者やアーキテクトが障害テストを自動化し、サービス中断時にも予測可能な動作を確保できるように設計されています。

意図的に障害を環境に注入することで、実際のサービス停止が顧客に影響を与える前に、安全メカニズムを検証できます。

ネイティブな復元力テストが重要な理由

セルフホスト型のデータセンターとは異なり、クラウドアプリケーションでは、フェイルオーバーテストを容易にするために、基盤となるインフラストラクチャへの直接アクセスが制限されています。

アプリケーションが障害を乗り越えられることを証明するネイティブツールがなければ、信頼性戦略に重大なギャップが生じ、複数のリスクにさらされることになります。

信頼と評判の低下: 障害が頻繁に発生したり、パフォーマンスが低下したりすると、顧客の不満を招き、ブランドイメージに長期的なダメージを与えます。
コンプライアンスと規制によるペナルティ: 多くの業界、特に金融機関では、障害復旧機能を証明できないと、コンプライアンス違反、監査、罰金につながる可能性があります。
移行の遅延: ゾーン障害が発生しても重要なアプリケーションの安定性を維持できることを検証できない場合、大規模な移行プロジェクトは停滞してしまいがちです。

Fault Injection Testing の仕組み

Fault Injection Testing では、テストテンプレートを作成してテストを実行できます。これらのテンプレートはブループリントとして機能し、注入する特定の障害と、テストの対象となるリソースを定義します。

この公開プレビュー版では、次の 2 つの主な障害シナリオをテストできます。

Cloud SQL のフェイルオーバー: この障害は、高可用性 Cloud SQL インスタンスの、プライマリゾーンからスタンバイゾーンへのフェイルオーバーをトリガーします。
アプリケーショントラフィックの劣化: レイヤ 7 ロードバランサを介して、レイテンシと HTTP エラーコードを選択的に追加できます。

Fault Injection Testing では、障害が注入される前に自動ドライランが実行されます。この読み取り専用のシミュレーションでは、権限がチェックされ、影響を受けるすべてのリソースの最新リストが提供されます。

スコープを確認したら、手動で注入を開始できます。テンプレートで定義した期間が経過すると、タイマーが切れて障害が元に戻ります。

テスト中に、アプリケーションが計画どおりに動作していることを確認できます。計画どおりに進まない場合は、停止と復元の機能を使用して、テストを直ちに停止し、リソースを通常の状態に復元できます。

プレビュー期間中は、ベストプラクティスとして、本番環境以外で FIT を使用することをおすすめします。プレビュー版では、サービスが既存のテスト手法にどのように適合し、補完するのかを早期に確認できます。また、プロダクトの改善に役立つフィードバックを Google に提供することもできます。

企業向けに設計

KeyBank や Servier などのパートナーは、すでに Fault Injection Testing を使用してデプロイを検証しています。これらの組織はネイティブなフォールトインジェクションを活用することで、ゾーンの停止といった極めて過酷な障害シナリオをシミュレーションし、サービスの安定稼働を確かなものにしています。

Fault Injection Testing を使ってみる

Fault Injection Testing は、Google Cloud コンソール、gcloud CLI、REST API を介して利用できます。

プレビュー版へのアクセスをリクエストする: Google Cloud アカウントチームに連絡して、プロジェクトをプレビュー版に追加します。
API を有効にする: Google Cloud コンソールで「Fault Testing API」を検索し、有効にします。
ロールを割り当てる: チームに roles/faulttesting.operator ロールがあり、テストを構成して実行できることを確認します。
最初のドライランを実行する: 本番環境以外で Cloud SQL またはロードバランサリソースのテンプレートを作成し、ドライランを実行して潜在的な影響を確認します。

実装の詳細については、Google のアカウント担当者にお問い合わせいただくか、Fault Injection Testing のユーザーガイドをご覧ください。

- Google Cloud、グループプロダクトマネージャー、Toby Owen

TelevisaUnivision が Google Cloud を利用して FIFA ワールドカップを数百万人にストリーミング配信

Tue, 25 Aug 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 8 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

スポーツのライブ配信は、デジタルメディアインフラストラクチャにとって究極のストレステストとなります。運営面の成否はミリ秒単位で評価され、何百万人もの視聴者が生で同時に目にします。2026 FIFA ワールドカップ開催期間中、スペイン語メディアの大手コングロマリットである TelevisaUnivision は、大きな課題に直面しました。メキシコは主要な開催国であると同時に、代表チームが有力な優勝候補であったため、ファンの関心は高く、ラテンアメリカ全域と TelevisaUnivision の ViX ストリーミングプラットフォームで前例のない需要が発生しました。

TelevisaUnivision のような大手放送局にとって、重要なイベントはブランドと評判に直接的かつ長期的な影響を及ぼします。視聴者は、試合の重要な瞬間を、途切れることなく、鮮明に視聴することを求めています。決定的なゴールシーンでの映像の中断、キックオフ時のログイン遅延、ストリーミング解像度の低下は、顧客満足度に直接影響し、サブスクライバーの離脱やブランドの希薄化を招くリスクがあります。トップレベルの世界的スポーツイベントをストリーミング配信する場合、技術面の運用が消費者の信頼に直接影響するため、プロバイダはダウンタイムなしの可用性と完璧なパフォーマンスを絶対に確保する必要があります。

TelevisaUnivision が Google Cloud を選んだ理由

ISP の細分化が激しく、国境を越えた中継のボトルネックが目立つラテンアメリカの複雑なネットワーキングエコシステムに対応するには、標準的なベンダー関係以上のものが必要でした。TelevisaUnivision は、ネットワーク容量、インフラストラクチャの復元力、カスタム機能の開発に共同で取り組んでくれる戦略的パートナーを必要としていました。TelevisaUnivision が Google Cloud の Media CDN を選んだ理由は、Google Cloud のアーキテクチャと顧客重視の姿勢という 2 つの基本的な差別化要因でした。

プラットフォームアーキテクチャ

Media CDN は、送信元インフラストラクチャを保護しながら、ライブ配信のトラフィックの急増を吸収するために特別に構築された、グローバルに分散された復元力のあるインフラストラクチャを提供しました。このアーキテクチャがもたらした主なメリットは次のとおりです。

ISP 内のディープエッジキャッシング: メキシコ、中南米のローカル ISP ネットワーク内に深く埋め込まれた Media CDN のキャッシュノードにより、視聴者から 1 ネットワークホップ以内の場所に動画セグメントが配置されました。
ISP とのダイレクトピアリング: América Móvil や Telefônica などの主要な地域通信事業者とのダイレクトピアリング接続を確立することで、混雑した多国間の中継ルートを完全に回避するアーキテクチャが実現しました。
専用容量の予約: TelevisaUnivision は、リージョン内で専用のヘッドルームを割り当ててライブイベントの容量を予約しました。この方法により、ライブ配信のトラフィックが「ノイジーネイバー」のリスクから隔離され、ピーク時のトラフィック急増を無理なく吸収できました。
Valkey 9.0 によるミリ秒未満のセッション: ワールドカップ期間中の大規模なトラフィック急増に対処するため、TelevisaUnivision はセッションストアを Memorystore for Valkey 9.0 に移行し、エッジコンピューティング上のサーバーレスマイクロサービスとして稼働させました。このアーキテクチャにより、重要な認証と権限チェックの応答時間が 1 ミリ秒未満になり、手動で容量を予約しなくても、ピーク時の API トラフィックを自動スケーリングで処理できるようになりました。

カスタマーサクセスへのこだわり

TelevisaUnivision が Google Cloud を選んだのには、技術的な能力だけでなく、共同エンジニアリングモデルや運用面での緊密な連携といった理由もありました。

24 時間 365 日の共同ウォールーム: 104 試合すべてで、TelevisaUnivision のエンジニアと Google Cloud のスペシャリストが統合コマンドセンターで並んで作業しました。
サービスとしてのプロアクティブなモニタリング: Google Cloud の顧客信頼性エンジニアリングチームが、24 時間体制でプロアクティブなモニタリングと自動アラートを提供しました。
運用面の共同権限: 大会前に、両チームが合同で、広範なストレステストとフェイルオーバーのシミュレーションを実施しました。試合のライブ配信中は、統合されたテレメトリーにより、共同リーダーがトラフィックを動的にルーティングし、地域の ISP で輻輳が発生したときに CDN 構成を即座に調整することができました。

まとめ

2026 FIFA ワールドカップにおける TelevisaUnivision と Google Cloud の戦略的パートナーシップは、世界のスポーツ放送の新たな基準を確立しました。TelevisaUnivision は、39 日間にわたるトーナメントの実施期間中、共同インフラストラクチャが以下の成果を上げたと報告しています。

放送された試合の総数	104 試合をライブ配信
プラットフォームの可用性	プラットフォームの可用性 100%（ダウンタイム 0）
累積視聴回数	TelevisaUnivision と ViX で 6 億 7,500 万回視聴

TelevisaUnivision と Google Cloud は、ローカライズされたエッジ配信、ミリ秒未満のサーバーレスコンピューティング、運用における専任の共同エンジニアリングを統合することで、過去最高の世界的規模でライブストリーミングイベントを実施するための、実証済みのブループリントを確立しました。

- TelevisaUnivision、プロダクトおよびエンジニアリング担当シニアバイスプレジデント、Alexandro David Campos Vega 氏

- Google Cloud、ネットワーキング、プロダクト管理担当バイスプレジデント、Kevin Hutchins

GKE の ClusterNetworkPolicy: マイクロサービスの制御と自律性のバランスを取る

Mon, 24 Aug 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 8 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

マルチテナントの Kubernetes 環境におけるネットワークセキュリティの管理では、通常、2 つの異なるニーズのバランスを取ることが求められます。デベロッパーがマイクロサービス間で円滑な通信を確保したいと考える一方で、プラットフォームおよびセキュリティチームは、コンプライアンスの維持、ラテラルムーブメントの防止、そしてクラスタ全体のガードレールの確立を確実に行わなければなりません。

従来、これには標準の Kubernetes NetworkPolicy が主なツールとして使われてきました。標準の NetworkPolicy は、単一の名前空間を分離するには効果的ですが、そのスコープは個々の名前空間に厳密に限定されており、デベロッパーのセルフサービスを前提とした設計になっています。クラスタ管理者がグローバルなセキュリティ強化のために使用しようとすると、ポリシーの競合や運用上の課題が生じる可能性があります。

この問題に対処するため、Google は Kubernetes SIG-Policy ワーキンググループ（WG）が開発したオープンソース標準である ClusterNetworkPolicy（CNP）を Google Kubernetes Engine（GKE）に導入しました。大規模環境を想定して設計された CNP は、クラスタ全体のリソースです。これにより、管理者はネットワークセキュリティを一元管理できるようになり、グローバルセキュリティの担当者が、一貫性のあるバイパスできないポリシーを実装するための仕組みを提供します。

CNP の技術的な詳細、一般的なユースケース、ポリシーの例、利用開始方法について、以下をご覧ください。

ティアによるポリシーの構造化

ClusterNetworkPolicy のコア機能は、その階層的なティアシステムです。CNP は、フラットで競合するピアルールを同時に調整しようとするのではなく、決定論的なトップダウンの評価階層を確立します。

管理者ティア: 最も優先度の高いレベル。ここでのルールは、他のあらゆるポリシーよりも先に適用されます。
ネットワークポリシーティア: 標準の名前空間レベル。デベロッパーが個々のアプリケーションポリシーを管理します。
ベースラインティア: 最も優先順位が低く、他のどのポリシーも適用されない場合のクラスタのデフォルト動作を規定します。これは、名前空間スコープのポリシーを使用でオーバーライドできます。

このティア構造により、ネットワークセキュリティを組織の役割と整合させることができます。標準のロールベースアクセス制御（RBAC）を使用すると、管理者ティアを管理してコンプライアンス要件を適用できます。一方、プラットフォームチームはベースラインティアを使用して、クラスタ全体にデフォルトの「すべて拒否」ゼロトラスト体制を設定できます。同時に、デベロッパーはコアセキュリティ要件をオーバーライドすることなく、自身のアプリケーションに対して標準ネットワークポリシーを定義できます。

この決定論的なトップダウンの評価方法により、異なるチームのポリシー間の競合が解消されます。管理者ティアでは、明示的な Pass アクションが導入されています。これにより、セキュリティチームはグローバルルールに照らしてトラフィックを検査し、最終的な許可または拒否の決定をデベロッパーの名前空間ポリシーに委任できるため、中央での統制と分散管理の両立が容易になります。

一般的なネットワークセキュリティシナリオ

このティアアーキテクチャは、複雑なセキュリティ要件を一元化されたルールへと落とし込みます。ClusterNetworkPolicy が有効な解決策となる一般的なシナリオをいくつか紹介します。

機密性の高いワークロードの分離: 管理者ティアのグローバル拒否ルールを適用して、支払い処理やコンプライアンスデータに使用される名前空間など、特定の名前空間をクラスタの他の部分から分離できます。このアクションは、放っておくとこれらの環境をさらしてしまう恐れのある、制限の緩いデベロッパーポリシーをオーバーライドします。
コアサービスの保護: 内部運用に支障をきたすような構成を防ぐため、管理者は kube-dns などの重要なサービスに対して、管理者ティアのグローバル許可ルールを作成できます。これにより、名前空間ポリシーに構成ミスがあっても、これらのサービスへのアクセスを維持できます。
外部への下り（外向き）の管理: IP アドレス範囲のマッチングを利用することで、下り（外向き）トラフィックをクラスタレベルで制御できます。この機能を使用すると、企業イントラネットや外部 IP 範囲へのアクセスを明示的に制限または許可できるため、不正なデータの持ち出しに対する安全対策として機能します。

シナリオの例

一般的な企業の要件を考えてみましょう。すべての名前空間にわたるアプリケーションワークロードは、中央のプラットフォームインフラストラクチャ（共有認証サービスやテレメトリーサービスなど）へのアクセスが許可されている必要がありますが、その一方で、機密性の高い環境（制限付きの Vault 名前空間など）へのアクセスは厳格に禁止されます。その一方で、通常のマイクロサービス間のトラフィックは、デベロッパーが管理する名前空間スコープのポリシーに委ねられます。

ClusterNetworkPolicy を使えば、これを簡単に実現できます。プラットフォーム管理者は、管理者ティアのガードレールを次のように一元的に定義するだけです。

code_block: <ListValue: [StructValue([('code', 'apiVersion: policy.networking.k8s.io/v1alpha2\r\nkind: ClusterNetworkPolicy\r\nmetadata:\r\n name: platform-isolation-guardrail\r\nspec:\r\n tier: Admin\r\n priority: 10\r\n subject:\r\n # Target all application tenant namespaces, excluding system and core infrastructure\r\n namespaces:\r\n matchExpressions:\r\n - key: kubernetes.io/metadata.name\r\n operator: NotIn\r\n values: ["kube-system", "shared-services", "restricted-vault"]\r\n egress:\r\n # 1. Mandate access to central shared platform services\r\n - name: allow-shared-services\r\n action: Accept\r\n to:\r\n - namespaces:\r\n matchLabels:\r\n kubernetes.io/metadata.name: shared-services\r\n\r\n # 2. Enforce strict block on accessing the restricted vault namespace\r\n - name: block-restricted-vault\r\n action: Deny\r\n to:\r\n - namespaces:\r\n matchLabels:\r\n kubernetes.io/metadata.name: restricted-vault\r\n\r\n # 3. Explicitly delegate all remaining traffic to developer namespace policies\r\n - name: delegate-remaining-egress\r\n action: Pass\r\n to:\r\n - namespaces: {}\r\n - networks:\r\n - 0.0.0.0/0\r\n - ::/0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288e834d0>)])]>

オープンソース基盤の拡張

Google は、この機能を独自の拡張機能として構築するのではなく、Kubernetes コミュニティと協力して ClusterNetworkPolicy API（policy.networking.k8s.io）を設計し、名前空間スコープの NetworkPolicy API（networking.k8s.io）と明確に区別しました。さらに、Cilium コミュニティと緊密に連携して、API の実装を構築しました。

GKE はオープンソース標準に基づいて構築されているため、セキュリティ構成をさまざまな環境に移植することが可能です。ClusterNetworkPolicy API は、ティアの選択をネイティブにサポートしているため、明確で決定論的なポリシー評価が可能です。このアプローチにより、管理者は堅牢なセキュリティガードレールを適用しながら、開発チームが必要とする運用上の柔軟性を維持できます。

GKE の ClusterNetworkPolicy は、ワークロードのネットワークセキュリティを強化し、運用を名前空間スコープのルールから、クラスタ全体にわたる統合されたガバナンスに移行します。現在は、バージョン 1.36 以降でプレビューとして利用可能です。詳細と利用開始方法については、以下をご覧ください。

- グループプロダクトマネージャー、Srini Jasti

- ソフトウェアエンジニア、Blaz Zupan

GKE マネージド DRANET を使用した Autopilot クラスタ: GPU と TPU

Fri, 31 Jul 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 7 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）マネージド DRANET は、GPU と TPU の両方をサポートしています。この実装を使用するための構成には、標準クラスタ（ユーザーが完全に制御する）や Autopilot クラスタ（Google によって複雑な構成が自動的に行われる）など、いくつかあります。私自身、これまでその機能を検証してきましたが、このブログでは、Autopilot クラスタの設定について説明します。

Autopilot とマネージド DRANET

GKE Autopilot は、ノード、スケーリング、セキュリティ、その他の事前構成された設定を処理する、GKE のマネージドバージョンです。GKE マネージド DRANET を使用すると、ネットワーキングリソースをリクエストして Pod に割り当てることができます。たとえば、TPU およびリモートダイレクトメモリアクセス（RDMA）をサポートするネットワークインターフェースを割り当てられます。

設定フロー

GKE Autopilot クラスタをデプロイしてマネージド DRANET を有効にするには、Virtual Private Cloud（VPC）を作成する必要があります。その設定を見ていきましょう。

Autopilot クラスタをデプロイする。
アクセラレータタイプ（TPU または GPU）をサポートするカスタム ComputeClass を作成する。
GPU（RDMA）または非 GPU（TPU）の ResourceClaimTemplate を作成する。
ワークロードをデプロイし、ComputeClass と ResourceClaimTemplate を参照して、適切なネットワーキングを設定する。

次に、TPU と GPU の両方の構成について見ていきましょう。

次のように変数を構成します。

code_block: <ListValue: [StructValue([('code', 'export PROJECT_ID=$(gcloud config get project) #automatically sets your Project_ID\r\nexport REGION="REGION"\r\nexport CLUSTER_NAME="CLUSTER_NAME"\r\nexport NETWORK="NETWORK"\r\nexport SUBNETWORK="SUBNETWORK"\r\nexport RESERVATION_URL="RESERVATION_URL"\r\nexport HF_TOKEN="HUGGING_FACE_TOKEN"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288da1f90>)])]>

次のように置き換えます。

REGION: クラスタを作成するリージョン（us-east1 など）。クラスタは、予約またはリソースが存在するリージョンでのみ作成できます。
CLUSTER_NAME: クラスタの名前（例: dranet-cluster）。
NETWORK: VPC ネットワークの名前。
SUBNETWORK: VPC 内のサブネットの名前。
RESERVATION_URL: リソースの作成に使用する予約の URL。
HUGGING_FACE_TOKEN: モデルをダウンロードするための Hugging Face アクセストークン。

1. Autopilot クラスタをデプロイする

Autopilot クラスタをデプロイします。

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters create-auto $CLUSTER_NAME \\\r\n --project=$PROJECT_ID \\\r\n --region=$REGION \\\r\n --release-channel=rapid \\\r\n --network=$NETWORK \\\r\n --subnetwork=$SUBNETWORK'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288da1710>)])]>

2. カスタム ComputeClass を作成する

例: GPU B200 カスタム ComputeClass（マネージド DRANET をサポートし、予約を使用）

code_block: <ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: dranet-a4-computeclass\r\nspec:\r\n nodePoolAutoCreation:\r\n enabled: true\r\n nodePoolConfig:\r\n dra:\r\n networking:\r\n enabled: true\r\n priorities:\r\n - machineType: a4-highgpu-8g\r\n gpu:\r\n count: 8\r\n type: nvidia-b200\r\n acceleratorNetworkProfile: auto\r\n reservations:\r\n affinity: Specific\r\n specific:\r\n - name: ${RESERVATION_URL}\r\n project: ${PROJECT_ID}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288da1550>)])]>

次のように置き換えます。

${RESERVATION} : リソースの作成に使用する予約の URL に置き換えます。
${PROJECT_ID}: 使用しているプロジェクトの ID に置き換えます。

または、ターミナルで変数を設定し、次のコマンドを使用して作成時に変数を渡すこともできます:

envsubst < filename.yaml | kubectl apply -f -

例: TPU v6e カスタム ComputeClass（オンデマンド）の例

code_block: <ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: dra-gke-auto\r\nspec:\r\n nodePoolAutoCreation:\r\n enabled: true\r\n nodePoolConfig:\r\n dra:\r\n networking:\r\n enabled: true\r\n priorities:\r\n - tpu:\r\n type: tpu-v6e-slice\r\n count: 8\r\n topology: "2x4" \r\n acceleratorNetworkProfile: auto\r\n location:\r\n zones: \r\n - us-east5-b'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288da0790>)])]>

3. ResourceClaimTemplate を作成する

GPU の RDMA サポート deviceClassName: mrdma.google.com ResourceClaimTemplate の例:

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-mrdma\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-mrdma\r\n exactly:\r\n deviceClassName: mrdma.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288da1490>)])]>

TPU の非 RDMA deviceClassName: netdev.google.com ResourceClaimTemplate の例:

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-netdev\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-netdev\r\n exactly:\r\n deviceClassName: netdev.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288da3e50>)])]>

4. ワークロードをデプロイし、ComputeClass と ResourceClaim を参照する

クラスタに Secret を作成します。

code_block: <ListValue: [StructValue([('code', 'kubectl create secret generic hf-secret \\\r\n --from-literal=hf_token=${HF_TOKEN}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288da1a50>)])]>

GPU のデプロイの例:

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: gemma-4-31-deploy\r\nspec:\r\n replicas: 2\r\n selector:\r\n matchLabels:\r\n app: gemma4\r\n template:\r\n metadata:\r\n labels:\r\n app: gemma4\r\n ai.gke.io/model: gemma-4-31b\r\n ai.gke.io/inference-server: vllm\r\n spec:\r\n resourceClaims:\r\n - name: rdma-claim \r\n resourceClaimTemplateName: all-mrdma\r\n containers:\r\n - name: vllm-inference\r\n image: us-docker.pkg.dev/vertex-ai/vertex-vision-model-garden-dockers/pytorch-vllm-serve:gemma4\r\n resources:\r\n requests:\r\n cpu: "10"\r\n memory: "1000Gi"\r\n ephemeral-storage: "1Ti"\r\n nvidia.com/gpu: "8"\r\n limits:\r\n cpu: "10"\r\n memory: "1000Gi"\r\n ephemeral-storage: "1Ti"\r\n nvidia.com/gpu: "8"\r\n claims:\r\n - name: rdma-claim\r\n command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]\r\n args:\r\n - --model=$(MODEL_ID)\r\n - --tensor-parallel-size=8\r\n - --host=0.0.0.0\r\n - --port=8000\r\n - --max-model-len=131072\r\n - --max-num-seqs=16\r\n - --enable-chunked-prefill\r\n - --gpu-memory-utilization=0.90\r\n env:\r\n - name: MODEL_ID\r\n value: google/gemma-4-31B\r\n - name: HUGGING_FACE_HUB_TOKEN\r\n valueFrom:\r\n secretKeyRef:\r\n name: hf-secret\r\n key: hf_token\r\n volumeMounts:\r\n - mountPath: /dev/shm\r\n name: dshm\r\n startupProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n failureThreshold: 240\r\n periodSeconds: 10\r\n livenessProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n periodSeconds: 10\r\n readinessProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n periodSeconds: 5\r\n volumes:\r\n - name: dshm\r\n emptyDir:\r\n medium: Memory\r\n nodeSelector:\r\n cloud.google.com/compute-class: dranet-a4-computeclass'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288da2a50>)])]>

Deployment が ResourceClaimTemplate と ComputeClass をどのように参照しているかに注目してください。これが開始されると、スケールアップオペレーションがトリガーされます。GKE Autopilot は ComputeClass を読み取って、特定のノードタイプをプロビジョニングし、マネージド DRANET ネットワーキングを構成します。一方、リソースクレームはブリッジとして機能し、Pod をノード上のアクセラレータに直接バインドします。このプロセスは TPU でもまったく同じように機能します。

次のステップ

GKE マネージド DRANET と Autopilot について詳しくは、以下のリソースをご覧ください。

ハンズオンラボ: TPU を使用する GKE Autopilot クラスタ、GKE マネージド DRANET、Gemma 4
ドキュメント一式: DRANET
ドキュメント: AI Hypercomputer

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

IDC: 適切なネットワーキングアプローチがエージェント型 AI の基盤となる理由

Fri, 24 Jul 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 7 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回は、IDC の「2026 AI in Networking Special Report Survey」の結果についてお話を伺います。このレポートは、組織におけるエージェント型 AI の台頭を支えるネットワーキングインフラストラクチャに関する企業の懸念事項について、Google Cloud が調査を委託したものです。

多くの企業が AI の試験運用を急速に進めていますが、試験運用から本番環境への移行は依然として不均一な状況にあります。AI モデルが重要なことは変わりませんが、IDC の調査によると、試験運用から本番環境への移行におけるボトルネックはインフラストラクチャを中心としたものであり、コアネットワーキングに関する懸念が AI プロジェクトの遅延や中止の主な要因の一つとして浮上しています。IDC の「2026 AI in Networking Special Report Survey」の調査結果により、以下のことが明らかになりました。

32.6% の回答者がセキュリティ上の懸念を挙げている: AI ワークフローが分散され、自律性が高まるにつれて、一貫したセキュリティとガバナンスを適用することが難しくなっている。
26.8% の回答者が自動化の課題を挙げている: 手動操作や制御の断片化は、導入を遅らせ、AI 環境のスケーリングを困難にする可能性がある。
24.7% の回答者がスタッフの時間的制約や人材不足を挙げている: スキルや運用リソースの不足によって、組織が AI イニシアチブを本番環境へ移行する能力が制限される可能性がある。

エージェント型 AI では、アプリケーション、サービス、API、ツール、データソース間での分散的かつ動的なやり取りが増えるため、こうした懸念がさらに高まります。本番環境では、こうしたやり取りは、異なるエージェントフレームワーク、モデルプロバイダ、クラウド、オープンソースツール、SaaS API、内部アプリケーションにまたがることが多く、運用範囲とセキュリティ / ガバナンスの対象領域の両方が拡大します。

大規模な運用管理、セキュリティ、ガバナンスのためのネットワーキング

ネットワーキングは、エージェント間の連携を可能にする主要な要素であり、クラウド内およびクラウド間のネットワークレイヤとサービスレイヤの接続、エンドツーエンドのセキュリティ、一貫したガバナンスにおいて基礎的な役割を担います。エージェントシステムでは、ネットワーキングがよりサービス中心の厳密な制御領域へと拡張され、分散したサービス同士がどのように互いを識別し、通信し、データを安全に交換するかを管理します。一般的な AI ワークロードでも East-West トラフィックの需要は増加していますが、エージェント型 AI ではさらに複雑性が加わり、アプリケーションのワークフローにより近い場所で、より厳密なポリシー、可視性、制御を必要とする動的なやり取りを生み出します。

インフラストラクチャの観点から見ると、ネットワーキングは単なる接続機能ではありません。ネットワーキングは、インフラストラクチャプラットフォームのコントロールプレーンの一部として、ポリシーベースの制御を適用し、オブザーバビリティをサポートし、AI エージェントの活動全体で一貫したセキュリティとガバナンスを維持する役割を担います。エージェントやサービスが異なるランタイム、クラウド、デプロイモデル、運用ドメインにまたがる環境では、フレームワークレベルの制御だけでは不十分になるため、これは重要です。

このような点から、インフラストラクチャレベルのアプローチが鍵となります。これは、アプリケーションフレームワークやオーケストレーション環境に代わるものではありませんが、複雑なアーキテクチャ環境全体で、より広範かつ一貫したポリシーの実装を可能にします。エージェント型 AI がより自律的かつ分散化されるにつれ、オブザーバビリティの断片化やポリシー適用の不整合を軽減し、管理されていないシャドーエージェントの活動を抑制するために、インフラストラクチャの一部としてこれらの制御機能を組み込む必要性が高まります。クラウドインフラストラクチャの観点から見ると、このときにクラウドネットワークサービスが戦略的に重要になります。

プラットフォームベースのアプローチとベストオブブリード型アプローチとのバランスを取る

エージェント型 AI システムは、その基盤となる分散ワークフローの性質上、本質的に断片化されています。多くの企業はすでに、ビジネス要件、オープンソースコンポーネント、新たなプロトコル標準、新しいアーキテクチャパターンなど、急速に進化する状況に対応しています。このような状況において、ベストオブブリード型のポイントソリューションとプラットフォームベースのアプローチのどちらを選択するかは、イデオロギーではなく戦略に基づいて行うべきです。

特定の技術要件に対応するには、ベストオブブリードの機能が必要になる場合があります。しかし、分散したエージェント型 AI 環境全体にポイントソリューションを導入することで、ポリシーの不整合、運用の複雑化、ガバナンスのギャップを生み出す可能性もあります。IDC の調査でこのジレンマが示されています。IDC の「2026 AI in Networking Special Report Survey」でも、AI ワークロードに対するアプローチとして、プラットフォームとベストオブブリードのどちらを支持するかは意見が分かれました。回答者がプラットフォームを支持した主な理由は、セキュリティの強化（32.9%）、複雑さの軽減（27.7%）、導入の迅速化（24.2%）でした。

IDC では、バランスが重要だと考えています。プラットフォームは、AI 導入に向けた一貫した運用とポリシーの基盤を提供できますが、同時に、ベストオブブリードの機能をプラットフォームのツールセットの一部として組み込めるよう、モジュール性と拡張性も備えている必要があります。エージェント型 AI に適したプラットフォームは、オープンで柔軟性があり、進化できるものでなければなりません。また、サードパーティ製ツールやオープンソースツールとの統合をサポートし、必要なセキュリティ機能やオブザーバビリティ機能を組み込むことができ、アーキテクチャを全面的に作り直すことなく適応できる必要があります。

現在は、テクノロジーが根本から変わる転換期にあります。企業は、動的なエージェント型 AI システムを適切に管理しながら、AI の目標を確実に達成しなければなりません。このような環境において、ネットワーキングは AI インフラストラクチャの単なる接続要素にとどまらず、組織が運用管理を確立し、ポリシーを一貫して適用し、エージェントワークフロー全体を通じてエンドツーエンドの信頼を維持するための基盤となります。

エージェント型 AI システムが進化し続ける中で、それらから生じる要求にベストオブブリードのポイントソリューションだけで対応することは、もはや現実的ではありません。エージェント型 AI を大規模に運用する組織は、オープンで柔軟かつ拡張可能なインフラストラクチャプラットフォームによって支えられた、適切なネットワーキングアプローチを活用することで、一貫性と適応力があるセキュリティとガバナンスのフレームワークを実現する必要があります。

スポンサーからのメッセージ

エージェントアプリケーションの自律的で非決定論的な通信は、クラウドネイティブ時代のインフラストラクチャやガバナンスモデルでは対応できない課題をもたらします。エージェントネイティブの時代には、効果的なガバナンスとオブザーバビリティを確保しつつ、エージェントアプリケーションを本番環境で大規模に運用するためのインフラストラクチャ主導のアプローチが求められます。オープン標準に基づく拡張可能なプラットフォームは、現在から成熟期までに至るエージェント活用の取り組みを支えるうえで不可欠です。実用的なエージェントインフラストラクチャを実現するためのインフラストラクチャの要件とオープン標準については、こちらをご覧ください。

- IDC、シニアリサーチマネージャー、Taranvir Singh 氏

C4N の一般提供を開始: クラウドで最高レベルの vCPU あたりのネットワークとブロックストレージの I/O を x86 ワークロードで実現

Fri, 24 Jul 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 7 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

組織が、高スループットのデータベースやネットワーク / セキュリティアプライアンスから、リアルタイム分析や AI / ML 推論に至るまで、最新のワークロードをスケールすると、ネットワークとブロックストレージのパフォーマンスがすぐにボトルネックになる可能性があります。標準の仮想マシンでは、コンピューティングの効率と、これらのアプリケーションの大量のデータ転送の需要とのバランスを取るのが難しいことがよくあります。

Google Cloud Next ‘26 で、Google は、要求の厳しいエンタープライズアプリケーションの I/O ボトルネックを解消するために特別に構築された、ネットワークとブロックストレージ向けに最適化された Google Compute Engine インスタンスである C4N のプレビュー版を発表しました。そしてこのたび、その一般提供が開始されました。Google のカスタム設計の Titanium オフロードアーキテクチャ上に構築された C4N インスタンスは、ネットワークとストレージのタスクを専用のハードウェアにオフロードし、驚異的なパフォーマンスとコンピューティング効率を実現します。C4N は、最大 400 Gbps のネットワーク帯域幅と、業界トップクラスのスループットである 95 MPPS（百万パケット/秒）を誇ります。これは、他のハイパースケーラーの同等の Intel ベースのサービスと比較して、vCPU あたりのネットワーク帯域幅が約 33% 高く、パケット処理のパフォーマンスが 224% 高速である数値です。このパフォーマンスにより、C4N は、仮想アプライアンス（次世代ファイアウォール、仮想ルーター、ロードバランサ、DDoS 軽減など）、大規模なデータ分析、通信アプリケーション（5G UPF）、分散コンピューティング、CPU ベースの AI / ML ワークロードなど、大量のデータのネットワーク伝送が必要となるアプリケーションに最適です。

C4N は、Google の高パフォーマンスブロックストレージである Hyperdisk Extreme と組み合わせることで、Compute Engine の最高レベルのブロックストレージパフォーマンスを実現し、ストレージ帯域幅を最大 25 GiB/秒、IOPS を 100 万までスケールアップすることもできます。これは、同等の Intel ベースのサービスと比較して、ストレージ帯域幅が約 33% 高く、vCPU あたりの IOPS が 39% 多い数値です。そのため、大規模データベース、高パフォーマンスファイルシステム、インメモリデータベース、その他、高ブロックストレージパフォーマンスのメリットを享受できるワークロードに最適です。

C4N は、ネットワーキング、1 秒あたりのパケット数に制約があるアプリケーション、ストレージ向けに最適化されたアプリケーションで、予測可能な高スループットの I/O パフォーマンスを実現するように特別に設計されています。お客様は C4N を使用することで、特定のワークロード要件を満たすためにネットワーク、ストレージ、コンピューティングリソースをより正確にスケールできます。また、I/O 需要を満たすためだけにリソースを過剰にプロビジョニングする必要がなくなるため、TCO を大幅に削減できます。

C4N は、第 5 世代の Intel® Xeon® スケーラブルプロセッサ（コード名: Emerald Rapids）を備えています。

「Google Cloud による C4N の導入は、データ量がますます多くなっているワークロードに対処するうえで、インフラストラクチャのイノベーションと強力なシリコン基盤がいかに役立つかを示しています。Intel Xeon とカスタム Infrastructure Processing Unit（IPU）を備えた C4N は、要求の厳しいネットワーク最適化環境に必要なパフォーマンスと効率を実現します。」 – Intel、データセンタープロダクト、Intel フェロー、Srini Krishna 氏

新機能: C4N で大規模なデータレイヤをスケール

ネットワーク最適化 C4N インスタンスは、予測可能な高パフォーマンスの I/O を大規模に実現するように設計されています。C4N は、すべての VM のシェイプとサイズで一貫した帯域幅、パケット処理パフォーマンス（PPS）、IOPS スケーリングを提供することで、最も要求の厳しいデータワークロードを確実に実行できるようにします。これを実現するために、Google はホストレイヤとファブリックレイヤから冗長なトップオブラック（ToR）スイッチまで、インフラストラクチャのあらゆるレイヤに優れた復元力を組み込み、アプリケーションが継続的に高いパフォーマンスを発揮できるようにしています。

ネットワーク最適化 C4N は、汎用 C4 VM と比較して、ネットワークとブロックストレージの両方のベクトルでパフォーマンスが大幅に高くなっています。

次世代のネットワークパフォーマンス

優れた VM 間ネットワーク帯域幅: 最大 400 Gbps の VM 間ネットワーク帯域幅（標準の C4 と比較して vCPU あたりの帯域幅がほぼ 4 倍）を実現し、同じ VPC ネットワーク内でルーティングされる C4N インスタンス間で最大 50 Gbps の単一フロー帯域幅をサポートします。これにより、高スループットのシングルストリームアプリケーションとマルチストリームアプリケーションで、ノンブロッキングのデータ配信が可能になります。
VM からインターネットへのパフォーマンスの向上: インターネットの外向きネットワーク帯域幅が 8 倍、最大 200 Gbps に達します。また、インターネットの外向きパケット処理パフォーマンスが約 32 倍向上し、最大 48 MPPS までスケールされます。
小規模なシェイプ向けに最適化された I/O: 2～16 個の vCPU のシェイプ専用に最大 25～50 Gbps のネットワーク帯域幅を提供することで、クラウド料金を抑えます。コンピューティングを過剰にプロビジョニングする必要がなく、I/O に制約があるタスクを高速化するのに最適です。さらに、これらの小規模なシェイプでは、予測可能な安定状態のベースライン帯域幅制限が導入されているため、低コストで一貫したパフォーマンスが提供されます。
すぐに使える強化されたネットワーク構成: C4N の gVNIC インターフェースは、デフォルトで適用される標準の Tx / Rx キューが多くなっており、vCPU 数に応じて最大 64 個のキューまでスケールされます（C4 / C4D では 16 個のキュー）。
Google Cloud Storage の転送時間の短縮: C4N VM では、Cloud Storage から大量のデータを取得して保存するための帯域幅が最大 2 倍に増加しているため、分析、AI / ML、バックアップのワークロードのパフォーマンスが向上します。

さらに、このパフォーマンスはアドオンなしで、すぐに利用できます。最初から高いパフォーマンスを発揮するように設計された C4N は、Tier_1 ネットワーキングなどのプレミアムアドオンを購入または構成しなくても、最大限のパフォーマンスを実現します。

Hyperdisk による動的なストレージパフォーマンス

C4N インスタンスファミリーと Hyperdisk を組み合わせることで、コンピューティングインスタンスのサイズ設定とは関係なく、ストレージのパフォーマンス、レイテンシ、スループットを動的に調整し、アプリケーションで高いブロックストレージパフォーマンスを実現できます。C4N は、Hyperdisk Balanced、Balanced High Availability、Extreme、Throughput、ML ブロックストレージオプションを含む、Hyperdisk のポートフォリオ全体をサポートしています。

Hyperdisk Extreme: Hyperdisk Extreme と組み合わせた C4N は、最新のデータベースやエンタープライズ AI アプリケーションに必要な低レイテンシかつ高速のデータアクセスを実現します。ブロックストレージのスループットは最大 25 GiB/秒、IOPS は約 100 万で、C4 と比較してストレージパフォーマンスが 2 倍向上しています。また、C4N など、ネットワーク最適化マシンシリーズ限定で、最小の 2 vCPU サイズを含むすべてのマシンサイズで Hyperdisk Extreme を提供しています。
Hyperdisk Balanced: Compute Engine ポートフォリオの汎用ブロックストレージで最高レベルのスループットと IOPS を実現する、C4N の Hyperdisk Balanced は、ブロックストレージのスループットを最大 20 GiB/秒、IOPS を約 64 万までスケールアップできます。そのため、ストレージを多用するアプリケーションを大規模に実行する場合に、費用対効果の高いオプションとなります。

C4N のネットワークとストレージの最適化を組み合わせることで、実際のアプリケーションで大きな効果が得られます。

ウェブサービス: 一般的なウェブリクエストサイズ（100～300 KB）の場合、C4 と比較して 1 秒あたりの Nginx リクエスト数が最大 1.5 倍増加し、ネットワークに制約があるウェブアプリケーションの処理能力が大幅に向上します。
データベース: データが主にディスクに保存されている場合、同等の C4 VM と比較して、MySQL の秒間クエリ数（QPS）が最大 45% 増加します。

お客様の声

業界のリーダーはすでに、ワークロード向けに最適化されたインフラストラクチャが変革のエンジンとなっていることを証明しています。お客様がネットワーク最適化 C4N のパワーをどのように活用しているかをご紹介します。

「5G コアのワークロードは本質的にネットワーク負荷が高く、高スループットのパケット処理と決定論的なレイテンシが求められます。標準的なパブリッククラウドインスタンスでは、大規模環境でこれらを維持するのは容易ではありません。Google Cloud C4N コンピューティングファミリーを活用することで、Ericsson On-Demand の理想的なエンジンを見つけました。ネットワーク向けに最適化されたコンピューティングに重点を置いた C4N のアーキテクチャにより、当社の 5G Core-as-a-Service は、お客様が求めるキャリアグレードの信頼性を維持しながらも、最近達成した 1 Tbps など、前例のないスループットレベルを実現しています。C4N を使用することで、クラウドネイティブという枠を超えて、パブリッククラウド環境でネットワークネイティブなパフォーマンスを実現しています。」- Ericsson、Ericsson On-Demand 責任者、バイスプレジデント、Eric Parsons 氏

「Teradata の Autonomous Knowledge Platform は、本番環境グレードの AI、分析、データを一つの統合システムに統合し、自律型 AI が大規模に必要とするコンテキスト、ガバナンス、パフォーマンスのバックボーンを提供します。お客様は Teradata を活用し、パフォーマンスと費用管理が価値を直接左右する、ミッションクリティカルかつ I/O 集約型のワークロードを実行しています。

Google Cloud C4N インスタンスは、このような要求の厳しいワークロードに適しており、優れたコストパフォーマンスを実現するとともに、より効率的で最適化されたデプロイをサポートします。Google Cloud 上の C4N を活用することで、Teradata Cloud は、お客様が分析情報を得てから行動に移すまでの時間を短縮して、エンタープライズインテリジェンスを自信を持ってスケールし、データと AI への投資からより大きな成果を出せるよう支援します。」- Teradata、コアプラットフォーム、プロダクトマネジメント担当シニアディレクター、Kevin Dougherty 氏

「C4N VM の次世代のネットワークとストレージ帯域幅により、Google Cloud NetApp Volumes は、お客様の最も要求の厳しい AI ワークロードをサポートする新たなレベルのパフォーマンスを実現します。Google と NetApp は、Google Cloud NetApp Volumes による C4N VM ファミリーのサポートを拡張するために連携することで、お客様の実際の課題に対処するためのパートナーシップを深めています。両社は、アーキテクチャを簡素化し、パフォーマンスを最大化し、データを成果に変える、データ移動が不要な AI および分析ソリューションを提供しています。」- NetApp、クラウドストレージおよびサービス担当シニアバイスプレジデント兼ゼネラルマネージャー、Pravjit Tiwana 氏

「ほとんどの Compute Engine インスタンスは、1 つの高速ネットワークインターフェースを備えています。新しい C4N は、2 つの 200 GbE インターフェースで帯域幅の可能性を 2 倍にしています。このアーキテクチャの移行は大きなものです。つまり、両方のネットワークをストレージトラフィック専用にできるため、前世代と比べて、データ量が多いワークロードで利用可能な帯域幅が 2 倍になり、ストレージパフォーマンスが 2 倍になります。C4N は数週間前に発表されたばかりですが、すでに Sycomp のテスト環境でアクティブになっており、お客様が最新の GCP 機能を遅滞なく評価できるようになっています。Google Cloud が公開している C4N の Hyperdisk Balanced の最大パフォーマンスは 20 GiB/秒です。3 台のストレージサーバーを使用したテストでは、読み取りで 58.5 GiB/秒、書き込みで 58.6 GiB/秒を達成し、10 台の C4N ストレージサーバーを使用したテストでは、読み取りと書き込みで 195 GiB/秒を達成しました。これは、プラットフォーム固有の調整を一切行わずに理論上の上限の 97% に達したことになります。出発点としては優れた結果であり、微調整できる構成作業を通じて残りのギャップを埋める余地は十分にあります。C4N は高速であるだけでなく、Google Cloud 上のストレージワークロードの費用対効果のバランスを変えます。」- Sycomp、シニア HPC ソリューションアーキテクト、Scott Fadden 氏

「ClipperDB Technologies の使命は、大規模な Spark 分析の費用を削減し、パフォーマンスを向上させることです。Google Cloud の C4N インスタンスは、完全にネイティブなアーキテクチャに最適なコンピューティングエンジンです。C4N の vCPU あたりのネットワーク帯域幅の大幅な増加と、大容量メモリ構成、第 5 世代 Intel Xeon プロセッサにより、ClipperDB の正確なクラウドストアの並列プリフェッチおよびキャッシュ保存、同時データフローのネイティブバッチパイプライン、ストリーミングのコピーなし交換、クラウドストアのチェックポイントのフォールトトレランスが実現し、分離された Cloud Storage データレイクを使用して Spark ワークロードを大幅に高速化し、コストを削減しています。

結果は一目瞭然です。業界標準の TPC-DS ベンチマーク全体で、ClipperDB+C4N は、Spark との互換性を 100% 維持しながらも、クエリあたりのコストを 3 分の 1 以下に削減し、分析を最大 11 倍高速化しました。C4N と Clipper DB Accelerator を組み合わせることで、お客様が Spark ワークロードの費用対効果を大幅に改善できるようになることを期待しています。」- ClipperDB Technologies、CEO、John Busch 氏

C4N のシェイプと仕様の詳細

C4N インスタンスには、2～192 個の vCPU と最大 1.5 TB の DDR5 メモリを備えた 9 つの異なるサイズがあり、事前定義されたシェイプを高 CPU、標準、高メモリの構成で利用できます。

キャッシュ保存と高速かつ低レイテンシのローカルストレージのメリットを活かせるアプリケーション向けに、C4N VM インスタンスは最大 12 TiB の最新の Titanium SSD を備えています（近日提供予定。C4N ローカル SSD プレビュー版へのアクセスをリクエストするには、こちらからご登録ください）。マシンのリソースに直接アクセスする必要があるワークロード（ハイパーバイザ、コンテナプラットフォームなど）、ネストされた仮想化ではパフォーマンス要件を満たせないワークロード、パフォーマンスのモニタリングまたはライセンスに関する特別なニーズがあるワークロード向けに、C4N ベアメタルシェイプを導入します。これらのネイティブベアメタルシェイプのネットワークとストレージの I/O パフォーマンスは、まもなく仮想マシンのシェイプと同等になります。Google Cloud のお客様は、Compute Engine と Google Kubernetes Engine（GKE）で C4N インスタンスを使用できます。その他のサービスも近日中にサポートされる予定です。

名前	vCPU	メモリ（GB）	ローカルストレージ（GiB）	ネットワーク帯域幅		Hyperdisk Extreme の帯域幅（MiB/秒）	Hyperdisk Extreme の IOPS
名前	vCPU	メモリ（GB）	ローカルストレージ（GiB）	VM 間（Gbps）	VM からインターネット（Gbps）	Hyperdisk Extreme の帯域幅（MiB/秒）	Hyperdisk Extreme の IOPS
C4n-highcpu	2～192	4～384	該当なし	25～400	7～200	1.000～25,000	8 万～100 万
C4n-standard	2～192	7～720	該当なし	25～400	7～200	1.000～25,000	8 万～100 万
C4n-standard-lssd	4～192	15～720	375～12,000	30～400	7～200	1.000～25,000	10 万～100 万
C4n-highmem	2～192	15～1,488	該当なし	25～400	7～200	1.000～25,000	8 万～100 万
C4n-highmem-lssd	4～192	31～1,488	375～12,000	30～400	7～200	1.000～25,000	10 万～100 万

C4N マシンシリーズのパフォーマンスと仕様

ご利用方法

C4N は、高負荷の分散データベースのホスティング、ネットワーク仮想化アプライアンスの実行、AI 向けの大規模データパイプラインのオーケストレーションなどで、ビジネスに求められるスループット、スケール、効率性を実現するように設計されています。C4N インスタンスは現在、オンデマンド、Spot VM、予約を通じて一般提供されています。また、us-central1（アイオワ）、us-east1（サウスカロライナ）、us-east5（オハイオ）、us-west1（オレゴン）、europe-west2（ロンドン）で 1 年間または 3 年間の確約利用割引（CUD）または FlexCUD を購入することで、さらなるコスト削減を実現できます。詳細については、ネットワーク最適化マシンタイプをご覧ください。

イノベーションのための高パフォーマンスの基盤を築く準備はできていますか？Google Cloud コンソールにアクセスして、「ネットワーク最適化」マシンファミリーで C4N VM をスピンアップしましょう。利用可能なリージョンの最新情報については、リージョンとゾーンのページをご覧になるか、Google Cloud の営業担当者にお問い合わせください。

- シニアプロダクトマネージャー、Parinda Gandhi

- シニアプロダクトマネージャー、Sajal Agarwal

BGP ルートポリシー: お客様の需要に基づく上位 3 つのユースケース

Wed, 22 Jul 2026 01:30:00 +0000

※この投稿は米国時間 2026 年 7 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

1 年以上前に Cloud Router の BGP ルートポリシーの一般提供を開始した際、Google が目指したのは、ネットワーク管理者がネットワークパスの評価と伝播の方法を詳細にプログラムで制御できるようにすることでした。それ以来、Google はお客様がこの機能をどのように採用しているかを注意深く見守ってきました。そして、従来はサードパーティ製の仮想アプライアンスなしには実現が難しかった、極めて高度でレジリエンスの高いルーティングアーキテクチャを、多くのネットワークエンジニアリングチームが構築する姿を目にしてきました。

今年、Google は Cloud Router のポリシー名付きセットをリリースしました。ルーティング環境が複雑化するにつれて、これらのポリシー内の個々のプレフィックスやコミュニティの管理は煩雑になる可能性があります。

ポリシー名付きセットは、IPv4 / IPv6 プレフィックスまたは BGP コミュニティのリストを再利用可能な単一のエンティティにグループ化することで、この問題を解決します。構成が大幅に簡素化され、複数の Cloud Router にわたってルーティングルールのスケール、管理、更新が容易になります。

Common Expression Language（CEL）を基盤とする BGP ルートポリシーを使用すると、Cloud Router 内で BGP ルートをフィルタし、ルート属性を直接変更するための、きめ細かい順序付きルールを定義できます。

ポリシー名付きセットのリリースを記念して、過去 1 年間にお客様が BGP ルートポリシーを使用された方法のうち、特に効果的だった 3 つの事例と、ポリシー名付きセットを自分で作成する方法を記載したリソースをご紹介します。

1. 基盤: ルートフィルタリングとネットワーク保護

トラフィックパスを操作する前に、ネットワークの安定性を確保するには、ネットワークに出入りできるルートを厳密に制御する必要があります。多くのお客様が BGP ルートポリシーを幅広く活用し、ピアから学習した不要なルートをフィルタリングしたり、特定のサブネットプレフィックスが Virtual Private Cloud（VPC）からアドバタイズされないようにしたりしています。

BGP ルートポリシーはデフォルトでは「フェイルオープン」モデルで動作しますが、セキュリティを重視する多くの組織が、評価リストの最後の項目として「すべてドロップ」ポリシーを追加することで、「フェイルクローズ」環境を構築しています。これにより、受け入れられたネットワークルートを確実に把握し、ルーティングループを防ぎ、トラフィックが BGP ハイジャックされたり、意図せずにブラックホール化されたりしないようにできます。

詳細: ルートフィルタリング用の CEL 式を設定する方法の基本については、詳細ガイド「BGP ポリシーの概要」をご覧ください。

2. アクティブ/スタンバイアーキテクチャのトラフィックパスの制御

最適なトラフィック分散を実現するには、コストの最適化やアクティブ / スタンバイ構成の管理など、特定のパスにトラフィックを強制的に誘導しなければならない場面が多々あります。お客様は、オンプレミスのハードウェアに手を加えることなく、BGP ルートポリシーを使用して優先 BGP ルートに影響を与えてきました。

BGP Multi-Exit Discriminator（MED）属性を動的に変更することで、ネットワークチームは特定のピアを受信トラフィックの優先パスとして設定できるようになります。逆に、輻輳したリンクやバックアップリンクからトラフィックを誘導したい場合は、AS-PATH プリペンディングを使用します。これは、ルートの AS-PATH に 1 つ以上の値を追加して、より広範なネットワーク全体で優先順位を下げる方法です。

詳細: MED と AS-Path プレフィックスの管理に関する構成手順については、 BGP ポリシーを使用してトラフィックパスに影響を与えるをご覧ください。

3. BGP コミュニティで非対称ルーティングを解決する

過去 1 年間で最も要望が多く、かつ高度なユースケースの一つが、トラフィックの対称性の実現です。オンプレミスでステートフルファイアウォールや特定のネットワークアプライアンスを使用する企業の場合、戻りトラフィックは、発信元と同じアプライアンスを通過する必要があります。そうでない場合は、トラフィックがドロップされます。

お客様は、BGP ルートポリシーを使用して特定の標準 BGP コミュニティと照合することで、この問題を解決しています。オンプレミスで特定のコミュニティにルートをタグ付けすると、Cloud Router はインバウンドポリシーを介してこれらのタグを読み取り、それに応じて MED を操作してルートの優先度を調整できます。これにより、Google Cloud はオンプレミスネットワークのステートフルなトポロジを本質的に理解し、戻りトラフィックを対称的にルーティングできます。

詳細: BGP コミュニティタグを使用してステートフルトラフィックの対称性を設計する方法については、BGP コミュニティを使用してトラフィックの対称性を作成するをご覧ください。

使ってみる

動的ルーティングの制御はこれまで以上に簡単かつ堅牢になりました。BGP ルートポリシーを使用することで、ハイブリッドクラウド接続を最適化して保護する絶好の機会となります。

BGP ルートポリシーを本番環境にロールアウトする前に、ステージング環境でテストして CEL 式とルーティングロジックを確認することをおすすめします。技術ドキュメントについては、BGP ルートポリシーの概要をご覧ください。

- プロダクトマネージャー、Olivier Vautrin

- クラウドネットワーキング、テクニカルソリューションコンサルタント、Jonny Almaleh

Cloud Network Insights: クロスクラウドネットワークに対するエンドツーエンドのオブザーバビリティ

Fri, 03 Jul 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 6 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

昨今のデジタル環境では、ネットワークは単一のデータセンターや一つのクラウドプロバイダの範囲に制限されません。クロスクラウド戦略を採用し、Google Cloud ワークロードをオンプレミス環境、AWS や Azure などの他のクラウド、インターネットに接続されたさまざまなアプリケーションに接続させる企業が増えています。この柔軟性はイノベーションを促進する一方で、運用上の複雑さを大幅に増大させる可能性もあります。アプリケーションのパフォーマンスが低下した場合、原因はネットワーク、アプリケーション、それとも他のどこにあるのかという重要な疑問が生じます。

このたび、Cloud Network Insights の一般提供が開始されました。すぐに使用できる Google Cloud ネイティブのソリューションである Cloud Network Insights は、複雑なマルチクラウド環境とハイブリッド環境全体でネットワークとデジタルエクスペリエンスのパフォーマンスを包括的に可視化します。

アクティブなモニタリングで可視性のギャップを解消

Broadcom AppNeta とのパートナーシップにより提供される Cloud Network Insights は、オブザーバビリティを Google Cloud の枠を超えてグローバルなデプロイ全体に拡大します。アクティブな合成プローブの利用によりユーザートラフィックがない場合でもネットワークルートをモニタリングできるため、事後対応ではなく予防的なモニタリングを可能にします。

クラウド、オンプレミスのデータセンター、インターネットアプリケーション、ISP、ラストマイル接続など、パフォーマンス低下の原因がどこにあるとしても、Cloud Network Insights を使用すればボトルネックの正確な場所を特定できます。

Cloud Network Insights は Google Cloud Observability スイートに直接統合されるため、高度なネットワークインテリジェンスを既存のツールに組み込むことができます。Cloud Network Insights は、次の機能を提供します。

エンドツーエンドのネットワークパスの可視性: 送信元と宛先の間のネットワークパスをホップバイホップ方式で可視化します。直接管理していないネットワークにおけるラウンドトリップ時間（RTT）、パケットロス、ジッターなどの重要な指標をモニタリングします。
デジタルエクスペリエンスに関する分析情報: ネットワーク層を超えて、ウェブアプリケーションのデジタルエクスペリエンスをモニタリングします。DNS の解決時間、HTTP レスポンスコード、ブラウザのページ全体の読み込み時間を測定して、アプリケーションのパフォーマンス低下がネットワークによるものか、アプリケーション自体によるものかを特定します。
プロアクティブな検出とアラート: シンセティックテストを使用して、顧客に影響が及ぶ前にパフォーマンスの低下を特定します。アラームは Cloud Monitoring および Cloud Logging と統合されており、メール、Slack、PagerDuty 経由でアラートを送信できます。
SLA の検証: ISP やサービスプロバイダがパフォーマンスのコミットメントを満たしているかを検証するのに必要なデータをチームに提供します。
迅速な根本原因分析: ネットワークの問題、アプリケーションレベルの問題、ブラウザのパフォーマンスへの影響をすばやく区別できます。
統合モニタリング: Google Cloud 内から直接指標とログにアクセスし、Cloud Monitoring と Cloud Logging を活用してダッシュボードとアラートを提供します。Google Cloud のオープンなパートナーエコシステムと、指標とログに利用される OpenTelemetry プロトコルのサポートを利用して、OTel SDK とコレクタによる直接取り込みを可能にします。
エージェントワークロードのモニタリング: シンセティックテストを使用して、接続とネットワークパフォーマンスをモニタリングし、エージェントとツールへの接続を最適化します。

Google Cloud、AWS、Azure との間のネットワークパフォーマンスとマルチパスルートを 1 つのビューで確認

仕組み: アクティブな合成プロービング

Cloud Network Insights は、3 つの主要コンポーネントで構成されるアクティブな合成プローブ技術を使用します。

モニタリングポイント: モニタリングポイントと呼ばれる軽量のソフトウェアエージェントを、中央 VPC、リモートブランチ、オンプレミスデータセンターなどの重要なネットワークセグメントにデプロイします。モニタリングポイントはコンテナまたは仮想マシンとしてデプロイできます。
合成プローブ: モニタリングポイントは、合成トラフィック（ユーザーまたはアプリケーションをシミュレート）の小さなバーストを頻繁にターゲットの宛先に送信します。これにより、ネットワーク上にユーザーが存在しない場合でも、24 時間 365 日パフォーマンスをモニタリングできます。
データ同期: モニタリングポイントは、リアルタイムのパフォーマンステレメトリーを中央のバックエンドサービスに送信します。このデータは Google Cloud に同期され、指標は Cloud Monitoring にエクスポートされ、アラームとイベントは Cloud Logging に送信されます。

核となる機能

Cloud Network Insights は、インフラストラクチャの全体像を把握するために、主に次の 2 種類のモニタリングをサポートしています。

1. ネットワークパフォーマンスのモニタリング（レイヤ 3 と 4）

これにより、送信元と宛先の間のネットワークをホップバイホップ方式で可視化できます。

取得される指標: ラウンドトリップ時間（RTT）、パケットロス、ジッター、パスの変更。
シングルエンドモード: エージェントは、モニタリングポイントがインストールされていない外部ターゲット（URL、IP アドレス、API エンドポイントなど）をプローブします。
デュアルエンドモード: モニタリングポイントが別のモニタリングポイントをプローブします。これにより、一方向のレイテンシの正確な把握と非対称ルーティング（データが送信時と受信時で異なるパスを通る場合）の検出が可能になり、より豊富なデータが提供されます。

Google Cloud コンソールに表示されたネットワークパス指標

2. デジタルエクスペリエンスモニタリング（レイヤ 7）

デジタルエクスペリエンスモニタリングを使用すると、ウェブアプリケーションのエンドツーエンドのエクスペリエンスを追跡できます。ここでは、次のいずれかを選択できます。

ブラウザモード: 実際のブラウザエンジン（Selenium）を使用してウェブページ全体を読み込み、JavaScript を実行してコンテンツをレンダリングします。ページの読み込み時間を完全に測定し、実際のユーザーエクスペリエンスを検証します。
HTTP モード: 合成 HTTP/S リクエストを URL または API エンドポイントに送信します。これにより、サーバーの可用性、レスポンス時間、DNS / TLS パフォーマンスの軽量なチェックを行います。

インテリジェンスと自動化

Cloud Network Insights には、さまざまなモニタリング機能とトラブルシューティング機能も用意されています。

プロアクティブなアラーム: Cloud Network Insights は自動ベースライン設定を利用し、過去の指標データに基づいてパフォーマンスしきい値を動的に設定します。定義されたパラメータから指標が逸脱すると、システムは Google Cloud でイベントを即座にトリガーし、メール、Slack、PagerDuty を介してアラートをチームに直接ルーティングします。
モニタリングポリシー: カスタムタグに基づいてパスを動的に作成または削除するポリシーを定義することで、大規模な環境全体でモニタリング設定を自動化できます。たとえば、主要なウェブアプリケーションのパフォーマンスを特定の地理的地域から自動で追跡できます。
根本原因分析: Cloud Network Insights は、ISP やトランジットネットワークなど、従来は「監視対象外」だった領域まで可視性を拡張するため、速度低下が Google Cloud 内で発生しているのか、ISP レベルで発生しているのか、AWS や Azure などの別のクラウド環境内で発生しているのかを即座に特定できます。
AI による分析情報: Gemini Cloud Assist との統合により、自然言語を使用して、より広範なインフラストラクチャデータとともに Cloud Network Insights テレメトリーを調査できます。ダッシュボードを手動で切り替えるのではなく、Gemini に Cloud Network Insights の特定の指標と他の Google Cloud の指標を相互参照させることで、平均解決時間（MTTR）を短縮します。

お客様の声

Cloud Network Insights に対しては、クロスクラウド運用を簡素化したいと考えているお客様からすでに大きな関心が寄せられています。すでに Sabre や Pexip などの組織は、ハイブリッド環境の透明性を高める目的で Cloud Network Insights を活用しています。

「Sabre のように複雑かつハイスケールな環境では、完全な可視性は単なる贅沢品ではなく、運用のレジリエンスを確保するための不可欠な要件です。Cloud Network Insights を使用することで、プロアクティブな最適化をさらに推進できます。グローバルなクラウドフットプリント全体にわたってきめ細かいリアルタイムのテレメトリーを提供することで、従来のネットワークの『ブラックボックス』を解消し、旅行者のエクスペリエンスに影響を与える前にチームがボトルネックを解決することを可能にします。」- Sabre、クラウドおよびインフラストラクチャ担当バイスプレジデント、Alfredo Rodriguez 氏

「Cloud Network Insights は、企業のプライベートネットワークとパブリッククラウドとの間の『可視性のギャップ』を埋め、共通のお客様がパフォーマンスのボトルネックを数時間ではなく数秒単位で特定することを可能にします。」- Broadcom、CIO、Alan Davidson 氏

Cloud Network Insights でネットワークの健全性を向上させた Pexip

使ってみる

複雑なデジタルエコシステムに対応するために可視性を犠牲にする必要はありません。Cloud Network Insights は、詳細なネットワークパフォーマンス指標とデジタルエクスペリエンスモニタリングを組み合わせることで、マルチクラウド環境とハイブリッド環境のギャップを埋めます。Google Cloud Observability と Gemini Cloud Assist に直接統合されているため、チームはインテリジェントなアラート、堅牢な SLA 検証、迅速な根本原因分析を利用できます。Google は、お客様がクロスクラウドネットワークの全体像をより明確に把握できるよう今後も支援を続けていきます。

Google Cloud コンソールで今すぐご利用いただけます。詳しくは、以下の資料をご参照ください。

モニタリングポイントのデプロイとポリシーの構成について詳しくは、プロダクトドキュメントをご覧ください。
最新のリリースノートで新機能に関する最新情報を確認できます。
概要動画を見る
Google Cloud と Broadcom のパートナーシップについて詳しくは、以下をご覧ください。

- プロダクトマネージャー、Poonam Yadav

レポート: GKE Inference Gateway が AI 応答を最大 92% 高速化

Wed, 17 Jun 2026 01:30:00 +0000

※この投稿は米国時間 2026 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI が試験運用から大規模な本番環境へと移行するにつれ、インフラストラクチャの効率が決定的な差別化要因になります。インフラストラクチャを最大限に活用し、コストのかかるアクセラレータのアイドル時間を最小限に抑える方法の一つが、Google Kubernetes Engine（GKE）Inference Gateway の活用です。GKE Inference Gateway は、リアルタイムのモデルサーバー指標に基づいて、生成 AI ワークロードをインテリジェントにルーティングします。

従来の単純なラウンドロビン方式のロードバランシングでは、アクセラレータでのコストのかかる再計算が頻繁に発生し、ユーザーレイテンシが急増することがあります。これに対し、GKE Gateway のネイティブ拡張機能である GKE Inference Gateway は、接頭辞キャッシュやモデル対応ルーティングなどの高度な機能を活用します。すぐに処理できる状態にある適切なアクセラレータにリクエストを確実に送ることで、GKE は大規模言語モデル（LLM）のサービング方法を変革し、優れたハードウェア使用率と極めて高速な応答時間を実現します。

実際、独立したベンチマークレポートによると、GKE Inference Gateway は、次に優れたマネージド Kubernetes サービスと比べて、スループットが 15.7% 高く、待機時間が 92.8% 短く、トークン間レイテンシが 62.6% 低いという結果を示しています。このパフォーマンスにより、LLM ベースのアプリケーションは、低速で高コストなものから、高速で本番環境対応のものへと変わります。

このパフォーマンスは、GKE Inference Gateway を使用した Snap の経験とも一致しています。

「Snap では、大規模で高性能な推論を実現するため、本番環境の AI インフラストラクチャに llm-d を統合しています。接頭辞キャッシュ対応ルーティングを採用することで、最大 75～80% の接頭辞キャッシュヒット率を達成しました。llm-d がオープンソースであることにより、Envoy ベースのサービスメッシュとシームレスに統合できる点を高く評価しています。」- Snap Inc.、ソフトウェアエンジニアリング担当シニアマネージャー、Vinay Kola 氏

このブログ投稿では、GKE Inference Gateway の接頭辞キャッシュについて、例を交えながら詳しく見ていきます。また、ベンチマーク結果の詳細もご紹介します。それでは詳しく見ていきましょう。

低レイテンシ AI の秘訣: 接頭辞キャッシュ

接頭辞キャッシュは、長く繰り返し使用されるプロンプトの接頭辞に対応する KV キャッシュ（アクティベーション状態）を保存することで、LLM のパフォーマンスを最適化します。連続するユーザーリクエストで、同じシステム指示、コンテキスト、ドキュメントが共有される場合、モデルはそれらのトークンの再処理を完全にスキップできます。GKE Inference Gateway は、受信リクエストの接頭辞を読み取り、そのデータをすでにメモリに保持している特定の Pod と照合します。これにより、GPU や TPU にかかる「思考」のコストを排除し、負荷の高い推論ループをほぼ瞬時の回答へと変えることができます。

ユースケース 1: 検索拡張生成（RAG）を使用したドキュメントとコードベースの Q&A

大規模なエンタープライズリポジトリをクエリする場合、RAG を使用してドキュメントセット全体を静的接頭辞としてキャッシュに固定することで、レイテンシを追加することなく、LLM の回答を根拠に基づいたものにできます。

GKE Inference Gateway は、ユーザーから質問があるたびに、数千行に及ぶ API リファレンスや社内 Wiki を LLM に再度読み込ませるのではなく、その特定のコンテキストがすでに KV キャッシュに保持されている Pod にクエリをルーティングします。これにより、LLM はユーザーの短い動的な質問のみを計算すればよく、コストの高いドキュメントの再評価を完全に回避できます。

code_block: <ListValue: [StructValue([('code', '[静的接頭辞 - キャッシュに保持] あなたは技術ドキュメントを専門とする AI アシスタントです。以下は、このソフトウェアプラットフォームの完全な API ドキュメントです。このコンテキストを使用して、ユーザーの質問に正確に回答してください。ドキュメント内に回答が見つからない場合は、「提供されたコンテキストでは見つかりません」と答えてください。\r\n\u200b\r\n<documentation> [10,000 語以上の API リファレンスドキュメント、エンドポイント、エラーコードなど] </documentation>\r\n\u200b\r\n[動的接尾辞 - リクエストごとに変化] ユーザーの質問: Python SDK を使用して 429 レート制限エラーを処理するにはどうすればよいですか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288f98790>)])]>

ユースケース 2: マルチターンチャット

接頭辞キャッシュを使用すると、コンピューティングコストを累積的に増やすことなく、数千もの同時セッションにわたってカスタマーサービスのやり取りを維持できます。これは、固定のシステムペルソナと中核的なビジネスルールを LLM サーバーに直接キャッシュ保存することで実現できます。

エンタープライズチャットアーキテクチャでは、基本となるシステムプロンプトと参照テーブルが、数百万件の顧客インタラクション全体で完全に同一のまま維持されます。GKE Inference Gateway は、コンテキスト対応ルーティングを使用してこうしたマルチターンの会話を処理し、繰り返し発生するトークン処理をバイパスします。これにより、トラフィックのピーク時でも chatbot は極めて高い応答性を維持できます。

code_block: <ListValue: [StructValue([('code', '[静的接頭辞 - キャッシュに保持]\r\n- システムペルソナ: あなたは、ABC Banking Solutions の親切で共感力があり、コンプライアンスに準拠した仮想アシスタント「FinBot」です。次のルールを厳守してください。1. 具体的な投資助言は決して提供しないでください。2. ユーザーが当座預金口座について質問しているのか、貯蓄口座について質問しているのかを必ず確認してください。3. 回答は 3 文以内にしてください。4. ユーザーが怒っている場合は、人間のマネージャーにつなぐことを提案してください。\r\n\u200b\r\n2026 年 5 月時点の金利表は次のとおりです。\r\n- 貯蓄口座: 年利 4.2%\r\n- 当座預金口座: 年利 0.5%\r\n- CD（12 か月）: 年利 5.1%\r\n\u200b\r\n[動的接尾辞 - リクエストごとに変化] ユーザー: 10,000 ドルを 1 年間預けた場合、いくら受け取れるのか知りたいのですが。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288f9b590>)])]>

GKE は他のマネージド Kubernetes ソリューションを上回るパフォーマンスを発揮

こうしたアーキテクチャ上の利点を検証するため、Principled Technologies は先日、GKE Inference Gateway を搭載した GKE と、従来のラウンドロビン方式の HTTP ロードバランシングを使用する標準的なサードパーティのマネージド Kubernetes サービスを比較した、独立したベンチマークレポートを公開しました。

同一のハードウェア（8 基の NVIDIA A100 40GB GPU）を使用し、Llama 3.1 8B Instruct の共有接頭辞ワークロードでテストした結果、2 つの Kubernetes サービスの間に大きなパフォーマンス差があることが明らかになりました。GKE は単に優位性を示しただけでなく、次の 3 つの重要な指標すべてにおいて推論効率のあり方を大きく変えました。

スループットの向上: 1 秒あたりに処理されるトークン数が 15.7% 増加し、リクエスト処理能力を高めることができます。また、同じワークロードに必要なハードウェアを削減することも可能です。
最初のトークンまでの時間（TTFT）の大幅な短縮: 待機時間が 92.8% 短縮され、インタラクティブなシナリオで、応答が始まるまでの体感時間を大幅に短縮できます。
トークン間レイテンシ（ITL）の低減: 62.6% の低減により、最初のトークン以降のトークンストリーミングがよりスムーズかつ高速になります。

図 3: 共有接頭辞のユースケースにおける Llama 3.1-8B Instruct LLM での、GKE Inference Gateway を使用した GKE とサードパーティのマネージド Kubernetes サービスの平均レイテンシ（出力トークンあたりの正規化時間）。どちらのソリューションも同じハードウェアを使用しました。出典: Principled Technologies

	GKE	サードパーティのマネージド Kubernetes サービス	GKE の利点
平均出力トークンスループット	7,169.21 出力トークン/秒	6,042.05 出力トークン/秒	出力トークンスループットが 15.7% 向上
最初のトークンまでの平均時間（TTFT）	188.36 ミリ秒	2624.73 ミリ秒	TTFT が 92.8% 短縮
平均トークン間レイテンシ（ITL）	30.20 ミリ秒	81.03 ミリ秒	ITL が 62.6% 低減

図 4: GKE Inference Gateway を使用した GKE は、標準的な HTTP ロードバランサを使用するサードパーティのマネージド Kubernetes サービスと比較して、優れた AI 推論パフォーマンスを実現しました。

生成 AI 推論ワークロードを加速させる準備はできていますか？

リアルタイムのカスタマーサポートエージェント、動的なコーディングアシスタント、サブ秒単位の不正検出モデルなどの推論ワークロードをデプロイする場合、インフラストラクチャのレイテンシがユーザーエクスペリエンスを左右します。GKE Inference Gateway は、共有プロンプトの接頭辞がアクティブキャッシュにほぼ 100% ヒットするようにすることで、LLM を低速で高コストな推論エンジンから高速で資本効率に優れた本番環境対応の強力な基盤へと変えます。

GKE Inference Gateway が生成 AI ワークロードにもたらすパフォーマンス上の優位性を確認してみませんか？ベンチマークレポートの全文はこちらからご覧いただけます。また、詳細については、こちらの解説動画をご覧ください。

Principled Technologies のシニアパフォーマンスアーキテクトである Dan Sullivan 氏に感謝いたします。

- ソフトウェアエンジニア、Bob Tian

- アウトバウンドプロダクトマネージャー、Susan Wu

TPU、GKE マネージド DRANET、マルチクラスタ推論ゲートウェイを使用したテスト

Wed, 10 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 6 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

あるリージョンでワークロードに障害が発生しても、サービスを使用しなければならない場合、どうすればよいでしょう？これは、可用性や稼働時間に関してよく見られるケースです。Kubernetes エコシステムと動的リソース割り当て（DRA）や推論ゲートウェイなどの機能が最近強化されたことを受け、AI 推論ワークロードを使用した簡単なテストで、Google Cloud のこれらの機能を試してみることにしました。

このブログ投稿では、この設定について詳しくご説明します。また、こちらの Codelab（TPU、Cloud Storage FUSE、マネージド DRANET を使用してマルチクラスタ GKE Inference Gateway を構築する）で、詳細な構成をすぐに確認することもできます。

構成要素

このテストを構築するには、以下のプロダクト、機能、ツールを使用します。

Google Kubernetes Engine（GKE）マネージド DRANET: これは、Pod 間でリソースのリクエストや共有ができるマネージド機能です。GPU と TPU をサポートしています。このテストでは、2 つの異なるリージョンで TPU を使用し、マネージド DRANET を使用してネットワークを割り当てました。
マルチクラスタ GKE Inference Gateway: AI / ML 推論ワークロードを複数の GKE クラスタ間で負荷分散します。これはフェイルオーバーの状況で効果的です。今回のテストではこれを試します。このテストをサポートするタイプは、マルチクラスタクロスリージョン内部アプリケーションロードバランサ（gke-l7-cross-regional-internal-managed-mc）です。
Cloud Storage FUSE: データ、モデル、チェックポイント、ログを Cloud Storage に直接保存できるようにします。デプロイを高速化するために、オープンソースの Gemma モデルをこのストレージにダウンロードし、そこから取得するようにしました。
Virtual Private Cloud（VPC）: 分離された安全な通信を内部ロードバランサとコンピューティングノードに提供する、基盤となるグローバルネットワークです。
GKE フリート: フリートは、個別のリージョンクラスタを、統合された管理コントロールプレーン下にグループ化します。
TPU v6e: モデルのサービングに必要なハイパフォーマンスコンピューティングを提供する、Google のカスタム AI アクセラレータです。使われていた VM ファミリータイプは、2x2 スライスの ct6e-standard-4t でした。

設計パターンの例

目的は、異なるリージョンにある 2 つの GKE クラスタに LLM モデル（Gemma 3）をデプロイすることです。各クラスタは 4 つの TPU v6e チップを使用します。モデルは Cloud Storage に保存する必要があります。ワークロードは、マルチクラスタ対応の GKE Inference Gateway を使用して提供します。ユーザーに最も近いリージョンにトラフィックをルーティングする必要があります。また、いずれかのリージョンで障害が発生した場合は、もう一方のリージョンにフェイルオーバーする必要があります。

設定手順

2 つのリージョンでプロジェクトの TPU にアクセスするには、それらのリージョンで必要な割り当てを確保しておく必要があります。

最初の手順: 環境を設定する。

予約と同じゾーンに標準 VPC を作成し、ファイアウォールルールとサブネットを設定します。
プロキシ専用サブネットを作成します。これは、GKE Inference Gateway にアタッチした内部リージョンアプリケーションロードバランサで使用されます。
トラフィックとヘルスチェックを許可するファイアウォールルールを設定します。
ゲートウェイ用に両方のリージョンで静的内部 IP アドレスを予約します。
Cloud Storage FUSE バケットをプロビジョニングし、専用の IAM サービスアカウントを構成します。これを Kubernetes Workload Identity にバインドし、Pod がバケットを安全にマウントしてモデルの重みを直接読み取れるようにします。

次の手順: 標準の GKE クラスタとノードプールを作成する。

選択したリージョンに、構成済みの 2 つの独立した GKE クラスタをデプロイします。
クラスタの作成時に、Gateway API（--gateway-api=standard）と Cloud Storage FUSE CSI ドライバ（--addons GcsFuseCsiDriver）を有効にします。
両方のクラスタに、専用の TPU v6e ノードプール（ct6e-standard-4t）を作成します。
---accelerator-network-profile=auto フラグと --node-labels=cloud.google.com/gke-networking-dra-driver=true フラグを設定し、これらの TPU ノードプールでマネージド DRANET を有効にします。

次の手順: フリート登録を介してグローバルメッシュを確立する。

フリートの作成と登録の設定の手順に沿って、統合された GKE フリートに両方の GKE クラスタを登録します。
フリートでのマルチクラスタサービスディスカバリとマルチクラスタ Ingress を有効にします。
プライマリリージョンを構成ハブとして指定し、両リージョンにわたるルーティングルールのコントロールプレーンとして機能させます。

次の手順: AI ワークロードをデプロイする。

Kubernetes の一時ジョブを使用して、Gemma 3（gemma-3-27b-it）モデルの重みを Cloud Storage バケットに直接ダウンロードします。
割り当てモードが「All」に設定されたマネージド DRANET デバイスクラス（deviceClassName: netdev.google.com）を明示的にリクエストする、ResourceClaimTemplate を定義します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-netdev\r\n namespace: default\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-netdev\r\n exactly:\r\n deviceClassName: netdev.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288d7c090>)])]>

両リージョンの TPU ノードに推論サーバー（vLLM など）をデプロイします。Pod 仕様で 2x2 TPU トポロジのノードセレクタを使用し、4 つの TPU を正確にリクエストして、netdev クレームをマウントするようにします。これにより、Pod は標準のイーサネットとともに専用のアクセラレータネットワークを確実に利用できるようになります。

次の手順: マルチクラスタ推論ゲートウェイを構成します。

必要なカスタムリソース定義（CRD）をインストールし、Kubernetes が InferenceObjective などの特殊なルーティングオブジェクトを処理できるようにします。
KV キャッシュ使用量など、ハードウェアの使用状況を追跡する、AutoscalingMetric をデプロイします。
Helm を使用して、両方のリージョンから独立した AI デプロイを、単一の論理 InferencePool にグループ化します。
クロスリージョンゲートウェイとそれに関連付けられた HTTPRoute をデプロイし、受信するグローバルトラフィックを管理します。
ヘルスチェックとバックエンドポリシーをプールに適用し、ロードバランシングでカスタムハードウェア指標を使うようにします。

InferenceObjective を構成して、過負荷状態の TPU を回避し、可用性が最も高いリージョンにプロンプトをルーティングするよう、ゲートウェイに指示します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: gateway.networking.k8s.io/v1\r\nkind: Gateway\r\nmetadata:\r\n name: cross-region-gateway\r\n namespace: default\r\nspec:\r\n gatewayClassName: gke-l7-cross-regional-internal-managed-mc\r\n addresses:\r\n - type: networking.gke.io/named-address-with-region\r\n value: "regions/europe-west4/addresses/gemma-gateway-ip-europe-west4"\r\n - type: networking.gke.io/named-address-with-region\r\n value: "regions/us-east5/addresses/gemma-gateway-ip-us-east5"\r\n listeners:\r\n - name: http\r\n protocol: HTTP\r\n port: 80\r\n---\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: HTTPRoute\r\nmetadata:\r\n name: gemma-route\r\n namespace: default\r\nspec:\r\n parentRefs:\r\n - name: cross-region-gateway\r\n kind: Gateway\r\n rules:\r\n - backendRefs:\r\n - group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n port: 8000\r\n---\r\napiVersion: networking.gke.io/v1\r\nkind: HealthCheckPolicy\r\nmetadata:\r\n name: gemma-health-check\r\n namespace: default\r\nspec:\r\n targetRef:\r\n group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n default:\r\n config:\r\n type: HTTP\r\n httpHealthCheck:\r\n requestPath: /health\r\n port: 8000\r\n---\r\napiVersion: networking.gke.io/v1\r\nkind: GCPBackendPolicy\r\nmetadata:\r\n name: gemma-backend-policy\r\n namespace: default\r\nspec:\r\n targetRef:\r\n group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n default:\r\n timeoutSec: 100\r\n balancingMode: CUSTOM_METRICS\r\n trafficDuration: LONG\r\n customMetrics:\r\n - name: gke.named_metrics.tpu-cache\r\n dryRun: false\r\n maxUtilizationPercent: 60\r\n---\r\napiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: tpu-cache\r\n namespace: default\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: gemma-server\r\n endpoints:\r\n - port: 8000\r\n path: /metrics\r\n metrics:\r\n - name: vllm:kv_cache_usage_perc\r\n exportName: tpu-cache\r\n---\r\napiVersion: inference.networking.x-k8s.io/v1alpha2\r\nkind: InferenceObjective\r\nmetadata:\r\n name: gemma-objective\r\n namespace: default\r\nspec:\r\n priority: 10\r\n poolRef:\r\n name: gemma-pool\r\n group: "inference.networking.k8s.io"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7288d7e510>)])]>

フェイルオーバーのテスト

プライマリリージョンの障害をシミュレートして、高可用性アーキテクチャを検証します。プライマリのデプロイがオフラインになると、ゲートウェイは障害を自動的に検出し、その後のすべてのユーザーリクエストをアクティブなセカンダリクラスタへシームレスに再ルーティングします。これにより、トラフィックをドロップすることなく継続的な可用性が確保されます。

次のステップ

上述の機能に関するハンズオン Codelab と詳細については、以下をご覧ください。

ハンズオン Codelab: TPU、Cloud Storage FUSE、マネージド DRANET を使用してマルチクラスタ GKE Inference Gateway を構築する
ドキュメント一式: DRANET
ドキュメント: AI Hypercomputer

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

AI 時代に向けた Google のグローバルおよびデータセンターネットワークの進化

Tue, 02 Jun 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 5 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

Google のグローバルネットワークを構築してきた過去 25 年間、私たちはインターネットからストリーミング、そしてクラウドへと、主要なアーキテクチャの時代を歩んできました。現在、私たちは第 4 の時代、すなわち AI 時代の真っ只中にいます。AI 時代のアプリケーションは、これまでの時代の消費者向けアプリケーションや企業向けアプリケーションとは根本的に異なり、コンピューティングリソースはもちろんのこと、ネットワークに対しても、これまでにない厳しい要件を課します。

基本的な物理的課題として、電子（電力）を移動させるのは、光子（ファイバー経由のデータ）を移動させるよりもはるかに難しいという点があります。AI コンピューティングの需要は、個々の施設のスペースや電力容量を上回ることが頻繁にあるため、Google はデータセンターをサステナブルなエネルギー源の近く、あるいは地域の電力網にクリーンエネルギー源を導入する手段が整った場所に戦略的に配置しています。こうして、ネットワークを活用して AI ワークロードをキャンパス全体に分散させることで、単一サイトの電力制限を克服する大規模なプール型ハイパーコンピューティングリソースを構築します。

これを実現するために、Google はチップからシステム、プラットフォーム、アプリケーション、エージェント型エコシステムまで、あらゆるものを網羅するエンドツーエンドの垂直統合型 AI 技術スタックを構築しました。このスタックには、事前構築されたエージェントとアプリケーションのポートフォリオ、AI 対応アプリケーションの構築、スケーリング、ガバナンス、最適化を支援する Gemini Enterprise Agent Platform、世界クラスの AI モデル、統合データプラットフォームが含まれています。これらすべての中核をなすのが、Google の AI Hypercomputer です。これは、専用のハードウェアとオープンソフトウェアを組み合わせた統合インフラストラクチャであり、柔軟な使用オプションが用意されています。数十年にわたるイノベーションを通じて築き上げられた Google のネットワークは、AI Hypercomputer の不可欠なファブリックです。

このスタックを支えるネットワークは、AI ワークロードにおける帯域幅、スケール、パフォーマンスへの厳しいニーズを満たさなければなりません。これは、ネットワークをスケールアップおよびスケールアウトさせる必要があるキャンパス内だけでなく、広帯域な相互接続を含む広域ネットワーク（WAN）全体にも当てはまります。AI トレーニングデータをデータソースから AI コンピューティングリソースへと転送する必要があるためです。

これらの課題に対処するため、Google はネットワークインフラストラクチャの 3 つの主要な柱（AI Hypercomputer 内のファブリック、AI Hypercomputer 間のファブリック、グローバルネットワーク）を再構築しました。それぞれを詳しく見ていきましょう。

1. AI Hypercomputer 内のファブリック

基盤 AI モデルのパラメータの爆発的な増加を背景に、現在の AI モデルは大規模化しており、AI トレーニングにはコンピューティングとネットワークの両面で極めて高い負荷がかかっています。

そのため、必要なネットワーク帯域幅は指数関数的に増加し、遅延（テールレイテンシなど）には厳しい制限が課せられます。これは、パフォーマンスの変動に対する敏感さや同期バースト（ミリ秒レベルで発生する激しく統制されたトラフィックスパイク）といった、AI ワークロード特有のトラフィックパターンに対応するためです。さらに、大規模なトレーニングジョブは障害やパフォーマンスのストラグラー（停滞）に対して特有の脆弱性があるため、高い信頼性と予測可能なパフォーマンスを維持することが絶対に不可欠です。

最新の AI ワークロードに必要なスケール、低レイテンシ、高い予測可能性、そして極端なバーストからの保護に対応するため、Google は「キャンパスをコンピュータとして」という理念を採用し、ネットワークを 3 つの異なるドメインに分離しました。

Pod 内接続用のスケールアップドメイン
専用の East-West スケールアウトアクセラレータファブリック
North-South のコンピューティングおよびストレージアクセス用の Jupiter フロントエンドネットワーク

この分離されたアーキテクチャには 3 つの戦略的利点があります。ドメインを個別に進化させてイノベーションを加速できること、大規模なトレーニング帯域幅を備えたノンブロッキングのスケールアウトネットワークを提供できること、新しい ML アクセラレータと足並みを揃えてネットワークを共同設計し、優れたハードウェアサポートを実現できることです。

Google は最近、最新の AI 向けに特別に設計されたスケールアウトデータセンターファブリックである Virgo Network を発表しました。Virgo は、高基数スイッチとフラットな 2 レイヤのノンブロッキングトポロジを利用して膨大な二分割帯域幅を提供すると同時に、ネットワーク階層を減らすことでレイテンシを最小限に抑えています。各プレーンに独立した制御ドメインを備えたマルチプレーン設計により、ハードウェアレベルの復元力と障害分離を実現しています。さらに、Virgo は複数のデータセンターに拡張できるため、物理的な建物の制限がなくなり、AI コンピューティングの柔軟なスケーリングが可能になります。

ネットワークとアクセラレータの共同設計の有効性は、最近発表された第 8 世代 TPU で完璧に実証されています。このアーキテクチャでは、Virgo Network は 134,000 個の TPU 8t チップをリンクして、単一のファブリックで最大 47 ペタビット/秒のノンブロッキング二分割帯域幅を実現できます。Virgo Network は、前世代比で TPU 8t アクセラレータあたり最大 4 倍の帯域幅を提供します。また、TPU 8t の無負荷時のファブリックレイテンシは、前世代の TPU ネットワークと比較して 40% 低減されています。この構成では、Virgo Network がアクセラレータの未加工のトラフィックを管理し、Jupiter がグローバル WAN とストレージへの信頼性の高い高速アクセスを提供します。Pathways と JAX を統合すると、この AI Hypercomputer ネットワーキングエンジンにより、単一の論理クラスタで最大 100 万個の TPU 8t チップまでほぼ線形にスケールできます。

自律的な信頼性: ワークロードのグッドプットを保護する

復元力のあるメガスケールのファブリックを構築することは、課題の一部にすぎません。数十万個のチップからなるクラスタでは、ハードウェア障害は統計的に必ず発生します。インスタンスが 1 つでも停止すると、同期トレーニングジョブ全体が停止し、貴重なコンピューティングサイクルが無駄になります。そのため、効率的な障害箇所の特定が不可欠となります。

Google は、自律的な信頼性機能を備えた Virgo Network を設計し、大規模環境におけるワークロード効率（いわゆるグッドプット）を最大化しました。既存のストラグラー検出を拡張し、Virgo Network には自動ハング検出機能も新たに搭載されました。障害停止イベントが発生した瞬間に、専門のエージェントが直ちに障害箇所を特定して故障したインスタンスを隔離し、チェックポイントからのトレーニングジョブの復元を可能にします。これにより、手動による介入を最小限に抑えつつ、トレーニングのタイムラインを迅速に軌道に戻すことができます。詳しくは、こちらのデモをご覧ください。

これらの機能を補完するために、高解像度のサブミリ秒単位のテレメトリーも使用して、従来の 30 秒間隔のモニタリングでは通常見逃される、捉えにくいネットワークマイクロバーストを検知します。高解像度テレメトリーの進歩により、ネットワーク運用がより効率的になり、プロビジョニングが改善され、平均復旧時間が短縮されます。

2. AI Hypercomputer 間のファブリック

最新の AI ワークロードは指数関数的に増加しているため、WAN を介してそれらを複数のキャンパスにスケールして分散する必要があります。同時に、従来のネットワークは AI トラフィックの広帯域や極端なバースト性を想定して設計されておらず、深刻なパフォーマンス低下を招く恐れのあるマイクロバーストを検出できないことがよくあります。Google は、サイトをまたぐ AI デプロイにおける WAN のパフォーマンスを最適化するために、以下のような一連のイノベーションを開発しました。

水平スケーリングを可能にするマルチシャードのグローバルネットワーク。Google のグローバルネットワークは、2020 年から 2025 年にかけての 10 倍という WAN トラフィックの増大に対応しました。
可用性、レイテンシ、サービス品質（QoS）といった不可欠な特性に合わせた、ファブリックのチューニング。リアルタイムのマイクロバースト管理により、マルチテナントインフラストラクチャ全体で公平な帯域割り当てとインフラストラクチャの分離が確保されます。
各ネットワークシャードが独自のコントロールプレーン、データプレーン、管理プレーンで動作するマルチシャード分離構造。

リージョン分離と Protective Reroute を組み合わせることで、このアーキテクチャは障害の影響を最小限に抑え、ユーザーに影響する停止時間を短縮し、AI ワークロードに不可欠な 99.999% を超える信頼性を実現します。

高速で柔軟かつ費用対効果の高い相互接続を提供することも優先事項です。AI トレーニングは、オンプレミスやさまざまなクラウドに分散していることが多く、膨大なデータセットに依存しています。AI コンピューティングの費用は高額であるため、アイドル時間を最小限に抑えることが不可欠です。たとえば、100 Gbps のリンクから 3.2 Tbps の接続にアップグレードすると、1 ペタバイトのデータを転送する時間が 22.2 時間からわずか 0.7 時間に短縮されます。これは、データ待ちによる AI コンピューティングのアイドル時間が 97% 削減されることを意味します。Google の AI ネイティブの Cloud Interconnect は、AI ワークロードの広帯域と低レイテンシのニーズに合わせて専用設計されており、400 Gbps のリンクを備えた最適化されたデータパスが特徴です。このリンクは 3.2 Tbps 単位でスケールアウトし、ペタビット/秒の容量にまで達します。また、トラフィックの差別化に加えて、直接ファイバーピアリングやコロケーション施設などの柔軟な接続オプションも提供しています。AI ネイティブな Cloud Interconnect は、クロスクラウドでの AI トレーニングやサービングに不可欠な、信頼性の高いプライベート接続により、ペタビット規模のデータ転送をサポートします。

3. 推論の時代を支える、復元力のあるグローバルネットワーク

世界中のユーザーに AI 推論を提供するアプリケーションや、エージェント型の企業を支えるアプリケーションは、従来のウェブアプリよりもはるかに高い性能が要求されます。遠隔地にある高価な AI コンピューティングリソースを機動的に活用する必要性や、分散されたサービス間の依存関係、そしてトラフィックのバースト性といった要因により、グローバルフットプリントを持つ広帯域ネットワークに加え、SaaS プロバイダや ISP、ハイパースケーラーとのディープピアリングが求められます。応答性と「常時オン」の可用性を維持するために、アプリケーションには低レイテンシかつ高復元力のネットワークが求められます。

Google のグローバルネットワークは、接続性、スケール、復元力に優れており、AI 推論時代のニーズに応えるための最適な基盤を整えていますGoogle のネットワークは 1,000 万キロメートルを超える陸上および海底の光ファイバー網を網羅し、43 の Cloud リージョンを接続しているほか、200 以上のエッジロケーションを備えています。これらは、AI 推論を提供する上で欠かせない広大なフットプリントとなっています。Google のプレミアムティアネットワークは、一貫した高品質のグローバルユーザーエクスペリエンスに必要な低レイテンシと信頼性を提供します。トラフィックの出入り口を最適化することで、ネットワークはアプリケーションのパフォーマンスを大幅に向上させます。この「常時オン」のインフラストラクチャは、復元力をその中核に備えています。

共に築く未来

Google Cloud のお客様は、これらのネットワークイノベーションを環境に直接組み込むことができます。Google のネットワークは、AI ワークロードに不可欠となる大規模なスケール、キャパシティ、信頼性、そしてパフォーマンスを実現します。

AI 時代には、単なるコンピューティング能力だけでなく、スケーリングのための堅牢なネットワークファブリックが必要になります。シリコンからソフトウェアエコシステムまで、垂直統合された Google AI の技術スタックは、AI Hypercomputer を基盤としており、お客様の変革を加速し、AI をすべての人にとって役立つものにします。メガスケールのファブリック、推論を支える復元力の高いグローバルネットワーク、AI ネイティブな Cloud Interconnect などにより、Google はお客様の AI 活用への道のりを、効率的かつ信頼性の高いものにします。Google は、皆様とともにこの未来を築いていきたいと考えています。

- Google グローバルインフラストラクチャ担当バイスプレジデント、Bikash Koley

- Google Cloud、エンジニアリングフェロー、Arjun Singh

Next ’26: Google Cloud と Wiz が AI 時代のセキュリティを再定義

Mon, 11 May 2026 02:00:00 +0000

aside_block: <ListValue: [StructValue([('title', 'Next ’26 で本日発表した最新情報'), ('body', <wagtail.rich_text.RichText object at 0x7f7289223390>), ('btn_text', ''), ('href', ''), ('image', None)])]>

※この投稿は米国時間 2026 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

AI の時代には、セキュリティも新たな時代へと進む必要があります。組織は、AI の可能性を活用すると同時に、その悪用に対抗するという二重の課題に直面しています。Google Cloud は、こうした変化への適応と成長を支援します。

Google Cloud の最新調査によると、攻撃者は AI を利用して、攻撃の速度、規模、巧妙さを高めています。一方、M-Trends 2026 によると、脅威アクター間の連携強化により、初期アクセスからセカンダリ脅威アクターへの引き継ぎに要する時間は、過去 3 年間で 8 時間から 22 秒へと短縮されたことが示されています。

本日開催の Google Cloud Next では、ますます巧妙化する脅威への防御をマシンスピードで実現し、AI とマルチクラウド環境を保護しながら、大規模なクラウドワークロードを安全に運用するための Google Cloud の取り組みをご紹介します。

エージェント型防御の提供

チップからモデルまでをカバーする Google のフルスタック AI アプローチにより、優れた統合性とスピードを実現し、顧客保護を強化するための競争優位性をもたらします。さらに、グローバル規模の脅威モニタリングと Mandiant の最前線の専門家による分析情報に加え、Google DeepMind の最先端のインサイトや技術的ブレークスルーを活用し、お客様のプラットフォームのセキュリティ強化を支援します。

本日 Google は、Google Security Operations に、AI のスピードでの防御を支援する 3 つの新しいエージェントを発表しました。

現在プレビュー提供中の Threat Hunting エージェントは、従来の防御を回避する新たな攻撃パターンや、ステルス性の高い攻撃者の挙動を、チームが先回りして検出できるようにします。
現在プレビュー提供中の Detection Engineering エージェントは、カバレッジギャップを特定し、脅威シナリオに応じた新たな検出機能を生成します。手間のかかる作業を削減し、検出機能の作成を手作業中心の運用から自動化されたプロセスへと刷新します。
近日プレビュー提供予定の Third-Party Context エージェントは、サードパーティコンテンツから得られるコンテキストデータを活用し、ワークフローを強化します。

Threat Hunting エージェントで脅威ハンティングを開始

Triage and Investigation エージェントは、過去 1 年間で 500 万件以上のアラートを処理し、通常 30 分かかる手動分析を、Gemini の活用により 60 秒へ短縮しました。

「運用レジリエンスとサイバーセキュリティは、BBVA におけるお客様からの信頼を支える基盤です。Triage and Investigation エージェントのような高度な AI を導入することで、新たな形で運用を拡張できるようになります」と、BBVA のセキュリティテクノロジー責任者である Diego Martinez Blanco 氏は述べています。

また同氏は、「初期対応に伴う負荷の高い作業を担い、誤検知を取り除くことで、人による判断が必要な問題に優先的に対応できます。さらに、エージェントが判断根拠を明確に示すことで、チームは推奨事項を理解し、より複雑な調査にリソースを集中できるようになります」とも述べています。

Google Security Operations 向けリモート Google Cloud Model Context Protocol (MCP) サーバー対応が一般提供となり、独自のセキュリティエージェントを構築できるようになりました。さらに利便性を高めるため、プレビュー提供中の Google Security Operations のチャットインターフェースから、MCP サーバークライアントへ直接アクセスすることも可能です。

Google Cloud のエージェント型防御を活用し、インテリジェンス主導かつ AI による拡張を取り入れた最新のセキュリティ運用を進める組織は、高い ROI を実現できます。 Christopher Kissel 氏、IDC リサーチ担当バイスプレジデント

Threat Hunting エージェントが作成した検出結果レポート

セキュリティチームは、Google Security Operations のエージェント型自動化を活用することで、対応業務を自動化できます。さらに、チームの手動トリアージからエージェント型防御への移行を進めるため、Google Threat Intelligence にダークウェブインテリジェンスを導入しました。こちらは現在プレビュー提供中です。内部テストによると、この機能は 1 日あたり数百万件の外部イベントを 98% の精度で分析し、真に重要な脅威を優先的に特定できます。

「IDC は、AI を活用したコンテキストと自動化により、組織が平均検出時間と平均対応時間の大幅な短縮、誤検知の減少、アナリストの生産性向上など、定量的に把握できる運用成果を得ていることを明らかにしています。こうした運用上の改善は、業務中断期間の短縮、インシデント関連コストの削減、セキュリティポスチャーや意思決定に対する経営層の信頼感向上など、重要なビジネス成果につながります」と、IDC のリサーチ担当バイスプレジデントである Christopher Kissel 氏は述べています。「Google Cloud のエージェント型防御を活用し、インテリジェンス主導かつ AI による拡張を取り入れた最新のセキュリティ運用を進める組織は、高い ROI を実現できます。」

Google Security Operations の新しいパートナー連携ワークフロー

本日さらに、Google Security Operations 向けの充実した新しいパートナーインテグレーションも発表します。導入後すぐに利用できる高精度なセキュリティワークフローを提供する、Google Cloud Security 統合エコシステムの最新パートナーには、Darktrace、Gigamon、SAP などが含まれます。

あらゆるインフラストラクチャで、AI とクラウドアプリケーションを保護

AI とクラウドアプリケーションは、複数のプラットフォームやモデルにまたがって構築されています。これらをエンドツーエンドで保護するため、構築環境や方法にかかわらず、リスクをより簡単かつ迅速に軽減できるようにします。こうした保護機能は、アマゾンウェブサービス（AWS）、Google Cloud、Microsoft Azure、Oracle Cloud などの主要なクラウド環境に加え、OpenAI などの SaaS（Software as a Service）環境、さらにセルフホスト型の環境にも対応しています。

さらに、Wiz が Google Cloud の一員となったことで、お客様が構築し運用するアプリを保護する機能が拡大し、一段と強化されました。Wiz は、AI を迅速かつ安全な導入を可能にするとともに、AI 開発ライフサイクルの保護も強化します。

Wiz は、RSA Conference で AI-Application Protection Platform（AI-APP）を発表しました。AI アプリケーション向けに、高度な可視化、リスクポスチャーの把握、ランタイム分析が可能になります。また、Wiz Security Agents と Wiz Workflows も発表し、リスクや脅威をマシンスピードで特定し、迅速に対応できるようになりました。

Google は、あらゆるクラウド、プラットフォーム、AI 環境でお客様を保護する体制を一段と強化します。その一環として、Wiz は、Databricks に加えて、AWS Agentcore、Gemini Enterprise Agent Platform、Microsoft Azure Copilot Studio、Salesforce Agentforce などの新しいエージェントスタジオにも対応します。チームがどのプラットフォームを選んで構築しても、お客様は全体の可視性の確保が可能です。

Wiz は Google Cloud Apigee、Cloudflare AI Security for Apps、Vercel プラットフォームなど、クラウドの外側レイヤーとのインテグレーションによってセキュリティエコシステムとの連携を継続し、Wiz Security Graph の適用範囲をさらに拡張しています。また、Google は、Wiz Defend のセキュリティ検出機能と Google Security Operations および Mandiant Threat Defense との連携方法のアップデートにより、アナリストが脅威情報の自動転送をより容易に設定できるようになりました。

さらに、Wiz は、AI ネイティブな開発ライフサイクルを保護し、チームがより迅速かつ安全にイノベーションを進められる新機能も発表しました。

バイブコーディングアプリケーションを保護: Wiz は、5 月に一般提供予定の新しいインテグレーションを発表しました。これにより、Wiz のセキュリティスキャンを Lovable プラットフォーム内で直接実行できるようになります。Wiz が検出した脆弱性、シークレット、設定ミスは、Lovable の組み込みセキュリティビュー上に表示され、チームがすでに開発を進めている環境でそのまま確認することができます。
AI 生成コードの保護: Wiz は、AI 生成コードに含まれるリスクを、生成された瞬間に取り除きます。インライン AI セキュリティフックは、IDE やエージェントワークフローに直接統合され、プロンプトを評価するとともに、AI 生成出力を即座にスキャンします。これにより、コードがコミットされる前にセキュリティガードレールを組み込むことができます。
エージェントベースの修復: Wiz Skills は、コーディングエージェントや AI ネイティブ IDE に、コードからクラウドまでの包括的なコンテキストと、Wiz Security Graph による検証済みの攻撃対象領域に関する検出結果を提供します。この機能により、チームは、デベロッパー個人の IDE 上でも、バージョン管理システム内のリポジトリや pull リクエスト単位でも、エージェント主導の自動修復ワークフローを実行することができます。
シャドー AI の排除: Wiz の動的な AI-Bill of Materials（AI-BOM）は、環境全体に存在するすべての AI フレームワーク、モデル、IDE 拡張機能を自動的にインベントリ化します。これにより、スタック全体でどのツールがコード生成に使われているかを完全に可視化し、Gemini Code Assist や GitHub Copilot などの承認済みツールを管理すると同時に、未承認のシャドー AI プラグインを検出することができます。

Wiz の発表について詳しくは、こちらをご覧ください。

AI エージェントとエージェント型ウェブの保護

クラウドと AI ワークロードを保護するだけでなく、Google Cloud の安全性を重視して設計された基盤は、エージェント、不正対策、ウェブ領域に至るまで、AI 時代のスピードでイノベーションを加速します。

Gemini Enterprise Agent Platform によるエージェントの保護とガバナンスGoogle は本日、エージェントの構築、オーケストレーション、ガバナンス、最適化を支援する、Gemini Enterprise Agent Platform を発表しました。主な内容は次のとおりです。

Agent Identity により、アクセス管理と AI ガバナンスを大規模に実現できます。新機能では、エージェントごとに固有の ID を付与し、特定の認証フローや、ユーザーから範囲を限定して委任された権限のもとで、自律的に動作できるようになります。
Agent Gateway は、すべてのエージェント間接続およびエージェントとツール間の接続に対して、ポリシー適用を実現します。エンタープライズ向けエージェントトラフィックを管理するとともに、MCP や Agent2Agent（A2A）などのエージェントプロトコルに対応し、あらゆるエージェント間インタラクションを検査して保護します。
モデルとエージェントのインタラクションを保護するランタイム保護機能 Model Armor は、Agent Gateway、Agent Runtime、Langchain との統合をプレビュー提供します。Firebase との統合は一般提供となります。デベロッパーはコードを変更することなく、エージェントのトラフィックやインタラクションに対して、インラインでのポリシー適用と無害化処理を行うことができます。これらのインテグレーションにより、プロンプトインジェクション、ツールポイズニング、センシティブデータ漏洩などのランタイムリスクに対する Model Armor の保護範囲が、Google Cloud の各種サービスと AI 製品群全体に広がります。

Google Cloud Fraud Defense と Chrome Enterprise でエージェント型ウェブを保護本日、Google は reCAPTCHA をさらに進化させる新サービスとして、Google Cloud Fraud Defense をリリースしました。本サービスは一般提供されています。この包括的なプラットフォームは、ボット、人間、エージェントが正当な利用主体であり、適切な権限を持っているかどうかを見極められるよう設計されています。さらに、Fraud Defense は Google のエコシステム保護と同等のスケールおよびシグナルを活用し、人間ユーザーと AI エージェント向けの新機能をまもなくプレビュー提供します。これにより、アカウント作成やログインから、支払いやチェックアウトに至るまで、デジタルコマースジャーニー全体の安全性を強化します。

AI の安全性を確保するという Google の取り組みは、AI とのインタラクションに不可欠なエンドポイントであるブラウザにも広がっています。Chrome Enterprise は、企業データを守りながら AI を安全に活用するために必要な可視性とコントロールを提供し、AI 時代に向けた包括的なデータ保護を実現します。

現在プレビュー提供中の AI 拡張機能向け脅威検出機能は、高度な拡張機能テレメトリーを可視化し、セキュリティチームが AI エージェントの異常な挙動を検出し、迅速に対応できるようにします。
まもなく一般提供される新しいシャドー AI レポート機能は、従業員による未承認のウェブベース AI や SaaS アプリケーションの利用を検知することで、シャドー AI の利用実態を可視化できます。

Trusted Cloud の新機能

Google は、お客様の環境を保護するため、クラウドプラットフォーム全体で新たなセキュリティコントロールの提供を続けるとともに、ID、データ、ネットワーク領域にわたる機能強化を進めています。今回は、以下のアップデートをご紹介します。

最新の IAM による権限管理の簡素化最小権限を迅速かつシンプルに実現するため、事前定義ロールのカタログを簡素化し、管理者、編集者、閲覧者などの使いやすいロールに整理しました。あわせて、IAM role picker や機密性の高い操作に対する再認証機能なども提供します。

データセキュリティクラウドプラットフォームのデータセキュリティポートフォリオ向けに、最もセンシティブなデータを保護し、AI による変革を加速する複数の新機能を提供します。

Confidential Computing: NVIDIA とのパートナーシップにより、Google は本日、Confidential Computing の G4 VM 向けサポートを発表しました。Google Compute Engine（GCE）の Confidential G4 VM は、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、グローバルでプレビュー提供されます。これにより、機密性の高いさまざまな AI ワークロードにおいて、機密性と完全性を強化します。さらに、Intel とのパートナーシップのもと、Google は C4 Confidential VMs のプレビュー提供も開始します。第 6 世代 Intel Xeon プロセッサに Intel TDX を採用し、業界をリードするコンピューティング密度とパフォーマンスを実現するとともに、さまざまな AI および分析ワークロードを保護します。
Cloud Key Management Services（KMS）: 新たに Confidential External Key Manager（cEKM）をプレビュー提供します。任意のリージョンで外部鍵をホストして保護しながら、機密環境内で検証可能な統制を維持できる柔軟な運用が可能になります。
ポスト量子暗号（PQC）: 新たに KMS Quantum Safe Key Imports をプレビュー提供します。これにより、耐量子アルゴリズムを用いた、お客様独自の鍵を持ち込めるようになります。
Secret Manager: パスワード漏洩防止とプロンプトインジェクションのリスク緩和に向け、Secret Manager と Agent Development Kit のネイティブ統合を一般提供します。

ネットワークセキュリティGoogle Cloud のクロスクラウドネットワークセキュリティ製品群に、複数の新機能を追加します。

Cloud NGFW: 巧みに検知を回避するゼロデイ脅威への防御強化に向け、Cloud NGFWの高度なマルウェアサンドボックスを、今年後半にプレビュー提供します。この機能は、Palo Alto Networks Advanced Wildfire を基盤としており、70,000 社を超える Palo Alto Networks の顧客から得られたデータを基にトレーニングし、既知か未知を問わずマルウェアの 99% を阻止します。
Cloud Armor: Thales Imperva を活用した新しい Cloud Armor マネージドルールをプレビュー提供します。レイヤ 7 のアプリケーション攻撃やゼロデイ CVE（React2Shell など）を検出できます。

SCC で Google Cloud のセキュリティを強化Google Cloud ネイティブのセキュリティソリューションである Security Command Center（SCC）は、Google Cloud 上の従来のアプリケーションと AI アプリケーションの両方を保護するために、クラウドセキュリティのベースラインを確立します。

AI エージェント、モデル、MCP サーバーは、継続的な検出と包括的なリスク分析により、脅威、脆弱性、設定ミスを特定することで保護されます。
SCC は、Google Cloud ワークロードのシャドー AI を把握するために、ランタイムの詳細な可視化を強化します。近日プレビュー提供予定の SCC では、エージェント、Cloud Run または GKE 上でホストされる MCP サーバー、GKE 上で稼働する推論エンドポイントなど、非管理下のエージェント型ワークロードを自動検出し、SCC 上でポスチャー検出結果として表示されます。
強化された Security Command Center Standard ティアは、データセキュリティポスチャー管理、コンプライアンス管理、脆弱性管理、リスク分析を備えています。これにより、Google Cloud のすべてのお客様は追加費用なしで、導入初日から強力なセキュリティ、コンプライアンス、リスク対応体制を確立できます。

次のステップ

Google をセキュリティチームの一員に迎えることで、インテリジェンス主導の AI ネイティブな防御力、安全性を重視して設計されたオープンクラウドの柔軟性、そして自社チームの延長として頼れる、業界屈指の現場経験を持つエキスパートを得られます。

こうした新たなイノベーションと、これから先を守る方法については、セキュリティスポットライトをご覧ください。また、Next ’26 の発表内容についてさらに詳しく知るには、ライブ配信またはオンデマンドで視聴できる多数のセキュリティ関連ブレイクアウトセッションもぜひご覧ください。

- Francis deSouza、Google Cloud COO 兼セキュリティプロダクト担当プレジデント

エージェント型エンタープライズのためのクロスクラウドインフラストラクチャのイノベーション

Fri, 08 May 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

エージェント型 AI の時代が人間の速度から機械の速度へと運用を加速させていますが、それと同時に、以前のテクノロジーインフラストラクチャに深刻なストレスを与えています。数千もの内部メッセージと複雑なクエリを生成するエージェントが、しかもさらに多くのエージェントを生み出すという新たな現実は、基盤となるシステムを限界に追い込んでいるのです。この状況の中、従来のネットワークやデータベースでは瞬く間に手に負えなくなり、新たなセキュリティ脆弱性が顕在化する可能性があります。

エージェントの時代に AI の可能性を最大限に引き出すには、安全で適応性の高い基盤が必要です。Google ではこれを、エージェント型エンタープライズ向けクロスクラウドインフラストラクチャと呼んでいます。Google は Google Cloud Next ‘26 で、このインフラストラクチャの 4 つの分野における一連の新しいイノベーションを発表します。

最新情報:

Fluid Compute: Google Compute Engine サービスと Kubernetes サービスの連携により、新しいコンピューティング機能とオーケストレーション機能が追加されます。これらの機能は、費用対効果と速度に優れた AI エージェントとエンタープライズワークロードを実現するものです。
安全なクロスクラウド接続: Agent Gateway、Cloud Armor などのツールで、AI エージェント向けの安全で管理されたネットワーキング基盤を簡素化します。この基盤には、クラウド間のエージェントトラフィックのオブザーバビリティも組み込まれています。
統合データレイヤ: スマートストレージ、Knowledge Catalog などのイノベーションで、受動的なデータアーカイブを動的な推論エンジンへと変換します。この推論エンジンが、実行に必要となるコンテキストを AI エージェントに渡します。
デジタル主権: Confidential External Key Management と、Google Distributed Cloud の新機能により、データの保存場所を問わずに Google の最先端のモデルと AI イネーブラーを利用できるようになります。

これら 4 つの分野それぞれの最新ニュースを詳しくご紹介します。

Fluid Compute

エージェントワークロードは動的であり、予測することはできません。このことは、従来のエンタープライズアプリケーションにも AI エージェント自体にも影響を与えます。そこで、Fluid Compute を実現するために、Google Compute Engine サービスと Google Kubernetes サービスが連携して動的にワークロードに適応し、リアルタイムで重みをシフトします。これにより、すべてのお客様にとって、費用対効果と速度に優れた AI エージェントとエンタープライズ向け運用ワークロードの実現が可能になります。

AI Hypercomputer が大規模な AI モデルトレーニング向けの素の処理能力を提供する一方で、Fluid Compute によって運用ワークロードとエージェントのニーズに対応します。エージェントが推論と強化学習へと移行する中、CPU は中心的な役割を取り戻しつつあります。CPU は、エージェントワークフローに必要な「分岐」ロジック、複雑な制御フロー、安全なコード実行サンドボックス（エージェントオーケストレーション、RL、SLM 推論、RAG 向けのサンドボックスなど）において優れた能力を発揮するためです。さらに、CPU はエージェントを安全に実行するために重要となるエージェントの隔離を可能にし、トレーニングで使用される GPU と TPU の並列処理能力を補完します。

Google は、従来のワークロードと AI エージェントを安全かつ大規模に実行できるようにするための新しい CPU ファミリー、GKE 機能、Hyperdisk ブロックストレージ機能を導入しています。

Google C4N シリーズ: このシリーズの VM は、エージェント型 AI の需要によってエンタープライズワークロードの速度が低下しないように、1 秒あたり最大 9,500 万パケットを処理します。これは、他の主要なハイパースケーラーと比べて最大 40% 高速なパフォーマンスです。これにより、セキュリティアプライアンス、ストリーミングメディア、オープンソースデータベースなどの要求の厳しいワークロードで、より小さいインスタンスサイズを使用するとしても、I/O ボトルネックが解消されます。
Hyperdisk Extreme を使用した Google M4N シリーズ: M4N は、エージェント、分析、ミッションクリティカルなデータベースからの膨大なデータ I/O の処理のニーズに対処するために、データパイプラインのボトルネックを解消してオーバープロビジョニングの必要をなくし、業界トップクラスのコアあたりの IOPS とスループットを実現しています。vCPU あたり 26.57 GB の RAM を提供する M4N を使用すれば、ミッションクリティカルなワークロードをより少ないコアでスケールして、優れた費用対効果を実現できます。たとえば、Hyperdisk Extreme を使用した M4N は、主要なハイパースケールクラウドと比較して、Oracle ワークロードの総所有コストを 20% 以上削減します。
GKE Agent Sandbox: このソリューションは、信頼できる gVisor でエージェントを隔離して保護し、クラスタごとに 1 秒あたり最大 300 個のサンドボックスを起動して需要の急増に対応します。GKE Agent Sandbox は、主要なハイパースケールクラウドの間で唯一利用可能なマネージドサンドボックステクノロジーを基盤としています。GKE Agent Sandbox で Google Axion N4A を使用して AI エージェントを実行する場合、競合他社よりも最大 30% 優れたコストパフォーマンスを実現します。

「Wayfair の AI 戦略は、Google Cloud での長年にわたる体系的なインフラストラクチャモダナイゼーションに基づいて構築されています。この戦略には、コアの e コマースエンジンとデータベースをレガシーシステムから移行すること、モノリシックなサービスをクラウドネイティブアーキテクチャに分解すること、データと分析プラットフォームを統合することが含まれています。Gemini Enterprise Agent Platform という基盤があるからこそ、他のすべてが可能になります。現在、カタログの拡充から、お客様が自分にぴったりの家を建てられるよう生成 AI が支援するショッピングエクスペリエンスまで、あらゆるものを Gemini Enterprise Agent Platform によって強化しています。また、私たちはこの同じ基盤を頼りに、AI が単に支援するだけでなく、あらゆる顧客タッチポイントとビジネス全体で積極的に発見、パーソナライズ、コマースを推進するエージェントとなる時代に向けて準備を整えています。」- Wayfair、最高技術責任者、Fiona Tan 氏

最新のコンピューティングイノベーションについては、こちらのブログ記事をご覧ください。

安全なクロスクラウド接続

エージェント型 AI は、予測可能な人間のリクエストを自律的な「推論ループ」に置き換えます。このループでは、エージェントが他のエージェントを呼び出し、そのエージェントが LLM を呼び出すため、コンピューティングとマシン間のトラフィックが急増することになります。こうしたエージェント型へのシフトは、ネットワークの予測可能性と人間以外の ID のセキュリティに関して他には見られない課題をもたらします。エージェント型 AI 向けに最適化されたクロスクラウドネットワークは、さまざまな環境間でデータを移動して、可視性とセキュリティによって従業員、顧客、エージェントをつなげます。クロスクラウドネットワークの新機能は次のとおりです。

Agent Gateway: Gemini Enterprise Agent Platform の「航空管制官」として、企業のエージェントトラフィックを管理およびオーケストレートします。MCP や A2A などのエージェントプロトコルをネイティブに理解し、すべてのエージェントのやり取りを検査して管理します。Google とサードパーティの ID および AI の安全性に関するサービスと連携して、アクセスの検証、攻撃のブロック、機密データの保護を目的とした詳細な検査を可能にし、コアビジネス全体でコンプライアンスを維持します。
Cloud Network Insights: ハイブリッドクラウドとマルチクラウドのインフラストラクチャ全体にわたる幅広い可視性を提供し、トラブルシューティングとネットワーク解決を迅速化します。Google Cloud、AWS、Azure、データセンター、インターネットアプリケーション、エージェントワークロード全体で、エージェント、ネットワーク、ウェブのエンドツーエンドのパフォーマンスを継続的にモニタリングします。Cloud Network Insights は、合成トラフィック分析を使用して、ホップごとのネットワークパスを可視化し、パフォーマンス低下の原因を特定できるよう支援します。また、オペレーションの自律性を高めるために、Cloud Network Insights には Gemini Cloud Assist の AI を活用した分析情報が結合されます。
強化された Cloud Next Generation Firewall（NGFW）と Cloud Armor: AI が生成するポリモーフィックマルウェアやゼロデイエクスプロイトの急増に対処するために、AI を活用した機械の速度での保護を提供します。Cloud NGFW の高度なマルウェアサンドボックスは、AI によって生成された脅威をリアルタイムでその場で防止します。一方、Cloud Armor のマネージドルールは、既知および未知の共通脆弱性識別子（CVE）の両方に対する自動保護を提供します。これらのサービスは Model Armor と連携して、AI エージェントのコミュニケーションのインテントと内容を分析します。

Google がデータセンター内外で AI 向けにネットワーキングを最適化した方法について詳しくは、こちらをご覧ください。

統合データレイヤ

AI エージェントの能力は、アクセスできるデータと与えられたコンテキストによって決まります。構造化データと非構造化データを使用するアプリケーションやプラットフォームが増えていますが、それらのデータを大規模にカタログ化、検索、活用するのは容易なことではなく、それが原因でエージェントの対応が非効率になる可能性があります。このギャップを埋めるためにエージェントに必要となるのは、すべてのデータがまとめられたクエリ可能なナレッジエンジン、つまり統合データレイヤです。これにより、エージェントは正確な情報源を特定してアクセスできるようになります。Next ‘26 では、統合データレイヤを強化する次の機能を取り上げます。

スマートストレージ: このソリューションは、新しいセマンティックインテリジェンスをデータオブジェクトに直接埋め込むことで、ダークデータを AI エージェントとトレーニングのための強力な知識アセットに変換します。自動アノテーション、エンティティ抽出、セマンティック検索などの新しい Google Cloud Storage 機能により、エージェントは必要とする特定のデータが組織全体にわたって存在するスプレッドシート、PDF、その他の非構造化形式のどれに隠されているかどうかにかかわらず、そのデータを瞬時に検出して使用できます。これにより、AI ソリューションの開発とデプロイが大幅にスピードアップします。AI ワークロードを加速するストレージイノベーションについて詳しくは、こちらをご覧ください。
Knowledge Catalog: Knowledge Catalog は、エージェントが最も正確な結果を提供できるように、データエステート全体にわたってビジネスの意味をマッピングし、グラウンディングされた信頼できる情報源を提供します。この基盤により、AI のトレーニングと推論が可能になり、データの移行が不要になります。エージェントは、データがどこにあっても、完全なコンテキストとガバナンスに沿って直接データとやり取りするため、モダナイゼーションが容易になります。

Google の Agentic Data Cloud の一部となっているスマートストレージと Knowledge Catalog により、データを受動的なアーカイブから動的な推論エンジンに変換できます。

「お客様のスマートホームとセキュリティソリューションをよりインテリジェントで便利なものにするためには、AI が不可欠です。Google Cloud のスマートストレージを活用すれば、BigQuery で配信される豊富なメタデータに自動的にアノテーションを付けることができます。データ検出とキュレーションの取り組みを拡大し、加速させたことで、AI 開発プロセスを数か月から数週間に短縮できたと同時に、信頼を築き、全体的な家庭環境を向上させるイノベーションを継続的に提供できるようになりました。」- Vivint、プロダクトおよび AI 担当バイスプレジデント、Brandon Bunker 氏

デジタル主権

エージェントの時代において、管理を犠牲にすることなくイノベーションを加速させようと目指す公共部門や企業のお客様にとって、デジタル主権は基本的な要件です。万能なソリューションというものは存在しません。そのため、Google ではパブリッククラウド、オンプレミス、ハイブリッドなど、あらゆる場所でさまざまなソブリン AI のニーズに対応できるよう、包括的な一連のサービスを設計しました。Google のソブリン AI ポートフォリオの新機能には、次のようなものがあります。

Confidential External Key Management: 組織は Confidential External Key Management を使用して、暗号鍵の完全な未編入領域、管理権、制御権と、暗号鍵を管理するポリシーを維持できます。Confidential External Key Management は、Confidential Compute を活用して、Google Cloud 内の改ざん防止環境で鍵管理エンドポイントをホストします。鍵の保存場所、鍵へのアクセスを許可するユーザー、アクセスを許可する状況は、お客様が管理できます。特権を持つ Google 管理者であっても、承認なしに鍵にアクセスすることはできません。また、承認はいつでも取り消すことができます。自社のデータを自社で管理できるというわけです。
Google Distributed Cloud 上の Gemini: GDC 上の Gemini を使用すると、企業はデータ主権のニーズを満たしながら、機密性の高い環境に Gemini を安全にデプロイできます。デプロイモデルの選択肢には、接続されたハードウェア上のマネージドソフトウェアや、エアギャップのある完全に切断されたソリューションなどがあります。最も制限の厳しい高度なセキュリティ環境であっても、強力な Gemini モデルから高度なコーディング、検索、その他のエージェント機能に至るまでの Google の最先端の AI 機能によるスケーリングが可能になりました。

さらに、すべてのソブリン AI ワークロードを加速および強化できるよう、Google Distributed Cloud では最新世代の AI インフラストラクチャと Gemini モデルを組み合わせたエンドツーエンドの AI スタックをサポートしています。このスタックには以下が含まれます。

NVIDIA Blackwell GPU: NVIDIA Blackwell（NVIDIA HGX B200）および NVIDIA Blackwell Ultra プラットフォーム（NVIDIA HGX B300）GPU は、第 5 世代 NVIDIA NVLink を活用して AI パフォーマンスを加速し、データセンター規模の帯域幅を環境に直接提供します。
新しい VM ファミリー: 新しい A4 ファミリーパッケージは、最も要求の厳しい推論タスクを処理する能力を提供し、ピーク時のコンピューティングを 2.25 倍に向上させます。メモリ最適化 M2 および M3 は、オンプレミスで大規模な ERP とデータ分析のワークロードに必要となる高いメモリ対 vCPU 比を実現します。
ストレージの強化: ゾーンあたりのストレージ容量が 6 倍に増え、パフォーマンスは 10 倍に向上しています。これによりストレージのボトルネックが解消されるため、オンプレミスで AI 推論を実行できます。今や、データインフラストラクチャは AI 推論のスピードで進化しています。

「弊社のお客様は、マルチテナントのリスクを伴わない、高性能なプライベート AI 推論を求めています。Google Distributed Cloud を使用すれば、機密データに関する厳格な要件を満たす、専用の低レイテンシ環境を提供できます。B200 と B300 で Gemini を実行できるため、推論速度を大幅に向上させ、スケーリングに必要となるトークンスループットをお客様に提供できます。」- Cirrascale Cloud Services、CEO / 共同創設者、Dave Driggers 氏

ビジョンを現実にする

以上の製品分野が収束した時点で、インフラストラクチャはエージェント時代に対応する高性能で安全かつ適応性のある基盤へと進化します。Google は単にツールを提供するだけでなく、企業や公共部門が AI とエージェントの力を最大限に活用できるようにするためのアーキテクチャブループリントを提供しています。

AI インフラストラクチャの主要な業界トレンドについて詳しくは、エージェント型 AI 時代のインフラストラクチャの現状に関するレポートをご覧ください。

- コンピューティングプラットフォーム部門プロダクト管理担当バイスプレジデント、Nirav Mehta

- Google Distributed Cloud 担当バイスプレジデント、Muninder Sambi

Google のスケールアウト AI データセンターファブリック、Virgo Network のご紹介

Wed, 22 Apr 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

AI 時代には、物理的なクラウドアーキテクチャを根本から見直す必要があります。特にネットワーキングはその中心です。基盤モデルのパラメータ数が指数関数的に増加するなか、従来の汎用ネットワークは限界に近づいています。今後 10 年の ML を支えるために、Google は「キャンパス全体を 1 台のコンピュータとして捉える」という考え方に基づく、新たなメガスケール AI データセンターファブリック Virgo Network を設計しました。これは Google の AI Hypercomputer を支える基盤でもあります。

従来型のネットワーク設計では、最新の AI が求める要件の一部に対応しきれません。

大規模化: トレーニング需要はすでに単一データセンターの電力や設置スペースの限界を超えており、複数のデータセンターをまたぐ統合ドメインが必要になっています。
帯域幅需要の急増: 基盤モデルのトレーニングはネットワーク依存度が非常に高いため、アクセラレータ 1 基あたりに必要な帯域幅はここ数年で大幅に増加しています。その結果、旧来のアーキテクチャではスループット不足や輻輳がボトルネックになっています。
同期バースト: ミリ秒単位で発生する激しいトラフィックスパイク（図 1）は、ネットワークバッファに大きな負荷をかけます。その結果、たった 1 つの「処理の遅い」ノードがクラスタ全体の性能を抑えてしまうことがあります。
低レイテンシ: ML サービングでは、リアルタイム推論を実現するために、高速かつ安定した応答時間が求められます。そのため、厳格なレイテンシ制御がアーキテクチャ設計上の重要な要件になります。

図 1: AI トレーニングワークロードで発生するサブミリ秒のラインレートバースト

データセンターネットワークの再構築

AI 時代の要求に応えるには、汎用的なネットワーク設計から脱却し、フラットで低レイテンシな専用ネットワークアーキテクチャへと大きく転換する必要があります。こうした固有のスケール要件とレイテンシ要件に対応するため、Google は north-south トラフィックには実績のある Jupiter ネットワークを活用し、east-west 通信には新たなファブリックを導入しました。その結果、3 つの異なる専用レイヤで構成されるアーキテクチャが、1 つの統合コンピューティングドメインとして機能します。

スケールアップドメイン: 単一 Pod 内のアクセラレータ間で、密接に連携した通信を行うために設計された、高帯域幅 / 低レイテンシの相互接続ファブリック。
スケールアウトアクセラレータファブリック（East-West）: Pod をまたいだ大規模な水平スケーリングに最適化された、アクセラレータ間の専用 RDMA（Remote Direct Memory Access）ファブリック。このレイヤは、決定論的なレイテンシと高い耐障害性を実現するよう設計されており、ML ワークロードに高い「実効スループット」を提供します。
Jupiter フロントエンドネットワーク（north-south）: 分散ストレージや汎用コンピューティングリソースに対して、高速かつ信頼性の高いアクセスを提供する大容量ファブリック。これにより、データアクセスがトレーニングやサービングワークロードのボトルネックになるのを防ぎます。また、非常に大規模なトレーニング実行に向けて、複数サイトにまたがるスケーリングにも使用されます。

このようにアーキテクチャを分離することで、次のような重要な戦略的メリットが得られます。

独立した進化: 各ネットワークドメインを個別に進化およびアップグレードできるため、システム全体への影響を抑えながら、イノベーションのサイクルを加速できます。
専用のスケールアウト帯域幅: ノンブロッキングネットワークにより、重要なトレーニングタスクに必要な大規模なバイセクション帯域幅をアクセラレータに提供できます。
ML とネットワークの協調設計: ネットワークは、ML アクセラレータの各世代に合わせて並行して設計されるため、対応するハードウェアに最適化されたファブリックを実現できます。

図 2: データセンターネットワークのアーキテクチャ

Virgo Network の紹介: メガスケールデータセンターファブリック

Virgo Network は、現代の AI ワークロードが求める極めて厳しい要件に応えるために設計されたスケールアウトファブリックです。1 台のスイッチでより多くのポートを扱える高ラディックススイッチを採用することでネットワーク階層を削減し、フラットな 2 層構成のノンブロッキングトポロジを実現しています。これにより、従来のデータセンターネットワークと比べてネットワーク階層が最小限に抑えられ、レイテンシを大幅に低減できます。さらに、アクセラレータを接続するために、独立した制御ドメインを備えたマルチプレーン設計を採用しています（図 3）。アクセラレータラックは、コンピューティングサービスやストレージサービスにアクセスするため、Jupiter の north-south ファブリックにも接続されます。こうしたシンプルで最適化されたアーキテクチャにより、分散トレーニングとサービングの両方に必要な、巨大なバイセクション帯域幅と、予測可能な低レイテンシを実現しています。

図 3: メガスケールデータセンターファブリック（Virgo Network）

Virgo Network は、Google の次世代アクセラレータ設計を支える基盤であり、次のような利点があります。

大規模なファブリックスケール: Virgo Network は、単一ファブリック内で 134,000 個のチップ（TPU 8t）を接続し、最大 47 ペタビット/秒のノンブロッキングバイセクション帯域幅を実現できます。
世代をまたぐ性能向上: 前世代と比べて、アクセラレータ（TPU 8t）あたり最大 4 倍の帯域幅を提供し、各チップの性能を最大限に引き出します。
予測可能な低レイテンシ: TPU における無負荷時のファブリックレイテンシを前世代比で 40% 低減し、レイテンシの影響を受けやすい AI ワークロードでも、より安定して予測しやすいパフォーマンスを実現します。

大規模環境における信頼性の向上

数十万個のチップを支えるシステムでは、ハードウェア障害は避けられません。しかも、1 つの不良コンポーネントが同期型のトレーニングジョブ全体に影響を及ぼす可能性があるため、この規模では信頼性の確保が最重要課題の一つになります。ワークロードの実効スループットを最大化するため、Google は Virgo Network のアーキテクチャを、障害の切り分け、高度な可観測性、そしてハングやストラグラーへの迅速な対処を中心に設計しました。

この規模では、システム全体のレジリエンスを支える強固なネットワーク基盤が欠かせません。Virgo Network は、独立したスイッチングプレーンを組み込むことで高い障害分離性を実現し、局所的なハードウェア障害によってクラスタ全体の実効スループットが損なわれないよう保護します。

図 4: fail-stop と fail-slow が MTTR に与える影響

この基盤の上で、Google はソフトウェアとオーケストレーションスタックも最適化し、主に次の 2 つの領域を通じて、平均中断間隔（MTBI）の最大化と平均復旧時間（MTTR）の最小化を図っています。

オブザーバビリティ: この規模で信頼性を確保するには、高精度な可視化が不可欠です。Google はサブミリ秒単位のテレメトリーを利用してネットワークシステムをモニタリングしています。このきめ細かな可視性により、一時的な輻輳の検知、バッファ管理の最適化、さらにハードウェアとソフトウェアのスタック全体にまたがる性能低下の根本原因の特定が可能になります。
ストラグラーとハングの検出: 性能が低下しているノード（ストラグラー）や、応答が完全に停止したノード（ハング）を特定するには、先回りしたモニタリングが不可欠です。自動化されたストラグラー検出と、新たに追加されたハング検出によって、こうしたボトルネックを迅速に特定し、トレーニングジョブを加速させるとともに、局所的な性能低下の影響から保護します。

AI Hypercomputer の基盤

Virgo Network は、現代の AI ワークロードが求める厳しい要件に対応するために専用設計された、新しいスケールアウト型データセンターネットワークです。このフラットでマルチプレーンなアーキテクチャにより、Pod をまたいでアクセラレータを 1 つのコンピューティングドメインに統合し、従来型ネットワークの帯域幅やスケーラビリティの限界を克服します。さらに、ハードウェアレベルで高い障害分離性を実現することで、Virgo Network はシステム全体のレジリエンスを支える基盤となり、同期型ワークロードを局所的なハードウェア障害から守ります。

最終的に、Virgo Network は、エージェント型 AI の時代を加速させるために必要なスケール、予測可能なレイテンシ、そして高い信頼性を提供します。AI の未来を支えるインフラストラクチャの構築についてさらに詳しく知りたい方は、 AI インフラストラクチャソリューションのページや技術ドキュメントをご覧いただくか、Google Cloud Next の専用ブレイクアウトセッションにご参加ください。

- プロダクト管理担当シニアディレクター、Benny Siman-Tov

- エンジニアリングフェロー、Arjun Singh

ネットワーキング

AI インフラストラクチャとオーケストレーションに関する最新情報

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

お客様とパートナーに関する最新情報

調査、レポート、詳細解説

2026 年 8 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイド、ドキュメント、ハウツー

お客様とパートナーに関する最新情報

2026 年 7 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

調査、レポート、詳細解説

2026 年 6 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

調査、レポート、詳細解説

お客様とパートナーに関する最新情報

2026 年 5 月

プロダクト、テクノロジー、ツールに関する最新情報

調査、レポート、詳細解説

お客様とパートナーに関する最新情報

AI 推論モデル提供のためのネットワーキング - GKE のみ、およびその他すべてのバックエンド

エントリ ポイント

設計における共通サービス

GKE のみで提供される設計パターン

GKE のトラフィック フローの例

すべてのバックエンドで提供される設計パターン

すべてのバックエンドのトラフィック フローの例

次のステップ

Google Cloud の U4 コンピューティングのご紹介: 超低レイテンシ取引を実現

Google Cloud クラウドネイティブなインフラストラクチャを活用

取引ワークロードのストレージと配置

ULL Solution を使ってみる

AI ワークロードのコンピューティングを柔軟に選択できるよう Google Cloud ネットワーキングがサポート

リソース オプション

ネットワーキングの選択肢

まとめ

次のステップ

Airtel、2026 年インディアン プレミアリーグのクリケット中継を完璧に配信

同時接続数とエッジ効率を考慮した設計

運用準備のためのプロアクティブな戦略

優れたライブ配信のためのブループリント

Uber がクラウド移行を妨げることなくネットワークの信頼性を向上させた方法

重要なトラフィックの優先順位付け

Uber の事例の要点

AI とそれ以外のネットワークの信頼性を確保

Fault Injection Testing で復元力テスト戦略を簡素化

ネイティブな復元力テストが重要な理由

Fault Injection Testing の仕組み

企業向けに設計

Fault Injection Testing を使ってみる

TelevisaUnivision が Google Cloud を利用して FIFA ワールドカップを数百万人にストリーミング配信

TelevisaUnivision が Google Cloud を選んだ理由

プラットフォーム アーキテクチャ

カスタマー サクセスへのこだわり

まとめ

GKE の ClusterNetworkPolicy: マイクロサービスの制御と自律性のバランスを取る

ティアによるポリシーの構造化

一般的なネットワーク セキュリティ シナリオ

シナリオの例

オープンソース基盤の拡張

GKE マネージド DRANET を使用した Autopilot クラスタ: GPU と TPU

Autopilot とマネージド DRANET

設定フロー

1. Autopilot クラスタをデプロイする

2. カスタム ComputeClass を作成する

3. ResourceClaimTemplate を作成する

4. ワークロードをデプロイし、ComputeClass と ResourceClaim を参照する

次のステップ

IDC: 適切なネットワーキング アプローチがエージェント型 AI の基盤となる理由

大規模な運用管理、セキュリティ、ガバナンスのためのネットワーキング

プラットフォーム ベースのアプローチとベスト オブ ブリード型アプローチとのバランスを取る

スポンサーからのメッセージ

C4N の一般提供を開始: クラウドで最高レベルの vCPU あたりのネットワークとブロック ストレージの I/O を x86 ワークロードで実現

新機能: C4N で大規模なデータレイヤをスケール

次世代のネットワーク パフォーマンス

Hyperdisk による動的なストレージ パフォーマンス

お客様の声

エントリポイント

GKE のトラフィックフローの例

すべてのバックエンドのトラフィックフローの例

リソースオプション

Airtel、2026 年インディアンプレミアリーグのクリケット中継を完璧に配信

プラットフォームアーキテクチャ

カスタマーサクセスへのこだわり

一般的なネットワークセキュリティシナリオ

IDC: 適切なネットワーキングアプローチがエージェント型 AI の基盤となる理由

プラットフォームベースのアプローチとベストオブブリード型アプローチとのバランスを取る

C4N の一般提供を開始: クラウドで最高レベルの vCPU あたりのネットワークとブロックストレージの I/O を x86 ワークロードで実現

次世代のネットワークパフォーマンス

Hyperdisk による動的なストレージパフォーマンス

2. アクティブ/スタンバイアーキテクチャのトラフィックパスの制御

Cloud Network Insights: クロスクラウドネットワークに対するエンドツーエンドのオブザーバビリティ

AI 時代に向けた Google のグローバルおよびデータセンターネットワークの進化

3. 推論の時代を支える、復元力のあるグローバルネットワーク

あらゆるインフラストラクチャで、AI とクラウドアプリケーションを保護

エージェント型エンタープライズのためのクロスクラウドインフラストラクチャのイノベーション

Google のスケールアウト AI データセンターファブリック、Virgo Network のご紹介

データセンターネットワークの再構築

Virgo Network の紹介: メガスケールデータセンターファブリック