Spanner

Spanner キューの発表: エージェントワークロードとその先を支えるトランザクションメッセージング

Thu, 15 Oct 2026 02:30:00 +0000

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

AI エージェントは、クエリに回答するだけでなく、自律的に払い戻しを行ったり、在庫を管理したり、複数ステップのハンドオフを実行したり、サブエージェントをオーケストレートしたりできます。これらは、複雑なエージェント型ワークフローのほんの一例です。そのため、多くの場合、エージェントは運用データベースで内部状態を維持しながら、別のメッセージングシステムやイベントキューシステムを介して非同期アクションをディスパッチする必要があります。残念ながら、これらのアプリケーションを構築するチームにとって、commit ポイントが異なる 2 つのシステムを管理することは、エージェントシステムにおけるトランザクションの一貫性を破壊することになります。

このたび、Spanner キューの一般提供が開始されました。これは、Spanner に直接組み込まれたネイティブなトランザクションメッセージング機能です。Spanner キューは、信頼性の高いエージェント実行に特化して設計されており、メッセージの作成はトランザクションにおける単なる書き込み操作にすぎません。エージェントの状態変更と、意図したダウンストリームアクションは、アトミックにまとめて commit されるか、完全に失敗します。

これを従来のアプローチと比較してみましょう。データベースの状態の更新は成功したものの、アクションのディスパッチが失敗した場合、AI エージェントは行動を決定したにもかかわらず、実際には実行されないという状態になります。メッセージのディスパッチが成功しても、状態トランザクションがロールバックされると、エージェントは無効な状態に基づいてアクションを実行します。非同期のマルチエージェント調整では、再試行、投機的実行、競合状態によってこれらの障害が増幅され、開発者は複雑なアウトボックスパターン、べき等性レイヤ、データ整合ワーカーを構築せざるを得なくなります。これは、エージェントアーキテクチャにおける信頼性担保のための大きな負担となります。

エージェントアーキテクチャの主な機能

Spanner キューは、インフラストラクチャのオーバーヘッドを発生させることなく、こうした複雑な非同期ワークフローをサポートするいくつかのコア機能を提供します。

アトミックな「意思決定とアクション」のエンキュー。単一の Spanner 読み取り / 書き込みトランザクション内で、エージェントは内部メモリまたは状態テーブルを更新し、同時にピアエージェントへのタスクをエンキューできます。Spanner の厳格な直列化可能性とグローバルな外部整合性に支えられ、状態の変化と実行インテントは 1 つのアトミックな単位として commit されます。

スケジュール実行と遅延実行。キューメッセージは、commit 時にすぐにディスパッチすることも、将来の配信をスケジュールすることもできます。遅延再試行、スケジュールされたエージェントチェックイン、SLA エスカレーションタイマーなどのエージェント型パターンは、外部の cron スケジューラやポーリングインフラストラクチャを必要とせずに、メモリの更新とともにトランザクション的にエンキューできます。

エージェントワーカー向けのストリーミング SQL pull。自律型エージェントは、ストリーミング SQL 読み取りを使用してタスクを動的に取り込んで処理します。エージェントランタイムは、受信タスクをストリーミングしながら、処理能力に空きができ次第それらを処理し、トランザクション内でタスクの完了を確認応答（ACK）することで、エンドツーエンドのタスク実行状態の信頼性を保証します。

エピソード記憶の永続性とハンドオフ。エージェントメモリの更新（長期的なエピソードの要約、内省的な状態遷移、サブエージェント間のコンテキストのハンドオフなど）は、キューを介して非同期かつトランザクション的に永続化できます。これにより、リアルタイムのインタラクティブなターンをブロックすることなく、エージェントの内部メモリが実行履歴と完全に同期された状態に保たれます。

Spanner キューが自律型エージェントに不可欠な理由

トランザクションによる exactly-once のエージェント実行: エージェントがツール呼び出しの結果を評価すると、状態の変更、推論の永続化、ダウンストリームツール呼び出しタスクが 1 つのトランザクションに保存されます。少なくとも 1 回の配信と、最大 1 回の ACK を保証することで、exactly-once の処理を実現できます。

堅牢なマルチエージェントオーケストレーションとハンドオフ: マルチエージェントシステム（A2A）では、プライマリエージェントからスペシャリストエージェントへの状態のハンドオフは、永続的でトランザクション的に commit されたメッセージとして処理されます。スペシャリストエージェントワーカーは、エージェント間のやり取りの完全に監査可能なリネージを維持しながら、配信されたメッセージを受信します。

ファーストクラスのタイムアウトと人間参加型ワークフロー: エージェントワークフローでは、人間の承認やスケジュールされたフォローアップのために一時停止が必要になることがよくあります。Spanner キューはタイムアウト管理をネイティブに処理します。単一のトランザクションが承認待ち状態を記録し、自動エスカレーションメッセージをスケジュールして、どちらか先にトリガーされた方の処理を確定させます。

エージェントキューの SQL ネイティブなオブザーバビリティ: 処理中のエージェントワークロードの検査、タスクバックログのモニタリング、エージェント実行履歴の監査は、キューテーブルに対する標準 SQL クエリで実行できるため、中身の見えないメッセージストアのブラックボックス化を防ぐことができます。

エージェントワークフローの先

AI エージェント以外にも、Spanner キューは、さまざまな従来のイベントドリブンアーキテクチャに対応する柔軟な多目的メッセージングプラットフォームとして機能します。ソーシャルアプリケーションでのリアルタイムのアクティビティフィードの強化、ニュース配信でのライブ情報の提供、小売業での注文処理と在庫ワークフローのオーケストレーション、金融サービスでの高スループットの非同期タスク処理とトランザクション通知の処理など、Spanner キューは、プライマリデータベース内での非同期メッセージ配信とトランザクションイベントドリブンワークフローのための堅牢な基盤を提供します。

仕組み: Spanner キューのトランザクションメカニズム

Spanner キューは Spanner のファーストクラスのリレーショナル構造として表されるため、使い慣れた GoogleSQL を使用してキューを定義、検査、管理できます。

1. キューの定義とアトミックなエンキュー

エージェントが顧客への払い戻しを承認すると、単一の ACID トランザクション内で Orders テーブルを更新し、OrderAgentTasks キューに実行タスクをディスパッチします。

code_block: <ListValue: [StructValue([('code', '-- Assume parent table:\r\n-- CREATE TABLE Orders (\r\n-- OrderId STRING(64) NOT NULL, ...\r\n-- )\r\n-- PRIMARY KEY (OrderId);\r\n\r\n-- Define the transactional queue table\r\nCREATE QUEUE OrderAgentTasks (\r\n OrderId STRING(64) NOT NULL,\r\n TaskId STRING(64) NOT NULL,\r\n TaskType STRING(64) NOT NULL,\r\n Payload JSON NOT NULL\r\n) PRIMARY KEY (OrderId, TaskId, TaskType), INTERLEAVE IN Orders;\r\n\r\n-- Inside a Read-Write Transaction:\r\n-- 1. Update business state atomically\r\n\r\n-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET Status = \'REFUND_APPROVED\',\r\n UpdatedAt = PENDING_COMMIT_TIMESTAMP()\r\nWHERE OrderId = @orderId;\r\n\r\n-- 2. Enqueue the asynchronous agent action in the same transaction\r\nINSERT INTO OrderAgentTasks (OrderId, TaskId, TaskType, Payload)\r\nVALUES (\r\n @orderId,\r\n @taskId,\r\n \'EXECUTE_REFUND\',\r\n JSON \'{"action": "execute_refund", "amount": 49.99}\'\r\n);\r\n\r\n-- COMMIT;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ade5dc50>)])]>

これにより、注文ステータスが REFUND_APPROVED に正常に移行した場合に限り、EXECUTE_REFUND タスクが存在するようになります。

2. 時間的スケジューリングとアトミックなキャンセル

エスカレーション前にマネージャーの承認を最大 72 時間待つなど、時間に依存するワークフローの場合、エージェントはシステム DeliverTime 列に値を入力して、メッセージの可視性を遅らせます。

code_block: <ListValue: [StructValue([('code', '-- Schedule an automated escalation check-in 72 hours in the future\r\nINSERT INTO OrderAgentTasks (OrderId, TaskId, TaskType, Payload, DeliverTime)\r\nVALUES (\r\n @orderId,\r\n @escalationTaskId,\r\n \'ESCALATE_UNAPPROVED_ORDER\',\r\n JSON \'{"action": "escalate_to_supervisor"}\',\r\n TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 72 HOUR)\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ade5c550>)])]>

マネージャーが 4 時間後にリクエストを承認した場合、アプリケーションは数日後に発生するファントムエスカレーションアラートに対処する必要はありません。1 回のトランザクションで、標準 SQL DELETE を使用して注文ステータスを更新し、保留中のエスカレーションタスクをキャンセルします。

code_block: <ListValue: [StructValue([('code', "-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET Status = 'MANAGER_APPROVED',\r\n ApprovedBy = @managerId\r\nWHERE OrderId = @orderId;\r\n\r\n-- Atomically cancel the pending delayed escalation task. `ASSERT_ROWS_MODIFIED 1` will\r\n-- act as a safeguard and cause a statement level error.\r\n\r\n-- A statement level error can be captured and the transaction can be\r\n-- user-aborted/cancelled in case the queue entry was already deleted.\r\n-- Otherwise the transaction will complete successfully regardless if the \r\n-- queue entry still exists and you'll only know if a queue entry was deleted by\r\n-- checking the number of rows affected by the DELETE.\r\nDELETE FROM OrderAgentTasks\r\nWHERE OrderId = @orderId\r\n AND TaskId = @escalationTaskId\r\n AND TaskType = 'ESCALATE_UNAPPROVED_ORDER',\r\nASSERT_ROWS_MODIFIED 1;\r\n\r\n-- COMMIT;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93af0f8450>)])]>

3. ストリーミング消費、リースの更新、アトミックな確認応答

ダウンストリームエージェントワーカーは、ストリーミング SQL 接続（ExecuteStreamingSql）経由で RECEIVE_<QueueName> テーブル値関数（TVF）を使用してタスクを消費します。Spanner はメッセージリースを自動的に管理し、リースされたタスクごとに一意の SpannerLeaseToken と有効期限のタイムスタンプを返します。

code_block: <ListValue: [StructValue([('code', "-- Step 1: Consume tasks via a long-lived streaming SQL query\r\nSELECT\r\n OrderId,\r\n TaskId,\r\n TaskType,\r\n Payload,\r\n SpannerLeaseToken,\r\n SpannerLeaseExpirationTimestamp\r\nFROM RECEIVE_OrderAgentTasks(max_duration => '20m');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93af0f9c10>)])]>

AI エージェントのタスクには、デフォルトのリース期間よりも長い時間を要するマルチターン LLM 推論や外部 API 呼び出しが含まれることが多いため、ワーカーは RENEWLEASE_<QueueName> 関数を使用してリースを積極的に延長できます。

code_block: <ListValue: [StructValue([('code', '-- Step 2: Extend lease ownership during long-running agent execution\r\nSELECT *\r\nFROM RENEWLEASE_OrderAgentTasks(lease_tokens => [@leaseToken]);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93af0f9b50>)])]>

エージェントは、外部ツールの実行を完了すると（このとき TaskId を外部 API のべき等キーとして渡します）、読み取り / 書き込みトランザクションを開いて最終状態を記録し、ASSERT_ROWS_MODIFIED 1 を使用してメッセージを削除することで確認応答（ACK）を行います。

code_block: <ListValue: [StructValue([('code', "-- Step 3: Atomically checkpoint agent results and ACK the message\r\n-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET RefundTransactionId = @externalRefundId,\r\n Status = 'REFUND_COMPLETED'\r\nWHERE OrderId = @orderId;\r\n\r\nDELETE FROM OrderAgentTasks\r\nWHERE OrderId = @orderId\r\n AND TaskId = @taskId\r\n AND TaskType = @taskType\r\nASSERT_ROWS_MODIFIED 1;\r\n\r\n-- COMMIT;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93af0f8e90>)])]>

ASSERT_ROWS_MODIFIED 1 を使用すると、リースの期限切れに伴う競合状態からシステムを保護できます。ネットワークの一時停止が原因でワーカーが停止し、リースが期限切れになった場合、別のワーカーがすでにタスクを処理して削除している可能性があります。停止したワーカーが再開してステートメントを実行しようとすると、ASSERT_ROWS_MODIFIED 1 は、キュー行がすでに存在しないことを検出し、ステートメントレベルのエラーをスローします。このエラーをキャッチしてトランザクションを中止することで、古いワーカーが新しいデータベースの状態を上書きするのを防ぎます。

Spanner 変更ストリームと Spanner キューの比較

Spanner の変更ストリームは、データベースのデータ変更（挿入、更新、削除）を準リアルタイムでキャプチャし、ダウンストリームの統合や監査に提供します。変更ストリームとキューはどちらも、アプリケーションがデータの変更を検知して処理できるようにするものですが、Spanner の変更ストリームは、継続的な変更データキャプチャ（CDC）や、ダウンストリームの分析 / ストレージへのデータストリーミング向けに設計されています。一方、Spanner キューは、トランザクションタスクのオーケストレーション向けに明示的に設計されており、ネイティブメッセージリース、スケジュール配信、SQL ベースの pull、読み取り / 書き込みトランザクション内でのアトミックな確認応答をサポートしています。

使ってみる

Spanner は、リレーショナル、ハイブリッド検索、グラフ、Key-Value の機能を厳格なグローバル整合性の下で組み合わせ、エージェントデータのための統合された基盤を提供します。Spanner キューは、エージェントが単一の統合プラットフォーム内でデータの推論からトランザクションアクションの実行にシームレスに移行できるようにすることで、エージェントループを完成させます。Spanner キューの一般提供が開始されました。

Spanner の 90 日間無料トライアルに登録し、公開ドキュメントをお読みください。Spanner データベースにキューテーブルを作成して、復元力のある exactly-once のエージェントワークロードの構築を今すぐ開始できます。

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

- エンジニアリングマネージャー兼 Cloud Spanner データストリーミングリード、Matthew Mucklo

JR東日本: Spanner と Cloud Run で「タッチトリガー」を実現し、改札データを起点に新たなコミュニケーションと価値を創出

Mon, 28 Sep 2026 02:00:00 +0000

利用しているサービス:
Spanner, Cloud Run, Cloud Logging, Cloud Tasks, Cloud Scheduler, BigQuery

東日本旅客鉄道株式会社（以下、JR東日本）が開発した「タッチトリガー」は、Suica の改札タッチをトリガー（起点）として、乗客のスマートフォンへタイムリーに情報を届ける新世代のコミュニケーションサービスです。この実現に向け、膨大なデータトラフィックを支えるインフラとして選ばれたのが、Google Cloud の Spanner と Cloud Run でした。開発の背景から、Google Cloud の製品が選ばれた理由、そして活用事例まで、マーケティング本部でプロジェクトを推進する 4 名に話を伺いました。

改札というリアルな接点から生まれる、生活に密着したデータ

日本最大の鉄道事業者として、乗客の移動を支える JR東日本。同社が発行する交通系 IC カード Suica は、2001 年のサービス開始以来、累計発行枚数が 1 億 2,000 万枚を超え、移動・決済のインフラとして、私たちの生活に欠かせないものとなっています。今、同社は Suica の利便性をより高め、活用範囲を広げる「Suica Renaissance」構想を進めています。その核となる技術のひとつが、乗客の改札通過データをもとに、さまざまな情報を提供する「タッチトリガー」です。マーケティング本部の戦略・プラットフォーム部門で副部門長を務める廣瀬道輝氏は、開発の背景にはコロナ禍があったと振り返ります。

「コロナ禍の最中、人々が通勤・通学や外出を控えざるをえなくなり、鉄道の利用者が大きく減るという事態に直面しました。『人の移動』という弊社事業の前提が揺らいだのです。その危機感のなかで、単に移動のインフラを提供するだけでなく、お客様の生活に寄り添い、一人ひとりに新しい価値を提案していく必要があると強く感じました。そこで生まれたのが『タッチトリガー』です。Suica に紐づく改札データを集約し、利用駅や時間帯、行動の文脈などに基づいて分析していけば、パーソナライズされた情報やサービスをお届けできます。私たちは改札タッチのタイミングをお客様とのコミュニケーションのきっかけにしたいと考えています。そのため『タッチトリガー』を、お客様の生活の利便性や快適さを上げていくための『コミュニケーション機能』として位置づけています。」

このような発想を根底で支えるのが、リアルなネットワークです。JR東日本の鉄道網は関東や東北、北陸に広がり、乗降客数は 1 日約 1,600 万人に上ります。ところが従来は、改札を通過した際に発生するデータはオンプレミスを軸にした社内システムで処理されており、巨大なポテンシャルをフルに活かしきれずにいました。この方法は、0.2 秒という超高速処理を実現するうえでは理にかなっていました。しかしマーケティングを担当するデジタルビジネスユニットの村上洋輔氏は、全社横断的なデータ活用が急務だったと振り返ります。

「改札ゲートはお客様の生活に密着したタッチポイントで、物理的な数の多さや、そこから得られるデータは、鉄道事業者ならではの強みだと考えています。また、あらゆる地域には駅を中心に商圏や生活圏が広がり、弊社のグループでもさまざまな部署が事業を展開していますので、データを横断的に活用すれば、大きなシナジーを生み出すことができます。そのためにも、運用基盤をクラウド化していくことが重要になっていました。折しも、Suica 全体をクラウド化していくという動きが全社的に進んでいましたので、『タッチトリガー』も、その流れと足並みをそろえることになりました。」

Spanner と Cloud Run で厳しいトラフィック処理の要件をクリア

ただし、データ処理のシステムをクラウドに移行するためには、厳しい技術要件がありました。まず 1 日のタッチ数は、山手線内の駅だけでも数百万回にのぼり、ラッシュ時には平常時の 10 倍にも跳ね上がります。無数の改札から送られてくるデータを、クラウド上のサーバーで処理するためには、トラフィックの急増に対応するスケーラビリティと、データを瞬時に記録する書き込み性能が鍵を握ります。これを満たすことができるのは、Google Cloud の製品だけだったといいます。

「ほぼすべてのクラウド型データベースで検証したところ、一般的な RDB（リレーショナルデータベース）では処理能力に上限があり、要件を満たせないことがわかりました。しかし Spanner だけは違いました。データを自動で振り分けながら、高い整合性を保つことができますし、Cloud Run と組み合わせることで、乗客の増減に応じてほぼタイムラグなくオートスケールできることもわかりました。テスト実装の段階で、想定どおりのスペックが出たことに開発チームは驚いていました。Spanner と Cloud Run がなければ、『タッチトリガー』を今の形で実現させることは難しかったでしょう。」（廣瀬氏）

実装の際には、いくつかの工夫もなされています。データ活用を行うには、年代や利用駅、購買履歴といった属性と、マーケティングの目標を瞬時に掛け合わせる作業が不可欠となります。ただし Spanner はデータの整合性を維持するために、独自のインデックス設計を採用しており、データ加工が必要となります。そこで技術的な支援を行ったのが、Google Cloud のサポートチームでした。

「本格的に Spanner を使うのは初めてでしたが、あまり試行錯誤することなく、最適解にたどり着くことができたと感じています。現場のエンジニアたちも、処理スピードやコスト最適化の方法や、Data Boost を活用した分析クエリに対するリソースの競合の回避方法など、多くのノウハウを吸収しました。Google Cloud と協働しながら改札システムのクラウド化を進めていけば、改札を抜けてホームに向かう間に、パーソナルな通知が届くような環境も構築していけると思います。」（廣瀬氏）

「タッチトリガー」が活性化させていく、毎日の暮らしと地域コミュニティ

「タッチトリガー」は 2024 年に山手線内の全駅に実装され、その後、JR東日本管内の新幹線停車駅や大井町などへ対象を広げています。最初に活用されたのは、同社が毎年開催している「山手線謎めぐり」というイベントでした。「タッチトリガー」のシステムやオペレーションを担当する、デジタルビジネスユニットの新名恵里佳氏は、盛り上がりを鮮明に覚えていました。

「これは沿線の街を散策しながら、謎解きをしていく体験型のイベントで、毎年多くの方にご参加いただいています。2024 年は Suica をタッチすると、駅に応じたコンテンツが配信される仕組みを採り入れました。参加した方からは『Suica でこんなことができるんだ！』という驚きの声があがっていました。その後、2025年には『みんなのトレインタウン』というスマホゲームでも、ミッションの達成条件に『改札タッチ』を組み込み、アイテムを獲得できるようにする施策なども行っています。」

また、JR東日本が推進する「まちづくり」との連携も進んでいます。同社は駅と接続する大型複合施設「TAKANAWA GATEWAY CITY」を 2025 年にオープン。その「まちびらき」に伴い、実証実験が行われました。同本部まちづくり部門品川ユニットチーフの小坂和広氏は、反響の大きさが想像以上だったと説明します。

「弊社のオフィスでは入館管理に Suica を使っており、この方法を他の用途に活用できないかという声は以前からありました。ちょうど全社的に『タッチトリガー』のプロジェクトが始まっていましたので、アプリと Suica を連携していただいたユーザーの方を対象に、改札を出ると施設内のお店でドリップコーヒーをプレゼントするクーポンを配信しました。アプリはローンチしたばかりでしたが、用意した 800 袋を 4 日間で配り終えるなど、想像以上の効果が得られました。提案する情報や通知のタイミングを含め、テストを重ねてより良い方法を探っていければと考えています。」

2026 年 3 月には大井町駅で、コンビニエンスストアの NewDays と連携し、おすすめ情報やクーポンを配信する施策が開始されています。一方、新幹線では、より踏み込んだ取り組みが行われてきました。村上氏によれば、2025 年には「GunMaaS」（群馬県内のさまざまな交通手段をシームレスに結びつけるスマートフォン向けサービス）と連携し、高崎駅で降りる乗客にタクシーを配車する試みが始まりました。「新幹線は『タッチトリガー』の展開という点で、非常にわかりやすいケースになっています。お客様が利用される便の時間や目的地、車内での滞在時間はあらかじめ把握できますので、乗車中はドラマや漫画などのコンテンツをご案内し、現地についたときには地元のタクシー会社がすでにお待ちしている。観光や宿泊情報のご提案なども、その方のニーズや志向に合わせて実施することができます。これを重ねていくことで、お客様と各事業者双方にとって Win-Win の関係を構築できます。」現在、同社は JRE ID の一本化に取り組んでおり、2028 年に Suica アプリ（仮称）が新たにリリースされれば、本格的な 1 to 1 コミュニケーションも可能になる見込みです。改札ゲートを起点に、データ活用の在り方が変わり、地域社会が変わり、毎日の生活が変わっていく。「タッチトリガー」と JR東日本の挑戦は、さらに加速していきます。

「『タッチトリガー』は、駅商圏を中心にサービスを展開する事業と特に相性が良いので、グループ外の企業とも実証実験を進めていく予定です。むろんお客様に安心してご利用いただけることが何よりも大切ですので、各種アプリと連携する際にはお客様の同意を得たうえで、情報を必要な範囲に限り、適切かつ安全に取り扱います。そのうえで『タッチトリガー』を軸にコミュニケーションを充実させ、すべての駅を、クオリティオブライフの充実や新たな事業展開、そして地域活性化を推進するハブにしていければと考えています。」（廣瀬氏）

東日本旅客鉄道株式会社（JR東日本）
1987 年に日本国有鉄道（国鉄）の分割民営化により設立。首都圏を中心に関東甲信越から東北までの東日本エリアの鉄道網を管轄し、営業キロは 7,418.7 km、輸送人員は 1 日あたり約 1,600 万人を誇る世界最大級の旅客鉄道会社。従来の交通事業に加え、Suica を核とするデジタルトランスフォーメーション、駅ビルや商業施設を中心としたまちづくりを推進。国際交流拠点「TAKANAWA GATEWAY CITY」、都市生活共創拠点「OIMACHI TRACKS」を中心とした「広域品川圏」の都市開発にも取り組む。

インタビュイー（写真右から）:
マーケティング本部
・戦略・プラットフォーム部門副部門長　廣瀬道輝氏
・戦略・プラットフォーム部門デジタルビジネスユニット　村上洋輔氏
・戦略・プラットフォーム部門デジタルビジネスユニット　新名恵里佳氏
・まちづくり部門品川ユニット TAKANAWA GATEWAY CITY（デジタルサービス戦略）チーフ　小坂和広氏

※文中の組織名・役職名は取材当時のものです。

その他の導入事例はこちらをご覧ください。

Spanner: DML トランザクションの累積ミューテーション上限を撤廃

Thu, 17 Sep 2026 02:00:00 +0000

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

Spanner は、Google Cloud の妥協のない業務データベースです。水平スケーリングや常時稼働の可用性といった最新の分散型システムの利点に加え、豊富な機能セットや使い慣れたエコシステムといったリレーショナルデータベースの利点を兼ね備えています。現在、銀行、小売、メディア、エンターテイメント、AI インフラストラクチャなどの業界のイノベーターが、最も重要なワークロードに Spanner を利用しています。この Spanner において、このたび、より大規模かつ複雑なトランザクションを柔軟に処理する新しい方法が導入されたことをお知らせします。これにより、最高レベルのデータ整合性を必要とするアプリケーションを簡素化できるようになります。

一般に、業務のワークロードは、リアルタイムの意思決定ときめ細かい更新の組み合わせです。たとえば、e コマースアプリで複数ステップの購入手続き中に不正行為を特定する場合を考えてみましょう。このような変更はトランザクション単位、つまり、すべてが成功するか、すべてが失敗するかのどちらかである必要があります。また、後続のリクエストが正しいデータを参照できる必要があります。Spanner の ACID トランザクションに対する今回のアップデートにより、アプリケーションは使い慣れた DML を使用して、整合性、スケーラビリティ、可用性を損なうことなく、更新時により多くのデータを処理できるようになります。

高い上限で柔軟性が向上

これまで Spanner では、クエリが 1 回のトランザクションで実行できる変更（DML を使用する場合など）の上限が 80,000 件でした。これは、更新する行数と列数の積に、依存するインデックスを加えたものとして大まかに計算されていました。アプリケーションは、時間の経過とともに、より多くのデータを処理し、新しい機能を提供できるように進化します。こうした進化に伴い、トランザクションのサイズが拡大すると、以前は小さかったトランザクションがこの上限に達する可能性が生じます。

今回のアップデートでは、80,000 件というミューテーション数の上限がトランザクションから個々の DML ステートメントに移行されます。DML ステートメントは、トランザクションレベルの全体的なミューテーション数の上限に影響しなくなります。INSERT、UPDATE、DELETE など、個々の DML ステートメントが生成するミューテーション数が 80,000 件未満である限り、1 つのトランザクションにいくつでも DML ステートメントを含められるようになりました。

主なメリット

大規模なトランザクション: 累積ミューテーション数の上限に準拠するために、DML ステートメントを人為的に分割するのではなく、ビジネス要件に基づいて論理的にグループ化できます。
シームレスな移行: 今回の変更は、既存のすべての Spanner クライアントライブラリと互換性があるため、アプリケーションコードの更新は不要です。

技術的な考慮事項

ロックと中止

1 つのトランザクションに含めることができる DML ステートメントの数が増えた一方で、トランザクションの規模が拡大して実行時間が長くなると、ロックが保持される時間も長くなることに注意が必要です。これにより、ロックの競合やトランザクションの中止が発生する可能性が高まります。トランザクションを簡潔に保つことで、高いパフォーマンスを維持し、リソースの競合を最小限に抑えることができます。

DML と Mutation API

上限の適用は、データを変更する方法によって異なります。

DML ステートメント: 各ステートメント（executeUpdate など）がミューテーション数の上限 80,000 件に対して個別に評価されます。
Mutation API: insert() や update() など、クライアントライブラリのメソッドを使用する場合、ミューテーションは Commit 呼び出し中に提供されます。80,000 件の上限は引き続き、その 1 回の呼び出しに含まれるミューテーションのセット全体に適用されます。

ミューテーション数について

Spanner では、変更されたセル、主キー、セカンダリインデックスの更新を含め、変更の複雑さに基づいてミューテーション数が数えられます。ミューテーションの数え方について詳しくは、こちらのブログをご覧ください。commit されたトランザクションの合計ミューテーション数は、CommitStats の mutation_count を使用して確認できます。mutation_count には、すべての DML ステートメントと commit 呼び出しにわたって、トランザクションの一部であるすべてのミューテーションが含まれます。

Java の実装例

次の例は、新しい上限のロジックで、1 つのトランザクション内で複数の DML ステートメントを実行する方法を示しています。

code_block: <ListValue: [StructValue([('code', 'import com.google.cloud.spanner.DatabaseClient;\r\nimport com.google.cloud.spanner.Statement;\r\nimport com.google.cloud.spanner.TransactionContext;\r\nimport com.google.cloud.spanner.TransactionRunner.Work;\r\n\r\n// Assuming dbClient is your initialized DatabaseClient\r\ndbClient\r\n .readWriteTransaction()\r\n .run(\r\n new Work<Void>() {\r\n @Override\r\n public Void doWork(TransactionContext transaction) throws Exception {\r\n // Each executeUpdate call is evaluated separately against the 80k mod limit.\r\n\r\n // Example 1: Updating specific products\r\n Statement stmt1 = Statement.newBuilder(\r\n "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")\r\n .bind("productId").to(1L)\r\n .build();\r\n transaction.executeUpdate(stmt1); // Verified against 80k limit\r\n\r\n Statement stmt2 = Statement.newBuilder(\r\n "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")\r\n .bind("productId").to(2L)\r\n .build();\r\n transaction.executeUpdate(stmt2); // Verified against 80k limit separately\r\n\r\n // Example 2: Inserting related order data\r\n Statement stmt3 = Statement.newBuilder(\r\n "INSERT INTO OrderItems (OrderId, ItemId, Quantity) VALUES (@orderId, @itemId, @qty)")\r\n .bind("orderId").to(100L)\r\n .bind("itemId").to(1L)\r\n .bind("qty").to(2)\r\n .build();\r\n transaction.executeUpdate(stmt3); \r\n\r\n Statement stmt4 = Statement.newBuilder(\r\n "UPDATE Orders SET LastUpdated = PENDING_COMMIT_TIMESTAMP() WHERE OrderId = @orderId")\r\n .bind("orderId").to(100L)\r\n .build();\r\n transaction.executeUpdate(stmt4); \r\n\r\n return null;\r\n }\r\n });'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ae4af590>)])]>

変更がない点

個々のステートメントの上限: 1 つの DML ステートメントが生成するミューテーション数が 80,000 件を超える場合は、現在と同じエラーが返されます。
その他のトランザクション上限: 最大トランザクションサイズ（バイト単位）など、その他の制約は引き続き有効です。詳細については、こちらをご覧ください。

ベストプラクティス

CommitStats をモニタリングする: CommitStats で返される mutation_count を利用して、処理によって生成される負荷を把握します。
大規模な処理を最適化する: 1 つのステートメント（一括更新など）が上限を超える場合は、パーティション化 DML の使用や、キーによるページ分けを検討します。

Spanner は、ダウンタイムなしでスケールする必要がある業務アプリケーションの選択肢として、信頼性に優れています。ミューテーション数の上限が引き上げられたことで、デベロッパーは Spanner のグローバル規模での整合性を活用して、より大規模なトランザクションを柔軟に実行できるようになります。Spanner を使用して、リスクを抑えつつイノベーションを推進する方法をご確認ください。また、無料トライアルや、月額わずか 54 ドルから利用できる本番環境インスタンスで、実際にお試しいただくこともできます。

外部の関連資料

- スタッフソフトウェアエンジニア、Rajeshwar Vanka

- プロダクトマネージャー、Justin Makeig

パブリックデータとプライベートデータを統合: Spanner のデータコモンズによるナレッジグラフのスケーリング

Wed, 19 Aug 2026 01:30:00 +0000

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

的確な意思決定を行うために、企業は社内データと公開リファレンスデータを接続し、実世界の事物とその関係性を可視化するナレッジグラフを作成する必要に迫られることがよくあります。しかし、パブリックとプライベートのデータをつなぐには、従来、非常に複雑なプロセスを要していました。このたび、Spanner Graph でのデータコモンズの一般提供と、新しいデータコモンズプラットフォームのプレビュー版のリリースにより、これらの接続を効率化し、独自のナレッジと公開データセットのナレッジグラフを統合できるようになりました。

包括的なデータコモンズプロジェクトは、世界中の情報を整理し、世界中の人がアクセスできて使えるようにするという Google の使命を後押ししています。データコモンズは、国連、世界銀行、米国国勢調査局、ユーロスタット、WHO、NOAA など、100 を超える信頼できるデータ提供元の断片化された公開データセットを統合しており、標準化された Schema.org 定義で構造化された 4,000 億を超えるデータポイントを網羅しています。データコモンズは、クリーンなデータセットにアクセスして統合するためのデータ探索ツール、MCP ツール、クラウドベースの API を提供します。

データコモンズは、農業、人口統計、経済、環境、保健など、複数の分野にわたる公開情報を統合します。この標準化されたアプローチにより、強力なユースケースが可能になります。たとえば、国の GDP トレンドの分析、地域的な煙による汚染レベルのマッピング、地方自治体レベルでの健康の公平性の追跡、人口分布の経時的な変化の把握など、これらすべてを、事前処理と正規化が済んだデータを使用して行うことができます。

データコモンズナレッジグラフのディメンション

ディメンション	サイズ	技術的な説明
統計的観測	4,000 億以上	個々の指標データポイント
グラフのエッジ	26 億以上	関係
ナレッジグラフのノード	17 億以上	標準化されたエンティティ
データソース	100 以上の提供元	信頼できる機関

データコモンズは、膨大な公的行政データを、即座に活用可能なクラウドベースのインフラストラクチャを通じてユーザーに提供します。

Spanner Graph を活用したモダンなインフラストラクチャ

データコモンズを最初に構築した際、Google が目指したのは、当時利用可能だったツールを用いて、膨大かつ多種多様な公開データセットを統合することでした。このプラットフォームは、キャッシュレイヤとして Bigtable を利用していました。これは、ネイティブのグラフデータベーステクノロジーが利用できなかった当時、大規模なルックアップを処理するための効果的な手法でした。

現在、Google はアーキテクチャをネイティブのグラフモデルである Spanner Graph に移行しました。これにより、SQL ライクなインターフェースの利便性とグラフの表現力が Spanner に備わるとともに、Spanner の強みである高可用性、水平スケーリング、マルチリージョンでのトランザクション整合性、そしてネイティブの ISO/IEC 39075 Graph Query Language（GQL）サポートが活用可能になりました。

マルチエンティティ Spanner Graph スキーマを採用することで、エンティティをノードとして、ドメインリンクを動的なグラフエッジとして表現できるようになりました。これにより、事前計算されたキャッシュ構造から脱却し、GQL を用いてデータベース内で直接、複雑な関係性クエリを実行することが可能になりました。

このアーキテクチャでは、費用のかかるインメモリでの再構築や複数のスナップショットを必要とする、複雑な事前計算インデックスが不要になるため、パイプラインも簡素化されます。Spanner Graph では、データベース全体を更新せずに特定のデータセットを増分更新できます。また、ステイル読み取りにより、データの取り込み中も一貫したデータスナップショットが維持されます。

Spanner Graph への移行による主なメリット

統合ストレージと増分更新: Spanner Graph のマルチエンティティスキーマを利用することで、複雑なキャッシュを増分データのインポートをサポートするモデルに置き換え、特定のデータセットに絞った更新を実現しています。
GraphRAG による動的なグラフトラバーサル: 大陸 → 国 → 州 → 郡 → 市といった階層をその場で辿るような、マルチホップクエリを実行します。これにより、静的キャッシュへの依存が解消され、データベースが自然言語クエリを構造化されたパスマッチングトラバーサルに直接マッピングする GraphRAG ワークフローが可能になります。
整合性のあるデータスナップショット: Spanner の TrueTime とステイル読み取りを活用することで、バージョン整合性のあるデータスナップショットを提供し、バッチ取り込みサイクル後も分散ノード全体でデータの一貫性を維持します。
大規模なオペレーショナル分析: Spanner のカラム型エンジンは、必要なフィールドのみを読み取ることで、大規模な時系列データセットを効率的にスキャンします。一方、Spanner の Data Boost テクノロジーを活用した BigQuery 連携 により、隔離された環境で EXTERNAL_QUERY を介して複雑な集計を実行できるようになり、本番環境のトラフィックを分離するのに役立ちます。

SDMX 3.0 の相互運用性によるシステムの橋渡し

複雑な統計データの活用を容易にするため、データコモンズでは、Statistical Data and Metadata eXchange（SDMX）技術標準のリーン実装を採用しています。SDMX は ISO 仕様として、統計データと記述的な統計メタ情報を記述および交換するための一貫したアプローチを提供します。

今回のデータコモンズプラットフォームのアップデートでは、SDMX 技術標準バージョン 3.0 のサポートが追加されました。これにより、多次元データセットにおいて、Tableau、Flourish、Observable などのサードパーティツールとの即座の連携が可能になります。これは、API 標準の SDMX-JSON および SDMX-CSV 2.0 形式を使用して、2 つの重要なエンドポイントを介して可能になります。

アベイラビリティ API: 生のデータを読み取ることなく、既存のディメンション、変数、日付範囲を特定するための、プログラムによる検出メカニズム。
データ API: 実際の観測データとメタデータを取得します。名前付きパラメータを使用することで、ディメンションが追加された際にコードが壊れるのを防ぐことができます。

データコモンズプラットフォームのプライベートインスタンスの変革

データコモンズプラットフォームのプライベートインスタンスを構築したい組織にとって、この新しいモダンなアーキテクチャは、従来のスケーリング制限を解消し、データスキーマ化を簡素化します。デベロッパーは、Google のデータコモンズインスタンスを支えるのと同じスケーラブルなテクノロジーを活用して、データコモンズプラットフォームのプライベートインスタンスをインスタンス化できます。プライベートインスタンスでは、ユーザーは自身のデータを完全に管理し、アクセスを制限することができます。その一方で、自然言語クエリを活用して、独自のプライベートデータと Google データコモンズインスタンス上の公開データをシームレスに組み合わせて表示することも可能です。Google の公開ナレッジグラフと、お客様独自のデータを含むプライベートナレッジグラフを連携させることで、データの分離を維持し、データの重複を回避しながら、魅力的な新しいユースケースを実現できます。

たとえば、小売企業は、国の GDP 推移、地域の人口構成の内訳、雇用統計などの公開データと、販売履歴、店舗のパフォーマンス指標、サプライチェーンのロジスティクスといった自社データを組み合わせることができます。これにより、アナリストはマクロ経済の公開指標と自社の取引データを照らし合わせて、商品の流通を最適化し、未開拓の市場を特定することが可能になります。

データコモンズプラットフォームのプライベートインスタンスに保存されている商業情報統計局（DGCIS）の統計データと、Google データコモンズのパブリックインスタンスに保存されている世界銀行の世界開発指標を組み合わせた自然言語クエリの実行例。

ユーザーが、国内の年平均気温の推移についてデータエージェントに問い合わせを行っている様子。エージェントはデータコモンズから情報を取得し、過去のデータが利用可能であることを説明した上で、予測される気温変化、気候要因、CMIP6 気候モデルシナリオ（SSP）を提供し、生成されたレポートをエクスポートするオプションを提示します。

ユーザーがデータエージェントに対し、ある国の農村部と都市部における男性の就業者人口比率（WPR）を比較するよう指示している場面。エージェントは、データコモンズからデータを取得し、WPR（総人口に対する就業者の割合）を定義して、両グループを分析および比較するために利用可能な人口統計変数の概要を示します。

早速始めましょう

データコモンズを探索する: datacommons.org にアクセスして、グローバルな統計知識を検索してみましょう。
ナレッジグラフ向けの Spanner Graph のユースケースと設定ガイドをご覧ください。
データコモンズプラットフォームをデプロイする: support@datacommons.org に連絡して、プレビューアクセスをリクエストし、デベロッパーツールをご確認ください。

- データコモンズ、シニアテクニカルプログラムマネージャー、Randeep Toor

- データベース担当グループプロダクトマネージャー、Piyush Mathur

Spanner のマルチモデルアーキテクチャでエージェントの時代を加速

Wed, 22 Jul 2026 00:00:00 +0000

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

エージェントの時代において、データベースの役割は根本的に変化しました。もはや単なる受け身のデータ保管場所ではありません。生成 AI アプリやモデルを支え、自律型ワークフローを強化する重要なコンテキストエンジンへと進化しています。これを効果的に行うには、データベースは断片化されたアーキテクチャから脱却し、統合されたマルチモデル基盤を採用し、深い推論を促進して、静的データをアクションシステムに変換する必要があります。

Spanner はこの取り組みを主導しており、Google の Agentic Data Cloud の基礎となる柱として、業界の注目を集めています。2025 年度の Gartner® Critical Capabilities for Operational Cloud Database Management Systems レポートで、Google（Spanner）は 2 年連続で軽量トランザクションユースケースで第 1 位にランクインしました。これは、最新のマイクロサービスとイベントドリブンアーキテクチャにとって最も効率的なエンジンであることを証明していると私たちは考えています。

Gartner® Operational Cloud DBMS ユースケース:

軽量トランザクションで第 1 位
トランザクションの整合性で 4.9 / 5.0
AI / ML および生成 AI で 4.6 / 5.0

この技術的な勢いは、最近 Spanner が名誉ある SIGMOD Systems Awardを受賞したことにも表れており、紛れもない経済的価値にも裏打ちされています。Google Cloud の委託により Forrester Consulting が実施した最近の Total Economic Impact™（TEI）調査では、ある組織（Forrester の調査による複合的な顧客プロファイルに基づく）は Spanner を導入したことで、9 か月という短い投資回収期間で 132% の ROI を実現し、3 年間で 774 万ドルの総利益を達成したことがわかりました。

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

AI の真の自律性には、深いコンテキストが必要です。AI エージェントが効果的に推論するには、単一のレンズを通してデータを見るわけにはいきません。構造化された履歴（リレーショナル）、セマンティクスな意味（ベクトル）、現実世界のつながり（グラフ）、テキストの詳細（全文検索）を同時に理解する必要があります。

Spanner は、これらのマルチモデルの障壁をネイティブに解消します。Spanner は、別々のエンジンを無理やりつなぎ合わせるのではなく、リレーショナル、ベクトル、グラフ、Key-Value、全文検索のデータを、単一の高性能なデータベースアーキテクチャ内で直接統合します。このアーキテクチャ統合により、AI モデルは状況に関するコンテキスト、意味的なコンテキスト、関係性のコンテキストを即座に同時に活用できるようになります。

Spanner の完全な相互運用性を備えたマルチモデル機能により、組織は妥協することなくインテリジェントなアプリケーションを構築できます。

Spanner Graph: ISO 標準の GQL を基盤とする、グラフとリレーショナルデータを統合したエクスペリエンスを提供します。データをグラフとしてネイティブにモデル化することも、リレーショナルデータの上にオーバーレイとしてモデル化することも可能です。これは、AI エージェントを実世界の事実に基づいてグラウンディングするためのナレッジグラフを構築するうえで非常に重要です。Palo Alto Networks をはじめとする企業は、Spanner Graph を活用して、地球規模での重要なアクセス制御のユースケースを実現しています。これにより、専用のサイロ化されたグラフデータベースを用意することなく、AI インフラストラクチャのセキュリティを確保しています。
統合ベクトル検索: K 最近傍（KNN）検索と近似最近傍（ANN）検索の両方に対応した、完全統合型のセマンティック検索ソリューションを提供します。100 億を超えるベクトルを含むインデックスにも対応でき、高速かつ低レイテンシの検索拡張生成（RAG）を実現します。
リレーショナルとKey-Value: Spanner は、リレーショナルスケールアウトデータベース（GoogleSQL と PostgreSQL）の先駆けです。また、Cassandra ネイティブエンドポイントを介して高性能な Key-Value 機能も導入し、Cassandra ワークロードの簡単なリフト＆シフトを可能にしました。
全文検索: Google が数十年にわたり培ってきた検索技術を基盤に、Spanner は構造化データと非構造化データの両方を横断して高度な情報検索を提供します。また、類義語の自動マッチとスペル修正を行う enhance_query オプションも備えています。ストリーミング法務インテリジェンスプラットフォームの Inspira は、4.5 TB のデータパイプラインを、統合された高パフォーマンスの信頼できる唯一の情報源へと簡素化しました。FTS とベクトル検索機能をネイティブにサポートする Spanner を活用することで、RAG ワークフローを使用した LLM ベースの法的分析において高精度のスニペットを実現しました。
Spanner カラム型エンジン: この画期的なアーキテクチャにより、ライブ運用データに対する分析クエリが最大 200 倍高速化されます。これにより、OLTP と分析とのギャップが解消され、エージェントは「ETL（抽出、変換、読み込み）の負担」を負わずに、必要なリアルタイムのコンテキストを得ることができます。AI を活用した不正防止プラットフォームの Verisoul は、カラム型エンジンを使用して、高速なトランザクション書き込みに対する豊富な分析を 1 か所で実行し、データのコピーやレプリケーションの遅延を排除して、ほぼ瞬時に回答を得ることができます。

真の相互運用性とは、これらが単なる個別の機能ではなく、緊密に統合されていることを意味します。グラフデータベース、ベクトルデータベース、検索エンジンを統合するために複雑なアプリケーションロジックや脆弱な ETL パイプラインを作成する代わりに、開発者は ACID に準拠した単一の SQL ステートメントで、関係性、セマンティックな意味、キーワードをクエリできます。

以下は、開発者がリレーショナル検索、グラフ走査、全文検索、ベクトル類似性検索を 1 つのまとまりのあるクエリに組み合わせて、インテリジェントな商品レコメンデーションエージェントを強化する方法の一例です。

Spanner Omni: マルチモデル機能をどこでも利用可能

Agentic Data Cloudの真の統合データ基盤となるには、データベースがインフラストラクチャの境界に制限されてはなりません。そこで、AlloyDB Omni と同様に、ハードウェアの制限なしにマルチモデル機能をあらゆる環境で利用できるようにする Spanner Omni を開発しました。

Spanner Omni は、完全にコンテナ化されたデプロイモデルで Spanner をダウンロードして使用できるバージョンです。専用のハードウェアは一切必要ありません。最大限の柔軟性を念頭に設計されており、すでに所有しているインフラストラクチャを使用して Kubernetes 上でネイティブに実行されます。ワークロードがオンプレミス、エッジ、または AWS や Azure などの他の主要なパブリッククラウドで実行されている場合でも、Spanner Omni を使用すると、自在なコントロールが可能になり、一貫性のあるグローバル分散データ基盤を確保できます。

つまり、組織は Spanner Graph、ベクトル検索、全文検索、カラム型エンジンをどこでも活用でき、クラウドサイロを効果的に解消して、ベンダーロックインなしでこれらの最先端の機能を利用できるようになります。

業界の基準を確立するコアデータベースの機能

2025 年度の Gartner® Critical Capabilities for Cloud Database Management Systems for Operational Use Cases レポートで、Gartner は 2 年連続で Google（Spanner）を軽量トランザクションユースケースで第 1 位に選出しました。これは、最新のイベントドリブンマイクロサービスにおける効率性と低レイテンシを証明するものです。

こうした業界からの評価は、単なる市場での存在感を示すだけのものではありません。Spanner を従来のアーキテクチャと一線を画す存在にしている、根源的な技術革新に裏打ちされた結果であると私たちは考えています。ばらばらでサイロ化されたデータベースエンジンをつなぎ合わせて「マルチモデル」と称するプラットフォームや、データベース作成時にユーザーがモダリティを選択する必要があり、モダリティ間の相互運用性がないプラットフォームとは異なり、Spanner の機能は、Google の最先端コンピュータサイエンスを基盤として構築されています。

TrueTime と Paxos によるグローバルな整合性: Spanner の分散トランザクションは、GPS と原子時計を利用した、可用性が高くグローバルに同期されたクロックシステムである TrueTime に則って管理されます。これにより、ロックフリーの分散読み取りと厳格な外部整合性をグローバルに実現できます。高度に最適化された Paxos コンセンサスと組み合わせることで、Spanner はリージョン全体で障害が発生した場合でも、データ損失ゼロ（目標復旧時点、つまり RPO=0）の同期レプリケーションと迅速な復旧タイムライン（目標復旧時間、つまり RTO=0）を実現します。
統合されたカラム型エンジン: ETL の負担をなくし、OLTP と OLAP のギャップを埋めるために、画期的なカラム型エンジンを Spanner の分散ストレージレイヤ（Colossus）に直接統合しました。これにより、開発者はトランザクションのパフォーマンスに影響を与えることなく、ライブ運用データに対して複雑な分析クエリを最大 200 倍高速に直接実行できます。また、ストレージとコンピューティングが完全に分離されているため、ユーザーはデータベースストレージに直接アクセスするサーバーレステクノロジーである Spanner DataBoost を使用して、運用ワークロードに影響を与えることなく大規模な分析クエリを実行できます。
ScaNN を活用したベクトル検索: Google のネイティブベクトル検索は、後付けの機能ではありません。このサービスは、Google 検索や YouTube と同じ最先端のインデックスアルゴリズムである Scalable Nearest Neighbors（ScaNN）を基盤としています。これにより、Spanner はリレーショナルデータやグラフデータと並行して、100 億を超えるベクトルインデックスに対してミリ秒以下の速度で類似検索をネイティブに実行できます。
動的リシャーディング: Spanner のアーキテクチャでは、サイズと負荷に基づいてデータが自動的にリシャーディングされます。この透過的なロードバランシングにより、従来の NoSQL システムや分散 SQL システムで問題となっていた「ホットスポット化」が解消されます。

業界の評価では、個別のデータベースエンジンを切り離して捉える断片的な視点で市場を測定することが少なくありません。しかし Google は、真のイノベーションを実現するには、このレベルの深いアーキテクチャ統合を可能にするエンジニアリングが必要であると考えています。エージェントの時代には、ネイティブに統合された基盤以外のものは単なるボトルネックです。

エージェントの時代の統一ビジョン

Google は、データの未来は、統合され、オープンであり、そして AI と切り離せないものになると考えています。Spanner の勢いは、隔離されたデータベースの寄せ集めから、単一のインテリジェントな Context Hub へと急速に移行している市場を反映しています。

この未来に正面から向き合うため、Google は一つの統合データベースで可能なことを絶え間なく拡大し続けています。これには、リアルタイム分析用の統合カラム型エンジン、Google の世界クラスの ScaNN テクノロジーを搭載したネイティブベクトル検索、モデル推論をデータに直接適用する組み込みの AI 関数などの画期的なイノベーションが含まれます。さらに、深い予測推論のためにグラフニューラルネットワーク（GNN）と統合された Spanner Graph と、この統合アーキテクチャをハイブリッド環境とマルチクラウド環境に拡張する Spanner Omni を統合することで、Google は次の時代を見据えたプラットフォームを提供しています。

重要なのは、Spanner は単独で存在するのではなく、Google のより広範な Agentic Data Cloud の基礎となる柱であることです。Spanner は、企業全体の分析のための BigQuery や高度なモデルオーケストレーションのための Gemini Enterprise Agent Platform を含むデータクラウド全体でシームレスなゼロ ETL 統合を実現し、運用データと企業インテリジェンスの間の障壁を解消します。

エージェントの時代では、AI モデルは単なる隔離されたデータポイント以上のもの、すなわち、まとまりのあるエコシステムを必要とします。Spanner からのリアルタイムの運用コンテキストと、BigQuery からのペタバイト規模の過去の分析情報をネイティブに統合することで、エージェントが自律的に行動し、深く推論し、前例のないビジネス価値を創出できるようにします。

Spanner は、データの保存場所に関係なく、リアルタイムで信頼できる多面的なデータビューを提供することで、組織が次世代の変革的なインテリジェントアプリケーションを構築できるようにします。

Google は、今後の展開に非常に期待しており、真のマルチモデルデータベースが実現しうる可能性のフロンティアを、これからも切り拓き続けてまいります。

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

^{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 および Magic Quadrant は、Gartner, Inc. および / またはその関係会社の米国およびその他の国における登録商標であり、同社の許可を得て使用されているものです。かかる権利はすべて留保されています。}

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

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

- データベース担当プロダクト管理ディレクター、Vaibhav Govil

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: Yahoo の事例

Wed, 24 Jun 2026 01:00:00 +0000

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

エージェント型 AI を導入する企業にとって必要なのは、事後対応型のインテリジェンスシステムから、プロアクティブなアクションシステムへの転換です。これは、必要とされるコンテキストとパフォーマンスを備えたエージェントを構築するとともに、すべての意思決定について説明と監査が可能な、規制当局の要求に対応できるレベルの説明責任を担保するためです。

Google Cloud Next ‘26 では、Agentic Data Cloud でアクションシステムを実現する方法について解説しましたが、まさにこのビジョンの好例となるのが Yahoo のデジタルメディア購入プラットフォームです。Yahoo は Google Cloud と提携し、Google データクラウドのグラフ技術を活用して、Seller Agent デジタルメディア購入プラットフォームを構築しました。Seller Agent は、数週間かかる手動プロセスをわずか数秒に凝縮して、完全に管理されたライブキャンペーンを実行できます。自律システムが厳格な説明責任を維持しながら驚異的なスピードで動作できることを証明するこのシステムは、さまざまな業界で活用できる強力なブループリントとなります。

「Yahoo! の使命は、デジタルの世界を案内する、信頼されるガイドになることです。Google Cloud とのパートナーシップを通して迅速性、透明性、効果、信頼性を確保したエージェント型メディア購入を実現することで、私たちは広告主様に対してもこの約束を果たしていきます。」- Yahoo、収益化責任者、Gabriel DeWitt 氏

このブログでは、エージェント型 AI への移行について詳しく説明し、Yahoo の Seller Agent アーキテクチャがメディア購入におけるスピードと信頼性の課題をいかに解決しているかを検証します。また、このグラフベースのパターンを応用して、皆様の組織で信頼できるアクションシステムを構築する方法もご紹介します。

ケーススタディ: エージェント型メディア購入

長年にわたり、プレミアムデジタル広告キャンペーンのような複雑で価値の高いワークフローでは、人手を介した数週間にわたる引き継ぎ、断片化したスプレッドシート、そして手動の分析が必要とされてきました。Yahoo は、エージェント型 AI を使えば、このタイムラインを劇的に短縮し、わずか数秒でキャンペーンを計画して実行できる可能性があることに着目しました。「手動から自律的な実行へ」というこの飛躍は、運用効率を大幅に改善し、投入した予算をより確実に測定可能な成果へと結びつける大きなチャンスでした。

しかし、リスクの高いワークフローに LLM をただ組み込むだけでは問題は解決しません。もし、リアルタイムの広告在庫や、価格設定ルール、ビジネス上の制約を決定論的に理解できていないエージェントが契約や広告掲載の交渉を行えば、ハルシネーションが生じやすくなり、甚大な損失を招く取引となるおそれがあるからです。信頼できるエージェントプラットフォームには、統計的な推測ではなく、確固たる事実に基づいて行動するためのリアルタイムかつ決定版の情報源が不可欠です。

しかも、「スピード」と「事実へのグラウンディング」は必要とされる条件の半分にすぎません。AI エージェントが実際の予算を動かし始めた瞬間、その動作は規制当局の厳しい監視の対象となります。そして規制当局は、特定の決定がなぜ行われ、どのポリシーが適用されたのかについて即座に説明できることを求めてきます。事後にシステムログをさかのぼって調べるような手法は、自律的な実行を管理する手段としては不適切です。実用できるレベルのアクションシステムには、後付けではなくワークフローに直接組み込まれた、規制当局の要求に対応可能なガバナンスと監査可能性が必要です。

信頼できるアクションシステムのアーキテクチャ

Yahoo! の使命は、デジタル世界を案内する、信頼できるガイドになることです。エージェント型メディア購入は、予算を Yahoo に託し、真の説明責任が果たされることを期待する広告主、代理店、パブリッシャー、そして規制当局に対しても、その約束を広げていくものです。課題は、説明可能、管理可能、監査可能な方法でキャンペーンの実施を自動化することでした。

この課題に対処するため、Yahoo は Google Cloud で実行されるマルチエージェントシステムとして Seller Agent を構築しました。バイヤーのリクエストは、Google Kubernetes Engine（GKE）で実行され、Google の Agent Development Kit（ADK）でオーケストレーションされる計画スーパーバイザーエージェントを介して入力されます。スーパーバイザーは、在庫の検出、オーディエンスのマッチング、予測、価格分析、パッケージの推奨、ガバナンスのレビュー、実行など、各リクエストを専門的なタスクに分解します。エージェントは、オープンな Agent2Agent（A2A）プロトコルを介して連携します。一方、Gemini Enterprise Agent Platform は、エンベディング、予測、グラフ学習のためのモデルをホストします。

しかし真のブレークスルーは、自律的な実行における迅速性と完全な透明性を両立させている「デュアルグラフ基盤」のプラットフォームです。このプラットフォームは、行動に最適化されたナレッジグラフと、記憶と学習を担うコンテキストグラフという、意図的に役割を分離した 2 つの特殊なグラフシステムによって支えられています。

ナレッジグラフ: エージェントをビジネスの実態にグラウンディング

Spanner Graph を活用した Yahoo のナレッジグラフは、収益化ビジネスの各要素を相互に関連付けられた運用モデルとして表すことで、エージェントのあらゆる意思決定をビジネスの実態にグラウンディングします。広告サービス、プレースメント、オーディエンスセグメント、広告枠、契約、ガバナンス管理は、それぞれファーストクラスエンティティとして、その相互関係とともにモデル化されます。重要なのは、ポリシーをアプリケーションロジックに埋め込むのではなく、バージョン管理された関係としてグラフ内に直接組み込んでいることです。この設計により、商品、契約上の義務、同意に関する要件、規制上の制約を、単一の統合されたグラフ操作でまとめて評価することが可能になっています。

グラフは、エージェントプラットフォーム全体でセマンティックコントラクトとして機能します。キャンペーンの評価中、エージェントは 1 つのクエリプラン内で、バイヤーの初期要件から対象となるオーディエンスや管理ポリシーまでを横断的に参照できます。Gemini Enterprise Agent Platform のエンベディングは、セマンティック類似性によってこれらのエンティティの情報を拡充し、グラフニューラルネットワークは推論された関係を提供します。これにより、エージェントは単に利用可能な広告枠を取得するだけでなく、広告枠選定の根拠を正確に把握したうえで、あらゆるガバナンス上の制約を確実に遵守できるようになります。

Yahoo のナレッジグラフオントロジー（IAB AdCOM などの業界標準に準拠）

コンテキストグラフ: 監査可能なメモリの作成

エージェント規模での実行が安全なのは、完全な透明性が確保されている場合のみです。その透明性を確保することが、コンテキストグラフの核となる役割です。Seller Agent がアクションを実行するたび、その正確な実行プロセスが BigQuery Agent Analytics プラグインによってキャプチャされます。システムは、未加工のイベントをログに記録するだけでなく、Yahoo の意思決定トレースオントロジーを活用した BigQuery Agent Analytics SDK を使用して、このエビデンスから型付きのクエリ可能なコンテキストグラフを作成し、BigQuery Graph に格納します。

その結果、すべての意思決定ポイント、候補パッケージ、ポリシー評価、スペシャリストエージェントへの委任、実行結果を相互に関連付けた、エビデンスのグラフが出来上がります。このトレースは型付きグラフとして構造化されているため、エージェントの意思決定プロセスを簡単なクエリによって説明することができます。監査人は、元のキャンペーンの概要、割り当てられたすべてのスコア、適用されたポリシーなどの意思決定までのプロセスを即座にトレースできます。これにより、自律的な動作が「不透明なプロセス」から「完全に透明で継続的に改善される意思決定記録」に変わり、絶対的な説明責任を確保するのに役立ちます。

Yahoo のコンテキストグラフオントロジー

人間ができる範囲からエージェントならではの規模へ

このアーキテクチャが実際にどのように機能するのか、具体例として広告キャンペーンの実施を考えてみましょう。従来は計画、販売、運用、コンプライアンスの各部門で数週間を要していた調整作業を、2 つのプロセスを同時進行させることで数秒で完了できるようになっています。

ナレッジグラフに基づくアクションの実行: このパイプラインでは、バイヤーのリクエストからナレッジグラフに基づくキャンペーンの公開まで、直線的に予算を動かしていきます。このプロセスは、以下の 4 つのステップで構成されます。

キャンペーンの概要の送信: バイヤーエージェントは、対象オーディエンス、予算、地域、ビジネス目標を記述したキャンペーン概要を Ad Context Protocol（AdCP）を介して送信します。
ナレッジの検索: Seller Agent は、ナレッジグラフに対してクエリを実行し、関連する広告枠、オーディエンス、契約上の利用可能性、過去のパフォーマンス、管理ポリシーを特定します。
評価とスコアリング: エージェントはこれらの要素を総合的に評価して、メディア購入候補のパッケージを組み立てます。予測モデルが各機会をスコアリングする一方で、ガバナンスエージェントが同意、ブランド保護、規制上の制約を個別に確認します。
承認と実行: パッケージは、ポリシーのしきい値に基づいて自動的に承認されるか、人間による審査のためにエスカレーションされます。承認されるとメディア購入が実行され、配信が開始されます。

コンテキストグラフを使用した監査と学習。実行パイプラインが進行する一方で、この並列ループはシステムの推論プロセスをコンテキストグラフに継続的に記録します。これにより、透明性が確保され、将来のサイクルの改善が可能になります。この監査と学習プロセスには、次の機能があります。

継続的なキャプチャ: 検討されたすべての候補、割り当てられたスコア、適用されたポリシー、ガバナンスの意思決定は、紐付けられた記録としてコンテキストグラフ内で元のキャンペーンセッションにリンクされます。
クローズドループ学習: 配信、アトリビューション、成果のシグナルが届くと、それらが生成元の意思決定に紐付けられ、将来の推奨事項を改善するためのトレーニングデータが作成されます。
即時の説明可能性: 広告主が特定のパッケージが選択された理由や、成果に影響を及ぼしたポリシーについて質問すると、回答がコンテキストグラフに保存され、1 回のクエリでアクセスできます。

これにより、ナレッジ、意思決定、ガバナンス、測定、学習が連携して機能するプラットフォームが実現し、自律的なメディア購入の説明可能性と監査可能性を確保しつつ、継続的な改善を図ることが可能になります。

あらゆる業種に適用できる設計

単なるアドバイザーとしての AI の時代は終わりを迎えつつあります。企業がいま求めているのは、複雑な複数ステップのワークフローを実行できる自律型エージェント、つまり「アクションシステム」です。しかし、規制の厳しい業界では、意思決定の根拠を証明できない場合、AI がもたらすスピードがむしろリスクに変わってしまいます。自律的な実行の主な障壁となるのは、もはやインテリジェンスではなく、信頼性です。

Yahoo と Google Cloud が構築したアーキテクチャは、この問題を解決できる、幅広く適用可能なブループリントを提供します。デジタルメディアの購入におけるボトルネックを解消するために設計されたものではありますが、その基盤となるパターンは、金融取引からサプライチェーンのロジスティクスまで、リスクの高い意思決定を管理するあらゆる業界に適用可能です。エージェントならではのスピードで運用しながら、人間による監督を維持していくために、企業は以下のような新しいアーキテクチャのベースラインを採用する必要があります。

ビジネスの実態に基づく意思決定: 確率モデルだけでエージェントを運用することはできません。ビジネスロジック、有効な契約、コンプライアンスルールを決定論的にマッピングするナレッジグラフによって、エージェントをグラウンディングする必要があります。
監査可能なメモリの構築: 追跡できないものを管理することはできません。エージェントのすべてのアクションをコンテキストグラフに記録し、クエリ可能な不変のレコードを作成して、意思決定の理由や却下された代替案を正確に把握できるようにする必要があります。
オープンな相互運用性の重視: 信頼には透明性が不可欠です。オープンプロトコルと来歴標準を基盤とすることで、エージェントの動作に関する、業界共通の監査可能な枠組みを確立できます。

基盤モデルがコモディティ化するにつれ、企業の競争優位性は変化してきています。長期的に優位性を守る鍵となるのは、デプロイする言語モデルではなく、自社独自のビジネスオペレーショングラフと、統制された履歴データです。同様に、エンタープライズ AI の未来は、単に動作できるシステムではなく、その動作を説明、管理し、責任を負うことができるシステムにあります。

使ってみる

信頼できるアクションシステムを構築する準備はできましたか？まず、Spanner Graph を使用して、エージェントワークフローをビジネスの実態にグラウンディングしましょう。次に、BigQuery Graph を使用して監査可能なメモリを構築すれば、クローズドループ学習と、規制当局の要求に応じられるレベルの説明可能性を実現できます。BigQuery Agent Analytics プラグインと SDK を使用して、これらの運用トレースのキャプチャと分析を今すぐ開始できます。最後に、Ad Context Protocol を確認して、Yahoo のエージェントプラットフォームを支えるオープンコミュニケーション標準をぜひ理解しておきましょう。

- Yahoo、エンジニアリング担当ディレクター、Mikul Bhatt 氏

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

Spanner Graph アルゴリズムの発表: 接続されたデータに Google グレードのインテリジェンスを提供

Fri, 12 Jun 2026 01:00:00 +0000

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

Google Cloud Next では、Spanner Graph によるグラフアルゴリズムのプレビュー版を発表しました。Google Research の最先端のグラフマイニング機能をデータベースにネイティブに組み込めるようになり、グラフインテリジェンス機能を活用することで、グラフデータから、より迅速で低コストかつ大規模に、貴重な分析情報を導き出すことができます。

不正行為の検出、ソーシャルネットワーク分析、エンティティ解決、医療研究などのユースケースにおいて、データの複雑な関係を明らかにするために、多くの企業がグラフ技術を活用するようになっています。ノード中心性やコミュニティ検出などのグラフアルゴリズムは、こうした構造を分析するために使用される計算手法であり、エンティティ間の接続のパターンや強度を定量化することで機能します。しかし、これまで、グラフアルゴリズムを大規模に実行することは、困難かつリソースを大量に消費するものであり、多くの場合、専用の分析ソリューションに複雑な ETL パイプラインが必要になったり、グラフデータベースのトランザクションパフォーマンスが低下したりするリスクがありました。

Spanner Graph アルゴリズムは、オペレーショナルデータベースのパフォーマンスを損なうことなく、要求の厳しいエンタープライズワークロードに対応できるように設計されています。このアーキテクチャには、以下のような明確な利点があります。

GQL との緊密な統合: ISO Graph Query Language（GQL）を使用してアルゴリズムを直接呼び出し、データ全体で構造分析を実行します。Spanner Graph は、アルゴリズムと標準クエリを順次組み合わせることで、外部エンジンへの複雑なデータ移動を最小限に抑え、アーキテクチャを簡素化し、分析情報取得までの時間を短縮します。
トランザクションにほとんど影響を及ぼさずに TCO を削減: アルゴリズムの実行は専用のコンピューティングリソースで行われるため、本番環境のライブトラフィックに影響を与えることはありません。Spanner はリソースを自動的にプロビジョニングし、Data Boost を介してデータを安全にルーティングするため、カスタム ETL パイプラインを作成する必要はありません。料金は使用した分に対してのみ発生するため、従来のソリューションに見られる運用上のオーバーヘッドや高額なライセンス費用を回避できます。
数十億エッジに及ぶグラフのグローバルな分析情報を数分で取得: スケールとスピードを重視して構築されたエンジンにより、数十億エッジに及ぶグラフに対して数分でアルゴリズムを実行できます。ランダムアクセスに最適化された高密度形式でトポロジをエンコードすることで、大規模なデータセットに対する高性能な構造分析を実現します。

Google Research は、これまでに、グラフマイニングツール（マルチコアクラスタリングなど）に基づく研究論文をいくつか発表しており、ワークショップの開催や、オープンソースプロジェクトのリリースなども行っていますが、こうした機能を Google Cloud のお客様に広く提供するのは今回が初めてです。以下に、グラフアルゴリズムの仕組みと、Spanner Graph での使用方法について詳しく見ていきましょう。

アルゴリズム: 接続されたデータからより深い分析情報を取得

Spanner Graph を初めてリリースしたときの私たちの目標は、Google のスケーラビリティに優れた分散データベースである Spanner 内で、ネイティブなグラフデータベースエクスペリエンスを通じてグラフデータ管理を再構築することでした。Spanner Graph はリレーショナルモデルとグラフモデルを統合し、ISO GQL を使用して接続されたデータをクエリできるようにするとともに、Spanner の既存の表形式、検索、ベクトル機能と相互運用できるようにします。これにより、複雑なデータパイプラインの作成、データの複製といった作業や、セキュリティやガバナンスのリスクの増大を伴うことなく、インテリジェントなアプリケーションを構築できます。

この基盤の上に構築された Spanner Graph アルゴリズムは、接続されたデータからさらに深い分析情報を抽出するのに役立ちます。グラフアルゴリズムは、データ内の関係やつながりを分析し、従来の分析手法では見逃されがちな隠れたパターンや分析情報を明らかにします。今回のリリースにより、接続性を分析することが可能になり、詐欺組織の検出、エンティティ解決のためのクラスタリング、複雑なネットワークにおける障害点の特定、接続されたユーザーの好みに基づく商品の推奨などを実施できるようになります。

Google ではグラフを幅広く使用しています。実際、Google 検索を支える基盤技術である PageRank など、多くの人気アルゴリズムが Google で開発されています。Spanner Graph のネイティブアルゴリズムサポートは、Google の最先端のグラフインテリジェンス機能の一部を Google Cloud のお客様に直接提供するものであり、これにより、データ内の隠れた構造を簡単に発見できる必須グラフアルゴリズムのセットを利用できるようになります。

中心性: 中間中心性、近接中心性、PageRank を使用して、ネットワーク内で最も影響力のある中心的なノードを特定します。
コミュニティ検出: ラベル伝播、相関クラスタリング、モジュール性クラスタリング、弱連結成分、クリーク集約を活用し、接続性の高いエンティティを自動的にグループ化して、隠れたセグメントを明らかにします。
類似性と経路探索: セット間の最短経路を使用して最適なルートを見つけたり、ジャカード、コサイン、共通近傍、全近傍を使用してノードの類似性を測定したりできます。

デベロッパーエクスペリエンスの統合

グラフ全体やサブグラフ、選択したノードとエッジのセットに対して、GQL を使用してグラフアルゴリズムを直接呼び出すことができます。Spanner は統合されたワークフローを提供し、グラフアルゴリズムの実行結果を Spanner Graph に直接書き戻すことができます。これにより、あるオペレーションの出力を次のオペレーションの入力として使用して、アルゴリズムと標準クエリを順番に呼び出せるほか、この結果を Cloud Storage バケットに保存することもできます。

例: 詐欺組織の首謀者を特定する

マネーロンダリング対策のために金融取引を分析するシナリオを考えてみましょう。不正行為者は通常、互いにやり取りする一連の「運び屋」アカウント（マネーロンダリングの中継アカウント）を操作して、集団で不正行為を行います。不正行為対策の専門家は、通常、検出した運び屋アカウントと隠れた運び屋アカウントの間の連携を把握するために、リンク分析やコミュニティ検出といったグラフアルゴリズムを利用します。以下に、Spanner Graph でアルゴリズムとクエリを組み合わせて、不正行為を特定する方法を示します。

ステップ 1: アカウントのコミュニティを特定する（アルゴリズム）まず、モジュール性クラスタリングアルゴリズムを適用して、アカウントをコミュニティにクラスタリングします。次に、この結果で得られた community_id を Spanner Graph 内の Account に直接書き戻します。

code_block: <ListValue: [StructValue([('code', "-- Runs community detection and update results to the graph\r\nEXPORT DATA OPTIONS(\r\n format ='CLOUD_SPANNER',\r\n table = 'Account',\r\n write_mode = 'update_ignore_all'\r\n) AS\r\nGRAPH FinGraph\r\nCALL ModularityClustering(\r\n node_labels => ['Account'],\r\n edge_labels => ['Transfer']\r\n)\r\nYIELD node, cluster\r\nRETURN node.id, cluster AS community_id;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93aedf6410>)])]>

ステップ 2: 不審なコミュニティを特定する（クエリ）すべてのアカウントがコミュニティに属するようになったので、GQL クエリを使用して各コミュニティに対して分析クエリを実行して、異常な行動を明らかにできます。たとえば、各コミュニティ内の既知の不正アカウントの総数を確認できます。

code_block: <ListValue: [StructValue([('code', '-- Finds the community with the highest concentration of flagged fraud\r\nGRAPH FinGraph\r\nMATCH (a:Account)\r\nWHERE a.community_id IS NOT NULL\r\n AND a.fraud_flag = TRUE\r\nRETURN a.community_id AS community_id, COUNT(*) AS fraud_count\r\nORDER BY fraud_count DESC;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ade018d0>)])]>

ステップ 3: 影響力を算出して「首謀者」を特定する（サブグラフのアルゴリズム）上記のクエリにより、Community 2 で不正行為が急増していることが明らかになったとします。このステップでは、グラフをフィルタリングして、その特定のコミュニティのアカウントのみを抽出し、PageRank アルゴリズムを実行して、そのグループ内の中心的な首謀者を特定します。

code_block: <ListValue: [StructValue([('code', "EXPORT DATA OPTIONS(\r\n format = 'CLOUD_SPANNER',\r\n table = 'Account',\r\n write_mode = 'update_ignore_all' \r\n) AS\r\n-- Specifies a suspicious subgraph\r\nGRAPH FinGraph\r\nMATCH (n:Account {community_id: 2})\r\nRETURN n\r\nFULL UNION ALL\r\nMATCH -[e:Transfer]->\r\nRETURN e\r\nNEXT\r\n-- Runs PageRank \r\nCALL PER() PageRank(max_iterations => 20) \r\nYIELD node, score\r\nRETURN node.id, score AS pagerank_score;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ade14210>)])]>

ステップ 4: ターゲットを調査する（クエリ）Community 2 のアカウントに pagerank_score が付与されたことで、最も中心的なアカウントを特定して、その首謀者が最近どこに資金を移動させたかを即座に追跡するクエリを作成できます。

code_block: <ListValue: [StructValue([('code', "-- Finds the top scorer (ringleader) and trace their money\r\nGRAPH FinGraph\r\nMATCH (ringleader:Account {community_id: 2})\r\nORDER BY ringleader.pagerank_score DESC\r\nLIMIT 1\r\nWITH ringleader\r\nMATCH (ringleader)-[e:Transfer]->{1, 5}(receiver:Account)\r\nWHERE e.ts > '2025-12-01'\r\nRETURN ringleader.id AS ringleader_id, receiver.id AS receiver_id, e.amount, e.ts;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ade17c90>)])]>

Spanner Graph では、標準の GQL クエリと高性能なアルゴリズムを組み合わせることができるため、オペレーショナルデータベースと外部分析エンジン間でデータをやり取りする必要がなくなります。この統合アプローチにより、データアーキテクチャが大幅に簡素化され、分析情報を取得するまでの時間が短縮されます。

業界のリーダーからの信頼

DaVita、Yahoo!、SoundCloud、WPP といったお客様が、すでに Spanner Graph アルゴリズムを活用して、極めて複雑なデータの課題解決に取り組んでいます。

「当社の Patient 360 イニシアチブに Spanner Graph を活用することで、複雑な医療データを一つの統合ビューに集約できるようになりました。コミュニティ検出や中心性といったネイティブグラフアルゴリズムが追加されたことは大きな進歩であり、患者ネットワーク内の深い分析情報をより迅速かつ大規模に発見できるようになりました。これらのフルマネージド機能により、当社のチームは複雑なデータパイプラインの管理という運用上の負担を負うことなく、患者ケアのイノベーションの推進に注力できます。」- DaVita Kidney Care、チーフエンタープライズアーキテクト、Sam Ghosh 氏

「Yahoo を象徴する消費者向けサービスをグローバル規模で運用するには、数十億のユーザープロファイルを一つのリアルタイムビューに統合する必要があります。当社の Unified User Profile（UUP）は、Spanner Graph によって一つのグラフとしてモデル化されており、これまで分散していたシステムを信頼できる一元的な情報源として統合しています。また、Spanner にフルマネージドのグラフアルゴリズムが追加されたことで、大規模なパーソナライズを実現する能力がさらに増強されました。コミュニティ検出や PageRank などのアルゴリズムを活用してオーディエンスのセグメンテーションをより深く行い、プラットフォーム全体でより関連性が高く魅力的なユーザーエクスペリエンスを提供できるようになりました。」 - Yahoo、エンジニアリング担当ディレクター、Chris James 氏

「190 か国以上、4,000 万人以上のアーティストによる 5 億曲以上の楽曲を擁する SoundCloud は、新進気鋭のアーティストが自分のサウンドを見つけたり、隠れた名曲を発見したり、音楽文化をリアルタイムで形成したりする場所です。当社は長年にわたり、グラフアルゴリズムをバッチモードで実行してきましたが、数十億エッジに及ぶ巨大な音楽グラフを分析するために、カスタムクラスタで数時間かかることもよくありました。Spanner Graph アルゴリズムの登場は、まさにゲームチェンジャーです。当社が必要とする大規模なスケーラビリティを得られるだけでなく、複雑なカスタム Python ワークフローからフルマネージドサービスに移行することもできます。特に重要なのは、クリエイターハブの特定やレコメンデーションの改善といったユースケースにおいて、最新のデータに対してグラフアルゴリズムを実行できるようになったことです。複雑な ETL パイプラインを必要とせず、Spanner で実行されている低レイテンシのトランザクションワークロードに影響を与えることもありません。」 - SoundCloud、エンジニアリング - データ基盤担当バイスプレジデント、Sergey Chekanskiy 氏

「私たちは、Open Intelligence（当社の基盤となるインテリジェンスレイヤ）に高度なグラフアルゴリズムを活用することを切望していました。Open Intelligence は、クライアント、パートナー、WPP からの数兆ものライブデータポイントを、プライバシーを最優先にしながら安全に接続するものであり、現在は WPP のエージェント型マーケティングプラットフォームである WPP Open に統合され、その基盤を支えています。数十億ものエンティティにわたる複雑な関係性を即座に探索し、計画、モデリング、試験運用を推進するためには、詳細なグラフ走査、構造的パターン認識、高度なアルゴリズムに対するネイティブなサポートが必要となります。Spanner Graph のアルゴリズムサポートは、運用上のオーバーヘッドや高額なライセンス費用を伴わずに、極めて困難なグラフ分析の問題に取り組むためのパフォーマンスとスケーラビリティを提供してくれます。」 - WPP、データ＆インテリジェンス担当戦略責任者、Rob Marshall 氏

よりインテリジェントなアプリケーションの構築

Spanner Graph でアルゴリズムがネイティブにサポートされるようになったことで、基本的な関係性の探索にとどまらず、最新のトランザクションデータに対して、詳細な構造分析を直接実行できるようになりました。定番のグラフアルゴリズムを大規模に適用することで、エンタープライズアプリケーションに新たな機能をもたらすことができます。

不正行為の事前検出とマネーロンダリング対策: コミュニティ検出（モジュール性クラスタリングなど）を使用して、接続された運び屋アカウントを自動的にグループ化することで、詐欺組織を特定します。その後、中心性（PageRank など）を適用して、違法な資金の流れを統率している首謀者を特定します。
Customer 360 とエンティティ解決: ジャカードなどの類似性関数や、ラベル伝播などのコミュニティ検出を使用して、断片化されたクロスチャネルデータを単一の正規プロファイルに統合します。これらのプロファイルは、各ノードに対して PageRank などのトポロジ特徴を生成することで、ダウンストリームの ML トレーニング用にさらに強化できます。
自律的なネットワーク運用とデジタルツイン: IT や通信インフラストラクチャをデジタルツインとしてモデル化し、類似性や経路探索（セット間の最短経路など）を使用して、重大な脆弱性をプロアクティブに特定し、連鎖的な障害を予測します。
高度にパーソナライズされたプロダクトレコメンデーション: 基本的な購入履歴にとどまらず、より広範にユーザー行動を分析します。類似性アルゴリズム（共通近傍など）を使用してエンティティ間の嗜好の重複を特定し、さらに、中心性（パーソナライズされた PageRank など）を使用することで、それらのグループにとって最も関連性の高いレコメンデーションを提示します。
レジリエンスに優れたサプライチェーンとロジスティクス: 中心性（中間中心性など）を使用して、過度に依存している物流センターを特定し、経路探索を使用して、障害発生時に効率的な代替ルートを即座に計算することで、サプライチェーンを隠れたボトルネックから保護します。
サイバーセキュリティの脅威ハンティングと影響範囲分析: コミュニティ検出（相関クラスタリングなど）を適用して異常なマシン通信を特定し、経路検出を使用して攻撃者の正確なラテラルムーブメントと影響範囲を追跡することで、脅威ハンティングを加速します。
顧客離れの予測分析: コミュニティ検出を使用して結束の固いサブスクライバーグループを特定し、連鎖的な顧客離れを防ぎます。そのうえで、中心性を適用して影響力の大きいコアメンバーを特定し、離脱が拡大する前に定着を図る施策を実施します。

使ってみる

Spanner Graph アルゴリズムは、Spanner の Enterprise エディションと Enterprise+ エディションでサポートされています。詳細については、ドキュメントをご覧いただくか、こちらの Codelab をお試しください。また、こちらの動画では、Spanner Graph でのグラフアルゴリズムのサポートについて概要を説明しています。

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

-Google Research、グラフマイニング担当バイスプレジデント兼 Google Fellow、Vahab Mirrokni

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Spanner Omni が重要である理由

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

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

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

Spanner Omni の紹介

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

Spanner Omni の特徴

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

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

Spanner Omni を支える技術

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

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

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

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

アクセス方法

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

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, 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

DeNA: Spanner、C4A インスタンスを駆使して世界規模のゲームアプリ『Pokémon TCG Pocket』の安定運用を実現

Mon, 22 Dec 2025 02:30:00 +0000

2024 年 10 月 30 日より、150 の国と地域でサービスを開始した、スマートフォン向けポケモンカードゲーム『Pokémon Trading Card Game Pocket（以下、ポケポケ）』。株式会社ポケモン、株式会社クリーチャーズ、そして株式会社ディー・エヌ・エー（以下、DeNA ）の合同プロジェクトである本アプリに、Google Cloud がどのように貢献しているのか。本プロジェクトでサーバー・アプリ開発を担当した DeNA のお二人に伺います。

利用しているサービス:
Spanner、Google Kubernetes Engine（GKE）、BigQuery など

利用しているソリューション:
データベース

Spanner の存在が Google Cloud を選んだ最大の理由

『ポケポケ』は世界中で楽しまれているポケモンカードを、手軽にコレクションできるアプリです。2025 年 10 月には全世界累計 1.5 億ダウンロードを突破し、世界規模で圧倒的な支持を集めています。

本タイトルは、パブリッシュと全体プロデュースを担う株式会社ポケモン、カードゲーム開発を担う株式会社クリーチャーズ、そしてサーバー・アプリ開発と運用を担う DeNA の 3 社合同プロジェクトとしてスタート。世界中から膨大なアクセスを受け付けるアプリの安定運用は、これまでさまざまなビッグタイトルを手がけてきた DeNA の手腕に委ねられていました。

同社 IT 本部 IT 基盤部副部長として『ポケポケ』のインフラ周りを統括した天野知樹氏は、DeNA がかねてより、サービス基盤のほとんどをパブリッククラウド化していることもあり、『ポケポケ』に関しても当初からクラウドで運用されることが決まっていたと話します。

「『ポケポケ』のような世界規模のサービスを展開するには、パブリッククラウドの迅速なリソース調達力が不可欠です。特に、負荷試験やサービス開始直後にドカンとリソースを使い、その後、徐々に落ちついていくゲーム特有の性質はパブリッククラウドに好適。現在では『ポケモンマスターズEX 』など、弊社タイトルの 99.99% が各種パブリッククラウド上で運用されるまでになっています。そこで、今回のプロジェクトにおけるインフラ基盤として、Google Cloud の利用をさらに拡大することにしました。」

天野氏は、 Google Cloud を選んだ最大の理由が Spanner だったと断言。サーバーの開発初期から本プロジェクトに携わり、現在はサーバーチームのリードエンジニアとして活躍する柴田佳祐氏は、Spanner の価値を次のように説明してくれました。

「『ポケポケ』のような多くのお客様がアクセスする大規模ゲームアプリでは、データベースのシャーディングやデータ整合性の維持などといった技術的課題をどう解決するかが大きな問題になります。従来のデータベース技術では、シャーディングの制御やシャードまたぎのトランザクションの考慮、シャード数の増減などが大変なのですが、Spanner はそれらの難度の高い処理を全て自動化してくれます。さらに、レプリケーション遅延を考慮する必要がなく、トランザクションが強い整合性を持つため、アプリ開発が容易になります。これはゲーム開発において大変魅力的な性質でした。サーバーの開発開始当初、他のパブリッククラウドには類似の機能を持つサービスはありませんでしたし、また、現在においても、トータルでは最も我々の用途に合致した選択肢だと考えています。」

「事前分割（Pre-splitting）」の活用で、ローンチ直後の大規模アクセスにも対応

もちろん、『ポケポケ』ほどの大規模アクセスをさばくのは Spanner であっても容易なことではありません。実際、毎秒 1,000 万クエリを Spanner に発行するなど、膨大なトラフィックを想定して行われた事前の負荷試験ではパフォーマンスの立ち上がりに課題が見つかったと、柴田氏は当時を振り返ります。

「Spanner には内部的にスプリットと呼ばれるシャードのようなものが存在します。これは基本的には自動で増減しますが、急激な負荷のスパイクが発生するとスプリットの増加が間に合わず、ローンチ直後や新しい拡張パックの追加直後にレイテンシの悪化が起こる懸念がありました。ダミーの負荷をかけて分割を促すこともできるのですが、お客様が遊んでいる状態で大きなダミーの負荷をかけるのはリスクを伴います。」

柴田氏がこの問題を Google Cloud に相談したところ、当時はまだプライベートプレビュー段階であった事前分割（Pre-splitting）機能を前倒しで提供（2025 年 4 月 28 日より一般提供開始）。あらかじめスプリットを割っておけるようになったことで、必要な時に必要なパフォーマンスを発揮できるようになったと言います。

「実際、2024 年 10 月のローンチ時も、ほぼ垂直にトラフィックのグラフが上がっていく中、見事に耐えきってくれて感動しました。チームの仲間たちと『恐ろしいほど問題が起きないね』と話していたくらいです（笑）。」（柴田氏）

事前分割機能はその後も、新しい拡張パックの公開時など、トラフィック増大が予想されるケースで活躍しています。

「Spanner があったからこそ、安定した運用ができているのは間違いありません。別のデータベースを使っていたら、もっと大変だったろうと想像しています。」（天野氏）

C4A インスタンスはコスパも安定性も優れた理想的な選択肢

『ポケポケ』のサービス安定性を支えているのは Spanner だけではありません。『ポケポケ』ではそのサービスを維持するため、膨大な数のサーバーを動かしており、サービス開始当初は、すでに多くの過去タイトルで採用実績のある Tau T2D インスタンスを採用していました。しかし、いくつかの理由から、当時登場したばかりの C4A インスタンスへ移行することを決断します。

「最大の理由はコストです。ポケポケでは API サーバーとバトルサーバーで合計約 2 万コアものサーバーを動かしており、その料金を削減したいという気持ちがありました。サービス開始前の試算では Tau T2D インスタンスが最も費用対効果に優れた選択肢だったのですが、C4A インスタンスがなんとポケポケのサービス開始と同日に発表され（笑）、すぐに移行を検討し始めました。また、パフォーマンスの安定性という観点からも『さまざまなワークロードに対して一貫して高いパフォーマンスを実現』と謳う C シリーズの方がポケポケのようなゲームタイトルと相性が良いと考えました。」（天野氏）

x86-64 アーキテクチャの Tau T2D インスタンスから、arm64 アーキテクチャの C4A インスタンスへの移行は、マルチアーキテクチャイメージを作成することで実現しています。

「クロスコンパイルが容易な Go 言語を使っていたこともあり、マルチアーキテクチャイメージのビルドは想定していたよりも苦労なく移行できました。」（柴田氏）

なお、インスタンスの移行は、サービスを中断せずにノーメンテナンスで実施。移行後は大きなチューニングも必要なく、すぐに大きな性能向上があったとのことです。

「特に API サーバーのコストパフォーマンス向上が著しく、Tau T2D インスタンスの時と比べて約 73% もの改善を達成しています。リアルタイム性の高いバトルサーバーは安定性を重視したため API サーバーほどの成果は得られませんでしたが、それでも約 11% の改善ができました。以前はコストパフォーマンス重視なら Tau T2D インスタンス、安定性重視なら C シリーズでしたが、C4A インスタンスは、とりわけ我々の用途においてはコスパも安定性も優れた理想的なインスタンスだと感じました。」（天野氏）

今回の成果は株式会社ポケモン、株式会社クリーチャーズからも高く評価されているとのこと。最後に、天野氏は、Spanner および C4A インスタンスの活用について、今後の展望を語ってくれました。

「『ポケポケ』での成果を踏まえ他のゲームタイトルでも Google Cloud を積極的に活用していくことになっていくでしょう。また、DeNA として AI に ALL IN していくことを表明しており、AI を用いた事業変革の中心にいる Google のポテンシャルにも期待しています。例えば重要性の高くない作業を AI エージェントに代替させていくことでエンジニアがより創造的な仕事に取り組んでいけるようにしたいですね。そのためにもこれからはより一層、コミュニケーションを密接にし、強力な信頼関係のもと、スピード感を高めた開発をしていければと思っています。」

株式会社ディー・エヌ・エー
「一人ひとりに　想像を超えるDelightを」のミッションのもと、ゲーム、ライブコミュニティ、スポーツ・まちづくり、ヘルスケア・メディカルなど幅広い事業を展開。事業価値の最大化と課題解決のためのAI活用と独自のデータ分析手法によって、顧客ニーズを的確に捉えた付加価値の高いサービス開発から運用までを行っている。

株式会社ポケモン
「ポケモン」を永続的なブランドに育てるべく 1998 年に設立。コンテンツや商品づくり、マーケティング、その他あらゆる活動を通じて、ポケモンの個性を引き出し、魅力を引き出すことを目的とする。グループは自社を含め世界に 13 社、オフィスは 14 拠点にあり、それぞれのマーケットで、ポケモンプロデューサーとして取り組んでいる。

株式会社クリーチャーズ
1995 年設立。任天堂株式会社、株式会社ゲームフリークと並ぶポケモン原作著作者企業（株式会社ポケモンはこの 3 社の共同出資により設立）。ポケモンのトレーディングカードゲーム・ビデオゲームの開発、『ポケットモンスター』シリーズなどの CG モデル・モーションの開発事業などを展開し、ますます広がるポケモンの世界を支えている。

インタビュイー（写真右から）
株式会社ディー・エヌ・エー
・IT 本部 IT 基盤部副部長　天野知樹氏
・ゲームサービス事業本部開発運営統括部第二技術部サーバー
　第一グループエンジニア　柴田佳祐氏

その他の導入事例はこちらをご覧ください。

Mercado Libre の多面的な Spanner アーキテクチャの概要

Thu, 27 Nov 2025 01:01:00 +0000

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

ラテンアメリカの e コマースとフィンテックのパイオニアである Mercado Libre は、驚くべき規模で事業を展開しており、復元力とスケーラビリティだけでなく、迅速なイノベーションの触媒となるインフラストラクチャを必要としています。Google の Spanner は、基盤となる整合性とスケーリングを実現するサービスとして知られていますが、さらに詳しく見ていくと、洗練された多層戦略に基づいていることがわかります。Spanner は単なるデータベースではありません。社内開発者プラットフォーム、多様なデータモデル、高度な分析ループ、インテリジェントな機能、さらには次世代 AI アプリケーションのロードマップを支えるコアエンジンです。

本ブログでは、Fury プラットフォームなどの社内イノベーションとともに Spanner を活用し、大きなビジネス効果を達成して AI 主導の未来への道筋を描いている、Mercado Libre の技術的基盤について説明します。

2 つの課題: インターネット規模での運用と開発者の速度

Mercado Libre は、インターネット規模のサービスに共通する課題に直面しています。それは、毎日数百万件の金融取引を安全に保つこと、デベロッパーが簡単にアプリを構築できるようにすること、ほぼ 100% の稼働時間を維持することです。このソリューションでは、十分なパワフルさを備えたデータベースを中核に据え、幅広いデベロッパーが採用したくなるほど優れた抽象化レイヤが必要でした。

Fury: Mercado Libre の開発者ゲートウェイ

Mercado Libre の戦略の中核をなすのは、社内のミドルウェアプラットフォームである Fury です。Fury は、さまざまなバックエンド技術の複雑さを抽象化し、アプリケーションを構築するための、標準化され、簡素化されたインターフェースを開発者に提供するように設計されています。

抽象化と標準化: Fury を使用すると、開発チームは分散データベース管理の微妙な違い、特定のエンジン向けのスキーマ設計、最適な接続プーリングではなく、ビジネスロジックに集中できます。

信頼性に優れたコアとなる Spanner: Spanner は、グローバルな整合性を備えた常時稼働のマルチモデルデータベースで、実質的に無制限のスケーリングが可能です。Mercado Libre は、Fury 内で Spanner を選択することで、Spanner を使用してプラットフォーム上に構築されたアプリケーションが、Spanner の優れた機能を継承できるようにしています。つまり、グローバルに整合性が保たれ、スケーリングしても中断されず、ダウンすることもほとんどありません。

図 1 - Fury のコアサービス

Spanner – 汎用性に優れたバックボーン

Fury を通じて、Spanner は Mercado Libre の開発者に驚異的な汎用性を提供します。複雑なトランザクションが必要なアプリもあれば、高速な検索が必要なアプリもあります。Spanner は両方に対応しているため、チームは 1 つのシステムのみを使用できます。

複雑なトランザクションのためのリレーショナル機能: 注文管理、支払い、在庫システムなどの高度なトランザクションワークロードでは、Spanner のリレーショナル機能（SQL、ACID トランザクション、結合）が依然として重要です。
高パフォーマンスの Key-Value ストア: 最新のアプリケーションの多くは、高速なポイント検索とシンプルなデータ構造を必要とします。Mercado Libre では Spanner を一般的な Key-Value ワークロードに対するデフォルトのバックエンドとしては利用していませんが、大規模な非リレーショナル KV スタイルのワークロードを Spanner で実行する特定のアプリケーションがあります。

グローバルな整合性を実現する TrueTime と、簡単なスケーリングを実現する自動シャーディングは、Spanner の基盤となるアーキテクチャであるため、Spanner は Fury プラットフォームを通じてこれらのアクセスパターンを確実に処理する理想的な候補です。

ピーク時の需要への対応

Mercado Libre の Spanner インスタンスは、約 214,000 秒間クエリ数（QPS）と、1 秒あたり 30,000 トランザクション（TPS）を処理する優れた処理能力を発揮しています。この膨大なワークロードを管理するために、Spanner インフラストラクチャは 400 ノード以上に動的にスケール（30% 増）し、基盤システムには需要の高いシナリオに対応する堅牢性と弾力性があります。このレベルのスループットとスケーラビリティは、最も多忙な時期に Mercado Libre のサービスのパフォーマンスと信頼性を維持するために不可欠です。

図 2 - Spanner で構築されたソリューションの図。現在の検索データを使用して、顧客が購入する可能性が最も高い商品を予測して推奨する。

データをアクションに変える

Mercado Libre は、高度な分析を活用して分析情報を運用システムに直接取り込む、Cloud Spanner を中心とした動的なデータエコシステムを構築しています。

また、Spanner Data Boost と BigQuery フェデレーションを組み合わせることで、リアルタイム分析を実現しています。Data Boost は分析クエリを分離し、重要なトランザクションのパフォーマンスに影響を与えないようにします。これにより、BigQuery 内の最新の Spanner データに対して、強力な大規模分析を直接実行できるうえ、他のデータソースとシームレスに統合できます。

BigQuery からの分析情報（顧客セグメントや不正スコアなど）は、リバース ETL を介してアクションが実行され、Spanner に直接取り込まれます。これにより、運用データが充実し、パーソナライズされたコンテンツの提供やリアルタイムのリスク評価の実施など、現場で使用されるアプリケーションによる即時のアクションが可能になります。

さらに、Spanner 変更ストリームと Dataflow を組み合わせることで、重要なサービス統合を推進します。Spanner からリアルタイムでデータの変更をキャプチャすることで、Mercado Libre は堅牢なパイプラインを確立しています。これにより、変更を BigQuery に読み込んで分析したり、Fury Stream などのサービスにストリーミングしてリアルタイムで利用したりできるようになり、低レイテンシのデータ伝播が保証され、システム全体でイベントドリブンアーキテクチャが実現します。

効果: コスト削減、アジリティ、将来への備え

Spanner の戦略的な導入と、Fury などの社内プラットフォームや高度なデータワークフローの活用により、Mercado Libre は次のような大きなメリットを得ています。

大幅な費用削減と低い総所有コスト: Spanner のマネージドな性質（手動シャーディングやメンテナンス作業の削減）、効率的なリソース使用率、Fury が提供する抽象化の組み合わせにより、総所有コストが削減され、大幅な費用削減が実現しました。
ビジネスへの影響とアジリティ: Fury によってインフラストラクチャの複雑さから解放され、Spanner の汎用性に優れた機能を手にした開発者は、新しい機能やアプリケーションをより迅速に提供できます。Spanner の高い信頼性が重要なビジネスオペレーションを支え、中断を最小限に抑えます。
運用上のオーバーヘッドが低い: Spanner では、スケーリング、シャーディング、メンテナンスが自動化されているため、大規模なデータベースインフラストラクチャを管理するために必要な人的労力が大幅に削減されます。

AI 向けに構築: Spanner 上の次世代アプリケーション

今後、Mercado Libre は、より多くの AI ワークロードをサポートするために Spanner の活用を検討しています。

Spanner の特性は、基盤として最適です。

一貫した状態管理: 状態コンテキストを維持し、確実に更新する必要がある AI システムに不可欠です。
スケーラブルなメモリ / ナレッジストア: AI システムのメモリ、ログ、コンテキスト情報に関する、膨大な量のデータを保存および取得する機能があります。
トランザクション処理: AI システムが他のシステムとやり取りするアクションを、優れた信頼性で実行できるようにします。
分析と ML の統合: 既存のデータループと ML.PREDICT 機能により、リアルタイムの分析情報とインテリジェンスで AI システムを強化できます。

Spanner は、このような高度な AI アプリケーションに必要なトランザクションの基盤を提供します。

まとめ: 統合されたインテリジェントなデータ基盤

Mercado Libre による Spanner の採用方法は、強力でグローバルに整合性のあるデータベースを、そのコア機能だけでなく、開発者の生産性、運用の効率性、高度な分析、将来の AI に関する展望を実現するための戦略的なイネーブラーとして使用する方法を示しています。Fury プラットフォームを通じて、私たちは Spanner の機能へのアクセスを簡素化し、リレーショナルと非リレーショナルの両方のニーズに対応できる柔軟な基盤として Spanner を活用できるようにしました。Data Boost を介した BigQuery との統合は、インテリジェントでデータドリブンな企業を構築するための包括的なアプローチを示しています。Mercado Libre が AI アプリケーションを構築するにあたり、Spanner は、次なるイノベーションの波を支える一貫性のあるスケーラブルな基盤としての役割を今後も果たしていくことでしょう。

詳細

-ソフトウェアテクニカルリーダー、Mercado Libre、Pablo Leopoldo Arrojo 氏

Spanner カラム型エンジン: 運用データの次世代分析を強化

Wed, 13 Aug 2025 01:00:00 +0000

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

長年にわたり、組織はオンライントランザクション処理（OLTP）と分析クエリ処理のワークロードの違いに悩まされてきました。Spanner などの OLTP システムは、大量の低レイテンシトランザクション向けに最適化されており、個々のレコードへのアクセスに効率的な行指向のストレージを使用します。一方、分析ワークロードでは、大規模なデータセット全体にわたる迅速な集計とスキャンが必要です。これらのタスクは従来、カラム型ストレージとトランザクションシステムからの受信データパイプラインを使用する個別のデータウェアハウスによって処理されてきました。OLTP ワークフローと分析ワークフローを分離すると、定期的なデータ転送が必要になるため、データが古くなったり、ETL パイプラインが複雑になったり、運用上のオーバーヘッドが発生したりすることがよくあります。

そこでこのたび、Spanner カラム型エンジンを発表いたします。これにより、Spanner データベースで直接新しい分析機能を利用できるようになります。AlloyDB のカラム型エンジンが PostgreSQL の分析を強化したように、Spanner の新しいカラム型エンジンでは、Spanner のグローバルな整合性、高可用性、強力なトランザクション保証を維持しながら、膨大な量の運用データをリアルタイムで分析できます。トランザクションワークロードに影響を与えることもありません。

Spanner のカラム型エンジンの機能により、Verisoul.ai などの組織は、大量のトランザクションシステムと高速分析を組み合わせる際に通常発生するデータサイロの問題を解消しています。「不正行為をリアルタイムで検出することは、私たちが行っていることの半分にすぎません。お客様に『なぜ』不正行為が起こったのかを示すことで、お客様はより迅速に行動し、信頼を測定可能な ROI に変えることができます」と、偽のユーザーと不正行為を阻止する ML プラットフォームである Verisoul.ai の創業者である Raine Scott 氏と Niel Ketkar 氏は述べています。「Spanner の新しいカラム型エンジンにより、高速なトランザクション書き込みと豊富な分析を 1 か所で実行できます。データのコピーやレプリケーションの遅延がなくなるため、お客様は即座に回答を得られます。」

カラム型ストレージとベクトル化実行

図: Spanner カラム型エンジンのアーキテクチャ

Spanner カラム型エンジンの核となるのは、カラム型ストレージとベクトル化されたクエリ実行を組み合わせた革新的なアーキテクチャです。

Spanner のカラム型ストレージ: ハイブリッドアーキテクチャ

従来の行指向ストレージでは、行全体が連続して保存されますが、カラム型ストレージでは、データが列ごとに保存されます。カラム型ストレージには次のようなメリットがあります。

I/O の削減: 分析クエリは、一度にアクセスする列が少ないことがよくあります。カラム型ストレージでは、ディスクから読み取る必要があるのは関連する列のみであるため、I/O オペレーションが大幅に削減されます。
圧縮率の向上: 通常、1 つの列内のデータは同じデータ型であり、多くの場合、同様のストレージパターンを示すため、圧縮率が大幅に向上します。つまり、より多くのデータをメモリに格納でき、読み取る必要があるバイト数が少なくなります。
効率的なスキャン: 列をスキャンするときに、連続する値をまとめて処理できるため、データ処理がより効率的になります。

Spanner カラム型エンジンは、既存の行指向ストレージにカラム形式を統合します。この統合されたトランザクション処理と分析処理の設計により、Spanner は OLTP パフォーマンスを維持しながら、ライブ運用データに対する分析クエリを最大 200 倍高速化できます。

ベクトル化実行: クエリを大幅に加速

カラム型ストレージを補完するために、カラム型エンジンは Spanner のベクトル化実行機能を利用します。従来のクエリエンジンはデータをタプル単位（行単位）で処理しますが、ベクトル化エンジンはデータを複数の行のバッチ（ベクトル）で処理します。このアプローチにより、以下を実現することで CPU 使用率が大幅に向上します。

関数呼び出しのオーバーヘッドの削減: ベクトル化エンジンでは、個々の行ごとに関数を呼び出すのではなく、バッチ全体に対して関数を 1 回呼び出すだけなので、オーバーヘッドが大幅に削減されます。
最適化されたメモリアクセス: ベクトル化された処理では、キャッシュフレンドリーなメモリアクセスパターンになることが多く、パフォーマンスがさらに向上します。

カラム型ストレージとベクトル化実行を組み合わせることで、Spanner での分析クエリを桁違いに高速化し、グローバル規模のデータに関するリアルタイムの分析情報を得ることができます。

BigQuery でさらに向上: 連携クエリの高速化

Spanner のカラム型エンジンは、Google のデータクラウドエコシステムとの統合をさらに一歩進め、特に Spanner と BigQuery の統合を強化します。データウェアハウジングと分析に BigQuery を活用している企業にとって、クエリを Spanner に直接連携させることは常に価値のある機能です。Spanner のカラム型エンジンにより、オペレーションデータの分析情報をより迅速に提供できるようになることで、この統合がさらに強力になります。

Data Boost は、分析ワークロード向けのフルマネージドで弾力的にスケーラブルな Spanner のコンピューティングサービスであり、この高速化を実現する最前線にあります。BigQuery が Spanner に対して連携クエリを発行し、そのクエリがカラム型スキャンとベクトル化実行の利点を活用できる場合、Data Boost は Spanner のカラム型エンジンを自動的に利用します。これには、次のような利点があります。

分析情報の迅速な取得: Spanner データを対象とする BigQuery から開始された複雑な分析クエリが大幅に高速化され、ほぼリアルタイムの運用データがより広範な分析環境に取り込まれます。
OLTP への影響を軽減: Data Boost は、分析ワークロードがプライマリ Spanner コンピューティングリソースからオフロードされるように支援し、トランザクション処理への影響を防止します。
データアーキテクチャの簡素化: 複雑な ETL パイプラインでデータを複製する必要がなく、Spanner のトランザクション整合性と BigQuery の分析能力という両方のメリットを得られます。

この統合により、データアナリストやデータサイエンティストは、Spanner のライブ運用データを BigQuery の他のデータセットと組み合わせて、より豊富でタイムリーな分析情報の取得と意思決定を実現できます。

カラム型エンジンの活用: 分析クエリの高速化

Spanner のカラム型エンジンで大幅な高速化が期待できるクエリの例をいくつか見てみましょう。分析ワークロードやグラフワークロードで一般的なこれらのタイプのクエリは、カラム型スキャンとベクトル化された処理のメリットを享受できます。

シナリオ: 大規模な e コマースデータベースを前提とします。デモ用に、TPC-H ベンチマークと同じスキーマを使用します。

クエリ 1: 特定の年の割引が適用された出荷による収益

SQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nSELECT\r\n sum(l.l_extendedprice * l.l_discount) AS revenue\r\nFROM\r\n lineitem l\r\nWHERE\r\n l.l_shipdate >= date "1994-01-01"\r\n AND l.l_shipdate < date_add(date "1994-01-01", INTERVAL 1 year)\r\n AND l.l_discount BETWEEN 0.08 - 0.01 AND 0.08 + 0.01\r\n AND l.l_quantity < 25;'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f93ae599010>)])]>

高速化: このクエリは、lineitem テーブルから l_shipdate、l_extendedprice、l_discount、l_quantity の列のみをスキャンすることで大きなメリットが得られます。ベクトル化実行では、日付、割引、数量のフィルタが迅速に適用され、条件を満たす行が特定されます。

クエリ 2: 割引対象外のアイテムの合計数量

SQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nSELECT\r\n sum(l_quantity)\r\nFROM\r\n lineitem\r\nWHERE\r\n l_discount = 0;'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f93ae599c90>)])]>

高速化: このクエリは、lineitem テーブルから l_discount 列と l_quantity 列のみをスキャンすることで大きなメリットが得られます。ベクトル化実行により、等価フィルタ（l_discount = 0）が迅速に適用され、一致する行が特定されます。

クエリ 3: 特定の税率区分の商品数と割引額の範囲

SQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nSELECT\r\n count(*),\r\n min(l_discount),\r\n max(l_discount)\r\nFROM\r\n lineitem\r\nWHERE\r\n l_tax IN (0.01, 0.02);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ae599c50>)])]>

高速化: このクエリは、lineitem テーブルから l_tax 列と l_discount 列のみをスキャンすることで大きなメリットが得られます。ベクトル化実行では、l_tax 列に IN フィルタが迅速に適用され、一致するすべての行が特定されます。

クエリ 4: Spanner Graph を使用してグラフ内のつながりが最も多い N を見つけるために、友達関係をスキャンする

GQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nGRAPH social_graph\r\nMATCH (p:Person)-[k:Knows]->(:Person)\r\nRETURN COUNT(k) AS friend_count GROUP BY p ORDER BY friend_count DESC LIMIT 10;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ae59b790>)])]>

高速化: このクエリは、サブグラフをスキャンし、グラフから関連する列のみを読み込むことで、大きなメリットが得られます。

クエリ 5: K 近傍法によるベクトル類似性検索を実行して、意味的に最も類似したエンベディング上位 10 件を取得する（再現率 100%）

GQL

code_block: <ListValue: [StructValue([('code', '@{scan_method=columnar}\r\nSELECT e.Id as key, COSINE_DISTANCE(@vector_param, e.Embedding) as distance\r\nFROM Embeddings e\r\nORDER BY distance LIMIT 10;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93ae59a510>)])]>

高速化: このクエリは、連続して保存されたベクトルエンベディングをスキャンし、テーブルから関連する列のみを読み込むことで、大きなメリットが得られます。

今すぐ Spanner のカラム型エンジンを使い始めましょう。

Spanner のカラム型エンジンは、Spanner の基本的な強みを損なうことなく、運用データからより迅速かつ詳細なリアルタイムの分析情報を引き出したいと考えている企業向けに設計されています。これにより、デベロッパーとデータアナリストの両方に新たな可能性が切り開かれることをとても嬉しく思います。Spanner のカラム型エンジンをぜひ真っ先にお試しください。Spanner カラム型エンジンのプレビュー版へのアクセスをリクエストするには、今すぐご登録ください。皆様がどのようなものを構築されるか楽しみにしております。

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

-ソフトウェアエンジニア、Alan Jin

TimeTree: Spanner への移行でサービスの継続性を確保、ビジネスのさらなる成長を支える土台を確立

Fri, 25 Jul 2025 01:00:00 +0000

カレンダーシェアアプリ「TimeTree」を開発・運営している株式会社TimeTree（以下、TimeTree）。多様なユーザーの予定管理を支える同社では、さらなるビジネスの成長に備えてサービス基盤の刷新に着手。他クラウドのデータベースサービスから、 Google Cloud の Spanner へ移行したことにより、サービスの継続性を確保するとともに、運用体制の大幅な改善を実現しました。今回は、この移行プロジェクトを担当したエンジニア 2 名に話を伺いました。

利用しているサービス:
Spanner, Cloud Run, Datastream, BigQuery, Cloud Load Balancing, Cloud CDN, Memorystore for Valkey, Cloud Storage, Pub/Sub, Looker

利用しているソリューション:
データベースの移行

ビジネスの順調な拡大に影を落とす 3 つの懸念、その対策として Google Cloud を採用

「あの人と共に生きる未来へ誘おう」というビジョンを掲げる TimeTree では、家族や恋人、友人、チームなど、複数人で予定を共有できるカレンダーシェアアプリ「TimeTree」を開発・運営しています。このアプリはスケジュールを管理するだけでなく、予定ごとにコメントを投稿できたり、通知でやり取りを促したりする機能で、日常の中に自然にコミュニケーションが生まれる仕組みを備えている点が大きな特徴です。こうした工夫が評価され、2015 年のサービス開始以来、国内外で高い支持を獲得。2025 年 5月時点で登録ユーザー数は累計 6,500 万人を突破し、200 以上の国と地域で利用されるグローバルサービスへと成長しました。

しかし、ビジネスが順調に成長する一方で、サービスを支えるバックエンドのシステムには大きな懸念が発生していました。メインのデータを格納しているクラウドデータベースサービスが、TimeTree のサービス規模の拡大に対応できなくなってきたのです。

従来のデータベースサービスには、主に 3 つの問題がありました。1 つ目は、近い将来、データ量の増加によってストレージ容量の上限に到達する可能性が高いこと。2 つ目は、ユーザー数やセッション数の増加により、同時コネクション数が上限に到達しそうなこと。そして 3 つ目は DDL（データ定義言語）のオペレーションに必要なローカルストレージが、大きなテーブルを処理する際に枯渇してエラーになるケースが出てきたことです。

SRE チームマネージャーの金井栄喜氏は次のように説明します。

「TimeTree のデータは、1 つの予定に対してさまざまな情報がひも付いてくるため、データが増えるペースが速いという特性があります。今後のサービスの成長目標を考慮してデータ量やアクセス量を見積ったところ、近い将来、3 つのいずれの課題にも対処するのが難しくなることがわかりました。弊社はこれから新サービスの追加やグローバル展開の強化などを目指しており、ビジネスの重要な局面を迎えます。そこで、ビジネスが成長できる土台を用意する必要があると考え、問題が顕在化する前にシステム基盤の移行に踏み切りました。」

3 つの課題解決に向けて、TimeTree が移行先のデータベースサービスとして選んだのが Spanner です。金井氏によれば、シャーディング機能に大きなアドバンテージがあることが採用の決め手でした。

「もともと今回は、データ量の増加に起因する致命的な問題に対して、シャーディングで解決するアプローチを取る方針でした。その点、フルマネージドな Spanner であれば、すべて自動でシャーディングが行われるので、運用負荷を上げることなく導入できるという大きな魅力があります。拡張性が高く、最大コネクション数などの要件も満たしていたので、今後のビジネスの成長を見据えたときに、弊社に 1 番合っているのが Spanner だと判断しました。」

SRE チームソフトウェアエンジニアの Greg 氏は、従来より BigQuery や Google Workspace といったプロダクトを使用していたことも、Spanner の採用を後押ししたと言います。

「システム基盤を Google Cloud に統一することで、データ分析基盤として利用している BigQuery とのシームレスな連携が可能になり、運用負荷の軽減やコスト削減といった効果が期待できました。また、ユーザー認証基盤として Google Workspace を利用していたので、セキュリティの強化と運用簡易化にもつながると考えました。」

Google Cloud チームと連携した入念な準備で、大規模データのスムーズな移行に成功

Spanner の採用を検討している過程で、TimeTree では Google Cloud Tech Acceleration Program（TAP）を利用し、Google Cloud のエンジニアと共に短期集中のワークショップを実施。移行に向けた課題やその解決策を議論することによって、実践的な視点で実現の可能性を探りました。Greg 氏は、TAP での取り組みを次のように振り返ります。

「移行前のデータベースが MySQL だったので、Spanner への移行は大きなリスクが伴うとも考えていました。例えば、シャーディングのパフォーマンスへの影響を最小化するには、どのようなスキーマ設計にすればいいのか。あるいはレコード数が 150 億以上にもなるデータをスムーズに移行できるのかなど、多くの心配事がありました。そこで TAP では、事前に想定されるさまざまな問題に対して、小さなプロトタイプを作ったりしながら議論し、ひとつずつ解決策を見つけていきました。この段階で疑問や不安が解消されたことで、Spanner 採用の準備はかなりスムーズになったと思います。」

データのクレンジングや、Spanner に最適化したスキーマ設計、アプリケーションの変更など、移行のための準備は 1 年以上の時間をかけて入念に行いました。また、Google Cloud の開発チームとも連携し、大容量データを移行するための Spanner 移行ツールの性能向上など、短時間での移行を可能にする環境も整えました。その成果もあり、実際の移行作業では致命的な問題は発生せず、計画停止の範囲内で実施することができました。

移行作業を成功させた要因として、金井氏は緻密なプロジェクトマネージメントも挙げています。

「もともと今回のプロジェクトには、将来的なビジネスの成長に備えるという目的があったので、タイムラインが非常に重要でした。この点に関しては、少人数体制で進めていくことで意思決定の遅れを回避できたことが、成功の要因だと考えています。Google Cloud チームとしっかり連携したうえで協力いただけたことも、大きかったと感じています。」

自動シャーディングを備えた Spanner により、データベース運用の負担が大幅に改善

TimeTree が抱えていた 3 つの課題は、Spanner への移行によって完全に解消されました。懸念されていたシャーディングによるパフォーマンスへの影響も発生せず、自動スケーリングによってコスト最適化も実現できました。それに加えて、データベース運用の負担も大幅に軽減されています。Greg 氏は、こうした運用面での改善を特に重要な成果と捉えていました。

「移行前はデータ容量やコネクション数の上限を意識して、常にメトリクスを監視しながら調整する必要があり、大きな負担となっていました。シャーディングを導入したとしても、手動で運用するの場合、データ量に応じた調整が困難なので高いリスクが付きまといます。Spanner ではその心配がまったくないので、運用上の手間が大幅に改善され、心理的な負担も払拭されました。」

Spanner の多彩な機能や高い柔軟性は、TimeTree の社内文化にも大きな変革をもたらす可能性があると金井氏は語ります。

「これまで新しい機能やサービスを導入する際には、企画チームが立案し、それをエンジニアが実装するという進め方が一般的でした。一方で、Spanner の多様な機能を活用できるようになれば、エンジニア自らが、技術的な視点から企画を提案することも可能になると考えています。今回の Spanner への移行をきっかけに、エンジニアリング主導の発想や提案で社内全体に活気が生まれ、サービスの成長スピードも加速できるのではないかと期待しています。」

TimeTree では、これからも積極的に Google Cloud を活用していく方針です。直近の目標としては、今回のプロジェクトでは対象外だった、NoSQL データベースの Google Cloud への移行が挙げられます。また AI の導入にも意欲的です。具体的には、イベント表や予約表の画像から予定を自動作成する機能や、アルバムの画像を分析してグルーピングする機能などに、Vertex AI をはじめとする AI サービスの活用を検討しています。マスターデータのデータベースを Google Cloud に移行したことで、AI を使った新しい機能を提供できる可能性が広がっています。

最後に金井氏は、Google Cloud を活用した TimeTree の未来に強い意欲をのぞかせました。

「Google Cloud はグローバルな利用を前提にしたサービスが多く、グローバル展開を目指している弊社とは非常に相性が良いと感じました。プロダクトの成長も早く、欲しいと思う機能がどんどん追加されるので、まだまだ伸びしろが大きいクラウドだと実感しています。我々としても、もっといろいろなサービスを積極的に利用してナレッジを高め、自社のプロダクトを成長させていきたいと考えています。」

株式会社TimeTree
2014 年 9 月 1 日設立。「あの人と共に生きる未来へ誘おう」というビジョンのもと、カレンダーシェアアプリ「TimeTree（タイムツリー）」の開発・運営を行う。TimeTreeは、家族・恋人・友人・職場など、複数人でスケジュールを共有・調整できる仕組みにより、コミュニケーションの円滑化や予定管理の効率化を支援します。国内外での累計登録ユーザー数は 6,500 万人を超えており、ユーザーの多様な利用シーンに対応する機能拡充を進めながら、カレンダーを起点として多様なライフスタイル支援サービスの展開を目指しています。

インタビュイー（写真右から）
・SRE チームマネージャー　金井栄喜氏
・SRE チームソフトウェアエンジニア　Greg 氏

その他の導入事例はこちらをご覧ください。

Spanner の永続的な影響: 2025 ACM SIGMOD Systems Award の受賞

Tue, 08 Jul 2025 03:00:00 +0000

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

今年に入り、Association for Computing Machinery's Special Interest Group on Management of Data（ACM SIGMOD）は、Google のグローバル分散型データベースである Spanner が 2025 SIGMOD Systems Award を受賞したと発表しました。SIGMOD Systems Award は、大規模なデータマネジメントの理論や実践に技術的な貢献を通じて大きな影響を与えたシステムを特に称えるものです。Spanner チーム全体、特に Spanner の開発初期から携わってきたエンジニアを代表して、このような名誉あるコミュニティから評価をいただいたことを、心から光栄に思います。Google は、6 月 22～27 日にドイツのベルリンで開催される 2025 SIGMOD カンファレンスにプラチナスポンサーとして参加します。

2022 SIGOPS Hall of Fame Award に続いてこの賞を受賞したことを鑑みると、この光栄がさらに意義のあるものに感じられます。SIGOPS Hall of Fame Award では、TrueTime や Google のネットワークインフラストラクチャなどのテクノロジーの重要な役割が強調され、最初の Spanner 論文で示された当初のビジョンの永続的な重要性が再確認されました。

Spanner の中核的なイノベーション: TrueTime と外部整合性

Spanner がこのように評価されたことは、Google が数年前に掲げたビジョンと、Spanner が実現する新しいアプリケーション構築方法の強力な裏付けとなります。アワードの授与理由によると、Spanner は「リレーショナルデータマネジメントを再考し、グローバル規模で外部整合性のある直列化可能性を実現した」ことが評価されました。

なぜ「再考」と言われているのでしょうか。Spanner 以前のデータベースでは、ACID トランザクションと SQL か、またはスケーリングとマルチデータセンターの信頼性か、どちらかを選ぶ必要がありました。スケールと可用性を確保するには分散システムが必要であり、それは結果整合性や他の形式のベストエフォート型同期を意味していました。Spanner は、この選択が絶対的なものではないことを示しました。つまり、分散システムの水平スケーラビリティに加えて、トランザクションと SQL のパワーおよび使いやすさを兼ね備えたデータベースを構築できることを示しました。スケールが最優先事項となっている企業は、Spanner によりデベロッパーの速度とアジリティを取り戻すことができました。Spanner は、分散アプリケーションに必要なロジックを大幅に簡素化します。デベロッパーは、データベースが世界中にまたがっている場合でも、単一の一貫したエンティティであるかのようにデータベースの状態を推論できます。

Spanner が外部整合性を実現できる主な要因は TrueTime です。TrueTime は、単なる同期グローバルクロックを超えて、クロックの不確実性を区切られた間隔として公開するスマートな API です。これにより、より高度なアルゴリズムでイベントの順序を推論することが可能になります。Google の TrueTime 実装では、GPS 受信機や原子時計などの特殊なハードウェア参照を使用して、信頼性が高く、非常に厳密な時間制限を実現しています。Spanner は、この区切られた不確実性を利用して外部整合性を実現します。トランザクションが commit されると、Spanner は TrueTime から派生した commit タイムスタンプを割り当てます。その後、Spanner は「commit wait」を強制します（これは、トランザクションの永続化と同時に行われることがあります）。その結果、トランザクションの効果を可視化する前に、commit タイムスタンプが確実に過去のものになります。これにより、割り当てられた commit タイムスタンプには、データセンターをまたいでも、トランザクションの真のグローバルシリアル化順序が決定的に反映されます。結果は驚くべきもので、パフォーマンスを犠牲にせずに外部整合性を実現できます。

整合性とスケールのジレンマに対処する

この道のりについて本当の意味で理解するには、2000 年代初頭から半ばまでの Google を振り返ってみるのがよいでしょう。インターネットが爆発的に普及したため、最大の課題は、それに遅れないようソフトウェアインフラストラクチャをスケールすることでした。インターネットのコピーを、大量の汎用サーバーを使用して保存および処理できるデータベースが必要でした。これにより、驚異的なパフォーマンスとスケーラビリティを実現する内部システムが開発されましたが、トレードオフも伴いました。

これらのシステムに慣れ、Gmail のような大規模なインタラクティブアプリケーションの構築に使用し始めると、結果整合性やクロスシャード同期の処理の難しさ、あらゆる問題（複雑さにかかわらず）を Key-Value ペアとしてモデル化する際の摩擦について、社内の開発者から絶えず聞くようになりました。すぐに明らかになったのは、従来のリレーショナルデータベースの使いやすさと保証（ACID トランザクション、直列化可能性、外部整合性など）を備えた、グローバルに分散したデータベースを構築する必要があるということでした。これを、より多くのユーザーにサービスを提供できるより大きなデータベースという、Google の増大するニーズをあきらめることなく行う必要がありました。加えて、お客様との緊密な連携を通じて、これは実際には Google が構築できるものであることが明らかになりました。その後のことは周知のとおりです。

クラウドサービスとしての Spanner

Google のインフラストラクチャの要である Spanner は、Google 広告、Google 検索インデックス、Gmail、YouTube、Google フォト、Cloud Storage 用メタデータ、BigQuery など、Google の最も重要な地球規模のサービスに使用されており、極端な負荷下でもその堅牢性とスケーラビリティが実証されています。

論理的な次のステップは、Google Cloud を通じて社外のお客様がこれらの機能を利用できるようにすることでした。Spanner のリリースとそれに続く進化は、このテクノロジーを民主化することを目的としており、グローバルに整合性がありスケーラブルなデータベースの機能を、スタートアップからグローバル企業まであらゆる規模の組織にもたらし、アプリケーションの開発と運用を簡素化しました。

Spanner がお客様に提供する主要な価値は、その独自のアーキテクチャから直接生じたものです。

強整合性を伴うグローバルスケール: Spanner は、当初の約束を果たしています。つまり、リージョンや大陸をまたいで水平方向にスケール可能なデータベース全体にわたる外部整合性を備えた ACID トランザクション、そして必要に応じて自動的にデータ分散（シャーディング）を管理する機能です。これは、SIGMOD アワードで評価された機能に直接対応するものです。
比類のない可用性: 複数のゾーンまたはリージョンにわたる Paxos ベースの同期レプリケーションを活用することで、Spanner はマルチリージョン構成において業界トップクラスの 99.999% の可用性サービスレベル契約（SLA）を提供しています。これにより、極めて高いフォールトトレランスが実現し、ミッションクリティカルなアプリケーションのダウンタイムリスクが最小化されます。
運用の簡素化: Spanner はフルマネージドサービスであるため、シャーディング、レプリケーション管理、バックアップ、メンテナンスなどの複雑な運用タスクを自動化できます。これにより、開発チームは運用上の大きな負担から解放され、データベースインフラストラクチャの管理ではなく、アプリケーションの構築に集中できるようになります。これは、従来のシャーディングされたデータベースで必要となる手作業の量や、NoSQL システムのアプリケーションレイヤに整合性ロジックを実装する際の複雑さとは対照的です。
デベロッパーの生産性: Spanner には、Google SQL と PostgreSQL の両方の言語をサポートする、使い慣れた SQL クエリインターフェースが備わっています。これにより、デベロッパーの学習曲線が大幅に平坦化されます。さらに、強整合性により、結果整合性システム上に構築されたアプリケーションでよく発生する、データの同期と調整に関連する一連の複雑な問題がすべて解消されます。

お客様と業界を支援する

もちろん、2012 年に Spanner に関する最初の論文が公開されてから、現在のデータ環境は変化しています。AI ファーストとなった現代のデータ環境では、お客様はこれまで以上に、データの価値を最大限に引き出すことに注力しています。データは多くの場合、データモデル、スケーラビリティ、信頼性が異なる多数のシステムに分散しています。Google は、Spanner Graph、AI アプリケーション向けベクトル検索、統合された全文検索を導入することで、これらの新たな課題に正面から取り組んでいます。これにより、幅広いデータを統合し、整合性のある、スケーラブルな単一のプラットフォーム内で迅速に反復処理できるようになります。さらに、コンピューティングおよびストレージ密度の向上、エディションを通じた階層的料金設定、階層型ストレージなどの費用最適化機能により、データが増加しても費用対効果の高い運用を実現できるようお客様を支援してきました。最後の点として、Cassandra 互換 API など、各種ツールや機能との相互運用性を強化することにより、スケールアウトワークロードを Spanner に取り込みやすくしてきました。

SIGMOD アワードのような学術的評価は嬉しいことである一方、システムの影響を真に測る尺度は、ユーザーが現実の問題を解決し、革新的なアプリケーションを構築するうえでどの程度役立つかにあると、Google は常に感じてきました。Spanner における機能の独自の組み合わせは、さまざまな業界で変革をもたらすことが実証されています。

金融サービスでは、整合性、可用性、セキュリティが最重要事項ですが、Spanner は多くの重要なシステムの基盤となっています。Goldman Sachs などの企業は取引台帳の統合に、arigatobank などの企業はピーク時の負荷下でも完全な整合性を維持して大量の金融トランザクションを処理するために、このソリューションを利用しています。みんなの銀行などのデジタルネイティブの銀行は、インフラストラクチャ全体を Spanner 上に構築し、その可用性と整合性を活用して、厳格な規制要件と顧客の期待に応えています。

ゲーム業界は、スケールとリアルタイムインタラクションの限界を常に押し広げています。Spanner は、ゲームデベロッパーが、コロプラの「ドラゴンクエストウォーク」のような世界的に成功を収めているタイトルをリリースできるよう支援し、初日から数百万人の同時プレーヤーに対応しています。世界中のプレーヤーベース全体にわたってプレーヤープロフィール、ゲーム内のインベントリ、リーダーボードを整合性のある方法で管理し、予測不可能なトラフィックの急増に弾力的に対応する機能は、シームレスなプレーヤーエクスペリエンスを提供するうえで極めて重要な役割を担ってきました。

小売業と e コマースでは、Spanner は企業が現代の商取引の複雑さを管理できるよう支援しています。Walmart は、Spanner を使用して在庫と支払いの管理をモダナイズし、オンライン店舗と実店舗の間でリアルタイムかつ一貫したビューを提供しています。グローバルなオンラインショッピングモールおよび e コマースプロバイダである MercadoLibre は、Spanner を活用して、主要な商品の発売時に発生する需要の急増など、世界中の顧客のニーズに対応しています。

Uber などの運輸業界のリーダーは、Spanner を利用して、10,000 を超える都市で毎月数百万人の同時ユーザーと数十億回の移動を処理し、1 日あたり数十億件のデータベーストランザクションを処理しています。

これらの例は、多くの最新のアプリケーションにとって、グローバルな整合性、大規模なスケーラビリティ、高可用性、相互運用可能なマルチモデルという Spanner の独自の組み合わせが、単なる技術的なメリットではなく、ビジネスを可能にする基盤であることを示しています。リアルタイムのグローバル在庫、瞬時に整合性が保たれる財務記録、世界規模のシームレスなマルチプレーヤーエクスペリエンスを基盤とするビジネスモデルは、Spanner を使用することで大幅に簡素化され、リスクが軽減されて、実装が容易になります。

Spanner が形作る未来

SIGMOD アワードは、Spanner の開発と進化の過程に携わった 30 人以上の個人と、無数の現職および元職の Google 社員の貢献を称えるものです。当初の野心的なコンセプトから、現在では世界に影響を与えるシステムに至るまでの道のりを目の当たりにできたことは光栄に思います。公開された OSDI 原著論文から今回の 2025 SIGMOD Systems Award に至るまでの道のりは、Google による 10 年以上にわたる継続的な研究、エンジニアリング、投資に光を当てるものです。このような長期的な取り組みは珍しく、Spanner の継続的な成功と影響力の背後にある重要な要素となっています。

お客様のおかげで、Spanner は進化し続ける生きたシステムとなっており、社内での使用とクラウドを利用しているお客様のニーズの両方によって推進される継続的な改善の恩恵を受けています。今後も、分散データベースの可能性の限界を押し広げていくことに尽力してまいります。Google は、AI を活用したアプリケーションなど、新しい種類のアプリケーションの実現を Spanner が支援することに期待を寄せています。また、世界を変える次世代のアプリケーションを構築するデベロッパーのために、データマネジメントを簡素化するというミッションを継続していきます。

Spanner の違いを体験する

2025 ACM SIGMOD Systems Award は大きな名誉であり、数年前に Google が歩み始めた道の正しさを証明するものです。2025 SIGMOD カンファレンスに参加される方は、6 月 24 日（火）午後 4 時 30 分に直接お会いして、Google チームの講演をお聞きいただけます。

整合性、スケーラビリティ、可用性に関する Spanner の機能が、直面している課題のお役に立てそうであれば、ぜひ以下の方法で詳細をご確認ください。

Spanner を実際に使用し、サポートされている機能とユースケースをご確認いただけます。90 日間の Spanner 無料トライアルインスタンスをご利用ください。
ドキュメントで詳細をご確認いただけます。
学術的な内容に関心をお持ちの場合、Spanner に関する原著論文と後続論文をお読みください。

最後に、Spanner は信頼性、スケーラビリティ、グローバルな整合性を備えたアプリケーションを構築するための新たな可能性を切り開くものであり、お客様が Spanner を使用してどのようなアプリケーションを構築されるのか、楽しみにしています。

-Spanner 創設者エンジニア、Google Fellow、Christopher Taylor

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

MySQL から Spanner へのアプリの移行がさらに簡単に

Mon, 26 May 2025 16:00:00 +0000

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

これからのアプリケーションは、AI を活用した動的なエクスペリエンスを、予測不可能な規模でダウンタイムなく提供することが求められますが、これまでのデータベースではこれに十分対応することができません。Google Cloud はその解決手段として、MySQL から Spanner へのデータベースワークロードのモダナイゼーションをシンプルにするための新しい機能、パフォーマンスの向上、そして移行ツールを Google Cloud Next 25 で発表しました。Spanner は、Google Cloud の水平方向にスケーラブルな常時稼働のオペレーショナルデータベースです。

MySQL は、現在の最も差し迫ったスケーリングと可用性のニーズに対応できるよう設計されてはいません。シャーディングや手動レプリケーションなどの一般的な修正は、複雑でリスクが高く、ビジネスが最も許容できないまさにそのタイミングで発生します。セルフマネージドデータベースにおけるスケーリングの計画と実行には通常、高額なアフターマーケットソリューションが必要になります。その設計とテストには数か月かかることもあり、開発チームのマンパワーを、より緊急性の高いユーザー向け機能に割けない状況にしています。また、スケーリングのオーバーヘッドのため、組織はピーク時の使用量に合わせてプロビジョニングすることが多く、その容量がほとんど使用されないこともあります。

これからのアプリケーションは、トランザクション処理以上のことも行う必要があります。セマンティック検索、協調レコメンデーション、リアルタイムの不正行為検出、動的料金設定などの新しいエクスペリエンスでは、それぞれデータの保存とクエリの方法が異なります。

aside_block: <ListValue: [StructValue([('title', '300 ドル分の無料クレジットで Google Cloud データベースを試用'), ('body', <wagtail.rich_text.RichText object at 0x7f93ae598150>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

MySQL から Spanner へのライブマイグレーションがシンプルに

Spanner には、アプリの成長とモダナイズに苦労している組織を支援するため、ダウンタイムをほぼゼロに抑えながら、本番環境のワークロードを MySQL から安全かつ簡単に移行するための明確な移行パスが用意されています。移行後は、Spanner のハンズフリーの信頼性と、リッチなグラフ、全文検索、統合 AI 機能を利用できます。

そのカギとなっているのが Spanner 移行ツールです。このツールは、スキーマとデータの移行を自動化して、ライブカットオーバーをサポートします。たとえば、ペタバイト規模のシャーディングされた MySQL データベースを数か月ではなく数日で統合できます。改良されたデータ移動テンプレートにより、大幅に少ない費用でスループットを高めることができるほか、移行時にデータを変換できる柔軟性も得られます。また、組み込みのリバースレプリケーションが更新され、シャーディングされた MySQL インスタンスに対して Spanner からデータが再同期されるようになったため、障害発生時に準リアルタイムでフェイルオーバーできます。最後の点として、新しい Terraform 構成と CLI インテグレーションにより、実装を柔軟にカスタマイズすることができます。

Spanner 移行ツールのアーキテクチャ

コードとクエリの変更量は少なくして、レイテンシの改善を実現

アプリケーションコードとクエリの移行にかかる費用と複雑さをさらに軽減するため、MySQL に密接にマッピングされる、リッチな新しいリレーショナル機能セットが Spanner に導入されました。

Repeatable Read は MySQL のデフォルトの分離レベルであり、パフォーマンスと整合性のバランスを取っています。この柔軟性が Spanner にも導入されます。新しい Repeatable Read 分離（現在プレビュー版で提供中）は、Spanner の既存の Serializable 分離を補完するものです。MySQL デベロッパーにも馴染みがある分離レベルで、パフォーマンスを大幅に向上させるための追加の手段となります。実際、一般的なワークロードのほとんどでは、以前の Spanner と比較してレイテンシが最大 5 倍改善されます。さらに、新しい auto_increment キー、SELECT…FOR UPDATE、80 個近い新しい MySQL 関数により、アプリケーションを Spanner に移行するために必要な変更が大幅に減少します。

「当社のカレンダー共有サービスの人気が高まるにつれ、需要は着実に増加しました。ユーザーが 5,500 万人に達したとき、データ量とアクティブ接続の両方において Aurora MySQL のスケーラビリティの限界に達しました。しかし、問題はスケーラビリティだけではありませんでした。アプリチームはデータベースの管理に多くの時間をとられたため、機能開発にかけられる時間が減りました。フルマネージド Spanner がこの問題を解決し、費用の大幅な削減と将来の成長が可能になりました。移行は簡単なことではありませんが、Google Cloud のサポートと Spanner 移行ツールのおかげで、最小限のダウンタイムで完了することができました。」 - TimeTree、SRE マネージャー、Eiki Kanai 氏

Forrester Consulting による最近の Total Economic Impact 調査でも、インタビュー対象のお客様を代表する複合組織において、Spanner は 3 年間で 132% の ROI と 774 万ドルの総利益をもたらしたことがわかっています。これは主に、セルフマネージドデータベースを廃止したこと、そして Spanner の弾力性のあるスケーラビリティと、組み込みのハンズフリーの高可用性オペレーションを活用したことによるものです。Forrester の調査によると、Spanner を使用することで、計画外のダウンタイムやシステムメンテナンスによる中断が減り、新しいアプリの導入にかかる時間が短縮され、開発チームは複雑な再設計プロジェクトや新たな資本支出なしで新しい機会に対応できるようになりました。

使ってみる

組織の次の成長マイルストーンにおいてストレスを軽減し、開発チームを成功に導く点で Spanner がどのように役立つかについて詳しくは、https://cloud.google.com/spanner をご確認ください。リファレンスアーキテクチャ、移行の成功事例に加えて、無料評価を実施している認定パートナーのディレクトリをご覧いただけます。MySQL からの移行を成功させる方法についてのドキュメントもご用意しております。Spanner を実際にお試しいただくには、90 日間の無料トライアルをご利用ください。本番環境インスタンスは月額 65 米ドルからご利用可能です。

-シニアプロダクトマネージャー、Justin Makeig

Spanner

Spanner キューの発表: エージェント ワークロードとその先を支えるトランザクション メッセージング

エージェント アーキテクチャの主な機能

Spanner キューが自律型エージェントに不可欠な理由

エージェント ワークフローの先

仕組み: Spanner キューのトランザクション メカニズム

Spanner 変更ストリームと Spanner キューの比較

使ってみる

JR東日本: Spanner と Cloud Run で「タッチトリガー」を実現し、改札データを起点に新たなコミュニケーションと価値を創出

改札というリアルな接点から生まれる、生活に密着したデータ

Spanner と Cloud Run で厳しいトラフィック処理の要件をクリア

「タッチトリガー」が活性化させていく、毎日の暮らしと地域コミュニティ

Spanner: DML トランザクションの累積ミューテーション上限を撤廃

高い上限で柔軟性が向上

技術的な考慮事項

ロックと中止

DML と Mutation API

ミューテーション数について

Java の実装例

変更がない点

ベスト プラクティス

パブリック データとプライベート データを統合: Spanner のデータコモンズによるナレッジグラフのスケーリング

データコモンズ ナレッジグラフのディメンション

Spanner Graph を活用したモダンなインフラストラクチャ

Spanner Graph への移行による主なメリット

SDMX 3.0 の相互運用性によるシステムの橋渡し

データコモンズ プラットフォームのプライベート インスタンスの変革

早速始めましょう

Spanner のマルチモデル アーキテクチャでエージェントの時代を加速

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

Spanner Omni: マルチモデル機能をどこでも利用可能

業界の基準を確立するコア データベースの機能

エージェントの時代の統一ビジョン

グラフ技術を活用した信頼できるエージェント プラットフォームの構築: Yahoo の事例

ケーススタディ: エージェント型メディア購入

信頼できるアクション システムのアーキテクチャ

ナレッジグラフ: エージェントをビジネスの実態にグラウンディング

コンテキスト グラフ: 監査可能なメモリの作成

人間ができる範囲からエージェントならではの規模へ

あらゆる業種に適用できる設計

使ってみる

Spanner Graph アルゴリズムの発表: 接続されたデータに Google グレードのインテリジェンスを提供

アルゴリズム: 接続されたデータからより深い分析情報を取得

デベロッパー エクスペリエンスの統合

業界のリーダーからの信頼

よりインテリジェントなアプリケーションの構築

使ってみる

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

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

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

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

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

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

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

Spanner Omni が重要である理由

Spanner Omni の紹介

Spanner Omni を支える技術

アクセス方法

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

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

新機能

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

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

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

使ってみる

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

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

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

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

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

今すぐ始めましょう

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

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

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

未来に向けた青写真

Spanner が評価された理由とは

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

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

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

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

Spanner キューの発表: エージェントワークロードとその先を支えるトランザクションメッセージング

エージェントアーキテクチャの主な機能

エージェントワークフローの先

仕組み: Spanner キューのトランザクションメカニズム

ベストプラクティス

パブリックデータとプライベートデータを統合: Spanner のデータコモンズによるナレッジグラフのスケーリング

データコモンズナレッジグラフのディメンション

データコモンズプラットフォームのプライベートインスタンスの変革

Spanner のマルチモデルアーキテクチャでエージェントの時代を加速

業界の基準を確立するコアデータベースの機能

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: Yahoo の事例

信頼できるアクションシステムのアーキテクチャ

コンテキストグラフ: 監査可能なメモリの作成

デベロッパーエクスペリエンスの統合

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

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

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

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

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

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

Spanner のカラム型ストレージ: ハイブリッドアーキテクチャ