デベロッパー

エージェントプラグインの開発から学んだ、評価エンジニアリングの 4 つの教訓

Mon, 02 Nov 2026 03:00:00 +0000

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

エージェントシステム開発における真の課題は、「作ること」ではなく「測ること」です。

評価エンジニアリングは、信頼性の高い AI システムを構築するための重要な基盤です。エージェントの挙動を正確に測る体系的かつ再現可能なテストを構築できるかどうか。それが、信頼できるツールをリリースできるか、それともサイレントエラーや API 呼び出しの失敗、誤作動を引き起こすツールになってしまうかの分かれ目となります。

私は Google で長年にわたり評価エンジニアリングの取り組みを推進してきました。新しくリリースされた Google Cloud Developer プラグインの開発は、実際のデベロッパーワークフローを通じてこれらの重要原則をストレステストし、検証する実践の場となりました。

新しいプラグインの開発から得られた、皆様のエージェント開発にも活かせる 4 つの評価の教訓をご紹介します。

1. 要約ではなく、実行ステップを評価する

エージェントを初めて評価した際、私たちは LLM-as-a-Judge を導入し、エージェントが最終的に返したテキスト回答を点検して、チェックリストに基づいて採点していました。しかし、採点ツールはエージェントが「実際に何を行ったか」ではなく「出力したテキスト」しか見ていないため、この方法には根本的な欠陥があることにすぐ気づきました。Google Cloud Developer プラグイン向けに、最初の 11 種類のプロンプトからなる評価スイートを実行したところ、自動採点ツールは 3 つのプロンプトを「不合格」と判定しました。しかし、未加工のツール呼び出しログを開いて対話履歴を確認してみると、プラグインは実際には 3 つすべて合格していたのです。たとえば Cloud Run のクリーンアップに関するプロンプトでは、ルーブリックとして「コマンドを実行する前に構文チェックを行うこと」が定められていました。エージェントは、最初のステップとして gcloud help run services list を実行しました。作業自体は完了していたものの、エージェントが最後に出力したメッセージは、ヘルプドキュメントを確認したことをわざわざ報告するのではなく、データの永久損失についてユーザーに警告することを優先していたのです。

採点ツールは、エージェントが正しい対応をしたにもかかわらず、要約でそれを報告しなかったという理由だけで減点してしまったのです。ルーブリックの項目に「X を実行したか？」とあっても、実際のツール呼び出しの実行プロセスを評価しない限り、LLM による判定は単なる推測にすぎません。

要点: エージェントの評価を、最後に出力されるまとめの言葉だけで行わないでください。未加工の実行プロセスを採点し、実際にどんなコマンドが実行され、検証され、対象範囲が設定されたのかを確認してください。

2. 非同期オペレーションの評価を設計する

ツール呼び出しの実行プロセスを読み解く段階になると、何を読み取るかと同じくらい、そのテレメトリーをどう抽出するかが重要になってきます。エージェントテレメトリーを時系列のフラットなイベントリストとして抽出してしまうと、ツールの同時ディスパッチが見えなくなってしまいます。これは、動作不良を引き起こす重大な原因の一つです。最新のエージェントハーネスは、多くの場合、配列を使用して複数のツール呼び出しをまとめ、1 回のアシスタントターンでバッチ処理します。

実際の評価で、エージェントに「環境の検査」と「ドキュメントの検索」をリクエストしたところ、ハーネスはスキルの読み込みと 2 件のドキュメント検索を、1 つの tool_calls ペイロード内で同時にディスパッチしました。スキルの有効化は多段階のプロセスです。最初の呼び出しでは短い起動スタブのみが返され、その次のターンで初めて指示の本文が挿入されます。そのため、検索処理を制御すべき指示がプロンプトコンテキストに届いたときには、システムはすでに検索を完了してしまっていたのです。

システムはスキルに対して専用のターンを挟まなかったため、スキルの指示をエージェントの行動に反映させることができなかったのです。テレメトリーパイプラインがターン構造を取り除き、すべての呼び出しを 1 つのフラットなタイムラインに統合してしまうと、エンジニアは「なぜエージェントはスキルに埋め込まれた明確な指示を無視したのか？」と思い悩み、何日も無駄に過ごすことになります。

要点: テレメトリーの抽出時にターン構造を保持してください。そうすることで、追加の指示がコンテキストウィンドウに読み込まれる前に、クライアントサイドで並列ディスパッチによるツール呼び出しが行われてしまう事象を検知できます。

3. ライブ実行と「ドライラン」を並行してテストする

並列ディスパッチなど、ハーネス独自の挙動を把握するには、実際の API 呼び出しを検査する必要があります。しかし、単一の環境条件だけでエージェントをテストしていると、重要な問題の半分を見落とすことになります。最初から、ライブ実行とプランのみの実行の 2 パターンを並行して実施する必要があります。ライブ実行の条件では、エージェントはサンドボックス化された実際の認証情報を保持し、実際にコマンドを実行します。これにより、構文が正常に動作するか、パラメータが綺麗にシリアライズされるか、破壊的な操作を行う前にエージェントに自制が効くかを確認できます。

ライブ実行では、ステップ 2 で予期しない権限エラーが発生し、テストしようとしている挙動に到達する前にテストが中止されることがよくあります。そこで必要になるのが「プランのみ」の条件です。あらかじめ認証情報を取り除いておき、何も実行せずに「何をしようとしているのか」をエージェントに説明させます。これにより権限の障害が取り除かれ、モデルの純粋な推論とルーティングの意図が明らかになります。最も重要な発見の約半分は、この 2 つの差から得られたものです。

たとえば、あるオンボーディング用のプロンプトでは、プロジェクトリストの呼び出し時にライブ実行がすぐにブロックされてしまいました。対照的に、プランのみの実行はスムーズに完了し、組織のポリシー、管理者の承認、ガバナンスを完全に無視した 8,000 文字のプランを生成しました。プランのみの実行がわずか数秒で明らかにした重大な認知上の欠陥が、ライブ実行では覆い隠されてしまっていたのです。

要点: ライブ評価とプランのみの評価を並行して実施してください。ライブ実行では実際の実行と安全上の制御をテストします。プランのみの実行では、権限エラーに阻まれることなく、モデルの生の推論とルーティングを確認できます。

4. 「ゴールデンセット」を永続的なベースラインとして使用する

フロンティアモデルのアーキテクチャは数か月ごとに変化し、エージェントハーネスは進化し、プラグインマニフェストの標準も必然的に変わっていきます。Google Cloud Developer プラグインを構築するにあたり、私たちは評価を、こうした非決定的な環境における継続的インテグレーションテストとして扱いました。つまり、ハーネス、ライブモデル、そして各種ツールが連携して動作する複合スタックに対し、現実的なタスクを使用してストレステストを実施したのです。

このアプローチでは、最終的なテキスト出力から推測するのではなく、エージェントが何を考え、実際にどのようなコマンドを実行し、何も壊さずに問題を解決できたかという、実行プロセス全体を把握します。次に、理想的なパスを理解している人間の専門家がキュレートしたゴールデンセットに対して、その実行結果を採点します。

要点: ハーネス、モデル、プラグインなど、システム全体が実際の運用環境で実行すべきことに基づいて、ゴールデンセットを構築してください。モデルは変化しますが、そうしたベースラインの実行結果がセーフティネットになります。

注意: 「ワンショット」デモではなく評価スイートを使用する

エンジニアが陥りがちな間違いの一つに、私がワンショットデモと呼んでいる手法があります。これは、LLM にプロンプトを入力し、LLM が完全な 3D ゲームを構築したりルービックキューブを一発で解いたりするのを見て、それを「評価」と呼んでしまうような状態のことです。しかし実際には、これは自己満足のための指標にすぎません。

AI で質の高い作業を行うには、評価スイートが必要だと私は確信しています。評価なしで進めるのは、暗闇の洞窟へと目隠しで飛び込むようなものです。エンタープライズグレードのエージェントを開発するなら、複数ステップに及ぶ対話の処理能力、権限の制御、そして破壊的な結果の回避能力をテストしなければなりません。たとえば、「コスト削減の機会を見つけて」とリクエストしただけなのに、プロジェクトが誤って削除されてしまうような事態を防ぐ必要があります。

次のステップ

エージェントプラグインや MCP サーバーの構築は、始まりにすぎません。実際のクラウドインフラストラクチャ環境で真に信頼できるものをリリースするには、期待どおりに動作することを確認するための評価作業に、かなりの労力が必要となります。結局のところ、モデルの入れ替わりを乗り越えられるのは、ストレステスト済みの評価スイートだけです。Google Cloud Developer プラグインのドキュメントをご確認いただくか、こちらの Codelab をご覧になり、Antigravity でプラグインの利用を始めてみてください。

- Google Cloud、AI インフラストラクチャおよび応用エンジニアリング担当デベロッパーリレーションズリード、Casey West

Google Antigravity で Claude Opus 5.5 と Claude Sonnet 5.5 が利用可能に

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

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

手早いバグの修正の繰り返しから複雑な移行の計画まで、タスクごとに適したモデルは異なります。

オープンなエコシステムへの取り組み、そしてあらゆるタスクに最適なモデルを開発者に提供するという Google Cloud のコミットメントに基づき、Google Cloud をご利用のお客様は Google Antigravity で Claude Opus 5.5 と Claude Sonnet 5.5 をお使いいただけるようになりました。Claude Opus 5.5 は複雑なタスク向けに設計されているのに対し、Claude Sonnet 5.5 はより高速かつ低コストな補完モデルです。

管理者によって有効化されると、開発者はモデル選択ツールから Claude Opus 5.5 と Sonnet 5.5 を直接選択できるようになります。管理者は、Gemini 3.8 Flash や Gemini 4 Argon を含む Google の Gemini モデルを選択することもできます。これらのモデルは、Antigravity 2.0、Antigravity CLI のほか、VS Code、JetBrains IntelliJ、Visual Studio 向けに最近リリースされた Antigravity IDE 拡張機能に適用されます。これにより、エンタープライズ共通の請求枠組みとセキュリティ境界のもとで、タスクに最適なモデルを選択できるようになります。

この投稿では、これらのモデルを使用して Antigravity で開発を行うための 2 つのエンジニアリングパターンをご紹介します。全サブスクリプションプランにおいて Antigravity でサポートされているモデルの一覧については、こちらのドキュメントをご覧ください。

Antigravity のマルチモデルエンジニアリングパターン

同じエージェントハーネス内で複数のモデルファミリーを利用可能にすることで、レイテンシとコストを管理しながらコードの品質を高める、実践的なマルチモデルワークフローが実現します。

パターン 1: ループワークフローとグラフワークフローでのクロスモデル検証（「LLM-as-a-Judge」）

エージェントループや複数ステップのグラフワークフローを構築する際、コードの記述と自身の出力のレビューに同じモデルを使用すると、そのモデル固有の盲点を補強してしまう恐れがあります。2 つの異なるモデルファミリーを組み合わせ、一方を実装者、他方を検証者（判定者）とすることで、ワークフローの次のステージに進む前に第三者的な検証が可能になります。

Antigravity では、このパターンをインタラクティブに実行することも、自動化されたサブエージェントを介して実行することもできます。

モデル A で計画と実装を行う: Claude Opus 5.5 または Gemini 4 Argon を使用してプランニングモードで開始し、複数ファイルにわたる変更の設計と実装を行います。
モデル B で検証する: ループの変更を commit するか、次のステップへ進める前に、モデルを切り替えるか、CLI で単発の /model チェックを呼び出して、別のモデルファミリーにテストスイートや要件に照らして実装を評価させます。

パターン 2: 推論モデルと Flash サブエージェントの組み合わせ

複雑なエンジニアリングタスクでは、高度な推論を要する少数の意思決定と、大量の機械的なルックアップ（ファイルの検索、ログの grep、lint 出力の確認、テスト失敗の分類など）が組み合わされることがよくあります。すべてのルックアップをフロンティアモデルで実行すると、レイテンシとコストの両方が増加する可能性があります。

Antigravity のサブエージェントカスタマイズシステム（.agents/agents/*.md）を使用すると、特定のモデルティア（inherit、flash、pro）を専門のサブエージェントに割り当てることができます。プライマリセッションでより強力なモデルを稼働させている場合、以下のように動作します。

model: inherit が設定されたサブエージェントは、高度な推論を要するサブタスクに対してアクティブなセッションモデルを使用します。

model: flash が設定されたサブエージェントは、高速な検索、分類、トリアージ作業を Gemini Flash モデルにオフロードします。

たとえば、.agents/agents/test-triager.md で高速なログトリアージサブエージェントを以下のように定義できます。

code_block: <ListValue: [StructValue([('code', '---\r\nname: test-triager\r\ndescription: Runs unit tests, classifies failures, and returns a concise summary of failing assertions.\r\nmodel: flash\r\ntools:\r\n - read\r\n - edit\r\n---\r\n\r\nRun the requested test targets, classify any failures by root cause (compilation error, assertion failure, or timeout), and return a structured summary to the parent agent.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5011e1c90>)])]>

また、.agents/agents/gemini-judge.md では、クロスモデルのコードレビュー担当者サブエージェントを以下のように定義できます。

code_block: <ListValue: [StructValue([('code', "---\r\nname:cross-model-judge\r\ndescription: Independent LLM-as-a-judge verifier that audits diffs and edge cases using Gemini Pro.\r\nmodel: pro\r\ntools:\r\n - read\r\n---\r\n\r\nReview the current workspace diff against the user's requirements. Check for regressions, missing edge-case tests, and security issues. Output a pass/fail verdict with specific line references."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500148450>)])]>

この設定により、高速な「テストと分類」のループを test-triager に委任し、cross-model-judge をトリガーして最終的なコード差分を検証できます。これにより、各モデルの強みを単一のワークフロー内で活かすことが可能になります。

ご利用にあたって

Claude Opus 5.5 と Claude Sonnet 5.5 は、Antigravity を使用している Google Cloud のお客様にご利用いただけます。

管理者（Gemini for Business）: サードパーティのパートナーモデルは、プールされている Gemini Enterprise Standard および Plus エディションの月間トークン割り当てから消費されることはありません。代わりに、既存の Google Cloud 請求先アカウントを通じて従量課金制で請求されるため、超過料金の設定を有効にする必要があります。Google Cloud コンソールで [Gemini Enterprise] > [設定] > [AI デベロッパーツール] に移動して、超過料金の請求、費用の上限、組織のパートナーモデルの承認を構成します。詳しい手順については、AI デベロッパーツールの設定方法をご覧ください。
管理者（Gemini プラットフォーム）: Gemini プラットフォームの API 経由で Antigravity をご利用の場合も、パートナーモデルを有効化できます。Model Garden で Claude モデルを有効化し、Anthropic の標準利用規約に同意してください。
開発者: Antigravity 2.0、Antigravity CLI、または Antigravity IDE 拡張機能を最新バージョンに更新し、モデル選択ツールを開いて（または /model を実行して）、タスクに適したモデルを選択します。エンタープライズガバナンスやマルチエージェント構成の詳細については、Google Antigravity Enterprise のドキュメントをご覧ください。ワークスペースの状態、開いているアーティファクト、ターミナルのコンテキストを保持したまま、同じ会話スレッド内のターン間でアクティブなモデルを切り替えることが可能です。

^{注: コンテキスト管理や要約といった高頻度で発生するクライアントサイドの調整処理のために、軽量なファーストパーティの Gemini モデルがバックグラウンドで引き続き稼働します。これらのモデルはファーストパーティトークンを消費するため、料金が発生する場合があります。}

- Google Cloud、プロダクトマーケティングマネージャー、Marialaura Garcia

- Google Antigravity、デベロッパーリレーションズ、Rich Hyndman

「MCP ツールボックス」Java SDK v1.0 のご紹介: 企業向けのエージェント型データアクセス

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

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

MCP ツールボックス v1.0 の画期的な発表に続き、「MCP ツールボックス」Java SDK バージョン 1.0 が正式にリリースされたことをお知らせいたします。

このリリースにより、世界で最も広く採用されているエンタープライズ向けエコシステムの一つで、最高水準の型安全なエージェントオーケストレーションが実現します。Java の成熟したアーキテクチャは、厳しい要求に対応できるよう構築されており、本番環境でミッションクリティカルな AI エージェントを安全にスケールするために必要な高い同時実行性、厳格なトランザクション整合性、堅牢な状態管理を提供します。

この投稿では、Java SDK v1.0 の新機能について説明し、実際の例を示しながら、独自の実装を始めるためのステップを解説します。

MCP: ユニバーサルインターフェース

現在、デベロッパーは複雑化する統合のボトルネックに直面しています。N 個の異なる AI モデルと M 個のエンタープライズデータソースがある場合、N × M 個のカスタム接続を構築、保護、維持する必要があります。このように統一されたインテグレーションレイヤがないため、エンジニアリングチームは、断片化されたアドホックなパイプラインが複雑に入り組んだ状態に頼らざるを得ません。その結果、エージェントアーキテクチャのスケーリングはすぐに持続不可能になり、機密性の高いエンタープライズデータベースが深刻なセキュリティ脆弱性、断片化されたアクセス制御、膨大なメンテナンスオーバーヘッドにさらされることになります。

Model Context Protocol（MCP）が解決する根本的な課題は、複雑に絡み合った独自のインテグレーションを解消することです。MCP は、AI オーケストレーションの「USB Type-C」のようなユニバーサルインターフェースとして機能し、モデルをデータソースから分離します。デベロッパーは、新しいモデルやデータベースごとにカスタムまたはマネージド API 統合コードを記述する代わりに、単一の標準化されたプロトコルに準拠してコードを記述します。このアプローチにより、MCP 準拠のエージェントは、MCP 対応のシステムとセキュアかつ即座にやり取りできます。MCP 接続により、デベロッパーは新しいモデルごとに個別のインテグレーションを構築することなく、エージェントを実世界のシステムに接続できます。

Java SDK v1.0 の新機能: 本番環境ワークロードに対応

「MCP ツールボックス」Java SDK の公開ベータ版を発表した際、Google の目標は、最高水準の型安全なエージェントオーケストレーションをエンタープライズ Java 環境に提供することでした。それ以来、Google はデベロッパーやオープンソースのコントリビューターと協力して API の堅牢化に努めてきました。

v1.0 リリースは、エンタープライズワークロードに適した、安定した後方互換性を備えた基盤となります。v0.2 リリース以降の新機能と堅牢化された機能は次のとおりです。

トランスポート層の抽象化と HttpMcpTransport: HttpMcpTransport とともに、クリーンなトランスポート層の抽象化を導入しました。この機能により、コアプロトコルロジックが基盤となる HTTP クライアントから分離されるため、ネットワーク実装の入れ替えや接続プールのカスタマイズが容易になります。
クライアント認証の疎結合化: 企業のセキュリティコンプライアンスを簡素化するため、CredentialsProvider クラスと AuthMethods クラスを使用してクライアント認証を切り離しました。認証情報はリクエストごとに非同期で解決されるため、チームはトークンを動的に更新したり、独自のトークンソースをプラグインしたりできます（ADC 経由の Google OIDC は標準で組み込まれており、それ以外は 1 つのメソッドを実装するだけのインターフェースです）。
デフォルトパラメータのサポート: ツールパラメータのデフォルト値をネイティブにサポートすることで、プロンプトのペイロードサイズを削減し、エージェントの信頼性を高めます。
バインドされたパラメータのプルーニング: サーバーサイドでバインドされた機密性の高いパラメータ（tenant_id など）が、公開されたツール定義から自動的に削除されるようになり、LLM による操作を防ぎます。
バージョン選択とセッショントラッキング: 標準化された MCP バージョン選択と堅牢なセッショントラッキングにより、一貫したプロトコルネゴシエーションと会話状態のライフサイクルを実現します。
HTTP 認証情報の漏洩に関する警告: 認証情報が平文の HTTP 接続で送信されようとしているときに、実行時に警告を発する組み込みの検出機能を追加しました。
汎用クライアントヘッダーのマップ: カスタムの企業プロキシヘッダー、トランザクショントレース ID、相関メタデータを、すべての送信リクエストに簡単に追加できます。

Java SDK v1.0 を使ってみる

「MCP ツールボックス」Java SDK は、企業チームがスムーズに利用できるように設計されています。pom.xml に次の依存関係を追加するだけで利用を開始できます。

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>1.0.0</version>\r\n</dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5000f7850>)])]>

実際の例: 自律型交通コンシェルジュ

Java SDK を AlloyDB と組み合わせて活用する例として、企業のユースケースを見てみましょう。

架空の都市間バス交通ネットワークである Cymbal Transit をご紹介します。利用者は、旅行を計画するのに、ネストされたプルダウンメニューを何度もクリックするような操作は望んでいません。次のように質問したいと考えています。

「明日の朝、ニューヨークからボストンまで移動する必要がある。ゴールデンレトリバーを連れて行くことはできる？連れて行ける場合は、最も早い便を予約して。」

AI エージェントがこの質問に答えるには、非構造化データ（ペットに関するポリシー）と構造化データ（運行スケジュール、座席の空き状況）を相互参照し、会話のコンテキストを維持しながらトランザクションを実行（予約）する必要があります。

基盤: ネイティブエンベディングを備えた AlloyDB スキーマ

この実装には、リレーショナルデータと高次元ベクトルをネイティブに処理できる AlloyDB を使用しました。そして、次のステートメントを使用してデータベーステーブルを作成しました。

code_block: <ListValue: [StructValue([('code', "-- Enable necessary extensions for semantic search and embeddings\r\nCREATE EXTENSION IF NOT EXISTS vector;\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration;\r\n\r\n-- Table 1: Transit Policies (Unstructured Data for RAG)\r\nCREATE TABLE transit_policies (\r\n policy_id SERIAL PRIMARY KEY,\r\n category VARCHAR(50),\r\n policy_text TEXT,\r\n policy_embedding vector(768)\r\n);\r\n\r\n-- Table 2: Intercity Bus Schedules (Structured Data)\r\nCREATE TABLE bus_schedules (\r\n trip_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n origin_city VARCHAR(100),\r\n destination_city VARCHAR(100),\r\n departure_time TIMESTAMP,\r\n arrival_time TIMESTAMP,\r\n available_seats INT DEFAULT 50,\r\n ticket_price DECIMAL(6,2)\r\n);\r\n\r\n-- Table 3: Booking Ledger (Transactional Action Data)\r\nCREATE TABLE bookings (\r\n booking_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n trip_id UUID REFERENCES bus_schedules(trip_id),\r\n passenger_id VARCHAR(100),\r\n status VARCHAR(20) DEFAULT 'CONFIRMED',\r\n booking_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP\r\n);"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7ff5000f6610>)])]>

インテントと SQL のマッピング: `tools.yaml`

MCP ツールボックスを使用すると、カスタムツールをセキュアに定義できます。LLM にデータベースへの直接アクセスを許可するのではなく、tools.yaml の設定によって、自然言語のインテントをパラメータ化された安全なクエリに直接マッピングします。

code_block: <ListValue: [StructValue([('code', 'kind: source\r\nname: alloydb\r\ntype: alloydb-postgres\r\nproject: my-project\r\nregion: us-central1\r\ncluster: my-cluster\r\ninstance: my-instance\r\ndatabase: postgres\r\n---\r\nkind: tool\r\nname: query-schedules\r\ntype: postgres-sql\r\nsource: alloydb\r\ndescription: Find available bus schedules between cities.\r\nparameters:\r\n - name: origin\r\n type: string\r\n description: The departure city name.\r\n - name: destination\r\n type: string\r\n description: The arrival city name.\r\n - name: limit\r\n type: integer\r\n description: Maximum number of schedules to return.\r\n default: 5\r\nstatement: |\r\n SELECT CAST(trip_id AS TEXT) AS trip_id, departure_time, ticket_price\r\n FROM bus_schedules\r\n WHERE lower(origin_city) = lower($1) AND lower(destination_city) = lower($2)\r\n ORDER BY departure_time ASC\r\n LIMIT $3'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500f2f190>)])]>

完全な YAML ファイルについては、mcp-toolbox-sdk-java リポジトリの tools.yaml ファイルをご覧ください。

Spring Boot のステートフルエージェントアーキテクチャ

エンタープライズアプリケーションで会話型 AI を構築するうえで最も難しいのは、状態の管理です。ユーザーが「空席がある便の出発時間は？」と尋ねた後、「午前 8 時の便を予約して」と言った場合、エージェントはターンをまたいで前のコンテキストを覚えておく必要があります。

「MCP ツールボックス」Java SDK を Spring Boot および LangChain4j と併せて使用すると、HTTP セッションで会話のメモリを適切に維持し、エージェントを次の 2 つの宣言型コンポーネントに明確に分離できます。

HTTP セッションを介してプロンプト、ツール、会話のメモリを管理する宣言型エージェントインターフェース。
エージェントのリクエストを MCP ツールボックスサーバーに直接ルーティングするツール実行サービス。

code_block: <ListValue: [StructValue([('code', 'interface TransitAgent {\r\n @SystemMessage({\r\n "You are the Cymbal Transit Concierge.",\r\n "Use the \'querySchedules\' tool for finding schedules.",\r\n "Use \'bookTicket\' to execute transactions.",\r\n "Use \'searchPolicies\' to look up luggage and pet rules."\r\n })\r\n String chat(@MemoryId String sessionId, @UserMessage String userMessage);\r\n}\r\n\r\n@Service\r\nclass TransitAgentTools {\r\n // These methods automatically invoke our MCP Toolbox server!\r\n @Tool("Query specific schedules between an origin and destination city.")\r\n public String querySchedules(String origin, String destination) { ... }\r\n\r\n @Tool("Book a ticket for a passenger.")\r\n public String bookTicket(String tripId, String passengerName) { ... }\r\n\r\n @Tool("Search transit policies for luggage and pet rules.")\r\n public String searchPolicies(String query) { ... }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500f2cc90>)])]>

@MemoryId アノテーションがセッショントラッキングを抽象化している点に注目してください。これにより、Spring Boot は会話のコンテキストをユーザーの HTTP セッションに自動的に関連付けることができます。その一方で、LangChain4j と MCP ツールボックスが舞台裏でスキーマ変換とツールルーティングを処理するため、手動で if/else 文によるインテント解析を書く必要はありません。

「MCP ツールボックス」Java SDK と LangChain4j を組み合わせることで、関心の分離を明確にし、手間をかけずに状態を管理できるようになります。

ボイラープレート不要のセッション管理: @MemoryId String sessionId パラメータにより、会話履歴がユーザーの HTTP セッションに直接バインドされます。
宣言型エージェントコントラクト: TransitAgent インターフェースは、複雑なプロンプトテンプレートを使用せずに、モデルのペルソナとシステム指示を定義します。
型安全なツールの実行: TransitAgentTools Spring サービスが、リモート MCP データベースツールをネイティブ Java メソッドとしてラップします。

このアーキテクチャにより、エージェントのモジュール性を保つことができます。インターフェースでプロンプトガイダンスを改良し、ユーザーセッションを自動的に管理しながら、密結合させることなく MCP ツールボックスを介して安セキュアなデータベースクエリを実行できます。

すべてをつなぎ合わせる: Java v1.0 におけるツールのリスト表示、呼び出し、実行

次に、TransitAgentTools インターフェースの内部を見てみましょう。Spring @Service の LangChain4j @Tool メソッド内では、MCP ツールボックス Java SDK が、Java サービスメソッドを tools.yaml ファイルで定義された MCP ツールに橋渡しするという複雑な処理を肩代わりします。型安全なコードを数行記述するだけで、新しい v1.0 の疎結合な認証情報とヘッダーの抽象化を使用してクライアントを初期化できます。

code_block: <ListValue: [StructValue([('code', '// 1. Initialize the Client with Decoupled Auth and Custom Headers (v1.0)\r\nString serviceUrl = "https://toolbox-my-project-uc.a.run.app/mcp";\r\nMcpToolboxClient mcpClient = McpToolboxClient.builder()\r\n .baseUrl(serviceUrl)\r\n .credentialsProvider(new GoogleCredentialsProvider(serviceUrl)) // Decoupled OIDC credentials\r\n .headers(Map.of( // Generic client headers\r\n "X-Correlation-ID", "enterprise-session-abc123",\r\n "X-Client-Platform", "Spring-Boot"\r\n ))\r\n .build();\r\n\r\n// 2. Listing Discoverable Tools\r\nmcpClient.listTools().thenAccept(tools -> {\r\n System.out.println("Successfully discovered " + tools.size() + " tools.");\r\n});\r\n\r\n// 3. Invoking a Tool (Read-Only Data with Default Parameter Support)\r\n// "limit" is omitted: the SDK fills it from the default in the tool definition\r\nString schedules = mcpClient.loadTool("query-schedules")\r\n .thenCompose(tool -> tool.execute(Map.of(\r\n "origin", "New York",\r\n "destination", "Boston")))\r\n .join().text();\r\n\r\n// 4. Executing a Transactional Tool (Using Bound Parameters)\r\nAuthTokenGetter toolAuthGetter = () -> CompletableFuture.completedFuture(myIdToken);\r\n\r\nString bookingConfirmation = mcpClient.loadTool("book-ticket", Map.of("google_auth", toolAuthGetter))\r\n // Bind the authenticated user context securely. bindParam returns a new immutable\r\n // Tool, and the bound parameter is pruned from the definition exposed to the LLM!\r\n .thenCompose(tool -> tool.bindParam("passenger_name", "Jane Doe")\r\n // Execute the mutable transaction\r\n .execute(Map.of("trip_id", "123e4567-e89b-12d3-a456-426614174000")))\r\n .join().text();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500f2df50>)])]>

セキュアバイデフォルト: 認証とデプロイ

AI エージェントを本番環境に移行するには、堅牢な認証情報処理と、需要に応じてスケールするインフラストラクチャが必要です。さまざまな環境で認証情報の安全性を確保し、Cloud Run に独立してデプロイする方法を見ていきましょう。

アプリケーションのデフォルト認証情報（ADC）と安全性

GoogleCredentialsProvider サービスを使用すると、Java アプリはアプリケーションのデフォルト認証情報（ADC）を介して、実行環境（ローカルまたは Google Cloud）から安全な ID を継承します。ハードコードされた鍵は不要で、OIDC トークンがオーディエンスごとにバックグラウンドで生成され、キャッシュに保存されます。さらに、v1.0 では HTTP 認証情報の漏洩警告が提供されます。これは、認証情報が平文の HTTP 接続で送信されようとしていることを自動的に検出し、HTTPS に切り替えるよう指示するランタイム警告を発します。

フリートを Cloud Run にデプロイ

MCP ツールボックスと Spring Boot エージェントは完全に疎結合化されているため、Google Cloud Run で独立してスケールし、高い同時実行性とステートフルな会話の要件に対応できます。

Cloud Run でツールボックスをセットアップして構成するには、オープンソースのデータベース向け MCP ツールボックスをダウンロードしてから、デプロイガイドに沿って操作します。

使ってみる

「MCP ツールボックス」Java SDK v1.0 を使用すると、企業の Java チームは Spring Boot と LangChain4j エージェントをツールボックスサーバーに接続し、そこから AlloyDB やその他のサポートされているデータソースに接続できます。ツールボックスを使用すると、引数は JVM から送信される前にツール定義に照らして検証され、認証は疎結合化され、カスタムヘッダーがすべての送信リクエストに添付されます。導入手順は次のとおりです。

ステップ 1: 依存関係を追加する

SDK を使用して開発を始めるには、Maven プロジェクトの pom.xml ファイルに次の依存関係を追加します。

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>1.0.0</version>\r\n \r\n </dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500f2fe50>)])]>

ステップ 2: リソースとデモを確認する

GitHub リポジトリ: データベース向け MCP ツールボックスを操作するための Java SDK
公式ドキュメント: MCP Toolbox for Databases（データベース向け MCP ツールボックス）

デモアプリケーション:「MCP ツールボックス」Java SDK V1.0 の最新版を体験するには、サンプルアプリケーションである Cymbal Transit プロジェクトをお試しください。

Gradle の実装

チームが Maven ではなく Gradle を使用している場合は、この依存関係を書き換える必要がある点にご注意ください。

code_block: <ListValue: [StructValue([('code', "implementation 'com.google.cloud.mcp:mcp-toolbox-sdk-java:1.0.0'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5024bc310>)])]>

バージョンの自動追跡

この設定を自動化された内部リポジトリにコピーする場合は、XML コメント  はそのままにします。これは、リリースマネージャーのデプロイスクリプトがバージョンを自動的に更新するために必要です。

最新のエージェントツールとサーバーを、安定した「MCP ツールボックス」Java SDK を使用してエンタープライズ Java アプリケーションに統合できるようになりました。今すぐお試しください。

- Google、スタッフデベロッパーアドボケイト Abirami Sukumaran

共同執筆者:

- Google、戦略的クラウドエンジニア Stenal Jolly

- Google、ソフトウェアエンジニア Anubhav Dhawan

Agent Development Kit は 5 つの言語に対応

Wed, 21 Oct 2026 02:00:00 +0000

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

エージェントといえば Python というイメージがありますが、実際は必ずしもそうではありません。現在の先進的なエコシステムでは、エージェントは Cloud Run 上で Go マイクロサービスとして大規模に同時実行されることもあれば、ブラウザタブ内で動作して Chrome のオンデバイスモデルを呼び出すこともあります。しかし、エージェントフレームワークの多くは Python のみのスタックを想定しています。そのため、エージェントワークロードのためだけに Python サービスをスピンアップしたり、エージェントオーケストレーションロジックを独自の言語でゼロから構築したりすることが必要になります。

Google の Agent Development Kit（ADK）は、Python、Go、TypeScript、Java、Kotlin をサポートしているため、このようなトレードオフは発生しません。ADK の各バージョンはそれぞれの言語のランタイムと型システムに合わせてゼロから構築されており、かつ、オープンプロトコルによる相互運用性を備えた統合アーキテクチャを共有しています。

共通の基盤

5 つの言語すべてが同じオープンプロトコルをサポートしているため、使用する言語によってアーキテクチャが固定されることはありません。すべての言語の ADK に Model Context Protocol クライアントが含まれており、MCP サーバーとして公開されたカスタムツールを、どの言語からでもすぐに呼び出すことができます。

マルチエージェントシステムの場合、ADK は Agent2Agent（A2A）プロトコルをサポートしているため、エージェントは HTTP 経由でリモートエージェントと通信できます。エージェントが異なる言語やフレームワークで記述されていても、A2A を通じて相互運用することができます。

エージェントファースト開発の第一歩

まず、1 回限りの設定コマンドを実行して Google Cloud 認証を確認し、CLI をインストールします。その後、Antigravity、Claude Code、Codex などのコーディングエージェントでファーストパーティの ADK スキルを設定します。

code_block: <ListValue: [StructValue([('code', 'uvx google-agents-cli setup'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501646ed0>)])]>

次に scaffold コマンドを実行して、A2A エンドポイントと Cloud Run、Gemini Enterprise Agent Runtime、または Google Kubernetes Engine（GKE）のデプロイ構成を含む作業プロジェクトを生成します。

code_block: <ListValue: [StructValue([('code', '# Scaffold an ADK project (use --agent adk for Python or --agent adk_go for Go)\r\nagents-cli scaffold create my-go-agent \\\r\n --agent adk_go \\\r\n --deployment-target cloud_run \\\r\n --region us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501644f90>)])]>

ADK for Python リポジトリと ADK for Kotlin リポジトリの両方とも、ソースツリーにはエージェントビルダーのスキルも含まれています。また、adk.dev/llms.txt リソースにより、5 つの言語すべてのコーディングエージェントでオンデマンドの API ドキュメントを利用できます。

コーディングエージェントスキルがプロジェクトの基盤を構築し、MCP と A2A が 5 つの言語ランタイムすべてを接続します。

各 ADK の実践的なサンプル

5 つの言語の違いを感じるには、各言語で同じ天気ツールを定義し、その設計とランタイムの連携方法を確認することが最もわかりやすいでしょう。

Python

ADK for Python では、デコレータやスキーマビルダークラスは必要ありません。プレーンな Python 関数を tools パラメータに渡すと、ADK の起動時にシグネチャ、型ヒント、docstring が検査され、ツール宣言と Pydantic パラメータスキーマが自動的に構築されます。

code_block: <ListValue: [StructValue([('code', 'from google.adk.agents.llm_agent import Agent\r\n\r\n\r\ndef get_weather(city: str) -> dict:\r\n """Retrieves the current weather report for a specified city.\r\n\r\n Args:\r\n city (str): The name of the city for which to retrieve the weather report.\r\n """\r\n return {"status": "success", "report": f"Sunny and 72F in {city}."}\r\n\r\n\r\nroot_agent = Agent(\r\n name="weather_agent",\r\n model="gemini-3.8-flash",\r\n instruction="Answer questions about the weather in a city.",\r\n tools=[get_weather],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7ff5016466d0>)])]>

Python は迅速なプロトタイピングが可能であるだけでなく、ADK のリファレンス実装でもあり、最も幅広い Google Cloud の統合（BigQuery、Spanner、Bigtable）とモデルアダプタ（Gemini、Anthropic、OpenAI、LiteLLM）が提供されています。adk eval コマンドまたは agents-cli eval run コマンドと組み合わせて評価ツールを使用することで、継続的インテグレーション（CI）でゴールデンデータセットを基準としてエージェントの軌跡をスコアリングし、本番環境サービスが別の言語で実行されている場合でも、システム全体をエンドツーエンドでテストできます。

Go

Python がテストと評価に優れている一方で、ADK for Go は本番環境のバックエンドエンジニアリングに最適です。

Go ツールの関数は、agent.Context 構成と厳密に型指定された入力構造体を受け取ります。functiontool.New 関数は、Go ジェネリクスを使用して、struct タグから入力スキーマと出力スキーマの両方を推測します。

code_block: <ListValue: [StructValue([('code', 'type GetWeatherArgs struct {\r\n\tCity string `json:"city" jsonschema:"The city to look up weather for."`\r\n}\r\n\r\ntype GetWeatherResult struct {\r\n\tReport string `json:"report"`\r\n}\r\n\r\nfunc getWeather(_ agent.Context, args GetWeatherArgs) (GetWeatherResult, error) {\r\n\treturn GetWeatherResult{Report: "Sunny and 72F in " + args.City}, nil\r\n}\r\n\r\nweatherTool, err := functiontool.New(functiontool.Config{\r\n\tName: "get_weather",\r\n\tDescription: "Retrieves the current weather report for a city.",\r\n}, getWeather)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501644690>)])]>

functiontool.New 関数はハンドラのシグネチャに対してジェネリクスを活用しているため、Go コンパイラは関数が想定されるコントラクトと一致することを確認してからバイナリを実行します。

Go は、Python の次に ADK 2.0 Graph Workflow ランタイムが提供された言語でもあります。LLM 推論と併せて決定的な制御フローを使用する必要がある場合は、workflow.New 関数を使用して、エージェントとプレーンな Go 関数を条件付きルーティングと並列ステップを持つ有向グラフに接続します。

code_block: <ListValue: [StructValue([('code', 'ag, err := workflowagent.New("order_pipeline", []workflow.Edge{\r\n\t{From: workflow.Start, To: triageNode},\r\n\t{From: triageNode, To: fulfillNode, Route: workflow.StringRoute("fulfill")},\r\n\t{From: fulfillNode, To: notifyNode},\r\n})'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501644810>)])]>

Go が真価を発揮するのは、本番環境でCloud Run および GKE と組み合わせて使用する場合です。コンパイルされた Go エージェントは、約 2 MiB の Google distroless 静的ベースイメージにパッケージ化され、言語 VM や重い依存関係ツリーはありません。静的な Go バイナリはコンテナが起動するとすぐにポートにバインドされ、動的言語のモジュールインポートや、JVM サービスの JAR の展開と JIT のウォームアップはスキップされます。

Go の同時実行モデルは、実行されたエージェントのワークロードと優れた適合性を発揮します。各 goroutine は 2 KB のスタックと最小限のスケジューリングオーバーヘッドで開始されるため、単一のインスタンスで数千の同時ストリーミングリクエストとツール呼び出しを多重化できます。ADK for Go には、組み込みの A2A サーバーハンドラと OpenTelemetry トレースも含まれています。

TypeScript

TypeScript は JavaScript へのコンパイル時に型アノテーションが消去されるため、ランタイムリフレクションは使用できません。代わりに、ADK for TypeScript は Zod と連携します。z.object(...) スキーマを FunctionTool 関数に渡すと、TypeScript はその単一の宣言から execute コールバックのパラメータ型を静的に推測します。

code_block: <ListValue: [StructValue([('code', 'import { FunctionTool, LlmAgent } from "@google/adk";\r\nimport { z } from "zod";\r\n\r\nconst getWeatherTool = new FunctionTool({\r\n name: "get_weather",\r\n description: "Retrieves the current weather report for a city.",\r\n parameters: z.object({\r\n city: z.string().describe("The name of the city."),\r\n }),\r\n execute: async ({ city }) => {\r\n return { status: "success", report: `Sunny and 72F in ${city}.` };\r\n },\r\n});\r\n\r\nexport const rootAgent = new LlmAgent({\r\n name: "weather_agent",\r\n model: "gemini-3.8-flash",\r\n instruction: "Answer questions about the weather in a city.",\r\n tools: [getWeatherTool],\r\n});'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501645a10>)])]>

ランタイム入力の検証、モデルに送信される JSON スキーマ、execute コールバック内の IDE 予測入力はすべて、信頼できる唯一の情報源から取得されます。

TypeScript は ADK 2.0 Graph Workflow エンジンでも動作し、スタンドアロンのブラウザバンドルが提供されています。Node.js サービス以外にも、ページレベルのツール用の WebMCP と Chrome のオンデバイス Prompt API を使用して、ブラウザタブで ADK エージェントを直接実行することができます。

Java

ADK for Java は、Maven、Gradle、Spring Boot で標準化している場合に最適です。メソッドパラメータに @Schema アノテーションを追加し、Fluent API である LlmAgent.builder() を使用してエージェントを組み立てます。

code_block: <ListValue: [StructValue([('code', 'public class WeatherTools {\r\n public static Map<String, String> getWeather(\r\n @Schema(name = "city", description = "The name of the city")\r\n String city) {\r\n return Map.of("status", "success", "report", "Sunny and 72F in " + city);\r\n }\r\n}\r\n\r\nLlmAgent agent = LlmAgent.builder()\r\n .name("weather_agent")\r\n .model("gemini-3.8-flash")\r\n .instruction("Answer questions about the weather in a city.")\r\n .tools(FunctionTool.create(WeatherTools.class, "getWeather"))\r\n .build();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501645510>)])]>

実行時には、ランナーが RxJava を介してエージェントイベントをリアクティブにストリーミングします。ローカルテストと既存の JVM アプリ向けに、ADK for Java には Maven Dev UI プラグインと、Spring AI および LangChain4j 用のファーストパーティブリッジが提供されています。

Kotlin

ADK for Kotlin は、ビルド時の安全性を重視しています。Kotlin Symbol Processing（KSP）コンパイラプラグインが、ビルド時に @Tool アノテーションと @Param アノテーションを読み取り、ツールスキーマをバイトコードに直接出力します。

code_block: <ListValue: [StructValue([('code', 'class WeatherTools {\r\n @Tool(\r\n name = "get_weather",\r\n description = "Retrieves the current weather report for a city.",\r\n )\r\n suspend fun getWeather(\r\n @Param("The name of the city.") city: String\r\n ): Map<String, String> = mapOf("status" to "success", "report" to "Sunny and 72F in $city")\r\n}\r\n\r\nval agent = LlmAgent(\r\n model = Gemini("gemini-3.8-flash"),\r\n name = "weather_agent",\r\n instruction = Instruction("Answer questions about the weather in a city."),\r\n tools = WeatherTools().generatedTools(),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501644090>)])]>

ツールシグネチャが、サポートされていない型を使用したり、null 非許容パラメータにデフォルト値を宣言したりした場合、本番環境で問題が発生するのではなく、Gradle ビルドがただちに失敗します。.generatedTools() 関数はランタイムリフレクションを使用しないため、Android R8 圧縮後も保持されます。

リフレクションを使用しないこの設計により、エージェントループ全体を Android 上でローカルに実行できます。また、JVM サーバーをサポートしており、Spring AI ブリッジや試験運用版の ADK 2.0 グラフワークフローなどを使用できます。オンデバイスでは、ADK for Kotlin は LiteRT-LM（ツール呼び出し）および ML Kit（Gemini Nano、テキスト生成）と統合できます。さらに、Room および AppSearch と連携してローカル状態を管理したり、Android AppFunctions と連携して OS レベルのアクションを実行したりすることができ、このいずれにもネットワーク接続は必要ありません。

妥協のない選択

ADK は 5 つの言語にネイティブで対応しているため、組織全体で 1 つのランタイムに統一する必要がありません。すべてのバージョンが MCP と A2A に対応しており、システムの各コンポーネントで最適な言語を使用できます。

Google の ADK で、どの言語を使用してエージェントを構築しましたか？皆様がどのようなスタックを使用しているか、X、LinkedIn、Bluesky でぜひ教えてください。

- デベロッパーリレーションズ担当ディレクター、Karl Weinmeister

AI 推論モデル提供のためのネットワーキング - GKE のみ、およびその他すべてのバックエンド

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

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

企業や個人の開発者は、複数の AI 推論モデルを頻繁に実行しています。適切なアーキテクチャを使用することで、モデルの呼び出し方法を簡素化すると同時に、一元化されたガバナンスを提供できます。この投稿では、ネットワークにおける AI 推論モデルの提供に焦点を当てた 2 つのリファレンスアーキテクチャについて説明します。1 つは Google Kubernetes Engine（GKE）用、もう 1 つはその他のすべてのバックエンドタイプ用です。まず、後ほど紹介するリファレンスアーキテクチャの共通点について説明します。次に、GKE バックエンドのアーキテクチャに固有のコンポーネントについて説明し、最後に、すべてのバックエンドタイプに共通するアーキテクチャの要素を確認します。

エントリポイント

推論呼び出しのフロントエンドとして機能する、高い安定性、セキュリティ、信頼性を持つエントリポイントの背後にモデルのデプロイを公開できます。このエントリポイントは、ポリシー、セキュリティ、ロジックを適用できる制御ゾーンとしても機能します。Cloud ロードバランサと推論ゲートウェイはどちらもエントリポイント機能を提供します。これらのタイプのエンドポイントは、TLS によるセキュアな接続の終端、API 管理コンポーネントとの統合、Service Extensions による機能の拡張、Model Armor の機能を活用したセキュリティ強化が可能です。

設計における共通サービス

どちらのリファレンス設計でも、次のサービスを使用します。

Private Service Connect 推論エンドポイント: 消費者の Virtual Private Cloud（VPC）ネットワーク内にエントリポイントを固定します。トラフィックはプライベート内部 IP アドレスに到達するため、推論呼び出しはプライベートネットワーク内に保持されます。
Apigee API Management（省略可）: Apigee Extension Processor コールアウトを介して統合され、リクエストがコンピューティングリソースに到達する前に、クライアント ID の検証、レート制限、割り当ての適用を処理します。
Model Armor: インライン AI 安全性チェックポイントとして機能し、プロンプトインジェクションや機密データの漏洩がないか、プロンプトと出力補完をスクリーニングします。

GKE のみで提供される設計パターン

このセクションでは、GKE のみのバックエンド設計に焦点を当てます。エンドツーエンドのコンセプトを完全に理解するには、アーキテクチャに関するドキュメント GKE での AI 推論モデル提供のためのネットワーキングをすべてお読みください。設計パターンは、次の図に基づいています。

前のセクションで特定した共通サービスに加えて、GKE の設計では次のコンポーネントを使用します。

GKE Inference Gateway: 内部アプリケーションロードバランサ（gke-l7-rilb）としてデプロイされます。受信リクエストのペイロードを解析し、HTTPRoute ルールを評価して、適切なモデル提供ターゲットにクエリを転送する、特殊な内向きエンジンとして機能します。
推論プール: 同じモデルのレプリカを含む論理グループ。Gateway はプロンプトを受け取ると、HTTPRoute ルールを評価し、モデル識別子に基づいて適切な推論プールを選択します。プールには初期サイズがあり、動的に自動スケーリングされるように構成できます。
モデルレプリカセット: シングルノードまたはマルチノードの GPU または TPU ノードプールにデプロイされた個々のモデルレプリカ（推論サーバーインスタンス）。レプリカセットは、これらのモデルレプリカの均一なグループを表します。

GKE のトラフィックフローの例

この GKE ベースのアーキテクチャを使用してバックエンドモデルを呼び出すクライアントアプリケーションは、次のようなフローをたどります。

内向き: コンシューマー VPC 内のクライアントアプリケーションが、ローカルの Private Service Connect エンドポイントに対して OpenAI 互換の API 呼び出しを発行し、リージョン内部アプリケーションロードバランサを使用して GKE Inference Gateway に直接ルーティングします。
ペイロード検査: Gateway は、リクエスト本文で指定されたターゲットモデルパラメータを読み取り、HTTP ヘッダーに追加します。
コントロールプレーンの検証: Apigee が使用されている場合、クライアントの認証情報と割り当てがチェックされます。Model Armor がプロンプトをスクリーニングし、ポリシー違反やデータ漏洩がないかを確認します。
バックエンドの選択: Gateway は HTTPRoute マッピングを評価してターゲットプールを特定し、プレフィックスキャッシュ共有コンテキストを照合して、リアルタイムの Prometheus データに基づいて最も負荷の低い GPU または TPU レプリカにルーティングします。
外向き: レプリカが推論ワークロードを実行します。出力トークンは Model Armor を通過して最終的なレスポンス検証が行われ、その後、プライベート接続を介してストリーミングで送り返されます。

すべてのバックエンドで提供される設計パターン

このセクションでは、推論に使用できる複数のバックエンドタイプに焦点を当て、次の図に示すアーキテクチャの概要を説明します。エンドツーエンドのコンセプトを完全に理解するには、アーキテクチャに関するドキュメントすべてのバックエンドでの AI 推論モデル提供のためのネットワーキングをすべてお読みください。

GKE、Cloud Run、Agent Platform、オンプレミスデータセンター、外部クラウドなどの混合環境にまたがるアーキテクチャでは、次のコンポーネントが追加で使用されます。

リージョン内部アプリケーションロードバランサ: ルーティングロジック、SSL 終端、Service Extensions コールアウトを管理する、中央のレイヤ 7 ルーティングプロキシとして機能します。
推論ペイロードプロセッサ（Service Extensions）: これは、GKE Inference Gateway で使用される本文ベースのルーティングに似ていますが、アプリケーションロードバランサでこの機能を有効にするには、Service Extensions が必要です。軽量の Cloud Run コールアウトが、受信した OpenAI API リクエストの JSON 本文を検査し、ターゲットモデル識別子を抽出して、URL マップによるルーティングを実行するために X-Gateway-Model-Name ヘッダーを書き込みます。
ネットワークエンドポイントグループ（NEG）: 書き込まれたモデルヘッダーに基づいて、異種バックエンドへの柔軟なルーティングを実現します。

すべてのバックエンドのトラフィックフローの例

このアーキテクチャを使用してバックエンドモデルを呼び出すクライアントアプリケーションは、次のようなフローをたどります。

プライベート内向き: クライアントアプリケーションは、プライベート IP アドレス空間を介して Private Service Connect エンドポイントをターゲットにします。リージョン内部アプリケーションロードバランサがリクエストを受信します。
モデル名の抽出: ロードバランサは、ペイロードを Cloud Run 本文ベースのルーターコールアウトに送信します。このコールアウトは、JSON ペイロードを検査して X-Gateway-Model-Name ヘッダーを挿入します。
ポリシーと安全性の適用: リクエストは Apigee に渡されて ID と割り当てが検証され、その後 Model Armor に渡されて機密データが削除され、悪意のあるプロンプトがブロックされます。
NEG ルーティング: ロードバランサの URL マップがモデルヘッダーを検査し、一致するバックエンド NEG（Agent Platform、GKE、Cloud Run、ハイブリッド、インターネット）にリクエストを転送します。
プライベート配信: ターゲットバックエンドがモデルプロンプトを実行し、Model Armor が補完をスクリーニングして、結果が内向きパスに沿ってプライベートに返されます。

次のステップ

Google Cloud での AI ワークロードの構築について詳しくは、以下をご覧ください。

ドキュメントセット: エージェント型 AI アーキテクチャガイド
アーキテクチャセンター: Google Cloud におけるマルチエージェントプライベートネットワーキングパターン
ドキュメント: Gemini Enterprise Agent Platform のネットワーキングアクセスの概要

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

SRE ブックの 10 年間:『Site Reliability Engineering』第 2 版のご紹介

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

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

10 年前、Google は O'Reilly Media から『Site Reliability Engineering: How Google Runs Production Systems』を出版しました。大規模なインフラストラクチャを管理する Google の手法を集めたものとして始まった本書はベストセラーとなり、多くの組織がそこに示された信頼性プラクティス（スケーラブルで信頼性が高く、持続可能なシステムを構築するためにソフトウェアエンジニアリングを運用に適用すること）を採用するきっかけとなりました。

過去 10 年間で、コンピューティング環境は大きく変化しました。AI、マイクロサービス、マルチクラウドデプロイ、サーバーレスパラダイム、プラットフォームエンジニアリングはすべて、ソフトウェアの構築と運用方法を再構築しました。このたび、本書の出版 10 周年を記念して、全面的に改訂された Google SRE ブック第 2 版を発表できることを嬉しく思います。Google 社内および業界全体で得た 10 年間の教訓を反映し、今日の運用上の課題に合わせた最新のガイダンスを提供します。

改訂する理由

初版を出版した当時、多くの組織はクラウドへの初期移行に注力しており、モノリシックアーキテクチャからの脱却を始めたばかりでした。昨今、組織が高速かつグローバル規模でソフトウェアを提供する中で、課題はもはやクラウドインフラストラクチャの導入ではなく、極めて複雑な状況に直面しながらも高い信頼性を維持することです。

最新の本番環境は、常に変化する状況下で運用されています。システムの境界はより複雑になり、依存関係は深まり、障害モードはこれまで以上に複雑化して深刻な被害をもたらすようになっています。生成 AI のようなリソースを大量に消費するワークロードの急増により、インフラストラクチャ管理における経済性と運用要件が変化しています。

この第 2 版を執筆するにあたり、私たちは一度立ち止まって、現代の環境で SRE を適切に実装するために何が必要かを評価する必要がありました。

10 年間の進化: SRE 手法の進歩

第 2 版では、サイト信頼性エンジニアリングの基礎的なプラクティスが過去 10 年間でどのように成熟し、タスク固有の手動作業から、プラットフォーム全体の自動化機能へとシフトしたのかを深く掘り下げて解説しています。以下はその例です。

SLO とエラーバジェット: 2016 年、チームは基本的な可用性指標と手動のエラーバジェットポリシーに依存していました。現在は、動的なバーンレートアラートと自動化されたポリシー適用を組み込んだ、ユーザー中心の多層 SLO へと成熟しています。

モニタリングとオブザーバビリティ: 初期のセットアップは、静的なダッシュボード、基本的なログ、手動のアラートトリアージが中心でした。最新のオブザーバビリティは、OpenTelemetry、分散トレース、自動化された異常相関を活用して、根本原因を迅速に特定します。

自動化とプラットフォーム: 運用は、個別のタスク用にカスタムスクリプトを作成することから、宣言型の Infrastructure as Code、社内開発者プラットフォーム、復元力のある自己修復システムを使用することへと移行しています。

信頼性テスト: 定期的なゲームデーや合成負荷テストのみに頼るのではなく、最新のエンジニアリングでは、継続的なレジリエンスチェック、自動化されたパイプラインテスト、本番環境でのライブカナリア検証を組み込んでいます。

容量とリソースの管理: 手動でのプロビジョニングや静的な予測は、動的な自動スケーリング、クラウド FinOps との連携、GPU および TPU ワークロードに特化したコストとクラスタの最適化に置き換えられました。

組織モデル: SRE は、特定のアプリケーションに割り当てられた専任チームの枠を超えて拡大しています。昨今の組織は、ハイブリッドモデル、プラットフォームエンジニアリングとの統合、各プロダクトチームに配置された信頼性チャンピオンを取り入れています。

AI 時代の SRE

さらに、SRE と AI には相互に影響し合う 2 つの関係があります。それは、SRE が AI インフラストラクチャをいかに支えるか、そして SRE チームが AI を活用していかに運用の信頼性を高めるか、という点です。

大規模言語モデル（LLM）や基盤モデルを実行すると、信頼性に関する新たな課題が生じます。本書では、AI インフラストラクチャを大規模に運用するための次の手法を概説しています。

大規模な GPU および TPU ハードウェアクラスタの信頼性とネットワークトポロジの管理
AI 固有の非決定論的な出力とレイテンシ特性のモニタリング
継続的なモデルトレーニング、ファインチューニング、データ処理のためのパイプライン信頼性の確保

AI は、信頼性エンジニアの能力を何倍にも引き上げる存在として急速に浸透しています。第 2 版では、人間の業務効率を向上させるための次の実践的なフレームワークを紹介しています。

生成 AI ツールを使用して、リアルタイムのインシデントトリアージと事後分析の生成を支援
自然言語クエリを使用して複雑なシステムテレメトリーを調査
予測 ML モデルを使用して、サービス停止が発生する前にリソースのボトルネックを特定

変わらない点: 文化の重要性

テクノロジーとアーキテクチャは進化し続けていますが、SRE の基本原則は変わらず、信頼性を重視する文化を確立するための鍵となっています。そのため、第 2 版では、システムエンジニアリングの人的要素と、それを実現する方法を改めて強調し、詳しく解説しています。

この分野の初心者、実務担当者、エンジニアリングマネージャー、テクノロジーエグゼクティブのどなたであっても、改訂された『Site Reliability Engineering』第 2 版は、次世代の本番環境システムの決定版ロードマップとして役立ちます。

書籍版（Google ブックスを参照）またはデジタル版を O'Reilly から今すぐご注文いただけます。

- SRE プログラムマネージャー、Betsy Beyer

- ソフトウェアエンジニア、サイト信頼性エンジニア、David Huska

低コストでスムーズな開発を実現する Managed Lustre を誰でも利用可能に

Sun, 18 Oct 2026 16:35:00 +0000

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

本記事は、Google Cloud が TB/秒のスループット、大規模クライアント環境下でのミリ秒未満のレイテンシ、POSIX 対応といった高性能並列ファイルシステムの基本価値を、より幅広いユースケースとユーザーに提供している方法を紹介する 2 部シリーズの第 1 回です。

これまで、並列ファイルシステムはコストがかかり、特殊な向けであったため、コールドデータはファイルシステムの外部に保存する必要がありました。また、AI 開発者は、コードの記述、ライブラリのコンパイル、リポジトリの管理のために、低速な環境を別途維持しなければなりませんでした。このような境の分断は、手動でのデータステージング、データセットのコピー、ばらばらな名前空間の管理といったトイルを増大させていました。

Google Cloud Managed Lustre は、1 GB あたり月額 6 セントのダイナミックティアと、さまざまな開発タスクやワークロード向けに Managed Lustre のパフォーマンスを最適化することで、これらの問題を解決します。これにより、Managed Lustre は、高パフォーマンスの AI および HPC ワークロードのための「ワンストップショップ」となります。

低コスト: ダイナミックティアで Lustre をより低コストで利用

Managed Lustre のダイナミックティアは、ホットデータに対してミリ秒未満のレイテンシを実現し、すべてのデータを単一の名前空間に保存できます。費用は月額わずか 6 セント/GB*です。

スループット、容量スケール、クライアントスケール: スループットは最大 80 PB の容量まで直線的にスケールされます。また、ホットデータのミリ秒未満のレイテンシは、数万のクライアントにスケールしても安定して維持されます。
単一の定額料金: 予測可能な料金体系です。ディスクメディアタイプ、名前空間内のデータ移動、メタデータ IOPS に対する個別の料金は発生しません。
読み取りレイテンシ: 高パフォーマンスキャッシュ（SSD）ではミリ秒未満のレイテンシを実現します。容量プール（「HDD」）は Google Cloud Hyperdisk Throughput を基盤に構築されており、平均読み取りレイテンシは 10～30 ミリ秒です。

ダイナミックティアに推奨されるワークロード

マルチエポックトレーニングや最適化されたフェッチサイズでのトレーニング: ホットデータは、最初の実行後に高パフォーマンスキャッシュ（SSD）に昇格されます。データプリフェッチを大きくすると、ダイナミックティアの費用構造を活かしつつ、低レイテンシの SSD のメリットを享受できます。
書き込み負荷の高いチェックポイント処理: バースト的なチェックポイントの書き込みは、高パフォーマンスキャッシュに直接保存されます。古いチェックポイントは、透過的に容量プール（HDD）に降格されます。
迅速なチェックポイント復元: 新しいチェックポイントは高パフォーマンスキャッシュに書き込まれるため、低レイテンシでのチェックポイント復元が可能になります。
開発者向けの快適な操作性: git クローン、ライブラリのコンパイル、ノートブックの実行などの低レイテンシタスクは、大規模なトレーニングセットをホストする同じ共有ワークスペースで、ローカルディスクと同等の操作感（平均読み取りレイテンシ約 300µs）が得られます。

スムーズな開発: 開発者のワークロードをワンストップで処理する Lustre

Managed Lustre は、大規模な AI および HPC ワークロード（チェックポイント / 再起動 / データ読み込み）に対応するスケーラビリティに加えて、インタラクティブな作業ニーズも満たします。つまり、開発者は Managed Lustre で作業を開始し、ワークロードのライフサイクル全体でもそのまま Managed Lustre を使用し続けることができます。

統合された基盤とインタラクティブなパフォーマンス

AI と HPC のライフサイクルを単一の名前空間に統合し、インタラクティブな作業に「ローカルディスク」のような使用感を提供します（ Salesforce などが経験した Managed Lustre による低レイテンシのメリットについて詳しくは、こちらをご覧ください）。

レイテンシ: 平均読み取りレイテンシは約 300µs で、他の分散ファイルシステムと比較して最大 4 倍の応答性を実現します。
セットアップの高速化: Linux カーネルの展開は約 2 分（他のファイルソリューションより 4.7 倍高速）、Python の 20 ワーカー並列 git クローンは約 40 秒、Python のコンパイルは約 200 秒で完了します。

高同時実行ブロードキャストとクラスタ起動

Managed Lustre は、クラスタの初期化中にストレージのボトルネックを解消することで、GPU の費用対効果を最大化します。

共有モデルのチェックポイント、ベースの重み、コンテナレイヤなど、数千のワーカーノードがまったく同じファイルを同時に読み取ろうとすると、従来の分散ファイルシステムでは局所的なホットスポットが発生して処理が滞り、高価な GPU クラスタが数分間アイドル状態になることがあります。

同じファイルを読み取る多数のクライアントの総スループットを向上: 代替ファイルソリューションと比較して 67% の向上が実証されています。
並列読み込み: PyTorch などのライブラリを 4,000 以上のプロセスに 60 秒未満でインポートします。

ワンストップショップワークフローを自分で実行

ご自身でもテストを実施できるよう、今回実行したテストのコードを以下に示します。

インタラクティブなアクセスでの低レイテンシ

fio を使用して、小規模で同時実行性の低い読み取りと書き込みをエミュレートしました。

1 ストレージシステムの仕様: Managed Lustre の 500 MBps/TiB ティア、108,000 GiB の容量。Filestore Zonal の容量は 102,400 GiB。同じ 40 GiB ファイルを読み取る 2,048 台のクライアント VM の平均スループットは 36.7 GB/秒。

code_block: <ListValue: [StructValue([('code', '# Read workload\r\nfio --ioengine=libaio --filesize=100M --ramp_time=2s \\\r\n --runtime=2m --time_based --numjobs=1 --direct=1 --verify=0 --randrepeat=0 \\\r\n --group_reporting --directory=~/LUSTRE_MOUNT \\\r\n --name=randread --blocksize=4k --iodepth=1 --readwrite=randread \\\r\n --buffer_compress_percentage=50\r\n\r\n# Write workload\r\nfio --ioengine=libaio --filesize=100M --ramp_time=2s \\\r\n --runtime=2m --time_based --numjobs=1 --direct=1 --verify=0 --randrepeat=0 \\\r\n --group_reporting --directory=~/LUSTRE_MOUNT \\\r\n --name=randwrite --blocksize=4k --iodepth=1 --readwrite=randwrite \\\r\n --buffer_compress_percentage=50'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501372510>)])]>

迅速な設定

Linux の展開方法

code_block: <ListValue: [StructValue([('code', '# Download a kernel tarball\r\nwget -P /tmp https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.18.9.tar.xz\r\n\r\n# Extract the archive to the Lustre mount\r\nmkdir ~/LUSTRE_MOUNT/kernel\r\ntar -C ~/LUSTRE_MOUNT/kernel -xf /tmp/linux-5.18.9.tar.xz'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501371b10>)])]>

上記のユースケースでは、root として実行する際に発生する可能性のあるメタデータパフォーマンスの負荷を回避するように注意する必要があります（つまり、tar が抽出されたファイルの所有者と権限をアーカイブに記録されているものと一致させようとして、chown と chmod を呼び出しを発行します）。それでも root として実行したい場合（かつ、このアプローチが設定に適していることを確認している場合）は、`--no-same-owner --no-same-permissions` を指定することで、抽出されたファイルの所有者が root のままで、root のデフォルトのファイル権限を維持できます。つまり、root としての抽出が、root 以外としての抽出のように動作します（アーカイブ内の所有者と権限が無視されます）。

Python gitclone の実行方法

code_block: <ListValue: [StructValue([('code', 'git config --global checkout.workers 20\r\nmkdir ~/LUSTRE_MOUNT/python\r\ngit clone https://github.com/python/cpython.git ~/LUSTRE_MOUNT/python'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501371ad0>)])]>

Python コンパイルの実行方法

code_block: <ListValue: [StructValue([('code', 'pushd ~/LUSTRE_MOUNT/python\r\n./configure > /dev/null\r\nmake > /dev/null\r\npopd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501372390>)])]>

大規模なディストリビューション

1 つの大きなファイルを多数のノードに分散する場合の集約スループット

各クライアント VM で以下を実行します。

code_block: <ListValue: [StructValue([('code', '# Start fio in server mode\r\nfio --server'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50034f050>)])]>

選択したクライアント VM で以下を実行します。

code_block: <ListValue: [StructValue([('code', "# Create a 40 GiB file\r\nfio --name=job1 \\\r\n --ioengine=libaio \\\r\n --direct=1 \\\r\n --buffer_compress_percentage=50 \\\r\n --blocksize=4m \\\r\n --iodepth=32 \\\r\n --filesize=40g \\\r\n --readwrite=write \\\r\n --filename ~/LUSTRE_MOUNT/40gb_test\r\n\r\n# Create an fio job file for the read workload\r\ncat <<'EOF' > /tmp/read.fio\r\n[job1]\r\nfilename=${HOME}/LUSTRE_MOUNT/40gb_test\r\nrw=read\r\nbs=4m\r\nexitall_on_error=1\r\nEOF\r\n\r\n# Run the read workload using all client VMs in ~/hostfile\r\nfio --client ~/hostfile /tmp/read.fio"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5022ce9d0>)])]>

多数のプロセスにわたるライブラリの並列読み込み

選択したクライアント VM で以下を実行します。

code_block: <ListValue: [StructValue([('code', '# Install PyTorch in a virtual env\r\npython3 -m venv ~/LUSTRE_MOUNT/env\r\nsource ~/LUSTRE_MOUNT/env/bin/activate\r\npip3 install --upgrade pip\r\npip3 install torch torchvision torchaudio \r\ndeactivate\r\n\r\n# Import PyTorch on all client VMs in ~/hostfile, 4 processes per host\r\nmpirun --allow-run-as-root --oversubscribe --hostfile ~/hostfile -N 4 \\\r\n bash -c \'source ~/LUSTRE_MOUNT/env/bin/activate && python3 -c "import torch"\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500148190>)])]>

未来と次のステップを見据えて

Google Cloud Managed Lustre は、手動のデータステージングの負担を排除し、ダイナミックティアで導入コストを削減することで、単一目的に特化したエンジンから、AI ライフサイクル全体に対応する汎用性の高い統合ストレージファブリックへと進化しています。

このシリーズの第 2 回では、今後提供予定のオブジェクト統合機能に焦点を当てます。今後の情報にご注目ください。

次のステップ

ご自身でベンチマークを実行してみましょう（まだの場合）: Google Cloud コンソールを使用して Google Cloud Managed Lustre インスタンスをデプロイし、上記で提供されているテストを実行して、自身のワークロードのベンチマークを実施してください。
ダイナミックティアについて: Google Cloud Managed Lustre のドキュメントで詳細をご覧ください。
パート 2 をお楽しみに: このシリーズの次回では、今後リリースされるオブジェクト統合機能と、それによって AI と HPC のストレージ運用がさらに簡素化される仕組みについて詳しく説明します。
Google Cloud Managed Lustre を活用して、開発からトレーニングまでのライフサイクルを一元化しましょう。

- Google Cloud Managed Lustre、シニアプロダクトマネージャー Barak Epstein

- Google Cloud Managed Lustre、ソフトウェアエンジニア Yuval Ehrental

GKE CPU 起動ブースト: オーバープロビジョニングなしでアプリの起動を高速化

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

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

トラフィックの急増に対応してマイクロサービスを起動する場合でも、新しいソフトウェアリリースをデプロイする場合でも、アプリケーションレプリカをスケールアップする場合でも、Google Kubernetes Engine（GKE）で実行されるアプリケーションの高速で応答性の高いユーザーエクスペリエンスを維持するには、Pod の起動時間が重要です

しかし、プラットフォームエンジニアと開発者は、アプリケーションが起動時に定常状態の運用時よりも大幅に多くの CPU パワーを必要とすることが多いという、根強いジレンマに直面しています。通常の定常状態の使用量に合わせて CPU リクエストをサイジングすると、起動時に CPU スロットリングが発生し、コールドスタートの遅延や、readiness プローブのタイムアウトにつながる可能性があります。逆に、短時間の起動バーストに対応するためにベースライン CPU リクエストをオーバープロビジョニングすると、貴重なコンピューティングリソースが無駄になり、インフラストラクチャの費用が膨らみます。

このたび、GKE 向け CPU 起動ブーストのプレビュー版をリリースいたしました。GKE の VerticalPodAutoscaler（VPA）に直接統合された CPU 起動ブーストは、初期化中にコンテナの CPU 割り当てを動的に引き上げ、アプリケーションの準備が整うとシームレスにベースラインの定常状態レベルにスケールバックします。コンテナを再起動する必要はありません。

仕組み: Kubernetes のインプレース Pod サイズ変更

これまで、Pod のリソースリクエストや上限を変更するには、Pod を削除して再作成する必要がありました。このように影響の大きいプロセスは、コンテナの再起動、キャッシュの無効化、そしてノードの再スケジューリングによるオーバーヘッドを引き起こしていました。

これを解決するために、CPU 起動ブーストは Kubernetes のインプレース Pod サイズ変更（IPPR）を基盤としています。

KEP-1287 として管理されている IPPR は、動的なインプレースリソースミューテーションを導入しました。Kubernetes 1.27 でアルファ版として導入され、v1.33 でベータ版に昇格、v1.35 で一般提供（GA）となった IPPR を使用すると、Kubernetes コントロールプレーンと kubelet が、コンテナプロセスを再起動することなく、実行中の Pod のコンテナ CPU とメモリのリクエストを更新できます。

GKE は、VPA 内の IPPR を活用して、Pod のアドミッション時に起動時の CPU ブーストを適用し、準備完了後にスムーズに引き下げます。

CPU 起動ブーストの仕組み（Pod ライフサイクルの概要）

CPU 起動ブーストは、次の 3 つのフェーズで動作します。

アドミッションフェーズ: Pod をデプロイすると、VPA アドミッション Webhook が作成リクエストをインターセプトします。ポリシー（2 倍の乗数や +2 vCPU など）に基づいて引き上げられた CPU リクエストを計算し、追跡アノテーションとともに Pod 仕様に挿入します。
起動フェーズ: Pod がスケジュールされ、ブーストされた CPU 割り当てで初期化されます。アプリケーションは、CPU スロットリングを発生させることなく、クラスの読み込み、JIT コンパイル、モジュールの解析を最高速度で完了します。
ブースト解除フェーズ: Pod の readinessProbe が成功すると（さらに、構成された durationSeconds のクールダウン遅延が経過すると）、VPA アップデータはインプレースサイズ変更リクエストを発行します。コンテナは中断されることなく実行を続け、CPU リクエストはベースラインレベルに戻ります。

前提条件と提供状況

CPU 起動ブーストは、GKE でプレビュー版として提供されています。

GKE バージョン: Standard クラスタと Autopilot クラスタのバージョン 1.36.0-gke.4447000 以降。
クラスタモード: GKE Autopilot でネイティブに有効（VPA はデフォルトで有効）。GKE Standard では、垂直 Pod 自動スケーリング（VPA）が有効になっていることを確認するだけです。
ワークロードのサポート: Deployment や StatefulSet などの標準の Kubernetes コントローラと連携します。

スタートガイド: CPU 起動ブーストを構成する

CPU 起動ブーストの構成は、VerticalPodAutoscaler マニフェストに startupBoost セクションを追加するだけです。

例 1: 固定定常状態での Pod レベルのブースト（`updateMode: "Off"`）

定常状態の CPU リクエストをマニフェスト定義にロックしたまま、起動ブーストのみに VPA を使用する場合は、updateMode を "Off" に設定します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: java-app-startup-boost\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: java-app\r\n updatePolicy:\r\n updateMode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 2\r\n durationSeconds: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500312d90>)])]>

この例では、GKE は起動時にコンテナの CPU リクエストを 2 倍にし、readiness プローブに合格してから 10 秒間、ブーストされた割り当てを維持した後、ベースラインにスケールバックします。

例 2: 起動ブーストと継続的な VPA 自動スケーリングの組み合わせ

GKE で起動時に CPU をブーストし、起動後に定常状態のリソースを継続的に最適化する場合は、updateMode を "InPlaceOrRecreate" に設定します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: nodejs-app-vpa\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: nodejs-service\r\n updatePolicy:\r\n updateMode: "InPlaceOrRecreate"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 3\r\n durationSeconds: 15'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500311dd0>)])]>

例 3: コンテナレベルでのきめ細かいブースト

起動時に追加の CPU を必要としないサイドカー（ロギングエージェントやサービスメッシュプロキシなど）を実行する Pod の場合は、特定のアプリコンテナをターゲットにします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: app-container-boost\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: API-gateway\r\n updatePolicy:\r\n updateMode: "Off"\r\n resourcePolicy:\r\n containerPolicies:\r\n - containerName: "web-app"\r\n mode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Quantity"\r\n quantity: "2"\r\n durationSeconds: 5'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500310ad0>)])]>

クラスタでの起動ブーストの確認

kubectl を使用して、GKE が起動ブーストを適用してダウンスケールしたことを確認できます。

1. Pod アノテーションを検査する: vpaCpuStartupBoost トラッキングアノテーションを確認します。

code_block: <ListValue: [StructValue([('code', 'kubectl get pod <POD_NAME> -o yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500313d90>)])]>

元のベースラインとブーストされた CPU リクエストを示すアノテーションを探します。

2. インプレースサイズ変更イベントをモニタリングする: readiness の後、GKE が CPU リクエストをベースラインにスケールダウンしたことを確認します。

code_block: <ListValue: [StructValue([('code', 'kubectl get events --field-selector reason=InPlaceResizedByVPA'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff500313c10>)])]>

reason=InPlaceResizedByVPA のイベントは、起動後のインプレースダウンスケーリングが成功したことを示しています。

本番環境ワークロードのベストプラクティス

HorizontalPodAutoscaler（HPA）との組み合わせ: CPU 起動ブーストと HPA を併用する場合は、堅牢な readinessProbe を定義し、durationSeconds を短く（例: 0 秒～10 秒）設定します。これにより、HPA が初期化時の CPU スパイクを定常状態の高負荷と誤って解釈するのを防ぎます。
GKE Capacity Buffers API でトラフィックの急増に対応: 大規模な起動オーバーヘッドを削減することで、より少ないノードでワークロードの密度を高め、全体的な使用率を向上させることができます。厳格な SLO を維持しながら、最小限の運用オーバーヘッドでトラフィックの急増を吸収するために、GKE Capacity Buffers API の導入を検討してください。
GKE Autopilot のリソース比率: GKE Autopilot では、Pod が有効な CPU とメモリの比率を維持する必要があります。起動時にブーストされた CPU 比率に対応できるよう、ベースラインのメモリ割り当てを確保します。

使ってみる

CPU 起動ブーストは、GKE ユーザーに両方のメリットをもたらします。Java、Node.js、Python などの CPU 負荷の高いワークロードのコールドスタートを高速化すると同時に、リソース効率を最大化してクラウド費用を削減します。

GKE ワークロードを高速化させるには、以下のリソースをご活用ください。

GKE CPU 起動ブーストのドキュメントを確認する。
GKE での垂直 Pod 自動スケーリングの詳細を確認する。
GKE 1.36.0-gke.4447000 以降を実行している GKE Standard クラスタまたは Autopilot クラスタで、CPU 起動ブーストをお試しください。

- Cloud デベロッパーアドボケイト、Abdel Sghiouar

- クラウドプロダクトマネージャー、Jakub Pawełczak

Data Agent Kit の一般提供を開始: Google のデータクラウドがあらゆるコーディングエージェントで利用可能に

Fri, 09 Oct 2026 03:00:00 +0000

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

このたび、Google Cloud Data Agent Kit の一般提供を開始しました。Data Agent Kit は、Model Context Protocol（MCP）ツールとエージェントスキルの無料セットです。Antigravity や Claude Code、Codex、その他の一般的なツールなど、すでに使用しているコーディングエージェントを Google Cloud データプロダクトと直接連携させることができます。

一般提供では、オープンレイクハウスに対する BigQuery Graph、Bigtable、Managed Service for Apache Spark からのアクセスがサポートされるほか、日常業務をより迅速かつスムーズにするためのさまざまな機能強化が追加されています。

Data Agent Kit とは

コーディングエージェントは、SQL、PySpark、パイプラインコードの作成に非常に優れています。デフォルトで欠けているのは、開発環境に関するコンテキストです。たとえば、どのテーブルが存在するか、どのようにパーティション分割されているか、チームが信頼しているのはどれか、昨夜のジョブが失敗したのはなぜか、といった情報です。これらがないと、優れたエージェントであっても、推測に基づいて作業せざるを得ず、最終的にはスキーマやエラーログをチャットに貼り付けて不足している情報を補うことになります。

Data Agent Kit は、次の 2 つの要素でその不足を埋めます。

MCP ツール: 15 以上の Google データクラウドサービスに接続できるため、エージェントはスキーマの検査、クエリの実行、ジョブログの読み取り、本番環境でのリソース管理を行うことができます。
Google が作成したスキル: Google Cloud エンジニアが提供するオープンソースの指示書により、エージェントは BigQuery SQL の最適化、Bigtable 行キーの設計、dbt（データビルドツール）パイプラインの構築といった、データのベストプラクティスを学習できます。

Data Agent Kit は、VS Code、Antigravity IDE、Cursor、その他の VS Code 互換エディタの IDE 拡張機能として、または Antigravity 2.0、Antigravity CLI、Claude Code、Codex のプラグインとして、あるいは Cloud Shell や Cloud Workstations にプリインストールされた状態で、既存の作業環境でそのまま使用できます。また、IDE 拡張機能により、Google Cloud コンソールの軽量版がエディタに組み込まれるため、ウィンドウを切り替えることなく、データの閲覧、クエリの実行、エージェントの作業の確認を行うことができます。

仕組み

たとえば、エージェントに「ベストセラー商品の来月の需要を予測し、それに対応できる十分な在庫があるかどうかを確認して」と指示したとします。Data Agent Kit が関連するスキルを読み込むため、エージェントはタスクに関する Google のベストプラクティスに従います。Knowledge Catalog を検索して、チームが信頼している販売テーブルと在庫テーブルを見つけます。次に、MCP ツールを使用して BigQuery で予測を実行し、AlloyDB for PostgreSQL で現在の在庫レベルを確認して、統合された回答をエディタまたはターミナルに返します。すべてのステップが独自の IAM 権限で実行されます。

Data Agent Kit がデータに接続する仕組み。

構築できるもの

Data Agent Kit は、分析、オペレーショナルデータベース、レイクハウス、パイプラインに対応しています。具体的にどのように機能するのか、まずは一般提供の新機能から見ていきましょう。

分析とグラフ: BigQuery と BigQuery Graph（一般提供の新機能）

グラフは、ユーザーが一緒に購入する商品や、サプライヤーが在庫にどのように接続しているかなど、関係性を自然に探索する方法です。通常、グラフを構築するには、CREATE PROPERTY GRAPH DDL を手動で記述し、GQL を学習して、どのキーが実際にエッジを形成するかを把握する必要があります。

代わりに、必要なグラフを指示するだけで、エージェントがグラフを構築してくれます。bigquery-graph-author スキルは、テーブルをノードとエッジにマッピングし、提案された各関係を実際のデータと照合したうえで、実際に作成する前に承認を求めるプランを表示します。既存の ER 図やデータモデルから始めることもできます。bigquery-graph-query スキルが GQL を記述し、IDE のグラフビジュアライザで結果をクリックして確認できます。

BigQuery プロパティグラフを構築して可視化する。

オペレーショナルデータベースとリアルタイムデータベース: Spanner、AlloyDB、Cloud SQL、Bigtable（一般提供版の新機能）

パーソナライズされたフィード、ライブカウンタ、ストアフロントの「最近閲覧した商品」レールなど、一部の機能は即座に読み込む必要があります。Bigtable はまさにそのために構築されており、行キーを適切に設計することで、その恩恵を最大限に得られます。

一般提供により、Bigtable は Spanner、AlloyDB、Cloud SQL とともに、Data Agent Kit で完全にサポートされるデータベースとなりました。新しい bigtable-basics スキルは、データの読み取り方法に基づいてスキーマを設計し、作成する前に、ホットスポットとフルテーブルスキャンにフラグを立てます。エージェントはテーブルを作成し、GoogleSQL でクエリを実行して、列ファミリーを読み取り可能な列にフラット化できます。IDE では、カタログエクスプローラで Bigtable インスタンスとテーブルをブラウジングし、SQL エディタからクエリを実行できます。

エージェントのガイドによる Bigtable スキーマの設計とクエリ。

レイクハウスと Spark: Managed Service for Apache Spark と Lakehouse for Apache Iceberg（一般提供の新機能）

エージェントは、これまでも BigQuery を介して Lakehouse 内の Apache Iceberg テーブルにクエリを実行することができました。さらに今度は、Managed Service for Apache Spark 上のサーバーレス Spark を使用して、同じテーブルを操作できるようになります。クラスタの管理は不要です。各セッションは状態を保持するため、一時ビューがステートメント間で引き継がれ、ブランチ、タイムトラベル、スキーマの進化など、Iceberg の全機能を利用できます。

また、すべてのテーブルを Google Cloud 上に配置する必要もありません。federate-lakehouse-catalog スキルは、Lakehouse を AWS Glue と Databricks Unity Catalog に接続します。これにより、エージェントは最初に取り込みパイプラインを構築することなく、そのデータを移動させずにその場でクエリできます。

Managed Service for Apache Spark を使用した Iceberg テーブルのブランチとクエリ。

パイプラインとオーケストレーション: dbt、Dataform、Managed Service for Apache Airflow

ロジックが機能するようになったら、エージェントはそれを独自に実行されるパイプラインに変換できます。エージェントが dbt または Dataform モデルを作成すると、gcp-pipeline-orchestration スキルがそれらをノートブックとともにまとめ、Managed Service for Apache Airflow 上のオーケストレーションパイプラインとしてスケジュールします。パイプラインには、モデルのアップロードやバッチ推論の実行など、Gemini Enterprise Agent Platform のステップを含めることもできます。

IDE では、ビジュアルパイプラインキャンバスで各実行を追跡できます。タスクに対応が必要な場合は、[診断] をクリックしてログをエージェントに渡します。Airflow と Spark のトラブルシューティングスキルが根本原因を特定し、ユーザーが承認するだけの修正案を提案します。

エージェントを使用して失敗した Airflow DAG をトラブルシューティングする。

デベロッパーエクスペリエンスの向上

一般提供では、セットアップや日常のワークフローも簡素化されます。利用を開始するには、1 回ログインして、使用する Google Cloud サービスを選択するだけです。Data Agent Kit は、必要な API を自動的に有効にし、対応するスキルをインストールして、手動で設定ファイルを作成することなく MCP サーバーを構成します。IDE では、SQL エディタとノートブックで、インラインコード生成、テーブルへの @ 参照、提案された変更の差分表示がサポートされるようになりました。この拡張機能は、アクティブなプロジェクト、開いているファイル、実行したばかりのクエリのエラーもエージェントと共有するため、「このクエリを修正して」と依頼するだけで機能します。

また、コアツールの高速化と応答性の向上も実現しました。新しい Spark ノートブックでは、Spark Connect ランタイムが自動的に作成、選択され、エディタ内の Spark SQL クエリは、組み込みの実行指標を使用して分離されたセッションで実行されます。カタログエクスプローラの読み込みが速くなり、サイドバーに BigQuery の一般公開データセットが表示されるようになりました。チューニングされたノートブックスキルにより、エージェントはより少ないトークンでノートブックタスクをより迅速に完了できます。

エンタープライズに対応

Data Agent Kit は追加料金なしでご利用いただけます。エージェントが使用する Google Cloud サービスの標準料金のみをお支払いいただきます。また、スキルはエージェントをコスト効率の良いクエリパターンへと誘導します。たとえば、BigQuery クエリの実行前に、誤ったフルテーブルスキャンを避けるためにパーティションキーを確認したり、ドライランを実行したりするように促します。また、スキルは GitHub でオープンソースとして公開されているため、チームはスキルを監査したり、フォークしたり、社内基準に合わせたカスタムスキルを独自に作成したりできます。

アクセス制御については、エージェントはユーザーまたはユーザーが権限を借用するサービスアカウントとして接続するため、行レベルおよび列レベルのセキュリティポリシーが自動的に適用されます。管理者は、Identity and Access Management（IAM）で MCP アクセスを管理し、Model Armor で MCP トラフィックをスクリーニングし、VPC Service Controls とプリンシパルアクセス境界ポリシーでエージェントのスコープを設定することもできます。

インストールして使ってみる

Data Agent Kit は、IDE またはターミナルで 1 分以内に設定できます。

オプション 1: IDE 拡張機能をインストールする

IDE 拡張機能: VS Code、Antigravity IDE、Cursor、または VS Code 互換エディタの拡張機能パネルで「Google Cloud Data Agent Kit」を検索します。VS Code Marketplace または Open VSX からインストールすることもできます。
Antigravity 2.0: [設定] > [カスタマイズ] > [Build with Google Plugins] に移動し、Data Agent Kit をダウンロードします。
Cloud Shell と Cloud Workstations: デフォルトですでにインストールされています。エディタを開いてログインするだけです。

オプション 2: CLI プラグインをインストールする

公式の GoogleCloudPlatform/data-agent-kit-plugin リポジトリを使用して、お好みのコーディングエージェントのコマンドを実行します。

code_block: <ListValue: [StructValue([('code', '# Antigravity CLI\r\nagy plugin install https://github.com/GoogleCloudPlatform/data-agent-kit-plugin\r\n\r\n# Claude Code\r\nclaude plugin install data-agent-kit-starter-pack@claude-plugins-official\r\n\r\n# Codex CLI\r\ncodex plugin marketplace add GoogleCloudPlatform/data-agent-kit-plugin\r\ncodex plugin add dak@dak-marketplace'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5015393d0>)])]>

そして最初のプロンプトとして、次を入力します:

code_block: <ListValue: [StructValue([('code', '先週のトップ 10 に入っていなかった、今週の米国で最も急上昇している検索キーワードは何ですか？BigQuery の一般公開 Google トレンドデータセットを使用してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5018d7b50>)])]>

Claude Code で実行されている Data Agent Kit プラグイン。

次のステップとハンズオンリソース

ドキュメントを読む: Data Agent Kit のドキュメントとプロダクトの概要ページをご覧ください。
スキルを試す: GitHub でスキルを閲覧、スター付け、貢献する。
分析ワークフローを構築する: Data Agent Kit と Antigravity IDE を使用した分析の Codelab をお試しください。また、関連ブログ記事 Data Agent Kit でエージェントを駆使した問題分析もご覧ください。
データサイエンスパイプラインを構築する: Data Agent Kit と Antigravity IDE を使用した不正行為検出パイプラインの Codelab をお試しください。

- Google、プロダクトマネージャー Arun Nair

- Google、デベロッパーアドボケイト、Jeff Nelson

強化学習（RL）による Gemini モデルのカスタマイズに関するベストプラクティスガイド

Tue, 06 Oct 2026 02:00:00 +0000

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

強化学習（RL）は、最新の LLM の事後学習の重要な要素となっていますが、大規模なトレーニングクラスタと、Gemini のような独自モデルでは外部の顧客がアクセスできないモデル内部へのアクセスを必要とします。そこで、Google Cloud は、これをマネージド RL ファインチューニングサービス（RLFT サービス） としてパッケージ化しました。お客様はプロンプトと報酬関数を用意するだけで、インフラストラクチャと独自モデルの内部は Google が処理します。

このサービスを使用すると、固定されたラベル付き回答セットではなく、定義した報酬シグナルに基づいてモデルに学習させることで、Gemini をサービスに適応させることができます。これにより、教師ありファインチューニング（SFT）では対応が難しい問題、つまり、実証は難しいものの、スコア付けは容易なタスクを解決できるようになります。

このガイドでは、RL ファインチューニングサービスを使用するための実践的なベストプラクティスについて説明します。まず、RL トレーニングループの概要、RL を使用するかどうか、いつ使用するかを判断する方法、このアプローチから最大限の価値を引き出す方法について説明します。

RLFT とは

RLFT は、ラベル付きの回答ではなく、定義した報酬シグナルに基づいて Gemini を調整します。大量のゴールドサンプルを作成する代わりに、回答をスコア付けするプログラムを 1 つ作成し、サービスがそれに基づいてモデルを改善します。これにより、実証は難しいが検証は容易なタスクを解決できるようになります。たとえば、すべてのスキーマに対して理想的な SQL を手動で記述することはできませんが、クエリを実行して結果を確認することはできます。

各トレーニングステップで、サービスはプロンプトに対して複数の回答候補を生成し、報酬でスコアを付け、元の Gemini に近い状態を維持しながら、スコアの高い回答が生成される可能性が高くなるようにモデルを改善します。これを可能にする強化学習はフルマネージドであるため、構成する必要はありません。あなたがコントロールし、結果を最も左右するものは、報酬です。

RLFT でできることとできないことは、次の 3 つの特性で定義されます。

モデル自体の出力から学習する: 外部のターゲットをコピーするのではなく、モデルがすでに生成したものを改良するため、SFT よりも無関係な機能を損なう可能性が低くなります。
経路ではなく結果に報酬を与える: 良い結果に到達した回答には報酬が与えられます。これは、有効な解決策が多数ある自由回答形式のタスクに適しています。
既存の能力を増幅する: たまにしか起きない成功を確実に再現できるようにしますが、モデルが一度も実証したことのないスキルを教えることはできません。

RLFT を使用する状況

プロンプトと SFT でほとんどの適応に対処できるため、まずはこれらを試してください。RLFT がその価値を発揮するのは、回答を評価できるが、安価に作成できない場合、重要な指標（忠実性、スキーマの有効性、トーン）で SFT が頭打ちになった場合、またはタスクに等しく有効な回答が多数あり、単一の参照ターゲットでは誤ってペナルティが課される場合です。

SFT と RLFT は競合するものではなく、補完的なものです。

直接 RLFT: ベースモデルがすでに時々成功している場合（報酬によってより良い回答とより悪い回答が区別される程度）。
SFT → RLFT の 2 段階: SFT データがある場合、またはベースの成功率が低すぎて RL が軌道に乗らない場合。SFT を短時間の安価なウォームスタートとして使用します。デモンストレーションを過学習させると RL による改善の余地が少なくなるため、SFT は軽めにとどめておきます。その後、SFT チェックポイントから RL を初期化する継続的チューニングを介して RL に移行します。

先行ユーザーの間では、これらのパターンは RLFT が最も価値を発揮する領域であることが示されています。いずれのパターンでも、企業が重視するものの、安価に実証できなかった成果を RLFT でスコア付けしています。

RLFT のユースケース

ゲーム内の AI を活用した NPC

内容: 多言語対応でマルチターンの長い会話で、キャラクターやブランドにふさわしい対話が展開される。
問題: 既製のモデルでは、言語の誤り、ハルシネーションにより生じたアイテム、プレーヤーの無視、繰り返しのループなどにより、没入感が損なわれる。
目標と報酬: Gemini 自動評価ツール（LLM-as-a-judge）が、ペルソナ、フロー、ゲーム状態のシンタックスに基づいて各ターンをスコア付けし、形式や言語のエラーにペナルティを課す。
結果: ループと言語のドリフトが解消され、状態のシンタックスが維持されたことで、ゲーム内のキャラクターを大規模にリリースすることが現実的なものになりました。

構造化されたエンティティの抽出

内容: サプライヤーの請求書や出荷明細書などの非構造化ドキュメントから一連の項目を抽出し、構造化レコードに自動的に変換する。
問題: SFT が頭打ちになるロングテール。必要なフィールドが見落とされている（再現率）か、存在しないフィールドが捏造されている（適合率）。
目標と報酬: ルールベースの適合率 / 再現率の報酬を使用して、各フィールドがソーステキストにグラウンディングされるようにして、1 つの正解から模倣されないようにする。
結果: チューニングが停滞していたノイズの多い実社会のドキュメントに対して、フィールドレベルの精度が向上し、手動によるレビュー手順を自動化できました。

コンテンツ管理

内容: 複雑なポリシーとディシジョンツリーを大規模に適用する。
問題: モデルのハルシネーションによる偽陽性や、無効な形式で評価を避けようとする報酬ハッキング。
目標と報酬: Cloud Run の報酬を使用して、形式の検証と決定論的な採点ツールを組み合わせて、複数ステップのポリシー遵守を強制する。
結果: モデルが複雑な免除措置を処理し、偽陽性を大幅に削減し、報酬ハッキングを阻止したことで、管理費用を増加させる人間へのエスカレーションの量が減少しました。

実行によって測定されるコード

内容: 顧客データに対して実際に実行されるかどうかに基づいて評価される SQL または API 呼び出し。
問題: SFT が 1 つの参照クエリを模倣し、未知の独自スキーマに対して機能しない。
目的と報酬: コード実行の報酬を使用して、安全なサンドボックスでコードを実行し、コンパイル、実行を経て、正しい結果が返された場合にのみ報酬を与える。
結果: モデルは、クローズドフロンティア品質の実行可能なクエリを最初の試行で生成し、推論コストを削減しました。これにより、技術者以外のユーザーも自然言語で独自のデータをクエリできるようになりました。

HTML によるプレゼンテーションスライドの生成

内容: HTML / CSS で作成された複数スライドの資料。
問題: テキストのみでトレーニングすると、視覚的な品質が無視されるため、オーバーフロー、要素のクリッピング、一貫性のないスタイル設定などが見過ごされる。
目標と報酬: コード実行の報酬を使用して、スライドをレンダリングし、ビジュアルデザイン、レイアウトの整合性、構造の完全性、評価基準の遵守をスコア付けする。
結果: モデルは、テーマに一貫性があり、レイアウトのオーバーフローがない、モジュール化された、適切なスタイルのスライドを出力しました。

どこから始めるべきか

データセット。最初の実行には、検証用として取り分けたデータを含む、多様なプロンプトのセットで十分です。ループが収束し、報酬が期待どおりに推移していることを確認してから、スケールします。トレーニングと評価は厳密に分けるようにしてください。評価が汚染されると、過学習が見落とされてしまいます。
報酬関数。コードまたは構成としてのタスク仕様であり、品質を左右する重要な要因。優れた報酬は、人間の好みに相関し、不正な出力に対して堅牢であり（解析の失敗をキャッチし、クラッシュすることなく、明確に否定的なスコアを返します）、報酬ハッキングに耐性があります。具体的には、複数の評価を組み合わせ、長さへのペナルティを課し、異常な出力への下限を設定し、モデルの意見よりも検証可能なチェックを優先します。リリース前にオフラインで検証してください。

残りはサービスが処理します。デフォルト設定から開始し、コンソールで報酬と評価の曲線を確認して、最後の段階ではなく、検証報酬が頭打ちになった時点のチェックポイントを使用します。

使ってみる

あなたは何を構築しますか？そのために必要なツールがここにあります。

ドキュメント: 強化学習ファインチューニング

- Google、シニアソフトウェアエンジニア、Jiaqi Pan

- Google、シニアプロダクトマネージャー、Kunal Jha

AI ワークロードのコンピューティングを柔軟に選択できるよう Google Cloud ネットワーキングがサポート

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

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

AI ワークロード用のリソース、特にアクセラレータの可用性は、業界全体で課題となる可能性があります。特定のタイプのアクセラレータを中心に構築されている場合、AI ワークロードのデプロイが遅くなる可能性があります。フルイドコンピューティングというコンセプトにより、ユースケースに適合する利用可能なリソースに基づき、複数のオプションを使用して AI デプロイを設計することが可能になります。

このブログ投稿では、Google Cloud ネットワーキングが AI ワークロードをどのようにサポートしているかを紹介するとともに、アクセラレータ（GPU または TPU）を選択する際の考慮事項について説明します。バックエンドのネットワーキングコンポーネント構成は、それぞれで完全に同じではないためです。

リソースオプション

AI デプロイで実現したいタスクを決定したら、次に重要な要素は、それを実行する実際のハードウェアです。この場合、プライベート LLM の推論を実行する必要があり、ターゲットは A4 VM（a4-highgpu-8g）で利用可能な NVIDIA B200 GPU ファミリーです。

これで、達成したいことと、利用可能なコンピューティングオプションは特定できました。しかし、「本当にそれが利用できるのか」という課題があります。

リソースにアクセスするには、次のような方法があります。

Dynamic Workload Scheduler（Flex Start VM）: 必要なアクセラレータノードがすべて同時に利用可能になるまでワークロードをキューに入れ、それらをまとめてプロビジョニングし、最大 7 日間プリエンプト不可で実行します。
Dynamic Workload Scheduler（カレンダーモード）: 1～90 日前にアクセラレータ容量を予約でき、開始時間と終了時間が保証されるため、スケジュールされた事前トレーニングの実行やベンチマークに最適です。
将来の予約: 将来の特定の日付から、指定したゾーンで確約されたハードウェアへのアクセスを保証します。
フレックス予約: 短期契約により、複数年のロックインなしで、希少なアクセラレータノードを確保できます。
動的なノード自動プロビジョニングと ComputeClasses: Google Kubernetes Engine（GKE）では、ComputeClasses 内にマルチファミリーフォールバックリストを定義することで、プライマリプールがリージョンの制約に直面した場合に、クラスタが代替アクセラレータタイプのプロビジョニングを自動的に試行できます。
Spot VM: フォールトトレラントなチェックポイント付きバッチジョブ向けに、余剰コンピューティングを大幅な割引価格で提供します。

詳しくは、ブログ投稿 コンピューティングリソースの不足を防止する: GKE リソースの入手可能性に関する実践ガイド をご覧ください。

ネットワーキングの選択肢

アクセラレータのネットワーキングコンポーネントは選択内容によって異なるため、標準ネットワーキング、高速 GPU ネットワーキング（TCPX / TCPXO と RoCEv2）、TPU ネットワーキング、Cloud Run の 4 つの構成について説明します。

標準ネットワーキング

サポートされているアクセラレータ: NVIDIA T4（N1 シリーズ）、NVIDIA L4（G2 シリーズ）、NVIDIA A100（A2 マシンシリーズのシングルノードとマルチノード）、Cloud TPU v3、 Cloud TPU v5e（単一ホスト / スタンドアロンスライス）。
アーキテクチャ: ノードは、標準の TCP / IP を介して Google Virtual NIC（gVNIC）を使用し、プライマリ Virtual Private Cloud（VPC）ネットワーク経由で通信します。
ワークロードの適合性: Google Cloud コンピューティング環境間で簡単に移植できます。標準の VPC ルーティングとネットワークポリシーを使用し、分散データの前処理、パイプラインステージの分離、独立した推論レプリカ、コンピュータビジョンワークロードをサポートします。

高速 GPU ネットワーキング（TCPX / TCPXO、RoCEv2）

分散トレーニングとマルチノード推論には、膨大なパラメータ交換と集団通信を処理するための特殊なマルチレールネットワークファブリックが必要です。

GPUDirect-TCPX ファブリックと GPUDirect-TCPXO ファブリック

サポートされているアクセラレータ: NVIDIA H100（4 レールの A3 High VM）と NVIDIA H100 Mega（8 レールの A3 Mega VM）。
アーキテクチャ: カスタムの GPUDirect-TCPX（4 つの専用 VPC）と GPUDirect-TCPXO（8 つの専用 VPC）オフロードエンジンを使用して、ネイティブ RDMA ハードウェアを必要とせずに、標準のイーサネットインフラストラクチャ上で高スループットのマルチレール GPU 通信を実現します。
デプロイブループリント: これらのマルチ VPC トポロジは、Cluster Toolkit の事前構築済みブループリントを使用するなど、さまざまな方法でデプロイできます。

RoCEv2 ファブリック（VM とベアメタル）

サポートされているアクセラレータ: NVIDIA H200（A3 Ultra VM）、NVIDIA B200（A4 VM）、NVIDIA GB200 NVL72（A4X VM）、NVIDIA GB300（A4X Max ベアメタル）。
ゾーンネットワークプロファイル: RoCEv2 は、専用のゾーンネットワークプロファイルに接続された専用の RDMA VPC 上で動作します。VM インスタンス（A3 Ultra、A4、A4X）は ZONE-vpc-roce プロファイルを使用し、ベアメタルインスタンス（A4X Max など）は専用の ZONE-vpc-roce-metal ベアメタルプロファイルを使用します。
レール整列型ファブリック: この専用 VPC は GPU 通信用に厳密に分離されており、アクセラレータ NIC に直接マッピングされたサブネットが含まれています。バックエンドはレール整列型で、ジャンボフレーム（MTU 8896）をサポートし、レール間の干渉を最小限に抑えながら、ノンブロッキングのマルチテラビット帯域幅を実現します。
GKE Dynamic Resource Allocation Network（DRANET）による自動配線: これらの GPU を GKE にデプロイする場合、GKE マネージド DRANET を使用して、追加のネットワークを自動的にプロビジョニングし、RDMA ネットワークインターフェースを GPU にマッピングするドライバを割り当てることができます。これらは、標準の Kubernetes リソースクレームを使用して、ワークロード Pod に直接割り当てて使用できます。
ターンキーデプロイ: RDMA VPC、MTU チューニング、DRA ドライバなど、このエンドツーエンドのスタック全体を、Cluster Toolkit の自動化されたブループリントを使用してデプロイできます。

TPU ネットワーキング

サポートされているアクセラレータ: Cloud TPU v4、Cloud TPU v5p、Cloud TPU v5e（マルチホスト Pod スライス）、Cloud TPU v6e（Trillium）、TPU7x（Ironwood）。
チップ間相互接続（ICI）: TPU Pod またはスライス内では、チップは 2D または 3D トーラスメッシュで構成された専用の超低レイテンシ光リンクを介して直接通信し、従来のネットワークスタックを完全にバイパスします。
光回線スイッチ（OCS）: TPU v4 と TPU v5p の SuperPod では、ソフトウェアで再構成可能な OCS ユニットが物理ネットワークトポロジを動的に変更し、障害のあるトレイを迂回して、手動でケーブルを再接続することなく、カスタムサイズのアクセラレータスライスをプロビジョニングします。
マルチ NIC アーキテクチャ（TPU v6e 以降）: 以前の TPU 世代は、スライス内の ICI とホストトラフィック用の単一 NIC に依存していましたが、Cloud TPU v6e（Trillium）と TPU7x には、ネイティブのマルチ NIC アーキテクチャが導入されています。このアーキテクチャでは、ワーカーノードが標準の Kubernetes 管理トラフィックをプライマリ VPC に分離し、高スループットの TPU データとクロススライス通信用に構成されたセカンダリ専用 VPC を使用します。
TPU デプロイ用の DRANET: これらの TPU を GKE にデプロイする場合、GKE マネージド DRANET を使用して、追加のネットワークを自動的にプロビジョニングし、TPU 通信用にドライバを割り当てることができます。これらは、標準の Kubernetes リソースクレームを使用して、ワークロード Pod に直接割り当てて使用できます。
データセンターネットワーク（DCN）マルチスライス: 個々の TPU スライスを超えてスケールするモデルの場合、Cloud TPU マルチスライスは、これらの専用マルチ NIC パスを利用し、Google の高速 Jupiter データセンターネットワークを介して複数の独立した ICI メッシュを接続します。

Cloud Run

サポートされているアクセラレータ: Cloud Run GPU サービスの NVIDIA L4（G2 シリーズ）と NVIDIA RTX PRO 6000（Blackwell）。
ダイレクト VPC 下り（外向き）: ダイレクト VPC 下り（外向き）を介して 1 分未満で IP を割り当てることで、サーバーレスコンテナをプライベート VPC ネットワークに直接バインドします。これにより、公共のインターネットを経由したり、レガシーコネクタ VM を必要としたりすることなく、内部データレイク、データベース、プライベート API にセキュアかつ低レイテンシでアクセスできます。

まとめ

Google Cloud のネットワーキングオプションは、さまざまなアクセラレータタイプをサポートしています。フルイドコンピューティングを使用する場合、ワークロードのパフォーマンスが最適化されるベストな設計をサポートするようネットワーク設定を調整できます。

次のステップ

Google Cloud AI インフラストラクチャとネットワーキングアーキテクチャについて詳しくは、以下のリソースをご覧ください。

ブログ記事: AI インフラストラクチャの動的容量管理
チュートリアル: フルイドコンピューティングを使用して GKE 上にエラスティックでスケーラブルな LLM 推論プラットフォームを構築する方法
ブログ記事: Google Cloud ネットワーキングが AI ワークロードをサポートする仕組み

ご質問やご意見がございましたら、LinkedIn 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

AlphaEvolve で動画処理を高速化する方法

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

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

リアルタイムストリーミングでは、1 ミリ秒の違いが結果を左右します。

たとえば、30 フレーム/秒（fps）の場合、デベロッパーはカメラフレームの取り込み、ニューラルセグメンテーションの実行、シェーダーの適用、出力の合成を、わずか 33.3 ミリ秒（60 fps の場合は 16.6 ミリ秒）という厳格なフレームバジェット内で行う必要があります。このバジェットを 1 ミリ秒でも超えると、ドロップフレーム（コマ落ち）やスタッタリング（カクつき）が発生します。

これを手動で最適化するのは、フレームグラフの分析や Swift、C++、Metal での低レベルコードの手動調整に何週間もかかるため、非常に面倒な作業になります。標準的な AI コーディング支援を使用すれば、ボイラープレートを生成することは可能です。しかし、ターゲットハードウェアに合わせた最適化や実際の環境で生じるレイテンシへのベンチマークには対応できず、また最適化後に視覚的な忠実度を完全に維持することもできません。

この状況を打破するには、自律的なクローズドループの進化史的最適化が有効です。AlphaEvolve のようなツールが、クラウド規模のモデル推論をローカルハードウェアでの実行と組み合わせ、すでに実用環境に効果をもたらしています。DoIt は、Google との提携により、AlphaEvolve を使用して、macOS のライブストリーミングアプリにおける本番環境 Swift コードの自律的最適化を実現しました。これにより、手動プロファイリングでは見つけられなかった伸びしろが見出され、パフォーマンスが改善されました（詳しくは完全版の技術レポートをご覧ください）。

この投稿では動画パイプラインに焦点を当てていますが、分割ループパターンは、マイクロサービスのスループットやデータベースのクエリから、ML テンソルパイプラインや組み込みシステムまで、パフォーマンスが重要となるあらゆる場面に適用できます。どのユースケースにおいても仕組みは同じで、クラウドにおける Gemini のコード生成を、ドメイン固有のベンチマークハーネスおよび自動品質ゲートと組み合わせます。

ここでは、AlphaEvolve を使用して動画処理を高速化する方法と、ユーザー固有のパフォーマンスボトルネックに以下の原則をどのように適用できるかについて確認していきましょう。

分割ループアーキテクチャを理解する: AlphaEvolve が、マネージドクラウド生成（Google Cloud 上の Gemini モデルアンサンブル）をローカルでの評価プロセス（ネイティブ Swift / Metal コードのコンパイルと実行時間の計測など）からどのように分離しているのかを理解します。
評価ツールの設計と品質ゲートを適用する: 構造的類似性指数（SSIM）などの指標を使用してスコアリング関数を構築し、進化ループがベンチマークの裏をかく（例: 速度を上げるためにレンダリングを完全にスキップする）のを防ぎます。
自律的なアルゴリズム検出を活用する: Gemini 主導の進化史的最適化検索により、プロンプトなしでフレームワーク API を自律的に検出し、エンジニアリングのバランス（フレームキャッシュの制限など）をインテリジェントに調整します。
現実的なパフォーマンス境界を設定する: 物理的なハードウェアの限界に対応するコードの最適化を測定します。

1. AlphaEvolve の分割ループアーキテクチャを理解する

AlphaEvolve は、クローズドループの進化プロセスを実行します。つまり、シードプログラムとカスタムスコアリング関数を使用して、Gemini モデルの混成がコードのバリエーションを提案し、各候補に対してスコアリング関数を実行します。その過程で最もパフォーマンスの高いコードを保持し、複数の世代にわたって反復的に最適ソリューションへと進化していく仕組みです。

AlphaEvolve アーキテクチャの主な利点は、次の 2 つの要素に明確に分けられていることです。

生成サイド（Google Cloud マネージドサービス）: プロンプトサンプラー、Gemini モデルアンサンブル、プログラムデータベースが含まれます。スケーリング、プロンプトオーケストレーション、生成メカニズムが Google Cloud で処理されます。
評価サイド（ユーザー管理のコンピューティング）: コード品質のスコアリングが、厳密にドメイン限定で実行されます。評価モジュールは完全にユーザーが所有し、独自のハードウェアまたはターゲットアーキテクチャ（この場合はネイティブ Swift コードを実行する macOS）で実行されます。

AlphaEvolve は、クラウド生成サイドでは Python ファーストですが、評価サイドは任意の言語で記述できます。カスタム評価ツールでは、Swift コードの各候補を Swift を使用してコンパイルし、標準の参照ウェブカメラクリップに照らして評価を実行します。

2. 評価ツールの機能と品質ゲートを適用する

AlphaEvolve のような自動最適化ループは、実際には動画ストリームを「見る」ことはありません。評価ツールが返す数値の適合度スコアを確認するだけです。評価指標に盲点がある場合、進化史的最適化によるコード生成はそれを積極的に利用してしまいます。

たとえば、初期の実行では、未熟な適合度スコアが元のレイテンシを重視するあまりに、処理が異常に高速化されました。モデルはぼかしレンダリングを完全にバイパスし、未修正のフレームを 0 ミリ秒で返したのです。

構造的類似性指数（SSIM）:

モデルがベンチマークの裏をかく行為を防ぐには、以下のように、スループットと構造的類似性指数（SSIM）などの構造的忠実度指標を組み合わせた 2 段階のスコアリング関数を記述します。

code_block: <ListValue: [StructValue([('code', 'speedup = baseline_ms_per_frame / candidate_ms_per_frame\r\nssim = mean_ssim_vs_golden\r\n\r\n#Disqualify any candidate falling below visual threshold\r\n\r\n\r\nif ssim < 0.98 or worst_frame_ssim < 0.95:\r\n return {"speedup": -1e12} # Disqualified\r\n\r\nreturn {"speedup": speedup, "ssim": ssim}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5022ce7d0>)])]>

これにより、以下のことが可能になります。

極めてハードルの高いクリップでテスト可能に: 静止フレームや空白のカメラ映像をベンチマークにすることは絶対に避けるべきです。コードの各候補は、静的な背景のフレームでは平均 SSIM ゲートを簡単に通過できてしまいますが、人がさっと振り向くような映像では必ず不適格になります。
平均だけでなく最小値も追跡可能に: 平均しきい値とフレームごとの最小値の両方を適用して、ドロップフレームやマスク更新の遅延を検出できます。

自律的なアルゴリズム検出を活用する

一般的に、デベロッパーは生成 AI を使用して、ローカルのマイクロ最適化（ヘルパー関数のインライン化、ループの展開、メモリプールの調整など）を行っています。しかし、アーキテクチャの余地を与えれば、進化ループがシステム的な最適化手段を自律的に発見することができます。

エンジニアリングのヒント:

分離されたループではなく、フレームワークのコンテキストを提供する: 公開 SDK ヘッダー、インターフェース定義、API リファレンス識別子をプロンプトまたは検索ハーネスに含めます。LLM のコンテキストウィンドウに、分離されたフレーム処理コールバックのみが含まれている場合、LLM はシーケンス対応サブシステムを使用できません。
マルチフレームライフサイクルフックを利用可能にする: 純粋なステートレス関数を適用するのではなく、コードの候補が前の実行から次の実行に制限付きの状態データ（マスクの履歴やキャッシュのタイムスタンプなど）を引き継げるようにします。
品質ゲートで動画の質と処理速度のバランスを管理する: AlphaEvolve に一時的なマスクキャッシュを導入した際、当初はマスクのキャッシュが過剰に行われ、動画にゴーストなどが残ってしまいました。そこで、SSIM ゲートによって動きのブレを規制し、パラメータを手動調整することなく、本番環境に対応したキャッシュウィンドウに検索を収束させました。

現実的なパフォーマンス境界を設定する

パフォーマンスエンジニアリングでよくある落とし穴は、闇雲に最適化を行うことです。2 倍の高速化を達成した場合、それで満足すべきでしょうか。それとも、さらに 3 倍を目指す余地があったのでしょうか。

リアルタイムのメディアにおいて、合計フレーム時間は次の 2 つのカテゴリに分けることができます。

変更可能なソフトウェアのオーバーヘッド: メモリ割り当て、バッファ形式の変換、スレッドコンテキストの切り替え、API ディスパッチの摩擦などがこれに相当します。
変更不可のハードウェアベースライン: 未処理のニューラルエンジン推論レイテンシ、GPU シェーダーコンピューティング時間、ハードウェアディスプレイ同期などがこれに相当します。

AlphaEvolve を最大限に活用するには、理論上の最大ヘッドルームを基準に測定する必要があります。

最適化ループを実行する際は、次の原則を考慮しましょう。

NoOps パイプラインを構築する: Swift / C++ オーケストレーション、データマーシャリング、フレーム変換は排除し、ウォームアップ済みの ML モデルと未加工 GPU のレンダリングパスのみをダミーバッファにディスパッチします。結果として得られる時間が、物理ハードウェアの下限となります。
対応可能な上限を計算する: 最適化可能な最大値は次の式で計算できます。

3. ハードウェアの制約を考慮して測定する: 任意の高速化倍率ではなく、最適化効率を測定します。

実際に使ってみる

すべてのベンチマークコード、テストクリップ、評価スクリプト、未加工の候補ログはオープンソースです。

GitHub リポジトリ: AlphaEvolve Camera Background Blur Example
DoIt の事例紹介に関する詳細な技術レポート: Running AlphaEvolve on Your Own Code

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

- DoIt、プリンシパル AI リード、Sascha Heyer 氏

Antigravity SDK を使用してエージェントハブやカスタムハーネスを単一ツールキットで実現

Fri, 18 Sep 2026 01:10:00 +0000

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

エンタープライズエージェントの導入に、万能の解決策はありません。エージェントを導入する際、多くの組織は、そのまますぐに使えるエージェントのデプロイとガバナンスの施行を求めて、Gemini Enterprise Agent Platform のような商用マネージドプラットフォームを選択する傾向があります。しかし、固有のワークフローやカスタム実行エンジンを利用しているデベロッパーは、独自の軽量エージェントハブの構築を選択することもよくあります。

一元化されたエージェントハブをゼロから構築するには、サンドボックス内で予測どおりに動作してすべてをログに記録してくれるツールが必要になります。Antigravity SDK を使用すると、Antigravity 2.0 や Antigravity CLI と同じランタイムエンジンを利用でき、安全性に関する宣言型ポリシー、リアルタイムテレメトリー、ステートフルなマルチターンの永続性を直接アプリケーションに組み込むことができます。しかも、コアランタイムが更新されると、SDK エージェントは自動的に最適化されます。そこで今回は、Antigravity SDK を使用して、完全なマルチエージェントコントロールプレーンを実現する方法について詳しく解説していきます。

Antigravity の仕組み

マルチエージェントコントロールプレーンは、LLM ワークロードをモニタリングして管理します。これにより、エージェントが何を考え、どのツールを呼び出し、状態をどのように保存しているのかを、正確に把握することができます。

そのワークフローは、次の 2 つの重要なコンポーネントで構成されています。

1. Antigravity SDK エージェントコア: モデルのインタラクション（Gemini 3.1 Pro や Gemini 3.8 Flash など）を管理し、ツールを実行し、思考トレースを生成し、スキルを実行するランタイム。

2. オブザーバビリティとテレメトリーのミドルウェア: Antigravity SDK ライフサイクルフックを活用したイベントドリブンレイヤ。ステップの開始、思考の更新、ツール呼び出しなどのエージェントアクションをインターセプトし、WebSocket 経由でテレメトリーをダッシュボードにストリーミングします。

ユースケース: マルチエージェントのモニタリングとインタラクティブな制御

カスタムエージェントハブを構築または維持している組織が、Antigravity SDK を活用したエージェントとの統合を考えている場合、どのようなアプローチがあるか、一緒に見ていきましょう。

問題: オペレーションエンジニアは、バックグラウンド調査、ドキュメントの要約、タスクのスケジューリングを実行する複数のアクティブなエージェント（gemini-pro-agent、github-agent、email-agent など）をモニタリングする必要があります。従来、エージェントの進捗状況をモニタリングするには、以下の必須タスクと課題がありました。

複数のターミナルウィンドウにまたがって断片化されたコンソールログを追跡
JSON の文字起こしを手動で検査して、ツール呼び出しの停止や失敗を診断
特定のエージェントセッションでどのスキルまたは MCP コネクタが読み込まれているかの把握が困難
累積トークン使用量と実行レイテンシの追跡が困難

解決策: この投稿では、リアルタイムオブザベーションのためのストリーミング API、ライフサイクルフックによるテレメトリーとインターセプト、ポリシーエンジンによる制御、機能管理のためのスキル、永続性を維持するセッション状態について、それぞれ詳しく説明します。SDK がもたらすダッシュボードにより、オペレーターは各エージェントの作業を 1 つのビューで確認できます。

実際のメカニズムオペレーターまたはダッシュボードが Antigravity エージェントとやり取りすると、ランタイムは 5 つのコアメカニズムを通じて処理の実行を調整します。

セッションの初期化と状態のアタッチ（save_dir と conversation_id）: ランタイムはセッションを初期化または再アタッチし、処理の実行をルート save_dir にバインドします。マルチターン軌跡のログ、ツール受信歴、アーティファクトは、永続的な監査を可能にするために traj-<conversation_id> に保存されます。
スキル解決（skills_paths）: ドメイン固有の機能と指示が、SKILL.md バンドルを指すファイルシステムパスから直接解決され、外部レジストリなしでエージェントのシステムプロンプトを動的に補充します。
同時ストリーム生成（ChatResponse）: ランタイムは、単一のモデルレスポンスに対して同時進行の 3 つの非同期イテレータを公開します。

response（表示可能なテキストトークンを生成）
response.thoughts（内部の Chain-of-Thought 推論の差分を生成）
response.tool_calls（.name と .args を含む型付き ToolCall イベントを生成）

宣言型ポリシーによるサンドボックス化と組み込みツールの実行: エージェントがワークスペースオペレーションを実行すると、組み込みツール（list_directory、find_file、search_directory、view_file、create_file、edit_file）は、安全性に関するポリシー（policy.workspace_only() など）に則って管理される指定のワークスペースディレクトリ内でのみ実行されます。
ライフサイクルフックによるテレメトリーとインターセプト: パラメータを付与された非同期フック関数（@hooks.on_session_start、@hooks.pre_tool_call_decide、@hooks.post_tool_call、@hooks.on_session_end）が、エージェントのやり取りの推移をリアルタイムでインターセプトし、ツール呼び出しを検証または修正して、WebSocket 経由でテレメトリーペイロードをライブダッシュボードにブロードキャストします。

Antigravity SDK は、これらのメカニズムを 4 つの主要な構成要素に分けて実行します。

1. ドメイン別のスキル適用

スキルは、エージェントが動的に読み込める、再利用可能なドメイン固有の指示バンドルと参照アセットを提供します。インメモリレジストリを管理する代わりに、SKILL.md ファイルを含むファイルシステムディレクトリからスキルのパスを直接解決できます。

code_block: <ListValue: [StructValue([('code', 'from google.antigravity import Agent, LocalAgentConfig\r\n\r\n# Pass directory paths containing SKILL.md bundles directly to config.\r\n# The runtime dynamically resolves and injects them into the prompt.\r\nconfig = LocalAgentConfig(\r\n model="gemini-3.8-flash",\r\n system_instructions=(\r\n "You are an enterprise operations assistant equipped with "\r\n "specialized operational skills."\r\n ),\r\n skills_paths=["./skills/research", "./skills/code_review"],\r\n)\r\n\r\nasync with Agent(config) as agent:\r\n response = await agent.chat("Analyze the deployment logs.")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501467050>)])]>

2. 組み込みツールとワークスペースのサンドボックス範囲指定

SDK には、すぐに使用できるプロダクションレディなファイルツールとワークスペースツールが用意されているため、カスタムファイルシステムラッパーを記述する必要がありません。これらのツールは、ワークスペースおよび安全性に関する宣言型ポリシーと組み合わさることで、承認されたディレクトリ内での使用に厳密に制限されます。

code_block: <ListValue: [StructValue([('code', 'from google.antigravity import Agent, LocalAgentConfig, types\r\nfrom google.antigravity.policies import policy\r\n\r\nconfig = LocalAgentConfig(\r\n model="gemini-3.8-flash",\r\n # Selectively enable built-in tools via CapabilitiesConfig\r\n capabilities=types.CapabilitiesConfig(\r\n enabled_tools=[\r\n types.BuiltinTools.LIST_DIR, # "list_directory"\r\n types.BuiltinTools.FIND_FILE, # "find_file"\r\n types.BuiltinTools.SEARCH_DIR, # "search_directory"\r\n types.BuiltinTools.VIEW_FILE, # "view_file"\r\n types.BuiltinTools.CREATE_FILE, # "create_file"\r\n types.BuiltinTools.EDIT_FILE, # "edit_file"\r\n ]\r\n ),\r\n # Enforce filesystem isolation: operations outside these paths are blocked\r\n workspaces=["./workspace"],\r\n policies=[policy.workspace_only()],\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5017dc8d0>)])]>

3. セッションの隔離と軌跡の永続化（save_dir と conversation_id）

Antigravity SDK の状態の永続性は、外部データベースではなく、宣言型の構成によって管理されます。save_dir を指定すると、traj-<conversation_id> の下に、マルチターン軌跡、ツール受信歴、アーティファクトが保存されるルートディレクトリが確立されます。

code_block: <ListValue: [StructValue([('code', 'from google.antigravity import Agent, LocalAgentConfig\r\n\r\nconfig = LocalAgentConfig(\r\n model="gemini-3.8-flash",\r\n # Root directory storing all conversation trajectories\r\n save_dir="./storage/sessions",\r\n # Supply conversation_id to reattach to an existing trajectory;\r\n # omit it to let the SDK mint a new ID on the first turn.\r\n conversation_id="ops-session-20260820-001",\r\n)\r\n\r\nasync with Agent(config) as agent:\r\n # Resumes prior context and continues the multi-turn session seamlessly\r\n response = await agent.chat("Summarize the issues identified in the last turn.")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5017dd790>)])]>

4. ライフサイクルフックによるリアルタイムのテレメトリーとインターセプト

ライフサイクルフックにより、ダッシュボードとモニタリングエンジンは処理の実行の全段階を監視し、制御できます。パラメータを付与された非同期関数を使用することで、WebSocket 経由でステータスの更新をストリーミングしたり、ツールのパラメータを検査したり、ツールを実行する前に人間参加型の承認を強制したりできます。

code_block: <ListValue: [StructValue([('code', 'from google.antigravity import Agent, LocalAgentConfig, types\r\nfrom google.antigravity.hooks import hooks\r\n\r\n# 1. Session start & end telemetry\r\n@hooks.on_session_start\r\nasync def on_session_start():\r\n broadcast_to_dashboard({"type": "STATUS", "status": "RUNNING"})\r\n\r\n@hooks.on_session_end\r\nasync def on_session_end():\r\n broadcast_to_dashboard({"type": "STATUS", "status": "IDLE"})\r\n\r\n# 2. Intercept tool calls before execution (human-in-the-loop / audit gate)\r\n@hooks.pre_tool_call_decide\r\nasync def intercept_tool(tool_call: types.ToolCall) -> types.HookResult:\r\n broadcast_to_dashboard({\r\n "type": "TOOL_CALL",\r\n "tool": tool_call.name,\r\n "args": tool_call.args,\r\n })\r\n # Return HookResult to approve or block execution\r\n return types.HookResult(allow=True)\r\n\r\n# 3. Post-execution tool receipts\r\n@hooks.post_tool_call\r\nasync def record_tool_result(result):\r\n broadcast_to_dashboard({\r\n "type": "TOOL_RESULT",\r\n "tool": result.name,\r\n "error": getattr(result, "error", None),\r\n })\r\n\r\nconfig = LocalAgentConfig(\r\n model="gemini-3.8-flash",\r\n hooks=[on_session_start, on_session_end, intercept_tool, record_tool_result],\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff5017df750>)])]>

使ってみる

以下のリソースを参考にして、独自のエンタープライズ向けエージェントコントロールプレーンの構築を開始してみませんか。

- Google Cloud、フォワードデプロイドエンジニア、Wei Yih Yap

- Google Cloud、プラクティスカスタマーエンジニア、Paul Datta

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

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

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

次のステップ

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

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

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

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

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

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 0x7ff50014bb10>), ('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 0x7ff500f5c5d0>), ('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 0x7ff500df4110>)])]>

標準の 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 0x7ff50223e3d0>)])]>

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

コルーチン 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 0x7ff5016ad990>)])]>

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

リクエストターンをまたいで会話履歴を手動で管理するのは煩雑な作業になることがあります。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 0x7ff5016ad050>)])]>

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

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

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

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

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

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

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

さらに、チャットサービスを使用する場合は、自動関数呼び出し（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 0x7ff5016ac990>)])]>

次のステップ

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

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

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

AI プロトタイプを本番環境に移行する前にすべてのスタートアップが答えておくべき 10 の質問

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

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

Google Cloud で AI を活用したスタートアップを立ち上げることが、これまでになく簡単になっています。

朝食時に Google AI Studio から API キーを取得し、それを Antigravity に貼り付ければ、昼食時には製品のプロトタイプができ始めているでしょう。

しかし、進歩の道のりは一直線ではありません。スタックを構築する際に、次の 3 つの課題に直面することがよくあります。

API キーが漏洩し、48 時間で高額な請求が発生する。
AI Studio から Gemini Enterprise Agent Platform への移行を急いで進めたが、チームに Identity and Access Management（IAM）の担当者がいないため、ロードマップが数週間停滞する。
リリースは成功したが、プロジェクトごとのデフォルトの割り当てが原因でアプリが「HTTP 429 Too Many Requests」を返すようになり、追加料金を支払わずに容量を増やす明確な方法がない。

これらはどれも特殊なエッジケースではありません。これらは、計画なしに急いで行動して失敗に陥ってしまうパターンであり、誰もが一度は経験したことがあるでしょう。

ここでは、スタートアップが事業を拡大する前に答えられるようにしておくべき 10 の質問を紹介します。これらの質問を、意思決定が将来を左右する 3 つのフェーズに分類しています。

オンボーディング（独自のプロジェクトと ID を適切に設定する）
スケール（費用をかけずにスループットを高める）
管理（費用、キー、エージェントの暴走を防ぐ）。

これらの 10 の質問は、プロトタイプから本番環境への移行そのものを対象としています。各質問の最後には、すぐに実行できる短いスニペットが用意されています。このスニペットは、ご自身のプロジェクトにコピーして使用できます。その移行に特有ではない周辺的な意思決定（データレイヤと RAG アーキテクチャ、CI / CD、ネットワーク設計など）については、同様に重要ですが、ここでは意図的に対象外としています。

オンボーディング: 基礎を固める（ごく初期の段階）。

#1 Google AI Studio と Gemini Enterprise Agent Platform のどちらから始めればよいですか？

どちらのサーフェスも同じ Gemini ファミリーのモデルを提供しますが、解決する問題は異なります。

Google AI Studio（Gemini Developer API を使用）は、アイデアから実際に動作するコードへと至る最短経路となります。ブラウザ IDE、API キー、豊富な無料枠が用意されており、クラウドプロジェクトを構成する必要はありません。ほとんどのアイデアはここから始めるべきであり、Google のガイダンスでもそのように推奨されています。
Gemini Enterprise Agent Platform （旧称 Vertex AI）は、同じ Gemini モデル（サードパーティ製と OSS のモデルも含む）に加えて、企業向けの管理機能を備えています。具体的には、未加工のキーに代わる IAM とサービスアカウントによる認証、VPC Service Controls、Cloud Logging と Cloud Monitoring、予約済み容量、リージョンエンドポイント、そして最初の企業顧客によるセキュリティ審査で問われるコンプライアンスサーフェスです。

ほとんどのスタートアップにとっての正解は、両方を意図した順序で行うことです。まず AI Studio でプロトタイプを作成し、その後、実際のユーザーに提供する前に移行します。スタートアップにとって危険なのは、これらを交換可能なソリューションとして扱うことです。AI Studio のシンプルなキーモデルは企業向けの管理機能に適したものではなく、Agent Platform の IAM モデルは、認証情報が盗まれる被害から保護されていることを実感するまで、過剰なものに見えるかもしれません。

実際には、思ったより手間はかかりません。

統合された google-genai SDK は、両方を対象としています。

code_block: <ListValue: [StructValue([('code', '# Prototype: Google AI Studio, raw API key\r\nfrom google import genai\r\nclient = genai.Client(api_key="YOUR_AI_STUDIO_KEY")\r\n\r\n# Production: GEAP, no key — uses Application Default Credentials (ADC)\r\nfrom google import genai\r\nclient = genai.Client(\r\n vertexai=True,\r\n project="my-startup-prod",\r\n location="us-central1",\r\n)\r\n\r\nresp = client.models.generate_content(\r\n model="gemini-2.5-pro",\r\n contents="Summarize this contract in three bullets.",\r\n)\r\nprint(resp.text)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff501467890>)])]>

#2 IAM のエキスパートがいない場合に Google Cloud プロジェクトを設定するにはどうすればよいですか？

スタートアップが Agent Platform への移行を躊躇する最大の理由は、コードではなく、API キーを 1 つ用意するだけの運用から、フォルダ、サービスアカウント、組織のポリシー、ロギング、IAM バインディングを備えたクラウドプロジェクトに移行するという、運用上の大きな変化です。チームに専任のクラウド管理者がいない場合、最初のプロジェクトのセットアップに 1 週間分のエンジニアリング時間がかかることがあります。

3 つのステップで、この時間を大幅に短縮できます。

コンソールを操作する代わりに、独自の設計思想が反映されたプロジェクトテンプレートを使用する。クラウド設定のチェックリストと Google Cloud アーキテクチャフレームワークを使用すると、本番環境レベルのフォルダ階層（prod / non-prod / dev）、一元的なロギングとモニタリングのプロジェクト、Security Command Center の有効化、ベースライン組織ポリシーが提供されるため、これらをゼロから設計する必要はありません。
実際に使用する API を一度有効にする必要なときにプロジェクトごとに実行しなくても済むように、バッチ処理します。請求先のリンクの手順は省略できません。これから有効にしようとしている有料 API は、請求先アカウントが関連付けられていないプロジェクトでは有効にできないため、まずはその設定を行います。
Gemini にロールを選択させますが、限定的なロールをリクエストします。ロールのリファレンスを覚える必要はありません。アクセス権を付与するダイアログで [推奨ロールの表示] を使用すると、平易な言葉でタスクを説明できます（「このサービスアカウントは Gemini モデルを呼び出し、1 つの Cloud Storage バケットを読み取る必要があります」など）。すると、その理由とともに事前定義ロールが返されます。初日に知っておくべき注意点が 1 つあります。デフォルトでは、一般的なユースケースをカバーするロールが提案されます。通常は、サービスの管理者、編集者、閲覧者のロールです。これらは、必要以上に広い権限を持っています。プロンプトで「最小権限」または「最小限のアクセス」と指定すると、代わりに詳細なロールが返されます。入力する量は同じですが、認証情報が漏洩した場合の影響範囲は大幅に小さくなります。出典: Gemini のアシスト機能を使用して事前定義ロールの候補を取得する

code_block: <ListValue: [StructValue([('code', '# One-shot: create a Vertex-ready project and turn on the services a\r\n# typical AI startup uses.\r\ngcloud projects create my-startup-prod --name="My Startup (prod)"\r\ngcloud config set project my-startup-prod\r\n\r\n# REQUIRED before enabling billing-dependent APIs (aiplatform, run, etc.).\r\n# Use `gcloud billing accounts list` to find your billing account ID.\r\ngcloud billing projects link my-startup-prod --billing-account=012345-6789AB-CDEF01\r\n\r\ngcloud services enable \\\r\n aiplatform.googleapis.com \\\r\n run.googleapis.com \\\r\n artifactregistry.googleapis.com \\\r\n logging.googleapis.com \\\r\n monitoring.googleapis.com \\\r\n secretmanager.googleapis.com \\\r\n cloudbilling.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138ce10>)])]>

出典: gcloud services enable リファレンス、gcloud billing projects link（GA）、GE Agent Platform 環境の設定。

単独の創業者である場合は、個人の GCP アカウントで構築しないようにしてください。適切な組織または自己所有の組織を最初に作成し、その内部ににプロジェクトを作成します。この 1 つの決定により、IAM から請求、監査まで、その他すべての作業が大幅に簡素化されます。

#3 Google Cloud を使用しています。コードの認証には、API キー、サービスアカウント、ユーザー認証情報のどれを使用すればよいですか？

この問題には安全性の階層があり、最も簡単なオプションが本番環境において適切なオプションであることは稀です。

未加工の API キーは、ローカルでのプロトタイピングには適しています。これは、有効期間が長く、クライアントバンドルや公開リポジトリに漏洩しやすく、それに気づくまで無制限のアクセスを許可してしまうため、本番環境では危険です。
OAuth によるユーザー認証情報（アプリケーションのデフォルト認証情報）は、対話型ツール、CLI のほか、デベロッパーのノートパソコンで実行されるコードに最適です。
サーバー、コンテナ、スケジュールされたジョブで実行されるものには、最小権限の IAM ロールを持つサービスアカウントが適しています。

目指すべきパターンは、コードが鍵をまったく認識しないパターンです。Google Auth ライブラリを呼び出すだけで、環境からアプリケーションのデフォルト認証情報（ADC）が読み取られます。これは、Cloud Run サービス、GKE ワークロード、または Compute Engine VM にアタッチされているサービスアカウントに対して発行された有効期間の短いトークンです。認証コードを記述しなくても、エンタープライズグレードの認証を利用できます。

code_block: <ListValue: [StructValue([('code', '# On a developer laptop\r\ngcloud auth application-default login\r\n\r\n# On a server (Cloud Run, GKE, etc.) — no login, no key file.\r\n# Attach a service account with just the roles the app needs.\r\ngcloud run deploy my-agent \\\r\n --image=us-docker.pkg.dev/my-startup-prod/agents/api:v1 \\\r\n --service-account=agent-runtime@my-startup-prod.iam.gserviceaccount.com \\\r\n --region=us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138ea90>)])]>

code_block: <ListValue: [StructValue([('code', '# Application code — notice: no keys, no secrets.\r\nfrom google import genai\r\n\r\nclient = genai.Client(\r\n vertexai=True,\r\n project="my-startup-prod",\r\n location="us-central1",\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138e810>)])]>

最後に、今後に備えて、そのサービスアカウントに、ワークロードが実際に必要とする最小限の IAM ロールを付与します。通常は、より広範な管理者ロールではなく、モデルを呼び出すための roles/aiplatform.user にします。30 秒ほど余分に時間がかかりますが、認証情報が漏洩したとしても、それがマスターキーになるのを防ぐことができます。

#4 AI Studio の API キーから Agent Platform の IAM モデルへの移行は、いつまで引き延ばせますか？

思っているよりも早く対応すべきです。正しいトリガーは、実害が出たときではありません。次のいずれかに該当する場合です。

キーがノートパソコンから流出した（リポジトリにチェックインした、Slack に貼り付けた、モバイルアプリに組み込んだ）。
チームに API を呼び出す必要がある人が複数いる。
1 か月あたり数百ドル以上を費やしている。
有料ユーザーのオンボーディングが間近に迫っている。

成長中のスタートアップが不意を突かれる可能性のある落とし穴は、単純なものです。たとえば、通常は月額 180 ドルを支払っているアカウントの Gemini API キーが公開リポジトリから漏洩し、蒸留攻撃に悪用されるケースです。この場合、所有者が最初の請求アラートを確認する前に、数万ドルの料金が累積してしまいます。Google Cloud の責任の共有モデルは明確です。お客様は、有効な認証情報を使用して発生した料金について責任を負います。

移行自体は、移行に対する不安よりもはるかに小規模なものです。google-genai では、#1 に示す 2 行の変更です。実際に時間がかかるのは、それに伴うプロジェクトのセットアップです。まさにそのために 2 が存在します。

カットオーバー日の実用的なチェックリスト:

code_block: <ListValue: [StructValue([('code', '# 1. Revoke every existing AI Studio key that has ever left a laptop.\r\n# (Go to https://aistudio.google.com/apikey and delete them.)\r\n\r\n# 2. Confirm your production code has no api_key= arguments.\r\ngrep -rn "api_key" src/\r\n\r\n# 3. Enable GEAP and confirm ADC works locally.\r\ngcloud services enable aiplatform.googleapis.com\r\ngcloud auth application-default login\r\npython -c "\r\nfrom google import genai\r\nc = genai.Client(vertexai=True, project=\'my-startup-prod\', location=\'us-central1\')\r\nprint(c.models.generate_content(model=\'gemini-2.5-flash\', contents=\'ping\').text)\r\n"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138d510>)])]>

ステップ 3 でレスポンスが出力された場合は、Agent Platform を使用しています。

スケール: 追加料金を支払うことなく容量を増やす。

#5 リリースしたのに、HTTP 429 エラーが頻発しています。これを解消するにはどうすればよいですか？

Agent Platform からの「429 Too Many Requests」はほとんどの場合、次の 2 つのいずれかを意味します。

プロジェクトの階層の動的共有割り当て（DSQ）の上限に達した場合。DSQ は、プロジェクトの履歴に基づいてサイズが設定される共有プールです。プラットフォーム全体での不正使用を防ぐため、新しいプロジェクトは設計上、控えめな上限から始まります。
世界的に需要が急増しているときに、グローバルエンドポイントを呼び出し、共有容量をめぐって世界中のトラフィックと競合している場合。

対策としてすぐ思いつくのは、割り当て増加のチケットを送信することです。必要であればそうすることもできますが、通常は 2 つのアーキテクチャ上の変更で、より迅速かつ安価に問題を解決できます。

リージョンエンドポイントに固定する。Agent Platform でのスタートアップトラフィックの半分以上は、デフォルトでグローバルルーティングに設定されています。特定のリージョン（us-central1 など）に固定すると、グローバルな競合を回避でき、通常はレイテンシも改善されます（次の質問で説明しますが、1 つだけ例外があります。Priority PayGo を特に希望される場合、この機能は現在グローバルエンドポイントでのみ提供されています。それ以外の場合は、リージョンに固定します）。

code_block: <ListValue: [StructValue([('code', 'from google import genai\r\n\r\n# Global (default): competes against worldwide demand.\r\n# Regional: routes only to the regional cluster, less contention.\r\nclient = genai.Client(\r\n vertexai=True,\r\n project="my-startup-prod",\r\n location="us-central1", # <-- this is the one-line fix\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138f210>)])]>

適切な再試行とバックオフを追加する。429 は再試行可能なシグナルであり、致命的なエラーではありません。本番環境のクライアントには、ジッターを伴う指数バックオフが必要です。最新の google-genai SDK には、この動作が組み込まれていますが、実際に有効にした場合にのみ機能します。これは見落としがちです。古い Vertex コードで見たことがあるかもしれませんが、従来の `google.api_core.retry.if_transient_error` デコレータは使用しないでください。これは従来の例外クラス向けに設計されており、新しい `google.genai.errors.APIError` を認識しないため、429 エラーを再試行せずに無視します。代わりに、SDK の組み込みの再試行オプションを使用します。

code_block: <ListValue: [StructValue([('code', 'from google import genai\r\nfrom google.genai import types\r\n\r\nclient = genai.Client(\r\n vertexai=True, project="my-startup-prod", location="us-central1",\r\n http_options=types.HttpOptions(retry_options=types.HttpRetryOptions(\r\n attempts=5, initial_delay=1.0, max_delay=60.0, exp_base=2.0, jitter=1.0,\r\n http_status_codes=[408, 429, 500, 502, 503, 504],\r\n ))\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138fe50>)])]>

この状況をどのように予測しますか？できれば、ユーザーから報告を受ける形ではなく。Agent Platform はサービング指標を Cloud Monitoring に公開します。また、[コンソール] > [Agent Platform] > [ダッシュボード] > [モデルのオブザーバビリティ] に、アセンブル不要の事前構築済みダッシュボードがあります。1 秒あたりのリクエスト数、トークンスループット、最初のトークンのレイテンシ、エラー率をすぐに確認できます。

実際にアラートを生成する指標は aiplatform.googleapis.com/publisher/online_serving/model_invocation_count です。error_category ラベルが付き、値は user、system、capacity のいずれかになります。capacityに関するアラートは、自分自身の間違ったリクエストから実際のスロットリングを分離します。これは、未加工の 429 エラーのカウントでは行われません。

注意すべき点として、Standard PayGo では「使用量が割り当ての 80% に達したら警告して」というアラートを作成できません。動的共有割り当てでは、80% を限度とする、プロジェクトごとの固定値はありません。429 エラーは、共有容量の一時的な競合を意味し、限度を超えたことを意味するものではありません。割合を上限とするアラートは、実際の上限指標が提供されるプロビジョンドスループットを使用している場合にのみ意味を持ちます。

code_block: <ListValue: [StructValue([('code', 'gcloud monitoring policies create --policy-from-file=capacity-alert.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138d710>)])]>

出典: Agent Platform の指標リスト、モデルのオブザーバビリティダッシュボード、RetryOptions のソース、コア retry_base.py、genai errors.py、429 エラーの削減、gcloud monitoring policies create、動的共有割り当て。

Agent Platform のレート制限に関するドキュメントに沿って、プロジェクトの現在の上限が実際にどの程度であるかを把握してから、上限を超えているかどうかを判断してください。

#6 Standard PayGo、Priority PayGo、プロビジョンドスループットのうち、どの消費モデルを利用すればよいですか。

3 つの消費モデルは、ワークロードの形態も進め方もまったく異なります。適切なものを選択することで、スタートアップは AI の請求額を大幅に削減できます。まず、それぞれの定義を確認し、どのような場合に適しているか、または適していないかを見ていきましょう。

Standard PayGo（DSQ）: 共有プールからのトークン単位の課金。低価格、保証なし。Priority PayGo: トークン単位の課金、プレミアム料金のためキューをスキップ可能。プロビジョンドスループット（PT）: 予約済み容量を前払い。予測可能、使用しないと無効。

消費タイプ	最適な用途	注意点
Standard PayGo（DSQ）	初期段階、低 QPS、急激に変動するプロトタイプトラフィック	急増時に 429 エラーが発生、信頼性 SLO なし
Priority PayGo	429 を許容できない、バースト性の高い、収益に不可欠なトラフィック	標準トークン価格の約 1.8 倍
プロビジョンドスループット（PT）	安定した、予測可能な、大量の本番環境トラフィック	使用率が 40% 未満の場合、費用が無駄になる。スパイク時には PayGo にオーバーフロー

スタートアップによくある間違いは、PT を早すぎる時期に購入することです。特に、大規模なリリースの翌週、トラフィックが増加する一方のように感じられるときに、こうした間違いが起きます。PT は予約済みの容量です。使用するかどうかにかかわらず料金を支払う必要があり、ベースラインが単なる願望ではなく、真に予測可能になった場合にのみ、元が取れるようになります。

実用的な手順は次のとおりです。

Standard PayGo の第 1～4 週。これを使用して、実際のリクエストの形態（p50 と p99 での 1 分あたりのトークン数、リクエストのバースト、バッチ処理可能とリアルタイム処理の内訳）を測定します。
初めて 429 エラーが大量に発生したときは、実際に重要なトラフィックに対して Priority PayGo を有効にします。これは構成の変更であり、注文書ではないため、調達部門の担当者は関与する必要はありません。

code_block: <ListValue: [StructValue([('code', '# Priority PayGo request: use the global endpoint + two extra headers.\r\nfrom google import genai\r\nfrom google.genai import types\r\n\r\nclient = genai.Client(vertexai=True, project="my-startup-prod", location="global")\r\nresp = client.models.generate_content(\r\n model="gemini-2.5-pro",\r\n contents="Rank these support tickets by urgency: ...",\r\n config=types.GenerateContentConfig(\r\n # Priority PayGo headers, per current GEAP docs.\r\n http_options=types.HttpOptions(headers={"X-Vertex-AI-LLM-Request-Type": "shared", "X-Vertex-AI-LLM-Shared-Request-Type": "priority"}),\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138fd10>)])]>

3. ベースラインの TPM を予測できるようになったら、PT を購入してフラットベースラインをカバーし、ベースラインを超える分は PayGo にオーバーフローします。これが、Google が推奨する組み合わせパターンであり、まったく理にかなったものです。単なる宣伝文句ではなく、両方の利点を活かしています。

出典: Priority PayGo のドキュメント、google-genai HttpOptions のソース、GEAP REST リファレンス。

#7 どのリクエストをライブにして、どのリクエストをバッチジョブにする必要がありますか？

スタートアップのワークロードのほとんどは、リアルタイムを装ったバッチジョブであることが実態です。ジョブをインタラクティブなパスから外すたびに、本当に高速であることが必要なトラフィック、つまりユーザーが実際にスピナーを見つめているトラフィックのために DSQ のヘッドルームが解放されます。

トラフィックを分類するのに役立つ 3 つの質問:

ユーザーが 1 秒以内に結果を確認する必要がありますか？この場合は、ライブ推論です。
ユーザーはスピナーを見ながら数秒間待つことができますか？この場合もライブですが、ストリーミングの候補でもあります。
ユーザーは「準備が整い次第メールでお知らせします」または「しばらくしてからもう一度ご確認ください」というメッセージを許容できますか？この場合は、バッチ予測です。

Agent Platform でのバッチ予測は完全に独立したキューで実行され、インタラクティブな DSQ を消費しません。また、通常はオンデマンド推論の半額程度です。これは、ライブトラフィックの高速化と費用の削減という二重のメリットをもたらす、まれな例です。

code_block: <ListValue: [StructValue([('code', '# Kick off a batch prediction job from a JSONL file in Cloud Storage.\r\n# Each line is one prompt; results land in another Cloud Storage prefix.\r\nfrom google import genai\r\nfrom google.genai import types\r\n\r\nclient = genai.Client(vertexai=True, project="my-startup-prod", location="us-central1")\r\n\r\njob = client.batches.create(\r\n model="gemini-2.5-flash",\r\n src="gs://my-startup-prod-batch/inputs/nightly-summaries.jsonl",\r\n config=types.CreateBatchJobConfig(\r\n dest="gs://my-startup-prod-batch/outputs/",\r\n ),\r\n)\r\nprint(job.name, job.state)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138e210>)])]>

一般的な候補: 夜間のドキュメント要約、新規登録者のバックグラウンド分類、一括翻訳、エンベディングのバックフィル、テストセットに対する評価実行。これらのいずれかが現在のライブパスにあれば、通常、それらを移動することが、今週できる最も効果的な変更となります。

管理: 費用、鍵、エージェントを管理する。

#8 請求額が 3 倍になっても丁寧なメールが届くだけでなく、実際に費用を削減できる利用額上限を設定するにはどうすればよいですか？

正直なところ、最近まで予算は通知するだけで、ブレーキペダルは自分で作る必要がありました。7 月にこの状況が変わりました。メカニズムは 3 つあり、これらはレイヤとして考えることができます。

利用額上限の予算（プレビュー）。Cloud Billing の予算で、メール通知だけでなく、強制的な適用が可能になりました。プロジェクトに利用額上限を設定すると、使用料金が予算の 100% を超えた時点で、Google はサービスを一時停止します。サービスを再開するには、手動で一時停止を解除する必要があります。Gemini API、Cloud Run、Cloud Run Functions とともに、Agent Platform が対象リストに明示的に記載されています。アラートは 50% と 80% で引き続き発生するため、予告もなく一時停止になるわけではありません。

利用する前に知っておくべき 3 つのこと:

各上限は、1 つのプロジェクトと 1 つの対象サービスに適用されます。アカウント全体の保護ではありません。Agent Platform と Cloud Run の両方に上限を設定する場合は、2 つの上限を設定することになります。
適用は即時ではなく、推定費用に基づきます。上限を超えた分は通常どおり請求されるため、実際の予算上限よりも低い数値を設定してください。上限の解除は手動で行われ、サービスの再開には最長で 1 時間かかることがあります。また、プロビジョンドスループットの使用も一時停止されるため、容量を前払いしている場合は、上限に達するとその容量も使えなくなります。
公開時点ではプレビュー版であり、対象サービスのリストは今後増えていくことが記載されています。設計する前に、現在のリストを確認してください。

2. 課金を無効にする Pub/Sub トリガーによる予算設定。利用額上限では対応できない、広範な影響範囲（複数のサービスの一括設定、プロジェクト全体、まだ対象になっていないサービスなど）が必要な場合は、依然として適切なツールです。予算がしきい値に達すると、Pub/Sub が Cloud Functions の関数を起動して請求先アカウントを切り離し、数分以内にすべての課金対象アクティビティを停止します。ネイティブの上限よりも大雑把で危険です。リソースが回復不能になる可能性があるため、最初にではなく、2 番目に試みてください。詳細なチュートリアル: 予算通知に自動的に応答する。

code_block: <ListValue: [StructValue([('code', '# Sketch: create a budget SCOPED TO ONE PROJECT that publishes to Pub/Sub at 50%, 90%, 100%.\r\ngcloud billing budgets create \\\r\n --billing-account=012345-6789AB-CDEF01 \\\r\n --display-name="my-startup-prod hard stop" \\\r\n --budget-amount=2000USD \\\r\n --filter-projects=projects/my-startup-prod \\\r\n --threshold-rule=percent=0.5 \\\r\n --threshold-rule=percent=0.9 \\\r\n --threshold-rule=percent=1.0,basis=current-spend \\\r\n --notifications-rule-pubsub-topic=projects/my-startup-prod/topics/budget-alerts'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138c7d0>)])]>

出典: 利用額上限の予算を管理する、プログラムによる通知を設定する、gcloud billing budgets create リファレンス、Cloud Billing の予算のコンセプト、通知で課金を無効にするチュートリアル、プログラムによる通知のペイロードスキーマ。

デフォルト設定が予期しない問題を引き起こす可能性があるため、事前に対応すべきことが 2 つあります。

予算の範囲を制限する: --filter-projects を使用しない場合、予算は請求先アカウント全体に適用されます。いずれかのプロジェクトで急増が発生すると、すべてのキルスイッチがトリガーされます。
ローカルにデプロイする: 予算通知では、影響を受けるプロジェクトが指定されていません。キルスイッチが目的のプロジェクトにのみ影響するように、保護するプロジェクト（my-startup-prod など）と同じプロジェクトに Cloud Functions の関数をデプロイします。

次に、そのトピックに小さな Cloud Functions の関数を接続し、100% のしきい値に達したときに projects.updateBillingInfo を呼び出して請求先アカウントのリンクを解除します。これが、回路ブレーカーの役割を果たします。

割り当てのオーバーライドによる機械的な上限。上記のキルスイッチを設定しなくても、プラットフォームのデフォルトを下回る、モデルごと、リージョンごとの割り当てを明示的に設定することで、費用が累積するレートに上限を設けることができます。アプリの本来の用途において gemini-2.5-pro に対する 1 分あたりのリクエスト数が 500 を超えることがない場合は、Cloud Quotas コンソールで上限を 500 に設定します。割り当てによってサービスが拒否されるため、キーが漏洩してもリソースが消費されることはありません。

#9 シークレットはどこに保存すべきですか？（.env ファイルではありません）

簡潔に言うと、Secret Manager です。環境変数、.env ファイル、リポジトリのいずれにも保存しないでください。IAM を介して、読み取りアクセス権を、そのアクセス権を必要とするサービスアカウントにのみ付与します。

code_block: <ListValue: [StructValue([('code', '# Store a third-party API key (Stripe, OpenAI, whatever).\r\necho -n "sk_live_xxx" | gcloud secrets create stripe-live-key --data-file=-\r\n\r\n# Grant only the runtime service account access to read it.\r\ngcloud secrets add-iam-policy-binding stripe-live-key \\\r\n --member=serviceAccount:agent-runtime@my-startup-prod.iam.gserviceaccount.com \\\r\n --role=roles/secretmanager.secretAccessor'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138f350>)])]>

code_block: <ListValue: [StructValue([('code', '# Application code fetches it at startup; nothing lives on disk.\r\nfrom google.cloud import secretmanager\r\nsm = secretmanager.SecretManagerServiceClient()\r\nresp = sm.access_secret_version(\r\n name="projects/my-startup-prod/secrets/stripe-live-key/versions/latest"\r\n)\r\nstripe_key = resp.payload.data.decode("utf-8")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138fcd0>)])]>

次に、2 つのちょっとした習慣を紹介します。これらは、いざ必要になったときにその価値がわかります。

定期的なローテーションと、疑いがあるときのローテーション。Secret Manager のバージョンは安価です。既存のバージョンを書き換えずに、ロールフォワードしてください。
シークレットが漏洩したときの検出。Secret Manager の通知と Google Cloud のSensitive Data Protectionにより、攻撃者に先んじて、リポジトリにチェックインされたキーやログストリームに貼り付けられたキーを捕捉できます。

ユーザーに代わって動作する AI アプリケーション（ユーザーに代わって Gmail を呼び出す、ドライブのフォルダを読み取る、ユーザーの認証情報を使用してサードパーティの SaaS にアクセスするなど）には、有効期間の長いトークンを保存しないでください。有効期間の短いアクセストークンと更新フローとともに OAuth 2.0 を使用します。これにより、ユーザーが突然退職した場合や、不正使用されたアカウントが取り消された場合、エージェントは同時にアクセス権を失います。

#10 新しい AI エージェントが、決してすべきではないことをしないようにするにはどうすればよいでしょうか？

ツールの呼び出し、ウェブの閲覧、コードの実行が可能なエージェントには、他のあらゆる本番環境サービスと同様の、あるいはそれ以上に「多層防御」の考え方が求められます。なぜなら、そうしたエージェントは、ユーザーにとってもモデルにとっても事前に完全には予測できないような判断を下すからです。

4 つのレイヤがあり、実際のユーザーがいる場合は、どれも省略できません。

1. エージェント自体の ID。エージェントに独自のサービスアカウントを付与し、本当に必要なリソースとツールのみにスコープを限定します。これは、他のワークロードと同じ最小権限の原則です。Agent Engine はファーストクラスのエージェント ID をサポートしているため、監査ログですべてのアクションを特定のエージェントインスタンスに関連付けることができます。

2. サンドボックス化されたコード実行。エージェントが生成されたコードを実行する場合（データ分析や「この Python を実行して」のフローにおける一般的なパターン）、アプリケーションプロセスで実行しないでください。隔離されたサンドボックスを使用することで、不適切な組み合わせが本番環境データに影響を与えないようにします。

code_block: <ListValue: [StructValue([('code', '# Enable server-side code execution inside a sandbox for a request.\r\nfrom google import genai\r\nfrom google.genai import types\r\n\r\nclient = genai.Client(vertexai=True, project="my-startup-prod", location="us-central1")\r\nresp = client.models.generate_content(\r\n model="gemini-2.5-pro",\r\n contents="Compute the correlation between these two columns: ...",\r\n config=types.GenerateContentConfig(\r\n tools=[types.Tool(code_execution=types.ToolCodeExecution())],\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff50138f250>)])]>

3. プロンプトと回答のフィルタリング。Model Armor は、モデル呼び出しの手前に配置され、プロンプトインジェクション、ジェイルブレイク、機密データの引き出し、ブランドにそぐわない出力をスクリーニングします。これらはすべて、実際のユーザーが使い始めれば、実質的に避けられないものとなります。

4. 行動のモニタリング。脅威検出機能を備えた Security Command Center は、エージェントの動作における異常にフラグを立てます。たとえば、サービスアカウントがこれまで使用したことのない API を突然呼び出す、エージェントが未知の外部ホストにアクセスする、特権操作が予期せず急増する、といったことです。これは、ほぼリアルタイムで行われます。

エージェントが実際のユーザーに代わって行動したり、実際のお金を扱ったりするようになると、これらはどれも省略できなくなります。

いわば宿題として

リポジトリ、ノートブック、本番環境ランタイムで、未加工の API キーを監査します。そこにあるべきでないキーをローテーションします。
同期レスポンスを必要としないワークロードは、Batch API に移行します。
モデルのオブザーバビリティダッシュボードを有効にして、容量エラーに関するアラートを 1 つ設定し、次の 429 エラーが顧客より前に自分に届くようにします。
プロジェクトの利用額上限を設定し、50% と 80% のアラートに注意します。使用量が予算の 100% を超えると、手動で解除するまで、Google はサービスを一時停止します。

今週この 4 つの事項を実施すれば、AI 機能をリリースしているほとんどのスタートアップよりも先を行くことができます。

次回取り上げてほしいシナリオはありますか？Google Cloud for Startups までお問い合わせください。

- Google Cloud AI、テクニカルソリューション、Sergio Villani

デベロッパー

エージェント プラグインの開発から学んだ、評価エンジニアリングの 4 つの教訓

1. 要約ではなく、実行ステップを評価する

2. 非同期オペレーションの評価を設計する

3. ライブ実行と「ドライラン」を並行してテストする

4. 「ゴールデン セット」を永続的なベースラインとして使用する

次のステップ

Google Antigravity で Claude Opus 5.5 と Claude Sonnet 5.5 が利用可能に

Antigravity のマルチモデル エンジニアリング パターン

ご利用にあたって

「MCP ツールボックス」Java SDK v1.0 のご紹介: 企業向けのエージェント型データアクセス

MCP: ユニバーサル インターフェース

Java SDK v1.0 の新機能: 本番環境ワークロードに対応

Java SDK v1.0 を使ってみる

実際の例: 自律型交通コンシェルジュ

基盤: ネイティブ エンベディングを備えた AlloyDB スキーマ

インテントと SQL のマッピング: tools.yaml

Spring Boot のステートフル エージェント アーキテクチャ

すべてをつなぎ合わせる: Java v1.0 におけるツールのリスト表示、呼び出し、実行

セキュア バイ デフォルト: 認証とデプロイ

使ってみる

Agent Development Kit は 5 つの言語に対応

共通の基盤

エージェント ファースト開発の第一歩

各 ADK の実践的なサンプル

Go

TypeScript

Java

Kotlin

妥協のない選択

AI 推論モデル提供のためのネットワーキング - GKE のみ、およびその他すべてのバックエンド

エントリ ポイント

設計における共通サービス

GKE のみで提供される設計パターン

GKE のトラフィック フローの例

すべてのバックエンドで提供される設計パターン

すべてのバックエンドのトラフィック フローの例

次のステップ

SRE ブックの 10 年間:『Site Reliability Engineering』第 2 版のご紹介

低コストでスムーズな開発を実現する Managed Lustre を誰でも利用可能に

低コスト: ダイナミック ティアで Lustre をより低コストで利用

スムーズな開発: 開発者のワークロードをワンストップで処理する Lustre

ワンストップ ショップ ワークフローを自分で実行

未来と次のステップを見据えて

次のステップ

GKE CPU 起動ブースト: オーバープロビジョニングなしでアプリの起動を高速化

最新のアプリケーションが起動時に追加の CPU を必要とする理由

仕組み: Kubernetes のインプレース Pod サイズ変更

CPU 起動ブーストの仕組み（Pod ライフサイクルの概要）

前提条件と提供状況

スタートガイド: CPU 起動ブーストを構成する

例 1: 固定定常状態での Pod レベルのブースト（updateMode: "Off"）

例 2: 起動ブーストと継続的な VPA 自動スケーリングの組み合わせ

クラスタでの起動ブーストの確認

本番環境ワークロードのベスト プラクティス

使ってみる

Data Agent Kit の一般提供を開始: Google のデータクラウドがあらゆるコーディング エージェントで利用可能に

Data Agent Kit とは

仕組み

構築できるもの

分析とグラフ: BigQuery と BigQuery Graph（一般提供の新機能）

オペレーショナル データベースとリアルタイム データベース: Spanner、AlloyDB、Cloud SQL、Bigtable（一般提供版の新機能）

レイクハウスと Spark: Managed Service for Apache Spark と Lakehouse for Apache Iceberg（一般提供の新機能）

パイプラインとオーケストレーション: dbt、Dataform、Managed Service for Apache Airflow

デベロッパー エクスペリエンスの向上

エンタープライズに対応

インストールして使ってみる

次のステップとハンズオン リソース

強化学習（RL）による Gemini モデルのカスタマイズに関するベスト プラクティス ガイド

RLFT とは

RLFT を使用する状況

RLFT のユースケース

どこから始めるべきか

使ってみる

AI ワークロードのコンピューティングを柔軟に選択できるよう Google Cloud ネットワーキングがサポート

リソース オプション

ネットワーキングの選択肢

まとめ

次のステップ

AlphaEvolve で動画処理を高速化する方法

エージェントプラグインの開発から学んだ、評価エンジニアリングの 4 つの教訓

4. 「ゴールデンセット」を永続的なベースラインとして使用する

Antigravity のマルチモデルエンジニアリングパターン

MCP: ユニバーサルインターフェース

基盤: ネイティブエンベディングを備えた AlloyDB スキーマ

インテントと SQL のマッピング: `tools.yaml`

Spring Boot のステートフルエージェントアーキテクチャ

セキュアバイデフォルト: 認証とデプロイ

エージェントファースト開発の第一歩

エントリポイント

GKE のトラフィックフローの例

すべてのバックエンドのトラフィックフローの例

低コスト: ダイナミックティアで Lustre をより低コストで利用

ワンストップショップワークフローを自分で実行

例 1: 固定定常状態での Pod レベルのブースト（`updateMode: "Off"`）

本番環境ワークロードのベストプラクティス

Data Agent Kit の一般提供を開始: Google のデータクラウドがあらゆるコーディングエージェントで利用可能に

オペレーショナルデータベースとリアルタイムデータベース: Spanner、AlloyDB、Cloud SQL、Bigtable（一般提供版の新機能）

デベロッパーエクスペリエンスの向上

次のステップとハンズオンリソース

強化学習（RL）による Gemini モデルのカスタマイズに関するベストプラクティスガイド

リソースオプション

1. AlphaEvolve の分割ループアーキテクチャを理解する

Antigravity SDK を使用してエージェントハブやカスタムハーネスを単一ツールキットで実現

実際のメカニズムオペレーターまたはダッシュボードが Antigravity エージェントとやり取りすると、ランタイムは 5 つのコアメカニズムを通じて処理の実行を調整します。

4. ライフサイクルフックによるリアルタイムのテレメトリーとインターセプト

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

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

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

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

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

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

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

#3 Google Cloud を使用しています。コードの認証には、API キー、サービスアカウント、ユーザー認証情報のどれを使用すればよいですか？

#6 Standard PayGo、Priority PayGo、プロビジョンドスループットのうち、どの消費モデルを利用すればよいですか。