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

※この投稿は米国時間 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 キューに実行タスクをディスパッチします。

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

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

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

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

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

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

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

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

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