顧客事例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yahoo が Managed Service for Apache Spark のフレキシブル VM でリソースを最適化している方法

Tue, 15 Sep 2026 03:00:00 +0000

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

Yahoo は、数億人のユーザーを金融、スポーツ、エンターテイメントのプラットフォームに接続するグローバルなメディアおよびテクノロジー企業として、分析ワークロードを高速で継続的に実行する必要がある大規模なデータインフラストラクチャを運用しています。期限が重視されるデータ環境では、固定の仮想マシン（VM）構成に依存すると、システムが脆弱になります。特定のマシンシェイプがリージョンの容量制限に直面すると、Managed Service for Apache Spark（旧称 Dataproc）でのクラスタプロビジョニングが遅延し、重要なデータパイプラインが停止する可能性があります。

Yahoo は、Managed Service for Apache Spark クラスタでフレキシブル VM を利用し、許容可能な VM シェイプのランク付けされたリストを定義することで、これらのリソースの変動に自動的に対応しています。これにより、システムはリージョンゾーンを動的に検索し、手動による介入なしでパイプラインの実行を維持できます。リージョン全体で容量を検索するには、自動ゾーンプレースメントも有効にする必要があります。

この最適化は、オンプレミスの Hadoop とビッグデータ資産を Google Cloud に直接移行する、Yahoo のより広範なデータモダナイゼーションの取り組みを基盤としています。これらのレガシーワークロードを移行することで、チームは動的なリソースの柔軟性を備えた、大規模なバッチ分析とストリーミング分析を実行できるクラウド基盤を確立しました。

この投稿では、Managed Service for Apache Spark でフレキシブル VM インスタンスのランキングを構成し、容量の制約を自動的に管理してパイプラインの実行を維持するための技術的なブループリントをご紹介します。

静的構成の運用上のトレードオフ

特定のゾーンで固定された単一のマシンタイプを使用してクラスタを構成すると、リージョンゾーンの容量が変動した場合に制約が生じ、クラスタのプロビジョニングに影響する可能性があります。カスタムの再試行ロジックや手動による介入によってこれらの容量の変動を管理するのではなく、柔軟な構成を使用することで、インフラストラクチャを自動的に適応させることができます。柔軟な構成により、複数の VM シェイプを受け入れ、選択したリージョン内のゾーン全体で検索を行うことで、プロビジョニングを合理化し、大規模な分析ワークロードをより適切にサポートできます。

柔軟なクラスタを構成するためのルール

柔軟な構成をデプロイするには、一連の設計上の選択を調整する必要があります。

自動ゾーンプレースメントを有効にする: Managed Spark がリージョン全体で利用可能な容量を検索できるように、リージョン（--region=${REGION}）または空のゾーン文字列（--zone=""）を渡す必要があります。
コアとメモリの均一性を維持する: Managed Spark クラスタで自動スケーリングを使用する場合、フレキシブルリスト内のすべてのマシンタイプは、異なる VM ファミリーのものであっても、同様のコア数とメモリサイズを共有する必要があります。プライマリワーカーとセカンダリワーカーで CPU とメモリの比率を統一すると、最小の比率によって有効なコンテナのサイズが決まるため、パフォーマンスの低下を防ぐことができます。
コンポーネントプロパティを調整する: Managed Spark は、VM のコアとメモリに基づいてシステムプロパティを計算します。マシンシェイプを混在させる場合、YARN と Spark のリソース割り当てをワーカーの想定される動作に合わせるために、プロパティの明示的なオーバーライドが必要になることがあります。

フレキシブル VM が大規模なワークロードをサポートする 2 つの方法

大規模なデータ環境の場合、柔軟な構成は次の 2 つの方法で運用をサポートします。

クラスタ作成の成功率の向上: 優先 VM タイプが利用不可の場合に失敗せず、Managed Spark がランク付けされたリストから代替の VM タイプを選択してプロビジョニングを継続します。
リージョンリソースの使用効率の向上: 自動ゾーンプレースメントでは、リージョン全体が検索され、容量が検出されるため、需要が高い期間のプロビジョニングの摩擦が軽減されます。

gcloud の例

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters create analytics-cluster \\\r\n --region=us-central1 \\\r\n --zone="" \\\r\n --num-workers=10 \\\r\n --master-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --master-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbe666cbe90>)])]>

API の例

この容量ポリシーは、Dataproc API の instanceFlexibilityPolicy フィールドを使用して、自動化されたパイプラインまたは Managed Service for Apache Airflow DAG に組み込むこともできます。

code_block: <ListValue: [StructValue([('code', '{\r\n "projectId": "PROJECT_ID",\r\n "clusterName": "analytics-cluster",\r\n "config": {\r\n "gceClusterConfig": {\r\n "zoneUri": ""\r\n },\r\n "secondaryWorkerConfig": {\r\n "numInstances": 8,\r\n "instanceFlexibilityPolicy": {\r\n "instanceSelectionList": [\r\n {\r\n "machineTypes": ["n2-standard-8"],\r\n "rank": 0\r\n },\r\n {\r\n "machineTypes": ["e2-standard-8", "t2d-standard-8"],\r\n "rank": 1\r\n }\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbe644f9110>)])]>

この API ポリシーは、同じ目標を達成します。つまり、優先するシェイプを確立し、有効なフォールバックを文書化し、自動化スクリプトを中断することなく、Managed Spark がリソースの制約を解決できるようにします。

インフラストラクチャポリシーの確立

この規模のデータを管理するには、固定された単一のマシンタイプに依存するのではなく、明確なリソースポリシーを標準化する必要があります。構成基準では、以下を規定する必要があります。

セカンダリワーカーの優先 VM ファミリーとフォールバック VM ファミリー。
柔軟なプロビジョニングを可能にするためのデフォルトの自動ゾーンプレースメント。
自動スケーリングを使用する場合のコアとメモリの同一構成。
コンテナのサイズを予測可能に保つためにすべてのワーカーグループで統一された CPU とメモリの比率。
異なるマシンライン間で一貫したランタイム動作を保証するための、YARN または Spark プロパティの明示的なオーバーライド。
Spot または弾力性の高い容量で実行される Spark ワークロード向けのシャッフルセーフパターン。

柔軟な構成を採用することで、インフラストラクチャのリソース不足が解消され、予測可能なフォールバックプランが適用されるため、重要なデータパイプラインを稼働させ続けることができます。

Yahoo の影響と結果

Yahoo は、Managed Service for Apache Spark にフレキシブル VM を実装することで、リージョンの容量不足が原因で発生していたクラスタプロビジョニングの失敗を 85% 削減することに成功しました。この柔軟な構成により、データインフラストラクチャは容量の制約に自動的に対処し、手動による介入を必要とせずにリソースを正常にプロビジョニングできます。その結果、Yahoo はワークロードを継続的に実行できるようになり、大規模なデータパイプライン全体でダウンストリーム処理の遅延を防止しています。

「Yahoo で大規模なデータ分析を管理するには、復元力のある自動化されたインフラストラクチャが必要です。Managed Service for Apache Spark のフレキシブル VM に移行したことで、当社のアプローチは一変しました。特定のマシンシェイプが容量の制約に直面したときに処理が停止するのではなく、クラスタがランク付けされたフォールバックオプションに自動的に切り替わるようになりました。これにより、プロビジョニングの失敗を 85% 削減し、グローバルメディアプラットフォームをスムーズに運用し続けるために必要な信頼性を確保できました。」- Yahoo!、シニアソフトウェアデベロッパーエンジニア、Akshay Jain 氏

柔軟なインフラストラクチャの戦略上のメリット

柔軟なコンピューティングスタックを採用することで、環境を運用ニーズに適応する動的なリソースプールへと変革できます。固定された単一のマシンタイプ構成に縛られないため、供給の変動に関係なく、ワークロードが必要なコンピューティングに確実にアクセスできるようになります。この移行により、ワークロードの入手可能性と信頼性が最大限に高まるだけでなく、古いタイプの VM を信頼性の高いフォールバックオプションとして維持しながら、新しい世代の VM を優先できるため、シームレスなハードウェアのモダナイゼーションが促進されます。

復元力のあるデータパイプラインを構築する

流動的なコンピューティング戦略に移行することで、リージョンリソースが変化しても、重要な分析を継続できます。インフラストラクチャの最適化を今すぐ始める方法を以下に示します。

ワークロードを検証する: 特定の VM ファミリーやゾーンに緊密に結合されているアプリケーションを特定し、実行可能な代替ハードウェアシェイプをマッピングします。
リソースポリシーを標準化する: Managed Spark のフレキシブル VM のドキュメントを読んで、優先 VM ファミリーとフォールバック VM ファミリーを確立します。
財務戦略を調整する: ワークロードが代替マシンタイプに動的に移行する場合に、フレキシブル確約利用割引（フレキシブル CUD）を利用して費用の予測可能性を維持します。
クレジットを獲得する: 新規のお客様は、Managed Service for Apache Spark や他の Google Cloud プロダクトを無料で試すことができる $300 分のクレジットを獲得できます。

- Yahoo、シニアソフトウェアエンジニア Akshay Jain 氏

- Google Cloud、データ / AI エンジニア Surjit Singh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Uber の事例の要点

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

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

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

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

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

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

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

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

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

業務の再定義: Pythian の社内 AI ハンドブックがもたらす顧客の ROI

Thu, 03 Sep 2026 02:00:00 +0000

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

Pythian が 27 か国に展開する 500 人規模の自社全体に Google Cloud の Gemini Enterprise を導入した際、その目的は明快でした。それは、自社を実証の場として、エンタープライズ AI が実際にどのように ROI をもたらすのかを見極めることでした。

そこで得られた知見が、私たちの戦略を根本から変えました。

Gemini Enterprise のロールアウトや、それ以前のエンタープライズ AI のデプロイを通じて、Pythian は、なぜこれほど多くの AI プロジェクトが停滞や失敗に終わるのかを、実体験として目の当たりにしてきました。

ほとんどの組織は、ツール中心の考え方の罠に陥っています。ライセンスを購入してツールを広く展開しさえすれば、価値は自ずとついてくると信じ込んでいるのです。ユーザーあたり 5 分の節約といった些細な効率化を追い求めるあまり、構造的で ROI の高いワークフローの変革を見逃してしまいます。さらに厄介なことに、カスタムエージェントを構築したとしても、AI モデルドリフト、エージェントのライフサイクル、継続的なオブザーバビリティを管理する運用能力がチームに不足しているため、試験運用の段階で停滞したり、本番環境で破綻したりすることが少なくありません。

この課題を解決するために、Pythian は Pythian AI オペレーティングモデルを構築しました。これは、エンタープライズ AI を大局的な戦略策定から持続的な本番運用へと導くために設計された、多面的かつエンドツーエンドのフレームワークです。デュアルセンターオブエクセレンス（COE）が実行の原動力を担う一方で、一貫して数百万ドル規模の成果を引き出しているのは、フィールド CTO 戦略やツールのデプロイからデュアル COE、XOps に至るまで、フレームワーク全体を適用することにほかなりません。

この完全なモデルをまず社内で実証することで、Pythian はアクティブユーザーエンゲージメントを 3 倍に急増させ、データベースインシデントの解決時間を 80% 短縮しました。

Pythian AI オペレーティングモデルの 4 つの柱

エンタープライズ AI の一般的な失敗要因を克服するために、Pythian のフレームワークでは、戦略、実行、運用を 1 つの継続的なループに統合しています。

フィールド CTO 戦略 ──> ツールのデプロイ ──> デュアル COE の実行 ──> 本番環境 XOps

フィールド CTO 戦略とガバナンス: 生成 AI は、IT の歴史において、理論的にも最も難易度の高いアーキテクチャの転換であると言えるでしょう。役員出身の技術リーダー陣が率いるフィールド CTO プラクティスは、経営幹部向けのアドバイザリーを通じて、運営委員会の設立や明確な価値指標の策定を支援します。チームは、16 個の水平方向のエージェント型パターン（ドキュメント処理の自動化やランブックの作成など）を使用して運用を監査し、開発が開始される前に、費用対効果の高いユースケースの優先順位付けされたバックログを構築します。
ツールとプラットフォームのデプロイ: チームは、Gemini Enterprise などのプラットフォーム上に本番環境グレードのセキュアな基盤を確立し、AI を CRM、ERP、データベース資産に直接接続して、実際の企業コンテキストにモデルをグラウンディングします。
デュアル COE: この実行エンジンは、2 つの専門エンジンに分かれています。

従業員の生産性 COE: このグループは、導入とチェンジマネジメントを担当します。技術部門以外のチーム（人事や調達など）が独自のエージェントを構築することを期待するのではなく、この COE は、イネーブルメントに完全に焦点を当てて、これらのチーム向けにノーコードエージェントを構築します。
プロセス生産性 COE: このチームは、自律的な運用のためにコアデータプラットフォームに統合される、高度なカスタムコード AI エージェントと複雑なエージェントワークフローを設計します。

XOps（AI 本番環境管理）: エージェントのデプロイは取り組みの 20% にすぎず、本番環境での精度を維持することが 80% を占めます。AI モデルとプロンプト構造は時間の経過とともに自然に変化するため、この XOps プラクティスは、コアワークフローを中断することなくエージェントのパフォーマンスを維持するために必要な継続的なモニタリング、プロンプトチューニング、モデルのオブザーバビリティを提供します。

散発的な小さい効率化を追求することと、構造的な企業 ROI を推進することの違いは、オペレーティング戦略をどのように調整するかによって決まります。

アライメント要素	ツール中心のアプローチ	Pythian AI オペレーティングモデル
主要な指標	ユーザー 1 人あたりの節約時間	インパクトの大きいワークフローの再定義と ROI
運用の重点	指針のない広範なツール提供	16 のエージェントパターンによる優先順位付けされたバックログ
実行力	ユーザーによるアドホックなテスト	デュアル COE（人材とプロセスの生産性）
本番環境のライフサイクル	モニタリングされていない静的デプロイ	アクティブ XOps（継続的な精度とドリフトの管理）

実際の導入効果: データベース運用からグローバルサプライチェーンまで

70 か所の製造プラント管理であれ、30,000 個のエンタープライズデータベース管理であれ、AI は構造的で価値の高いワークフローに結びついたときに成果を発揮します。

「自らが顧客となる」Pythian の事例: 月間 15,000 件に及ぶデータベースチケットに対し、プロセス COE は、エンジニアが着手する前にチケットの読み取り、ナレッジベースの検索、ミニランブックの自動生成を行うエージェント型ワークフローをデプロイしました。その結果、平均解決時間が 80% 短縮され、アクティブユーザーエンゲージメントが 3 倍になりました。
ナレッジマネジメント企業の顧客: 10,000 人のコンサルタントに自律型 IT サポートエージェントをデプロイしました。その結果、年間 20,000 件の IT チケットの 10% を「ノータッチ」で解決できるようになり、100 万時間以上の運用時間を節約できました。
サプライチェーン企業の顧客: Gemini Enterprise でカスタムのエージェントサプライチェーンツールを構築することで、世界 70 か所の製造拠点で予測マッチングサイクルを数週間から 2～3 日に短縮できました。
小売企業の顧客: Gemini エージェント型 AI とコンピュータビジョンを組み合わせて、店舗の商品オンボーディングを自動化しました。その結果、20 分かかっていた手動タスクを数秒のフローに変換できました。

AI オペレーティングモデルを構築する準備はできましたか？

AI をスケールするには、ツールレベルのテストだけでは不十分です。エンドツーエンドの AI オペレーティングモデルも必要になります。Pythian が Google Cloud と連携して戦略を体系化し、XOps を合理化して、Gemini Enterprise 導入への道のりをどのように加速させるか、ぜひ詳細をご覧ください。

- Pythian、最高技術責任者、Paul Lewis 氏

- Pythian、ビジネス開発担当バイスプレジデント、Vanessa Simmons 氏

Mirendil の事例: トレーニング前後のアプリケーションに AI Hypercomputer のTPU と GPU を活用

Tue, 01 Sep 2026 01:00:00 +0000

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

ほぼすべての大手 AI 研究所が、モデルのトレーニング、エージェントの推論、最先端の研究などに Google Cloud インフラストラクチャを使用しています。Google Cloud は、業界の研究とイノベーションを牽引する急成長中の新興 AI スタートアップから選ばれるプラットフォームであり続けています。

このたび、AI 開発の加速に注力する最先端の AI 研究所である Mirendil も、Google Cloud の AI Hypercomputer を採用することを発表しました。具体的には、Google の TPU AI アクセラレータと、Google Cloud 上で稼働するフルスタックの NVIDIA AI インフラストラクチャを併用し、この専用設計の AI インフラストラクチャによって Mirendil のモデル事前トレーニングと事後トレーニングのアプリケーションをサポートします。

Mirendil チームは、AI の研究開発を加速し、民主化するのに役立つ新しい AI システムを構築しています。これはつまり、初期モデルの事前トレーニングから事後トレーニングまで、複雑なエンドツーエンドのトレーニングワークフローを管理し、大規模な強化学習をサポートすることを意味します。Google Cloud を通じて TPU と、NVIDIA のフルスタックアクセラレーテッドコンピューティングプラットフォームの両方を自在に組み合わせることで、Mirendil は不可欠なコンピューティングに非常に迅速にアクセスし、状況の変化に合わせてワークロードを最適なアーキテクチャに適合させ続けることが可能になっています。

Google は Mirendil と緊密に連携して、コンピューティング、ストレージ、ネットワーク、コントロールプレーンの各層にわたって、TPU と NVIDIA AI インフラを統合した環境の設計からデプロイまでをエンドツーエンドで実施しました。また、Gemini Enterprise Agent Platform で実行されるマネージドトレーニングクラスタを使用するシステム構築でも協力し、Mirendil における TPU と GPU 両環境のプロビジョニングと管理を大幅に効率化しました。Mirendil はすでに TPU v5P チップのクラスタでの運用を開始しており、NVIDIA AI アクセラレーテッドコンピューティングシステムも近日中に稼働を開始する予定です。

Mirendil の共同創業者 / CEO である Behnam Neyshabur 氏は、次のように述べています。「AI の進歩は、実験の設計、結果の評価、反復という研究ループを人間がどれだけ速く実行できるかによって制限されてきました。私たちは、そのループ自体を加速させ、改善することができる AI システムを構築しています。Google Cloud を基盤として拡張することで、システムをさらに進化させ、最先端の AI 研究機能をより多くの科学者やエンジニアの手に届けるためのスケールと柔軟性が得られます。これにより、研究ループをより迅速かつ大規模に回すことが可能になります。」

Google と Mirendil のパートナーシップについて詳しくは、Mirendil のブログをご覧ください。

- Google、グローバルスタートアップおよび投資家エコシステム担当バイスプレジデント、Darren Mowry

JBサービス: Google Threat Intelligence で、さらに効率的で高精度、プロアクティブなセキュリティサービスを提供

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

JBサービス株式会社（以下、JBサービス）は、SOC（Security Operations Center）の運用を通じて、企業のセキュリティ監視サービスを 24 時間 365 日体制で提供しています。近年は SOAR（Security Orchestration, Automation and Response）で、セキュリティ対策の自動化や効率化を推進。さらに Google Threat Intelligence を導入し、SOAR に組み込むことで、セキュリティの脅威をプロアクティブに阻止できる体制を実現しています。Google Threat Intelligence 導入の背景や効果、新たな顧客向けサービスへの展開について、導入プロジェクトを主導した 3 人の担当者にうかがいました。

利用しているサービス:
Google Threat Intelligence

圧倒的な情報量と利便性を評価し、Google Threat Intelligence を導入

JBサービスは、さまざまな企業の DX 推進を支援する JBCCホールディングスの事業子会社として、2007 年に設立。2015 年からセキュリティ事業を展開し、運用センター SMAC（Solution Management and Access Center）を中心とする SOC サービスを通じて、高い評価を得てきました。上級執行役員でセキュリティ事業部事業部長の平田直樹氏は、同社の持ち味を次のように説明します。

「運用センター SMAC は、SOC とヘルプデスクが同一拠点で連携する独自の運用体制を強みに、アラート検知からユーザー対応、改善提案までをワンストップで提供しています。さらに、既存の SOC で培った知見を基盤に、AI セキュリティ領域へとサービスを拡張し、監視・対応・改善を一体化した次世代 SOC の実現に取り組んでいます。」

同社は SOC 業務に約 80 名、セキュリティ事業部全体では約 200 名のスタッフを擁し、きめ細かなサービスを展開してきました。その鍵となっていたのが、SOAR と各ベンダーから提供される脅威情報を連携させたオペレーションです。しかし、平田氏はさらなる安心・安全の確保のために、次の目標を見据えていたと振り返ります。

「そこで注目したのが、Google Threat Intelligence です。Google Threat Intelligence には、弊社のエンジニアたちが以前から見てきた VirusTotal や、定評ある Mandiant の知見、Google Cloud が持つ膨大なデータまで統合されています。特に、単なる脅威情報の収集にとどまらず、世界規模で観測されている攻撃情報や攻撃者の動向を一元的に把握できる点に大きな魅力を感じました。従来は複数の情報ソースを横断して確認していた分析業務も、Google Threat Intelligence を活用することで効率化でき、アナリストがより高度な調査やお客様への提案に時間を割けるようになることが期待できます。」

第一サイバーセキュリティ部部長で、エンドポイントにおける運用チームのマネージャーを務める鈴木祐介氏によれば、インターフェースのわかりやすさや日常業務での使いやすさ、顧客対応の迅速化が期待できる点も、Google Threat Intelligence への評価を高めました。

「Google Threat Intelligence のインターフェースは、VirusTotal の延長線上のような感覚で、エンジニアにとって非常にわかりやすいものでした。しかも Google Threat Intelligence では、IOC（Indicator of Compromise：攻撃や侵害の痕跡を示す指標）も充実しています。評価の際にはアドバンスドライセンスを利用し、攻撃者情報と攻撃手法を関連付けた情報まで参照できました。Google Threat Intelligence で得られる高品質な脅威情報を SOAR に取り込み、自動分析や相関分析に活用することで、アナリストが対応すべきアラートを効率的に絞り込めるようになりました。」

従来は検出できなかった脅威を可視化し、プロアクティブな防御を展開

JBサービスでは、2025 年 3 月から約 2 か月間、PoC（Proof of Concept: 概念実証）を実施したうえで、Google Threat Intelligence の採用を決定。直後に実装へと移り、SOC サービスの効率化や精度向上、既存システムとの API 連携などの検証を自社グループ内で重ねてきました。ネットワーク運用チームのマネージャーを務める第二サイバーセキュリティ部部長の吉永臣作氏は、技術的なポイントをこう説明します。

「もともと弊社では SOAR を活用してセキュリティ運用の自動化を進めていましたが、Google Threat Intelligence の豊富な脅威インテリジェンスを既存の運用に組み込むことは、新たな取り組みでした。導入にあたっては、API を通じて取得できる情報の精度や有用性を検証しながら、Google Threat Intelligence の情報を SOAR へ連携する仕組みを構築し、脅威情報の収集や分析の自動化を実現しました。また、既存のセキュリティ製品が提供する脅威情報との重複を避け、それぞれの強みを生かせる形で運用を設計することも重要なテーマでした。Google Cloud には検証段階から伴走支援いただき、課題を一つひとつ解決しながら、円滑に本番運用へ移行することができました。」

PoC および導入の過程における Google Cloud のサポートは、平田氏も高く評価していました。

「検討段階から Google Cloud のオフィスで丁寧な説明を受け、エンジニアの皆様にも継続的なサポートをいただきました。導入時には細かな確認や調整を重ねる必要がありましたが、その支援のおかげで、PoC から実装、運用開始までを安心してスムーズに進めることができました。」

2025 年 6 月から約 1 年間かけて行われた社内運用では、確かな手応えも得られています。

「特に大きな効果を感じているのは、膨大な EDR（Endpoint Detection and Response）ログに埋もれた脅威を迅速に特定できるようになったことです。従来は多くのログを分析しながら脅威の有無を見極める必要がありましたが、Google Threat Intelligence を活用することで、優先的に対応すべきリスクを効率的に抽出できるようになりました。また、豊富な IOC を活用することで、インシデントが発生する前の兆候を把握し、お客様に対して先回りした対策や提案を行うなど、よりプロアクティブなサービスの提供を実現しています。」（鈴木氏）

「業務の自動化と最適化を進めた結果、アナリストの負荷増加を抑えながら運用効率を高めることができました。また、Google Threat Intelligence が提供する豊富な脅威情報と分析結果を活用することで、検知精度の向上と対応品質の標準化も実現しています。セキュリティ分析は担当者の知識や経験に依存しやすい領域ですが、経験値の差による判断のばらつきを抑え、より迅速かつ一貫性の高い分析が可能になりました。その結果、お客様へ提供するサービス品質の向上と、より高い安心・安全の実現につながると考えています。」（平田氏）

1 年間の運用で得られた成果を基盤に、新たな SOC サービスの提供を開始

実際の作業を通して、機能性や信頼性の高さを改めて確信した同社は、2026 年 7 月、新たな SOC サービスの提供を開始しました。これは Google Threat Intelligence と SOAR を組み合わせて監視・分析・対応の高度化を実現したもので、既存のセキュリティサービスに追加して利用できるようになっています。

平田氏は「高度な脅威インテリジェンスを自社で個別に運用することが難しいお客様でも、JBサービスの SOC サービスを通じて、最新の脅威情報を活用した監視・分析・対応を受けられる点が大きなメリットです」と語ります。

新たなサービスは段階的な提供が計画されています。第 1 弾では、エンドポイントのセキュリティを強化し、その後ファイアウォールやクラウドへも対象を広げていく予定です。顧客に寄り添った独自のサービスをさらに強化し、より高い安心・安全を提供するため、平田氏はダークウェブを対象とするデジタルスレットモニタリングや、生成 AI の活用も視野に入れていました。

「セキュリティを担保する重要性は、ますます高まっています。最近は生成 AI の技術が悪用されるケースも増えていますが、こちらも Google Threat Intelligence と Gemini をさらに活用することで、緻密なセキュリティ保護が提供できるようになるでしょう。もちろん、セキュリティ管理の分野では誤検知をゼロにはできませんし、最終的には、長年培われてきた人間のノウハウや経験値が重要になってきます。弊社のスタッフにも、より高度な、人にしかできない分析に注力してもらいたい。そのためにも Google Threat Intelligence で、運用の効率化や自動化を追求していく予定です。」

JBサービス株式会社
企業の DX 推進を支援する IT 企業、JBCCホールディングスの事業子会社として、現在の JBCC株式会社（旧・日本ビジネスコンピューター株式会社）の会社分割により設立され、2015 年からセキュリティ事業を展開。企業の IT システム運用や情報セキュリティ対策、機器の保守、ヘルプデスク業務に加え、BPO および AI 運用を含むサービスなどを 24 時間 365 日、一元的に代行・支援する。巧妙化するサイバー攻撃への対応、IT 人材不足などの課題を抱える企業に対し、包括的なサポートを提供している。

インタビュイー（写真左から）
・セキュリティ事業部セキュリティサービス本部第二サイバーセキュリティ部部長　吉永臣作氏
・セキュリティ事業部上級執行役員事業部長　平田直樹氏
・セキュリティ事業部セキュリティサービス本部第一サイバーセキュリティ部部長　鈴木祐介氏

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

金融サービスにおけるエージェント型 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

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 氏

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

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 氏

API 対応エコシステムでアジリティを獲得した Deutsche Bank の手法

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

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

銀行のデジタルトランスフォーメーションというと、モバイルアプリや新しいデジタルサービスといった、目に見える結果に目を奪われがちです。しかし、これらのサービスすべてを実現している、目に見えないインフラストラクチャが存在します。それが API です。Deutsche Bank では、API を単なる技術的な「配管」ではなく、現代の銀行業務の「神経系」であると認識していました。

数年前、当行のアプリケーション環境はモノリシックシステムが主流でした。これらをモジュール式の再利用可能な API に分割する方法を評価する中で、明らかになった点が 1 つあります。それは、単に業務を API に分解するだけでは不十分で、これから生じるものを管理するための一元的な API 管理プラットフォーム（APIM）が必要であるということです。ドキュメント、セキュリティポリシー、ガバナンスが、後付けではなく最初から組み込まれているプラットフォームが必要でした。

問題は、モダナイズの方法だけではありませんでした。特に技術面で新たなパラダイムシフトが発生している中で、お客様に最適なサービスを提供し、将来の機会に備える方法が重要でした。

現代の銀行業務の需要に対応できる適応性、スケーラビリティ、信頼性、安全性、AI 対応能力を備えたシステムを必要としていた当行は、APIM プラットフォームとして Google Cloud の Apigee を選択しました。

バックボーンの構築: 4 つの主要な機能

現在、フィンテックパートナーと当行をつなぐオープンバンキング API から、さまざまなバンキングプラットフォームを支える社内マイクロサービス、オンラインバンキングなどのシームレスなデジタルエクスペリエンスを可能にするクライアント向けアプリケーションまで、当行の API エコシステムを Apigee が管理しています。

このプラットフォームが提供する 4 つの重要な機能は次のとおりです。

1. スピードを犠牲にしない統合ガバナンス

Apigee は、当行の API カタログの基盤です。すべてのエンドポイント、バージョン、依存関係が文書化され、検出可能な状態になっています。開発チームは、機能を再構築するのではなく、既存の API を探して再利用しています。数日をかけて顧客データ API を探し回る環境から、どの開発者でもアクセスできる検索可能なリアルタイムカタログに移行しました。

しかし、ガバナンスは本来、ボトルネックとなるものではなく、ガードレールの役割を果たすものです。当行では、Apigee のポリシーフレームワークを使用して、標準を自動的に適用しています。現在では、OpenAPI 仕様、スキーマ検証、エラー処理がプラットフォームに組み込まれています。一貫したフレームワーク内で作業できるため、チームの作業が迅速化しました。

2. セキュリティ: 従業員のオンボーディングとの類似性

API のセキュリティについて、新入社員のオンボーディングにたとえて考えてみましょう。新入社員に、初日からすべてのシステムに対するアクセス権を付与することはないでしょう。最小権限の原則に従い、その役割に必要な権限のみを付与します。異動した場合は、アクセス権が更新されます。退職した場合は、アクセス権が直ちに取り消されます。Apigee は、サービスやアプリケーションについて同様に機能します。

たとえば、顧客アカウントにアクセスする新しいサービスに接続する場合、いきなりすべてを許可することはありません。OAuth2 スコープと API キー管理を通じて、次のようにエージェントがアクセスできるものを細かく定義します。

口座残高の読み取り: 許可する。
電信送金の開始: 許可しない。
90 日間の取引履歴へのアクセス: 許可する。
過去のデータ全体: 昇格された権限がある場合のみ。

従業員のアクセス権と同様に、これらの権限は一元管理され、定期的に監査され、即座に取り消すことができます。コンプライアンスを目的に従業員の活動を追跡する場合と同様、Apigee はすべての API 呼び出しをログに記録し、誰が、いつ、どのデータに、どのような理由でアクセスしたのかを確認します。

この点は、大量のデータを処理する自動化システムでは特に重要です。構成が不適切な場合、自動化されたサービスが、休むことなく 1 分間に数千回もの呼び出しを行う可能性があります。レート制限と割り当てを適用することで、問題が発生した場合でも、その影響範囲を抑えることができます。

3. 大規模なレジリエンスとパフォーマンス

銀行業務にダウンタイムはありません。顧客が午前 3 時に残高を確認した場合や、市場の取引活動が急増した場合も、API が即座かつ確実に応答する必要があります。

Apigee のロードバランシングと自動スケーリングにより、こうしたトラフィックが均等に分散されます。ヘルスチェックと回路ブレーカーが、問題のあるサービスを自動的に回避します。また、頻繁にアクセスされるデータについては、Apigee のキャッシュが、バックエンドにアクセスすることなくミリ秒未満の応答を実現します。

4. オブザーバビリティ: すべて測定可能

Apigee を導入する前は、API のパフォーマンスを把握することは、別々の箱からピースを集めてジグソーパズルを組み立てるようなものでした。現在は、リアルタイムのトラフィック、サービス別のエラー率、消費者別の使用状況分析、コンプライアンス指標を示す統合ダッシュボードがあります。この可視性が、運用、パートナーの価値を追跡するプロダクトマネージャー、異常を特定するセキュリティチームの支えとなっています。

Apigee は、API ライフサイクル全体を管理するための中心的な機能スイートを提供する

将来を見据える

当行は、API エコノミーのためにこのインフラストラクチャを構築しました。また、そうすることで、デジタルバンキングの未来に向けた強固な基盤も構築できました。業界の進化に応じて、この API ファーストのアプローチは、次世代のサービスを統合するうえで不可欠になるでしょう。

デジタルバンキングの進化に伴い、リアルタイムで対応、予測、支援できるインテリジェントサービスへの移行が進んでいます。リアルタイムのパターン認識、予測インサイト、AI 搭載アシスタントなどの機能は、日常的なデジタルエクスペリエンスの一部になりつつあり、導入が加速するにつれて、その可視性と影響力が高まっています。これらの機能はそれぞれ API を使用します。そして、超低レイテンシ、高スループットのデータフロー、複数の API にわたる安全なオーケストレーションといった新しい要件が生まれます。

当行は、Apigee で柔軟な API プラットフォームに投資したため、インフラストラクチャを再構築する必要はなく、こうした将来のニーズに合わせてインフラストラクチャを適応させ、最適化していく準備が整っています。

新たな標準: MCP、A2A、そして未来

業界は新たな統合標準を模索しています。Model Context Protocol（MCP）や Google の Agent2Agent（A2A）などのプロトコルは、既存の API インフラストラクチャを基盤としているため、興味深いものです。

Apigee で管理している当行の API では、こうした進化を最適な形で活用できます。たとえば、MCP は OpenAPI 仕様のメリットを享受でき、A2A は OAuth2 フレームワークを活用できます。そして、どちらも当行が構築したガバナンスを基盤にすることができます。

また、最新のワークフローに対応しながらセキュリティ管理を維持するために、新しいタイプのサーバーを Apigee プロキシの背後に配置するといったパターンも検討しています。当行の「常時 API」パターンでは、サービスへのアクセス方法に関係なく、サービスが集中管理のメリットを確実に享受できます。

MCP と A2A は補完関係にあり、MCP はツールとリソースに、A2A はピアコラボレーションに重点を置いている

ビジョン: ユニバーサルインターフェースとしての API

すべての銀行業務機能は最終的に API として公開されるようになるでしょう。これは、API が流行しているからではありません。モバイルアプリ、パートナーフィンテック、分析プラットフォーム、その他の自動エージェントなど、何によって利用される場合でも、最も柔軟かつコンポーズ可能で、管理しやすい機能の共有方法だからです。

Deutsche Bank では、この変化がすでに形になりつつあります。当行のコアプラットフォームを支えるものと同じ API 基盤が、銀行全体でのよりインテリジェントな AI 支援サービスへの進化を可能にしています。この基盤は、これらの機能を実際に活用するために必要な整合性、ガバナンス、スケーラビリティを提供し、新しいインテリジェントサービスが登場したときに、シームレスかつ安全に、エンタープライズ規模で統合できるようにします。

Apigee は、すべてのユースケースに拡張できるガバナンスを提供することで、これを可能にします。重要なのはイノベーションを制御することではなく、安全に実現することです。

学んだ教訓

優れたドキュメントに投資する。セマンティックな要約と明確なスキーマは、単に追加するものではなく、開発者と AI の両方にとって欠かせない基盤です。
セキュリティを従業員のオンボーディングのように扱う。最小権限とロールベースのアクセス権は、API にも同様に適用されます。
オブザーバビリティは競争上の優位性をもたらす。統合された分析により、データに基づく意思決定が可能になります。
今すぐ将来に備える。API 管理インフラストラクチャが高度な統合レイヤになります。
好奇心を持ち続ける。さまざまな新標準を試しましょう。柔軟性が勝利の要因になります。

まとめ

当行は転換点を迎えています。API エコノミーにより、フィンテックとオープンバンキングが実現しました。今では、同じインフラストラクチャが、次のイノベーションのバックボーンとして機能できます。API プラットフォームへの当行の投資は、API をより適切に管理することだけが目的ではありませんでした。次に何が起こっても対応できる基盤を構築することが重要でした。

業界が変化する中でも、当行の準備は万全です。未来は、破壊を伴わずに迅速に行動できる組織のものです。当行の場合、その未来は Apigee によって実現されます。

- Deutsche Bank、API 戦略およびインテグレーション担当、Stefan Mesquita 氏

Spanner Graph で小売商品の検索性能を強化し、データベースのメンテナンス工数半減を達成した Target の取り組み

Thu, 20 Aug 2026 01:10:00 +0000

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

現代の小売環境における買い物客は、高度にパーソナライズされた商品発見体験と、自然で本物らしく、心から役に立つと感じられる会話型アシスタンスを期待しています。今日、優れた商品検索には、商品、カテゴリ、顧客の意図の密接な関係やセマンティックな意味を理解することが求められます。キーワードや基本的なブラウジングだけでは不十分です。

Target でこの作業を担当しているのがゲストプロダクトコンフィデンスプラットフォームチームです。評価、レビュー、AI を活用したデジタルショッピングアシスタントなど、信頼を確立し、購入の意思決定を導く機能を構築する責任を担っています。その好例が、2025 年のホリデーシーズンにオンラインストアと Target アプリにリリースされた Gift Finder チャットエージェントです。このエージェントは、親しみやすい会話を通じて、買い物客がぴったりの商品を見つけるのをサポートします。

このようなリアルタイムのパーソナライズとコンテキストリッチなセマンティック応答をグローバル規模で提供するには、断片化されたデータエコシステムを脱却し、統合型のデータプラットフォームに移行するという重要なアーキテクチャ上の課題があることがわかりました。当社は、高スループットのトランザクションワークロード、高度に接続されたグラフ関係、ベクトル類似度検索、全文キーワード検索をまとめてサポートできるソリューションを必要としていました。

この投稿では、これら 4 つのすべてを実現するうえで Spanner が果たした役割について説明します。

断片化されたアーキテクチャからの脱却

従来の Target のディスカバリーデータエコシステムは、検索と転置インデックス用の Elasticsearch クラスタと、トランザクションデータ用の個別の NoSQL データストアの組み合わせで構成されていました。この断片化されたアーキテクチャは機能はするものの、運用上および技術上の大きな課題を抱えていました。

コンテキストの分断: 検索、ベクトル、トランザクションの各データベースの完全同期は常に課題でした。情報がサイロ化されていることで、コンテキストの欠落、属性間の関係の断絶、クエリ結果の不整合が発生していました。
運用上のオーバーヘッドの増大: 独立したクラスタの管理、検索インデックスのチューニング、複雑なカスタム同期と集計ロジックの処理を実行するには、エンジニアリングチームによる集中的な手動介入が必要でした。
拡張のボトルネック: 小売データドメインを拡張するには、新しいデータベースコレクションの追加、複雑な結合の維持、検出システムとコアトランザクションシステムにおける弱いトランザクション保証への対処が必要でした。
サイロ化されたインテリジェンス: グラフの関係、ベクトル類似度、キーワード検索インデックスを 1 件のトランザクションでクエリする機能が欠如していました。

AI を活用した次世代のゲストエクスペリエンスを構築するには、1 つのプラットフォームに統合する必要がありました。

Spanner Graph でエンタープライズオントロジーを構築

スタンドアロンのベクトルデータベースやニッチなグラフデータベースなど、複数の専用テクノロジーを評価しました。しかし、単一目的のデータベースを追加すると、運用の複雑さとデータ同期パイプラインのパフォーマンスが悪化するだけでした。

最終的に選択した方法が、Spanner Graph を利用してエンタープライズオントロジーを構築することでした。これは「グラフのグラフ」パラダイムであり、生成 AI を活用した大規模なショッピンググラフの構築を可能にします。

データを統合することで、セマンティックデータ、グラフ関係、ベクトルエンベディング、運用トランザクションを 1 つの屋根の下に集約します。これにより、トランザクションの状態とセマンティックインテリジェンスの両方について、Spanner が信頼できる唯一の情報源となります。

当社のハイレベルなアーキテクチャは、以下の 3 つの主要な柱で構成されています。

1. エンタープライズ拡張このレイヤは、当社のエンタープライズ小売カタログをキャプチャし、複数のバックエンドソースから関連するメタデータを集約し、エージェントによるデータ拡充に生成 AI を活用して、取り込む商品データの品質と深さを大幅に向上させます。

2. グラフ、ベクトル、検索の統合ストアSpanner Graph では、複数のデータベース間でデータを移動させるのではなく、エンティティノード、関係エッジ、ベクトルエンベディングを同じデータベースエンジンに保存します。Spanner Graph は、リレーショナルテーブルに対するマルチホップグラフ探索、セマンティックベクトル類似検索、全文キーワードクエリをネイティブにサポートしています。このマルチモデルシナジーはネイティブであるため、脆弱な外部同期パイプラインを介さずに分散ワークロード全体で厳格な ACID トランザクションを実現し、絶対的な正確性を確保できます。

3. オーケストレーションと AI レイヤこのレイヤは、会話型ゲストインターフェースを強化し、Spanner Graph から直接供給される豊富な構造化コンテキストを利用して LLM をグラウンディングします。責任ある AI プロセスを管理し、生成された出力を評価しながら、非常に具体的な商品関係を抽出することで Gift Finder などのツールを強化します。

ダウンタイムなしでスムーズに段階的に移行

当社の検索と見つけやすさのインフラストラクチャは何百万人もの顧客が利用する重要なものであるため、移行にあたってはダウンタイムをゼロにする慎重なアプローチが必要でした。この移行は、4 つの構造化されたフェーズで実行されました。

スキーマとオントロジーのマッピング: Spanner Graph スキーマ内で、商品、カテゴリ、ブランド、顧客の好みなどの特定の小売エンティティと、それらに対応する関係を定義しました。
データ統合と並列リプレイ: ミューテーションベースのデータ統合を並列パイプラインで構築しました。これにより、リアルタイムのトランザクションの更新を継続的にリプレイし、スキーマ変換を適用して、エンベディングを生成し、リアルタイムで Spanner Graph に直接書き込むことができました。
カナリアデプロイ: ライブの読み取りトラフィックを新しい Spanner Graph ベースのプラットフォームに徐々に移行し、実際の小売ワークロードでクエリのパフォーマンス、セマンティックの精度、データベースの安定性を検証しました。
カットオーバーとクリーンアップ: パフォーマンスを徹底的に検証した後、すべての検索と見つけやすさのトラフィックを Spanner に完全に移行し、以前の Elasticsearch スタックを廃止することで、Elasticsearch クラスタのメンテナンスの負担を完全に排除しました。

ビジネスへの影響

Spanner Graph 上で直接構築することで、技術面とビジネス面で測定可能な成果を達成できました。

究極の GraphRAG 基盤: 従来の RAG はフラットなベクトル類似度に依存しているため、たとえば特定のおもちゃと互換性のあるアクセサリーや年齢適合性の照合など、商品間の構造化された関連性を見落としがちです。統合された GraphRAG アーキテクチャ内で深いグラフ探索とセマンティックベクトル検索を組み合わせることで、LLM を高精度のコンテキストでグラウンディングしました。これにはおすすめの関連性を直接改善する効果があり、顧客の満足度とネットプロモータースコアの向上につながりました。

SQL と GQL の相互運用性の統合: Spanner Graph を使用すると、デベロッパーは標準 SQL と GQL（Graph Query Language）を使用して、1 回のクエリで構造化されたリレーショナルカタログデータと接続されたグラフ関係に対して処理を要求できます。これにより、これらのパラダイムを橋渡しするためのデータの重複、レイテンシ、複雑な ETL パイプラインが不要になります。

成長の上限がないサーバーレスのスケーラビリティ: Spanner は、ブラックフライデーやサイバーマンデーなどの小売イベントのピーク時に、予測不可能な大規模なトラフィックの急増を自動的に処理します。Spanner に組み込まれたオートスケーラーがコンピューティング容量を動的に調整し、期間限定のプロモーション特典期間中に発生した高負荷のバーストトラフィックを、パフォーマンスを犠牲にすることなく処理しました。

インフラストラクチャのメンテナンス工数の半減: トランザクション NoSQL データベースと検索インデックスデータベースを 1 つのマネージド Google Cloud サービスに統合することで、別々のデータベースクラスタを維持する運用上の負担がなくなりました。開発者がデータベース管理とインフラストラクチャの維持に費やす時間が 50% 削減され、顧客向けの新しい AI 機能をより迅速に構築してデプロイできるようになりました。

Spanner Graph への移行により、当社の生成 AI ロードマップは加速しました。これは、適切なデータ基盤の構築が提供する価値を証明する究極の例となりました。

AI アプリの強化を目指しているのであれば、まずは、適切なグラフ機能を備えたデータベースを事実上無制限の規模で利用することから始めましょう。Spanner Graph で組織のデータをアクションに変える方法をご確認ください。

- プリンシパルエンジニア Sayanti Dey

- Target 社シニアエンジニアリングマネージャー Kaushik Shelat 氏

Best Buy、Workforce Identity 連携で AI ワークロードをスケールし、アクセスを保護

Fri, 07 Aug 2026 02:30:00 +0000

Best Buy のテクノロジーチームは、同社が高度な分析や AI のために Google Cloud の利用を拡大するなかで、スケーリングに関する 2 つの大きな課題に直面しました。それは、Microsoft Entra ID から数千人のバックエンドユーザーを同期する際のリスクの軽減と、管理の煩雑さへの対処です。

この小売業者は、Google Cloud の Workforce Identity 連携を実装することで、両方の問題を解決し、大規模なクラウド拡張への道を開きました。この直接的なアプローチにより、デベロッパーは別の ID ストアを用意することなく、既存の Microsoft 認証情報でクラウドリソースにセキュアにアクセスできるようになりました。これにより、技術部門のリーダーは、アクセスが厳密に制御され、監査可能で、大規模な管理が可能であるという確信を持つことができました。

サービスアカウントを直接連携に置き換える

Best Buy はこれまで、バックエンドユーザーを Entra ID から Google Cloud にコピーするために、複雑な同期パイプラインを維持していました。Google Workspace をデプロイせずに Cloud Identity を使用していたため、より直接的なアプローチが必要でした。以前は、Best Buy における Power BI と BigQuery の連携は、サービスアカウントの認証情報に依存していました。

このパターンは小規模なチームでは機能しますが、チームが拡大するにつれて、いつの間にか負債になっていきます。

サービスアカウントのキーを手動でローテーションするということは、各チームが保持する認証情報を追跡し、すべてのキーが潜在的なセキュリティの脆弱性であることを受け入れることを意味していました。サービスアカウントキーは、Best Buy のセキュリティチームとプラットフォームチームにとって日々の運用の妨げとなっていました。また、データアクセス要件が複雑化するにつれて、技術的負債も蓄積していきました。

数万人のユーザーをサポートするために、Best Buy は ID アーキテクチャをモダナイズしました。チームは、Workforce Identity 連携を採用して、既存の Entra ID の ID を Google Cloud に直接連携しました。

現在、デベロッパーが Power BI を通じて BigQuery にアクセスする際は、既存の Entra ID の ID を使用して本人認証を行います。キーのローテーション、チャットメッセージで認証情報が公開されることの心配、監査ログで誰がアクションを実行したかの推測をする必要はもうありません。

このアーキテクチャは、2 つのコンポーネントが連携して動作します。Entra ID が認証を処理し、Workforce Identity 連携が Entra ID と Google Cloud 間の信頼関係を仲介します。この連携は Google 側ではステートレスです。ユーザーレコードを同期するのではなく、アクセスの時点でトークンを検証します。サービスアカウントキーのレイヤを削除することで、認証情報管理の負担が大幅に軽減されます。

アーキテクチャ

下の図は、Entra ID から Workforce Identity 連携を介して、Best Buy でチームが使用するサービスにどのように ID が流れるかを示しています。以前のアプローチからの主な変更点は、サービスアカウントキーのレイヤが完全に削除されたことです。Entra ID と Google Cloud の間で管理する認証情報はありません。

ID は Entra ID から Workforce Identity 連携を介して、Best Buy のチームが使用するサービスに流れる

実装に関する主な決定事項

このアーキテクチャを実装するにあたり、Best Buy はいくつかの重要な技術的選択を行いました。

Entra ID でプロビジョニングアプリと SSO アプリを分離する: 構成は、Entra ID のプロビジョニングとシングルサインオン（SSO）の設定ガイドに沿っています。Entra ID でプロビジョニングアプリケーションと SSO アプリケーションを分離する必要があります。2 つの異なるエンタープライズアプリとして実行すると、関心の分離がより明確になります。プロビジョニングの変更が SSO 構成に影響を与えることはなく、その逆も同様です。
Automation OU を慎重に配置する: Entra ID プロビジョニングサービスアカウントを別の組織部門（OU）に配置し、その組織部門の SSO を明示的に無効にする必要があります。これにより、ブートストラップの問題（SSO をグローバルに適用すると、プロビジョニングアカウントが認証を行えず、そもそもプロビジョニングの設定ができなくなる）を回避できます。
同期不要とは、Google 側がステートレスであることを理解する: Workforce Identity 連携では、Cloud Identity にユーザーレコードを作成または保持することはありません。アクセスの時点でトークンを検証します。これにより、同期の遅延、古いレコードのクリーンアップ、個別のプロビジョニングパイプラインが不要になるため、Best Buy の目標規模に合ったアーキテクチャが実現します。

デベロッパー向けのセキュアな認証

デベロッパーにとって、この変更は実質的に意識されることはありませんでした。社内の Entra ID 認証情報で一度認証するだけで、Power BI を使用する場合でも、API を直接呼び出す場合でも、BigQuery に自動的にアクセスできます。SSO のエクスペリエンスは、Microsoft ID を使用してアクセスする他のすべてのものと一致します。

セキュリティチームとプラットフォームチームにとって、そのメリットは非常に大きいものです。認証情報管理による攻撃対象領域が消滅します。監査ログには、共有サービスアカウント ID ではなく個々のユーザーが表示されるようになり、手動での鍵のローテーションを待つのではなく、企業の ID ライフサイクルに基づいてアクセスを迅速に取り消すことができます。

現在、デベロッパーの Google Cloud アクセスをサービスアカウントキーで管理しているなら、Workforce Identity 連携への移行を検討する価値は十分にあります。セキュリティ上の大きなメリットが得られ、チームが拡大するにつれて運用が簡素化されます。Best Buy は現在、将来の小売業務を強化するために、このセキュアなアクセスをより幅広い従業員に拡大しています。

Workforce Identity 連携のサポートを拡大

Google Cloud は、あらゆる組織が独自の ID プロバイダを簡単に導入できるように、継続的に取り組んでいます。最近のアップデートにより、Ping Identity ユーザーの設定が簡素化され、オンライン請求先アカウントへのアクセスが拡張されました。

Ping Identity のインテグレーション: Ping Identity を使用している場合は、新しい専用のセットアップガイドに沿って連携を構成できます。このガイドでは、従業員を Google Cloud リソースにセキュアに接続するための手順を説明します。
オンライン請求サポート: Google Cloud は、オンライン請求先アカウントをお持ちのお客様をサポートします。Workforce Identity 連携を使用すると、企業請求契約を結ぶことなく、セキュアで同期不要のアクセスが可能になります。

使ってみる

Google Cloud は、クラウド導入の障壁を取り除き、組織が環境をより簡単に保護できるように取り組んでいます。これらの新機能を試し、組織の ID プロバイダを接続するには、Workforce Identity 連携で ID を直接連携させる方法の詳細を確認し、サポートされている Google Cloud サービスをご覧ください。

- Best Buy、クラウドエンジニアリング担当シニアマネージャー、Kishor Patil 氏

- Google Cloud Security、シニアプロダクトマネージャー、Stephen Cakebread

The Blueprint: Voicify が AI を活用した注文体験を顧客にとって満足度の高いものに

Thu, 06 Aug 2026 02:10:00 +0000

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

「The Blueprint」へようこそ。今回始まったこの特集では、最新の AI とクラウドテクノロジーを使用して業界共通の課題や個別の課題に対処する Google Cloud のお客様の取り組みをご紹介します。仕事でイノベーションを目指す皆さまの着想の一助になれば幸いです。

2018 年に設立された Voicify は、すべての通話をシームレスで魅力的な体験に変えることを目標として、従来の電話の概念を一変させています。

課題:

2018 年に Voicify を創業したとき、当社のビジョンは、組織が、電話やチャットなどのあらゆるチャネルで、信頼性が高く、実用的で、技術的な基盤に基づく音声駆動型アシスタントを構築できるよう支援することでした。しかし、パンデミックによってすべてが変わりました。

当社は、主に飲食業界と医療業界の電話のユースケースに焦点を移しました。これらの業界では当時、通話量と人員配置が大きな課題となっていました。飲食店では、電話の最大 20% に応答できず、その結果注文を失う可能性がありました。また、医療機関では、予約情報を診療管理システムに統合する際に、情報の精度を 100% 維持しながら多くの通話に対応するのに苦労していました。その際、専門的な目的別 AI アシスタントが、企業が優れたサービスを大規模に維持するための鍵であることに気づきました。

成功を収めるには、4 つの主要な課題を克服する必要がありました。

トランザクションの精度: 音声アシスタントは、POS システムや診療管理システムに対する複雑な顧客リクエストを 100% の精度で推論する必要がありました。
トラフィックの急増への対応: 飲食店や医療機関では（極端な）トラフィックの急増がよく見られますが、費用を抑え、カスタマーサービスを維持するには、LLM の使用量を正確にプロビジョニングする必要があります。
レイテンシ: アシスタントの応答が遅れると、顧客が電話を切ってしまう可能性があります。ユーザーが音声またはテキストのリクエストを送信してから、AI モデルが最初の出力を生成するまでの遅延を最小限に抑え、最初のトークンまでの時間を極めて短くする必要がありました。
セキュリティとコンプライアンス: 2018 年の創業以来、当社は HIPAA、SOC2、ISO27001、PCI に準拠し、エンタープライズグレードのセキュリティを確保しています。データの完全性とセキュリティを保護するために、可能な限りの安全保護対策を採用したアーキテクチャとインフラストラクチャが必要でした。

ソリューション:

当社の会話型オーケストレーションプラットフォームは、飲食店の注文を送信する前に、POS システムと照合して構築および検証し、正確性を確保します。そのプラットフォームの内部では、Gemini Enterprise Agent Platform を介して提供される Gemini Flash が、レイテンシを大幅に短縮し、ユーザーの待ち時間を最小限に抑え、ユーザーが電話を切るのを防ぎます。それにより、以前に使用していた他の LLM と比較して、約 25%～30% の費用削減と、信頼性向上も実現しました。

ビジネスの成長、通話量の増加、そしてトラフィックの急増に対応するために、Google AI Studio から Vertex AI（現在は Gemini Enterprise）に切り替えました。後者が提供するエンタープライズ向けの保証は、医療機関のお客様のセキュリティとコンプライアンスだけでなく、スケーリングにも必要でした。Gemini Enterprise Agent Platform の特定の機能により、サービスの中断や、応答できない状況が発生することなく、大量の通話に対応できます。

これらのエンタープライズグレードのサービスは、AI Studio よりも費用がかかる可能性がありますが、信頼できる稼働時間を確保するうえで価値は十分にあります。また、従量課金制のプレミアム機能により、スケーリングがはるかに簡単になりました。たとえば、感謝祭の前日に過去最高の使用量に対応するために、Vertex AI でプロビジョンドスループットと従量課金制のプレミアム機能を組み合わせて使用したところ、レート制限の問題は発生しませんでした。

アーキテクチャ:

結果:

Gemini により、コンテキストの取得とメニューの作成を行う社内プログラマティックツールの負担が軽減されました。Gemini を使用することで、レイテンシが短縮され、信頼性が向上するなど、パフォーマンスと信頼性が大幅に向上しました。また、Gemini を活用したアシスタントの安定性が向上したことで、お客様のオンボーディングがはるかに効率的になりました。飲食店が POS システムにアクセスできるようになってからテストの準備が整うまでの期間は、以前は 1～2 週間でしたが、現在はわずか 1～2 日になりました。

スケーリングとエンタープライズグレードのサービスを実現する Google のソリューションにより、重要な指標である最初のトークンまでの時間を最適化し、お客様の待ち時間を最小限に抑えることができました。Vertex AI のプロビジョンドスループットと従量課金制の機能を使用することで、過去最高の使用量となった期間でも、100% の稼働率を確保し、応答できない状況やレート制限の問題を回避できました。今では、飲食店のトラフィックの急増に簡単に対応できるようになりました。

技術面では、会話型の注文取得から、会話や POS アクティビティのコンテキストを使用したよりプロアクティブな支援へと移行することを見込んでいます。たとえば、金曜日の夜に、いつものようにお気に入りの日本料理店に注文する際には、近い将来、Voicify の音声アシスタントがプロアクティブに注文してくれるようになるかもしれません。

詳細:

当社が注力している業界には、バックエンド内で時間をかけて解決しなければならない独自の課題がいくつかあります。

Voicify ソリューションの中核となるコンポーネントは、音声オーケストレーションプラットフォームです。これは、電話 AI スタック全体を管理し、エンタープライズグレードのスケーラビリティとセキュリティを実現するように設計されています。また、ユーザーのニーズに応じて業界ソリューションが呼び出されるノードでもあります。当社の音声オーケストレーションプラットフォームは、お客様の近くに配置され、Gemini や音声アシスタントのさまざまなコンポーネントなどのバックエンドサービスを調整します。このプラットフォームは、純粋な生成ではなく、プログラム上の要素を含む、自動音声認識、テキスト読み上げ、テキスト生成などの機能を管理するために使用します。

アーキテクチャについて当社が下した独自の決定の一つは、複雑で膨大な飲食店のメニューを管理する方法でした。メニュー全体を 1 つのプロンプトに含めることは避け、最初のプロンプトには特定の情報のみを含め、会話が進むにつれて詳細情報を収集することにしました。これにより、応答時間が短縮され、特定のやり取りで各メニューの関連部分のみに焦点を当てることで、大規模な注文の複雑さを管理できます。

また、当社は創業当初から、特に医療分野において、セキュリティとコンプライアンスに関する企業のお客様の高い基準を満たすようにアーキテクチャを設計しました。エンタープライズグレードのスケーラビリティも保証しています。アーキテクチャの面でも、データの完全性と安全性を確保するために、あらゆる安全保護対策を講じています。最後に、可能な限り高いレベルの可用性を実現するための戦略の一環として、当社のプラットフォームはマルチクラウド環境をサポートするように設計されています。

- Voicify、CTO / 共同創業者、Nick Laidlaw 氏

- Voicify、エンジニアリング担当ディレクター、Aadu Pirn 氏

メンテナンスからイノベーションへ: Checkout における Managed Service for Apache Airflow への移行

Wed, 29 Jul 2026 02:00:00 +0000

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

データプラットフォームを構築したデータエンジニアリングチームが、「2 日目」（運用上の現実）に直面することがよくあります。それは、オーケストレーター自体の継続的なメンテナンス作業です。

Checkout.com のデータプラットフォームチームの場合、本来であれば他の作業に費やすことができていた時間を、別のハイパースケーラーでセルフホスト型の Apache Airflow 環境を管理することに費やす必要がありました。サーバー管理、パッチ適用、インシデント対応に気を取られ、パイプラインの構築に集中することができずにいました。

Google Cloud のフルマネージド Airflow サービスである Managed Service for Apache Airflow（第 3 世代）に移行することで、Checkout.com はその信頼性と費用構造を大きく変革しました。今回は、同社がよりスケーラブルで費用効率に優れた、堅牢なデータ基盤を構築した手法をご紹介します。

出発点: セルフマネージド Airflow

移行前、Checkout.com はセルフマネージドインフラストラクチャで Airflow を実行していました。機能には問題がありませんでしたが、基盤となるリソースのメンテナンスには細心の注意が必要でした。パッチ適用、アップグレード、サーバー管理により、定期的にサービスを中断する必要がありました。

過去 1 年間の運用データから、同社が以下のような課題に直面していたことが明らかになっています。

運用面での障害の軽減: セルフマネージド環境にあった Checkout.com は、特に負荷の高い期間に、安定性に関する課題に直面していました。
複雑な依存関係の管理: パッケージのアップグレードと互換性の確保を絶えず手動で行う必要があり、手間がかかっていました。Managed Airflow（第 3 世代）に移行した後は、イメージレベルで依存関係を処理することでこのプロセスを簡素化し、日常的な環境アップグレードの中でシームレスに互換性を確保できるようになりました。
DAG の同期時間: S3 へのデプロイ後、スケジューラへの DAG の同期に約 6 分かかり、イテレーションの速度に影響を与えていました。
手動プロセス: スケーリングには人間による介入が必要で、新しいチームのオンボーディング時には dbt 用のシークレットと変数を手動で作成する必要がありました。

ソリューション: Managed Service for Apache Airflow（第 3 世代）

Checkout.com のチームは、インフラストラクチャに関連する責務を軽減し、Google Cloud のマネージドスケーラビリティを活用するために、Managed Airflow に移行しました。その結果はすぐに表れ、信頼性、費用、開発速度の 3 つの領域で数値で示すことができる成果が上がりました。

動的スケーリングの効果

以前の Elastic Container Service 環境では、ピーク時の負荷に必要な最大数のワーカーを割り当てていました。つまり、実際の使用量に関係なく、常時ピーク時の容量に対応できる料金を支払う必要がありました。

Managed Airflow には動的スケーリング機能が組み込まれているため、リソースを手動で管理する必要がありません。この環境では、ワークロードの具体的な需要に基づいてワーカーの数が自動的に調整されます。システムは、タスクが急増するとスケールアップし、タスクが減少するとスケールダウンしてリソースを節約します。同様に、固定プロビジョニングから動的スケーリングに移行することで、月額費用も推定 30% 削減されました。

信頼性と DAG の分離

Checkout.com による移行の主な目的は、安定性の向上でした。以前は、問題のある DAG が 1 つあるだけで環境全体に影響が及ぶことがあったからです。

Managed Airflow により、アーキテクチャ面での重要な改善点が数多く導入されました。

DAG の分離: 各 DAG は独自の実行環境で実行されます。1 つの DAG が失敗したり、リソースを過剰に消費したりしても、環境全体に影響することはありません。
マネージドオペレーション: Google Cloud がスケジュールに従ってパッチ適用とアップグレードを処理するため、手動でのアップグレード管理が不要になります。
可視性の向上: Google Cloud Monitoring および Cloud Logging とのインテグレーションにより、タスクの実行を明確に可視化できます。エンジニアは、プラットフォームチームに問題をエスカレーションすることなく、個別にデバッグできるようになりました。

デベロッパーワークフローの高速化

この移行により、Checkout.com のデータエンジニアの日常的なワークフローも改善されました。

デプロイの高速化: DAG に Cloud Storage を使用することで、ほぼ瞬時の同期が可能になりました。
オンボーディングの簡素化: チームがオンボーディング前に変数を作成する際に、プラットフォームサポートが不要になりました。
dbt 実行のモダナイズ: 同社の最も大きな成果の一つが、dbt の実行方法の変更です。以前は、サポートされている dbt バージョンごとに、エンジニアが複雑な仮想環境を手動でインストールして管理する必要がありました。Managed Airflow（第 3 世代）は、コンテナ化された dbt 実行を活用することで、依存関係のボトルネックを解消します。これにより依存関係が完全に分離されるため、チームは最小限の設定で、手動によるインフラストラクチャのオーバーヘッドなしに、必要な dbt モデルを実行できます。
環境の更新: 新しいロールを追加したり、Python パッケージを更新したりするために、Airflow 環境全体を再デプロイする必要がなくなりました。
Gemini Cloud Assist による AI を活用したトラブルシューティング: セルフマネージド環境では、タスクが失敗すると、断片化されたログや指標でその原因を必死に探すことがよくありました。Checkout.com は、Managed Airflow を導入したことで、Google Cloud コンソールの Airflow DAG UI から直接 Gemini による調査を開始できるようになりました。

Gemini は一般的なエラーメッセージを提供するだけでなく、裏付けとなる証拠と矛盾する証拠の両方を含む、さまざまな仮説の評価スコアカードを生成します。これにより、平均復旧時間を大幅に短縮できます。

まとめ

Checkout.com にとって、Managed Airflow（第 3 世代）への移行が戦略的転換点となり、エンジニアが価値の提供に集中できる環境を整えることができました。

「Managed Service for Apache Airflow を導入したことで、効率、スケーラビリティ、信頼性が大幅に向上しました。マネージドインフラストラクチャ、自動スケーリング、迅速なデプロイ、分離された実行環境により、業務遂行に変革をもたらすことができました。」- Checkout.com、データプラットフォームエンジニア、Keisi Mancellari 氏

スケーラブルで費用効率に優れた、安定したプラットフォームを導入したことで、Checkout.com は自社のデータパイプラインの将来に集中できるようになりました。今後何が起こっても、自社のオーケストレーションレイヤで対応できると確信しています。

Managed Service for Apache Airflow の詳細と、このソリューションがいかにしてデータプラットフォームをサポートするかをご確認ください。

この投稿にご協力いただいた Serge Bouschet 氏と Keisi Mancellari 氏に心より感謝いたします。

- Managed Airflow、リードプロダクトマネージャー、Piotr Wieczorek

- カスタマーエンジニア、Michelle Liu

損保ジャパン、機械学習モデルの開発を AI エージェントで自動化 ─ 1 週間かかっていた実験サイクルが 1 日に

Mon, 27 Jul 2026 01:00:00 +0000

保険の現場では、代理店やお客様からの「この保険は契約できるのか」「この事故は補償されるのか」といった照会が日々発生します。損害保険ジャパン株式会社（損保ジャパン）は、こうした問い合わせ対応を支援する社員向けツール「おしそん LLM」を提供しています。Chrome の拡張機能から質問を投げると、関連する社内資料を検索して回答に反映する検索拡張生成 (RAG) が裏側で動き、AI がまとめます。

その回答の良し悪しを左右するのが、社内で育てている検索用の機械学習モデルです。ただ、このモデルを改良する作業は工程が複雑で、どの工夫がなぜ効いたのかを言葉で説明しづらく、担当者の経験と勘に頼る、いわゆる属人化した状態でした。損保ジャパンは、このモデル改良の進め方を AI エージェントに進めさせる仕組みをつくり、これまで何日もかけていた試行錯誤を、短いサイクルで回せるようにしています。

今回は、この開発を率いる損害保険ジャパンの眞方様と、チームで実務を担う SOMPO ホールディングスのキム様に、その舞台裏をうかがいました。

実験は回せるのに、良し悪しが見極められない

いちばんの悩みは、実験はたくさん回せるのに、その良し悪しを見極められないことでした。モデルの改良では、何度も試しては結果を確かめます。ところが、その 1 回 1 回が良い実験だったのかを見直す作業が追いつきません。「質のいい実験なのかどうかのレビューはすごく難しい。そこを効率化、自動化できないかというのが出発点でした」と眞方様は振り返ります。実験によっては結果が出るまでに 1 本で 1 週間かかることもあり、数を増やすほど見直しが回らなくなっていました。

そこで眞方様は、この一連の流れを AI エージェントに任せられないかと考えます。「データ分析ができて、計画も立てられる。機械学習の知識も Web 検索で補える。だとしたら、できない要素がないなと思い始めました」。こうして、モデル改良の自動化に踏み出しました。

3 つの役割分担で、EDA から学習・評価までを回す

仕組みは大きく 3 つの部品でできています。

学習プログラムを Gemini Enterprise Agent Platform（以降 Agent Platform）上で動かすML 実行基盤
データの中身を調べる EDA Agent
実験の段取りを考えて回す実験オーケストレータ

EDA（探索的データ分析）とは、いきなりモデルを作りはじめる前に、手元のデータにクセや問題がないかをひと通り点検しておく作業のことです。

中心になるのが、損保ジャパンが内製した EDA Agent です。Agent Development Kit (ADK) で開発し、Agent Platform の Agent Runtime 上で動かしています。経験豊富なデータ分析の担当者が最初に行う点検作業を、まるごと肩代わりします。

BigQuery に取り込んだデータを、エージェントが自分で SQL を書いて点検します。「自動車保険ばかりで火災保険がほとんどない」といった件数の偏り、文章データのノイズ、全角と半角が混じった表記の不統一（Unicode の正規化が必要な箇所）などを確認。さらに BigQuery ML で小さなモデルを試し、どの前処理が効きそうかのあたりもつけます。データが大きいと費用がかさむため、重すぎる処理は事前に見積もって止めます。結果は元データと同じ場所に決まった命名規則で残すので、人もエージェントも後から判断の理由をたどれます。

データの加工の流れは、Knowledge Catalog のデータリネージが自動で記録します。どのデータが、どんな処理を通って、どう変わったのかという来歴を線でつないで地図のように見せる仕組みです。中間データの出どころを後からさかのぼれるので、原因さがしや作り直しがぐっと楽になります。

もう一方の実験オーケストレータは、コードを書いて実験を動かすコーディングエージェントです。自ら方針を立て、EDA Agent の点検結果をふまえて、学習を Agent Platform Pipelines で回し、できあがったモデルの成績を評価します。良ければ本番へ、いまひとつなら EDA Agent に戻ってやり直す、この往復を自動でくり返します。役割を 2 つに分けたのは、あとから経緯をたどれるようにするためです。「コーディングエージェントで全部やることもできますが、それだと、なぜこのデータ分析をしたのかというログが残らない。だから分けています」と眞方様は話します。

1 週間の実験サイクルが 1 日に

効果は、かかる時間にはっきり表れました。データを調べて、学習させて、結果を見直す。この実験のひと回りに、1 週間かかるものもありました。それが、エージェントを使うと 1 日ほどで終わります。キム様も「以前は 1 回の実験サイクルに 3 日以上かかっていましたが、いまは 1 日のうちに何度も試せるようになりました」と語ります。

回せる回数が増えただけではありません。担当者の頭の中にあった判断の理由が、エージェントの記録として残るようになり、属人化もほぐれてきました。これまで手の回らなかった、結果を 1 件ずつ見て確かめるような地道な分析にも取り組めるようになっています。

AI に「作業」を、人に「課題づくり」を

時間が空いたぶん、チームの重心はどこに移ったのでしょうか。眞方様が最も重要だと語るのは、タスクを作ること、データを作ること、課題を見つけることでした。

「ビジネス上の課題を機械学習のタスクに落とし込んで、そのためにデータセットを加工する。ここが一番大変で、まだ AI にはできないところなんです。だから、AI でできないところに注力するよう心がけています」。エージェントが出した定性分析が本当に合っているのか、最終的な判断は人が担います。いまはそのレビューに力を入れているそうです。

人と AI の線引きを、眞方様は自動運転にたとえます。「自動運転の技術ができたとしても、どこにどう行きたいかを決めるのは人です。機械学習も同じで、どういう文脈でどこに使いたいのか、どんなデータセットを作るのかを考えることは、人にしかできない部分だと思います」。キム様も同じ方向を見ています。「AI に任せるのは作業のほうですね。定型的なところは AI に任せて、エンジニアはもう少し上のレイヤー、戦略を考えることに時間を割くべきかなと」

変化の時代に、気軽に試せるチームでいたい

最後に、これからの展望と、同じ挑戦に向かう人たちへのメッセージを聞きました。狙いは、自動化できる領域を広げていくこと。そして、AI エンジニアが意思決定や戦略にフォーカスできる状態を作ることです。

「今のやり方も、半年後には陳腐化している可能性が全然あると思っています。だからこそ、気軽に試していくことが大事なのかなと。うまくいかないことも多いですが、それをチームとして取り組める状態になっていくと、AI 時代を生き抜けるエンジニアになり、強い組織になるんじゃないかな」と眞方様は語ります。

キム様は、人と AI の関わり方をこう締めくくりました。「AI は何でも自動化できそうなんですが、実際はそうでもないんです。やってみると、ここはうまくいかない、人間が必要だ、というところがちゃんと見つかる。人間がそこにフォーカスして価値を出していく。AI に合わせるのではなく、AI と共同して価値を作っていきたいです」

人手では追いつかなかった機械学習の開発に、AI エージェントとの分担で挑む。損保ジャパンの取り組みは、保険の現場の問い合わせ対応という足元の課題から始まり、開発のあり方そのものを変えはじめています。

利用している主なサービス:

Gemini 2.5 Pro / Gemini 2.5 Flash / Gemini 3.5 Flash
Gemini Enterprise Agent Platform（Custom Jobs / Pipelines / Agent Engine）
BigQuery / BigQuery ML
Agent Development Kit (ADK)
Knowledge Catalog（Data Lineage)

SOMPO Digital Lab
https://zenn.dev/p/sompojapan_dx

インタビュイー

損害保険ジャパン株式会社
部署・役職 DX推進部開発推進グループチーフエンジニア
眞方篤史様

SOMPO ホールディングス株式会社
部署・役職デジタル・データ戦略部シニアAIエンジニア／主任
キムヘン様

セガサミーホールディングス: Google Security Operations と Google Threat Intelligence を導入し、セキュリティ対策をグローバルで標準化へ

Fri, 17 Jul 2026 02:00:00 +0000

セガサミーグループはグローバルにビジネスを展開する総合エンタテインメント企業です。そのコーポレート IT を担うセガサミーホールディングス株式会社（以下、セガサミー HD）IT ソリューション本部は、SIEM（Security Information and Event Management）の刷新を機に Google Cloud Security の利用検討を開始し、導入を決定。個別最適で積み上がってきたセキュリティ運用の統合管理へと大きく舵を切りました。本プロジェクトの中核メンバーに、当初の課題から選定の決め手、今後の展望までを伺います。

利用しているサービス:
Google Security Operations, Google Threat Intelligence など

利用しているソリューション:
セキュリティ

"個別最適" がもたらした、セキュリティ管理・運用体制の構造的課題

セガサミーグループは、ゲームコンテンツや映像作品などを手がける「エンタテインメントコンテンツ事業」、パチンコ・パチスロ機器の製造・販売などを行う「遊技機事業」、そしてゲーミング機器の開発や統合型リゾートの運営などを行う「ゲーミング事業」という 3 つの柱を持つ、総合エンタテインメント企業グループです。グループで保有する機密情報は、未発売ゲームタイトルの開発データから遊技機の技術情報、さらにはビジネスのノウハウやユーザー情報まで多岐にわたります。セガサミー HD IT ソリューション本部の宮地雅人氏は、「金融系の情報ではないものの、外部への漏えいは絶対に許されないものばかり」だと前置きし、同社が抱えるセキュリティ管理の課題を次のように説明します。

「当グループでは厳しいセキュリティ要件に対応すべく、各セキュリティ領域において、その時点で最も優れた製品を個別に選定・導入する方針を取ってきました。しかし結果として、機能ごとにコンソールが乱立する状況が生まれ、管理・運用の大きな負担になっていたことは否めません。こうした状況を解消し、セキュリティを統合して管理・運用できる環境に移行したいという気持ちが強まってきたのです。」

加えて、ログ管理の中核を担ってきたオンプレミス型 SIEM の老朽化が進んでいたことも解決すべき課題でした。同社 SOC（Security Operations Center）担当として、サイバー攻撃の検出やログ分析を担ってきた IT ソリューション本部グローバルセキュリティ推進室 IT インフラセキュリティ課田邉由嗣氏は、当時の SIEM 環境の課題をこう振り返ります。

「従来のオンプレミス型 SIEM は、とにかくログを集約し、オンラインで見られる状態にしておこうという発想で構築されたものでした。しかし、ログの量があまりに膨大だったため、すべてのログを入れておけない状態が長く続いており、思うような分析ができずにいたのです。増設やクラウド型 SIEM への移行も検討していたのですが、コストの増大などを嫌って後回しにしてしまい、気がつけば抜本的な見直しが急務になっていました。」

ログを蓄積するだけの運用から、インテリジェントな活用へ

そうした中、2024 年ごろ、各国の拠点で個別に管理・運用されていた IT 施策を、セガサミー HD がヘッドクオーターとなって指揮する方針が決定。セキュリティ製品についてもグローバルで統一しようという機運が高まり、蓄積してきた課題を一気に解消するチャンスが巡ってきました。グローバルセキュリティ推進室グローバルセキュリティ企画課範國貴栄氏によれば、新環境に向けたセキュリティソリューション選定で重視されたのは、総合的な利便性の高さでした。

「複数のクラウド型 SIEM を比較・検討した結果、行き着いたのが Google Security Operations（SecOps）でした。最大の決め手となったのが、その利便性の高さ。ログを蓄積してしまえば、標準で搭載されている Curated Detections が自動で脅威検知し、独自アラートルールの作成を Gemini に手伝ってもらうこともできます。我々の目指す、ログのインテリジェントな活用という方向性に最も近い選択肢だと感じました。また、ダッシュボードもカスタマイズしやすいため、グローバルなレベルで運用の標準化を促進する効果も見込まれました。」

さらに「比較・検討した他社製品と比べてコストメリットが大きかった」（宮地氏）という要因も導入を後押ししたといいます。このような中、2025 年 7 月からの PoV（価値実証）、10 月の部門内レビュー、年末の役員説明を経て、2026 年 4 月から、まずは国内での正式な活用がスタートすることになりました。

「Google Cloud のパートナーである株式会社リベルスカイの伴走や、Google Cloud サポートチームの献身的な対応もあり、スムーズに移行することができました。しいて言えば、ログを中継して SecOps に投げるサーバーの構築に少し苦労した程度です。SecOps は Gemini と連携させていくことにより、SIEM という難解な印象の強いソリューションを扱いやすくし、セキュリティに関する全社的なリテラシーを高めていく効果も期待できます。現在は旧来のオンプレミス型 SIEM も並行して動かしていますが、年内には完全に切り替えが完了し、海外拠点でも順次切り替えを進めていく見込みです。」（範國氏）

「ちなみにエストニアの拠点は、今回の取り組みに先行して SecOps の導入を進めていました。彼らも使い始めたばかりですが、実際的な運用方法や細かなチューニングなども含めて弊社グループ内で積極的に情報を共有し、より高度な活用につなげていければと考えています。」（宮地氏）

SecOps と Google Threat Intelligence による管理体制を世界 80 拠点で標準化

今回の SecOps 導入では、運用体制の変革をもたらすことも期待されています。同社の SOC 業務では、スタッフ個々の負担増加や、ノウハウが属人化してしまう状況をいかに回避するかが、目標になってきました。

「少人数 SOC による属人化状態になってしまうと、他の業務の繁忙期や、担当者が体調不良になった際に監視・分析が止まってしまうことも考えられます。しかし、SecOps のように AI も活用しながら、誰でも脅威や侵害に気づいて迅速に対策できるツールがあれば、工数をチームメンバーに分散でき、属人化も解消できます。何より、より多くの社員が実際の運用に関わるようになることで、SOC 業務が "自分ごと化" される価値も大きいと感じています。今後はチケット管理ツールなどと連携させ、アラートから通知までを一気通貫でつなげて自動化させていく予定です。SOC の負荷をさらに低減し、本来やるべきセキュリティ対策の議論に時間を割けるようにしていきたいです。」（田邉氏）

属人化の解消という点では、脅威インテリジェンスの領域でも変革が進んでいます。従来使っていた脅威インテリジェンスサービスは製品としては非常に優れていたものの、ライセンス料が高額で、各拠点に 1 ライセンスずつしか割り振れていない悩みがありました。これを解決すべく、SecOps の導入に並行して、Google Threat Intelligence も採用されています。

「ライセンスが少ないと脅威情報にアクセスできる人間が、ごく一握りになってしまいます。その点、Google Threat Intelligence であれば、同じ予算で各拠点のセキュリティ担当者全員にアカウントを払い出せます。SIEM への取り込みなど、API 連携が容易な点も魅力的です。これにより、自分たちの会社の脅威情報を自分たちでプロアクティブに見にいける環境を整えることができたと思っています。」（宮地氏）

「受け身ではない、能動的なセキュリティ対策は、数年前から目指していました。従来の環境ではうまく実現できていなかったことが、Google Threat Intelligence の導入でいよいよ本格的に実現できるのではないかと期待しています。」（田邉氏）

今後、セガサミー HD は、Sega of America、Sega Europe など、およそ 80 にもおよぶ海外拠点に対して、SecOps や Google Threat Intelligence をはじめとする Google Cloud のセキュリティソリューションを統一的に展開していく予定です。

「ここで活きてくるのが、そのブランド力です。Google Cloud は世界中の誰もが知っており、どの地域でも利用できるため、各海外拠点のエンジニアたちにもすんなりと受け入れてもらえます。今後は ASM（Attack Surface Management）や、CNAPP（Cloud Native Application Protection Platform）である Wiz なども活用し、製品開発業務の生産性や、サービスの品質を世界中で高めていきたいと考えています。」（宮地氏）

セガサミーホールディングス株式会社
2004 年 10 月 1 日に大手パチンコ・パチスロ機器メーカーのサミーと、大手ゲームメーカーのセガの経営統合により設立された総合エンタテインメント企業グループの持株会社。グループの経営管理および、コーポレート IT 整備などの附帯業務を行う。従業員数は単体で 492 名、グループ連結で 11,944 名（2026 年 3 月末現在）。

インタビュイー（写真右から）
IT ソリューション本部
・グローバルセキュリティ推進室部長兼セキュリティガバナンス管理課課長兼
　グループ CIO 室　宮地雅人氏
・グローバルセキュリティ推進室グローバルセキュリティ企画課　範國貴栄氏
・グローバルセキュリティ推進室 IT インフラセキュリティ課　田邉由嗣氏

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

顧客事例

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

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

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

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

Yahoo が Managed Service for Apache Spark のフレキシブル VM でリソースを最適化している方法

静的構成の運用上のトレードオフ

柔軟なクラスタを構成するためのルール

フレキシブル VM が大規模なワークロードをサポートする 2 つの方法

gcloud の例

API の例

インフラストラクチャ ポリシーの確立

Yahoo の影響と結果

柔軟なインフラストラクチャの戦略上のメリット

復元力のあるデータ パイプラインを構築する

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

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

Uber の事例の要点

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

業務の再定義: Pythian の社内 AI ハンドブックがもたらす顧客の ROI

Pythian AI オペレーティング モデルの 4 つの柱

実際の導入効果: データベース運用からグローバル サプライ チェーンまで

AI オペレーティング モデルを構築する準備はできましたか？

Mirendil の事例: トレーニング前後のアプリケーションに AI Hypercomputer のTPU と GPU を活用

JBサービス: Google Threat Intelligence で、さらに効率的で高精度、プロアクティブなセキュリティ サービスを提供

圧倒的な情報量と利便性を評価し、Google Threat Intelligence を導入

従来は検出できなかった脅威を可視化し、プロアクティブな防御を展開

1 年間の運用で得られた成果を基盤に、新たな SOC サービスの提供を開始

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

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

TelevisaUnivision が Google Cloud を選んだ理由

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

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

まとめ

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

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

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

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

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

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

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

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

背景: 高度な計算

課題: 供給を上回る需要

解決策: 共有 GPU フリート

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

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

参考ポイント

次のステップ

API 対応エコシステムでアジリティを獲得した Deutsche Bank の手法

バックボーンの構築: 4 つの主要な機能

1. スピードを犠牲にしない統合ガバナンス

2. セキュリティ: 従業員のオンボーディングとの類似性

3. 大規模なレジリエンスとパフォーマンス

4. オブザーバビリティ: すべて測定可能

将来を見据える

新たな標準: MCP、A2A、そして未来

ビジョン: ユニバーサル インターフェースとしての API

学んだ教訓

まとめ

Spanner Graph で小売商品の検索性能を強化し、データベースのメンテナンス工数半減を達成した Target の取り組み

断片化されたアーキテクチャからの脱却

Spanner Graph でエンタープライズ オントロジーを構築

ダウンタイムなしでスムーズに段階的に移行

ビジネスへの影響

Best Buy、Workforce Identity 連携で AI ワークロードをスケールし、アクセスを保護

サービス アカウントを直接連携に置き換える

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

インフラストラクチャポリシーの確立

復元力のあるデータパイプラインを構築する

Pythian AI オペレーティングモデルの 4 つの柱

実際の導入効果: データベース運用からグローバルサプライチェーンまで

AI オペレーティングモデルを構築する準備はできましたか？

JBサービス: Google Threat Intelligence で、さらに効率的で高精度、プロアクティブなセキュリティサービスを提供

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ビジョン: ユニバーサルインターフェースとしての API

Spanner Graph でエンタープライズオントロジーを構築

サービスアカウントを直接連携に置き換える