Google Cloud は2026年10月2日、Spannerに組み込んだメッセージング機能「Spanner queues」の一般提供を発表しました。主な対象は、処理の完了を待たずに次の作業へ進む「非同期処理」を伴うAIエージェント の業務の流れです。データの状態更新と、次に実行するタスクの登録をまとめて確定できるようになります。
状態更新と次のタスクをまとめて確定
Spanner queuesの中心となるのは、関連する操作を一まとまりで確定する「トランザクション」を使ったメッセージングです。キューとは、処理を待つタスクをためておく仕組みを指します。
Google Cloudによると、状態更新とタスク登録は、両方が成功するか、両方が失敗する形で扱えます。「状態だけ更新されたが、次のタスクは登録されていない」という食い違いを避けるための機能です。
発表に添えられた絵。1回のCOMMITで、表はSPANNERへ、封筒はqueueへ送られる 出典: Google Cloud Blog (引用) メッセージはすぐに配信するほか、将来の日時を指定して配信できます。時間を置いて処理をやり直す「遅延再試行」も、別の予定管理の仕組みである外部スケジューラーを使わずに設定できるとしています。
用途として挙げられているのが、複数のAIエージェント間での作業の引き継ぎ です。引き継ぎを、保存され続けるメッセージとして扱えます。また、人の承認を待つ状態と、期限を過ぎた後の通知予約を同時に記録できます。AI以外では、小売の注文・在庫処理や、金融の非同期タスク処理も用途に挙げています。
配信の保証と処理完了の扱い
タスクを実行するプログラムである「ワーカー」は、ストリーミングSQLでタスクを取得できます。SQLは、データを検索・操作するための言語です。長時間かかる処理では、メッセージを担当する期間である「リース」を延長できるとしています。
Google Cloudは、メッセージを少なくとも1回配信し、受領確認は最大1回にすることを保証すると説明しています。処理完了の状態記録と受領確認を同じトランザクションで行えることなどにより、厳密に1回の処理を実現できるとしています。
ここで、少なくとも1回の配信と、厳密に1回の処理は別の説明です。導入の検討では、メッセージが届く回数だけで判断せず、状態記録と受領確認をどのようにまとめるかを確認する必要があります。外部システムへの操作も含む業務では、どこまでが保証の対象になるかを開発担当者や委託先に確認してください。
処理待ちのタスクや実行履歴は標準SQLで確認できます。キューの定義・確認・管理にはGoogleSQLを使えるとしています。
情シス・会社への影響
今回の発表で注目したいのは、AIの回答能力ではなく、業務処理のつなぎ方です。AIエージェントへの引き継ぎや承認待ちを含む仕組みを検討している会社は、「現在の状態」と「次に動かすタスク」を一緒に管理できるかが評価項目になります。
既存の連携機能との役割の違いも確認が必要です。Spanner change streamsは変更データの連携向けですが、Spanner queuesはタスク制御向けです。既存の連携をすべて置き換えるものとしてではなく、どの業務のどの部分に使うかを整理して検討してください。
また、処理待ちタスクや実行履歴をSQLで確認できるため、運用担当者が何を見て、誰に対応を依頼するかも検討事項になります。開発側だけでなく、情シスと委託先の間で確認方法や担当を決めておくとよいでしょう。
今回の資料には、日本での利用可否、日本語対応、日本向けの価格は書かれていません。一般提供の発表だけで自社環境での利用条件を判断せず、契約や提供条件を確認する必要があります。
いま確かめること
構成図や設計書で、状態更新とタスク登録を別々に行っている箇所、承認待ちや再試行が必要な箇所を洗い出す。
開発担当者や委託先に、処理完了の記録と受領確認をどうまとめるか、外部システムへの操作は保証の対象かを確認する。
既存のSpanner change streamsやタスク管理の仕組みと、Spanner queuesの役割分担を整理する。
処理待ちタスクや実行履歴を確認する担当者、確認手順、異常時の連絡先を運用ルールにまとめる。
契約資料や提供条件で、自社環境での利用可否と料金を確認する。日本向けの条件は今回の資料だけでは判断しない。
