データベース

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

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

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

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

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

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

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

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

重要である理由

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

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

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

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

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

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

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

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

提供状況

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原則に基づく評価

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pg_textsearch を使用する理由

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

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

全文検索の例

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

インデックスの作成

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

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

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

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

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

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

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

AlloyDB ハイブリッド検索の例

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

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

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

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

ハイブリッド検索

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

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

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

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

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

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

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

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

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

ハイブリッド検索

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

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

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

実際の操作を見る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ML レイヤ: Distributed Graph Flow（DGF）

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

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

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

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

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

ユースケース

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

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

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お客様の声

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

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

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

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

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

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

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

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

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

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

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

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

M4N のマシンタイプと仕様

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データベース運用

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

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

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

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

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

早速始めましょう

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

Spanner: DML トランザクションの累積ミューテーション上限を撤廃

Thu, 17 Sep 2026 02:00:00 +0000

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

Spanner は、Google Cloud の妥協のない業務データベースです。水平スケーリングや常時稼働の可用性といった最新の分散型システムの利点に加え、豊富な機能セットや使い慣れたエコシステムといったリレーショナルデータベースの利点を兼ね備えています。現在、銀行、小売、メディア、エンターテイメント、AI インフラストラクチャなどの業界のイノベーターが、最も重要なワークロードに Spanner を利用しています。この Spanner において、このたび、より大規模かつ複雑なトランザクションを柔軟に処理する新しい方法が導入されたことをお知らせします。これにより、最高レベルのデータ整合性を必要とするアプリケーションを簡素化できるようになります。

一般に、業務のワークロードは、リアルタイムの意思決定ときめ細かい更新の組み合わせです。たとえば、e コマースアプリで複数ステップの購入手続き中に不正行為を特定する場合を考えてみましょう。このような変更はトランザクション単位、つまり、すべてが成功するか、すべてが失敗するかのどちらかである必要があります。また、後続のリクエストが正しいデータを参照できる必要があります。Spanner の ACID トランザクションに対する今回のアップデートにより、アプリケーションは使い慣れた DML を使用して、整合性、スケーラビリティ、可用性を損なうことなく、更新時により多くのデータを処理できるようになります。

高い上限で柔軟性が向上

これまで Spanner では、クエリが 1 回のトランザクションで実行できる変更（DML を使用する場合など）の上限が 80,000 件でした。これは、更新する行数と列数の積に、依存するインデックスを加えたものとして大まかに計算されていました。アプリケーションは、時間の経過とともに、より多くのデータを処理し、新しい機能を提供できるように進化します。こうした進化に伴い、トランザクションのサイズが拡大すると、以前は小さかったトランザクションがこの上限に達する可能性が生じます。

今回のアップデートでは、80,000 件というミューテーション数の上限がトランザクションから個々の DML ステートメントに移行されます。DML ステートメントは、トランザクションレベルの全体的なミューテーション数の上限に影響しなくなります。INSERT、UPDATE、DELETE など、個々の DML ステートメントが生成するミューテーション数が 80,000 件未満である限り、1 つのトランザクションにいくつでも DML ステートメントを含められるようになりました。

主なメリット

大規模なトランザクション: 累積ミューテーション数の上限に準拠するために、DML ステートメントを人為的に分割するのではなく、ビジネス要件に基づいて論理的にグループ化できます。
シームレスな移行: 今回の変更は、既存のすべての Spanner クライアントライブラリと互換性があるため、アプリケーションコードの更新は不要です。

技術的な考慮事項

ロックと中止

1 つのトランザクションに含めることができる DML ステートメントの数が増えた一方で、トランザクションの規模が拡大して実行時間が長くなると、ロックが保持される時間も長くなることに注意が必要です。これにより、ロックの競合やトランザクションの中止が発生する可能性が高まります。トランザクションを簡潔に保つことで、高いパフォーマンスを維持し、リソースの競合を最小限に抑えることができます。

DML と Mutation API

上限の適用は、データを変更する方法によって異なります。

DML ステートメント: 各ステートメント（executeUpdate など）がミューテーション数の上限 80,000 件に対して個別に評価されます。
Mutation API: insert() や update() など、クライアントライブラリのメソッドを使用する場合、ミューテーションは Commit 呼び出し中に提供されます。80,000 件の上限は引き続き、その 1 回の呼び出しに含まれるミューテーションのセット全体に適用されます。

ミューテーション数について

Spanner では、変更されたセル、主キー、セカンダリインデックスの更新を含め、変更の複雑さに基づいてミューテーション数が数えられます。ミューテーションの数え方について詳しくは、こちらのブログをご覧ください。commit されたトランザクションの合計ミューテーション数は、CommitStats の mutation_count を使用して確認できます。mutation_count には、すべての DML ステートメントと commit 呼び出しにわたって、トランザクションの一部であるすべてのミューテーションが含まれます。

Java の実装例

次の例は、新しい上限のロジックで、1 つのトランザクション内で複数の DML ステートメントを実行する方法を示しています。

code_block: <ListValue: [StructValue([('code', 'import com.google.cloud.spanner.DatabaseClient;\r\nimport com.google.cloud.spanner.Statement;\r\nimport com.google.cloud.spanner.TransactionContext;\r\nimport com.google.cloud.spanner.TransactionRunner.Work;\r\n\r\n// Assuming dbClient is your initialized DatabaseClient\r\ndbClient\r\n .readWriteTransaction()\r\n .run(\r\n new Work<Void>() {\r\n @Override\r\n public Void doWork(TransactionContext transaction) throws Exception {\r\n // Each executeUpdate call is evaluated separately against the 80k mod limit.\r\n\r\n // Example 1: Updating specific products\r\n Statement stmt1 = Statement.newBuilder(\r\n "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")\r\n .bind("productId").to(1L)\r\n .build();\r\n transaction.executeUpdate(stmt1); // Verified against 80k limit\r\n\r\n Statement stmt2 = Statement.newBuilder(\r\n "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")\r\n .bind("productId").to(2L)\r\n .build();\r\n transaction.executeUpdate(stmt2); // Verified against 80k limit separately\r\n\r\n // Example 2: Inserting related order data\r\n Statement stmt3 = Statement.newBuilder(\r\n "INSERT INTO OrderItems (OrderId, ItemId, Quantity) VALUES (@orderId, @itemId, @qty)")\r\n .bind("orderId").to(100L)\r\n .bind("itemId").to(1L)\r\n .bind("qty").to(2)\r\n .build();\r\n transaction.executeUpdate(stmt3); \r\n\r\n Statement stmt4 = Statement.newBuilder(\r\n "UPDATE Orders SET LastUpdated = PENDING_COMMIT_TIMESTAMP() WHERE OrderId = @orderId")\r\n .bind("orderId").to(100L)\r\n .build();\r\n transaction.executeUpdate(stmt4); \r\n\r\n return null;\r\n }\r\n });'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fca41c2a950>)])]>

変更がない点

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

ベストプラクティス

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

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

外部の関連資料

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

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

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

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

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

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

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

関係が重要な理由

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

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

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

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

仕組み

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

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

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

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

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

ターゲット: 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 0x7fca41cd1790>)])]>

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

ターゲット: 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 0x7fca42b93ed0>)])]>

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

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

移行したルーティンを再びアプリケーションのデータアクセスレイヤに統合する際、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 0x7fca42b93b90>)])]>

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

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

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

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

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

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

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

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

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

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

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

クエリの説明:

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 0x7fca42c38e50>), ('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 0x7fca42c93310>)])]>

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

データベース

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

重要である理由

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

提供状況

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pg_textsearch を使用する理由

全文検索の例

AlloyDB ハイブリッド検索の例

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

実際の操作を見る

関連リソース

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

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

ML レイヤ: Distributed Graph Flow（DGF）

ユースケース

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

使ってみる

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

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

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

お客様の声

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

M4N のマシンタイプと仕様

使ってみる

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

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

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

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

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

データベース運用

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

早速始めましょう

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

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

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

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

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

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

まとめ

Spanner: DML トランザクションの累積ミューテーション上限を撤廃

高い上限で柔軟性が向上

技術的な考慮事項

ロックと中止

DML と Mutation API

ミューテーション数について

Java の実装例

変更がない点

ベスト プラクティス

メジャーがサポートされるようになった 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 内部の動作

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

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

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

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

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

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

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

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

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

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

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

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

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

ベストプラクティス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クイックスタートガイド

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