データベース

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 AI で PostgreSQL の多言語全文検索における制限を解消する方法

Mon, 03 Aug 2026 02:00:00 +0000

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

AlloyDB は、いくつかの世界最大規模の組織において、エンタープライズグレードの検索を強化し、テキスト検索、ベクトル検索、キーワード検索をシンプルなランク付けされた SQL クエリに組み合わせる堅牢なハイブリッド検索機能を提供しています。また、最近リリースされた RUM インデックスのサポートにより、AlloyDB のお客様はさらに強力な全文検索機能をすぐに利用できるようになりました。

しかし、データベース開発者は、中国語、日本語、韓国語などの表語文字言語の連続するテキストをインデックス化する際に、従来の空白ベースのトークン化は機能しないという制限に直面しています。Gemini の多言語機能を使用すると、これらの言語のテキストをインテリジェントに解析して、高度な単語分割とストップワードの削除を実装できますが、大規模なデータセットで行単位の API 呼び出しをオーケストレートすると、処理が遅く、脆弱なものになります。AlloyDB AI 関数を使用すれば、Gemini モデルが持つ広範な知識をデータベースにネイティブに統合できるため、複雑な ETL パイプラインの管理オーバーヘッドなしで、表語文字言語の全文検索を高い精度で実行できるようになります。

連続したテキストと表語文字言語

このネイティブ統合が大きな進歩であることを理解するには、まずテキスト検索の基本的な仕組みと、連続したテキストの処理には従来のインデックス手法が機能しない理由を確認する必要があります。

PostgreSQL で効果的な全文検索インデックスを構築するには、エンジンが to_tsvector 関数を使用してテキストを解析し、検索トークン（語彙素）に分割する必要があります。simple や english などの標準的なテキスト検索構成では、デフォルトで単語が空白で区切られていると想定されます。データベースエンジンは、これらの空白位置で入力文字列を分割し、検索語句を抽出します。

しかし、中国語などの表語文字言語では、単語の間に空白は使用されません。単語は連続して記述され、境界を示すのは句読点のみです。そのため、標準の PostgreSQL パーサーでは個々のキーワードを抽出できません。代わりに、文全体や長い句を 1 つの連続した語彙素として扱います。

たとえば、入力文字列が「你们研究所有十个图书馆」（研究所には図書館が 10 館あります）であるとします。

この文字列を to_tsvector('simple', ...) に渡すと、空白がないため、「你们研究所有十个图书馆」という 1 つの長い語彙素が生成されます。

そのため、「研究所」または「图书馆」（図書館）を検索しても、一致は返されません。キーワードが長い文字列の中に埋め込まれているため、長い文字列を正確に指定して検索しなければ、結果は得られません。

従来の方法とその限界

従来のツールやパイプラインを使用してこの問題を解決しようとすると、どちらを使用した場合でも、大きな運用上の摩擦や精度の限界が生じます。

サードパーティのデータベース拡張機能: zhparser や pg_jieba などの拡張機能は、PostgreSQL に中国語トークン化機能を追加します。ただし、これらの機能は、フルマネージドデータベース環境ではサポートされていないことがほとんどです。また、定義済みの固定の辞書に依存しているため、最新の専門用語、ブランド名、文脈に依存する用語を正しく解析できないことがよくあります。
外部の前処理パイプライン: テキストを外部アプリケーション（jieba や spaCy を実行する Python マイクロサービスなど）にエクスポートし、スペースを挿入してデータベースに保存します。このパターンでは、データベース層外にデータを移動するため、ETL が大幅に複雑化し、ネットワークレイテンシが発生し、データ漏洩のリスクが高まります。
ルールベースおよび辞書を利用した分割では不十分: 従来のトークナイザーは、固定の辞書と手動でコーディングされた構文ルールに依存してテキストを分割しますが、セマンティックな曖昧さにより、まったく同じ文字シーケンスでも、コンテキストに応じて分割方法を変えることが必要となるため、それを解消するのは困難です。正確な分割を行うには、Gemini のような大規模言語モデルが有する世界中の知識とコンテキストインテリジェンスが必要です。

Gemini を使用したデータベース内での前処理

AlloyDB AI では、ai.generate() などのネイティブなデータベース内 AI 関数が導入されているため、これらの回避策は必要はなく、その限界に制限されることもありません。SQL から直接 Gemini を呼び出すことができるため、データとインテリジェンスは 1 箇所に保持されます。

このアプローチには、主に 3 つの利点があります。

データの移動なし: テキストの前処理と分割はすべて、データベースエンジン内で直接行われます。これにより、ネットワークレイテンシが最小限に抑えられ、データはデータベースの境界内で保護されます。
データベース内インテリジェンス: 外部マイクロサービスやオーケストレーションフレームワークを構築、デプロイ、保守する必要はありません。モデルの呼び出しは、データベースエンジンによりネイティブに調整されます。
ストアドプロシージャベースのバッチ処理: 配列集計が組み込まれた PL/pgSQL ストアドプロシージャを使用すると、行を並列バッチで処理し、GENERATE_SERIES を使用して結果を安全に展開して、各バッチを即座に commit できます。これにより、大規模なテーブルを処理する場合でも、データベースのメモリ枯渇や行ロックの競合が回避され、安定した高パフォーマンスの実行を実現できます。

セマンティック単語分割の実装

このソリューションを実装するために、元のコンテンツ、分割されたテキスト、検索ベクトル、ベクトルエンベディングをまとめて保存するデータベーステーブルを作成します。

code_block: <ListValue: [StructValue([('code', "CREATE TABLE documents (\r\n id SERIAL PRIMARY KEY,\r\n title TEXT NOT NULL,\r\n original_content TEXT NOT NULL,\r\n content_segmented TEXT,\r\n search_vector tsvector GENERATED ALWAYS AS (to_tsvector('english', content_segmented)) STORED,\r\n embedding vector(3072) GENERATED ALWAYS AS (embedding('gemini-embedding-001', content_segmented)) STORED\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7d0370>)])]>

search_vector と embedding を生成された列として定義することにより、content_segmented 列が更新されるたびに、AlloyDB で全文検索インデックスとベクトルエンベディングの両方が自動的に更新されます。これにより、アプリケーション側のロジックが 1 つの UPDATE ステートメントに削減されます。

ステップ 1: ドキュメントのバッチ分割

AlloyDB AI のドキュメントでは、大規模なデータセット（10,000 行から数百万行）を扱う場合、メモリのボトルネックを回避するために、カーソルベースの処理を使用することが推奨されていますが、

ドキュメントのカーソル例は、INSERT を使用して新しい空のテーブルにテキストをストリーミングする、追加専用の演算に重点を置いています。このブログ投稿のユースケースでは、ライブの documents テーブルでインプレース UPDATE を行う必要があります。標準的な匿名ブロック（DO $$）で未加工のカーソルループを使用してこれを実装すると、本番環境で発生する可能性のある重大なリスクがあります。ライブアプリケーションをフリーズさせる過剰な行ロック、ネットワークの障害が発生した場合のロールバックリスク、並列カーソルが同期しなくなるアライメントリスクの 3 つです。

これらのリスクを軽減し、パフォーマンスを向上させるために、高スループットの配列ベースのバッチ処理を実行するよう構成されたストアドプロシージャを使用します。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE PROCEDURE segment_all_documents(p_batch_size INT DEFAULT 100)\r\nLANGUAGE plpgsql AS $$\r\nDECLARE\r\n v_processed_count INT;\r\nBEGIN\r\n LOOP\r\n -- 1. Grab a single isolated batch, aggregate into arrays, and call Gemini.\r\n -- We explicitly ORDER BY id during aggregation to guarantee the arrays match perfectly.\r\n WITH batch_raw AS (\r\n SELECT id, original_content\r\n FROM documents\r\n WHERE content_segmented IS NULL OR content_segmented = ''\r\n ORDER BY id\r\n LIMIT p_batch_size\r\n ),\r\n batch_processed AS (\r\n SELECT \r\n ARRAY_AGG(id ORDER BY id) AS target_ids,\r\n ai.generate(\r\n prompts => ARRAY_AGG('Perform Chinese word segmentation (分词) on the provided text to prepare it for full-text search indexing.\r\nRules:\r\n- Insert a single space between every atomic, meaningful word.\r\n- Separate all punctuation marks (both full-width and half-width) with spaces.\r\n- Preserve the original structure, line breaks, and non-Chinese characters (e.g., English words, numbers).\r\n- Output ONLY the processed text. Do not include any greetings, explanations, or formatting wrappers like markdown code blocks unless they exist in the original text.\r\nText to process: ' || original_content ORDER BY id),\r\n model_id => 'gemini-2.5-flash-lite'\r\n ) AS ai_outputs\r\n FROM batch_raw\r\n ),\r\n -- 2. Use GENERATE_SERIES to unpack the paired array indexes safely\r\n unpivoted_results AS (\r\n SELECT \r\n b.target_ids[i] AS doc_id,\r\n b.ai_outputs[i] AS segmented_text\r\n FROM batch_processed b,\r\n GENERATE_SERIES(1, COALESCE(ARRAY_LENGTH(b.target_ids, 1), 0)) i\r\n )\r\n -- 3. Execute the batch update for this chunk\r\n UPDATE documents d\r\n SET content_segmented = r.segmented_text\r\n FROM unpivoted_results r\r\n WHERE d.id = r.doc_id;\r\n\r\n -- Check how many rows were updated in this pass\r\n GET DIAGNOSTICS v_processed_count = ROW_COUNT;\r\n\r\n -- If the update affected 0 rows, it means the whole table is finished\r\n EXIT WHEN v_processed_count = 0;\r\n\r\n -- 4. Commit immediately to save progress and release row locks!\r\n COMMIT;\r\n \r\n RAISE NOTICE 'Successfully processed and committed a batch of % rows.', v_processed_count;\r\n END LOOP;\r\nEND $$;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7d0eb0>)])]>

テーブル全体に対してこの前処理パイプラインを実行するには、ストアドプロシージャを呼び出します。

code_block: <ListValue: [StructValue([('code', 'CALL segment_all_documents(100);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7d0be0>)])]>

このストアドプロシージャを使用するアプローチには、本番環境での課題を直接解決する次の 3 つの利点があります。

配列の並列集計（シーケンスのボトルネックを解消）: バッチを配列に集計し、配列を指定して ai.generate(prompts => ...) を呼び出すことで、AlloyDB がモデルのリクエストをバッチ処理し、並列実行します。これは、行を 1 つずつ順に処理するよりも高速です。
インデックスベースの安全な展開（カーソルの同期ずれを解決）: GENERATE_SERIES を使用して配列インデックスを展開すると、モデル出力が正しいドキュメント ID にマッピングされ、並列ストリームの同期ずれが発生するリスクが軽減されます。
即時 commit とロック解除（ブロッキングとロールバックのリスクを解消）: COMMIT; を使用して各ループイテレーションの最後にトランザクションを commit することは、重要な最適化です。進行状況がすぐにディスクに保存され、行ロックが解除されるため、トランザクションの長時間実行によりライブアプリケーションがフリーズするのを防ぎ、ネットワーク障害によって数時間分の作業がロールバックされないようにします。

このパイプラインを実行すると、上記の例の文は content_segmented に「你们研究所有十个图书馆」として保存されます。

ステップ 2: simple と english の選択

生成された tsvector 列を定義する際は、適切な PostgreSQL テキスト検索構成を選択する必要があります。この選択はデータセットによって異なります。

simple を使用する場合: データベースに中国語のテキストのみが含まれている場合は、simple 構成が最適です。この構成ではテキストが小文字に変換されますが、ステミングやデフォルトのストップワードの削除は実行されません。モデルのプロンプトでセマンティック分割とカスタムストップワードフィルタリングが処理されるため、simple 構成は、それ以上の変更を加えることなく、モデルの最適化された出力に直接マッピングされます。
english を使用する場合: 最新のエンタープライズアプリケーションでは、中国語のドキュメントやユーザーのクエリに、英単語（商品コード、ブランド名、技術用語など）が含まれていることがよくあります。これらのバイリンガルシナリオでは、english 構成の方が優れています。英語の Porter ステマーは、非 ASCII の中国語文字は語彙素としてそのまま残しながら、英単語を自動的に正規化（例: 「running」を「run」にステミング）し、一般的な英語のストップワード（「the」、「and」）をフィルタリングします。これにより、個別の列や複雑なルーティングロジックを必要とせずに、バイリンガル検索機能を統合できます。

ステップ 3: クエリ時の前処理

ドキュメントコンテンツの分割は、処理の半分にすぎません。インデックス化されたデータと一致させるには、入力された検索クエリを、同じ Gemini ベースのセグメンテーションロジックを使用して前処理する必要があります。

検索の精度を向上させるため、これをさらに一歩進めます。モデルをインテリジェントなストップワードフィルタとして機能させ、検索結果に不要な要素を追加する価値の低い文法的なノイズを取り除くよう指示できます。

文法助詞（例: 的、了）
代名詞（例: 你、我们）
比較語（例: 比、最）
疑問詞（例: 怎么、为什么）

たとえば、SQL クエリを使用して、ユーザーのクエリをその場で処理できます。

code_block: <ListValue: [StructValue([('code', "SELECT ai.generate(\r\n '提供されたテキストに対して中国語の単語分割（分词）を実行してください。\r\n さらに、助詞（例: 的、了）、代名詞（例: 你、我们）、比較語（例: 比、最）、疑問詞（例: 怎么、为什么）などの価値の低い文法的なノイズを削除してください。\r\n ルールは次のとおりです。\r\n - 残りのテキストで、意味のある最小単位の単語の間に半角スペースを 1 つ挿入する。\r\n - 処理されたキーワードのみを出力する。挨拶や説明は含めない。\r\n 処理するクエリ: 你们研究所的图书馆在哪里？'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7d0cd0>)])]>

モデルはこのクエリを処理し、キーワード文字列「研究所图书馆」を返します。

ステップ 4: RUM で検索を実行する

ドキュメントを分割してインデックス化したら、生成された search_vector 列に RUM インデックスを作成できます。RUM インデックスは、語彙素の位置を直接保存するインデックスタイプです。これにより、AlloyDB は検索の関連性と単語の距離をインデックス内で直接計算できるようになり、従来の GIN インデックスで必要だった低速の再スキャン操作を回避できます。

code_block: <ListValue: [StructValue([('code', 'CREATE INDEX idx_docs_rum\r\nON documents\r\nUSING rum (search_vector rum_tsvector_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7d0e50>)])]>

検索を実行するには、前処理されたクエリ文字列（「研究所图书馆」）を plainto_tsquery を使用して検索クエリに変換し、RUM インデックスに対して実行します。RUM 距離演算子（<=>）を使用すると、結果を関連度順に並べ替えることができます。

code_block: <ListValue: [StructValue([('code', "SELECT id, title, original_content,\r\n search_vector <=> plainto_tsquery('english', '研究所 & 图书馆') AS distance\r\nFROM documents\r\nWHERE search_vector @@ plainto_tsquery('english', '研究所 & 图书馆')\r\nORDER BY distance ASC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7d0b50>)])]>

RUM インデックスは距離スコアを直接計算するため、このクエリは効率的に実行され、関連する一致が数ミリ秒で返されます。

ハイブリッド検索への拡張

キーワードベースのテキスト検索は、完全一致を見つけるには優れていますが、異なる用語を使用している関連ドキュメントを見逃す可能性があります。これを解決するには、多言語対応の gemini-embedding-001 モデルを使用して、分割された全文の検索とセマンティックベクトル検索を組み合わせます。ハイブリッド検索と呼ばれるこのパターンでは、語彙的にも意味的にも関連する結果が取得されます。

AlloyDB を使用すると、ハイブリッド検索を簡単に実行できます。embedding 列に ScaNN インデックス（Google のベクトルインデックス技術）を作成し、RUM インデックスと組み合わせることができます。

ScaNN インデックスの作成

ベクトル検索を高速化するために、embedding 列に ScaNN インデックスを作成します。

code_block: <ListValue: [StructValue([('code', 'CREATE EXTENSION IF NOT EXISTS alloydb_scann;\r\n\r\nCREATE INDEX idx_docs_scann\r\nON documents\r\nUSING scann (embedding cosine);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7d0e80>)])]>

ハイブリッド検索クエリの実行

ベクトル検索の結果とテキスト検索の結果を組み合わせるには、Reciprocal Rank Fusion（RRF）を実装する SQL クエリを使用できます。RRF は、ランクベースのアルゴリズムの一種で、複数の検索結果リストを 1 つの統合リストにマージするために、個々のリストにおけるドキュメントのランクに基づいて、各ドキュメントにスコアを割り当てます。

次のクエリは、共通テーブル式（CTE）を使用して両方の検索を並行実行し、FULL OUTER JOIN を使用して結果を結合して、最終的な RRF スコアを計算します。

code_block: <ListValue: [StructValue([('code', "WITH vector_search AS (\r\n SELECT id,\r\n RANK() OVER (ORDER BY embedding <=> ai.embedding('gemini-embedding-001', '研究所图书馆')::vector) AS rank\r\n FROM documents\r\n ORDER BY embedding <=> ai.embedding('gemini-embedding-001', '研究所图书馆')::vector\r\n LIMIT 10\r\n),\r\ntext_search AS (\r\n SELECT id,\r\n RANK() OVER (ORDER BY search_vector <=> plainto_tsquery('english', '研究所 & 图书馆')) AS rank\r\n FROM documents\r\n WHERE search_vector @@ plainto_tsquery('english', '研究所 & 图书馆')\r\n ORDER BY search_vector <=> plainto_tsquery('english', '研究所 & 图书馆')\r\n LIMIT 10\r\n)\r\nSELECT\r\n COALESCE(vector_search.id, text_search.id) AS id,\r\n COALESCE(1.0 / (60 + vector_search.rank), 0.0) + COALESCE(1.0 / (60 + text_search.rank), 0.0) AS rrf_score\r\nFROM vector_search\r\nFULL OUTER JOIN text_search ON vector_search.id = text_search.id\r\nORDER BY rrf_score DESC\r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7d0d30>)])]>

クエリの説明:

vector_search CTE は、gemini-embedding-001 モデルを使用し、ScaNN インデックスを利用してクエリに意味的に最も近い上位 10 件のドキュメントを検索します。
text_search CTE は、RUM インデックスを使用して、分割されたキーワードに一致する上位 10 件のドキュメントを検索します。ランキングには RUM 距離演算子が使用されます。
最後の SELECT ステートメントでは、これらのリストを結合し、標準定数 60 を使用して RRF スコアを計算します。キーワードの完全一致とセマンティックの一致を高い精度で組み合わせた、上位 5 件の結果が返されます。

検索に AlloyDB AI が最適な理由

AlloyDB AI を使用して多言語検索とハイブリッド検索の課題を解決することで、エンタープライズ AI アプリケーションの堅牢でスケーラブルかつ費用対効果の高い基盤を構築できます。

ネイティブのデータベース内インテリジェンス: AlloyDB AI 内で直接モデル処理を実行することにより、トランザクションデータを外部の AI サービスに移動する場合の費用、レイテンシ、データ漏洩のリスクを回避できます。
エンタープライズグレードの検索パフォーマンス: ScaNN ベクトル検索（Google の検索テクノロジーをベースに構築）と RUM 全文検索を単一のリレーショナルデータベースに統合することで、複雑な検索エンジンを個別に維持することなく、高速かつ正確な検索結果が得られます。
高いコンテキストアウェア精度: 最新の用語が含まれていないルールベースの固定の辞書とは異なり、Gemini の世界中の知識を活用して深く意味を理解した単語分割が行われるため、高い検索精度を実現します。
運用の簡素化: 標準 SQL を使用して、堅牢なバイリンガル検索機能とハイブリッド検索機能を利用できます。つまり、新しい API を習得したり、複雑な外部パイプラインを管理したりすることなく、すでに持っているデータベースのスキルを使用して AI アプリケーションを構築し、スケールできます。

次のステップ

アプリケーションがトランザクションデータと安全かつ効率的にやり取りできるようにすることで、断片化されたデータサイロから、AI が企業の実体に確実にアクセスできるアーキテクチャへと移行できます。

構築を始める準備ができたら、30 日間の無料トライアルで AlloyDB をお試しください。また、AlloyDB でハイブリッド検索を使ってみる Codelab を活用して、アプリケーションでインテリジェントな検索エクスペリエンスの構築を今すぐ始めましょう。

- クラウドソリューションアーキテクト、Charlie Wang

- AlloyDB AI プロダクトマネージャー、Paul Ramsey

pgvector の強化: AlloyDB で HNSW ベクトル検索が 4 倍高速化

Fri, 31 Jul 2026 02:00:00 +0000

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

AlloyDB は、特に要求の厳しいエンタープライズワークロード向けに構築された PostgreSQL 互換のフルマネージドデータベースサービスです。オープンソースの PostgreSQL の優れた機能と Google の高度なテクノロジーを組み合わせることで、大規模なスケーラビリティ、高可用性、ネイティブ AI 機能を提供します。高性能なリレーショナルストア、ベクトル検索と全文検索の統合バックエンド、標準の PostgreSQL より最大 100 倍高速な分析エンジンとして機能します。

ベクトル検索は、最新の AI アプリケーションと検索拡張生成（RAG）アプリケーションの基盤です。AlloyDB やその他の PostgreSQL データベースを使用する開発者にとって、pgvector はベクトルエンベディングの保存、インデックス作成、クエリに広く採用されている拡張機能であり、HNSW（Hierarchical Navigable Small World）は、多層構造にわたる近似最近傍探索用に設計された、非常に効率的なグラフベースのアルゴリズムです。AlloyDB のカラム型エンジンで高速化された HNSW（現在プレビュー版）を使用すると、標準の PostgreSQL HNSW と比較して、ベクトル検索の秒間クエリ数（QPS）を最大 4 倍に向上させることができます。

エンタープライズ AI アプリケーションは、常にスピードと精度のトレードオフに直面しています。数百万または数十億のベクトルを検索する場合、検索品質（再現率）を損なうことなく秒間クエリ数（QPS）を最大化することは、本番環境ワークロードをスケールするうえで非常に重要です。PostgreSQL の pgvector 拡張機能は、近似最近傍（ANN）検索を高速化できるインデックスの一つとして HNSW を提供します。AlloyDB が速度と精度のトレードオフをどのように解決するのかを詳しく見ていきましょう。

注: この投稿では HNSW のパフォーマンスに焦点を当てていますが、HNSW は AlloyDB の高度なベクトルツールキットの一部にすぎません。AlloyDB には、14 年以上にわたる Google Research の成果に裏打ちされた最先端のインデックスである ScaNN も搭載されており、ワークロードに最適なインデックスを柔軟に選択できます。さらに、絶対的な精度が求められるユースケースでは、標準の k 近傍法（KNN）検索をいつでも利用して 100% の再現率を確保できます。各インデックスの比較については、ベクトルインデックスの選択ガイドをご覧ください。

aside_block: <ListValue: [StructValue([('title', 'AlloyDB の 30 日間の無料トライアルインスタンスを使ってみる'), ('body', <wagtail.rich_text.RichText object at 0x7f60de772a30>), ('btn_text', '無料で構築を始める'), ('href', 'http://goo.gle/try_alloydb'), ('image', None)])]>

まず、AlloyDB カラム型エンジンとは？

AlloyDB カラム型エンジンは組み込みのインメモリキャッシュで、頻繁にクエリされるデータを、スキャンに最適化された特殊なカラム型形式で自動的に保存します。これにより、AlloyDB は標準の PostgreSQL よりも最大 100 倍高速に大量の分析クエリを処理できます。さらに、インデックスをメモリに保存し、高速な走査のためにベクトル化されたメモリレイアウトを使用し、標準の PostgreSQL バッファマネージャーのオーバーヘッドをバイパスすることで、ANN 検索を高速化します。

パフォーマンスの可視化

カラム型エンジンで高速化された HNSW の実際のパフォーマンス特性を把握するために、100 件の制限で 100 万件以上のレコードを検索して、GloVe 100 Angular データセットの標準 QPS と再現率の曲線を作成しました。

このベンチマークスクリプトを実行すると、次のようなグラフが得られます。

注: これらの測定値は、AlloyDB C4A 16 vCPU マシンで取得されたものです。HNSW グラフの構築には固有のランダム性があるため、実行ごとに結果が若干異なる場合があります。

このデータから、2 つの変革的なメリットが明らかになりました。

パフォーマンススループットが大幅に向上: 任意の目標再現率（0.95 など）に対して、QPS が約 4.2～4.9 倍に増加します。これにより、同じハードウェアで同時に処理できるベクトル検索の数が大幅に増加します。
再現率（精度）が大幅に向上: 逆に、QPS レベルが一定の場合、カラム型エンジンで高速化された HNSW は再現率を大幅に向上させます。たとえば、上述のグラフでは、約 350 QPS の時点で、カラム型エンジンを有効にすると、再現率が約 0.78 から 0.94 超へと向上し、0.163 の再現率の向上が見られました。つまり、AI アプリケーションはレイテンシの影響を受けることなく、より正確な結果を得られます。

特筆すべきは、ベースライン（青い線）は、インデックスが PostgreSQL の共有バッファキャッシュに完全に保存されている状態をすでに示しているという点です。ここで示されているパフォーマンスの向上は、単にデータをディスクから RAM に移動した結果ではなく、より効率的なメモリアーキテクチャを採用した結果です。

仕組み: カラム型エンジンで高速化された HNSW

標準的な PostgreSQL アーキテクチャでは、インデックスオペレーションで共有バッファキャッシュが使用されます。データが完全にメモリ内にある場合でも、データベースはバッファマネージャーから大きなオーバーヘッドを発生させます。バッファマネージャーは、ページの固定と固定解除、ロックの取得、バッファテーブルのルックアップ、LRU（Least Recently Used）管理などのオペレーションを処理する必要があります。

AlloyDB のカラム型エンジンは、スキャン用に最適化された特殊な形式でデータを保存する、組み込みのインメモリキャッシュです。

このリリースにより、AlloyDB はカラム型エンジンで高速化された HNSW を使用して、以下の処理を行うことができます。

インデックスの固定: pgvector HNSW インデックスは、カラム型エンジンのメモリに直接固定（高速アクセスを確保するためにメモリ内に永続的に保持）されます。
ベクトル化されたアクセス: HNSW グラフに必要な、同時実行性が高くポインタを多用する走査向けに特別に設計されたメモリレイアウトを利用します。
バッファのオーバーヘッド回避: AlloyDB は、専用のメモリ空間でグラフをナビゲートすることで、標準のバッファマネージャーのボトルネックを回避します。このアーキテクチャの移行により、完全にキャッシュされた標準インデックスと比較した場合でも、上述のような QPS と再現率の大幅な改善が可能になります。

これが重要である理由

エンタープライズ規模のアプリケーションの場合、これは単にデータベースが高速になるだけでなく、費用と品質にも影響します。

インフラストラクチャ費用の削減: コンピューティングリソースを大幅に削減しながら、同じパフォーマンスを実現できます。
AI の精度向上: 以前は「ドラフト」（高速、低精度の結果）品質の検索でしか実現できなかった速度で、より高い再現率と品質を実現できます。
アプリケーションの変更は不要: これは AlloyDB に組み込まれているため、同じ標準の pgvector SQL 構文を使用してこれらのメリットを得られます。

カラム型エンジンはメモリを使用しますが、高度に圧縮され、緻密に管理されています。エンジンはベクトルデータを効率的なカラム形式で保存するため、メモリ使用量はパフォーマンスの大幅な向上に比べて最小限に抑えられます。これは、エンタープライズワークロードにとって非常に有利なトレードオフです。

クイックスタートガイド

AlloyDB でカラム型エンジンで高速化された HNSW を試すには、次の手順を行います。

1. インデックスキャッシュとカラム型エンジンを有効にする

AlloyDB インスタンスで google_columnar_engine.enabled フラグと google_columnar_engine.enable_index_caching フラグの両方が on に設定されていることを確認します。

2. HNSW インデックスをカラム型エンジンに追加する

pgvector を使用して HNSW インデックスを作成したら、次の SQL コマンドを実行してカラム型エンジンにキャッシュ保存します。

code_block: <ListValue: [StructValue([('code', "SELECT google_columnar_engine_add_index('<hnsw_index_name>');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de772f70>)])]>

3. 参考情報

AlloyDB をまだご利用でない場合は、30 日間の無料トライアルで AlloyDB をお試しください。
Google Colab ノートブック: GloVe データセットの取り込み、インデックスの作成、再現率と QPS の曲線のプロットを行うエンドツーエンドの Python スクリプト。
HNSW は貴社のユースケースに最適なベクトルインデックスでしょうか？「AlloyDB AI でベクトルインデックスを選択する」ガイドをご覧ください。

- シニアソフトウェアエンジニア、Vinay Sharma

- グループプロダクトマネージャー、Darshana Sivakumar

AI エージェントの準備は完了。では、データは？

Thu, 30 Jul 2026 01:00:00 +0000

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

組織による AI イニシアチブの拡張を妨げている最大のボトルネックの一つは何でしょう？それは、現在のモデルの機能ではありません。ビジネスコンテキストとセマンティックな意味へのアクセスです。

エージェントの時代における企業は、単にデータを保存するだけでなく、信頼できるコンテキストでデータを有効活用し、受動的な記録システムから能動的な「アクションシステム」へと移行する必要があります。

しかし、AI エージェントは非線形的な速度で動作します。たとえば、1 つのプロンプトでエージェントが複数のシステムを対象に自律的にブラウジングを行い、クエリを発行して処理を実行する場合、基盤となるインフラストラクチャに負荷をかけることがあります。コンピューティング、ネットワーキング、ストレージの各レイヤがエージェント型 AI 向けに最適化されていない場合、その上に位置するデータプラットフォームは崩壊します。

Google のインフラストラクチャの現状に関するレポートによると、本番環境グレードのエージェント型 AI システムをサポートするにはインフラストラクチャのアップグレードが必要だと考える組織が 83% を占めています。

この問題を解決するために、Google は Google Cloud Next 2026 で Agentic Data Cloud を発表しました。これは、データ、AI モデル、運用データベースを単一の「アクションシステム」に統合するソリューションです。Agentic Data Cloud を機能させるには、チップからモデルまで、すべてが AI ネイティブである必要があります。基盤となるインフラストラクチャは、エージェントの負荷に対応できる必要があります。

Google の Agentic Data Cloud

適切なインフラストラクチャ基盤を整えることで、組織が現在直面している最大のデータ課題を Agentic Data Cloud がいかに解決できるか、以降で見ていきましょう。

コンテキストの欠如を克服する

エージェント型システムを効果的に機能させるにはコンテキストにアクセスする必要がありますが、こうしたコンテキストは、多くの場合、断片化されたデータシステムや従来のアーキテクチャに存在します。このため、エージェントがこうしたコンテキストを把握することが難しくなり、不完全かつ不正確な結果につながる可能性があります。実際、Google のレポートによると、43% の IT リーダーが「従来の API やデータソースとの統合の難しさ」をエージェント型 AI インフラストラクチャの最大のギャップとして挙げています。

しかし、組織が膨大なデータセットを移動して AI に接続しようとする場合、必ず複雑さと費用の増大が伴います。

Agentic Data Cloud は、オープンかつ柔軟なインフラストラクチャ上で実行されるボーダーレスなレイクハウスを活用することで、この問題を解決します。エージェントは、オープンスタンダード（Apache Spark、Apache Iceberg）を介して BigQuery や Spanner などの強力なネイティブエンジンにアクセスすることで、従来の環境で発生するレイテンシと費用を回避しながら、まるでローカルであるかのように複数の環境間でデータを読み取り、推論し、有効活用できます。

不要な手作業を回避する

分断されたシステムの寄せ集めにエージェントをスケールすると、大きなボトルネックが生じる可能性があります。Google の調査では、AI をスケールする際の予期せぬ費用の筆頭として、81% のリーダーが運用の複雑さとエンジニアリングのオーバーヘッドを挙げています。その例として、エンジニアが異なるシステムにまたがる AI エージェントを手動でつなぎ合わせる作業に費やす時間が挙げられています。

「考える」エージェントから「実行する」エージェントに移行するには、分析ソースと運用ソースの両方でリアルタイムデータを接続できなければなりません。これには垂直統合が必要です。モデル、データシステム、基盤となるアクセラレータが共同設計された AI ネイティブインフラストラクチャ上に Agentic Data Cloud を構築すると、ネットワークホップが減り、ツールがより適切に統合されます。この統合システムにより、エージェントは典型的なエンジニアリングのオーバーヘッドなしで分析情報を取得し、安全なトランザクションをトリガーできます。

データに信頼と知識をもたらす

エージェントに必要なのは、データを検出してクエリを実行する機能だけではありません。安全かつ正確なアクションを実行するには、豊富なコンテキストとビジネスロジックも必要です。しかし、36% のリーダーが、AI モデルのグラウンディングに使用される専門的な高スループットのベクトルデータベースの不足を、インフラストラクチャの主要なギャップとして挙げています。このギャップにより、エージェントにコンテキストを提供する能力が損なわれます。

エージェントがその可能性を最大限に発揮するには、レガシー ERP やサードパーティ CRM を含むデータシステムに対してリアルタイムで読み書きを実行できるように構築された基盤が必要です。また、複雑なタスクを実行する際に、たとえば 3 週間前のユーザーの好みを「思い出す」ことができる長期記憶も必要です。こうしたリアルタイムの自動化がない場合、エージェントはクエリごとにデータを再処理する必要があります。

AI にコンテキストを提供するために、組織は Knowledge Catalog を使用してデータレイク内のデータを集約して拡充し、エージェントによる検索を可能にしています。非構造化データから意味を抽出してセマンティクスを自動生成することで、カタログはアクティブな推論レイヤとして機能するようになります。そして、そのカタログは、エージェントが適切なコンテキストを取得できるように、高スループットのインフラストラクチャによって支えられている必要があります。

将来を見据える

今こそ、AI によって真の競争優位性を獲得するために、接続されたアクティブなデータエコシステムを構築する絶好のタイミングです。試験運用から本番環境に移行するには、エージェントがすべてのデータにシームレスにアクセスできるようにする必要があります。また、エージェントの時代の要求に対応できるインフラストラクチャで、これを支える必要があります。2026 年以降に勝利を収められるのは、必ずしも高度にスマートなエージェントを備える企業とは限りません。これらのエージェントに適切な知識を、安全かつ費用対効果の高い方法で大規模に提供できる企業が勝利するでしょう。貴社のデータは、エージェントの時代に対応する準備ができていますか？

エージェント型 AI 時代におけるインフラストラクチャの現状に関するレポートで、アーキテクチャに対して AI に最適化されたアプローチを採用しているリーダーたちの手法をご確認ください。

- プロダクト管理、データ分析担当バイスプレジデント、Sirish Chandrasekaran

Android、Google Cloud、Nexus SDV が実現する AI 定義車両

Wed, 29 Jul 2026 01:00:00 +0000

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

ハードウェア中心のプラットフォームを構築してきた自動車業界は、独自の高度なソフトウェア定義車両（SDV）アーキテクチャの構築へと移行しています。OEM にとって、車両はもはや単なる移動手段ではなく、AI ネイティブなエコシステム内でインテリジェントな接続ノードとして機能する存在です。

Google の Android と Google Cloud は、複数のパートナーと連携し、この移行の最前線に立っています。Android のオープンソース Automotive OS（AAOS）SDV が AI 定義車両を実装し、Google Cloud が包括的な AI 統合ツールを含むスケーラブルなインフラストラクチャを提供します。その際、自動車および製造テレマティクスを大規模に実現する Bigtable などのサービスが活用されています。Google Cloud パートナーである Valtech は、Nexus SDV プラットフォームの一部で Google のテクノロジーを使用し、真のエージェントモビリティを実現するエンドツーエンドの総合的なコネクテッドカーシステムを確立しています。これにより、自動車 OEM は、次世代のコネクテッドカー向けにすぐに使用可能なエンドツーエンドの基盤を手に入れることができます。これらすべてがどのように連携して機能するか、以降でご紹介します。

車両側: AAOS SDV

車載プラットフォームの基盤となる Google のオープンソースの AAOS SDV プラットフォームが、物理ハードウェアに依存しない再利用可能なサービスにコア機能を抽象化し、モジュール式のサービス指向アーキテクチャ（SOA）を確立します。AAOS SDV プラットフォームでは、空調、照明、診断などの安全に関係のない領域を電子制御ユニット（ECU）から分離することで、動的なランタイムサービスディスカバリを導入しています。これにより、SDV は実行中のサービス（走行距離計、HVAC、サンルーフ、電動シート、電動ウィンドウなど）とそのステータスを簡単に検出できます。

開発を加速するために、エンジニアリングチームは Android Cuttlefish エミュレータを活用してクラウドにデジタルツインを構築し、高頻度のセンサーストリームをシミュレートして、物理的なシリコンの準備ができる前にこれらの分離されたサービスをビット単位で検証しています。Valtech Nexus SDV は、この AAOS SDV ミドルウェアレイヤを利用して車両リソースを検出、マッピング、管理し、高頻度のテレメトリーデータを構造化して Bigtable に直接ストリーミングします。これに対し、以前は OEM がシステムソフトウェアをさまざまなサプライヤーにアウトソーシングし、各サプライヤーが独自のパイプライン、プロトコル、データを個別のサイロに保存していました。

重要なのは、このモデルがサービスをメインの重いインフォテインメントスタックから切り離すため、車両の電源がオフの状態で駐車中の場合でも、サービスを独立して実行できる点です。これにより、メインのインフォテインメントシステムの電源が切れていても、車両の遠隔モニタリングなどの機能が有効なままになり、テレメトリーに継続的にアクセスできます。車両の 12 V バッテリーやメインの EV バッテリーパックを消耗させることはありません。

AAOS SDV プラットフォームと Nexus SDV の緊密な統合により、エージェント型 AI と革新的なファーストパーティソリューションが数多く実現しています。従来のサンドボックス化されたインフォテインメントツールとは異なり、マルチモーダル AI エージェントはサービスディスカバリレイヤを利用して物理的な自動車と安全にやり取りし、複雑な意図ベースのリクエストを処理できます。たとえば、運転者との会話に応じて、または気候センサーに反応して、AI エージェントが気候ゾーン、ウィンドウアクチュエータ、室内照明を自動的に調整できます。以下のクリップをご覧ください。

Nexus SDV で管理されるこの車載サービスレイヤを、Bigtable に保存された過去のフリートテレメトリーとリンクすることで、高度に統合されたエクスペリエンスを提供し、新たなモビリティソリューションを実現できます。次に、クラウド側を簡単に見てみましょう。

Google Cloud 側: AI ネイティブなモビリティ

現在、SDV を超えて、AI が車両の運用ロジックの中核となる AI 定義車両（AIDV）へと急速に移行しています。AI ネイティブとは、あらゆるアーキテクチャレベルに AI を組み込み、設計段階から自律性を考慮している、という意味です。このレベルの AI では、システムが環境を認識し、Google Gemini などのエンジンを使用して複雑なシナリオを推論し、アクションをプロアクティブに実行できます。たとえば、Gemini を搭載した車両は、バッテリー残量が少ないと警告するだけではありません。ユーザーのスケジュール、交通状況、充電スポットの空き状況を分析して、あらかじめバッテリーの状態を整えて最大限に効率化できるよう、最適な充電スケジュールを提案します。AIDV の特徴は、このレベルでコンテキストを理解し、プロアクティブに自動化できるという点です。

これを、車両全体のさまざまなシステムから送られてくる大量の多様なデータを取り込めるようには設計されていない、従来のアーキテクチャと比較してみてください。この場合、メンテナンスと安全に関する情報テレマティクスが分離されたデータサイロが生じる可能性があります。さらに、このデータは断片化されているため、システム全体でデータからまとまった価値を得ることが非常に困難です。AI ネイティブなアプローチは、こうしたサイロを解消し、コンテキストを統合的に理解するうえで役立ちます。これにより、OEM の主な課題が解消されます。つまり、SDV テレマティクスなどの複数のソースから得た高帯域幅テレメトリーの管理の複雑さが大幅に軽減されるのです。

Bigtable: 自動車テレメトリーのデータバックボーン

Bigtable は、大量の取り込みレートとミリ秒未満のレイテンシ要件への対応に特化したソリューションであり、ペタバイト規模の自動車および製造テレメトリーデータセットのデータバックボーンとして機能します。実際、Bigtable を活用したビジネスクリティカルな自動車テレメトリーソリューションがすでに存在します。その柔軟なスパースロースキーマにより、OEM はダウンタイムなしでデータモデルを進化させ、高頻度のエンジン指標から LiDAR ポイントクラウドまで、多様なセンサーアレイを単一の統合テーブル構造内に収容できます。また、大量の書き込みと複雑な多次元分析ルックアップの両方を対象にネイティブに最適化された方法で時系列イベントをバージョン管理することで、Bigtable が従来のシステムにありがちなデータ過負荷の回避を支援します。

一方、継続的マテリアライズドビュー（CMV）などの機能を使用すると、ストレージレイヤ内で直接、平均バッテリー温度やフリート全体のトルク分布などの主要な指標を事前に計算できるため、コンピューティングのオーバーヘッドを最小限に抑えることができます。Bigtable と Agent Development Kit（ADK）の統合により、AI エージェントがデータにアクセスできるようになり、データとアクションのギャップがさらに解消されます。このキットと、Apache Spark などのフレームワークとの Bigtable の統合を組み合わせることで、大量に流れてくるライブテレメトリーデータをモニタリングし、自動ワークフローをリアルタイムでトリガーできます。たとえば、特定の劣化パターンが検出された瞬間に、ミッションクリティカルなアラートのロギング、プロアクティブな無線（OTA）ソフトウェア調整の開始、交換部品の事前注文などを実行できます。

すべてを統合した Nexus-SDV プラットフォーム

Google Cloud 上に構築された Nexus SDV プラットフォームは、AAOS SDV と統合してコネクテッドカーの未来を支えます。Nexus は、標準化されたデータ基盤を提供することで、自動車 OEM がインフラストラクチャをゼロから構築する手間を省き、独自のブランドエクスペリエンスに注力できるようにします。

Nexus SDV は、Gemini Enterprise Agent Platform、Bigtable、BigQuery などの Google コンポーネントを使用します。Nexus SDV のセットアップは、迅速、自動、透過的です。OEM は、車両内だけでなく、UI 画面、モバイルアプリ、サービスセンターなどの他の顧客タッチポイントでも、ブランド固有の顧客体験を創出できます。車両への接続には、オープンソースの Synadia NATS インターフェースが利用されます。車両との統合は、クラウドと車両のシンプルな SDK を介して行われるため、両側でサービスディスカバリが容易になります。Nexus SDV は AAOS SDV 向けに最適化されていますが、あらゆる車両フレームワークと統合できます。

セキュリティは「多層防御」モデルを通じて Nexus アーキテクチャに組み込まれています。相互 TLS（mTLS）と Google Cloud Certificate Authority Service（CAS）により、暗号化された安全な ID が車両に提供されます。ネットワーク分離はプライベート GKE クラスタによって維持される一方、Secure AI Framework（SAIF）は ML ライフサイクル全体でデータプライバシーを確保し、機密性の高いユーザーデータと OEM の知的財産を保護します。

迅速なセットアップと統合、標準化されたデータ基盤、組み込みの最先端セキュリティが組み合わさることで、自動車メーカーは測定可能なビジネス上の効果を即座に得られます。

まとめとして、具体的なユースケースについて詳しく取り上げます。

予測メンテナンス

事後対応型のメンテナンスから予測メンテナンスに移行することで、OEM は保証費用を削減し、顧客ロイヤルティを向上させ、車両の稼働時間を長くすることができます。

課題: 多くの場合、従来の定期メンテナンスは非効率的で、不要なサービス訪問や予期せぬ車両の故障につながり、OEM と所有者の両方に多大な費用を発生させます。Nexus SDV、Bigtable、ADK は、AI を活用したプロアクティブなアプローチに移行することで、このエクスペリエンスを変革します。このプロセスではまず、大量に流れてくる車両のテレメトリーデータ（エンジンの回転数、振動、液面、ブレーキ圧など）をモニタリングして取り込み、Bigtable に直接保存します。

リアルタイムの異常検出を可能にするために、エージェント型 AI はテレメトリーストリームが到着すると同時にデータをモニタリングします。Bigtable CMV は、エンジンの平均振動やバッテリー温度プロファイルの急激な変動などのローリング集計を事前に計算します。これらのライブ集計を消費する AI モデルは、通常のパラメータからの微妙な逸脱を検出できるため、ダッシュボードに警告灯が表示されるかなり前に、エンジンの摩耗やバッテリーの急速な劣化の兆候を特定できます。

専門 AI モデルによって異常が検出されると、システムはエージェントによる推論とアクションのフェーズに移行します。Gemini を搭載したエンジンが、走行距離、モデル、メーカー、サービス履歴、今後の移動予定などの要素を考慮して、データの重大度とコンテキストを評価します。このインテリジェントな評価に基づいて、システムは AAOS インフォテインメントシステムを介して運転者にプロアクティブに通知し、近くのディーラーでの最適なサービス予約を提案します。また、到着時にすべてが準備できているように、部品の自動注文をトリガーすることもできます。AI モデルは、偽陰性が発生しないよう対処し、顧客感情の悪化や信頼の低下を防ぎます。また、ソリューション全体としては、車両の稼働時間を向上させ、メンテナンスを事後対応型の負担の大きい作業から、ブランドを定義するサービスエクスペリエンスへと変容させます。

ご利用にあたって

AAOS SDV と統合した AI ネイティブの Nexus SDV プラットフォームはこちらからご利用いただけます。極めて規模が大きく、分析が厳格な最新のモビリティに対応するように設計された、エンドツーエンドの高度なコネクテッドカーエコシステムを実現します。この統合オープンソースアーキテクチャを採用することで、OEM は従来のインフラストラクチャの制限を乗り越え、ブランドを定義する影響力の大きい機能の開発にリソースを再配分できます。

Nexus SDV は、コネクテッドカーサービスをエージェントの時代へと導きます。車両はもはや接続されているだけでなく、運転時のインテリジェントかつプロアクティブなパートナーの役割を果たすようになっています。ぜひ、今すぐお試しください。

詳細

Nexus SDV プラットフォーム、AAOS SDV、Bigtable の詳細については、nexus-sdv@google.com までお問い合わせください。

AAOS SDV は、Android Automotive 26Q2 リリースでご利用いただけます。Nexus SDV のドキュメントはこちらでご覧いただけます。

自動車テレメトリーの時系列データベースとしての Bigtable について詳しくは、こちらをご覧ください。

コネクテッドカーのセキュリティについて検討されている場合は、エージェントでギアを上げる: ソフトウェア定義車両のセキュリティを確保をご覧ください。

- Valtech Mobility、マネージングディレクター、Peter Ivanov 氏

- Google、Android Automotive、グループプロダクトマネージャー、Matt Crowley

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

^{Gartner、「Critical Capabilities for Cloud Database Management Systems for Operational Use Cases」（作成者: Ramke Ramakrishnan、Masud Miraz、Xingyu Gu、Henry Cook、Aaron Rosenbaum、2025 年 11 月 19 日）}

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

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

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

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

AlloyDB AI 関数 - 革命的なパフォーマンス向上と費用削減を実現

Thu, 09 Jul 2026 01:00:00 +0000

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

AlloyDB は AI ネイティブなデータベースです。単なる受動的なデータストアではなく、データをインテリジェントに理解して処理します。AlloyDB では、業界をリードするベクトル検索とハイブリッド検索、会話型エージェントを構築するためのほぼ 100% の精度を誇る自然言語から SQL への変換機能、好みのエージェント型 IDE で構築できるツール、AI 関数を通じて Gemini などの基盤モデルのインテリジェンスをデータに直接適用する機能を利用できます。

このブログ投稿では、AI 関数処理における大きなブレークスルーと、一連のまったく新しい AI 関数について説明します。

まず、AI 機能とは具体的にどのようなものでしょうか？AI 機能は Gemini の世界中の知識を AlloyDB のデータに適用します。ユーザーからの生のフィードバックを管理する課題について考えてみましょう。そのようなフィードバックは構造化されておらず、解析が困難です。このデータを検索に活用するには、前処理とエンティティ抽出が必要になる場合があります。知識抽出のために複雑なカスタムパイプラインを維持する代わりに、AlloyDB 内で Gemini の生成機能を直接使用して、未加工のテキストを構造化された検索可能な分析情報に変換できます。たとえば、ai.generate を使用して、生のフィードバックをクリーンで構造化された JSON に即座に変換する方法は次のとおりです（その他の例はこちら）。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n log_id,\r\n raw_content,\r\n -- Gemini 3.0 を使用して、ユーザーからの生のフィードバックについて推論し、構造を抽出する\r\n ai.generate(\r\n model_id => 'gemini-3.1-pro-preview',\r\n prompt =>\r\n 'Analyze this raw customer feedback entry. Extract the country, service name, and a 1-sentence summary of the feedback. Return as JSON.'\r\n || raw_content) AS structured_feedback\r\nFROM raw_feedback_logs\r\nWHERE user_type <> 'internal';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de79fa60>)])]>

結果の例を次に示します。

log_id	raw_content	structured_analysis
1001	2025-12-16 08:00:01 [ERROR] Service: OrderSvc \| DbConnectionTimeout: 5,000 ミリ秒経過後、プール「primary-shard-04」から接続を取得できませんでした。	{"errorCode": "DbConnectionTimeout", "serviceName": "OrderSvc", "rootCause": "サービスが 5,000 ミリ秒のタイムアウト制限内にプライマリシャードプールからデータベース接続を取得できませんでした。"}
1002	2025-12-16 08:05:12 [WARN] Service: IdentityProvider \| 401 Unauthorized: user_id=9942 の署名なしトークンの検証に失敗しました。署名が一致しません。	{ "error_code": "401", "service_name": "IdentityProvider", "root_cause": "署名が一致しないため、署名なしトークンの検証に失敗しました。" }
1003	2025-12-16 08:12:45 [CRITICAL] Service: AnalyticsEngine \| OutOfMemoryError: Java ヒープスペース。1.2 GB の配列の割り当てに失敗しました。ヒープ使用率 99%。	{ "error_code": "OutOfMemoryError", "service_name": "AnalyticsEngine", "root_cause": "サービスが 1.2 GB の配列を割り当てようとした際に、利用可能な Java ヒープメモリを使い果たしました。" }
1004	2025-12-16 08:25:33 [ERROR] Service: WebFrontEnd \| 404 NotFound: リソース /api/v3/users/profile/settings が見つかりません。アップストリームから 404 が返されました。	{ "error_code": "404", "service_name": "WebFrontEnd", "root_cause": "ユーザープロファイル設定に対してリクエストされた API リソースが、アップストリームサービスで見つかりませんでした。" }
1005	2025-12-16 08:35:50 [WARN] Service: NotificationGateway \| GatewayTimeout: 外部プロバイダ「SendGrid」が 30 秒以内に応答できませんでした。再試行がスケジュールされました。	{"error_code": "GatewayTimeout", "service_name": "NotificationGateway", "root_cause": "外部プロバイダ SendGrid が 30 秒のタイムアウト制限内に応答できませんでした。"}

要約や感情分析を行う関数を追加

Google のコア AI 関数である ai.generate、ai.rank、ai.if、ai.forecast の一般提供が開始されました。最初の 3 つの関数のユースケースについて詳しくは、こちらのブログ投稿をご覧ください。予測機能の実際の動作を確認するには、こちらの詳細をご覧ください。

この勢いに乗り、Google は 3 つの新しい関数、ai.summarize、ai.agg_summarize、ai.analyze_sentiment を導入しました。

ai.analyze_sentiment: テキストの感情的なトーンを肯定的、否定的、中立的として自動的に分類します。
ai.summarize: 長文のテキストを、元のトーンとニュアンスを維持しながら、最も重要な情報に凝縮します。
ai.agg_summarize: 列内の複数の行を処理して、（GROUP BY 句などを使用して）グループ全体の統合された単一の要約を生成する集約ツール。

ai.agg_summarize を使用して、小売ウェブサイトの商品レビューを統合する方法の例を以下に示します。

code_block: <ListValue: [StructValue([('code', 'SELECT productname, ai.agg_summarize(review) as reviews_summary\r\nGROUP BY productname;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de79fa00>)])]>

2 つのゲーム機製品のレビューを要約した結果の例を以下に示します。

productname

reviews_summary

AlphaCore Console

ユーザーは、美しい 4K グラフィック、スムーズな 120 Hz のフレームレート、人間工学に基づいたコントローラのデザインを高く評価しています。

しかし、複数のレビューで、長時間ゲームをプレイすると冷却ファンの音がうるさくなるという不満が示されています。

全体として、熱や騒音に関するわずかな不満はあるものの、最高水準のゲーム機と見なされています。

NeoCore Console

ユーザーは、外出先での携帯ゲームに最適な、優れたバッテリー駆動時間と鮮やかな OLED ディスプレイを気に入っています。

多くのユーザーが、UI が遅く感じられることと、ゲームライブラリが現在限られていることを指摘しています。

カジュアルゲーマーには大きな価値がありますが、パワーユーザーはパフォーマンスが不十分だと感じる可能性があります。

LLM の力をデータに: 大幅な高速化とコスト削減を実現

Google は、AI 機能の処理において前例のないパフォーマンス向上と費用削減のブレークスルーを達成しました。以前は、大規模なデータベースの各行で基盤モデルの呼び出しを実行することで、費用とレイテンシの制約が生じていました。2 つの画期的な機能を導入することで、これらの障壁を打ち破りました。

AI 関数のスマートバッチ処理: この AI 関数アクセラレーション機能は、AI 関数呼び出しのインテリジェントなバッチ処理を実現し、パフォーマンスと品質を最適化します。この効率性は、プロンプトのオーバーヘッドの重複を排除することで実現されます。LLM の定型的な指示は、個々の行で繰り返されるのではなく、バッチごとに 1 回送信されます。「これをアプリケーションレイヤで実行してはいけないのか？」と疑問に思われるかもしれません。そうしない理由は、AlloyDB が最適な結果を得るための適切なバッチサイズをインテリジェントに決定するからです。バッチサイズを過小評価すると、費用とレイテンシのメリットが得られません。バッチサイズを過大評価すると、LLM へのプロンプトが膨張してハルシネーションが発生したり、モデルのトークン制限を超えたりする可能性があります。AlloyDB は、それぞれのリクエストに最適なバッチサイズを計算するだけでなく、設定なしで自動的に再試行を処理するため、パイプラインの復元力を維持できます。社内でテストを行ったところ、大きな成果が得られました。たとえば、従来の 1 行ずつの LLM 呼び出しと比較して、パフォーマンスが最大 2,400 倍向上しました（1 秒あたり 10,000 行を処理）。現在、この機能は ai.if 関数と ai.rank 関数で利用できます。今後、他の関数もサポートされる予定です。

このユースケースを解決するために、ai.if でスマートバッチ処理 / アクセラレーションを使用する例を見てみましょう。ある顧客が、水深 60 メートル以上でも使用できるカメラをガジェット販売サイトで検索しているとします。従来のハイブリッド検索では、最も近い意味的一致と全文一致が抽出されますが、数値データの厳しい制約が考慮されません。つまり、水深 20 メートルでしか使用できないカメラが表示される可能性があります。AlloyDB の ai.if ベースのインテリジェントフィルタリングを使用すると、データベースは水深のニュアンスを実際に理解し、水深 60 メートルの基準を満たすか、それを上回る商品をクエリで返します。以下の例では、バッチサイズを指定する必要がないことに注目してください。ai.if を使用すると、AlloyDB がすべての最適化を内部で処理します。

code_block: <ListValue: [StructValue([('code', "-- スマートバッチ処理 / AI 関数アクセラレーション\r\nSET google_ml_integration.enable_ai_function_acceleration = on;\r\nSELECT productid, productname, category,description\r\nFROM products AS p\r\nWHERE\r\n ai.if(\r\n 'Evaluate if the product description indicates that the product is waterproof at depth 60m or deeper. Description:'\r\n || description);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de79f9a0>)])]>

架空のガジェットサイトでの検索結果の例を以下に示します。商品の詳しい説明が、水深 60 メートルで使用できるという条件に合致していることに注目してください。

最適化された AI 関数: 効率性をさらに高めるために、まずは ai.if に、最適化モードを導入しました。埋め込みを利用し、特定の LLM 出力に基づいてトレーニングされた小さなプロキシモデルをデプロイすることで、データベース内でネイティブに意思決定を処理できます。これにより、外部 LLM を呼び出す必要性が大幅に減ります。Google の内部テストでは、驚くべき成果が見られました。たとえば、1 秒あたりに処理される行数が最大 100,000 行（23,000 倍増加）に達し、費用が 6,000 分の 1（0.1 セント）に削減されました。この手法が最も効果的な場合と効果的でない場合など、技術的な分析情報については、こちらのブログ投稿をご覧ください。最適化された ai.if を使用すると、AlloyDB は次の処理を行います。

プロキシモデルをトレーニングする: AlloyDB は、データのサンプルに基づいて軽量なプロキシモデルをトレーニングします。これは、最適化されたクエリのモデルをトレーニングするために、ai.if 関数で PREPARE ステートメントを使用すると、バックグラウンドで行われます。
クエリを実行する: EXECUTE ステートメントを使用すると、AlloyDB はトレーニング済みのプロキシモデルを使用してクエリをローカルで処理します。
LLM にフォールバックする: モデルの精度が低い場合や、モデルが見つからない場合、AlloyDB は自動的に LLM の使用にフォールバックします。

水深 60 メートル以上で使用できるカメラを検索する先ほどの例で、最適化された ai.if を使用する場合を見てみましょう。ここでは、PREPARE ステートメントを使用してプロキシモデルをトレーニングし、その後 EXECUTE ステートメントを実行します。

code_block: <ListValue: [StructValue([('code', "-- 最適化された関数 / プロキシモデルを準備する\r\nPREPARE waterproof_camera_60m AS\r\nSELECT productid, productname, category, description\r\nFROM products AS p\r\nWHERE\r\n ai.if(\r\n 'Evaluate if the product description indicates that the product is waterproof at depth 60m or deeper. Description:'\r\n || description,\r\n description_embedding);\r\n\u200b\r\n-- プロキシモデルを実行する\r\nEXECUTE waterproof_camera_60m;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de79f940>)])]>

上のスクリーンショットのように、水深 60 メートルで動作するという基準に実際に合致する商品が表示されます。説明をより詳しく確認できるように、最初の 3 つの商品を表にしたものを以下に示します。

productname	description
Pulsetron Action Camera MZ314	このカメラで次の冒険を制覇しましょう。厳しい自然環境でも使用可能。水深 60 メートルまで潜水できるほか、耐衝撃性に優れたアドベンチャー仕様のシャーシで、過酷なトレイルにも対応します。高度な水平手ぶれ補正により、ジャンプ、ターン、水しぶきなど、あらゆる動きが完璧にスムーズにレンダリングされ、比類のない流動性で映像がストーリーを伝えます。
Hyperbyte Action Camera LG688	激しいアクティビティでも、世界を息をのむほど細部まで捉えます。このカメラは、驚くほど頑丈なポケットサイズのフレームに、1 インチの強力なセンサーを搭載しています。プロ仕様の機器に匹敵する、美しい 5K 動画と鮮明な 20MP の静止画を撮影できます。水深 60 メートルの優れた防水性能で、これまで以上に深く潜水できます。
Alphasync Action Camera WW897	このコンパクトでパワフルなカメラは、あらゆる自然環境に対応。1 インチの大型センサーが、息をのむような瞬間を 5K 動画と 20MP の鮮明な静止画に変換します。水深 60 メートルの防水性能と革新的な水平手ぶれ補正により、深海から高山まで、あらゆる環境で使用可能で、驚くほど安定した映像を実現します。

デモのご紹介

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

始め方は簡単

AI ワークロードに前例のないスピードと費用対効果をもたらす準備はできていますか？

AlloyDB を初めてご利用の場合: 30 日間の無料トライアルで AlloyDB をお試しください。
AI 関数のクイックスタート: いくつかの簡単な前提条件を満たして、SQL クエリ内で ai.if、ai.generate、ai.analyze_sentiment などの関数を直接呼び出しましょう。まずは、実用的な例をご覧ください。
パフォーマンスの向上と費用の最適化: 最大限のパフォーマンス向上と費用削減を実現するには、最適化された関数に関するガイドに従ってください。この最適化は ai.if のプレビュー版で利用可能であり、まもなく他の関数でも利用可能になる予定です。この手法が最も効果的な場合と効果的でない場合など、技術的な分析情報については、こちらのブログ投稿をご覧ください。
スループットのスケーリング: スマートバッチ処理を使用して AI 関数を高速化する（ai.if と ai.rank のプレビュー版で利用可能）か、配列ベースの関数（すべての LLM ベースの AI 関数で一般提供）を使用して、大量のプロンプトをスムーズに処理することができます。

- グループプロダクトマネージャー、Darshana Sivakumar

- ソフトウェアエンジニア、Pushkar Khaldikar

Atlas が Cloud SQL Enterprise Plus エディションにより数百の加盟店のデータベースをどうスケールしたか

Fri, 03 Jul 2026 02:00:00 +0000

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

Atlas は、飲食店向けのオペレーティングシステムを構築しています。オンラインショップ、POS、サードパーティロジスティクス、食のプラットフォームの統合、顧客ロイヤリティ、AI ツールは、飲食店の立ち上げから運営、そして成長に必要なあらゆる要素を網羅しています。当社はシンガポールでは、SaladStop、Killiney、Haidilao、Raffles Hotel、Lo and Behold Group、Les Amis Group などのブランドと連携し、加盟店の 1 回あたりの購入額の増加、売上拡大、運用コスト削減を支援しています。

Atlas の各加盟店には、専用の Cloud SQL for PostgreSQL データベースが割り当てられます。飲食店の形態はそれぞれ大きく異なります。単一店舗のカフェと複数店舗あるチェーン店で、裏側の仕組みが同じであるべきではありません。データベースを独立させることで、データが完全に分離されているほか、昼食時や夕食時のピーク時でもパフォーマンスが予測可能で、各店舗を個別にスケール、チューニング、移行できる柔軟性があります。Atlas の成長に伴い、データベースの数も増えています。

課題: 標準エディションの枠を超えたスケール

当社は、最初に標準の Cloud SQL Enterprise エディションを導入しました。これは強固な基盤でしたが、加盟店が増え、機能が追加されるにつれて、データベースを管理するために必要な運用レイヤがボトルネックになりました。

接続プーリングを別のレイヤとして管理していたため、実行、保護、モニタリングするサービスが増えていきました。クエリによって CPU が急上昇した場合、何が起こったのか、どの加盟店がトリガーしたのかを正確に把握する必要がありましたが、限られたシグナルから問題を突き止めるのに時間がかかりすぎていました。小規模なチームで、専任のデータベースエンジニアがいなかったため、コンポーネントが追加されるたびにメンテナンスの負荷が増加していました。

Enterprise Plus エディションへの移行

新しいデータベースインスタンスをプロビジョニングする必要が生じたとき、Google Cloud チームに Cloud SQL Enterprise Plus エディションを紹介してもらいました。運用上のオーバーヘッドがどれだけ増えるのかをすでに懸念していましたが、Enterprise Plus エディションでは、本来なら自社で対応しなければならない作業のカテゴリ全体が不要になることがわかりました。

マネージド接続プーリング: この機能が Cloud SQL に直接組み込まれるようになったため、プーリングを個別のレイヤとして実行する必要がなくなりました。これにより、システムの構成要素が減り、メンテナンスの負担が軽減されただけでなく、攻撃対象領域も小さくなりました。
Query insights: これは、当社に最も大きな効果をもたらした機能でした。どのクエリの負荷が高く、どの加盟店がそのクエリをトリガーしているかを正確に把握できるようになったからです。パフォーマンスチューニングが、推測に基づくものから、具体的で実行可能なものへと変わりました。数百ものデータベースを実行するプラットフォームにとって、この可視性は「スーパーパワー」と言えます。
データキャッシュ: これにより、加盟店のデータセットが増加しても、読み取りパフォーマンスが一定に保たれるようになりました。飲食店では毎日多くのデータが生成されるため、データレイヤはそうした複雑化に合わせて高速処理を維持する必要があります。
ダウンタイムがほぼゼロのスケーリング: 加盟店の拡大に合わせて、オフピーク時にサービスを中断することなくインスタンスをスケールできるようになりました。

新しいインスタンスで結果を確認した後、既存のすべてのデータベースも Enterprise Plus エディションに移行しました。

効果: インフラストラクチャ管理ではなくイノベーションに注力

現在、Atlas は数千の飲食店で利用されており、数百ものマネージドデータベースを使用して毎日数万件の注文を処理しています。最も大きな変化は、エンジニアリングの時間の使い方です。データベース運用にかかる時間が 30% 減り、プロダクトを構築するための時間が増えました。新規加盟店のオンボーディングも簡素化されました。すぐに使用できるマネージドデータベースが数秒でプロビジョニングされるため、導入がスムーズです。パフォーマンスは以前よりもはるかにプロアクティブになり、問題が加盟店に悪影響を及ぼす前に検出して修正しています。日々の業務では、データベース管理について考える必要はなく、加盟店により良いサービスをどう提供するかに注力できています。その結果 Atlas は前年比 200～300% の成長を遂げました。

今後の展望: AI ファーストの未来

当社は、社内外で AI に多額の投資を行っています。社内では、AI 支援の開発ワークフローを通じてエージェントエンジニアリングに全面的に取り組んでおり、少人数のチームでもコードのビルド、レビュー、リリースを大幅に高速化できるようになりました。社外では、飲食店の経営者がより良い意思決定を行い、それに基づいて行動できるよう支援する AI 搭載ツールを構築しています。当社のロードマップは、ユーザーとの新たな接点や飲食店の成長を支援する新しい方法など、多くの実験的なアイデアであふれています。これらすべてを迅速に進める自信を与えてくれるのは、基盤となるレイヤである Cloud SQL と Google Kubernetes Engine（GKE）の存在です。このレイヤは実績があり、開発の妨げになることはないからです。

インフラストラクチャの複雑さは Google Cloud が処理してくれるため、Atlas は飲食店向けの最適なツールの構築に専念できます。

Cloud SQL Enterprise Plus により、柔軟性、オブザーバビリティ、スケーラビリティに優れたデータベースアーキテクチャが実現しました。これによりインフラストラクチャ管理に頭を悩ませることなく、加盟店のことだけを考えられるようになりました。AI をさらに活用し、プラットフォームを成長させていく中で、Google Cloud は、基盤となるインフラストラクチャを気にかけずに迅速に前進するための自信を与えてくれます。

データベースアーキテクチャをスケールする準備はできていますか

インフラストラクチャのボトルネックにより、イノベーションが妨げられないようにしましょう。管理するデータベースが数十個でも数百個であっても、エンジニアリングチームが最も重要な作業に集中できるように、Google Cloud SQL がどのように運用の合理化とオブザーバビリティの強化を行うかをご覧ください。

Cloud SQL Enterprise Plus エディションに関する詳細
登録して Cloud SQL を無料で試す。

- Atlas、共同創業者 / エンジニアリング責任者、Surendhar Reddy 氏

- Google Cloud、データベース、シニアプロダクトマネージャー、Alok Srivastava

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

データエージェントの新機能: AI ワークフローの強化

Tue, 23 Jun 2026 02:00:00 +0000

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

AI エージェントの台頭は、アプリケーションや分析システムに根本的な変革をもたらしています。汎用的な AI プラットフォームは通常、企業データベースに保存されているコンテキストにアクセスできません。これは、従来のデータアーキテクチャでは、データ資産全体にわたってエージェント向けのコンテキストが欠如していることが多く、エージェントの精度の低下につながる可能性があるためです。また、きめ細かなアクセス制御が不足しているため、セキュリティギャップが生じやすい傾向もあります。

Google の Agentic Data Cloud は、運用システムと分析システムの両方を備えた、AI ネイティブなアクションシステムです。カスタムシリコンから最先端の Gemini モデルまで、スタック全体に AI を組み込むことで、エージェントがリアルタイムの企業データに基づいてほぼ 100% の精度で推論できる、テンプレートを使用した決定論型のデベロッパーフレームワークと、統合されたガバナンスを提供します。

このたび Google は、より簡単にエージェントを開発できるようにするため、多数のデータエージェントとツールを新たに導入いたしました。具体的には、ビジネスアナリスト向けの会話型分析、自動化とインテリジェンスを強化する、データサイエンティスト、エンジニア、データベース管理者向けの一連の Google 製データエージェント、現在のオープンなエージェントエコシステムとの統合を強化する、デベロッパー向けのデータエージェントツールです。

1. 会話型分析

自然言語を使用してエージェントを構築するデベロッパーを支援するため、データクラウド全体にわたって会話型分析対応を拡充することをお知らせいたします。

BigQuery の会話型分析（プレビュー版提供中）では、高度な AI 推論エンジンが BigQuery Studio に直接組み込まれています。これにより、データチームやビジネスチームは、手動で SQL を記述するだけでなく、ビジネスコンテキストを活用したマルチモーダル統合と詳細な調査を使用して、回答をグラウンディングできます。また、一部のお客様にプレビュー版が提供されている Agentic Workflows は、根本原因分析を自動化し、アクションをスケジュール設定して、企業データをプロアクティブで実用的なインテリジェンスに変換します。

BigQuery の会話型分析でエージェントを作成し、データ分析情報を迅速に取得する

Lakehouse の会話型分析（プレビュー版提供開始）は、Lakehouse の統合インフラストラクチャを拡張し、ユーザーが自然言語を使用して、AWS、Azure、Google Cloud に分散したデータレイクに対してクエリを実行できるようにします。これにより、データを 1 バイトも移動させることなく、クラウドプラットフォーム全体で分析情報を統合することが可能になります。
AlloyDB、Spanner、Cloud SQL の会話型分析（いずれもプレビュー版を提供開始）は、すぐに使える会話型 AI をサポートしているため、誰でもデータにアクセスできるようになります。AlloyDB、Spanner、Cloud SQL のユーザーは、自然言語でデータベースと会話をして、リアルタイムの運用データの可視化や分析情報の取得を行うことができます。

会話型分析を使用して、運用データから回答を得る

Looker 埋め込み会話型分析（一般提供開始）では、ローコードの iframe 実装を介して、エージェントをカスタムアプリケーションや社内ワークフローに直接埋め込むことができるため、プロダクションレディな会話型 AI をあらゆるアプリケーションに簡単に組み込むことができます。さらに、Looker の Conversational Analytics API を使用すると、AI による推奨事項を提供するマルチターンの会話型ワークフローを作成できるだけでなく、その基盤となる SQL クエリの検証と説明も行うことができます。また、すでに一般提供されている Looker の核となる会話型分析エージェントも大幅にアップグレードされ、優れた推論とセマンティックグラウンディングにより、曖昧さを解消できるようになります。

会話型 AI のためにエージェントをアプリケーションに直接埋め込む

2. 新たなデータエージェント

データプロフェッショナルが事後対応型のデータ管理から事前対応型のインテリジェンスに移行し、ビジネスアナリストがダッシュボードをより効果的に操作できるよう、Google は、自動化、インテリジェンス、自然言語機能を日々のワークフローに提供する新たなデータエージェントを発表いたします。

データエンジニアリングエージェント（一般提供開始）は、データパイプラインの構築や維持管理といった手間のかかる作業を自動化します。自然言語の要件を BigQuery と Dataflow 向けに最適化された SQL または Python コードに変換するとともに、パイプラインの障害を事前対応的に特定して修正します。スキーマの改善やパーティショニング戦略を提案することにより、手動で試行錯誤する必要なく、スケーラブルで信頼性の高い、パフォーマンスが調整されたデータ基盤を確保できます。
データサイエンスエージェント（プレビュー版提供開始）は、元データからプロダクションレディなモデルへの移行を加速させます。関連する特徴の提案、ボイラープレートノートブックコードの生成、技術ドキュメント処理の自動化を通じて、データサイエンティストを支援します。
データベースオブザーバビリティエージェント（Cloud SQL、AlloyDB、Spanner、Bigtable の一部のお客様にプレビュー版を提供中）は、データベースのパフォーマンスを事前対応的にモニタリングし、潜在的な問題が深刻化する前に、継続的に特定します。その後、インテリジェントな推奨事項とマルチターンの修復ワークフローを提供し、迅速かつ包括的なトラブルシューティングと最適化を実現します。また、データベースフリート全体のパフォーマンス分析機能は、データベース全体のパフォーマンスを最適化する機会を迅速に特定するのに役立ちます。
データベースオンボーディングエージェント（一部のお客様にプレビュー版を提供中）は、推測に頼らずにデータベースの選択やデプロイができるようにします。単純なユースケースの説明から複雑な企業ニーズまで、さまざまな要件の評価をもとに、最適な Google Cloud データベースを推奨し、プロビジョニングのプロセスを支援します。
Looker ダッシュボードエージェント（プレビュー版提供開始）では、ダッシュボード内のデータと会話形式でやり取りできます。ダッシュボード内で、ユーザーは自然言語で質問し、コンテキストを認識した回答を受け取ることができます。この機能では、ダッシュボードから得られた重要なポイントや分析情報をまとめた、AI 生成による要約も提供されます。
Gemini Enterprise の会話型分析（プレビュー版提供開始）は Looker、BigQuery、Lakehouse に対応しており、データ実務者が構築した、管理されたインテリジェンスをビジネスリーダーに直接提供します。これは、Google データクラウドへの「正面玄関」として機能し、ビジネスユーザーは技術コンソールにアクセスすることなく、BigQuery、Looker、Lakehouse で構築されたエージェントを利用できるようになります。これらのエージェントを Google データから Gemini Enterprise に公開することにより、組織は正確なデータ探索と即時の回答のためのグラウンディングされた単一のインターフェースを、ビジネスユーザーに提供します。
Data Insights エージェント（プレビュー版提供開始）は、構造化されたソース（BigQuery や Snowflake など）と構造化されていないデータ（会議メモや公開ウェブ情報など）を同時にクエリすることで、Gemini Enterprise 内のデータ資産に関する総合的な分析情報を提供します。このエージェントは、日常業務で利用するユーザー向けの迅速な応答エンジンとして機能し、Workspace エコシステム（ドキュメント、スプレッドシート、ドライブ）や、Jira、HubSpot などのサードパーティ製アプリの情報を統合します。このエージェントは、インタラクティブな可視化機能を豊富に備えており、時間の経過とともにユーザーの好みに合わせて継続的に学習します。
Deep Research エージェント（プレビュー版提供開始）は、Knowledge Catalog を使用して、リスクの高い多層的なビジネス上の問題を解決します。単なる検索にとどまらず、社内ドキュメント、BigQuery テーブル、公開ウェブの情報を統合して包括的な調査計画を策定します。その結果、企業のプライバシーとユーザーの権限を常に尊重しながら、動的な可視化と検証可能な引用を使用した詳細なレポートが生成されます。

3. データエージェント向けのツール

エージェント開発向けのオープンソース標準は、AI アプリケーションやカスタムエージェントを構築するデベロッパーに対し、データやツールに一貫性を持って安全にアクセスするための統合フレームワークを提供します。このたび Google は、エージェント開発の取り組みを支援する、以下のツールを発表いたします。

Data Agent Kit（プレビュー版提供開始）は、好きな開発環境（IDE / CLI）内で直接使用できる標準化されたスキルとツールのスイートを提供し、データ実務者が Agentic Data Cloud 機能の規範的なガイダンスを使用して、データを大規模に検出、変換、活用できるようにします。
データベース向けマネージド MCP サーバー（一般提供開始）は、AlloyDB、Spanner、Cloud SQL、Bigtable、Firestore で利用でき、AI モデルをデータに安全に接続するために必要なインフラストラクチャを完全に管理します。そのため、MCP サーバーをお客様ご自身でホスト、保護、スケーリングする必要はありません。これにより、デベロッパーは Google のデータベースポートフォリオ全体から最新のコンテキストをエージェントに提供できるようになり、AI モデルは最新の企業データに基づいて推論や行動ができるようになります。
Looker 向けマネージド MCP サーバー（プレビュー版提供開始）を使用すると、あらゆる MCP クライアントやエージェントプラットフォームで Looker のセマンティックモデルをクエリできるようになり、管理された BI 分析情報をサードパーティ製アプリケーション全体に拡張できるようになります。

マネージド MCP サーバーを介して Looker セマンティックモデルにアクセスする

データベース向け MCP ツールボックス 1.0（一般提供開始）は、安定性における大きなマイルストーンを達成し、本番環境アプリケーションを安心して構築できるようになりました。また、ドキュメントを全面的に見直し、人間の開発者にとっても自律型エージェントにとっても、プラットフォームがはるかに使いやすくなりました。
Cloud SQL、AlloyDB、Spanner 向け QueryData（いずれもプレビュー版提供開始）は、自然言語の質問をデータベースクエリに変換します。各 QueryData はこれらのデータベースにネイティブに組み込まれており、メタデータ、クエリの例、評価を通じて、自然言語から SQL への変換をほぼ 100% の精度で実現します。
BigQuery を活用した Universal Commerce Protocol（UCP）分析（プレビュー版提供開始）により、販売者やデベロッパーは UCP から BigQuery にリアルタイムイベントを直接ストリーミングできるようになります（サンプルを参照）。この統合により、エージェント型コマースでオブザーバビリティ機能がすぐに使えるようになり、チームはコンバージョンプロセスのモニタリング、自動購入手続きのパフォーマンスの追跡、システムエラーの特定が可能になります。BigQuery 内でこれらの指標を標準化することで、企業は AI によるトランザクションと既存のビジネスインテリジェンスワークフローのギャップを埋めることができます。

新しいエージェントやツールへのアクセス方法について詳しくは、このページにある各ドキュメントへのリンク先をご覧ください。また、データエージェントは、Gemini Enterprise と Google Cloud コンソールからもご利用いただけます。

- Google Cloud、プロダクト管理担当、Sean Rhee

- Google Cloud、アウトバウンドプロダクト管理責任者、Geeta Banda

BigQuery Graph で食品サプライチェーンのデジタルツインをモデリング

Wed, 17 Jun 2026 00:40:00 +0000

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

成長中のレストランの例

レストランチェーンを経営している場面を想像してみてください。ビジネスがどのように動いているのかを、実際に一つひとつ見たり触れたりして把握することは至難の業です。ビジネスの健全性を把握するには、その状態を感知するためのツールと、ビジネスのデジタルレプリカが必要です。

成長に伴う摩擦

成長は、スプレッドシートだけでは解決できない特有の摩擦を生み出します。

ブルウィップ効果: 下流の需要の小さな変化が、上流では在庫の大きな変動へと膨らみます。
SOP の逸脱: 標準的な仕込み作業からのわずかな逸脱が、やがてブランド全体の雰囲気を損なっていきます。
食品安全上の影響範囲: 汚染された 1 つの食材が、ネットワーク全体に広がる複雑なリスクを生み出します。
管理外支出: 各店舗のマネージャーが契約外で食材を購入することで発生する「100 万ドル規模の漏れ」です。

デジタルツイン

デジタルモデルは、世界についてより深い問いを立てる力を与えてくれます。一方で、データをどのように構造化するかという重要な選択も迫っています。従来はリレーショナルテーブルが標準でしたが、今でもあらゆる用途に最適なツールといえるのでしょうか。私たちの世界が本質的に相互につながっていることを踏まえると、現実を捉えるためにグラフベースのモデルに移行することは、自然な進化と言えるかもしれません。

数千ものアセット、複雑なサプライチェーン、グローバルなロジスティクスネットワークを管理する場合、従来のリレーショナルデータベースでは、依存関係をたどるためにリソースを大量に消費する大規模な SQL 結合が必要になります。このアーキテクチャでは、現実世界で起きた事象を運用上の認識に反映するまでに、レイテンシのギャップが生じます。

BigQuery Graph でのモデリング

BigQuery Graph を使用すると、既存のデータプラットフォーム内で、サプライチェーン全体のデジタルツインを構築できます。現実世界のアイテム、レシピ、場所を、検索可能なノードとエッジのマップに変換することで、これまで以上に明確に関係性を把握できるようになります。

1. セマンティックレイヤを定義する

データを新しいデータベースに移動する代わりに、既存のテーブル上にグラフビューを作成します。これにより、テーブル同士がどのように関連しているかを BigQuery に正確に伝えることができます。

クエリ言語:

code_block: <ListValue: [StructValue([('code', '# グラフのノードとエッジを構築する\r\nCREATE or REPLACE PROPERTY GRAPH `restaurant.bombod`\r\nNODE TABLES (\r\n `restaurant.item` label item properties all columns,\r\n `restaurant.location` label location properties all columns,\r\n `restaurant.itemlocation` label itemlocation properties all columns\r\n)\r\nEDGE TABLES (\r\n `restaurant.bom`\r\n KEY(bomKey)\r\n SOURCE KEY (childItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n DESTINATION KEY (parentItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n LABEL consists_of properties all columns\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de91a610>)])]>

BigQuery Graph でモデル化した架空のレストランサプライチェーンの画像

実務で活きる精度

この変化は、日々の業務をどのように変えるのでしょうか。ビジネスを、混乱した対応から精度の高い対応へと移行させます。

外科手術のように正確なリコール対応: サプライヤーからリステリア菌の発生が報告された場合、グラフを前方にたどることで、どのレストランのどのメニュー項目が影響を受けるのかを正確に特定できます。
気象リスク分析: ハリケーンが配送センターに迫っている場合、単なる店舗リストではなく、影響が及ぶ範囲を把握できます。そのハブに大きく依存している拠点を特定し、物資の配送ルートを変更できます。

2. 検索を実行する

グラフクエリは、モデラーやデータサイエンティストがデータをクエリするための新しいツールです。複数のドメインにまたがる複雑なデータ概念を扱いやすくし、クエリを簡素化することで、データ分析を、問題の構造をより自然に表現するものにします。たとえば、鶏肉を扱っているすべての拠点を知りたい場合は、次のようなグラフクエリを実行できます。

特定の苦情やリスクを調査するには、グラフクエリ言語を使用してモデルを検索します。

Graph Query Language

code_block: <ListValue: [StructValue([('code', "# 特定の食材に関する問題の発生源をたどる\r\nGraph restaurant.bombod\r\nMATCH (a:itemlocation)-[c:consists_of]->(b:itemlocation)\r\nWHERE b.itemKey LIKE '%Chicken%'\r\nRETURN to_json([to_json(a),to_json(c),to_json(b)]) as result"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de91a040>)])]>

悪臭の発生源をグラフとしてモデル化した例

将来を見据えて

デジタルツインを最大限に活用するには、次の基本原則に沿って進めることが重要です。

構造に重点を置く: 関係性や依存関係にはグラフを使用し、日次売上の合計などはリレーショナルテーブルに保持します。
キーを整備する: データエンジニアリングに時間をかけます。グラフの価値は、その接続の正確さによって決まります。
エッジのプロパティを取得する: リードタイムや送料などのメタデータをエッジに直接保存することで、モデルの有用性を高めます。

まとめ

レストラン業界は、ビジネスデータを単なるリストとして扱うリレーショナルな方法だけでは対応しきれない段階に来ています。BigQuery Graph を使用して、ドメイン間の関係をデジタルツインとして構築することで、事後対応型の問題解決から先を見越したモデリングへと移行できます。ネットワークをリストで管理するのはもうやめて、つながりを数秒で把握できるようにしましょう。

使ってみる

チュートリアルはこちら
BigQuery のドキュメントを見る: 概要とクイックスタートガイドをご覧ください。
フィードバックを共有する: コミュニティに参加するか、bq-graph-preview-support@google.com までお問い合わせください。
関連ブログ: BigQuery Graph のご紹介

- Google Cloud、クラウドトランスフォーメーション技術リード Guru Rangavittal

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

AlloyDB ホットスタンバイ: 高速なフェイルオーバー、安定したパフォーマンス

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

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

AlloyDB for PostgreSQL は、特に要求の厳しいエンタープライズデータベースワークロード向けに設計された、PostgreSQL 互換のフルマネージドデータベースサービスです。PostgreSQL の優れた機能と Google の強みを組み合わせ、卓越したパフォーマンス、スケーラビリティ、可用性を実現します。Google は、AlloyDB のレジリエンスをさらに高めるべく絶えず革新を続けており、このたび、高可用性（HA）アーキテクチャの重要なアップグレードであるホットスタンバイを発表しました。

AlloyDB の HA アーキテクチャ

高可用性用に構成された AlloyDB プライマリインスタンスは、レジリエンスを確保するために、リージョン内の異なるゾーンに配置されたアクティブノードとスタンバイノードで構成されています。AlloyDB のクラウドネイティブアーキテクチャでは、コンピューティングとストレージが分離されているため、各リソースを個別にスケールできます。データベースの write-ahead log（WAL）は、耐久性を確保するためにリージョンログ永続化レイヤに同期的に書き込まれます。一方、データブロックは AlloyDB のリージョンストレージサービスに保存されます。ロードバランサは、固定 IP アドレスを使用して、現在アクティブなノードにトラフィックを転送します。

従来の HA モデルでは、アクティブノードが使用できなくなった場合、AlloyDB が自動的にフェイルオーバーを開始し、スタンバイノード（PostgreSQL からはアイドル状態に見えている）が、データベースを起動し、残りのログを処理し、アクティブノードを引き継ぎます。これにより高可用性が確保されますが、データベースの起動時間とそれに続くキャッシュウォーミング期間が、アプリケーションの復旧時間やパフォーマンスに影響を与える可能性がありました。

新しいアーキテクチャ: AlloyDB ホットスタンバイ

このたび新たに提供を開始したホットスタンバイ機能により、スタンバイノードの役割は大きく変わります。スタンバイノードは、受動的なノードではなくなり、プライマリからストリーミングされる WAL レコードを継続的に適用するようになります。このアーキテクチャの変更により、2 つの大きなメリットがもたらされます。

フェイルオーバー時間の劇的な短縮: スタンバイ側では PostgreSQL がすでに実行、初期化されており、アクティブにレプリケートされているため、障害発生時にスタンバイをプライマリに昇格させるために必要な時間が大幅に短縮されます。システムは障害を検出（通常は 30 秒以内）し、スタンバイを昇格させて接続をリダイレクトします。スタンバイ側でのデータベース起動フェーズが不要になるため、全体的なダウンタイムや目標復旧時間（RTO）を短縮できます。
フェイルオーバー後の安定したパフォーマンス: ホットスタンバイノードはログをアクティブに再生するため、そのメモリキャッシュ（PostgreSQL バッファキャッシュなど）は「ウォーム」な状態に保たれます。このキャッシュには、プライマリノードのキャッシュと同様に、アクセス頻度の高いデータが多く含まれています。フェイルオーバーが発生すると、新しいプライマリはほぼ即座に最適な速度でリクエストを処理できます。これにより、キャッシュがディスクからウォームアップする間に通常見られるパフォーマンスの「ブラウンアウト」を回避し、アプリケーションのパフォーマンスを安定させることができます。

そして何よりすばらしいのは、この可用性とレジリエンスの大幅な向上は、追加費用なしで実現できます。

ホットスタンバイの仕組み

新しいホットスタンバイ HA と従来の HA 構成の違いを示す簡単なデモをご用意しました。この動画では、2 つの AlloyDB インスタンスでベンチマーク負荷を実行し、両方で同時にフェイルオーバーをトリガーしています。

デモの概要:

ホットスタンバイのインスタンスは、約 15 秒でフェイルオーバーを完了します。重要なのは、1 秒あたりのトランザクション数（TPS）がフェイルオーバー前のレベルにほぼ即座に戻ることです。
従来の HA のインスタンスでは、フェイルオーバーの完了に明らかに時間がかかっています。オンラインに戻った後も、TPS は大幅に低下したままであり、キャッシュがウォームアップし、元のパフォーマンスレベルに戻るまで数分を要しています。

このように並べて比較すると、ダウンタイムを最小限に抑え、フェイルオーバー後のパフォーマンスへの影響を排除できるホットスタンバイのメリットが明確にわかります。

強化された HA を使ってみる

ホットスタンバイは、PostgreSQL 18 で新規作成される AlloyDB インスタンスに順次ロールアウトされ、アップグレードされた HA エクスペリエンスを自動的に提供します。また、以前のメジャーバージョンも、今後数か月以内にロールアウトされる予定です。AlloyDB の 99.99% の SLA は引き続き確保され、フェイルオーバーが高速化されたほか、フェイルオーバー後のパフォーマンスの予測可能性も向上しています。

この機能強化は、最高水準のエンタープライズグレードのマネージド PostgreSQL エクスペリエンスを提供するという Google のコミットメントをさらに明確に示すものです。

AlloyDB の高可用性機能の詳細については、公式ドキュメントをご覧ください。AlloyDB をまだご利用でない場合は、今すぐお試しください。

- シニアプロダクトマネージャー、Emir Okan

- エンジニアリングマネージャー、Ramkumar Vadali

Cloud Run、Firebase、Cloud SQL を使用したフルスタックのバイブコーディングが AI Studio で可能に（クレジットカードは不要）

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

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

Google I/O 2026 では、Google AI Studio と Google Cloud のインテグレーションに関する最新情報を発表しました。

新規ユーザーは、請求先アカウントなしで、フルスタックアプリケーションを 2 つまで Google Cloud スターターティアにデプロイ可能
データベースの選択肢の拡大: 非リレーショナルデータ用の Firestore と、新しいリレーショナルデータベースオプションとしての Cloud SQL
Firebase Auth を単一のユーザーログインフローとして使用することで、Google スプレッドシート、Google カレンダー、Gmail などの Google Workspace ツールとの緊密なインテグレーションを実現

これらは、3 月に発表したインテグレーションのアップデートであり、これには、Cloud Run、Firestore、Firebase Auth を活用することで、バイブコーディングされたフルスタックアプリケーションを AI Studio からデプロイするためのサポートが含まれていました。

このインテグレーションの拡大により、AI Studio を使用してより幅広いアプリケーションを構築できるようになりました。データベースには、Cloud SQL を使用したリレーショナルデータベースか、Firestore を使用した非リレーショナルデータベースのいずれかを使用できますが、ユーザーがデータベースを指定する必要はありません。AI エージェントが、アプリや機能に適したデータベースを自動的に判断します。

ぜひ実際にお試しください。AI Studio では、スターターティアで Cloud Run、Cloud SQL for PostgreSQL（来月提供開始）、Firestore、Firebase Auth を無料でご利用いただけます。

AI Studio から Cloud Run へ、フルスタックアプリケーションをワンクリックで公開

手軽に導入: Google Cloud スターターティア

AI Studio でアプリケーションを構築して、プロトタイプを Cloud Run に直接デプロイしたり、Firebase Auth で認証を行ったり、データを Firestore や Cloud SQL データベースに保存したりできます。クレジットカードや Google Cloud アカウントは必要ありません、面倒な手続きも一切不要です。プロンプトを入力するだけで、すぐに開始できます。

AI Studio では、アカウントがない場合は、Google Cloud スターターティアを使用してリソースが作成されます。フルスタックアプリケーションは 2 つまでデプロイできます。スターターティアの制限を超えた場合は、請求先アカウントが登録されている標準の Google Cloud プロジェクトにアップグレードできます。すべてのリソースが課金対象の Google Cloud プロジェクトに移行されるため、アプリケーションを成長に合わせてスケールできます。

Cloud SQL でフルスタックのバイブコーディングを強化

インテリジェントかつ自動化されたデータ基盤を導入することで、デベロッパーは、インフラストラクチャではなくアプリケーションに集中できるようになります。

AI Studio と Cloud SQL のインテグレーションには、以下が含まれます。

即座に利用開始: インスタントプロビジョニングにより、プロンプト入力から完全にデプロイされた PostgreSQL データベースの利用までを迅速に実現できます。
無料で開始: クレジットカードや Google Cloud アカウントがなくても、Google Cloud スターターティアで Cloud SQL を無料でお試しいただけます。
柔軟な費用管理: AI エージェントは新しい Cloud SQL for PostgreSQL デベロッパーエディションを使用します。これにより、バックエンドが自動的にゼロにスケールできるようになります。課金されるのはアプリを使用している間のみです。
エージェント主導のエクスペリエンス: 新しいプロンプトを入力するだけでアプリケーションを更新できます。AI エージェントが自動的にスキーマを作成し、データベース内で SQL ステートメントを実行します。
グローバルなスケーラビリティ: インターフェースはシンプルですが、アプリケーションは Google Cloud の堅牢で信頼性が高く、安全に設計されたインフラストラクチャ上で実行されます。数百万人ものユーザーをサポートするようにスケールすることも可能です。

Cloud SQL for PostgreSQL デベロッパーエディションを活用したアプリの作成

Firestore と Firebase Auth を使用したフルスタックのバイブコーディング

AI Studio でアプリを構築する際、エージェントは、プロンプトに基づいてデータストレージや認証が必要かどうかをプロアクティブに検出し、データベースやユーザー認証の設定を提案します。ドキュメントデータベースが役立つアプリの場合、エージェントは、Firestore や Firebase Authentication を有効にするカードを表示し、ユーザーの承認を求めます。

アプリケーションで Firebase を有効にするかどうかの確認を求めるエージェント

[Firebase を有効にする] をクリックすると、エージェントは自動的に以下の処理を行います。

Firestore をプロビジョニングし、認証を有効にして、アプリをデータベースに接続する
ウェブアプリのログインページを作成し、Google ログインによる認証を構成する
アプリ内で Firestore コードを生成し、セッションやデバイス間でデータを同期できるようにする
アプリのロジックに基づいて Firestore セキュリティルールの下書きを作成してデプロイする（ただし、アプリの共有やデプロイを行う前に、ユーザーがこれらのルールを必ず再確認する必要があります）

Firebase Auth を使用すると、以下のことが可能になります。

自然言語を使用してアプリを Google Workspace に接続する: Workspace の機能（Google スプレッドシート、Google カレンダー、Gmail など）をリクエストすると、エージェントは Firebase Authentication を利用した「Google でログイン」フローを実装し、Google AI Studio がデータに安全にアクセスできるようにします

Firebase Authentication を利用してアプリを Google スプレッドシートに接続

詳しくは、Google I/O で発表された Firebase の最新情報に関するブログ記事をご覧ください。

AI Studio を使ってみる

アイデアをアプリで実現することは、もはや絵空事ではありません。以下の手順に沿って進めることで、フルスタックアプリケーションを無料で構築できます。

AI Studio にログインする: プラットフォームにアクセスしてプロジェクトを開始します。
プロンプトを使用して構築する: 自然言語のプロンプトを使用してアプリケーションの構築を開始します。たとえば、「経費管理アプリを構築して」などと指示します。
データベースを有効にする:「データベースを追加して」という指示をすると、AI Studio が「Enable」ウィジェットを通じてデータベースをインテリジェントにプロビジョニングします。特定のリレーショナルデータベースを明示的に指定することもできます。
システムを設定する: [Enable] を選択し、利用規約に同意します。
共有を開始: [Publish] ボタンを使用してアプリケーションをデプロイし、共有します。

AI Studio を今すぐ利用して、アイデアを数秒でライブアプリケーションに変換しましょう。

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

- プロダクトマネージャー、Gopal Ashok

Urban Outfitters、Sterling OMS を AlloyDB for PostgreSQL に移行して大幅な費用削減を実現

Tue, 02 Jun 2026 02:00:00 +0000

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

編集者注: Urban Outfitters, Inc.（URBN）は最近、大規模なインフラストラクチャのアップグレードを完了し、既存の IBM Sterling Order Management System（Sterling OMS）の Oracle データベースを Google Cloud の AlloyDB for PostgreSQL に移行しました。Google Cloud と IBM のパートナーシップの拡大を証明するこの戦略的な取り組みは、URBN に大きなメリットをもたらし、効率向上と費用削減を実現したほか、将来を見据えたテクノロジー環境の構築への道を開きました。この成功事例は、企業が AlloyDB for PostgreSQL を活用してデータベースをモダナイズし、新たなレベルのパフォーマンスとスケーラビリティを実現する方法を示しています。

変化の速い小売業界において、注文管理はシームレスなカスタマーエクスペリエンスの基盤となります。Urban Outfitters, Inc.（URBN）は、IBM Sterling Order Management System（Sterling OMS）を同社のグローバルな e コマース事業の中心に据え、注文の受付から、リアルタイムの在庫追跡、納品の最適化、購入後のロジスティクスに至るまで、あらゆる業務をオーケストレートしていました。このシステムは、店舗、倉庫、デジタルチャネルのグローバルネットワーク全体で数百万件のトランザクションを効率的に処理でき、迅速で正確かつ柔軟に注文を処理するという顧客の期待に応えられるものでした。

しかし、この重要なシステムの基盤である 11 TB もの巨大な Oracle データベースが、次第にボトルネックになりつつありました。また、高額なライセンス費用や保守費用、増大する運用上の複雑さ、独自技術による制約が、スケーラビリティと長期的なイノベーションにとって重大な課題となっていました。そのため、Sterling OMS の高可用性、パフォーマンス、トランザクションの整合性を維持するために、以下のような要件を満たす最新のデータベースソリューションが必要になりました。

総所有コスト（TCO）の削減: 信頼性を維持しながら、ライセンス費用、運用上のオーバーヘッド、インフラストラクチャ費用を削減する。
ビジネス継続性の確保: 高可用性、迅速なフェイルオーバー、障害復旧をサポートし、注文処理や顧客取引の中断を防ぐ。
オープンスタンダードの採用: 独自技術から移行し、オープンで柔軟性があり、将来を見据えたソリューションを採用する。
同等の機能の維持: Sterling OMS の機能を損なうことなくシームレスな移行を実現し、すべてのミッションクリティカルな機能をそのまま維持する。

URBN のような小売企業においては、注文管理のわずかな不具合でさえ、財務面や運用面に重大な影響を及ぼす可能性があります。取引の失敗、在庫の予測ミス、納品の遅延は、顧客満足度、ブランドの評判、収益に直接影響します。Sterling OMS はミッションクリティカルなシステムであるため、URBN は技術的に堅牢かつ正確な移行アプローチを必要としていました。そのため、ダウンタイム、データ損失、パフォーマンス低下をほぼゼロに抑えた移行が求められました。

ソリューション: AlloyDB for PostgreSQL

この複雑な移行の成否は、URBN、IBM、Google Cloud による緊密かつ継続的なコラボレーションにかかっていました。このパートナーシップにより、業界をリードする専門知識と最先端の技術が結集し、各チームが全フェーズを通じて綿密に連携して取り組みました。URBN の技術スタッフと IBM と Google Cloud の専任エンジニアが直接連携することで、各チームは大規模なデータベースの移行を綿密に計画し、最適化できました。

このプロジェクトの成功は、以下のような重要な柱によって支えられました。

ファーストティアデータベースの認識と機能開発: IBM と Google Cloud のエンジニアリングチームが協力して、Sterling OMS で AlloyDB for PostgreSQL をファーストティアデータベースとして完全に認識し、サポートできるようにしました。
2 つの読み取りレプリカによるエンタープライズグレードの信頼性: パフォーマンスを向上させ、高可用性とスケーラビリティを実現するために、AlloyDB のデプロイアーキテクチャには 2 つの読み取りレプリカが含まれています。これにより、レポート作成や分析のためのデータへの低レイテンシアクセスが可能になり、Sterling OMS アプリケーション全体のオペレーショナルレジリエンスが向上します。
広範なパフォーマンスチューニング: Google Cloud の専任のパフォーマンスエンジニアリングチームが、URBN と IBM のエキスパートと協力して、データベースクエリの微調整と構成の最適化を行いました。このような継続的かつ高品質なサポートにより、AlloyDB は以前の Oracle データベースのパフォーマンスベンチマークを達成しただけでなく、それを上回る成果を上げることができました。この作業は、AlloyDB 上で Sterling OMS の膨大なトランザクション量を処理する、URBN のような非常に大規模な小売業者にとって不可欠です。
厳格な切り替えテストとリスク軽減: Google Cloud と IBM のチームは、厳格かつ反復的な切り替えテスト戦略で URBN を支援しました。この戦略には、Sterling OMS システムで AlloyDB を丸 1 日稼働させてから Oracle データベースに戻すという作業が含まれていました。このプロアクティブなテストにより、URBN のチームは制御された環境下で潜在的な問題を特定、解決でき、リスクを大幅に軽減するとともに、移行後のシステムに対する信頼性を高めることができました。

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

変革をもたらす転換

AlloyDB への移行により、URBN のデータ戦略は根本的に再構築されました。パフォーマンスや信頼性を損なうことなく、最適化されたストレージとコンピューティングアーキテクチャを通じて、より望ましい TCO を実現しています。さらに、PostgreSQL 互換データベースである AlloyDB への移行により、オープンソースエコシステムの柔軟性を手に入れました。この移行により、ベンダーロックインから解放されるだけでなく、活気のあるコミュニティやさまざまな最新ツールにアクセスできるようになり、長期的な技術的アジリティの確保につながりました。

この移行によって、費用や柔軟性の面だけでなく、優れたパフォーマンスと拡張性が実現し、URBN のミッションクリティカルな業務をサポートできるようになりました。また、最適化されたデータベースカーネルと高精度のクエリ調整を組み合わせることで、大幅な速度向上を実現し、Sterling Commerce システムの応答性を直接的に高めることができました。

成功への道筋: 計画とテスト

URBN が IBM Sterling OMS での AlloyDB への移行を成功させたこの事例は、ミッションクリティカルなインフラストラクチャをモダナイズし、AI の拡張に備えた将来性のある環境を構築しようとする組織にとってのブループリントとなります。組織をまたいだ緊密なパートナーシップと、段階的にリスクを軽減するアプローチの組み合わせは、極めて複雑なミッションクリティカルな移行でさえも実現できることを証明しています。

モダナイゼーションの課題に直面している企業にとって、URBN の事例は成功への明確なロードマップとなります。AlloyDB 上でシステムを実行し、元の環境に戻すという反復的な切り替えテストの実施は、本番稼働に必要な信頼を築くための「秘訣」でした。このレベルの厳格なテストを優先することで、企業はよりアジリティと効率性に優れ、イノベーションに満ちた未来へと進むことができます。

その他の情報

AlloyDB が PostgreSQL の優れた機能と Google Cloud の強みを組み合わせている方法を紹介している最新の電子書籍。
AlloyDB を 30 日間無料で試せる AlloyDB の無料トライアルクラスタ。
AlloyDB for PostgreSQL の詳細。

- Urban Outfitters、CIO、Rob Frieman 氏

- Google Cloud、プロダクト管理、データベース担当バイスプレジデント、Raj Pai

将来を見据えたデータ戦略のために: AlloyDB に PostgreSQL 18 と新しい延長サポートを追加

Fri, 22 May 2026 02:00:00 +0000

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

2026 年のインフラストラクチャロードマップを検討するにあたっては、迅速なイノベーションの必要性と運用上の安定性のバランスを取ることが目標となります。最新のデータベース機能を導入することと、ワークロードに対応した安全な環境を維持することのどちらか一方を選択する必要はないはずです。この投稿では、AlloyDB での PostgreSQL 18 の一般提供と、以前のメジャーバージョンに対する延長サポートの提供についてお知らせいたします。これらのアップデートにより、既存のアプリケーションに信頼性の高い長期的なセーフティネットを提供しながら、最先端のオープンソースツールを使用して柔軟に構築を行えるようになります。

延長サポートで安定性を維持

本番環境のワークロードを新しいメジャーバージョンに移行するのは重大な作業であり、入念な計画とテストを必要とします。お客様がセキュリティを損なうことなく、各社のスケジュールで柔軟にアップグレードができるように、AlloyDB の延長サポートをご用意いたしました。

この新しいサービスは、コミュニティによるサポートが終了した日から、お客様のアップグレード予定までの期間をカバーし、特に重要なアプリケーションのビジネス継続性を確保します。

主なスケジュール

AlloyDB クラスタは 3 年間の延長サポートの対象となり、以下のスケジュールに沿って自動的に登録されます。

PostgreSQL 14: 2027 年 2 月 1 日から 2030 年 2 月 1 日まで。
PostgreSQL 15: 2028 年 2 月 1 日から 2031 年 2 月 1 日まで。
PostgreSQL 16: 2029 年 2 月 1 日から 2032 年 2 月 1 日まで。
PostgreSQL 17: 2030 年 2 月 1 日から 2033 年 2 月 1 日まで。
PostgreSQL 18: 延長サポートのスケジュールは後日発表します。

内容

延長サポート期間中、Google Cloud は以下を提供します。

重要なセキュリティパッチ: 重大度が「高」または「重大」のすべての共通脆弱性識別子（CVE）に対する保護
プロアクティブなバグの修正: AlloyDB で維持されているコード内の問題解決
SLA の適用範囲: 条件を満たすクラスタの可用性保護を継続
新しいクラスタの作成: 延長サポートのバージョンで新しいクラスタをプロビジョニングする機能

移行の管理

延長サポートは追加料金でご利用いただけます。クラスタを通常サポートの対象であるメジャーバージョンにアップグレードするだけで、いつでもオプトアウトできます。延長サポートと改定料金については、年内にお知らせします。

AlloyDB 上の PostgreSQL 18 で開発を加速

PostgreSQL 18（PG18）では、アプリケーションの高速化と開発プロセスの直感的な操作を目的とする機能が導入されました。AlloyDB クラスタに PG18 を選択すると、パフォーマンスの向上と最新のデータ処理にすぐにアクセスできます。

B ツリーのスキップスキャンによるクエリ高速化: クエリに一致しないインデックスエントリはバイパスされるため、データ取得が高速化されます。
並列 GIN インデックスの使用: 複数の CPU コアを利用することで、全文検索と JSON 検索を高速化できます。
仮想生成列: 即座に計算される列を使用できるため、追加のディスク容量を使用せずに、保存列と同じ簡単な API を提供できます。
ネイティブ UUIDv7 サポート: 従来のランダム UUID と比べて並べ替え機能とインデックス作成効率に優れた UUIDv7 を使用して、分散アプリケーションを構築できます。

信頼性の実証: UKG がデータ基盤をモダナイズ

本番環境システムを大規模にアップグレードするのは複雑な作業になる場合がありますが、AlloyDB の PostgreSQL では、このプロセスが簡素化され、アップグレード前後のタスクの多くが自動化されています。人事 / 給与ソリューションのプロバイダである UKG は最近、AlloyDB クラスタを PostgreSQL 17 にアップグレードし、準リアルタイムのデータ基盤である People Fabric の新機能を強化しました。大量のデータベースオブジェクトを含む高密度なマルチテナントアーキテクチャの管理は重要な課題でした。インプレースのメジャーバージョンアップグレードを使用することで、UKG はリスクを最小限に抑え、ユーザーへの影響を回避しました。

UKG のデータプラットフォームエンジニアリング担当シニアディレクターである Rajiv Jain 氏は次のように述べています。「数千個のオブジェクトを含むマルチテナント環境のアップグレードは、通常は大きなリスクを伴います。しかし、AlloyDB のインプレースアップグレードパスにより、一般的なダウンタイムやパフォーマンスの低下なしにフリートをモダナイズできました。その結果、People Fabric の最新リリースの目標を達成し、PostgreSQL の新機能をお客様のために活用できました。」

インプレースのメジャーバージョンアップグレードでは、データを移動したり接続文字列を変更したりすることなくデータベースをモダナイズできるため、アップグレード時間を数分に短縮できます。この合理化されたパスは、PostgreSQL 18 を含むすべてのターゲットバージョンに適用されるため、大規模なマルチテナントフリートでも、最小限のダウンタイムで最新の機能を取り入れることができます。このプロセスをクエリプラン管理と組み合わせることで、最新の PostgreSQL リリースへの移行が、迅速かつ低リスク、そして予測可能なものになります。

データベース対応ストレージでパフォーマンスを最大化

AlloyDB は PG18 のイノベーションを基盤に、特殊なアーキテクチャでその機能を拡張しています。コンピューティングとストレージの分離により、負荷の高いデータベースオペレーションは専用のインテリジェントなレイヤにオフロードされます。これには次のような利点があります。

データベース対応のオフロード: AlloyDB はロギングとメンテナンスのタスクを専用のサービスに委任します。このため、プライマリデータベースインスタンスはトランザクションの処理に専念できます。
データの重複なしで水平方向にスケーリング: 読み取り専用レプリカを数秒で追加できます。すべてのレプリカが同じ分散ストレージにアタッチされるため、データの複数のコピーを管理する費用と遅延を回避できます。
優れたコストパフォーマンス: 最近のベンチマークによると、AlloyDB はセルフマネージド PostgreSQL と比べて最大 2 倍の優れたコストパフォーマンスを実現します。コンピューティングリソースがセルフマネージド環境の半分であっても、AlloyDB はカーネルをより効率的に使用することで、1 分あたりのトランザクション数が多くなります。
お支払いは従量制: AlloyDB のストレージは弾力性があります。ストレージサイズを指定する必要はなく、データに応じてシステムが自動的に拡大、縮小されます。
予測可能なスループット: 多くのクラウドデータベースでは、パフォーマンスを向上させるためだけにストレージを追加購入する必要があります。AlloyDB では、ストレージサイズに基づいて速度が制限されることはありません。初日からフルパフォーマンスが得られ、保存したデータに対してのみ料金が発生します。

使ってみる

PostgreSQL 18 インスタンスを作成する: AlloyDB コンソールにアクセスします。
アップグレードを計画する: メジャーバージョンアップグレードに関するドキュメントを確認します。
サポート期間を確認する: 延長サポートに関するドキュメントと、更新されたバージョンのサポートポリシーをご覧ください。

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

Next '26 で Firestore の新機能を発表: エージェントによる開発、検索、MongoDB 互換性を強化

Thu, 21 May 2026 01:30:00 +0000

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

AI エージェントの時代において、画期的なアイデアと実際に使用されるアプリケーションとのギャップはかつてないほど縮まっています。アプリケーションの構築は、エージェントの支援に大きく依存するようになっていますが、重要な疑問が残されたままです。データベースインフラストラクチャは対応できるのでしょうか？

実質的に無制限のスケーラビリティと高可用性を備えた Google Cloud のフルマネージドドキュメントデータベースである Firestore は、急速に普及しつつあるエージェントアプリケーションに最適な存在です。Firestore は AI を活用したアプリケーション向けにさらに強化され、Google Cloud Next ‘26 で以下の新機能が発表されました。

エージェント型 AI とのより緊密な統合: AI Studio やサードパーティのコーディングエージェントとのネイティブな統合が実現し、LLM とデータベースが同じ言語でやり取りできるようになりました。
全文検索と表現に優れたクエリ: 他に類を見ない検索機能とパイプラインオペレーションにより、エージェントとユーザーはデータの中から必要なものをピンポイントで見つけられるようになりました。
MongoDB 互換性の強化: 既存の MongoDB ワークロードの Firestore エコシステムへの移行がこれまで以上に簡単になりました。

このブログでは、Next ‘26 での発表内容を詳しく見ていきます。その前に、Firestore の概要をおさらいしておきましょう。

Firestore の特長

従業員による独自の生産性向上ツール作成を支援したい企業幹部も、突然浮かんだアイデアを割り箸袋に書き留めている起業家も、求めるものは同じです。考える速度でプロトタイプを作成し、フィードバックを得た瞬間に軌道修正し、それらすべてを銀行口座を破綻させることなく行う、そしてもちろん、データベースも破綻させてはなりません。

だからこそ、データベースを選択する際には、次のことを考慮する必要があります。

スケーリング: そのデータベースは、トラフィックの急増に耐えられますか？
費用効率: そのソリューションは、運用停止中はゼロへのスケーリングで費用を節約できますか？
イテレーション速度: エージェントのプロンプトを頻繁に調整する場合、費用のかかるデータベーススキーマ移行が必要になってパフォーマンスが低下しませんか？

Firestore は、まさにこうした懸念を払拭するために設計されました。Firestore は、サーバーレスアーキテクチャにより、常に迅速で自動的かつ弾力性のあるデータベーススケーリングを簡単に実現してきました。このアーキテクチャはプロビジョニングも簡単で瞬時に完了します。同時に、Firestore のドキュメントモデルはデータ構造のイテレーションを簡素化かつ高速化します。スキーマの変更による中断やダウンタイムはなく、パフォーマンスが低下しません。

開発速度の加速がエンタープライズガバナンスを犠牲にするようなことは、決してあってはなりません。Firestore は、業界随一の 99.999% の SLA と ACID 準拠のトランザクションを提供し、Google Cloud に本質的に備わる厳格なセキュリティとプライバシーの監視能力をそのまま受け継いでいます。

Firestore の有用性は多くの企業に高く評価されています。たとえば、FlutterFlow からは以下のコメントをいただいております。

「ウェブとモバイル開発の民主化を専門とする AI ネイティブ企業として、FlutterFlow は Firestore を基盤データベースに採用し、150 か国以上にわたるユーザーベースを 0 から 300 万人以上にスケールアップしてきました。過去 5 年間、7, 500 億件以上の読み取りと 750 億件の書き込みを処理しながら、一度も停止したことはありません。当社は Firestore を心から信頼しています。」 - FlutterFlow、CEO / 共同創業者、Abel Mengistu 氏

では、Next ‘26 で発表された Firestore の新機能を見ていきましょう。

1. エージェント型 AI の統合でアプリケーション開発を加速

Firestore を AI のクリエイティブプロセスに直接組み込みました。AI Studio とのネイティブな統合が実現し、デベロッパーは、Firestore データベースと統合されて追加認証を備えたフルスタックアプリケーションを、単一の自然言語プロンプトから構築してプロビジョニングできるようになりました。この統合は Firestore に大きな勢いをもたらし、Firestore のデベロッパーベース全体を月間アクティブデベロッパー数 75 万人、ホストされているデータベース数 1,000 万以上にまで押し上げました。

デベロッパーは、自然言語のプロンプトを 1 つ入力するだけで、AI Studio を通じて Gemini を活用し、データベースとして Firestore を備えたフルスタックのアプリケーションを作成して設定できます。

また、Firestore を Claude Code、Cursor、Codex などのサードパーティ AI エージェントと統合する機能も強化しました。Firestore Skills と Firestore リモート MCP サービスの一般提供により、よく使われている外部エージェントへの接続が一層簡単になりました。

さらに、生産性向上の支援を強化するために、Google Cloud コンソールでの自然言語クエリ（プレビュー版）を導入しました。Gemini Code Assist を活用して、シンプルな自然言語クエリを MongoDB 互換の複雑なクエリに変換できます。

Gemini Code Assist を使用して自然言語でクエリを記述。

2. 他に類を見ない検索とクエリ

高性能でデータが豊富な AI エージェントを構築するには、最新の検索機能とクエリ機能を備えたデータベースが必要です。Firestore の Enterprise エディションではクエリエンジンが一新され、充実したパイプラインオペレーションとともに一般提供が開始されました。数百もの新しいクエリ機能が追加され、微妙な表現に対応するアプリケーションにとって Firestore の優れたサービスは確固たる存在となっています。

組み込みの全文検索も主要な新機能で、現在プレビュー版でご利用いただけます。Firestore の全文検索は Google の検索テクノロジーを活用しており、40 以上の言語をサポートする高品質な関連性モデルを使用して、ユーザーに正確な結果を提供しています。これに対照的なデータベースと検索のハイブリッドセットアップでは、検索インデックスで結果整合性のみが使用されるため、データベースの実データを反映しない検索結果が生成される可能性があります。一方、Firestore の検索インデックスはトランザクションデータと強整合性があるため、より正確な検索結果を導き出します。重要なのは、このネイティブ機能が Firestore のサーバーレスアーキテクチャを継承している点です。これにより、個別の検索インフラストラクチャ管理で生じる運用上の摩擦が大幅に軽減されます。

新しい search() ステージを使用して、既存の Firestore ドキュメントデータを活用しながら、全文検索機能をアプリケーションに統合できます。

さらに、地理空間クエリ機能をプレビュー版として導入しました。これにより、デベロッパーは、周辺の場所検索が容易な位置情報認識アプリケーションを簡単に構築できます。

code_block: <ListValue: [StructValue([('code', "// Find nearby restaurants\r\nfirestore.pipeline().collection('restaurants')\r\n .search({\r\n query: field('location')\r\n .geoDistance(new GeoPoint(38.989177, -107.065076))\r\n .lessThan(1000 /* m */)\r\n });"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de7cd2e0>)])]>

また、今回のリリースでは、かねてからご要望の多かった JOIN 機能も一般提供に含まれています。JOIN 機能はサブクエリによって実装され、パイプラインオペレーションによる異なる複数コレクションの横断的な検索を可能にします。また、コレクション内のドキュメントの一括正規化、サニタイズ、バックフィルを容易にする、組み込みのデータ操作演算子もプレビュー版でリリースされました。

code_block: <ListValue: [StructValue([('code', '// Retrieve all reviews less than 2 stars for a given restaurant\r\nconst pipeline = db.pipeline()\r\n .collection("restaurants")\r\n .define(field("__name__").as("restaurant_id"))\r\n .select("__name__", db.pipeline().collection("reviews")\r\n .where(field("parent_restaurant_id").equals(variable("restaurant_id"))\r\n .where(field("rating").lessThan(2))\r\n .select("review", "rating"))\r\n .toArrayExpression()\r\n .as("negative_reviews"));'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de8770a0>)])]>

さらに、使用状況のモニタリング機能も強化され、より詳細なオブザーバビリティの分析情報が得られるようになりました。たとえば、プレビュー版の新しい Usage Insights を使用すると、コレクションごとの使用状況を確認できます。

Usage Insights によるコレクションごとの内訳を通じて Firestore の使用状況をデバッグできます。

最後に、Firestore はまもなく Knowledge Catalog と統合され、データモデルがどのように進化するかについて、コレクションレベルでより深い分析情報を提供できるようになります。

3. MongoDB との互換性とスケーラビリティを強化

Google は、MongoDB との互換性を強化することで、Firestore への移行と構築を容易にし、エンタープライズワークロードに対する Firestore の有用性を高め続けています。

Firestore は、MongoDB との互換性強化のために、最大 16 MiB の大型ドキュメントもサポート可能になり、複雑なデータ移行や大量のワークロードに対する従来の障壁が取り除かれました。

さらに、リアルタイムのデータ移動をサポートするために、スケーラビリティに優れた変更ストリーム機能も追加しました。これにより、Firestore から BigQuery などのサービスへの変更が大規模に同期できるようになります。この機能は、実質的に読み取り / 書き込みオペレーションを規模を問わずに処理できる設計で、データベースの本番環境トラフィックに合わせて変更ストリームをシームレスにスケールできるため、ユーザーが安心して利用することができます。

MongoDB と互換性のある新しい変更ストリームを簡単に作成して、コレクションやデータベースのデータ変更をリアルタイムでリスニングできます。

また、データライフサイクル管理も改善されました。デベロッパーはコレクションを削除して、より柔軟な有効期間（TTL）のタイムオフセットでデータの自動期限を設定でき、データの削除を効率的に管理できます。しかも、これらの管理オペレーションが、データベースの本番環境トラフィックに影響を与えることはありません。

code_block: <ListValue: [StructValue([('code', 'db.receipts.drop();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f60de877910>)])]>

Firestore を使ってみましょう

これらの新機能は、Firestore Enterprise エディションでご利用いただけます。ネイティブモードと MongoDB 互換モードが用意されています。デベロッパーは、これらの高度な機能をインテリジェントなエージェントアプリケーションに今すぐ組み込むことができます。

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

- Google Cloud、エンジニアリングマネージャー、Patrick Costello

ミリ秒未満の読み取りレイテンシを実現する新しい Bigtable インメモリ階層

Wed, 20 May 2026 02:10:00 +0000

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

デジタルインフラストラクチャの成否が大きく問われる世界では、スピードは単なる指標ではなく、価値そのものです。Google Cloud Next ‘26 で発表した Bigtable インメモリ階層は、フルマネージドのクラウドデータベースサービスに次のような画期的な機能をもたらします。

ミリ秒未満の読み取りレイテンシで時間的制約があるデータを処理
1 ドルあたりのポイント読み取りスループットが最大 10 倍向上、TCO を大幅に削減
ホットスポット耐性により、単一行に対して最大 120,000 クエリ/秒を手間なくサポート

詳しくは、Bigtable のパフォーマンスに関するドキュメントをご覧ください。次に、Bigtable インメモリ階層がワークロードのパフォーマンスと運用プロセスに与える影響を見てみましょう。

キャッシュミスの悪夢: よくあるケース

午前 2 時に、プロモーションキャンペーンが一気に拡散され、トラフィックが急増していると仮定します。あいにく、データベースアーキテクチャはトランプの家のように脆く不安定なため、プライマリデータベースは処理が追いつかず、別のキャッシュレイヤがシールドとして機能している状態です。

そこに突然、アクセス集中の問題が発生しました。拡散された同じコンテンツに皆がアクセスしようとしています。キャッシュノードは飽和状態になっています。より大きなノードにアップグレードするか、リードレプリカを追加するしかありません。チーム全員、疲れ切っています。2 つの異なるシステムを管理し、複雑なキャッシュアサイドのロジックを維持する（そしてキャッシュ内のデータがデータベースと同期していることを祈る）だけでなく、実際のインシデントに対応する必要もあります。そのために、ピーク負荷に対応できるように CPU をオーバープロビジョニングし、すべてがメモリに収まるように RAM を追加し、キャッシュアサイドの複雑さを回避します。これにより、実際にはメモリに保存する必要のないウォームデータに対して、高額な料金を支払うことになります。理論上の 1 ドルあたりのスループットは高いように見えますが、実際にはリソースの 90% がほとんどの時間アイドル状態になっています。

Bigtable のインメモリ階層の登場

Bigtable インメモリ階層はこのサイクルを断ち切ります。RAM、SSD、HDD にまたがるデータ階層化を、ハイブリッドストレージアーキテクチャを備えた単一の統合サービスで実現することで、「仲介役」が不要になります。

その結果、キャッシュの元々のスループットと速度に、Bigtable が設計された目的である耐久性とスケーラビリティが加わります。拡散によりアクセスが急増すると、Bigtable はアクセスが集中している行を自動的にメモリに移動して負荷を処理します。CPU スパイクが発生することも、パフォーマンスが低下することもありません。トラフィックが増加すると、Bigtable クラスタも増加し、インメモリ読み取り能力が向上します。これでアイドル状態の RAM やキャッシュノードに過剰な料金を支払う必要はなくなります。Bigtable がデータをインテリジェントに管理し、ホットデータのみをメモリに保持して、インメモリ階層と SSD ストレージ間のデータ整合性を確保します。

TCO のメリットは明らかですが、おそらく最も重要なのは、それによって得られる安心感です。これはかけがえのないものです。

舞台裏のご紹介

ほぼすべてのデータベースサーバーは、CPU がインデックスや Bloom フィルタなどのレイテンシの影響を受けやすい、頻繁にアクセスされるデータに高速にアクセスできるようにするために、メモリを使用しています。では、この発表のどこが特別なのでしょうか。

その秘密は、リモートダイレクトメモリアクセス（RDMA）にあります。これは、システムのオペレーティングシステムも CPU も関与せずに、コンピュータがあるマシンのメモリから別のマシンのメモリに直接データを転送できる高性能ネットワーキングテクノロジーです。Google のアーキテクチャは、RDMA を使用してサーバーメモリに高速に直接アクセスできるようにします。その結果、インメモリ階層のスループットとレイテンシは、サーバー CPU による制限を受けることがなくなり、大きなメリットにつながります。Data Boost が ML トレーニングなどの負荷の高いワークロードに対してディスクへの直接アクセスを可能にするのと同様に、RDMA はリアルタイム処理においてメモリへの高速な直接アクセスを実現します。

よく利用されているソーシャルメディアサイトを運営しているとします。ユーザーの 98% はフォロワー数 250 人未満ですが、最も人気のあるユーザーはフォロワー数 1 億人以上です。ユーザーの 60% は投稿が週 1 回未満で、上位 10% のユーザーがコンテンツの 80% を生成しています。一般的な投稿の表示回数は 500 回ほどですが、人気のある投稿では数千万回に達します。

このユースケースに効率的に対処するために、次のようなデータ階層化を必要としています。

メモリ: フォロワー数の多いユーザーのプロファイルからのコンテンツ
SSD: 最近のコンテンツ、アクティブなユーザープロファイル
HDD: 古いコンテンツ、非アクティブなユーザープロファイル

幸いなことに、Bigtable ではこれを非常に簡単に行うことができます。クラスタでインメモリを有効にして、データベースリクエストを発行する際にメモリ対応のアプリケーションプロファイルを使用するだけで、ホットデータのライフサイクルを自動的に管理できます。また、エージベースのポリシーを設定して、コールドデータをアクセス頻度の低い階層に分類することもできます。この設定では、コンテンツが読み取られると、そのコンテンツは永続ストレージからメモリ階層に昇格され、それより後に読み取られたアイテムの保存場所を確保するために削除されるまでそこに留まります。この作業に手を煩わせることはありません。5 年前の投稿が突然再浮上して拡散されたとしても、心配無用です。

しかし、キャッシュ保存するものをより細かく制御したい場合はどうすればよいでしょうか。人気のあるコンテンツクリエイターのリストがあり、そのごく一部の投稿にのみメモリ使用量を制限したいとします。そのためには、それらのユーザーに対するトラフィックはメモリ対応のアプリプロファイル経由でルーティングし、他のコンテンツに対してはメモリ対応でないアプリプロファイルを使用するだけです。

キャッシュミスの悪夢を再現

キャッシュミスのシナリオを再現してみましょう。ただし、今回は Bigtable のインメモリ階層を有効にしています。日曜日の午前 2 時に、プロモーションキャンペーンが急速に拡散され、トラフィックが急増しています。今から 1 時間以内に 1 秒あたり 8 万回の読み取りを追加で処理できるようにする必要があります。しかし、通知が来ることはなく、午前 11 時に鳥のさえずりで目覚め、穏やかな朝食と素晴らしい天気で 1 日を始めます。午前 2～3 時の間にトラフィックが急増したことを示す唯一の証拠は、請求額が 0.40 ドル増えていることです。

幅広い業界においてアプリケーションに対するリクエストの分布はべき乗則に従うため、このようなシナリオはソーシャルメディアに限定されません。たとえば、証券取引所では数千の証券が取引されますが、最も活発に取引される上位 30 銘柄が通常、1 日の総取引量の 40% 以上を占めています。同時に、最新のデータポイント（最終取引、売値 / 買値）は頻繁にリクエストされ、低レイテンシのレスポンスが期待されますが、過去のデータへのアクセスははるかに頻度が低く、レイテンシの許容範囲は比較的広くなります。この例のデータを Bigtable のデータ階層に分類してみましょう。

メモリ: 最も人気の高い株式の直近の証券価格
SSD: 最近の履歴、集計指標（時間単位、日単位、月単位など）
HDD: 古いデータ、個々の取引などの未加工のイベント

この機能のユースケースは多岐にわたります。自動取引システムはメモリから最新の価格にアクセスし、個人投資家は SSD のデータからローソク足チャートを作成し、クオンツは Data Boost を使用して HDD の過去のデータにアクセスしてモデルをバックテストします。すべてが 1 つのデータベースに格納されており、互いに干渉することはありません。金融時系列をテレメトリーデータ、センサーネットワーク、デジタルツインに置き換えても、ストーリーはそれほど変わりません。

また、Bigtable のインメモリ階層を使用しても、高可用性、スケーリング、監査、ガバナンス、アクセス制御などの他のエンタープライズ機能が妨げられることはありません。これらの機能は通常、大きなオーバーヘッドを発生させます。このような企業要件を満たしながら、ミリ秒未満のレイテンシを実現していることは非常に印象的です。また、クライアントとネットワークを最適化することで、p50 SSD レイテンシを 2 ミリ秒未満に短縮することもできました。

Bigtable Enterprise Plus を使ってみる

Bigtable インメモリ階層は、新しい Bigtable Enterprise Plus エディションでのみご利用いただけます。このエディションは、多くの追加機能を備えており、最高レベルのパフォーマンスと管理効率を求める組織向けに設計されています。

今すぐスタックを Bigtable Enterprise Plus とインメモリ機能にアップグレードして、インフラストラクチャの管理をやめ、未来の構築を始めましょう。

詳細

Bigtable Enterprise Plus エディションと、そのインメモリ階層以外の機能の詳細をご覧ください。Google Cloud コンソールにアクセスして、新しいクラスタを作成したり、既存のクラスタをアップグレードしたりして、ぜひお試しください。
Bigtable を初めてご利用になる方は、新しい Bigtable 無料トライアルで Google の先駆的な NoSQL データベースをご体験いただけます。専用の Enterprise Edition ノード、500 GB のストレージ、Bigtable の使い方ガイドをご利用ください。
利用開始方法、技術仕様、リージョン別の提供状況について詳しくは、Bigtable の公式プロダクトページをご覧ください。

- Bigtable、シニアプロダクトマネージャー、Anton Gething

- Bigtable、エンジニアリングマネージャー、Sudarshan Kadambi

データベースの新機能: エージェントの未来を強化

Fri, 01 May 2026 00:30:00 +0000

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

エージェントの時代を迎え、企業データの役割は受動的なリソースから能動的な「行動のシステム（System of Action）」へと変化しています。そこで Google は、モデル、分析、運用データベースを単一の AI ネイティブシステムに統合する統合型アーキテクチャ Agentic Data Cloud を発表しました。これにより、組織はデータの可能性を最大限に引き出すことができ、すべての AI アプリケーションとエージェントで真実に基づいた運用を行い、費用が急に膨らむようなことなくリアルタイムでアクションを実行できるようになります。

現在、Google は以下の取り組みを進めています。

データスタック全体に AI を組み込むことで、他に類を見ない最適化されたデベロッパーエクスペリエンスを実現しています。
トランザクションと分析の領域を統合し、手動による統合の手間を解消します。
管理が一段と容易でより迅速なデプロイが可能な業界トップクラスのオープンデータベースにより、エンタープライズグレードのデプロイを簡素化します。

データスタックのあらゆるレイヤに AI を組み込む

Google は、AI エージェントとエンタープライズデータベース間のスムーズかつ継続的な接続を可能にすることで、手間のかからないエージェント主導のデータベースエクスペリエンスを実現します。現在、シチズンデベロッパー向けのバイブコーディングツールから、エンタープライズ向けの大規模なベクトル検索まで、データベースがエージェントワークフローの主要なコンポーネントの一つとなっていることは明らかです。

主なリリースは次のとおりです。

AI Studio によるデータベースのバイブコーディング統合: クリエイターを支援するため、Google は最先端のバイブコーディングプラットフォームである Google AI Studio との連携機能を提供します。このエージェント主導の自動ワークフローを使うことで、シンプルなテキストプロンプトからライブアプリケーションを数秒で作成し、そのアプリケーションを Firestore などの信頼できるデータベースサービスに接続できます。Cloud SQL for PostgreSQL のサポートも近日中に提供される予定です。
データエージェント向けツール（プレビュー版）: これらのツールは、開発者がカスタム AI エージェントにデータベース機能への直接かつ安全なアクセスを許可するために使用するモジュール式のビルディングブロックです。AlloyDB、Cloud SQL、Spanner で利用が可能で、高精度のテキストから SQL への変換を行う QueryData ツールなどの機能がすぐに使用できます。これにより、あらゆるエージェントがデータを確実にクエリ、理解、操作できるようにします。AlloyDB、Spanner、Cloud SQL のデータエージェント向けのツールでは、Text-to-SQL で 100% に近い変換精度を実現しました。
データベースオンボーディングおよびオブザーバビリティエージェント（プレビュー版）: 新しいデータベースオンボーディングエージェントは、データベースの選択とデプロイにおける推測を不要とします。単純なユースケースの説明から複雑な企業ニーズといった要件の評価をもとに、理想的な Google Cloud データベースを推奨し、プロビジョニングのプロセスを支援します。さらに、AI を活用した新しい Database Observability Agent が、AlloyDB、Bigtable、Cloud SQL、Spanner のパフォーマンスと健全性をプロアクティブにモニタリングします。これにより、潜在的な問題の根本原因を特定し、トラブルシューティングのための正確な修復を実現できます。
AlloyDB AI を活用した大規模検索 （プレビュー版）: エンタープライズ検索で、かつてないスケールとパフォーマンスを実現します。AlloyDB は、Google の ScaNN インデックスを使用することで 100 億のベクトルにスケーリングできるようになり、標準の PostgreSQL の HNSW インデックスと比較して最大 6 倍高速なベクトルクエリを提供します。さらに、Google の HNSW インデックスは、カラム型エンジンによって高速化されているため、標準の PostgreSQL の 4 倍の性能となっています。Google は、高速なベクトル取得と業界標準の全文検索を組み合わせることで、デベロッパーが究極のハイブリッド検索エンジンを構築できるよう支援しています。この検索エンジンは、近日中に提供されるネイティブの BM25 サポートによって最適化されます。

AlloyDB のベクトル検索のイノベーション

AlloyDB の最適化された新しい AI 関数 （プレビュー版）: AlloyDB AI 関数は、Gemini などの LLM を活用した企業データの統合を支援します。たとえば、AI.IF 関数は、カスタムロジックの代わりに、ユーザーのトランザクションが不正かどうかを判断するために使用できます。既存のスイートである AI.IF、AI.RANK、AI.GENERATE、AI.FORECAST に加え、新たに AI.ANALYZE_SENTIMENT と AI.SUMMARIZE の 2 つが追加されました。また、AI.IF の最適化モードも利用できるようになり、コストとパフォーマンスが大幅に向上します。
データベース向けマネージドリモート MCP サーバー （一般提供）: AlloyDB、Bigtable、Cloud SQL、Firestore、Spanner 向けのマネージドリモート Model Context Protocol（MCP）サーバーの提供を開始しました。また、Google のポートフォリオ全体で MCP を利用できるように、Memorystore、Database Migration Service、Datastream、データベースセンター、Oracle Database@Google Cloud のプレビュー版も提供しています。AI モデルをデータに安全に接続するために必要なインフラストラクチャを完全に管理することで、自社で MCP サーバーのホスティング、保護、スケーリングを行う運用上の負担がなくなります。これにより、AI モデルは本番環境グレードの信頼性で、最新の企業データに基づいて推論し、行動できるようになります。
オープンソースのデータベース向け MCP ツールボックス（1.0）: 10 社のベンダーの協力を得ることで 40 以上のデータベースをサポートする、オープンソースかつ業界標準のデータベース向け MCP ツールボックスが、今回のリリースで安定性における大きなマイルストーンを達成しました。メジャーバージョンアップがない限り API が機能することを保証することで、本番環境向けのアプリケーションを安心して構築できるようになり、デベロッパーと自律型 AI エージェントの両方にとって信頼性の高い基盤が提供されます。

レイクハウスのインテグレーションで閉ざされた環境を解消

デベロッパーがリアルタイム AI アプリケーションを構築するには、ライブのトランザクションコンテキストと膨大な過去の分析情報をミリ秒未満のレイテンシで組み合わせる必要があります。現在、データクラウドをご利用の最大規模のお客様の 98% が、Google の Agentic Data Cloud で運用ワークロードと分析ワークロードを実行しています。

発表内容:

AlloyDB 向けレイクハウスフェデレーション （プレビュー版）: AlloyDB のお客様は、PostgreSQL データプレーンから Iceberg と BigQuery のライブデータにアクセスできるようになりました。ユーザーは、AlloyDB Studio UI から直接、BigQuery または Lakehouse for Apache Iceberg テーブルを検出して検索し、すぐにクエリを開始できます。フィルタと集計は BigQuery にプッシュダウンされます。これにより、データの移動を必要とせずに、AlloyDB のトランザクションデータと BigQuery または Iceberg の過去の分析情報をライブで結合できます。
BigQuery 向けリバース ETL（プレビュー版）: 多くのお客様が BigQuery とレイクハウスを使用して、Apache Spark や BigQuery ML などのツールでウェアハウスの構造化データとデータレイクの豊富なコンテキストを組み合わせています。このたび、Google の新しいワンクリックリバース ETL により、お客様はこれらの分析情報を活用し、レイクハウスから AlloyDB にワンクリックでデータを同期できるようになりました。AlloyDB は、リアルタイムアプリケーションやエージェントアプリケーションのニーズを満たすように最適化された、同時実行性が高く低レイテンシのサービングレイヤとして機能します。AlloyDB 独自のカラム型エンジンと超高速キャッシュによって、優れたサービングパフォーマンスを実現します。利用に追加料金は発生しません。
Datastream によるシームレスな継続的レプリケーション （一般提供）: Datastream では、データループを完結させるために、AlloyDB から BigQuery および Iceberg テーブルにデータを継続的に複製できるようになりました。これにより、運用面の変更が分析環境に迅速に反映されるため、リアルタイムの ML 特徴量エンジニアリングに不可欠な環境を実現できます。Datastream は、セットアップが簡単で、完全にサーバーレスです。AlloyDB から BigQuery へのストリームには無料枠が用意されています。
Knowledge Catalog（旧称 Dataplex） （プレビュー版）: Knowledge Catalog は、集約、継続的な拡充、検索の厳格なフレームワークを使用して、データ資産全体でビジネス上の意味をマッピングおよび推論するユニバーサルコンテキストエンジンです。Google とパートナーのデータプラットフォーム、セマンティックモデル、サードパーティカタログのネイティブコンテキストを集約し、単一の管理された信頼できる情報源として統合します。一貫してガバナンスが適用され、アクセス制御は一元的に管理されるため、データライフサイクル全体で完全な可視性とセキュリティが維持されます。
Spanner カラム型エンジン（一般提供）: この機能により、ライブ運用データでスキャンが最大 200 倍高速化されるため、分析クエリが加速されます。Spanner は、従来の行ベースのストレージと並行してカラム形式でデータを保存することにより、複雑なクエリを自動的に実行できます。その際は、データを行単位ではなく一度にバッチ処理するベクトル化された実行を使用します。Spanner では、Iceberg テーブル、BigQuery からの継続的なリバース ETL、高速化された連携クエリもサポートされるようになりました。これらすべてで Spanner のカラム型エンジンが使用されています。
BigQuery を使用したデータベースセンター（プレビュー版）: データベースセンターで、Google Compute Engine 上の運用データベースとセルフマネージドデータベースに加えて、BigQuery がサポートされるようになりました。クリティカルなアプリケーションを実行するデータベースからビジネスに関して分析するウェアハウスまで、データ資産全体を単一のインテリジェントな管理プレーンからモニタリングできるようになりました。さらに、Gemini を活用したフリート分析により、環境全体でパフォーマンス最適化の機会がプロアクティブに提示されます。また、新しい API とマネージド MCP サポートにより、これらの豊富なフリート指標を任意のサードパーティツールやカスタムダッシュボードに直接ストリーミングできるようになります。

「Google Cloud とのパートナーシップでは、よりスマートで高速な取引所の構築に重点を置いています。かつては、古いシステムによりサイロ化されていた状況と技術的負担によって業務が滞ることもありましたが、Google の Agentic Data Cloud を利用することで、そうした課題が解消されました。Cloud SQL が持つ運用信頼性と BigQuery の高度な推論を統合することで、デベロッパーと AI エージェントが検証、最適化、革新をリアルタイムで進められるデータエコシステムを構築しました」—CME Group、クラウドデータエンジニアリング担当エグゼクティブディレクター、Kristofer Shane Sikora

オープンデータとマルチクラウドの柔軟性への取り組み

データベースがすべてのアプリケーションの日々の運用にどれほど重要であるかは、Google も認識しています。Google では、Iceberg、MySQL、PostgreSQL、Valkey などのオープンソースとオープンデータ形式に重点を置きながら、業界をリードする信頼性、コストパフォーマンス、スケールを実現するためのイノベーションを継続しています。

エンタープライズグレードのデプロイを簡素化するために、Google は以下を発表します。

Spanner Omni（プレビュー版）: 業界をリードする分散データベースを Google Cloud の外でも利用できるようにする、Spanner の新しいダウンロード可能なエディションです。Spanner Omni を使用すると、組織は Spanner の比類のないスケーラビリティ、高可用性、強整合性、エンタープライズグレードのセキュリティ、完全に相互運用可能なマルチモデル機能を、独自のデータセンター、クラウド全体、さらにはエッジでも AI 対応アプリケーションで使用できます。

Spanner Omni の特長

Bigtable インメモリ （プレビュー版）: Bigtable はアーキテクチャを進化させ、新しいメモリ階層でミリ秒未満の読み取りレイテンシを実現します。Bigtable の新しい Enterprise Plus エディションの機能として利用できる、RAM、SSD、HDD にまたがるハイブリッドストレージアーキテクチャを備えた新しいノードは、頻繁にアクセスされるデータをインメモリデータベースを長期アーカイブストレージと統合します。これらすべてを、単一のフルマネージドサービス内で行えます。ご興味がある場合は、こちらのフォームにご記入ください。
Memorystore for Valkey 9.0（一般提供）: Memorystore for Valkey 9.0 は、Google のオープンソースへの強いコミットメントを示すマイルストーンとなっています。導入の簡素化とエンタープライズグレードのパフォーマンスの提供に重点が置かれています。セルフマネージドの Redis と Valkey から Memorystore へのマネージド移行パスを導入し、これまで以上に簡単にモダナイズできるようにしました。また、コストパフォーマンスを向上させるために、小規模ノードと大規模ノードの新たなサイズを追加し、Valkey-bloom モジュールと Valkey-json モジュールをサポートします。さらに、アクセス制御リスト（ACL）、トークンベースの認証、柔軟な認証局に対応したエンタープライズグレードのセキュリティも追加します。
Oracle Database@Google Cloud: 対象リージョンを 20 に拡大し、Oracle GoldenGate Service のサポート、BigQuery への準リアルタイムのデータレプリケーション、Knowledge Catalog（旧称 Dataplex）とデータベースセンターの統合を追加します。
Compute Engine からマネージドサービスへの移行（プレビュー版）: これは、データベース移行の複雑さを解消するために設計された新しいエクスペリエンスです。Cloud SQL、AlloyDB、データベースセンターにネイティブに統合されており、PostgreSQL の自動ネットワーキングとレプリケーションを提供します。これにより、Compute Engine ワークロードを最小限の労力とダウンタイムで Google の強力なマネージドサービスに移行できます。
Firestore の全文検索と地理空間検索（プレビュー版）: Google の業界をリードする検索テクノロジーを Firestore とネイティブに統合することで、差別化された統合サーバーレスデータベースと検索サービスが実現しました。このサービスは、検索結果が基盤となるデータベースのデータと一貫性を保つようにして、運用上のオーバーヘッドを大幅に削減しつつ、関連性の高いキーワードクエリ、フレーズクエリ、地理空間クエリを実行できるようにします。

Mercado Libre: 「Mercado Libre では、社内開発者ゲートウェイとして Fury を構築しました。Fury を通じて、比類のないスケーラビリティ、レジリエンス、整合性を備えた Spanner を活用した NewSQL サービスを提供しています。当社はクラウドネイティブ企業ですが、インサイダー脅威、ランサムウェア、クラウドの停止などのリスクについて、長年にわたって警戒を続けてきました。Spanner Omni は真のクロスクラウドレジリエンスを実現し、他のクラウドプロバイダでは実装がはるかに複雑化するであろう差別化された堅牢な戦略を提供します」– Mercado Libre、シニアテクニカルマネージャー、Diego Oscar Narducci

今すぐ使ってみる

Google のポートフォリオの詳細については、https://cloud.google.com/products/databases をご覧ください。移行とモダナイゼーションの取り組みを開始するにあたっては、ぜひ RAMP サービスをご利用ください。

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

- プロダクト管理、データベース担当バイスプレジデント Raj Pai

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データベース

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

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

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

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

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

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

AlloyDB AI で PostgreSQL の多言語全文検索における制限を解消する方法

連続したテキストと表語文字言語

Gemini を使用したデータベース内での前処理

セマンティック単語分割の実装

ハイブリッド検索への拡張

検索に AlloyDB AI が最適な理由

次のステップ

pgvector の強化: AlloyDB で HNSW ベクトル検索が 4 倍高速化

まず、AlloyDB カラム型エンジンとは？

パフォーマンスの可視化

仕組み: カラム型エンジンで高速化された HNSW

これが重要である理由

クイック スタートガイド

AI エージェントの準備は完了。では、データは？

不要な手作業を回避する

データに信頼と知識をもたらす

将来を見据える

レポート: 83%の組織がエージェント型 AI に対応するためにインフラストラクチャのアップグレードを必要としている

Android、Google Cloud、Nexus SDV が実現する AI 定義車両

車両側: AAOS SDV

Google Cloud 側: AI ネイティブなモビリティ

Bigtable: 自動車テレメトリーのデータ バックボーン

すべてを統合した Nexus-SDV プラットフォーム

予測メンテナンス

ご利用にあたって

詳細

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

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

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

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

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

AlloyDB AI 関数 - 革命的なパフォーマンス向上と費用削減を実現

LLM の力をデータに: 大幅な高速化とコスト削減を実現

デモのご紹介

始め方は簡単

Atlas が Cloud SQL Enterprise Plus エディションにより数百の加盟店のデータベースをどうスケールしたか

課題: 標準エディションの枠を超えたスケール

Enterprise Plus エディションへの移行

効果: インフラストラクチャ管理ではなくイノベーションに注力

今後の展望: AI ファーストの未来

データベース アーキテクチャをスケールする準備はできていますか

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

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

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

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

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

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

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

使ってみる

データエージェントの新機能: AI ワークフローの強化

1. 会話型分析

2. 新たなデータ エージェント

3. データ エージェント向けのツール

BigQuery Graph で食品サプライ チェーンのデジタルツインをモデリング

成長中のレストランの例

成長に伴う摩擦

デジタルツイン

BigQuery Graph でのモデリング

実務で活きる精度

将来を見据えて

まとめ

使ってみる

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

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

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

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

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

使ってみる

AlloyDB ホットスタンバイ: 高速なフェイルオーバー、安定したパフォーマンス

AlloyDB の HA アーキテクチャ

新しいアーキテクチャ: AlloyDB ホットスタンバイ

ホットスタンバイの仕組み

強化された HA を使ってみる

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

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

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

クイックスタートガイド

Bigtable: 自動車テレメトリーのデータバックボーン

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

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

データベースアーキテクチャをスケールする準備はできていますか

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

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

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

2. 新たなデータエージェント

3. データエージェント向けのツール

BigQuery Graph で食品サプライチェーンのデジタルツインをモデリング

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

Cloud Run、Firebase、Cloud SQL を使用したフルスタックのバイブコーディングが AI Studio で可能に（クレジットカードは不要）

手軽に導入: Google Cloud スターターティア

Cloud SQL でフルスタックのバイブコーディングを強化

Firestore と Firebase Auth を使用したフルスタックのバイブコーディング