顧客事例

AI が自らモデルを進化させる時代へ。カインズが AlphaEvolve で需要予測の誤差を 19% 改善

Fri, 30 Oct 2026 01:00:00 +0000

全国に 281 店舗以上のホームセンターを展開し、独自のプライベートブランド（PB）商品の開発やデジタル戦略に注力する株式会社カインズ（以下、カインズ）。同社では、膨大な商品の発注・在庫管理を最適化するため、Google Cloud を基盤とした需要予測プロジェクトを推進しています。本記事では、アルゴリズムを自律的に進化させる AlphaEvolve（プレビュー版）を導入し、3 年間のチューニングの壁を突破して需要予測の誤差を 19% 改善した取り組みについて、同社の矢口氏と神戸氏にお話を伺いました。

利用しているサービス:
BigQuery、AlphaEvolve

全店舗・最大 3,000 万行におよぶ需要予測の歩みと、属人化からの脱却

カインズにおける需要予測プロジェクトは 2021 年 11 月に発足し、約半年間のプロトタイプ検証を経て、2022 年 6 月にミニマムでの本番運用をスタートしました。その後、段階的に対象を拡大し、2024 年 9 月には約 200 店舗、2025 年 10 月には全店舗へと展開を完了しています。

現在、同社では大きく分けて「長期予測」と「短期予測」の 2 つの軸で需要予測モデルを実行しています。

長期予測（PB 商品の海外生産向け）：カインズが注力する PB 商品は海外で生産されるケースが多く、長いリードタイムが求められます。そのため、食品から雑貨まで全カテゴリーにわたる約 1 万 SKU を対象に、単品別で 39 週先の需要予測を行っています。
短期予測（店舗の自動発注・在庫管理向け）：店舗の在庫が一定水準を下回った際に自動で発注を行う「自動発注点管理」に用いられます。店舗の限られた在庫スペースを最適にコントロールするため、店舗別・単品別（SKU 別）に 6 週先の細かい予測を実施しています。通常時で約 190 万 SKU、繁忙期には最大 500 万 SKU（× 6 週間分で約 3,000 万行）という膨大な規模の予測を処理しています。

この仕組みを導入する以前、長期予測においては各ディストリビューターの経験や個人のオペレーションマニュアルに依存しており、担当者のスキルによって発注精度にばらつきが生じることが課題でした。また、短期予測においても、従来は表計算ソフトで前年や直近の実績をもとに発注点を管理していましたが、直近実績だけでは季節性商品の立ち上がりを捉えきれず、欠品が発生するなどの課題を抱えていました。

Google Cloud の Vertex AI Forecasting を用いた需要予測モデルの導入により、新任の担当者であっても一定の精度を担保した発注が可能になり、店舗における欠品削減など着実な成果を上げてきました。

3 年間の試行錯誤で見えてきた、人間による特徴量設計とモデル改善の限界

全店展開によって一定の成果を上げていたカインズですが、運用を続ける中でさらなる精度向上に向けた「壁」に直面していました。当時の課題について、矢口氏は次のように振り返ります。

「一番の課題は、モデルの改善における試行錯誤の限界でした。私たちは週に 1 回、業務ユーザーと打ち合わせを行い、『ピークにもっと追従してほしい』『特定のイベントによる特需の影響は来年の予測から除外してほしい』といったドメイン知識や要望をヒアリングし、特徴量の出し入れやハイパーパラメーターの調整を行っていました。しかし、人間が自分で考えて調整し、検証を回すやり方では、試せる回数にも限界があり、本当にこのモデルが最適なのかを追求しきれないという実情がありました。」（矢口氏）

また、新商品が投入された際に既存商品の売上が分散する「カニバリゼーション（社内競合）」の予測も難題の一つでした。月 1 回のモデル再学習を行っていたものの、新商品の売れ行きトレンドが実績として現れるまでにはタイムラグが生じるため事前の予測が難しく、実績が出始めた後のトレンド変化やカテゴリー内の需要分散を素早く捉えるための特徴量設計も複雑を極めていました。3 年間にわたり PDCA を回し続けた結果、人間の手作業によるチューニングではこれ以上の改善は難しいという手詰まり感が生まれていたのです。

自律的にアルゴリズムを進化させる「AlphaEvolve」との出会い

この状況を打破するきっかけとなったのが、2026 年 4 月頃に矢口氏が目にした Google のブログ記事で紹介されていた「AlphaEvolve」でした。AlphaEvolve は、AI が自律的にアルゴリズムの最適化やモデルの進化を行うエージェント技術です。一般的なコーディング支援 AI との違いについて、矢口氏は次のように語ります。

「一般的な LLM やコーディングエージェントでも、対話を通じて『こういう特徴量やパラメーターが良いのではないか』という提案やサポートはしてくれます。しかし、それを実際に実行して結果を確認し、ダメなら次の手を考えるというプロセス自体は、結局人間がワンショットで 1 回ずつ回さなければなりません。これでは既存の作業が多少早くなるだけで、本質的な改善にはなりませんでした。私たちが求めていたのは、実行結果を踏まえて AI 自身が自己学習的に新しいパラメーターや特徴量を何百、何千と自動で試し、テストと検証を繰り返して最適解を導き出してくれる仕組みでした。AlphaEvolve を見たとき、『これならモデルの改善を自動でやってくれるのではないか』と強い可能性を感じました。」（矢口氏）

「需要予測の精度を高める」という明確な評価指標を持っていたカインズにとって、目標に向かって自律的にアルゴリズムを進化させる AlphaEvolve はまさに理想的なソリューションでした。さらに、実業務へ導入する上では、Antigravity などのコーディングエージェントと AlphaEvolve を組み合わせることで大きな相乗効果が得られたと矢口氏は続けます。

「AlphaEvolve は自律的にモデルを進化させてくれますが、その土台となる初期プログラムの作成や、データリークを防ぎつつ精度を正しく測る評価ロジックの設計、さらには生成されたモデルの本番パイプラインへの組み込みなどを AlphaEvolve 単体で行うのは正直なところ簡単ではありません。そうした周辺の実装や検証環境の構築をコーディングエージェントにサポートしてもらい、コアとなる何百・何千回のアルゴリズム探索を AlphaEvolve に任せるという組み合わせが非常に相性が良く、実践におけるハードルを大きく下げてくれました。」（矢口氏）

予測誤差を 19% 削減し、複数モデルの統合による運用効率化とコスト削減を実現

カインズは AlphaEvolve を長期予測モデルの本番環境に導入し、劇的な成果を上げています。長期予測モデルの改善を担当する神戸氏は、その定量的なインパクトについて次のように語ります。

「私がジョインしてから約 3 年間、長期モデルの改善を段階的に行ってきましたが、手詰まり感があった中で AlphaEvolve を使ったアルゴリズム改善に取り組んだ結果、予測の誤差を一気に 19% 改善することができました。3 年間かけて人間がチューニングしてきたものから、さらに 19% 跳ね上がったというのは非常に大きな成果です」（神戸氏）

さらに、AlphaEvolve の導入は精度向上だけでなく、システム運用の効率化とコスト面でも大きなメリットをもたらしました。

複数モデルの統合による汎用性の向上：従来は販売数量などの条件に応じて複数のモデルに分割して予測を行っていましたが、AlphaEvolve によって生成されたアルゴリズムは極めて汎用性が高く、すべてを「1 つのモデル」に統合した上で 19% の誤差改善を達成しました。
運用負荷とコストの削減：これまで Vertex AI Forecasting で複数のモデルを稼働させていた環境を、AlphaEvolve による単一の高精度モデルへと置き換えたことで、管理・運用の手間が大幅に軽減されるとともに、ランニングコストの削減も実現しました。

今後の展望：人が特徴量を考える時代から、AI が自らモデルを進化させる時代へ

新しい長期予測モデルが本番稼働を開始して約 4〜5 週間が経過し、現在は 13 週〜39 週先のリードタイムに向けた予測が進行しています。また、AI がカテゴリー内の需要変化を捉える特徴量を自律的に探索できるようになったことで、従来は人手での対応に限界があったカニバリゼーションに伴う需要変動に対しても、今後さらに改善していける可能性が見えてきています。今後は、予測精度が向上したカテゴリーにおいて、実際の店舗やサプライチェーンでの欠品削減や在庫水準の最適化にどれだけの経営インパクトが表れるか、効果測定を楽しみにしていると語ります。

最後に、今回の実績を踏まえ、これから需要予測や機械学習のビジネス活用を目指す企業へのメッセージとして、矢口氏は次のように締めくくりました。

「これまでもノーコードやローコードのツールを使えば、機械学習モデルを『作ること』自体はできました。しかし、実務で使えるレベルまでモデルの精度を高めるには、経験豊富な AI/ML エンジニアが試行錯誤して特徴量を考えたりチューニングしたりする必要があり、十分な精度が出せないことが壁となってビジネスへの機械学習の適用はなかなか進みませんでした。しかし、AlphaEvolve に目標を与えれば、パラメーターの調整だけでなくドメイン特有の特徴量まで AI が自ら生成し、モデルを進化させてくれます。専門の AI/ML エンジニアがいなくてもモデルの精度を高めることができるため、需要予測に限らず、ビジネスにおける機械学習の適用可能性が飛躍的に高まっていくと考えています。」（矢口氏）

株式会社カインズ
株式会社カインズは、全国に 289 店舗を展開するホームセンターチェーンです。「くらし DIY 」をブランドコンセプトに、くらしを豊かにする価値ある商品・サービスを開発し、お値打ち価格で毎日提供します。Kindness（親切心）と創意工夫のアイデアあふれる店舗づくりに努めることで、お客様一人ひとりの、ご家族の、そして地域の日常を楽しいものとし、お客様とのプロミスである「くらしに、ららら。」をお届けします。

インタビュイー
株式会社カインズ　
ビジネスソリューション部需要予測グループ　グループマネジャー　矢口未知彦氏
ビジネスソリューション部需要予測グループ　データサイエンティスト　神戸佑太氏

インタビュアー
グーグル・クラウド・ジャパン合同会社
シニアアカウントエグゼクティブ　西森万晃
カスタマーエンジニア　遠山雄二

Sky: Gemini を全社で一斉に導入し、98% の利用定着率と 2,000 個近いエージェントの共有を実現

Thu, 29 Oct 2026 01:00:00 +0000

「AI に強く、AI を使いこなす会社」を目指す Sky株式会社（以下、Sky）は、内製の AI ツールで活用の土台を構築。さらに後継のツールとして Gemini を全従業員約 5,000 名へ一斉配布し、大きな成果を上げています。単なる「業務効率化」ではなく「業務プロセスそのものの変革」を目指すアプローチ、そして具体的な成果について、改革を牽引する AI Innovation Lab の 2 名に伺いました。

利用しているサービス:
Gemini, Gemini Notebook など

利用しているソリューション:
生成 AI

「SKYAI」の内製開発で定着した AI 活用文化を、いかに発展させるか

クライアント運用管理ソフトウェア「SKYSEA Client View」や営業名刺管理サービス「SKYPCE」などで知られる Sky は、自社商品を開発・提供する ICT ソリューション事業と、顧客のシステム開発を担うクライアント・システム開発事業を両輪としています。そんな同社の特長の 1 つは、現場のニーズに応じてソリューションを独自に開発する企業文化です。社内システムも大部分を内製しており、その数は約 200 にのぼります。

事実、生成 AI が登場すると、同社は対話型の生成 AI サービス「SKYAI」を独自開発して全社に提供。自律型リサーチ機能「Deep Research」が普及したときにも、「SKYAI Deep Research」を自力で開発しています。こうしたプロジェクトを牽引してきたメンバーが集まって誕生したのが、社内の AI 専門チームである AI Innovation Lab です。同 Lab 課長の須藤康正氏は、一連の開発プロジェクトの狙いを次のように説明します。

「AI Innovation Lab は、会社のスタイルを構築しつつ、代表が掲げる理念をサービスや機能という形で体現していく、Skyスタイル部に所属しています。『SKYAI』と『SKYAI Deep Research』には、皆の業務を便利にするという目的以上に重要な役割がありました。AI を使うということを従業員のスタイルとして根付かせていくことです。」（須藤氏）

ウェブ検索機能やプロンプト評価機能の実装、全従業員向けの研修といった取り組みもあり、SKYAI の月間利用率は最終的に 90% に達しました。しかしここで須藤氏は、大きな決断を迫られます。SKYAI の継続に注力すれば、新たな AI システムの開発ができなくなるからです。保守部門に運用を引き継ぐ選択肢もありましたが、須藤氏は「攻めの決断」を下しました。

「SKYAI は役割を果たしたと判断し、サービスを終了することにしました。ただし従業員には、代わりとなる AI ツールが必要になりますので、検討に入りました。そこで念頭に置いたのは『どのツールを選ぶか』ではなく、『我々は AI を会社の中でどう使いたいのか』『我々が目指している AI の活用スタイルを育むためには、ツールはいかにあるべきか』というものでした。」（須藤氏）

横断検索の精度、データ連携、ガバナンスを評価して Gemini を選定

このような問題意識に基づき、最終的に選ばれたのは Gemini でした。その際にまず検証されたのは、横断検索の精度だったといいます。同社では高機能な AI を使うことがすでに当たり前となっており、検索精度が低いとユーザーがすぐに離れていくことが懸念されたからです。

「社内で Deep Research を内製していたときには、ナレッジグラフを作っていかなければなりませんでした。また、ベクトル化やチューニング、チャンクサイズの調整など、多くの試行錯誤を繰り返していましたが、企業向け Gemini を採用してみると、我々が作ったシステムと同等以上の精度がすぐに得られました。これはまさに驚きでした。」（須藤氏）

次に検証されたのはデータ連携です。同社は Google Workspace を導入していませんが、企業向け Gemini には、サードパーティ SaaS 向けのコネクタが数多く用意されているため、多様なプラットフォームとのデータ連携は容易に実現できました。そして 3 つ目が、ガバナンスとセキュリティです。同社は顧客のシステム開発も担っているため、エンタープライズ利用を想定したアクセスコントロール、法務部門との調整に必要な情報の確保、知的財産の侵害リスクに備える IP 補償、EnterpriseWebSearch との統合などが不可欠になります。これらの機能が揃っていたことも、採用の後押しとなりました。

「セキュリティについては、条件が『保証されている』『明文化されている』ことを重視しています。Google Cloud は AI 活用におけるセキュリティの担保にも非常に慎重かつ真摯に取り組んでおり、我々が目指しているのと同じ方向で、安全性を追求できるのではないかと感じました。」（須藤氏）

これらの検証を踏まえて、2026 年 1 月、Sky は Gemini の利用を開始。「スタイルは従業員全員で作る」という指針のもと、約 5,000 名の全従業員に一斉に展開しました。これはかなり思い切った決断でしたが、現場ではさまざまな成果が生まれ始めています。AI Innovation Lab 課長代理の帯野幸司氏は、最初の例として、新メンバーのオンボーディングを挙げました。

「従来は新しいメンバーに大量の資料を渡して読んでもらう形になっており、どこまで理解しているかが、なかなか正確に把握できませんでした。しかし、社内の業務情報を部署ごとに整理して Gemini Notebook に読み込ませるようにしたところ、AI との対話を通じて新メンバーが自律的に学習し、疑問点を自己解決できるようになりました。これによりオンボーディング期間が大幅に短縮されています。また、従業員が自律的に部署のノウハウを蓄積し、データを共有する際の形式まで意識してくれるようになりました。これも思わぬ効果です。」（帯野氏）

次の好例は、上長の簡易クローン構築によるコミュニケーションの効率化です。

「上長に案件のレビューや相談を依頼したくても、時間を確保してもらうのが難しいのが実情です。幸い、Sky には従業員が日頃感じていることや考えていることを社内ブログにアウトプットする文化があるので、そこから上長の思考スタイルを Markdown にまとめ、Gemini でエージェント化しました。メンバーだけでなく上長も含め、双方の時間が短縮できています。」（帯野氏）

さらに帯野氏は、Deep Research を使った検索の充実にも触れました。

「以前は AI 活用研修を企画する際にも、ウェブ上の他社事例と社内の過去の研修内容を別々に調べる必要があり、手間がかかっていました。しかし、社内情報とウェブの情報を横断的に検索することにより、自社の実情や過去の文脈に合った精度の高いリサーチができるようになりました。」（帯野氏）

「従業員が AI と一緒に働く」環境を構築し、独自のスタイルを追求

Gemini のアクティブユーザー数は、展開後約 2 か月で急増した後に高止まりしており、定着率は 98% というきわめて高い水準を維持しています。帯野氏は「Gemini が物珍しさだけで使われているのではなく、日々の業務に不可欠なツールとしてほぼすべての従業員に受け入れられ、継続的に利用されていることを示していると考えられます」と解説します。

事実、現場主導で Gemini の活用が広がったことにより、Sky では 2,000 個近くのエージェントが従業員によって開発され、広く共有されるようになりました。その結果、エージェントの検索が困難になるという嬉しい悩みも発生しましたが、この問題は Google Cloud のサポートによって解決されています。

「検索機能の問題もそうですが、エンタープライズユースで『こういう機能が欲しい』と相談すると、いつもすごく真摯に解決案を提案してもらえます。製品の機能とは別に、これも Google Cloud と仕事をしていくうえですごく良いと感じている点です。」（須藤氏）

Sky における AI 活用は、既存業務の強化を目的としたものから、「業務プロセスを変える」ものへ、そして「従業員が AI と一緒に働くようなスタイル」を実現させるものへと進化してきました。導入成果の測定に関しては KPI を設定せず、各部署に独自の基準作りを委ねる一方、活用度そのものを全社共通で評価できる「PAM」というシステムも新たに構築されています。また最近では、自社を「ゼロカスタマー（最初の顧客）」に設定した商品開発でも、AI を活用する方法が模索され始めています。最後に須藤氏は、Gemini に寄せる信頼の大きさを改めて語りました。

「2026 年 7 月には、AI Innovation Lab に『AI 社員』が参加しました。AI は業務のチャットログを常にチェックしており、自分ができる業務をどんどん代行していきます。私たちはこうして生まれた時間を、新たな創発的な業務に 100% 投下していく予定です。生成 AI の活用は、単なるツールの導入に終わらせるのではなく、企業が目指す『スタイル』を明確に思い描き、AI ネイティブな業務改革を進めていくことが重要です。その点、Gemini は私たちにとって、最も使いやすいツールになっています。」（須藤氏）

Sky株式会社
1985 年 3 月 2 日設立。クライアント運用管理ソフトウェア「SKYSEA Client View」や営業名刺管理サービス「SKYPCE」などの自社商品を開発・提供する ICT ソリューション事業と、顧客のシステム開発を担うクライアント・システム開発事業を両輪に事業を展開している。「AI に強く、AI を使いこなす会社」を掲げ、AI 活用による DX やサービス開発などに取り組む。従業員数は 4,655 名（2026 年 10 月 1 日現在）。

インタビュイー（写真右から）
・Skyスタイル部 AI Innovation Lab 課長須藤康正氏
・Skyスタイル部 AI Innovation Lab 課長代理帯野幸司氏

▼ セッション動画を観る
本事例のインタビュイーによるセッション動画が公開中です。あわせてご覧ください。
【Next Tokyo 26 セッション】ツール導入ではない、企業のスタイルを創る「AI 戦略」としての Gemini Enterprise

▼他の導入事例記事を読む
その他の Google Cloud 導入事例はこちらをご覧ください。

ZenteiQ、llm-d を搭載した GKE Inference Gateway でバッチ推論のスループットを 4 倍に拡大

Thu, 29 Oct 2026 01:00:00 +0000

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

今回は、Indian Institute of Science（IISc）からスピンアウトした AI スタートアップである ZenteiQ についてご紹介します。IndiaAI Mission の対象企業として選出された同社は、自国主導の科学基盤モデルをゼロから構築することを目指しています。物理法則、支配方程式、数値ソルバーを理解するモデルを事前トレーニングするため、ZenteiQ は、複数のモデルファミリーにわたって動作し、検証済みのデータセットをトレーニング実行にフィードする、大規模なバッチ合成データ生成パイプラインを設計、構築しました。Google Kubernetes Engine（GKE）と GKE Inference Gateway を活用して、ZenteiQ はパイプライン内に推論ルーティングレイヤを構築し、推論の総スループットを 4.07 倍に拡大するとともに、1 日あたりの出力をアクセラレータ 1,000 個あたり 14 億 7,000 万トークンから 59 億 7,000 万トークンに増加させました。 - Google Cloud、プロダクトマネージャー、Fisayo Feyisetan

主にウェブ上のテキストやコードを使用してトレーニングされた汎用言語モデルとは異なり、科学基盤モデルは、熱力学、計算流体力学、電磁気学などの分野にわたる複雑な物理システム、数学的支配方程式、数値ソルバーを理解する必要があります。ZenteiQ では、シミュレーション出力を解釈し、方程式の定式化を評価し、物理法則に従って段階的に数学的導出を行う、自国主導の科学基盤モデルをゼロから構築しています。

支配方程式の大規模なデータセットを使用してモデルを事前トレーニングするには、数千億もの推論トークンが必要です。ZenteiQ では、キュレートされた科学文献やシミュレーションデータセットに加え、独自に設計、実装したバッチ型合成データ生成パイプラインも利用しています。このパイプラインは、候補となる導出やソルバー検証問題を生成、評価、フィルタしてから、MaxText の事前トレーニングジョブにフィードします。

ZenteiQ は演算リソースの割り当てを固定して運用しているため、アクセラレータがトレーニングデータの生成と検証に 1 時間費やすごとに、事前トレーニングに使える時間が 1 時間減少します。データ生成に遅れが生じると、事前トレーニング用に予約されたマルチホストアクセラレータクラスタは、データセット待ちのアイドル状態になります。

データ生成が事前トレーニングの遅れにつながるケース

データの生成速度を最大化するため、パイプラインでは、ワーカー Pod でのプロンプトの準備と、マルチノードアクセラレータプールにおける vLLM でのモデルサービングを分離しています。各バッチは 4 つの段階を経て処理されます。科学的なシードコンセプトのプロンプトバッチへの拡張、生成モデルによる推論トレース候補の生成、評価モデルによる回答のスコアリング、別のモデルファミリーによるガードレールチェックを実行した後、検証済みのデータセットを事前トレーニング用にパッケージ化します。

当初、これらのモデルプールは Kubernetes 上で運用され、推論エンドポイント間で標準的な ClusterIP によるラウンドロビン方式のロードバランシングが行われていました。90 億パラメータおよび 350 億パラメータというモデルスケジュールに対応できるようパイプラインをスケールアップしたところ、2 つのルーティングボトルネックが発生し、データセットの作成が遅れ始めました。

不均一なエンジンキュー: アップストリームのワーカー Pod は、シードコンセプトを複雑さやレスポンス長が大きく異なるプロンプトへと展開します。標準的なラウンドロビン方式のロードバランシングでは、vLLM のエンジンキュー状況を可視化できないため、近くのノードに余力があるにもかかわらず、長い推論トレースの処理ですでにビジー状態になっているサービング Pod に新たなリクエストを送り続けていました。
冗長なプレフィックス計算: 生成バッチ内のプロンプトでは、指示コンテキストやタスク仕様の約 70～80% が共通しています。ラウンドロビン方式のルーティングでは、同じ指示を含むリクエストが異なるサービングインスタンスに分散されるため、各 Pod はアクセラレータメモリ内のウォームキャッシュを再利用できず、同じ共有プロンプトプレフィックスをゼロから再計算しなければなりませんでした。

不均一なキューと冗長なプレフィル作業が重なることで、1 回の実行における生成スループットが最大半分まで変動し、データセットの作成が長引き、スケジュールされていた事前トレーニングの開始が遅れてしまいました。そのため、研究者にモデル開発を中断させてカスタム推論スケジューラを構築、保守させることなく、vLLM キューの深さやプロンプトキャッシュをリアルタイムで把握できるルーティングが必要でした。

llm-d を搭載した GKE Inference Gateway による基盤構築

ZenteiQ ではすでにデータの準備と MaxText の事前トレーニングジョブを GKE で実行しているため、チームは同じ Kubernetes プラットフォーム上でデータ生成とモデルトレーニングを管理できます。Google Cloud からの推奨事項に従い、基盤となる科学的手法やパイプライン設計を変更することなくルーティングのボトルネックを解消できるよう、オープンソースの llm-d 分散推論フレームワークを搭載した GKE Inference Gateway を、vLLM アクセラレータプールの前にデプロイしました。

このパイプラインでは、ワーカー Pod が Cloud Storage から科学的なシードドキュメントやドメイン分類体系を取得し、それらをマルチステッププロンプトのバッチへと展開します。これらのバッチは、すべてのモデルファミリーおよびサービングノード間のトラフィックを管理する、単一の GKE Inference Gateway デプロイを経由して処理されます。

モデル階層ごとに独立したルーティングを維持するのではなく、生成リクエスト、評価クエリ、ガードレールチェックを、同じゲートウェイ経由でそれぞれのモデルプールにルーティングします。候補となる回答が評価とガードレールチェックに合格すると、ワーカー Pod が検証済みデータセットの重複排除とパッケージ化を行い、GKE 上のダウンストリームの MaxText 事前トレーニングジョブで直接使用できるようにします。

GKE Inference Gateway は、検証済みデータセットを MaxText の事前トレーニングにフィードする前に、vLLM を実行しているマルチノードアクセラレータプール全体に、バッチ生成、評価、ガードレールの各リクエストをルーティングします。

ラウンドロビン方式から負荷とキャッシュを考慮したルーティングへ

GKE Inference Gateway と llm-d を導入すると、ルーティングの決定には、静的なラウンドロビン方式のローテーションではなく、vLLM インスタンスからのリアルタイムのサービングシグナルが使用されます。GKE Inference Gateway は、vLLM エンドポイント全体のリアルタイムのキュー深度や Key-Value（KV）キャッシュの使用率を継続的にモニタリングします。サービングノードが長い方程式の導出のデコード処理でビジー状態になっている場合、ゲートウェイは受信リクエストを処理能力に余力のあるノードにルーティングします。そのため、近くのノードがアイドル状態であるにもかかわらず、ビジー状態のワーカーの後ろに負荷の高いプロンプトが溜まることはなくなります。

同時に、ゲートウェイは、科学的指示が一致するリクエストを、そのプレフィックスの KV キャッシュがアクセラレータメモリ内ですでにウォーム状態にあるサービングノードにルーティングします。各プロンプトの 70～80% は指示コンテキストが共通していますが、生成される推論の軌跡はリクエストごとに異なります。プレフィックスキャッシュの局所性とキューのリアルタイムバランシングを組み合わせることで、Pod は単一のレプリカに過負荷をかけることなく、繰り返しのプレフィル作業をスキップできるようになります。

スループットの向上とトレーニング実行の予測可能性

llm-d を搭載した GKE Inference Gateway を導入したことで、データ生成パイプラインの処理速度と予測可能性が向上しました。本番環境クラスタ全体で、インテリジェントルーティングにより以下が実現しました。

フリートのスループットが 4 倍に向上: アクセラレータ 1,000 個あたりの総スループットが毎秒 16,964 トークンから 69,114 トークンに急増し、1 日あたりの出力が 14 億 7,000 万トークンから約 60 億トークンに増加しました。
個々のモデルプール全体で 3.5～5.5 倍のパフォーマンス向上: リアルタイムのキューバランシングにより、各実行を通じてサービングノードの負荷が均等に保たれ、時間のかかる推論導出に起因する実行中の速度低下が防止されました。
プレフィックスキャッシュヒット率が 14 パーセントポイント向上: 科学的指示が一致するプロンプトをウォームキャッシュにルーティングすることで、各リクエストが独自の導出に分岐する前に、冗長なプレフィル作業を回避しました。

研究チームとインフラストラクチャチームにとって、最も重要な成果はスケジュールの予測可能性でした。1 日の出力が 4 倍になったことで、検証済みデータセットが時間どおりに準備され、データ生成を待つことなく、マルチホストの事前トレーニングがスケジュールどおりに開始されるようになりました。

ZenteiQ における物理 AI の今後の展開

科学基盤モデルを 90 億パラメータから 350 億パラメータ以上へとスケールアップするにあたり、トレーニング後の強化学習（RL）と自動数値ソルバー評価ループにも、これと同じ GKE Inference Gateway と llm-d ルーティング設定を使用する予定です。マルチターンロールアウトでは、各ターンが前のターンのコンテキストに基づいて構築されるため、キューのリアルタイムバランシングとウォームプレフィックスキャッシュへの依存度がさらに高くなります。

これらの機能を独自のワークロードで試すには、GKE Inference Gateway のドキュメントと、オープンソースの llm-d プロジェクトをご覧ください。また、Gemini プラットフォームチームが GKE Inference Gateway を使用してレイテンシを 35% 抑えた方法もご確認ください。

- ZenteiQ、創業者、Sashikumaar Ganesan 教授

- Google Kubernetes Engine、プロダクトマネージャー、Fisayo Feyisetan

Gemini エージェントがスタートアップにもたらすメリット

Wed, 28 Oct 2026 01:20:00 +0000

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

小規模なチーム、限られたランウェイ、そして常に迅速なプロダクト提供を求められるプレッシャー。これは、Google for Startups が日々ともに働く起業家たちが直面している現実です。会社をゼロから立ち上げる際、運用上のオーバーヘッドやインフラストラクチャ構築に費やす時間は、コアプロダクトの開発に割くべき時間を削ることになります。

先週開催された Gemini at Work 2026 で、Google は Gemini エージェントを発表しました。これは、パーソナルアシスタントとしても、チームの専任メンバーとしても機能する汎用エージェントです。そして今週、新しいフロンティアモデルである Gemini 4 Argon の一般提供を開始しました。このモデルは、長時間のマルチステップタスク全体を通してコンテキストを維持するようにトレーニングされています。

ここでは、Gemini エージェントの仕組み、創業者に役立つ 5 つのポイント、そしてスタートアップが実力以上の成果を上げるためにこれをどう活用しているかをご紹介します。

Gemini エージェントとは

文書作成、コーディング、データ分析ごとに、別々の chatbot にプロンプトを入力する必要はもうありません。Gemini エージェントなら、1 つのエージェントが大まかな目標を理解し、完成した成果物まで仕上げて提供します。これは、次の 3 つの原則によって定義されます。

統合型: 1 つのエージェントで、ナレッジワーク、データ分析、クリエイティブアセットの生成、コードの記述と実行を処理できるようになりました。複雑なジョブの場合、専用の一時的なサブエージェントを動的にスピンアップし、それらの作業を並列または順次連携させます。
どこからでもアクセス可能: ウェブ、コマンドライン、デスクトップ、モバイルなど、日常的に使うあらゆる環境で動作します。さらに、Gmail、ドキュメント、スプレッドシート、スライド、ドライブ、Chat、カレンダーにもネイティブに対応しています。
永続性: クラウド上で動作し、4 つの領域（セッション、セマンティック、手続き、エピソード）にわたって連続的なメモリーを保持します。新規採用者のように自ら業務に慣れ、チーム、ツール、ビジネスコンテキストを学習するため、プロンプトごとに自社について説明し直す必要はありません。また、ノートパソコンを閉じた後も、数日間にわたるタスクを進め続けることができます。

5 つの役割を同時にこなす創業者にとって、Gemini は、カレンダー、プロジェクト、ドキュメントの状況をすでに把握している「デジタル参謀」のように機能します。マーケットトレンドの調査、スプレッドシートでの財務モデル作成、そしてその両方を網羅した提案資料の作成まで、各ステップでプロジェクト概要や目標を繰り返し説明することなく、Gemini にまとめて依頼できます。また、先回りして自発的に機能します。投資家から最新のプロダクトアップデートを資料として求めるメールが届くと、Gemini がそのリクエストを検知して処理を提案します。ワンクリックで作業が完了し、すぐに共有やレビューが可能な状態で手元に戻ってきます。

スタートアップ向けの 5 つの重要ポイント

1. コワーカーエージェントとスキルでアウトプットを拡大

個人のアシスタント機能にとどまらず、チーム全体と連携する持続的なコワーカーエージェントを作成することもできます。各エージェントには、それぞれ専用の Workspace アカウント、メールアドレス、ドライブストレージ、ディレクトリ情報が付与されます。リリースコーディネーター、QA トリアージ担当者、財務アナリストといった特定の役割を設定すれば、チームメンバーは Chat スペースにエージェントを追加したり、Google ドキュメントのコメントで @名前リンクを追加したりして作業を委任できます。

また、エージェントに再利用可能なスキルを持たせるだけでなく、Gemini が業務プロセスを学習しながら自らスキルを作成することも可能です。たとえば、BigQuery や Knowledge Catalog と連携した運用レポートスキルを使えば、チームの誰もが平易な言葉で質問するだけで、リアルタイムのレポートを作成して保存できます。一度保存すれば、追加のトークンコストをかけることなく、必要なときにいつでもレポートを実行できます。さらに Gemini では、法務や金融サービスをはじめとする、特定の領域に特化した事前構築済みの機能も提供しています。

スタートアップにとっての意味: コワーカーエージェントによってチームの対応力を即座に引き上げることができます。また、スキルを活用することで、投資家向けレポートや運用レポートなどの定期的なプロセスを標準化し、実行のたびにトークンを消費することもなくなります。

2. オープンモデルとサードパーティモデルを自由に選択

Gemini はエージェントであり、その基盤となるモデルは自由に選択できます。スタートアップのアーキテクチャが成熟するにつれて、すべてのタスクを単一のフロンティアモデルに処理させると、粗利益が急速に圧迫されます。Gemini エージェントを使用すると、Gemini モデル、Anthropic の Claude などのサードパーティモデル、Gemma などの軽量なオープンモデルの間で、ワークロードを動的にルーティングできます。

スタートアップにとっての意味: ロックインされることなく、柔軟性を確保できます。大量の決定的ジョブにはコンパクトモデルを、複雑な推論にはフロンティアモデルを使用することで、タスクあたりのコストを最適化できます。また、プロダクトの進化に合わせて、ワークフローを再構築することなくモデルを入れ替えることができます。

3. サービスやツールに接続

エージェントの有用性は、アクセスできるシステムによって決まります。Gemini エージェントは、Google Workspace に加え、パートナーソリューションを含むエンジニアリング、データ、ビジネスの各種スタックに直接接続できます。

開発とコラボレーション: Git、Slack、Jira など。
データとローカルファイル: BigQuery、Postgres、Snowflake、Databricks などに加え、デスクトップ上のファイルにも対応。
MCP を介したカスタムツール: ネットワーク内外の Model Context Protocol（MCP）サーバー。エンジニアが社内ツールを構築して共有できます。

スタートアップにとっての意味: カスタムコネクタの保守にエンジニアのリソースを割く代わりに、エージェントを既存のコードベース、データベース、MCP ツールに直接接続して、データの所在を問わずリアルタイムに操作できるようになります。

4. 組み込みのセキュリティとガバナンス

B2B スタートアップにとって、大企業によるセキュリティ監査は、商談が失速しやすい大きな関門です。バックグラウンドでは、各エージェントに暗号化されたエージェント ID が割り当てられ、明確な監査証跡が確保されます。また、エージェントは分離されたサンドボックス内で実行され、組み込みのプロンプトインジェクション防御機能によって保護されます。外部トラフィックは Agent Gateway を経由してルーティングされるため、ガバナンスポリシーを確実に適用できます。さらに、コワーカーエージェントもそれぞれ Workspace アカウントを持つため、管理の手間はこれまでのユーザー管理とまったく変わりません。

スタートアップにとっての意味: 大企業の最高情報セキュリティ責任者から、AI ワークフローにおけるデータプライバシー、プロンプトインジェクション、アクセス制御への対策を問われても、すでにエンタープライズグレードのアーキテクチャが整っているため、調達プロセスのハードルをスムーズにクリアできます。

5. リアルタイムのコスト管理でランウェイを保護

サブエージェントを数時間から数日間にわたって実行する自律型エージェントは、ループ処理をチェックしないままでいると、すぐに請求額が膨れ上がってしまいます。こうした事態を防ぐため、Cloud Billing コンソールでリアルタイムの費用上限を直接設定できるようになりました。上限に達するとプロジェクトのエージェントが自動的に一時停止するため、バグによる予期せぬ高額請求を確実に回避できます。その基盤として、Gemini は推論に最適化された TPU 8i を含む Google による特化型 AI インフラストラクチャ上で動作し、前世代比で 80% 優れたコストパフォーマンスを実現します。

スタートアップにとっての意味: 創業者や開発者は、長時間動く並列エージェントループの試行錯誤に安心して取り組めます。標準で備わった財務セーフティネットが手元資金を守り、投資家からの信頼確保にもつながります。

すでに実践している創業者

スタートアップや AI ネイティブなイノベーターは、すでに Gemini を活用しています。没入型ストーリーテリングプラットフォームを提供する Whenere は Dreamlands を活用して、名作小説『高慢と偏見』の世界を Fortnite 上に再現しました。Dreamlands は Gemini 基盤のエージェント型 3D ワールド構築プラットフォームであり、Gemini は新しいオブジェクトごとにテクスチャを約 7 秒、10 セント未満のコストで生成しました。あるアーティストは、1 日で約 250 個のカスタムアセットを作成し、歴史的に忠実な邸宅を 1 週間足らずで完成させました。アプリケーション構築プラットフォームの Lovable をはじめ、OpenEvidence、Recursion、Replit などのスタートアップやイノベーターも、この動きに加わっています。

Google for Startups で構築

エージェント時代の到来により、社内業務を担うコワーカーエージェントのデプロイから、プロダクトへのエージェント型ワークフローの直接組み込みまで、少数精鋭のチームであっても実力以上の大きな成果を生み出せるようになります。

これらの新しい Gemini エージェント機能はまだ一般公開されていませんが、スタートアップのお客様は Google のセールスチームにお問い合わせいただくことで、詳細の確認や今後の準備についてご相談が可能です。また、Google for Startups プログラムで、クレジット、実践的な技術ガイダンス、メンターシップ、グローバルな創業者コミュニティプログラムなどもご利用いただけます。

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

Visko が Google Cloud TPU でリアルタイムの世界モデルをストリーミングする仕組み

Tue, 27 Oct 2026 01:00:00 +0000

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

編集者注: 生成 AI スタートアップは、静的なクリップ生成から、インタラクティブでリアルタイムな世界の構築へと急速に移行しています。この技術的な詳細解説では、AI スタートアップの Visko が Google Cloud TPU エンジニアと協力して、連続的にストリーミングするライブ世界モデルである Orbis を Cloud TPU にデプロイし、最初のキックオフから本番環境への引き継ぎまでをわずか 30 日で完了した方法を解説します。

ライブ動画世界モデルを本番環境で提供するのが難しいのはなぜでしょうか。ボトルネックは平均スループットではなく、リアルタイムで刻まれる厳しい時間の制約に打ち勝つことです。ユーザーがプロンプトを送信してキューで待機するオフラインの動画生成ツールとは異なり、ライブ世界モデルは連続的にストリーミングします。動画と同期された音声の新しいチャンクは、視聴者が前のチャンクを見終わる前にレンダリングを完了する必要があります。そうしないと、世界は停止してしまいます。

本日は、インタラクティブな世界モデルのパイオニアである AI スタートアップの Visko が、Google Cloud と連携してこの課題を解決した方法をご紹介します。Visko と Google Cloud のエンジニアは共同で Visko のエンドツーエンドのライブ推論パイプラインをデプロイしました。このパイプラインは、動画生成、超解像アップスケーリング、同期音声を組み合わせて、単一の Cloud TPU スライスに統合したものです。両チームが一丸となってエンドツーエンドの生成時間を短縮した結果、1.07 倍の再生速度でのレンダリングを実現しました。

本記事では、このマイルストーンをわずか 1 か月で達成したパイプラインの設計アプローチ、大きな成果をもたらしたアーキテクチャの最適化、そして Google Cloud 上で超低レイテンシの生成 AI を構築するスタートアップのための実践的なナレッジについて詳しく解説します。

ライブ世界モデルでインタラクティブメディアを再定義

ほとんどの生成動画プラットフォームが固定された事前作成済みのクリップのレンダリングに重点を置く一方で、Visko はライブモデルと呼ばれるものを構築しています。これは、連続的に生成しながら、その場で応答する動画世界モデルです。

Visko のフラッグシップモデルである Orbis は、1 つのテキストまたは画像プロンプトからライブ動画をストリーミングします。ストリームの再生中に、視聴者は新しいステアリングプロンプトをリアルタイムで入力し、配信を中断したり連続性を損なったりすることなく、シーンを動的に変化させることができます。たとえば、あるテストセッションでは、パチパチと音を立てる暖炉のそばで猫が昼寝をしているライブ配信から始まります。視聴者がシーンの指示を出して餌の入ったボウルを登場させると、ボウルがシームレスに実体化し、猫が伸びをして立ち上がり、ニャーと鳴きます。

2026 年 9 月 1 日に公開デモをリリースして以来、Orbis はインタラクティブエンターテイメント、ライブコマース、AI コンパニオン、没入型教育、ロボットシミュレーションなど、さまざまな分野で新たな可能性を切り開いてきました。これらのインタラクティブセッションを確実にスケールするため、Visko は 2026 年 8 月に Google Cloud TPU エンジニアと提携し、Orbis ライブパイプラインを Google の Tensor Processing Unit（TPU）に移植しました。30 日足らずで、完全なマルチモーダルパイプラインが TPU 上でリアルタイムに実行されるようになりました。

Visko の目標は、人々がリアルタイムで参加して形作ることができる、新世代のインタラクティブな世界の基盤となることです。厳密な時間的制約のもとで動画と音声を連続ストリーミングすることは、オフラインのクリップ生成とは根本的に異なるシステム上の課題です。Google Cloud の TPU エンジニアと協力して、Visko は Orbis パイプライン全体をわずか 30 日で TPU に移行しました。これにより、ライブモデルをクリエイターやデベロッパーに大規模に提供するために必要な低レイテンシのコンピューティングとメモリ帯域幅を確保できました。

「Visko は、リアルタイムで制御できる、新しいタイプのワークロードを Cloud TPU エコシステムにもたらしています。JAX、torchax、カスタム Pallas カーネルを活用し、単一の TPU スライス上でライブマルチモーダルパイプラインを共同開発したことで、リーンスタートアップチームが PyTorch プロトタイプから Google Cloud の AI Hypercomputer 上で 1.07 倍の再生速度でレンダリングするまでに、いかに素早く到達できるかを証明しました。」– Google Cloud、AI 担当デベロッパーアドボカシー責任者、Dave Elliott

ライブ動画は厳しい時間的制約との戦い

オフラインのクリップ生成サービスを提供する場合、レイテンシはそれほど問題になりません。バックエンドがフレームを処理する間、ユーザーは一度だけ待てばよいからです。ライブ世界モデルには待合室がありません。

セッションが実行されている限り、すべてのチャンクをリアルタイムの再生速度よりも速く、ノイズ除去、潜在空間からのデコード、1664x936（18 fps）へのアップスケール、生成された音声とのペアリングを行う必要があります。

ライブ世界モデルは、2 つの構造上の制約により、標準的なバッチ推論よりもはるかに高い要件が求められます。

バッチサイズが 1: 各ライブ配信は、個々の視聴者によるインタラクティブセッションとなります。数十の同時リクエストを巨大なバッチにまとめることでレイテンシを隠す、という手は使えません。これは、AI アクセラレータの稼働率を限界まで高めるための定石アプローチです。
厳密な順次依存関係: すべてのチャンクが、その前のチャンクに直接依存します。動画モデルは、チャンク N+1 がチャンク N のアクションをスムーズに引き継げるように、直近の動画潜在変数のローリングメモリとして保持します。そのため、チャンクを順不同で事前レンダリングしたり、将来のタイムスタンプにわたって並列化したりすることはできません。

LLM サービングの経験を持つスタートアップのインフラストラクチャエンジニアにとっては、ライブ世界モデリングを 1 秒あたりのトークン数というスループットベンチマークではなく、ステップごとの厳格なレイテンシ SLO として捉えると理解しやすくなります。

単一の TPU スライスでマルチモーダルパイプラインを構築する

Visko の規模が拡大してもインフラストラクチャを無駄なく費用対効果の高い状態に保つため、チームは、BF16 精度で実行される単一の Cloud TPU スライス上で 3 つの異なる生成モデルをチェーンするライブパイプラインを設計しました。

視聴者が最初のプロンプトを送信するか、ライブステアリングを更新すると、3 つの生成モデル（コア動画拡散モデル、超解像アップスケーラー、音声生成ツール）すべてが同じチップを共有し、チャンクごとにハードウェアを交代で使用します。

図 1: Visko のエンドツーエンドの Orbis ライブパイプラインは、動画拡散、潜在デコード、超解像アップスケーリング、純粋な JAX 音声生成を単一の Cloud TPU スライス上で順次チェーンし、各チャンクを再生速度よりも速く完了します。

スタートアップならではの迅速なイテレーションとベアメタルアクセラレータの処理速度を両立させるため、このソフトウェアスタックは 3 つのオープンソースを柱として構築されています。

JAX: アクセラレータ向けの Google の高性能 Python 配列ライブラリ。XLA コンパイラによって最適化されたマシンコードにコンパイルされます。
torchax: JAX を介して Cloud TPU 上で PyTorch モデルを直接実行する相互運用レイヤ。スタートアップチームは、既存の PyTorch コンポーネントを、ゼロから書き直すことなく移行できます。
Pallas: JAX の TPU 向けカスタムカーネルプログラミング言語。

リアルタイムのパフォーマンスの内訳: タイムリミット

エンジニアリングチームは、単一スライス上にて BF16 精度で各ステージのプロファイリングと最適化を行い、ライブストリーミング中の変動を吸収するための約 7% のヘッドルームを確保しつつ、チャンクあたりの合計レイテンシを目標以下に抑えることに成功しました。

図 2: 1 つの TPU スライスにおけるチャンクあたりのレイテンシバジェットのグラフ。

動画のノイズ除去はコンピューティング予算全体の 3 分の 2 近くを占めるため、この段階がカーネルと並列処理の最適化の主な焦点となりました。

スタックの内部: リアルタイムストリーミングを実現した 3 つの最適化

1. すべての TPU チップ間での Ulysses コンテキスト並列処理

動画チャンクは、動画トランスフォーマー内で時空間トークンの膨大なシーケンスに展開されます。バッチサイズ 1 で TPU チップ全体にワークロードを分散するために、チームは Ulysses コンテキスト並列処理を実装しました。

Ulysses は、モデルの重みを分割するのではなく、トークンシーケンスをチップ間で分割します。アテンションレイヤの直前で、高速なオールツーオール相互接続交換によりテンソルが再グループ化され、各チップが動画シーケンス全体を保持するようになります。ただし、処理するのはアテンションヘッドの 4 分の 1 のみに限定されます。各チップが割り当てられたヘッドのシーケンス全体にわたってアテンションを計算した後、2 回目のオールツーオール交換により、フィードフォワードレイヤのシーケンス分割レイアウトが復元されます。

図 3: バッチサイズ 1 での TPU チップ間の Ulysses コンテキスト並列処理。高速なオールツーオールチップ間相互接続（ICI）により、フィードフォワードレイヤのシーケンス分割レイアウトと Pallas スプラッシュアテンションのヘッド分割レイアウトの間で遷移テンソルが交換されます。

2. MaxDiffusion のカスタム Pallas スプラッシュアテンション

アテンション計算自体を高速化するために、チームは Cloud TPU 上の拡散モデル向け Google Cloud オープンソースリファレンスライブラリである MaxDiffusion から、カスタム Pallas スプラッシュアテンション カーネルを統合しました。

スプラッシュアテンションは、FlashAttention スタイルのタイリングを TPU アーキテクチャに導入します。高帯域幅メモリ（HBM）で二次関数的に膨らむアテンション行列を実体化するのではなく、超高速のオンチップ VMEM 内に収まるコンパクトなタイル単位でアテンションを計算します。スタートアップチームは、custom_splash_attention.py を介して、この移植で使用されているカーネルをそのまま独自のパイプラインに組み込むことができます。

3. torchax から純粋な JAX に移行することで、音声処理が 5.8 倍高速化

まず、3 つの Orbis モデルすべてを Cloud TPU に移行しました。その際、JAX と XLA を介して TPU 上で PyTorch コードを書き換えなしで実行できる torchax を使用しました。動画モデルとアップスケーリングモデルでは、torchax と Pallas アテンションカーネルを組み合わせることで、レイテンシの目標を直接達成できました。最終的なパイプラインでは、どちらも torchax に残っています。

書き換えが必要だったのは音声モデルだけでした。音声ステージを torchax からネイティブ JAX に移行することで、5.8 倍高速化し、パイプライン全体を再生期限内に完了できるようになりました。

AI ビルダーのためのフィールドノート: Cloud TPU のレッスン

Cloud TPU でのライブマルチモーダル推論のチューニングから得られた学び:

単一ストリーム動画の Ulysses コンテキスト並列処理: バッチサイズ 1 では、オールツーオール相互接続交換を使用してチップ間でトークンシーケンスを分割する方が、テンソル並列処理とリングアテンションの両方よりも高速でした。
連続ストリームにおけるネイティブ BF16: FP8 量子化によりメモリ帯域幅の負荷は軽減されますが、連続ストリームの複数のチャンクにわたって小さな量子化エラーが蓄積されます。ネイティブ BF16 は、レイテンシバジェット内で視覚的な品質を維持しました。
JAX への選択的な移植: torchax では、動画モデルとアップスケーリングモデルを PyTorch に残し、ネイティブ JAX で音声のボトルネックのみを書き直しました。
XLA コンパイルのキャッシュ保存: 最初の起動時に、XLA グラフのコンパイルに数分かかります。コンパイルされたアーティファクトをキャッシュに保存することで、ワーカーの再起動が 1 分未満に短縮されます。

Cloud TPU でリアルタイム生成モデルを構築している場合は、ここから始めましょう

ライブ動画、世界モデル、超低レイテンシのマルチモーダル推論の限界に挑戦しているスタートアップは、Visko の移植を支えたのと同じツールキットを使用して構築できます。

すぐに使える拡散アテンションの高速化: このコラボレーションで使用されたオープンソースのスプラッシュアテンションカーネルを MaxDiffusion から入手し、 Pallas のドキュメントを参考にしてカスタム TPU カーネルを作成できます。
PyTorch を迅速に移行し、選択的に最適化する: torchax を使用して既存の PyTorch モデルを TPU に迅速に移行し、Cloud TPU Profiler でボトルネックを特定して、レイテンシが重要なステージをネイティブの JAX に移植します。
オンデマンドで TPU をスピンアップ: TPU Flex Start VM を使用して、長期予約なしで、短期間の開発やベンチマーク実行のために TPU 容量をプロビジョニングします。
Google for Startups でビジネスを拡大: クラウドクレジット、技術メンターシップ、Google Cloud の AI Hypercomputer スタックへのアクセスを希望する初期段階の AI スタートアップは、 Google for Startups クラウドプログラムにお申し込みいただけます。

緊密な技術パートナーシップを築いてくれた Visko.ai チームと、プロジェクトを主導した Google Cloud TPU エンジニアの Yixin Shi 氏、James Huang 氏、Elisa Tsai 氏に感謝します。

- Visko、CEO、Will Yin 氏

- Google Cloud、デベロッパーリレーションズエンジニア、Ivan Nardini

サイバーエージェント: Cloud Run や Agent Development Kit を活用し、クリエイティブ生成 AI プラットフォーム「AI SCREAM」のエージェント化を推進

Fri, 23 Oct 2026 02:00:00 +0000

株式会社サイバーエージェントは、広告領域での活用を想定した社内向けクリエイティブ生成 AI プラットフォーム「AI SCREAM（アイスクリーム）」を、Google Cloud 上に構築し、約 3 年にわたって運用してきました。2025 年には Agent Development Kit（ADK）を活用したエージェント基盤を追加し、画像を作るための「道具」から、制作ワークフローを支援する「仕組み」へと進化させることに成功しています。その開発キーマンに、3 年間の総括と今後の展望を伺いました。

利用しているサービス:
Cloud Run、Pub/Sub、Veo、Imagen、Nano Banana など

利用しているソリューション:
生成 AI

独自プラットフォーム「AI SCREAM」で全社員に生成 AI を届ける

AI SCREAM は、動画生成 AI の Veo や、画像生成 AI の Imagen、Nano Banana（Gemini Flash Image / Pro Image 等）など、社内審査を経て商用利用可能な複数の生成 AI モデルを統一された UI 上で横断的に活用できる、サイバーエージェント独自のクリエイティブ生成AIプラットフォームです。広告制作などで必要となる静止画や動画、音声といった素材の作成から、それらを組み合わせた最終アウトプットまでを、誰もが手軽に行える仕組みを提供しています。

AI SCREAM 開発責任者の瓜生和也氏は、その出発点は「生成 AI を使いたくても使えない人が社内に大勢いたこと」だったと振り返ります。

「2023 年当時、画像生成 AI 活用の機運は高まり始めていましたが、導入と利用には高度な専門知識が求められており、エンジニア以外のクリエイターや営業担当者は、到底手の出せない状況でした。そうした『壁』を取り払い、全社員に生成 AI を届けることが、このプロジェクトの目的となっています。」（瓜生氏）

2023 年 10 月、VM 1 台でスモールスタートした AI SCREAM は、2024 年 1 月に全社展開を見据えたリアーキテクチャを実施します。Cloud Run で動くフロントエンド／バックエンドと、推論ワーカーの VM 群の間に Pub/Sub を挟み、非同期の境界で疎結合にする構成に作り替えることで、より多くの社員が快適に使えるようになりました。

「インフラ層においては、社員約 8,000 人のうち 3 割、約 2,400 人が日常的に使うところまでスケールさせたいという事業要求に応えることが求められていました。一方、当時の GPU モデルは容量が大きく、1 つの VM に複数モデルを載せるのは現実的ではないという物理制約もありました。そこで、この両方の要件を満たすために、モデルごとに VM を分け、Pub/Sub のメッセージ流量で水平にスケールさせる構成にしています。事業要求と物理制約を先に見込んで Pub/Sub の境界を作り込んだおかげで、その後モデルが増え続けても、基本的にこの境界は触らずに済みました。」（瓜生氏）

（2024 年 1 月全社展開に向けたリアーキテクチャ）

アプリケーション層では、異なるアプローチが採られています。2024 年 6 月には「2 週間に 1 つ、新しいモデルを提供する」という目標を設定。常に新しい生成 AI を試せること自体を価値と捉えて過度な共通化を避け、推論ワーカーのテンプレート化やコピーも意図的に許容しました。これにより、次々に登場する新たなモデルに迅速に対応することが可能になりました。瓜生氏は、わずか 3 年で 30 を超えるモデルを導入できたのも、この判断があったからだと言います。

「ただし緩めたのは実装の部分だけで、アーキテクチャ設計とデータ設計は守りました。何でも緩めたのではなく、緩める粒度を選んだというのが正確な表現だと思います。」（瓜生氏）

（2024 年 7 月〜 Stable Image Core / Ultra で初の API 連携での生成 AI モデル導入）

エージェント化によって営業メンバーもクリエイティブ制作の担い手に

次の転機となったのが AI エージェント機能の追加です。もともと社内では 2024 年 6 月頃から、クリエイティブ制作をエージェンティックにできないかという要望がありました。これを受けて 2025 年 3 月に検証が開始され、翌 4 月には、Google がリリースしたオープンソースのエージェント開発フレームワーク「Agent Development Kit（ADK）」の採用を決定。そのわずか 3 か月後の 2025 年 7 月に、エージェント基盤をリリースしています。

「ADK を選んだ理由は 3 つあります。オープンソースかつ Google の長期サポートが見込めること、Agent2Agent（A2A）プロトコルというエージェント間連携の仕組みが設計に組み込まれていること、そして Google Cloud のマネージドサービスと親和性が高いことです。」（瓜生氏）

短期間でのリリースを可能にしたのは、新規構築と既存資産の見極めでした。エージェント基盤そのものは ADK、Cloud Run、PostgreSQL で別アプリケーションとしてゼロから設計したのに対し、画像生成については既存基盤をそのまま呼び出す形にしたのです。現在稼働する主なエージェントは、プロンプトから画像を生成する「画像生成」、画像内のテキストを差し替える「ブラッシュアップ」、LP（ランディングページ）や参考画像をもとに広告バナーを作る「バナー生成」、アスペクト比に合わせてレイアウトを組み替える「リサイズ」の 4 種類。これらはすでに現場での活用が進んでいます。

「2026 年 4 月にはエージェント機能を用いて約 1 万枚の広告クリエイティブが生成され、そのうち約 20% にあたる約 2,000 枚が実用候補としてダウンロードされました。従来、生成機能のダウンロード率は 7～8% 程度だったので、予想以上の数字だったと言えるでしょう。利用の拡大は、用途が明確なリサイズ機能に牽引されている面もありますが、バナー生成単体でもダウンロード率は 10% 弱となっています。素材生成が中心だった従来の生成機能より、バナー生成やリサイズなど制作工程をより先まで進められるエージェント機能の方が、ダウンロードにつながりやすい傾向が見られます。」（瓜生氏）

エージェント機能の提供開始により、営業担当者が自らバナーを制作し、それを叩き台に広告主企業とすり合わせたりするといった事例も生まれ始めました。まだ制作・外注コストの削減効果までは確認できていないものの、生成 AI の利用者をクリエイター以外の職種にも広げられたことは、エージェント化がもたらした大きな成果と言えます。

（アーキテクチャ全体像）

より対話的な体験を追求、そして社外への展開も開始

2 度の大きなアップデートで実用性を高め、サイバーエージェント社内に根付いた AI SCREAM。2025 年 2 月から 2026 年 6 月までの間に生成された成果物は累計 160 万点を超え、制作時間は従来比で約 3 割も短縮されています。瓜生氏はその実績を踏まえたうえで、これから AI SCREAM が目指すのは、エージェントをむやみに増やすことではなく、さらに品質を高め、実際の制作業務のニーズに応えていくことだと説明します。

「たとえばクライアント様のロゴや商品画像は原則として改変してはならない要素です。守るべきところはしっかりと守った上で、それ以外の部分を生成 AI で加工し、バナーとして成立させていく取り組みを進めています。」（瓜生氏）

そしてもう 1 つ、今後の AI SCREAM の進化の軸として検討されているのが、より対話的な制作体験の実現です。現在のバナー生成は、制作に必要な情報をフォームに入力すると生成結果が返ってくる仕組みで、その後も AI と継続的に対話しながら、制作を進める仕組みにはなっていません。しかし実際の制作現場では、関係者とのやり取りのなかでバナーの方向性を固め、フィードバックを受けて修正を重ねながら仕上げていくプロセスです。瓜生氏は、AI とやり取りを重ねながら仕上げていく体験に近づけることで、AI SCREAM の「次」が見えてくるのではないかと語ります。

「エージェントのランタイムやセッションサービスなど、今後実現したい制作体験に必要となる機能は、Google Cloud にすでに揃っていると考えています。今後はこれらを上手に活用しながら、AI SCREAM をより良いものにアップデートしていきたいですね。Google Cloud には今後も、より高精度な画像生成・動画生成モデルの提供を期待しています。」（瓜生氏）

サイバーエージェントは、こうして社内で磨き上げてきた AI SCREAM の企業向け提供を、2026 年 8 月に開始しました。AI クリエイティブ BPO 事業の専門チームが、導入から運用定着、制作体制の構築まで一貫して伴走するなど、大規模な SaaS として一気に利用拡大を図るのではなく、顧客とコミュニケーションを取りながら丁寧に展開していく方針を打ち出しています。

株式会社サイバーエージェント
「21 世紀を代表する会社を創る」をビジョンに掲げ、1998 年に設立。国内最大級のインターネット広告代理事業をはじめ、メディア & IP 事業、ゲーム事業を主軸とした多岐にわたる事業を展開している。従業員数は 8,878 名（連結子会社含む。2026 年 6 月時点）。

インタビュイー
AI クリエイティブカンパニー
AI SCREAM 開発責任者
瓜生和也氏

▼ セッション動画を観る
本事例のインタビュイーによるセッション動画が公開中です。あわせてご覧ください。
【Next Tokyo 26 セッション】SDXL から AI エージェントへ: クリエイティブ AI プラットフォーム 3 年間の設計判断

▼他の導入事例記事を読む

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

アイルランドにおけるイノベーション: アイルランド企業が Gemini によって事業を拡大している方法

Tue, 20 Oct 2026 01:00:00 +0000

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

ここ数十年間で、アイルランドはグローバルテクノロジーの一大拠点へと成長を遂げました。モダナイゼーションが加速するなか、政府機関から大手企業、AI などの分野で成長を続けるスタートアップに至るまで、アイルランドのさまざまな組織が技術基盤を強化しています。現在、国内のリーダーたちは、ビジネスや業務ワークフローのあらゆるレイヤにエージェント型 AI を導入しています。

Gemini Enterprise を活用し、初期のプロトタイプからプロダクションレディなデプロイへと移行する組織が増えています。このような進展が、欧州市場におけるアイルランドの競争力を強固なものにしています。Google の現地での貢献度を試算した Implement Consulting Group の最新レポートによると、官民のリーダーたちは、世界の AI 市場における経済効果を 400 億〜450 億ユーロと推計しています。

こうした強い意欲は、政府が進めるより広範な取り組みとも合致しています。2026 年後半の EU 理事会議長国就任を見据え、アイルランドはより高次元なテクノロジーおよび政策対話を主導してきました。そして、さまざまな分野における生産性とイノベーションの向上を目指し、国家デジタルおよび AI 戦略の枠組みを策定しました。

この戦略を支援するため、Google はこれらの機能をより手軽に利用できるよう注力しています。Google の現地チームは、業界をリードする企業と連携して Gemini Enterprise の導入を進めています。Gemini Enterprise は、会話型 AI エージェントや自然言語によるデータ分析から、エージェント型エコシステムを活用した業務運用の最適化まで、多彩な機能を提供します。

経済的な波及効果は、すでに目に見える形で現れ始めています。2025 年だけでも、AI やクラウドサービスを含む Google の事業活動は、アイルランドの国内総生産に推定 100 億ユーロの付加価値をもたらしました。この勢いはアイルランド全土に広がりを見せており、さまざまな組織が Google Cloud を活用してインフラストラクチャをモダナイズし、AI の本格的な業務活用を進めています。

アイルランドのさまざまな組織が Google Cloud と Gemini Enterprise を活用してモダナイゼーションを実現している事例をご紹介します。

Ryanair: AI を活用したオペレーションで数百万人の乗客をサポート

ヨーロッパ最大の航空会社である Ryanair は、約 35,000 人の従業員に Gemini Enterprise と Google Workspace を導入することで、協調的な業務とインフラストラクチャをモダナイズしています。乗務員、運航計画担当者、本社系スタッフは、意思決定の合理化、クルーのロジスティクスの最適化、本社業務の生産性向上によるメリットを享受できます。同時に、デュアルクラウド戦略が、インフラストラクチャの復元力を強化し、2034 年までに乗客数を 3 億人に増やすという同社の目標達成を支えています。

Smyths Toys: エージェント型サポートでカスタマーエクスペリエンスを刷新

世界最大級の玩具専門小売業者である Smyths Toys は、Google Cloud と Gemini Enterprise を活用してカスタマーサポートを刷新しています。AI エージェント「Codie」を導入したことで、同社はウェブ問い合わせの 60% 以上を自己解決へと導き、ホリデーシーズンの未対応メールの滞留を削減しました。繁忙期には 1 日最大 1,000 件のメール対応に追われていたカスタマーケアチームが、より複雑な判断を要する約 50 件の問い合わせに集中できるようになりました。

アイルランド歳入庁: 公共部門のデータを進化

アイルランドでは、公共機関も進歩を遂げています。税金や関税を管理し、アイルランド経済の円滑な運用を支えるアイルランド歳入庁は、Google Cloud と連携して、従来のオンプレミスシステムから統合 AI レイクハウスアーキテクチャへの移行を進めています。このアーキテクチャは、データサイロを解消し、信頼できる唯一の情報源を確立するよう設計されています。厳格なデータ主権管理によって納税者情報を保護する一方で、Gemini Enterprise がエージェント型データ分析を推進し、歳入庁がセキュアで迅速かつ柔軟な行政サービスを提供できるよう支援しています。

Virgin Media Ireland: ワークフローを高速化

Google Cloud と Liberty Global のパートナーシップのもと、Virgin Media Ireland は AI の活用を概念検証から本番環境へと移行させています。最新のインフラストラクチャと自動化により、同チームはワークロードのデプロイ速度を 3 倍に向上させました。現在は複数の AI エージェントの展開を進めているほか、事業成長を牽引する新たなカスタマーサービスの立ち上げに取り組んでいます。

エンタープライズ向けツールで事業を拡大するアイルランドのスタートアップ

既存の大手企業がレガシーシステムのモダナイズを進める一方で、アイルランドのスタートアップは創業初日から最新のテクノロジーを基盤にビジネスを展開しています。現地の強固なテクノロジーエコシステムに支えられたこれらの機動的なチームは、グローバルな舞台で競い合えるサービスを生み出しています。

Hexis: パーソナライズされたスポーツ栄養の提供を拡大

Hexis は、アスリートがパフォーマンスの最大化とコンディションの回復を図るためのテクノロジーソリューションを開発しています。同社は、リアルタイムの生体データや行動データを Google Cloud 上で保存および処理し、Gemini Enterprise を活用して自然言語での対話機能を実現しています。これにより、ユーザーに対して 1 日を通じた最適な栄養補給の調整方法を説明しています。現在、このプラットフォームは、ツール・ド・フランスの集団に属する選手の 40% と、2026～2027 年シーズンのプレミアリーグ加盟クラブの半数をサポートしています。

Kitman Labs: パフォーマンス分析を統合

2012 年にダブリンで設立された Kitman Labs は、世界 26 か国、4,000 以上のスポーツ組織に向けて、スポーツサイエンスとパフォーマンスインテリジェンスを提供しています。同社は、自社のインテリジェンスプラットフォームに高度なアナリティクスと Gemini Enterprise を組み合わせることで、チームがデータに基づく意思決定を行えるよう支援しています。これにより、アスリートの健康維持、怪我のリスク軽減、選手のキャリア延伸に貢献しています。

Spryt: 医療連携の自動化

Spryt は、Google Cloud と Gemini Enterprise を基盤とする AI を使用し、患者体験の最適化、無断キャンセルの削減、管理業務の負担軽減を実現することで、英国と米国における医療連携の効率化を図っています。同社は NHS と連携し、米国の 70 以上のクリニックで事業を展開しています。また、Mayo Clinic との複数年にわたる共同プロジェクトの一環として、これまでに 2 億 2,400 万件もの予約実績データを分析してきました。

IMPT: カーボンオフセットを自動化

IMPT は、AI、ブロックチェーン、Google Cloud を連携させることで、検証済みのカーボンオフセットを日常的なホテル予約やオンライン購入に組み込んでいます。15 週間かけて Google Cloud に移行した同社は、195 か国で 800 万件のリスティングをサポートしています。Gemini Enterprise の導入により、同社の少数精鋭チームは 1 日あたり約 400 件の顧客チャットに対応し、応答時間の中央値 6 秒という迅速なサポートを実現しています。これにより、スタッフはシステム管理の手間から解放され、ビジネスの成長に注力できるようになりました。

アイデアを構想から本番環境へ

アイルランドが世界のテクノロジーハブとして発展を続けるなか、現地の組織は AI の持つ可能性をいかにして実質的な成果へと結びつけるか、その実践例を示しています。お客様事例をご覧いただき、他の組織が Google Cloud をどのように活用しているかをご確認ください。また、アイルランドの Google チームにお問い合わせいただき、導入への取り組みを加速させてください。

- Google Cloud 英国およびアイルランド担当マネージングディレクター、Sandeep Khanna

AI21、AI Hypercomputer の導入により AI ワークロードの起動時間を 83% 短縮

Wed, 14 Oct 2026 02:50:00 +0000

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

編集者注: AI21 Labs は、基盤モデル、特に Jamba ファミリーの構築で長年の実績を持つ世界有数の AI ラボであり、現在は特化型 LLM とエージェント最適化テクノロジーに注力しています。Google Cloud AI Hypercomputer の導入により、AI21 は優先度の高いジョブの待ち時間を 72 時間から 12 時間へと短縮し、手動によるスケジューリング介入を週 20 回からゼロへと削減しました。

AI21 は、企業が最先端の品質でエージェントを効率的に実行できるようにする基盤モデルとエージェント最適化プロダクトを構築しています。Jamba ファミリーを含む AI21 の言語モデルとエージェント最適化プロダクトスイートは、AI21 独自のワークロードをはじめとする、要求の厳しい本番環境ワークロードを稼働させています。そこで、これらを大規模なスケールで稼働させるために Google Cloud AI Hypercomputer を選択しました。

モデルトレーニングの稼働率を高く維持するには、インフラストラクチャ、オーケストレーション、使用量モデル全体で共同設計された、パフォーマンスとスケーラビリティに優れた環境が必要でした。モデルのトレーニングは、共有の Google Kubernetes Engine（GKE）クラスタの 1 つで実行され、数千の Google Cloud A3（NVIDIA H100 Tensor Core GPU 搭載）インスタンスと A3 Ultra（NVIDIA H200 Tensor Core GPU 搭載）インスタンスをプールしています。これにより、どのチームも、割り当てられた一部のキャパシティに制限されることなく、フリートの全キャパシティを活用できます。このクラスタは、Jamba ファミリー以外のモデルやエージェント最適化ワークロードのトレーニングにも使用されています。このアプローチによって使用率は高く維持されますが、その反面、スケジューリングは困難になります。

高使用率クラスタの行き詰まり

オーケストレーションに GKE を活用する前は、Slack で手動でキャパシティを調整していました。トレーニング実行のためのキャパシティが必要な場合は、#gpu-resources に投稿して、うまくいくことを祈るしかありませんでした。

クラスタに余裕があるときは、これで問題ありませんでした。使用率が 100% 近くに張り付くと、機能しなくなりました。これこそが、予約済みのコンピューティングフリートに求められる稼働状態であるにもかかわらず、です。

やがて、すべてのリクエストが交渉の対象となりました。チームリーダーは、コンピューティングリソースの割り当てを巡る争いの仲裁に時間を費やしていました。優先度の高いジョブ、つまりクラスタの半分以上を一度に必要とし、モデルプロジェクトのクリティカルパスとして機能する大規模なマルチノードトレーニング実行は、十分な連続した空きキャパシティが確保できるまで最大 72 時間ブロックされる可能性がありました。

図 1: #gpu-resources での典型的な 1 日。手動リクエスト、アドホックな調整、返信を待つ研究者。

リソースの不足は 2 つの異なる問題を生み出しましたが、それらを別々の問題として認識するまでには時間がかかりました。1 つ目は競合です。次にコンピューティングリソースにアクセスできるユーザーを決定する必要があり、これは交渉によって解決しました。2 つ目は断片化です。技術的には空きキャパシティがあるものの、大きなジョブで使用するには小さすぎる断片に分散している状態であり、これはいくら交渉しても解決できないビンパッキング問題でした。

図 2: GPU の断片化。4 つのノードに 1+1+4+2 として分散された 8 つの空き GPU では、8 GPU のワークロードを収めることができません。

理論上は十分な空きキャパシティがある場合でも、それが複数のマシンに分散していて、大きなジョブを実際に実行するにはチャンクが小さすぎることもありました。オールオアナッシングアドミッションがなければ、クラスタはデッドロックに陥り、誰かが手動で介入するまで、マシンは有用な作業を行わずにリソースを保持することになります。

現状がうまくいっていないことは明らかで、もっと良いものが必要でした。

適切なスケジューラの選択

当社では、Apache YuniKorn、Volcano、Kueue など、いくつかのオープンソースバッチスケジューラを検討しました。YuniKorn は、当社のすべてのユースケースをカバーしていませんでした。Volcano は機能が豊富でしたが、当社の環境に統合するには、Kubernetes スケジューラのコアコンポーネントを置き換える必要がありました。

シンプルさと統合のしやすさが、Kueue を採用する決め手となりました。標準の Kubernetes で動作し、コアコンポーネントを置き換える必要がなく、ジョブ仕様を書き直す必要もありませんでした。

Kueue と、GKE を通じた AI Hypercomputer の柔軟でオープンな運用を組み合わせたことも、成功に貢献しました。GKE を利用しているのは、コンピューティング負荷の高い AI ワークロードを適切に制御できるからです。GPU ハードウェアとドライバに直接アクセスできる一方で、生のインスタンスを自社で管理するオーバーヘッドは発生しません。Kueue は、Spot VM や Dynamic Workload Scheduler などの Google Cloud のキャパシティタイプを含め、GKE とネイティブに統合されているため、予約されたキャパシティが満杯になると、ジョブが滞ることなく、同じスケジューリングロジックが自動的に拡張可能なキャパシティにアクセスできます。

オープンソースとのフィードバックループの確立

Kueue の導入は、単なるプロセスの変更以上のものとなりました。Google Cloud と提携しているため、当社には専任のテクニカルアカウントマネージャーがついています。その担当者が、AI21 を Kueue チームのデザインパートナーに推薦する好機だと考えてくれました。そうすれば、単なるユーザーにとどまらず、本番環境における実際の要件を提供する存在として、ツールの今後の方向性を形作るのに貢献できます。

このパートナーシップから最初に生まれたものの一つが、Kueue チームと共有した要件ドキュメントです。このドキュメントには、まだ存在していなかった、必要とする動作が記載されていました。それは、通常は公平なスケジューリングに付随するプリエンプションを行うことなく、マルチノードジョブに対してチーム間で公平なアドミッション順序を実現することです。Kueue チームは、この機能を実際に開発してくれました。Admission Fair Sharing（AFS）は、すでに実行されているジョブを中断することなく、これまで使用したキャパシティが少ないチームを優先するようにアドミッションキューを並べ替えます。同じ頃、トポロジを考慮したスケジューリングも有効にしました。この既存の機能により、Kueue は物理クラスタのレイアウトを認識できるため、単一ノードに収まらないジョブを、実行する場所がないまま配置するのではなく、受け入れを拒否できます。

当社にとって、これはオープンソースのフィードバックループの最良の形です。本番環境での使用を通じて実際の要件が明らかになり、それが Kueue に直接フィードバックされます。

同じフリートで、よりスムーズに

Slack の #gpu-resources チャンネルはアーカイブされました。デバッグ pod、マルチノードトレーニング実行、推論デプロイなど、あらゆるワークロードがキューに登録され、優先順位が付けられ、自動的にスケジュールされます。効果はすぐに表れました。手動による介入は、週に約 20 回からゼロに減少しました。以前は最大 72 時間待機していた優先度の高いジョブの待ち時間が、今では 12 時間に短縮されました。クラスタ全体の断片化は 15% から 8% に減少し、「ゾンビジョブ」の問題（ワークロードが部分的に受け入れられ、実行する場所がない）は解消されました。

これによって総費用が変わることはありませんでした。当社では、予約済みフリートを意図的に 100% に近い稼働率で運用しているため、純粋な支出額そのものは、もともと最適化の対象ではありませんでした。変わったのは、従業員が何に時間を費やすかです。チームリーダーはコンピューティングに関する争いを仲裁する必要がなくなり、研究者は Slack での返信を待つ必要がなくなりました。これにより、誰もがより多くのテストを実施し、より迅速に反復処理を行えるようになります。

- AI21、テクノロジーおよびアーキテクチャ担当バイスプレジデント、Barak Peleg 氏

- AI21、DevOps エンジニア、Asaf Ben-Tovim 氏

オーケー: AlloyDB と Database Migration Service で「止められない基幹システム」を移行し、データドリブンな価値創出を加速

Mon, 05 Oct 2026 02:00:00 +0000

小売業界で急速な事業拡大を続けるオーケー株式会社（以下、オーケー）は、ネットスーパーの成長を支えるデータベースの基盤強化と、店舗の「止められない」業務を担うデータベースの刷新という 2 つの課題に挑戦。AlloyDB を軸とする Google Cloud のソリューションを採用し、現場への影響を極小化しながら、新たな基盤の構築に成功しています。このプロジェクトを推進してきたオーケーと KDDIアイレット株式会社（以下、KDDIアイレット）の担当者に、話を伺いました。

利用しているサービス:
AlloyDB, Database Migration Service（DMS）, BigQuery, Firebase, Partner Interconnect, Datastream, Google Workspace, Gemini など

利用しているソリューション:
データベースのモダナイゼーション

ビジネスの急成長を受けて高まった、2 つの基幹データベース刷新の必要性

オーケーは「高品質・Everyday Low Price」を経営方針に掲げ、関東・関西に 180 店舗以上を展開するディスカウントスーパーマーケットです。同社は高品質な商品でありながら、特売日を設けず毎日が低価格の「Everyday Low Price（EDLP）」方針を徹底し、「小売 × IT」の最先端の仕組みづくりに挑戦してきました。2020 年に Google Cloud を導入し、オンプレミスのデータウェアハウスを BigQuery へと刷新したのを皮切りに、2021 年には「オーケーネットスーパー」を開始。会員向けスマートフォンアプリも、Firebase を活用して短期間で構築するなど、デジタル領域での顧客体験向上に注力しています。

しかし、オーケー IT本部副本部長の荒川健児氏は、こうした取り組みの裏側で、システムの心臓部を担う 2 つのコアデータベースの刷新が求められていたと振り返ります。1 つ目は、ネットスーパーの顧客体験向上を担う「ネットスーパー DB」です。

「この領域は将来的には法人利用も視野に入れており、増大するトランザクションに柔軟に対応できるスケーラビリティと、インフラ運用コストの最適化が強く求められていました。従来は他社のクラウド上で稼働しており、データが各システムにサイロ化していたのが実情です。このため高度な分析基盤や AI と連携しながら、お客様に対してパーソナライズされた提案をリアルタイムに行えるようにすることが目標となっていました。」

2 つ目のデータベースは、日々の店舗業務を支える「生鮮 DB」です。これは各店舗のマスター情報や仕入れ、棚卸し、販売実績といったデータを蓄積し、全店舗からのデータ参照や現場の帳票出力などに対応しており、絶対に止めることができないシステムです。

「『生鮮 DB』については長年稼働してきたオンプレミス環境からの脱却を目標にしていましたが、新しいクラウド環境とオンプレミス環境が並存する過渡期に、データ連携と一貫性をいかに維持するかという課題がありました。また『生鮮 DB』は、現場に定着している業務プロセスと密接に結びついているため、一斉停止を伴う全面移行をいかに避けるかも問われていました。」（荒川氏）

AlloyDB の採用により、業務の根幹を支えるデータベースの移行と基盤統一を実現

現行業務への影響を最小限に抑えながら、既存のデータベースからコアデータを安全に切り離し、新たなクラウドに段階的に移行する。この難易度の高いミッションをクリアすべく、オーケーは基本方針の決定からネットワーク構築、PoC（概念実証）、データ移行、本番切り替えまでのサポートを KDDIアイレットに依頼します。評価されたのは、Google Cloud 導入支援と運用最適化を多数手がけてきた実績でした。

これ以降、両社は共に検討を重ね「ネットスーパー DB」と「生鮮 DB」の移行先を統一し、その共通基盤として AlloyDB の採用を決定しました。KDDIアイレットで開発を率いた齋藤寛隆氏は、その選定理由として 5 つのポイントを挙げています。

「まず大前提となったのは高可用性です。AlloyDB は、止められない生鮮業務を支えられる『99.99% のサービスレベル契約（SLA）と約 15 秒のフェイルオーバー』という性能を持っていました。2 つ目は、標準的な PostgreSQL 比で 4 倍以上のトランザクション処理性能、3 つ目は、オートバキュームなどの自動化による運用負荷の削減です。4 つ目はすでに活用されている BigQuery との親和性で、最後は移行支援ツールの充実も決め手になりました。」

AlloyDB への統合にあたっては、「セキュアなプライベート通信の確立」と「種類の異なるデータベース間での無停止移行」という要件がありました。まず通信に関しては、オンプレミスのデータセンターや他社クラウドから Google Cloud へ Partner Interconnect の専用線で接続。インターネットを経由せずに AlloyDB と通信できる閉域網環境が構築されています。

データ移行では、DB ごとに方法が使い分けられました。「ネットスーパー DB」は一部データの移行となり、システムを停止させることが可能だったため、対象データを既存の PostgreSQL からエクスポートし、AlloyDB へインポートする方法が採用されています。これに対して「生鮮 DB」は、システムを止めることができないため、データ移行をアシストする Database Migration Service（DMS）が活用されました。

「『生鮮 DB』の移行では、DMS を用いて従来のデータベースのトランザクションログから差分データを解釈し、新しいデータベースへ継続的にデータ書き込みを行う方式を採用しました。これはクエリを発行しないため、稼働中のデータベースへの負荷を最小限に抑えることができます。また、差分のみの転送で遅延を最小限に抑えつつ、切り替え時のダウンタイムの極小化が実現できると判断し、DMS の採用を決めました。」（齋藤氏）

この移行プロセスでは、KDDIアイレットの知見も活かされています。スキーマ変換では、DMS のコンバージョンワークスペースと Gemini の変換提案を活用して作業の効率化を実現。DMS が対応していない日本語のカラム名では、英数字の仮テーブルを経由して、移行後に再設定する方法が採られています。移行後のデータ検証には、Google Cloud のデータ検証ツールが使用されました。

Gemini や AlloyDB AI も活用しながら、DX と新たな価値創出を追求

今回の移行プロジェクトで得られた技術的な成果を、齋藤氏は次のように総括します。

「『生鮮 DB』は日々の業務を担う『止められないシステム』です。本プロジェクトでは、止められないから移行を諦めるのではなく、ダウンタイムを極小化しながら AlloyDB に移行することで要件をクリアしただけでなく、将来的なデータ活用まで視野に入れることができました。BigQuery との連携では、Datastream を活用することにより、セキュアな通信を維持したまま、AlloyDB から BigQuery へニアリアルタイムにデータを連携できるようにもなりました。」

一方、荒川氏は AlloyDB を軸とした新たなデータベース基盤が、現場における業務を大きく変えつつあると説明します。

「従来、生鮮の現場では、担当者が独自のツールを使って DB からデータを抽出し、手作業で表計算ソフトの集計や状況確認を行っていました。しかし新たなシステムでは、BigQuery 上に生鮮のニアリアルタイムなデータを集約し、さらに天気情報や人流データ、客数予測といった外部データを掛け合わせることが可能になります。店舗での売り上げ情報を即座に反映して『製造の推奨数』を算出することにより、生鮮領域のロスを削減しながら、売り上げを増やすための合理化も図られるようになりました。」

オーケーではデータドリブンな業務改革を定着させるため、環境づくりも進められています。実際に必要とされるデータやシステム運用のリテラシーは職種や部門によって異なるため、AI をエージェント化し、自然言語でデータを活用できるようにする取り組みが始まっています。「自動化できるところは AI で積極的に自動化し、人間は本当に考えるべき業務だけを担う」という発想には、少子高齢化による人手不足に対応する狙いも込められています。

「小売 × IT」で新たなニーズに対応し、事業成長を牽引していく。このアプローチを推進し続けるべく、荒川氏は Google Cloud のエコシステムを活用しながら、DX の推進と顧客体験の向上を図りたいと改めて強調しました。

「デジタル上で店舗の商品を見つけやすくすることは、顧客体験を向上させ、売り上げを伸ばす意味でも重要です。例えば従来のキーワード検索では、『コレステロールが気になる人向けの油は？』といった問いかけに対し、商品を見つけられないことがありました。しかし AlloyDB AI を活用すれば、意味や文脈を汲み取った検索や、類似商品の提案も可能になっていきます。AlloyDB や BigQuery はもとより、Google Workspace や NotebookLM、Gemini をはじめとするツールには、データ連携や集約がシームレスに行えるという大きな魅力があります。今後も KDDIアイレットや Google Cloud のサポートを受けながら先進的な IT を活用し、お客様に提供する価値を高め続けていきたいと考えています。」

オーケー株式会社
1958 年創業。「高品質・Everyday Low Price」を経営方針に掲げ、関東（1 都 3 県）、関西（大阪府・兵庫県）に 180 店舗以上のディスカウントスーパーマーケットを展開。高品質な商品でありながら、特売日を設けず毎日が低価格の「Everyday Low Price（EDLP）」方針を徹底し、ナショナルブランド商品については地域一番の最安値を目指す。2024 年には関西エリアにも進出し、年商 7,500 億円を超える規模へと成長している。

KDDIアイレット株式会社
2003 年 8 月にアイレット株式会社として創業し、2017 年 2 月に KDDI株式会社の傘下に。2026 年 4 月に KDDI Digital Divergence Holdings株式会社との合併により、社名を KDDIアイレット株式会社に変更。クラウドインテグレーション事業、開発事業、デザイン事業、提携事業を展開し、Google Cloud パートナーとして、インフラの移行や新規構築、アプリケーション開発、AI エージェント開発まで数多くの実績を持つ。

インタビュイー（写真左から）

・オーケー株式会社
　IT本部副本部長　荒川健児氏

・KDDIアイレット株式会社
　クラウド・イノベーション本部クラウドインテグレーション事業部グループリーダー
　齋藤寛隆氏

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

Orange はどのように FinOps のアカウンタビリティを確立し、なぜ次にエージェントなのか

Thu, 01 Oct 2026 02:30:00 +0000

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

フランスを拠点とする大手多国籍通信プロバイダの Orange では、エンジニアリングチームがデリバリーバックログを一時中断して、全員でクラウド費用のクリーンアップに 1 日を費やす日があります。ランキングが表示され、素敵な特典が用意されています。経験豊富な実務担当者が初心者を指導するため、初心者は実際に作業しながら仕事を覚えます。一日の終わりには、プロジェクトの支援者（スポンサー）も結果を確認できます。

Orange はこれを FinOps Clean Days と呼んでいます。ゲーム要素を取り入れたハッカソンと組み合わせることで、100 人以上の社員が参加する FinOps コミュニティは、社内におけるネットプロモータースコアで 70 を超える評価を獲得しました。

これらの数字は、業界全体が苦戦しているある課題を示唆しています。最近の State of FinOps レポートでは、エンジニアに行動を起こさせることが、組織が直面する最大の課題の一つとして挙げられています。単なる認識から実際の行動へと移すには、FinOps のアカウンタビリティを醸成し、チームに真剣に取り組んでもらう方法を見つけなければなりません。

つまり、FinOps はビジネスにおける「変革」の課題と言えます。そして、ビジネスの変革に関する課題には、既知の解決策があります。Orange の FinOps リードである Camille Marini 氏に、同社がどのようにしてこれらの課題を克服し、AI の導入と ROI を加速させたのか、また、他の組織がどのようにして同じ道をたどることができるのかについて詳しくお話を伺いました。

Clean Days が効果的な理由

Orange は、FinOps チームの立ち上げ当初から、2 つの原則を掲げています。1 つ目は、Cloud FinOps は責任の共有であり、プロジェクトのすべての関係者がそれぞれの方法で関与する、という点です。そして 2 つ目は、その責任の共有を実現する唯一の道はコミュニケーションと、意図的な変革の取り組みである、という点です。

「FinOps の実践において、組織全体で責任の共有というコンセプトを重視しました」と Marini 氏は語ります。「これは、クラウドセキュリティに対する当社のアプローチと非常によく似ています。責任ある効果的な AI への支出と使用を実現するには、プロジェクトのすべての関係者が、それぞれの方法で FinOps に関与していることをチームに理解してもらう必要がありました。」

これらの原則に基づき、Orange は Google Cloud コンサルティングのサポートを受けて FinOps 実践コミュニティを立ち上げました。このコミュニティは、標準化されたコミュニケーションチャネルで運営されたため、その手法は中心メンバーの枠を超えて広く浸透しました。また、会議では具体的な最適化案や請求の更新情報を共有し、常に「すぐに行動に移せる内容」に徹したことで、すべてのセッションが参加者にとって価値あるものとなりました。

Clean Days は、アジャイルなチームが実際にどのように機能しているかを見極めたうえで考案されました。デプロイが絶え間なく行われるアジャイル環境では、最適化作業がスプリントより優先されることはほとんどありません。デリバリーの優先事項、バックログ、日常業務で、利用できる時間は真っ先に埋まってしまいます。そこで Orange は、専用の時間を確保し、それを共同作業にして、楽しいイベントに仕立て上げました。

このアプローチがなぜ効果的なのかは、McKinsey の「変革の 4 つの構成要素」によって説明がつきます。このフレームワークでは、大規模な組織変更には、次の 4 つの領域にわたるアクションが必要であるとしています。

納得と理解:「自分に何が期待されているかを理解し、それに同意している。」
公式なメカニズム:「構造、プロセス、システムによって変化が促されている。」
ロールモデリング:「リーダーや同僚の行動が変化している。」
人材とスキル:「新しい方法で行動するためのスキルと機会が与えられている。」

Orange の手法をこれらのブロックにマッピングすると、パターンが見えてきます。ゲーム要素と報酬により、エンジニアたちにお手本となる同僚が生まれます。ランキングによってさまざまな行動が可視化され、スポンサーはすぐに成果を確認できます。経験豊富な実務者が初心者を指導することで、コミュニティ自体を通じて人材とスキルが育成されます。定期的なセッションで最適化と請求に関する最新情報を共有することで、資金の使途を把握しているという確信が生まれます。

変化の 4 つの構成要素にマッピングされた FinOps アクティビティと、AI エージェントがそれらを強化できるポイント。

100 人を超える場合

100 人の熱心なコミュニティを築くことは、それだけでも十分に大きな成果です。しかし、数千人のエンジニアを抱える組織では、中央の FinOps チームが全員に直接連絡することはできません。リーダーにとっての課題は、Orange のようなコミュニティがもたらすもの、つまり意識改革、当事者意識の共有、行動の習慣化を、FinOps チームが直接アプローチできない人々に、どのように浸透させていくかです。

ここで、AI エージェントの出番です。AI エージェントは 2 つの主なメリットをもたらし、FinOps チームの能力を高めます。これまで人間が対応せざるを得なかった、複雑で時間のかかる作業をエージェントが引き受け、社内の誰もが摩擦なしに FinOps に取り組めるようになります。

エージェントをチームに定着させるには、自社が抱える具体的な課題に焦点を当てた戦略が必要です。こうした課題は多くの場合、認知負荷の高さ、責任の所在のあいまいさ、あるいは優先事項の競合などから生じています。まずは、FinOps ライフサイクルにおいてエンゲージメントが低下するポイントを特定します。

認識のギャップ: チームが支出の影響を把握していない場合、分析情報エージェントが、日常的に使用するツールにリアルタイムの費用データを push できます。
リソースのギャップ: エンジニアがバックログの消化に追われているなら、修復エージェントがすぐに効果の出る対策を特定し、そのままマージできる状態のコード変更として提示してくれます。
複雑さのギャップ: レポート作成が面倒なルーティン作業のように感じられる場合、オーケストレーションエージェントがデータを収集してプロセスを簡素化できます。

信頼から始め、自律性を追加する

賢明な進め方は、段階を踏んで進めることです。Orange のように、コミュニティプラクティスを確立します。次に、情報提供と提案を行う読み取り専用エージェントを導入します。コミュニティ全体でこれらが定着して初めて、システムに直接変更を加えるエージェントの構築へと進むべきです。直接的なアクションには運用上のリスクが伴うため、慎重に管理してください。しかし同時に、そこにこそ、最も大きな成果が眠っているのも事実です。

どのように構築するかは、誰が構築を担うかによって異なります。最小限のコードで迅速にデプロイしたいチームの場合は、Gemini Enterprise app がエージェントを作成するためのノーコード環境を提供します。きめ細かい制御を必要とするデベロッパー向の場合は、Gemini Enterprise Agent Platform（旧称 Vertex AI）が、Agent Development Kit（ADK）などのフレームワークで構築されたエージェントをリリースして管理するための高度なツールを提供します。

Cloud FinOps は、一元化されたレポートから、実際の開発現場で即座にアクションを起こすフェーズへと移行しつつあります。この変革に成功している組織は、まず「文化の醸成」から始め、次に AI エージェントを活用することで、一つのチームの限界を超えた組織全体への拡大を実現しています。

Orange の数値はコミュニティの取り組みから得られたものです。その基盤を構築することが、最初に真似るべき部分です。この取り組みをさらに拡大する準備ができたら、Google Cloud コンサルティングがコミュニティプラクティスの形成を支援します。また、Gemini Enterprise アプリを活用すれば、最初の読み取り専用エージェントを手軽にチームへ導入することができます。

- Google、AI Transformation および FinOps コンサルタント、Samuel Moss

- Google、AI Transformation コンサルタント、Celine Devie

住友重機械工業: Google Cloud で SDV 開発基盤を構築し、大型機械用ソフトウェア開発の高速化と人材育成を両立

Tue, 29 Sep 2026 02:00:00 +0000

「デジタルの力で、世界中の現場を快適に、携わる人々を幸せに」というビジョンに基づき DX を推進している住友重機械工業株式会社（以下、住友重機械工業）では、製造業 DX と SDV（Software Defined Vehicle）用のロボット開発基盤を Google Cloud で構築。製造業で深刻化している労働力不足の解消にも取り組んでいます。なぜ SDV のために Google Cloud を採用し、いかに人材育成も充実させたのか。AIロボティクスセンターの開発者と責任者に話を伺いました。

利用しているサービス:
Gemini Enterprise, Gemini CLI, Cloud Workstations, BigQuery, Cloud Build, Cloud Run, Identity-Aware Proxy など

利用しているソリューション:
生成 AI

加速する SDV の流れに対応するために、Google Cloud でプラットフォームを構築

重機械メーカーである住友重機械工業は、減速機や放射線治療装置など、多岐にわたる製品を研究開発しています。その中で、物流・建設機械を扱うロジスティックス＆コンストラクションセグメントを担当しているのが、AIロボティクスセンターです。現在、同センターでは、自動フォークリフト（AGF：Automated Guided Forklift）の開発を推進。技術本部技術研究所 AIロボティクスセンターロボティクスプラットフォームグループの中尾拓真氏は、その背景を次のように説明します。

「製造業は、ハードウェアの性能で製品価値が決まる時代から、ソフトウェアのアップデートで機能が追加され、より便利になる SDV の時代への変革期にあります。自動車ではすでに、OTA と呼ばれるインターネット経由のアップデートで自動運転の性能や燃費が購入後にも向上するようになりました。この流れは物流・建設機械にも広がってきていますので、大型機械の中で動くソフトウェアの開発を、より高速化することが求められています。」

同センターでは、AGF の開発を通じて、SDV に対応したクラウドの開発環境を検証。得られた成果や知見をもとに、ソフトウェア開発を効率化し、油圧ショベルやクレーンなどの他の機種にも展開していく予定です。

「コーディングでは生成 AI を利用して、AGF の動作やアルゴリズムを短時間で実装します。こうして実装した機能は、まずシミュレーターで動作を確認してから実機実験に進みますが、実機実験は時間や場所、安全性の制約が大きいので、可能な限りシミュレーターで不具合を解決しておくことが大切になります。また、そこで得られたデータはクラウド上で分析され、不具合の原因特定や次の改善に活かされます。」（中尾氏）

デジタルツインを活用した事前検証を行い、実機実験を 1 回でクリア

住友重機械工業では基盤となるプラットフォームとして、Google Cloud を採用。決め手となったのは、開発に必要な機能はもちろん、内製化に向けた支援プログラムなどが包括的に提供されることでした。

Google Cloud 上の開発プラットフォームは、生成 AI 開発環境、CI/CD、デジタルツイン、データ分析の 4 つの役割を担っており、検証を終えた機能は Docker イメージで実機にデプロイされます。例えば AGF がパレットを検出してピックアップする自動化機能の開発では、Cloud Workstations 上のデジタルツインでシミュレーションを行った結果、1 回目の実機実験で動作テストを問題なくクリアできました。

「シミュレーターは実機とまったく同じプロトコルで通信できるので、ロボットのプログラムから見ると、接続している相手が実機なのか、シミュレーターなのかを意識する必要がなくなります。だからこそ、動作確認したプログラムが実機でもそのまま動くのです。」（中尾氏）

中尾氏によれば、Google Cloud の導入は個別の開発だけでなく、チーム全体の作業プロセスにも大きな変化をもたらしました。

「クラウドを導入する前は、開発環境や使用ツールが各自バラバラで、ソースコード管理も個々が行っていました。しかし Cloud Workstations で環境を標準化し、ソースコード管理や CI/CD も実現したことにより、シナジーを生むチーム開発へ移行できました。特に Cloud Workstations は、メンバー全員が同一環境で開発できるため、新規メンバーのオンボーディング短縮にもつながっています。新入社員として配属されたメンバーが、配属初日から作業に着手できた例もありました。」（中尾氏）

開発プラットフォームでは、コーディングやデバッグ、ドキュメント作成などの幅広い工程で、Gemini CLI や Gemini Enterprise などの生成 AI が活用されています。中尾氏は、その効果を高めるために独自の仕組みも構築してきました。

「生成 AI でエンジニアの発想をすぐにコード化し、CI/CD と組み合わせて定型作業も自動化したことで、エンジニアが創造的な作業に専念できるようになりました。ただし、AI コーディングエージェントは、同じエラーの解決方法を毎回 1 から探してしまいます。そこで、エラーログをキーにして AI が解決策を自動蓄積・検索する『KAI（Knowledge & AI）』を構築し、チーム全体へナレッジを展開できるようにしました。さらに、AI の学習データに含まれない社内の内製ライブラリの仕様を正しく理解させるため、ソースコードとドキュメントを関連付けて検索できる『GraphRAG』も実装しています。」（中尾氏）

Cloud Workstations と TAP で最適なクラウド人材の育成環境を整備

住友重機械工業は、Google Cloud 上のプラットフォームによって AGF の新機能実装を大幅に効率化しました。しかし意欲的な開発を継続していくには、クラウドに習熟した人材の確保が急務となります。ロボティクスプラットフォームグループでグループリーダを務める藤井北斗氏は、2025 年に入社した中尾氏を例に挙げながら、短期間で優れた人材を育成するうえでも Google Cloud の導入が有用だと語りました。

「SDV をけん引する人材育成には、早い段階で数多くの失敗と成功を体験させることが重要です。しかし弊社のように歴史が古く、規模の大きな組織では、自由にロボット開発を試せるクラウド環境を提供するのは、ガバナンスやセキュリティの観点から難しいのも事実です。この課題を Google Cloud で解決しようと考えました。」

まずガバナンス・セキュリティ面では、Google Workspace の Enterprise エディションを採用し、組織管理アカウントと IAM（権限管理）を連携させることで、少人数でも安全かつ適切なアカウント管理を実現。Security Command Center（SCC）も導入し、脅威の検知から修復までをカバーするセキュアで効率的な運用環境を確保しています。

「開発の経験を積むにはセキュリティガードレール、自由なプレイグラウンド（実験環境）と AI サポート、失敗しても元に戻せるサンドボックスの 3 要素が必要です。Cloud Workstations はコンテナなので壊れても元に戻せますし、IAP（Identity-Aware Proxy）で防護されているので安全も確保できます。生成 AI は Gemini Enterprise で誰が何に使っているかを把握できるようにし、ネットワークやセキュリティは Google Cloud Skills Boost で基礎的なことを学んでから、実装に取り組む体制にしています。中尾も、ガードレールの中で安全に失敗を繰り返すことで、バランスが取れた実装ができるようになりました。」（藤井氏）

一方、組織開発では、外部の知見を入れながら継続的に組織をスケールさせるための取り組みがなされています。そこで利用されたのが、Google Cloud が提供するアジャイル型内製化支援ワークショップ、TAP（Tech Acceleration Program）です。

「ロボット開発基盤のプロトタイピングでは、Google Cloud のエンジニアと 3 日間の合宿を実施していただきました。TAP では、プラットフォームエンジニアリング

やサイト信頼性エンジニアリング（SRE）だけでなく、Google のカルチャーや組織開発についても学ぶことができました。さらには生成 AI を使ったバイブコーディング研修を実施いただき、それを軸に社内教育も実施しています。」（藤井氏）

住友重機械工業は今後、SDV のサービス化に向けた企画やビジネスモデル構築、マイクロサービス開発、デジタルツイン環境の拡張へと取り組みを広げていく計画です。藤井氏は次の目標をすでに見据えていました。

「例えばデジタルツインは、開発やデバッグだけでなく、お客さまに新しいサービスを早く検証していただくための環境も提供します。この技術を基に、すべての住友製品とクラウドでつくったサービスが、仮想空間でつながる世界を実現したいと考えています。また、Gemini Robotics-ER 1.6 が公開されたので、フィジカル AI との統合も検討しています。OTA の仕組みを欧州の規制に適合させる、あるいは Firebase で顧客の操作状況を把握して UX を向上させるなど、弊社には他にも多くの目標があります。これらの実現に向け、今後も Google Cloud を活用した開発の効率化や、労働力不足などの課題を解決できる仕組みづくりに挑戦し続けていきます。」（藤井氏）

住友重機械工業株式会社
1888 年の創業から 130 年以上の歴史がある総合機械メーカー。「住友の事業は住友自身を利するとともに、国家を利し、社会を利する事業でなければならぬ」という住友グループの経営理念に基づき、メカトロニクス、インダストリアルマシナリー、ロジスティックス＆コンストラクション、エネルギー＆ライフラインの 4 つのセグメントを事業領域としてカバーする。連結従業員数は 2 万 5,123 名（2025 年 12 月 31 日現在）で売上高は 1 兆 669 億円（2025 年度）。

インタビュイー（写真左から）
技術本部技術研究所 AIロボティクスセンター
・ロボティクスプラットフォームグループグループリーダ・主任研究員　藤井北斗氏
・ロボティクスプラットフォームグループ　中尾拓真氏

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

JR東日本: Spanner と Cloud Run で「タッチトリガー」を実現し、改札データを起点に新たなコミュニケーションと価値を創出

Mon, 28 Sep 2026 02:00:00 +0000

利用しているサービス:
Spanner, Cloud Run, Cloud Logging, Cloud Tasks, Cloud Scheduler, BigQuery

東日本旅客鉄道株式会社（以下、JR東日本）が開発した「タッチトリガー」は、Suica の改札タッチをトリガー（起点）として、乗客のスマートフォンへタイムリーに情報を届ける新世代のコミュニケーションサービスです。この実現に向け、膨大なデータトラフィックを支えるインフラとして選ばれたのが、Google Cloud の Spanner と Cloud Run でした。開発の背景から、Google Cloud の製品が選ばれた理由、そして活用事例まで、マーケティング本部でプロジェクトを推進する 4 名に話を伺いました。

改札というリアルな接点から生まれる、生活に密着したデータ

日本最大の鉄道事業者として、乗客の移動を支える JR東日本。同社が発行する交通系 IC カード Suica は、2001 年のサービス開始以来、累計発行枚数が 1 億 2,000 万枚を超え、移動・決済のインフラとして、私たちの生活に欠かせないものとなっています。今、同社は Suica の利便性をより高め、活用範囲を広げる「Suica Renaissance」構想を進めています。その核となる技術のひとつが、乗客の改札通過データをもとに、さまざまな情報を提供する「タッチトリガー」です。マーケティング本部の戦略・プラットフォーム部門で副部門長を務める廣瀬道輝氏は、開発の背景にはコロナ禍があったと振り返ります。

「コロナ禍の最中、人々が通勤・通学や外出を控えざるをえなくなり、鉄道の利用者が大きく減るという事態に直面しました。『人の移動』という弊社事業の前提が揺らいだのです。その危機感のなかで、単に移動のインフラを提供するだけでなく、お客様の生活に寄り添い、一人ひとりに新しい価値を提案していく必要があると強く感じました。そこで生まれたのが『タッチトリガー』です。Suica に紐づく改札データを集約し、利用駅や時間帯、行動の文脈などに基づいて分析していけば、パーソナライズされた情報やサービスをお届けできます。私たちは改札タッチのタイミングをお客様とのコミュニケーションのきっかけにしたいと考えています。そのため『タッチトリガー』を、お客様の生活の利便性や快適さを上げていくための『コミュニケーション機能』として位置づけています。」

このような発想を根底で支えるのが、リアルなネットワークです。JR東日本の鉄道網は関東や東北、北陸に広がり、乗降客数は 1 日約 1,600 万人に上ります。ところが従来は、改札を通過した際に発生するデータはオンプレミスを軸にした社内システムで処理されており、巨大なポテンシャルをフルに活かしきれずにいました。この方法は、0.2 秒という超高速処理を実現するうえでは理にかなっていました。しかしマーケティングを担当するデジタルビジネスユニットの村上洋輔氏は、全社横断的なデータ活用が急務だったと振り返ります。

「改札ゲートはお客様の生活に密着したタッチポイントで、物理的な数の多さや、そこから得られるデータは、鉄道事業者ならではの強みだと考えています。また、あらゆる地域には駅を中心に商圏や生活圏が広がり、弊社のグループでもさまざまな部署が事業を展開していますので、データを横断的に活用すれば、大きなシナジーを生み出すことができます。そのためにも、運用基盤をクラウド化していくことが重要になっていました。折しも、Suica 全体をクラウド化していくという動きが全社的に進んでいましたので、『タッチトリガー』も、その流れと足並みをそろえることになりました。」

Spanner と Cloud Run で厳しいトラフィック処理の要件をクリア

ただし、データ処理のシステムをクラウドに移行するためには、厳しい技術要件がありました。まず 1 日のタッチ数は、山手線内の駅だけでも数百万回にのぼり、ラッシュ時には平常時の 10 倍にも跳ね上がります。無数の改札から送られてくるデータを、クラウド上のサーバーで処理するためには、トラフィックの急増に対応するスケーラビリティと、データを瞬時に記録する書き込み性能が鍵を握ります。これを満たすことができるのは、Google Cloud の製品だけだったといいます。

「ほぼすべてのクラウド型データベースで検証したところ、一般的な RDB（リレーショナルデータベース）では処理能力に上限があり、要件を満たせないことがわかりました。しかし Spanner だけは違いました。データを自動で振り分けながら、高い整合性を保つことができますし、Cloud Run と組み合わせることで、乗客の増減に応じてほぼタイムラグなくオートスケールできることもわかりました。テスト実装の段階で、想定どおりのスペックが出たことに開発チームは驚いていました。Spanner と Cloud Run がなければ、『タッチトリガー』を今の形で実現させることは難しかったでしょう。」（廣瀬氏）

実装の際には、いくつかの工夫もなされています。データ活用を行うには、年代や利用駅、購買履歴といった属性と、マーケティングの目標を瞬時に掛け合わせる作業が不可欠となります。ただし Spanner はデータの整合性を維持するために、独自のインデックス設計を採用しており、データ加工が必要となります。そこで技術的な支援を行ったのが、Google Cloud のサポートチームでした。

「本格的に Spanner を使うのは初めてでしたが、あまり試行錯誤することなく、最適解にたどり着くことができたと感じています。現場のエンジニアたちも、処理スピードやコスト最適化の方法や、Data Boost を活用した分析クエリに対するリソースの競合の回避方法など、多くのノウハウを吸収しました。Google Cloud と協働しながら改札システムのクラウド化を進めていけば、改札を抜けてホームに向かう間に、パーソナルな通知が届くような環境も構築していけると思います。」（廣瀬氏）

「タッチトリガー」が活性化させていく、毎日の暮らしと地域コミュニティ

「タッチトリガー」は 2024 年に山手線内の全駅に実装され、その後、JR東日本管内の新幹線停車駅や大井町などへ対象を広げています。最初に活用されたのは、同社が毎年開催している「山手線謎めぐり」というイベントでした。「タッチトリガー」のシステムやオペレーションを担当する、デジタルビジネスユニットの新名恵里佳氏は、盛り上がりを鮮明に覚えていました。

「これは沿線の街を散策しながら、謎解きをしていく体験型のイベントで、毎年多くの方にご参加いただいています。2024 年は Suica をタッチすると、駅に応じたコンテンツが配信される仕組みを採り入れました。参加した方からは『Suica でこんなことができるんだ！』という驚きの声があがっていました。その後、2025年には『みんなのトレインタウン』というスマホゲームでも、ミッションの達成条件に『改札タッチ』を組み込み、アイテムを獲得できるようにする施策なども行っています。」

また、JR東日本が推進する「まちづくり」との連携も進んでいます。同社は駅と接続する大型複合施設「TAKANAWA GATEWAY CITY」を 2025 年にオープン。その「まちびらき」に伴い、実証実験が行われました。同本部まちづくり部門品川ユニットチーフの小坂和広氏は、反響の大きさが想像以上だったと説明します。

「弊社のオフィスでは入館管理に Suica を使っており、この方法を他の用途に活用できないかという声は以前からありました。ちょうど全社的に『タッチトリガー』のプロジェクトが始まっていましたので、アプリと Suica を連携していただいたユーザーの方を対象に、改札を出ると施設内のお店でドリップコーヒーをプレゼントするクーポンを配信しました。アプリはローンチしたばかりでしたが、用意した 800 袋を 4 日間で配り終えるなど、想像以上の効果が得られました。提案する情報や通知のタイミングを含め、テストを重ねてより良い方法を探っていければと考えています。」

2026 年 3 月には大井町駅で、コンビニエンスストアの NewDays と連携し、おすすめ情報やクーポンを配信する施策が開始されています。一方、新幹線では、より踏み込んだ取り組みが行われてきました。村上氏によれば、2025 年には「GunMaaS」（群馬県内のさまざまな交通手段をシームレスに結びつけるスマートフォン向けサービス）と連携し、高崎駅で降りる乗客にタクシーを配車する試みが始まりました。「新幹線は『タッチトリガー』の展開という点で、非常にわかりやすいケースになっています。お客様が利用される便の時間や目的地、車内での滞在時間はあらかじめ把握できますので、乗車中はドラマや漫画などのコンテンツをご案内し、現地についたときには地元のタクシー会社がすでにお待ちしている。観光や宿泊情報のご提案なども、その方のニーズや志向に合わせて実施することができます。これを重ねていくことで、お客様と各事業者双方にとって Win-Win の関係を構築できます。」現在、同社は JRE ID の一本化に取り組んでおり、2028 年に Suica アプリ（仮称）が新たにリリースされれば、本格的な 1 to 1 コミュニケーションも可能になる見込みです。改札ゲートを起点に、データ活用の在り方が変わり、地域社会が変わり、毎日の生活が変わっていく。「タッチトリガー」と JR東日本の挑戦は、さらに加速していきます。

「『タッチトリガー』は、駅商圏を中心にサービスを展開する事業と特に相性が良いので、グループ外の企業とも実証実験を進めていく予定です。むろんお客様に安心してご利用いただけることが何よりも大切ですので、各種アプリと連携する際にはお客様の同意を得たうえで、情報を必要な範囲に限り、適切かつ安全に取り扱います。そのうえで『タッチトリガー』を軸にコミュニケーションを充実させ、すべての駅を、クオリティオブライフの充実や新たな事業展開、そして地域活性化を推進するハブにしていければと考えています。」（廣瀬氏）

東日本旅客鉄道株式会社（JR東日本）
1987 年に日本国有鉄道（国鉄）の分割民営化により設立。首都圏を中心に関東甲信越から東北までの東日本エリアの鉄道網を管轄し、営業キロは 7,418.7 km、輸送人員は 1 日あたり約 1,600 万人を誇る世界最大級の旅客鉄道会社。従来の交通事業に加え、Suica を核とするデジタルトランスフォーメーション、駅ビルや商業施設を中心としたまちづくりを推進。国際交流拠点「TAKANAWA GATEWAY CITY」、都市生活共創拠点「OIMACHI TRACKS」を中心とした「広域品川圏」の都市開発にも取り組む。

インタビュイー（写真右から）:
マーケティング本部
・戦略・プラットフォーム部門副部門長　廣瀬道輝氏
・戦略・プラットフォーム部門デジタルビジネスユニット　村上洋輔氏
・戦略・プラットフォーム部門デジタルビジネスユニット　新名恵里佳氏
・まちづくり部門品川ユニット TAKANAWA GATEWAY CITY（デジタルサービス戦略）チーフ　小坂和広氏

※文中の組織名・役職名は取材当時のものです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

gcloud の例

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

API の例

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

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

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

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

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

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

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

Yahoo の影響と結果

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Uber の事例の要点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

顧客事例

AI が自らモデルを進化させる時代へ。カインズが AlphaEvolve で需要予測の誤差を 19% 改善

全店舗・最大 3,000 万行におよぶ需要予測の歩みと、属人化からの脱却

3 年間の試行錯誤で見えてきた、人間による特徴量設計とモデル改善の限界

自律的にアルゴリズムを進化させる「AlphaEvolve」との出会い

予測誤差を 19% 削減し、複数モデルの統合による運用効率化とコスト削減を実現

今後の展望：人が特徴量を考える時代から、AI が自らモデルを進化させる時代へ

Sky: Gemini を全社で一斉に導入し、98% の利用定着率と 2,000 個近いエージェントの共有を実現

「SKYAI」の内製開発で定着した AI 活用文化を、いかに発展させるか

横断検索の精度、データ連携、ガバナンスを評価して Gemini を選定

「従業員が AI と一緒に働く」環境を構築し、独自のスタイルを追求

ZenteiQ、llm-d を搭載した GKE Inference Gateway でバッチ推論のスループットを 4 倍に拡大

Gemini エージェントがスタートアップにもたらすメリット

Gemini エージェントとは

スタートアップ向けの 5 つの重要ポイント

すでに実践している創業者

最新生成 AI 活用事例 121 社を一挙公開！ AI エージェントの本格活用が広がる（2026 年 10 月更新）

10 月版で新しく追加された事例

第 6 回 生成 AI 事例アワード ピッチコンテスト

Visko が Google Cloud TPU でリアルタイムの世界モデルをストリーミングする仕組み

ライブ世界モデルでインタラクティブ メディアを再定義

ライブ動画は厳しい時間的制約との戦い

単一の TPU スライスでマルチモーダル パイプラインを構築する

リアルタイムのパフォーマンスの内訳: タイムリミット

スタックの内部: リアルタイム ストリーミングを実現した 3 つの最適化

AI ビルダーのためのフィールド ノート: Cloud TPU のレッスン

Cloud TPU でリアルタイム生成モデルを構築している場合は、ここから始めましょう

サイバーエージェント: Cloud Run や Agent Development Kit を活用し、クリエイティブ生成 AI プラットフォーム「AI SCREAM」のエージェント化を推進

独自プラットフォーム「AI SCREAM」で全社員に生成 AI を届ける

エージェント化によって営業メンバーもクリエイティブ制作の担い手に

より対話的な体験を追求、そして社外への展開も開始

アイルランドにおけるイノベーション: アイルランド企業が Gemini によって事業を拡大している方法

エンタープライズ向けツールで事業を拡大するアイルランドのスタートアップ

アイデアを構想から本番環境へ

AI21、AI Hypercomputer の導入により AI ワークロードの起動時間を 83% 短縮

高使用率クラスタの行き詰まり

適切なスケジューラの選択

オープンソースとのフィードバックループの確立

同じフリートで、よりスムーズに

オーケー: AlloyDB と Database Migration Service で「止められない基幹システム」を移行し、データドリブンな価値創出を加速

ビジネスの急成長を受けて高まった、2 つの基幹データベース刷新の必要性

AlloyDB の採用により、業務の根幹を支えるデータベースの移行と基盤統一を実現

Gemini や AlloyDB AI も活用しながら、DX と新たな価値創出を追求

Orange はどのように FinOps のアカウンタビリティを確立し、なぜ次にエージェントなのか

Clean Days が効果的な理由

100 人を超える場合

信頼から始め、自律性を追加する

住友重機械工業: Google Cloud で SDV 開発基盤を構築し、大型機械用ソフトウェア開発の高速化と人材育成を両立

加速する SDV の流れに対応するために、Google Cloud でプラットフォームを構築

デジタルツインを活用した事前検証を行い、実機実験を 1 回でクリア

Cloud Workstations と TAP で最適なクラウド人材の育成環境を整備

JR東日本: Spanner と Cloud Run で「タッチトリガー」を実現し、改札データを起点に新たなコミュニケーションと価値を創出

改札というリアルな接点から生まれる、生活に密着したデータ

Spanner と Cloud Run で厳しいトラフィック処理の要件をクリア

「タッチトリガー」が活性化させていく、毎日の暮らしと地域コミュニティ

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

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

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

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

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

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

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

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

gcloud の例

API の例

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

Yahoo の影響と結果

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

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

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

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

Uber の事例の要点

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

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

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

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

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

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

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

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

第 6 回生成 AI 事例アワードピッチコンテスト

ライブ世界モデルでインタラクティブメディアを再定義

単一の TPU スライスでマルチモーダルパイプラインを構築する

スタックの内部: リアルタイムストリーミングを実現した 3 つの最適化

AI ビルダーのためのフィールドノート: Cloud TPU のレッスン

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

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

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

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

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

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

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

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

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

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

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

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