データベース

AlloyDB と Memorystore for Valkey で AI エージェントの長期記憶を実装する方法

Fri, 16 Oct 2026 02:00:00 +0000

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

エンタープライズ AI エージェントが、複数日にわたる複雑なワークフローや長期にわたるタスクを実行するには、永続メモリが必要です。このブログ投稿では、短期バッファメモリに Memorystore for Valkey を、長期永続メモリに AlloyDB AI を使用する 2 層メモリアーキテクチャによって、重要なデータとエンタープライズガードレールを維持しながら、トークン消費量を最大 70% 削減する仕組みを見ていきます。

たとえば、ユーザーの休暇の予約を支援する、パーソナライズされた旅行エージェントを構築するとします。ユーザーは数日間にわたってエージェントと何度もやり取りし、旅行プランのアイデア出しから具体的な購入・予約の検討に至るまで、さまざまな質問をします。真にシームレスなエクスペリエンスを提供するには、このエージェントは、以前のセッションで設定されたフライトの好み（例: 「直行便のみ」）、ホテルの予算、食事の要望（例: 「グルテンフリーのメニューが必要」）を記憶しておく必要があります。さらに重要なのは、会話が観光のおすすめや旅行プランの計画といった細かい内容に深入りしても、これらの重要情報を保持する必要がある点です。エージェントは、追加の質問や訪問先に関する魅力的な詳細情報によって、ユーザーの基本的な要件や決定事項を忘れたり上書きしたりすることがないようにしなければなりません。

ステートフルなワークフローは、LLM のステートレスな性質と本質的に矛盾する

AI エージェントは、マルチターンの会話や長期にわたるワークフローに活用されていますが、大規模言語モデル（LLM）はセッション間でステートレスのままとなっています。ユーザーが数日後にエージェントを再び利用する際、モデルはコンテキストウィンドウが空の状態で処理を開始します。アプリケーションがエージェントの長期メモリを使用して過去のコンテキストを再構築するように設計されていない限り、ユーザーは目標とコンテキストを最初から説明し直す必要があるため、ストレスのたまる断片的なユーザー体験になってしまいます。

100 万トークンのコンテキストウィンドウが標準となった現在、この問題に対する手っ取り早い解決策としてよく使われるのは「コンテキストスタッフィング」です。これは、未加工のチャット履歴からツールの実行ログまで、プロンプトに収まるあらゆるものを会話のターンごとに詰め込むというものです。実際、これは AI モデルが使用され始めた初期によく見られたパターンです。しかし、この手っ取り早い解決策では、規模が大きくなるとすぐに問題が発生します。メッセージごとのトークン消費量が倍増し、単純なプロンプトでも応答時間が 30 秒を超えるようになり、モデルでは「lost in the middle（情報の埋もれ）」と呼ばれる精度低下が生じ、大量のプロンプトテキストに埋もれた重要な指示を見落とすようになります。

もう一つの一般的な回避策は、ローリングサマリーを使用することです。これは LLM に古いメッセージを定期的に要約して、短い文章に圧縮するよう指示する手法です。これによりプロンプトのサイズは削減されますが、LLM ベースの要約は本質的に情報の欠落を伴います。数回の圧縮を繰り返すうちに、些細ながらも重要な詳細がバックグラウンドノイズとして除去されてしまうからです。数ターンも経つと、エージェントはユーザーが最初に設定した制約を、いつの間にか無視するようになります。以前の会話やマルチターンタスクの記憶を保持するには、ユーザー体験の低下や、新たなボトルネックの発生を回避したうえでの、よりスケーラブルなアプローチが必要であることは明らかです。

2 層メモリアーキテクチャの実装

ガードレールと制約を遵守し、信頼性と費用対効果に優れたエンタープライズエージェントを構築するには、2 層メモリアーキテクチャの採用をおすすめします。

短期セッションバッファ: トークン数で制限されたスライディングウィンドウを使用して、アクティブな会話ターンをメモリにキャッシュします。これにより、デバイスをまたいだ複数回のやり取りでもコンテキストウィンドウのデータ量を一定に保ち、直近のメッセージを常に最新の状態に保つことができます。この階層では、ターンごとに 1 ミリ秒未満の高速かつ高スループットなルックアップが必要となるため、Memorystore for Valkey がアクティブなセッション状態の維持に最適です。
長期永続メモリ: 重要な事実、ユーザーの好み、エピソード的事実をセッションをまたいで保存します。この階層では、トランザクションの整合性、データガバナンス、リレーショナルデータとベクトルにわたるハイブリッド検索が必要となります。これらは、AlloyDB AI がネイティブに提供する機能です。

長期記憶とアクティブセッションバッファの両方をリレーショナルデータベースに直接保存することも可能ですが、インメモリキャッシュを備えた 2 層アーキテクチャの方がパフォーマンスとスケーラビリティが向上します。アクティブセッションバッファは非常に一時的なもので、会話のターンごとに 1 ミリ秒未満の高スループットな更新が必要です。これらの高頻度で発生する書き込みをインメモリ Key-Value キャッシュで処理することで、リレーショナルデータベースでの書き込みの増大とテーブルの肥大化を防ぎます。これを行わないと、頻繁な行の削除や負荷の高いバキューム処理が必要になってしまいます。これは、データベースの前段にキャッシュ階層を追加して、アクセスが集中している行への高頻度なルックアップをオフロードするのと同様の仕組みです。この分業により、プライマリデータベースは負荷を抑えて応答性の高い状態を維持し、トランザクションの整合性、複雑なハイブリッドベクトル検索、長期的な分析クエリの実行など、本来の目的にリソースを集中させることができます。

Memorystore for Valkey の短期キャッシュと AlloyDB AI のネイティブ機能を組み合わせることで、エンティティ抽出、メモリ圧縮、セッションをまたいだメモリ、ハイブリッド検索をデータベース層内で直接実行し、アクティブなプロンプトを軽量かつ高速に維持し、優れた費用対効果を実現できます。

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

4 種類のメモリについて

エージェントの長期的なステートを効果的に整理するために、エージェントのメモリを、前述の短期ストレージレイヤと長期ストレージレイヤにわたる、互いに補完し合う 4 つのタイプにさらに分割します。

メモリのタイプ	保存される内容	ストレージレイヤ	存続期間
バッファ（短期）	直近の未加工の会話履歴	Memorystore for Valkey	アクティブなセッション
要約メモリ	古いターンの履歴を圧縮する（一般に「コンパクション」と呼ばれる）	Memorystore for Valkey	マルチターンウィンドウ
エピソード記憶	過去のアクション、イベント、ツールの出力	AlloyDB for PostgreSQL（構造化 SQL + 全文検索 + ベクトルによるハイブリッド検索）	永続的
エンティティとルールの記憶	ユーザーの好み、制約、禁止事項	AlloyDB for PostgreSQL（構造化 SQL + 全文検索 + ベクトルによるハイブリッド検索）	永続的

短期的な会話コンテキストを構造化された長期的なルールから分離することで、エージェントは、トークンウィンドウを未加工のインタラクションログで埋め尽くすことなく、関連するコンテキストをオンデマンドで取得できます。

階層型メモリアーキテクチャのブループリント

以下の図は、アプリケーションオーケストレーションレイヤ、Memorystore for Valkey の短期バッファ、AlloyDB AI の長期リポジトリを接続する読み取りパスと書き込みパスの概要を示しています。

このシステムは、以下の 2 つの連携した実行パスで動作します。

読み取りパス: ユーザーが質問すると、アプリケーションは Memorystore for Valkey からアクティブなスライディングウィンドウを取得し、ai.generate を使用してデータベース内クエリの正規化を実行します。そして ai.hybrid_search を使用して AlloyDB にクエリを送信し、スコープ設定されたエンティティルールと関連するエピソード的事実を取得します。
書き込みパス: 回答が生成されると、会話のターンはすぐに Memorystore for Valkey にキャッシュされます。非同期のバックグラウンドキューワーカーが、会話のやり取りから構造化エンティティを抽出し、AlloyDB に直接書き込みます。AlloyDB では、トランザクション自動エンベディングによってベクトル表現が即座に計算され、データベースに保存されます。

ビジネスへの影響と費用対効果

開発におけるマルチターンの対話（45 ターン以上、大量のツール実行）を対象としたベンチマークテストでは、短期キャッシュを長期永続化から分離することで、単純なコンテキストスタッフィングと比較して、費用削減とパフォーマンス向上を実現しました。

指標 / ディメンション	単純なコンテキストスタッフィング	階層型メモリ（AlloyDB + Valkey）	ビジネスへの最終的な影響
アクティブなプロンプトのサイズ（45 ターン目）	747,033 トークン	83,262 トークン	プロンプトが 88.9% 縮小
45 ターン目のレスポンスレイテンシ	33.5 秒	6.7 秒	80.0% 高速なレスポンス
ターンごとのレスポンスまでの待ち時間	33.5 秒	4.2～6.7 秒	36%～80% 削減
累積セッショントークン	1,790 万トークン	409 万トークン	トークンと費用を 72.0% 削減
ルールと制約の再現率	ターンごとに低下	低下しない	ACID を維持した再現率

注: 上記の指標は、実際のエンタープライズ AI ペアプログラミングアシスタントが、複数のセッション、プロジェクト、コンテキストの切り替えにわたって開発者とやり取りする様子を再現した、シミュレートされた開発ワークロードに基づく内部ベンチマーク結果を反映したものです。実際の費用削減とレイテンシは、プロンプトの構造、クエリの頻度、データ量によって異なります。

これらの結果は、階層型メモリがエージェントのユニットエコノミクスをどのように変化させるかを示しています。ターンが追加されるたびに費用曲線が上昇するのではなく、プロンプトサイズが一定の範囲内に収まるため、高速の応答時間を維持しながら、継続的な LLM API 費用を削減できます。

AlloyDB AI の核となる技術的メリット

AlloyDB AI は、コア AI 機能をデータベースエンジンに直接組み込むことで、永続的なエージェントメモリの実装に伴う運用上のオーバーヘッドを削減します。その主な特長は以下のとおりです。

データベース内トランザクション自動エンベディング（ai.initialize_embeddings）: AlloyDB は、Agent Platform（旧称 Vertex AI）とのネイティブ統合を使用して、テキスト列のベクトルエンベディングを自動的に生成し、1 秒あたり最大 3,000 個のエンベディングを処理できます。incremental_refresh_mode => 'transactional' を使用すると、AlloyDB は同じトランザクション内でソースデータが変更されるとエンベディングを最新の状態に保つため、カスタムエンベディングパイプライン、外部スケジューラ、複雑な再試行ロジックが不要になります。
データベース内生成 AI 関数（ai.generate）: AlloyDB では、Gemini などの基盤モデルを SQL クエリから直接実行できます。これを使用すると、データベース内でクエリを分解できます。つまり、ユーザーの複合的な質問を単一の要素からなるサブクエリに分割し、相対的な時間表現（「前回のセッション」など）を明示的な識別子に解決できます。アプリケーション側で個別にラウンドトリップを行う必要もありません。
組み込みの Reciprocal Rank Fusion（ai.hybrid_search）によるネイティブハイブリッド検索: AlloyDB は、エンジン内で直接 Reciprocal Rank Fusion（RRF）を実行する組み込み SQL 関数を提供します。ベクトルコサイン類似度（HNSW または ScaNN インデックスに対する <=>）と PostgreSQL 全文検索（BM25、RUM、または GIN を使用）を 1 回のデータベース呼び出しで組み合わせ、セマンティックマッチングと正確なキーワード検索を融合させます。同時に、メタデータフィルタプッシュダウン（filter_condition）をサポートすることで、パフォーマンスの向上と確定的なスコープ分離を実現します。
IAM 認証情報を使用した Agent Platform との直接統合: AlloyDB は、Google Cloud IAM サービスアカウントのロールとデータベース認証を使用して、Google Cloud のプライベートネットワーク経由で Agent Platform 基盤モデルに直接接続します。これにより、アプリケーションコードで API キーを保存、ローテーション、受け渡す必要がなくなります。
運用、ベクトル、ガバナンスの統合エンジン: AlloyDB は、リレーショナルビジネスデータ、ベクトルエンベディング、全文インデックス、エンタープライズ権限を、ACID 準拠の単一の PostgreSQL データベースに統合します。これにより、個別の運用データベースとベクトルデータベース間で発生するデータのドリフトや統合の複雑さを回避できます。

主な実装パターン

以下は、2 層メモリアーキテクチャの構成に使用されるコアデータベースパターンです。実行可能な完全な Python スクリプトと SQL スクリプトについては、対応する AlloyDB エージェントメモリ Codelab をご覧ください。

1. スキーマと自動エンベディングの設定

AlloyDB で、必要な拡張機能をインストールし、構造化メタデータ、全文検索用に生成された tsvector 列、ベクトルエンベディング列を含む agent_entities テーブルを定義します。

code_block: <ListValue: [StructValue([('code', "-- 1. Enable AI extensions\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;\r\nCREATE EXTENSION IF NOT EXISTS vector CASCADE;\r\nCREATE EXTENSION IF NOT EXISTS rum CASCADE;\r\n\r\n-- 2. Create structured entity & preference table\r\nCREATE TABLE IF NOT EXISTS agent_entities (\r\n entity_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n user_id TEXT NOT NULL,\r\n entity_name TEXT NOT NULL,\r\n project_id TEXT DEFAULT 'global',\r\n session_id TEXT,\r\n scope TEXT NOT NULL DEFAULT 'session',\r\n summary TEXT NOT NULL,\r\n summary_embedding VECTOR(768),\r\n summary_tsv TSVECTOR GENERATED ALWAYS AS (\r\n to_tsvector('english', entity_name || ' ' || summary)\r\n ) STORED,\r\n updated_at TIMESTAMPTZ DEFAULT NOW(),\r\n UNIQUE (user_id, entity_name)\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb82b2e50>)])]>

次に、ai.initialize_embeddings を使用してエンベディングを生成します。トランザクション モードを使用すると、ソースデータの変更に応じてエンベディングが最新の状態に保たれます。

code_block: <ListValue: [StructValue([('code', "-- Register transactional in-database auto-embedding\r\nCALL ai.initialize_embeddings(\r\n model_id => 'text-embedding-005',\r\n table_name => 'agent_entities',\r\n content_column => 'summary',\r\n embedding_column => 'summary_embedding',\r\n incremental_refresh_mode => 'transactional',\r\n batch_size => 10\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb82b2610>)])]>

最後に、HNSW ベクトルインデックスと RUM 全文検索インデックスを作成して、ハイブリッド検索を高速かつ効率的に行えるようにします。

code_block: <ListValue: [StructValue([('code', '-- Create vector and full-text indexes\r\nCREATE INDEX IF NOT EXISTS agent_entities_embedding_idx\r\n ON agent_entities USING hnsw (summary_embedding vector_cosine_ops);\r\n\r\nCREATE INDEX IF NOT EXISTS agent_entities_tsv_idx\r\n ON agent_entities USING rum (summary_tsv rum_tsvector_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb82b1ad0>)])]>

2. ネイティブハイブリッド検索による長期記憶のクエリ

読み取りパスで、ai.hybrid_search を使用して関連する長期エンティティを取得します。このネイティブ SQL 関数は、AlloyDB で直接 Reciprocal Rank Fusion（RRF）を実行し、ベクトル類似性検索と全文キーワード検索の結果をシームレスに再ランキングして、単一のデータベースクエリに結合します。

code_block: <ListValue: [StructValue([('code', 'def retrieve_hybrid_entities(\r\n conn,\r\n user_id: str,\r\n project_id: str,\r\n query_text: str,\r\n query_vector_literal: str,\r\n limit: int = 3\r\n) -> dict[str, Any]:\r\n """Queries long-term memory using AlloyDB native hybrid_search (RRF)."""\r\n filter_cond = f"user_id = \'{user_id}\' AND (project_id = \'{project_id}\' OR scope = \'global\')"\r\n \r\n search_inputs = [\r\n json.dumps({\r\n "data_type": "vector",\r\n "weight": 0.4,\r\n "table_name": "agent_entities",\r\n "key_column": "entity_name",\r\n "vec_column": "summary_embedding",\r\n "distance_operator": "<=>",\r\n "limit": 10,\r\n "query_vector": query_vector_literal,\r\n "filter_condition": filter_cond\r\n }),\r\n json.dumps({\r\n "data_type": "text",\r\n "weight": 0.6,\r\n "table_name": "agent_entities",\r\n "key_column": "entity_name",\r\n "text_column": "summary_tsv",\r\n "limit": 10,\r\n "ranking_function": "ts_rank",\r\n "query_text_input": query_text,\r\n "filter_condition": filter_cond\r\n })\r\n ]\r\n\r\n query_sql = """\r\n SELECT e.entity_name, e.summary, e.project_id, e.scope, e.updated_at\r\n FROM ai.hybrid_search(\r\n search_inputs => %s::JSONB[],\r\n include_json_output => false\r\n ) h\r\n JOIN agent_entities e ON e.entity_name = h.id\r\n WHERE e.user_id = %s\r\n LIMIT %s;\r\n """'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb82b3810>)])]>

3. AI 関数を使用したデータベース内メモリ圧縮

カスタムのプルーニングスクリプトを記述せずに長期的なストレージの増加を管理するには、AlloyDB で自動抽出および圧縮クエリを直接実行して、保存しておくべき重要な部分を特定します。このパターンでは、SQL 共通テーブル式（CTE）と ai.generate を使用して、古いエピソード的事実の履歴を高密度の要約に統合します。

code_block: <ListValue: [StructValue([('code', "-- Consolidate older episodic logs into a permanent summary\r\nWITH old_events AS (\r\n SELECT document AS content\r\n FROM langchain_pg_embedding\r\n WHERE cmetadata->>'user_id' = 'user_dev_42'\r\n AND created_at < NOW() - INTERVAL '30 days'\r\n ORDER BY created_at ASC\r\n LIMIT 50\r\n),\r\nconsolidated AS (\r\n SELECT ai.generate(\r\n 'Summarize these historical events into a dense memory paragraph:\\n' || string_agg(content, E'\\n'),\r\n model_id => 'gemini-3.5-flash'\r\n ) AS summary_text\r\n FROM old_events\r\n)\r\nINSERT INTO agent_entities (user_id, entity_name, summary, updated_at)\r\nSELECT 'user_dev_42', 'longterm_session_summary', summary_text, NOW()\r\nFROM consolidated\r\nWHERE summary_text IS NOT NULL\r\nON CONFLICT (user_id, entity_name)\r\nDO UPDATE SET summary = EXCLUDED.summary, updated_at = NOW();"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf923ba850>)])]>

たとえば、子どもを連れて飛行機を乗り継ぐことの複雑さに関する長いやり取りを、「直行便を希望」という要約にまとめることができます。

4. 2 層メモリアーキテクチャの ADK エージェントへの接続

コアの 2 層メモリアーキテクチャを構成したら、対応する Codelab で示されるように、デフォルトの ADK Memory プロバイダを拡張して、この 2 層メモリアーキテクチャを使用できます（例: ADKTieredMemoryProvider）。長期記憶を ADK エージェントにアタッチするには、次のようにツール（例: longterm_memory_tool）として提供するだけです。

code_block: <ListValue: [StructValue([('code', 'from adk_memory_provider import ADKTieredMemoryProvider\r\n\r\nagent = Agent(\r\n name="adk_memory_agent", model=GEMINI_MODEL, instruction="Initial instruction",\r\n tools=[long_term_memory_tool, run_command_tool],\r\n before_tool_callback=guardrail.create_before_tool_callback(USER_ID, "CloudRetail")\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf93431610>)])]>

エンタープライズガバナンスとマルチテナントセキュリティ

エンタープライズの本番環境でエージェントメモリを実行するには、厳格なセキュリティ境界とアクセス制御が必要です。まず、スコープとマルチテナントの分離を維持する必要があります。agent_entities の user_id、project_id、scope 列にインデックスを付け、PostgreSQL の行レベルセキュリティ（RLS）を適用することで、同じデータベースクラスタ内の部門、チーム、個々のユーザー間でメモリストアを分離できます。パラメータ化されたセキュアビュー（PSV）は、もう一つの確定的なアプリケーションレベルのセキュリティレイヤを提供し、悪意のあるプロンプトや過度に広範な SQL クエリから保護するのに役立ちます。

さらに、上記の実装パターンに示すように、メモリライフサイクルの自動管理を提供する必要があります。スケジュールされた SQL コンパクションクエリと時間ベースのパーティションプルーニングを組み合わせることで、データベースのフットプリントとクエリのレイテンシを長期にわたって予測可能な状態に維持できます。このアプローチの詳細については、対応する Codelab をご覧ください。

まとめと次のステップ

アクティブなコンテキストウィンドウを永続ストレージから分離することは、プロダクションレディな AI エージェントを構築するための実用的なアプローチです。1 ミリ秒未満のセッションキャッシュを実現する Memorystore for Valkey と、トランザクション対応の長期ストレージである AlloyDB AI を組み合わせることで、長期にわたるタスクや複数ターンのエージェントエクスペリエンス全体で厳格なビジネスルールを維持しながら、トークン費用を大幅に削減し、応答時間を短縮できます。

利用方法は次のとおりです。

対応する AlloyDB エージェントメモリ Codelab の実践的なチュートリアルを最後まで進め、実際に動作する 2 層メモリアーキテクチャをデプロイします。
データベース側の ML 機能の詳細については、AlloyDB AI のドキュメントをご覧ください。
自動ベクトルエンベディングの生成とハイブリッドベクトル検索の実行に関するガイドをご覧ください。

- Google、AlloyDB AI シニアエンジニアリングマネージャー、Itai Rosenblatt

- Google、AlloyDB AI / Cloud SQL 担当プロダクトマネージャー、Paul Ramsey

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 0x7fdf926bb3d0>)])]>

これにより、注文ステータスが 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 0x7fdf926b8d50>)])]>

マネージャーが 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 0x7fdf926bab50>)])]>

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 0x7fdf926b86d0>)])]>

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 0x7fdf926b8d90>)])]>

エージェントは、外部ツールの実行を完了すると（このとき 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 0x7fdf91f23a50>)])]>

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

Apache Iceberg を自動管理して大規模展開する: Spanner を活用した Lakehouse ランタイムカタログ

Wed, 14 Oct 2026 02:35:00 +0000

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

企業がレイクハウスアーキテクチャへとモダナイズを進めるなかで、Apache Iceberg などのオープンフォーマットに準拠した共有データ資産を作成し、複数のエンジンで使用できるようにするという動きが広がっています。このように、AI ネイティブなレイクハウスを構築すれば、データをセマンティックな知識に変換したり、プロアクティブにアクションを実行したりするなど、エージェントの規模での運用が可能となります。

レイクハウスの主要コンポーネントの一つはカタログであり、Apache Iceberg 環境では通常、Iceberg REST カタログがこれに該当します。Apache Iceberg カタログは、テーブルポインタの維持や、アトミックコミットの処理といった役割を担うほか、テーブルの場所に関する信頼できる唯一の情報源となります。しかし、大規模なエンタープライズがレイクハウスへとモダナイズするにしたがって、スケーラビリティと可用性を備えたマネージドカタログがレイクハウスアーキテクチャの一部として必要であるという認識が生まれつつあります。エージェントによるクエリの量が増えるにつれて、この重要性はさらに増していきます。エージェントが繰り返し実行する大量の細かなクエリに対応するために、基盤のマネージドカタログには、アトミック性、整合性、可用性、同時実行性を大規模なスケールで提供する能力が求められます。

このブログ投稿では、エージェント規模へと広がる最新のクラウド環境においてマネージドカタログが直面する課題を考察するとともに、Google Cloud のサーバーレスの Lakehouse ランタイムカタログがこうした課題の解決にどのように役立つかについて説明します。Lakehouse ランタイムカタログは、Google Cloud の常時稼働データベースである Spanner（実質的に無制限で拡張可能）を基盤とし、オープンな Apache Iceberg REST カタログ仕様に準拠しています。これにより、エージェントの時代に必要なスケーラビリティと可用性を提供する基盤となります。

レイクハウスのマネージドカタログが直面する課題

データエンジニアやインフラストラクチャ責任者の方々に話を伺うと、レイクハウスで大規模に本番環境の分析を行うことに関して、以下のような共通した課題を抱えています。これらはすべて、マネージドカタログにおいて解決すべきものです。

アトミックコミットと同時実行制御: Iceberg は、オプティミスティック同時実行制御（OCC）により、ACID トランザクションを保証しています。したがって、マネージドカタログに強固なアトミック比較交換（CAS）オペレーションを実装し、現在のメタデータポインタをスワップする必要があります。

高可用性と運用保守: カタログがダウンすると、クエリはその瞬間からエラーとなります。そのため、マネージドカタログは最重要な Tier-1 サービスに位置付けられます。

カタログを支えるデータベースのスケーリング: カタログの設計者は往々にして、テーブルのメタデータおよび状態の保存用データベースの選択において、難しいジレンマに陥ります。従来のスケールアップ型のリレーショナルデータベースは SQL に対応しており、ACID トランザクションを提供しますが、読み取り / 書き込みの同時実行処理が増えると、CPU、メモリ、ストレージ、接続数が垂直方向の限界に達します。これを回避するには、手動でのシャーディングが必要となりますが、その場合は、運用上のオーバーヘッドが膨大になります。一方、スケールアウト型のデータベースシステムは、即時整合性が得られない、管理が困難、エンタープライズに対応できない、といった問題があります。

テーブルのメンテナンス作業: カタログは、データの最適化まではしてくれません。人間の担当者が、データの圧縮、古いスナップショットの消去、マニフェストの書き換え、孤立ファイルのクリーンアップといった補助パイプラインを構築して運用する必要があります。

ガバナンスとセキュリティ: カタログは、セキュリティの門番として、以下を実装して維持することが求められます。

認証プロトコル（OAuth2 トークン交換、IAM 連携など）
名前空間からテーブルレベルまでのアクセス制御
一時的なストレージ認証情報（例: クエリエンジンに対して、広範なストレージに直接アクセスできる認証情報ではなく、有効期間の短いトークンを生成する）

Lakehouse ランタイムカタログ

これらの課題を解決するために、Google は Iceberg REST カタログをサポートする Lakehouse ランタイムカタログ（一般提供）を構築しました。Lakehouse ランタイムカタログは、高可用性を備えた完全にサーバーレスな統合メタデータレジストリであり、Apache Iceberg などの最新のオープンなテーブルフォーマットをサポートするようにゼロから設計されています。 Lakehouse ランタイムカタログでは、Apache Iceberg REST カタログ仕様をネイティブに実装することで、メタデータ検出をコンピューティングエンジンから分離しています。これにより、複数の Iceberg 互換エンジンが共有データ資産にアクセスできるようになり、ワークロードを迅速に本番環境に移すことが可能となります。Google はすでに、多くのお客様がマネージドカタログの移行をスムーズに行えるよう支援してきました。たとえば、Etsy は Lakehouse ランタイムカタログへと移行し、データを動かさずに結合することで、パイプラインクエリを 60% 高速化しています。

このアプローチには、アーキテクチャ上のメリットが以下のように多数あります。

オープン API: Iceberg REST カタログがサポートされているため、ユーザーは単一の統合データセットに対してさまざまな分析ツールを自由に使用できます。
マルチエンジンの相互運用性: 登録されたテーブルは、標準の REST インターフェースを介して、Google Cloud Managed Service for Apache Spark、BigQuery、オープンソースエンジンで即座に検出やクエリが可能になります。
Iceberg テーブルの読み取り / 書き込みの相互運用性: BigQuery、Managed Spark などの Iceberg 互換エンジンを使用して、Lakehouse ランタイムカタログに登録されている Iceberg テーブルに書き込めます。また、Managed Spark を使用して、外部カタログの Iceberg テーブルに書き込むこともできます。
エンタープライズグレードの機能を備えたフルマネージドの Iceberg ストレージ: Google 独自のインフラストラクチャを使用し、Iceberg テーブルでパフォーマンスの高い分析を実行できます。これにより、オープンソースの柔軟性に加え、パフォーマンス、スケーリング、ガバナンス、マルチモーダル処理のメリットが得られます。
データコピー不要: テーブル定義は、基盤となるオブジェクトストアの既存データを直接参照します。基盤となるデータの移動、書き換え、複製を行う必要はありません。
クラウド間の双方向のカタログ連携: 一時的な認証情報と OIDC トークン交換がサポートされており、Databricks Unity、Snowflake Horizon、AWS Glue のデータにアクセスできます。これにより、Google AI を AWS や Azure のデータに直接適用することが可能です。
一時的な認証情報によるセキュアなアクセス: カタログは複数の認可メカニズムに対応しており、一時的な認証情報とエンドユーザー認証情報のいずれかを選択できます。そのため、一時的な認証情報などの最新方式を使って、基盤となるオブジェクトストア（Cloud Storage、AWS S3、Azure Blob Storage）内のファイルに直接アクセスすることなく、テーブルにアクセスすることが可能です。
AI を活用したコンテキストとガバナンス: Lakehouse ランタイムカタログは、Knowledge Catalog および Cloud IAM と直接統合されているため、エージェント用の信頼できるコンテキストを定義したり、すべてのコンピューティングエンジンにテーブルレベルのセキュリティを一貫して適用したりできます。また、カタログ内の Iceberg テーブルの検索や、リネージや分析情報の取得にあらかじめ対応しています。
アトミックコミットによる同時実行制御、高可用性、スケーラビリティ: Google の地球規模のインフラストラクチャと Spanner を基盤としたアーキテクチャによって、データに合わせてメタデータをスケールするために必要な高可用性、同時実行性、スケーラビリティが得られます。たとえば、Cloud Storage のデュアルリージョンバケットとマルチリージョンバケットのサポートにより、フェイルオーバーのユースケースに対応できます。また、サーバーレスな NoOps 環境によって TCO 削減につながるほか、あらゆるサイズのワークロードに対応可能なスケーラビリティを得られます。

Lakehouse ランタイムカタログの原動力

Lakehouse ランタイムカタログは Spanner 上に構築されているため、高可用性、同時実行性、スケーラビリティに優れているのに加えて、強整合性が保証されています。従来のスケールアップ型のリレーショナルデータベースが、単一ノード内で垂直方向の限界に達するのに対し、Spanner は、読み取りと書き込みの両方で水平方向にスケールアウトできるという NoSQL システムならではの柔軟性に加え、完全なリレーショナル SQL のセマンティクス、複数テーブルでの ACID トランザクションというメリットを提供します。

Spanner のリージョン構成では最大 99.99% の可用性が得られ、Lakehouse ランタイムカタログにおいて高可用性を実現できます。さらに、Spanner が自動的なスケーラビリティを Lakehouse ランタイムカタログに提供します。Spanner は水平方向にスケーラブルなデータベースであるため、手動でのシェーディングは必要なく、コンピューティングおよびストレージのリソースが自動的かつ透過的にスケールされます。具体的には、Spanner がデータ量とクエリ負荷を動的にモニタリングし、データ範囲を分割して、ノード間で再分配します。コンピューティングノードは、CPU 使用率とストレージのしきい値に基づいて、動的にスケールされます。また、スプリットレベルで過負荷を自動検出し、過負荷状態のノードから重いスプリットを移動します。また、Spanner によって、「リレーショナルの整合性」と「分散によるスケーラビリティ」の間の従来のトレードオフが解消され、Lakehouse ランタイムカタログのユーザーは業界最高水準の整合性保証を享受できます。Lakehouse のトランザクションはシリアル化されており、データベース内のトランザクションの順序は、クライアント側でトランザクションのコミットが観察される順序と一致します。この基盤によって、Lakehouse ユーザーは、エージェント規模での運用を実現できます。

さらに、エージェントユースケースへの対応を強化するため、Lakehouse ランタイムカタログは Knowledge Catalog と直接統合されており、レイクハウス内の Iceberg テーブルを簡単に検出して、信頼できるコンテキストをエージェントに提供することができます。Spanner が提供する全文検索とネイティブのベクトル検索という効率的な組み合わせを Knowledge Catalog で活用して、単一のクエリ内で語彙キーワード検索とセマンティックエンベディングを併用し、検索の再現率を高められます。これらの 2 種類のインデックスタイプは同じベースデータセット上に構築されており、ベーステーブルが DML で操作されると、トランザクションの ACID 整合性を厳密に保ちながらインデックスが更新されます。そのため、運用上のオーバーヘッド、たとえば、同期パイプライン、外部ベクトル、全文検索システムの管理といった作業が発生しません。簡潔に言うと、Lakehouse ランタイムカタログを使用すると、エージェントのユースケースを迅速に市場に投入することが可能となります。

分析と運用のワークロードを組み合わせる

Apache Iceberg をベースにした、Google Cloud のボーダーレスな Lakehouse なら、分析データを運用ワークロードと組み合わせることができます。ユースケースとしては、Lakehouse のデータアセットと Spanner からの OLTP データを組み合わせて分析を実行する、Spanner やその他の運用データベースからレイクハウスのアセットにアクセスして低レイテンシのアプリケーションを実現する、ファーストパーティおよびサードパーティのエージェントで会話型分析を行う、など多岐にわたるものがあります。

Lakehouse ランタイムカタログと Spanner の動作の例を以下に示します。この例では、マンハッタンのタクシー運行に関する分析データ（Apache Iceberg）と、タクシーのゾーンに関する運用データ（Spanner）を組み合わせて、最も混雑している交通経路を特定しています。さらに、会話型分析エージェントを使ってこの同じデータにアクセスし、二次的な分析情報を取得しています。

マンハッタンで最も混雑している交通ルートを調べる

ボーダーレスな Lakehouse にモダナイズ

Google Cloud の Lakehouse にモダナイズすることによって、分析エンジンやエージェント間のデータサイロを最小限に抑える、マルチエンジンのガバナンスを統合する、信頼できるコンテキストをエージェントに提供する、運用コストを大幅に削減する、といったメリットが得られます。Spanner ベースの Lakehouse ランタイムカタログを活用し、最新のクラウド環境をエージェント規模で運用する基盤を整えましょう。詳細および無料トライアルについては、

Lakehouse のウェブページをご覧ください。Spanner の詳細についてはこちらをご覧ください。

- プロダクトマネージャー、Vinod Ramachandran

- ソフトウェアエンジニアリングマネージャー Mina Mikhail

AlloyDB: ハイブリッド検索のための統合データベースエンジン

Wed, 14 Oct 2026 02:30:00 +0000

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

最新の AI アプリケーションや RAG アプリケーションで高い検索関連性を実現するには、少なくとも 2 つの手法を組み合わせる必要があります。それは、セマンティックなコンテキストを把握するためのベクトル検索と、キーワードの精度を高めるための全文検索（FTS）です。AlloyDB for PostgreSQL はこれら両方の機能に対応していますが、従来、これらの機能を管理して最高のパフォーマンスを確保するには、より多くの手作業を伴う運用アプローチが必要でした。

難しいのは、検索を実行することではなく、その検索結果を統合することです。ベクトルクエリ（距離スコア）と FTS クエリ（関連性スコア）の結果を統合するには、複雑な SQL クエリや、アプリケーションレイヤ側でのカスタムコードの実装が必要です。そのため多くの場合、結果の統合、スコアの正規化、再ランキングのための別システムを維持管理する手間が発生します。

この記事では、AlloyDB AI のハイブリッド検索がこの複雑さを解消する仕組みを詳しくご紹介します。最近のアップデートによって実現した、以下の機能を順に見ていきます。

ハイブリッド検索の簡素化: 複雑な SQL クエリや複数ステップのアプリケーションワークフローを、Reciprocal Rank Fusion（RRF）を活用した単一の高性能 SQL 関数に統合します。
FTS のパフォーマンス最適化: 新しい RUM 拡張機能を使用して、単語の位置をインデックスに直接保存することで、低レイテンシの関連性ランキングと効率的なフレーズマッチを実現します。
業界標準のランキングの活用: ネイティブにサポートされる新しい BM25 インデックスを利用して、キーワードベースの優れたスコアリングをすぐに利用できます。
検索の汎用性の拡張: 新しい外部検索用の外部データラッパー（FDW）を使用して、AlloyDB 環境を離れることなく、Elasticsearch、OpenSearch、Solr などの特化型の外部クラスタに対してクエリを実行できます。

複数ステップのワークフローの問題

AlloyDB AI のネイティブソリューションが登場する前は、堅牢なハイブリッド検索の実現は非常に骨の折れる作業でした。特に、標準 SQL を使用してこのロジックをデータベース内で完結させようとするデベロッパーにとっては困難な課題でした。そうしたアプローチでは複数のステップからなるオーケストレーションが必要となりますが、2 つのソースを管理、維持するだけでも困難なうえ、ソースが追加されるとスケーリングが事実上不可能になります。具体的には、以下のような手順が必要でした。

ベクトル検索を実行する: ベクトル列またはベクトルインデックス（AlloyDB の場合は ScaNN インデックス）を使用してクエリを実行し、Top-K の検索結果を見つけてベクトルスコアを生成します。
FTS クエリを実行する: 汎用転置インデックス（GIN）を使用して Top-K の結果を検索するなどして、FTS クエリを実行します。
スコアを正規化する（脆弱なステップ）: 複雑な SQL ロジックやカスタムアプリケーションコードを記述して、両方の結果セットを共通のスケールにマッピングします。このロジックは、データの分布が変化すると破綻する恐れがあります。
クロスサービス結合と再ランキングを実行する: ベクトル検索に使用するシステムとは別のシステムで FTS 検索を行う場合は、アプリケーションメモリを使用してドキュメント ID に対し複雑な FULL OUTER JOIN を実行し、正規化されたスコアの加重合計を適用して、最後に結合された結果を並べ替えます。

このような分散型のアプローチは、スコアロジックの脆弱化、レイテンシの増加、運用負荷の上昇を招き、検索品質の維持作業が属人化してアプリケーション開発者に大きな負担がかかり続ける原因となっていました。

AlloyDB でハイブリッド検索アーキテクチャを簡素化

これを簡素化する鍵は、RRF を採用することです。RRF は本質的にランクベースであるため、スコア正規化という脆弱なステップをスマートに回避できます。RRF は次の 2 つの要素で構成されています。

1. 信頼できる唯一の情報源

複数のステップからなるフェッチと結合の処理を行う代わりに、1 つの SQL 関数を呼び出して、検索コンポーネントを宣言型の JSON 配列として渡します。

SQL

code_block: <ListValue: [StructValue([('code', 'SELECT id, score \r\nFROM ai.hybrid_search(\r\n search_inputs => ARRAY[\r\n -- Vector Component (Semantic) with dynamic embedding generation from natural language\r\n $json${\r\n "data_type": "vector",\r\n "limit": 10,\r\n "table_name": "documents",\r\n "key_column": "doc_id",\r\n "vec_column": "embedding",\r\n "distance_operator": "<=>",\r\n "query_vector": "ai.embedding(\'text-embedding-005\', \'alloydb search\')::vector"\r\n }$json$::jsonb,\r\n \r\n -- Text Component (Keyword)\r\n $json${\r\n "data_type": "text",\r\n "limit": 10,\r\n "table_name": "documents",\r\n "key_column": "doc_id",\r\n "text_column": "content",\r\n "query_text_input": "alloydb search"\r\n }$json$::jsonb\r\n ]\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf92906410>)])]>

（注: 統合された ai.hybrid_search API は、2 つのコンポーネントだけに限定されるものではありません。また、新しい FDW を介して外部検索ソースをネイティブにサポートします。）

2. データベースネイティブのオーケストレーション

hybrid_search() 関数は、ワークフロー全体を単一のクエリプランで実行するため、オーバーヘッドを最小限に抑えながらトランザクションの整合性を確保することができます。この関数は、以下の処理を行います。

動的な CTE 生成: この関数は動的 SQL を構築して、各コンポーネントの共通テーブル式（CTE）を作成します。各 CTE は、結果の順位（ROW_NUMBER()）の計算を担います。
カーネルレベルでの融合: ランキングされたすべてのコンポーネントの結果が、ドキュメント ID に基づく FULL OUTER JOIN を使用して直ちに結合されます。
最終的な RRF スコア: 結合されたランクから、RRF の数式に基づいて最終的な統合スコアが算出されます。

このアプローチを採用することで、脆弱なスコア計算処理や、アプリケーション側での結合が不要になります。現在のランキングアルゴリズムは Reciprocal Rank Fusion（RRF）ですが、追加の結合オプションとランキングオプションを今後導入していく予定です。

結果: パフォーマンスと運用の簡素化

複雑な外部ワークフローからネイティブ SQL 関数への移行は、即座に目に見えるメリットをもたらします。

指標	複数ステップのアプリケーションワークフロー（手動 SQL によるシミュレーション）	AlloyDB AI ネイティブの hybrid_search() UDF
コードの複雑さ	複雑なスコア正規化関数、サービス呼び出し、アプリケーション結合。	外部ロジック不要。宣言型の SQL 呼び出し 1 回のみ。
維持管理	正規化数式の継続的な調整。	チューニング不要。RRF はランクベースで、分布に依存しない。

FTS のパフォーマンスを向上: RUM 拡張機能

AlloyDB AI の hybrid_search() 関数は、高パフォーマンスのベクトル検索と FTS を組み合わせることで、網羅的で関連性の高い検索結果を返すように設計されています。AlloyDB のネイティブ FTS 機能は、強力である一方、テキストコンポーネントに標準の PostgreSQL GIN インデックスを使用しているため、高度なオペレーションではボトルネックになる可能性があります。

GIN インデックスの課題は、単語の出現位置の情報が保存されないことです。この制限があるため、以下のような処理を行う際はコストのかかるテーブルスキャンを実行して再分析せざるを得なくなります。

関連性ランキング: 単語の近接性と頻度に基づいて検索結果のスコアを計算する。
フレーズ検索: 正確な語順を見つける。出現位置の情報が必要。

FTS のレイテンシを低減する RUM 拡張機能のご紹介

RUM 拡張機能は、GIN をベースにした強力なインデックスアクセス手法で、これらのパフォーマンスの課題を直接解決します。

RUM の主な利点: GIN インデックス（単語 -> [docID] をマッピング）とは異なり、RUM インデックスは各単語の出現位置の情報をインデックス内に直接保存します（例: 単語 -> [(docID1, [pos])], ...）。
パフォーマンス上のメリット: これにより、RUM はランキングやフレーズ照合などの複雑なオペレーションを主にインデックス自体の中で実行できるため、コストのかかるヒープスキャンを回避できます。RUM を使用することで、関連性ランキングが大幅に高速化され、フレーズ検索や近接検索も効率的に行えるようになります。
ハイブリッド検索に最適: RUM は、ハイブリッド検索フレームワークにおいてベクトル検索（ScaNN など）を補完する極めて重要な要素です。GIN はレイテンシが発生するリスクがあるため、リアルタイムのハイブリッド処理にはあまり適していません。

RUM 拡張機能は、ランキング重視のアプリケーションや同時実行性の高い検索アプリケーションに最適です。単語の出現位置をインデックスに直接保存することで、ランキング処理中にテーブルページを再スキャンする必要がなくなり、並べ替え済みの結果を高速に返すことができます。ただし、インデックスの構築が遅くなり、ディスク使用量が増えるというトレードオフもあります。書き込み速度やストレージ密度よりも、高速なクエリと正確なランキングが優先されるワークロードであれば、RUM は投資する価値が十分にあります。

測定可能な成果とインテグレーション

RUM を採用すると、AlloyDB の FTS のパフォーマンスが直接的に向上します。単体の FTS クエリはもちろん、FTS クエリを含むハイブリッド検索のパフォーマンスも向上します。以下は、さまざまな BEIR データセットにおける、GIN と比較した RUM のパフォーマンス向上率を示した統計データです。

（パフォーマンスは、BEIR Natural Questions ベンチマークを使用したテストに基づきます）。

RUM は、検索とランキングに特化した <=> 距離演算子と統合されており、ハイブリッド検索の SQL 呼び出しで使用できるため、双方の長所を活かすことができます。次の Codelab では、ハイブリッド検索 UDF で RUM インデックスを構成して使用する方法を説明します。

BM25 インデックスの導入: 最新のランキング標準

Google はこのたび、CloudSQL と AlloyDB に BM25 インデックスをプレビュー版として導入し、pg_textsearch 拡張機能を通じて業界標準の関連性ランキングを利用できるようにしました。BM25 は、用語頻度飽和と文書長正規化を考慮した TF-IDF を使用して、キーワードベースの検索クエリの精度と品質を大幅に向上させます。AlloyDB AI 内のネイティブ BM25 インデックスを活用することで、導入してすぐに高いランキング精度を達成できます。外部の検索エンジンや複雑なカスタムスコアリングロジックの実装が不要になり、完全一致の用語や重要なキーワードに高いスコアが自動的に割り当てられます。

code_block: <ListValue: [StructValue([('code', "-- Install pg_textsearch extension\r\nCREATE EXTENSION pg_textsearch;\r\n\r\n-- Create the native BM25 index on the content column\r\nCREATE INDEX idx_docs_bm25 \r\nON cymbal_products \r\nUSING bm25 (product_description) \r\nWITH (text_config='english');\r\n\r\n-- Full text search query\r\nSELECT product_name, product_description <@> 'cherry tree' AS bm25_score \r\nFROM cymbal_products\r\nORDER BY bm25_score \r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf922feed0>)])]>

外部検索: 外部データラッパーで汎用性を拡大

検索機能をさらに拡張するため、外部検索用の外部データラッパー（FDW）も AlloyDB AI に導入しました。これにより、Elasticsearch、OpenSearch、Solr をはじめとする特化型の外部クラスタに対する全文検索が可能になり、アーキテクチャ面で以下のような重要なメリットを得られます。

最適化された検索: AlloyDB 環境を離れることなく、専用の検索バックエンドからランキングアルゴリズムと豊富な機能セットを活用できます。
統合された SQL インターフェース: 高度な FTS クエリの表現力を維持したまま、標準の PostgreSQL SQL を使用して外部データを操作し、結合を実行して、結果を統合できます。
優れたポータビリティ: 既存の検索インフラストラクチャをそのまま維持しながら、AlloyDB AI が提供するシンプルなハイブリッドアーキテクチャのメリットを享受できます。

以下の Codelab は、Elasticsearch と Solr のインテグレーションを使用したハイブリッド検索について説明する、エンドツーエンドのコードガイドです。

AI を活用した検索のための統合アーキテクチャ

最先端の検索における真の課題は、技術的そのものではなく、アーキテクチャの簡素化と長期にわたる運用の安定性を両立させることにあります。AlloyDB AI は、以下の 3 つのコアイノベーションを基盤とした統合プラットフォームによってこの問題を解決します。

ハイブリッド検索の簡素化: RRF を活用した AlloyDB AI のハイブリッド検索機能は、脆弱な複数ステップのアプリケーションワークフローを、単一の高性能な SQL 呼び出しに変換します。このネイティブ実装により、複雑なスコア正規化やアプリケーション側での結合が不要になります。その結果、運用コストとエンジニアリングコストを大幅に削減しながら、一貫して正確で高速かつ関連性の高いハイブリッド検索結果を提供できます。
FTS パフォーマンスの最適化: ハイブリッド検索における FTS コンポーネントが多様なアプリケーション要件を満たせるよう、AlloyDB AI はさまざまな全文検索オプションを提供しています。RUM 拡張機能は、出現位置データをインデックスに直接保存することで、関連性ランキングの高速化と効率的なフレーズ検索を可能にし、低レイテンシなパフォーマンスを実現します。これは、高速なクエリが求められる場合に重要です。一方、BM25 インデックスは業界標準の関連性ランキングを提供するため、キーワードスコアリングの精度を優先する場合に推奨される選択肢です。検索レイテンシとランキング精度のどちらを重視するかによって使い分けることができます。
外部検索による汎用性の向上: FDW を介した外部検索を追加することで、AlloyDB は Elasticsearch などの特化型の検索バックエンドとも連携できるようになります。これにより、使い慣れた PostgreSQL インターフェースはそのままに、特化型検索クラスタの大規模な処理能力と高度な検索機能を活用できます。これらの外部結果をハイブリッド検索フレームワークに直接統合することで、AlloyDB AI は、非常に大規模なテキストリポジトリとベクトルベースのセマンティック分析情報を組み合わせることができます。

AlloyDB AI は、スコアリング、結合、再ランキングという複雑な処理をデータベースカーネル内に集約し、FTS を実現する 2 通りの方法（最適化された低レイテンシの内部 FTS に RUM を活用する、または特化型のスケーラブルなバックエンドに外部検索を活用する）を提供することで、堅牢で自己完結型の検索基盤を実現します。この 2 つの方法の共存が、ハイブリッド検索の実現を根本から支え、ワークロード、データ量、既存のインフラストラクチャに基づいて最適な方法を選択できる柔軟性をもたらします。これにより、検索アーキテクチャの優れたパフォーマンスとメンテナンス性の高さを信頼して、インテリジェントなアプリケーション機能の開発に集中できるようになります。

デモ動画のご紹介

AlloyDB が究極のハイブリッド検索エンジンと呼ばれる理由を、ぜひ動画でご確認ください。

AlloyDB での BM25 のサポートについての詳細をご覧ください。

ご利用にあたって

AI ワークロードのスピードと費用対効果を向上させる準備はできていますか？

AlloyDB を初めてご利用の場合: 30 日間の無料トライアルで AlloyDB をお試しください。
ハイブリッド検索を使ってみる: テキスト検索インデックスを設定し、ベクトル検索インデックスを選択します。インデックスを作成すると、さまざまなハイブリッド検索クエリ実行するためのサンプルを確認できます。
外部検索: AlloyDB に外部データラッパーと外部テーブルを作成し、Elasticsearch、Solr、OpenSearch から外部データをクエリします。

- データベース担当シニアプロダクトマネージャー Kumar Ramamurthy

- データベース担当ソフトウェアエンジニア Ricky Zhou

AlloyDB がエージェント向け PostgreSQL を提供: ワークロードを完全に分離し、エージェント規模でリアルタイムデータを処理

Tue, 06 Oct 2026 18:10:00 +0000

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

ミッションクリティカルな運用データベースは企業にとってなくてはならないものであり、パフォーマンスの低下は許されません。しかし従来のアーキテクチャでは、わずか数個のエージェントが高密度の推論ループを実行しただけで、予測不可能なクエリのバーストが発生して簡単に過負荷状態に陥ります。

このたび、AlloyDB でエージェント向け PostgreSQL（プレビュー版）の提供を開始したことをお知らせいたします。これにより、ミッションクリティカルなシステムのパフォーマンスを損なうことなくリアルタイムのデータアクセスを行うことが可能になります。AlloyDB は、サンドボックス化されたデータベースインスタンスを数秒でプロビジョニングしてスケールすることでエージェントによる突発的なクエリの急増に対応し、ワークロードの完全な分離を可能にします。インスタンスはエージェントが終了すると自動的にスピンダウンするため、数個でも数百万個でも、エージェントをあらゆる規模で費用対効果よく実行できます。この発表による変更点は以下のとおりです。

AlloyDB に、秒単位で同期された本番環境の最新データに読み取り専用でアクセスできる数千のサーバーレスデータベースインスタンスへと PostgreSQL をスケールさせるように設計されたエージェント向けデータベースアーキテクチャが搭載されます。これらのインスタンスは常時、本番環境ワークロードがアクセスするプライマリ、スタンバイ、リードレプリカのインスタンスから完全に分離されています。
これらの各インスタンスは、Google が提供するエクサバイト規模の分散ストレージシステムである Colossus の統合ストレージレイヤを基盤とするデータベース内のリアルタイムデータにアクセスします。これにより、エージェントはミリ秒未満の I/O とテラビット/秒の集約スキャンスループットを実現し、秒間 300 万以上のクエリにも対応できます。
これらのインスタンスは完全な AlloyDB PostgreSQL エンジンを備え、すべてのインデックス、SQL の全機能、包括的なベクトル検索、全文検索、空間検索へのアクセスを提供します。さらに、複雑な ETL パイプラインを構築しなくても、エージェントは BigQuery と Spark を活用してレイクハウス分析を実行できます。
これらのインスタンスはエージェントがタスクを完了するとすぐにゼロへとスケールダウンされるため、料金はアクティブな推論ループに対してのみ発生し、クラウド費用を削減できます。

Google は、この AlloyDB for PostgreSQL により高度なベクトル演算、ML 推論、基盤モデルのインテグレーションを 100% PostgreSQL 互換のエンジンに直接組み込み、エージェント向けエンタープライズリレーショナルデータベースの分野における先駆けとなりました。AlloyDB for PostgreSQL は Google Cloud のセキュリティ機能と緊密に統合されており、静的パスワードに代わる IAM 認証の使用、VPC Service Controls を介したトラフィック分離、顧客管理の暗号化と監査の提供によりデータを保護します。この機能とエージェントアーキテクチャによるスケーラビリティを組み合わせて提供する AlloyDB は、エンタープライズグレードの優れたエージェント PostgreSQL サービスとなっています。

プレビュー版をご利用になるには、こちらからお申し込みください。

重要である理由

エージェントの時代となった今、企業による AI の使用方法は単一のコパイロットエージェントとのやり取りから、数百万のエージェントが同時に連携するネットワークへと急速に移行しています。これらのエージェントが一斉にクエリを実行してデータベースを操作すると、突発的なトラフィックの急増によってコアデータベースが過負荷に陥り、ビジネスを運営する基幹システムと競合してしまう可能性があります。

エージェントがワークフローを効率的に実行するためには、B ツリー、ベクトル、テキスト、空間の各インデックスを活用して、高度な分析とリアルタイムの本番データに対する低遅延アクセスの両方を実現する必要があります。新興のアーキテクチャはオブジェクトストレージの上に配置されたページキャッシュレイヤを使用しますが、これにはスケーリングと費用に関する課題があり、本番環境システムの安定性が損なわれる可能性があります。

加えて、分析のために本番環境のデータを解放すると運用アクセスにパフォーマンスのボトルネックが生じ、エージェントが本番環境にリリースされた瞬間からミッションクリティカルなデータベースがリスクにさらされるという、難しいトレードオフも発生します。これらは、データベースストレージに従来のオブジェクトストアを使用して問題を解決しようとするアプローチです。分析アクセスが可能になるので一部のエージェントはこれを役立てることができますが、基盤となるデータベースの処理速度が本番環境のワークロードに対して遅すぎ、I/O レイテンシが最大で 10 倍悪化します。ページキャッシュレイヤがあっても、一時しのぎ程度にしかなりません。キャッシュ自体の速度が依然として十分に速くないうえに、エージェントワークロードによって簡単に飽和してしまうスケーラビリティのボトルネックを抱えることになります。

アクティブなマルチエージェントシステムが高密度な推論サイクルを実行すると、高度に並列化された予測不可能なクエリのバーストが発生してこれらのキャッシュレイヤを圧倒し、ミッションクリティカルな本番環境システムが、エージェント起因のサービス停止に対して無防備な状態になります。その結果、このアーキテクチャでは運用ユースケースの全領域が実行不可能となり、企業はライブのエンタープライズデータが持つ、AI による変革の力をビジネスに活用する機会を失うことになります。

AlloyDB 独自の PostgreSQL エージェントアーキテクチャ

Google はこれとは異なるアプローチを採用しました。AlloyDB は、AI 時代に特化して設計されたエージェント向けデータベースアーキテクチャを提供し、4 つの主要な差別化機能を備えています。

人工的なボトルネックのない、1 ミリ秒未満の I/O レイテンシ: 業界をリードする AlloyDB のトランザクションおよびクエリ処理性能と、Google の地球規模の Colossus ストレージインフラストラクチャに支えられた低レイテンシのオブジェクトストレージが組み合わさったこのアーキテクチャは、エージェント向けの大規模な共有ストレージプレーンを提供します。ミリ秒未満の I/O と 1 秒あたり 1 テラビットを超える集計スキャン帯域幅を実現しているため、エージェントが最新の運用データに対して直接、集中的に読み取りクエリとベクトル検索を実行しても問題なく処理できます。
本番環境のワークロードから完全に分離しつつ、需要に合わせてスケーリング: AlloyDB は、最新の本番環境データに対してサンドボックス化されたデータベースインスタンスを数秒で動的にプロビジョニングすることでスケールします。エージェント同士が運用リソースを奪い合う従来のアーキテクチャとは異なり、エージェントデータベースコンピューティングはプライマリデータベースクラスタから完全に分離されています。そのため、エージェントが高密度で予測不可能な推論ループを実行しても本番環境のパフォーマンスが低下することはありません。これらの堅牢な安全ガードレールと、エンタープライズグレードのガバナンス、きめ細かいアクセス制御が組み合わさっているため、アクティブなエージェントループで分析クエリ、ベクトルクエリ、運用データのポイントルックアップをシームレスに組み合わせ、本番環境データに対して PostgreSQL の性能を制限なく最大限に活用することができます。
従量課金制: エージェントのアクティビティは一般的に、短時間のうちに大量のクエリが同時送信され、それが終わると非アクティブな期間が続くという特徴があります。このような急増に備えて専用のリードレプリカをプロビジョニングした場合、高価なインフラストラクチャを 24 時間体制で維持する必要があります。費用対効果の高い方法で大規模なエージェントグループをサポートし、プロビジョニングしたシステムがアイドル状態のままでコンピューティングオーバーヘッドを発生させることを避けられるよう、エージェント AlloyDB インスタンスは迅速にスケールして秒間数百万のクエリに対応できます。また、柔軟な従量課金制の料金モデルによって自動的にゼロへとスケールさせることができます。
ETL 不要のネイティブレイクハウス統合: 本番環境データはすべて、Google Cloud のボーダーレスレイクハウスとネイティブに統合されます。そのため、エージェントは BigQuery と Lightning Engine for Apache Spark に対して連携クエリを実行し、大規模なレイクハウスデータセットと、AlloyDB の秒単位で更新される最新のトランザクションデータを結合できます。これにより、壊れやすいバッチ ETL パイプラインを構築して維持する必要がなくなり、自律型エージェントは最新の運用状態と、レイクハウスに格納されている過去のコンテキストデータの両方に即座にアクセスできます。

「サプライチェーンの自律性が高まるにつれ、当社のプラットフォームでは、数千もの施設にわたる複雑な物流ワークフローを調整するリアルタイムのトランザクションインテリジェンスが欠かせなくなっています。AlloyDB の新しいエージェント向け PostgreSQL アーキテクチャは、当社にとって大きな転機となりました。現在では、コアのトランザクション処理には一切影響を及ぼすことなく、同時に連携して動作するエージェントのネットワークをデプロイし、在庫データや注文データを 1 秒未満の鮮度で分析できるようになっています。このアーキテクチャにより、次世代のエンタープライズサプライチェーン AI を支えるために必要な分離、スピード、費用対効果を実現できました。」 - Manhattan Associates、エグゼクティブバイスプレジデント兼最高技術責任者、Sanjeev Siotia 氏

提供状況

AlloyDB の PostgreSQL for Agents は現在、プレビュー版としてご利用いただけます。

詳細については、ドキュメントページをご覧ください。ご利用を開始するには、こちらからお申し込みください。

エージェントの時代における妥協のない新しいデータベースアーキテクチャ

Tue, 06 Oct 2026 18:00:00 +0000

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

データベースエンジニアはキャリア全体を通して、ある 1 つの課題に取り組んできました。それは、データを保持する記録システムの信頼性を損なうことなく、OLTP ワークロードをどのようにスケールするかということです。

Exadata は、データベース下部のスケールアウトストレージ階層にクエリをオフロードすることで、ネットワークのボトルネックを排除し、この課題を解決しました。Azure SQL Hyperscale は、共有ブロックサーバーを使用して、数十のリードレプリカにスケールアウトしました。Aurora は、ログの適用処理を分散ストレージノードにオフロードし、複数の PostgreSQL ノードにわたる読み取り処理のスケーリングを実現しました。一方、新しいアーキテクチャでは、従来のオブジェクトストレージにデータを永続化し、その手前にプロビジョニングされたキャッシュ階層を配置しています。これにより、ホットデータのレイテンシは抑制できるものの、キャッシュミスが発生するたびに長いレイテンシが発生します。

これらのアーキテクチャはどれも、スケール、レイテンシ、分離という 3 つの特性のうち、少なくとも 1 つ、場合によっては 2 つの制約を本質的に抱えています。たとえば、共有ブロックサーバー上に構築されたアーキテクチャでは、ブロックサーバーで I/O が必然的にボトルネックになるため、スケーラビリティが損なわれます。また、レプリケーショントラフィックが急増するたびに本番環境のワークロードがスロットリングされるため、分離も損なわれます。

こうしたトレードオフの中には、設計当初は実際に妥当だったものもあり、40 年間にわたってエンタープライズデータベースワークロードの要件を満たしてきました。しかし、エージェントの時代においては、このような妥協はもはや通用しません。エージェントワークロードは動的に生成されるため、事前に検証することはできません。そのため、ミッションクリティカルなシステムから分離することが、ビジネスの継続性を確保するうえで不可欠です。エージェントワークロードは、データベースエンジンとそのすべてのインデックスの能力を最大限に活用して初めて実現できる低レイテンシを必要とします。同時に、単一のデータベースでは前例のない、まったく新しいレベルの弾力的なスケーリングも求められます。具体的には、単一のデータベースに対して数秒以内に 1,000 個のコンピューティングノードを要求し、1 分以内に処理を終了するような、エージェントのバーストに対応できるスケーリングです。

真のエージェント型データベースアーキテクチャに必要な 3 つの原則

エージェントの時代には、3 つの基本原則によって定義される新しいエージェント型データベースアーキテクチャが必要であると Google は考えています。エージェント型データベースアーキテクチャがその真価を発揮するには、これら 3 つの条件すべてを満たすことが不可欠です。

原則: 分離 - 設計レベルでの分離でありながら、リアルタイムなデータアクセスを実現。エージェントは、プライマリクラスタとデータベースコンポーネントを共有しないデータパスを介して、1 秒未満の更新頻度で本番環境のライブデータを読み取る必要があります。リアルタイムとは、古いコピーやブランチではなく、秒単位で更新される最新のデータを意味します。これは割り当てではなく、物理的な分離です。リソースを共有するということは、運命を共にすることを意味するからです。その境界線はストレージレイヤまで達しているため、設計レベルでリソースの競合を排除しています。
原則: レイテンシ - 1 ミリ秒未満のベースライン I/O。運用ワークロードでは 1 ミリ秒未満のブロック I/O が求められますが、エージェントでもその基準は変わりません。コンピューティングノードは DRAM とローカル SSD を利用して高速化を実現していますが、キャッシュミスが発生してリモートストレージへアクセスする場合であっても、アプリケーションかエージェントかを問わず、1 ミリ秒未満で処理を完了できるストレージ設計が求められます。パフォーマンスが桁違いに低下するアーキテクチャは、エージェントにとって根本的に使い物になりません。
原則: スケール - エージェントスケールのコンピューティングと I/O。エージェントのスケールは、瞬発的かつ一時的でありながら、極めて大規模という特徴を同時に持ちます。データベースコンピューティングノードは、数秒でのスピンアップ、数千台へのスケール、短時間でのバースト実行、エージェントの処理終了後の自動的なゼロへのスピンダウンを行う必要があります。本番環境に一切影響を与えずに、データベースのコンピューティングと I/O を数千ノード規模へ即座にスケールさせることは、従来のデータベースの常識では不可能なことでした。エージェントの動的な性質を考えると、コンピューティング、ストレージ I/O、その間にあるキャッシュ階層にいたるまで、スタック全体における事前プロビジョニングは現実的ではありません。

重要なのは、エージェントアーキテクチャは、これら 3 つの原則をすべて同時に満たす必要があるということです。こうしたアーキテクチャにより、エージェントは本番環境の安定性を損なうことなく、ライブ運用データ、つまり企業の実体に直接アクセスして処理を行うことができます。その結果、以下のような劇的な変化がもたらされます。

連動障害がない: ビジネスを運営するエンジンと、その上で推論を行うエージェントフリートが完全に分離されているため、エージェントが本番環境に影響を与える経路が排除されます。
容量予測が不要: 真の弾力性により、予測不可能なエージェントの急増に備えて事前プロビジョニングを行う煩わしさが解消されます。
セマンティクスの妥協がない: エージェントに対して制限される機能はありません。すべての推論ステップにおいて、リレーショナル SQL、ハイブリッド検索（ベクトル、全文、空間）、そしてインデックスの機能を最大限に活用できます。

AlloyDB のエージェントアーキテクチャ

AlloyDB の新しいエージェント型データベースアーキテクチャは、これら 3 つの原則をすべて満たす初のシステムです。Google は、ストレージ、ネットワーク、コンピューティング、データベースにわたって、これをゼロから構築し、以下を実現しました。

分離によって設計レベルでの障害の連鎖を回避: トランザクション本番環境クラスタは、エージェントワークロードから完全に分離され、事前プロビジョニングされた専用インフラストラクチャ上で実行されます。エージェントは、Model Context Protocol（MCP）を介して、本番環境とは別の専用の Colossus ストレージセグメントから直接読み取る、マイクロ VM ベースの AlloyDB ノードの独立したエフェメラルプールに接続します。
予測可能な 1 ミリ秒未満のストレージ I/O: すべてのストレージ読み取りは、Google の Colossus ストレージシステムによって直接処理され、1 ミリ秒未満のベースラインレイテンシを継承します。これにより、コールドキャッシュミスによるパフォーマンスの急激な低下がなくなります。
ゼロから数千ノードへの真のコンピューティングスケーリング: エージェントプールは、エージェントアクティビティのバーストに対応して、ゼロから数千のノードへと迅速にスケールアップし、タスクが完了した瞬間にゼロにスケールダウンします。

エージェントは、1 秒未満の更新頻度で本番環境データをクエリし、PostgreSQL エンジンのすべての機能（ポイント検索、インデックストラバーサル、ベクトル、全文検索、空間検索、カラム型スキャン、レイクハウス全体の連携クエリ）を駆使して、推論ループを強化できます。

エージェント向け AlloyDB PostgreSQL のプレビューに参加して、データの規模を問わず本番環境データ上でエージェントを実行しましょう。その全機能について詳しくは、関連するお知らせのブログ記事をご覧ください。

既存のアーキテクチャが 3 つの原則をすべて満たせない理由

従来型および新興の運用データベースは、3 つのアーキテクチャパラダイムのいずれかを採用することでスケーリングを図っています。自律型 AI エージェントの要件に照らして評価すると、どのパラダイムにも構造上の根本的な限界があり、3 つの原則を同時に満たすことは不可能です。

独立したレプリカ（シェアードナッシングストレージ）

従来のリレーショナルアーキテクチャでは、プライマリインスタンスから専用のレプリカデータベースにレプリケーションログをストリーミングすることで読み取りをスケールします。各レプリカデータベースは、それぞれ専用のローカルストレージまたはアタッチされたブロックストレージを備えています。これは「原則: 分離」を満たしています。つまりレプリカはプライマリクラスタと物理リソースを共有せず、継続的なログレプリケーションにより、準リアルタイムの最新性が維持されます。また、「原則: レイテンシ」も満たしています。専用のローカルストレージにより、予測可能な 1 ミリ秒未満の読み取りレイテンシが保証されます。しかし、「原則: スケーリング」は満たしていません。スケーリングには、新しいレプリカをプロビジョニングし、数百ギガバイトまたはテラバイトのストレージをリハイドレーションする必要があります。これらすべての処理には数時間かかります。これでは、秒単位で発生するエージェントの爆発的な推論バーストには対応できません。さらに、静的にプロビジョニングされたコンピューティングとストレージは、エージェントの実行が完了した後も、アイドル状態でコストが発生し続けます。

分離された共有ストレージサーバー

2 つ目のアプローチは、ステートレスコンピューティングノードを、永続性とレプリケーションを管理し、ブロック書き込みをオフロードする可能性のあるカスタムストレージサーバーの共有マルチテナント階層から切り離すことです。このアプローチは、「原則: レイテンシ」を満たします。最適化されたストレージサーバーへの読み取りアクセスは、常に安定した低いレイテンシで処理されます。しかし、「原則: 分離」は満たしていません。すべてのレプリカがプライマリと同じサーバーから読み取るため、エージェント I/O が本番環境 I/O と直接競合し、障害の連鎖のリスクが生じるためです。また、「原則: スケール」も満たしていません。データがコピーされないため、ステートレスコンピューティングレプリカは迅速にスピンアップするものの、ストレージ I/O の合計帯域幅が、事前にプロビジョニングされたストレージ階層の容量に制限されるためです。基盤となる I/O 容量をスケールせずにコンピューティングノードを追加しても、ストレージの処理能力が飽和し、スロットリングを加速させるだけです。

共有ブロックサーバーを使用したオブジェクトストレージ

3 つ目の新しいアプローチは、汎用オブジェクトストレージでデータの耐久性を確保し、ブロックサーバーの共有階層からブロック読み取りを行うというものです。オブジェクトストレージからのランダム読み取りには数十ミリ秒かかります。これは従来のデータベースストレージより桁違いに遅く、少なくとも 25 年前のエンタープライズ向けディスクアレイと比べてもさらに遅いレベルです。そのため、ブロックサーバーにホットデータを保持させることで、低レイテンシでのデータ提供を実現しています。このアプローチは、「原則: レイテンシ」を満たしますが、1 つ注意点があります。それは、ブロックサーバーでキャッシュミスが起きると、許容できないほど高いレイテンシでオブジェクトストレージまでフォールバックが発生してしまう点です。一方で、「原則: 分離」を満たしていません。レプリカは本番環境とブロックサーバーを共有しているためです。エージェント I/O と本番環境 I/O は同じ処理容量を使用します。そのため、その容量が枯渇したりスロットリングされたりすると、エージェントだけでなく本番環境にも影響が及びます。また、共有ストレージサーバーと同じ理由で、「原則: スケール」も満たしていません。レプリカはすぐに起動しますが、ブロックサーバーがバーストに合わせて I/O をスケールしないためです。

このファミリーの一部のアーキテクチャでは、Apache Spark などの分析エンジンがデータベースエンジンをバイパスして、基盤となるオブジェクトストレージを直接読み取ることもできます。分析ワークロードの場合、これは価値があり、十分に現実的なアプローチです。しかし、エージェントには低レイテンシの検索が不可欠です。インデックス、ポイント検索、ベクトル検索を排除すると、ブルートフォーステーブルスキャンが余儀なく行われ、レイテンシが急増し、エージェントが検索と推論のループを実行できなくなります。

既存アーキテクチャの評価

Google は、共有ブロックサーバーを備えたオブジェクトストレージアーキテクチャを使用する市販のサービスを対象に、スケーリングの限界と本番環境の分離の両方を検証する評価を行いました。利用可能な DRAM よりも大きなデータセットに対して、同時にインデックス検索を実行しました。1 つのリーダーインスタンスから始めて、最大 8 つのリードレプリカを追加してワークロードをスケールしました。

物理リソースを共有するアーキテクチャでは、リードレプリカを追加してエージェントをスケールすると、レプリカとプライマリの両方のパフォーマンスが急速に低下します。以下のグラフに示すように、Google のテストでは、レプリカを追加してもスループットの増加は 2 倍未満にとどまりました。レプリカ 4 台でピークに達した後、共有ブロックサーバーの帯域幅が飽和状態になると、スループットは低下しました。

プライマリデータベースへの影響は即座に、かつ深刻な形で現れました。レプリカが追加されると、プライマリのスループットは 75% 以上も急落したのです。

つまり、従来型と新興型のどちらのアーキテクチャも、エージェントが求める規模に対応できないということです。本番環境システムの安定性を損なうことなくそれを実現することは、到底不可能です。

原則に基づく評価

* 部分的に対応: ホットデータはブロックサーバーから低レイテンシで提供されますが、ブロックサーバーでキャッシュミスが発生すると、オブジェクトストレージへのアクセスが生じて数十ミリ秒のレイテンシが発生します。

いずれの場合も、この課題は構造的なものであり、単にチューニングで解決できる問題ではありません。レプリケーションは、各レプリカに専用ストレージを割り当てることで分離を実現します。そのため、そのストレージへのデータ同期にかかる時間よりも短い時間でレプリカを追加することはできません。共有ストレージサーバーは、ストレージを共有することでコンピューティングを迅速に追加できますが、I/O を分離することもスケールすることもできません。オブジェクトストレージ上のブロックサーバーは、プロビジョニングされた階層でレイテンシを抑制できるものの、分離もバーストもできず、キャッシュミスが発生するたびにオブジェクトストレージへのアクセスが生じてしまいます。どのアプローチも、あるレイヤで問題を解決したとしても、別のレイヤでその代償を払うことになります。3 つの原則をすべて同時に満たすには、コンピューティング、ネットワーク、ストレージにわたるデータベースアーキテクチャを再考する必要があります。

AlloyDB をスタック全体でどのように構築したか

AlloyDB のエージェント型データベースアーキテクチャは、Google のデータ、AI、インフラストラクチャスタック（AI モデル、データベースエンジン、および分析エンジン、さらにはストレージ、ネットワーキング、コンピューティングインフラストラクチャ）全体にわたって垂直統合されています。

ストレージ: 基盤としての Colossus

永続レイヤでは、AlloyDB は Google のエクサバイト規模の分散ストレージシステムである Colossus を基盤としています。Colossus は、Google 検索、YouTube、Gmail、Google ドライブ、Spanner、Bigtable を支えています。1 つの Colossus クラスタは、エクサバイト規模のストレージと数万台のマシンにスケールします。Spanner では、Colossus 上に直接構築されたトランザクションデータベースが数千ノードまでスケールできることを実証しました。新しい AlloyDB アーキテクチャは、同じ基盤を新たな課題、すなわちエージェントに適用します。

Colossus には、AlloyDB がこれら 3 つの原則を満たすための、3 つの特性があります。

1 ミリ秒未満の直接 I/O: Colossus は、読み取りレイテンシを最小限に抑えるように設計されています。Colossus ストリームを開くデータベースノードは、データが物理的に存在する場所を記述したハンドルを受け取ります。承認とメタデータの解決は、ストリームの作成時に 1 回しか行われません。それ以降の読み取りはすべて、最適化されたネットワークプロトコルを介して、データを保持するディスクに対して直接行われます。その結果、データベースのすべてのデータで 1 ミリ秒未満のレイテンシが実現します。ウォームアップする中間層も、キャッシュミスを起こすような層もありません。
圧倒的なスループット: Colossus は、帯域幅をプロビジョニングする必要がなく、同時ホスト数に制限がないため、単一の AlloyDB データベースに対して最大 15 TB/秒の総スループットと 2,000 万の秒間クエリ数を実現します。Colossus のスケールから見れば、AlloyDB エージェントノードのフリートがもたらす負荷は、ストレージのサイズ調整が必要になるようなものではありません。それは、このストレージがすでに処理している負荷のごく一部にすぎないからです。
物理セグメントのパーティショニング: AlloyDB は、本番とは別の Colossus セグメントからエージェントにサービスを提供するため、エージェントの I/O が本番環境のデータパスと競合することはなく、意図的に本番環境のデータパスから分散されます。

コンピューティング、ネットワーク、ストレージのいずれのデータパスにおいても、エージェントがデータベースコンポーネントを本番環境と共有することはありません。

ネットワーク: Jupiter によるスケーラブルな帯域幅

コンピューティングとストレージは、Google の大容量データセンターネットワークである Jupiter によって結び付けられています。1 つの Jupiter ファブリックが 10 万台以上のサーバーを 13 ペタビット/秒の二分割帯域幅で接続します。これは、地球上のすべての人がビデオ通話を行うのに十分な帯域幅です。

Jupiter は、ネットワーキングファブリック全体で予測可能な低レイテンシと高い二分割帯域幅を提供します。そのため、エージェントノードをクラスタ内のどこにでも柔軟に配置でき、一元化されたストレージに常にアクセスできます。エージェントプールがゼロから数千ノード規模にスケールするにつれて、基盤となる相互接続の容量が、配置上のボトルネックを発生させることなく、増大するトラフィックを吸収します。

コンピューティング: 柔軟でサーバーレスな PostgreSQL と分析

コンピューティングレイヤでは、エージェントが MCP を介して AlloyDB のエージェントプールに接続します。エージェントプールを構成する AlloyDB エージェントノードは、データベースの秒単位の最新状態に、読み取り専用でアクセスできます。このレイヤは、以下の機能を提供します。

マイクロ VM 分離: 各エージェントノードは、軽量かつセキュアなマイクロ VM 内で実行される、完全に機能する AlloyDB for PostgreSQL データベースエンジンです。これらのインスタンスは、互いに完全に分離されており、専用のプライマリクラスタからも分離されています。
迅速なスピンアップとスケーリング: エージェントノードは、エージェントからのリクエストに応じてプロビジョニングされ、エージェントが処理を終了すると自動的に停止します。バーストが発生すると、AlloyDB は数千のエージェントノードを迅速にプロビジョニングし、数百万の同時エージェントにサービスを提供します。エージェントが処理を終了すると、それらを解放します。課金はエージェントノードのアクティビティの秒単位で行われるため、1,000 個のノードを数十秒間使用するバーストでは、ジョブが消費したリソースに対してのみ課金され、それ以上のコストは発生しません。

一方、本番環境クラスタは、専用インフラストラクチャ上に事前プロビジョニングされ、記録システムに合わせてサイジングされた、従来通りの状態のまま維持されます。エージェントノードは Colossus から直接データを読み取るため、1 秒未満の更新頻度で、一貫した本番環境のデータを参照できます。

エージェントプール以外にも、BigQuery と Spark は本番環境クラスタから同じように分離された Colossus から AlloyDB データを読み取ることができるため、エージェントは Lakehouse Federation を使用して、リアルタイムの運用データを大規模な Lakehouse データセットと結合できます。

AlloyDB の新しいエージェントデータベースアーキテクチャは、Google 規模のストレージ、ネットワーク、コンピューティングレイヤを基盤とすることで、際立った目標を達成しています。それは「データのみを共有し、それ以外は何一つ共有しない」という目標です。

AlloyDB のエージェント型データベースアーキテクチャの評価

Google は、利用可能な DRAM よりも大きなデータセットに対して同時インデックス検索を実行し、フルスタック全体におけるスケーラビリティを検証することで、AlloyDB の性能を評価しました。エージェントワークロードを、単一のエージェントノード（従来のリードレプリカではなく、エージェントプール内の独立したデータベースインスタンス）から開始し、単一のデータベース上で数千ノードまで動的にスケールしました。その際、エージェント全体の合計スループットと、本番環境への影響を測定しました。

このテストでは、エージェントノードを 1 つから 10 個に増やすと、スループットが 3,900 QPS から 4.1 万 QPS へとほぼ完全に比例して向上しました。さらに 2 桁上（100倍）の規模までスケールさせても、最大 1,000 ノードに達するまで、ほぼ完全に比例したパフォーマンスが得られました。Google は、以下を確認しました。

プライマリのパフォーマンス低下ゼロ: エージェントノードを 1 から 1,000 にスケールしても、プライマリクラスタのパフォーマンスに測定可能な影響は生じませんでした。
膨大なスループット: 合計スループットが動的に 773 倍の 300 万 QPS にスケールされ、1,000 台のコンピューティングノードにわたって Colossus で 800 万 IOPS 以上を達成しました。

2,100 のエージェントノードでテーブル全体のスキャンを同時に実行する同様のベンチマークでは、合計スキャンスループットが 1 秒あたり約 1 テラビットを超えました。

エージェントプールは本番環境クラスタと物理インフラストラクチャを共有しないため、チームは本番環境システムを危険にさらすことなく、推論フリートを数千ノード規模にスケールできます。

3 つの原則すべてを設計に組み込む

次の表は、AlloyDB のアーキテクチャが 3 つの原則をどのように満たしているかを示しています。

エージェント型データベースアーキテクチャには、これら 3 つの基本要素が不可欠です。すなわち、Colossus の特性を備えたストレージ、コンピューティングとストレージをボトルネックなしに接続するネットワーク、そしてエージェントの規模に合わせてプロビジョニングと解放ができるコンピューティングです。

Google は、Google 検索、YouTube、Gmail を稼働させるために、20 年以上かけてまさにその基盤を構築してきました。現在、これは Google のエージェント型データベースアーキテクチャの基盤となっています。

本番環境に影響を与えることなく、エージェントにライブデータを提供

AI を活用した開発に取り組むすべての組織が、ある共通のジレンマに直面しています。それは、ビジネスを支えるシステムを危険にさらすことなく、エージェントに対して本番環境のライブデータへの完全なアクセス権をどのように付与するか、という問題です。これまでは、アプリケーションのニーズではなく、アーキテクチャの制約によって、その選択を強いられていました。エージェントにデータベースへの直接アクセスを許可すると、ミッションクリティカルなシステムを、予測不可能な負荷、深刻なリソース競合、本番環境の停止のリスクにさらすことになります。

これら 3 つの原則に基づいて構築されたアーキテクチャは、こうした妥協を完全に排除します。エージェントは、1 秒未満の更新頻度を保った本番環境のライブデータに基づいて推論します。そして、すべてのインデックス、ベクトル、全文検索、空間検索、SQL の全機能など、エンジンのフル機能を 1 ミリ秒未満の I/O で自由自在に駆使できます。このアーキテクチャは、エージェントの要求に応じて数千もの分離されたノードに動的にスケールし、処理が終了したらゼロにスケールダウンします。その間も、コアトランザクションワークロードは影響を受けることはありません。共有コンポーネントも、共有割り当ても存在せず、連動障害のリスクもないからです。エージェントは、ビジネスの継続性を損なうことなくビジネスにイノベーションをもたらすことができます。

この優れた特性が、本番環境データを参照する他のすべてのシステムにも適用されます。レポート、分析、アプリケーションは、本番環境を危険にさらすことなくライブデータを自由に読み取ることが可能になり、50 年間にわたってオペレーショナルデータベースを縛り続けてきた制約が、ついに解消します。

企業の記録システム内のデータは、その企業にとって最も重要なものです。この基盤の上に構築されたそのデータは、ついに最大限に活用できるようになります。

制約なきデータベースへ。

詳細については、ドキュメントページをご覧ください。こちらから登録すると、今すぐご利用いただけます。

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

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

オーケー: AlloyDB と Database Migration Service で「止められない基幹システム」を移行し、データドリブンな価値創出を加速

Mon, 05 Oct 2026 02:00:00 +0000

小売業界で急速な事業拡大を続けるオーケー株式会社（以下、オーケー）は、ネットスーパーの成長を支えるデータベースの基盤強化と、店舗の「止められない」業務を担うデータベースの刷新という 2 つの課題に挑戦。AlloyDB を軸とする Google Cloud のソリューションを採用し、現場への影響を極小化しながら、新たな基盤の構築に成功しています。このプロジェクトを推進してきたオーケーと KDDIアイレット株式会社（以下、KDDIアイレット）の担当者に、話を伺いました。

利用しているサービス:
AlloyDB, Database Migration Service（DMS）, BigQuery, Firebase, Partner Interconnect, Datastream, Google Workspace, Gemini など

利用しているソリューション:
データベースのモダナイゼーション

ビジネスの急成長を受けて高まった、2 つの基幹データベース刷新の必要性

オーケーは「高品質・Everyday Low Price」を経営方針に掲げ、関東・関西に 180 店舗以上を展開するディスカウントスーパーマーケットです。同社は高品質な商品でありながら、特売日を設けず毎日が低価格の「Everyday Low Price（EDLP）」方針を徹底し、「小売 × IT」の最先端の仕組みづくりに挑戦してきました。2020 年に Google Cloud を導入し、オンプレミスのデータウェアハウスを BigQuery へと刷新したのを皮切りに、2021 年には「オーケーネットスーパー」を開始。会員向けスマートフォンアプリも、Firebase を活用して短期間で構築するなど、デジタル領域での顧客体験向上に注力しています。

しかし、オーケー IT本部副本部長の荒川健児氏は、こうした取り組みの裏側で、システムの心臓部を担う 2 つのコアデータベースの刷新が求められていたと振り返ります。1 つ目は、ネットスーパーの顧客体験向上を担う「ネットスーパー DB」です。

「この領域は将来的には法人利用も視野に入れており、増大するトランザクションに柔軟に対応できるスケーラビリティと、インフラ運用コストの最適化が強く求められていました。従来は他社のクラウド上で稼働しており、データが各システムにサイロ化していたのが実情です。このため高度な分析基盤や AI と連携しながら、お客様に対してパーソナライズされた提案をリアルタイムに行えるようにすることが目標となっていました。」

2 つ目のデータベースは、日々の店舗業務を支える「生鮮 DB」です。これは各店舗のマスター情報や仕入れ、棚卸し、販売実績といったデータを蓄積し、全店舗からのデータ参照や現場の帳票出力などに対応しており、絶対に止めることができないシステムです。

「『生鮮 DB』については長年稼働してきたオンプレミス環境からの脱却を目標にしていましたが、新しいクラウド環境とオンプレミス環境が並存する過渡期に、データ連携と一貫性をいかに維持するかという課題がありました。また『生鮮 DB』は、現場に定着している業務プロセスと密接に結びついているため、一斉停止を伴う全面移行をいかに避けるかも問われていました。」（荒川氏）

AlloyDB の採用により、業務の根幹を支えるデータベースの移行と基盤統一を実現

現行業務への影響を最小限に抑えながら、既存のデータベースからコアデータを安全に切り離し、新たなクラウドに段階的に移行する。この難易度の高いミッションをクリアすべく、オーケーは基本方針の決定からネットワーク構築、PoC（概念実証）、データ移行、本番切り替えまでのサポートを KDDIアイレットに依頼します。評価されたのは、Google Cloud 導入支援と運用最適化を多数手がけてきた実績でした。

これ以降、両社は共に検討を重ね「ネットスーパー DB」と「生鮮 DB」の移行先を統一し、その共通基盤として AlloyDB の採用を決定しました。KDDIアイレットで開発を率いた齋藤寛隆氏は、その選定理由として 5 つのポイントを挙げています。

「まず大前提となったのは高可用性です。AlloyDB は、止められない生鮮業務を支えられる『99.99% のサービスレベル契約（SLA）と約 15 秒のフェイルオーバー』という性能を持っていました。2 つ目は、標準的な PostgreSQL 比で 4 倍以上のトランザクション処理性能、3 つ目は、オートバキュームなどの自動化による運用負荷の削減です。4 つ目はすでに活用されている BigQuery との親和性で、最後は移行支援ツールの充実も決め手になりました。」

AlloyDB への統合にあたっては、「セキュアなプライベート通信の確立」と「種類の異なるデータベース間での無停止移行」という要件がありました。まず通信に関しては、オンプレミスのデータセンターや他社クラウドから Google Cloud へ Partner Interconnect の専用線で接続。インターネットを経由せずに AlloyDB と通信できる閉域網環境が構築されています。

データ移行では、DB ごとに方法が使い分けられました。「ネットスーパー DB」は一部データの移行となり、システムを停止させることが可能だったため、対象データを既存の PostgreSQL からエクスポートし、AlloyDB へインポートする方法が採用されています。これに対して「生鮮 DB」は、システムを止めることができないため、データ移行をアシストする Database Migration Service（DMS）が活用されました。

「『生鮮 DB』の移行では、DMS を用いて従来のデータベースのトランザクションログから差分データを解釈し、新しいデータベースへ継続的にデータ書き込みを行う方式を採用しました。これはクエリを発行しないため、稼働中のデータベースへの負荷を最小限に抑えることができます。また、差分のみの転送で遅延を最小限に抑えつつ、切り替え時のダウンタイムの極小化が実現できると判断し、DMS の採用を決めました。」（齋藤氏）

この移行プロセスでは、KDDIアイレットの知見も活かされています。スキーマ変換では、DMS のコンバージョンワークスペースと Gemini の変換提案を活用して作業の効率化を実現。DMS が対応していない日本語のカラム名では、英数字の仮テーブルを経由して、移行後に再設定する方法が採られています。移行後のデータ検証には、Google Cloud のデータ検証ツールが使用されました。

Gemini や AlloyDB AI も活用しながら、DX と新たな価値創出を追求

今回の移行プロジェクトで得られた技術的な成果を、齋藤氏は次のように総括します。

「『生鮮 DB』は日々の業務を担う『止められないシステム』です。本プロジェクトでは、止められないから移行を諦めるのではなく、ダウンタイムを極小化しながら AlloyDB に移行することで要件をクリアしただけでなく、将来的なデータ活用まで視野に入れることができました。BigQuery との連携では、Datastream を活用することにより、セキュアな通信を維持したまま、AlloyDB から BigQuery へニアリアルタイムにデータを連携できるようにもなりました。」

一方、荒川氏は AlloyDB を軸とした新たなデータベース基盤が、現場における業務を大きく変えつつあると説明します。

「従来、生鮮の現場では、担当者が独自のツールを使って DB からデータを抽出し、手作業で表計算ソフトの集計や状況確認を行っていました。しかし新たなシステムでは、BigQuery 上に生鮮のニアリアルタイムなデータを集約し、さらに天気情報や人流データ、客数予測といった外部データを掛け合わせることが可能になります。店舗での売り上げ情報を即座に反映して『製造の推奨数』を算出することにより、生鮮領域のロスを削減しながら、売り上げを増やすための合理化も図られるようになりました。」

オーケーではデータドリブンな業務改革を定着させるため、環境づくりも進められています。実際に必要とされるデータやシステム運用のリテラシーは職種や部門によって異なるため、AI をエージェント化し、自然言語でデータを活用できるようにする取り組みが始まっています。「自動化できるところは AI で積極的に自動化し、人間は本当に考えるべき業務だけを担う」という発想には、少子高齢化による人手不足に対応する狙いも込められています。

「小売 × IT」で新たなニーズに対応し、事業成長を牽引していく。このアプローチを推進し続けるべく、荒川氏は Google Cloud のエコシステムを活用しながら、DX の推進と顧客体験の向上を図りたいと改めて強調しました。

「デジタル上で店舗の商品を見つけやすくすることは、顧客体験を向上させ、売り上げを伸ばす意味でも重要です。例えば従来のキーワード検索では、『コレステロールが気になる人向けの油は？』といった問いかけに対し、商品を見つけられないことがありました。しかし AlloyDB AI を活用すれば、意味や文脈を汲み取った検索や、類似商品の提案も可能になっていきます。AlloyDB や BigQuery はもとより、Google Workspace や NotebookLM、Gemini をはじめとするツールには、データ連携や集約がシームレスに行えるという大きな魅力があります。今後も KDDIアイレットや Google Cloud のサポートを受けながら先進的な IT を活用し、お客様に提供する価値を高め続けていきたいと考えています。」

オーケー株式会社
1958 年創業。「高品質・Everyday Low Price」を経営方針に掲げ、関東（1 都 3 県）、関西（大阪府・兵庫県）に 180 店舗以上のディスカウントスーパーマーケットを展開。高品質な商品でありながら、特売日を設けず毎日が低価格の「Everyday Low Price（EDLP）」方針を徹底し、ナショナルブランド商品については地域一番の最安値を目指す。2024 年には関西エリアにも進出し、年商 7,500 億円を超える規模へと成長している。

KDDIアイレット株式会社
2003 年 8 月にアイレット株式会社として創業し、2017 年 2 月に KDDI株式会社の傘下に。2026 年 4 月に KDDI Digital Divergence Holdings株式会社との合併により、社名を KDDIアイレット株式会社に変更。クラウドインテグレーション事業、開発事業、デザイン事業、提携事業を展開し、Google Cloud パートナーとして、インフラの移行や新規構築、アプリケーション開発、AI エージェント開発まで数多くの実績を持つ。

インタビュイー（写真左から）

・オーケー株式会社
　IT本部副本部長　荒川健児氏

・KDDIアイレット株式会社
　クラウド・イノベーション本部クラウドインテグレーション事業部グループリーダー
　齋藤寛隆氏

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

AlloyDB と Cloud SQL のネイティブ BM25 ランキングを発表

Fri, 02 Oct 2026 01:00:00 +0000

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

ベクトル検索は、生成 AI、検索拡張生成（RAG）、データエージェントアーキテクチャの重要なコンポーネントですが、ベクトル検索だけでは不十分な場合もあります。ベクトルエンベディングは概念的な意味を理解するのに優れていますが、特定の英数字 ID や正確な商品 SKU 番号を扱うのは苦手です。真に堅牢な検索アプリケーションや AI アプリケーションを構築するには、セマンティックベクトル検索と従来の完全一致キーワード全文検索を組み合わせる必要があるかもしれません。これは、ハイブリッド検索と呼ばれます。

検索において、Best Matching 25（BM25）は、特定のクエリに対するドキュメントの関連性を推定するために使用される重要なアルゴリズムです。これまで、AlloyDB や Cloud SQL で BM25 ランキングを使用するには、全文検索バックエンドを追加する必要がありました。これにより、データサイロ、同期の遅延、運用の複雑化が生じていました。このたび、Tiger Data が作成したオープンソースの pg_textsearch 拡張機能により、AlloyDB と Cloud SQL for PostgreSQL 17 以降でネイティブ BM25 インデックスのプレビュー版が利用可能になりました。これにより、個別の全文検索バックエンドを維持する手間がなくなります。

統合されたハイブリッド検索バックエンドにより、最先端の全文検索を実現するために、個別のシステムをプロビジョニング、管理、または購入する必要がなくなりました。これらはすべて、運用データが保存されているデータベース内で直接行われ、以下を実現します。

業界標準のキーワードランキング: Tiger Data の pg_textsearch を活用して、C 言語で最適化された超高速の BM25 スコアリングを Postgres テーブルに直接適用できます。
複雑さを排除し、完全な整合性を実現: ベクトル検索と全文検索のために複数のバックエンドを維持する場合に発生する、データの重複、ETL パイプライン、同期の遅延を排除します。
強化されたセマンティック検索（AlloyDB 限定）: ScaNN および HNSW インデックスタイプにより、ベクトル検索クエリが（標準の PostgreSQL と比較して）最大 6 倍および 10 倍高速になります。

pg_textsearch を使用する理由

PostgreSQL に組み込まれている ts_rank を使用して、ある程度の規模で全文検索を行ったことがある方なら、その限界をご存じでしょう。コーパスが大きくなるにつれて、ランキングの品質が低下します。逆文書頻度はサポートされていないため、一般的な単語は珍しい単語と同じ重み付けになります。用語頻度飽和がないため、「データベース」という単語が 50 回出現するドキュメントは、1 回しか出現しないドキュメントよりも上位にランクされます。

BM25 は、情報検索のゴールドスタンダードであり、逆文書頻度（珍しい用語ほど重要）、用語頻度飽和（繰り返しに左右されない）、文書長正規化を提供します。Tiger Data のブログ投稿では、PostgreSQL ページで BM25 検索エンジンを構築した方法について詳しく説明しています。

全文検索の例

AlloyDB と Cloud SQL の両方で BM25 全文検索を始める方法をご紹介します。サンプルテーブル cymbal_products を考えてみましょう。このテーブルには、固有識別子 uniq_id、product_name 列、各商品のテキスト説明を含む product_description 列、生成された product_embedding 列が含まれています。cymbal_products には、屋内植物や屋外植物など、さまざまな小売商品に関する情報が含まれています。

インデックスの作成

BM25 を使用するには、pg_textsearch 拡張機能を有効にします。

code_block: <ListValue: [StructValue([('code', '-- Install pg_textsearch extension\r\nCREATE EXTENSION pg_textsearch;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf928f8710>)])]>

cymbal_products テーブルの product_description 列にインデックスを作成します。

code_block: <ListValue: [StructValue([('code', "-- Create the native BM25 index on the content column\r\nCREATE INDEX idx_docs_bm25 \r\nON cymbal_products \r\nUSING bm25 (product_description) \r\nWITH (text_config='english');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf928f9110>)])]>

BM25 全文検索クエリは、<@> 特殊演算子を使用して実行できます。以下のスニペットでは、「cherry tree」を検索しています。

code_block: <ListValue: [StructValue([('code', "-- Full text search query\r\nSELECT product_name, product_description <@> 'cherry tree' AS bm25_score \r\nFROM cymbal_products\r\nORDER BY bm25_score \r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf928fbb50>)])]>

出力例を以下に示します。スコアが低いほど、関連性が高いことを示します。

AlloyDB ハイブリッド検索の例

AlloyDB でハイブリッド検索システムを設定するのは簡単です。同じテーブルにベクトルインデックスとキーワードインデックスの両方を作成し、ハイブリッド検索ユーザー定義関数（UDF）を使用して結果をシームレスに統合できます。

ベクトルインデックスの作成

ScaNN ベクトル検索インデックスを作成する方法は次のとおりです。

code_block: <ListValue: [StructValue([('code', '-- Install vector extension\r\nCREATE EXTENSION vector;\r\n\r\n-- Install scann extension\r\nCREATE EXTENSION IF NOT EXISTS alloydb_scann;\r\n\r\n-- Create scann vector search index \r\nCREATE INDEX cymbal_products_embeddings_scann ON cymbal_products USING scann(product_embedding cosine);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf928fb010>)])]>

ハイブリッド検索

AlloyDB には、ハイブリッド検索クエリを非常に簡単に実行できる、すぐに使用可能なハイブリッド検索 UDF が用意されています。UDF は、Reciprocal Rank Fusion（RRF）アルゴリズムを使用して、各検索コンポーネントのランク付けされた結果を 1 つの統合リストにマージします。このクエリは、UDF を利用して、商品説明で「trees that grow taller than houses（家よりも高く成長する木）」のベクトル検索と「California（カリフォルニア）」のキーワード検索を実行します。

code_block: <ListValue: [StructValue([('code', 'CREATE EXTENSION google_ml_integration;\r\n\r\nSELECT *\r\nFROM ai.hybrid_search(\r\n search_inputs => ARRAY[\r\n \'{\r\n "data_type": "vector",\r\n "weight": 0.5,\r\n "table_name": "cymbal_products",\r\n "key_column": "uniq_id",\r\n "vec_column": "product_embedding",\r\n "distance_operator": "public.<=>",\r\n "limit": 10,\r\n "query_vector": "ai.embedding(\'\'text-embedding-005\'\', \'\'trees that grow taller than houses\'\')::vector"\r\n }\'::JSONB,\r\n \'{\r\n "data_type": "text",\r\n "weight": 0.5,\r\n "table_name": "cymbal_products",\r\n "key_column": "uniq_id",\r\n "text_column": "product_description",\r\n "limit": 10,\r\n "ranking_function": "<@>",\r\n "query_text_input": "California"\r\n }\'::JSONB\r\n ],\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf928f8950>)])]>

以下のサンプル出力に示すように、結果は RRF スコアの降順でランク付けされます。

ここで、ハイブリッド検索は、セマンティックな直感と正確なキーワードマッチングのギャップを埋めます。ベクトルエンベディングは「家より高く育つ木」のような概念的なクエリの理解に優れていますが、従来の全文検索は「カリフォルニア」のような厳密な識別子に求められるピンポイントの精度を提供します。この 2 つを融合することで、AlloyDB は、アプリケーションが「California Sycamore」のような、地域に関連性の高い具体的な結果をリストの最上位に優先的に表示できるようにします。

Cloud SQL ハイブリッド検索の例

Cloud SQL では、同じテーブルにベクトルインデックスとキーワードインデックスの両方を作成し、共通テーブル式（CTE）を使用して結果をシームレスに結合し、以下に示すように RRF スコアを統合できます。

ベクトルインデックスの作成

Cloud SQL で HNSW インデックスを作成する方法は次のとおりです。

code_block: <ListValue: [StructValue([('code', '-- Install vector extension\r\nCREATE EXTENSION vector;\r\n\r\n-- Create an HNSW index on the embedding column for fast approximate nearest neighbor search\r\nCREATE INDEX product_hnsw_idx ON cymbal_products USING hnsw(product_embedding vector_cosine_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf928faf10>)])]>

ハイブリッド検索

こちらがハイブリッド検索クエリです。

code_block: <ListValue: [StructValue([('code', "CREATE EXTENSION google_ml_integration;\r\n\r\n-- BM25 keyword results\r\nWITH keyword_results AS (\r\n SELECT uniq_id, product_name, \r\n ROW_NUMBER() OVER (ORDER BY product_description <@> 'California') AS rank_kw\r\n FROM cymbal_products\r\n ORDER BY product_description <@> 'California'\r\n LIMIT 10\r\n),\r\n-- Semantic vector results\r\nsemantic_results AS (\r\n SELECT uniq_id, product_name, \r\n ROW_NUMBER() OVER (ORDER BY product_embedding <=> google_ml.embedding('text-embedding-005', 'trees that grow taller than houses')::vector) AS rank_vec\r\n FROM cymbal_products\r\n ORDER BY product_embedding <=> google_ml.embedding('text-embedding-005', 'trees that grow taller than houses')::vector\r\n LIMIT 10\r\n)\r\n-- Reciprocal Rank Fusion (RRF) to merge and score both lists\r\nSELECT COALESCE(k.uniq_id, s.uniq_id) AS uniq_id,\r\n COALESCE(k.product_name, s.product_name) AS product_name,\r\n COALESCE(1.0 / (60 + k.rank_kw), 0) + COALESCE(1.0 / (60 + s.rank_vec), 0) AS rrf_score\r\nFROM keyword_results k\r\nFULL OUTER JOIN semantic_results s ON k.uniq_id = s.uniq_id\r\nORDER BY rrf_score DESC\r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf928f8090>)])]>

結果の出力は、上記の AlloyDB ハイブリッド検索の結果と同じです。

実際の操作を見る

こちらのデモ動画で、これらの機能がどのように連携するかをご覧ください。

電気通信事業者の自律性の拡張: Distributed GraphFlow を使用したグラフニューラルネットワークの活用

Wed, 30 Sep 2026 10:00:00 +0000

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

通信業界は現在、従来の人間による手動運用から、完全な自律型ネットワーク運用へのパラダイムシフトを経験しています。最新のネットワークは複雑性、異種性、大規模性を増しているため、運用の自動化を実現するには、手動で設定したルールによるルールベースの手法や従来型の機械学習（ML）手法だけでは不十分です。従来の ML は大量の構造化データから微妙なパターンを特定してきめ細かな予測を行うことができる一方、データとそれが示すシステムを理解して推論し、最終的に人間のオペレーターと同じような意思決定を行う能力はありません。

AI エージェントの成長とその推論能力は、この課題に対する有望な解決策となります。しかし、人間のオペレーターが大規模なネットワーク中に作成された数十億のデータポイントに分散した統計情報を直接取り込むことができないのと同様に、AI エージェントにもそのような規模のネットワークを運用する能力はありません。この課題に対処するために電気通信事業者が採用しているのがグラフニューラルネットワーク（GNN）です。GNN は、大量の時間データやリレーショナルデータをネイティブに処理するように設計された最新の ML です。電気通信事業者は、GNN を AI エージェントと統合することで、根本原因分析、キャパシティプランニング、トラフィック予測、What-If 分析、リアルタイムの異常検出などの高度な診断を、これらの分析情報を解釈して正当なアクションを実行するために必要な推論能力と組み合わせて利用できます。この強力な組み合わせにより、ネットワークを TM Forum が定義するレベル 5 の自律性（システムが自律的に動作する状態）に安全に移行させることが可能になります。

この投稿では、Google Cloud の自律型ネットワーク運用フレームワークを強化する 3 つのコンポーネント（データ、ML、AI）を紹介します。

Google 自律型ネットワーク運用フレームワークのアーキテクチャ

基盤: Spanner Graph 上のデジタルツイン

Google Cloud の自律型ネットワーク運用フレームワークの中核となるのは、ネットワークデジタルツインです。これは、稼働中の通信ネットワークをリアルタイムで継続的にミラーリングし、細部にわたって忠実に再現する仮想レプリカです。静的なモデルではなく、進化し続けるコンポーネントの状態と関係を経時的に捉える、動的な時系列ネットワークグラフとして表現されます。このアーキテクチャアプローチにより、オペレーターは過去に「戻って」過去のデータで ML モデルをトレーニングおよび評価できると同時に、レベル 5 の自律性を実現するために必要な基本的な運用知識を AI エージェントに提供できます。デジタルツインは、提案されたネットワーク変更の影響をこのデジタル環境内でシミュレートすることで、信頼性の重要なレイヤを確立し、AI エージェントが自信を持って将来の状態を設計し、ネットワークの問題を自動的に解決できるようにします。

Google Cloud の Spanner Graph はこのデジタルツインをホストするのに最適なサービスですが、その理由は以下のとおりです。

スケーラビリティと可用性: Spanner Graph は、最新のアプリケーションに妥協のない基盤を提供します。ネットワークの成長に合わせて事実上無制限にスケーリングでき、RPO と RTO はともに 0 であると同時に、99.999% の可用性を保証します。
マルチモデルのサポート: 単一のプラットフォームで複数のデータモデル（リレーショナル、グラフ、ベクトル、全文検索）をサポートしているため、グラフ走査と最近傍ベクトル検索を組み合わせるなど、複雑な構成の構築が可能です。
グローバルな整合性: Spanner は、グローバルに整合性のあるネットワークビューを提供し、システム開発を簡素化します。

次の図は、ルーター、インターフェース（物理ポート）、VPN（L3VPN サービスインスタンス）、フロー（アクティブなトラフィックセッション）の 4 種類のノードを含むネットワークトポロジを示しています。これらは、ネットワークスタック全体をキャプチャする有向エッジによって接続されます。接続の種類としては、ルーターとインターフェース間の物理的封じ込め、インターフェース間の物理リンク、OSPF/iBGP を介したルーター間のコントロールプレーンピアリング、ルーターと VPN 間のサービスメンバーシップ、フローとインターフェース間およびフローと VPN 間のトラフィックアンカリングが挙げられます。

ネットワークトポロジの概要

ML レイヤ: Distributed Graph Flow（DGF）

ネットワークの動作と反応を予測するために、デジタルツインは Distributed Graph Flow（DGF）を活用した ML レイヤを利用します。このレイヤは、Spanner Graph 内にホストされている膨大な量の過去の構造化データでトレーニングすることで、重要な予測的分析情報を引き出します。これにより、人間のオペレーターと AI エージェントは、事後的ではなく事前的にネットワークを管理できるようになります。

先日オープンソース化された DGF は、GNN モデリングのエンドツーエンドのライフサイクル全体を管理するために設計された Python ライブラリです。Google CoreML と Google Research によって開発されたこのライブラリにより、Google Cloud の企業クライアントは、Google が 10 年にわたり開発してきた社内ツールと専門知識を直接活用できるようになります。さまざまなエンジニアリングニーズに対応するこのライブラリは、高度なチーム向けに高性能でコンポーズ可能な低レベルプリミティブを提供するほか、GNN の専門知識なしで迅速な開発を行うためのシンプルな API も提供しています。

たとえば、高レベル API を使用して GraphFlow で GNN モデルをトレーニングして評価する場合、次のように 5 行のコードを記述するだけで済みます。

code_block: <ListValue: [StructValue([('code', 'import dgf\r\n\r\n# Fetch the data from Spanner Graph\r\ngraph, schema = dgf.io.read_spanner_graph(...)\r\n\r\n# Train a node attribute prediction model\r\nmodel = dgf.learning.train_node_model(graph, schema, target_column="risk_score")\r\n\r\n# Evaluate the model\r\nmodel.evaluate()\r\n# Make predictions\r\nmodel.predict(graph, seed_node_idxs=[0, 1, 2])\r\n\r\n# Save the model for later\r\nmodel.save("/tmp/model")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf92895d50>)])]>

DGF は、自律型ネットワーク運用要件に直接マッピングされる最上位概念を提供します。

ユースケース

DGF と GNN を活用する電気通信事業者は、複数の高度なユースケースを通じて、事後保守から予防保守へと移行できます。

異常検出: GNN は、過去のパターンと現在の状態をカプセル化したノードとエッジのエンベディングを生成します。異常なエンベディングは、サービスの低下につながる前に調査対象としてフラグが立てられます。
根本原因分析（RCA）: DGF は、特定の郵便番号での「接続失敗」など、インシデントに関連するネットワークインスタンスのみを含む特定のサブグラフを出力できます。グローバルネットワーク全体をスキャンする必要性がなくなるため、トラブルシューティングエージェントは、分析を高速で実行できます。
予測メンテナンス: システムは、高速移動する機器の「ハンドオーバー障害」など、デバイスの障害やエッジの切断の可能性を予測し、プロアクティブなロードバランシングやルート変更を可能にします。さらに、エージェントを組み合わせることで、「人間関与型」や「人間参加型」を採用して修復アクションを自動化できます。
What-If 分析: GNN を使用すると、電気通信事業者はファイバーの切断、トラフィックの急増、デバイス構成の変更などのシナリオをシミュレートできます。GNN は、トポロジカルな依存関係をモデル化することで、こうした局所的な変化がネットワーク全体にどのように伝播するかを予測できるため、エンジニアはリスクのないデジタル環境で復元力をテストし、緩和戦略を評価できます。

シナリオ: GNN と DGF を使用した根本原因分析

デジタルツインを作成したら（サンプルコード）、以下の簡単な 5 ステップのプロセスで、GNN と DGF を使用した根本原因分析（RCA）検出を実装できます。

デジタルツインに接続する: DGF Spanner Graph コネクタ（dgf.io.read_spanner_graph）を使用して、Spanner Graph のデジタルツインから DGF 環境にネットワークトポロジを直接読み込みます。
教師ありノード（またはエッジ）予測モデルをトレーニングする: トレーニングデータと目的に応じて、教師ありノード予測モデルをトレーニングしてターゲットノードの特徴を予測するか、エッジ予測モデルをトレーニングして根本原因エンティティノードと影響を受けるエンティティノード間のエッジを予測します。指定されたサンプルデータに対して、高レベルの dgf.learning.train_node_model API を使用して、教師ありノード予測モデルをトレーニングします。
ノード予測モデルを使用して根本原因ノードを予測する: ノード予測モデルを直接使用して、異常のあるノードへの影響スコアを予測できます。異常の影響を受けるエンティティノードのうち、予測される影響スコアが最も高いものが根本原因の最有力候補となります。
Gemini Enterprise Agent Platform（旧称 Vertex AI）にデプロイする: モデルをエクスポートして Gemini Enterprise エンドポイントにホストし、スケーラブルかつ低レイテンシの予測を可能にします。
リアルタイム推論: 異常の日付を入力として、推論エンドポイントに予測呼び出しを行います。エンドポイントは、予測された根本原因のエンティティノードを返します。

使ってみる

Distributed Graph Flow を使用した GNN のネットワーク運用への統合は、単なる技術的なアップグレードではなく、通信業界の重要な進化です。GNN を活用した自律型フレームワークに移行することで、電気通信事業者はサービス停止時間を大幅に短縮し、リアルタイムで容量を最適化できます。さらに、最終的には運用効率の向上を通じて優れたカスタマーエクスペリエンスを提供することにもつながります。

独自のインテリジェントネットワークアプリケーションの構築を始めるには、スケーラブルな GNN トレーニングと推論に不可欠なプリミティブを提供する Distributed GraphFlow（DGF）ライブラリをご覧ください。実践演習を行う場合は、コードサンプルの手順に沿って進めます。また、当社が最近受賞したビジネスアウェア GNN ヒーリングネットワークに関するムーンショットプロジェクトもご覧ください。自己最適化自律ネットワークに対する Google のアプローチについては、こちらのホワイトペーパーをご確認ください。

M4N VM ファミリーの一般提供を開始: I/O およびメモリバウンドワークロードでコアあたり最高の IOPS とスループットを実現

Fri, 25 Sep 2026 01:00:00 +0000

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

企業がミッションクリティカルなアプリケーションの規模を拡大するにつれ、ストレージ I/O やメモリアクセスが運用上の大きなボトルネックになることがあります。Oracle Database、SAP HANA のようなインメモリデータベース、高スループットの SQL Server クラスタ、EHR システム、リアルタイムのビッグデータ分析など、メモリバウンドのワークロードでは、必要な RAM 容量とストレージ帯域幅を確保するために、実際に必要な数を超えるコンピューティングコア（vCPU）をプロビジョニングせざるを得ないことが少なくありません。その結果、高額なサードパーティソフトウェアのライセンス費用がさらに膨らむことになります。

このたび、Google Compute Engine の M4N マシンシリーズの一般提供を開始しました。M4N は、I/O 負荷が高く、大容量メモリを必要とするワークロード向けに特化して設計されたマシンシリーズで、ネットワークとブロックストレージに最適化された VM ファミリーの第 2 弾です。主要なハイパースケーラーが提供する同等のサービスと比べ、M4N はハイメモリインスタンスでコアあたり最高の IOPS とスループットを実現し、Oracle Database の TCO を 20% 以上削減できます。

M4N は、ネットワークおよびブロックストレージに最適化されたインスタンスとして、より高いメモリ比率（最大 26:1）と大容量メモリ（最大 6 TB）を実現した業界初のプロダクトでもあります。第 5 世代 Intel® Xeon® スケーラブルプロセッサを搭載し、Google Cloud 独自の Titanium オフロードアーキテクチャを基盤とする M4N インスタンスは、Hyperdisk Extreme と組み合わせることで、ホストあたり合計で最大 25,000 MiB/秒（25 GiB/秒）のストレージスループットと最大 100 万 IOPS を実現します。これは、現行の M4 インスタンスと比べて 2 倍のブロックストレージ性能です。

M4N は、極めて大容量の RAM と妥協のない I/O 性能の両方が求められるワークロード向けに設計されています。高スループットのエンタープライズアプリケーションで課題となるストレージやネットワークのボトルネックを解消することで、M1、M2、M3、M4、X4 などの既存のメモリ最適化ファミリーを補完します。

要求の厳しいワークロードに対応

ワークロードのカテゴリ	主な用途	M4N の強み
ミッションクリティカルなエンタープライズデータベース	Oracle、SAP HANA、SQL Server、IBM DB2、MySQL、PostgreSQL	vCPU あたり最大 26.57 GB のメモリと 25 GiB/秒のストレージ性能を組み合わせることで、データの高速取り込みやトランザクションログ処理を実現し、バックアップ時の処理停止も回避できます。
生成 AI と RAG のデータレイヤ	Milvus、Pinecone、Qdrant、Vespa、Redis、インメモリコンテキストキャッシュ	RAM 上の大規模なベクトルインデックスに対してミリ秒未満で類似性検索を実行できます。さらに、400 Gbps のネットワーク帯域幅により、分散環境でのモデル取得を高速化します。
エンタープライズ向け医療システムと ERP	Epic Systems（オペレーショナルデータベース）、SAP ECC、SAP S/4HANA	十分な I/O 余力を継続的に確保することで、臨床業務やトランザクション処理が集中するピーク時間帯でもクエリレイテンシの急増を防ぎます。
リアルタイム分析と EDA	電子設計自動化、ゲノムモデリング、インメモリ OLAP	大容量メモリにより大規模なデータセット全体を RAM に読み込み、最大限のストレージ帯域幅を活用してチェックポイントダンプを高速に処理できます。

Oracle のライセンス費用を最適化

企業の IT 部門にとって、コア数に応じて増加するソフトウェアライセンス費用は大きな課題です。Oracle Database などのワークロードでは、通常、インスタンスに割り当てられた vCPU または物理コアの数に基づいてライセンス料が算定されます。そのため従来は、必要な RAM 容量やストレージ性能を確保するためだけに、実際には不要なコンピューティングコアまでプロビジョニングし、その分の費用を負担せざるを得ないというトレードオフがありました。

M4N は、業界をリードする高いメモリ対 vCPU 比によって、この課題を解消します。主要なハイパースケーラーが提供するハイメモリインスタンスの中で、M4N はコアあたり最高の IOPS とスループットを実現します。これにより、データベース管理者は次のようなメリットを得られます。

TCO とライセンス費用を削減: Oracle Database に必要な性能密度を確保しながら、コアの過剰なプロビジョニングを回避できます。その結果、主要なハイパースケーラーの同等サービスと比較して、TCO を 20% 以上削減できます。
インフラストラクチャを適正規模に調整: 大容量メモリを利用しながら、ワークロードに必要な分だけコンピューティングリソースを割り当てることができます。
キャッシュヒット率を向上: コアあたりのメモリ容量が増えることで、データベースのより多くの部分をシステムグローバル領域（SGA）に保持できます。これにより、負荷の大きい I/O 処理を減らし、さらなる効率向上を図ることができます。

お客様の声

M4N を早期に利用したお客様の事例からは、ワークロードに最適化されたインフラストラクチャが変革を支える原動力となることがわかります。

「M4N の登場以前は、Google Cloud 上で厳しい I/O 要件を満たそうとすると、必要な性能密度を確保するために、コンピューティングリソースを過剰にプロビジョニングせざるを得ないことがよくありました。新しい M4N インスタンスでは、小規模から大規模まで、さまざまなマシン構成で高いスループットを実現することで、この課題を解消できます。」- Sabre、シニアプリンシパルソリューションアーキテクト Sherri Trojan 氏

「Google Cloud が、ミッションクリティカルなデータベースワークロード向けに次世代の高性能インフラストラクチャを導入したことを大変嬉しく思います。この新しいコンピューティングプラットフォームは、スケーラビリティ、レジリエンス、高いパフォーマンスが求められるエンタープライズ向け Oracle 環境に大きな可能性をもたらします。このイノベーションによって、Google Cloud 上で Oracle ワークロードを実行するお客様にどのような新たな可能性が開かれるのか、大いに期待しています。」- Tessell、共同創業者 / CEO Bala Kuchibhotla 氏

「M4N によって、Google Cloud はプラットフォームの共同設計の可能性をさらに広げています。第 5 世代 Intel Xeon スケーラブルプロセッサと Google 独自の Titanium オフロードアーキテクチャを組み合わせることで、M4N は、世界でも特に要求の厳しいミッションクリティカルなデータ環境に求められる大容量メモリ、高いメモリ帯域幅、妥協のない I/O スループットを実現します。」- Intel

新機能: M4N で大規模なデータレイヤをスケール

M4N は、これまでクラウドインフラストラクチャでは別々に追求されてきた大容量メモリと極めて高い I/O 性能を両立します。Google Cloud 独自の Titanium オフロード技術を採用することで、追加のインフラストラクチャを導入したり、メモリ密度を犠牲にしたりすることなく、I/O のボトルネックを最小限に抑えます。ここでは、M4N がこうした環境でどのようなメリットをもたらすのかを見ていきます。

1. 高帯域幅のデータ転送を実現

大容量メモリを必要とするワークロードに対して、M4N は次の機能を提供します。

優れた VM 間帯域幅: 同一 VPC 内で、VM 間の合計ネットワーク帯域幅は最大 400 Gbps、単一フローの帯域幅は最大 50 Gbps に達します。これにより、分散データベースクラスタやリアルタイムストリーミングデータレイヤで、滞りのないデータ交換が可能になります。
インターネットへの送信（外向き通信）のスループットを向上: インターネットへの送信帯域幅は最大 200 Gbps、パケット処理性能は最大 48 MPPS を実現します。
追加オプションなしで高帯域幅を利用: プレミアムな Tier_1 ネットワーキングアドオンを購入したり構成したりすることなく、最大限の性能を引き出せます。

2. Hyperdisk でストレージ性能を柔軟に調整

Google Cloud の次世代ストレージポートフォリオと組み合わせることで、M4N と Hyperdisk では、IOPS、スループット、容量をそれぞれ個別に調整できます。

Hyperdisk Extreme（HdX）: 合計ブロックストレージスループットは最大 25 GiB/秒、IOPS は最大 100 万に達し、標準の M4 と比べて 2 倍のストレージ性能を実現します。データベースの迅速な復旧、トランザクションのチェックポイント処理、インメモリインデックスの即時再読み込みなどに適しています。
Hyperdisk Balanced（HdB）: スループットは最大 20 GiB/秒、IOPS は最大 64 万まで拡張でき、大規模なエンタープライズストレージを高い費用対効果で実現します。

M4N のマシンタイプと仕様

M4N インスタンスは、メモリ対 vCPU 比が異なる 3 つのティアで提供され、16～224 個の vCPU と最大 5,952 GB の DDR5 RAM に対応しています。また、さまざまなワークロード要件に合わせて、3 種類のメモリ対 vCPU 比に基づく事前定義済みの VM シェイプが用意されており、リソースベースの確約利用割引（CUD）も利用できます。詳しくは、こちらをご覧ください。

使ってみる

M4N インスタンスは現在、世界各地の一部のリージョンでご利用いただけます。M4N ファミリーを活用して、メモリバウンドおよび I/O バウンドのアプリケーションの性能を高め、ライセンス費用を削減する方法について詳しくは、アカウント担当者にお問い合わせいただくか、ドキュメントをご覧ください。

- シニアプロダクトマネージャー、Eduardo Mattos Duarte

- シニアプロダクトマネージャー、Sajal Agarwal

AlloyDB Omni RPM オーケストレーターを使用するエンタープライズグレードの PostgreSQL の一般提供を開始

Fri, 18 Sep 2026 02:30:00 +0000

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

このたび、AlloyDB Omni Red Hat RPM オーケストレーターの一般提供を開始しました。これにより、エンタープライズ環境の PostgreSQL ワークロードで、プロダクションレディなセキュリティ、復元力、低ダウンタイムの運用が実現します。今回の一般提供開始は、プレビューリリースで築いた基盤を足がかりとしています。また、AlloyDB Omni バージョン 18.3.0 とともにリリースされたため、Google AI の機能により、仮想マシンやベアメタルサーバーで直接、クラウドのようなデータベース自動化が可能になります。

この一般提供の開始時点では、要件に合わせて以下の 4 つのモードで AlloyDB Omni をデプロイできます。詳しくは、AlloyDB Omni のドキュメントをご覧ください。

スタンドアロンコンテナ（Debian / UBI）
高可用性エンタープライズデプロイ向けの Kubernetes オペレーターを備えたコンテナ
スタンドアロン RPM
高可用性エンタープライズデプロイ向けの RPM オーケストレーター

セルフマネージドデータベースを運用する理由

多くのユースケースで、マネージドクラウドデータベースサービスが最もシンプルで費用対効果の高いオプションとなっています。しかし、クラウド上またはクラウド外で、PostgreSQL データベースを独自に運用することを選択するシナリオもあります。AlloyDB Omni RPM デプロイは、クラウドのパフォーマンスと、コンテナ化されていないローカルインフラストラクチャの制御を必要とする組織向けのソリューションであり、次のようなユースケースに対応できます。

ワークロードのモダナイゼーション: AlloyDB Omni は、標準の PostgreSQL と比較して、トランザクションワークロードに関しては 2 倍以上、分析クエリに関しては最大 100 倍のスピードで動作し、完全な移行を行わなくても、既存のインフラストラクチャを活性化できます。
規制の厳しい環境: RPM オーケストレーターは、データの所在地とセキュリティに関する厳格な要件がある業界向けに、コンプライアンスを維持するために必要な SELinux やローカル監査ロギングなどのツールを提供します。
エッジへのデプロイとオンプレミスのデプロイ: エッジまたはベアメタルサーバーにデプロイすることで、低レイテンシの処理とオフライン環境での運用が可能になります。
AI 対応インフラストラクチャ: 最新の生成 AI アプリケーションに対応したベクトル検索などの AlloyDB AI 機能をオンプレミスで直接使用して、AI 統合用のデータベースクラスタをプロビジョニングできます。

柔軟なリファレンスアーキテクチャ

AlloyDB Omni RPM オーケストレーターは、パフォーマンスの最大化、読み取りスループットのスケーリング、堅牢な高可用性（HA）の確保など、組織の特定の運用要件に合わせてカスタマイズされた柔軟なデプロイモデルを提供します。詳しくは、AlloyDB Omni の可用性リファレンスアーキテクチャの概要をご覧ください。オーケストレーターは、ユーザーがインスタンスパラメータ、ノード構成、ネットワーキングオプションを調整してカスタマイズ可能なリファレンスアーキテクチャ仕様を定義できるようにすることで、クラスタのプロビジョニングとライフサイクル管理を簡素化します。スケーラブルな AlloyDB Omni HA リファレンスアーキテクチャのデプロイ図の例を以下に示します。

RPM オーケストレーターを使用した AlloyDB Omni クラスタの高可用性リファレンスアーキテクチャ

この図は、RPM オーケストレーターによって管理される AlloyDB Omni の高可用性分散データベースリファレンスアーキテクチャを示しています。クライアントアプリケーションは堅牢なロードバランシング層に接続し、ロードバランサは読み取り / 書き込みトラフィックをアクティブなプライマリデータベースノードに直接ルーティングしています。また、読み取り専用トラフィックはレプリカノードにルーティングされています。ロードバランサは仮想 IP（VIP）を使用しており、Keepalived（VIP フェイルオーバー用）、PgBouncer（PostgreSQL 接続プーリング用）、Haproxy（ルーティングとロードバランシング用）により、ロードバランサ自体が高可用性を備えています。AlloyDB Omni プライマリ インスタンスデータベースノードは、複数のゾーンにわたってデータを同期的に複製することで高可用性を実現します。プライマリ HA クラスタに影響を与えずに、読み取り負荷の高いワークロードをスケールアウトするために、個別の読み取りプール インスタンスがデプロイされています。これらはアクティブノードから非同期レプリケーションを受け取り、スケールアウトされます。

この図は、独立したコントロールプレーンがクラスタ全体の構成と状態を管理する仕組みを示しています。管理者は RPM オーケストレーターを操作して、データベースのライフサイクルを監視します。コントロールプレーンは、冗長なクラスタマネージャーと 3 ノードの etcd ベースの分散構成ストアで構成されており、クラスタの状態を確実に維持して構成を管理できます。コントローラは、個々のデータベースノードで実行されているノードマネージャーと直接やり取りします。単一のクラスタのみをデプロイする場合は、コントロールプレーンとデータプレーンのコンポーネントを同じノードセットで実行できます。

高可用性と読み取りのスケーラビリティ

RPM オーケストレーターを使用すると、要求の厳しいワークロードの稼働時間の維持と読み取りのスケーリングが簡単になります。このオーケストレーターは、スタック全体の障害を自動的に処理できる復元力のあるアーキテクチャを提供します。たとえば、すべてのデータ / 制御パスコンポーネントや読み取り可能なスタンバイの障害を処理する機能や、ノード間のネットワーク中断を軽減する機能などがあります。

このオーケストレーターは、読み取りワークロードをスケールアウトするための読み取りプールをサポートするようになりました。これにより、読み取りプールを動的に作成したりクラスタに追加したりして、分析クエリや同様のワークロードのニーズを満たすことができます。また、スタンバイノードと読み取りプールに対する専用の読み取りエンドポイントの構成もシステムによって行われます。

Google は、AlloyDB Omni RPM オーケストレーターの機能を継続的に拡張しています。ビジネスの継続性とクロスリージョンの復元力をさらに強化する高度なエンタープライズグレードの機能など、今後の機能にご期待ください。

データ保護とセキュリティ

データセキュリティとデータの復元は、RPM オーケストレーターの中核をなす要素です。このリリースでは、自動化されたバックアップと復元の機能が統合され、バックアップスケジュールを構成して、GCS または S3 互換ストレージへの完全自動バックアップを自動的に管理できるようになりました。このオーケストレーターを使用すると、S3 バケットまたは GCS バケットに対して、またはローカルでバックアップを実行できます。さらに、ポイントインタイムリカバリと、完全に自動化されたインプレース PIT 復元がネイティブにサポートされています。

RPM オーケストレーターは、ブートストラップ時またはブートストラップ後の SELinux 適用をサポートしています。これにより、厳格な企業のコンプライアンスとセキュリティ基準を満たし、強制的なアクセス制御と強力なプロセス分離を実現できます。

データベース運用

データベースフリートの管理に関連する運用上のオーバーヘッドが削減されました。

手間のかからない低ダウンタイムメンテナンス: 完全に自動化された新しい低ダウンタイムメンテナンス（LDTM）により、ライフサイクルアップデートとスケーリングオペレーションの管理が容易になります。マイナーバージョンのアップグレード時や CPU とメモリリソースの調整時に、ダウンタイムを最小限に抑え、自動ロールバックをサポートすることで、最大限の可用性を実現します。
動的な構成: データベース管理者は、ブートストラップ時またはブートストラップ後に GUC / 構成を変更する機能などを使用して、設定を動的に調整できます。AI 統合用のクラスタをプロビジョニングすることもできます。
クラスタメンテナンスの簡素化: ワークロードの需要の変化に応じてデータベースノードを追加または削除するネイティブな運用機能により、クラスタフットプリントの管理が簡単になります。

オブザーバビリティ、AI、拡張機能

フリートのモニタリングと調整には、細部まで把握できる可視性と適切なツールセットが必要です。

高度なロギング: このオーケストレーターは、データパスとコントロールパスのログをログディスクに転送することで、監査とデバッグを簡素化します。
優れたオブザーバビリティ: カスタム指標がサポートされているため、モニタリングエコシステムに合わせてオブザーバビリティを微調整できます。カスタム指標を使用すると、1 分あたりの新規ユーザー登録数、特定のテナントのアクティブセッション数、処理された注文数など、ビジネスレベルのイベントをデータベースから直接追跡し、自社の中心的なオブザーバビリティプラットフォームにエクスポートできます。
AI と拡張機能: このオーケストレーターでは、AlloyDB Omni でサポートされている一連の拡張機能だけでなく、自然言語を使用したクエリ、AI を活用した検索、AI 関数など、AlloyDB Omni のすべての AI 機能がサポートされています。

早速始めましょう

AlloyDB Omni Red Hat RPM オーケストレーターは、ベアメタルまたは VM プラットフォームで PostgreSQL 互換ワークロードを管理するための新たな手段となります。AlloyDB の高パフォーマンス、生成 AI 機能へのアクセス、Gemini モデルを組み合わせて、AI エージェントとアプリケーションを構築し、完全な自動化を実現できます。

オンプレミスのデータベース運用のレベルアップをご希望なら、AlloyDB のドキュメントで詳細をご確認のうえ、今すぐ一般提供リリースをお試しください。こちらからご登録いただけます。

さらに、Google の新しい Codelab もお試しください。RPM オーケストレーターを使用して高可用性 AlloyDB Omni クラスタをデプロイできます。

- シニアスタッフエンジニア、Ujjwal Lanjewar

- プロダクトマネージャー、Omkar Deshmukh

DMS の領域を超えて: SQL Server のログインとユーザーを Cloud SQL に効率的に移行

Fri, 18 Sep 2026 02:30:00 +0000

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

データベースのモダナイゼーションを計画したとしましょう。Google Cloud の Database Migration Service（DMS）を設定し、レプリケーションを構成して、オンプレミスまたはクラウドシステムからフルマネージドの Cloud SQL for SQL Server インスタンスにアプリケーションデータベースを正常に同期しました。

そしてレプリケーションが完了し、データが最新の状態になり、カットオーバーの準備が整いました。しかし、移行したばかりのデータベースにアプリケーションを接続しようとすると、次のメッセージが表示され、壁にぶつかります。

Msg 18456, Level 14, State 1, Line 1: Login failed for user 'app_user.

原因は単純です。SQL Server のログインが、データベースと一緒に移行されなかったからです。この投稿では、このギャップが存在する理由、これが組織のセキュリティポスチャーの保護につながる理由、そして長年の実績がある標準的な SQL Server ツールを使用して簡単にこのギャップを埋める方法をご説明します。

DMS でログインが移行されない理由: セキュリティとコンプライアンス

Database Migration Service（DMS）は、データベースレベルのスキーマとトランザクションデータを非常に効率的に複製しますが、システム master データベースやサーバーのログインと権限などのインスタンスレベルのオブジェクトは移行しません。これは、意図的な動作です。

機能が欠けているように感じられるかもしれませんが、実際には、次の 3 つの基本方針に基づく慎重な設計なのです。

セキュリティの分離と権限の境界: 移行元の環境と移行先の Cloud SQL 環境は、異なるセキュリティパラダイムで運用されています。マスターシステムデータベースを直接複製すると、不正な権限昇格につながる可能性があります。たとえば、sysadmin 権限を持つオンプレミスのログインに、フルマネージドの Google Cloud データベースへの無制限の sysadmin アクセス権を付与すべきではありません。クラウドプロバイダが物理的なバックアップ、パッチ適用、セキュリティを管理する場合、適切な運用を確保するために、基盤となるオペレーティングシステムへのアクセスを制限する必要があります。
コンプライアンスと監査ガバナンス: 暗号化されたパスワードハッシュとサーバーレベルのセキュリティ認証情報を、管理者の明示的な監視なしに自動的に移行した場合、PCI-DSS や SOC 2 などの企業のコンプライアンスフレームワークに違反してしまうことが珍しくありません。セキュリティオブジェクトの移行を管理者が主導する慎重なステップとして維持することで、組織は承認された ID のみがクラウドランディングゾーンにプロビジョニングされることを保証できます。
ID のモダナイゼーションの必要性: クラウドへの移行は、古くなった認証情報を更新および削除する絶好の機会です。オンプレミスインスタンスには、使用されなくなった以前の SQL ログインが含まれていることがよくあります。深く考えずにそれらをクラウドマネージドサービスに複製することは、セキュリティのアンチパターンです。さらに、Cloud SQL への移行が、以前の SQL 認証から、顧客管理の Active Directory（CMAD）などのクラウドネイティブな最新の ID ソリューションへの移行を促進するきっかけとなることがよくあります。

ログインとユーザーの違い: SID 接続

ログインを正常に移行するために、SQL Server がセキュリティを管理する方法を簡単に復習しておきましょう。SQL Server では、ID が次の 2 つのレイヤに分かれています。

ログイン（サーバーレベル）: master データベースに保存されます。ログインは、SQL Server インスタンスへのクライアント接続を認証します。
ユーザー（データベースレベル）: 個々のユーザーデータベース内に保存されます。ユーザーは、その特定のデータベース内で接続が実行できるアクションを承認します。

サーバーログインとデータベースユーザーを橋渡しするのは、一意のセキュリティ識別子（SID）です。

データベースをバックアップして復元する（または DMS を使用して複製する）と、データベースレベルの「ユーザー」（および対応する SID）がデータベースファイル内に移行されます。ただし、対応するサーバーレベルの「ログイン」が移行先の master データベースに存在しない場合、または存在しても SID が異なる場合、マッピングは解除されます。これにより、データベースアクセス権限はあるものの、サーバーレベルで認証できない「孤立したユーザー」が生じます。

図 1: 対応するログインがないデータベース、またはセキュリティ識別子（SID）が一致しないデータベースを移行すると、移行先のインスタンスで孤立したユーザーが生じる。

推奨ソリューション: sp_help_revlogin を使用してログインを複製する

すべてのログインを手動で再作成し、パスワードハッシュの見当を付けようとする代わりに、Microsoft が従来より提供しているスクリプト sp_help_revlogin を使用するとよいでしょう。

このスクリプトは、移行元インスタンスのすべての SQL Server 認証ログイン用 CREATE LOGIN ステートメントを含む T-SQL クエリを生成します。このステートメントは、元の暗号化されたパスワードハッシュと正確なセキュリティ識別子（SID）を備えています。

ステップ 1: 移行元インスタンスでヘルパープロシージャを作成する

SQL Server Management Studio（SSMS）を使用して、移行元の SQL Server インスタンスに接続します。Microsoft の公式スクリプトをコピーして実行し、移行元の master データベースに 2 つの必須ストアドプロシージャ（sp_hexadecimal と sp_help_revlogin）を作成します。

ステップ 2: 移行スクリプトを生成する

プロシージャが作成されたら、SSMS のクエリウィンドウで次のステートメントを実行します。出力を正確にコピーするには、出力設定を [Results to Text] に切り替えてください（Ctrl+T）。

code_block: <ListValue: [StructValue([('code', 'EXEC master.dbo.sp_help_revlogin;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf933a94d0>)])]>

出力には、次のような自動生成された T-SQL ステートメントが含まれます。

code_block: <ListValue: [StructValue([('code', 'CREATE LOGIN [app_user] WITH PASSWORD = 0x01004F3D... HASHED, SID = 0x8D2F..., DEFAULT_DATABASE = [CustomerDB]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf933ab0d0>)])]>

HASHED パスワードオプションと元の SID を使用してログインをスクリプト化することで、SQL Server で元のパスワードと安全なリンクをそのまま維持してログインを安全に再作成できます。

ステップ 3: スクリプトを Cloud SQL に適用する

生成されたスクリプトをコピーし、移行先の Cloud SQL for SQL Server インスタンスに接続して、クエリを実行します。ログインは、正しいパスワードでクラウドに即座に作成されます。

sp_help_revlogin によって生成されたスクリプトを実行することで、正確なセキュリティ識別子（SID）とパスワードハッシュをそのまま維持した状態で、移行先の Cloud SQL インスタンスにログインを複製できます。以下に示すように、これにより、データベースレベルのユーザーがデータベースの移行時にサーバーレベルのログインに自動的にマッピングされるため、「孤立したユーザー」を完全に回避できます。

図 2: sp_help_revlogin スクリプトを使用した統合移行プロセス。パスワードハッシュと元の SID を保持し、Cloud SQL for SQL Server でユーザーマッピングを解決する。

注: sp_help_revlogin は、Microsoft が作成、管理しているストアドプロシージャです。必ず最新バージョンをダウンロードし、ドキュメントをお読みください。

孤立したユーザーのトラブルシューティング

sp_help_revlogin を実行する前に、移行先の Cloud SQL インスタンスにログインを手動で作成していた場合、SID が一致せず、ユーザーが「孤立」する可能性があります。

孤立したユーザー（app_user など）が見つかった場合は、次の 1 つのコマンドで簡単に、新しく作成したサーバーログインに再マッピングできます。

code_block: <ListValue: [StructValue([('code', 'ALTER USER [app_user] WITH LOGIN = [app_user];'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf933a9050>)])]>

このコマンドにより、データベースユーザーとサーバーログインが SID を介してすぐに再結合され、アプリケーションの接続が完全に復元されます。

セキュリティをさらに強化

sp_help_revlogin を使用した SQL ログインの移行は、リフト＆シフト移行の最も簡単な方法ですが、クラウド移行を利用した認証のモダナイズもご検討いただけます。Cloud SQL for SQL Server は、顧客管理の Active Directory（CMAD）との堅牢な統合をサポートしています。移行先インスタンスを Active Directory と統合することで、従来の SQL ログインを廃止し、一元化されたエンタープライズグレードの Kerberos 認証に移行できます。

まとめ

データベースの移行は、単なるデータ行の移動ではありません。アプリケーションのセキュリティ、コンプライアンス、運用性を初日から確保することが重要です。Google Cloud の DMS によってデータレプリケーションの煩雑な処理を行う一方、シームレスなカットオーバーを保証する簡単な 3 ステップのプロセスでログインを移行できます。

移行戦略の最適化について詳しくは、Cloud SQL for SQL Server 移行ガイドをご覧ください。また、Database Migration Service を使用して Google Cloud への移行を効率化する方法もご確認ください。

- SQL Server ブラックベルト、Assaf Fraenkel

- シニアプロダクトマネージャー、Adi Shtatfeld

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 0x7fdf93224090>)])]>

変更がない点

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

ベストプラクティス

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

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

外部の関連資料

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

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

メジャーがサポートされるようになった BigQuery Graph を使用して、信頼できるエージェントワークロードを実現

Tue, 25 Aug 2026 02:00:00 +0000

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

企業が単純なチャットアシスタントの使用から自律型のエージェントワークロードに移行すると、すぐに厳しい現実に直面します。それは、エージェントが元テーブルを直接使用する際に、不正確な分析情報を生成する傾向があるということです。

BigQuery Graph は、組織がフラットで静的なテーブルから脱却し、現実世界に存在する企業を正確に表現できるように、つまり、現実世界の依存関係を持つ、相互に接続された事業体として表現できるようにします。BigQuery Graph（プレビュー版）でメジャーがサポートされるようになったことで、管理された指標と関係マッピングが統合されます。これにより、エージェントはグラフで収集された複雑な依存関係全体について、メジャーの精度に基づいて推論できます。

関係が重要な理由

従来のデータ構造では、マルチホップのビジネスコンテキストが考慮されないため、次のように、AI エージェントが運用上誤った意思決定を行うことがあります。

具体的な問題: 小売業者のエージェントが、シアトルでの冬用ジャケットの売り上げが 12% 減少した理由を尋ねられた場合、フラットテーブルをクエリして、「事実」（12% の減少）を報告することはできますが、「シアトルの注文 ➔ 配送センター ➔ 地域の嵐によるサプライヤーの遅延」という関係パスを追跡できないため、「理由」を特定することはできません。
分断されたシステムのリスク: 関係のコンテキストがないため、エージェントが関連性のない 15% オフのキャンペーンを提案し、不必要に利益率を低下させます。さらに、あるチームがサプライヤーの関係を別のグラフデータベースにマッピングし、別のチームが SQL 指標を維持するというように、別々のシステムを維持すると、エージェントは実行時にこれらのスタックを結合せざるを得なくなります。このプロセスは時間がかかり、費用もかさみ、KPI の計算に一貫性がなくなります。

BigQuery Graph のメジャーは、既存のテーブルをプロパティグラフにインプレースでマッピングし、ETL を不要にすることで、この問題を解決します。この統合された設定により、次のような問い合わせの論理的な進化が可能になります。

メタデータのグラウンディングは、存在するデータを確立します。
ビジネス指標（メジャー）は、ビジネスのパフォーマンスを計算します。
関係マッピング（グラフ）は、それが起こった理由を明らかにします。

仕組み

従来、グラフ走査中の標準 SQL の結合では行が重複し、集計計算が不正確になっていました。BigQuery Graph は、これをネイティブに解決します。

データモデラーは、プロパティグラフ DDL 内で直接 MEASURE（SUM や AVG など）を定義します。エンジンは GRAPH_EXPAND 関数と AGG アグリゲータを介して標準 SQL を使用して、指標を評価する前に構造グラフのパスを解決します。これにより、エージェントは計算機（SQL）が必要なときと地図（グラフ）が必要なときを認識できるほどスマートになります。

bigquery-public-data のような一般公開プロジェクトは厳密に読み取り専用であるため、読み取り専用の一般公開テーブルをノードおよびエッジとして直接参照しながら、プレースホルダ変数（YOUR_PROJECT_ID）を使用して独自のプロジェクト内で論理プロパティグラフをマッピングする必要があります。

code_block: <ListValue: [StructValue([('code', '-- 1. Map the graph inside YOUR project \r\n\r\n\r\nCREATE OR REPLACE PROPERTY GRAPH `YOUR_PROJECT_ID.YOUR_DATASET.thelook_ecommerce_graph`\r\nNODE TABLES(\r\n `bigquery-public-data.thelook_ecommerce.users` AS User\r\n KEY(id)\r\n LABEL User PROPERTIES(id, city, country),\r\n `bigquery-public-data.thelook_ecommerce.orders` AS Order\r\n KEY(order_id)\r\n LABEL Order PROPERTIES(\r\n order_id, \r\n MEASURE(AVG(num_of_item)) AS avg_items_per_order,\r\n MEASURE(SUM(num_of_item)) AS total_items\r\n )\r\n)\r\nEDGE TABLES(\r\n `bigquery-public-data.thelook_ecommerce.orders` AS OrderedBy\r\n SOURCE KEY(order_id) REFERENCES Order(order_id)\r\n DESTINATION KEY(user_id) REFERENCES User(id)\r\n LABEL ORDERED_BY\r\n);\r\n\r\n-- 2. Query your new graph with standard SQL—using standard {Label}_{Property} column outputs\r\nSELECT\r\n User_city AS city,\r\n ROUND(AGG(Order_avg_items_per_order), 2) AS agg_avg_items,\r\n ROUND(AGG(Order_total_items), 2) AS agg_total_items\r\nFROM GRAPH_EXPAND("YOUR_PROJECT_ID.YOUR_DATASET.thelook_ecommerce_graph")\r\nGROUP BY User_city\r\nORDER BY agg_total_items DESC\r\nLIMIT 10;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf93288f90>)])]>

BigQuery Studio でグラフインテリジェンスを民主化

デベロッパーとビジネスユーザーの双方が、これらの関係ネットワークをスムーズに管理、デプロイできるように、直感的なネイティブ運用ツールを BigQuery Studio に直接組み込みました。

視覚的なグラフモデラー: BigQuery Studio 内のノーコードのドラッグ＆ドロップインターフェースで、複雑な DDL スクリプトを手動で記述することなく、プロパティグラフ、ノード、エッジを視覚的に構築、編集、マッピングできます。

会話型分析（CA）のインテグレーション: ユーザーはグラフと自然にやり取りできます。会話型分析エージェントは、テーブル結合を推測するのではなく、グラフの決定論的な関係認識マップをナビゲートし、自然言語の質問を、境界が制約された正確な GoogleSQL クエリまたは ISO GQL クエリに変換します。これにより、モデルのハルシネーションを防ぎ、セマンティックな一貫性を確保します。

統合されたセマンティクス: Looker とのネイティブなインテグレーション

断片化されたロジックスタックの維持を避けるために、ビジネス指標はデータレイヤに存在する必要があります。Looker（LookML）を、データベース内分析モデルとしての BigQuery Graphs とネイティブに統合することで、コアでロジックを一度定義するだけで済みます。

データベース管理モデル（sql_analytic_model_name）: sql_analytic_model_name を使用して、Looker にデータベース定義の BigQuery Graph を直接参照させ、標準の LookML のディメンションとメジャーをグラフプロパティに直接マッピングします。
Looker 管理モデル（derived_analytic_model）: derived_analytic_model を使用して、LookML ビュー内で BigQuery Graph スキーマを直接定義します。Looker は、SQL DDL ステートメントを動的に生成して実行し、BigQuery 内のグラフを維持します。
エンタープライズ DevOps ワークフロー: Looker IDE、Git ベースのバージョン管理、継続的インテグレーション（CI）を使用して、グラフのライフサイクル全体を管理します。主要な KPI（離脱率など）は、検証済みで、信頼できる、まったく同じものが維持されます。

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

- ソフトウェア開発マネージャー、Yun Zhang

Gemini in Database Migration Service を使用した PostgreSQL への移行の迅速化

Fri, 21 Aug 2026 02:00:00 +0000

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

次のようなシナリオを考えてみましょう。Oracle や SQL Server などの既存の商用データベースから、オープンソースの PostgreSQL や AlloyDB for PostgreSQL などのフルマネージドサービスにコアアプリケーションを移行するとします。

最初のフェーズは順調に進みます。スキーマが変換され、テーブルにデータが入力され、データ移行パイプラインが数テラバイトのデータを数時間で転送します。プロジェクトは予定より早く進んでいるようです。

そのとき、チームはボトルネックに直面します。

既存のデータベースには、何百ものストアドプロシージャ、複雑なトリガー、そして PL/SQL や T-SQL など独自の SQL 言語で記述されたカスタム関数が埋め込まれています。これらのルーチンには、トランザクションの検証、注文処理、カスタムレポートの処理など、長年にわたる重要なビジネスロジックが含まれています。

モダナイゼーションプロジェクトは急に行き詰まります。数千行に及ぶ手続き型ロジックの変換には、2 つの言語に関する専門知識、数か月にわたる手作業での書き換えが必要となり、高確率で変換エラーが伴います。このコード変換は、データベース移行の「ラストワンマイル」のボトルネックであり、移行における最も複雑な部分です。

幸いなことに、このラストワンマイル問題は、最近の AI の進歩によって解決できます。Database Migration Service（DMS）には、Gemini を活用した AI によるコード変換が含まれています。移行ワークフローに生成 AI を直接組み込むことで、ストアドプロシージャ、トリガー、カスタム関数を、より高速かつ正確に PostgreSQL PL/pgSQL コードに変換できます。

ストアドプロシージャの変換に関する課題

商用データベースエンジンでは、ストアドプロシージャ、ユーザー定義関数、パッケージ本体、条件付きロジックに、ベンダー固有の構文が使用されています。このロジックを PostgreSQL PL/pgSQL に変換するには、変数の定義、例外処理ブロック、カーソルループ、組み込み関数のマッピングが必要になります。

何百ものストアドプロシージャを含む複雑なエンタープライズスキーマを移行する場合、たいていは手動でのコード変換に数か月のエンジニアリング作業が必要になります。データベースチームは、以前のロジックを 1 行ずつ解析し、条件分岐を実装し直して、エンジン間のデータ型変換を検証する必要があります。

DMS での AI によるコード変換

Gemini in Database Migration Service は、Google Cloud コンソール内で直接、この変換作業を迅速化します。DMS は、スキーマを自動的に変換するとともに、AI 生成のコードを提案して、ソース言語と PostgreSQL の構造上の違いを説明します。

PL/pgSQL に変換されたコードは、元のソースコードと並べて表示されます。データベースチームは提案内容をリアルタイムで確認、編集、検証できます。

図 1: Database Migration Service のインターフェースに、変換前後のコードと Gemini によるインラインの説明が表示されている。

AI の統合が重要である理由

主要ベンダーのほとんどの AI アプリや AI ツールには、SQL コードなどのコードを生成、変換する機能があります。しかし、汎用の AI チャットツールが提供するスニペットの変換機能では、エンタープライズデータベースの変換には不十分です。Gemini in Database Migration Service には、以下の重要な利点があります。

スキーマの完全なコンテキスト: Gemini in DMS は、コードスニペットを個別に評価するのではなく、移行プロジェクト全体にわたり、テーブルの関係、データ型、依存ビュー、プロシージャ間参照などのデータベースコンテキストを総合的に分析します。
エンタープライズ向けのセキュリティとプライバシー: コード変換は、厳密に Google Cloud プロジェクトの境界と IAM ガバナンスの範囲内で実行されるため、独自のビジネスロジックと知的財産を保護できます。
統合された実行ワークスペース: DMS を使用すると、何百ものファイルにわたる手動でのコピーと貼り付けが不要になります。単一のコンソール内で、並べて表示されたコードの違いと AI によるインラインの説明を確認し、必要に応じてコードを編集したうえで、検証済みの PL/pgSQL ルーティンをターゲットデータベースに直接デプロイできます。
決定論的な精度と AI コンパイル: DMS は決定論的なコンパイラルールによる 1 対 1 のマッピング（標準的な DDL 変換、スカラー関数、明確に定義された構文変換など）と、複雑な手続き型ブロックのための Gemini の文脈的統合を組み合わせることで、モデルのドリフトを防ぎ、正確で予測可能な変換を保証します。

Oracle PL/SQL から PostgreSQL への変換

顧客の合計注文額を算出し、独自の NVL 関数と DECODE 関数を使用して段階別の割引を適用する Oracle PL/SQL ストアドプロシージャを考えてみましょう。当初のワークフローでは、NVL を COALESCE に手動でマッピングし、DECODE ステートメントを標準の CASE 式に書き換え、WHEN NO_DATA_FOUND THEN などの例外ブロックを調整する必要がありました。

DMS で移行評価を実行すると、Gemini がソースプロシージャを分析し、ネイティブの PostgreSQL PL/pgSQL コードを生成します。

ソース: Oracle PL/SQL

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE PROCEDURE calculate_discount (\r\n p_customer_id IN NUMBER,\r\n p_discount OUT NUMBER\r\n) AS\r\n v_total NUMBER := 0;\r\nBEGIN\r\n SELECT NVL(SUM(amount), 0) INTO v_total\r\n FROM orders WHERE customer_id = p_customer_id;\r\n \r\n p_discount := DECODE(TRUE, v_total > 10000, 0.15, v_total > 5000, 0.10, 0.05);\r\nEXCEPTION\r\n WHEN NO_DATA_FOUND THEN\r\n p_discount := 0;\r\nEND;\r\n/'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf934d2510>)])]>

ターゲット: PostgreSQL PL/pgSQL（Gemini in DMS で変換）

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE FUNCTION calculate_discount (\r\n p_customer_id NUMERIC,\r\n OUT p_discount NUMERIC\r\n) RETURNS NUMERIC AS $$\r\nDECLARE\r\n v_total NUMERIC := 0;\r\nBEGIN\r\n SELECT COALESCE(SUM(amount), 0) INTO v_total\r\n FROM orders WHERE customer_id = p_customer_id;\r\n\r\n p_discount := CASE\r\n WHEN v_total > 10000 THEN 0.15\r\n WHEN v_total > 5000 THEN 0.10\r\n ELSE 0.05\r\n END;\r\nEND;\r\n$$ LANGUAGE plpgsql;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf9328b310>)])]>

Gemini は、生成された SQL とともに、NVL が COALESCE に変換された理由と、Oracle の DECODE 関数が PostgreSQL で明示的な CASE ブロックに変換された方法について、詳しい説明をインラインで表示します。

図 2: Gemini in DMS を活用したエンドツーエンドのデータベースコード変換パイプライン。

スキーマの完全な管理と検証の維持

セキュリティ、透明性、コードの精度は、データベースのモダナイゼーションにおいて依然として中心的な要素です。Gemini in DMS は、厳密に Google Cloud の確立されたセキュリティ境界内で動作し、コードをプロジェクト内に限定して公開します。

変換と検証のプロセスは、信頼性を保証するため、構造化されたワークフローに沿って行われます。

スキーマコンテキストの自動取得: DMS 変換ワークスペースを設定すると、テーブルスキーマ、データ型、外部キー制約、プロシージャ間の依存関係など、ソースデータベースの全メタデータが自動的に解析されます。Gemini では、このプロジェクト全体のコンテキストを参照してコードが生成されるため、依存オブジェクトの定義を手動で指定する必要はありません。
構文と依存関係の自動検証: コードの生成時、DMS はターゲットとなる PostgreSQL の構文ルールに照らして検証パーサーを実行します。検証ステータスインジケーター（変換済み、警告、要対応など）が各オブジェクトに割り当てられるため、手動での確認が必要なルーティンはすぐにわかります。
インタラクティブな評価状態: スキーマの変更はすべて完全に管理できます。変換ワークスペース内で、ターゲットデータベースに変更を適用する前に、コードを並べて違いを確認したり、AI によるインラインの説明を確認したり、PL/pgSQL コードを直接編集したりできます。
デプロイと検証のステージング: コードがワークスペース検証に合格したら、変換されたスキーマと関数をターゲットのステージングインスタンス（Cloud SQL や AlloyDB など）に適用し、本番環境への切り替え前に機能の実行とパフォーマンステストを行うことができます。

データベースのモダナイゼーションの効率化

Database Migration Service の AI によるコード変換により、データベースチームは以前のデータベースロジックを数か月ではなく数日で変換できます。データベース管理者とアプリケーション開発者は、貴重な時間を費やしてコードを最初から書き直す代わりに、新しい機能の追加、パフォーマンスのテスト、アプリケーションのモダナイゼーションに注力できます。

Oracle と SQL Server の一般的な変換シナリオと、DMS がそれらを PostgreSQL に変換する方法の代表的な例については、新しい Gemini に習う PostgreSQL 動画シリーズをご覧ください。

SQL Server コードを PostgreSQL に変換する

データベース移行に関する悩みを解消し、以前のデータベースロジックをシームレスに変換する方法を Gemini に教えてもらいましょう。

Database Migration Service を使ってみる

データベースの変換を始めるには、Database Migration Service コンソール（https://console.cloud.google.com/dms）で移行評価を実行するか、異種間移行ガイド（https://cloud.google.com/database-migration）をお読みください。

- Google Cloud、戦略的クラウドエンジニア、Tanya Sharma

複数の結果セット: Database Migration Service における SQL Server から PostgreSQL への変換の自動化

Thu, 20 Aug 2026 02:00:00 +0000

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

Medium のブログ投稿「From MARS to SETOF REFCURSOR: Migrating Multi-Result Stored Procedures to PostgreSQL」（MARS から SETOF REFCURSOR へ: 複数の結果を返すストアドプロシージャを PostgreSQL に移行する）で、複数の結果セットに関する SQL Server と PostgreSQL の基本的なアーキテクチャの違いについて説明しました。SQL Server では 1 回の実行で複数の表形式ストリームをネイティブにストリーミングする一方、PostgreSQL では、明示的なカーソル操作を使用する、より慎重な戦略が必要であるという内容でした。

このようなプロシージャが数百もある大規模なデータベース移行に対応しなければならない場合、手動での書き換えは現実的ではありません。こうした状況で役立つのが自動ツールです。この投稿では、この課題に対する Google Cloud の Database Migration Service（DMS）のアプローチ、その内部で適用される変換ロジック、生成されたコードを実際に実行してテストする方法について詳しく説明します。

DMS の中核的な変換戦略

データベースを PostgreSQL に移行する要因は数多くあります。たとえば、エンタープライズ規模のパフォーマンスと可用性、拡大し続けるデベロッパーとユーザーのコミュニティ、強力な AI 機能などです。しかし、複数の結果セットを含むクエリなどの複雑なクエリの場合、移行プロジェクトの遅延を招く可能性があります。

DMS が確認するのは、プロシージャが返す結果セットの数と、スカラー戻り値（RETURN）を使用するかどうかの 2 点です。

変換に関する意思決定マトリックスは次のようなものです。

シナリオ	SQL Server の特性	PostgreSQL ターゲットオブジェクト	メカニズム
シナリオ A	結果セット 1 つ、またはスカラー戻り値 1 つのみ	ストアドプロシージャ	INOUT refcursor パラメータまたは標準の変数トラッキングを介してネイティブに処理。
シナリオ B	複数の結果セット、または結果セットとスカラー戻り値の組み合わせ	関数	RETURNS SETOF refcursor ブロックに変換。スカラー戻り値は、独自の個別カーソルデータセットとして追加される。

複数の結果セットの変換を自動化: DMS 内部の動作

SQL Server は、明示的な宣言なしで単一の接続実行パスを介して複数の結果を送信できるようにする、表形式データストリームプロトコルを利用します。一方、PostgreSQL は、カーソルを介して複数のデータセットが決定的に管理される、別個の実行プロトコルに依存しています。この構造上の違いを補うため、DMS は変換ロジックを自動化します。

医療報告のベースラインシナリオを例に考えてみましょう。マスタープロシージャ（sp_GetPatientSummary）は、検査結果用（sp_GetPatientLabResults）と診察用（sp_GetPatientDoctorVisits）の 2 つの子プロシージャを条件付きで呼び出すことで、患者のデータ取得をオーケストレートします。

条件付きロジックと手続き型実行パスに応じて、1 回の実行で最大 4 つの異なる結果セットと、患者が見つかったかどうかを示すステータス整数を返すことができます。

SQL

code_block: <ListValue: [StructValue([('code', 'CREATE OR ALTER PROCEDURE sp_GetPatientSummary\r\n @PatientID INT\r\nAS\r\nBEGIN\r\n SET NOCOUNT ON;\r\n DECLARE @LabReturnValue INT;\r\n\r\n IF NOT EXISTS (SELECT 1 FROM Patient WHERE PatientID = @PatientID) \r\n RETURN 0; \r\n\r\n SELECT PatientID, FirstName, LastName, DateOfBirth FROM Patient WHERE PatientID = @PatientID;\r\n\r\n EXEC @LabReturnValue = sp_GetPatientLabResults @PatientID = @PatientID, @QueryType = 1;\r\n\r\n-- Conditional: If child returned 1, call it again for Result Set #3\r\n IF @LabReturnValue = 1\r\n EXEC sp_GetPatientLabResults @PatientID = @PatientID, @QueryType = 2;\r\n\r\n EXEC sp_GetPatientDoctorVisits @PatientID = @PatientID;\r\n \r\n RETURN 1; -- Success scalar status\r\nEND;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf9352f8d0>)])]>

ターゲット: PostgreSQL の決定的カーソル

PostgreSQL の実行モデルに合わせるため、DMS は SETOF refcursor と明示的なカーソル管理を使用して、元の T-SQL の動作を構造的な PL/pgSQL アーキテクチャにマッピングします。

1. シンプルなトラッキング: ストアドプロシージャの変換

1 つの結果セットのみを生成する子プロシージャ sp_getpatientdoctorvisits について、DMS は標準の PostgreSQL PROCEDURE を作成します。その際、明示的な INOUT refcursor パラメータを使用して、ポインタを呼び出し元に安全に返します。

SQL

code_block: <ListValue: [StructValue([('code', "CREATE PROCEDURE dbo.sp_getpatientdoctorvisits(\r\n _patientid INTEGER, \r\n INOUT result_set_refcursor refcursor\r\n)\r\nLANGUAGE plpgsql\r\nAS $$\r\nBEGIN\r\n sp_getpatientdoctorvisits.result_set_refcursor := NULL;\r\n OPEN result_set_refcursor FOR \r\n SELECT visitid, patientid, doctorname, visitdate, visitnotes\r\n FROM dbo.doctorvisits\r\n WHERE doctorvisits.patientid = sp_getpatientdoctorvisits._patientid\r\n AND doctorvisits.visitdate >= localtimestamp + interval '-6 MON';\r\nEND;\r\n$$;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf92637610>)])]>

2. マルチセットトラッキング: 関数への変換

マスタールーティンと複雑な検査の子ルーティンについては、INOUT パラメータだけではさまざまな出力配列を取り込めません。DMS は、SETOF refcursor を返す PL/pgSQL 関数にこれらを変換します。

変換された sp_getpatientlabresults がカーソルを順番に構築し、最後に「return_value」と明示的に命名された個別のカーソルを動的に開いて、スカラー整数を実行スタックに返す方法に注目してください。

SQL

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE FUNCTION dbo.sp_getpatientlabresults(_patientid INTEGER, _querytype INTEGER)\r\nRETURNS SETOF refcursor\r\nLANGUAGE plpgsql\r\nAS $$\r\nDECLARE rc refcursor; _recordsfound INTEGER := 0;\r\nBEGIN\r\n IF _querytype IN (1, 3) THEN\r\n OPEN rc FOR \r\n SELECT resultid, patientid, testname, testdate, isexception\r\n FROM dbo.labresults\r\n WHERE patientid = _patientid \r\n AND testdate >= localtimestamp - interval '6 months';\r\n RETURN NEXT rc;\r\n\r\n IF EXISTS (\r\n SELECT 1 FROM dbo.labresults \r\n WHERE patientid = _patientid \r\n AND testdate >= localtimestamp - interval '6 months'\r\n ) THEN recordsfound := 1; \r\n END IF;\r\n END IF;\r\n\r\n IF _querytype IN (2, 3) THEN \r\n rc := NULL; -- Reset to generate a new unique cursor name\r\n OPEN rc FOR \r\n SELECT resultid, patientid, testname, testdate, isexception\r\n FROM dbo.labresults\r\n WHERE patientid = _patientid \r\n AND isexception = TRUE \r\n AND testdate >= localtimestamp - interval '2 years';\r\n RETURN NEXT rc;\r\n\r\n IF EXISTS (\r\n SELECT 1 FROM dbo.labresults \r\n WHERE patientid = _patientid \r\n AND isexception = TRUE \r\n AND testdate >= localtimestamp - interval '2 years'\r\n ) THEN \r\n _recordsfound := 1; \r\n END IF;\r\n END IF;\r\n\r\n rc := 'return_value';\r\n OPEN rc FOR SELECT _recordsfound AS return_value;\r\n RETURN NEXT rc;\r\nEND;\r\n$$;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf92637a10>)])]>

プログラムによる出力の解析

移行したルーティンを再びアプリケーションのデータアクセスレイヤに統合する際、QA エンジニアとアプリケーションエンジニアは、実行結果の処理方法を調整する必要があります。呼び出し元のアプリケーションまたはテストハーネスは、標準的な表形式の行を順番に読み取るのではなく、カーソル参照の配列を受け取ります。これをプログラムで処理するには、返された各ポータルからデータを順番に取得する必要があります。DMS は、実行スタックの最後で、明示的に命名された専用の「return_value」カーソルデータセット内にスカラー戻り値を配置することで、このスカラー戻り値を分離します。この構造マッピングに対応できるよう開発チームの体制を整えることで、アプリケーションロジックと検証スクリプトが、多層のレスポンス配列を中断なく正確に解析できるようになります。

移行したコードの実行とテスト

PostgreSQL で移行されたオブジェクトをテストする場合、明示的なトランザクションブロック内で作業する必要があります。PostgreSQL カーソルはトランザクションのライフサイクルにバインドされているため、メモリポータルからデータにアクセスするには、実行コマンドとデータ取得コマンドを 1 つの BEGIN ... COMMIT ブロック内にカプセル化する必要があります。

PostgreSQL 内で患者 3 の複雑なデータセット全体を実行して取得する方法は次のとおりです。

SQL

code_block: <ListValue: [StructValue([('code', 'BEGIN;\r\n\r\n-- 1. Exec the function to initialize and stream back the cursors\r\nSELECT * FROM dbo.sp_getpatientsummary(3) AS summary_cursors; \r\n\r\n-- 2. Fetch data from the sequentially generated anonymous portals\r\nFETCH ALL FROM "<unnamed portal 1>"; -- Patient Demographics\r\nFETCH ALL FROM "<unnamed portal 2>"; -- Lab Results (Query Type 1)\r\nFETCH ALL FROM "<unnamed portal 3>"; -- Lab Results (Query Type 2)\r\nFETCH ALL FROM "<unnamed portal 4>"; -- Doctor Visits\r\n\r\n-- 3. Fetch the named scalar return value tracking cursor\r\nFETCH ALL FROM "return_value";\r\n\r\nCOMMIT;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf91f35290>)])]>

DMS の技術詳解: 結果セットのカウントの仕組み

DMS プロダクトは、予想される結果セットの数と戻り値の存在の可能性を把握するための高度な前処理メカニズムを採用しています。最終的な目標は、すべての SQL Server プロシージャを 3 種類のカテゴリのいずれか（結果セットなし、結果セット 1 つ、複数の動的な結果セット数）にマッピングすることです。

これを正確に実行するために、DMS は詳細な構造分析を行います。

直接結果セット: まず、エンジンがプロシージャのボディ部分をスキャンして、直接結果セットをカウントします。直接結果セットとは、プロシージャ内で直接実行される明示的な SELECT ステートメントです。
動的考慮: ループまたは条件付きの SELECT / EXEC ステートメントを扱う場合は、特別な考慮が必要です。これらの構成要素は本質的に、返される結果セットの数が実行ごとに異なる可能性があることを意味するため、そのプロシージャの数は即座に「動的」としてマークされます。
呼び出しネットワークの構築: 他のストアドプロシージャへの参照を検出した時点のエンジンは、それらの子プロシージャが公開する結果セットの数をまだ把握していません。これを解決するために、DMS は包括的な有向グラフを構築して、プロシージャ間の呼び出し階層全体をモデル化します。
DFS の伝播: この有向ネットワークが完全に構築されて初めて、エンジンは深さ優先探索（DFS）アルゴリズムを実行できます。この DFS トラバーサルでは、固定整数または動的フラグのいずれであっても、結果セットの数が呼び出しチェーンをさかのぼって最上位のプロシージャに体系的に伝播されます。

結果的に、生成されたコードは、外部データセットを返すように、またネストされた実行スタック内で子ルーティンを正しく呼び出すことができるように、正確に変更されます。このグラフベースのアプローチにより精度が保証され、直接再帰と間接再帰の両方を含む、非常に複雑なプロシージャ間のやり取りがシームレスにサポートされます。

まとめ

Google Cloud の Database Migration Service は、結果セットの数に基づいて FUNCTION と PROCEDURE のディシジョンツリーをプログラムで適用することで、構造変換の不確実性を排除します。中核的なビジネスおよび条件付き実行ロジックは完全に保持されますが、アプリケーション接続プールと QA エンジニアが実行結果を処理する方法は変わります。

この自動化されたアーキテクチャについて理解することで、PostgreSQL での Day 2（2 日目からの）運用がシームレスになるよう、検証スクリプトを効果的にマッピングし、データアクセスレイヤを構成できます。

以上で、複数の結果セットを変換する方法を習得できました。早速、Google Cloud で PostgreSQL データベースを活用しましょう。ぜひ、皆様のご体験をお聞かせください。

Google Cloud の $300 分の無料クレジットで Database Migration Service をご利用いただけます。無料で構築を始める

- SQL Server ブラックベルト、Assaf Fraenkel

- シニアソフトウェアエンジニア、Yuval Ben Arie

Spanner Graph で小売商品の検索性能を強化し、データベースのメンテナンス工数半減を達成した Target の取り組み

Thu, 20 Aug 2026 01:10:00 +0000

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

現代の小売環境における買い物客は、高度にパーソナライズされた商品発見体験と、自然で本物らしく、心から役に立つと感じられる会話型アシスタンスを期待しています。今日、優れた商品検索には、商品、カテゴリ、顧客の意図の密接な関係やセマンティックな意味を理解することが求められます。キーワードや基本的なブラウジングだけでは不十分です。

Target でこの作業を担当しているのがゲストプロダクトコンフィデンスプラットフォームチームです。評価、レビュー、AI を活用したデジタルショッピングアシスタントなど、信頼を確立し、購入の意思決定を導く機能を構築する責任を担っています。その好例が、2025 年のホリデーシーズンにオンラインストアと Target アプリにリリースされた Gift Finder チャットエージェントです。このエージェントは、親しみやすい会話を通じて、買い物客がぴったりの商品を見つけるのをサポートします。

このようなリアルタイムのパーソナライズとコンテキストリッチなセマンティック応答をグローバル規模で提供するには、断片化されたデータエコシステムを脱却し、統合型のデータプラットフォームに移行するという重要なアーキテクチャ上の課題があることがわかりました。当社は、高スループットのトランザクションワークロード、高度に接続されたグラフ関係、ベクトル類似度検索、全文キーワード検索をまとめてサポートできるソリューションを必要としていました。

この投稿では、これら 4 つのすべてを実現するうえで Spanner が果たした役割について説明します。

断片化されたアーキテクチャからの脱却

従来の Target のディスカバリーデータエコシステムは、検索と転置インデックス用の Elasticsearch クラスタと、トランザクションデータ用の個別の NoSQL データストアの組み合わせで構成されていました。この断片化されたアーキテクチャは機能はするものの、運用上および技術上の大きな課題を抱えていました。

コンテキストの分断: 検索、ベクトル、トランザクションの各データベースの完全同期は常に課題でした。情報がサイロ化されていることで、コンテキストの欠落、属性間の関係の断絶、クエリ結果の不整合が発生していました。
運用上のオーバーヘッドの増大: 独立したクラスタの管理、検索インデックスのチューニング、複雑なカスタム同期と集計ロジックの処理を実行するには、エンジニアリングチームによる集中的な手動介入が必要でした。
拡張のボトルネック: 小売データドメインを拡張するには、新しいデータベースコレクションの追加、複雑な結合の維持、検出システムとコアトランザクションシステムにおける弱いトランザクション保証への対処が必要でした。
サイロ化されたインテリジェンス: グラフの関係、ベクトル類似度、キーワード検索インデックスを 1 件のトランザクションでクエリする機能が欠如していました。

AI を活用した次世代のゲストエクスペリエンスを構築するには、1 つのプラットフォームに統合する必要がありました。

Spanner Graph でエンタープライズオントロジーを構築

スタンドアロンのベクトルデータベースやニッチなグラフデータベースなど、複数の専用テクノロジーを評価しました。しかし、単一目的のデータベースを追加すると、運用の複雑さとデータ同期パイプラインのパフォーマンスが悪化するだけでした。

最終的に選択した方法が、Spanner Graph を利用してエンタープライズオントロジーを構築することでした。これは「グラフのグラフ」パラダイムであり、生成 AI を活用した大規模なショッピンググラフの構築を可能にします。

データを統合することで、セマンティックデータ、グラフ関係、ベクトルエンベディング、運用トランザクションを 1 つの屋根の下に集約します。これにより、トランザクションの状態とセマンティックインテリジェンスの両方について、Spanner が信頼できる唯一の情報源となります。

当社のハイレベルなアーキテクチャは、以下の 3 つの主要な柱で構成されています。

1. エンタープライズ拡張このレイヤは、当社のエンタープライズ小売カタログをキャプチャし、複数のバックエンドソースから関連するメタデータを集約し、エージェントによるデータ拡充に生成 AI を活用して、取り込む商品データの品質と深さを大幅に向上させます。

2. グラフ、ベクトル、検索の統合ストアSpanner Graph では、複数のデータベース間でデータを移動させるのではなく、エンティティノード、関係エッジ、ベクトルエンベディングを同じデータベースエンジンに保存します。Spanner Graph は、リレーショナルテーブルに対するマルチホップグラフ探索、セマンティックベクトル類似検索、全文キーワードクエリをネイティブにサポートしています。このマルチモデルシナジーはネイティブであるため、脆弱な外部同期パイプラインを介さずに分散ワークロード全体で厳格な ACID トランザクションを実現し、絶対的な正確性を確保できます。

3. オーケストレーションと AI レイヤこのレイヤは、会話型ゲストインターフェースを強化し、Spanner Graph から直接供給される豊富な構造化コンテキストを利用して LLM をグラウンディングします。責任ある AI プロセスを管理し、生成された出力を評価しながら、非常に具体的な商品関係を抽出することで Gift Finder などのツールを強化します。

ダウンタイムなしでスムーズに段階的に移行

当社の検索と見つけやすさのインフラストラクチャは何百万人もの顧客が利用する重要なものであるため、移行にあたってはダウンタイムをゼロにする慎重なアプローチが必要でした。この移行は、4 つの構造化されたフェーズで実行されました。

スキーマとオントロジーのマッピング: Spanner Graph スキーマ内で、商品、カテゴリ、ブランド、顧客の好みなどの特定の小売エンティティと、それらに対応する関係を定義しました。
データ統合と並列リプレイ: ミューテーションベースのデータ統合を並列パイプラインで構築しました。これにより、リアルタイムのトランザクションの更新を継続的にリプレイし、スキーマ変換を適用して、エンベディングを生成し、リアルタイムで Spanner Graph に直接書き込むことができました。
カナリアデプロイ: ライブの読み取りトラフィックを新しい Spanner Graph ベースのプラットフォームに徐々に移行し、実際の小売ワークロードでクエリのパフォーマンス、セマンティックの精度、データベースの安定性を検証しました。
カットオーバーとクリーンアップ: パフォーマンスを徹底的に検証した後、すべての検索と見つけやすさのトラフィックを Spanner に完全に移行し、以前の Elasticsearch スタックを廃止することで、Elasticsearch クラスタのメンテナンスの負担を完全に排除しました。

ビジネスへの影響

Spanner Graph 上で直接構築することで、技術面とビジネス面で測定可能な成果を達成できました。

究極の GraphRAG 基盤: 従来の RAG はフラットなベクトル類似度に依存しているため、たとえば特定のおもちゃと互換性のあるアクセサリーや年齢適合性の照合など、商品間の構造化された関連性を見落としがちです。統合された GraphRAG アーキテクチャ内で深いグラフ探索とセマンティックベクトル検索を組み合わせることで、LLM を高精度のコンテキストでグラウンディングしました。これにはおすすめの関連性を直接改善する効果があり、顧客の満足度とネットプロモータースコアの向上につながりました。

SQL と GQL の相互運用性の統合: Spanner Graph を使用すると、デベロッパーは標準 SQL と GQL（Graph Query Language）を使用して、1 回のクエリで構造化されたリレーショナルカタログデータと接続されたグラフ関係に対して処理を要求できます。これにより、これらのパラダイムを橋渡しするためのデータの重複、レイテンシ、複雑な ETL パイプラインが不要になります。

成長の上限がないサーバーレスのスケーラビリティ: Spanner は、ブラックフライデーやサイバーマンデーなどの小売イベントのピーク時に、予測不可能な大規模なトラフィックの急増を自動的に処理します。Spanner に組み込まれたオートスケーラーがコンピューティング容量を動的に調整し、期間限定のプロモーション特典期間中に発生した高負荷のバーストトラフィックを、パフォーマンスを犠牲にすることなく処理しました。

インフラストラクチャのメンテナンス工数の半減: トランザクション NoSQL データベースと検索インデックスデータベースを 1 つのマネージド Google Cloud サービスに統合することで、別々のデータベースクラスタを維持する運用上の負担がなくなりました。開発者がデータベース管理とインフラストラクチャの維持に費やす時間が 50% 削減され、顧客向けの新しい AI 機能をより迅速に構築してデプロイできるようになりました。

Spanner Graph への移行により、当社の生成 AI ロードマップは加速しました。これは、適切なデータ基盤の構築が提供する価値を証明する究極の例となりました。

AI アプリの強化を目指しているのであれば、まずは、適切なグラフ機能を備えたデータベースを事実上無制限の規模で利用することから始めましょう。Spanner Graph で組織のデータをアクションに変える方法をご確認ください。

- プリンシパルエンジニア Sayanti Dey

- Target 社シニアエンジニアリングマネージャー Kaushik Shelat 氏

Database Operations Agents のご紹介: 自律型データベース管理の未来

Thu, 20 Aug 2026 00:00:00 +0000

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

Google はこのたび、Google Cloud Next ‘26 における Agentic Data Cloud のリリースの一環として、データベース管理を簡素化する 2 つの AI 搭載データベースエージェントを発表しました。具体的には、Day 0 運用（セットアップ、構成、初期デプロイ）のためのデータベースオンボーディングエージェントと、Day 1 および Day 2 運用（モニタリング、トラブルシューティング、継続的なメンテナンスなど）のためのデータベースオブザーバビリティエージェントです。

これらの常時稼働のエージェントは Google の長年の経験を反映しており、Chat、CLI、Google Cloud コンソール、Managed Context Protocol（MCP）サーバーなどの Google のさまざまなサービスだけでなく、普段お使いの統合開発環境（IDE）を含むサードパーティツールにも統合されています。そのため、必要なときに必要な場所でサポートを受けることができます。

これまで、データベースの構築や管理には手動でのアーキテクチャ設計、カスタムスクリプト、そしてバラバラのツールを組み合わせる作業がつきものでした。データベースのプロビジョニング、スキーマ設計、インデックス構成、クエリのチューニング、さらにはパフォーマンスのモニタリングまでをチームが担い、アプリケーションの要求の変化に合わせてテストと最適化のサイクルを頻繁に繰り返す必要がありました。この手法でも運用は可能ですが、データベースのライフサイクル全体を通じて、高度な技術力が不可欠なだけでなく、絶えず運用管理にリソースを割かなければなりません。たとえば、将来的なスケーラビリティが損なわれることを懸念して、開発者がアップデートに慎重になりすぎてしまうことは珍しくありません。また、アプリケーションの遅延が発生した際も、原因となる特定のクエリやリソースの制約を突き止めるために、手作業での調査やトラブルシューティングに何時間も費やしてしまうことがよくあります。

インテリジェントな AI 搭載エージェントは、ワークロードに適したデータベースタイプの推奨から、異常の検出、適切な構成の推奨、クエリの最適化、運用効率を向上させるための実用的な分析情報の提供まで、多くのタスクを自動化することでデータベースのライフサイクル管理を簡素化します。これらの機能を必要なワークフローに直接組み込めば、運用オーバーヘッドを削減しつつ、データベースの構築から最適化までをより効率的に行えるようになります。

それでは、これらの新しいデータベースエージェントについて詳しく見ていきましょう。

データベースオブザーバビリティエージェント: 診断から修復まで

オブザーバビリティエージェントは、サイト信頼性エンジニア（SRE）、DevOps プロフェッショナル、データベース管理者、開発者がシンプルな自然言語プロンプトを使用して複雑な問題を診断し、修復できるよう支援します。

運用規模が拡大するにつれて、クエリのホットスポットやロック競合といった捉えにくい問題の特定は、コストのかかる大きな負担となります。データベースオブザーバビリティエージェントは、Google の専門知識と Gemini の推論機能を活用して、こうした課題を解決します。データベースインサイト、Cloud Monitoring、Cloud Logging、Cloud Trace などの複数のソースにわたるテレメトリーを自動的に接続することで、数分で明確な根本原因分析を提供できます。

また、単に「原因」を特定するだけでなく、見つかった問題を解決するための推奨される対応を提案し、ユーザーの承認を得たうえで検証済みのアクションを実行することも可能です。たとえば、ボトルネックが検出された場合、エージェントは「Cloud SQL インスタンスの接続プールを有効にする」といった提案を行い、変更を適用する前にその根拠と予想される影響を提示します。主な機能には、次のようなものがあります。

フリートレベルのトラブルシューティング: オブザーバビリティエージェントはデータベースセンターと統合されているため、Gemini Chat を使用して「過去 7 日間にフリート内で最も CPU を消費したデータベースはどれ？」といったフリート全体に関する複雑な質問を投げかけ、フリート全体を網羅した要約分析を受け取ることができます。
プロダクト内調査: データベーステレメトリー、Cloud Monitoring、Cloud Logging、Cloud Trace など、多岐にわたるデータソースの複雑なテレメトリーを関連付けて、レイテンシの急増やロック競合などの問題をピンポイントで特定します（一部のお客様を対象にプレビュー版を提供中）。
検証済みの修復: 単に問題を特定するだけでなく、的確な推奨事項を提案します。また、ユーザーの承認を得たうえで Cloud SQL インスタンスのインデックスの追加といった検証済みのアクションを実行することもできます（一部のお客様を対象にプレビュー版を提供中）。
MCP ツール: オブザーバビリティエージェントは、システム指標、クエリ指標、フリートインベントリ、検出された問題などのデータを活用して分析情報を導き出します。これらは、データベースインサイト MCP サーバーとデータベースセンター MCP サーバーを介して MCP ツールとしても利用できます。

ワークフローに合わせて統合可能

こうしたデータベースオブザーバビリティエージェントの機能を、既存のデータベース管理プロセスに直接組み込んで利用することができます。このエージェントは、以下のような機能を提供します。

Cloud Assist チャット: 「上位の Cloud SQL インスタンスの CPU 使用率の傾向は？」といった質問を自然言語で投げかけるだけで、グラフ付きの要約分析が提示されます。その後、チャットウィンドウ内でそのまま問題の調査を開始し、根本原因の分析や修復策の確認ができます。

プロダクト内での調査: コンソールの関連するデータベースページで Gemini Cloud Assist を使用して、コンテキストに沿って問題を調査し、修正できます。

デベロッパーツール: Antigravity または任意の IDE を通してエージェントの機能を利用できます。Google が提供する豊富なオブザーバビリティ MCP ツールによって、その機能はさらに強化されています。これらのツールはすべて、Google リモート MCP サーバーで利用可能です。これらを組み合わせることで、開発者は仮想のデータベース管理者に頼りながら、すべての最適化作業を IDE 内で完結できるようになります。

複数のマネージドデータベースに対応

オブザーバビリティエージェントは、データベースクエリに対する回答を得る、データベース指標に瞬時にアクセスする、AI による診断を利用して複雑な問題を解決するといった目的に活用できます。以下のような、幅広い Google Cloud データベースの問題に対応可能です。

Cloud SQL: すべての Cloud SQL データベースエンジンにおけるデータベースインスタンスの負荷、クエリのパフォーマンス、接続の問題をトラブルシューティングして最適化します。Cloud SQL for PostgreSQL では、エージェントを活用してよくあるデータベースの問題をトラブルシューティングできます。

他の対応データベースや問題の種類でも同様に、エージェントを活用して問題の特定、根本原因の突き止め、是正措置を行えます。

Spanner: Spanner において最も一般的なトラブルシューティングのシナリオは、読み取りと書き込みのレイテンシの最適化です。ホットスポットからロック競合まで、幅広いシナリオに対応するエージェントを活用して数分でトラブルシューティングできます。
AlloyDB: データベースインスタンスの負荷、クエリのパフォーマンス、レプリカラグの問題をトラブルシューティングして最適化します。
Bigtable: 読み取りと書き込みのレイテンシを診断して最適化し、明確で実用的な推奨事項を提示します。

データベースオンボーディングエージェント

新しいデータベースオンボーディングエージェントは、データベースの選定プロセスにおける心強いパートナーです。ドキュメントを何時間もかけて読まなくても、アプリケーションの要件を自然言語でエージェントに説明するだけで、IOPS、レイテンシ制限、レプリケーションラグなどの技術的な指標を踏まえた的確な推奨事項を導き出すことができます。データベースオンボーディングエージェントの機能は、Gemini とのチャットインターフェースから直接ご利用いただけます。データベースオンボーディングエージェントを使用すると、以下のメリットがあります。

データベースソリューションの推奨: ワークロードのパフォーマンス、スケール、データ型、信頼性に関するユーザー要件を分析し、最適な Google Cloud マネージドデータベースサービス（Cloud SQL、Spanner、AlloyDB など）を提案します。
スマートな推奨事項: エージェントが要件に基づく根拠（高可用性構成に AlloyDB を推奨するなど）を提示するため、確信を持ってサービスを選択できます。
構成の効率化: サービスを選択すると、エージェントが設定に必要なコマンドを生成します。生成されたコマンドを実行するだけで、データベースインスタンスをプロビジョニングし、適切な機能を構成してデプロイできます。

使ってみる

データベースオブザーバビリティエージェントとオンボーディングエージェントの機能は、AlloyDB、Bigtable、Cloud SQL（PostgreSQL、MySQL、SQL Server）、Firestore、Memorystore、Spanner などの幅広いサービスでご利用いただけます。現在は Gemini Cloud Assist 経由で提供されています。AlloyDB、Cloud SQL、Spanner の AI を活用したトラブルシューティングと Gemini Chat についてご確認ください。詳しくは、Gemini Cloud Assist のページをご覧ください。

- グループプロダクトマネージャー、Niranjan Shivprasad

- シニアプロダクトマネージャー、Nitesh Mehta

パブリックデータとプライベートデータを統合: 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

AlloyDB に追加されたグループ認証により、エンタープライズ規模の運用と AI エージェントのセキュリティを強化

Thu, 06 Aug 2026 03:00:00 +0000

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

データベースセキュリティは従来、開発者が求める緻密なアクセス制御と、数千もの個別データベースパスワードの管理に伴う運用オーバーヘッドとの間の「危ういバランス」に頼ってきました。AI エージェントのアクセス管理、静的認証情報のローテーション、従業員のオンボーディングとオフボーディングの処理、アクセスログの監査など、パスワードは依然として運用上の負担であり、潜在的なセキュリティの脆弱性となっています。

Google Cloud の目標は、データベースアクセスを透過的でセキュア、かつパスワード不要なものにすることです。

Google はその取り組みにおいて重要な一歩を踏み出します。このたび、AlloyDB の Identity and Access Management（IAM）グループ認証がプレビュー版で利用可能になりました。この機能により、エンタープライズワークロードに ID 主導のアクセス制御がもたらされます。

Cloud SQL のお客様は、すでにこの認証パターンを導入して大きな成果を上げており、今回のリリースにより、両サービスでセキュリティ体制が統一されることになります。

個々のスケールに関する問題

長年にわたり、Cloud SQL と AlloyDB は、ネイティブな IAM 認証を使用して、個々の Google Cloud ID をデータベースユーザーに直接マッピングしてきました。しかし、エンタープライズ規模においては、アクセスを個別に管理すると、複雑さが大幅に増す可能性があります。

グループベースの管理を行わない場合、数百のインスタンスと数千のユーザーにスケールすると、次のような課題が生じます。

オンボーディングのボトルネック: 新しいチームメンバーごとにデータベースユーザーのプロビジョニングが必要になります。
オフボーディングのリスク: 分散データベース環境全体で従業員のアクセス権を完全に削除するには、監査が複雑になる可能性があります。
ポリシーの逸脱: 開発、ステージング、本番環境のシステム間で同一の権限を維持すると、エラーが発生しやすくなります。

このような課題に直面すると、アプリケーション全体にサービスを提供するために、単一の強力なユーザーアカウントまたはサービスアカウントを使用したいという誘惑に駆られます。しかし、このような強力なアプリケーションアカウントのアクセスを単純化しすぎると、リスクにさらされ、詳細な監査機能が失われるという代償が伴います。

エージェント型 AI の未来を守る

規模に関する課題は、もはや人間のユーザーだけにとどまりません。組織がデプロイする AI エージェントの数が増えるにつれて、データベースの ID とアクセス制御の管理はより複雑になります。

AI エージェントが汎用の共有アカウントや広範なサービスアカウントを使用してデータベースに接続する場合、混乱した使節の問題を引き起こすリスクがあります。ユーザーの ID を引き継ぐ代わりに、過剰な権限を持つ認証情報を使用すると、エージェントは、アクションをリクエストしたエンドユーザーが閲覧を許可されている範囲を超えてデータにアクセスしたり、データを変更したりする可能性があります。さらに重要なことに、アクションが汎用サービスアカウントに紐付けられるため、監査ログから個別の責任の所在が失われてしまいます。

きめ細かい認証は、このリスクを軽減するのに役立ちます。エージェントはエンドユーザーの特定のアイデンティティと認証スコープをデータベース層まで引き渡すことができるため、クエリはユーザーに代わって実行され、データアクセスはエンドユーザーが許可されているオブジェクトのみに制限されます。

AI エージェントを介してユーザーグループ ID を AlloyDB に渡すことで、データベースはアクセスを承認し、正確な監査証跡を記録できます。

IAM グループ認証は、このアーキテクチャを簡素化します。セキュリティチームは、エージェントとユーザーの組み合わせごとにマイクロ権限を管理する代わりに、最大 200 個の機能的な Google グループ（financial-agents@company.com や regional-analysts@company.com など）を定義できます。Google Cloud のマネージドデータベースインフラストラクチャは、ユーザーのグループコンテキストを検証し、データベースまたはテーブルのレベルでデータアクセスが承認されるようにします。また、監査ログには、アクセスされたデータ、変更されたデータ、誰の代理として行われたかが正確に記録されます。

デジタルリーダーにとっての実証された価値

一元化された ID の原則を採用することで、すでに運用スピードを向上させている企業があります。大手プラットフォームポイントプログラムの Bilt は、Google の統合アプローチを使用して、大規模なデータベース環境のセキュリティ強化に役立てています。

「AlloyDB のグループベースの IAM と、自動化されたグループ管理および Privileged Access Manager（PAM）の権限を組み合わせることで、共有認証情報のリスクを完全に排除しました。データベースとロールのプロビジョニングは、初日から完全にテンプレート化されているため、エンジニアは必要なときに必要なデータにのみ安全にアクセスできます」と、Bilt の CTO である Kosta Krauth 氏は述べています。

パスワードレスアクセスのための統合ブループリント

今回のリリースにより、Google Cloud は Cloud SQL と AlloyDB の両方にわたるアクセス制御の統合アプローチを提供します。組織は、リレーショナルデータベースポートフォリオ全体に対して、標準化された多層防御アクセス戦略を適用できるようになりました。

IAM グループ認証を VPC Service Controls、組織のポリシー、IAM 条件、Private Service Connect などの機能と組み合わせることで、セキュリティチームは、人間のエンジニアによるアクセスか自律型 AI エージェントによるアクセスかを問わず、データベースアクセスが、検証済みの企業 ID とセキュアなネットワーク境界にバインドされるようにすることができます。

ゼロトラストデータベースの未来に向けて

セキュリティによって、エンジニアリングの速度とコンプライアンスの間に妥協が生じるべきではありません。AlloyDB と、Cloud Identity および Workforce Identity 連携を統合することで、データベース管理の摩擦を解消し、よりセキュアなアーキテクチャの実装を支援します。

この機能を今すぐお試しになり、グループベースのデータベースロールを設定する方法をご確認ください。セキュリティとコンプライアンスに関するその他の推奨事項とベストプラクティスについては、ドキュメントをご覧ください。

- プロダクトマネージャー、Bjoern Rost

- プロダクトマネージャー、Alok Srivastava

データベース

AlloyDB と Memorystore for Valkey で AI エージェントの長期記憶を実装する方法

ステートフルなワークフローは、LLM のステートレスな性質と本質的に矛盾する

2 層メモリ アーキテクチャの実装

4 種類のメモリについて

階層型メモリ アーキテクチャのブループリント

ビジネスへの影響と費用対効果

AlloyDB AI の核となる技術的メリット

主な実装パターン

エンタープライズ ガバナンスとマルチテナント セキュリティ

まとめと次のステップ

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

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

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

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

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

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

使ってみる

Apache Iceberg を自動管理して大規模展開する: Spanner を活用した Lakehouse ランタイム カタログ

レイクハウスのマネージド カタログが直面する課題

Lakehouse ランタイム カタログ

Lakehouse ランタイム カタログの原動力

分析と運用のワークロードを組み合わせる

ボーダーレスな Lakehouse にモダナイズ

AlloyDB: ハイブリッド検索のための統合データベース エンジン

複数ステップのワークフローの問題

AlloyDB でハイブリッド検索アーキテクチャを簡素化

結果: パフォーマンスと運用の簡素化

FTS のパフォーマンスを向上: RUM 拡張機能

測定可能な成果とインテグレーション

BM25 インデックスの導入: 最新のランキング標準

外部検索: 外部データラッパーで汎用性を拡大

AI を活用した検索のための統合アーキテクチャ

デモ動画のご紹介

ご利用にあたって

AlloyDB がエージェント向け PostgreSQL を提供: ワークロードを完全に分離し、エージェント規模でリアルタイム データを処理

重要である理由

AlloyDB 独自の PostgreSQL エージェント アーキテクチャ

提供状況

エージェントの時代における妥協のない新しいデータベース アーキテクチャ

真のエージェント型データベース アーキテクチャに必要な 3 つの原則

AlloyDB のエージェント アーキテクチャ

既存のアーキテクチャが 3 つの原則をすべて満たせない理由

分離された共有ストレージ サーバー

共有ブロック サーバーを使用したオブジェクト ストレージ

既存アーキテクチャの評価

AlloyDB をスタック全体でどのように構築したか

AlloyDB のエージェント型データベース アーキテクチャの評価

3 つの原則すべてを設計に組み込む

本番環境に影響を与えることなく、エージェントにライブデータを提供

オーケー: AlloyDB と Database Migration Service で「止められない基幹システム」を移行し、データドリブンな価値創出を加速

ビジネスの急成長を受けて高まった、2 つの基幹データベース刷新の必要性

AlloyDB の採用により、業務の根幹を支えるデータベースの移行と基盤統一を実現

Gemini や AlloyDB AI も活用しながら、DX と新たな価値創出を追求

AlloyDB と Cloud SQL のネイティブ BM25 ランキングを発表

pg_textsearch を使用する理由

全文検索の例

AlloyDB ハイブリッド検索の例

Cloud SQL ハイブリッド検索の例

実際の操作を見る

関連リソース

電気通信事業者の自律性の拡張: Distributed GraphFlow を使用したグラフ ニューラル ネットワークの活用

基盤: Spanner Graph 上のデジタルツイン

ML レイヤ: Distributed Graph Flow（DGF）

ユースケース

シナリオ: GNN と DGF を使用した根本原因分析

使ってみる

M4N VM ファミリーの一般提供を開始: I/O およびメモリ バウンド ワークロードでコアあたり最高の IOPS とスループットを実現

要求の厳しいワークロードに対応

Oracle のライセンス費用を最適化

お客様の声

新機能: M4N で大規模なデータレイヤをスケール

M4N のマシンタイプと仕様

使ってみる

AlloyDB Omni RPM オーケストレーターを使用するエンタープライズ グレードの PostgreSQL の一般提供を開始

セルフマネージド データベースを運用する理由

柔軟なリファレンス アーキテクチャ

高可用性と読み取りのスケーラビリティ

データ保護とセキュリティ

データベース運用

2 層メモリアーキテクチャの実装

階層型メモリアーキテクチャのブループリント

エンタープライズガバナンスとマルチテナントセキュリティ

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

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

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

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

Apache Iceberg を自動管理して大規模展開する: Spanner を活用した Lakehouse ランタイムカタログ

レイクハウスのマネージドカタログが直面する課題

Lakehouse ランタイムカタログ

Lakehouse ランタイムカタログの原動力

AlloyDB: ハイブリッド検索のための統合データベースエンジン

AlloyDB がエージェント向け PostgreSQL を提供: ワークロードを完全に分離し、エージェント規模でリアルタイムデータを処理

AlloyDB 独自の PostgreSQL エージェントアーキテクチャ

エージェントの時代における妥協のない新しいデータベースアーキテクチャ

真のエージェント型データベースアーキテクチャに必要な 3 つの原則

AlloyDB のエージェントアーキテクチャ

分離された共有ストレージサーバー

共有ブロックサーバーを使用したオブジェクトストレージ

AlloyDB のエージェント型データベースアーキテクチャの評価

電気通信事業者の自律性の拡張: Distributed GraphFlow を使用したグラフニューラルネットワークの活用

M4N VM ファミリーの一般提供を開始: I/O およびメモリバウンドワークロードでコアあたり最高の IOPS とスループットを実現

AlloyDB Omni RPM オーケストレーターを使用するエンタープライズグレードの PostgreSQL の一般提供を開始

セルフマネージドデータベースを運用する理由

柔軟なリファレンスアーキテクチャ

ベストプラクティス

メジャーがサポートされるようになった BigQuery Graph を使用して、信頼できるエージェントワークロードを実現

BigQuery Studio でグラフインテリジェンスを民主化

ストアドプロシージャの変換に関する課題

1. シンプルなトラッキング: ストアドプロシージャの変換

2. マルチセットトラッキング: 関数への変換

Spanner Graph でエンタープライズオントロジーを構築

データベースオブザーバビリティエージェント: 診断から修復まで

複数のマネージドデータベースに対応

データベースオンボーディングエージェント

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

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

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

デジタルリーダーにとっての実証された価値

パスワードレスアクセスのための統合ブループリント

ゼロトラストデータベースの未来に向けて