Cloud Blog JA

分析の高速化: PayPal の Managed Service for Apache Spark 導入事例

Thu, 08 Oct 2026 02:00:00 +0000

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

データドリブンな世界において、PayPal が優位性を維持するためには、タイムリーで実用的な分析情報を提供できる機能が不可欠です。PayPal では、不正行為の検出からユーザーエクスペリエンスの向上まで、あらゆる場面でデータを活用しています。データは、エージェントソリューションとエクスペリエンスの可能性を引き出すためにも中心的な役割を果たします。

しかし、当社の分析環境は、増大し続ける需要に対応していくうちに、時間の経過とともに、さまざまなテクノロジーとソリューションをオンプレミスで組み合わせた複雑なエコシステムになっていました。このアプローチでその時点でのニーズに対応することはできましたが、スケーリングとメンテナンスの面で新たな課題が生じ始めました。

困難な分析環境を乗り切る

急激な成長と買収により、当社のデータ分析プラットフォームは徐々に不均一な状態になっていきました。新しいプラットフォームや統合の導入により特定のビジネスニーズには対応できましたが、それらが組み合わさることで、運用上のオーバーヘッドが増加し、パフォーマンスのボトルネックが生じていました。スケーリングがますます困難になり、プロセスが複雑になるにつれて分析情報を得るまでの時間が長くなりました。

複雑さにより生じた停滞

PayPal の従来のデータ分析プラットフォームは、毎日ペタバイト規模のデータを処理する強力なものでしたが、急速な成長に伴い、柔軟性が失われていきました。小売業のピークイベントやグローバルなリリース時にスケールアップするには、数か月にわたる計画と時間のかかるハードウェアの手動プロビジョニングが必要であり、多くの場合、スピードとコストの間で妥協を余儀なくされていました。

PayPal がグローバルに拡大を続けるなか、データの効率性を高め、イノベーションを加速させるために、合理化された統合インフラストラクチャが必要であると認識しました。

ソリューション: 統合されたクラウドネイティブな分析

これらの問題を克服するために、分析ワークロードを従来の Hadoop オンプレミスプラットフォームから Google の Managed Service for Apache Spark に移行しました。

この選択の主な理由は次のとおりです。

迅速なプロビジョニングと柔軟なスケーリング: Managed Spark により、クラスタを数分でデプロイし、処理ニーズに応じてスケーリングできるようになったため、時間のかかる設定やアイドル状態のリソースのコストが排除されました。
統合されたインフラストラクチャ: Apache Spark に標準化することでチーム間に一貫性が生まれ、Managed Service for Apache Spark やその他のマネージドサービスを活用することで運用の複雑さが軽減されました。
シームレスな統合: Google Cloud Storage（GCS）、BigQuery、その他の Google Cloud サービスへのネイティブフックにより、エンドツーエンドのデータ移動が効率化されました。

PayPal は、この移行により、クラウドネイティブソリューションの柔軟性、スケーラビリティ、信頼性を活用して、データ処理機能をモダナイズできました。以前は複数のプラットフォームでばらばらに実行されていたワークフローとバッチジョブを、単一のクラウドベースの分析プラットフォームに統合することで、データサイロを削減し、より迅速で豊富な分析情報を提供する統合データ基盤を構築しました。

これにより、開発者とアプリケーションチームは、インフラストラクチャに制限されることなく、ビジネス価値を創出することに集中できるようになりました。重要なのは、この移行が単なるプラットフォームの再構築にとどまらなかったことです。新しい実験の文化を育成し、変化するビジネスニーズに応じて、チームが分析ワークロードを迅速にテスト、調整、デプロイできるようにしました。

結果: 分析情報の迅速な取得、オーバーヘッドの低減

Managed Spark を活用した最新の Google Cloud ベースのエコシステムは、大きな効果をもたらしました。

コア分析ワークロードの処理時間が 25% 短縮され、主要なビジネスオペレーションに関する分析情報をほぼリアルタイムで取得できるようになりました。
季節限定のセールイベントなど、トラフィックが急増する期間でも、SLA の遵守率が 30% 向上しました。
ツールの統合と手動メンテナンスの削減により、運用コストが低下しました。

しかし、おそらく最も重要な改善点は、エンジニアが問題対応に費やす時間が減り、イノベーションに費やす時間が増えたことです。これにより、顧客やパートナーに価値をもたらす新しい分析機能を迅速にプロトタイピングできるようになりました。

断片化された環境から、一貫性のあるクラウドネイティブなプラットフォームに移行したことで、PayPal の分析機能は根本から強化されました。ビジネスニーズが進化するなか、スケーラブルで統合されたデータ基盤に投資することで、迅速かつ正確で、有益な分析情報を提供できるようになり、世界中のお客様に継続的なイノベーションをもたらすことができます。Managed Service for Apache Spark の導入は、最新の分析基盤を構築するうえで重要なステップでした。

Managed Service for Apache Spark と BigQuery を使用して、Agentic Data Cloud を構築する方法を今すぐご確認ください。

- PayPal、分析信頼性エンジニアリング担当ディレクター、Vinod Ganesan 氏

- PayPal、ビッグデータプラットフォームエンジニアリング担当シニアマネージャー、Raghu Agani 氏

AI 駆動で進める、クラウド移行と運用のこれから。AI-Ready Infra & DB Summit '26

Wed, 07 Oct 2026 02:00:00 +0000

こんにちは、Google Cloud Japan です。

AI がシステムを使うようになると、アクセスは昼夜を問わず増え、データには検索と生成の両方が求められます。AI を業務で使い続けるには、それに耐えるインフラとデータベースへの移行が欠かせません。

Google Cloud は 2026 年 10 月 16 日（金）に AI-Ready Infra & DB Summit '26 を開催します。最新のクラウド動向調査の結果を発表するほか、Google Cloud のインフラとデータベースの最新情報を、お客様の事例とともにお届けします。調査からコード移植までを AI 駆動で進めるクラウド移行の方法も、あわせて解説します。会場は Google 渋谷オフィスで、オンライン配信もあります。

▶ AI-Ready Infra & DB Summit '26 に申し込む

基調講演のテーマは「AI が使う基盤、AI で作る基盤」

基調講演には、ロッテホールディングスの橋本桂祐氏とマクロミルの宮坂雅輝氏をお迎えし、Google Cloud の安原稔貴とともに登壇いただきます。コンピュート、ネットワーク、ストレージ、データベースの各領域の最新情報とあわせて、既存の基盤をどこから見直すべきか、その道筋を示します。

お客様 4 社が、基盤づくりと移行の実例を紹介

お客様セッションには、業種も規模も異なる 4 社が登壇します。

GovTech 東京: 都民 1,400 万人が利用する東京都公式アプリ「東京アプリ」で、将来の利用拡大や AI 活用まで見据えて、後から変えにくい技術をどう選んだのかをお話しします。
ロッテ: データと AI の基盤づくりと重点ユースケースの創出を同時に進め、TAP (Tech Acceleation Program) を活用して事業部門と一体で内製開発を進める取り組みをお話しします。
マクロミル: クラウドコストとレガシー構成の保守リスクを抱えたアンケート配信システム「TRANS-AM」を、Google Cloud へ移管する計画を紹介します。
スタメン: 1,400 社、150 万ユーザーが使う TUNAG を、AWS から Google Cloud へ移行中です。AI Skills を使い、少人数で進める具体策をお話しします。

Google Cloud が、AI 駆動型の移行と運用のアプローチを紹介

Google Cloud のスペシャリストが、移行と運用の各工程での AI の使い方を、具体的な手順とあわせて解説します。

Gemini と Skills で進めるクラウド移行: 移行のノウハウを Skills にまとめて Gemini に読み込ませ、現行環境の調査からコード移植と差分検証まで進める方法です。実際に使った Skills と成果物をお見せします。
AI で進めるデータベース移行: 手間のかかる異種データベースへの移行で、AI が手作業をどこまで減らせるかを紹介します。
クラウドネットワークの見える化: 障害の原因がアプリかネットワークかを切り分ける手法を、AI を使ったトラブルシューティングとあわせて解説します。

このほか、Jagu'e'r によるパネルトーク、Datadog、GitLab、KDDI アイレットによるセッションも予定しています。

会場に来た方だけの特典も

渋谷の会場にお越しの方には、Google Cloud オリジナルの特典を用意しています。お渡しには条件があり、詳しくは当日ご案内します。終了後の懇親会にも、ぜひお立ち寄りください。

AI-Ready Infra & DB Summit '26 のイベントページからお申し込みください。

基盤を作る方も、運用する方も、移行を任された方も、会場とオンラインでお会いしましょう！

AI エージェントを現場実装する 2 日間、Agentic AI Summit '26 Fall

Wed, 07 Oct 2026 02:00:00 +0000

こんにちは、Google Cloud Japan です。

AI エージェントは、動くものを作るところまでは驚くほど早く進みます。難しいのはその先です。

エンジニアにとっては本番で任せられる品質の担保、情報システム部門にとってはセキュリティとガバナンス、事業部門にとっては全社への定着と成果づくりが次の課題になります。

Google Cloud は 2026 年 10 月 29 日（木）と 30 日（金）に Agentic AI Summit '26 Fall を開催し、それぞれの課題に取り組んできた企業の知見をお届けします。会場はベルサール渋谷ガーデンで、オンラインでも配信します。

▶ Agentic AI Summit '26 Fall に申し込む

Day 1 は全社展開の実例がそろう

初日は、Gemini Enterprise を中心に、AI エージェントを社内で使われる状態にするまでの進め方がテーマです。基調講演には三菱 UFJ 銀行をはじめ 2 社のお客様が登壇し、Gemini Enterprise を選んだ理由とその背景を語ります。

ブレイクアウトは全社展開の実例が中心です。

ソニー: 非エンジニア約 70 名の経営企画部門が、2 桁の業務アプリを本番稼働させるまでの記録です。定着や社内調整でのつまずきも語ります。
日本テレビ: 担当者の経験と勘に支えられてきた番組づくりに客観性を加え、「ヒットの再現性」を高める AI エージェント「ミカタッチAI」の取り組みです。
足立区: 議会答弁 AI エージェントの実装プロセスと、区民の声にすばやく応えるための取り組みです。

ほかにも、大阪ガスの内製 AI 駆動開発基盤や、営業担当に次の一手を届ける Hajimari のエージェント開発があります。そして、Googler Cloudのセッションでは、Tokenmics（適切なモデルを利用する際のコスト効率向上について）や、AI エージェントの統制とモデル選択を両立するエージェント基盤の設計、Microsoft 365 などの既存環境とつないで Gemini Enterprise を全社に定着させる進め方などがあります。

他社の事例を一気に見るならピッチコンテスト

Day 1 の 13:30 からは、第 6 回 AI エージェント事例アワードのピッチコンテストを開催します。生成 AI で自社の課題を解いたファイナリストが、その取り組みをステージで発表します。

ファイナリストは、KDDI アイレット、コクヨ、Contrea、千趣会、テレビ朝日、ベンチャーサポート税理士法人と SoLabo、三菱食品、Ubie の 8 チームです。

審査員には、次の 4 名を迎えます。

漆原茂氏（ULS コンサルティング株式会社取締役会長）
酒井真弓氏（ノンフィクションライター、Jagu'e'r アンバサダー）
深津貴之氏（株式会社 THE GUILD 代表取締役）
森正弥氏（株式会社博報堂 DY ホールディングス執行役員 Chief AI Officer）

MC は、PIVOT などで MC とプロデューサーを務め、J-WAVE のニュース情報番組「JAM THE PLANET」のパーソナリティとしても活躍する野嶋紗己子氏です。

アワードの詳細は AI エージェント事例アワードの開催概要をご覧ください。

Day 2 は丸ごとエンジニア向け

2 日目は、AI エージェントを構築、デプロイ、運用するための Google Cloud のプラットフォームを中心に、エージェント開発とバイブコーディングのセッションが並びます。

基調講演には Antigravity のエンジニアや、エージェント開発のエキスパートが登壇し、Sakana AI、荏原製作所、エイベックスがエージェントを現場で動かしている取り組みを話します。

ブレイクアウトは本番運用の話が中心です。

AI エージェントを本番に載せるアーキテクチャ設計: 同じ入力でも同じ答えが返るとは限らない相手を、どうテストし、どこでリリース可否を決めるか。複数エージェントの責任の境界、コストとレイテンシの制約まで扱います。
コロプラ: Agent2Agent プロトコル (A2A) の作法だけを接続境界に決め、各部署のエージェントを作り直さずに Agent Development Kit (ADK) 製のハブへつないだ全社基盤です。
損保ジャパン: 全自動エージェントをあえて捨て、人が承認する場所を設けて、実験サイクルを 1 週間から 1 日に縮めました。

ほかにも、ライブデモと agy teamwork まで紹介する Antigravity 徹底解説、メルカリの AI PDLC と TPU 活用、エージェントの推測を減らすデータ基盤の設計、Google Cloud のテクニカルサポートチームの AI 活用などがあります。

作って試すなら Builder Day

Day 2 には、参加型の Builder Day を並行開催します。90 分の座学の後、Google Cloud 上で Antigravity などを使い、AI エージェントやアプリを作るミニハッカソンに挑戦できます。

Google Cloud のデベロッパーリレーションズのメンバーがメンターにつきます。

定員制なので、参加希望の方は登録フォームで Builder Day への参加を忘れずに選択してください。

会場に来た方だけの特典も

各フロアのデモブースでは、最新の生成 AI 製品やお客様の事例に触れられます。現地参加の方には、抽選でオリジナル T シャツのプレゼントもあります。

エージェントを作る方も、守る方も、社内に広げる方も、渋谷の会場でも、オンラインでもお待ちしています！

▶ Agentic AI Summit '26 Fall に申し込む

AlloyDB がエージェント向け PostgreSQL を提供: ワークロードを完全に分離し、エージェント規模でリアルタイムデータを処理

Tue, 06 Oct 2026 18:10:00 +0000

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

ミッションクリティカルな運用データベースは企業にとってなくてはならないものであり、パフォーマンスの低下は許されません。しかし従来のアーキテクチャでは、わずか数個のエージェントが高密度の推論ループを実行しただけで、予測不可能なクエリのバーストが発生して簡単に過負荷状態に陥ります。

このたび、AlloyDB でエージェント向け PostgreSQL（プレビュー版）の提供を開始したことをお知らせいたします。これにより、ミッションクリティカルなシステムのパフォーマンスを損なうことなくリアルタイムのデータアクセスを行うことが可能になります。AlloyDB は、サンドボックス化されたデータベースインスタンスを数秒でプロビジョニングしてスケールすることでエージェントによる突発的なクエリの急増に対応し、ワークロードの完全な分離を可能にします。インスタンスはエージェントが終了すると自動的にスピンダウンするため、数個でも数百万個でも、エージェントをあらゆる規模で費用対効果よく実行できます。この発表による変更点は以下のとおりです。

AlloyDB に、秒単位で同期された本番環境の最新データに読み取り専用でアクセスできる数千のサーバーレスデータベースインスタンスへと PostgreSQL をスケールさせるように設計されたエージェント向けデータベースアーキテクチャが搭載されます。これらのインスタンスは常時、本番環境ワークロードがアクセスするプライマリ、スタンバイ、リードレプリカのインスタンスから完全に分離されています。
これらの各インスタンスは、Google が提供するエクサバイト規模の分散ストレージシステムである Colossus の統合ストレージレイヤを基盤とするデータベース内のリアルタイムデータにアクセスします。これにより、エージェントはミリ秒未満の I/O とテラビット/秒の集約スキャンスループットを実現し、秒間 300 万以上のクエリにも対応できます。
これらのインスタンスは完全な AlloyDB PostgreSQL エンジンを備え、すべてのインデックス、SQL の全機能、包括的なベクトル検索、全文検索、空間検索へのアクセスを提供します。さらに、複雑な ETL パイプラインを構築しなくても、エージェントは BigQuery と Spark を活用してレイクハウス分析を実行できます。
これらのインスタンスはエージェントがタスクを完了するとすぐにゼロへとスケールダウンされるため、料金はアクティブな推論ループに対してのみ発生し、クラウド費用を削減できます。

Google は、この AlloyDB for PostgreSQL により高度なベクトル演算、ML 推論、基盤モデルのインテグレーションを 100% PostgreSQL 互換のエンジンに直接組み込み、エージェント向けエンタープライズリレーショナルデータベースの分野における先駆けとなりました。AlloyDB for PostgreSQL は Google Cloud のセキュリティ機能と緊密に統合されており、静的パスワードに代わる IAM 認証の使用、VPC Service Controls を介したトラフィック分離、顧客管理の暗号化と監査の提供によりデータを保護します。この機能とエージェントアーキテクチャによるスケーラビリティを組み合わせて提供する AlloyDB は、エンタープライズグレードの優れたエージェント PostgreSQL サービスとなっています。

プレビュー版をご利用になるには、こちらからお申し込みください。

重要である理由

エージェントの時代となった今、企業による AI の使用方法は単一のコパイロットエージェントとのやり取りから、数百万のエージェントが同時に連携するネットワークへと急速に移行しています。これらのエージェントが一斉にクエリを実行してデータベースを操作すると、突発的なトラフィックの急増によってコアデータベースが過負荷に陥り、ビジネスを運営する基幹システムと競合してしまう可能性があります。

エージェントがワークフローを効率的に実行するためには、B ツリー、ベクトル、テキスト、空間の各インデックスを活用して、高度な分析とリアルタイムの本番データに対する低遅延アクセスの両方を実現する必要があります。新興のアーキテクチャはオブジェクトストレージの上に配置されたページキャッシュレイヤを使用しますが、これにはスケーリングと費用に関する課題があり、本番環境システムの安定性が損なわれる可能性があります。

加えて、分析のために本番環境のデータを解放すると運用アクセスにパフォーマンスのボトルネックが生じ、エージェントが本番環境にリリースされた瞬間からミッションクリティカルなデータベースがリスクにさらされるという、難しいトレードオフも発生します。これらは、データベースストレージに従来のオブジェクトストアを使用して問題を解決しようとするアプローチです。分析アクセスが可能になるので一部のエージェントはこれを役立てることができますが、基盤となるデータベースの処理速度が本番環境のワークロードに対して遅すぎ、I/O レイテンシが最大で 10 倍悪化します。ページキャッシュレイヤがあっても、一時しのぎ程度にしかなりません。キャッシュ自体の速度が依然として十分に速くないうえに、エージェントワークロードによって簡単に飽和してしまうスケーラビリティのボトルネックを抱えることになります。

アクティブなマルチエージェントシステムが高密度な推論サイクルを実行すると、高度に並列化された予測不可能なクエリのバーストが発生してこれらのキャッシュレイヤを圧倒し、ミッションクリティカルな本番環境システムが、エージェント起因のサービス停止に対して無防備な状態になります。その結果、このアーキテクチャでは運用ユースケースの全領域が実行不可能となり、企業はライブのエンタープライズデータが持つ、AI による変革の力をビジネスに活用する機会を失うことになります。

AlloyDB 独自の PostgreSQL エージェントアーキテクチャ

Google はこれとは異なるアプローチを採用しました。AlloyDB は、AI 時代に特化して設計されたエージェント向けデータベースアーキテクチャを提供し、4 つの主要な差別化機能を備えています。

人工的なボトルネックのない、1 ミリ秒未満の I/O レイテンシ: 業界をリードする AlloyDB のトランザクションおよびクエリ処理性能と、Google の地球規模の Colossus ストレージインフラストラクチャに支えられた低レイテンシのオブジェクトストレージが組み合わさったこのアーキテクチャは、エージェント向けの大規模な共有ストレージプレーンを提供します。ミリ秒未満の I/O と 1 秒あたり 1 テラビットを超える集計スキャン帯域幅を実現しているため、エージェントが最新の運用データに対して直接、集中的に読み取りクエリとベクトル検索を実行しても問題なく処理できます。
本番環境のワークロードから完全に分離しつつ、需要に合わせてスケーリング: AlloyDB は、最新の本番環境データに対してサンドボックス化されたデータベースインスタンスを数秒で動的にプロビジョニングすることでスケールします。エージェント同士が運用リソースを奪い合う従来のアーキテクチャとは異なり、エージェントデータベースコンピューティングはプライマリデータベースクラスタから完全に分離されています。そのため、エージェントが高密度で予測不可能な推論ループを実行しても本番環境のパフォーマンスが低下することはありません。これらの堅牢な安全ガードレールと、エンタープライズグレードのガバナンス、きめ細かいアクセス制御が組み合わさっているため、アクティブなエージェントループで分析クエリ、ベクトルクエリ、運用データのポイントルックアップをシームレスに組み合わせ、本番環境データに対して PostgreSQL の性能を制限なく最大限に活用することができます。
従量課金制: エージェントのアクティビティは一般的に、短時間のうちに大量のクエリが同時送信され、それが終わると非アクティブな期間が続くという特徴があります。このような急増に備えて専用のリードレプリカをプロビジョニングした場合、高価なインフラストラクチャを 24 時間体制で維持する必要があります。費用対効果の高い方法で大規模なエージェントグループをサポートし、プロビジョニングしたシステムがアイドル状態のままでコンピューティングオーバーヘッドを発生させることを避けられるよう、エージェント AlloyDB インスタンスは迅速にスケールして秒間数百万のクエリに対応できます。また、柔軟な従量課金制の料金モデルによって自動的にゼロへとスケールさせることができます。
ETL 不要のネイティブレイクハウス統合: 本番環境データはすべて、Google Cloud のボーダーレスレイクハウスとネイティブに統合されます。そのため、エージェントは BigQuery と Lightning Engine for Apache Spark に対して連携クエリを実行し、大規模なレイクハウスデータセットと、AlloyDB の秒単位で更新される最新のトランザクションデータを結合できます。これにより、壊れやすいバッチ ETL パイプラインを構築して維持する必要がなくなり、自律型エージェントは最新の運用状態と、レイクハウスに格納されている過去のコンテキストデータの両方に即座にアクセスできます。

「サプライチェーンの自律性が高まるにつれ、当社のプラットフォームでは、数千もの施設にわたる複雑な物流ワークフローを調整するリアルタイムのトランザクションインテリジェンスが欠かせなくなっています。AlloyDB の新しいエージェント向け PostgreSQL アーキテクチャは、当社にとって大きな転機となりました。現在では、コアのトランザクション処理には一切影響を及ぼすことなく、同時に連携して動作するエージェントのネットワークをデプロイし、在庫データや注文データを 1 秒未満の鮮度で分析できるようになっています。このアーキテクチャにより、次世代のエンタープライズサプライチェーン AI を支えるために必要な分離、スピード、費用対効果を実現できました。」 - Manhattan Associates、エグゼクティブバイスプレジデント兼最高技術責任者、Sanjeev Siotia 氏

提供状況

AlloyDB の PostgreSQL for Agents は現在、プレビュー版としてご利用いただけます。

詳細については、ドキュメントページをご覧ください。ご利用を開始するには、こちらからお申し込みください。

Google Cloud パートナー、Gemini Enterprise を活用して新たなセキュリティエージェントと AI 防御機能を提供

Tue, 06 Oct 2026 18:00:00 +0000

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

脅威アクターが AI を利用してサイバー攻撃を加速、開発するケースが増えるなか、企業の防御者は AI と、防御者にとって重要な強みである「自社だけが持つビジネスコンテキスト」の両方を活用する必要があります。

企業のサイバー防御は、ID、ネットワーク、エンドポイント、データ、クラウド、アプリケーションの各レイヤにまたがっており、多くの場合、12 種類以上のプロダクトに分散し、それぞれが独自のコンテキストを持っています。Google Cloud Next では、パートナーが構築したエージェントを Gemini Enterprise に組み込み、セールス、コンテンツおよびクリエイティブワークフロー、人事、セキュリティなどの機能にわたり、専門エージェントを 1 か所で検出してデプロイできるようにしました。

このたび、Gemini Enterprise エコシステムでパートナーが構築したセキュリティサービスカタログを拡充し、単一の統合インターフェースからセキュリティコンテキストを最大限に活用できるようにいたしました。

主要なサイバーセキュリティベンダーが提供するこれらの新たなセキュリティエージェントとインテグレーションは、チームが Gemini Enterprise で直接呼び出すパートナー製セキュリティエージェントと、AI およびエージェント型ワークロードの保護という 2 つの領域にわたっています。これらを Gemini Enterprise に組み込むことにより、Gemini Enterprise 環境で直接、複数ステップのセキュリティワークフローをオーケストレーションできるようになり、AI を活用した機能を防御に取り入れることが可能になります。

Gemini Enterprise で構築された、新たなセキュリティエージェントとエージェント型防御のご紹介

Acalvio: Gemini Enterprise からアクセスできる Acalvio ShadowPlex ディセプションエージェントは、企業ネットワーク全体へのデコイとハニートークンのデプロイを自動化し、ディセプションガードレールを顧客の運用環境に直接埋め込みます。手動での構成は不要です。ShadowPlex は、ネットワークデコイ、ID ハニーアカウント、検索拡張生成（RAG）デコイ、ハニースキル、ハニートークンを大規模にデプロイし、不正なインタラクションを迅速に捕捉します。

Britive: Gemini Enterprise を基盤とする Britive Emergency Termination Agent を使用すると、セキュリティチームは複数のコンソールを操作することなく、単一の自然言語リクエストから、侵害された人間または人間以外の ID を封じ込めることができます。このエージェントは、ID を確認し、アクティブな特権セッションをすべて一覧表示して、人間の承認を得てすべてのセッションを取り消し、ID を無効にして、インシデントチケットの監査コンテキストを収集します。その結果、エージェントの厳格なガバナンスと最小権限アクセスを維持しながら、封じ込めまでの平均時間（MTTC）を大幅に短縮できます。

Check Point: Google Cloud Agent Gateway および Agent Registry と統合された Check Point AI Defense Plane は、エンタープライズ規模の AI で必要とされる重要なセキュリティ管理と可視性を提供します。組織は、AI ワークロードの検出、リスクポスチャーのモニタリング、コンプライアンスに違反する動作の検出に加えて、プロンプトインジェクション、データ漏洩、エージェントの不正な挙動に対するリアルタイムのガードレールの適用が可能になります。Gemini Enterprise 内の Check Point Agent を通じて管理されるこの統合ソリューションは、Gemini Enterprise での AI ワークロードのデプロイを保護し、高速化します。

CrowdStrike: CrowdStrike Falcon® Guardian は、Agent Gateway と統合することでガードレールとランタイム保護を拡張し、Gemini Enterprise で実行されるエージェント型ワークロードをプロンプトインジェクション、機密データの漏洩、悪意のある AI アクティビティなどのリスクから保護します。さらに、CrowdStrike Gemini Enterprise エージェントにより、実務担当者は Gemini Enterprise を通じて CrowdStrike プラットフォームを操作できます。これにより、CrowdStrike のセキュリティコンテキストをエージェント型の調査と対応に組み込み、多数のツールにわたる SOC ワークフローのオーケストレーションを支援します。

Cyberhaven: Cyberhaven Linea エージェントは、エンドポイント、クラウドアプリ、エージェント型ワークフロー全体にわたる機密データの検出と分類を Gemini Enterprise で可能にします。Cyberhaven のデータリネージモデルを活用したこのエージェントは、平易な言葉で表現された意図を適用可能なポリシーに変換し、インタラクションをモニタリングして、マッピングされていないリスクを侵害が発生する前に捕捉します。また、証拠の自動収集により調査が迅速化します。Gemini Enterprise の Antigravity 全体にわたり、Linea エージェントはアラート疲れを解消し、自律型エージェントが機密性の高いアセットを移動するのと同じ速さでセキュリティチームがそれらを保護できるようにします。

Cyera: Gemini Enterprise を基盤とする Cyera Agent Guardian は、Gemini で実行されるエージェントを保護し、データセキュリティポスチャー管理（DSPM）とデータ損失防止（DLP）を提供します。Cyera エージェントは、マシン ID、委任された権限、機密データの分類を相互に関連付け、承認されたエージェント型の動作を検証できるため、組織はエージェントを安全にデプロイし、エンタープライズ規模で運用コンプライアンスを維持できます。

Endor Labs: Endor Labs AURI エージェントは、デベロッパーとセキュリティのワークフロー全体に AI ネイティブのアプリケーションセキュリティをもたらします。同社の静的アプリケーションセキュリティテスト（SAST）トリアージエージェントは、Google Antigravity などのデベロッパープラットフォーム内でコードから検出された問題を自動的に分類し、優先順位を付けることができます。Gemini Enterprise では、セキュリティチームはこれらの検出結果を会話形式でクエリして対応できます。実際に悪用可能なものを確認し、修正を追跡することが可能で、そのすべてが Endor Labs アプリケーションのコンテキストに基づいています。

Exabeam: Exabeam は、Gemini Enterprise を基盤とする次世代の Exabeam Nova を導入しています。これは、セキュリティチームが脅威をより迅速に調査して対応できるようにする、統合マルチエージェント AI システムです。Nova は、ワークフロー全体で共有されている運用コンテキストを維持しながら、行動の分析、リスクの優先順位付け、調査の実施、対応アクションの誘導を行うことができる、専門の AI エージェントと連携します。その結果、アナリストはよりインテリジェントで効率的なエクスペリエンスを得ることができ、組織は既存のセキュリティ運用環境からより大きな価値を引き出すことができます。

Fastly: Fastly Autonomous Edge Defense Agent（AEDA）を使用すると、セキュリティチームは Gemini Enterprise 内で、ログを手動で解析する代わりに、エッジやインフラストラクチャのインシデントを平易な言葉で調査できます。AEDA は、組織独自のテレメトリーと Fastly のグローバルな顧客ベースから得た匿名化されたインテリジェンスを組み合わせ、異常は単発的なものなのか、より広範な攻撃の一部なのかを数秒で判断し、証拠に裏付けられた調査結果と推奨される修正策を返します。

Fortinet: Fortinet FortiAIGate は、Google Cloud のお客様に大規模言語モデル（LLM）のランタイム保護を提供します。Gemini Enterprise と統合され、Google Cloud 環境にデプロイされた FortiAIGate は、組織が高度なエージェント型 AI アプリケーションをデプロイできるよう支援します。これにより、データ、プロンプト、モデルとのインタラクションを新たな脅威から積極的に保護できます。

Menlo Security: Gemini を使用して構築された HEAT Shield Agent は、ウェブコンテンツを分析し、実行時にゼロデイ脅威やプロンプトインジェクションをブロックします。これに加えて、Gemini Enterprise を基盤とする Menlo Security Orchestrator が、セキュリティオペレーションセンター（SOC）のレスポンスを自然言語によるエージェント型ワークフローに変換します。これは、攻撃の再構築、影響範囲の特定、ポリシーの適用を、数時間ではなく数秒で行うことができます。Menlo Agent Runtime Security（MARS）は、このループを完結させ、人間とエージェントおよびエージェント同士のインタラクションを保護することで、エージェント型ワークロード全体で検出と封じ込めが統合された状態を維持します。

Obsidian Security: Gemini Enterprise で Obsidian Security の Risk Analyzer エージェントと Breach Response エージェントを使用すると、セキュリティアナリストはリスクを評価し、侵害に対応できるようになります。組織のクラウドと AI ネイティブアプリケーションポートフォリオを保護するために構築された Obsidian エージェントは、企業環境全体にわたり AI エージェントを検出し、リスクを評価して、ガバナンスのギャップを報告します。また、どのエージェントが昇格された権限や書き込みアクセス権を持っているかといった重要な質問に答えます。

Palo Alto Networks: Palo Alto Networks のクラウド、ネットワーク、AI リスク評価（CLARA）エージェントは、開発のペースを落とすことなく、重要なデータとコンプライアンスを確保した AI 運用を保護できるよう、セキュリティチームを支援します。クラウドインフラストラクチャと AI ワークロードを継続的にスキャンし、隠れた脆弱性を自動的に検出して修正の優先順位を付けることで、クラウドや AI のリスクが侵害に発展する前に発見して修正できます。これにより、セキュリティチームは脅威の検出に費やす時間を減らし、脅威の解消により多くの時間を費やすことができるようになります。

Ping Identity: Gemini Enterprise で利用可能になった Ping Identity の新しい PingID セルフサービスエージェントを使用すると、従業員は多要素認証（MFA）のリセットやデバイスの復元など、ID やデバイスに関する一般的な問題を自然言語で質問して解決できます。ヘルプデスクのチケットは不要です。PingOne を基盤とする、セキュアな委任認証を備えた PingID セルフサービスエージェントは、従業員の ID を管理するためのエンタープライズ対応の手段を IT チームに提供すると同時に、サポート費用の削減とオンボーディングエクスペリエンスの向上を実現します。

Qualys: Qualys ROCky for Gemini Enterprise は、セキュリティチームが Gemini Enterprise 内で会話を使用して脆弱性を管理し、パッチを適用するのに役立ちます。「Log4Shell の影響はどの程度か」、「まず何を修正すべきか」、「CISA KEV の期限を守れているか」といった質問をすると、Qualys TruRisk スコアに基づいてランク付けされた回答が得られます。各ユーザーが所有する Qualys の利用資格に基づいて動作するため、誰でもサポートなしで自ら回答を得ることができます。また、パッチのステージングとデプロイも行えます。

Splunk（Cisco 傘下）: Gemini Enterprise と統合された Splunk Security AI エージェントは、膨大なテレメトリーストリームをセキュリティデータとオブザーバビリティデータ全体にわたるリアルタイムインテリジェンスに変換する自律システムとして機能します。手動によるトリアージを省略して、重大な異常やシステム脅威を即座に表面化させることで、チームは事後対応型の調査からプロアクティブな防御へと転換できます。これにより、プレッシャーの大きなインシデント発生時の認知負荷が軽減され、セキュリティチームはリスクをより迅速に解決できるようになります。

Synk: Gemini Enterprise と Antigravity を使用して構築しているすべての企業が、かつてない速さでコードをリリースしています。Snyk は、コードが作成された後ではなく作成されたその瞬間から、コードがセキュアであることを保証します。Snyk は、AI エージェントが生成したものをリアルタイムで検証し、脆弱性やセキュアでない依存関係がリポジトリに到達する前に検出します。これは、AI がコードを記述する速度に合わせて構築されたセキュリティです。人がかつて記述していた速度に合わせたものではありません。

Thales: Gemini Enterprise と統合された Thales AI Security Fabric は、エージェント型 AI のインタラクション全体にわたって可視性、ランタイム保護、一元化されたガバナンスを提供します。組織は、エージェント型 AI を試験運用から本稼働に移行し、きめ細かなアクセスポリシーを適用して、重要なデータアセットを実行環境で直接保護できます。

Transmit Security: Gemini Enterprise を基盤として構築された Transmit Security Agent Intelligence は、顧客向けアプリケーションとやり取りを行うエージェント型アクティビティを特定します。ユーザーがタスク、トランザクション、権限を AI エージェントに委任することが増えるにつれ、組織は、そのアクティビティの内容、発生元、意図を明確に把握する必要があります。こうしたコンテキストを把握することで、企業は正常なエージェントと悪意のあるエージェントを見分け、許可すべきものとブロックすべきものを判断し、正当な取引を制限することなくリスクを未然に防ぐことができます。

Zscaler: Zscaler Risk360 は、既存の Zscaler のデプロイからデータを取り込み、サイバーリスクを定量化し、リスクポスチャーの詳細なビューを作成して、リスクを軽減するための明確な分析情報を提示する、包括的かつ実用的なフレームワークを提供します。Risk360 Agent は、Gemini Enterprise を使用した ZAgent フレームワーク上に構築された AI 搭載コンパニオンです。自然言語によるやり取りを使用して、Zscaler とパートナーからのシグナルの統合、ゼロトラストリスクの分析、財務的影響の定量化、緩和策の推奨、意思決定に役立つ分析情報を提供します。

パートナーが構築したエージェントやコネクタのエコシステムが拡大する中、Gemini Enterprise は、お客様がすでに利用しているセキュリティツールと連携し、それらを基盤としてカスタムエージェント型ワークフローを構築できるようにします。Google Cloud Marketplace で、現在利用可能なセキュリティエージェントを今すぐご確認ください。

- セキュリティおよび ID パートナーシップ担当ディレクター、Vineet Bhan

- セキュリティ担当パートナーエンジニアリング責任者、Ashish Verma

エージェントの時代における妥協のない新しいデータベースアーキテクチャ

Tue, 06 Oct 2026 18:00:00 +0000

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

データベースエンジニアはキャリア全体を通して、ある 1 つの課題に取り組んできました。それは、データを保持する記録システムの信頼性を損なうことなく、OLTP ワークロードをどのようにスケールするかということです。

Exadata は、データベース下部のスケールアウトストレージ階層にクエリをオフロードすることで、ネットワークのボトルネックを排除し、この課題を解決しました。Azure SQL Hyperscale は、共有ブロックサーバーを使用して、数十のリードレプリカにスケールアウトしました。Aurora は、ログの適用処理を分散ストレージノードにオフロードし、複数の PostgreSQL ノードにわたる読み取り処理のスケーリングを実現しました。一方、新しいアーキテクチャでは、従来のオブジェクトストレージにデータを永続化し、その手前にプロビジョニングされたキャッシュ階層を配置しています。これにより、ホットデータのレイテンシは抑制できるものの、キャッシュミスが発生するたびに長いレイテンシが発生します。

これらのアーキテクチャはどれも、スケール、レイテンシ、分離という 3 つの特性のうち、少なくとも 1 つ、場合によっては 2 つの制約を本質的に抱えています。たとえば、共有ブロックサーバー上に構築されたアーキテクチャでは、ブロックサーバーで I/O が必然的にボトルネックになるため、スケーラビリティが損なわれます。また、レプリケーショントラフィックが急増するたびに本番環境のワークロードがスロットリングされるため、分離も損なわれます。

こうしたトレードオフの中には、設計当初は実際に妥当だったものもあり、40 年間にわたってエンタープライズデータベースワークロードの要件を満たしてきました。しかし、エージェントの時代においては、このような妥協はもはや通用しません。エージェントワークロードは動的に生成されるため、事前に検証することはできません。そのため、ミッションクリティカルなシステムから分離することが、ビジネスの継続性を確保するうえで不可欠です。エージェントワークロードは、データベースエンジンとそのすべてのインデックスの能力を最大限に活用して初めて実現できる低レイテンシを必要とします。同時に、単一のデータベースでは前例のない、まったく新しいレベルの弾力的なスケーリングも求められます。具体的には、単一のデータベースに対して数秒以内に 1,000 個のコンピューティングノードを要求し、1 分以内に処理を終了するような、エージェントのバーストに対応できるスケーリングです。

真のエージェント型データベースアーキテクチャに必要な 3 つの原則

エージェントの時代には、3 つの基本原則によって定義される新しいエージェント型データベースアーキテクチャが必要であると Google は考えています。エージェント型データベースアーキテクチャがその真価を発揮するには、これら 3 つの条件すべてを満たすことが不可欠です。

原則: 分離 - 設計レベルでの分離でありながら、リアルタイムなデータアクセスを実現。エージェントは、プライマリクラスタとデータベースコンポーネントを共有しないデータパスを介して、1 秒未満の更新頻度で本番環境のライブデータを読み取る必要があります。リアルタイムとは、古いコピーやブランチではなく、秒単位で更新される最新のデータを意味します。これは割り当てではなく、物理的な分離です。リソースを共有するということは、運命を共にすることを意味するからです。その境界線はストレージレイヤまで達しているため、設計レベルでリソースの競合を排除しています。
原則: レイテンシ - 1 ミリ秒未満のベースライン I/O。運用ワークロードでは 1 ミリ秒未満のブロック I/O が求められますが、エージェントでもその基準は変わりません。コンピューティングノードは DRAM とローカル SSD を利用して高速化を実現していますが、キャッシュミスが発生してリモートストレージへアクセスする場合であっても、アプリケーションかエージェントかを問わず、1 ミリ秒未満で処理を完了できるストレージ設計が求められます。パフォーマンスが桁違いに低下するアーキテクチャは、エージェントにとって根本的に使い物になりません。
原則: スケール - エージェントスケールのコンピューティングと I/O。エージェントのスケールは、瞬発的かつ一時的でありながら、極めて大規模という特徴を同時に持ちます。データベースコンピューティングノードは、数秒でのスピンアップ、数千台へのスケール、短時間でのバースト実行、エージェントの処理終了後の自動的なゼロへのスピンダウンを行う必要があります。本番環境に一切影響を与えずに、データベースのコンピューティングと I/O を数千ノード規模へ即座にスケールさせることは、従来のデータベースの常識では不可能なことでした。エージェントの動的な性質を考えると、コンピューティング、ストレージ I/O、その間にあるキャッシュ階層にいたるまで、スタック全体における事前プロビジョニングは現実的ではありません。

重要なのは、エージェントアーキテクチャは、これら 3 つの原則をすべて同時に満たす必要があるということです。こうしたアーキテクチャにより、エージェントは本番環境の安定性を損なうことなく、ライブ運用データ、つまり企業の実体に直接アクセスして処理を行うことができます。その結果、以下のような劇的な変化がもたらされます。

連動障害がない: ビジネスを運営するエンジンと、その上で推論を行うエージェントフリートが完全に分離されているため、エージェントが本番環境に影響を与える経路が排除されます。
容量予測が不要: 真の弾力性により、予測不可能なエージェントの急増に備えて事前プロビジョニングを行う煩わしさが解消されます。
セマンティクスの妥協がない: エージェントに対して制限される機能はありません。すべての推論ステップにおいて、リレーショナル SQL、ハイブリッド検索（ベクトル、全文、空間）、そしてインデックスの機能を最大限に活用できます。

AlloyDB のエージェントアーキテクチャ

AlloyDB の新しいエージェント型データベースアーキテクチャは、これら 3 つの原則をすべて満たす初のシステムです。Google は、ストレージ、ネットワーク、コンピューティング、データベースにわたって、これをゼロから構築し、以下を実現しました。

分離によって設計レベルでの障害の連鎖を回避: トランザクション本番環境クラスタは、エージェントワークロードから完全に分離され、事前プロビジョニングされた専用インフラストラクチャ上で実行されます。エージェントは、Model Context Protocol（MCP）を介して、本番環境とは別の専用の Colossus ストレージセグメントから直接読み取る、マイクロ VM ベースの AlloyDB ノードの独立したエフェメラルプールに接続します。
予測可能な 1 ミリ秒未満のストレージ I/O: すべてのストレージ読み取りは、Google の Colossus ストレージシステムによって直接処理され、1 ミリ秒未満のベースラインレイテンシを継承します。これにより、コールドキャッシュミスによるパフォーマンスの急激な低下がなくなります。
ゼロから数千ノードへの真のコンピューティングスケーリング: エージェントプールは、エージェントアクティビティのバーストに対応して、ゼロから数千のノードへと迅速にスケールアップし、タスクが完了した瞬間にゼロにスケールダウンします。

エージェントは、1 秒未満の更新頻度で本番環境データをクエリし、PostgreSQL エンジンのすべての機能（ポイント検索、インデックストラバーサル、ベクトル、全文検索、空間検索、カラム型スキャン、レイクハウス全体の連携クエリ）を駆使して、推論ループを強化できます。

エージェント向け AlloyDB PostgreSQL のプレビューに参加して、データの規模を問わず本番環境データ上でエージェントを実行しましょう。その全機能について詳しくは、関連するお知らせのブログ記事をご覧ください。

既存のアーキテクチャが 3 つの原則をすべて満たせない理由

従来型および新興の運用データベースは、3 つのアーキテクチャパラダイムのいずれかを採用することでスケーリングを図っています。自律型 AI エージェントの要件に照らして評価すると、どのパラダイムにも構造上の根本的な限界があり、3 つの原則を同時に満たすことは不可能です。

独立したレプリカ（シェアードナッシングストレージ）

従来のリレーショナルアーキテクチャでは、プライマリインスタンスから専用のレプリカデータベースにレプリケーションログをストリーミングすることで読み取りをスケールします。各レプリカデータベースは、それぞれ専用のローカルストレージまたはアタッチされたブロックストレージを備えています。これは「原則: 分離」を満たしています。つまりレプリカはプライマリクラスタと物理リソースを共有せず、継続的なログレプリケーションにより、準リアルタイムの最新性が維持されます。また、「原則: レイテンシ」も満たしています。専用のローカルストレージにより、予測可能な 1 ミリ秒未満の読み取りレイテンシが保証されます。しかし、「原則: スケーリング」は満たしていません。スケーリングには、新しいレプリカをプロビジョニングし、数百ギガバイトまたはテラバイトのストレージをリハイドレーションする必要があります。これらすべての処理には数時間かかります。これでは、秒単位で発生するエージェントの爆発的な推論バーストには対応できません。さらに、静的にプロビジョニングされたコンピューティングとストレージは、エージェントの実行が完了した後も、アイドル状態でコストが発生し続けます。

分離された共有ストレージサーバー

2 つ目のアプローチは、ステートレスコンピューティングノードを、永続性とレプリケーションを管理し、ブロック書き込みをオフロードする可能性のあるカスタムストレージサーバーの共有マルチテナント階層から切り離すことです。このアプローチは、「原則: レイテンシ」を満たします。最適化されたストレージサーバーへの読み取りアクセスは、常に安定した低いレイテンシで処理されます。しかし、「原則: 分離」は満たしていません。すべてのレプリカがプライマリと同じサーバーから読み取るため、エージェント I/O が本番環境 I/O と直接競合し、障害の連鎖のリスクが生じるためです。また、「原則: スケール」も満たしていません。データがコピーされないため、ステートレスコンピューティングレプリカは迅速にスピンアップするものの、ストレージ I/O の合計帯域幅が、事前にプロビジョニングされたストレージ階層の容量に制限されるためです。基盤となる I/O 容量をスケールせずにコンピューティングノードを追加しても、ストレージの処理能力が飽和し、スロットリングを加速させるだけです。

共有ブロックサーバーを使用したオブジェクトストレージ

3 つ目の新しいアプローチは、汎用オブジェクトストレージでデータの耐久性を確保し、ブロックサーバーの共有階層からブロック読み取りを行うというものです。オブジェクトストレージからのランダム読み取りには数十ミリ秒かかります。これは従来のデータベースストレージより桁違いに遅く、少なくとも 25 年前のエンタープライズ向けディスクアレイと比べてもさらに遅いレベルです。そのため、ブロックサーバーにホットデータを保持させることで、低レイテンシでのデータ提供を実現しています。このアプローチは、「原則: レイテンシ」を満たしますが、1 つ注意点があります。それは、ブロックサーバーでキャッシュミスが起きると、許容できないほど高いレイテンシでオブジェクトストレージまでフォールバックが発生してしまう点です。一方で、「原則: 分離」を満たしていません。レプリカは本番環境とブロックサーバーを共有しているためです。エージェント I/O と本番環境 I/O は同じ処理容量を使用します。そのため、その容量が枯渇したりスロットリングされたりすると、エージェントだけでなく本番環境にも影響が及びます。また、共有ストレージサーバーと同じ理由で、「原則: スケール」も満たしていません。レプリカはすぐに起動しますが、ブロックサーバーがバーストに合わせて I/O をスケールしないためです。

このファミリーの一部のアーキテクチャでは、Apache Spark などの分析エンジンがデータベースエンジンをバイパスして、基盤となるオブジェクトストレージを直接読み取ることもできます。分析ワークロードの場合、これは価値があり、十分に現実的なアプローチです。しかし、エージェントには低レイテンシの検索が不可欠です。インデックス、ポイント検索、ベクトル検索を排除すると、ブルートフォーステーブルスキャンが余儀なく行われ、レイテンシが急増し、エージェントが検索と推論のループを実行できなくなります。

既存アーキテクチャの評価

Google は、共有ブロックサーバーを備えたオブジェクトストレージアーキテクチャを使用する市販のサービスを対象に、スケーリングの限界と本番環境の分離の両方を検証する評価を行いました。利用可能な DRAM よりも大きなデータセットに対して、同時にインデックス検索を実行しました。1 つのリーダーインスタンスから始めて、最大 8 つのリードレプリカを追加してワークロードをスケールしました。

物理リソースを共有するアーキテクチャでは、リードレプリカを追加してエージェントをスケールすると、レプリカとプライマリの両方のパフォーマンスが急速に低下します。以下のグラフに示すように、Google のテストでは、レプリカを追加してもスループットの増加は 2 倍未満にとどまりました。レプリカ 4 台でピークに達した後、共有ブロックサーバーの帯域幅が飽和状態になると、スループットは低下しました。

プライマリデータベースへの影響は即座に、かつ深刻な形で現れました。レプリカが追加されると、プライマリのスループットは 75% 以上も急落したのです。

つまり、従来型と新興型のどちらのアーキテクチャも、エージェントが求める規模に対応できないということです。本番環境システムの安定性を損なうことなくそれを実現することは、到底不可能です。

原則に基づく評価

* 部分的に対応: ホットデータはブロックサーバーから低レイテンシで提供されますが、ブロックサーバーでキャッシュミスが発生すると、オブジェクトストレージへのアクセスが生じて数十ミリ秒のレイテンシが発生します。

いずれの場合も、この課題は構造的なものであり、単にチューニングで解決できる問題ではありません。レプリケーションは、各レプリカに専用ストレージを割り当てることで分離を実現します。そのため、そのストレージへのデータ同期にかかる時間よりも短い時間でレプリカを追加することはできません。共有ストレージサーバーは、ストレージを共有することでコンピューティングを迅速に追加できますが、I/O を分離することもスケールすることもできません。オブジェクトストレージ上のブロックサーバーは、プロビジョニングされた階層でレイテンシを抑制できるものの、分離もバーストもできず、キャッシュミスが発生するたびにオブジェクトストレージへのアクセスが生じてしまいます。どのアプローチも、あるレイヤで問題を解決したとしても、別のレイヤでその代償を払うことになります。3 つの原則をすべて同時に満たすには、コンピューティング、ネットワーク、ストレージにわたるデータベースアーキテクチャを再考する必要があります。

AlloyDB をスタック全体でどのように構築したか

AlloyDB のエージェント型データベースアーキテクチャは、Google のデータ、AI、インフラストラクチャスタック（AI モデル、データベースエンジン、および分析エンジン、さらにはストレージ、ネットワーキング、コンピューティングインフラストラクチャ）全体にわたって垂直統合されています。

ストレージ: 基盤としての Colossus

永続レイヤでは、AlloyDB は Google のエクサバイト規模の分散ストレージシステムである Colossus を基盤としています。Colossus は、Google 検索、YouTube、Gmail、Google ドライブ、Spanner、Bigtable を支えています。1 つの Colossus クラスタは、エクサバイト規模のストレージと数万台のマシンにスケールします。Spanner では、Colossus 上に直接構築されたトランザクションデータベースが数千ノードまでスケールできることを実証しました。新しい AlloyDB アーキテクチャは、同じ基盤を新たな課題、すなわちエージェントに適用します。

Colossus には、AlloyDB がこれら 3 つの原則を満たすための、3 つの特性があります。

1 ミリ秒未満の直接 I/O: Colossus は、読み取りレイテンシを最小限に抑えるように設計されています。Colossus ストリームを開くデータベースノードは、データが物理的に存在する場所を記述したハンドルを受け取ります。承認とメタデータの解決は、ストリームの作成時に 1 回しか行われません。それ以降の読み取りはすべて、最適化されたネットワークプロトコルを介して、データを保持するディスクに対して直接行われます。その結果、データベースのすべてのデータで 1 ミリ秒未満のレイテンシが実現します。ウォームアップする中間層も、キャッシュミスを起こすような層もありません。
圧倒的なスループット: Colossus は、帯域幅をプロビジョニングする必要がなく、同時ホスト数に制限がないため、単一の AlloyDB データベースに対して最大 15 TB/秒の総スループットと 2,000 万の秒間クエリ数を実現します。Colossus のスケールから見れば、AlloyDB エージェントノードのフリートがもたらす負荷は、ストレージのサイズ調整が必要になるようなものではありません。それは、このストレージがすでに処理している負荷のごく一部にすぎないからです。
物理セグメントのパーティショニング: AlloyDB は、本番とは別の Colossus セグメントからエージェントにサービスを提供するため、エージェントの I/O が本番環境のデータパスと競合することはなく、意図的に本番環境のデータパスから分散されます。

コンピューティング、ネットワーク、ストレージのいずれのデータパスにおいても、エージェントがデータベースコンポーネントを本番環境と共有することはありません。

ネットワーク: Jupiter によるスケーラブルな帯域幅

コンピューティングとストレージは、Google の大容量データセンターネットワークである Jupiter によって結び付けられています。1 つの Jupiter ファブリックが 10 万台以上のサーバーを 13 ペタビット/秒の二分割帯域幅で接続します。これは、地球上のすべての人がビデオ通話を行うのに十分な帯域幅です。

Jupiter は、ネットワーキングファブリック全体で予測可能な低レイテンシと高い二分割帯域幅を提供します。そのため、エージェントノードをクラスタ内のどこにでも柔軟に配置でき、一元化されたストレージに常にアクセスできます。エージェントプールがゼロから数千ノード規模にスケールするにつれて、基盤となる相互接続の容量が、配置上のボトルネックを発生させることなく、増大するトラフィックを吸収します。

コンピューティング: 柔軟でサーバーレスな PostgreSQL と分析

コンピューティングレイヤでは、エージェントが MCP を介して AlloyDB のエージェントプールに接続します。エージェントプールを構成する AlloyDB エージェントノードは、データベースの秒単位の最新状態に、読み取り専用でアクセスできます。このレイヤは、以下の機能を提供します。

マイクロ VM 分離: 各エージェントノードは、軽量かつセキュアなマイクロ VM 内で実行される、完全に機能する AlloyDB for PostgreSQL データベースエンジンです。これらのインスタンスは、互いに完全に分離されており、専用のプライマリクラスタからも分離されています。
迅速なスピンアップとスケーリング: エージェントノードは、エージェントからのリクエストに応じてプロビジョニングされ、エージェントが処理を終了すると自動的に停止します。バーストが発生すると、AlloyDB は数千のエージェントノードを迅速にプロビジョニングし、数百万の同時エージェントにサービスを提供します。エージェントが処理を終了すると、それらを解放します。課金はエージェントノードのアクティビティの秒単位で行われるため、1,000 個のノードを数十秒間使用するバーストでは、ジョブが消費したリソースに対してのみ課金され、それ以上のコストは発生しません。

一方、本番環境クラスタは、専用インフラストラクチャ上に事前プロビジョニングされ、記録システムに合わせてサイジングされた、従来通りの状態のまま維持されます。エージェントノードは Colossus から直接データを読み取るため、1 秒未満の更新頻度で、一貫した本番環境のデータを参照できます。

エージェントプール以外にも、BigQuery と Spark は本番環境クラスタから同じように分離された Colossus から AlloyDB データを読み取ることができるため、エージェントは Lakehouse Federation を使用して、リアルタイムの運用データを大規模な Lakehouse データセットと結合できます。

AlloyDB の新しいエージェントデータベースアーキテクチャは、Google 規模のストレージ、ネットワーク、コンピューティングレイヤを基盤とすることで、際立った目標を達成しています。それは「データのみを共有し、それ以外は何一つ共有しない」という目標です。

AlloyDB のエージェント型データベースアーキテクチャの評価

Google は、利用可能な DRAM よりも大きなデータセットに対して同時インデックス検索を実行し、フルスタック全体におけるスケーラビリティを検証することで、AlloyDB の性能を評価しました。エージェントワークロードを、単一のエージェントノード（従来のリードレプリカではなく、エージェントプール内の独立したデータベースインスタンス）から開始し、単一のデータベース上で数千ノードまで動的にスケールしました。その際、エージェント全体の合計スループットと、本番環境への影響を測定しました。

このテストでは、エージェントノードを 1 つから 10 個に増やすと、スループットが 3,900 QPS から 4.1 万 QPS へとほぼ完全に比例して向上しました。さらに 2 桁上（100倍）の規模までスケールさせても、最大 1,000 ノードに達するまで、ほぼ完全に比例したパフォーマンスが得られました。Google は、以下を確認しました。

プライマリのパフォーマンス低下ゼロ: エージェントノードを 1 から 1,000 にスケールしても、プライマリクラスタのパフォーマンスに測定可能な影響は生じませんでした。
膨大なスループット: 合計スループットが動的に 773 倍の 300 万 QPS にスケールされ、1,000 台のコンピューティングノードにわたって Colossus で 800 万 IOPS 以上を達成しました。

2,100 のエージェントノードでテーブル全体のスキャンを同時に実行する同様のベンチマークでは、合計スキャンスループットが 1 秒あたり約 1 テラビットを超えました。

エージェントプールは本番環境クラスタと物理インフラストラクチャを共有しないため、チームは本番環境システムを危険にさらすことなく、推論フリートを数千ノード規模にスケールできます。

3 つの原則すべてを設計に組み込む

次の表は、AlloyDB のアーキテクチャが 3 つの原則をどのように満たしているかを示しています。

エージェント型データベースアーキテクチャには、これら 3 つの基本要素が不可欠です。すなわち、Colossus の特性を備えたストレージ、コンピューティングとストレージをボトルネックなしに接続するネットワーク、そしてエージェントの規模に合わせてプロビジョニングと解放ができるコンピューティングです。

Google は、Google 検索、YouTube、Gmail を稼働させるために、20 年以上かけてまさにその基盤を構築してきました。現在、これは Google のエージェント型データベースアーキテクチャの基盤となっています。

本番環境に影響を与えることなく、エージェントにライブデータを提供

AI を活用した開発に取り組むすべての組織が、ある共通のジレンマに直面しています。それは、ビジネスを支えるシステムを危険にさらすことなく、エージェントに対して本番環境のライブデータへの完全なアクセス権をどのように付与するか、という問題です。これまでは、アプリケーションのニーズではなく、アーキテクチャの制約によって、その選択を強いられていました。エージェントにデータベースへの直接アクセスを許可すると、ミッションクリティカルなシステムを、予測不可能な負荷、深刻なリソース競合、本番環境の停止のリスクにさらすことになります。

これら 3 つの原則に基づいて構築されたアーキテクチャは、こうした妥協を完全に排除します。エージェントは、1 秒未満の更新頻度を保った本番環境のライブデータに基づいて推論します。そして、すべてのインデックス、ベクトル、全文検索、空間検索、SQL の全機能など、エンジンのフル機能を 1 ミリ秒未満の I/O で自由自在に駆使できます。このアーキテクチャは、エージェントの要求に応じて数千もの分離されたノードに動的にスケールし、処理が終了したらゼロにスケールダウンします。その間も、コアトランザクションワークロードは影響を受けることはありません。共有コンポーネントも、共有割り当ても存在せず、連動障害のリスクもないからです。エージェントは、ビジネスの継続性を損なうことなくビジネスにイノベーションをもたらすことができます。

この優れた特性が、本番環境データを参照する他のすべてのシステムにも適用されます。レポート、分析、アプリケーションは、本番環境を危険にさらすことなくライブデータを自由に読み取ることが可能になり、50 年間にわたってオペレーショナルデータベースを縛り続けてきた制約が、ついに解消します。

企業の記録システム内のデータは、その企業にとって最も重要なものです。この基盤の上に構築されたそのデータは、ついに最大限に活用できるようになります。

制約なきデータベースへ。

詳細については、ドキュメントページをご覧ください。こちらから登録すると、今すぐご利用いただけます。

- データベースエンジニアリング担当バイスプレジデント、Amit Ganesh

- データベース、エンジニアリング担当バイスプレジデント、Sailesh Krishnamurthy

IO 負荷の高いワークロードに適した、ストレージ最適化 Z4D マシンファミリーの一般提供が開始

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

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

このたび、Google Compute Engine の次世代 Z4D ストレージ最適化マシンシリーズの一般提供が始まりました。仮想マシン（VM）インスタンスとベアメタルインスタンスの両方でご利用いただけます。

Z4D は、I/O 負荷の高い、ビジネスクリティカルなワークロードを想定して構築されたマシンシリーズであり、SQL、NoSQL、KVrocks、ベクトルデータベース、データ分析、データ検索といった用途で大容量のローカルストレージおよび高いストレージパフォーマンスが必要な場合に適しています。AMD の第 5 世代の EPYC プロセッサ（Turin）を搭載し、Titanium の最新機能を組み合わせることで、最大 84,000 GiB のローカル SSD（LSSD）ストレージをサポートしています。前世代の Z3 インスタンスと比較して、パフォーマンスが最大 40% 向上しているため、特に要求の厳しいワークロードにおいて高い効果を発揮し、アプリケーションのスループット向上およびクラウド費用の最適化をもたらします。さらに、Z4D は大容量 LSSD を提供しているという点が大きな特徴であり、AI / ML のトレーニングおよび推論や、大規模な分散並列ファイルシステムの実行といった用途に最適なストレージソリューションとなっています。

Z4D の VM インスタンスとベアメタルインスタンス

Z4D の VM ポートフォリオでは、大容量のローカル SSD および高密度の SSD（vCPU ごと）が提供されており、これらを使って、ワークロード要件に適したインフラストラクチャをサイジングし、クラスタをスケールできます。Z4D には 2 種類の VM タイプがあります。Z4D-highmem-standardlssd タイプは、7 種類の VM シェイプがあり、vCPU あたり 219 GiB の LSSD を提供します。これらの VM は、データ分析（OLAP）や SQL データベース（MySQL や Postgres など）向けに最適化されています。一方、Z4D-highmem-highlssd タイプは、 7 種類の VM シェイプがあり、vCPU あたり 438 GiB の LSSD を提供します。このタイプは、分散データベース、データストリーミング、大規模な並列ファイルシステム、データ検索といった用途向けに最適化されています。さらに、Z3 ベースの既存のワークロードがある場合は、Z4D を含むクラスタに拡張することによって、簡単にスケールできます。

Z4D ベアメタルインスタンスでは、仮想化レイヤを介さずに物理ハードウェアに直接アクセスできます。これによりレイテンシが短縮されるため、レイテンシの影響を受けやすいワークロードや、カスタムハイパーバイザ、一定のライセンス要件があるワークロードに適しています。さらに、Z4D ベアメタルは、AMD ベースのインスタンスとして初めて、複数のクラウドプロバイダにまたがるハイブリッドマルチクラウドプラットフォームである Nutanix Cloud Clusters（NC2）をサポートしています。また、Z4D ベアメタルインスタンスの大容量 LSSD および低レイテンシという特徴は、エージェント型 AI アーキテクチャにおいてマイクロ VM を使用するような場合にも最適です。たとえば、単一ホスト内で数千単位の分離サンドボックスを実行するような場合でも、ネイティブのパフォーマンスと効率を維持できます。

Z4D の VM インスタンスとベアメタルインスタンスは、84,000 GiB のローカル SSD ストレージに加え、最大 384 個の vCPU、最大 3,072 GiB のメモリを提供しています。Z4D インスタンスは Titanium SSD を基盤としており、ローカルストレージの処理を CPU リソースからオフロードすることによって、リアルタイムのデータ処理、低レイテンシ、高スループットのストレージパフォーマンスを実現してます。それと同時に、ストレージセキュリティも強化されています。また、Z4D は最大 15,600K のランダム読み取り IOPS と、最大 75,600 MiB/秒のシーケンシャル読み取りスループットを提供しており、LSSD ストレージのパフォーマンスが Z3 と比べて最大 70% 向上します。さらに、書き込みレイテンシが Z3 と比較して最大 25% 短縮され、読み取り / 書き込み混在の IOPS が最大 30% 向上していますが、Z3 に比べて IO レイテンシは増加していません。また、ネットワークスループットは Z3 と比べて 2 倍、標準ネットワーク帯域幅は最大 400 Gbps となっており、エンタープライズワークロードや AI / ML ワークロードに求められる接続性とストレージパフォーマンスを提供します。

お客様とパートナー様の声

「Elastic では、当社の提供する Elasticsearch プラットフォームにおいて、最高水準のパフォーマンスを提供すべく取り組んでいます。このプラットフォームは、オブザーバビリティ、セキュリティ、検索、AI ソリューションの基盤となるものであり、こうしたワークロードを大規模に実行するお客様にとって、パフォーマンスと費用効率は非常に重要です。新しい Z4D 仮想マシンの初期テストでは、前世代の Z3 VM と比較して、インデックス作成のスループットが最大 50% 向上しました。Google Cloud 上で Elasticsearch をデプロイしているユーザーに、こうしたメリットを提供できることを嬉しく思っております。」- Elastic、プリンシパルプロダクトマネージャー、Yuvraj Gupta 氏

「Z4D インスタンスに移行したことで、処理の実行時間が約 70% 短縮され、全体的な費用の削減につながりました。これにより、大量の免疫データ処理を高速処理し、生物学的分析情報へと変換できるようになります。製薬会社は、研究開発の全過程を通じてより多くの情報に基づいた意思決定を行うことが可能になります。」- immunai、ソフトウェアエンジニアリング担当シニアディレクター、Guy Yachdav 氏

「このたび Google Cloud との技術提携ならびに AMD との戦略的パートナーシップを拡充し、新しい Z4D ベアメタルインスタンスに Nutanix Cloud Clusters（NC2）を導入できる運びとなったことを、大変嬉しく思っています。この「NC2 オン Z4D」によって、NC2 対応の初の AMD メタルインスタンスが提供されることになり、これは、お客様にとって重要なマイルストーンとなります。AMD の最先端のコンピューティングパフォーマンスと、Google Cloud の堅牢なインフラストラクチャ、Nutanix のハイブリッドクラウドプラットフォームを組み合わせることで、これまでにない柔軟性、スケール、選択肢を提供することが可能となり、企業のワークロードに貢献できます。」- Nutanix、プロダクト管理担当バイスプレジデント、Saveen Pakala 氏

「Redis は、世界中の数千の組織のリアルタイムデータインフラストラクチャと AI ワークロードを支えています。当社の Flex は、特に大規模なデータセットに対応していますが、これらのデータをすべて RAM で処理した場合の経済的負担を解消するため、ローカル SSD でスケールを処理し、メモリでスピードを出しています。Flex ベンチマークスイートで、フラッシュを多用する同一ワークロードを対象に、Google Cloud の新しい Z4D ストレージ最適化 VM と現行世代の C3D インスタンスを比較したところ、比較的低スペックの VM シェイプでスループットが最大 4.3 倍、レイテンシは最大 77% 低減するという、驚異的結果が得られました。また、RAM ヒット率が 100% という条件のもとで、Z4D は 1 秒あたり約 180 万回のオペレーションを維持しました。フラッシュから読み出すデータの割合が増えるほど、Z4D のメリットが大きくなり、これは、Flex の開発思想とぴったり合致しています。Z4D のおかげで、小さなフットプリントで一定のパフォーマンスレベルを提供できる見通しがはっきりと立ちました。Z4D の一般提供を受け、テストを大規模に実行できるのが楽しみです。」 - Redis、CTO、Benjamin Renaud 氏

「Shopify は、当社のフリートにとって最適なマシンを追求しています。Z4D は、高速なローカル接続ストレージ、高速ネットワーキングに加え、高い CPU 密度を提供してくれます。Shopify のユーザーエクスペリエンスはデータの提供速度に依存しますし、AI ショッピングエージェントはストアフロントに対して人間よりもはるかに高頻度でクエリを実行します。Z4D のシェイプは、こうした状況に対応できるようなスループットを提供してくれます。Z4D では、Z3 と比較してスループットが約 20% 向上しました。」 - Shopify、上級エンジニア、Brad Dietrich 氏

「Google は Z4D VM で大きな飛躍を遂げました。当社のテストでは、前世代の Gen 2 VM と比較して最大 60%、Z3 VM と比較して最大 36% のパフォーマンス向上が確認されました。Z4D は、高いローカル SSD 密度、優れた費用対効果、システムの信頼性向上を実現しています。これにより、Silk のお客様に対して、特に要求の厳しいワークロードにおいても高速で予測可能なパフォーマンスを提供することが可能となります。」- Silk、チーフ R&D オフィサー、Adik Sokolovski 氏

「ペタバイト規模の最新データと AI の組み合わせにより、当社システムの検索対象はかつてなく膨大になっています。新しい Z4D インスタンスタイプは、目を見張るものがあります。Z3 と比較して、本番環境のクエリおよびインデックス作成のワークロードにおいてスループットが 40% 向上しました。これは、お客様にとって、ウェブスケールの検索がより高速かつ低コストで行えるようになることを意味します。」 - turbopuffer、エンジニア、Ben Linsay 氏

メンテナンスの利便性の向上

Z4D の VM インスタンスとベアメタルインスタンスでは、必要なメンテナンスの数日前にシステムから通知が届くため、事前に計画を立てて、任意のタイミングでメンテナンス作業をスケジュールすることができます。Z4D VM では、ローカル SSD ストレージが 42,000 GiB 以下の VM のメンテナンスイベント中に、インスタンスをライブマイグレーションできるなど、メンテナンス時の利便性が向上しています。ローカル SSD が 84,000 GiB の Z4D VM および Z4D ベアメタルインスタンスでは、計画的なメンテナンスイベントでのシャットダウン / 再起動時に、データがそのまま保持されます。

Hyperdisk のサポート

Z4D の VM とベアメタルは、Google Cloud のワークロード最適化ブロックストレージである Hyperdisk をサポートしています。Hyperdisk は、インスタンスごとにストレージのパフォーマンスと容量を調整できるのが特徴で、ワークロードごとにパフォーマンスを最適化できます。

特筆すべきは、Hyperdisk Balanced、Hyperdisk Throughput、Extreme Hyperdisk ストレージに対応しているという点であり、これらのスケーラブルかつ高パフォーマンスのネットワーク接続ストレージを通じて、インスタンスあたり最大 512 TiB の容量を利用できます。Hyperdisk Balanced は、インスタンスあたり最大 32万の IOPS をサポートしており、汎用ワークロードにおいてパフォーマンスと費用対効果を両立したい場合に適しています。一方、Hyperdisk Extreme は超低レイテンシが特徴で、Z4D の VM およびベアメタルでインスタンスあたり最大 50 万の IOPS と 12,500 MiB/秒のスループットをサポートしており、要求の厳しいデータベースワークロードに最適です。

Z4D を今すぐ使ってみる

Z4D VM は現在、世界の一部リージョンでご利用いただけます。Z4D ベアメタルインスタンスはプレビュー版が提供されています。利用方法など詳細については、Google のアカウント担当者までお問い合わせください。Z4D インスタンスの使用を開始するには、Google Cloud コンソールで新しい VM または GKE ノードプールを作成するときに、ストレージ最適化マシンファミリーに属する Z4D を選択します。詳しくは、Z4D マシンシリーズのページをご覧ください。ご利用いただけるリージョンについて詳しくは、Google Cloud の営業担当者までお問い合わせください。

- プロダクトマネジメント担当、Bob Napaa

強化学習（RL）による Gemini モデルのカスタマイズに関するベストプラクティスガイド

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

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

強化学習（RL）は、最新の LLM の事後学習の重要な要素となっていますが、大規模なトレーニングクラスタと、Gemini のような独自モデルでは外部の顧客がアクセスできないモデル内部へのアクセスを必要とします。そこで、Google Cloud は、これをマネージド RL ファインチューニングサービス（RLFT サービス） としてパッケージ化しました。お客様はプロンプトと報酬関数を用意するだけで、インフラストラクチャと独自モデルの内部は Google が処理します。

このサービスを使用すると、固定されたラベル付き回答セットではなく、定義した報酬シグナルに基づいてモデルに学習させることで、Gemini をサービスに適応させることができます。これにより、教師ありファインチューニング（SFT）では対応が難しい問題、つまり、実証は難しいものの、スコア付けは容易なタスクを解決できるようになります。

このガイドでは、RL ファインチューニングサービスを使用するための実践的なベストプラクティスについて説明します。まず、RL トレーニングループの概要、RL を使用するかどうか、いつ使用するかを判断する方法、このアプローチから最大限の価値を引き出す方法について説明します。

RLFT とは

RLFT は、ラベル付きの回答ではなく、定義した報酬シグナルに基づいて Gemini を調整します。大量のゴールドサンプルを作成する代わりに、回答をスコア付けするプログラムを 1 つ作成し、サービスがそれに基づいてモデルを改善します。これにより、実証は難しいが検証は容易なタスクを解決できるようになります。たとえば、すべてのスキーマに対して理想的な SQL を手動で記述することはできませんが、クエリを実行して結果を確認することはできます。

各トレーニングステップで、サービスはプロンプトに対して複数の回答候補を生成し、報酬でスコアを付け、元の Gemini に近い状態を維持しながら、スコアの高い回答が生成される可能性が高くなるようにモデルを改善します。これを可能にする強化学習はフルマネージドであるため、構成する必要はありません。あなたがコントロールし、結果を最も左右するものは、報酬です。

RLFT でできることとできないことは、次の 3 つの特性で定義されます。

モデル自体の出力から学習する: 外部のターゲットをコピーするのではなく、モデルがすでに生成したものを改良するため、SFT よりも無関係な機能を損なう可能性が低くなります。
経路ではなく結果に報酬を与える: 良い結果に到達した回答には報酬が与えられます。これは、有効な解決策が多数ある自由回答形式のタスクに適しています。
既存の能力を増幅する: たまにしか起きない成功を確実に再現できるようにしますが、モデルが一度も実証したことのないスキルを教えることはできません。

RLFT を使用する状況

プロンプトと SFT でほとんどの適応に対処できるため、まずはこれらを試してください。RLFT がその価値を発揮するのは、回答を評価できるが、安価に作成できない場合、重要な指標（忠実性、スキーマの有効性、トーン）で SFT が頭打ちになった場合、またはタスクに等しく有効な回答が多数あり、単一の参照ターゲットでは誤ってペナルティが課される場合です。

SFT と RLFT は競合するものではなく、補完的なものです。

直接 RLFT: ベースモデルがすでに時々成功している場合（報酬によってより良い回答とより悪い回答が区別される程度）。
SFT → RLFT の 2 段階: SFT データがある場合、またはベースの成功率が低すぎて RL が軌道に乗らない場合。SFT を短時間の安価なウォームスタートとして使用します。デモンストレーションを過学習させると RL による改善の余地が少なくなるため、SFT は軽めにとどめておきます。その後、SFT チェックポイントから RL を初期化する継続的チューニングを介して RL に移行します。

先行ユーザーの間では、これらのパターンは RLFT が最も価値を発揮する領域であることが示されています。いずれのパターンでも、企業が重視するものの、安価に実証できなかった成果を RLFT でスコア付けしています。

RLFT のユースケース

ゲーム内の AI を活用した NPC

内容: 多言語対応でマルチターンの長い会話で、キャラクターやブランドにふさわしい対話が展開される。
問題: 既製のモデルでは、言語の誤り、ハルシネーションにより生じたアイテム、プレーヤーの無視、繰り返しのループなどにより、没入感が損なわれる。
目標と報酬: Gemini 自動評価ツール（LLM-as-a-judge）が、ペルソナ、フロー、ゲーム状態のシンタックスに基づいて各ターンをスコア付けし、形式や言語のエラーにペナルティを課す。
結果: ループと言語のドリフトが解消され、状態のシンタックスが維持されたことで、ゲーム内のキャラクターを大規模にリリースすることが現実的なものになりました。

構造化されたエンティティの抽出

内容: サプライヤーの請求書や出荷明細書などの非構造化ドキュメントから一連の項目を抽出し、構造化レコードに自動的に変換する。
問題: SFT が頭打ちになるロングテール。必要なフィールドが見落とされている（再現率）か、存在しないフィールドが捏造されている（適合率）。
目標と報酬: ルールベースの適合率 / 再現率の報酬を使用して、各フィールドがソーステキストにグラウンディングされるようにして、1 つの正解から模倣されないようにする。
結果: チューニングが停滞していたノイズの多い実社会のドキュメントに対して、フィールドレベルの精度が向上し、手動によるレビュー手順を自動化できました。

コンテンツ管理

内容: 複雑なポリシーとディシジョンツリーを大規模に適用する。
問題: モデルのハルシネーションによる偽陽性や、無効な形式で評価を避けようとする報酬ハッキング。
目標と報酬: Cloud Run の報酬を使用して、形式の検証と決定論的な採点ツールを組み合わせて、複数ステップのポリシー遵守を強制する。
結果: モデルが複雑な免除措置を処理し、偽陽性を大幅に削減し、報酬ハッキングを阻止したことで、管理費用を増加させる人間へのエスカレーションの量が減少しました。

実行によって測定されるコード

内容: 顧客データに対して実際に実行されるかどうかに基づいて評価される SQL または API 呼び出し。
問題: SFT が 1 つの参照クエリを模倣し、未知の独自スキーマに対して機能しない。
目的と報酬: コード実行の報酬を使用して、安全なサンドボックスでコードを実行し、コンパイル、実行を経て、正しい結果が返された場合にのみ報酬を与える。
結果: モデルは、クローズドフロンティア品質の実行可能なクエリを最初の試行で生成し、推論コストを削減しました。これにより、技術者以外のユーザーも自然言語で独自のデータをクエリできるようになりました。

HTML によるプレゼンテーションスライドの生成

内容: HTML / CSS で作成された複数スライドの資料。
問題: テキストのみでトレーニングすると、視覚的な品質が無視されるため、オーバーフロー、要素のクリッピング、一貫性のないスタイル設定などが見過ごされる。
目標と報酬: コード実行の報酬を使用して、スライドをレンダリングし、ビジュアルデザイン、レイアウトの整合性、構造の完全性、評価基準の遵守をスコア付けする。
結果: モデルは、テーマに一貫性があり、レイアウトのオーバーフローがない、モジュール化された、適切なスタイルのスライドを出力しました。

どこから始めるべきか

データセット。最初の実行には、検証用として取り分けたデータを含む、多様なプロンプトのセットで十分です。ループが収束し、報酬が期待どおりに推移していることを確認してから、スケールします。トレーニングと評価は厳密に分けるようにしてください。評価が汚染されると、過学習が見落とされてしまいます。
報酬関数。コードまたは構成としてのタスク仕様であり、品質を左右する重要な要因。優れた報酬は、人間の好みに相関し、不正な出力に対して堅牢であり（解析の失敗をキャッチし、クラッシュすることなく、明確に否定的なスコアを返します）、報酬ハッキングに耐性があります。具体的には、複数の評価を組み合わせ、長さへのペナルティを課し、異常な出力への下限を設定し、モデルの意見よりも検証可能なチェックを優先します。リリース前にオフラインで検証してください。

残りはサービスが処理します。デフォルト設定から開始し、コンソールで報酬と評価の曲線を確認して、最後の段階ではなく、検証報酬が頭打ちになった時点のチェックポイントを使用します。

使ってみる

あなたは何を構築しますか？そのために必要なツールがここにあります。

ドキュメント: 強化学習ファインチューニング

- Google、シニアソフトウェアエンジニア、Jiaqi Pan

- Google、シニアプロダクトマネージャー、Kunal Jha

オーケー: AlloyDB と Database Migration Service で「止められない基幹システム」を移行し、データドリブンな価値創出を加速

Mon, 05 Oct 2026 02:00:00 +0000

小売業界で急速な事業拡大を続けるオーケー株式会社（以下、オーケー）は、ネットスーパーの成長を支えるデータベースの基盤強化と、店舗の「止められない」業務を担うデータベースの刷新という 2 つの課題に挑戦。AlloyDB を軸とする Google Cloud のソリューションを採用し、現場への影響を極小化しながら、新たな基盤の構築に成功しています。このプロジェクトを推進してきたオーケーと KDDIアイレット株式会社（以下、KDDIアイレット）の担当者に、話を伺いました。

利用しているサービス:
AlloyDB, Database Migration Service（DMS）, BigQuery, Firebase, Partner Interconnect, Datastream, Google Workspace, Gemini など

利用しているソリューション:
データベースのモダナイゼーション

ビジネスの急成長を受けて高まった、2 つの基幹データベース刷新の必要性

オーケーは「高品質・Everyday Low Price」を経営方針に掲げ、関東・関西に 180 店舗以上を展開するディスカウントスーパーマーケットです。同社は高品質な商品でありながら、特売日を設けず毎日が低価格の「Everyday Low Price（EDLP）」方針を徹底し、「小売 × IT」の最先端の仕組みづくりに挑戦してきました。2020 年に Google Cloud を導入し、オンプレミスのデータウェアハウスを BigQuery へと刷新したのを皮切りに、2021 年には「オーケーネットスーパー」を開始。会員向けスマートフォンアプリも、Firebase を活用して短期間で構築するなど、デジタル領域での顧客体験向上に注力しています。

しかし、オーケー IT本部副本部長の荒川健児氏は、こうした取り組みの裏側で、システムの心臓部を担う 2 つのコアデータベースの刷新が求められていたと振り返ります。1 つ目は、ネットスーパーの顧客体験向上を担う「ネットスーパー DB」です。

「この領域は将来的には法人利用も視野に入れており、増大するトランザクションに柔軟に対応できるスケーラビリティと、インフラ運用コストの最適化が強く求められていました。従来は他社のクラウド上で稼働しており、データが各システムにサイロ化していたのが実情です。このため高度な分析基盤や AI と連携しながら、お客様に対してパーソナライズされた提案をリアルタイムに行えるようにすることが目標となっていました。」

2 つ目のデータベースは、日々の店舗業務を支える「生鮮 DB」です。これは各店舗のマスター情報や仕入れ、棚卸し、販売実績といったデータを蓄積し、全店舗からのデータ参照や現場の帳票出力などに対応しており、絶対に止めることができないシステムです。

「『生鮮 DB』については長年稼働してきたオンプレミス環境からの脱却を目標にしていましたが、新しいクラウド環境とオンプレミス環境が並存する過渡期に、データ連携と一貫性をいかに維持するかという課題がありました。また『生鮮 DB』は、現場に定着している業務プロセスと密接に結びついているため、一斉停止を伴う全面移行をいかに避けるかも問われていました。」（荒川氏）

AlloyDB の採用により、業務の根幹を支えるデータベースの移行と基盤統一を実現

現行業務への影響を最小限に抑えながら、既存のデータベースからコアデータを安全に切り離し、新たなクラウドに段階的に移行する。この難易度の高いミッションをクリアすべく、オーケーは基本方針の決定からネットワーク構築、PoC（概念実証）、データ移行、本番切り替えまでのサポートを KDDIアイレットに依頼します。評価されたのは、Google Cloud 導入支援と運用最適化を多数手がけてきた実績でした。

これ以降、両社は共に検討を重ね「ネットスーパー DB」と「生鮮 DB」の移行先を統一し、その共通基盤として AlloyDB の採用を決定しました。KDDIアイレットで開発を率いた齋藤寛隆氏は、その選定理由として 5 つのポイントを挙げています。

「まず大前提となったのは高可用性です。AlloyDB は、止められない生鮮業務を支えられる『99.99% のサービスレベル契約（SLA）と約 15 秒のフェイルオーバー』という性能を持っていました。2 つ目は、標準的な PostgreSQL 比で 4 倍以上のトランザクション処理性能、3 つ目は、オートバキュームなどの自動化による運用負荷の削減です。4 つ目はすでに活用されている BigQuery との親和性で、最後は移行支援ツールの充実も決め手になりました。」

AlloyDB への統合にあたっては、「セキュアなプライベート通信の確立」と「種類の異なるデータベース間での無停止移行」という要件がありました。まず通信に関しては、オンプレミスのデータセンターや他社クラウドから Google Cloud へ Partner Interconnect の専用線で接続。インターネットを経由せずに AlloyDB と通信できる閉域網環境が構築されています。

データ移行では、DB ごとに方法が使い分けられました。「ネットスーパー DB」は一部データの移行となり、システムを停止させることが可能だったため、対象データを既存の PostgreSQL からエクスポートし、AlloyDB へインポートする方法が採用されています。これに対して「生鮮 DB」は、システムを止めることができないため、データ移行をアシストする Database Migration Service（DMS）が活用されました。

「『生鮮 DB』の移行では、DMS を用いて従来のデータベースのトランザクションログから差分データを解釈し、新しいデータベースへ継続的にデータ書き込みを行う方式を採用しました。これはクエリを発行しないため、稼働中のデータベースへの負荷を最小限に抑えることができます。また、差分のみの転送で遅延を最小限に抑えつつ、切り替え時のダウンタイムの極小化が実現できると判断し、DMS の採用を決めました。」（齋藤氏）

この移行プロセスでは、KDDIアイレットの知見も活かされています。スキーマ変換では、DMS のコンバージョンワークスペースと Gemini の変換提案を活用して作業の効率化を実現。DMS が対応していない日本語のカラム名では、英数字の仮テーブルを経由して、移行後に再設定する方法が採られています。移行後のデータ検証には、Google Cloud のデータ検証ツールが使用されました。

Gemini や AlloyDB AI も活用しながら、DX と新たな価値創出を追求

今回の移行プロジェクトで得られた技術的な成果を、齋藤氏は次のように総括します。

「『生鮮 DB』は日々の業務を担う『止められないシステム』です。本プロジェクトでは、止められないから移行を諦めるのではなく、ダウンタイムを極小化しながら AlloyDB に移行することで要件をクリアしただけでなく、将来的なデータ活用まで視野に入れることができました。BigQuery との連携では、Datastream を活用することにより、セキュアな通信を維持したまま、AlloyDB から BigQuery へニアリアルタイムにデータを連携できるようにもなりました。」

一方、荒川氏は AlloyDB を軸とした新たなデータベース基盤が、現場における業務を大きく変えつつあると説明します。

「従来、生鮮の現場では、担当者が独自のツールを使って DB からデータを抽出し、手作業で表計算ソフトの集計や状況確認を行っていました。しかし新たなシステムでは、BigQuery 上に生鮮のニアリアルタイムなデータを集約し、さらに天気情報や人流データ、客数予測といった外部データを掛け合わせることが可能になります。店舗での売り上げ情報を即座に反映して『製造の推奨数』を算出することにより、生鮮領域のロスを削減しながら、売り上げを増やすための合理化も図られるようになりました。」

オーケーではデータドリブンな業務改革を定着させるため、環境づくりも進められています。実際に必要とされるデータやシステム運用のリテラシーは職種や部門によって異なるため、AI をエージェント化し、自然言語でデータを活用できるようにする取り組みが始まっています。「自動化できるところは AI で積極的に自動化し、人間は本当に考えるべき業務だけを担う」という発想には、少子高齢化による人手不足に対応する狙いも込められています。

「小売 × IT」で新たなニーズに対応し、事業成長を牽引していく。このアプローチを推進し続けるべく、荒川氏は Google Cloud のエコシステムを活用しながら、DX の推進と顧客体験の向上を図りたいと改めて強調しました。

「デジタル上で店舗の商品を見つけやすくすることは、顧客体験を向上させ、売り上げを伸ばす意味でも重要です。例えば従来のキーワード検索では、『コレステロールが気になる人向けの油は？』といった問いかけに対し、商品を見つけられないことがありました。しかし AlloyDB AI を活用すれば、意味や文脈を汲み取った検索や、類似商品の提案も可能になっていきます。AlloyDB や BigQuery はもとより、Google Workspace や NotebookLM、Gemini をはじめとするツールには、データ連携や集約がシームレスに行えるという大きな魅力があります。今後も KDDIアイレットや Google Cloud のサポートを受けながら先進的な IT を活用し、お客様に提供する価値を高め続けていきたいと考えています。」

オーケー株式会社
1958 年創業。「高品質・Everyday Low Price」を経営方針に掲げ、関東（1 都 3 県）、関西（大阪府・兵庫県）に 180 店舗以上のディスカウントスーパーマーケットを展開。高品質な商品でありながら、特売日を設けず毎日が低価格の「Everyday Low Price（EDLP）」方針を徹底し、ナショナルブランド商品については地域一番の最安値を目指す。2024 年には関西エリアにも進出し、年商 7,500 億円を超える規模へと成長している。

KDDIアイレット株式会社
2003 年 8 月にアイレット株式会社として創業し、2017 年 2 月に KDDI株式会社の傘下に。2026 年 4 月に KDDI Digital Divergence Holdings株式会社との合併により、社名を KDDIアイレット株式会社に変更。クラウドインテグレーション事業、開発事業、デザイン事業、提携事業を展開し、Google Cloud パートナーとして、インフラの移行や新規構築、アプリケーション開発、AI エージェント開発まで数多くの実績を持つ。

インタビュイー（写真左から）

・オーケー株式会社
　IT本部副本部長　荒川健児氏

・KDDIアイレット株式会社
　クラウド・イノベーション本部クラウドインテグレーション事業部グループリーダー
　齋藤寛隆氏

その他の導入事例はこちらをご覧ください。

Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出

Mon, 05 Oct 2026 01:00:00 +0000

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

Gartner は 2026 年の Gartner® Magic Quadrant™ で、「ビジョンの完全性と実行能力」に基づき、Google を 4 年連続でコンテナ管理のリーダーとして認定しました。Google は、評価対象となった全ベンダーの中で実行能力において最も高い評価を得ています。これは、パフォーマンスと効率の両面で高度に最適化されたコンテナプラットフォームを提供するという Google のミッションの成功を証明するものと考えています。Google は、次世代の AI アプリケーションやエージェントアプリケーションなど、特に要求が厳しく複雑なワークロードを大規模に構築、実行できるよう、世界中のお客様を支援しています。

Magic Quadrant に付随する 2026 Gartner Critical Capabilities for Container Management レポート（2026 年の Gartner のコンテナ管理の重要機能に関するレポート）によると、Google Cloud は、すべてのユースケース（新しいクラウドネイティブなアプリケーション、コンテナ化された既存のアプリケーション、AI トレーニング、AI 推論、エッジアプリケーション、ハイブリッドアプリケーション）において第 1 位にランクインしました。

Gartner は、「Kubernetes を使用する新規の AI デプロイは、2025 年には 30% 未満だったが、2028 年までに 95% になる」と予測しています1。コンテナは昨今の特に革新的なアプリやビジネスを推進し、エージェントの時代にビジネスを変革するお客様が求めるインフラストラクチャを提供します。

Google Cloud は、2014 年に Kubernetes を導入し、2015 年に世界初のマネージド Kubernetes サービスである Google Kubernetes Engine（GKE）をリリースしたことで、業界全体のクラウドネイティブ革命を主導しました。それ以来、コンテナプラットフォームと、活気に満ちた革新的な Kubernetes エコシステムに対する Google の取り組みは、さらに強化され、深まっています。GKE とともに、Google のサーバーレスコンテナプラットフォームである GKE Autopilot と Cloud Run により、運用コストが大幅に削減され、デベロッパーは優れたコンテナ化アプリをこれまで以上に迅速に提供できるようになります。

エンタープライズ AI の急速な普及を受け、Google は AI 時代に向けてインフラストラクチャ管理を再定義しました。2026 年、Google はこれまでに、GKE と Cloud Run を、自律型 AI システム、大規模な推論ワークロード、セキュアなランタイム分離向けに設計された、エージェントネイティブな高性能プラットフォームに移行するために、幅広い基盤の改善を導入しています。最先端の AI トレーニング、AI スタートアップの立ち上げ、企業の AI 変革の主導など、あらゆるニーズに対応するコンテナプラットフォームをご用意しています。重要なポイントは次のとおりです。

AI インフラストラクチャで優れたパフォーマンスと効率を実現

GKE 予測レイテンシブースト: GKE Inference Gateway に組み込まれたこの ML 駆動型機能は、静的な構成ではなく容量認識ルーティングを使用して、最初のトークンまでの時間（TTFT）を最大 70% 短縮します。
GKE の自動 KV キャッシュストレージ階層化: KV キャッシュデータを RAM、ローカル SSD、Cloud Storage 間で自動的に移動します。これにより、メモリのボトルネックが軽減され、RAM へのオフロードによって TTFT が 40% 短縮され、大規模なプロンプトコンテキストではローカル SSD によってスループットが 70% 向上します。[1]
GKE によるコンテナとモデルの起動の高速化: GKE ノードのスピンアップ時間が最短で 4 分の 1 に短縮され、Pod の起動速度が最大 80% 向上しました。さらに、ネイティブの Run:ai Model Streamer のインテグレーションにより、重いモデルを Cloud Storage から 5 倍速く pull できます。
Cloud Run のオンデマンドサーバーレス GPU のゼロへのスケーリング: Cloud Run は NVIDIA RTX PRO 6000 Blackwell GPU をサポートしているため、チームは 700 億以上のパラメータがあるモデルをオンデマンドでサービングできます。サービスは、ゼロの状態から、完全にプロビジョニングされた GPU（すべてのドライバがプリインストール済み）に 5 秒未満で移行できます。アクティブな推論やファインチューニングの実行が完了すると、Cloud Run はインスタンスを自動的にゼロの状態にスケールダウンし、アイドル状態のインフラストラクチャ費用を排除します。

エージェントインフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

GKE Agent Substrate: オープンソースでセキュアバイデフォルトのエージェント実行ランタイムである Agent Substrate は、標準的なコンテナランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。自律型エージェントの時代に向けて専用設計された Substrate は、ネイティブのゼロトラストカーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。Agent Substrate は、あらゆる Kubernetes インフラストラクチャで動作し、GKE 向けに最適化されたオープンソースソリューションとして提供されます。
GKE Agent Sandbox: gVisor カーネル分離テクノロジーを基盤とする Agent Sandbox は、信頼できないマルチエージェント AI のコード実行からホスト環境を分離します。セキュアな実行を大規模に実現し、1 秒未満のレイテンシで 1 秒あたり最大 300 個のサンドボックスを処理します。また、Axion プロセッサで実行した場合、同等のハイパースケーラークラウドプロバイダと比較して最大 30% 優れたコストパフォーマンスを実現します。
GKE Dataplane V2 のスケーラビリティの上限: アクティブな NetworkPolicy を実装する GKE クラスタのアーキテクチャ上の容量上限が、クラスタあたり 7,500 ノードから 15,000 ノードに倍増し、大企業や AI を活用するお客様の膨大なインフラストラクチャニーズに対応します。
GKE のインテントベースの自動スケーリング: GKE は、基本的なハードウェア指標だけでなく、アプリケーションインテントとカスタム指標を使用して、ネイティブに水平自動スケーリングできるようになりました。これにより、リソース割り当ての反応時間が 25 秒からわずか 5 秒に短縮されます。
Filestore エージェントボリューム: NFS マウントをミリ秒単位でアタッチ / デタッチする新しいサービス。エージェントをほぼ瞬時に開始 / 再開できるほか、ネイティブの Read-Write-Many（RWX）アクセスと POSIX 準拠のファイルロックにより、書き込みの競合を発生させることなく、安全なマルチエージェントコラボレーションを実現します。

サーバーレスコンテナによる次世代のデベロッパーエクスペリエンス

Cloud Run は、標準的なウェブ API のホスティング、負荷の高いバッチデータジョブの実行、非同期メッセージキューの処理、複雑な AI エージェントのデプロイなどをすべて、比類のないデベロッパーエクスペリエンスと最大限のエンジニアリング速度を実現する単一の統合されたサーバーレスモデルで処理します。

Google AI Studio でのワンクリックプロトタイピング: フルスタックアプリケーションを直接構築してデプロイできる Google AI Studio は、迅速なプロトタイピングやテストに最適な環境となっています。ワンクリックで、バイブコーディングされたアプリケーションを即座にパッケージ化して Cloud Run に公開できます。
Cloud Run インスタンス: この新しいプリミティブは、Cloud Storage ボリュームマウントを統合した、個別にアドレス指定可能な長時間実行のシングルトンリソースを管理します。これにより、OpenClaw のような常駐型のバックグラウンドエージェントを費用対効果よくデプロイできるようになります。Cloud Run インスタンスは、ベースラインの共有 CPU 構成の料金が、予測しやすい月額約 5.70 ドルの定額料金（1 つの vCPU と 1 GiB の RAM の場合）からとなっており、従来の VM の無駄なアイドル費用や運用上のオーバーヘッドを回避しながら、常時稼働の VM のようなエクスペリエンスを提供します。
Cloud Run サンドボックス: 500 ミリ秒未満でスピンアップするハードウェア的に隔離された環境で、信頼性の低いモデル生成コードを安全に実行し、ホストシステムを不正アクセスから保護します。

次のステップ

Google は、コンテナプラットフォームのパフォーマンス、セキュリティ、スケールを新たな高みへと引き上げながら、オープンな環境で未来を築き続けています。ぜひ、Agent Sandbox と Agent Substrate を今すぐお試しください。お客様やパートナー様とともに、エージェントインフラストラクチャの未来を築いていけることを楽しみにしています。学習を続けるには、以下のリソースをご覧ください。

2026 年 Gartner® Magic Quadrant™ のコンテナ管理部門を無料でダウンロードできます。
GKE で Agent Sandbox をお試しください。
Agent Sandbox のオープンソースコミュニティに参加して協力しましょう。
Agent Substrate をご確認ください。
11 月 9～12 日にソルトレイクシティで開催される KubeCon North America 2026 にご参加ください。1 日早く到着して 11 月 9 日の GKE Day にも参加すると、より一層お楽しみいただけます。
Google が 2026 年 Gartner® Magic Quadrant™ でクラウドネイティブアプリケーションプラットフォーム部門のリーダーにも選出された理由をご確認ください。
cloud.run で、サーバーレスアプリケーションの未来を築きましょう。

^{1. Gartner レポート: Critical Capabilities for Container Management、2026 年 9 月 8 日}

^{Gartner、Magic Quadrant のコンテナ管理部門、Dennis Smith 他、2026 年 9 月 2 日Gartner、Critical Capabilities for Container Management、Tony Iams、Wataru Katsurashima、Lucas Albuquerque、Dennis Smith、Bhuvie Chhabra、2026 年 9 月 8 日。Gartner および Magic Quadrant は、Gartner, Inc. および / またはその関係会社の商標です。免責事項: Gartner は、発行物に掲載されている特定の企業、ベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner の発行物は、Gartner のビジネスおよびテクノロジーインサイト組織の見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、商品性や特定の目的への適合性を含め、本出版物に関連したいかなる保証も行いません。}

日々のマイクロハビットを活用して企業における AI 構築担当者ーをスキルアップする方法

Mon, 05 Oct 2026 00:00:00 +0000

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

企業が生成 AI への投資を進めるなか、テックリーダーはいつも同じパターンを目にすることになります。開発者が AI ツールを 1 週間試してみるものの、セットアップで行き詰まり、結局は元のバックログに戻ってしまうのです。結局、何もリリースされません。

真のギャップはイネーブルメントにあります。Harvard Business Review の画期的な記事で、Josh Bersin 氏と Marc Zao-Sanders 氏は、ナレッジワーカーが正式な学習に割く時間は 1 日わずか 5 分であると指摘しています。ほとんどの企業研修プログラムは、いまだに 1 週間がかりのクラスルームブートキャンプや、数週間に及ぶ資格認定トラック、受け身のビデオ講義に頼っています。これらはどれも、開発者が実際に確保できる限られた時間には収まらないものばかりです。

Build with Gemini イベントシリーズが開催されるなか、Google Cloud コンサルティングは、チームのルーティンに手軽な日々の実践を組み込むことで、AI イネーブルメントのあり方を再考するリーダーが増えていることを実感しています。この投稿では、4 つの柱からなるアプローチと、グローバルなデベロッパーチャレンジから得た教訓を説明し、マイクロハビットスキルアップの概要を紹介します。

ワークショップから日々の実践へ

従来の方法	これからの方法
複数週にわたる半年に 1 度のクラスルームブートキャンプ	5 分間の実践演習
ローカルワークステーションの構成と認証情報の設定	事前構成済みのブラウザベースのサンドボックス
出席とコンプライアンスの確認が必須	毎日の継続記録、バッジ、チームチャレンジ
多肢選択式テストの完了	デプロイ可能なエージェントツールと再利用可能なコード

このようなモデルを導入できるかどうかは、各タスクを小さく、管理しやすいものに留められるかにかかっています。エンジニアリングチーム全体で、この作業をどのように構成しているかをご紹介します。

マイクロラーニングを習慣にする。1 日がかりのまとまったトレーニングを行うのではなく、モデルをデータベーススキーマに接続する、構造化出力を検証するなど、1 つのスキルをカバーする短いタスクを提示します。
チームにブラウザベースのサンドボックスを提供する。セットアップは、ほとんどのトレーニングで停滞する部分であるため、なくしてしまいます。事前構成されたマネージドクラウド環境により、開発者はタブを開いて数分でコードを書き始めることができます。認証情報の申請は不要で、ローカルマシンへのインストールやメンテナンスの手間も一切ありません。
毎日の継続記録を組み込む。マイルストーンの達成、成功体験の共有、そしてチームメイトとのソリューションの比較を通じて、日々の学習がごく自然に日常業務の一部になっていきます。
すべてのセッションを、実行可能なコンポーネントで終了する。各演習は、実際に動作するコンポーネントが手元に残るようにします。時間の経過とともに、それらのコンポーネントはコードやプロンプトの共有ライブラリとして蓄積され、チーム全体がいつでも引き出して再利用できるようになります。

Advent of Agents プログラムから得た教訓

Advent of Agents は、Google Cloud が開発者向けに提供している、エージェント構築を毎日行うプログラムです。このプログラムを立ち上げたとき、私たちは、技術支援からセットアップとスケジュール調整の負担をなくすとどうなるか、という疑問を検証したいと考えました。

開発者は、半日を費やしたり、最初にセットアップガイドを読んだりすることなく、ブラウザで直接実行できる、実務に即した短いエージェント演習を毎日 1 つずつ行いました。

世界中のチームから 15 万人以上の開発者が参加。
ブラウザベースの環境で 859,000 回以上の実践的なコード実行。
参加者の 31% が毎日継続して学習。これは、自分のペースで進める技術学習における業界平均（10%）の 3 倍以上であり、MOOC の標準ベンチマークである 5〜15% を大幅に上回る成果です。
32,000 人以上の参加者が、実際に機能するエージェントコンポーネントを構築。

上記のデータは、Advent of Agents の Google アナリティクスの指標から取得したものです。

演習をそれぞれ 5 分未満に収め、サンドボックスを事前に整えておくことで、企業研修でボトルネックとなりがちな 2 つの課題（環境構築の手間とスケジュールの確保）を解消しました。このデータは、普段どおりの一日のスケジュールに演習が無理なく収まるのであれば、開発者は自ら時間を見つけて学習に取り組むということを示しています。

マイクロイネーブルメントを実践する

AI イネーブルメントのために、開発のスプリントを中断する必要はありません。必要なのは、継続的な実践の習慣と、チームが通常業務と並行して構築を進められるツールです。

ライブ構築を体験する。エンジニアリングチームに Build with Gemini ワークショップの機会を提供しましょう。イベントは参加費無料で、ビジネスリーダー向けのノーコードから開発者向けのコードファーストまで、技術的な深さに応じたさまざまなトラックが用意されています。さらに、Google Cloud のエキスパートがサポートするライブハンズオンラボも実施されます。
GEAR でスキルを身に付ける。技術チームとビジネスチームを Gemini Enterprise Agent Ready（GEAR）プログラムに登録しましょう。メンバーシップは無料で、Google Skills の毎月の学習クレジット、ハンズオンラボ、スキルバッジなどの特典が含まれています。また、開発者、事業部門のリーダー、IT 意思決定者向けのラーニングパスも用意されています。

小さく始めて、頻繁に構築する

AI スキルの習得は、日々のルーティンを変えることから始まります。開発者は、毎日行う短時間の実践的な演習を通じて学ぶことができます。その過程で作成した実用的なコードは、チームが本番環境で利用できる初期ライブラリになります。

開発者に 1 日数分の時間と、準備ができたときにいつでも使用できるサンドボックスを提供しましょう。今週はまず 1 つの演習から始めて、小さな日々の習慣が、組織全体の AI 活用能力をどのように高めていくか、ぜひ実感してみてください。

Build with Gemini ワークショップに参加する: セキュアな AI エージェントを開発するためのインタラクティブなラボと実践的なトレーニングに今すぐお申し込みください。
GEAR で構築を開始する: GEAR に参加して、実践的な学習とガイダンスを通じてエンタープライズグレードのエージェントをデプロイする方法を学びましょう。
Google Skills の無料コースを探索する: 需要の高い AI の専門知識を自分のペースで身に付けましょう。

- Delta、エージェントによる変革担当責任者、Ryan Faris

- Delta、プロダクトマネージャー、Enrique Chan

ガバナンスが組み込まれた、AI 支援による EKS から GKE への移行を実現する GKE エージェント型移行の概要

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

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

最も重要な AI 駆動型ワークロードを実行するために、Google Kubernetes Engine（GKE）を標準として採用する企業が増えています。高スループットのデータアクセスを実現する Cloud Storage FUSE から、カスタムコンピューティングクラス（CCC）や高度な GPU スライス法まで、GKE は最新のアプリケーションに必要なスケールと効率性を備えています。

しかし、複雑な Kubernetes 環境を AWS EKS から GKE に移行することは、従来、エンジニアリング上の大きな課題であり、多大な手間を伴うものでした。プラットフォームチームは、複雑な Infrastructure as Code（IaC）を手動で分析し、クラウド固有のアーキテクチャの違いを把握して、カスタム変換スクリプトを構築する必要があります。

エンジニアリングチームは、汎用 LLM を使用してコード変換のドラフトを作成することをよく試みていますが、アドホックなプロンプトはすぐに運用上の落とし穴になる可能性があります。未加工のモデルは、存在しないリソースプロパティのハルシネーションを起こしたり、重要なネットワーク構成や ID 構成を欠落させたり、相互に依存するファイル間でコンテキストを失ったりします。プラットフォームエンジニアがモデルエラーを監査、解決、デバッグするために費やす時間は、当初得られるはずだったスピード向上効果を相殺し、手作業による労力と予測不可能性を生み出します。

このたび、Google は GKE エージェント型移行のオープンソースリリースを発表いたしました。これは、不安定なアドホックプロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェントプラグインです。

「大企業のお客様にとって、クラウドのモダナイゼーションにおける最大の障壁は、実行リスクと予測不可能性です。コンテキストを失い、構成をハルシネーションする未加工のチャットプロンプトとは異なり、Google の GKE エージェント型移行は、生成 AI のスピードと、企業が必要とする決定論的なガードレール（構造化された状態の永続性、プラットフォームチームとアプリチーム間のマルチペルソナ境界、交渉の余地のない人間の承認ゲート）の両方を備えてます。これにより、当社のグローバルエンジニアリング部門は、コンパイラ並みの精度で検証可能な移行ファクトリーを手に入れることができ、デリバリーリスクを大幅に削減できました。- Persistent、EVP、Rahul Shrivastava 氏

インフラストラクチャの移行に伴う課題

インフラストラクチャの移行プロセスについてお客様と話すとき、ガバナンスに関するいくつかの課題をよく耳にします。

自動化の信頼ギャップ: Kubernetes 構成を手動でリファクタリングすると、非常に時間がかかることがあります。しかし、汎用的な AI コーディングアシスタントを使用すると、許容できないリスクが生じます。標準的な LLM は、インフラストラクチャコードをハルシネーションしたり、非推奨の API フィールドを使用したり、重要なセキュリティルールを省略したりすることがあります。「ほぼ正しい」コードを生成しても、ボトルネックがコードの作成からデバッグに移行するにすぎません。
ライブクラスタの可変性の危険性（ClickOps）: 従来の移行ツールは多くの場合、ライブクラスタに直接接続し、API 呼び出しを介してデプロイします。これにより、組織の Git リポジトリ（信頼できる情報源）がバイパスされて、CI / CD パイプラインが中断され、ロールバックが非常に困難になります。
サイロ化されたハンドオフのボトルネック: 移行は多くの場合、複数週にわたる長期的な作業となります。プラットフォームエンジニアがランディングゾーンを構築し、アプリケーションデベロッパーがワークロードを移行します。標準的な AI ツールを使うと、引き継ぎ時にコンテキストが失われます。
断片化されたツールチェーン: Velero などのバックアップツールは障害復旧には優れていますが、AWS 固有の構成（ALB など）をそのままキャプチャするため、Google Cloud 向けには変換されません。一方、リバースエンジニアリングツールは、デベロッパーの本来の論理的な意図を排除したフラットな構成を生成します。

GKE エージェント型移行の概要

GKE エージェント型移行は、LLM の推論機能と厳格で決定論的なツールを組み合わせることで、これらの課題に対処します。エージェントスキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを、自動化された pull リクエスト経由で GKE ランディングゾーンに直接変換します。

GKE エージェント型移行の特徴となっている主な機能は次のとおりです。

1. ハイブリッド検証 - LLM で生成し、決定論的に検証。危険な IaC ハルシネーションに対処するため、LLM ワーカーが Terraform と Kubernetes YAML の複雑な作成を処理し、サーバーが Workload Identity アノテーションやイメージレジストリなどの正確なマッピングのために決定論的な変換を実行します。重要なのは、AI が生成したこれらの変換は、ユーザーに提示される前に、厳格な決定論的検証（terraform validate、Kubernetes マニフェストコントラクトなど）にかけられることです。このアプローチは、ハルシネーションに対する安全性を維持しつつ、あらゆる操作を人間参加型（HITL）の承認によって制限するのに役立ちます。

2. GitOps ネイティブの PR ワークフロー: プラグインがライブクラスタに変更を直接適用することはありません。代わりに、信頼できる情報源を読み取り、ターゲット状態を生成して、pull リクエストを開きます。これにより、すべての変更が標準の人間参加型（HITL）CI / CD 審査プロセスをとおして処理されるようになります。「ClickOps」は不要です。

3. 変換と転送の分離を保護: プラグインは、アーキテクチャ変換の面倒なロジックを自動化しますが、ステートフルデータを意図的に転送しません。最も機密性の高いアセットを保護するため、プラグインは、専用の SLA に裏付けられたツール（Google Cloud の Database Migration Service や Storage Transfer Service など）の使用をチームに指示する、コンテキストに応じたランブックを生成します。

4. マルチペルソナの状態管理: 移行はチームが行う取り組みです。プラグインは、長時間実行される移行状態を保持します。これにより、保護された非同期のハンドオフが可能になります。プラットフォームエンジニアがベースラインのランディングゾーンを確立し、アプリデベロッパーは各自のマシンからワークスペースに個別にアクセスして、権限が分離されたフォルダ内で個々のワークロードを変換します。

仕組み: 移行のライフサイクル

内部的には、GKE エージェント型移行は実行可能関数の移行状態グラフを利用し、チェーンに沿ってコンテキストを体系的に渡します。オープンソースのエージェントプラグインとしてパッケージ化されているため、カスタム CLI バイナリをインストールする必要も、中央のコントロールプレーンを管理する必要もありません。チームは既存の開発ハーネスを通じてコラボレーションし、検証済みの pull リクエストと実用的なランブックをソースリポジトリに直接配信できます。これには、次のような利点があります。

EKS リポジトリの念入りな検出: プラグインは、ソース Git リポジトリのクローンを作成するか、EKS クラスタのライブスキャンを実行し、ソースマニフェストをプログラムによりインデックスに登録して、依存関係をマッピングし、インベントリを構築します。
評価とブロッカーガバナンス: アーキテクチャの非互換性を特定する準備状況レポートを生成します。設計を開始する前に、すべてのブロッカーにオーナーと解決目標日を割り当てる必要があります。プラットフォームエンジニアは、変換を開始する前に移行の境界を承認します。
ランディングゾーンの設計: プラグインは、プラットフォームの明示的な決定（GKE Autopilot か GKE Standard かなど）に基づいて、基本的な Google Cloud Terraform モジュール（VPC、サブネット、GKE クラスタ、組織のポリシー）をスキャフォールディングします。
AI を活用したクラウド変換: プラグインは、AWS IRSA から Workload Identity への変換、ALB Ingress から Gateway API へのマッピング、Karpenter ノードクレームから GKE ノード自動プロビジョニング（NAP）またはカスタムコンピューティングクラス（CCC）への変換など、独自の移行を処理します。
オフライン検証: 生成されたモジュールとマニフェストは、オフラインでコンパイルされ、検証されます（terraform validate、マニフェスト構造のチェック、出力コントラクト）。
デプロイ（pull リクエスト経由）: 最終的な構成がローカルで検証され、レビューのために PR が開かれます。

使ってみる

GKE エージェント型移行は、クラウド移行を、まとまりのないリファクタリング作業から、予測可能で AI が支援する、レビュー可能な GitOps ワークフローへと変革します。GKE への移行を加速させる準備は整いましたか？

GitHub の GKE エージェント型移行リポジトリにスターを付け、クローンを作成してみましょう。
オンボーディングガイドを読み、サンプルの EKS リポジトリに対してプラグインを実行しましょう。
Google Cloud コミュニティに参加して、フィードバックの共有、質問、投稿を行ってください。

- GKE プロダクトマネージャー、Sunny Hwang

- GKE エンジニアリングマネージャー、Hamed Seifoddini

AlphaEvolve で動画処理を高速化する方法

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

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

リアルタイムストリーミングでは、1 ミリ秒の違いが結果を左右します。

たとえば、30 フレーム/秒（fps）の場合、デベロッパーはカメラフレームの取り込み、ニューラルセグメンテーションの実行、シェーダーの適用、出力の合成を、わずか 33.3 ミリ秒（60 fps の場合は 16.6 ミリ秒）という厳格なフレームバジェット内で行う必要があります。このバジェットを 1 ミリ秒でも超えると、ドロップフレーム（コマ落ち）やスタッタリング（カクつき）が発生します。

これを手動で最適化するのは、フレームグラフの分析や Swift、C++、Metal での低レベルコードの手動調整に何週間もかかるため、非常に面倒な作業になります。標準的な AI コーディング支援を使用すれば、ボイラープレートを生成することは可能です。しかし、ターゲットハードウェアに合わせた最適化や実際の環境で生じるレイテンシへのベンチマークには対応できず、また最適化後に視覚的な忠実度を完全に維持することもできません。

この状況を打破するには、自律的なクローズドループの進化史的最適化が有効です。AlphaEvolve のようなツールが、クラウド規模のモデル推論をローカルハードウェアでの実行と組み合わせ、すでに実用環境に効果をもたらしています。DoIt は、Google との提携により、AlphaEvolve を使用して、macOS のライブストリーミングアプリにおける本番環境 Swift コードの自律的最適化を実現しました。これにより、手動プロファイリングでは見つけられなかった伸びしろが見出され、パフォーマンスが改善されました（詳しくは完全版の技術レポートをご覧ください）。

この投稿では動画パイプラインに焦点を当てていますが、分割ループパターンは、マイクロサービスのスループットやデータベースのクエリから、ML テンソルパイプラインや組み込みシステムまで、パフォーマンスが重要となるあらゆる場面に適用できます。どのユースケースにおいても仕組みは同じで、クラウドにおける Gemini のコード生成を、ドメイン固有のベンチマークハーネスおよび自動品質ゲートと組み合わせます。

ここでは、AlphaEvolve を使用して動画処理を高速化する方法と、ユーザー固有のパフォーマンスボトルネックに以下の原則をどのように適用できるかについて確認していきましょう。

分割ループアーキテクチャを理解する: AlphaEvolve が、マネージドクラウド生成（Google Cloud 上の Gemini モデルアンサンブル）をローカルでの評価プロセス（ネイティブ Swift / Metal コードのコンパイルと実行時間の計測など）からどのように分離しているのかを理解します。
評価ツールの設計と品質ゲートを適用する: 構造的類似性指数（SSIM）などの指標を使用してスコアリング関数を構築し、進化ループがベンチマークの裏をかく（例: 速度を上げるためにレンダリングを完全にスキップする）のを防ぎます。
自律的なアルゴリズム検出を活用する: Gemini 主導の進化史的最適化検索により、プロンプトなしでフレームワーク API を自律的に検出し、エンジニアリングのバランス（フレームキャッシュの制限など）をインテリジェントに調整します。
現実的なパフォーマンス境界を設定する: 物理的なハードウェアの限界に対応するコードの最適化を測定します。

1. AlphaEvolve の分割ループアーキテクチャを理解する

AlphaEvolve は、クローズドループの進化プロセスを実行します。つまり、シードプログラムとカスタムスコアリング関数を使用して、Gemini モデルの混成がコードのバリエーションを提案し、各候補に対してスコアリング関数を実行します。その過程で最もパフォーマンスの高いコードを保持し、複数の世代にわたって反復的に最適ソリューションへと進化していく仕組みです。

AlphaEvolve アーキテクチャの主な利点は、次の 2 つの要素に明確に分けられていることです。

生成サイド（Google Cloud マネージドサービス）: プロンプトサンプラー、Gemini モデルアンサンブル、プログラムデータベースが含まれます。スケーリング、プロンプトオーケストレーション、生成メカニズムが Google Cloud で処理されます。
評価サイド（ユーザー管理のコンピューティング）: コード品質のスコアリングが、厳密にドメイン限定で実行されます。評価モジュールは完全にユーザーが所有し、独自のハードウェアまたはターゲットアーキテクチャ（この場合はネイティブ Swift コードを実行する macOS）で実行されます。

AlphaEvolve は、クラウド生成サイドでは Python ファーストですが、評価サイドは任意の言語で記述できます。カスタム評価ツールでは、Swift コードの各候補を Swift を使用してコンパイルし、標準の参照ウェブカメラクリップに照らして評価を実行します。

2. 評価ツールの機能と品質ゲートを適用する

AlphaEvolve のような自動最適化ループは、実際には動画ストリームを「見る」ことはありません。評価ツールが返す数値の適合度スコアを確認するだけです。評価指標に盲点がある場合、進化史的最適化によるコード生成はそれを積極的に利用してしまいます。

たとえば、初期の実行では、未熟な適合度スコアが元のレイテンシを重視するあまりに、処理が異常に高速化されました。モデルはぼかしレンダリングを完全にバイパスし、未修正のフレームを 0 ミリ秒で返したのです。

構造的類似性指数（SSIM）:

モデルがベンチマークの裏をかく行為を防ぐには、以下のように、スループットと構造的類似性指数（SSIM）などの構造的忠実度指標を組み合わせた 2 段階のスコアリング関数を記述します。

code_block: <ListValue: [StructValue([('code', 'speedup = baseline_ms_per_frame / candidate_ms_per_frame\r\nssim = mean_ssim_vs_golden\r\n\r\n#Disqualify any candidate falling below visual threshold\r\n\r\n\r\nif ssim < 0.98 or worst_frame_ssim < 0.95:\r\n return {"speedup": -1e12} # Disqualified\r\n\r\nreturn {"speedup": speedup, "ssim": ssim}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a8c65ea10>)])]>

これにより、以下のことが可能になります。

極めてハードルの高いクリップでテスト可能に: 静止フレームや空白のカメラ映像をベンチマークにすることは絶対に避けるべきです。コードの各候補は、静的な背景のフレームでは平均 SSIM ゲートを簡単に通過できてしまいますが、人がさっと振り向くような映像では必ず不適格になります。
平均だけでなく最小値も追跡可能に: 平均しきい値とフレームごとの最小値の両方を適用して、ドロップフレームやマスク更新の遅延を検出できます。

自律的なアルゴリズム検出を活用する

一般的に、デベロッパーは生成 AI を使用して、ローカルのマイクロ最適化（ヘルパー関数のインライン化、ループの展開、メモリプールの調整など）を行っています。しかし、アーキテクチャの余地を与えれば、進化ループがシステム的な最適化手段を自律的に発見することができます。

エンジニアリングのヒント:

分離されたループではなく、フレームワークのコンテキストを提供する: 公開 SDK ヘッダー、インターフェース定義、API リファレンス識別子をプロンプトまたは検索ハーネスに含めます。LLM のコンテキストウィンドウに、分離されたフレーム処理コールバックのみが含まれている場合、LLM はシーケンス対応サブシステムを使用できません。
マルチフレームライフサイクルフックを利用可能にする: 純粋なステートレス関数を適用するのではなく、コードの候補が前の実行から次の実行に制限付きの状態データ（マスクの履歴やキャッシュのタイムスタンプなど）を引き継げるようにします。
品質ゲートで動画の質と処理速度のバランスを管理する: AlphaEvolve に一時的なマスクキャッシュを導入した際、当初はマスクのキャッシュが過剰に行われ、動画にゴーストなどが残ってしまいました。そこで、SSIM ゲートによって動きのブレを規制し、パラメータを手動調整することなく、本番環境に対応したキャッシュウィンドウに検索を収束させました。

現実的なパフォーマンス境界を設定する

パフォーマンスエンジニアリングでよくある落とし穴は、闇雲に最適化を行うことです。2 倍の高速化を達成した場合、それで満足すべきでしょうか。それとも、さらに 3 倍を目指す余地があったのでしょうか。

リアルタイムのメディアにおいて、合計フレーム時間は次の 2 つのカテゴリに分けることができます。

変更可能なソフトウェアのオーバーヘッド: メモリ割り当て、バッファ形式の変換、スレッドコンテキストの切り替え、API ディスパッチの摩擦などがこれに相当します。
変更不可のハードウェアベースライン: 未処理のニューラルエンジン推論レイテンシ、GPU シェーダーコンピューティング時間、ハードウェアディスプレイ同期などがこれに相当します。

AlphaEvolve を最大限に活用するには、理論上の最大ヘッドルームを基準に測定する必要があります。

最適化ループを実行する際は、次の原則を考慮しましょう。

NoOps パイプラインを構築する: Swift / C++ オーケストレーション、データマーシャリング、フレーム変換は排除し、ウォームアップ済みの ML モデルと未加工 GPU のレンダリングパスのみをダミーバッファにディスパッチします。結果として得られる時間が、物理ハードウェアの下限となります。
対応可能な上限を計算する: 最適化可能な最大値は次の式で計算できます。

3. ハードウェアの制約を考慮して測定する: 任意の高速化倍率ではなく、最適化効率を測定します。

実際に使ってみる

すべてのベンチマークコード、テストクリップ、評価スクリプト、未加工の候補ログはオープンソースです。

GitHub リポジトリ: AlphaEvolve Camera Background Blur Example
DoIt の事例紹介に関する詳細な技術レポート: Running AlphaEvolve on Your Own Code

- Google、グループ AI プロダクトマネージャー兼エンジニア、Anant Nawalgaria

- DoIt、プリンシパル AI リード、Sascha Heyer 氏

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

ボーダーレスな Lakehouse を加速: クロスクラウドキャッシュのプレビュー版を発表

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

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

この投稿では、ボーダーレスな Lakehouse の機能強化についてお知らせします。これは、データエンジニア、データサイエンティスト、そして急速に導入が進む AI エージェントが、管理されたデータをその保存場所で直接クエリできるようにするためのソリューションです。

正確な推論を行い、複雑なエンタープライズワークフローを自動化するには、あらゆるタイプのエージェントとデータ利用者が、組織のデータ資産すべてに迅速かつ統合的にアクセスできる環境が必要です。そうした環境であれば、クラウドをまたいで顧客レコード、トランザクションログ、運用テレメトリーを結合することが可能になります。しかし、現代の企業データが 1 か所に収まっていることはほとんどありません。データ資産は、Amazon S3、Azure Data Lake Storage（ADLS）、Google Cloud Storage、オペレーショナルデータベース、さらには Salesforce、SAP、Workday などの SaaS プラットフォームに分散しているのが一般的です。これまで、こうした分散したデータセットの統合には、不安定な ETL パイプライン、ストレージの重複、極めて高額なクロスクラウドデータ転送費用がつきものでした。

組織がクラウドをまたいでデータをクエリして有効活用できるようにするため、今年 Google はボーダーレスな Lakehouse を導入しました。Apache Iceberg REST カタログ仕様を採用することで、Databricks Unity Catalog、AWS Glue、Snowflake Horizon などのカタログとの直接連携が可能になりました。また、他のクラウドプロバイダへの高帯域幅のプライベートリンクを確立する Partner Cross-Cloud Interconnect も導入しました。この接続により、1 ギガバイトあたりの転送費用を公共のインターネットを使用するよりも削減できます。

今回の機能強化では、「そもそもネットワーク経由で転送する必要があるデータの量を最適化する」ことで、マルチクラウドの効率化をさらに一歩進めました。

クロスクラウドデータのクエリ費用をさらに削減する、2 つの新機能をご紹介します。1 つは、Lakehouse 向けのクロスクラウドキャッシュのプレビュー版です。頻繁にアクセスされるデータを Google Cloud 内にローカルキャッシュすることで、ユーザーに意識させることなく BigQuery でのクロスクラウドクエリを高速化し、リモート転送の費用も削減することができます。標準的な Iceberg の列圧縮とクロスクラウドでのキャッシュ保存を組み合わせることで、クラウド間で実際に転送するデータの量を処理データの 5% 未満にまで抑えられることも珍しくありません。これにより、総所有コスト（TCO）を削減して、エンタープライズ規模でのクロスクラウド分析と AI 活用を実現できます。もう 1 つは、BigQuery のクロスクラウド接続のプレビュー版（こちらも提供中）です。この機能を使用すれば、他のクラウドにある Iceberg 以外のデータをクエリしてワークロードを高速化できます。

クロスクラウドキャッシュの仕組み

クロスクラウドキャッシュは、パラメータ調整やストレージ管理を一切必要とすることなくクエリを高速化し、企業が求める高度なパフォーマンスとセキュリティ要件を両立させます。それを実現する内部メカニズムの一部をご紹介します。

サブファイルブロック単位での処理: Apache Parquet などのカラム型フォーマットでは、クロスクラウドキャッシュはサブファイルブロックレベルで動作します。そのため、クエリが数列にしかアクセスしない場合、数ギガバイトに及ぶファイル全体をクラウド間で転送する必要がなくなります。BigQuery は、クエリで指定された特定の列チャンクと辞書ページのみをキャッシュ保存します。キャッシュミスが発生すると、BigQuery はクエリに応答するために必要なデータをリモートクラウドから取得し、将来のクエリのためにコピーをローカルにキャッシュ保存します。これにより、繰り返し発生するワークロードのネットワーク転送とレイテンシを大幅に削減できます。
デフォルトの保存データの暗号化: キャッシュに保存されたデータブロックは、Google が管理する暗号鍵（GMEK）によってデフォルトで暗号化されます。一時的なキャッシュストレージであっても、追加のオーバーヘッドなしで、通常の BigQuery ストレージと同様のエンタープライズグレードのセキュリティポスチャーを維持します。
テナントとリージョンの分離: キャッシュエントリは、プロジェクトとカタログの境界ごとに厳密に分割され、テナント間でのデータ漏洩を防ぎます。Lakehouse は、ローカルキャッシュとクエリ実行の両方を、指定された Google Cloud リージョン（例: us-east4）に厳密に限定します。これにより、リモートクラウドへのクエリ実行時にも、各リージョンのデータ所在地要件への準拠を支援します。
更新頻度チェック: マルチクラウドキャッシュでは、処理速度と鮮度のトレードオフを強いられることがよくあります。ステイル読み取りを防ぐため、BigQuery はキャッシュに保存されたデータを使用する前にリモートオブジェクトのメタデータを取得して、データが変更されておらず、ユーザーが引き続きアクセスできることを確認します。元データのテーブルが変更されると、BigQuery は新しいファイルをフェッチし、参照されなくなったキャッシュブロックは自動的に破棄します。これにより、信頼できる唯一の情報源の正確性を維持しながら、ローカルクエリと同等の速度を実現します。

キャッシュの仕組み、統計カウンタ、リージョンに関する留意事項について詳しくは、Lakehouse のインテリジェントキャッシュに関するドキュメントをご確認ください。

クロスクラウドキャッシュの実際の操作

では、日常業務において、この仕組みはどのように動作するのでしょうか。例として、e コマースチームが、Databricks Unity Catalog から Lakehouse に統合された Amazon S3 の 10 TiB の Iceberg 売上テーブル（aws_lakehouse_catalog.sales.web_sales）に対してクエリを実行する場合を考えてみましょう。夕方のタイムセールの時間帯（午後 8 時～9 時）には、アナリストが過去の取引データをクエリし、購入意向の強いユーザー層において、どのオンライン店舗がピーク時の取引量と収益を押し上げているかを特定します。

code_block: <ListValue: [StructValue([('code', 'SELECT w.web_name, hd.hd_buy_potential, COUNT(*) AS total_transactions, ROUND(SUM(ws.ws_sales_price), 2) AS total_sales\r\nFROM `aws_lakehouse_catalog.sales.web_sales` ws\r\n-- Joins household_demographics, time_dim (8:00-9:00 PM), and web_site.\r\nGROUP BY w.web_name, hd.hd_buy_potential;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a8c1eba90>)])]>

初回実行: コールド状態でのカラム型データ取得

この最初のコールド実行では、ローカルキャッシュは空の状態です（cacheBytesRead: "0"）。BigQuery は、パーティションのプルーニングと列投影を適用して、必要な Parquet バイト範囲のみを Partner Cross-Cloud Interconnect 経由で Amazon S3 から転送します。

code_block: <ListValue: [StructValue([('code', '{\r\n "totalBytesProcessed": "230343464114",\r\n "objectStorageStats": [\r\n{"cloudProvider": "AWS", \r\n"objectStorageBytesRead": "25834740486", \r\n"cacheBytesRead": "0"}]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a8c27ea10>)])]>

処理される論理データ: BigQuery は、10 TiB のデータセット全体のうち 214.5 GiB を処理します。
標準的な Iceberg の圧縮効率: Zstandard（zstd）を使用した標準的な Iceberg 列圧縮により、BigQuery が S3 から読み取るのは24.1 GiB のみです。これは8.9:1 の圧縮率に相当します。これらのサブファイル Parquet ブロックが Google Cloud に到着すると、BigQuery はそれらのデータをリージョンキャッシュに保存します。

追加の探索: ディメンションの追加

実際には、アナリストやエージェントがまったく同じクエリを 2 回続けて実行することはほとんどありません。フルフィルメントの詳細をさらに深堀りするため、アナリストは配送方法ディメンション（sm.sm_type）を追加してクエリを修正します。

code_block: <ListValue: [StructValue([('code', 'SELECT w.web_name, sm.sm_type, hd.hd_buy_potential, COUNT(*) AS total_transactions, ROUND(SUM(ws.ws_sales_price), 2) AS total_sales\r\nFROM `aws_lakehouse_catalog.sales.web_sales` ws\r\nJOIN `aws_lakehouse_catalog.sales.ship_mode` sm ON ws.ws_ship_mode_sk = sm.sm_ship_mode_sk\r\n-- Reuses existing joins on household_demographics, time_dim, and web_site.\r\nGROUP BY w.web_name, sm.sm_type, hd.hd_buy_potential;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a8c27f4d0>)])]>

この後続クエリのジョブ統計は次のようになります。

code_block: <ListValue: [StructValue([('code', '{\r\n "totalBytesProcessed": "287928766472",\r\n "objectStorageStats": [\r\n{"cloudProvider": "AWS", \r\n"objectStorageBytesRead": "1426587648", \r\n"cacheBytesRead": "25834740486"}]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a8736b790>)])]>

94.8% のキャッシュヒット率: BigQuery は、以前にクエリを実行した列の 24.1 GiB をローカルキャッシュから直接返します。
最小限のリモート取得: BigQuery は、新しい ws_ship_mode_sk 列と ship_mode テーブルを対象に、S3 から 1.33 GiB だけを転送します。
サブファイル単位の柔軟性: キャッシュに保存された列チャンクが再利用されるため、クエリを修正しても新たに必要になったバイトのみが転送されます。

エンタープライズ規模で効率性を向上

クロスクラウドクエリの TCO を検討する際に重要となる、上位 2 つの要素は次のとおりです。

圧縮率: Iceberg でデフォルトの圧縮アルゴリズム（Zstandard / zstd）を使用すると、カラム型データは高い圧縮効果を発揮します。データの圧縮率が 8:1 であると仮定した場合、処理される論理データ 1 TiB ごとに、ネットワーク経由で移動する必要があるデータは約 128 GiB のみとなります。
キャッシュヒット率: 最近アクセスされたデータをネットワーク経由ではなくキャッシュから取得できれば、ネットワーク転送を回避できます。データの 80% がキャッシュヒットになると仮定すると、アクセスされる物理データ 100 GiB ごとに、ネットワーク上を移動するデータは 20 GiB のみとなります。

これらの 2 つの要素と前提条件を掛け合わせると、組織が処理するデータ 1 TiB あたり、ネットワーク経由で転送する必要があるデータ量は約 26 GiB（処理されるデータ全体の 3% 未満）で済みます。この削減効果と Partner Cross-Cloud Interconnect を組み合わせることで、TCO を削減し、ペタバイト規模のクロスクラウド分析や AI 活用を極めて優れた費用対効果で実現できます。

BigQuery クロスクラウド接続のプレビュー版を提供開始

クロスクラウドキャッシュと併せて提供開始となった BigQuery クロスクラウド接続のプレビュー版では、BigQuery を Amazon S3 や Azure Storage のオープン形式データに直接接続することができます。

カタログ連携とクロスクラウド接続のどちらを使うべきかの判断基準はシンプルです。

BigQuery のクロスクラウド接続（元ファイル用）: Iceberg カタログで管理されていないスタンドアロンファイル（CSV、JSON、アドホックな Parquet）の場合、クロスクラウド接続を利用することで、リモートのバケットパスを直接参照する BigQuery 外部テーブルを作成できます。
Lakehouse カタログ連携（Iceberg 向け）: Databricks Unity、AWS Glue、Snowflake Horizon などのカタログで管理されている Iceberg データの場合、Lakehouse がスキーマとテーブルスナップショットを自動的に同期します。これにより、ユーザーエクスペリエンスが簡素化され、ユーザーが常に最新のデータに対してクエリを実行できるようになります。

クロスクラウド接続は、他のクラウドのコンピューティングワーカーではなく、Google Cloud リージョン内の標準 BigQuery コンピューティングワーカーを使用する、最先端のアーキテクチャを採用しています。このアプローチにより、世界各地のリージョンでの利用が可能になるほか、リモートファイルでも BigQuery と同等の機能（BigQuery AI や Gemini を含む）が提供されます。

Lakehouse のクロスクラウドキャッシュ機能は、BigQuery のクロスクラウド接続からクエリされたデータと、Lakehouse カタログ連携のデータの双方に適用されます。接続の作成方法や外部バケットパスへのクエリ実行方法については、BigQuery のクロスクラウド接続の設定に関するドキュメントをご確認ください。

- グループプロダクトマネージャー、Will Ochandarena

- スタッフソフトウェアエンジニア、Jason Ganetsky

AlloyDB と Cloud SQL のネイティブ BM25 ランキングを発表

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

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

ベクトル検索は、生成 AI、検索拡張生成（RAG）、データエージェントアーキテクチャの重要なコンポーネントですが、ベクトル検索だけでは不十分な場合もあります。ベクトルエンベディングは概念的な意味を理解するのに優れていますが、特定の英数字 ID や正確な商品 SKU 番号を扱うのは苦手です。真に堅牢な検索アプリケーションや AI アプリケーションを構築するには、セマンティックベクトル検索と従来の完全一致キーワード全文検索を組み合わせる必要があるかもしれません。これは、ハイブリッド検索と呼ばれます。

検索において、Best Matching 25（BM25）は、特定のクエリに対するドキュメントの関連性を推定するために使用される重要なアルゴリズムです。これまで、AlloyDB や Cloud SQL で BM25 ランキングを使用するには、全文検索バックエンドを追加する必要がありました。これにより、データサイロ、同期の遅延、運用の複雑化が生じていました。このたび、Tiger Data が作成したオープンソースの pg_textsearch 拡張機能により、AlloyDB と Cloud SQL for PostgreSQL 17 以降でネイティブ BM25 インデックスのプレビュー版が利用可能になりました。これにより、個別の全文検索バックエンドを維持する手間がなくなります。

統合されたハイブリッド検索バックエンドにより、最先端の全文検索を実現するために、個別のシステムをプロビジョニング、管理、または購入する必要がなくなりました。これらはすべて、運用データが保存されているデータベース内で直接行われ、以下を実現します。

業界標準のキーワードランキング: Tiger Data の pg_textsearch を活用して、C 言語で最適化された超高速の BM25 スコアリングを Postgres テーブルに直接適用できます。
複雑さを排除し、完全な整合性を実現: ベクトル検索と全文検索のために複数のバックエンドを維持する場合に発生する、データの重複、ETL パイプライン、同期の遅延を排除します。
強化されたセマンティック検索（AlloyDB 限定）: ScaNN および HNSW インデックスタイプにより、ベクトル検索クエリが（標準の PostgreSQL と比較して）最大 6 倍および 10 倍高速になります。

pg_textsearch を使用する理由

PostgreSQL に組み込まれている ts_rank を使用して、ある程度の規模で全文検索を行ったことがある方なら、その限界をご存じでしょう。コーパスが大きくなるにつれて、ランキングの品質が低下します。逆文書頻度はサポートされていないため、一般的な単語は珍しい単語と同じ重み付けになります。用語頻度飽和がないため、「データベース」という単語が 50 回出現するドキュメントは、1 回しか出現しないドキュメントよりも上位にランクされます。

BM25 は、情報検索のゴールドスタンダードであり、逆文書頻度（珍しい用語ほど重要）、用語頻度飽和（繰り返しに左右されない）、文書長正規化を提供します。Tiger Data のブログ投稿では、PostgreSQL ページで BM25 検索エンジンを構築した方法について詳しく説明しています。

全文検索の例

AlloyDB と Cloud SQL の両方で BM25 全文検索を始める方法をご紹介します。サンプルテーブル cymbal_products を考えてみましょう。このテーブルには、固有識別子 uniq_id、product_name 列、各商品のテキスト説明を含む product_description 列、生成された product_embedding 列が含まれています。cymbal_products には、屋内植物や屋外植物など、さまざまな小売商品に関する情報が含まれています。

インデックスの作成

BM25 を使用するには、pg_textsearch 拡張機能を有効にします。

code_block: <ListValue: [StructValue([('code', '-- Install pg_textsearch extension\r\nCREATE EXTENSION pg_textsearch;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a86dc5890>)])]>

cymbal_products テーブルの product_description 列にインデックスを作成します。

code_block: <ListValue: [StructValue([('code', "-- Create the native BM25 index on the content column\r\nCREATE INDEX idx_docs_bm25 \r\nON cymbal_products \r\nUSING bm25 (product_description) \r\nWITH (text_config='english');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a86dc72d0>)])]>

BM25 全文検索クエリは、<@> 特殊演算子を使用して実行できます。以下のスニペットでは、「cherry tree」を検索しています。

code_block: <ListValue: [StructValue([('code', "-- Full text search query\r\nSELECT product_name, product_description <@> 'cherry tree' AS bm25_score \r\nFROM cymbal_products\r\nORDER BY bm25_score \r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a86dc7450>)])]>

出力例を以下に示します。スコアが低いほど、関連性が高いことを示します。

AlloyDB ハイブリッド検索の例

AlloyDB でハイブリッド検索システムを設定するのは簡単です。同じテーブルにベクトルインデックスとキーワードインデックスの両方を作成し、ハイブリッド検索ユーザー定義関数（UDF）を使用して結果をシームレスに統合できます。

ベクトルインデックスの作成

ScaNN ベクトル検索インデックスを作成する方法は次のとおりです。

code_block: <ListValue: [StructValue([('code', '-- Install vector extension\r\nCREATE EXTENSION vector;\r\n\r\n-- Install scann extension\r\nCREATE EXTENSION IF NOT EXISTS alloydb_scann;\r\n\r\n-- Create scann vector search index \r\nCREATE INDEX cymbal_products_embeddings_scann ON cymbal_products USING scann(product_embedding cosine);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a86dc4490>)])]>

ハイブリッド検索

AlloyDB には、ハイブリッド検索クエリを非常に簡単に実行できる、すぐに使用可能なハイブリッド検索 UDF が用意されています。UDF は、Reciprocal Rank Fusion（RRF）アルゴリズムを使用して、各検索コンポーネントのランク付けされた結果を 1 つの統合リストにマージします。このクエリは、UDF を利用して、商品説明で「trees that grow taller than houses（家よりも高く成長する木）」のベクトル検索と「California（カリフォルニア）」のキーワード検索を実行します。

code_block: <ListValue: [StructValue([('code', 'CREATE EXTENSION google_ml_integration;\r\n\r\nSELECT *\r\nFROM ai.hybrid_search(\r\n search_inputs => ARRAY[\r\n \'{\r\n "data_type": "vector",\r\n "weight": 0.5,\r\n "table_name": "cymbal_products",\r\n "key_column": "uniq_id",\r\n "vec_column": "product_embedding",\r\n "distance_operator": "public.<=>",\r\n "limit": 10,\r\n "query_vector": "ai.embedding(\'\'text-embedding-005\'\', \'\'trees that grow taller than houses\'\')::vector"\r\n }\'::JSONB,\r\n \'{\r\n "data_type": "text",\r\n "weight": 0.5,\r\n "table_name": "cymbal_products",\r\n "key_column": "uniq_id",\r\n "text_column": "product_description",\r\n "limit": 10,\r\n "ranking_function": "<@>",\r\n "query_text_input": "California"\r\n }\'::JSONB\r\n ],\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a86dc4590>)])]>

以下のサンプル出力に示すように、結果は RRF スコアの降順でランク付けされます。

ここで、ハイブリッド検索は、セマンティックな直感と正確なキーワードマッチングのギャップを埋めます。ベクトルエンベディングは「家より高く育つ木」のような概念的なクエリの理解に優れていますが、従来の全文検索は「カリフォルニア」のような厳密な識別子に求められるピンポイントの精度を提供します。この 2 つを融合することで、AlloyDB は、アプリケーションが「California Sycamore」のような、地域に関連性の高い具体的な結果をリストの最上位に優先的に表示できるようにします。

Cloud SQL ハイブリッド検索の例

Cloud SQL では、同じテーブルにベクトルインデックスとキーワードインデックスの両方を作成し、共通テーブル式（CTE）を使用して結果をシームレスに結合し、以下に示すように RRF スコアを統合できます。

ベクトルインデックスの作成

Cloud SQL で HNSW インデックスを作成する方法は次のとおりです。

code_block: <ListValue: [StructValue([('code', '-- Install vector extension\r\nCREATE EXTENSION vector;\r\n\r\n-- Create an HNSW index on the embedding column for fast approximate nearest neighbor search\r\nCREATE INDEX product_hnsw_idx ON cymbal_products USING hnsw(product_embedding vector_cosine_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a86dc60d0>)])]>

ハイブリッド検索

こちらがハイブリッド検索クエリです。

code_block: <ListValue: [StructValue([('code', "CREATE EXTENSION google_ml_integration;\r\n\r\n-- BM25 keyword results\r\nWITH keyword_results AS (\r\n SELECT uniq_id, product_name, \r\n ROW_NUMBER() OVER (ORDER BY product_description <@> 'California') AS rank_kw\r\n FROM cymbal_products\r\n ORDER BY product_description <@> 'California'\r\n LIMIT 10\r\n),\r\n-- Semantic vector results\r\nsemantic_results AS (\r\n SELECT uniq_id, product_name, \r\n ROW_NUMBER() OVER (ORDER BY product_embedding <=> google_ml.embedding('text-embedding-005', 'trees that grow taller than houses')::vector) AS rank_vec\r\n FROM cymbal_products\r\n ORDER BY product_embedding <=> google_ml.embedding('text-embedding-005', 'trees that grow taller than houses')::vector\r\n LIMIT 10\r\n)\r\n-- Reciprocal Rank Fusion (RRF) to merge and score both lists\r\nSELECT COALESCE(k.uniq_id, s.uniq_id) AS uniq_id,\r\n COALESCE(k.product_name, s.product_name) AS product_name,\r\n COALESCE(1.0 / (60 + k.rank_kw), 0) + COALESCE(1.0 / (60 + s.rank_vec), 0) AS rrf_score\r\nFROM keyword_results k\r\nFULL OUTER JOIN semantic_results s ON k.uniq_id = s.uniq_id\r\nORDER BY rrf_score DESC\r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5a86dc55d0>)])]>

結果の出力は、上記の AlloyDB ハイブリッド検索の結果と同じです。

実際の操作を見る

こちらのデモ動画で、これらの機能がどのように連携するかをご覧ください。

Orange はどのように FinOps のアカウンタビリティを確立し、なぜ次にエージェントなのか

Thu, 01 Oct 2026 02:30:00 +0000

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

フランスを拠点とする大手多国籍通信プロバイダの Orange では、エンジニアリングチームがデリバリーバックログを一時中断して、全員でクラウド費用のクリーンアップに 1 日を費やす日があります。ランキングが表示され、素敵な特典が用意されています。経験豊富な実務担当者が初心者を指導するため、初心者は実際に作業しながら仕事を覚えます。一日の終わりには、プロジェクトの支援者（スポンサー）も結果を確認できます。

Orange はこれを FinOps Clean Days と呼んでいます。ゲーム要素を取り入れたハッカソンと組み合わせることで、100 人以上の社員が参加する FinOps コミュニティは、社内におけるネットプロモータースコアで 70 を超える評価を獲得しました。

これらの数字は、業界全体が苦戦しているある課題を示唆しています。最近の State of FinOps レポートでは、エンジニアに行動を起こさせることが、組織が直面する最大の課題の一つとして挙げられています。単なる認識から実際の行動へと移すには、FinOps のアカウンタビリティを醸成し、チームに真剣に取り組んでもらう方法を見つけなければなりません。

つまり、FinOps はビジネスにおける「変革」の課題と言えます。そして、ビジネスの変革に関する課題には、既知の解決策があります。Orange の FinOps リードである Camille Marini 氏に、同社がどのようにしてこれらの課題を克服し、AI の導入と ROI を加速させたのか、また、他の組織がどのようにして同じ道をたどることができるのかについて詳しくお話を伺いました。

Clean Days が効果的な理由

Orange は、FinOps チームの立ち上げ当初から、2 つの原則を掲げています。1 つ目は、Cloud FinOps は責任の共有であり、プロジェクトのすべての関係者がそれぞれの方法で関与する、という点です。そして 2 つ目は、その責任の共有を実現する唯一の道はコミュニケーションと、意図的な変革の取り組みである、という点です。

「FinOps の実践において、組織全体で責任の共有というコンセプトを重視しました」と Marini 氏は語ります。「これは、クラウドセキュリティに対する当社のアプローチと非常によく似ています。責任ある効果的な AI への支出と使用を実現するには、プロジェクトのすべての関係者が、それぞれの方法で FinOps に関与していることをチームに理解してもらう必要がありました。」

これらの原則に基づき、Orange は Google Cloud コンサルティングのサポートを受けて FinOps 実践コミュニティを立ち上げました。このコミュニティは、標準化されたコミュニケーションチャネルで運営されたため、その手法は中心メンバーの枠を超えて広く浸透しました。また、会議では具体的な最適化案や請求の更新情報を共有し、常に「すぐに行動に移せる内容」に徹したことで、すべてのセッションが参加者にとって価値あるものとなりました。

Clean Days は、アジャイルなチームが実際にどのように機能しているかを見極めたうえで考案されました。デプロイが絶え間なく行われるアジャイル環境では、最適化作業がスプリントより優先されることはほとんどありません。デリバリーの優先事項、バックログ、日常業務で、利用できる時間は真っ先に埋まってしまいます。そこで Orange は、専用の時間を確保し、それを共同作業にして、楽しいイベントに仕立て上げました。

このアプローチがなぜ効果的なのかは、McKinsey の「変革の 4 つの構成要素」によって説明がつきます。このフレームワークでは、大規模な組織変更には、次の 4 つの領域にわたるアクションが必要であるとしています。

納得と理解:「自分に何が期待されているかを理解し、それに同意している。」
公式なメカニズム:「構造、プロセス、システムによって変化が促されている。」
ロールモデリング:「リーダーや同僚の行動が変化している。」
人材とスキル:「新しい方法で行動するためのスキルと機会が与えられている。」

Orange の手法をこれらのブロックにマッピングすると、パターンが見えてきます。ゲーム要素と報酬により、エンジニアたちにお手本となる同僚が生まれます。ランキングによってさまざまな行動が可視化され、スポンサーはすぐに成果を確認できます。経験豊富な実務者が初心者を指導することで、コミュニティ自体を通じて人材とスキルが育成されます。定期的なセッションで最適化と請求に関する最新情報を共有することで、資金の使途を把握しているという確信が生まれます。

変化の 4 つの構成要素にマッピングされた FinOps アクティビティと、AI エージェントがそれらを強化できるポイント。

100 人を超える場合

100 人の熱心なコミュニティを築くことは、それだけでも十分に大きな成果です。しかし、数千人のエンジニアを抱える組織では、中央の FinOps チームが全員に直接連絡することはできません。リーダーにとっての課題は、Orange のようなコミュニティがもたらすもの、つまり意識改革、当事者意識の共有、行動の習慣化を、FinOps チームが直接アプローチできない人々に、どのように浸透させていくかです。

ここで、AI エージェントの出番です。AI エージェントは 2 つの主なメリットをもたらし、FinOps チームの能力を高めます。これまで人間が対応せざるを得なかった、複雑で時間のかかる作業をエージェントが引き受け、社内の誰もが摩擦なしに FinOps に取り組めるようになります。

エージェントをチームに定着させるには、自社が抱える具体的な課題に焦点を当てた戦略が必要です。こうした課題は多くの場合、認知負荷の高さ、責任の所在のあいまいさ、あるいは優先事項の競合などから生じています。まずは、FinOps ライフサイクルにおいてエンゲージメントが低下するポイントを特定します。

認識のギャップ: チームが支出の影響を把握していない場合、分析情報エージェントが、日常的に使用するツールにリアルタイムの費用データを push できます。
リソースのギャップ: エンジニアがバックログの消化に追われているなら、修復エージェントがすぐに効果の出る対策を特定し、そのままマージできる状態のコード変更として提示してくれます。
複雑さのギャップ: レポート作成が面倒なルーティン作業のように感じられる場合、オーケストレーションエージェントがデータを収集してプロセスを簡素化できます。

信頼から始め、自律性を追加する

賢明な進め方は、段階を踏んで進めることです。Orange のように、コミュニティプラクティスを確立します。次に、情報提供と提案を行う読み取り専用エージェントを導入します。コミュニティ全体でこれらが定着して初めて、システムに直接変更を加えるエージェントの構築へと進むべきです。直接的なアクションには運用上のリスクが伴うため、慎重に管理してください。しかし同時に、そこにこそ、最も大きな成果が眠っているのも事実です。

どのように構築するかは、誰が構築を担うかによって異なります。最小限のコードで迅速にデプロイしたいチームの場合は、Gemini Enterprise app がエージェントを作成するためのノーコード環境を提供します。きめ細かい制御を必要とするデベロッパー向の場合は、Gemini Enterprise Agent Platform（旧称 Vertex AI）が、Agent Development Kit（ADK）などのフレームワークで構築されたエージェントをリリースして管理するための高度なツールを提供します。

Cloud FinOps は、一元化されたレポートから、実際の開発現場で即座にアクションを起こすフェーズへと移行しつつあります。この変革に成功している組織は、まず「文化の醸成」から始め、次に AI エージェントを活用することで、一つのチームの限界を超えた組織全体への拡大を実現しています。

Orange の数値はコミュニティの取り組みから得られたものです。その基盤を構築することが、最初に真似るべき部分です。この取り組みをさらに拡大する準備ができたら、Google Cloud コンサルティングがコミュニティプラクティスの形成を支援します。また、Gemini Enterprise アプリを活用すれば、最初の読み取り専用エージェントを手軽にチームへ導入することができます。

- Google、AI Transformation および FinOps コンサルタント、Samuel Moss

- Google、AI Transformation コンサルタント、Celine Devie

ゲームチェンジャー: エージェント型 AI を使用してインフラストラクチャコードを保護する

Thu, 01 Oct 2026 02:00:00 +0000

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

AI は、かつてないペースでソフトウェア開発を加速させています。しかし、コード生成が拡大するにつれて、コードのセキュリティを確保する課題も増大しています。特に、AI を利用した新たな脆弱性の悪用が懸念されています。こうした課題に対処するため、Google AI およびインフラストラクチャチームは、セキュリティへの取り組み方を変革しています。この記事では、Google が開発した新しい AI ネイティブなエージェント手法について説明します。この手法は、高精度で網羅的な脆弱性スキャンとパッチ適用を、Google のソフトウェア開発ライフサイクルに体系的かつ直接組み込むものです。Google は、インフラストラクチャにデプロイされる数億行に及ぶコードのあらゆる変更を継続的にスキャンすることで、毎月数百件もの脆弱性がコードベースや本番環境に混入するのを未然に防ぎ、グローバルネットワーク、AI インフラストラクチャ、そしてユーザーを保護しています。

ソリューションアーキテクチャと実装

送信前のエージェント型スキャンを徹底: 継続的なソフトウェア開発の一環としてのセキュリティ

従来、テクノロジー業界は、処理に時間がかかり、十分なコンテキストを把握できない単発の大規模なセキュリティスキャンに頼ってきました。その結果、脆弱性の発見が遅れることがよくあります。Google のアプローチでは、これとは異なり送信前スキャンに焦点を当てています。AI エージェントを活用し、スタックのあらゆるレイヤにおいて、コードのチェックインをリアルタイムで評価します。デベロッパーの使い慣れたツールに送信前スキャンを統合することで、セキュリティは、ルールチェッカーや可読性レビューなどのソフトウェア開発ツールと同じように、開発プロセスにおける日常的なルーティン作業になります。また、AI の観点から見ると、個々のコード変更をスキャンする方が、大規模な 1 回限りのスキャンを実行するよりもはるかに少ないコンテキストで済むため、スキャンの効果が大幅に向上します。

ローカライズされた脅威モデルの重要性

この取り組みのために、Google はオープンソースのマルチエージェントレビューハーネスである Mantis を進化させ、ローカライズされた堅牢な脅威モデルのコホートと照合することで、セキュリティエージェントの精度を高めました。脅威モデルは、コードから切り離された静的なドキュメントに依存するのではなく、リアルタイムのコードベースメタデータを使用します。スキャンエージェントは、パッケージやライブラリ間の依存関係コールグラフを使用し、脅威モデルのコンテキストを拡張および洗練させることで、精度をさらに向上させます。脅威モデルを継続的な脆弱性スキャンの一部に組み込むことで、開発者が脅威や依存関係を常に更新するようになり、モデルを最新の状態に保つことができます。ローカライズされた正確な脅威モデルデータを使用することは、精度の劇的な向上に直結しており、場合によっては偽陽性率をわずか 3% にまで抑えることができます。

専門のトリアージエージェントが開発を加速

コードチェックインの一環として脆弱性スキャンを行う場合、エンジニアリングの生産性を妨げないよう、コードを生成する開発者やエージェントに迅速に対応する必要があります。低レイテンシで回答を得るために、2 段階の検証プロセスを実行しています。まず、迅速な軽量スキャンを実行し、その結果を専門のトリアージエージェントで検証します。このエージェントは、コードの実際の構造をプログラムでチェックし（抽象構文ツリーの解析、コールグラフの走査、事前インデックス化されたドメイン安全ルールを使用）、脆弱なパスが実際に攻撃者によって到達可能であることを証明します。このエージェントは 92% 以上の精度を達成し、1 分以内に作業を完了します。次に、夜間の統合テストの一環として、送信後のスキャンが第 2 の防御層として機能し、オフピークサイクルを使用して、複数の変更にわたって導入された可能性のある脆弱性をテストします。

バグ修正エージェントがループを閉じる

脆弱性を見つけることは、解決への道のりの半分にすぎません。Google のソリューションの最後のコンポーネントは、スキャン結果と生成された実証コード（脆弱性がどのように再現されるかを示すコードスニペット）を使用して、Google の社内コーディング標準に合致した正確な修正案を自律的に生成する自動バグ修正エージェントです。エージェントは、元の変更リクエストのレビューの一環として、人間によるレビューのために修正を送信します。これにより、検出から解決までの時間がさらに短縮されます。

学んだことと行動喚起

継続的なスキャンをソフトウェア開発ライフサイクルに直接組み込むことは、Google においてまさにゲームチェンジャーとなりました。AI が提示する修正案は広く採用されており、数多くの脆弱性がコードベースに混入するのを未然に防いでいます。セキュリティ向上を目指す組織であれば、次の原則に従うことで、同様の AI ネイティブなアプローチを導入することが可能です。

システムを分離する: バイアスを防ぐため、開発、スキャン、トリアージの各エージェントのハーネス、ルール、コンテキストを分離します。軽量な AI スキャンと決定的かつ構造的な検証を組み合わせることで、レイテンシを短縮し、精度を向上させます。
コンテキストを賢く使用する: 既存の脅威モデルをエージェントにフィードします。偽陽性を減らすには、正確なコンテキストが不可欠です。また、最新の脅威モデルを使用することで、送信前スキャンの真陽性率が向上し、チームのセキュリティポスチャーの最低基準が引き上げられます。
優れたハーネスを構築する: 基盤となるモデルの選択は重要ですが、マルチエージェントハーネスを使用すると、モデル選択のばらつきを補うことができるため、大きな効果が得られます。
修正を自動化する: エージェントを使用して、人間参加型の修正を提案し、解決までの時間をさらに短縮します。

独自の AI ネイティブなセキュリティ変革を始めたい場合は、Mantis がオープンソースとして公開されていますので、ぜひ活用してそのメリットをお役立てください。また、サイバーセキュリティの基礎や、このエージェント型パイプラインを支える他のプラットフォーム（Google Cloud、Gemini Enterprise、Trillium および Ironwood TPU で実行される Gemini モデル）についても詳しく学ぶことができます。また、Google Cloud のセキュアなソフトウェア開発のライフサイクル（SDLC）の取り組みに不可欠な要素として、エージェント型の脆弱性スキャンと修復が Google Cloud のお客様をどのように保護しているかについても、ヒントを得ることができます。

^{この成果の実現に多大な貢献をした主要メンバーである、Stella Voutsina（リードプログラムマネージャー）、Yulong Zhang（シニアスタッフセキュリティエンジニア、Mantis）、Nick Galloway（スタッフセキュリティエンジニア、Mantis）に心からの敬意を表します。}

- Google、上級エンジニア、Andrés Lagar-Cavilla

- バイスプレジデント兼エンジニアリングフェロー、Parthasarathy Ranganathan

Google Public Sector でエージェントの時代におけるサービス提供の定義を一新

Thu, 01 Oct 2026 02:00:00 +0000

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

州政府や地方自治体は、迅速かつ公平で、利用しやすいサービスを提供するという共通の使命を担っています。しかし、老朽化したシステムの技術的負債、分断されたデータ、そして重い事務負担が使命の遂行を遅らせ、この目標の達成を阻む要因となっています。

このようなシステム上の断片化は、公共部門全体で費用のかかる運用上のボトルネックを生み出します。

レガシーデータのサイロ化: ケースワーカーの重要な情報は、多くの場合、別々の部門が管理する独立したリポジトリに保存されています。
手作業によるボトルネック: 行政機関の職員は、日常的なデータ入力や手作業での書類作成の処理に、多大な時間を費やしています。
関係者とエンドユーザーのストレス: レガシーシステム同士が連携していないため、ユーザーは異なるプラットフォームでまったく同じ証明書類を何度も提出させられることがよくあります。

現在、エージェントはサイロを解消し、定型業務や手作業を自動化することで、行政機関の職員が価値の高い公共サービスや、本来の使命である「人間にしかできない温かみのある業務」に集中できるよう支援しています。

AI は州の CIO にとって最優先事項

公共部門全体で、AI は試験的なものから戦略の中核へと急速に進化しています。この変化を反映して、全米州最高情報責任者協会（NASCIO）の州 CIO 年次トップ 10 レポートでは、最近初めて AI が州 CIO の最優先事項にランクインしました。この優先順位の再定義は、州や地方自治体の未来にとって極めて重要な意味を持ちます。州の行政機関が山積する事務処理、インフラストラクチャの老朽化、そして変化する住民の期待に直面するなか、CIO は、インテリジェントな自動化こそが職員の対応力を高め、ケースワーカーのワークフローを合理化し、より迅速で公平なサービスを地域住民に提供するための中核的な手段であると認識しているからです。

行政機関が AI の試験運用や実証実験から本格的な導入へと移行するなか、多くの機関にとって中心的な課題となっているのは、「既存のレガシー投資と最新のサービス提供とのギャップを、AI を活用してどのように埋めるか」ということです。

AI を活用して成果につなげる

Google は、スピード、スケール、費用効率に重点を置き、手動によるシステム統合の煩わしさを解消するように設計された統合 AI スタックを提供しています。Google Public Sector と提携して AI を活用している公共部門の組織をいくつか詳しく見ていきましょう。

ユタ州運輸省（UDOT）: 52,000 以上の土地区画を特定して地図化するという膨大なタスクに直面していました。当初は膨大な手作業により完了まで 33.5 年を要すると見積もられていましたが、UDOT は BigQuery 上に統合データプラットフォームを構築することで、プロジェクト全体を 1 年未満で完了し、エンジニアが道路の安全性向上に専念できる環境を整えました
ハートフォード市: AI を使用して、すべての公聴会で 80 言語のリアルタイム双方向翻訳を提供。参加の機会を広げつつ 130 万ドルの構造的コスト削減を達成し、インクルーシブなガバナンスの全米ベンチマークを確立しました。
チャタヌーガ市: Google Cloud の AI と分析ツールを使用して市内の交通事故やインシデントデータを一元化。都市計画担当者や公安チームが危険な路線を特定し、信号機のタイミングを最適化し、インフラストラクチャ投資の優先順位を判断できるようにすることで、住民がより安全に通行できる街路を実現しています。
インディアナ州運輸局（INDOT）: Google Cloud の AI とドキュメント分析モデルを導入し、膨大な調達契約リポジトリ全体におけるコンプライアンス監査の自動化と、スマート道路インフラストラクチャの拡張を実現しました。有資格のエンジニアを進行中の現場プロジェクトから引き離すことなく、30 日という厳しいコンプライアンス要件を満たすことで、このソリューションはシニアエンジニアの労働時間を 360 時間削減。同時に道路資産の検出を自動化して、州全域の住民に向けて、より安全で適切に維持管理された高速道路を確保しました。
ロサンゼルス市: 2026 年のワールドカップ、2027 年のスーパーボウル、2028 年のオリンピック / パラリンピックといったグローバルイベントの開催を控え、膨大な運営負荷に直面している同市は、45 の部門と 27,500 人の職員の日常のワークフローに Gemini を直接統合しています。市職員の能力を何倍にも高める原動力として機能するこのプラットフォームは、複雑な事務作業を自動化して組織の対応力を強化。サービス提供を迅速化するとともに、1,500 万人を超える予想訪問者と 400 万人の住民が話す 224 以上の言語に対応する多言語サポートを拡大します。
メリーランド州: Google Public Sector と提携し、プライバシーを重視したセキュアなクラウド基盤内で Gemini と Gemini Notebook を使用して、4 万人にのぼる職員を支援しています。認知負荷を軽減し、反復的な管理タスクを自動化することで、州政府の担当チームはわずか 5 週間で水質管理アプリケーションを構築、デプロイしました。これにより、数千時間におよぶ職員の労働時間を削減し、環境監督業務を迅速化。メリーランド州全域の住民に向けて、より迅速で持続可能な公共サービスの提供を実現しました。

Google Public Sector で AI への取り組みを加速

エージェントの時代とは、人間の能力を強化し、公共サービスを支えるリーダーや構築者を支援することにほかなりません。公共部門の組織は、Google Cloud の統合 AI スタックを活用して、ステークホルダーへのサービス提供、職員の能力向上、そしてミッション推進のあり方を再定義しています。Google Public Sector は、よりレジリエンスが高く、対応力に優れ、シームレスにつながる行政機関をともに構築していくため、先駆的な組織の皆様とパートナーとして協働できることを心から楽しみにしています。

10 月 20 日に開催される Google Public Sector Summit にぜひご参加ください。エージェントの時代に AI を活用してサービス提供のあり方を再定義している公共部門のリーダーたちの講演をお聞きいただけます。

- Google Public Sector、米国州政府、地方自治体、教育機関担当マネージングディレクター、Matt Schneider

Secure Source Manager の新機能で CI / CD パイプラインを強化

Thu, 01 Oct 2026 02:00:00 +0000

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

レジリエンスを備えたソフトウェアサプライチェーンは、最新のデリバリーの基盤であり、継続的インテグレーションと継続的デリバリー（CI / CD）パイプラインを保護することこそが、イノベーションを安全に推し進める原動力となります。

Wiz の最新のクラウド脅威ハイライトレポートによると、2026 年上半期の注目すべきサプライチェーン攻撃は、2025 年下半期と比較して 2 倍以上に急増しています。

プライベートクラウドにおいて、ソースコードが最も脆弱な部分にならないようにすることが重要です。ソフトウェアサプライチェーンの脅威に、より効果的に対処できるよう、Google Cloud Secure Source Manager（SSM）では、統一された認証と認可の仕組みを使用して、ソースコードと CI / CD システムを管理できます。

Google は、開発と CI / CD ワークフローを簡素化し、セキュリティを高める 2 つの新機能の一般提供を開始しました。

CI / CD システムへの不正アクセス: 攻撃者は、デプロイスクリプトをたった 1 つ改ざんするだけで、CI / CD パイプラインをマルウェアの拡散ルートに変貌させてしまいます。このリスクを軽減するため、SSM は、バージョン管理システムからビルドやアーティファクトのシステム、デプロイツールに至るまで、たとえ企業ネットワークが侵害された場合でも、CI / CD システムへの不正アクセスをブロックできるようになりました。
権限を持つユーザーによるコードの不正な変更: 新しい Code Owners システムは、ファイル単位、ブランチ単位で pull リクエストの承認者セットを管理し、よりきめ細かい Identity and Access Management（IAM）を提供します。Code Owners は、コードの記述、編集、レビューを行うエンジニアを支援します。リポジトリ内のファイルとディレクトリに、ファイル単位またはブランチ単位で追加の保護ルールを適用します。

主な機能

CI / CD パイプラインへのソースコード変更をはじめとして、新しい Code Owners 機能はきめ細かいマージガードを提供します。CODEOWNERS ファイルをリポジトリにチェックインすることで、必要な承認者を極めて詳細に指定できます。

パスごとの承認者セット: 柔軟な glob スタイルのパス指定子を使用して、一致するファイルへの変更に対して、指定されたユーザーセットの 1 人以上による承認を必須にすることができます。
ブランチ固有のガバナンス: セキュリティルールとデプロイルールをブランチ間でスムーズに管理できます。同じファイル内で main や dev に異なるオーナーを定義できるため、既存の CODEOWNERS ソリューションで発生するマージコンフリクトを解消できます。詳しくは、こちらのドキュメントをご覧ください。
ネスト可能な複数ファイルのオーナー設定: 5,000 行にも及ぶような巨大なルートファイル 1 つに縛られる必要はありません。CODEOWNERS ファイルはサブディレクトリにネストできます。SSM は「ローカル優先」ロジックを採用しているため、サブチームがそれぞれのフォルダのオーナー権限を持ちつつ、ルート管理者はリポジトリ全体に対する拒否権を維持できます。
独立した承認セクション: [SectionName][count] 構文（例: [Security Team][2]）により、1 つの pull リクエスト（PR）において、複数の部門からの個別の承認を同時に義務付けることが可能になります。PR 自体はチームのメンバーによってレビューされても、セキュリティチームのメンバー 2 人による承認が揃うまではマージできないようになっています。

ソースコードの準備が整ったら、SSM の新しい Developer Connect 連携により、CI / CD システムとランタイムが異なるプライベートネットワークにある場合でも、セキュアかつ簡単に接続できるようになります。

プライベート CI / CD ブループリントのアーキテクチャは、セキュアな接続経路を採用しています。Secure Source Manager が Private Service Connect に接続し、そこからさらに Cloud Build へと接続されます。リポジトリ、ビルドプール、アーティファクトストレージはすべてプライベートネットワーク内に配置され、VPC Service Controls（VPC-SC）が多層防御を提供することで、プロキシエンドポイントへのアクセスを制限します。

次のステップ

ネットワークを保護するには、新しいプライベートネットワークの統合ガイドに沿って、Developer Connect を使用して SSM を Cloud Build に接続します。

pull リクエストの承認を保護するには、ルート CODEOWNERS ファイルを作成して、一律の IAM「承認者」ロールを、ファイル固有のオーナー権限に置き換えます。

- Google Cloud、プロダクトマネージャー、Logan Henriquez

Cloud Blog JA

分析の高速化: PayPal の Managed Service for Apache Spark 導入事例

困難な分析環境を乗り切る

複雑さにより生じた停滞

ソリューション: 統合されたクラウドネイティブな分析

結果: 分析情報の迅速な取得、オーバーヘッドの低減

AI 駆動で進める、クラウド移行と運用のこれから。AI-Ready Infra & DB Summit '26

基調講演のテーマは「AI が使う基盤、AI で作る基盤」

お客様 4 社が、基盤づくりと移行の実例を紹介

Google Cloud が、AI 駆動型の移行と運用のアプローチを紹介

会場に来た方だけの特典も

AI エージェントを現場実装する 2 日間、Agentic AI Summit '26 Fall

Day 1 は全社展開の実例がそろう

他社の事例を一気に見るならピッチ コンテスト

Day 2 は丸ごとエンジニア向け

作って試すなら Builder Day

会場に来た方だけの特典も

AlloyDB がエージェント向け PostgreSQL を提供: ワークロードを完全に分離し、エージェント規模でリアルタイム データを処理

重要である理由

AlloyDB 独自の PostgreSQL エージェント アーキテクチャ

提供状況

Google Cloud パートナー、Gemini Enterprise を活用して新たなセキュリティ エージェントと AI 防御機能を提供

Gemini Enterprise で構築された、新たなセキュリティ エージェントとエージェント型防御のご紹介

エージェントの時代における妥協のない新しいデータベース アーキテクチャ

真のエージェント型データベース アーキテクチャに必要な 3 つの原則

AlloyDB のエージェント アーキテクチャ

既存のアーキテクチャが 3 つの原則をすべて満たせない理由

分離された共有ストレージ サーバー

共有ブロック サーバーを使用したオブジェクト ストレージ

既存アーキテクチャの評価

AlloyDB をスタック全体でどのように構築したか

AlloyDB のエージェント型データベース アーキテクチャの評価

3 つの原則すべてを設計に組み込む

本番環境に影響を与えることなく、エージェントにライブデータを提供

IO 負荷の高いワークロードに適した、ストレージ最適化 Z4D マシン ファミリーの一般提供が開始

Z4D の VM インスタンスとベアメタル インスタンス

お客様とパートナー様の声

メンテナンスの利便性の向上

Hyperdisk のサポート

Z4D を今すぐ使ってみる

強化学習（RL）による Gemini モデルのカスタマイズに関するベスト プラクティス ガイド

RLFT とは

RLFT を使用する状況

RLFT のユースケース

どこから始めるべきか

使ってみる

オーケー: AlloyDB と Database Migration Service で「止められない基幹システム」を移行し、データドリブンな価値創出を加速

ビジネスの急成長を受けて高まった、2 つの基幹データベース刷新の必要性

AlloyDB の採用により、業務の根幹を支えるデータベースの移行と基盤統一を実現

Gemini や AlloyDB AI も活用しながら、DX と新たな価値創出を追求

Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出

AI インフラストラクチャで優れたパフォーマンスと効率を実現

エージェント インフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

サーバーレス コンテナによる次世代のデベロッパー エクスペリエンス

次のステップ

日々のマイクロ ハビットを活用して企業における AI 構築担当者ーをスキルアップする方法

ワークショップから日々の実践へ

Advent of Agents プログラムから得た教訓

マイクロ イネーブルメントを実践する

小さく始めて、頻繁に構築する

ガバナンスが組み込まれた、AI 支援による EKS から GKE への移行を実現する GKE エージェント型移行の概要

インフラストラクチャの移行に伴う課題

GKE エージェント型移行の概要

仕組み: 移行のライフサイクル

使ってみる

AlphaEvolve で動画処理を高速化する方法

1. AlphaEvolve の分割ループ アーキテクチャを理解する

2. 評価ツールの機能と品質ゲートを適用する

自律的なアルゴリズム検出を活用する

現実的なパフォーマンス境界を設定する

AlphaEvolve を最大限に活用するには、理論上の最大ヘッドルームを基準に測定する必要があります。

実際に使ってみる

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

リソース オプション

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

まとめ

次のステップ

ボーダーレスな Lakehouse を加速: クロスクラウド キャッシュのプレビュー版を発表

クロスクラウド キャッシュの仕組み

クロスクラウド キャッシュの実際の操作

他社の事例を一気に見るならピッチコンテスト

AlloyDB がエージェント向け PostgreSQL を提供: ワークロードを完全に分離し、エージェント規模でリアルタイムデータを処理

AlloyDB 独自の PostgreSQL エージェントアーキテクチャ

Google Cloud パートナー、Gemini Enterprise を活用して新たなセキュリティエージェントと AI 防御機能を提供

Gemini Enterprise で構築された、新たなセキュリティエージェントとエージェント型防御のご紹介

エージェントの時代における妥協のない新しいデータベースアーキテクチャ

真のエージェント型データベースアーキテクチャに必要な 3 つの原則

AlloyDB のエージェントアーキテクチャ

分離された共有ストレージサーバー

共有ブロックサーバーを使用したオブジェクトストレージ

AlloyDB のエージェント型データベースアーキテクチャの評価

IO 負荷の高いワークロードに適した、ストレージ最適化 Z4D マシンファミリーの一般提供が開始

Z4D の VM インスタンスとベアメタルインスタンス

強化学習（RL）による Gemini モデルのカスタマイズに関するベストプラクティスガイド

エージェントインフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

サーバーレスコンテナによる次世代のデベロッパーエクスペリエンス

日々のマイクロハビットを活用して企業における AI 構築担当者ーをスキルアップする方法

マイクロイネーブルメントを実践する

1. AlphaEvolve の分割ループアーキテクチャを理解する

リソースオプション

ボーダーレスな Lakehouse を加速: クロスクラウドキャッシュのプレビュー版を発表

クロスクラウドキャッシュの仕組み

クロスクラウドキャッシュの実際の操作

ゲームチェンジャー: エージェント型 AI を使用してインフラストラクチャコードを保護する

ソリューションアーキテクチャと実装

専門のトリアージエージェントが開発を加速