AI & 機械学習

新しい GKE Cloud Storage FUSE プロファイルにより、AI ストレージの構成における当て推量が不要に

Thu, 16 Apr 2026 02:00:00 +0000

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

AI / ML の世界では、データはトレーニングと推論のワークロードに欠かせない要素です。Google Kubernetes Engine（GKE）ユーザーは、Cloud Storage FUSE を使用して Google Cloud Storage に保存されているデータに高いパフォーマンスでスケーラブルにアクセスできます。しかし、Cloud Storage FUSE のパフォーマンスを最大限に引き出すのは複雑な場合がある、というお客様の声が寄せられていました。

このたび、GKE Cloud Storage FUSE プロファイルが導入されました。この新機能は、運用オーバーヘッドを最小限に抑えながら、パフォーマンス調整を自動化し、AI / ML ワークロード（トレーニング、チェックポイント、推論）のデータアクセスを高速化するように設計されています。特定のワークロードのニーズに合わせて調整されたこれらのプロファイルを使用すると、Cloud Storage FUSE の高いパフォーマンスをすぐに活用できます。

導入前（手動調整）

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: serving-bucket-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 64Gi\r\n persistentVolumeReclaimPolicy: Retain\r\n storageClassName: ""\r\n claimRef:\r\n name: serving-bucket-pvc\r\n mountOptions:\r\n - implicit-dirs\r\n - metadata-cache:ttl-secs:-1\r\n - metadata-cache:stat-cache-max-size-mb:-1\r\n - metadata-cache:type-cache-max-size-mb:-1\r\n - file-cache:max-size-mb:-1\r\n - file-cache:cache-file-for-range-read:true\r\n - file-system:kernel-list-cache-ttl-secs:-1\r\n - file-cache:enable-parallel-downloads:true\r\n - read_ahead_kb=1024\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: BUCKET_NAME\r\n volumeAttributes:\r\n skipCSIBucketAccessCheck: "true"\r\n gcsfuseMetadataPrefetchOnMount: "true"\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: serving-bucket-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 64Gi\r\n volumeName: serving-bucket-pv\r\n storageClassName: ""\r\n–--\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: gcs-fuse-csi-example-pod\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\nspec:\r\n containers:\r\n # Your workload container spec\r\n ...\r\n volumeMounts:\r\n - name: serving-bucket-vol\r\n mountPath: /serving-data\r\n readOnly: true\r\n serviceAccountName: KSA_NAME \r\n volumes:\r\n - name: gke-gcsfuse-cache # gcsfuse file cache backed by RAM Disk\r\n emptyDir:\r\n medium: Memory \r\n - name: serving-bucket-vol\r\n persistentVolumeClaim:\r\n claimName: serving-bucket-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb86021eeb0>)])]>

導入後（Cloud Storage FUSE のマウントオプション、CSI 構成、ファイルキャッシュメディアが自動的に構成されます）

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: serving-bucket-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 64Gi\r\n persistentVolumeReclaimPolicy: Retain\r\n storageClassName: gcsfusecsi-serving\r\n claimRef:\r\n name: serving-bucket-pvc\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: BUCKET_NAME\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: serving-bucket-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 64Gi\r\n volumeName: serving-bucket-pv\r\n storageClassName: gcsfusecsi-serving\r\n–--\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: gcs-fuse-csi-example-pod\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\nspec:\r\n containers:\r\n # Your workload container spec\r\n ...\r\n volumeMounts:\r\n - name: serving-bucket-vol\r\n mountPath: /serving-data\r\n readOnly: true\r\n serviceAccountName: KSA_NAME \r\n volumes: \r\n - name: serving-bucket-vol\r\n persistentVolumeClaim:\r\n claimName: serving-bucket-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb86091c280>)])]>

Cloud Storage FUSE の最適化に伴う課題

高パフォーマンスのワークロード向けに Cloud Storage FUSE を最適化することは、多次元的な問題です。従来、ユーザーは数十ページに及ぶ手動構成ガイドを読み解く必要がありました。AI / ML の進化に伴い、Cloud Storage FUSE の機能も強化され、ワークロードを高速化するための新しいマウントオプションが利用できるようになりました。設定が「適切」かどうかは静的なものではなく、さまざまな動的要因に大きく左右されるものでした。

バケットの特性: データセットの合計サイズとオブジェクトの数は、メタデータとファイルキャッシュの要件に大きく影響します。
インフラストラクチャの多様性: GPU、TPU、汎用コンピューティングのいずれを使用するかによって、最適な構成は異なります。
ノードリソース: Cloud Storage への費用のかかるラウンドトリップを最小限に抑えるためにローカルにキャッシュ保存できるデータの量は、利用可能な RAM とローカル SSD の容量によって決まります。
ワークロードパターン: トレーニングワークロード（大規模データセットの高スループット読み取り）では、チェックポイントワークロード（バースト性が高い、高スループット書き込み）やサービングワークロード（レイテンシの影響を受けやすいモデルの読み込み）とは異なる調整が必要です。

実際、多くのお客様は、Cloud Storage FUSE の設定が最適化されていないか、誤って構成されているために、利用可能なパフォーマンスを十分に活用できていないか、信頼性の問題（Pod のメモリ不足による強制終了など）に直面しています。

GKE 向け Cloud Storage FUSE プロファイルの概要

GKE Cloud Storage FUSE プロファイルは、特定の AI / ML パターンに合わせてカスタマイズされた、事前定義された動的管理の StorageClass を使用して、この複雑さを簡素化します。数十ものマウントオプションを手動で調整する必要はなく、ワークロードのタイプに一致するプロファイルを選択するだけでかまいません。

これらのプロファイルは、階層化されたモデルで機能します。Cloud Storage FUSE の基本的なベストプラクティスをベースに、GKE 固有のインテリジェンスレイヤを追加します。プロファイルを使用して Pod をデプロイすると、GKE は自動的に次の処理を行います。

バケット（または特定のディレクトリ）をスキャンして、そのサイズとオブジェクト数を把握します。
ターゲットノードを分析して、利用可能な RAM、ローカル SSD、アクセラレータタイプを確認します。
最適なキャッシュサイズを計算し、最適なバッキングメディア（RAM またはローカル SSD）を自動的に選択します。

リリース時には、次の 3 つの主要なプロファイルが用意されています。

gcsfusecsi-training: GPU と TPU にデータを供給し続ける高スループットの読み取りに最適化されています。
gcsfusecsi-serving: モデルの読み込みと推論に最適化され、自動化された Rapid Cache 統合が可能です。
gcsfusecsi-checkpointing: 数ギガバイトの大きなチェックポイントファイルを高速かつ確実に書き込むように最適化されています。

GKE Cloud Storage FUSE プロファイルを使用すると、次のようなメリットがあります。

調整の簡素化: 複雑でエラーが発生しやすい手動構成が、3 つのシンプルな専用 StorageClass に置き換えられます。
リソースを認識した動的な最適化: CSI ドライバは、リアルタイムの環境シグナルに基づいてキャッシュサイズを自動的に調整するため、ノードの安定性を損なうことなくパフォーマンスを最大化できます。
読み取りパフォーマンスの向上: サービングプロファイルは Rapid Cache を自動的にトリガーし、データをコンピューティングの近くに配置して、コールドスタートモデルの読み込みを高速化します。
きめ細かなパフォーマンス分析情報: 構造化されたログを通じて自動調整の決定を可視化し、特定のキャッシュサイズとメディアが Pod に対して選択された理由を正確に把握できます。

GKE Cloud Storage FUSE プロファイルの推論プロファイルを使用することで、TPU（480 GB）上の Qwen3-235B-A22B ワークロードのモデル読み込み時間を 39 時間からわずか 14 分に短縮できました。これにより、お客様は Cloud Storage FUSE GCSFuse をすぐに使用して最大限のメリットを得ることができます。

GKE で Cloud Storage FUSE プロファイルを使用する方法

まず、Cloud Storage FUSE CSI ドライバが有効になっている GKE バージョン 1.35.1-gke.1616000 以降がクラスタで実行されていることを確認します。

1. StorageClass を特定する

GKE には、プロファイルベースの StorageClass がプリインストールされています。次のコマンドで確認できます。

code_block: <ListValue: [StructValue([('code', 'kubectl get sc -l gke-gcsfuse/profile=true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb86091cbb0>)])]>

2. PV と PVC を作成する

PersistentVolume を作成する際、Cloud Storage バケットを参照するようにします。GKE は、最適な構成を判断するためにバケットスキャンを自動的に開始します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: gcs-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 5Gi\r\n persistentVolumeReclaimPolicy: Retain \r\n storageClassName: gcsfusecsi-training\r\n mountOptions:\r\n - only-dir=my-ml-dataset-subdirectory # Optional\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: my-ml-dataset-bucket\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: gcs-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 5Gi\r\n storageClassName: gcsfusecsi-training\r\n volumeName: gcs-pv'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb86091c490>)])]>

3. デプロイを作成する

PersistentVolumeClaim（PVC）がバインドされたら、他のボリュームと同様に Deployment で使用するだけです。GKE は、ハードウェアとデータセットに必要となる正確な設定でボリュームをマウントします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: my-deployment\r\nspec:\r\n replicas: 3\r\n selector:\r\n matchLabels:\r\n app: my-app\r\n template:\r\n metadata:\r\n labels:\r\n app: my-app\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\n spec:\r\n serviceAccountName: my-ksa\r\n containers:\r\n - name: my-container\r\n image: busybox\r\n volumeMounts:\r\n - name: my-gcs-volume\r\n mountPath: "/data"\r\n volumes:\r\n - name: my-gcs-volume\r\n persistentVolumeClaim:\r\n claimName: gcs-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb86091c8b0>)])]>

デプロイ後、CSI ドライバは、GPU や TPU、メモリ、ローカル SSD、バケットまたはサブディレクトリのサイズ、サイドカーのリソース上限など、ノードのリソースに基づいて最適なキャッシュサイズとマウントオプションを自動的に計算します。

使ってみる

GKE Cloud Storage FUSE プロファイルを使用すると、高パフォーマンスなクラウドストレージを構成する際に当て推量が不要になります。手動の「ノブ調整」からワークロードを認識する自動プロファイルに移行することで、ストレージスループットのデバッグに費やす時間を減らし、次世代の AI の構築に多くの時間を費やすことができます。

ぜひご利用ください。GKE Cloud Storage FUSE プロファイルは、バージョン 1.35.1-gke.1616000 で一般提供されています。AI / ML ワークロード向けに GKE で Cloud Storage FUSE プロファイルを構成する方法については、公式ドキュメントをご覧ください。

- エンジニアリングマネージャー、Nishtha Jain

- ソフトウェアエンジニア、Uriel Guzmán-Mendoza

Vertex AI の Lyria 3 モデルで音楽生成をアプリに組み込む

Tue, 14 Apr 2026 03:00:00 +0000

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

最新情報: Google の音楽生成モデルファミリーである Lyria 3 が、Vertex AI で公開プレビュー版としてご利用いただけるようになりました。Lyria 3 モデルを使用すると、テキストプロンプトや画像から、ボーカルサポート付きの高音質かつ高忠実度のステレオ音声を生成できます。

多様なニーズにお応えするため、API を通じて 2 つの異なるモデルを提供しています。

Lyria 3 Pro: 最長 3 分の完全な楽曲を生成します。音楽の構成を理解し、イントロ、A メロ、サビ、ブリッジなどの特定の構成要素を考慮します。
Lyria 3: 最長 30 秒のトラックを生成します。迅速なプロトタイピング、ソーシャルメディアアセット、短尺音声の生成に最適です。

ビジネスにとって重要である理由: これらのモデルは、ボーカル、タイミングに合わせた歌詞、完全なインストゥルメンタルアレンジなど、構造的な一貫性を提供します。スタジオ品質の音声制作をアプリに直接組み込むことができ、以下のような制作が可能になります。

マルチモーダル入力: 標準的なテキストプロンプトを使用するか、参照画像を使用してストーリー、ムード、スタイルをガイドすることで、音声を生成します。
ボーカルと歌詞: ボーカルと、タイミングを合わせた歌詞を生成したり、ユーザーが提供した歌詞を使用してトラックをガイドしたりできます。ボーカルなしの BGM が必要な場合は、プロンプトに「インストゥルメンタル」と入力します。
柔軟な構成: 尺調整機能を使用して、明確なイントロ、A メロ、サビ、ブリッジを持つフル楽曲を生成できます。

Lyria へのアクセス方法: Vertex AI API と Vertex AI Media Studio からモデルにアクセスできます。

Lyria 3 モデルがお客様のオーディオエクスペリエンスの実現にどのように役立っているか

「Artlist は、音楽に関する深い専門知識と、デジタル世界を形作るグローバルなサウンドトレンドを確立するというコミットメントに基づいて構築されています。豊富な経験を活かして、当社の『人間参加型』の音楽学と Google の最先端の生成音楽モデルを組み合わせることで、Lyria 3 の可能性を最大限に引き出しています。Lyria 3 は、これまでにないレベルのクリエイティブコントロールと高忠実度の出力を提供し、技術革新と Artlist ブランドを定義する本格的なサウンドの強力な融合を実現します。」- Artlist、最高製品技術責任者、Roee Peled 氏

「Lyria 3 により、『単なる生成』から『真のクリエイティブコントロール』への明確な移行を実感しています。これにより、Freepik のお客様は、ビジョンやワークフローに、より正確に沿った音楽を制作できるようになります。Lyria 3 で際立っているのは、その制御性の高さです。イテレーションの時間を短縮し、音楽生成を実際のクリエイティブパイプラインにおいて、はるかに予測可能で実用的なものにしています。」- Freepik、エンジニアリングリード、Carlos Perez 氏

商用利用の安全性と責任ある制作

責任ある開発は基本であり、Lyria 3 モデルの設計とトレーニングにおいて不可欠な要素です。YouTube と Google が利用規約、パートナー契約、適用法に基づいて使用権を持つ素材のみを使用しています。さらに、既存のコンテンツと照合して出力をチェックするフィルタを導入しているほか、ユーザーは他者の知的財産権やプライバシーの権利を侵害することを禁止する利用規約と生成 AI の使用禁止に関するポリシーを遵守する必要があります。Lyria 3 と Lyria 3 Pro のすべての出力には SynthID の透かしが埋め込まれ、C2PA に対応しています。

今すぐ制作に着手しましょう

ベストプラクティスについて詳しくは、以下のリソースをご覧ください。

モデルカード
Lyria のプロンプトに関する究極のガイド
Gen AI SDK for Python ノートブック
Gen Media MCP ツールでこれらのモデルを使用している場合は、こちらのエージェントスキルを介してドメイン固有のサウンドデザインの知識を提供できます。

Google Workspace または Google AI の定期購入をご利用のお客様は、Google Vids で Lyria 3 モデルを体験し、ブランドのスタイルに合ったカスタムトラックを動画に追加することもできます。

- Google Cloud、生成メディア担当グループプロダクトマネージャー、Sandeep Gupta

- Google Cloud、プロダクトマネジメント担当シニアディレクター、Reah Miyara

膨大な表計算作業から脱却。AI と数理最適化で実現する、需要予測の先の「発注・在庫管理の自動化」

Tue, 14 Apr 2026 03:00:00 +0000

商品、サービス、店舗を通じて、より効率的で最適なサプライチェーンの実現を目指す中で、需要予測の精度向上は株式会社カインズにとっても最優先課題です。しかし、精度の高い需要予測モデルを構築し予測結果を出力することはサプライチェーン全体においては入り口に過ぎません。

実際には、予測値が出た後に、SKU ごとの特性や季節性に応じた「予測結果の精査」や「発注・在庫管理のためのメンテナンス」という不可欠な実務工程が存在し、その膨大な作業を表計算ソフトによる手作業で支えているという実態がありました。

本記事では、Vertex AI による需要予測の次のステップとして、AI エージェントを組み合わせることで、190 万行に及ぶ SQL 処理と複雑な表計算ソフト作業をどのように刷新したのか、株式会社カインズの取り組みの舞台裏を詳しく紹介します。

利用しているサービス:
Big Query、Vertex AI、Cloud Run Jobs、Workflows、Vertex AI Agent Builder (SDK)

「表計算ソフト作業」への依存がもたらす限界

これまで、需要予測の結果を実務に反映させるプロセスは、まさに「表計算ソフト作業との格闘」でした。システムから出力されるデータは、190 万行に及ぶ膨大な SQL クエリ結果を発注点メンテナンス向けの表計算ソフトの作業用シートに書き出したもので、その出力だけで丸 2 日を要していました。

出力されたデータは 1 ファイルに収まりきらず、20 万行ごとに 6〜7 個のファイルに分割して管理されていました。現場の担当者は、これらのファイルに対して棚割りデータや在庫データ、直近の売上実績などから様々なフラグを作成したり、他システムで管理しているマスタデータを VLOOKUP 等の関数で紐付けたりしていました。さらに「この在庫は動かさない」といった個別のフラグを手作業で立てるなど、複雑で膨大な表計算ソフト作業を行っていました。

「こうした表計算ソフト作業でメンテナンスを行うこと自体が、もはや正解ではないと感じていました」と、矢口氏は当時の課題を振り返ります。表計算ソフトの作業用シートのメンテナンスは、専任の担当エンジニアがつきっきりで数式の変更や列の追加要望に対応していましたが、列ずれの確認やテストに多大な工数がかかり、現場のニーズに即座に応えることが難しい状況にありました。

AI エージェントの導入：自然な対話で「発注点メンテナンス」を民主化

この課題を根本から解決するために導入されたのが、AI エージェントを活用したデータ処理基盤です。Vertex AI Agent Builder を活用し、ユーザーが自由な条件でデータの絞り込みを行える仕組みを構築しました。

従来の運用では、メンテナンスの要望があるたびに表計算ソフト作業のロジックを書き換える必要がありましたが、AI エージェントを介することで、ユーザー自身が「この条件でデータを抽出してほしい」といった指示を出し、BigQuery 上のデータを直接操作・抽出することが可能になりました。

また、需要予測の「後工程」として非常に負荷が高かったのが、酒類などの発注において「車建発注（在庫回転日数をコントロールしつつトラック積載量を最大化する）」の最適化計算です。これまでは、カインズ側でベースの発注量を 1 日かけて表計算ソフトで算出して翌日に取引先に送付し、取引先側で車建計算を行っていました。しかし、数理最適化を使ったアルゴリズムを開発し、計算を組み込むことでこのプロセスを自動化。現在ではカインズ自身で車建発注量の計算を行えるようになりました。

導入効果：劇的な業務削減と「あるべき姿」への集中

今回の取り組みにより、主に以下の 3 つの成果が得られました。

劇的な工数削減： 2〜3 日かかっていた発注点メンテナンスのためのデータ抽出および表計算ソフト作業が大幅に効率化されました。
柔軟性の向上：Vertex AI Agent Builder を使った AI エージェントの導入により、自分たちで「やりたいこと」を AI エージェントを通じて即座に実行できる内製化のスピード感が実現しました。
データの正確性と一貫性：複数のファイルに分散しローカル保存されていた表計算ソフト作業のデータが BigQuery という単一のソースに統合され、属人的な数式ミスや列ずれの不安が解消されました。

「需要予測を起点に発注管理から在庫管理まで、すべて統合された基盤で実行することが可能になった」と矢口氏は語るように、点在していた業務プロセスが Google Cloud 上で統合されたことが、最大の価値となっています。

今後の展望：数理最適化のさらなる拡張と AI エージェントの融合

現在はローカル環境で行っている数理最適化計算のリクエスト処理なども、順次 AI エージェント上に移行していく予定です。またシーズン商品の最適化や棚割の最適化など、より複雑な変数が絡む領域への数理最適化の適用も視野に入れています。

AI が単に予測値を出すだけでなく、実務における判断をサポートし、複雑な計算を肩代わりする。株式会社カインズにとって、この「需要予測のその先」の実現こそが、小売・流通業界における真の DX の鍵となるはずです。

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

インタビュイー
株式会社カインズ　
ビジネスソリューション部需要予測グループ　グループマネジャー　矢口未知彦氏

GKE Inference Gateway を使用して、同じインフラストラクチャでリアルタイム推論と非同期推論を実行する

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

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

AI ワークロードが実験的なプロトタイプから本番環境グレードのサービスに移行するのに伴い、それらをサポートするインフラストラクチャは、利用率のギャップが拡大するという課題に直面しています。昨今の企業は通常、同時実行性が高く、低レイテンシのリアルタイムリクエストに対応するシステムを構築するか、高スループットの「非同期」処理用に最適化するかという二者択一を迫られています。

Kubernetes 環境では、従来、これらの要件には、サイロ化された別々の GPU および TPU アクセラレータクラスタによって対応してきました。リアルタイムトラフィックは、バーストを処理するためにオーバープロビジョニングされるため、オフピーク時には大幅なアイドル容量が発生する可能性があります。一方、非同期タスクは多くの場合、セカンダリクラスタに追いやられるため、ソフトウェアスタックが複雑化し、リソース管理が断片化します。

AI サービングワークロードの場合、Google Kubernetes Engine（GKE）は、推論パターンの全範囲に対応する統合プラットフォームである GKE Inference Gateway を使用して、この「費用とパフォーマンス」のトレードオフに対処します。Google は OSS ファーストのアプローチを活用することで、アクセラレータの容量を単一の流動的なリソースプールとして扱うスタックを開発しました。これにより、決定論的なレイテンシと高スループットの両方を必要とするワークロードに対応できます。

この投稿では、最新の AI サービスを推進する 2 つの主要な推論パターンと、それぞれのパターンにおける問題および現在利用可能なソリューションについて説明します。このブログ記事を最後までお読みいただくと、GKE が GKE Inference Gateway を介してこれらのパターンにどのように対応するかについておわかりいただけます。

2 つの推論パターン: リアルタイムと非同期

このブログ記事では、リアルタイムと非同期という 2 種類の AI 推論ワークロードを取り上げます。リアルタイム推論の場合、これらは優先度の高い同期リクエストです。たとえば、お客様が LLM からの即時レスポンスを待っている、chatbot とのやり取りなどです。一方、小売業におけるインデックス登録や商品分類のドキュメント化などの非同期トラフィックでは、通常、レイテンシが許容されます。つまり、トラフィックはキューに入れられ、遅延して処理されることがよくあります。

1. リアルタイム推論: レイテンシの影響を受けやすい 0 秒のリクエスト

優先度の高い同期トラフィックの場合、レイテンシが最も重要な指標となります。しかし、従来のロードバランシングでは、高レイテンシを示す KV キャッシュ使用率などのアクセラレータ固有の指標が無視されることが多いため、パフォーマンスを最適化できません。

ソリューション: GKE Inference Gateway

この問題のソリューションは、Inference Gateway です。Inference Gateway は、リアルタイムの指標（KV キャッシュのステータスなど）に基づいてモデルサーバーのパフォーマンスを予測し、レイテンシを考慮したスケジューリングを実行して、最初のトークンまでの時間を最小限に抑えます。これにより、キューイングの遅延も減り、負荷が高い場合でも一貫したパフォーマンスを確保できます。

2. 非同期（ニアリアルタイム）推論: 0 分のレイテンシ

レイテンシが許容されるタスクは、ミリ秒単位の要件ではなく、分単位のサービスレベル目標（SLO）で動作します。従来のセットアップでは、リアルタイムトラフィックとのリソース競合を防ぐために、これらのリクエストを別々の専用インフラストラクチャで実行することがよくありました。この静的なパーティショニングは、利用の断片化とハードウェア費用の膨張につながる可能性があります。さらに、カスタムビルドの非同期ポーラーは、通常、同じアクセラレータにワークロードを多重化するために必要な高度なスケジューリングロジックを備えていないため、エンジニアは 2 つの異なる複雑なソフトウェアスタックを管理する必要があります。

ソリューション: 非同期プロセッサエージェント + Inference Gateway

Inference Gateway を Cloud Pub/Sub と統合する「プラグアンドプレイ」アーキテクチャ。バッチ処理エージェントは、構成されたトピックからリクエストを pull し、それらを「削除可能な」トラフィックとして Inference Gateway にルーティングします。システムはバッチタスクを「フィラー」として扱い、リアルタイムの急増の合間にアイドル状態のアクセラレータ（GPU / TPU）の容量を使用します。これにより、リソースの断片化が最小限に抑えられ、ハードウェア費用を削減できます。

主な機能:

リアルタイムトラフィックのサポート: リアルタイム推論トラフィックは Inference Gateway によって処理されます。
永続的なメッセージング: Pub/Sub を介して信頼性の高いリクエスト処理が行われます。
インテリジェントな再試行: キューの深さのリアルタイムモニタリングに基づいて、キューアーキテクチャに組み込まれた構成可能な再試行ロジックを活用します。
厳密な優先順位: ゲートウェイレベルでは、リアルタイムトラフィックがバッチトラフィックよりも常に優先されます。
緊密な統合: ユーザーは Pub/Sub トピックを「プラグイン」するだけで、エージェントが共有アクセラレータプールへのルーティングロジックを処理します。

図 1 : リアルタイム推論トラフィックと非同期推論トラフィックを解決するための統合アーキテクチャの概要。

上の図に示されているリクエストフローは次のとおりです。

ユーザーがリアルタイムリクエストを送信します。Inference Gateway はまずそのリクエストのスケジュール作成をします。
ユーザーは、構成された Pub/Sub トピックを介して非同期推論リクエストをパブリッシュできます。
非同期プロセッサが、利用可能な容量に基づいてキューから読み取りを行います。
非同期プロセッサは、同じアクセラレータ（GPU / TPU）リソースを利用して、Inference Gateway を介してリクエストをルーティングします。リアルタイムリクエストが優先されます。非同期リクエストは、コンピューティングサイクルで未使用のアクセラレータに割り当てられます（上の図を参照）。
非同期プロセッサは、レスポンスを出力トピックに書き込みます。
ユーザーは、レスポンストピックから非同期リクエストのレスポンスを取得します。

これらのリアルタイムワークロードと非同期ワークロードを共有アクセラレータに統合することで、GKE は「費用とパフォーマンス」のパラドックスを解決します。脆弱なカスタムキューポーラーを管理したり、使用率の低いクラスタを個別に維持したりする必要はもうありません。さらに、これらの作業はすべてオープンソースで可能です。つまり、複数のクラウドや環境でこれらのプロダクトを使用できます。

統合ワークロードの実例

共有インフラストラクチャでリアルタイムワークロードと非同期ワークロードを実行するというアイデアは、理論的には素晴らしいものですが、実際にはどのように機能するのでしょうか。優先度の高いリアルタイムワークロードとレイテンシが許容されるバッチリクエストを統合リソースプール内で同時に処理する有効性を分析したところ、有望な結果が得られました。

リアルタイムトラフィックは、予測不能な急増が特徴です。低レイテンシの回答を維持するには、ピーク時にプールの容量の 100% をリアルタイムトラフィックに使用できるようにする必要があります。一方、レイテンシが許容されるタスクは、容量が使用可能になるまで保留状態のままにする必要があります。

最初のテストで、管理されていない多重化のリスクが明らかになりました。優先度が低く、レイテンシが許容されるリクエストが、非同期プロセッサエージェントを使用せずに Inference Gateway に直接送信された場合、リソースの競合によりメッセージの 99% が削除されました。しかし、非同期プロセッサを使用した場合、レイテンシが許容されるリクエストの 100% が利用可能なサイクル中に処理されました。

図 2: リアルタイムトラフィック + レイテンシが許容されるバッチトラフィックで使用率が向上することを示しています。

次のステップ

同じインフラストラクチャでリアルタイム AI ワークロードとバッチ AI ワークロードの両方を実行することに関心をお持ちの場合は、最初に、Inference Gateway を使用した非同期推論のクイックスタートガイドをご覧ください。GitHub で OSS プロジェクトに参加して、この取り組みに貢献することもできます。開発の次の段階では、期限を考慮したスケジューリングに重点を置き、ユーザーがバッチ完了期間に「ソフトリミット」を設定できるようにすることで、フィラートラフィックとリアルタイムの需要のバランスをシステムが取る方法をさらに最適化します。この重要な取り組みでコミュニティと連携できることを楽しみにしています。

- シニアプロダクトマネージャー、Poonam Lamba

- シニアスタッフソフトウェアエンジニア、Abdullah Gharaibeh

Google Cloud で利用できる Gemma 4 の概要: Google の最も高性能なオープンモデル

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

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

今回、Google Cloud での Gemma 4 をリリースいたしました。

最新情報: これは、サイズに対して最も高性能なオープンモデルファミリーです。Gemini 3 と同じ研究に基づいて構築され、商用利用の自由度が高い Apache 2.0 ライセンスでリリースされたこれらのモデルは、チャットの枠を超えて進化しています。最大 256K のコンテキストウィンドウ、ネイティブのビジョンと音声処理、140 以上の言語での流暢な対応を実現しており、特に複雑なロジック、オフラインのコード生成、エージェントワークフローに優れたモデルとなっています。モデルについて詳しくは、こちらをご覧ください。

ビジネスにとって重要である理由: エンタープライズ AI には、データを安全な境界内に保持しながら複雑なロジックを実行するモデルが必要です。Gemma 4 ではこれを両立できます。組織は、Sovereign Cloud ソリューションを含む厳格なコンプライアンス保証を満たすために、Google Cloud 全体でこれらのモデルをデプロイできます。これにより、デジタル主権の基盤が提供され、チームはデータ、インフラストラクチャ、モデルを完全に制御できるようになります。

Gemma 4 を使い始めるには

Vertex AIGemma 4 を独自の Vertex AI エンドポイントにデプロイします。Model Garden からモデルを選択し、アプリケーションに必要な特定のコンピューティングリソースをプロビジョニングします。このセルフデプロイモデルでは、Google Cloud 環境内にデータを保持しながら、サービングインフラストラクチャと費用を直接管理できます。

また、 Vertex AI Training Clusters（VTC）を使用して Gemma 4 をファインチューニングすることもできます。VTC は、NVIDIA NeMo Megatron を通じて、最適化された SFT レシピと高スケールなレジリエンスを提供します。これにより、エッジタスク向けの効率的な 2B（E2B）モデルから、複雑なエンタープライズオーケストレーション向けの 31B 高密度モデルまで、あらゆるバリアントを効率的に適応させることができます。 Vertex AI で Gemma 4 31B モデルを効率的にファインチューニングしてサービングするためのエンドツーエンドガイドをご覧ください。

さらに、Google は、Vertex AI で利用可能な自社モデル、オープンモデル、サードパーティモデルの厳選されたコレクションにより、お客様の選択肢を増やし、イノベーションを推進できるよう取り組んでいます。そこでこのたび、Gemma 4 26B MoE モデルが今後数日以内に Model Garden でフルマネージドのサーバーレスとして利用可能になることを発表いたします。

Agent Development Kit（ADK）ADK は、AI エージェントの開発とデプロイを目的として設計された、柔軟性の高いモジュール型オープンソースフレームワークです。Gemma 4 は、推論、関数呼び出し、コード生成、構造化出力などの高度なエージェント機能を備えています。ADK を使用すれば、Gemma 4 で完全に機能する AI エージェントを構築できます。Gemma 4 と Google ADK を使用して AI エージェントの構築を今すぐ開始しましょう。

Cloud RunNVIDIA RTX PRO 6000（Blackwell）GPU のパワーを活用して、要求の厳しい Gemma 4 推論ワークロードを Cloud Run で効率的に実行できるようになりました。96 GB の vGPU メモリにより、Gemma-4-31B-it などのモデルをサーバーレス GPU に簡単にデプロイできます。

基盤となるインフラストラクチャは Cloud Run で処理されるため、ユーザーはアプリケーションに集中できます。モデルは非アクティブ時にはゼロまでスケールダウンし、需要に応じて動的に調整されます。使用した分のみが課金対象となるため、費用が最適化されます。さらに、推論ワークロードごとに CPU とメモリの構成を柔軟に調整できます。us-central1 または europe-west4 では、予約なしでオンデマンドでご利用いただけます。今すぐお試しください。

Google Kubernetes Engine（GKE）GKE は、Gemma 4 をデプロイするためのスケーラビリティとカスタマイズ性に優れた環境を提供します。これは AI インフラストラクチャをきめ細かく制御する必要があるチームに最適です。GKE で独自のインフラストラクチャを管理することで、コンピューティングリソースを柔軟に調整し、特定の GPU または TPU アクセラレータを選択し、トラフィックパターンに正確に一致するカスタムの自動スケーリング指標を実装できます。この制御レベルにより、AI ワークロードを既存のマイクロサービスとシームレスに統合しながら、組織の厳格なセキュリティとデータコンプライアンスの要件を遵守できます。

このたび、高スループットでメモリ効率の高い LLM サービングエンジンである vLLM を使用して、GKE で Gemma 4 モデルを効率的にサービングできるようになりました。GKE を活用することで、リソース使用率と費用を最適化しながら、推論ワークロードをゼロからピーク需要までシームレスにスケールできます。使い始めるにあたって、GKE で Gemma 4 をサービングする方法に関する最新のチュートリアルをご覧ください。

将来に向けて、Gemma 4 は、Google Cloud 上で次世代のエージェントアプリケーションを強化できる独自の立場にあります。Gemma 4 のマルチステッププランニング機能と新しい GKE Agent Sandbox を組み合わせることで、開発者は LLM で生成されたコードとツール呼び出しを、高度に分離された Kubernetes ネイティブ環境内で安全に実行できます。この環境では、1 秒未満のコールドスタートと、1 秒あたり最大 300 のサンドボックスが提供され、安全かつ効率的なマルチステッププランニングが実現します。さらに、GKE Inference Gateway と llm-d の高度な分散推論機能（予測レイテンシベースのスケジューリングなど）を活用することで、これらの複雑なワークフローは、キャッシュの再利用とサーバー負荷を動的にバランスさせるインテリジェントなルーティングの恩恵を受けます。GKE Inference Gateway と予測レイテンシブーストを組み合わせると、ヒューリスティックな推測をリアルタイムの容量認識ルーティングに置き換えることで、最初のトークンまでの時間（TTFT）のレイテンシを最大 70% 削減できます。手動によるチューニングは必要ありません。

Google Cloud TPUGemma 4 は、GKE、GCE、Vertex AI を通じて Google Cloud 全体の TPU で利用可能になります。このたび、一般的によく使用されるさまざまなオープンソース TPU プロジェクトを使用して、Gemma-4-31B Dense と Gemma-4-26B-A4B MoE のサービング、事前トレーニング、事後トレーニングが可能になりました。

事前トレーニングと事後トレーニングのテストには MaxText を活用し、事後トレーニングを実施して、テキスト分析と生成、推論、画像分析のユースケースに合わせてカスタマイズできます。
オンラインサービングとバッチ推論では、本番環境ワークロード対応の vLLM TPU を使用できます。これには Google の事前構築済み Docker コンテナ、クイックスタートビジョン、テキストデモチュートリアルが使用されます。

コミュニティから提供される SGLang-JAX チュートリアルにもご期待ください。

Sovereign CloudGemma 4 は、すべてのSovereign Cloud サービスでご利用いただけます。これには、Data Boundary を活用したパブリッククラウド、Google Cloud Dedicated（フランスの S3NS など）、エアギャップとオンプレミスのデプロイ向け Google Distributed Cloud が含まれます。この拡大は、組織がデータ、暗号化、運用環境を完全に制御できる、オープンな主権のあるデジタル世界の実現という Google のコミットメントを強化するものです。

Gemma 4 は、オープンウェイトを提供することで、デベロッパーが機密性の高い環境向けの特別なソリューションを構築できるようにしています。企業や政府機関は、データ所在地とデータ主権に関する厳格なルールを満たしながら、地域ごとの違いやドメインの専門知識を尊重するローカライズされたサービスをデプロイできるようになりました。このアプローチにより、組織は国内および業界の要件を完全に遵守しながら、AI を活用して迅速にイノベーションを実現できます。

使ってみる

Vertex AI から Sovereign Cloud まで、Gemma 4 を使用した構築を今すぐ始めましょう。Google Cloud で Gemma 4 を選択することで、企業や主権組織は、最高水準のセキュリティと信頼性を満たしながら最先端の機能を提供する、信頼できる透明性の高い基盤が手に入ります。

- Google Cloud、チーフエバンジェリスト、Richard Seroter

Claude Mythos Preview: Vertex AI で限定公開プレビュー版を提供開始

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

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

Anthropic の最新かつ最も強力なモデルである Claude Mythos Preview が、Project Glasswing の一環として、Google Cloud の一部のお客様を対象に限定公開プレビュー版で利用可能になりました。

Vertex AI での Claude Mythos Preview の提供は、最先端の AI ラボのモデルをお客様に提供するという Google の取り組みを明確に示すものです。AI アプリケーションとエージェントの構築、スケーリング、管理を行うためのエンタープライズグレードの Vertex AI の機能と、この新しい汎用モデルを組み合わせることで、サイバーセキュリティリスクの低減に新たな焦点を当てつつ、多様なユースケースにおいて高いパフォーマンスを発揮します。

このリリースの詳細については、Anthropic のブログ投稿をご覧ください。

Claude Opus 4.6 や Claude Sonnet 4.6 などの他の Claude モデルを使用して、今すぐ Vertex AI で構築しましょう。

- Vertex AI、プロダクトマネジメント担当バイスプレジデント、Michael Gerstenhaber

FM Logistic が AlphaEvolve を使って倉庫規模の「巡回セールスマン問題」を解決

Wed, 08 Apr 2026 03:00:00 +0000

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

巡回セールスマン問題とは、「すべての地点を 1 回ずつ訪問する最短ルートは何か」という、一見すると単純な問題です。これはコンピュータサイエンスにおける最も難しい問題の一つであり、数学者は 1 世紀近くもこの問題に取り組んでいます。また、FM Logistic のポーランドの倉庫作業員が日々直面している課題でもあります。

倉庫は全体でサッカー場 8 面分の広さがあり、ピッキングポイントの数は 17,700 を超えています。シフトごとの作業員数は数十人にのぼり、その各人が電動車両に乗ってフロアを縦横に駆け巡り、1 度の巡回で数十か所の保管場所を回って段ボール箱を回収します。こうした作業において、不要な経路が積み重なっていくと、時間が無駄になるだけでなく、車両の劣化や、納品の遅延にもつながります。

14 か国以上でグローバル事業を展開する物流プロバイダの FM Logistic は、すでにルーティングを最適化する仕組みを有していました。既存のモデルは、費用優先の高速なルート割り当てロジックに基づき、リアルタイムで応答を得られるようなものです。これはこれでうまく機能していましたが、ルートの判断がその都度行われる仕組みになっており、倉庫全体から見たルート調整能力に限界がありました。一度のシフトで同時に働く作業員数が数十人にのぼることを考えると、ルートがわずかでも改善されれば、大きな効果に直結します。

そこで導入されたのが、Google Cloud の AlphaEvolve です。

AI に、もっと優れたアルゴリズムを書いてもらう

AlphaEvolve は、Gemini モデルを使ってアルゴリズムを自律的に生成、改良する進化型のコーディングエージェントです。固定ルールからスケジュールを計算するのではなく、コーディングパートナーのように動作するのが特徴で、新しいコードを記述し、スコアを付け、最初のコードよりも優れたソリューションが見つかるまで反復処理を行います。

この取り組みをゼロから始めたわけではありません。既存のアルゴリズムを AlphaEvolve に「シード」プログラムとして提供しました。このアルゴリズムは、各ステップごとに、最善と思われるルートをその都度採用するというものです。この実際に使用されているアルゴリズム（すでに問題を解決しており、まだ最適化の余地があるもの）をベースラインとして使用し、Gemini を使って変更や新しいロジックを加えて新たなコードを生成して、人間が設計した元のコードを上回ることができるかどうかを調べました。

改善結果の評価

AlphaEvolve によって改善するには、各アルゴリズムのパフォーマンスを測定する方法が必要となります。そこで、60 件の巡回（合計 1 時間以上の作業員データ）を代表的なデータセットとして使ってカスタム評価関数を設計し、生成された数千のアルゴリズムを実際の状況下でテストしました。

この評価では、「ピックごとの平均移動距離を最小に抑える」という基本的な目標に基づいてコードをスコア付けします。また、運用上の問題を回避するため、フォークリフトの容量超過や、注文品の回収漏れ、同じ箱の重複割り当て、注文の先入れ先出しルール違反、リアルタイム運用で許容される計算時間の超過といった事象にそれぞれペナルティを設け、不適切な解を避けられるようにしています。

結果

新しいルーティングロジックでは、過去最良だったベースラインからの改善をただちに数値で確認できました。

過去最良のソリューションと比較して、ルーティング効率が 10.4% 向上。
全体で、倉庫内の移動距離が年間 15,000 km 以上削減。

この効率化により、人員や車両を増やすことなく、従来と同じ作業員数および設備でより多くの注文を処理できるようになりました。

FM Logistic のグループ CIO である Rodolphe Bey 氏は、次のように述べています。「Google Cloud と協力して AlphaEvolve および Gemini を実装したことで、このスピードが要求される業務においてルーティングアプローチをさらに最適化することができました。既存のアルゴリズムもすでに高度に最適化されていたため、そのベースラインを超えることは困難と思われましたが、上乗せで 10.4% の改善を実現しました。この改善は、納品のスピードアップや、労働条件の改善、車両の劣化軽減に直結しています。」

最終的に勝ち残ったアルゴリズムの動作

AlphaEvolve の実験を繰り返し、実験のたびに数百の候補プログラムを生成するという方法によって、人間が設計した最良のアルゴリズムを上回る新しいアルゴリズムが生み出されました。この新しいアルゴリズムは、人間が解読可能なルールセットとなっており、倉庫チームが内容を確認して適宜調整することが可能です。

3 つの主な改善点:

密度ベースの開始点（アンカー選択）: 旧システムでは、最も多くのピッキングが必要な一か所を開始点として選択していました。新しいアルゴリズムでは、開始点を広く捉えるようになっています。具体的には、互いに近くにあるアイテム同士をクラスタ化して、アイテムが密集しているエリアを開始点（基点アンカーグループ）として使用します。この方法によって、すべての巡回において開始点の効率が高められます。
距離シミュレーションにおけるフィルタリング: リアルタイムに通用する速度を維持するため、2 段階の処理プロセスを使用しています。まず、クイックフィルタによって、ルートロジックに適さない注文を除外します。続けて、残った適切な候補に対してのみ厳密な距離シミュレーションを実行することで、スピードを落とすことなく最も効率の良い経路を見つけています。
柔軟なルート構築: ある出発点から初めて、トラックを効率的に満載にできなくなった場合、無駄なルートを強制することはありません。メインプールにいったん積み荷を戻し、後でもっと良いルートでピックすることで、倉庫全体で効率を向上させています。

次のステップ

ポーランドでの試験運用（現在は本番環境に移行済み）では、倉庫規模の複雑なルーティングにおいて、進化型 AI が役立つことが示されました。FM Logistic は現在、大量の商品を扱っている他の e コマース施設にもこのアルゴリズムを適用することを計画中です。また、AlphaEvolve を道路輸送にも応用し、トラックが積載量に満たない場合の効率化に役立てられないかどうか探っています。さらに、倉庫内の商品配置にも AI を活用して移動距離をさらに短縮できないかどうか検討中です。

^{このプロジェクトは、FM Logistic チーム（Mateusz Klimowicz、Jarosław Urbański、Florent Martin、Alberto Brogio）、Google Cloud の AI for Science チーム（Kartik Sanu、Laurynas Tamulevičius、Nicolas Stroppa、Chris Page、Gary Ng、John Semerdjian、Skandar Hannachi、Vishal Agarwal、Anant Nawalgaria、他）、Google DeepMind の協力によって実現しました。}

- FM Logistic、シニアソフトウェアエンジニア、Mateusz Klimowicz 氏

- Google、シニアスタッフ ML エンジニア兼プロダクトマネージャー、 Anant Nawalgaria

Vertex AI に Veo 3.1 Lite と Veo の新しいアップスケーリング機能を導入

Wed, 08 Apr 2026 03:00:00 +0000

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

このたび、Vertex AI に、最も費用対効果の高い動画モデルである Veo 3.1 Lite を導入いたします。

また、この新しいモデルとともに、既存の動画アセットを強化するのに役立つ、Veo のスタンドアロンの新しいアップスケーリング機能も Vertex AI でリリースいたします。

ワークロードに適した Veo モデルの選択

動画生成機能をアプリケーションに統合する際は、特定のユースケースに合わせてモデルを選ぶことが重要です。Veo 3.1 ファミリーのティアは 3 つになり、いずれのティアでもネイティブ音声生成機能が利用可能です。

Veo 3.1: このモデルは、最終的な制作カットで視覚的な忠実度が最優先される最先端の動画生成向けに設計されています。
Veo 3.1 Fast: 高品質を維持しながら動画生成を高速化するオプションで、標準的な制作ワークフローに最適です。
Veo 3.1 Lite: Google の最も費用対効果の高いモデルです。企業は大量の動画アプリケーションを構築し、迅速に反復処理してスケールできます。

料金の内訳については、Vertex AI の料金ページをご覧ください。

完全なガイドについては、Veo 3.1 のプロンプトに関する究極のガイドをご覧ください。

Veo の新しいアップスケーリング機能でアセットをアップスケール

お客様から特に要望の多かった機能は、既存の低解像度動画を高解像度にアップスケールする機能です。限定公開プレビュー版で利用可能で、近日中に公開プレビュー版で利用可能になる Veo の新しいアップスケーリング機能により、Veo、他の AI モデル、従来のカメラのいずれで生成された動画でも、1080p および 4K まで画質を向上させることができます。

次のデモで、Veo がアイデアをどのように形にするかをご覧ください。

Veo 3.1 Lite を今すぐお試しください

このたび、Vertex AI API と Vertex AI Media Studio を通じてこのモデルにアクセスいただけるようになりました。

ベストプラクティスについて詳しくは、以下のリソースをご覧ください。

- Google Cloud、生成メディア担当グループプロダクトマネージャー、Sandeep Gupta

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

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

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

AI により、学生デベロッパーはかつてないレベルで作業を効率化し、難しい問題を解決したり、野心的なプロジェクトに取り組んだりできるようになりました。一方、この新技術の登場によって、技術専攻の学生たちは学習について本質的な問いに向き合うようになってきています。

それは、AI をどの程度、何に使用すべきか、という問題です。

Google の DORA 2025 レポートによると、現在、日々の業務で AI を使用している技術者は 90% に達しています。こうした状況の中で、次世代が AI ツールとどう付き合っているのかを理解することがこれまでになく重要になっています。カリフォルニア大学バークレー校の学生を対象とした Google の調査では、学業における不正行為や知的作業の省略といった懸念を覆す結果が明らかになりました。学生は AI を近道としてではなく、学習パートナーとして捉え、タスクによって意図的に使用したり、使用を控えたりしています。

AI がソフトウェア開発の基盤となるにつれ、AI ツールを導入するかどうかよりも、懸命な活用方法が焦点になってきています。カリフォルニア大学バークレー校の学生たちは、その答えの一つを示してくれます。それは、彼らのもつ好奇心や、慎重さ、学習に対する純粋な意欲を、AI は支えることはできても、取って代わることはできない、ということです。

調査

カリフォルニア大学バークレー校の 4 人の学生チーム（Andrew Harlan、Mindy Tsai、Kenny Ly Hong、Karissa Wong）が、学業での AI の利用状況を把握するため、コンピュータサイエンス、電気工学、デザイン、データサイエンス専攻の学生を対象に調査を実施しました。この調査には、混合手法を使用しています。

また、同校の別のチーム（Edward Fraser、Jessie Deng、Eileen Thai）が、デベロッパー歴 1～5 年の人々を対象に、アイトラッキング技術を使って AI コーディングアシスタントの使用状況を観察しました。両チームとも専任メンターの支援のもと調査を進め、混合手法調査については Google 社員の Harini Sampath、Becky Sohn、Derek DeBellis が、アイトラッキング調査についてはカリフォルニア大学バークレー校の John Chuang 教授（博士）が助言を行っています。

これらの調査から、学生が AI を活用すると同時に、真の専門知識を身につけるためにどのような方法をとっているのか、3 つの重要な結果が明らかになりました。学生の間で見られるパターンは、実際に開発職に就いている人々を対象にした DORA の調査結果とよく似通っています。

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

AI は近道ではなく家庭教師

調査で AI との関係性について尋ねられた学生は皆一様に、学びの場ならではの言葉を使いました。AI のことを、アシスタントや生産性向上ツールではなく、「家庭教師」や「先生」と呼んでいたのです。

「AI は教師のような存在です。内容の濃い資料を解説してもらったり、データベースにあらかじめ記述されているコードを部分的に説明してもらったりするなど、プロジェクトの基礎的な部分について理解を深めるためにとても役立っています。」

「[AI を] お抱えの家庭教師として利用しています。授業や講義の特定のトピックの [理解を深める] ために。コンピュータサイエンスだけでなく、あらゆる授業で使っています。」

ここで重要なのは、学生が AI に依存せず、計画的に使用しているということです。AI に課題を完成させるのではなく、自分の理解度を踏まえて AI を使用し、知識の抜けを特定したり、不確かな概念を明らかにしたり、学習プロセスをリードしてもらったりしています。回答の中には、講義で取り上げられた複数の学術論文を要約してもらい、どれを深く読みこむべきかを判断するといった使い方や、コードでエラーが発生する理由を AI に説明してもらう、といったものがありました。

ある学生は、学習プロセスに次のように組み込んでいます。

「教授の説明がわからなかったときは AI に尋ねます。たとえば、ある概念や、コードの機能について説明してもらったりします。また、ラボのどこから手をつけたらよいかわからないときは、AI にプロンプトで尋ねます。それからコードを書き始め、修正すべき点を尋ねるといった具合です。」

学習障がいのある学生にとっては、常に利用できるという点が、不利な状況を克服するために役立っています。

「私は学習障がいがあるため、問題を理解するのに人より時間がかかります。AI にはすごく助けられています。24 時間 365 日、いつでも付いていてくれるサブ教師のような存在です。」

AI を使えば、学校の営業時間に縛られることなく、いつでも理解を掘り下げられます。AI のおかげで脳の処理能力に余裕が生まれ、より高度な思考が可能となります。

「実際にコーディングする時間は減り、全体のアイデアを練るのに時間をかけられるようになりました。今では、手動でコードを生成する代わりに、ロジックとコンセプトの検討や、アイデアの創出に時間を費やしています。」

こうしたコメントから、AI が最終的な作品を仕上げるためではなく、探索ツールとして利用されている様子が浮かび上がります。これは、DORA の調査結果と一致しています。調査によると、AI がルーチンワークを引き受けることで、デベロッパーはユーザーへの価値提供に専念できるようになっています。

調査結果その 2: 過度な依存に対する積極的な抵抗

学びのプロセスを守るために、境界線を設ける

学生たちは、AI を学習ツールとして活用する一方で、AI への過依存への不安を率直に表現しました。

「AI がなくなったら、自分で解決方法を探すのに苦労してしまうかもしれません。」

エッセイ執筆中の脳活動を脳波検査で測定した最近の研究では、AI の利用者は、検索エンジンやツールを使用しない人に比べ、認知エンゲージメントのパターンが弱いことがわかりました。また、AI のヘビーユーザーが、アシスタントを使わずにエッセイを書いてみたところ、以前に書いた作品についての記憶があまりなく、自分の作品であるという意識も低いことがわかりました。このことを、論文の著者は「認知の負債」と表現しています。1

一方で、ポジティブな兆候が明らかになりました。学生たちは、この認知上のリスクをただ受け入れるのではなく、意図的に境界線を設けて対応しています。

機械工学専攻のある学生は、電子機器を何年も使用するうちに、以下のように能力ベースの AI 使用ルールを確立したといいます。

「サーボや超音波などの基本的センサーなら自分でコーディングできますが、複雑なセンサーで、かつ、機能を厳密に把握する必要性がないときは、AI を使用します」と回答し、次のように説明しています。「何かがうまくいかないとき、その理由を理解できても、問題を解決するための直接的な言語を知らない場合があります。AI は、そのような状況で役立ちます。」

この学生は、最近携わったプロジェクト（触って操作できるストーリーテリングツールの構築）において、基本的なコンセプトを理解した後、カウントおよび比較のシステム構築のために助けを求めたとのことです。「AI は、基本構造のセットアップに大変役立ちましたが、その後、微調整のコーディングは自力でやる必要がありました。」また、作業の振り分けについては、次のように明確な意見を述べています。「自分でも引き続き、コードを書いています。技術者のように丸投げするわけではなく、AI と共同で作業を進め、私が司令塔となって AI にやってほしいことを指示します。ただやみくもにリクエストしても、まったく役に立ちません。」

学生が AI を利用する際には、明確な利用ルールを設けているケースが多く見られました。

「AI にはたまに、完全な答えではなく方向性だけを示すように頼みます。」

過度な依存を避けるため、学生は以下のような具体策を編み出しています。

高度なモデルの利用を避ける:

「料金制の AI ツールを使用するつもりはありません。AI モデルを使いすぎてしまう恐れがありますから。」

AI の使用、不使用を交互に繰り返す:

「for ループの処理など、一部の処理はまた自分で書くようになりました。」

「バイブコーディング」を警戒する:

「AI ツールがデベロッパーの生産性を高めるために役立つことは間違いありません。ただし、バイブコーディングに慣れてしまわないよう、十分な注意が必要です。AI が生成するコードを理解して検証し、適切な方法で使用するということが大前提です。」

こうした懸念は、学生たちが認知について意識的に考えているということを示しています。彼らは、一番楽な方法が最も学習効果が高いわけではないと認識しています。これは DORA の調査結果とも一致しています。調査によると、AI の導入率が 90% にのぼるにもかかわらず、利用者の約 30% が AI が生成したコードをほとんど（あるいはまったく）信用していないと答えています。AI を効果的に使用するには、単に導入するだけでなく、厳しい評価と検証の方法を習得することが求められます。

調査結果その 3: AI の使いどころを心得ている

アイトラッキングデータからわかったこと

アイトラッキング技術を使用した調査では、人の動作の面から検証を行いました。1～5 年の経験を持つデベロッパーを対象に、AI コーディングアシスタントとやり取りする様子を観察したところ、タスクの種類によって AI の利用に大きな違いがあることがわかりました。

思考と深い理解が必要なタスク: AI への視覚的注目が 1% 未満
機械的なタスク（ボイラープレートコードなど）: AI への視覚的注目が 19%

高度な作業においては、たとえ AI の提案が正確で時間の節約につながるような場合でも、敢えて無視されていることがわかりました。深い理解が必要なときは、AI は認知上の負担となります。熟練デベロッパーは、AI をオフにすべきときを心得ています。

すべてを任せるのではなく、意図的に取り入れる

学生への聞き取り調査からも、学生が AI を用途に応じて使い分けている様子が伺えます。

「私は普段、とっかかりとなるアイデアを得るために AI を使っています。」

「AI の使用が許可されていることは知ってましたが、学習と試行錯誤のプロセスを大事にしました。創造性の余地も必要です。」

カスタマイズが肝

現在、ほとんどの AI コーディングアシスタントは、インライン提案のオン / オフを切り替えたり、オンデマンド専用モードに設定したり、提案頻度を調整したりできます。これらの設定を試して、タスクとその認知要件に応じて AI を使い分けることで、ルーチンワークでは助けてもらいつつ、自分で深く考えたい仕事の邪魔をされないようにすることができます。

この調査結果が業界において意味すること

AI を利用した開発の未来を形作っていくのは、今の学生たちです

調査に協力してくれた学生たちは、時代の一歩先をいっており、すでに AI リテラシーを身につけています。用途に応じた使い分けや、出力の検証方法を心得ており、自らの理解力を維持するためにときには敢えて手動で作業するといった対策をとっています。AI 導入を検討中の方にとって、こうした学生の経験は、進むべき方向を探るヒントとなります。

さまざまなカスタマイズ設定を試す: 作業の妨げとならず、助けとなるような設定を見つけましょう。
ワークフローに検証プロセスを取り入れる: AI の提案を無批判に受け入れないようにしましょう。
自分の聖域を確保する: スピードよりも深い理解が重要となる高度な問題には、AI の助けを借りずに自分で取り組むようにしましょう。

業界の専門家が AI の導入をどのように進めているかについて詳しくは、2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状をダウンロードしてご覧ください。カリフォルニア大学バークレー校の研究者との共同研究による論文全文もあわせてお読みいただけます。

^{1. Kosmyna, Nataliya, et al. "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task." arXiv, 10 June 2025, doi:10.48550/arXiv.2506.08872.（参照日付: 2026 年 1 月 28 日）}

- Andrew Harlan 博士（独立系 UX リサーチャー兼クリエイティブテクノロジスト）

- Steve Fadden 博士（Google、UX リサーチ担当リード）

初級者コースのように簡単: Vail Resorts がパーソナライズされたおすすめを自動化する AI アシスタントを構築した方法

Mon, 06 Apr 2026 02:20:00 +0000

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

スキーヤーやスノーボーダーは、新雪を追い求めたり、新しいトリックをマスターしたり、新しい地形を探索したりと、ゲレンデでのあらゆる瞬間を精一杯楽しむものです。よく知っているお気に入りのゲレンデを訪れる場合でも、初めてのゲレンデを訪れる場合でも、必要な情報をすぐに手に入れて、自信を持って移動し、隠れた名所を見つけ、到着した瞬間からその場所に溶け込みたいと考えています。

そのような理由から、Vail Resorts は 2024～2025 年の雪シーズンに My Epic Assistant をリリースしました。Vail は、世界で最も象徴的で愛されている山岳リゾート（ウィスラーブラッコム、パークシティマウンテン、ストウ、クレステッドビュートなど）を運営しています。同社は、すべての利用者が新しいアプリで十分なサポートを受けられる、つまり、ゲレンデ体験に没頭したまま、迅速かつ有益な回答を得て、ゲレンデにあるすべてのものを発見できるようにしたいと考えていました。

情報ブースを探すのと、次の滑走に向けてリフトに乗っている間にアプリで情報を得るのと、どちらがよいか、考えれば答えは明白です。

My Epic Assistant は、Vail Resorts の IT チーム、接客チーム、運営チームのノウハウを Google の強力な Gemini モデルにフィードする AI 搭載アシスタントです。結果として、ゲレンデで適切なシーズンパスを選択するサポート、最新の雪の状況の共有、レッスンの準備状況の確認、ココアを飲むのに最適な場所の提案などを、このエージェントで行えるようになりました。Vail Resorts は、単なる chatbot ではなく、ウィスラーでパウダースノーを楽しめる日と、ビーバークリークへの家族旅行に適した日の微妙な違いを理解できるデジタルコンシェルジュを求めていました。

これらのサービスを次のレベルに引き上げるため、Vail Resorts のチームと Google Cloud スペシャリスト 66degrees は、2025～2026 年シーズン向けに My Epic Assistant を更新し、シーズンパスのおすすめや強化されたパーソナライズなどの新機能を追加しました。この機能により、ゲストの質問を理解し、複雑なリクエストに対応して、ゲストに最適なパスをインテリジェントに案内できるようになりました。

この投稿では、ゲレンデを楽しむために迅速なサポートを求めている、目の肥えた利用者からの、微妙な違いのある複雑な質問に効果的に回答できるマルチエージェントシステムをオーケストレートするという難題に、Google がどのように取り組んだのかをご紹介します。このような AI 搭載ツールを活用できるのは、ゲレンデに詳しい利用者だけではありません。

このような AI 搭載ツールを活用できるのは、ゲレンデに詳しい利用者だけではありません。

このブログ投稿では、接客業のこの過酷な分野特有の課題に巧みに対処できるマルチエージェントシステムをオーケストレートして、My Epic Assistant を構築した方法について詳しく説明します。これは、顧客中心の他の分野の組織が、それぞれの状況に合わせてエージェントシステムを構築するうえでも役立つアプローチです。

新しいシーズン、より良い結果

My Epic Assistant 内のパーソナライズ、検索、要約の各機能、会話フローを実装して改良した結果、アプリの初回リリース以降、人間のエージェントへのエスカレーションが 45% 減少しました。

テクノロジーは人と人の触れ合いに取って代わるのではなく、それを強化するものです。日常的なロジスティクスを自動化し、パーソナライズを拡大することで、Vail Resorts のゲストエクスペリエンステクノロジーチームは、そのことを確実にすることができました。全体的に、サポートを求める利用者は、より迅速かつ確実に、より多くの方法とタイミングでサポートを利用できるようになりました。

「Google Cloud のツールを利用することで、エージェント設計パターンを活用して、自然でパーソナライズされた会話を実現できました。これにより、顧客満足度が向上し、手動でのインテント設計の必要性が低減しました。また、これらのツールにより、柔軟性と制御性を組み合わせて、アシスタントがブランド、ポリシー、プロダクト戦略の範囲内で常に流動的に対応できるようになりました」とチームは述べています。

My Epic Assistant の構築手順

まず、My Epic Assistant はサブトピック分類エージェントを使用して、パスの比較、おすすめの提案、一般的な情報の検索など、利用者の最初のリクエストを理解します。パスは期間限定でのみ購入できるため、日付オブジェクトを使用して時期を判断します。パスが販売終了している場合は、自動的にリフト券の情報にルーティングされます。パスとリフト券の両方が購入可能な場合、アシスタントはいくつかの確認の質問をして、旅行に最適な価値を提供するオプションを顧客が決定できるようにします。次に、アシスタントは、おすすめを提示するために必要な追加データを判断するために、データ収集エージェントに引き継ぎます。認証済みのユーザーの場合、Vail Resorts は、よく訪問するリゾート、平均訪問回数、年齢、今後訪問予定のリゾート、ピーク日の好みなどの既存のデータを、Webhook から呼び出して提供します。認証されていない新規のユーザーの場合、ギャップを埋めるために、確認のための回答しやすい質問をします。一方通行の静的なフォーム入力ではありません。

このステップでは、生成 AI の会話機能が真価を発揮します。My Epic Assistant は、自由に会話できるように設計されているため、利用者はいつでも確認のための質問をして、コンテキストを失うことなくレコメンデーションプロセスに戻ることができます。ハンドブックの手順に沿って、モデルは出力に必要なすべてのパラメータが入力されているかどうかを継続的に評価し、次のステップに進みます。このプロセス中も、利用者は他の質問をすることができます。

たとえば、ピーク日の利用を希望するかどうかを尋ねられた利用者が、「制限の対象となる今年のピーク日はいつですか？」と続けて質問する可能性があります。My Epic Assistant は、Vail Resorts の広範な知識を体系化したウェブサイトのデータストアを呼び出して対応します。その後、My Epic Assistant は回答を提供し、コンテキストを失うことなく会話の前のターンに戻ります。

最後に、レコメンデーションエージェントが引き継ぎます。収集したユーザーデータを使用して、すべてのパスオプションの構造化データベースに対してクエリを実行し、完全一致を見つけます。その後、システムは、特定されたパスが適している理由を説明するユーザーフレンドリーな回答を生成し、直接購入リンクを含むコンテンツカードを提供して、利用者の最終ステップを簡素化します。

パスレコメンデーションエージェントのコア機能は、既存のすべてのパス、その特長、制限事項の構造化ファイルを含むパスマトリックスのデータストアツールです。利用可能なオプションが多数あるため、ツールがすべての入力パラメータを受け取ったときに有効で適切なオプションを返すことを確認するには、広範なテストが必要でした。66degrees は、この分野に関する Vail Resorts の深い知識を活用して、あらゆる結果を検証しました。

プロンプトエンジニアリングにより、最終的な回答では、特定のパスが利用者に最適なオプションである理由を詳細に説明したおすすめが提示されます。また、おすすめの購入リンクを含むコンテンツカードも呼び出されます。ハンドブックを終了する必要はありません。新しくリリースされた Epic Friends 機能に関する詳細情報が表示されるなど、生成された回答が適切でない場合もありました。静的な回答は、コードスニペットと条件付きアクションを介して呼び出されます。これらもハンドブック自体に格納されるため、全体的なアーキテクチャが簡素化されます。

パーソナライズが初級者コースのように簡単に

My Epic Assistant のスマートテクノロジーとユーザー重視のデザインの新しい組み合わせにより、Vail Resorts は、単なる顧客の質問とその回答という枠を超えて、多くの顧客のリクエストに対して真に会話型でありながら完全に自動化されたエクスペリエンスを提供できるようになりました。重要なのは、Vail Resorts のような運営企業にリゾート利用者が期待するコンシェルジュサービスを、AI とクラウドテクノロジーなしでは実現できない規模で提供していることです。

Vail Resorts は、My Epic Assistant のパスのおすすめ機能により、すべての利用者がこれまでで最高のシーズンを過ごすためのカスタムのおすすめ情報を受け取れるように準備を進めています。

上級者コースのように技術的に難しい課題を、初級者コースのように簡単に扱えるソリューションで解決することをご希望の場合は、66degrees と Google Cloud のエキスパートにお問い合わせのうえ、最新の AI とクラウドテクノロジーで何ができるかをご確認ください。

- 66degrees、会話アーキテクト、Olivia Marrese

- Google、カスタマーエンジニア、Jacob Walcik

AI インフラストラクチャとしての Kubernetes: Google Cloud、llm-d、CNCF

Fri, 03 Apr 2026 01:00:00 +0000

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

Google Cloud は、大規模な基盤モデルのビルダーや AI ネイティブ企業の膨大なニーズに応えることを、当社の AI インフラストラクチャ戦略の最優先事項としています。生成 AI の利用がミッションクリティカルな本番環境へと移行する中、このようなイノベーターは、複雑なオーケストレーションの課題を克服し、エージェント主導の未来を推進できる、動的かつ絶え間なく効率的なインフラストラクチャを必要としています。

こうした状況を鑑み、このたび、llm-d が Cloud Native Computing Foundation（CNCF）のサンドボックスプロジェクトとして正式に承認されたことを大変嬉しく思います。Google Cloud は、Red Hat、IBM Research、CoreWeave、NVIDIA とともに、llm-d の創設メンバーとして貢献できることを誇りに思います。私たちは、業界を定義する明確なビジョン「あらゆるモデル、あらゆるアクセラレータ、あらゆるクラウド」の下に団結しています。

この貢献は、オープンソースのイノベーションにおける Google の長年のリーダーシップを裏付けるものです。私たちはまた、Linux Foundation の信頼できる管理の下、分散 AI 推論の未来が、閉ざされた環境ではなくオープンスタンダードに基づいて構築されるよう支援しています。これにより、基盤モデルのビルダーは、ベンダーに縛られることなくモデルをグローバルにデプロイできるという確信を得られるとともに、これらのオープンテクノロジーの実装を高度に最適化したうえで Google Cloud で直接行えるようになります。

推論のための Kubernetes の強化

Kubernetes は、オーケストレーションの業界標準として揺るぎない地位を確立しています。強固な基盤を提供しますが、元々は、LLM 推論のために構築されたものではなく、高度にステートフルで動的な要求には対応できませんでした。GKE Inference Gateway は、こうした新しいタイプのワークロードに対応するために Kubernetes を進化させたもので、単純なロードバランシングをはるかに超えるネイティブ API を提供します。このゲートウェイの内部では、スケジューリングインテリジェンスのために llm-d Endpoint Picker（EPP）を活用しています。このシステムでは、ルーティングの決定を llm-d に委任することで、リアルタイムの KV キャッシュヒット率、処理中のリクエスト数、インスタンスキューの深さを考慮した多目的ポリシーを適用し、各リクエストを処理に最適なバックエンドにルーティングします。

大規模に運用する基盤モデルのビルダーにとって、こうしたモデル対応のルーティングがもたらす現実世界への影響は画期的です。最近、Google の Vertex AI チームは本番環境でこのアーキテクチャを検証し、脆弱なカスタムスケジューラに依存することなく、予測が非常に難しいトラフィックを処理できることを証明しました。Qwen Coder を使用したコンテキストを多用するコーディングタスクでは、最初のトークンまでの時間（TTFT）のレイテンシが 35% 以上短縮されました。また、研究目的に DeepSeek を使用してバースト性が高く確率的なチャットワークロードを処理した場合には、P95 テールレイテンシが 52% 改善され、深刻な負荷変動を効果的に吸収できました。特に重要なのは、このゲートウェイのルーティングインテリジェンスにより、Vertex AI の接頭辞キャッシュヒット率が 35% から 70% に倍増したことであり、これにより、再計算のオーバーヘッドとトークンあたりの費用が大幅に削減されました。

インテリジェントなルーティングに加えて、マルチノード AI デプロイをオーケストレートするには、堅牢な基盤となるプリミティブが必要です。そのため、Google では Kubernetes LeaderWorkerSet（LWS）API の開発を主導しています。LWS により、llm-d は広範なエキスパート並列処理をオーケストレートし、計算負荷の高いプリフィルフェーズとメモリ負荷の高いデコードフェーズを、個別にスケーリング可能な Pod に分離できます。業界で広く採用されている LWS は、今では、急速に拡大する本番環境の AI ワークロードのフットプリントをオーケストレートし、グローバル規模で TPU と GPU の大規模なフリートを管理しています。このオーケストレーションを補完するものとして、Google は最近、Cloud TPU 向けに vLLM をネイティブに拡張しました。PyTorch と JAX の統合バックエンドに加え、Ragged Paged Attention v3 などの革新的な機能を備えたこのインテグレーションにより、昨年初めにリリースした最初のバージョンと比較して、スループットが最大 5 倍向上しました。Google Cloud TPU や NVIDIA GPU のどちらでスケールする場合でも、これらの進歩により、最先端の AI サービングが高度に最適化され、アクセラレータに依存しない機能として維持されます。

次世代の AI インフラストラクチャを共同で構築

究極の AI インフラストラクチャを構築するには、クラウドネイティブな Kubernetes オーケストレーションと最先端の AI 研究との間のギャップを埋める必要があります。本番環境レベルの生成 AI への移行には、信頼性と透明性を備えたエンジンが必要であり、可能性の限界を押し広げる AI / ML リーダーとの緊密なコラボレーションも求められます。

私たちは、Linux Foundation、CNCF、PyTorch Foundation、その他のオープンソースコミュニティとともに、次世代の AI インフラストラクチャを構築できることを大変嬉しく思っています。「well-lit paths」（現実的な負荷の下でエンドツーエンドにテストされた、実証済みで再現可能なブループリント）を確立することで、高性能な AI がオープンで誰もがアクセスできるエコシステムとして発展し、境界のないイノベーションを促進できるようにしています。

AI 推論のオープンな未来を一緒に形作りましょう。大規模基盤モデルのビルダー、AI ネイティブ企業、プラットフォームエンジニア、AI 研究者の皆様の参加を心よりお待ちしております。

「well-lit paths」を確認する: llm-d ガイドを参照し、ご自身のインフラストラクチャに SOTA 推論スタックを今すぐデプロイしましょう。
詳細: 公式ウェブサイト（https://llm-d.ai/）をご覧ください。
ご協力のお願い: Slack のコミュニティに参加し、GitHub リポジトリ（https://github.com/llm-d/）での活動にご協力ください。

llm-d の CNCF サンドボックスプロジェクトへの参加をお待ちしております。皆様とともにこのエンジンを発展させていくことを楽しみにしています。

- プロダクトマネージャー、Sean Horgan

- シニアクラウドデベロッパーアドボケイト、Abdel Sghiouar

DRA: 動的リソース割り当てが切り開く Kubernetes デバイス管理の新時代

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

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

大規模言語モデル（LLM）の爆発的な普及により、GPU や TPU などの高性能アクセラレータの需要が高まっています。組織が AI 機能を拡大させる中で、コンピューティングリソースの不足が主要なボトルネックとして浮上することがあります。すべての GPU と TPU のサイクルを効率的に管理することは、もはや推奨事項ではなく、運用上の必要事項となっています。

Kubernetes は、企業が LLM を実行する際の事実上の標準プラットフォームになりつつあります。今週開催された KubeCon Europe において、NVIDIA は GPU 用の動的リソース割り当て（DRA）ドライバを、Google は Tensor Processing Unit（TPU）用の DRA ドライバをそれぞれ Kubernetes コミュニティに寄贈しました。このことは、より広範なコミュニティの育成とイノベーションの加速を実現し、Kubernetes が最新のクラウド環境に対応して AI ワークロードのポータビリティを向上させることにつながります。DRA は Google Kubernetes Engine（GKE）でも一般提供されています。このブログ記事の残りの部分では DRA について掘り下げ、DRA が構築された理由、DRA でできること、DRA の使用方法について説明します。

静的なインフラストラクチャからの脱却

長年にわたり、ハードウェアアクセラレータを使用するには、Kubernetes のデバイスプラグインフレームワークを利用するのが標準的な方法でした。ただし、デバイスプラグインでは、ハードウェア要件を単純な整数（例: gpu: 1）としてしか表現できないため、フラクショナル GPU は使用できません。これでは、現代の複雑なワークロードに求められる微妙できめ細かな調整を行うには不十分です。また、デバイスプラグインでは、Pod のスケジューリングに先立って、クラスタにアクセラレータを事前プロビジョニングさせておく必要があります。

Kubernetes におけるリソース管理の新標準である DRA は Kubernetes OSS 1.34 で「安定版」のステータスに昇格しました。DRA は、ハードウェアの処理方法において、静的な割り当てから柔軟なリクエストベースのモデルへの移行というパラダイムシフトを体現しています。これにより、次のような課題が解決されます。

手動によるノードの固定が不要: デバイスプラグインフレームワークでは、アプリオペレーターは、特定のハードウェアを搭載したノードを自分で調べてから、nodeSelector またはアフィニティを使用して、Pod がそのノードに配置されるようにする必要がありました。DRA は、スケジューラが特定のハードウェア機能をネイティブに認識できるようにすることで、このプロセスを自動化します。リクエストに基づいてワークロードに適したノードを検出するため、ユーザーがクラスタのトポロジをマッピングする必要はありません。
柔軟なパラメータ化: デバイスプラグインの「全か無か」のアプローチとは異なり、DRA では、ResourceClaim を使用して、最小 VRAM 量、特定のハードウェアモデル、相互接続要件などの特定の要件を定義できます。これにより、高価なハードウェアをよりきめ細かく効率的に使用できます。
DeviceClass を介したハードウェアの抽象化: DRA は、ハードウェアの「ブループリント」として機能する DeviceClass を導入します。プラットフォーム管理者は、デベロッパーが名前でリクエストするクラス（例: high-memory-gpu や low-latency-fpga）を定義できます。これにより、基盤となるハードウェアアドレスからワークロードのニーズが切り離されます。これは、スケジューラがワークロードの要件と利用可能なハードウェアインベントリのマッチングを行うことを可能にします。

詳細解説: DRA の仕組み

DRA の中核をなすのは ResourceSlice と ResourceClaim です。これら 2 つの主要な構成要素は、ハードウェアインベントリとワークロード要件を分離します。これらは、Kube-scheduler が適切な意思決定を行い、より柔軟なリソースプールを実現するために使用する入力です。

ResourceSlice: 可用性の記述

ResourceSlice API は、基盤となるハードウェアの機能と属性をリソースドライバがクラスタに公開するために使用されます。デバイスプラグインが単純なラベルを使用することでデバイスの詳細を覆い隠しがちであるのと対照的に、ResourceSlice は利用可能なアセットを忠実に記述します。これにより、ドライバは各デバイスに関する以下のような詳細情報を報告できます。

容量: 合計メモリ、コア数、または特殊なコンピューティング単位数
属性: アーキテクチャ、バージョン、PCIe ルートコンプレックスまたは NUMA ノード

ResourceClaim: 要件の定義

ResourceClaim API を使用すると、AI エンジニアはアプリケーションを正常に実行するために必要なものを正確に定義できます。ResourceSlice API がデバイスの詳細を公開するため、開発者は一般的なリクエストにとどまらず、次の項目に基づく要件の指定を行うことができます。

属性ベースの選択: 特定のモデルを指定する代わりに、ユーザーは「40 GB 以上の VRAM を備えた GPU」という風にリクエストできます。
複雑な制約: DRA はデバイス間の制約をサポートします。たとえば、ハイパフォーマンスコンピューティングジョブでは、レイテンシを最小限に抑え、スループットを最大化するために、GPU と NIC の両方が同じ PCIe ルートコンプレックスに接続されているという要件のもとに、GPU と NIC をリクエストできます。

能力ベースのアプローチによるスマートなスケジュール設定

DRA は、「何」（ResourceClaim）を「どこ」（ResourceSlice）から切り離すことで、デバイスのマッチングの負担をユーザーから Kube-scheduler に移します。

以前までは、ユーザーは適切なハードウェアに Pod を配置するために、手動のノードセレクタや taint に頼らざるを得ないことがほとんどでした。DRA を使用すると、スケジューラはデバイスの属性とクラスタのトポロジを全体的な視点から把握できるようになります。これにより、より「流動的な」リソースプールが可能になります。スケジューラは、利用可能なすべてのスライスをクレームの特定の基準に基づいて評価し、静的なラベルではなく実際のハードウェアの可用性に基づいて配置を最適化できます。

この能力ベースのアプローチによって利用可能なハードウェアのうち最適なものにワークロードを確実に割り当てられるようになり、リソース使用率とアプリケーションパフォーマンスの両方が向上します。

DRA の動作を確認するには、Google デベロッパーフォーラムのこちらのブログ記事をご覧ください。このブログ記事では、環境設定、GKE クラスタの作成、ドライバのインストール、レプリカのスケーリングなど、カスタム ComputeClass を使用して GPU をスケールする方法を紹介しています。

1.35 のリリースでは、AI / ML ワークロードと最新のユースケースの新しい標準を確立するために、Kubernetes AI Conformance プログラムが作成されました。DRA のサポートは、この新しい基準の要となるため、最初の必須要件として特定されました。

ぜひお試しください

Kubernetes ワークロードがより複雑でミッションクリティカルになるにつれて、柔軟でインテリジェントかつ使いやすいリソース管理の実現が重要になっています。GKE の DRA は、要求の厳しい動的な環境でハードウェアリソースを最適化する際に手作業や当て推量に頼る必要性を排除します。DRA の詳細と利用方法については、以下のリソースをご覧ください。

- シニアソフトウェアエンジニア、Morten Torkildsen

- シニアプロダクトマネージャー、Bo Fu

「生成 AI」から「エージェント型 AI」へ — 自律する AI が変える企業経営

Tue, 31 Mar 2026 02:00:00 +0000

エージェント型 AI（Agentic AI）に投資した企業は、平均 3.5 倍の ROI を達成し、プロジェクト成功率は 81% に達しています。 成功の鍵は、AI スキルへの人材投資、高品質なデータ基盤、そしてフルスタックプラットフォームの選択にありました。

今、企業がとるべきアプローチは明確です。エージェント型 AI を軸に据え、データ基盤を整備し、人材のスキルを高め、信頼できるプラットフォームと組む。本記事では、IDC による最新調査「Asia Pacific Generative AI Adoption Study 2025」のデータから、そのポイントを解説します。

詳細なホワイトペーパーはこちらからダウンロードしてください。

単なるコンテンツ生成から自律的な意思決定へ — エージェント型 AI の台頭

AI は今、自ら分析し、推論し、行動するエージェント型 AI へと進化しています。 人間の指示を待つのではなく、複数のツールを連携させてワークフローを自律的に実行し、複雑なビジネス目標を人手を介さずに成果へと変えていく。これがエージェント型 AI の最大の強みです。

すでに現場での活用も広がっています。製造業では、予測型 AI と生成 AI を組み合わせ、ラインの速度を調整したり、不足した部品をリアルタイムで自動発注したりして、ダウンタイムなしでの稼働を実現。小売業でも、店舗と配送センターの間で欠品の自動補充や、1 時間ごとの動的な価格調整が自律的に動き始めました。

期待される 3 倍の ROI と「先行組」の成功の秘訣

企業の 66% が、生成 AI への投資で 3 倍の ROI を期待しています。 そして実際に、先行組と呼ばれる企業群は平均 3.5 倍の ROI を達成し、AI プロジェクトの成功率も 81% に達しました。

この成功の裏には、AI ツール単体への依存ではなく、部門横断的な協力体制の構築や、社内のメンター制度の促進など、人とエージェントが協力するためのスキルアッププログラムへの積極的な投資がありました。熟練したチームの存在こそが、AI 主導の変革を成功に導く鍵になっています。

成功の鍵を握るデータ基盤とフルスタックプラットフォーム

エージェント型 AI のスケールを左右するのは、データ基盤とプラットフォームの質です。 すべての業界で最大の障壁となっているのが不十分なデータアクセスと低いデータ品質であり、一部の業界では最大 51% の組織がこの課題に直面しています。高品質なデータがなければ、AI エージェントは正確に機能しません。

こうした現実を受けて、企業は AI 予算のかなりの部分を、データエンジニアリングや AI インフラストラクチャ、セキュリティといった基盤に戦略的に振り向け始めました。

プラットフォームの選択も同様に欠かせないポイントです。モデル、ツール、インフラストラクチャ、ガバナンスをひとつのプラットフォームで提供し、既存の企業システムとシームレスに統合できるフルスタック AI ソリューションベンダーを、戦略的パートナーとして重視する傾向が強まっています。

実務的なアプローチで進化する日本市場の未来

日本では今後 12 か月以内に 42% の組織がエージェント型 AI の導入を計画しています。 生成 AI の導入率はすでに 65% とアジア太平洋地域で 3 番目に高く、保守的でありながらも実用性を重視する日本独自の姿勢がこの数字に表れています。

注目すべきは、モデルやプラットフォーム基盤よりも、ビジネスアプリケーションへの適用を強く優先している点でしょう。生産性の向上で 67%、カスタマーサポートで 66% と、エージェント型 AI への期待が高い領域がはっきりしており、従業員の負荷軽減や顧客エクスペリエンスの向上といった具体的なビジネス課題に焦点を当てた取り組みが進んでいます。

日本企業の今後 12 か月の AI 投資先を見ると、ビジネスアプリケーション（45%）を筆頭に、セキュリティが 41%、データエンジニアリングが 39%、インフラストラクチャが 36% と、基盤領域への投資も着実に伸びています。ビジネスアプリケーションで成果を実感した企業が、次のステップとしてデータ基盤やプラットフォームの整備へと投資を広げていく流れは、今後さらに加速していくでしょう。

これからの企業成長において、AI は単なる IT プロジェクトではなく、企業の中核的なケイパビリティになっていきます。安全なデータ基盤を構築し、従業員のスキルを高め、信頼できるプラットフォームと連携する。その先に、エージェント型 AI がもたらす自律的な未来が広がっています。

Ironwood TPU を使用したトレーニングに関するデベロッパーガイド

Mon, 30 Mar 2026 02:10:00 +0000

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

数兆単位のパラメータを扱う AI モデルへの移行により、演算リソースの需要が急激に高まり、従来のインフラストラクチャの限界が試されています。第 7 世代の Ironwood TPU は、Google がカスタム設計した AI インフラストラクチャです。チップ間相互接続（ICI）、光回路スイッチ（OCS）、データセンターネットワーク（DCN）、および大規模な集約型高帯域幅メモリ（HBM）容量を組み合わせることで、最大 9,216 個のチップを格納できる Pod に対応する包括的なシステムとしてスケールできるように設計されています。さらに、Ironwood はハードウェアアーキテクチャとソフトウェアの統合された共同設計を特徴としており、コンパイラ中心の XLA、および Pallas や Mosaic などの Python ネイティブカーネルといったイノベーションが導入されています。組織はこれらの機能を組み合わせることで、高度なフロンティアモデルをトレーニングおよび提供する能力を大幅に高め、AI ライフサイクル全体を最適化し、高いパフォーマンスを維持できます。

この技術概要では、Ironwood ハードウェア上でのトレーニング効率の向上と、卓越したパフォーマンスの実現を目指して設計された、JAX および MaxText エコシステムにおける具体的な手法とツールについて説明します。

Ironwood の主な最適化戦略

1. MaxText によるネイティブ FP8 の活用

Ironwood は、行列乗算ユニット（MXU）で 8 ビット浮動小数点（FP8）をネイティブにサポートする最初の TPU 世代です。重み、アクティベーション、勾配に FP8 精度を利用することで、ユーザーは理論上、スループットを Brain Floating Point 16（BF16）の 2 倍に高められます。FP8 レシピを正しく構成すると、モデルの品質を損なうことなく効率を向上させることができます。

これらの FP8 トレーニングレシピを実装するには、Qwix ライブラリから始めます。この機能は、MaxText 構成内で関連するフラグを指定すると有効になります。,

詳しくは、Google デベロッパーフォーラムのブログ投稿 Ironwood での FP8 トレーニングの最適化についてをご覧ください。

2. Tokamax カーネルによる加速

Tokamax は、TPU 向けに最適化された高パフォーマンスの JAX カーネルのライブラリです。これらのカーネルは、次のメカニズムを通じて特定のボトルネックを軽減するように設計されています。

Splash Attention: このメカニズムは、標準的なアテンションプロセスに内在する I/O の制限に対処します。オンチップ SRAM 内で計算を維持することで、メモリ帯域幅が制約になることが多い長いコンテキストの処理に特に効果を発揮します。
Megablox グループ化行列乗算（GMM）: これは、混合エキスパート（MoE）モデルでよく見られる「不規則な」なテンソルを管理します。GMM を利用すると、システムは非効率的なパディングを回避し、MXU の使用率を高められます。
カーネルチューニング: Tokamax ライブラリには、ハイパーパラメータを最適化するためのユーティリティが含まれています。これらのツールを使用すると、Ironwood TPU の特定のメモリ階層に合わせて、タイルサイズやその他の構成を調整できます。

3. SparseCore への集団のオフロード

Ironwood の第 4 世代 SparseCore は、不規則なメモリアクセスパターンを管理するために特別に設計されたプロセッサです。ユーザーは、特定の XLA フラグを使用して、All-Gather や Reduce-Scatter などの集団通信演算を SparseCore に直接オフロードできます。

このオフロードメカニズムにより、TensorCore を主要なモデル計算に専念させながら、通信タスクを並行して実行できます。このような機能の重複は、通信のレイテンシを隠し、MXU へのデータスループットを一定に保つための重要な戦略です。

4. VMEM 上でのメモリパイプラインのファインチューニング

TPU メモリアーキテクチャの重要な部分である VMEM は、カーネルのパフォーマンスを最適化するように設計された高速なオンチップ SRAM です。現在の演算と将来の重みのプリフェッチの間で VMEM の割り当てを調整することで、実行速度を全体的に向上させることができます。たとえば、現在のスコープ用に予約されている VMEM を増やすと、カーネルで使用されるタイルサイズを大きくすることができます。これにより、潜在的なメモリストールが解消され、カーネルのパフォーマンスが向上します。

TPU メモリアーキテクチャの詳細については、TPU パイプラインをご覧ください。

5. 最適なシャーディング戦略の選択

最後に、MaxText は、すべての TPU で利用できるさまざまな並列処理手法をサポートしています。最適な選択は、モデルサイズ、アーキテクチャ（Dense や MoE）、シーケンス長によって異なります。適切なシャーディング戦略を選択すると、モデルのパフォーマンスを高められます。

完全にシャーディングされたデータ並列処理（FSDP）: これは、単一チップのメモリ容量を超える大規模モデルをトレーニングする場合に推奨される戦略です。FSDP は、モデルの重み、勾配、オプティマイザの状態を複数のチップにシャーディングします。デバイスごとのバッチサイズを増やし、より多くの演算を導入することで、All-Gather 演算のレイテンシを隠し、効率を向上させることができます。
テンソル並列処理（TP）: 個々のテンソルをシャーディングします。Ironwood は演算密度が高いため、モデルの次元が極めて大きい場合に TP が最大の効果を発揮します。TP を 2 分割して活用すると、Ironwood のデュアルチップレット設計における高速なダイ間相互接続を利用できます。
エキスパート並列処理（EP）: MoE モデルでエキスパートをデバイス間で分散するのに役立ちます。
コンテキスト並列処理（CP）: 非常に長いシーケンスに必要で、シーケンスの次元に沿ってアクティベーションをシャーディングします。
ハイブリッドアプローチ: 大規模な実行で演算、メモリ、通信のバランスを取るには、戦略の組み合わせが必要になる場合が多いです。

上述の 2～5 の手法について詳しくは、デベロッパーフォーラムの投稿 Optimizing Frontier Model Training on TPU v7x Ironwood（TPU v7x Ironwood でのフロンティアモデルトレーニングの最適化）をご覧ください。

Ironwood のメリット: システムレベルのパフォーマンス

これらの最適化手法と、高速の 3D トーラスチップ間相互接続（ICI）や大容量 HBM などの Ironwood のアーキテクチャ上の強みを組み合わせることで、フロンティアモデルのトレーニング向け高性能プラットフォームが実現します。ハードウェア、コンパイラ（XLA）、フレームワーク（JAX、MaxText）間の緊密な共同設計により、AI インフラストラクチャから最大限のパフォーマンスを引き出すことができます。

AI の取り組みを加速させる準備は整いましたか？以下のリソースで、各最適化手法について詳しく確認できます。

関連情報

このブログ投稿に協力してくれた Hina Jajoo と Amanda Liang に感謝します。

- プロダクト戦略およびオペレーション担当、Lillian Yu

- Google TPU 担当プロダクトマネージャー、Liat Berry

JA 共済連: 年間数百件におよぶ問い合わせの回答支援 AI エージェントを Gemini Enterprise を用いてスピーディに構築

Mon, 30 Mar 2026 02:00:00 +0000

将来的な人員減を見据え、全国共済農業協同組合連合会（以下、JA共済連）は、富士通株式会社（以下、富士通）とのパートナーシップのもと、Google Cloud の AI エージェントプラットフォーム Gemini Enterprise を活用した業務効率化プロジェクトを始動させました。その第一歩となったのが、各県域における地域貢献活動にかかる積立金の支出可否判断の支援です。ここでは取り組みの詳細をプロジェクトで中心的な役割を担った 4 名のキーパーソンに伺います。

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

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

AI エージェント活用で「2040 年問題」に備える

多くの企業・組織で人手不足が叫ばれる昨今。政府試算によると、日本の労働人口は 2040 年までに現労働人口の約 2 割、最大 1,200 万人ほど減少すると言われています。この問題はJA 共済連にとっても無縁ではありません。同会は「相互扶助」の理念を掲げ、全国の JA（農業協同組合）と連携・協調しながら「ひと・いえ・くるま」の総合保障の提供のほか、豊かで安心して暮らすことのできる地域社会づくりに貢献しています。この質の高いサービスを維持するためにも、「2040 年問題」にいかに備えるかが喫緊の課題となっています。そこで着目されたのが生成 AI の技術です。JA共済連農業・地域活動支援部地域貢献企画管理グループ主幹の市川豪氏は、次のように説明します。

「将来的に予想される職員の減少に対応するためには、業務を効率化していくことも有効な手段となります。最近、社会的に大きな注目を集めている生成 AI 技術を活用することで、現状をかなり改善できるのではないかという期待があり、具体的な活用方法を探ってみることになりました。」

JA共済連は、同会のシステム開発・運用パートナーである富士通に AI を用いた業務効率化を相談。いくつかのユースケースを検討した結果、対応のスピードアップと負荷軽減が求められていた地域貢献活動にかかる基金の支出判断に、AI エージェント技術を活用するプランを採用します。

「地域貢献活動とは、健康増進や防災、交通事故対策、農機具の寄贈など、JA・JA共済連が、組合員や地域住民の方々のために行う活動です。実施に当たっては、ガイドラインに基づいて支出可否を判断します。ただし、地域貢献活動は一般的な共済事業と異なり、明確な約款が定められているわけではありません。実際には、過去事例などと照らし合わせながら個別かつ総合的に検討する必要があり、どうしても判断に時間がかかってしまいます。公益性の高い非常に重要な活動を充実させるうえでも、判断の迅速化が求められていました。」（市川氏）

市川氏とともに同業務を担当してきた地域貢献企画管理グループ主査、町田瑞季氏は、AI導入によって期待される効果を、業務負荷の軽減という観点から説明します。

「最大の問題はガイドラインの解釈が担当者によって異なり、判断基準に差が生じるリスクがあったことです。これまでは、そうした問題を未然に防ぐため、部署内で全国からの問い合わせに関する認識をすり合わせたうえで、回答を行っていました。しかし、文書による照会だけで年間 200～300 件、さらに毎日数件、電話による問い合わせがあり、認識のすり合わせだけでも負担になっていました。この部分に AI エージェントをうまく活用できれば、私たち本部の作業だけでなく、地域貢献活動を実施する JA と直接やりとりをしている全国各地の担当者の作業負荷も大きく軽減されるのではないかという期待がありました。」

Gemini Enterprise だから実現できた短期間での課題解決

この課題解決にあたり、富士通の営業部門担当者として、JA共済連の業務効率化を担当してきた岡田晋太朗氏は、さまざまなソリューションの中から、Gemini Enterprise の採用を決定しました。

「AI エージェント導入に際しては、『短期間で成果を出したい』『アジャイル的に対話しながら AI を育てたい』というリクエストがありましたので、ノーコード・ローコードで構築できる Gemini Enterprise を選択しました。他の選択肢も検討しましたが、チューニング力や短期間での成果創出の確実性を考えると、今回は Gemini Enterprise が最適解という結論に達しました。」

2025 年 7 月に開発に着手。その後はスピード感をもって進められ、業務フローのヒアリング後、わずか 1〜2 週間でプロトタイプが完成。富士通のエンジニアとして AI エージェント開発に携わった宇野健介氏は、Gemini Enterprise を用いた AI エージェント作成について、こう語ります。

「今回は Gemini Enterprise の ADK（Agent Development Kit）を用いてAI エージェントを開発しました。Gemini Enterprise には、Gemini Pro をはじめとする高性能なモデル、SDK、UI、ローコードツールなどが一通り揃っているうえ、それらを連携させるのも容易で、スムーズに開発を進めることができました。今回、Gemini には、ガイドラインのほか、過去 3 年分、約 600 件の照会票（照会内容と回答の記録）データをナレッジとして追加しました。AI エージェントに新たに照会内容を入力すると、ナレッジを参照し、適切な回答を出してくれる仕組みです。最初のプロトタイプの時点でかなり精度が出ていましたが、そこからさらにご要望に沿うようチューニングしていき、トータルおよそ 1.5 か月程度で必要な精度・内容に仕上げられています。」

チューニングでは、いくつかの工夫も行われました。

「例えば、照会内容によって検討すべき争点が異なるため、まず AI エージェントに照会内容から争点を洗い出させ、そのうえで回答を生成させるようにしました。これにより、担当者の思考プロセスに、より近い回答が生成されるようになりました。また、単に過去事例をナレッジとして追加するだけでは、AI がキーワードにヒットした複数の過去事例の「いいところ取り」をしてしまい、文脈のつながらない回答を生成してしまう恐れがありました。照会票データを 1 つずつ「別のファイル」としてナレッジに追加することで、個別ケースの文脈を維持した回答を引き出せるように対応しました。」（宇野氏）

さらに、回答精度の向上に加え、「この情報が足りていないので教えてください」と AI 側から追加情報の提供を促す機能も実現。これらの改善によって、実用性が大きく高まったと言います。

業務負荷を最大 50％削減見込み、今後は他部署への展開を予定

町田氏は出来上がった AI エージェントを初めて利用した際、瞬時に理想的な回答が提示されたことに感動したと、当時を振り返ります。

「単に承認・否決を判定するのではなく、過去事例なども踏まえ、『ガイドラインのこの箇所に合致します、理由はこれです』と判断の根拠を明確に提示してくれるため、これならすぐに業務に使えそうだと感じたのをよく覚えています。また、チャット形式でやり取りできることも操作の学習が不要でありがたかったですね。」（町田氏）

市川氏によると、本システムの導入によって、照会応答業務負荷が 20〜50％程度削減できることを見込んでいるとのこと。

「特に回答の均質化・平準化が図れる点を高く評価しています。今後、実務への導入が実現した場合には、まずは各県本部に対してこの AI エージェントをリリースすることで、各地の職員が悩む時間を減らし、迅速に判断できるのではないかと考えています。将来的には他部署へも横断的に展開し、組織全体の効率化を図っていきたいです。Gemini Enterprise の導入で削減できた時間を、本来注力すべき、より良い地域貢献活動の企画・分析に充てていくことで、最終的には組合員や利用者の利益にもつなげていけるのではと期待しています。」（市川氏）

今回の取り組みの成功を受け、JA 共済連と富士通は今後、さらに AI エージェントの活用を拡大していく予定で、すでに別部署では、新たな業務効率化に向けた PoC（概念実証）も始まっています。

「今後は問い合わせ業務に限らず、営業推進、査定、支払いなど、バリューチェーン全体での活用を提案していければと考えています。また、現場の担当者自らが Gemini Enterprise を操作し、AI エージェントを作成・チューニングしていく取り組みも加速していきたいです。」（岡田氏）

「今回は AI エージェントを用いた業務改善でしたが、今後は、地域貢献活動参加者のニーズ分析などに Google Cloud の技術と知見を活用していきたいと考えています。2026 年 1 月に JA共済連は 75 周年を迎えました。伝統を守りつつも、新しいテクノロジーの力で組織の変革・改革を前に進めて、より深く多角的に地域に貢献していきたいですね。」（市川氏）

全国共済農業協同組合連合会
JA グループの共済事業を全国規模で支える連合会。「相互扶助」の理念のもと、「ひと・いえ・くるま」の総合保障を中心とした活動で、組合員・地域住民の暮らしと営農を支える。全国本部と 47 都道府県本部からなる体制で、総窓口数は約 5,400 か所。従業員数は6,367 名（2025 年 3 月末現在）。

富士通株式会社
（Google Cloud パートナー）
「イノベーションによって社会に信頼をもたらし、世界をより持続可能にしていく」というパーパスを掲げ、世界中のお客様に選ばれるデジタル・トランスフォーメーション（DX）パートナーとして、社会課題の解決に取り組んでいる。AI、コンピューティング、ネットワーク、データ＆セキュリティ、およびコンバージングテクノロジーの 5 つの重点技術領域を核に、幅広いサービスとソリューションを提供。これらの技術を駆使し、持続可能な社会の実現を目指すサステナビリティ・トランスフォーメーション（SX）を推進している。

インタビュイー
全国共済農業協同組合連合会
・農業・地域活動支援部地域貢献企画管理グループ主幹　市川豪氏
・農業・地域活動支援部地域貢献企画管理グループ主査　町田瑞季氏
富士通株式会社
・Finance & Public事業本部共済事業部　岡田晋太朗　氏
・クロスインダストリーソリューション事業本部
　Forward Deployed Engineering事業部　宇野健介氏

映像制作は映像「創作」へ ── 日本テレビが挑む AI 共創の最前線

Thu, 26 Mar 2026 03:10:00 +0000

Google Cloud 主催「Agentic AI Summit '26 Spring」内で開催された第 5 回生成 AI 事例アワード。6 社のファイナリストによるピッチコンテストで見事最優秀賞に輝いたのは、日本テレビ放送網が開発した AI 共創プラットフォーム「AI Co-Creator」でした。

ドラマ「TOKYO 巫女忍者」で証明した AI × 実写の可能性

発表者は日本テレビ放送網の古谷康佑氏。2024 年新卒入社ながら、AI チーフクリエイターとして地上波ドラマ「TOKYO 巫女忍者」の制作を主導。大規模セットを使わず、実写と生成 AI を高度に融合させた映像作品を実現しました。

台本ひとつで映像が動き出す「AI Co-Creator」

この成功体験から生まれたのが「AI Co-Creator」です。台本を入力するだけで、AI が場所・人物・衣装などを自動で読み解き、シーンをまたいでも一貫した世界観を保つ画像・動画を生成します。中核には Gemini 3 Pro がオーケストレーターとして座り、画像生成には Nano Banana Pro、動画生成には Veo 3.1 を使い分けながら、アセットは Google Cloud Storage に蓄積。これらが自律型 AI エージェントとして連携する仕組みです。

AI が自ら採点・修正し、クリエイターの「打席数」を増やす

最大の特徴は、生成された動画を AI 自らが採点し修正案を出してくれる点。クリエイターは泥臭い修正作業から解放され、制作の主体が「手」から「目」へと変わります。従来数週間かかっていた絵コンテ制作がわずか 1 時間で完結し、アイデアの打席数を爆発的に増やせるようになりました。

AI は単なる効率化ツールではなく、「そうきたか」とプロを触発するクリエイティブパートナー。アイデアを持つ誰もが物語を解き放てる世界が、すぐそこまで来ています。古谷氏は今後の展望として、これまで予算の壁で諦めていたハリウッド級の CG 表現を AI で実現し、よりプレミアムなコンテンツを発信していきたいと語りました。

サイバーエージェント: 広告クリエイティブ制作を効率化する「AI SCREAM」において、 Google Cloud の画像生成 AI モデルが活躍

Thu, 26 Mar 2026 03:00:00 +0000

株式会社サイバーエージェント（以下、サイバーエージェント）は、同社が誇る豊富なクリエイティブ制作のノウハウに生成 AI 技術を組み合わせた「AI クリエイティブ BPO（Business Process Outsourcing）」事業（※1）を展開しています。その中でもとりわけ注目されているのが、クリエイティブ生成 AI プラットフォーム「AI SCREAM（アイスクリーム）」（※2）です。今回は、同プロジェクトで中心的な役割を果たしてきたおふたりに、AI SCREAM 誕生の裏側と、どのように Google Cloud の生成 AI 技術が活用されているかを伺いました。

利用しているサービス:
Veo、Imagen、Nano Banana など

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

生成 AI 活用により広告クリエイティブ制作の「量と質」を最大化する「AI SCREAM」

運用の最適化が求められるインターネット広告においては、ターゲットの属性やリアルタイムな広告効果の変化に合わせて、最適なクリエイティブを供給し続ける必要があります。サイバーエージェントの「AI SCREAM」は、各社の生成 AI モデルを、統一された UI 上で一元管理し、横断的に活用できる画期的なプラットフォームです。このプラットフォームでは、広告制作などに必要な静止画や動画、テキストといった「素材」の準備から、それらを組み合わせて広告クリエイティブなどの最終アウトプットを完成させるまでの作業を、誰もがスピーディーに行うことが可能です。

AI SCREAM 開発に初期から携わってきた同社 AI 事業本部 AIクリエイティブカンパニープロジェクトマネージャー、亀山千尋氏はその開発の背景と強みを次のように説明します。

「生成 AI を利用した広告クリエイティブ制作は、膨大な量の素材を即座に用意できることが最大の長所で、インターネット広告との相性が良いと言えます。一方で、各社のモデルは提供方法や UI、対応言語などがそれぞれ異なっており、現場のビジネス職が複数のモデルを適材適所で使い分けるハードルの高さも課題になっていました。こうしたギャップを埋めるために誕生したのが『AI SCREAM』です。プロンプトの改善や目的に最適なモデルの選択をワンストップで行える環境を整えており、専門知識を問わず、誰もが高精度なクリエイティブ制作を実現できるようになっています。」

AI SCREAM は、企画当初から AI クリエイティブ BPO 事業での展開を想定。社外へ質の高いサービスを提供するため、まずは社内で徹底的に使い込み、完成度を高める方針で開発が進められました。その後、社内 PoC を経て 2024 年 2 月に社内向けにリリースされ、現在は社内のクリエイターやビジネス職など、毎日およそ 1,000 名のユーザーに利用されるまでに成長しています。

Google Cloud の生成 AI モデルは人物のフォトリアルな表現に長けている

AI SCREAM では、商用利用可能な新たな生成 AI モデルが各社から登場すると毎回、社内ガイドライン（※3）と照らし合わせた上で、2 週間以内に検証・実装を完了するスピード重視の方針が採用されています。亀山氏によれば、さまざまな生成 AI の中でも、Veo や Imagen、Nano Banana などの Google Cloud の画像生成 AI モデル群は、社内利用で高い評価を獲得しているとのことです。

「広告クリエイティブにおいて、商品やサービスに親近感を持っていただくためには、自然な人物描写が必要な場合があります。その点、Google Cloud の画像生成 AI モデルは、特に人物を違和感なく描写できるといったような評価がとても多いです。」

亀山氏と共に AI SCREAM のプロジェクトを推進してきた、AI 事業本部 AI クリエイティブカンパニープロジェクトマネージャー、鈴木知佳氏は、フォトリアルな表現に加え、ユーザーの意図に忠実なアウトプットが可能であることも、Google Cloud の生成 AI モデル群が高く支持される理由だと語ります。

「Google Cloud の画像生成 AI モデルは、プロンプトの意図を正確に捉えた出力精度が高く、イメージ通りに仕上げやすいところが喜ばれているようです。特に Nano Banana は、発表直後から機能性や表現力の面で注目を集めており、現場からは『1 日も早く AI SCREAM に組み込んでほしい』という要望が上がるほどでした。」

サイバーエージェントでは、現場の声を受けた改善も継続的に実施。例えば 2025 年 12 月には、クリエイティブ制作から部分的な修正・編集までを誰でもスピーディーに完結できる、「ブラッシュアップ AI 機能」も追加されています。

「ブラッシュアップ AI 機能は、複数の生成 AI モデルを組み合わせたエージェント技術で実現しています。ただし、開発は容易ではありませんでした。AI ならではの出力の不確実性を最小限に抑え、膨大な選択肢から、ベストプラクティスを見出すことの難しさを痛感させられましたね。」（鈴木氏）

この課題を乗り越えるべく、AI SCREAM 開発チームはアジャイルなアプローチを採用。まずはベータ版として同機能を提供し、ユーザーからのフィードバックを踏まえて、迅速に改善を重ねることで完成度を高めていきました。亀山氏は、この迅速な開発サイクルを支えたのが、Google Cloud の献身的なサポート体制だったと振り返ります。

「生成 AI モデルのベンダーは多くが海外企業ということもあり、サポートを受けるまで時間を要する場合もあります。しかし Google Cloud の対応は極めて速く、いつも助けられました。『新モデル登場から 2 週間以内に提供する』という私たちの方針を維持し、ブラッシュアップ AI 機能を実現できたのは、その親身な伴走のおかげだと感じています。」

（AI SCREAM によるクリエイティブ編集の例）

AI SCREAM がデザイナー、ビジネス職双方に意識変容をもたらした

AI SCREAM で生成された素材の点数は、2025 年 2 月からの 1 年間で累計 120 万点を突破しました（※4）。そのうち約 10 万点が実際の案件や社内キャンペーン、提案資料など、さまざまなシーンで使われています。とりわけ特筆すべきは、制作時間短縮で、従来の方法に比べて現段階で約 30% の削減に成功しました。しかし鈴木氏は、それが意味するのは、単なる省力化やコストカットではないと胸を張ります。

「広告クリエイティブ制作に携わるメンバーが『どうすれば広告効果を最大化できるか』という本質的な発想や表現の開発により注力できるようになりました。 AI を活用することで、人間とテクノロジーの適切な役割分担が実現しています。」

さらに、亀山氏は、AI SCREAM 最大の成果は、直観的で分かりやすい UI / UX の実現によって、ビジネス職でも、自らクリエイティブを制作・編集を行える環境が整ったことだと強調します。

「このことは大きな意識変容をもたらしました。広告運用の現場では、細かな修正に即座に対応し、PDCA を回す速さが成果を左右します。こうしたスピーディーな対応を誰もが行える環境になったことは、ビジネス職にとっても大きな変化でした。クリエイターには、彼らにしかできない高度な判断や企画にリソースを集中させ、それ以外の工程を効率化するという好循環が生まれ、結果としてアウトプット全体のクオリティ向上につながっています。」

サイバーエージェントは、自社およびパートナー企業での活用を通じて得られた知見と実績をもとに、今後は外部企業への展開をより一層加速させていきます。最後に、亀山氏は将来を見据え、Google Cloud への期待を語ってくれました。

「継続的な機能改善のためにも、Google Cloud が提供する優れたモデルのさらなる進化を心待ちにしています。個人的には、グローバル企業ならではのローカライズに期待しているところです。“日本らしさ” を理解し、これまで以上に違和感のない出力ができるようになると、活用の幅がますます広がっていくはずです。また、多くの企業が安心して生成 AI を導入できるよう、Google Cloud には安全性強化の点でも、業界を牽引していただけることを願っています。」

^（※1）^{AI クリエイティブ BPO（Business Process Outsourcing）事業}^（※2）^{クリエイティブ生成 AI プラットフォーム「AI SCREAM（アイスクリーム）」}^（※3）^{社内ガイドライン}^（※4）^{AI SCREAM で生成された累計生成点数は 120 万点を突破}

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

インタビュイー
・AI 事業本部　AI クリエイティブカンパニープロジェクトマネージャー　亀山千尋氏
・AI 事業本部　AI クリエイティブカンパニープロジェクトマネージャー　鈴木知佳氏

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

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

Wed, 25 Mar 2026 03:00:00 +0000

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

AI の世界は急速に変化しており、モデルのサービングを大規模かつ確実に行う必要性も高まっています。このたび、マルチクラスタ GKE Inference Gateway のプレビュー版がリリースされましたのでお知らせいたします。これにより、複数の Google Kubernetes Engine（GKE）クラスタにわたり（異なる Google Cloud リージョンにまたがる場合も含め）、AI / ML 推論ワークロードのスケーラビリティ、復元力、効率性を強化できます。

GKE Gateway API の拡張機能として構築されたマルチクラスタ Inference Gateway は、マルチクラスタ Gateway の機能を活用して、特に要求の厳しい AI アプリケーション向けに、モデル対応のインテリジェントなロードバランシングを提供します。

AI 推論にマルチクラスタを使用する理由

AI モデルの複雑性が増し、ユーザーのグローバル化が進むにつれて、単一クラスタのデプロイでは次のような課題に直面する可能性があります。

可用性のリスク: リージョンの停止やクラスタのメンテナンスがサービスに影響を及ぼす可能性があります。
スケーラビリティの上限: 単一のクラスタまたはリージョン内で、ハードウェアの上限（GPU / TPU）に達してしまいます。
リソースのサイロ化: あるクラスタで十分に活用されていないアクセラレータ容量を別のクラスタで使用できません。
レイテンシ: サービスを提供しているクラスタから離れているユーザーはレイテンシが高くなる可能性があります。

マルチクラスタ GKE Inference Gateway は、これらの課題に正面から取り組み、次のようなさまざまな機能とメリットを提供します。

信頼性とフォールトトレランスの強化: 異なるリージョン間を含め、複数の GKE クラスタにわたってトラフィックをインテリジェントにルーティングします。1 つのクラスタまたはリージョンで問題が発生した場合、トラフィックは自動的に再ルーティングされ、ダウンタイムが最小限に抑えられます。
スケーラビリティの向上とリソース使用量の最適化: さまざまなクラスタから GPU / TPU リソースをプールして活用できます。単一クラスタの容量を超えてバーストすることで需要の急増に対応し、利用可能なアクセラレータをフリート全体で効率的に活用できます。
グローバルに最適化されたモデル対応のルーティング: Inference Gateway は、高度なシグナルを使用してスマートなルーティング判断を下すことができます。GCPBackendPolicy を使用して、リアルタイムのカスタム指標（モデルサーバーの KV キャッシュ使用率指標など）に基づいてロードバランシングを構成できるので、最適なバックエンドインスタンスにリクエストが送信されるようになります。処理中リクエストの制限など、他のモードもサポートされています。
運用の簡素化: モデルを複数の「ターゲットクラスタ」で実行しながら、専用の GKE「構成クラスタ」で 1 つの Inference Gateway 構成を使用して、グローバルに分散された AI サービスへのトラフィックを管理できます。

仕組み

GKE Inference Gateway には、InferencePool と InferenceObjective という 2 つの基本リソースがあります。InferencePool は、同じコンピューティングハードウェア（GPU や TPU など）とモデル構成を共有する Pod のリソースグループとして機能し、スケーラブルで高可用性のサービングを実現します。InferenceObjective は、特定のモデル名を定義し、サービングの優先順位を割り当てます。これにより、Inference Gateway はトラフィックをインテリジェントにルーティングし、レイテンシの影響を受けやすいタスクと緊急性の低いワークロードを多重化できます。

このリリースでは、Kubernetes カスタムリソースを使用して、分散推論サービスが管理されます。各「ターゲットクラスタ」の InferencePool リソースは、モデルサーバーのバックエンドをグループ化します。これらのバックエンドはエクスポートされ、「構成クラスタ」で GCPInferencePoolImport リソースとして表示されます。構成クラスタ内の標準の Gateway リソースと HTTPRoute リソースは、エントリポイントとルーティングルールを定義し、トラフィックをこれらのインポートされたプールに転送します。CUSTOM_METRICS や IN_FLIGHT リクエストの使用など、きめ細かいロードバランシングの動作は、GCPInferencePoolImport にアタッチされた GCPBackendPolicy リソースを使用して構成されます。

このアーキテクチャにより、グローバルな低レイテンシのサービング、障害復旧、容量のバースト、異種ハードウェアの効率的な使用などのユースケースが可能になります。

GKE Inference Gateway のコアコンセプトについて詳しくは、ガイドをご覧ください。

使ってみる

AI 推論サービングワークロードをより多くの場所とより多くのユーザーにスケールする際に、マルチクラスタ GKE Inference Gateway をぜひお試しください。詳細と利用方法については、次のドキュメントをご覧ください。

- シニアプロダクトマネージャー、Arman Rye

- シニアスタッフソフトウェアエンジニア、Andres Guedez

Anatom-AI：自然言語で 3D 人体解剖アトラスを操作する、医師チームの挑戦

Wed, 25 Mar 2026 02:00:00 +0000

Zenn 主催、Google Cloud 協賛で開催した「第 4 回 Agentic AI Hackathon with Google Cloud 」では、全 880 エントリー・200 超のプロジェクトが集まりました。その中で最優秀賞に輝いたのが、現役医師 4 名のチームが開発した Anatom-AI です。

医療現場から生まれた課題意識

医学生の 71% が解剖学に苦手意識を持つと言われています。従来の教科書は 2D のイラストが中心で、臓器の立体的な位置関係を把握しにくいという課題がありました。3D アプリも登場していますが、目的の臓器にたどり着くまでに何十回ものクリック操作が必要で、初学者にとってハードルの高いものでした。

AI エージェントが解剖学の「使いにくさ」を解消

Anatom-AI は、Google Cloud の Vertex AI（Gemini）を活用した AI エージェントと、2,000 パーツ以上の 3D モデルを組み合わせた解剖アトラスです。バックエンドは Cloud Run 上にデプロイされており、スケーラブルかつ低コストな運用を実現しています。チャット欄に「膵臓の位置を教えて」と入力するだけで、AI が必要な臓器を自動で判断し、周囲を透明化して 3D で表示します。

注目すべきは、単なる解剖学習にとどまらない点です。「脳梗塞で詰まる血管の影響範囲を見せて」といった病態の可視化にも対応しており、チームによれば救急現場での迅速な確認や患者への説明ツールとしての活用も見据えているとのことです。

拡張性のあるアーキテクチャと今後の展望

AI エージェントと 3D モデルを分離した設計により、3D パーツを自由に拡張できる点も高く評価されました。チームによると、今後は患者の CT 画像から個別の 3D モデルを再構成し、手術前シミュレーションに活用できる「患者個別アトラス」への発展を構想しているとのことです。また、脳梗塞や胆嚢疾患などの典型的な病態テンプレートを充実させることで、教材としての有用性をさらに高めていく予定だと語っていました。

現役医師ならではのリアルな課題意識と、AI エージェントの可能性を最大限に引き出した技術力。まさに Agentic AI が医療の未来を変えていく好例と言えるプロジェクトでした。

Google Cloud と NVIDIA が GTC 2026 で業界全体に AI イノベーションを拡大

Tue, 24 Mar 2026 03:00:00 +0000

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

エージェント型 AI の時代により、企業インフラストラクチャのニーズは根本的に変化しています。組織が動的な推論と自律的な実行が可能なシステムを構築するにつれて、基盤となるインフラストラクチャも進化する必要があります。これらのエージェントワークロードを大規模な混合エキスパート（MoE）アーキテクチャとともにスケールするには、細部まで最適化された共同設計のスタックが必要です。

こうした需要に応えるため、Google は AI に最適化された Infrastructure as a Service である Google Cloud AI Hypercomputer を構築しました。これは、パフォーマンスが最適化されたハードウェア、最先端のソフトウェア、オープンフレームワーク、柔軟な使用量モデルを包括的な単一システムに統合したものであり、超低レイテンシ、高スループット、費用対効果の高い推論を実現します。この統合アーキテクチャ内でお客様にさらに多くのオプションを提供するために、Google は NVIDIA とのパートナーシップを拡大しています。

今週開催される NVIDIA GTC 2026 で、Google Cloud と NVIDIA はパートナーシップを拡大し、共同設計した AI インフラストラクチャ基盤を紹介する一連の新しい発表を行います。

インフラストラクチャとハードウェア

NVIDIA RTX Pro™ 6000 Blackwell Server Edition を搭載した Google Cloud G4 VM の勢い
NVIDIA vGPU テクノロジーを使用した、柔軟な分割式 G4 VM のプレビュー版 - NVIDIA RTX Pro™ 6000 Blackwell Server Edition では業界初
NVIDIA Vera Rubin NVL72 プラットフォームのサポート予定

ソフトウェアとプラットフォーム

NVIDIA Dynamo と GKE Inference Gateway のインテグレーション
Vertex AI Training と Model Garden 全体で NVIDIA のサポートを強化

エコシステム

公共部門向け AI スタートアップアクセラレータプログラムの開始

発表内容を詳しく見ていきましょう。

G4 VM で AI ワークロードを高速化

NVIDIA RTX Pro 6000 Blackwell Server エディション GPU を搭載した G4 VM は、高度な空間コンピューティングから完全な AI 開発ライフサイクルまで、さまざまな高パフォーマンスワークロードを強化するために構築されています。たとえば、Otto Group One.O や WPP などの企業は、G4 を使用して物理的に正確なシミュレーションやリアルタイムの 3D レンダリングを大規模に実行しています。

シミュレーション以外にも、G4 はモデルのファインチューニングと推論で優れた性能を発揮し、特に 300 億から 1,000 億以上のパラメータを持つモデルに適しています。4 ビット浮動小数点（FP4）精度と Google のピアツーピア（P2P）通信を活用することで、お客様はモデル提供のスループットの向上とレイテンシの大幅な削減を実現し、リアルタイムのマルチモーダル AI エージェントや応答性の高い生成 AI アプリケーションという新しいクラスを可能にしています。

お客様がすでに G4 VM のパフォーマンスと効率性を活用して、最も要求の厳しいワークロードを高速化させている例をいくつかご紹介します。

「Google Cloud の G4 VM は、膨大な量のフォトリアルなシミュレーションをパイプラインで処理するために必要とされる、スケーラブルな GPU バックボーンを提供してくれます。スループットが 4 倍に向上したことで、ML チームはより迅速にイテレーションを行い、より豊富なデータでトレーニングし、モデルが実環境に導入されるよりかなり前にエッジケースを検証できるようになりました。」– General Motors、AI / ML エンジニアリング担当ディレクター、Sony Mohapatra 氏

「NVIDIA Blackwell を搭載した G4 VM を使用することで、マルチモーダルモデルをさらに進化させられるようになりました。推論の高速化、信頼性の向上、言語を問わない即時応答などです。目標は変わりません。企業規模で機能する音声エージェントを、妥協せずに作成することです。今後も共同で開発を続け、お客様がこのツールをどのように活用されるかを楽しみにしています。」– ElevenLabs、共同創業者、Mati Staniszewski 氏

「Google Cloud G4 VM は、当社のロボット連携レイヤの計算バックボーンを提供し、物流センター全体で自律型フリートをミリ秒単位の精度で同期できるようにします。忠実度の高いデジタルツインで複雑な倉庫環境をシミュレートすることで、サプライチェーン全体を仮想的に最適化してから、ロボットに床を移動させることができます。」 - Otto Group One.O、CEO、Stefan Borsutzky 博士

「G4 VM に移行したところ、Terraform スクリプトを更新するだけで、処理レイテンシが 50% 削減され、スループットが 6 倍に向上しました。運用オーバーヘッドを追加することなく、コアワークロードのパフォーマンスをこれほど向上させることはめったにありません。」– Imgix、エンジニアリング責任者、Alfonso Acosta 氏

分割式 G4 VM の導入

このたび、AI およびグラフィックワークロード向けの非常に効率的で費用対効果の高いエントリーポイントとなる、分割式 G4 VM のプレビュー版がリリースされました。NVIDIA 仮想 GPU（vGPU）テクノロジーを使用したこれらの新しい構成により、NVIDIA RTX PRO 6000 Blackwell Server エディション GPU のパワーを柔軟かつ小規模な単位で活用できるため、アプリケーションの特定の需要に合わせてインフラストラクチャを適切なサイズに調整できます。

「企業は、複雑なエージェント型 AI ワークロードをスケールするために、前例のないほどの柔軟性を必要としています。NVIDIA は Google Cloud とともに、NVIDIA RTX PRO 6000 を搭載した分割式 G4 VM を導入し、お客様が GPU 容量のサイズを適正化して ROI を最大化できるようにしました。Vertex AI 上の NVIDIA NeMo から GKE の NVIDIA Dynamo まで、共同設計されたスタックにより、次世代の推論モデルと MoE モデル向けのオープンで高性能なプラットフォームを提供します。」- NVIDIA、ハイパースケール / HPC 担当バイスプレジデント兼ゼネラルマネージャー、Ian Buck 氏

高度なハードウェアへのアクセスをより細かく制御できるため、分割式 G4 VM はパフォーマンスを犠牲にすることなく、リソース割り当てを最適化してオーバーヘッドを削減できます。特定のニーズに合わせて、追加の GPU スライスサイズから選択できるようになりました。

1/2 GPU: LLM 推論、ロボットセンサーシミュレーション、高忠実度 3D レンダリングなど、より負荷の高いタスクに最適です。
1/4 GPU: 中程度のクリエイティブデザイン、動画のコード変換、リアルタイムのデータ可視化など、主流のワークロード向けに最適化されています。
1/8 GPU: リモートデスクトップ、生産性向上ツール、エントリーレベルのストリーミングサービスなどの軽量アプリケーションに最適です。

これらの柔軟な G4 サイズポートフォリオにより、次のことが可能です。

インフラストラクチャの適切なサイジング: 軽量なリモートデスクトップから集中的なデータ処理まで、GPU 容量をアプリケーションの需要に正確に一致させます。
費用効率を最大化: 特定のタスクに必要な分割 GPU リソースのみを利用して料金を支払うことで、運用オーバーヘッドを削減します。
多様なワークロードをスケール: 高忠実度のクリエイティブデザインやストリーミングから、複雑なロボットシミュレーションやリアルタイム推論まで、幅広いイノベーションを推進します。

これらの部分的な G4 VM は Google Kubernetes Engine（GKE）で管理できるため、開発者は高度なコンテナビンパッキングを使用して、さらに高い費用対効果とリソース使用率を実現できます。Dynamic Workload Scheduler を使用して管理する場合、分割スライスにフォールバックの優先順位を設定できます。これにより、スケジューラが各ワークロードで利用可能な GPU 構成を自動的に検出できるようになるため、取得可能性が大幅に向上します。

「G4 vGPU の柔軟なサイズ設定により、各分子シミュレーションの規模に合わせてコンピューティングリソースを正確に調整できるため、創薬パイプライン全体で最大限の効率を確保できます。このきめ細かい制御により、研究者は固定されたハードウェア構成に制約されることなく、小規模なワークフローと大規模な並列処理の間をシームレスに切り替えられます。」– Schrödinger、EVP、CIO、Shane Brauner 氏

NVIDIA Vera Rubin NVL72 で AI Hypercomputer をスケーリング

NVIDIA との緊密なエンジニアリングパートナーシップを基盤として、Google は NVIDIA Blackwell アーキテクチャの後継である、先日発表された NVIDIA Vera Rubin プラットフォームをサポートできることを誇りに思います。Google は 2026 年下半期に NVIDIA Vera Rubin NVL72 ラック規模システムをいち早く提供するクラウドプロバイダとなる予定です。このシステムを Google の AI Hypercomputer アーキテクチャに統合し、次世代の推論 AI とエージェント型 AI を強化します。

AI インフラストラクチャスタック全体で効率性を実現

Google は、完全にオープンなエコシステムへの取り組みの一環として、Dynamo と GKE Inference Gateway のインテグレーションを発表いたしました。これにより、アプリケーションレイヤとハードウェア全体にわたってモジュール式のオープンソースコントロールプレーンが提供されます。Dynamo と GKE の Inference Gateway を組み合わせることで、チームはインフラストラクチャを正確なニーズに合わせて調整し、アクセラレータから最大限の費用対効果を引き出し、新しい AI モデルの市場投入までの時間を短縮し、デプロイを将来にわたって保証できます。

A4X VM（NVIDIA GB200 NVL72 と Dynamo を搭載）向けの新しい高度なスケーリングレシピを通じて、大規模な MoE アーキテクチャのパフォーマンスを最大化する方法を学ぶことができます。これらの構成は、AI Hypercomputer で AI 推論ワークロードを実行する際に、メモリとインターコネクトのボトルネックを克服する方法を示しています。

また、Dynamic Workload Scheduler を通じてリソースの取得可能性を高めています。A4X および A4X Max（NVIDIA GB300 NVL72 搭載）の Calendar モードと Flex Start、および G4 VM の新しい Flex Start サポートが提供されます。Dynamic Workload Scheduler を使用すると、必要な容量を正確に予約したり、柔軟な開始ウィンドウを使用したりできます。

Google Cloud の長年の顧客である Snap は、主要なデータ処理パイプライン 2 つを NVIDIA L4 Tensor コア GPU を搭載した Google Cloud G2 VM に移行することで、大幅な費用削減を実現しました。これは、GKE 上の Spark と NVIDIA の新しい cuDF ライブラリを活用することで実現しました。cuDF ライブラリは、シャッフルを多用するワークロードの最適化を自動化し、GPU の効率を最大限に高めます。詳しくは、GTC セッション S81678 をご覧ください。

Vertex AI のトレーニングと Model Garden の進化

Google は、Vertex AI トレーニングクラスタの 2 つの主要なインフラストラクチャの進歩により、次世代 AI の需要に対応しています。まず、A4X VM ドメインのサポートにより、Vertex AI のマネージドインフラストラクチャとフレームワーク機能を活用して、NVIDIA GB200 NVL72 ラックスケールシステムで大規模なトレーニングを行うことができます。これらの集中的なワークロードが中断されないようにするため、新しいハードウェアの復元機能により、構成可能な事前対応型の障害検出スキャンを適用できます。これにより、潜在的なハードウェアの問題を特定して軽減し、重要な「ヒーロー」トレーニングの実行が中断されるのを防ぎます。これらの機能により、グッドプットが向上し、数週間にわたるトレーニングジョブが費用のかかる再起動なしで順調に進むようになります。

「私たちは Google および NVIDIA とともに、高性能で一貫性があり、正確で応答性の高い AI エージェントを提供するという、エージェント型エンタープライズの新たな基準を打ち立てています。NVIDIA GB200 NVL72 上の Vertex AI トレーニングクラスタを活用して Agentforce 360 プラットフォームを強化することで、インフラストラクチャのボトルネックを解消し、GPU を完全に飽和状態に保つことができました。この高パフォーマンスで復元力のあるアーキテクチャにより、研究者は大規模なイノベーションに集中でき、最も複雑な推論ワークロードで大きな成果を上げています。」- Salesforce、最高科学責任者、Silvio Savarese 氏

同時に、NVIDIA の Nemotron 3 ファミリーのオープンモデルのサポートにより、Vertex AI Model Garden の範囲を拡大し続けています。たとえば、Nemotron 3 Nano はワンクリックでデプロイできるため、プライベート VPC への統合が簡単です。また、カタログを拡大し、NVIDIA Nemotron 3 Super 120B モデルを追加しました。これにより、高性能な大規模推論にすぐにアクセスできます。これらのモデルの価値を最大限に高めるため、Google は NVIDIA の最新のパフォーマンスライブラリを Vertex AI に直接統合し、NVIDIA TensorRT-LLM で一般的なオープンソースモデルを最適化しました。

公共部門向けの AI スタートアップを支援

エコシステム内の継続的なイノベーションを促進するため、Google Public Sector と NVIDIA は AI スタートアップアクセラレータプログラムを開始します。この 1 年間のイニシアチブでは、公共部門向けのソリューションを構築する、AI に重点を置いた独立系ソフトウェアベンダー（ISV）の選抜されたコホートをサポートします。

参加者は、NVIDIA Inception と Google Cloud の ISV アクセラレータリソースの両方にアクセスできます。GTC で開始され、Google Cloud Next まで続くこの共同プログラムでは、ミッションクリティカルな公共部門アプリケーションをスケールするために必要な、共同設計されたインフラストラクチャ、技術ガイダンス、市場開拓サポートを、新興テクノロジーのリーダーに提供します。プログラムについて詳しくは、お問い合わせフォームにご記入ください。今後、他のコホートも選出され、発表される予定です。

共同エンジニアリングのコラボレーションが AI スタックのあらゆるレイヤを強化

複雑なエージェント型 AI への移行には、単なるコンピューティング能力以上のものが求められます。完全に最適化された共同設計のスタックが必要です。Google は、分割式 G4 インスタンスや今後リリースされる Vera Rubin プラットフォームなどの柔軟なハードウェアを AI Hypercomputer アーキテクチャに統合し、ソフトウェアの緊密な共同エンジニアリングと組み合わせることで、最も野心的な AI ビジョンを現実に変えるために必要なスケール、レジリエンス、効率性を実現します。

GTC に参加されますか？ブース番号 513 にぜひお立ち寄りください。詳細をご覧いただき、Google のチームと直接お話いただけます。Google と NVIDIA のコラボレーションの詳細については、cloud.google.com/NVIDIA をご覧ください。

-AI およびコンピューティングインフラストラクチャ担当バイスプレジデント兼ゼネラルマネージャー、Mark Lohmeyer

AI & 機械学習

新しい GKE Cloud Storage FUSE プロファイルにより、AI ストレージの構成における当て推量が不要に

Cloud Storage FUSE の最適化に伴う課題

GKE 向け Cloud Storage FUSE プロファイルの概要

GKE で Cloud Storage FUSE プロファイルを使用する方法

使ってみる

Vertex AI の Lyria 3 モデルで音楽生成をアプリに組み込む

Lyria 3 モデルがお客様のオーディオ エクスペリエンスの実現にどのように役立っているか

商用利用の安全性と責任ある制作

今すぐ制作に着手しましょう

膨大な表計算作業から脱却。AI と数理最適化で実現する、需要予測の先の「発注・在庫管理の自動化」

「表計算ソフト作業」への依存がもたらす限界

AI エージェントの導入：自然な対話で「発注点メンテナンス」を民主化

導入効果：劇的な業務削減と「あるべき姿」への集中

今後の展望：数理最適化のさらなる拡張と AI エージェントの融合

GKE Inference Gateway を使用して、同じインフラストラクチャでリアルタイム推論と非同期推論を実行する

2 つの推論パターン: リアルタイムと非同期

1. リアルタイム推論: レイテンシの影響を受けやすい 0 秒のリクエスト

2. 非同期（ニア リアルタイム）推論: 0 分のレイテンシ

ソリューション: 非同期プロセッサ エージェント + Inference Gateway

統合ワークロードの実例

次のステップ

Google Cloud で利用できる Gemma 4 の概要: Google の最も高性能なオープンモデル

Gemma 4 を使い始めるには

使ってみる

Claude Mythos Preview: Vertex AI で限定公開プレビュー版を提供開始

FM Logistic が AlphaEvolve を使って倉庫規模の「巡回セールスマン問題」を解決

AI に、もっと優れたアルゴリズムを書いてもらう

改善結果の評価

結果

最終的に勝ち残ったアルゴリズムの動作

次のステップ

Vertex AI に Veo 3.1 Lite と Veo の新しいアップスケーリング機能を導入

ワークロードに適した Veo モデルの選択

Veo の新しいアップスケーリング機能でアセットをアップスケール

Veo 3.1 Lite を今すぐお試しください

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

調査

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

調査結果その 2: 過度な依存に対する積極的な抵抗

調査結果その 3: AI の使いどころを心得ている

すべてを任せるのではなく、意図的に取り入れる

カスタマイズが肝

この調査結果が業界において意味すること

初級者コースのように簡単: Vail Resorts がパーソナライズされたおすすめを自動化する AI アシスタントを構築した方法

AI インフラストラクチャとしての Kubernetes: Google Cloud、llm-d、CNCF

推論のための Kubernetes の強化

次世代の AI インフラストラクチャを共同で構築

DRA: 動的リソース割り当てが切り開く Kubernetes デバイス管理の新時代

静的なインフラストラクチャからの脱却

詳細解説: DRA の仕組み

ResourceSlice: 可用性の記述

ResourceClaim: 要件の定義

能力ベースのアプローチによるスマートなスケジュール設定

ぜひお試しください

「生成 AI」から「エージェント型 AI」へ — 自律する AI が変える企業経営

単なるコンテンツ生成から自律的な意思決定へ — エージェント型 AI の台頭

期待される 3 倍の ROI と「先行組」の成功の秘訣

成功の鍵を握るデータ基盤とフルスタック プラットフォーム

実務的なアプローチで進化する日本市場の未来

Ironwood TPU を使用したトレーニングに関するデベロッパー ガイド

Ironwood の主な最適化戦略

Ironwood のメリット: システムレベルのパフォーマンス

JA 共済連: 年間数百件におよぶ問い合わせの回答支援 AI エージェントを Gemini Enterprise を用いてスピーディに構築

AI エージェント活用で「2040 年問題」に備える

Gemini Enterprise だから実現できた短期間での課題解決

業務負荷を最大 50％ 削減見込み、今後は他部署への展開を予定

映像制作は映像「創作」へ ── 日本テレビが挑む AI 共創の最前線

ドラマ「TOKYO 巫女忍者」で証明した AI × 実写の可能性

台本ひとつで映像が動き出す「AI Co-Creator」

AI が自ら採点・修正し、クリエイターの「打席数」を増やす

サイバーエージェント: 広告クリエイティブ制作を効率化する「AI SCREAM」において、 Google Cloud の画像生成 AI モデルが活躍

生成 AI 活用により広告クリエイティブ制作の「量と質」を最大化する「AI SCREAM」

Google Cloud の生成 AI モデルは人物のフォトリアルな表現に長けている

AI SCREAM がデザイナー、ビジネス職双方に意識変容をもたらした

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

AI 推論にマルチクラスタを使用する理由

仕組み

使ってみる

Anatom-AI：自然言語で 3D 人体解剖アトラスを操作する、医師チームの挑戦

Lyria 3 モデルがお客様のオーディオエクスペリエンスの実現にどのように役立っているか

2. 非同期（ニアリアルタイム）推論: 0 分のレイテンシ

ソリューション: 非同期プロセッサエージェント + Inference Gateway

成功の鍵を握るデータ基盤とフルスタックプラットフォーム

Ironwood TPU を使用したトレーニングに関するデベロッパーガイド

業務負荷を最大 50％削減見込み、今後は他部署への展開を予定

AI インフラストラクチャスタック全体で効率性を実現