Back to Archive

GCP News - 2026-09-18

2026-09-18
最終更新: 2026-09-22 12:25:12 JST

AI による概要

12 記事

この日は 10 件で、ロードバランサーとモデル保護の更新、脅威インテリジェンスの評価、データ基盤の事例が中心でした。リリースノートでは、Cloud Load Balancing のバックエンド mTLS 向けマネージドワークロード ID が、グローバル外部・リージョン外部・クロスリージョン内部・リージョン内部の各アプリケーションロードバランサーで一般提供となり、Certificate Authority Service と Certificate Manager との統合で証明書と信頼の管理を自動化し、ワークロード ID プールの設定に基づいて証明書が自動ローテーションされます。Model Armor はフィルターバージョン v4 が公開されて Latest エイリアスの既定となり、v3 が Stable エイリアスへ昇格しました (asia-northeast3 では v1 が Stable のまま、australia-southeast2 では 2026 年 9 月 25 日に v3 が Stable になります)。Stable エイリアスを使うテンプレートは自動的に v3 へ更新されます。Google Cloud ブログでは、Google が Forrester Wave: External Threat Intelligence Service Providers, Q3 2026 のリーダーに選出され、9 つの評価基準すべてで満点の 5.0 を獲得したことが発表されました。事例では、Lucius AI が 5 大陸の入札情報 (21 万件超) を扱う調達インテリジェンスの基盤全体を、単独運営者で AlloyDB for PostgreSQL 上に構築し、セマンティック検索を ScaNN インデックスへ移行してクエリレイテンシを 1.14 秒から 24 ミリ秒 (47 倍) に短縮、MCP を通じたデータベース運用の自動化も実現しました。Pine59 は最大 1,400 万か所の位置情報を扱う日次の人流指標パイプラインを、Apache Airflow 3 を搭載した Managed Service for Apache Airflow (旧 Cloud Composer) へ移行した経緯が紹介されています。日本語ブログ (抄訳) では、Data Agent Kit によるエージェント駆動の問題分析、Antigravity SDK によるエージェントハブ構築、Airtel の IPL 2026 配信 (トラフィックの 99.9% をインド国内から配信、キャッシュヒット率 98% 超)、AlloyDB Omni RPM オーケストレーターの GA、DMS で移行されない SQL Server のログインとユーザーの移行、Forrester Wave Public Cloud Platforms Q3 2026 でのリーダー選出が紹介されました (いずれも前週までに紹介済みの内容の抄訳です)。日本語ブログでは Google Maps Platform の発表が 2 件加わりました。1 つは業務効率化に向けた 3 プロダクトで、ドライバーを Google マップや Waze など好みのアプリへ渡しつつリアルタイムの位置情報・到着予定時刻・ルート外れのアラートを自社プラットフォームへ返し続ける Navigation Connect API (プレビュー)、実際の移動時間に基づいて到達可能範囲をマッピングする Isochrones API (プレビュー)、ユーザージャーニーをアプリ内で完結させる Places UI キット Pro (Android と iOS のモバイル SDK は一般提供、ウェブ版は今秋予定) です。もう 1 つは米国で一般提供が始まった大型車両向けルート検索 (LVR) で、Routes API・Route Optimization API・Navigation SDK において、高さ・重量・長さ・幅・車軸数・危険物の分類といった車両プロファイルを指定し、高さ制限のある橋や狭いトンネルなどの道路上の制約をルート検索のロジックに直接取り込んで、大型車の走行速度とリアルタイム/予測の交通データを組み合わせた到着予定時刻を算出できます。

主要トピック

  • ネットワーク: Cloud Load Balancing のバックエンド mTLS 向けマネージドワークロード ID が GA、証明書を自動ローテーション

  • AI 保護: Model Armor のフィルター v4 が Latest の既定に、v3 が Stable へ昇格 (australia-southeast2 は 2026-09-25)

  • 評価: Google が Forrester Wave External Threat Intelligence Service Providers Q3 2026 でリーダー、9 基準で満点 5.0

  • 事例: Lucius AI が AlloyDB の ScaNN インデックスで検索レイテンシを 1.14 秒から 24 ミリ秒 (47 倍) に短縮し MCP で運用を自動化

  • 事例: Pine59 が Airflow 3 の Managed Service for Apache Airflow へ移行、最大 1,400 万か所の人流指標を処理

  • 抄訳: Data Agent Kit、Antigravity SDK、Airtel の IPL 2026 配信、AlloyDB Omni RPM、SQL Server ログイン移行、Forrester Wave Public Cloud (前週まで紹介済み)

  • 位置情報: Navigation Connect API と Isochrones API をプレビュー公開、Places UI キット Pro はモバイル SDK が一般提供

  • 物流: 大型車両向けルート検索 (LVR) が米国で GA、車両プロファイルと道路制約を考慮したルートと到着予定時刻

AI (Claude Opus 5) が生成 · 2026-09-23 08:18:32 JST

Google Cloud Release Notes

September 18, 2026

詳細を表示

Cloud Load Balancing

Feature

Managed workload identity for backend mTLS is generally available for the following Application Load Balancers:

  • Global external Application Load Balancers
  • Regional external Application Load Balancers
  • Cross-region internal Application Load Balancers
  • Regional internal Application Load Balancers

The key benefits are as follows:

  • Streamline certificate management: Automated certificate and trust management for backend mTLS through seamless integration with Certificate Authority Service and Certificate Manager.

  • Eliminate operational toil: Certificates are automatically rotated based on the workload identity pool's configuration, removing the complexity and manual bottleneck of private key provisioning and maintenance.

  • Improve visibility and governance: Gain visibility into communication between distributed services and proactively apply governance to workloads across environments.

For more information, see Backend mTLS with managed workload identity overview

Model Armor

Feature

Filter version v4 is available and set as the default for the Latest alias. Filter version v3 is promoted to the Stable alias in all supported regions except the following:

  • In asia-northeast3, v1 remains the Stable version.
  • In australia-southeast2, v3 becomes the Stable version on September 25, 2026.

If your templates use the Stable alias, they automatically upgrade to v3 when v3 becomes Stable in that region.

Filter versions v1 (except in asia-northeast3, and starting September 25, 2026 in australia-southeast2) and v2 transition to Legacy status and retire on December 17, 2026. If your templates are explicitly configured with v1 or v2 in regions where those versions are in Legacy status, you must migrate them to v3 or the Stable alias before December 17, 2026.

For more information, see Version release timeline and Model Armor filter version history.

Google Cloud Blog

How a solo founder runs a five-continent tender platform on AlloyDB and MCP

詳細を表示

Editor's note: Lucius AI, a tender-intelligence startup covering markets across five continents, runs its entire data platform on AlloyDB for PostgreSQL with a single operator. By migrating semantic search to a ScaNN index and managing database operations through Model Context Protocol (MCP), query latency dropped by 47x while automating day-to-day administrative tasks via MCP.

Executive summary

  • Lucius AI runs a global tender platform spanning more than 210,000 tenders across the UK, EU, India, and Australia, requiring minimal operational overhead for a solo founder.

  • Lucius AI deployed AlloyDB for PostgreSQL to consolidate its relational catalog, audit logs, and vector embeddings into a single managed database engine.

  • Migrating semantic search to a ScaNN index lowered query latency from 1.14 seconds to 24 milliseconds — a 47x speedup on a representative production query.

  • Connecting an AI agent to AlloyDB using the Model Context Protocol (MCP) helps Lucius AI automate query analysis, data freshness checks, and incident forensics under strict least-privilege permissions.

Making tender intelligence work as a company of one

Lucius AI helps businesses bidding on public contracts evaluate opportunities across global markets. The platform ingests public procurement notices from the UK, the EU, the US and Canada, Australia and New Zealand, India and Singapore, alongside World Bank donor-funded notices across Africa and Asia. Lucius AI analyzes tender documents using Gemini to generate compliance matrices, bid recommendations, and draft responses citing original source pages. For small and mid-sized suppliers, this replaces days of manual document reviews and costly external consulting.

Running a platform of this scope requires extensive operational coordination:

  • Nightly ingestion from thirteen public procurement sources

  • A catalog of more than 210,000 tenders, including tens of thousands open for active bidding

  • Two production regions on Cloud Run: Europe, and an Australian deployment on its own AlloyDB cluster with customer-managed encryption keys (CMEK) for defense-adjacent customers

  • Ongoing analytics, performance tuning, data validation, and incident response

Managing these responsibilities without dedicated data engineering or database administration teams requires offloading operational maintenance. Lucius AI addressed this challenge on two fronts: using AlloyDB for PostgreSQL as the core system of record, and connecting an AI agent through the Model Context Protocol (MCP) to safely execute database operations.

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


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

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


  </div>
</div>

Consolidating systems into AlloyDB

Rather than deploying separate relational databases, vector databases, and log stores, Lucius AI houses all core data in AlloyDB for PostgreSQL. The relational tender catalog, document metadata, audit logs, and vector embeddings reside in the same database engine. Storing vector embeddings alongside relational rows avoids managing separate vector stores, establishes a unified backup schedule, and centralizes identity management.

Authentication relies strictly on Cloud IAM. Services connect using dedicated Google Cloud service accounts mapped to database roles scoped to specific access requirements, without storing database passwords in application environments. Database reliability is managed natively by AlloyDB through automated backups and point-in-time recovery, avoiding custom disaster recovery procedures.

In production, this consolidated architecture supports:

  • More than 210,000 tenders in the catalog, with embeddings stored directly alongside them

  • Rebuilding the semantic index embedded 115,820 records in 10.6 minutes with the Gemini embedding model, for around three dollars in API spend; AlloyDB auto embeddings now keep those vectors current.

  • Retrieval reranking executed directly inside the database using the ai.rank function — with mean latency of 77-milliseconds - returning the most relevant results for search queries without requiring a standalone reranking microservice

Accelerating semantic search by 47x

Semantic search across the tender catalog initially relied on unindexed vector comparisons, where a representative query took 1.14 seconds. Migrating this workload to a ScaNN index in AlloyDB reduced query latency to 24 milliseconds — a 47x improvement.

The index recommendation originated from the AI agent during an automated performance audit, where it benchmarked the query plan before preparing the index migration.

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


  </div>
</div>

Automating database operations with MCP

To delegate routine administrative tasks, Lucius AI configured the open-source MCP Toolbox for Databases using the prebuilt alloydb-postgres server.

Operational delegation requires strict access controls. The agent connects using a dedicated PostgreSQL role granted SELECT across the schema and UPDATE on a single operational table. Destructive commands (DROP, DELETE, TRUNCATE) are omitted, restricting agent actions to authorized operational boundaries.

Under this configuration, the AI agent performs regular database operations across four key areas:

  • On-demand analytics: Compiles retention cohorts, activation funnels, and catalog coverage by country via ad hoc SQL queries, removing the need to build and maintain manual dashboards or complex analytical pipelines.

  • Performance optimization: Performs query-plan inspections and index analysis, such as identifying the ScaNN indexing strategy.

  • Incident forensics: In response to an external security probe, the agent parsed audit logs to reconstruct the request timeline in minutes, verifying that tenant isolation remained intact.

  • Automated data-quality checks: Evaluates ingestion watermarks and freshness across all thirteen procurement sources every morning.

<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/original_images/3_MXwqVC6.gif" />
    
    </a>
  
</figure>


  </div>
</div>

For teams adopting this architecture, establishing a progressive permission structure provides clear guardrails: start with read-only access, expand permissions as requirements dictate, and keep destructive operations restricted to human administrators.

Looking ahead

Lucius AI is planning three technical initiatives to further reduce operational overhead:

  1. Automated vector embeddings in AlloyDB AI: After validating ai.initialize_embeddings across the full catalog, a weekly maintenance job uses ai.refresh_embeddings to update vectors.

  2. Columnar engine acceleration: Having enabled AlloyDB’s columnar engine with auto-columnarization, the database identified and stored 40 frequently queried columns across four tables in memory within a day, accelerating reporting queries without a separate analytical store.

  3. Managed Remote MCP Server: Transitioning from self-hosted Toolbox processes to Google Cloud's fully managed Remote MCP Server for AlloyDB will offload MCP server hosting and maintenance.

By anchoring core data in AlloyDB and managing routine operations through MCP, Lucius AI demonstrates how a single engineer can build and operate a resilient, multi-region procurement platform.

To explore Lucius AI, visit ailucius.com. To evaluate AlloyDB for PostgreSQL, deploy an AlloyDB cluster to test performance against your own workloads.

Google named a Leader in the External Threat Intelligence Service Forrester Wave™

詳細を表示

At Google, we see firsthand how the speed, scale, and sophistication of cyber threats continue to challenge traditional enterprise defenses. Today’s defenders can’t rely on reactive triage or fragmented data feeds; you require high-fidelity intelligence, deep underground visibility, and actionable context to anticipate adversary moves before an attack unfolds.

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

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







  <p>We are proud to announce that Forrester has named Google a Leader in The Forrester Wave™: External Threat Intelligence Service Providers, Q3 2026. In this evaluation, Google received the highest possible score of 5.0 across nine distinct criteria spanning both Current Offering and Strategy.</p><p>Organizations trust our decades of threat intelligence expertise to help them understand today’s attacks and to protect against tomorrow’s threats. <a href="https://cloud.google.com/security/products/threat-intelligence">Google Threat Intelligence</a> operationalizes protection with specialized threat intelligence agents that autonomously conduct multi-step investigations and malware analysis at machine speed. Underpinning these capabilities is the unified visibility provided by Mandiant’s frontline incident response, VirusTotal’s crowdsourced visibility, and Google-scale infrastructure with industry-leading deep and dark web monitoring, illuminating adversary operations where they begin.</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="2-graph" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/2-graph.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Google is a Leader in the Forrester Wave™: External Threat Intelligence Service Providers, Q3 2026</p></figcaption>
  
</figure>


  </div>
</div>

Key attributes of a leader

Accurate and relevant deep and dark web monitoring enables proactive security, spotting exposed credentials, threat actor reconnaissance, and illicit forum chatter before they escalate into active attacks. 

We received the highest possible score in the Deep and Dark Web Monitoring and Intelligence Collection Sources criteria. 

As Forrester wrote in the report, “Google is the only vendor in this evaluation that is also a frontier AI model developer and a significant player in quantum computing.” 

Because Google Threat Intelligence has direct access to a leading frontier model rather than an off-the-shelf wrapper, our AI agents don’t just summarize data — they can actively evolve. We fine-tune and stress-test our agents continuously using proprietary Gemini best practices, removing the usage limits and latency typical of third-party layers. 

For security teams, this translates directly to immediate threat context, faster detection updates, and drastically reduced time to resolution. The Forrester report stated, "Google's recent Gemini advancements accelerated the success of many of its Al-enabled functionalities." In addition to our finished intelligence reports, defenders can now use our agent to create custom analysis derived from frontline observations, tailored to their local threat profile and environment.

Google Threat Intelligence agents autonomously conduct campaign attribution and pioneer complex agentic malware analysis. Backed by codified Mandiant tradecraft, dynamic visual workflows, and real-time telemetry that programmatically hardens tool routing and execution, our agentic platform transforms complex threat landscapes into a decisive defender advantage.

Google received the highest scores possible in the Analyst Tradecraft and Services, Attribution and Frameworks Used, and Analyst Experience criteria in the report. This foundation is built by hundreds of dedicated researchers across the Google Threat Intelligence Group (GTIG) in over 30 countries speaking 30 languages. Our rigorous, evidence-based attribution maps directly to MITRE ATT&CK, empowering practitioners through interactive graphs and Gemini-enabled agentic threat intelligence. 

By feeding the newest threat discoveries into detection workflows, these capabilities raise alert quality and take the guesswork out of rule creation across the security stack. Security operations center (SOC) teams and threat hunters can rapidly author resilient rules against novel variants, link suspicious events directly to known actor playbooks, and triage critical alerts with certainty. 

While Google also received a 5/5 score in the partner ecosystem criterion, customers using Google Security Operations can directly leverage Google Threat Intelligence enrichments with agents: 

  • The Triage and Investigation agent autonomously investigates alerts and prioritizes threats. 

  • The Detection Engineering agent automatically finds and fills coverage gaps as they emerge. 

  • The Threat Hunting agent proactively searches your environment for novel attack patterns.

Within the strategy category, Google Threat Intelligence received the highest possible scores in the Roadmap, Partner Ecosystem, and Community criteria, as well as the Intelligence Dissemination criterion in the Current Offering category. 

The Forrester report stated, “Google maintains an open, partner-centric approach that avoids lock-in to the Google SecOps ecosystem and benefits from a strong community presence across the broader Google Cloud Security ecosystem.”

Delivering measurable value for security teams

Google Threat Intelligence delivers a measurable impact on the speed and scale of modern defense. Our customers report identifying 139% more threats proactively and make their CTI teams 46% more efficient. These gains are accelerated by AI-driven summarization and context, and can help you eliminate manual guesswork, act on validated frontline intelligence, and focus on high-value investigations.

By accelerating detection engineering and proactive exposure management, Google Threat Intelligence identifies malicious infrastructure before adversaries can use it in campaigns. This faster defense helps you anticipate their maneuvers and disrupt their attack chains earlier, reducing threat dwell time and risk to your organization.

Empowering defenders everywhere

We are very pleased that Forrester recognized us as a Leader in Forrester Wave™: External Threat Intelligence Service Providers, Q3 2026. We continue to push the boundaries of what is possible in threat research, as an early, leading innovator enhancing malware analysis and dark web monitoring with AI. We continue to deliver the autonomous decision advantage to preemptively neutralize the right threats with the right action and the right context.

To learn more about Google’s position as a Leader, you can access the full Forrester Wave™: External Threat Intelligence Service Providers, Q3 2026 here.

Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here .

The future of orchestration: Pine59’s journey to Airflow 3 on Google Cloud

詳細を表示

Operating large data pipelines requires an orchestration layer that scales smoothly as workloads expand. When your pipelines process millions of complex data points every day to feed predictive models, staying up-to-date with your technology stack is a strategic necessity.

Pine59 provides location intelligence data through data pipelines that produce analytical metrics on cadences ranging from hourly to quarterly. One of the company’s most data-intensive metrics, Daily Foot Traffic, computes data for as many as 14 million distinct locations in a single job. To handle this massive volume, Pine59’s system runs entirely on Google Cloud, with the heavy lifting in BigQuery and all of it orchestrated by Managed Service for Apache Airflow (formerly Cloud Composer) running Apache Airflow 3.

As the company’s volume of data and number of machine learning workloads scaled up, Pine59 decided to modernize its monorepo, which contains hundreds of directed acyclic graphs (DAGs). Here is a look at how that transition improved Pine59’s MLOps capabilities, developer workflow, and pipeline speed.

Proactive modernization for growth

Pine59 has long relied on a shared monorepo with code and tooling spanning multiple projects to run its metric production pipelines. As it considered its infrastructure’s future, the company wanted to help its data pipelines run faster and more reliably.

That’s why it decided to stress-test production workloads against the newly available Managed Airflow (Gen 3) architecture running Airflow 3. The initial results were unambiguous: the Gen 3 environment delivered immediate and significant processing speed, task scheduling, and overall stability improvements. Recognizing the clear potential for performance gains, Pine59 initiated a full transition to the new environment.

<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 - Pine59 Google Cloud Architecture Vertical Version" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/Vertical_Version_yyTMhsG.max-1000x1000.jpg" />
    
    </a>
  
</figure>


  </div>
</div>

Orchestrating advanced MLOps

Pine59’s pipelines don’t just move data; they drive complex ML models, so a core aspect of its migration was optimizing the orchestration of its ML inference workloads.

Previously, Pine59 had used standard Kubernetes operators for these tasks. By moving to Managed Airflow (Gen 3), which features a highly optimized and abstracted infrastructure layer, the company’s engineering team refined its MLOps architecture. They did so by setting up a dedicated Google Kubernetes Engine (GKE) cluster that was specifically optimized for model inference and integrated it into the Pine59 pipelines.

This clear separation of orchestration and heavy ML execution compute allows data processing and model inference to run efficiently, showcasing Managed Airflow as a resilient, scalable backbone for enterprise MLOps.

Supporting developers with custom extensibility

Beyond infrastructure improvements, Pine59 was also able to immediately capitalize on Airflow 3’s delivery of a vastly improved developer workflow and user interface. Indeed, managing hundreds of interconnected DAGs requires excellent observability, and Pine59 found Airflow 3’s plugin authoring system remarkably easy to use.

To improve internal developer velocity, the company quickly built a number of custom plugins that it integrated directly into its new Airflow UI:

  • BigQuery Auto-linkify: A tool that automatically detects internal BigQuery table references within the Airflow Logs and XCom tabs, dynamically generating direct links to BigQuery Studio for faster debugging (available as a public GitHub gist)

  • DAG Run Configuration Search: A custom search form added directly to the DAG overview page. It allows Pine59 engineers to query specific key-value pairs within DAG run payloads (configs) and instantly surface matching runs. This in turn drastically reduces troubleshooting time.

In addition, the team also deployed a compatibility shim layer within its monorepo. This “compat” module dynamically abstracts logic between Airflow versions, streamlining operator migration across versions.

Faster, more reliable pipelines

For Pine59, migrating to Managed Airflow (Gen 3) with Airflow 3 has yielded clear, quantifiable results.

The most important improvement was the speed of its DAG runs. In the company’s previous setup, tasks often got stuck in a queued state during peak processing surges. With Gen 3, queue latency has dropped dramatically, allowing tasks to start running almost immediately.

Consider the comparison below of total aggregated “queued” & “running” time of more than 300 runs of the same DAG between Managed Airflow (Gen2) with Airflow 2.11 vs. Managed Airflow (Gen3) with Airflow 3.1 below. As we can readily see, the difference in queued time is significant.

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


  </div>
</div>

Coupled with internal DAG optimizations made during the transition, the performance gains are also highly tangible. For example, the Daily Foot Traffic pipeline previously took nearly 38 minutes to complete. With the new instance, the same workload now takes less than 26 minutes —nearly 32% less processing time.

Today, Pine59 processes all its production workloads on its new Managed Airflow (Gen 3) instance. By moving to this next generation orchestration, the company improved its MLOps capabilities, equipped its developers with better tools, and built a faster, more resilient foundation for future workloads.

If your engineering team spends more time managing infrastructure than delivering value, consider a similar transition and discover how it can help you move from maintaining servers to building the future of your data and AI pipelines today.

Special thanks to the following contributor to this post: Alexandre Crespo-Perez

Google Cloud Japan Blog

Data Agent Kit でエージェントを駆使した問題分析

詳細を表示

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

想像してみてください。月曜の朝、出社早々、上司からチャット メッセージが入ります。曰く、「1 月の平均注文額は 7% 減だけど、総収益は横ばいだね。なんでかな？」

データ実務者であれば、このような質問が一筋縄ではいかないことは、よくご存じなのではないでしょうか。しかも、答えは単純明快ではありません。根本原因を示す単一のダッシュボードがあるわけでもありません。ウェブのログにエラーが記録されているのか。プロモーション コードの設定に誤りがあったのか。深掘りするまで皆目見当がつかないし、1 か所や 2 か所、調べただけでは答えはまず見つからないでしょう。

答えにつながる鍵は、環境内のさまざまな領域に散在しています。

  • 販売履歴（注文と明細項目）はデータ ウェアハウスに保存されています。

  • 有効な顧客レコードは本番環境の PostgreSQL インスタンスに保存されています。

  • マーケティング キャンペーン ルールは、オブジェクト ストア内の未加工 JSON ファイルに保存されています。

これらの情報を引き出すクエリを 1 つだけ作成するなら簡単です。実際には、同じクエリを何度も記述し、WHERE 句を調整したり、サブクエリを追加したりして、答えを見つけ出す必要があります。1 つのシステムが終わったら次のシステムに移動し、別の方法で再びクエリを行います。気づけばブラウザのタブが 10 個も開いていて、1 つの質問に答えるだけで丸一日がつぶれてしまいます。

Data Agent Kit

まさにこのような問題を解決するために構築されたのが、Data Agent Kit です。MCP サーバーとエージェント スキルを組み合わせた Data Agent Kit を使用することで、データ デベロッパーは IDE からデータ ワークフローを実行できるようになります。VS Code フォーク（Antigravity IDE、Cursor）の拡張機能としても、他のツール（Antigravity 2.0、Antigravity CLI、Claude Code、Codex）のプラグインとしても利用できるため、IDE を離れることなく、答えを見つけ出せます。

Data Agent Kit は、次の 2 つのコア メカニズムを基盤としています。

  • Model Context Protocol（MCP）: エージェントをツール、データベース、リモート クラウド インフラストラクチャに接続するオープン スタンダード。

  • エージェント スキル: AI エージェントに特定スタックとのやり取りの方法を教え、エージェントの知識を補強する Markdown ファイル。

Data Agent Kit を使用すると、SQL スニペットを生成してコンソールにコピーして貼り付ける代わりに、エージェントがクエリを実行して結果を読み取ることができます。

これを平均注文額（AOV）のシナリオに適用したら、どのようになるのか見てみましょう。この場合、データ ウェアハウスには BigQuery が、Postgres インスタンスには Cloud SQL が相当し、キャンペーン ルールは Cloud Storage に保存されています。

<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_dak_architecture" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/1_dak_architecture.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Data Agent Kit のサンプル アーキテクチャ</p></figcaption>
  
</figure>


  </div>
</div>

事象を把握する

調査は、まず IDE のチャットペインで、次の自然言語プロンプトを使用して、基本的な数値の確認から始めます。

code_block
<ListValue: [StructValue([('code', 'BigQuery の orders テーブルと order items テーブルを使用して、2025 年 8 月から 2026 年 1 月までの月間平均注文額を計算してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be1958490>)])]>

結果を確認する

エージェントがプロンプトを処理し、関連スキルを呼び出して、データのクエリを開始する準備をします。しかし、まだ実行はせず、IDEを一時停止して必要な MCP ツール（execute_sql_readonly など）の使用許可を求めます。ユーザーは、監査のために 1 回だけ許可することも、[常に許可] を選択してワークフローを継続することもできます。許可すると、エージェントはクエリを送信します。

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


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

  
  
    
    <img alt="2_skill_tool_use" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/2_skill_tool_use.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>チャットでエージェント スキルと BigQuery MCP を呼び出す</p></figcaption>
  
</figure>


  </div>
</div>

エージェント IDE では、実行トレイルを検査して、各 MCP ツール呼び出しの記録や BigQuery に送信された未加工 SQL などを確認できます。エージェントが生成したコードは人間の目で再確認する必要がありますが、不慣れなスキーマに対して一からクエリを記述するの比べれば、大幅な時間の節約になるはずです。

数値を深掘りする

数値を見ると、平均注文額（AOV）は 8 月から 12 月まで 110 ドル前後を維持していましたが、1 月には 103 ドルに減少しています。この理由を調べるために、エージェントにドリルダウンを依頼します。

code_block
<ListValue: [StructValue([('code', '1 月の AOV を注文タイプ別に分類して、詳細を確認してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be04b4f10>)])]>

結果は、ビジネスの衰退ではなく、平均値の偏りを示しています。オンライン注文とオフライン注文は約 110 ドルで堅調に推移していますが、1 月に B2B-Wholesale という新しいチャネルが登場し、その AOV はわずか 75 ドルほどでした。注文が減少したのではなく、プロダクト構成の変化が AOV の見た目を押し下げました。

Cloud SQL に調査を広げる

AOV の低下につながった要因がわかりました。次に、卸売業者のバイヤーの実体を把握する必要があります。顧客レコードは Cloud SQL Postgres の運用データベースに保存されています。同じチャット スレッドで、次のように続けましょう。

code_block
<ListValue: [StructValue([('code', 'B2B のお客様はどのような事業者ですか。Cloud SQL データベースで、アカウントの詳細と作成日を確認してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be04b7410>)])]>

エージェントは MCP を Cloud SQL MCP に切り替え、customers テーブルを調査します。100 件の卸売アカウントはすべて、過去 30 日以内に作成された新しい事業体です。12 月には、これらの事業体はいずれも存在していませんでした。

<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_b2b_customers" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/3_b2b_customers.gif" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Cloud SQL で運用顧客レコードをクエリする</p></figcaption>
  
</figure>


  </div>
</div>

コードを探求する

BigQuery で B2B 注文を簡単に確認すると、92% が promo_code = BIGORDER25 を適用していることがわかります。次に、エージェントにそのコードを追跡してキャンペーン ファイルを確認するよう依頼すると、エージェントは Google Cloud Storage MCP サーバーを使用してファイルにアクセスします。

マーケティング キャンペーンでは、25% 割引コードにより低価格の卸売注文が大量に発生し、総収益は横ばいだったものの、総合的な AOV は減少しました。

このように、エージェントは、1 回のチャット セッションで、分析データ（BigQuery）、運用記録（Cloud SQL）、非構造化メタデータ（Cloud Storage）をクエリして、根本原因を特定しました。

調査結果を報告する

調査が終わったので、上司に短いエグゼクティブ サマリーを提出するようエージェントに指示します。

<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_executive_summary" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/4_executive_summary.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>エージェントが生成したエグゼクティブ サマリー</p></figcaption>
  
</figure>


  </div>
</div>

これで完了です。IDE から直接、自然言語のプロンプトをいくつか入力するだけで、上司からの一筋縄ではいかない質問に答えることができました。

しかし、このような根本原因の分析作業は、日常業務のごく一部であり、その都度、時間を費やすわけにはいきません。次にまた作業が必要になったときに、同じプロセスを繰り返すのは非効率です。代わりに、この調査を再現可能なデータモデルに変換すると便利です。

再現可能なパイプラインを構築する

エージェントに、アドホック分析を永続的な dbt プロジェクトに変換するよう依頼することができます。AOV はペット関連商品の平均注文額なので、ここでは顧客のペット プロファイルを分析に組み込みます。

code_block
<ListValue: [StructValue([('code', 'BigQuery ステージング モデルを Cloud SQL の顧客レコードおよびペットのプロファイル属性と結合する dbt プロジェクトを構築してください。さらに、order_id に一意性テストを追加し、dbt build を実行してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be0aac090>)])]>

エージェントは、1 つのプロンプトから dbt-bigquery を使用して仮想 Python 環境を作成し、プロジェクト モデルとテストを記述します。しかし、dbt build は、一意性テストで order_id の重複が検出され、失敗に終わります。

これは、顧客によっては複数のペットを飼っている場合があるためです。モデルの最初のバージョンでは、これらのプロファイルを各注文に直接関連付けたため、3 匹のペットを飼っている世帯からの注文は 3 行になりました（一意ではありませんでした）。

エージェントは自身のターミナル出力を読み取り、失敗を検出します。その後、dbt ロジックを書き換え、ビルドが成功するまで再実行を繰り返します。

これは、エージェント ワークフローに関して特記すべき点です。エージェントは大量のコードを記述できますが、パイプラインへのデータ品質チェックの適用は不可欠です（幸い、エージェントはそれも記述できます）。

次に上層部から平均注文額の変動理由を尋ねられたときには、dbt モデルが回答を準備してくれます。

まとめ

エージェント IDE を使用すると、ウェアハウス、データベース、オブジェクト ストア、ターミナルを行き来する必要がなくなります。

MCP などのオープン スタンダードと、柔軟な構成と編集が可能なエージェント スキルを組み合わせることで、Data Agent Kit は質問と回答をスムーズに連動させて問題解決へと導きます。不慣れなスキーマを調べたり、多様なコードを使い分けたりすることはもちろん、これまで何度も記述してきた結合の生成も、これからはすべてエージェントに任せられます。エージェントが行う調査の指揮をするのが、あなたの役目です。

実際に試す

Data Agent Kit は現在プレビュー版で提供され、Antigravity（2.0、CLI、IDE）、Claude Code、Codex、Cursor、その他の一般的なツールでネイティブに動作します。

- Google、デベロッパー アドボケイト、Jeff Nelson

Antigravity SDK を使用してエージェント ハブやカスタム ハーネスを単一ツールキットで実現

詳細を表示

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

エンタープライズ エージェントの導入に、万能の解決策はありません。エージェントを導入する際、多くの組織は、そのまますぐに使えるエージェントのデプロイとガバナンスの施行を求めて、Gemini Enterprise Agent Platform のような商用マネージド プラットフォームを選択する傾向があります。しかし、固有のワークフローやカスタム実行エンジンを利用しているデベロッパーは、独自の軽量エージェント ハブの構築を選択することもよくあります。

一元化されたエージェント ハブをゼロから構築するには、サンドボックス内で予測どおりに動作してすべてをログに記録してくれるツールが必要になります。Antigravity SDK を使用すると、Antigravity 2.0 や Antigravity CLI と同じランタイム エンジンを利用でき、安全性に関する宣言型ポリシー、リアルタイム テレメトリー、ステートフルなマルチターンの永続性を直接アプリケーションに組み込むことができます。しかも、コア ランタイムが更新されると、SDK エージェントは自動的に最適化されます。そこで今回は、Antigravity SDK を使用して、完全なマルチエージェント コントロール プレーンを実現する方法について詳しく解説していきます。

Antigravity の仕組み

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


  </div>
</div>

マルチエージェント コントロール プレーンは、LLM ワークロードをモニタリングして管理します。これにより、エージェントが何を考え、どのツールを呼び出し、状態をどのように保存しているのかを、正確に把握することができます。

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


  </div>
</div>

そのワークフローは、次の 2 つの重要なコンポーネントで構成されています。

1. Antigravity SDK エージェント コア: モデルのインタラクション（Gemini 3.1 Pro や Gemini 3.8 Flash など）を管理し、ツールを実行し、思考トレースを生成し、スキルを実行するランタイム。

2. オブザーバビリティとテレメトリーのミドルウェア: Antigravity SDK ライフサイクル フックを活用したイベント ドリブン レイヤ。ステップの開始、思考の更新、ツール呼び出しなどのエージェント アクションをインターセプトし、WebSocket 経由でテレメトリーをダッシュボードにストリーミングします。

ユースケース: マルチエージェントのモニタリングとインタラクティブな制御

カスタム エージェント ハブを構築または維持している組織が、Antigravity SDK を活用したエージェントとの統合を考えている場合、どのようなアプローチがあるか、一緒に見ていきましょう。

問題: オペレーション エンジニアは、バックグラウンド調査、ドキュメントの要約、タスクのスケジューリングを実行する複数のアクティブなエージェント（gemini-pro-agent、github-agent、email-agent など）をモニタリングする必要があります。従来、エージェントの進捗状況をモニタリングするには、以下の必須タスクと課題がありました。

  • 複数のターミナル ウィンドウにまたがって断片化されたコンソールログを追跡

  • JSON の文字起こしを手動で検査して、ツール呼び出しの停止や失敗を診断

  • 特定のエージェント セッションでどのスキルまたは MCP コネクタが読み込まれているかの把握が困難

  • 累積トークン使用量と実行レイテンシの追跡が困難

解決策: この投稿では、リアルタイム オブザベーションのためのストリーミング API、ライフサイクル フックによるテレメトリーとインターセプト、ポリシー エンジンによる制御、機能管理のためのスキル、永続性を維持するセッション状態について、それぞれ詳しく説明します。SDK がもたらすダッシュボードにより、オペレーターは各エージェントの作業を 1 つのビューで確認できます。

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


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

  
  
    
    <img alt="03-agy-bespoke-agent-hub" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/03-agy-bespoke-agent-hub.max-1000x1000.jpg" />
    
    </a>
  
</figure>


  </div>
</div>

実際のメカニズムオペレーターまたはダッシュボードが Antigravity エージェントとやり取りすると、ランタイムは 5 つのコア メカニズムを通じて処理の実行を調整します。

  1. セッションの初期化と状態のアタッチ（save_dir と conversation_id）: ランタイムはセッションを初期化または再アタッチし、処理の実行をルート save_dir にバインドします。マルチターン軌跡のログ、ツール受信歴、アーティファクトは、永続的な監査を可能にするために traj-<conversation_id> に保存されます。

  2. スキル解決（skills_paths）: ドメイン固有の機能と指示が、SKILL.md バンドルを指すファイルシステム パスから直接解決され、外部レジストリなしでエージェントのシステム プロンプトを動的に補充します。

  3. 同時ストリーム生成（ChatResponse）: ランタイムは、単一のモデル レスポンスに対して同時進行の 3 つの非同期イテレータを公開します。

    • response（表示可能なテキスト トークンを生成）

    • response.thoughts（内部の Chain-of-Thought 推論の差分を生成）

    • response.tool_calls（.name と .args を含む型付き ToolCall イベントを生成）

  4. 宣言型ポリシーによるサンドボックス化と組み込みツールの実行: エージェントがワークスペース オペレーションを実行すると、組み込みツール（list_directory、find_file、search_directory、view_file、create_file、edit_file）は、安全性に関するポリシー（policy.workspace_only() など）に則って管理される指定のワークスペース ディレクトリ内でのみ実行されます。

  5. ライフサイクル フックによるテレメトリーとインターセプト: パラメータを付与された非同期フック関数（@hooks.on_session_start、@hooks.pre_tool_call_decide、@hooks.post_tool_call、@hooks.on_session_end）が、エージェントのやり取りの推移をリアルタイムでインターセプトし、ツール呼び出しを検証または修正して、WebSocket 経由でテレメトリー ペイロードをライブ ダッシュボードにブロードキャストします。

Antigravity SDK は、これらのメカニズムを 4 つの主要な構成要素に分けて実行します。

1. ドメイン別のスキル適用

スキルは、エージェントが動的に読み込める、再利用可能なドメイン固有の指示バンドルと参照アセットを提供します。インメモリ レジストリを管理する代わりに、SKILL.md ファイルを含むファイル システム ディレクトリからスキルのパスを直接解決できます。

code_block
<ListValue: [StructValue([('code', 'from google.antigravity import Agent, LocalAgentConfig\r\n\r\n# Pass directory paths containing SKILL.md bundles directly to config.\r\n# The runtime dynamically resolves and injects them into the prompt.\r\nconfig = LocalAgentConfig(\r\n model="gemini-3.8-flash",\r\n system_instructions=(\r\n "You are an enterprise operations assistant equipped with "\r\n "specialized operational skills."\r\n ),\r\n skills_paths=["./skills/research", "./skills/code_review"],\r\n)\r\n\r\nasync with Agent(config) as agent:\r\n response = await agent.chat("Analyze the deployment logs.")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be05b7ad0>)])]>

2. 組み込みツールとワークスペースのサンドボックス範囲指定

SDK には、すぐに使用できるプロダクション レディなファイルツールとワークスペース ツールが用意されているため、カスタム ファイルシステム ラッパーを記述する必要がありません。これらのツールは、ワークスペースおよび安全性に関する宣言型ポリシーと組み合わさることで、承認されたディレクトリ内での使用に厳密に制限されます。

code_block
<ListValue: [StructValue([('code', 'from google.antigravity import Agent, LocalAgentConfig, types\r\nfrom google.antigravity.policies import policy\r\n\r\nconfig = LocalAgentConfig(\r\n model="gemini-3.8-flash",\r\n # Selectively enable built-in tools via CapabilitiesConfig\r\n capabilities=types.CapabilitiesConfig(\r\n enabled_tools=[\r\n types.BuiltinTools.LIST_DIR, # "list_directory"\r\n types.BuiltinTools.FIND_FILE, # "find_file"\r\n types.BuiltinTools.SEARCH_DIR, # "search_directory"\r\n types.BuiltinTools.VIEW_FILE, # "view_file"\r\n types.BuiltinTools.CREATE_FILE, # "create_file"\r\n types.BuiltinTools.EDIT_FILE, # "edit_file"\r\n ]\r\n ),\r\n # Enforce filesystem isolation: operations outside these paths are blocked\r\n workspaces=["./workspace"],\r\n policies=[policy.workspace_only()],\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be106c550>)])]>

3. セッションの隔離と軌跡の永続化（save_dir と conversation_id）

Antigravity SDK の状態の永続性は、外部データベースではなく、宣言型の構成によって管理されます。save_dir を指定すると、traj-<conversation_id> の下に、マルチターン軌跡、ツール受信歴、アーティファクトが保存されるルート ディレクトリが確立されます。

code_block
<ListValue: [StructValue([('code', 'from google.antigravity import Agent, LocalAgentConfig\r\n\r\nconfig = LocalAgentConfig(\r\n model="gemini-3.8-flash",\r\n # Root directory storing all conversation trajectories\r\n save_dir="./storage/sessions",\r\n # Supply conversation_id to reattach to an existing trajectory;\r\n # omit it to let the SDK mint a new ID on the first turn.\r\n conversation_id="ops-session-20260820-001",\r\n)\r\n\r\nasync with Agent(config) as agent:\r\n # Resumes prior context and continues the multi-turn session seamlessly\r\n response = await agent.chat("Summarize the issues identified in the last turn.")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be0aace90>)])]>

4. ライフサイクル フックによるリアルタイムのテレメトリーとインターセプト

ライフサイクル フックにより、ダッシュボードとモニタリング エンジンは処理の実行の全段階を監視し、制御できます。パラメータを付与された非同期関数を使用することで、WebSocket 経由でステータスの更新をストリーミングしたり、ツールのパラメータを検査したり、ツールを実行する前に人間参加型の承認を強制したりできます。

code_block
<ListValue: [StructValue([('code', 'from google.antigravity import Agent, LocalAgentConfig, types\r\nfrom google.antigravity.hooks import hooks\r\n\r\n# 1. Session start & end telemetry\r\n@hooks.on_session_start\r\nasync def on_session_start():\r\n broadcast_to_dashboard({"type": "STATUS", "status": "RUNNING"})\r\n\r\n@hooks.on_session_end\r\nasync def on_session_end():\r\n broadcast_to_dashboard({"type": "STATUS", "status": "IDLE"})\r\n\r\n# 2. Intercept tool calls before execution (human-in-the-loop / audit gate)\r\n@hooks.pre_tool_call_decide\r\nasync def intercept_tool(tool_call: types.ToolCall) -> types.HookResult:\r\n broadcast_to_dashboard({\r\n "type": "TOOL_CALL",\r\n "tool": tool_call.name,\r\n "args": tool_call.args,\r\n })\r\n # Return HookResult to approve or block execution\r\n return types.HookResult(allow=True)\r\n\r\n# 3. Post-execution tool receipts\r\n@hooks.post_tool_call\r\nasync def record_tool_result(result):\r\n broadcast_to_dashboard({\r\n "type": "TOOL_RESULT",\r\n "tool": result.name,\r\n "error": getattr(result, "error", None),\r\n })\r\n\r\nconfig = LocalAgentConfig(\r\n model="gemini-3.8-flash",\r\n hooks=[on_session_start, on_session_end, intercept_tool, record_tool_result],\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be0aac310>)])]>

使ってみる

以下のリソースを参考にして、独自のエンタープライズ向けエージェント コントロール プレーンの構築を開始してみませんか。

- Google Cloud、フォワード デプロイド エンジニア、Wei Yih Yap

- Google Cloud、プラクティス カスタマー エンジニア、Paul Datta

Airtel、2026 年インディアン プレミアリーグのクリケット中継を完璧に配信

詳細を表示

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

インディアン プレミアリーグ（IPL）の何百万人もの熱狂的なファンにとって、クリケットのライブ配信を完璧な状態で視聴できることは絶対条件です。世界最大規模の同時視聴者数を誇るリーグのテレビ放送を制作する Airtel にとって、パケットのドロップやバッファリングは、決してあってはならないことです。

IPL 2026 のシーズン中、Airtel は Google Cloud と提携して、このデジタル配信に対応しました。このストリーミング インフラストラクチャが 74 試合にわたって配信した外向きデータは数百ペタバイトに及びます。決勝戦だけで数百億件のリクエストが処理され、ピーク時の外向きトラフィックは数 Tbps に達しました。

このような同時接続数の急増に対応して動画を配信するには、ローカル化を徹底追及したエッジ アーキテクチャと、プロアクティブな運用モニタリングを組み合わせる必要があります。

IPL 2026 の目標は、同時接続数の急増やネットワークの状況にかかわらず、インド全土のクリケット ファンに、スタジアムにいるかのようなスムーズな視聴体験を提供することでした。Airtel は、Google Cloud と提携して Media CDN を使用することで、ローカルエッジへの近接性と優れたキャッシュ効率を実現できました。そして、これを試合当日のプロアクティブなリアルタイム モニタリングと組み合わせることで、最初から最後まで信頼性の高いブロードキャスト体験を提供できました。

同時接続数とエッジ効率を考慮した設計

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


  </div>
</div>

スポーツのライブ配信における主な課題の一つは、トラフィックの急増をシームレスに処理し、ストリーミングのパフォーマンスを低下させたり、バックエンドの配信元に過剰な負荷をかけたりしないことです。最終オーバーは何百万人もの視聴者が同時に視聴します。1 ミリ秒が勝負を分けるため、この点が特に重要となります。

Airtel は、インドの多様な ISP 環境にわたってコンテンツ配信を高速化するために、Google Cloud の Media CDN を利用しました。Google の広範なグローバル エッジ ネットワークを活用することで、エンドユーザーに物理的に近いエッジ ロケーションから視聴者のリクエストを処理できるようになります。この徹底したローカル化が、ブロードキャストの成功の礎となりました。インド国内からローカル配信されたトーナメントのトラフィックは 99.9% にも及びます。

この効率的なアーキテクチャにより、ネットワーク ホップが最小限に抑えられ、トランジットの輻輳が軽減されました。その結果、全 74 試合にわたりインフラストラクチャと視聴者エクスペリエンスの指標が大幅に向上しました。

  • 優れたキャッシュ効率: キャッシュ ヒット率が全体的に 98% を超えました。大量の視聴者トラフィック負荷をエッジで効果的に吸収することで、プレーオフの視聴者数がピークに達したときでも、配信元サーバー / 動画プラットフォームに対する需要は最小限に抑えられました。

  • 一貫した超低レイテンシ: Airtel はトーナメント中に 300 ミリ秒未満の p99 レイテンシを維持しました。その結果、ストリーミング開始までの時間が短縮され、試合の重要な場面でのバッファリングのリスクが最小限に抑えられました。

運用準備のためのプロアクティブな戦略

インテリジェントなバックエンド アーキテクチャの維持は、Airtel の IPL ストリーミング戦略において極めて重要なことでしたが、それだけでは不十分でした。全 74 試合連続で一発勝負のライブ配信を行うには、入念な運用準備と、試合当日のプロアクティブな対応も必要でした。

Airtel と Google Cloud は、最初の試合が始まるずっと前に潜在的なボトルネックを特定する必要があることを認識し、緊密に統合された運用サポートモデルを確立しました。

  1. トーナメント前のサポート準備状況の確認: 開幕戦のかなり前に、共同エンジニアリング チームが包括的なサポート準備状況の確認を実施しました。チームは、トラフィック予測の監査、マニフェスト構成の確認、フェイルオーバー メカニズムの検証を早期に実施することで、クライアントが堅牢な準備態勢を整えられるようサポートし、結果的にトーナメント中の運用上の摩擦を軽減しました。

  2. Monitoring as a Service（MaaS）: チームは、Media CDN 上の MaaS を通じて継続的かつプロアクティブなテレメトリー モニタリングを維持しました。リアルタイムのオブザーバビリティにより、異常が視聴者の再生に影響を与える前にネットワークの変化を早期に検出して軽減できました。

  3. 試合日と週末の専用サポート: スポーツのライブ配信は通常の営業時間内に行われるとは限らないため、Airtel はすべての試合を対象とした包括的なモニタリング プロトコルを確立しました。週末の重大な試合や、命運をかけたプレーオフのステージでは、Google Cloud のテクニカル アカウント マネジメント チームと MaaS チームが Airtel のエンジニアリング チームと緊密に連携して、専任でリアルタイムのイベント サポートを提供しました。

優れたライブ配信のためのブループリント

Airtel が IPL 2026 のストリーミングに成功したことで、膨大な同時接続数への対応には、アーキテクチャ、エッジのローカル化、運用ガバナンスにわたる統合戦略が不可欠であると実証されました。Airtel は、98% 以上のキャッシュ ヒット率、99.9% のローカル配信、試合当日のプロアクティブなモニタリングを組み合わせることで、大規模なライブ スポーツ放送のベンチマークを達成しました。

このデプロイメントは、同時接続数が多いイベント向けにライブメディア配信をスケールする際の技術アーキテクチャと運用戦略の全体像を示します。ライブ配信とエッジ配信の最適化について詳しくは、Media CDN のデベロッパー向けドキュメントをご覧ください。

-Hitesh Bhatia, Assistant Vice President and Head of Engineering, Airtel Digital

-Anand Vijayan, Senior Product Manager, Media CDN, Google Cloud

大型車両向けルート検索機能を提供

詳細を表示

トラックやバスなどの大型車両の運用には、特有の課題が伴います。ドライバーは、高さ制限のある橋や道幅の狭いトンネル、急カーブといった走行上の物理的制約を把握しておく必要があります。さらに車両の運行管理者は、地域、州、国ごとに異なる道路網の規制を考慮して計画を立てる必要があります。

こうした課題に対し、このたび米国において、Routes API、Route Optimization API、Navigation SDK に大型車両向けルート検索（LVR）機能の一般提供を開始したことをお知らせします。LVR は、物流会社、車両運行管理者、大型車両ドライバー向けに特別に構築されており、商用車や特殊車両に固有の要件を満たすように設計されています。大型車両ならではの物理的特性や、実際に直面する道路上の制約を考慮した、高度に最適化されたルートを提供できる機能です。

従来のルート検索アルゴリズムは普通乗用車のルートや走行速度に合わせて最適化されているため、大型車両に影響する特有の要素までは考慮されていないのが一般的です。そのため、車両管理者やドライバーは手作業での確認や土地勘に頼らざるを得ず、ルート設定やナビゲーションの方法が非効率的で安全性を欠いた持続可能性の低いものになりがちです。LVR は、現実世界の車両と道路の制約をルート検索のロジックに直接統合する、API ドリブンなソリューションを実現します。

料金設定と計画の精度を向上

既存の Routes API と Route Optimization API を使用して LVR を導入すると、大型車両のニーズを考慮した、より正確なルートを実現できます。物流会社は LVR を使用して次のことができます。

  • 高さ、重量、長さ、幅、車軸数、危険物の分類など、車両の詳細なプロファイルを指定する。

  • 実現可能性と車両の進入可否を考慮した 1 台の車両または車両群のルート計画を最適化し、全体的な運用効率を向上させる。

  • Google の包括的な道路データと交通モデルを使用して、車両の属性に合わせたルート、移動時間、移動距離を算出する。

<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="LVR-1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/LVR-1.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>商用ルートを比較し、費用面や運用面でメリットがある場合は動的に有料道路を回避します。</p></figcaption>
  
</figure>


  </div>
</div>

車両群全体の運用を効率化

ルートとルート最適化機能により、1 か所または複数か所に立ち寄るルートや、複数台の車両の 1 日または 1 週間の運行計画を立てることができます。ドライバーに道路制約を考慮したルートを提示しながら、時間や工数、走行距離を削減できます。さらに、ルートトークンを使用することで、計画したルートどおりの道案内を確実にドライバーに表示することが可能です。LVR を使用して、車両運行管理者は次のことができます。

  • 大型車両に特化した新しい到着予定時刻モデルを使用して、より正確な到着予定時刻を計算する。このモデルは、観測された大型車の走行速度と、リアルタイムの交通データおよび予測交通データを組み合わせて、大型車向けのより正確な推定値を提供します。

  • ドライバーやオペレーターが使い慣れたインターフェースで、信頼できるエクスペリエンスを構築する。

  • ルートトークンを活用して、道路の制約を考慮したルート計画の詳細を Routes API から Navigation SDK へ渡し、管理者の計画とドライバーによる実際の走行を確実に一致させる。

<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="LVR-2" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/LVR-2.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>時間、走行距離、その他のビジネス上の制約を考慮して最適化し、最も効率的なルートの組み合わせを算出します。Route Optimization API を使用すると、一連の経由地、車両数、車両の制約条件を組み込むことができます。</p></figcaption>
  
</figure>


  </div>
</div>

ドライバーの安心感と効率性を高める

Routes API は最適ルートを提供し、Navigation SDK は Google マップと同様のインターフェースでそのルートを表示します。機能の吹き出しが追加され、走行ルート上の制約の特定と認識が容易になりました。Navigation SDK は、運送業者が提供する既存のアプリケーションに組み込むことができます。そのため、ドライバーにとって使いやすく、計画ルートの取得から確認までをシームレスに行えます。Navigation SDK で LVR を有効にすると、ドライバーがルート上の制約を視覚的に確認しながら、トラックなどの大型車両向けのターンバイターンのナビゲーションを利用できるようになります。また、高さ制限や重量制限など、車両サイズに応じた制約を表示することも可能です。

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


<figure class="article-image--medium
  
  
    h-c-grid__col
    
    h-c-grid__col--4 h-c-grid__col--offset-4
    
  ">

  
  
    
    <img alt="LVR-3" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/LVR-3.max-1000x1000.jpg" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>LVR と Navigation SDK を組み合わせることで、アプリ内でのシームレスなナビゲーションが実現し、ドライバーが使い慣れた信頼性の高い Google マップのガイダンスを運転席で直接利用できるようになります。</p></figcaption>
  
</figure>


  </div>
</div>

使ってみる

大型車両向けルート検索で広がる可能性を、ぜひご体験ください。配送トラックのフリートの最適化、複雑な重量物輸送の計画、危険物の輸送などに必要な精度とインテリジェンスを LVR は提供します。詳細については、ウェブページとドキュメントをご覧ください。

- Google Maps Platform、プロダクト マネージャー、Mohit Moondra

ドライバーのリアルタイムの可視性、道路網を考慮した境界線、アプリ内でのユーザー維持により、業務効率を合理化

詳細を表示

人や物の移動、サービス車両の運用、あるいはアプリ内でのコンバージョン促進。そのあらゆる物理的な道のりとデジタルのタッチポイントが、ビジネスの成否を分ける重要な鍵となります。

このたび、新たに 3 つのプロダクトをリリースいたしました。

  • Navigation Connect API（プレビュー版）: ドライバーのエンドツーエンドの可視性を維持します。

  • Isochrones API（プレビュー版）: 実際の移動時間に基づいて、現実世界での到達可能性を高い精度でマッピングします。

  • Places UI キット Pro（Android と iOS のモバイル SDK は一般提供中、ウェブ版は今秋一般提供予定）: ユーザー ジャーニー全体をアプリ内から直接エンドツーエンドで管理します。

これらの最新プロダクトを活用することで、企業は道路状況の実際のデータや現実世界の場所が持つコンテキストを正確に把握できるようになります。これにより、配送や移動の失敗を減らし、コストの損失を最小限に抑え、コンバージョン率を最大限に高めることが可能になります。

アプリを切り替えても、ドライバーの可視性を常に維持

ドライバーが一般向けのナビゲーション アプリに切り替えてしまうと、状況に応じた適切な更新や円滑な業務運営に欠かせないリアルタイムのデータフローが途絶え、ビジネスに支障をきたすことになります。バックグラウンドでの位置情報の共有や、複数のソースから得た位置情報と到着予定時刻を継ぎはぎして利用するといった回避策では、十分な信頼性を確保できない場合があります。

Navigation Connect API を使用すれば、ドライバーを好みのアプリ（Google マップまたは Waze）に誘導しながら、リアルタイムの位置情報、正確な到着予定時刻、ルート外れのアラートなど、ビジネスに不可欠なルートデータを継続的にプラットフォームに返すことができます。これにより、ドライバーが好みのナビゲーション アプリを自由に使い続けられる環境を提供しながら、管理者側は可視性を損なうことなく、お客様への正確な状況報告と業務効率化を両立できます。

Navigation Connect API は、エンジニアリングに多大な工数をかけることなく可視性を確保したい企業向けに設計されています。軽量な Pub/Sub または API 統合だけで導入できるため、わずか半日という短期間で車両群の運用を劇的に改善し、統合コストと開発時間を大幅に削減することが可能です。

車両に適したツールの選択

Google Maps Platform Navigation SDK は、UI を自在にコントロールし、ユーザーを自社のカスタム アプリケーション環境内に留める「埋め込み型のエクスペリエンス」を想定して設計されています。これに対し、新しい Navigation Connect API は、「ハンドオフ型のエクスペリエンス」に最適です。ネイティブなユーザーアプリを活用することで、迅速な実装とドライバーの使いやすさを実現すると同時に、配送や移動を確実に成功させ、顧客満足度を高めるために不可欠なサーバーサイドの可視性もしっかりと維持できます。

<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="Nav-1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/nav-1.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>使い慣れた Google マップと Waze のユーザー エクスペリエンスでビジネスに不可欠なデータを提供。</p></figcaption>
  
</figure>


  </div>
</div>

Isochrones API で真の到達可能性をマッピング

複雑な都市環境でビジネスを展開するには、道路網の実際のデータを反映した境界線が欠かせません。それがあって初めて、「今この瞬間、車で 15 分以内に到達できるのはどこか？」といった極めて重要な問いに答えることができるのです。単なる半径による円指定に頼ってしまうと、到着予定時刻の誤差が生じやすく、エリア管理の信頼性を損なう原因にもなりかねません。

Isochrones API は、道路網を考慮した境界線を生成し、特定の時間枠（車の場合は最大 60 分、徒歩または自転車の場合は最大 120 分）内に到達可能な範囲を秒単位の精度で正確に示します。標準的なルート検索にとどまらず、逆等時線を計算することで、インバウンド ルートや到着時間の最適化も可能です（たとえば、拠点となるフルフィルメント ハブへ戻る複数の配送ドライバーの動きを調整する場合などに有効です）。リアルタイム交通情報、道路網、さまざまな移動手段を考慮することで、物流を最適化し、動的な到着予定時刻に基づいてサービスゾーンを確認し、到着の信頼性を高めることができます。Isochrones API は、Google マップと同じ堅牢な道路網と交通データを利用して、標準の GeoJSON ポリゴンを返します。これにより、デベロッパーは抽象的な位置座標を、実用的で視覚的なルート決定に簡単に変換できます。

モビリティと物流の最適化

Isochrones API は、フリートと配送ネットワークにおける複雑なルーティングの課題を解決するように設計されています。

  • 配送エリアの最適化: リアルタイムの交通状況やドライバーの稼働状況に基づき、極めて効率的なサービス境界線を定義できます。

  • 配車と移動: 特定の運転時間内に到達できる電気自動車充電スタンドや最適なルートをドライバーが特定できるよう支援します。

他業界での活用

物流以外にも、この API を使用して、デベロッパーは他の業界向けに位置認識エクスペリエンスを構築できます。

  • 不動産物件の検索: 通勤や通学を考慮した物件検索を提供し、購入希望者が単純な直線距離ではなく、職場や学校までの実際の移動時間に基づいて住宅を見つけられるようにします。

  • 都市計画: 緊急サービスへのアクセシビリティを可視化し、交通機関のカバー範囲を分析して、公共交通機関のルート配置を最適化します。

Isochrones API を活用すれば、車、徒歩、自転車など、ユーザーの移動手段を問わず、指定の時間内に到達できるすべての場所を瞬時に可視化できます。これにより、最適なルートを提示し、最高レベルのユーザー エクスペリエンスを提供することが可能になります。

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


  </div>
</div>

Places UI キット Pro でエンドツーエンドのユーザー ジャーニーを所有する

ユーザーが目的地や場所を調べるためにアプリを離れるたびに、ユーザーを失うリスクが生じます。Places UI キット Pro は、モバイル版がすでに提供されており、ウェブ版は今秋に提供予定です。このローコード コンポーネント ライブラリは、豊富なプレイスデータと、ユーザーに焦点を当てた明確な「行動を促すフレーズ」をアプリに直接組み込むことで、ユーザーの離脱を防ぎます。

デベロッパー向けの高度なカスタマイズ機能により、厳選したカルーセルの作成、テーマ（「雰囲気」や「料理」など）によるクチコミや写真のフィルタ、カスタム操作ボタン（「空き状況を確認」など）の追加が可能です。ユーザーはアプリを離れることなく、意思決定に必要なコンテキストを得られます。

Places UI キット Pro を使用すると、アプリ内でアクションを実行するために必要なすべてのコンテキストをユーザーに提供し、ユーザー ジャーニー全体をエンドツーエンドで管理できます。

<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="Nab-3" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/Nab-3.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Places UI キット Pro を使用して、ユーザーをアプリに引き留めましょう。アプリ内で場所の詳細をコンテキストに合わせて提供することで、ユーザーはスムーズに目的を達成できるようになり、アプリのエンゲージメント向上につながります。</p></figcaption>
  
</figure>


  </div>
</div>

最新のプロダクトを今すぐお試しください

Google の最新プロダクトを組み合わせることで、業務の盲点を排除し、ドライバーのワークフローを合理化して、ユーザー コンバージョンを最大化できます。

ビジネスにおけるルートの効率と完了率を劇的に向上させませんか？Navigation Connect API、Isochrones API、Places UI キット Pro モバイル SDK（Android

（新しいタブで開きます）および iOS）を今すぐお試しください。

- Google Maps Platform、プロダクト マネージャー、Qi Wang
- Google Maps Platform、プロダクト マネージャー、Torben Spitzer
- Google Maps Platform、プロダクト マネージャー、Austin Wells

AlloyDB Omni RPM オーケストレーターを使用するエンタープライズ グレードの PostgreSQL の一般提供を開始

詳細を表示

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

このたび、AlloyDB Omni Red Hat RPM オーケストレーターの一般提供を開始しました。これにより、エンタープライズ環境の PostgreSQL ワークロードで、プロダクション レディなセキュリティ、復元力、低ダウンタイムの運用が実現します。今回の一般提供開始は、プレビュー リリースで築いた基盤を足がかりとしています。また、AlloyDB Omni バージョン 18.3.0 とともにリリースされたため、Google AI の機能により、仮想マシンやベアメタル サーバーで直接、クラウドのようなデータベース自動化が可能になります。

この一般提供の開始時点では、要件に合わせて以下の 4 つのモードで AlloyDB Omni をデプロイできます。詳しくは、AlloyDB Omni のドキュメントをご覧ください。

  1. スタンドアロン コンテナ（Debian / UBI）

  2. 高可用性エンタープライズ デプロイ向けの Kubernetes オペレーターを備えたコンテナ

  3. スタンドアロン RPM

  4. 高可用性エンタープライズ デプロイ向けの RPM オーケストレーター

セルフマネージド データベースを運用する理由

多くのユースケースで、マネージド クラウド データベース サービスが最もシンプルで費用対効果の高いオプションとなっています。しかし、クラウド上またはクラウド外で、PostgreSQL データベースを独自に運用することを選択するシナリオもあります。AlloyDB Omni RPM デプロイは、クラウドのパフォーマンスと、コンテナ化されていないローカル インフラストラクチャの制御を必要とする組織向けのソリューションであり、次のようなユースケースに対応できます。

  • ワークロードのモダナイゼーション: AlloyDB Omni は、標準の PostgreSQL と比較して、トランザクション ワークロードに関しては 2 倍以上、分析クエリに関しては最大 100 倍のスピードで動作し、完全な移行を行わなくても、既存のインフラストラクチャを活性化できます。

  • 規制の厳しい環境: RPM オーケストレーターは、データの所在地とセキュリティに関する厳格な要件がある業界向けに、コンプライアンスを維持するために必要な SELinux やローカル監査ロギングなどのツールを提供します。

  • エッジへのデプロイとオンプレミスのデプロイ: エッジまたはベアメタル サーバーにデプロイすることで、低レイテンシの処理とオフライン環境での運用が可能になります。

  • AI 対応インフラストラクチャ: 最新の生成 AI アプリケーションに対応したベクトル検索などの AlloyDB AI 機能をオンプレミスで直接使用して、AI 統合用のデータベース クラスタをプロビジョニングできます。

柔軟なリファレンス アーキテクチャ

AlloyDB Omni RPM オーケストレーターは、パフォーマンスの最大化、読み取りスループットのスケーリング、堅牢な高可用性（HA）の確保など、組織の特定の運用要件に合わせてカスタマイズされた柔軟なデプロイ モデルを提供します。詳しくは、AlloyDB Omni の可用性リファレンス アーキテクチャの概要をご覧ください。オーケストレーターは、ユーザーがインスタンス パラメータ、ノード構成、ネットワーキング オプションを調整してカスタマイズ可能なリファレンス アーキテクチャ仕様を定義できるようにすることで、クラスタのプロビジョニングとライフサイクル管理を簡素化します。スケーラブルな AlloyDB Omni HA リファレンス アーキテクチャのデプロイ図の例を以下に示します。

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


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

  
  
    
    <img alt="1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/1_8L3W52J.max-1000x1000.jpg" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>RPM オーケストレーターを使用した AlloyDB Omni クラスタの高可用性リファレンス アーキテクチャ</p></figcaption>
  
</figure>


  </div>
</div>

この図は、RPM オーケストレーターによって管理される AlloyDB Omni の高可用性分散データベース リファレンス アーキテクチャを示しています。クライアント アプリケーションは堅牢なロード バランシング層に接続し、ロードバランサは読み取り / 書き込みトラフィックをアクティブなプライマリ データベース ノードに直接ルーティングしています。また、読み取り専用トラフィックはレプリカノードにルーティングされています。ロードバランサは仮想 IP（VIP）を使用しており、Keepalived（VIP フェイルオーバー用）、PgBouncer（PostgreSQL 接続プーリング用）、Haproxy（ルーティングとロード バランシング用）により、ロードバランサ自体が高可用性を備えています。AlloyDB Omni プライマリ インスタンス データベース ノードは、複数のゾーンにわたってデータを同期的に複製することで高可用性を実現します。プライマリ HA クラスタに影響を与えずに、読み取り負荷の高いワークロードをスケールアウトするために、個別の読み取りプール インスタンスがデプロイされています。これらはアクティブ ノードから非同期レプリケーションを受け取り、スケールアウトされます。

この図は、独立したコントロール プレーンがクラスタ全体の構成と状態を管理する仕組みを示しています。管理者は RPM オーケストレーターを操作して、データベースのライフサイクルを監視します。コントロール プレーンは、冗長なクラスタ マネージャーと 3 ノードの etcd ベースの分散構成ストアで構成されており、クラスタの状態を確実に維持して構成を管理できます。コントローラは、個々のデータベース ノードで実行されているノード マネージャーと直接やり取りします。単一のクラスタのみをデプロイする場合は、コントロール プレーンとデータプレーンのコンポーネントを同じノードセットで実行できます。

高可用性と読み取りのスケーラビリティ

RPM オーケストレーターを使用すると、要求の厳しいワークロードの稼働時間の維持と読み取りのスケーリングが簡単になります。このオーケストレーターは、スタック全体の障害を自動的に処理できる復元力のあるアーキテクチャを提供します。たとえば、すべてのデータ / 制御パス コンポーネントや読み取り可能なスタンバイの障害を処理する機能や、ノード間のネットワーク中断を軽減する機能などがあります。

このオーケストレーターは、読み取りワークロードをスケールアウトするための読み取りプールをサポートするようになりました。これにより、読み取りプールを動的に作成したりクラスタに追加したりして、分析クエリや同様のワークロードのニーズを満たすことができます。また、スタンバイ ノードと読み取りプールに対する専用の読み取りエンドポイントの構成もシステムによって行われます。

Google は、AlloyDB Omni RPM オーケストレーターの機能を継続的に拡張しています。ビジネスの継続性とクロスリージョンの復元力をさらに強化する高度なエンタープライズ グレードの機能など、今後の機能にご期待ください。

データ保護とセキュリティ

データ セキュリティとデータの復元は、RPM オーケストレーターの中核をなす要素です。このリリースでは、自動化されたバックアップと復元の機能が統合され、バックアップ スケジュールを構成して、GCS または S3 互換ストレージへの完全自動バックアップを自動的に管理できるようになりました。このオーケストレーターを使用すると、S3 バケットまたは GCS バケットに対して、またはローカルでバックアップを実行できます。さらに、ポイントインタイム リカバリと、完全に自動化されたインプレース PIT 復元がネイティブにサポートされています。

RPM オーケストレーターは、ブートストラップ時またはブートストラップ後の SELinux 適用をサポートしています。これにより、厳格な企業のコンプライアンスとセキュリティ基準を満たし、強制的なアクセス制御と強力なプロセス分離を実現できます。

 データベース運用

データベース フリートの管理に関連する運用上のオーバーヘッドが削減されました。

  • 手間のかからない低ダウンタイム メンテナンス: 完全に自動化された新しい低ダウンタイム メンテナンス（LDTM）により、ライフサイクル アップデートとスケーリング オペレーションの管理が容易になります。マイナー バージョンのアップグレード時や CPU とメモリリソースの調整時に、ダウンタイムを最小限に抑え、自動ロールバックをサポートすることで、最大限の可用性を実現します。

  • 動的な構成: データベース管理者は、ブートストラップ時またはブートストラップ後に GUC / 構成を変更する機能などを使用して、設定を動的に調整できます。AI 統合用のクラスタをプロビジョニングすることもできます。

  • クラスタ メンテナンスの簡素化: ワークロードの需要の変化に応じてデータベース ノードを追加または削除するネイティブな運用機能により、クラスタ フットプリントの管理が簡単になります。

オブザーバビリティ、AI、拡張機能

フリートのモニタリングと調整には、細部まで把握できる可視性と適切なツールセットが必要です。

  • 高度なロギング: このオーケストレーターは、データパスとコントロール パスのログをログディスクに転送することで、監査とデバッグを簡素化します。

  • 優れたオブザーバビリティ: カスタム指標がサポートされているため、モニタリング エコシステムに合わせてオブザーバビリティを微調整できます。カスタム指標を使用すると、1 分あたりの新規ユーザー登録数、特定のテナントのアクティブ セッション数、処理された注文数など、ビジネスレベルのイベントをデータベースから直接追跡し、自社の中心的なオブザーバビリティ プラットフォームにエクスポートできます。

  • AI と拡張機能: このオーケストレーターでは、AlloyDB Omni でサポートされている一連の拡張機能だけでなく、自然言語を使用したクエリ、AI を活用した検索、AI 関数など、AlloyDB Omni のすべての AI 機能がサポートされています。

早速始めましょう

AlloyDB Omni Red Hat RPM オーケストレーターは、ベアメタルまたは VM プラットフォームで PostgreSQL 互換ワークロードを管理するための新たな手段となります。AlloyDB の高パフォーマンス、生成 AI 機能へのアクセス、Gemini モデルを組み合わせて、AI エージェントとアプリケーションを構築し、完全な自動化を実現できます。

オンプレミスのデータベース運用のレベルアップをご希望なら、AlloyDB のドキュメントで詳細をご確認のうえ、今すぐ一般提供リリースをお試しください。こちらからご登録いただけます。

さらに、Google の新しい Codelab もお試しください。RPM オーケストレーターを使用して高可用性 AlloyDB Omni クラスタをデプロイできます。

- シニア スタッフ エンジニア、Ujjwal Lanjewar

- プロダクト マネージャー、Omkar Deshmukh

DMS の領域を超えて: SQL Server のログインとユーザーを Cloud SQL に効率的に移行

詳細を表示

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

データベースのモダナイゼーションを計画したとしましょう。Google Cloud の Database Migration Service（DMS）を設定し、レプリケーションを構成して、オンプレミスまたはクラウド システムからフルマネージドの Cloud SQL for SQL Server インスタンスにアプリケーション データベースを正常に同期しました。

そしてレプリケーションが完了し、データが最新の状態になり、カットオーバーの準備が整いました。しかし、移行したばかりのデータベースにアプリケーションを接続しようとすると、次のメッセージが表示され、壁にぶつかります。

Msg 18456, Level 14, State 1, Line 1: Login failed for user 'app_user.

原因は単純です。SQL Server のログインが、データベースと一緒に移行されなかったからです。この投稿では、このギャップが存在する理由、これが組織のセキュリティ ポスチャーの保護につながる理由、そして長年の実績がある標準的な SQL Server ツールを使用して簡単にこのギャップを埋める方法をご説明します。

DMS でログインが移行されない理由: セキュリティとコンプライアンス

Database Migration Service（DMS）は、データベース レベルのスキーマとトランザクション データを非常に効率的に複製しますが、システム master データベースやサーバーのログインと権限などのインスタンス レベルのオブジェクトは移行しません。これは、意図的な動作です。

機能が欠けているように感じられるかもしれませんが、実際には、次の 3 つの基本方針に基づく慎重な設計なのです。

  1. セキュリティの分離と権限の境界: 移行元の環境と移行先の Cloud SQL 環境は、異なるセキュリティ パラダイムで運用されています。マスター システム データベースを直接複製すると、不正な権限昇格につながる可能性があります。たとえば、sysadmin 権限を持つオンプレミスのログインに、フルマネージドの Google Cloud データベースへの無制限の sysadmin アクセス権を付与すべきではありません。クラウド プロバイダが物理的なバックアップ、パッチ適用、セキュリティを管理する場合、適切な運用を確保するために、基盤となるオペレーティング システムへのアクセスを制限する必要があります。

  2. コンプライアンスと監査ガバナンス: 暗号化されたパスワード ハッシュとサーバーレベルのセキュリティ認証情報を、管理者の明示的な監視なしに自動的に移行した場合、PCI-DSS や SOC 2 などの企業のコンプライアンス フレームワークに違反してしまうことが珍しくありません。セキュリティ オブジェクトの移行を管理者が主導する慎重なステップとして維持することで、組織は承認された ID のみがクラウド ランディング ゾーンにプロビジョニングされることを保証できます。

  3. ID のモダナイゼーションの必要性: クラウドへの移行は、古くなった認証情報を更新および削除する絶好の機会です。オンプレミス インスタンスには、使用されなくなった以前の SQL ログインが含まれていることがよくあります。深く考えずにそれらをクラウド マネージド サービスに複製することは、セキュリティのアンチパターンです。さらに、Cloud SQL への移行が、以前の SQL 認証から、顧客管理の Active Directory（CMAD）などのクラウドネイティブな最新の ID ソリューションへの移行を促進するきっかけとなることがよくあります。

ログインとユーザーの違い: SID 接続

ログインを正常に移行するために、SQL Server がセキュリティを管理する方法を簡単に復習しておきましょう。SQL Server では、ID が次の 2 つのレイヤに分かれています。

  • ログイン（サーバーレベル）: master データベースに保存されます。ログインは、SQL Server インスタンスへのクライアント接続を認証します。

  • ユーザー（データベース レベル）: 個々のユーザー データベース内に保存されます。ユーザーは、その特定のデータベース内で接続が実行できるアクションを承認します。

サーバー ログインとデータベース ユーザーを橋渡しするのは、一意のセキュリティ識別子（SID）です。

データベースをバックアップして復元する（または DMS を使用して複製する）と、データベース レベルの「ユーザー」（および対応する SID）がデータベース ファイル内に移行されます。ただし、対応するサーバーレベルの「ログイン」が移行先の master データベースに存在しない場合、または存在しても SID が異なる場合、マッピングは解除されます。これにより、データベース アクセス権限はあるものの、サーバーレベルで認証できない「孤立したユーザー」が生じます。

<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="SQL Server Logins 1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_kO5uMVL.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>図 1: 対応するログインがないデータベース、またはセキュリティ識別子（SID）が一致しないデータベースを移行すると、移行先のインスタンスで孤立したユーザーが生じる。</p></figcaption>
  
</figure>


  </div>
</div>

推奨ソリューション: sp_help_revlogin を使用してログインを複製する

すべてのログインを手動で再作成し、パスワード ハッシュの見当を付けようとする代わりに、Microsoft が従来より提供しているスクリプト sp_help_revlogin を使用するとよいでしょう。

このスクリプトは、移行元インスタンスのすべての SQL Server 認証ログイン用 CREATE LOGIN ステートメントを含む T-SQL クエリを生成します。このステートメントは、元の暗号化されたパスワード ハッシュと正確なセキュリティ識別子（SID）を備えています。

ステップ 1: 移行元インスタンスでヘルパー プロシージャを作成する

SQL Server Management Studio（SSMS）を使用して、移行元の SQL Server インスタンスに接続します。Microsoft の公式スクリプトをコピーして実行し、移行元の master データベースに 2 つの必須ストアド プロシージャ（sp_hexadecimal と sp_help_revlogin）を作成します。

ステップ 2: 移行スクリプトを生成する

プロシージャが作成されたら、SSMS のクエリ ウィンドウで次のステートメントを実行します。出力を正確にコピーするには、出力設定を [Results to Text] に切り替えてください（Ctrl+T）。

code_block
<ListValue: [StructValue([('code', 'EXEC master.dbo.sp_help_revlogin;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be0b95550>)])]>

出力には、次のような自動生成された T-SQL ステートメントが含まれます。

code_block
<ListValue: [StructValue([('code', 'CREATE LOGIN [app_user] WITH PASSWORD = 0x01004F3D... HASHED, SID = 0x8D2F..., DEFAULT_DATABASE = [CustomerDB]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be126e850>)])]>

HASHED パスワード オプションと元の SID を使用してログインをスクリプト化することで、SQL Server で元のパスワードと安全なリンクをそのまま維持してログインを安全に再作成できます。

ステップ 3: スクリプトを Cloud SQL に適用する

生成されたスクリプトをコピーし、移行先の Cloud SQL for SQL Server インスタンスに接続して、クエリを実行します。ログインは、正しいパスワードでクラウドに即座に作成されます。

sp_help_revlogin によって生成されたスクリプトを実行することで、正確なセキュリティ識別子（SID）とパスワード ハッシュをそのまま維持した状態で、移行先の Cloud SQL インスタンスにログインを複製できます。以下に示すように、これにより、データベース レベルのユーザーがデータベースの移行時にサーバーレベルのログインに自動的にマッピングされるため、「孤立したユーザー」を完全に回避できます。

<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="SQL Server Logins 2" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/image2_lFILOIi.max-1000x1000.png" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>図 2: sp_help_revlogin スクリプトを使用した統合移行プロセス。パスワード ハッシュと元の SID を保持し、Cloud SQL for SQL Server でユーザー マッピングを解決する。</p></figcaption>
  
</figure>


  </div>
</div>

注: sp_help_revlogin は、Microsoft が作成、管理しているストアド プロシージャです。必ず最新バージョンをダウンロードし、ドキュメントをお読みください。

孤立したユーザーのトラブルシューティング

sp_help_revlogin を実行する前に、移行先の Cloud SQL インスタンスにログインを手動で作成していた場合、SID が一致せず、ユーザーが「孤立」する可能性があります。

孤立したユーザー（app_user など）が見つかった場合は、次の 1 つのコマンドで簡単に、新しく作成したサーバー ログインに再マッピングできます。

code_block
<ListValue: [StructValue([('code', 'ALTER USER [app_user] WITH LOGIN = [app_user];'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1be126d790>)])]>

このコマンドにより、データベース ユーザーとサーバー ログインが SID を介してすぐに再結合され、アプリケーションの接続が完全に復元されます。

セキュリティをさらに強化

sp_help_revlogin を使用した SQL ログインの移行は、リフト＆シフト移行の最も簡単な方法ですが、クラウド移行を利用した認証のモダナイズもご検討いただけます。Cloud SQL for SQL Server は、顧客管理の Active Directory（CMAD）との堅牢な統合をサポートしています。移行先インスタンスを Active Directory と統合することで、従来の SQL ログインを廃止し、一元化されたエンタープライズ グレードの Kerberos 認証に移行できます。

まとめ

データベースの移行は、単なるデータ行の移動ではありません。アプリケーションのセキュリティ、コンプライアンス、運用性を初日から確保することが重要です。Google Cloud の DMS によってデータ レプリケーションの煩雑な処理を行う一方、シームレスなカットオーバーを保証する簡単な 3 ステップのプロセスでログインを移行できます。

移行戦略の最適化について詳しくは、Cloud SQL for SQL Server 移行ガイドをご覧ください。また、Database Migration Service を使用して Google Cloud への移行を効率化する方法もご確認ください。

- SQL Server ブラックベルト、Assaf Fraenkel

- シニア プロダクト マネージャー、Adi Shtatfeld

Google、「The Forrester Wave™: Public Cloud Platforms, Q3 2026」でリーダーに選出

詳細を表示

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

このたび、「Forrester Wave™: Public Cloud Platforms, Q3 2026」レポートにおいて、Google Cloud がリーダーに選出され、「現在のサービス」カテゴリで最高スコアを獲得しました。このレポートは、30 項目の包括的な基準に基づいて、最も重要なパブリック クラウド プロバイダ 10 社を評価したものです。また Google は、ビジョン、イノベーション、AI 開発サービス、データベース サービス、分析サービス、コンテナおよび Kubernetes サービス、モダナイゼーション サービス、セキュリティ サービスなど、30 項目の評価基準のうち 23 項目で最高スコアを獲得しました。Forrester による今回の評価は、エージェントの時代をリードするには、シリコンからシステム、モデルに至るまで、ゼロから設計された完全な統合プラットフォームが必要であるという Google の信念を裏付けるものだと考えています。

<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>無料レポート <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>

グローバル企業で実績のある共同設計インフラストラクチャを基盤に構築

10 年以上にわたり、Google のインフラストラクチャ エンジニア、アプリケーション デベロッパー、AI 研究者は肩を並べて、Gemini、検索、YouTube、マップ、Gmail を支えるインフラストラクチャを共同設計してきました。必要なプラットフォームとインフラストラクチャを単純に購入することはできず、自社での開発が必要でした。その結果、TPU から、Transformer アーキテクチャ、Kubernetes、Axion、そして Gemini に至るまで、あらゆるものが生み出されました。

エージェントの時代には、最前線で AI 研究に取り組んでいなくても、コンピューティング、オーケストレーション ソフトウェア、モダナイゼーション ツール、グローバル ネットワークが連携して、投資からより多くの価値を引き出す統合 AI スタックが必要です。Google Cloud は、大手企業、スタートアップ、最先端の研究機関にこうした画期的なイノベーションをもたらし、新たなレベルの規模と効率性を実現できるよう、たゆまぬ努力を続けてきました。Forrester の評価は、その戦略が正しいことを証明するものだと考えています。

「Google Cloud のビジョンは『エージェント型エンタープライズ』を実現することです。AI はすでにそのプラットフォームに浸透しており、同社は、企業における AI 導入をますます形作っているビジネス ユーザー向けに、技術スタックをさらに拡張する立場にあります。Google Cloud は、迅速な技術革新と、AI を活用した幅広いクラウド プラットフォームを求める企業に最適です。」-「The Forrester Wave™: Public Cloud Platforms, Q3 2026」レポート

セキュアで柔軟なプラットフォームでエージェントを迅速に実行

従来のインフラストラクチャのほとんどは、エージェントの進化についていけないため、企業はスケーラブルな代替インフラストラクチャを必要としています。しかし、AI エージェントのためだけに新しいグリーンフィールド プラットフォームを導入することは望ましくありません。Kubernetes は、マイクロサービスやトランザクション データベースからリアルタイムの LLM 推論まで、最新のエンタープライズ アプリケーションにおける実績のある業界標準です。Google は、組織が単一の実績あるプラットフォーム上で従来のワークロードとともに自律型エージェントをスケールできるように、Google Kubernetes Engine（GKE）と運用ツールを進化させています。

Forrester は、コンテナおよび Kubernetes サービス、サーバーレス / FaaS サービス、運用管理サービスの評価で Google Cloud に最高スコアを付け、次のように述べています。

「オペレーターは、運用管理、コンテナ、Kubernetes サービスにおいて、強力なサービスを見つけることができます。評価の結果、機能に大きなギャップは見つかりませんでした。」

過去 3 か月間、Google は、チームが企業の予測可能性を維持しながらエージェント ワークロードをスケールできるように、インフラストラクチャ ポートフォリオを強化しました。最近のアップデートにより、以下のことが可能になりました。

  • GKE Agent Sandbox（一般提供版）と Cloud Run Sandbox（プレビュー版）を使用して、デフォルト拒否のセキュリティで従来のワークロードと並行して、信頼できないエージェント コードを安全に実行できます。これらのプロダクトにより、エージェント用に gVisor で分離された軽量の境界が 1 秒未満で（および 1 つのクラスタで毎秒最大 300 個のサンドボックスが）プロビジョニングされます。

  • GKE Pod スナップショットを使用してコンテナの RAM 状態を Google Cloud Storage に直接シリアル化することで、アイドル状態のコンピューティング費用を最大 90% 削減できます。これにより、アイドル状態のエージェント セッションを約 100 ミリ秒で一時停止し、約 280 ミリ秒で再開できます。

  • GKE Inference Gateway の予測ルーティングにより、最初のトークンまでの時間（TTFT）を最大 70%短縮し、キャッシュ ヒット率を 2 倍に向上させることができます。GKE Inference Gateway は継続的にトレーニングされた ML モデルを使用して、リアルタイムのトラフィック データに基づいてルーティングを決定します。

リアルタイムの企業データでエージェントをグラウンディング

エージェントの有効性は、グラウンディングのコンテキストによって決まります。従来の分散データ トポロジでは、断片化されたマルチホップ パイプラインを介して、オペレーショナル データベースと分析システムが分離されています。エージェントの時代において、この分断はマルチホップのレイテンシ、古いコンテキスト、ガバナンスの摩擦を引き起こします。

Google の Agentic Data Cloud は、エンタープライズ データ プラットフォームを静的なリポジトリから動的な推論エンジンへと進化させます。トランザクション処理と分析インテリジェンスをアクティブなアクション システムに統合し、自律型ワークフローに必要なリアルタイムのコンテキストと決定論的な応答性を提供します。Google は、データベース サービス、分析サービス、データ統合サービス、データ ガバナンス サービスの各基準で 5/5 のスコアを獲得しました。

「マルチクラウドとハイブリッドの機能、分析システムとトランザクション システムを橋渡しする Agentic Data Cloud など、Google Cloud のデータベース サービスと分析における従来の強みは、優れたパフォーマンスを推進しています。」

過去 3 か月間で、Google は、お客様がデータ資産を統合できるよう、Agentic Data Cloud に以下の重要な機能を導入しました。

  • SAP BDC Connect for BigQuery（一般提供版）を使用して、コストのかかるデータの移動を必要とせずに、エージェントがライブの財務記録やサプライ チェーン記録をクエリできるようにする。SAP BDC Connect for BigQuery により、SAP システムと BigQuery の間でゼロコピーの双方向データ共有が可能になります。

  • Knowledge Catalog を使用して、データ資産全体にわたってビジネス上の意味をマッピングおよび推論する。Google とパートナーのデータ プラットフォーム、セマンティック モデル、サードパーティのカタログ全体でネイティブ コンテキストを集約し、それらを管理された信頼できる唯一の情報源として統合できるようになりました。

  • レイクハウス フェデレーションを使用して、PostgreSQL データプレーンから Iceberg と BigQuery のライブデータにアクセスする。データの移動を必要とせずに、AlloyDB のトランザクション データと BigQuery または Iceberg の過去の分析情報をライブで結合できます。また、Datastream を使用して、AlloyDB から BigQuery および Iceberg テーブルにデータを継続的に複製することもできます。

新たな基準の確立: Google Cloud で次世代のテクノロジーを構築

Google Cloud が The Forrester Wave™: Public Cloud Platforms, Q3 2026 においてリーダーに選出されたことを光栄に思います。この評価は、数十年にわたる基礎研究、統制されたフルスタックの共同設計、オープンで信頼性の高いクラウドの構築に対する Google の取り組みが認められた結果だと考えています。

断片化されたインフラストラクチャの時代は終わりを告げました。100 万個のアクセラレータ チップでモデルをスケールする AI 研究機関、決済システムで数兆ドルを決済するグローバルな金融取引所、自律型ワークフローで数百万人のユーザーを支援する企業など、どのような組織にも、Google Cloud は次世代のテクノロジーの構築に必要なパフォーマンス、スケール、セキュリティ、データ基盤を提供します。

クラウドへの移行の次のステップ:

- Google Cloud Platform および SRE 担当プレジデント、Brad Calder

- AI およびコンピューティング インフラストラクチャ担当バイス プレジデント兼ゼネラル マネージャー、Mark Lohmeyer

前日
Archive
翌日