データベース

データベースの新機能: エージェントの未来を強化

Fri, 01 May 2026 00:30:00 +0000

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

エージェントの時代を迎え、企業データの役割は受動的なリソースから能動的な「行動のシステム（System of Action）」へと変化しています。そこで Google は、モデル、分析、運用データベースを単一の AI ネイティブシステムに統合する統合型アーキテクチャ Agentic Data Cloud を発表しました。これにより、組織はデータの可能性を最大限に引き出すことができ、すべての AI アプリケーションとエージェントで真実に基づいた運用を行い、費用が急に膨らむようなことなくリアルタイムでアクションを実行できるようになります。

現在、Google は以下の取り組みを進めています。

データスタック全体に AI を組み込むことで、他に類を見ない最適化されたデベロッパーエクスペリエンスを実現しています。
トランザクションと分析の領域を統合し、手動による統合の手間を解消します。
管理が一段と容易でより迅速なデプロイが可能な業界トップクラスのオープンデータベースにより、エンタープライズグレードのデプロイを簡素化します。

データスタックのあらゆるレイヤに AI を組み込む

Google は、AI エージェントとエンタープライズデータベース間のスムーズかつ継続的な接続を可能にすることで、手間のかからないエージェント主導のデータベースエクスペリエンスを実現します。現在、シチズンデベロッパー向けのバイブコーディングツールから、エンタープライズ向けの大規模なベクトル検索まで、データベースがエージェントワークフローの主要なコンポーネントの一つとなっていることは明らかです。

主なリリースは次のとおりです。

AI Studio によるデータベースのバイブコーディング統合: クリエイターを支援するため、Google は最先端のバイブコーディングプラットフォームである Google AI Studio との連携機能を提供します。このエージェント主導の自動ワークフローを使うことで、シンプルなテキストプロンプトからライブアプリケーションを数秒で作成し、そのアプリケーションを Firestore などの信頼できるデータベースサービスに接続できます。Cloud SQL for PostgreSQL のサポートも近日中に提供される予定です。
データエージェント向けツール（プレビュー版）: これらのツールは、開発者がカスタム AI エージェントにデータベース機能への直接かつ安全なアクセスを許可するために使用するモジュール式のビルディングブロックです。AlloyDB、Cloud SQL、Spanner で利用が可能で、高精度のテキストから SQL への変換を行う QueryData ツールなどの機能がすぐに使用できます。これにより、あらゆるエージェントがデータを確実にクエリ、理解、操作できるようにします。AlloyDB、Spanner、Cloud SQL のデータエージェント向けのツールでは、Text-to-SQL で 100% に近い変換精度を実現しました。
データベースオンボーディングおよびオブザーバビリティエージェント（プレビュー版）: 新しいデータベースオンボーディングエージェントは、データベースの選択とデプロイにおける推測を不要とします。単純なユースケースの説明から複雑な企業ニーズといった要件の評価をもとに、理想的な Google Cloud データベースを推奨し、プロビジョニングのプロセスを支援します。さらに、AI を活用した新しい Database Observability Agent が、AlloyDB、Bigtable、Cloud SQL、Spanner のパフォーマンスと健全性をプロアクティブにモニタリングします。これにより、潜在的な問題の根本原因を特定し、トラブルシューティングのための正確な修復を実現できます。
AlloyDB AI を活用した大規模検索 （プレビュー版）: エンタープライズ検索で、かつてないスケールとパフォーマンスを実現します。AlloyDB は、Google の ScaNN インデックスを使用することで 100 億のベクトルにスケーリングできるようになり、標準の PostgreSQL の HNSW インデックスと比較して最大 6 倍高速なベクトルクエリを提供します。さらに、Google の HNSW インデックスは、カラム型エンジンによって高速化されているため、標準の PostgreSQL の 4 倍の性能となっています。Google は、高速なベクトル取得と業界標準の全文検索を組み合わせることで、デベロッパーが究極のハイブリッド検索エンジンを構築できるよう支援しています。この検索エンジンは、近日中に提供されるネイティブの BM25 サポートによって最適化されます。

AlloyDB のベクトル検索のイノベーション

AlloyDB の最適化された新しい AI 関数 （プレビュー版）: AlloyDB AI 関数は、Gemini などの LLM を活用した企業データの統合を支援します。たとえば、AI.IF 関数は、カスタムロジックの代わりに、ユーザーのトランザクションが不正かどうかを判断するために使用できます。既存のスイートである AI.IF、AI.RANK、AI.GENERATE、AI.FORECAST に加え、新たに AI.ANALYZE_SENTIMENT と AI.SUMMARIZE の 2 つが追加されました。また、AI.IF の最適化モードも利用できるようになり、コストとパフォーマンスが大幅に向上します。
データベース向けマネージドリモート MCP サーバー （一般提供）: AlloyDB、Bigtable、Cloud SQL、Firestore、Spanner 向けのマネージドリモート Model Context Protocol（MCP）サーバーの提供を開始しました。また、Google のポートフォリオ全体で MCP を利用できるように、Memorystore、Database Migration Service、Datastream、データベースセンター、Oracle Database@Google Cloud のプレビュー版も提供しています。AI モデルをデータに安全に接続するために必要なインフラストラクチャを完全に管理することで、自社で MCP サーバーのホスティング、保護、スケーリングを行う運用上の負担がなくなります。これにより、AI モデルは本番環境グレードの信頼性で、最新の企業データに基づいて推論し、行動できるようになります。
オープンソースのデータベース向け MCP ツールボックス（1.0）: 10 社のベンダーの協力を得ることで 40 以上のデータベースをサポートする、オープンソースかつ業界標準のデータベース向け MCP ツールボックスが、今回のリリースで安定性における大きなマイルストーンを達成しました。メジャーバージョンアップがない限り API が機能することを保証することで、本番環境向けのアプリケーションを安心して構築できるようになり、デベロッパーと自律型 AI エージェントの両方にとって信頼性の高い基盤が提供されます。

レイクハウスのインテグレーションで閉ざされた環境を解消

デベロッパーがリアルタイム AI アプリケーションを構築するには、ライブのトランザクションコンテキストと膨大な過去の分析情報をミリ秒未満のレイテンシで組み合わせる必要があります。現在、データクラウドをご利用の最大規模のお客様の 98% が、Google の Agentic Data Cloud で運用ワークロードと分析ワークロードを実行しています。

発表内容:

AlloyDB 向けレイクハウスフェデレーション （プレビュー版）: AlloyDB のお客様は、PostgreSQL データプレーンから Iceberg と BigQuery のライブデータにアクセスできるようになりました。ユーザーは、AlloyDB Studio UI から直接、BigQuery または Lakehouse for Apache Iceberg テーブルを検出して検索し、すぐにクエリを開始できます。フィルタと集計は BigQuery にプッシュダウンされます。これにより、データの移動を必要とせずに、AlloyDB のトランザクションデータと BigQuery または Iceberg の過去の分析情報をライブで結合できます。
BigQuery 向けリバース ETL（プレビュー版）: 多くのお客様が BigQuery とレイクハウスを使用して、Apache Spark や BigQuery ML などのツールでウェアハウスの構造化データとデータレイクの豊富なコンテキストを組み合わせています。このたび、Google の新しいワンクリックリバース ETL により、お客様はこれらの分析情報を活用し、レイクハウスから AlloyDB にワンクリックでデータを同期できるようになりました。AlloyDB は、リアルタイムアプリケーションやエージェントアプリケーションのニーズを満たすように最適化された、同時実行性が高く低レイテンシのサービングレイヤとして機能します。AlloyDB 独自のカラム型エンジンと超高速キャッシュによって、優れたサービングパフォーマンスを実現します。利用に追加料金は発生しません。
Datastream によるシームレスな継続的レプリケーション （一般提供）: Datastream では、データループを完結させるために、AlloyDB から BigQuery および Iceberg テーブルにデータを継続的に複製できるようになりました。これにより、運用面の変更が分析環境に迅速に反映されるため、リアルタイムの ML 特徴量エンジニアリングに不可欠な環境を実現できます。Datastream は、セットアップが簡単で、完全にサーバーレスです。AlloyDB から BigQuery へのストリームには無料枠が用意されています。
Knowledge Catalog（旧称 Dataplex） （プレビュー版）: Knowledge Catalog は、集約、継続的な拡充、検索の厳格なフレームワークを使用して、データ資産全体でビジネス上の意味をマッピングおよび推論するユニバーサルコンテキストエンジンです。Google とパートナーのデータプラットフォーム、セマンティックモデル、サードパーティカタログのネイティブコンテキストを集約し、単一の管理された信頼できる情報源として統合します。一貫してガバナンスが適用され、アクセス制御は一元的に管理されるため、データライフサイクル全体で完全な可視性とセキュリティが維持されます。
Spanner カラム型エンジン（一般提供）: この機能により、ライブ運用データでスキャンが最大 200 倍高速化されるため、分析クエリが加速されます。Spanner は、従来の行ベースのストレージと並行してカラム形式でデータを保存することにより、複雑なクエリを自動的に実行できます。その際は、データを行単位ではなく一度にバッチ処理するベクトル化された実行を使用します。Spanner では、Iceberg テーブル、BigQuery からの継続的なリバース ETL、高速化された連携クエリもサポートされるようになりました。これらすべてで Spanner のカラム型エンジンが使用されています。
BigQuery を使用したデータベースセンター（プレビュー版）: データベースセンターで、Google Compute Engine 上の運用データベースとセルフマネージドデータベースに加えて、BigQuery がサポートされるようになりました。クリティカルなアプリケーションを実行するデータベースからビジネスに関して分析するウェアハウスまで、データ資産全体を単一のインテリジェントな管理プレーンからモニタリングできるようになりました。さらに、Gemini を活用したフリート分析により、環境全体でパフォーマンス最適化の機会がプロアクティブに提示されます。また、新しい API とマネージド MCP サポートにより、これらの豊富なフリート指標を任意のサードパーティツールやカスタムダッシュボードに直接ストリーミングできるようになります。

「Google Cloud とのパートナーシップでは、よりスマートで高速な取引所の構築に重点を置いています。かつては、古いシステムによりサイロ化されていた状況と技術的負担によって業務が滞ることもありましたが、Google の Agentic Data Cloud を利用することで、そうした課題が解消されました。Cloud SQL が持つ運用信頼性と BigQuery の高度な推論を統合することで、デベロッパーと AI エージェントが検証、最適化、革新をリアルタイムで進められるデータエコシステムを構築しました」—CME Group、クラウドデータエンジニアリング担当エグゼクティブディレクター、Kristofer Shane Sikora

オープンデータとマルチクラウドの柔軟性への取り組み

データベースがすべてのアプリケーションの日々の運用にどれほど重要であるかは、Google も認識しています。Google では、Iceberg、MySQL、PostgreSQL、Valkey などのオープンソースとオープンデータ形式に重点を置きながら、業界をリードする信頼性、コストパフォーマンス、スケールを実現するためのイノベーションを継続しています。

エンタープライズグレードのデプロイを簡素化するために、Google は以下を発表します。

Spanner Omni（プレビュー版）: 業界をリードする分散データベースを Google Cloud の外でも利用できるようにする、Spanner の新しいダウンロード可能なエディションです。Spanner Omni を使用すると、組織は Spanner の比類のないスケーラビリティ、高可用性、強整合性、エンタープライズグレードのセキュリティ、完全に相互運用可能なマルチモデル機能を、独自のデータセンター、クラウド全体、さらにはエッジでも AI 対応アプリケーションで使用できます。

Spanner Omni の特長

Bigtable インメモリ （プレビュー版）: Bigtable はアーキテクチャを進化させ、新しいメモリ階層でミリ秒未満の読み取りレイテンシを実現します。Bigtable の新しい Enterprise Plus エディションの機能として利用できる、RAM、SSD、HDD にまたがるハイブリッドストレージアーキテクチャを備えた新しいノードは、頻繁にアクセスされるデータをインメモリデータベースを長期アーカイブストレージと統合します。これらすべてを、単一のフルマネージドサービス内で行えます。ご興味がある場合は、こちらのフォームにご記入ください。
Memorystore for Valkey 9.0（一般提供）: Memorystore for Valkey 9.0 は、Google のオープンソースへの強いコミットメントを示すマイルストーンとなっています。導入の簡素化とエンタープライズグレードのパフォーマンスの提供に重点が置かれています。セルフマネージドの Redis と Valkey から Memorystore へのマネージド移行パスを導入し、これまで以上に簡単にモダナイズできるようにしました。また、コストパフォーマンスを向上させるために、小規模ノードと大規模ノードの新たなサイズを追加し、Valkey-bloom モジュールと Valkey-json モジュールをサポートします。さらに、アクセス制御リスト（ACL）、トークンベースの認証、柔軟な認証局に対応したエンタープライズグレードのセキュリティも追加します。
Oracle Database@Google Cloud: 対象リージョンを 20 に拡大し、Oracle GoldenGate Service のサポート、BigQuery への準リアルタイムのデータレプリケーション、Knowledge Catalog（旧称 Dataplex）とデータベースセンターの統合を追加します。
Compute Engine からマネージドサービスへの移行（プレビュー版）: これは、データベース移行の複雑さを解消するために設計された新しいエクスペリエンスです。Cloud SQL、AlloyDB、データベースセンターにネイティブに統合されており、PostgreSQL の自動ネットワーキングとレプリケーションを提供します。これにより、Compute Engine ワークロードを最小限の労力とダウンタイムで Google の強力なマネージドサービスに移行できます。
Firestore の全文検索と地理空間検索（プレビュー版）: Google の業界をリードする検索テクノロジーを Firestore とネイティブに統合することで、差別化された統合サーバーレスデータベースと検索サービスが実現しました。このサービスは、検索結果が基盤となるデータベースのデータと一貫性を保つようにして、運用上のオーバーヘッドを大幅に削減しつつ、関連性の高いキーワードクエリ、フレーズクエリ、地理空間クエリを実行できるようにします。

Mercado Libre: 「Mercado Libre では、社内開発者ゲートウェイとして Fury を構築しました。Fury を通じて、比類のないスケーラビリティ、レジリエンス、整合性を備えた Spanner を活用した NewSQL サービスを提供しています。当社はクラウドネイティブ企業ですが、インサイダー脅威、ランサムウェア、クラウドの停止などのリスクについて、長年にわたって警戒を続けてきました。Spanner Omni は真のクロスクラウドレジリエンスを実現し、他のクラウドプロバイダでは実装がはるかに複雑化するであろう差別化された堅牢な戦略を提供します」– Mercado Libre、シニアテクニカルマネージャー、Diego Oscar Narducci

今すぐ使ってみる

Google のポートフォリオの詳細については、https://cloud.google.com/products/databases をご覧ください。移行とモダナイゼーションの取り組みを開始するにあたっては、ぜひ RAMP サービスをご利用ください。

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

- プロダクト管理、データベース担当バイスプレジデント Raj Pai

運用から分析へ: Spanner Graph と BigQuery Graph による統合ソリューション

Fri, 24 Apr 2026 01:00:00 +0000

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

データ内の関係性を理解することは、隠れたインサイトを発見し、インテリジェントなアプリケーションを構築するために不可欠です。しかし、運用（OLTP）と分析（OLAP）のグラフワークロードを管理するには通常、切り離されたデータベースに悪戦苦闘し、脆弱なデータパイプラインを構築し、複雑なインテグレーションを管理することになります。このような断片化により、データサイロが生まれ、運用上のオーバーヘッドが増加し、スケーラビリティが制限されます。

本日は、Spanner Graph と BigQuery Graph を活用した、グラフデータベースと分析の統合ソリューションをご紹介します。このソリューションは、デプロイ方法に関する推奨ブループリントと、代表的なユースケースのスタートガイドの 2 つの部分で構成されています。このブログ記事では、ソリューションの構成要素を確認し、最も一般的なユースケースの概要を説明します。また、実際にソリューションをデプロイしたお客様の声もご紹介します。

運用ワークロード向けの Spanner Graph

Spanner Graph は、グラフ、リレーショナル、検索、生成 AI の各機能を 1 つのデータベースに統合することで、グラフデータマネジメントを刷新します。これは Spanner の特徴である無制限のスケーラビリティ、高可用性、強整合性を基盤としています。

Spanner Graph により、以下のことが可能になります。

テーブルからグラフへの統合マッピング: 既存の Spanner リレーショナルテーブル上に直接グラフを定義し、データを複製することなく、運用データをグラフとして表示およびクエリできます。
相互運用可能なグラフクエリとリレーショナルクエリ: ISO 規格の Graph Query Language（GQL）インターフェースを活用して直感的なパターンマッチングを行い、GQL と SQL を 1 つのクエリに組み合わせてグラフデータと表形式データをまとめて走査できます。
高度な検索と AI のインテグレーション: 組み込みのベクトル検索、全文検索、Vertex AI のインテグレーションを利用して、セマンティックな意味でデータを取得し、データベース内で直接インテリジェントアプリケーションを強化します。

お客様はすでに、Spanner Graph を使用して高スループット、低レイテンシのアプリケーションを強化しており、数百万のエンティティにわたる ID 解決、広大で複雑な環境にわたる依存関係の特定、データリネージ、Customer 360 のユースケース、リアルタイムの不正行為検出の強化などに取り組んでいます。

「Open Intelligence は、クライアント、パートナー、WPP からの数兆ものライブデータポイントをプライバシー最優先で安全に接続する、当社の基盤となるインテリジェンスレイヤです。現在では、WPP のエージェント型マーケティングプラットフォームである WPP Open に統合され、支えています。Google Cloud の Spanner Graph を基盤とする Open Intelligence は、AI を活用したマーケティングにおける大きな進歩であり、BigQuery Graph で分析グラフワークロードのユースケースを拡大できることを嬉しく思います。」- WPP、データ＆インテリジェンス担当戦略責任者、Rob Marshall 氏

分析ワークロード向けの BigQuery Graph

Spanner Graph はアクティブなオペレーションを処理しますが、真に大規模な分析では、数十億のノードとエッジの関係を探索してパターンを特定し、過去のデータをクエリする必要があります。SQL でデータベースとデータウェアハウスにそれぞれ異なるツールが使用されるのと同様に、グラフでもワークロードごとに専用のツールが必要です。そこで、BigQuery Graph を構築しました。

BigQuery Graph は、接続されたデータ分析をデータウェアハウスに直接取り込みます。既存の BigQuery データをグラフスキーマにマッピングし、SQL または GQL でクエリを実行することで、データを移動することなく、膨大なデータセットに隠された関係を明らかにできます。

主な機能は次のとおりです。

テーブルからグラフへの統合マッピング: 既存の BigQuery テーブルをグラフに即座にマッピングし、ETL パイプラインを構築することも、データを一切移動させることもなく、データウェアハウスに隠された関係を明らかにします。
相互運用可能なグラフクエリとリレーショナルクエリ: GQL の表現力豊かなパターンマッチングを大規模な過去のデータセットに適用し、SQL と GQL を 1 つのクエリに組み込んで、使い慣れたデータウェアハウスと強力なグラフ走査を組み合わせることができます。
高度な検索と AI のインテグレーション: BigQuery AI とのネイティブインテグレーションを利用して予測分析を行うとともに、組み込みのベクトル検索、全文検索、地理空間機能を使用して、数十億件のレコードにわたって接続された情報を見つけます。

統合ソリューションとしての Spanner Graph と BigQuery Graph

各プラットフォームは単体でも強力ですが、一緒にデプロイすることで真価を発揮します。運用環境と分析環境を接続することで、データサイロを排除し、データベースのパフォーマンスを損なうことなく分析情報を得るまでの時間を短縮できます。

「Spanner Graph を使用することで、Yahoo はグローバル規模で接続された基盤にデータを統合し、エージェント型広告プラットフォーム全体でリアルタイムのインテリジェントな意思決定を可能にしています。これにより、AI 主導のアプローチを強化し、最大規模のデジタル広告エコシステムを推進しています。Spanner Graph と BigQuery Graph を連携させることで、より深い分析と予測機能が可能になり、将来のイノベーションを推進できることを楽しみにしています。」- Yahoo、消費者向け収益化責任者、Gabriel DeWitt 氏

例として、金融詐欺の検出について考えてみましょう。アプリケーションは Spanner Graph を使用して不審な接続を即座に特定し、決済時にトランザクションをブロックできます。一方、BigQuery Graph はペタバイト規模の過去のトランザクションデータを分析して、詐欺行為を引き起こした複雑で長期的な詐欺組織を暴きます。

以下では、これら 2 つのエンジンを統合してエンドツーエンドのグラフワークフローを作成する方法について説明します。

1）グラフクエリとスキーマの統合エクスペリエンス

このソリューションの主な利点は、両方のプラットフォームで一貫したスキーマと GQL が共有されることです。共通の言語を使用することで、開発時間を短縮し、コンテキスト切り替えの摩擦を最小限に抑えることができます。

たとえば、特定のアカウントを起点としてつながっている可能性のある詐欺組織をリアルタイムで検出するには、次の Spanner Graph クエリを使用します。

code_block: <ListValue: [StructValue([('code', 'GRAPH FinGraph\r\nMATCH p=(:Account {id: @accountId})-[:Transfers]->{2,5}(:Account)\r\nRETURN PATH_LENGTH(p) AS path_length, TO_JSON(p) AS full_path;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a819bc10>)])]>

同じ分析を実行して、過去の詐欺組織に関与したすべてのアカウントを特定する場合、BigQuery Graph クエリは、以下のようにほぼ同じです。

code_block: <ListValue: [StructValue([('code', 'GRAPH bigquery.FinGraph\r\nMATCH p=(:Account)-[:Transfers]->{2,5}(:Account)\r\nRETURN PATH_LENGTH(p) AS path_length, TO_JSON(p) AS full_path;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a819bf70>)])]>

2）Data Boost を使用して BigQuery Graph で Spanner データをクエリする

Data Boost を使用すると、トランザクションワークロードのパフォーマンスに影響を与えることなく、BigQuery から Spanner Graph データを直接クエリできます。これにより、データを移動することなく、Spanner のリアルタイムの運用データと BigQuery の過去の分析データを組み合わせた「仮想グラフ」を構築できます。

たとえば、Spanner Graph のリアルタイムの アカウント ノードとユーザー ノードを、BigQuery の過去のログインエッジと組み合わせて、さまざまなデバイスにわたる不審なログインパターンを特定できます。

これを行うには、まず CREATE EXTERNAL SCHEMA ステートメントを使用して BigQuery を Spanner に接続します。

code_block: <ListValue: [StructValue([('code', "CREATE EXTERNAL SCHEMA spanner\r\nOPTIONS (\r\n external_source = 'google-cloudspanner:/projects/PROJECT_ID/instances/INSTANCE/databases/DATABASE',\r\n location = 'LOCATION'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a819be20>)])]>

次に、Spanner と BigQuery の両方のテーブルを組み込んだ BigQuery Graph を定義します。

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE PROPERTY GRAPH bigquery.FinGraph\r\n NODE TABLES (\r\n -- Account and Person are stored in Spanner,\r\n -- made available in BigQuery through the `CREATE EXTERNAL SCHEMA` statement.\r\n spanner.Account KEY (account_id),\r\n spanner.Person KEY (person_id),\r\n -- Media is stored in BigQuery.\r\n bigquery.Media KEY (media_id)\r\n )\r\n EDGE TABLES (\r\n -- Transfers and Owns are stored in Spanner.\r\n spanner.Transfers AS Transfers\r\n KEY (transfer_id)\r\n SOURCE KEY(account_id) REFERENCES Account\r\n DESTINATION KEY(target_account_id) REFERENCES Account,\r\n spanner.Owns AS Owns\r\n KEY (person_id, account_id)\r\n SOURCE KEY(person_id) REFERENCES Person\r\n DESTINATION KEY(account_id) REFERENCES Account,\r\n -- LogIn is stored in BigQuery.\r\n bigquery.LogIn AS LogIn\r\n KEY (login_id)\r\n SOURCE KEY(media_id) REFERENCES Media\r\n DESTINATION KEY(account_id) REFERENCES Account,\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a819bb80>)])]>

最後に、BigQuery Graph でクエリを実行して、Spanner（accounts、users、transfers、owns）と BigQuery（logins、devices）の両方のデータにアクセスし、不審なログインパターンを特定します。

code_block: <ListValue: [StructValue([('code', 'GRAPH bigquery.FinGraph\r\nMATCH p=(owner:Person)-[:Owns]->\r\n (:Account)<-[login:LogIn]-\r\n (media:Media {blocked: true})\r\nRETURN TO_JSON(p) AS full_path\r\nORDER BY login.time\r\nLIMIT 20;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a819bb20>)])]>

3）リバース ETL を使用して BigQuery データを Spanner Graph にエクスポートする

分析データを Spanner に戻して低レイテンシのリアルタイムクエリを実行する必要がある場合は、リバース ETL を使用できます。パイプラインを追加する必要はありません。たとえば、BigQuery から Spanner Graph に過去のデバイスデータ（IP アドレス、デバイス ID）をインポートして、リアルタイムの不正行為検出オペレーションを強化できます。

code_block: <ListValue: [StructValue([('code', 'EXPORT DATA\r\n OPTIONS (\r\n uri = \'https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE/databases/DATABASE\',\r\n format=\'CLOUD_SPANNER\',\r\n spanner_options="""{ "table": "Media" }"""\r\n ) AS \r\nSELECT * FROM Media;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a819beb0>)])]>

4）グラフデータを可視化する

接続されたデータの可視化は、分析、データ探索、調査の要です。Spanner Studio とBigQuery Studio（近日提供開始予定）を使用すると、使い慣れた環境から離れることも、外部ツールを設定することもなく、グラフデータを即座に可視化できます。プログラムによる詳細なデータ探索では、Spanner Graph ノートブックと BigQuery ノートブックを利用して、既存のデータサイエンスワークフロー内でクエリ結果を直接レンダリングすることもできます。

5）グラフ可視化パートナーとのインテグレーション

Spanner Graph と BigQuery Graph は、主要なグラフ可視化パートナーとも統合されており、包括的な探索ツールスイートを提供しています。

Kineviz: GraphXR を介して最先端の可視化と高度な分析を組み合わせます。
Graphistry: GPU アクセラレーションを活用したビジュアルグラフインテリジェンスプラットフォームを使用して、大規模なデータセットから重要な分析情報を抽出します。
G.V(): 高パフォーマンスの可視化とノーコードのデータ探索のための、手軽にインストールできるクライアントを提供します。
Linkurious: Linkurious Enterprise プラットフォームを介して、大量の接続されたデータ内の脅威を検出して分析します。

グラフに関するあらゆるニーズに対応する統合ソリューション

Spanner Graph と BigQuery Graph を組み合わせることで、さまざまなユースケースにわたる運用ニーズと分析ニーズに対応する統合ソリューションが実現します。

分野	Spanner Graph	BigQuery Graph
金融サービス	通常とは異なる、不審なトランザクションを即座にブロックします。	複雑で長期的な詐欺組織を検出します。
小売業、e コマース	パーソナライズされたおすすめの商品情報をその場で提案します。	膨大な購入履歴を分析して需要を予測します。
サイバーセキュリティ	アクティブな脅威を隔離し、攻撃の発生源を即座に追跡します。	過去の脆弱性をモデル化して防御を強化します。
医療	医療現場で臨床判断支援システムを強化します。	公衆衛生の傾向と病気のリスク要因を分析します。
サプライチェーン	世界中で商品を追跡し、チームに中断の発生を即座に知らせます。	システム上のボトルネックを特定し、今後のルーティングを最適化します。
通信	ネットワークのデジタルツインを作成して、異常の検出と根本原因の分析をリアルタイムで行います。	トラフィックパターンを大規模に分析して、将来のインフラストラクチャアップグレードを計画します。

Spanner Graph と BigQuery Graph を今すぐ使ってみる

Spanner Graph と BigQuery Graph を組み合わせることで、運用と分析の両方のニーズを満たす統合されたグラフデータマネジメントを実現できます。

運用ワークロード向けの Spanner Graph のユースケースと設定ガイド、分析ニーズ向けの BigQuery Graph の概要と作成ガイドをご覧ください。この組み合わせを最大限に活用する方法をご体験いただくには、統合ソリューションガイドをご覧になり、Codelab をお試しください。

- スタッフソフトウェアエンジニア、Bei Li

- プロダクトマネージャー、Candice Chen

Spanner Omni を発表：あらゆるインフラで Google のイノベーションを活用

Wed, 22 Apr 2026 03:50:00 +0000

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

本日、Google Cloud は Spanner Omni のプレビュー版を発表しました。Spanner Omni は、Google Cloud 外でも利用可能なダウンロード版の Spanner であり、業界を牽引する分散データベース機能をさらに拡張するものです。これにより、企業は Spanner を自社のデータセンターや複数のクラウド、あるいはノート PC 上で実行できるようになります。事実上無制限の水平スケーラビリティ、高可用性、強力な整合性、エンタープライズグレードのセキュリティ、そしてマルチモデル機能を AI 対応アプリケーションが稼働するあらゆる場所で活用可能です。

Spanner Omni が重要である理由

10 年以上前、Google Cloud は Spanner によって分散 SQL 市場を切り拓きました。Spanner は、NoSQL の水平スケーラビリティと、従来のリレーショナルデータベースが持つ ACID（原子性、整合性、独立性、永続性）準拠および強力な整合性を兼ね備えた、まさに理想的なソリューションを提供しました。それ以来、Spanner は SQL、グラフ、キーバリュー、全文検索、ベクトル検索、そしてカラム型エンジンによる分析処理を統合した、相互運用可能なマルチモーダルデータベースへと進化を遂げました。この進化は AI 時代に必要な機能を提供するとともに、お客様のワークロードの簡素化と統合を可能にします。こうした進化は、すでに多くのお客様に大きな価値をもたらしています。

お客様の IT 環境は、パブリッククラウドやハイブリッドクラウド、あるいはネットワークから隔離されたよりセキュアな環境まで多岐にわたります。Spanner Omni は、現代企業の多様なニーズに応えるべく、お客様が運用するあらゆる環境へ柔軟に導入いただけます。具体的には、以下のニーズに対応します。

ビジネスの継続性： ミッションクリティカルなワークロードには、クラウドの枠を超えた、真にレジリエントで高可用なアーキテクチャが求められます。ビジネス状況や世界情勢の変化によりクラウドの利用方針を変更せざるを得ない場合でも、これらのワークロードは稼働を続ける必要があります。
規制遵守： 金融サービスなど、規制の厳しい業界のお客様は、データ主権などの規制要件を満たす必要があります。コンプライアンス維持のために大規模なオンプレミス環境を運用している企業も多い一方で、AI エージェント時代に向けたモダナイズも急務となっています。
アプリケーションのポータビリティ： SaaS プロバイダーや独立系ソフトウェアベンダー（ISV）にとって、マルチクラウドやプライベートデータセンターなど、お客様が運用するあらゆる環境でサービスを提供できることは、ビジネス成長の鍵となります。イノベーションのための高度な機能を維持しつつ、開発や運用のオーバーヘッドを最小限に抑えるため、環境を問わず一貫したテクノロジースタックが求められています。

Spanner Omni の紹介

Spanner Omni は、フルマネージドサービスである Spanner と同等のコア機能を提供し、かつ必要な場所に自由にデプロイできる柔軟性を備えています。仮想マシン（VM）や Linux コンテナから Kubernetes クラスターまで、柔軟な構成オプションに対応しています。また、オンプレミス、マルチクラウド、マルチリージョンに加え、適切なレイテンシを維持できるハイブリッド環境、さらにはエアギャップ環境やネットワーク接続環境など、多様な形態で運用いただけます。スケーラビリティにおいても、単一のサーバーから数千台規模のクラスターまで柔軟に拡張可能です。Google Cloud 内部のベンチマークテストでは、Spanner Omni が単一リージョンのデプロイにおいて、ペタバイト規模のデータに対する秒間数百万件のクエリ（QPS）処理が実証されています。

Spanner Omni の特徴

Spanner Omni は新しい可能性を切り拓きます。初期段階で導入いただいたお客様との取り組みを通じて、Spanner Omni の活用における 3 つの主要なアーキテクチャをご紹介します。

ハイブリッドおよびマルチクラウドのレジリエンス： Google Cloud 上の Spanner マネージドサービスをメインデータベースとして運用し、セカンダリクラウドやオンプレミスのデータセンターに Spanner Omni をホット / コールドフェイルオーバーサイトとしてデプロイする構成です。このプライマリ / セカンダリアーキテクチャはビジネスにおける確かな備えとなり、特に規制の厳しい業界において、ディザスタリカバリや事業継続計画（BCP）の要件を満たすのに役立ちます。また、特定の法域でデータ主権が求められ、Google Cloud のデータセンターが 1 つしか存在しない地域においても、マルチリージョンでの高可用性（HA）構成を構築可能です。
環境を問わない統一された技術スタック： マルチクラウドやハイブリッド戦略をとる組織にとって、Spanner Omni は環境を問わず「一度書けばどこでも実行できる」アプリケーション開発体験を提供します。データベース層を標準化することで、チームは運用のオーバーヘッドを大幅に削減し、最先端のデータベース技術を活用しながら、あらゆる環境で真のアプリケーションポータビリティを実現できます。
オンプレミス環境のモダナイズ： 大規模なオンプレミス資産を持つ組織や自社管理を重視する組織も、クラウドネイティブなイノベーションを活用できるようになります。Spanner Omni により、既存のハードウェアインフラストラクチャ上で、スケーラビリティの確保、高可用性、グローバルな整合性などを実現する Spanner の革新的な技術を用い、マルチモデル機能を備えた次世代 AI アプリケーションの構築や刷新が可能になります。

Spanner Omni を支える技術

私たちのビジョンはシンプルです。コンピューティングリソースとデータベース用に利用可能なローカルファイルシステムがあれば、どこでも Spanner Omni を実行できるようにすることです。これを実現するために、一連のイノベーションにより、Google Cloud 独自のインフラへの依存を解消しました。Paxos コンセンサス、自動シャーディング、同期レプリケーションといった Spanner のコア技術を継承しつつ、Colossus や TrueTime といった Google 独自のコンポーネントを、創造的で革新的な新しいソリューションへと置き換えています。

あらゆる場所での分散ストレージを実現するため、Spanner Omni は Google の分散ファイルシステムである Colossus への依存を解消し、Colossus 相当の機能を提供する抽象化レイヤーを導入しました。このレイヤーは接続されたローカルファイルシステムにデータを書き込み、ネットワーク経由で他のノードから利用可能にします。ソフトウェアがシャードの分割と再配置を自動的に処理し、利用可能なすべてのサーバー間でストレージのバランスを整えることで、最適なパフォーマンスを確保します。Spanner Omni のファイルレイヤーは Colossus そのものではありませんが、ほとんどのワークロードにおいて、Spanner マネージドサービスに匹敵するパフォーマンスを発揮します。

また、原子時計と GPS を使用して世界規模で時間を同期させる、Spanner の象徴的な技術の一つであるTrueTime も再構築しました。Spanner Omni のために開発したソフトウェアベースの代替ソリューションは、Google Cloud 上の TrueTime と同様に、Spanner Omni がデプロイされたサーバー間において、誤差範囲が限定された極めて信頼性の高い時刻同期を提供します。Spanner は強力な外部整合性を実現するために時刻同期に依存していますが、時刻の不確実性に起因する待機時間を他のデータベース処理とオーバーラップさせて実行する機能を備えています。この仕組みにより、実際の TrueTime が提供するよりも緩やかな不確実性の範囲を許容することが可能です。TrueTime はこの柔軟性を活かし、Spanner の可用性やパフォーマンスを損なうことなく、多種多様な環境における正確な時刻管理を実現しています。

aside_block: <ListValue: [StructValue([('title', 'お客様からのコメント'), ('body', <wagtail.rich_text.RichText object at 0x7f5098693cd0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

アクセス方法

Spanner Omni のデベロッパーエディションは、本日よりプレビュー版として公開（ダウンロード）しています。このエディションには、非商用および非本番環境での開発やテストに適した Spanner のコア機能が含まれています。エンタープライズ向けセキュリティ機能は含まれていませんが、次なるプロジェクトのサンドボックスとして最適です。フル機能を備えた商用エディションへの早期アクセスについては、https://cloud.google.com/consulting/spanner-omni までお問い合わせください。

Agentic Data Cloud の新機能：「System of Action」を実現

Wed, 22 Apr 2026 03:50:00 +0000

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

企業は単に質問に答えるだけの生成 AI から、自律的に状況を認識し、推論し、ユーザーに代わって行動する「自律型エージェント」へと転換期を迎えています。これらのエージェントをレガシースタック上で拡張しようとすると、ガバナンスの断片化、信頼性の欠如、寸断された推論ループといった構造的な問題が露呈し、コストの急増を招くことがあります。

これらの課題を解決するために、 Google Cloud は Agentic Data Cloud を発表します。これは、エンタープライズデータプラットフォームを静的なリポジトリから動的な推論エンジンへと進化させる、 AI ネイティブアーキテクチャです。これにより「思考」と「行動」の間のギャップを埋め、 AI エージェントがビジネスデータとコンテキストに基づいて自律的に行動することを可能にします。前世代のシステムオブインテリジェンス（System of Intelligence）は人間が扱う規模を想定し構築されていましたが、Agentic Data Cloud はエージェントによる大規模な処理を前提とした「行動のシステム（System of Action）」へと進化させました。

すでに多くの先進的な企業が、Agentic Data Cloud を使用して具体的な価値を創出しています。

Vodafone は、顧客にシームレスなサービスを提供すべく、数百のエージェントを導入し、年間数百万ユーロのコスト削減を見込んでいます。
American Express は、基幹オンプレミスデータウェアハウスと数百の本番アプリケーションを BigQuery に移行し、大規模で信頼性の高い「エージェンティックコマース」を推進しています。
Virgin Voyages は、1,000 以上の専門 AI エージェントを活用しており、そのうちの 1 つは大規模な旅程の再予約にかかる時間を 6 時間からわずか 11 分に短縮しました。

本日、 Google Cloud は Agentic Data Cloud を強化する 3 つの新しいイノベーションを発表します。

ユニバーサルコンテキストエンジンは、エージェントに信頼性の高いビジネスコンテキストを提供し、精度を向上させます。
エージェントファーストの開発者体験により、データ担当者や開発者の役割をエージェントのオーケストレーターへと進化させます。
AI ネイティブなクロスクラウドレイクハウスがデータ資産全体を接続し、データサイロを排除します。

ユニバーサルコンテキストエンジンでエージェントを強化

AI の有用性は、そのコンテキストに依存します。エージェントが企業独自の「粗利」の定義や、複雑なサプライチェーンの相関関係を理解していなければ、正確な判断は下せません。エージェンティックエンタープライズの時代において、データだけでは不十分であり、従来のガバナンスモデルも十分ではありません。Google Cloud は、Dataplex Universal Catalog を Knowledge Catalog へと進化させました。これは、集約、継続的なエンリッチメント、および検索という厳格なフレームワークを用いて、データ資産全体にわたるビジネス上の意味をマッピングし、推論します。

仕組みは以下の通りです。

集約：真のコンテキストを構築するには、あらゆる場所から情報を集める必要があります。Google Cloud およびパートナーのデータプラットフォーム全体からネイティブコンテキストを集約しています。これには、サードパーティのカタログ、アプリケーション、オペレーティングシステム、および Palantir、Salesforce Data360、SAP、ServiceNow、Workday（プレビュー）などの AI プラットフォームが含まれます。Google Cloud のレイクハウスを使用することで、サードパーティのデータ資産を Knowledge Catalog へ自動的にマッピングします。Google Cloud のデータソースについては、戦略ドキュメントからセマンティクスを自律的に生成する新しい LookML Agent（プレビュー）や、ビジネスロジックをプラットフォームにネイティブに埋め込む BigQuery measures（プレビュー）によって、ビジネスロジックの自動化を実現します。
継続的なエンリッチメント： Knowledge Catalog は、組織全体の利用ログの分析とバックグラウンドでのデータをプロファイリングを通じて、継続的なエンリッチメントを提供します。これにより、データが「何であるか」だけでなく、企業内で「実際にどのように使用されているか」を学習します。この機能は非構造化データにも対応します。Google Cloud Storage にファイルが保存された瞬間に、Smart Storage（プレビュー）が瞬時に画像にタグを付け、エンリッチメントを実行します（PDF オブジェクトも近日対応予定）。また、Knowledge Catalog は有用な非構造化データのコレクションを特定し、Gemini を使用して欠落しているスキーマを自動生成して複雑な関係性をマッピングすることで、AI がコンテキストを把握できない「視界不良」の状態を防ぎます。
検索とリトリーバル： 膨大なコンテキストレイヤーの構築は重要ですが、エージェント時代において、検索は新しいクエリパスへと進化しました。エンタープライズスケールにおける大きな課題は、速度、関連性、グローバルなリーチ、そしてセキュリティです。これらを解決するため、Knowledge Catalog は Google 検索のイノベーションを基盤とした高度なハイブリッド検索スタックを採用しています。高い関連性を実現するために、セマンティックマッチングとレキシカル（語彙）マッチングを、機械学習ベースのインテリジェントなリランキングと組み合わせています。また、信頼性を確保するため、アクセス制御を考慮した検索によってセキュリティ権限をネイティブに適用しており、エージェントは権限を持つ資産のみを取得し、操作することができます。この高精度なインフラストラクチャにより、信頼できるコンテキストを即座に特定し、特化型エージェントに提供することが可能になります。

Knowledge Catalog は Deep Research Agent（プレビュー版）を強化しています。Gemini Enterprise で利用可能なエージェント群の一部であるこのエージェントは、 BigQuery などの Google Cloud データプラットフォーム、社内文書、ウェブ資産にわたって多段階の推論を行い、これまで数週間の手作業を要していた複雑な問いに対し、引用元を伴う正確な回答を提示します。

エージェントファーストな開発者体験

この新しいアーキテクチャへの移行に伴い、データ担当者の役割は、手動でパイプラインを構築することから、「意図（インテント）」に基づいたエンジニアリングをオーケストレーション（統括および制御）することへとシフトします。

この移行を加速させるため、 Google Cloud Data Agent Kit（プレビュー版）を提供します。これは新しいインターフェースを導入するのではなく、 VS Code、 Gemini CLI、 Codex、 Claude Code といった開発者が使い慣れた環境に組み込めるポータブルなスキル、ツール、環境固有の拡張機能、および組み込みプラグインのスイートを提供します。これにより、 IDE やノートブック、またはエージェント型ターミナルがネイティブなデータ環境となり、 dbt、 Apache Spark、 Apache Airflow などの適切なフレームワークを自動選択し、 Google のベストプラクティスに基づいた本番環境対応のコードを生成しながら、幅広いビジネス成果を自律的に運用できます。

このキットは単にツールを接続するだけではなく、データを移動させることなく、ペタバイト規模まで拡張可能な高パフォーマンスな機能を開発者のフローに直接組み込みます。Data Agent Kit は、Google 独自のビルトインエージェントを動かしているものと同じ次のスキルやツールが含まれています。

Data Engineering Agent（一般提供）：複雑なパイプライン変換をゼロから構築し、不良データが本番環境に混入しないようガバナンスルールを自動適用します。
Data Science Agent（一般提供）：データの前処理からトレーニングまで、モデルのライフサイクル全体を自動化し、BigQuery Dataframes および Serverless Apache Spark 上でスケーラブルに処理を実行します。
Database Observability Agent（プレビュー版）：24 時間 365 日体制でインフラを監視し、根本原因の診断とデータベースの修復を実行します。

さらに、エージェントのスムーズな実行を支援するため、Google Cloud は Model Context Protocol（MCP）を全面的に採用しました。MCP はあらゆるエージェントがデータ資産を検出および利用できる、セキュアなユニバーサルインターフェースを提供します。対応するコアエンジンには、BigQuery、Spanner（プレビュー版）、AlloyDB、Cloud SQL（一般提供）、 Looker MCP（プレビュー版）が含まれます。また、 Google Cloud 向け MCP は Google のセキュリティスタックを使用しており、既存の IAM ポリシー、 VPC Service Controls 、およびデータレジデンシー要件に基づいて、エージェントのインタラクションを管理します。

また、Conversational Analytics によってビジネスユーザー体験を再定義します。BigQuery（一般提供）、Cloud SQL、Spanner、 AlloyDB（プレビュー版）、および Looker（一般提供）に対応しており、組織はこれらのカスタム分析エージェントを Gemini Enterprise で公開するだけで、従業員が使い慣れたインターフェースでライブデータと対話できるようになります。技術的な障壁を取り除くことで、手動レポート作成に費やしていた数週間という待ち時間を排除し、ビジネスを「思考のスピード」で加速させます。

エージェントスケールに合わせて構築されたクロスクラウド基盤

エージェントが行動するには、オープンな基盤が必要です。エージェントがクラウド間の遅延によってブロックされたり、特定のベンダー環境に囲い込まれた場合、その自律性は損なわれます。そのため、データがどこに存在していてもその価値を解き放つことができる、真に境界のないクロスクラウドレイクハウスを導入します。

分析基盤の接続：Cross-Cloud Interconnect（CCI）をデータプレーンに直接統合します。 CCI の専用高速プライベートネットワークと Apache Iceberg REST Catalog を組み合わせることで、低遅延で膨大なエグレス費用なしにクラウド間の接続を実現します。その結果、エージェントは AWS や Azure 上のデータを、まるで Google Cloud のローカルデータであるかのようにシームレスなクロスクラウドアクセスで利用できます。
独自サイロの解消：特定ベンダーに依存したカタログの時代に終止符を打つべく、オープンフェデレーションを推進し、双方向フェデレーション（プレビュー版）を開始します。Iceberg REST Catalog により強化された、Amazon S3 上の Databricks Unity Catalog（プレビュー版）、 Snowflake Polaris（プレビュー版）、および Amazon S3 上の AWS Glue Data Catalog（プレビュー版）からエンジンが直接読み取れるようになります。これは強化された Lakehouse Governance（プレビュー版）によって補強され、セキュリティポリシーとアクセス制御がこの境界のない環境全体に即座に適用されます。
運用データの解放：世界で最もスケーラブルかつグローバルに一環したデータベースを、あらゆる場所で利用できるようにする Spanner Omni（プレビュー版）を発表します。これにより初めて、Googleの運営を支える Spanner エンジンをクラウド、オンプレミス、あるいはあなたの PC など、あらゆる場所で、実行可能にします。
インサイトからアクションへのギャップを埋める：インサイトとアクションの間のギャップも解消します。多くの「統合」データプラットフォームでは、複雑な ETL パイプラインの作成を必要とし、エージェントがリアルタイムデータにアクセスすることを妨げています。 AlloyDB 向けレイクハウスフェデレーション（プレビュー版）により、プロトコルレベルのゼロ ETL 同期を提供することでこれらのパイプラインを排除し、エージェントが運用トランザクションにおいて低遅延で蓄積された膨大な分析データにアクセスできるようにします。

未来の自動化に向けて

エージェント規模への移行により、ワークロードは桁違いに増加します。これをサポートするため、 Google は 4 つの主要なパフォーマンスのブレークスルーを発表します。

Lightning Engine for Apache Spark は、市場の競合製品と比較して、最大 2 倍のコストパフォーマンスを実現します。
Managed Lustre は、最大 10 TB/s のスループットを実現し、要求の厳しいモデルに対してデータを十分な速度で処理します。
Bigtable のインメモリティアにより、リアルタイムアプリケーション向けにミリ秒未満の読み取り遅延を提供します。これにより、個別のキャッシュ層が不要になります。
BigQuery fluid scaling により、オートスケーリングが適用されるワークロードにおいて、コストを平均で最大 34% 削減します。エージェントの行動に合わせて瞬時にリソースをスケールアップし、不要な時にはスケールダウンします。

System of Action で成功を築く

受動的なデータ観察の時代は終わりました。これからのビジネスは、Google Cloud の Agentic Data Cloud が実現する「System of Action」によって思考と同じ速さで動きます。

Agentic Data Cloud の詳細や、System of Action を通じて自律型エージェントを加速させるためのデータ準備については、戦略ワークショップにお申し込みください。

Agentic Data Cloud の詳細については、受動的なデータを能動的なアクションへと変えるための設計図についてご覧ください。

BigQuery Graph のご紹介: データに潜む関係性を明らかに

Tue, 21 Apr 2026 02:00:00 +0000

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

このたび、BigQuery Graph のプレビュー版の提供を開始しました。BigQuery Graph は、データエンジニア、データアナリスト、データサイエンティスト、AI デベロッパーが、大規模な関係性をこれまでにない形でモデル化、分析、可視化できるようにする、使いやすく高いスケーラビリティを備えたグラフ分析ソリューションです。

データが変化し、増え続ける中で、人、場所、商品といったさまざまなエンティティが互いにどのようにつながっているのかを把握することはますます重要になっています。結局のところ、エンティティどうしのつながりがわかってこそ、データはより大きな意味を持ちます。従来の SQL では、「友だちの友だちの友だち」を見つけるだけでも、複数の JOIN を入れ子にした処理が必要になり、記述も読解も難しくなりがちです。しかも、規模が大きくなるにつれて、パフォーマンスは急激に低下します。たとえば、嵐によるサプライチェーンの混乱がどこまで影響するのかという「影響範囲」を特定するには、複数ホップにまたがる探索、すなわち本格的なグラフ分析が必要です。こうした課題により適切に対応するため、データはしばしば、私たちを取り巻く現実世界をグラフとして表現する形でモデル化されます。こうした表現は、従来のリレーショナルデータ構造よりも、複雑で見えにくい関係性を見つけ出すのに適しています。

業界を問わず企業が直面するグラフ導入の課題

グラフ技術は、不正検知、レコメンデーションエンジン、サプライチェーン管理、ナレッジグラフアプリケーションなど、さまざまな業界で幅広く活用されています。しかし、グラフを導入するにあたっては、いくつかの大きな課題があります。

データサイロと運用負荷の増大: グラフデータをスタンドアロンのグラフデータベースに保存して管理する必要があるため、データサイロやデータの不整合、追加コストが生じるだけでなく、運用負荷も増大します。
グラフに関する専門知識の不足: グラフ技術を導入するには、新しい言語や考え方、場合によっては新しいデータベースも習得しなければなりません。その一方で、これまで組織が積み上げてきた SQL の知識やスキルを十分に生かしにくいという課題もあります。
パフォーマンスとスケーラビリティへの懸念: 多くのスタンドアロングラフデータベースは、少数のノードを起点としたグラフ走査には適していますが、ビジネスの成長に伴って数十億規模のエンティティまで拡張するのは難しい場合があります。

BigQuery Graph は、次の機能によって、こうした課題の多くに対応します。

組み込みのグラフクエリ機能: より直感的なグラフクエリ言語（GQL）により、最新の ISO GQL 標準に基づいて、異なるデータセット間のパターンを見つけたり、関係をたどったりできます。
リレーショナルデータモデルとグラフデータモデルの統合: グラフデータモデルとリレーショナルデータモデルが緊密に統合されているため、データの重複や移動を行うことなく、単一の信頼できるデータソースをもとに、最適な方法でデータをモデル化できます。さらに、グラフクエリと SQL は完全に相互運用できるため、既存の SQL スキルを生かしながら、グラフクエリの高い表現力も活用できます。
構造化データと非構造化データをまたぐグラフ分析: BigQuery Graph では、豊富な AI 関数に加え、ベクトル検索や全文検索も利用できます。これにより、グラフ上で意味ベースの検索やキーワード検索を行うことができ、構造化データと非構造化データの間を橋渡しできます。
グラフの可視化: BigQuery Studio ノートブックや Jupyter Notebook を使って、データどうしのつながりを直感的なグラフ形式で簡単に探索、調査、説明できます。
業界最高水準の使いやすさ、パフォーマンス、スケーラビリティ: BigQuery Graph は、BigQuery のサーバーレスでスケーラブルかつ費用対効果に優れた分散分析エンジンを基盤として構築されており、数十億規模のノードやエッジにも対応できます。
Spanner Graph とのインテグレーション: これにより、リアルタイムのグラフニーズには Spanner Graph、バッチのグラフニーズには BigQuery Graph という形で、両方をカバーする統一的なグラフスキーマとグラフクエリ言語を利用できます。さらに、連携クエリを使えば、データを移動することなく、Spanner の最新データと BigQuery の履歴データを組み合わせた仮想グラフを構築することもできます。
グラフとの対話: まもなく会話型分析エージェントを使用することで、グラフに直接話しかけるような操作が可能になります（続報をお待ちください）。

BigQuery Graph の主なユースケース

BigQuery Graph は、インテリジェントなアプリケーションを構築するうえで、業界を問わず幅広い可能性をもたらします。

金融詐欺行為の検出: ユーザー、アカウント、トランザクションの間の複雑な関係を分析して、資金洗浄やエンティティ間の異常な接続など、リレーショナルデータベースでは検出が困難な疑わしいパターンや異常を特定します。
Customer 360: 顧客との関係、嗜好、購入履歴を追跡します。各お客様を包括的に把握し、パーソナライズされたおすすめ情報、ターゲットを絞ったマーケティングキャンペーン、カスタマーサービスの利用体験の向上を実現します。
ソーシャルネットワーク: ユーザーのアクティビティとインタラクションをキャプチャし、友だちのおすすめ情報やコンテンツの検出のためにグラフパターンマッチングを使用します。
製造とサプライチェーン管理: グラフパターンを使用して、グラフにパーツ、サプライヤー、注文、在庫状況、欠陥をモデル化し、欠品分析、費用のロールアップ、コンプライアンスチェックを効率的に実施します。
ヘルスケア: 患者の関係性、病状、診断、治療に関する情報を捉え、患者の類似性分析や治療計画の立案に役立てます。
輸送の最適化: グラフで場所、乗り継ぎ、距離、費用をモデル化し、グラフクエリを使用して最適なルートを検索します。

実際の BigQuery Graph の活用事例

さまざまな業界のお客様が、BigQuery Graph を活用して現実のビジネス課題を解決しています。ここでは、その活用例をいくつかご紹介します。

BioCorteX: 創薬

「疾患を理解するということは、単にデータを増やすことではなく、そのデータの中にある関係性を理解することです。BigQuery Graph の経路検索を大規模に活用し、7 ホップを超える深さまで到達できるようになったことで、私たちはついにヒト代謝マップをこれまで以上に見渡せるようになりました。この規模だからこそ、試行錯誤を超えて、複雑な疾患を治療するために働きかけるべき正確な生物学的レバーを特定できます。もはや推測しているのではありません。計算機の速度で生命を再現しようとしているのです。」- BioCorteX、CEO / 共同創業者、Nik Sharma 氏

Curve: 不正検知

「BigQuery Graph を導入したことで、これまでの制約の多い SQL ベースのアプローチから脱却し、不正検知ネットワーク分析のための、よりスケーラブルなソリューションへ移行することができました。これにより、一見無関係に見えるアカウントや取引の間に潜むつながりを明らかにし、高度な不正ネットワークを検出できるようになりました。従来のリレーショナルクエリからグラフベースの分析へ移行したことで、約 910 万ポンドの削減という、測定可能な事業インパクトも得られました。この転換は、不正検知の精度を高めただけでなく、運用負荷を大きく増やすことなく、エコシステムを保護するためのスケーラブルな基盤も提供してくれました。」- Curve、データおよび ML 担当 VP、Francis Darby 氏

Virgin Media O2: 不正検知

「Virgin Media O2 では、ますます巧妙化する不正ネットワークの先を行くために、防御策を絶えず進化させています。すでに堅牢な不正アラートシステムに、新たな強力なレイヤを追加しました。BigQuery Graph を使うことで、アカウント、デバイス、アクティビティの間にある隠れた関係性を可視化する複雑な 4 ホップクエリを実行できるようになりました。この可視性の向上によって、不審な住所のネットワークを特定できるようになりました。これは単に不正を検知するだけではありません。既知のリスクネットワークへの新たな接続を被害が発生する前に検知する早期警戒システムとしても機能します。」- Virgin Media O2、データアプリケーション担当ディレクター、Jonathan Ford 氏

BigQuery Graph の使い方

BigQuery Graph は単なる新機能ではありません。データに対する新しい考え方をもたらし、より大きな問いを立て、より深いインサイトを引き出し、最も難しい課題の解決を可能にします。

次の 3 つの簡単なステップで利用を開始できます。

ステップ 1: 単一コピーのデータをもとに、DDL を使って関係テーブル上にグラフスキーマを作成します。

リレーショナルテーブルを「Account」「Person」「Loan」の各ノードに対応付け、それらの関係を「Transfers」「Owns」「Repays」の各エッジとして定義することで、金融グラフを作成します。

code_block: <ListValue: [StructValue([('code', 'CREATE PROPERTY GRAPH graph_db.FinGraph\r\nNODE TABLES (\r\n graph_db.Account KEY(id),\r\n graph_db.Person KEY(id),\r\n graph_db.Loan KEY(id)\r\n) \r\nEDGE TABLES (\r\n graph_db.Transfers \r\n KEY (id, to_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Account (id)\r\n DESTINATION KEY (to_id) REFERENCES Account (id), \r\n graph_db.Owns\r\n KEY (id, account_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Person (id)\r\n DESTINATION KEY (account_id) REFERENCES Account(id),\r\n graph_db.Repays\r\n KEY (id, loan_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Person (id)\r\n DESTINATION KEY (loan_id) REFERENCES Loan(id)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a81a6d30>)])]>

ステップ 2: 直感的な SQL / GQL を使ってデータ間の関係をたどり、隠れたつながりを見つけます。

Jacob が所有する口座と、その口座から返済しているローンを見つけます。

code_block: <ListValue: [StructValue([('code', 'GRAPH graph_db.FinGraph\r\nMATCH\r\n (person:Person {name: "Jacob"}) \r\n -[own:Owns]->(account:Account)\r\n -[repay:Repays]->(loan:Loan)\r\nRETURN\r\n account.id AS account_id,\r\n loan.id AS loan_id'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a81a6e80>)])]>

ベクトル検索とグラフトラバーサルを組み合わせて、詐欺師に類似した口座と、その口座に関する送金アクティビティを 1～6 ホップの範囲で見つけます。

code_block: <ListValue: [StructValue([('code', "DECLARE similar_account_to_fraudster DEFAULT ((\r\n SELECT array_agg(base.id)\r\n FROM VECTOR_SEARCH(TABLE graph_db.Account, 'embedding',\r\n (SELECT * FROM graph_db.Account WHERE id=102), 'embedding', \r\n top_k => 6)\r\n));\r\nGRAPH graph_db.FinGraph\r\nMATCH\r\n (person:Person)-[own:Owns]->\r\n (account:Account)-[transfer:Transfers]->{1,6}\r\n (to_account:Account)\r\nWHERE to_account.id IN \r\n UNNEST(similar_account_to_fraudster)\r\nRETURN\r\n person.id AS person_id,\r\n account.id AS src_account,\r\n to_account.id AS to_account"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50a81a6fa0>)])]>

ステップ 3: BigQuery Studio ノートブックでグラフの結果を可視化し、異なるデータどうしのつながりを、より直感的に把握します。

より専門的なグラフ可視化ツールをお探しの場合は、BigQuery Graph は G.V()、Graphistry、Kineviz、Linkurious などの業界をリードするパートナーと統合されています。これらのツールを使えば、Google Cloud コンソールの外でも、BigQuery Graph のクエリ結果を可視化できます。

準備ができたら

データ分析の未来は、つながりの理解にあります。BigQuery Graph を使えば、そのつながりを解き明かし、企業のナレッジに根ざした実用的なインサイトへと変えることができます。今すぐ使い始めて、相互に結び付いたデータの力を引き出しましょう。

BigQuery のドキュメントを見る: 概要とクイックスタートガイドをご覧ください。
チュートリアルを試す: チュートリアルを通じて、BigQuery Graph を実際に体験できます。
フィードバックを共有する: コミュニティに参加し、bq-graph-preview-support@google.com で質問できます。
関連ブログ記事:

- プロダクトマネージャー、Candice Chen

- BigQuery、プロダクトマネジメント担当ディレクター、Vinay Balasubramaniam

エージェントが自然言語を AlloyDB、Cloud SQL、Spanner のクエリに変換できるように QueryData がサポート

Tue, 21 Apr 2026 02:00:00 +0000

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

このたび、QueryData のプレビュー版がリリースされました。自然言語をデータベースクエリにほぼ 100% の精度で変換するツールです。QueryData を使用すると、AlloyDB、Cloud SQL（for MySQL および PostgreSQL）、Spanner（GoogleSQL 用）全体でエージェントエクスペリエンスを構築できます。QueryData は、自然言語から SQL への変換に関する、世界で最も競争の激しいベンチマークの一つである BiRD ベンチマークで 1 位を獲得した Google Cloud の機能と、Gemini アシストによるコンテキストエンジニアリングに基づいています。

通信業界のリーダーである Hughes Network Systems をはじめ、すでに多くのデベロッパーが QueryData を本番環境にデプロイし、そのメリットを実感しています。「Google Cloud のデータエージェントにより、ユーザーサポート業務を変革しました。QueryData は当社のソリューションの中核であり、本番環境で 100% に近い精度を実現します。エージェントシステムの未来に期待しています。」 - Hughes Network Systems、AI 担当ディレクター、Amarender Singh Sardar 氏

エージェントシステムの可能性: インテントからアクションへ

エージェントシステムは、人間へのアドバイス役から、能動的な意思決定者へと進化しています。エージェントがビジネスアクションを正確に実行するには、運用データベース（価格、在庫、取引記録など）からの正確な情報が必要です。

自然言語で表現されたリクエストを使用して、会話型入力とデータベースレコードのギャップを埋めることが不可欠です。エージェントがアクションを実行できるようにするには、自然言語をクエリに変換する質の高い機能が必須です。

開発者のジレンマ: データベースを使用するエージェントに対する自然言語が難しい理由

エージェントがエンタープライズデータをクエリする際のハードルは、精度、セキュリティ、使いやすさの 3 つです。QueryData はこれら 3 つすべてに対応しています。

精度 – 回答が不正確だと、ビジネス上の意思決定の誤り、エンドユーザーの不満、金銭的損失のリスクが生じます。多くの業界では、テキストを SQL に変換する精度が 90% だと、アクションを実行するのに不十分です。
セキュリティ - 各ユーザー（またはエージェント）が、閲覧を許可されたデータのみをクエリできるようにするには、企業に、監査可能で決定論的なアクセス制御が必要になります。LLM の判断に頼る（いわゆる「確率的」アクセス制御）だけでは、その要件を満たすことはできません。たとえセキュリティ侵害のリスクが低くても、実際に侵害が生じた場合の損失は不釣り合いに大きくなります。
使いやすさ - 高い精度を達成するには、デベロッパーがデータに関する広範なコンテキスト情報を提供する必要があります。これは手間のかかる作業です。また、エージェントツールを統合して維持する作業なども、デベロッパーの負担になります。

精度のギャップを理解する

LLM はクエリコードの作成に非常に優れています。しかし、特定のデータベースに対して正確なクエリを作成するには、コーディングスキルやスキーマの解析機能を備えているだけでなく、以下のような状況に対応できる必要があります。

スキーマが不明確なことがある - デベロッパーは略称や短縮名を使用することがよくあります。たとえば、「product」という名前の列は何を意味するでしょうか？商品カテゴリなのか、特定のモデルなのか、不明確です。「prod」や「p」のような列名では、さらにわかりにくくなります。
値が曖昧なことがある –「注文返品ステータス」という列を例に取ってみましょう。値は「1」、「2」、「3」という整数で表されています。このうち、「返品済み」または「返品手続き開始済み」を表すのはどれでしょうか？
スキーマはデータ構造を定義するが、ビジネスロジックには対応しない - ビジネスでは、「1 か月のアクティブユーザー」を、ログインしただけでなく、少なくとも 1 回投稿したユーザーとして定義する場合がありますが、データベースにはこのニュアンスがない場合があります。
クエリの指定が不十分 – 自然言語の質問は、「最新の売上」のように曖昧な場合があります。

QueryData はほぼ 100% の精度をどのように実現するか

QueryData は、Gemini LLM と、独自のデータベースを記述するコンテキストを活用します。

データベースコンテキストは、基本的に QueryData を強化するコードであり、以下を含む説明と指示のセットです。

スキーマオントロジー – データの意味に関する情報。列、テーブル、値の説明。QueryData が質問に答えるために必要なデータを把握して、曖昧さを克服するうえで役立ちます。
クエリのブループリント - 特定の種類の質問に答えるためにデータベースクエリを記述する方法に関するガイドラインと明示的な指示。テンプレートとファセットは、特定の種類の質問に対して記述する正確な SQL を指定します。

最後の手段として、QueryData は、明確化のための質問が必要な状況を検出します。

クエリの決定論的なセキュリティ

エージェントアプリケーションには、決定論的で監査可能なセキュリティが必要です。デベロッパーは、パラメータ化されたセキュアビュー（PSV）を使用して、ユーザー ID やリージョンなどの固定パラメータを介してエージェントのアクセスを定義できます。アプリケーションはセキュリティ上重要なこれらのパラメータをクエリとは別に渡すことで、エージェントが許可されたデータにのみアクセスできるようにします。これにより、エージェントが制限された情報をクエリしようとしても、できなくなります。

PSV は現在 AlloyDB でサポートされており、Cloud SQL と Spanner でも近日中にサポートが開始される予定です。

品質向上とツール統合のための使いやすさ

QueryData はエージェントワークフローに簡単に統合できます。QueryData API は、直接使用することも、人気のあるオープンソースの MCP サーバーであるデータベース向け MCP ツールボックスを介して Model Context Protocol（MCP）ツールとして公開することもできます。QueryData はさまざまなデータベース言語に自動的に対応します。データベース固有のコードは不要で、1 つの API ですべてのデータベースにクエリを実行できます。

QueryData がデベロッパーの作業を容易にするもう 1 つの領域は、コンテキストエンジニアリングです。コンテキストエンジニアリングは、コンテキストを繰り返し評価して最適化するプロセスです。これは、QueryData がデータベースに対して正確にクエリを実行する能力にとって非常に重要です。QueryData を使用するデベロッパーは、以下の堅牢なツールスイートを利用できます。

すぐに行えるコンテキスト生成 – QueryData を構成すると、Gemini CLI の専用エージェントである Context Engineering Assistant が、データベースの最初のコンテキストセットの作成を支援します。
評価: デベロッパーは、バンドルされている Evalbench フレームワークを使用して、ユースケースに固有の一連のテストに対する精度を測定できます。
コンテキストの最適化: Context Engineering Assistant は評価結果を確認し、変更を推奨してから、評価の再実行を支援します。この反復プロセスを通じて、ほぼ 100% の精度を達成できます。

QueryData で今すぐ構築できるもの

デベロッパーはすでに QueryData を使用してさまざまなものを構築しています。例を以下に示します。

顧客向けアプリケーション: 不動産検索エンジン。QueryData がユーザープロンプトをデータベースクエリに変換し、内覧の予約をスケジュールします。
社内ツール: AI を活用したスタッフ配置アプリ。人事データをクエリして、マネージャーが従業員をシフトに割り当てられるようにします。
マルチエージェントアーキテクチャ: 貿易コンプライアンスワークフロー。最上位のエージェントがサブエージェントに、取引相手の KYC（顧客理解）ステータスが適切であることを確認するよう指示します。KYC エージェントがデータベースにクエリを実行して、顧客の身元を確認します。

次のステップ

エージェントを介して、ほぼ 100% の精度のデータベース呼び出しを行うためのツール、QueryData の使用を今すぐ開始できます。詳しくは、以下の技術ドキュメントをご覧ください。

下に示す「スイスの物件検索」の高忠実度デモをご確認ください（動画チュートリアルはこちら）。注: これは独立したプロジェクト（Google Cloud によって管理されていない）であり、説明のみを目的としています: GitHub リンク

- グループプロダクトマネージャー、Tom Kubik

- エンジニアリングディレクター、Andrew Brook

Spanner の完全に相互運用可能なマルチモデルデータベースを使用した実際の成功事例

Thu, 16 Apr 2026 01:00:00 +0000

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

生成 AI の基盤を築くマルチモデルデータベースの力に焦点を当てた最初の投稿では、組織がデータベースのアーキテクチャと管理に対する従来のアプローチでもたらされる課題を克服するうえで、Google Cloud Spanner がどのように役立つかを説明しました。この投稿では、4 つの一般的なユースケースを取り上げて、具体的な例を詳しく見ていきます。

以下に挙げる 3 つの主要な戦略目標を達成するために、Spanner のマルチモデル機能を選択するお客様が増えています。

スケーラビリティと信頼性の基盤: グラフ、ベクトル、検索などに特化した多くの専用データベースは、従来の単一マシンアーキテクチャで構築されています。結果として、お客様はスケーラビリティ、可用性、整合性に関する根本的な課題に直面しています。限界に達したか、あと少しで達するため、お客様はこうした専用システムから移行しています。Spanner のすべてのデータモデルは、99.999% の可用性、自動スケーリング、無制限の水平スケーリングを提供する実証済みのプラットフォーム上に構築されており、新しい機能へと簡単に拡張できます。たとえば、既存のグラフスキーマにベクトルエンベディング列を追加するといったことが可能です。
乱立するデータベースの統合と ETL の排除: 複数の異なるデータベースにそれぞれ独自のデータモデル、クエリ言語、バックアップポリシーがある場合、それらを管理、保護し、パッチを適用するのは、ユーザーにとって悪夢のような煩わしい作業になります。データを同期するために必要な抽出、変換、読み込み（ETL）パイプラインは、不整合や遅延を生み出すことが多く、特にストレスとなります。Spanner は、単一の統合データベースで複数のデータモデルを提供することで、この複雑さを解消し、余分なデータコピー、不整合、管理オーバーヘッドを排除します。さらに、Spanner の相互運用可能なマルチモデル機能により、デベロッパーは 1 つの SQL クエリを作成するだけで、リレーショナルテーブルを結合し、グラフ関係を走査し、ベクトル検索またはテキスト検索機能に対してフィルタを適用できます。
進化するアプリケーションニーズに適応する将来性: 多くのお客様は簡単なアプリケーションから始めますが、時間の経過とともに、よりスマートでより複雑なアプリケーションにする必要が生じることを認識しています。Spanner では、グラフベースのレコメンデーションや AI を活用したベクトル検索を後から追加できます。デベロッパーは、簡単なデータ定義言語（DDL）コマンドを使用して、運用データに対してグラフ機能や検索機能を簡単に有効化できます。Spanner を使用すれば、面倒な移行も複雑な再設計も不要で、成長の限界もありません。お客様は、信頼性の高いリレーショナルデータベースを基盤として構築しながら、アプリケーションの進化に合わせて新しい高度なデータモデルをシームレスに追加できます。

ここでは、さまざまな業界のお客様が、Spanner の進化するマルチモデル機能を活用して、最も困難なデータ課題を解決し、早期に成功を収めている例をご紹介します。

1. 不正行為の検出

不正行為者は、複数のトランザクションやアカウントにまたがる複雑でわかりにくいパターンを悪用することがよくあります。従来のリレーショナルデータベースでは、このような入り組んだ関係をリアルタイムで検出するのは容易ではありません。Spanner は、リレーショナルクエリとグラフ分析を組み合わせて、リアルタイムのパターン認識を実現します。これにより、企業は不正行為を示す可能性のある不審なクラスタや異常な接続を効率的に特定し、財務上の損失を大幅に削減してセキュリティを強化できます。

DANA: 急速に拡大する顧客ベースに対するマネーロンダリング対策

DANA は、インドネシアを拠点とする電子ウォレットアプリで、融資、保険、投資などの支払いとデジタル金融サービスを提供しています。DANA は自社に不可欠なマネーロンダリング対策（AML）の取り組みをサポートするために、Spanner Graph を採用しました。

課題: 急速に拡大を続ける大規模なユーザーベースを持つ DANA は、トランザクションにおけるマネーロンダリングのパターンを検出するために、既存のリレーショナルデータベースを使用して、スケールしてクエリパフォーマンス SLA を満たすのに四苦八苦していました。グラフデータベースで分析を行うように移行すればよいのは明らかでしたが、市場の多くのグラフデータベースプロバイダは、そのような規模には対応できませんでした。
ソリューション: 綿密な RFP プロセスを経て、その高可用性、実質無制限のスケーラビリティ、外部整合性から、Spanner が選ばれました。全文検索（FTS）とベクトル検索をグラフモデル内で直接使用できる機能が、重要な差別化要因となりました。

Palo Alto Networks: SaaS ID のアクセスグラフ

サイバーセキュリティの大手企業である Palo Alto Networks は、Spanner を活用して組織の ID 体制に関する分析情報を提供し、構成ミスや過剰な権限を持つアカウント、休眠アカウント、ローテーションされていない認証情報、ID プロバイダ（IDP）にないアカウントを検出しています。

課題: チームは、データサイロを生み出すことなく高いスケーラビリティを確保しながらイノベーションを加速できる、AI 時代に対応する世界クラスのエージェントセキュリティプロダクトを構築する必要がありました。
ソリューション: Spanner 上に「アクセスグラフ」を構築し、ユーザー ID、アクセス許可、関連するユーザーアクティビティを SaaS アプリケーション内で接続しました。Spanner では、グラフとグラフ以外の両方のユースケースに対して単一のスキーマをシームレスに使用して、大規模なスケールを実現できます。

Verisoul.ai: リアルタイムの偽ユーザー検出

Verisoul は、偽ユーザーを検出して防止するための AI を活用した統合プラットフォームを提供しており、アカウントが実在し、一意で、信頼できるものであることを保証します。

課題: Verisoul は以前は、Postgres、Cassandra、Neo4j にわたる 10 種類の独立したサービスを構築、維持することで、ネットワークインテリジェンス、デバイスインテリジェンス、行動データやセンサーデータ、メール、マルチアカウンティングなど、さまざまな種類のデータを処理していました。この複雑さにより、最新の不正攻撃の速度、規模、高度化に対抗できるゼロレイテンシ検出を提供することが困難になっていました。
ソリューション: Spanner に統合することで、Verisoul は何百万ものアカウントを持つ何百もの顧客をリアルタイムでモニタリングし、すべてのログイン、ページビュー、クリック、マウスの動きを捕捉できるようになりました。Spanner により、グラフ、ベクトル検索、そして BigQuery とのシームレスな統合のためのオールインワンデータベースが得られ、メンテナンスのオーバーヘッドを排除しながら、無制限のスループットの提供をすべてシンプルなアーキテクチャで実現することができました。

2. レコメンデーションエンジン

パーソナライズされたレコメンデーションは、消費者向けオンラインビジネスの中核をなすものです。効果的なレコメンデーションエンジンを構築するには、膨大な量のユーザー行動データ、商品やサービスの属性、過去のインタラクションを分析する必要があります。Spanner の相互運用可能なクエリを使用すると、ユーザープロファイル（リレーショナル）、インタラクション履歴（検索）、商品の類似性（グラフ）を組み合わせて、関連性の高いおすすめ表示をリアルタイムで生成し、ユーザーエンゲージメントの向上を促進し、コンバージョン率を改善できます。

Target: ベクトル検索とグラフ検索を組み合わせてギフトのおすすめを表示

Target は、生成 AI を活用した Gift Finder を使用して高度にパーソナライズされたギフトのおすすめを表示し、ホリデーシーズンのショッピング体験を向上させたいと考えていました。

課題: アプリケーションは検索専用データベースで実行されており、表示するギフトのおすすめの内容は限定されていました。ショッピング体験をパーソナライズしてより良いものにするには、高度なアップグレードが必要でした。
ソリューション: Target は、汎用性の高いハイブリッドクエリモデルとなる Spanner Graph を選択しました。このソリューションは、グラフ走査機能とベクトル検索を独自のエンベディングと組み合わせて、直感的なリアルタイムの商品提案を実現します。これらすべてを、2025 年のブラックフライデーとサイバーマンデーの買い物商戦に間に合わせることができました。

True Digital Group: AI 検索を統合

タイの大手通信テクノロジー企業である True Digital Group は、ストリーミングメディアと印刷メディアの両方にわたる幅広い高品質なデジタルサービスと、顧客ロイヤリティの追跡を提供しています。同社の AI を活用したインテリジェント検索機能により、キーワードとユーザーインテントに基づいてコンテンツを正確に取得できます。

課題: 複数のデータベースでスタックが断片化されていることで、データの更新頻度の低さ、整合性のないトークン化、複数のクエリ言語の混在、検索の品質低下などから、ユーザーは検索機能の使用を避けるようになっていました。
ソリューション: True Digital は、すべての検索機能を Spanner に統合しました。SQL を使用してキーワードとインテントベースの検索結果を組み合わせることで、検索の関連性と精度が大幅に向上し、顧客エンゲージメントと満足度の向上につながりました。

3. ハイブリッド検索

情報検索は、事実に基づいた最新データで AI モデルをグラウンディングし、エージェントワークフローを可能にする重要な架け橋です。多くの場合、ユーザーは法的文書、財務報告書、研究論文の膨大なコーパスを検索する必要があります。これはまるで、干し草の山の中から特定の針を探すようなものです。相互運用可能なマルチモデル Spanner は、ハイブリッド検索機能でお客様を支援し、AI モデルが任意の規模で最も関連性の高いコンテキストを正確に取得できるようにします。

Rogo: 財務ワークフローの自動化

Rogo は、独自の社内データと、ファイリング、PitchBook、LSEG、FactSet、S&P Capital IQ などの外部の金融情報源を接続し、財務担当者が提案資料の作成から投資メモの作成まで、ワークフローを自動化できるよう支援しています。

課題: Rogo は、構造化形式と非構造化形式の両方にわたって、数十の情報源からデータを同時に取り込んで接続する必要があります。これをサポートする適切なバックエンドを見つけるのは簡単ではありませんでした。
ソリューション: Rogo は、その高いパフォーマンス、スケーラビリティ、管理のしやすさから、Google Cloud Spanner を選択しました。リレーショナルデータとドキュメントベースのデータの両方を 1 か所に保存してクエリを実行できるため、プラットフォームの成長に伴い、監査とメンテナンスが容易になりました。

Inspira: リーガルインテリジェンスのストリーミング

リーガルテックの大手企業である Inspira は、法的調査や一般的な労働力の最適化に特化した、AI を活用したソリューションを提供しています。同社のプラットフォームは、法律事務所、企業、政府機関にサービスを提供し、7,500 万件の法的文書と 4 億 4,000 万件のベクトルの膨大なリポジトリを管理しています。

課題: Spanner に移行する前、Inspira は、Elasticsearch、BigQuery、Cloud SQL で構成された多言語対応システムに依存する、複雑で断片化されたアーキテクチャに苦慮していました。これにより、データの同期が複雑化し、キーワード検索とベクトル検索を組み合わせるために複雑な「2 段階」のクエリフィルタリングが必要でした。また、レイテンシと高い読み取り / 書き込みスループットを犠牲にすることなく、10 億個を超えるベクトルをスケールする方法も必要でした。
ソリューション: こうした非効率性を解消するため、Inspira はスタック全体を Spanner に統合し、4.5 TB のデータパイプラインを、統合された高パフォーマンスの信頼できる唯一の情報源へと大幅に簡素化しました。FTS とベクトル検索の両方をネイティブにサポートする Spanner を活用することで、ハイブリッドクエリにおいて「1 段階」のフィルタリングが可能になり、RAG ワークフローを使用した LLM ベースの法的分析において高精度のスニペットを実現しました。

4. 自律型ネットワーク運用

自律型ネットワーク運用（ANO）は、事後対応型メンテナンスから予防的な自己修復型ネットワークへの移行を意味します。ネットワークトポロジの包括的なデジタルツインを作成し、リアルタイムの運用データと重ね合わせることで、通信事業者は根本原因分析を自動化し、異常を予測し、人手を介さずにネットワークインシデントを解決できます。

MasOrange: デジタルツイン

MasOrange の ANO の取り組みの中心にあるのは、時間的デジタルツインです。これは、同社の全国規模のワイヤレスネットワークトポロジを、オペレーションサポートシステム（OSS）やビジネスサポートシステム（BSS）のデータとともに複製します。

課題: MasOrange は、ANO スタックの基盤となる、ゼロ RPO / RTO の高可用性で無限にスケーラブルなグラフデータベースを必要としていました。複数の異なるソリューションの管理という運用上のオーバーヘッドのない、ベクトル検索や全文検索機能を求めていました。
ソリューション: MasOrange は、スケーラビリティと可用性の厳しい要件を満たしながら、完全に相互運用可能なグラフ検索、ベクトル検索、全文検索機能を提供できることから、Spanner を選択しました。現在、MasOrange のデジタルツインは Spanner 上で稼働しており、エンドツーエンドの異常検出と根本原因分析を強化しています。

今後の展望

スケール保証、高い信頼性、グローバルな整合性、さまざまなデータモデルを相互運用可能な方法で処理する汎用性を備えた Spanner は、エージェントワークロードに対応できる将来を見据えたデータベースです。

Google は、データベースが単純な実装の詳細となり、デベロッパーは生産性の向上、運用効率の改善、ビジネス目標の達成に純粋に集中できるようになる未来を思い描いています。Spanner のページで詳細をご覧になり、詳細を確認して今すぐ始めましょう。

- グループプロダクトマネージャー、Wenzhe Cao

ID.me、1 億 6,000 万ユーザーに対応するスケーリングと運用リスクの軽減を同時に達成

Thu, 09 Apr 2026 02:00:00 +0000

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

編集者注: ID.me は、デジタル ID のセキュリティを変革することで、ID の確立が容易であることを証明しています。さらに、同社のプラットフォームは 1 億 6,000 万人の会員に対応できるようスケールされ、1 分あたり最大 40,000 人のユーザーへの対応が可能となっています。圧倒的な規模とリアルタイム AI を必要とする税務申告などのサービスに対応するために、同社のチームは 50 テラバイトのデータを従来のプラットフォームから Google Cloud に移行し、AlloyDB、Cloud SQL、Vertex AI を基盤とする最新のアーキテクチャを採用しました。このアーキテクチャにより、開発の迅速化、不正行為の検出精度の向上、データチーム全体の作業完了時間の 40% 短縮が実現しました。

皆さん、家を出るときは、スマートフォン、運転免許証、クレジットカードなど、必ずなんらかの身分証明書を携帯するでしょう。それによって自分の身元を証明できますし、ほぼどこでも利用できます。しかし、オンラインでは、何度も本人確認を求められ、新しいサービスやツールを使い始めるたびに、新しいログイン情報を作成する必要があります。ID.me は、ユーザーが本人確認を一度だけ安全に行い、その認証情報をオンラインのどこでも使用できるようにすべきだと考えています。

当社の目標は、公的機関と民間企業の両方で信頼性の高いログイン方法として機能する、ID 用のデジタルウォレットを開発することです。当社は現在、1 億 6,000 万人以上の会員にサービスを提供しており、私たちの生活や仕事において ID の重要性が高まっています。このため当社は、対面で運転免許証を提示する場合と同じくらい簡単に、オンラインで本人であることを証明できるよう規模を拡張しています。

追いつかないスピードで増える需要

ID.me の以前の会員数は 5,000 万人でしたが、この数年間で 1 億 6,000 万人以上という規模まで成長しました。現在は 1 日単位での使用状況のトラッキングは行わず、代わりにほぼリアルタイムのモニタリングを行っています。現時点で、当社のプラットフォームは 1 分あたり最大 40,000 人の会員に対応できるように設計されています。この種の需要は予測できません。ID.me の会員にとって、アクセスがすべてです。稼働時間だけでなく、政府の給付金、医療、限定特典などに関して、会員が必要とする場合に、安全かつ即座に本人確認を行えることが重要です。そしてユーザー数が拡大する中、当社のインフラストラクチャを必要な形でスケールできていないことがわかりました。アーキテクチャの限界に達しつつあったため、当社はある決断を下しました。ID.me のデータ基盤を Google Cloud 上で再構築して、次の成長段階に備えることにしたのです。

1 億 6,000 万人の大切なお客様と当社のための新しいデータベース

最初の作業は、当社が必要としていた圧倒的なスケーラビリティと信頼性を実際に提供できるデータベースを選択することでした。すぐに目に留まったのが AlloyDB for PostgreSQL でした。以前の環境で直面していたスケーリングのボトルネックと運用上の複雑さに直接対処するソリューションであったため、ピーク時の需要にも自信を持って対応できるようになりました。この移行によって、技術的な課題を解決できただけでなく、開発者のエクスペリエンスが劇的に向上しました。チームがプロビジョニング、メンテナンス、パッチ適用に費やす時間が大幅に減り、開発サイクルが数週間からわずか数日に短縮されました。

過去 2 年間で、15 個のデータベースインスタンスに分散されていた 50 テラバイト以上のデータを Google Cloud に移行しました。しかも、ダウンタイムは最小限で済みました。また、2 階層アーキテクチャも導入しました。Cloud SQL がより小規模かつ標準的なサービスをサポートし、AlloyDB が ID.me プラットフォームのバックボーンを形成するより負荷の高いワークロードを実行します。これにより、安定性を損なうことなく迅速に処理を進めることができます。また、チームに余裕が生まれ、実際にイノベーションを推進する作業に集中できています。たとえば、当社の ID に対する取り組みに逆行するのではなく、確実に役立つ AI の開発などです。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースでよりスマートに構築'), ('body', <wagtail.rich_text.RichText object at 0x7f50a81b0d90>), ('btn_text', ''), ('href', ''), ('image', None)])]>

AI トレーニングの目的は . . . AI との戦い？

あらゆる組織が AI を活用しようと躍起になっています。しかし ID.me では、その不正使用を防ぐことも同じくらい重要です。脅威の状況は進化しており、特に生成モデルは、個人になりすます能力だけでなく、合成 ID を作成する能力も高めています。ユーザーが名乗ったとおりの人物であることを確認することをビジネスとしている当社にとって、この脅威は大きな問題です。

AlloyDB の優れた点の一つは、複数の読み取りプールを作成できることです。当社では、これらの読み取りプールを、データエンジニアやデータサイエンティストと迅速に共有できるデータクリーンルームとしています。不正行為分析担当者がそこに入り、問題を発見して、リアルタイムで修正または防止できます。

全体で見ると、AlloyDB AI のおかげで従来のシステムを 10～20 倍にスケールし、さらに料金も下げることができました。その効果は非常に大きいものです。ID.me は、米国連邦政府から、国家システム内での大規模な不正行為を防止する役割を担っていると認められています。この成功の重要な要因となったのは、AlloyDB に組み込まれた高可用性と、スケーリングが容易な読み取りプールです。これにより、米国の国家税務当局である Internal Revenue Service（IRS）は、前回の納税申告のピーク時に、1 秒あたり 120,000 件を超えるトランザクションを滞りなくシームレスに処理できました。これは実質的に、以前のセルフホスト型 PostgreSQL のパフォーマンスの 2 倍に相当します。

多くの新機能を試してきましたが、特に期待しているのは Gemini Enterprise と AlloyDB AI の自然言語です。これにより、当社の AI の構築と操作の方法に根本的な変化がもたらされるからです。

1 つのログインであらゆるシステムにスムーズに対応

当社のデータチームは Google Cloud を大いに活用しており、作業が大幅に楽になりました。移行後は、変更をはるかに迅速に行えるようになり、全体の作業完了時間が 40% 短縮されました。ID.me のエンジニアリングチームでは、開発者のエクスペリエンスが劇的に向上しました。チームが製品の機能全体をリリースするまでに要する期間が数週間から数日に短縮し、当社の会員にとって重要な問題の解決に時間を費やせるようになりました。

インフラストラクチャのスケーリングと信頼の拡大を同時に達成できました。ポータブル ID を圧倒的な規模で処理できるように構築された、より高速でスマートなプラットフォームにより、当社は目標達成に一歩近づきました。それは、必要なときに必要な場所で、デジタルによる安全な方法で本人確認を行うことができるソリューションです。子どもの頃に飼っていたペットに関するセキュリティ保護用の質問は、もうなくなるかもしれません。

詳細:

AlloyDB と AlloyDB AI の機能の詳細をご確認ください。
AlloyDB の無料トライアルを今すぐ開始しましょう。
AlloyDB を活用してビジネスを変革している Bayer や Character.ai などのお客様の事例をご覧ください。

- ID.me、クラウドプラットフォームアーキテクト Kevin Liu 氏

エージェント型 AI の時代を支える Spanner のマルチモデルによる強み

Tue, 07 Apr 2026 02:00:00 +0000

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

エージェント型 AI の時代を迎え、データベースの役割は根本的に変わりつつあります。データベースは、もはや単なる受け身のデータ保管場所ではありません。生成 AI の基盤モデルを支え、先回りしたアクションを促す推論エンジンの土台となる、インテリジェントで能動的なコンテキストハブへと進化しています。高度な AI やエージェント型ワークフローを支えるには、データベースは単にデータを保存して検索するだけでは不十分です。複数のデータモデルが共存する環境の中で、推論を支援し、豊かなコンテキストを提供し、静的な情報から先を見越したアクションを導く役割が求められます。

マルチモデルデータベースというアプローチでは、分断されたサイロ間でデータを手作業で連携させる代わりに、リレーショナルデータ、ベクトルデータ、グラフデータを統合し、豊富で一元化されたナレッジベースを構築できます。これにより AI は、状況に関するコンテキスト、意味的なコンテキスト、関係性のコンテキストを同時に活用できるようになります。Google Cloud の Spanner は、グローバルな整合性、スケーラビリティ、フルマネージドの運用性を備えたデータベースとして、AI 時代を見据えて設計されています。データを統合し、高度なエージェント型 AI を支えるための一貫したアプローチを提供します。

この投稿では、Spanner が組織の AI 活用を本番運用レベルへと引き上げるうえで、どのように役立っているのかを見ていきます。さらに具体的な事例を知りたい方は、関連する記事もあわせてご覧ください。そこでは、不正検出、パーソナライズされたおすすめ表示、ハイブリッド検索、自律型ネットワーク運用という 4 つの主要分野を取り上げています。

相互運用性を備えたマルチモデルデータベースの力

現在一般的に行われている分断された複数データベースの運用戦略には、次のような重大な課題があります。

データの不整合: 信頼できる単一の情報源が存在しないため、開発者は壊れやすいアプリケーションコードによって無理に整合性を保たなければなりません。その結果、データの重複や陳腐化が生じるだけでなく、ガバナンスやセキュリティ上の深刻な脆弱性につながります。最終的には、アプリケーション全体の信頼性は、最も SLA の低いデータベースに左右されてしまいます。
運用とスキルのサイロ化: 異なるシステムを個別に管理することは、膨大な運用負荷を生むだけでなく、チームを専門スキルごとの縦割り構造に分断します。その結果、「複雑性のコスト」が発生し、コストの増大と開発スピードの低下を直接招きます。
統合インテリジェンスを阻む要因: 本質的なデータサイロに加え、ETL に伴う遅延がアーキテクチャ上の障壁となり、先進的な AI アプリケーションに不可欠な、リアルタイムで文脈を理解するインテリジェンスの実現を妨げます。

こうした課題が重なることで、AI 時代において大きな構造的不利が生じます。

Spanner がもたらす AI 時代の優位性

Google は長年にわたり、最も要求の厳しいクラウドワークロードにも対応できるよう、Spanner を継続的に進化させてきました。そして生成 AI の登場により、データベースにはこれまでにない新たな課題への対応が求められています。

そうした中、Spanner はその中核基盤を土台に、昨年、相互運用性に優れたマルチモデル機能を導入しました。これにより、リレーショナル、Key-Value、グラフ、ベクトルといった多様なモデルを用いて、単一の高性能なデータベース基盤の中でデータにアクセスし、クエリを実行できるようになりました。各データモデルは、それぞれ独自の強みを備えています。

リレーショナル: Spanner は、リレーショナルスケールアウトデータベースの先駆けとして、Google SQL と PostgreSQL の両方の言語で ANSI SQL を提供し、世界規模で可用性 99.999% と強整合性を実現しています。
Key-Value: Spanner は高性能な Key-Value データベース機能も備えています。Cassandra ネイティブエンドポイントにより、アプリケーションコードを変更することなく、Cassandra のワークロードを Spanner に容易に移行できます。
グラフ: ISO 標準の GQL を基盤としており、データをネイティブなグラフとしてモデル化することも、リレーショナルデータの上にシンプルなオーバーレイとして表現することも可能です。
ベクトル: KNN と ANN の両方に対応した、完全統合型のセマンティック検索ソリューションを提供します。特に ANN は、Google が持つ最先端の ScaNN 技術を用いて構築されており、100 億を超えるベクトルを含むインデックスにも対応できます。
全文検索: Google が数十年にわたり培ってきた検索技術を基盤に、40 以上の言語に対応した高度な情報検索機能を標準で備えており、構造化データと非構造化データの両方を横断して検索できます。
データウェアハウスとの統合: トランザクションデータと、分析処理から得られるインサイトをシームレスに結び付けることができます。

この統合アーキテクチャにより、複数の専用データベース間で複雑なデータ同期を行う必要がなくなり、環境を大幅に簡素化しながら開発を加速できます。お客様は Spanner の相互運用性に優れたマルチモデル機能を活用することで、異なる種類のデータをシームレスに組み合わせられるようになります。

AI をグローバル規模で成功へと導く企業

MakeMyTrip は、Spanner のマルチモデル機能を活用し、厳しい実運用環境の中で AI を本番導入している数多くの企業の一つです。

インドを拠点とするオンライン旅行会社 MakeMyTrip は、4 つの専用データベースを単一の Spanner インスタンスに統合することに成功しました。これにより、運用の複雑さを大幅に軽減するとともに、AI イノベーションを加速させ、高性能で高品質なアウトプットを実現しています。

MakeMyTrip でテクノロジー開発を統括する Ravindra Tiwary 氏は、Spanner への移行が組織にもたらしたさまざまなメリットについて、次のように述べています。「私たちは MongoDB、Neo4j、Elasticsearch、Qdrant を 1 つの統合システムに集約し、運用の複雑さを 75% 削減しました。この移行によって、複数のデータベースごとの違いに対応する負担や、重複した同期パイプラインを管理する手間が解消されました。

とりわけ大きな変化をもたらしたのは、語彙検索、キーワード検索、埋め込み検索を横断する統合クエリを、単一のプラットフォーム上で実行できるようになったことです。この統合により、統合ビュー機能の開発サイクルは 30% から 50% 加速し、目的地ごとに週 5.5 時間から 9.5 時間の運用工数を削減できました。

さらに、Spanner を信頼できる単一の情報源として活用することで、データドリフトを解消し、事実情報をアトミックに更新できるようになりました。その結果、回答品質スコアは 9% 向上しました。Spanner は今や、当社の『Destination Expert』エコシステム、すなわちパーソナライズされた旅行提案を行う自社開発の生成 AI 搭載旅行プランナー bot と、今後の AI ワークフローを支えるうえで不可欠な、スケーラブルかつ高性能な基盤となっています。」

AI 活用の取り組みで新たな到達点に達したのは、MakeMyTrip だけではありません。Target、Palo Alto Networks、MasOrange といった先進的な企業が Spanner を活用してどのように成果を上げているのかについては、次回の投稿でご紹介します。

Spanner を活用した自社の AI 活用を始めるには、Spanner のページをご覧ください。詳細を確認し、今すぐ取り組みを始めることができます。

- グループプロダクトマネージャー Wenzhe Cao

Manhattan Associates、Google Cloud データベースで 1 日に 10 億件以上の API 呼び出しを処理

Mon, 06 Apr 2026 02:10:00 +0000

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

編集者注: サプライチェーンとオムニチャネルコマースソリューションのグローバルリーダーである Manhattan Associates は、それまで使用していた Oracle と DB2 のシステムから Google Cloud データベースに移行することで、Manhattan Active SaaS プラットフォームをモダナイズしました。Cloud SQL と BigQuery を活用することで、同社は現在、1 日あたり 10 億件以上の API 呼び出しを平均 150 ミリ秒未満の応答時間で処理しており、数万の店舗と物流センターで毎月数十万人のアクティブユーザーをサポートしています。

モノリシックな基盤からクラウドのレジリエンスへ

当社の Manhattan Active SaaS プラットフォームは、グローバルサプライチェーンのサポートに不可欠なため、常時稼働と高いパフォーマンスが求められます。従来の Oracle と DB2 のインフラストラクチャは、手動によるスケーリング、複雑なライセンス管理、高額なメンテナンス費用が必要で、運用に大きな負担が生じていました。そのため、可用性を契約条項に規定した SLA、自動化されたレジリエンス、予測可能な費用モデルを利用できる新しいデータベース基盤を必要としていました。

当社が Google Cloud のデータベースを選んだのは、Manhattan Active をグローバル規模で稼働させるために必要な、柔軟性、スケーラビリティ、運用の容易さのバランスが適切だったからです。マネージドデータベースの Google Cloud SQL を使用することで、手動でのメンテナンスを排除でき、組み込みの高可用性、スケーラビリティ、リージョン間の障害復旧に注力できるようになりました。

Manhattan Active の各機能は、現在、独立したコンテナ化されたサービスとして実行されており、Google Kubernetes Engine（GKE）によってオーケストレートされています。データは Pub/Sub を介して BigQuery にストリーミングされ、リアルタイム分析が行われます。また、Cloud Logging と Cloud Monitoring により、大規模なオブザーバビリティを実現しています。Google Cloud のマネージドサービスを活用したマイクロサービスファーストの設計により、当社は、迅速に進化するためのアジリティを得られたほか、全リージョンにおいてミッションクリティカルな運用のレジリエンスを維持できるという確信を持つことができました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースでよりスマートに構築'), ('body', <wagtail.rich_text.RichText object at 0x7f50a819e5b0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

あらゆるトランザクションにレジリエンスとスピードを組み込む

当社のプラットフォーム基盤を Google Cloud で刷新したことで、大規模に価値を提供する方法を再検討する機会が生まれました。Manhattan Active のアーキテクチャは、マネージドデータベースと連携することで、サプライチェーンの煩雑さが解消され、応答性とレジリエンスに優れたシステムへと変わりました。

そのメリットはプラットフォーム全体に波及しています。Cloud SQL は Manhattan Active の中核を担っており、1 日あたり数百万件に及ぶサプライチェーンのトランザクションを迅速かつ確実に実行しています。リアルタイム分析は BigQuery に送信され、より精度の高い予測と、より迅速な異常検出を小売業者に提供しています。自動フェイルオーバーとクロスリージョンレプリカによってビジネスの継続性が確保されるため、障害が発生した場合でも重要なサービスは利用可能な状態を維持できます。

基盤をモダナイズ: データベースからインテリジェンスへ

従来の Oracle と DB2 のシステムからの Google Cloud データベースへの移行は、パフォーマンスの問題を解決しただけでなく、次のステップに向けた強固な基盤を築くことにもなりました。その信頼性とスケーラビリティにより、生成 AI をサプライチェーンに直接組み込むことも可能になりました。

当社のエージェント型 AI スイートには、店舗や物流センターの業務全体でリアルタイムの意思決定を調整する事前構築済みエージェント（Intelligent Store Manager や Labor Optimizer など）が含まれています。また、Manhattan Agent Foundry を利用すれば、ローコード環境を使用してカスタム AI エージェントを構築することも可能です。この基盤は、リアルタイムのログ分析、デベロッパー向けコード支援、シナリオシミュレーションといったユースケースを通じて、社内の効率化も支えています。

かつてないスピード、規模、運用効率を実践

このプラットフォームのモダナイゼーションの効果は、小売業者にもすぐに現れました。それは、目に見えるスピードと信頼性です。

現在、Manhattan Active は、Cloud SQL と BigQuery を活用して驚異的な数の API 呼び出しに日々対応しており、平均応答時間は 150 ミリ秒未満を実現しています。このスピードにより、数万の店舗と物流センターにわたって数十万人の月間アクティブユーザーをサポートしており、重要な場面でのリアルタイムな意思決定を可能にしています。

運用面では、プラットフォームの弾力性と効率性が向上しました。このシステムは、1 日に数十万件のスケーリングイベントを自動的に処理するため、ピーク時のトラフィック急増時でも一貫したパフォーマンスを維持できます。高額なオーバープロビジョニングを行う必要はありません。また、Query Insights などのデータベースオブザーバビリティツールにより、エンジニアは状況を明確に把握できるため、データベースのパッチ適用や事後対応型のトラブルシューティングに費やす時間が減り、機能開発やパフォーマンスチューニングにより多くの時間を割けるようになりました。

現在、Manhattan Associates では、レジリエンスが組み込みの機能となっています。これは、当社のソフトウェアを利用する小売業者にとって、よりスマートかつ迅速で、将来のあらゆる事態に備えたサプライチェーンの実現へとつながるものです。

詳細

Cloud SQL でビジネスを変革する方法をご確認ください。今すぐ無料トライアルを開始できます。
IDC レポートをダウンロードして、Cloud SQL への移行によってコストの削減、アジリティの向上、デプロイの高速化を実現する方法をご確認ください。
Ford と Yahoo が Cloud SQL でモダナイズして、高いパフォーマンスを実現し、費用を削減した方法をご確認ください。

- Manhattan Associates、シニアディレクター、Narayana Reddy Kothapu 氏

- Manhattan Associates、テクニカルディレクター、Rajkumar Ramani 氏

読み取りのスケーラビリティを合理化する Cloud SQL の自動スケーリングを備えた読み取りプール

Wed, 01 Apr 2026 02:10:00 +0000

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

データベースから頻繁に読み取りを行うアプリケーションの一般的なパターンは、読み取り負荷の高いワークロードをリードレプリカにオフロードすることです。これにより、アプリケーションをスケールしても、プライマリデータベースインスタンスでの重要な書き込みオペレーションに影響が及ぶことはありません。しかし、このような読み取り負荷の高いワークロードでは、単一のリードレプリカの容量を簡単に超えてしまう可能性があります。デベロッパーはロードバランサの背後に複数のレプリカを手動で実装できますが、この方法は複雑で、保守とスケーリングが困難です。

Cloud SQL は、MySQL と PostgreSQL の読み取りプールを使用して、読み取りをスケールするための簡素化されたフルマネージドソリューションを提供します。この機能を使用すると、単一の読み取りエンドポイントからアクセスできる複数のリードレプリカをプロビジョニングできるため、アプリケーションを変更することなく、リードレプリカを簡単に追加および削除できます。効率をさらに向上させるために、Google は最近、Cloud SQL の読み取りプールに自動スケーリングを導入しました。これにより、リアルタイムのアプリケーションニーズに基づいて読み取り機能が動的に調整されます。自動スケーリングを備えた読み取りプールは、 Cloud SQL Enterprise Plus エディションで一般提供されています。詳しくは、MySQL と PostgreSQL のドキュメントとリリースノートをご覧ください。

読み取りプールを使用する理由

プライマリインスタンスからレプリケートする読み取りプールを作成すると、Cloud SQL は 読み取りプールノードと呼ばれる複数のリードレプリカを自動的にプロビジョニングし、クエリをノードにラウンドロビン方式でディスパッチする単一のロードバランサ（読み取りエンドポイント）を作成します。1 つのプールには 1～20 個のノードを含めることができます。

読み取りプールは単一のエンティティとして管理されるため、運用上の負担が軽減されます。プールは同種のノードのセットを表します。データベースフラグ、VM タイプ、その他のパラメータの更新などの構成変更を行うと、その変更はプール内のすべてのノードに自動的に適用されます。また、ワークロードの変化に応じて、プールからノードの追加や削除ができるため、いつでもスケールアウトとスケールインが可能です。すべてのクエリは読み取りエンドポイントのロードバランサを通過するため、プール内のノードが更新、追加、削除されても、アプリケーションを再構成する必要はありません。

読み取りプールの自動スケーリングでスケーリングが容易に

読み取りプールは、ワークロードが変動するシナリオで真価を発揮します。Cloud SQL の読み取りプール向けの自動スケーリングの一般提供が開始されたことで、こうした変動の管理がさらに簡単になりました。

読み取りプールの自動スケーリングの主なメリットは以下のとおりです。

トラフィックの急増に対する自動管理: データベース接続または CPU 使用率に基づいてプールが最大 20 個のノードまで動的にスケールアップされるため、需要がピークに達してもアプリケーションの応答性を維持できます。
オペレーションの簡素化: 自動スケーリングは単一の読み取りエンドポイントと統合されているため、基盤となるノードが調整されても、アプリケーションは同じアドレスに接続されたままになります。
費用の最適化: トラフィックが少ない期間は自動的なスケールインによって、実際に使用したリソースに対してのみ料金が発生するため、オーバープロビジョニングによって発生する費用を回避できます。

Cloud SQL が読み取りプールで可用性を向上させる仕組み

ミッションクリティカルな信頼性を実現するように設計された Cloud SQL の読み取りプールは、可用性が高い読み取りワークロードの基盤となります。ノードを 2 つ以上維持することで、読み取りプールは 99.99% の可用性 SLA によってサポートされ、これにはメンテナンスのダウンタイムも含まれます。これを実現するために、Cloud SQL は次のように環境をインテリジェントに管理します。

読み取りプールにノードを追加する際、既存の接続は、既存のノードで中断することなく続行されます。新しい接続は新たに追加されたノードに割り当てられる場合があります。既存の接続が処理を完了すると、負荷はすべてのノード間で均等に分散されるようになります。
2 つ以上のノードを含む読み取りプールの場合、VM タイプやデータベースフラグを変更したり、その他の大半の構成更新を実行したりすると、読み取りプールはダウンタイムがほぼゼロで更新されます。
他の Cloud SQL インスタンスと同様に、Cloud SQL は読み取りプールインスタンスの基盤となるハードウェアの問題を自動的に検出して修復します。異常が検出されたノードは、ロードバランサのローテーションから削除され、それを置き換えるための新しいノードが作成されます。

自動スケーリングを備えた読み取りプールの有効化と使用

読み取りプールは、ワークロードが大きく変動する環境で優れた性能を発揮します。Cloud SQL の自動スケーリングでは、CPU 使用率やデータベース接続などの主要な指標の目標値を設定すると同時に、ノードの最小数と最大数を定義できます。

小売業界は良い例になります。トラフィックが、日々のサイクル、季節の変化、期間限定セールなどに基づいてよく変動するからです。こうしたピーク時に動的にスケールアウトし、需要が落ち着いたらスケールインすることで、オーバープロビジョニングされた環境のオーバーヘッドなしに、優れたカスタマーエクスペリエンスを提供できます。

Enterprise Plus エディションのインスタンスをすでに作成している場合は、そのインスタンスからレプリケートする読み取りプールを作成できます。次のコマンドは、2 つのノードを含む読み取りプールを作成し、自動スケーリングを有効にします。自動スケーリングは、CPU 使用率を 60% 前後で維持しながら、ノードを 2～10 個の間でスケールするように構成されています。

code_block: <ListValue: [StructValue([('code', 'gcloud sql instances create myautoscaledreadpool \\\r\n --tier=db-perf-optimized-N-4 --edition=ENTERPRISE_PLUS \\\r\n --instance-type=READ_POOL_INSTANCE \\\r\n --master-instance-name=myprimary \\\r\n --region=us-west1 \\\r\n --node-count=2 \\\r\n --auto-scale-enabled \\\r\n --auto-scale-min-node-count=2 \\\r\n --auto-scale-max-node-count=10 \\\r\n --auto-scale-target-metrics=AVERAGE_CPU_UTILIZATION=0.60'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50986d4940>)])]>

読み取りエンドポイントの IP アドレスは、Google Cloud コンソールでインスタンスを確認するか、gcloud CLI を使用して取得できます。この IP アドレスは、プールの存続期間中は変更されません。

既存の読み取りプールがある場合は、簡単に自動スケーリングを有効にできます。

code_block: <ListValue: [StructValue([('code', 'gcloud sql instances patch myreadpool \\\r\n --auto-scale-enabled \\\r\n --auto-scale-min-node-count=2 \\\r\n --auto-scale-max-node-count=10 \\\r\n --auto-scale-target-metrics=AVERAGE_DB_CONNECTIONS=100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50986d46a0>)])]>

このコマンドは、ノードが 2～10 個の間で自動的にスケールされるように myreadpool を構成します。その際、ノードあたりの平均データベース接続数が最大 100 になるように調整されます。

自動スケーリングは、変動するワークロードのほとんどに推奨されますが、必要に応じてノード数を直接更新することで、読み取りプールを手動でスケールすることもできます。

code_block: <ListValue: [StructValue([('code', '# Manually scale out to 4 nodes\r\ngcloud sql instances patch myreadpool --node-count=4\r\n\r\n# Manually scale back in to 2 nodes\r\ngcloud sql instances patch myreadpool --node-count=2'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50986d4820>)])]>

使ってみる

新しい自動スケーリング機能を備えた読み取りプールを使用することで、多数の読み取りレプリカの管理に伴う面倒な作業を回避できるほか、アプリケーションに必要な読み取り容量を必要に応じて提供でき、過剰な費用を回避できます。今すぐ始めるには、以下のリソースをご覧ください。

読み取りプールに関する Cloud SQL のドキュメント

読み取りプールについて（MySQL、PostgreSQL）
読み取りプールの作成と管理（MySQL、PostgreSQL）: gcloud CLI、Terraform、REST API のコマンド例を含む
読み取りプールの自動スケーリング（MySQL、PostgreSQL）: gcloud CLI、Terraform、REST API のコマンド例を含む

新しい Cloud SQL の無料トライアルにご登録ください。これは、新規および既存の Google Cloud ユーザーの皆様を対象とした、Cloud SQL（PostgreSQL および MySQL）が提供するプレミアムなエンタープライズグレードの機能をご利用いただくことを目的とした 30 日間の専用プログラムです。

- ソフトウェアエンジニア、Phil Sung

- プロダクトマネージャー、Shahzeb Farrukh

Memorystore for Valkey 9.0 の一般提供を開始: 次世代のキャッシュ保存

Thu, 26 Mar 2026 03:30:00 +0000

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

高スループット、低レイテンシのアプリケーション構築を目指すバックエンドデベロッパーやアーキテクトの間で、Valkey の利用が進んでいます。Valkey は、オープンソースで高性能な Key-Value データストアであり、キャッシュ保存やメッセージキューなどのさまざまなワークロードに対応します。Google Cloud では、Google Cloud Memorystore の一部としてValkey のフルマネージドバージョンを提供していますが、このたび、Valkey 9.0 の一般提供（GA）を開始しましたのでお知らせいたします。Valkey 9.0 は、パフォーマンスが大幅に向上しているほか、デベロッパー向けの優れた新機能を提供しています。

プレビュー期間中は、最高レベルのパフォーマンスを求めるお客様から大きな関心が寄せられ、多数の方にご利用いただきました。スケールとレイテンシの限界に挑む各社が、特に要求の厳しいワークロードで Valkey 9.0 の真価を試しています。

「Snap のインフラストラクチャにとって、高パフォーマンスのキャッシュレイヤは非常に重要です。Google Cloud Memorystore で Valkey 9.0 の一般提供が開始されたことを大変嬉しく思います。SIMD 最適化などの新しいアーキテクチャ強化によりパフォーマンスが大幅に向上し、スループットとレイテンシに反映されています。オープンスタンダードを基盤としたマネージドサービスを利用することで、キャッシュワークロードのデプロイおよび管理方法において貴重な柔軟性を得ることができています。」- Snap、プリンシパルソフトウェアエンジニア、Ovais Khan 氏

スピードと柔軟性に対する飽くなきニーズは、ソーシャルネットワークのインフラストラクチャに限った話ではありません。リアルタイムのトランザクション処理および信頼性が必要不可欠な金融業界でも、同様のニーズが広がっています。

「金融サービス業界では、ミリ秒単位の時間が重要であり、データの信頼性が最優先事項です。当社は、インドの大手銀行向けの UPI Acquirer Switch （統一決済処理機関用スイッチ）の重要な基盤である GPay スタックで、Google Cloud の Memorystore for Valkey を活用しています。これにより、極めて低いレイテンシかつ高スループットでトランザクションデータを処理することが可能となっています。

Valkey 9.0 の一般提供が開始されたことを大変嬉しく思います。パイプラインメモリのプリフェッチなどのパフォーマンス向上に加えて、真のオープンソースソリューションをフルマネージドで利用できることから、あらゆるお客様にサービスを安全に提供するために必要なスケールと信頼性を確保できます。」- Juspay、UPI 責任者、Arun Ramprasadh 氏

また、メディアおよびエンターテイメント業界は、膨大な数の視聴者にシームレスなエクスペリエンスを提供するのが仕事ですが、そのために、トラフィックの急増に即座に対応できるようなキャッシュレイヤを必要としています。

「Google Cloud Memorystore で Valkey 9.0 のプレビュー版を使用しましたが、驚くほどのパフォーマンスと安定性を実感しました。ライブストリーミングでは、レイテンシを最小限に抑え、スループットを最大化することが求められます。Valkey 9.0 のアーキテクチャ強化により、キャッシュレイヤをより効率的にスケールして、大規模イベント中のトラフィック急増に対処できるようになりました。フルマネージドのオープンソースソリューションのおかげで、視聴者にシームレスな視聴体験を提供することが可能となっています。」- Fubo、プラットフォームエンジニアリングマネージャー、Kevin Anthony 氏

スケーリング時のパフォーマンス: 妥協のないスピード

Valkey 9.0 は、素のスピード向上を追求した設計となっています。Valkey 8.0 で IO スレッドアーキテクチャが強化されましたが、それを基盤としながら、マルチコアの VM でスループットを大幅に向上し、低レイテンシを実現しています。Valkey のブログの Valkey 9.0 公式リリース発表にあるように、このパフォーマンスの向上は、以下に示すアーキテクチャ強化によって実現されています。

パイプラインメモリのプリフェッチ: この最適化により、パイプライン処理中のメモリアクセス効率が向上し、スループットが最大 40% 高まります。
コピー不要のレスポンス: 大規模なリクエストにおいて内部メモリのコピーを回避することで、スループットが最大 20% 向上します。
SIMD の最適化: Valkey 9.0 では、BITCOUNT および HyperLogLog オペレーションに SIMD を活用しており、これらの一般的タスクのスループットが最大 200% 向上しています。（注: 上記の数値はオープンソースのベンチマークに基づいています。実際の数値は、ワークロードの種類によって異なります。）

スループットのメカニズム: パイプライン処理

Valkey のレイテンシは、ネットワークのラウンドトリップ時間（RTT）に大きく依存します。アプリケーションが次のリクエストを開始する前に各レスポンスを待機する場合、合計スループットには、このラウンドトリップレイテンシが反映されます。パイプライン処理では、レイテンシとスループットを切り分けることでこの問題に対処しています。具体的には、1 つの接続において即時レスポンスを待つことなく複数のリクエストを送信できるようにしています。

ほとんどの Valkey クライアントはパイプライン処理をネイティブにサポートしています。たとえば、valkey-go のように、デベロッパーに対して「自動パイプライン処理」機能を提供し、最適化を透過的に処理するものなどがあります。

Valkey 8.0 では、バックグラウンドスレッドのメモリプリフェッチにより、パフォーマンスが大幅に向上しました。具体的には、メインスレッドがデータを要求する前に、DRAM から CPU キャッシュにデータを移動するようハードウェアに指示します。この最適化により、メインスレッドは最小限の遅延でオペレーションを実行できるようになりましたが、それでもまだ制約がありました。パイプライントラフィックにおいてプリフェッチの恩恵を受けるのは最初のオペレーションのみであり、後続のリクエストでは CPU キャッシュミスによるボトルネックが生じていたのです。

Valkey 9.0 では、Valkey 8.0 のアーキテクチャを基盤としてコマンド処理が再設計され、パイプラインワークロード向けに最適化されました。具体的には、最初のオペレーションに対してのみキーをプリフェッチするのではなく、パイプライン内のすべてのオペレーションを同時にプリフェッチします。

CPU キャッシュは通常、DRAM アクセスよりも数十倍高速であるため、一見するとわずかな改善でも、その影響は非常に大きくなります。Valkey 9.0 では、メインスレッドの CPU キャッシュヒットを最大化することで、全体のスループットを最大 40% 向上させています。

開発者からの新たな要望に対応

Valkey 9.0 では、パフォーマンスが向上しただけではありません。コミュニティからの多くの要望に応えて、アプリケーションロジックとデータマネジメントを簡素化する強力な新しいコマンドが導入されています。

ハッシュフィールドの有効期限を個別に設定

インメモリストアに対してよく寄せられる要望として、キー全体ではなくハッシュ内の個々のフィールドに有効期限を設定したいというものがありました。Valkey 9.0 ではこの機能が導入され、データライフサイクル管理の柔軟性が大幅に向上しました。

実際の例: 認証トークン、一時的な設定、長期的な設定を保存する「ユーザーセッション」ハッシュを管理する場合について考えてみましょう。HEXPIRE を使えば、temporary_session_token フィールドに 30 分の有効期限を設定し、残りのユーザープロファイルデータをそのまま保持するといったことが可能です。つまり、フィールドごとに異なる有効期間（TTL）を設定するという目的のためだけに、1 つの論理オブジェクトを複数のキーに分割する必要がなくなります。
新しいコマンド: このリリースでは、HEXPIRE、HEXPIREAT、HEXPIRETIME、HPERSIST、HTTL などの各種コマンドが完全サポートされています。

地理空間の詳細指定、条件付きロジック

地理空間インデックスに対するポリゴン検索: ポリゴンを指定して位置情報をクエリできるようになりました。たとえば、物流アプリケーションで、配送ゾーンを非円形で厳密に定義して（特定のエリアや工業団地など）、現在その境界内にあるすべてのアクティブなアセットをクエリするといったことができます。

この機能を使用するには、地理空間インデックスに座標を追加するだけです。

code_block: <ListValue: [StructValue([('code', '> GEOADD gcp:regions -121.1851 45.5946 "us-west1 (Oregon)" -118.2437 34.0522 "us-west2 (Los Angeles)" -111.8910 40.7608 "us-west3 (Salt Lake City)" -115.1398 36.1699 "us-west4 (Las Vegas)" -95.8608 41.2619 "us-central1 (Iowa)" -77.4874 39.0438 "us-east4 (N. Virginia)"\r\n\r\n(integer) 6'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5098356fa0>)])]>

次に、GEOSEARCH で BYPOLYGON オプションを指定します。

code_block: <ListValue: [StructValue([('code', '> GEOSEARCH gcp:regions BYPOLYGON 5 -125.00 49.00 -125.00 32.00 -114.00 32.00 -109.00 42.00 -116.00 49.00\r\n\r\n1) "us-west2 (Los Angeles)"\r\n2) "us-west4 (Las Vegas)"\r\n3) "us-west3 (Salt Lake City)"\r\n4) "us-west1 (Oregon)"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5098356820>)])]>

条件付き削除（DELIFEQ）: このコマンドは、キーの現在の値が指定値と一致する場合にのみ、キーを削除します。これは分散ロックにおいて画期的な機能です。このコマンドにより、ワーカーは、ロックの取得時に使った一意のトークンをまだ保持している場合にのみ、安全にロックを解放できます。こうすることで、すでに期限切れとなって別のプロセスに再割り当てされたロックを誤って削除することがなくなります。以前は、このような操作は Lua スクリプトを使ってのみ可能でした。

DELIFEQ の便利さを理解するために、2 つのプロセス（プロセス A とプロセス B）がロックへの排他的アクセスを必要とする場合を考えてみましょう。

プロセス A は、次のコードを実行して、分散ロックを 30 秒間取得します。

code_block: <ListValue: [StructValue([('code', '>SET distributed_lock process_A NX PX 30000\r\nOK'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f50983564f0>)])]>

プロセス B が同じことを試みても、NX オプションを指定しているため、成功しません。

code_block: <ListValue: [StructValue([('code', '> SET distributed_lock process_B NX PX 30000\r\n(nil)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5098356af0>)])]>

プロセス A が終了したら、新しい DELIFEQ コマンドを使用して安全にロックを解除できます。

code_block: <ListValue: [StructValue([('code', '> DELIFEQ distributed_lock process_A\r\n(integer) 1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5098356a30>)])]>

これで、プロセス B はロックを取得できます。

code_block: <ListValue: [StructValue([('code', '> SET distributed_lock process_B NX PX 30000\r\nOK'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5098356850>)])]>

新しいフィルタオプション	説明
NAME <名前>, NOT-NAME <名前>	指定した名前のクライアントを含める、または、除外する。
IDLE <秒>	指定した秒数以上アイドル状態になっているクライアントのみを含める。
FLAGS <フラグ>, NOT-FLAGS <フラグ>	さまざまなフラグ（プライマリ接続、レプリカ接続など）に基づいてクライアントを含める、または、除外する。
LIB-NAME <名前>, LIB-VER <バージョン>, NOT-LIB-NAME <名前>, NOT-LIB-VER <バージョン>	指定したライブラリバージョンまたはライブラリ名に一致するクライアントを含める、または、除外する（たとえば、valkey-py のバージョン 6 のみを含める）。
DB <データベース>、NOT-DB <データベース>	現在選択されているデータベースに基づいて、クライアントを含める、または、除外する。
CAPA <フラグ>、NOT-CAPA <フラグ>	クライアントが宣言した機能（リダイレクトをサポートするかどうかなど）に基づいて、クライアントを含める、または、除外する。
IP <ip>, NOT-IP <ip>	クライアントを IP アドレスに基づいて含める、または、除外する。
NOT-ID <id>, NOT-TYPE <タイプ>, NOT-ADDR <アドレス>, NOT-LADDR <ローカルアドレス>, NOT-USER <ユーザー名>	既存のフィルタの多くが、除外オプションに対応。

拡張された CLIENT LIST 機能は、Memorystore for Valkey でそのまま使用できます。

エンタープライズ対応の機能

今回のリリースでは、クラスタ環境のデータベース構成も導入されています。これにより、Blue/Green キャッシュパターンなどの複雑なユースケースにも容易に対応できるようになります。複数のサービスで番号付きデータベースを利用できるため、データを効率的にパーティショニングして、論理的に名前空間を分けることが可能となります。クラスタモードで、キースペースの名前空間に最大 100 個の番号付きデータベースを構成できます。

構成例: Google Cloud CLI でインスタンスを作成するときに、データベースの数を指定できます。

code_block: <ListValue: [StructValue([('code', 'gloud memorystore instances create my-valkey-instance \\\r\n--engine-version=VALKEY_9_0 \\\r\n--replica-count=1 \\\r\n--shard-count 10 \\\r\n--engine-configs=cluster-databases=100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5098356280>)])]>

クラスタ環境のデータベース構成では、単一のスケーラブルなクラスタインスタンス内で、さまざまなサービスや環境に対してデータを効率的にパーティショニングできます。これにより、クラスタの大規模なスケールを活用しながら、論理的組織に基づき複数のデータベースを使用することが可能となります。この機能を使えば、現在、クラスタ化していないレガシーの Redis インスタンスの制約を受けているお客様の多くが、複雑なアプリケーションの再設計を行うことなく、マルチデータベース構造に依存するワークロードを簡単にモダナイズできるようになります。

シームレスなアップグレード

Memorystore for Valkey をすでにご利用のお客様は、ダウンタイムなしの簡単なインプレースアップグレードで、これらの新機能をすぐに利用できます。このたび、クラスタが有効または無効の両方のインスタンスで Valkey 9.0 が使用可能になったことにより、最新エンジンへのスムーズな移行が実現します。

今後の展望

Valkey 9.0 の一般提供は、オープンソースデータベースの進化における重要なマイルストーンです。しかし、この取り組みはまだ始まったばかりです。Google はすでに、次のイノベーションの波に向けて鋭意取り組み中であり、Google Cloud Next 2026 で Valkey エコシステムのさらなる強化について発表する予定です。

さっそく構築を始める

Memorystore for Valkey 9.0 のパワーを体験するには、実際に試してみるのが一番です。まずはドキュメントをご覧になるか、さっそく初めての Valkey インスタンスをデプロイしてみましょう。セルフマネージドの Redis に囚われることなく、Memorystore for Valkey のシンプルさとスピードを今すぐ体験し、アプリケーションにご活用ください。そうすることで、真に重要なイノベーションや、ビジネスにおける重要アプリケーションの開発に専念することが可能となります。

- Google、シニアプロダクトマネージャー、Ankit Sud

- ソフトウェアエンジニア、Jacob Murphy

Google Cloud のお客様が構築した優れたソリューション（2 月版）: Team USA のテック、通信会社のデータ刷新、ゴールデンステートの「G.O.A.T.T.」

Tue, 17 Mar 2026 01:30:00 +0000

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

AI とクラウドテクノロジーは、世界中のあらゆる業界のあらゆる分野を変革しています。お客様がいなければ、Google Cloud は存在しなかったでしょう。お客様こそが Google のプラットフォームで未来を築いている存在だからです。このシリーズでは、ビジネスを根本から変え、業界を形作り、新しいカテゴリを生み出しているエキサイティングなプロジェクトの数々を取り上げます。

今回の最新号では、Google Cloud がスキー＆スノーボード米国代表向けに AI 搭載のトレーニングツールをどのように構築したのかをはじめ、Vodafone と Fastweb の新しいデータ活用の取り組み、John Lewis Partnership のデベロッパープラットフォームの評価、ゴールデンステートウォリアーズの AI 活用ハンドブック、Hackensack Meridian Health における健全で安定したネットワーク運用、そして Ab Initio が AI 用のデータにより良いコンテキストをもたらす取り組みまで幅広く取り上げます。

来年改めてチェックして、さらに多くの業界のリーダーや注目のスタートアップが Google Cloud テクノロジーをどのように活用しているかをご確認ください。また、まだご覧になっていない場合は、Google のお客様による 1,001 件の実際の生成 AI ユースケースのリストをご確認ください。

AI で米国代表チームをさらに強く

対象: Google Cloud は、今年 2 月にイタリアで開催される冬季オリンピックに向けて、スキー＆スノーボード米国代表チームのための AI 搭載トレーニングツールの開発に取り組みました。

取り組み: スノーボーダーの Maddie Mastro 選手やフリースキーヤーの Alex Hall 選手など、米国代表チームのアスリートたちが競技で優位に立てるようにするとともに、オリンピックに向けて彼らの大胆なトリックに潜む物理法則を解き明かすため、Google Cloud は業界初となる AI 搭載の動画分析プラットフォームを構築しました。このプラットフォームでは、空間知能に関する研究を基に Google DeepMind が開発した独自モデルが活用されています。このツールの目的は、スキー＆スノーボード米国代表チームの選手たちが、トリックの完成度を高めると同時に自信を深められるよう支援することです。

意義: Google Cloud ツールを使用すると、リフトで山頂に戻るまでの間に、各技の完全な分析、過去の取り組みとの比較、次回改善できる点に関する膨大なメモやヒントを確認できます。このツールを開発した主な理由はアスリートのパフォーマンス向上でしたが、安全性の確保もそれに次ぐ重要な目的でした。身体の動きをより正確に把握できるようになれば、事故やけがの予防にもつながります。240 人の選手を擁するチームでは、数十人がけがで離脱する可能性もあるため、これは極めて重要です。

コメント:「以前は、友人に電話して『5 年前のあのトリックの映像、持ってる？』と聞き、ビデオを行き来しながら比較していました。でもこのツールなら違います。過去の滑走を取り込み、今の分析に生かすことができます。スロー再生して、その瞬間に頭や体がどの位置にあるのかを正確に確認できるのです。重要なのは、そうした細かな動きをリアルタイムで見て理解できることです。」– 米国オリンピック代表 5 回参加者 / 金メダル 3 回受賞者、Shaun White 氏

Google Cloud × Team USA - 技術の舞台裏

Fastweb + Vodafone: データワークフローを再構築

対象: 2025 年に Swisscom が Vodafone Italy を買収したことを受け、欧州の通信業界をリードする両社は、顧客へのサービス提供のあり方を見直し、モバイル、ブロードバンド、デジタルの各チャネルで、タイムリーかつパーソナライズされた体験を届けたいと考えました。

取り組み: 両社はすでに BigQuery を使って顧客データワークフローのモダナイズを進めていましたが、エコシステムを統合したことで、既存構成の限界が見えてきました。そこで、すべてのチャネルが正確な顧客データにリアルタイムでアクセスできるよう、Spanner をサービスおよびガバナンス層として導入しました。これにより、低レイテンシでの参照、水平方向のスケール、高可用性を実現し、運用負荷をほぼゼロにできるフルマネージド環境を整備しました。また、Gemini を活用し、コードから直接分かりやすいドキュメントを生成することで、手作業にかかっていた時間を大幅に削減しています。

意義: Spanner Graph を利用することで、プラットフォームが実際にどう動いているかに即した形で、データリネージを可視化できるようになりました。具体的には、どのテーブルがどのジョブを動かしているのか、変換処理がどのように連鎖するのか、依存関係がどこにあるのかといった点を把握できるようになっています。コールセンターでは、より完全で最新の顧客情報を確認できるようになり、デジタルチャネルでは、カスタムインテグレーションなしでも整合性のあるデータを利用できるようになりました。また、パートナーは、Apigee を通じて必要な情報に低レイテンシでアクセスできるようになりました。

Fastweb + Vodafone のコメント:「Google Cloud サービスで Customer 360 プラットフォームを再構築したことで、Fastweb + Vodafone の業務の仕組みは大きく変わりました。ワークフローのモニタリングが簡素化され、パイプラインがより効率的になり、リアルタイムのサービス提供が一般的になりました。」– Fastweb + Vodafone、IT AI 導入およびプラットフォームエンジニアリングリード、 Vincenzo Forciniti 氏

John Lewis がデベロッパープラットフォームの価値を測定

対象: John Lewis Partnership は、John Lewis の百貨店と Waitrose のスーパーマーケットを展開する英国の大手小売企業です。同社はデジタルトランスフォーメーションを推進するため、John Lewis Digital Platform（JLDP）を構築し、johnlewis.com 向けに高品質なソフトウェアを開発する数十のプロダクトチームを支えています。

取り組み: John Lewis は、単純な利用状況の指標にとどまらず、プラットフォームが生み出す本当の価値を測るための、より高度で多段階の手法を整備しました。当初は「オンボーディングに要する時間」のようなスピード重視の指標で測っていましたが、その後は DORA 指標に加え、DX プラットフォームを通じたエンジニアの主観的なフィードバックも組み合わせた包括的なモデルへと移行しました。さらに、35 以上の健全性指標（Kubernetes のベストプラクティス、セキュリティ、運用準備状況など）を小規模な自動ジョブで継続的にモニタリングする独自の「Technical Health（技術的健全性）」機能も導入しています。これにより、各チームは「信号機」を見るかのようにサービスの状態をリアルタイムで把握できます。

意義: 活動量ではなく価値に焦点を当てたことで、必須だから使うツールであることにとどまらず、開発者の手間やつまずきを実際に減らしていることを確認できました。また、自動化された Technical Health チェックにより、プロダクトチームは技術的負債やセキュリティ上の脆弱性を先回りして管理できるようになりました。その結果、中央の運用チームが個々のサービス運用に集中する必要が減り、インシデント解決（MTTR）の短縮、障害の減少、そして大幅なコスト削減につながっています。

コメント:「測定は、到達点ではなく旅の過程です。まずは関係者にとって意味のある指標を測ることから始めつつ、プラットフォームの進化に合わせて柔軟に見直していく準備もしておくべきです。プラットフォームの実現可能性を示す段階で重要だったことが、数年後に機能が成熟した段階でも同じように重要とは限りません。」– John Lewis Partnership、プリンシパルプラットフォームエンジニア、 Alex Moss 氏

Hackensack Meridian Health、VPC Flow Logs でネットワーク移行のリスクを低減

対象: Hackensack Meridian Health（HMH）は、ニュージャージー州最大の医療機関病院システムを擁する大手の非営利医療機関です。病院、救急医療センター、診療所からなる広大なネットワークを運用しているため、システムの信頼性は同組織にとって中核となる価値です。

取り組み: 新しい Google Cloud のネットワーク設計へ大規模に移行する準備として、HMH は VPC Flow Logs と Flow Analyzer を活用し、ハイブリッド環境のトラフィックが「ブラックボックス」になってしまう問題を解消しました。具体的には、Cloud Interconnect の VLAN アタッチメントでログを有効化し、送信元 / 宛先 IP、ポート、プロトコルなど、粒度の細かいテレメトリーを取得しました。その後、このデータをエクスポートし、「誰が誰と通信しているか」を可視化したマップを作成しました。これにより、オンプレミスのデータセンターと、特定の Google Cloud リージョン、VPC、アプリケーションとの間にある重要なトラフィックパターンを特定できるようになりました。

意義: 医療の現場では、ネットワークのわずかな途切れでさえ、重大な影響につながりかねません。トラフィックを事前にマッピングしておくことで、Hackensack Meridian Health は、カットオーバーのどの局面でリスクが最も高まるのかを正確に特定できました。この準備により、移行時の問題をわずか 3 分で検知し、5 分以内に解決できました。従来であれば数時間かかっていた可能性のある作業です。さらに移行にとどまらず、この水準の可視化によって、ハイブリッドインフラ全体にわたるキャパシティ計画、コスト配賦、セキュリティコンプライアンスをより適切に管理できるようになります。

コメント:「相互接続のトラフィックはこれまでブラックボックスのようなものでした。VPC Flow Logs を有効にして Flow Analyzer にフィードすることにより、求めていたマップをようやく入手できるようになりました。ルートを変更する前に、このような重要なトラフィックフローを特定することが、移行全体のリスクを軽減するうえでの鍵でした。」— Hackensack Meridian Health、クラウドエンジニアリングマネージャー、Randall Brokaw 氏

ゴールデンステートウォリアーズの AI 活用バックオフィス

対象: ゴールデンステートウォリアーズは、NBA の中でも近年特に成功を収めているフランチャイズの一つです。そしてコート上の勝利を陰で支えているのが、組織の「G.O.A.T.T.」とも呼べる専門の運用チームです。「G.O.A.T.T.（Greatest of All-Time Technologies）」は、データと AI を活用したプラットフォームで、試合中のインサイト、トレード判断、ファン体験の向上を後押しします。

取り組み: ウォリアーズは、Google Cloud 上に社内の「デジタル頭脳」を構築し、これまでの「勘と経験」に頼る文化から、「分析を起点とする」戦略へと舵を切りました。BigQuery と Gemini を活用することで、試合前のスカウティングレポート作成など、以前は数時間かかっていた複雑な業務フローを自動化できるようになりました。さらに ML を用いて、個々の選手の単純な成績よりも「チームへの適合性」を重視したトレードシミュレーションを数千回実行しています。加えて、コンピュータビジョンにより、NBA におけるすべてのシュートについて「ショットの質」を追跡しています。ビジネス面でも、Discovery API を使ったコンテンツ推薦エンジンを構築し、世界中のファンに対してパーソナライズされたデジタル体験を提供しています。

意義: AI を軸にしたこのアプローチによって、経営陣が検討すべき選択肢をあらかじめ絞り込めるようになり、人間の専門性を実現可能性の高い案に集中させられます。データ処理という「科学」の部分を自動化することで、コーチやスカウトは、対面での指導や戦略立案、選手育成といった「職人技」により多くの時間を割けるようになります。この統合は、3 ポイント革命のようなコート上の戦術に影響を与えただけではありません。業務面でも効率が向上し、従業員はトップダウンの指示を待つのではなく、AI によるアイデアを自発的に IT チームへ持ち込むようになりました。

コメント:「人間か機械のどちらかがすべての意思決定を担うような段階に到達することはありません。大事なのは、直感とデータが同じ結論に行き着くちょうどよい中間点を見つけることです。データは、具体的な選択肢を評価し始める前の段階で、意思決定ツリーを絞り込むのに役立ちます。」— ゴールデンステートウォリアーズ、消費者向け製品および新興テクノロジー担当シニアディレクター、 Nick Manning 氏

Ab Initio がエージェント型 AI 時代に向けて企業データ活用を推進

対象: Ab Initio は、大量データの統合とガバナンスを得意とするエンタープライズ向けソフトウェア企業です。同社のプラットフォームは、ハイブリッドおよびマルチクラウド環境にまたがる複雑なデータライフサイクルを管理するため、大規模組織から信頼されています。

取り組み: AI エージェントが正確なデータに基づいて動けるようにする（グラウンディングする）という課題を解決するため、Ab Initio は Google Cloud と連携し、自社のデータファブリックを BigQuery、Dataplex Universal Catalog、Gemini と統合しました。さらに、メインフレーム、COBOL、SAS などのレガシー環境と、最新のクラウド環境の間をつなぐ、500 以上のメタデータおよびデータコネクタ群も提供しています。この統合により、フィールド（項目）単位でエンドツーエンドのデータリネージを把握できるようになり、Gemini はデータの所在に左右されることなく、十分に文書化された「AI ですぐ使える」データにアクセスできるようになります。

意義: AI エージェントの有効性は、アクセスできるデータの質と範囲に大きく左右されます。Ab Initio を「中立的なハブ」として使うことで、企業はデータそのものを移動させることなく、オンプレミスやマルチクラウドのデータを単一の統合レイヤに連携できます。その結果、Gemini が根拠に基づき、説明可能な形で推論するために必要となる、豊かな意味的コンテキスト（セマンティクス）とリネージを提供できるようになります。企業にとっては、テスト段階の AI から、監査可能でコンプライアンスにも対応し、複雑な意思決定を自動で行えるプロダクションレディなエージェント型ワークフローへより速く移行できるということです。

コメント:「エージェント型 AI には、信頼できる AI 対応のデータとメタデータが必要です。情報の出所、品質、意味を理解することは、データそのものと同じくらい重要です。Gemini はエージェントレイヤの重要なコンポーネントとして機能し、このコンテキストを使用して説明可能かつ監査可能な意思決定を行います。」— Ab Initio、開発責任者 Scott Studer 氏および Google Cloud、データガバナンス、共有、統合担当プロダクトリード、Chai Pydimukkala 氏

- Google Cloud コンテンツおよび編集担当編集長

PayPal 史上最大規模のデータ移行が生成 AI イノベーションの基盤に

Mon, 09 Mar 2026 01:30:00 +0000

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

生成 AI 時代の到来により、企業には革新的なプロダクトを生み出す前例のない機会が訪れており、それに対応するため、テクノロジーインフラの戦略的な見直しが求められています。数年前、数億人の顧客にサービスを提供するデジタルネイティブ企業である PayPal は、大きな課題に直面していました。同社は 25 年にわたりサービスと機能を拡大してきましたが、その結果、データ分析インフラは複雑化していました。さらに、規模拡大の制約や Venmo、Braintree などの企業買収の影響により、約 400 ペタバイトものデータが 12 のサイロ化されたシステムに分散していました。

成長とイノベーションで成功を重ねた結果、複雑さが増し、それが次の進化の足かせになりかねない状況でした。

金融サービス分野における次なるイノベーションの波を引き続き牽引していくために、私たち PayPal はデータ基盤のモダナイゼーションが不可欠だと判断しました。今回は、PayPal が、おそらく史上最大級のデータ移行の一つを成功させ、最終的に分析基盤を Google Cloud のエンタープライズ向けデータウェアハウスである BigQuery に移行した経緯をご紹介します。この取り組みは、事業の重点領域を拡大および推進し、絶えず変化するお客様の金融ニーズに応えていくために必要となる強固なデータ基盤を構築するうえで、大きな前進となりました。

この移行は不可欠でしたが、規模の大きさは圧倒的でした。実際、（すでに運用を終了した）Teradata システムをはじめ、いくつかの指標で見ても、これは史上最大級のデータ移行の一つだったと私たちは考えています。こうした規模の移行にふさわしく、私たちがどのようにこの移行を進めたのか、また皆さんが自社で大規模な移行に取り組む際に検討すべき点は何かについて、いくつかの示唆を共有したいと思います。

データに眠る可能性

デジタル決済の草分け的存在の一つとして、PayPal は数十億件の取引を処理し、数十年にわたる貴重なお客様インサイトを蓄積してきました。当社には、お客様や加盟店のために十分活用しきれないまま、何十年もかけて蓄積されてきた膨大なデータがあります。まさに「山」ではなく「山脈」と呼ぶべき規模です。

買収や新サービスの追加によって有用な機能は増えましたが、その一方で新たなデータ課題も生まれました。たとえば、小規模事業者がオンライン販売では PayPal を、地域での取引では Venmo を使うといったことがあります。しかし、事業全体を一元的に把握できる形で見せるには、コストも時間もかかる複雑な処理が必要でした。

データが分断されていたため、消費者一人ひとりに合わせた体験を提供しにくくなり、その結果、利用者がお金の価値を最大限に引き出せる可能性も小さくなっていました。加えて、データからより深いインサイトを得ることも難しくなっていました。

生成 AI の時代が始まるにつれ、この分断は単なる技術的な不便さでは済まなくなってきました。金融サービスにおいて AI が大きな変革をもたらし、費用対効果も大きいと見込まれる中、データが断片化したままでは、お客様が期待する高度で賢い体験を生み出す力が大きく制約されてしまうことは明らかでした。具体的には、業界をリードする不正検知モデルをさらに強化することから、競争の激しいグローバル経済で加盟店が成功できるよう最高水準のコマース基盤を提供することまで、幅広い取り組みが含まれます。

そこに到達するには、まず分散していたデータ基盤を整える必要がありました。

レガシーシステムとこれからの目標

対象範囲は非常に大規模でした。世界最大規模とされる Teradata 環境に加え、Hadoop クラスタ、Redshift、Snowflake、さらにペタバイト級の取引データを処理するさまざまなシステムを含む、複数のデータプラットフォームを統合する必要がありました。しかもこの移行は、お客様が求めるセキュリティと信頼性を損なうことなく、サービスを止めずに実行しなければなりませんでした。

テクノロジー企業として PayPal には相応の社内リソースがあるため、まずはこの課題に自前で取り組むべきかどうかを判断する必要がありました。コストと効果を比較検討した結果、将来のニーズに対応するためにオンプレミス基盤を統合し、拡張していくやり方では、費用も完了までの期間も現実的ではないと分かりました。さらに、AI のイノベーションはクラウド上で急速に進んでいました。データの力を真に活用するには、そのイノベーションが生まれている場所に身を置く必要がありました。

私たちはさまざまなデータウェアハウスソリューションを評価した結果、多くの利点を備えた BigQuery を選択しました。BigQuery は、コンピューティングとストレージが分離され、それぞれを独立してスケールできる、フルマネージドのクラウドネイティブプラットフォームです。また、私たちが必要としていた規模とパフォーマンスに対応する強力な機能を備えており、使い慣れた SQL インターフェースを利用できるため、開発者コミュニティにとっても学習のハードルが比較的低いという利点がありました。

最も重要なのは、BigQuery が AI とネイティブに統合されている点です。これにより、データ分析をシームレスかつ効率的に行えます。

統合データに向けた歩み

データパートナーとして Google Cloud を選定したのち、私たちはこの歴史的なデータ移行プロジェクトに着手しました。大げさに聞こえるかもしれません。しかし、PayPal の事業規模、展開する地域の広さ、地域ごとに異なる規制、そしてこのデータが高い機密性を持ち、文字どおり大きな価値を有することを踏まえると、この取り組みがいかに大規模で難易度の高いものだったかが見えてきます。

Google Cloud コンサルティングのパートナーや専門家の支援を受けながら、私たちは 300 ペタバイト超のデータを移行し、運用を効率化しました。同時に、全体の約 25% に相当するワークロードを廃止しました。そしてこれらを、事業運用のダウンタイムを一切発生させることなく、またお客様への影響もなく実現しました。成功につながった主な要因は、次のとおりです。

連携: 大規模な変革を実現するうえで最初のハードルは、関係者の間で共通の目標に対する認識をそろえることです。そこで私たちは、この取り組みを全社的な最優先事項と位置付けました。

調査と分析: 移行の範囲、作業量、予算見込みを定義するためには、データ、ワークロード、入出力のデータストリームについて詳細な棚卸しを行うことが不可欠です。データリネージを確立することで、さまざまなコンポーネントの起点や相互関係を追跡できるようになり、依存関係の構造を明確かつ包括的に把握できるようになりました。

戦略: 移行プロセスの基本原則を定めることも重要です。たとえば、リフト＆シフトを採用するのか、それともモダナイゼーションを進めるのかを判断すること、セキュリティ原則を定義すること、ガバナンスのガードレールを設定すること、利用状況をどのように追跡するかを決定することなどが含まれます。

実行: 可能な限りあらゆる作業を自動化し、移行の進捗を継続的に把握できるよう、リアルタイムのダッシュボードも構築しました。また、移行プロセス全体に FinOps を組み込み、利用状況とパフォーマンスを明確に可視化できるようにしました。

BigQuery で得られた成果とその先にある価値

より迅速にインサイトを得られるようになりました。データサイエンティストが用いる複雑なクエリも含め、クエリの実行速度は 2.5 倍から 10 倍に向上しました。これによりリアルタイムの分析情報が得られるようになり、PayPal は商品レコメンド、オファー、カスタマーサポートをより個別化できるようになりました。

新たな AI の土台も整いました。モデルのトレーニングに利用できるデータは、鮮度が 16 倍向上しました。AI 開発上重要な工程である特徴量エンジニアリングも、整備されたガバナンス下のクリーンなデータに即時アクセスできるようになったことで改善されています。その結果、個人および企業の双方に向けた、パーソナライズされた金融ガイダンスや予測分析の開発が加速しました。

業務の最適化も実現しました。BigQuery への移行により、データインフラのベンダーは 4 社から 1 社に集約され、運用が簡素化されるとともに複雑さも大きく軽減されました。また、プラットフォーム間で発生していたデータの重複も完全に解消されました。

BigQuery 上に構築した新しい統合データプラットフォームは、PayPal の次なるイノベーションを支える基盤となっています。これにより、エコシステム全体にわたって、より直感的でパーソナライズされた体験を提供できるようになり、生成 AI の力も最大限に活用できるようになりました。

AI を活用したイノベーションの可能性

今後、この統合データプラットフォームを基盤として、これまで実現できなかった AI を活用した体験の提供を検討しています。たとえば、次のような取り組みです。

お客様に影響が及ぶ前に潜在的な問題を検知する予測型の不正防止。
加盟店がビジネスを最適化できるよう支援するパーソナライズされた金融インサイト。
お客様一人ひとりの好みや行動パターンに合わせて最適化されるシームレスな決済体験。
より高度なリスク評価を通じた、これまで十分な金融サービスを受けられていなかったコミュニティに対する金融アクセスの拡大。

さらに、エージェント型コマースをはじめとする新たな可能性も見据えています。

AI 時代の教訓

私たちの移行は規模の面で特別な取り組みに見えるかもしれませんが、抱えている課題や目指している方向性は、決して私たちだけのものではありません。今まさに自社のデータ基盤を見直そうとしている金融サービス業界の企業はもちろん、それ以外の業界にとっても、参考になる論点は数多くあります。

まず、データがどれほど十分に活用されていないか、そしてどれほど整理されていないかを過小評価しないことです。

データを一元化し、正確性と整合性を担保できれば、AI の実験や本番投入に向けた土台が整います。データファブリックの整備に時間を投じる組織ほど、ML や生成 AI のアプリケーションを、より早く、しかも大規模に市場へ投入できるようになります。

次に重要なのは、適切な統制のもとで、組織内の誰もがデータにアクセスできる状況を整えることです。これにより、多くの可能性が開かれます。データオーケストレーションとエンタープライズ検索を生成 AI と組み合わせれば、長年固定化してきた部門間のサイロを取り払い、組織全体の意思決定を加速できる可能性があります。これは、AI 活用の中でも特に有望な領域の一つです。

金融の世界は、新たなテクノロジーと変化する顧客の期待に後押しされ、今後も進化し続けるでしょう。PayPal のデータ変革は、老舗企業であっても、立ちはだかる根本課題に正面から向き合う意思さえあれば、この変化に先回りする形で自らを再構築できることを示しています。

その結果、私たちはデジタル決済のパイオニアとしての地位を守っただけでなく、デジタルコマースにおける次なるイノベーションの波を牽引し続けるための基盤も整えることができました。

- PayPal、SVP 兼データ、AI、ML テクノロジー担当グローバルヘッド、Mani Iyer 氏

- PayPal、データ分析担当シニアディレクター、Vaishali Walia 氏

Spanner カラム型エンジンで Iceberg レイクハウスの最新データを迅速に提供

Thu, 05 Mar 2026 03:00:00 +0000

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

運用データベースのデータと分析データレイクハウスのデータの間の境界は急速に消えつつあります。ゼロ ETL レイクハウスアーキテクチャを導入する企業が増えるにつれ、課題は単に Apache Iceberg のようなオープンデータ形式でデータを保存することから、最新のアプリケーションや AI エージェントが必要とするデータを低レイテンシのパフォーマンスとスピードで提供することに移っています。脅威検出に関する分析情報をリアルタイムで必要とする Palo Alto Networks のようなサイバーセキュリティプロバイダであれ、より優れたカスタマーエクスペリエンスを提供するためにデータワークフローの再構築を検討している Vodafone のような通信業界の大手企業であれ、組織は事前に計算された分析情報と AI モデルを大量に提供しなければなりません。

そこでこのたび、Spanner カラム型エンジンのプレビュー版をリリースしたことをお知らせいたします。これにより、Google の Spanner が持つスケーラビリティと低レイテンシで Iceberg レイクハウスのデータを提供できるようになります。

OLTP と分析の統合: Spanner カラム型エンジン

従来、組織は OLTP データベースの高性能なトランザクション機能と、カラム型ウェアハウスの分析能力のどちらかを選択せざるを得ませんでした。Spanner のカラム型エンジンは、これら 2 つの世界を水平方向にスケーラブルな 1 つのシステムに統合することで、このトレードオフの問題を解消します。

カラム型エンジンでは、特別なストレージメカニズムが採用されています。このメカニズムは、ライブ運用データのスキャンを最大 200 倍に高速化して分析クエリを加速させるように設計されています。Spanner は、従来の行ベースのストレージと並行してカラム形式でデータを保存することにより、複雑なクエリを自動的に実行できます。その際は、データを行単位ではなく一度にバッチ処理するベクトル化された実行を使用します。最も重要な点は、このパフォーマンスの向上を重要なトランザクションワークロードから分離できることです。これにより、顧客向けアプリケーションの応答性を維持しながら、運用データストアからリアルタイムの分析情報を取得できます。

新機能

Spanner カラム型エンジンを初めて発表して以来、パフォーマンスを加速させ、ユーザビリティを高めるための新機能がいくつか追加されています。たとえば、以下のようなものが挙げられます。

ベクトル化された実行: エンジンは、ベクトル化された実行を使用して、より高速なカラム型スキャンと集計に対応し、より効率的にデータを処理します。
自動クエリ処理: Spanner は、大規模スキャン分析クエリを自動的にカラム型表現にリダイレクトし、同時に実行しているトランザクションワークロードに影響を与えることなく分析クエリを高速化して、真のハイブリッド処理を実現します。
オンデマンドのカラム型データ変換: 自動化されたカラム型データ変換に加えて、新しいメジャーコンパクション API により、既存の非カラム型データをカラム型形式に変換するプロセスが加速します。

Iceberg データに高速かつ低レイテンシのサービングプラットフォームが必要である理由

オープンレイクハウスアーキテクチャの標準となっている Apache Iceberg は、クラウドベースのストレージで大規模なオープン形式のデータセットを管理する堅牢な手段となります。ただし、レイクハウスは大規模な分析には優れていますが、ライブアプリケーションで求められる、同時実行性の高い 1 秒未満での「ポイント検索」や集計サービス向けには、通常は設計されていません。

Spanner が独自の価値提案を提供するのはこの部分です。キュレートされた処理済みデータをレイクハウスから Spanner に移動するプロセス（リバース ETL と呼ばれます）により、「コールド」分析データが「ホット」運用データに変換されます。Spanner は、アプリケーションが必要とするグローバルな整合性と高可用性を提供します。低レイテンシの API を介して Iceberg データにアクセスできるようにすることで、リアルタイムの意思決定やエージェント型 AI 機能の利用が可能になります。

Spanner カラム型エンジンのベンチマーク

Spanner の新しいサービング機能を実証するために、業界をリードする分析データベースベンチマークの Clickbench を使用しました。Clickbench は、ウェブ解析やリアルタイムダッシュボードでよく使われるクエリタイプに焦点を当てています。これはまさに、低レイテンシのサービングが重要となるシナリオです。

単一の Spanner ノードを使用したベンチマークの結果から、カラム型エンジンが持つ力がわかります。

Clickbench のクエリ	Spanner カラム型エンジンの高速化
Q01	46.3 倍
Q02	32.7 倍
Q19	46.7 倍
Q32	58.6 倍

上述の結果は、Spanner カラム型エンジンにおける実際のワークロードの高速化を表しており、Spanner がスキャン負荷の高い複雑なクエリを実行し、ミリ秒単位で結果を返すことができることを示しています。これは、リアルタイムダッシュボードやユーザー向け機能の強化に最適です。今や Spanner は、最新のデジタルエクスペリエンスが求めるスピードで複雑な分析結果を提供できる、高性能なエンジンとなっています。

ユニバーサルリバース ETL: すべてのレイクハウスのデータを提供

Spanner は、データエコシステム全体のサービングレイヤとして機能するように設計されています。レイクハウスが BigQuery、Snowflake、Databricks、Oracle のいずれにある場合でも、Spanner は高速サービングのための統合経路を提供します。

最新のリバース ETL ワークフローにより、分析の世界と運用の世界を簡単につなぐことができます。

BigQuery: Spanner と BigQuery の緊密な統合により、運用環境と分析環境の両方で Iceberg データを管理するための強力な双方向ブリッジが実現します。BigQuery の Spanner 外部データセットを使用して BigLake Iceberg テーブルと Spanner テーブルに対する連携クエリを実行できるため、データを移動しなくてもリアルタイムで分析できます。キュレートされた BigQuery の分析情報を大規模に提供する必要がある場合は、リバース ETL ワークフローを使用して、BigQuery と BigLake Iceberg テーブルからデータを Spanner に直接 push できます。さらに、Datastream を使用して、Spanner でライブ運用データの変更をキャプチャし、BigQuery と BigLake Iceberg のテーブルにストリーミングできます。これにより、レイクハウスでは Spanner のトランザクションデータと同期された状態が保たれ、エージェント型 AI やリアルタイムでの意思決定を実現できます。
Databricks: Databricks の Universal Format（UniForm）を使用すると、Delta Lake テーブルの Iceberg メタデータを自動的に生成できます。これにより、Spanner は BigQuery または Dataflow を介して処理された Databricks データを取り込むことができるため、エンジニアリングのオーバーヘッドを最小限に抑えながら、「キュレーション済み」のデータセットをアプリケーションの強化に活用できます。
Snowflake: Iceberg テーブルを Google Cloud Storage にエクスポートし、BigQuery BigLake をゼロコピーの中間ストレージとして使用することで、EXPORT DATA コマンド経由でデータを直接 Spanner に push できます。代わりに、よりシンプルな移行方法として、Snowflake データを CSV としてエクスポートし、Dataflow テンプレートを使用して Spanner に高スループットで取り込むこともできます。
Oracle Autonomous AI Lakehouse: Oracle Goldengate 26ai では、Oracle Autonomous AI Lakehouse のデータを Spanner に複製し、Spanner のスケーラビリティと整合性を活かして Oracle のデータエコシステムから生成された分析情報を提供できるようになりました。

使ってみる

レイクハウスのクエリが完了するのを待つのはもうやめましょう。Spanner カラム型エンジンを搭載した Google Spanner を使用して、更新頻度の高いホットデータをすばやく提供してください。Spanner カラム型エンジンは現在プレビュー版で公開されています。DDL を簡単に変更するだけで、既存の Spanner テーブルに対してすぐに有効にできます。

GitHub で入手できる Spanner で Clickbench クエリを実行すると、Spanner カラム型エンジンのパフォーマンスの向上を実際に確認できます。

すぐに使用を開始できるよう、Spanner へのリバース ETL パイプラインを構築する Codelab をご紹介します。

Databricks:

および

Snowflake:

- グループプロダクトマネージャー、Jagan R. Athreya

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

従来の Apache Cassandra スタックを廃止し、Spanner で未来志向の基盤を構築

Thu, 05 Mar 2026 00:10:00 +0000

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

従来の NoSQL 環境である Apache Cassandra などから Spanner へ移行するお客様が増えています。その戦略的な背景は明確です。総保有コスト（TCO）の大幅な削減、弾力的なスケーラビリティ、そしてほぼゼロに近い運用負荷です。

Cassandra Query Language（CQL）API を Spanner 上で利用できるネイティブエンドポイントが一般提供されたことで、既存の Cassandra アプリケーションは、使い慣れた CQL をそのまま活用しながら、強整合性、事実上無制限のスケール、99.999% の可用性を備えた Spanner のエンタープライズ基盤を利用できるようになりました。

さらに、CQL インターフェースを用いた Spanner への移行は、通常、コードの 1 行を変更するだけで済みます。既存の CQL 文はそのまま有効だからです。Google が提供する統合型の高性能バルクマイグレーションツールおよびライブマイグレーションツールと組み合わせることで、Cassandra から Spanner への移行はシンプルに実現できます。

NoSQL の先へ: Cassandra ユーザー向けの戦略的ソリューション

CQL API は移行を容易にしますが、Spanner は、従来の Cassandra アーキテクチャに内在するデータの完全性と運用上の制約そのものを解決します。

グローバル ACID トランザクション: 結果整合性に伴う懸念を最小限に抑えます。あらゆる規模においてデータの完全性を確保できるよう、包括的なグローバル ACID トランザクションを実現します。
強力なインデックス: 強整合性のセカンダリインデックスにより、複雑なクエリパターンにも対応できます。最適化が組み込まれており、完全性に関するリスクもありません。
豊富な SQL: 結合や集計をサポートする高度な SQL インターフェースを活用できます。
高い信頼性: リージョン構成では 99.99%、マルチリージョン構成では 99.999% の可用性を享受できます。
コンプライアンスとレイテンシ: 地域的パーティショニングにより、データレジデンシ要件への対応を簡素化します。グローバルなユーザー基盤に対して、低レイテンシのローカル読み書きを提供できます。
組み込みのオブザーバビリティ: 追加費用なしで、Google Cloud コンソール上から各種パフォーマンス指標やチャート一式にアクセスできます。

ネイティブ CQL エンドポイントは、既存の Cassandra アプリケーションを切り離し、Spanner の能力を最大限に活用してモダナイズするための明確な道筋を提供します。次に、Cassandra から Spanner へデータとアプリケーションを移行した後のステップを見ていきましょう。

ワークロードに合わせた Spanner の最適化

移行後は、以下の方法で Spanner 環境をワークロードに合わせて最適化できます。

1. コストと運用効率の最適化

ワークロードの特性	おすすめの解決策	主なメリット
書き込み負荷が高いトラフィック	スループットを最適化した書き込み	リクエストのバンドリングにより、書き込みスループットが最大 6 倍に向上（レイテンシへの影響は最小限）。
トラフィックが変動または増減する	オートスケーラー	需要に応じて容量を自動調整し、過剰プロビジョニングによるコストを排除。
安定したベースライン容量が必要	確約利用割引（CUD）	定常的な運用コストを最大 40% 削減。
ストレージ集約型ワークロード	階層型ストレージ（HDD）	費用対効果の高い HDD ストレージを活用し、長期的なストレージ費用を大幅に削減。

2. 低レイテンシの実現Spanner は、ミッションクリティカルかつ高並行性のワークロードを支えるため、継続的にパフォーマンスを強化しています。

シングルディジットミリ秒のパフォーマンス: 読み取りおよび書き込みの両方で、常に 5 ms 未満のレイテンシを実現します。
反復可能な読み取りの分離: 楽観的同時実行制御を活用し、読み取り中心かつ競合の少ないシナリオにおいて、レイテンシとトランザクション中断を低減します。
読み取りリース: マルチリージョン構成において、リージョン間の調整を行わずに強整合な読み取りを可能にします。これにより、ノード効率とパフォーマンスを最大化します。

3. トラフィック急増への備えマーケティング施策のローンチや大規模データ取り込みなど、計画的なイベントに備えて、容量を事前に管理できます。

Manual split API: Spanner はは通常、自動でデータをパーティション分割しますが、事前分割機能を使うことで、ピーク負荷の前にデータ分散方法を正確に定義できます。これにより、新たに追加した容量を即座に活用でき、安定したパフォーマンスを確保できます。

4. 運用系と分析系のパイプラインを分離BI や ETL プロセスをコア業務処理から分離し、リソース競合を防ぎます。

専用リソース: 読み取り専用レプリカや有向読み取りを活用することで、ワークロードの分離を実現します。
高度な分析機能: Spanner はカラム型エンジンにより高性能なオペレーショナル分析を提供します。また、Data Boost、リバース ETL、継続的クエリを通じて BigQuery と統合できます。

Cassandra エコシステムを再構築する

Apache Cassandra から Spanner への移行は、複雑に絡み合ったサイドカーユーティリティ群からアーキテクチャを切り離す戦略的な機会です。Cassandra 互換 API はあくまで入口にすぎません。真の価値は、運用上の「Cassandra 税」ともいえる負担を、統合されたマネージド型マルチモデルエコシステムへと集約できる点にあります。

こちらは、TCO を大幅に削減しながら、パフォーマンスを大きく向上させるためのクイックガイドです。

1. コネクタを活用してスムーズに移行

Spanner Cassandra アダプタや各種コネクタを活用することで、管理レイヤーとアプリケーションレイヤーを、コード変更をほぼ伴わずに移行できます。これにより、移行初期の負担を最小限に抑えられます。

オーケストレーション: Spanner プロキシに付け替えることで、既存の Airflow DAG を維持できます。
アプリケーションフレームワーク: Spring Data Cassandra から Spring Data Spanner へ移行し、既存のリポジトリパターンを保ちながら、より優れたトランザクションモデルを活用できます。
データ処理: Spanner のネイティブ CQL エンドポイントに接続するか、Spark 向けの専用 Spanner Connector を使用することで、Apache Spark の活用を継続できます。

2. ネイティブ統合でサイドカーを整理

Cassandra では運用面の「付き添い」レイヤーが不可欠ですが、Spanner はそれを自動化します。従来の保守ツールを段階的に廃止し、Spanner の高度な機能を活用できます。

アンチエントロピー: Cassandra Reaper を廃止できます。Spanner は Paxos ベースのレプリケーションにより整合性をネイティブに管理するため、手動のリペアサイクルが不要になります。
データ保護: Medusa は Spanner ネイティブのバックアップに置き換えられます。脆弱な SSTable スナップショットから脱却し、信頼性の高いポイントインタイムリカバリ（PITR）へ移行できます。
オブザーバビリティ: 複雑な JMX エクスポータの代わりに Cloud Monitoring を利用できます。保守負債を増やす監視ではなく、Query Insights や Lock Statistics といった高付加価値の指標に注力できます。
統合検索: 外部の Elasticsearch サイドカーや複雑な ETL パイプラインを Spanner の全文検索で置き換えられます。これにより、インデックス同期の問題を解消できます。
モダンなストリーミング: 従来の CDC を Spanner 変更ストリームに置き換えられます。Dataflow や Kafka とネイティブに統合できます。
グラフ分析: JanusGraph は Spanner Graph に移行できます。複雑な ETL を介さずに、運用データに対して openCypher クエリを直接実行できます。
クエリフェデレーション: Trino / Presto は、Data Boost を介した BigQuery Federation に置き換えられます。本番環境の I/O に影響を与えることなく、リアルタイムのトランザクションデータと大規模なデータレイクを結合できます。

Spanner のマルチモデルの強みで未来を築く

Spanner は、リレーショナル、Key-Value、グラフ、検索、ベクトル検索といった機能を 1 つの相互運用可能なプラットフォームに統合した常時稼働型のデータベースです。Spanner に移行することで、分断された複数データベースを管理する負担を解消し、統一されたデータ基盤の上で革新的なアプリケーションを開発できるようになります。新規アプリケーションの構築にも、既存アプリケーションのモダナイゼーションにも、Spanner の機能を最大限に活用できます。

今すぐ始めましょう

運用管理の負担から解放され、構築に集中する準備はできていますか？今すぐ移行を開始し、既存の Cassandra Query Language をそのまま活用しながら、Spanner の能力を体験してください。

Codelab: ネイティブ CQL エンドポイントを使ったハンズオンで、実践的なスキルを習得できます。
無料トライアル: Spanner を 90 日間無料で試すことができます。あるいは、月額 65 ドルから、中断なくスケールできるプロダクションレディなインスタンスを開始できます。
移行ガイド: 詳細な技術ドキュメントと包括的な移行リソースにアクセスできます。

- プロダクトマネージャー、Nitin Sagar

Gartner® の Critical Capabilities レポートの軽量トランザクションユースケースで Google（Spanner）が第 1 位を獲得

Fri, 27 Feb 2026 03:40:00 +0000

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

Google（Spanner）は、Gartner レポート「Critical Capabilities for Cloud Database Management Systems for Operational Use Cases」（運用ケース向けクラウドデータベース管理システムの重要機能）において 2 年連続で高く評価され、軽量トランザクションユースケースで第 1 位を獲得しました。これは、このプロダクトの効率性、低レイテンシ、高パフォーマンスに一貫性があることを示していると Google は考えています。また、同プロダクトは OLTP トランザクションユースケースの最新のランキングでも 第 2 位を獲得しました。これは、「無限」の水平スケーリングが、従来のトランザクションパフォーマンスを犠牲にせずに実現されていることを示していると私たちは考えています。この 2 年連続の受賞は、世界で最も要求の厳しいデータ環境に対する継続的な卓越性とイノベーションを実現するという Google の理念を裏付けています。

こちらから Gartner レポートの全文をご確認いただけます。

運用パフォーマンスについて

Critical Capabilities の評価を見ると、Spanner のパフォーマンスこそが、さまざまなカテゴリで継続的に評価されている理由だと Google は考えています。

軽量トランザクションユースケースで第 1 位（2 年連続）: マイクロサービスとイベントドリブンアーキテクチャが一般的になるにつれ、高頻度で低レイテンシのトランザクションを処理する能力が非常に重要になります。Spanner が 1 位にランクインしたことは、Spanner が最新のワークロードにとって最も効率的なエンジンであることを示していると言えるでしょう。
分散トランザクションのサポート（スコア: 5.0 点中 5.0 点）: Spanner は、複数のノード、リージョン、地域をまたがる分散トランザクションをサポートする機能で 5.0 点を獲得した唯一のサービスです。
AI / ML と生成 AI（スコア: 5.0 点中 4.6 点）: このスコアは、AI を Spanner に直接統合するために Google が 2025 年に実施した、大規模な数々のイノベーションの結果であると考えています。
トランザクションの整合性（スコア: 5.0 点中 4.9 点）: Spanner は地球規模で外部整合性を提供するため、いつどこで発生したトランザクションでも、常にグローバルレベルで正確であることを保証します。
OLTP ユースケースで第 2 位: Spanner は、従来型の大量のトランザクションワークロードにますます使用されるようになっています。これは、Spanner の「無限」の水平スケーリングが、レガシーからの移行時の最適な選択肢になっていることが理由だと Google は考えています。

これらの評価は、Spanner がグローバル規模の特殊なソリューションから、ほぼすべてのミッションクリティカルなアプリケーションに対応できる、技術面で特に優れたデータベースへと進化したことを示していると考えられます。

エージェントを活用している企業の基盤

2025 年、数多くの新機能が追加された Spanner は、AI エージェントの「頭脳」となりました。

Spanner Graph（一般提供を開始しました）: グラフとリレーショナルデータを統合したエクスペリエンスを提供します。Spanner Graph では、ISO 規格の GQL と SQL を使用して複雑な関係性をトラバースできます。これは、AI エージェントを実世界の事実に基づいてグラウンディングするためのナレッジグラフを構築するうえで非常に重要です。
統合ハイブリッド検索: 2025 年に一般提供が開始された Spanner は、SQL モダリティとグラフモダリティ内で大規模な全文検索とベクトル検索を直接サポートしています。これにより、統合された低レイテンシの検索拡張生成（RAG）を大規模に実現できます。
Spanner カラム型エンジン: このアーキテクチャ上の画期的な進歩により、Iceberg テーブルから取得したライブ運用データに対する分析クエリが最大 200 倍高速化されます。これにより、エージェントは必要なリアルタイムのコンテキストを「ETL（抽出、変換、読み込み）の負担」を負わずに得ることができます。
相互運用性の拡大: 新しい Cassandra 互換 API により、コードを変更せずにスケールアウトワークロードを Spanner に取り込むことがこれまで以上に簡単になり、従来のデータを AI 革命に活用できるようになりました。

未来に向けた青写真

Gartner によるこの評価は、データ管理は今後、オープンかつ統合され、AI が組み込まれたものに移行していくだろうという Google の信念を裏付けていると私たちは考えています。お客様は、日常的に Spanner の最新のイノベーションを活用しています。

Palo Alto Networks: 世界的なサイバーセキュリティリーダーである Palo Alto Networks は、マルチテナントアーキテクチャの中核として Spanner を利用しています。99.999% の可用性を備えた Spanner と Spanner Graph を活用することで、同社は重要なアクセス制御のユースケースを地球規模で実現しました。この統合アプローチにより、専用のグラフデータベースサイロがなくても、重要な顧客ワークフローを管理する一貫性のあるアーキテクチャを構築し、AI を大規模に保護できます。
Mercado Libre: ラテンアメリカの e コマースおよびフィンテックを扱うこの大手企業は、社内システムの基盤となる整合性とスケーラビリティの確保に Spanner を活用しています。Spanner を社内の「Fury」プラットフォームと統合することで、ほぼ完ぺきな稼働状況で毎日数百万件の金融取引を管理しています。Spanner Data Boost を活用して、トランザクションのパフォーマンスに影響を与えることなくリアルタイム分析を実現しています。また、AI を活用した次世代金融エージェントの信頼できるメモリストアとして Spanner を使用するようになりました。
Unico: この大手 ID テクノロジー企業は、2021 年以降、12 億件以上のデジタル ID 認証を実施可能にすることで、数十億ドル規模の不正行為を防止しています。Spanner の統合ベクトル検索により、Unico は数十億のベクトルを対象に複雑な 1:N（1 対多）の顔生体認証検索を高精度かつ低レイテンシで実行しています。これにより、別のベクトルデータベースが不要になるため、同社の「ID ネットワーク」は高速かつ高精度で、メンテナンス不要の状態を維持できます。

Spanner が評価された理由とは

今後はデータ管理は統合され、AI 向けに構築されていきます。軽量トランザクションで 1 位を獲得した Spanner は、ミッションクリティカルなアプリケーションに最適な選択肢であると Google は確信しています。

2025 年 Gartner® Magic Quadrant のクラウドデータベース管理システム（DBMS）のレポート全文をご覧ください。
2025 年度の「Gartner Critical Capabilities for Operational Cloud DBMS」レポートをご覧ください。
Spanner を無料で試して、AI 対応アプリケーションの構築を今すぐ始めましょう。

^{Gartner、「Critical Capabilities for Cloud Database Management Systems for Operational Use Cases」（作成者: Ramke Ramakrishnan、Masud Miraz、Xingyu Gu、Henry Cook、Aaron Rosenbaum、2025 年 11 月 19 日）}

^{Gartner は、リサーチに関する発行物に掲載されている特定のベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner のリサーチに関する発行物は、Gartner のリサーチ組織の見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、本リサーチの商品性や特定の目的への適合性を含め、いかなる保証も行いません。}

^{上の図は、リサーチドキュメントの一部として Gartner, Inc. より公開されているもので、ドキュメント全体の文脈に即して評価する必要があります。この Gartner のドキュメントをご希望の方は、Google Cloud までご請求ください。}

- グループプロダクトマネージャー、Jagan R. Athreya

- プロダクト管理担当ディレクター、Jagdeep Singh

Google Cloud データベースで次世代のエージェントを強化する

Thu, 26 Feb 2026 03:00:00 +0000

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

カスタムエージェントや chatbot などの AI アプリケーションを構築する開発者は、オープンソースの Model Context Protocol（MCP）標準により、作成したイノベーションがデータやツールに一貫性のある方法で安全にアクセスできるようにすることができます。Google は 2025 年末、Google マップや BigQuery などのサービス向けにマネージドおよびリモート MCP のサポートを導入することで、AI がツールに接続するための標準的な方法を確立し、アプリケーションのユニバーサルインターフェースを効果的に作成しました。このたび、このサービスを拡張し、PostgreSQL（AlloyDB、Spanner、Cloud SQL）と、高パフォーマンスの NoSQL ワークロード向けの Firestore および Bigtable を追加しました。また、IDE を Google のドキュメントに接続する API を備えた新しい Developer Knowledge MCP サーバーも導入します。これらのサーバーは Google Cloud で実行され、Gemini やその他の MCP 準拠のクライアントがデータやインフラストラクチャと簡単にやり取りできる安全なインターフェースを提供します。

Gemini 3 のリリースにより、開発者は高度な推論機能を利用して、複雑な問題を計画、構築、解決できるようになりました。しかし、AI モデルが有用な「エージェント」として機能するには、信頼できる方法で環境とやり取りする必要があります。今回の発表は、これらの機能を、お客様が作業環境のバックボーンとして日常的に利用しているデータベースツールにまで幅広く拡張するものです。

エージェントをこれらのサーバーに接続するために、インフラストラクチャをデプロイする必要はありません。エージェント構成で MCP サーバーエンドポイントを構成するだけで、エンタープライズグレードの監査、オブザーバビリティ、ガバナンスに裏付けられた運用データに即座にアクセスできます。インフラストラクチャの管理が不要なため、運用上のオーバーヘッドを発生させることなく、エージェントのワークロードをスケーリングできます。

エージェントに運用データを提供

これらの新しいマネージドサーバーにより、エージェントは Google のポートフォリオ全体で特定の機能にアクセスできるようになります。

AlloyDB for PostgreSQL: エージェントは PostgreSQL ワークロードとやり取りして、スキーマの作成、複雑なクエリの遅延の診断、ベクトル類似性検索の実行などのタスクを可能にします。
Spanner: Spanner の統合マルチモデル機能（Spanner Graph など）を使用すると、エージェントは標準（SQL および GQL）クエリを使用し、リレーショナルデータやセマンティックデータと並行して複雑な関係をモデル化およびクエリできます。これにより、エージェントは MCP ツールを自由に使用して、詐欺組織の特定や商品のレコメンデーション生成など、深い分析情報を迅速に発見できます。
Cloud SQL for PostgreSQL、MySQL、SQL Server: 開発者とデータベース管理者は、MySQL、PostgreSQL、SQL Server のフリート全体で Cloud SQL MCP Server を使用し、データベースとの自然言語でのやり取り、AI によるアプリ開発の支援、クエリパフォーマンスの最適化、エージェントによるデータベースのトラブルシューティングを行うことができます。
Bigtable: Bigtable の柔軟なスキーマと高スループットの取り込み機能は、デジタル統合ハブの構築や時系列データの管理によく使用されます。MCP を使用すると、運用ワークフローの自動化が簡素化され、カスタマーサポート、CRM、人事、IT 運用、サプライチェーン、ロジスティクス分野でこのデータを使用したエージェントアプリケーションを開発しやすくなります。
Firestore: モバイルとウェブの開発に重点を置いた Firestore MCP サーバーにより、エージェントはライブドキュメントコレクションと同期できます。その結果、自然言語プロンプトを介してユーザーセッションの状態を確認したり、注文状況を確認したりするなどの動的なインタラクションがサポートされます。

アプリケーションとインフラストラクチャの管理

Google は、エージェントがデータの取得だけでなく、アプリケーションの構築と管理を支援できるようにしています。Developer Knowledge MCP サーバーは、IDE を Google のドキュメントに接続し、エージェントが関連性の高いコンテキストを使用して技術的な質問に答えたり、コードのトラブルシューティングを行ったりできるようにします。

セキュリティとガバナンス

エージェントをデータベースに接続するには、堅牢なセキュリティとガバナンスが必要です。これらのサーバーは、Google Cloud の標準的な ID およびオブザーバビリティフレームワークに基づいて構築されています。

ID ファーストのセキュリティ: 認証はすべて、共有キーではなく、Identity and Access Management（IAM）を通じて処理されます。これにより、エージェントはユーザーが明示的に承認した特定のテーブルまたはビューにのみアクセスできるようになります。
完全なオブザーバビリティ: エージェントのアクティビティを追跡できるように、これらの MCP サーバーを介して行われたすべてのクエリとアクションは Cloud Audit Logs に記録されます。これにより、セキュリティチームはすべてのデータベース操作の記録を取得し、可視性を維持しながら簡単にアクセスできます。

デモ: ローカルコードからマネージドデータへ

新しい MCP サーバーの動作例を見てみましょう。

フィットネスコミュニティ向けのフルスタックイベント管理プラットフォームの移行を自動化するエージェントを想像してみてください。Gemini CLI で一連の自然言語の指示を使用することにより、エージェントは Cloud SQL リモート MCP サーバーを利用して、マネージド PostgreSQL インスタンスをプロビジョニングし、正しいスキーマを適用して、ローカルデータを安全に移行します。複雑な gcloud コマンドを習得したり、Cloud SQL のエキスパートになったりする必要はありません。面倒な作業はエージェントが行います。この移行は、Developer Knowledge MCP サーバーが公式ドキュメントを参照してエージェントをベストプラクティスに導くことによって、リアルタイムで設計されます。その結果、アプリケーションのバックボーンがローカルストレージからフルマネージドのエンタープライズデータベースに簡単にアップグレードされます。

サードパーティエージェントのサポート

これらのサーバーはオープンな MCP 標準に準拠しているため、お気に入りの AI エージェントとも連携できます。設定でカスタムコネクタを追加することで、Anthropic の Claude などのクライアントを簡単に接続できます。Google Cloud データベースの MCP エンドポイントを指定するだけで、すぐに構築を開始できます。複雑な構成ファイルはいりません。

次のステップ

今後数か月以内に、Looker、Database Migration Service（DMS）、BigQuery Migration Service、Memorystore、データベースセンター、Pub/Sub、Kafka などのマネージド MCP サポートが追加され、このエコシステムはさらに拡大する予定です。

安全なデータドリブンエージェントの構築を開始するには、AlloyDB、Spanner、Cloud SQL、Bigtable、Firestore のガイドをご覧ください。Cloud SQL と Spanner の Codelab や、Google Cloud へのアプリの移行手順について説明するこちらのデモ動画もご覧ください。

- AI およびデータベース担当バイスプレジデント、Amit Ganesh

- データベース向け AI 担当シニアプロダクトマネージャー、Rahul Deshmukh

2025 年の Spanner: インテリジェントなマルチモデル AI アプリケーションを強化するイノベーション

Wed, 04 Feb 2026 02:00:00 +0000

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

Google は 10 年以上にわたり、常時稼働でほぼ無制限のスケーリングが可能なデータベースである Spanner を基盤として、Gmail、YouTube、Google フォトなどの世界規模のアプリケーションを支えてきました。現在、Spanner が処理する秒間クエリ数は 60 億以上（ピーク時）、データ量は 17 エクサバイトを超え、99.999% の可用性とグローバルな整合性を実現しています。

2025 年は、Google Cloud 上の Spannerにとって、大きな年でした。Walmart、Goldman Sachs、Palo Alto Networks、Mercado Libre などのお客様の要求の厳しいワークロードを Spanner が支えているからです。同時に、AI が中心となる時代において、データベースの役割は大きな変革を遂げつつあります。データベースは、受動的なデータリポジトリとしての従来の機能を超えて進化し、インテリジェントなコンテキストハブになりつつあります。Spanner は現在、商品検索とレコメンデーション、不正行為の検出、ID の解決、自律型ネットワーク運用（ANO）などの主要なユースケースをサポートしています。

2026 年に向けて期待が高まるなか、昨年のハイライトをいくつか振り返ってみましょう。Google は 2025 年に、以下を達成しました。

AI ワークロードの主要な基盤としての Spanner の位置付け
運用データと分析データのギャップ解消
移行の簡素化
費用対効果の基準引き上げ
エンタープライズレベルの安全性とデータ保護の強化

おさらいしていきましょう。

マルチモデルをサポートする Spanner AI

真にインテリジェントな生成 AI アプリケーションを構築するために、複数のポイントソリューションを組み合わせる必要はありません。こうした理由から Google は、2024 年に AI モデルへのコンテキスト提供を目指してベクトル、グラフ、リレーショナルデータを統合しました。2025 年には、これらのマルチモデル機能を拡張し、グラフ、ベクトル、テキスト検索、そして Vertex AI との連携を含め、新しい機能を追加しました。

AI 機能: Spanner を AI ファーストのデータベースにするために、複数の機能を導入しました。これには、自然言語クエリ用の ML.PREDICT、データベース向け MCP ツールボックス、Gemini CLI 用 Spanner 拡張機能、会話型データエージェント、Spanner 用 Agent Development Kit などの組み込みの AI インテグレーションが含まれ、これらを併用することで、デベロッパーは Spanner を使用して高度なエージェントアプリケーションを構築できます。また、マルチモデルプラットフォームを拡張して、GraphRAG ユースケースでグラフにベクトル検索を活用するといった、高度な AI ユースケースに対応できるようにもなりました。最後に、Vertex RAG Engine では、データのインデックス作成と取得オペレーションに、RAG が管理するデータベースとして Spanner を使用できるようになりました。
グラフの機能強化: Spanner Graph にスキーマレスデータのサポートが追加されました。これにより、スキーマを変更しないでも、反復型開発と頻繁な更新が可能になりました。また、名前付きスキーマ オブジェクトと SQL ビューでグラフを構築し、アプリの重要な要素を整理してカプセル化できるようにもなりました。
全文検索: enhance_query オプションにより、多数の関数に対する類義語の自動マッチとスペル修正が可能になるため、再現率を高めるために必要な手動チューニングの手間を省くことができます。
近似最近傍（ANN）: Google の ScaNN を使用した ANN は高速でスケーラブルなベクトル検索手法です。この検索手法は、高次元ベクトル検索の効率を重視して最適化されており、AI レコメンデーションシステム、画像検索、セマンティック検索で不可欠です。2025 年には、ANN 検索の一般提供を発表しました。これにより、デベロッパーはベクトルエンベディングに対する高速な類似検索を実行できるようになり、大規模な整合性が重要となる生成 AI アプリケーションを支えています。

AI を活用した運用

2025 年には、デベロッパーがアプリケーションに Spanner を活用しやすくなるよう、AI を活用した複数の機能が強化されました。

Spanner インデックスアドバイザー: インデックスアドバイザーは、クエリパターンを分析し、パフォーマンスと費用を最適化するために新しいインデックスをプロアクティブに提案します（または、使用されていないインデックスを特定します）。
スキーマに関する推奨事項（プレビュー版）: スキーマ設計をスキャンしてホットスポット化しやすい主キーなどのアンチパターンがないかを確認し、本番環境で問題が発生する前に改善を提案するインテリジェントなツールです。
Spanner CLI: gcloud に直接バンドルされた新しいコマンドラインインターフェース（CLI）で、この CLI により、既存のデベロッパーワークフロー内で SQL の実行、セッションの管理、スクリプトの自動化が可能になります。

統合分析: サイロと複雑さを最小限に抑える

昨年、Google は複数の新機能によって運用データと分析データのギャップを埋めました。

Spanner カラム型エンジン（プレビュー版）: このエンジンを使用すると、Spanner のグローバルな整合性、高可用性、強力なトランザクション保証を維持しながら、大量の運用データをリアルタイムで自動的に分析できます。トランザクションワークロードに影響を与えることはありません。Verisoul.ai は、偽アカウントの検出を自動化するオールインワンプラットフォームのプロバイダです。同社は Spanner と Spanner カラム型エンジンを活用して、低レイテンシのトランザクション書き込みと豊富な分析をサポートし、ユーザーに迅速なレスポンスを提供しています。
「BigQuery でさらに向上」エコシステム: Spanner と BigQuery のインテグレーションを強化し、運用エンジンと分析エンジンを統合することでリアルタイムの分析情報を提供しています。

Apache Iceberg のサポート: この機能により、データアナリストは、BigQuery 上の Apache Iceberg テーブルと Spanner のライブデータの結合、および Iceberg データの Spanner へのエクスポートができます。これによって、リアルタイムの運用データ（Spanner から取得）をクエリして、その結果をキュレートされたデータレイクハウス（Iceberg 内）と組み合わせることができます。
Spanner 外部データセットのマテリアライズドビュー: BigQuery の Spanner 外部データセットの一般提供を発表しました。これにより、BigQuery ユーザーは ETL を必要とせずに Spanner のライブ運用データをクエリできるようになりました。さらに、この機能を拡張して BigQuery マテリアライズドビューと統合し、事前に計算されたクエリ結果に基づく超高速のレポート作成を実現しました。
リバース ETL を使用した継続的クエリ（BigQuery から Spanner）: BigQuery の継続的クエリ機能を Spanner へのリバース ETL と組み合わせることで、不正行為アラートや動的料金設定シグナルなどの計算された分析情報を BigQuery から Spanner にリアルタイムでストリーミングし、これらの分析情報を低レイテンシで提供できるようになりました。Fastweb + Vodafone は、まさにそれを実現しました。具体的には、両社はこの機能を活用し、Spanner を BigQuery と連携させたリアルタイムのサービングレイヤとして使用しました。

シンプルな移行

お客様は、99.999% の可用性、事実上無制限のスケーリング、低い運用上のオーバーヘッド、グローバルな整合性といったメリットを得るために、Spanner に移行することがよくあります。Google は 2025 年に、Cassandra と MySQL のワークロードを Spanner に簡単に移行できるようにしました。

Cassandra インターフェース: Spanner の Cassandra インターフェースを使用すると、使い慣れた Cassandra ツールと構文を使用して、Spanner のフルマネージドで、スケーラブルかつ高可用性のインフラストラクチャを活用できます。既存の CQL アプリケーションを、ほぼ変更なしでリフト＆シフトできます。
MySQL の相互運用性: 80 個の MySQL 関数のライブラリをインストールできるようになりました。これにより、MySQL ワークロードを Spanner に移行するために必要なアプリケーションの変更を減らすことができます。

パフォーマンスと費用の改善

Spanner チームにとって、費用対効果の基準を継続的に引き上げることは、常に目指すべき目標です。2025 年に Google は、クエリのパフォーマンス向上と費用削減に役立つ複数の機能を導入しました。

Repeatable Read 分離（プレビュー版）: この新しい分離レベルでは、ロック管理のオーバーヘッドが削減されるため、読み取り / 書き込みの競合が少ないワークロードのレイテンシが改善されます。
JSON インデックス作成機能: Spanner の全文検索と同じ基盤を使用する JSON インデックス作成機能は、構造やデータに関する事前定義がなくても、JSON に対する一般的なクエリを高速化します。これにより、デベロッパーはパフォーマンスを損なうことなく柔軟に作業できます。
読み取りリース: 読み取りリースは、読み取り操作が大半を占める一般的なワークロードに対する書き込みパフォーマンスを多少犠牲にする代わりに、マルチリージョン構成の強整合性データの読み取りレイテンシを改善できます。
階層型ストレージ: 階層型ストレージを活用すると、同じインスタンス内で SSD ストレージと HDD ストレージを使用できるため、データライフサイクルの費用を効率的に管理できます。すべての管理は構成を通じて行われ、データにアクセスするために使用する API を変更する必要はありません。この機能は、古いデータを低コストの HDD ストレージ（最大約 80% 安価）に移動し、新しいデータは高パフォーマンスの SSD に自動的に保持します。
マネージドオートスケーラー: マネージドオートスケーラーの一般提供を発表し、読み取り専用レプリカを読み取り / 書き込みレプリカとは別にスケールできるように機能を強化しました。これにより、トラフィックパターンに基づいて費用を最適化しながら、読み取りパフォーマンスが向上しました。
手動分割点: Spanner はシャーディングを自動化して、インスタンス内のノード間で作業を分散しますが、トラフィックパターンは Google よりもお客様の方がよくご存じの場合があります。新しい分割点 API を使用すると、期間限定セールやゲームのリリースなど、予想されるトラフィック急増に合わせてデータを「ウォームアップ」または事前分割しておけるため、トラフィックに即座に対処できます。
クエリオプティマイザー: 新しいデフォルトのクエリオプティマイザー（バージョン 8）には、自動化された拡張機能が多数導入されたほか、結合戦略とインデックスの使用が最適化され、クエリのパフォーマンスと予測可能性が向上しました。
多重化されたセッション と遅延デコード: 主要な SDK（Java、Go）で多重化されたセッションをデフォルトで有効にし、スループットとリソース使用率を大幅に向上させました。また、パーティション分割されたクエリに対して遅延デコードでクライアントライブラリを最適化し、アプリケーションが大幅に少ないメモリ使用量で大規模なデータセットを処理できるようにしました。さらに、新しい組み込みのクライアント指標により、アプリケーションのデータベースパフォーマンスをきめ細かく把握できます。

エンタープライズレベルの安全性の水準を引き上げる

特に金融サービス、小売、ヘルスケアなどの業界のお客様にとって、信頼性は絶対条件です。今年、Google は、あらゆるシステムで最も予測不可能な要素である人為的ミスからのデータ保護を強化する、追加の「セーフティネット」を導入しました。

削除からの保護機能: 誤ってデータを削除すると、致命的な事態が生じる場合があります。Google は、本番環境の安全対策としてスキーマオブジェクトの削除からの保護機能を導入しました。これは、重要なテーブル、インデックス、列が誤って削除されるという運用上のミスを防ぐ役割を果たします。
デフォルトのバックアップスケジュールによるゼロタッチコンプライアンス: データ保護は手動のチェックリストに委ねるべきではありません。データベースが作成された瞬間に復元のベースラインが確保されるよう、デフォルトのバックアップスケジュールを導入しました。これにより、バックアップを忘れるリスクを最小限に抑え、ワークロードを初日から組織のガバナンスとコンプライアンスの基準に準拠させることができます。

受賞歴と評価

Google は、お客様のニーズと業界のトレンドに基づいて Spanner を強化し続けていますが、その取り組みが業界で認められることは常に素晴らしいことです。実際、2025 年に以下のような評価を受けました。

Spanner は、Gartner Magic Quadrant のクラウドデータベース管理システム（DBMS）部門のリーダーに選ばれたほか、2025 年の 「Critical Capabilities for Operational Databases」レポートの軽量トランザクションユースケースで第 1 位（すべてのカテゴリで上位 3 位）にランク付けされ、「OLTP トランザクション」で AWS Aurora を抑えて第 2 位を獲得しました。
技術的なパフォーマンスのほかに、2025 年 3 月の Forrester Total Economic Impact™（TEI）調査では、Spanner がもたらす大きなビジネス価値が検証されました。その調査によると、代表的なモデル組織は 3 年間で 132% の ROI と 774 万ドルの総利益を達成し、投資回収期間はわずか 9 か月でした。
また、Google は「リレーショナルデータマネジメントを再考し、グローバル規模で外部整合性のある直列化可能性を実現した」ことが評価され、2025 ACM SIGMOD Systems Award を受賞しました。

今後の対応

Google は、2025 年にお客様に提供してきたイノベーションを誇りに思っており、お客様が Spanner で構築する革新的なソリューションを楽しみにしています。このイノベーションはまだ始まったばかりであり、2026 年にはさらに多くの魅力的な機能の提供が予定されていることは言うまでもありません。

Spanner の独自性や使用例について詳しくは、こちらをご覧ください。

また、90 日間無料で、あるいは月額わずか 65 米ドルから、中断を伴う再構築やダウンタイムなしでビジネスの成長に合わせて拡張できる、プロダクションレディなインスタンスをお試しください。

- グループプロダクトマネージャー、Shubhankar Chatterjee

- グループプロダクトマネージャー、Piyush Mathur

AlloyDB のマネージド接続プーリングのご紹介 - 規模の拡大と接続の高速化

Thu, 29 Jan 2026 03:00:00 +0000

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

AlloyDB for PostgreSQL は、要求の厳しいエンタープライズワークロード向けに設計されたフルマネージドデータベースサービスです。PostgreSQL の使いやすさと堅牢性を Google Cloud の高度なテクノロジーと組み合わせることで、卓越したパフォーマンス、スケーラビリティ、高可用性を実現します。

しかし、アプリケーションが増加し、ユーザー負荷が強まると、「データベース接続の効率的な管理」という、また別の要素の重要性が高まります。非効率的な接続処理がボトルネックになり、AlloyDB が本来発揮すべきパフォーマンスとスケーラビリティが損なわれる可能性があるからです。この状況を踏まえ、この課題に正面から取り組むための新機能、マネージド接続プーリングを発表いたしました。

表面化しないデータベース接続費用

多くのアプリケーションアーキテクチャ、特にウェブアプリケーションやサーバーレス関数のような短時間での頻繁なやり取りが発生するアプリケーションアーキテクチャでは、リクエストごとに新しいデータベース接続を開き、後で閉じるというパターンが一般的です。このアプローチはわかりやすいように思えますが、特に大規模な運用では、表面化しない多額の費用が発生します。

新しいデータベース接続を頻繁に確立する場合（ウェブアプリやサーバーレス関数では一般的）、リソースを大量に消費します。新しい接続を確立するたびに、ネットワークハンドシェイク、Transport Layer Security（TLS）ネゴシエーション（状況に応じて）、認証、セッションの初期化、リソース割り当てが行われるため、レイテンシが増加し、サーバーの CPU とメモリが消費されます。数百または数千の同時リクエストでこうした処理が増え続けると、この接続オーバーヘッドの累積的な影響は相当なものになります。

パフォーマンスの低下: 接続の設定と切断に費やされる時間が、アプリケーションの応答時間の増加に直結します。アプリケーションが新しい接続を待ってからクエリを実行するため、ユーザーのインタラクションに遅延が生じます。
リソースの枯渇とスケーラビリティのボトルネック: データベースは、クライアント接続ごとにリソースを割り当てます。アイドル状態の接続でもメモリと CPU を消費します。これは接続の数だけの問題ではありません。作成と破棄が絶えず繰り返されることで非効率が生じ、貴重なリソースが消費されて、データベースのスケーリングが制限されてしまいます。
信頼性に関する懸念: トラフィックが急増すると接続も急増し、結果的にサーバーが過負荷になり、パフォーマンスの低下、接続のタイムアウト、さらにはサーバーの停止につながりかねません。

アプリケーションフレームワーク内にはクライアントサイドの接続プーリングライブラリが存在しますが、分散システムやマイクロサービスアーキテクチャ全体でこれらを効果的に管理しようとすると、複雑性が増大する可能性があります。多数の独立したクライアントプール全体で一貫した構成、動作、効率的なリソース利用を確保することは、簡単なことではありません。このような環境では、一元的なサーバーマネージドアプローチが、より堅牢かつシンプルなソリューションとなります。

AlloyDB マネージド接続プーリングの概要

これらの課題にマネージド環境内で直接対処するのが、AlloyDB for PostgreSQL のマネージド接続プーリングです。これは、データベース接続の管理と、アプリケーションのパフォーマンス、スケーラビリティ、信頼性の向上を目的として最適化された統合ソリューションです。このたび、AlloyDB for PostgreSQL のマネージド接続プーリングの一般提供が開始されました。

接続プーリングの仕組み

リクエストごとに新しい接続を作成するのではなく、すぐに使用できるアクティブなデータベース接続のキャッシュをプーラーが維持します。アプリケーションが接続をリクエストすると（プーラーの専用ポート 6432 を経由）、プーラーは費用のかかる設定プロセスを行わずに、プールから利用可能な接続を割り当てます。アプリケーションが終了すると、接続は閉じられるのではなく、プールに戻されて再利用されます。

「マネージド」の利点

重要な点は、これが単なる接続プーリングソリューションではなく、AlloyDB によって管理されるマネージドソリューションであることです。こうしたソリューションには、次のような利点があります。

緊密な統合: プーリングメカニズムは AlloyDB サービスに直接組み込まれており、データベースインスタンスと並行して効率的に実行されます。
運用の簡素化: AlloyDB が接続プーラーの設定、構成、パッチ適用、メンテナンスを処理します。PgBouncer などの外部ツールを使用する場合に必要な、個別のプーリングインフラストラクチャのデプロイ、管理、スケーリングという運用負担を負わずに、さまざまなメリットを得られます。この点は、AlloyDB の管理タスクを自動化し、データベース管理を簡素化するという Google Cloud の基本理念と完全に一致しています。
最適化されたパフォーマンスとセキュリティ: プーラーは AlloyDB 環境と Google Cloud のネットワークに統合されているため、プーラーとバックエンドデータベースプロセスの間の通信が高度に最適化され、レイテンシを最小限に抑えられます。接続は、Google Cloud のインフラストラクチャの堅牢なセキュリティポスチャーによって保護されます。
信頼性の向上: マネージドプーラーは、高可用性（HA）構成など、自身が実行される AlloyDB インスタンスの基盤となる信頼性機能を引き継ぎます。

つまり、Google は、接続プーリングを AlloyDB のマネージド機能として統合することで、従来の PostgreSQL 接続モデルの基本的なスケーリングの課題に直接対処し、スケーラビリティと復元力の高いアプリケーションをこれまで以上に簡単に構築できるようにしています。

規模、信頼性、パフォーマンスの向上

AlloyDB でマネージド接続プーリングを有効にすると、アプリケーションにも次のような具体的なメリットがもたらされます。

規模とパフォーマンスの向上: 接続を効率的に再利用することで、インスタンスの能力をさらに引き出すことができます。AlloyDB は、新しいマネージド接続プーリング機能により、標準的な接続と比較して 3 倍以上のクライアントを処理し、トランザクションスループットを最大 5 倍向上させます。
接続急増時の信頼性の向上: プールは、トラフィックの急増時に既存の接続でリクエストを迅速に処理してバックエンドの過負荷を防ぐ、緩衝器の役割を果たします。これにより、ピーク負荷時にも安定性が維持され、接続エラーを防止できます。プールが一時的に枯渇した場合も、プーラーは受信リクエストを適切にキューに入れることができるため、アプリケーションの復元力が向上します。
一時的な接続のレイテンシの短縮: 短時間での頻繁な接続（ウェブ、マイクロサービス、サーバーレスでは一般的）の接続設定のオーバーヘッドを排除し、クエリの実行を高速化して、エンドユーザーの応答時間を大幅に改善します。

さまざまなアプリケーションのニーズと動作に対応するため、AlloyDB のマネージド接続プーリングでは、構成可能なプーリングモードを通じて柔軟性を高めています。

トランザクションモード（デフォルト）: トランザクションごとに接続を割り当て、可能な限りの再利用とスケーラビリティの最大化を実現します。短時間のトランザクションが大量にある場合に最適です。トランザクションスコープ外の SET、セッションアドバイザリロック、LISTEN、WITH HOLD カーソル、プロトコルレベルの準備済みステートメント（max_prepared_statements を介して、名前の付いた準備済みステートメントを使用）などのセッション固有の機能との互換性はありません。
セッションモード: クライアントのセッション全体に接続を割り当て、PostgreSQL のすべての機能との完全な互換性を確保します。セッション状態の永続性を必要とする長期セッションやアプリケーションに適していますが、接続の多重化は控えめになります。

どちらのモードを選択しても、トレードオフが伴います。トランザクションモードでは最大のスケーラビリティとリソース効率が優先される一方、セッションモードではすべてのセッション機能との完全な互換性が優先されます。AlloyDB では、構成時にアプリケーションの要件に最適なモードを簡単に選択できます。

次の表は、マネージド接続プーリングを有効にすることで得られる主な改善点をまとめたものです。

指標	マネージドプーリングなし	マネージドプーリングあり（標準）	メリット
1 分あたりのトランザクション数	ベースライン（1 倍）	最大 5 倍	同じインスタンスでのスループットが向上
最大同時接続数	ベースライン（1 倍）	3 倍超	より多くのクライアント同時接続をサポート
接続レイテンシ	高（設定のオーバーヘッド）	低（接続の再利用）	一時的な接続に対する応答が高速化
信頼性（負荷の急増）	過負荷に弱い	復元力が高く、急増に対応可	高負荷時の安定性が向上

お客様事例: UKG

人事、給与、従業員管理ソリューションの大手プロバイダである UKG は、AlloyDB のマネージド接続プーリングを先行して導入しました。UKG は、数百万人ものユーザーが日々使用するミッションクリティカルな People Fabric アプリケーションをサポートするために、大規模な環境、大量のトランザクション、変動する需要に対応できるデータベースを必要としていました。

「AlloyDB を選んだ理由は、そのパフォーマンス、信頼性、管理しやすさにあります。AlloyDB 独自のアーキテクチャでは、クラスタごとにパックできるデータベースの数が、他の Postgres マネージドサービスに比べてはるかに多くなります。しかし、容量が大きくなったことで、ユーザーやアプリケーションからのデータベース接続が増加し、Postgres の通常の接続上限について不安がありました。マネージド接続プーリングの先行導入で Google と連携できたことを嬉しく思います。この重要な機能のおかげで、世界中のお客様に最高のパフォーマンスと低レイテンシを保証できるようになりました。また、使用量がピークに達したときでも、接続の制約を心配することなく、同じサーバーで自由に規模を拡大できます。」- UKG、シニアプリンシパルアーキテクト兼 People Fabric チーフアーキテクト、Jeff Bogenschneider 氏

UKG の事例は、最先端の要求の厳しいワークロードをサポートするうえで、効率的な接続管理が果たす役割の重要性を浮き彫りにしています。UKG は、マネージド接続プーリングを活用することで、動的かつ予測不可能な負荷パターンでも、AlloyDB インフラストラクチャの堅牢性と応答性を維持しています。HR テクノロジー分野の主要プロバイダでこれだけの効果を発揮していることから、次世代のインテリジェントな大規模アプリケーションの強化に AlloyDB が適していることがわかります。

マネージド接続プーリングを使ってみる

マネージド接続プーリングの大きな利点の一つは、そのシンプルさであり、有効にする手順も簡単です。

Google Cloud コンソールでマネージド接続プーリングを有効にします。新しい AlloyDB 読み取りプールインスタンスを作成するとき、または既存のプライマリインスタンスや読み取りプールインスタンスを編集するときに、チェックボックスを探してください。gcloud コマンドラインツールのフラグまたは AlloyDB API を使用して有効にすることもできます。
標準の PostgreSQL ドライバとデータベース認証情報を使用してアプリケーションを接続します。アプリケーションのターゲットを、デフォルトの PostgreSQL ポート 5432 ではなく、接続プーラーの専用ポート 6432 に設定するだけです。AlloyDB Auth Proxy または言語コネクタを使用している場合は、変更は必要ありません。
最後に、インスタンスの作成時に、目的のプーリングモード（トランザクションまたはセッション）やプールサイズの上限などのオプションを簡単に構成できます。これらのオプションは、Google Cloud コンソール、gcloud、または API を使用して変更できます。

詳細な手順、高度な構成パラメータ、モニタリングのガイダンス、ベストプラクティスについては、公式のドキュメントをご覧ください。

さらに進化した AlloyDB

AlloyDB のマネージド接続プーリングは単なる新機能ではなく、AlloyDB をより幅広いアプリケーションで利用しやすく、効果的にする基本的な機能です。データベース接続をインテリジェントに管理することで、一般的なパフォーマンスとスケーラビリティのボトルネックに直接対処し、アプリケーションが AlloyDB のパフォーマンスと堅牢なアーキテクチャを最大限に活用できるようにします。

この機能のメリットを体験してみたいとお考えなら、今すぐ AlloyDB インスタンスでマネージド接続プーリングを有効にしましょう。

詳細: https://cloud.google.com/alloydb/docs/configure-managed-connection-pooling
AlloyDB を初めてご利用の場合: 無料トライアルはこちら

- シニアプロダクトマネージャー、Emir Okan

- ソフトウェアエンジニア、Haoli Du

データベース

データベースの新機能: エージェントの未来を強化

データスタックのあらゆるレイヤに AI を組み込む

レイクハウスのインテグレーションで閉ざされた環境を解消

オープンデータとマルチクラウドの柔軟性への取り組み

運用から分析へ: Spanner Graph と BigQuery Graph による統合ソリューション

運用ワークロード向けの Spanner Graph

分析ワークロード向けの BigQuery Graph

統合ソリューションとしての Spanner Graph と BigQuery Graph

グラフに関するあらゆるニーズに対応する統合ソリューション

Spanner Graph と BigQuery Graph を今すぐ使ってみる

Spanner Omni を発表：あらゆるインフラで Google のイノベーションを活用

Spanner Omni が重要である理由

Spanner Omni の紹介

Spanner Omni を支える技術

アクセス方法

Agentic Data Cloud の新機能：「System of Action」を実現

ユニバーサル コンテキスト エンジンでエージェントを強化

エージェント ファーストな開発者体験

エージェント スケールに合わせて構築されたクロス クラウド基盤

未来の自動化に向けて

System of Action で成功を築く

BigQuery Graph のご紹介: データに潜む関係性を明らかに

業界を問わず企業が直面するグラフ導入の課題

BigQuery Graph の主なユースケース

実際の BigQuery Graph の活用事例

BigQuery Graph の使い方

準備ができたら

エージェントが自然言語を AlloyDB、Cloud SQL、Spanner のクエリに変換できるように QueryData がサポート

エージェント システムの可能性: インテントからアクションへ

開発者のジレンマ: データベースを使用するエージェントに対する自然言語が難しい理由

精度のギャップを理解する

QueryData はほぼ 100% の精度をどのように実現するか

クエリの決定論的なセキュリティ

品質向上とツール統合のための使いやすさ

QueryData で今すぐ構築できるもの

次のステップ

Spanner の完全に相互運用可能なマルチモデル データベースを使用した実際の成功事例

1. 不正行為の検出

DANA: 急速に拡大する顧客ベースに対するマネー ロンダリング対策

Palo Alto Networks: SaaS ID のアクセス グラフ

Verisoul.ai: リアルタイムの偽ユーザー検出

2. レコメンデーション エンジン

True Digital Group: AI 検索を統合

3. ハイブリッド検索

Rogo: 財務ワークフローの自動化

Inspira: リーガル インテリジェンスのストリーミング

4. 自律型ネットワーク運用

今後の展望

ID.me、1 億 6,000 万ユーザーに対応するスケーリングと運用リスクの軽減を同時に達成

追いつかないスピードで増える需要

1 億 6,000 万人の大切なお客様と当社のための新しいデータベース

AI トレーニングの目的は . . . AI との戦い？

1 つのログインであらゆるシステムにスムーズに対応

エージェント型 AI の時代を支える Spanner のマルチモデルによる強み

相互運用性を備えたマルチモデル データベースの力

Spanner がもたらす AI 時代の優位性

AI をグローバル規模で成功へと導く企業

Manhattan Associates、Google Cloud データベースで 1 日に 10 億件以上の API 呼び出しを処理

モノリシックな基盤からクラウドのレジリエンスへ

あらゆるトランザクションにレジリエンスとスピードを組み込む

基盤をモダナイズ: データベースからインテリジェンスへ

かつてないスピード、規模、運用効率を実践

詳細

読み取りのスケーラビリティを合理化する Cloud SQL の自動スケーリングを備えた読み取りプール

読み取りプールを使用する理由

読み取りプールの自動スケーリングでスケーリングが容易に

Cloud SQL が読み取りプールで可用性を向上させる仕組み

自動スケーリングを備えた読み取りプールの有効化と使用

使ってみる

Memorystore for Valkey 9.0 の一般提供を開始: 次世代のキャッシュ保存

スケーリング時のパフォーマンス: 妥協のないスピード

スループットのメカニズム: パイプライン処理

開発者からの新たな要望に対応

エンタープライズ対応の機能

シームレスなアップグレード

今後の展望

さっそく構築を始める

Google Cloud のお客様が構築した優れたソリューション（2 月版）: Team USA のテック、通信会社のデータ刷新、ゴールデン ステートの「G.O.A.T.T.」

PayPal 史上最大規模のデータ移行が生成 AI イノベーションの基盤に

ユニバーサルコンテキストエンジンでエージェントを強化

エージェントファーストな開発者体験

エージェントスケールに合わせて構築されたクロスクラウド基盤

エージェントシステムの可能性: インテントからアクションへ

Spanner の完全に相互運用可能なマルチモデルデータベースを使用した実際の成功事例

DANA: 急速に拡大する顧客ベースに対するマネーロンダリング対策

Palo Alto Networks: SaaS ID のアクセスグラフ

2. レコメンデーションエンジン

Inspira: リーガルインテリジェンスのストリーミング

相互運用性を備えたマルチモデルデータベースの力

Google Cloud のお客様が構築した優れたソリューション（2 月版）: Team USA のテック、通信会社のデータ刷新、ゴールデンステートの「G.O.A.T.T.」

Iceberg データに高速かつ低レイテンシのサービングプラットフォームが必要である理由

ユニバーサルリバース ETL: すべてのレイクハウスのデータを提供

Gartner® の Critical Capabilities レポートの軽量トランザクションユースケースで Google（Spanner）が第 1 位を獲得

デモ: ローカルコードからマネージドデータへ

サードパーティエージェントのサポート

エンタープライズレベルの安全性の水準を引き上げる