Cloud Blog JA

AI コーディングエージェント向け Google Cloud Developer プラグインのご紹介

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

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

エージェントスキルをドキュメントやリモート MCP サーバーと組み合わせて使用することは、AI ワークフローを成功させるための有効な手段となります。特定のユースケースではコンテキストウィンドウの使用量を削減する効果もあり、インストールも簡単です。しかし、個々のスキルの管理は煩雑になりがちであり、スキルによっては他のスキルや MCP サーバーと連携して同じ目標に向かって動作するときに最も効果を発揮するものもあります。こうした場合に役立つのがプラグインです。

そこでこのたび、AI コーディングエージェント向けの新しい Google Cloud プラグインをリリースしました。これらのエージェントプラグインは、インストール可能なバンドルとして設計されており、Google Cloud 上でより効果的に動作するためのスキルとツールを任意の AI エージェントに提供します。

ツールの連動に関する問題を解決

コーディングエージェントの使用を拡大していくと、関連するスキルを組み合わせて使用したり、補完的なコンテキストやツールと併用したりすることで、その能力が大幅に向上する場合があります。たとえば、インフラストラクチャを分析するエージェントは、ドメインの知識、ワークフローの推奨事項、ライブ環境とやり取りする機能と組み合わせることで、効果が向上します。

プラグインは、関連する機能をまとまりのあるインストール可能なバンドルにパッケージ化することで、「ツールを連動させる」という課題を解決します。これにより、複雑な依存関係を管理することなく、幅広い基本機能とプロダクト固有の高度なツールの両方を活用できるようになります。

このリリースではまず、すべての Google Cloud ユーザーのエージェント機能に対応できる基本的なプラグインを提供します。エージェントが Google Cloud 関連のスキルを簡単に取得し、公式ドキュメントを活用して、Google Cloud とのプログラマティックなやり取りを処理できるようにすることに重点を置いています。

オープンスタンダードを基盤に構築

また、Google のプラグインは、エージェントスキルと Model Context Protocol（MCP）サーバーをポータブルで相互運用可能なユニットにパッケージ化するための、オープンかつベンダーに依存しない標準である Agent Plugins 仕様に準拠して構築されています。Agent Plugins 標準は、開発者が AI アシスタントごとに異なる構成やラッパーを管理する必要をなくし、統合されたマニフェストとディレクトリ構造を提供します。

Google Cloud のプラグインは、この標準を採用することで、さまざまな AI コーディング環境を利用するデベロッパーが Google Cloud での成功を支援するツールにアクセスする際の一貫性と品質を確保しています。この標準は、本日ご紹介するプラグインだけでなく、Google Agent Skills リポジトリに公開されている他のすべてのプラグインにも適用されています。

ここでは、Google Agent Skills リポジトリに公開したばかりのフラッグシッププラグインである google-cloud-developer について見ていきます。このプラグインは、エージェントが Google Cloud を操作する際の基本事項（認証、認可、プロジェクトの管理、gcloud CLI オペレーションのガードレールなど）を適切に処理できるようにするためのものです。このプラグインには、Developer Knowledge MCP サーバーの構成もバンドルされています。そのため、エージェントは Google のデベロッパー向け公式ドキュメントを最新のグラウンディングとして利用できます。

プラグインの動作: プロジェクトのオンボーディングと ID の認証

このプラグインの仕組みを理解するため、スクリプト作成作業の一環として新しいプロジェクトをブートストラップする場合を考えてみましょう。google-cloud-developer プラグインをインストールすると、エージェントに次のようなプロンプトを送信できます。

このプラットフォームを初めて使用するので、アカウントを取得して、課金を設定した最初のプロジェクトを作成する必要があります。次に、作成中のスクリプトが自分自身としてではなく、サービス ID として API を呼び出せるように、ローカルマシンを認証する必要があります。

環境の把握: エージェントは、CLI が利用可能か、既存のプロジェクトや組織があるかといった前提条件を確認するため、実際の環境に対してバックグラウンドでサイレントにチェックを実行します。
レビュー: エージェントは、プロンプトの内容に起因して発生しうるリスク（誤って鍵を漏洩する、Git への commit など）を考慮します。
ガードレールとのやり取り: エージェントはワークフローのロードマップを提示し、リソースを変更する前に、それらのステップを実行するかどうかをユーザーに確認します。

Google Cloud プラグインのインストール

Google Cloud プラグインは、オープンな Google Agent Skills リポジトリから入手可能です。標準の Agent Plugins レイアウトに準拠しているため、簡単にご利用の環境に追加できます。たとえば、google-cloud-developer プラグインは以下の方法でインストールできます。

Antigravity CLI

Google Agent Skills リポジトリ内のパスを使用して、CLI からプラグインを直接インストールします。

code_block: <ListValue: [StructValue([('code', 'agy plugin install https://github.com/google/skills/plugins/cloud/google-cloud-developer'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0842b50>)])]>

Claude Code

Google プラグインマーケットプレイスを追加してから、プラグインをインストールします。

code_block: <ListValue: [StructValue([('code', 'claude plugin marketplace add google/skills\r\nclaude plugin install google-cloud-developer@google-plugins'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde1156ad0>)])]>

Codex CLI

Google プラグインマーケットプレイスを追加してから、プラグインをインストールします。

code_block: <ListValue: [StructValue([('code', 'codex plugin marketplace add google/skills\r\ncodex plugin add google-cloud-developer@google-plugins'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde1156850>)])]>

次のステップ

すでに Google Cloud を利用している場合は、上記の手順に沿ってインストールし、エージェントを成功へ導けるよう設定してみてください。皆様にその効果を実感していただけるものと確信しております。詳細なガイド付きの手法をご希望の方向けに、新しい Codelab では Antigravity でのプラグインのインストールと初期探索の方法について説明しています。

Google Cloud を初めてご利用になる場合は、Google のドキュメントの手順に沿ってローカル開発環境をセットアップすることもできます。

さらに詳しく知りたい方は、Google Agent Skills リポジトリで、現在利用可能なプラグインとエージェントスキルの詳細をご確認ください。

- コンテンツストラテジスト、Jonathan Lee

Spanner: DML トランザクションの累積ミューテーション上限を撤廃

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

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

Spanner は、Google Cloud の妥協のない業務データベースです。水平スケーリングや常時稼働の可用性といった最新の分散型システムの利点に加え、豊富な機能セットや使い慣れたエコシステムといったリレーショナルデータベースの利点を兼ね備えています。現在、銀行、小売、メディア、エンターテイメント、AI インフラストラクチャなどの業界のイノベーターが、最も重要なワークロードに Spanner を利用しています。この Spanner において、このたび、より大規模かつ複雑なトランザクションを柔軟に処理する新しい方法が導入されたことをお知らせします。これにより、最高レベルのデータ整合性を必要とするアプリケーションを簡素化できるようになります。

一般に、業務のワークロードは、リアルタイムの意思決定ときめ細かい更新の組み合わせです。たとえば、e コマースアプリで複数ステップの購入手続き中に不正行為を特定する場合を考えてみましょう。このような変更はトランザクション単位、つまり、すべてが成功するか、すべてが失敗するかのどちらかである必要があります。また、後続のリクエストが正しいデータを参照できる必要があります。Spanner の ACID トランザクションに対する今回のアップデートにより、アプリケーションは使い慣れた DML を使用して、整合性、スケーラビリティ、可用性を損なうことなく、更新時により多くのデータを処理できるようになります。

高い上限で柔軟性が向上

これまで Spanner では、クエリが 1 回のトランザクションで実行できる変更（DML を使用する場合など）の上限が 80,000 件でした。これは、更新する行数と列数の積に、依存するインデックスを加えたものとして大まかに計算されていました。アプリケーションは、時間の経過とともに、より多くのデータを処理し、新しい機能を提供できるように進化します。こうした進化に伴い、トランザクションのサイズが拡大すると、以前は小さかったトランザクションがこの上限に達する可能性が生じます。

今回のアップデートでは、80,000 件というミューテーション数の上限がトランザクションから個々の DML ステートメントに移行されます。DML ステートメントは、トランザクションレベルの全体的なミューテーション数の上限に影響しなくなります。INSERT、UPDATE、DELETE など、個々の DML ステートメントが生成するミューテーション数が 80,000 件未満である限り、1 つのトランザクションにいくつでも DML ステートメントを含められるようになりました。

主なメリット

大規模なトランザクション: 累積ミューテーション数の上限に準拠するために、DML ステートメントを人為的に分割するのではなく、ビジネス要件に基づいて論理的にグループ化できます。
シームレスな移行: 今回の変更は、既存のすべての Spanner クライアントライブラリと互換性があるため、アプリケーションコードの更新は不要です。

技術的な考慮事項

ロックと中止

1 つのトランザクションに含めることができる DML ステートメントの数が増えた一方で、トランザクションの規模が拡大して実行時間が長くなると、ロックが保持される時間も長くなることに注意が必要です。これにより、ロックの競合やトランザクションの中止が発生する可能性が高まります。トランザクションを簡潔に保つことで、高いパフォーマンスを維持し、リソースの競合を最小限に抑えることができます。

DML と Mutation API

上限の適用は、データを変更する方法によって異なります。

DML ステートメント: 各ステートメント（executeUpdate など）がミューテーション数の上限 80,000 件に対して個別に評価されます。
Mutation API: insert() や update() など、クライアントライブラリのメソッドを使用する場合、ミューテーションは Commit 呼び出し中に提供されます。80,000 件の上限は引き続き、その 1 回の呼び出しに含まれるミューテーションのセット全体に適用されます。

ミューテーション数について

Spanner では、変更されたセル、主キー、セカンダリインデックスの更新を含め、変更の複雑さに基づいてミューテーション数が数えられます。ミューテーションの数え方について詳しくは、こちらのブログをご覧ください。commit されたトランザクションの合計ミューテーション数は、CommitStats の mutation_count を使用して確認できます。mutation_count には、すべての DML ステートメントと commit 呼び出しにわたって、トランザクションの一部であるすべてのミューテーションが含まれます。

Java の実装例

次の例は、新しい上限のロジックで、1 つのトランザクション内で複数の DML ステートメントを実行する方法を示しています。

code_block: <ListValue: [StructValue([('code', 'import com.google.cloud.spanner.DatabaseClient;\r\nimport com.google.cloud.spanner.Statement;\r\nimport com.google.cloud.spanner.TransactionContext;\r\nimport com.google.cloud.spanner.TransactionRunner.Work;\r\n\r\n// Assuming dbClient is your initialized DatabaseClient\r\ndbClient\r\n .readWriteTransaction()\r\n .run(\r\n new Work<Void>() {\r\n @Override\r\n public Void doWork(TransactionContext transaction) throws Exception {\r\n // Each executeUpdate call is evaluated separately against the 80k mod limit.\r\n\r\n // Example 1: Updating specific products\r\n Statement stmt1 = Statement.newBuilder(\r\n "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")\r\n .bind("productId").to(1L)\r\n .build();\r\n transaction.executeUpdate(stmt1); // Verified against 80k limit\r\n\r\n Statement stmt2 = Statement.newBuilder(\r\n "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")\r\n .bind("productId").to(2L)\r\n .build();\r\n transaction.executeUpdate(stmt2); // Verified against 80k limit separately\r\n\r\n // Example 2: Inserting related order data\r\n Statement stmt3 = Statement.newBuilder(\r\n "INSERT INTO OrderItems (OrderId, ItemId, Quantity) VALUES (@orderId, @itemId, @qty)")\r\n .bind("orderId").to(100L)\r\n .bind("itemId").to(1L)\r\n .bind("qty").to(2)\r\n .build();\r\n transaction.executeUpdate(stmt3); \r\n\r\n Statement stmt4 = Statement.newBuilder(\r\n "UPDATE Orders SET LastUpdated = PENDING_COMMIT_TIMESTAMP() WHERE OrderId = @orderId")\r\n .bind("orderId").to(100L)\r\n .build();\r\n transaction.executeUpdate(stmt4); \r\n\r\n return null;\r\n }\r\n });'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde2441d10>)])]>

変更がない点

個々のステートメントの上限: 1 つの DML ステートメントが生成するミューテーション数が 80,000 件を超える場合は、現在と同じエラーが返されます。
その他のトランザクション上限: 最大トランザクションサイズ（バイト単位）など、その他の制約は引き続き有効です。詳細については、こちらをご覧ください。

ベストプラクティス

CommitStats をモニタリングする: CommitStats で返される mutation_count を利用して、処理によって生成される負荷を把握します。
大規模な処理を最適化する: 1 つのステートメント（一括更新など）が上限を超える場合は、パーティション化 DML の使用や、キーによるページ分けを検討します。

Spanner は、ダウンタイムなしでスケールする必要がある業務アプリケーションの選択肢として、信頼性に優れています。ミューテーション数の上限が引き上げられたことで、デベロッパーは Spanner のグローバル規模での整合性を活用して、より大規模なトランザクションを柔軟に実行できるようになります。Spanner を使用して、リスクを抑えつつイノベーションを推進する方法をご確認ください。また、無料トライアルや、月額わずか 54 ドルから利用できる本番環境インスタンスで、実際にお試しいただくこともできます。

外部の関連資料

- スタッフソフトウェアエンジニア、Rajeshwar Vanka

- プロダクトマネージャー、Justin Makeig

Google、2026 年 Gartner® Magic Quadrant™ エンタープライズ AI アシスタント部門のリーダーに選出

Wed, 16 Sep 2026 02:00:00 +0000

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

このたび、新設された 2026 年 Gartner Magic Quadrant エンタープライズ AI アシスタント部門で、Google がリーダーに選出されました。エンタープライズ AI アシスタントの主要ベンダーを対象としたこの包括的な評価において、Google は「ビジョンの完全性」と「実行能力」の両面で「リーダー」のクアドラントに位置付けられました。

Gemini Enterprise は、組織が従業員の日常業務に役立つ安全な AI を直接導入できるよう支援しています。組織内の各チームは、基本的なチャット操作からさらに先に進み、複数ステップのエンドツーエンドワークフローを AI エージェントによって自動化できます。Gemini Enterprise は、会社がすでに使用しているツールやインフラストラクチャと接続し、セキュリティとガバナンスを確保しながら、費用対効果の高い方法で簡単にスケールできます。

Google は、ビジネスユーザーからデベロッパーまで、誰もが AI エージェントと連携してより多くの成果を上げることができる統合プラットフォームの構築を目指してきました。Gartner による今回の評価は、この目標の妥当性を裏付けるものだと考えています。

Google がリーダーに選出された理由

スタンドアロンの AI ツールや新しいプラットフォームが複雑に絡み合う状況の中で、Gemini Enterprise は Google の AI スタック全体を基盤とする統合されたオープンなエージェントプラットフォームとして登場しました。レポートでは、次のような強みが挙げられています。

統合された「AI のフロントドア」: Gemini Enterprise は、エンタープライズ向けのチャットと検索、ファーストパーティとサードパーティのエージェント、ノーコードのエージェントデザイナー、Google Workspace の統合、サードパーティのコネクタをすべて 1 つのプラットフォームに一元化したものであるため、組織は異なる AI ツールを組み合わせる必要がありません。
オープンな接続性: Gemini Enterprise は、Google のエコシステムだけでなく、Microsoft 365、その他のサードパーティソフトウェア、内部のエンタープライズデータソースにまで及ぶ広範な接続性を提供します。このオープンな接続性により、組織は既存のインフラストラクチャと並行して Gemini Enterprise を導入でき、費用のかかるシステムの全面見直しが不要となります。
シンプルな料金体系: Gemini Enterprise は料金モデルがわかりやすく、チャットや検索などの操作は基本 SKU に含まれます。組織は、ユーザーあたりのシートサブスクリプションと従量課金制オプションを選択できます。後者の場合、ユーザーはタスクの途中で割り当て上限に達することなくエージェントワークロードを実行できます。
組み込みのガバナンス: Gemini Enterprise は、追加費用なしですぐに使える堅牢なエージェントガバナンスを提供します。これにより、企業はセキュリティリスクとエージェントの無秩序な増加を抑制しながら、ユーザー、エージェント、データ権限をシームレスに管理できます。
フルスタックの深さと規模: Google の垂直統合型スタックは、グローバルインフラストラクチャ、カスタムシリコン、世界水準のモデル、エンタープライズに対応した安全な基盤を提供します。これらはすべて、セキュリティ、相互運用性、費用を考慮して最適化されています。

レポートの全文は、こちらからダウンロードしてお読みいただけます。

Gemini Enterprise の最新の機能強化でビジョンを推進

この数か月間、Google はプロダクトの大幅な機能強化で Gemini Enterprise をさらに進化させてきました。

業種別ソリューション: 先月、法律と金融サービスに特化したソリューションを公開しました。これらのカスタマイズされたソリューションは、事前構築済みのエージェント、その分野固有のスキル、安全なデータコネクタ、オープンなパートナーエコシステムを備え、迅速なデプロイが可能です。また、Gemini Enterprise の管理されたコントロールプレーン上に構築されているため、規制の厳しい業界でもワークフローを作成、管理できます。
Gemini Enterprise の Google Antigravity: Gemini Enterprise に AI デベロッパーツールが導入され、企業は対象となる Gemini Enterprise ライセンスにより、開発チーム向けに Antigravity や Android Studio などのエージェント型開発ツールを簡単に有効にし、管理コンソール内で完全なガバナンスとオブザーバビリティを維持できるようになりました。
FinOps と費用管理: 新しい FinOps と費用管理機能が先月導入され、組織はより多くの料金オプション、フレキシブル割引プラン、きめ細かい支出管理を通じて AI 支出を最適化できるようになりました。

Gemini Enterprise のお客様も価値を実感

Gartner からこのような評価を受けたことは光栄なことですが、Gartner だけでなく、お客様も実質的な価値を実感しており、それが日々、組織全体にプラスの影響を広げています。

最近のプロダクトの機能強化に対するお客様の声をお聞きください。

「Accenture では、Gemini Enterprise に Antigravity をデプロイすることで、Google Cloud の安全で信頼できる基盤上で、Google DeepMind の優れたテクノロジーをエンジニアに提供しています。運用の複雑さを抽象化することで、開発スピードとエンタープライズグレードのガバナンスのどちらかを選ぶ必要がなくなり、高速なエンジニアリングと革新的な価値をクライアントに提供できるようになりました。」- Accenture Google Business Group、グローバルプラクティスリード、Chetna Sehgal 氏。詳しくはこちらをご覧ください。

「Cleary は、戦略的かつ競争力のある方法で AI をワークフローに組み込むことに取り組んでいます。Google の Gemini Enterprise は、日々の業務で使用する他のツールとシームレスに連携できるため、チームの効率性を高め、クライアントにさらに質の高い成果物を提供できます。」- Cleary Gottlieb、マネージングパートナー、Jeff Karpf 氏。詳しくはこちらをご覧ください。

「金融リサーチエージェントのデザインパートナーとして、Deutsche Bank は、データ保護やガバナンスからチームが日々使用するワークフローまで、規制の厳しい業界の現実を考慮して、この機能の形成を支援してきました。」- Deutsche Bank、技術、データ、イノベーション最高責任者兼取締役、Marie-Jeanne Deverdun 氏。詳しくはこちらをご覧ください。

「Google Cloud と提携して、Gemini Enterprise for Legal を早期に導入できることを嬉しく思います。Google のテクノロジーを統合してワークフローを合理化し、クライアントの将来にとって重要な成果を形作るうえで訴訟担当者をさらにサポートできることを楽しみにしています。」- Williams & Connolly、会長、Joe Petrosinelli 氏。詳しくはこちらをご覧ください。

使ってみる

レポートを読む: 2026 年 Gartner Magic Quadrant エンタープライズ AI アシスタント部門を無料でダウンロードして、詳細な分析をご確認ください。
Gemini Enterprise の詳細を確認: 組織が、管理、接続されたエージェントをすべてのチームにデプロイする方法については、 cloud.google.com/gemini-enterprise をご覧ください。

- Google Cloud プロダクトマーケティング担当バイスプレジデント、Peder Ulander

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 0x7fdde1155490>)])]>

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 0x7fdde15c4ad0>)])]>

この 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

BigQuery の TabFM のご紹介: 予測分析の再定義

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

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

これまで、チャーン、購入意向、不正行為スコアの予測といった企業の予測分析タスクでは、XGBoost、ランダムフォレスト、ディープニューラルネットワーク（DNN）などのライブラリを使用してカスタムモデルを構築する必要がありました。トレーニング、チューニング、デプロイ、再トレーニングという従来のサイクルは効果的ですが、複雑で時間がかかる場合があります。さらに、手動での特徴量エンジニアリング、ハイパーパラメータチューニング、時間と費用のかかるトレーニングといったオーバーヘッドに加え、専門的なデータサイエンススキルが必要となることから、企業は意思決定において予測モデルを十分に活用できていない可能性があります。

この投稿では、BigQuery の TabFM モデルについてお知らせします。Google Research が開発した TabFM は、表形式データの回帰と分類に対応した、最先端の事前トレーニング済み基盤モデルです。コンテキスト内学習（ICL）を使用し、単一の SQL ステートメントを介して、表形式のデータセットに対する高精度な予測を瞬時に提供し、独立したトレーニングとデプロイの手順を不要にします。BigQuery の TabFM は現在プレビュー版です。

TabFM は、以下のようなメリットを BigQuery 分析にもたらします。

ゼロショット予測: モデルのトレーニング、チューニング、アーティファクトのデプロイをスキップします。ラベル付きの過去データと新しい予測テーブルを単一の SQL 関数に渡すだけで、高品質な予測を即座に取得できます。
エージェントアプリケーション向けの予測 ML: ビジネス用途のエージェントを構築する場合、TabFM と BigQuery MCP サーバーを組み合わせることで、予測機能を追加できます。ランタイムやインフラストラクチャを管理する必要はありません。データを入力するだけで予測結果が得られます。
最先端の精度: 複雑なデータセットにおいて、カスタムトレーニングされた既成の従来モデルを上回り、業種別ベンチマークで優れた精度スコアを達成します。
シンプルなデベロッパーエクスペリエンス: BigQuery 上でネイティブに実行され、シンプルな SQL 構文でアクセスできます。欠損値やカテゴリエンコードなどの特徴量化タスクを自動的に処理するため、複雑な特徴量エンジニアリングパイプラインを管理する必要がありません。
スケーラビリティ: BigQuery の分散推論アーキテクチャを使用して、大規模な推論テーブル（最大数百万行）を数分で処理します。

表形式の予測のための主要なモデル

Google の TabFM は、幅広い表形式データにわたり業界トップクラスの精度を実現しています。TabArena ベンチマークの評価において、TabFM のパフォーマンスは、従来の ML モデルと他の表形式基盤モデルの両方を一貫して上回っています。

TabArena の分類（上）と回帰（下）における上位 10 モデルの ELO 評価（↑）。（D）= デフォルト、（T+E）= チューニング + アンサンブル。スコアが高いほど、パフォーマンスが優れていることを示します。

TabFM モデルについて詳しくは、こちらをご覧ください。

BigQuery で TabFM を使ってみる

TabFM の使い方は簡単です。新しい組み込みの SQL 関数である AI.PREDICT と AI.EVALUATE を通じて、直接利用できます。

1. AI.PREDICT で即座に予測結果を取得する予測を行うには、トレーニングデータと予測データを渡す単一のクエリを記述します。モデルは、ターゲットラベルのデータ型に基づいて、タスクが分類問題か回帰問題かを自動的に推論します。

code_block: <ListValue: [StructValue([('code', "-- トランザクションが不正かどうかを分類する\r\nSELECT *\r\nFROM AI.PREDICT(\r\n TABLE `my_project.my_dataset.historical_transactions`, -- トレーニングデータ（コンテキスト内の例）\r\n TABLE `my_project.my_dataset.new_transactions`, -- 予測データ\r\n label_col => 'is_fraud'-- 予測するターゲット列\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde04fb610>)])]>

この例の出力には、予測テーブルの元の列すべてに加えて、予測ラベルと確率の列（predicted_is_fraud など）が含まれます。手動での特徴量エンジニアリングやモデルの作成は不要でした。

2. AI.EVALUATE でモデルを評価するAI.EVALUATE 関数を使用すると、テストセットに対する予測パフォーマンスをすばやく確認できます。これにより、標準的な評価指標を 1 ステップで生成できます。

code_block: <ListValue: [StructValue([('code', "-- 顧客のライフタイムバリュー（LTV）の回帰評価\r\nSELECT *\r\nFROM AI.EVALUATE(\r\n TABLE `my_project.my_dataset.historical_customer_ltv`,\r\n TABLE `my_project.my_dataset.test_customer_ltv`,\r\n label_col => 'ltv'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde36f7e50>)])]>

AI.EVALUATE は、回帰問題に対しては r2_score、mean_absolute_error などの堅牢な指標セットを、分類問題に対しては適合率、再現率、f1 などの指標を返します。

BigQuery の TabFM の仕組み

従来の ML では、モデルパラメータをトレーニングデータセットに適合させる必要があります。これに対し、TabFM ではコンテキスト内学習を使用します。大規模言語モデル（LLM）が少数ショットのプロンプト例からタスクを学習するのと同様に、TabFM はトレーニングテーブルをコンテキスト内の例として読み取り、1 回のフォワードパスでターゲットテーブルに対する予測を生成します。

表形式基盤モデルの演算の複雑さとメモリ使用量に対応するため、BigQuery はデータに対して分散並列推論を実行します。さらに、インテリジェントなトレーニングデータサンプリングと分散実行を使用して、パフォーマンスとリソース使用率を最適化します。これにより、BigQuery はトレーニングデータとして大規模な入力行を処理しながら、数百万行の推論データに対して迅速かつ効率的に予測を実行できます。

ジョブに適したツールを選択

TabFM は、BigQuery に画期的なゼロショット機能を導入し、XGBoost モデルなどの既存のサービスを補完します。TabFM と他のモデルのどちらを選択すべきかは、以下の基準で判断します。

TabFM は、ML の専門知識がなくても迅速かつ高品質な予測分析情報が必要な場合や、過去のデータセットが小規模から中規模である場合、データが頻繁に変更される場合、そして精度を維持するためにモデルを頻繁に再トレーニングする必要がある場合に使用します。また、オンデマンドでの予測分析を必要とする会話型ワークフローやエージェントワークフローにも適しています。
XGBoost のような従来のモデルは、非常に大規模な過去のデータセットがある場合、カスタムハイパーパラメータチューニングを完全に制御する必要がある場合、TabFM の現在の制限を超えるほど特徴量が多い場合、または特徴量の重要度の説明可能性（例: どの入力特徴量が予測に最も貢献したか）が必要な場合に使用します。

予測 ML が簡単に

TabFM が BigQuery にネイティブに統合されたことで、予測 ML は標準の SELECT クエリを実行するのと同じくらい簡単になりました。TabFM により、モデルのトレーニング、チューニング、管理に伴う手作業のオーバーヘッドが排除され、デベロッパー、データサイエンティスト、アナリストは、元データから豊富な予測分析情報を数秒で取得できます。

今すぐ利用を開始するには、一般公開ドキュメントをご覧ください。ご質問やご意見がございましたら、bqml_feedback@google.com までお知らせください。皆様がどのようなものを構築されるのか、楽しみにしております。

- グループプロダクトマネージャー、Vaibhav Sethi

- エンジニアリングマネージャー、Xi Cheng

Spanner への移行: Antigravity CLI で二重書き込みを自動化してサービス停止を最小限に

Mon, 14 Sep 2026 02:10:00 +0000

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

Google のファイナンスエンジニアリングチームは、レガシーデータレイヤーをモダナイズする必要が生じた際、グローバルに分散され、強整合性があり、高可用性機能を備えたマルチモデルデータベースである Spanner を選択しました。しかし、本番環境サービスをオフラインにせずに Spanner に移行することは、エンジニアリング上の大きな課題でした。アプリケーションを担当する社内チームとして、数十のデータアクセスオブジェクト（DAO）にわたって二重書き込みロジックを手動で書き換える必要がありましたが、このプロセスは時間がかかり、人的エラーが発生しやすいものでした。さらに、サービスを停止することなくこれを行うには、コードベース内のすべての DAO にわたって、マルチフェーズの二重書き込みアーキテクチャを実装する必要がありました。

この課題を解決するために、別のアプローチを採用しました。ヘッドレスモードの Antigravity CLI を利用した自動リファクタリングパイプラインを構築したのです。これにより、本番環境の準備を進めるなか、ステージング環境で厳格なデータパリティを維持しながら、移行速度を大幅に向上させることができました。

課題: 二重書き込みによる移行の仕組み

財務上の正確性が不可欠な高スループットの本番環境サービスを移行する場合、単純なカットオーバースクリプトは機能しません。過去のデータのバックフィルと検証がすべて完了するまで、レガシーデータストアと Spanner の両方が同じ書き込みを同時に受信することを確認する必要があります。

移行は、次の 3 つのフェーズに分けて実施しました。

過去のデータのバックフィル: 参照整合性を維持しながら、既存の過去のレコードを Spanner にコピーします。
二重書き込み / 二重読み取りの実装: 移行期間中に、すべての DAO を変更して、プライマリストアと Cloud Spanner の両方にミューテーションを並行して書き込みます。
自動化された API 検証とパリティチェック: RPC トラフィックをインターセプトし、すべての書き込みが両方のストアでバイト単位で同等に完了することをエンドツーエンドで検証します。

アーキテクチャパターンはクリーンですが、Google の規模では、摩擦が生じ始めました。これは、各 DAO に以下が必要なためです。

複雑なドメインモデルを Spanner スキーマ列にマッピングする専用の MutationConverter クラス
二重書き込みブランチの処理とロールバックまたはエラー報告のロジック
疑似時間ソースとテストダブル（FakeTimeSource）を使用して、プライマリと Spanner の両方の書き込みを検証する単体テストのスイート

30 以上の DAO にわたって、同一の高精度なコード変更を手作業で行っていたら、エンジニアリングに数か月を要していたでしょう。

解決策: 標準化されたミューテーションコンバータパターン

自動化パイプラインがクリーンなコードを確実に生成できることを検証するために、まず、分離された MutationConverter インターフェースを中心に DAO リファクタリングパターンを標準化しました。

中核的な DAO ビジネスロジック内に未加工の Spanner テーブル名と列割り当てを直接埋め込むのではなく、Spanner スキーマ変換を専用のコンバータユニットに分離します。

code_block: <ListValue: [StructValue([('code', '// Example of the standardized pattern generated by our pipeline\r\n\r\ntype BpcTransferAmountsMutationConverter interface {\r\n ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n ToUpdateMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n}\r\n\r\ntype bpcTransferAmountsMutationConverterImpl struct {\r\n tableName string\r\n}\r\n\r\nfunc (c *bpcTransferAmountsMutationConverterImpl) ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error) {\r\n if entity == nil {\r\n return nil, errors.New("entity cannot be nil")\r\n }\r\n \r\n // Map domain fields to Cloud Spanner table schema\r\n cols := []string{"TransferId", "AmountCents", "CurrencyCode", "LastModifiedTimestamp"}\r\n vals := []interface{}{\r\n entity.TransferId,\r\n entity.AmountCents,\r\n entity.CurrencyCode,\r\n spanner.CommitTimestamp, // Use Spanner commit timestamps\r\n }\r\n \r\n return spanner.Insert(c.tableName, cols, vals), nil\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde1181310>)])]>

DAO と Spanner SDK（spanner.Mutation）の間に厳格で決定論的なコントラクトを確立することで、AI コーディングエージェントが推論して確実に生成できる正確なターゲット仕様を作成しました。

Antigravity CLI をヘッドレスモードで使用する理由

IDE のインタラクティブな AI チャットインターフェースは、探索的なコーディングには適していますが、コードベース全体にわたる体系的な複数ファイルのコード更新には適していません。エッジケースを見逃さずに、数十のターゲットに繰り返し可能なリファクタリングを適用する必要がある場合は、自動化されたワークフローが必要です。

この問題に対処するため、Antigravity CLI をヘッドレスモード（-p）で実行するオーケストレーションスクリプト（migration_ui.py）を構築しました。

ヘッドレスモードでは、ターミナルのプロンプトに手動で応答しなくても、シェルスクリプト、継続的インテグレーションパイプライン、バックグラウンド自動化ジョブ内で Antigravity を直接実行できます。このアプローチにより、主に 3 つの方法で作業を効率化できました。

決定論的なプロンプトアーキテクチャ: プロンプトをバージョン管理されたエンジニアリングアーティファクトとして扱いました。タイムスタンプのシリアル化、null 可能性の変換、ミューテーションの曖昧さ、FakeTimeSource テストインジェクションなど、Spanner の一般的なエッジケースを処理する正確なルールを、再利用可能なプロンプトテンプレートに直接コード化しました。
バッチ実行と自動検証: オーケストレーションスクリプトが、ターゲット DAO 名を入力として使用し、既存の単一書き込みソースコードとスキーマを取得して、構造規則とともにヘッドレス Antigravity にフィードします。Antigravity は、新しいコンバータ、リファクタリングされた二重書き込み DAO、対応する単体テストを生成します。その後、スクリプトは blaze test を実行します。linter エラーやテストアサーションの失敗が発生すると、エラーログが Antigravity に直接フィードバックされ、自己修正が行われます。
夜間に大規模に実行: ループは無人で実行されるため、エンジニアは 1 日の終わりに 10 個の DAO をキューに入れることができます。朝までに、パイプラインは人間によるコードレビューの準備が整った 10 個のクリーンな変更リストを生成、テスト、検証します。

クラウドエンジニアにとっての成果と重要なポイント

Spanner の分散データベースプリミティブと Antigravity CLI のヘッドレス自動化を組み合わせることで、エンジニアリング組織全体に明確なメリットがもたらされました。

移行作業の大幅な削減: 二重書き込みによる DAO の移行は、以前は広範な手動コーディングとテストが必要でしたが、わずかな時間で完了し、確認されました。
信頼性の高いデータ移行: 生成されたすべての DAO が、テスト済みのまったく同じ MutationConverter パターンに準拠し、Spanner テストダブルに対する自動単体テストを受けたため、広範な移行テスト中も高いデータ忠実度を維持できました。
より価値の高いエンジニアリングに集中: エンジニアは、繰り返しのボイラープレートリファクタリングを回避し、データモデリング、アーキテクチャの復元力、パフォーマンスの最適化に集中する時間を確保できました。

次回のデータベース移行に役立つ 3 つのヒント

まずスキーマ変換を分離する: 移行スクリプトを記述する前に、新しいクラウドデータベース SDK の要件を既存のビジネスロジックから分離する厳密なインターフェース（MutationConverter など）を定義します。AI エージェントは、明確で限定された設計パターンを与えられた場合に、最も効果的に機能します。
インタラクティブなチャットからヘッドレス自動化に移行する: 3～4 個以上のファイルにわたって繰り返しリファクタリングを実行する場合は、スクリプト化されたヘッドレスワークフローにリソースを投入します。プロンプト入力とテスト検証を自動化されたビルドステップとして扱うことで、品質と一貫性を維持できます。
ビルドシステムをガードレールとして機能させる: AI 生成ループをビルドおよびテストハーネス（bazel test または go test）に直接接続します。これにより、デベロッパーがコードを確認する前に、モデルがコンパイルエラーとアサーションエラーを修正できます。

使ってみる

金融システムの移行でも、クラウドネイティブアプリケーションのゼロからの構築でも、Spanner と Antigravity はスケーラブルなソフトウェア開発の基盤となります。

Cloud Spanner を確認する: Spanner の分散アーキテクチャの詳細については、Google Cloud Spanner のドキュメントをご覧ください。
デベロッパー向け Gemini を確認する: AI を活用したコーディングとヘッドレス CLI の自動化がエンジニアリングワークフローにどのように役立つかを、デベロッパー向け Google Cloud AI でご確認ください。

- アプリケーションエンジニア Sachin Mathapati

LLM ワークロードはすべて同じではない: 分類と生成における TPU のパフォーマンスベンチマーク

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

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

大規模言語モデル（LLM）を試験運用版のプロトタイプからエンタープライズ規模の本番環境に移行すると、インフラストラクチャがパフォーマンスの上限とユニットエコノミクスの両方を左右するという重要な事実が明らかになります。多くの標準的なハードウェアベンチマークでは、すべての LLM リクエストが同じようにシリコンに負荷をかけるわけではないという基本的な現実が見過ごされています。

この投稿では、Google Cloud TPU v6e 上で Gemma 3 12B と Gemma 3 27B を比較する包括的なベンチマークテストについて詳しく見ていくことで、「構造的に異なるワークロードを大規模に処理する場合、TPU インフラストラクチャの実際のパフォーマンスはどうなるのか？」というアーキテクチャに関する重要な問題を考えます。

主な結果と提案

ベンチマークの手法を詳しく説明する前に、TPU v6e で Gemma 3 をデプロイするアーキテクトにとって重要なポイントを以下に示します。

生成タスクにおけるパフォーマンスの壁

デコード負荷が高い生成タスクでは、Gemma 3 27B モデルは同時ユーザー数が 64 人を超えるとパフォーマンスの限界に達し、128 人では正規化スループット係数が 4.12 倍で頭打ちになります。一方、12B モデルは最大 8.19 倍までスケールアップします。

提案: 多くの生成を同時実行するワークロードの場合は、12B モデルに縮小するか、27B モデルでレプリカあたりの同時リクエスト数を 64 に制限する厳格な Pod 自動スケーリング制限を設定します。

分類タスクでは互角

プリフィル負荷が高い分類タスクでは、モデルのパラメータサイズの影響が大きく下がります。12B モデルと 27B モデルはどちらも、TPU を飽和させることなく、同様のピークスケーリング（ユーザー 128 人で正規化スループットが約 6.0 ～ 6.4 倍）を達成しています。

提案: 要約や分類のワークフローでは、スループットを低下させることなく、より大規模で高性能なモデルを安全にデプロイできます。平均の --max-num-seqs や --max-model-len は、平均ユーザー負荷とリクエストあたりの平均トークン数に基づいて慎重に維持する必要があります。そうしないと、リクエストのドロップが発生する可能性があります。

壁を回避するための設計

ハードウェアの飽和は、深刻なレイテンシの急増と、リクエストのサイレントドロップアウトとして現れます。これを軽減するには、標準の CPU / メモリスケーリングトリガーに依存しないようにします。代わりに、エンドツーエンド（E2E）レイテンシ指標に基づいてスケールし、積極的な vLLM バケットパディング最適化（VLLM_TPU_BUCKET_PADDING_GAP）を実装してメモリを節約します。

アーキテクチャの構成

推論スタックは、次の 3 つの主な要素に分けることができます。

1. インフラストラクチャ: GKE と TPU

今回のデプロイメントの基盤となったのは、Google Kubernetes Engine（GKE）Autopilot クラスタです。これに、2×2 チップトポロジで構成された単一ホストの TPU v6e ノードプールを接続しました。

2. ソフトウェアとツール: vllm

サービングフレームワークには、vllm-project/tpu-inference を介して vLLM を活用しました。

3. モデル: Gemma 3 12B、27B

今回は、Gemma 3 12B と Gemma 3 27B という 2 つの高性能なオープンウェイトモデルを評価しました。これらのモデルには HuggingFace 経由でアクセスしました。

ワークロード: 分類と生成

すべての LLM リクエストがシステムに同じ負荷をかけるわけではありません。今回は、分類と生成という 2 つの異なるシナリオで、同時ユーザー数が 16 人、32 人、64 人、128 人の場合のベンチマークを実施しました。

分類（高入力、低出力）: このユースケースは、e コマースのコンプライアンスタスクを模倣するものです。プロンプトには、商品ルール、アイテムの説明、OCR で抽出されたテキストの大きなブロックが含まれています。出力は非常に小さく、通常はアイテムを「許可」または「禁止」に分類するだけです。入力シーケンス長（ISL）は約 4,000 トークン、出力シーケンス長（OSL）は約 10 トークンです。
生成（低 / 中入力、高出力）: このユースケースは、長文テキストの生成を模倣するものです。プロンプトでは、労働市場における AI の未来に関する詳細な分析的政策提言書を求めます。モデルは、ほとんどの時間を数百のトークンのデコードとストリーミングに費やします。入力シーケンス長（ISL）は 500 トークン、出力シーケンス長（OSL）は約 1,000 トークンです。

結果と考察

スループット（リクエスト数/秒）、エンドツーエンドのレイテンシなどの指標を測定した結果、パラメータサイズとハードウェア帯域幅の相互作用について興味深い知見が得られました。アーキテクチャの整合性を確保するため、ベンチマークはすべて vllm-project/tpu-inference ハードウェアプラグインを使用して実行され、max-model-len=128000、max-num-batched-tokens=8192、max-num-seqs=512 という標準的なグローバルサービング構成が利用されました。

生成タスクにおけるスケーリングの相違

生成タスクでは、同時ユーザー数が 64 人まで、両モデルのパフォーマンスは同等です。しかし、同時ユーザー数が 128 人になると、Gemma 3 12B モデルのほうが大幅にスケーリングに優れ、正規化スループット係数が 8.19 倍に達します。一方、Gemma 3 27B モデルは 4.12 倍で頭打ちになります（ユーザー数 16 人での Gemma 3 12B のベースラインに対する正規化）。これは、生成負荷が高い状況では、より大規模な 27B モデルのほうが大幅に早くメモリまたはコンピュートの上限に達することを示唆しています。

同時ユーザー数	Gemma 3 12B のスループット（リクエスト数/秒）	Gemma 3 27B のスループット（リクエスト数/秒）
16 人	1.00 倍	1.05 倍
32 人	1.98 倍	1.97 倍
64 人	2.96 倍	4.00 倍
128 人	8.19 倍	4.12 倍

aside_block: <ListValue: [StructValue([('title', '上級者向けのヒント → 同時実行数が多い場合の指標のインフレ'), ('body', <wagtail.rich_text.RichText object at 0x7fdde26b5ed0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

分類タスクにおけるパフォーマンスは互角

分類タスクでは、Gemma 3 12B モデルと Gemma 3 27B モデルのスケーリング動作にほとんど差はありません。どちらのモデルもハードウェアの容量内で効率的に動作し、スケーラビリティに優れています。同時ユーザー数が 128 人の場合、正規化スループットのピークは約 6.04～6.37 倍に達します（ユーザー数 16 人での Gemma 3 12B のベースラインに対する正規化）。

同時ユーザー数	Gemma 3 12B のスループット（リクエスト数/秒）	Gemma 3 27B のスループット（リクエスト数/秒）
16 人	1.00 倍	0.76 倍
32 人	1.18 倍	1.53 倍
64 人	2.04 倍	3.15 倍
128 人	6.37 倍	6.04 倍

レイテンシしきい値の分析

エンドツーエンド（E2E）のレイテンシは、モデルのサイズとタスクによって異なるスケーリング動作を示します。同一のサービングハイパーパラメータ（--max-num-seqs=512）を使用した場合、Gemma 3 12B モデルにおける分類タスクのレイテンシは、ユーザー数が 32 人から 64 人に増えると約 2 倍になり、リソースの競合が発生していることを示します。これに対して、より大規模な Gemma 3 27B モデルでは、分類タスクのレイテンシはユーザー 32 人から 64 人の間で比較的横ばいであり、ユーザー 128 人で 2 倍になります。

モデル	タスク	16 人	32 人	64 人	128 人
Gemma 3 12B	生成	1.00倍	1.13倍	1.40倍	1.70倍
Gemma 3 12B	分類	1.00倍	0.99倍	1.79倍	2.90倍
Gemma 3 27B	生成	1.20倍	1.68倍	2.93倍	3.33倍
Gemma 3 27B	分類	1.20倍	1.95倍	1.95倍	3.88倍

aside_block: <ListValue: [StructValue([('title', '重要な TPU 最適化手法'), ('body', <wagtail.rich_text.RichText object at 0x7fdde0ab4110>), ('btn_text', ''), ('href', ''), ('image', None)])]>

まとめ

Google Cloud TPU v6e アーキテクチャで Gemma 3 12B モデルと 27B モデルのベンチマークを実施した結果、推論パフォーマンスの予測因子は、生のパラメータ数だけではないことがわかりました。むしろ、サービングフレームワーク、ハードウェアトポロジ、ワークロードトークン比率の相互作用が効率を左右します。生成タスク（低入力、高出力）では、同時実行数が多い場合、12B モデルのほうが優れていることが実証されました。12B モデルは 8.19 倍の相対スループット係数を維持する一方、27B モデルは 4.12 倍で飽和しました。これに対して、プリフィル負荷が高い分類タスクでは、両モデルのパフォーマンスが同等であるため、組織はスケーリングを大幅に損なうことなく、より大規模なモデルをデプロイできます。今回の評価では、ハードウェアの飽和しきい値を正確にマッピングしました。たとえば、分類ではユーザー 64 人でエンドツーエンドのレイテンシが 2 倍になり、生成ではユーザー 128 人で急激に増加します。この結果をもとに、コストをかけてオーバープロビジョニングを行うのではなく、データドリブンな自動スケーリングトリガーを正確に設定できます。最終的に、これらのピーク指標を達成するには、vLLM のパラメータを積極的にチューニングする必要があります。たとえば、バッチ処理を行うトークンの調整や、TPU 固有のバケットパディングの構成によって、コンピュートの無駄を防ぎます。これは、AI インフラストラクチャの費用対効果を高めるためには、本番環境ワークロード固有の入出力プロファイルにモデルの選択とサービング構成を厳密に合わせる必要があることを実証しています。

LLM ワークロードをスケールするために

最適化されていないインフラストラクチャが、エンタープライズ AI の展開のボトルネックにならないようにしましょう。さまざまなワークロードの形状がハードウェアの飽和にどのように影響するかを理解したところで、これらの知見を実践に活かしましょう。

今回のベンチマークを使用して本番環境アーキテクチャのサイズを適正化します。プリフィル負荷が高い分類タスクには、スループットを低下させることなく、より大規模な Gemma 3 27B を安全に活用できます。一方、デコード負荷が高い生成タスクを高い同時実行数で処理する場合は、線形スケーリングを維持するために 12B モデルへの切り替えを検討してください。
TPU v6e ノードプールを備えた Google Kubernetes Engine（GKE）を使用してデプロイし、スケーラビリティに優れたマネージド AI 基盤と専用の vllm-project/tpu-inference ハードウェアプラグインを構築します。また、Gemini Enterprise Agent Platform の Model Garden を介してデプロイすることも、Gemma 3 モデルのサービング用に TPU VM をスピンアップすることもできます。

本番環境へのデプロイで、同様のパフォーマンスの壁にぶつかったことはありませんか？Google Cloud コミュニティフォーラムで、スケーリング戦略を共有し、質問を投稿し、ディスカッションに参加してください。

- AI エンジニア Rupjit Chakraborty

Google Gen AI SDK for Kotlin 1.0 の発表: Gemini への慣用的なマルチプラットフォームアクセス

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

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

Kotlin アプリケーションに最新の生成 AI 機能を統合するのに、低レベルな HTTP クライアントを操作したり、異なる Java ライブラリを連携させたりする必要はありません。このたび、Google Gen AI SDK for Kotlin（google-genai-kotlin）のリリース 1.0 が公開されました。GitHub の googleapis/kotlin-genai で、コードを詳しく調べ、実行可能なサンプルを試し、プロジェクトにスターを付けることができるようになっています。

Kotlin マルチプラットフォーム（KMP）ライブラリとしてゼロから構築されたこの SDK は、JVM（バックエンドサービス、サーバーレス関数、デスクトップ）と Android の両方をターゲットとするデベロッパーに、慣用的な Kotlin パラダイム（ファーストクラスのコルーチン、非同期 Flow ストリーミング、名前付きパラメータとデフォルトパラメータを持つ不変データクラスなど）を提供します。

この SDK では、Gemini Developer API（Google AI Studio）と Gemini Enterprise Agent Platform（Google Cloud）の両方を操作するための統合サーフェスが提供され、構成の調整は最小限で済みます。

1. はじめに: 依存関係を追加する

SDK は、Maven Central の com.google.genai:google-genai-kotlin で公開されています。

Kotlin マルチプラットフォーム（KMP）

マルチプラットフォームアプリケーションの場合は、commonMain ソースセットに依存関係を追加します。

code_block: <ListValue: [StructValue([('code', '// build.gradle.kts\r\nkotlin {\r\n sourceSets {\r\n commonMain.dependencies {\r\n implementation("com.google.genai:google-genai-kotlin:1.0.0")\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde03d4750>)])]>

標準の JVM プロジェクト

単一プラットフォームの Kotlin プロジェクトの場合、Gradle は Gradle Module Metadata を介して最適なバリアントを自動的に選択します。

code_block: <ListValue: [StructValue([('code', '// build.gradle.kts\r\ndependencies {\r\n implementation("com.google.genai:google-genai-kotlin:1.0.0")\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de6110>)])]>

2. 単項およびストリーミングのテキスト生成とチャット

プライマリエントリポイントは Client クラスです。環境変数（Google AI Studio の場合は GEMINI_API_KEY または GOOGLE_API_KEY、標準の Google Cloud アプリケーションのデフォルト認証情報の場合は GOOGLE_GENAI_USE_ENTERPRISE=true）に基づいて、HTTP 接続と認証を自動的に管理します。

Gemini Flash を使用した単一プロンプトリクエスト

Kotlin の use 拡張機能を使用すると、クライアントの基盤となるネットワークエンジンと HTTP 接続が確実に解放されます。

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val response = client.models.generateContent(\r\n model = "gemini-flash-latest",\r\n text = "Explain quantum entanglement in two sentences."\r\n )\r\n\r\n println(response.text)\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de5110>)])]>

コルーチン Flow による低レイテンシストリーミング

インタラクティブな UI やレスポンシブな CLI ツールの場合、generateContentStream はコールド Kotlin コルーチン Flow<GenerateContentResponse> を返し、トークンチャンクをリアルタイムで提供します。

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val responseFlow = client.models.generateContentStream(\r\n model = "gemini-flash-latest",\r\n text = "Outline the key architectural patterns for microservices on Google Cloud."\r\n )\r\n\r\n responseFlow.collect { chunk ->\r\n chunk.text?.let { print(it) }\r\n }\r\n println()\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de7a90>)])]>

マルチターンの会話（チャット）

リクエストターンをまたいで会話履歴を手動で管理するのは煩雑な作業になることがあります。SDK には、コンテキストの維持、ターンの追加、会話履歴のフォーマット、関数呼び出しの処理を自動的に行う専用の chats サービスが含まれています。

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport com.google.genai.kotlin.types.Content\r\nimport com.google.genai.kotlin.types.GenerateContentConfig\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val config = GenerateContentConfig(\r\n systemInstruction = Content.fromText("You are an expert Google Cloud Solutions Architect.")\r\n )\r\n\r\n // Create a multi-turn chat session\r\n val chat = client.chats.create(\r\n model = "gemini-flash-latest",\r\n config = config\r\n )\r\n\r\n // Turn 1\r\n val firstResponse = chat.sendMessage("We are designing an event-driven ingestion pipeline on Google Cloud.")\r\n println("Gemini: ${firstResponse.text}\\n")\r\n\r\n // Turn 2: context from the first turn is included automatically\r\n val secondResponse = chat.sendMessage("Which managed messaging service should we choose: Pub/Sub or Kafka?")\r\n println("Gemini: ${secondResponse.text}\\n")\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de6150>)])]>

chat.sendMessageStream(...) を使用して、マルチターンチャットレスポンスをストリーミングすることもできます。

3. Google 検索でグラウンディングされたマルチモーダル分析

Gemini のマルチモーダル推論は、外部検証と組み合わせると特に効果的です。たとえば、技術、医療、科学に関する図を分析する場合、Google 検索のグラウンディングをアタッチして、事実に基づく主張をライブのウェブソースと照合できます。

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport com.google.genai.kotlin.types.*\r\nimport java.io.File\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val imageBytes = File("src/main/resources/medical_diagram.png").readBytes()\r\n\r\n val content = Content(\r\n parts = listOf(\r\n Part(inlineData = Blob(mimeType = "image/png", data = imageBytes)),\r\n Part(text = "Is this anatomical diagram accurate? Verify labels against authoritative medical sources.")\r\n )\r\n )\r\n\r\n // Enable Google Search as a grounding tool\r\n val config = GenerateContentConfig(\r\n tools = listOf(Tool(googleSearch = GoogleSearch()))\r\n )\r\n\r\n val response = client.models.generateContent(\r\n model = "gemini-flash-latest",\r\n content = content,\r\n config = config\r\n )\r\n\r\n println("=== Analysis ===")\r\n println(response.text)\r\n\r\n // Inspect citations and search queries\r\n val grounding = response.groundingMetadata\r\n println("\\n=== Search Queries Executed ===")\r\n grounding?.webSearchQueries?.forEach { println("- $it") }\r\n\r\n println("\\n=== Grounding Sources ===")\r\n grounding?.groundingChunks?.mapNotNull { it.web }?.forEach { source ->\r\n println("- ${source.title}: ${source.uri}")\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de63d0>)])]>

4. ビジュアル生成と会話型編集: Gemini 3 画像ファミリー

この SDK は、Google の最新の画像生成モデル（リーダーボードでは Nano Banana シリーズのモデルとして広く知られています）を完全にサポートしています。

画像の生成と保存

生成された画像バイトは、レスポンスの一部で Blob として直接提供されます。

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport java.io.File\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val response = client.models.generateContent(\r\n model = "gemini-3.1-flash-image", // Nano Banana 2\r\n text = "A photorealistic blueprint of an eco-friendly modern datacenter, isometric view, 4k"\r\n )\r\n\r\n val imagePart = response.parts?.firstOrNull { it.inlineData != null }\r\n imagePart?.inlineData?.data?.let { bytes ->\r\n File("datacenter_blueprint.png").writeBytes(bytes)\r\n println("Image generated and saved successfully.")\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de53d0>)])]>

画像から画像への会話型編集

同じリクエストで、既存の画像と会話型の編集指示を渡すことができます。

code_block: <ListValue: [StructValue([('code', 'val originalImage = File("input.png").readBytes()\r\n\r\nval editPrompt = Content(\r\n parts = listOf(\r\n Part(inlineData = Blob(mimeType = "image/png", data = originalImage)),\r\n Part(text = "Change the daylight illumination to a dramatic twilight skyline with illuminated windows.")\r\n )\r\n)\r\n\r\nval editResponse = client.models.generateContent(\r\n model = "gemini-3-pro-image", // Nano Banana Pro\r\n content = editPrompt\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de7810>)])]>

5. Gemini Live とのリアルタイムの双方向インタラクション

低レイテンシの音声、オーディオ、ライブのマルチモーダルインタラクションの場合、SDK は client.live.connect(...) を使用した永続的な WebSocket 接続を介して Gemini Live API をサポートします。

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport com.google.genai.kotlin.types.AudioTranscriptionConfig\r\nimport com.google.genai.kotlin.types.LiveConnectConfig\r\nimport kotlinx.coroutines.launch\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val model = if (client.enterprise) "gemini-live-2.5-flash-native-audio"\r\n else "gemini-3.1-flash-live-preview"\r\n\r\n val config = LiveConnectConfig(\r\n outputAudioTranscription = AudioTranscriptionConfig()\r\n )\r\n\r\n // Establish real-time bidirectional WebSocket session\r\n client.live.connect(model, config).use { session ->\r\n println("Connected to Gemini Live session!")\r\n\r\n // Launch collector for server messages (audio and text transcriptions)\r\n val receiveJob = launch {\r\n session.receive().collect { serverMessage ->\r\n serverMessage.serverContent?.outputTranscription?.text?.let { text ->\r\n print(text)\r\n }\r\n }\r\n }\r\n\r\n // Stream real-time text (or raw PCM audio blobs via session.sendRealtimeInput(audio = ...))\r\n session.sendRealtimeInput(text = "Hello Gemini! Give me a 5-second motivational quote.")\r\n\r\n // When finished, clean up\r\n receiveJob.cancel()\r\n session.closeSession()\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de5a90>)])]>

6. 構造化されたツールと関数呼び出し

エージェントワークフローを構築する場合や、LLM をバックエンドマイクロサービスと連携させる場合、デベロッパーは FunctionDeclaration を介して構造化 JSON スキーマを渡すことができます。モデルは、ツールを呼び出すタイミングをインテリジェントに選択します。

code_block: <ListValue: [StructValue([('code', 'val telemetryTool = FunctionDeclaration(\r\n name = "getDatacenterMetrics",\r\n description = "Fetch real-time CPU and thermal telemetry for a Google Cloud region",\r\n parameters = Schema(\r\n type = Type.OBJECT,\r\n properties = mapOf("region" to Schema(type = Type.STRING)),\r\n required = listOf("region")\r\n )\r\n)\r\n\r\nval response = client.models.generateContent(\r\n model = "gemini-flash-latest",\r\n text = "Check telemetry for europe-west1",\r\n config = GenerateContentConfig(\r\n tools = listOf(Tool(functionDeclarations = listOf(telemetryTool)))\r\n )\r\n)\r\n\r\nresponse.functionCalls?.firstOrNull()?.let { call ->\r\n println("Model triggered tool: ${call.name} with arguments: ${call.args}")\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de4190>)])]>

さらに、チャットサービスを使用する場合は、自動関数呼び出し（AFC）を利用できます。つまり、次の例に示すように、チャットの会話で宣言された関数を、SDK がユーザーに代わって自動的かつ透過的に呼び出すことができます。

code_block: <ListValue: [StructValue([('code', 'fun main() = runBlocking {\r\n // A mocked function\r\n val getWeather = callableFunction("get_weather", paramName = "city") { city: String ->\r\n "18 degrees and sunny in $city"\r\n }\r\n\r\n Client().use { client ->\r\n val chat = client.chats.create(\r\n model = "gemini-flash-latest",\r\n automaticFunctionCalling = AutomaticFunctionCalling(getWeather),\r\n )\r\n\r\n // SDK calls get_weather if needed in this conversation\r\n println(chat.sendMessage("What is the weather in Zurich?").text)\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0de7e10>)])]>

次のステップ

Google Gen AI SDK for Kotlin のリリース 1.0 により、バックエンドサーバーエコシステム（Ktor、Spring Boot、Quarkus、Micronaut）とモバイルアプリケーションの Kotlin デベロッパーは、生成 AI アプリケーションを構築するためのクリーンなマルチプラットフォーム基盤を手に入れました。

詳細と利用方法については、以下のリソースをご覧ください。

GitHub リポジトリ: ソース、スター、ディスカッションは github.com/googleapis/kotlin-genai でご確認ください。
ドキュメントとサンプル: Kotlin 生成 AI サンプルスイートをご覧ください。
フィードバック: 問題の報告、機能の提案、pull リクエストの送信を GitHub で直接行っていただけます。

Kotlin と Gemini を使用して、皆様がどのようなものを構築されるか楽しみにしております。

- デベロッパーアドボケイト、Guillaume Laforge

BigQuery の新しい ID 列でパイプラインを簡素化

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

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

お客様のデータジャーニーをさらに支援するため、このたび、BigQuery の ID 列のリリースを発表いたしました。この新機能により、ユーザーは連続する 64 ビット整数値を自動的に生成する列を定義できるため、テーブル内の一意の識別子の管理方法を簡素化できます。

データエンジニアは、データの取り込みをよりスムーズかつ信頼性の高いものにする方法を常に模索しています。BigQuery の ID 列は、テーブルに一意の数値を自動的に生成する強力な組み込みメカニズムを提供します。ID 生成の責任を BigQuery に移すことで、データパイプラインの複雑さを大幅に軽減し、分析情報の提供に集中できるようになります。

データパイプラインにとっての主なメリット

ID 列を実装すると、データアーキテクチャの開発とメンテナンスの効率化に役立つ、いくつかの利点が得られます。

取り込みの合理化: アプリケーションロジックや ETL ツールで一意のキーを事前に計算する必要なく、データを取り込めるようになります。
ボイラープレートの削減: 自動生成されたシーケンスを使用することで、データベースでキー管理がネイティブに処理されるため、SQL コードがよりクリーンになり、メンテナンスしやすくなります。
自動化の統合: ID 列は標準の DML オペレーションとスムーズに連動し、新しい行ごとに一意の識別子が自動的に割り当てられます。
柔軟な統合: INSERT ステートメントと MERGE ステートメントのどちらを使用している場合でも、ID 列は既存のワークフローに適応します。

ID 列を実装する方法

ID 列の設定は簡単で、CREATE TABLE ステートメント内で直接行うことができます。これらの値の処理方法を定義するには、主に 2 つの方法があります。

定義のオプション

句	説明
`GENERATED ALWAYS AS IDENTITY`	BigQuery が値の一意性を自動的に管理、保証します。
`GENERATED BY DEFAULT AS IDENTITY`	自動生成された値が提供されますが、必要に応じて手動でオーバーライドすることもできます。

使用例次の SQL ステートメントは、ID を自動的にインクリメントするテーブルを作成する方法を示しています。ID は 1 から始まり、新しいエントリごとに 1 ずつ大きい値になります。

code_block: <ListValue: [StructValue([('code', "CREATE TABLE my_project.my_dataset.orders (\r\n order_id INT64 GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1),\r\n customer_name STRING,\r\n order_date DATE\r\n);\r\n\r\n-- Ingesting data is now simpler:\r\nINSERT INTO my_project.my_dataset.orders (customer_name, order_date)\r\nVALUES ('Joe Doe', CURRENT_DATE());"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0590210>)])]>

使ってみる

ID 列は、柔軟性とパフォーマンスが高く、標準に準拠したデータプラットフォームを提供するという Google の継続的な取り組みを象徴するものです。サロゲートキーの生成を自動化することで、スケーラブルでメンテナンスしやすいデータアーキテクチャを簡単に構築できるようにしています。

プロジェクトにこの機能を実装する方法の詳細については、BigQuery の ID 列に関するドキュメントをご覧ください。

- プロダクトマネージャー Wawrzek Hyska

- ソフトウェアエンジニア Aayush Bhatnagar

Google、2026 年 Gartner® Magic Quadrant™ で戦略的クラウドプラットフォームサービス部門のリーダーに選出

Thu, 10 Sep 2026 17:00:00 +0000

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

Gartner® は、Gartner Magic Quadrant™ で戦略的クラウドプラットフォームサービス部門のリーダーとして Google を選出しました。これで、Google は 9 年連続で選出されたことになります。また、Google は「ビジョンの完全性」において最高評価を獲得しました。

この評価は、お客様が Google Cloud 上で極めて要求の厳しいワークロードを確実かつセキュアに構築、スケールできるよう支援してきた、Google の長年にわたる取り組みが認められたものだと考えています。エージェントの時代を迎え、Google は動的なインフラストラクチャで企業の取り組みを加速させ、エンタープライズアプリ、データ、エージェントを単一の柔軟なプラットフォーム上で接続して、予測可能な費用とパフォーマンスを実現しています。

この勢いを後押ししているものは何でしょうか。Google Cloud を際立たせている、3 つの大きな利点があります。

共同設計された統合技術スタック: カスタムシリコンとハードウェアシステム、オープンソフトウェアとオーケストレーション、フロンティアモデルとエージェントアプリケーションにわたる技術スタックです。
動的なインフラストラクチャ: あらゆる場所でユーザー、データ、アプリ、エージェントをセキュアに接続し、スケールできます。
真の選択肢があるデジタル主権: 組織はクラウドの重要な機能を犠牲にすることなく、データを完全に制御できます。

Google は、お客様が必要とする柔軟性、パフォーマンス、制御を提供しながら、大規模なイノベーションとデリバリーを実現できるよう支援しています。Google Cloud がインフラストラクチャを構築、強化し続けるうえで重視している 3 つの設計原則を詳しくご紹介します。

1. ロックインのない共同設計スタックで AI を加速

Google Cloud は、シリコンからエージェントアプリケーションまで、綿密に共同設計された完全なファーストパーティ AI スタックを提供する唯一のプロバイダです。Google のインフラストラクチャチームは、Google DeepMind の研究者と協力して、技術スタックのあらゆるレイヤを共同設計し、最適化しています。Google TPU や Arm ベースの Google Axion プロセッサなどのカスタムシリコンから、Google Kubernetes Engine（GKE）や Gemini モデルまで、Google のシステムは優れたパフォーマンスと予測可能な費用を実現しています。

ハードウェアとソフトウェアを共同設計することで、運用効率が大幅に向上しますが、これは閉じたエコシステムを構築することを意味するものではありません。Google は、分散推論用の llm-d などのフレームワーク、GKE Prism によるオープンモデルのベンチマーク、TPU と GPU の間で PyTorch 互換を実現する TorchTPU によるハードウェアロックインの排除など、スタックのあらゆるレイヤでオープンソースとオープンスタンダードに深く取り組んでいます。モデル、フレームワーク、シリコンを完全に自由に選択しながら、垂直方向に共同設計されたスタックの機能を最大限に活用できます。これらの緊密に統合されたすべてのコンポーネントを組み合わせることは、優れたスケール、パフォーマンス、効率性を可能にする AI Hypercomputer を構築することを意味します。これは、世界の AI ラボの上位 10 社中 9 社が選んだインフラストラクチャ基盤と同じものです。

2. 動的なインフラストラクチャで迅速かつ経済的にスケーリング

現在、AI リソースの需要は急増しています。Google 内では、データセンターで毎月 3,200 兆個のトークンが処理されており、これは昨年の約 7 倍に相当します1。この変化を乗り切ろうとする企業のリーダーにとって、AI システムのスケーリングは、設計が難しく、リソースを大量に消費し、バースト性があることで知られています。そのため、スケーリングのボトルネックや、十分に活用されていないコンピューティングプールの肥大化につながる可能性があります。

組織は、容量管理を自動化し、独自のペースでビジネスアプリケーションをモダナイズし、データ、アプリ、エージェントを安全に接続して、最適化されたグローバルエクスペリエンスを推進するための動的なインフラストラクチャを必要としています。

エージェント規模で成功するには、単一のシステムとして運用できるインフラストラクチャが必要です。Google Cloud のメリットは以下のとおりです。

Gemini を活用したツールを使用して、コアアプリのマッピングとモダナイゼーションをインテリジェントに行い、静的なレガシーシステムを AI とエージェントの動的な基盤に変換することで、AI 変革を推進 できます。
ワークロードに最適化された幅広いコンピューティングの種類と構成から選択できます。事前定義されたカスタムの CPU シェイプ、NVIDIA GPU、Google カスタムシリコン（TPU と Axion CPU）を組み合わせることができます。これらは、AI ワークロードとエンタープライズワークロードで優れた費用対効果をもたらすように設計されています。
Google Kubernetes Engine を使用して、単一の柔軟なコントロールプレーンでエンタープライズと AI インフラストラクチャを接続できます。これには、計画されたイベントの容量を事前にスケジュールする Dynamic Workload Scheduler や、リソースの消費方法を指示する高度なルールを定義する動的リソース割り当てなどの容量管理機能が含まれ、使用率の最大化と費用の削減に役立ちます。
Gemini Cloud Assist を使用して、新しいエージェントベースのワークフローの運用上の問題をプロアクティブに特定、トラブルシューティング、解決することで、Day 2（2 日目からの）運用を簡素化できます。
最後に、Cross-Cloud Interconnect を使用して、ハイブリッド環境とマルチクラウド環境でワークロードを実行できます。Google の 1,000 万キロメートルを超えるプライベートファイバーバックボーンを活用することで、パブリックインターネットルーティングよりも最大 40% 高いパフォーマンスがもたらされます。また、自動化されたデリバリーが数分で行われます2。

動的なインフラストラクチャ、適応型アプリケーション、応答性の高いシステムの統合された基盤を採用することで、組織は、この新しいテクノロジーの最前線をリードするために必要な、復元力に優れた高パフォーマンスのインフラストラクチャを確立できます。

3. 選択肢の拡大とセキュリティの強化でデジタル主権を確立

モダナイゼーション、最先端の AI 機能、規制管理のいずれも妥協すべきではありません。Google の Sovereign Cloud では、3 つの柔軟なデプロイオプションにより、ソブリンプラットフォーム間で Gemini とオープンウェイトモデルにアクセスできます。

データ主権と制御: Google Cloud Data Boundary を使用して、データの場所と暗号化権限を完全に制御できます。Key Access Justifications（KAJ）とともに外部鍵管理（EKM）を使用して、Google インフラストラクチャの外部で暗号鍵を管理しながら、Google Cloud と Google Workspace の両方で地理的な処理とストレージの境界を正確に適用します。
地域のコンプライアンスとリージョンオペレーション: 欧州のお客様向けに Google Cloud Dedicated で構築され、地域のパートナーが独占的に運用する物理的および論理的に分離されたリージョンクラウドでアプリケーションを実行します。フランスでは、S3NS が PREMI3NS を提供しています。これは、フランス情報システムセキュリティ庁（ANSSI）から SecNumCloud 3.2 認証を取得したスタンドアロンソブリンクラウドです。Thales が運用する専用のソブリンクラウドオペレーションも、ドイツで近日中に提供される予定です。
オンプレミスとエアギャップの柔軟性: Google Distributed Cloud（GDC）を介して、Google Cloud の機能をオンプレミス環境に直接導入できます。GDC には、2 つの異なるデプロイモードがあります。エアギャップ モードは、公共部門、防衛、規制対象企業のワークロード向けに、公共のインターネットに接続せずに運用される、フルマネージドの自己完結型環境です。接続モードでは、Google Cloud の一元化されたコントロールプレーンを活用して統合管理を行いながら、独自のハードウェア上でワークロードをローカルに実行できます。

クラウドへの移行を加速する

コアエンタープライズシステムのモダナイズから、複雑なコンプライアンス要件の管理、自律型 AI エージェントのデプロイまで、Google Cloud は、成功に必要なパフォーマンス、スケール、選択の自由を提供します。

詳しくは、2026 年 Gartner Magic Quadrant 戦略的クラウドプラットフォームサービス部門の全文をご覧いただくか、AI Hypercomputer のページをご確認ください。

^{1. Sundar Pichai、I/O 2026: Welcome to the agentic Gemini era（I/O 2026: エージェント型 Gemini の時代へようこそ）The Keyword、Google、2026 年 5 月 19 日2. テストでは、ターゲットへのトラフィックがクロスクラウドネットワークを経由した場合、パブリックインターネットを経由した場合と比較して、同じターゲットへのトラフィックのネットワークレイテンシが 40% 以上短縮されました。}

- Google Cloud Platform、バイスプレジデント兼ゼネラルマネージャー、Brad Calder

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

数週間から数分へ: データパイプラインの新たなエージェント時代

Thu, 10 Sep 2026 16:00:00 +0000

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

データパイプラインは現代の企業のバックボーンですが、オーケストレーションには参入障壁があり、多くのデータ専門家がこの重要な機能を利用できない状況にあります。Google Cloud NEXT ’26 での発表で Orchestration Pipelines フレームワークを紹介したことで、この状況は根本的に変わろうとしています。

この強力なフレームワークを実務担当者に直接提供するため、Google は Data Agent Kit を提供しています。これは、データエンジニアリングとデータサイエンスのツールを統合した、自由に利用できるオープンソースのコレクションで、お好みの IDE や CLI（VS Code、Claude Code、Codex など）に直接統合できます。

Data Agent Kit は、Orchestration Pipelines フレームワークを 2 つの異なる方法でワークフローにシームレスに組み込みます。まず、包括的なパイプライン管理のための専用の [データエンジニアリング] タブが用意されています。2 つ目は、自然言語を使用して本番環境グレードの Apache Airflow® DAG を作成、デプロイ、トラブルシューティングできるように設計された、専門的なエージェントスキルです。

これらの専門的なエージェントスキルを宣言型の YAML DSL と組み合わせることで、アナリストから ML エンジニアまで、あらゆるデータ担当者が複雑な Python Airflow ボイラープレートを回避できます。このフレームワークは、高レベルのオーケストレーションロジックを基盤となるコンピューティング実行から切り離し、データ組織全体で強力な MLOps 機能へのアクセスを民主化します。

この投稿では、MLOps の模範的なユースケースを例に、これを簡単に実現する方法を説明します。

環境設定

最初のオーケストレーションパイプラインを作成する前に、ローカル開発環境を設定する必要があります。2 分もかからずに開始できます。

1. 拡張機能をインストールして構成する

VS Code、VS Code フォーク、Antigravity、Claude Code、Antigravity CLI、Codex など、お好みの IDE または CLI に拡張機能をインストールし、Google Cloud アカウントで認証するには、公式ドキュメントの Google Cloud Data Agent Kit インストールガイドに記載されている手順に沿って設定します。

2. オーケストレーションパイプラインのスキルを確認する

インストールしたら、必要なエージェントスキルが有効になっていることを確認します。

VS Code アクティビティバーで [Google Cloud Data Agent Kit] パネルを開きます。
[設定] > [スキル] の順に移動します。
「gcp-pipelines-orchestration」スキルが有効になっていることを確認します。

このスキルにより、エージェントは、パイプライン構文、変数置換、シークレット管理、Airflow 実行の自動インシデント診断に関する深い背景知識を得ることができます。

3. 最初のパイプラインを構築する

自然言語プロンプトを使用して、VS Code 互換の IDE 内で直接オーケストレーションパイプラインの作成、構築、検証を開始するには、公式の構築ガイド（パイプライン構築ガイド）をご覧ください。

ビジネス上の問題の例: プロアクティブなサプライチェーン管理

ビジネス上の問題の例を見ていきましょう。物流および小売業界では、顧客満足度は正確な配達予定に左右されます。注文が予告なく遅延すると、顧客離れが急増し、サポート費用が膨らむ可能性があります。

これに対処するため、倉庫の場所、顧客の場所、注文の特性に基づいて正確な配送日数（日数単位）を予測するエンドツーエンドの MLOps アーキテクチャを構築しています。出荷前にこうした遅延を予測することで、運用チームはサービスレベル契約（SLA）に違反する前に、顧客に事前に通知したり、配送レベルを自動的にアップグレードしたりできます。

このアーキテクチャを完全に再現可能にするため、BigQuery の一般公開データセットである bigquery-public-data.thelook_ecommerce を使用します。デモの目的上、この静的データセットをトレーニングセットと推論セットに分割します。実際のシナリオでは、推論は新たに入ってくるデータに対して行われます。このデータセットは、実際の運用上の複雑さを提供します。

地理データ: 顧客の住所（users）と配送センター（distribution_centers）の緯度と経度。
時間データ: 注文ライフサイクルの詳細なタイムスタンプ（created_at、shipped_at、delivered_at）。
注文属性: 商品カテゴリ、価格、フルフィルメントステータス（orders、order_items）。

このデータセットを BigQuery、Managed Service for Apache Spark サーバーレス、Gemini Enterprise Agent Platform、dbt と組み合わせることで、トレーニング、毎日のバッチ推論、モデルドリフト評価を処理する、自動化された自己修復型の MLOps ループを構築する方法を実証します。

エージェントワークフロー: プロンプトからパイプラインまで、わずか数分で

拡張機能を構成すると、DAG 作成用のボイラープレート Python を完全にバイパスできます。VS Code 内で Data Agent Kit チャットを開き、単一の自然言語プロンプトを入力するだけで、継続的な MLOps フィードバックループを定義しました。

注: 詳細なプロンプトは、このブログ投稿のために、再現性を考慮して作成されました。実際のシナリオでは、パイプラインごとに、より会話調で同じ結果を達成できます。完全なプロンプトと生成されたすべてのファイルは、Orchestration-pipelines GitHub リポジトリで入手できます。

注: Orchestration Pipelines スキルを備えたフロンティアモデルは、多くの場合、1 ステップで完全なワークフローを骨組みを作成できますが、LLM のレスポンスは、モデルのバージョン、ワークスペースのコンテキスト、トークンの深さによって当然異なります。最初のパスで特定のパラメータ、データセットパス、依存関係が省略された場合は、短いフォローアッププロンプトを入力します。

数分以内で、Data Agent Kit が、基盤となる PySpark スクリプト、dbt 構成、3 つの宣言型 YAML パイプラインを生成しました。

生成された YAML パイプラインと、その視覚的な図を以下に示します。このパイプラインは、Orchestration Pipelines の機能を説明するために簡略化した例です。実際には、本番環境の MLOps の推奨設定は、具体的なユースケースや運用上のニーズによって異なります。

パイプライン 1: トレーニングエンジン

このパイプラインは、高負荷のコンピューティングエンジンとして機能します。エージェントは、まず BigQuery にクエリを実行して過去に完了した注文を抽出する YAML 定義を生成しました。その後、Managed Spark サーバーレスクラスタを動的にプロビジョニングして、地理的な距離を計算し、本番環境で使用するモデルをトレーニングします。最後に、トレーニング済みモデルを Gemini Enterprise Agent Platform Model Registry に push します。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "training-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - sql:\r\n name: "extract_training_data"\r\n engine:\r\n bigquery:\r\n location: "US"\r\n destinationTable: "your-project-id.mlops.training_dataset"\r\n query:\r\n path: "blogpostdemo/training_query.sql"\r\n\r\n - pyspark:\r\n name: "train_model_dataproc"\r\n dependsOn:\r\n - "extract_training_data"\r\n engine:\r\n dataprocServerless:\r\n location: "us-central1"\r\n resourceProfile:\r\n inline:\r\n runtimeConfig:\r\n version: "2.3"\r\n properties:\r\n "spark.dataproc.driverEnv.PYTHONPATH": "./libs/lib/python3.11/site-packages"\r\n "spark.executorEnv.PYTHONPATH": "./libs/lib/python3.11/site-packages"\r\n mainFilePath: "blogpostdemo/train_model.py"\r\n environment:\r\n requirements:\r\n inline:\r\n list:\r\n - "tensorflow==2.14.1"\r\n - "numpy<2.0.0"\r\n - "protobuf<5.0.0dev"\r\n - "google-cloud-storage"\r\n\r\n - ai:\r\n name: "upload_model_vertex"\r\n dependsOn:\r\n - "train_model_dataproc"\r\n agentPlatform:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n modelUpload:\r\n modelName: "transit_days_predictor"\r\n modelArtifactUri: "gs://your-bucket-name/models/tf_transit_days_model"\r\n servingContainerImageUri: "us-docker.pkg.dev/vertex-ai/prediction/tf2-cpu.2-14:latest"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde116dc90>)])]>

パイプライン 2: 日次推論

日々の運用ワークフローでは、この軽量なパイプラインが、トレーニング済みのモデルを現在配送中のすべての注文に適用します。BigQuery ジョブを介してデータセットをクエリし、Gemini Enterprise Agent Platform を介して推論ジョブを実行し、結果を BigQuery テーブルに書き戻して、カスタマーサポートチームに SLA 違反の可能性を通知します。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "inference-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - sql:\r\n name: "extract_inference_data"\r\n engine:\r\n bigquery:\r\n location: "US"\r\n destinationTable: "your-project-id.mlops.inference_dataset"\r\n query:\r\n path: "blogpostdemo/inference_query.sql"\r\n\r\n - ai:\r\n name: "run_vertex_batch_prediction"\r\n dependsOn:\r\n - "extract_inference_data"\r\n agentPlatform:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n batchInference:\r\n jobDisplayName: "inference_job"\r\n modelName: "projects/your-project-id/locations/us-central1/models/your-model-id"\r\n bigquerySource: "bq://your-project-id.mlops.inference_dataset"\r\n bigqueryDestinationPrefix: "bq://your-project-id.mlops"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0f8ff90>)])]>

パイプライン 3: 自動評価と分岐

日次評価パイプラインは、自動品質ゲートとして機能します。dbt モデルをトリガーして予測を実際の配送タイムスタンプと結合し、絶対誤差と SLA 違反を計算します。

パイプラインは、組み込みのロジックを使用して、これらの指標を自動的に評価します。モデルのエラー率が許容しきい値を超えた場合、条件に応じて「training-pipeline」がトリガーされ、新しいモデルが生成されます。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "evaluation-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - pipeline:\r\n name: "run_dbt_models"\r\n framework:\r\n dbt:\r\n airflowWorker:\r\n projectDirectoryPath: "blogpostdemo/dbt_project"\r\n\r\n - python:\r\n name: "check_retraining_condition"\r\n dependsOn:\r\n - "run_dbt_models"\r\n mainFilePath: "blogpostdemo/evaluate_drift.py"\r\n pythonCallable: "check_drift"\r\n engine:\r\n local: {}\r\n\r\n - orchestrationPipeline:\r\n name: "trigger_retraining_pipeline"\r\n dependsOn:\r\n - "check_retraining_condition"\r\n pipelineId: "training-pipeline"\r\n bundleId: "my-first-bundle"\r\n waitForCompletion: false'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0f8eb50>)])]>

Managed Service for Apache Airflow への自動デプロイ

パイプラインロジックの作成は、作業の半分にすぎません。本番環境に安全かつ確実にデプロイする段階で、データチームはこれまで貴重な時間を失ってきました。

Orchestration Pipelines を使用すると、標準的な CI / CD プラクティスを通じてデプロイが合理化されます。デプロイスクリプトを手動で作成したり、複雑な環境境界を構成したりする必要はありません。Data Agent Kit が、ワークスペースに必要な継続的インテグレーションワークフロー（GitHub Actions など）を自動的に生成します。

つまり、commit をクリックするだけで、フレームワークが Orchestration Pipelines Bundle をシームレスにパッケージ化し、Managed Airflow 環境に直接デプロイします。

これらの自動化されたワークフローを既存の CI / CD パイプラインに統合するための包括的なガイドについては、公式ガイド「Orchestration Pipelines のデプロイ」をご覧ください。

Day 2（2 日目からの）運用: モニタリングとエージェントによるトラブルシューティング

これらのパイプラインのメンテナンスは、構築と同じくらい直感的に行えます。Data Agent Kit は、オーケストレーションコントロールプレーンを IDE に直接組み込むことで、ブラウザタブを頻繁に切り替えることなく、Managed Airflow の実行をリアルタイムでモニタリングできるようにします。

Data Agent Kit を使用すると、IDE 内で直接、Managed Airflow の実行をリアルタイムでモニタリングできます。

Data Agent Kit が、作成されたパイプラインを可視化します。

インフラストラクチャやデータの問題は避けられません。たとえば、季節的なデータの急増により Managed Spark クラスタでメモリ不足の例外が発生したり、BigQuery の割り当ての上限に達したりすることがあります。これらの問題を解決するために、何千行もの未加工の実行ログを調べる必要はもうありません。

パイプラインが失敗した場合、Data Agent Kit はすぐに使えるエージェント型トラブルシューティングを提供します。IDE で [トラブルシューティング] ボタンをクリックするだけで、データエンジニアリングエージェントが失敗のコンテキストを分析します。インフラストラクチャの割り当て上限とコードレベルのバグを正確に区別し、根本原因の概要を即座に提供して、インライン修正（コンピューティングテンプレートのスケールアップなど）を提案します。

エージェント型トラブルシューティングにより、パイプラインの障害を即座に診断し、インフラストラクチャのボトルネックを特定して、インライン修正を提案します。

まとめ: 価値創出までの時間を短縮

レジリエントな MLOps アーキテクチャの構築（過去のデータの抽出、dbt 変換の実行、Managed Spark ML コンピューティングのプロビジョニング、モデルレジストリと推論のための Gemini Enterprise Agent Platform のインテグレーション、DAG 間の条件付きトリガーの構成）には、従来、プラットフォームエンジニアリングチームが複雑な Python Operator ロジックを記述するのに数週間かかっていました。

Orchestration Pipelines と Data Agent Kit を使用することで、このライフサイクル全体を数分で作成、デプロイ、簡単にメンテナンスできました。ボイラープレートインフラストラクチャコードを、宣言型の、エージェント対応の標準に置き換えることで、データ組織がパイプラインのオーケストレーションに費やす時間を減らし、具体的なビジネス価値の創出に多くの時間を割けるようにしています。

使ってみる:

Orchestration Pipelines のドキュメントを確認する。
お好みの IDE または CLI に Data Agent Kit をインストールし、ワークスペースを構成する。
エコシステム全体の詳細については、最近のブログ投稿「Data Agent Kit は IDE または CLI にデータ処理のスキルとツールを提供」を確認する。
Data Agent Kit のドキュメントでリファレンスアーキテクチャを確認する。

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

- ソフトウェアエンジニア、Alexandre Moueddene

近畿大学と Google Cloud が包括連携協定を締結 - 約 2 万人超へ「Google AI Pro for Education」を導入し、「AI ネイティブ大学」の実現を支援

Thu, 10 Sep 2026 01:00:00 +0000

Google Cloud は、近畿大学（大阪府東大阪市）と、AI 人材育成モデルの確立ならびに生成 AI を活用した大学運営、学生支援、研究支援の高度化に向け、包括連携協定を締結しました。

本協定に基づく具体的な取り組みとして、全 16 学部の 1・2 年生 19,033 人および教職員 2,105 人、合わせて 21,138 人を対象に、教育機関向け Gemini アプリケーションの有償版である「Google AI Pro for Education」のライセンス導入を Google Cloud がサポートします。また、2026 年度後期の授業開始に合わせて近畿大学が進める、生成 AI 技術を活用した学生支援窓口のオンライン化に向けたトライアルも、Google Cloud が技術面から後押しします。

近畿大学の大規模かつ多様な教育・研究環境と、Google Cloud が提供する生成 AI、クラウド、データ分析などの技術を組み合わせ、AI 人材育成、大学運営、学生支援、研究支援の各領域を横断した「AI ネイティブ大学」の実現を強力に支援してまいります。

【本協定のポイント】

● Google Cloud が近畿大学との包括連携協定を通じて、生成 AI 活用による大学全体の変革を支援

● 全 16 学部の 1・2 年生および教職員合わせて約 2 万人を対象に、「Google AI Pro for Education」のライセンス導入をサポート

● 「AI ネイティブ大学」の実現に向け、AI 人材育成、大学運営、学生支援、研究支援の 4 領域で取り組みを推進

【本件の内容】

近畿大学ではこれまで、従来の教育向け生成 AI サービスの試験導入などを通じて、学生および教職員による生成 AI の活用方法や導入効果を検証してきました。学生の学修支援に加え、教職員による文書作成、要点整理、議事録作成、規程・マニュアルの検索・要約など、さまざまな場面で生成 AI の活用を進めています。

また、学生支援においては、チャットボットやオンライン問い合わせフォームを活用し、対面とオンラインを組み合わせた相談・問い合わせ体制の検証にも取り組んできました。

近畿大学は本協定を機に、これまで培ってきた実績を Google Cloud の技術支援を通じて大学全体の変革へとつなげていきます。

Google Cloud が支援する「AI ネイティブ大学」とは、単に生成 AI サービスを導入するだけではなく、学生と教職員が生成 AI を日常的かつ適切に活用し、AI 人材育成、大学運営、学生支援、研究支援の仕組みそのものを継続的に改善していく大学です。

本協定を通じて、近畿大学は 4 領域で生成 AI を活用した具体的な取り組みを進めます。Google Cloud は、その取り組みを技術面から支えるとともに、そこで得られた知見が国内の高等教育における新たな生成 AI 活用モデルとなることを期待しています。

【近畿大学がめざす 4 つの領域への Google Cloud の支援】

◼︎ AI 人材育成モデルの確立
近畿大学は、自身の持つ多様な教育環境と Google Cloud の生成 AI・クラウド技術を掛け合わせ、全学的な AI 人材育成モデルの確立を目指します。具体的には、全 16 学部の 1・2 年生および教職員の約 2 万人を対象に、「Google AI Pro for Education」のライセンスを導入します。さらに、近畿大学では 2027 年 4 月から全学部で情報リテラシー関連科目を必修化する予定です。Google for Education の協力を得て、生成 AI の仕組み、ファクトチェック、著作権、情報セキュリティ、学術公正などを学ぶこの教育を技術・コンテンツの両面から支援し、学生が専門教育や研究・制作活動において Gemini などの生成 AI を目的に応じて適切に活用できる力の育成を後押しします。

◼︎ AI ネイティブ大学運営モデルの共同構築
近畿大学は、既存業務に生成 AI を追加するにとどまらず、問い合わせ、申請、決裁、文書作成、情報検索、会議運営などの大学業務を生成 AI 活用前提で再設計し、次世代の大学運営モデルの構築を推進します。また、複数のシステムやデータを横断して処理する業務や、複雑な判断・手順を伴う業務、学内 LMS の活用などについて、Gemini Enterprise の AI エージェント機能を活用した自動化・高度化の可能性を Google Cloud とともに検証していきます。

◼︎ AI を活用した「24 時間学生支援モデル」の構築（学生支援窓口のオンライン化）
近畿大学は、2026 年度後期の授業開始に合わせて、AI チャットボット、オンライン問い合わせフォーム、予約制相談を組み合わせた学生支援窓口のオンライン化に向けた移行トライアルを開始します。

学生が時間や場所を問わず必要な情報にアクセスできる環境を目指し、FAQ、学内規程、手続案内、シラバスなどを活用した検索・回答支援の充実に向けた取り組みを、Google Cloud が技術面から後押しします。

◼︎ 研究者と AI が協働する「次世代研究支援基盤」の構築
近畿大学は、論文・研究情報の収集、先行研究の整理、研究データの分析、共同研究者の探索などを支える全学的な研究支援基盤の構築に取り組みます。Google Cloud は、Gemini Enterprise や BigQuery などのサービス提供および技術支援を通じて、研究者と AI が協働する新たな研究環境の創出を支えます。

【近畿大学長松村到のコメント】

生成 AI は、知識を得るためのツールにとどまらず、私たちの思考を広げ、学びを深め、新たな価値を生み出す大きな可能性を持っています。一方で、AI が示す答えをそのまま受け入れるのではなく、情報の正確性を確かめ、自ら考え、判断し、責任を持って活用する力が、これまで以上に重要になります。

今回の Google Cloud との包括連携は、単に新しい AI サービスを導入するものではありません。Google Cloud が持つ生成 AI やクラウド、データ活用に関する技術・知見と、本学の大規模かつ多様な教育・研究環境を掛け合わせ、両者が共に新しい大学のあり方を創り上げていく取り組みです。約 2 万人の学生・教職員への「Google AI Pro for Education」の導入を一つの起点として、教育、学生支援、大学運営、研究の各分野において、生成 AI の活用を前提とした「AI ネイティブ大学」の実現をめざします。

近畿大学はこれまで、社会の変化を先取りし、実社会の課題に向き合う「実学教育」を大切にしてきました。生成 AI が社会に広く浸透する時代だからこそ、学生には AI に使われるのではなく、AI を使いこなし、人にしかできない発想や判断、対話を通じて、新しい価値を生み出せる人材へと成長してほしいと考えています。

令和 9 年（2027 年）4 月から全学部で必修化する情報リテラシー関連科目などを通じて、AI の可能性とリスクの双方を正しく理解し、実践的に活用する力を育んでまいります。さらに、学生支援や大学業務、研究支援にも AI 活用を広げ、大学全体の仕組みそのものを進化させていきます。

Google Cloud との共創を通じて、学生、教職員、研究者が安心・安全に AI を活用し、新しい価値を生み出し続ける大学へ。近畿大学はこれからも、実学教育を進化させながら、これからの高等教育の新しい姿を切り拓いてまいります。

【グーグル・クラウド・ジャパン合同会社執行役員パブリックセクター & ヘルスケア・ライフサイエンス事業本部長和泉綾志のコメント】

先進的な教育を牽引される近畿大学様との包括連携協定の締結を、大変光栄に思います。

Google Cloud は最先端の AI 技術である Gemini、クラウド基盤そしてセキュアなデータ基盤などを提供することで、学生の皆様がこれからの時代に求められる AI スキルを実践的に学べる教育・研究環境づくりを全面的に支援いたします。

また、教職員の皆様の校務、教務等の業務環境 DX、AX 推進を支え、より質の高い学習体験を提供できる基盤づくりに貢献してまいります。

Google Cloud の技術を活用いただくことで、近畿大学様の実学教育による次世代の AI 人材の育成に貢献してまいります。

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

バグの発見と修正を支援するオープンソースの AI ハーネス、Mantis のスタートガイド

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

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

AI モデルは、人間の手をほとんど、あるいはまったく介さずに脆弱性を発見して悪用する能力を持っていることが判明しています。防御側が AI を活用して優位性を確保できるよう、Google はソフトウェアの脆弱性の発見、トリアージ、再現、パッチ適用を自動化する Mantis ハーネスを構築しました。

誰でも利用可能なオープンソースフレームワークである Mantis は、マシンスピードでの脆弱性の発見と修正を実現するための Google の社内アプローチの一環として誕生しました。Mantis により、より効果的でスケーラブルかつコンテキストを考慮したリポジトリ分析が可能になります。

AI コードスキャンは精度が低く、ハルシネーションを起こすことが多いため、真陽性率は 7% を下回ります。Mantis は、批評エージェントやレビューエージェントなどの業界標準のエージェント手法とサンドボックス環境での脆弱性の再現を組み合わせてグラウンディングを行うことで、実効性を持たせた設計になっています。

6 月に公開した記事で詳しく解説したとおり、Mantis はリポジトリの履歴を調べて過去のセキュリティに関する修正から学習し、アーキテクチャと脅威モデルのドキュメントが提供されていない場合でも、それらのドキュメントを自動的に作成します。

階層型のセキュリティサマリーツリーを構築し、個々のファイルをディレクトリレベルとルートレベルのサマリーに集約します。この手法により、大規模なリポジトリ全体で重要な構造コンテキストを維持しながら、トークンのオーバーヘッドを 85% 以上削減することに成功しました。

Google が数十年の期間をかけて幅広いコードベースにわたって蓄積してきたサイバーセキュリティの専門知識の結晶である Mantis は、GitHub で入手可能です。Mantis の使用を開始する方法は次のとおりです。

まず、次のコマンドを使用して Mantis リポジトリのクローンをローカルに作成します。

code_block: <ListValue: [StructValue([('code', 'git clone https://github.com/google/mantis.git'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde03b7650>)])]>

次に、任意のコーディングエージェントを開き、「path/to/mantis にある Mantis フレームワークを使用して、path/to/your/code にあるコードをレビューしたいのですが、やり方を教えてください」というプロンプトを入力します。

Google 社内では、このプロンプトを使用して、多くのコードリポジトリで実際の脆弱性を発見しています。GitHub の Mantis リポジトリには、サンドボックス化のサンプルオプションが含まれています。自社のワークフローに合わせて独自のサンドボックスを実装することもできます。

Mantis は、脆弱性の検出、真陽性のフィルタリング、パッチ適用を簡単に開始できるようにすることを目的としています。AI が検出した脆弱性を把握したら、新しい mantis-advise スキルを使用して、蓄積された知識を活用し、コーディングエージェントに最初から安全なコードを記述させることができます。

AI を活用した脆弱性検出を最大限に活用して開発手法をモダナイズするにあたって、以下に示す 2 つの重要事項の実行を推奨します。

ツールに適切なコンテキストを提供する。Mantis はコミット履歴とコードを自動的に分析してドキュメントを独自に作成することができますが、人間によってキュレートされた知識を得ることで、結果の品質が大幅に向上することがよくあります。たとえば、プログラムをクラッシュさせるようなバグの修正に時間を取られないようにするには、スキャンパイプラインでそうしたバグを確実に検出できるよう、人間によってキュレートされた知識を提供することが非常に重要になります。
脆弱性受け入れ基準を使用してサイバーサンドボックスを構築する。明確な脆弱性再現基準に基づいて脆弱性を再現できる安全なサンドボックス環境を使用すると、知るべきことのみを明らかにし、修正が正しいことを確認することが容易になります。

Mantis について詳しくは、こちらをご覧ください。

- Google、スタッフセキュリティエンジニア、Nick Galloway

- Google、シニアスタッフセキュリティエンジニア、Yulong Zhang

Cloud KMS における耐量子鍵インポートの発表

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

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

企業の間でマルチクラウドアーキテクチャの採用が広がるなか、Bring Your Own Key（BYOK）は、データ主権の維持と重要なクラウドワークロードの保護において不可欠な柱となっています。同時に、量子コンピューティングは急速に進歩しており、セキュリティチームは、ネットワーク間で暗号鍵を安全に転送する方法を再評価する必要があります。

Cloud Key Management Service（Cloud KMS）における耐量子デジタル署名と耐量子鍵カプセル化メカニズム（KEM）の発表に続き、このたび、ソフトウェアベースの暗号鍵を対象とした Cloud KMS における耐量子鍵インポートのプレビュー版をリリースしました。

ポスト量子暗号（PQC）移行タイムラインの次のフェーズの第一歩となる、更新された耐量子 BYOK 機能は、暗号解読が可能な量子コンピュータ（CRQC）が登場する前に、機密性の高い鍵を保護するのに役立ちます。

転送中の鍵の保護を強化するために耐量子鍵インポートを導入する際は、一般提供が開始された Cloud KMS PQC insights を活用して、ポスト量子に向けた全体的なセキュリティポスチャーをモニタリングすることも可能です。この概要を示すビジュアルでは、使用されているアルゴリズムの分類に基づいて非対称鍵が可視化されます。これにより、将来のモダナイゼーションに向けた計画立案や、長期的なレジリエンスの向上に役立てることができます。

脅威:「今すぐ保存、後で解読」攻撃

従来の鍵インポート方法では、転送中の鍵をラップするために、従来の非対称暗号化標準が使用されます。これらのアルゴリズムは現在の脅威に対しては有効ですが、攻撃者が傍受して保存した鍵を復号できる実用的な量子コンピュータが登場すると、根本的に安全ではなくなります。

耐量子鍵インポートは、鍵を耐量子エンベロープで最初からラップすることで、「今すぐ保存、後で解読」（SNDL）攻撃を軽減するのに役立ちます。

鍵を保護する耐量子エンベロープの構築

Cloud KMS で利用可能になったポスト量子転送メカニズムは、ハイブリッド公開鍵暗号化（HPKE）を使用します。Google の新しいインポート方法では、機密性の高いソフトウェア鍵マテリアルを耐量子転送エンベロープでラップします。このプロセスは既存の Cloud KMS API ワークフローに統合されるため、導入の手間を最小限に抑えることができます。

ジョブの開始: クライアントは、Cloud KMS API を通じて新しいインポートジョブを作成し、ポスト量子 HPKE インポートメソッドをリクエストします。
鍵の生成: Cloud KMS サーバーは、ポスト量子 KEM 秘密鍵を生成し、対応する公開鍵をクライアントに公開します。
クライアントサイドのラッピング: サポートされている暗号ライブラリ（Tink や OpenSSL など）を使用して、クライアントは HPKE Seal() オペレーションを実行します。これにより、共有シークレットを確立するために公開鍵がカプセル化され、HKDF-SHA256 を使用してエフェメラル AES 鍵が導出され、ターゲット鍵マテリアルが暗号化されます。
送信: クライアントは、カプセル化された暗号テキストと暗号化された鍵マテリアルを直接連結して Cloud KMS エンドポイントに送信します。このエンドポイントには、すでに耐量子な転送中データ保護機能が組み込まれています。
ラップ解除: Cloud KMS サーバーは、ラッピング鍵の秘密部分を使用して HPKE Open() オペレーションを実行し、Cloud KMS 境界内で鍵マテリアルを安全に復号して保護します。

KEM レイヤでは、X-Wing、ML-KEM-768、ML-KEM-1024 のいずれかを選択できます。鍵導出レイヤは HKDF-SHA-256 を利用し、最終的な対称ラッパーは、標準の 12 バイトのノンスを備えた AES-256-GCM を採用しています。

インポートジョブの設定、外部暗号ライブラリを使用したローカル鍵マテリアルの準備、耐量子ソリューションの管理の詳細については、Cloud KMS の耐量子鍵インポートに関するドキュメントをご覧ください。

Google Cloud の PQC への取り組みにおける重要なマイルストーン

ポスト量子暗号へのグローバルな移行は、マイルストーンを 1 つずつ達成していくマラソンのようなものです。今すぐ最初の耐量子鍵インポートジョブを作成して、アプリケーションの耐量子化のプロセスを開始できます。

皆様からのフィードバックをお待ちしております。また、貴組織のポスト量子戦略を Google がどのようにサポートできるかについて、ぜひお問い合わせください。

- Cloud KMS、シニアソフトウェアエンジニア、Alessio Buraggina

- Google Cloud、シニアプロダクトマネージャー、Erlander Lo

Fault Injection Testing で復元力テスト戦略を簡素化

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

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

データベースの障害やネットワークパスの不調が発生しても、ミッションクリティカルなクラウドサービスはオンラインの状態を維持し続けなければなりません。しかし、現代の分散システムは複雑化しており、高可用性の確保はますます困難になっています。

障害発生時にも可用性と信頼性を維持できるよう、Fault Injection Testing のプレビュー版をリリースいたしました。Fault Injection Testing は、開発者やアーキテクトが障害テストを自動化し、サービス中断時にも予測可能な動作を確保できるように設計されています。

意図的に障害を環境に注入することで、実際のサービス停止が顧客に影響を与える前に、安全メカニズムを検証できます。

ネイティブな復元力テストが重要な理由

セルフホスト型のデータセンターとは異なり、クラウドアプリケーションでは、フェイルオーバーテストを容易にするために、基盤となるインフラストラクチャへの直接アクセスが制限されています。

アプリケーションが障害を乗り越えられることを証明するネイティブツールがなければ、信頼性戦略に重大なギャップが生じ、複数のリスクにさらされることになります。

信頼と評判の低下: 障害が頻繁に発生したり、パフォーマンスが低下したりすると、顧客の不満を招き、ブランドイメージに長期的なダメージを与えます。
コンプライアンスと規制によるペナルティ: 多くの業界、特に金融機関では、障害復旧機能を証明できないと、コンプライアンス違反、監査、罰金につながる可能性があります。
移行の遅延: ゾーン障害が発生しても重要なアプリケーションの安定性を維持できることを検証できない場合、大規模な移行プロジェクトは停滞してしまいがちです。

Fault Injection Testing の仕組み

Fault Injection Testing では、テストテンプレートを作成してテストを実行できます。これらのテンプレートはブループリントとして機能し、注入する特定の障害と、テストの対象となるリソースを定義します。

この公開プレビュー版では、次の 2 つの主な障害シナリオをテストできます。

Cloud SQL のフェイルオーバー: この障害は、高可用性 Cloud SQL インスタンスの、プライマリゾーンからスタンバイゾーンへのフェイルオーバーをトリガーします。
アプリケーショントラフィックの劣化: レイヤ 7 ロードバランサを介して、レイテンシと HTTP エラーコードを選択的に追加できます。

Fault Injection Testing では、障害が注入される前に自動ドライランが実行されます。この読み取り専用のシミュレーションでは、権限がチェックされ、影響を受けるすべてのリソースの最新リストが提供されます。

スコープを確認したら、手動で注入を開始できます。テンプレートで定義した期間が経過すると、タイマーが切れて障害が元に戻ります。

テスト中に、アプリケーションが計画どおりに動作していることを確認できます。計画どおりに進まない場合は、停止と復元の機能を使用して、テストを直ちに停止し、リソースを通常の状態に復元できます。

プレビュー期間中は、ベストプラクティスとして、本番環境以外で FIT を使用することをおすすめします。プレビュー版では、サービスが既存のテスト手法にどのように適合し、補完するのかを早期に確認できます。また、プロダクトの改善に役立つフィードバックを Google に提供することもできます。

企業向けに設計

KeyBank や Servier などのパートナーは、すでに Fault Injection Testing を使用してデプロイを検証しています。これらの組織はネイティブなフォールトインジェクションを活用することで、ゾーンの停止といった極めて過酷な障害シナリオをシミュレーションし、サービスの安定稼働を確かなものにしています。

Fault Injection Testing を使ってみる

Fault Injection Testing は、Google Cloud コンソール、gcloud CLI、REST API を介して利用できます。

プレビュー版へのアクセスをリクエストする: Google Cloud アカウントチームに連絡して、プロジェクトをプレビュー版に追加します。
API を有効にする: Google Cloud コンソールで「Fault Testing API」を検索し、有効にします。
ロールを割り当てる: チームに roles/faulttesting.operator ロールがあり、テストを構成して実行できることを確認します。
最初のドライランを実行する: 本番環境以外で Cloud SQL またはロードバランサリソースのテンプレートを作成し、ドライランを実行して潜在的な影響を確認します。

実装の詳細については、Google のアカウント担当者にお問い合わせいただくか、Fault Injection Testing のユーザーガイドをご覧ください。

- Google Cloud、グループプロダクトマネージャー、Toby Owen

BigQuery Graph の一般提供を開始: エージェントの時代を支える知識の基盤

Tue, 08 Sep 2026 02:10:00 +0000

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

エンタープライズデータで重要になる質問の多くは、個々の行に関するものではなく、さまざまな要素の相互関係に関するものです。たとえば、2 つのアカウントがどのようにリンクされているか、支払いがどのような経路をたどったか、AI エージェントの回答の根拠となるコンテキストは何か、というものです。グラフを使用することで、こうした質問に回答できます。従来、こうした分析情報を引き出すには、データをスタンドアロンのグラフデータベースに抽出する必要があり、結果的にサイロ化と運用上のオーバーヘッドを招いていました。こうした障壁を取り除くため、Google はネイティブグラフ機能をデータウェアハウスに直接組み込みました。そしてこのたび、BigQuery Graph の一般提供を開始いたしました。

プレビュー版の BigQuery Graph では、グラフ分析とリレーショナル分析を統合しました。ISO 規格の Graph Query Language（GQL）と SQL が併用され、走査がネイティブに実行されるため、ETL は不要です。また、BigQuery を基盤とする BigQuery Graph はその機能を継承し、さらに拡張しています。具体的には、スケールアップデータベースのメモリボトルネックなしでペタバイト規模に達し、既存の行レベルおよび列レベルのセキュリティの下で実行され、同じクエリで BigQuery ML と AI 関数を呼び出します。1 つのエンジンで、大規模なグラフ分析と AI エージェント向けの相互につながりのあるコンテキストの提供という 2 つの役割を担います。

「BigQuery Graph は、当社の脅威検出パイプラインに大きな変化をもたらし、単純でサイロ化されたアラートからの脱却を可能にしました。セキュリティシグナルデータをプロパティグラフとしてモデル化することで、以前は計算上不可能だった複雑なマルチホップ走査を数秒で実行できるようになりました。このグラフ中心のアプローチにより、異常が一貫した攻撃ストーリーに自動的にクラスタ化され、それが Gemini モデルのシームレスな統合と組み合わさることで、実用的な脅威ナラティブを生成できています。ネイティブの BigQuery Graph アルゴリズムを統合して、ワークフローをさらに効率化できるようになることを楽しみにしています。」- Thales Cybersecurity Products、グローバルエンジニアリング担当バイスプレジデント、Pete Rubio 氏

プレビュー版のリリース以降、さまざまな業界のデータチームによって分析ワークフローとエージェントワークフローの両方に BigQuery Graph が採用されてきました。

脅威と不正行為の検出: セキュリティ組織や金融機関では、イベントログ全体でシグナルを相互に関連付け、マルチホップ攻撃パス、不正行為ネットワーク、不審なトランザクションループを検出しています。
サプライチェーンのデジタルツイン: 製造組織や物流組織では、サプライヤー、部品、配送ルート間の依存関係をマッピングして、停止をシミュレートし、フルフィルメントを最適化しています。
ID 解決と Customer 360: 広告テクノロジープラットフォームと小売プラットフォームでは、断片化されたユーザー ID と行動タッチポイントを、チャネルをまたいで統合された顧客プロファイルにまとめています。
ナレッジグラフと AI エージェントのグラウンディング: 企業の AI チームは、非構造化ドキュメントから構造化されたナレッジグラフを構築し、Gemini モデルと GraphRAG ワークフローのグラウンディングのためのドメインコンテキストを提供しています。
ネットワークリネージとインフラストラクチャ管理: 通信業界と企業の IT チームは、複雑なネットワークトポロジ、サービス依存関係、マルチホップパス全体のデータリネージを追跡しています。

BigQuery Graph の新機能

一般提供までたどり着いたことには、単なる「安定性の確保」を上回る意味があります。この段階に達するまでに、2 つの取り組みを行いました。まず、グラフエンジン自体を高速化し、適用範囲を広げました。次に、エージェントがグラフを構築し、グラフとチャットし、監査可能なメモリをグラフに保持できるよう、グラフエンジンを取り巻くエージェントエコシステムを構築しました。以下で紹介する機能の中には、現時点で一般提供されているもの、プレビュー版のもの、数週間以内にリリースされるものが含まれています。

グラフエンジンの高速化と適用範囲の拡大

「広告業界は数十年にわたり、個々のイベントを最適化してきました。エージェントの時代が到来し、それらのイベント間の関係が最適化されるようになるでしょう。Yahoo の AI エージェントは、キャンペーン、オーディエンス、露出、成果などの相互につながりのあるコンテキストを BigQuery Graph から得ています。これらのコンテキストに対して、収益化データがすでに存在する場所で、標準の GQL を使用して走査を実行できます。個別のグラフエンジンやデータの移動は不要です。エージェントはグラフを読み取るだけでなく、グラフについて推論し、その結果を新しい関係として書き戻します。こうすることで、自動化を超えて、信頼できる自律システムへと収益化を移行させることができます。」- Yahoo、収益化プラットフォーム担当エンジニアリングディレクター、Mikul Bhatt 氏

ボーダーレスグラフレイクハウス

エージェントの性能は、推論対象となるコンテキストの質に左右されます。そして、そのコンテキストが 1 か所にまとまっていることはほとんどありません。ボーダーレスレイクハウスを使用することで、単一の BigQuery Graph で、ネイティブの BigQuery テーブルと（Databricks Unity Catalog、AWS Glue、Snowflake を介した）他のクラウドのオープンな Iceberg テーブルをその場で走査できます。データをコピーしたり ETL パイプラインを構築したりする必要はありません。

たとえば、サポートエージェントが「この顧客の遅れている注文の商品のサプライヤーはどこで、その拠点はどこか？」という質問に答える必要があるとします。顧客データは Google Cloud の Iceberg レイクハウスに、商品とサプライヤーのレコードは AWS の Databricks カタログにあります。この場合、エージェントは、リクエストごとにソースを結合するのではなく、すでにソースを相互に関連付けている 1 つの仮想ナレッジグラフを走査します。対象となるデータが移動することはありません。

図 1: Google Cloud（青色のノード）、AWS（黄色のノード）、その他のクラウド（緑色のノード）にまたがる仮想ナレッジグラフを示す図。データの移動は発生しない。

次の DDL ステートメントは、ノードテーブルとエッジテーブルを両方のクラウド環境に直接マッピングして、この仮想グラフを定義する方法を示しています。

code_block: <ListValue: [StructValue([('code', '-- A virtual knowledge graph spanning two clouds - no data movement\r\nCREATE OR REPLACE PROPERTY GRAPH `my_project.retail.virtual_kg`\r\n NODE TABLES (\r\n -- Google Cloud\r\n `my_project.gcs_lake.retail.customers` AS Customer KEY (customer_id),\r\n -- AWS\r\n `my_project.dbx_fed_catalog.retail.products` AS Product KEY (product_id),\r\n `my_project.dbx_fed_catalog.retail.suppliers` AS Supplier KEY (supplier_id)\r\n )\r\n EDGE TABLES (\r\n `my_project.gcs_lake.retail.purchases` AS Bought KEY (purchase_id)\r\n SOURCE KEY (customer_id) REFERENCES Customer (customer_id)\r\n DESTINATION KEY (product_id) REFERENCES Product (product_id),\r\n `my_project.dbx_fed_catalog.retail.products` AS Supplied_By KEY (product_id)\r\n SOURCE KEY (product_id) REFERENCES Product (product_id)\r\n DESTINATION KEY (supplier_id) REFERENCES Supplier (supplier_id)\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0b30ad0>)])]>

これにより、エージェントは 2 つのクラウドにまたがって組み立てられた、グラウンディング済みマルチホップの回答を 1 回の走査で取得できます。

code_block: <ListValue: [StructValue([('code', "-- Agent grounding: trace a customer to the supplier behind their product, across clouds\r\nGRAPH `my_project.retail.virtual_kg`\r\nMATCH (c:Customer {customer_id: 'C1'})-[:Bought]->\r\n (:Product)-[:Supplied_By]->(s:Supplier)\r\nRETURN s.name AS supplier, s.country AS supplier_country"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdde0e2a3d0>)])]>

GQL の高速化と表現力の強化

BigQuery Graph は、相互の関連付けに関する質問に対応するように構築されています。たとえば、2 つのアカウントがどのようにリンクされているか、支払いがどのような経路をたどったか、フラグが付けられたエンティティから数ホップ以内にどのエンティティが存在するか、といった質問です。これらは SQL 結合では表現が難しい質問であり、このような場面でグラフエンジンが真価を発揮します。一般提供では、実行速度が向上し、記述がさらに容易になりました。

迅速な実行。一般提供では、非巡回および無向の走査の経路探索が最適化されています。公開ベンチマークと比較して、プレビュー版以降の GQL は 2 倍高速になり、無向の走査は 100 倍になりました。ACYCLIC および TRAIL 経路モードでは、より高速でリソース効率の高いサイクル検出が可能です。クエリのレイテンシが低いため、エージェントの回答の根拠となる近傍検索とパス検索は、頻繁なインタラクティブアクセスでも応答性を維持できます。
表現力が強化されたクエリ。新しい CALL ステートメントと拡張されたサブクエリのサポートにより、結果のエンティティごとにグラフサブクエリを実行したり、再利用可能な名前付き関数を呼び出したりできるため、複雑な質問を 1 つの広範なパターンとして扱うのではなく、複数のパーツに分割できます。アナリストが記述する同じ関数は、エージェントがツールとして呼び出す構成要素になります。

エージェントの時代への適応

「企業には従業員に関するデータが豊富にありますが、従業員に何ができるか、従業員がどの分野に適しているかについての共通認識はほとんどありません。BigQuery Graph を使用すると、散在する情報を 1 つの再利用可能なプロパティグラフに変換し、人材、役割、能力、証拠の相互関係を大規模に走査できます。これにより、相互につながりのある同じ従業員コンテキストを、数千の意思決定に利用できます。意思決定ごとにコンテキストを再作成する必要はありません。これにより、仕事の進め方に関するより難しい質問に関して、AI が回答のためのより強固な基盤を得ることができます。」- Workerbee、創設者兼 CEO、Heiko Roth 氏

グラフとチャットする

グラフを探索するために GQL を記述する必要はありません。BigQuery の会話型分析を使用すると、自然言語で直接グラフとチャットできます。この機能は、スキーマ内の関係を読み取って質問を SQL または GQL に変換し、パスベースの回答のために走査を可視化します。エージェントは、説明や類義語などのグラフメタデータを活用して、結果のグラウンディングを維持します。グラフをグラフたらしめている関係性こそが、自由形式の自然言語クエリに問題をもたらす曖昧さやハルシネーションを排除するのです。また、MCP サーバーを介して Gemini Enterprise を BigQuery Graph に接続したり、会話型データエージェントを直接 Gemini Enterprise に公開したりすることもできます。

エージェントを使用してグラフを構築する

グラフの準備作業（テーブルをノードとエッジにモデル化し、それらに対する GQL を記述する作業）は、すでにご利用のデータエージェントに任せることができます。Google は、GQL パターンマッチング、グラフと SQL の融合、推奨プラクティスに沿ったスキーマ設計など、BigQuery Graph の専門知識をエージェントスキルにパッケージ化し、エージェントがグラフを使いこなせるようにしました。これらの機能は、Google Cloud Data Agent Kit 拡張機能を使用することで、Antigravity、Visual Studio Code、Claude Code、Codex など、お好みのエージェントコーディングツールでそのまま利用できます。

このスキルは、アドバイスだけでなく作成も学習しており、この機能はまもなくリリースされる予定です。エージェントにデータセット、モデルドキュメント、ER 図を参照させると、ノードとエッジが提案され、グラフの構築前に各関係がデータと照合されて、一致率が表示されます。たとえば、98% で一致するものもあれば、56% で一致するものもあります。これにより、最初から信頼できるグラフを手に入れることができます。

エージェントに監査可能なメモリを提供する

エージェントのグラウンディングは、目的の半分にすぎません。残りの半分は、エージェントが何をしたかを記憶することです。エージェントの役割がアドバイスの提供から行動へと移行する中で、どのオプションが選択されたか、どのポリシーが適用されたか、どの代替案が却下されたかなど、すべての決定について事後に説明できることが必要になってきます。BigQuery Agent Analytics のコンテキストグラフを使用すると、エージェントが実行する各アクションが取り込まれ、コンテキストグラフに変換されます。これは、エージェントの推論を型付きのクエリ可能なトレースとして BigQuery Graph に直接保存したものです。トレース自体がグラフであるため、「エージェントの意思決定の理由」を 1 回の走査で確認できます。また、それらの決定に再結合した結果は、次の決定を改善するためのデータになります。

BigQuery Graph を今すぐ使ってみる

BigQuery Graph は、クラウドをまたいでグラフ分析を実行し、AI エージェントをデータにグラウンディングします。まずは、概要とデータモデルで GQL、ノードテーブル、エッジテーブルを連携させる方法を確認し、ご自身のチームのよくあるパターンに適用してみてください。不正行為の検出 Codelab で不審な資金移動や合成 ID を追跡したり、ID の解決 Codelab で断片化されたメール、デバイス、Cookie を 1 人の顧客に結び付けたり、サプライチェーンをデジタルツインとしてモデル化して、停止が発生したときに隠れた依存関係に対してクエリを実行したりできます。

ここから、エージェントへと進みます。エージェントコンテキストグラフ Codelab では、未加工のイベントログを、自律型エージェントが実際に行ったことを監査、説明、追跡するグラフに変換します。これは、信頼できるシステムを支える、相互につながりのあるメモリです。ワークロードがリアルタイムの運用トランザクションと大規模な分析の両方にまたがる場合は、Google の統合グラフソリューションで Spanner Graph と BigQuery Graph を連携させる方法をご確認ください。さらに詳しく知りたい場合は、電子書籍でプロセス全体を説明していますので、ぜひご覧ください。

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

- プロダクトマネージャー、Candice Chen

Cloud CISO の視点: AI 時代に水道事業者を保護するためのヒント

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

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

2026 年 8 月、2 回目の投稿となる「Cloud CISO の視点」をご覧いただきありがとうございます。今回は、Chris Sistrunk と Stephanie Kiel が、水道事業者が直面している重大な課題と、OT 運用担当者がインフラストラクチャを保護するために実行できる具体的な手順について詳しく説明します。

これまでのすべての「Cloud CISO の視点」と同様、このニュースレターのコンテンツは Google Cloud 公式ブログに投稿されます。現在ウェブサイトでご覧になっていて、メール版の受信をご希望の方は、こちらからご登録いただけます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud で取締役会向けの重要な情報を得る'), ('body', <wagtail.rich_text.RichText object at 0x7fdde189b310>), ('btn_text', 'Insights Hub を見る'), ('href', 'https://cloud.google.com/solutions/security/board-of-directors?utm_source=cgc-site&utm_medium=et&utm_campaign=FY26-Q2-GLOBAL-GCP39634-email-dl-dgcsm-CISOP-NL-177159&utm_content=-&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

AI 時代に水道事業者を保護するためのヒント

Mandiant Consulting、OT 担当プラクティスリーダー Chris Sistrunk 氏、および Google Cloud、政府関連業務および公共政策、クラウドセキュリティポリシー責任者、Stephanie Kiel

Chris Sistrunk, Practice Leader, OT, Mandiant Consulting

Google Cloud の脅威インテリジェンスチームは、地政学的紛争の中で、脅威アクターが重要インフラを標的にする際、手口がますます大胆になっていることを確認しています。最近、米国では、インターネットに接続された水道事業のプログラマブルロジックコントローラを標的とした攻撃が増加しています。

Stephanie Kiel, Head of Cloud Security Policy, Government Affairs and Public Policy, Google Cloud

これまで、サイバーインシデントによって業務が中断されることはあまりありませんでした。その理由の一つとして、水道事業者が長年にわたり手動オーバーライド機能を備え、水が消費者に届く前に水質検査を実施してきたことが挙げられます。ポンプや配管の故障は、サイバー脅威とは無関係の理由で日常的に発生します。

しかし、これには緊急の対応と、より強力なセキュリティ対策への取り組みが必要であることは確かです。手動によるオーバーライドは信頼性の高いセーフティネットとなりますが、サイバー脅威を防ぐには、基本的なデジタルセキュリティへの取り組みが依然として必要です。特に AI 時代においてはなおさらです。

脅威を把握し、リスクを管理した対応をおすすめします。水道事業者のセキュリティの現状を踏まえると、これらのシステムを安全に保つ独自の運用レジリエンスを考慮して、さらなる対策を真剣に検討する必要があることを示しています。

上下水道事業者が検討すべきアクション

リソースに制約のある公益事業にとって、最も効果的な防御策はサイバーセキュリティの基本に注力することです。これらの基本的な対策を優先することで、システムを大幅に強化し、組織をはるかに攻撃しにくく、復元力の高い標的に変えることができます。これにより、リソースが豊富な脅威アクターでさえ、別の標的を探すようになります。

アセットのインベントリを作成し、露出を評価する: 制御システムがインターネットに安全でない状態で露出しているかどうかを特定します。このような状態により、脆弱性が悪用される可能性が高くなります。
基本的なセキュリティ対策: デフォルトの認証情報を安全なパスワードに置き換え、ファイアウォールを含む、公開されているアクセスポイントを厳格に強化します。
バックアップ: 制御システムを含む重要なシステムが、実績のある 3-2-1 バックアップルール（データのコピーを 3 つ作成し、2 種類のストレージに保存し、少なくとも 1 つのコピーをオフサイトに保存する）に従って保護されていることを確認します。サイバー攻撃によるダウンタイムを最小限に抑えるために、重要な予備機器を確保します。
セグメンテーション: ネットワークセグメンテーションと多要素認証を使用して、必要に応じてリモートアクセスを厳密に制御します。完全な制御が必要ない場合は、読み取り専用アクセスを使用する必要があります。
緊急時計画: サイバーインシデント計画を、FEMA NIMS や産業用制御システムのインシデントコマンドシステムなど、既存の全ハザードインシデントコマンドシステムに統合します。これは、物理的な配管の破損、煮沸水警報、自然災害に対してすでに使用しているのと同じ対応構造です。
サードパーティとベンダーのアクセスの保護: 多くの水道事業者は、自社の IT や OT を管理せず、サードパーティのシステムインテグレータに依存しているため、システムインテグレータやメンテナンス請負業者が使用するリモート接続を監査する必要があります。サードパーティベンダーに厳格なアクセス制御（MFA 標準など）とロギング要件を適用する必要があります。

これらの推奨事項は、米国水道協会、全米地方水道協会、Water-ISAC、環境保護庁、サイバーセキュリティインフラストラクチャセキュリティ庁、FBI のガイダンスを反映しています。

IT および OT リーダーへの推奨事項: ガバナンスのギャップを埋める

IT と OT のリーダーは、統一されたガバナンスフレームワークを構築するために連携する必要があります。また、サイバーフィジカルシステムのレジリエンスを長期的に高めることに注力すべきです。これは、行政機関、民間組織、個人のすべてが一丸となって取り組む必要があることです。これらのシステムをセキュリティが確保され、適応性が高く、中断から迅速に復元できるものにすることが今後の目標です。

ほとんどの場合、PLC は標準的なソフトウェア開発手法の対象外ですが、組織が使用するソフトウェアに対する堅牢なアプローチは、NIST の Secure Software Development Framework（SSDF）で説明されているように、セキュリティポスチャー全体を大幅に強化できます。また、これらはレジリエンスを測定するのに役立つ先行指標の好例でもあります。Google は、先行指標を評価するためのガイドを公開しています。

手動によるオーバーライドは信頼性の高いセーフティネットとなりますが、サイバー脅威を防止するには、特に AI 時代においては、基本的なデジタルセキュリティへの取り組みが依然として必要です。

テクノロジーの進化に伴い、セキュリティのモダナイズが不可欠となっています。事後対応型の手動モデルから、人間の専門知識を意思決定の中心に据えた AI 拡張型アプローチへの移行が必要です。このアプローチは、小規模なセキュリティチームの能力を増強するまたとない機会を提供します。

昨今の脅威に先手を打つには、組織は単純なコンプライアンスチェックリストから脱却し、コンプライアンスを主要な目標ではなく、優れたセキュリティの自然な結果とする、よりアジャイルで脅威を考慮した戦略を採用する必要があります。

Mandiant のオペレーショナルテクノロジー（OT）に関する Theory of 99 は、AI 時代においてさらに重要性を増しています。機会のファネルは大幅に圧縮されていますが、OT に影響を与えるほど深い侵入では、次のようになります。

侵害されたシステムの 99% は、コンピュータワークステーションとサーバー
マルウェアの 99% は、コンピュータワークステーションとサーバーを対象に設計される
フォレンジックの 99% は、コンピュータワークステーションとサーバーで実施される
検出機会の 99% は、コンピュータワークステーションとサーバーに関連するアクティビティ
侵入の滞留時間の 99% は、Purdue レベル 0～1 のデバイスが影響を受ける前に、市販のコンピュータ機器で発生する

その結果、IT ネットワークと OT ネットワークを標的とする脅威アクターが使用する戦術、手法、手順には、多くの場合、大きな重複があります。しかし、Theory of 99 は、AI 時代における防御側の大きな優位性を浮き彫りにしています。高度な AI 機能を使用して中間インフラストラクチャの 99% を保護することで、組織は脅威をプロアクティブに無力化し、物理的な運用プロセスの重要な 1% を確実に保護できます。

サイバー防御のための AI

以前にもお伝えしたように、AI 機能はネットワークセキュリティのバランスを防御側に有利にシフトする機会を提供します。悪意のある行為者が攻撃ライフサイクル全体で AI 機能を活用するケースが増えているため、防御側の優位性はさらに重要になっています。

現在の脅威環境では、防御を自動化することで、人間のセキュリティチームの能力を強化し、意思決定と生産性を向上させ、重大な脆弱性が悪用される前に対処できます。重要インフラプロバイダは、慎重な計画を立てることで、物理的な資産を保護しながら、より復元力のある、脅威を考慮した防御を構築できます。

防御における AI のメリットを効果的に実現するには、AI ツールを構造化された意図的な方法でシステムに統合する必要があります。事業者は、AI が物理プロセスにもたらす特有の脆弱性を理解し、セキュリティの自動化の恩恵を受けられる特定のビジネスユースケースを評価し、継続的なテストとモニタリングのための明確なフレームワークを確立することが重要です。Google のアプローチの一環として、セキュア AI フレームワークを開発しました。これは、分野を問わず、AI 機能のセキュアなインテグレーションとデプロイを実現するのに役立ちます。

最も重要なのは、人間による監視を中核に据えることです。つまり、AI は意思決定をサポートするものであり、安全対策をインシデント対応計画に直接組み込む必要があります。

水の安全の今後

悪意のあるサイバー脅威から水道システムを保護することは、単なる技術的な課題ではなく、公共の安全を守るための基本的な責務です。清潔で信頼できる水へのアクセスは不可欠なサービスであるため、連邦政府、州政府、地方自治体は、サイバー脅威に直面してもこの重要な公共インフラストラクチャの継続性を確保するために、政策議論から断固とした行動へとますます移行していくことが予想されます。

たとえば、国家サイバー長官室はテキサス州と提携して、水道インフラプロバイダをサイバー攻撃から保護するための試験運用プログラムを立ち上げたばかりです。また、米国上院議員は、最近の出来事に対応して新しい法案をすでに提出しています。

Google は、お客様がクラウドおよびハイブリッドクラウドの OT 環境を保護できるよう支援することに尽力しています。重要インフラストラクチャの保護に関する Google のガイダンスについて詳しくは、CISO インサイトハブをご覧ください。

aside_block: <ListValue: [StructValue([('title', '新しいことを学ぶ'), ('body', <wagtail.rich_text.RichText object at 0x7fdde189a5d0>), ('btn_text', '今すぐ見る'), ('href', 'https://x.com/googlecloud/status/2090213589558698309?s=20'), ('image', <GAEImage: Cloud-CISO-Perspectives-logo-A>)])]>

その他の最新情報

セキュリティチームからこれまでに届いた今月のアップデート、プロダクト、サービス、リソースに関する最新情報は以下のとおりです。

高度なセキュリティガバナンスで自律型エージェントを強化: AI エージェントが有用性と安全性を確保するには、アクセス権とガードレールが必要です。Google 最新の AI インフラストラクチャの現状レポートによると、テクノロジーリーダーの 79% が、セキュリティ、ガバナンス、運用のいずれかを推論のスケーリングにおける最大の課題として挙げています。詳細はこちら。
2026 年のクラウドリスクの状況: ほとんどのセキュリティ検出結果は、実際の攻撃者の機会ではない: Wiz Research のテレメトリーにより、重大度の高い検出結果の大部分に侵害への経路がない理由が明らかになりました。詳細はこちら。
Google Cloud Fault Injection Testing のプレビュー版をリリース: データベースに障害が発生し、ネットワークパスが不安定になった場合でも、ミッションクリティカルなクラウドサービスをオンラインに維持する必要があります。Fault Injection Testing（FIT）は、障害テストを自動化し、障害発生時に予測可能な動作を保証するのに役立ちます。詳細はこちら。
Wiz が AI を活用したデータ検出を構築した方法: バケットスキャナをコンテキストエンジンに変えたマルチエージェントパイプラインとフィードバックループの内部。詳細はこちら。
Wiz による FinOps の民主化: Wiz Cloud Cost が費用配分を自動化し、デベロッパー主導の費用最適化を促進して、費用をビジネス価値に結び付ける方法。詳細はこちら。
Google Workspace Studio の多層防御でエージェントのリスクを防御: Studio には、脅威アクターによるリスクを軽減する多層防御と、組織がエージェントを安全に導入できるようにする堅牢なオブザーバビリティツールが組み込まれています。安全性を重視して設計された Google のアーキテクチャを基盤とする Studio は、ネイティブな脅威防御とエコシステムの詳細な可視化を組み合わせて、マルチステップのエージェント型ワークフローを保護します。詳細はこちら。

今月公開されたその他のセキュリティ関連の記事については、Google Cloud 公式ブログをご覧ください。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud CISO Community にご参加ください'), ('body', <wagtail.rich_text.RichText object at 0x7fdde1898310>), ('btn_text', '詳細'), ('href', 'https://rsvp.withgoogle.com/events/google-cloud-ciso-community-interest-form-2026?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY25-Q1-global-GCP30328-physicalevent-er-dgcsm-parent-CISO-community-2025&utm_content=cisop_&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

脅威インテリジェンスに関するニュース

ロシアが関心を寄せる個人を標的とした複数のクラスタ: Google Threat Intelligence Group（GTIG）は、正規の認証フローを悪用して、ヨーロッパと米国全域の学術機関、航空宇宙、政府機関、シンクタンクで働く個人を標的とする、ロシアのサイバーエスピオナージ脅威クラスタと疑われる 3 つのクラスタを追跡しています。詳細はこちら。
AI インフラストラクチャへの 90 日間にわたる攻撃: Wiz のハニーポットが、RCE、ブラインドプロンプトインジェクション、メモリ認証情報の窃取を通じて LiteLLM、MCP サーバー、AI フレームワークを標的とするアクティブなキャンペーンを明らかにしました。詳細はこちら。
バージョン管理 DFIR: GitHub、GitLab、Bitbucket、Azure DevOps のクイックリファレンス: 主要なバージョン管理サービスにおけるログの可視性、インシデントへの備え、脅威ハンティングに関する実務者向けガイド。詳細はこちら。
arrayref に対する Rust サプライチェーン攻撃: 北朝鮮によるキャンペーンと大幅に重複: arrayref Rust クレート（およびその他）の悪意のあるバージョンが、コンパイル時にバックドアを実行しました。このキャンペーンのインフラストラクチャは、Mastra や axios など、最近の北朝鮮のサプライチェーン攻撃と重複しています。詳細はこちら。

注目の Google Cloud ポッドキャスト(英語)

Cloud Security Podcast: AI、エージェント、Rust、タブを使用したブラウザのパッチ適用: Chrome Security の Jasika Bawa と Doug Turner が、Google Chrome が AI エージェントを使用して、これまでにない規模でセキュリティの脆弱性を自律的に特定してパッチを適用し、ブラウザの更新頻度を大幅に向上させている方法について説明します。ポッドキャストを聴く。
Cloud Security Podcast: Wiz の AI 脆弱性調査プロジェクト Atlas のすべて: Wiz の脆弱性調査責任者である Near Orfeld 氏が、クラウドインフラストラクチャにおける深刻なゼロデイ脆弱性を発見するために、チームがマルチエージェント AI システムをどのように活用しているかを詳しく解説します。ポッドキャストを聴く。
Cloud Security Podcast: 脆弱性のクラスを大規模に根絶する Google の手法: AI がコードを記述し、人によるレビューが追いつかない状況下でも、安全性を維持できる Google 規模のエンタープライズ基盤を構築するにはどうすればよいでしょうか。Google のプリンシパルセキュリティエンジニアである Christoph Kern が、AI 時代における「安全性を重視した設計」の真の意味を探ります。ポッドキャストを聴く。

月 2 回発行される「Cloud CISO の視点」をメールで受信するには、ニュースレター(英語版)にご登録ください。次回も Google Cloud からセキュリティ関連の最新情報をお届けします。

- Mandiant Consulting、OT 担当プラクティスリーダー Chris Sistrunk 氏

- Google Cloud、クラウドセキュリティポリシー、政府関連業務および公共政策責任者、Stephanie Kiel

Google Cloud 上でのサーバーレス Apache Spark: アーキテクチャの選択と AI によるトラブルシューティング

Tue, 08 Sep 2026 00:30:00 +0000

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

現代のエンタープライズデータエンジニアリングにおいて、Apache Spark は大量のデータセットを大規模に処理するための基盤となるフレームワークであり続けています。しかし、クラスタのプロビジョニング、YARN 構成のチューニング、アイドル状態のハードウェアのコスト回避といったインフラストラクチャの管理に追われ、最も重要である「復元力のあるデータパイプラインの構築」に集中できなくなることが少なくありません。Google Cloud は、Managed Service for Apache Spark を通じてこの運用上のオーバーヘッドに対処し、特定の運用ニーズに合わせたサーバーレスおよびマネージドクラスタの柔軟なデプロイモードを提供しています。

この技術ガイドでは、Google Cloud で Spark をデプロイするためのアーキテクチャに関する意思決定マトリックスに加え、リソースと費用を最適化する手法を詳しく解説します。また、組み込みの Gemini Cloud Assist を適用して、サーバーレスバッチパイプラインの障害を迅速にトラブルシューティングし、解決する方法を実演します。これら 3 つのパートは順番に読むとより理解が深まりますが、それぞれを個別に読んでも、Google Cloud での Spark 開発を進めるうえでの有用なヒントが得られます。

パート 1: Apache Spark デプロイモデルの選択

Managed Service for Apache Spark で Spark ワークロードを起動する際の最初の大きな意思決定ポイントは、従来のマネージドクラスタを構築するか、管理不要のサーバーレスインフラストラクチャフットプリントに移行するかを評価することです。

検討事項 1: マネージドクラスタかサーバーレスか

* Gemini Enterprise Agent Platform の Nano Banana 2 を使用して作成

従来の Managed Spark クラスタとサーバーレスのどちらを選択するかは、エコシステムの要件、そしてコスト効率を左右するリソースの利用パターンによって決まります。

ワークロードの頻度、レイテンシの影響を受けやすいワークロード、コストの適合性: クラスタノードの使用率ベースラインが常に高く（80% 以上）、継続的で予測可能性の高い24 時間 365 日のストリーミングまたはバッチ処理パイプラインや、ワークフローの起動時間が積み重なることで SLA 目標の達成が危ぶまれるような場合は、カスタム YARN 自動スケーリングルールを使用してファインチューニングした従来型クラスタを常時実行する方が、費用の予測可能性が高まります。一方、断続的、バースト的、アドホック、またはオーケストレータートリガーのパイプラインの場合は、Managed Spark サーバーレスが極めて有効です。運用管理の手間が省けるだけでなく、計画にかかる時間を短縮でき、アイドル状態のコンピューティング時間に対して料金を支払う必要がありません。
エコシステムとコンポーネントの要件: Managed Spark サーバーレスは、Apache Spark 3.x 以降のコードベースに完全に最適化されています。処理パイプラインが Apache Flink、Presto / Trino、Hive LLAP、Apache HBase などの他のエコシステムコンポーネントに依存している場合、または以前の Spark 2.x コードベースにロックインされている場合は、Managed Spark クラスタを使用する必要があります。
インフラストラクチャのカスタマイズのニーズ: Managed Spark サーバーレスは、基盤となる仮想マシン（VM）レイヤを抽象化します。ワークロードで、OS レベルでの高度なハードウェアチューニング、カスタム OS の初期化アクション、インスタンスへの root SSH アクセス、特定のローカル SSD 構成、カスタムマシンシェイプが必要な場合は、従来のクラスタが必要です。なお、サーバーレスは特定のアプリケーションレベルのライブラリをバンドルするためのカスタム Docker コンテナイメージをサポートしています。

検討事項 2: サーバーレスインタラクティブセッションとサーバーレスバッチ

* Gemini Enterprise Agent Platform の Nano Banana 2 を使用して作成

サーバーレスデプロイモードを選択したら、開発ステージと運用要件に基づいて適切な実行モデルを選択する必要があります。Managed Service for Apache Spark には、サーバーレスワークロードを実行するための 2 つのオプションがあります。

サーバーレスインタラクティブセッション

インタラクティブセッションは、反復的なユースケースや試験的なユースケースに最適です。コードブロックを記述し、中間 DataFrame を検査し、変数を変更し、データセットをメモリに保持したままビジュアリゼーションを生成します。

プライマリインターフェース: 人間参加型のインタラクション向けに設計されています。デベロッパーは、Colab、Gemini Enterprise Agent Platform Workbench、Antigravity、Jupyter ノートブックなどの好みの IDE を使用して、コードをセルごとに実行します。
アイドル時のコスト: コンピューティングリソースは、デベロッパーが検討している間も即座に実行できるようにアクティブな状態を維持します。セッションを非アクティブなままにすると、アイドル状態のコンピューティング料金が発生する可能性があります。

サーバーレスバッチ

バッチは、実行する内容がわかっていて、非インタラクティブな自動化された実行が必要な場合に便利です。このエンジンは、完成済みのパッケージ化された PySpark スクリプト（.py）または Java / Scala アプリケーションファイル（.jar）を、人間の手作業による介入なしに最初から最後まで実行します。

主なインターフェース: Managed Service for Apache Airflow、Cloud Scheduler、CI / CD パイプラインなどの自動オーケストレーターによって管理されます。
アイドル時のコスト: 実行時間に対してのみ、厳密に課金されます。コンピューティングリソースはオンデマンドでプロビジョニングされ、スクリプトを実行し、完了するとすぐにシャットダウンして、アイドル状態のコストを防止します。

開発から本番環境までのライフサイクル

これらの実行オプションは、自然なパイプラインライフサイクルとして連携するように設計されています。開発の初期段階では、ノートブックインターフェース内でサーバーレスインタラクティブセッションを開き、データセットの探索、スキーマのクリーンアップ、変換のプロトタイピングを行います。ロジックが検証され、変換が完了したら、コードを Python スクリプトにパッケージ化し、本番環境での実行のために Managed Service for Apache Airflow によってオーケストレートされるサーバーレスバッチジョブとしてスケジュールします。この移行により、運用の信頼性を確保しつつ、継続的な開発コストを最小限に抑えることができます。

パート 2: 高度なパフォーマンスチューニングと DCU コストの最適化

サーバーレスの Managed Spark は、クラスタメンテナンスの運用オーバーヘッドを解消してくれますが、デフォルト設定のまま本番環境でエンタープライズグレードのパイプラインを実行すると、パフォーマンスのボトルネックや予算の浪費を招く恐れがあります。効率的なデータコンピューティング単位（DCU）のバーンレートを維持するには、送信時にランタイム構成プロパティを使用してリソース割り当てを明示的に宣言する必要があります。

Google は最近、履歴ベースの自動チューニングを導入しました。サーバーレスの環境においては、この機能がベストプラクティスや過去の実行履歴に基づいて、最適化を自動的に適用します。これは、繰り返し実行されるバッチワークロードを、Google がコホートと呼ぶものにグループ化することで実現されます。自動チューナーが、同じコホート名で以前に実行された際のテレメトリーと統計情報を分析して、ボトルネックがどこにあるかを特定します。

ドライバとエグゼキュータのシェイプのカスタマイズ

デフォルトでは、サーバーレスバッチは一般的な仕様（4 コア、16,000 MB RAM）を割り当てます。これは、アプリケーションの性質によっては、効率性に重大な問題を引き起こす可能性があります。

メモリバウンドジョブ: 圧縮されていない大量のデータを処理するパイプラインは、メモリ不足（OOM）エラーが発生してクラッシュする可能性があります。これに対処するには、spark.driver.memory と spark.executor.memory を使用してヒープサイズを個別に増やします。
コンピューティングバウンドジョブ: 数学モデリングや大量のトークン化を実行する処理集約型のジョブでは、CPU が飽和状態になる一方で、高価な RAM がアイドル状態になる可能性があります。spark.driver.cores と spark.executor.cores を明示的に調整して、インスタンスごとの処理の同時実行をファインチューニングします。

デフォルトでは、コア数を増やすと、vCPU と RAM の比率に見合ったベースラインメモリが自動的にプロビジョニングされることに注意してください。そのため、コアとメモリの両方の値をオーバーライドすることが重要です。

自動スケーリングの境界の制御

Managed Spark サーバーレスは、未処理のタスクに基づいて、アクティブなエグゼキュータの数を動的にスケールアップおよびスケールダウンします。ただし、制約のないスケーリングは、不正なコードループや最適化されていないデカルト結合が導入されると、予算超過につながる可能性があります。

防御的なガードレールとして、spark.dynamicAllocation.maxExecutors を使用して常に明示的な上限を宣言してください。これは、予算超過を防ぐための安全装置として機能します。妥当な上限に制限することで、コードが最適に動作しない場合でも、ジョブが固定のインフラストラクチャフットプリントを超えてスケールすることはありません。

高優先度（SLA 主導）: maxExecutors で上限を高く設定して、リソースのバーストを可能にし、全体的なランタイム期間を最小限に抑えます。
低優先度（夜間バッチ）: maxExecutors で上限を低く、厳しく設定します。ワークロードの実行時間は長くなりますが、DCU の消費は予測可能な一定のペースに保たれ、コスト効率に優れた運用が可能になります。

シャッフルストレージの効率の管理

groupBy()、join()、distinct() などのワイド変換を伴う処理では、ネットワーク全体にデータを再配布する必要があり、シャッフルストレージと呼ばれる中間ディスク書き込みが発生します。

Spark はデフォルトで、パーティション数が 200 に静的設定されています（spark.sql.shuffle.partitions）。数ギガバイトに及ぶ大規模なデータセットを処理する場合、パーティション数が 200 個のままだと、個々のチャンクが大きくなりすぎてしまいます。パーティションのサイズが利用可能なエグゼキュータ RAM を超えると（たとえば、1 GB のパーティションを、割り当てられたヒープ領域 0.5 GB 内で処理しようとする場合）、データがディスクにあふれ出します。これにより、実行速度が低下し、プレミアムまたは標準のシャッフルストレージブロックの追加料金が発生します。目安として、各パーティションがメモリ内で約 100 MB ～ 200 MB のデータを処理できるように、合計データサイズに基づいてパーティションパラメータを動的にスケールするとよいでしょう。最適な結果が得られるまで、何回か繰り返す必要が生じる場合があります。

上述のプロパティは、主なチューニング可能なプロパティです。その他のサーバーレスランタイム構成プロパティについては、こちらのリンクをご覧ください。

パート 3: Gemini Cloud Assist による運用診断

本番環境で自動データパイプラインが失敗した場合、データエンジニアは従来であれば、ドライバとエグゼキュータにまたがる冗長で断片的なログファイルを何時間もかけて精査する必要がありました。Managed Service for Apache Spark は、Gemini Cloud Assist を Google Cloud コンソールにネイティブに統合することで、こうした手間を取り除きます。これにより、エンジニアは自然言語を使用して障害を診断し、解決できます。

この運用スタイルの変化を具体的に示すため、ある PySpark ETL パイプラインの事例を見ていきましょう。このパイプラインは、Google Cloud Storage（GCS）バケットから顧客トランザクションデータを読み取り、変換を適用する過程で、予期せぬランタイムエラーにより失敗したものです。この事例を通して、一般的なトラブルシューティングの流れを解説します。

ステージ 1: 欠落している実行パラメータの診断

新しいパイプラインの最初の実行試行中、バッチジョブのステータスが保留中から実行中に切り替わり、最終的には一般的な終了メッセージ「アプリケーションは終了コード 1 で失敗しました（Application failed with exit code 1）」とともに失敗状態になっています。

エンジニアは、Cloud Logging を手動でクエリしたり、コンソールの複数のセクションを移動したりするのではなく、エラーログを見つけて [ログを調べる] オプションを選択できます。この操作により、ネイティブの会話ペインが開き、Gemini Cloud Assist によってドライバのテレメトリーとシステムログが自動的に分析されます。

このシナリオでは、送信時に必要なランタイム引数（ソース GCS バケットパスなど）が省略されたために PySpark スクリプトが失敗したことを、アシスタントがわかりやすい英語で説明してくれます。Gemini Code Assist は、これらの引数を想定しているスクリプト内の正確な行を即座に特定するため、スタックトレースを読み取る必要がなくなります。

ステージ 2: スキーマとデータ型の異常を解決する

不足している引数を解決してジョブを再送信すると、パイプラインは実行されますが、2 回目のデータ異常が発生します。大量のデータを取り込むパイプラインでは、アップストリームのソースファイルに破損したレコードや形式の不整合が含まれていることがよくあります。

2 回目の失敗後、エンジニアは再び Gemini Cloud Assist にログの調査を指示します。アシスタントは TypeError を特定し、クラッシュの原因となっている正確な DataFrame 変換を特定します。これは、スキーマが列を文字列として自動推論したために失敗した除算演算（df['amount'] / df['transaction_id']）です。

さらに、アシスタントは基盤となる GCS ファイルデータをスキャンして、根本原因を特定します。この場合は、ソースデータセット内の非数値の異常（数値セル内のテキスト文字列など）です。

ステージ 3: 検証済みのコード修正の生成とデプロイ

エンジニアは、スキーマタイプをキャストして null 値をキャッチする PySpark ロジックを手動で書き換えるのではなく、Gemini Cloud Assist に直接プロンプトを入力して、復元力のあるソリューションを生成させることができます。

ユーザープロンプト: 「transaction_id ではなく、quantity で amount を割るようにコードを書き換える方法を提案して。さらに、プロセスを失敗させることなく無効なレコードをスキップするロジックを追加して。」

アシスタントは、復元力のあるキャストと null 処理関数（coalesce や try_cast など）を使用して、修正された PySpark コードブロックを生成します。

この修正されたスクリプトを実装することで、オーケストレーションパイプラインは、バッチ実行全体をクラッシュさせることなく、不良なソースレコードをスムーズに除外できます。後続の実行は正常に完了し、データの更新速度に関する SLA が維持されます。

サーバーレス Apache Spark の活用: メリットと次のステップ

データ処理パイプラインの管理に、インフラストラクチャ構成に関する高度な専門知識は必要ありません。サーバーレスバッチのハンズオフスケールと、動的割り当て上限やシャッフルサイズの計算など、リソースの明示的なチューニングを組み合わせることで、データチームはパフォーマンスとコストのプロファイルを厳密に管理できます。障害が発生しても、Gemini Cloud Assist をロギングワークフローに直接統合することで、複雑なトラブルシューティングのあり方が一変します。手動でログを精査する手間がなくなり、迅速で自動化されたサイクルへと進化させることができます。

これらのアーキテクチャを実際に使用するには、Managed Service for Apache Spark のドキュメントを確認し、Google Cloud コンソールでサーバーレスバッチを直接実行してください。

これらのコンセプトのアーキテクチャ分析の詳細については、エージェントの時代における Apache Spark® の実務担当者向けガイドを今すぐご覧ください。このガイドには、Codelab、ステップバイステップのワークフロー、GitHub リポジトリから直接実行できる PySpark と Terraform のテンプレートが含まれています。Google Cloud を初めてご利用になる場合は、$300 分のクレジット付き無料トライアルに登録することで、サーバーレスクラスタやマネージドクラスタ上でこれらのブループリントを無料でお試しいただけます。

- Google Cloud、データ分析担当カスタマーエンジニア、Lior（Leo）Ginzberg

Google Cloud Partner Tech Influencer Challenge 2026 / Google Cloud Next Tokyo 26 関連コンテンツのご紹介

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

Google Cloud Partner Tech Influencer Challenge 2026 について

Google Cloud ではパートナー企業の社員の皆様による技術コンテンツの投稿を応援しています。2022 年より開始した「テクニカルブログチャレンジ」は、2025 年から「Google Cloud Partner Tech Influencer Challenge」と名称を変更し、ブログに限らない Web 媒体も対象として実施しています。

Google Cloud Partner Tech Influencer Challenge 2026 参加ガイド

期間：2025 年 11 月 1 日〜 2026 年 10 月 31 日
対象：上記期間内に初めて投稿された Google Cloud 技術コンテンツとします。技術コンテンツとは、Google Cloud と Google Workspace に関する検証内容、使い方Tips、アーキテクチャ説明を含めた導入事例等を指します。
対象投稿者：パートナー企業にお勤めの方であればエンジニア・非エンジニアは問いません。
投稿場所：自社のテクニカルブログサイト、自社ホームページ、または Qiita、Zenn、スライド共有サービスといった、Web 媒体（URL が存在して誰でもアクセスできるもの）にご投稿ください。テキストベースのブログコンテンツだけでなく、YouTube などの動画コンテンツも対象となります。
参加方法：エントリーフォームにてコンテンツの URL をご登録ください。1つのフォームで最大 10 の投稿をエントリーできます（1 記事ずつお送りいただいても問題ありません）。期間内であれば、新規の投稿を何回でもエントリーいただけます。

Google Cloud Next Tokyo 26 関連コンテンツの紹介

2026 年の Google Cloud Next Tokyo 26 は 7 月 30 日と 31 日の 2 日間にかけて開催され、好評のうちに幕を閉じました。140 以上のブレイクアウトセッションとスポンサーセッション、50 以上のオープンステージとDeveloper Stage セッションに加えて、120 以上の Expo ブースで来場された方々をお迎えしました。パートナーの皆様にはこの Google Cloud Next Tokyo 26 での発見や体験をもとに多くの技術コンテンツを投稿いただいております。本記事では、ご応募頂いたコンテンツの中から抜粋して、Google Cloud Next Tokyo 26 に関連する記事を紹介させて頂きます。たくさんの素晴らしいコンテンツをご応募いただきまして、本当にありがとうございます。

※ 以下、掲載順は所属企業のドメインのアルファベット順となっております。

クラウドエース株式会社

Demochkin Evgenii 様
NEXT TOKYO ‘26：ゲーム・インフラ・メディアのAI・クラウド活用事例まとめ

伊藤龍治様
技術イベントに参加する価値って何だろう？〜Google Cloud Next Tokyo 26で新卒エンジニアが感じたこと〜

ラリオス川口様
忙しい方のための一行速報！｜Google Cloud Next Tokyo 26｜基調講演｜Day1｜ラリオス｜エモーショナルカタリスト｜雲の向こう側｜クラウドや AI の魅力をエモーショナルに
 速報！｜Google Cloud Next Tokyo 26 基調講演｜エージェント時代のビジネス変革がいよいよ始まる｜ラリオス｜エモーショナルカタリスト｜雲の向こう側｜クラウドや AI の魅力をエモーショナルに

小勝亮拓様 / 村田会富様
【速報まとめ】Google Cloud Next Tokyo ’26 基調講演 Day 1 | クラウドエース株式会社
 【速報まとめ】Google Cloud Next Tokyo ’26 基調講演 Day 2 | クラウドエース株式会社

佐々木新様
Google Cloud Next Tokyo ’26レポート〜クラウドエースのテーマは「個人のAI活用から組織のAXへ」〜 | クラウドエース株式会社

株式会社電算システム

Tomoaki Sekiya 様
「作れるか」から「任せられるか」へ - Next Tokyo 26 Day 2 基調講演で見たAIエージェント運用の状況
 BigQueryが高速な理由とアーキテクチャ - Next Tokyo 26 Developer Stage
セッション連動記事："Gemini Enterprise を安全に活用する Agentic Defense の土台"を自分の手で試めそう

髙橋祐輔様
【Next Tokyo ‘26】セッションレポート：AIが変えるサイバー空間における攻撃と防御の最前線
 【Next Tokyo ‘26】セッションレポート：PSC で実現する今どきのシンプルかつセキュアなサービス接続
 【Next Tokyo ‘26】セッションレポート：「JRE ID」におけるGoogle Cloud Fraud Defenseの導入と活用

富士通株式会社

青木智博様
【Next Tokyo 26】BigQuery × Gemini で実現する自律型データ基盤 #GoogleCloud - Qiita
【Next Tokyo 26】BigQuery 2026 徹底解説：AI時代のDWHが向かう「自律型データ基盤」の全貌 #GoogleCloud - Qiita
【Next Tokyo 26】Gemini × ADK 2.0 徹底解説：リアルタイム「Agentic RAG」の進化と実用例 #GoogleCloud - Qiita

フューチャーアーキテクト株式会社

林知範様
Google Cloud Next Tokyo 26 の Developer Stage が熱い！

株式会社 G-gen

今村壱生様
ツール導入ではない、企業のスタイルを創る「AI戦略」としてのGemini Enterprise(Google Cloud Next Tokyo 26セッションレポート) - G-gen Tech Blog
Gemini Enterprise Agent Platform入門！進化した次世代エージェント構築基盤の全貌(Google Cloud Next Tokyo 26セッションレポート) - G-gen Tech Blog

奥田梨紗様
CDPだけで顧客理解は不十分？Google Cloudと生活者データで実現する”Why 分析”最前線(Google Cloud Next Tokyo 26セッションレポート) - G-gen Tech Blog

杉村勇馬様
Google Cloud Next Tokyo 26 速報レポート - キーノート（1日目） - G-gen Tech Blog

高宮怜様
非エンジニアが安心してバイブコーディングして公開するには？セキュアなAI駆動開発ハーネスの仕組み(Google Cloud Next Tokyo 26セッションレポート) - G-gen Tech Blog

KDDI アイレット株式会社

山際哲哉様
【Google Cloud Next Tokyo 26】ソフトウェアの先へ: Anthropic が示す次世代エンタープライズ AI | iret.media

エントリーをお待ちしています

今回は Google Cloud Next Tokyo 関連のコンテンツを紹介いたしました。2026 年の本キャンペーンへのエントリーは 2026 年 10 月 31 日で締切となります。引き続き、エントリーフォームよりご応募お待ちしております。

Cloud Blog JA

AI コーディング エージェント向け Google Cloud Developer プラグインのご紹介

ツールの連動に関する問題を解決

オープン スタンダードを基盤に構築

プラグインの動作: プロジェクトのオンボーディングと ID の認証

Google Cloud プラグインのインストール

次のステップ

Spanner: DML トランザクションの累積ミューテーション上限を撤廃

高い上限で柔軟性が向上

技術的な考慮事項

ロックと中止

DML と Mutation API

ミューテーション数について

Java の実装例

変更がない点

ベスト プラクティス

Google、2026 年 Gartner® Magic Quadrant™ エンタープライズ AI アシスタント部門のリーダーに選出

Google がリーダーに選出された理由

Gemini Enterprise の最新の機能強化でビジョンを推進

Gemini Enterprise のお客様も価値を実感

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

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

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

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

gcloud の例

API の例

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

Yahoo の影響と結果

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

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

BigQuery の TabFM のご紹介: 予測分析の再定義

表形式の予測のための主要なモデル

BigQuery で TabFM を使ってみる

BigQuery の TabFM の仕組み

ジョブに適したツールを選択

予測 ML が簡単に

Spanner への移行: Antigravity CLI で二重書き込みを自動化してサービス停止を最小限に

課題: 二重書き込みによる移行の仕組み

解決策: 標準化されたミューテーション コンバータ パターン

Antigravity CLI をヘッドレス モードで使用する理由

クラウド エンジニアにとっての成果と重要なポイント

次回のデータベース移行に役立つ 3 つのヒント

使ってみる

LLM ワークロードはすべて同じではない: 分類と生成における TPU のパフォーマンス ベンチマーク

主な結果と提案

アーキテクチャの構成

ワークロード: 分類と生成

結果と考察

まとめ

LLM ワークロードをスケールするために

Google Gen AI SDK for Kotlin 1.0 の発表: Gemini への慣用的なマルチプラットフォーム アクセス

1. はじめに: 依存関係を追加する

2. 単項およびストリーミングのテキスト生成とチャット

3. Google 検索でグラウンディングされたマルチモーダル分析

4. ビジュアル生成と会話型編集: Gemini 3 画像ファミリー

5. Gemini Live とのリアルタイムの双方向インタラクション

6. 構造化されたツールと関数呼び出し

次のステップ

BigQuery の新しい ID 列でパイプラインを簡素化

データ パイプラインにとっての主なメリット

ID 列を実装する方法

使ってみる

Google、2026 年 Gartner® Magic Quadrant™ で戦略的クラウド プラットフォーム サービス部門のリーダーに選出

1. ロックインのない共同設計スタックで AI を加速

2. 動的なインフラストラクチャで迅速かつ経済的にスケーリング

3. 選択肢の拡大とセキュリティの強化でデジタル主権を確立

クラウドへの移行を加速する

数週間から数分へ: データ パイプラインの新たなエージェント時代

環境設定

ビジネス上の問題の例: プロアクティブなサプライ チェーン管理

エージェント ワークフロー: プロンプトからパイプラインまで、わずか数分で

Managed Service for Apache Airflow への自動デプロイ

Day 2（2 日目からの）運用: モニタリングとエージェントによるトラブルシューティング

まとめ: 価値創出までの時間を短縮

近畿大学と Google Cloud が包括連携協定を締結 - 約 2 万人超へ「Google AI Pro for Education」を導入し、「AI ネイティブ大学」の実現を支援

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

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

Uber の事例の要点

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

バグの発見と修正を支援するオープンソースの AI ハーネス、Mantis のスタートガイド

AI コーディングエージェント向け Google Cloud Developer プラグインのご紹介

オープンスタンダードを基盤に構築

ベストプラクティス

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

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

解決策: 標準化されたミューテーションコンバータパターン

Antigravity CLI をヘッドレスモードで使用する理由

クラウドエンジニアにとっての成果と重要なポイント

LLM ワークロードはすべて同じではない: 分類と生成における TPU のパフォーマンスベンチマーク

Google Gen AI SDK for Kotlin 1.0 の発表: Gemini への慣用的なマルチプラットフォームアクセス

データパイプラインにとっての主なメリット

Google、2026 年 Gartner® Magic Quadrant™ で戦略的クラウドプラットフォームサービス部門のリーダーに選出

数週間から数分へ: データパイプラインの新たなエージェント時代

ビジネス上の問題の例: プロアクティブなサプライチェーン管理

エージェントワークフロー: プロンプトからパイプラインまで、わずか数分で

パート 2: 高度なパフォーマンスチューニングと DCU コストの最適化