Back to Archive

GCP News - 2026-09-15

2026-09-15
最終更新: 2026-09-16 05:00:08 JST

AI による概要

6 記事

この日は 6 件で、BigQuery の拡張分析機能、Dataflow の性能改善、Forrester による評価に加え、エージェント向けのガバナンス機能拡充が目立ちました。BigQuery には、複雑なデータ分析を自動化する拡張分析用のテーブル値関数 (TVF) が 6 種類新たに加わりました。AI・ML・統計的手法を組み合わせて指標の変化理由の診断、データ全体の傾向や関係性の発見、ビジネス上の意思決定が及ぼした真の影響の切り分けまでを行え、データのある場所で直接実行されるため外部ツールへのエクスポートが要りません。ML.DETECT_CHANGE_POINTS・AI.KEY_DRIVERS・AI.CAUSAL_EFFECT のようにチェーンでき、出力が構造化された SQL であることから AI エージェントのスキルとして組み込みやすく、会話形式のデータ調査ワークフローを自動化できます。Dataflow では、バッチジョブの Pause/Resume が一般提供となり、失敗前にすでに処理済みのデータへアクセスできず全体をやり直していた無駄な計算を回避できるようになったほか、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載した G4 VM がサポートされ、AI ワークロード向けの推論性能が強化されました。評価では、Google Cloud が Forrester Wave: Public Cloud Platforms, Q3 2026 でリーダーに選出され、現行製品部門で最高スコア、30 の評価基準のうち 23 で最高評価を獲得しました。エージェントのガバナンス面では、Gemini モデルの強化学習ファインチューニングを Google Cloud コンソール上で作成・監視・テストできる機能がプレビューで提供され、Python コードやモデルベースの報酬関数を設定し、ジョブ起動前にサンプルプロンプトで報酬ロジックを検証できます。Policy Troubleshooter は、エージェントの ID がそれ自身の権限で行動する際の IAM 許可・拒否ポリシーや主体アクセス境界ポリシーのトラブルシューティングに対応し、エージェントのプリンシパル識別子やアクセス拒否イベントのエラー ID から調査できるようになりました。日本語ブログ (抄訳) では、表形式データの回帰・分類に対応した事前学習済み基盤モデル BigQuery TabFM がプレビューで紹介され、コンテキスト内学習により学習・チューニング・デプロイの手順なしに単一の SQL ステートメントから高精度な予測を即座に得られます。Yahoo が Managed Service for Apache Spark のフレキシブル VM でリージョンの容量制約を自動的に吸収している事例の抄訳も改めて掲載されました (前週にすでに紹介済みの記事です)。

主要トピック

  • 分析: BigQuery に拡張分析用の TVF を 6 種類追加、ML.DETECT_CHANGE_POINTS などをチェーンして変化要因を診断

  • データパイプライン: Dataflow のバッチジョブ Pause/Resume が GA、NVIDIA RTX PRO 6000 Blackwell 搭載 G4 VM に対応

  • 評価: Google Cloud が Forrester Wave Public Cloud Platforms Q3 2026 でリーダーに選出、30 基準中 23 で最高評価

  • エージェントガバナンス: Gemini モデルの強化学習ファインチューニングを Cloud コンソールで作成・監視・テスト可能にプレビュー提供

  • エージェントガバナンス: Policy Troubleshooter がエージェント ID の IAM ポリシートラブルシューティングに対応

  • 抄訳: 表形式データ向けの事前学習済み基盤モデル BigQuery TabFM がプレビュー、SQL 1 文でゼロショット予測

  • 抄訳: Yahoo の Managed Service for Apache Spark フレキシブル VM 活用事例を再掲載 (前週紹介済み)

AI (Claude Opus 5) が生成 · 2026-09-17 22:11:53 JST

Google Cloud Release Notes

September 15, 2026

Batch

Issue

A workaround has been added for the known issue that jobs might fail when specifying Compute Engine (or custom) VM OS images with outdated kernels.

Gemini Enterprise Agent Platform

Feature

Reinforcement learning fine-tuning in the Google Cloud console (Preview)

You can create, monitor, and test reinforcement learning fine-tuning jobs for Gemini models in the Google Cloud console (Preview). From the Models > Tuning page, you can configure Python code or model-based reward functions, test reward logic against sample prompts before launching a job, track training and evaluation metrics in real time, and test tuned checkpoints in Agent Studio.

For more information, see Quick start: Reinforcement learning fine-tuning using the console.

Policy Intelligence

Feature

Policy Troubleshooter now supports troubleshooting access for agent identities. You can troubleshoot IAM allow policies, deny policies, and principal access boundary policies for agents acting under their own authority by entering the agent's principal identifier or by troubleshooting with an error ID from an access denial event. To learn more, see Troubleshooting access.

Google Cloud Blog

Agent-ready analytics: Unlocking insights with BigQuery augmented analytics

詳細を表示

BigQuery now features a suite of augmented analytics Table-Valued Functions (TVFs) designed to automate complex data analysis at scale. Augmented analytics combines AI, ML and statistical methods to automate insight discovery and pattern explanation. These functions allow you to diagnose why metrics changed, uncover underlying trends and relationships across the data, and even isolate the true impact of business decisions. 

These TVFs run directly where your data lives, which helps speed up analysis and reduces the need to export data into external tools. In addition, since these functions are compact and yield structured SQL outputs, they can easily be integrated as skills for AI agents, which easily enables automated, conversational data investigation workflows. 

We are introducing six new augmented analytics functions in BigQuery, each created to address a specific analytical challenge:

TVF Function

What It Helps You Find

Real World Question It Answers

AI.KEY_DRIVERS

Identifies the top drivers behind an increase or drop in a metric between two time periods or groups. 

Why did revenue spike this quarter compared to last quarter?

AI.CAUSAL_EFFECT

Quantifies the impact of an action or event by comparing the observed results to an expected baseline.

How much of the revenue lift came from our pricing update rather than organic growth?

ML.CORRELATION

Evaluates the direction and strength of the relationship between pairs of numeric metrics. 

Does increased user session duration correlate with higher lifetime customer value?

ML.DETECT_CHANGE_POINTS

Identifies specific dates or intervals where a metric experiences a shift compared to surrounding patterns.

During which time periods did our platform latency experience persistent, structural shifts?

ML.TREND

Separates the underlying growth or decline from short-term fluctuations or noise. 

What are the underlying trends of my revenue over the past year, abstracting away the outlying spikes and drops?

ML.SEASONALITY

Discovers predicable repeated cycles across hours, days, weeks, months or quarters.  

Which days of the week consistently experience the highest server load?

As we show in the next section, these functions can be easily chained together. The output of one function, such as a detected time window, can directly parameterize the next analytical step.

A step-by-step example of chaining insights

Consider a case where there is a shift in a metric, and you need to diagnose the underlying cause and measure the business lift. 

To diagnose, we can chain ML.DETECT_CHANGE_POINTS, AI.KEY_DRIVERS and AI.CAUSAL_EFFECT using the Austin Bikeshare sample dataset (bigquery-public-data.austin_bikeshare.bikeshare_trips). This dataset contains historical trip volume and demographic data for the city’s bikesharing program. 

Step 1: Detect change points

ML.DETECT_CHANGE_POINTS automatically identifies statistically significant structural shifts or level changes in your time-series data. While this example demonstrates the analysis  in a single aggregate metric, this function is highly scalable and is capable of running across millions of individual time series. 

To find these shifts,  we run the following query across the daily baseline:

code_block
<ListValue: [StructValue([('code', "WITH daily_trips AS (\r\n SELECT\r\n TIMESTAMP_TRUNC(start_time, DAY) AS trip_day,\r\n COUNT(*) AS total_trips\r\n FROM `bigquery-public-data.austin_bikeshare.bikeshare_trips`\r\n GROUP BY 1\r\n)\r\nSELECT\r\n begin_timestamp,\r\n end_timestamp,\r\n metrics.avg AS avg_daily_trips,\r\n metrics.min AS min_daily_trips,\r\n metrics.max AS max_daily_trips,\r\n metrics.count AS duration_days\r\nFROM ML.DETECT_CHANGE_POINTS(\r\n (SELECT * FROM daily_trips),\r\n data_col => 'total_trips',\r\n timestamp_col => 'trip_day'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f06051e65d0>)])]>

The output identifies the exact time intervals where the baselines have shifted over the company’s history:

<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/original_images/image5_syrvVHj.png" />
    
    </a>
  
</figure>


  </div>
</div>

If we look at the raw daily session counts, this aligns with shifts over time. We highlight the two change points with the longest durations below:

<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_lQiu1DF.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

The shift in February 2018 aligns with the day the Austin City Council passed the “Dockless Mobility Pilot Program”, to transform the transit ecosystem, integrating shared electric scooters and bikes into the public. 

Step 2: Key drivers attribution

We can input the February 2018 slice found directly to AI.KEY_DRIVERS to determine the particular factors (i.e. bike_type, subscriber_type, etc) driving the surge. AI.KEY_DRIVERS can scan through millions of rows of multi-dimensional data in seconds. 

We define the interest group as the slice of time after the shift occurs and compare it against the time period before the shift as the reference group.

code_block
<ListValue: [StructValue([('code', "WITH daily_segments AS (\r\n SELECT \r\n start_station_name,\r\n end_station_name,\r\n subscriber_type,\r\n bike_type,\r\n 1 AS trip_count,\r\n -- We use the precise breakpoint identified by Change Points\r\n IF(EXTRACT(DATE FROM start_time) >= '2018-02-11', TRUE, FALSE) AS after_shift\r\n FROM `bigquery-public-data.austin_bikeshare.bikeshare_trips`\r\n -- Equidistant ~30 day window around the event\r\n WHERE start_time BETWEEN '2018-01-12' AND '2018-03-13'\r\n)\r\nSELECT \r\n drivers,\r\n metric_interest,\r\n metric_reference,\r\n difference,\r\n relative_difference,\r\n unexpected_difference,\r\n contribution\r\nFROM AI.KEY_DRIVERS(\r\n (SELECT * FROM daily_segments),\r\n metric_col => 'trip_count',\r\n interest_label_col => 'after_shift',\r\n dimension_cols => ['start_station_name', \r\n 'end_station_name', \r\n 'subscriber_type', \r\n 'bike_type'],\r\n top_k => 10\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f06051e7450>)])]>

AI.KEY_DRIVERS isolates the top contributing dimension values.  Each row contains a segment, which represents a slice of data identified by a specific combination of dimension values (e.g., subscriber_type = 'UT Student' and bike_type = 'classic'). 

<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_BD47nN6.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

The analysis reveals that the overall trip count increased +374.7% (+40,159 trips) between the reference and interest time windows. The massive growth was overwhelmingly concentrated in U.T. Student Memberships (+7,167.1%) and trips ending at the 21st & Speedway @PCL station (+20,739.1%).

This aligns with Austin Bikeshare’s response to the Dockless Mobility Pilot Program. In early February, the bikeshare program launched a large promotional partnership with the University of Texas that offered free annual memberships to all UT students.

Step 3: Causal effect

While we know what drove the surge and when it started, we need to isolate the true return on investment over organic expectations. AI.CAUSAL_EFFECT can construct an ARIMA_PLUS counterfactual to measure what the volume would have been had the program never launched.

code_block
<ListValue: [StructValue([('code', "WITH daily_trips AS (\r\n SELECT \r\n TIMESTAMP_TRUNC(start_time, DAY) AS trip_day, \r\n COUNT(*) AS total_trips\r\n FROM `bigquery-public-data.austin_bikeshare.bikeshare_trips`\r\n -- Training on the 6-month baseline leading up to the intervention\r\n WHERE start_time BETWEEN '2017-08-11' AND '2018-04-11'\r\n GROUP BY 1\r\n)\r\nSELECT \r\n *\r\nFROM AI.CAUSAL_EFFECT(\r\n (SELECT * FROM daily_trips),\r\n data_col => 'total_trips',\r\n timestamp_col => 'trip_day',\r\n -- We inject the breakpoint found in Step 1 as our intervention\r\n intervention_timestamp => '2018-02-11 00:00:00',\r\n output_time_series => TRUE\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f06051e4590>)])]>

If we graph the predicted and actual trips per day, we can see the surge compared to the counterfactual.

<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_X3SlXmT.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

If we set the output_time_series => FALSE, we can see a summary of the lift

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


  </div>
</div>

AI.CAUSAL_EFFECT reveals that the program caused a +358% volume surge above organic baseline projections, resulting in an estimated 89,775 incremental trips (with 99.9% probability of causal effect).

Connecting augmented analytics to Conversational Analytics

Conversational Analytics lets you chat with agents about your data using natural language. All new BigQuery augmented analytical functions are now available in Conversational Analytics. Since these TVFs can execute complex analytics at BigQuery-scale in seconds, Conversational Analytics can orchestrate multi-step investigative workflows based on a given prompt. Below we show two examples:

Example 1: Chicago taxi trips

Here is an example using the Chicago Taxi Trips (`bigquery-public-data.chicago_taxi_trips.taxi_trips`).

Prompt: What metric has the strongest correlation with drivers getting tipped? Then run an attribution analysis to tell me which categorical dimensions (like location and payment type) most disproportionately drive that specific metric.

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


  </div>
</div>

The results here used ML.CORRELATION in combination with AI.KEY_DRIVERS.

Credit card payments serve as the primary positive driver of trip distance, adding +1.65M due to longer travel routes and automated digital tip tracking. Trips originating from O'Hare International Airport (Community Area 76) represent another major positive factor, contributing an additional +1.10M miles among tipped credit card rides. In contrast, cash transactions act as a significant negative driver (-652.96K miles), reflecting that cash is predominantly used for shorter journeys rather than extended airport travel.

Example 2: Iowa liquor dataset

Here is an example using the Iowa liquor dataset (`bigquery-public-data.iowa_liquor_sales.sales`) that uses both ML.TREND in combination with ML.SEASONALITY.

Prompt: Find the historical trend for bottles sold. Then, describe the yearly seasonality patterns.

<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/Example_2.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

The results show that liquor sales in Iowa show persistent long-term growth, rising from 1.3–1.5 million bottles in 2012 before stabilizing around 2.6 million in recent years. There are strong seasonal cycles, particularly during October and December as well as May and June. There is a drop in sales around January and February.  

The skills for these TVFs are now available at the Google Skills Github repository. The BQ AI/ML skills can be found here. 

Take the next step

We would like to extend our sincere thanks to Katelin Amann, Shirley Fu, Chaoyi Shen, Haiyang Qi, Zheng Zhang, Xi Cheng and the wider engineering team for their feedback and contributions of this work.

Announcing Pause/Resume and NVIDIA RTX PRO 6000 Blackwell GPU support in Dataflow

詳細を表示

Overview
As enterprises scale their AI and agentic workflows, they require serverless platforms that make data preparation for model training, evaluation, and inference effortless and efficient. Dataflow is a critical component of Google Cloud’s AI stack. It enables our customers to create batch and streaming pipelines that support a variety of analytics and AI use cases. 

Today, we’re delivering significant enhancements to Dataflow that directly address your top challenges: maximizing compute efficiency for long-running batch jobs and delivering extra inference power for your most demanding AI workloads. We’re thrilled to announce the general availability of Pause/Resume for Dataflow batch jobs as well as support for G4 VMs powered by NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs. With these features, you can accelerate your AI development lifecycle and optimize your costs.

Recover wasted compute and increase developer productivity with Pause/Resume for Dataflow batch jobs
Dataflow customers frequently run large batch workloads that sometimes run for a few days. When these jobs fail, Dataflow users currently cannot access the data that was already processed before the job failure. Instead, they have to retry the entire job, leading to wasted compute resources and decreased engineering productivity.

In addition to addressing failures from large jobs, Dataflow customers with AI workloads sometimes want to increase the utilization of accelerated compute resources like GPUs and TPUs by dynamically re-allocating them from already running, lower priority Dataflow batch jobs to higher priority workloads like feature engineering and AI inference. 

To better support these use cases, we are announcing the GA launch of Pause/Resume for Dataflow batch jobs. Powered by internal Google innovation, this feature enables Dataflow customers to resume their failed long running jobs instead of starting from scratch. It also allows customers to pause and resume their Dataflow batch jobs based on their respective business requirements.

For more details, see manually pause a Dataflow job.

<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_k7tia8a.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

Accelerate AI inference workloads with NVIDIA RTX PRO 6000 GPUs
While Dataflow already supports a wide variety of GPUs and TPUs for accelerating AI inference workloads, we’re taking things a step further by announcing support for G4 VMs powered by NVIDIA RTX PRO 6000 Blackwell GPUs. 

The NVIDIA RTX PRO 6000 Blackwell GPU delivers significant performance gains compared to the NVIDIA L4 GPU, bringing 96GB vGPU memory and 1.6 TB/s of bandwidth. This means that you can perform AI inference right within your Dataflow job using up to 70B+ parameter models. You can do this while continuing to take advantage of native Dataflow ML capabilities like RunInference, right fitting and GPU-enabled autoscaling which make it easy for you to onboard and scale your AI inference jobs without having to manage underlying infrastructure or manually deal with hard problems like tuning and autoscaling. 

Take the next step
Together, Pause/Resume and RTX PRO 6000 Blackwell GPUs help you optimize your batch job costs while running demanding AI workloads. We’re incredibly excited about Dataflow’s capabilities and the possibilities they unlock for our customers. Get started with Dataflow today and use these features to solve your hardest AI challenges. We cannot wait to see what you build.

Google is a leader in The Forrester Wave™: Public Cloud Platforms, Q3 2026

詳細を表示

We are excited to share that Google Cloud was named a Leader and received the highest score in the ‘current offering’ category in the Forrester Wave™: Public Cloud Platforms, Q3 2026 report, which examines the 10 most significant public cloud providers across 30 comprehensive criteria, Google also received the highest possible score in 23 out of 30 evaluation criteria, including, but not limited to vision, innovation, AI development services, database services, analytics services, containers and kubernetes services, modernization services, and security services. We believe Forrester’s recognition confirms our belief that to lead in the agentic era, you need a complete, integrated platform that’s engineered from the ground up, from silicon to systems to 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="image1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_ZbIiC7j.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Access the complimentary report: <a href="https://cloud.google.com/resources/content/2026-forrester-public-cloud-platform-wave-report">The Forrester Wave™: Public Cloud Platforms, Q3 2026.</a></p></figcaption>
  
</figure>


  </div>
</div>

Build on co-designed infrastructure proven in global enterprises

For over a decade, our infrastructure engineers, application developers, and AI researchers worked side by side to co-design infrastructure to power Gemini, Search, YouTube, Maps, and Gmail. We couldn't simply buy the platform and infrastructure we needed; we had to invent it. This led to the creation of everything from TPUs, the Transformer architecture, Kubernetes, Axion, and now Gemini.

In the agentic era, you need an integrated AI stack, where compute, orchestration software, modernization tools, and global networks operate together to give you more value from your investments — even if you’re not working at the frontiers of AI research. At Google Cloud, we’ve worked tirelessly to bring these breakthrough innovations to leading enterprises, startups, and frontier labs to help them achieve new levels of scale and efficiency, and we believe Forrester’s evaluation validates that strategy: 

“Google Cloud’s vision is to enable the ‘agentic enterprise,’ and AI already permeates its platform, positioning the company to push further up the tech stack toward business users who increasingly shape AI adoption in the enterprise. Google Cloud is a good fit for enterprises seeking rapid technology innovation and a broad AI-enabled cloud platform.” - The Forrester Wave™: Public Cloud Platforms, Q3 2026 report

Run agents quickly on a secure, flexible platform

Most traditional infrastructure can’t keep pace with agents, and enterprises need a scalable alternative. But you don’t want a new, greenfield platform just for AI agents. Kubernetes is the proven industry standard for modern enterprise applications — from microservices and transactional databases to real-time LLM inference. We are evolving Google Kubernetes Engine (GKE) and our operations tooling so organizations can scale autonomous agents alongside traditional workloads on a single, proven platform.

Forrester gave Google Cloud the highest scores possible in Container and Kubernetes services, Serverless/FaaS services, and Operations management services, noting:

“Operators will find strong offerings in operations management as well as containers and Kubernetes services. Our evaluation did not identify significant capability gaps.”

Over the past three months, we’ve enhanced our infrastructure portfolio to help teams scale agentic workloads with enterprise predictability. Recent updates let you:

  • Safely execute untrusted agent code alongside traditional workloads with default-deny security using GKE Agent Sandbox (GA) and Cloud Run Sandboxes (preview), which provision lightweight, gVisor-isolated boundaries for your agent in under a second (and up to 300 sandboxes/sec per cluster).

  • Eliminate up to 90% of idle compute costs by serializing your container RAM state directly to Google Cloud Storage with GKE Pod Snapshots, allowing you to suspend idle agent sessions in ~100ms and resume them in ~280ms.

  • Cut time-to-first-token (TTFT) up to 70% and double cache-hit rates with predictive routing in GKE Inference Gateway, which uses a continuously trained ML model to make routing decisions based on real-time traffic data.

Ground your agents with real-time enterprise data

Agents are only as effective as the context that grounds them. Traditional distributed data topologies separate operational databases from analytical systems through fragmented, multi-hop pipelines. In the agentic era, this divide introduces multi-hop latency, stale context, and governance friction.

Our Agentic Data Cloud evolves the enterprise data platform from a static repository into a dynamic reasoning engine. It unifies transaction processing and analytical intelligence into an active system of action, providing the real-time context and deterministic responsiveness that autonomous workflows require. Google received 5/5 scores across the Database services, Analytics services, Data integration services, and Data Governance services criteria:

“Google Cloud’s traditional strength in database services and analytics drives strong performance, including multicloud and hybrid capabilities, along with an Agentic Data Cloud that bridges analytics and transactional systems.”

Over the past three months, we’ve introduced key capabilities to the Agentic Data Cloud to help customers unify their data estates:

  • Enable agents to query live financial and supply chain records without costly data movement using SAP BDC Connect for BigQuery (GA), which provides bi-directional, zero-copy data sharing between your SAP systems and BigQuery.

  • Map and infer business meaning across your entire data estate with Knowledge Catalog. You can now aggregate native context across your Google and partner data platforms, semantic models, and third-party catalogs, unifying them into a single, governed source of truth.

  • Access live data from Iceberg and BigQuery from the PostgreSQL data plane with Lakehouse federation. Perform live joins between AlloyDB's transactional data and historical insights in BigQuery or Iceberg without any data movement. You can also replicate data continuously to BigQuery and, importantly, to Iceberg tables directly from AlloyDB with Datastream.

The benchmark is set: Build what’s next on Google Cloud

We are honored that Forrester has named Google Cloud a Leader in The Forrester Wave™: Public Cloud Platforms, Q3 2026. We believe this recognition validates decades of foundational research, disciplined full-stack co-design, and our commitment to building an open, reliable cloud.

The era of fragmented infrastructure has come to an end. Whether your organization is an AI research lab scaling models across one million accelerator chips, a global financial exchange settling trillions in clearing systems, or an enterprise empowering millions of users with autonomous workflows, Google Cloud delivers the performance, scale, security, and data foundation to build what’s next.

Take the next step in your cloud journey:

Google Cloud Japan Blog

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

詳細を表示

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

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

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

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

  • ゼロショット予測: モデルのトレーニング、チューニング、アーティファクトのデプロイをスキップします。ラベル付きの過去データと新しい予測テーブルを単一の SQL 関数に渡すだけで、高品質な予測を即座に取得できます。

  • エージェント アプリケーション向けの予測 ML: ビジネス用途のエージェントを構築する場合、TabFM と BigQuery MCP サーバーを組み合わせることで、予測機能を追加できます。ランタイムやインフラストラクチャを管理する必要はありません。データを入力するだけで予測結果が得られます。

  • 最先端の精度: 複雑なデータセットにおいて、カスタム トレーニングされた既成の従来モデルを上回り、業種別ベンチマークで優れた精度スコアを達成します。

  • シンプルなデベロッパー エクスペリエンス: BigQuery 上でネイティブに実行され、シンプルな SQL 構文でアクセスできます。欠損値やカテゴリ エンコードなどの特徴量化タスクを自動的に処理するため、複雑な特徴量エンジニアリング パイプラインを管理する必要がありません。

  • スケーラビリティ: BigQuery の分散推論アーキテクチャを使用して、大規模な推論テーブル（最大数百万行）を数分で処理します。

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

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

<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_vsRpJjZ.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>TabArena の分類（上）と回帰（下）における上位 10 モデルの ELO 評価（↑）。（D）= デフォルト、（T+E）= チューニング + アンサンブル。スコアが高いほど、パフォーマンスが優れていることを示します。</p></figcaption>
  
</figure>


  </div>
</div>

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

BigQuery で TabFM を使ってみる

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

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

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

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

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

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

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

BigQuery の TabFM の仕組み

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

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

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

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

  • TabFM は、ML の専門知識がなくても迅速かつ高品質な予測分析情報が必要な場合や、過去のデータセットが小規模から中規模である場合、データが頻繁に変更される場合、そして精度を維持するためにモデルを頻繁に再トレーニングする必要がある場合に使用します。また、オンデマンドでの予測分析を必要とする会話型ワークフローやエージェント ワークフローにも適しています。

  • XGBoost のような従来のモデルは、非常に大規模な過去のデータセットがある場合、カスタム ハイパーパラメータ チューニングを完全に制御する必要がある場合、TabFM の現在の制限を超えるほど特徴量が多い場合、または特徴量の重要度の説明可能性（例: どの入力特徴量が予測に最も貢献したか）が必要な場合に使用します。

予測 ML が簡単に

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

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

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

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

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

詳細を表示

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

Yahoo は、数億人のユーザーを金融、スポーツ、エンターテイメントのプラットフォームに接続するグローバルなメディアおよびテクノロジー企業として、分析ワークロードを高速で継続的に実行する必要がある大規模なデータ インフラストラクチャを運用しています。期限が重視されるデータ環境では、固定の仮想マシン（VM）構成に依存すると、システムが脆弱になります。特定のマシンシェイプがリージョンの容量制限に直面すると、Managed Service for Apache Spark（旧称 Dataproc）でのクラスタ プロビジョニングが遅延し、重要なデータ パイプラインが停止する可能性があります。

Yahoo は、Managed Service for Apache Spark クラスタでフレキシブル VM を利用し、許容可能な VM シェイプのランク付けされたリストを定義することで、これらのリソースの変動に自動的に対応しています。これにより、システムはリージョン ゾーンを動的に検索し、手動による介入なしでパイプラインの実行を維持できます。リージョン全体で容量を検索するには、自動ゾーン プレースメントも有効にする必要があります。

この最適化は、オンプレミスの Hadoop とビッグデータ資産を Google Cloud に直接移行する、Yahoo のより広範なデータ モダナイゼーションの取り組みを基盤としています。これらのレガシー ワークロードを移行することで、チームは動的なリソースの柔軟性を備えた、大規模なバッチ分析とストリーミング分析を実行できるクラウド基盤を確立しました。

    <div class="article-video__aspect-image">
      <span class="h-u-visually-hidden">Hadoop pioneer to cloud innovator: Yahoo’s data lake modernization journey</span>
    </div>
  
  <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>

この投稿では、Managed Service for Apache Spark でフレキシブル VM インスタンスのランキングを構成し、容量の制約を自動的に管理してパイプラインの実行を維持するための技術的なブループリントをご紹介します。

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

特定のゾーンで固定された単一のマシンタイプを使用してクラスタを構成すると、リージョン ゾーンの容量が変動した場合に制約が生じ、クラスタのプロビジョニングに影響する可能性があります。カスタムの再試行ロジックや手動による介入によってこれらの容量の変動を管理するのではなく、柔軟な構成を使用することで、インフラストラクチャを自動的に適応させることができます。柔軟な構成により、複数の VM シェイプを受け入れ、選択したリージョン内のゾーン全体で検索を行うことで、プロビジョニングを合理化し、大規模な分析ワークロードをより適切にサポートできます。

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

柔軟な構成をデプロイするには、一連の設計上の選択を調整する必要があります。

  • 自動ゾーン プレースメントを有効にする: Managed Spark がリージョン全体で利用可能な容量を検索できるように、リージョン（--region=${REGION}）または空のゾーン文字列（--zone=""）を渡す必要があります。

  • コアとメモリの均一性を維持する: Managed Spark クラスタで自動スケーリングを使用する場合、フレキシブル リスト内のすべてのマシンタイプは、異なる VM ファミリーのものであっても、同様のコア数とメモリサイズを共有する必要があります。プライマリ ワーカーとセカンダリ ワーカーで CPU とメモリの比率を統一すると、最小の比率によって有効なコンテナのサイズが決まるため、パフォーマンスの低下を防ぐことができます。

  • コンポーネント プロパティを調整する: Managed Spark は、VM のコアとメモリに基づいてシステム プロパティを計算します。マシンシェイプを混在させる場合、YARN と Spark のリソース割り当てをワーカーの想定される動作に合わせるために、プロパティの明示的なオーバーライドが必要になることがあります。

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

大規模なデータ環境の場合、柔軟な構成は次の 2 つの方法で運用をサポートします。

  1. クラスタ作成の成功率の向上: 優先 VM タイプが利用不可の場合に失敗せず、Managed Spark がランク付けされたリストから代替の VM タイプを選択してプロビジョニングを継続します。

  2. リージョン リソースの使用効率の向上: 自動ゾーン プレースメントでは、リージョン全体が検索され、容量が検出されるため、需要が高い期間のプロビジョニングの摩擦が軽減されます。

gcloud の例

code_block
<ListValue: [StructValue([('code', 'gcloud dataproc clusters create analytics-cluster \\\r\n --region=us-central1 \\\r\n --zone="" \\\r\n --num-workers=10 \\\r\n --master-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --master-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc6f84c0d90>)])]>

API の例

この容量ポリシーは、Dataproc API の instanceFlexibilityPolicy フィールドを使用して、自動化されたパイプラインまたは Managed Service for Apache Airflow DAG に組み込むこともできます。

code_block
<ListValue: [StructValue([('code', '{\r\n "projectId": "PROJECT_ID",\r\n "clusterName": "analytics-cluster",\r\n "config": {\r\n "gceClusterConfig": {\r\n "zoneUri": ""\r\n },\r\n "secondaryWorkerConfig": {\r\n "numInstances": 8,\r\n "instanceFlexibilityPolicy": {\r\n "instanceSelectionList": [\r\n {\r\n "machineTypes": ["n2-standard-8"],\r\n "rank": 0\r\n },\r\n {\r\n "machineTypes": ["e2-standard-8", "t2d-standard-8"],\r\n "rank": 1\r\n }\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc6f8315590>)])]>

この API ポリシーは、同じ目標を達成します。つまり、優先するシェイプを確立し、有効なフォールバックを文書化し、自動化スクリプトを中断することなく、Managed Spark がリソースの制約を解決できるようにします。

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

この規模のデータを管理するには、固定された単一のマシンタイプに依存するのではなく、明確なリソース ポリシーを標準化する必要があります。構成基準では、以下を規定する必要があります。

  • セカンダリ ワーカーの優先 VM ファミリーとフォールバック VM ファミリー。

  • 柔軟なプロビジョニングを可能にするためのデフォルトの自動ゾーン プレースメント。

  • 自動スケーリングを使用する場合のコアとメモリの同一構成。

  • コンテナのサイズを予測可能に保つためにすべてのワーカー グループで統一された CPU とメモリの比率。

  • 異なるマシンライン間で一貫したランタイム動作を保証するための、YARN または Spark プロパティの明示的なオーバーライド。

  • Spot または弾力性の高い容量で実行される Spark ワークロード向けのシャッフル セーフ パターン。

柔軟な構成を採用することで、インフラストラクチャのリソース不足が解消され、予測可能なフォールバック プランが適用されるため、重要なデータ パイプラインを稼働させ続けることができます。

Yahoo の影響と結果

Yahoo は、Managed Service for Apache Spark にフレキシブル VM を実装することで、リージョンの容量不足が原因で発生していたクラスタ プロビジョニングの失敗を 85% 削減することに成功しました。この柔軟な構成により、データ インフラストラクチャは容量の制約に自動的に対処し、手動による介入を必要とせずにリソースを正常にプロビジョニングできます。その結果、Yahoo はワークロードを継続的に実行できるようになり、大規模なデータ パイプライン全体でダウンストリーム処理の遅延を防止しています。

「Yahoo で大規模なデータ分析を管理するには、復元力のある自動化されたインフラストラクチャが必要です。Managed Service for Apache Spark のフレキシブル VM に移行したことで、当社のアプローチは一変しました。特定のマシンシェイプが容量の制約に直面したときに処理が停止するのではなく、クラスタがランク付けされたフォールバック オプションに自動的に切り替わるようになりました。これにより、プロビジョニングの失敗を 85% 削減し、グローバル メディア プラットフォームをスムーズに運用し続けるために必要な信頼性を確保できました。」- Yahoo!、シニア ソフトウェア デベロッパー エンジニア、Akshay Jain 氏

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

柔軟なコンピューティング スタックを採用することで、環境を運用ニーズに適応する動的なリソースプールへと変革できます。固定された単一のマシンタイプ構成に縛られないため、供給の変動に関係なく、ワークロードが必要なコンピューティングに確実にアクセスできるようになります。この移行により、ワークロードの入手可能性と信頼性が最大限に高まるだけでなく、古いタイプの VM を信頼性の高いフォールバック オプションとして維持しながら、新しい世代の VM を優先できるため、シームレスなハードウェアのモダナイゼーションが促進されます。

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

流動的なコンピューティング戦略に移行することで、リージョン リソースが変化しても、重要な分析を継続できます。インフラストラクチャの最適化を今すぐ始める方法を以下に示します。

  1. ワークロードを検証する: 特定の VM ファミリーやゾーンに緊密に結合されているアプリケーションを特定し、実行可能な代替ハードウェア シェイプをマッピングします。

  2. リソース ポリシーを標準化する: Managed Spark のフレキシブル VM のドキュメントを読んで、優先 VM ファミリーとフォールバック VM ファミリーを確立します。

  3. 財務戦略を調整する: ワークロードが代替マシンタイプに動的に移行する場合に、フレキシブル確約利用割引（フレキシブル CUD）を利用して費用の予測可能性を維持します。

  4. クレジットを獲得する: 新規のお客様は、Managed Service for Apache Spark や他の Google Cloud プロダクトを無料で試すことができる $300 分のクレジットを獲得できます。

- Yahoo、シニア ソフトウェア エンジニア Akshay Jain 氏

- Google Cloud、データ / AI エンジニア Surjit Singh

前日
Archive
翌日