Cloud Blog JA

金融サービスにおけるエージェント型 AI を活用したオペレーショナルレジリエンスの構築

Fri, 28 Aug 2026 01:00:00 +0000

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

金融機関にとって、オペレーショナルレジリエンスは、消費者の高い期待はもとより、規制当局や監督当局の期待事項として長年織り込まれてきました。欧州連合のデジタルオペレーショナルレジリエンス法（DORA）の施行により、こうした期待は一段と厳格なものとなり、より明確で整合性が取れた、エビデンス重視の要件が課されるようになりました。企業は、重要なビジネスサービスとそれを支えるデジタルインフラストラクチャが、業務の中断に耐え、連携した対応を可能にし、統制を保った状態で復旧できることを実証しなければなりません。

これらの条件を満たすために、Deutsche Bank は AI 搭載のエージェント型レジリエンスプラットフォームを開発しました。これにより、規制に関する机上レジリエンス演習を大規模にモダナイズし、手動で行っていた準備作業を、実際の運用データに基づいたコンテキストアウェアで、かつ即座にエビデンスとして活用可能なシミュレーションへと刷新しました。このプラットフォームは、アーキテクチャ、データフロー、ログ、インシデント履歴、アラートシグナル、運用テレメトリーからエンタープライズコンテキストを構築し、シナリオ、シミュレートされた運用エビデンス、構造化されたセッションレコード、規制当局に対応したアーティファクトを生成します。

相互に依存するアプリケーション、データフロー、サードパーティサービスにまたがる業務を抱える多くの大手銀行にとって、これは重要かつ不可欠な変化です。金融サービス全体で監督当局の期待が高度化するなか、銀行の机上演習においても、本番環境の依存関係や実際の運用条件、そして一貫したエビデンス基準への準拠を、より直接的に反映させることが求められています。

Deutsche Bank は、この移行を大規模かつ効率的に成功させる方法を検討するにあたり、長年のパートナーである Google Cloud と、その拡大するエージェント型 AI ツールのスイートに注目しました。

机上演習からレジリエンスインテリジェンスへ

Deutsche Bank は、エージェント型レジリエンスプラットフォームを活用することで、従来の手動による準備を伴う机上演習を、継続的なインテリジェンスモデルへと進化させました。さらに、実際の運用コンテキストが必要な場合には、この同じエージェントレイヤを根本原因分析にまで拡張して活用できるようになっています。

つまり、実行されるすべてのシナリオが、実際のエンタープライズシグナルに基づいたものとなっています。これにより、リアルタイムのインサイトよりも推測に陥りがちな「静的な入力」に頼るのではなく、実際のシステム依存関係や障害パターン、ビジネスへの影響を正確に反映できるようになります。

Gemini Enterprise Agent Platform を使用することで、Deutsche Bank はこの運用コンテキストを、明確なタイムライン、意思決定ポイント、予想される回答を含む構造化されたシナリオに移行できました。これにより、各演習は実際のシステム動作に基づいたものとなり、規制当局の期待に応える、一貫性のある監査対応のエビデンスを確実に生成できるようになっています。

制御と柔軟性を実現するデュアルオーケストレーション

規制当局レベルの制御と運用の柔軟性を両立させるため、Deutsche Bank のプラットフォームには、ワークフローを 2 つの補完的な実行モデルに分離するデュアルオーケストレーションアーキテクチャが採用されました。

まず、規制に準拠した実行を実現するため、同行は LangGraph を活用しています。これにより、入力コンテキストから出力まで明確なリネージを備えた、追跡可能かつ決定論的なプロセスを通じてすべてのシナリオを生成し、監督審査で求められる監査可能性を担保しています。

次に、適応型シナリオと調査型シナリオについては、Google Agent Development Kit（ADK）を使用してエージェント主導の連携を実現しています。このアプローチにより、同行のプラットフォームは、あらかじめ実行パスを定義しておく必要がなく、状況を動的に分析して回答を生成できるようになります。

図 1. コンテキストアセンブリ、オーケストレーション、シナリオ生成のアーキテクチャ。

このアーキテクチャ上の分離により、プラットフォームは共通のインテリジェンスレイヤを維持しながら、統制された実行と適応型の調査を組み合わせることができます。同一のエージェントとツールを使用して、机上演習シナリオの生成から関連するインシデント分析ワークフローに至るまで、アーキテクチャ、データフロー図、ログ、コードアーティファクトを横断的に推論できます。重要なのは、計画された演習と実際の運用イベントの両方で一貫したレジリエンスモデルがサポートされることです。

「Deutsche Bank がこのプラットフォームで目指したのは、極めて複雑な分散環境においても、規制当局の期待に応える重要金融システム向けのレジリエンスモデルを構築することでした。動的に生成されたシナリオを実際のビジネスコンテキストに結びつけ、統制されたオーケストレーションと適応型の分析を組み合わせることで、このプラットフォームは、オペレーショナルレジリエンスのためのインテリジェントで継続的に適応可能なモデルを当行にもたらしました。」- Deutsche Bank、マネージングディレクター、監視テクノロジーおよびコンプライアンスクラウド担当グローバル責任者、AI トランスフォーメーションリード、Sanjay Tripathi 氏

Google Cloud で生成とガバナンスを強化

Google Cloud のエージェントツールスイートは、Deutsche Bank のプラットフォームを、管理されたエンタープライズグレードのレジリエンスワークフロー全体にスケールするための基盤を提供しています。その仕組みは次のとおりです。

Cloud Run が、シナリオおよびエビデンス生成サービスの弾力的な実行をサポートします。
Gemini Enterprise Agent Platform が、運用コンテキストを構造化されたレジリエンスシナリオに変換します。
Google ADK が、適応型エージェントの連携を可能にします。
Cloud SQL が、シナリオ、セッションアーティファクト、レビュー記録に対して、高い耐久性と永続性を提供します。

これらのサービスを組み合わせることで、コンプライアンスレビューと継続的な改善に不可欠な、追跡可能な生成、制御された実行、永続的なエビデンス記録の保持を、Deutsche Bank が実現できるようになります。

スケーラブルでエビデンス対応のレジリエンステスト

Deutsche Bank のプラットフォームで生成されるあらゆるシナリオは、対応、エスカレーション、復旧を担うチームの構造化された机上演習セッションを推進します。これらの演習は実際のエンタープライズコンテキストに基づいているため、運用の実態を反映すると同時に、チーム間の一貫性を強化し、規制当局の期待に応える監査対応のエビデンスを生成します。これにより、DORA や同様のフレームワークの規制下にある金融機関にとって、統制され、連携の取れた、規律ある対応を大規模に実証することが容易になります。

このモデルは現在、Deutsche Bank の複数のポートフォリオに適用されており、同行がより一貫性のあるスケーラブルなレジリエンスパラダイムを確立し、金融セクター全体で活用できる再現可能なブループリントを構築する一助となっています。

このモデルでは、根本原因分析が実際のインシデントと将来のレジリエンステストの間のフィードバックループとして機能します。本番環境のイベントから得られたインサイトは、将来の机上演習シナリオに反映させることができます。また、演習の結果は、対応ハンドブック、エスカレーションパス、復旧準備の強化に役立てられます。

こうした一連の取り組みにより、シナリオベースのレジリエンステストを主なユースケースとして維持しつつ、計画的なレジリエンス演習から実際の運用イベントに至るまで、プラットフォームの価値が拡張されます。

導入が拡大するにつれて、このプラットフォームはコンテキストアウェアなレジリエンスに関する Google Cloud の手法を組み込むことで、運用の一貫性をもたらします。また、断片的な手動アプローチを解消し、同行全体で部門横断的な AI 活用型運用モデルを確立します。

レジリエンスインテリジェンスに向けて

同行の次のステップは、このアプローチをより広範なレジリエンスインテリジェンスレイヤへと拡張することです。同じパターンを展開することで、ハンドブックの改良、復旧準備の評価、そして刻々と変化するシステム状況に対する制御の継続的検証が可能になります。

金融機関にとって、これは戦略的な転換です。システムの分散化が進み、規制当局からの要求が厳しさを増すなか、銀行は定期的なレジリエンステストから、インテリジェンス主導の継続的な対応能力へと移行する必要があります。Deutsche Bank では、Google Cloud によって組織全体でこの移行を簡単に行うことができています。

コンテキストアウェアなレジリエンスに関する Google Cloud の手法について詳しくは、こちらの記事をご覧ください。

- Deutsche Bank、エージェント型レジリエンスプラットフォーム - ディレクター兼リードアーキテクト、Pankaj Ojha 氏

- Google Cloud コンサルティング、スタッフソリューションコンサルタント、Florian Graf

構造化データと非構造化データのインサイトを統合する BigQuery 検索のイノベーション

Fri, 28 Aug 2026 00:10:00 +0000

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

現代の企業は膨大な量の非構造化データを保有しており、その管理や価値の抽出において大きな課題に直面することがよくあります。これまで、PDF、音声ファイル、画像、非構造化テキストに埋もれたインサイトを引き出すには、ウェアハウスからのデータ移動、複雑な LLM パイプラインの統合、散在する検索インデックスの管理といった、断片化されたアーキテクチャを前提とする必要がありました。

BigQuery は、こうした非構造化データを理解するために多くの企業で活用されています。たとえば、数千件に及ぶ臨床試験ドキュメント（PDF）を管理する先進的なヘルスケア企業では、BigQuery を使用することで、アクセス、処理、グラウンディング、関連付け、活用というシンプルな 5 段階のライフサイクルを通じて、これらのドキュメントから価値あるインサイトを抽出できます。

この投稿では、このフレームワークの「グラウンディング」のフェーズに重点を置いた 3 つの主要なマイルストーンを紹介します。

自律型エンベディング生成（一般提供版）
単一クエリのパフォーマンスが大幅に向上する AI.SEARCH（一般提供版）
ハイブリッド検索（公開プレビュー版）

これらの機能が連携して AI アーキテクチャを簡素化する仕組みを、実際の臨床試験研究プラットフォームを例に詳しく見ていきましょう。

パイプラインを簡素化する「自律型エンベディング生成」（一般提供版）

検索拡張生成（RAG）パイプラインや検索アプリケーションを構築するには、通常、複雑で非同期なエンベディングインフラストラクチャの管理が必要であり、新しいレコードが到着するたびに、再試行、エラーロギング、パイプラインのオーケストレーションを自分で行わなければなりません。

このたび、自律型エンベディング生成の一般提供が開始されたことで、BigQuery がユーザーに代わってこれらをすべて管理できるようになりました。スキーマで列を定義するだけで、新しいデータが取り込まれるたびに BigQuery が非同期かつ継続的にエンベディングを生成します。外部モデル（Vertex AI テキストエンベディングなど）を選択することも、BigQuery 内で Gemma エンベディングモデルをネイティブに直接利用することもできます。

実際の活用例

たとえば、Google Cloud Storage に保存されている臨床試験の PDF を分析する研究プラットフォームを構築しているとします。研究のタイトルや疾患領域をテーブルに抽出すると、そのタイトルを自動的に埋め込むことができます。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE TABLE mydataset.clinical_trials\r\n(\r\n trial_id STRING,\r\n study_title STRING,\r\n study_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>\r\n GENERATED ALWAYS AS (AI.EMBED(\r\n study_title,\r\n connection_id => 'myconnection',\r\n endpoint => 'text-embedding-005'\r\n ))\r\n STORED\r\n OPTIONS( asynchronous = TRUE )\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ece66850>)])]>

BigQuery は、1 つの構成でエンタープライズ規模の処理を管理することで、複雑なサードパーティのベクトルデータベースを不要にします。この自律的なエンベディング生成により、ソーステキストの変更に合わせてデータが自動的に同期されるため、手動による ML パイプラインが不要になります。この統合アプローチにより、動的なデータセットのワークフローが効率化され、カスタムデータスクリプトの維持管理にかかる運用上の負担が軽減されます。

さらに、この一般提供の開始に伴い、自律型エンベディング生成では ObjectRefs を使用して画像からネイティブにエンベディングを生成できるようになり、真のマルチモーダル検索と分析が可能になりました。

大規模な自然言語検索を可能にする「AI.SEARCH」（一般提供版）

会話型分析エージェントや快適なユーザーエクスペリエンスを真に実現するには、基盤となる検索インフラストラクチャが直感的かつ高性能である必要があります。

データをシームレスに埋め込むことができたら、次は、それらを効率的にクエリする手段が必要となります。このたび一般提供が開始された AI.SEARCH() は、自然言語に焦点を当てた合理的な検索エクスペリエンスを提供するもので、これにより、検索パスでエンべディングを生成することなく、意味的に関連するレコードを簡単に見つけることができます。また、自律型エンベディング生成と組み合わせることで、データセットで使用しているエンベディングモデルをそのまま検索にも利用できるため、利便性がさらに高まります。

さらに、昨年実施した効率化への投資の一環として、AI.SEARCH を単一クエリの実行向けに大幅に最適化しました。その結果、オンラインアプリケーションや単一クエリ検索（エージェント検索で最も一般的なもの）において、スロット効率が最大 133 倍向上したことが確認されています。

このことは、BigQuery 上のデータに対して、ユーザー向けの自然言語検索を高い同時実行性で処理しつつ、従来よりも高速かつ費用対効果の高い方法で提供できることを意味しています。

code_block: <ListValue: [StructValue([('code', 'SELECT base.trial_id, base.study_title, distance\r\nFROM\r\n AI.SEARCH(\r\n TABLE mydataset.clinical_trials,\r\n \'study_title\',\r\n "What treatments are available for advanced tumors?"\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ee3b3590>)])]>

キーワードとベクトルを統合する「ハイブリッド検索」（公開プレビュー版）

セマンティック（ベクトル）検索は非常に強力です。たとえば、上記のクエリでは、「化学療法」のような概念的に関連する用語も適切に返すことができます。しかし、セマンティック検索だけでは十分でない場合もあります。たとえば、研究者が、非常に専門的な免疫療法薬の具体的な名称（「MK3475」など）を検索した場合はどうなるでしょうか。この英数字の文字列には広い意味的な文脈がないため、純粋なベクトル検索だけでは正しく順位付けすることが難しい場合があります。

BigQuery のハイブリッド検索は、語彙検索と既存のセマンティック機能を統合することで、キーワードの類似性とその根底にある意味の両方に基づいてデータを取得できます。このアプローチは、セマンティックベクトル検索の概念的な深さと、語彙マッチングの高い精度を統合するものであり、Reciprocal Rank Fusion や BM25 などのアルゴリズムを利用しています。これにより、検索結果の精度が大きく向上するほか、キーワードの出現頻度や意味的な関連性に基づく再ランキングを通じて、LLM のハルシネーションに伴う費用を抑えることができます。ユーザーは、AI.SEARCH 関数や VECTOR_SEARCH 関数で HYBRID モードや lexical_search_columns パラメータを利用することで、この仕組みを実装できます。さらに、ベクトルインデックスを拡張してキーワードデータを含めることで、パフォーマンスを最適化し、語彙検索プロセスを高速化できます。

以下のように、AI.SEARCH() 関数のモードを HYBRID に設定するだけで、ハイブリッド検索を簡単に実行できるようになりました。

code_block: <ListValue: [StructValue([('code', 'SELECT base.trial_id, base.study_title, distance\r\nFROM\r\n AI.SEARCH(\r\n TABLE mydataset.clinical_trials,\r\n \'study_title\',\r\n "Cancer treated by MK-3475",\r\n mode => \'HYBRID\'\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ec586010>)])]>

これらのハイブリッドクエリを大規模に高速化するには、検索の語彙部分で使用するキーワード列を含めるように CREATE VECTOR INDEX DDL を拡張するだけで、インデックスをネイティブに統合できます。

エンドツーエンドの非構造化データ分析プラットフォームの構築

ここで紹介した検索機能とエンベディング機能は、より大きなビジョンの一部にすぎません。Google は、エンドツーエンドの非構造化データ分析プラットフォームを構築しています。非構造化データの代表例のひとつがドキュメントであり、BigQuery は、以下のようなワークフローをエンドツーエンドで管理するための完全なツールセットを提供しています。

アクセス: オブジェクトテーブルを使用して、Google Cloud Storage に保存されている非構造化 PDF やドキュメントを直接クエリすることで、ゼロ ETL のワークフローを実現します。
処理: レイアウト対応のチャンキング（RAG に最適）には AI.PARSE や AI.CHUNK_DOC（近日リリース予定）などの組み込み AI 機能を利用するほか、エンティティ抽出 / 要約には AI.GENERATEを、SQL パイプラインで基盤モデルを直接使用してレコードを即座に分類するには AI.CLASSIFY を利用します。
グラウンディング: 自律型エンベディングとハイブリッド検索を使用して、精度の高いコンテキストを構築します。ハイブリッド検索は、セマンティックベクトル検索による概念的な理解と、語彙的なキーワードマッチングによる高い精度を組み合わせたものです。意味的な関連性とキーワードの出現頻度の両方に基づいて結果を再ランキングすることで、検索結果の精度が大きく向上するほか、LLM のハルシネーションも抑制できます。
関連付け: 抽出されたエンティティ（スポンサー、臨床試験、医薬品など）を BigQuery Graph にマッピングすることで、隠れたマルチホップのインサイトを発見できます。特別なグラフデータベースは必要ありません。
活用: BigQuery の会話型分析エージェントを活用して、これらすべてを統合します。AI.AGG などの関数を使用すると、複雑なデータと直接やり取りしたり、可視化を生成したり、大規模なトレンド分析を実行したりできます。

BigQuery において非構造化データが第一級のデータとして扱われるようになったことで、未加工のドキュメントと会話型 AI との間のギャップを埋めることが可能になりました。

準備ができたら

コードを確認する: BigQuery のドキュメント分析 GitHub リポジトリで、臨床試験に関するエンドツーエンドのデモの完全版をご覧ください。
ドキュメントを読む: 自律型エンベディングとハイブリッド検索の公式ドキュメントを読み、独自の統合データパイプラインの構築を今すぐ始めましょう。

- Google、プロダクトマネージャー、Joe Malone

- Google、エンジニアリングマネージャー、Francis Lan

ゼロコード、低コストのデータの取り込み: BigQuery DTS の新機能

Fri, 28 Aug 2026 00:00:00 +0000

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

急速に変化するデジタルエコノミーにおいて、データは最も重要なエンジンです。しかし、多くの企業は、脆弱な社内 ETL パイプラインの構築や修正に週 100 時間以上をかけたり、予測不可能なサードパーティツールと格闘したりといった犠牲を払う逆説的な状況に陥っています。

毎日、数千社のお客様が信頼して利用する BigQuery Data Transfer Service（DTS）は、このようなエンジニアリングの負担を解消します。フルマネージドのノーコードデータ移動ソリューションである BigQuery DTS は、BigQuery へのデータの取り込みを自動化し、チームがパイプラインのメンテナンスから戦略的なデータサイエンスへと数分で移行できるようにします。

エコシステムの拡大: 新しいコネクタと機能

BigQuery DTS は、データベース、広告、マーケティングプラットフォームにわたりデータサイロを排除するために、統合環境を急速に拡大しています。最新の追加機能と拡張機能は以下のとおりです。

オープンレイクハウスの取り込み

Apache Iceberg マネージドテーブルへの直接取り込み（プレビュー版）: Google Cloud Storage、Amazon S3、Azure Blob Storage などの一般的なソースから Iceberg マネージドテーブルにデータを直接取り込めるようになりました。これにより、BigQuery のトップレベルのパフォーマンスチューニングを活用しながら、マルチクラウドストレージと他のクエリエンジンとの完全な相互互換性を維持できます。

次世代のエージェント型アーキテクチャ

フルマネージドのリモート Model Context Protocol（MCP）サーバー（プレビュー版）: これにより、開発者は AI アプリケーションや AI エージェントを DTS に接続し、プログラムを使ってデータソースを検出したり、ユーザーに代わって転送を構成、実行したりできます。

エンタープライズデータベースとリレーショナルデータベース（完全転送と増分転送の両方をサポート）

Microsoft SQL Server（プレビュー版）: トランザクションテーブル、スキーマ、運用データを BigQuery 内の分析環境に直接転送し、簡単に一元化できます。
PostgreSQL（一般提供版）と MySQL（一般提供版）: データ配信を自動化し、大量のウェブワークロードやアプリケーションワークロードを一元的なデータウェアハウスに数分で簡単にレプリケートできます。オンプレミス環境、Cloud SQL、その他のクラウドからのデータレプリケーションに対応しています。

e コマースとグロースマーケティング

Shopify（プレビュー版）: 粒度の高い注文履歴、在庫ログ、顧客プロファイルを分析スキーマに直接抽出するプロセスを自動化します。
Klaviyo（プレビュー版）: 詳細なメールと SMS のエンゲージメントログ（クリック、送信、開封など）を抽出して、正確なマルチチャネルライフサイクル属性を構築します。
HubSpot（プレビュー版）: パイプライン、連絡先のトラッキング、インバウンドマーケティングの指標を同期して、収益オペレーションチームの連携を維持します。
Mailchimp（プレビュー版）: キャンペーンのパフォーマンスとオーディエンスリストの属性をデータウェアハウスに直接、自動的に移動します。

移行コネクタ

Snowflake（一般提供版）: 増分転送、スキーマの自動検出、プライベート接続、3 つの主要クラウド（Google Cloud、AWS、Azure）に保存されているデータの移行サポートなどの機能を使用して、Snowflake からデータを移行できます。

主要なコネクタの機能強化

ServiceNow、Salesforce、Oracle: ネイティブの増分更新サポートが強化され、エンタープライズ規模の CRM、ITSM、財務ワークフローの大規模なパイプライン更新が高速化されました。

BigQuery Data Transfer Service を選ぶ理由

エンタープライズアーキテクチャ内でデータを移動する際に、費用、管理オーバーヘッド、パイプラインの健全性の間で複雑な妥協を求められるべきではありません。BigQuery DTS は、次の 3 本の柱にわたって独自のメリットを提供します。

1. 比類のないコスト効率

主要なソースの取り込み費用はゼロ: Google 広告、Google アナリティクス 4、キャンペーンマネージャー、YouTube、Google Cloud Storage など、Google Play を除く Google のソースすべてのデータの取り込みが無料です。Amazon S3、Azure Blob Storage、Amazon Redshift、Teradata の取り込み費用も無料です。
サードパーティ SaaS は使用量ベースの低料金: サードパーティソースからの取り込みは、すべて柔軟な使用量モデルに基づきます。コンピューティング料金は、主要なリージョンでスロット時間あたり 6 セント未満です。料金は行数ではなくコンピューティングフットプリントに応じて変動するため、ソースデータの圧縮形式と利用可能なネットワーク帯域幅によっては、大量のデータを効率的に転送できます。

2. スムーズなセキュリティとネイティブ管理

中継サーバーや、外部のセキュリティと API の構成が不要になります。BigQuery DTS は Cloud IAM と完全に統合されています。データ転送は、追加の構成オーバーヘッドなしで、宛先データセットの列レベルのセキュリティ、行レベルのセキュリティ、顧客管理の暗号鍵（CMEK）を即座に継承します。ストリームは、ネイティブの Google Cloud 境界内で安全に流れます。

3. 業界トップクラスのパフォーマンスとレジリエンス

エンタープライズ規模でデータを管理する場合、ダウンタイムはビジネスの機会損失を意味します。BigQuery DTS は、高い復元力を持つ取り込みフットプリントを提供し、これは厳格な Google Cloud サービスレベル契約（SLA）に裏付けられています。システムは月間稼働率 99.99% 以上を実現し、分析、自動化されたパイプライン、運用ダッシュボードの更新を確実に保証します。

データ運用の変革を始めましょう

手動の取り込みスクリプトにビジネスの成長を制限される状況はもう終わりにしましょう。Google のネイティブクラウドレイクハウスデータ移動アーキテクチャを利用して、最新のスケーラブルなデータスタックを構築している数千社もの企業の仲間に加わってください。

今すぐプラットフォームをお試しください。BigQuery Data Transfer Service コンソールに移動し、コネクタを選択して、数回クリックするだけで最初の自動転送をデプロイできます。

次に構築すべきコネクタは？

Google は、お客様のビジネスニーズに基づいて、ネイティブ統合ライブラリを常に拡大しています。現在、手動で抽出せざるを得ないソースはあるでしょうか。次にレプリケートする必要がある特定のリレーショナルデータベース、NoSQL エンジン、リージョン SaaS プラットフォームについて、機能リクエストでお知らせください。

機能リクエストは、公開 Issue Tracker からお送りいただけます。

- プロダクトマネージャー、Vignesh Rajamani

- エンジニアリングマネージャー、Pallavi Palleti

Google Dataflow で費用対効果に優れた高スループットな生成 AI ワークフローを構築する

Thu, 27 Aug 2026 02:00:00 +0000

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

リアルタイムストリーミングパイプラインは現代の企業において運用のバックボーンとなっており、カスタマーサポートでのやり取りからトランザクションログまで、あらゆるデータを処理し続けています。従来のストリーミング DAG は静的なものであり、一度デプロイされると、その処理ロジックや実行パスは変更できなくなります。しかし、生成 AI エージェントを統合すれば、静的なロジックから適応型の実行へと移行することが可能です。これにより、データの内容に応じてストリーミングワークフローが実行時にプランを動的に立案し、データベースへのクエリや独自の修復処理を自律的に開始できるようになります。

たとえば、注文品の破損について顧客から不満を示すメッセージが届いた際、パイプラインの役割は単なるエラーログの記録や、ダッシュボードへのフラグ立てにとどまるべきではありません。顧客の注文と在庫の記録を保持するデータベースで注文情報を検索し、修復アクション（交換品の発送や払い戻しなど）を自ら判断して、顧客へのメール送信から最終的な対応結果の記録までを一貫して行うべきです。

しかし、生成 AI ワークフローをストリーミングシステムに実行しようとすると、スケール、レイテンシ、コストという、エンジニアリング上の根本的な障壁に直面することになります。すべての未加工イベントを、外部データベースとメールツールを備えた高負荷なモデルやマルチステップエージェントに直接送信すると、コストが跳ね上がり、レイテンシも増大します。また、API のレート制限もすぐに使い果たしてしまいます。

ここで紹介するパターンは、Google Dataflow（Google Cloud が提供する Apache Beam のフルマネージドサーバーレス実行サービス）と Agent Development Kit（ADK）を組み合わせてハイブリッドストリーミングパイプラインを構築することで、スケーラビリティと複雑さという課題に対処します。軽量で CPU バウンドな ML モデルをアップストリームで使用してイベントをフィルタリングし、評価することで、パイプラインの費用対効果を高く保ち、複雑なケースのみをダウンストリームエージェントにルーティングします。ケースを受け取ったエージェントは、実行するアクションを動的に決定し、パイプラインの静的 DAG に膨大な数の条件付きステップをハードコードすることなく、ストリームに動的分岐を導入します。

大規模ストリーム向けのユニバーサルなブループリント

以下ではカスタマーサポートにおけるトリアージのシナリオを例にしていますが、この「事前フィルタ + エージェントによるアクション」というパターンは、幅広い分野に適用できる普遍的モデルです。このパターンは、イベントの大多数（90% 超）が定型的であり、複雑なコンテキスト推論を必要とするイベントはごくわずかである、以下のようなストリームに適用できます。

IT 運用と DevOps: 数百万件の定型的なシステムログを CPU 上でフィルタリングし、重大な異常が検知された場合にのみエージェントをトリガーして診断を実行し、バグチケットを開く。
金融詐欺のトリアージ: 数百万件のトランザクションを軽量なローカルルールでスクリーニングし、疑わしいパターンが検出された場合にのみエージェントを呼び出してマルチデータベース検索ツールを実行する。
産業用 IoT: エッジで定常的なテレメトリーをモニタリングし、突発的な異常をエージェントにルーティングして、機器のシャットダウンやフィールドエンジニアへの通知など一連の対応を調整する。

アーキテクチャ: ストリーミングイベントを事前にフィルタする理由

高スループットなストリームの場合、メッセージの大部分は複雑な推論や修復を必要としません。その多くは、肯定的なフィードバック、中立的な問い合わせ、単純な質問などです。

すべてのイベントを高負荷な LLM ワークフローにルーティングすると、主に 3 つのボトルネックが発生します。

API のコスト: フロンティアモデルはトークン単位で課金されます。高スループットの場合、コストはストリームのボリュームに比例して増加します。
レイテンシ: データベース参照や外部 API 呼び出しを含むマルチステップワークフローには数秒かかるため、ストリーミング DAG のボトルネックになります。
割り当て: 外部 API には厳格なレート制限があり、ストリーミングワーカーがその枠をすぐに使い切ってしまうおそれがあります。

これを防ぐため、Apache Beam と Dataflow を使用して、事前フィルタリングされたパイプラインを構築します。

パイプラインフロー

取り込み: Google Pub/Sub から未加工の顧客メッセージを読み取ります。
軽量の感情分類器（CPU）: Apache Beam の RunInference 変換を使用して、軽量の CPU ベースの Hugging Face モデル（distilbert-base-uncased-finetuned-sst-2-english）ですべてのメッセージを処理します。これは Dataflow ワーカーの CPU でローカルに実行されるため、外部 API の費用は発生しません。
事前審査ゲート: シンプルな DoFn でストリームをフィルタします。感情が POSITIVE または NEUTRAL と判定されたメッセージは、確認応答を返したうえで破棄されます。
自動修復（ADK）: メッセージが NEGATIVE に分類された場合にのみ、ADKAgentModelHandler を介して gemini-3.5-flash を基盤とする生成 AI エージェントをトリガーします。エージェントは各種ツールを活用して、BigQuery でのユーザー検索、注文情報の取得、対応策の選定、Gmail API を介した通知メールの送信までを自律的に実行します。

適応的実行: Beam DAG の動的な構成

従来のストリーミングアーキテクチャでは、パイプラインの有向非巡回グラフ（DAG）は固定されています。Dataflow にデプロイされると変換のシーケンスが固定されるため、新しいタイプのアラートを処理したり、特定のイベントのルーティング方法を変更したりする必要が生じた場合はパイプライン全体を変更、テスト、再デプロイする必要があります。

感情の事前フィルタのダウンストリームに生成 AI エージェントを配置することで、静的な DAG 内に動的で適応性のあるノードを導入できます。

全レコードの 95% を占める肯定的または中立的なデータは、パイプライン上の高速な静的パスに沿って処理されます。しかし、フィルタがネガティブなレコードを検知すると、エージェントはペイロードを評価し、実行時に API ツールの適切な実行順序（データベースへのクエリ、在庫確認、メール通知など）を動的に選択します。これにより、パイプラインで複雑な決定木を動的に実行できるようになり、静的な Apache Beam コードに膨大な数の条件分岐をハードコードして構築、保守し続けるといった煩雑な作業が不要になります。

パイプラインの実装

Google Agent Development Kit（ADK）と RunInference フレームワークを活用した Apache Beam での実装例を以下に示します。

1. 軽量な感情モデルの定義

HuggingFacePipelineModelHandler を使用して、アップストリームの CPU モデルを定義します。このモデルは、ワーカーインスタンス上で感情を POSITIVE、NEUTRAL、NEGATIVE に分類します。

code_block: <ListValue: [StructValue([('code', 'model_handler = HuggingFacePipelineModelHandler(\r\n task="sentiment-analysis",\r\n model="distilbert-base-uncased-finetuned-sst-2-english"\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ece4e7d0>)])]>

2. 高負荷な ADK エージェントの構築

ADK エージェントは修復アシスタントとして機能します。このエージェントに、次の 3 つのツールを実装します。

lookup_user: BigQuery に顧客のメールアドレスをクエリします。
lookup_orders: BigQuery に顧客の注文と現在の商品在庫をクエリします。
send_email: Gmail API を使用して対応メールを顧客に送信します。

code_block: <ListValue: [StructValue([('code', 'def make_adk_tools(project: str, dataset: str = "sentiment_demo"):\r\n def lookup_user(user_id: int) -> dict:\r\n """Look up user information (email address) from BigQuery by user ID."""\r\n from google.cloud import bigquery\r\n\r\n client = bigquery.Client(project=project)\r\n query = (\r\n f"SELECT user_id, user_email "\r\n f"FROM `{project}.{dataset}.users` "\r\n f"WHERE user_id = @user_id"\r\n )\r\n job_config = bigquery.QueryJobConfig(\r\n query_parameters=[bigquery.ScalarQueryParameter("user_id", "INT64", user_id)]\r\n )\r\n try:\r\n results = list(client.query(query, job_config=job_config).result())\r\n if results:\r\n row = results[0]\r\n return {"user_id": row.user_id, "user_email": row.user_email}\r\n return {"error": f"No user found with user_id={user_id}"}\r\n except Exception as exc:\r\n return {"error": str(exc)}\r\n\r\n def lookup_orders(user_id: int) -> dict:\r\n """Look up a user\'s orders and current product inventory from BigQuery."""\r\n from google.cloud import bigquery\r\n\r\n client = bigquery.Client(project=project)\r\n query = (\r\n f"SELECT p.order_id, p.product_id, pr.remaining_inventory, pr.price "\r\n f"FROM `{project}.{dataset}.purchases` p "\r\n f"JOIN `{project}.{dataset}.products` pr ON p.product_id = pr.product_id "\r\n f"WHERE p.user_id = @user_id"\r\n )\r\n job_config = bigquery.QueryJobConfig(\r\n query_parameters=[bigquery.ScalarQueryParameter("user_id", "INT64", user_id)]\r\n )\r\n try:\r\n results = list(client.query(query, job_config=job_config).result())\r\n orders = [\r\n {\r\n "order_id": row.order_id,\r\n "product_id": row.product_id,\r\n "remaining_inventory": row.remaining_inventory,\r\n "price": float(row.price),\r\n }\r\n for row in results\r\n ]\r\n return {"orders": orders}\r\n except Exception as exc:\r\n return {"error": str(exc)}\r\n\r\n def send_email(to_address: str, subject: str, body: str) -> str:\r\n """Send a plain-text email to the customer via the Gmail API."""\r\n import google.auth\r\n import googleapiclient.discovery\r\n import email.mime.text\r\n import base64\r\n\r\n try:\r\n creds, _ = google.auth.default(\r\n scopes=["https://www.googleapis.com/auth/gmail.send"]\r\n )\r\n service = googleapiclient.discovery.build("gmail", "v1", credentials=creds)\r\n\r\n mime_msg = email.mime.text.MIMEText(body)\r\n mime_msg["to"] = to_address\r\n mime_msg["subject"] = subject\r\n raw = base64.urlsafe_b64encode(mime_msg.as_bytes()).decode("utf-8")\r\n service.users().messages().send(userId="me", body={"raw": raw}).execute()\r\n return "Email sent successfully"\r\n except Exception as exc:\r\n return f"Failed to send email: {exc}"\r\n\r\n return [lookup_user, lookup_orders, send_email]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ece38210>)])]>

LlmAgent を構成し、ADKAgentModelHandler に組み込みます。

code_block: <ListValue: [StructValue([('code', 'adk_agent = LlmAgent(\r\n name="remediation_agent",\r\n model="gemini-3.5-flash",\r\n instruction=(\r\n "You are a customer service remediation assistant with access to "\r\n "BigQuery lookup tools and an email sending tool. "\r\n "When given a prompt describing a customer situation, follow the "\r\n "numbered steps exactly and use your tools to complete the task."\r\n ),\r\n tools=adk_tools,\r\n)\r\n\r\n# RunInference handler for the ADK agent\r\nadk_handler = ADKAgentModelHandler(agent=adk_agent)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ecfdf310>)])]>

3. Dataflow DAG の組み立て

パイプライン全体を明確に定義します。アップストリームの感情推論の結果はフィルタリングステップ（FilterNegativeADK）に直接渡され、フィルタリングステップはダウンストリームの ADKInference を条件付きで実行します。

code_block: <ListValue: [StructValue([('code', 'with beam.Pipeline(options=pipeline_options) as p:\r\n # 1. Read from Pub/Sub and classify sentiment on CPU\r\n sentiment_results = (\r\n p\r\n | "ReadFromPubSub" >> beam.io.ReadFromPubSub(topic=known_args.input_topic)\r\n | "DecodeMessages" >> beam.Map(lambda x: x.decode(\'utf-8\'))\r\n | "SentimentInference" >> RunInference(model_handler)\r\n )\r\n\r\n # 2. Filter out non-negative sentiment and invoke the ADK Agent\r\n _ = (\r\n sentiment_results\r\n | "FilterNegativeADK" >> beam.ParDo(FilterNegativeAndPromptADK())\r\n | "ADKInference" >> RunInference(adk_handler)\r\n | "LogADKResults" >> beam.ParDo(LogADKResponse())\r\n )'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ecfdd050>)])]>

コストとパフォーマンスのメリット

このフィルタリングステップを導入すると、エンジニアリング面と運用面の両方で大きなメリットがあります。

1. 大幅なコスト削減

すべての受信イベントに対して料金を支払うのではなく、顧客のネガティブな感情が含まれる一部のメッセージ（通常は 5% 未満）に対してのみ Gemini の入出力トークンの料金を支払うだけで済みます。残りの 95% は CPU インスタンスでローカルに分類されるため、API の追加費用はかかりません。

2. 高いストリーミングスループット

Dataflow は、CPU による分類ワークロードを多数のインスタンスに分散して処理します。CPU 推論はミリ秒単位で完了するため、パイプラインを水平方向にスケールして高スループットのイベントストリームを処理できます。ツール実行のためにリクエストごとに数秒を要する高負荷な LLM エージェントは、呼び出し回数を最小限に抑えることで、バックログの発生を防いでいます。

3. ネイティブな Apache Beam 統合

DAG にエージェントを追加するのに、複雑なオーケストレーションロジックや手動のスレッドプールは一切必要ありません。ADKAgentModelHandler を Beam ネイティブの RunInference 変換と併用することで、並列ワーカースレッド、バッチ処理、統合の処理が自動化され、コードベースをクリーンでメンテナンスしやすい状態に保てます。

重要ポイント

ストリーミングデータは高速かつ大量であるのに対し、高負荷な生成 AI 推論は低速でコストがかかります。

Google Dataflow と ADK を使用して事前フィルタリングを組み込んだパイプラインを構築することで、ローカルの CPU ベースのモデルが持つ「低コストとスピード」、そして Gemini を活用したエージェントの「高度な自動化機能」という両方の長所を最大限に引き出すことができます。

完全なコードベースを参照してご自身でデプロイしてみる場合は、next-2026-demo GitHub リポジトリをご確認ください。

^{Apache Beam は Apache Software Foundation の商標です。}

- グループプロダクトマネージャー、Reza Rokni

- Google Cloud、ソフトウェアエンジニア、Danny McCormick

AI 時代の FinOps：エージェント向けの新しい柔軟な請求と費用管理

Thu, 27 Aug 2026 02:00:00 +0000

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

AI がより複雑な業務を担うようになる中、ビジネスリーダーは、利益率と予算を守りながら、エージェントを活用して迅速なイノベーションを可能にするという新しい課題に直面しています。AI から投資対効果を得るには、技術の進化にあわせて財務運用 (FinOps) とともに費用管理も進化させる必要があります。これにより、明確なコストの可視化、プロアクティブなコスト統制、ニーズに合った柔軟な支払いモデルの実現が可能になります。

本日、Gemini Enterprise 全体にわたるエージェントワークロード、ならびに Google Antigravity in Gemini Enterprise や Android Studio といったデベロッパーツール向けに、請求を柔軟にする支払いオプションと新しい費用管理ツールを発表します。

柔軟な支払いオプション：既存の予測可能なユーザー単位のシートサブスクリプションと、Gemini Enterprise app の新しい従量課金オプションを組み合わせることができます。これにより、タスクの途中で制限に達することなく、エージェントワークロードを実行できます。
デベロッパーへのアクセス権と AI の一括管理：Google Antigravity および Android Studio での AI 利用が Gemini Enterprise のサブスクリプションに含まれるようになりました（一部のお客様に提供中、他のお客様には順次提供予定）。これにより、管理負担を増やすことなくデベロッパーにより多くの機能を提供できます。Google Antigravity、プラットフォーム、アプリにわたる利用状況は、個別ライセンスや請求でサイロ化されず、単一のビューに集約されます。
用量の増加に応じた割引：AI ワークロードが安定している、または増加している場合、 Flexible Savings Plans を利用することで、許容できる月額支出にコミットし、トークン費用を 10〜20% 削減できます。最低額や上限額の条件はなく、新しい請求サイロの管理も発生しません。
統合された支出ガードレール：AI 支出やプロジェクトに月額の上限を設定し、エージェントの実行費用を見積もり、請求書に反映される前に予期しない予算の急増を検知できるようになりました。

Gemini Enterprise の支出をコントロールしながらチームに柔軟性を提供

企業ごとに組織運営の方法は異なります。また同じ企業内であっても、AI の利用方法はチームによって様々です。ビジネスユーザーは日常的な生産性ツールを継続的に使用する傾向にある一方で、技術チームは AI エージェントワークロードを短期間に集中して実行することがあります。

実際の業務の進め方に費用を適合させるため、以下の支払いおよびライセンスの選択肢を Gemini Enterprise の各機能と組み合わせることができます。

オプション	仕組み	費用最適化に役立つ理由
Gemini Enterprise app のユーザー単位シートサブスクリプション	ユーザーごとに一定の月額料金を支払います。これにはプロジェクト全体で共有される毎日の割り当てプールが含まれます。	予測可能な予算：日々安定した生産性ニーズを持つチーム向け。財務経理部に明確な月額費用を提供します。
【新機能】従量課金制 Gemini Enterprise app *一部のお客様に提供中、他のお客様には順次提供予定	前払い契約や基本サブスクリプション料金はなく、標準モデル API レートに基づき、チームが消費したコンピューティングとトークンの分のみを厳密に支払います。	使用した分のみ支払い：支出は実際の利用状況に応じて自動的に増減するため、プロジェクトの需要が低下したときに利用されていない社員の料金を支払う必要がありません。
【Google Antigravity in Gemini Enterprise の向け新機能】統合されたプール割り当て	日々の利用上限はプロジェクト全体でプールされ、ビジネスアプリ、デベロッパーツール、カスタムエージェントはこの共有枠から消費します。プールされた割り当てが常に優先して消費されますが、管理者は超過利用を許可するかどうかを制御でき、許可した場合の超過分は従量課金レートで請求されます。	リソース利用の効率化：ビジネスユーザーの未使用の制限枠を、デベロッパーやカスタム API エージェントの負荷の高いワークロードに自動的に、割り当てられるため、日々の制限枠が無駄になりません。
【今後提供開始】遅延実行価格 *一部のワークロード向けに提供予定	対象となるエージェントワークロードを遅延実行として指定すると、Gemini Enterprise Agent Platform のインテリジェントスケジューラがオフピーク時間帯のキャパシティで実行します。	急がない業務の大幅な割引：AI ワークロードを分離されたオフピーク容量で実行できるため、推論コストを半額程度に抑えつつ、標準の割り当てを使わずにすむため、同じ予算内で大幅に多くのエージェントワークロードを実行できます。

単一の Gemini Enterprise サブスクリプションで高度なエージェントツールをデベロッパーに提供

Google Cloud は、Google Antigravity in Gemini Enterprise を提供開始しています。Google Antigravity in Gemini Enterpriseは、高度なエージェントコーディングおよびエージェント構築機能を技術チームにもたらすエージェントファーストのデベロッパープラットフォームで、対象となるお客様の Gemini Enterprise サブスクリプションに含まれます。さらに、Android デベロッパーは、プロフェッショナルな Android 開発向けのエージェント IDE である Android Studio 内で、 Gemini Enterprise サブスクリプションに含まれる Google Antigravity の割り当てをネイティブに活用できます。

エージェントコーディングの費用効率を高めるため、各 Gemini Enterprise サブスクリプションに含まれるデベロッパーツールの割り当てをプール化し、Google Cloud プロジェクト全体で利用できるようにしています。これにより、チームは購入済みのキャパシティを無駄なく活用できます。一元化されたガバナンスと管理を維持しながら、デベロッパーに高度なエージェントツールを提供できます。Google Antigravity in Gemini Enterprise の新機能や、お客様による本番環境での活用事例の詳細については、こちら（英語）をご覧ください。

Gemini Enterprise Flexible Savings Plans（FSPs）でよりスマートに予算を管理

企業の AI ワークロードが安定または増加している場合、Gemini Enterprise Flexible Savings Plans（FSPs）は、Gemini Enterprise 全体の利用に対してシンプルな利用額ベースのモデルを提供します。FSPs は、予算の柔軟性を維持しながらトークン費用を削減するように設計されています。

プログラムによる割引：Gemini Enterprise 全体の月額利用額に対し、1 年間の約定で 10% 割引、3 年間の約定で 20% 割引を受けられます。
ペースに合わせて調整：最低利用額や上限額の条件がないため、現在のトラフィックに合った月額コミットメントを決め、利用量の増加に合わせて調整できます。
Enterprise Agreement（EA）に対応： FSPs の利用額は、既存の Google Cloud EA の枠からシームレスに消化されるため、全体的なクラウドの約定枠を細分化することなく、各事業部門専用の予算管理が可能です。

Gemini Enterprise Flexible Savings Plans は、セルフサービスのお客様およびエンタープライズ契約をご利用のお客様に提供を開始しています。

財政規律を維持しながらチームに構築の自由を提供

ビジネスリーダーとしての目標は、AI の潜在的な価値を制限することではなく、管理されていない AI 費用によって発生する財務上および運用上のリスクを取り除くことです。エンジニアリング、マーケティング、運用の各チームにエージェントを活用したイノベーションの自由を与えつつ、それらのエージェントの挙動を信頼できる可視性と、予算を保護するセーフティネットを確保する必要があります。

このギャップを埋めるため、Google Cloud Billing Console 内に 3 つの明確な目標に基づいた堅牢なネイティブガバナンスツールを構築しました。

プロジェクト開始前に費用試算：Google Cloud Pricing Calculator を使用すると、ユーザー単位のライセンス、デベロッパーツール、バックグラウンドエージェントのランタイム全体にわたる Gemini Enterprise の見込み費用を試算できます。プロジェクト業務の開始前に、必要な予算を確認できます。
支出を細かく管理せずにしきい値を設定：プロジェクトチーム全体の日々の利用変動を管理するため、以下のツールにモニタリングを依頼することができます。
- 早期の異常検知：プロジェクトの AI 支出が通常より高くなる傾向を示した場合、システムは根本原因分析とともに異常値をフラグ付けし、増加の原因となっている上位 3 つの SKU を特定します。これにより、何が変化したのかを正確に把握できます。

Billing Console に表示された初期異常アラートと、原因の主なSKUを強調表示した根本原因分析（RCA: the Root Cause Analysis）の内訳

プロジェクトレベルの支出上限：プロジェクトで明確な予算上の制限が必要な場合、Google Cloud Billing Console で直接、確実な月額支出上限を設定できます。プロジェクトが上限に達すると、エージェントの API 呼び出しが一時停止し、本番インフラストラクチャに影響を与えることなく予算を保護します。また、予算の 50%、80%、100% に達した際に送信される自動メールアラートにより、支出上限に対する進捗状況を把握できます。
超過利用コントロール：支出上限に達し処理が停止した場合でも、コンソールで 1 クリックで業務を再開できます。継続的な運用を優先する場合は、超過利用を有効にして超過利用分を従量課金レートへとスムーズに移行させることができます。この超過分は FSPs から直接引き落とされるため、超過単価には大幅な割引価格を維持できます。

プロジェクトの従量課金による超過利用の有効化

3. ビジネス価値の可視化：統合された請求レポートを FinOps エージェントと組み合わせて使用することで、予算の支出先に関するインサイトを自然言語で生成し、経営陣に ROI を簡単に提示できます。

Google Cloud Console における AI 支出レポート

AI 費用の最適化をさらに深めるには

モデルとインフラストラクチャの費用、レイテンシ、パフォーマンスを最適化するフルスタックの FinOps 戦略を構築するには、詳細なアーキテクチャ仕様とフレームワークをご覧ください。

動的な容量管理によりインフラストラクチャの制約を克服する方法： Google Kubernetes Engine および Google Compute Engine の機能を活用してコンピューティング投資を最適化する方法をご紹介します。これらの機能は、リソースを自動的にスケジュールおよび再割り当てし、中断、過剰なプロビジョニング、特定のハードウェア構成への過度な依存を回避します。
エンタープライズのお客様向けに Google Antigravity を拡張：技術チームがエージェントファーストのワークフローによってソフトウェアのデリバリーをどのように加速しているか、デベロッパーツールに関する詳細解説ををご確認ください。
スポーツカーから学ぶ AI 支出最適化：トークン数が多ければ常に優れた AI になるとは限りません。Gemini Enterprise Agent Platform プロダクトマネジメントディレクターである Mike Clark との対談で、馬力と効率のバランスをとり、AI への投資からより高いリターンを得る方法をご覧ください。
利用スパイク時の保護：負荷の大きいワークロードは、それ以外の時間にアイドル状態となる高価な専用インフラストラクチャの料金を支払うことなく、ピーク時に急増させることができます。AI の利用が拡大しても、Gemini モデルは人工的なレート制限に達することなくオンデマンドで自動的にスケーリングし、1 分あたり最大 5,000 万トークンを処理できます。プロビジョンドスループットの詳細をご覧ください。

Malachyte がマネージドリアルタイム AI で小売業のコールドスタート問題を解決した方法

Thu, 27 Aug 2026 01:00:00 +0000

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

未知の潜在顧客に商品をすすめるには、どのような方法が最適なのでしょうか。

私たちは、Spotify や Priceline などの大手企業とともに、長年この問題の解決に取り組んできました。そして、Sidd Motwani を中心に、AI を活用した e コマースのレコメンデーションプラットフォーム Malachyte を創設したのも、まさにこの問題を解決するためでした。最近では、消費者はパーソナライズされて関連性の高いコンテンツを期待するようになり、オンラインサービスは消費者の関心を集めるために競わねばならず、その結果がビジネスの成否を左右するまでになっています。

Malachyte は、高度な AI モデル、特に大規模言語モデルを、パーソナライズやレコメンデーションといった従来の課題に新しい方法で適用する独自のインサイトを見い出し、それが革新を生むきっかけとなりました。

さらに、潜在顧客の獲得を目指すうえで、Malachyte が常に思い描いていたビジョンを実現し、パーソナライズアルゴリズムを構築し続けるには、セキュアかつスケーラブルで信頼性が高く、何よりも最先端の AI インフラストラクチャが必要でした。そこで、Bigtable や Managed Service for Apache Kafka などの Google Cloud ツールを活用することで、Malachyte は小売業者の売上を 2 倍、場合によっては 3 倍に増やすことに成功したのです。

ここでは、Malachyte がそのプラットフォームをいかにして構築したか、そして、企業家の皆様がこのようなサービスを利用して AI 基盤モデルのデプロイを新しい方法で開始するにはどうすればよいか、ご紹介します。

Malachyte はお客様の売り上げをどのように伸ばしたのか

Malachyte には、アテンションメカニズムを備えたニューラルネットワーク（大規模言語モデルを支えるのと同じコンセプト）を使用して、小売検索と商品ページをパーソナライズできることを発見したときがひらめきの瞬間でした。このアプローチは、大規模言語モデル（LLM）でシーケンス内のアイテムの相対的な順序から意味を引き出すために使用されています。この場合、シーケンスは文中の単語と音節の順序です。Malachyte は、これを小売業のウェブサイトやアプリに応用し、顧客がサイトを操作する際の一連の行動の把握に努めました。

LLM が文の次の単語を予測するように、e コマースサイトでユーザーが次に何を求めているかを予測できたらどうでしょうか。

GPT 以前の言語モデルでも、単語や単語の断片（現在ではトークンとして知られているもの）の特定の並びを調べることは可能でした。しかし、それらの初期のモデルでは、単語が同等の順序で並んでいても、連続していなかったり、並べ替えられていたりした場合にどうなるかを調べることはできませんでした。この状況が打破されたのは、LLM がアイテムのシーケンス内の複雑で広い範囲の依存関係を理解できるようになったときでした。これには、Google の Transformer に関する取り組みも部分的に貢献しています。

このより洗練された手法は、生成 AI の一般的な普及はもちろん、Malachyte によるこのテクノロジーの応用という点でも、劇的な成果をもたらしました。

これを実践で機能させるために、Malachyte はユーザーがサイトにアクセスしたときに、そのユーザーについて知り得るすべての情報をベクトル化しています。ほとんどのユーザーは初めてサイトを訪れるため、ユーザーに関する情報はほぼありません。これが、いわゆる「コールドスタート」問題です。これに対応するには、ユーザーとのあらゆるやり取りをすべて活用して、このベクトルを改良する必要があります。たとえば、クリックやクエリなど、ベクトルに新しい要素が追加されるたびに、ユーザーが次に何を求めているかの予測が促進され、ユーザーに関する情報がさらに提供されます。

Malachyte のプラットフォームでは、その際にユーザーベクトルと予測を同時に更新します。これにより、個々のユーザーとその好みをより深く理解できるだけでなく、匿名化されたユーザーデータを使用してモデル全体を改善することができます。推論を行うたびに、平均的な買い物客と特定の買い物客の両方のコンテキストが拡大する仕組みです。

Malachyte は、アテンションベースのニューラルネットワークを使用するだけでなく、ユーザープロファイルを 100 ミリ秒ごとに更新することで、さらなるイノベーションを実現しています。

Malachyte のレコメンデーションエージェントと検索エージェントは、ユーザーが前のページでクリックした内容に基づいて、次のページの検索結果やレコメンデーションカルーセルにデータを入力します。

正確には、このコンセプト自体は新しいものではありません。小売業者は長年にわたり、コラボレーションフィルタリングレコメンデーションシステムを使用して、類似するユーザーとアイテムを特定してきました。ただし、これには膨大な量のインタラクション履歴が必要でした。これらのモデルでは通常、サードパーティ Cookie ベースのプロファイルやユーザー属性など、大量のデータを必要とします。

しかし、セッション内のインタラクションのシーケンスに焦点を当てることで、小売業者はユーザーのプロファイルのみに焦点を当てるよりも、必要なデータや費用を抑えながら、はるかに多くのパーソナライズを実現できるようになります。また、長期的な Cookie データに依存しないことで、ユーザーのプライバシーをより尊重できる利点もあります。

これは、モデルの構造と、ブラウザデータ、クリック履歴、検索など、ユーザーに関するあらゆる情報をエンコードするマルチモーダルベクトルによって実現されます。出力もマルチモーダルです。同じモデルを、サイト内検索の商品ページ、カテゴリページ、「カートに追加」カルーセルに適用できます。

この仕組みは、カタログ内の各商品がユーザーベクトルと同じ空間に埋め込まれることで機能します。それにより、ユーザーベクトルが更新されて、関連する商品に近づき、関連しない商品からは遠ざかるようになります。エンベディングを計算するニューラルネットワークは、Malachyte と連携する小売業者全体で継続的にトレーニングされ、すべてのユーザーの品質を向上させています。このシステムは事実上、データ協同組合として機能し、各小売業者のユーザーがモデルをさらにスマート化させながら、それが全ユーザーに役立つ仕組みになっています。

商品の空間でベクトルとして表されるユーザーセッション。

この仕組みをすべてのユーザーに対して推論ごとに 100 ミリ秒で実現するために、Malachyte は Google Cloud のリアルタイム AI スタックを基盤とすることに大きなメリットを見出しました。

このシステムでは、すべての行動イベントが Managed Service for Apache Kafka クラスタにストリーミングされます。各イベントは、将来のトレーニングジョブのためにキューに入れられるのではなく、Bigtable で直ちにユーザープロファイルの更新に使用されます。Kafka クラスタにより、お客様のフロントエンドが永続化されるため、ユーザーセッションのシグナルをユーザーベクトルにどのように適合させるかをあまり心配することなく、迅速に処理できます。

Bigtable によって、Malachyte のサービスは適切なユーザーベクトルを検索して更新できるようになります。Bigtable と Kafka はステップごとに 10 ミリ秒のオーダーで動作するため、レコメンデーションループ全体が、ユーザーエクスペリエンスを中断することなく完了します。

小売業者のウェブサイト、Malachyte の AI モデルとサービングフロントエンド、コンテキスト管理インフラストラクチャから成る 3 層のリアルタイム AI アーキテクチャ。

高速コアの機能に加え、商品カタログの更新事項、在庫シグナル、小売店固有のディメンションデータから成る第 2 レイヤには、商品データを最新の状態に保つ働きがあります。このデータは Cloud Pub/Sub 経由で送信されます。Cloud Pub/Sub は、グローバルアクセスが可能な REST API を提供するため、小売業者は緻密な統合作業なしで接続を利用できます。Malachyte エージェントは Google Kubernetes Engine （GKE）で実行され、モデル推論は Google Compute Engine（GCE）で行われます。

商品カタログの更新事項などの外部データの継続的な取り込みは、Pub/Sub のグローバルメッセージングシステムを通じて行われます。

Google Cloud AI アーキテクチャに移行したことで、Malachyte は本番環境の AI 推論とトレーニングが GPU とストレージだけでは決まらないことを実証しました。高速な Key-Value ストア、ストリーミングレイヤ、マネージドメッセージングシステムを含むリアルタイムの継続的学習インフラストラクチャが必要であり、これらすべてが基盤モデルアーキテクチャと統合されていることが重要です。

このアプローチは、Malachyte のような小規模なチームでも業界に多大な影響を与えることができることを示しています。必要なのは、強力なインフラストラクチャとコア AI マネージドサービスへのアクセスです。

使ってみる

Malachyte のように業界に革新をもたらしたり、他社に先駆けて業界をリードしたりすることを目指すなら、Managed Service for Apache Kafka、Cloud Pub/Sub、Bigtable をお試しください。新規のお客様は、$300 分の Google Cloud クレジットを利用できます。

- Malachyte、CEO、Sidd Motwani 氏

Malachyte、スタッフ ML エンジニア、Vicki Boykis 氏

Gemini Enterprise、業界特化型ソリューション向けに進化

Wed, 26 Aug 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 8 月 26 日に、Google Cloud blog に投稿された Gemini Enterprise for Financial Services および Gemini Enterprise for Legal の抄訳です。

Google Cloud は本日、金融サービス向け AI Gemini Enterprise for Financial Services および法務向け AI Gemini Enterprise for Legal の提供開始を発表しました。あらゆる専門家が日々の業務プロセスに合わせて Google AI を活用できるようにネイティブ設計し、安全でガバナンスの行き届いた Gemini Enterprise プラットフォーム上に構築した、業界特化型のパッケージソリューションのシリーズの第一弾です。

各業界向けソリューションは、すぐに導入可能な領域特化型の AI 機能を備えています。これには調整済みのエージェント、多様なワークフローの管理を簡素化する専用の「スキル」、データコネクタ、特定業界向けに最適化したモデルなどが含まれます。 Google Cloud のインフラストラクチャと Gemini Enterprise プラットフォーム上に構築したこれらのソリューションは、エンタープライズプラットフォームに求められるセキュリティ、ガバナンス、コンプライアンス、コストマネジメント機能を提供します。顧客データ、ビジネスルール、知的財産、カスタムエージェント、モデルの出力結果は組織固有のプライベートな状態を維持し、リスクマネジメント、監査ログ、ガバナンスをプラットフォームアーキテクチャに直接組み込んでいます。さらに、インフラストラクチャやモデルからアプリケーションレイヤーに至る Google Cloud のフルスタックアプローチにより、組織はパフォーマンスとコストを最適化し、AI 投資の価値を最大限に引き出せます。

Gemini Enterprise for Financial Services によるイノベーション、セキュリティ、コンプライアンスの融合

資産の保護にスピードが求められる現在の市場において、汎用的な AI ツールには規制対象となる金融機関が求めるセキュリティ、リアルタイムな精度、データリネージが不足しています。また、手作業によるレポート作成によって、アナリストは迅速なインサイトの抽出ではなく、定型的なデータ収集に貴重な時間を費やしています。エージェンティック AI が業界標準となりつつある中、従来のマニュアル作業に依存したままの機関は、提案、価格設定、市場変化への対応において不利な状況に直面します。

Gemini Enterprise for Financial Services は、モデルと金融サービス業界に必要なデータ、システム、専門知識、統制機能を統合するプラットフォームを提供し、これらの課題を解決します。

Google Cloud の CEO である Thomas Kurian は次のように述べています。「金融分野の専門家は、特定のモデルやエコシステムにロックインされることなく、日常的に使用する IT システムと接続し、高度なセキュリティとコンプライアンスを備えた AI プラットフォームを求めています。 Gemini Enterprise for Financial Services により、検証可能なデータの説得力を備えた金融ワークフロー向けのエージェント機能を提供し、金融機関が AI イノベーションを確実な競合優位性へと変えられるよう支援します。」

Gemini Enterprise for Financial Services の主な構成要素:

Financial Research エージェント: Google が管理するこのエージェントは、完全な説明可能性を備えたエンドツーエンドのリサーチを自動化します。50 以上の基礎的なスキルを備え、確信度スコア、明示的な手法、監査を容易にするデータスナップショット、確実な検証を可能にする正確な情報源の引用を通じて、推論プロセスの透明性を提供します。ユーザーは Gemini Enterprise app から直接エージェントにアクセスできるほか、 Agent2Agent (A2A) API を介して既存のエージェントワークフローに接続できます。エージェントは Model Context Protocol (MCP) 統合を介して多種多様なエンタープライズデータソースに直接接続し、個別のニーズに合わせたカスタマイズ可能なレポートやドキュメントを生成します。
業界特化型金融スキル: 業界特化型スキルにより、ブランドガイドラインの適用からレポートのフォーマット作成、特定データへのアクセスに至るまで、反復的な作業のショートカットを作成できます。プライベートエクイティの専門家、資産運用担当者、コンプライアンスチームのいずれが使用する場合でも、本ソリューションは信用リスク評価、ポートフォリオモニタリング、市場ニュースの要約、調査型財務リサーチなど、多様なワークフローに適応します。スキルは Financial Research エージェント内で利用できるほか、お客様が自社で構築するエージェントからもアクセス可能です。
コネクタ: 本ソリューションは、CoinDesk Data & Indices、Daloopa、Dun & Bradstreet、FactSet、Finnhub、Fiscal.ai、Guidepoint、LSEG、Moody’s、MSCI、PitchBook、S&P Global、SEC Edgar などのライセンス取得済みデータソースに対する 13 のセキュアな統合を提供し、顧客環境内で直接設定できます。
サードパーティエージェントおよびパートナーエコシステム: Gemini Enterprise for Financial Services は、法人顧客のオンボーディング加速と Know Your Customer (KYC) コンプライアンス強化を実現する D&B Business Verification エージェント、ローンパックの完全性確認、書類抽出、キャピタルマーケット向けのデータ照合を行う FlowX エージェント、プライベートマーケットや法人融資チームによる複雑な財務分析の加速を支援する Obin Financial エージェント、多段階の分析、レポート作成、リサーチワークフローに対応する S&P Global Data Retrieval エージェント、複雑なエネルギーやサステナビリティに関するデータを財務ワークフロー向けの迅速なインサイトに変換する S&P Global Energy Horizons エージェントなど、 Google Cloud のパートナーエコシステムが提供する複数のサードパーティエージェントへ簡単にアクセスできます。

Gemini Enterprise for Financial Services は、すでに CME Group や、 Financial Research エージェントの主要な設計パートナーである Deutsche Bank をはじめとするグローバル金融機関が導入しています。 BNY、Citi Wealth、Lloyds Banking Group、Macquarie Bank、Signal Iduna などの多くの大手金融機関が、生産性と効率性を向上させる先進的なエージェンティックワークフローツールとして利用を進めており、 Gemini Enterprise の導入の勢いは急速に高まっています。

法務実務向けに特化した AI である Gemini Enterprise for Legal

企業が複雑なエンドツーエンドプロセスの自動化を進める一方で、汎用ツールには厳格な機密保持、倫理的障壁（エシカルウォール）、検証済みの法的根拠、完全なデータ隔離など、法務作業が求める統制機能が欠けています。分断されたポイントソリューションや単体のモデルを組み合わせてこの問題に対処しようとすると、システム統合にかかるコストが増大し、脆弱なワークフローにつながります。

Gemini Enterprise for Legal は、これらの要件に焦点を当てて設計しており、契約レビュー、デューデリジェンス、規制モニタリング、プライバシーリクエストなどの法務ワークフロー全体を実行する特化型スキル、パートナーエージェント、コネクタを提供します。主要なドキュメントおよび案件管理システムへのセキュアなコネクタを通じて、組織のエシカルウォールを自動的に引き継ぎます。リサーチ出力はモデルの学習データだけでなく一次法源に基づき、組織のデータ、プレイブック、クライアントファイル、交渉ポジションは常にプライベートな領域内に保護します。

Gemini Enterprise for Legal の主な構成要素:

法務エージェント向け特化型スキル: Gemini Enterprise for Legal には、準備書面の作成、引用の検証、コントラクトライフサイクルマネジメント、規制動向の監視、データ主体アクセスリクエスト (DSAR) への対応など、複雑で高度な法務業務で AI エージェントを導く特化型スキルが含まれています。
コネクタ: 本ソリューションは、 Docusign、Everlaw、Harvey、iManage、Legora、NetDocuments、RelativityOne、Solve Intelligence、Thomson Reuters など、主要な法務業界プラットフォームへのセキュアな Model Context Protocol (MCP) 統合を提供します。
サードパーティエージェントおよびパートナーエコシステム: Gemini Enterprise for Legal は、本プラットフォーム上で開発を行う法務技術プロバイダーのネットワークに加え、Accenture、Deloitte、Devoteam、Eudia、Factor Law、KPMG、Tribe AI、Valtech、Zazmic、Zencore、66degrees などの大手コンサルティングパートナーやシステムインテグレータへのスムーズなアクセスを提供します。

Google Cloud の CEO である Thomas Kurian は次のように述べています。「エージェンティック AI により、法務の専門家は過去の判例のリサーチ、複雑な論理展開の構築、定型作業の自動化を実現し、クライアントに大きな価値を提供できるようになります。一方で、これらのエージェンティックワークフローのすべての側面が正確かつ事実に基づき、法的根拠に裏付けられていることが非常に重要です。 Gemini Enterprise for Legal は、現代の法務における複雑な実務に対応しながら、チームが自信を持って戦略的なアドバイスに集中できるよう、重要な根拠付けとガバナンス機能を提供します。」

提供時期

Gemini Enterprise for Financial Services および Gemini Enterprise for Legal は、本日より世界中の Google Cloud をご利用のお客様向けにプレビュー版として提供を開始します。ソリューションの詳細については、 Gemini Enterprise for Financial Services ブログおよび Gemini Enterprise for Legal ブログをご覧ください。

Google Cloud について

Google Cloud は、AI インフラストラクチャ、Gemini をはじめとする先進的なモデル、データ管理、マルチクラウドセキュリティ、開発ツール、さらにエージェントやアプリなど、強力で最適化された AI スタックを提供し、エージェント時代に向けた組織の変革を支援します。200 以上の国と地域で、信頼されるテクノロジーパートナーとして選ばれています。

Box が Gemini Embeddings 2 でマルチモーダルエンタープライズエージェントを実現

Wed, 26 Aug 2026 02:00:00 +0000

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

エンタープライズコンテンツ管理は、クラウド移行の時代以来、最も大きなアーキテクチャの転換期を迎えています。

長年にわたり、企業は財務モデル、臨床試験プロトコル、M&A デューデリジェンスルーム、エンジニアリングスキーマ、法令遵守ハンドブックなど、数兆ギガバイトに及ぶ重要なデータを Box に保存してきました。これまでは、テキストベースの検索と検索拡張生成（RAG）によって、これらのリポジトリ内の膨大なナラティブナレッジが効果的に活用され、エンタープライズ AI インテリジェンスの強力かつ非常に効果的なベースラインが確立されてきました。

従来の RAG アーキテクチャはテキスト処理に優れていますが、エージェントの時代にはそれ以上のものが求められます。次なる論理的な進化は、このフレームワークを拡張して、テキストと並存する本質的にマルチモーダルで、高度な空間情報や構造を持つ要素を捉えることです。テキストエンベディングは文章のインデックス作成に優れていますが、マルチモーダルアーキテクチャは、これまでにない画期的な機能を実現します。たとえば、財務表における厳密な行と列のセマンティクスを保持したり、臨床データのような視覚的情報を解釈したり、複数ページにわたるフローチャートのロジックを空間レイアウトを維持したままマッピングしたりすることが可能になります。

あらゆるデジタルコンテンツに対応する次世代の機能を提供するため、Google Cloud と Box は Gemini Multimodal Embeddings 2 を活用して高度なマルチモーダル機能を Box の Agentic Platform に統合し、業界をリードする Box のインテリジェントコンテンツ管理プラットフォームと Google Cloud の高度な AI エンべディングを融合させています。

エンベディングの改善によるメリット: ドキュメントコンテンツの次元の拡張

視覚的および空間的なジオメトリの保持: 複数列の表や財務マトリックスなどの複雑なドキュメント要素は、その空間的なレイアウトによって意味を成しています。これらの要素をフラットなテキスト文字列に変換すると、列ヘッダーと対応するデータポイントとの関連付けが失われてしまうおそれがあります。マルチモーダルエンベディングにより、システムは人間とまったく同じようにドキュメントを解釈できるようになり、空間的な位置関係の整合性が維持されます。
視覚的なモダリティの解明: 企業のドキュメントには、技術的な図表、プロセスフローチャート、ブランディングアセット、製品写真などの視覚的なインジケーターが多数含まれています。マルチモーダル機能により、これらの要素は検索システムにとって不可視なものではなくなり、ユーザーは画像とテキストを組み合わせた同時検索が可能になります。
ハイブリッドファイル形式の接続: 実際のビジネスワークフローが、単一のドキュメント形式で完結することはほとんどありません。エージェントは、PDF ポリシー、ログを追跡するスプレッドシート、プレゼンテーション資料を相互参照する必要がある場合があります。マルチモーダルエンベディングによって RAG を拡張することで、これら多様な形式を横断した統一的な理解が可能になります。

アーキテクチャソリューション: Gemini Multimodal Embeddings 2

Google Cloud の Gemini Multimodal Embeddings 2 は、テキスト、ラスター画像、ドキュメントページ、レンダリングされたスプレッドシートの表、ビジュアルチャートを同一のセマンティック表現空間に埋め込むことができる、統合されたマルチモーダルベクトル空間を実現します。

gemini-embeddings-2 によって実現される主なプロダクト機能:

クロスモーダル検索（テキストからビジュアル / ビジュアルからテキスト）: 自然言語クエリにより、手動のタグ付けをすることなく、膨大なスライドライブラリから特定のチャートや図解といったピンポイントなビジュアル要素を検索および抽出できるようになります。
レイアウトを考慮したドキュメントエンベディング: ファイルを任意のテキストブロックに分割するのではなく、ドキュメントページのレンダリングを直接埋め込むことで、視覚的な階層構造、コールアウトボックス、構造的なコンテキストをそのまま保持できます。
異種形式のブリッジ: モダリティ固有の構造情報を損なうことなく、.docx、.xlsx、.pdf、.pptx、.png、.csv 間のコンテンツをシームレスにつなぐネイティブサポート。

マルチモーダルエンタープライズエージェントの 3 つのコアパターン

Box 内でマルチモーダルエンベディングを活用することで、従来の RAG を拡張して複雑なビジュアルワークフローをサポートするための、主要な 3 つの独自デザインパターンを見出しました。

パターン 1: 複雑な財務レポートと分析レポート

課題

企業の財務、調査、監査の各チームは、高度に構造化されたドキュメントを分析します。こうしたドキュメントでは、埋め込みの表、成長チャート、脚注アノテーションの中に重要なデータが存在しています。テキストのみのインデックス登録では、これらの数字がコンテキストから分離されるため、自動分析が困難になります。

マルチモーダルの利点

構造の整合性: エンベディングモデルは表やグラフの物理的な構造を捉えるため、財務エージェントは、どの列ヘッダーが特定の指標の行に対応しているのかを正確に理解できるようになります。
視覚的な傾向分析: エージェントは、記述された要約と、付随する棒グラフや折れ線グラフの視覚的な傾向を相互参照し、文書内の主張とソースデータとの不一致を特定して指摘できます。
コンテキストに応じたソースの特定: ユーザーは複雑なポートフォリオに対してクエリを実行し、特定の指標を裏付ける正確なページ、表、グラフを即座に取得できます。

パターン 2: マルチモーダルによる臨床意思決定支援と診断補助

課題

医療および臨床環境では、重要な患者データが、外部の外観写真（視覚的証拠）、顕微鏡の病理スライド（検査レポート）、構造化されたリスクマトリクス（トリアージグリッド）など、さまざまな非構造化の視覚およびテキスト形式に断片化されています。従来のテキストベースのシステムや個別の分析ツールでは、こうしたクロスモーダルな関係性を同時に統合して理解することはできません。その結果、重要な診断の遅れを招いたり、生命に直結する処置上の合併症を見逃したりするリスクが生じます。

マルチモーダルの利点

クロスモーダルな臨床情報の統合: 臨床写真、組織病理画像、トリアージグリッドを同一のスペースにインデックス化することで、身体症状と細胞レベルの検査エビデンスを同時に評価します。
微細な異常の特定: 顕微鏡下で観察される微細な視覚パターン（寄生虫の嚢胞壁など）を医学的知識と結び付け、希少な疾患を迅速に特定します。
リスクを考慮した意思決定支援: 得られた所見をトリアージフレームワークと照合し、生命を脅かすアナフィラキシーショックなど、患者の差し迫ったリスクについて即座に警告を発します。

パターン 3: ドキュメント間のマルチモーダル統合とデータ調整

課題

企業内の情報は、接続されていないファイルや形式（PDF の議事録、Excel のグラフ、PNG のチラシ、メールスレッドなど）に断片化されています。従来のツールはこれらのファイルを個別に分析するため、独立したドキュメントを横断して詳細を確認したり、データの矛盾を解消したりする際に、情報を結びつけて全体像を把握することができません。

マルチモーダルの利点

ファイル間の統合: 完全に異なる形式（PDF、スプレッドシート、画像、メール）の情報を同時に結び付けて、複雑なビジネスクエリに回答します。
不整合の解決: アセット間の不整合を特定して解消します。たとえば、最新の財務スプレッドシートと照合することで、画像内に記載された古い価格情報を見つけ出すといったことが可能です。
画像とテキストの照合監査: 画像やスキャンされたファイルをテキストベースの記録と照らし合わせ（署名済みの PDF 契約書を法的レビューのメールで検証するなど）、条項の欠落や変更箇所を特定します。

エージェント型エンタープライズコンテンツ管理の未来

gemini-embeddings-2 と Box のエージェントプラットフォームのインテグレーションは、次世代のコンテンツインテリジェンスを向上させる重要な新機能です。マルチモーダルエンベディングにより、Box は従来の検索の枠を超え、能動的かつインテリジェントなコラボレーションへと進化します。Box のインテリジェントコンテンツ管理プラットフォームは、エンタープライズ AI インフラストラクチャの根本的な転換を体現するものです。単なる受動的なドキュメントストレージから、ガバナンスの効いたセマンティックインデックスによる推論レイヤに移行することで、AI エージェントは、既存のコンプライアンスとセキュリティ管理を維持したまま、コンテンツの照会や相互参照、アクションの実行を自在に行えるようになります。

マルチモーダルエンベディングと、検索、メタデータ抽出、調査、分析、作成にわたるネイティブ AI エージェントスイートを搭載した Box により、組織は、古い価格データの特定、契約条項の期限切れ、ドキュメント間の矛盾といったインサイトを、ビジネスリスクが顕在化する前にプロアクティブに抽出できるようになります。金融サービス、ライフサイエンス、法務業務といった複雑性の高い業界では、マルチモーダル理解が競争上の必須要件となっています。Box なら、テキスト、表、グラフ、画像を横断して推論することが可能です。

より広範なエンタープライズ AI エコシステムとの相互運用を前提に設計された Box は、ガバナンスの効いた一元的なコンテンツ基盤として機能します。これにより、AI を活用したあらゆるワークフローが、承認済みで監査可能な企業データに基づいていることが保証されます。

考えてみれば、企業のデータ環境はもともとマルチモーダルなものでした。そして今、それを最大限に活用するためのテクノロジーが現実のものとなりました。gemini-embeddings-2 とのインテグレーションにより、Box は、ユーザーが非構造化エンタープライズコンテンツからこれまでにない価値を引き出せるよう支援します。マルチモーダルファーストのアーキテクチャ、厳格な精度ベンチマーク、そして監査対応のグラウンディングを積極的に取り入れるプロダクトリーダーが、企業の生産性とイノベーションにおける次なる波を牽引することになるでしょう。

このプロジェクトに携わってくださった Ken Ikeda、Afshaan Mazagonwalla、Samip Thakkar の各氏に感謝いたします。

- Google、エージェントプロダクトコンサルティングリード、Sandhya Patil

- Box、スタッフ AI プロダクトマネージャー、Darryl Sladden 氏

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

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

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

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

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

TelevisaUnivision が Google Cloud を選んだ理由

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

【Google Cloud Next Tokyo 26】DAY 2 基調講演まとめ：インフラからセキュリティまで、フルスタックで支える AI エージェント

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

Google Cloud Next Tokyo 26 の Day 2 基調講演では、AI エージェントの実用化をフルスタックで支える最新テクノロジーが勢ぞろいしました。インフラの進化から、エージェント開発、データ基盤、そしてセキュリティまで。GovTech東京や NTTドコモなど先進企業の実践も交えて、最前線で今何が起きているのか、注目のトピックを分かりやすくお届けします！

見逃した方はぜひこちらからご覧ください。

AI を支えるインフラ

幕開けは Google Cloud の渕野の挨拶から。AI コンピューティングへの需要が急速に高まるなか、ハードウェアからモデル、プラットフォームまで全レイヤーを自ら手がけてきたことが強みだと語りました。その象徴が、クリーンエネルギーや専用インフラを 1 つのエンジンにまとめた AI Hypercomputer です。学習と推論それぞれの要求に合わせた第 8 世代 TPU を用意し、新しいネットワーク Virgo Network は 134,000 個のチップを束ねて 170 万エクサ FLOPS を生み出します。運用の面では、Google Kubernetes Engine（GKE）が 256,000 ノードを 1 つのクラスタにまとめ、大規模な学習も支えます。すでに Woven by Toyota が時空間理解の視覚言語モデルの学習を高速化するなど、多くの企業がこの基盤で成果を上げています。

エージェントを本番で動かすプラットフォーム

続いて登壇したのは Google Cloud の Brad Calder。エージェントを本番で動かすための Gemini Enterprise Agent Platform を紹介しました。作る出発点はオープンソースの Agent Development Kit (ADK) で、Google Cloud の全サービスが標準で MCP に対応し、エージェント同士は Agent2Agent プロトコル (A2A) で協調します。動かす Agent Runtime、守る Agent Identity や Agent Gateway、Model Armor まで、本番運用に必要な部品が一式そろいました。

デモでは、Google Cloud の塚越が、Antigravity CLI で作った購買エージェントを動かして見せました。「ノート PC が 3 台ほしい」と頼むと、A2UI が申請ボタンやフォームをその場で組み立て、在庫を確かめて発注を 2 台へ調整します。不正な指示や未登録の MCP への通信は、ポリシーがブロック。開発者が向き合うのは業務ロジックだけです。

データにコンテキストを与える Agentic Data Cloud

続いて、データの活かし方を語ったのは Google Cloud の Sirish Chandrasekaran です。これまでのデータ基盤は、人が問いかけて初めて答える受け身のものでした。Sirish はこうした仕組みを System of Intelligence と呼びます。これからは、AI が自分で判断して動く System of Action が要ります。そのためには、文書や画像のまま眠っている 9 割の非構造化データにも意味を持たせ、いつでも引き出せるようにしておかなければなりません。これを実現するのが Agentic Data Cloud です。データを動かさずに扱う Borderless Lakehouse、AIエージェントや分析基盤に信頼できるコンテキスト（文脈）を提供する「Knowledge Catalog」、自然言語で分析・実行できる Intent-Driven Outcomes という 3 つの柱で支えます。国内でも、メルカリが「Socrates」を BigQuery や Looker の Semantic Layerを使って、NTT データが決済サービス「ADAPTIS」を AlloyDB 上で動かしています。

デモでは、Google Cloud の山田が、架空の食品会社のマーケターとして腕を振るいます。話題の「お濃茶ジェラート」を海外に広げるべきか。その判断までふだんは 5 週間かかるところを、5 分に縮めました。PDF に埋もれた原材料の情報を Gemini が読み解き、AWS にある購買データを動かさず BigQuery につなぎ、組み上げたデータエージェントが売上や ROI を予測して、報告スライドまで用意しました。

1,000万人の都民が使う共通の入り口を目指して

ここで紹介されたのが、GovTech東京の井原氏です。きっかけは 2024 年 1 月 1 日、能登半島での地震でした。災害のさなかに行政サービスにアクセスできない不安を自ら経験し、行政のデジタル化に飛び込んだといいます。GovTech東京は東京都と 62 の市区町村と連携し、デジタルサービスを内製する組織です。現在、600 万ダウンロードを超えた東京都公式アプリを、1,000 万人の都民が使う共通の入り口とすることを目指しています。災害時等の集中アクセスでも安定して動き、情報が矛盾なく整合すること。この要件を満たす基盤に Google Cloud を選び、大規模な書き込みと強い整合性を両立できる Spanner を採用しました。

NTTドコモが目指すフル AI マーケティング

NTTドコモの鈴木氏が語ったのは、フル AI マーケティングの構想です。1 億を超える dポイントのユーザーと 2,000 種類以上の顧客データを前に、一人ひとりに最適な体験を届けるには膨大な検討が欠かせません。着目したのは、社内の資産。5,000 人以上の社員が使うデータ活用アプリのソースコードや利用ログに眠る現場の知識を、AI が読み取れるナレッジに変えました。基盤の Google Cloud なら、月 160 億通の顧客アプローチも、お客様の声や営業社員の日報も、BigQuery でまとめて扱えます。施策設計エージェントは、100 パターンを超えるセグメントへ自動で分け、立案から生成、審査までを自律的に進めます。目指すのは、2027 年のマーケティングフル AI 化です。

AI の脅威に AI で立ち向かうセキュリティ

渕野が最後に取り上げたのは、エージェント時代に欠かせないセキュリティでした。攻撃側も AI を使いこなす今、Google は共同プロジェクト Big Sleep で未知のゼロデイ脆弱性を AI 単独で見つけ、脆弱性を自動で直す CodeMender も投入しました。CodeMender では、Gemini 3.5 Flash をセキュリティ用途に特化させたカスタムモデル Gemini 3.5 Flash Cyber も選べます。渕野が掲げたのは、可視化から優先順位付け、修復、監視までを AI で連携させる AI Threat Defense です。

デモでは、Wiz Cloud Japan の大井が、公開状態の Python 製チャットボットに潜む認証回避の脆弱性をレッドエージェントで突き止め、グリーンエージェントが対策を提案するところを見せました。

修復役の CodeMender は、Google Cloud の高橋が cm find・cm verify・cm fix で、脆弱性の発見からパッチ作成までを実演しました。防御を人間のスピードからマシンのスピードへ。渕野はそう締めくくりました。

まとめ

2 日間の基調講演で見えてきたのは、AI エージェントを業務に取り入れる技術が、事例とともに整いつつある姿です。ハードウェアからアプリケーションまで、Google Cloud が一貫してそろえます。最後に、渕野が紹介したのは、手を動かして試せるハンズオンイベント「Build with Gemini Tokyo」や、「第 6 回 AI エージェント事例アワード」。次にこの基盤を活かすのは、みなさんです。来年の Next Tokyo は 8 月 5 日と 6 日。また会場でお会いしましょう。

Google Cloud Next Tokyo 公式サイトにて基調講演を含むセッションをアーカイブ公開中です。現地 / ライブ配信での視聴が出来なかったという方も、ぜひアーカイブ配信にてセッションの復習や新たな学びのきっかけに、ぜひご活用ください。

メジャーがサポートされるようになった BigQuery Graph を使用して、信頼できるエージェントワークロードを実現

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

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

企業が単純なチャットアシスタントの使用から自律型のエージェントワークロードに移行すると、すぐに厳しい現実に直面します。それは、エージェントが元テーブルを直接使用する際に、不正確な分析情報を生成する傾向があるということです。

BigQuery Graph は、組織がフラットで静的なテーブルから脱却し、現実世界に存在する企業を正確に表現できるように、つまり、現実世界の依存関係を持つ、相互に接続された事業体として表現できるようにします。BigQuery Graph（プレビュー版）でメジャーがサポートされるようになったことで、管理された指標と関係マッピングが統合されます。これにより、エージェントはグラフで収集された複雑な依存関係全体について、メジャーの精度に基づいて推論できます。

関係が重要な理由

従来のデータ構造では、マルチホップのビジネスコンテキストが考慮されないため、次のように、AI エージェントが運用上誤った意思決定を行うことがあります。

具体的な問題: 小売業者のエージェントが、シアトルでの冬用ジャケットの売り上げが 12% 減少した理由を尋ねられた場合、フラットテーブルをクエリして、「事実」（12% の減少）を報告することはできますが、「シアトルの注文 ➔ 配送センター ➔ 地域の嵐によるサプライヤーの遅延」という関係パスを追跡できないため、「理由」を特定することはできません。
分断されたシステムのリスク: 関係のコンテキストがないため、エージェントが関連性のない 15% オフのキャンペーンを提案し、不必要に利益率を低下させます。さらに、あるチームがサプライヤーの関係を別のグラフデータベースにマッピングし、別のチームが SQL 指標を維持するというように、別々のシステムを維持すると、エージェントは実行時にこれらのスタックを結合せざるを得なくなります。このプロセスは時間がかかり、費用もかさみ、KPI の計算に一貫性がなくなります。

BigQuery Graph のメジャーは、既存のテーブルをプロパティグラフにインプレースでマッピングし、ETL を不要にすることで、この問題を解決します。この統合された設定により、次のような問い合わせの論理的な進化が可能になります。

メタデータのグラウンディングは、存在するデータを確立します。
ビジネス指標（メジャー）は、ビジネスのパフォーマンスを計算します。
関係マッピング（グラフ）は、それが起こった理由を明らかにします。

仕組み

従来、グラフ走査中の標準 SQL の結合では行が重複し、集計計算が不正確になっていました。BigQuery Graph は、これをネイティブに解決します。

データモデラーは、プロパティグラフ DDL 内で直接 MEASURE（SUM や AVG など）を定義します。エンジンは GRAPH_EXPAND 関数と AGG アグリゲータを介して標準 SQL を使用して、指標を評価する前に構造グラフのパスを解決します。これにより、エージェントは計算機（SQL）が必要なときと地図（グラフ）が必要なときを認識できるほどスマートになります。

bigquery-public-data のような一般公開プロジェクトは厳密に読み取り専用であるため、読み取り専用の一般公開テーブルをノードおよびエッジとして直接参照しながら、プレースホルダ変数（YOUR_PROJECT_ID）を使用して独自のプロジェクト内で論理プロパティグラフをマッピングする必要があります。

code_block: <ListValue: [StructValue([('code', '-- 1. Map the graph inside YOUR project \r\n\r\n\r\nCREATE OR REPLACE PROPERTY GRAPH `YOUR_PROJECT_ID.YOUR_DATASET.thelook_ecommerce_graph`\r\nNODE TABLES(\r\n `bigquery-public-data.thelook_ecommerce.users` AS User\r\n KEY(id)\r\n LABEL User PROPERTIES(id, city, country),\r\n `bigquery-public-data.thelook_ecommerce.orders` AS Order\r\n KEY(order_id)\r\n LABEL Order PROPERTIES(\r\n order_id, \r\n MEASURE(AVG(num_of_item)) AS avg_items_per_order,\r\n MEASURE(SUM(num_of_item)) AS total_items\r\n )\r\n)\r\nEDGE TABLES(\r\n `bigquery-public-data.thelook_ecommerce.orders` AS OrderedBy\r\n SOURCE KEY(order_id) REFERENCES Order(order_id)\r\n DESTINATION KEY(user_id) REFERENCES User(id)\r\n LABEL ORDERED_BY\r\n);\r\n\r\n-- 2. Query your new graph with standard SQL—using standard {Label}_{Property} column outputs\r\nSELECT\r\n User_city AS city,\r\n ROUND(AGG(Order_avg_items_per_order), 2) AS agg_avg_items,\r\n ROUND(AGG(Order_total_items), 2) AS agg_total_items\r\nFROM GRAPH_EXPAND("YOUR_PROJECT_ID.YOUR_DATASET.thelook_ecommerce_graph")\r\nGROUP BY User_city\r\nORDER BY agg_total_items DESC\r\nLIMIT 10;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48c700c610>)])]>

BigQuery Studio でグラフインテリジェンスを民主化

デベロッパーとビジネスユーザーの双方が、これらの関係ネットワークをスムーズに管理、デプロイできるように、直感的なネイティブ運用ツールを BigQuery Studio に直接組み込みました。

視覚的なグラフモデラー: BigQuery Studio 内のノーコードのドラッグ＆ドロップインターフェースで、複雑な DDL スクリプトを手動で記述することなく、プロパティグラフ、ノード、エッジを視覚的に構築、編集、マッピングできます。

会話型分析（CA）のインテグレーション: ユーザーはグラフと自然にやり取りできます。会話型分析エージェントは、テーブル結合を推測するのではなく、グラフの決定論的な関係認識マップをナビゲートし、自然言語の質問を、境界が制約された正確な GoogleSQL クエリまたは ISO GQL クエリに変換します。これにより、モデルのハルシネーションを防ぎ、セマンティックな一貫性を確保します。

統合されたセマンティクス: Looker とのネイティブなインテグレーション

断片化されたロジックスタックの維持を避けるために、ビジネス指標はデータレイヤに存在する必要があります。Looker（LookML）を、データベース内分析モデルとしての BigQuery Graphs とネイティブに統合することで、コアでロジックを一度定義するだけで済みます。

データベース管理モデル（sql_analytic_model_name）: sql_analytic_model_name を使用して、Looker にデータベース定義の BigQuery Graph を直接参照させ、標準の LookML のディメンションとメジャーをグラフプロパティに直接マッピングします。
Looker 管理モデル（derived_analytic_model）: derived_analytic_model を使用して、LookML ビュー内で BigQuery Graph スキーマを直接定義します。Looker は、SQL DDL ステートメントを動的に生成して実行し、BigQuery 内のグラフを維持します。
エンタープライズ DevOps ワークフロー: Looker IDE、Git ベースのバージョン管理、継続的インテグレーション（CI）を使用して、グラフのライフサイクル全体を管理します。主要な KPI（離脱率など）は、検証済みで、信頼できる、まったく同じものが維持されます。

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

- ソフトウェア開発マネージャー、Yun Zhang

エージェント型モバイルアプリ開発のためのデベロッパーデバイスプラットフォームのご紹介

Tue, 25 Aug 2026 01:30:00 +0000

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

ほとんどの企業は、デバイスを通じて顧客と接点を持っています。モバイルアプリを使用した商品の注文、カスタマーサービスへの問い合わせ、コンテンツの閲覧、アカウント管理など、どのような操作においても、カスタマーエクスペリエンスはアプリが顧客のデバイス上でいかにスムーズに動作するかに左右されます。

このため、ローカルで動作するコンポーネントを含むあらゆるエンタープライズリリースにおいて、多種多様なデバイスでアプリケーションを構築・テストすることは極めて重要です。しかし、デバイスを大規模に調達してホストするには費用がかかり、複雑な作業が必要になります。また、テストは不安定で、判定不能だったり、デバッグが難しかったりすることがよくあります。そのため、多くのデベロッパーは、手元の実機でリリース前のテストを行い、その結果が他のほとんどのデバイスでも通用することを願うしかありません。

この課題を解決するため、このたび Google Cloud において Developer Device Platform（DDP）の公開プレビュー版の提供開始を発表いたしました。DDP は、実機と高並行仮想エミュレータにわたる複数のハードウェアプロファイルに、オンデマンドで即座にアクセスできるフルマネージドクラウドプラットフォームです。DDP は、クラウドデベロッパー向けの Firebase Test Lab の進化版であり、エージェント型開発向けに構築された初のデバイスプラットフォームでもあります。DDP を使用すると、デベロッパーは好みのエージェントを利用して、さまざまなデバイスにわたってアプリのバイブコーディング、テストの実行、デバッグ、パフォーマンスの最適化を効率的かつ迅速に行うことができます。

アプリを構築してテストし、パフォーマンスを保証する

標準的なモバイル開発ライフサイクルでは、デベロッパーは新しい機能を反復的に開発し、さまざまな対象デバイスでパフォーマンスを保証するために QA テストを実行し、最適化およびデバッグ済みの機能をユーザー向けに本番環境へリリースします。デベロッパーデバイスプラットフォームには、このサイクルを加速させる 2 つの主な機能があります。

デバイスストリーミングによるインタラクティブなデバッグ: Device Streaming API を使用すると、デベロッパーは選択したエミュレータや実機に直接アクセスし、バイブコーディング、反復テスト、デバッグ、アプリとのインタラクションをリモートで行うことができます。デバイスストリーミングを使用すれば、実機のハードウェアでパフォーマンスをモニタリングしながら、カスタマーエクスペリエンスを直接体験し、リアルタイムでスクロールやクリックといった操作を簡単に行うことができます。

デバイスランによる並列テスト: Google の Device Run API を使用すると、デベロッパーは CI / CD パイプラインの一部としてテストを作成し、一度に数百もの異なるデバイスで並列実行できます。得られた結果をもとに、デベロッパーは特定のデバイスに固有の問題をピンポイントで特定してデバッグでき、あらゆる層のデバイスで動作するという確信を持ってコードを本番環境にリリースできます。

DDP エージェントスキルと効率的なテストでモバイルアプリ開発を加速させる

モバイル開発におけるコーディングエージェントの台頭は、特に実機と組み合わせることで新たな可能性を切り開きます。コーディングエージェントは、実機のハードウェアを操作してテストできるため、独自のスマートフォン画面サイズ（折りたたみ式スマートフォンの UI など）や特殊なハードウェア（CPU や GPU など）を活用できます。

Developer Device Platform はまもなく Android Studio と Android CLI に統合され、Device Streaming API を介して実機に直接アクセスできるようになります。DDP エージェントスキルを使用すると、選択した AI コーディングエージェントと連携して開発を加速することもできます。DDP エージェントスキルを使用すると、コーディングエージェントは次のことができます。

複数のステップから成るユーザージャーニーを単独で実行する
視覚的なアーティファクトを検出する
オンデバイスでチップのパフォーマンスをリアルタイムで分析する
ハードウェア固有のバグの修正を検証し、デバイス固有の機能に合わせて最適化する

これらのエージェント機能に加えて、DDP ではアプリのパッケージ化や、スマートシャーディングによる並列テストの実行も可能です。これにより、数百台のデバイスにわたるテスト結果をわずか数分で確認できるようになります。スマート自動再試行により、DDP はシャード内で失敗した特定のテストを再試行するため、テストスイート全体を再実行することなく、エラーをより迅速に解決できます。

デベロッパーデバイスプラットフォームで今すぐ開発を始めましょう

8 月 12 日より、Developer Device Platform がすべての Google Cloud ユーザー向けに公開プレビュー版として提供されます。公開プレビュー期間中は、1 分単位の従量課金制モデルに基づいて料金が請求されるため、実際にテストに使用した時間（分）に対してのみ料金が発生します。なお、料金はエミュレータと実機でそれぞれ異なります。

Google Cloud を利用するモバイルデベロッパーが、Developer Device Platform を活用して開発を加速し、増え続ける独自のデバイス機能やオンデバイス AI の可能性を最大限に引き出すことを楽しみにしています。

- Google プロダクトマネージャー、Derek Bekebrede

- プロダクト戦略およびオペレーション担当、Jason Nager

【Google Cloud Next Tokyo 26】 DAY 1 基調講演まとめ：日本企業の現場で動き始めた AI エージェント

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

Google Cloud Next Tokyo 26 の Day 1 基調講演では、自ら考えて業務を進める AI エージェントが、日本企業の現場を動かし始めた姿がくっきりと見えてきました。変革の全体像から、Gemini Enterprise の進化、NTTデータやＳＯＭＰＯホールディングス、Ｓｋｙ、スクウェア・エニックスの実践、そして Google Workspace とセキュリティまで。最前線で今何が起きているのか、注目のトピックを分かりやすくお届けします！

見逃した方はぜひこちらからご覧ください。

「電気で 30 年」を、AI なら何年で？

最初に立った Google Cloud の三上は、今の AI による変化を工場の電化になぞらえました。工場に電気が通っても、生産性が上がるまでには約 30 年。中央の蒸気機関を大きなモーターに替えただけでは変わらず、機械の一台ごとに小さなモーターを載せ、作業の流れごと作り直したときに一気に伸びました。AI エージェントも、業務の一つひとつに組み込んでこそ力を発揮します。しかも今回は、3 年、3 か月で景色が変わります。

世界では Google Cloud のお客様の約 75% が AI を活用し、多くが本番運用へ進んでいます。一方、日本市場の独自調査では、対象の 70% が AI エージェントをまだ使えておらず、利用者の約半数は会社非公認の「シャドー AI」に頼っています。ここに、日本企業の伸びしろがあります。

Google 自身は、検索や YouTube など月間のべ 150 億人以上のサービスに AI を組み込んでいます。その規模を支える力をお客様に届けるのが Google Cloud で、AI ハイパーコンピュータからモデル、データ基盤、Agent Platform まで、変革に必要なフルスタックを自社で持ちます。AI 専用チップの TPU は第 8 世代となり、学習用と推論用に最適化した 2 種類をそろえました。このフルスタックの上で、働く人が実際に触れるのが Gemini Enterprise です。日立製作所やファナックでもすでに導入が進んでいるといいます。

NTTデータ：自らが Client Zero となって

NTTデータの西村氏は、機微データを守りガバナンスを効かせつつ AI を速く届ける難しさを挙げ、その答えが、自社を実践の場にする Client Zero だと説明しました。同社は 2026 年 6 月に Google Cloud と包括契約を結び、Google Workspace と Gemini Enterprise を大規模に活用する基盤を整備。業務にAIエージェントを組み込んで働き方を見直し、得た知見をお客様への提案につなげるといいます。

NTTデータの西村氏は、機密データを守りガバナンスを効かせつつ AI を速く届ける難しさを挙げ、その答えが、自社を実践の場にする Client Zero だと説明しました。同社は 2026 年 6 月に Google Cloud と包括契約を結び、Google Workspace と Gemini Enterprise を大規模に導入。業務にエージェントを組み込んで働き方を見直し、得た知見をお客様への提案につなげるといいます。

Gemini Enterprise の進化と、小売の現場デモ

Google Cloud の Lilly McNealus は、Gemini Enterprise を、企業で働く人が AI を利用する入口だと位置づけました。複雑なツールやトークン課金の悩みに対し、シンプルさ、安全性、コスト効率の 3 つの価値を届けると話します。コードなしで使える 24 時間 365 日のスーパーエージェント、一つの管理画面でのガバナンス、目的に合わせてモデルを選べるコスト最適化がそろい、単一のアーキテクチャで統合されています。

続いて、Google Cloud の岡本によるデモです。店舗を担当する社員が店舗巡回アシスタントエージェントに相談すると、ミネラルウォーターの陳列スペースが足りない点や、古い POP を指摘します。音声メモと写真を渡せば、報告書 PDF が作られ Teams や Outlook へ連携されます。本部の担当者が Gemini Enterprise の Spark に POS や気象データを渡すと、翌朝には熱中症対策商品を目立つ位置に置く棚割り案が届きました。デモのあと Lilly は、目的を伝えれば動く Gemini Spark や、ノーコードで作れる Agent Designer など、Gemini Enterprise の新機能も紹介しました。

開発者に向けたアップデート

さらに Lilly からは、Gemini Enterprise から直接アクセスできる Antigravity、日本リージョン対応の Gemini Enterprise app、国内で処理を完結できる Gemini 3.5 Flash の一般提供、Anthropic や Mistral なども選べる Model Garden、コード最適化の AlphaEvolve などが紹介されました。

SOMPOホールディングス：グループ 3 万 4,000 人が使う「SOMPO AI エージェント」

ＳＯＭＰＯホールディングスの中島氏は、SOMPOグループの AI 戦略を紹介しました。同グループは今年 1 月、全社員が使う汎用型 AI を従来のチャット型 AI から Gemini Enterprise へ切り替え、3 万 4,000 人へ「SOMPO AI エージェント」として提供しています。決め手は、約款やマニュアルなどの社内ナレッジと相性の良い Gemini Notebook。

ユースケースを拡大するために、会議の録音を自動共有する「SOMPO 音声メモアプリ」を個別開発したほか、レッカー費用を一次チェックする「レカみる」など市民開発では、数か月で 1 万件超のエージェントが生まれ、週 1 回以上使う社員は 80% 超、部長以上では 98% に達しました。

Ｓｋｙ：5 か月で 2 万個のエージェントを自作

Ｓｋｙ株式会社の太田氏は、処理精度と検索、ガバナンスの強さから Gemini Enterprise を全社導入しました。社員が業務に合う独自エージェントを自作し、単一の用途に分類するのが難しい、複合的なプロンプトが約 48% を占めます。AI への総リクエストは 1 日 1 万 5,000 回から 3 万回へ倍増し、エージェント数は 5 か月で 20,000 個に。作る過程で個人の暗黙知が集まり、可視化されるのも効果的です。

スクウェア・エニックス：見て、考えて、動く AI

スクウェア・エニックスの荒牧氏は、音や画面を理解するマルチモーダル AI の活用を目指し、Gemini Enterprise Agent Platform を採用しました。今年 8 月に 14 周年を迎えた『ドラゴンクエストX オンライン』において、期間限定のクローズドベータテストとして開発・提供していた対話型AIバディ「おしゃべりスラミィ」の取り組みが紹介されました。「おしゃべりスラミィ」は、プレイヤーと音声で会話し、プレイ状況に応じて自ら話しかける機能を備えています。

さらに会場では、ゲーム QA 作業の自動化デモ動画として、「船を見たい」という指示に応じて Gemini が地図を開き、コントローラーを操作して QA を進める様子も紹介されました。

Google Workspace で変わる、ある一日

Google Workspace の Yulie Kwon Kim は、相手の必要を先に汲む「おもてなし」を AI に込めたいと話しました。朝は Google Chat の「デイリーブリーフ」が要点を届け、Sheets Canvas がデータからダッシュボードを作り、Google Meet の Gemini 3.5 Live Translate が 70 以上の言語をつなぎます。さらに、Microsoft 365 からの移行も、従来と比べて最大 5 倍速くなったと紹介されました。

Google Cloud の服部によるデモでは、Google Workspace に標準搭載される Google Pics で写真のスパークリングワインをビールジョッキに差し替え、必要な情報をサイドパネルから呼び込み、AI でスライドの体裁を整えるなど、顧客への案内スライドを数分で仕上げました。

AI の脅威に AI で備える、そして次の一歩

三上が最後に強調したのは、エージェント時代に欠かせないサイバーセキュリティでした。攻撃者も AI を使う今、脆弱性の悪用までの時間は、この数年で 1.3 年から 1.6 日へと縮まりました。こうした脅威には AI で自律的に立ち向かう必要があります。

Google 自身も月に数万件の脅威レポートを処理し、エージェントで対応時間を 90% 以上短くしました。5 月発表の Google AI Threat Defense を、準備・スキャン・修復・監視の 4 ステップで、NTTデータや NEC、日立製作所、富士通などと日本でも展開します。

電気で 30 年かかった変化を、AI ではどこまで短くできるか。この問いかけとともに、DAY 1 基調講演は幕を閉じました。

Gemini Enterprise データを Looker のセマンティックレイヤで制御してユーザーの信頼を確保

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

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

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

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

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

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

Looker エージェントを公開し、Gemini Enterprise で使用可能に

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

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

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

code_block: <ListValue: [StructValue([('code', '[ Gemini Enterprise Chat UI ] \r\n │\r\n (A2A Protocol / NLP)\r\n ▼\r\n [ Looker Governed Agent ] ──► Generates Deterministic SQL\r\n │\r\n [ Looker Semantic Layer ] ──► Business-Approved Definitions & Logic\r\n │\r\n ▼\r\n [ Enterprise Data Cloud ] ──► (BigQuery, AlloyDB, Spanner, etc.)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48edaa5090>)])]>

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

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

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

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

OAuth 認証: Gemini Enterprise 内で Looker エージェントを使用する際、エンドユーザーはセキュアな 1 回限りの OAuth 同意を提出する必要があります。これにより、Gemini セッションが特定の Looker 認証情報にバインドされます。
強力なガバナンスの適用: アーキテクチャはライブパススルークエリに依存しているため、Looker の既存の行および列単位のアクセス制御が維持されます。
厳格なセキュリティ分離: ユーザーが Looker プラットフォーム内で、たとえば地域別の給与や財務など、機密データの行を表示する権限を持たない場合、Looker エージェントは Gemini 環境でそのデータを能動的に制限します。エージェントを Agent Gallery に公開してアクセスしやすくしても、確立済みのセキュリティ制御がバイパスされることはありません。

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

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

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

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

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

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

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

Looker ベースのユーザー認証

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

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

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

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

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

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

SOAP Architecture: S3 に眠るデータを、Google Cloud で AI エージェントの基盤に変える

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

利用している主なサービス・ソリューション

Products Used: BigQuery, Looker / LookML, Knowledge Catalog, BigQuery Graph, Cross-Cloud Interconnect, Gemini Enterprise
Solutions Used: Borderless Lakehouse, Data Analytics & AI Platform

生成 AI の活用が経営課題となる一方で、その原動力であるデータの多くは、長年運用されてきた Amazon S3 に眠ったままです。「まずデータ基盤を全面刷新してから」と考えた瞬間に、移行の規模とリスクの前で計画は止まり、AI 活用は PoC の先へ進めなくなります。膨れ上がる移行コスト、断片化したナレッジ、そしてビジネスの文脈を持たないままもっともらしい回答を返す AI——従来のアプローチでは、この距離を容易に埋めることはできません。

本稿では、この課題に対する一つの答えとして、SOAP Architecture (Semantic and Ontology Agent Platform) をご紹介します。データを動かさずにつなぎ、意味と知識の層で AI をグラウンディング（接地）し、エージェントに働かせる。Google Cloud のデータ分析ポートフォリオを一枚の設計図にまとめた、リファレンスアーキテクチャです。

SOAP の考え方はシンプルです。

つなぐ - データは AWS 等に置いたまま、BigQuery から直接分析します。
意味を与える - LookML、BigQuery Graph、Knowledge Catalog、Open Knowledge Format がデータに文脈を与えます。
働かせる - Conversational Analytics と Gemini Enterprise が、その意味を理解して動きます。

大規模なデータ移行プロジェクトは、前提ではありません。

データは動かさない: Borderless Lakehouse で「いま在る場所」につなぐ

SOAP の土台は Borderless Lakehouse です。 S3 上の Apache Iceberg テーブルは、Cross-Cloud Interconnect とキャッシュ(プレビュー版)を通じて BigQuery から直接クエリでき（Cross-Cloud Interconnect を導入していない環境でも、インターネット経由での接続が可能です）、AWS Glue Data Catalog / Databricks Unity Catalog / Snowflake Horizon のメタデータは、カタログフェデレーション(プレビュー版)で Lakehouse のランタイムカタログと自動的に同期されます。 ETL パイプラインを組む前に、まず「つながる」のです。 ( Iceberg 形式のファイルでない場合は Cross-Cloud Connections で直接参照可能です)

このアプローチは、次のメリットをもたらします。

ゼロコピーのクロスクラウド分析: ファイルを複製することなく、S3 のデータをその場で分析できます。分析のために「まずコピー」する運用から解放されます。
「クラウド間の税金」の解消: 外向きデータ転送料はかかりません。(相互接続サービスの時間単位の料金はかかります) 従量の egress 課金に怯えることなく、クロスクラウド分析を定額で計画できます。 (Partner Cross-Cloud Interconnectを使用した場合)
初日からの価値: 接続したその日から、使い慣れた SQL でレガシーデータに問い合わせできます。移行の完了を待つ必要はありません。

AI の信頼性は、モデルではなく「意味の層」で決まる

SOAP の名前の中核である Semantic and Ontology は、このアーキテクチャの最も重要な主張を表しています。エージェントの回答品質を決めるのは、モデルの選定ではなく、データに与えられた意味と関係の質だということです。

ここで言うオントロジーとは、業務上の実体 (顧客・注文・商品…) と、その関係と意味を、AI が直接読める形で表現した知識の構造のことです。メタデータが「何があるか」の目録なら、オントロジーは「何を意味し、どう繋がるか」の地図です。

セマンティックレイヤを担うのは LookML です。指標やディメンションの定義を一元管理し、ダッシュボードと AI が同じ「言葉の定義」を共有します。オントロジーを担うのは BigQuery Graph、Knowledge Catalog、そして Open Knowledge Format (OKF) です。テーブル間の関係をグラフとして明示すれば、エージェントが結合方法を推測する余地がなくなり、ハルシネーションの入り口を塞げます。

この層は、次の 3 つの要素で構成されます。

セマンティックレイヤ(LookML): 「売上」「アクティブ顧客」の定義を一箇所に。 BI と AI の回答が食い違う問題を根本から解決します。
ナレッジグラフ(BigQuery Graph): 顧客、注文、商品といった実体の関係をプロパティグラフとして定義し、ISO 標準の GQL で問い合わせます。グラフはそのままエージェントのデータソースになります。
オントロジーの「共通語」(OKF + Knowledge Catalog): Knowledge Catalog が社内 Wiki のようなページも参照しながら、テーブルの意味、指標の背景、運用のナレッジを OKF (Markdown のバンドル) として生成します。生成した OKF は Git で管理し、エージェントへは Knowledge Catalog が供給します。散在していた組織のナレッジが、AI の資産に変わります。

3 つの入口、1 つの基盤: エージェントが「使う」

意味の層が整うと、その上で複数の利用スタイルが同じガバナンスのもとに成立します。 SOAP では、利用者を 3 つのペルソナで捉えます。

定型分析とドリルダウン: Looker のダッシュボードが LookML に接地した指標を提供します。Looker の Conversational Analytics は最大 5 つの Explore を束ね、質問ごとに適切な Explore へルーティングします。
Agentic なアドホック分析: BigQuery の Conversational Analytics が、BigQuery Graph をデータソースとして自然言語の質問に答えます。エージェントは A2A(Agent2Agent)プロトコルで Gemini Enterprise に公開され、ビジネスユーザーは Slack や社内ポータルから話しかけるだけです。
エンジニアリング分析: VS Code や Claude Code などのコーディングエージェントが、Data Agent Kit を通じて同じ基盤に接続します。 OKF は Git ネイティブなので、エンジニアはナレッジそのものをコードと同じレビュープロセスで育てられます。

入口は 3 つですが、接地はひとつです。どの入口から入っても、同じ定義、同じ権限、同じナレッジで答えが返ります。権限はエージェントのために新設するものではなく、BigQuery と Looker の既存のアクセス制御がそのまま適用されます。

モダナイズもエージェントと進める: 「移行計画書」から始まる

データ基盤のモダナイゼーションが止まる本当の理由は、技術ではなくアセスメントです。ストレージ内に何があるか誰も説明できず、棚卸しに数か月を要し、その間に意思決定が止まる——多くの企業で繰り返されてきた光景です。

SOAP では、この最初の壁もエージェントに任せます。既存のメタデータやクエリ履歴などを読み取り専用で収集すれば、コーディングエージェントがテーブル単位の処遇(移行 / アーカイブ / 残置 / 廃棄候補)を判定根拠つきで分類し、フェーズ単位の移行計画書をドラフトします。判断できない項目は「確認事項」として人間に返してくるため、レビューと承認に集中できます。

生成される計画書には、機械可読な移行マニフェストが付属します。つまり、資料のための計画ではなく、そのまま次のフェーズで DDL 等に変換できる、実行可能な計画です。データの棚卸しからドキュメント整備、移行計画の立案まで——これまで数か月を要した工程が、エージェントとの協働では最初のワークショップのアジェンダになります。

SOAP の経済性

このアーキテクチャの経済性は、「運ばない・書き換えない・全部やらない」の 3 点に集約されます。 S3 のデータはゼロコピーで分析し、既存の Parquet 資産はメタデータだけで Iceberg 化し、移行対象はアクセス実態にもとづいて絞り込みます。実際の棚卸しでは、テーブルの相当数が 12 か月以上参照されていない「廃棄候補」であることも珍しくありません。移行の恐怖の大半は「全部運ぶ」という誤解から来ています。

次のステップ

AI の賢さは、モデルの選定ではなく、データに与える意味で決まります。そしてその意味の層は、データを動かす前から作り始めることができます。

最初の一歩は、大きな移行の決断ではありません。読み取り専用の棚卸しと、最初の OKF バンドルから始めてください。

Borderless Lakehouse の全体像は、概要ドキュメントをご確認ください。
Open Knowledge Format は、紹介ブログと仕様をご覧ください。
グラフを AI との対話に使う方法は、グラフとチャットすることで今日から試せます。

SOAP という名前は Semantic and Ontology Agent Platform の頭字語ですが、そこにはもうひとつの意図も込められています。長年の運用で埃をかぶったデータも、意味の層で洗い上げれば AI の一級の資産になる、ということです。

レガシーも、洗えば資産です。

関連リンク・次のステップ

著者・コントリビューター紹介

執筆者:
- Kuma Arakawa: Senior Customer Engineer
  Yu Yamada:Data Analytics Specialist Tech Lead
  Akira Igarashi: Data Analytics Specialist Sales Manager
  Mei Sakurai: Head of Data Analytics Specialist Customer Engineering, Japan
お問い合わせ: Google Cloud のデータ分析・AI エージェント基盤導入に関するご相談は、担当営業またはカスタマーエンジニアまでお気軽にお問い合わせください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

シナリオの例

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

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

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

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

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

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

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

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

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

WPP が AI マーケティングのためにプラットフォームとデータエンジニアリングを運用化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エージェント型 AI のスケーリング: UiPath が AI Hypercomputer 上に高性能 GPU プラットフォームを構築した方法

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

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

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

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

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

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

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

背景: 高度な計算

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

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

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

課題: 供給を上回る需要

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

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

急激に変動するワークロード: ピーク時の需要に対応できる十分な能力を確保するために、多くの場合、追加の容量を購入せざるを得ませんでした。この容量は、需要が少ない時期にはアイドル状態になり、高価なヘッドルームを無駄にしていました。同社は、計算処理を行っていないシリコンに料金を支払う必要のない、インテリジェントなオンデマンドスケーリングを必要としていました。
供給のボトルネック: 大規模なファインチューニングにおいては、8 クラスタの H100 を搭載したゴールドスタンダードのハイエンド A3 VM インスタンスの費用対効果は圧倒的です。しかし、これらのチップは世界的に需要が供給を上回っており、ノードを追加するだけで UiPath が望むスピードでトレーニングの取り組みをスケールすることはほぼ不可能になっています。
運用上のオーバーヘッド: UiPath は、地理的な非効率性にも悩まされていました。安定した推論の需要があるということは、複数のリージョンで専用クラスタを維持することで、世界中の顧客向けに低レイテンシを確保する必要があることを意味していました。さらに、トレーニングと推論の両方のために GPU インフラストラクチャを管理することで、運用オーバーヘッドの非効率的なレイヤが追加されました。

解決策: 共有 GPU フリート

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

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

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

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

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

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

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

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

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

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

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

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

Omega Healthcare は、UiPath を使用して 1 億件を超えるトランザクションを 99.5% の精度で自動化し、処理時間を 40% 短縮、反復タスクを月あたり 15,000 時間削減しました。
Thermo Fisher Scientific は UiPath を使用して請求書や注文書などの PDF からデータを抽出しています。現在では請求書の 53% を人手を介さずに処理できるようになり、処理時間を 70% 短縮しています。

参考ポイント

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

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

容量の切り離し: ハードウェアを特定のプロダクトに結び付けるのではなく、リソースをプールして使用量の急増を平準化します。
事後対応よりもスケジュール設定: DWS などのツールを使用してコンピューティングを事前に予約することで、可用性が保証され、費用が安定します。
シリコンのサイズ適正化: トレーニングには A3 VM インスタンスを使用し、推論には G4 VM インスタンスなどの効率的なオプションを選択します。

次のステップ

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

構築: GitHub でエンジニアリングパターンを確認する。
最適化: Google Cloud G4 VM インスタンスを使い始める。
UiPath - IXP の詳細を確認する。

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

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

Gemini in Database Migration Service を使用した PostgreSQL への移行の迅速化

Fri, 21 Aug 2026 02:00:00 +0000

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

次のようなシナリオを考えてみましょう。Oracle や SQL Server などの既存の商用データベースから、オープンソースの PostgreSQL や AlloyDB for PostgreSQL などのフルマネージドサービスにコアアプリケーションを移行するとします。

最初のフェーズは順調に進みます。スキーマが変換され、テーブルにデータが入力され、データ移行パイプラインが数テラバイトのデータを数時間で転送します。プロジェクトは予定より早く進んでいるようです。

そのとき、チームはボトルネックに直面します。

既存のデータベースには、何百ものストアドプロシージャ、複雑なトリガー、そして PL/SQL や T-SQL など独自の SQL 言語で記述されたカスタム関数が埋め込まれています。これらのルーチンには、トランザクションの検証、注文処理、カスタムレポートの処理など、長年にわたる重要なビジネスロジックが含まれています。

モダナイゼーションプロジェクトは急に行き詰まります。数千行に及ぶ手続き型ロジックの変換には、2 つの言語に関する専門知識、数か月にわたる手作業での書き換えが必要となり、高確率で変換エラーが伴います。このコード変換は、データベース移行の「ラストワンマイル」のボトルネックであり、移行における最も複雑な部分です。

幸いなことに、このラストワンマイル問題は、最近の AI の進歩によって解決できます。Database Migration Service（DMS）には、Gemini を活用した AI によるコード変換が含まれています。移行ワークフローに生成 AI を直接組み込むことで、ストアドプロシージャ、トリガー、カスタム関数を、より高速かつ正確に PostgreSQL PL/pgSQL コードに変換できます。

ストアドプロシージャの変換に関する課題

商用データベースエンジンでは、ストアドプロシージャ、ユーザー定義関数、パッケージ本体、条件付きロジックに、ベンダー固有の構文が使用されています。このロジックを PostgreSQL PL/pgSQL に変換するには、変数の定義、例外処理ブロック、カーソルループ、組み込み関数のマッピングが必要になります。

何百ものストアドプロシージャを含む複雑なエンタープライズスキーマを移行する場合、たいていは手動でのコード変換に数か月のエンジニアリング作業が必要になります。データベースチームは、以前のロジックを 1 行ずつ解析し、条件分岐を実装し直して、エンジン間のデータ型変換を検証する必要があります。

DMS での AI によるコード変換

Gemini in Database Migration Service は、Google Cloud コンソール内で直接、この変換作業を迅速化します。DMS は、スキーマを自動的に変換するとともに、AI 生成のコードを提案して、ソース言語と PostgreSQL の構造上の違いを説明します。

PL/pgSQL に変換されたコードは、元のソースコードと並べて表示されます。データベースチームは提案内容をリアルタイムで確認、編集、検証できます。

図 1: Database Migration Service のインターフェースに、変換前後のコードと Gemini によるインラインの説明が表示されている。

AI の統合が重要である理由

主要ベンダーのほとんどの AI アプリや AI ツールには、SQL コードなどのコードを生成、変換する機能があります。しかし、汎用の AI チャットツールが提供するスニペットの変換機能では、エンタープライズデータベースの変換には不十分です。Gemini in Database Migration Service には、以下の重要な利点があります。

スキーマの完全なコンテキスト: Gemini in DMS は、コードスニペットを個別に評価するのではなく、移行プロジェクト全体にわたり、テーブルの関係、データ型、依存ビュー、プロシージャ間参照などのデータベースコンテキストを総合的に分析します。
エンタープライズ向けのセキュリティとプライバシー: コード変換は、厳密に Google Cloud プロジェクトの境界と IAM ガバナンスの範囲内で実行されるため、独自のビジネスロジックと知的財産を保護できます。
統合された実行ワークスペース: DMS を使用すると、何百ものファイルにわたる手動でのコピーと貼り付けが不要になります。単一のコンソール内で、並べて表示されたコードの違いと AI によるインラインの説明を確認し、必要に応じてコードを編集したうえで、検証済みの PL/pgSQL ルーティンをターゲットデータベースに直接デプロイできます。
決定論的な精度と AI コンパイル: DMS は決定論的なコンパイラルールによる 1 対 1 のマッピング（標準的な DDL 変換、スカラー関数、明確に定義された構文変換など）と、複雑な手続き型ブロックのための Gemini の文脈的統合を組み合わせることで、モデルのドリフトを防ぎ、正確で予測可能な変換を保証します。

Oracle PL/SQL から PostgreSQL への変換

顧客の合計注文額を算出し、独自の NVL 関数と DECODE 関数を使用して段階別の割引を適用する Oracle PL/SQL ストアドプロシージャを考えてみましょう。当初のワークフローでは、NVL を COALESCE に手動でマッピングし、DECODE ステートメントを標準の CASE 式に書き換え、WHEN NO_DATA_FOUND THEN などの例外ブロックを調整する必要がありました。

DMS で移行評価を実行すると、Gemini がソースプロシージャを分析し、ネイティブの PostgreSQL PL/pgSQL コードを生成します。

ソース: Oracle PL/SQL

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE PROCEDURE calculate_discount (\r\n p_customer_id IN NUMBER,\r\n p_discount OUT NUMBER\r\n) AS\r\n v_total NUMBER := 0;\r\nBEGIN\r\n SELECT NVL(SUM(amount), 0) INTO v_total\r\n FROM orders WHERE customer_id = p_customer_id;\r\n \r\n p_discount := DECODE(TRUE, v_total > 10000, 0.15, v_total > 5000, 0.10, 0.05);\r\nEXCEPTION\r\n WHEN NO_DATA_FOUND THEN\r\n p_discount := 0;\r\nEND;\r\n/'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ec53a4d0>)])]>

ターゲット: PostgreSQL PL/pgSQL（Gemini in DMS で変換）

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE FUNCTION calculate_discount (\r\n p_customer_id NUMERIC,\r\n OUT p_discount NUMERIC\r\n) RETURNS NUMERIC AS $$\r\nDECLARE\r\n v_total NUMERIC := 0;\r\nBEGIN\r\n SELECT COALESCE(SUM(amount), 0) INTO v_total\r\n FROM orders WHERE customer_id = p_customer_id;\r\n\r\n p_discount := CASE\r\n WHEN v_total > 10000 THEN 0.15\r\n WHEN v_total > 5000 THEN 0.10\r\n ELSE 0.05\r\n END;\r\nEND;\r\n$$ LANGUAGE plpgsql;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48ed992450>)])]>

Gemini は、生成された SQL とともに、NVL が COALESCE に変換された理由と、Oracle の DECODE 関数が PostgreSQL で明示的な CASE ブロックに変換された方法について、詳しい説明をインラインで表示します。

図 2: Gemini in DMS を活用したエンドツーエンドのデータベースコード変換パイプライン。

スキーマの完全な管理と検証の維持

セキュリティ、透明性、コードの精度は、データベースのモダナイゼーションにおいて依然として中心的な要素です。Gemini in DMS は、厳密に Google Cloud の確立されたセキュリティ境界内で動作し、コードをプロジェクト内に限定して公開します。

変換と検証のプロセスは、信頼性を保証するため、構造化されたワークフローに沿って行われます。

スキーマコンテキストの自動取得: DMS 変換ワークスペースを設定すると、テーブルスキーマ、データ型、外部キー制約、プロシージャ間の依存関係など、ソースデータベースの全メタデータが自動的に解析されます。Gemini では、このプロジェクト全体のコンテキストを参照してコードが生成されるため、依存オブジェクトの定義を手動で指定する必要はありません。
構文と依存関係の自動検証: コードの生成時、DMS はターゲットとなる PostgreSQL の構文ルールに照らして検証パーサーを実行します。検証ステータスインジケーター（変換済み、警告、要対応など）が各オブジェクトに割り当てられるため、手動での確認が必要なルーティンはすぐにわかります。
インタラクティブな評価状態: スキーマの変更はすべて完全に管理できます。変換ワークスペース内で、ターゲットデータベースに変更を適用する前に、コードを並べて違いを確認したり、AI によるインラインの説明を確認したり、PL/pgSQL コードを直接編集したりできます。
デプロイと検証のステージング: コードがワークスペース検証に合格したら、変換されたスキーマと関数をターゲットのステージングインスタンス（Cloud SQL や AlloyDB など）に適用し、本番環境への切り替え前に機能の実行とパフォーマンステストを行うことができます。

データベースのモダナイゼーションの効率化

Database Migration Service の AI によるコード変換により、データベースチームは以前のデータベースロジックを数か月ではなく数日で変換できます。データベース管理者とアプリケーション開発者は、貴重な時間を費やしてコードを最初から書き直す代わりに、新しい機能の追加、パフォーマンスのテスト、アプリケーションのモダナイゼーションに注力できます。

Oracle と SQL Server の一般的な変換シナリオと、DMS がそれらを PostgreSQL に変換する方法の代表的な例については、新しい Gemini に習う PostgreSQL 動画シリーズをご覧ください。

SQL Server コードを PostgreSQL に変換する

データベース移行に関する悩みを解消し、以前のデータベースロジックをシームレスに変換する方法を Gemini に教えてもらいましょう。

Database Migration Service を使ってみる

データベースの変換を始めるには、Database Migration Service コンソール（https://console.cloud.google.com/dms）で移行評価を実行するか、異種間移行ガイド（https://cloud.google.com/database-migration）をお読みください。

- Google Cloud、戦略的クラウドエンジニア、Tanya Sharma

「ノイジーネイバー」問題の解決: シャーディングアーキテクチャがマルチテナントプラットフォームを守る方法

Fri, 21 Aug 2026 02:00:00 +0000

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

マルチテナントの SaaS プロバイダ、社内データプラットフォームを管理する大企業、混合ワークロードのデータ処理を扱う企業のいずれであっても、共有インフラストラクチャ環境を管理するということは、「ノイジーネイバー」という共通の脅威に直面することを意味します。単一のテナントで大量のデータバーストやデータベースインスタンスの障害が発生した場合、環境内の他のテナントをダウンさせ、複数の重要なデータパイプラインにわたって大幅なバックログの蓄積やグローバル規模でのサービスレベル契約（SLA）違反を引き起こす可能性があります。

モノリシックアーキテクチャから、シャーディングを取り入れたハブアンドスポークパターンに移行して、プラットフォームの復元力を確保する方法をご紹介します。

課題: モノリシックのボトルネック

従来の一般的なアーキテクチャでは、すべてのテナントとビジネスドメインのデータを 1 つの巨大なストリームで処理します。パイプラインが統合されているため、特定のデータベーステナントインスタンスでパフォーマンスの問題が発生すると、バックプレッシャーが発生し、プラットフォーム上の他のすべてのテナントのパフォーマンスが低下します。

痛手となる影響:

100% の影響範囲: 1 つのデータベース障害で、すべての処理が停止する可能性があります。
非効率的なスケーリング: 多くの場合、「最悪のケース」のテナントに合わせてリソースをスケールする必要があるため、無駄な支出が多くなります。
SLA の不安定性: 1 つの大規模なテナントがシステム全体を遅延させる可能性がある場合、グローバル規模の SLA を維持することはほぼ不可能です。

解決策: シャーディングによるハブアンドスポークアーキテクチャ

この課題を解決するには、処理をルーティング用の「ハブ」と、分離された実行用の「スポーク」に分けます。

1. ハブ: ルーターパイプライン

ハブは、トラフィックコントローラとして機能する軽量の Dataflow ジョブです。統合されたソーストピックから読み取り、テナント ID またはビジネスドメインを解析して、データを分離されたバッファにファンアウトします。これにより、エントリーポイントがシンプルかつ堅牢になります。

2. バッファ: 永続的な分離

ハブとスポークの間に Pub/Sub トピックを導入します。これらは永続的な緩衝器として機能し、低速なダウンストリームシンクが元のソースをバックアップするのを防ぎます。

3. スポーク: 分離された実行

1 本の巨大なパイプラインではなく、複数の小規模な Dataflow インスタンスをデプロイして、ワークロードごとに分類します。

ティア 1（優先度高）: 重要なテナント向けにリソース割り当てを多くした専用パイプライン。
共有ティア: 小規模なテナント向けにパイプラインをグループ化して費用を最適化。
ドメイン固有: コードの複雑さを分離するために、複雑なロジック（異なるビジネスドメインの分離など）に特化したパイプライン。

メリットの比較

機能	モノリシック（従来）	ハブアンドスポーク
フォールトトレランス	1 つの DB の障害ですべてが停止	障害は特定のスポークに限定
影響範囲	100%	5% 未満（1 つのスポークに限定）
リソースのスケーリング	「最悪のケース」を想定してスケーリング	テナントの負荷ごとに独立したスケーリング
メンテナンス	グローバルなアップデートが全体に影響	他のドメインに影響を与えずに 1 つのドメインを更新

実装に関する活用のヒント

このアーキテクチャへの移行は、単に構成図の中でボックスを移動するだけではありません。最大限の安定性を確保するためには、追加で「スポーク」レベルを最適化することが推奨されます。

デッドレターキュー（DLQ）の実装: 単一の SQL 例外によってパイプラインが停止しないようにします。失敗したレコードをストレージ（BigQuery や Google Cloud Storage など）にルーティングして、後で調査します。
厳格な接続プール: データベースには接続制限があります。スレッドセーフなシングルトンパターンを使用し、ワーカーあたりの MaximumPoolSize を低く（1～2 などに）設定して、自動スケーリング中にデータベースを使い果たさないようにします。
非同期 I/O: GroupIntoBatches 変換を使用して書き込みをバッファリングすることで、データベースに起因するレイテンシのトリガーとなることが多い接続オーバーヘッドを削減します。

まとめ

シャーディングのアプローチを採用することで、プラットフォームは「ノイジーネイバー」が近隣の脅威にならないことを保証できます。このアーキテクチャは、厳格な SLA を維持するために必要な分離を実現すると同時に、独立したスケーリングと、より安全なデプロイを可能にします。

シャーディングによるハブアンドスポークアーキテクチャの実装について詳しくは、Dataflow のドキュメントをご覧ください。

- Google Cloud、クラウドデータエンジニア Sri Harshini Donthineni

- Google Cloud、クラウドデータコンサルタント Abdullateef Abdulsalam

Cloud Blog JA

金融サービスにおけるエージェント型 AI を活用したオペレーショナル レジリエンスの構築

机上演習からレジリエンス インテリジェンスへ

制御と柔軟性を実現するデュアル オーケストレーション

Google Cloud で生成とガバナンスを強化

スケーラブルでエビデンス対応のレジリエンス テスト

レジリエンス インテリジェンスに向けて

構造化データと非構造化データのインサイトを統合する BigQuery 検索のイノベーション

パイプラインを簡素化する「自律型エンベディング生成」（一般提供版）

実際の活用例

大規模な自然言語検索を可能にする「AI.SEARCH」（一般提供版）

キーワードとベクトルを統合する「ハイブリッド検索」（公開プレビュー版）

エンドツーエンドの非構造化データ分析プラットフォームの構築

準備ができたら

ゼロコード、低コストのデータの取り込み: BigQuery DTS の新機能

エコシステムの拡大: 新しいコネクタと機能

エンタープライズ データベースとリレーショナル データベース（完全転送と増分転送の両方をサポート）

e コマースとグロース マーケティング

移行コネクタ

主要なコネクタの機能強化

BigQuery Data Transfer Service を選ぶ理由

データ運用の変革を始めましょう

次に構築すべきコネクタは？

Google Dataflow で費用対効果に優れた高スループットな生成 AI ワークフローを構築する

大規模ストリーム向けのユニバーサルなブループリント

アーキテクチャ: ストリーミング イベントを事前にフィルタする理由

パイプライン フロー

適応的実行: Beam DAG の動的な構成

パイプラインの実装

コストとパフォーマンスのメリット

重要ポイント

AI 時代の FinOps：エージェント向けの新しい柔軟な請求と費用管理

Gemini Enterprise の支出をコントロールしながらチームに柔軟性を提供

単一の Gemini Enterprise サブスクリプションで高度なエージェント ツールをデベロッパーに提供

Gemini Enterprise Flexible Savings Plans（FSPs）でよりスマートに予算を管理

財政規律を維持しながらチームに構築の自由を提供

AI 費用の最適化をさらに深めるには

Malachyte がマネージド リアルタイム AI で小売業のコールド スタート問題を解決した方法

Malachyte はお客様の売り上げをどのように伸ばしたのか

使ってみる

Gemini Enterprise、業界特化型ソリューション向けに進化

Gemini Enterprise for Financial Services によるイノベーション、セキュリティ、コンプライアンスの融合

Gemini Enterprise for Financial Services の主な構成要素:

法務実務向けに特化した AI である Gemini Enterprise for Legal

Gemini Enterprise for Legal の主な構成要素:

提供時期

Box が Gemini Embeddings 2 でマルチモーダル エンタープライズ エージェントを実現

エンベディングの改善によるメリット: ドキュメント コンテンツの次元の拡張

アーキテクチャ ソリューション: Gemini Multimodal Embeddings 2

マルチモーダル エンタープライズ エージェントの 3 つのコアパターン

エージェント型エンタープライズ コンテンツ管理の未来

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

TelevisaUnivision が Google Cloud を選んだ理由

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

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

まとめ

【Google Cloud Next Tokyo 26】DAY 2 基調講演まとめ：インフラからセキュリティまで、フルスタックで支える AI エージェント

AI を支えるインフラ

エージェントを本番で動かすプラットフォーム

データにコンテキストを与える Agentic Data Cloud

1,000万人の都民が使う共通の入り口を目指して

NTTドコモが目指すフル AI マーケティング

AI の脅威に AI で立ち向かうセキュリティ

まとめ

メジャーがサポートされるようになった BigQuery Graph を使用して、信頼できるエージェント ワークロードを実現

仕組み

BigQuery Studio でグラフ インテリジェンスを民主化

統合されたセマンティクス: Looker とのネイティブなインテグレーション

エージェント型モバイルアプリ開発のためのデベロッパー デバイス プラットフォームのご紹介

アプリを構築してテストし、パフォーマンスを保証する

DDP エージェント スキルと効率的なテストでモバイルアプリ開発を加速させる

デベロッパー デバイス プラットフォームで今すぐ開発を始めましょう

【Google Cloud Next Tokyo 26】 DAY 1 基調講演まとめ：日本企業の現場で動き始めた AI エージェント

「電気で 30 年」を、AI なら何年で？

NTTデータ：自らが Client Zero となって

Gemini Enterprise の進化と、小売の現場デモ

開発者に向けたアップデート

SOMPOホールディングス：グループ 3 万 4,000 人が使う「SOMPO AI エージェント」

Ｓｋｙ：5 か月で 2 万個のエージェントを自作

スクウェア・エニックス：見て、考えて、動く AI

金融サービスにおけるエージェント型 AI を活用したオペレーショナルレジリエンスの構築

机上演習からレジリエンスインテリジェンスへ

制御と柔軟性を実現するデュアルオーケストレーション

スケーラブルでエビデンス対応のレジリエンステスト

レジリエンスインテリジェンスに向けて

エンタープライズデータベースとリレーショナルデータベース（完全転送と増分転送の両方をサポート）

e コマースとグロースマーケティング

アーキテクチャ: ストリーミングイベントを事前にフィルタする理由

パイプラインフロー

単一の Gemini Enterprise サブスクリプションで高度なエージェントツールをデベロッパーに提供

Malachyte がマネージドリアルタイム AI で小売業のコールドスタート問題を解決した方法

Box が Gemini Embeddings 2 でマルチモーダルエンタープライズエージェントを実現

エンベディングの改善によるメリット: ドキュメントコンテンツの次元の拡張

アーキテクチャソリューション: Gemini Multimodal Embeddings 2

マルチモーダルエンタープライズエージェントの 3 つのコアパターン

エージェント型エンタープライズコンテンツ管理の未来

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

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

メジャーがサポートされるようになった BigQuery Graph を使用して、信頼できるエージェントワークロードを実現

BigQuery Studio でグラフインテリジェンスを民主化

エージェント型モバイルアプリ開発のためのデベロッパーデバイスプラットフォームのご紹介

DDP エージェントスキルと効率的なテストでモバイルアプリ開発を加速させる

デベロッパーデバイスプラットフォームで今すぐ開発を始めましょう

Gemini Enterprise データを Looker のセマンティックレイヤで制御してユーザーの信頼を確保

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

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

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

WPP が AI マーケティングのためにプラットフォームとデータエンジニアリングを運用化

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

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

ストアドプロシージャの変換に関する課題

「ノイジーネイバー」問題の解決: シャーディングアーキテクチャがマルチテナントプラットフォームを守る方法

解決策: シャーディングによるハブアンドスポークアーキテクチャ