GCP News - 2026-10-13

Overview

Since introducing zero-shot time-series forecasting in BigQuery with AI.FORECAST — initially powered by TimesFM 2.0 and later upgraded to TimesFM 2.5 — you have been able to generate forecasts directly in SQL without training or managing custom models. However, up until TimesFM 2.5, these foundation models were limited to univariate forecasting, predicting future values from the history of a single time series alone. In practice, most real-world forecasting problems are multivariate, where related targets and external drivers like weather, promotions, and holidays jointly shape future outcomes.

Today, we are thrilled to announce the preview of TimesFM 3.0 in BigQuery. Developed by Google Research, TimesFM 3.0 is a 330-million parameter state-of-the-art foundation model designed to unlock native multivariate time-series forecasting directly inside BigQuery SQL. TimesFM 3.0 ranks #1 across all three major public time-series leaderboards — GIFT-Eval, FEV-Bench, and TIME — achieving top zero-shot accuracy on both covariate and multivariate forecasting tasks compared to existing foundation models.

Alongside its new multivariate capabilities, TimesFM 3.0 also serves as a drop-in upgrade for univariate forecasting via AI.FORECAST and anomaly detection via AI.DETECT_ANOMALIES. Existing workflows can immediately benefit from higher benchmark accuracy simply by specifying model => 'TimesFM 3.0'.

What’s new: Multivariate foundation modeling

With TimesFM 3.0, BigQuery brings enterprise-grade multivariate modeling into familiar SQL workflows via AI.FORECAST:

Multivariate forecasting with BigQuery SQL

To see how these capabilities work together, let’s forecast daily commuter (subscriber_trips) and leisure (casual_trips) bike rides over a seven-day horizon using the NYC Citi Bike public dataset (bigquery-public-data.new_york.citibike_trips).

BigQuery uses a single-table input format for multivariate forecasting that combines two sets of rows:

• Historical observation rows: timestamps between start time (2016-01-01) and the forecast cutoff date (2016-06-01), fully populated with target metrics, past covariates, and known future covariates

• Future horizon rows: timestamps across the seven-day forecast horizon (2016-06-01 to 2016-06-07) populated with known future covariates, while target columns and past-only covariates are set to NULL

This query highlights the three multivariate dimensions supported in TimesFM 3.0:

1. Forecasting correlated targets (target_cols) Instead of running separate models for each rider segment, passing TARGET_COLS => ['subscriber_trips', 'casual_trips'] forecasts both metrics jointly in a single call. TimesFM 3.0 captures the cross-series dynamics between commuter and casual riders — such as shared weather sensitivity and diverging weekend ridership patterns.

2. Using past covariates (past_covariate_cols) Some signals can only be observed historically and are not known in advance, such as average ride duration (avg_duration_min), historical foot traffic, or unplanned service disruptions. Passing PAST_COVARIATE_COLS => ['avg_duration_min'] (with future horizon rows set to NULL) gives the model historical context to distinguish temporary shocks from underlying trends without requiring future values for that feature.

3. Using future covariates (future_covariate_cols) Other external drivers are known ahead of time across both the historical window and the forecast horizon — such as weekends (is_weekend), holidays, or scheduled promotions. Passing FUTURE_COVARIATE_COLS => ['is_weekend'] (populated across all rows through 2016-06-07) allows TimesFM 3.0 to condition its seven-day predictions directly on upcoming calendar events.

Understanding the output

The function returns structured predictions for each target column specified in target_cols. For each column in target_cols, AI.FORECAST returns a struct containing the point forecast (value) and the lower and upper prediction interval bounds:

TimesFM 3.0 in BigQuery Conversational Analytics

You can also run multivariate forecasts using natural language in BigQuery Conversational Analytics. On the same bigquery-public-data.new_york.citibike_trips dataset, you can simply ask "Forecast both daily subscriber and casual trips for June 1–7, 2016 using two month historical data, with average trip duration as a past covariate and weekend indicator as a future covariate." Conversational Analytics automatically generates and executes the underlying AI.FORECAST query with TimesFM 3.0, returning a summary of the results, interactive forecast charts with prediction intervals for each target, and key forecast insights.

Summary and next steps

With native multivariate support in TimesFM 3.0, BigQuery brings state-of-the-art foundation model forecasting to complex, interconnected enterprise datasets without requiring data movement, custom feature engineering pipelines, or dedicated model hosting infrastructure.

To start forecasting with TimesFM 3.0 in BigQuery:

• Read the Google Research blog post to learn more about the TimesFM 3.0 model architecture and capabilities.

• Explore the BigQuery TimesFM documentation.

• Follow the step-by-step multivariate forecasting tutorial.

• Try AI.FORECAST with `model => 'TimesFM 3.0'` directly in the BigQuery Studio SQL workspace.

• Try AI.DETECT_ANOMALIES with `model => 'TimesFM 3.0'` for univariate time series anomaly detection in BigQuery.

• Try AI.EVALUATE with `model => 'TimesFM 3.0'` for univariate time series evaluation in BigQuery.

As a business intelligence user, this probably sounds familiar: Most dashboards only provide you with a standardized canvas and a fixed library of charts, and the “analysis” consists of a CSV export that takes you to another system. Or sometimes it's designing the dashboard that’s the challenge: You can picture the executive briefing, the customer-facing portal, or the interactive explainer that you want, but can’t assemble it out of the available grid tiles.

Either way, the solution has always been to build a custom application. The advent of AI has sped up the process — a working prototype now takes an afternoon — but the excitement of that first demo fades fast. Without access to governed data, row-level security, an infrastructure owner, or a clear path through security review, a tool written by an LLM is simply a prototype that can never go to production.

Today, to bridge this gap, we are announcing Looker Data Apps (in preview) — pairing the speed of agent-generated applications with the governance, security, and trust of your existing Looker governance framework. Describe what you need in plain language, and the agent builds it as a real, production-grade application hosted natively inside Looker!

What is a data app?

A data app is a bespoke, interactive web application generated by an AI agent and hosted natively within Looker. While dashboards provide top-down visibility, data apps serve as an active system of action designed around a specific operational workflow. A data app:

• Goes beyond standard grid tiles with pixel-perfect, bespoke layouts configured for a specific operational role or job-to-be-done.

• Enables business users to input parameters, test scenarios, run live simulations, and update underlying records.

• Connects end-to-end business processes by connecting data analysis to business execution tasks like updating source records or dispatching events to tools like Salesforce and Jira.

Expanding your semantic layer into an application platform

Data apps do not replace dashboards; they expand the boundaries of what you can build on top of your existing dashboards and semantic layer.

• Dashboards excel at aggregate visibility and passive reporting. Data apps handle active execution, letting users modify parameters and trigger downstream business tasks.

• Dashboards provide consistency using standardized chart libraries. Data apps deliver broad flexibility, unlocking custom web components and specialized interactions.

• Data apps are grounded in governed data to ensure accuracy. Whether users are reviewing a KPI dashboard or adjusting budgets in a data app, all logic is governed centrally with the LookML semantic layer to eliminate metric discrepancies and hallucinations.

Built for enterprise scale

We designed Looker Data Apps for demanding, governed enterprises. 

• Every measure is grounded in the semantic layer. Every app you build directly inherits your existing semantic models, row-level security, and access controls. Calculations stay consistent across the enterprise, and built-in query inspection lets teams audit every line of generated SQL to eliminate metric hallucinations.

• Zero-code by default. Deploy agent-generated React applications directly inside Looker with no code. Or users can use LLMs like Claude Code and Antigravity CLI to build interactive apps and deploy them as data apps in minutes.

• No runtime token costs. LLM tokens are only consumed when you’re designing or generating the app. After that, every end-user interaction runs on native Looker APIs and models. Put a data app in front of 50 people or 5,000 and the marginal cost doesn't change.

• As easy as embedding a dashboard. You can deploy your data apps into external portals using the same workflows you use to embed a dashboard. No new pipelines, no custom application code, no second permission models.

From prototype to production in minutes

The days of having to choose between basic dashboards and investing valuable engineering time to build bespoke systems are coming to an end. Instead of letting prototypes stall in sandboxes due to compliance and security barriers, Looker Data Apps allows teams to deploy governed, production-grade tools in minutes.

Looker Data Apps are now in preview. Get started today.

Imagine your compliance team notices that payments are taking longer than expected to clear. They suspect fraud, and you’re the data scientist helping figure out which transactions to investigate first. Assembling that shortlist requires ingesting and cleaning raw transaction logs, training a model on past fraud, scoring new records, and scheduling the pipeline to run daily. Here’s how you can build that workflow end to end with an agent, using the Data Agent Kit inside the Antigravity IDE.

Introducing the Data Agent Kit

Data Agent Kit helps you work with Google Cloud data through a plugin for coding agents or an extension for Visual Studio Code-based IDEs. It brings two significant additions to the workflow:

• Help for your agent: MCP tools connect your agent to data services. Skills are Markdown files that give it instructions and best practices for working with your data stack

• Tools in your IDE: work with Google’s Agentic Data Cloud, from querying databases to deploying an Airflow pipeline, without leaving your editor

Loading the data

Let’s start with the raw transaction logs in Google Cloud Storage. You can ask the agent to create a notebook that loads them into BigQuery using Spark:

The agent generates a Jupyter notebook that loads the JSON logs into a BigQuery table named raw_transactions. You can open the notebook, review the code, and run it using a preconfigured Spark Serverless runtime from the IDE.

After the notebook runs, you can open the raw_transactions table with the Data Agent Kit. The extension allows you to browse the table and inspect its metadata right from the IDE.

The records are now in BigQuery, but they aren’t ready for model training yet. First, we’ll handle duplicate and incomplete records, then join the remaining records with info about who sent and received each payment.

Cleaning it up

Let’s put the cleanup logic into a dbt project so we can run it on each new batch of data. We’ll also test that each transaction appears only once. Prompt the agent:

The agent generates a dbt project with SQL models for cleaning and enriching the data. Take a look at the generated code to check how it handles duplicates and joins reference tables. Then run dbt build in the terminal. This builds the staging and enriched tables in BigQuery, along with a separate table for records with missing transaction IDs. dbt also runs the uniqueness test.

We also keep the is_fraud column, which indicates whether a past transaction was fraudulent. We’ll train the model on records with known labels and use it to score new transactions, where we’re unsure yet whether fraud occurred.

Building the review queue

With the data prepared, let’s ask the agent to create a training notebook using a Random Forest classifier running on Spark Serverless.

Review and run the notebook, then check its evaluation output to see how well the model separates fraudulent transactions from legitimate ones. You can also use the Data Agent Kit extension to verify that the trained model artifacts were saved to Google Cloud Storage.

Now we can use the saved model to score transactions that don’t have an is_fraud value yet:

In this example, the inference notebook scores the unlabeled transactions in BigQuery and sends those with an estimated fraud probability of 50% or higher to the Spanner review queue. The flagged records help the team decide where to investigate, but they still need to determine whether fraud occurred.

Look at how the inference notebook filters and writes flagged records, then run it. Once it finishes, query the Spanner table in the IDE to inspect the results.

This table is the list we set out to build. The compliance team can now start reviewing transactions, and we have a workflow that gets records from raw logs into the queue.

So far, we have been kicking off each step ourselves. We can now connect them so the workflow runs automatically each day.

Running it again tomorrow

Each day we will load the latest logs, apply the dbt transformations, and score unlabeled transactions using the saved model. We’ll use the Managed Service for Apache Airflow to run these steps in order. Ask the agent: 

The agent generates a YAML pipeline definition and deployment configuration. The pipeline definition sets the schedule and dependencies between steps. Meanwhile, the deployment configuration specifies the Airflow environment where it will run.

Data Agent Kit then turns the definition into an Airflow DAG, which you can explore as an interactive graph in the IDE. Open the pipeline under “Orchestration Pipelines” and click a task to inspect it. For notebook tasks, you can follow the link straight back to the code.

With the Airflow environment configured, click “Run pipeline” in the canvas. Data Agent Kit packages the notebooks and dbt project, deploys the DAG, and triggers a run. Open the pipeline’s execution history to follow its progress. You can also select individual tasks to inspect their status, duration, and logs.

Airflow will run the pipeline every day, taking new batches of data from raw logs to the review queue. The compliance team can now focus on flagged transactions, and you’ve automated the work of getting those records to them!

Try it yourself

If you are ready to try this for yourself, we have designed a codelab that walks you through the full setup so you can build and run this workflow. You can also read our documentation or check out the skills and tools in the open-source repository on GitHub.

When we talk about agents, that doesn't necessarily mean we're talking about Python. In today's modern ecosystem, an agent might run as a high-concurrency Go microservice on Cloud Run, or live inside a browser tab calling Chrome's on-device model. Yet many agent frameworks assume a Python-only stack. That assumption forces teams to either spin up a Python service just for their agent workloads, or to build agent orchestration logic from scratch in their own language.

Google's Agent Development Kit (ADK) removes that trade-off with coverage for Python, Go, TypeScript, Java, and Kotlin. Each version of the ADK is built from the ground up for its own runtime and type system, while sharing a unified architecture with interoperability through open protocols.

A shared foundation

Picking a language doesn't lock in your architecture: all five support the same open protocols. ADK includes a Model Context Protocol client in every language, so a custom tool exposed as an MCP server can be called from any of them immediately.

For multi-agent systems, ADK supports the Agent2Agent (A2A) protocol, allowing an agent to communicate with a remote agent over HTTP. Through A2A, agents written in different languages or frameworks are interoperable.

Starting agent-first

To get started, run the one-time setup command to check your Google Cloud authentication, install the CLI, and then set up first-party ADK skills in coding agents like Antigravity, Claude Code, or Codex:

Then, run the scaffold command to generate a working project with A2A endpoints and deployment config for Cloud Run, Gemini Enterprise Agent Runtime, or Google Kubernetes Engine (GKE):

Both the ADK for Python and ADK for Kotlin repositories also ship agent builder skills in their source trees, and the adk.dev/llms.txt resource gives any coding agent on-demand API documentation across all five languages.

Hands-on view of each ADK

The clearest way to feel the difference between the five languages is to define the same weather tool in each one and see how its design fits the runtime.

Python

In ADK for Python, you don't need a decorator or a schema builder class. You pass a plain Python function into the tools parameter, and ADK inspects its signature, type hints, and docstring at startup to automatically construct the tool declaration and Pydantic parameter schema:

Beyond fast prototyping, Python is ADK's reference implementation, shipping the broadest set of Google Cloud integrations (BigQuery, Spanner, Bigtable) and model adapters (Gemini, Anthropic, OpenAI, LiteLLM). Paired with the adk eval or agents-cli eval run commands, its evaluation tooling scores agent trajectories against golden datasets in continuous integration (CI) to test the whole system end to end, even when your production service runs in another language.

Go

While Python leads in experimentation and evaluation, ADK for Go hits the sweet spot for production backend engineering.

A Go tool function takes the agent.Context configuration and a strongly typed input struct. The functiontool.New function uses Go generics to infer both the input and output schemas from your struct tags:

Because the functiontool.New function is generic over your handler's signature, the Go compiler verifies that your function matches the expected contract before your binary ever runs.

Go was also the first language after Python to ship the ADK 2.0 Graph Workflow runtime. When you need deterministic control flow alongside LLM reasoning, the workflow.New function wires agents and plain Go functions into a directed graph with conditional routing and parallel steps:

Where Go really stands out is in production on Cloud Run and GKE. A compiled Go agent packages onto a roughly 2 MiB Google distroless static base image, with no language VM or heavy dependency tree. A static Go binary binds to its port as soon as the container starts, skipping the module imports of dynamic languages and the JAR unpacking and JIT warmup of JVM services.

After it's running, Go's concurrency model fits agent workloads naturally. Each goroutine starts with a 2 KB stack and minimal scheduling overhead, so a single instance can multiplex thousands of concurrent streaming requests and tool calls. ADK for Go also includes built-in A2A server handlers and OpenTelemetry tracing out of the box.

TypeScript

TypeScript erases type annotations when compiling to JavaScript, so runtime reflection isn't an option. Instead, ADK for TypeScript pairs with Zod. You pass a z.object(...) schema to the FunctionTool function, and TypeScript statically infers the parameter types of your execute callback from that single declaration:

Your runtime input validation, the JSON Schema sent to the model, and your IDE autocomplete inside the execute callback all flow from one source of truth.

TypeScript also runs on the ADK 2.0 Graph Workflow engine and ships a standalone browser bundle. Beyond Node.js services, you can run an ADK agent directly in a browser tab using WebMCP for page-level tools and Chrome's on-device Prompt API.

Java

ADK for Java snaps right in for teams who have standardized on Maven, Gradle, and Spring Boot. You add @Schema annotations to method parameters and assemble agents by using a fluent LlmAgent.builder() API:

At runtime, the runner streams agent events reactively through RxJava. For local testing and existing JVM apps, ADK for Java ships a Maven Dev UI plugin alongside first-party bridges for Spring AI and LangChain4j.

Kotlin

ADK for Kotlin takes a strong stance on build-time safety. Its Kotlin Symbol Processing (KSP) compiler plugin reads @Tool and @Param annotations at build time and emits the tool schema directly into bytecode:

If a tool signature uses an unsupported type or declares a default value on a non-nullable parameter, your Gradle build fails immediately instead of breaking in production. Because the .generatedTools() function uses zero runtime reflection, it survives Android R8 shrinking.

That zero-reflection design makes it possible to run the entire agent loop locally on Android. It offers JVM server support, including a Spring AI bridge and experimental ADK 2.0 graph workflows. On-device, ADK for Kotlin integrates with LiteRT-LM for tool calling and ML Kit (Gemini Nano) for text generation. It also works with Room and AppSearch for local state, and Android AppFunctions for OS-level actions, all without requiring a network connection.

Choice without compromise

Having five native languages in ADK means you don't have to pick a single runtime for your entire organization. Because every version of ADK speaks MCP and A2A, each component of your system can use the language that fits it best.

What languages have you used to build agents with Google's ADK? Let me know what stack you're running on X, LinkedIn, or Bluesky.

脅威モデリング

AI を使用してコード セキュリティ分析を行う際の重要な最初のステップは、対象のコードベースの脅威モデルを確立することです。ソフトウェア アーキテクチャは千差万別であり、脅威モデルがなければ、攻撃ベクトル、ビジネス ロジック、到達可能性といった重要なコンテキストを見失うおそれがあります。

従来のソースコード レビュー エンジンが画一的なパターン マッチング ルールに依存するのに対し、LLM には、標準権限ユーザーがアクセスできるコード、管理者限定のコード、あるいはまったく実行されないコードを識別できるという明確な優位性があります。

パイプラインは、探索エージェントをディスパッチして、ターゲット コードベースの主な目的を特定することから始まります。このエージェントは、ソフトウェア ドメイン（ウェブやデスクトップ アプリケーションなど）を判別し、検出されたドキュメントを確認します。また、スキャンから除外すべきディレクトリ（単体テストを含むものなど）にフラグを立て、スペシャリスト探索サブエージェントをディスパッチします。

スペシャリスト探索サブエージェントは、認証、認可、ルーティング、その他のドメイン固有のカテゴリなど、それぞれの専門分野を掘り下げます。これらの出力は、脅威モデル合成エージェントに渡され、検出結果が一貫性のある脅威モデルへと集約されます。

この段階の分析が完了すると、次の工程に進む前の検証用として、脅威モデルのテキスト情報と図解の両方がコンサルタントに提示されます。この承認ゲートにより、パイプラインの残りの部分が正確な基盤に基づいて動作することが保証されます。

図 3 は、ハーネスによって生成されたビジュアル脅威モデルのレイアウト例であり、どのアプリケーション コンポーネントが公開され、それらがどのように接続されているかを示しています。

エントリ ポイントの検出

脅威モデルを確立した段階で、並列化された検出エージェントをデプロイして、スコープ内のすべてのファイルを分析します。これらのエージェントは、軽量な Gemini Flash Lite モデルを活用してコードを大規模に処理することで、HTTP ルートやプロセス間通信（IPC）リスナー、その他のドメイン固有の攻撃ベクトルといった、アプリケーションの重要なエントリ ポイントを抽出します。同時に、これらの特定されたエントリ ポイントにネストされている、ユーザー入力の特定可能なすべてのソースを分離して抽出します。

コンテキストの拡充

分析対象のエントリ ポイントが選択されると、ハーネスはそれぞれを専用の拡充エージェントに割り当てます。エンタープライズ アプリケーションでは、エントリ ポイントを個別に分析するだけでは不十分なことがほとんどです。というのも、サニタイザー、権限、ルーティング条件といった重要なコンポーネントは、高度に分散していることが多いからです。

さらに、脆弱性は、ネストされた関数呼び出し、複数のホップ、最初のソースから離れたファイルの奥深くに隠れていることがよくあります。このギャップを埋めるために、拡充エージェントはコードベースを探索し、割り当てられたエントリ ポイントのコンテキストに関連するコードを集約します。この集約されたデータを評価し、エントリ ポイントに対して、アクセス制御エージェントやデータフロー分析エージェント、あるいはその両方によるさらなる分析が必要かどうかを判断します。

Hypothesis Generation

効果的なコード分析ができるかどうかは、制御フローとデータフローという 2 つの主要な特性をいかに把握できるかにかかっています。制御フローがタスクと命令の実行順序を規定するのに対し、データフローはアプリケーション全体で情報がどのように移動し、変換されるかを追跡します。

AVDH はこれらの重要なタスクを、アクセス制御エージェントとデータフロー分析エージェントにそれぞれ委任します。

この段階では、これらのエージェントは最小限の自己検証を行います。主な目的は、広範なブレインストーミングです。生成される膨大な数の仮説を管理するために、このクリエイティブ プロセスは、コンサルタントが構成した信頼度フィルタによって制御されます。

アクセス制御エージェントは、ターゲットとなるエントリ ポイントに適用されている保護機能を評価し、アプリケーション ユーザーに対する全体的なアクセス性を判定します。その主な目的は、セキュリティの前提条件を検証し、特権機能が制限されているか、権限のないユーザーに誤って公開されていないかを確認することです。この分析により、チェックの未実施や誤った ID に対する検証といった欠陥が浮き彫りになります。これには、認可の欠落、権限昇格、クロスサイト リクエスト フォージェリ（CSRF）などが含まれます。

一方、データフロー分析エージェントは、最初の入力ポイントからアプリケーション全体にわたるユーザー入力の流れを追跡します。具体的には、ネストされた関数呼び出し、サニタイザー変換、データベースなどのストレージ境界を通過するデータをトレースします。

エージェントの目標は、このユーザー提供データが危険な「シンク」（悪意のある入力が行われて害を及ぼす可能性がある関数）に到達するかどうかを判断することです。この詳細なトレースにより、SQL インジェクション、クロスサイト スクリプティング（XSS）、コマンド インジェクション、パス トラバーサルなどの脆弱性クラスが明らかになります。

仮説の検証

ターゲット コードベースの仮説が生成されると、ハーネスは新しいエージェント セットをディスパッチして仮説を検証します。LLM では、Temperature パラメータが出力の変動性とランダム性を左右します。Temperature が低いと予測可能で安定した回答が得られる一方で、値が高いと毎回大きく異なる結果が生成されるようになります。

ハーネスではこの特性を活かし、高い Temperature 設定で構成された複数の 検証エージェントをディスパッチして各仮説を評価します。それと並行して、1 つの検証合成エージェントが、これらのエージェントの判定を処理して最終的な決定を下します。Temperature を高く設定することで、予測可能な期待どおりの回答にとどまらず、より幅広い可能性を検証できるようになります。最終的に、この Temperature 設定によって、最終判断を下すエージェントには、より豊富で包括的なコンテキストがもたらされます。

合成エージェントは、検証エージェントによる推論内容と判定結果を評価し、仮説が Mandiant の厳格な品質基準を満たしているか、また全体的な脅威モデルと整合しているかを判断します。その結果、次の 3 つのいずれかの結論に至ります。

• 確認済みの検出結果: 仮説は妥当であり、検証エージェントによって個別に実証されています。

• 反証された仮説: 検証エージェントが、欠陥の妥当性を否定する重大な矛盾証拠を明らかにしました。

• 却下された仮説: 仮説が確立された脅威モデルと整合しないか、脆弱性として認められません。

人間による専門的知見

専門家による検証

ハーネスが確認済みの検出結果を重複排除し、リスク評価を行った後、人間の専門家による厳格なレビューを行い、分析を継続します。Mandiant は、エクスプロイトを動的に再現し、概念実証（POC）コードを実行することで、AI の想定が正確であるか、また攻撃パスを阻害する未知の補完的コントロールが存在しないかを確認し、デュー デリジェンスを徹底しています。

検証が完了すると、コンサルタントは AI が生成した検出結果を自身の専門的な分析と統合し、正式な開示に向けた準備を整えます。逆に、この動的テストフェーズをクリアできなかった検出結果は破棄されます。

同様の脆弱性発見ハーネスの実装を検討しているネットワーク防御担当者の方には、検出結果を手動で検証することをおすすめします。

蒸留された知識

人間参加型の検証によって、確認された検出結果の偽陽性を効果的に最小限に抑えることはできますが、依然として偽陰性への対処も必要です。

AI エージェントが脆弱性を見逃していないかどうかを判断するために、Mandiant の専門知識を分析パイプラインに直接注入するルールベースのアプローチを設計しました。これは、スキル エンジニアリングのコンセプトと同様に、コンサルタントの集合知から抽出された高度に専門化されたプロンプトを使用します。

この人間の知性を AI 主導の分析に直接統合することで、結果の精度が大幅に向上します。このナレッジ システムのモジュール性とスケーラビリティを維持するため、ソフトウェア ドメインを最上位とし、その下に言語、フレームワーク、脆弱性という 3 つの主要なルールカテゴリを配した階層構造を採用しました。

成果の測定

エージェントによるコード分析パイプラインを維持し、継続的に改善するには、正確なベンチマークと評価が不可欠です。Mandiant は、オーケストレーション ハーネスのパフォーマンスを測定するための厳格な社内手法を開発しました。これにより、プロンプトの調整やルールの更新が、品質の劣化を招くことなく、データに裏付けられた改善を常に確実にもたらすようにしています。

コード分析パイプラインの進捗と有効性を評価するために、同様のベンチマーク システムを実装することをおすすめします。

ベンチマークの目標

公開されているコード脆弱性データセットは存在するものの、トレーニング データの汚染は、LLM を評価するうえでの大きな課題となっています。最新のフロンティア モデルは、すでにこれらの公開リポジトリを学習に取り込んでいる可能性があるため、モデルが脆弱性を真に推論しているのか、それとも記憶した解決策を単に呼び出しているだけなのかを判断することはほぼ不可能です。

高忠実度の評価を確保するために、Mandiant は独自の合成コードベースのスイートを開発しました。これらのカスタム ベンチマークは、ソフトウェア ドメイン、プログラミング言語、脆弱性の深さ、そして従来のモノリスから最新のマイクロサービスに至るアーキテクチャまで、多岐にわたる分野を網羅しています。

特筆すべきは、Mandiant のセキュリティ コンサルタントが、注入されたすべての脆弱性を手動で検証し、実際に到達可能で動的に悪用可能であることを担保している点です。ハーネスとその基盤となるプロンプトをチューニングする際には、厳格なレビュー プロセスを徹底し、AI がこれらのベンチマーク コードベースに過学習するのを能動的に防止しています。

ベンチマークの採点

Mandiant の採点プロセスでは、AI による評価と、専門家による人間参加型のレビューを組み合わせています。ハーネスがベンチマーク ディレクトリを分析すると、出力は専用の採点エージェントに渡されます。この採点エージェントは、パイプラインの検出結果をグラウンド トゥルース データセットと照らし合わせて評価します。そこでは、曖昧な意味的類似性に頼るのではなく、脆弱性の正確な一致を厳格に求めます。

その後、採点パイプラインは分岐してエッジケースを処理します。

• 偽陽性のトリアージ: グラウンド トゥルースにマッピングされないハーネスの検出結果は、セカンダリ エージェントにルーティングされ、偽陽性か正当な脆弱性かが確定的に分類されます。

• 重複の解消: パイプラインが単一のグラウンド トゥルースの問題にマッピングされる複数の検出結果を生成した場合、別のエージェントがそのクラスタを分析し、検出結果が重複しているかどうかを判定します。

最後に、人間の専門家が採点済みデータを手動で確認することで、AI による判定の精度を検証します。Mandiant は、ハーネスのメジャー リリースごとに、複数のドメインとアーキテクチャにわたってこの厳格なテストサイクルを実施しています。その際、LLM 固有の非決定性を考慮し、結果を平均化することで精度の安定を図っています。

フレームワークと言語のルールはパイプライン全体に適用され、対象のコードベースで採用されている特定のテクノロジーに関するコンサルタントの知見をエージェントに提供します。これらのルールは、一般的なエントリ ポイントの定義パターンや固有の攻撃対象領域といった重要な詳細を網羅しており、脅威モデリングに不可欠なコンテキスト情報も併せて提供します。

対照的に、脆弱性ルールはパイプラインの最終段階でのみ適用され、特定の種類の脆弱性をどのように検出し、検証し、リスク評価すべきかを厳密に定めています。この構造化されたシステムにより、分析パイプライン全体に Mandiant の専門的知見が反映されます。しかもそれは、保守性と高度なモジュール性を備えた形で実現されています。

まとめ

ソフトウェア開発パイプラインのセキュリティ確保は、現代の企業防衛における極めて重要な課題となっています。Mandiant の継続的な調査により、防御者は敵対的 AI の急速な能力向上への対応において、極めて困難な課題に直面していることが明らかになっています。

こうした新たな脅威に対抗するには、コード パイプラインの保護が最新の防御戦略における不可欠な要素でなければなりません。手動によるソースコード レビューでは AI のスピードに追いつけず、従来のスキャン エンジンでは、最新のソフトウェアに潜む広範な脆弱性を常に見逃してしまいます。

しかし、このハーネスの成功は、防御者が敵対的 AI に対して再び優位に立てることを実証しています。専門家が定義したハーネスにフロンティア モデルを組み込むことで、防御者は定型的な脆弱性の検出を自動化できます。

こうした定型的な検出結果を処理することで、ソースコードの可視性はスケーラブルな防御へと進化します。これにより、コンサルタントなどの防御者は単純作業から解放され、複雑な欠陥の分析に完全に専念できるようになります。このハーネスを構築し、改良を重ねるなかで確信したのは、AI の真価は、人間の専門知識を何倍にも高めるマルチプライヤーとして活用したときにこそ発揮されるということです。

Mandiant のツールは、スポット的な評価や、プロアクティブで詳細な脆弱性調査を目的として構築されました。一方で、最近のブログ投稿では、CodeMender が AI による継続的なモニタリングをソフトウェア開発と脆弱性管理に提供し、このツールをいかに補完するかについて解説しています。これらの機能をすぐにデプロイして活用したい組織のために、Google AI Threat Defense は常時稼働のプラットフォームを提供しています。これには CodeMender のコードスキャンと修復機能が含まれており、システムの分析、脅威の優先順位付け、脆弱性へのパッチ適用、そして新たな攻撃の継続的な監視を可能にします。標的を絞った深層分析を行う AVDH と、CodeMender による継続的なスキャンを組み合わせることで、2 層構造の防御戦略を実現します。このアプローチでは、複雑な攻撃チェーンに対してスポット的な修復を活用しながら、開発ライフサイクル全体にわたって継続的な可視性を維持します。

実際の環境でのパイプライン構築とデプロイの詳細にご興味はありませんか？2026 年 9 月 15 日～16 日にワシントン D.C. で開催されるサイバー防御サミットにぜひご参加ください。Mandiant は「How Mandiant Orchestrates Gemini to Find Zero-Days Before Adversaries」（Mandiant が Gemini をオーケストレートして、敵対者よりも先にゼロデイを見つける方法）というプレゼンテーションを行います。ライブデモの実演、エージェント ワークフローの導入から得られた知見の共有、AI による攻防能力の未来についての議論などをお届けします。サミットには、こちらからご登録ください。

- Google Threat Intelligence Group