Back to Archive

GCP News - 2026-10-23

2026-10-23
最終更新: 2026-10-24 09:16:12 JST

AI による概要

9 記事

この日は 8 件 (重複を除くと 7 件) で、Google Cloud 上の Claude のデプロイ方式が増えたこと、Knowledge Catalog のコンテキスト拡充、そしてエージェントからのデータアクセスが中心でした。Google Cloud 上の Claude モデルについて、Anthropic が管理するデプロイの選択肢が一般提供となりました。従来の Google が管理するデプロイとあわせて、AI のワークロードを Google Cloud に集約しながら運用方法を選べるようにするものです。どちらの選択肢でも同じフロンティアモデルが初日から使え、価格も同じで、課金は Google Cloud にまとまります。違いはデータ処理者が誰になるか、そして新しい Claude プラットフォームの機能が公開された時点で使えるかどうかの 2 点です。Anthropic が管理する方式では Claude モデルとプラットフォーム機能に初日からアクセスできます。データ基盤では、エージェント向けのコンテキストエンジンである Knowledge Catalog に、自己学習型のコンテキスト拡充と刷新された Knowledge Studio がプレビューで追加されました。既存の Gemini による拡充の上に、エージェントと利用者のやり取りを分析して不足を見つけ、業務上のコンテキストを正確かつ最新に保ちます。Knowledge Studio はコンテキストエンジニアやデータスチュワードのための新しい司令塔で、自社のデータ資産を対話的に探索し、視覚的なコンテキストグラフをたどり、グラフへの変更案を利用者やエージェントに公開する前にレビューできます。エージェントの能力は、組織全体の定義・ルール・関係といったコンテキストの質で決まるため、コンテキストの整備がエンタープライズのエージェント活用で最も重要な分野のひとつになったという位置づけです。日本のブログでは 4 本が公開されました。1 本目はサイバーエージェントの事例です。広告領域での活用を想定した社内向けクリエイティブ生成 AI プラットフォーム「AI SCREAM」を Google Cloud 上に約 3 年運用しており、Veo・Imagen・Nano Banana (Gemini Flash Image / Pro Image など) といった社内審査を通った複数のモデルを統一された UI から横断して使えます。2023 年 10 月に仮想マシン 1 台で小さく始め、2025 年には Agent Development Kit を使ったエージェント基盤を足して、画像を作る「道具」から制作ワークフローを支援する「仕組み」へ進めたという経緯で、Cloud Run や Pub/Sub を使っています。出発点は、生成 AI を使いたくても高度な専門知識が要るためエンジニア以外のクリエイターや営業担当者が手を出せなかったことだったとされています。2 本目は MCP ツールボックスの Java SDK v1.0 です。N 個のモデルと M 個のデータソースがあると N × M 本のカスタム接続を作って守って維持しなければならないという統合のボトルネックに対し、MCP を AI オーケストレーションの USB Type-C のような共通インターフェースとしてモデルとデータソースを切り離す位置づけで、Java の成熟したアーキテクチャによって高い同時実行性、厳格なトランザクション整合性、堅牢な状態管理を備えた型安全なエージェントオーケストレーションを実現します。3 本目は Gemini とボーダーレス Lakehouse の連携です。複数のクラウド・SaaS・オンプレミスに分散したデータへのアクセスと推論がボトルネックになるという前提で、Lakehouse カタログ連携を通じて Databricks Unity Catalog や Snowflake Horizon といったデータソースへのアクセスを Gemini から直接設定できるようになりました (プレビュー)。業務利用者は自然言語でクラウドをまたいだレコードをクエリでき、AI エージェントは同じデータを根拠に推論しコードを生成でき、いずれもデータを移動せずに行えます。4 本目は Alteryx One Live Query と BigQuery の連携です。ブラウザベースの環境でコードを書かずに高度なデータパイプラインを組み、安全な SQL プッシュダウンによって変換のロジックをネットワーク越しにデータを動かさずウェアハウス内で実行します。請求書 PDF の処理のようにドキュメントを多用するワークフローで効果が大きく、BigQuery のガバナンスとセキュリティを保ったまま Gemini などのモデルをオーケストレーションして PDF や画像から情報を抽出できます。リリースノートでは、Cloud Monitoring の Ops Agent 2.73.0 が、システムのルート証明書に関わる Go の脆弱性 CVE-2026-111943 の修正を含めて公開されました。セキュリティ速報では GCP-2026-071 が公開されました (2026 年 10 月 23 日公開、CVE-2026-111943)。eMudhra (emSign) の複数の中間認証局 (CA) の秘密鍵が侵害されたもので、これらの認証局を信頼している未修正の TLS クライアントとコンテナランタイムは、外部との TLS 接続において能動的なネットワークの中間者 (MitM) 攻撃による傍受とトラフィックのなりすましを受けるおそれがあります。

主要トピック

  • モデル: Google Cloud 上の Claude モデルに Anthropic 管理のデプロイ方式が追加され GA。Google 管理の方式と同じモデル・同じ価格・Google Cloud での課金で、違いはデータ処理者と新しい Claude プラットフォーム機能への初日アクセス

  • データ基盤: Knowledge Catalog に自己学習型のコンテキスト拡充と新しい Knowledge Studio がプレビュー。エージェントと利用者のやり取りから不足を見つけ、変更案を公開前にレビューできる

  • 国内: サイバーエージェントの AI SCREAM。2023 年 10 月に VM 1 台から始め、Cloud Run と Pub/Sub で約 3 年運用。2025 年に ADK のエージェント基盤を足して制作ワークフロー支援へ

  • 国内: MCP ツールボックス Java SDK v1.0。N × M のカスタム接続という統合のボトルネックに対し、MCP を共通インターフェースとして型安全なエージェントオーケストレーションを提供

  • 国内: Gemini とボーダーレス Lakehouse の連携がプレビュー。Databricks Unity Catalog や Snowflake Horizon へのアクセスを Gemini から直接設定し、データを動かさずにクエリと推論ができる

  • 国内: Alteryx One Live Query と BigQuery の連携。SQL プッシュダウンでウェアハウス内実行し、請求書 PDF などから Gemini で情報を抽出

  • 運用: Ops Agent 2.73.0 がシステムのルート証明書に関わる Go の脆弱性 CVE-2026-111943 を修正

  • セキュリティ速報: GCP-2026-071 (CVE-2026-111943)。eMudhra (emSign) の中間 CA 秘密鍵が侵害され、未修正の TLS クライアントとコンテナランタイムが MitM のおそれ

AI (Claude Opus 5) が生成 · 2026-10-24 18:44:18 JST

Google Cloud Release Notes

October 23, 2026

Cloud Monitoring

Fixed

Ops Agent version 2.73.0 includes patches for a Go vulnerability involving system root certificates, CVE-2026-111943. For more information, see Ops Agent 2.73.0 notes.

Google Cloud Blog

Introducing new self-learning context enrichment in Knowledge Catalog

詳細を表示

Today, we’re launching self-learning context enrichment (preview) and a reimagined Knowledge Studio experience (preview) in Knowledge Catalog, Google Cloud’s context engine for agents. Building on Knowledge Catalog's existing Gemini-powered enrichment, self-learning enrichment analyzes agent and user interactions to find gaps and keep your business context accurate and current. Knowledge Studio is the new command center for context engineers and data stewards to explore their data estate conversationally, navigate a visual context graph, and review proposed changes to the context graph before they are published to their users and agents.

An agent is only as good as the organization-wide definitions, rules, and relationships it reasons over — the context, as it were. That’s why curating context has become one of the most important disciplines in enterprise agentic capabilities. Today, most of that work happens by hand. Context engineers write prompts and mappings agent by agent, while data stewards try to manually keep definitions current across thousands of assets. But this breaks down as organizations move from a handful of agents to thousands, and eventually millions.

Knowledge Catalog’s Gemini-powered self-learning enrichment turns that manual upkeep into a continuous feedback loop. By analyzing agent and user interactions, it pinpoints missing or outdated context and pulls verified definitions from playbooks, code repositories, and business documents into governed, reusable context sets. Then, with optimized search, every agent gets precisely the right context it needs instead of reasoning over bloated prompts and raw schemas, and benefits from shared learning across your organization. Knowledge Catalog makes AI agents nearly 4X more accurate, with up to 33% lower latency, and using up to 75% fewer tokens, based on internal benchmarks.

Keep context current with Gemini-powered self-learning enrichment

Consider a simple question to a Gemini agent: "What was the net revenue in EMEA last quarter?" Answering it correctly requires knowing how your company defines net revenue, which tables hold the bookings, and how they join, yet that knowledge is typically scattered across a finance playbook in Google Docs, a data model in GitHub, and a Confluence page. Static catalogs expect subject matter experts to manually capture and update business definitions, metrics, and other context upfront so that an agent can effectively query the right data. However, in reality, experts rarely have the time to document every asset, and the moment the finance team revises how partner credits are treated next quarter, static definitions fall behind and every agent with a hardcoded formula starts giving the wrong answer.

Knowledge Catalog’s enrichment capability acts where you already keep your business knowledge: across your team’s every doc, repo, and table. It connects to your structured data across first-party and third-party sources and unstructured data in Cloud Storage, Google Workspace, GitHub, Confluence, and SharePoint. It finds, extracts, assembles, and maintains that business knowledge for you, linking those unstructured sources like playbooks and wikis and their context to your structured metadata in Knowledge Catalog like tables and schemas to make your structured data far more discoverable and actionable. On demand or on a schedule, it proposes business definitions, table and column descriptions, join relationships, golden queries, and task-specific agent instructions, each with source citations and a confidence score. On every run, it detects what changed at the source, retires obsolete definitions, and flags conflicts for review.

It learns from both your user and agent interactions. You can configure enrichment to analyze interaction traces from Gemini agents, Conversational Analytics in BigQuery, or your custom agents while redacting PII, and it pinpoints where agents struggled, such as ambiguous column lookups, ungrounded metrics, missing definitions, or users rephrasing the same question. It then finds the authoritative answer and stages a fix, so the same mistake doesn't happen twice. That's how context engineering keeps pace with millions of agent interactions, freeing experts to review changes instead of writing them from scratch.

<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-explore-search" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/1-explore-search.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Configuring an enrichment task with connected sources, evaluation, and self-learning</p></figcaption>
  
</figure>


  </div>
</div>

Automation doesn't mean giving up control. You can choose to enable or disable auto-publishing at any time, and set the exact confidence score (for example, 85%) at which proposed changes are automatically approved. Anything below your threshold, along with sensitive updates such as deletions, become a Change Request for a steward to approve, edit, or reject. You can also provide your own evaluation set to test proposed updates end to end. Every change is logged with full provenance and can be reverted. And of course, Google never uses your data to train its models.

<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-enrichment-task" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/2-enrichment-task.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Reviewing enrichment proposals, confidence scores, and change diffs before publishing</p></figcaption>
  
</figure>


  </div>
</div>

Set the right context for each audience with context sets

By design, an enterprise context graph is quite broad, but for a given task, both agents and users often only need the right, trusted segment of it. Knowledge Catalog achieves that with context sets — curated, governed subsets of the context graph that contains the definitions, metrics, join logic, and golden queries for a specific domain, team, agent, or group of end users. For instance, a sales agent can be bound to the Sales context set, while a finance analyst's assistant can be bound to the Finance context set. Because "net revenue" can legitimately mean different things to each group, every domain maintains its own definitions in the same catalog. However, agents don't have to be bound to a single set; with search in Knowledge Catalog, an agent can also dynamically search and find the right context set for any given task.

Context sets also provide built-in data governance and fine-grained access control. Access to each context set is managed with IAM, so stewards decide which agents and users can read, use, or edit it. Agents only retrieve context from the sets they're authorized to use, and access to the underlying data continues to follow your existing permissions. Every update is traceable, and reversible, and because context sets build on the Open Knowledge Format (OKF), you can import an OKF bundle to become a context set and export it back out as OKF so your context stays portable.

<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-review-changes" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/3-review-changes.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Approved enrichments published to a governed context set</p></figcaption>
  
</figure>


  </div>
</div>

Explore and govern it all in Knowledge Studio

All of these capabilities come together in the reimagined Knowledge Catalog experience, built for context engineers and data stewards who curate and govern context for agents.

<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-context-set" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/4-context-set.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Navigating the context graph visually in Knowledge Studio</p></figcaption>
  
</figure>


  </div>
</div>

The new Knowledge Studio turns Knowledge Catalog from a repository of static inventory into an interactive command center, allowing you to:

  • See context coverage at a glance: Navigate a visual map of your cross-cloud data estate, from operational databases and warehouses to semantic models, context sets, and documentation.
  • Explore context conversationally: Ask business questions in natural language, traverse relationships across your enterprise context graph, and see exactly how agents reason over your metadata.
  • Review and validate enrichments in one place: Inspect each proposed change, source citations, and confidence score. Test context sets against real questions, and approve, edit, or roll back change requests with software-style version control.
  • Monitor enrichment runs: Track each enrichment task's schedule, results, token usage, and run duration, and get notified by email when a run completes.

Get started

    <img alt="How Knowledge Catalog’s self-learning enrichment grounds enterprise AI agents" src="https://img.youtube.com/vi/qeWzgLGSkls/maxresdefault.jpg" />
  
  <svg class="h-c-video__play h-c-icon h-c-icon--color-white" xmlns="http://www.w3.org/2000/svg">
    <use xlink:href="#mi-youtube-icon" xmlns:xlink="http://www.w3.org/1999/xlink"></use>
  </svg>
</a>


  <figcaption class="article-video__caption h-c-page">
    
      <h4 class="h-c-headline h-c-headline--four h-u-font-weight-medium h-u-mt-std">Watch the demo: How Knowledge Catalog’s self-learning enrichment grounds agents</h4>
    
    
  </figcaption>

These features will be rolled out to customers in the next few weeks. Sign up to request immediate access and visit the documentation for step-by-step guidance.

Expanding Claude availability and deployment choice on Google Cloud

詳細を表示

Every organization has unique requirements for building and scaling generative AI. At Google Cloud, we are committed to giving developers model choice and architectural flexibility to run workloads however they need.

Today, we’re announcing the general availability of an Anthropic-managed deployment option for Claude Models on Google Cloud. This gives teams more choice in how they run their models, helping them consolidate AI workloads on Google Cloud alongside our existingGoogle-managed deployment option. 

Both options deliver the same frontier models on day zero, the same pricing, and the same Google Cloud billing. The difference comes down to who acts as your data processor and whether you need access to the new Claude platform features when they launch:

[NEW] Claude Models on Google Cloud (Anthropic managed)

Delivers day-zero access to Claude models and Claude Platform features such as Claude Managed Agents (beta), skills, and code execution. Anthropic operates the stack as the data processor on Google Cloud infrastructure under Anthropic’s terms of service, while organizations authenticate with Google Cloud IAM, maintain Cloud Audit Logging, and consolidate spend under their existing Google Cloud billing and eligible commitments.

Learn more: Claude Models on Google Cloud (Anthropic-managed).

Claude Models on Google Cloud (Google managed)

Continues to deliver day-zero access to the latest Claude models with strict governance, compliance, and sovereignty requirements. Google Cloud operates as the data processor under existing customer agreements, providing VPC Service Controls, Customer-Managed Encryption Keys (CMEK), and data residency in the U.S., EU, and APAC. New Claude Platform features roll out over time as they are integrated into the Google-managed infrastructure. Teams also benefit from native integrations with Google Cloud services like BigQuery and Model Armor, along with standard billing and eligible commitment drawdown. 

Learn more: Claude Models on Google Cloud (Google managed)

Comparing deployment options

 

Feature

Anthropic-managed

Google-managed

Model availability

Available on Day 0

Available on Day 0

First-party tools and betas 

Available on Day 0

Available once integrated into the Google-managed infrastructure

Data processor and terms

Anthropic (under Anthropic’s Commercial Terms)

Google Cloud (under existing Google Cloud customer agreements)

Pricing & commitments

Standard pricing (draws down eligible Google Cloud commitments)

No matter how you choose to deploy, you can access Anthropic's latest frontier models on Google Cloud, including Claude Fable 5.1, Sonnet 5.5, Haiku 5.5, and Opus 5.5, with new platform features available immediately on the Anthropic-managed option and rolling out on the Google-managed option once integrated. This gives developers the full spectrum of reasoning, coding, and multi-modal capabilities with Google Cloud IAM and Marketplace billing. Get started.

Google Cloud Japan Blog

Gemini のイノベーションで、ボーダーレス Lakehouse をエージェントの時代へ導く

詳細を表示

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

企業が AI の利用を試験運用的な chatbot から自律型エージェントへと移行するにつれ、チームは重大なボトルネックに直面しています。それは、複数のクラウド、SaaS プラットフォーム、オンプレミス システムに分散したデータへのアクセスと、そのデータに基づく推論です。AI エージェントを真の「アクション システム」に変えるには、データ移動に伴うセキュリティ リスクを負うことなく、ペタバイト規模の推論を処理できる基盤が必要です。先週開催された Gemini at Work イベントでは、Gemini がビジネス ワークフローの変革にどのように役立つかをご紹介しました。皆様がエンタープライズ データを活用してエージェントを強化できるよう、Gemini とボーダーレス Lakehouse の新たな連携について詳しく解説し、データ資産全体にわたって機能するエージェントの構築、保護、スケーリングを支援します。

Gemini を通じて Google Cloud の外部にあるデータにアクセスする

ボーダーレス Lakehouse の真価は、Gemini をフロントドアとして組織を変革するために構築するエージェントを通じて発揮されます。Gemini との新たな連携により、事前構成されたデータやボーダーレス Lakehouse に保存されたデータを、Gemini に直接取り込んで活用できるようになりました。現在プレビュー版として提供されているこの機能により、Gemini から直接、Lakehouse カタログ連携を通じて Databricks Unity Catalog や Snowflake Horizon などの新しいデータソースへのアクセスを設定できるようになります。

これで、ビジネス ユーザーは自然言語を使ってクラウド全体に分散して存在するレコードをクエリできるようになり、AI エージェントは同じデータを根拠として推論を行い、コードを生成できるようになりました。これらはすべて、データを移動することなく実行できます。ボーダーレス Lakehouse 全体にわたり 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="image1" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/image1_HJqokGb.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>ビジネス ユーザーが呼び出した Gemini エージェントは、BigQuery と Databricks Unity Catalog に格納されているデータにアクセスし、包括的なレポートを提供するとともに、自然言語を使用して分析情報を取得できます。</p></figcaption>
  
</figure>


  </div>
</div>

ボーダーレス Lakehouse の進化

このたび、Gemini との新しいネイティブ連携に加えて、ボーダーレス Lakehouse でデータ基盤を強化するために今年初めに導入したいくつかの機能の一般提供が開始されたことをお知らせします。

  • AWS および Azure 向けの Cross-Cloud Interconnect とクロスクラウド キャッシュのサポート

  • BigQuery での Apache Iceberg V3 仕様のサポート

  • BigQuery と Managed Service for Apache Spark の両方における Apache Iceberg テーブルの読み取り / 書き込みの相互運用性

  • Lakehouse ランタイム連携を使用した、AWS Glue、Databricks Unity Catalog、Snowflake Horizon カタログとの双方向キャッシュ

  • Knowledge Catalog とのインテグレーション

  • Salesforce、SAP、Workday、そして新たに Confluent Tableflow とのゼロコピー データ統合

  • Dataflow を使用した Lakehouse コンソール経由での Databricks Delta Lake アセットの同期

では、詳しく見ていきましょう。

ペタバイト規模のパフォーマンスと推論

エージェントのコンテキスト ウィンドウは通常、一度に取り込めるデータ量が数百キロバイトに制限されていますが、エンタープライズ ワークフローでは、複数のクラウドにわたりペタバイト規模のデータを結合することがあります。製品データや顧客データといったさまざまなソースのデータを、CRM クラウドやウェアハウスのテレメトリーと結合する必要があるエージェント ネイティブなデータ プラットフォームは、大規模なデータ処理が可能でなければなりません。MCP を使用してこれを行う場合、コンテキスト ウィンドウとペイロード サイズの制約により、処理の規模がメガバイト単位に制限されます。ボーダーレス Lakehouse は、データと AI スタックをあらゆるレイヤで連携させることで、エンタープライズ グレードのスケーラビリティを提供します。これにより、エージェントはペタバイト規模のデータをローカルに保存されている場合と同様のパフォーマンスで推論できます。

ネットワーキング レイヤでは、Cross-Cloud Interconnect とクロスクラウド キャッシュにより、AWS と Azure への高スループット、低レイテンシのパスが提供され、変動する外向きデータ送信料金が不要になります。エージェントが Amazon や Azure Data Lake Storage の Iceberg テーブルを BigQuery のデータと結合すると、スキャンするキャッシュ保存されていないバイトがすべてクラウドの境界を越えるため、ネットワークにより処理速度が決まります。Cross-Cloud Interconnect は、Google Cloud と AWS または Azure の間に、1 接続あたり 10 Gbps または 100 Gbps の専用プライベート接続を Lakehouse に提供します。Lakehouse のクエリは、パブリック インターネットではなく、この接続を介して送信されるため、低レイテンシの予測可能な状態が維持されます。また、クロスクラウド キャッシュは、Google Cloud 内から繰り返し行われる読み取り処理に対応するため、エージェントは他のクラウドのデータを移行することなく直接クエリできます。

ボーダーレス Lakehouse には、Iceberg メタデータをクエリエンジンに統合するための重要な最適化がいくつか盛り込まれています。BigQuery で、バイナリ削除ベクトルや並べ替え順など、Apache Iceberg V3 仕様がサポートされるようになりました。これらの機能により、データファイル全体を書き換える必要がなくなるため、エンジンは行レベルの更新や削除をより効率的に処理できるようになります。また、BigQuery の実行エンジンをアップグレードし、新しい FlatBuffers ベースの Parquet リーダーと並列化された I/O を導入しました。これにより、CPU オーバーヘッドやシリアル化によるボトルネックを軽減し、オープン フォーマットとネイティブ ストレージのパフォーマンスの差を縮めました。

これは、エージェントのワークロードをサポートするように設計されたクエリ エンジンの最近のパフォーマンス イノベーションに基づいています。エージェントのワークロードは一斉に大量発生することが多く、小規模なクエリを迅速かつ費用対効果の高い方法で処理することが求められます。BigQuery の流動的なスケーリングと履歴ベースの最適化により、Apache Iceberg とのオープン性を維持しながら、スケーラブルかつ効率的なエージェント ワークロードを実行できます。

一方、BigQuery と Managed Service for Apache Spark の両方で Apache Iceberg テーブルの読み取り / 書き込みの相互運用性が確保されているため、すべてのデータチームが Google Cloud Storage 内の同じ Iceberg テーブルを簡単に利用できます。この垂直方向に最適化されたスタックは、BigQuery と Lightning Engine の力を活用してデータを移動することなく有効化し、エージェントの高速化と費用対効果の向上を実現します。Lakehouse の分析能力をさらに拡張するため、BigQuery の Iceberg 向けグラフ機能のサポートにより、サプライ チェーンなどの関係ネットワークをオープン テーブル データセットで直接分析できるようになりました。

エージェント向けの包括的なコンテキストとデータアクセス

AI エージェントの能力は、アクセスできるコンテキストに左右されます。ハルシネーションを防止し、メタデータ レイヤの精度を向上させるために、ボーダーレス Lakehouse は Lakehouse ランタイム カタログを使用してエンタープライズ データを統合します。Apache Iceberg REST カタログをベースに、AWS Glue、Databricks Unity Catalog、Snowflake Horizon Catalog との双方向のカタログ連携を実現します。Lakehouse ランタイム カタログには、新たな標準の Hive Metastore 互換エンドポイントも含まれており、Apache Spark、Trino、Presto などのエンジンがアーキテクチャを変更することなくメタデータを参照できます。

ボーダーレス Lakehouse は、分散したデータアセットを自動的にインデックス化する Knowledge Catalog とも直接連携しており、エージェントがエンタープライズ コーパス全体（Cloud Storage 内の非構造化データを含む）を推論するために必要な、正確なビジネス メタデータとセマンティック定義を提供します。これにより、エージェントはトークン費用を抑えながら、正確性を確保するのに十分なコンテキストを得られるため、インテリジェントで持続可能なエージェント活用戦略を策定できます。

ボーダーレス Lakehouse は、Salesforce、SAP、Workday などの SaaS アプリケーションとのゼロコピー データ統合を実現し、より広範なパートナー エコシステムと連携することにより、Knowledge Catalog を通じてエンタープライズ データをキャプチャし、エージェントのための単一のコンテキスト エンジンとして機能します。このたび Google は、パートナー エコシステムを拡大し、Confluent Tableflow との新たな連携機能の一般提供を開始しました。これにより、Lakehouse ランタイム カタログと同期され、生成された Iceberg テーブルが BigQuery に直接表示されるようになります。コピーや追加の ETL は不要です。

最後に、Databricks 中心のリポジトリを持つ組織は、Lakehouse コンソール経由で Dataflow を使用して、Delta Lake アセットを Lakehouse に簡単にインポート、変換、同期できるようになりました。

モダナイゼーションを容易に

2025 年初頭以降、Apache Iceberg の利用は 3 倍以上に増加しており、Google Cloud のボーダーレス Lakehouse を使用してデータ基盤を構築している企業は、大きな成果を上げています。

  • Etsy: ボーダーレス Lakehouse を活用して、3 ペタバイトのデータを統合し、データを移動させずに結合することで、パイプライン クエリを 60% 高速化しました。

  • Commerzbank: 分散している生データを、ガバナンス管理されたエージェントがすぐにアクセスできるデータへと変換しています。

  • Hightouch: ボーダーレス Lakehouse と直接連携しているため、チームはオープンな Iceberg Lakehouse 上で直接マーケティング活動を強化し、Google Cloud エコシステム全体でそのデータを活用できます。

  • Roundel: ボーダーレス Lakehouse を活用して Target Product Ads の技術スタックを徹底的にモダナイズし、データの取り込み、処理、測定のパイプラインを完全に再構築しました。

組織でボーダーレス Lakehouse に移行する準備ができているなら、そのプロセスは難しくありません。現在、従来の Dataproc Metastore をご利用中の組織向けに、サーバーレス Lakehouse ランタイム カタログへの自動化されたダウンタイム ゼロの移行パスが用意されています。これにより、既存のスキーマやリネージを維持したまま、ボーダーレス Lakehouse の AI 対応機能を活用できるようになります。その結果、インフラストラクチャの管理から解放され、エージェントの活用に注力できるようになります。

ボーダーレス Lakehouse 構築の Codelab を今すぐお試しください。詳細については、Google のウェブサイトをご覧ください。

- プロダクト マネジメント担当ディレクター、Gaurav Saxena

- エンジニアリング担当ディレクター、Ahmet Altay

非構造化データ ワークフローのモダナイズ: Alteryx Live Query と Google Cloud BigQuery の連携

詳細を表示

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

Alteryx One Live Query と Google Cloud BigQuery は、分断されたツールへの依存を減らし、データの移動を最小限に抑え、ウェアハウス ネイティブの実行を可能にすることで、企業が複雑な非構造化データを大規模に処理する方法を一新します。

Live Query は、ビジネス ユーザーがコードを 1 行も記述することなく高度なデータ パイプラインを構築できる、直感的なブラウザベースの環境を提供します。BigQuery のスケールとパフォーマンスを組み合わせることで、安全な SQL プッシュダウンが可能になります。つまり、データ変換ロジックは、ネットワーク経由でデータを移動させることなく、ウェアハウス内で直接実行されます。この相乗効果は、ドキュメントを多用するワークフローで特に威力を発揮します。Live Query は、BigQuery 環境の厳格なデータ ガバナンスとセキュリティを維持しながら、Gemini などの Google の高度な AI および ML モデルをオーケストレートして、PDF や画像から情報を抽出できます。

請求書 PDF の処理から、Live Query を使用した BigQuery での例外レポート管理まで

財務チームやオペレーション チームは、ベンダーからの請求書の山に埋もれてしまうことがよくあります。これらのドキュメントは PDF 形式で届きますが、データに一貫性がなく、請求書番号の形式もさまざまであるため、手作業によるエラーが発生するリスクが高くなっています。従来、データチームは手動でデータを抽出するか、分断された複数のツールを使用してデータをウェアハウスに移す必要がありました。このプロセスには、時間がかかるだけでなく、データの重複や金額の不一致が発生しやすいという問題がありました。

Live Query for BigQuery のインテグレーションにより、請求書のライフサイクル全体を自動化できるようになりました。データチームは、BigQuery エコシステム内で直接、PDF の処理、主要なフィールドの抽出、結果の標準化を行うことにより、ドキュメント内の異常やデータの問題といった例外をより迅速に特定できると同時に、BigQuery のきめ細かなアクセス ポリシーに基づいて構成、ガバナンス管理された企業データを、ウェアハウスの外部に転送する必要がなくなります。

ソリューションの概要: 抽出、分類、検証、ルーティング、計上

Live Query ソリューションの仕組みについて、さらに詳しく見ていきましょう。請求書 PDF は、非構造化ドキュメントとして Google Cloud Storage に届きます。Live Query ワークフローでは、ドキュメント抽出ツールが、ユーザーが選択したモデル（Gemini や Document AI など）を使用して構造化フィールドを抽出します。その後、結果は信頼性の高い照合が行えるよう標準化され、BigQuery にすでに格納、ガバナンス管理されている請求書の履歴レコードと照合されます。

この自動化されたワークフローは、手作業による介入を最小限に抑えながら、ドキュメントから意思決定へとスムーズに至れるよう設計されています。エンタープライズ規模では、このパターンは少数の PDF を処理するだけにとどまりません。照合ロジックを BigQuery と整合させながら、数百万件もの非構造化ドキュメントに対する分析や AI 活用を可能にします。

AI を活用した抽出と BigQuery ネイティブの実行を組み合わせることで、このソリューションは以下を実現します。

  • ストレート スルー処理の向上: 手作業を減らし、より多くの請求書を自動的に処理できるようにします。

  • 照合の迅速化と手動例外の削減: 抽出した請求書をプロセスの早い段階で BigQuery データと照合することにより、チームは重複や不一致を早期に特定し、手動での確認が必要な請求書の数を減らすことができます。

  • 監査可能性の強化: ソースから最終的な業務出力まで、データの明確な処理履歴を保持します。

  • データ移動の削減: データを BigQuery 内にとどめ、その組み込み機能を活用することで、セキュリティ、ガバナンス、管理機能を強化します。

アーキテクチャ: 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="image1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_1k1nSQi_c5ubZpu.max-1000x1000.jpg" />
    
    </a>
  
</figure>


  </div>
</div>

大まかに言うと、請求書 PDF は Cloud Storage にステージングされ、ブラウザ上の Live Query ワークフローで処理された後、BigQuery にすでに格納、ガバナンス管理されている請求書履歴と照合され、ファイナンス チームの最終的な業務出力として書き戻されます。このパターンのアーキテクチャ上の主な利点は、ワークフローの作成をブラウザ上で行える一方、変換や照合のロジックは、プラットフォーム サービスを通じて、ガバナンス管理されたデータ環境に対して実行されることです。

Live Query アーキテクチャは、ウェアハウス規模の処理とガバナンス管理された実行を目的として設計されています。安全な SQL プッシュダウンを使用して、変換と照合のロジックを BigQuery 内で直接実行し、Gemini  と連携することで、ドキュメントの抽出、分類、要約といった高度な AI 機能を実現します。

  1. Live Query（ブラウザ）: ユーザーはブラウザ上でワークフローを視覚的に作成し、ドキュメントの抽出、分類、クレンジング、検証、ルーティングのロジックを構成します。

  2. Alteryx One Platform Services: 変換サービスは、ブラウザ ワークフローとお客様のデータ環境の間におけるリクエスト処理、実行計画、結果取得を調整します。また、これらのサービスにより、ワークフローの実行全体にわたるトレーサビリティとオブザーバビリティが向上し、運用モニタリングと監査可能性の両方が強化されます。

  3. お客様の Google Cloud: 請求書 PDF は Google Cloud Storage（GCS）にステージングされ、請求書の履歴データは BigQuery でガバナンス管理された状態で保持されます。AI を活用した抽出はその環境に対して実行され、ワークフローの出力は BigQuery に書き戻されます。

このパターンでは、ブラウザがオーサリング レイヤ、Alteryx One Platform Services が調整レイヤ、Google Cloud がガバナンス管理されたデータおよび実行レイヤとなります。この構成により、Live Query でワークフロー ロジックを視覚的に作成しながら、BigQuery でガバナンス管理されたデータおよびウェアハウス規模の処理と連携して実行できます。

Live Query ワークフロー解説: PDF から分析情報まで

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


  </div>
</div>

請求書を例に、Live Query ワークフローが非構造化 PDF をどのように処理するかを詳しく見ていきましょう。

請求書 PDF を取り込むワークフローは、未加工の PDF ファイルが格納されている Google Cloud Storage のディレクトリ入力を指定することから始まります。実際には、このステップではフォルダを特定するだけでなく、PDF の場所を列挙し、絶対ファイルパス、サイズ、作成 / 更新タイムスタンプといったファイルレベルのメタデータを返します。これにより、ワークフローは適切なドキュメント セットをダウンストリームの抽出ステップに確実に渡すことができます。

主要なフィールドを抽出するAlteryx の Document Extract ツールを使用して、ワークフローは Google Cloud Storage に格納されている PDF 請求書を処理し、構造化または半構造化された結果を BigQuery 内で直接抽出します。抽出ステップでは、ワークフローの構成に応じて、ユーザーが選択したモデル（Document AI または Gemini AI）が使用されます。このツールは、内部で入力ドキュメントの URI から一時的な外部オブジェクト テーブルを構築し、適切な関数（Document AI モデルの場合は ML.PROCESS_DOCUMENT、Gemini AI モデルの場合は AI.GENERATE）を実行します。このワークフローでは Gemini の処理ルートが使われており、AI.GENERATE がリクエストされた請求書フィールドをダウンストリームの Live Query ワークフローに返します。

インタラクティブな設計時、Live Query はプレビューのためにドキュメント URI のごく一部のみに処理を制限しますが、ランタイム実行ではすべての請求書 PDF を処理します。

code_block
<ListValue: [StructValue([('code', "-- illustrative pattern only\r\nSELECT *\r\nFROM AI.GENERATE(\r\n MODEL project.dataset.gemini_model,\r\n (\r\n SELECT\r\n uri,\r\n 'Extract invoice_number, invoice_amount, vendor_name, net_amount, tax_amount, and line_items.' AS prompt\r\n FROM project.dataset.temp_invoice_object_table\r\n )\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f45691905d0>)])]>

抽出されたデータの内容を分類する抽出後、ワークフローは Alteryx の Classify ツールを使用して、抽出された請求書テキストにゼロショット分類を適用します。このユースケースでは、BigQuery の AI.CLASSIFY を使用して、明細項目の内容を、工業用品や事務用品などの事前定義されたビジネス カテゴリに分類します。これにより、予測ラベルが新しい列としてダウンストリーム ワークフローに返されます。このビジネス コンテキストにより、抽出されたデータは、ダウンストリームでの照合、例外処理、レポート作成においてより有用なものとなります。

code_block
<ListValue: [StructValue([('code', "-- illustrative pattern only\r\nSELECT *,\r\n AI.CLASSIFY(line_item_text, categories => ['industrial', 'office']) AS line_item_classify\r\nFROM upstream"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4569393e90>)])]>

データを正規化する抽出された請求書番号はクレンジングされ、標準化されます。これにより、空白文字や書式の不一致といった軽微な表記の違いによって照合中に重複の可能性が見落とされることがなくなります。

履歴と比較するワークフローは、正規化された現在の請求書レコードを、すでに BigQuery に格納されている請求書の履歴データと結合します。この照合ステップでは、履歴にすでに存在する請求書番号と一致するレコードを特定し、重複の可能性があるものとしてフラグを立てます。

例外にフラグを立てる次に、数式ステップで、残りのレコードにビジネスルール ロジックを適用します。これらのルールはワークフローによって異なり、金額の不一致、必須フィールドの欠落、無効な合計額、その他の財務特有の例外に対するチェックなどが含まれます。この例では、1 つのルールで invoice_amount が net_amount + tax_amount と一致するかどうかを確認し、不一致があれば確認対象としてフラグを立てます。

業務出力を生成するこのワークフローでは 2 つの業務出力が生成されます。1 つは、履歴レコードと一致し、重複の可能性があるとしてフラグが立てられた請求書に関するものです。もう 1 つは、履歴と一致しなかった今回の請求書に関するもので、検証と必要に応じて例外のラベル付けが行われ、未払い請求書の処理に回されます。

その結果得られるのは、単に抽出されたデータにとどまらず、ファイナンス チームがすぐに確認して対応できる、ガバナンス管理された業務出力です。

まとめ: ドキュメントから意思決定まで、ガバナンス管理されたワークフロー

私たちの共通のお客様は、ビジネス プロセスの改善に役立つこれらの新機能に大きな期待を寄せています。

「Alteryx One: Google エディションで特に印象的だったのは、Google Cloud のエクスペリエンスに自然にフィットしている点です。ビジネス ユーザーが直感的でガバナンス管理されたエクスペリエンスを通じて BigQuery データを操作できるようにすることで、分析をより身近なものにする機会が得られることを嬉しく思います。」 - Papa Johns、エンタープライズ データおよびコーポレート ソリューション担当バイス プレジデント、Michael Wyant 氏

これは、単なる抽出ツールのユースケースにとどまりません。非構造化ドキュメントを実用的な業務出力に変換する、強力な Google Cloud ネイティブ パターンを表しています。このワークフローは、分断された準備ツールにウェアハウス データを移動するのではなく、ストレージ、抽出、照合、出力生成を、BigQuery にすでに格納されているガバナンス管理された企業データと整合させます。Alteryx One Live Query の直感的な設計と BigQuery のスケールおよび AI 機能を組み合わせることで、ファイナンス チームは手作業による負担を減らし、例外処理を迅速化して、より価値の高い戦略的な取り組みに注力できるようになります。

- Alteryx、シニア プロダクト マネージャー、Kira Droganova 氏

- Google、データ分析スペシャリスト、Rama Vundela

サイバーエージェント: Cloud Run や Agent Development Kit を活用し、クリエイティブ生成 AI プラットフォーム「AI SCREAM」のエージェント化を推進

詳細を表示

株式会社サイバーエージェントは、広告領域での活用を想定した社内向けクリエイティブ生成 AI プラットフォーム「AI SCREAM（アイスクリーム）」を、Google Cloud 上に構築し、約 3 年にわたって運用してきました。2025 年には Agent Development Kit（ADK）を活用したエージェント基盤を追加し、画像を作るための「道具」から、制作ワークフローを支援する「仕組み」へと進化させることに成功しています。その開発キーマンに、3 年間の総括と今後の展望を伺いました。

利用しているサービス:
Cloud Run、Pub/Sub、Veo、Imagen、Nano Banana など

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

独自プラットフォーム「AI SCREAM」で全社員に生成 AI を届ける

AI SCREAM は、動画生成 AI の Veo や、画像生成 AI の Imagen、Nano Banana（Gemini Flash Image / Pro Image 等） など、社内審査を経て商用利用可能な複数の生成 AI モデルを統一された UI 上で横断的に活用できる、サイバーエージェント独自のクリエイティブ生成AIプラットフォームです。広告制作などで必要となる静止画や動画、音声といった素材の作成から、それらを組み合わせた最終アウトプットまでを、誰もが手軽に行える仕組みを提供しています。

AI SCREAM 開発責任者の瓜生 和也氏は、その出発点は「生成 AI を使いたくても使えない人が社内に大勢いたこと」だったと振り返ります。

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

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







  <p>「2023 年当時、画像生成 AI 活用の機運は高まり始めていましたが、導入と利用には高度な専門知識が求められており、エンジニア以外のクリエイターや営業担当者は、到底手の出せない状況でした。そうした『壁』を取り払い、全社員に生成 AI を届けることが、このプロジェクトの目的となっています。」（瓜生氏）</p><p>2023 年 10 月、VM 1 台でスモール スタートした AI SCREAM は、2024 年 1 月に全社展開を見据えたリアーキテクチャを実施します。Cloud Run で動くフロントエンド／バックエンドと、推論ワーカーの VM 群の間に Pub/Sub を挟み、非同期の境界で疎結合にする構成に作り替えることで、より多くの社員が快適に使えるようになりました。</p><p>「インフラ層においては、社員約 8,000 人のうち 3 割、約 2,400 人が日常的に使うところまでスケールさせたいという事業要求に応えることが求められていました。一方、当時の GPU モデルは容量が大きく、1 つの VM に複数モデルを載せるのは現実的ではないという物理制約もありました。そこで、この両方の要件を満たすために、モデルごとに VM を分け、Pub/Sub のメッセージ流量で水平にスケールさせる構成にしています。事業要求と物理制約を先に見込んで Pub/Sub の境界を作り込んだおかげで、その後モデルが増え続けても、基本的にこの境界は触らずに済みました。」（瓜生氏）</p>
</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="CA_1_全社展開に向けたリアーキテクチャ" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/CA_1_QuanSheZhanKainiXiangketariakitekuchi.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>（2024 年 1 月 全社展開に向けたリアーキテクチャ ）</p></figcaption>
  
</figure>


  </div>
</div>

アプリケーション層では、異なるアプローチが採られています。2024 年 6 月には「2 週間に 1 つ、新しいモデルを提供する」という目標を設定。常に新しい生成 AI を試せること自体を価値と捉えて過度な共通化を避け、推論ワーカーのテンプレート化やコピーも意図的に許容しました。これにより、次々に登場する新たなモデルに迅速に対応することが可能になりました。瓜生氏は、わずか 3 年で 30 を超えるモデルを導入できたのも、この判断があったからだと言います。

「ただし緩めたのは実装の部分だけで、アーキテクチャ設計とデータ設計は守りました。何でも緩めたのではなく、緩める粒度を選んだというのが正確な表現だと思います。」（瓜生氏）

<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="CA_2_API 連携でもアーキテクチャを変えずに吸収" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/CA_2_API_LianXietemoakitekuchiyaoBianesuni.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>（2024 年 7 月〜 Stable Image Core / Ultra で初の API 連携での生成 AI モデル導入）</p></figcaption>
  
</figure>


  </div>
</div>

エージェント化によって営業メンバーもクリエイティブ制作の担い手に

次の転機となったのが AI エージェント機能の追加です。もともと社内では 2024 年 6 月頃から、クリエイティブ制作をエージェンティックにできないかという要望がありました。これを受けて 2025 年 3 月に検証が開始され、翌 4 月には、Google がリリースしたオープンソースのエージェント開発フレームワーク「Agent Development Kit（ADK）」の採用を決定。そのわずか 3 か月後の 2025 年 7 月に、エージェント基盤をリリースしています。

「ADK を選んだ理由は 3 つあります。オープンソースかつ Google の長期サポートが見込めること、Agent2Agent（A2A）プロトコルというエージェント間連携の仕組みが設計に組み込まれていること、そして Google Cloud のマネージド サービスと親和性が高いことです。」（瓜生氏）

短期間でのリリースを可能にしたのは、新規構築と既存資産の見極めでした。エージェント基盤そのものは ADK、Cloud Run、PostgreSQL で別アプリケーションとしてゼロから設計したのに対し、画像生成については既存基盤をそのまま呼び出す形にしたのです。現在稼働する主なエージェントは、プロンプトから画像を生成する「画像生成」、画像内のテキストを差し替える「ブラッシュアップ」、LP（ランディング ページ）や参考画像をもとに広告バナーを作る「バナー生成」、アスペクト比に合わせてレイアウトを組み替える「リサイズ」の 4 種類。これらはすでに現場での活用が進んでいます。

「2026 年 4 月にはエージェント機能を用いて約 1 万枚の広告クリエイティブが生成され、そのうち約 20% にあたる約 2,000 枚が実用候補としてダウンロードされました。従来、生成機能のダウンロード率は 7～8% 程度だったので、予想以上の数字だったと言えるでしょう。利用の拡大は、用途が明確なリサイズ機能に牽引されている面もありますが、バナー生成単体でもダウンロード率は 10% 弱となっています。素材生成が中心だった従来の生成機能より、バナー生成やリサイズなど制作工程をより先まで進められるエージェント機能の方が、ダウンロードにつながりやすい傾向が見られます。」（瓜生氏）

エージェント機能の提供開始により、営業担当者が自らバナーを制作し、それを叩き台に広告主企業とすり合わせたりするといった事例も生まれ始めました。まだ制作・外注コストの削減効果までは確認できていないものの、生成 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="CA_3_アーキテクチャ全体像" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/CA_3_akitekuchiyaQuanTiXiang.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>（アーキテクチャ全体像）</p></figcaption>
  
</figure>


  </div>
</div>

より対話的な体験を追求、そして社外への展開も開始

2 度の大きなアップデートで実用性を高め、サイバーエージェント社内に根付いた AI SCREAM。2025 年 2 月から 2026 年 6 月までの間に生成された成果物は累計 160 万点を超え、制作時間は従来比で約 3 割も短縮されています。瓜生氏はその実績を踏まえたうえで、これから AI SCREAM が目指すのは、エージェントをむやみに増やすことではなく、さらに品質を高め、実際の制作業務のニーズに応えていくことだと説明します。

「たとえばクライアント様のロゴや商品画像は原則として改変してはならない要素です。守るべきところはしっかりと守った上で、それ以外の部分を生成 AI で加工し、バナーとして成立させていく取り組みを進めています。」（瓜生氏）

そしてもう 1 つ、今後の AI SCREAM の進化の軸として検討されているのが、より対話的な制作体験の実現です。現在のバナー生成は、制作に必要な情報をフォームに入力すると生成結果が返ってくる仕組みで、その後も AI と継続的に対話しながら、制作を進める仕組みにはなっていません。しかし実際の制作現場では、関係者とのやり取りのなかでバナーの方向性を固め、フィードバックを受けて修正を重ねながら仕上げていくプロセスです。瓜生氏は、AI とやり取りを重ねながら仕上げていく体験に近づけることで、AI SCREAM の「次」が見えてくるのではないかと語ります。

「エージェントのランタイムやセッション サービスなど、今後実現したい制作体験に必要となる機能は、Google Cloud にすでに揃っていると考えています。今後はこれらを上手に活用しながら、AI SCREAM をより良いものにアップデートしていきたいですね。Google Cloud には今後も、より高精度な画像生成・動画生成モデルの提供を期待しています。」（瓜生氏）

サイバーエージェントは、こうして社内で磨き上げてきた AI SCREAM の企業向け提供を、2026 年 8 月に開始しました。AI クリエイティブ BPO 事業の専門チームが、導入から運用定着、制作体制の構築まで一貫して伴走するなど、大規模な SaaS として一気に利用拡大を図るのではなく、顧客とコミュニケーションを取りながら丁寧に展開していく方針を打ち出しています。

 

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

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







  <p><a href="https://www.cyberagent.co.jp/"><b>株式会社サイバーエージェント</b></a><br />「21 世紀を代表する会社を創る」をビジョンに掲げ、1998 年に設立。国内最大級のインターネット広告代理事業をはじめ、メディア &amp; IP 事業、ゲーム事業を主軸とした多岐にわたる事業を展開している。従業員数は 8,878 名（連結子会社含む。2026 年 6 月時点）。</p><p><b>インタビュイー<br /></b>AI クリエイティブカンパニー<br />AI SCREAM 開発責任者<br />瓜生 和也 氏</p>
</div>

 

▼ セッション動画を観る
本事例のインタビュイーによるセッション動画が公開中です。あわせてご覧ください。
【Next Tokyo 26 セッション】SDXL から AI エージェントへ: クリエイティブ AI プラットフォーム 3 年間の設計判断

▼他の導入事例記事を読む

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

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

詳細を表示

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

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

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

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

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

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

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

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

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

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

  • トランスポート層の抽象化と HttpMcpTransport: HttpMcpTransport とともに、クリーンなトランスポート層の抽象化を導入しました。この機能により、コア プロトコル ロジックが基盤となる HTTP クライアントから分離されるため、ネットワーク実装の入れ替えや接続プールのカスタマイズが容易になります。

  • クライアント認証の疎結合化: 企業のセキュリティ コンプライアンスを簡素化するため、CredentialsProvider クラスと AuthMethods クラスを使用してクライアント認証を切り離しました。認証情報はリクエストごとに非同期で解決されるため、チームはトークンを動的に更新したり、独自のトークンソースをプラグインしたりできます（ADC 経由の Google OIDC は標準で組み込まれており、それ以外は 1 つのメソッドを実装するだけのインターフェースです）。

  • デフォルト パラメータのサポート: ツール パラメータのデフォルト値をネイティブにサポートすることで、プロンプトのペイロード サイズを削減し、エージェントの信頼性を高めます。

  • バインドされたパラメータのプルーニング: サーバーサイドでバインドされた機密性の高いパラメータ（tenant_id など）が、公開されたツール定義から自動的に削除されるようになり、LLM による操作を防ぎます。

  • バージョン選択とセッション トラッキング: 標準化された MCP バージョン選択と堅牢なセッション トラッキングにより、一貫したプロトコル ネゴシエーションと会話状態のライフサイクルを実現します。

  • HTTP 認証情報の漏洩に関する警告: 認証情報が平文の HTTP 接続で送信されようとしているときに、実行時に警告を発する組み込みの検出機能を追加しました。

  • 汎用クライアント ヘッダーのマップ: カスタムの企業プロキシ ヘッダー、トランザクション トレース ID、相関メタデータを、すべての送信リクエストに簡単に追加できます。

Java SDK v1.0 を使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. HTTP セッションを介してプロンプト、ツール、会話のメモリを管理する宣言型エージェント インターフェース。

  2. エージェントのリクエストを MCP ツールボックス サーバーに直接ルーティングするツール実行サービス。

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

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

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

  • ボイラープレート不要のセッション管理: @MemoryId String sessionId パラメータにより、会話履歴がユーザーの HTTP セッションに直接バインドされます。

  • 宣言型エージェント コントラクト: TransitAgent インターフェースは、複雑なプロンプト テンプレートを使用せずに、モデルのペルソナとシステム指示を定義します。

  • 型安全なツールの実行: TransitAgentTools Spring サービスが、リモート MCP データベース ツールをネイティブ Java メソッドとしてラップします。

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

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

Gradle の実装

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

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

バージョンの自動追跡

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

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

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

共同執筆者:

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

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

Google Cloud Blog (AI & ML)

Expanding Claude availability and deployment choice on Google Cloud

詳細を表示

Every organization has unique requirements for building and scaling generative AI. At Google Cloud, we are committed to giving developers model choice and architectural flexibility to run workloads however they need.

Today, we’re announcing the general availability of an Anthropic-managed deployment option for Claude Models on Google Cloud. This gives teams more choice in how they run their models, helping them consolidate AI workloads on Google Cloud alongside our existingGoogle-managed deployment option. 

Both options deliver the same frontier models on day zero, the same pricing, and the same Google Cloud billing. The difference comes down to who acts as your data processor and whether you need access to the new Claude platform features when they launch:

[NEW] Claude Models on Google Cloud (Anthropic managed)

Delivers day-zero access to Claude models and Claude Platform features such as Claude Managed Agents (beta), skills, and code execution. Anthropic operates the stack as the data processor on Google Cloud infrastructure under Anthropic’s terms of service, while organizations authenticate with Google Cloud IAM, maintain Cloud Audit Logging, and consolidate spend under their existing Google Cloud billing and eligible commitments.

Learn more: Claude Models on Google Cloud (Anthropic-managed).

Claude Models on Google Cloud (Google managed)

Continues to deliver day-zero access to the latest Claude models with strict governance, compliance, and sovereignty requirements. Google Cloud operates as the data processor under existing customer agreements, providing VPC Service Controls, Customer-Managed Encryption Keys (CMEK), and data residency in the U.S., EU, and APAC. New Claude Platform features roll out over time as they are integrated into the Google-managed infrastructure. Teams also benefit from native integrations with Google Cloud services like BigQuery and Model Armor, along with standard billing and eligible commitment drawdown. 

Learn more: Claude Models on Google Cloud (Google managed)

Comparing deployment options

 

Feature

Anthropic-managed

Google-managed

Model availability

Available on Day 0

Available on Day 0

First-party tools and betas 

Available on Day 0

Available once integrated into the Google-managed infrastructure

Data processor and terms

Anthropic (under Anthropic’s Commercial Terms)

Google Cloud (under existing Google Cloud customer agreements)

Pricing & commitments

Standard pricing (draws down eligible Google Cloud commitments)

No matter how you choose to deploy, you can access Anthropic's latest frontier models on Google Cloud, including Claude Fable 5.1, Sonnet 5.5, Haiku 5.5, and Opus 5.5, with new platform features available immediately on the Anthropic-managed option and rolling out on the Google-managed option once integrated. This gives developers the full spectrum of reasoning, coding, and multi-modal capabilities with Google Cloud IAM and Marketplace billing. Get started.

GKE Security Bulletins

GCP-2026-071

詳細を表示

Published: 2026-10-23
Reference: CVE-2026-111943

Description Severity

Multiple eMudhra (emSign) subordinate Certificate Authority (CA) private keys were compromised (CVE-2026-111943). Unpatched TLS clients and container runtimes that trust these authorities are vulnerable to active network Man-in-the-Middle (MitM) interception and traffic spoofing on external TLS connections. Internal GKE cluster control-plane and node mutual TLS (mTLS) communication is unaffected because it uses an isolated per-cluster private PKI. However, external TLS connections from node daemons (such as containerd pulling images from external registries) or control-plane components (such as kube-apiserver calling external HTTPS webhooks without an explicit caBundle) rely on the system or Go runtime root CA store. Most of these connections occur to registries or endpoints that are also on Google Cloud traveling over encrypted links that are not at risk of a MitM attack. All currently supported GKE Standard and GKE Autopilot versions running Container-Optimized OS or Ubuntu node images are impacted. Node images and GKE system containers are being updated to distrust the compromised CAs. Customer application containers do not inherit the host node's root CA store and must be updated independently.

What should I do?

The following versions of GKE have been updated to fix this vulnerability in Container-Optimized OS. For security purposes, even if you have node auto-upgrade enabled, we recommend that you manually upgrade your cluster and Container-Optimized OS node pools to one of the following GKE versions or later:

  • 1.36.5-gke.1817000
  • 1.35.9-gke.1390000
  • 1.34.12-gke.1508000
  • 1.33.13-gke.2152000
  • 1.32.13-gke.2883000
  • 1.31.14-gke.3093000

Note: We'll update this bulletin when Ubuntu patch versions are available.

If you don't see these versions in the Google Cloud console, use the gcloud container clusters upgrade command to specify the versions and upgrade your node pools. Once patch versions are available in the Rapid channel, they can be installed on other channels, see run patch versions from a newer channel.

If you are unable to patch, you can implement the following mitigations:

  • Enforce container image pull integrity: Use image digest pinning (@sha256:...) in Pod specifications or enforce Binary Authorization so that a network MitM cannot substitute untrusted container images during registry pulls.
  • Verify admission webhook caBundle configurations: When clientConfig.caBundle is omitted on a ValidatingWebhookConfiguration or MutatingWebhookConfiguration, kube-apiserver falls back to the system WebPKI root store. Ensure all external HTTPS webhooks specify an explicit caBundle. You can check for webhooks with an empty caBundle by running: 
    kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations -o go-template='{{range $item := .items}}{{range .webhooks}}{{if not .clientConfig.caBundle}}WARNING (No caBundle): {{$item.kind}}/{{$item.metadata.name}} -> {{.name}}{{"\n"}}{{end}}{{end}}{{end}}'
  • Apply live-node OS mitigation (GKE Standard only): For existing Container-Optimized OS worker nodes awaiting patched OS images, you can deploy the privileged Container-Optimized OS CA certificate mitigation DaemonSet to remove the compromised roots and restart node daemons in place. (Note: Because this DaemonSet requires privileged host access, it is not supported on GKE Autopilot.) A similar approach can be followed for Ubuntu by using Canonical's upgrade advice.
  • Rebuild and redeploy customer container workloads: Because containers bundle their own OS root certificates (/etc/ssl/certs) and language runtimes, upgrading GKE nodes does not patch your application containers. Rebuild your container images using patched base images.
 High
前日
Archive
翌日