アプリケーションモダナイゼーション

Google Cloud と SAP、Agentic Enterprise に向けた青ブループリントを公開

Fri, 08 May 2026 01:00:00 +0000

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

Google Cloud と SAP はパートナーシップをさらに強化し、世界有数の大企業の中核業務プロセスに Gemini AI を直接組み込む取り組みを進めています。

AI の新たな基盤: このたび、Google Cloud Next '26 において、Google Cloud と SAP は、継続的なパートナーシップを通じて実現した Agentic Enterprise に向けた最新の成果を紹介しました。

その中核を成すのが Unified Data Foundation です。これは、SAP データと非 SAP データを双方向の信頼できる単一の情報基盤に統合し、従来のクラウドモダナイゼーションを、データドリブンな価値を生み出す戦略的な推進力へと進化させるものです。さらに、新たに追加されたゼロコピーデータ共有機能により、データ移動に伴う負荷をなくし、アーキテクチャをいっそう簡素化できます。これにより、ミッションクリティカルな AI ワークロードの構築に不可欠な、高忠実度のデータアクセスとリアルタイムの信頼性を確保できます。

また Google Cloud は、SAP Engagement Cloud の新機能も支援し、AI の作成、発想、学習を支える最新ツールを提供しています。これらのプラットフォームは SAP の従業員だけでなく、SAP のお客様にも提供されます。この一連の AI ツールは、企業全体でのエージェント活用に対する理解を深め、導入を後押しします。

重要な理由: この変化により、データストレージと AI イノベーションの間にあった隔たりは着実に埋まりつつあります。企業は、単にインフラストラクチャを管理する段階から、複雑で多段階のタスクを自律的に実行できるインテリジェントエージェントを実際に展開する段階へと進めるようになります。

とりわけ Unified Data Foundation は、既存のワークフローに有益なインサイトをもたらすだけでなく、AI ツールやエージェント型ワークフローが生み出す成果を支える基盤としても機能します。

全体像: このパートナーシップの深化は、SAP がお客様に価値を提供する方法をすでに変え始めています。

市場での競争力を維持し、優位性を築くという方針のもと、SAP の Engagement Cloud 部門は Google Cloud と連携し、次世代のエージェント型ソリューションを構築しました。これには、動的なコンテンツ開発、マーケティングブリーフやビジュアルコンセプトの生成、そして複数のエージェントが協調して実行する仕組みが含まれます。

コメント:「エージェント型 AI が価値を生み出すのは、信頼できるデータに基づき、実行に直接つながっている場合に限られます。だからこそ、Google Cloud とのパートナーシップは企業にとって非常に大きな意味を持ちます。生成 AI とエージェント型インテリジェンスを Engagement Cloud に直接組み込むことで、Google と SAP はマーケティングチームに、リアルタイムのインテリジェンスを意義ある顧客接点へと変える実践的な方法を提供しています。」- SAP、Engagement Cloud 責任者、Joanna Milliken 氏

新機能:

ゼロコピーの革新: SAP BDC Connect for BigQuery により、双方向のゼロコピーデータ共有が可能になります。膨大なデータセットを移動したり複製したりすることなく、データ基盤全体を統合できます。
Cortex Framework: 豊富なメタデータを BigQuery に直接埋め込む新たなソリューションアクセラレータです。これにより、Gemini エージェントは正確な企業コンテキストに基づいて動作できるようになり、AI のハルシネーションリスクを大幅に抑えられます。
99.95% SLA への向上: AI を活用した障害の予測と予防により、Google Cloud 上の RISE with SAP で業界トップクラスの稼働率保証を提供します。
SAP Sovereign on Google Cloud: 厳格なデータ所在地要件を持つお客様は、SAP の S/4HANA Private Cloud Edition を Google のソブリンインフラストラクチャ上で直接実行できるようになりました。

数値で見る: お客様は、データ分析にかかる総所有コスト（TCO）を最大 54% 削減できます。さらに、エネルギー効率に優れた Google のパブリッククラウドで SAP ワークロードを実行することで、企業の ESG 目標の達成も加速できます。

今後の予定: SAP BDC Connect for BigQuery は、まもなく一部のデータセンターで提供を開始し、2026 年後半にはさらに広い範囲で利用可能になる予定です。

さらに詳しく見る:

- 移行担当マネージングディレクター、Casey McGee

Google Cloud パートナーとのエージェント型エンタープライズの構築と 7 億 5,000 万ドルのイノベーションファンド

Mon, 27 Apr 2026 02:10:00 +0000

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

現在、エージェント型エンタープライズがお客様にとって現実のものとなりつつあります。今週開催の Next ‘26 では、お客様がエージェント型 AI をさらに加速させるのに役立つ、新しい画期的なイノベーションを発表しました。

エージェント型エンタープライズを実現するうえでは、Google のパートナー様が重要な役割を果たします。そこで今回は、エージェントの時代に業界で最も有能なパートナーエコシステムをお客様に提供するための新しいリソース、テクノロジー、緊密な技術パートナーシップについても発表いたしました。これには以下が含まれます。

グローバルコンサルティング企業、ソフトウェアパートナー、チャネルパートナーを対象とするエージェント開発のための 7 億 5,000 万ドルのパートナーファンド。
お客様が Gemini Enterprise でパートナーのエージェントをデプロイできる新しい方法。
お客様をサポートするために、グローバルコンサルティング企業との技術パートナーシップを強化し、Google から現地に配置するエンジニアチームを新たに編成。
Palantir、Salesforce、SAP、ServiceNow などのエンタープライズプラットフォームに Gemini モデルをより深く統合。
パートナー様が質の高いサービスを提供できるよう、Google Cloud パートナーネットワークの AI 搭載機能を拡充。

AI エージェントの開発を加速させるための投資

Google は、業界で最も AI 能力に優れたパートナーエコシステムをお客様に提供できるよう取り組んでいます。エージェント型 AI の時代にパートナー様が真の変革を推進できるよう、Google は 7 億 5,000 万ドルのイノベーションファンドを立ち上げます。エージェントの開発とデプロイを世界中で加速することを目的とし、対象はあらゆるビジネスプロセス、機能、業界となります。

このファンドは、以下のような幅広い活動を支援します。

ソフトウェア会社が Gemini Enterprise Agent Platform を使用して AI エージェントを自社製品に組み込み、Google の Agent Marketplace や、Gemini Enterprise の新しい Agent Gallery を通じて市場に投入できるよう、実践的サポートを提供します。
熟練した Google の前線配置エンジニア（FDE）が、主要なシステムインテグレータと連携して、お客様の技術的に難しい課題の解決や Google AI の迅速なデプロイを支援します。
デプロイと利用に関するインセンティブにより、サービスパートナー様がエージェントの時代に成功を収められるよう支援します。
パートナー様が Gemini Enterprise Agent Platform を使用してお客様向けにエージェントを構築、デプロイできるよう、トレーニング、技術開発イニシアチブ、ワークショップを提供します。

パートナー様が構築したエージェントを Gemini Enterprise で公開

Next では、エージェントを構築、スケール、管理、最適化するための包括的なプラットフォームである Gemini Enterprise Agent Platform を発表しました。このプラットフォームには、パートナーが構築した厳選されたエージェントをお客様が閲覧できる Agent Gallery が含まれます。

現在、Agent Gallery では幅広いサードパーティエージェントにアクセスできます。これらのエージェントは、Google の安全なエンタープライズグレードのインフラストラクチャ上に構築されているため、お客様は最高レベルのガバナンスと信頼性をもってビジネスにデプロイできます。現在、Accenture、Adobe、Atlassian、Deloitte、Lovable、Oracle、Palo Alto Networks、Replit、S&P Global、Salesforce、ServiceNow、Workday などが構築したエージェントがあります。

グローバルコンサルティングパートナーが AI トランスフォーメーションを推進できるよう支援

現在、Google Cloud のグローバルコンサルティングパートナーとシステムインテグレータパートナーは、Google AI の実装に関するトレーニングを受けた 33 万人以上のエキスパートをお客様に提供しています。Google Cloud は、今回の Next に合わせて、主要なシステムインテグレータとのパートナーシップを次のように拡大します。

Accenture は、前例のない Gemini Enterprise Acceleration Program の立ち上げにより、企業が AI を活用した変革とビジネス価値の向上を迅速かつ大規模に推進できるよう支援します。このプログラムでは、Google Cloud と Accenture のトップレベルの技術力と前線配置エンジニアをお客様の現場まで直接届けます。
BCG は Google Cloud とのパートナーシップを拡大して Gemini Enterprise による変革を加速させ、組織がエージェントの導入を大規模に実現できるよう支援します。
Capgemini は、Gemini Enterprise のエンタープライズ規模での導入を加速させるために、Google Cloud AI Enterprise Hub を設立します。
Cognizant は、Gemini Enterprise の企業への導入を加速させるために、Gemini Enterprise 専門のプラクティスグループを立ち上げます。
Deloitte は、Gemini Enterprise に特化した Google Cloud エージェント変革のプラクティスを立ち上げ、10 万を超える自社チームに Gemini Enterprise を展開します。
HCLTech は、Gemini Enterprise を基盤とする業界固有のソリューションの開発と導入を加速させるために、Gemini Enterprise ビジネスユニットを立ち上げます。
Infosys は、Infosys Topaz プラットフォーム内で Gemini Enterprise を活用し、Infosys のグローバルデリバリーチーム全体で 10 万人を超える Infosys の開発者に Gemini Enterprise を提供します。
KPMG は、ライフサイエンス企業に Gemini Enterprise をデプロイし、Workday と Google Cloud で構築された新しい Financial Close Companion エージェントをリリースします。
Kyndryl は、AI 対応の主権アプリケーション向けの Google Distributed Cloud サービスを拡大し、Google Cloud とのパートナーシップを強化します。
McKinsey は、McKinsey Google Transformation Group を立ち上げ、Gemini Enterprise を使用して企業の AI 成果を加速させます。戦略的専門知識と Google の AI スタックを組み合わせることで、組織がエージェントによる変革をスケールできるよう支援します。
PwC は、Google Cloud AI 専門のセンターオブエクセレンスを立ち上げ、組織の AI 導入の拡大を支援します。業界の専門知識と Gemini Enterprise を組み合わせることで、推論、行動、プロセスの自動化を大規模に行う AI エージェントをデプロイします。
TCS は、新しいエージェント型 AI サービスと Gemini Enterprise 専門のプラクティスを開始します。3,000 を超える業界に特化した AI エージェントと、Gemini Experience Centre のグローバルネットワークの拡大により、AI ネイティブの自律的な企業運営を加速させます。

Google Cloud はさらに、Accenture、Capgemini、Cognizant、Deloitte、HCLTech、PwC、TCS などの一部のグローバルパートナーにエンジニアチームを派遣し、お客様が自社内で AI エージェントのプロトタイプ作成とデプロイをより迅速に行えるよう支援します。Altimetrik、Artefact、Covasant、Deepsense、Distyl.ai、Northslope、Quantium、Tribe.ai、Tryolabs などの AI ネイティブサービスパートナーは、Gemini Enterprise のプラクティスを立ち上げ、サンドボックス開発、技術的なスキルアップ、紹介の機会のクレジットを受け取る予定です。

また、Google Cloud は、Accenture、BCG、Deloitte、McKinsey など、一部のパートナー様にモデルの早期アクセスを提供する新しいプログラムも展開します。これらのパートナー様は、Google DeepMind の今後のモデルのプレリリースバージョンをプレビューして、構築を開始できます。

一般的な SaaS プラットフォームを通じて Gemini をより多くのお客様に提供

世界をリードする多くのエージェント型 SaaS や AI プラットフォーム企業が、Gemini をすでに自社製品に統合しています。Cloud Next では、こうした統合を次のようにさらに拡大します。

Atlassian は、Gemini 3 Flash を Rovo に導入し、マルチモーダル機能を Confluence の Remix に統合することで、チームがテキストベースのドキュメントを忠実度の高い図やグラフに即座に変換し、関係者の意思決定を迅速化できるようにします。
Box は、Gemini 3 Flash と Gemini Enterprise を活用した新しい Box Agent をリリースします。これにより、企業は AI オーケストレーションを安全なコンテンツ管理ワークフローにネイティブに統合し、静的ファイルを実用的なインテリジェンスへと変換できます。
DocuSign は、Gemini を活用して、複雑な契約書を要約し、重要な条項を特定し、契約の言外の意味をユーザーが理解できるようにする新機能を提供します。
Oracle は、Gemini Enterprise 向け Oracle AI Database コネクタをリリースします。この新しいエージェントにより、エンドユーザーは Gemini Enterprise で Oracle データに関するビジネス上の質問を自然言語で行うことができるため、SQL を記述したり、基盤となるデータモデルを理解したりする必要がなくなります。
Palantir は、商用のお客様向けに Gemini と BigQuery のインテグレーションを追加し、お客様が最高水準のモデルを最も重要な AI ワークフローや業務に接続できるようにします。
Salesforce は、Atlas 推論エンジンにネイティブの Gemini サポートを追加します。これにより、Agentforce はテキスト、画像、動画など形式を問わず確認し、長年にわたる顧客履歴から複雑な問題を的確に解決できます。すでに数千ものお客様が Agentforce 内で Gemini を使用してプロンプトを作成した成果を基盤に、より迅速かつスマートな解決が可能になります。
SAP は、Gemini Enterprise を Engagement Cloud に統合し、AI を活用したカスタマーサービスと販売の分析情報とともに、画像やテキストを生成するクリエイティブツールを提供します。
ServiceNow は、自社の AI エージェントを Gemini Enterprise と統合し、世界最大規模の企業に自律運用を提供します。

エージェント時代のパートナーチャネルの構築

Google の新しいパートナープログラムである Google Cloud パートナーネットワークは、パートナー様がエージェントの時代に成功できるよう設計されています。昨年、Google は AI を使用してパートナーツール全体で深い分析情報を引き出せるようにしました。現在は、これらの分析情報を自律的な成長につなげるエージェント型ワークフローを構築しています。主な更新内容は次のとおりです。

Partner Agent: Partner Network Hub に統合されたこのエージェント型ツールは、パートナーエクスペリエンスの中央のオーケストレーターとして機能します。質問に答えるだけでなく、次のステップについて積極的にパートナーを導き、複雑なアセットを要約し、登録や作業明細書についてリアルタイムでコーチングします。
Agentic Earnings Hub: ここでは、作業明細書の下書きを自動で作成する新機能や、使用量のマイルストーンをモニタリングして請求リクエストを自動生成する新機能を確認できます。これらのツールを Earnings Potential Modeler と組み合わせると、コンテキストに応じて、利用可能なすべてのインセンティブを個々のクライアントレベルまでマッピングする推奨事項が提案されます。
パートナー検索ツール: このインテリジェンスをお客様にも拡張し、極めて具体的なワークロードに最適なパートナーを自然言語のプロンプトで特定できる会話機能を実現します。

最後に、Google Cloud の 2026 年パートナーアワードの受賞者をご紹介します。このアワードは、パートナー様が過去 1 年間にお客様にもたらした変革面の影響と素晴らしい価値を称えるものです。Google Cloud のエコシステムは、あらゆる業界のビジネスニーズに応えるために進化を続けています。Google Cloud のテクノロジーを使用してグローバル規模の複雑な課題を解決するパートナーの皆様の能力には、常に感銘を受けています。これらの優れた成果について詳しくは、パートナーアワード受賞者の一覧をご覧ください。

今週、数千人ものパートナーの皆様にお会いして、エージェント型エンタープライズの未来を一緒に構築できることを楽しみにしています。

- Google Cloud、グローバルエコシステム担当プレジデント、Kevin Ichhpurani

エージェントの未来を築く: メディアとエンターテイメント分野の Google Cloud パートナーエコシステムに注目

Fri, 24 Apr 2026 00:00:00 +0000

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

ラスベガスで NAB Show 2026 の開催が迫るなか、業界内の話題は変化しています。今は AI が機能するかどうかよりも、AI をいかにスケールさせるかに注目が集まっています。AI の試験運用の時代は終わり、本番環境グレードの実行の時代が到来しました。

Google Cloud は、スタジオや放送局がこの未来を単独で構築する必要はないと考えています。Google Cloud のミッションは、パートナー企業がアイデアを迅速にイノベーションにつなげられるエージェントプラットフォームと AI ツールやクラウドツールを提供することです。これは、編集スイートで使用するツールから、世界中の何百万人もの視聴者に動画を配信するテクノロジーまで、広範囲に及びます。

制作の強化: 手作業からインテリジェントなアシスタントへ

最新のクリエイティブワークフローは、手動の技術的タスクによってスピードが落ちることがよくあります。Google Cloud は、エコシステムのリーダー企業と協力して、高度な AI 機能を本番環境ソフトウェアのコアに直接統合しています。これにより、クリエイターは面倒な作業よりも、作品の芸術面に集中できます。制作チームは、クリエイティブスイート内で AI をプロアクティブなアシスタントとして活用することで、原案がフレームとして完成するまでの時間を大幅に短縮できます。

Avid は、Google Cloud 上で Content Core をリリースし、真のクラウドネイティブスタジオを提供しています。また、Media Composer にマルチモーダル AI 検索を統合しているため、編集担当者は自然言語を使用して必要なフレームを正確に見つけることができ、何時間もかかっていたログの検索が数秒で完了します。
Backlight は、制作から収益化まで、あらゆる規模のチームにとって複雑なメディアワークフローを簡素化します。Google Cloud と Video Intelligence API を基盤とする Backlight の Iconik プラットフォームは、アップロード時に検索可能なメタデータを自動的に追加します。お客様は、メディアライブラリを深く理解し、重複を減らし、アセットの配置を最適化することで、制作サイクルを最大 50% 短縮し、ストレージを最大 60% 節約できます。
Brahma AI は、小売、エンターテイメント、ヘルスケアの各分野で高忠実度のデジタルライクネスを推進するエンタープライズ AI コンテンツプラットフォームです。安全で管理されたフレームワーク内で、インタラクティブでインテリジェンス主導のデジタルライクネスを実現します。

コンテンツの価値向上: 静的なアーカイブからアクティブなアセットへ

データの価値は、そこから引き出せるインサイトによって決まります。Google Cloud Marketplace に掲載されているパートナー企業は、生成メディアモデルを使用して、膨大な静的アーカイブを検索可能で収益を生み出すエンジンへと変えています。Google Cloud は、すべてのフレームを検出可能にすることで、メディア企業が何十年分もの歴史を即座に機会に変えられるよう支援しています。

Ateme は、生成 AI を活用した新しい字幕ソリューションにより、グローバル配信を簡素化しています。このソリューションによって、さまざまなメディアタイプのローカライズにかかる手作業を大幅に削減できます。
Perfect Memory は、従来のストレージを、コンテキストを認識するナレッジエンジンへと変えるのに役立ちます。このプラットフォームは、アスリート、過去のイベント、感情のニュアンスの関係を理解し、膨大なメディアアーカイブをインテリジェントなライブラリに変換します。クリエイティブチームはあらゆるストーリーに最適なコンテンツを即座に探し出すことができます。
VionLabs は、Cineverse、Plex、Crunchyroll などの企業と連携し、AI を使用してコンテンツライブラリを分析、インデックス化することで、動画アセットへのアクセスを容易にし、メタデータの生成を可能にしています。Vionlabs は、各シーンの具体的なムードやスタイルを理解することで、ストリーミングプラットフォームが基本的なジャンル別タグの枠を超えて、より微妙な感情ベースのコンテンツの発見とマーケティングを実現できるよう支援します。

グローバルリーチへの拡大: シンプルなストリーミングから視聴者の拡大まで

この時代にメディア企業が成功するには、スムーズな視聴体験と簡単な支払い方法を提供する必要があります。Google Cloud のエコシステムは、信頼性と品質に優れた配信を通じて企業のリーチを拡大し、すべての視聴者の価値を最大化できるツールを提供しています。

Bending Spoons は、Google Cloud のグローバルな規模を活用し、Brightcove や Vimeo などの自社サービスを通じて、大企業、中小企業、次世代のクリエイターなどにプロフェッショナルグレードのツールを提供しています。同社のプラットフォームにより、グローバルブランドから独立系のストーリーテラーまで、誰もが質の高い動画を制作、配信できます。
Bitmovin は、ストリーミングサービスが効率的にスケールしながら、幅広いデバイスでプレミアムなエクスペリエンスを提供できるようにします。メディアチームは、リアルタイムのオブザーバビリティと AI による分析情報を組み合わせることで、エンゲージメントと収益化をプロアクティブに最適化できます。また、Bitmovin の高度なエンコードが、低ビットレートで優れた画質を実現し、需要の高いビデオオンデマンド（VOD）から大規模な 24 時間 365 日のライブ配信まで幅広くサポートします。
Evergent は、複雑な請求と収益化のワークフローを自動化し、AI を活用した収益管理を可能にします。メディア企業や通信企業は、Evergent のツールを使用して、個別の状況に応じたアジャイルな支払いオプションを用意することで、サブスクリプションの増加を最大化し、長期的な顧客維持率を向上させることができます。
Harmonic は、Grupo Globo などの大手放送局の業務のモダナイズを支援しています。新しいデジタル放送機能をクラウドベースのストリーミングソリューションに統合することで、リーダー企業が大規模な動画の処理と配信をより迅速かつ効率的に管理できるようにしています。

信頼性の確保: インフラストラクチャから信頼の基盤へ

高品質のコンテンツには、高性能の基盤が必要です。Google Cloud は、インフラストラクチャのリーダー企業と提携し、最も複雑なグローバルブロードキャストの安定性、安全性、応答性を確保しています。

Zixi は、プロフェッショナルな動画をあらゆるネットワーク上で移動するために必要となる放送レベルのトランスポートとワークフローの自動化を提供しています。Zixi は、制御の一元化と、配信プロセスに対する完全な可視性を提供することで、Fubo のようなリーダー企業が、信号が途切れるリスクを負うことなく、重要な放送品質のライブイベントを管理できるようにします。

エコシステムを実際にご覧ください

Google Cloud のエコシステムの強みは、メディアとエンターテイメントのあらゆる側面を統合していることです。カメラからクラウド、そして視聴者の画面まで、各パートナー企業が、よりクリエイティブで効率的、そして主体的なメディア業界の未来を体現しています。

4 月 19～22 日に開催される NAB Show で Google Cloud のブース（West Hall、#W2731）にお越しください。ライブデモやシアターセッションを通じて、多くのパートナー企業のソリューションをご覧いただけます。

- 通信、メディア、エンターテイメント、ゲーム担当グローバルリード、Anshul Kapoor

- Google Cloud、エンターテイメント業界ソリューション担当グローバルリード、Buzz Hays

大手消費者インサイトブランドが Dataproc を使用して高度なパーソナライズを加速している方法

Tue, 21 Apr 2026 01:00:00 +0000

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

RVU には、人々を支援し、業界を変革するという明確かつ重要な使命があります。

当社が展開している Confused.com、Uswitch、Tempcover、Money.co.uk、Mojo Mortgages などの市場をリードする家計管理ブランドや乗り換え支援ブランドにおいて、何よりも重要なのは透明性と正確な情報です。昨今の消費者は、単純な比較表以上のものを求めています。つまり、各消費者の状況に合わせたパーソナライズされたおすすめを求めているのです。

その期待に応えるには、すべてのブランドを支える真のパーソナライズエンジンを構築する必要があります。また、それを実現するには高度な ML モデル向けに膨大で複雑なデータセットを処理できるデータ基盤が必要です。現在、当社のプラットフォームはすべてのブランドから収集した数十億のデータポイントを活用して最適化した、数百もの自動化されたパーソナライズキャンペーンを支えています。この大規模なプラットフォームの構築には、Google Cloud と、Google Cloud が提供する Apache Spark 向けの 2 つのソリューション（Dataproc と Google Cloud Serverless for Apache Spark）を活用しました。Google Cloud を採用したことで、当社の使命は現実のものになりつつあります。

特徴量エンジニアリングのための高速エンジン

当社と Google Cloud の関係は今に始まったものではありません。当社は 10 年以上にわたり、統合データプラットフォームとして BigQuery を使用しています。パフォーマンスマーケティングのバックグラウンドを持つ当社では、常に大量のデータを扱ってきました。しかし、自社はデジタルインフラストラクチャ企業ではないという認識は早い段階からありました。どこに価値があるのかに常に注目しなくてはならないため、インフラストラクチャやキャパシティの問題に悩む必要がなくなる BigQuery のようなマネージドソリューションは、創業当初から私たちにとってまさにうってつけでした。

主な課題は、全ブランドにわたり、顧客の行動を意味のある一貫した全体像にまとめることでした。無数の断片的なインタラクションを、ユーザーの行動、クリック、意思決定の方法をそのまま反映したデータに変換する必要があったのです。単独のイベントや集計ビューを頼りにするのではなく、これらのシグナルを、当社の ML モデルが活用できる有用なナラティブとして取り込むことができるプラットフォームを構築する必要がありました。

これを実現するために Dataproc を利用できたことは、実に画期的でした。Dataproc が最も効果を発揮したのは、主に ML モデル開発の特徴量エンジニアリングを目的とした、高速 Spark 処理エンジンとしての役割です。膨大な未加工の顧客データをデータサイエンスモデルが活用できる形へと変えていく「特徴量エンジニアリング」は、まさに当社の価値を高める要素であり、Google が大きな競争優位性を持つ分野です。

その結果、イノベーションの速度が大幅に向上しました。Serverless for Apache Spark を使用することで、わずか数日で特徴量エンジニアリング用に顧客データを整形できるようになりました。以前は数週間かかっていた作業です。製品化までの時間も、数週間かかっていたのが大幅に短縮されました。今では、チームに新たに加わった契約社員でも、探索的データ分析やすべての特徴量エンジニアリングを含むモデルをわずか 1 週間半で提供することができます。これはものすごいスピードです。

パーソナライズされたエクスペリエンスの提供

イノベーションのスピードを向上させることで、お客様やパートナーに、よりパーソナライズされたユーザーエクスペリエンスを提供できるようになりました。

Spark への移行後、高度なパーソナライズへの取り組みは加速しました。膨大な行動データやコンテキストデータを処理する大規模なデータ処理ジョブを実行して、真に有意義な予測を生成するモデルを構築できるようになりました。

これらのモデルは、お客様に何を言うべきかだけでなく、いつ、どのように言うべきかを理解できるようサポートしてくれます。これにより、適切なタイミングと適切なチャネルを選んで、お客様の心に響くパーソナライズされた情報を提供することができます。

未来のビジョンを築く

Google のデータクラウドは、価値を優先するという当社の文化とまさに合致しており、ビジネスに大きな影響を与えています。私はこれを、すべてが同じエコシステム内でシームレスに接続されるネットワーク効果と呼んでいます。当社のデータは BigQuery に存在し、そのデータを検証、拡充、変換する能力は Dataproc と Serverless for Apache Spark に紐付けられ、ML モデルをデプロイする機能はこのネットワーク全体に及んでいます。すべてが連携し統合されているため、当社の消費者ブランドのリアルタイムでの精度を高め、競争優位性を確保することができるのです。

エンジニアにとっての大きなメリットは、インフラストラクチャを扱う必要がないことです。クラスタやサーバーのネットワークを設定して相互に通信させる必要はなく、ボタンを押すだけで 10 分以内にすべてのデータを処理できます。非常に効率的で、データプロダクトの構築やイテレーションなど、より価値の高い作業に時間を割くことができます。

Dataproc のおかげで、スピード、スケール、アジリティが向上しました。また、AI を活用してイノベーションを起こし、高度なパーソナライズの未来を築くためのツールも提供されます。現在、RVU の最先端のテクノロジーとデータは、英国の何百万人もの消費者がよりスマートに十分な情報に基づいて意思決定できるようサポートし、まさに業界を変革しようとしています。

RVU の成功から何かヒントを得られましたでしょうか。Dataproc を使用した永続的なクラスタが必要な場合も、サーバーレス Spark のアジリティが必要な場合も、Google Cloud ならインフラストラクチャではなく価値に集中できるマネージドソリューションを見つけることができます。ユースケースに適した Google Cloud 上の Spark をご確認ください。

- RVU、データエンジニアリング責任者、Siddharth Dawara 氏

一元化されたポリシーと分散ロジック: Eventarc Advanced の概要

Tue, 17 Mar 2026 01:00:00 +0000

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

エンタープライズアーキテクトは、開発者のアジリティと組織の管理のどちらを優先するかという根本的なジレンマに直面することがよくあります。開発チームは、迅速に作業し、許可を待つことなく独立したマイクロサービスをデプロイする必要があります。セキュリティチームとコンプライアンスチームは安全を確保し、データフローが可視化され、ポリシーによって管理されるようにする必要があります。

そこで、Google はサーバーレスのイベント処理プラットフォームである Eventarc Advanced を構築しました。これは Eventarc Standard の進化版です。Eventarc Advanced は、一元化されたポリシーと分散されたロジックを組み合わせることで、最新のクラウド向けに改善されたアーキテクチャパターンを提供します。Eventarc Advanced では、ガバナンスレイヤ（「バス」）と処理レイヤ（「パイプライン」）を明確に分離することで、SecOps チームが求める可視性と制御を実現する一方で、開発者が AI エージェントを調整してイベントドリブンアプリケーションを自律的に構築できるようにしています。Eventarc Advanced は 2025 年 8 月に一般提供されました。

この投稿では、インテグレーションアーキテクチャの変遷（サービスバスから、マイクロサービス、現在に至るまで）について見ていくとともに、実例を挙げながら解説します。それでは詳しく見ていきましょう。

インテグレーションアーキテクチャの進化

新しいパターンの価値を理解するために、これまでの経緯と、以前のアーキテクチャパターンで妥協を余儀なくされた点について確認しておきましょう。

エンタープライズサービスバスにおける集中的なボトルネック

インテグレーションアーキテクチャの初期のアプローチの一つに、エンタープライズサービスバス（ESB）があり、これは、一元管理を優先していました。ESB は、ポイントツーポイントのインテグレーションにおける「スパゲッティアーキテクチャ」を解決するために登場しました。具体的には、異種システム間のやり取りを標準化する一元化された通信レイヤを提供します。しかし、多くの場合、重大な落とし穴がありました。

主な問題は、一元化されたロジックのトラップと呼ばれるものです。変換やオーケストレーションなどの複雑なビジネスロジックがガバナンスレイヤに直接埋め込まれることが多く、その結果、ミドルウェアレイヤが不透明になり、サービスを所有する開発者側から重要なビジネスルールが見えない状態になりました。

そのため、インテグレーションの変更に、中央のミドルウェアチームが介入しなければならないのが一般的でした。開発チームは自律性を失い、インテグレーションスペシャリストの順番待ちを強いられ、小さな機能でさえリリースに数週間かかることがよくありました。

マイクロサービスのガバナンスの盲点

これに対処するため、業界はマイクロサービス（通称「スマートエンドポイントとダムパイプ」）へと移行し、ロジックを分散してチームが求めていた自律性を実現しました。同期トラフィック（REST、gRPC）では、API ゲートウェイやサービスメッシュなどのツールによってインフラストラクチャレベルで認証やレート制限などのポリシーを適用することで、ガバナンスレイヤを復元できます。

しかし、アーキテクチャがレジリエンスと分離を強化するためにイベントドリブンアーキテクチャ（EDA）へと移行するにつれ、新たな課題が生じました。分散された非同期環境では、一元管理が失われることがよくあり、SecOps チームが秩序を維持するのに苦労するというガバナンス上の課題が生まれたのです。問題となったのは、以下の 3 点です。

可視性の欠如: 一元的なポリシーがないと、シャドー IT サービスが検出されずに機密性の高いイベントをひそかにサブスクライブする可能性があります。
ポリシーの問題: ブローカーが個々のメッセージを不透明な blob として扱う場合、データ所在地や PII マスキングを適用することはほぼ不可能です。
依存関係のリスク: 明示的な取り決めなしにイベントスキーマを変更すると、ダウンストリーム側の不明なコンシューマーがいつのまにか破損されるリスクがあります。

新しいパターン: ポリシーは一元化、ロジックは分散

Eventarc Advanced は、一元化されたポリシーと分散ロジックという新しいアーキテクチャパターンにより、制御とスピードの両立という課題に対処しています。

Eventarc Advanced では、これらの異なる責任を 2 つの特定のアーキテクチャリソースにマッピングします。各リソースはそれぞれ、以下の異なるロールに対応しています。

バス: このガバナンスレイヤは、イベントがルーティングされる前にプラットフォーム管理者がグローバルな制約を適用する、一元管理用のハブです。これは、従来の ESB の一元化されたルーティングと、サービスメッシュの最新のセキュリティアーキテクチャを統合したものです。Identity and Access Management（IAM）やそのコンテンツベースのアクセス制御を処理し、誰にパブリッシュを許可するかを厳密に定義して、VPC Service Controls と連携しながらデータ引き出しを防止できます。
パイプライン: この分散型のチーム所有リソースは、いわば、開発者のインテグレーションロジックレイヤです。このレイヤで、AI エージェントとマイクロサービスのイベント処理パターンが自由に解放され、開発者は特定のビジネスロジックに従ってイベントフローと配信を構成できます。データを不透明なビットとして扱う多くのサービスメッシュとは異なり、このパイプラインはコンテンツを理解します。開発者は、イベントの変換、ペイロードの形式変換（JSON から Avro など）、再試行ポリシーおよび認証の構成を独立して行うことができます。

つまり、Eventarc Advanced はこれらの役割を分離することで、ESB の制御、マイクロサービスのアジリティ、最新型のイベントドリブンアーキテクチャのレジリエンスをすべて実現しています。

仕組み: 小売業のイベントメッシュの例

一般的な Eventarc Advanced ソリューションは最小限の構成で実装でき、管理ガバナンスと分散インテグレーションロジックの両方で合理化されたエクスペリエンスを提供します。このモデルが実際にどのように機能するかを、小売業のイベントメッシュの事例で見てみましょう。

例として、グローバルな小売業者のエコシステムについて考えます。4 つの自律的な部門があり、それぞれ以下のサービスを担当しています。

コマース

財務

物流

インテリジェンス（AI インサイトエージェント）

従来の方法では、これらの部門を連携させるのは困難です。インテリジェンス部門はモデルの全データにアクセスしたいと考えます。一方、財務部門はコンプライアンスのためにすべてのデータをロックする必要があります。物流チームは出荷のために安定したスキーマを求めています。コマース部門は新しい機能を即座にリリースする必要があります。

基盤: CloudEvents 上に構築

Eventarc Advanced は、オープンな CloudEvents 標準に基づくデータモデルを使用しており、あらゆる種類のペイロードに対応できます。そのため、柔軟性を維持しながら、ガバナンスおよび検出可能性を確保することが可能です。この例では、プラットフォーム管理者によって、単一イベントをパブリッシュする前に、すべてのメッセージに標準属性およびガバナンス用のカスタム拡張属性を含めることが義務付けられているものとします。

この例では、バス上のすべてのイベントに次の属性を含める必要があります。

type: イベントインスタンスの標準識別子（例: com.retail.order.created）
source: プロデューサーを識別する標準属性（例: //commerce/frontend）
data_sensitivity: リスクを分類するカスタム拡張属性

さらに、この組織では 3 種類のデータ機密性レベルを定義しています。

restricted （高）: クレジットカードのトークンや納税者番号などの高リスクデータ
confidential （中）: 自宅住所などの個人情報（PII）
general （低）: 注文 ID などの安全な運用データ

この標準化されたメタデータレイヤにより、特定の属性名に基づいてバスからポリシーを適用することが可能となります。具体的には、データの送信元（source）とデータの種類（data_sensitivity）をチェックできます。

ワークフロー

このモデルは、単一の注文のライフサイクルにおいて、機密性がステップごとに変化する安全なフローとなります。

注文: Commerce（コマース）サービスが order.created をバスにパブリッシュします。このイベントのデータ機密性は general とタグ付けされています。AI Insights Agent（AI インサイトエージェント）サービスは、市場のトレンドを分析するために、この情報をサブスクライブします。
支払い認証: Commerce サービスが payment.authorized をパブリッシュし、restricted タグを付けます（セキュアトークンが含まれます）。Finance（財務）サービスが、このトークン取得をサブスクライブして、請求処理を実行します。
決済: Finance サービスが payment.success をパブリッシュし、general タグを付けます。これが、出荷に進んでよいという合図になり、財務上の機密情報は隠されたままになります。Logistics（物流）が出荷のためにこれをサブスクライブします。また、Intelligence AI Insights Agent（インテリジェンス AI インサイトエージェント）がトリガーされて、次のサプライチェーンサイクルの市場動向を評価します。
出荷: Logistics サービスが shipment.ready をパブリッシュし、confidential タグを付けます（お客様の電話番号が含まれます）。Logistics が自らの通知パイプラインによってこれをサブスクライブし、SMS 通知をトリガーします。

従来のアーキテクチャだと、PCI、PII、運用のデータが単一バスに混在し、コンプライアンスの面で非常に複雑になりますが、Eventarc Advanced を使用すれば、この問題は解決します。

バス: ガバナンスレイヤ

プラットフォーム管理者は、バスに安全な戦略を実装できます。たとえば、内部サービスをむやみに信頼するのではなく、グローバルポリシーによってきめ細かなアクセス制御（FGAC）を適用し、CloudEvents 属性を検査することができます。

ソースの整合性の検証

サービスの侵害によるイベントのスプーフィングを防ぐため、バス管理者は、プロデューサー ID とソース属性の一致を求めます。

たとえば、プリンシパル sa-commerce@retail.com のみに、message.source.startsWith("//commerce/") という表記に一致するイベントのパブリッシュを許可するようにバスポリシーを設定できます。仮に Intelligence AI Insights Agent サービスが //commerce/payments からであると偽ってイベントをパブリッシュしようとすると、バスはこのリクエストを拒否します。

データ分類の検証

バス管理者は、すべてのイベントを機密性に基づいて分類できるようにするために、バスに送られるすべてのペイロードに有効な機密性属性を求めます。バスポリシーに、message.data_sensitivity が ['general', 'confidential', 'restricted'] のいずれかであるかどうかを検証するよう指定できます。これにより、イベントメッシュにはガバナンス対応の分類済みデータのみが確実に含まれるようになります。

パイプライン: ロジックレイヤと、自律的なチームのイノベーション

バスでセキュリティポスチャーを確立する一方で、開発チームはパイプラインを使用し、複雑なインテグレーションの課題を独自のドメイン内で解決できます。具体的にどんな課題があるのかを見てみましょう。

スキーマに対応した形式変換とペイロードの変換

物流部門は、高効率のプロトコルバッファを使って倉庫ロボットをアップグレードすることにしました。財務部門に JSON 出力の変更を強制すると、他のコンシューマーが壊れる可能性があるため、その代わりに、物流部門が独自のパイプラインを使って変換ステップを構成できます。

財務部門からの一般的な com.retail.payment.success イベントは、次のような JSON として届きます。

code_block: <ListValue: [StructValue([('code', '{\r\n "id": "89d5663e-789e-4d9f-a65f-f7d83742d987",\r\n "source": "//finance/ledger",\r\n "type": "com.retail.payment.success",\r\n "data_sensitivity": "general",\r\n "datacontenttype": "application/json",\r\n "data": {\r\n "order_number": "ORD-2023-8841",\r\n "total_amount": 249.99,\r\n "currency": "USD",\r\n "transaction_id": "tx_77382910",\r\n "status": "SETTLED"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f42dd8c4880>)])]>

倉庫ロボットサービスは、次のようなバイナリの Protobuf メッセージを想定しています。

code_block: <ListValue: [StructValue([('code', 'message PaymentConfirmed {\r\n string order_id = 1;\r\n double insured_value = 2;\r\n string currency_code = 3;\r\n string ledger_reference = 4;\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f42dd8c4d90>)])]>

物流部門は、json を入力として受け付け、Protobuf に出力するようにパイプラインを構成します。データをマッピングするために、以下のように Common Expression Language（CEL） を使って変換を構成しています。

code_block: <ListValue: [StructValue([('code', '// CEL 変換によって、ターゲットの Protobuf メッセージを構築\r\n{\r\n "order_id": message.data.order_number,\r\n // 交換費用をカバーするため、総額の 110% にする\r\n "insured_value": message.data.total_amount * 1.1,\r\n // 通貨を大文字に統一\r\n "currency_code": message.data.currency.upperAscii(),\r\n "ledger_reference": message.data.transaction_id,\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f42dd8c4ac0>)])]>

この変換では、入力のマッピングだけでなく、ビジネスロジックも適用され、保険適用後の金額計算と通貨コードの正規化が行われています。物流部門は、財務部門と打ち合わせを一切することなく、このモダナイゼーションを実装できます。

エージェントのワークフロー: AI エージェントのフィルタとトリガー

Eventarc Advanced では、Agent2Agent（A2A）や Model Context Protocol（MCP）などのオープンスタンダードプロトコルを使って、パイプラインが AI エージェントと直接通信できるようにし、エージェントのワークフローを実現しています。また、フィルタなどの豊富な機能もあり、エージェントの呼び出しタイミングを最適化できます。

インテリジェンス部門は、ai-insights と名付けたパイプラインと A2A プロトコルを使用して AI インサイトエージェントに接続し、注文に基づいて市場動向をプロアクティブに分析してもらえます。エージェントの処理はリソースを大量に消費するため、フィルタを使用して、詳細な分析が必要な高額注文に対してのみエージェントを呼び出すことができます。

パイプラインフィルタを、次のように構成します。

code_block: <ListValue: [StructValue([('code', 'message.type == "order.created" && \r\ndouble(message.amount) > 5000.0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f42dcb101f0>)])]>

フィルタが渡されると、パイプラインは HTTP Message Destination Binding（MDB）の構文を使ってエージェントを直接トリガーします。CEL テンプレートを定義することによって、ネイティブな A2A SendMessage リクエストを構築して戦略担当の AI インサイトエージェントに送るという複雑な処理をパイプラインで行えます。これにより、手動で「グルーコード」を作成することなく、複雑なイベントデータから派生した会話型プロンプトをエージェントに送信することができます。

code_block: <ListValue: [StructValue([('code', '{\r\n "headers": headers.merge({ "Content-Type": "application/json", "A2A-Version": "1.0" }),\r\n "body": {\r\n "jsonrpc": "2.0",\r\n "id": message.id,\r\n "method": "message/send",\r\n "params": {\r\n "message": {\r\n "messageId": message.id,\r\n "role": "ROLE_USER",\r\n "parts": [\r\n { \r\n "text": "Analyze Order " + message.data.order_number + " for market trends." \r\n }\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f42dd5707f0>)])]>

MCP などの他の一般的なエージェント通信プロトコルでも、同様のプロンプトメッセージを作成できます。

フィルタとエージェントプロトコル変換を組み合わせることで、AI リソースを本当に必要な場面で有効利用することが可能となります。インテリジェンス部門は、取り込みコードを記述したり、コマース部門や管理部門と調整したりすることなく、独自にこれを実装できます。さらに、エージェントが独自の戦略的推奨事項をバスにパブリッシュし、AI の知見を適宜活用できるようにすることで、一般的なクラウドイベントが競争に役立つインテリジェンスへと生まれ変わります。

高度な API リクエストモデリング

出荷の準備が整うと、物流部門はパイプラインからレガシーのゲートウェイ API を使って SMS を送信します。サードパーティのレガシー API と統合するためには、リクエストの書式設定のために、「グルーコード」サービスの記述が必要となるのが一般的です。

物流部門は、レガシーサービスが想定しているリクエストを正確に記述するために専用のパイプラインを構成することで、このメンテナンスの負担を解消しています。

具体的には、HTTP Message Destination Binding の CEL 構文を使って、電話番号を標準化し、API で必須の X-SMS-To HTTP ヘッダーにマッピングします。また、以下のように SMS テキストも作成します。

code_block: <ListValue: [StructValue([('code', '{\r\n "headers": { "X-SMS-To", \r\n message.data.phone.matches(\'^\\\\+1\') ?\r\n message.data.phone : \r\n \'+1\' + message.data.phone \r\n },\r\n\r\n "body": {\r\n "sms_text": "Order " + message.data.order_id + " shipped!"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f42dd570e50>)])]>

最後に、パイプラインに直接、堅牢な再試行ポリシー（線形バックオフ、最大 5 回の試行）を構成して、一時的なネットワーク中断によって通知が失われないようにします。このパイプラインは、確実な配信を実現するほか、すぐに使える認証を提供します。宛先として、HTTP エンドポイントのほか、Cloud Run、Pub/Sub、バス、ワークフローや、200 以上の Google サービスがサポートされています。

アジャイルなインテグレーションに向けた未来

Eventarc Advanced は、一元化ポリシー、分散型ロジックのパターンを導入することで、イベントドリブンアーキテクチャにおける重要な盲点に対処し、非同期通信において同期通信と同レベルの成熟度を達成しています。

プラットフォームチームは、バスですべてのメッセージに整合性と機密性を厳格に適用することで、あたかもサービスメッシュのようなセキュリティをイベントレイヤに導入できます。
開発者は、自律性を取り戻せます。パイプラインを使って、特定のニーズに応じてイベントをフィルタ、変換、形式変換、ルーティングできるため、イベントを不透明なアーティファクトではなく、重要な産物として扱うことが可能となります。

このアーキテクチャは、次世代のインテリジェントアプリケーションの基盤となります。安全で定型化された、信頼できるイベントメッシュは、生成 AI エージェントおよびリアルタイム分析の基軸となり、ビジネスコンテキストを必要とするシステムに安全に公開することが可能となります。

使ってみる

ガバナンスに足を引っ張られることなく、イノベーションを促進しましょう。Eventarc Advanced の使用を開始するにあたっては、以下のリソースをご利用ください。

詳細: Eventarc Advanced のドキュメントで、バスとパイプラインの全機能をご確認ください。
実践: 「小売業のイベントメッシュ」のシナリオを自分でデプロイしてみましょう。また、クイックスタートとチュートリアルでエンタープライズのパターンについて理解を深められます。
構築してみる: Google Cloud コンソールを開き、初めてのバスとパイプラインをさっそく構成してみましょう。
ご相談ください: 複雑なエンタープライズユースケースがおありですか？Google Cloud の営業担当者までお問い合わせください。Eventarc Advanced がお客様の広範なインテグレーション戦略にどのように役立つかについて、ご説明させていただきます。

- スタッフソフトウェアエンジニア、Milen Kovachev

Replit が Google Cloud でエンタープライズグレードのバイブコーディングを提供

Fri, 19 Dec 2025 01:10:00 +0000

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

バイブコーディングは今年大ブームになりました。AI を使用してチャットインターフェースに会話形式で入力するだけで、斬新なアプリを作成したり、動的なウェブサイトを構築したりできるのは、魔法のように思えるかもしれません。しかし、この動きは主に個人の開発者の領域にとどまっており、大規模なビジネスチームの領域では普及していませんでした。

このたび、Replit と Google Cloud は戦略的パートナーシップを拡大し、企業の開発者と開発チームにバイブコーディング機能を提供します。

Replit にとって、Google Cloud は初めてのクラウドパートナーでした。同社の AI コーディング向けの人気のあるプラットフォームは Google Cloud のインフラストラクチャ上で運用され、複数の Google Cloud サービスを利用しています。また、Vertex AI を通じて Google の Gemini モデルの統合を進めています。

Replit は、Google Cloud とのパートナーシップを拡大し、インフラストラクチャとクラウドサービスの利用を拡張する新たな複数年契約を締結しました。これにより、プラットフォームへの Google のモデルの統合をさらに推し進め、企業のお客様向けのバイブコーディングユースケースを共同でサポートします。先月、Replit は Gemini 3 を新しい設計モードに統合して、好評を博しました。パートナーシップ拡大契約には次のような条項があります。

Google Cloud は今後も Replit の主要なクラウドプロバイダであり続けます。Google Cloud Run、Google Kubernetes Engine、BigQuery などのサービスで Replit のアプリケーションの基盤を支え、会社の成長に伴うさらなるスケーリングを可能にします。
Gemini 3、2.5 Flash Lite、2.5 Flash、Imagen 4 などの Google モデルが Replit でサポートされるようになります。これにより、コーディングとマルチモーダルの両方のユースケースが拡充され、Google Cloud のトークンの使用量が大幅に増加します。
Replit と Google Cloud は、Google Cloud Marketplace での共同市場開拓と Google Cloud の広範な共同販売プログラムを通じて、企業のお客様がバイブコーディングを採用し、開発者が生産性を高められるよう連携して支援します。

Google Cloud の CEO である Thomas Kurian は、次のように述べています。「パートナーシップの拡大により、Google AI およびクラウドサービスとの緊密な統合を通じて、Replit のユーザーにさらに多くの機能を提供する予定です。また、Google Cloud AI を活用した Replit の使いやすい AI ツールをより多くの組織に提供することで、企業におけるバイブコーディングの導入を加速させます。」

Replit の共同創業者兼 CEO である Amjad Masad 氏は、次のように述べています。「私たちの使命は、趣味で開発を行っている方から起業家や企業まで、あらゆるソフトウェアクリエイターをさらに 10 億人支援することです。この数か月の間に、特に Fortune 1000 企業において、驚くほどの普及が進みました。今回 Google とのパートナーシップを拡大したことで、Google のサービスと当社のサービスの統合を進めて、より迅速かつ完全なスケーリングが可能になります。これはまだ始まりにすぎません。」

コーディングユースケースで Google AI モデルを活用しているお客様の事例について詳しくは、こちらをご覧ください。Replit やその他のお客様のように、Vertex AI を使用して Gemini 3 を構築しましょう。

-Google Cloud、社長兼最高収益責任者、Matt Renner

Google Cloud でのカオスエンジニアリング: 原則、実践、開始方法

Mon, 27 Oct 2025 01:30:00 +0000

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

エンジニアであれば誰でも、完璧な復元力を持つシステムを夢見ます。完璧にスケーリングし、優れたユーザーエクスペリエンスを提供し、決してダウンしないシステムです。このような復元力のあるシステムを構築する鍵が、障害を回避することではなく、意図的に障害を引き起こすことだとしたらどうでしょうか。カオスエンジニアリングの世界へようこそ。ここでは、管理された環境でシステムにカオス（障害）を導入して、システムにストレステストを行います。ダウンタイムが数百万ドルの損失につながり、評判が瞬く間に失墜する時代において、最も革新的な企業としては、災害が起こるのをただ待っているだけではいけません。災害を意図的に引き起こし、その結果として生じる障害から学び、本番環境で混乱が起こる前に混乱に対する免疫を獲得して行くのです。

カオスエンジニアリングはあらゆる種類のシステムに役立ちますが、特にクラウドベースの分散システムに有効です。最新のアーキテクチャは、モノリシックなシステムからマイクロサービスベースのシステムへと進化し、多くの場合、数百から数千のサービスで構成されています。このように複雑なサービス依存関係は、複数の障害点をもたらします。また、従来のテスト方法では、あらゆる障害モードを予測することは、不可能ではなくても、困難です。これらのアプリケーションをクラウドにデプロイすると、複数のアベイラビリティゾーンとリージョンにデプロイされます。クラウド環境は分散性が高く、多数のサービスが共存しているため、障害の発生する可能性が高くなっています。

良くある誤解ですが、クラウド環境ではアプリケーションには自ずと復元力があるので、テストは不要であるというものがあります。クラウドプロバイダは、クラウドプロダクトに対してさまざまなレベルの復元力と SLA を提供していますが、これだけではビジネスアプリケーションが保護されるとは限りません。アプリケーションがフォールトトレラントになるように設計されていない場合や、クラウドサービスが常に利用可能であることを前提としている場合、依存している特定のクラウドサービスが利用できなくなると、アプリケーションは動作しなくなります。

手短に言えば、カオスエンジニアリングは、担当者にとって最悪の「もしも」のシナリオを想定し、それに対する対応を十分にリハーサルできるようにします。カオスエンジニアリングは、システムを破壊すること（いわばカオスなエンジニアリング）ではありません。カオスエンジニアリングは、管理された条件下とはいえ、すでにカオスを乗り切った経験から得られる冷静な自信を持って本番環境のインシデントに対処できるチームを構築することです。

Google Cloud の Professional Service Organization（PSO）エンタープライズアーキテクチャチームは、アプリケーション開発、クラウド移行、エンタープライズアーキテクチャなど、お客様のクラウド変革の取り組みについてコンサルティングを行い、実践的な専門知識を提供しています。また、クラウド環境向けの復元力のあるアーキテクチャの設計についてアドバイスする際には、カオスエンジニアリングの原則とプラクティス、およびサイト信頼性エンジニアリング（SRE）のプラクティスを定期的に紹介しています。

シリーズの最初になるこのブログ投稿では、カオスエンジニアリングの基本、つまりカオスエンジニアリングとは何か、そのコアとなる原則と要素について説明します。次に、クラウドで分散アプリケーションを実行しているチームにとって、カオスエンジニアリングが特に役立ち、重要である理由を説明します。最後に、これを活用開始する方法と、その他のリソースについて説明します。

カオスエンジニアリングについて

カオスエンジニアリングは、Netflix が 2010 年に考案した手法です。AWS 環境の複雑度が上がる中、より復元力と信頼性が高いシステムを構築する必要性に対処するため、「Chaos Monkey」を作り出し、普及させました。同じ頃、Google は障害復旧テスト（DiRT）を導入しました。これにより、Google のビジネス、システム、データの継続的て、自動的な障害対策、対応、復旧が可能になりました。Google Cloud の PSO チームでは、お客様が SRE プラクティスの一環として DiRT を実装できるよう、さまざまなサービスを提供しています。これらのサービスには、Google Cloud で動作するアプリケーションやシステムで DiRT を実行する方法に関するトレーニングも含まれています。中心となるコンセプトは単純です。管理された障害を意図的にシステムに導入して、脆弱性を特定し、その復元力を評価し、全体的な信頼性を高めるというものです。

予防的な手法であるカオスエンジニアリングにより、組織はシステム内の弱点を、大規模なサービス停止や障害につながる前に特定できます。ここで言うシステムには、技術的なコンポーネントだけでなく、組織の人員やプロセスまでも含まれます。カオスエンジニアリングでは、管理された、実際の停止状態を導入することで、システムの堅牢性、復元可能性、フォールトトレランスをテストできます。このアプローチによって担当者は潜在的な脆弱性を発見できるため、システムは予期しないイベントに対処し、ストレス下でもスムーズに機能し続けることができます。

カオスエンジニアリングの原則と実践

カオスエンジニアリングは、これを実施すべき理由に関する一連の基本原則によって導かれ、また実践は実施すべき内容を定めます。

カオスエンジニアリングの原則は次のとおりです。

定常状態に関する仮説を立てる: 停止を引き起こすアクションを開始する前に、システムにとっての「正常」な状態がどのようなものかを決定する必要があります。これは一般に「定常状態仮説」と呼ばれます。
現実世界の状況を再現する: カオステストでは、本番環境でシステムが遭遇する可能性のある現実的な障害シナリオをエミュレートします。
本番環境でテストを実行する: カオスエンジニアリングは、実際のトラフィックと、依存関係の両方がある本番環境でのみ復元力の正確な全体像を把握できるという信念にしっかりと根ざしています。これが、カオスエンジニアリングと従来のテストの違いです。
テストの自動化: 復元力テストを、一度限りのテストではなく、継続的なプロセスの一部にします。
影響範囲を特定する: 本番環境システムへの悪影響を最小限に抑えるために、テストは綿密に設計する必要があります。そのためには、テストが顧客や他のアプリケーション、サービスに与える影響に基づいて、アプリケーションとサービスをさまざまな階層に分類する必要があります。

これらの原則を確立したら、カオスエンジニアリングのテストを実施する際に次の手法に従います。

定常状態を定義する: 注目する特定の指標（レイテンシ、スループットなど）を特定し、それらのベースラインを確立します。
仮説を立てる: これは、テスト可能な単一のステートメントを作成する手法です。たとえば、「このコンテナ Pod を削除しても、ユーザーのログインには影響しない」などです。仮説は通常、お客様のユーザージャーニーを特定し、そこからテストシナリオを導き出すことで作成されます。
管理された環境を使用する: カオスエンジニアリングの原則の一つに、テストは本番環境で実行する必要があるというものがありますが、まずは小規模に始め、非本番環境でテストを実行し、学び、調整してから、徐々に本番環境に範囲を拡大するようにしてください。
障害の注入: これは、システムに直接（VM の削除、データベースインスタンスの停止など）または環境に間接的に（ネットワークルートの削除、ファイアウォールルールの追加など）障害を注入して、停止状態を引き起こす手法です。
テストの実行を自動化する: カオスエンジニアリングを再現可能でスケーラブルなプラクティスとして確立するには、自動化が不可欠です。これには、障害注入に自動ツールを使用すること（CI/CD パイプラインの一部にするなど）や、自動ロールバックメカニズムを使用することが含まれます。
行動につながるインサイトを導き出す: カオスエンジニアリングを使用する主な目的は、システムの脆弱性に関するインサイトを導き出し、それによって復元力を高めることです。これには、テスト結果の厳密な分析、弱点と改善すべき点の特定、関連チームへのテスト結果の周知が含まれ、これによってその後のテスト設計とシステム強化を行います。

つまり、カオスエンジニアリングは、単にシステムを壊すことが目的ではなく、システムの限界を理解し、それらに事前に対処することで、より復元力の高いシステムを構築することが目的です。

カオスエンジニアリングの要素

カオスエンジニアリングテストで使用するコア要素は、次の 5 つの原則から導き出されます。

テスト: カオステストは、システムに障害を発生させてその応答を確認する、意図的で事前に計画された手順で構成されます。
定常状態仮説: 定常状態仮説は、評価対象のシステムのベースラインとなる運用状態、つまり「正常」な動作を定義します。
アクション: アクションは、テスト対象のシステムに対して実行される具体的なオペレーションを表します。
プローブ: プローブは、テスト中にシステム内で定義された条件を観察するメカニズムを提供します。
ロールバック: テストでは、テスト中に実装された変更を元に戻すように設計された一連のアクションが組み込まれる場合があります。

カオスエンジニアリングを開始する

カオスエンジニアリングと、クラウド環境でカオスエンジニアリングを使用する理由について理解を深めたら、次のステップとして、独自の開発環境で実際に試してみましょう。

市場には複数のカオスエンジニアリングソリューションがあります。有料のプロダクトもあれば、オープンソースのフレームワークもあります。すぐに始めるには、Chaos Toolkit をカオスエンジニアリングフレームワークとして使用することをおすすめします。

Chaos Toolkit は、Python で記述されたオープンソースのフレームワークです。モジュール式のアーキテクチャが提供されており、他のライブラリ（「ドライバ」とも呼ばれます）をプラグインして、カオスエンジニアリングのテストを拡張できます。たとえば、Google Cloud、Kubernetes、その他多くのテクノロジーの拡張ライブラリがあります。Chaos Toolkit は Python ベースの開発者ツールであるため、まず Python 環境を構成します。Chaos Toolkit のテストの優れた例と、その手順については、こちらをご覧ください。

最後に、Google Cloud のお客様とエンジニアがアプリケーションにカオステストを導入できるように、特に Google Cloud のための一群のカオスエンジニアリングレシピを作成しました。各レシピには、特定の Google Cloud サービスにカオスを導入する特定のシナリオを収めています。たとえば、あるレシピでは Google Cloud の内部または外部アプリケーションロードバランサの背後で実行されているアプリケーション/サービスにカオスを導入し、また別のレシピでは ToxiProxy という別の Chaos Toolkit 拡張機能を利用して、Cloud Run で実行されているアプリケーションと Cloud SQL データベースに接続するアプリケーション間のネットワーク停止をシミュレートします。

Google Cloud 環境にカオスエンジニアリングを導入する方法を学ぶための、手順ガイド、スクリプト、サンプルコードを含むレシピの完全なコレクションは、GitHub にあります。今後の投稿では、Google Cloud 環境に障害を導入する方法など、カオスエンジニアリングの手法を取り上げますので、ご期待ください。

-Parag Doshi、キーエンタープライズアーキテクト

製薬業界の開発を変革する中外製薬の挑戦：Gemini Code Assist 活用で開発速度は最大 5 倍に

Wed, 22 Oct 2025 02:00:00 +0000

日本の製薬業界をリードする中外製薬株式会社（以下、中外製薬）は、Google の AI、Gemini を活用したコーディングエージェント「Gemini Code Assist」を導入し、開発プロセスに大きな変革をもたらしています。臨床開発からアジャイルなソフトウェア開発、データサイエンスまで、多様な分野で Gemini Code Assist がどのように活用され、どのような成果を上げているのか、具体的な事例を交えてご紹介します。

今回お話を伺ったのは、多様な立場で Gemini Code Assist の活用を推進する 3 名のキーパーソンです。バイオメトリクス部で AI を活用した臨床開発を推進する高野様。デジタルソリューション部アジャイル開発グループで、全社向け生成 AI アプリ「Chugai AI Assistant」などを開発する尾形様。そして、デジタルソリューション部データサイエンスグループで、データサイエンスの観点から AI モデルの精度改善や創薬研究支援まで幅広く手がける水谷様。それぞれの視点から、具体的な取り組みについて語っていただきました。

属人化と心理的ハードル、AI 導入前の開発課題

Gemini Code Assist 導入以前、中外製薬の開発現場ではいくつかの課題に直面していました。

臨床開発部門の高野様は、「ビジネスサイドである臨床部門では、アプリケーション開発ができる人材が限られており、新しいアプリケーション開発に対する心理的なハードルが高かった」と語ります。「従来は 1 つのアプリケーションを開発するだけでも相当な工数がかかり、じっくりと要件をヒアリングして、効果があるものなのかを精査した上で企画書にまとめてから作り始めるというプロセスを踏んでいました。特に外部へ委託する案件では、効果の定量化やマネジメント承認といったハードルがさらに高くなるため、気軽に『作ってみよう』とは言えない状況でした。」

また、アジャイルなアプリ内製開発と全社展開を推進するアジャイル開発グループの尾形様は、「一度決めた仕様はなかなか変更できず、フィードバックを受けて改善するサイクルを迅速に回すことが困難でした」と振り返ります。

データサイエンスグループの水谷様も同様に、従来の開発スタイルに課題を感じていました。「LLM が登場した当初は、生成されたコードが自身の環境で動作しないことや、意図と異なるコードが出力されることがありました。また、ライブラリのバージョンの問題で、自身の環境では動作しないといったこともありました。」

プロトタイピングを加速し、開発文化を変革する Gemini Code Assist

Gemini Code Assist の導入は、これらの課題を解決し、開発文化そのものを変革するきっかけとなりました。選定の決め手となったのは、主に「コンテキスト性能」「ライセンス体系」「Google Cloud との親和性」の 3 点でした。

尾形様が特に評価したのは、Gemini Code Assist の基盤となる Gemini モデルが持つ、膨大な情報から開発者の意図を正確に汲み取る広いコンテキストウィンドウです。これにより、他製品と比較してエラーが少なく、精度の高いコード生成が可能になります。加えて、高野様は、多くの他製品が従量課金制である中で、開発時間や予算を気にせず利用できるサブスクリプション体系を魅力に感じています。データサイエンスを担う水谷様にとっては、BigQuery の SQL を容易に作成できるなど、既存の Google Cloud 環境とシームレスに連携できる点も大きな利点でした。

これらの特長が、中外製薬の開発プロセスに具体的な変化をもたらします。高野様は、まず開発着手までのプロセスが劇的に変化したと話します。「以前は数週間かかっていたプロトタイプの作成が、今では数十分で可能になりました。ビジネスユーザーからの『こんなアプリはできないか』というフランクな相談に対し、その場ですぐにモックアップを作ってイメージをすり合わせることができます。アプリ開発について詳しくない臨床開発のメンバーに対しても完成イメージをすぐに共有することができるため、実現可能性を迅速に検証できるようになりました。」

この変化は、開発の進め方にも影響を与えています。「以前は要件を固めてから開発していましたが、今は『まず作って、見てもらう』というサイクルを高速で回すスタイルに変わりました。完成度が高くなくても、早い段階でフィードバックをもらい、改善を重ねていく。このアジャイルなアプローチが、ビジネス部門主導の開発を可能にしています。」

臨床開発、アジャイル開発、データサイエンス ―― 多様な現場での活用事例

Gemini Code Assist は、部門の垣根を越えて、それぞれの専門領域で効果を発揮しています。

高野様（臨床開発） 臨床試験では、規制当局へ提出するための文書など、膨大な量のドキュメント作成が求められます。高野様は Gemini Code Assist を活用し、これらのドキュメント作成を効率化するための AI エージェント開発に取り組んでいます。特に、最近追加されたエージェントモード（Gemini CLI と連携し、目標を複数のステップに分解し、必要なツールを使いながら自律的に計画を実行・修正）は、開発の幅を広げる上で大きな役割を果たしていると語ります。「エージェントモードのおかげで、これまで自身の得意な Python や Streamlit に限定されがちだった開発の幅が広がり、React のような自分にとって未知の言語やフレームワークにも気軽に挑戦できるようになりました。最適な技術を選択して、より良いアプリケーションを迅速に開発できるようになったのは大きな進歩です。」

尾形様（アジャイル開発） 全社向けの生成 AI アプリケーション「Chugai AI Assistant」をはじめ、様々なアプリケーション開発に Gemini Code Assist を活用しています。特にエージェントモードの登場は、働き方を大きく変えたと語ります。「要件を伝えるだけで、エージェントが既存のコードベースを理解し、変更箇所を提案、そして実装まで一気通貫で行ってくれます。エラーが発生した際も、エラーメッセージを貼り付けるだけで原因分析と解決策を提示してくれる。現在は、AI に適切な指示を出して効率的に開発を進めることが、業務の中心になっています。」

水谷様（データサイエンス） データサイエンスの領域でも Gemini Code Assist は不可欠なツールです。水谷様は、論文の再現実装、コードのリファクタリング、データ分析など、幅広い業務で活用しています。「論文のテキストを渡すだけで、その内容を実装してくれます。また、自身で書いた雑多なコードを、ベストプラクティスに沿ったリーダブルなコードに整理してくれるので、コードの品質が格段に向上しました。」さらに、データ分析のプロセス自体も変化しています。「Jupyter Notebook 上でデータを可視化すると、Gemini Code Assist がその結果を解釈し、インサイトまで提供してくれます。単なるコーディング支援に留まらず、データサイエンティストの思考を拡張してくれるパートナーです。」

開発速度は最大 5 倍に ―― Gemini Code Assist がもたらした定量的・定性的効果

Gemini Code Assist の導入効果は、定量的にも定性的にも表れています。

尾形様は、「体感的な開発速度は 5 倍になりました。会議の合間にエージェントに指示を出して開発を進めることができるため、時間を非常に有効活用できます。実質的に、1 時間の作業時間で 5 時間分の開発成果を得られる感覚です」と、その効果を語ります。水谷様も「3〜4 倍の効率化」を実感しており、複数のプロジェクトを並行して担当できるようになったと語ります。

高野様も、「以前は 1 年に 1、2 個のアプリケーションを開発するのがやっとでしたが、今では 3、4 個は普通に作れる感覚です」と、生産性の向上を実感しています。

これらの効果は、単に仕事が速くなっただけでなく、新しい挑戦への心理的ハードルを下げ、より多くのプロジェクトに取り組む余裕を生み出しています。

今回 Gemini Code Assist を選定された理由について、尾形様は「コンテキストウィンドウの広さ」を挙げられました。膨大な情報から開発者の意図を正確に汲み取るため、他製品と比較してエラーが少なく、コード生成の精度が高い点を評価いただいています。

加えて、高野様は「サブスクリプションのライセンス体系」を評価されています。多くの他製品が従量課金制であるのに対し、Gemini Code Assist はサブスクリプションで利用できるため、開発時間や予算超過を気にすることなく、安心して開発に集中できる点も魅力だと語ります。

水谷様は、Google Cloud 環境との親和性の高さを挙げられました。データ分析で利用する BigQuery の SQL 文を容易に作成できることや、開発環境である Cloud Workstations から手軽に利用できる点を評価されています。

AI との協業時代における、人と組織の在り方

AI の活用が広がる一方で、新たな課題も生まれています。AI を使いこなす人材とそうでない人材の生産性の差や、ジュニア層の育成、AI が生成したコードのレビュー体制などです。

尾形様は、「AI は先生としても振る舞える」と考えています。「ジュニア層は、AI が生成したコードの意図を質問し、対話することで、自身の理解を深めることができます。良いコードに触れることで、スキルアップの機会にもなります。」

中外製薬では、AI を活用した開発のベストプラクティスをドキュメント化し、社内での浸透を図っています。AI が生成したコードは 100% 正しいわけではないことを前提に、必ず人間がレビューする「ヒューマンインザループ」のプロセスを徹底しています。

未来への展望：AI と共に創る新しい開発スタイル

最後に、今後の展望について伺いました。

高野様は、「ビジネス部門が主体となって高速にアプリケーションを開発できる文化と体制を、さらに推進していきたい」と語ります。将来的には、業務ごとに特化したエージェントを複数開発し、それらをプラットフォーム上から誰もが簡単に利用できる世界を目指しています。

尾形様も、LangGraph や Dify といったツールを活用し、より高度な特化型エージェントの開発を構想しています。「個別のプロジェクト要件に合わせて、エージェントの振る舞いをノーコードで定義できるような仕組みを導入し、さらなる開発の高速化を目指します。」

水谷様は、Gemini のさらなる進化に期待を寄せています。「最新のライブラリやリファレンスをより正確に参照できるようになること、そして、より多くのファイルコンテキストを一度に扱えるようになることで、私たちの生産性はさらに向上するでしょう。」

中外製薬の挑戦は、AI が単なるツールではなく、開発者の能力を拡張し、組織全体の創造性を高めるための強力なパートナーであることを示しています。Gemini と共に歩む彼らの取り組みは、製薬業界のみならず、多くの企業の開発現場に新たな可能性を示唆していると言えるでしょう。

中外製薬株式会社は「革新的な医薬品とサービスの提供を通じて新しい価値を創造し、世界の医療と人々の健康に貢献します」をミッションとして掲げ、独自の技術とサイエンスを強みとして、ヘルスケア産業のトップイノベーターを目指しています。

インタビュイー

バイオメトリクス部臨床システム・インフォマティクスグループ高野達人様
デジタルトランスフォーメーションユニットデジタルソリューション部アジャイル開発グループ尾形遥介様
デジタルトランスフォーメーションユニットデジタルソリューション部データサイエンスグループ水谷圭佑様

シアトル小児病院で医師の作業を迅速化、効率化する AI 搭載アシスタントの舞台裏

Wed, 08 Oct 2025 01:00:00 +0000

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

名前からは想像できないかもしれませんが、シアトル小児病院は世界最大の小児医療システムです。

メインキャンパスはシアトルにありますが、シアトル小児病院はアラスカ、モンタナ、アイダホ、ワシントンに 47 のサテライト病院を擁し、ハワイからも患者が治療に訪れます。シアトル小児病院は 100 年以上にわたり、米国西部の子供たちが健康を回復し、健康を維持できるよう支援してきました。支払い能力は問いません。

広大な地域をカバーし、さまざまな患者を治療するシアトル小児病院は、患者と医療従事者に一貫した質の高いケアを提供するために、常に新しいテクノロジーを求めてきました。生成 AI は、医療ツールキットの最新の進化です。

その取り組みは、約 20 年前に始まりました。当時、シアトル小児病院は、臨床医が数十もの病状に対処する際に、より迅速かつ確実に意思決定できるよう設計された標準化されたプロトコルである小児臨床パスを作成しました。このような治療経路は医療分野全体で一般的になりつつあり、シアトル小児病院は、子どもの特有の医療ニーズに対応する治療経路をいち早く開発していました。

これらのツールは革新的でしたが、臨床医は特定の病状に必要な情報を見つけるために、索引や長いバインダーをめくって探す必要がありました。医療現場では、一刻を争う場合が少なくありません。

シアトル小児病院はすでに Google Cloud と協力して多くのプロジェクトに取り組んでいました。生成 AI によって臨床医の業務を簡素化できる可能性を探り始めたとき、まず臨床パスウェイから取り組むのが自然なステップだと考えました。Vertex AI と Gemini を使用して、Pathways Assistant を迅速に開発できました。これは、臨床パスウェイのドキュメントからトレーニングを受け、検索機能だけでなく会話機能も強化したものです。ページをめくる代わりに、臨床医が必要とする救命情報を迅速かつ確実に検索できる方法を大きく変えたのです。

医療の改善への道は Gemini を通じて「クリニカルパスウェイ」とは、特定の病状や病気に対するエンドツーエンドの治療プロトコルです。シアトル小児病院の小児臨床パスウェイは、診断基準から検査プロトコル、投薬の推奨事項まで、あらゆる情報を提供しており、世界中の病院で広く尊重され、使用されています。

以前は、これらの臨床パスウェイは PDF のみで文書化されており、その数は何十万ページにも及びます。必要な回答を得るためにコンテンツを従来の方法で検索すると、数分、あるいは数秒が重要な環境で、臨床医が治療を提供する能力が遅れてしまいます。

Google Cloud のエンジニアは、医療とテクノロジーの両方の世界にまたがるシアトル小児病院の情報医学の医師と協力して、Pathway Assistant を作成しました。新しいマルチモーダル AI chatbot は、PDF の情報を使用して、音声またはテキストの自然言語クエリに回答します。

質問を処理した後、Pathway Assistant は各 PDF のメタデータを検索します。メタデータには、Gemini によって PDF から抽出され、臨床医によってキュレートされた JSON 形式の半構造化データが含まれています。次に、最も関連性の高い PDF を選択し、埋め込まれている複雑なフローチャート、図、イラストなどの情報を解析して、わずか数秒で臨床医の質問に答えます。

正確な意思決定のためのインタラクティブな情報検索Pathway Assistant は、使用するほど精度が向上します。医療機関は、chatbot と臨床パスウェイについて「対話」することができます。chatbot は、質問に答える代わりに、説明が必要な場合は独自の質問を投げかけ、正確に回答できると確信できるまでやり取りを繰り返します。この chatbot は、回答の作成に使用した各 PDF の特定の部分を常に表示するため、臨床医は回答の正確性を確認できます。

インターフェースには、chatbot の分析と回答の正確性や適切性についてユーザーがフィードバックを提供できる機能も含まれています。フィードバックは、BigQuery テーブルに保存します。このテーブルは、自然言語を使用して情報をクエリできる臨床医と、フィードバックを処理して臨床医が混乱した点や今後の回答の精度を向上させる方法を要約する組み込みの Gemini モデルの両方によって、今後のフォレンジック分析に使用されます。

この反射的な機能により、Pathway Assistant は、不正確さが PDF のコンテンツに起因する場合、臨床医のフィードバックに基づいて PDF を更新できます。臨床医は、メタデータの精度が向上し、キュレーションの必要性が低下していることも確認しています。Pathway Assistant は、ドキュメントの誤字脱字も自動的に修正します。新しい臨床パスウェイが開発されると、最新情報を含む PDF が PDF ライブラリに追加されます。

この増え続けるコレクションは、Google Cloud Storage に安全に保管されており、データが増えるほどその有用性は高まります。以前は必ずしもそうではありませんでした。紙ベースのコレクションは情報量が増えるほど充実していましたが、その分読み込む手間も増え、特に緊急医療の現場では扱いが大変でした。Pathway Assistant は、この負担をほぼ完全に軽減し、いつでも数秒で最も完全な情報を合成して提供します。

結局のところ、Pathway Assistant は意思決定ツールではなく、情報検索ツールです。エビデンスに基づく重要なガイドラインの調査に数時間かかっていたのが、数分で済むようになりました。

このスピードと有効性により、臨床医はケアの現場でより迅速に適切な判断を下すことができ、研究時間を大幅に短縮し、患者の安全性と転帰を向上させることができます。最終的に、医療従事者は PDF の処理に追われるのではなく、より多くの患者と向き合う時間を確保できるようになります。

どの医師に聞いても、最良の医療技術はまさに患者に集中し、書類作業に追われないようにしてくれる、と答えるでしょう。

-Darren Migita 博士 、Seattle Children’s Hospital、臨床効果担当メディカルディレクター

-Jérôme Massot、 GenAI Cloud Architect、Google

Eventarc Advanced で複雑なイベント処理を大規模に簡素化

Thu, 25 Sep 2025 02:00:00 +0000

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

最新のアプリケーション開発では、スケールアップだけに投資するだけでは十分でなく、簡素化と一元的なガバナンスにも投資する必要があります。これはメッセージのルーティング以上の意味を持ちます。つまり、リアルタイムで情報の流れをインテリジェントにフィルタリング、変換、管理し、複雑さをすべて 1 か所で解消できる、シンプルで統合されたメッセージングプラットフォームが必要になります。

このたび、Eventarc Advanced の一般提供を開始しました。これは、リアルタイムのフィルタリング、変換、管理、デリバリーを 1 か所に集約することで、単純なルーティングを超えた、複雑なマルチソースのイベントドリブンアーキテクチャに対応する統合されたサーバーレスのイベントプラットフォームです。

複雑性に対処するための Eventarc の進化

Eventarc Advanced は Eventarc Standard の進化版であり、イベント処理のニーズを簡素化する統合パターンをすぐに利用できます。

Eventarc Advanced では以下のことが可能です。

Publish API を使用して既存のサービスを統合し、Google Cloud イベントを活用して高度なイベントドリブンアプリケーションを構築します。
メッセージ単位のきめ細かいアクセス制御をサポートし、サービス間のメッセージフローを集中管理、保護、監視します。
インテリジェントにルーティング: 柔軟なメッセージ条件に基づいて、メッセージを適切な宛先にルーティングします。
変換: 複数のペイロード形式をサポートし、イベント属性を変換する機能が組み込まれているため、イベントをリアルタイムで変換します。
HTTP バインディングを使用して Google Cloud サービスに公開します。

Eventarc Advanced を使用すると、高度なイベントシステムを構築できます。一方、Eventarc Standard は、Google Cloud イベントを含むシンプルな 1 対 1 のイベント処理のニーズに最適です（比較）。

Eventarc Advanced の主な技術的特徴は次のとおりです。

Publish API を使用して、CloudEvents 形式でカスタムメッセージとサードパーティメッセージを取り込みます（詳細）。
メッセージバス: イベントドリブンアーキテクチャの中枢神経系として機能し、オブザーバビリティ、セキュリティ、管理を一元化します。メッセージバスは Envoy をベースとしており、Cloud Load Balancer と Cloud Service Mesh のポリシーエンジンを使用します。

既存のシステムは、中央のメッセージバスにメッセージをパブリッシュできます。このメッセージバスは、柔軟な基準に基づいて適切なコンシューマーにインテリジェントにルーティングできます。メッセージバスは、イベント管理を簡素化し、運用上のオーバーヘッドを削減します。
一元化されたモニタリング、ロギング、トレース機能により、メッセージフローに関する分析情報を得ることができます。ログは Cloud Logging でキャプチャされ、イベント処理とエラーに関する詳細な情報が提供されます。

すぐに使用できるイベントメディエーション機能により、ソースまたは宛先サービスを変更せずにメッセージをその場で適応させ、複数のペイロード形式（Avro、JSON、Protobuf）のサポートとイベント属性を変換する組み込み機能を通じてさまざまなイベントを処理できます。

Eventarc Advanced は、信頼性の高いイベント配信と一時的な障害からのスムーズな復旧を提供することで、エラー処理を組み込んでいます。

デベロッパーとオペレーターを支援

Eventarc Advanced は、デベロッパーとオペレーターの両方のニーズに対応するように設計されています。

デベロッパーにとっての「シンプルさ」: 複雑なイベントルーティングロジックではなく、アプリケーションのコア機能の構築に集中できます。Eventarc Advanced は、統合された API と一貫したエクスペリエンスを提供し、リアルタイム変換などの分離された信頼性の高いスケーラブルなサービスを構築できます。
プラットフォームオペレーター向けの「一元化されたガバナンス」: イベントインフラストラクチャのセットアップと管理を簡素化します。プロジェクトおよびチーム全体でガバナンスを一元化し、モニタリングとロギングを行うことで、問題の特定と解決が容易になり、運用オーバーヘッドが削減されます。

Eventarc Advanced の仕組み

注文の作成、支払いの処理、商品の発送を行う注文処理システムを考えてみましょう。各アクションは「イベント」であり、複雑なシステムでは、このフローの管理が困難になることがあります。そこで役立つのが Eventarc Advanced です。アプリケーションのすべてのイベントを一元的に管理、監視、ルーティングできます。この仕組みを詳しく見ていきましょう。

メッセージバスを設定する

Eventarc Advanced の中心となるのは、イベントドリブンアプリケーションの中枢神経系として機能するメッセージバスです。すべてのイベントは、その発生元にかかわらず、分析とルーティングのためにメッセージバスに送信されます。この中央ハブでは、セキュリティポリシーを定義して、イベントを送信できるユーザーと許可されるイベントの種類を正確に制御できます。

この例では、注文関連のすべてのイベントを受信するためのメッセージバスを作成します。注文が新規作成された場合、支払いが確認された場合、ステータスが「発送済み」に変更された場合など、イベントはここに記録されます。

イベントソースを接続する

次に、注文イベントを生成するソースを接続します。イベントソースは、イベントを生成してメッセージバスにフィードするサービスとアプリケーションです。Eventarc Advanced では、以下を含む幅広いソースをサポートしているため、これが簡単になります。

Google API イベント
Publish API を介した外部アプリまたはカスタムシステム

この例では、イベントソースは Publish API を使用するカスタムサービスです。新しい注文が保存されるか、既存の注文が更新されるたびに、メッセージバスにイベントが自動的に送信されます。

パイプラインと宛先の構成

これも Eventarc Advanced の優れた点です。イベントがメッセージバスに流れ込むと、パイプラインを構成して、イベントを正しい宛先にインテリジェントにルーティングできます。これにより、イベントを正確にフィルタリング、変換、指示できます。

上記の例では、次のように設定されています。

新規注文の通知: ステータスが「新規」のイベントを検索するフィルタを設定できます。このパイプラインは、これらのイベントを通知サービスにルーティングし、通知サービスが注文確認メールをお客様に送信します。
不正行為の検出: 高額な注文（例: 1,000 ドル以上）の場合、変換を適用して、分析のために専門の不正行為検出サービスにルーティングできます。

新たな可能性を切り開く

Eventarc Advanced は、アプリケーションとワークフローに新たな可能性をもたらします。

大規模なアプリケーション統合: 多数のサービスとエージェントを接続し、異なるイベント形式やスキーマ間でも、非同期で確実に通信できるようにします。
AI と分析のためのイベントストリーミング: IoT デバイスや AI ワークロードからの大量のデータを、分析パイプラインにフィードする前にフィルタリングして変換することで処理します。
ハイブリッドクラウドとマルチクラウドのデプロイ: イベントドリブンアーキテクチャを Google Cloud の枠を超えて拡張し、オンプレミスシステムや他のクラウドプロバイダと統合します。

次のステップ

昨今のアプリケーションは、エージェント化、分散化、データドリブン化が進んでおり、効率的かつ安全なイベントオーケストレーションの必要性がこれまで以上に高まっています。データパスにカスタムコードを挿入する Service Extensions のネイティブサポートと、Model Armor、Eventarc Advanced のメッセージバスなどのサービスが間もなく提供される予定です。これにより、エージェント通信のセキュリティとネットワーキング制御が提供されます。

Eventarc Advanced は今すぐご利用いただけます。Eventarc Advanced の詳細については、ドキュメントをご覧ください。イベントドリブンアーキテクチャの詳細については、Google Cloud のベストプラクティスに基づいたアーキテクチャセンターをご覧ください。イベントドリブンアーキテクチャを次のレベルに引き上げましょう。

ープロダクト管理担当ディレクター、Vidya Nagarajan Raman

ープロダクトマネージャー、Raj Duraisamy

Horizon : クラウドでのビルドを加速させる新しい Android Automotive ソリューション

Mon, 08 Sep 2025 01:01:00 +0000

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

自動車業界は、ソフトウェア定義車両（SDV）の時代に向けて突き進んでいます。しかし、この変化はメーカーとサプライヤーの両方に大きな課題をもたらしています。自動車メーカーの優先事項は、優れたソフトウェアではなく、優れた車両を作ることです。ただし、優れた車両を作るには優れたソフトウェアが不可欠であり、その必要性はますます高まっています。SDV のビジョンを実現するまでのさまざまなハードルがある中、OEM はソフトウェアデリバリーの効率と品質を上げる方法を特定し、新しいコラボレーションモデルを確立しなければなりません。

これに対処するため、Google は Android Automotive OS を使用したプラットフォーム開発のための新しいオープンソースソフトウェアファクトリーである Horizon を構築しました。Horizon は標準化された開発ツールチェーンの提供を通じて、自動車業界のソフトウェア変革を支援し、差し迫った課題に取り組むことを目指しています。これにより、OEM は製品とエクスペリエンスの構築に重点を置きながら、価値を生み出すことができます。

自動車業界のパートナー 6 社が Horizon を早期導入したところ、デベロッパーへのフィードバックの提供が 10 ～ 50 倍速くなり、リリースの頻度とビルドの品質が向上しました。この投稿では、自動車ソフトウェアの変革における主な障害を克服するうえで、Horizon がどのように役立つかについてお伝えします。

自動車ソフトウェア開発のイノベーションにおける足かせ

現在、従来の自動車メーカー（OEM）は、アジリティに欠け、スケーリングが困難なことが多いハードウェア中心の視点からソフトウェア開発を行っています。このアプローチでは、ソフトウェアのライフサイクルに対応することが負担となるほか、多くの場合に一貫性がなく信頼性の低いツールが使用されるため、開発が減速することになります。

OEM は開発費の急増、品質の問題、イノベーションの遅れに直面しており、新規参入者や高度な機能に対する需要の高まりについていくことが困難になっています。さらに、ほとんどの顧客はスマートフォンなどのデバイスで受け取るものと同様に、頻繁かつ高品質の無線（OTA）ソフトウェアアップデートを期待しているため、大半の OEM は家電製品のエクスペリエンスを反映せざるを得なくなっています。

しかし、自動車はテレビでも冷蔵庫でもなく、多くの人が形容するような「走るコンピュータ」でもありません。車両は、多くの独立した非常に複雑なシステムで構成されており、通常は「クローズドボックス」ソリューションを提供することが多い複数のサプライヤーの多数のコンポーネントを通常は統合する必要があります。車両のコネクテッド化が進み、基本的な操作から高度な操作まで、あらゆる面でコネクテッドシステムに依存するようになっても、車両プラットフォームの統合と革新は容易になるどころか、実際には難しくなっています。

Google はもっと良い方法で、優れたカスタマーエクスペリエンスを提供するために必要なペースを維持できるはずだと考えていました。

HORIZON のご紹介: 共同で未来を切り開く

業界が直面するこうした喫緊の課題に対処するために、Google と Accenture は Horizon を開始しました。これは、自動車業界をソフトウェア主導のイノベーション市場に変革するために設計されたオープンソースのリファレンス開発プラットフォームです。

Horizon のビジョンは、自動車メーカーと OEM が製品化までの時間を大幅に短縮してチームのアジリティを高めながら、開発コストを大きく削減できるようにすることです。Horizon では自動車ソフトウェアの未来に向けた包括的なプラットフォームが提供されるため、統合だけでなくイノベーションにさらに投資できるようになります。

優れたソフトウェアを実現する主要な機能

Horizon には包括的な機能スイートが用意されており、デベロッパー中心のクラウドを活用した組み込みソフトウェアの導入しやすいオープンな業界標準が確立されています。

1. AAOS によるソフトウェアファーストの開発

Horizon は製品設計に対する仮想ファーストのアプローチを提唱し、Android Automotive OS（AAOS）と密接に統合することでソフトウェア主導の開発サイクルを強化しています。これには、Vehicle Hardware Abstraction Layer（VHAL）、virtio、Cuttlefish といった高忠実度のクラウドベースの仮想デバイスを効果的に使用することが含まれます。これらは、必要に応じて数千のインスタンスにスケールできます。スケーラブルな自動ソフトウェア回帰テストや弾力的な直接のデベロッパーテスト戦略が可能になるため、このアプローチは車両の完全なデジタルツインを作成するための最初のステップと見なすことができます。

2. コーディング、ビルド、テストの合理化されたパイプライン

Horizon は、ソフトウェア開発ライフサイクル全体に標準を導入することを目指しています。

コーディング: Gerrit を使用した柔軟で構成可能なコード管理がサポートされています。Google Cloud Marketplace から GerritForge マネージドサービスを入手して、生産的なデプロイを実現することもできます。Cloud Workstations に統合された Gemini Code Assist では、コードの補完、バグの特定、テストの生成を活用して開発を強化できるほか、Android API の説明も支援されます。
ビルド: インテリジェントなクラウドの使用と動的なスケーリングを活用したスケーリング済みのビルドプロセスを備えています。これに不可欠なのは、ウォームアップされた環境に基づく AAOS プラットフォームビルドのキャッシュと、最適化された Android Build File System（ABFS）の統合です。これにより、ビルド時間を 95% 以上短縮し、キャッシュヒット率を最大 100% にして 1～2 分でゼロから完全にビルドできます。Horizon は、Android 14 および 15、Cuttlefish、AVD、Raspberry Pi、Google Pixel Tablet など、さまざまなビルド対象をサポートしています。ビルド環境はコンテナ化されており、再現性が確保されています。
テスト: 仮想化されたランタイム環境で Cuttlefish を使用して、Google Cloud で Android の互換性テストスイート（CTS）を使ってスケーラブルなテストを実行できます。MTK Connect を使用すると、複数の物理ビルドファームにリモートでアクセスして、ウェブブラウザから安全かつ低レイテンシでハードウェアとやり取りできるため、デベロッパーにハードウェアを送る必要がなくなります。

3. クラウドを活用したインフラストラクチャ

Google Cloud 上に構築された Horizon では、スケーラビリティと信頼性が確保されています。Terraform、GitOps、Helm チャートなどのツールを使用してデプロイが簡素化され、プラグアンドプレイのツールチェーンが提供されているほか、Kubernetes へのツールやアプリケーションのデプロイも追跡可能です。

自動車 OEM と業界全体に価値をもたらす

Horizon リファレンスプラットフォームは、自動車 OEM に次のような大きなメリットをもたらします。

コストの削減: ハードウェア関連の開発コストが削減され、開発費の全体的な増加が抑えられます。
製品化までの時間の短縮: 開発とイノベーションサイクルの加速化により、製品化までの時間と機能のサイクル時間を短縮できます。
品質と生産性の向上: 標準化されたツールセットの提供とチームコラボレーションのより効果的な促進を通じて、品質が安定し、チームの生産性が向上します。
カスタマーエクスペリエンスの向上: より高速で頻繁かつ高品質なビルドを可能にすることで、自動車ソフトウェアの開発方法を変えることができます。そうすることで、カスタマーエクスペリエンスが向上し、ソフトウェア主導のサービスを通じて新たな収益源を開拓できます。
戦略的焦点: 効率的なソフトウェア開発プラットフォームは OEM の差別化の要因となるべきではなく、製品そのもののイノベーションが重視されるべきだという信念が下支えされています。そのため、ソフトウェア開発にさらに時間とリソースを費やし、品質、効率、柔軟性を高めることができます。
堅牢なエコシステム: 多様な車両プラットフォームで将来を見据えたスケーラブルで安全なデプロイを可能にするため、Horizon では Google、統合パートナー、プラットフォーム採用者間の連携を促進することを目指しています。Horizon では、リファレンスプラットフォームの機能を強化しながら、車両ハードウェア、レガシーシステム、コンプライアンス基準との統合と互換性をカスタマイズすることも可能です。

Horizon のエコシステム

最高のソフトウェアはシームレスで完璧に機能するため、ユーザーがその存在に気づくことはないと言われています。道路と移動の楽しさに焦点が置かれるべきソフトウェア定義車両では、これが特に当てはまります。

これは、自動車メーカーにとっての差別化の要因が効率的なソフトウェア開発を可能にするプラットフォームではなく車両そのものであるべきだと、Google が考える理由です。信頼できるタイヤや優れたサウンドシステムのように、ソフトウェアは今や不可欠なものとはいえ、製品そのものではありません。それは、設計、エンジニアリング、開発、生産を組み合わせた完全なパッケージにほかなりません。

ソフトウェア開発は現在、自動車製造プロセスに不可欠なため、自動車メーカーにとって妨げではなくイネーブラーであるべきでしょう。それを実現するため、Google Cloud、Android、Accenture の各チームは、関連するツールチェーンコンポーネントへのアクセスと使用を継続的に簡素化することを目指してきました。OpenBSW と Android Build File System（ABFS）の統合は、マネージド Gerrit サービスを提供する GerritForge から始まった取り組みの最新の通過点にすぎません。今後のリリースでは、さらに多くのパートナーが加わる予定です。

ぜひ、この取り組みにご参加ください。コミュニティの一員として、早期のインサイトを入手してフィードバックを提供し、Horizon の今後の方向付けに積極的にご協力いただけると幸いです。また、GitHub でオープンソースリリースを確認し、Google Cloud 環境に Horizon をデプロイしてリファレンスワークロードを実行することで、プラットフォームを評価、カスタマイズできます。

Horizon は自動車ソフトウェアの未来に向けた新たな幕開けとなりますが、オープンなコラボレーションとクラウドを活用したイノベーションを通じて、皆さまと一緒に実現していく必要があります。

^{このソリューションの提供を支援してくれた Google 社員と Accenture の皆様、Mike Annau、Ulrich Gersch、Steve Basra、Taylor Santiago、Haamed Gheibi、James Brook、Ta’id Holmes、Sebastian Kunze、Philip Chen、Alistair Delva、Sam Lin、Femi Akinde、Casey Flynn、Milan Wiezorek、Marcel Gotza、Ram Krishnamoorthy、Achim Ramesohl、Olive Power、Christoph Horn、Liam Friel、Stefan Beer、Colm Murphy、Robert Colbert、Sarah Kern、Wojciech Kowalski、Wojciech Kobryn、Dave M.Smith、Konstantin Weber、Claudine Laukant、Lisa Unterhauser に心より感謝します。}

^—

^{「ソフトウェア定義車両のコンセプトを示す次のブログ投稿のためのヘッダー画像を生成して <最初の 6 つの段落を挿入>」というプロンプトで、Imagen 4 を使用して作成された画像を開きます。}

-自動車 EMEA、業界アーキテクトリードFlorian Haubner
-Android、テクニカルプログラムマネージャーRoger Ellis

ルノーグループによる、Google のソフトウェア定義自動車業界ソリューションの活用法

Thu, 24 Jul 2025 01:08:00 +0000

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

ルノーグループはヨーロッパの大手自動車メーカーとしてよく知られており、ソフトウェア会社だと認識している方は少ないかもしれませんが、そう考えるのが妥当である理由も多くあります。ルノーグループの Ampere Software Technology は、インテリジェントな電気自動車向けの高度ソフトウェアソリューションを開発および統合し、顧客体験の向上と新しいサービスを実現するソフトウェア定義自動車（SDV）の開発に取り組んでいます。

Ampere は、大規模な Android Automotive OS（AAOS）コードベースを活用して、ルノーグループのソフトウェア定義自動車を開発しています。しかし、他のソフトウェア企業と同様に、費用の抑制、コードベースの同期、適切なテスト体制の維持、新しい人材のオンボーディングに苦労していました。

Google Cloud とルノーグループの既存のパートナーシップを基盤として、Ampere はソフトウェア定義自動車の開発に Google Cloud ソリューションを導入しました。Google Cloud Workstations と Gemini Code Assist を活用したこのソリューションは、開発過程でよく発生する障害の多くを排除することで、プロセスを効果的に合理化し、安全性と生産性を高めました。

Cloud Workstations は、セキュリティを重視する企業を対象にフルマネージド開発環境を提供します。同時に、Gemini 2.5 を活用した Gemini Code Assist は、ソフトウェア開発ライフサイクル全般にわたって安全な生成 AI コーディング支援とエージェントを提供します。また、AAOS 向けに特別に開発された Google のバーチャルツイン技術を活用することで、Ampere はフルデジタル版の自動車を構築しました。

このソリューションのコンポーネントを詳しく見ていきましょう。

Google Cloud Workstations

Google Cloud Workstations は、Android オープンソースプロジェクト（AOSP）に携わる開発者の全般的な生産性向上に大きく役立ちます。Ampere のコンテキストでは、お客様の AAOS リポジトリと事前に同期された永続ディスクを備えたオンデマンドの開発環境が提供されます。これにより、長い同期時間やビルド時間が不要になり、開発者はどこからでも作業にアクセスできます。Ampere のプラットフォーム管理者はこれらのワークステーションをプロビジョニングし、開発者が生産性を発揮できるようになるまでの時間を大幅に短縮しています。開発者は、十分な vCPU、RAM、高速 SSD ストレージを備えた高性能な仮想マシンに即座にアクセスできます。これは、要求の厳しいエミュレータを使用する開発者にとって重要なことです。リソースを柔軟に利用できるようになり、ボトルネックの防止や開発の加速が進みます。次に、安全な認証済みクラウドアクセスと Google Cloud のセキュリティツールにより、IP（知的財産）の漏洩と不正アクセスを大幅に削減できます。最後に、一貫した開発環境を確保することで、「私のマシンでは動いたのに」という問題を回避し、デバッグ時間を短縮できます。柔軟なアクセスとディスク構成により、どこからでもワークステーションにアクセスでき、永続ディスクを介したコードベース、構成、ビルドアーティファクトのセッション間での保持が可能になりリポジトリの同期を繰り返す必要がなくなるため、AAOS 開発者の生産性が向上します。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f42dd444790>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

AI を活用した Android 開発のための Gemini Code Assist

そこで Ampere は、Gemini Code Assist と統合された Android Studio と Code OSS の IDE を開発者に提供して複雑化するコード管理に対処しました。これは、習得に要する時間を短縮しただけでなく、エラーの防止にも役立ちました。Gemini Code Assist は、検索拡張生成（RAG）を使用して Ampere の非公開コードベースとドキュメントにアクセスし、Android 開発の標準と規則に合わせて調整された、関連性が高く正確なコード提案を提供します。関数についての説明、モジュールの要約、次のステップの提案で、膨大なコードベースを迅速に把握できるようになり、新しい開発者や SDV ソフトウェアのさまざまな部分に取り組む開発者にメリットをもたらしました。また、ボイラープレートコードの自動化、API の提案、潜在的な問題の検出により、Android 開発の生産性向上にも役立ちました。開発者は反復作業ではなく、SDV のコアロジックに集中できるようになりました。

バーチャルツイン

Google Cloud により、Ampere の AAOS 開発者とテスターは車の「バーチャルツイン」を使用できるようになり、実車テストや管理が不十分な仮想テストに必要なリソースの確保や工程の複雑化という問題が解決されました。開発者は、強力な Compute Engine インスタンスと、Cuttlefish などの特殊な Android エミュレータを使用して、正確な仮想車両組み込みシステムを構築できます。これにより、仮想ハードウェアを使った厳格なソフトウェアテストが可能になり、物理プロトタイプを作る前に堅牢なパフォーマンスを確保できます。AAOS 開発者は、スケーラブルな仮想デバイスを使用して、並列テスト、包括的な回帰スイート、シミュレーションを行うこともできます。これにより、CI/CD パイプラインの「テスト」フェーズが加速し、SDV ライフサイクルが改善されます。バーチャルツインは、GKE と GitLab などを利用して Cloud Workstations 開発環境とお客様の CI/CD パイプラインに統合されているため、開発者は、ワークステーションで AAOS に追加した変更をビルドしてバーチャルツインのフリートでトリガーする自動テストにより、コードに関するフィードバックを即座に取得できます。

SDV 開発のモダナイゼーションによる具体的な効果

Google Cloud は、Cloud Workstations の堅牢なマネージドインフラストラクチャ、Gemini Code Assist のインテリジェントな支援、バーチャルツインを組み合わせることで、Renault による自動車ソフトウェア開発のモダナイゼーション、イノベーションの加速、新機能のこれまでになくスピーディーな市場投入に役立っています。

「...ヨーロッパでソフトウェア定義自動車向けソフトウェアプラットフォームに投資して構築するには、ツールが必要です。Google はその点で優れています。その中心にあるのは AI です。コード生成について言えば、コンパイルを待ってから開発者が利用できるようになるのではなく、すぐに実行する必要があるものをインスタンス化します。エンジニアの効率を高めて、より少ない時間でより多くのことを行えるようにするためです。私たちは時間に追われています。」 - Ampere 最高ソフトウェア責任者（ルノーグループ）Henry Bzeih 氏

Google Cloud と Gemini Code Assist は、自動車 OEM にとって単なるツール導入に留まりません。競争力、収益性、イノベーションのスピードを高め、ビジネス成果に確かなインパクトをもたらす変革を実現します。

従来、新しい開発者のオンボーディングには数日と費用がかかります。AAOS での開発には、セットアップに時間がかかるだけでなく、依存関係の管理、ビルドシステムのトラブルシューティングも必要となるケースが多くあります。リポジトリの同期やツールチェーンの構成など、これまで数日かかっていた環境のセットアップを数分に短縮し、AI アシスタンスを活用すれば開発スピードも大幅に加速します。

OEM は、ローカルデバイスから知的財産が漏洩することを懸念しています。Cloud Workstations は、お客様の Virtual Private Cloud 内で動作することで、この懸念に対処します。このアプローチでは、ソースコードがローカル環境で同期されるため外部エンドポイントに公開されることがなく、セキュリティリスクを抑えることができます。

クラウドインフラストラクチャの費用は発生しますが、全体として大幅なコスト削減が可能です。ハイエンドのローカルマシンを排除し、環境管理にかかる開発者の時間を最小限に抑えることでスケジュールを短縮し、総開発コストを削減します。また、実際に利用した分にのみ料金が発生するクラウドリソースを迅速に調整できることで、アイドル状態のハードウェアにかかるコストを避け、エンジニアリング投資のリターンも向上します。

最後に、自動車のバーチャルツインを活用すれば、品質保証や検証作業の効率がよくなります。開発者は、限られたプロトタイプや信頼性に欠けるローカルエミュレータに頼る代わりに、精緻な仮想自動車モデルを活用することで、イテレーションの高速化、スケーラブルなテスト、早期のバグ検出、高度なシナリオシミュレーションを実現できます。

Cloud Workstations と Gemini Code Assist の活用により、自動車メーカーは新たなテクノロジーを導入するだけでなく、開発能力そのものの再構築を進めています。詳細については、SDV 業界ソリューションの成功に関する、ルノーグループの Ampere 最高ソフトウェア責任者（ルノーグループ）Henry Bzeih 氏との対談をご覧ください。

自動車業界のお客様は、Google の GitHub リポジトリをご覧になることで、Gemini Code Assist を活用したカスタム AAOS 開発環境の構築をすぐに始めていただけます。もちろん、Google のパートナーエンジニアリング担当者、カスタマーエンジニアリング担当者がサポートいたします。

-Cloud Shell および Cloud Workstations プロダクトリード Femi Akinde

ローカルホストからリリースまで: Cloud Run と Docker Compose で AI アプリのデプロイを簡素化

Thu, 17 Jul 2025 03:00:00 +0000

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

Google Cloud は、次世代の AI アプリケーションとエージェントアプリケーションをできるだけシームレスに構築、デプロイできるように取り組んでいます。このたび、Google はDocker とのコラボレーションにより、デプロイワークフローを大幅に簡素化し、高度な AI アプリケーションをローカル開発から Cloud Run に簡単に移行できます。

compose.yaml を Cloud Run に直接デプロイ

以前は、開発環境と Cloud Run などのマネージドプラットフォームのギャップを埋めるには、インフラストラクチャを手動で変換して構成する必要がありました。MCP サーバーと自己ホスト型モデルを使用するエージェントアプリケーションは、さらに複雑さを増しました。

オープンソースの Compose Specification は、開発者がローカル環境で複雑なアプリケーションをイテレーションする最も一般的な方法の一つであり、Docker Compose の基盤となっています。そして、gcloud run compose up によって、Docker Compose のシンプルさが Cloud Run にもたらされ、このプロセス全体が自動化されます。現在限定公開プレビュー版のこの機能を使用すると、既存の compose.yaml ファイルを単一のコマンドで Cloud Run にデプロイできます。これには、ソースからのコンテナのビルドや、データ永続化のための Cloud Run のボリュームマウントの活用も含まれます。

Cloud Run で Compose Specification をサポートすることで、ローカルとクラウドのデプロイを簡単に移行できます。同じ構成形式を維持できるため、一貫性が確保され、開発サイクルが加速します。

「Docker Compose は最近、エージェントアプリケーションをサポートするように進化しました。GPU を利用した実行をサポートする Google Cloud Run にもそのイノベーションが広がったことを嬉しく思います。Docker と Cloud Run を使用することで、開発者はローカルでイテレーションを行い、1 つのコマンドでインテリジェントエージェントを本番環境に大規模にデプロイできるようになりました。これは、AI ネイティブな開発をアクセス可能で構成可能なものにするための大きな一歩です。Google Cloud との緊密なコラボレーションを継続し、開発者が次世代のインテリジェントアプリケーションを構築、実行する方法を簡素化できることを楽しみにしています」- Docker、エンジニアリングおよびプロダクト担当エグゼクティブバイスプレジデント Tushar Jain 氏

AI アプリケーションのホーム、Cloud Run

Cloud Run には、Compose Specification のサポート以外にも、AI に適したイノベーションが備わっています。Google は最近、Cloud Run GPU の一般提供を発表しました。これにより、AI ワークロードに GPU を利用したい開発者にとって、導入の大きな障壁が取り除かれました。Cloud Run は、秒単位の課金、ゼロへのスケーリング、迅速なスケーリング（gemma3:4b モデルの場合、最初のトークンまでの時間は約 19 秒）を備えており、LLM のデプロイとサービングに最適なホスティングソリューションです。

また、Cloud Run は Docker が最近発表した OSS MCP Gateway と Model Runner の強力なソリューションでもあり、開発者は AI アプリケーションをローカルからクラウドのプロダクションにシームレスに移行できます。Docker が最近オープンな Compose Specification に「モデル」を追加したことをサポートすることで、これらの複雑なソリューションを 1 つのコマンドでクラウドにデプロイできます。

まとめ

上記のデモの compose ファイルを確認しましょう。これは、ソースから構築され、ストレージボリューム（volumes で定義）を利用するマルチコンテナアプリケーション（services で定義）で構成されています。また、新しい models 属性を使用して、AI モデルと、使用するランタイムイメージを定義する Cloud Run 拡張機能を定義します。

code_block: <ListValue: [StructValue([('code', 'name: agent\r\nservices:\r\n webapp:\r\n build: .\r\n ports:\r\n - "8080:8080"\r\n volumes:\r\n - web_images:/assets/images\r\n depends_on:\r\n - adk\r\n\r\n adk:\r\n image: us-central1-docker.pkg.dev/jmahood-demo/adk:latest\r\n ports:\r\n - "3000:3000"\r\n models:\r\n - ai-model\r\n\r\nmodels:\r\n ai-model:\r\n model: ai/gemma3-qat:4B-Q4_K_M\r\n x-google-cloudrun:\r\n inference-endpoint: docker/model-runner:latest-cuda12.2.2\r\n\r\nvolumes:\r\n web_images:'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f42dd515730>)])]>

AI の未来を築く

Google は、オープンスタンダードを採用し、さまざまなエージェントフレームワークをサポートすることで、デベロッパーに最大限の柔軟性と選択肢を提供することに尽力しています。 Cloud Run と Docker に関する今回のコラボレーションは、デベロッパーがインテリジェントアプリケーションを構築、デプロイするプロセスを簡素化するという Google の目標を達成するためのもう一つの例です。

Compose Specification のサポートは、信頼できるユーザー様にご利用いただけます。限定公開プレビュー版にこちらからご登録ください。

-Cloud Run 担当プロダクトマネージャー、Justin Mahood

-Google Cloud、エンジニアリング担当ディレクター、Yunong Xiao

プラットフォームエンジニアリングを駆使してデベロッパーエクスペリエンスを簡素化 - パート 2

Thu, 17 Jul 2025 01:04:00 +0000

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

前回の記事では、John Lewis Digital Platform と、プラットフォームエンジニアリングと「舗装道路」機能を通じてデベロッパーエクスペリエンスを簡素化するアプローチを紹介し、Google Cloud でのリソース作成や、専用のテナント環境内でのプラットフォームの運用機能とセキュリティ機能のデプロイをプラットフォームエンジニアリングによって実現する方法に焦点を当てました。この記事では、そのコンセプトを基に、プラットフォームによってコンポーネント（通常はマイクロサービス）レベルでもビルドと実行を簡素化する方法について、さらに詳しく説明します。

わずか 1 年ほどで、John Lewis Digital Platform は完全に製品レベルに進化しました。当社のプラットフォームを使用するチームは約 25 チームで、本番環境で実行されている johnlewis.com の小売ウェブサイトの主要な部分でも使用されています。チームが Google Cloud でリソースをプロビジョニングできるようにセルフサービス機能を構築し、プラットフォームの基盤が Google Kubernetes Engine（GKE）上にあることを明確にしました。しかし、最近のチームからは、Kubernetes の習得に時間がかかるという声が聞こえてきました。これは想定されていたことでした。チームが独自のサービスを構築して実行するという文化変革を推進していたため、アプリケーション開発者が独自のソフトウェアをサポートするのに Kubernetes のスキルが必要になることは予想できていたのです。とはいえ、私たちのビジョンは開発者の負担を軽減することであり、彼らのフィードバックは明確でした。優れたドキュメントがあるにもかかわらず、チームが推奨する手順に従っていないケースがいくつか見られました。たとえば、ワークロードが障害に耐えられるように支援するアンチアフィニティルールや PodDisruptionBudgets を使用していませんでした。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f42f0179370>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

2017 年に Kelsey Hightower は次のように書いています。「Kubernetes はプラットフォームを構築するためのプラットフォームです。これはより良いスタート地点であって、最終目標ではありません。」

Kelsey の言葉に触発された私たちは、行動を起こしました。Kubernetes を使用する開発者のインタラクションポイントを簡素化するために、独自のカスタムコントローラを作成するというアイデアが浮かんだのです。私たちが好むアプローチに沿って John Lewis 固有の抽象化を行うのです。こうして JL Microservice が誕生しました。

これを行うために、開発者が設定する必要があると思われるフィールドのみを含む簡略化された仕様で Kubernetes CustomResourceDefinition を宣言しました。たとえば、テナントがアプリケーションを自ら構築して運用することを想定しているため、レプリカの数や必要なリソース量などの属性は、開発者自身に任せるのが最適です。しかし、ノード間で Pod を分散する方法を定義するルールを彼らがカスタマイズできるようにする必要は本当にあるのでしょうか。Deployment を参照する Service を変更することはどのくらいの頻度で必要になるでしょうか。詳しく調べてみると、重複が非常に多いことがわかりました。当時の分析では、開発者が作成した YAML ファイルの内容のうち、アプリケーションに関連するものは約 33% にすぎませんでした。これは、簡素化の対象が豊富にあるということです。

この機能を構築するにあたり、Kubebuilder を選択し、それを使用して CustomResourceDefinition を宣言し、コントローラ（MicroserviceManager と命名）を構築しました。これは有益な決定でした。最初のプロトタイピングは迅速に行われ、数か月後に機能がリリースされ、非常に好評を博しました。チームは Go プログラミング言語のスキルアップが必要でしたが、Kubebuilder がもたらすメリットを考えると、このトレードオフは価値があると感じました。それ以来、他のソフトウェアエンジニアリングにも役立っています。

最初の実装では、エンジニアが Deployment と Service を理解して完全に構成する必要がなくなり、代わりに、変更する必要があるフィールドのみを含む、はるかに短い YAML ファイルを適用すればよくなりました。同一のフィールドの直接変換（たとえば、image と replicas は、Deployment にあるものと同等）だけでなく、Kubernetes API で行われる選択を簡素化することもできました。John Lewis では、その機能の一部は必要なかったからです。たとえば、writablePaths: [] はエンジニアが理解しやすいコンセプトです。その裏では、コントローラがこれをより複雑な Volume と VolumeMount の組み合わせに変換しています。同様の例として、visibleToOtherServices: true は Kubernetes NetworkPolicy とのやり取りを簡素化します。チームがリソースに正しくラベルを付けるためにドキュメントを読んで必要な構文を理解する必要はなく、コントローラがそれらの規則を理解して処理します。

Microservice リソースの基本コンセプトが確立されたことで、さらに機能を追加して付加価値を高めることができました。すぐに拡張して Prometheus のスクレイピング構成を定義し、さらに、チームが Google Cloud Endpoints を使用することを宣言できるようにするなどの複雑な機能を追加しました。これにより、コントローラは必要なサイドカーコンテナを Deployment に挿入し、Service に接続できます。機能を追加するにつれて、既存のテナントはこの仕様を使用するように変更され、現在ではプラットフォームで宣言されたワークロードの大部分を占めています。

プラットフォームの境界を移動する

MicroserviceManager を構築する動機は、開発者の作業を楽にすることにありました。しかし、当初は予想していなかったさらなるメリットがあることがわかりました。それは、プラットフォーム内でも大きなメリットが得られるということです。テナントを巻き込むことなく、バックグラウンドで変更を加えることができるようになったことで、テナントのトイルが減り、プロダクトの改善が容易になりました。これは少し予想外でしたが、非常に大きなメリットでした。テナントとプラットフォームの間で確立された契約を変更することは一般的に困難ですが、このような抽象化を作成することでより多くのものを我々の管理下に置くことができ、これはすべてのユーザーにとってメリットとなります。

その一例として、johnlewis.com のライブ負荷テストで、特定のワークロードが数百の Pod までバーストしたことがありました。これは、クラスタで実行していた通常のノード数を上回る数です。これにより、新しいノードが作成され、Pod の自動スケーリングが遅くなり、ビンパッキングが不十分になりました。Kubernetes の運用経験が豊富な方なら、ここで何が起こったかはお察しいただけるでしょう。デフォルトのアンチアフィニティルールは、復元力を最適化するように設定されており、特定のノードには 1 つのレプリカしか許可されていませんでした。ただし、幸運なことにワークロードは Microservice Manager の制御下にあり、関連する YAML をデプロイにコピーするようテナントに指示する必要がなかったため、アンチアフィニティルールをより新しい podTopologyConstraints に置き換えるのは簡単でした。これにより、特定のレプリカ数を超えるワークロードについて、ノードにスタックできるレプリカ数をカスタマイズできるようになりました。テナントによる操作は一切必要ありませんでした。

より複雑な例としては、サービスメッシュをロールアウトしたときが挙げられます。我々はコントロールプレーンコンポーネントの実行の複雑さの処理を Google Cloud に任せたいと基本的に考えていたので、Google の Cloud Service Mesh プロダクトを使用することにしました。しかし、それでも、常に使用されているビジネスクリティカルなプラットフォームにメッシュをロールアウトするには、リスクが伴います。Microservice Manager では、Microservice リソースのフィーチャートグルを使用して、ワークロードをメッシュに登録する頻度を制御できます。まず、プラットフォームが所有するワークロードでロールアウトを開始してアプローチをテストし、その後、先行ユーザーが Cloud Service Mesh の一部の機能を検証して利用できるように、テナントにフラグを通知します。ロールアウトを拡大する際には、ビジネス上の重要度に基づいて段階的にリリースするようにフラグを操作し、必要に応じてオプトアウトメカニズムを提供します。これにより、実装が大幅に簡素化されました。プロダクトチームがやるべきことはほとんどなく、数百のマイクロサービスを実行している約 40 のチームに適切な構成変更を依頼する必要もありませんでした。フィーチャートグルを活用するこの手法は、独自のテストをサポートするために幅広く活用しています。

マイクロサービスを超えて

Microservice Manager を構築したことで、Kubernetes ネイティブな方法が考えられるようになりました。カスタムリソース + コントローラというコンセプトは強力な手法であり、これを使用して他の機能も構築しました。たとえば、外部接続の必要性を Istio リソースに変換して、下り（外向き）ゲートウェイ経由でルーティングするコントローラです。Istio は非常に強力なプラットフォーム機能ですが、活用する際にユーザー側に求められる知識やスキルは少なくありません。したがってこれは、プラットフォームエンジニアリングがチームの代わりに管理し、チームがその機能を活用できるようにするのに最適な例と言えます。テクノロジーに対する信頼が高まった今、この分野でさまざまなアイデアが生まれています。

まとめると、John Lewis Partnership は Google Cloud とプラットフォームエンジニアリングを活用して、e コマースの運用とデベロッパーエクスペリエンスをモダナイズしました。マルチテナントアーキテクチャで「舗装道路」アプローチを実装することで、開発チームを強化し、デプロイサイクルを加速させ、カスタムの Microservice CRD を使用して Kubernetes のインタラクションを簡素化しました。この戦略により、運用効率を維持し、エンジニアリングチームを効果的にスケールしながら、複雑さを軽減することで、効果的なスケールとデベロッパーエクスペリエンスの向上を実現できました。

Google Cloud でのプラットフォームエンジニアリングの詳細については、プラットフォームエンジニアリングに関する 5 つの誤解: プラットフォームエンジニアリングとは一体なのか、プラットフォームエンジニアリングにまつわるさらなる 5 つの誤解、道を照らす: プラットフォームエンジニアリング、ゴールデンパス、セルフサービスのパワーなどの記事をご覧ください。

-アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード、Darren Evans
-John Lewis Partnership、プリンシパルプラットフォームエンジニア、Alex Moss 氏

プラットフォームエンジニアリングを駆使して開発者の利便性を強化 - パート 1

Thu, 17 Jul 2025 01:00:00 +0000

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

編集者注: この投稿は記事のパート 1 です。読み終えたらパート 2 へお進みください。

2017 年、年間 25 億ポンドものオンライン売上高を誇る英国の大手小売業者 John Lewis は、モノリシックな e コマースプラットフォームの課題に悩まされていました。この時代遅れのアプローチは、チーム間の依存関係の増大や煩雑で頻度の低いリリース（せいぜい月 1 回）、過剰な手動テストの原因となり、複雑なオンプレミスインフラストラクチャによってさらに状況が悪化していました。そこで必要とされたのは、迅速かつ大幅な変革を推進するための大胆な決断です。

John Lewis のエンジニアたちはより良い方法があることを知っていました。エンジニアたちは Google Cloud と連携し、e コマース事業をモダナイズするために Google Kubernetes Engine を採用しました。フロントエンドから始まったこのプロジェクトは、すぐに成果を上げ始めました。わずか数か月でフロントエンドが Google Cloud に移行され、フロントエンドのブラウザへのリリースが毎週行われるようになったことから、同社は他の分野への拡大に乗り出しました。

同時に、チームはより広範な戦略を考えていました。それは、プラットフォームエンジニアリングのアプローチを採用して、従来のコマースエンジンの機能に取って代わる独自のマイクロサービスを構築するためのプロダクトチームを多く立ち上げるとともに、顧客向けのまったく新しいエクスペリエンスを作成するというものです。

こうして、John Lewis Digital Platform が誕生しました。そのビジョンは、開発チームを強化し、迅速なリリースのために必要なツールとプロセスを提供して、チームごとのビジネスサービスに関して完全に責任を持たせることでした。チームのモットーは、「自分で作る。自分で運営する。自分で責任を持つ」です。このように開発と運用の責任を分散することで、チームの規模を拡大することも可能になります。

この記事では、John Lewis がプラットフォームエンジニアリングにより業務のモダナイズと合理化を進める過程で得た戦略、プラットフォームの構築、主な教訓について、プリンシパルプラットフォームエンジニアの Alex Moss 氏が詳しく説明してくれます。プラットフォームエンジニアリングを自社組織にどのように適用できるかを検討するきっかけとなるはずです。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f42de12b5e0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ステップ 1: モノリシックからマルチテナントへ

この実現のために、John Lewis はマルチテナントアーキテクチャを採用する必要がありました。ビジネスサービスごとに 1 つのテナントを割り当て、各所有チームが他のチームにリスクを与えることなく独立して作業できるようにすることで、プラットフォームチームは各チームに大きな自由度を与えられるようになりました。

会社の主な目標がプロダクトチームの数を大幅に増やすことであるとわかっていたため、初期のデザイン思考に反映させました。テナントは少数でしたが、多くの独立したチームをサポートできるように体制を整えることができました。

この基本的な設計は非常にうまく機能し、7 年経った今でもほとんど変更されていません。マルチテナントコンセプトの中核を成すのは、私たちが「サービス」と呼ぶものです。これは論理的なビジネスアプリケーションを指し、通常は複数のマイクロサービスとデータを保存するためのコンポーネントで構成されます。

自社のプラットフォームは、主に「自分でコンテナを持ち込む」としていますが、特に状態の処理に関しては、他の Google Cloud サービスも活用することをチームに推奨しています。Firestore や Pub/Sub などのサービスを採用することで、プラットフォームチームが対応しなければならない複雑さを軽減できます。特に、レジリエンスや障害復旧などの分野で効果を発揮します。また、私たちは、Cloud Run などのコンピューティングプロダクトよりも Kubernetes を優先して利用しています。Kubernetes は開発チームの自由度を高めつつ、プラットフォームで特定の動作を実行できる適切なバランスを実現しているからです（たとえば、過度の摩擦が生じることなく、適切なレベルのガードレールを設定できます）。

当社のプラットフォームでは、プロダクトチーム（テナント）が独自の名前空間とプロジェクトをかなり細かく制御できるようになっています。これにより、他チームに依存することなくワークロードのプロトタイピング、構築、最終的な運用が可能になります。これはスケールの実現に欠かせない要素です。

プラットフォームの進化にあたり、先行チームの存在は非常に有益でした。彼らは、機能の不足を認めて独自のソリューションを開発する意欲を示し、ニーズを満たすものを構築しているかどうかについてたくさんのフィードバックを提供してくれました。

このプラットフォームを最初に採用したチームは、johnlewis.com の検索機能を再構築し、市販のソリューションに置き換えました。このチームは、最新のソフトウェア開発とマイクロサービスベースのアーキテクチャの利点に精通した経験豊富なエンジニアで構成されており、アプリケーションでデータを保存し、コンポーネント間で非同期通信を行うためのサポートサービスが必要であることをすぐに特定しました。また、プラットフォームチームと協力して選択肢を検討し、自社でデータベースやメッセージングの運用をせずに Google Cloud のネイティブサービスを活用したいという当社の意向に賛同してくれました。その結果、Google Kubernetes Engine 以外の最初の拡張機能として Cloud Datastore と Pub/Sub を採用することになりました。

すべての道が成功への道

チームの自律性が非常に高いプラットフォームでは、テクノロジーの選択や実装パターンの面でやや無秩序になりやすいというリスクがあります。デベロッパー中心の姿勢を維持しながらこの問題に対処するために、「Golden Path」に似た「Paved Road」（舗装道路）というコンセプトを採用しました。

「Paved Road」アプローチにより、次の点が容易になりました。

デベロッパーが迅速かつ安全に作業を進められる便利なプラットフォーム機能を構築する
アプローチや手法を共有し、エンジニアがチーム間を移動できるようにする
チームが必須の実践事項に従っていることを組織全体に示す（これは、リリースで制限するのではなく、保証機能を構築することで実現します）

「Paved Road」というコンセプトは、プラットフォームで構築するほとんどの部分に浸透しており、John Lewis Digital の領域を超えて、John Lewis Partnership の他の領域にも影響を与えています。

当社の「Paved Road」は、チームの簡素化を実現する 2 つの主要な機能によって支えられています。

Paved Road パイプライン: これはサービス全体で動作し、Google Cloud リソースのプロビジョニングやオブザーバビリティツールなどの機能を提供します。
マイクロサービス CRD: その名が示すように、これはマイクロサービスレベルの抽象化のことです。ここでの主なメリットは、チームが Kubernetes をより簡単に扱えるようになることです。

どちらの機能も開発者の利便性を念頭に置いて作成されましたが、プラットフォームチームにも多くのメリットがあることがわかりました。

Paved Road パイプラインは構成ファイル（もちろん yaml 形式）によって駆動します。この構成ファイルを「サービス定義」と呼びます。これにより、テナンシーを所有するチームは、推論が容易な構成を通じてプラットフォームに提供してほしい機能を記述できます。関連ドキュメントとサンプルは、何が実現できるのかをチームメンバーが理解するのに有用です。このファイルに push すると、プラットフォームが所有する多数のジョブ（「プロビジョナー」と呼んでいます）の CI / CD パイプラインが実行されます。これらのプロビジョナーはマイクロサービスと同様に、独立してリリース可能であり、一般的に 1 つのタスクを適切に実行することに重点を置いています。以下に、プロビジョナーの例とその機能を説明します。

各チームのプロジェクトに Google Cloud リソースを作成する。例: バケット、Pub/Sub、Firestore など。
ゴールデンシグナルと自己計測指標に基づいて、プラットフォーム提供のダッシュボードとカスタムダッシュボードを構成する
特定のマイクロサービスの SLO に合わせてアラート構成を調整し、それらのアラートに対するインシデント対応の動作を調整する

これにより、プロダクトチームが Google Cloud リソースのプロビジョニングの仕組みや、そのための Infrastructure as Code（IaC）ツールについて深く理解する必要がなくなります。推奨テクノロジーとベストプラクティスは当社のエキスパートが厳選したものであり、デベロッパーはプロビジョニングする内容とタイミングを完全に制御しながら、ビジネスに差別化をもたらすソフトウェアの構築に集中できます。

先ほど述べたように、このアプローチには、プラットフォームチームが独自の機能を構築するために利用できるというメリットがあります。チームがサービス用に更新した構成は、チームに関するメタデータと組み合わせて、API 経由または Pub/Sub に公開されたイベントを通じて表示できます。これにより、インシデント対応やセキュリティツール、事前プロビジョニングされたドキュメントリポジトリなど、他の機能のアップデートも促進されます。これは、当初はチームが独自の IaC を記述する手間を省く手段として意図されていたものが、プラットフォーム機能の構築を容易にし、付加価値をさらに高めるためにも活用できることを示した一例です。デベロッパーがそのことを意識する必要もありません。

このアプローチは、チームが使用できるように事前構築された Terraform モジュールを提供するよりもスケーラブルであると考えています。Terraform モジュールのアプローチではチームが Terraform に精通している必要があり、バージョニングや依存関係の複雑さがメンテナンス作業の面でプラットフォームエンジニアの負担になる可能性があります。代わりに、理解しやすい API を提供し、プラットフォームチームに意図的に負担をかけることで、チームに必要なすべての機能をサービスが提供できるようにしています。この抽象化により、必要に応じて大幅なリファクタリングを選択することもできます。

このアプローチを採用することで、プラットフォーム全体でテクノロジーの一貫性を広く維持できます。たとえば、プラットフォームで Pub/Sub のリソースを簡単に作成できるのに、チームがわざわざ Kafka を実装する必要はあると思いますか？これは、機能するビジネスサービスに組み立てられるランタイムコンポーネントだけでなく、そのソフトウェアを運用するためのすべての付随的なニーズ（レジリエンスエンジニアリング、モニタリングとアラート、インシデント対応、セキュリティツール、サービス管理など）にも及ぶことを考えると、エンジニアの生産性に大きな増幅効果をもたらします。これらの要素はすべて、John Lewis Digital Platform 上で完全な「Paved Road」機能を備えており、チームがニーズを認識して適切なオプションを特定し、それらを使用するためのテクノロジーやプロセスを実装する際の認知負荷を軽減してくれます。
とはいえ、私たちが「Paved Road」のコンセプトを特に気に入っている理由の一つは、チームの「オフロードに挑む」という選択肢を排除しない点です。「Paved Road」は必須ではありませんが、エンジニアが他の方法を選びたくならないような、説得力のあるものであるべきです。他のアプローチの使用を禁止すると、イノベーションを阻害し、「これで十分だ」と構築した機能に甘んじてしまうリスクがあります。「Paved Road」は、デベロッパーの変化するニーズに応え続けられるようプロダクトを改善し続けるという課題をプラットフォームエンジニアに課しています。同様に、開発チームが独自の道を歩もうとしても、強力なプラットフォーム機能を複製する際に伴う負担の増加がそれを思いとどまらせます。

エンジニアのニーズは一定ではなく、Google Cloud ももちろん新しい機能をリリースし続けています。そのため、この例えを拡張して「Dusty Path」（ほこりっぽい道）というコンセプトを追加することにしました。これは、私たちが望むほど機能が豊富ではない（セルフサービスプロビジョニングやすぐに使えるオブザーバビリティが欠けているなど）新しいプラットフォーム機能を表しています。チームには、さまざまなオプションを試して、まだ整備されていない Google Cloud プロダクトを活用することが求められています。このテストを可能にするのが「Paved Road パイプライン」です。このテストプロセスを「スノーフレーク（実験的利用の意味）」と呼んでいます。そして、ここに非公式の「3 つのルール」を設けています。少なくとも 3 つのチームが同じ機能をリクエストしていることが確認された場合、その機能のセルフサービス化を進めるというものです。

かたや、もう一方の極端ではチームが完全に単独で作業することもあります（「クレイジーペイビング（「非標準実装の意味）」と呼んでいます）。これは、大胆なテストのサポートや、プラットフォームの安全な運用の要件に応えられないワークロードへの対応に必要となる場合があります。この分野のソリューションは一般的に長続きしません。

この記事では、John Lewis がプラットフォームエンジニアリングにマルチテナントの「Paved Road」アプローチを採用することで、e コマース事業に変革を起こした事例を紹介しました。この戦略によって開発チームをどのように強化し、Google Cloud リソースのプロビジョニングや運用機能とセキュリティ機能のデプロイをどのように合理化したかを検証しました。

このシリーズのパート 2 では、John Lewis がマイクロサービス CRD を導入することで開発者の利便性をさらに強化させた方法について詳しく説明します。この独自の Kubernetes 抽象化により、コンポーネントレベルでの Kubernetes 操作の複雑さが大幅に軽減され、開発サイクルの短縮と運用効率の向上につながった仕組みについて解説します。

Google Cloud でのプラットフォームエンジニアリングを活用したシフトダウンについて、詳しくはこちらをご覧ください。Google Kubernetes Engine（GKE）の堅牢かつインテリジェントなフルマネージド Kubernetes Service によって、コンテナ化されたアプリケーションのデプロイ、スケール、管理をデベロッパーが簡単に実行できるようにする方法については、こちらから詳細をご確認いただけます。

-アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード、Darren Evans

-John Lewis Partnership、プリンシパルプラットフォームエンジニア、Alex Moss 氏

Sansan の Platform Engineering 戦略：開発者体験とビジネス価値を最大化する Orbit とは

Mon, 23 Jun 2025 02:00:00 +0000

多くの開発現場が抱える「開発者がインフラ関連の作業に追われ、開発に集中できない」という課題。この「痛み」を解決するアプローチが Platform Engineering です。

Google Cloud では Tech Acceleration Program ( 以下、TAP) の一つとして、Platform Engineering の実践を支援する「Platform Engineering Jumpstart」を提供しています。Google Cloud のエンジニアが Google Kubernetes Engine などを中心に、開発者向けのプラットフォーム設計や Platform Engineering の適用をサポートします。

今回ご紹介する Sansan株式会社は、この Platform Engineering を採用し、アプリケーション開発プラットフォーム「Orbit」を構築し、開発者体験を劇的に向上させ、開発生産性も大きく向上させました。アプリのリリース頻度アップや開発期間の短縮など、ビジネスを加速させた成功の裏側には何があったのか？その詳細に迫ります。

利用している主なサービス:
Google Kubernetes Engine (GKE)

利用している主なソリューション:
アプリケーションのモダナイゼーション

開発の「痛み」から生まれた共通プラットフォーム「Orbit」

Orbit を導入する以前の Sansan では、開発チームはいくつもの課題に直面していました。特に顕著だったのは、開発チームの担当範囲があまりにも多岐にわたっていた点です。インフラ運用、CI/CD パイプライン、Terraform などの管理は非常に大変でした。

会社としては新規事業を数多く立ち上げる一方で、インフラエンジニアが不在のケースもあり、アプリケーション開発者がインフラ設定などに時間を取られてしまうという状況が生じていました。Orbit のユーザーの立場で「名刺メーカー」の開発を担当する山門峻様は、当時の状況について「使うサービスの設定が最適かどうか毎回悩むなどで時間がかかり、それが開発チームやビジネスサイドにとって具体的な『痛み』となっていた」と語っています。設定ファイルが散らばっていたり、手作業で変更されているケースもあり、そうしたことが認知負荷となっていたそうです。

このような課題を解決するために、Platform Engineering が検討され始めました。この目的は、単に開発者体験を良くするだけでなく、プラットフォーム側とアプリケーションエンジニア側の両方の工数を圧縮し、組織全体の生産性を向上させることを目指しています。

そして誕生したのが、アプリケーション開発プラットフォーム「Orbit」です。その名称「Orbit」は、Google Cloud の六本木のオフィスで、TAP に参加した際に、六本木ヒルズの玄関口にドラえもんがたくさんいた時期があり、そこから連想された「宇宙」や、アプリケーションが効率よくぐるぐる回る「軌道」に由来しています。プラットフォームエンジニアとして開発を担当する辻田美咲様は、「プラットフォームの名前を決めようとした日がドラえもんの誕生日だった」という、素敵なエピソードも紹介してくれました。Orbit には、アプリケーションが軌道に乗ってスムーズに稼働する世界観が込められています。

「Orbit」によって、アプリのリリース頻度が 84% 増加など、驚くべき導入効果

プラットフォームの基盤として Google Cloud を選んだきっかけは、Platform Engineering Kaigi での発表で Platform Engineering Jumpstart を知ったことでした。辻田様は「このプログラム参加を通じて Platform Engineering の解像度が大幅に上がり、当初 Cloud Run と迷っていたアーキテクチャ選定において、自信を持って GKE を選択することができたのはすごく良かったです」と振り返っています。

GKE には複雑そうというイメージがありましたが、Autopilot ではインフラ管理の手間をなくし、コストを最適化しながら、セキュアでスケーラブルなKubernetes環境の構築ができることを知りました。Cloud Run ではバックエンド管理が必要で認知負荷になりうるとも思われた一方、GKE ではマニフェストで定義できる点が問題解決につながると判断されました。Sansan の Strategic Products Engineering Unit (以下、SPEU) では以前から Google Cloud を使うことが多く、App Engine や Cloud Run の利用経験もあったことが Google Cloud 選定の背景にあります。他のクラウドサービスを検討しなかったのは、SPEU が元々 Google Cloud を頻繁に利用し、エンジニアの習熟度も高かったためです。

Orbit の導入・構築は、Platform Engineering Jumpstart がきっかけとなり、アーキテクチャが概ね決定された後、すぐにクラスタ構築とデモアプリケーションのデプロイから着手されました。その後、DB 接続サンプル作成や Secret Manager 構築などを行い、「名刺メーカー」で当時開発中だった新機能を、実際に Orbit 上で稼働させてみたのです。この初期構築は、辻田様がほぼ 1 名で実施されたとのことで、そのスピード感には驚かされます。

最初のユーザーとなったのは「名刺メーカー」チームでした。これは、Orbit を構築するチームと同じチームであったことが大きな理由です。山門様は、実際に利用を開始すると「権限回りのエラーや Pod サイズの問題、GKE Gateway のヘルスチェック理解など、想定外の問題にぶつかりましたが、都度 Orbit Team に問い合わせし、解決していった」と語っています。最初に辻田様とペアプログラミングでこれらの問題をスムーズに解決できたことで、山門様の Orbit に対する理解も深まりました。

Orbit 導入によって、開発者体験は大きく向上しました。山門様は「インフラ設定の認知負荷が減り、マニフェストを見れば理解できるようになりました。設定作業も減り、開発環境、ステージング環境、本番環境の設定が同じになったため、環境ごとに特別な準備が必要なくなりました」と、その効果を実感しています。ArgoCD のダッシュボードから Pod の起動なども確認可能になり、開発者はインフラの細部を気にせず開発に集中できるようになったそうです。

定量的な効果も顕著に現れています。アプリのリリース頻度は 84% 増加し、インフラのリリース頻度も 20% 増加しました。また、アプリのリードタイムは 43% 削減、インフラのリードタイムも 16% 削減されました。あるプロジェクトでは、予定より 1 週間前倒しでリリースでき、これは 20 人日分の圧縮効果に相当すると推計されています。

また、社内への展開にあたっては、全社開発メンバー向けに Orbit を紹介する社内 LT や、少人数で課題を聞き出し提案するといった「社内営業」も大切だったと語られています。

これらの高い評価や活動は、全社展開を見据えて Platform Engineering Unit が新たに発足するきっかけとなり、増員も進められています。さらに、今回の取り組みは、採用面でも良い効果を生んでおり、プラットフォーム志望者の応募が増え、返信率も高いとのことです。

Google Cloud 上で実践するメリットと今後の展望

Platform Engineering Unit のグループマネージャーである水谷高朗様は、Google Cloud 上で Platform Engineering を実践することのメリットとして「Google Cloud 自体がプラットフォームであり、使いやすい点が挙げられます。また、ネットワーク等の抽象化のレベル感が良い点も魅力です。TAP の存在も大きかった」と語っています。

辻田様も「Google Cloud 自体がプラットフォームとして使える感じがしてすごく使いやすいです。特に Google Cloud Next での Product Manager とのミーティングで機能要望を出しやすい点もメリットと感じており、ユーザーとして今後も使い続けたい」と述べています。山門様はユーザー視点から「Web リファレンス、サポート、ドキュメント、Slack からの問い合わせなど、使う側への配慮がある点も高く評価できます。新しく Google Cloud の個別サービスを使う際に、参考になるものが多かったり、設計で困ったときに相談できたりするのは、使う側を考えていただいていると感じます」と、ドキュメントやサポートの充実を評価しています。

Orbit の利用は今後さらに拡大していく計画です。現在は名刺メーカー、Sansan Data Hub での利用が中心ですが、6 月を目処に全社展開を進めています。R&D (研究開発) 部門での利用 (NineOCR など)、特に GPU への期待や、Contract One、Seminar One での利用も検討・進行中です。Google Cloud は GPU リソースを確保しやすい点も評価されています。

今後の機能拡張としては、DB マイグレーション (Elasticsearch から Spanner など) への対応や AI ワークロード (Inference GW) への対応も視野に入れています。

水谷様は「Platform Engineering Jumpstart の活用を強く推奨します」と述べています。また、辻田様も「社内の開発チームとのコミュニケーションがとても大事であり、『社内営業』も必要です。開発チームにその必要性を丁寧に理解してもらうことが成功の鍵となります」と、技術面だけでなく組織内のコミュニケーションの重要性を強調してくれました。

Sansan の Platform Engineering「Orbit」の取り組みは、開発チームの課題を解決し、開発者体験の向上とビジネス価値の最大化を同時に実現する素晴らしい事例です。Google Cloud のサービスを活用し、Platform Engineering Jumpstart も効果的に使いながら、短期間でこれだけの効果を出している点は、Platform Engineering を検討する多くの企業にとって参考になるでしょう。今後のさらなる全社展開と機能拡張にも期待が高まります！

Sansan株式会社は「出会いからイノベーションを生み出す」をミッションとして掲げ、働き方を変えるDXサービスを提供しています。主なサービスとして、営業DXサービス「Sansan」や名刺アプリ「Eight」、経理DXサービス「Bill One」、AI契約データベース「Contract One」を国内外で提供しています。

インタビュイー

技術本部 Platform Engineering Unit
Application Platformグループ GrM
水谷高朗様

技術本部 Platform Engineering Unit Application Platformグループ
プロダクト開発エンジニア
辻田美咲様

技術本部 Sansan Engineering Unit 名刺メーカーDevグループ
プロダクト開発Webエンジニア
山門峻様

Cloud Run で GPU の一般提供を開始: AI ワークロードの実行が誰にとっても簡単に

Fri, 06 Jun 2025 02:00:00 +0000

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

Google Cloud のサーバーレスランタイムである Cloud Run は、そのシンプルさ、柔軟性、スケーラビリティから、デベロッパーに人気を博しています。このたび、Cloud Run での NVIDIA GPU のサポートが一般提供となり、さまざまなユースケースに対応するパワフルなランタイムを非常にコスト効率の高い形で提供できることになりました。

今後は、GPU と CPU の両方で次のメリットを享受できます。

秒単位の課金: 使用した GPU リソースに対してのみ、秒単位で課金されます。
ゼロへのスケーリング: Cloud Run は、リクエストが届かない間は GPU インスタンスを自動的にゼロにスケールダウンすることで、アイドル状態の費用を排除します。散発的または予測不可能なワークロードには朗報です。
迅速な起動とスケーリング: GPU とドライバをインストールしたインスタンスが 5 秒以内にゼロから起動するため、アプリケーションは非常に迅速に需要に対応できます。たとえば、ゼロからスケール（コールドスタート）した場合、最初のトークンまでの時間が gemma3:4b モデルで約 19 秒という驚異的な数値を達成しました（これには、起動時間、モデルの読み込み時間、推論の実行時間が含まれます）。
完全なストリーミングのサポート: HTTP と WebSocket ストリーミングのサポートがすぐに使える状態で組み込まれているため、真にインタラクティブなアプリケーションを構築して、LLM の回答が生成されたらすぐにユーザーに提供できます。

Cloud Run での GPU のサポートは重要なマイルストーンであり、GPU で高速化されたアプリケーションをこれまで以上にシンプル、高速、費用対効果の高いものにする取り組みにおける Google のリーダー的地位を実証しています。

「サーバーレス GPU アクセラレーションは、最先端の AI コンピューティングをより利用しやすくするための大きな進歩です。NVIDIA L4 GPU へのシームレスなアクセスにより、デベロッパーはこれまで以上に費用対効果の高い方法で迅速に AI アプリケーションを本番環境に展開できるようになりました。」- NVIDIA、アクセラレーテッドコンピューティングプロダクト担当ディレクター Dave Salvator 氏

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f42def36e50>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

誰もが利用できる AI 推論

この一般提供版リリースで最も注目すべき点は、Cloud Run の GPU として NVIDIA L4 GPU が誰でも利用できるようになったことです。割り当てリクエストは不要であるため、導入への大きなハードルが解消され、Cloud Run サービスで GPU アクセラレーションをすぐに活用できます。Cloud Run コマンドラインから --gpu 1 を使用するか、コンソールで [GPU] チェックボックスをオンにするだけで、割り当てをリクエストする必要はありません。

プロダクションレディ

一般提供が開始されたことにより、Cloud Run での GPU のサポートは、Cloud Run のサービスレベル契約（SLA）の対象となり、信頼性と稼働時間が保証されるようになりました。Cloud Run はデフォルトでゾーン冗長性を提供しており、ゾーン停止に耐えるために十分な容量をサービスに確保できます。これは、Cloud Run で GPU を使用した場合にも適用されます。また、ゾーン冗長性をオフにして、ゾーン停止が発生した場合に GPU ワークロードのベストエフォートフェイルオーバーを行うことにすれば、料金を低く抑えられるメリットがあります。

マルチリージョン GPU

グローバルなアプリケーションをサポートするため、Cloud Run の GPU は 5 つの Google Cloud リージョン（us-central1（米国アイオワ）、europe-west1（ベルギー）、europe-west4（オランダ）、asia-southeast1（シンガポール）、asia-south1（インド、ムンバイ））で利用可能で、今後さらに拡大する予定です。

また、Cloud Run は複数のリージョンにわたるサービスのデプロイを簡素化しています。たとえば、1 つのコマンドで米国、ヨーロッパ、アジアにサービスをデプロイし、低レイテンシと高い可用性をグローバルユーザーに提供できます。例として、オープンモデルを実行する最も簡単な方法の一つである Ollama を、3 つのリージョンにわたって Cloud Run にデプロイする方法を以下に示します。

code_block: <ListValue: [StructValue([('code', 'gcloud run deploy my-global-service \\\r\n --image ollama/ollama --port 11434 \\\r\n --gpu 1 \\\r\n --regions us-central1,europe-west1,asia-southeast1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f42dc8598b0>)])]>

実際の動作を確認する: 4 分で NVIDIA GPU を 0 個から 100 個へ

GPU を使用した Cloud Run の驚異的なスケーラビリティを、Google Cloud Next 25 のこちらのライブデモで実際に確認できます。わずか 4 分で GPU を 0 個から 100 個までスケールする様子を紹介しています。

Cloud Run の GPU で実行されている Stable Diffusion サービスの負荷テスト。4 分間で GPU インスタンス 100 個に到達している。

Cloud Run ジョブで NVIDIA GPU を使用して新たなユースケースを実現

Cloud Run での GPU の使用がメリットとなるのは、リクエストドリブン型の Cloud Run サービスを使用するリアルタイム推論だけではありません。Cloud Run ジョブでも GPU が利用可能になったため、特にバッチ処理や非同期タスクの新しいユースケースが実現します。

モデルのファインチューニング: 基盤となるインフラストラクチャを管理することなく、事前トレーニング済みモデルを特定のデータセットで簡単にファインチューニングできます。GPU を活用したジョブをスピンアップし、データを処理し、完了したらゼロまでスケールダウンできます。
AI 推論のバッチ処理: 大規模なバッチ推論タスクを効率的に実行できます。画像の分析、自然言語の処理、推奨事項の生成など、GPU を使用した Cloud Run ジョブは、さまざまな負荷に対応できます。
メディアのバッチ処理: 動画のコード変換、サムネイルの生成、複雑な画像操作を大規模に行うことができます。

Cloud Run ジョブの GPU の限定公開プレビュー版にご登録ください。

Cloud Run のお客様の声

Google の説明だけでなく、Cloud Run の GPU を早期に導入したお客様の声もご紹介します。

「Cloud Run は、vivo が AI アプリケーションのイテレーションを迅速に行うのに役立ち、運用とメンテナンスの費用を大幅に削減します。自動スケーリングが可能な GPU サービスは、AI の海外展開の効率も大幅に向上させます。」- vivo、AI アーキテクト Guangchao Li 氏

「L4 GPU は、リーズナブルな費用で非常に優れたパフォーマンスを提供します。高速な自動スケーリングと組み合わせることで、費用を最適化し、85% の費用削減を実現できました。Cloud Run で GPU が利用できるようになったことを非常に嬉しく思っています。」- Wayfair、シニアソフトウェアエンジニア John Gill 氏（Next '25 にて）

「Midjourney では、Cloud Run の GPU が当社の画像処理タスクに非常に有用であることがわかりました。Cloud Run は開発者エクスペリエンスがシンプルであるため、インフラストラクチャの管理に時間を取られることなく、イノベーションに集中できます。また、Cloud Run の GPU のスケーラビリティにより、数百万もの画像を簡単に分析、処理できます。」- Midjourney、データチームリーダー Sam Schickler 氏

使ってみる

Cloud Run の GPU は、次世代のアプリケーションを強化する準備が整っています。ドキュメント、クイックスタート、モデル読み込みの最適化に関するベストプラクティスをご覧ください。皆様が構築されるアプリケーションを楽しみにしております。

-プロダクトマネジメント担当ディレクター、Steren Giannini

-エンジニアリング担当ディレクター、Yunong Xiao

Google Cloud の KCC を使用して Waze を Infrastructure as Code に移行

Tue, 13 May 2025 01:00:00 +0000

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

2023 年、Waze のプラットフォームエンジニアリングチームは、Google Cloud の Config Connector（KCC）を使用して Infrastructure as Code（IaC）に移行し、それ以来大きな成果を上げてきました。Waze では、オープンソースの Kubernetes アドオンである Config Connector を採用し、Kubernetes を介して Google Cloud リソースを管理しています。また、管理を効率化するために、Google Kubernetes Engine（GKE）上で Config Connector のホスト型バージョンである Config Controller を活用し、Policy Controller と Config Sync を組み込んでいます。この移行により、インフラストラクチャ管理が大幅に改善され、将来のインフラストラクチャの基盤が築かれました。

Config Connector への移行

Waze は以前、特にデュアルクラウド環境における VM ベースのフェーズでは、リソース管理に Terraform を使用していました。しかし、状態の維持や調整作業が困難であり、構成の一貫性の欠如や、管理オーバーヘッドの増加が発生していました。

そこで、2023 年に Config Connector を採用し、Google Cloud インフラストラクチャを GKE クラスタ内の Kubernetes Resource Modules（KRM）に変換することにしました。このアプローチにより、Terraform で発生していた調整の問題が解決しました。また、Config Sync と Config Connector を組み合わせることで、ソースリポジトリからライブ GKE クラスタへの KRM の自動同期が可能になりました。このマネージドソリューションにより、カスタム調整システムの構築や保守が不要になりました。

この移行により、Waze のインフラストラクチャチームにおける、以下の 3 種類の主要なユーザーのニーズを満たすことができました。

インフラストラクチャの利用者: 基盤となるリソースの保守や複雑さについて心配することなく、インフラストラクチャを簡単にデプロイしたいアプリケーション開発者。
インフラストラクチャオーナー: Google Cloud 上の Waze 全体でリソースの作成方法に関するベストプラクティスの定義や標準化に取り組む、特定のリソースタイプ（Spanner、Google Cloud Storage、ロードバランサなど）の専門家。
プラットフォームエンジニア: インフラストラクチャオーナーがベストプラクティスを体系化および定義するシステムを構築し、インフラストラクチャの利用者にシームレスな API を提供するエンジニア。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud コンテナと Kubernetes をお試しいただける $300 分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7f42dd384b80>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectpath=/marketplace/product/google/container.googleapis.com'), ('image', None)])]>

最初のステップ: Config Connector

Google Cloud インフラストラクチャ全体を Google Cloud サービス内の KRM として定義するのは循環的に思えるかもしれませんが、KRM は既存の IaC ツールとは異なり、実際には Waze のインフラストラクチャを表現するのに適しています。

Terraform の調整の問題（状態のずれ、バージョン管理、帯域外の変更）は、重大な課題です。Config Connector には、Config Sync を通じてすぐに使用できる調整機能が備わっており、これは理想的なマネージドソリューションでした。テンプレート機能は KRM と Terraform のどちらにもありますが、KCC のマネージド機能は Google Cloud ネイティブソリューションへの移行に適しており、メンテナンスの負担も軽減します。

インフラストラクチャの複雑さは、ツールに関係なく一般化する必要があります。これは、以下のように、Spanner に対する Waze の要件を見れば明らかです。

すべての Spanner データベースの一貫したバックアップが必要。
各 Spanner データベースは、専用の Cloud Storage バケットとサービスアカウントを使用して DDL ジョブの実行を自動化する。
一貫性のある監査可能なアクセス制御を確保するために、Spanner インスタンス、データベース、Cloud Storage バケットのすべての IAM ポリシーをコードで定義する。

これらのリソースを定義するために、さまざまなテンプレートツールとレンダリングツールを評価した結果、Kubernetes 向けの堅牢な CNCF パッケージ管理システムである Helm を選択することにしました。その強力なオープンソースコミュニティ、豊富なテンプレート機能、ネイティブなレンダリング機能は、Waze にごく自然に適合できました。現在では、バンドルされたインフラストラクチャ構成を「チャート」と呼んでいます。その後、KRO が登場して、同様の目的を達成できるようになりましたが、上述の選定プロセスは、KRO がリリースされる前のものです。

仕組み

このシステムがどのように機能し、どのように Waze に価値をもたらしているのかを詳しく見ていきましょう。

Waze のインフラストラクチャオーナーが Waze 独自のインフラストラクチャを Helm チャートで汎用的に定義します。
インフラストラクチャの利用者が、これらのチャートを使用して、シンプルな入力でインフラストラクチャを生成します（デモ）。
インフラストラクチャのコードがリポジトリに保存され、検証と送信前のチェックが可能になります。

コードは Artifact Registry にアップロードされ、ここで、Config Sync と Config Connector が Google Cloud インフラストラクチャをコード定義に合わせます。

この図は、バインドされたサービス、データベース、ネットワーク、データのコレクションである単一の「データドメイン」を表しています。現在のテクノロジー組織の多くは、本番、QA、ステージング、開発などの環境で構成されています。

目標へのアプローチ

では、なぜこれが重要なのでしょうか。このアプローチを採用することで、Infrastructure as Code から Infrastructure as Software に移行することができました。各チャートをソフトウェアコンポーネントとして扱うことで、インフラストラクチャ管理は単なるコード宣言を超えたものになります。現在では、チャートと構成がバージョン管理され、高度なリリース管理、自動ロールバック、詳細な変更追跡など、さまざまなソフトウェアプラクティスを活用できるようになっています。

これを実践したのが、冗長性を最小限に抑える構成継承モデルです。Resource チャートは Project から設定を継承し、Project は Bootstrap から設定を継承します。この 3 つはすべてチャートとして定義されています。このため、Bootstrap の構成はすべての Project に適用され、Project の構成はすべての Resource に適用されます。

既存のインフラストラクチャの変更から新しいリソースタイプのロールアウトまで、インフラストラクチャに対するあらゆる変更をソフトウェアのロールアウトのように扱うことができます。

インフラストラクチャ全体がソフトウェアのように扱われるようになったことで、システム全体にどのような効果があるかを確認できます。

目標の達成

まとめると、Config Connector と Config Controller により、Waze は真の Infrastructure as Software を実現し、インフラストラクチャのニーズに応える堅牢でスケーラブルなプラットフォームの他にも、以下のような多くのメリットを得ることができました。

インフラストラクチャの利用者は、バージョン管理されたアップデートを通じて最新のベストプラクティスを入手できるようになりました。
インフラストラクチャオーナーはイテレーションにより、インフラストラクチャを安全に改善できるようになりました。
プラットフォームエンジニアとセキュリティチームは、リソースが監査可能でコンプライアンスを確保していると確信できるようになりました。
Config Connector で Google のマネージドサービスが利用されているため、運用上のオーバーヘッドが削減されました。

-Waze、スタッフサイト信頼性エンジニア Tyler Reid 氏

SaaS デリバリーを簡単に: SaaS ランタイム

Fri, 02 May 2025 01:03:00 +0000

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

Software as a Service（SaaS）ベースのソリューションは、AI を活用した高度なパーソナライズ、業種別ソリューションの増加、ノーコード革命といった要因が追い風となり、急速に需要が高まっています。しかし、これから SaaS プロバイダを目指そうにも、SaaS の構築やスケーリングを成功させようと思うと、怖気づいてしまうのではないでしょうか。課題としては、パーソナライズされたエクスペリエンスの作成が難しいことや、数千におよぶインスタンスの管理が複雑であること、多様なインフラストラクチャに対処しながらパフォーマンスと信頼性の目標を満たす必要があることなどが挙げられます。このような運用上の負担が障壁となり、イノベーションや、優れたカスタマーエクスペリエンスの提供という、本来の目的がおろそかになる恐れもあります。

Google Cloud Next 25 で、Google は SaaS ランタイムのプレビュー版を発表しました。これは、フルマネージドの Google Cloud サービス管理プラットフォームであり、SaaS プロバイダが複雑なインフラストラクチャ運用を簡素化および自動化し、コアビジネスに集中できるようにするものです。SaaS ランタイムは、Google が社内で複数テナントの多数ユーザー向けに使用しているプラットフォームに基づいており、大規模にサービスを管理してきた豊富な経験が活かされています。SaaS ランタイムは、自動化を中心に、大規模な管理を実現する豊富なツールセットを備えており、SaaS 環境のモデル化、デプロイの迅速化、運用の合理化に役立ちます。

SaaS ランタイムの目標は、ソフトウェアプロバイダを以下の点で支援することです。

迅速なリリース、カスタマイズ、イテレーション: SaaS ランタイムは、カスタマイズ可能なビルド済みブループリントを提供するため、迅速なイテレーションとデプロイに役立ちます。シンプルなデータモデル抽象化によって、AI アーキテクチャのブループリントを既存のシステムに簡単に統合することが可能となります。
運用の自動化、テナントのモニタリングおよびスケーリング: SaaS ランタイムはフルマネージドサービスであり、大規模な自動化を実現できます。まず、現在の継続的インテグレーション / 継続的デリバリー（CI / CD）パイプラインから始めて、SaaS ランタイムにオンボーディングし、スケーリングして、クラウドとエッジの両環境でサービス管理、テナントのモニタリング、運用を簡素化できます。
迅速な統合、最適化、拡張: SaaS ランタイムは Google Cloud エコシステムに密接に統合されています。デベロッパーは、新しい Application Design Center でアプリケーションを設計し、Google Cloud Marketplace で提供できます。さらに、アプリケーションをテナントにデプロイした後は、Cloud Observability と App Hub でパフォーマンスをモニタリングできます。この統合アプローチにより、デベロッパーには、ビジネスの詳細情報で拡充されたアプリケーション層の統合ビューが提供され、迅速な統合、最適化、スケーリングを行うことが可能となります。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f42de12bac0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

SaaS ランタイムの仕組み: モデル化、デプロイ、運用

SaaS ランタイムは、モデル化、デプロイ、運用という 3 つのステップで構成される合理化されたプロセスを通じて、SaaS のライフサイクル管理を簡素化します。

たとえば、あなたは SaaS プロバイダで、小売業者が在庫を最適化し、需要を予測し、各店舗の廃棄物を削減できるように、在庫管理アプリケーション（IMS）を SaaS として提供するとします。また、料金階層を設定する、AI 機能でアプリケーションを拡張することも検討しています。Google Cloud でこれを実現する方法を見てみましょう。

1. モデル

SaaS プロバイダとして、まず SaaS ランタイムの推奨データモデルを使用して SaaS アーキテクチャを定義またはインポートします。SaaS ランタイムをスケーリングに利用したい場合は、SaaS ランタイムの推奨モデルフレームワークに基づき、自社のアーキテクチャを再利用することが可能です。具体的には、デプロイとアップデートを一緒に行うコンポーネントをパッケージ化し、複数の異なるブループリントを作成できます。この構造化されたアプローチは、アプリケーションとインフラストラクチャの複雑さを抽象化するため、パフォーマンスと信頼性が高まるように最適化できます。

まず、一般的なソースリポジトリ（GitHub、GitLab、Bitbucket など）を通じて Terraform モジュールをインポートし、ブループリントを作成します。これらのブループリントは SaaS プロダクトの構成要素として機能し、数千のテナントインスタンスに簡単にスケーリングできます。

在庫管理 SaaS のシナリオでは、独立したデプロイと迅速なイテレーションを実現するために、基本インフラストラクチャブループリントと依存 IMS アプリケーションブループリントという 2 つのブループリントの階層構造を使用します。この例では 2 つのブループリントを使用していますが、SaaS ランタイムのブループリントモデルは自由にコンポーズ可能であり、グループ化や依存関係を柔軟にカスタマイズできるため、信頼性を主眼としてさまざまなビジネス目標を達成できます。

2. デプロイ

SaaS ランタイムは、ブループリントのプロビジョニングとオーケストレーションを自動化し、一貫性と信頼性を確保します。この在庫管理 SaaS のデプロイ用に、基本ブループリントおよび IMS ブループリントに対応する 2 つのリリースが作成されます。

続けて、作成されたリリースを使用し、各小売業者に応じたパーソナライズを行ったうえで、それぞれの在庫管理 SaaS インスタンス（テナントインスタンス）をプロビジョニングできます。

3. 運用

SaaS ランタイムの包括的なサービス管理ツールを使って、SaaS 運用を管理、モニタリング、最適化できます。具体的には、以下のことができます。

既存のリリースを大規模にロールアウトする: 基本および IMS のリリースをすべての小売業者にロールアウトするには、ロールアウト機能を使用します。リリースを一度に 1 つずつ選択し、すべてのテナントに一度にロールアウトできます。または、一度に 1 つのリージョンにロールアウトして、安全性および信頼性を確保することもできます。
新リリースをロールアウトする: 在庫管理 SaaS アプリケーションに動的料金最適化などの新しい AI 機能を追加したアップデート版をロールアウトするには、IMS ブループリントに依存する新しい AI ブループリントを作成します。新リリースを作成し、すべてまたは一部の小売業者テナントにロールアウトします。

フィーチャートグル構成を使って新機能をロールアウトする: 一部の小売業者テナントにのみ、プロモーション価格調整などの新機能をロールアウトするには、SaaS ランタイムのフィーチャートグル 機能を使用します。この機能を有効にするには、PromoPricing フラグを true に変更するだけでよく、新しいバイナリアップデートをロールアウトする必要はありません。

ロールアウトとデプロイの進行状況をプロアクティブにモニタリング、制御する: 少数の SaaS インスタンスでロールアウトのドライランを行い、すべてのテナントにロールアウトする前に機能と信頼性を検証することもできます。また、すべてのリージョンとテナントでのロールアウトの進捗状況をモニタリングすることもできます。ロールアウト中に問題が発生した場合は、いつでも一時停止や再開ができます。また、ロールアウトをキャンセルしたり、ロールバックしたり、いったん保留にして延期したりすることも可能です。

aside_block: <ListValue: [StructValue([('title', 'AI SaaS のスケーリング: Avathon の事例'), ('body', <wagtail.rich_text.RichText object at 0x7f42de12b790>), ('btn_text', ''), ('href', ''), ('image', None)])]>

使ってみる

SaaS ランタイムを使用すると、ソフトウェアプロバイダは SaaS サービスのイノベーションとスケーリングを迅速に実現できます。たとえば、在庫管理アプリケーションの例で示したように、合理的な 3 段階プロセスを使用するスマートな SaaS を構築できます。SaaS ランタイムでは、コンポーズ可能なブループリントモデルによって、レイヤごとに独立して開発を行い、迅速にイテレーションを行えます。これらのブループリントをデプロイするという方法によって、個々のテナントに応じてエクスペリエンスをカスタマイズすることが可能となります。さらに、SaaS ランタイムを使うことで、複雑な運用を大幅に簡素化し、多様なテナントグループに対するバージョンおよび機能のロールアウトをきめ細かく制御することができます。

Google Cloud の SaaS ランタイムは現在プレビュー版が提供されており、これを使って SaaS 管理を簡素化および自動化できます。Google Cloud Next 25 のプレゼンテーションの録画をご覧ください。

プロダクトページにアクセスして詳細をご覧になるか、Cloud コンソールでさっそく使用を開始して、今すぐ SaaS の革新を始めましょう。

-プロダクト管理担当ディレクター、Vidya Nagarajan Raman

Gemini を使用してアプリを構築できる Firebase Studio とエージェントデベロッパーツールのご紹介

Fri, 02 May 2025 01:02:00 +0000

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

世界中の何百万もの開発者が Firebase を活用してユーザーとのエンゲージメントを高め、毎日 700 億を超えるアプリインスタンスをあらゆる場所で動かしています。Firebase は、モバイルデバイスやウェブブラウザから、組み込みプラットフォームやエージェントエクスペリエンスに至るまで、幅広い環境で利用されています。しかし、フルスタック開発は急速に進化しており、生成 AI の台頭により、アプリの構築方法だけでなく、実現可能なアプリの種類そのものも大きく変わりました。そのため複雑さが増し、デベロッパーは多くの新しいテクノロジーに追いつくために、手動でそれらをつなぎ合わせなければならず、大きなプレッシャーにさらされています。一方で、あらゆる規模の企業が、AI アプリの開発サイクルをより効率化して質の高いソフトウェアを提供し、市場投入を早める方法を模索しています。

このたび、Google Cloud Next で、Firebase をエンドツーエンドのプラットフォームへと進化させ、アプリケーションのライフサイクル全体を加速する一連の新機能を発表しました。新しい Firebase Studio はすべてのユーザーが利用できるプレビュー版で、Gemini を活用したクラウドベースのエージェント開発環境です。本番環境品質の AI アプリをすばやく作成して公開するために必要な機能のすべてが 1 か所にまとめられています。Firebase プラットフォーム全体でさらにいくつかのアップデートが行われ、デベロッパーは Google Cloud で最新のデータドリブンアプリを活用できるようになります。これらの発表により、デベロッパーは複数のプラットフォームにわたって AI アプリケーションを構築するための新しい道を切り開くことができます。

Firebase Studio のご紹介

昨年、Google は、迅速かつ手軽に AI アプリを構築するために、Firebase の Gemini、Genkit、Project IDX（Code OSS のフォーク）など、多くの新しいサービスをリリースしました。Firebase Studio のリリースにより、これらの機能のすべてが Firebase サービスと Gemini のクリエイティブな力と融合し、新しいネイティブなエージェントエクスペリエンスが誕生しました。

Firebase Studio でフルスタックの AI アプリを構築

新しいアプリでは、60 種類以上の事前構築済みテンプレートから選択するか、アプリのプロトタイピングエージェントを使用して開始します。自然言語、画像、図形描画ツール、スクリーンショットを使用して、UI、API スキーマ、AI フローなどのアプリの設計を支援します。プロトタイプを繰り返し改善し、準備ができたら Firebase App Hosting に直接デプロイしましょう。完全に機能するバージョンのプロトタイプの URL を共有して、フィードバックを得ることや、テストを実施することができます。使用状況や動作をひと目で確認し、Firebase コンソールに移動して詳細なモニタリングを行うことなどもできます。いつでもワンクリックで Firebase Studio のコーディングワークスペース内のアプリを開けます。新たな設定は不要です。アプリでは、アーキテクチャを調整して、機能を拡張して本番環境へのデプロイに備えることができます。

コーディングワークスペースでは、次のことも可能です。

コーディングワークフローを簡素化: コードの記述と機能のテストは、すべて Firebase の Gemini のサポートを受けながら、各ステップごとに進めることができます。デバッグ、テスト、リファクタリング、コードの説明、ドキュメント化など、さまざまなタスクを簡単に実行できます。
既存のアプリを強化: ローカルマシンや GitHub、GitLab、Bitbucket など、git ベースのリポジトリから既存のコードベースをインポートできます。好みの技術スタック用のカスタムテンプレートを作成してチームで共有できます。
フルスタックエクスペリエンスを作成: AI モデルの推論、エージェント、検索拡張生成（RAG）から、ユーザーエクスペリエンス、ビジネスロジック、データベースまで、アプリのあらゆる側面をカスタマイズして進化させます。API やマイクロサービスなどのツールを簡単に公開し、AI アプリに統合できます。
使い慣れたツールで作業: システムツール、拡張機能、環境変数などの特定の構成を持ち込み、ワークスペースをカスタマイズできます。Open VSX Registry から何千もの拡張機能にアクセスできます。
柔軟なデプロイオプション: Firebase バックエンドサービスや Google Cloud Run との組み込みのインテグレーションにより、クラウド上でアプリを実行するように設定できます。独自のカスタムインフラストラクチャにデプロイすることもできます。

Firebase Studio は現在、プレビュー期間中、3 つのワークスペースを無料でお使いいただけます。Google Developer Program のメンバーは、最大 30 のワークスペースを利用できます。ぜひ Firebase Studio をお試しください。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f42dcbfd0a0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ワークフロー全体で AI エージェントを活用

Firebase Studio から Gemini Code Assist エージェントに早期アクセスすることもできます。たとえば、Firebase Studio で移行エージェントを呼び出して Java のバージョン間でコードを移行できます。また、AI テストエージェントを使用して AI モデルに対して敵対的テストを実行し、有害な可能性のある出力を検出して修正できます。さらに、コードドキュメントエージェントを呼び出してコードに関する wiki スタイルのナレッジベースでチャットし、新しいチームメンバーのオンボーディングを簡単に行うこともできます。

Google Developer Program から、Gemini Code Assist エージェントの順番待ちリストに今すぐご登録ください。

Firebase Studio からアクセスできる AI テストエージェント

Firebase App Distribution は、手動テストと自動テストを実行するための統合モバイルアプリテストサービスです。Firebase App Distribution の新しいアプリのテストエージェントは、アプリで実際のユーザーインタラクションをシミュレートできます。たとえば、「ギリシャへの旅行を検索する」という目標を設定したテストを作成します。アプリのテストエージェントは Gemini を使用してその目標を達成するための計画を立て、仮想デバイスまたは物理デバイスで実行します。UI を操作してエージェントが選択したパスを可視化し、直感的な説明とともに詳細な結果（合格 / 不合格）を生成します。アプリのテストエージェントは現在プレビュー版で提供されており、Android アプリで今すぐお試しいただけます。今年中には、さらに多くのプラットフォームに対応する予定です。

Firebase App Distribution の新しいアプリのテストエージェント

新しい AI アプリエクスペリエンスを創出

最先端の AI 機能をアプリケーションに統合する際には、ベストプラクティスや標準が不足していることが課題となります。そのため、Google は開発プロセスを効率化するための堅牢なフレームワーク、SDK、ツールに継続的に投資し、デベロッパーが真に魅力的で革新的なユーザーインタラクションの構築に専念できるよう支援しています。

Genkit の言語サポートの拡張

Genkit は、アプリの AI 機能の構築、テスト、モニタリングの複雑さを軽減します。構造化された出力、ツールの呼び出し、人間参加型インタラクション、検索拡張生成（RAG）、Model Context Protocol（MCP）、マルチモデルオーケストレーションをサポートする、パワフルなエージェントエクスペリエンスを開発します。このたび、Python の早期サポートと Go の拡張サポートを導入することで、お好みの言語でこれを簡単に実現できるようになりました。Vertex Model Garden から Gemini モデル、Imagen 3、Llama や Mistral などの追加モデルにアクセスできます。さらに、Ollama を使用したセルフホスト型モデルや、コミュニティプラグインを通じたサードパーティモデルのエコシステムも拡大しています。

Genkit を使用して構築するには、Firebase Studio でこちらのテンプレートをお試しください。

Genkit は AI 搭載機能の構築を支援します

Vertex AI in Firebase による新しいモデル

Vertex AI in Firebase では、デベロッパーは効率的かつ安全な SDK を使用して、生成 AI をアプリケーションに統合できます。現在では、数千のアプリで使用されています。たとえば、食事計画とショッピングリスト管理アプリの Meal Planner、AI を活用した日記アシスタントの Life、オフラインハイキングマッププロバイダの HiiKER、クリエイター向けソーシャルメディアアプリの Waveful などです。3 月には、Gemini ファミリーのモデルに加えて Imagen 3 モデル（Imagen 3 と Imagen 3 Fast）のサポートが追加されました。これにより、Android、iOS、Flutter、ウェブアプリケーションに画像生成機能を直接組み込むことができます。今回、Gemini モデルの Live API のサポートを追加しました。これにより、音声で質問して回答を得るといった、アプリでの会話型のインタラクションをさらに強化しました。

Vertex AI in Firebase を介して Gemini モデルで使用できる Live API

最新のデータドリブンアプリを加速

Firebase Data Connect と Firebase App Hosting の一般提供も開始され、アプリのアーキテクチャとデプロイプロセスをより細かく制御できるようになりました。

Firebase Data Connect で高度なアプリを構築

Firebase Data Connect は、Google Cloud SQL for PostgreSQL の堅牢な信頼性と、即時に利用可能な GraphQL API と型安全な SDK を提供します。複雑なユーザー関係を扱うソーシャルメディアのアプリ、大規模な商品カタログを扱う e コマースプラットフォーム、組み込みのベクトル検索によるパーソナライズされたおすすめ情報など、幅広いエクスペリエンスを構築できます。

Data Connect では、次のことが可能になります。

スキーマとクエリを簡単に生成: Firebase の Gemini を使用すると、Data Connect のスキーマ、クエリ、ミューテーション、クライアント SDK を自動的に生成し、バックエンドの開発の速度が大幅に向上します。
拡張されたクエリ機能を活用: Data Connect は、ネイティブの集計サポートによりクエリ機能が強化され、深いデータ分析が可能になったほか、アトミックデータ変更や、サーバー値式を使用したトランザクションにも対応し、複雑なオペレーション全体でデータの整合性を確保します。

ウェブフレームワークで構築: ウェブフレームワーク用の生成された型安全なフックとコンポーネントにより、緊密なインテグレーションと合理化されたデータ処理を実現し、動的でデータドリブンなアプリケーションを迅速に開発できます。

Firebase Studio の Firebase Data Connect

Firebase App Hosting でデプロイ

Firebase App Hosting は、最新のフルスタックウェブアプリ向けの、独自の git 中心のホスティングソリューションです。App Hosting は、ビルドから CDN、サーバーサイドレンダリングに至るまで、アプリのスタック全体を管理することで、製品化までの時間を短縮します。GitHub に push するだけで、あとは App Hosting が自動的に処理を行います。App Hosting は、Cloud Build、Cloud Run、Cloud CDN などのエンタープライズクラスの Google Cloud サービス上に構築されています。

このリリースの App Hosting では、次のことが可能になります。

ビルドのテストとトラブルシューティングを簡単に実行: App Hosting にローカルエミュレータが追加され、エラーメッセージが改善されたことで、ビルドの失敗を未然に防ぐことができ、トラブルシューティングが容易になりました。
本番環境のインシデントから数秒で復旧: App Hosting の新しいモニタリング ダッシュボードを使用してアプリのパフォーマンスと健全性を把握し、回帰を発見したらすぐに以前のバージョンにロールバックできます。

Virtual Private Cloud（VPC）に接続: パブリック IP アドレスではアクセスできない Google Cloud プロジェクト内のバックエンドサービス（Cloud Memorystore によるコンテンツのキャッシュ、Firebase 以外のデータベースからのアクセスなど）にアプリからアクセスできるようにします。

Firebase App Hosting の新しいモニタリングダッシュボード

アプリの構築方法だけでなく、ビルドできるアプリの種類も再考する準備をしましょう。これらのプロダクトの詳細については、Firebase に関するブログ記事をご覧ください。皆様が Firebase プラットフォームで作成したものを見れることを楽しみにしています。

-デベロッパー X 担当バイスプレジデント兼ゼネラルマネージャー、Jeanine Banks

アプリケーション モダナイゼーション

Google Cloud と SAP、Agentic Enterprise に向けた青ブループリントを公開

Google Cloud パートナーとのエージェント型エンタープライズの構築と 7 億 5,000 万ドルのイノベーション ファンド

AI エージェントの開発を加速させるための投資

パートナー様が構築したエージェントを Gemini Enterprise で公開

グローバル コンサルティング パートナーが AI トランスフォーメーションを推進できるよう支援

一般的な SaaS プラットフォームを通じて Gemini をより多くのお客様に提供

エージェント時代のパートナー チャネルの構築

エージェントの未来を築く: メディアとエンターテイメント分野の Google Cloud パートナー エコシステムに注目

制作の強化: 手作業からインテリジェントなアシスタントへ

コンテンツの価値向上: 静的なアーカイブからアクティブなアセットへ

グローバル リーチへの拡大: シンプルなストリーミングから視聴者の拡大まで

信頼性の確保: インフラストラクチャから信頼の基盤へ

エコシステムを実際にご覧ください

大手消費者インサイト ブランドが Dataproc を使用して高度なパーソナライズを加速している方法

特徴量エンジニアリングのための高速エンジン

パーソナライズされたエクスペリエンスの提供

未来のビジョンを築く

一元化されたポリシーと分散ロジック: Eventarc Advanced の概要

インテグレーション アーキテクチャの進化

新しいパターン: ポリシーは一元化、ロジックは分散

仕組み: 小売業のイベント メッシュの例

バス: ガバナンス レイヤ

パイプライン: ロジックレイヤと、自律的なチームのイノベーション

アジャイルなインテグレーションに向けた未来

使ってみる

Replit が Google Cloud でエンタープライズ グレードのバイブ コーディングを提供

Google Cloud でのカオス エンジニアリング: 原則、実践、開始方法

カオス エンジニアリングについて

カオス エンジニアリングの原則と実践

カオス エンジニアリングの要素

カオス エンジニアリングを開始する

製薬業界の開発を変革する中外製薬の挑戦：Gemini Code Assist 活用で開発速度は最大 5 倍に

属人化と心理的ハードル、AI 導入前の開発課題

プロトタイピングを加速し、開発文化を変革する Gemini Code Assist

臨床開発、アジャイル開発、データサイエンス ―― 多様な現場での活用事例

開発速度は最大 5 倍に ―― Gemini Code Assist がもたらした定量的・定性的効果

AI との協業時代における、人と組織の在り方

未来への展望：AI と共に創る新しい開発スタイル

シアトル小児病院で医師の作業を迅速化、効率化する AI 搭載アシスタントの舞台裏

Eventarc Advanced で複雑なイベント処理を大規模に簡素化

複雑性に対処するための Eventarc の進化

デベロッパーとオペレーターを支援

Eventarc Advanced の仕組み

新たな可能性を切り開く

次のステップ

Horizon : クラウドでのビルドを加速させる新しい Android Automotive ソリューション

自動車ソフトウェア開発のイノベーションにおける足かせ

HORIZON のご紹介: 共同で未来を切り開く

優れたソフトウェアを実現する主要な機能

自動車 OEM と業界全体に価値をもたらす

Horizon のエコシステム

ルノーグループによる、Google のソフトウェア定義自動車業界ソリューションの活用法

Google Cloud Workstations

AI を活用した Android 開発のための Gemini Code Assist

バーチャル ツイン

SDV 開発のモダナイゼーションによる具体的な効果

ローカルホストからリリースまで: Cloud Run と Docker Compose で AI アプリのデプロイを簡素化

プラットフォーム エンジニアリングを駆使してデベロッパー エクスペリエンスを簡素化 - パート 2

プラットフォームの境界を移動する

マイクロサービスを超えて

プラットフォーム エンジニアリングを駆使して開発者の利便性を強化 - パート 1

ステップ 1: モノリシックからマルチテナントへ

すべての道が成功への道

Sansan の Platform Engineering 戦略：開発者体験 とビジネス価値を最大化する Orbit とは

開発の「痛み」から生まれた共通プラットフォーム「Orbit」

「Orbit」によって、アプリのリリース頻度が 84% 増加など、驚くべき導入効果

Google Cloud 上で実践するメリットと今後の展望

Cloud Run で GPU の一般提供を開始: AI ワークロードの実行が誰にとっても簡単に

Google Cloud の KCC を使用して Waze を Infrastructure as Code に移行

Config Connector への移行

最初のステップ: Config Connector

仕組み

目標へのアプローチ

目標の達成

SaaS デリバリーを簡単に: SaaS ランタイム

SaaS ランタイムの仕組み: モデル化、デプロイ、運用

使ってみる

Gemini を使用してアプリを構築できる Firebase Studio とエージェント デベロッパー ツールのご紹介

Firebase Studio のご紹介

アプリケーションモダナイゼーション

Google Cloud パートナーとのエージェント型エンタープライズの構築と 7 億 5,000 万ドルのイノベーションファンド

グローバルコンサルティングパートナーが AI トランスフォーメーションを推進できるよう支援

エージェント時代のパートナーチャネルの構築

エージェントの未来を築く: メディアとエンターテイメント分野の Google Cloud パートナーエコシステムに注目

グローバルリーチへの拡大: シンプルなストリーミングから視聴者の拡大まで

大手消費者インサイトブランドが Dataproc を使用して高度なパーソナライズを加速している方法

インテグレーションアーキテクチャの進化

仕組み: 小売業のイベントメッシュの例

バス: ガバナンスレイヤ

Replit が Google Cloud でエンタープライズグレードのバイブコーディングを提供

Google Cloud でのカオスエンジニアリング: 原則、実践、開始方法

カオスエンジニアリングについて

カオスエンジニアリングの原則と実践

カオスエンジニアリングの要素

カオスエンジニアリングを開始する

バーチャルツイン

プラットフォームエンジニアリングを駆使してデベロッパーエクスペリエンスを簡素化 - パート 2

プラットフォームエンジニアリングを駆使して開発者の利便性を強化 - パート 1

Sansan の Platform Engineering 戦略：開発者体験とビジネス価値を最大化する Orbit とは

Gemini を使用してアプリを構築できる Firebase Studio とエージェントデベロッパーツールのご紹介

新しい AI アプリエクスペリエンスを創出