GCP News - 2026-08-24

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

エンタープライズ向けのエージェント型自動化とビジネス オーケストレーションの市場リーダーである UiPath は、業界のエージェント型 AI への移行を先導しています。これにより、同社は自律型エージェントをデプロイして、さまざまなシステムにわたって積極的に推論、意思決定を行い、複雑なビジネス プロセスを実行しています。

単純なタスクの自動化から認知的意思決定エージェントへの移行には、膨大なコンピューティング能力とともに、世界最大規模の企業のニーズに十分な信頼性を備えた強力なインフラストラクチャが必要です。

数百もの GPU を完璧にオーケストレートできることが、単なる研究実験の実施と、グローバルな AI プラットフォームとの構築の違いを生み出します。このようなオーケストレーションを実現するには、費用の急増やレイテンシの急上昇を発生させることなく、大規模なトレーニング ジョブとリアルタイム推論のバランスを取る必要があります。

そのために、UiPath は UiPath IXP を使用した大規模なインテリジェント ドキュメント処理（IDP）をサポートするようインフラストラクチャを再設計し、分離されたクラスタから、共有の Google Cloud GPU フリートへと移行しました。トレーニングには A3 VM インスタンス（NVIDIA H100 GPU）を、推論には G4 VM インスタンス（NVIDIA RTX Pro 6000）を使用してバランスを取っています。このアーキテクチャにより、UiPath は「急激に変動するワークロード」の問題を解決できました。また、予測可能な費用とオープンソース パターンを頼りに、同社のエンジニアリング チームがこのアーキテクチャを自ら複製できるようになりました。

「エンタープライズ向けエージェント型 AI の可能性を最大限に引き出すには、当社の高い目標にふさわしいインフラストラクチャが必要です。Google Cloud は、特殊なモデルをトレーニングしてグローバルにデプロイするために必要な規模と柔軟性を提供してくれます。このパートナーシップにより、高精度のインテリジェントなドキュメント処理と、単にチャットするだけでなく、お客様のビジネス成果を積極的に推進する自律型エージェントを提供できます。」– UiPath、最高技術責任者、Raghu Malpani 氏

背景: 高度な計算

UiPath は、フルスタックの自動化プラットフォームを長年にわたって Google Cloud 上で運用してきましたが、エージェント型 AI の取り組みが拡大するにつれて、インフラストラクチャに関する一連の新たな課題に直面しました。

IDP、コンピュータ ビジョン、LLM を活用した推論などのコア機能には、高度な計算が必要となります。そのため、UiPath のエンジニアリング チームは、ロボットが人間のような明瞭さでインターフェースを「認識」できる LLAMA モデルのグラウンディングを活用しています。また、Qwen アーキテクチャを基盤とする特殊なドキュメント モデルにより、煩雑な実世界の書類から価値あるデータを抽出できます。

これらのモデルは UiPath のクラウド インフラストラクチャ上に存在し、可能な限りレイテンシを短縮することが不可欠です。「優れたデモ」から、費用を急増させることなく信頼性の高い本番環境ツールに移行するには、基盤となるシリコンを再考する必要がありました。

課題: 供給を上回る需要

UiPath のチームが新しいモデルのトレーニングや推論を行う必要があるとき、これまではオンデマンドで GPU ノードをプロビジョニングし、ワークロードの急増または減少に応じてスケールアップまたはスケールダウンしていました。

クラウドの容量が安価で豊富にあり、完全に弾力的であった時代には、これは機能的な戦略でした。しかし、AI への意欲が高まるにつれ、UiPath はこのアプローチでは運用の複雑さに対応できなくなっていることに気づきました。このとき、次の 3 つの新たな課題に直面していました。

1. 急激に変動するワークロード: ピーク時の需要に対応できる十分な能力を確保するために、多くの場合、追加の容量を購入せざるを得ませんでした。この容量は、需要が少ない時期にはアイドル状態になり、高価なヘッドルームを無駄にしていました。同社は、計算処理を行っていないシリコンに料金を支払う必要のない、インテリジェントなオンデマンド スケーリングを必要としていました。

2. 供給のボトルネック: 大規模なファインチューニングにおいては、8 クラスタの H100 を搭載したゴールド スタンダードのハイエンド A3 VM インスタンスの費用対効果は圧倒的です。しかし、これらのチップは世界的に需要が供給を上回っており、ノードを追加するだけで UiPath が望むスピードでトレーニングの取り組みをスケールすることはほぼ不可能になっています。

3. 運用上のオーバーヘッド: UiPath は、地理的な非効率性にも悩まされていました。安定した推論の需要があるということは、複数のリージョンで専用クラスタを維持することで、世界中の顧客向けに低レイテンシを確保する必要があることを意味していました。さらに、トレーニングと推論の両方のために GPU インフラストラクチャを管理することで、運用オーバーヘッドの非効率的なレイヤが追加されました。

解決策: 共有 GPU フリート

こうしたことを踏まえ、UiPath は GPU をプロダクト中心の弾力的なインフラストラクチャではなく、共有の戦略的リソースとして扱うことにしました。

その結果、エンジニアリング チームは、自社の ML サービス（MLS）プラットフォームが管理するプラットフォーム レベルの共有 GPU フリートを設計しました。このフリートは、ワークフロー間で需要のバランスを取りながら、チームと時間枠をまたいで作業を優先順位付けします。日中は、リアルタイム推論や、レイテンシの影響を受けやすいワークロードを処理し、夜間やオフピーク時には、バッチ トレーニングや長時間実行ジョブに自動的に切り替わります。

MLS は、フリートレベルでワークロードを調整することで、インスタンスごとの弾力性に依存することなく、競合を減らしながら使用率を最大化します。また、事前に容量をスケジュールできるため、研究と本番環境の両方のユースケースで予測可能性が向上します。

Google Cloud を選ぶ理由: AI Hypercomputer アーキテクチャ

UiPath は、拡大する規模に対応するために、Google Cloud AI Hypercomputer を活用しました。これは、パフォーマンスが最適化されたハードウェア、オープン ソフトウェア、柔軟な使用量モデルを統合環境に組み込んだシステムレベルのアプローチを提供するものです。AI Hypercomputer は、ハードウェア レイヤとソフトウェア レイヤの間の摩擦も最小限に抑えるため、エンジニアリング チームはインフラストラクチャの管理ではなく、モデルのパフォーマンスに集中できます。

共有フリートモデルの採用を決めた UiPath には、GPU の確実な可用性、競争力のある価格、バースト容量を提供できるクラウド パートナーが必要になりました。そこで、同社は既存の Google Cloud フットプリントを拡大し、高度に特化した AI スタックを Google Kubernetes Engine で実行することにしました。

現在、UiPath は Google Cloud の Dynamic Workload Scheduler（DWS）を活用して、予測可能な容量を利用することで、供給のボトルネックを解消しています。同社は、Google Cloud なら数日単位の通知期間で GPU 容量を確実に確保できることを知っていました。エンジニアリング チームは DWS を使用して、トレーニングの実行を事前にスケジュールして、短時間のバーストのための容量を確保できます。また、不足が発生してから対応するのではなく、容量を計画できるようになりました。UiPath は現在、すべてのトレーニングと、ほとんどの IDP モデル推論ワークロードを Google Cloud で実行しています。

UiPath は、負荷の高いトレーニングとファインチューニングに A3 VM インスタンスを使用していますが、すべてのタスクにそのレベルの能力が必要なわけではありません。そのため、現在は、推論ワークロードの最適化を新たに実現するために、Google Cloud G4 VM インスタンスをデプロイしています。これらのインスタンスは、パフォーマンスと価格のバランスが良く、費用対効果に優れており、UiPath はトレーニング用に予約された高パフォーマンスのクラスタを占有することなく、より軽量な推論タスクを実行できます。

「Google Cloud の共有フリートに移行したことで、運用モデルが変わりました。事後対応型のプロビジョニングから予測可能な高パフォーマンスのエンジンへと移行し、最先端の IDP とエージェント型 AI ワークロードを支えられるようになりました。Dynamic Workload Scheduler などのツールと、A3 インスタンスと G4 インスタンスの組み合わせにより、費用と速度の両方を最適化できる柔軟性が得られました。これにより、エンジニアはコンピューティングを待つのではなく、イノベーションに時間をかけることができます。」- UiPath、AI インフラストラクチャ担当ディレクター、Arthur Wilcke 氏

実用的な検証: 大規模な差別化モデル

Google Cloud GPU に安定してアクセスできるようになったことで、UiPath は高度なモデルを本番環境に導入できるようになりました。また、本番環境の推論を妨げることなく大規模なトレーニング ジョブをスケジュールできるため、研究実験と本番環境の信頼性のバランスを取ることができます。

これにより、UiPath は、構造化されていないさまざまなドキュメントからデータを高精度で抽出する高度な IDP 機能を実現できます。例:

• Omega Healthcare は、UiPath を使用して 1 億件を超えるトランザクションを 99.5% の精度で自動化し、処理時間を 40% 短縮、反復タスクを月あたり 15,000 時間削減しました。

• Thermo Fisher Scientific は UiPath を使用して請求書や注文書などの PDF からデータを抽出しています。現在では請求書の 53% を人手を介さずに処理できるようになり、処理時間を 70% 短縮しています。

参考ポイント

UiPath のこれまでの最大の成果は、可用性と信頼性の向上です。ワークロードの移行は今も継続しており、以前の GPU リソースの廃止に伴い、さらなる費用削減が見込まれます。

同様のプラットフォームの構築を検討しているエンジニアリング チームにとって、重要なポイントは次のとおりです。

1. 容量の切り離し: ハードウェアを特定のプロダクトに結び付けるのではなく、リソースをプールして使用量の急増を平準化します。

2. 事後対応よりもスケジュール設定: DWS などのツールを使用してコンピューティングを事前に予約することで、可用性が保証され、費用が安定します。

3. シリコンのサイズ適正化: トレーニングには A3 VM インスタンスを使用し、推論には G4 VM インスタンスなどの効率的なオプションを選択します。

次のステップ

UiPath は、最近のインフラストラクチャの進化後も、AI イノベーションの次の進化をサポートするために、MLS プラットフォームの改良を続けています。この成功を皆様の組織でも再現するために、以下のリソースをご活用ください。

• 構築: GitHub でエンジニアリング パターンを確認する。

• 最適化: Google Cloud G4 VM インスタンスを使い始める。

• UiPath - IXP の詳細を確認する。

- AI インフラストラクチャ担当シニア カスタマー エンジニア、Abhijeet Rajwade

- UiPath、AI パートナーシップ担当プリンシパル、Jason Morrison 氏

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

市場の細分化と経済の不安定化が無秩序に進むなか、マーケティングやコミュニケーションの代理店は、クライアントを獲得し、広告費用を最適化するために従来使用してきた人間の直感に頼ることができなくなっています。WPP は、AI を活用して市場動向の変化を把握することで、こうした推測に頼る必要をなくしています。これにより、ブランドは予測の確実性が得られ、市場のスピードに合わせて自信を持って投資できます。これがエージェント型マーケティング システム WPP Open の価値です。

しかし、高度な AI モデルを適用して分析情報を強化する前に、WPP は重要なエンジニアリング上の課題を克服する必要がありました。モデルを構成するマーケティング データが、世界中の数百もの代理店に分散していたのです。このような状況で、AI ツールを効率的かつ安全にデプロイすることはほぼ不可能でしたが、モデルへのアクセスは問題の一部にすぎませんでした。そして、データをモデルに取り込み、クリーニングし、提供するための信頼できる方法を構築するまで、WPP が生成 AI の本当の実力を引き出すことはできませんでした。

この問題を解決するため、WPP は Google Cloud と提携して、統合されたデータ バックボーンとカスタム プラットフォーム エンジニアリング パスを構築しました。現在、WPP はサーバーレス コンピューティング パターンとデータ処理ワークフローを標準化することで、標的型マーケティング キャンペーンを数か月ではなく数日で安全に展開できるようになりました。

サービスベースの集中型データ基盤の設計

この取り組みにおける重要な部分は、データの可用性向上と管理の一元化でした。これを実現するために、WPP は現在の本番環境にサービスベースのプロジェクト構造を採用しました。エンジニアリング チームは、すべてのワークロードを別個のサイロに分離するのではなく、Google Cloud Storage（GCS）と BigQuery を専用の共有データ プロジェクトに一元化すると同時に、コンピューティングと処理のワークロードを異なる処理プロジェクトに分離しました。

この構造により、コアチームのユーザー エクスペリエンスが簡素化され、データ利用者全員が、統合された信頼できる情報源を操作できるようになりました。共有インフラストラクチャには、WPP のさまざまなプロダクト ラインのデータが保存されているため、セキュリティを細部まで厳格に適用することが不可欠でした。同社は個々の GCS バケットと BigQuery データセットのレベルで Identity and Access Management（IAM）制御を直接適用することで、各チームがアクセスを許可されたデータのみを表示できるようにしました。

同時に、さまざまなパートナーからの元データは、未加工の入力データを整理して分離するために、専用の GCS バケットに保存されます。そこから、Managed Service for Apache Spark が Apache Spark のカスタムジョブを実行して、情報をクレンジング、正規化し、標準のコホート定義（SCD）に変換します。WPP のデータ エンジニアリング チームは、サーバーレス アーキテクチャを、パイプライン オーケストレーション用の Kubeflow と組み合わせて利用することで、クラスタ インフラストラクチャの管理でよく発生するオーバーヘッドを回避しました。これにより、ダウンストリームの GCS と BigQuery のレイヤに対するデータ変換ロジックに完全に集中できるようになりました。これらのレイヤが、最終的にオーディエンスとパフォーマンスの AI モデルにデータを提供することになります。

Google Cloud とのコラボレーションが成功したのは、ベスト プラクティスに関する妥協のないプロ意識と、非常に実用的で現実的なソリューションのタイムリーな提供のバランスが取れていたからです。
- WPP、シニア データ エンジニアリング リード、Jonas Dahlbaek 氏

データを統合コホートで標準化

 元データが WPP の処理ゾーンに入ると、プラットフォームによって SCD に変換され、それがフレームワーク全体でキーイング目的で使用されるコア コンセプトになります。これらは、年齢、性別、地域、商品、興味 / 関心の 5 つのキーに基づきます。しかし、これらの基礎となるデータ定義は流動的であり、進化するマーケティングのコンセプトを反映するために継続的に正規化されます。その結果、この統一された構造により、WPP は機密性の高い基礎的な詳細を公開したり、共有識別子に依存したりすることなく、グローバル規模でデータを結合および集計できます。

プラットフォームのコア処理エンジンは、包括的な可視性とコンプライアンスを確保するために、型安全性を備えた Scala で構築されました。このカスタム フレームワークは、データの変換方法を厳密に制御するとともに、キュレートされたデータセット内のすべてのデータポイントをその起源までたどれることを保証しながら、ソースの完全なトレーサビリティを本質的にサポートします。データ サイエンティストと監査担当者は、モデルにどのような情報が入力されるかを正確に把握する必要があるため、これはエンタープライズ AI アプリケーションを構築する際に重要なレベルのトレーサビリティです。ただし、WPP はそれと並行して、全社的なデータ ガバナンス自動化のために、将来的に Google Cloud Knowledge Catalog に移行する準備も進めています。

Google Cloud との連携は、エンジニアリングの取り組みを迅速化、標準化するうえで非常に役立っています。大量の断片化されたデータが日々課題となる環境においては、適切なインフラストラクチャの存在が AI 時代に成功を収めるために最も重要であり、社内の開発者と AI マーケターの双方に役立ちます。- WPP、OI および Google パートナーシップ担当プロダクト マネージャー、Suleman Khan 氏

エンタープライズ ソフトウェア ライフサイクルの標準化

これらのステップをすべて実施しても、データの処理は WPP にとってまだ課題の半分にすぎません。同社のプラットフォーム エンジニアリング チームは、アプリケーションを提供し、基盤となるインフラストラクチャを管理するために、再利用可能な継続的インテグレーションと継続的デプロイ（CI / CD）のテンプレート スイートを GitLab で開発し、一元化しました。これにより、WPP は個々の開発チームの認知負荷を軽減するとともに、すべてのデプロイが厳格な全社的セキュリティ基準を満たすようにしました。

これらのテンプレートは、さまざまなエンタープライズ ワークロードを自律的に管理します。テンプレート スイートには、フルスタックのウェブ アプリケーション、データのバッチ処理、スケジュール設定されたパイプライン用の汎用 Cloud Run テンプレートが含まれています。また、マルチステージ ワークフロー用のデプロイ専用テンプレートと、イベント ドリブン マイクロサービス用の Cloud Run functions デプロイ テンプレートも含まれています。

再ビルドなしのプロモーションの実装

本番環境でコンテナ イメージを再ビルドすると、不必要なリスクや構成ドリフトが発生する可能性があります。WPP は、環境の整合性を維持するために、「一度のビルドで何度でもデプロイする」手法を採用し、IAM ロジックと Google Cloud Artifact Registry の構成をプロジェクト間で適用しました。

このプロセスでは、開発者が開発環境でコンテナ イメージを構築してテストします。これらの不変のコンテナ イメージは、検証後にそのまま本番環境にプロモートされます。この再構築不要のプロモーションにより、デプロイ ステージ間で完全な整合性が確保され、本番環境での予期しない動作がなくなります。CI / CD テンプレートは、段階的なトラフィック移行も容易にします。これにより、チームは完全なロールアウトを開始する前に、トラフィックのごく一部を新しいリビジョンにルーティングできるようになりました。

不変のデプロイ、追跡可能なデータ、揺るぎない信頼。AI に何が入力されるかを正確に把握できれば、光の速さでリリースできます。- WPP Media、DevOps（I&P）担当アソシエイト ディレクター、Ranjith K Poldas

セキュリティとインテリジェント ネットワーキングの自動化

この最新式のアーキテクチャでは、エンタープライズ セキュリティが WPP の基盤となるイネーブラーとして機能するため、同社は Wiz のセキュリティ スキャンを CI / CD パイプラインの push 前のフェーズに直接統合し、コードがマージされる前に脆弱性を検出できるようにしました。また、Google Cloud Identity-Aware Proxy を利用して、社内アプリケーション全体にゼロトラスト アクセスを適用しました。

運用をさらに簡素化するために、WPP はインテリジェントな Virtual Private Cloud（VPC）ロジックを盛り込んだテンプレートを採用しました。この構成では、以前の VPC コネクタと最新のダイレクト VPC アクセスの間でネットワークの競合が自動的に特定され、解決されます。このネットワーキングの自動化により、デプロイの失敗が防止され、リリース サイクルが加速されます。

運用の健全性をモニタリングして ROI を促進

復元力のあるプラットフォーム基盤には詳細なオブザーバビリティが必要であるため、WPP のエンジニアリング チームは現在、デプロイ頻度のみに頼らずに、厳格な運用指標をモニタリングしています。チームは、4xx と 5xx のエラー率とともに、p50、p95、p99 のパーセンタイルでリクエストのレイテンシを追跡しています。また、コンテナの起動時間をモニタリングしてコールド スタートを軽減するとともに、CPU とメモリの全体的な使用率を追跡しています。この詳細レベルにより、データ パイプラインとサーバーレス インフラストラクチャの両方で、常に高い可用性が維持されることになります。

「データ エンジニアリング、プラットフォーム インフラストラクチャ、AI 統合にまたがる複数の複雑なワークストリームにわたって、これほど大規模な変革を推進するには、単なる連携以上のもの、つまり深い相互信頼が必要でした。Google Cloud と WPP は真のパートナーとして連携し、プロダクション レディなプラットフォーム機能を予定どおりに実現しました。」Google Cloud、プログラム マネージャー、Yang Yue

WPP は、このスピード感でデータと AI スタックを運用化することで、高度なワークロードに必要なインフラストラクチャを実現しました。そのビジネス インパクトは明らかで、数値化も可能でした。この二重の基盤を構築することで、同社はクリエイティブと戦略にかかる時間を 4 週間からわずか 3 時間に短縮しました。また、制作効率が 70% 向上し、コンテンツ量が 33 倍に増え、キャンペーンの投資収益率が 2.8 倍に向上しました。まとめると、WPP は Google Cloud と提携して、幅広いプロダクトとツールのスイートを実装することで、短期間で高い ROI を実現し、全社的に生産性、効率性、信頼性、セキュリティを向上させることができたのでした。

- テクニカル ソリューション コンサルタント、Utkarsh Bhardwaj

- 戦略的クラウド エンジニア、Prabha Arya

※この投稿は米国時間 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 は、フラットで競合するピアルールを同時に調整しようとするのではなく、決定論的なトップダウンの評価階層を確立します。

1. 管理者ティア: 最も優先度の高いレベル。ここでのルールは、他のあらゆるポリシーよりも先に適用されます。

2. ネットワーク ポリシー ティア: 標準の名前空間レベル。デベロッパーが個々のアプリケーション ポリシーを管理します。

3. ベースライン ティア: 最も優先順位が低く、他のどのポリシーも適用されない場合のクラスタのデフォルト動作を規定します。これは、名前空間スコープのポリシーを使用でオーバーライドできます。

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

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

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

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

• 機密性の高いワークロードの分離: 管理者ティアのグローバル拒否ルールを適用して、支払い処理やコンプライアンス データに使用される名前空間など、特定の名前空間をクラスタの他の部分から分離できます。このアクションは、放っておくとこれらの環境をさらしてしまう恐れのある、制限の緩いデベロッパー ポリシーをオーバーライドします。

• コアサービスの保護: 内部運用に支障をきたすような構成を防ぐため、管理者は kube-dns などの重要なサービスに対して、管理者ティアのグローバル許可ルールを作成できます。これにより、名前空間ポリシーに構成ミスがあっても、これらのサービスへのアクセスを維持できます。

• 外部への下り（外向き）の管理: IP アドレス範囲のマッチングを利用することで、下り（外向き）トラフィックをクラスタレベルで制御できます。この機能を使用すると、企業イントラネットや外部 IP 範囲へのアクセスを明示的に制限または許可できるため、不正なデータの持ち出しに対する安全対策として機能します。

シナリオの例

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

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

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

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

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

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

• GKE ClusterNetworkPolicy の構成

• Kubernetes SIG-Network ClusterNetworkPolicy API 仕様

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

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

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

AI エージェントを大規模にデプロイする組織にとって、構造化データと非構造化データのギャップは、しばしば重大な問題となります。大規模言語モデル（LLM）は、テキスト ドキュメント、メール、PDF の解析には優れた力を発揮しますが、企業の未加工データベースには手こずることがあります。一方、標準的な自然言語から SQL への変換（NL2SQL）モデルは、データベース スキーマの相互適合性を推測に頼りがちで、予測不可能なクエリ、一貫性のない指標、AI ハルシネーションを生んでユーザーの信頼を損なう可能性があります。

Gemini Enterprise は、こうした課題を解決する役割を果たします。直感的なチャット インターフェースを通じて Google AI の最先端機能をすべての従業員に提供し、職場における AI 活用の「一元化された窓口」として機能します。しかも、Looker の統制されたセマンティック レイヤが Gemini Enterprise 内における構造化データの信頼できる基盤として機能するようになりました。これにより、Gemini Enterprise のすべてのユーザーは、信頼できるセルフサービス ビジネス インテリジェンスを利用できます。このインテグレーションにより、Looker を使用するアナリストと管理者は、Agent-to-Agent（A2A）プロトコルを介して、会話型エージェントを Gemini Enterprise 環境にネイティブに公開できます。つまり、組織は、AI をフル活用するタスクフォースを編成して、リアルタイム分析を完備した安定性と信頼性の高いツールを提供できるようになったのです。しかも、ツールはワークスペースの日常業務同様、自然言語で対応し、活用することができます。Gemini Enterprise で会話型エージェントを簡単に提供できるようになったことで、必要な情報を見つけやすくなり、データドリブンな文化が促進され、誰もが AI を活用しやすくなりました。

構造化データと非構造化データの両方に対応するセマンティック基盤

Looker のセマンティック レイヤと Gemini Enterprise のインテグレーションにより、構造化データベースと非構造化ドキュメントの両方を 1 か所で、平易な自然言語でクエリできるようになりました。数値を把握するために、もうダッシュボードと他のツールを行ったり来たりする必要はありません。客観的かつ具体的な指標を現実世界のコンテキストに即座に結び付け、問題解決や意思決定を迅速に行うことができます。

AI ハルシネーションを最小限に抑える

一般的な AI chotbot は、非構造化クラウド データベースを使用した「収益」や「離脱率」の計算を指示されると、どのテーブルを結合し、どのフィルタを適用し、どのタイムスタンプを信頼するか、などの推測が必要になります。このため、同じ質問をしても、そのときどきでまったく異なる回答が得られたりします。

Looker のセマンティック レイヤは、この推測を排除し、重要なコンテキストをコード化されたデータ形式で Gemini Enterprise にフィードすることで、エージェントが確定的で予測可能な回答を提供できるようにします。

Gemini Enterprise でユーザーがビジネス KPI をリクエストすると、リクエストは Looker エージェントに直接ルーティングされます。セマンティック レイヤは、バージョン管理されたビジネス ロジックに基づいて、正確な決定論的 SQL を生成します。これにより、たとえば、経営幹部が「収益」を尋ねたときには、推測ではなく、きちんと管理された正確な企業指標が得られるようになります。

堅牢なガバナンスとセキュアなアクセス管理

AI を企業のデータ ウェアハウスに導入する際には、データ ガバナンスとセキュリティが非常に重要です。組織は、企業情報が厳格な権限を通さずに緩く取り込まれたり、インデックス化されたり、公開されたりするリスクを負うことはできません。

その点、Looker と Gemini Enterprise のインテグレーションは、ゼロリスクのパススルー アーキテクチャに基づいて構築されており、データを処理はしますが、永続ストレージには書き込みません。Gemini Enterprise は、基盤となるデータベースのレコードを取り込んだり、複製したり、保存したりすることはありません。代わりに、Looker とのインテグレーションにより、A2A プロトコルを介して安全かつセキュアに運用し、次の基本原則に沿って処理します。

• OAuth 認証: Gemini Enterprise 内で Looker エージェントを使用する際、エンドユーザーはセキュアな 1 回限りの OAuth 同意を提出する必要があります。これにより、Gemini セッションが特定の Looker 認証情報にバインドされます。

• 強力なガバナンスの適用: アーキテクチャはライブ パススルー クエリに依存しているため、Looker の既存の行および列単位のアクセス制御が維持されます。

• 厳格なセキュリティ分離: ユーザーが Looker プラットフォーム内で、たとえば地域別の給与や財務など、機密データの行を表示する権限を持たない場合、Looker エージェントは Gemini 環境でそのデータを能動的に制限します。エージェントを Agent Gallery に公開してアクセスしやすくしても、確立済みのセキュリティ制御がバイパスされることはありません。

技術的な機能性とエンタープライズ対応

A2A プロトコルを介して Gemini Enterprise にネイティブにデプロイできる Looker エージェントの効果は、スマートさの向上だけにとどまりません。セキュリティを犠牲にせずに、インタラクティビティと相互運用性を高める効果もあります。たとえば、このリリースには以下の機能が含まれています。

優れたビジュアル インタラクティビティ: グラフのサポート

「1 枚の写真は千の言葉に値する」と言われますが、ユーザーが Gemini Enterprise 内の Looker エージェントとやり取りすると、プラットフォームはテキストによる説明だけでなく、ネイティブでインタラクティブなデータグラフを提示できます。たとえば、月次販売実績や地域別の分布などの視覚的なトレンド情報を求めると、Looker エージェントはデータベース レスポンスを、プレゼン資料にそのまま使えるような豊かなビジュアルにマッピングして、ユニバーサル チャット ボックス内に直接表示します。

注: バージョン 26.12 より前の Looker リリースで Gemini Enterprise に Looker エージェントを公開した場合は、これらの強化されたビジュアリゼーション機能を活用するために、エージェントを 26.12 以降のリリースで更新することをおすすめします。

ファースト パーティおよびサードパーティ エージェントとの相互運用性

Gemini Enterprise に公開された Looker エージェントは、他のさまざまなエージェントおよびデータソースのコンテキストを理解することができます。Looker エージェントは、標準的な通信フレームワークを活用して、構造化され、管理されたインサイトを Deep Research エージェントなどの他のファースト パーティ Google Cloud エージェントや外部のサードパーティ エージェントとセキュアに共有し、構造化されたワークフローを作成できます。これにより、複雑なマルチエージェント オーケストレーションが可能になり、企業の運用エージェントが Looker エージェントからデータを取得して、別の生産性ワークフローやサプライ チェーン ワークフローにフィードできます。

Looker ベースのユーザー認証

企業のガバナンスを維持するために、Looker と Gemini Enterprise のインテグレーションでは、ID を中心とした堅牢な認証モデルが実装されています。ユーザーは、1 回限りの OAuth 同意を提出し、基盤となる Looker 認証情報にアクティブな Gemini Enterprise セッションをセキュアにバインドする必要があります。これにより、データベースに送信されるすべての会話型クエリがユーザーレベルで認証され、既存の Looker 権限構造、行レベルのデータアクセス フィルタ、列レベルのマスキング ルールが例外なく適用されます。

信頼できるデータをもたらす Gemini Enterprise

エージェント型 AI は未来の仕事を支えます。Gemini Enterprise は、このエージェント型 AI をデジタル タスクフォースとしてグローバルに展開する一元化されたセキュアなアーキテクチャを提供し、企業の開発者、従業員、顧客のための最先端の Google AI でビジネスを力強く後押しします。

Looker と Gemini Enterprise のインテグレーションにより、信頼できるデータ分析がビジネス ユーザーに提供されるだけでなく、豊かなインタラクティビティ、視覚的なグラフ、データ ストーリーテリングが日常のワークスペースに直接追加されます。ビジネス ユーザーは、エージェントを活用した、この新しい働き方を取り入れることで、テキストによる回答を得るだけでなく、そのままプレゼン資料に使えるような、運用指標や複雑な分析情報をわかりやすく提示するビジュアリゼーションを得ることができます。

まず、Gemini Enterprise でデータ エージェントを公開する方法を学び、エージェントの事前定義されたコンテキストと分析力を組織全体で利用できるようにしましょう。

- プロダクト マネージャー、Tarunima Tripathi