データ分析

Data Agent Kit でエージェントを駆使した問題分析

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

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

想像してみてください。月曜の朝、出社早々、上司からチャットメッセージが入ります。曰く、「1 月の平均注文額は 7% 減だけど、総収益は横ばいだね。なんでかな？」

データ実務者であれば、このような質問が一筋縄ではいかないことは、よくご存じなのではないでしょうか。しかも、答えは単純明快ではありません。根本原因を示す単一のダッシュボードがあるわけでもありません。ウェブのログにエラーが記録されているのか。プロモーションコードの設定に誤りがあったのか。深掘りするまで皆目見当がつかないし、1 か所や 2 か所、調べただけでは答えはまず見つからないでしょう。

答えにつながる鍵は、環境内のさまざまな領域に散在しています。

販売履歴（注文と明細項目）はデータウェアハウスに保存されています。
有効な顧客レコードは本番環境の PostgreSQL インスタンスに保存されています。
マーケティングキャンペーンルールは、オブジェクトストア内の未加工 JSON ファイルに保存されています。

これらの情報を引き出すクエリを 1 つだけ作成するなら簡単です。実際には、同じクエリを何度も記述し、WHERE 句を調整したり、サブクエリを追加したりして、答えを見つけ出す必要があります。1 つのシステムが終わったら次のシステムに移動し、別の方法で再びクエリを行います。気づけばブラウザのタブが 10 個も開いていて、1 つの質問に答えるだけで丸一日がつぶれてしまいます。

Data Agent Kit

まさにこのような問題を解決するために構築されたのが、Data Agent Kit です。MCP サーバーとエージェントスキルを組み合わせた Data Agent Kit を使用することで、データデベロッパーは IDE からデータワークフローを実行できるようになります。VS Code フォーク（Antigravity IDE、Cursor）の拡張機能としても、他のツール（Antigravity 2.0、Antigravity CLI、Claude Code、Codex）のプラグインとしても利用できるため、IDE を離れることなく、答えを見つけ出せます。

Data Agent Kit は、次の 2 つのコアメカニズムを基盤としています。

Model Context Protocol（MCP）: エージェントをツール、データベース、リモートクラウドインフラストラクチャに接続するオープンスタンダード。
エージェントスキル: AI エージェントに特定スタックとのやり取りの方法を教え、エージェントの知識を補強する Markdown ファイル。

Data Agent Kit を使用すると、SQL スニペットを生成してコンソールにコピーして貼り付ける代わりに、エージェントがクエリを実行して結果を読み取ることができます。

これを平均注文額（AOV）のシナリオに適用したら、どのようになるのか見てみましょう。この場合、データウェアハウスには BigQuery が、Postgres インスタンスには Cloud SQL が相当し、キャンペーンルールは Cloud Storage に保存されています。

Data Agent Kit のサンプルアーキテクチャ

事象を把握する

調査は、まず IDE のチャットペインで、次の自然言語プロンプトを使用して、基本的な数値の確認から始めます。

code_block: <ListValue: [StructValue([('code', 'BigQuery の orders テーブルと order items テーブルを使用して、2025 年 8 月から 2026 年 1 月までの月間平均注文額を計算してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b197eed50>)])]>

結果を確認する

エージェントがプロンプトを処理し、関連スキルを呼び出して、データのクエリを開始する準備をします。しかし、まだ実行はせず、IDEを一時停止して必要な MCP ツール（execute_sql_readonly など）の使用許可を求めます。ユーザーは、監査のために 1 回だけ許可することも、[常に許可] を選択してワークフローを継続することもできます。許可すると、エージェントはクエリを送信します。

チャットでエージェントスキルと BigQuery MCP を呼び出す

エージェント IDE では、実行トレイルを検査して、各 MCP ツール呼び出しの記録や BigQuery に送信された未加工 SQL などを確認できます。エージェントが生成したコードは人間の目で再確認する必要がありますが、不慣れなスキーマに対して一からクエリを記述するの比べれば、大幅な時間の節約になるはずです。

数値を深掘りする

数値を見ると、平均注文額（AOV）は 8 月から 12 月まで 110 ドル前後を維持していましたが、1 月には 103 ドルに減少しています。この理由を調べるために、エージェントにドリルダウンを依頼します。

code_block: <ListValue: [StructValue([('code', '1 月の AOV を注文タイプ別に分類して、詳細を確認してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19ced150>)])]>

結果は、ビジネスの衰退ではなく、平均値の偏りを示しています。オンライン注文とオフライン注文は約 110 ドルで堅調に推移していますが、1 月に B2B-Wholesale という新しいチャネルが登場し、その AOV はわずか 75 ドルほどでした。注文が減少したのではなく、プロダクト構成の変化が AOV の見た目を押し下げました。

Cloud SQL に調査を広げる

AOV の低下につながった要因がわかりました。次に、卸売業者のバイヤーの実体を把握する必要があります。顧客レコードは Cloud SQL Postgres の運用データベースに保存されています。同じチャットスレッドで、次のように続けましょう。

code_block: <ListValue: [StructValue([('code', 'B2B のお客様はどのような事業者ですか。Cloud SQL データベースで、アカウントの詳細と作成日を確認してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19cec4d0>)])]>

エージェントは MCP を Cloud SQL MCP に切り替え、customers テーブルを調査します。100 件の卸売アカウントはすべて、過去 30 日以内に作成された新しい事業体です。12 月には、これらの事業体はいずれも存在していませんでした。

Cloud SQL で運用顧客レコードをクエリする

コードを探求する

BigQuery で B2B 注文を簡単に確認すると、92% が promo_code = BIGORDER25 を適用していることがわかります。次に、エージェントにそのコードを追跡してキャンペーンファイルを確認するよう依頼すると、エージェントは Google Cloud Storage MCP サーバーを使用してファイルにアクセスします。

マーケティングキャンペーンでは、25% 割引コードにより低価格の卸売注文が大量に発生し、総収益は横ばいだったものの、総合的な AOV は減少しました。

このように、エージェントは、1 回のチャットセッションで、分析データ（BigQuery）、運用記録（Cloud SQL）、非構造化メタデータ（Cloud Storage）をクエリして、根本原因を特定しました。

調査結果を報告する

調査が終わったので、上司に短いエグゼクティブサマリーを提出するようエージェントに指示します。

エージェントが生成したエグゼクティブサマリー

これで完了です。IDE から直接、自然言語のプロンプトをいくつか入力するだけで、上司からの一筋縄ではいかない質問に答えることができました。

しかし、このような根本原因の分析作業は、日常業務のごく一部であり、その都度、時間を費やすわけにはいきません。次にまた作業が必要になったときに、同じプロセスを繰り返すのは非効率です。代わりに、この調査を再現可能なデータモデルに変換すると便利です。

再現可能なパイプラインを構築する

エージェントに、アドホック分析を永続的な dbt プロジェクトに変換するよう依頼することができます。AOV はペット関連商品の平均注文額なので、ここでは顧客のペットプロファイルを分析に組み込みます。

code_block: <ListValue: [StructValue([('code', 'BigQuery ステージングモデルを Cloud SQL の顧客レコードおよびペットのプロファイル属性と結合する dbt プロジェクトを構築してください。さらに、order_id に一意性テストを追加し、dbt build を実行してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19cec6d0>)])]>

エージェントは、1 つのプロンプトから dbt-bigquery を使用して仮想 Python 環境を作成し、プロジェクトモデルとテストを記述します。しかし、dbt build は、一意性テストで order_id の重複が検出され、失敗に終わります。

これは、顧客によっては複数のペットを飼っている場合があるためです。モデルの最初のバージョンでは、これらのプロファイルを各注文に直接関連付けたため、3 匹のペットを飼っている世帯からの注文は 3 行になりました（一意ではありませんでした）。

エージェントは自身のターミナル出力を読み取り、失敗を検出します。その後、dbt ロジックを書き換え、ビルドが成功するまで再実行を繰り返します。

これは、エージェントワークフローに関して特記すべき点です。エージェントは大量のコードを記述できますが、パイプラインへのデータ品質チェックの適用は不可欠です（幸い、エージェントはそれも記述できます）。

次に上層部から平均注文額の変動理由を尋ねられたときには、dbt モデルが回答を準備してくれます。

まとめ

エージェント IDE を使用すると、ウェアハウス、データベース、オブジェクトストア、ターミナルを行き来する必要がなくなります。

MCP などのオープンスタンダードと、柔軟な構成と編集が可能なエージェントスキルを組み合わせることで、Data Agent Kit は質問と回答をスムーズに連動させて問題解決へと導きます。不慣れなスキーマを調べたり、多様なコードを使い分けたりすることはもちろん、これまで何度も記述してきた結合の生成も、これからはすべてエージェントに任せられます。エージェントが行う調査の指揮をするのが、あなたの役目です。

実際に試す

Data Agent Kit は現在プレビュー版で提供され、Antigravity（2.0、CLI、IDE）、Claude Code、Codex、Cursor、その他の一般的なツールでネイティブに動作します。

シナリオを試す: Data Agent Kit と Antigravity IDE を使用した分析の Codelab で、詳しい設定手順を確認する。
ドキュメントを読む: Google Cloud Data Agent 拡張機能のドキュメントで詳細を確認する。
プラグインを試す: GitHub のオープンソースリポジトリでスキルとツールを確認する。

- Google、デベロッパーアドボケイト、Jeff Nelson

Yahoo が Managed Service for Apache Spark のフレキシブル VM でリソースを最適化している方法

Tue, 15 Sep 2026 03:00:00 +0000

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

Yahoo は、数億人のユーザーを金融、スポーツ、エンターテイメントのプラットフォームに接続するグローバルなメディアおよびテクノロジー企業として、分析ワークロードを高速で継続的に実行する必要がある大規模なデータインフラストラクチャを運用しています。期限が重視されるデータ環境では、固定の仮想マシン（VM）構成に依存すると、システムが脆弱になります。特定のマシンシェイプがリージョンの容量制限に直面すると、Managed Service for Apache Spark（旧称 Dataproc）でのクラスタプロビジョニングが遅延し、重要なデータパイプラインが停止する可能性があります。

Yahoo は、Managed Service for Apache Spark クラスタでフレキシブル VM を利用し、許容可能な VM シェイプのランク付けされたリストを定義することで、これらのリソースの変動に自動的に対応しています。これにより、システムはリージョンゾーンを動的に検索し、手動による介入なしでパイプラインの実行を維持できます。リージョン全体で容量を検索するには、自動ゾーンプレースメントも有効にする必要があります。

この最適化は、オンプレミスの Hadoop とビッグデータ資産を Google Cloud に直接移行する、Yahoo のより広範なデータモダナイゼーションの取り組みを基盤としています。これらのレガシーワークロードを移行することで、チームは動的なリソースの柔軟性を備えた、大規模なバッチ分析とストリーミング分析を実行できるクラウド基盤を確立しました。

この投稿では、Managed Service for Apache Spark でフレキシブル VM インスタンスのランキングを構成し、容量の制約を自動的に管理してパイプラインの実行を維持するための技術的なブループリントをご紹介します。

静的構成の運用上のトレードオフ

特定のゾーンで固定された単一のマシンタイプを使用してクラスタを構成すると、リージョンゾーンの容量が変動した場合に制約が生じ、クラスタのプロビジョニングに影響する可能性があります。カスタムの再試行ロジックや手動による介入によってこれらの容量の変動を管理するのではなく、柔軟な構成を使用することで、インフラストラクチャを自動的に適応させることができます。柔軟な構成により、複数の VM シェイプを受け入れ、選択したリージョン内のゾーン全体で検索を行うことで、プロビジョニングを合理化し、大規模な分析ワークロードをより適切にサポートできます。

柔軟なクラスタを構成するためのルール

柔軟な構成をデプロイするには、一連の設計上の選択を調整する必要があります。

自動ゾーンプレースメントを有効にする: Managed Spark がリージョン全体で利用可能な容量を検索できるように、リージョン（--region=${REGION}）または空のゾーン文字列（--zone=""）を渡す必要があります。
コアとメモリの均一性を維持する: Managed Spark クラスタで自動スケーリングを使用する場合、フレキシブルリスト内のすべてのマシンタイプは、異なる VM ファミリーのものであっても、同様のコア数とメモリサイズを共有する必要があります。プライマリワーカーとセカンダリワーカーで CPU とメモリの比率を統一すると、最小の比率によって有効なコンテナのサイズが決まるため、パフォーマンスの低下を防ぐことができます。
コンポーネントプロパティを調整する: Managed Spark は、VM のコアとメモリに基づいてシステムプロパティを計算します。マシンシェイプを混在させる場合、YARN と Spark のリソース割り当てをワーカーの想定される動作に合わせるために、プロパティの明示的なオーバーライドが必要になることがあります。

フレキシブル VM が大規模なワークロードをサポートする 2 つの方法

大規模なデータ環境の場合、柔軟な構成は次の 2 つの方法で運用をサポートします。

クラスタ作成の成功率の向上: 優先 VM タイプが利用不可の場合に失敗せず、Managed Spark がランク付けされたリストから代替の VM タイプを選択してプロビジョニングを継続します。
リージョンリソースの使用効率の向上: 自動ゾーンプレースメントでは、リージョン全体が検索され、容量が検出されるため、需要が高い期間のプロビジョニングの摩擦が軽減されます。

gcloud の例

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters create analytics-cluster \\\r\n --region=us-central1 \\\r\n --zone="" \\\r\n --num-workers=10 \\\r\n --master-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --master-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b1998ce10>)])]>

API の例

この容量ポリシーは、Dataproc API の instanceFlexibilityPolicy フィールドを使用して、自動化されたパイプラインまたは Managed Service for Apache Airflow DAG に組み込むこともできます。

code_block: <ListValue: [StructValue([('code', '{\r\n "projectId": "PROJECT_ID",\r\n "clusterName": "analytics-cluster",\r\n "config": {\r\n "gceClusterConfig": {\r\n "zoneUri": ""\r\n },\r\n "secondaryWorkerConfig": {\r\n "numInstances": 8,\r\n "instanceFlexibilityPolicy": {\r\n "instanceSelectionList": [\r\n {\r\n "machineTypes": ["n2-standard-8"],\r\n "rank": 0\r\n },\r\n {\r\n "machineTypes": ["e2-standard-8", "t2d-standard-8"],\r\n "rank": 1\r\n }\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b193203d0>)])]>

この API ポリシーは、同じ目標を達成します。つまり、優先するシェイプを確立し、有効なフォールバックを文書化し、自動化スクリプトを中断することなく、Managed Spark がリソースの制約を解決できるようにします。

インフラストラクチャポリシーの確立

この規模のデータを管理するには、固定された単一のマシンタイプに依存するのではなく、明確なリソースポリシーを標準化する必要があります。構成基準では、以下を規定する必要があります。

セカンダリワーカーの優先 VM ファミリーとフォールバック VM ファミリー。
柔軟なプロビジョニングを可能にするためのデフォルトの自動ゾーンプレースメント。
自動スケーリングを使用する場合のコアとメモリの同一構成。
コンテナのサイズを予測可能に保つためにすべてのワーカーグループで統一された CPU とメモリの比率。
異なるマシンライン間で一貫したランタイム動作を保証するための、YARN または Spark プロパティの明示的なオーバーライド。
Spot または弾力性の高い容量で実行される Spark ワークロード向けのシャッフルセーフパターン。

柔軟な構成を採用することで、インフラストラクチャのリソース不足が解消され、予測可能なフォールバックプランが適用されるため、重要なデータパイプラインを稼働させ続けることができます。

Yahoo の影響と結果

Yahoo は、Managed Service for Apache Spark にフレキシブル VM を実装することで、リージョンの容量不足が原因で発生していたクラスタプロビジョニングの失敗を 85% 削減することに成功しました。この柔軟な構成により、データインフラストラクチャは容量の制約に自動的に対処し、手動による介入を必要とせずにリソースを正常にプロビジョニングできます。その結果、Yahoo はワークロードを継続的に実行できるようになり、大規模なデータパイプライン全体でダウンストリーム処理の遅延を防止しています。

「Yahoo で大規模なデータ分析を管理するには、復元力のある自動化されたインフラストラクチャが必要です。Managed Service for Apache Spark のフレキシブル VM に移行したことで、当社のアプローチは一変しました。特定のマシンシェイプが容量の制約に直面したときに処理が停止するのではなく、クラスタがランク付けされたフォールバックオプションに自動的に切り替わるようになりました。これにより、プロビジョニングの失敗を 85% 削減し、グローバルメディアプラットフォームをスムーズに運用し続けるために必要な信頼性を確保できました。」- Yahoo!、シニアソフトウェアデベロッパーエンジニア、Akshay Jain 氏

柔軟なインフラストラクチャの戦略上のメリット

柔軟なコンピューティングスタックを採用することで、環境を運用ニーズに適応する動的なリソースプールへと変革できます。固定された単一のマシンタイプ構成に縛られないため、供給の変動に関係なく、ワークロードが必要なコンピューティングに確実にアクセスできるようになります。この移行により、ワークロードの入手可能性と信頼性が最大限に高まるだけでなく、古いタイプの VM を信頼性の高いフォールバックオプションとして維持しながら、新しい世代の VM を優先できるため、シームレスなハードウェアのモダナイゼーションが促進されます。

復元力のあるデータパイプラインを構築する

流動的なコンピューティング戦略に移行することで、リージョンリソースが変化しても、重要な分析を継続できます。インフラストラクチャの最適化を今すぐ始める方法を以下に示します。

ワークロードを検証する: 特定の VM ファミリーやゾーンに緊密に結合されているアプリケーションを特定し、実行可能な代替ハードウェアシェイプをマッピングします。
リソースポリシーを標準化する: Managed Spark のフレキシブル VM のドキュメントを読んで、優先 VM ファミリーとフォールバック VM ファミリーを確立します。
財務戦略を調整する: ワークロードが代替マシンタイプに動的に移行する場合に、フレキシブル確約利用割引（フレキシブル CUD）を利用して費用の予測可能性を維持します。
クレジットを獲得する: 新規のお客様は、Managed Service for Apache Spark や他の Google Cloud プロダクトを無料で試すことができる $300 分のクレジットを獲得できます。

- Yahoo、シニアソフトウェアエンジニア Akshay Jain 氏

- Google Cloud、データ / AI エンジニア Surjit Singh

BigQuery の TabFM のご紹介: 予測分析の再定義

Tue, 15 Sep 2026 01:00:00 +0000

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

これまで、チャーン、購入意向、不正行為スコアの予測といった企業の予測分析タスクでは、XGBoost、ランダムフォレスト、ディープニューラルネットワーク（DNN）などのライブラリを使用してカスタムモデルを構築する必要がありました。トレーニング、チューニング、デプロイ、再トレーニングという従来のサイクルは効果的ですが、複雑で時間がかかる場合があります。さらに、手動での特徴量エンジニアリング、ハイパーパラメータチューニング、時間と費用のかかるトレーニングといったオーバーヘッドに加え、専門的なデータサイエンススキルが必要となることから、企業は意思決定において予測モデルを十分に活用できていない可能性があります。

この投稿では、BigQuery の TabFM モデルについてお知らせします。Google Research が開発した TabFM は、表形式データの回帰と分類に対応した、最先端の事前トレーニング済み基盤モデルです。コンテキスト内学習（ICL）を使用し、単一の SQL ステートメントを介して、表形式のデータセットに対する高精度な予測を瞬時に提供し、独立したトレーニングとデプロイの手順を不要にします。BigQuery の TabFM は現在プレビュー版です。

TabFM は、以下のようなメリットを BigQuery 分析にもたらします。

ゼロショット予測: モデルのトレーニング、チューニング、アーティファクトのデプロイをスキップします。ラベル付きの過去データと新しい予測テーブルを単一の SQL 関数に渡すだけで、高品質な予測を即座に取得できます。
エージェントアプリケーション向けの予測 ML: ビジネス用途のエージェントを構築する場合、TabFM と BigQuery MCP サーバーを組み合わせることで、予測機能を追加できます。ランタイムやインフラストラクチャを管理する必要はありません。データを入力するだけで予測結果が得られます。
最先端の精度: 複雑なデータセットにおいて、カスタムトレーニングされた既成の従来モデルを上回り、業種別ベンチマークで優れた精度スコアを達成します。
シンプルなデベロッパーエクスペリエンス: BigQuery 上でネイティブに実行され、シンプルな SQL 構文でアクセスできます。欠損値やカテゴリエンコードなどの特徴量化タスクを自動的に処理するため、複雑な特徴量エンジニアリングパイプラインを管理する必要がありません。
スケーラビリティ: BigQuery の分散推論アーキテクチャを使用して、大規模な推論テーブル（最大数百万行）を数分で処理します。

表形式の予測のための主要なモデル

Google の TabFM は、幅広い表形式データにわたり業界トップクラスの精度を実現しています。TabArena ベンチマークの評価において、TabFM のパフォーマンスは、従来の ML モデルと他の表形式基盤モデルの両方を一貫して上回っています。

TabArena の分類（上）と回帰（下）における上位 10 モデルの ELO 評価（↑）。（D）= デフォルト、（T+E）= チューニング + アンサンブル。スコアが高いほど、パフォーマンスが優れていることを示します。

TabFM モデルについて詳しくは、こちらをご覧ください。

BigQuery で TabFM を使ってみる

TabFM の使い方は簡単です。新しい組み込みの SQL 関数である AI.PREDICT と AI.EVALUATE を通じて、直接利用できます。

1. AI.PREDICT で即座に予測結果を取得する予測を行うには、トレーニングデータと予測データを渡す単一のクエリを記述します。モデルは、ターゲットラベルのデータ型に基づいて、タスクが分類問題か回帰問題かを自動的に推論します。

code_block: <ListValue: [StructValue([('code', "-- トランザクションが不正かどうかを分類する\r\nSELECT *\r\nFROM AI.PREDICT(\r\n TABLE `my_project.my_dataset.historical_transactions`, -- トレーニングデータ（コンテキスト内の例）\r\n TABLE `my_project.my_dataset.new_transactions`, -- 予測データ\r\n label_col => 'is_fraud'-- 予測するターゲット列\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19a6d450>)])]>

この例の出力には、予測テーブルの元の列すべてに加えて、予測ラベルと確率の列（predicted_is_fraud など）が含まれます。手動での特徴量エンジニアリングやモデルの作成は不要でした。

2. AI.EVALUATE でモデルを評価するAI.EVALUATE 関数を使用すると、テストセットに対する予測パフォーマンスをすばやく確認できます。これにより、標準的な評価指標を 1 ステップで生成できます。

code_block: <ListValue: [StructValue([('code', "-- 顧客のライフタイムバリュー（LTV）の回帰評価\r\nSELECT *\r\nFROM AI.EVALUATE(\r\n TABLE `my_project.my_dataset.historical_customer_ltv`,\r\n TABLE `my_project.my_dataset.test_customer_ltv`,\r\n label_col => 'ltv'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b196b7590>)])]>

AI.EVALUATE は、回帰問題に対しては r2_score、mean_absolute_error などの堅牢な指標セットを、分類問題に対しては適合率、再現率、f1 などの指標を返します。

BigQuery の TabFM の仕組み

従来の ML では、モデルパラメータをトレーニングデータセットに適合させる必要があります。これに対し、TabFM ではコンテキスト内学習を使用します。大規模言語モデル（LLM）が少数ショットのプロンプト例からタスクを学習するのと同様に、TabFM はトレーニングテーブルをコンテキスト内の例として読み取り、1 回のフォワードパスでターゲットテーブルに対する予測を生成します。

表形式基盤モデルの演算の複雑さとメモリ使用量に対応するため、BigQuery はデータに対して分散並列推論を実行します。さらに、インテリジェントなトレーニングデータサンプリングと分散実行を使用して、パフォーマンスとリソース使用率を最適化します。これにより、BigQuery はトレーニングデータとして大規模な入力行を処理しながら、数百万行の推論データに対して迅速かつ効率的に予測を実行できます。

ジョブに適したツールを選択

TabFM は、BigQuery に画期的なゼロショット機能を導入し、XGBoost モデルなどの既存のサービスを補完します。TabFM と他のモデルのどちらを選択すべきかは、以下の基準で判断します。

TabFM は、ML の専門知識がなくても迅速かつ高品質な予測分析情報が必要な場合や、過去のデータセットが小規模から中規模である場合、データが頻繁に変更される場合、そして精度を維持するためにモデルを頻繁に再トレーニングする必要がある場合に使用します。また、オンデマンドでの予測分析を必要とする会話型ワークフローやエージェントワークフローにも適しています。
XGBoost のような従来のモデルは、非常に大規模な過去のデータセットがある場合、カスタムハイパーパラメータチューニングを完全に制御する必要がある場合、TabFM の現在の制限を超えるほど特徴量が多い場合、または特徴量の重要度の説明可能性（例: どの入力特徴量が予測に最も貢献したか）が必要な場合に使用します。

予測 ML が簡単に

TabFM が BigQuery にネイティブに統合されたことで、予測 ML は標準の SELECT クエリを実行するのと同じくらい簡単になりました。TabFM により、モデルのトレーニング、チューニング、管理に伴う手作業のオーバーヘッドが排除され、デベロッパー、データサイエンティスト、アナリストは、元データから豊富な予測分析情報を数秒で取得できます。

今すぐ利用を開始するには、一般公開ドキュメントをご覧ください。ご質問やご意見がございましたら、bqml_feedback@google.com までお知らせください。皆様がどのようなものを構築されるのか、楽しみにしております。

- グループプロダクトマネージャー、Vaibhav Sethi

- エンジニアリングマネージャー、Xi Cheng

BigQuery の新しい ID 列でパイプラインを簡素化

Fri, 11 Sep 2026 02:00:00 +0000

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

お客様のデータジャーニーをさらに支援するため、このたび、BigQuery の ID 列のリリースを発表いたしました。この新機能により、ユーザーは連続する 64 ビット整数値を自動的に生成する列を定義できるため、テーブル内の一意の識別子の管理方法を簡素化できます。

データエンジニアは、データの取り込みをよりスムーズかつ信頼性の高いものにする方法を常に模索しています。BigQuery の ID 列は、テーブルに一意の数値を自動的に生成する強力な組み込みメカニズムを提供します。ID 生成の責任を BigQuery に移すことで、データパイプラインの複雑さを大幅に軽減し、分析情報の提供に集中できるようになります。

データパイプラインにとっての主なメリット

ID 列を実装すると、データアーキテクチャの開発とメンテナンスの効率化に役立つ、いくつかの利点が得られます。

取り込みの合理化: アプリケーションロジックや ETL ツールで一意のキーを事前に計算する必要なく、データを取り込めるようになります。
ボイラープレートの削減: 自動生成されたシーケンスを使用することで、データベースでキー管理がネイティブに処理されるため、SQL コードがよりクリーンになり、メンテナンスしやすくなります。
自動化の統合: ID 列は標準の DML オペレーションとスムーズに連動し、新しい行ごとに一意の識別子が自動的に割り当てられます。
柔軟な統合: INSERT ステートメントと MERGE ステートメントのどちらを使用している場合でも、ID 列は既存のワークフローに適応します。

ID 列を実装する方法

ID 列の設定は簡単で、CREATE TABLE ステートメント内で直接行うことができます。これらの値の処理方法を定義するには、主に 2 つの方法があります。

定義のオプション

句	説明
`GENERATED ALWAYS AS IDENTITY`	BigQuery が値の一意性を自動的に管理、保証します。
`GENERATED BY DEFAULT AS IDENTITY`	自動生成された値が提供されますが、必要に応じて手動でオーバーライドすることもできます。

使用例次の SQL ステートメントは、ID を自動的にインクリメントするテーブルを作成する方法を示しています。ID は 1 から始まり、新しいエントリごとに 1 ずつ大きい値になります。

code_block: <ListValue: [StructValue([('code', "CREATE TABLE my_project.my_dataset.orders (\r\n order_id INT64 GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1),\r\n customer_name STRING,\r\n order_date DATE\r\n);\r\n\r\n-- Ingesting data is now simpler:\r\nINSERT INTO my_project.my_dataset.orders (customer_name, order_date)\r\nVALUES ('Joe Doe', CURRENT_DATE());"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19e5c4d0>)])]>

使ってみる

ID 列は、柔軟性とパフォーマンスが高く、標準に準拠したデータプラットフォームを提供するという Google の継続的な取り組みを象徴するものです。サロゲートキーの生成を自動化することで、スケーラブルでメンテナンスしやすいデータアーキテクチャを簡単に構築できるようにしています。

プロジェクトにこの機能を実装する方法の詳細については、BigQuery の ID 列に関するドキュメントをご覧ください。

- プロダクトマネージャー Wawrzek Hyska

- ソフトウェアエンジニア Aayush Bhatnagar

数週間から数分へ: データパイプラインの新たなエージェント時代

Thu, 10 Sep 2026 16:00:00 +0000

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

データパイプラインは現代の企業のバックボーンですが、オーケストレーションには参入障壁があり、多くのデータ専門家がこの重要な機能を利用できない状況にあります。Google Cloud NEXT ’26 での発表で Orchestration Pipelines フレームワークを紹介したことで、この状況は根本的に変わろうとしています。

この強力なフレームワークを実務担当者に直接提供するため、Google は Data Agent Kit を提供しています。これは、データエンジニアリングとデータサイエンスのツールを統合した、自由に利用できるオープンソースのコレクションで、お好みの IDE や CLI（VS Code、Claude Code、Codex など）に直接統合できます。

Data Agent Kit は、Orchestration Pipelines フレームワークを 2 つの異なる方法でワークフローにシームレスに組み込みます。まず、包括的なパイプライン管理のための専用の [データエンジニアリング] タブが用意されています。2 つ目は、自然言語を使用して本番環境グレードの Apache Airflow® DAG を作成、デプロイ、トラブルシューティングできるように設計された、専門的なエージェントスキルです。

これらの専門的なエージェントスキルを宣言型の YAML DSL と組み合わせることで、アナリストから ML エンジニアまで、あらゆるデータ担当者が複雑な Python Airflow ボイラープレートを回避できます。このフレームワークは、高レベルのオーケストレーションロジックを基盤となるコンピューティング実行から切り離し、データ組織全体で強力な MLOps 機能へのアクセスを民主化します。

この投稿では、MLOps の模範的なユースケースを例に、これを簡単に実現する方法を説明します。

環境設定

最初のオーケストレーションパイプラインを作成する前に、ローカル開発環境を設定する必要があります。2 分もかからずに開始できます。

1. 拡張機能をインストールして構成する

VS Code、VS Code フォーク、Antigravity、Claude Code、Antigravity CLI、Codex など、お好みの IDE または CLI に拡張機能をインストールし、Google Cloud アカウントで認証するには、公式ドキュメントの Google Cloud Data Agent Kit インストールガイドに記載されている手順に沿って設定します。

2. オーケストレーションパイプラインのスキルを確認する

インストールしたら、必要なエージェントスキルが有効になっていることを確認します。

VS Code アクティビティバーで [Google Cloud Data Agent Kit] パネルを開きます。
[設定] > [スキル] の順に移動します。
「gcp-pipelines-orchestration」スキルが有効になっていることを確認します。

このスキルにより、エージェントは、パイプライン構文、変数置換、シークレット管理、Airflow 実行の自動インシデント診断に関する深い背景知識を得ることができます。

3. 最初のパイプラインを構築する

自然言語プロンプトを使用して、VS Code 互換の IDE 内で直接オーケストレーションパイプラインの作成、構築、検証を開始するには、公式の構築ガイド（パイプライン構築ガイド）をご覧ください。

ビジネス上の問題の例: プロアクティブなサプライチェーン管理

ビジネス上の問題の例を見ていきましょう。物流および小売業界では、顧客満足度は正確な配達予定に左右されます。注文が予告なく遅延すると、顧客離れが急増し、サポート費用が膨らむ可能性があります。

これに対処するため、倉庫の場所、顧客の場所、注文の特性に基づいて正確な配送日数（日数単位）を予測するエンドツーエンドの MLOps アーキテクチャを構築しています。出荷前にこうした遅延を予測することで、運用チームはサービスレベル契約（SLA）に違反する前に、顧客に事前に通知したり、配送レベルを自動的にアップグレードしたりできます。

このアーキテクチャを完全に再現可能にするため、BigQuery の一般公開データセットである bigquery-public-data.thelook_ecommerce を使用します。デモの目的上、この静的データセットをトレーニングセットと推論セットに分割します。実際のシナリオでは、推論は新たに入ってくるデータに対して行われます。このデータセットは、実際の運用上の複雑さを提供します。

地理データ: 顧客の住所（users）と配送センター（distribution_centers）の緯度と経度。
時間データ: 注文ライフサイクルの詳細なタイムスタンプ（created_at、shipped_at、delivered_at）。
注文属性: 商品カテゴリ、価格、フルフィルメントステータス（orders、order_items）。

このデータセットを BigQuery、Managed Service for Apache Spark サーバーレス、Gemini Enterprise Agent Platform、dbt と組み合わせることで、トレーニング、毎日のバッチ推論、モデルドリフト評価を処理する、自動化された自己修復型の MLOps ループを構築する方法を実証します。

エージェントワークフロー: プロンプトからパイプラインまで、わずか数分で

拡張機能を構成すると、DAG 作成用のボイラープレート Python を完全にバイパスできます。VS Code 内で Data Agent Kit チャットを開き、単一の自然言語プロンプトを入力するだけで、継続的な MLOps フィードバックループを定義しました。

注: 詳細なプロンプトは、このブログ投稿のために、再現性を考慮して作成されました。実際のシナリオでは、パイプラインごとに、より会話調で同じ結果を達成できます。完全なプロンプトと生成されたすべてのファイルは、Orchestration-pipelines GitHub リポジトリで入手できます。

注: Orchestration Pipelines スキルを備えたフロンティアモデルは、多くの場合、1 ステップで完全なワークフローを骨組みを作成できますが、LLM のレスポンスは、モデルのバージョン、ワークスペースのコンテキスト、トークンの深さによって当然異なります。最初のパスで特定のパラメータ、データセットパス、依存関係が省略された場合は、短いフォローアッププロンプトを入力します。

数分以内で、Data Agent Kit が、基盤となる PySpark スクリプト、dbt 構成、3 つの宣言型 YAML パイプラインを生成しました。

生成された YAML パイプラインと、その視覚的な図を以下に示します。このパイプラインは、Orchestration Pipelines の機能を説明するために簡略化した例です。実際には、本番環境の MLOps の推奨設定は、具体的なユースケースや運用上のニーズによって異なります。

パイプライン 1: トレーニングエンジン

このパイプラインは、高負荷のコンピューティングエンジンとして機能します。エージェントは、まず BigQuery にクエリを実行して過去に完了した注文を抽出する YAML 定義を生成しました。その後、Managed Spark サーバーレスクラスタを動的にプロビジョニングして、地理的な距離を計算し、本番環境で使用するモデルをトレーニングします。最後に、トレーニング済みモデルを Gemini Enterprise Agent Platform Model Registry に push します。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "training-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - sql:\r\n name: "extract_training_data"\r\n engine:\r\n bigquery:\r\n location: "US"\r\n destinationTable: "your-project-id.mlops.training_dataset"\r\n query:\r\n path: "blogpostdemo/training_query.sql"\r\n\r\n - pyspark:\r\n name: "train_model_dataproc"\r\n dependsOn:\r\n - "extract_training_data"\r\n engine:\r\n dataprocServerless:\r\n location: "us-central1"\r\n resourceProfile:\r\n inline:\r\n runtimeConfig:\r\n version: "2.3"\r\n properties:\r\n "spark.dataproc.driverEnv.PYTHONPATH": "./libs/lib/python3.11/site-packages"\r\n "spark.executorEnv.PYTHONPATH": "./libs/lib/python3.11/site-packages"\r\n mainFilePath: "blogpostdemo/train_model.py"\r\n environment:\r\n requirements:\r\n inline:\r\n list:\r\n - "tensorflow==2.14.1"\r\n - "numpy<2.0.0"\r\n - "protobuf<5.0.0dev"\r\n - "google-cloud-storage"\r\n\r\n - ai:\r\n name: "upload_model_vertex"\r\n dependsOn:\r\n - "train_model_dataproc"\r\n agentPlatform:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n modelUpload:\r\n modelName: "transit_days_predictor"\r\n modelArtifactUri: "gs://your-bucket-name/models/tf_transit_days_model"\r\n servingContainerImageUri: "us-docker.pkg.dev/vertex-ai/prediction/tf2-cpu.2-14:latest"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19c7c0d0>)])]>

パイプライン 2: 日次推論

日々の運用ワークフローでは、この軽量なパイプラインが、トレーニング済みのモデルを現在配送中のすべての注文に適用します。BigQuery ジョブを介してデータセットをクエリし、Gemini Enterprise Agent Platform を介して推論ジョブを実行し、結果を BigQuery テーブルに書き戻して、カスタマーサポートチームに SLA 違反の可能性を通知します。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "inference-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - sql:\r\n name: "extract_inference_data"\r\n engine:\r\n bigquery:\r\n location: "US"\r\n destinationTable: "your-project-id.mlops.inference_dataset"\r\n query:\r\n path: "blogpostdemo/inference_query.sql"\r\n\r\n - ai:\r\n name: "run_vertex_batch_prediction"\r\n dependsOn:\r\n - "extract_inference_data"\r\n agentPlatform:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n batchInference:\r\n jobDisplayName: "inference_job"\r\n modelName: "projects/your-project-id/locations/us-central1/models/your-model-id"\r\n bigquerySource: "bq://your-project-id.mlops.inference_dataset"\r\n bigqueryDestinationPrefix: "bq://your-project-id.mlops"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19340250>)])]>

パイプライン 3: 自動評価と分岐

日次評価パイプラインは、自動品質ゲートとして機能します。dbt モデルをトリガーして予測を実際の配送タイムスタンプと結合し、絶対誤差と SLA 違反を計算します。

パイプラインは、組み込みのロジックを使用して、これらの指標を自動的に評価します。モデルのエラー率が許容しきい値を超えた場合、条件に応じて「training-pipeline」がトリガーされ、新しいモデルが生成されます。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "evaluation-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - pipeline:\r\n name: "run_dbt_models"\r\n framework:\r\n dbt:\r\n airflowWorker:\r\n projectDirectoryPath: "blogpostdemo/dbt_project"\r\n\r\n - python:\r\n name: "check_retraining_condition"\r\n dependsOn:\r\n - "run_dbt_models"\r\n mainFilePath: "blogpostdemo/evaluate_drift.py"\r\n pythonCallable: "check_drift"\r\n engine:\r\n local: {}\r\n\r\n - orchestrationPipeline:\r\n name: "trigger_retraining_pipeline"\r\n dependsOn:\r\n - "check_retraining_condition"\r\n pipelineId: "training-pipeline"\r\n bundleId: "my-first-bundle"\r\n waitForCompletion: false'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b193405d0>)])]>

Managed Service for Apache Airflow への自動デプロイ

パイプラインロジックの作成は、作業の半分にすぎません。本番環境に安全かつ確実にデプロイする段階で、データチームはこれまで貴重な時間を失ってきました。

Orchestration Pipelines を使用すると、標準的な CI / CD プラクティスを通じてデプロイが合理化されます。デプロイスクリプトを手動で作成したり、複雑な環境境界を構成したりする必要はありません。Data Agent Kit が、ワークスペースに必要な継続的インテグレーションワークフロー（GitHub Actions など）を自動的に生成します。

つまり、commit をクリックするだけで、フレームワークが Orchestration Pipelines Bundle をシームレスにパッケージ化し、Managed Airflow 環境に直接デプロイします。

これらの自動化されたワークフローを既存の CI / CD パイプラインに統合するための包括的なガイドについては、公式ガイド「Orchestration Pipelines のデプロイ」をご覧ください。

Day 2（2 日目からの）運用: モニタリングとエージェントによるトラブルシューティング

これらのパイプラインのメンテナンスは、構築と同じくらい直感的に行えます。Data Agent Kit は、オーケストレーションコントロールプレーンを IDE に直接組み込むことで、ブラウザタブを頻繁に切り替えることなく、Managed Airflow の実行をリアルタイムでモニタリングできるようにします。

Data Agent Kit を使用すると、IDE 内で直接、Managed Airflow の実行をリアルタイムでモニタリングできます。

Data Agent Kit が、作成されたパイプラインを可視化します。

インフラストラクチャやデータの問題は避けられません。たとえば、季節的なデータの急増により Managed Spark クラスタでメモリ不足の例外が発生したり、BigQuery の割り当ての上限に達したりすることがあります。これらの問題を解決するために、何千行もの未加工の実行ログを調べる必要はもうありません。

パイプラインが失敗した場合、Data Agent Kit はすぐに使えるエージェント型トラブルシューティングを提供します。IDE で [トラブルシューティング] ボタンをクリックするだけで、データエンジニアリングエージェントが失敗のコンテキストを分析します。インフラストラクチャの割り当て上限とコードレベルのバグを正確に区別し、根本原因の概要を即座に提供して、インライン修正（コンピューティングテンプレートのスケールアップなど）を提案します。

エージェント型トラブルシューティングにより、パイプラインの障害を即座に診断し、インフラストラクチャのボトルネックを特定して、インライン修正を提案します。

まとめ: 価値創出までの時間を短縮

レジリエントな MLOps アーキテクチャの構築（過去のデータの抽出、dbt 変換の実行、Managed Spark ML コンピューティングのプロビジョニング、モデルレジストリと推論のための Gemini Enterprise Agent Platform のインテグレーション、DAG 間の条件付きトリガーの構成）には、従来、プラットフォームエンジニアリングチームが複雑な Python Operator ロジックを記述するのに数週間かかっていました。

Orchestration Pipelines と Data Agent Kit を使用することで、このライフサイクル全体を数分で作成、デプロイ、簡単にメンテナンスできました。ボイラープレートインフラストラクチャコードを、宣言型の、エージェント対応の標準に置き換えることで、データ組織がパイプラインのオーケストレーションに費やす時間を減らし、具体的なビジネス価値の創出に多くの時間を割けるようにしています。

使ってみる:

Orchestration Pipelines のドキュメントを確認する。
お好みの IDE または CLI に Data Agent Kit をインストールし、ワークスペースを構成する。
エコシステム全体の詳細については、最近のブログ投稿「Data Agent Kit は IDE または CLI にデータ処理のスキルとツールを提供」を確認する。
Data Agent Kit のドキュメントでリファレンスアーキテクチャを確認する。

- リードプロダクトマネージャー、Piotr Wieczorek

- ソフトウェアエンジニア、Alexandre Moueddene

BigQuery Graph の一般提供を開始: エージェントの時代を支える知識の基盤

Tue, 08 Sep 2026 02:10:00 +0000

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

エンタープライズデータで重要になる質問の多くは、個々の行に関するものではなく、さまざまな要素の相互関係に関するものです。たとえば、2 つのアカウントがどのようにリンクされているか、支払いがどのような経路をたどったか、AI エージェントの回答の根拠となるコンテキストは何か、というものです。グラフを使用することで、こうした質問に回答できます。従来、こうした分析情報を引き出すには、データをスタンドアロンのグラフデータベースに抽出する必要があり、結果的にサイロ化と運用上のオーバーヘッドを招いていました。こうした障壁を取り除くため、Google はネイティブグラフ機能をデータウェアハウスに直接組み込みました。そしてこのたび、BigQuery Graph の一般提供を開始いたしました。

プレビュー版の BigQuery Graph では、グラフ分析とリレーショナル分析を統合しました。ISO 規格の Graph Query Language（GQL）と SQL が併用され、走査がネイティブに実行されるため、ETL は不要です。また、BigQuery を基盤とする BigQuery Graph はその機能を継承し、さらに拡張しています。具体的には、スケールアップデータベースのメモリボトルネックなしでペタバイト規模に達し、既存の行レベルおよび列レベルのセキュリティの下で実行され、同じクエリで BigQuery ML と AI 関数を呼び出します。1 つのエンジンで、大規模なグラフ分析と AI エージェント向けの相互につながりのあるコンテキストの提供という 2 つの役割を担います。

「BigQuery Graph は、当社の脅威検出パイプラインに大きな変化をもたらし、単純でサイロ化されたアラートからの脱却を可能にしました。セキュリティシグナルデータをプロパティグラフとしてモデル化することで、以前は計算上不可能だった複雑なマルチホップ走査を数秒で実行できるようになりました。このグラフ中心のアプローチにより、異常が一貫した攻撃ストーリーに自動的にクラスタ化され、それが Gemini モデルのシームレスな統合と組み合わさることで、実用的な脅威ナラティブを生成できています。ネイティブの BigQuery Graph アルゴリズムを統合して、ワークフローをさらに効率化できるようになることを楽しみにしています。」- Thales Cybersecurity Products、グローバルエンジニアリング担当バイスプレジデント、Pete Rubio 氏

プレビュー版のリリース以降、さまざまな業界のデータチームによって分析ワークフローとエージェントワークフローの両方に BigQuery Graph が採用されてきました。

脅威と不正行為の検出: セキュリティ組織や金融機関では、イベントログ全体でシグナルを相互に関連付け、マルチホップ攻撃パス、不正行為ネットワーク、不審なトランザクションループを検出しています。
サプライチェーンのデジタルツイン: 製造組織や物流組織では、サプライヤー、部品、配送ルート間の依存関係をマッピングして、停止をシミュレートし、フルフィルメントを最適化しています。
ID 解決と Customer 360: 広告テクノロジープラットフォームと小売プラットフォームでは、断片化されたユーザー ID と行動タッチポイントを、チャネルをまたいで統合された顧客プロファイルにまとめています。
ナレッジグラフと AI エージェントのグラウンディング: 企業の AI チームは、非構造化ドキュメントから構造化されたナレッジグラフを構築し、Gemini モデルと GraphRAG ワークフローのグラウンディングのためのドメインコンテキストを提供しています。
ネットワークリネージとインフラストラクチャ管理: 通信業界と企業の IT チームは、複雑なネットワークトポロジ、サービス依存関係、マルチホップパス全体のデータリネージを追跡しています。

BigQuery Graph の新機能

一般提供までたどり着いたことには、単なる「安定性の確保」を上回る意味があります。この段階に達するまでに、2 つの取り組みを行いました。まず、グラフエンジン自体を高速化し、適用範囲を広げました。次に、エージェントがグラフを構築し、グラフとチャットし、監査可能なメモリをグラフに保持できるよう、グラフエンジンを取り巻くエージェントエコシステムを構築しました。以下で紹介する機能の中には、現時点で一般提供されているもの、プレビュー版のもの、数週間以内にリリースされるものが含まれています。

グラフエンジンの高速化と適用範囲の拡大

「広告業界は数十年にわたり、個々のイベントを最適化してきました。エージェントの時代が到来し、それらのイベント間の関係が最適化されるようになるでしょう。Yahoo の AI エージェントは、キャンペーン、オーディエンス、露出、成果などの相互につながりのあるコンテキストを BigQuery Graph から得ています。これらのコンテキストに対して、収益化データがすでに存在する場所で、標準の GQL を使用して走査を実行できます。個別のグラフエンジンやデータの移動は不要です。エージェントはグラフを読み取るだけでなく、グラフについて推論し、その結果を新しい関係として書き戻します。こうすることで、自動化を超えて、信頼できる自律システムへと収益化を移行させることができます。」- Yahoo、収益化プラットフォーム担当エンジニアリングディレクター、Mikul Bhatt 氏

ボーダーレスグラフレイクハウス

エージェントの性能は、推論対象となるコンテキストの質に左右されます。そして、そのコンテキストが 1 か所にまとまっていることはほとんどありません。ボーダーレスレイクハウスを使用することで、単一の BigQuery Graph で、ネイティブの BigQuery テーブルと（Databricks Unity Catalog、AWS Glue、Snowflake を介した）他のクラウドのオープンな Iceberg テーブルをその場で走査できます。データをコピーしたり ETL パイプラインを構築したりする必要はありません。

たとえば、サポートエージェントが「この顧客の遅れている注文の商品のサプライヤーはどこで、その拠点はどこか？」という質問に答える必要があるとします。顧客データは Google Cloud の Iceberg レイクハウスに、商品とサプライヤーのレコードは AWS の Databricks カタログにあります。この場合、エージェントは、リクエストごとにソースを結合するのではなく、すでにソースを相互に関連付けている 1 つの仮想ナレッジグラフを走査します。対象となるデータが移動することはありません。

図 1: Google Cloud（青色のノード）、AWS（黄色のノード）、その他のクラウド（緑色のノード）にまたがる仮想ナレッジグラフを示す図。データの移動は発生しない。

次の DDL ステートメントは、ノードテーブルとエッジテーブルを両方のクラウド環境に直接マッピングして、この仮想グラフを定義する方法を示しています。

code_block: <ListValue: [StructValue([('code', '-- A virtual knowledge graph spanning two clouds - no data movement\r\nCREATE OR REPLACE PROPERTY GRAPH `my_project.retail.virtual_kg`\r\n NODE TABLES (\r\n -- Google Cloud\r\n `my_project.gcs_lake.retail.customers` AS Customer KEY (customer_id),\r\n -- AWS\r\n `my_project.dbx_fed_catalog.retail.products` AS Product KEY (product_id),\r\n `my_project.dbx_fed_catalog.retail.suppliers` AS Supplier KEY (supplier_id)\r\n )\r\n EDGE TABLES (\r\n `my_project.gcs_lake.retail.purchases` AS Bought KEY (purchase_id)\r\n SOURCE KEY (customer_id) REFERENCES Customer (customer_id)\r\n DESTINATION KEY (product_id) REFERENCES Product (product_id),\r\n `my_project.dbx_fed_catalog.retail.products` AS Supplied_By KEY (product_id)\r\n SOURCE KEY (product_id) REFERENCES Product (product_id)\r\n DESTINATION KEY (supplier_id) REFERENCES Supplier (supplier_id)\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b18e219d0>)])]>

これにより、エージェントは 2 つのクラウドにまたがって組み立てられた、グラウンディング済みマルチホップの回答を 1 回の走査で取得できます。

code_block: <ListValue: [StructValue([('code', "-- Agent grounding: trace a customer to the supplier behind their product, across clouds\r\nGRAPH `my_project.retail.virtual_kg`\r\nMATCH (c:Customer {customer_id: 'C1'})-[:Bought]->\r\n (:Product)-[:Supplied_By]->(s:Supplier)\r\nRETURN s.name AS supplier, s.country AS supplier_country"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b187cfb10>)])]>

GQL の高速化と表現力の強化

BigQuery Graph は、相互の関連付けに関する質問に対応するように構築されています。たとえば、2 つのアカウントがどのようにリンクされているか、支払いがどのような経路をたどったか、フラグが付けられたエンティティから数ホップ以内にどのエンティティが存在するか、といった質問です。これらは SQL 結合では表現が難しい質問であり、このような場面でグラフエンジンが真価を発揮します。一般提供では、実行速度が向上し、記述がさらに容易になりました。

迅速な実行。一般提供では、非巡回および無向の走査の経路探索が最適化されています。公開ベンチマークと比較して、プレビュー版以降の GQL は 2 倍高速になり、無向の走査は 100 倍になりました。ACYCLIC および TRAIL 経路モードでは、より高速でリソース効率の高いサイクル検出が可能です。クエリのレイテンシが低いため、エージェントの回答の根拠となる近傍検索とパス検索は、頻繁なインタラクティブアクセスでも応答性を維持できます。
表現力が強化されたクエリ。新しい CALL ステートメントと拡張されたサブクエリのサポートにより、結果のエンティティごとにグラフサブクエリを実行したり、再利用可能な名前付き関数を呼び出したりできるため、複雑な質問を 1 つの広範なパターンとして扱うのではなく、複数のパーツに分割できます。アナリストが記述する同じ関数は、エージェントがツールとして呼び出す構成要素になります。

エージェントの時代への適応

「企業には従業員に関するデータが豊富にありますが、従業員に何ができるか、従業員がどの分野に適しているかについての共通認識はほとんどありません。BigQuery Graph を使用すると、散在する情報を 1 つの再利用可能なプロパティグラフに変換し、人材、役割、能力、証拠の相互関係を大規模に走査できます。これにより、相互につながりのある同じ従業員コンテキストを、数千の意思決定に利用できます。意思決定ごとにコンテキストを再作成する必要はありません。これにより、仕事の進め方に関するより難しい質問に関して、AI が回答のためのより強固な基盤を得ることができます。」- Workerbee、創設者兼 CEO、Heiko Roth 氏

グラフとチャットする

グラフを探索するために GQL を記述する必要はありません。BigQuery の会話型分析を使用すると、自然言語で直接グラフとチャットできます。この機能は、スキーマ内の関係を読み取って質問を SQL または GQL に変換し、パスベースの回答のために走査を可視化します。エージェントは、説明や類義語などのグラフメタデータを活用して、結果のグラウンディングを維持します。グラフをグラフたらしめている関係性こそが、自由形式の自然言語クエリに問題をもたらす曖昧さやハルシネーションを排除するのです。また、MCP サーバーを介して Gemini Enterprise を BigQuery Graph に接続したり、会話型データエージェントを直接 Gemini Enterprise に公開したりすることもできます。

エージェントを使用してグラフを構築する

グラフの準備作業（テーブルをノードとエッジにモデル化し、それらに対する GQL を記述する作業）は、すでにご利用のデータエージェントに任せることができます。Google は、GQL パターンマッチング、グラフと SQL の融合、推奨プラクティスに沿ったスキーマ設計など、BigQuery Graph の専門知識をエージェントスキルにパッケージ化し、エージェントがグラフを使いこなせるようにしました。これらの機能は、Google Cloud Data Agent Kit 拡張機能を使用することで、Antigravity、Visual Studio Code、Claude Code、Codex など、お好みのエージェントコーディングツールでそのまま利用できます。

このスキルは、アドバイスだけでなく作成も学習しており、この機能はまもなくリリースされる予定です。エージェントにデータセット、モデルドキュメント、ER 図を参照させると、ノードとエッジが提案され、グラフの構築前に各関係がデータと照合されて、一致率が表示されます。たとえば、98% で一致するものもあれば、56% で一致するものもあります。これにより、最初から信頼できるグラフを手に入れることができます。

エージェントに監査可能なメモリを提供する

エージェントのグラウンディングは、目的の半分にすぎません。残りの半分は、エージェントが何をしたかを記憶することです。エージェントの役割がアドバイスの提供から行動へと移行する中で、どのオプションが選択されたか、どのポリシーが適用されたか、どの代替案が却下されたかなど、すべての決定について事後に説明できることが必要になってきます。BigQuery Agent Analytics のコンテキストグラフを使用すると、エージェントが実行する各アクションが取り込まれ、コンテキストグラフに変換されます。これは、エージェントの推論を型付きのクエリ可能なトレースとして BigQuery Graph に直接保存したものです。トレース自体がグラフであるため、「エージェントの意思決定の理由」を 1 回の走査で確認できます。また、それらの決定に再結合した結果は、次の決定を改善するためのデータになります。

BigQuery Graph を今すぐ使ってみる

BigQuery Graph は、クラウドをまたいでグラフ分析を実行し、AI エージェントをデータにグラウンディングします。まずは、概要とデータモデルで GQL、ノードテーブル、エッジテーブルを連携させる方法を確認し、ご自身のチームのよくあるパターンに適用してみてください。不正行為の検出 Codelab で不審な資金移動や合成 ID を追跡したり、ID の解決 Codelab で断片化されたメール、デバイス、Cookie を 1 人の顧客に結び付けたり、サプライチェーンをデジタルツインとしてモデル化して、停止が発生したときに隠れた依存関係に対してクエリを実行したりできます。

ここから、エージェントへと進みます。エージェントコンテキストグラフ Codelab では、未加工のイベントログを、自律型エージェントが実際に行ったことを監査、説明、追跡するグラフに変換します。これは、信頼できるシステムを支える、相互につながりのあるメモリです。ワークロードがリアルタイムの運用トランザクションと大規模な分析の両方にまたがる場合は、Google の統合グラフソリューションで Spanner Graph と BigQuery Graph を連携させる方法をご確認ください。さらに詳しく知りたい場合は、電子書籍でプロセス全体を説明していますので、ぜひご覧ください。

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

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

Google Cloud 上でのサーバーレス Apache Spark: アーキテクチャの選択と AI によるトラブルシューティング

Tue, 08 Sep 2026 00:30:00 +0000

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

現代のエンタープライズデータエンジニアリングにおいて、Apache Spark は大量のデータセットを大規模に処理するための基盤となるフレームワークであり続けています。しかし、クラスタのプロビジョニング、YARN 構成のチューニング、アイドル状態のハードウェアのコスト回避といったインフラストラクチャの管理に追われ、最も重要である「復元力のあるデータパイプラインの構築」に集中できなくなることが少なくありません。Google Cloud は、Managed Service for Apache Spark を通じてこの運用上のオーバーヘッドに対処し、特定の運用ニーズに合わせたサーバーレスおよびマネージドクラスタの柔軟なデプロイモードを提供しています。

この技術ガイドでは、Google Cloud で Spark をデプロイするためのアーキテクチャに関する意思決定マトリックスに加え、リソースと費用を最適化する手法を詳しく解説します。また、組み込みの Gemini Cloud Assist を適用して、サーバーレスバッチパイプラインの障害を迅速にトラブルシューティングし、解決する方法を実演します。これら 3 つのパートは順番に読むとより理解が深まりますが、それぞれを個別に読んでも、Google Cloud での Spark 開発を進めるうえでの有用なヒントが得られます。

パート 1: Apache Spark デプロイモデルの選択

Managed Service for Apache Spark で Spark ワークロードを起動する際の最初の大きな意思決定ポイントは、従来のマネージドクラスタを構築するか、管理不要のサーバーレスインフラストラクチャフットプリントに移行するかを評価することです。

検討事項 1: マネージドクラスタかサーバーレスか

* Gemini Enterprise Agent Platform の Nano Banana 2 を使用して作成

従来の Managed Spark クラスタとサーバーレスのどちらを選択するかは、エコシステムの要件、そしてコスト効率を左右するリソースの利用パターンによって決まります。

ワークロードの頻度、レイテンシの影響を受けやすいワークロード、コストの適合性: クラスタノードの使用率ベースラインが常に高く（80% 以上）、継続的で予測可能性の高い24 時間 365 日のストリーミングまたはバッチ処理パイプラインや、ワークフローの起動時間が積み重なることで SLA 目標の達成が危ぶまれるような場合は、カスタム YARN 自動スケーリングルールを使用してファインチューニングした従来型クラスタを常時実行する方が、費用の予測可能性が高まります。一方、断続的、バースト的、アドホック、またはオーケストレータートリガーのパイプラインの場合は、Managed Spark サーバーレスが極めて有効です。運用管理の手間が省けるだけでなく、計画にかかる時間を短縮でき、アイドル状態のコンピューティング時間に対して料金を支払う必要がありません。
エコシステムとコンポーネントの要件: Managed Spark サーバーレスは、Apache Spark 3.x 以降のコードベースに完全に最適化されています。処理パイプラインが Apache Flink、Presto / Trino、Hive LLAP、Apache HBase などの他のエコシステムコンポーネントに依存している場合、または以前の Spark 2.x コードベースにロックインされている場合は、Managed Spark クラスタを使用する必要があります。
インフラストラクチャのカスタマイズのニーズ: Managed Spark サーバーレスは、基盤となる仮想マシン（VM）レイヤを抽象化します。ワークロードで、OS レベルでの高度なハードウェアチューニング、カスタム OS の初期化アクション、インスタンスへの root SSH アクセス、特定のローカル SSD 構成、カスタムマシンシェイプが必要な場合は、従来のクラスタが必要です。なお、サーバーレスは特定のアプリケーションレベルのライブラリをバンドルするためのカスタム Docker コンテナイメージをサポートしています。

検討事項 2: サーバーレスインタラクティブセッションとサーバーレスバッチ

* Gemini Enterprise Agent Platform の Nano Banana 2 を使用して作成

サーバーレスデプロイモードを選択したら、開発ステージと運用要件に基づいて適切な実行モデルを選択する必要があります。Managed Service for Apache Spark には、サーバーレスワークロードを実行するための 2 つのオプションがあります。

サーバーレスインタラクティブセッション

インタラクティブセッションは、反復的なユースケースや試験的なユースケースに最適です。コードブロックを記述し、中間 DataFrame を検査し、変数を変更し、データセットをメモリに保持したままビジュアリゼーションを生成します。

プライマリインターフェース: 人間参加型のインタラクション向けに設計されています。デベロッパーは、Colab、Gemini Enterprise Agent Platform Workbench、Antigravity、Jupyter ノートブックなどの好みの IDE を使用して、コードをセルごとに実行します。
アイドル時のコスト: コンピューティングリソースは、デベロッパーが検討している間も即座に実行できるようにアクティブな状態を維持します。セッションを非アクティブなままにすると、アイドル状態のコンピューティング料金が発生する可能性があります。

サーバーレスバッチ

バッチは、実行する内容がわかっていて、非インタラクティブな自動化された実行が必要な場合に便利です。このエンジンは、完成済みのパッケージ化された PySpark スクリプト（.py）または Java / Scala アプリケーションファイル（.jar）を、人間の手作業による介入なしに最初から最後まで実行します。

主なインターフェース: Managed Service for Apache Airflow、Cloud Scheduler、CI / CD パイプラインなどの自動オーケストレーターによって管理されます。
アイドル時のコスト: 実行時間に対してのみ、厳密に課金されます。コンピューティングリソースはオンデマンドでプロビジョニングされ、スクリプトを実行し、完了するとすぐにシャットダウンして、アイドル状態のコストを防止します。

開発から本番環境までのライフサイクル

これらの実行オプションは、自然なパイプラインライフサイクルとして連携するように設計されています。開発の初期段階では、ノートブックインターフェース内でサーバーレスインタラクティブセッションを開き、データセットの探索、スキーマのクリーンアップ、変換のプロトタイピングを行います。ロジックが検証され、変換が完了したら、コードを Python スクリプトにパッケージ化し、本番環境での実行のために Managed Service for Apache Airflow によってオーケストレートされるサーバーレスバッチジョブとしてスケジュールします。この移行により、運用の信頼性を確保しつつ、継続的な開発コストを最小限に抑えることができます。

パート 2: 高度なパフォーマンスチューニングと DCU コストの最適化

サーバーレスの Managed Spark は、クラスタメンテナンスの運用オーバーヘッドを解消してくれますが、デフォルト設定のまま本番環境でエンタープライズグレードのパイプラインを実行すると、パフォーマンスのボトルネックや予算の浪費を招く恐れがあります。効率的なデータコンピューティング単位（DCU）のバーンレートを維持するには、送信時にランタイム構成プロパティを使用してリソース割り当てを明示的に宣言する必要があります。

Google は最近、履歴ベースの自動チューニングを導入しました。サーバーレスの環境においては、この機能がベストプラクティスや過去の実行履歴に基づいて、最適化を自動的に適用します。これは、繰り返し実行されるバッチワークロードを、Google がコホートと呼ぶものにグループ化することで実現されます。自動チューナーが、同じコホート名で以前に実行された際のテレメトリーと統計情報を分析して、ボトルネックがどこにあるかを特定します。

ドライバとエグゼキュータのシェイプのカスタマイズ

デフォルトでは、サーバーレスバッチは一般的な仕様（4 コア、16,000 MB RAM）を割り当てます。これは、アプリケーションの性質によっては、効率性に重大な問題を引き起こす可能性があります。

メモリバウンドジョブ: 圧縮されていない大量のデータを処理するパイプラインは、メモリ不足（OOM）エラーが発生してクラッシュする可能性があります。これに対処するには、spark.driver.memory と spark.executor.memory を使用してヒープサイズを個別に増やします。
コンピューティングバウンドジョブ: 数学モデリングや大量のトークン化を実行する処理集約型のジョブでは、CPU が飽和状態になる一方で、高価な RAM がアイドル状態になる可能性があります。spark.driver.cores と spark.executor.cores を明示的に調整して、インスタンスごとの処理の同時実行をファインチューニングします。

デフォルトでは、コア数を増やすと、vCPU と RAM の比率に見合ったベースラインメモリが自動的にプロビジョニングされることに注意してください。そのため、コアとメモリの両方の値をオーバーライドすることが重要です。

自動スケーリングの境界の制御

Managed Spark サーバーレスは、未処理のタスクに基づいて、アクティブなエグゼキュータの数を動的にスケールアップおよびスケールダウンします。ただし、制約のないスケーリングは、不正なコードループや最適化されていないデカルト結合が導入されると、予算超過につながる可能性があります。

防御的なガードレールとして、spark.dynamicAllocation.maxExecutors を使用して常に明示的な上限を宣言してください。これは、予算超過を防ぐための安全装置として機能します。妥当な上限に制限することで、コードが最適に動作しない場合でも、ジョブが固定のインフラストラクチャフットプリントを超えてスケールすることはありません。

高優先度（SLA 主導）: maxExecutors で上限を高く設定して、リソースのバーストを可能にし、全体的なランタイム期間を最小限に抑えます。
低優先度（夜間バッチ）: maxExecutors で上限を低く、厳しく設定します。ワークロードの実行時間は長くなりますが、DCU の消費は予測可能な一定のペースに保たれ、コスト効率に優れた運用が可能になります。

シャッフルストレージの効率の管理

groupBy()、join()、distinct() などのワイド変換を伴う処理では、ネットワーク全体にデータを再配布する必要があり、シャッフルストレージと呼ばれる中間ディスク書き込みが発生します。

Spark はデフォルトで、パーティション数が 200 に静的設定されています（spark.sql.shuffle.partitions）。数ギガバイトに及ぶ大規模なデータセットを処理する場合、パーティション数が 200 個のままだと、個々のチャンクが大きくなりすぎてしまいます。パーティションのサイズが利用可能なエグゼキュータ RAM を超えると（たとえば、1 GB のパーティションを、割り当てられたヒープ領域 0.5 GB 内で処理しようとする場合）、データがディスクにあふれ出します。これにより、実行速度が低下し、プレミアムまたは標準のシャッフルストレージブロックの追加料金が発生します。目安として、各パーティションがメモリ内で約 100 MB ～ 200 MB のデータを処理できるように、合計データサイズに基づいてパーティションパラメータを動的にスケールするとよいでしょう。最適な結果が得られるまで、何回か繰り返す必要が生じる場合があります。

上述のプロパティは、主なチューニング可能なプロパティです。その他のサーバーレスランタイム構成プロパティについては、こちらのリンクをご覧ください。

パート 3: Gemini Cloud Assist による運用診断

本番環境で自動データパイプラインが失敗した場合、データエンジニアは従来であれば、ドライバとエグゼキュータにまたがる冗長で断片的なログファイルを何時間もかけて精査する必要がありました。Managed Service for Apache Spark は、Gemini Cloud Assist を Google Cloud コンソールにネイティブに統合することで、こうした手間を取り除きます。これにより、エンジニアは自然言語を使用して障害を診断し、解決できます。

この運用スタイルの変化を具体的に示すため、ある PySpark ETL パイプラインの事例を見ていきましょう。このパイプラインは、Google Cloud Storage（GCS）バケットから顧客トランザクションデータを読み取り、変換を適用する過程で、予期せぬランタイムエラーにより失敗したものです。この事例を通して、一般的なトラブルシューティングの流れを解説します。

ステージ 1: 欠落している実行パラメータの診断

新しいパイプラインの最初の実行試行中、バッチジョブのステータスが保留中から実行中に切り替わり、最終的には一般的な終了メッセージ「アプリケーションは終了コード 1 で失敗しました（Application failed with exit code 1）」とともに失敗状態になっています。

エンジニアは、Cloud Logging を手動でクエリしたり、コンソールの複数のセクションを移動したりするのではなく、エラーログを見つけて [ログを調べる] オプションを選択できます。この操作により、ネイティブの会話ペインが開き、Gemini Cloud Assist によってドライバのテレメトリーとシステムログが自動的に分析されます。

このシナリオでは、送信時に必要なランタイム引数（ソース GCS バケットパスなど）が省略されたために PySpark スクリプトが失敗したことを、アシスタントがわかりやすい英語で説明してくれます。Gemini Code Assist は、これらの引数を想定しているスクリプト内の正確な行を即座に特定するため、スタックトレースを読み取る必要がなくなります。

ステージ 2: スキーマとデータ型の異常を解決する

不足している引数を解決してジョブを再送信すると、パイプラインは実行されますが、2 回目のデータ異常が発生します。大量のデータを取り込むパイプラインでは、アップストリームのソースファイルに破損したレコードや形式の不整合が含まれていることがよくあります。

2 回目の失敗後、エンジニアは再び Gemini Cloud Assist にログの調査を指示します。アシスタントは TypeError を特定し、クラッシュの原因となっている正確な DataFrame 変換を特定します。これは、スキーマが列を文字列として自動推論したために失敗した除算演算（df['amount'] / df['transaction_id']）です。

さらに、アシスタントは基盤となる GCS ファイルデータをスキャンして、根本原因を特定します。この場合は、ソースデータセット内の非数値の異常（数値セル内のテキスト文字列など）です。

ステージ 3: 検証済みのコード修正の生成とデプロイ

エンジニアは、スキーマタイプをキャストして null 値をキャッチする PySpark ロジックを手動で書き換えるのではなく、Gemini Cloud Assist に直接プロンプトを入力して、復元力のあるソリューションを生成させることができます。

ユーザープロンプト: 「transaction_id ではなく、quantity で amount を割るようにコードを書き換える方法を提案して。さらに、プロセスを失敗させることなく無効なレコードをスキップするロジックを追加して。」

アシスタントは、復元力のあるキャストと null 処理関数（coalesce や try_cast など）を使用して、修正された PySpark コードブロックを生成します。

この修正されたスクリプトを実装することで、オーケストレーションパイプラインは、バッチ実行全体をクラッシュさせることなく、不良なソースレコードをスムーズに除外できます。後続の実行は正常に完了し、データの更新速度に関する SLA が維持されます。

サーバーレス Apache Spark の活用: メリットと次のステップ

データ処理パイプラインの管理に、インフラストラクチャ構成に関する高度な専門知識は必要ありません。サーバーレスバッチのハンズオフスケールと、動的割り当て上限やシャッフルサイズの計算など、リソースの明示的なチューニングを組み合わせることで、データチームはパフォーマンスとコストのプロファイルを厳密に管理できます。障害が発生しても、Gemini Cloud Assist をロギングワークフローに直接統合することで、複雑なトラブルシューティングのあり方が一変します。手動でログを精査する手間がなくなり、迅速で自動化されたサイクルへと進化させることができます。

これらのアーキテクチャを実際に使用するには、Managed Service for Apache Spark のドキュメントを確認し、Google Cloud コンソールでサーバーレスバッチを直接実行してください。

これらのコンセプトのアーキテクチャ分析の詳細については、エージェントの時代における Apache Spark® の実務担当者向けガイドを今すぐご覧ください。このガイドには、Codelab、ステップバイステップのワークフロー、GitHub リポジトリから直接実行できる PySpark と Terraform のテンプレートが含まれています。Google Cloud を初めてご利用になる場合は、$300 分のクレジット付き無料トライアルに登録することで、サーバーレスクラスタやマネージドクラスタ上でこれらのブループリントを無料でお試しいただけます。

- Google Cloud、データ分析担当カスタマーエンジニア、Lior（Leo）Ginzberg

Google Cloud の Lakehouse ランタイムカタログを使用して Apache Hive をモダナイズする

Tue, 01 Sep 2026 02:30:00 +0000

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

Apache Hive メタストア（HMS）は、10 年以上にわたり、ビッグデータ分析における事実上のメタデータ管理基盤として機能してきました。Hadoop クラスタ上でも、MySQL や PostgreSQL を基盤とする自己管理型の Compute Engine VM 上でも、HMS は中央スキーマレジストリとして機能し、Apache Spark、Presto、Hive が未加工の .parquet ファイルや .orc ファイルをクエリできるようにしてきました。

しかし、企業のデータアーキテクチャがペタバイト規模に拡大し、複数のクエリエンジン（Google Cloud Managed Service for Apache Spark、BigQuery、Trino など）を横断的に利用するようになると、従来の Hive メタストアが運用上の深刻なボトルネックとして顕在化するようになりました。

このブログ記事では、エージェント規模の最新のクラウド環境において、従来のメタストアがなぜ課題を抱えているのかを探り、昨年発表したサーバーレスの Google Cloud Lakehouse ランタイムカタログが、その解決にどのように役立つかを紹介します。このカタログは、オープンな Apache Iceberg REST カタログ仕様に基づいて構築されており、本番環境の Hive テーブルをわずか数分で即座に実行可能な形で移行できる、データコピー不要の移行ソリューションです。

従来の Hive メタストアの課題

本番環境で大規模な分析を実行しているデータエンジニアやインフラストラクチャ責任者の方々と話をすると、スタンドアロンの Hive メタストアには共通して 3 つの課題があることが分かります。

アーキテクチャとスケーリングのボトルネックスタンドアロンの HMS デプロイでは、テーブルスキーマ、パーティション、保存場所を追跡するために、リレーショナルデータベースのバックエンド（MySQL や Postgres など）に依存しています。データレイクが数十万ものパーティション分割テーブルにまで拡大すると、パーティションのプルーニングや大量のリスト処理が発生し、このことがリレーショナルデータベースにおける深刻なパフォーマンスのボトルネックを引き起こします。パーティションメタデータを要求する複雑な Spark ジョブが実行されると、メタストアの CPU 使用率が 100% に達し、クラスタ全体のクエリ処理に遅延が生じたり、メモリ不足（OOM）が発生したりする可能性があります。

サイロ化された ID とセキュリティガバナンス従来のメタストアは、境界ベースの Hadoop セキュリティモデルに基づいて設計されています。そのため、Apache Spark のコンピューティングジョブと BigQuery のようなエンタープライズ SQL エンジンの両方で、テーブルレベルのアクセス制御リスト（ACL）などの最新のきめ細かいデータガバナンスを適用するには、2 つの異なるコントロールプレーンに分断された、重複するセキュリティポリシーを維持する必要があります。

運用上のオーバーヘッドと総所有コスト（TCO）高可用性 MySQL / Postgres インスタンスの管理、HMS デーモンのパッチ適用、JDBC 接続プールの調整、アイドル状態でも課金されるインスタンスベースのメタストアサーバーの運用などは、データプラットフォームチームに大きな負荷を強いるものであり、本来であればエージェント向けの高価値なデータプロダクトの開発に充てるべき、データプラットフォームチームの貴重な時間を奪っています。

解決策: Lakehouse ランタイムカタログ

既存のペタバイト規模のストレージペイロードを書き換えることなく、こうしたアーキテクチャ上のボトルネックを解消するために、Google は Iceberg REST カタログと Hive カタログをサポートする Lakehouse ランタイムカタログを構築しました。

Lakehouse ランタイムカタログは、高可用性を備えた完全にサーバーレスな統合メタデータレジストリであり、従来の Hive / Parquet テーブルと、Apache Iceberg などの最新のオープンテーブル形式の両方をサポートするようにゼロから設計されています。 Lakehouse ランタイムカタログでは、Apache Iceberg REST カタログ仕様をネイティブに実装することで、メタデータ検出をコンピューティングエンジンから分離しています。カタログとコンピューティングエンジンをこのように分離することで、複数の Iceberg 互換エンジンがデータコピー不要で同じデータにアクセスできるようになり、その結果、顧客側でデータのコピーを複数維持する必要性が軽減され、ワークロードをより早く本番環境に移行できるようになります。

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

マルチエンジンの相互運用性: 登録されたテーブルは、標準の REST インターフェースを介して、Google Cloud Managed Spark、BigQuery、オープンソースエンジンで即座に検出やクエリが可能になります。
オープン API: Iceberg REST カタログと Hive カタログをサポートしているため、異なるチームがそれぞれ好みの分析ツールを使用しながら、単一の統合データセットを共有できます。
データコピー不要: テーブル定義は、Google Cloud Storage の既存のデータを直接参照します。基盤となるデータの移動、書き換え、複製を行う必要はありません。
AI を活用したガバナンス、セキュリティ、信頼できるコンテキスト: Lakehouse ランタイムカタログは、Knowledge Catalog および Cloud IAM と直接統合されているため、エージェント用の信頼できるコンテキストや、すべてのコンピューティングエンジンに一貫して適用されるテーブルレベルのセキュリティを定義できます。さらに、認証情報ベンディングなどの主要な認証メカニズムもサポートしています。これにより、基盤となる Cloud Storage バケット内のファイルに直接アクセスすることなく、テーブルにアクセスできます。
エンタープライズ対応、スケーリング、TCO 削減: Google の地球規模のインフラストラクチャと Spanner を基盤としたメタデータは、データに合わせてスケールできます。Cloud Storage のデュアルリージョンバケットとマルチリージョンバケットのサポートにより、フェイルオーバーのユースケースが可能になります。また、サーバーレスな NoOps 環境と、あらゆるワークロードサイズに対応可能なスケーラビリティにより TCO を削減します。

従来の Hive メタストアからゼロコピーで移行

実際の運用においてスムーズなカットオーバーが可能であることを示すために、従来の自己管理型 Hive メタストアを Google Cloud Lakehouse にモダナイズできる機能を提供しています。この機能は、従来の Hive メタストアに直接接続し、外部テーブルの定義とパーティションマップを抽出して、サーバーレスの Lakehouse カタログに直接登録します。登録後は、Google Managed Spark、BigQuery、Gemini の会話型分析エージェントでデータを利用できます。

Lakehouse にモダナイズし、主要なエージェントジャーニーで即座にデータを活用できるようにしましょう。

データアーキテクチャをモダナイズする準備はできていますか？

従来の Hive メタストアから Google Cloud の Lakehouse にモダナイズすることで、分析エンジンやエージェント間のデータサイロを最小限に抑え、マルチエンジンのガバナンスを統合し、信頼できるコンテキストをエージェントに提供し、運用コストを大幅に削減できます。これにより、最新のクラウド環境をエージェント規模で運用できる基盤が整います。

今すぐ Apache Hive メタストアテーブルを Google Cloud に移行して、エージェントの時代に備えましょう。Google Cloud Lakehouse の詳細については、こちらをご覧ください。

- Lakehouse 担当プロダクトリード、Vinod Ramachandran

- バイスプレジデント、Pratibha Suryadevara

BigQuery でエージェント時代の未来に備える: 継続的なコストパフォーマンスの向上を、手間をかけずに実現

Tue, 01 Sep 2026 01:00:00 +0000

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

現代のデータ環境において、クエリパフォーマンスのチューニングやシステムのコストパフォーマンスの管理は、大きな課題になっています。特に、エージェント型ワークロードの増加に伴い、その難易度はさらに高まっています。データの量、多様性、速度が爆発的に増加し続けるなか、クエリ実行プランの分析やスキーマの調整、クエリヒントの追加といった作業は、経験豊富な開発者や DBA にとっても終わりのないルーチンワークとなり、ビジネスの機動力を削いでいます。

パフォーマンスチューニングは一般的な手法ですが、最新のデータプラットフォームに求められるのは、それだけではありません。データプラットフォームが「インテリジェンスシステム」から「アクションシステム」へと進化し、分析ワークロードの主体が「人間による 1 日数回の実行」から「無数のエージェントによる毎分数千回の実行」へと移行するなか、従来の手動によるクエリ調整はもはや限界を迎えています。ユーザーのアクションに応じてエージェントやアプリケーションがクエリを自動生成するようになると、手動での最適化は事実上不可能です。

BigQuery は、データウェアハウスからエージェント型 AI 時代の主要なエンジンへと進化しました。ストレージとコンピューティングを真に分離した独自のアーキテクチャ、サーバーレス処理、きめ細かいコンピューティング管理を基盤に、BigQuery は自律的なクエリ処理の限界を押し広げ続けています。Google の究極の目標は、クエリ、スキーマ、データ、ワークロードを問わず、人間とエージェントの双方が手間をかけずに最適なコストパフォーマンスを享受できる、自律型クエリプロセッサを実現することです。2025 年だけでも、クエリのパフォーマンスが最大 35% 向上し、クエリ処理コスト（スロット使用量）が最大 40% 削減されました。

図 1. 業界標準のベンチマークに基づく、2025 年の BigQuery コストパフォーマンス向上の概要。

以下は、パフォーマンスと総所有コスト（TCO）の改善に貢献する主なイノベーションの一部です。これには、回帰に対する組み込みのガードレールも含まれます。

BigQuery の自己学習エンジン: 履歴ベースの最適化（HBO）

BigQuery の自律型クエリプロセッサの基盤となる機能の一つが、履歴ベースの最適化です。

従来のクエリオプティマイザーは、静的な統計情報やメタデータ、カーディナリティ推定に依存しています。そのため、非常に複雑な複数テーブルの結合や、急速に増加または変化するデータに直面すると、その精度が著しく低下することがあります。これらに対応することは、管理者にとって極めて重要な業務であり、効果的かつ効率的な運用には、ワークロードごとに自動化をきめ細やかに調整する必要があります。すべてが最新かつ正確であっても、自然なデータスキューや利用可能なコンピューティングリソースの変化により、クエリの動作が大きく異なることがあります。履歴ベースの最適化は、これまでのパラダイムを転換します。クエリ実行中にプランやリソース割り当てを変更できる BigQuery の既存の適応型クエリ実行に加え、過去の実行から学習し、将来の実行に向けてさらなる最適化を自動的に適用します。

過去のクエリのランタイム統計を追跡して、どの最適化が有益だったかを「記憶」し、それらを適用し続けます。また、以前のミスから学習して、同じミスを繰り返さないようにします。同じまたは類似のクエリが再度実行されると、BigQuery は効果が実証されている最適化手法を自動的に適用し、回帰を引き起こす可能性のある手法を回避します。

ユーザーの操作が不要、安全ガードレールが標準実装

履歴ベースの最適化では、アプリケーションの書き換え、SQL の修正、スキーマの変更は必要ありません。ユーザーは文字どおり何もする必要がなく、定期的なダッシュボード、ELT パイプライン、エージェントワークロード、事業部門モジュールがより高速に実行されます。

重要なのは、これが安全ガードレールを標準実装した、自己メンテナンス型、自己改善型のクローズドループシステムであるということです。履歴ベースの最適化は、パフォーマンスの向上が確実に見込まれる場合にのみ適用されます。もし最適化の判断を誤った場合は、どうなるでしょうか？この機能には本質的に自己修正能力が備わっています。最適化が適用されると、システムが結果を測定します。期待される改善が確認された場合、最適化が承認されます。パフォーマンスが大幅に向上しない場合、またはさらに悪いことに、パフォーマンスが低下したり、失敗につながったりした場合、その最適化は直ちに拒否され、取り消され、そのクエリに対して再度試行されることはありません。これにはデータスキューの検出も含まれます。これにより、パラメータ依存のプランを持つクエリにおいて、WHERE 句などのパラメータを一つ変更しただけでパフォーマンスが大幅に低下する、といった事態を防ぐことができます。

その結果、実行時間の短縮とスロットの削減が実現します。ある企業のお客様は、P90 の実行時間が最大 50% 短縮され、スロット使用量が最大 15% 削減されたと報告しています。これにより、コストパフォーマンスが大幅に向上し、回帰も発生しなくなりました。

図 2. 企業のお客様から報告された、履歴ベースの最適化によるパフォーマンス改善の一例。

BigQuery 実行エンジンに新しいトリックを教える: 高度なランタイム

BigQuery の自律型機能は、BigQuery の高度なランタイムによって、実行レイヤの深部にまで及びます。このエンジンのアップグレードにより、手動での細かなチューニングを一切行うことなく、クエリに最適な物理実行パスが自動的に決定されます。

1. ベクトル化の強化

ベクトル化実行自体は新しいコンセプトではありませんが、BigQuery は単一命令複数データ（SIMD）命令による最新のプロセッサ処理効率を活用することで、その実装を強化しました。エンジンは、重複する計算を回避する機会を自律的に特定し、辞書とランレングス圧縮でデータをネイティブに処理します。最先端の並列アルゴリズムと組み合わせ、対象となるクエリステージに適用することで、高速化の機会を増やします。効果: 完全に自動化されたプロセスを通じて、対象となるクエリを最大 10 倍まで安全に高速化し、全体のスロット時間を最大 40% 削減することに成功しています。

図 3. 高度なランタイム - ベクトル化の強化

2. 短いクエリの最適化

高い同時実行性と低レイテンシが求められる BI ダッシュボードや、1 秒未満のレイテンシを必要とし、数千件のクエリを生成するエージェント型アプリケーションの場合、分散処理に伴うオーバーヘッドがボトルネックになる可能性があります。BigQuery は、同時実行されている他のクエリに影響を与えることなく、対象となる「短い」クエリを自律的に高速化できるようになりました。ステージ数を減らしてデータシャッフルを減らすことで、BigQuery はクエリのレイテンシとリソース効率を全体的に向上させます。BigQuery は、スケーラブルな大規模並列処理（MPP）分散データベースにおいて、効率的な対称型マルチプロセッシング（SMP）クエリパスを透過的に実現しています。効果: 短いクエリのスロット使用量が最大 10 分の 1 に減少し、P99 のクエリレイテンシが 1 秒未満になります。各クエリのスロット占有時間が短縮されることで、一部のお客様のワークロードではスループットが最大 3 倍向上しました。これらはすべて、エンドユーザーが一切意識することなく、透過的に実現されます。

図 4. 高度なランタイム - 短いクエリの最適化

データ形式を問わない共通のメリット

Apache Iceberg のようなオープンテーブル形式を使用してオープンレイクハウスアーキテクチャを採用する場合でも、自律的なパフォーマンスを犠牲にする必要はないと Google は考えています。BigQuery のパフォーマンス向上は、基盤となるテーブルやデータ形式に関係なく同じように機能します。すなわち、BigQuery のネイティブ Capacitor ストレージ形式を使用する場合でも、基盤となるデータが Parquet 形式の Iceberg テーブルを使用する場合でも、同じメリットが得られるということです。

フィルタの自動プッシュダウン、列メタデータインデックス（CMETA）の枝刈り、ページスキップと非同期読み取りによる I/O レイヤの最適化、同じ拡張ベクトル化の採用など、オープン形式でもネイティブテーブルと変わらない自動高速化の恩恵を受けられます。

図 5. レイクハウス Iceberg テーブルでの BigQuery のパフォーマンスとコストを、TPC-DS（10 TB）から派生したベンチマークを使用して、一般的なオープンソースの分散 SQL クエリエンジンに対して社内でテスト

流動的なスケーリング: 実際の使用量のみを支払うオートスケーラー

BigQuery のコンピューティングモデルは、ノードやクラスタのスライスではなく、消費されたスロット秒に直接結びついているため、自律的なパフォーマンスの向上は直接的なコスト削減につながります。流動的なスケーリングで強化された BigQuery オートスケーラーを使用すると、コストとパフォーマンスのトレードオフを解消した優れた自動スケーリングモデルで、変動の大きいワークロードを柔軟に組み合わせて実行できます。BigQuery の流動的なスケーリングにより、消費されたコンピューティングリソース（スロット）に対して厳密な秒単位の課金が可能になり、自動スケーリングワークロードのコストが平均で最大 34% 削減されます。

図 6. 流動的なスケーリングを可能にする拡張オートスケーラー

流動的なスケーリングがもたらすコストパフォーマンスのメリットについて、1 日 1 PB 以上のデータを処理し、月間 3 兆件を超える入札を管理する大手アドテック企業 RISE の CEO / 共同創業者である Chen Shalit 氏は次のように述べています。「広告の世界は競争が激しく、1 セントも無駄にできません。BigQuery の流動的なスケーリングにより、インフラストラクチャのコストが 25% 削減され、スロット消費をスケールしてワークフロー全体を加速できるようになりました。モデルの結果をより迅速に提供し、1 時間あたりのデータ処理スループットを向上させることで、お客様に可能な限り最新のデータを提供できるようになりました。」

エージェント時代の未来に向けた基盤

これらの自律型機能は、現在のビジネスインテリジェンスダッシュボードや分析クエリの実行を高速化するだけでなく、最新のデータプラットフォームの未来を支える基盤となります。AI や ML の導入が急速に進むなか、組織のワークロードはエージェント型へと移行しつつあります。

AI エージェントによるデータの扱いは、人間とは根本的に異なります。クエリのレイテンシや同時実行数（QPS）に対する要件水準は、人間のユーザーが生成するものよりも桁違いに厳しく、人間を基準に設計された従来の分析プラットフォームの限界を超えています。自律型エージェントがリアルタイムの意思決定を行うために、1 秒間に数千もの異なる秒間クエリを発行するような状況では、人間参加型のクエリチューニングなど到底不可能です。

自己チューニングや自己学習システムといった BigQuery の差別化された機能には、回帰に対する組み込みの安全ガードレールが組み込まれています。こうした自律性が基準となることで、インフラストラクチャの手動管理、事後対応的なクエリの最適化、急増するコンピューティング費用の抑制といった作業に、貴重なエンジニアリングサイクルを浪費する必要がなくなります。その分、高度なエージェントアプリケーションでユーザーに最高のエクスペリエンスを提供するという、真に価値のある業務に時間と労力を集中させることができます。

BigQuery が TCO に与える総合的な効果: 高速化とコストパフォーマンスのさらなる向上

履歴ベースの自己学習型オプティマイザーと、高度にスケーラブルなメタデータプラットフォーム（CMETA）でサポートされる自動スケーリングの高度なランタイムエンジンを組み合わせることで、パフォーマンスと総所有コスト（TCO）に大きな効果がもたらされます。

まとめ

Google が目指しているのは、ユーザーの手を煩わせることなく BigQuery がクエリを自動的かつ安全に最適化することです。それにより、ユーザーが「出勤するだけで、BigQuery が前日よりも速くなっている」と感じられるような体験を提供したいと考えています。

データスキューや古い統計情報によるパフォーマンス低下の心配は無用です。どのクエリにどのプランガイドが最適か、時間帯や時期（日次、月次）に合わせて頭を悩ませる必要はなくなります。低価格なスポットインスタンスが不足して予算が足りなくなるのでは、と気をもむ必要はもうありません。組織の目標に集中するだけで、あとは BigQuery データプラットフォームがエージェントと人間のワークロードの両方に最適なコストパフォーマンスを自律的に提供します。特別な操作や設定は一切不要です。

BigQuery のデータと AI 機能の詳細を確認し、無料トライアルを開始しましょう。

- プロダクトマネージャー、Joe Yong

- グループプロダクトマネージャー、Manan Goel

構造化データと非構造化データのインサイトを統合する BigQuery 検索のイノベーション

Fri, 28 Aug 2026 00:10:00 +0000

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

現代の企業は膨大な量の非構造化データを保有しており、その管理や価値の抽出において大きな課題に直面することがよくあります。これまで、PDF、音声ファイル、画像、非構造化テキストに埋もれたインサイトを引き出すには、ウェアハウスからのデータ移動、複雑な LLM パイプラインの統合、散在する検索インデックスの管理といった、断片化されたアーキテクチャを前提とする必要がありました。

BigQuery は、こうした非構造化データを理解するために多くの企業で活用されています。たとえば、数千件に及ぶ臨床試験ドキュメント（PDF）を管理する先進的なヘルスケア企業では、BigQuery を使用することで、アクセス、処理、グラウンディング、関連付け、活用というシンプルな 5 段階のライフサイクルを通じて、これらのドキュメントから価値あるインサイトを抽出できます。

この投稿では、このフレームワークの「グラウンディング」のフェーズに重点を置いた 3 つの主要なマイルストーンを紹介します。

自律型エンベディング生成（一般提供版）
単一クエリのパフォーマンスが大幅に向上する AI.SEARCH（一般提供版）
ハイブリッド検索（公開プレビュー版）

これらの機能が連携して AI アーキテクチャを簡素化する仕組みを、実際の臨床試験研究プラットフォームを例に詳しく見ていきましょう。

パイプラインを簡素化する「自律型エンベディング生成」（一般提供版）

検索拡張生成（RAG）パイプラインや検索アプリケーションを構築するには、通常、複雑で非同期なエンベディングインフラストラクチャの管理が必要であり、新しいレコードが到着するたびに、再試行、エラーロギング、パイプラインのオーケストレーションを自分で行わなければなりません。

このたび、自律型エンベディング生成の一般提供が開始されたことで、BigQuery がユーザーに代わってこれらをすべて管理できるようになりました。スキーマで列を定義するだけで、新しいデータが取り込まれるたびに BigQuery が非同期かつ継続的にエンベディングを生成します。外部モデル（Vertex AI テキストエンベディングなど）を選択することも、BigQuery 内で Gemma エンベディングモデルをネイティブに直接利用することもできます。

実際の活用例

たとえば、Google Cloud Storage に保存されている臨床試験の PDF を分析する研究プラットフォームを構築しているとします。研究のタイトルや疾患領域をテーブルに抽出すると、そのタイトルを自動的に埋め込むことができます。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE TABLE mydataset.clinical_trials\r\n(\r\n trial_id STRING,\r\n study_title STRING,\r\n study_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>\r\n GENERATED ALWAYS AS (AI.EMBED(\r\n study_title,\r\n connection_id => 'myconnection',\r\n endpoint => 'text-embedding-005'\r\n ))\r\n STORED\r\n OPTIONS( asynchronous = TRUE )\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b18e37150>)])]>

BigQuery は、1 つの構成でエンタープライズ規模の処理を管理することで、複雑なサードパーティのベクトルデータベースを不要にします。この自律的なエンベディング生成により、ソーステキストの変更に合わせてデータが自動的に同期されるため、手動による ML パイプラインが不要になります。この統合アプローチにより、動的なデータセットのワークフローが効率化され、カスタムデータスクリプトの維持管理にかかる運用上の負担が軽減されます。

さらに、この一般提供の開始に伴い、自律型エンベディング生成では ObjectRefs を使用して画像からネイティブにエンベディングを生成できるようになり、真のマルチモーダル検索と分析が可能になりました。

大規模な自然言語検索を可能にする「AI.SEARCH」（一般提供版）

会話型分析エージェントや快適なユーザーエクスペリエンスを真に実現するには、基盤となる検索インフラストラクチャが直感的かつ高性能である必要があります。

データをシームレスに埋め込むことができたら、次は、それらを効率的にクエリする手段が必要となります。このたび一般提供が開始された AI.SEARCH() は、自然言語に焦点を当てた合理的な検索エクスペリエンスを提供するもので、これにより、検索パスでエンべディングを生成することなく、意味的に関連するレコードを簡単に見つけることができます。また、自律型エンベディング生成と組み合わせることで、データセットで使用しているエンベディングモデルをそのまま検索にも利用できるため、利便性がさらに高まります。

さらに、昨年実施した効率化への投資の一環として、AI.SEARCH を単一クエリの実行向けに大幅に最適化しました。その結果、オンラインアプリケーションや単一クエリ検索（エージェント検索で最も一般的なもの）において、スロット効率が最大 133 倍向上したことが確認されています。

このことは、BigQuery 上のデータに対して、ユーザー向けの自然言語検索を高い同時実行性で処理しつつ、従来よりも高速かつ費用対効果の高い方法で提供できることを意味しています。

code_block: <ListValue: [StructValue([('code', 'SELECT base.trial_id, base.study_title, distance\r\nFROM\r\n AI.SEARCH(\r\n TABLE mydataset.clinical_trials,\r\n \'study_title\',\r\n "What treatments are available for advanced tumors?"\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b189fbed0>)])]>

キーワードとベクトルを統合する「ハイブリッド検索」（公開プレビュー版）

セマンティック（ベクトル）検索は非常に強力です。たとえば、上記のクエリでは、「化学療法」のような概念的に関連する用語も適切に返すことができます。しかし、セマンティック検索だけでは十分でない場合もあります。たとえば、研究者が、非常に専門的な免疫療法薬の具体的な名称（「MK3475」など）を検索した場合はどうなるでしょうか。この英数字の文字列には広い意味的な文脈がないため、純粋なベクトル検索だけでは正しく順位付けすることが難しい場合があります。

BigQuery のハイブリッド検索は、語彙検索と既存のセマンティック機能を統合することで、キーワードの類似性とその根底にある意味の両方に基づいてデータを取得できます。このアプローチは、セマンティックベクトル検索の概念的な深さと、語彙マッチングの高い精度を統合するものであり、Reciprocal Rank Fusion や BM25 などのアルゴリズムを利用しています。これにより、検索結果の精度が大きく向上するほか、キーワードの出現頻度や意味的な関連性に基づく再ランキングを通じて、LLM のハルシネーションに伴う費用を抑えることができます。ユーザーは、AI.SEARCH 関数や VECTOR_SEARCH 関数で HYBRID モードや lexical_search_columns パラメータを利用することで、この仕組みを実装できます。さらに、ベクトルインデックスを拡張してキーワードデータを含めることで、パフォーマンスを最適化し、語彙検索プロセスを高速化できます。

以下のように、AI.SEARCH() 関数のモードを HYBRID に設定するだけで、ハイブリッド検索を簡単に実行できるようになりました。

code_block: <ListValue: [StructValue([('code', 'SELECT base.trial_id, base.study_title, distance\r\nFROM\r\n AI.SEARCH(\r\n TABLE mydataset.clinical_trials,\r\n \'study_title\',\r\n "Cancer treated by MK-3475",\r\n mode => \'HYBRID\'\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b189fb350>)])]>

これらのハイブリッドクエリを大規模に高速化するには、検索の語彙部分で使用するキーワード列を含めるように CREATE VECTOR INDEX DDL を拡張するだけで、インデックスをネイティブに統合できます。

エンドツーエンドの非構造化データ分析プラットフォームの構築

ここで紹介した検索機能とエンベディング機能は、より大きなビジョンの一部にすぎません。Google は、エンドツーエンドの非構造化データ分析プラットフォームを構築しています。非構造化データの代表例のひとつがドキュメントであり、BigQuery は、以下のようなワークフローをエンドツーエンドで管理するための完全なツールセットを提供しています。

アクセス: オブジェクトテーブルを使用して、Google Cloud Storage に保存されている非構造化 PDF やドキュメントを直接クエリすることで、ゼロ ETL のワークフローを実現します。
処理: レイアウト対応のチャンキング（RAG に最適）には AI.PARSE や AI.CHUNK_DOC（近日リリース予定）などの組み込み AI 機能を利用するほか、エンティティ抽出 / 要約には AI.GENERATEを、SQL パイプラインで基盤モデルを直接使用してレコードを即座に分類するには AI.CLASSIFY を利用します。
グラウンディング: 自律型エンベディングとハイブリッド検索を使用して、精度の高いコンテキストを構築します。ハイブリッド検索は、セマンティックベクトル検索による概念的な理解と、語彙的なキーワードマッチングによる高い精度を組み合わせたものです。意味的な関連性とキーワードの出現頻度の両方に基づいて結果を再ランキングすることで、検索結果の精度が大きく向上するほか、LLM のハルシネーションも抑制できます。
関連付け: 抽出されたエンティティ（スポンサー、臨床試験、医薬品など）を BigQuery Graph にマッピングすることで、隠れたマルチホップのインサイトを発見できます。特別なグラフデータベースは必要ありません。
活用: BigQuery の会話型分析エージェントを活用して、これらすべてを統合します。AI.AGG などの関数を使用すると、複雑なデータと直接やり取りしたり、可視化を生成したり、大規模なトレンド分析を実行したりできます。

BigQuery において非構造化データが第一級のデータとして扱われるようになったことで、未加工のドキュメントと会話型 AI との間のギャップを埋めることが可能になりました。

準備ができたら

コードを確認する: BigQuery のドキュメント分析 GitHub リポジトリで、臨床試験に関するエンドツーエンドのデモの完全版をご覧ください。
ドキュメントを読む: 自律型エンベディングとハイブリッド検索の公式ドキュメントを読み、独自の統合データパイプラインの構築を今すぐ始めましょう。

- Google、プロダクトマネージャー、Joe Malone

- Google、エンジニアリングマネージャー、Francis Lan

ゼロコード、低コストのデータの取り込み: BigQuery DTS の新機能

Fri, 28 Aug 2026 00:00:00 +0000

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

急速に変化するデジタルエコノミーにおいて、データは最も重要なエンジンです。しかし、多くの企業は、脆弱な社内 ETL パイプラインの構築や修正に週 100 時間以上をかけたり、予測不可能なサードパーティツールと格闘したりといった犠牲を払う逆説的な状況に陥っています。

毎日、数千社のお客様が信頼して利用する BigQuery Data Transfer Service（DTS）は、このようなエンジニアリングの負担を解消します。フルマネージドのノーコードデータ移動ソリューションである BigQuery DTS は、BigQuery へのデータの取り込みを自動化し、チームがパイプラインのメンテナンスから戦略的なデータサイエンスへと数分で移行できるようにします。

エコシステムの拡大: 新しいコネクタと機能

BigQuery DTS は、データベース、広告、マーケティングプラットフォームにわたりデータサイロを排除するために、統合環境を急速に拡大しています。最新の追加機能と拡張機能は以下のとおりです。

オープンレイクハウスの取り込み

Apache Iceberg マネージドテーブルへの直接取り込み（プレビュー版）: Google Cloud Storage、Amazon S3、Azure Blob Storage などの一般的なソースから Iceberg マネージドテーブルにデータを直接取り込めるようになりました。これにより、BigQuery のトップレベルのパフォーマンスチューニングを活用しながら、マルチクラウドストレージと他のクエリエンジンとの完全な相互互換性を維持できます。

次世代のエージェント型アーキテクチャ

フルマネージドのリモート Model Context Protocol（MCP）サーバー（プレビュー版）: これにより、開発者は AI アプリケーションや AI エージェントを DTS に接続し、プログラムを使ってデータソースを検出したり、ユーザーに代わって転送を構成、実行したりできます。

エンタープライズデータベースとリレーショナルデータベース（完全転送と増分転送の両方をサポート）

Microsoft SQL Server（プレビュー版）: トランザクションテーブル、スキーマ、運用データを BigQuery 内の分析環境に直接転送し、簡単に一元化できます。
PostgreSQL（一般提供版）と MySQL（一般提供版）: データ配信を自動化し、大量のウェブワークロードやアプリケーションワークロードを一元的なデータウェアハウスに数分で簡単にレプリケートできます。オンプレミス環境、Cloud SQL、その他のクラウドからのデータレプリケーションに対応しています。

e コマースとグロースマーケティング

Shopify（プレビュー版）: 粒度の高い注文履歴、在庫ログ、顧客プロファイルを分析スキーマに直接抽出するプロセスを自動化します。
Klaviyo（プレビュー版）: 詳細なメールと SMS のエンゲージメントログ（クリック、送信、開封など）を抽出して、正確なマルチチャネルライフサイクル属性を構築します。
HubSpot（プレビュー版）: パイプライン、連絡先のトラッキング、インバウンドマーケティングの指標を同期して、収益オペレーションチームの連携を維持します。
Mailchimp（プレビュー版）: キャンペーンのパフォーマンスとオーディエンスリストの属性をデータウェアハウスに直接、自動的に移動します。

移行コネクタ

Snowflake（一般提供版）: 増分転送、スキーマの自動検出、プライベート接続、3 つの主要クラウド（Google Cloud、AWS、Azure）に保存されているデータの移行サポートなどの機能を使用して、Snowflake からデータを移行できます。

主要なコネクタの機能強化

ServiceNow、Salesforce、Oracle: ネイティブの増分更新サポートが強化され、エンタープライズ規模の CRM、ITSM、財務ワークフローの大規模なパイプライン更新が高速化されました。

BigQuery Data Transfer Service を選ぶ理由

エンタープライズアーキテクチャ内でデータを移動する際に、費用、管理オーバーヘッド、パイプラインの健全性の間で複雑な妥協を求められるべきではありません。BigQuery DTS は、次の 3 本の柱にわたって独自のメリットを提供します。

1. 比類のないコスト効率

主要なソースの取り込み費用はゼロ: Google 広告、Google アナリティクス 4、キャンペーンマネージャー、YouTube、Google Cloud Storage など、Google Play を除く Google のソースすべてのデータの取り込みが無料です。Amazon S3、Azure Blob Storage、Amazon Redshift、Teradata の取り込み費用も無料です。
サードパーティ SaaS は使用量ベースの低料金: サードパーティソースからの取り込みは、すべて柔軟な使用量モデルに基づきます。コンピューティング料金は、主要なリージョンでスロット時間あたり 6 セント未満です。料金は行数ではなくコンピューティングフットプリントに応じて変動するため、ソースデータの圧縮形式と利用可能なネットワーク帯域幅によっては、大量のデータを効率的に転送できます。

2. スムーズなセキュリティとネイティブ管理

中継サーバーや、外部のセキュリティと API の構成が不要になります。BigQuery DTS は Cloud IAM と完全に統合されています。データ転送は、追加の構成オーバーヘッドなしで、宛先データセットの列レベルのセキュリティ、行レベルのセキュリティ、顧客管理の暗号鍵（CMEK）を即座に継承します。ストリームは、ネイティブの Google Cloud 境界内で安全に流れます。

3. 業界トップクラスのパフォーマンスとレジリエンス

エンタープライズ規模でデータを管理する場合、ダウンタイムはビジネスの機会損失を意味します。BigQuery DTS は、高い復元力を持つ取り込みフットプリントを提供し、これは厳格な Google Cloud サービスレベル契約（SLA）に裏付けられています。システムは月間稼働率 99.99% 以上を実現し、分析、自動化されたパイプライン、運用ダッシュボードの更新を確実に保証します。

データ運用の変革を始めましょう

手動の取り込みスクリプトにビジネスの成長を制限される状況はもう終わりにしましょう。Google のネイティブクラウドレイクハウスデータ移動アーキテクチャを利用して、最新のスケーラブルなデータスタックを構築している数千社もの企業の仲間に加わってください。

今すぐプラットフォームをお試しください。BigQuery Data Transfer Service コンソールに移動し、コネクタを選択して、数回クリックするだけで最初の自動転送をデプロイできます。

次に構築すべきコネクタは？

Google は、お客様のビジネスニーズに基づいて、ネイティブ統合ライブラリを常に拡大しています。現在、手動で抽出せざるを得ないソースはあるでしょうか。次にレプリケートする必要がある特定のリレーショナルデータベース、NoSQL エンジン、リージョン SaaS プラットフォームについて、機能リクエストでお知らせください。

機能リクエストは、公開 Issue Tracker からお送りいただけます。

- プロダクトマネージャー、Vignesh Rajamani

- エンジニアリングマネージャー、Pallavi Palleti

Google Dataflow で費用対効果に優れた高スループットな生成 AI ワークフローを構築する

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

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

リアルタイムストリーミングパイプラインは現代の企業において運用のバックボーンとなっており、カスタマーサポートでのやり取りからトランザクションログまで、あらゆるデータを処理し続けています。従来のストリーミング DAG は静的なものであり、一度デプロイされると、その処理ロジックや実行パスは変更できなくなります。しかし、生成 AI エージェントを統合すれば、静的なロジックから適応型の実行へと移行することが可能です。これにより、データの内容に応じてストリーミングワークフローが実行時にプランを動的に立案し、データベースへのクエリや独自の修復処理を自律的に開始できるようになります。

たとえば、注文品の破損について顧客から不満を示すメッセージが届いた際、パイプラインの役割は単なるエラーログの記録や、ダッシュボードへのフラグ立てにとどまるべきではありません。顧客の注文と在庫の記録を保持するデータベースで注文情報を検索し、修復アクション（交換品の発送や払い戻しなど）を自ら判断して、顧客へのメール送信から最終的な対応結果の記録までを一貫して行うべきです。

しかし、生成 AI ワークフローをストリーミングシステムに実行しようとすると、スケール、レイテンシ、コストという、エンジニアリング上の根本的な障壁に直面することになります。すべての未加工イベントを、外部データベースとメールツールを備えた高負荷なモデルやマルチステップエージェントに直接送信すると、コストが跳ね上がり、レイテンシも増大します。また、API のレート制限もすぐに使い果たしてしまいます。

ここで紹介するパターンは、Google Dataflow（Google Cloud が提供する Apache Beam のフルマネージドサーバーレス実行サービス）と Agent Development Kit（ADK）を組み合わせてハイブリッドストリーミングパイプラインを構築することで、スケーラビリティと複雑さという課題に対処します。軽量で CPU バウンドな ML モデルをアップストリームで使用してイベントをフィルタリングし、評価することで、パイプラインの費用対効果を高く保ち、複雑なケースのみをダウンストリームエージェントにルーティングします。ケースを受け取ったエージェントは、実行するアクションを動的に決定し、パイプラインの静的 DAG に膨大な数の条件付きステップをハードコードすることなく、ストリームに動的分岐を導入します。

大規模ストリーム向けのユニバーサルなブループリント

以下ではカスタマーサポートにおけるトリアージのシナリオを例にしていますが、この「事前フィルタ + エージェントによるアクション」というパターンは、幅広い分野に適用できる普遍的モデルです。このパターンは、イベントの大多数（90% 超）が定型的であり、複雑なコンテキスト推論を必要とするイベントはごくわずかである、以下のようなストリームに適用できます。

IT 運用と DevOps: 数百万件の定型的なシステムログを CPU 上でフィルタリングし、重大な異常が検知された場合にのみエージェントをトリガーして診断を実行し、バグチケットを開く。
金融詐欺のトリアージ: 数百万件のトランザクションを軽量なローカルルールでスクリーニングし、疑わしいパターンが検出された場合にのみエージェントを呼び出してマルチデータベース検索ツールを実行する。
産業用 IoT: エッジで定常的なテレメトリーをモニタリングし、突発的な異常をエージェントにルーティングして、機器のシャットダウンやフィールドエンジニアへの通知など一連の対応を調整する。

アーキテクチャ: ストリーミングイベントを事前にフィルタする理由

高スループットなストリームの場合、メッセージの大部分は複雑な推論や修復を必要としません。その多くは、肯定的なフィードバック、中立的な問い合わせ、単純な質問などです。

すべてのイベントを高負荷な LLM ワークフローにルーティングすると、主に 3 つのボトルネックが発生します。

API のコスト: フロンティアモデルはトークン単位で課金されます。高スループットの場合、コストはストリームのボリュームに比例して増加します。
レイテンシ: データベース参照や外部 API 呼び出しを含むマルチステップワークフローには数秒かかるため、ストリーミング DAG のボトルネックになります。
割り当て: 外部 API には厳格なレート制限があり、ストリーミングワーカーがその枠をすぐに使い切ってしまうおそれがあります。

これを防ぐため、Apache Beam と Dataflow を使用して、事前フィルタリングされたパイプラインを構築します。

パイプラインフロー

取り込み: Google Pub/Sub から未加工の顧客メッセージを読み取ります。
軽量の感情分類器（CPU）: Apache Beam の RunInference 変換を使用して、軽量の CPU ベースの Hugging Face モデル（distilbert-base-uncased-finetuned-sst-2-english）ですべてのメッセージを処理します。これは Dataflow ワーカーの CPU でローカルに実行されるため、外部 API の費用は発生しません。
事前審査ゲート: シンプルな DoFn でストリームをフィルタします。感情が POSITIVE または NEUTRAL と判定されたメッセージは、確認応答を返したうえで破棄されます。
自動修復（ADK）: メッセージが NEGATIVE に分類された場合にのみ、ADKAgentModelHandler を介して gemini-3.5-flash を基盤とする生成 AI エージェントをトリガーします。エージェントは各種ツールを活用して、BigQuery でのユーザー検索、注文情報の取得、対応策の選定、Gmail API を介した通知メールの送信までを自律的に実行します。

適応的実行: Beam DAG の動的な構成

従来のストリーミングアーキテクチャでは、パイプラインの有向非巡回グラフ（DAG）は固定されています。Dataflow にデプロイされると変換のシーケンスが固定されるため、新しいタイプのアラートを処理したり、特定のイベントのルーティング方法を変更したりする必要が生じた場合はパイプライン全体を変更、テスト、再デプロイする必要があります。

感情の事前フィルタのダウンストリームに生成 AI エージェントを配置することで、静的な DAG 内に動的で適応性のあるノードを導入できます。

全レコードの 95% を占める肯定的または中立的なデータは、パイプライン上の高速な静的パスに沿って処理されます。しかし、フィルタがネガティブなレコードを検知すると、エージェントはペイロードを評価し、実行時に API ツールの適切な実行順序（データベースへのクエリ、在庫確認、メール通知など）を動的に選択します。これにより、パイプラインで複雑な決定木を動的に実行できるようになり、静的な Apache Beam コードに膨大な数の条件分岐をハードコードして構築、保守し続けるといった煩雑な作業が不要になります。

パイプラインの実装

Google Agent Development Kit（ADK）と RunInference フレームワークを活用した Apache Beam での実装例を以下に示します。

1. 軽量な感情モデルの定義

HuggingFacePipelineModelHandler を使用して、アップストリームの CPU モデルを定義します。このモデルは、ワーカーインスタンス上で感情を POSITIVE、NEUTRAL、NEGATIVE に分類します。

code_block: <ListValue: [StructValue([('code', 'model_handler = HuggingFacePipelineModelHandler(\r\n task="sentiment-analysis",\r\n model="distilbert-base-uncased-finetuned-sst-2-english"\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b18e20e50>)])]>

2. 高負荷な ADK エージェントの構築

ADK エージェントは修復アシスタントとして機能します。このエージェントに、次の 3 つのツールを実装します。

lookup_user: BigQuery に顧客のメールアドレスをクエリします。
lookup_orders: BigQuery に顧客の注文と現在の商品在庫をクエリします。
send_email: Gmail API を使用して対応メールを顧客に送信します。

code_block: <ListValue: [StructValue([('code', 'def make_adk_tools(project: str, dataset: str = "sentiment_demo"):\r\n def lookup_user(user_id: int) -> dict:\r\n """Look up user information (email address) from BigQuery by user ID."""\r\n from google.cloud import bigquery\r\n\r\n client = bigquery.Client(project=project)\r\n query = (\r\n f"SELECT user_id, user_email "\r\n f"FROM `{project}.{dataset}.users` "\r\n f"WHERE user_id = @user_id"\r\n )\r\n job_config = bigquery.QueryJobConfig(\r\n query_parameters=[bigquery.ScalarQueryParameter("user_id", "INT64", user_id)]\r\n )\r\n try:\r\n results = list(client.query(query, job_config=job_config).result())\r\n if results:\r\n row = results[0]\r\n return {"user_id": row.user_id, "user_email": row.user_email}\r\n return {"error": f"No user found with user_id={user_id}"}\r\n except Exception as exc:\r\n return {"error": str(exc)}\r\n\r\n def lookup_orders(user_id: int) -> dict:\r\n """Look up a user\'s orders and current product inventory from BigQuery."""\r\n from google.cloud import bigquery\r\n\r\n client = bigquery.Client(project=project)\r\n query = (\r\n f"SELECT p.order_id, p.product_id, pr.remaining_inventory, pr.price "\r\n f"FROM `{project}.{dataset}.purchases` p "\r\n f"JOIN `{project}.{dataset}.products` pr ON p.product_id = pr.product_id "\r\n f"WHERE p.user_id = @user_id"\r\n )\r\n job_config = bigquery.QueryJobConfig(\r\n query_parameters=[bigquery.ScalarQueryParameter("user_id", "INT64", user_id)]\r\n )\r\n try:\r\n results = list(client.query(query, job_config=job_config).result())\r\n orders = [\r\n {\r\n "order_id": row.order_id,\r\n "product_id": row.product_id,\r\n "remaining_inventory": row.remaining_inventory,\r\n "price": float(row.price),\r\n }\r\n for row in results\r\n ]\r\n return {"orders": orders}\r\n except Exception as exc:\r\n return {"error": str(exc)}\r\n\r\n def send_email(to_address: str, subject: str, body: str) -> str:\r\n """Send a plain-text email to the customer via the Gmail API."""\r\n import google.auth\r\n import googleapiclient.discovery\r\n import email.mime.text\r\n import base64\r\n\r\n try:\r\n creds, _ = google.auth.default(\r\n scopes=["https://www.googleapis.com/auth/gmail.send"]\r\n )\r\n service = googleapiclient.discovery.build("gmail", "v1", credentials=creds)\r\n\r\n mime_msg = email.mime.text.MIMEText(body)\r\n mime_msg["to"] = to_address\r\n mime_msg["subject"] = subject\r\n raw = base64.urlsafe_b64encode(mime_msg.as_bytes()).decode("utf-8")\r\n service.users().messages().send(userId="me", body={"raw": raw}).execute()\r\n return "Email sent successfully"\r\n except Exception as exc:\r\n return f"Failed to send email: {exc}"\r\n\r\n return [lookup_user, lookup_orders, send_email]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b18afb010>)])]>

LlmAgent を構成し、ADKAgentModelHandler に組み込みます。

code_block: <ListValue: [StructValue([('code', 'adk_agent = LlmAgent(\r\n name="remediation_agent",\r\n model="gemini-3.5-flash",\r\n instruction=(\r\n "You are a customer service remediation assistant with access to "\r\n "BigQuery lookup tools and an email sending tool. "\r\n "When given a prompt describing a customer situation, follow the "\r\n "numbered steps exactly and use your tools to complete the task."\r\n ),\r\n tools=adk_tools,\r\n)\r\n\r\n# RunInference handler for the ADK agent\r\nadk_handler = ADKAgentModelHandler(agent=adk_agent)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19be8b90>)])]>

3. Dataflow DAG の組み立て

パイプライン全体を明確に定義します。アップストリームの感情推論の結果はフィルタリングステップ（FilterNegativeADK）に直接渡され、フィルタリングステップはダウンストリームの ADKInference を条件付きで実行します。

code_block: <ListValue: [StructValue([('code', 'with beam.Pipeline(options=pipeline_options) as p:\r\n # 1. Read from Pub/Sub and classify sentiment on CPU\r\n sentiment_results = (\r\n p\r\n | "ReadFromPubSub" >> beam.io.ReadFromPubSub(topic=known_args.input_topic)\r\n | "DecodeMessages" >> beam.Map(lambda x: x.decode(\'utf-8\'))\r\n | "SentimentInference" >> RunInference(model_handler)\r\n )\r\n\r\n # 2. Filter out non-negative sentiment and invoke the ADK Agent\r\n _ = (\r\n sentiment_results\r\n | "FilterNegativeADK" >> beam.ParDo(FilterNegativeAndPromptADK())\r\n | "ADKInference" >> RunInference(adk_handler)\r\n | "LogADKResults" >> beam.ParDo(LogADKResponse())\r\n )'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b19beba50>)])]>

コストとパフォーマンスのメリット

このフィルタリングステップを導入すると、エンジニアリング面と運用面の両方で大きなメリットがあります。

1. 大幅なコスト削減

すべての受信イベントに対して料金を支払うのではなく、顧客のネガティブな感情が含まれる一部のメッセージ（通常は 5% 未満）に対してのみ Gemini の入出力トークンの料金を支払うだけで済みます。残りの 95% は CPU インスタンスでローカルに分類されるため、API の追加費用はかかりません。

2. 高いストリーミングスループット

Dataflow は、CPU による分類ワークロードを多数のインスタンスに分散して処理します。CPU 推論はミリ秒単位で完了するため、パイプラインを水平方向にスケールして高スループットのイベントストリームを処理できます。ツール実行のためにリクエストごとに数秒を要する高負荷な LLM エージェントは、呼び出し回数を最小限に抑えることで、バックログの発生を防いでいます。

3. ネイティブな Apache Beam 統合

DAG にエージェントを追加するのに、複雑なオーケストレーションロジックや手動のスレッドプールは一切必要ありません。ADKAgentModelHandler を Beam ネイティブの RunInference 変換と併用することで、並列ワーカースレッド、バッチ処理、統合の処理が自動化され、コードベースをクリーンでメンテナンスしやすい状態に保てます。

重要ポイント

ストリーミングデータは高速かつ大量であるのに対し、高負荷な生成 AI 推論は低速でコストがかかります。

Google Dataflow と ADK を使用して事前フィルタリングを組み込んだパイプラインを構築することで、ローカルの CPU ベースのモデルが持つ「低コストとスピード」、そして Gemini を活用したエージェントの「高度な自動化機能」という両方の長所を最大限に引き出すことができます。

完全なコードベースを参照してご自身でデプロイしてみる場合は、next-2026-demo GitHub リポジトリをご確認ください。

^{Apache Beam は Apache Software Foundation の商標です。}

- グループプロダクトマネージャー、Reza Rokni

- Google Cloud、ソフトウェアエンジニア、Danny McCormick

Malachyte がマネージドリアルタイム AI で小売業のコールドスタート問題を解決した方法

Thu, 27 Aug 2026 01:00:00 +0000

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

未知の潜在顧客に商品をすすめるには、どのような方法が最適なのでしょうか。

私たちは、Spotify や Priceline などの大手企業とともに、長年この問題の解決に取り組んできました。そして、Sidd Motwani を中心に、AI を活用した e コマースのレコメンデーションプラットフォーム Malachyte を創設したのも、まさにこの問題を解決するためでした。最近では、消費者はパーソナライズされて関連性の高いコンテンツを期待するようになり、オンラインサービスは消費者の関心を集めるために競わねばならず、その結果がビジネスの成否を左右するまでになっています。

Malachyte は、高度な AI モデル、特に大規模言語モデルを、パーソナライズやレコメンデーションといった従来の課題に新しい方法で適用する独自のインサイトを見い出し、それが革新を生むきっかけとなりました。

さらに、潜在顧客の獲得を目指すうえで、Malachyte が常に思い描いていたビジョンを実現し、パーソナライズアルゴリズムを構築し続けるには、セキュアかつスケーラブルで信頼性が高く、何よりも最先端の AI インフラストラクチャが必要でした。そこで、Bigtable や Managed Service for Apache Kafka などの Google Cloud ツールを活用することで、Malachyte は小売業者の売上を 2 倍、場合によっては 3 倍に増やすことに成功したのです。

ここでは、Malachyte がそのプラットフォームをいかにして構築したか、そして、企業家の皆様がこのようなサービスを利用して AI 基盤モデルのデプロイを新しい方法で開始するにはどうすればよいか、ご紹介します。

Malachyte はお客様の売り上げをどのように伸ばしたのか

Malachyte には、アテンションメカニズムを備えたニューラルネットワーク（大規模言語モデルを支えるのと同じコンセプト）を使用して、小売検索と商品ページをパーソナライズできることを発見したときがひらめきの瞬間でした。このアプローチは、大規模言語モデル（LLM）でシーケンス内のアイテムの相対的な順序から意味を引き出すために使用されています。この場合、シーケンスは文中の単語と音節の順序です。Malachyte は、これを小売業のウェブサイトやアプリに応用し、顧客がサイトを操作する際の一連の行動の把握に努めました。

LLM が文の次の単語を予測するように、e コマースサイトでユーザーが次に何を求めているかを予測できたらどうでしょうか。

GPT 以前の言語モデルでも、単語や単語の断片（現在ではトークンとして知られているもの）の特定の並びを調べることは可能でした。しかし、それらの初期のモデルでは、単語が同等の順序で並んでいても、連続していなかったり、並べ替えられていたりした場合にどうなるかを調べることはできませんでした。この状況が打破されたのは、LLM がアイテムのシーケンス内の複雑で広い範囲の依存関係を理解できるようになったときでした。これには、Google の Transformer に関する取り組みも部分的に貢献しています。

このより洗練された手法は、生成 AI の一般的な普及はもちろん、Malachyte によるこのテクノロジーの応用という点でも、劇的な成果をもたらしました。

これを実践で機能させるために、Malachyte はユーザーがサイトにアクセスしたときに、そのユーザーについて知り得るすべての情報をベクトル化しています。ほとんどのユーザーは初めてサイトを訪れるため、ユーザーに関する情報はほぼありません。これが、いわゆる「コールドスタート」問題です。これに対応するには、ユーザーとのあらゆるやり取りをすべて活用して、このベクトルを改良する必要があります。たとえば、クリックやクエリなど、ベクトルに新しい要素が追加されるたびに、ユーザーが次に何を求めているかの予測が促進され、ユーザーに関する情報がさらに提供されます。

Malachyte のプラットフォームでは、その際にユーザーベクトルと予測を同時に更新します。これにより、個々のユーザーとその好みをより深く理解できるだけでなく、匿名化されたユーザーデータを使用してモデル全体を改善することができます。推論を行うたびに、平均的な買い物客と特定の買い物客の両方のコンテキストが拡大する仕組みです。

Malachyte は、アテンションベースのニューラルネットワークを使用するだけでなく、ユーザープロファイルを 100 ミリ秒ごとに更新することで、さらなるイノベーションを実現しています。

Malachyte のレコメンデーションエージェントと検索エージェントは、ユーザーが前のページでクリックした内容に基づいて、次のページの検索結果やレコメンデーションカルーセルにデータを入力します。

正確には、このコンセプト自体は新しいものではありません。小売業者は長年にわたり、コラボレーションフィルタリングレコメンデーションシステムを使用して、類似するユーザーとアイテムを特定してきました。ただし、これには膨大な量のインタラクション履歴が必要でした。これらのモデルでは通常、サードパーティ Cookie ベースのプロファイルやユーザー属性など、大量のデータを必要とします。

しかし、セッション内のインタラクションのシーケンスに焦点を当てることで、小売業者はユーザーのプロファイルのみに焦点を当てるよりも、必要なデータや費用を抑えながら、はるかに多くのパーソナライズを実現できるようになります。また、長期的な Cookie データに依存しないことで、ユーザーのプライバシーをより尊重できる利点もあります。

これは、モデルの構造と、ブラウザデータ、クリック履歴、検索など、ユーザーに関するあらゆる情報をエンコードするマルチモーダルベクトルによって実現されます。出力もマルチモーダルです。同じモデルを、サイト内検索の商品ページ、カテゴリページ、「カートに追加」カルーセルに適用できます。

この仕組みは、カタログ内の各商品がユーザーベクトルと同じ空間に埋め込まれることで機能します。それにより、ユーザーベクトルが更新されて、関連する商品に近づき、関連しない商品からは遠ざかるようになります。エンベディングを計算するニューラルネットワークは、Malachyte と連携する小売業者全体で継続的にトレーニングされ、すべてのユーザーの品質を向上させています。このシステムは事実上、データ協同組合として機能し、各小売業者のユーザーがモデルをさらにスマート化させながら、それが全ユーザーに役立つ仕組みになっています。

商品の空間でベクトルとして表されるユーザーセッション。

この仕組みをすべてのユーザーに対して推論ごとに 100 ミリ秒で実現するために、Malachyte は Google Cloud のリアルタイム AI スタックを基盤とすることに大きなメリットを見出しました。

このシステムでは、すべての行動イベントが Managed Service for Apache Kafka クラスタにストリーミングされます。各イベントは、将来のトレーニングジョブのためにキューに入れられるのではなく、Bigtable で直ちにユーザープロファイルの更新に使用されます。Kafka クラスタにより、お客様のフロントエンドが永続化されるため、ユーザーセッションのシグナルをユーザーベクトルにどのように適合させるかをあまり心配することなく、迅速に処理できます。

Bigtable によって、Malachyte のサービスは適切なユーザーベクトルを検索して更新できるようになります。Bigtable と Kafka はステップごとに 10 ミリ秒のオーダーで動作するため、レコメンデーションループ全体が、ユーザーエクスペリエンスを中断することなく完了します。

小売業者のウェブサイト、Malachyte の AI モデルとサービングフロントエンド、コンテキスト管理インフラストラクチャから成る 3 層のリアルタイム AI アーキテクチャ。

高速コアの機能に加え、商品カタログの更新事項、在庫シグナル、小売店固有のディメンションデータから成る第 2 レイヤには、商品データを最新の状態に保つ働きがあります。このデータは Cloud Pub/Sub 経由で送信されます。Cloud Pub/Sub は、グローバルアクセスが可能な REST API を提供するため、小売業者は緻密な統合作業なしで接続を利用できます。Malachyte エージェントは Google Kubernetes Engine （GKE）で実行され、モデル推論は Google Compute Engine（GCE）で行われます。

商品カタログの更新事項などの外部データの継続的な取り込みは、Pub/Sub のグローバルメッセージングシステムを通じて行われます。

Google Cloud AI アーキテクチャに移行したことで、Malachyte は本番環境の AI 推論とトレーニングが GPU とストレージだけでは決まらないことを実証しました。高速な Key-Value ストア、ストリーミングレイヤ、マネージドメッセージングシステムを含むリアルタイムの継続的学習インフラストラクチャが必要であり、これらすべてが基盤モデルアーキテクチャと統合されていることが重要です。

このアプローチは、Malachyte のような小規模なチームでも業界に多大な影響を与えることができることを示しています。必要なのは、強力なインフラストラクチャとコア AI マネージドサービスへのアクセスです。

使ってみる

Malachyte のように業界に革新をもたらしたり、他社に先駆けて業界をリードしたりすることを目指すなら、Managed Service for Apache Kafka、Cloud Pub/Sub、Bigtable をお試しください。新規のお客様は、$300 分の Google Cloud クレジットを利用できます。

- Malachyte、CEO、Sidd Motwani 氏

Malachyte、スタッフ ML エンジニア、Vicki Boykis 氏

Box が Gemini Embeddings 2 でマルチモーダルエンタープライズエージェントを実現

Wed, 26 Aug 2026 02:00:00 +0000

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

エンタープライズコンテンツ管理は、クラウド移行の時代以来、最も大きなアーキテクチャの転換期を迎えています。

長年にわたり、企業は財務モデル、臨床試験プロトコル、M&A デューデリジェンスルーム、エンジニアリングスキーマ、法令遵守ハンドブックなど、数兆ギガバイトに及ぶ重要なデータを Box に保存してきました。これまでは、テキストベースの検索と検索拡張生成（RAG）によって、これらのリポジトリ内の膨大なナラティブナレッジが効果的に活用され、エンタープライズ AI インテリジェンスの強力かつ非常に効果的なベースラインが確立されてきました。

従来の RAG アーキテクチャはテキスト処理に優れていますが、エージェントの時代にはそれ以上のものが求められます。次なる論理的な進化は、このフレームワークを拡張して、テキストと並存する本質的にマルチモーダルで、高度な空間情報や構造を持つ要素を捉えることです。テキストエンベディングは文章のインデックス作成に優れていますが、マルチモーダルアーキテクチャは、これまでにない画期的な機能を実現します。たとえば、財務表における厳密な行と列のセマンティクスを保持したり、臨床データのような視覚的情報を解釈したり、複数ページにわたるフローチャートのロジックを空間レイアウトを維持したままマッピングしたりすることが可能になります。

あらゆるデジタルコンテンツに対応する次世代の機能を提供するため、Google Cloud と Box は Gemini Multimodal Embeddings 2 を活用して高度なマルチモーダル機能を Box の Agentic Platform に統合し、業界をリードする Box のインテリジェントコンテンツ管理プラットフォームと Google Cloud の高度な AI エンべディングを融合させています。

エンベディングの改善によるメリット: ドキュメントコンテンツの次元の拡張

視覚的および空間的なジオメトリの保持: 複数列の表や財務マトリックスなどの複雑なドキュメント要素は、その空間的なレイアウトによって意味を成しています。これらの要素をフラットなテキスト文字列に変換すると、列ヘッダーと対応するデータポイントとの関連付けが失われてしまうおそれがあります。マルチモーダルエンベディングにより、システムは人間とまったく同じようにドキュメントを解釈できるようになり、空間的な位置関係の整合性が維持されます。
視覚的なモダリティの解明: 企業のドキュメントには、技術的な図表、プロセスフローチャート、ブランディングアセット、製品写真などの視覚的なインジケーターが多数含まれています。マルチモーダル機能により、これらの要素は検索システムにとって不可視なものではなくなり、ユーザーは画像とテキストを組み合わせた同時検索が可能になります。
ハイブリッドファイル形式の接続: 実際のビジネスワークフローが、単一のドキュメント形式で完結することはほとんどありません。エージェントは、PDF ポリシー、ログを追跡するスプレッドシート、プレゼンテーション資料を相互参照する必要がある場合があります。マルチモーダルエンベディングによって RAG を拡張することで、これら多様な形式を横断した統一的な理解が可能になります。

アーキテクチャソリューション: Gemini Multimodal Embeddings 2

Google Cloud の Gemini Multimodal Embeddings 2 は、テキスト、ラスター画像、ドキュメントページ、レンダリングされたスプレッドシートの表、ビジュアルチャートを同一のセマンティック表現空間に埋め込むことができる、統合されたマルチモーダルベクトル空間を実現します。

gemini-embeddings-2 によって実現される主なプロダクト機能:

クロスモーダル検索（テキストからビジュアル / ビジュアルからテキスト）: 自然言語クエリにより、手動のタグ付けをすることなく、膨大なスライドライブラリから特定のチャートや図解といったピンポイントなビジュアル要素を検索および抽出できるようになります。
レイアウトを考慮したドキュメントエンベディング: ファイルを任意のテキストブロックに分割するのではなく、ドキュメントページのレンダリングを直接埋め込むことで、視覚的な階層構造、コールアウトボックス、構造的なコンテキストをそのまま保持できます。
異種形式のブリッジ: モダリティ固有の構造情報を損なうことなく、.docx、.xlsx、.pdf、.pptx、.png、.csv 間のコンテンツをシームレスにつなぐネイティブサポート。

マルチモーダルエンタープライズエージェントの 3 つのコアパターン

Box 内でマルチモーダルエンベディングを活用することで、従来の RAG を拡張して複雑なビジュアルワークフローをサポートするための、主要な 3 つの独自デザインパターンを見出しました。

パターン 1: 複雑な財務レポートと分析レポート

課題

企業の財務、調査、監査の各チームは、高度に構造化されたドキュメントを分析します。こうしたドキュメントでは、埋め込みの表、成長チャート、脚注アノテーションの中に重要なデータが存在しています。テキストのみのインデックス登録では、これらの数字がコンテキストから分離されるため、自動分析が困難になります。

マルチモーダルの利点

構造の整合性: エンベディングモデルは表やグラフの物理的な構造を捉えるため、財務エージェントは、どの列ヘッダーが特定の指標の行に対応しているのかを正確に理解できるようになります。
視覚的な傾向分析: エージェントは、記述された要約と、付随する棒グラフや折れ線グラフの視覚的な傾向を相互参照し、文書内の主張とソースデータとの不一致を特定して指摘できます。
コンテキストに応じたソースの特定: ユーザーは複雑なポートフォリオに対してクエリを実行し、特定の指標を裏付ける正確なページ、表、グラフを即座に取得できます。

パターン 2: マルチモーダルによる臨床意思決定支援と診断補助

課題

医療および臨床環境では、重要な患者データが、外部の外観写真（視覚的証拠）、顕微鏡の病理スライド（検査レポート）、構造化されたリスクマトリクス（トリアージグリッド）など、さまざまな非構造化の視覚およびテキスト形式に断片化されています。従来のテキストベースのシステムや個別の分析ツールでは、こうしたクロスモーダルな関係性を同時に統合して理解することはできません。その結果、重要な診断の遅れを招いたり、生命に直結する処置上の合併症を見逃したりするリスクが生じます。

マルチモーダルの利点

クロスモーダルな臨床情報の統合: 臨床写真、組織病理画像、トリアージグリッドを同一のスペースにインデックス化することで、身体症状と細胞レベルの検査エビデンスを同時に評価します。
微細な異常の特定: 顕微鏡下で観察される微細な視覚パターン（寄生虫の嚢胞壁など）を医学的知識と結び付け、希少な疾患を迅速に特定します。
リスクを考慮した意思決定支援: 得られた所見をトリアージフレームワークと照合し、生命を脅かすアナフィラキシーショックなど、患者の差し迫ったリスクについて即座に警告を発します。

パターン 3: ドキュメント間のマルチモーダル統合とデータ調整

課題

企業内の情報は、接続されていないファイルや形式（PDF の議事録、Excel のグラフ、PNG のチラシ、メールスレッドなど）に断片化されています。従来のツールはこれらのファイルを個別に分析するため、独立したドキュメントを横断して詳細を確認したり、データの矛盾を解消したりする際に、情報を結びつけて全体像を把握することができません。

マルチモーダルの利点

ファイル間の統合: 完全に異なる形式（PDF、スプレッドシート、画像、メール）の情報を同時に結び付けて、複雑なビジネスクエリに回答します。
不整合の解決: アセット間の不整合を特定して解消します。たとえば、最新の財務スプレッドシートと照合することで、画像内に記載された古い価格情報を見つけ出すといったことが可能です。
画像とテキストの照合監査: 画像やスキャンされたファイルをテキストベースの記録と照らし合わせ（署名済みの PDF 契約書を法的レビューのメールで検証するなど）、条項の欠落や変更箇所を特定します。

エージェント型エンタープライズコンテンツ管理の未来

gemini-embeddings-2 と Box のエージェントプラットフォームのインテグレーションは、次世代のコンテンツインテリジェンスを向上させる重要な新機能です。マルチモーダルエンベディングにより、Box は従来の検索の枠を超え、能動的かつインテリジェントなコラボレーションへと進化します。Box のインテリジェントコンテンツ管理プラットフォームは、エンタープライズ AI インフラストラクチャの根本的な転換を体現するものです。単なる受動的なドキュメントストレージから、ガバナンスの効いたセマンティックインデックスによる推論レイヤに移行することで、AI エージェントは、既存のコンプライアンスとセキュリティ管理を維持したまま、コンテンツの照会や相互参照、アクションの実行を自在に行えるようになります。

マルチモーダルエンベディングと、検索、メタデータ抽出、調査、分析、作成にわたるネイティブ AI エージェントスイートを搭載した Box により、組織は、古い価格データの特定、契約条項の期限切れ、ドキュメント間の矛盾といったインサイトを、ビジネスリスクが顕在化する前にプロアクティブに抽出できるようになります。金融サービス、ライフサイエンス、法務業務といった複雑性の高い業界では、マルチモーダル理解が競争上の必須要件となっています。Box なら、テキスト、表、グラフ、画像を横断して推論することが可能です。

より広範なエンタープライズ AI エコシステムとの相互運用を前提に設計された Box は、ガバナンスの効いた一元的なコンテンツ基盤として機能します。これにより、AI を活用したあらゆるワークフローが、承認済みで監査可能な企業データに基づいていることが保証されます。

考えてみれば、企業のデータ環境はもともとマルチモーダルなものでした。そして今、それを最大限に活用するためのテクノロジーが現実のものとなりました。gemini-embeddings-2 とのインテグレーションにより、Box は、ユーザーが非構造化エンタープライズコンテンツからこれまでにない価値を引き出せるよう支援します。マルチモーダルファーストのアーキテクチャ、厳格な精度ベンチマーク、そして監査対応のグラウンディングを積極的に取り入れるプロダクトリーダーが、企業の生産性とイノベーションにおける次なる波を牽引することになるでしょう。

このプロジェクトに携わってくださった Ken Ikeda、Afshaan Mazagonwalla、Samip Thakkar の各氏に感謝いたします。

- Google、エージェントプロダクトコンサルティングリード、Sandhya Patil

- Box、スタッフ AI プロダクトマネージャー、Darryl Sladden 氏

メジャーがサポートされるようになった 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 0x7f3b18bcf990>)])]>

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

SOAP Architecture: S3 に眠るデータを、Google Cloud で AI エージェントの基盤に変える

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

利用している主なサービス・ソリューション

Products Used: BigQuery, Looker / LookML, Knowledge Catalog, BigQuery Graph, Cross-Cloud Interconnect, Gemini Enterprise
Solutions Used: Borderless Lakehouse, Data Analytics & AI Platform

生成 AI の活用が経営課題となる一方で、その原動力であるデータの多くは、長年運用されてきた Amazon S3 に眠ったままです。「まずデータ基盤を全面刷新してから」と考えた瞬間に、移行の規模とリスクの前で計画は止まり、AI 活用は PoC の先へ進めなくなります。膨れ上がる移行コスト、断片化したナレッジ、そしてビジネスの文脈を持たないままもっともらしい回答を返す AI——従来のアプローチでは、この距離を容易に埋めることはできません。

本稿では、この課題に対する一つの答えとして、SOAP Architecture (Semantic and Ontology Agent Platform) をご紹介します。データを動かさずにつなぎ、意味と知識の層で AI をグラウンディング（接地）し、エージェントに働かせる。Google Cloud のデータ分析ポートフォリオを一枚の設計図にまとめた、リファレンスアーキテクチャです。

SOAP の考え方はシンプルです。

つなぐ - データは AWS 等に置いたまま、BigQuery から直接分析します。
意味を与える - LookML、BigQuery Graph、Knowledge Catalog、Open Knowledge Format がデータに文脈を与えます。
働かせる - Conversational Analytics と Gemini Enterprise が、その意味を理解して動きます。

大規模なデータ移行プロジェクトは、前提ではありません。

データは動かさない: Borderless Lakehouse で「いま在る場所」につなぐ

SOAP の土台は Borderless Lakehouse です。 S3 上の Apache Iceberg テーブルは、Cross-Cloud Interconnect とキャッシュ(プレビュー版)を通じて BigQuery から直接クエリでき（Cross-Cloud Interconnect を導入していない環境でも、インターネット経由での接続が可能です）、AWS Glue Data Catalog / Databricks Unity Catalog / Snowflake Horizon のメタデータは、カタログフェデレーション(プレビュー版)で Lakehouse のランタイムカタログと自動的に同期されます。 ETL パイプラインを組む前に、まず「つながる」のです。 ( Iceberg 形式のファイルでない場合は Cross-Cloud Connections で直接参照可能です)

このアプローチは、次のメリットをもたらします。

ゼロコピーのクロスクラウド分析: ファイルを複製することなく、S3 のデータをその場で分析できます。分析のために「まずコピー」する運用から解放されます。
「クラウド間の税金」の解消: 外向きデータ転送料はかかりません。(相互接続サービスの時間単位の料金はかかります) 従量の egress 課金に怯えることなく、クロスクラウド分析を定額で計画できます。 (Partner Cross-Cloud Interconnectを使用した場合)
初日からの価値: 接続したその日から、使い慣れた SQL でレガシーデータに問い合わせできます。移行の完了を待つ必要はありません。

AI の信頼性は、モデルではなく「意味の層」で決まる

SOAP の名前の中核である Semantic and Ontology は、このアーキテクチャの最も重要な主張を表しています。エージェントの回答品質を決めるのは、モデルの選定ではなく、データに与えられた意味と関係の質だということです。

ここで言うオントロジーとは、業務上の実体 (顧客・注文・商品…) と、その関係と意味を、AI が直接読める形で表現した知識の構造のことです。メタデータが「何があるか」の目録なら、オントロジーは「何を意味し、どう繋がるか」の地図です。

セマンティックレイヤを担うのは LookML です。指標やディメンションの定義を一元管理し、ダッシュボードと AI が同じ「言葉の定義」を共有します。オントロジーを担うのは BigQuery Graph、Knowledge Catalog、そして Open Knowledge Format (OKF) です。テーブル間の関係をグラフとして明示すれば、エージェントが結合方法を推測する余地がなくなり、ハルシネーションの入り口を塞げます。

この層は、次の 3 つの要素で構成されます。

セマンティックレイヤ(LookML): 「売上」「アクティブ顧客」の定義を一箇所に。 BI と AI の回答が食い違う問題を根本から解決します。
ナレッジグラフ(BigQuery Graph): 顧客、注文、商品といった実体の関係をプロパティグラフとして定義し、ISO 標準の GQL で問い合わせます。グラフはそのままエージェントのデータソースになります。
オントロジーの「共通語」(OKF + Knowledge Catalog): Knowledge Catalog が社内 Wiki のようなページも参照しながら、テーブルの意味、指標の背景、運用のナレッジを OKF (Markdown のバンドル) として生成します。生成した OKF は Git で管理し、エージェントへは Knowledge Catalog が供給します。散在していた組織のナレッジが、AI の資産に変わります。

3 つの入口、1 つの基盤: エージェントが「使う」

意味の層が整うと、その上で複数の利用スタイルが同じガバナンスのもとに成立します。 SOAP では、利用者を 3 つのペルソナで捉えます。

定型分析とドリルダウン: Looker のダッシュボードが LookML に接地した指標を提供します。Looker の Conversational Analytics は最大 5 つの Explore を束ね、質問ごとに適切な Explore へルーティングします。
Agentic なアドホック分析: BigQuery の Conversational Analytics が、BigQuery Graph をデータソースとして自然言語の質問に答えます。エージェントは A2A(Agent2Agent)プロトコルで Gemini Enterprise に公開され、ビジネスユーザーは Slack や社内ポータルから話しかけるだけです。
エンジニアリング分析: VS Code や Claude Code などのコーディングエージェントが、Data Agent Kit を通じて同じ基盤に接続します。 OKF は Git ネイティブなので、エンジニアはナレッジそのものをコードと同じレビュープロセスで育てられます。

入口は 3 つですが、接地はひとつです。どの入口から入っても、同じ定義、同じ権限、同じナレッジで答えが返ります。権限はエージェントのために新設するものではなく、BigQuery と Looker の既存のアクセス制御がそのまま適用されます。

モダナイズもエージェントと進める: 「移行計画書」から始まる

データ基盤のモダナイゼーションが止まる本当の理由は、技術ではなくアセスメントです。ストレージ内に何があるか誰も説明できず、棚卸しに数か月を要し、その間に意思決定が止まる——多くの企業で繰り返されてきた光景です。

SOAP では、この最初の壁もエージェントに任せます。既存のメタデータやクエリ履歴などを読み取り専用で収集すれば、コーディングエージェントがテーブル単位の処遇(移行 / アーカイブ / 残置 / 廃棄候補)を判定根拠つきで分類し、フェーズ単位の移行計画書をドラフトします。判断できない項目は「確認事項」として人間に返してくるため、レビューと承認に集中できます。

生成される計画書には、機械可読な移行マニフェストが付属します。つまり、資料のための計画ではなく、そのまま次のフェーズで DDL 等に変換できる、実行可能な計画です。データの棚卸しからドキュメント整備、移行計画の立案まで——これまで数か月を要した工程が、エージェントとの協働では最初のワークショップのアジェンダになります。

SOAP の経済性

このアーキテクチャの経済性は、「運ばない・書き換えない・全部やらない」の 3 点に集約されます。 S3 のデータはゼロコピーで分析し、既存の Parquet 資産はメタデータだけで Iceberg 化し、移行対象はアクセス実態にもとづいて絞り込みます。実際の棚卸しでは、テーブルの相当数が 12 か月以上参照されていない「廃棄候補」であることも珍しくありません。移行の恐怖の大半は「全部運ぶ」という誤解から来ています。

次のステップ

AI の賢さは、モデルの選定ではなく、データに与える意味で決まります。そしてその意味の層は、データを動かす前から作り始めることができます。

最初の一歩は、大きな移行の決断ではありません。読み取り専用の棚卸しと、最初の OKF バンドルから始めてください。

Borderless Lakehouse の全体像は、概要ドキュメントをご確認ください。
Open Knowledge Format は、紹介ブログと仕様をご覧ください。
グラフを AI との対話に使う方法は、グラフとチャットすることで今日から試せます。

SOAP という名前は Semantic and Ontology Agent Platform の頭字語ですが、そこにはもうひとつの意図も込められています。長年の運用で埃をかぶったデータも、意味の層で洗い上げれば AI の一級の資産になる、ということです。

レガシーも、洗えば資産です。

関連リンク・次のステップ

著者・コントリビューター紹介

執筆者:
- Kuma Arakawa: Senior Customer Engineer
  Yu Yamada:Data Analytics Specialist Tech Lead
  Akira Igarashi: Data Analytics Specialist Sales Manager
  Mei Sakurai: Head of Data Analytics Specialist Customer Engineering, Japan
お問い合わせ: Google Cloud のデータ分析・AI エージェント基盤導入に関するご相談は、担当営業またはカスタマーエンジニアまでお気軽にお問い合わせください。

Gemini Enterprise データを Looker のセマンティックレイヤで制御してユーザーの信頼を確保

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

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

AI エージェントを大規模にデプロイする組織にとって、構造化データと非構造化データのギャップは、しばしば重大な問題となります。大規模言語モデル（LLM）は、テキストドキュメント、メール、PDF の解析には優れた力を発揮しますが、企業の未加工データベースには手こずることがあります。一方、標準的な自然言語から SQL への変換（NL2SQL）モデルは、データベーススキーマの相互適合性を推測に頼りがちで、予測不可能なクエリ、一貫性のない指標、AI ハルシネーションを生んでユーザーの信頼を損なう可能性があります。

Gemini Enterprise は、こうした課題を解決する役割を果たします。直感的なチャットインターフェースを通じて Google AI の最先端機能をすべての従業員に提供し、職場における AI 活用の「一元化された窓口」として機能します。しかも、Looker の統制されたセマンティックレイヤが Gemini Enterprise 内における構造化データの信頼できる基盤として機能するようになりました。これにより、Gemini Enterprise のすべてのユーザーは、信頼できるセルフサービスビジネスインテリジェンスを利用できます。このインテグレーションにより、Looker を使用するアナリストと管理者は、Agent-to-Agent（A2A）プロトコルを介して、会話型エージェントを Gemini Enterprise 環境にネイティブに公開できます。つまり、組織は、AI をフル活用するタスクフォースを編成して、リアルタイム分析を完備した安定性と信頼性の高いツールを提供できるようになったのです。しかも、ツールはワークスペースの日常業務同様、自然言語で対応し、活用することができます。Gemini Enterprise で会話型エージェントを簡単に提供できるようになったことで、必要な情報を見つけやすくなり、データドリブンな文化が促進され、誰もが AI を活用しやすくなりました。

構造化データと非構造化データの両方に対応するセマンティック基盤

Looker のセマンティックレイヤと Gemini Enterprise のインテグレーションにより、構造化データベースと非構造化ドキュメントの両方を 1 か所で、平易な自然言語でクエリできるようになりました。数値を把握するために、もうダッシュボードと他のツールを行ったり来たりする必要はありません。客観的かつ具体的な指標を現実世界のコンテキストに即座に結び付け、問題解決や意思決定を迅速に行うことができます。

Looker エージェントを公開し、Gemini Enterprise で使用可能に

AI ハルシネーションを最小限に抑える

一般的な AI chotbot は、非構造化クラウドデータベースを使用した「収益」や「離脱率」の計算を指示されると、どのテーブルを結合し、どのフィルタを適用し、どのタイムスタンプを信頼するか、などの推測が必要になります。このため、同じ質問をしても、そのときどきでまったく異なる回答が得られたりします。

Looker のセマンティックレイヤは、この推測を排除し、重要なコンテキストをコード化されたデータ形式で Gemini Enterprise にフィードすることで、エージェントが確定的で予測可能な回答を提供できるようにします。

code_block: <ListValue: [StructValue([('code', '[ Gemini Enterprise Chat UI ] \r\n │\r\n (A2A Protocol / NLP)\r\n ▼\r\n [ Looker Governed Agent ] ──► Generates Deterministic SQL\r\n │\r\n [ Looker Semantic Layer ] ──► Business-Approved Definitions & Logic\r\n │\r\n ▼\r\n [ Enterprise Data Cloud ] ──► (BigQuery, AlloyDB, Spanner, etc.)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3b18d42d10>)])]>

Gemini Enterprise でユーザーがビジネス KPI をリクエストすると、リクエストは Looker エージェントに直接ルーティングされます。セマンティックレイヤは、バージョン管理されたビジネスロジックに基づいて、正確な決定論的 SQL を生成します。これにより、たとえば、経営幹部が「収益」を尋ねたときには、推測ではなく、きちんと管理された正確な企業指標が得られるようになります。

堅牢なガバナンスとセキュアなアクセス管理

AI を企業のデータウェアハウスに導入する際には、データガバナンスとセキュリティが非常に重要です。組織は、企業情報が厳格な権限を通さずに緩く取り込まれたり、インデックス化されたり、公開されたりするリスクを負うことはできません。

その点、Looker と Gemini Enterprise のインテグレーションは、ゼロリスクのパススルーアーキテクチャに基づいて構築されており、データを処理はしますが、永続ストレージには書き込みません。Gemini Enterprise は、基盤となるデータベースのレコードを取り込んだり、複製したり、保存したりすることはありません。代わりに、Looker とのインテグレーションにより、A2A プロトコルを介して安全かつセキュアに運用し、次の基本原則に沿って処理します。

OAuth 認証: Gemini Enterprise 内で Looker エージェントを使用する際、エンドユーザーはセキュアな 1 回限りの OAuth 同意を提出する必要があります。これにより、Gemini セッションが特定の Looker 認証情報にバインドされます。
強力なガバナンスの適用: アーキテクチャはライブパススルークエリに依存しているため、Looker の既存の行および列単位のアクセス制御が維持されます。
厳格なセキュリティ分離: ユーザーが Looker プラットフォーム内で、たとえば地域別の給与や財務など、機密データの行を表示する権限を持たない場合、Looker エージェントは Gemini 環境でそのデータを能動的に制限します。エージェントを Agent Gallery に公開してアクセスしやすくしても、確立済みのセキュリティ制御がバイパスされることはありません。

技術的な機能性とエンタープライズ対応

A2A プロトコルを介して Gemini Enterprise にネイティブにデプロイできる Looker エージェントの効果は、スマートさの向上だけにとどまりません。セキュリティを犠牲にせずに、インタラクティビティと相互運用性を高める効果もあります。たとえば、このリリースには以下の機能が含まれています。

優れたビジュアルインタラクティビティ: グラフのサポート

「1 枚の写真は千の言葉に値する」と言われますが、ユーザーが Gemini Enterprise 内の Looker エージェントとやり取りすると、プラットフォームはテキストによる説明だけでなく、ネイティブでインタラクティブなデータグラフを提示できます。たとえば、月次販売実績や地域別の分布などの視覚的なトレンド情報を求めると、Looker エージェントはデータベースレスポンスを、プレゼン資料にそのまま使えるような豊かなビジュアルにマッピングして、ユニバーサルチャットボックス内に直接表示します。

注: バージョン 26.12 より前の Looker リリースで Gemini Enterprise に Looker エージェントを公開した場合は、これらの強化されたビジュアリゼーション機能を活用するために、エージェントを 26.12 以降のリリースで更新することをおすすめします。

ファーストパーティおよびサードパーティエージェントとの相互運用性

Gemini Enterprise に公開された Looker エージェントは、他のさまざまなエージェントおよびデータソースのコンテキストを理解することができます。Looker エージェントは、標準的な通信フレームワークを活用して、構造化され、管理されたインサイトを Deep Research エージェントなどの他のファーストパーティ Google Cloud エージェントや外部のサードパーティエージェントとセキュアに共有し、構造化されたワークフローを作成できます。これにより、複雑なマルチエージェントオーケストレーションが可能になり、企業の運用エージェントが Looker エージェントからデータを取得して、別の生産性ワークフローやサプライチェーンワークフローにフィードできます。

Looker ベースのユーザー認証

企業のガバナンスを維持するために、Looker と Gemini Enterprise のインテグレーションでは、ID を中心とした堅牢な認証モデルが実装されています。ユーザーは、1 回限りの OAuth 同意を提出し、基盤となる Looker 認証情報にアクティブな Gemini Enterprise セッションをセキュアにバインドする必要があります。これにより、データベースに送信されるすべての会話型クエリがユーザーレベルで認証され、既存の Looker 権限構造、行レベルのデータアクセスフィルタ、列レベルのマスキングルールが例外なく適用されます。

信頼できるデータをもたらす Gemini Enterprise

エージェント型 AI は未来の仕事を支えます。Gemini Enterprise は、このエージェント型 AI をデジタルタスクフォースとしてグローバルに展開する一元化されたセキュアなアーキテクチャを提供し、企業の開発者、従業員、顧客のための最先端の Google AI でビジネスを力強く後押しします。

Looker と Gemini Enterprise のインテグレーションにより、信頼できるデータ分析がビジネスユーザーに提供されるだけでなく、豊かなインタラクティビティ、視覚的なグラフ、データストーリーテリングが日常のワークスペースに直接追加されます。ビジネスユーザーは、エージェントを活用した、この新しい働き方を取り入れることで、テキストによる回答を得るだけでなく、そのままプレゼン資料に使えるような、運用指標や複雑な分析情報をわかりやすく提示するビジュアリゼーションを得ることができます。

まず、Gemini Enterprise でデータエージェントを公開する方法を学び、エージェントの事前定義されたコンテキストと分析力を組織全体で利用できるようにしましょう。

- プロダクトマネージャー、Tarunima Tripathi

「ノイジーネイバー」問題の解決: シャーディングアーキテクチャがマルチテナントプラットフォームを守る方法

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

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

マルチテナントの SaaS プロバイダ、社内データプラットフォームを管理する大企業、混合ワークロードのデータ処理を扱う企業のいずれであっても、共有インフラストラクチャ環境を管理するということは、「ノイジーネイバー」という共通の脅威に直面することを意味します。単一のテナントで大量のデータバーストやデータベースインスタンスの障害が発生した場合、環境内の他のテナントをダウンさせ、複数の重要なデータパイプラインにわたって大幅なバックログの蓄積やグローバル規模でのサービスレベル契約（SLA）違反を引き起こす可能性があります。

モノリシックアーキテクチャから、シャーディングを取り入れたハブアンドスポークパターンに移行して、プラットフォームの復元力を確保する方法をご紹介します。

課題: モノリシックのボトルネック

従来の一般的なアーキテクチャでは、すべてのテナントとビジネスドメインのデータを 1 つの巨大なストリームで処理します。パイプラインが統合されているため、特定のデータベーステナントインスタンスでパフォーマンスの問題が発生すると、バックプレッシャーが発生し、プラットフォーム上の他のすべてのテナントのパフォーマンスが低下します。

痛手となる影響:

100% の影響範囲: 1 つのデータベース障害で、すべての処理が停止する可能性があります。
非効率的なスケーリング: 多くの場合、「最悪のケース」のテナントに合わせてリソースをスケールする必要があるため、無駄な支出が多くなります。
SLA の不安定性: 1 つの大規模なテナントがシステム全体を遅延させる可能性がある場合、グローバル規模の SLA を維持することはほぼ不可能です。

解決策: シャーディングによるハブアンドスポークアーキテクチャ

この課題を解決するには、処理をルーティング用の「ハブ」と、分離された実行用の「スポーク」に分けます。

1. ハブ: ルーターパイプライン

ハブは、トラフィックコントローラとして機能する軽量の Dataflow ジョブです。統合されたソーストピックから読み取り、テナント ID またはビジネスドメインを解析して、データを分離されたバッファにファンアウトします。これにより、エントリーポイントがシンプルかつ堅牢になります。

2. バッファ: 永続的な分離

ハブとスポークの間に Pub/Sub トピックを導入します。これらは永続的な緩衝器として機能し、低速なダウンストリームシンクが元のソースをバックアップするのを防ぎます。

3. スポーク: 分離された実行

1 本の巨大なパイプラインではなく、複数の小規模な Dataflow インスタンスをデプロイして、ワークロードごとに分類します。

ティア 1（優先度高）: 重要なテナント向けにリソース割り当てを多くした専用パイプライン。
共有ティア: 小規模なテナント向けにパイプラインをグループ化して費用を最適化。
ドメイン固有: コードの複雑さを分離するために、複雑なロジック（異なるビジネスドメインの分離など）に特化したパイプライン。

メリットの比較

機能	モノリシック（従来）	ハブアンドスポーク
フォールトトレランス	1 つの DB の障害ですべてが停止	障害は特定のスポークに限定
影響範囲	100%	5% 未満（1 つのスポークに限定）
リソースのスケーリング	「最悪のケース」を想定してスケーリング	テナントの負荷ごとに独立したスケーリング
メンテナンス	グローバルなアップデートが全体に影響	他のドメインに影響を与えずに 1 つのドメインを更新

実装に関する活用のヒント

このアーキテクチャへの移行は、単に構成図の中でボックスを移動するだけではありません。最大限の安定性を確保するためには、追加で「スポーク」レベルを最適化することが推奨されます。

デッドレターキュー（DLQ）の実装: 単一の SQL 例外によってパイプラインが停止しないようにします。失敗したレコードをストレージ（BigQuery や Google Cloud Storage など）にルーティングして、後で調査します。
厳格な接続プール: データベースには接続制限があります。スレッドセーフなシングルトンパターンを使用し、ワーカーあたりの MaximumPoolSize を低く（1～2 などに）設定して、自動スケーリング中にデータベースを使い果たさないようにします。
非同期 I/O: GroupIntoBatches 変換を使用して書き込みをバッファリングすることで、データベースに起因するレイテンシのトリガーとなることが多い接続オーバーヘッドを削減します。

まとめ

シャーディングのアプローチを採用することで、プラットフォームは「ノイジーネイバー」が近隣の脅威にならないことを保証できます。このアーキテクチャは、厳格な SLA を維持するために必要な分離を実現すると同時に、独立したスケーリングと、より安全なデプロイを可能にします。

シャーディングによるハブアンドスポークアーキテクチャの実装について詳しくは、Dataflow のドキュメントをご覧ください。

- Google Cloud、クラウドデータエンジニア Sri Harshini Donthineni

- Google Cloud、クラウドデータコンサルタント Abdullateef Abdulsalam

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 氏

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

データ分析

Data Agent Kit でエージェントを駆使した問題分析

Data Agent Kit

事象を把握する

結果を確認する

数値を深掘りする

Cloud SQL に調査を広げる

コードを探求する

調査結果を報告する

再現可能なパイプラインを構築する

まとめ

実際に試す

Yahoo が Managed Service for Apache Spark のフレキシブル VM でリソースを最適化している方法

静的構成の運用上のトレードオフ

柔軟なクラスタを構成するためのルール

フレキシブル VM が大規模なワークロードをサポートする 2 つの方法

gcloud の例

API の例

インフラストラクチャ ポリシーの確立

Yahoo の影響と結果

柔軟なインフラストラクチャの戦略上のメリット

復元力のあるデータ パイプラインを構築する

BigQuery の TabFM のご紹介: 予測分析の再定義

表形式の予測のための主要なモデル

BigQuery で TabFM を使ってみる

BigQuery の TabFM の仕組み

ジョブに適したツールを選択

予測 ML が簡単に

BigQuery の新しい ID 列でパイプラインを簡素化

データ パイプラインにとっての主なメリット

ID 列を実装する方法

使ってみる

数週間から数分へ: データ パイプラインの新たなエージェント時代

環境設定

ビジネス上の問題の例: プロアクティブなサプライ チェーン管理

エージェント ワークフロー: プロンプトからパイプラインまで、わずか数分で

Managed Service for Apache Airflow への自動デプロイ

Day 2（2 日目からの）運用: モニタリングとエージェントによるトラブルシューティング

まとめ: 価値創出までの時間を短縮

BigQuery Graph の一般提供を開始: エージェントの時代を支える知識の基盤

BigQuery Graph の新機能

グラフエンジンの高速化と適用範囲の拡大

エージェントの時代への適応

BigQuery Graph を今すぐ使ってみる

Google Cloud 上でのサーバーレス Apache Spark: アーキテクチャの選択と AI によるトラブルシューティング

パート 1: Apache Spark デプロイモデルの選択

パート 2: 高度なパフォーマンス チューニングと DCU コストの最適化

パート 3: Gemini Cloud Assist による運用診断

サーバーレス Apache Spark の活用: メリットと次のステップ

Google Cloud の Lakehouse ランタイム カタログを使用して Apache Hive をモダナイズする

従来の Hive メタストアの課題

解決策: Lakehouse ランタイム カタログ

従来の Hive メタストアからゼロコピーで移行

データ アーキテクチャをモダナイズする準備はできていますか？

BigQuery でエージェント時代の未来に備える: 継続的なコスト パフォーマンスの向上を、手間をかけずに実現

BigQuery の自己学習エンジン: 履歴ベースの最適化（HBO）

ユーザーの操作が不要、安全ガードレールが標準実装

BigQuery 実行エンジンに新しいトリックを教える: 高度なランタイム

データ形式を問わない共通のメリット

流動的なスケーリング: 実際の使用量のみを支払うオートスケーラー

エージェント時代の未来に向けた基盤

BigQuery が TCO に与える総合的な効果: 高速化とコスト パフォーマンスのさらなる向上

まとめ

構造化データと非構造化データのインサイトを統合する BigQuery 検索のイノベーション

パイプラインを簡素化する「自律型エンベディング生成」（一般提供版）

実際の活用例

大規模な自然言語検索を可能にする「AI.SEARCH」（一般提供版）

キーワードとベクトルを統合する「ハイブリッド検索」（公開プレビュー版）

エンドツーエンドの非構造化データ分析プラットフォームの構築

準備ができたら

ゼロコード、低コストのデータの取り込み: BigQuery DTS の新機能

エコシステムの拡大: 新しいコネクタと機能

エンタープライズ データベースとリレーショナル データベース（完全転送と増分転送の両方をサポート）

e コマースとグロース マーケティング

移行コネクタ

主要なコネクタの機能強化

BigQuery Data Transfer Service を選ぶ理由

データ運用の変革を始めましょう

次に構築すべきコネクタは？

Google Dataflow で費用対効果に優れた高スループットな生成 AI ワークフローを構築する

インフラストラクチャポリシーの確立

復元力のあるデータパイプラインを構築する

データパイプラインにとっての主なメリット

数週間から数分へ: データパイプラインの新たなエージェント時代

ビジネス上の問題の例: プロアクティブなサプライチェーン管理

エージェントワークフロー: プロンプトからパイプラインまで、わずか数分で

パート 2: 高度なパフォーマンスチューニングと DCU コストの最適化

Google Cloud の Lakehouse ランタイムカタログを使用して Apache Hive をモダナイズする

解決策: Lakehouse ランタイムカタログ

データアーキテクチャをモダナイズする準備はできていますか？

BigQuery でエージェント時代の未来に備える: 継続的なコストパフォーマンスの向上を、手間をかけずに実現

BigQuery が TCO に与える総合的な効果: 高速化とコストパフォーマンスのさらなる向上

エンタープライズデータベースとリレーショナルデータベース（完全転送と増分転送の両方をサポート）

e コマースとグロースマーケティング

アーキテクチャ: ストリーミングイベントを事前にフィルタする理由

パイプラインフロー

Malachyte がマネージドリアルタイム AI で小売業のコールドスタート問題を解決した方法

Box が Gemini Embeddings 2 でマルチモーダルエンタープライズエージェントを実現

エンベディングの改善によるメリット: ドキュメントコンテンツの次元の拡張

アーキテクチャソリューション: Gemini Multimodal Embeddings 2

マルチモーダルエンタープライズエージェントの 3 つのコアパターン

エージェント型エンタープライズコンテンツ管理の未来

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

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

Gemini Enterprise データを Looker のセマンティックレイヤで制御してユーザーの信頼を確保

優れたビジュアルインタラクティビティ: グラフのサポート

ファーストパーティおよびサードパーティエージェントとの相互運用性

「ノイジーネイバー」問題の解決: シャーディングアーキテクチャがマルチテナントプラットフォームを守る方法

解決策: シャーディングによるハブアンドスポークアーキテクチャ

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

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

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

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