Back to Archive

GCP News - 2026-09-04

2026-09-04
最終更新: 2026-09-05 05:18:08 JST

AI による概要

5 記事

この日は Google Data Cloud の週次まとめ (8 月 31 日〜9 月 4 日) を軸に、リリースノートと日本語の技術記事が並びました。BigQuery の継続的クエリでステートフル処理がプレビュー提供となり、JOIN や集計、ウィンドウ関数をストリーミングクエリの中で直接使えるようになりました。30 分平均のような時間をまたいだ指標を計算できるため、下流のアプリケーションや AI エージェントへ渡す信号を格段に豊かにできます。Managed Service for Kafka には合成データ生成ツールが一般提供で加わり、クライアントアプリの書き換えや VM の用意なしに、3 クリックで 2 分以内にモックデータをクラスタへ流し始められます。Dataflow ではパイプラインの更新が速く柔軟になり、既存のインプレース更新に加えて停止と置き換えによる更新ができるようになりました。リリースノートでは Cloud SQL for SQL Server が書き込みエンドポイントでの接続に対応し、Cloud SQL Auth Proxy や言語コネクタに書き込みエンドポイントの DNS 名を設定しておくと、レプリカのフェイルオーバーやスイッチオーバーの際に新しいプライマリへ自動的にリダイレクトされます。課金面では、Gemini Code Assist のサブスクリプションを持たない請求先アカウントは、Google Cloud コンソールから新規に購入できなくなりました。既にサブスクリプションがあるアカウントは影響を受けません。新規に必要な場合は営業への問い合わせとなり、代替の AI 開発ツールとしては Gemini Enterprise のサブスクリプションや Gemini Enterprise Agent Platform から使える Antigravity が案内されています。日本語ブログでは、分散 Ray クラスタに gVisor サンドボックスを導入する Anyscale との協業による試験運用版ライブラリが紹介されました。強化学習の事後学習で Ray が標準のランタイムとして定着するなか、動的なロールアウトやコード生成、マルチターンのツール操作を安全に実行するための隔離環境を大規模に扱う課題に応えるもので、新しい抽象を持ち込まずに各サンドボックスを Ray アクターとして表現し、Ray 2.58 以降では使い慣れた API とパターンのまま管理できます。あわせて、Google DeepMind の研究「Intelligent AI Delegation」を踏まえ、検証できる単位へ仕事を分解する「コントラクトファーストの分解」など 4 つの原則からエージェントの委任を設計する記事と、API キーの流出や AI Studio から Gemini Enterprise Agent Platform への移行、プロジェクトごとの割り当てによる HTTP 429 といったつまずきを避けるために、スタートアップが本番移行前に答えておくべき 10 の質問が公開されています。

主要トピック

  • ストリーミング: BigQuery の継続的クエリがステートフル処理にプレビュー対応し、JOIN・集計・ウィンドウ関数を利用可能に

  • Kafka: Managed Service for Kafka の合成データ生成ツールが GA、3 クリック・2 分以内でクラスタへデータを流せる

  • データ処理: Dataflow のパイプライン更新が停止と置き換えに対応し、並列パイプラインのオプションで移行を高速化

  • 可用性: Cloud SQL for SQL Server が書き込みエンドポイントに対応し、フェイルオーバー時に新プライマリへ自動リダイレクト

  • 課金変更: Gemini Code Assist の新規サブスクリプションがコンソールから購入不可に (既存契約は影響なし、代替は Antigravity)

  • 分離実行: 分散 Ray クラスタに gVisor サンドボックスを Ray アクターとして導入 (Ray 2.58 以降、Anyscale との協業)

  • エージェント設計: DeepMind の研究を踏まえた「コントラクトファーストの分解」など委任の 4 原則

  • スタートアップ: AI プロトタイプを本番へ移す前に答えておくべき 10 の質問 (オンボーディング・スケール・管理)

AI (Claude Opus 5) が生成 · 2026-09-05 22:49:04 JST

Google Cloud Release Notes

September 04, 2026

詳細を表示

Cloud SQL for SQL Server

Feature

Cloud SQL for SQL Server now supports connecting to instances with write endpoints using the Cloud SQL Auth Proxy or Cloud SQL language connectors. When you configure the proxy or a language connector with a write endpoint DNS name, connections are redirected automatically to the new primary instance during replica failover or switchover.

For more information, see Connect to an instance using a write endpoint.

Gemini

Announcement

New subscriptions for Gemini Code Assist can no longer be purchased through the Google Cloud console using billing accounts that don't have an active Gemini Code Assist subscription. Billing accounts that currently have an active Gemini Code Assist subscription are unaffected.

For billing accounts that don't have an active Gemini Code Assist subscription, you can obtain a new Gemini Code Assist subscription by contacting Google Cloud sales. For alternative AI developer tools, use Antigravity, which is available through eligible Gemini Enterprise subscriptions and through Gemini Enterprise Agent Platform.

Announcement

New subscriptions for Gemini Code Assist can no longer be purchased through the Google Cloud console using billing accounts that don't have an active Gemini Code Assist subscription. Billing accounts that currently have an active Gemini Code Assist subscription are unaffected.

For billing accounts that don't have an active Gemini Code Assist subscription, you can obtain a new Gemini Code Assist subscription by contacting Google Cloud sales. For alternative AI developer tools, use Antigravity, which is available through eligible Gemini Enterprise subscriptions and through Gemini Enterprise Agent Platform.

Google Cloud Blog

What’s new with Google Data Cloud

詳細を表示

August 31 - September 4

  • Stateful processing is available in BigQuery continuous queries in Preview
    Stateful operations significantly expand what’s possible with BigQuery continuous queries. This feature allows users to leverage functions like JOINs, aggregations, and windowing functions directly in their streaming queries. Now you can calculate metrics over time (for example, a 30-minute average) to power your downstream applications and AI agents with much richer, real-time signals.

    Try out our feature here and share your feedback with bq-continuous-queries-feedback@google.com!

  • Synthetic data generator tool is available for Managed Service for Kafka
    You’ve launched your first Kafka cluster. Now what? The next thing to do is to produce some data to the cluster, but that involves modifying a client application somewhere or spinning up a virtual machine. The synthetic data generator tool, now generally available, can start sending mock data to your cluster in 3 clicks, and will get data streaming into your cluster in less than two minutes. The perfect utility for those moments you just want to test your cluster and new features. Try our quickstart today!

  • Dataflow pipeline updates are faster & more flexible
    Dataflow pipeline updates can now stop-and-replace pipelines, a major addition to the existing in-place-update feature. The new parallel pipeline option accelerates the migration between the old & new pipeline, resulting in reduced disruption to your business. You can also set a timeout on drains that prevents runaway costs for your pipeliness in the event of stuck processing. This feature is generally available. Try it here!

July 6 - July 10

  • New Lakehouse managed tables now in preview
    Lakehouse tables for Apache Iceberg are now in preview and available in the console. By using Google-managed Apache Iceberg tables in Lakehouse, you can eliminate the overhead of maintaining duplicate data pipelines and complex synchronization logic between BigQuery and open-source engines. This unified table format delivers native, multi-engine read and write interoperability, allowing you to run concurrent DML/DDL operations across diverse analytics tools on a single, shared storage layer.  Built-in automated table management handles painful background optimization tasks like compaction and partition tuning, freeing up your team to focus on building rather than managing storage maintenance.

June 1 - June 5

  • Beyond the Query: Powering AI Agents with Bigtable, Firestore & Memorystore
    Discover the latest advancements in Google Cloud's NoSQL Database portfolio, including Bigtable, Firestore, and Memorystore. This series is designed for a broad audience: whether you are exploring these databases for the first time or are an existing user looking to leverage the new capabilities announced at Next '26.

    Register here to secure your spot!

  • Cloud Engineer's AI Toolkit Workshops: Solve data-driven challenges with BigQuery, AlloyDB, Gemini and more. Hosted by Google Cloud Labs, this highly technical event is built specifically for Platform Engineers, SREs, and cloud infrastructure teams ready to bridge the gap between AI prototypes and production-grade deployments. Look out for more locations coming soon

    Toronto - June 25 (Data Cloud) | RSVP Here
    Chicago - June 30 (Data Cloud) | RSVP Here

  • Start a 10-day Bigtable free trial with a 1 node SSD cluster and up to 500GB of storage capacity. With no credit card required to start, you can easily ingest workloads and manage workloads that require low-latency, high-throughput, and predictable access. Plus, new Google Cloud customers get $300 in free credits on signup.

May 11 - May 15

  • Managed Service for Apache Airflow has launched a wave of new features, including the general availability of Airflow 3.1, AI-powered agentic troubleshooting, a new managed Airflow MCP Server for custom agent integration, and declarative YAML-based orchestration pipelines—discover all the details in the full blog post.

April 20 - April 24

  • Google-built ODBC Driver for BigQuery is now available in Preview
    We are excited to announce the launch of the new, Google-built ODBC driver for BigQuery. This new open-source driver provides a direct, high-performance connection for applications to BigQuery and is developed entirely in-house by Google. Download a new driver and connect your application to BigQuery.

April 13 - April 17

  • We announced we are reintroducing Data Studio to play a significant role in the AI era, expanding from data visualizations and reports to host BigQuery conversational agents and data apps built in Colab notebooks.
  • We announced BigQuery Graph is now available in preview, offering an easy-to-use, highly scalable graph analytics solution, empowering data professionals to model, analyze and visualize massive-scale relationships in an entirely new way.

April 6 - April 10

March 23 - March 27

  • We showed you how you can scale your reads with Cloud SQL autoscaling read pools. This feature allows you to provision multiple read replicas that are accessible via a single read endpoint and to dynamically adjust your read capability based on real-time application needs. 
  • Our customers are leveraging the full power of Conversational Analytics and Looker to drive major business and technical breakthroughs in the AI era. Companies like Telenor, Pet Circle, Fluent Commerce, Lighthouse Intelligence, Wego, and ROLLER are turning data into insights and actions, grounded by Looker’s semantic layer.

March 16 - March 20

February 23 - February 27

February 16 - February 20

  • Our customers are leveraging the full power of Looker to drive major business and technical breakthroughs. Companies like Arrive, Audika, Carousell, Framebridge, GumGum, Intel, Overdose Digital, Ocean Network Express, Subskribe and Promevo are leveraging Looker’s newest AI-driven capabilities, including Conversational Analytics, to transform data to insights and actions, and empower their entire organization with a single source of truth, powered by Looker’s semantic layer.

February 2 - February 6

  • Join us on March 4 for our webinar, Win Your AI Strategy with Cloud SQL Enterprise Plus, to learn how to power your generative AI workloads with 3x higher performance and 99.99% availability. Register today to discover how to build a scalable, enterprise-grade foundation for your most demanding AI applications.

January 26 - January 30

January 19 - January 23

  • We have fundamentally reimagined Firestore with pipeline operations for Enterprise edition. Experience a powerful new engine featuring over a hundred new query features, index-less queries, new index types, and observability tooling to improve query performance. Seamlessly migrate using built-in tools and leverage Firestore’s existing differentiated serverless foundation, virtually unlimited scale, and industry-leading SLA. Join a community of 600K developers to craft expressive applications that maximize the benefits of rich queryability, real-time listen queries, robust offline caching, and cutting-edge AI-assistive coding integrations.

  • Introducing Google Cloud SQL on MSSQLTips: We are highlighting a new technical guide published on MSSQLTips titled "Introducing Google Cloud SQL." This article serves as an essential resource for SQL Server administrators and developers exploring Google Cloud's fully managed database service. It provides a detailed overview of Cloud SQL capabilities, including high availability, security integration, and the seamless transition of on-premises SQL Server workloads to the cloud, making it an ideal resource for those planning their migration strategy.

  • We are excited to announce the Public Preview of Microsoft Entra ID (formerly Azure Active Directory) integration with Cloud SQL for SQL Server. Designed to tackle the challenge of identity sprawl in multi-cloud environments, this integration allows organizations to govern database access using their existing Microsoft identity infrastructure. Key benefits include centralized identity management, enhanced security features like Multi-Factor Authentication (MFA), and simplified user administration through direct group mapping. This feature is available for SQL Server 2022 and supports both public and private IP configurations.

January 12 - January 16

  • Google-built JDBC Driver for BigQuery is now available in Preview
    We are excited to announce the launch of the new, Google-built JDBC driver for BigQuery. This new open-source driver provides a direct, high-performance connection for Java applications to BigQuery and is developed entirely in-house by Google. Download a new driver and connect your Java application to BigQuery.
  • Troubleshoot Airflow tasks instantly with Gemini Cloud Assist investigations: Cloud Composer just got smarter. We are excited to announce that Gemini Cloud Assist investigations are now available directly within Cloud Composer 3. Instead of manually sifting through raw logs, you can now simply click "Investigate" on a failed Airflow task. Gemini analyzes logs and task metadata to identify failure patterns—such as resource exhaustion or timeouts—and provides actionable recommendations driven by Gemini Cloud Assist to resolve the issue. This integration shifts the debugging experience from manual toil to automated root cause analysis, significantly reducing the time required to restore your pipelines. Learn more about AI-assisted troubleshooting.

Related Article

    <div class="uni-related-article-tout__content-wrapper">
      <div class="uni-related-article-tout__image-wrapper">
        <div class="uni-related-article-tout__image"></div>
      </div>
      <div class="uni-related-article-tout__content">
        <h4 class="uni-related-article-tout__header h-has-bottom-margin">What’s new with Google Data Cloud - 2025</h4>
        <p class="uni-related-article-tout__body">Recent product news and updates from our data analytics, database and business intelligence teams.</p>
        <div class="cta module-cta h-c-copy  uni-related-article-tout__cta muted">
          <span class="nowrap">Read Article
            <svg class="icon h-c-icon" xmlns="http://www.w3.org/2000/svg">
              <use xlink:href="#mi-arrow-forward" xmlns:xlink="http://www.w3.org/1999/xlink"></use>
            </svg>
          </span>
        </div>
      </div>
    </div>
  </div>
</a>

Google Cloud Japan Blog

エージェントがより適切に委任を行う方法
詳細を表示

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

組織行動論の授業では、効果的な委任が経験豊富なリーダーにとって最も重要なスキルの一つであると生徒は学びます。有意義な作業を完了するには、プロジェクトを管理可能なタスクに細分化し、そのタスクをチームのスキルにマッピングして、適切な担当者に割り当てることから始めて、慎重に調整する必要があります。

Google Cloud では、エンタープライズ ワークフローにおける AI エージェントの構築とデプロイに関しても、同様の教訓を得ています。これらのワークフローには、複雑なタスクを分割して実行できるマルチエージェント システムが最適です。そのためには、AI エージェントが優れた委任者になる必要があります。

その方法を学ぶために、Google DeepMind の研究に目を向けました。最近の研究「Intelligent AI Delegation」では、委任自体にインテリジェンス、具体的には、適応型の交渉、正式なコントラクトに基づく調整、セキュリティ ガードレールがどのように関わっているかが実証されています。

この研究により、コミュニケーション、タスクの共有、設定された目標に向けた調整が可能な AI エージェントを構築するお客様に新たな機会がもたらされます。今回は、その研究から生まれた 4 つの原則と、それらを独自のワークフローに適用する方法をご紹介します。

原則 1: 委任された作業を検証する

AI にタスクを委任することを許可する場合、単に作業を任意に割り当てる以上のことが AI に求められます。エージェントは、作業を、確実に検証できるタスクにインテリジェントに分割する必要があります。Google の研究では、これを「コントラクト ファーストの分解」と呼んでいます。

人間が委任を行う場合と同様に、これには慎重な検討が必要です。人間の場合、リーダーがチームの強みを理解し、完了前に作業を確認することなどが考えられます。AI にも同様の学習曲線があります。オーケストレーション AI（マルチエージェント システムの最上位に位置するマネージャー）は、作業を最適に分解して割り当てる方法について複数の計画を検討し、サブ目標を、監視および検証できるほど単純になるまで、より小さなチャンクに分解し続けます。理想的には、すべてを確実に評価できる計画を立てる必要があります。しかし、実際には、これを常に実現できるとは限りません。

場合によっては、期待どおりに作業が完了したかどうかを主観的に評価する必要があるかもしれません。このようなコンポーネントを特定することは、問題にはならず、むしろ、人間の時間をどこに費やすのが最適か、エージェント システムの監視に人間の専門家の判断をどのように関与させるのが最適かを判断するのに役立ちます。

原則 2: 費用を賢く管理する

この研究フレームワークは、お客様からよく寄せられる「この特定のタスクは、より小さく、より安価なモデルで処理できるか？」という質問に答えるのに役立ちます。企業は費用にますます注意を払うようになっており、それは当然のことです。

パフォーマンスと予算の適切なバランスを見つけるのは難しいことです。給与計算のような複雑な問題を軽量モデルに任せても、期待する結果を得るだけの能力がない可能性があります。また、スプレッドシートの形式の再設定のような単純なタスクを強力な推論モデルにルーティングすることは不必要です。

研究によると、委任についてインテリジェントなエージェントは、このようなシナリオを認識し、各タスクに適したツールまたはエンドポイントを選び、最小限のコストで望ましい結果と最大限の信頼性を実現することを学習します。API ゲートウェイ内のモデル ルーティング機能の使用は、クライアントサイド プロキシの使用の代替手段（LiteLLM など）に加えて、お客様の間で人気が高まっています。

モデル ルーティングについて詳しくは、こちらをご覧ください。

原則 3: 機密データを尊重する

多くのワークフローは非公開の機密データを処理するため、AI エージェントはそれらの境界と権限を尊重する必要があります。たとえば、給与データ用のオーケストレーター エージェントをデプロイする場合、そのエージェントが一連の情報全体をサブエージェントに渡すことがあってはなりません。これが発生すると、セキュリティが損なわれるだけでなく、エージェントのコンテキスト ウィンドウが肥大化し、パフォーマンスが低下します。エージェントには、特定の任務を完了するために必要な最小限の権限のみを付与する必要があります。

難しいのは、最初の原則に従って、非公開の情報を明らかにすることなく、作業が確実に完了したことを証明する必要がある場合です。研究によると、ゼロ知識証明などの手法による高度な暗号化が、この問題の解決に役立つ可能性があります。ゼロ知識証明により、一方の AI エージェントが、データ自体を明らかにすることなく、計画された計算が正しく実行されたことをもう一方の AI エージェントに証明できます。たとえば、機密性の高いデータセットの分析を任されたエージェントは、結果の特定のプロパティを証明する簡潔で非インタラクティブな知識の論証を生成できます。これにより、委任者は証明の有効性を即座に検証できます。

原則 4: 無関心圏に注意する

無関心圏とは、アメリカの企業経営者であるチェスター バーナードが 1938 年に著した『The Function of the Executive（経営者の役割）』で用いた造語であり、従業員が疑問を抱くことなくタスクを受け入れる心理的スペースのことを意味します。通常、このタスクは従業員の業務範囲内にあるため、無意識のうちに受け入れてしまいます。たとえば、営業担当者が、重要な顧客との今後のプレゼンテーションに参加するようマネージャーから指示された場合、おそらく反論したり、深く考えたりすることはないでしょう。

研究で示されているように、現在の AI システムは、トレーニング後の安全フィルタとシステム指示によって定義されています。リクエストが重大な違反を引き起こさない限り、モデルはリクエストに従います。しかし、台頭しつつあるエージェント型ウェブを考慮すると、リクエストに従うというこの行動は実際にはシステム上のリスクを生み出す可能性があります。研究で言及されているように、「委任チェーンが長くなると（? → ? → ?）、広範な無関心圏により、微妙な意図の不一致やコンテキストに依存する危害が下流に急速に伝播する可能性があり、各エージェントは責任あるアクターではなく、無思考のルーターとして機能します。」

これは重大な影響を及ぼします。なぜなら、インテリジェントな委任には「動的な認知的摩擦」が必要であることを意味するためです。つまり、エージェントに提供される情報を検証して、その情報が正確で、関連性があり、管理されており、効率的であることを確認する必要があるということです。

このようにして、エージェントは、リクエストがあまりにも曖昧なために、無関心圏から脱却することを正当化し、委任者に異議を唱えたり、人間の検証を要求したりする必要がある場合に、それを認識できます。同様に、人間の参加と監督は、ある程度の認知的摩擦と積極的なエンゲージメントを前提としていますが、システムのユーザーに過度の負担をかけないように、慎重に管理する必要があります。人間の時間は貴重であり、必要な場合にのみ人間の介入を要求する必要があります。

今後の展望

Google Cloud の長期的な目標は、エージェントを組織に自然かつ効率的に統合することです。これは、人間の専門家との間で委任を行い、境界を尊重することを意味します。この組み合わせが、個々のエージェントが対応できる枠を超えたビジネス価値をもたらすと考えています。

エージェント型ウェブをナビゲートする準備ができたら、arXiv で Google DeepMind のレポート「Intelligent AI Delegation」をお読みください。

注: この投稿に協力してくれた Google DeepMind の Matija Franklin と Simon Osindero、Google Cloud の Vishal Agarwal と Andrea Morange に感謝します。

- Google DeepMind、リサーチ サイエンティスト Nenad Tomasev

- Google Cloud、応用 AI ブラックベルト Reshu Yadav

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

詳細を表示

※この投稿は米国時間 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 つのフェーズに分類しています。

  1. オンボーディング（独自のプロジェクトと ID を適切に設定する）

  2. スケール（費用をかけずにスループットを高める）

  3. 管理（費用、キー、エージェントの暴走を防ぐ）。

これらの 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 0x7f3dbb75fdc0>)])]>

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

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

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

  1. コンソールを操作する代わりに、独自の設計思想が反映されたプロジェクト テンプレートを使用する。クラウド設定のチェックリストと Google Cloud アーキテクチャ フレームワークを使用すると、本番環境レベルのフォルダ階層（prod / non-prod / dev）、一元的なロギングとモニタリングのプロジェクト、Security Command Center の有効化、ベースライン組織ポリシーが提供されるため、これらをゼロから設計する必要はありません。

  2. 実際に使用する API を一度有効にする必要なときにプロジェクトごとに実行しなくても済むように、バッチ処理します。請求先のリンクの手順は省略できません。これから有効にしようとしている有料 API は、請求先アカウントが関連付けられていないプロジェクトでは有効にできないため、まずはその設定を行います。

  3. 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 0x7f3dbb75f100>)])]>

出典: 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 0x7f3dbb75f3a0>)])]>
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 0x7f3dbb75f280>)])]>

最後に、今後に備えて、そのサービス アカウントに、ワークロードが実際に必要とする最小限の 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 0x7f3dbb75fd90>)])]>

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

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

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

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

  1. プロジェクトの階層の動的共有割り当て（DSQ）の上限に達した場合。DSQ は、プロジェクトの履歴に基づいてサイズが設定される共有プールです。プラットフォーム全体での不正使用を防ぐため、新しいプロジェクトは設計上、控えめな上限から始まります。

  2. 世界的に需要が急増しているときに、グローバル エンドポイントを呼び出し、共有容量をめぐって世界中のトラフィックと競合している場合。

対策としてすぐ思いつくのは、割り当て増加のチケットを送信することです。必要であればそうすることもできますが、通常は 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 0x7f3dbb75f1c0>)])]>

適切な再試行とバックオフを追加する。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 0x7f3dbb75ff40>)])]>

この状況をどのように予測しますか？できれば、ユーザーから報告を受ける形ではなく。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 0x7f3dcecbd760>)])]>

出典: 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 は予約済みの容量です。使用するかどうかにかかわらず料金を支払う必要があり、ベースラインが単なる願望ではなく、真に予測可能になった場合にのみ、元が取れるようになります。

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

  1. Standard PayGo の第 1～4 週。これを使用して、実際のリクエストの形態（p50 と p99 での 1 分あたりのトークン数、リクエストのバースト、バッチ処理可能とリアルタイム処理の内訳）を測定します。

  2. 初めて 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 0x7f3dbb7e5bb0>)])]>

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

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

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

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

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

  1. 利用額上限の予算（プレビュー）。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 0x7f3dbb7e5b50>)])]>

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

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

  1. 予算の範囲を制限する: --filter-projects を使用しない場合、予算は請求先アカウント全体に適用されます。いずれかのプロジェクトで急増が発生すると、すべてのキルスイッチがトリガーされます。

  2. ローカルにデプロイする: 予算通知では、影響を受けるプロジェクトが指定されていません。キルスイッチが目的のプロジェクトにのみ影響するように、保護するプロジェクト（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 0x7f3dbb7e5a90>)])]>
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 0x7f3dccf6f130>)])]>

次に、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 0x7f3dccf6f4f0>)])]>

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

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

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

いわば宿題として

  1. リポジトリ、ノートブック、本番環境ランタイムで、未加工の API キーを監査します。そこにあるべきでないキーをローテーションします。

  2. 同期レスポンスを必要としないワークロードは、Batch API に移行します。

  3. モデルのオブザーバビリティ ダッシュボードを有効にして、容量エラーに関するアラートを 1 つ設定し、次の 429 エラーが顧客より前に自分に届くようにします。

  4. プロジェクトの利用額上限を設定し、50% と 80% のアラートに注意します。使用量が予算の 100% を超えると、手動で解除するまで、Google はサービスを一時停止します。

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

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

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

分散 Ray クラスタに gVisor サンドボックスを導入

詳細を表示

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

強化学習（RL）のエコシステムでは、複雑なトレーニング後のワークフローを支える統合コンピューティング ランタイムとして、Ray の採用が急速に進んでいます。Google Cloud のお客様も、マルチモーダル データ パイプラインから最先端の RL まで、さまざまなワークロードに Ray を活用しています。しかし、エージェント モデルと推論モデルが進化するにつれて、重大な課題が浮き彫りになってきています。それは、動的なロールアウト、コード生成、マルチターンのツール操作を安全に実行するために、安全で分離されたサンドボックスを大規模にオーケストレートすることです。このたび、Anyscale とのパートナーシップによる Ray の試験運用版ライブラリを導入いたします。このライブラリは、Google で開発中のエージェント型 AI テクノロジーを活用して、ネイティブで高性能なサンドボックス環境を分散 Ray クラスタに直接提供するものです。

Ray プリミティブとしてのサンドボックス

Ray は、トレーニング後のワークロードをオーケストレートするための標準的なランタイムとして定着しています。veRL、NeMo-RL、SLIME、MILES、SkyRL などのフレームワークは、すでに Ray を使用して分散トレーナー、推論エンジン、ロールアウト ワーカーなどのコンポーネントを調整しています。

Ray サンドボックスの設計において重要な目標としたのは、隔離された実行のために新たな抽象化を導入するのではなく、既存の Ray プログラミング モデルに自然に馴染む形にすることです。サンドボックスは、Ray が管理する他のリソースと共通する特性を多く備えています。具体的には、マシンへの配置や、リソースの割り当て、作成と破棄、障害からの復旧、周囲のワークロードに応じたスケーリングなど、他のリソースと同様の管理が求められます。こうした背景から、各ハイレベル サンドボックスを Ray アクターとして表現する手法を採用しました。

<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="image1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_SrQumpQ.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

Ray スケジューラは、どのノードでサンドボックスを実行するかを決定し、対応する CPU とメモリリソースを予約します。サンドボックス アクターが自身のライフサイクルを管理する一方で、gVisor はそのノード上で隔離された実行環境を提供します。

Ray 2.58 以降では、フレームワークの作成者と研究者は、他のワークロードで使い慣れた Ray API やパターンをそのまま使用して、サンドボックス環境を管理できます。以下にその例を示します。

code_block
<ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental import sandbox\r\n\r\nray.init()\r\n# Create a gVisor sandbox environment and return an actor handle for a proxy actor\r\nsb = sandbox.create(\r\n cpu=1.0,\r\n memory="512Mi",\r\n image="python:3.12-slim"\r\n)\r\n# Execute code inside the sandbox\r\nresult = ray.get(sb.exec.remote("python -c \'import sys; print(sys.version)\'"))\r\nprint(result.stdout)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3dbb55adc0>)])]>

これにより、OCI 互換イメージから gVisor サンドボックスが作成され、Ray アクターのハンドルが返されます。exec の呼び出しは通常の Ray アクター呼び出しと同じであるため、サンドボックスはクラスタ内のどこにでも配置できます。作成されたアクターは、オペレーションを gVisor に転送するプロキシです。

サンドボックス API は、エージェント型ワークロードに必要な基本的なライフサイクル管理に対応しています。

  • OCI コンテナ イメージから環境を作成する

  • CPU とメモリの上限を設定する

  • 環境変数、作業ディレクトリ、ネットワーキングを構成する

  • コマンドを実行する

  • ファイルの読み取り、書き込み、アップロード、ダウンロードを行う

  • サンドボックスの状態を検査する

  • 環境を終了または削除する

さらに詳細な制御が必要な場合は、SandboxRuntime を使用してローカルの gVisor サンドボックスを直接操作できます。これにより、gVisor に引き渡す前の OCI 仕様をユーザー側で編集できるようになります。この API を使用してアクター内にローカル サンドボックスのプールを構築する方法を以下に示します。

code_block
<ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental.sandbox.runtime import SandboxRuntime\r\n\r\n@ray.remote\r\nclass SandboxPool:\r\n def __init__(self, size: int = 3, image: str = "python:3.10-slim"):\r\n self.runtime = SandboxRuntime()\r\n self.sandboxes = [\r\n self.runtime.create(image=image, memory="512Mi")\r\n for _ in range(size)\r\n ]\r\n\r\n def run_command(self, index: int, command: str):\r\n return self.runtime.exec(self.sandboxes[index], command)\r\n\r\n def close(self):\r\n for sb_id in self.sandboxes:\r\n self.runtime.delete(sb_id)\r\n\r\n# Deploy an actor managing a pool of local sandboxes\r\npool = SandboxPool.remote(size=3)\r\nresult = ray.get(pool.run_command.remote(0, "python3 -c \'print(\\"Hello from pool!\\")\'"))\r\nprint(result.stdout)\r\nray.get(pool.close.remote())'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3dbb55abb0>)])]>

gVisor を選ぶ理由

モデルが生成したコードを実行する際は、その環境内のコードを「信頼できないもの」として扱う必要があります。Ray サンドボックスは、Google のオープンソース アプリケーション カーネルである gVisor を初期サンドボックス ランタイムとして使用します。gVisor は、Linux システムコール インターフェースの大部分をユーザー空間に実装し、ワークロードとホストカーネルの間に、さらなる分離境界を追加します。OCI 互換で、標準のコンテナ イメージをそのまま利用でき、Docker デーモンやホスト Docker ソケットをサンドボックスに公開する必要もありません。

この組み合わせは、エージェント型ワークロードに非常に適しています。環境を動的に作成できるほど軽量に保ちながら、生成されたコードを通常のコンテナで直接実行するよりも強力な隔離環境を実現できるからです。gVisor は 1 秒未満の高速起動と低メモリ オーバーヘッドを両立しているため、サンドボックスを粒度の細かい分散リソースとして柔軟に活用できます。

Ray の今後のバージョンでは、Agent Substrate や Kata Containers といった他のサンドボックス ランタイムにもサポートを拡大していく予定です。

GKE で Ray サンドボックスを試す

Ray サンドボックスの詳細は、Ray のドキュメントでご確認いただけます。GKE でこれらのサンドボックス機能を試すには、Ray サンドボックスのユーザーガイドをご参照ください。フィードバックやアイデアがございましたら、GitHub の issue でディスカッションにぜひご参加ください。強化学習における Ray の未来を一緒に考えていきましょう。

- Google、スタッフ ソフトウェア エンジニア、 Andrew Sy Kim

- Anyscale、最高技術責任者、Philipp Moritz 氏

前日
Archive
翌日