データベース

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 0x7fdfb42462e0>), ('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 0x7fdfb9c4cfd0>), ('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 0x7fdfb9099ee0>)])]>

読み取りエンドポイントの 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 0x7fdfb9099d60>)])]>

このコマンドは、ノードが 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 0x7fdfa568fc10>)])]>

使ってみる

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

読み取りプールに関する 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 0x7fdfba9e2b20>)])]>

次に、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 0x7fdfba9e2e80>)])]>

条件付き削除（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 0x7fdfb99d1520>)])]>

プロセス 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 0x7fdfb8dd65b0>)])]>

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

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

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

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

新しいフィルタオプション	説明
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 0x7fdfb9cbd9d0>)])]>

クラスタ環境のデータベース構成では、単一のスケーラブルなクラスタインスタンス内で、さまざまなサービスや環境に対してデータを効率的にパーティショニングできます。これにより、クラスタの大規模なスケールを活用しながら、論理的組織に基づき複数のデータベースを使用することが可能となります。この機能を使えば、現在、クラスタ化していないレガシーの 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

Fastweb + Vodafone: Spanner と BigQuery でデータワークフローを再定義

Wed, 28 Jan 2026 03:00:00 +0000

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

編集者注: イタリアの大手通信プロバイダである Fastweb + Vodafone は、チャネル全体でより迅速かつパーソナライズされたカスタマーエクスペリエンスをサポートする Customer 360 プラットフォームを構築しました。また、Spanner、BigQuery、Gemini などの Google Cloud サービスを使用してサービングレイヤとガバナンスを再構築することで、アーキテクチャを簡素化し、AI を活用したエンジニアリングワークフローを導入しました。Fastweb + Vodafone は現在、組織全体にリアルタイムの分析情報を提供しており、将来的に AI エージェントのユースケースを拡大する準備を進めています。

2025 年の Swisscom による Vodafone Italy の買収を経て、2026 年 1 月の正式な合併を迎えるにあたり、お客様へのサービス提供方法を見直す機会が訪れました。

イタリアの大手通信プロバイダである当社は、モバイル、ブロードバンド、デジタルチャネルにおいて、タイムリーでパーソナライズされたエクスペリエンスを提供することを目指しています。私たちの仕事は、当社のビジネスに関わるすべての人が必要なときに必要な顧客インサイトにアクセスできるようにすることです。こうしたインサイトは、数千ものソースからのデータを統合し、リアルタイムで利用できるようにする堅牢な Customer 360 プラットフォームに支えられています。

両社はすでに、Google Cloud、特に BigQuery を活用した顧客データワークフローのモダナイズを進めていました。しかし、エコシステムを組み合わせたことで、既存のセットアップの限界が明らかになりました。このアーキテクチャは、想定以上に多くのメンテナンスが必要で、統合した組織に必要な柔軟性もありませんでした。顧客データの提供と管理の方法を見直す時期が来ていたのです。

単一のツールではなく、コネクテッドプラットフォームを選択

Fastweb + Vodafone に必要なものを改めて見直すと、単一のツールを求めていないことは明らかでした。私たちが求めていたのは、運用上の負担を増やすことなく、リアルタイムのサービス提供、より強力なガバナンス、AI を活用した新しいワークフローをサポートできる、コネクテッドプロダクトスイートでした。

図 1: Customer 360 サービングレイヤのアーキテクチャ図

ウェアハウス側では BigQuery をすでに導入しており、コア分析ワークロードを処理できていました。当社に欠けていたのは、アーキテクチャを簡素化しつつ、BigQuery のスピードと柔軟性に対応できるサービングレイヤでした。また、スタック全体での緊密な統合により、インサイトの可視化や AI 導入をより容易に実現したいとも考えていました。

Google Cloud では、これらの機能がすべて一元化されており、各プロダクトがネイティブに統合されているため、当社にとって最適な選択肢でした。システム接続に費やす時間を減らすことができ、ビジネスで実際に必要とされる機能の構築に注力できるようになりました。

Spanner がオーバーヘッドなしでサービングを加速

あらゆるチャネルに正確な顧客データをリアルタイムで提供するには、通信トラフィックに遅れを取らないサービングレイヤが必要でした。その解決策は Spanner でした。Spanner は、低レイテンシの読み取り、水平方向のスケーラビリティ、高可用性を実現し、運用オーバーヘッドがゼロのフルマネージド環境を提供します。

Spanner と BigQuery のネイティブなインテグレーションは、大きな変化をもたらしました。Spanner を導入する前は、データウェアハウスのデータをダウンストリームシステムに移動するためだけに構築したカスタムレイヤをいくつか使用していました。しかし、Spanner と BigQuery の直接的な相互運用性により、その複雑さのほとんどが解消されました。Spanner をフロントエンドのサービングレイヤとして採用したことで、10 個のアプリケーションをわずか 2 週間で移行できました。

また、Spanner はワークフローのモニタリングとメンテナンスの方法も変えました。4 つの異なるモニタリングプロセスが 1 つのビューに統合されたことで、トラブルシューティングと最適化が大幅に迅速化されました。また、Apigee を使用して Spanner データをコールセンター、デジタルチャネル、パートナーシステムに公開したことで、改善の効果はエンジニアリング部門だけでなく、組織全体にまで広がりました。

数千のデータフローを理解する

サービングレイヤとして Spanner を導入した後の次の課題は、Fastweb + Vodafone のデータプラットフォームを支える数千ものバッチ処理とリアルタイムの取り込みフローを理解することでした。これらのパイプラインにおけるデータの流れを理解することは、品質、コンプライアンス、日々のエンジニアリングに不可欠です。私たちには、以前のソリューションよりも高速で、はるかに直感的なものが必要でした。

Spanner のマルチモデル機能がその基盤となりました。

Spanner Graph を使用することで、プラットフォームの実際の動作を反映したリネージのマッピングが可能となりました。具体的には、どのテーブルが特定のジョブを駆動するのか、変換がどのようにカスケードするのか、依存関係がどこにあるのかをマッピングできるようになりました。その後、ベクトル検索と全文検索を追加し、より豊富な検出レイヤを実現しました。これにより、大規模かつ複雑なエコシステムにおいても、結果を迅速に確認することが容易になりました。

これらの機能を組み合わせることで、私たちが求めていたガバナンスエクスペリエンスを実現できました。精度が向上しただけでなく、エンジニアやアナリストの作業負担も格段に減ったのです。

図 2: Spanner Graph モデルにより、複雑なデータリネージのスケーラブルでナビゲートしやすいビジュアリゼーションを迅速に構築し、データガバナンスを改善

ドキュメント作成を簡素化

私たちはまた、組織内の大規模かつ多様なコードベース全体でよりスムーズに開発を行いたいと考えていました。多くのサービス、特に時間の経過とともに進化してきた古いシステムでは、ドキュメントが不十分な状態でした。Gemini は、こうしたギャップを埋めるのに役立ちました。

Gemini を使用すると、コードから直接、わかりやすいドキュメントを生成できるため、手作業の時間を大幅に節約できます。この出力をベクトルエンベディングとして Spanner に保存することで、プラットフォームとともに成長する検索可能なナレッジベースを作成できます。

この知識をさらに使いやすくするために、Gemini を活用したチャットインターフェースを構築しました。デベロッパーは、関数や変更がシステム全体にどのように影響するかなどについて、自然言語で質問でき、コンテキストに応じた回答を数秒で得られます。これは、コードベースを探索するはるかに直感的な方法であり、レガシーロジックを解読したり、専門家に問い合わせたりする時間を短縮できます。

図 3: Gemini と Spanner によるコードのドキュメント化の拡張と検索

この AI を活用したワークフローは、現在では当社の開発プロセスの一部となっています。これにより、オンボーディングが迅速化されるほか、システムが進化する中でも生産性を向上できるスケーラブルな手法が得られます。

ビジネスのスピードで進化するエンジニアリング

Google Cloud サービスで Customer 360 プラットフォームを再構築したことで、Fastweb + Vodafone の業務の仕組みは大きく変わりました。

ワークフローのモニタリングが簡素化され、パイプラインがより効率的になり、リアルタイムのサービス提供が一般的になりました。

この取り組みの成果は、ビジネス全体に及んでいます。コールセンターでは、より完全で最新の顧客情報を確認できるようになり、デジタルチャネルでは、カスタム　インテグレーションなしでも整合性のあるデータを利用できるようになりました。また、パートナーは、Apigee を通じて必要な情報に低レイテンシでアクセスできるようになりました。これらすべてを組み合わせることで、よりスムーズでパーソナライズされたカスタマーエクスペリエンスを実現しています。これは、このプロセスの開始時に私たちが思い描いていた姿そのものです。

この取り組みはまだ始まったばかりです。現在は、Spanner Graph の機能を活用することで、世帯単位の分析やソーシャルインデックスを通じて顧客との関係をより深く理解する方法を模索中です。また、分析や意思決定の向上を支援する AI エージェントの可能性もさらに高まると考えています。

Google Cloud は、当社のエンジニアリングを簡素化しただけでなく、組織全体の運営方法そのものを変えました。

詳細:

グローバル規模のワークロードに対応するフルマネージドリレーショナルデータベースである Spanner と、Spanner Graph の優れた機能をご確認ください。
組み込みのパフォーマンスとスケーラビリティで分析を簡素化する BigQuery の活用方法をご紹介します。
Gemini for Google Cloud を使用して、エンジニアリングワークフローに AI アシスタンスを導入しましょう。

- Fastweb + Vodafone、IT AI 導入およびプラットフォームエンジニアリングリード、Vincenzo Forciniti 氏

Firestore の新しい高度なクエリエンジンでアプリケーションを強化

Mon, 26 Jan 2026 02:00:00 +0000

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

価値あるデータベースの特徴は、格納されているデータを簡単にクエリできることです。これにより、デベロッパーはカスタマイズされた複雑なユーザーエクスペリエンスをアプリケーション内で構築できます。先週、Google Cloud のエンタープライズクラスのスケーラブルなドキュメントデータベースである Firestore が大きく進化しました。高度なクエリエンジンが導入され、より洗練されたアプリケーションを構築できるようになりました。

Firestore ネイティブモードの一部として利用できるこの強力なエンジンは、パイプラインオペレーションと呼ばれる新しいクエリ機能を 100 個以上備えています。これらの機能はプレビュー版として公開されており、複雑なクエリをデータベース内で直接効率化します。これに加えて、インデックス作成の厳密な制御のリリースや、Query Explain や Query Insights などのオブザーバビリティツールの更新により、パフォーマンスのきめ細かい制御が可能になりました。これらの優れた機能はすべて、Firestore Enterprise エディションで利用できます。このエディションは料金モデルの透明性が高く、費用削減を図ることも可能です。これらの点すべてが、運用のオーバーヘッドを削減しながら、多くの次元にわたってデータをクエリ、変換、フィルタできる、表現豊かな高パフォーマンスアプリケーションの構築に役立ちます。同時に、Firestore 独自のサーバーレス基盤、マルチリージョンレプリケーション、事実上無制限のスケーラビリティのメリットを享受できるため、データベース管理の複雑さから解放され、イノベーションに専念できます。

Firestore は、60 万人を超える活気あるデベロッパーコミュニティを持ち、そのシンプルさが長年にわたり高く評価されてきました。2019 年には、ネイティブモードの Firestore Standard エディションが、自動生成されたインデックスを使用して高パフォーマンスを保証するシンプルなクエリインターフェースによってコラボレーションアプリケーションの開発を効率化しました。しかし、この簡素化されたクエリエンジンは、クエリの実行においてインデックス作成に大きく依存し、多くの場合、アプリケーションのライフサイクル全体で事前計画を必要とします。Enterprise エディションに高度なクエリエンジンが導入されたことで、デベロッパーはインデックスが明示的に存在するかどうかに関係なく、表現豊かなアプリケーションを構築できるようになりました。これは特に、e コマース、インタラクティブゲーム、コンテンツ管理、高度なユーザーパーソナライズなどの要求の厳しいソリューションに適しています。改良されたクエリエンジンにより、パイプラインオペレーションの作成が容易になります。複雑な集計、配列に対する直接的なクエリ、高度な文字列照合機能、詳細なフィルタリングオプションのサポートなど、洗練された新しいステージと式が用意されています。

新しいクエリエンジンとパイプラインオペレーションのエクスペリエンス

これを実現するため、Google は Firestore の既存の SDK を更新し、パイプラインオペレーションのサポートを拡大しました。現在は、集計、グループ化、フィルタリングなどの重要なタスクのために、多数のステージをスムーズに連結できるようになりました。クエリの実行にインデックスが必須とならないため、パフォーマンスを最適化するためにインデックスを作成するタイミングを自由に決められます。パイプラインオペレーションの例を見てみましょう。

注: この例は、Firestore のデータモデルと既存のクエリ方法について理解していることを前提としています。

ユーザーがレシピにハッシュタグを追加できる既存の料理レシピアプリケーションで、人気のあるハッシュタグを特定するとします。レシピ本文のような重要なデータについては、レシピをいくつかのフィールドを持つドキュメントとして表せます。ハッシュタグは文字列のみで表せるため、レシピドキュメントに文字列の配列として直接追加できます。

code_block: <ListValue: [StructValue([('code', '{\r\n title: "My recipe",\r\n instructions: "Cook the ingredients",\r\n authorId: "SomeAuthorID",\r\n hashtags: ["easy", "high protein", "low carb"],\r\n ...\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb7b537f0>)])]>

Firestore ユーザーは、既存のコアオペレーションを使用して、レシピ内で特定のハッシュタグをクエリできます。しかし、クエリ中にドキュメント内から配列データを抽出して集計する直接的な方法は、パイプラインオペレーション以前にはありませんでした。

パイプラインオペレーションを使用すると、配列を直接「ネスト解除」できます。これにより、人気のあるハッシュタグを簡単に特定してユーザーに提案できます。JavaScript を使用してこれを実装する方法の例を以下に示します。

code_block: <ListValue: [StructValue([('code', '// ハッシュタグを人気順で 10 個取得する。\r\nconst snapshot = await db.pipeline()\r\n\u200b\r\n // レシピドキュメントのコレクションから始める。\r\n .collection("recipes")\r\n\u200b\r\n // ドキュメントを `hashtags` フィールドのみに制限する。\r\n .select("hashtags")\r\n\u200b\r\n // `hashtags` 配列内の各タグをネスト解除して独自のドキュメントにする。\r\n .unnest(field("hashtags").as("tagName"))\r\n\u200b\r\n // 複数のレシピにわたり各タグのインスタンス数をカウントし、\r\n // tagName ごとに、tagName を共有するドキュメントを 1 つのドキュメントに\r\n // 統合する。\r\n .aggregate({\r\n accumulators: [countAll().as("tagCount")],\r\n groups: ["tagName"]\r\n })\r\n\u200b\r\n // 結果のハッシュタグをカウントで並べ替える。\r\n .sort(field("tagCount").descending())\r\n\u200b\r\n // クエリ結果を上位 10 個のハッシュタグに制限する。\r\n .limit(10)\r\n\u200b\r\n .execute()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb7b53d30>)])]>

また、Firestore Enterprise エディションでは、より幅広いインデックスタイプ（単一フィールド、複合、スパース、非スパース、一意のインデックスなど）がサポートされており、クエリのパフォーマンスをさらに最大化できます。さらに、インデックスを作成するタイミングを制御できるため、Standard エディションの自動単一フィールドインデックスと比較して、全体的な書き込みパフォーマンスとストレージ使用率が向上します。これにより、書き込みオペレーション中のインデックスファンアウトを軽減できます。

インデックス作成は完全にカスタマイズ可能であるため、Enterprise エディションには、Query Explain と Query Insights という高度なオブザーバビリティツールも用意されています。これらのツールは、デベロッパーがインデックス不足を特定して、クエリを確認、最適化できるように特別に構築されています。Query Explain を使用すると、デベロッパーはクエリをプロファイリングして、クエリプランナーの詳細を包括的に把握するとともに、実行の統計情報を確認できます。これには、課金情報などの重要なデータや、クエリの実行パスに関するシステムレベルの詳細な可視性が含まれます。

Query Explain でプロファイリングすることで、クエリでインデックスが使用されているかどうかを確認し、その合計実行指標を分析する。

これに加えて、Query Insights では、レイテンシが高いクエリや頻繁に実行されているクエリがないかどうかを継続的にモニタリングし、調整が必要かどうかを検討できます。Query Insights ダッシュボードを利用することで、インデックスを導入すればパフォーマンスの向上が可能なクエリを特定できます。

Query Insights を活用して、データベースで特にレイテンシが高いクエリや、特に頻繁に実行されているクエリを特定し、スキャンされているインデックスエントリの数に基づいてインデックスの作成が必要かどうかを評価する。

ご利用中の Firestore の移行

Firestore を初めてご利用の場合、Firestore Enterprise エディションのデータベースを作成するだけで簡単に始めることができます。Firestore をすでにご利用中のデベロッパーが Firestore パイプラインオペレーションに移行するのも簡単です。統合されたインポート / エクスポートサービスを使用して、Firestore Standard エディションのデータベースから、新たにプロビジョニングされた Enterprise エディションのデータベースにデータを移行するだけです。重要な点として、Enterprise エディションでは下位互換性が維持されているため、Firestore コアオペレーションの既存のアプリケーションコードを保持できます。高度な機能を活用する適切なタイミングが来たら、次の方法でコアオペレーションのコードをパイプラインオペレーションに変換できます。

code_block: <ListValue: [StructValue([('code', 'const query = db.collection("recipes").where("authorId", "==", user.id);\r\n\u200b\r\n// クエリをパイプラインに変換する\r\nconst pipeline = db.pipeline.createFrom(query);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb7b53c10>)])]>

その後、新しいパイプライン機能をすぐに使い始めることができます。

code_block: <ListValue: [StructValue([('code', '// 最後のスニペットから\r\nconst pipeline = db.pipeline.createFrom(query);\r\n\u200b\r\nconst snapshot = pipeline\r\n .where(field("rating").greaterThan(4))\r\n .execute();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb7b53c40>)])]>

予測可能な料金と最適化された費用

Firestore Enterprise エディションでは、改善された透明性の高い料金モデルで費用を管理できます。データベースに対して実行されるすべての読み取りオペレーションと書き込みオペレーションについて、ドキュメントと関連インデックスエントリのサイズに基づいて課金されます。この新しいアプローチにより、4 キビバイト未満のドキュメントに対する読み取りオペレーションの実行時に、費用を最大 86% 削減できる可能性があります。

リアルタイムリッスンクエリの更新は、発生した時点で個別に測定、課金されます。さらに、初期費用は不要で、データベースクラスタの容量計画の誤りやデータベースシャーディングの非効率性から生じる潜在的な費用もありません。ストレージ使用量については、高可用性のための複製コピーも含め、実際に使用した容量に対してのみ課金されます。Firestore を初めてお試しになる場合は、Enterprise エディションに十分な無料枠が含まれているため、簡単に始めることができます。

Firestore パイプラインオペレーションを使ってみる

Enterprise エディションにおいて、柔軟なデベロッパーエクスペリエンスを実現する高度なクエリエンジンは、Firestore ネイティブモードと Firestore MongoDB 互換モードのどちらからでもアクセスできます。このため、デベロッパーは Firestore と MongoDB の両方のデベロッパーコミュニティから、既存のライブラリやツールを最大限に活用できます。新しい Firestore Enterprise エディションのネイティブモードで新規データベースを作成することで、Firestore パイプラインオペレーションのプレビュー版を今すぐご利用いただけます。パイプラインオペレーションの開始方法の詳細については、ドキュメントをご覧ください。

Enterprise エディションは、初期費用が不要で、十分な無料枠を用意しています。ぜひご利用ください。詳細については、https://cloud.google.com/products/firestore をご覧ください。

- Google Cloud、グループプロダクトマネージャー Minh Nguyen

- Google Cloud、スタッフソフトウェアエンジニア Joseph (JD) Batchik

新しい書き込み最適化機能により Cloud SQL for MySQL の書き込みパフォーマンスを強化

Mon, 19 Jan 2026 01:40:00 +0000

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

書き込み負荷の高いワークロード向けに MySQL インスタンスを調整することは、長年にわたるエンジニアリング上の課題です。このたび、Cloud SQL for MySQL Enterprise Plus エディションに、書き込み最適化機能が追加されました。これは、リアルタイムのワークロードとインフラストラクチャの指標に基づいて MySQL の構成を調整する一連の自動化機能です。これにより、手動操作なしで書き込みレイテンシが短縮され、スループットが向上します。

Enterprise Plus エディションのすべてのインスタンスで、この機能がデフォルトで有効になっています。この投稿では、基盤となる最適化について詳しく説明し、パフォーマンスの向上を測定するための再現可能なベンチマークを提供します。

Cloud SQL for MySQL の書き込み最適化機能の内容

書き込み最適化機能には 5 種類の最適化が含まれています。これらはすべて、MySQL のパラメータ、フラグ、データ処理を自動的に調整することにより、インスタンスとワークロードのニーズに基づいて書き込みパフォーマンスを最適化します。書き込み最適化機能の各コンポーネントの仕組みについて、もう少し詳しく見てみましょう。

特長	説明
適応型パージ	Cloud SQL は、innodb_purge_threads を動的に調整して、通常のデータベースメンテナンスオペレーションよりもユーザーワークロードを優先します。
適応型 I/O の上限	Cloud SQL は、I/O パラメータ（具体的には innodb_io_capacity と innodb_io_capacity_max）を動的に調整します。この調整は、ワークロード需要の変動に直接対応して行われ、トラフィックの急増時に I/O ボトルネックが発生するのを防ぎます。
スケーラブルなシャーディング I/O	Cloud SQL は、複数のミューテックスに負荷を分散することで I/O のシャーディングを実装し、I/O スループットを向上させて、要求の厳しいワークロードに対応します。
REDO の高速リカバリー	Cloud SQL は、一時データの処理とダーティページの迅速なフラッシュを最適化します。結果として、復元時間が短縮され、より大きな REDO ログの利用が可能になります。
適応型バッファプールウォームアップ	Cloud SQL は、利用可能なディスク I/O 容量を動的に使用して、ページ読み取りをスケジュール設定することでデータキャッシュのウォームアップを高速化します。これにより、インスタンスを再起動した後のデータキャッシュのウォームアップが高速化され、パフォーマンスのばらつきが軽減されます。

書き込み最適化機能により、Cloud SQL for MySQL Enterprise Plus は Enterprise エディションと比較して最大 3 倍の書き込みスループットを実現し、レイテンシを大幅に削減します。これらの最適化は、書き込み負荷の高い OLTP ワークロードで特に効果的であり、結果はマシン構成によって異なります。主に読み取りを行うワークロードの場合、Cloud SQL Enterprise Plus エディションには、SSD を基盤とするデータキャッシュオプションも統合されており、最初のリリースに関するブログ投稿で詳しく説明されているように、読み取りスループットが最大 3 倍になります。

書き込み最適化機能によるパフォーマンスの向上をテストする

Cloud SQL for MySQL Enterprise Plus エディションが提供する優れた書き込みパフォーマンスについてご理解いただけたところで、ご自身の環境でどのような効果があるかについて関心をお持ちかもしれません。このパフォーマンスの向上は、sysbench ベンチマークツールで測定できます。以下の手順に沿って、特定のマシン構成パラメータを調整し、通常のワークロードに合わせてテストを実施できます。

ステップ 1: データベースインスタンスを作成するパフォーマンスの向上を調査するために、まず次の 3 種類のマシンクラスを作成します。

Enterprise Edition（ee）
書き込み最適化機能なしの Enterprise Plus エディション（ee+）
書き込み最適化機能ありの Enterprise Plus エディション（ee+）

code_block: <ListValue: [StructValue([('code', '# will set some basic configuration variables to help us run things with higher scalability.\r\n\r\n#------------------------------------------------------\r\n# ee\r\ngcloud sql instances create ee --database-version="MYSQL_8_0_37" --availability-type=zonal --edition=ENTERPRISE --cpu=64 --memory=416GB --storage-size=3000 --storage-type=SSD --zone="us-central1-c" --network=projects/${PROJECT}/global/networks/default --no-assign-ip --enable-google-private-path --no-enable-bin-log --database-flags="max_prepared_stmt_count=1000000,innodb_adaptive_hash_index=off,innodb_flush_neighbors=0,table_open_cache=200000"\r\n\r\n#------------------------------------------------------\r\n# ee+ without optimized writes\r\n# Note: this configuration is not recommended and being shown only for comparison\r\n# without optimized write larger redo log size will cause longer recovery time so switch back the redo log size to what it was originally (before optimized write was introduced).\r\ngcloud sql instances create eeplusow0 --database-version="MYSQL_8_0_37" --availability-type=zonal --edition=ENTERPRISE_PLUS --tier=db-perf-optimized-N-64 --storage-size=3000 --storage-type=SSD --zone="us-central1-c" --network=projects/${PROJECT}/global/networks/default --no-assign-ip --enable-google-private-path --no-enable-bin-log --database-flags="max_prepared_stmt_count=1000000,innodb_adaptive_hash_index=off,innodb_flush_neighbors=0,table_open_cache=200000,innodb_cloudsql_optimized_write=off,innodb_log_file_size=1073741824"\r\n\r\n#------------------------------------------------------\r\n# ee+ with optimized writes\r\ngcloud sql instances create eeplusow1 --database-version="MYSQL_8_0_37" --availability-type=zonal --edition=ENTERPRISE_PLUS --tier=db-perf-optimized-N-64 --storage-size=3000 --storage-type=SSD --zone="us-central1-c" --network=projects/${PROJECT}/global/networks/default --no-assign-ip --enable-google-private-path --no-enable-bin-log --database-flags="max_prepared_stmt_count=1000000,innodb_adaptive_hash_index=off,innodb_flush_neighbors=0,table_open_cache=200000"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfbb126b80>)])]>

ステップ 2: クライアントを作成する

次に、クライアントインスタンス用の VM を作成します。クライアントインスタンスは同じリージョンに配置されますが、ゾーンは異なります。

code_block: <ListValue: [StructValue([('code', 'gcloud compute instances create c1 --zone="us-central1-a" --boot-disk-size=10GB --create-disk=name=c1disk,size=100GB --machine-type=n2-custom-32-65536 --network=projects/${PROJECT}/global/networks/default\r\n\r\ngcloud compute instances create c2 --zone="us-central1-a" --boot-disk-size=10GB --create-disk=name=c2disk,size=100GB --machine-type=n2-custom-32-65536 --network=projects/${PROJECT}/global/networks/default\r\n\r\ngcloud compute instances create c3 --zone="us-central1-a" --boot-disk-size=10GB --create-disk=name=c3disk,size=100GB --machine-type=n2-custom-32-65536 --network=projects/${PROJECT}/global/networks/default'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfbb1260a0>)])]>

次に、クライアントインスタンスにログインし、次のコマンドを実行して sysbench と mysqladmin をインストールします。

code_block: <ListValue: [StructValue([('code', 'gcloud compute ssh <CLIENT_INSTANCE> --zone us-central1-a'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfbb126700>)])]>

code_block: <ListValue: [StructValue([('code', 'sudo apt-get --purge remove sysbench\r\n\r\n# check for latest repo here https://dev.mysql.com/downloads/repo/apt/\r\nwget https://repo.mysql.com//mysql-apt-config_0.8.36-1_all.deb\r\n\r\n# command will prompt for selecting the mysql version. Feel free to select any version (8.4 default or change it to 8.0)\r\nsudo apt install ./mysql-apt-config_0.8.36-1_all.deb\r\nsudo apt update\r\nsudo apt -y install make automake libtool pkg-config libaio-dev\r\nsudo apt -y install libssl-dev zlib1g-dev\r\nsudo apt -y install libmysqlclient-dev\r\nsudo apt -y install mysql-community-client-core\r\n\r\nsudo apt -y install git\r\nmkdir ~/sysbench\r\ngit clone https://github.com/akopytov/sysbench\r\ncd sysbench\r\n./autogen.sh\r\n./configure --prefix=$HOME/sysbench/installed\r\nmake -j 16\r\nmake install\r\ncd ~/\r\nrm mysql-apt-config_0.8.36-1_all.deb'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfbb126df0>)])]>

ステップ 3: ベンチマークワークロードを実行する

最後に、次のスクリプトを使用して sysbench 書き込みベンチマークを実行できます。

code_block: <ListValue: [StructValue([('code', 'mkdir opt-write\r\ncd opt-write\r\n\r\n# TODO: EDIT THE USER/HOST/PASSWORD\r\n\r\n#copy the script and replace the HOST IP address with the database instance ip.\r\nnohup ./write-workload.sh'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfbb1268b0>)])]>

code_block: <ListValue: [StructValue([('code', '#!/bin/bash\r\n\r\n# write-workload.sh\r\n\r\nHOST=HOST_IP_ADDRESS\r\nsysbenchdir="$HOME/sysbench/installed/"\r\nmysqlclidir="/usr/bin"\r\nmysqluser="root"\r\nmysqlpasswd="pas$w0rd"\r\n\r\nrows=("12000000")\r\n\r\nfor (( k=1; k<=4; k+=1 ))\r\ndo\r\n for row in ${rows[@]};\r\n do\r\n #------------\r\n # step-1: load data\r\n $mysqlclidir/mysql -u $mysqluser -h $HOST -e "drop database if exists x86; create database if not exists x86;"\r\n $sysbenchdir/bin/sysbench --threads=100 --mysql-host=$HOST --mysql-port=3306 --mysql-db=x86 --mysql-user=$mysqluser --mysql-password=$mysqlpasswd $sysbenchdir/share/sysbench/oltp_insert.lua --tables=100 --table-size=$row prepare\r\n $sysbenchdir/bin/sysbench --threads=128 --events=10000000 --time=0 --report-interval=10 --mysql-host=$HOST --mysql-port=3306 --mysql-db=x86 --mysql-user=$mysqluser --mysql-password=$mysqlpasswd $sysbenchdir/share/sysbench/oltp_update_index.lua --tables=100 --table-size=$row run\r\n sleep 300\r\n\r\n #------------\r\n # step-2: start write benchmarking workload\r\n for (( i=128; i<=512; i*=2 ))\r\n do\r\n $sysbenchdir/bin/sysbench --threads=$i --time=3600 --report-interval=10 --mysql-host=$HOST --mysql-port=3306 --mysql-db=x86 --mysql-user=$mysqluser --mysql-password=$mysqlpasswd $sysbenchdir/share/sysbench/oltp_write_only.lua --tables=100 --table-size=$row run\r\n sleep 120\r\n done\r\n $mysqlclidir/mysql -u root -h $HOST -e "drop database if exists x86;"\r\n done\r\ndone'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb4350bb0>)])]>

完了すると、ステップ 1 で作成した 3 つの Cloud SQL インスタンスのスループットとレイテンシの結果が表示されます。これらの結果により、Enterprise Plus エディションのパフォーマンスが優れていて、書き込み最適化機能によってさらに改善されることが確認できます。ただし、パフォーマンスの結果は変動する可能性があり、マシン構成によって異なる場合があることにご注意ください。

書き込み最適化機能を有効にする準備はできましたか？

既存のインスタンスと新しく作成されたインスタンスのすべてに対して、デフォルトで書き込み最適化機能が有効になります。Cloud SQL インスタンスを今すぐ Enterprise Plus エディションにアップグレードして、パフォーマンスの向上を実感してください。

- シニアソフトウェアエンジニアリングマネージャー Alex Joseph

- データマネジメントスペシャリスト Somdyuti Paul

エージェントアプリで 100% に近い精度の Text-to-SQL を実現

Wed, 14 Jan 2026 01:00:00 +0000

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

現在の AI 機能は、テキストと音声を使用するアプリケーションを通じて、エンタープライズデータを使用した自然言語（NL）によるやり取りを可能にする絶好の機会を提供しています。実際、エージェントアプリケーションの世界では、自然言語が急速にインタラクションの標準になりつつあります。つまり、エージェントは自然言語でデータベースに質問し、正確な回答を受け取る必要があります。Google Cloud では、この状況を受けて、AlloyDB データベースに自然言語から SQL への変換（NL2SQL）テクノロジーを構築しました。このテクノロジーは、質問を入力として受け取り、自然言語の結果、またはその結果を取得するのに役立つ SQL クエリを返します。

現在プレビュー版の AlloyDB AI 自然言語 API を使用すると、デベロッパーは、エージェントまたはエンドユーザーからのデータベースのデータに関する自然言語の質問に対し、安全で、ビジネスとの関連性が高い、説明可能な方法で、100% に近い精度で回答するエージェントアプリケーションを構築できます。Google は、この機能をより幅広い Google Cloud データベースに提供することに注力しています。

2024 年に初めてこの API をリリースしたとき、NL2SQL の精度は 100% には及ばなかったものの、すでに業界トップクラスでした。しかし、業界トップクラスというだけでは不十分です。多くの業界では、テキストを SQL に変換する精度は 80% どころか 90% でも十分ではありません。回答の質が低いと、顧客の不満やビジネス上の意思決定の誤りなど、金銭的に測定可能なコストが発生します。エンドユーザーが求めていること（「意図」）を理解できない不動産検索アプリケーションは、関連性の低い回答を返すリスクがあります。小売商品の検索では、回答の関連性が低いと販売につながるコンバージョン率の低下につながります。つまり、Text-to-SQL 変換の精度は、ほとんどの場合、非常に高くなければなりません。

このブログでは、AlloyDB AI 自然言語 API の価値と、その回答の精度を最大化する手法について説明します。

結果の精度と関連性を 100% に近づける

テキストから SQL への変換で高い精度を実現するには、Gemini に質問を入力するだけでは不十分です。アプリを開発する際に、データベースのテーブルと列の説明などの説明的コンテキストを AlloyDB AI に提供する必要があります。このコンテキストは自動生成できます。その後、AlloyDB AI 自然言語 API が質問を受け取ると、関連する説明的コンテキストをインテリジェントに取得し、Gemini が質問とデータベースデータの関連性を把握できるようにします。

それでも、多くのお客様は、ユースケースで 100% に近い（95% 以上、99% 以上など）精度を達成できるよう、説明可能で、証明可能で、ビジネスとの関連性が高い回答を求めていました。

AlloyDB AI 自然言語 API の最新のプレビューリリースでは、回答をさまざまな方法で改善する機能が提供されています。

ビジネスとの関連性: コンバージョンやエンドユーザーのエンゲージメントなどのビジネス指標を改善するために、回答には情報が含まれ、適切にランク付けされている必要があります。
説明可能性: 結果には、エンドユーザーが理解できる言葉で、NL API が質問をどのように解釈したかを明確にする意図の説明を含める必要があります。たとえば、不動産アプリが「家族向けのデルマーの家を見せて」という質問を「近くによい学校があるデルマーの家」と解釈した場合、その解釈をエンドユーザーに説明します。
検証済みの結果: 結果は、ユーザーまたはエージェントに説明された意図に沿った内容である必要があります。
精度: 結果は質問の意図を正確に捉えている必要があります。

この点については、AlloyDB AI 自然言語 API を使用することで、ユースケースでの精度を段階的に向上させることができます。これは「ヒルクライミング」と呼ばれることもあります。精度が 100% に近づくにつれて、AlloyDB AI の意図の説明により、不正確な回答をした場合の影響が軽減されます。つまり、エンドユーザーやエージェントは、API が意図した質問とは少し異なる質問に回答したことを理解できます。

aside_block: <ListValue: [StructValue([('title', 'AlloyDB の 30 日間の無料トライアルインスタンスを使ってみる'), ('body', <wagtail.rich_text.RichText object at 0x7fdfb7b0d1c0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

100% の精度に近づけるためのヒルクライミング

簡単なワークフローで AlloyDB AI の精度を反復的に向上させることができます。

まず、AlloyDB AI が提供していてすぐに使用できる NL2SQL API から始めます。自然言語の質問を SQL クエリに変換する組み込みエージェントと、そのエージェントが使用する自動生成された説明的コンテキストのおかげで、精度は（完璧ではありませんが）非常に高くなっています。

次に、コンテキストを改善することで、約 100% の精度とビジネスとの関連性を目指して、迅速にイテレーションを行うことができます。重要な点として、AlloyDB AI 自然言語 API では、コンテキストは次の 2 つの形式で提供されます。

テーブルと列の説明を含む説明的コンテキスト。
SQL テンプレートと（条件）ファセットを含む規範的コンテキスト。これにより、NL リクエストが SQL に変換される方法を制御できます。

最後に、「値インデックス」は、データベースに固有の用語（SKU や従業員名など）を明確にします。これらの用語は、基盤モデルではすぐには理解できません。

柔軟かつ安全に 100% の精度に近づけるためのヒルクライミングは、2 種類のコンテキストと AlloyDB の値インデックスにより可能となっています。

コンテキストと値インデックスについて詳しく見ていきましょう。

1. 説明的コンテキストと規範的コンテキスト

前述のように、AlloyDB AI 自然言語 API は、説明的コンテキストと規範的コンテキストに依存して、生成する SQL コードの精度を向上させます。

説明的コンテキスト（主にテーブルと列の説明）を改善することで、SQL クエリが適切なテーブルと列を適切なロールで使用する可能性が高まります。しかし、規範的コンテキストは、より難しい問題を解決します。それは、特定のユースケースで重要な難しい質問を正確に解釈することです。たとえば、エージェント型の不動産アプリケーションでは、「<指定された都市> のよい学校の近くにある家を見せてください」といった質問に答える必要があります。この質問には次のような課題があります。

「近く」とはどのくらいの距離か。
「よい」学校をどのように定義するか。
データベースに評価が記載されている場合、良い学校の評価の基準はどこからか。
結果をリストとして提示する際に、（ランキングの目的を考慮し、上位の結果のビジネス価値を確保するという観点から）学校からの距離と学校のランキングをどの程度の比重で評価するのが最適か。

これを支援するために、AlloyDB 自然言語 API ではテンプレートを提供しています。これにより、質問のタイプをパラメータ化された SQL クエリとパラメータ化された説明に関連付けることができます。これにより、AlloyDB NL API は、非常に微妙なニュアンスを含む可能性のある自然言語の質問を正確に解釈できます。そのため、テンプレートは、よくある微妙なニュアンスを含む質問に適したオプションとなります。

2 つ目の規範的コンテキストであるファセットでは、個々の SQL 条件とそれに対応する自然言語の条件を指定できます。ファセットを使用すると、テンプレートの精度に加えて、膨大な数の条件に対する検索の柔軟性を提供できます。たとえば、「良い学校の近く」は、数多くの条件の一つにすぎません。価格、「若い家族向け」、「オーシャンビュー」など、他の要素も考えられます。「海が見える良い学校の近くの家」のように、複数の条件を組み合わせたものもあります。しかし、条件の組み合わせごとにテンプレートを用意することはできません。以前は、このような条件すべてに対応するために、考えられるすべての条件の検索フィールドを含むダッシュボードを作成しようとしたかもしれませんが、すぐに非常に扱いにくくなったでしょう。自然言語インターフェースを使用すると、ファセットを使用して、単一の検索フィールドでも、任意の数の条件をカバーできます。自然言語インターフェースの強みが発揮されるのは、まさにこのような場合です。

AlloyDB AI 自然言語 API を使用すると、説明的コンテキストと規範的コンテキストを簡単に作成できます。たとえば、パラメータ化された質問、パラメータ化された意図の説明、パラメータ化された SQL を提供するのではなく、add_template API を使用してテンプレートを追加するだけで済みます。この API では、質問の例（「デルマーの良い学校に近い家」）と、それに対応する正しい SQL を提供します。AlloyDB AI は、この質問を自動的に一般化してどの都市にも対応できるようにし、意図の説明を自動的に準備します。

2. 値インデックス

約 100% の精度を実現する 2 つ目の重要な要素は、AlloyDB AI の値インデックスです。これは、データベースに固有の、基盤モデルには知られていない用語を明確にします。自然言語の質問に含まれる固有の用語は、多くの問題を引き起こします。まず、ユーザーは単語をタイプミスします。当然、音声インターフェースでは言い間違いが多くなります。また、自然言語の質問では、固有の用語のエンティティタイプが明示されていない場合があります。たとえば、大学の管理者が「ジョンスミスは 2025 年にどのような成績を収めましたか？」と質問したとします。このとき、ジョンスミスが教員なのか学生なのかは指定されていません。それぞれのケースで、質問に答えるには異なる SQL クエリが必要になります。値インデックスは、「ジョンスミス」がどのようなエンティティであるかを明確にするもので、AlloyDB AI によってアプリケーション用に自動的に作成できます。

構造化データ、非構造化データ、マルチモーダルデータに対する自然言語検索

構造化データを検索するアプリケーションに関しては、AlloyDB AI 自然言語 API により、簡潔で高度な検索エクスペリエンスを実現できます。従来、アプリケーションは、エンドユーザーが検索を絞り込むために使用できるフィルタとして、ユーザーインターフェースに条件を表示していました。一方、NL 対応のアプリケーションでは、シンプルなチャットインターフェースを提供できます。あるいは、検索条件のあらゆる組み合わせを直接または間接的に提示する音声コマンドを受け付けて、その質問に答えることもできます。検索機能が従来のアプリの制約から解放されると、まったく新しいユーザーエクスペリエンスの可能性が広がります。

NL2SQL テクノロジーと AI 検索機能を組み合わせることで、構造化データ、非構造化データ、マルチモーダルデータの組み合わせをクエリすることもできます。AlloyDB AI 自然言語 API は、ベクトル検索、テキスト検索、および AI.IF 条件などのその他の AI 検索機能を含む SQL クエリを生成できます。これにより、テキストデータとマルチモーダルデータのセマンティック条件をチェックできます。たとえば、不動産アプリで「デルマーの即入居可能な住宅」について質問されたとします。これにより、real_estate.properties テーブルの description 列のテキストが「即入居可能」に類似しているかどうかをチェックする AI.IF 関数を含む SQL クエリが生成されます。

AlloyDB AI 自然言語 API をエージェントアプリケーションに組み込む

AlloyDB AI 自然言語 API をエージェントアプリケーションに統合する準備はできましたか？AlloyDB からデータを取得する AI ツール（関数）を作成する場合は、データベース向け MCP ツールボックスをお試しください。ノーコードエージェントプログラミングには、Gemini Enterprise を使用できます。たとえば、Gemini を使用してウェブの知識とデータベースから抽出したデータに基づいて質問に回答する会話型エージェントアプリケーションを、コードを 1 行も書かずに作成できます。どちらの場合でも、皆様がどのようなものを構築されるか楽しみにしております。

-Google Cloud、データベース担当上級エンジニア、Yannis Papakonstantinou

-Google Cloud、データベース担当スタッフソフトウェアエンジニア、Reza Sherkat

新たな最高スコア: BIRD ベンチマークでの Text-to-SQL の進歩

Wed, 17 Dec 2025 17:00:00 +0000

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

エージェント開発の世界は急速に進化しており、自然言語がインタラクションの標準になりつつあります。この変化は、運用データベースの力と深く結びついています。より正確なテキストから SQL への変換機能は、より優れた、より有能なエージェントを構築するための大きな触媒となります。技術者ではないユーザーがデータをセルフサービスで利用できるようにすることから、アナリストの生産性を向上させることまで、自然言語の質問を正確に SQL に変換できることは、大きな変革をもたらします。エンドユーザーとのやり取りがチャットで行われることが増えるにつれ、会話は企業と顧客を結び付ける基本的なつながりとなっています。

以前の投稿「AI を使って優れた SQL を作成する: Text-to-SQL 手法の説明」では、Text-to-SQL の主な課題（複雑なビジネスコンテキスト、曖昧なユーザーの意図、微妙な SQL 言語の処理）と、それらを解決するために使用される一般的な手法について説明しました。

本日は、理論から実践に移ります。Google Cloud は BIRD ベンチマークの単一トレーニング済みモデルトラックにおいて新たに最先端のスコアを獲得することができました。76.13 というスコアは、他の単一モデルソリューションを上回っているものです（スコアが高いほど優れています）。一般的に、人間のパフォーマンスのベンチマーク（92.96）に近づくほど、スコアを上げるのが難しくなります。

BIRD（BIg Bench for LaRge-scale Database Grounded Text-to-SQL Evaluation）は、Text-to-SQL ソリューションをテストするための業界標準です。BIRD は、合計サイズ 33 GB の 95 個のデータベースから 12,500 を超える固有の質問と SQL のペアを網羅しています。単一のトレーニング済みモデルトラックは、モデルの精度を高めるためによく使用される複雑な前処理、検索、エージェントフレームワークの使用を制限し、モデル自体の生の、本質的な能力を測定するように設計されています。つまり、このテストの成功は、SQL を生成するというモデルのコア機能の向上を反映しています。

Gemini が BIRD で 1 位を獲得（2025 年 10 月）

研究から業界をリードするプロダクトへ

NL2SQL と呼ばれるより正確な自然言語から SQL への変換機能の飛躍は、社内の研究やエンジニアリングの成果にとどまりません。いくつかの主要なデータサービス全体でカスタマーエクスペリエンスを根本的に向上させます。また、この分野における最先端の研究により、お客様がエージェント AI でデータを活用するために使用する、業界をリードするプロダクトを作成できるようになります。

AlloyDB AI の自然言語機能は、エンドユーザーが最新の運用データをクエリする際に自然言語を使って使用できるツールです。たとえば、Echostar Corporation の Hughes のような企業は、通話分析などの重要なタスクに AlloyDB の NL2SQL を利用しています。小売、テクノロジー、業界の他の多くの企業が、この機能を顧客向けアプリケーションに統合しています。ほぼ 100% の精度を誇る NL2SQL を使用することで、リアルタイムのデータアクセスに依存する本番環境ワークロードにおいて、お客様は自信を持ってアプリケーションを構築、デプロイすることができるようになります。

NL2SQL のメリットは分析にも及びます。その例が BigQuery の会話分析です。このサービスによりビジネスユーザーとデータアナリストは自然言語を使用してデータを探索し、レポートを実行し、膨大な履歴データセットからビジネスインテリジェンスを抽出することができるようになります。マルチターンチャットエクスペリエンスの導入と、高精度の NL2SQL エンジンを組み合わせることで、BigQuery ベースのアプリケーションからのレスポンスが常に正確であるという確信を根拠にした情報に基づく意思決定を行うことができます。

ついに、デベロッパーは新たな効率性を獲得することになります。長年の間、デベロッパーはコード生成に Google Code Assist（GCA）を利用し、Spanner、AlloyDB、Cloud SQL Studio 全体でデータベースを使用したアプリケーション開発を支援しています。より正確な NL2SQL が利用可能になることで、デベロッパーは AI のコーディング支援を使用して SQL コードも生成できるようになります。

BIRD: コアモデルの能力を実証する場

BIRD ベンチマーク は、テキストから SQL への分野で最も一般的に使用されているベンチマークの一つです。このベンチマークは単純な単一テーブルのクエリにとどまらず、モデルが処理する必要がある現実世界の課題をカバーしています。たとえば、非常に大きなスキーマに対する推論、曖昧な値の処理、外部のビジネス知識の組み込みなどです。重要なのは、BIRD が重要な基準である実行検証済み精度を測定することです。つまり、クエリは正しく見えるだけでは「正しい」とは見なされず、正常に実行されて正しいデータを返す必要があります。

特に「単一のトレーニング済みモデル」トラックを対象としたのは、テキストから SQL へのタスクを解決するモデルのコア能力を（アンサンブルではなく）分離して測定できるからです。アンサンブルとは、複数の並列モデル、リランカーなど、複数のコンポーネントを持つシステムのことです。この区別は重要です。テキストから SQL への変換の精度は、動的な少数ショット検索やスキーマの事前処理などの手法で向上させることができます。このトラックは、モデルの真の推論能力を反映しています。単一モデルのソリューションに焦点を当てた BIRD の結果は、コアモデルを強化することで、その上に構築されたシステムの基盤がより強固になることを示しています。

Google の手法: モデルの特化

最先端のスコアを達成するには、強力なベースモデルを使用するだけでは不十分です。重要なのは、モデルを特化させることです。汎用的な推論エンジンから、高度に専門化された SQL 生成エキスパートにモデルを変換するように設計されたレシピを開発しました。

このレシピは、推論の前に適用される 3 つの重要なフェーズで構成されていました。

厳格なデータフィルタリング: モデルが完璧な「ゴールドスタンダード」のデータセットから学習できるようにします。
マルチタスク学習: モデルに変換するだけでなく、正しい SQL クエリを記述するために必要な暗黙的なサブタスクを理解させる。
テスト時のスケーリング: 「自己整合性」、つまり最適な回答を選択する。

各ステップを詳しく見ていきましょう。

SOTA の結果を達成するためのプロセス

ステップ 1: クリーンな基盤から始める（データフィルタリング）

ファインチューニングの重要な原則の一つに「garbage in, garbage out（ゴミを入れたら、ゴミが出てくる）」があります。不正確、非効率的、または曖昧なクエリを含むデータセットでトレーニングされたモデルは、不適切なパターンを学習する可能性があります。BIRD ベンチマークで提供されるトレーニングデータは強力ですが、ほとんどの大規模データセットと同様に、完璧ではありません。

モデルを SQL のエキスパートにするには、まずゴールドスタンダードのデータセットをキュレートする必要がありました。厳格な 2 段階のパイプラインを使用しました。まず、実行ベースの検証で、すべてのクエリを実行し、失敗したクエリ、エラーを返したクエリ、空の結果を返したクエリを破棄しました。2 つ目は、LLM ベースの検証です。複数の LLM が「審査員」として機能し、質問と SQL のセマンティックアライメントを検証して、実行はされるもののユーザーの質問に実際には回答しないクエリを検出します。この積極的なフィルタリングにより、より小さく、よりクリーンで、より信頼性の高いデータセットが作成され、モデルはノイズではなく純粋な品質のシグナルから学習できるようになりました。

ステップ 2: モデルを SQL スペシャリストにする（マルチタスク学習）

クリーンなデータセットが用意できたので、教師ありファインチューニングに進むことができます。これは、大規模な汎用モデル（Google の場合は Gemini 2.5-pro）を取り上げ、狭い範囲の専門的なデータセットでさらにトレーニングして、特定のタスクの専門家にするプロセスです。

これらのスキルをモデルに直接組み込むために、公開されている Vertex AI の Gemini 用教師ありチューニング API を活用しました。このサービスは、マルチタスクの教師ありファインチューニング（SFT）アプローチの基盤となりました。このアプローチでは、Gemini-2.5-pro を複数の異なるが関連するタスクで同時にトレーニングしました。

また、トレーニングデータを拡張して、Text-to-SQL の主な領域以外のタスクもカバーし、モデルの推論、計画、自己修正機能を強化しました。

この組み合わせのタスクで並行してトレーニングすることで、モデルはより豊富で堅牢なスキルセットを学習します。単純な質問からクエリへのマッピングにとどまらず、問題を深く分析し、アプローチを計画し、独自のロジックを洗練させることを学習するため、精度が大幅に向上し、エラーが減少します。

ステップ 3: 自己整合性による推論精度とテスト時のスケーリング

最後のステップは、テスト時にモデルの最良の回答を確実に選択できるようにすることでした。これには、自己整合性と呼ばれる手法を使用しました。

自己整合性では、モデルに 1 つの回答を求めるのではなく、同じ質問に対して複数のクエリ候補を生成するように求めます。次に、これらのクエリを実行し、実行結果でクラスタリングして、最大のクラスタから代表的なクエリを選択します。モデルが異なる推論パスを通じて同じ答えにたどり着いた場合にその答えが正しい可能性がはるかに高くなるためこのアプローチは効果的です。

自己整合性は標準的で効率的な方法ですが、クエリを選択する唯一の方法ではないことに注意してください。より複雑なエージェントフレームワークでは、さらに高い精度を実現できます。たとえば、CHASE-SQL（Google の最先端のアンサンブル手法）に関する Google のチーム独自の研究では、多様な候補ジェネレーターとトレーニング済みの選択エージェントを使用することで、一貫性ベースの手法を大幅に上回るパフォーマンスを実現できることが示されています。

このベンチマークでは、モデルのコアパフォーマンスに焦点を当てたいと考えました。そこで、より直接的な自己整合性手法を使用しました。複数のクエリを生成して実行し、最も一般的な結果を生成したクエリをグループから選択しました。このアプローチで、より複雑なフィルタリングや再ランキングシステムの影響を最小限に抑え、モデルのテキストから SQL への変換能力を測定できました。

BIRD シングルモデルトラックでは、モデル自身の内部能力を反映する自己整合性が明示的に許可されています。ベンチマークでは、使用する候補の数（「少数」、「多数」、「スケール」）に基づいて提出物を分類します。「少数」（1 ～ 7 人の候補者）のカテゴリが「スイートスポット」でした。

このアプローチにより、実行精度が最終的に大幅に向上し、モデルがランキングのトップに躍り出ました。さらに重要なのは、この結果が Google のコアとなる主張を証明していることです。高品質のデータと指示チューニングに投資することで、重く高レイテンシの推論フレームワークを必要とせずに、本番環境に対応できるほど強力な単一のモデルを構築できます。

Text-to-SQL 用に Gemini をカスタマイズするレシピ

クリーンなデータ、マルチタスク学習、効率的な自己整合性の組み合わせにより、強力な Gemini 2.5-pro モデルを基に、BIRD 単一モデルベンチマークで最高ランクのスコアを達成したスペシャリストを構築できました。

ファインチューニングされたモデルは、Text-to-SQL のベースラインを大幅に強化しています。ただし、このスコアは精度の上限ではないことに注意してください。そうではなく、制約のある設定におけるコアモデルの能力について、Google が新たに確立したより高いベースラインです。これらの結果は次のいずれかにより増幅されます。

アンサンブルを作成する（つまり、この専門モデルを前処理（例: 例の検索）やエージェントのスキャフォールディング（例: Google の CHASE-SQL 研究）を採用するより広範なシステムに統合する）、または
メタデータやクエリの例を強化して、独自のデータベースのモデル品質を最適化する（お客様が通常、本番環境のワークロードをデプロイする方法です）。

それでも、この調査から得られた知見は、Google データクラウド向けの次世代 AI 搭載プロダクトの構築方法に積極的に反映されており、Google は今後もデータサービスでこれらの機能強化を提供していきます。

高度な Text-to-SQL 機能を今すぐお試しください

Google は、最先端の機能をプロダクトに組み込むことに常に取り組んでおり、その第一歩として、AlloyDB と BigQuery 上に構築されたアプリケーションに自然言語クエリを導入しています。AI で強化された検索では、お客様は特に AlloyDB とその AI 機能を高く評価しています。AlloyDB は AI 機能をデータベースに直接統合しているため、デベロッパーはデータを移動することなく、標準 SQL クエリを使用して強力な AI モデルを実行できます。インテリジェントなフィルタリングのための AI.IF()、検索結果のセマンティックな再ランキングのための AI.RANK()、データベース内のテキスト生成とデータ変換のための AI.GENERATE() などの特殊な演算子を提供します。

SQL を自分で記述したい場合は、Gemini Code Assist が役立ちます。簡単なプロンプトで、作成したいクエリを Gemini に指示できます。Gemini がコードを生成するので、データベースに対して実行してすぐにテストできます。皆様がどのようなものを構築されるか楽しみにしております。

-ソフトウェアデベロッパー Mohammadreza Pourreza

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

CME Group が Cloud SQL でより高速かつスマートな取引所を構築

Mon, 15 Dec 2025 03:00:00 +0000

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

編集者注: シカゴマーカンタイル取引所（CME Group）は、商品取引所として 19 世紀に業務を開始し、世界有数の先進的な金融市場インフラストラクチャへと発展しました。CME Group は、グローバル規模のリアルタイム取引とリスク管理をサポートするため、Google Cloud との戦略的パートナーシップを立ち上げました。その後、Cloud SQL に移行して AI による分析情報を導入。これによりデベロッパーの能力強化と技術的負債の削減が可能になり、金融市場全体でデータドリブンイノベーションの新たなチャンスを切り開きました。

バターや卵から帯域幅まで

CME Group には、リスクとチャンスが共存しています。当取引所で行われるトランザクション（注文、取引、リスク計算）はすべて、データが瞬時に完全な状態で移動することで成り立っています。市場の健全性は、このデータ処理にかかっていると言ってもよいでしょう。

このような取引の背後には、評価額、所有権、その他多くの情報を保存するデータベースがあり、これらはすべて一日中、ミリ秒単位で変化します。私たちの規模では、これらのデータベースは常に続く高需要の中で情報を保存し、取得しなければなりません。レイテンシやエラーが許されない状態で、一日に数百万件のメッセージを処理しています。このレベルの精度を保つのは容易ではありません。特に、パフォーマンスとセキュリティ、レポート作成を共存させなければならない規制の厳しい業界ではなおさらです。私たちが行う変更はすべて、厳格なコンプライアンス基準とグローバルな規制の枠組みに沿ったものでなければなりません。

スピードは常に私たちの強みでしたが、規模の拡大が課題となりました。CME Group の従来のデータベース資産には、パフォーマンスを維持し、規制要件を満たすための多大なエンジニアリング作業が必要でした。セキュリティポスチャーを向上させながら運用オーバーヘッドを削減しなければならず、透明性の高いオブザーバビリティと明確なコンプライアンス管理体制を実現する、マネージドデータベースソリューションが必要だったのです。

Cloud SQL を取引フロアに導入

この課題に対処するため、私たちは 10 年間にわたる Google Cloud との戦略的パートナーシップを結びました。それにより、すべてのテクノロジーをクラウドに移行して、クラウドインフラストラクチャのサポート範囲を拡大するイノベーションとコラボレーションが実現しました。現在、Google とともに、超低レイテンシパフォーマンスをクラウドで実現する新しい方法を模索しています。データ量が急増し、AI がリスク管理の中心となるにつれて、情報をミリ秒単位で移動して解釈する能力が技術的な要件となっています。Google Cloud でシステムを構築することで、市場を未来に導きながら、その機能を維持できるのです。

Cloud SQL を使用することで、市場のニーズに合った高速かつ信頼性の高いデータレイヤーを維持する方法が見つかりました。データベース内の状況をチームがリアルタイムに把握でき、アプリケーションの速度が低下した場合は、数時間も費やすことなく分単位で根本原因を特定できます。これらの分析情報はプラットフォームに組み込まれているため、運用を安定させるためのカスタムツールや手動分析は必要ありません。

しかし、Cloud SQL の価値を高めているのはパフォーマンスチューニングだけではありません。何よりも、信頼できることが大切です。データベース管理者は戦略的な改善に集中でき、開発者はエスカレーションを待つことなくクエリを検証して最適化できます。これらを組み合わせることで、トラブルシューティングが迅速化され、常時稼働が求められるグローバルな取引に対応できるデータ基盤が整いました。

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

Cloud SQL は新たなベストパートナー

Cloud SQL の使用を重ねると、チームに新メンバーが加入したような感覚になります。Cloud SQL の AI による分析情報を活用することで、CME Group チームの働き方が変わりました。アプリケーションの速度が低下すると、Cloud SQL がその理由を教えてくれます。異常を検出してガイド付き分析を行い、数分でパフォーマンスを回復するためのクエリの最適化案まで示してくれます。開発者は、ワークフローで直接これらの推奨事項を確認し、修正をテストして、次のステップに進むことができます。待たされることはなく、引き継ぎや緊急対応も無用です。

つまり、AI を活用したトラブルシューティングにより、パフォーマンスの管理責任を共有することになったのです。また、Cloud SQL は一貫したエクスペリエンスを提供するため、チームは環境間をシームレスに移動できます。これによりトレーニングの必要性が減り、コラボレーションが大幅に増加しました。最終的に、CME Group はよりスマートで統合されたデータ文化を築いています。

パフォーマンスが競争上の優位性

Google Cloud との取り組みは、単なるモダナイゼーションではありません。スピードや確実性、可視性の向上は、そのままビジネスの信頼につながります。CME Group により、クライアントが依拠する継続性を維持しながら、新機能をより迅速にデプロイできるようになりました。

Cloud SQL は、そのアジリティの基盤となっています。パフォーマンスの問題が減ることで、イノベーションに注力する時間を増やせます。たとえば、分析機能の拡張、AI イニシアチブの加速、責任を持ってデータを商品化するための新たな方法を模索できるようになります。障害対応に追われることがなくなると、より大きな賭けに出て未来を築くための時間が生まれます。

CME Group にとっては、常にパフォーマンスこそがプロダクトでしたが、今ではプラットフォームも立派なプロダクトであると言えるでしょう。私たちは、グローバル市場を動かし続けるインフラストラクチャと、次の時代を形作るインテリジェンスを Google Cloud で構築しています。

詳細:

新しい Cloud SQL の無料トライアルにご登録ください。これは、新規および既存の Google Cloud ユーザーに対して、Cloud SQL（PostgreSQL および MySQL）が提供するプレミアムなエンタープライズグレードの機能をご利用いただくことを目的とした 30 日間の専用プログラムです。
IDC レポートをダウンロードして、Cloud SQL への移行によってコストの削減、アジリティの向上、デプロイの高速化を実現する方法をご確認ください。
Ford と Yahoo が Cloud SQL でモダナイズして、高いパフォーマンスを実現し、費用を削減した方法をご確認ください。

-CME Group、クラウドデータエンジニアリング担当エグゼクティブディレクター Kristofer Shane Sikora

データベース

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 イノベーションの基盤に

データに眠る可能性

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

統合データに向けた歩み

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

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

AI 時代の教訓

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

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

新機能

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

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

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

使ってみる

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

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

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

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

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

今すぐ始めましょう

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

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

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

未来に向けた青写真

Spanner が評価された理由とは

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

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

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

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

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

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

次のステップ

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

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

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 位を獲得

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

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

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

Fastweb + Vodafone: Spanner と BigQuery でデータワークフローを再定義

単一のツールではなく、コネクテッドプラットフォームを選択

新しいクエリエンジンとパイプラインオペレーションのエクスペリエンス

Firestore パイプラインオペレーションを使ってみる

エージェントアプリで 100% に近い精度の Text-to-SQL を実現

構造化データ、非構造化データ、マルチモーダルデータに対する自然言語検索

AlloyDB AI 自然言語 API をエージェントアプリケーションに組み込む

Cloud SQL は新たなベストパートナー