Back to Archive

GCP News - 2026-10-07

2026-10-07
最終更新: 2026-10-08 07:44:38 JST

AI による概要

8 記事

この日は 8 件で、エージェント時代のデータベースアーキテクチャと、レイクハウスのカタログ、そして国内イベントの案内が中心でした。分析では、Spanner が Lakehouse runtime catalog を支える仕組みが解説されました。レイクハウスアーキテクチャへ移行する顧客は、互換エンジンをまたいだ共有のデータ資産を作るために Apache Iceberg のような開かれたフォーマットへ標準化しつつあります。レイクハウスの重要な構成要素がカタログで、Apache Iceberg の世界では通常 Iceberg REST Catalog を指します。カタログはテーブルのポインタを保ち、アトミックなコミットを扱い、テーブルの場所についての単一の真実の源として機能します。大企業がレイクハウスへ移行するにつれ、高いスケーラビリティと可用性を備えたマネージドなカタログがアーキテクチャの一部として必要だと気づき始めており、エージェントによってクエリが増えるほどその重要性は増します。エージェントから繰り返し飛んでくる大量の小さなクエリを支えるには、巨大な規模でアトミック性・一貫性・可用性・同時実行性を提供するマネージドなカタログの上に構築する必要がある、という問題意識です。Google Cloud のサーバーレスな Lakehouse runtime catalog は、事実上無限のスケールを持つ常時稼働のデータベースである Spanner を基盤に、開かれた Apache Iceberg REST catalog の仕様を満たす形で作られており、エージェントの時代に必要な高くスケールする可用性の高い土台になります。エージェントのデータアクセスでは、MCP Toolbox Java SDK がバージョン 1.0 に到達しました。世界で最も広く採用されているエンタープライズのエコシステムの 1 つに、型安全なエージェントのオーケストレーションをもたらすリリースです。Java の成熟したアーキテクチャは厳しい要求に応えるために作られており、本番でミッションクリティカルな AI エージェントを安全にスケールさせるために必要な高い同時実行性、厳密なトランザクション整合性、堅牢な状態管理を提供します。背景には、N 種類の AI モデルと M 個のエンタープライズデータソースがあると N × M 本の独自の接続を作って守って保守しなければならない、統合のボトルネックがあります。統合レイヤーが統一されていないために場当たり的なパイプラインの寄せ集めに頼ることになり、エージェント型のアーキテクチャのスケールは早々に持続不能になって、機微なエンタープライズデータベースを深刻なセキュリティ上の脆弱性やばらばらのアクセス制御、膨大な保守の負担にさらします。Model Context Protocol (MCP) は AI オーケステーションにおける「USB Type-C」のような普遍的なインターフェイスとして振る舞い、モデルとデータソースを切り離すことでこの問題を解決します。モデルやデータベースごとに独自の統合コードを書く代わりに、標準化された 1 つのプロトコルに対して書けばよく、MCP に準拠したエージェントはどの MCP 対応システムとも安全にすぐやり取りできます。データベースでは、AlloyDB がエージェント向け PostgreSQL をプレビュー提供しました。ミッションクリティカルな運用データベースは性能の低下が許されませんが、従来のアーキテクチャではわずか数個のエージェントが高密度の推論ループを回すだけで、予測できないクエリのバーストによって簡単に過負荷になります。AlloyDB はサンドボックス化されたデータベースインスタンスを数秒でプロビジョニングしてスケールさせることで突発的なクエリの急増に対応し、ワークロードを完全に分離します。インスタンスはエージェントが終了すると自動でスピンダウンするため、数個でも数百万個でも費用対効果よく動かせます。秒単位で同期された本番の最新データに読み取り専用でアクセスできる数千のサーバーレスなインスタンスへ PostgreSQL をスケールさせる設計で、これらは本番ワークロードが使うプライマリ・スタンバイ・リードレプリカから常時完全に分離されています。各インスタンスは Google のエクサバイト規模の分散ストレージである Colossus を基盤とする統合ストレージ層のリアルタイムデータにアクセスし、1 ミリ秒未満の I/O とテラビット/秒の集約スキャンスループット、秒間 300 万以上のクエリに対応します。完全な AlloyDB PostgreSQL エンジンを備え、すべてのインデックス、SQL の全機能、ベクトル検索・全文検索・空間検索を使えるほか、複雑な ETL を組まずに BigQuery と Spark でレイクハウス分析も行えます。タスクが終わるとすぐにゼロへスケールダウンするため、課金はアクティブな推論ループに対してのみ発生します。静的パスワードに代わる IAM 認証、VPC Service Controls によるトラフィック分離、顧客管理の暗号化と監査も備えます。あわせて、エージェントの時代に求められるデータベースアーキテクチャの考え方も示されました。Exadata はクエリを下部のスケールアウトストレージ層へオフロードし、Azure SQL Hyperscale は共有ブロックサーバーで数十のリードレプリカへスケールアウトし、Aurora はログの適用処理を分散ストレージノードへオフロードしてきましたが、いずれもスケール・レイテンシー・分離という 3 つの特性のうち少なくとも 1 つ、場合によっては 2 つの制約を本質的に抱えています。エージェントのワークロードは動的に生成されて事前に検証できないため、ミッションクリティカルなシステムからの分離が事業継続に不可欠であり、同時に単一のデータベースに対して数秒で 1,000 のコンピュートノードを要求して 1 分以内に終えるような、前例のない弾力的なスケーリングも求められます。Google はそのための原則として、設計レベルの物理的な分離とリアルタイムなデータアクセス、1 ミリ秒未満のベースライン I/O、そして弾力的なスケーリングの 3 つすべてを満たす必要があると述べています。セキュリティでは、Google Cloud のパートナーが Gemini Enterprise を活用した新しいセキュリティエージェントと AI 防御機能を提供し始めたことが紹介されました。企業のサイバー防御は ID・ネットワーク・エンドポイント・データ・クラウド・アプリケーションの各レイヤーにまたがり、しばしば 12 種類以上のプロダクトに分散してそれぞれが独自のコンテキストを持っています。Gemini Enterprise のエコシステムでパートナー製のセキュリティサービスのカタログを拡充し、単一の統合インターフェイスから複数ステップのセキュリティワークフローをオーケストレーションできるようになりました。Acalvio の ShadowPlex はネットワークデコイや ID のハニーアカウント、RAG デコイ、ハニートークンの大規模な展開を手作業の構成なしに自動化し、Britive の Emergency Termination Agent は自然言語の 1 つの依頼で侵害された ID を封じ込め (ID の確認、アクティブな特権セッションの一覧、人間の承認を得た上での全セッションの取り消し、ID の無効化、インシデントチケット用の監査コンテキストの収集)、封じ込めまでの平均時間 (MTTC) を大きく短縮します。Check Point の AI Defense Plane は Google Cloud Agent Gateway と Agent Registry と統合され、AI ワークロードの検出、リスクポスチャーの監視、プロンプトインジェクションやデータ漏洩、エージェントの不正な挙動に対するリアルタイムのガードレールを提供します。リリースノートでは、Apigee hybrid のパッチリリース v1.14.9 が公開されました。JWKS の uriRef を使う VerifyJWT ポリシーが、5 分の JWKS キャッシュ TTL の失効直後の最初のリクエストで ID プロバイダの鍵ローテーション時に steps.jwt.NoMatchingPublicKey を返しうる問題 (キャッシュが失効時に同期的に更新されるようになりました)、Message Processor の送信 HTTP 検証を強化して Kubernetes クラスター内部のホスト名 (*.svc.cluster.local) へのリクエストを遮断することなど、複数の修正が含まれます。国内のイベントでは 2 本の案内が出ました。2026 年 10 月 16 日 (金) に Google 渋谷オフィスとオンラインで開催される AI-Ready Infra & DB Summit '26 は、「AI が使う基盤、AI で作る基盤」を基調講演のテーマに、ロッテホールディングスとマクロミルが登壇し、GovTech 東京・ロッテ・マクロミル・スタメンの 4 社が基盤づくりと移行の実例を紹介します。Gemini と Skills を使ったクラウド移行、AI によるデータベース移行、クラウドネットワークの見える化といった AI 駆動の移行・運用の手法も解説されます。2026 年 10 月 29 日 (木)・30 日 (金) にベルサール渋谷ガーデンとオンラインで開催される Agentic AI Summit '26 Fall は、Day 1 が Gemini Enterprise を中心とした全社展開の実例 (三菱 UFJ 銀行の基調講演、ソニー・日本テレビ・足立区などのブレイクアウト、第 6 回 AI エージェント事例アワードのピッチコンテスト)、Day 2 がエンジニア向けにエージェントの構築・デプロイ・運用と本番運用のアーキテクチャ設計を扱う構成です。

主要トピック

  • 分析: サーバーレスな Lakehouse runtime catalog を Spanner が支える、Iceberg REST catalog 仕様に沿いエージェント規模の小さな大量クエリに対応

  • エージェント: MCP Toolbox Java SDK が v1.0 に、型安全なエージェントオーケストレーションを Java のエコシステムへ

  • 統合: N × M の独自接続という統合のボトルネックを、MCP という普遍的インターフェイスで解消

  • データベース: AlloyDB がエージェント向け PostgreSQL をプレビュー提供、数千のサーバーレスインスタンスを本番から完全分離し秒間 300 万クエリ超に対応

  • アーキテクチャ: エージェント時代のデータベースに必要な 3 原則 (設計レベルの分離・1 ミリ秒未満の I/O・弾力的スケーリング) を提示

  • セキュリティ: パートナー製セキュリティエージェントが Gemini Enterprise に、Acalvio の ShadowPlex や Britive の緊急封じ込め、Check Point の AI Defense Plane

  • リリースノート: Apigee hybrid v1.14.9、JWKS キャッシュ失効時の VerifyJWT の問題を修正し内部ホスト名への送信を遮断

  • 国内イベント: 10/16 に AI-Ready Infra & DB Summit '26、10/29・30 に Agentic AI Summit '26 Fall を開催

AI (Claude Opus 5) が生成 · 2026-10-08 08:23:00 JST

Google Cloud Release Notes

October 07, 2026

詳細を表示

Apigee hybrid

Announcement

v1.14.9

On October 7, 2026 we released an updated version of the Apigee hybrid software, v1.14.9.

Fixed

Fixed in this release

Bug ID Description
565072374 Fixed an issue where VerifyJWT policies using a JWKS uriRef could return steps.jwt.NoMatchingPublicKey on the first request after the 5-minute JWKS cache TTL expired when the identity provider rotated keys. The cache now refreshes synchronously upon expiration.
564969400 Fixed an issue where variables initialized from an empty <Value/> element in AssignMessage (AssignVariable) were not treated as empty strings when referenced in message template functions such as replaceAll.
558888960 Fixed an issue in distributed tracing where the target URL was omitted from outbound target request span attributes after a request-flow policy step executed.
554114419 Apigee hybrid now allows policies to modify HTTP/2 request pseudo-headers (:path and :authority) when communicating over HTTP/2.
548763108 Hardened Message Processor outbound HTTP validation to block requests to internal Kubernetes cluster hostnames (*.svc.cluster.local).
513032450 Fixed an issue where apigee-connect-agent control-plane connections could hang for up to 2 hours when silently dropped by a network intermediary by restoring a 15-second TCP keep-alive.

Security

Bug ID Description
N/A Security fixes for apigee-asm-ingress.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-asm-istiod.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-connect-agent.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-fluent-bit.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-hybrid-cassandra-client.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-kube-rbac-proxy.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-mart-server.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-mint-task-scheduler.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-open-telemetry-collector.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-operators.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-prom-prometheus.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-prometheus-adapter.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-runtime.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-synchronizer.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-udca.
This addresses the following vulnerabilities:
N/A Security fixes for apigee-watcher.
This addresses the following vulnerabilities:

Gemini Enterprise Agent Platform

Feature

Anthropic's Claude Haiku 5.5

Claude Haiku 5.5 is available in Model Garden.

Fixed

CodeMender updates (v0.13.0)

This release introduces updates to CodeMender:

  • Consistent finding deduplication: Improved finding deduplication consistency across repeated cm find, --deep, --diff, and --parallel scans.
  • Bug fixes:
    • Fixed an issue where deduplicated findings could appear in cm report --status DISMISSED.
    • Improved local state reliability during concurrent cm find --diff and cm find --deep scans.
    • Updated streaming error handling so non-retryable errors fail immediately instead of retrying.
    • Ensured local session state and logs are saved cleanly when a session is interrupted (Ctrl+C).

For more information, see the CodeMender documentation.

Google Kubernetes Engine

Feature

The microVM sandbox type is now Generally Available (GA) with GKE Sandbox in clusters that run version 1.37.0-gke.4713000 and later. MicroVM sandboxes provide hardware virtualization and isolation for untrusted workloads, AI agent runtimes, and multi-tenant environments. GKE microVM sandboxes use Kata Containers and Cloud Hypervisor to provide this isolation while maintaining a full Linux kernel that includes standard Linux features

For more information, see the GKE Sandbox documentation.

Google Cloud Blog

Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog

詳細を表示

As customers modernize to lakehouse architectures, they are standardizing on open formats such as Apache Iceberg to create a shared data estate across compatible engines. This enables you to build AI-native lakehouses that turn data to semantic knowledge, enable proactive action, and operate at an agentic scale.

One of the key components of a lakehouse is the catalog, and in the Apache Iceberg environment, that usually means the Iceberg REST Catalog. An Apache Iceberg catalog is responsible for maintaining table pointers, handling atomic commits, and serving as the single source of truth for table locations. But as large enterprise organizations modernize to lakehouses, they have begun to realize that they need a highly scalable and available managed catalog as a part of their lakehouse architecture. This becomes even more important as querying scales with agents. To support a large amount of repeated small queries from agents, you will need to build on top of a managed catalog that provides atomicity, consistency, availability and concurrency at massive scale. 

In this blog, we explore the challenges a managed catalog faces in modern cloud environments at agent scale, and show you how Google Cloud’s serverless Lakehouse runtime catalog can help address them. Powered by Spanner, Google Cloud’s always-on database with virtually unlimited scale, and built to meet the open Apache Iceberg REST catalog specification, the Lakehouse runtime catalog is the highly scalable and available foundation you need for the agentic era.

Challenges a managed catalog needs to solve in the Lakehouse

When speaking with data engineers and infrastructure leads running production analytics at scale in a Lakehouse, the following core pain points consistently emerge and need to be solved by a managed catalog: 

Atomic commits and concurrency control: Iceberg guarantees ACID transactions via optimistic concurrency control (OCC). A managed catalog must implement a bulletproof atomic compare-and-swap (CAS) operation to swap the current metadata pointer.

High availability and operational maintenance: Because queries fail immediately if the catalog is down, a managed catalog becomes a critical Tier-1 service.

Scaling the database backing the catalog: Catalog architects typically face a difficult trade-off when choosing a backing database for table metadata and state. Traditional scale-up relational databases provide SQL and ACID transactions, but hit vertical CPU, memory, storage and connection limits under heavy concurrent read/write loads unless manually sharded which incurs a huge operational overhead; while scale-out database systems are either eventually consistent, hard to manage, not enterprise-ready, or all of the above.

Table maintenance coordination: A catalog alone does not optimize data; you must build and operate ancillary pipelines for compaction, snapshot expiration, manifest rewriting, and orphan file cleanup.

Governance and security: A catalog acts as the security gatekeeper. The catalog must implement and maintain:

  • Authentication protocols (e.g., OAuth2 token exchange, IAM federation)

  • Access control down to namespace and table levels

  • Vended storage credentials (e.g., generating short-lived tokens so query engines don't need broad, direct storage credentials)

Lakehouse runtime catalog

To solve these challenges, we built the Lakehouse runtime catalog (GA) with support for Iceberg Rest Catalog. The Lakehouse runtime catalog is a fully serverless, highly available, and unified metadata registry designed from the ground up to support modern open table formats like Apache Iceberg. By natively implementing the Apache Iceberg REST Catalog specification, the Lakehouse runtime catalog decouples metadata discovery from compute engines, helping ensure multiple Iceberg-compatible engines can access a shared data estate and enabling you to take your workloads to production sooner. We’ve helped many customers streamline the migration of their managed catalogs. For example, Etsy migrated its catalog to Lakehouse runtime catalog, joining data in place to accelerate pipeline queries by 60%.

<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="1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/1_bmVFk8w.max-1000x1000.jpg" />
    
    </a>
  
</figure>


  </div>
</div>

This approach offers a number of architectural benefits:

  • Open APIs: Support for Iceberg Rest Catalog enables different teams to use their preferred analytics tools on a single, unified dataset.

  • Multi-engine interoperability: Once registered, tables are immediately discoverable and queryable across Google Cloud Managed Service for Apache Spark, BigQuery, and open-source engines via standard REST interfaces.

  • Read/write interoperability for Iceberg tables: Leverage Iceberg-compatible engines such as BigQuery, Managed Spark to write to Iceberg tables registered in the Lakehouse runtime catalog. Customers can also use Managed Spark to write to Iceberg tables in external catalogs.

  • Fully managed Iceberg storage with enterprise-grade features: Use Google's differentiated infrastructure to run analytics with performance on Iceberg tables. This gives you the benefits of open-source flexibility plus performance, scale, governance, and multimodal processing. 

  • Zero data copy: Table definitions point directly to your existing data in the underlying object store. You do not move, rewrite, or duplicate your underlying data.

  • Bi-directional catalog federation across clouds: Access data from Databricks Unity, Snowflake Horizon and AWS Glue with support for vended credentials and OIDC token exchange. This lets you bring Google AI directly to your AWS and Azure data.

  • Secure access using credential vending: The catalog supports multiple authorization mechanisms, letting you choose between credential vending and end-user credentials. This means that you can access tables with modern mechanisms such as credential vending without needing direct access to the files in the underlying object store (Cloud Storage, AWS S3, Azure Blob Storage). 

  • AI-powered context and governance: The Lakehouse runtime catalog integrates directly with Knowledge Catalog and Cloud IAM, allowing you to define trusted context for your agents, and apply table-level security consistently across all compute engines. Get out-of-the-box search, lineage, and insights for Iceberg tables in the catalog. 

  • Atomic commits and concurrency control, high availability and scalability: Backed by Google’s planet-scale infrastructure and Spanner, you get the high availability, concurrency and scale you need for your metadata to scale with your data. Support for Cloud Storage dual-region and multi-region buckets enables failover use cases. It also provides reduced TCO due to serverless and no-ops environments, and scalability for any workload size.

What powers the Lakehouse runtime catalog?

The Lakehouse runtime catalog is a highly available, concurrent and scalable catalog with strong consistency guarantees because it is built on top of Spanner. Unlike traditional scale-up relational databases that hit vertical single-node ceilings, Spanner combines full relational SQL semantics and multi-table ACID transactions with the horizontal scale-out elasticity for both reads and writes of a NoSQL system.

Spanner makes the Lakehouse runtime catalog highly available through Spanner’s regional configurations with up to 99.99% availability. Spanner also delivers out-of-the-box scalability for  Lakehouse runtime catalog: As a horizontally scalable database, Spanner does not require manual sharding and scales compute and storage independently and transparently. Spanner dynamically monitors data volume and query load, splitting and redistributing data ranges across nodes. Compute nodes scale dynamically based on CPU utilization and storage thresholds. Spanner automatically detects split-level overload and moves heavy splits away from overloaded nodes. Spanner also lets Lakehouse runtime catalog users eliminate the traditional trade-offs between relational consistency and distributed scalability, delivering Lakehouse runtime catalog’s industry-leading consistency guarantees. Lakehouse transactions are serializable — the order of transactions within the database is the same as the order in which clients observe the transactions to have been committed. This foundation allows Lakehouse users to operate at agent-scale.  

Then, to further power agentic use cases, the Lakehouse runtime catalog integrates directly with Knowledge Catalog to easily discover lakehouse Iceberg tables and provide trusted context to agents. Knowledge Catalog leverages an efficient combination of full-text search and native vector search provided by Spanner; this approach enables better recall for search retrieval, pairing lexical keyword searches with semantic embeddings in a single query. Because both index types are built on the identical base dataset, they update with strict, transactional ACID consistency alongside base table DML operations. This removes operational overhead such as managing sync pipelines, and external-vector and full-text search systems. In short, the Lakehouse runtime catalog provides faster time-to-market for your agentic use cases.

Combine analytical and operational workloads

With Google Cloud’s borderless Lakehouse based on Apache Iceberg, you can combine your analytical data with your operational workloads. Use cases span combining data assets from your Lakehouse with OLTP data (from Spanner) for analytics, to low-latency serving applications where your Lakehouse assets are accessible in an operational database such as Spanner, to conversational analytics in first-party and third-party agents. 

Below, in an example, you can see the Lakehouse runtime catalog with Spanner in action. Here, we combine analytical data for taxi trips in Manhattan (backed by Apache Iceberg) with operational data for taxi zones in Spanner to find the most congested traffic routes. The example also shows that you can also use a Conversational Analytics Agent to access the same data and get second-order insights.

<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="2" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/2_TvlKrOP.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Find out most congested traffic routes in Manhattan</p></figcaption>
  
</figure>


  </div>
</div>

Modernize to the borderless Lakehouse

Modernizing to Google Cloud’s Lakehouse minimizes data silos across analytics engines and agents, unifies multi-engine governance, provides trusted context to your agents and slashes operational TCO. Leveraging the Spanner-based Lakehouse runtime catalog helps prepare your modern cloud environments to operate at agent-scale. To learn more and get started with a free trial, visit the 

Lakehouse web page and learn more about Spanner here.

Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise

詳細を表示

Co-authors:
Stenal Jolly, Strategic Cloud Engineer, Google
Anubhav Dhawan, Software Engineer, Google

Following the landmark announcement of MCP Toolbox v1.0, we're thrilled to announce that the MCP Toolbox Java SDK has officially reached version 1.0.

This release brings first-class, type-safe agent orchestration to one of the world's most widely adopted enterprise ecosystems. Java's mature architecture is purpose-built for rigorous demands, providing the high concurrency, strict transactional integrity, and robust state management required to safely scale mission-critical AI agents in production.

In this post, we'll tell you about what's new in Java SDK v1.0, show you a real-world example, and help you get started with your own implementation.

MCP: The universal interface

Today, developers face a compounding integration bottleneck: if you have N different AI models and M enterprise data sources, you must build, secure, and maintain N × M bespoke, custom connections. This lack of a unified integration layer forces engineering teams to rely on a fragmented web of ad-hoc pipelines. As a result, scaling an agentic architecture quickly becomes unsustainable, exposing sensitive enterprise databases to severe security vulnerabilities, fragmented access controls, and massive maintenance overhead.

Eliminating the fragmented web of custom integrations is the core problem solved by the Model Context Protocol (MCP). Acting as a universal interface—the "USB Type-C" for AI orchestration—MCP decouples models from data sources. Instead of writing custom or managed API integration code for every new model or database, developers write to a single, standardized protocol. This approach allows any MCP-compliant agent to securely and immediately interact with any MCP-enabled system. The MCP connection lets developers connect agents to real-world systems without building bespoke integrations for every new model.

What's new in Java SDK v1.0: Built for production workloads

When we announced the public Beta for the MCP Toolbox Java SDK, our goal was to bring first-class, type-safe agent orchestration to enterprise Java environments. Since then, we've collaborated with developers and open-source contributors to harden our APIs.

The v1.0 release marks a stable, backwards-compatible foundation suitable for enterprise workloads. Here's what's new and hardened since our v0.2 release:

  • Transport layer abstraction & HttpMcpTransport: We introduced a clean transport layer abstraction alongside HttpMcpTransport. This feature decouples the core protocol logic from underlying HTTP clients, making it easy to swap network implementations or customize connection pooling.

  • Decoupled client authentication: To simplify enterprise security compliance, client authentication is now decoupled using CredentialsProvider and AuthMethods classes. Credentials are resolved asynchronously on every request, so teams can refresh tokens dynamically or plug in their own token source (Google OIDC via ADC ships in the box, anything else is a one-method interface).

  • Default parameter support: Native support for default values in tool parameters, reducing prompt payload sizes and enhancing agent reliability.

  • Pruning bound parameters: Sensitive parameters that are bound server-side (like tenant_id) are now automatically stripped from exposed tool definitions so the LLM can't manipulate them.

  • Version selection & session tracking: Standardized MCP version selection and robust session tracking ensure consistent protocol negotiation and conversation-state lifecycles.

  • HTTP credential exposure warnings: Added built-in detection that warns you at runtime when credentials are about to travel over a plaintext HTTP connection.

  • Generic client headers map: Easily attach custom corporate proxy headers, transaction tracing IDs, or correlation metadata to all outgoing requests.

Get started with the Java SDK v1.0

We designed the MCP Toolbox Java SDK to be frictionless for enterprise teams. Just add the following dependency to your 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 0x7f3c41fc3a90>)])]>

Real-world example: The autonomous transit concierge

To demonstrate the power of the Java SDK combined with AlloyDB, let's look at an enterprise use case.

Meet Cymbal Transit, a fictitious intercity bus network. Customers don't want to click through nested dropdown menus to plan a trip. They want to ask:

"I need to get from New York to Boston tomorrow morning. Can I bring my Golden Retriever? If so, book me the fastest trip."

To answer this question, an AI agent must cross-reference unstructured data (pet policies) with structured data (schedules and seat availability) and execute a transaction (booking)—all while maintaining the context of the conversation.

The foundation: AlloyDB schema with native embeddings

We used AlloyDB for this implementation because it handles relational data and high-dimensional vectors natively. Set up your database tables with these statements:

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

Mapping intents to SQL: The tools.yaml

The MCP Toolbox lets you define custom tools securely. Rather than granting the LLM direct database access, a tools.yaml configuration maps natural language intents directly to parameterized, safe queries:

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

For the complete YAML file, see the tools.yaml file in the mcp-toolbox-sdk-java repository.

Stateful agent architecture in Spring Boot

The hardest part of building conversational AI in enterprise applications is managing state: when a user asks, "What times are available?" and follows up with, "Book the 8 AM one," the agent must remember prior context across turns.

Using the Java MCP Toolbox SDK with Spring Boot and LangChain4j, we can cleanly maintain conversational memory in the HTTP Session and we can cleanly separate the agent into two declarative components:

  1. A declarative agent interface that manages the prompt, tools, and conversational memory via an HTTP session.

  2. A tool execution service that routes agent requests directly to the MCP Toolbox server.

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

Notice how the @MemoryId annotation abstracts session tracking: Spring Boot automatically correlates conversational context to the user's HTTP session. Meanwhile, LangChain4j and the MCP Toolbox handle schema translation and tool routing behind the scenes—no handwritten if/else intent parsing required.

By pairing the MCP Toolbox Java SDK with LangChain4j, we achieve clean separation of concerns and effortless state management:

  • Zero-boilerplate session management: The @MemoryId String sessionId parameter binds conversation history directly to the user's HTTP session.

  • Declarative agent contract: The TransitAgent interface defines the model's persona and system instructions without complex prompt templating.

  • Type-safe tool execution: The TransitAgentTools Spring service wraps remote MCP database tools as native Java methods.

This architecture ensures your agent remains modular: you can refine prompt guidance in the interface, manage user sessions automatically, and execute secure database queries through MCP Toolbox without tight coupling.

Connecting the dots: Listing, invoking, and executing tools in Java v1.0

Now let's look under the hood of the TransitAgentTools interface. Inside those LangChain4j @Tool methods on our Spring @Service, the MCP Toolbox Java SDK handles the heavy lifting—bridging your Java service methods to the MCP tools defined in the tools.yaml file. In just a few lines of type-safe code, we can initialize our client using the new v1.0 decoupled authentication and headers abstractions:

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

Secure by default: authentication and deployment

Moving an AI agent to production requires rock-solid credential handling and an infrastructure that scales with demand. Let's look at how you can enforce credential safety across environments and deploy independently on Cloud Run.

Application Default Credentials (ADC) & safety

By using the GoogleCredentialsProvider service, your Java app inherits its secure identity from its execution environment (whether local or in Google Cloud) through Application Default Credentials (ADC)—no hard-coded keys, with OIDC tokens minted and cached per audience under the hood. Furthermore, v1.0 offers HTTP Credential Exposure Warnings that automatically detect when credentials are about to travel over a plaintext HTTP connection and emit a runtime warning telling you to switch to HTTPS.

Deploying the fleet to Cloud Run

Because MCP Toolbox and the Spring Boot Agent are fully decoupled, they scale independently on Google Cloud Run to meet high concurrency and stateful conversation requirements.

To set up and configure Toolbox on Cloud Run, download the open-source MCP Toolbox for Databases and then follow the deployment guide.

Get started today

With MCP Toolbox Java SDK v1.0, enterprise Java teams can wire Spring Boot and LangChain4j agents to the Toolbox server, and through it, to AlloyDB and every other supported data source. When you use the toolbox, arguments are validated against the tool definition before they leave the JVM, authentication is decoupled, and custom headers are attached to every outgoing request. The following implementation steps will help you get started.

Step 1: Add the Dependency

To start building with the SDK, add the following dependency to your Maven project's pom.xml file:

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 <!-- {x-version-update:mcp-toolbox-sdk-java:current} -->\r\n </dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3c41b1f0d0>)])]>

Step 2: Explore Resources & Demos

Demo Application: To experience the Java SDK V1.0 for MCP Toolbox latest, try the sample application Cymbal transit project.

Gradle implementation

If your team uses Gradle instead of Maven, remember they will need to translate this dependency:

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

Automatic version tracking

If you copy this setup into automated internal repositories, keep the XML comment <!-- {x-version-update...} --> intact. It's required by the release manager's deployment scripts to automatically bump versions.

Now that you can integrate your modern agentic tools and servers to your enterprise Java applications with a stale MCP Toolbox Java SDK, get started today!

Google Cloud Japan Blog

Google Cloud パートナー、Gemini Enterprise を活用して新たなセキュリティ エージェントと AI 防御機能を提供

詳細を表示

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

脅威アクターが AI を利用してサイバー攻撃を加速、開発するケースが増えるなか、企業の防御者は AI と、防御者にとって重要な強みである「自社だけが持つビジネス コンテキスト」の両方を活用する必要があります。

企業のサイバー防御は、ID、ネットワーク、エンドポイント、データ、クラウド、アプリケーションの各レイヤにまたがっており、多くの場合、12 種類以上のプロダクトに分散し、それぞれが独自のコンテキストを持っています。Google Cloud Next では、パートナーが構築したエージェントを Gemini Enterprise に組み込み、セールス、コンテンツおよびクリエイティブ ワークフロー、人事、セキュリティなどの機能にわたり、専門エージェントを 1 か所で検出してデプロイできるようにしました。

このたび、Gemini Enterprise エコシステムでパートナーが構築したセキュリティ サービス カタログを拡充し、単一の統合インターフェースからセキュリティ コンテキストを最大限に活用できるようにいたしました。

主要なサイバーセキュリティ ベンダーが提供するこれらの新たなセキュリティ エージェントとインテグレーションは、チームが Gemini Enterprise で直接呼び出すパートナー製セキュリティ エージェントと、AI およびエージェント型ワークロードの保護という 2 つの領域にわたっています。これらを Gemini Enterprise に組み込むことにより、Gemini Enterprise 環境で直接、複数ステップのセキュリティ ワークフローをオーケストレーションできるようになり、AI を活用した機能を防御に取り入れることが可能になります。

Gemini Enterprise で構築された、新たなセキュリティ エージェントとエージェント型防御のご紹介

Acalvio: Gemini Enterprise からアクセスできる Acalvio ShadowPlex ディセプション エージェントは、企業ネットワーク全体へのデコイとハニートークンのデプロイを自動化し、ディセプション ガードレールを顧客の運用環境に直接埋め込みます。手動での構成は不要です。ShadowPlex は、ネットワーク デコイ、ID ハニー アカウント、検索拡張生成（RAG）デコイ、ハニースキル、ハニートークンを大規模にデプロイし、不正なインタラクションを迅速に捕捉します。

Britive: Gemini Enterprise を基盤とする Britive Emergency Termination Agent を使用すると、セキュリティ チームは複数のコンソールを操作することなく、単一の自然言語リクエストから、侵害された人間または人間以外の ID を封じ込めることができます。このエージェントは、ID を確認し、アクティブな特権セッションをすべて一覧表示して、人間の承認を得てすべてのセッションを取り消し、ID を無効にして、インシデント チケットの監査コンテキストを収集します。その結果、エージェントの厳格なガバナンスと最小権限アクセスを維持しながら、封じ込めまでの平均時間（MTTC）を大幅に短縮できます。

Check Point: Google Cloud Agent Gateway および Agent Registry と統合された Check Point AI Defense Plane は、エンタープライズ規模の AI で必要とされる重要なセキュリティ管理と可視性を提供します。組織は、AI ワークロードの検出、リスク ポスチャーのモニタリング、コンプライアンスに違反する動作の検出に加えて、プロンプト インジェクション、データ漏洩、エージェントの不正な挙動に対するリアルタイムのガードレールの適用が可能になります。Gemini Enterprise 内の Check Point Agent を通じて管理されるこの統合ソリューションは、Gemini Enterprise での AI ワークロードのデプロイを保護し、高速化します。

CrowdStrike: CrowdStrike Falcon® Guardian は、Agent Gateway と統合することでガードレールとランタイム保護を拡張し、Gemini Enterprise で実行されるエージェント型ワークロードをプロンプト インジェクション、機密データの漏洩、悪意のある AI アクティビティなどのリスクから保護します。さらに、CrowdStrike Gemini Enterprise エージェントにより、実務担当者は Gemini Enterprise を通じて CrowdStrike プラットフォームを操作できます。これにより、CrowdStrike のセキュリティ コンテキストをエージェント型の調査と対応に組み込み、多数のツールにわたる SOC ワークフローのオーケストレーションを支援します。

Cyberhaven: Cyberhaven Linea エージェントは、エンドポイント、クラウドアプリ、エージェント型ワークフロー全体にわたる機密データの検出と分類を Gemini Enterprise で可能にします。Cyberhaven のデータリネージ モデルを活用したこのエージェントは、平易な言葉で表現された意図を適用可能なポリシーに変換し、インタラクションをモニタリングして、マッピングされていないリスクを侵害が発生する前に捕捉します。また、証拠の自動収集により調査が迅速化します。Gemini Enterprise の Antigravity 全体にわたり、Linea エージェントはアラート疲れを解消し、自律型エージェントが機密性の高いアセットを移動するのと同じ速さでセキュリティ チームがそれらを保護できるようにします。

Cyera: Gemini Enterprise を基盤とする Cyera Agent Guardian は、Gemini で実行されるエージェントを保護し、データ セキュリティ ポスチャー管理（DSPM）とデータ損失防止（DLP）を提供します。Cyera エージェントは、マシン ID、委任された権限、機密データの分類を相互に関連付け、承認されたエージェント型の動作を検証できるため、組織はエージェントを安全にデプロイし、エンタープライズ規模で運用コンプライアンスを維持できます。

Endor Labs: Endor Labs AURI エージェントは、デベロッパーとセキュリティのワークフロー全体に AI ネイティブのアプリケーション セキュリティをもたらします。同社の静的アプリケーション セキュリティ テスト（SAST）トリアージ エージェントは、Google Antigravity などのデベロッパー プラットフォーム内でコードから検出された問題を自動的に分類し、優先順位を付けることができます。Gemini Enterprise では、セキュリティ チームはこれらの検出結果を会話形式でクエリして対応できます。実際に悪用可能なものを確認し、修正を追跡することが可能で、そのすべてが Endor Labs アプリケーションのコンテキストに基づいています。

Exabeam: Exabeam は、Gemini Enterprise を基盤とする次世代の Exabeam Nova を導入しています。これは、セキュリティ チームが脅威をより迅速に調査して対応できるようにする、統合マルチエージェント AI システムです。Nova は、ワークフロー全体で共有されている運用コンテキストを維持しながら、行動の分析、リスクの優先順位付け、調査の実施、対応アクションの誘導を行うことができる、専門の AI エージェントと連携します。その結果、アナリストはよりインテリジェントで効率的なエクスペリエンスを得ることができ、組織は既存のセキュリティ運用環境からより大きな価値を引き出すことができます。

Fastly: Fastly Autonomous Edge Defense Agent（AEDA）を使用すると、セキュリティ チームは Gemini Enterprise 内で、ログを手動で解析する代わりに、エッジやインフラストラクチャのインシデントを平易な言葉で調査できます。AEDA は、組織独自のテレメトリーと Fastly のグローバルな顧客ベースから得た匿名化されたインテリジェンスを組み合わせ、異常は単発的なものなのか、より広範な攻撃の一部なのかを数秒で判断し、証拠に裏付けられた調査結果と推奨される修正策を返します。

Fortinet: Fortinet FortiAIGate は、Google Cloud のお客様に大規模言語モデル（LLM）のランタイム保護を提供します。Gemini Enterprise と統合され、Google Cloud 環境にデプロイされた FortiAIGate は、組織が高度なエージェント型 AI アプリケーションをデプロイできるよう支援します。これにより、データ、プロンプト、モデルとのインタラクションを新たな脅威から積極的に保護できます。

Menlo Security: Gemini を使用して構築された HEAT Shield Agent は、ウェブ コンテンツを分析し、実行時にゼロデイ脅威やプロンプト インジェクションをブロックします。これに加えて、Gemini Enterprise を基盤とする Menlo Security Orchestrator が、セキュリティ オペレーション センター（SOC）のレスポンスを自然言語によるエージェント型ワークフローに変換します。これは、攻撃の再構築、影響範囲の特定、ポリシーの適用を、数時間ではなく数秒で行うことができます。Menlo Agent Runtime Security（MARS）は、このループを完結させ、人間とエージェントおよびエージェント同士のインタラクションを保護することで、エージェント型ワークロード全体で検出と封じ込めが統合された状態を維持します。

Obsidian Security: Gemini Enterprise で Obsidian Security の Risk Analyzer エージェントと Breach Response エージェントを使用すると、セキュリティ アナリストはリスクを評価し、侵害に対応できるようになります。組織のクラウドと AI ネイティブ アプリケーション ポートフォリオを保護するために構築された Obsidian エージェントは、企業環境全体にわたり AI エージェントを検出し、リスクを評価して、ガバナンスのギャップを報告します。また、どのエージェントが昇格された権限や書き込みアクセス権を持っているかといった重要な質問に答えます。

Palo Alto Networks: Palo Alto Networks のクラウド、ネットワーク、AI リスク評価（CLARA）エージェントは、開発のペースを落とすことなく、重要なデータとコンプライアンスを確保した AI 運用を保護できるよう、セキュリティ チームを支援します。クラウド インフラストラクチャと AI ワークロードを継続的にスキャンし、隠れた脆弱性を自動的に検出して修正の優先順位を付けることで、クラウドや AI のリスクが侵害に発展する前に発見して修正できます。これにより、セキュリティ チームは脅威の検出に費やす時間を減らし、脅威の解消により多くの時間を費やすことができるようになります。

Ping Identity: Gemini Enterprise で利用可能になった Ping Identity の新しい PingID セルフサービス エージェントを使用すると、従業員は多要素認証（MFA）のリセットやデバイスの復元など、ID やデバイスに関する一般的な問題を自然言語で質問して解決できます。ヘルプデスクのチケットは不要です。PingOne を基盤とする、セキュアな委任認証を備えた PingID セルフサービス エージェントは、従業員の ID を管理するためのエンタープライズ対応の手段を IT チームに提供すると同時に、サポート費用の削減とオンボーディング エクスペリエンスの向上を実現します。

Qualys: Qualys ROCky for Gemini Enterprise は、セキュリティ チームが Gemini Enterprise 内で会話を使用して脆弱性を管理し、パッチを適用するのに役立ちます。「Log4Shell の影響はどの程度か」、「まず何を修正すべきか」、「CISA KEV の期限を守れているか」といった質問をすると、Qualys TruRisk スコアに基づいてランク付けされた回答が得られます。各ユーザーが所有する Qualys の利用資格に基づいて動作するため、誰でもサポートなしで自ら回答を得ることができます。また、パッチのステージングとデプロイも行えます。

Splunk（Cisco 傘下）: Gemini Enterprise と統合された Splunk Security AI エージェントは、膨大なテレメトリー ストリームをセキュリティ データとオブザーバビリティ データ全体にわたるリアルタイム インテリジェンスに変換する自律システムとして機能します。手動によるトリアージを省略して、重大な異常やシステム脅威を即座に表面化させることで、チームは事後対応型の調査からプロアクティブな防御へと転換できます。これにより、プレッシャーの大きなインシデント発生時の認知負荷が軽減され、セキュリティ チームはリスクをより迅速に解決できるようになります。

Synk: Gemini Enterprise と Antigravity を使用して構築しているすべての企業が、かつてない速さでコードをリリースしています。Snyk は、コードが作成された後ではなく作成されたその瞬間から、コードがセキュアであることを保証します。Snyk は、AI エージェントが生成したものをリアルタイムで検証し、脆弱性やセキュアでない依存関係がリポジトリに到達する前に検出します。これは、AI がコードを記述する速度に合わせて構築されたセキュリティです。人がかつて記述していた速度に合わせたものではありません。

Thales: Gemini Enterprise と統合された Thales AI Security Fabric は、エージェント型 AI のインタラクション全体にわたって可視性、ランタイム保護、一元化されたガバナンスを提供します。組織は、エージェント型 AI を試験運用から本稼働に移行し、きめ細かなアクセス ポリシーを適用して、重要なデータアセットを実行環境で直接保護できます。

Transmit Security: Gemini Enterprise を基盤として構築された Transmit Security Agent Intelligence は、顧客向けアプリケーションとやり取りを行うエージェント型アクティビティを特定します。ユーザーがタスク、トランザクション、権限を AI エージェントに委任することが増えるにつれ、組織は、そのアクティビティの内容、発生元、意図を明確に把握する必要があります。こうしたコンテキストを把握することで、企業は正常なエージェントと悪意のあるエージェントを見分け、許可すべきものとブロックすべきものを判断し、正当な取引を制限することなくリスクを未然に防ぐことができます。

Zscaler: Zscaler Risk360 は、既存の Zscaler のデプロイからデータを取り込み、サイバーリスクを定量化し、リスク ポスチャーの詳細なビューを作成して、リスクを軽減するための明確な分析情報を提示する、包括的かつ実用的なフレームワークを提供します。Risk360 Agent は、Gemini Enterprise を使用した ZAgent フレームワーク上に構築された AI 搭載コンパニオンです。自然言語によるやり取りを使用して、Zscaler とパートナーからのシグナルの統合、ゼロトラスト リスクの分析、財務的影響の定量化、緩和策の推奨、意思決定に役立つ分析情報を提供します。

パートナーが構築したエージェントやコネクタのエコシステムが拡大する中、Gemini Enterprise は、お客様がすでに利用しているセキュリティ ツールと連携し、それらを基盤としてカスタム エージェント型ワークフローを構築できるようにします。Google Cloud Marketplace で、現在利用可能なセキュリティ エージェントを今すぐご確認ください。

- セキュリティおよび ID パートナーシップ担当ディレクター、Vineet Bhan

- セキュリティ担当パートナー エンジニアリング責任者、Ashish Verma

エージェントの時代における妥協のない新しいデータベース アーキテクチャ

詳細を表示

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

データベース エンジニアはキャリア全体を通して、ある 1 つの課題に取り組んできました。それは、データを保持する記録システムの信頼性を損なうことなく、OLTP ワークロードをどのようにスケールするかということです。

Exadata は、データベース下部のスケールアウト ストレージ階層にクエリをオフロードすることで、ネットワークのボトルネックを排除し、この課題を解決しました。Azure SQL Hyperscale は、共有ブロック サーバーを使用して、数十のリードレプリカにスケールアウトしました。Aurora は、ログの適用処理を分散ストレージ ノードにオフロードし、複数の PostgreSQL ノードにわたる読み取り処理のスケーリングを実現しました。一方、新しいアーキテクチャでは、従来のオブジェクト ストレージにデータを永続化し、その手前にプロビジョニングされたキャッシュ階層を配置しています。これにより、ホットデータのレイテンシは抑制できるものの、キャッシュミスが発生するたびに長いレイテンシが発生します。

これらのアーキテクチャはどれも、スケール、レイテンシ、分離という 3 つの特性のうち、少なくとも 1 つ、場合によっては 2 つの制約を本質的に抱えています。たとえば、共有ブロック サーバー上に構築されたアーキテクチャでは、ブロック サーバーで I/O が必然的にボトルネックになるため、スケーラビリティが損なわれます。また、レプリケーション トラフィックが急増するたびに本番環境のワークロードがスロットリングされるため、分離も損なわれます。

こうしたトレードオフの中には、設計当初は実際に妥当だったものもあり、40 年間にわたってエンタープライズ データベース ワークロードの要件を満たしてきました。しかし、エージェントの時代においては、このような妥協はもはや通用しません。エージェント ワークロードは動的に生成されるため、事前に検証することはできません。そのため、ミッション クリティカルなシステムから分離することが、ビジネスの継続性を確保するうえで不可欠です。エージェント ワークロードは、データベース エンジンとそのすべてのインデックスの能力を最大限に活用して初めて実現できる低レイテンシを必要とします。同時に、単一のデータベースでは前例のない、まったく新しいレベルの弾力的なスケーリングも求められます。具体的には、単一のデータベースに対して数秒以内に 1,000 個のコンピューティング ノードを要求し、1 分以内に処理を終了するような、エージェントのバーストに対応できるスケーリングです。

真のエージェント型データベース アーキテクチャに必要な 3 つの原則

エージェントの時代には、3 つの基本原則によって定義される新しいエージェント型データベース アーキテクチャが必要であると Google は考えています。エージェント型データベース アーキテクチャがその真価を発揮するには、これら 3 つの条件すべてを満たすことが不可欠です。

  1. 原則: 分離 - 設計レベルでの分離でありながら、リアルタイムなデータアクセスを実現。エージェントは、プライマリ クラスタとデータベース コンポーネントを共有しないデータパスを介して、1 秒未満の更新頻度で本番環境のライブデータを読み取る必要があります。リアルタイムとは、古いコピーやブランチではなく、秒単位で更新される最新のデータを意味します。これは割り当てではなく、物理的な分離です。リソースを共有するということは、運命を共にすることを意味するからです。その境界線はストレージ レイヤまで達しているため、設計レベルでリソースの競合を排除しています。

  2. 原則: レイテンシ - 1 ミリ秒未満のベースライン I/O。運用ワークロードでは 1 ミリ秒未満のブロック I/O が求められますが、エージェントでもその基準は変わりません。コンピューティング ノードは DRAM とローカル SSD を利用して高速化を実現していますが、キャッシュミスが発生してリモート ストレージへアクセスする場合であっても、アプリケーションかエージェントかを問わず、1 ミリ秒未満で処理を完了できるストレージ設計が求められます。パフォーマンスが桁違いに低下するアーキテクチャは、エージェントにとって根本的に使い物になりません。

  3. 原則: スケール - エージェント スケールのコンピューティングと I/O。エージェントのスケールは、瞬発的かつ一時的でありながら、極めて大規模という特徴を同時に持ちます。データベース コンピューティング ノードは、数秒でのスピンアップ、数千台へのスケール、短時間でのバースト実行、エージェントの処理終了後の自動的なゼロへのスピンダウンを行う必要があります。本番環境に一切影響を与えずに、データベースのコンピューティングと I/O を数千ノード規模へ即座にスケールさせることは、従来のデータベースの常識では不可能なことでした。エージェントの動的な性質を考えると、コンピューティング、ストレージ I/O、その間にあるキャッシュ階層にいたるまで、スタック全体における事前プロビジョニングは現実的ではありません。

重要なのは、エージェント アーキテクチャは、これら 3 つの原則をすべて同時に満たす必要があるということです。こうしたアーキテクチャにより、エージェントは本番環境の安定性を損なうことなく、ライブ運用データ、つまり企業の実体に直接アクセスして処理を行うことができます。その結果、以下のような劇的な変化がもたらされます。

  • 連動障害がない: ビジネスを運営するエンジンと、その上で推論を行うエージェント フリートが完全に分離されているため、エージェントが本番環境に影響を与える経路が排除されます。

  • 容量予測が不要: 真の弾力性により、予測不可能なエージェントの急増に備えて事前プロビジョニングを行う煩わしさが解消されます。

  • セマンティクスの妥協がない: エージェントに対して制限される機能はありません。すべての推論ステップにおいて、リレーショナル SQL、ハイブリッド検索（ベクトル、全文、空間）、そしてインデックスの機能を最大限に活用できます。

AlloyDB のエージェント アーキテクチャ

AlloyDB の新しいエージェント型データベース アーキテクチャは、これら 3 つの原則をすべて満たす初のシステムです。Google は、ストレージ、ネットワーク、コンピューティング、データベースにわたって、これをゼロから構築し、以下を実現しました。

  • 分離によって設計レベルでの障害の連鎖を回避: トランザクション本番環境クラスタは、エージェント ワークロードから完全に分離され、事前プロビジョニングされた専用インフラストラクチャ上で実行されます。エージェントは、Model Context Protocol（MCP）を介して、本番環境とは別の専用の Colossus ストレージ セグメントから直接読み取る、マイクロ VM ベースの AlloyDB ノードの独立したエフェメラル プールに接続します。

  • 予測可能な 1 ミリ秒未満のストレージ I/O: すべてのストレージ読み取りは、Google の Colossus ストレージ システムによって直接処理され、1 ミリ秒未満のベースライン レイテンシを継承します。これにより、コールド キャッシュミスによるパフォーマンスの急激な低下がなくなります。

  • ゼロから数千ノードへの真のコンピューティング スケーリング: エージェント プールは、エージェント アクティビティのバーストに対応して、ゼロから数千のノードへと迅速にスケールアップし、タスクが完了した瞬間にゼロにスケールダウンします。

<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="1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/1_W9G0CoR.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

エージェントは、1 秒未満の更新頻度で本番環境データをクエリし、PostgreSQL エンジンのすべての機能（ポイント検索、インデックス トラバーサル、ベクトル、全文検索、空間検索、カラム型スキャン、レイクハウス全体の連携クエリ）を駆使して、推論ループを強化できます。

エージェント向け AlloyDB PostgreSQL のプレビューに参加して、データの規模を問わず本番環境データ上でエージェントを実行しましょう。その全機能について詳しくは、関連するお知らせのブログ記事をご覧ください。

既存のアーキテクチャが 3 つの原則をすべて満たせない理由

従来型および新興の運用データベースは、3 つのアーキテクチャ パラダイムのいずれかを採用することでスケーリングを図っています。自律型 AI エージェントの要件に照らして評価すると、どのパラダイムにも構造上の根本的な限界があり、3 つの原則を同時に満たすことは不可能です。

独立したレプリカ（シェアードナッシング ストレージ）

従来のリレーショナル アーキテクチャでは、プライマリ インスタンスから専用のレプリカ データベースにレプリケーション ログをストリーミングすることで読み取りをスケールします。各レプリカ データベースは、それぞれ専用のローカル ストレージまたはアタッチされたブロック ストレージを備えています。これは「原則: 分離」を満たしています。つまりレプリカはプライマリ クラスタと物理リソースを共有せず、継続的なログ レプリケーションにより、準リアルタイムの最新性が維持されます。また、「原則: レイテンシ」も満たしています。専用のローカル ストレージにより、予測可能な 1 ミリ秒未満の読み取りレイテンシが保証されます。しかし、「原則: スケーリング」は満たしていません。スケーリングには、新しいレプリカをプロビジョニングし、数百ギガバイトまたはテラバイトのストレージをリハイドレーションする必要があります。これらすべての処理には数時間かかります。これでは、秒単位で発生するエージェントの爆発的な推論バーストには対応できません。さらに、静的にプロビジョニングされたコンピューティングとストレージは、エージェントの実行が完了した後も、アイドル状態でコストが発生し続けます。

分離された共有ストレージ サーバー

2 つ目のアプローチは、ステートレス コンピューティング ノードを、永続性とレプリケーションを管理し、ブロック書き込みをオフロードする可能性のあるカスタム ストレージ サーバーの共有マルチテナント階層から切り離すことです。このアプローチは、「原則: レイテンシ」を満たします。最適化されたストレージ サーバーへの読み取りアクセスは、常に安定した低いレイテンシで処理されます。しかし、「原則: 分離」は満たしていません。すべてのレプリカがプライマリと同じサーバーから読み取るため、エージェント I/O が本番環境 I/O と直接競合し、障害の連鎖のリスクが生じるためです。また、「原則: スケール」も満たしていません。データがコピーされないため、ステートレス コンピューティング レプリカは迅速にスピンアップするものの、ストレージ I/O の合計帯域幅が、事前にプロビジョニングされたストレージ階層の容量に制限されるためです。基盤となる I/O 容量をスケールせずにコンピューティング ノードを追加しても、ストレージの処理能力が飽和し、スロットリングを加速させるだけです。

共有ブロック サーバーを使用したオブジェクト ストレージ

3 つ目の新しいアプローチは、汎用オブジェクト ストレージでデータの耐久性を確保し、ブロック サーバーの共有階層からブロック読み取りを行うというものです。オブジェクト ストレージからのランダム読み取りには数十ミリ秒かかります。これは従来のデータベース ストレージより桁違いに遅く、少なくとも 25 年前のエンタープライズ向けディスクアレイと比べてもさらに遅いレベルです。そのため、ブロック サーバーにホットデータを保持させることで、低レイテンシでのデータ提供を実現しています。このアプローチは、「原則: レイテンシ」を満たしますが、1 つ注意点があります。それは、ブロック サーバーでキャッシュミスが起きると、許容できないほど高いレイテンシでオブジェクト ストレージまでフォールバックが発生してしまう点です。一方で、「原則: 分離」を満たしていません。レプリカは本番環境とブロック サーバーを共有しているためです。エージェント I/O と本番環境 I/O は同じ処理容量を使用します。そのため、その容量が枯渇したりスロットリングされたりすると、エージェントだけでなく本番環境にも影響が及びます。また、共有ストレージ サーバーと同じ理由で、「原則: スケール」も満たしていません。レプリカはすぐに起動しますが、ブロック サーバーがバーストに合わせて I/O をスケールしないためです。

このファミリーの一部のアーキテクチャでは、Apache Spark などの分析エンジンがデータベース エンジンをバイパスして、基盤となるオブジェクト ストレージを直接読み取ることもできます。分析ワークロードの場合、これは価値があり、十分に現実的なアプローチです。しかし、エージェントには低レイテンシの検索が不可欠です。インデックス、ポイント検索、ベクトル検索を排除すると、ブルート フォース テーブル スキャンが余儀なく行われ、レイテンシが急増し、エージェントが検索と推論のループを実行できなくなります。

既存アーキテクチャの評価

Google は、共有ブロック サーバーを備えたオブジェクト ストレージ アーキテクチャを使用する市販のサービスを対象に、スケーリングの限界と本番環境の分離の両方を検証する評価を行いました。利用可能な DRAM よりも大きなデータセットに対して、同時にインデックス検索を実行しました。1 つのリーダー インスタンスから始めて、最大 8 つのリードレプリカを追加してワークロードをスケールしました。

物理リソースを共有するアーキテクチャでは、リードレプリカを追加してエージェントをスケールすると、レプリカとプライマリの両方のパフォーマンスが急速に低下します。以下のグラフに示すように、Google のテストでは、レプリカを追加してもスループットの増加は 2 倍未満にとどまりました。レプリカ 4 台でピークに達した後、共有ブロック サーバーの帯域幅が飽和状態になると、スループットは低下しました。

<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="2" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/2_sz3VF5H.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

プライマリ データベースへの影響は即座に、かつ深刻な形で現れました。レプリカが追加されると、プライマリのスループットは 75% 以上も急落したのです。

<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="3" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/3_AJe6Y3V.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

つまり、従来型と新興型のどちらのアーキテクチャも、エージェントが求める規模に対応できないということです。本番環境システムの安定性を損なうことなくそれを実現することは、到底不可能です。

原則に基づく評価

<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="4" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/4_ErZMLBi.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

* 部分的に対応: ホットデータはブロック サーバーから低レイテンシで提供されますが、ブロック サーバーでキャッシュミスが発生すると、オブジェクト ストレージへのアクセスが生じて数十ミリ秒のレイテンシが発生します。

いずれの場合も、この課題は構造的なものであり、単にチューニングで解決できる問題ではありません。レプリケーションは、各レプリカに専用ストレージを割り当てることで分離を実現します。そのため、そのストレージへのデータ同期にかかる時間よりも短い時間でレプリカを追加することはできません。共有ストレージ サーバーは、ストレージを共有することでコンピューティングを迅速に追加できますが、I/O を分離することもスケールすることもできません。オブジェクト ストレージ上のブロック サーバーは、プロビジョニングされた階層でレイテンシを抑制できるものの、分離もバーストもできず、キャッシュミスが発生するたびにオブジェクト ストレージへのアクセスが生じてしまいます。どのアプローチも、あるレイヤで問題を解決したとしても、別のレイヤでその代償を払うことになります。3 つの原則をすべて同時に満たすには、コンピューティング、ネットワーク、ストレージにわたるデータベース アーキテクチャを再考する必要があります。

AlloyDB をスタック全体でどのように構築したか

AlloyDB のエージェント型データベース アーキテクチャは、Google のデータ、AI、インフラストラクチャ スタック（AI モデル、データベース エンジン、および分析エンジン、さらにはストレージ、ネットワーキング、コンピューティング インフラストラクチャ）全体にわたって垂直統合されています。

<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="image4" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/image4_DPg3jLH.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

ストレージ: 基盤としての Colossus

永続レイヤでは、AlloyDB は Google のエクサバイト規模の分散ストレージ システムである Colossus を基盤としています。Colossus は、Google 検索、YouTube、Gmail、Google ドライブ、Spanner、Bigtable を支えています。1 つの Colossus クラスタは、エクサバイト規模のストレージと数万台のマシンにスケールします。Spanner では、Colossus 上に直接構築されたトランザクション データベースが数千ノードまでスケールできることを実証しました。新しい AlloyDB アーキテクチャは、同じ基盤を新たな課題、すなわちエージェントに適用します。

Colossus には、AlloyDB がこれら 3 つの原則を満たすための、3 つの特性があります。

  1. 1 ミリ秒未満の直接 I/O: Colossus は、読み取りレイテンシを最小限に抑えるように設計されています。Colossus ストリームを開くデータベース ノードは、データが物理的に存在する場所を記述したハンドルを受け取ります。承認とメタデータの解決は、ストリームの作成時に 1 回しか行われません。それ以降の読み取りはすべて、最適化されたネットワーク プロトコルを介して、データを保持するディスクに対して直接行われます。その結果、データベースのすべてのデータで 1 ミリ秒未満のレイテンシが実現します。ウォームアップする中間層も、キャッシュミスを起こすような層もありません。

  2. 圧倒的なスループット: Colossus は、帯域幅をプロビジョニングする必要がなく、同時ホスト数に制限がないため、単一の AlloyDB データベースに対して最大 15 TB/秒の総スループットと 2,000 万の秒間クエリ数を実現します。Colossus のスケールから見れば、AlloyDB エージェント ノードのフリートがもたらす負荷は、ストレージのサイズ調整が必要になるようなものではありません。それは、このストレージがすでに処理している負荷のごく一部にすぎないからです。

  3. 物理セグメントのパーティショニング: AlloyDB は、本番とは別の Colossus セグメントからエージェントにサービスを提供するため、エージェントの I/O が本番環境のデータパスと競合することはなく、意図的に本番環境のデータパスから分散されます。

コンピューティング、ネットワーク、ストレージのいずれのデータパスにおいても、エージェントがデータベース コンポーネントを本番環境と共有することはありません。

ネットワーク: Jupiter によるスケーラブルな帯域幅

コンピューティングとストレージは、Google の大容量データセンター ネットワークである Jupiter によって結び付けられています。1 つの Jupiter ファブリックが 10 万台以上のサーバーを 13 ペタビット/秒の二分割帯域幅で接続します。これは、地球上のすべての人がビデオ通話を行うのに十分な帯域幅です。

Jupiter は、ネットワーキング ファブリック全体で予測可能な低レイテンシと高い二分割帯域幅を提供します。そのため、エージェント ノードをクラスタ内のどこにでも柔軟に配置でき、一元化されたストレージに常にアクセスできます。エージェント プールがゼロから数千ノード規模にスケールするにつれて、基盤となる相互接続の容量が、配置上のボトルネックを発生させることなく、増大するトラフィックを吸収します。

コンピューティング: 柔軟でサーバーレスな PostgreSQL と分析

コンピューティング レイヤでは、エージェントが MCP を介して AlloyDB のエージェント プールに接続します。エージェント プールを構成する AlloyDB エージェント ノードは、データベースの秒単位の最新状態に、読み取り専用でアクセスできます。このレイヤは、以下の機能を提供します。

  • マイクロ VM 分離: 各エージェント ノードは、軽量かつセキュアなマイクロ VM 内で実行される、完全に機能する AlloyDB for PostgreSQL データベース エンジンです。これらのインスタンスは、互いに完全に分離されており、専用のプライマリ クラスタからも分離されています。

  • 迅速なスピンアップとスケーリング: エージェント ノードは、エージェントからのリクエストに応じてプロビジョニングされ、エージェントが処理を終了すると自動的に停止します。バーストが発生すると、AlloyDB は数千のエージェント ノードを迅速にプロビジョニングし、数百万の同時エージェントにサービスを提供します。エージェントが処理を終了すると、それらを解放します。課金はエージェント ノードのアクティビティの秒単位で行われるため、1,000 個のノードを数十秒間使用するバーストでは、ジョブが消費したリソースに対してのみ課金され、それ以上のコストは発生しません。

一方、本番環境クラスタは、専用インフラストラクチャ上に事前プロビジョニングされ、記録システムに合わせてサイジングされた、従来通りの状態のまま維持されます。エージェント ノードは Colossus から直接データを読み取るため、1 秒未満の更新頻度で、一貫した本番環境のデータを参照できます。

エージェント プール以外にも、BigQuery と Spark は本番環境クラスタから同じように分離された Colossus から AlloyDB データを読み取ることができるため、エージェントは Lakehouse Federation を使用して、リアルタイムの運用データを大規模な Lakehouse データセットと結合できます。

AlloyDB の新しいエージェント データベース アーキテクチャは、Google 規模のストレージ、ネットワーク、コンピューティング レイヤを基盤とすることで、際立った目標を達成しています。それは「データのみを共有し、それ以外は何一つ共有しない」という目標です。

AlloyDB のエージェント型データベース アーキテクチャの評価

Google は、利用可能な DRAM よりも大きなデータセットに対して同時インデックス検索を実行し、フルスタック全体におけるスケーラビリティを検証することで、AlloyDB の性能を評価しました。エージェント ワークロードを、単一のエージェント ノード（従来のリードレプリカではなく、エージェント プール内の独立したデータベース インスタンス）から開始し、単一のデータベース上で数千ノードまで動的にスケールしました。その際、エージェント全体の合計スループットと、本番環境への影響を測定しました。

このテストでは、エージェント ノードを 1 つから 10 個に増やすと、スループットが 3,900 QPS から 4.1 万 QPS へとほぼ完全に比例して向上しました。さらに 2 桁上（100倍）の規模までスケールさせても、最大 1,000 ノードに達するまで、ほぼ完全に比例したパフォーマンスが得られました。Google は、以下を確認しました。

  • プライマリのパフォーマンス低下ゼロ: エージェント ノードを 1 から 1,000 にスケールしても、プライマリ クラスタのパフォーマンスに測定可能な影響は生じませんでした。

  • 膨大なスループット: 合計スループットが動的に 773 倍の 300 万 QPS にスケールされ、1,000 台のコンピューティング ノードにわたって Colossus で 800 万 IOPS 以上を達成しました。

<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="7" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/7_C0rtDwX.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

2,100 のエージェント ノードでテーブル全体のスキャンを同時に実行する同様のベンチマークでは、合計スキャン スループットが 1 秒あたり約 1 テラビットを超えました。

エージェント プールは本番環境クラスタと物理インフラストラクチャを共有しないため、チームは本番環境システムを危険にさらすことなく、推論フリートを数千ノード規模にスケールできます。

3 つの原則すべてを設計に組み込む

次の表は、AlloyDB のアーキテクチャが 3 つの原則をどのように満たしているかを示しています。

<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="8" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/8_OwYnVhS.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

エージェント型データベース アーキテクチャには、これら 3 つの基本要素が不可欠です。すなわち、Colossus の特性を備えたストレージ、コンピューティングとストレージをボトルネックなしに接続するネットワーク、そしてエージェントの規模に合わせてプロビジョニングと解放ができるコンピューティングです。

Google は、Google 検索、YouTube、Gmail を稼働させるために、20 年以上かけてまさにその基盤を構築してきました。現在、これは Google のエージェント型データベース アーキテクチャの基盤となっています。

本番環境に影響を与えることなく、エージェントにライブデータを提供

AI を活用した開発に取り組むすべての組織が、ある共通のジレンマに直面しています。それは、ビジネスを支えるシステムを危険にさらすことなく、エージェントに対して本番環境のライブデータへの完全なアクセス権をどのように付与するか、という問題です。これまでは、アプリケーションのニーズではなく、アーキテクチャの制約によって、その選択を強いられていました。エージェントにデータベースへの直接アクセスを許可すると、ミッション クリティカルなシステムを、予測不可能な負荷、深刻なリソース競合、本番環境の停止のリスクにさらすことになります。

これら 3 つの原則に基づいて構築されたアーキテクチャは、こうした妥協を完全に排除します。エージェントは、1 秒未満の更新頻度を保った本番環境のライブデータに基づいて推論します。そして、すべてのインデックス、ベクトル、全文検索、空間検索、SQL の全機能など、エンジンのフル機能を 1 ミリ秒未満の I/O で自由自在に駆使できます。このアーキテクチャは、エージェントの要求に応じて数千もの分離されたノードに動的にスケールし、処理が終了したらゼロにスケールダウンします。その間も、コア トランザクション ワークロードは影響を受けることはありません。共有コンポーネントも、共有割り当ても存在せず、連動障害のリスクもないからです。エージェントは、ビジネスの継続性を損なうことなくビジネスにイノベーションをもたらすことができます。

この優れた特性が、本番環境データを参照する他のすべてのシステムにも適用されます。レポート、分析、アプリケーションは、本番環境を危険にさらすことなくライブデータを自由に読み取ることが可能になり、50 年間にわたってオペレーショナル データベースを縛り続けてきた制約が、ついに解消します。

企業の記録システム内のデータは、その企業にとって最も重要なものです。この基盤の上に構築されたそのデータは、ついに最大限に活用できるようになります。

制約なきデータベースへ。

詳細については、ドキュメントページをご覧ください。こちらから登録すると、今すぐご利用いただけます。

- データベース エンジニアリング担当バイス プレジデント、Amit Ganesh

- データベース、エンジニアリング担当バイス プレジデント、Sailesh Krishnamurthy

AlloyDB がエージェント向け PostgreSQL を提供: ワークロードを完全に分離し、エージェント規模でリアルタイム データを処理

詳細を表示

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

 

ミッション クリティカルな運用データベースは企業にとってなくてはならないものであり、パフォーマンスの低下は許されません。しかし従来のアーキテクチャでは、わずか数個のエージェントが高密度の推論ループを実行しただけで、予測不可能なクエリのバーストが発生して簡単に過負荷状態に陥ります。

このたび、AlloyDB でエージェント向け PostgreSQL（プレビュー版）の提供を開始したことをお知らせいたします。これにより、ミッション クリティカルなシステムのパフォーマンスを損なうことなくリアルタイムのデータアクセスを行うことが可能になります。AlloyDB は、サンドボックス化されたデータベース インスタンスを数秒でプロビジョニングしてスケールすることでエージェントによる突発的なクエリの急増に対応し、ワークロードの完全な分離を可能にします。インスタンスはエージェントが終了すると自動的にスピンダウンするため、数個でも数百万個でも、エージェントをあらゆる規模で費用対効果よく実行できます。この発表による変更点は以下のとおりです。

  • AlloyDB に、秒単位で同期された本番環境の最新データに読み取り専用でアクセスできる数千のサーバーレス データベース インスタンスへと PostgreSQL をスケールさせるように設計されたエージェント向けデータベース アーキテクチャが搭載されます。これらのインスタンスは常時、本番環境ワークロードがアクセスするプライマリ、スタンバイ、リードレプリカのインスタンスから完全に分離されています。

  • これらの各インスタンスは、Google が提供するエクサバイト規模の分散ストレージ システムである Colossus の統合ストレージ レイヤを基盤とするデータベース内のリアルタイム データにアクセスします。これにより、エージェントはミリ秒未満の I/O とテラビット/秒の集約スキャン スループットを実現し、秒間 300 万以上のクエリにも対応できます。

  • これらのインスタンスは完全な AlloyDB PostgreSQL エンジンを備え、すべてのインデックス、SQL の全機能、包括的なベクトル検索、全文検索、空間検索へのアクセスを提供します。さらに、複雑な ETL パイプラインを構築しなくても、エージェントは BigQuery と Spark を活用してレイクハウス分析を実行できます。

  • これらのインスタンスはエージェントがタスクを完了するとすぐにゼロへとスケールダウンされるため、料金はアクティブな推論ループに対してのみ発生し、クラウド費用を削減できます。

Google は、この AlloyDB for PostgreSQL により高度なベクトル演算、ML 推論、基盤モデルのインテグレーションを 100% PostgreSQL 互換のエンジンに直接組み込み、エージェント向けエンタープライズ リレーショナル データベースの分野における先駆けとなりました。AlloyDB for PostgreSQL は Google Cloud のセキュリティ機能と緊密に統合されており、静的パスワードに代わる IAM 認証の使用、VPC Service Controls を介したトラフィック分離、顧客管理の暗号化と監査の提供によりデータを保護します。この機能とエージェント アーキテクチャによるスケーラビリティを組み合わせて提供する AlloyDB は、エンタープライズ グレードの優れたエージェント PostgreSQL サービスとなっています。

プレビュー版をご利用になるには、こちらからお申し込みください。

重要である理由

エージェントの時代となった今、企業による AI の使用方法は単一のコパイロット エージェントとのやり取りから、数百万のエージェントが同時に連携するネットワークへと急速に移行しています。これらのエージェントが一斉にクエリを実行してデータベースを操作すると、突発的なトラフィックの急増によってコア データベースが過負荷に陥り、ビジネスを運営する基幹システムと競合してしまう可能性があります。

エージェントがワークフローを効率的に実行するためには、B ツリー、ベクトル、テキスト、空間の各インデックスを活用して、高度な分析とリアルタイムの本番データに対する低遅延アクセスの両方を実現する必要があります。新興のアーキテクチャはオブジェクト ストレージの上に配置されたページ キャッシュ レイヤを使用しますが、これにはスケーリングと費用に関する課題があり、本番環境システムの安定性が損なわれる可能性があります。

加えて、分析のために本番環境のデータを解放すると運用アクセスにパフォーマンスのボトルネックが生じ、エージェントが本番環境にリリースされた瞬間からミッション クリティカルなデータベースがリスクにさらされるという、難しいトレードオフも発生します。これらは、データベース ストレージに従来のオブジェクト ストアを使用して問題を解決しようとするアプローチです。分析アクセスが可能になるので一部のエージェントはこれを役立てることができますが、基盤となるデータベースの処理速度が本番環境のワークロードに対して遅すぎ、I/O レイテンシが最大で 10 倍悪化します。ページ キャッシュ レイヤがあっても、一時しのぎ程度にしかなりません。キャッシュ自体の速度が依然として十分に速くないうえに、エージェント ワークロードによって簡単に飽和してしまうスケーラビリティのボトルネックを抱えることになります。

アクティブなマルチエージェント システムが高密度な推論サイクルを実行すると、高度に並列化された予測不可能なクエリのバーストが発生してこれらのキャッシュ レイヤを圧倒し、ミッション クリティカルな本番環境システムが、エージェント起因のサービス停止に対して無防備な状態になります。その結果、このアーキテクチャでは運用ユースケースの全領域が実行不可能となり、企業はライブのエンタープライズ データが持つ、AI による変革の力をビジネスに活用する機会を失うことになります。

AlloyDB 独自の PostgreSQL エージェント アーキテクチャ

Google はこれとは異なるアプローチを採用しました。AlloyDB は、AI 時代に特化して設計されたエージェント向けデータベース アーキテクチャを提供し、4 つの主要な差別化機能を備えています。

  • 人工的なボトルネックのない、1 ミリ秒未満の I/O レイテンシ: 業界をリードする AlloyDB のトランザクションおよびクエリ処理性能と、Google の地球規模の Colossus ストレージ インフラストラクチャに支えられた低レイテンシのオブジェクト ストレージが組み合わさったこのアーキテクチャは、エージェント向けの大規模な共有ストレージ プレーンを提供します。ミリ秒未満の I/O と 1 秒あたり 1 テラビットを超える集計スキャン帯域幅を実現しているため、エージェントが最新の運用データに対して直接、集中的に読み取りクエリとベクトル検索を実行しても問題なく処理できます。

  • 本番環境のワークロードから完全に分離しつつ、需要に合わせてスケーリング: AlloyDB は、最新の本番環境データに対してサンドボックス化されたデータベース インスタンスを数秒で動的にプロビジョニングすることでスケールします。エージェント同士が運用リソースを奪い合う従来のアーキテクチャとは異なり、エージェント データベース コンピューティングはプライマリ データベース クラスタから完全に分離されています。そのため、エージェントが高密度で予測不可能な推論ループを実行しても本番環境のパフォーマンスが低下することはありません。これらの堅牢な安全ガードレールと、エンタープライズ グレードのガバナンス、きめ細かいアクセス制御が組み合わさっているため、アクティブなエージェント ループで分析クエリ、ベクトルクエリ、運用データのポイント ルックアップをシームレスに組み合わせ、本番環境データに対して PostgreSQL の性能を制限なく最大限に活用することができます。

  • 従量課金制: エージェントのアクティビティは一般的に、短時間のうちに大量のクエリが同時送信され、それが終わると非アクティブな期間が続くという特徴があります。このような急増に備えて専用のリードレプリカをプロビジョニングした場合、高価なインフラストラクチャを 24 時間体制で維持する必要があります。費用対効果の高い方法で大規模なエージェント グループをサポートし、プロビジョニングしたシステムがアイドル状態のままでコンピューティング オーバーヘッドを発生させることを避けられるよう、エージェント AlloyDB インスタンスは迅速にスケールして秒間数百万のクエリに対応できます。また、柔軟な従量課金制の料金モデルによって自動的にゼロへとスケールさせることができます。

  • ETL 不要のネイティブ レイクハウス統合: 本番環境データはすべて、Google Cloud のボーダーレス レイクハウスとネイティブに統合されます。そのため、エージェントは BigQuery と Lightning Engine for Apache Spark に対して連携クエリを実行し、大規模なレイクハウス データセットと、AlloyDB の秒単位で更新される最新のトランザクション データを結合できます。これにより、壊れやすいバッチ ETL パイプラインを構築して維持する必要がなくなり、自律型エージェントは最新の運用状態と、レイクハウスに格納されている過去のコンテキスト データの両方に即座にアクセスできます。

「サプライ チェーンの自律性が高まるにつれ、当社のプラットフォームでは、数千もの施設にわたる複雑な物流ワークフローを調整するリアルタイムのトランザクション インテリジェンスが欠かせなくなっています。AlloyDB の新しいエージェント向け PostgreSQL アーキテクチャは、当社にとって大きな転機となりました。現在では、コアのトランザクション処理には一切影響を及ぼすことなく、同時に連携して動作するエージェントのネットワークをデプロイし、在庫データや注文データを 1 秒未満の鮮度で分析できるようになっています。このアーキテクチャにより、次世代のエンタープライズ サプライ チェーン AI を支えるために必要な分離、スピード、費用対効果を実現できました。」 - Manhattan Associates、エグゼクティブ バイス プレジデント兼最高技術責任者、Sanjeev Siotia 氏

提供状況

AlloyDB の PostgreSQL for Agents は現在、プレビュー版としてご利用いただけます。

詳細については、ドキュメントページをご覧ください。ご利用を開始するには、こちらからお申し込みください。

AI 駆動で進める、クラウド移行と運用のこれから。AI-Ready Infra & DB Summit '26

詳細を表示

こんにちは、Google Cloud Japan です。

AI がシステムを使うようになると、アクセスは昼夜を問わず増え、データには検索と生成の両方が求められます。AI を業務で使い続けるには、それに耐えるインフラとデータベースへの移行が欠かせません。

Google Cloud は 2026 年 10 月 16 日（金）に AI-Ready Infra & DB Summit '26 を開催します。最新のクラウド動向調査の結果を発表するほか、Google Cloud のインフラとデータベースの最新情報を、お客様の事例とともにお届けします。調査からコード移植までを AI 駆動で進めるクラウド移行の方法も、あわせて解説します。会場は Google 渋谷オフィスで、オンライン配信もあります。

▶ AI-Ready Infra & DB Summit '26 に申し込む

基調講演のテーマは「AI が使う基盤、AI で作る基盤」

基調講演には、ロッテホールディングスの橋本 桂祐 氏とマクロミルの宮坂 雅輝 氏をお迎えし、Google Cloud の安原 稔貴とともに登壇いただきます。コンピュート、ネットワーク、ストレージ、データベースの各領域の最新情報とあわせて、既存の基盤をどこから見直すべきか、その道筋を示します。

お客様 4 社が、基盤づくりと移行の実例を紹介

お客様セッションには、業種も規模も異なる 4 社が登壇します。

  • GovTech 東京: 都民 1,400 万人が利用する東京都公式アプリ「東京アプリ」で、将来の利用拡大や AI 活用まで見据えて、後から変えにくい技術をどう選んだのかをお話しします。
  • ロッテ: データと AI の基盤づくりと重点ユースケースの創出を同時に進め、TAP (Tech Acceleation Program) を活用して事業部門と一体で内製開発を進める取り組みをお話しします。
  • マクロミル: クラウド コストとレガシー構成の保守リスクを抱えたアンケート配信システム「TRANS-AM」を、Google Cloud へ移管する計画を紹介します。
  • スタメン: 1,400 社、150 万ユーザーが使う TUNAG を、AWS から Google Cloud へ移行中です。AI Skills を使い、少人数で進める具体策をお話しします。

Google Cloud が、AI 駆動型の移行と運用のアプローチを紹介

Google Cloud のスペシャリストが、移行と運用の各工程での AI の使い方を、具体的な手順とあわせて解説します。

  • Gemini と Skills で進めるクラウド移行: 移行のノウハウを Skills にまとめて Gemini に読み込ませ、現行環境の調査からコード移植と差分検証まで進める方法です。実際に使った Skills と成果物をお見せします。
  • AI で進めるデータベース移行: 手間のかかる異種データベースへの移行で、AI が手作業をどこまで減らせるかを紹介します。
  • クラウド ネットワークの見える化: 障害の原因がアプリかネットワークかを切り分ける手法を、AI を使ったトラブルシューティングとあわせて解説します。

このほか、Jagu'e'r によるパネルトーク、Datadog、GitLab、KDDI アイレットによるセッションも予定しています。

会場に来た方だけの特典も

渋谷の会場にお越しの方には、Google Cloud オリジナルの特典を用意しています。お渡しには条件があり、詳しくは当日ご案内します。終了後の懇親会にも、ぜひお立ち寄りください。

<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="blog-present-2436x1000" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/blog-present-2436x1000.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

AI-Ready Infra & DB Summit '26 のイベントページ からお申し込みください。

基盤を作る方も、運用する方も、移行を任された方も、会場とオンラインでお会いしましょう！

AI エージェントを現場実装する 2 日間、Agentic AI Summit '26 Fall

詳細を表示

こんにちは、Google Cloud Japan です。

AI エージェントは、動くものを作るところまでは驚くほど早く進みます。難しいのはその先です。

エンジニアにとっては本番で任せられる品質の担保、情報システム部門にとってはセキュリティとガバナンス、事業部門にとっては全社への定着と成果づくりが次の課題になります。

Google Cloud は 2026 年 10 月 29 日（木）と 30 日（金）に Agentic AI Summit '26 Fall を開催し、それぞれの課題に取り組んできた企業の知見をお届けします。会場はベルサール渋谷ガーデンで、オンラインでも配信します。

▶ Agentic AI Summit '26 Fall に申し込む

Day 1 は全社展開の実例がそろう

初日は、Gemini Enterprise を中心に、AI エージェントを社内で使われる状態にするまでの進め方がテーマです。基調講演には三菱 UFJ 銀行をはじめ 2 社のお客様が登壇し、Gemini Enterprise を選んだ理由とその背景を語ります。

ブレイクアウトは全社展開の実例が中心です。

  • ソニー: 非エンジニア約 70 名の経営企画部門が、2 桁の業務アプリを本番稼働させるまでの記録です。定着や社内調整でのつまずきも語ります。
  • 日本テレビ: 担当者の経験と勘に支えられてきた番組づくりに客観性を加え、「ヒットの再現性」を高める AI エージェント「ミカタッチAI」の取り組みです。
  • 足立区: 議会答弁 AI エージェントの実装プロセスと、区民の声にすばやく応えるための取り組みです。

ほかにも、大阪ガスの内製 AI 駆動開発基盤や、営業担当に次の一手を届ける Hajimari のエージェント開発があります。そして、Googler Cloudのセッションでは、Tokenmics（適切なモデルを利用する際のコスト効率向上について）や、AI エージェントの統制とモデル選択を両立するエージェント基盤の設計、Microsoft 365 などの既存環境とつないで Gemini Enterprise を全社に定着させる進め方などがあります。

他社の事例を一気に見るならピッチ コンテスト

Day 1 の 13:30 からは、第 6 回 AI エージェント事例アワードのピッチ コンテストを開催します。生成 AI で自社の課題を解いたファイナリストが、その取り組みをステージで発表します。

<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="finalist (1)" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/finalist_1.max-1000x1000.jpg" />
    
    </a>
  
</figure>


  </div>
</div>

ファイナリストは、KDDI アイレット、コクヨ、Contrea、千趣会、テレビ朝日、ベンチャーサポート税理士法人と SoLabo、三菱食品、Ubie の 8 チームです。

審査員には、次の 4 名を迎えます。

  • 漆原 茂 氏（ULS コンサルティング株式会社 取締役会長）
  • 酒井 真弓 氏（ノンフィクション ライター、Jagu'e'r アンバサダー）
  • 深津 貴之 氏（株式会社 THE GUILD 代表取締役）
  • 森 正弥 氏（株式会社博報堂 DY ホールディングス 執行役員 Chief AI Officer）

MC は、PIVOT などで MC とプロデューサーを務め、J-WAVE のニュース情報番組「JAM THE PLANET」のパーソナリティとしても活躍する野嶋 紗己子 氏です。

アワードの詳細は AI エージェント事例アワードの開催概要 をご覧ください。

Day 2 は丸ごとエンジニア向け

2 日目は、AI エージェントを構築、デプロイ、運用するための Google Cloud のプラットフォームを中心に、エージェント開発とバイブコーディングのセッションが並びます。

基調講演には Antigravity のエンジニアや、エージェント開発のエキスパートが登壇し、Sakana AI、荏原製作所、エイベックスがエージェントを現場で動かしている取り組みを話します。

ブレイクアウトは本番運用の話が中心です。

  • AI エージェントを本番に載せるアーキテクチャ設計: 同じ入力でも同じ答えが返るとは限らない相手を、どうテストし、どこでリリース可否を決めるか。複数エージェントの責任の境界、コストとレイテンシの制約まで扱います。
  • コロプラ: Agent2Agent プロトコル (A2A) の作法だけを接続境界に決め、各部署のエージェントを作り直さずに Agent Development Kit (ADK) 製のハブへつないだ全社基盤です。
  • 損保ジャパン: 全自動エージェントをあえて捨て、人が承認する場所を設けて、実験サイクルを 1 週間から 1 日に縮めました。

ほかにも、ライブデモと agy teamwork まで紹介する Antigravity 徹底解説、メルカリの AI PDLC と TPU 活用、エージェントの推測を減らすデータ基盤の設計、Google Cloud のテクニカル サポートチームの AI 活用などがあります。

作って試すなら Builder Day

Day 2 には、参加型の Builder Day を並行開催します。90 分の座学の後、Google Cloud 上で Antigravity などを使い、AI エージェントやアプリを作るミニハッカソンに挑戦できます。

Google Cloud のデベロッパー リレーションズのメンバーがメンターにつきます。

定員制なので、参加希望の方は登録フォームで Builder Day への参加を忘れずに選択してください。

<figure class="article-image--wrap-small
  
  ">

  
  
    
    <img alt="t-shirt (1)" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/t-shirt_1.max-1000x1000.png" />
    
    </a>
  
</figure>







  <h3><b>会場に来た方だけの特典も</b></h3><p>各フロアのデモブースでは、最新の生成 AI 製品やお客様の事例に触れられます。現地参加の方には、抽選でオリジナル T シャツのプレゼントもあります。</p>
</div>

エージェントを作る方も、守る方も、社内に広げる方も、渋谷の会場でも、オンラインでもお待ちしています！

▶ Agentic AI Summit '26 Fall に申し込む

前日
Archive
翌日