データベース

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

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

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

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

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

関係が重要な理由

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

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

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

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

仕組み

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oracle PL/SQL から PostgreSQL への変換

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

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

ソース: Oracle PL/SQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Database Migration Service を使ってみる

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

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

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

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

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

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

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

DMS の中核的な変換戦略

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

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

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

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

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

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

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

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

SQL

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

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

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

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

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

SQL

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

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

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

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

SQL

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

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

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

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

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

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

SQL

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ビジネスへの影響

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

早速始めましょう

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AlloyDB 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 0x7f5ad9d3a250>)])]>

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

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

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

このストアドプロシージャを使用するアプローチには、本番環境での課題を直接解決する次の 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 0x7f5ad9d3ac40>)])]>

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

ステップ 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 0x7f5ad9d3a7f0>)])]>

検索を実行するには、前処理されたクエリ文字列（「研究所图书馆」）を 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 0x7f5ad9d3ae20>)])]>

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

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

ベクトル検索の結果とテキスト検索の結果を組み合わせるには、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 0x7f5ad9d3ab50>)])]>

クエリの説明:

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 0x7f5ad89e8460>), ('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 0x7f5ad89e8910>)])]>

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

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

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

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

架空のガジェットサイトでの検索結果の例を以下に示します。商品の詳しい説明が、水深 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 0x7f5ad928f9a0>)])]>

上のスクリーンショットのように、水深 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 0x7f5ad8f76430>)])]>

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

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

将来を見据えて

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

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

まとめ

レストラン業界は、ビジネスデータを単なるリストとして扱うリレーショナルな方法だけでは対応しきれない段階に来ています。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 0x7f5ad93971f0>)])]>

ステップ 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 0x7f5ad9397e80>)])]>

ステップ 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 0x7f5ad9397880>)])]>

ステップ 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 0x7f5ad9397400>)])]>

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

データベース

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

仕組み

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

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

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

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

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

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

Oracle PL/SQL から PostgreSQL への変換

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

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

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

Database Migration Service を使ってみる

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

DMS の中核的な変換戦略

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

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

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

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

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

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

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

まとめ

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

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

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

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

ビジネスへの影響

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

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

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

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

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

使ってみる

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

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

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

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

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

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

早速始めましょう

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 関数 - 革命的なパフォーマンス向上と費用削減を実現

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クイックスタートガイド

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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