GCP News - 2026-08-28

When Pythian rolled out Google Cloud’s Gemini Enterprise across our 500-person company in 27 countries, the goal was simple: use our own company as a proving ground to discover how enterprise AI actually delivers ROI.

What we found changed our strategy entirely.

Since the rollout of Gemini Enterprise and our previous enterprise AI deployments, Pythian observed firsthand why so many enterprise AI initiatives stall out or fail. 

Most organizations trap themselves in a tool-centric mindset — buying licenses, making tools broadly available, and assuming value will naturally follow. They get stuck chasing "nickel and dime" micro-efficiencies (like saving 5 minutes per user) while missing structural, high-ROI workflow transformations. Compounding the problem, even when custom agents are built, they frequently stall in pilot mode or break down in production because teams lack the operational capability to manage AI model drift, agent lifecycles, and ongoing observability.

To solve this, we engineered the Pythian AI Operating Model — a multifaceted, end-to-end framework designed to take enterprise AI from high-level strategy all the way into sustained production. While our dual center of excellence (COE) serves as the core execution muscle, it is the application of the entire framework, from Field CTO strategy and tooling deployment to the dual COE and XOps, that consistently unlocks million-dollar outcomes.

By proving this complete model internally first, Pythian drove a 3x surge in active user engagement and cut our database incident resolution times by 80%.

The four pillars of the Pythian AI operating model

To move past the common failure points of enterprise AI, our framework consolidates strategy, execution, and operations into a single continuous loop:

Field CTO strategy  ──>  tooling deployment  ──>  dual COE execution  ──>  production XOps

1. Field CTO strategy and governance: Generative AI is arguably the most academically challenging architectural shift in IT history. Led by former C-suite tech leaders, our Field CTO practice provides executive advisory to establish steering committees and clear value metrics. The team audits operations using 16 horizontal agentic patterns (like automated document processing and runbook creation) to build a prioritized backlog of high-ROI use cases before development starts.

2. Tooling and platform deployment: The team establishes a secure, production-grade foundation on platforms like Gemini Enterprise and connects AI directly into CRMs, ERPs, and database estates to ground models in real corporate context.

3. The dualCOE: This execution muscle is split into two specialized engines:

• People productivity COE: This group handles adoption and change management. Instead of expecting non-technical teams (like HR or Procurement) to build its own agents, this COE builds no-code agents for them, focusing entirely on enablement.

• Process productivity COE: This team engineers deep, custom-coded AI agents and complex agentic workflows that integrate into core data platforms for autonomous operations.

4. XOps (AI production management): While deploying an agent is 20% of the journey,  maintaining accuracy in production is 80%. Because AI models and prompt structures naturally drift over time, this XOps practice provides the continuous monitoring, prompt tuning, and model observability needed to keep agents performing without breaking core workflows.

The difference between chasing minor, scattered efficiencies and driving structural enterprise ROI comes down to how you align your operating strategy:

Real-world impact: from database ops to global supply chains

Whether managing 70 manufacturing plants or 30,000 enterprise databases, AI succeeds when tied to structural, high-value workflows:

• Pythian “as a customer:” Across 15,000 monthly database tickets, our Process COE deployed an agentic workflow that reads tickets, searches knowledge bases, and auto-generates mini runbooks before an engineer touches them. The result was slashed mean time to resolution by 80% and tripled active user engagement.

• Knowledge management customer: We deployed autonomous IT support agents across 10,000 consultants. As a result, we were able to automate 10% of 20,000 annual IT tickets into "no-touch" resolutions, saving 1,000,000+ operational hours.

• Supply chain customer: By building custom agentic supply chain tools on Gemini Enterprise, we compressed forecast-matching cycles from weeks down to 2–3 days across 70 global manufacturing sites.

• Retail customer: We combined Gemini Agentic AI and computer vision to automate store product onboarding. As a result, we transformed a 20-minute manual task into a multi-second flow.

Ready to build your AI operating model?

Scaling AI demands more than tool-level experimentation. It also requires an end-to-end AI operating model. Learn how Pythian pairs with Google Cloud to operationalize strategy, streamline XOps, and fast-track your Gemini Enterprise journey.

Need a low-cost, high-performance way to run long-lived, stateful workloads such as AI agents? Today, we introduced Cloud Run instances, which let you do just that.  

Consider AI agents such as OpenClaw or Hermes, which are intended for individual developers or personal use. Because these agents often work continuously and tend to serve only one user at a time, their infrastructure requirements look quite different from stateless, high-throughput web services that typically run on Cloud Run services.

Cloud Run services scale to zero when requests stop, so they aren’t ideal for a long-lived agent that expects exactly one copy to be running continuously. On the other hand, the alternative — running a dedicated VM — means paying for full compute 24/7, managing operating system updates, opening firewall ports, and provisioning your own HTTPS endpoints.

Cloud Run instances provide dedicated, singleton compute runtimes on Cloud Run. They have the following attributes:

• Runs just one instance with no autoscaling

• Up to 7-day continuous runtime, with automatic restart policy configured by default

• Every instance gets a HTTPS URL that remains unchanged across updates and restarts.

• You can stop each instance when you aren't using it and resume it whenever you need it

The cost to run a Cloud Run instance with 1 vCPU and 1 GiB of memory continuously for 30 days is $5.70. Cloud Run instances use shared vCPU with vCPU burst budgets to run continuously for a low, predictable price. This model is also ideal for long-lived agents that aren’t doing compute-intensive work all the time, and only spike in usage when asked to perform a task.

Example: Deploy OpenClaw on a Cloud Run instance

OpenClaw is an open-source personal AI agent that can perform various tasks on your behalf, and become a better assistant over time. Many OpenClaw users start out running it on their own laptops, until they realize they need somewhere to run it where it won’t shut down every time their laptop goes to sleep.

Deploying OpenClaw to a Cloud Run instance is easy. Once you’ve uploaded OpenClaw’s configuration files to a Cloud Storage bucket, you can deploy your OpenClaw agent to a Cloud Run instance with just one command:

Once deployed, you can keep this OpenClaw instance running for as long as you want. You can interact with it over Telegram, WhatsApp, or the social media platform of your choice, and connect it to any tools you want it to use, as well.

For the full instructions on how to deploy OpenClaw, refer to this codelab.

Coming soon, we’re also launching SSH access for both Cloud Run instances and Cloud Run services. Sign up for private access here.

What users are saying

Cloud Run instances are helping Google Cloud users achieve their goals for running AI agents and other long-lived workloads at low cost and high performance.

OffDeal, an AI-powered investment bank for small businesses, is running long-lived agents on Cloud Run instances:

“We're currently using Cloud Run instances as our primary infrastructure for our long-running agent. It reduced cold starts by 88%. Everything was very straightforward to implement, and it has been very reliable.” - Luis Ruiz Morel, Member of Technical Staff @ OffDeal

Learn more

Currently in preview, Cloud Run instances are a cost-effective way to run a new kind of workload, without sacrificing performance. For more information about Cloud Run instances, check out the following resources:

• How to deploy Openclaw to Cloud Run instances

• Cloud Run instances documentation

※この投稿は米国時間 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

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

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

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

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

1. 自律型エンベディング生成（一般提供版）

2. 単一クエリのパフォーマンスが大幅に向上する AI.SEARCH（一般提供版）

3. ハイブリッド検索（公開プレビュー版）

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

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

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

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

実際の活用例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="image1" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/image1_bQnyG2Q.gif" />
    
    </a>
  
</figure>


  </div>
</div>

• アクセス: オブジェクト テーブルを使用して、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

※この投稿は米国時間 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）を使用してエージェント主導の連携を実現しています。このアプローチにより、同行のプラットフォームは、あらかじめ実行パスを定義しておく必要がなく、状況を動的に分析して回答を生成できるようになります。

<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="image1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_dbc2MvR.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>図 1. コンテキスト アセンブリ、オーケストレーション、シナリオ生成のアーキテクチャ。</p></figcaption>
  
</figure>


  </div>
</div>

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

「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

When Pythian rolled out Google Cloud’s Gemini Enterprise across our 500-person company in 27 countries, the goal was simple: use our own company as a proving ground to discover how enterprise AI actually delivers ROI.

What we found changed our strategy entirely.

Since the rollout of Gemini Enterprise and our previous enterprise AI deployments, Pythian observed firsthand why so many enterprise AI initiatives stall out or fail. 

Most organizations trap themselves in a tool-centric mindset — buying licenses, making tools broadly available, and assuming value will naturally follow. They get stuck chasing "nickel and dime" micro-efficiencies (like saving 5 minutes per user) while missing structural, high-ROI workflow transformations. Compounding the problem, even when custom agents are built, they frequently stall in pilot mode or break down in production because teams lack the operational capability to manage AI model drift, agent lifecycles, and ongoing observability.

To solve this, we engineered the Pythian AI Operating Model — a multifaceted, end-to-end framework designed to take enterprise AI from high-level strategy all the way into sustained production. While our dual center of excellence (COE) serves as the core execution muscle, it is the application of the entire framework, from Field CTO strategy and tooling deployment to the dual COE and XOps, that consistently unlocks million-dollar outcomes.

By proving this complete model internally first, Pythian drove a 3x surge in active user engagement and cut our database incident resolution times by 80%.

The four pillars of the Pythian AI operating model

To move past the common failure points of enterprise AI, our framework consolidates strategy, execution, and operations into a single continuous loop:

Field CTO strategy  ──>  tooling deployment  ──>  dual COE execution  ──>  production XOps

1. Field CTO strategy and governance: Generative AI is arguably the most academically challenging architectural shift in IT history. Led by former C-suite tech leaders, our Field CTO practice provides executive advisory to establish steering committees and clear value metrics. The team audits operations using 16 horizontal agentic patterns (like automated document processing and runbook creation) to build a prioritized backlog of high-ROI use cases before development starts.

2. Tooling and platform deployment: The team establishes a secure, production-grade foundation on platforms like Gemini Enterprise and connects AI directly into CRMs, ERPs, and database estates to ground models in real corporate context.

3. The dualCOE: This execution muscle is split into two specialized engines:

• People productivity COE: This group handles adoption and change management. Instead of expecting non-technical teams (like HR or Procurement) to build its own agents, this COE builds no-code agents for them, focusing entirely on enablement.

• Process productivity COE: This team engineers deep, custom-coded AI agents and complex agentic workflows that integrate into core data platforms for autonomous operations.

4. XOps (AI production management): While deploying an agent is 20% of the journey,  maintaining accuracy in production is 80%. Because AI models and prompt structures naturally drift over time, this XOps practice provides the continuous monitoring, prompt tuning, and model observability needed to keep agents performing without breaking core workflows.

The difference between chasing minor, scattered efficiencies and driving structural enterprise ROI comes down to how you align your operating strategy:

Real-world impact: from database ops to global supply chains

Whether managing 70 manufacturing plants or 30,000 enterprise databases, AI succeeds when tied to structural, high-value workflows:

• Pythian “as a customer:” Across 15,000 monthly database tickets, our Process COE deployed an agentic workflow that reads tickets, searches knowledge bases, and auto-generates mini runbooks before an engineer touches them. The result was slashed mean time to resolution by 80% and tripled active user engagement.

• Knowledge management customer: We deployed autonomous IT support agents across 10,000 consultants. As a result, we were able to automate 10% of 20,000 annual IT tickets into "no-touch" resolutions, saving 1,000,000+ operational hours.

• Supply chain customer: By building custom agentic supply chain tools on Gemini Enterprise, we compressed forecast-matching cycles from weeks down to 2–3 days across 70 global manufacturing sites.

• Retail customer: We combined Gemini Agentic AI and computer vision to automate store product onboarding. As a result, we transformed a 20-minute manual task into a multi-second flow.

Ready to build your AI operating model?

Scaling AI demands more than tool-level experimentation. It also requires an end-to-end AI operating model. Learn how Pythian pairs with Google Cloud to operationalize strategy, streamline XOps, and fast-track your Gemini Enterprise journey.