顧客事例

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 インフラセキュリティ課　田邉由嗣氏

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

AI エージェント事例アワード開催！指示するから、自律する AI へ。

Mon, 13 Jul 2026 02:00:00 +0000

前身の「生成 AI 事例アワード」を始めてから、2 年あまりが経ちました。この場には、ビジネスを大きく動かした取り組みから、日々の業務を助ける等身大のアイデアまで、素晴らしい事例が数多く集まってきました。そして、この 2 年で生成 AI そのものも、試す段階から業務に組み込む段階へと移ってきています。

指示を一つずつ出す使い方から、目的を伝えて自律的に動かす使い方へ。この変化は、AI を業務にどう生かすかという問いそのものを変えつつあります。そして、アワードに応募いただく事例の顔ぶれも、この 2 年で確かに変わってきました。

こうした変化に合わせて、今回から名称を 「AI エージェント事例アワード」へと改め、次の一歩をつくる活用事例をあらためて募集します。ビジネスを前に進める最先端の取り組みから、アイデアが光る業務効率化まで。分野や規模は問いません。みなさんの事例をお待ちしています。

事例アワードへの応募・詳細はこちら

スケジュール

エントリーからピッチコンテストまでの日程は次のとおりです。

エントリー開始: 7 月 7 日（火）
エントリー締切: 9 月 2 日（水）
ファイナリストのピッチコンテスト : Agentic AI Summit '26 Fall（10 月 29 日）内で実施

評価基準

審査では、次の 3 つの観点から事例を見ます。

技術的革新性（特に AI エージェントの活用）
実用性と実現可能性
社会的・経済的な影響

表彰内容

受賞した企業には、次の賞を用意しています。※ 表彰内容は予告なく変更になる場合があります。

最優秀賞（1 社 2 名）

トロフィー
Google Cloud Next 27（ラスベガス開催）への特別招待

優秀賞（3 社）

トロフィー
Google Cloud グッズ

ファイナリスト賞（8 社）

Google Cloud グッズ

みなさんの応募をお待ちしています。

日立「Gemini Enterprise 活用コンテスト」開催レポート ― 112 件の応募から選ばれた、現場を変える 10 の AI エージェント

Thu, 09 Jul 2026 02:00:00 +0000

6 月 17 日（水）渋谷ストリームグーグルオフィスにて AI エージェントは、現場のどんな仕事を本当に楽にしてくれるのか。その答えを、日立製作所のみなさん自身が見せてくれる一日がありました。今年 4 月からデジタルシステム＆サービスセクターの社員を中心に利用が広がった Gemini Enterprise。その活用アイデアを競う「Gemini Enterprise 活用コンテスト」には、総勢 112 件もの応募が集まりました。選り抜かれた 10 組が登壇した発表会の熱気を、そのままお届けします。

112 件の応募から、現場発の 10 組が登壇

発表会は、日立とグーグル・クラウド・ジャパン両社の挨拶で幕を開けました。AI を業務にどう根付かせるかという強い意志が、冒頭から明確に打ち出されていました。

日立デジタルシステム&サービス/ AI &ソフトウェアサービスビジネスユニット事業主管を務める西孝治氏は、AI への期待をこう語りました。「AI は非常に活況を呈していますが、一番やりたいのは日立の社内トランスフォーメーションです。みなさんが AI を使いこなして、お客様の前でもマーケットの中でも、 Gemini をこんな風に使っているぞと宣伝してくれる、そんな AI のショーケースになってほしい」。 1 人で考えるには限界がある、隣の人が何をしているかという知見をぜひ共有してほしい、という呼びかけもそえられました。

続いて登壇した Google Cloud 執行役員自動車・産業営業本部本部長の浅井は、会場を見渡してこう切り出します。「壇上から見ると、みなさんの顔が自信に満ちあふれているのがひしひしと伝わってきて、私自身もワクワクしています」。日頃 Google Cloud と一緒にビジネスの変革を進められていることへの感謝を述べました。

現場の「困った」から生まれた 10 のエージェント

10 組の発表はどれも、日々の業務でぶつかる具体的な「困った」を出発点にしていました。発表順にご紹介します。

失注ポストモーテム AI 「失注リフレクター」: 失注した案件の経緯を SharePoint の社内資料から再構成し、「3 つの分岐点」「顧客の発言と真意」「次回への教訓」を 3 分で構造化レポートにまとめます。レポートは社内のナレッジ DB にためて、営業担当者が商談前に過去の知見として参照できるようにします。原因分析にかかる時間を短縮するとともに、分析の実施率を大幅に高めることで、失注を組織の武器に変える仕組みを提案しました。
Power Automate × Gemini Enterprise による定例会議議事録作成の「完全自動化」 : Microsoft の Power Automate と Gemini Enterprise を組み合わせ、定例会議の議事録づくりを入口から仕上げまで自動でつなぎました。
業務改善アドバイザー: 複数のエージェントが手分けして、自分の業務をヒアリングし、分析し、ボトルネックを洗い出して改善案まで示します。業務の流れは Mermaid 形式の図にして一目で見渡せるようにしました。業務のヒアリングから分析、改善提案までのプロセスを大幅に短縮できる可能性が示されました。これまで数日かかっていた作業が、約 10 分に縮みます。
議事録「ワンショット 5 方向展開」マルチエージェント: Gemini Enterprise の Agent Designer で 5 つのサブエージェントを組み、 Teams のトランスクリプトから Markdown レポート、 Word 議事録、 Excel の Q&A 、 Teams 向けの展開メッセージ、 Redmine チケットを一度に生成します。議事録1 本あたりの二次加工は 90 分から 5 分へ、 94 % 削減。年間およそ 7,000 時間の削減になります。
開発チーム、転生したら AI だった件: 開発が一段落してメンバーが抜けた後の問い合わせや軽微なバグ修正を引き受ける仕組みです。離任する前に「AI 転生テンプレート」で自分の思考の進め方や口調まで写したサブエージェントを残し、人が減ってもチームが回ります。問い合わせ対応や初期調査は 1 時間〜半日から 5 〜 10 分に短くなり、問い合わせの 8 割以上に対して、AIが妥当な回答案を提示できると見ています。
ExcelScribe 手書き帳票の Excel 自動転記ツール: 端末を持ち込めないデータセンターなどの現場で手書きした帳票を、 Gemini Enterprise が文字認識して元の Excel に書き戻します。アウトプットをより精緻に行うために組み合わせるツールを作成しました。
画面録画 × Gemini で PC 操作のムダを可視化: PC 上の自分の作業を画面録画して渡すだけで、 Gemini が操作を読み取り、ショートカットや関数で速くできる箇所を具体的に示します。リモートワークで「隣の人の操作を見て盗む」機会が減った今だからこそ効くアイデアで、マウス操作などをおよそ 20 〜 30 % 減らせます。
NotebookLM と Gemini Enterprise を活用したグラフィックレコーディング作成 : 会議資料や記事を NotebookLM で要約し、その結果を Gemini Enterprise に渡して、グラレコの構成案・レイアウト・イラストの案、さらに画像までを生成します。技術のある社員が、構成作りも含めて 2 時間かかっていた作業が、10 分で実施できるケースも見られました。
提案の質と速度を極める財務分析 with 3 つの AI エージェント: 決算短信サーチ、財務諸表分析、可視化の 3 つのエージェントが連携し、企業名を入れるだけで IR 資料を集め、在庫の回転日数など供給網に効く指標まで自動で計算します。 1 社あたり 3 時間かかっていた情報収集・分析が 45 分に、工数を 75 % 削減しました。
Gemini マルチエージェントによる設計書レビュー支援: チェックリストや日立がこれまで積み上げてきた社内の設計ガイドをレビュー観点として整理し、複数の専門エージェントがシステムの設計書を多角的に確認します。観点不足による見逃しを抑え、レビューがレビュアーの経験に左右されにくくなりました。

どの発表にも共通していたのは、 AI に丸投げするのではなく、「どこを AI に任せ、どこは人が判断するか」をていねいに切り分けていたことです。発表のあとは毎回 Q&A が活発に飛び交い、自分の業務にどう応用できるかを考える声が会場のあちこちから上がっていました。

受賞した 5 組と、審査員からの言葉

審査員が選んだ受賞者の 5 組には、それぞれの着眼点に対して温かいコメントが寄せられました。

オーディエンス賞: 画面録画 × Gemini で PC 操作のムダを可視化。会場の投票で一番多くの支持を集めました。審査員からは「なぜこの人たちは、資料を書かないという選択をしなかったのか。ふつうは AI に資料そのものを作らせたくなるのに、この人たちはあえて、作る作業を速くするほうへ情熱を注いだ。そこがすごい」「現場で起きている泥臭い作業をいかに AI で効率化していくか。これはフィジカル AI の基本で、とても期待できます」と熱のこもった講評がありました。

Google Cloud 賞: 開発チーム、転生したら AI だった件。 Google Cloud の執行役員カスタマーエンジニアリング統括技術本部長渕野は「アイデアとしてとても面白い」と評価したうえで、応用の広がりに触れました。「コーディングを助けるエージェントは増えていますが、実際のシステム開発はプロジェクトの背景を踏まえて進める必要があります。その文脈までエージェントに引き継げる、という意味で応用が効く発想だと思いました」。

Google Cloud 賞: ExcelScribe 手書き帳票の Excel 自動転記ツール。賞品を手渡した Google Cloud 浅井は、「他社のツールであっても、ちゃんと書き込めるモジュールを開発してほしい、という熱いプレッシャーを感じました。フィールドの声として、しっかり開発チームに届けます」とコメントしました。

日立賞: 失注ポストモーテム AI 「失注リフレクター」。日立の内藤氏は、失注分析の難しさに踏み込みました。「受注は意外と再現性が低く、失注は再現性が高いという事実をよく見ていくと、受注確度を上げることに繋がります。そこをきちんと言語化できているのがとても良かった。ぜひお客様の営業活動にも役立てられる形へ、 Gemini と一緒にアイデアを練り上げていってください」。

日立賞: Gemini マルチエージェントによる設計書レビュー支援。日立のものづくりで培ってきた設計の知見を、そのままレビューの観点としてエージェントに持たせた点が評価されました。

5 組とも、削減できた時間や工数といった数字だけでなく、現場の心理的な負担まで軽くしている点が印象的でした。

これからも、日立の挑戦とともに

閉会のあいさつで、 Google Cloud の渕野はこの日の手応えをこう振り返りました。「今日のプレゼンはどれも Q&A が活発で、発表を見て自分のアイデアはこうできるんじゃないか、と考えている様子が伝わってきました。みなさんを支援している私たち Google のメンバーも、やりがいと達成感を感じる素晴らしい会でした」そして、これからへの期待も。「 1 回目でこのレベルの高さです。 2 回、 3 回と続けていけば、どんどん上がっていくはずです。私たちも引き続き、しっかり支援させていただきます」。

また、審査員を務めた日立デジタルシステム&サービス/経営戦略統括本部統括本部長内藤氏からは、30年のキャリアを振り返りつつ、日立の未来への明るい展望が語られました。

「私自身、社内で Gemini Enterprise を毎日5回以上は必ず使う愛用者ですが、今日の皆さんのアイデアを聞いて『こういう使い方もあったのか！』と非常に理解が深まりました。今すぐにでもやってみたいアイデアがたくさんあり、とても楽しいひとときでした」と感謝を述べました。

また、コンテストを通じて見えた社内の変化についても、次のように熱く語りました。「この活動は、自分たちの業務を良くしていく『カスタマーゼロ』につながることはもちろんですが、何より発表者の皆さんが本当に楽しそうでした。これまで30年間会社にいますが、横の人がこんなに楽しそうに仕事をしている姿は見たことがありません。今日そういう一面が見えて、日立の未来は明るいんじゃないかと勝手に思ったりしています」

挨拶の最後には、「日立の取り組みと、Google さんの発展を心から祈念して、ぜひ皆さんと一緒にやってみたいと思います！」と会場に呼びかけました。内藤氏の「すごいぞ！」という掛け声に、会場全体が「Gemini！」と大きな声で応え、イベントは最高潮の盛り上がりのなか締めくくられました。

開会で西さんが語った「日立を AI のショーケースに」という思いは、この日の 10 組の発表で、もう確かな形になり始めていました。現場の「困った」から生まれたアイデアが、 112 件という数になって集まり、その一つひとつが誰かの仕事を軽くしていく。 Google Cloud はこれからも、日立のみなさまのこうした挑戦に、 Gemini Enterprise とともに伴走していきます。

Alphaevolve で分子発見を 4 倍に高速化した Schrödinger の事例

Mon, 06 Jul 2026 19:00:00 +0000

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

計算化学の研究者は、従来より、分子間相互作用をシミュレートする際に、精度を犠牲にする高速な古典的力場を使用するか、大規模なジョブでは実行速度が遅すぎる高精度の量子力学的手法に頼るかという、悩ましいトレードオフに直面してきました。

ML 力場（MLFF）は、高忠実度の量子データでニューラルネットワークをトレーニングすることで、そのギャップを埋めます。しかし、現代の創薬や材料設計では、膨大な化学ライブラリを処理するために、さらに高速な処理速度が求められています。このようなパフォーマンスの制約を克服するために、Schrödinger は Google Cloud と提携して AlphaEvolve をデプロイしました。これは Google DeepMind が開発した進化型 AI コーディングエージェントで、アルゴリズムのボトルネックを克服する最も効率的なコードパスを見つけるために、アルゴリズムを繰り返し生成して改良します。

AlphaEvolve とのコラボレーション

30 年以上にわたり科学ソフトウェアの開発をリードしてきた Schrödinger は、MLFF トレーニングパイプライン内でパフォーマンスを制限する重要なアルゴリズムとして、近傍リスト計算法とエバルト総和法の 2 つを特定しました。これらのアルゴリズムは、原子の近傍からのデータを集計して長距離ポテンシャルを計算しますが、どちらもトレーニングと推論の速度において制限要因となっていました。

Schrödinger の技術面での最大の目標は、エネルギーと力の計算のための AI モデルのトレーニングを高速化することでした。具体的には、分子力学で使用される、重要ではあるものの計算負荷の高い機能であるエバルト総和法をターゲットとしました。Schrödinger の PyTorch コードにおいて、エバルト総和法が主なパフォーマンス上の制約となっていました。ベクトル化されたアルゴリズムは確立されておらず、通常は単純な for ループに頼っていたため、大規模なシミュレーションでは処理が遅くなっていました。

AlphaEvolve をモデルに組み込むことで、システムは並列バッチ行列乗算を使用して、エバルト総和法のバッチ実装を生成できるようになりました。これにより、PyTorch コードが進化し、既存のカスタムカーネルを上回るパフォーマンスを実現できました。

評価指標

Schrödinger は、厳格な多層的評価フレームワークを使用して、進化したコードがパフォーマンスと科学的正確性の両方を備えていることを確認しました。

逆時間（主要指標）: 計算時間をベースラインスコア 7.9 から短縮して、スループットを最大化することが主な目標でした。
機能的正確性: 進化したプログラムはすべて、無秩序水モデルなどの複雑なシステムに対する回帰テストを含む、完全なテストスイートに合格する必要がありました。
成功率: 機能的に正確で、ベースラインよりも高速なプログラムの割合で測定しました。

「AlphaEvolve を使用することで、これまでよりも迅速かつ効率的に、より広範な化学空間を探索できるようになりました。MLFF 推論の高速化は、創薬、触媒設計、材料開発における研究開発サイクルを短縮し、企業が分子候補のスクリーニングを数か月ではなく数日で完了できるようにすることで、ビジネスに現実的な効果をもたらします。」- Schrödinger、ML テクニカルリード、Gabriel Marques 氏

結果: 4 倍の高速化とボトルネックの解消

AlphaEvolve を適用することで、Schrödinger はエバルト総和法のコード内の単純な for ループを並列バッチ行列乗算に置き換えました。この最適化により、プログラムの成功率は 1% 未満（5,000 件の評価のうち 40 件）から 60% 以上に向上し、パフォーマンス指標はベースラインの 7.9 から 30 近くまで改善されました。

これらの基本的なアルゴリズムを最適化することで、MLFF のトレーニングと推論の両方で 4 倍の高速化が実現しました。この高速化により、研究者は分子スクリーニングのタイムラインを短縮できます。これは、いくつかの重要な研究分野に直接的なメリットをもたらします。

創薬: 緊急の医療ニーズに対応するため、有望な治療候補を迅速に特定できます。
触媒設計: 産業用途向けに効率的な化学プロセスを開発できます。
材料開発: 電子機器やエネルギー貯蔵向けに、カスタムプロパティを持つ次世代材料を設計できます。

次なる進化

Schrödinger は、この進化的なアプローチをカスタム GPU カーネルに適用し、AI によって生成されたコードが、人間が設計した実装よりも優れているかどうかをテストする予定です。

進化型 AI エージェントが科学的なコードベースを最適化する方法については、AlphaEvolve に関する技術論文の全文をお読みください。また、研究ワークフローの高速化についてご相談されたい場合は、Google Cloud AI チームにお問い合わせください。

- Google、プログラムマネージャー、Kartik Sanu

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

Atlas が Cloud SQL Enterprise Plus エディションにより数百の加盟店のデータベースをどうスケールしたか

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

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

Atlas は、飲食店向けのオペレーティングシステムを構築しています。オンラインショップ、POS、サードパーティロジスティクス、食のプラットフォームの統合、顧客ロイヤリティ、AI ツールは、飲食店の立ち上げから運営、そして成長に必要なあらゆる要素を網羅しています。当社はシンガポールでは、SaladStop、Killiney、Haidilao、Raffles Hotel、Lo and Behold Group、Les Amis Group などのブランドと連携し、加盟店の 1 回あたりの購入額の増加、売上拡大、運用コスト削減を支援しています。

Atlas の各加盟店には、専用の Cloud SQL for PostgreSQL データベースが割り当てられます。飲食店の形態はそれぞれ大きく異なります。単一店舗のカフェと複数店舗あるチェーン店で、裏側の仕組みが同じであるべきではありません。データベースを独立させることで、データが完全に分離されているほか、昼食時や夕食時のピーク時でもパフォーマンスが予測可能で、各店舗を個別にスケール、チューニング、移行できる柔軟性があります。Atlas の成長に伴い、データベースの数も増えています。

課題: 標準エディションの枠を超えたスケール

当社は、最初に標準の Cloud SQL Enterprise エディションを導入しました。これは強固な基盤でしたが、加盟店が増え、機能が追加されるにつれて、データベースを管理するために必要な運用レイヤがボトルネックになりました。

接続プーリングを別のレイヤとして管理していたため、実行、保護、モニタリングするサービスが増えていきました。クエリによって CPU が急上昇した場合、何が起こったのか、どの加盟店がトリガーしたのかを正確に把握する必要がありましたが、限られたシグナルから問題を突き止めるのに時間がかかりすぎていました。小規模なチームで、専任のデータベースエンジニアがいなかったため、コンポーネントが追加されるたびにメンテナンスの負荷が増加していました。

Enterprise Plus エディションへの移行

新しいデータベースインスタンスをプロビジョニングする必要が生じたとき、Google Cloud チームに Cloud SQL Enterprise Plus エディションを紹介してもらいました。運用上のオーバーヘッドがどれだけ増えるのかをすでに懸念していましたが、Enterprise Plus エディションでは、本来なら自社で対応しなければならない作業のカテゴリ全体が不要になることがわかりました。

マネージド接続プーリング: この機能が Cloud SQL に直接組み込まれるようになったため、プーリングを個別のレイヤとして実行する必要がなくなりました。これにより、システムの構成要素が減り、メンテナンスの負担が軽減されただけでなく、攻撃対象領域も小さくなりました。
Query insights: これは、当社に最も大きな効果をもたらした機能でした。どのクエリの負荷が高く、どの加盟店がそのクエリをトリガーしているかを正確に把握できるようになったからです。パフォーマンスチューニングが、推測に基づくものから、具体的で実行可能なものへと変わりました。数百ものデータベースを実行するプラットフォームにとって、この可視性は「スーパーパワー」と言えます。
データキャッシュ: これにより、加盟店のデータセットが増加しても、読み取りパフォーマンスが一定に保たれるようになりました。飲食店では毎日多くのデータが生成されるため、データレイヤはそうした複雑化に合わせて高速処理を維持する必要があります。
ダウンタイムがほぼゼロのスケーリング: 加盟店の拡大に合わせて、オフピーク時にサービスを中断することなくインスタンスをスケールできるようになりました。

新しいインスタンスで結果を確認した後、既存のすべてのデータベースも Enterprise Plus エディションに移行しました。

効果: インフラストラクチャ管理ではなくイノベーションに注力

現在、Atlas は数千の飲食店で利用されており、数百ものマネージドデータベースを使用して毎日数万件の注文を処理しています。最も大きな変化は、エンジニアリングの時間の使い方です。データベース運用にかかる時間が 30% 減り、プロダクトを構築するための時間が増えました。新規加盟店のオンボーディングも簡素化されました。すぐに使用できるマネージドデータベースが数秒でプロビジョニングされるため、導入がスムーズです。パフォーマンスは以前よりもはるかにプロアクティブになり、問題が加盟店に悪影響を及ぼす前に検出して修正しています。日々の業務では、データベース管理について考える必要はなく、加盟店により良いサービスをどう提供するかに注力できています。その結果 Atlas は前年比 200～300% の成長を遂げました。

今後の展望: AI ファーストの未来

当社は、社内外で AI に多額の投資を行っています。社内では、AI 支援の開発ワークフローを通じてエージェントエンジニアリングに全面的に取り組んでおり、少人数のチームでもコードのビルド、レビュー、リリースを大幅に高速化できるようになりました。社外では、飲食店の経営者がより良い意思決定を行い、それに基づいて行動できるよう支援する AI 搭載ツールを構築しています。当社のロードマップは、ユーザーとの新たな接点や飲食店の成長を支援する新しい方法など、多くの実験的なアイデアであふれています。これらすべてを迅速に進める自信を与えてくれるのは、基盤となるレイヤである Cloud SQL と Google Kubernetes Engine（GKE）の存在です。このレイヤは実績があり、開発の妨げになることはないからです。

インフラストラクチャの複雑さは Google Cloud が処理してくれるため、Atlas は飲食店向けの最適なツールの構築に専念できます。

Cloud SQL Enterprise Plus により、柔軟性、オブザーバビリティ、スケーラビリティに優れたデータベースアーキテクチャが実現しました。これによりインフラストラクチャ管理に頭を悩ませることなく、加盟店のことだけを考えられるようになりました。AI をさらに活用し、プラットフォームを成長させていく中で、Google Cloud は、基盤となるインフラストラクチャを気にかけずに迅速に前進するための自信を与えてくれます。

データベースアーキテクチャをスケールする準備はできていますか

インフラストラクチャのボトルネックにより、イノベーションが妨げられないようにしましょう。管理するデータベースが数十個でも数百個であっても、エンジニアリングチームが最も重要な作業に集中できるように、Google Cloud SQL がどのように運用の合理化とオブザーバビリティの強化を行うかをご覧ください。

Cloud SQL Enterprise Plus エディションに関する詳細
登録して Cloud SQL を無料で試す。

- Atlas、共同創業者 / エンジニアリング責任者、Surendhar Reddy 氏

- Google Cloud、データベース、シニアプロダクトマネージャー、Alok Srivastava

英国の成長企業が AI 時代にどのようにビジネスを構築しているか

Thu, 02 Jul 2026 02:00:00 +0000

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

英国の 500 万を超える中小企業（SMB）は、英国経済の屋台骨です。現在、こうした重要な役割を担う企業は AI の導入を進めており、業務の効率化や迅速化、そして最終的には顧客により良い成果を提供できるようになりつつあります。

この変化は、日々の具体的な成果によってもたらされています。Google とのパートナーシップで Enterprise Nation が発表した最近の調査によると、英国で調査対象となった AI 導入企業の 71% が、AI によってルーチン業務の時間を節約できていると回答し、64% が生産性の直接的な向上を報告しています。さらに、AI 対応の生産性向上ツール（Google Workspace with Gemini など）は、中小企業の生産性を 20% 向上させており、これは実質的に、毎週 1 日分の労働時間を中小企業に還元していることになります。

Google Cloud は、この変化を最前列で見てきました。中小企業は長年にわたって Google Workspace などのプラットフォームを利用しており、現在では Google AI プラットフォームとモデルで変革を遂げています。実際、Google Cloud AI を利用している英国の中小企業の数は、前年比でほぼ 2 倍になっています。これには、Gemini モデルや、Gemini Enterprise、AI Studio などのプロダクトが含まれます。これらは、中小企業が次のようなことを行えるよう支援しています。

より優れたカスタマーサポートシステムを導入し、電話対応のエスカレーションと解決をより迅速に行えるようにする。
給与計算や会計などの分野で、反復的な作業を自動化する。
データアナリストとしての専門教育を受けていない従業員も含め、より多くの従業員が業務でデータを理解し、活用できるようにする。
マーケティング関連資料の新しいデザインを迅速に作成し、導入する。
より多くの人が、日々の業務をサポートする独自の AI エージェントを構築できるよう支援する。
これまでにないスピードと低コストで、複雑な調査プロジェクトを実施する。

今回の Google Cloud ロンドンサミットでは、Google AI ツールを積極的に使用して業務を変革している、革新的な中小企業のお客様を多数ご紹介します。その中には、最近 Google との連携を拡大した企業も含まれます。

サステナビリティフィンテック企業の Neural Alpha は、Gemini モデルを使用して、非構造化の環境レポートや企業のサステナビリティレポートを読み取り、数千もの重要な事実を自動的に抽出および整理しています。これにより、数か月を要していた手動での調査を、ほんのわずかな時間に短縮しました。
デジタルセキュリティプロバイダの Sep 2 は、Gemini Enterprise を使用して、24 時間 365 日体制で脅威をモニタリングする自律型 AI エージェントをデプロイしています。これにより、インシデント検出を迅速化し、顧客に対するセキュリティ脅威を素早く排除しています。
戦略的なブランドデザインエージェンシーである Sunhouse は、Gemini Enterprise を使用して Google ドライブに保存されたアーカイブ済みのデザイン制作物を簡単に見つけられるようにしています。これにより、チームはファイル検索に費やす時間を減らし、グローバルブランドとのビジネスを成長させるためにより多くの時間を使えるようになっています。
グローバルな B2B イベント企業である Terrapinn は、Gemini モデル、NotebookLM、Looker、BigQuery を活用して手作業を自動化されたワークフローに置き換え、世界クラスのカンファレンスの企画、マーケティング、開催までのスピードを加速させることで、業務を変革しています。
通信プロバイダの VoCoVo は、Google Cloud AI をシステム全体に統合して、孤立したデータを活用可能なインテリジェンスに変え、自律的なワークフローを構築しています。これにより、ルーチン業務を効率化し、チームがインパクトの大きいイノベーションに集中できるようにしています。

チームの強化: 英国企業の成長を支援する AI スキル向上リソース

中小規模のチームがインパクトを最大化し、最新の AI 環境を自信を持って活用できるよう、Google は専用の無料スキル向上リソースを用意しました。既存のチームをトレーニングする場合でも、全従業員がデータツールを利用できるようにする場合でも、これらのプログラムは AI 活用に向けた組織づくりに役立ちます。

中小企業向けプログラム: 新しい中小企業向け学習プログラムをチェックするか、Gemini Enterprise Agent Ready（GEAR）プログラムに登録して、エージェント型 AI の専門的なトレーニングを受けることができます。
組織向け Google Skills: Google Cloud と Google DeepMind のエキスパートが作成した 3,000 以上の AI コースとハンズオンラボを備えた、無料のオンデマンドラーニングプラットフォームを利用できます。
Get Certified Program: チームの専門知識を実証する準備ができたら、このプレミアムなコホートベースのプログラムを活用しましょう。ここではクラスルームトレーニング、技術メンターシップ、AI を取り入れたスキルバッジが提供されており、業界で認められた認定資格の取得に向けてチームが準備できるよう設計されています。

Google は、Workspace の生産性向上ツールから、すべての広告サービス、そして強力な AI ツールまで、中小企業向けのテクノロジーとトレーニングのフルパッケージを提供することで、中小企業が将来どのような状況になっても成長し続けられるよう支援しています。

- 英国、アイルランド、サハラ以南のアフリカ担当バイスプレジデント、Maureen Costello

顧客事例

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 ワークロードをスケールし、アクセスを保護

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

アーキテクチャ

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

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

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

使ってみる

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

課題:

ソリューション:

アーキテクチャ:

結果:

詳細:

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

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

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

まとめ

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

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

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

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

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

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

最新 AI エージェント事例を厳選！ Gemini Enterprise で企業の業務を変える

7 月版で新しく追加された企業

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI エージェント事例アワード開催！指示するから、自律する AI へ。

データベースアーキテクチャをスケールする準備はできていますか