BigQuery

Google Cloud Knowledge Catalog のご紹介

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

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

従来のデータカタログは、技術ユーザー向けの手動インベントリとして作成されており、AI エージェントが必要とする深いコンテキストではなく、テーブル構造に重点が置かれていました。エージェントがビジネス上のセマンティクスやデータ間の関係性を十分に把握できていないと、ハルシネーションや高レイテンシ、古い分析情報の生成につながります。

この問題に対処するため、Google は Dataplex を動的で常時稼働の Knowledge Catalog へと進化させています。企業向けのユニバーサルコンテキストエンジンとして、エージェントが複雑なタスクを高精度で実行できるよう支援するツールです。

Bloomberg Media のようなお客様は、すでに Knowledge Catalog を使用して、信頼できるコンテキストでエージェントを強化しています。

「Knowledge Catalog を通じて Bloomberg Media のエンタープライズメタデータとビジネスコンテキストを統合することで、Data Access AI Agent を無事にリリースできました。この社内ソリューションにより、組織全体の関係者はデータレイクを直感的に探索できるようになり、複雑なビジネス上の問いに対しては、AI が即座にわかりやすく説明します。重要なのは、信頼できる組織内のコンテキストを根拠として AI に提供することで、生成されるあらゆる分析情報の精度と品質に自信を持てるようになることです。」

- Bloomberg Media、CTO、William Anderson 氏

Knowledge Catalog は、次の 3 つの基本的な柱で構成されています。

集約: コンテキストを統合し、定義の不整合を解消
拡充: 継続的に意味を生成し、関係性をマッピング
検索: 高精度の検索でエージェントを支援

集約: データアセット全体でコンテキストを統合

真のコンテキストを構築するには、あらゆる場所に散在する情報を集約する必要があります。Knowledge Catalog は、Google とパートナーのデータプラットフォーム、セマンティックモデル、サードパーティのカタログ全体でネイティブコンテキストを集約し、それらを管理の行き届いた信頼できる情報源に一元化します。

幅広いメタデータの集約 （GA）: 真に包括的なコンテキストエンジンを構築するには、サイロをすべて解消する必要があります。Knowledge Catalog は、BigQuery、AlloyDB、Spanner、Cloud SQL、Firestore（プレビュー版）、Looker（プレビュー版）などの基盤システム全体から技術的メタデータを自動的に収集します。また、Atlan、Collibra、Datahub、Ab Initio、Anomalo などのサードパーティデータベースやパートナーカタログとの統合もサポートしており、レガシーメタデータもエージェントの枠組みに取り込むことができます。
エンタープライズ接続 （プレビュー）: 業務を本当の意味で理解するには、セマンティックコンテキストが企業内の主要システムをすべてカバーしている必要があります。そうしたシステムは、Google Cloud Lakehouse を使用し、コンテキストフェデレーションによって相互接続されます。これにより Knowledge Catalog は、Palantir、Salesforce Data360、SAP、ServiceNow、Workday などのアプリケーション、オペレーティングシステム、AI プラットフォームを迅速かつ詳細に可視化できます。たとえば、SAP のデータプロダクトは自動的に Knowledge Catalog にマッピングされます。
LookML エージェント: ビジネスロジックの定義方法を自動化します。新しい LookML エージェントは、戦略ドキュメントを自律的に読み取り、ビジネスにそのまま活用できるセマンティクスを即座に生成します。これらのセマンティックモデルを Knowledge Catalog に集約することで、コアとなるビジネスロジックを企業全体で連携させ、エージェントがアナリストと同じ定義に基づいて推論を導き出せるようにします。デベロッパーは、LookML セマンティックモデル用の新しい VS Code 拡張機能を利用し、エージェント対応のあらゆる IDE からセマンティックレイヤのライフサイクル全体を扱えます。
BigQuery measures（プレビュー版）: プログラマティックなビジネスロジックを SQL エンジンに直接組み込むことで、データの整合性を再定義します。BigQuery measures により、すべての計算が汎用的に再利用可能になり、かつ数学的に正確であることが保証されます。Knowledge Catalog は最終的なアグリゲータとして機能し、BigQuery measures と LookML を管理の行き届いたセマンティック基盤に一元化します。
データプロダクト（GA）: データプロダクトは、エージェントを支えるデータアセットとコンテキストをパッケージ化し、本番環境での信頼性を高めます。この自己完結型のブロックには、インテント、SLA、ガバナンスの制約が組み込まれており、複雑な AI ユースケースをスケーリングするための基本要素を提供します。

拡充: 継続的な学習を通じて意味を生成する

Knowledge Catalog は継続的にデータを拡充します。手動によるキュレーションに留まらず、構造化スキーマ、クエリログ、BI セマンティックモデルを能動的に分析し、非構造化データからエンティティ間の関係性を抽出します。こうした継続的なデータ拡充機能を、チームが実際に作業する環境に提供します。

スマートストレージおよびオブジェクトコンテキスト API（プレビュー版）: Google Cloud Storage（GCS）にネイティブで組み込まれたスマートストレージは、ファイルがバケットに保存されると、即座かつ自動的にタグ付け、埋め込み、メタデータによる拡充を行います。このインテリジェンス機能を Knowledge Catalog に統合することで、エージェントは非構造化データを即座に発見できるようになります。
高度なマルチモーダルメタデータ抽出（プレビュー）: 複雑な非構造化データの集合に対しては、Knowledge Catalog は Gemini とネイティブで統合されているため、有用なビジネス情報を特定するとともに、非構造化コンテンツから直接エンティティを抽出して、複雑なビジネス関係をマッピングするパイプラインを自動的に構築できます。
コンテキストの自動キュレーション（プレビュー版）: Knowledge Catalog は、データセット、データプロダクト、関係性、検証済みの SQL パターンに対して、ビジネス用語集を含む自然言語の説明を自動生成します。これにより、人間とエージェントの双方が推測に頼ることなくデータを活用できます。こうした隠れた関係性やインテントに基づくパターンを推論することで、データとビジネスの実際の関連性を示す、動的に進化し続けるマップを構築します。
検証済みのクエリとセマンティックガードレール（プレビュー版）: AI の失敗の主な原因の一つは、ハルシネーションによる誤ったロジックや推測に基づく SQL 結合です。これを防ぐために、Knowledge Catalog には検証済みの SQL パターンと事前生成された自然言語の質問が用意されています。

検索: 高精度で安全なデータ取得によるエージェント活用の拡大

膨大なコンテキストレイヤを作成することは重要ですが、エージェント時代では、検索は新しいクエリ経路に進化しています。自律型エージェントは、ユーザーに代わって作業する際に非常に高速に反復処理を行います。エンタープライズ規模での最大の問題は、スピード、関連性、グローバルなリーチ、セキュリティです。

高精度セマンティック検索（GA）: Knowledge Catalog は、Google の数十年にわたるイノベーションを活用したハイブリッド検索スタックを使用します。Google 検索と同じ高度なクエリ書き換え技術と ML 技術を基盤として構築されており、エージェントが必要とする 1 秒未満のレイテンシと的確な関連性を提供します。エージェントがプロンプトを受け取ると、Knowledge Catalog は適切なコンテキストを即座にランク付けし、リアルタイムでエージェントに返します。
アクセス制御対応の検索: エージェント時代には、適切なデータとそのコンテキストを見つけることが重要です。エージェントが間違ったコンテキストを取得すると、ハルシネーションが発生します。信頼性を確保するために、このグローバル検索では、ソースシステムで定義されているメタデータアクセス権限が尊重されます。これにより、エージェントは明示的に閲覧を許可されたアセットのみを取得、操作します。
測定可能なコンテキスト評価: 長期的な精度を確保するために、堅牢な評価フレームワークで検索機能を強化しています。これにより、コンテキスト構築が、当て推量から測定可能なエンジニアリングプロセスへと変わります。そのため、チームはさまざまなコンテキスト構築戦略を定量的に検証して改善を繰り返し、エージェントに提供するコンテキストの関連性と質を継続的に最適化できます。

基盤となるデータプロダクト、高精度の検索、ガードレールを整備することで、信頼性が高い状態で高度な AI をデプロイできます。その代表的な例が、Knowledge Catalog を活用した Gemini Enterprise の Deep Research エージェント（プレビュー版）です。このエージェントは Knowledge Catalog にネイティブで対応しており、ライブのビジネスデータ、社内ドキュメント、ウェブ調査を統合し、非常に複雑な質問にも回答できます。決定論的な精度と詳細な引用を備え、これまで数週間の手作業が必要だったタスクを数分で実行します。

エージェントにビジネスにおける暗黙のルールを推測させるのはやめましょう。コンテキストを一度構築すれば、あとはエージェントに任せることができます。

Knowledge Catalog を今すぐお試しください。

- Chai Pydimukkala、プロダクトリーダー、Google Cloud

- Sam McVeety、テクニカルリーダー、Google Cloud

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エージェンティック時代を支える BigQuery の新機能

Thu, 23 Apr 2026 03:00:00 +0000

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

エージェンティック時代において成功を収めるには、データ戦略の抜本的な変革が不可欠です。それは、人間が処理できる規模から、エージェントファーストのワークロードへと移行することを意味します。また、受動的なインテリジェンスから能動的なアクションへと進化させ、生のデータをエージェントが正確に推論するためのセマンティックな知識へと昇華させなければなりません。

10 年以上にわたり、 BigQuery の継続的なイノベーションは、数万におよぶ組織がスケーラブルなデータと AI の基盤を築き、業界や技術の革新の波を乗り越えるための支援をしてきました。現在、BigQuery は自律型のデータ＆ AI プラットフォームへとさらなる進化を遂げています。 Gemini によるデータ処理量は 30 倍以上に拡大し、非構造化データを処理する AI 関数は 25 倍、さらに Model Context Protocol (MCP) を活用したエージェント構築ツールは 20 倍もの成長を記録しています。

Definity のような先進的な企業は、顧客体験の向上、バックオフィス業務の効率化、そしてデータチームの生産性向上を目指し、データプラットフォームを構築しています。

「当社は Google Cloud 上にデータプラットフォームを構築し、わずか 10 か月ですべての重要な保険データを取り込みました。これは業界平均の約半分という驚異的なスピードです。BigQuery の大規模データを極めて迅速に処理する技術は、実務担当者やエンジニアに高度なツールをもたらし、AI / ML が統合された先進的なプラットフォームを実現しています。その結果、短期間でユーザー数を 2 倍に増やすことができました」 — Definity、チーフテクノロジーオフィサー、Tatjana Lalkovic 氏

本日、 Google Cloud はレイクハウス、組み込み型 AI 処理と推論、エージェンティックな体験の 3 つの軸において、BigQuery の新機能を発表します。これらはすべて、業界をリードする価格パフォーマンスとエンタープライズ対応の信頼性へのコミットメントに基づいています。

オープンかつ境界なきクロスクラウドレイクハウスの実現

企業のデータは多くの場合、アプリケーションや複数のクラウド、オンプレミスに分散しています。初期のレイクハウスソリューションはデータの重複を削減しましたが、エージェンティック時代には、ネイティブにマルチモーダルかつクロスクラウドで、AI に最適化された基盤が求められます。 Google Cloud は、 Apache Iceberg の相互運用性と Google 独自のインフラストラクチャを融合させ、以下の新機能を提供します。

Managed Iceberg tables in Lakehouse（一般提供、旧称 BigLake）: Iceberg のオープン性に、自動テーブル管理、Iceberg パーティショニング、マルチテーブル・トランザクション、CDC（変更データキャプチャ）、高度なベクトル化、履歴ベースの最適化といった BigQuery の高度な機能を融合させます。
Iceberg REST Catalog: BigQuery、Spark、その他 OSS やサードパーティエンジン間において、Iceberg テーブルの読み書きの相互運用性（プレビュー）を実現します。これにより、複雑なエンジンに伴う複雑なトレードオフに悩まされることはありません。
Cross-cloud Lakehouse（プレビュー）: BigQuery の AI と分析機能を、AWS や Azure をはじめとする他のクラウドへ拡張します。Iceberg REST Catalog などのオープンスタンダード、 Cross-Cloud Interconnect による広帯域ネットワーク、透過的なキャッシュ技術を活用することで、他社ネイティブのデータウェアハウスと同等のパフォーマンスと TCO（総保有コスト）を実現。真のクロスクラウド体験を提供します。
カタログフェデレーション（プレビュー）: AWS Glue、Databricks、SAP、Salesforce、Snowflake、Confluent Tableflow（年内公開予定）にわたるデータの探索、分析、ゼロコピー共有を容易にします。
リアルタイムデータレプリケーション：Spanner 、AlloyDB 、Cloud SQL から BigQuery テーブル（一般提供）および Iceberg（プレビュー）へデータを即座に複製可能にすることで、ローデータの取り込みからビジネスアクションまでのサイクルを迅速化します。

SQL または自然言語を使用して、BigQuery と AWS 上の Iceberg テーブルにまたがるデータを分析

レイクハウスに関する最新のイノベーションの詳細はこちらをご参照ください。

エンタープライズエージェントのためのグラフベースの推論

AI が複雑で多段階の運用課題を解決するには、ビジネスロジックがデータプラットフォーム層まで深く浸透している必要があります。このレイヤーでロジックを定義することで、データの取り込みから消費に至るまで、定義の一貫性とガバナンスが担保されます。BigQuery Graph（プレビュー）は、こうしたコンテキストを活性化させる基盤を提供し、データ実務者がエンティティ、リレーションシップ、およびビジネスロジックをデータプラットフォーム内に直接マッピングできるようにします。これにより、 AI エージェントを統制された現実に即した形で定着させ、高度な課題を大規模かつ一貫した精度で解決できるようになります。

AI 推論を強化する新しいグラフ機能を発表します。

BigQuery Graph における指標（メジャー）のネイティブサポート（プレビュー）: 分析指標（メジャー）とデータ間のリレーションシップを、統制された一つのエンティティとして統合できます。これにより、データを「ビジネスマップ」へと変換し、マルチホップな構造的推論を可能にします。エージェントは単なる検索を超えて、あるビジネスイベントが他にどのような波及効果（リップルエフェクト）をもたらすかまでを追跡できるようになります。
BigQuery Conversational Analytics におけるグラフサポート（プレビュー）: 対話型分析エージェントが生のテーブルではなく、確定的なビジネスマップを参照することで、回答精度が飛躍的に向上します。エージェントは指標を用いて正確な KPI を即座に算出すると同時に、複雑な関係性をたどって数値の背景にある理由を明らかにできます。
BigQuery Graph と Looker の統合（プレビュー）: グラフを Looker ビューとして公開することで、BigQuery で定義した指標をデータスタック全体で再利用できます。また、ソース管理と検証機能を備えた Looker を使用して BigQuery Graph を定義することも可能です。この相互運用性により、解約率などの重要指標がダッシュボードと AI エージェントの両方で一致することを保証します。
BigQuery Studio におけるビジュアルモデリング体験（プレビュー）: エージェントのコンテキストを支えるエンティティ、リレーションシップ、ビジネスロジックを直感的に構築および管理できるインターフェースを提供します。

BigQuery Graph を活用した Conversational Analytics Agents による、自然言語でのデータ分析

構造化、非構造化データの価値を引き出すネイティブな AI 処理

データはもはや行と列に限定されません。エージェントが求めているのは、データのコピーや移動を強いることなく、構造化データと非構造化データの双方を大規模に処理できるプラットフォームです。BigQuery AI は、 170 以上の基盤モデルへの組み込みアクセスにより、予測 ML タスク（需要予測、異常検知、レコメンデーションなど）や生成 AI タスク（画像やテキストからのエンティティ抽出、コンテンツ生成、データ拡張など）を容易に実行します。

AI.PARSE_DOCUMENT（プレビュー）: OCR（光学文字認識）、レイアウト解析、チャンク分割を自動化する単一の SQL 関数により、複雑なドキュメント処理ワークフローを簡素化します。
TabularFM モデル（プレビュー）: 大規模な特徴量選択、チューニング、トレーニング、モデル管理を必要とせず、高品質な回帰および分類機能を BigQuery にもたらします。
ObjectRef（一般提供）: SQL および Python を使用して、構造化データとともに非構造化データを処理できます。これにより、ナレッジカタログ上に直接、リッチでマルチモーダルなコンテキストを構築する基盤が整います。
最適化モード（プレビュー）: AI.CLASSIFY や AI.IF などの SQL 優先の AI 共同処理マネージド関数において、タスク固有のモデルをオンザフライでトレーニングし、従来の生成 AI の行単位の処理と比較して、トークン消費量を 230 分の 1 に削減します。
BigQuery ネイティブの Gemma エンベディング（プレビュー）: 標準的な CPU 上で高品質なエンベディングを大規模に生成できます。
自律的なエンベディング生成（一般提供）: 非構造化データのパイプラインをフルマネージド化し、新しいデータが取り込まれる度にベクトルインデックスを自動的に同期します。
BigQuery ハイブリッド検索（プレビュー）: セマンティック検索と全文検索を単一の関数に統合し、 RAG や複雑な探索において極めて高い精度を実現します。
Python UDF（一般提供）: フルマネージドな Python スカラー関数により、データの拡張、変換、クリーニングが可能になります。独自のコードやライブラリを持ち込むことができ、サーバーレスな実行環境によって数百万行規模まで自動スケールします（今後数週間にわたって段階的に展開予定）。
Connected Sheets: BigQuery のスケールを Google スプレッドシート上で利用可能にします。新たに TimesFM モデルによる予測（一般提供）と異常検知（プレビュー）に対応しています。
地理空間分析データセット（プレビュー）: インフラ資産や道路管理のインサイトなどの地理空間データに BigQuery から直接アクセス可能になりました。複雑なデータ加工なしに、エンタープライズデータと組み合わせて深い分析が行えます。

BigQuery における非構造化データへのアクセス、処理および活用

エージェンティックな体験

AI は、定型的で時間のかかるタスクを肩代わりすることで、高度なスキルを持つデータチームがインパクトの大きい戦略的イニシアチブに集中できる環境を整えます。 Google Cloud は、 Google の基盤研究、高性能なモデル、専用ツールを BigQuery に直接統合し、データライフサイクルのあらゆる段階で自動化と支援を提供します。

Conversational Analytics in BigQuery（一般提供）: 自然言語を用いて複雑なデータセットへのクエリが可能になります。安全かつ透明性の高い形でインサイトを得られるだけでなく、予測分析や構造化および非構造化データを横断した推論もサポートします。BigQuery Studio に加え、 Data Studio（プレビュー）、 Gemini Enterprise（プレビュー）、またはカスタムアプリケーション用 API（一般提供）から利用可能です。

Conversational Analytics in BigQuery により、自然言語を用いてデータからインサイトを取得

プロアクティブなエージェンティックワークフロー（プレビュー）: 単なる質問への回答を超えて、指標の変化を検知し、根本原因分析を行って理由を説明し、定期的な調査レポートをメールで直接配信します。

BigQuery におけるプロアクティブなエージェントワークフロー

BigQuery Agent Analytics: ADK（一般提供）および LangGraph（プレビュー）フレームワーク用のプラグインを提供し、エージェントのアクティビティを BigQuery に記録して、トラブルシューティング、最適化、評価に役立てることができます。
BigQuery Studio: リソース探索やトラブルシューティングをサポートするコンテキスト認識型アシスタント（プレビュー）をはじめ、SQL と DataFrames を統合する SQL Cells（一般提供）、ノートブック内で直接ビジュアルを作成する Visualization Cells（一般提供）など、新しい生産性向上のためのツールを追加しました。Files Explorer（一般提供）により、開発者はフォルダ形式でコード資産を整理、共有、管理することが可能になります。さらに、 BigQuery Notebooks における Git 連携とワークフロー（プレビュー）を導入し、データサイエンスのワークフローにおいて GitHub、GitLab、Bitbucket、Azure DevOps を網羅する包括的な SCM カバレッジを提供します。
Data Science Agent（一般提供）: BigQuery ノートブックにおいて、目標を自然言語で入力するだけで、 BigQuery ML 、 DataFrames 、または Spark を使用したデータのロード、クリーニング、視覚化の計画を自動実行します。
Colab Data Apps（プレビュー）: ノートブックでの分析を、共有可能なフルマネージドのインタラクティブ Python アプリケーションに変換します。
BigQuery remote MCP server（一般提供）および BigQuery ADK toolset（一般提供）は、エージェントのための手動によるデータベースコネクタ作成の手間を大幅に軽減します。
Google Cloud Data Agent Kit（プレビュー）: 環境を問わず利用可能な一連のスキル、 Model Context Protocol（MCP）ツール、環境固有の拡張機能、およびネイティブプラグインを統合したスイートを提供します。VS Code、Gemini CLI、Codex、Claude Code など、開発者が普段利用している環境に寄り添うことで、Data Agent Kit は IDE、ノートブック、あるいはターミナルをネイティブなデータ環境へと変貌させます。これにより、使用している環境から広範なデータワークフローのオーケストレーションが可能になり、BigQuery、dbt、Apache Spark、Apache Airflow などの適切なフレームワークを自動的に選択して、本番環境に対応したコードを生成します。

圧倒的なパフォーマンスとスケール

現代の分析ワークロードは予測が難しく、分散化が進んでいます。Google Cloud は、データの増大がコストや運用のオーバーヘッドに直結しないよう、BigQuery のコアエンジンの強化に投資を続けています。

Fluid scaling（一般提供）: コストとパフォーマンスをトレードオフを必要としない、高度なオートスケーリングモデルです。変動の激しいワークロードでも秒単位の課金を実現し、最大 34% のコスト削減を可能にします。
高度なランタイム、小規模クエリ、履歴ベースの最適化（一般提供）: コードやスキーマの変更なしに、ネイティブおよび Iceberg ワークロードを加速させます。BigQuery は、クエリ処理コストを前年比で 40% 削減しつつ、クエリ速度を 35% 向上させました。
新しいワークロード管理機能: 予約グループ（一般提供）、柔軟な動的割り当て（プレビュー）などにより、詳細なコスト配分と価格パフォーマンスの制御を簡素化します。
可観測性の向上（一般提供）: ミッションクリティカルなワークロードに対して柔軟なディザスタリカバリ機能を提供します。エージェントによる可観測性（プレビュー）やセキュリティセンター（プレビュー）により、運用とアクセス制御をさらに簡素化します。

予測困難なワークロードに対応する BigQuery の Fluid scaling

エージェンティック時代において、 BigQuery は単にデータが存在する場所ではありません。データが考え、推論し、行動するための場所です。よりオープンで自律的、そしてパワフルなデータの未来が今ここにあります。

BigQuery へのデータ移行特典を活用して、データと AI ジャーニーを今すぐ始めましょう。皆様のイノベーションの成果を伺えることを楽しみにしています。

BigQuery Graph と Kineviz GraphXR で企業ナレッジの非構造化データを拡張

Wed, 22 Apr 2026 02:20:00 +0000

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

企業データの 80% 以上は、PDF、メール、レポート、規制関連の提出書類など、非構造化形式で存在しています。このようなソースには重要なビジネス情報が含まれていることが多いにもかかわらず、大規模なアクセスや推論は困難です。BigQuery Graph と Kineviz GraphXR を組み合わせることで、意思決定者は単一の合理化されたワークフローを作成して非構造化データを管理し、隠れたビジネスインサイトをはるかに簡単に発見できるようになります。BigQuery がグラフ構造の保持と構築を担い、Kineviz GraphXR がアナリストによる関係性の視覚的検証、分析情報の根拠の追跡、そして対話的な質問への回答を可能にします。

検索拡張生成（RAG）とベクトル検索は、非構造化データを扱うための業界標準のアプローチとなりました。しかし、トレンド分析、エンティティ間の比較、マルチホップ推論、説明可能な意思決定支援においては、グラフが RAG を補完し、コンテキストと関係性をマッピングする役割を果たします。Google の「エビデンスファースト」のナレッジグラフアプローチでは、元のエビデンスのニュアンスを維持し、グラフ内のあらゆる要素のトレーサビリティを確保することを優先しているため、分析結果の検証可能性と信頼性が高まります。この投稿では、BigQuery AI 関数、BigQuery Graph、Kineviz GraphXR を使用して、複雑な ETL パイプライン、データの重複、個別のグラフデータベースなしで、Fortune 500 企業の SEC 提出書類に関するビジネス上の質問に回答する例を紹介します。

BigQuery で、断片化されたデータを統合

従来の非構造化分析パイプラインは、複雑で散漫になりがちでした。通常は、未加工ファイルのオブジェクトストレージ、カスタム解析サービス、個別の AI 抽出レイヤ、スタンドアロンのグラフデータベース、そして分析用の BI ツールなど、複数のステップを要します。この複雑な設定は、データの重複、同期のオーバーヘッド、複数の潜在的な障害点の導入を伴うため、維持が困難になる可能性があります。

BigQuery はこのプロセスを合理化します。未加工のドキュメントは Google Cloud Storage に保存され、テキスト抽出、Gemini を活用した推論、グラフ作成はすべて同じプラットフォーム内で直接行われます。これにより、システム間のデータ移動、複雑なサービスオーケストレーション、同期されていないデータコピーの蓄積が不要になります。

緊密なインテグレーションにより、パイプラインはシンプルで保守しやすく、専用のインフラストラクチャがなくてもデータの完全な来歴を確認できます。

BigQuery パイプライン: 非構造化データから構造化データへ

BigQuery パイプラインを使用して、2020 年から 2024 年までの Fortune 500 企業の SEC 10-K 提出書類を調査しました。各提出書類は、約 100 ページに及ぶ詳細な内容です。

各 Company（企業）が Competitors（競合他社）（COMPETES_WITH）、Risks（リスク）（FACES_RISK）、Markets（市場）（ENTERING / EXITING / EXPANDING）に接続するスキーマを設計し、次の 4 つのステップでプロセスを進めました。

1. 取り込んで解析する。SEC EDGAR から 10-K 提出書類を取得し、階層構造を維持しながら SGML（Standard Generalized Markdown Language）を Markdown に変換して、Cloud Storage 経由で未加工のテキストを BigQuery に読み込みます。

2. 重要なシグナルセクションに注目する。100 ページに及ぶ提出書類全体を処理するのではなく、市場の動向、リスク、競合他社に関連するセクション（具体的には、事業、リスク要因、経営陣の議論と分析のセクション）にのみ抽出を集中させます。BigQuery の各行には、年度、企業名、CIK、セクション ID、原本の提出書類への直接 URL など、重要なメタデータが保持されています。

3. Gemini を使用して抽出する。Gemini 3 Pro で AI.GENERATE_TEXT() を利用して、各セクションを処理し、構造化された JSON を返します。この出力には、競合他社、リスク、市場の動向、機会に関する詳細が記載され、すべての要素は最初の提出書類のエビデンステキストによってグラウンディングされています。このプロセスは、外部のオーケストレーションやデータ移動を必要とせず、BigQuery 内で完結します。

4. グラフを宣言する。 構造化された JSON データは、ノード用とエッジ用の個別のテーブルに分割されます。これらのテーブルは、以下に示すように、1 つのデータ定義言語（DDL）ステートメントを使用して完全に走査可能なグラフにマッピングされ、結合を必要とせずにグラフクエリを可能にします。

code_block: <ListValue: [StructValue([('code', 'CREATE PROPERTY GRAPH sec_filings.SecGraph\r\n NODE TABLES (\r\n nodes_company, nodes_competitor, nodes_risk, nodes_market, nodes_opportunity\r\n )\r\n EDGE TABLES (\r\n edges_competes SOURCE nodes_company DESTINATION nodes_competitor LABEL COMPETES_WITH,\r\n edges_faces_risk SOURCE nodes_company DESTINATION nodes_risk LABEL FACES_RISK,\r\n edges_entering SOURCE nodes_company DESTINATION nodes_market LABEL ENTERING\r\n -- plus EXITING, EXPANDING, PURSUING\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d5a6c2ee0>)])]>

このプロセスにより、87,000 個のエンティティと 20,000 件以上の競合他社に関する言及が抽出されました。解決と正規化の後、これらの言及は約 8,100 の個別の競合他社に統合され、非構造化データの SEC 提出書類が、競争環境を示すナレッジグラフに変換されました。

Kineviz GraphXR で隠れた分析情報を引き出す

Kineviz の GraphXR は BigQuery Graph に直接接続し、アナリストがデータをインタラクティブに探索、分析できる環境を提供します。アナリストは、クエリを記述することなく、ローコードワークフローを通じて関係を視覚的にナビゲートし、サブグラフをドリルダウンできます。これは、戦略、コンプライアンス、調査の各チームがデータに直接アクセスして、分析を独自に改善できることを意味します。

GraphXR の AI を活用したワークフローにより、ユーザーは「Apple の競合他社との比較を時系列で表示して」などの自然言語を使用して分析タスクを定義し、ライブグラフビューにリンクされたダッシュボードを生成できます。グラフビューが変更されると、ダッシュボードのグラフが動的に更新されます。たとえば、SEC 提出書類から抽出された構造化データポイントを見ると、Apple を競合他社として挙げた企業の数は、時間の経過とともに 14 社前後で比較的安定していることがわかります。このパターンは個々の提出書類を調査するだけでは明らかになりません。

ダッシュボード: Apple について言及した企業（時系列）

AI を活用したビジュアル分析エージェントは、これらの評価の精度とニュアンスを向上させます。たとえば、GraphXR の「trace neighbor」機能を使用して、Google を競合他社として挙げている企業を特定した後、エージェントの分析により、業界をまたがる複雑な関係が明らかになります。その代表的な例が、エネルギー公益事業会社の AES Corp. です。同社は、競合と協調が入り混じった関係を示す文脈で登場しており、これはクラウドや AI インフラストラクチャの導入に向けた、より広範な市場の変化を浮き彫りにしています。

グラフ構造とノードプロパティの両方について、エージェントの理由を添えて競合分析を行う

私たちのワークフローは、監査可能性に重点を置いています。グラフ内のすべてのノードは、元の SEC 提出書類内のソースに直接リンクされています。アナリストは分析情報をその起源までたどって、コンテキスト内で調査結果を検証できます。たとえば、下の画像では、リスクエンティティを選択すると、そのリスクが特定されたドキュメントの関連する場所に読者を誘導する URL リンクが提供されます。

リスク分析。ソースドキュメント内の抽出された情報の正確な場所への直接リンクをクリックできます。

メリット

BigQuery Graph と Kineviz GraphXR を組み合わせることで、組織は次のことが可能になります。

シンプルさ: システムとコピーの削減 - パイプラインはフルマネージドの統一プラットフォームで実行され、BigQuery に保存されたデータは、データの移動や重複なしに GraphXR で探索、分析されます。
スケーラビリティ: BigQuery は、専用のグラフインフラストラクチャなしで、数百万のドキュメントと数十億の抽出されたファクトを処理します。
説明可能性: すべての分析情報が情報源のエビデンスに遡ることができ、検証はワンクリックで完了します。
柔軟性: 新しい質問やエンティティタイプによって抽出モデルを再構築する必要はなく、スキーマを拡張するだけで済みます。

企業ナレッジの大半は閉じ込められたままです。BigQuery AI 関数、BigQuery Graph、Kineviz の BI ツールを組み合わせることで、グラフベースの推論、エビデンスファーストの分析、インタラクティブな探索を、単一の合理化されたパイプラインに変え、非構造化データに閉じ込められたインテリジェンスを引き出すエンドツーエンドのソリューションが提供されます。

始める

BigQuery Graph の詳細についてはこちらを、ご利用を開始する場合はこちらをご覧ください。Kineviz GraphXR は Google Cloud Marketplace で入手できます。Fortune 500 企業のチュートリアルは、GitHub ノートブックで確認するか、こちらの動画をご覧ください。

BigQuery Graph のご紹介: データに潜む関係性を明らかに

Tue, 21 Apr 2026 02:00:00 +0000

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

このたび、BigQuery Graph のプレビュー版の提供を開始しました。BigQuery Graph は、データエンジニア、データアナリスト、データサイエンティスト、AI デベロッパーが、大規模な関係性をこれまでにない形でモデル化、分析、可視化できるようにする、使いやすく高いスケーラビリティを備えたグラフ分析ソリューションです。

データが変化し、増え続ける中で、人、場所、商品といったさまざまなエンティティが互いにどのようにつながっているのかを把握することはますます重要になっています。結局のところ、エンティティどうしのつながりがわかってこそ、データはより大きな意味を持ちます。従来の SQL では、「友だちの友だちの友だち」を見つけるだけでも、複数の JOIN を入れ子にした処理が必要になり、記述も読解も難しくなりがちです。しかも、規模が大きくなるにつれて、パフォーマンスは急激に低下します。たとえば、嵐によるサプライチェーンの混乱がどこまで影響するのかという「影響範囲」を特定するには、複数ホップにまたがる探索、すなわち本格的なグラフ分析が必要です。こうした課題により適切に対応するため、データはしばしば、私たちを取り巻く現実世界をグラフとして表現する形でモデル化されます。こうした表現は、従来のリレーショナルデータ構造よりも、複雑で見えにくい関係性を見つけ出すのに適しています。

業界を問わず企業が直面するグラフ導入の課題

グラフ技術は、不正検知、レコメンデーションエンジン、サプライチェーン管理、ナレッジグラフアプリケーションなど、さまざまな業界で幅広く活用されています。しかし、グラフを導入するにあたっては、いくつかの大きな課題があります。

データサイロと運用負荷の増大: グラフデータをスタンドアロンのグラフデータベースに保存して管理する必要があるため、データサイロやデータの不整合、追加コストが生じるだけでなく、運用負荷も増大します。
グラフに関する専門知識の不足: グラフ技術を導入するには、新しい言語や考え方、場合によっては新しいデータベースも習得しなければなりません。その一方で、これまで組織が積み上げてきた SQL の知識やスキルを十分に生かしにくいという課題もあります。
パフォーマンスとスケーラビリティへの懸念: 多くのスタンドアロングラフデータベースは、少数のノードを起点としたグラフ走査には適していますが、ビジネスの成長に伴って数十億規模のエンティティまで拡張するのは難しい場合があります。

BigQuery Graph は、次の機能によって、こうした課題の多くに対応します。

組み込みのグラフクエリ機能: より直感的なグラフクエリ言語（GQL）により、最新の ISO GQL 標準に基づいて、異なるデータセット間のパターンを見つけたり、関係をたどったりできます。
リレーショナルデータモデルとグラフデータモデルの統合: グラフデータモデルとリレーショナルデータモデルが緊密に統合されているため、データの重複や移動を行うことなく、単一の信頼できるデータソースをもとに、最適な方法でデータをモデル化できます。さらに、グラフクエリと SQL は完全に相互運用できるため、既存の SQL スキルを生かしながら、グラフクエリの高い表現力も活用できます。
構造化データと非構造化データをまたぐグラフ分析: BigQuery Graph では、豊富な AI 関数に加え、ベクトル検索や全文検索も利用できます。これにより、グラフ上で意味ベースの検索やキーワード検索を行うことができ、構造化データと非構造化データの間を橋渡しできます。
グラフの可視化: BigQuery Studio ノートブックや Jupyter Notebook を使って、データどうしのつながりを直感的なグラフ形式で簡単に探索、調査、説明できます。
業界最高水準の使いやすさ、パフォーマンス、スケーラビリティ: BigQuery Graph は、BigQuery のサーバーレスでスケーラブルかつ費用対効果に優れた分散分析エンジンを基盤として構築されており、数十億規模のノードやエッジにも対応できます。
Spanner Graph とのインテグレーション: これにより、リアルタイムのグラフニーズには Spanner Graph、バッチのグラフニーズには BigQuery Graph という形で、両方をカバーする統一的なグラフスキーマとグラフクエリ言語を利用できます。さらに、連携クエリを使えば、データを移動することなく、Spanner の最新データと BigQuery の履歴データを組み合わせた仮想グラフを構築することもできます。
グラフとの対話: まもなく会話型分析エージェントを使用することで、グラフに直接話しかけるような操作が可能になります（続報をお待ちください）。

BigQuery Graph の主なユースケース

BigQuery Graph は、インテリジェントなアプリケーションを構築するうえで、業界を問わず幅広い可能性をもたらします。

金融詐欺行為の検出: ユーザー、アカウント、トランザクションの間の複雑な関係を分析して、資金洗浄やエンティティ間の異常な接続など、リレーショナルデータベースでは検出が困難な疑わしいパターンや異常を特定します。
Customer 360: 顧客との関係、嗜好、購入履歴を追跡します。各お客様を包括的に把握し、パーソナライズされたおすすめ情報、ターゲットを絞ったマーケティングキャンペーン、カスタマーサービスの利用体験の向上を実現します。
ソーシャルネットワーク: ユーザーのアクティビティとインタラクションをキャプチャし、友だちのおすすめ情報やコンテンツの検出のためにグラフパターンマッチングを使用します。
製造とサプライチェーン管理: グラフパターンを使用して、グラフにパーツ、サプライヤー、注文、在庫状況、欠陥をモデル化し、欠品分析、費用のロールアップ、コンプライアンスチェックを効率的に実施します。
ヘルスケア: 患者の関係性、病状、診断、治療に関する情報を捉え、患者の類似性分析や治療計画の立案に役立てます。
輸送の最適化: グラフで場所、乗り継ぎ、距離、費用をモデル化し、グラフクエリを使用して最適なルートを検索します。

実際の BigQuery Graph の活用事例

さまざまな業界のお客様が、BigQuery Graph を活用して現実のビジネス課題を解決しています。ここでは、その活用例をいくつかご紹介します。

BioCorteX: 創薬

「疾患を理解するということは、単にデータを増やすことではなく、そのデータの中にある関係性を理解することです。BigQuery Graph の経路検索を大規模に活用し、7 ホップを超える深さまで到達できるようになったことで、私たちはついにヒト代謝マップをこれまで以上に見渡せるようになりました。この規模だからこそ、試行錯誤を超えて、複雑な疾患を治療するために働きかけるべき正確な生物学的レバーを特定できます。もはや推測しているのではありません。計算機の速度で生命を再現しようとしているのです。」- BioCorteX、CEO / 共同創業者、Nik Sharma 氏

Curve: 不正検知

「BigQuery Graph を導入したことで、これまでの制約の多い SQL ベースのアプローチから脱却し、不正検知ネットワーク分析のための、よりスケーラブルなソリューションへ移行することができました。これにより、一見無関係に見えるアカウントや取引の間に潜むつながりを明らかにし、高度な不正ネットワークを検出できるようになりました。従来のリレーショナルクエリからグラフベースの分析へ移行したことで、約 910 万ポンドの削減という、測定可能な事業インパクトも得られました。この転換は、不正検知の精度を高めただけでなく、運用負荷を大きく増やすことなく、エコシステムを保護するためのスケーラブルな基盤も提供してくれました。」- Curve、データおよび ML 担当 VP、Francis Darby 氏

Virgin Media O2: 不正検知

「Virgin Media O2 では、ますます巧妙化する不正ネットワークの先を行くために、防御策を絶えず進化させています。すでに堅牢な不正アラートシステムに、新たな強力なレイヤを追加しました。BigQuery Graph を使うことで、アカウント、デバイス、アクティビティの間にある隠れた関係性を可視化する複雑な 4 ホップクエリを実行できるようになりました。この可視性の向上によって、不審な住所のネットワークを特定できるようになりました。これは単に不正を検知するだけではありません。既知のリスクネットワークへの新たな接続を被害が発生する前に検知する早期警戒システムとしても機能します。」- Virgin Media O2、データアプリケーション担当ディレクター、Jonathan Ford 氏

BigQuery Graph の使い方

BigQuery Graph は単なる新機能ではありません。データに対する新しい考え方をもたらし、より大きな問いを立て、より深いインサイトを引き出し、最も難しい課題の解決を可能にします。

次の 3 つの簡単なステップで利用を開始できます。

ステップ 1: 単一コピーのデータをもとに、DDL を使って関係テーブル上にグラフスキーマを作成します。

リレーショナルテーブルを「Account」「Person」「Loan」の各ノードに対応付け、それらの関係を「Transfers」「Owns」「Repays」の各エッジとして定義することで、金融グラフを作成します。

code_block: <ListValue: [StructValue([('code', 'CREATE PROPERTY GRAPH graph_db.FinGraph\r\nNODE TABLES (\r\n graph_db.Account KEY(id),\r\n graph_db.Person KEY(id),\r\n graph_db.Loan KEY(id)\r\n) \r\nEDGE TABLES (\r\n graph_db.Transfers \r\n KEY (id, to_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Account (id)\r\n DESTINATION KEY (to_id) REFERENCES Account (id), \r\n graph_db.Owns\r\n KEY (id, account_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Person (id)\r\n DESTINATION KEY (account_id) REFERENCES Account(id),\r\n graph_db.Repays\r\n KEY (id, loan_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Person (id)\r\n DESTINATION KEY (loan_id) REFERENCES Loan(id)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d582b0d60>)])]>

ステップ 2: 直感的な SQL / GQL を使ってデータ間の関係をたどり、隠れたつながりを見つけます。

Jacob が所有する口座と、その口座から返済しているローンを見つけます。

code_block: <ListValue: [StructValue([('code', 'GRAPH graph_db.FinGraph\r\nMATCH\r\n (person:Person {name: "Jacob"}) \r\n -[own:Owns]->(account:Account)\r\n -[repay:Repays]->(loan:Loan)\r\nRETURN\r\n account.id AS account_id,\r\n loan.id AS loan_id'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d582b0670>)])]>

ベクトル検索とグラフトラバーサルを組み合わせて、詐欺師に類似した口座と、その口座に関する送金アクティビティを 1～6 ホップの範囲で見つけます。

code_block: <ListValue: [StructValue([('code', "DECLARE similar_account_to_fraudster DEFAULT ((\r\n SELECT array_agg(base.id)\r\n FROM VECTOR_SEARCH(TABLE graph_db.Account, 'embedding',\r\n (SELECT * FROM graph_db.Account WHERE id=102), 'embedding', \r\n top_k => 6)\r\n));\r\nGRAPH graph_db.FinGraph\r\nMATCH\r\n (person:Person)-[own:Owns]->\r\n (account:Account)-[transfer:Transfers]->{1,6}\r\n (to_account:Account)\r\nWHERE to_account.id IN \r\n UNNEST(similar_account_to_fraudster)\r\nRETURN\r\n person.id AS person_id,\r\n account.id AS src_account,\r\n to_account.id AS to_account"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d582b0520>)])]>

ステップ 3: BigQuery Studio ノートブックでグラフの結果を可視化し、異なるデータどうしのつながりを、より直感的に把握します。

より専門的なグラフ可視化ツールをお探しの場合は、BigQuery Graph は G.V()、Graphistry、Kineviz、Linkurious などの業界をリードするパートナーと統合されています。これらのツールを使えば、Google Cloud コンソールの外でも、BigQuery Graph のクエリ結果を可視化できます。

準備ができたら

データ分析の未来は、つながりの理解にあります。BigQuery Graph を使えば、そのつながりを解き明かし、企業のナレッジに根ざした実用的なインサイトへと変えることができます。今すぐ使い始めて、相互に結び付いたデータの力を引き出しましょう。

BigQuery のドキュメントを見る: 概要とクイックスタートガイドをご覧ください。
チュートリアルを試す: チュートリアルを通じて、BigQuery Graph を実際に体験できます。
フィードバックを共有する: コミュニティに参加し、bq-graph-preview-support@google.com で質問できます。
関連ブログ記事:

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

- BigQuery、プロダクトマネジメント担当ディレクター、Vinay Balasubramaniam

Gemini アシスタントの強化により、BigQuery Studio がこれまで以上に便利に

Tue, 24 Mar 2026 03:00:00 +0000

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

現代のデータチームは、単なるデータ分析よりも、分析のオーバーヘッドの管理に多くの時間を費やしています。これには、必要なデータの特定、スケジュールの構成、停滞しているジョブの原因調査などのタスクが含まれます。こうした運用上の課題に加えて、自社のデータに精通し、現在の作業のコンテキストを認識しているアシスタントも必要としています。

このたび利用可能になった BigQuery Studio の最新の Gemini 搭載アシスタントには、データ環境との関わり方を一変させる新機能が備わっており、エージェントをコードアシスタントから、コンテキストを完全に認識する分析パートナーへと変貌させます。

今すぐ利用できる主な改善点の詳細は以下のとおりです。

1. コンテキストアウェアな相互運用性

クエリエディタのタブとチャットインターフェースの相互運用性が高まりました。アシスタントは、アクティブなクエリタブや開いているクエリタブを認識できます。

つまり、コードスニペットをコピーして貼り付けたり、コンテキストをゼロから説明したりする必要がなくなりました。アクティブなクエリタブに基づいて質問したり、最適化をリクエストしたりするだけで、アシスタントはどのコードとリソースを参照しているかをインテリジェントに理解します。

高度な SQL 生成: 標準的なクエリだけでなく、AI オペレーターと連携クエリを利用する高度な SQL を生成できるようになりました。これにより、シンプルな自然言語プロンプトで、より複雑な分析ユースケースを実現できます。

図 1.1 - アシスタントはコンテキストを認識して、アクティブなタブと、「クエリ」が何を参照しているかを把握

2. インテリジェントなリソース検出

組織が成長するにつれて、データはさまざまなプロジェクト、データセット、テーブルに分散されます。必要な特定のリソースを見つけるのは、干し草の山から針を探すようなものです。

BigQuery Studio のアシスタントに追加されたリソース検出機能により、Dataplex Universal Catalog の検索を利用して、単一または複数のプロジェクトにわたってリソースを検索できます。データセット、テーブル、モデル、保存済みクエリ、スケジュール設定されたクエリなど、幅広い BigQuery リソースを検索できるようになりました。これにより、以下のことが可能です。

自然な言葉での質問: 正確なテーブル ID を覚えておく必要はもうありません。「新規ユーザーの年齢や場所などのユーザー属性はどこで確認できる？」や「e コマースという名前のデータセットはある？」など、インテントベースのプロンプトを使用して検索できます。
メタデータの深堀り: アシスタントが適切なデータセットを見つけた後も、会話は終わりません。コードを書き始める前に、フォローアップの質問をしてデータの構造を理解できます。

ビジュアルスキーマ: アシスタントは、テーブルスキーマとデータセットの詳細を、チャットウィンドウ内のユーザーフレンドリーな UI に直接表示します。
クエリの最適化:「このテーブルはパーティション分割されている？」や「このテーブルのクラスタリングは何？」と質問することで、最初から効率的なクエリを作成できます。
オーナーの特定: アクセス権をリクエストする必要がある場合は、「このデータセットのオーナーは誰？」と質問します。

図 1.2 - アシスタントはプロジェクトをまたいで検索し、ユーザーのプロンプトに関連するデータセットを一覧表示できる

さらに、この機能は組織のセキュリティポリシーに従い、実際に閲覧権限があるリソースのメタデータのみを取得します。

3. ジョブの即時分析とトラブルシューティング

普段は数秒で終わるクエリがハングしたり、予想よりも費用がかさんだりするのは、誰もが経験することです。従来は、目的の分析情報を得るために、情報スキーマやログを掘り下げる必要がありました。

新しいジョブ分析機能により、アシスタントは個人とプロジェクトの両方のジョブ履歴を検索して分析情報を提供できるようになりました。

長時間実行されるクエリのデバッグ: ジョブが停止している理由を推測する代わりに、ジョブ ID をコピーして「このジョブ（[ジョブ ID]）に時間がかかっているのはなぜ？」と質問するだけで済みます。エージェントはジョブのステータスを分析し、スロットの競合、大規模な行スキャン、データ量の多さなど、遅延を説明する主要な統計情報を返します。
根本原因の分析: スケジュールされたジョブが失敗した場合は、「このスケジュールされたジョブ（[ジョブ ID]）が失敗したのはなぜ？」と質問して、根本原因を分析します。また、問題の解決方法に関する推奨事項も提供されます。
費用管理:「過去 2 日間で最も費用のかかったクエリを 3 つ教えて」と質問して、リソースの使用状況を監査します。エージェントは、この情報を取得するための情報スキーマをクエリするのに必要な正しい SQL を返します。

図 1.3 - アシスタントはジョブを分析して最適化を提案できる

Gemini を活用したチャット内のこれらの高度な機能により、BigQuery Studio アシスタントは、データライフサイクル全体をサポートする、コンテキストを認識するエージェントパートナーへと進化しています。リソースの検出の簡素化、SQL ワークフローの自動化、トラブルシューティングの合理化により、運用管理ではなく、価値の高い分析情報に集中できます。

アシスタントの機能の全容と利用方法については、ドキュメントページをご覧ください。

- Google Cloud、プロダクトマネージャー、Blessing Bamidur

TVer: 日本最大級の動画配信プラットフォームを支える広告基盤を Google Cloud で内製化

Tue, 10 Mar 2026 03:00:00 +0000

民放公式テレビ配信サービス「TVer」は、2025 年に10 周年を迎え、月間再生 6.5 億回、累計 9,000 万 DL 超の巨大プラットフォームへ成長しました。同社はこの成長を支えるべく広告サーバーの内製化を決断。GKE や Bigtable を活用し、1日あたり億単位のリクエストを低遅延で処理する新基盤を構築しました。株式会社 TVer（以下、TVer）大野祐輔氏と髙品純大氏に、内製化の舞台裏と Google Cloud 選定理由を伺いました。

利用しているサービス:
GKE Standard, Bigtable, Memorystore for Redis Cluster, BigQuery, Cloud Logging など

利用しているサービス:
Google Cloud Consulting (PSO)

事業成長を加速させるため、ビジネスの心臓部である広告サーバーの内製化を決断

TVer の広告事業は、サービスの利用者数増加に伴い、非常に大きな規模へと拡大しています。これまで広告配信は外部の配信プラットフォームを利用してきましたが、さらなる機能開発のスピードアップと、配信技術に関する知見を社内に蓄積するため、独自の広告サーバーを構築するフェーズに移行しました。内製化を決断した理由について広告プロダクト本部長の大野氏は、こう説明します。

「TVer にとって広告配信システムは、まさにビジネスの心臓部とも言える重要な事業基盤です。これを内製化することで、新しい広告フォーマット、新機能への挑戦やデリバリー速度の改善といった一連の作業を、従来よりも高速に回せると考えました」

今回のプロジェクトにおける最優先事項は、ビジネスクリティカルなシステムに相応しい「高い可用性」「低レイテンシなパフォーマンス」「スケーラビリティ」の 3 点でした。1 日に数億件という膨大な広告リクエストを遅滞なく処理し、トラフィックが急増しても事業成長を阻害しない強固なインフラが求められたのです。

TVer が Google Cloud を選んだ最大の理由について、システム開発を担当しているプロダクト開発部の髙品氏は、「データの取り回しの良さとコスト効率」が最も重要だったと説明します。

「内製化以前から、広告ログの分析・集計基盤は BigQuery で構築していました。もし広告配信基盤を他のクラウドに構築した場合、毎日発生する億単位の広告ログをクラウド間で転送する必要があり、膨大なアウトバウンドコストが発生します。また、事業価値の高いデータを転送時のトラブルで失うリスクも避けたいと考えました。BigQuery という強力なデータ基盤と同じ場所に配信サーバーを置くことが、コストとリスクの両面で最適だったのです。

また、開発言語として Go を採用したいという現場のニーズと、Google Cloud との親和性の高さも、エンジニアチームにとって大きな後押しとなりました。」

GKE と、Memorystore、Bigtable の適材適所な併用。技術的難題を突破した PSO の支援

構築された新システムは、GKE Standard をコンピューティング基盤とし、データベースには要件に応じて Memorystore for Redis Cluster（以下 MRC）と Bigtable を使い分ける構成を採用しました。

髙品氏は、データベースの選定理由について次のように解説します。

「広告配信 API に求められるミリ秒単位のレイテンシを実現するため、リレーショナルデータベースではなく NoSQL を選択しました。データの整合性が重要で、超高速なレスポンスが必要なものは MRC、ストレージの容量とコスト効率を重視するものは Bigtable と、戦略的に併用しています。GKE Standard を採用したのも、秒間数十万リクエストが集中するリアルタイム配信に耐えうるキャパシティを事前に確保できる柔軟性を評価したからです。」

この複雑なアーキテクチャの実装と、本番環境の広告配信を止めずに新基盤へ移行するという難易度の高いミッションを支えたのが、Google Cloud のプロフェッショナルサービス（PSO）でした。PSO の役割の重要性を大野氏はこう振り返ります。

「PSO の支援がなければ、予定通りのローンチは不可能だったでしょう。インフラの設定にとどまらず、アプリケーションのアルゴリズムやデータ構造にまで深く踏み込んだレビューをいただいたことが、厳しい負荷試験をクリアする決定打となりました。コードレベルの改善案を迅速に提示いただけるなど、その専門性の高さとスピード感に非常に感謝しています。」

安定と革新を両立した配信基盤を武器に、さらなる視聴体験の向上を目指す

新サーバーへの移行によって、TVer の広告事業は「自分たちでコントロールできる」自由を手に入れました。現在は、システムの信頼性やパフォーマンスを損なうことがないように細心の注意を払って機能をリリースしつつも、守りに徹するだけではなく、 Google Cloud のアップデートを積極的に検証しています。

「最新世代マシンへの刷新に加え、Bigtable の継続的マテリアライズドビューによる集計効率化、さらには Memorystore for Valkey への移行など、最新技術を積極的に取り入れ、より強固な配信基盤を目指していきたいと考えています。」と髙品氏は今後の展望を明かします。

最後に大野氏は、このプロジェクトを振り返り、次のように締めくくりました。

「今回のプロジェクトを通じて、Google のサービスを支える信頼性とスケーラビリティを備えた技術を組織の資産にできたことは大きな収穫です。パブリッククラウドの選択肢が増え、相対化できるようになったことで、今後の大規模プロダクト開発に活かせる自信がつきました。TVer 広告は、これからもテクノロジーの力で、ユーザーに素晴らしい視聴体験を提供し続けていきます。そしてこのような最新でエキサイティングな業務を一緒に取り組める仲間も大募集中です。」

株式会社TVer
2006 年に広告代理店および在京民放キー局の共同出資により、株式会社プレゼントキャストとして設立。2015 年に民放公式テレビ配信サービス「TVer（ティーバー）」を開始し、場所や時間に縛られない「見逃し配信」という新たな視聴習慣を国内に定着させた。2020 年の社名変更を経て、現在は在京・在阪の民放 10 社および広告代理店が参画する国内最大級の映像配信プラットフォームへと成長を遂げている。サービス開始 10 周年を迎える 2025 年には、累計アプリダウンロード数 9,000 万、月間動画再生数 6.5 億回を突破。現在は「テレビを開放して、もっとワクワクする未来を　TVerと新しい世界を、一緒に。」をミッションに掲げ、リアルタイム配信やコネクテッド TV 対応を強化し、放送と通信を融合させた次世代のテレビ体験の創出を目指している。

インタビュイー（写真左から）
・広告プロダクト本部本部長大野祐輔氏
・広告プロダクト本部プロダクト開発部髙品純大氏

BigQuery の自律型エンべディング生成で AI ワークフローを簡素化

Thu, 05 Mar 2026 01:00:00 +0000

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

生成 AI や検索拡張生成（RAG）の世界において、エンべディングは、マシンや AI エージェントがデータのセマンティックな意味を理解できるようにするための「秘訣」です。BigQuery がデータを AI につなげる自律型プラットフォームの能力を拡張する中で、エンべディングによって価値の高いマルチモーダルユースケースが実現します。しかし、多くのデータエンジニアにとって、エンベディングの管理は頭痛の種です。従来、ユーザーはソースコンテンツの更新、エンベディングの生成、保存の伝播のために、エンベディング生成パイプラインを自身で設定する必要がありました。

このたび、BigQuery ユーザーの AI ワークロードを支援するために、自律型エンベディング生成機能を発表しました。この機能により、BigQuery ではソース列に基づいてテーブルのエンベディング列を自動的に維持できます。手動パイプラインの必要性や同期の問題もなくなり、AI 対応のデータを簡単に活用できるようになります。

エンベディングの管理（従来の方法）

自律型の生成ではない従来の方法では、ベクトル検索データベースを更新するプロセスは通常、以下のような流れでした。

ソーステーブルの新しい行を検出する。
AI.EMBED などの関数を使用してエンベディングを生成する。
レート制限と再試行を処理する。
新しいベクトルで宛先テーブルを更新する。
エンベディング生成の進行状況をモニタリングする。

データが頻繁に変更される場合、これらのベクトルを同期し続けることは、ユーザーや管理者にとって大きな負担になる場合があります。このような背景を踏まえ、以下の機能によって BigQuery を強化することを検討しました。

1. ユーザーがデータを直接操作できるようにする

ユーザーの検索エクスペリエンスを簡素化し、AI.SEARCH(TABLE mydataset.products, 'product_description', "A really fun toy") のような簡単な操作を、エンべディングを理解したり操作したりすることなく実行できるようする。

2. 自動同期

BigQuery がユーザーに代わってエンベディングの生成を管理し、生成されたエンベディングをソースデータと同期させる。

3. ベクトルインデックスとの緊密な統合

BigQuery の VECTOR_SEARCH は多くのユーザーに利用されているため、マネージドエンベディングがこの機能に統合されることを保証する。

解決策: 自律的に生成されるエンベディング列

エンべディングをテーブルの管理対象の一部として扱うことで、この問題を解決しました。これにより、使い慣れた SQL 構文を使用して、BigQuery が管理する自律型エンべディング列を定義できるようになりました。

code_block: <ListValue: [StructValue([('code', "CREATE TABLE mydataset.products (\r\n name STRING,\r\n description STRING,\r\n description_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>\r\n GENERATED ALWAYS AS (AI.EMBED(\r\n description,\r\n connection_id => 'us.test_connection',\r\n endpoint => 'text-embedding-005'\r\n ))\r\n STORED OPTIONS( asynchronous = TRUE )\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44faa3a0>)])]>

詳細については、こちらのガイドをご覧ください。

ベクトルインデックスやベクトル検索との統合

さらに、BigQuery のベクトルインデックスやベクトル検索も、生成されたエンベディング列と統合されます。ソースデータ列に関連付けられたベクトルインデックスを直接作成でき、エンべディングを手動で管理することなくデータをクエリできます。BigQuery は、ベーステーブルのモデルを自動的に適用して、クエリと互換性のあるエンべディングを生成します。

AI.SEARCH の導入

また、データ中心の検索エクスペリエンスを簡単に開始できるように、新たに AI.SEARCH 関数をリリースしました。AI.SEARCH は、ベーステーブルから生成されたエンベディング列に関連付けられたエンベディングモデルを自動的に使用するため、AI.SEARCH や VECTOR_SEARCH を使用する際にエンベディング構成を操作する必要がありません。

code_block: <ListValue: [StructValue([('code', 'SELECT base.name, base.description, distance\r\nFROM AI.SEARCH(TABLE mydataset.products, \'description\', "A really fun toy");'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44faaa60>)])]>

シンプルな管理

自律型エンベディング生成は、現在プレビュー版を提供しています。データ分析パイプラインの一部として今すぐご利用いただけます。また、プロセスをエンドツーエンドで簡単に管理できるようにする以下のような機能も導入しています。

エンベディングステータスメタデータ: テーブル内の null 以外のエンベディングの割合をクエリすることで、エンベディング生成の進行状況を追跡できます。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n COUNTIF(description_embedding IS NOT NULL\r\n AND description_embedding.status = '') * 100.0 / COUNT(*) AS percent\r\nFROM mydataset.products;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44faa8b0>)])]>

ベクトルインデックスの作成はいつでも開始できますが、インデックスモデルの生成は、パフォーマンス向上が見込まれる規模に達した場合にのみ実行されます。

Vertex AI モデルへのネイティブアクセス: BigQuery 接続に Vertex AI ユーザーのロールを付与することで、エンベディング生成が、ユーザーの代わりにリモートの最先端の Vertex AI エンベディングモデルと安全に「通信」できるようになります。
ネイティブエラーモニタリング: エンべディング生成パイプラインのいずれかのステップが失敗した場合、INFORMATION_SCHEMA ジョブビュー（例）で最近のバックグラウンドジョブのステータスを確認できます。このビューには、問題を解決するのに役立つ詳細なエラー情報が表示されます。

今後の予定

自律型エンベディング生成の取り組みは、あらゆる種類のデータの処理や有効化に対応した AI ネイティブのマルチモーダルデータ基盤への移行を表すものです。データプラットフォーム内でエンベディング生成を自動化して結合することで、実装作業に費やすデベロッパーの負担を減らし、インテリジェントなアプリケーション構築に注力できるよう支援します。また、現在も以下のような機能の開発に取り組んでいます。

データ定義ライブラリ（DDL）とデータ制御言語（DCL）による接続作成の簡素化
生成されたエンベディング列を既存のテーブルに追加する機能（ALTER TABLE ADD COLUMN DDL 経由）
生成されたエンべディング列を管理する API と UI のサポート
ObjectRef を使用したマルチモーダルデータの直接サポート

準備はよろしいですか？BigQuery の公式ドキュメントをご参照ください。マネージドエンべディングテーブルのセットアップを今すぐ始めましょう。

- ソフトウェアエンジニア、Andong Li

- ソフトウェアエンジニア、Brian Seung

イオンフィナンシャルサービス: BigQuery を軸に全社横断的なデータ分析基盤を構築し、緻密な 1 to 1 マーケティングを強化

Tue, 03 Mar 2026 02:00:00 +0000

グループ全体で 18,086 店舗（2025 年 2 月時点）を誇り、総従業員数は 60 万人を超えるイオングループ。その金融事業を担い、クレジットカード「イオンカード」やスマホ決済「AEON Pay」、電子マネー「WAON」など、決済を中心に多様な金融サービスを展開するイオンフィナンシャルサービス株式会社（以下、イオンフィナンシャルサービス）にとって、高精度かつ高速な全社横断型データマネジメント基盤は不可欠の存在となっています。その構築プロジェクトにおいて、Google Cloud が基盤として選ばれた理由、現在の手応え、今後の展望までをプロジェクトの最高責任者に伺いました。

利用しているサービス:
BigQuery など

利用しているソリューション:
インフラストラクチャのモダナイゼーション

緻密な 1 to 1 マーケティングに不可欠な、全社横断型データマネジメント基盤

総合スーパー「イオン」「ダイエー」や、小型スーパー「まいばすけっと」など国内だけでなく、アジアを中心に 14 か国で小売事業を展開しているイオングループ。80 年代からは金融事業にも進出しており、現在はイオンフィナンシャルサービスを中心に、決済サービスや銀行、保険、リースなど幅広くサービスを提供しています。イオンフィナンシャルサービスの常務執行役員システム担当兼システム本部長兼サイバーセキュリティ担当の光石博文氏は、大規模小売事業者であるイオングループが金融事業部門を持つ意義を、次のように説明します。

「買い物をする店舗と決済のスキームが同一グループ内にあることは、どちらか片方しか持たない事業者と比べて圧倒的なアドバンテージとなります。小売事業が持つ詳細な購入履歴・商品情報と、金融事業が持つお客さま情報を紐付けることで、お客さま一人ひとりに最適化されたアプローチが可能になるためです。具体的にはお客さまが購入した商品に合わせた電子クーポンを発行したり、キャンペーンの告知を行ったりといった 1 to 1 のマーケティング施策を精度高く、クイックに実行できます。」

イオングループは、この決済と小売が融合した環境を「イオン生活圏」と呼んでいます。そのメリットを最大限に引き出すためにはグループ全体のデータを素早く収集し、リアルタイムなマーケティング分析を可能にする DMS（データマネジメントシステム：決済に関連するデータを分析する基盤）が欠かせません。しかし光石氏によれば、以前のイオングループはその点で大きな課題を抱えていました。

「とりわけネックになっていたのが、情報収集・処理速度の遅さです。イオングループには全社をまたぐ DMS が存在せず、それぞれの企業がデータ基盤をオンプレミスで構築していました。他社のデータを利用したい場合、データが同一プラットフォーム上に存在しないため、データの取り寄せが 2 日遅れになることもあり、お客さまの現在の嗜好や行動に合う提案が難しくなっていたのです。また、精度の低いデータではセグメント分けも大まかにならざるを得ず、緻密な 1 to 1 マーケティングを展開できませんでした。しかし我々は、例えばキュウリを買ったお客さまには、ランドセルや自転車のクーポンではなく、やはりマヨネーズのクーポンをお店にいる間にお届けしたい。売上の面だけでなく、顧客のファン化、リピーター化を促進するという意味でも、早期の解決が求められていました。」

膨大な量のデータを高速かつ柔軟に扱える BigQuery をシステム構築の柱に

これらの問題を解決すべく、光石氏は全社横断で使える DMS の構築を決意。2022 年にイオンフィナンシャルサービスが主体となって、プロジェクトをスタートさせました。同プロジェクトでは、DMS 構築の目的として、顧客一人ひとりに寄り添ったサービス提供・提案を可能にすること、情報を素早く収集しリアルタイム性を確保すること、そして、グループ全体で情報を共有し、連携したマーケティング分析を可能にすることの 3 点を掲げました。しかし、これらの目標を会社ごとに分断されたオンプレミス環境で実現するのは実質不可能です。そこで選択されたのがクラウドへの移行でした。

「クラウドへの移行は、プロジェクトのかなり早い段階で決断しました。そのうえで我々の目的に最適なプラットフォームを見つけ出すため、およそ数か月かけて技術検証やコンペティションを行い、2022 年冬に BigQuery を中核とするデータベースを構築する方針を固めました。BigQuery を選んだのは、イオングループの膨大な量のデータを高速かつ柔軟に扱えたからです。Google Cloud が提供する分析基盤なだけあり、イオングループの月数十億に及ぶ商品単位の購買データや、数千万人の会員データをノンストレスで処理できる点においては、素晴らしいパフォーマンスを見せてくれました。また、イオングループでも Google Cloud を利用している会社が多く、グループ内の親和性を期待できる点も決め手になりました。」

なお、DMS の開発にあたっては従来のアプローチを一新。開発手法をウォーターフォールからアジャイルに変更して、サービスや機能を段階的にリリースしていけるようにしたほか、これまで外部に委託することの多かった開発を内製化することにも挑戦しています。

「このプロジェクトを通じ、社内の開発力を高めていきたいという狙いがありました。とは言え、まだ社内メンバーだけでは人数もスキルも足りませんから、外部のパートナー企業にも入ってもらいつつ、皆が対等で意見交換できるワンチーム体制で開発に取り組んでいます。開発体制の変更にはリスクもありましたが、社内開発力アップのためには避けて通れません。Google Cloud に提供してもらった教育カリキュラムを利用するなどしてチームの質を高めていきました。」

プロジェクト推進においては、実際に DMS を利用する現場メンバーも巻き込みました。どういうデータがほしいか、どういう形に出力したいかを開発メンバーと現場メンバーでコミュニケーションをとることで、DMS に対する思い入れも深まり、実用性も大幅に向上するという副次効果も生まれました。

DMS の開発作業は 2023 年 12 月に最初の機能を提供した後、2024 年 7 月から本格的に加速。2025 年 5 月には通常業務に必要な機能をひと通り提供することができました。現在は、既存システムからの完全移行を目指し、まだ移行しきれていない細かな機能の追加が進められています。

組織と働き方を変える真の DX、さらには決済サービスのグローバル化も推進

まだ移行段階とはいえ、すでにイオングループの各現場で活用が始まっているという DMS。光石氏はその成果を次のように説明します。

「これまで 2 日はかかっていたデータ収集・分析が、わずか数分程度で完了するようになり、迅速な顧客アピールができる基盤が整ったと現場から喜びの声が上がっているところです。また、運用コストも従来システムと比べて、劇的に安く抑えることができています。とはいえ、本格的な運用成果が出てくるのはこれから。2026 年度には念願だったリアルタイムの 1 to 1 マーケティングキャンペーンの発信を本格化させ、お客さまそれぞれに、本当に必要な情報をお届けできるようにしていく予定です。」

さらに光石氏は、このプロジェクトを通じ、データ分析システムの刷新だけでなく、組織と働き方を変える真の DX を目指しているとも説明。以前は外注していたダッシュボードを現場の利用者たちが自ら作り始めるなど、すでに新たな動きが始まっていると語ります。

「この取り組みの面白いところは部署内で閉じていないこと。現場から経営陣までが同じダッシュボードを見て、同じ情報を共有する新しい試みをしている点を高く評価しています。こうした挑戦が現場から生まれていることも今回のプロジェクトの大きな成果と言えるでしょう。今後が非常に楽しみですし、できればこういった挑戦を一部のメンバーだけでなく、全従業員ができるようにしていきたいと考えています。」

もちろん今後、DMS の活用範囲はさらに拡大していきます。例えば、BigQuery に蓄積されたビッグデータから顧客の嗜好や行動を把握するために、AI をこれまで以上に活用していくことなどに挑戦していく予定です。

「あとは海外展開です。イオンの決済サービスは今後、より積極的にグローバル化を推進していきますので、Google Cloud にはぜひともアジアに力を入れてほしい。BigQuery を前提とした仕組みを作ったので、それをあらゆる国・地域で快適に使えるようにしてもらいたいですね。Google Cloud の技術力は断トツだと高く評価していますので、今後も世界中で一緒にビジネスを拡大していければと思います。」

イオンフィナンシャルサービス株式会社
イオングループの核となる小売事業と連携し、イオンカードや AEON Pay、電子マネーの WAON などの決済サービスを提供しているほか、銀行、保険、リースなどの事業も展開。従業員数は金融グループ全体で 15,547 人（国内 4,644 人、国際 10,903 人）（2025 年 2 月末時点）。

インタビュイー
常務執行役員
システム担当兼システム本部長兼サイバーセキュリティ担当
光石博文氏

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

新しい BigQuery グローバルクエリで、単一の SQL ステートメントを使用して分散データを探索

Mon, 02 Mar 2026 02:00:00 +0000

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

グローバル経済では、データは世界中で生成、保存されます。多国籍企業の場合、顧客データは米国本社近くに保存され、トランザクションログはヨーロッパとアジアに分割されるため、パフォーマンス、規制遵守、データ主権のニーズを満たすことができます。しかし、これには課題があります。データが大陸をまたいで分散している場合、どのようにしてビジネスを単一の統合ビューで把握できるのでしょうか。

これまで、分析の前にデータをコピーして一元化するために、複雑で時間と費用のかかる ETL パイプラインが必要でした。これは、遅延や複雑さを招き、チームがタイムリーにアドホック分析を行うことを妨げていました。

このたび、BigQuery のグローバルクエリによってこの状況が変わります。グローバルクエリを使用すると、単一の標準 SQL クエリで、異なる地理的ロケーションに保存されたデータをクエリでき、ETL は不要です。グローバルクエリはプレビュー版でご利用いただけます。

グローバルクエリとは

グローバルクエリは、異なる地域に分散したデータセット間の障壁を取り除きます。多国籍企業である当社は、BigQuery コンソールから直接、1 つのクエリで全データを結合、統合、分析できるようになりました。

バックグラウンドでは、クエリの実行に必要なデータ移動が BigQuery によって自動的に処理されるため、マルチロケーション分析でシームレスなゼロ ETL エクスペリエンスが実現します。BigQuery は、異なるリージョンで実行する必要があるクエリのさまざまな部分を特定し、それに応じて実行します。次に、これらの部分クエリの結果は、メインクエリの実行時に選択されたロケーションに転送されます（転送サイズを最小限に抑えるための最適化が行われます）。最後に、すべての部分が結合され、クエリ全体の結果が返されます。

BigQuery ユーザーである EssilorLuxottica は、グローバルクエリを早期に導入し、この新機能で大きな成果を上げています。

「EssilorLuxottica では、データセキュリティとコンプライアンスを最重要事項としています。そのため、情報は常に生成元のリージョンに保存されます。BigQuery のグローバルクエリを使用すると、この分散データをシームレスに統合できます。これにより、コンプライアンスを損なうことなく、リージョンをまたいだ集計分析を行えます。セキュリティを確保しながら、分析情報に基づいた意思決定を行うための優れた方法です。」 - EssilorLuxottica、カスタマーデータプラットフォームマネージャー Rubens Ballabio 氏

同時に、リージョン間でデータを転送すると追加費用が発生し、さまざまな規制により、個人情報（PII）データを元のロケーションから移動することが禁止されることもよくあります。こうした理由から、地理的境界を越えたデータ転送には堅牢なガバナンスが必要です。グローバルクエリは、セキュリティとユーザー管理を最優先に設計されています。その仕組みは次のとおりです。

明示的なオプトインが必要: 誤ったデータ転送や費用の発生を防ぐため、グローバルクエリ機能はデフォルトで無効になっています。使用するには、管理者がプロジェクトのグローバルクエリを明示的に有効にする必要があります。また、グローバルクエリを実行するには、ユーザーまたはサービスアカウントごとに特別な権限が必要です。
場所を制御: グローバルクエリが実行されるロケーションを指定することにより、データが処理される場所を制御し、データ所在地とコンプライアンスの要件を遵守できます。
ガバナンスコントロールを尊重: グローバルクエリは、VPC Service Controls を含む既存のセキュリティポスチャーを尊重するため、確立されたポリシーに違反するような方法でデータが移動することはありません。

グローバルクエリの活用

実用的な例として、1 つのクエリで生成されたグローバル販売の統合レポートを見てみましょう。以前は、これにはデータエンジニアリングプロジェクトが必要でした。現在では、権限のあるアナリストであれば、1 回のクエリで数秒以内に回答を得ることができます。

code_block: <ListValue: [StructValue([('code', "-- Set the location where the final query will be executed, can also be set in the Console.\r\nSET @@location = 'US';\r\n\r\n-- Combine transactions from both European and Asian datasets\r\nWITH transactions AS (\r\n SELECT customer_id, transaction_amount FROM `eu_transactions.sales_2024`\r\n UNION ALL\r\n SELECT customer_id, transaction_amount FROM `asia_transactions.sales_2024`\r\n)\r\n\r\nSELECT\r\n c.customer_name,\r\n SUM(t.transaction_amount) AS total_sales\r\nFROM\r\n hq_customers.customer_list AS c\r\n LEFT JOIN transactions AS t\r\n ON c.id = t.customer_id\r\nGROUP BY\r\n c.customer_name\r\nORDER BY\r\n total_sales DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d58ed2580>)])]>

ご覧のとおり、これはすべて標準 SQL です。ヨーロッパとアジアのデータセットに保存されているすべてのトランザクションを取得し、米国で保持されている顧客データと結合します。これまでと異なるのは、BigQuery が数千キロ離れたデータセット間でこの処理を行うようになったことです。これにより、アーキテクチャが大幅に簡素化され、分析情報を取得するまでの時間が短縮されます。

今すぐグローバルクエリを始めましょう

グローバルクエリを使用すると、分散データ全体にわたって新しい分析情報を引き出し、チームが真のオンデマンドグローバル分析を利用できるようになります。

この機能を有効にして使用する方法の詳細については、公式ドキュメントをご覧ください。Google はこの機能の強化を続けており、一般提供に向けて皆様からのフィードバックをお待ちしています。

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

- ソフトウェアエンジニア Oleh Khoma

ユーフォリア: Gemini で AI マルチエージェントを構築し、最先端のスポーツ科学の知見とデータを、すべての人々の健康づくりに活用

Wed, 25 Feb 2026 02:00:00 +0000

株式会社ユーフォリア（以下、ユーフォリア）は、スポーツテックのリーディングカンパニーとしてプロ・アマや競技種別を問わず、国内外の数多くのアスリートを支援してきました。そんな同社は Google Cloud と Gemini を活用し、長年蓄積してきたデータとスポーツ科学の知見を、一般社会の健康づくりに役立てるプロジェクトを推進しています。この意欲的な試みを主導するキーパーソン 3 名にお話を伺いました。

利用しているサービス:
Gemini, BigQuery, Looker Studio など

利用しているソリューション:
生成 AI

トップスポーツの分野で得られたノウハウを、いかに還元していくか

「すべての人の可能性が生きる未来へ」というビジョンの下、ユーフォリアは 2008 年に設立。創業 5 年目の 2012 年から、ラグビー日本代表の強化プロジェクトをデータ分析の分野で精力的にサポートするなど、スポーツテックの分野に本格的に進出しています。このノウハウを反映した「ONE TAP SPORTS」は、選手の身体能力やコンディション、トレーニング状況などを一元管理できるシステムとして、国内外のスポーツ界で高い評価を得てきました。しかし、共同創業者で代表取締役社長の橋口寛氏は、より大きな目標を目指してきたと振り返ります。

「創業時、共同創業者の宮田（誠氏）と考えたのは『人やモノが本来持っているポテンシャルが発揮されていない現状を変えていきたい』ということでした。その一環としてスポーツの分野に関わるようになりましたが、トップスポーツは、宇宙開発などと同様に『イノベーションの苗床』としての側面も持っています。極限の環境で磨かれた最先端の技術やノウハウが、やがて汎用化されて広く普及し、社会全体を変えていくのです。私たちにとっても、トップスポーツの分野で獲得したノウハウを、いかに多くの人にスケーラブルに還元していくかが、究極のテーマになってきました。」

この目標を達成すべく、ユーフォリアは 2017 年に「ONE TAP SPORTS」の分析項目に「睡眠」を追加。スタンフォード大学で、睡眠・生体リズム研究所所長を務める西野精治氏もアドバイザーに起用します。さらに 2023 年 8 月には、国立スポーツ科学センターの研究員として、生体リズムと睡眠を専門分野に、多くの五輪アスリートの国際競技力の向上に携わった安藤加里菜氏を、リサーチャーとして迎えました。安藤氏は、睡眠の大切さとユーフォリアに参画した理由を次のように説明します。

「正しく睡眠を取るのは、誰でも無料でできる健康管理の手段です。また、生体リズムや睡眠の分野は、2017 年に『時計遺伝子』の研究がノーベル生理学・医学賞を受賞した頃から注目されてきました。しかし日本は、OECD が 2021 年に実施した調査では、調査対象となった 33 か国のなかで最も睡眠時間が短いとされるなど、睡眠不足による健康被害や経済損失が深刻な社会課題となってきました。トップスポーツの分野では、私たちのような専門家が個別にカウンセリングや指導を行ってきました。しかし、抱えられるクライアントの数には限界がありますので、テクノロジーの力を借りて、このような状況を変えたいと思っていました。」

BigQuery と Gemini の導入で実現した、ビジネスモデルの進化

安藤氏が入社した 2 か月後には、AI や量子コンピュータの開発に携わってきた田中孝氏も入社し、R&Dセンター長に就任します。田中氏がまず取り組んだのは、Google Cloud と BigQuery を導入し「ONE TAP SPORTS」で蓄積されてきた膨大なデータを活用できる基盤を構築することでした。

「『ONE TAP SPORTS』は他社製のクラウドを使用していたのですが、データ構造がアプリケーション内で閉じていたため、多角的に活用するのが困難でした。しかし各種デバイスから得られる客観データや、アスリートの主観データなどを BigQuery で統合し、Looker Studio で可視化すれば、ユーザーにとっても 10 年近く蓄積したデータの活用度が一気に上がります。」

さらに翌年には Gemini が導入され、睡眠をアドバイスする AI エージェントの開発がスタートします。橋口氏と田中氏にとっては、これも必然的な決断でした。

「BigQuery の導入により、弊社のビジネスモデルは『ONE TAP SPORTS』の販売から、より付加価値の高いデータやダッシュボードの提供へと変化しました。Gemini の導入はその延長線上にあります。AI を活用すれば、物理的なキャパを超えてより多くの人に、より低価格に高品質なサービスを提供できるはずだという考えは、以前からずっとありました。」（橋口氏）

「Gemini は、Google Cloud 環境にあるデータウェアハウスとシームレスに連携でき、マルチクラウドにも対応しています。コスト、性能、将来的な拡張性や進化のスピードを考えても、ほぼ一択だったと言えます。特に初期段階では、Google Cloud のエンジニアと何度もディスカッションして、最適なアーキテクチャやツールの組み合わせを固めてから AI エージェントを開発しましたので、大きな問題や手戻りは発生しませんでした。」（田中氏）

ユーフォリアの AI システムは、先進的なアーキテクチャで構成されています。田中氏によれば、最大の特徴は睡眠を軸に、栄養エージェント、トレーニングエージェントなど、何人もの「専門家」が連携してユーザーを支援する「マルチエージェントシステム」を採用している点にあります。

「人間の体は複雑で、睡眠の悩みひとつをとっても、原因は食事、運動、メンタルなど多岐にわたります。そこで、単一の AI ですべてを処理するのではなく、各分野の専門知識を持つ複数の AI エージェントに、分析とフィードバックの役割を分けることにしました。それらを束ねるオーケストレーター（指揮者）役のエージェントも設け、総合的かつ具体的なアドバイスを導き出すようにしています。」

一方、負荷計算などを行う際には、従来型の数理最適化モデルや同社が長年蓄積してきたデータを用いた計算結果に基づき、Gemini が文章を生成するコンポジット構造を採用しています。これはハルシネーションを回避しつつ、回答の精度を最大限に高める工夫ですが、プロンプトのチューニングでは、安藤氏の知見もフルに活用されました。

「最初はアルバイトの方に指示をするような要領で入力していたのですが、出力される結果はイメージとどこか違っていました。それは私たち人間が無意識のうちに多くの判断をしており、指示書に落とし込めていないからなのです。生成 AI はユーザーに気を使い、データがない状況でも『良い結果ですね』と回答してしまいがちになりますので、この傾向を修正することも必要でした。さらには詳細な分析と読みやすさを両立させるために、文字数の最適なバランスを見つける、シフトワーカーの方に向けて、土日のない勤務体系や分眠（複数回に分けて眠ること）を踏まえたアドバイスができるようにするなど、様々な試行錯誤を重ねました。今後は、海外出張や海外旅行の『行き先と日程を考慮した』最適な過ごし方の提案などに応用することも考えています。」

AI エージェントの活用がもたらす、社会全体のエンパワーメント

AI エージェントは社内テストを完了。四国電力株式会社などの顧客企業との実証実験が始まっています。利用者からは「データに基づいた具体的な改善案が提示されるのでわかりやすい」「行動変容につながりやすい」「AI のアドバイスを実践したことで中途覚醒が減り、睡眠の質が明らかに向上した」などの声が寄せられているとのことです。安藤氏によれば、運用面での定量的な成果も得られ始めています。

「これまではクライアントにアポイントメントを取った後、データの見方など基本的な説明をするのに多くの時間を割いていました。その部分を AI が代行することで、かなり効率化が進んでいます。一人のカウンセラーがアドバイスできるキャパシティも、30 人から 100 人に増やす計画を進めていますし、生成 AI の活用が進めば、1,000 人のクライアントをサポートすることも夢ではありません。将来的には、1 万人規模の企業にも対応できるレベルを目指したいと思っています。」

ユーフォリアでは、企業向けのサービスとして「ONE TAP SPORTS for Biz」を開発し、昼夜を問わず働くシフトワーカーやドライバーなど「産業アスリート」と呼ばれる人々の支援も行ってきました。今後は睡眠だけでなく、食事、運動、メンタルヘルスなど、あらゆる領域で AI エージェントを開発し、互いに連動させることによって、より包括的なサービスを展開していく予定です。橋口氏は、この新たな AI システムを「QUARIA AI」（商標登録 / 特許出願中）と名付けています。そこには、クオリア＝人間らしい感性を大切にしながら、社会的な使命を全うしていきたいという情熱が込められていました。

「QUARIA AI には弊社が培ってきたノウハウが反映されますので、部活動の指導者不足の解消や、地域コミュニティの健康増進、企業の生産性向上など、社会課題の解決に幅広く貢献できると思います。ただし我々が目指しているのは、各分野のエキスパートの方々を代替することではありません。むしろ『エンパワー（元気づける）』することです。新たなソリューションを多くの人に届け、社会全体を変えられるインパクトを持たせるには、最新のテクノロジーが不可欠。Google Cloud とともに、ビジョンの実現に邁進していきたいと考えています。」

株式会社ユーフォリア
2008 年設立。「人とスポーツの出合いを幸福にする。」をミッションに掲げるスポーツテック企業。スポーツ選手のコンディション管理・ケガ予防のためのデータマネジメントシステム「ONE TAP SPORTS」、スポーツスクール・クラブ活動のための運営管理アプリ「Sgrum」（スグラム）、各種団体のためのグループコミュニケーションサービス「らくらく連絡網＋（プラス）」などを開発・提供している。現在はスポーツで培った知見を活かし、企業向けの「ONE TAP SPORTS for Biz」も展開。スポーツ科学と AI の融合により、社会課題の解決に取り組んでいる。

インタビュイー（写真左から）
・R&Dセンター長　田中孝氏
・代表取締役社長　橋口寛氏
・ウェルネスチーム　安藤加里菜氏

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

BigQuery の会話型分析のご紹介

Thu, 05 Feb 2026 03:00:00 +0000

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

企業はすばやく行動し、情報に基づいた意思決定を行いたいと考えていますが、昨今の組織ではデータが爆発的に増加しているため、ナレッジチームが作業に忙殺され、ビジネスユーザーは必要なデータ分析情報を得るために長い順番待ちをすることがよくあります。AI エージェントは、この関係を根本的に変え、ユーザーがデータから行動へとより迅速に移行できるようになります。

Google はこのたび、BigQuery の会話型分析（プレビュー版）を発表いたします。この新しいサービスにより、ユーザーは自然言語を使用してデータを分析できるようになり、長らく当たり前に存在していた知識の壁や時間の無駄を解消できます。Looker における会話型分析の一般提供に続き、このインテグレーションにより、高度な AI 搭載の推論エンジンが BigQuery Studio に直接組み込まれます。

データプロフェッショナル向けのデータ分析情報を会話形式で提供

BigQuery の会話型分析は、単なる chatbot ではありません。最新の Gemini モデルを活用して、特定のビジネスコンテキストに基づいた回答を BigQuery の安全でスケーラブルな環境で直接生成、実行、可視化するインテリジェントエージェントです。

BigQuery の会話型分析を使用すると、技術チームとビジネスチームは、既存のデータとメタデータを活用して、インテリジェントエージェントをソース側で構築、デプロイし、迅速なイノベーションを実現できます。コンテキストとビジネスを認識するエージェントをデータが存在する場所に作成できるようになったため、すべてのユーザーが信頼できるアナリストの指導を受けながら、回答を順番待ちしたり SQL を学んだりすることなく、スマートな分析情報を得ることができます。

図 1 - BigQuery の会話型分析

質問から信頼できる回答の取得まで数秒

BigQuery の会話型分析は、単純なデータツールとは異なり、ビジネスメタデータと本番環境のロジックを使用して、ユーザーとそのデータ間の信頼を構築します。

ユーザーが質問すると、エージェントは多段階のワークフローを使用して、すべての回答が正確かつコンテキストに関連していることを保証します。このような AI を活用した分析情報により、ユーザーは要約された回答、元データの結果、可視化を通じて包括的な分析を得ることができます。加えて、フォローアップの質問を行って、調査をさらに進めることができます。

図 2 - BigQuery の会話型分析

BigQuery の会話型分析の特徴は次のとおりです。

現実に基づくグラウンディング: エージェントは、BigQuery のスキーマ、メタデータ、カスタム指示を活用することで、SQL の生成が一般的な仮定ではなく内部ロジックに基づいて行われるようにします。
検証済みのクエリと信頼できるロジック: 本番環境の指標との一貫性を維持するために、検証済みのクエリとユーザー定義関数（UDF）に基づいてエージェントをグラウンディングできます。チームのエンタープライズ対応アセットが活用されるため、ゼロから作り直す必要はありません。
透明性の高いロジックと要約: 信頼性を高めるために、エージェントは「思考プロセス」と、すべての回答の背後にある生成された SQL を提示します。その後、数千行にわたって得られた分析情報を統合し、数値の背後にある「理由」を説明する簡潔なエグゼクティブサマリーを提供します。
設計から考えられたセキュリティとガバナンス: ユーザーは、閲覧を許可されたデータにのみアクセスできます。すべてのクエリは、BigQuery コンプライアンスフレームワーク内で監査のためにログに記録されます。

クエリの先へ: 次の展開を数秒で予測する

ほとんどのツールはデータのレポートを遡及的に作成しますが、BigQuery の会話型分析により、遡及的なエクスペリエンスが予測的なエクスペリエンスに変わります。BigQuery AI を活用することで、エージェントは簡単な言葉で結果を予測し、隠れたパターンを明らかにできます。

エージェントは、バックグラウンドで AI.FORECAST などの関数を使用してトレンドを予測したり、AI.DETECT_ANOMALIES を使用してリアルタイムで外れ値を検出したりします。これにより、ユーザーはチャットインターフェースを離れることなく、高度な予測分析を数秒で実行できます。エージェントは生成 AI を活用して数百万行のデータを明確なストーリーに要約し、コンテキストに沿った、共有しやすい分析情報を迅速に作成します。

図 3 - 予測分析に BigQuery AI 関数を活用

非構造化データの価値を引き出す

BigQuery の会話型分析に使用できるのは、行と列で構成されるデータだけではありません。エージェントは、BigQuery オブジェクトテーブルに保存された画像などの非構造化データ全体で推論を行うことができます。これにより、単一のインターフェースからデータ資産全体をクエリできるようになり、これまでアクセスできなかった情報を、手動での処理なしで実用的な分析情報に変換できます。

図 4 - BigQuery の会話型分析は非構造化データをサポート

エージェントに命を吹き込む

BigQuery の会話型分析は、元データを最小限の労力でアクティブなインテリジェントエージェントに変換できるように構築されています。テーブルを接続し、特定のビジネス指示とメタデータを追加するだけで、手動クエリから自動インサイトに移行できます。BigQuery のアシストオーサリングを使用すると、高品質のエージェントを迅速に作成し、Looker Studio Pro と BigQuery UI で共有できます。

さらに、API と ADK ツールを使用して、独自のカスタムアプリや既存のエージェントエコシステムにエージェントを統合することもできます。

今すぐデータ分析を変革する

データ分析のボトルネックに対処する準備が整ったら、今すぐ BigQuery の会話型分析のプレビュー版をお試しください。コンテキストに基づくグラウンディングと API 統合のベストプラクティスについて詳しくは、こちらのドキュメントをご覧ください。または、Google Cloud のデータ分析用 AI エージェントに関する詳細をご覧ください。

- プロダクトマネージャー、Vasiya Krishnan

- シニアエンジニアリングマネージャー、Jiaxun Wu

BigQuery AI: Gemini 3.0 対応、エンベディング生成の簡素化、新しい類似度関数

Mon, 02 Feb 2026 02:00:00 +0000

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

デジタル環境には、画像、動画、音声、ドキュメントなどの非構造化データが溢れており、多くの場合、これらは活用されていません。このデータの可能性を最小限の摩擦で活用できるよう、Google は Gemini やその他の Vertex AI モデルを BigQuery に直接統合しました。これにより、BigQuery SQL を使用して生成 AI やエンベディングモデルを簡単に操作できます。この分野での新たなリリースにより、設定がさらに簡素化され、AI 関数でできることが広がります。

エンドユーザー認証情報（EUC）を使用した権限設定の簡素化
テキストと構造化データの両方を生成する AI.generate() 関数
エンベディング生成用の AI.embed() 関数
テキストと画像のセマンティック類似度スコアを計算する AI.similarity()
Gemini 3.0 Pro / Flash のサポート

EUC による合理化された設定

以前は、Vertex AI モデルを BigQuery と統合する際に、個別の接続を構成し、サービスアカウントの権限を管理する必要がありました。EUC を有効にすることで、個人の IAM ID を使用して Vertex AI リクエストを認証できるようになりました。これにより、標準的なインタラクティブクエリの中間接続が不要になり、connection_id パラメータがオプションになります。EUC を利用するには、アカウントに IAM で Vertex AI ユーザーロールが付与されていることを確認するだけです。手順を示した以下のスクリーンショット、または詳しく説明した一般公開ドキュメントをご覧ください。プロジェクトオーナーの場合は、必要な権限がすでに付与されているため、この設定を行う必要はありません。

一般提供版の次世代テキストと構造化生成関数

次世代の BigQuery 生成 AI 関数である AI.GENERATE と AI.GENERATE_TABLE が、プレビュー版から一般提供版になりました。これらの新しい関数により、BigQuery の生成 AI 推論機能で次のことが可能になります。

あらゆる種類のデータを分析: 新しい関数は、テキスト、画像、動画、音声、ドキュメントなど、あらゆる種類の入力を受け付けます。
主要な AI / ML タスクのほとんどを実行: LLM に実行させたいことのプロンプトを入力するだけで、抽出、翻訳、要約、感情分析などのタスクを簡単に実行できます。
SQL のどこでも AI を使用: これらの関数は完全にコンポーズ可能で、標準 SQL 関数が使用できる場所ならどこでも使用できます（SELECT ステートメント、WHERE 句、ORDER BY 句など）。これにより、高度で柔軟なデータ処理が可能になります。
構造化出力を生成: 目的の output_schema を指定して、非構造化データを構造化された分析情報に変換します。

AI.GENERATE は自由形式のテキスト生成に優れており、単純なプロンプトを入力するだけで、要約、翻訳、感情分析など、LLM を利用した幅広い一般的なタスクに活用できます。

さらに、AI.GENERATE は構造化された出力も生成できます。output_schema パラメータを使用すると、出力フィールドの名前とタイプを定義できるため、結果をすぐに解析して、ダウンストリームのアプリケーションで使用できます。

さらに、「sentiment」や「summarize_in_one_sentence」などの説明的な出力フィールド名を指定することで、AI.GENERATE は 1 回の関数呼び出しで複数の AI タスクを実行できます。結果は、簡単に使用できる複数の列で返されます。

以下に 2 つの例を示します。最初の例では、bigquery-public-data.bbc_news.fulltext テーブルのテキストデータを使用します。1 回の AI.GENERATE 呼び出しで、1）主要エンティティの抽出、2）トピックのモデリング、3）感情分析、4）翻訳、5）要約の 5 つのタスクを同時に実行します。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n title,\r\n body,\r\n AI.GENERATE(\r\n body,\r\n output_schema =>\r\n "key_entities ARRAY<STRING>, main_topics ARRAY<STRING>, sentiment STRING, translate_to_chinese STRING, summary_one_sentence STRING").*\r\n EXCEPT (full_response, status)\r\nFROM bigquery-public-data.bbc_news.fulltext\r\nWHERE category = \'tech\'\r\nLIMIT 3;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d218a8bb0>)])]>

上記のクエリを実行すると、次の出力が得られます。

2 つ目の例では、画像を分析します。まず、Cloud Storage の画像を指す BigQuery 外部テーブルを作成します。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE EXTERNAL TABLE bqml_tutorial.product_images\r\n WITH CONNECTION\r\n DEFAULT OPTIONS (\r\n object_metadata = 'SIMPLE',\r\n uris = ['gs://cloud-samples-data/bigquery/tutorials/cymbal-pets/images/*.png']);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d218a8820>)])]>

続けて、次のクエリを実行します。このクエリでは、1 つの AI.GENERATE 関数呼び出しを使用して、画像の説明を生成し、主要なエンティティを抽出します。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n uri,\r\n STRING(OBJ.GET_ACCESS_URL(ref,\'r\').access_urls.read_url) AS signed_url,\r\n AI.GENERATE(\r\n ("What is this: ", OBJ.GET_ACCESS_URL(ref, \'r\')),\r\n output_schema =>\r\n "image_description STRING, entities_in_the_image ARRAY<STRING>").*\r\nFROM bqml_tutorial.product_images\r\nLIMIT 3'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d218a1fa0>)])]>

結果は次のようになります。BigQuery は、署名付き URL を使用して画像を自動的に可視化できます。

BigQuery には、構造化された出力の生成に関して AI.GENERATE と同様の機能を持つ AI.GENERATE_TABLE TVF も用意されています。詳しくは、公式ドキュメントと以前のブログ投稿 BigQuery で生成 AI モデルから構造化データを作成をご覧ください。

エンベディング生成と類似度計算のための新しい簡素化された関数

AI.EMBED 関数は、複雑なデータをエンベディングに変換します。エンベディングとは、意味的類似度を数学的な近さで表現した数値ベクトルです。AI.EMBED を使用してデータを変換することで、抽象的なコンセプトを測定可能な距離に変換し、アイテムを数学的に比較して最適な一致を見つけることができます。これらの機能はどちらも現在プレビュー版で利用できます。

上記で使用した BBC ニュースのデータセットに戻り、次のクエリを使用してテーブル全体のエンベディングを生成できます。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n title,\r\n body,\r\n AI.EMBED(\r\n body,\r\n endpoint => "text-embedding-005"\r\n ).result\r\nFROM\r\n `bigquery-public-data.bbc_news.fulltext`\r\nLIMIT 3;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44730550>)])]>

次のスクリーンショットは、生成された出力を示しています。

さらに、新しい AI.SIMILARITY スカラー関数は、2 つのテキスト、2 つの画像、またはテキストと画像の間で、意味的類似度を計算します。この関数は、内部で 2 つの入力のエンベディングを計算し、それらのコサイン類似度を計算します。これを使用してみるため、住宅市場の下落傾向に関する記事を検索します。次のクエリを使用して、コンテンツが最も類似しているデータセット内の上位 5 件の記事を取得できます。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n "housing market downward trends" AS query,\r\n title AS bbc_news_title,\r\n body AS bbc_news_body,\r\n AI.SIMILARITY(\r\n "housing market downward trends", body, endpoint => "text-embedding-005")\r\n AS similarity_score\r\nFROM `bigquery-public-data.bbc_news.fulltext`\r\nORDER BY similarity_score DESC\r\nLIMIT 5;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44730460>)])]>

出力は以下のとおりです。

これは、AI.SIMILARITY がクエリの根底にあるコンセプトを理解することで、単純な部分文字列検索を超越していることを示しています。エンベディング生成と類似度計算の両方を 1 つの洗練されたステップで処理するため、BigQuery でセマンティック検索を実行する最も効率的な方法です。事前計算や複雑なパイプラインは必要ありません。そのため、アジリティが重要となるインタラクティブな分析、プロトタイピング、小規模から中規模のデータセットの結合に最適です。

これらのセマンティック機能を数百万行または数十億行にわたってスケールする必要があるユースケースでは、VECTOR_SEARCH 関数にシームレスに移行して、事前計算されたエンベディングとベクトルインデックスを利用できます。

Gemini 3.0 のサポート

BQML は、AI.GENERATE などの生成 AI 関数において Gemini 3.0 に対応しています。次のクエリを使用して Gemini 3.0 を呼び出すことができます。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n body,\r\n AI.GENERATE(\r\n CONCAT("Translate into French ", body),\r\nendpoint => \'https://aiplatform.googleapis.com/v1/projects/{YOUR_PROJECT}/locations/global/publishers/google/models/gemini-3-flash-preview\',).result AS translation\r\nFROM\r\n `bigquery-public-data.bbc_news.fulltext`\r\nWHERE\r\n category = \'tech\'\r\nLIMIT 3;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d447304f0>)])]>

Gemini 3.0 のプレビュー期間中は、上記の例のように、HTTP エンドポイント文字列全体を指定する必要があります。近い将来、指定するエンドポイント名は endpoint => 'gemini-3-flash' に簡略化される予定です。

使ってみる

BigQuery の AI 関数を使用してデータを探索する準備はできましたか？使用を開始するには、ドキュメントをご覧ください。これらの新機能に関するご意見や、追加機能のご要望がありましたら、bqml-feedback@google.com までお寄せください。

- ソフトウェアエンジニア、Tianxiang Gao

- ソフトウェアエンジニア、Derrick Li

オープンモデルに対する BigQuery マネージド SQL ネイティブ推論の導入

Wed, 21 Jan 2026 02:00:00 +0000

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

BigQuery では、テキストやエンベディングの生成に利用できるさまざまな LLM（Google の Gemini モデルや、Anthropic、Mistral といったパートナーが提供する Google マネージドモデルなど）にアクセスできます。Gemini モデルや Google マネージドパートナーモデルを BigQuery で使用することは簡単です。基盤モデル名を使ってモデルを作成し、直接 SQL クエリで推論を実行するだけです。このたび、Hugging Face または Vertex AI Model Garden から選択した任意のモデルで、このシンプルさとパワーを実現できるようになりました。

自動管理による SQL ネイティブのワークフロー

BigQuery でマネージドサードパーティ生成 AI 推論（プレビュー版）がリリースされたことにより、わずか 2 つの SQL ステートメントでオープンモデルを実行できるようになりました。

この新機能には、次の 4 つの主なメリットがあります。

デプロイの簡素化: モデル ID 文字列（例: google/gemma-3-1b-it）と単一の CREATE MODEL SQL ステートメントを使用して、オープンモデルをデプロイします。BigQuery により、コンピューティングリソースがデフォルトの構成で自動的にプロビジョニングされます。
自動リソース管理: BigQuery は、アイドル状態のコンピューティングリソースを自動的に解放し、意図しない費用が発生するのを防ぎます。アイドル時間は endpoint_idle_ttl で構成できます。
きめ細かなリソース制御: CREATE MODEL ステートメント内でバックエンドのコンピューティングリソース（マシンタイプや最小 / 最大レプリカ数など）を直接カスタマイズして、パフォーマンスと費用に対するニーズを満たすことができます。
統合された SQL インターフェース: モデルの作成、推論から、費用管理とクリーンアップまで、ワークフロー全体を BigQuery で SQL を使用して直接管理できます。

仕組み: 実例

オープンモデルを作成して活用するプロセスを見ていきましょう。

ステップ 1: BigQuery マネージドオープンモデルを作成するHugging Face または Vertex AI Model Garden のオープンモデルを使用するには、オープンモデル ID とともに CREATE MODEL ステートメントを使用します。モデルのサイズやマシンタイプによって変動しますが、クエリの完了には通常、数分かかります。

Hugging Face モデルhugging_face_model_id オプションを provider_name/model_name 形式で指定します。たとえば、sentence-transformers/all-MiniLM-L6-v2 のように指定します。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE MODEL my_dataset.managed_embedding_model\r\nREMOTE WITH CONNECTION DEFAULT\r\nOPTIONS (\r\n hugging_face_model_id = 'sentence-transformers/all-MiniLM-L6-v2'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219e9520>)])]>

Vertex AI Model Garden モデルmodel_garden_model_name オプションを publishers/publisher/models/model_name@model_version 形式で指定します。たとえば、publishers/google/models/gemma3@gemma-3-1b-it のように指定します。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE MODEL my_dataset.managed_text_model\r\nREMOTE WITH CONNECTION DEFAULT\r\nOPTIONS (\r\n model_garden_model_name = 'publishers/google/models/gemma3@gemma-3-1b-it'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219e9700>)])]>

負荷の高いワークロードの場合は、デプロイ設定（マシンタイプ、レプリカ数、エンドポイントのアイドル時間）をカスタマイズすることで、スケーラビリティを向上させ、費用を管理できます。また、Compute Engine の予約を使用して、GPU インスタンスを確保し、一貫したパフォーマンスを実現することもできます。すべてのオプションについては、CREATE MODEL 構文をご覧ください。

ステップ 2: バッチ推論を実行する上述の CREATE MODEL ジョブが完了したら、BigQuery のデータで AI.GENERATE_TEXT（LLM 推論用）または AI.GENERATE_EMBEDDING（エンベディング生成用）とともに使用できます。

code_block: <ListValue: [StructValue([('code', "-- For embedding generation\r\nSELECT *\r\nFROM\r\n AI.GENERATE_EMBEDDING(\r\n MODEL my_dataset.managed_embedding_model,\r\n (\r\n SELECT text AS content\r\n FROM bigquery-public-data.hacker_news.full\r\n WHERE text != ''\r\n LIMIT 10\r\n ));\r\n\r\n-- For LLM inference\r\nSELECT *\r\nFROM\r\n AI.GENERATE_TEXT(\r\n MODEL my_dataset.managed_text_model,\r\n (\r\n SELECT 'Summarize the text: ' || text AS prompt\r\n FROM bigquery-public-data.hacker_news.full\r\n WHERE text != ''\r\n LIMIT 10\r\n ));"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219e9280>)])]>

Vertex AI エンドポイントのライフサイクル管理と費用管理BigQuery では、自動オプションと手動オプションの両方を使用して、Vertex AI エンドポイントのライフサイクルと費用を柔軟に管理できます。

自動制御: endpoint_idle_ttl オプションを使用すると、リソースの自動リサイクルを有効化できます。指定した期間（例: INTERVAL 10 HOUR）モデルを使用しないようにすると、BigQuery が自動的に Vertex AI エンドポイントを「デプロイ解除」し、費用の発生がすべて停止します。

手動制御: エンドポイントを手動で「デプロイ解除」して費用発生を即座に停止したり、シンプルな ALTER MODEL ステートメントを使用してエンドポイントを再デプロイしたりすることもできます。

code_block: <ListValue: [StructValue([('code', '-- Manually undeploy the model to save costs\r\nALTER MODEL my_dataset.managed_embedding_model\r\nSET OPTIONS(deploy_model = FALSE);\r\n\r\n-- Manually redeploy the model for the next inference job.\r\nALTER MODEL my_dataset.managed_embedding_model\r\nSET OPTIONS(deploy_model = TRUE);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219e9640>)])]>

リソースのクリーンアップが容易

モデルを使い終わったら、後は削除するだけです。BigQuery は関連するすべての Vertex AI リソース（エンドポイントやモデルなど）を自動的にクリーンアップするため、これらのリソースに対する費用は発生しなくなります。

code_block: <ListValue: [StructValue([('code', '-- Model deletion and all backend resource cleanup\r\nDROP MODEL my_dataset.managed_embedding_model;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219e97c0>)])]>

使ってみる

BigQuery のサードパーティモデル向けの新しいマネージド推論機能は、データチームによるサードパーティの生成 AI モデルへのアクセス方法や活用方法を根本的に変えます。モデルのライフサイクル管理全体を、使い慣れた SQL インターフェースに統合することで、運用上の摩擦をなくし、データアナリストから AI / ML エンジニアまで、すべての BigQuery ユーザーが強力なオープンモデルにアクセスできるようになります。包括的なドキュメントとチュートリアルについては、以下のリソースをご参照ください。

ドキュメントを読む: 自動デプロイされるオープンモデルの作成
テキスト生成チュートリアルを試す: Gemma モデルを使用してテキストを生成する
エンベディング生成チュートリアルを試す: オープンモデルを使用してテキストエンベディングを生成する

皆様がどのようなものを構築されるか楽しみにしております。

- ソフトウェアエンジニア Jiashang Liu

- ソフトウェアエンジニア Yunmeng Xie

BigQuery のフルマネージドリモート MCP サーバーでデータ分析エージェントを迅速に構築

Tue, 13 Jan 2026 03:00:00 +0000

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

AI エージェントをエンタープライズデータに接続するのに、複雑なカスタム統合や数週間の開発作業が必要であってはなりません。先月、フルマネージドのリモート Model Context Protocol（MCP）サーバー（Google サービス用）がリリースされたことで、BigQuery MCP サーバーを使用して、データを直接かつ安全に分析する手段を AI エージェントに提供できるようになりました。このフルマネージド MCP サーバーを使うと、管理上のオーバーヘッドが削減され、インテリジェントエージェントの開発に集中できるようになります。

BigQuery の MCP サーバーのサポートは、サーバーの柔軟性と制御性を高めたいユーザー向けに設計されたオープンソースのデータベース向け MCP ツールボックスでも利用できます。このブログ投稿では、2026 年 1 月時点でプレビュー版としてリリースされているフルマネージドのリモート BigQuery サーバーの統合について説明し、デモを行います。

リモート MCP サーバーはサービスのインフラストラクチャで実行され、AI アプリケーションに HTTP エンドポイントを提供します。これにより、定められた標準仕様に基づいて AI MCP クライアントと MCP サーバー間の通信が可能になります。

MCP は、定義されたツールセットを通じて LLM 搭載アプリケーションが分析データに直接アクセスできるようにすることで、AI エージェントの構築プロセスを加速します。Google OAuth 認証メソッドを使用して BigQuery MCP サーバーを ADK と統合するのは簡単です。詳しくは、Agent Development Kit（ADK）と Gemini CLI についての以下の説明をご覧ください。LangGraph、Claude コード、Cursor IDE、その他の MCP クライアントなどのプラットフォームやフレームワークも、大きな労力をかけずに統合できます。

では詳しく見ていきましょう。

ADK で BigQuery MCP サーバーを使用する

ADK を使用して BigQuery エージェントのプロトタイプを構築する手順は次の 6 つです。

前提条件: プロジェクト、必要な設定、環境を準備します。
構成: MCP と必要な API を有効にします。
サンプルデータセットを読み込みます。
OAuth クライアントを作成します。
Gemini API キーを作成します。
エージェントを作成してテストします。

重要: 本番環境へのデプロイを計画する場合や、実際のデータで AI エージェントを使用する場合は、AI のセキュリティと安全性、安定性に関するガイドラインを遵守してください。

手順 1: 前提条件 > 構成と環境

1.1 Cloud プロジェクトを設定する課金が有効になっている Google Cloud プロジェクトを作成するか、既存のプロジェクトを使用します。

1.2 ユーザーロールユーザーアカウントに、プロジェクトに対する次の権限があることを確認します。

roles/bigquery.user（クエリの実行用）
roles/bigquery.dataViewer（データへのアクセス用）
roles/mcp.toolUser（MCP ツールへのアクセス用）
roles/serviceusage.serviceUsageAdmin（API の有効化用）
roles/iam.oauthClientViewer（OAuth）
roles/iam.serviceAccountViewer（OAuth）
roles/oauthconfig.editor（OAuth）

1.3 環境を設定するgcloud CLI がインストールされた MacOS または Linux ターミナルを使用します。

シェルで、Cloud の PROJECT_ID を指定して次のコマンドを実行し、Google Cloud アカウントを認証します。これは、ADK が BigQuery にアクセスできるようにするために必要です。

code_block: <ListValue: [StructValue([('code', '# Set your cloud project id in env variable\r\nBIGQUERY_PROJECT=PROJECT_ID\r\n\r\ngcloud config set project ${BIGQUERY_PROJECT}\r\ngcloud auth application-default login'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219cbb50>)])]>

指示に沿って認証プロセスを完了します。

手順 2: 構成 > ユーザーロールと API

2.1 BigQuery API と MCP API を有効にする次のコマンドを実行して、BigQuery API と MCP API を有効にします。

code_block: <ListValue: [StructValue([('code', 'gcloud services enable bigquery.googleapis.com --project=${BIGQUERY_PROJECT}\r\ngcloud beta services mcp enable bigquery.googleapis.com --project=${BIGQUERY_PROJECT}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219cbc70>)])]>

手順 3: サンプルデータセットを読み込む > cymbal_pets データセット

3.1 cymbal_pets データセットを作成するこのデモでは、cymbal_pets データセットを使用します。次のコマンドを実行して、公開ストレージバケットから cymbal_pets データベースを読み込みます。

code_block: <ListValue: [StructValue([('code', '# Create the dataset if it doesn\'t exist (pick a location of your choice)\r\n# You can add --default_table_expiration to auto expire tables.\r\nbq --project_id=${BIGQUERY_PROJECT} mk -f --dataset --location=US cymbal_pets\r\n\r\n# Load the data\r\nfor table in products customers orders order_items; do \r\nbq --project_id=${BIGQUERY_PROJECT} query --nouse_legacy_sql \\\r\n "LOAD DATA OVERWRITE cymbal_pets.${table} FROM FILES(\r\n format = \'avro\',\r\n uris = [ \'gs://sample-data-and-media/cymbal-pets/tables/${table}/*.avro\']);"\r\ndone'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219cb9a0>)])]>

手順 4: OAuth クライアント ID を作成する

4.1 OAuth クライアント ID を作成するGoogle OAuth を使用して BigQuery MCP サーバーに接続します。

7. Google Cloud コンソールで、[Google Auth Platform] > [クライアント] > [クライアントの作成] に移動します。

* [アプリケーションの種類] の値には [デスクトップアプリ] を選択します。
クライアントを作成したら、クライアント ID とシークレットをコピーして安全に保管してください。

省略可: OAuth クライアントに別のプロジェクトを使用した場合は、CLIENT_ID_PROJECT を指定して以下を実行します。

code_block: <ListValue: [StructValue([('code', 'gcloud beta services mcp enable bigquery.googleapis.com --project=CLIENT_ID_PROJECT'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d219cbd00>)])]>

注 [Cloud Shell ユーザーのみ]: Google Cloud Shell または localhost 以外のホスティング環境を使用している場合は、「ウェブアプリケーション」の OAuth クライアント ID を作成する必要があります。

Cloud Shell 環境の場合:

[承認済みの JavaScript 生成元] の値には、次のコマンドの出力を指定します。echo "https://8000-$WEB_HOST"
[承認済みのリダイレクト URI] の値には、次のコマンドの出力を使用します。echo "https://8000-$WEB_HOST/dev-ui/"（Cloud Shell の URI は一時的なもので、現在のセッションの終了後に期限切れになります）

注: ウェブサーバーを使用する場合は、「ウェブアプリケーション」タイプの OAuth クライアントを使用し、適切なドメインとリダイレクト URI を入力する必要があります。

手順 5: Gemini の API キー

5.1 Gemini の API キーを作成するAPI キーのページで Gemini API キーを作成します。ADK を使用して Gemini モデルにアクセスするには、生成されたキーが必要です。

手順 6: ADK ウェブアプリケーションを作成する

6.1 ADK をインストールするADK をインストールしてエージェントプロジェクトを開始するには、ADK の Python クイックスタートに記載されている手順に沿って進めます。

6.2 新しい ADK エージェントを作成する次に、BigQuery リモート MCP サーバー統合用の新しいエージェントを作成します。

code_block: <ListValue: [StructValue([('code', 'adk create cymbal_pets_analyst\r\n\r\n#When prompted, choose the following:\r\n#2. Other models (fill later)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44329040>)])]>

6.3 env ファイルを構成する次のコマンドを実行して、cymbal_pets_analyst/.env ファイルを以下の変数とその実際の値で更新します。

code_block: <ListValue: [StructValue([('code', 'cat >> cymbal_pets_analyst/.env <<EOF\r\nGOOGLE_GENAI_USE_VERTEXAI=FALSE\r\nGOOGLE_CLOUD_PROJECT=BIGQUERY_PROJECT\r\nGOOGLE_CLOUD_LOCATION=REGION\r\nGOOGLE_API_KEY=AI_STUDIO_API_KEY\r\nOAUTH_CLIENT_ID=YOUR_CLIENT_ID\r\nOAUTH_CLIENT_SECRET=YOUR_CLIENT_SECRET\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44329100>)])]>

6.4 エージェントコードを更新するcymbal_pets_analyst/agent.py ファイルを編集し、ファイルの内容を次のコードに置き換えます。

code_block: <ListValue: [StructValue([('code', 'import os\r\nfrom google.adk.agents.llm_agent import Agent\r\nfrom google.adk.tools.mcp_tool import McpToolset\r\nfrom google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams\r\nfrom google.adk.auth.auth_credential import AuthCredential, AuthCredentialTypes\r\nfrom google.adk.auth import OAuth2Auth\r\nfrom fastapi.openapi.models import OAuth2\r\nfrom fastapi.openapi.models import OAuthFlowAuthorizationCode\r\nfrom fastapi.openapi.models import OAuthFlows\r\nfrom google.adk.auth import AuthCredential\r\nfrom google.adk.auth import AuthCredentialTypes\r\nfrom google.adk.auth import OAuth2Auth\r\n\r\ndef get_oauth2_mcp_tool():\r\n auth_scheme = OAuth2(\r\n flows=OAuthFlows(\r\n authorizationCode=OAuthFlowAuthorizationCode(\r\n authorizationUrl="https://accounts.google.com/o/oauth2/auth",\r\n tokenUrl="https://oauth2.googleapis.com/token",\r\n scopes={\r\n "https://www.googleapis.com/auth/bigquery": "bigquery"\r\n },\r\n )\r\n )\r\n )\r\n auth_credential = AuthCredential(\r\n auth_type=AuthCredentialTypes.OAUTH2,\r\n oauth2=OAuth2Auth(\r\n client_id=os.environ.get(\'OAUTH_CLIENT_ID\', \'\'),\r\n client_secret=os.environ.get(\'OAUTH_CLIENT_SECRET\', \'\')\r\n ),\r\n )\r\n\r\n bigquery_mcp_tool_oauth = McpToolset(\r\n connection_params=StreamableHTTPConnectionParams(\r\n url=\'https://bigquery.googleapis.com/mcp\'),\r\n auth_credential=auth_credential,\r\n auth_scheme=auth_scheme,\r\n )\r\n return bigquery_mcp_tool_oauth\r\n\r\n\r\nroot_agent = Agent(\r\n model=\'gemini-3-pro-preview\',\r\n name=\'root_agent\',\r\n description=\'Analyst to answer all questions related to cymbal pets store.\',\r\n instruction=\'Answer user questions, use the bigquery_mcp tool to query the cymbal pets database and run queries.\',\r\n tools=[get_oauth2_mcp_tool()],\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d443295b0>)])]>

6.5 ADK アプリケーションを実行するcymbal_pets_analyst フォルダを含む親ディレクトリから次のコマンドを実行します。

code_block: <ListValue: [StructValue([('code', 'adk web --port 8000 .'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44329220>)])]>

ブラウザを起動し、http://127.0.0.1:8000/ または ADK を実行するホストを指定して、プルダウンからエージェント名を選択します。これで、Cymbal のペットのデータに関する質問に答えるパーソナルエージェントができました。エージェントが MCP サーバーに接続すると、OAuth フローが開始され、アクセス権を付与できるようになります。

2 つ目のプロンプトでは、プロジェクト ID を指定する必要がなくなっています。エージェントは会話からこの情報を推測できるためです。

質問の例は次のとおりです。

my_project にはどのようなデータセットがある？
cymbal_pets データセットにはどのようなテーブルがある？
cymbal_pets データセットのテーブル customers のスキーマを取得して
米国西部地域の Cymbal のペットショップで、過去 3 か月間の注文数上位 3 件を特定して。注文したお客様とそのメール ID も特定して。
上位 1 件ではなく、上位 10 件の注文を取得できる？
過去 6 か月間で最も売れた商品は？

Gemini CLI で BigQuery MCP サーバーを使用する

Gemini CLI を使用するには、~/.gemini/settings.json ファイルで次の構成を使用します。既存の構成がある場合は、この構成を mcpServers フィールドの下にマージする必要があります。

code_block: <ListValue: [StructValue([('code', '{\r\n "mcpServers": {\r\n "bigquery": {\r\n "httpUrl": "https://bigquery.googleapis.com/mcp",\r\n "authProviderType": "google_credentials",\r\n "oauth": {\r\n "scopes": [\r\n "https://www.googleapis.com/auth/bigquery"\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d443294c0>)])]>

次に、gcloud で認証を実行します。

code_block: <ListValue: [StructValue([('code', 'gcloud auth application-default login --clien-id-file YOUR_CLIENT_ID_FILE'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d44329310>)])]>

Gemini CLI を実行します。

code_block: <ListValue: [StructValue([('code', 'gemini'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9d443293d0>)])]>

エージェント用の BigQuery MCP サーバー

BigQuery ツールを開発ワークフローに統合し、LLM と BigQuery MCP サーバーを使用してインテリジェントなデータエージェントを作成できます。統合は、すべての主要なエージェント開発 IDE およびフレームワークと互換性のある単一の標準プロトコルに基づいています。もちろん、本番環境向けにエージェントを構築したり、実際のデータで使用したりする前に、AI のセキュリティと安全性に関するガイドラインを遵守してください。

皆様も BigQuery MCP サーバーを活用して、データ分析生成 AI アプリケーションをぜひ開発してみてください。

- テクニカルプログラムマネージャー、Vikram Manghnani- ソフトウェアエンジニア、Prem Ramanathan

すかいらーくグループにおける生成 AI 活用: 店舗オペレーションの変革とデータ民主化への挑戦

Wed, 07 Jan 2026 02:30:00 +0000

「ガスト」や「ジョナサン」「バーミヤン」など 20 以上のブランド、計約 3,000 店舗を運営展開、年間約 3.5 億人の来訪客を迎える日本を代表する外食チェーンのすかいらーくグループ。その運営母体である株式会社すかいらーくホールディングス（以下、すかいらーく）ではデジタル技術を活用した店舗の業務改善や、データドリブン経営の推進に積極的に取り組んでいます。今回は、生成 AI を活用したユニークな店舗施策である「いらあり（挨拶あり）」プロジェクトと、組織全体でのデータ活用を加速させる「Gemini in BigQuery」の活用事例について、その背景や開発の裏側、そして得られた成果について、マーケティング本部の池田氏と藤本氏にお話を伺いました。

店舗業務の効率化が進む中、「挨拶」をテクノロジーで可視化

すかいらーくグループが現在推進している「いらあり」プロジェクトは、店舗における「いらっしゃいませ」「ありがとうございました」という基本の挨拶をデジタル技術で計測し、サービス品質を向上させる取り組みです。昨今、店舗では配膳ロボットやセルフレジの導入が進み、業務効率が飛躍的に向上している一方で、お客様とスタッフとの物理的な接点が減少しているという課題感がありました。そこで、限られたお客様との接点の中で最大限のホスピタリティを発揮するため、基本である挨拶を気持ちよく行えているかを客観的に計測するプロジェクトが立ち上がりました。

具体的には、店舗に元々置いているデバイスを活用し、店舗スタッフの発話を Gemini などの AI で分析します。その際、24 時間分のデータを全て分析するのではなく、店舗の AI カメラとの連携などを通し、必要箇所のみ抽出する工夫が行われています。

分析結果として得られた、発話率や挨拶のクオリティは、営業チームと共有し、効果の検証を進めています。

開発にあたっては、Google Cloud が提供する「Technical Acceleration Program（TAP）」を活用しました。これは通常のワークショップとは異なり、Google Cloud のエンジニアとすかいらーくの担当者が、アーキテクチャディスカッションを経て、その場でプロトタイプまでを作り上げる実践的なプログラムです。当初、独自に開発を進めた場合 2〜3 か月かかると想定されていた工程が、この TAP を利用することでわずか 2 日間で構成のディスカッションからプロトタイプ作成まで完了し、圧倒的なスピードでプロジェクトを加速させることができました。「ここまでのスピード感で進められた事は圧倒的なメリットでしたが、技術的な観点でも非常に大きな転換になりました。例えば、従来のやり方を踏襲するならば、一度音声データを Cloud Storage などに置いて、プログラムから処理するというやり方を採用していたかと思います。しかし、今回のディスカッションを通して、最終的には BigQuery から直接 Storage のデータを書き起こし処理まで行うなど、最新の機能を踏まえたよりシンプルな構成で実現できるという結論に至ることができました」と池田氏は話します。

現在、検証段階のこのプロジェクトには、まだ発話の見逃しやスコア生成の精度に課題が残っています。今後は、蓄積されたデータをもとにさらなるプロンプト調整を行い、低コストかつ高精度な店舗オペレーション分析基盤として完成度を高めていきたいと考えています。

業務部門が自らデータに触れる。「データの民主化」がもたらす意識変革

もう 1 つの大きな柱が、Gemini in BigQuery を活用したデータ活用のプロジェクトです。この取り組みは、これまで一部の専門部署に閉じていたデータを組織全体で活用 / 分析できるようにし、「データの民主化」と「業務効率の抜本的改善」を実現することを目的としています。2025 年 8 月から 11 月にかけて実施された PoC（概念実証）では、3 つのユースケースを対象に、生成 AI とデータ分析基盤を融合させた新たな業務フローの検証が行われました。

BigQuery の AI 関数（Gemini）を活用し、自社の1st Party データに加え、Web 上のリアルタイム情報（自社や他社のキャンペーン、トレンド、気象実績や予報など）を掛け合わせた高度な分析が可能になりました。

これを受け、マーケティング本部では売上分析の高度化に着手しました。従来、「売上が 5% 下がった理由」を特定するには、天候、販促影響、メニュー改定、前年実績といった多岐にわたる要因を個別に調査する必要があり、多大な労力を要していました。現在は Gemini in BigQuery を活用することで、こうした複合的な要因について Gemini の膨大な知識を活用して、自然言語で多角的に分析をすることができるようになりました。

また営業本部では、約 3,000 店舗におよぶ PL（損益計算書）分析において Gemini in BigQuery を活用しています。

取り組みの第一歩として、従来表計算ソフトで個別管理され、閲覧範囲も限定的だった店舗別 PL データを BigQuery へ集約しました。これにより、顧客対応やマーケティング部門が収益と各費用項目の相関関係を直接分析できるようになり、サービス向上や業務改善につながる新たな価値創出が期待されています。

藤本氏は次のように語ります。「データの民主化により、ビジネスの現場担当者が直接データに触れ、試行錯誤（トライアンドエラー）を繰り返せるようになりました。これは非常に意義深いことです。例えば『ここの数字に違和感がある』といった現場ならではの肌感覚や知見を、即座に分析へ反映できるからです。また、担当者自身が手を動かして改善まで繋げられる点は、分析業務を『自分事』として捉える意識変革にも寄与していると感じています。」

店舗開発の分野では、これまで現場のプロフェッショナルが、表計算ソフトと長年の「暗黙知」を頼りに、新規出店候補の売上予測を行ってきました。

今回のプロジェクトでは、Gemini in BigQuery の「Data Science Agent」を導入しました。これにより、データサイエンティストではない現場のビジネスユーザー自らが、トライアンドエラーを繰り返しながら予測精度を高めていくプロセスが実現しました。

プロジェクトの中では、「街路樹が視認性を遮る」「駐車場の配置が重要」といったベテラン社員ならではの経験則を用いて、AI の予測結果を人間が補正する場面もありました。現在はさらなる精度向上に向け、こうした経験則（暗黙知）自体を可能な限り「数値」として取り込み、分析モデルに組み込むことで、より高度なデータドリブン経営の実現に取り組んでいます。

技術と業務の垣根がなくなったことで、社員が主体的にデータに向き合う土壌が育まれ、まさに「データの民主化」が形になりつつあります。今後は社内での成功事例を積み重ね、この新しい文化を組織全体へ浸透させることで、すかいらーくの変革をさらに加速させていきます。

インタビュイー（写真右から）
株式会社すかいらーくホールディングス
マーケティング本部
池田裕
藤本祥恵

株式会社すかいらーくホールディングス
『価値ある豊かさの創造』という経営理念と「ひとりでも多くのお客様に　安くておいしい料理を　気持ちのよいサービスで　快適な空間で味わっていただく」というミッションのもと、ガスト、バーミヤン、ジョナサンなど、約 3,000 店舗を展開し、年間約 3.5 億人のお客様が来店。

株式会社システムサポート
Google Cloud の認定パートナーとして数多くの生成 AI 案件の実績を持ち、「いらあり」プロジェクトでは Gemini 2.5 Flash を利用し「文字起こし・検出」の精度をさらに向上させるための有効なアプローチと「スコア生成」の評価を実施。

株式会社データフォーシーズ
データサイエンスのスペシャリスト集団として、高度な解析技術を用いたビジネス課題の解決や DX 推進を支援する企業。今回の事例ではデータマート構築の支援を実施。

DeNA: Spanner、C4A インスタンスを駆使して世界規模のゲームアプリ『Pokémon TCG Pocket』の安定運用を実現

Mon, 22 Dec 2025 02:30:00 +0000

2024 年 10 月 30 日より、150 の国と地域でサービスを開始した、スマートフォン向けポケモンカードゲーム『Pokémon Trading Card Game Pocket（以下、ポケポケ）』。株式会社ポケモン、株式会社クリーチャーズ、そして株式会社ディー・エヌ・エー（以下、DeNA ）の合同プロジェクトである本アプリに、Google Cloud がどのように貢献しているのか。本プロジェクトでサーバー・アプリ開発を担当した DeNA のお二人に伺います。

利用しているサービス:
Spanner、Google Kubernetes Engine（GKE）、BigQuery など

利用しているソリューション:
データベース

Spanner の存在が Google Cloud を選んだ最大の理由

『ポケポケ』は世界中で楽しまれているポケモンカードを、手軽にコレクションできるアプリです。2025 年 10 月には全世界累計 1.5 億ダウンロードを突破し、世界規模で圧倒的な支持を集めています。

本タイトルは、パブリッシュと全体プロデュースを担う株式会社ポケモン、カードゲーム開発を担う株式会社クリーチャーズ、そしてサーバー・アプリ開発と運用を担う DeNA の 3 社合同プロジェクトとしてスタート。世界中から膨大なアクセスを受け付けるアプリの安定運用は、これまでさまざまなビッグタイトルを手がけてきた DeNA の手腕に委ねられていました。

同社 IT 本部 IT 基盤部副部長として『ポケポケ』のインフラ周りを統括した天野知樹氏は、DeNA がかねてより、サービス基盤のほとんどをパブリッククラウド化していることもあり、『ポケポケ』に関しても当初からクラウドで運用されることが決まっていたと話します。

「『ポケポケ』のような世界規模のサービスを展開するには、パブリッククラウドの迅速なリソース調達力が不可欠です。特に、負荷試験やサービス開始直後にドカンとリソースを使い、その後、徐々に落ちついていくゲーム特有の性質はパブリッククラウドに好適。現在では『ポケモンマスターズEX 』など、弊社タイトルの 99.99% が各種パブリッククラウド上で運用されるまでになっています。そこで、今回のプロジェクトにおけるインフラ基盤として、Google Cloud の利用をさらに拡大することにしました。」

天野氏は、 Google Cloud を選んだ最大の理由が Spanner だったと断言。サーバーの開発初期から本プロジェクトに携わり、現在はサーバーチームのリードエンジニアとして活躍する柴田佳祐氏は、Spanner の価値を次のように説明してくれました。

「『ポケポケ』のような多くのお客様がアクセスする大規模ゲームアプリでは、データベースのシャーディングやデータ整合性の維持などといった技術的課題をどう解決するかが大きな問題になります。従来のデータベース技術では、シャーディングの制御やシャードまたぎのトランザクションの考慮、シャード数の増減などが大変なのですが、Spanner はそれらの難度の高い処理を全て自動化してくれます。さらに、レプリケーション遅延を考慮する必要がなく、トランザクションが強い整合性を持つため、アプリ開発が容易になります。これはゲーム開発において大変魅力的な性質でした。サーバーの開発開始当初、他のパブリッククラウドには類似の機能を持つサービスはありませんでしたし、また、現在においても、トータルでは最も我々の用途に合致した選択肢だと考えています。」

「事前分割（Pre-splitting）」の活用で、ローンチ直後の大規模アクセスにも対応

もちろん、『ポケポケ』ほどの大規模アクセスをさばくのは Spanner であっても容易なことではありません。実際、毎秒 1,000 万クエリを Spanner に発行するなど、膨大なトラフィックを想定して行われた事前の負荷試験ではパフォーマンスの立ち上がりに課題が見つかったと、柴田氏は当時を振り返ります。

「Spanner には内部的にスプリットと呼ばれるシャードのようなものが存在します。これは基本的には自動で増減しますが、急激な負荷のスパイクが発生するとスプリットの増加が間に合わず、ローンチ直後や新しい拡張パックの追加直後にレイテンシの悪化が起こる懸念がありました。ダミーの負荷をかけて分割を促すこともできるのですが、お客様が遊んでいる状態で大きなダミーの負荷をかけるのはリスクを伴います。」

柴田氏がこの問題を Google Cloud に相談したところ、当時はまだプライベートプレビュー段階であった事前分割（Pre-splitting）機能を前倒しで提供（2025 年 4 月 28 日より一般提供開始）。あらかじめスプリットを割っておけるようになったことで、必要な時に必要なパフォーマンスを発揮できるようになったと言います。

「実際、2024 年 10 月のローンチ時も、ほぼ垂直にトラフィックのグラフが上がっていく中、見事に耐えきってくれて感動しました。チームの仲間たちと『恐ろしいほど問題が起きないね』と話していたくらいです（笑）。」（柴田氏）

事前分割機能はその後も、新しい拡張パックの公開時など、トラフィック増大が予想されるケースで活躍しています。

「Spanner があったからこそ、安定した運用ができているのは間違いありません。別のデータベースを使っていたら、もっと大変だったろうと想像しています。」（天野氏）

C4A インスタンスはコスパも安定性も優れた理想的な選択肢

『ポケポケ』のサービス安定性を支えているのは Spanner だけではありません。『ポケポケ』ではそのサービスを維持するため、膨大な数のサーバーを動かしており、サービス開始当初は、すでに多くの過去タイトルで採用実績のある Tau T2D インスタンスを採用していました。しかし、いくつかの理由から、当時登場したばかりの C4A インスタンスへ移行することを決断します。

「最大の理由はコストです。ポケポケでは API サーバーとバトルサーバーで合計約 2 万コアものサーバーを動かしており、その料金を削減したいという気持ちがありました。サービス開始前の試算では Tau T2D インスタンスが最も費用対効果に優れた選択肢だったのですが、C4A インスタンスがなんとポケポケのサービス開始と同日に発表され（笑）、すぐに移行を検討し始めました。また、パフォーマンスの安定性という観点からも『さまざまなワークロードに対して一貫して高いパフォーマンスを実現』と謳う C シリーズの方がポケポケのようなゲームタイトルと相性が良いと考えました。」（天野氏）

x86-64 アーキテクチャの Tau T2D インスタンスから、arm64 アーキテクチャの C4A インスタンスへの移行は、マルチアーキテクチャイメージを作成することで実現しています。

「クロスコンパイルが容易な Go 言語を使っていたこともあり、マルチアーキテクチャイメージのビルドは想定していたよりも苦労なく移行できました。」（柴田氏）

なお、インスタンスの移行は、サービスを中断せずにノーメンテナンスで実施。移行後は大きなチューニングも必要なく、すぐに大きな性能向上があったとのことです。

「特に API サーバーのコストパフォーマンス向上が著しく、Tau T2D インスタンスの時と比べて約 73% もの改善を達成しています。リアルタイム性の高いバトルサーバーは安定性を重視したため API サーバーほどの成果は得られませんでしたが、それでも約 11% の改善ができました。以前はコストパフォーマンス重視なら Tau T2D インスタンス、安定性重視なら C シリーズでしたが、C4A インスタンスは、とりわけ我々の用途においてはコスパも安定性も優れた理想的なインスタンスだと感じました。」（天野氏）

今回の成果は株式会社ポケモン、株式会社クリーチャーズからも高く評価されているとのこと。最後に、天野氏は、Spanner および C4A インスタンスの活用について、今後の展望を語ってくれました。

「『ポケポケ』での成果を踏まえ他のゲームタイトルでも Google Cloud を積極的に活用していくことになっていくでしょう。また、DeNA として AI に ALL IN していくことを表明しており、AI を用いた事業変革の中心にいる Google のポテンシャルにも期待しています。例えば重要性の高くない作業を AI エージェントに代替させていくことでエンジニアがより創造的な仕事に取り組んでいけるようにしたいですね。そのためにもこれからはより一層、コミュニケーションを密接にし、強力な信頼関係のもと、スピード感を高めた開発をしていければと思っています。」

株式会社ディー・エヌ・エー
「一人ひとりに　想像を超えるDelightを」のミッションのもと、ゲーム、ライブコミュニティ、スポーツ・まちづくり、ヘルスケア・メディカルなど幅広い事業を展開。事業価値の最大化と課題解決のためのAI活用と独自のデータ分析手法によって、顧客ニーズを的確に捉えた付加価値の高いサービス開発から運用までを行っている。

株式会社ポケモン
「ポケモン」を永続的なブランドに育てるべく 1998 年に設立。コンテンツや商品づくり、マーケティング、その他あらゆる活動を通じて、ポケモンの個性を引き出し、魅力を引き出すことを目的とする。グループは自社を含め世界に 13 社、オフィスは 14 拠点にあり、それぞれのマーケットで、ポケモンプロデューサーとして取り組んでいる。

株式会社クリーチャーズ
1995 年設立。任天堂株式会社、株式会社ゲームフリークと並ぶポケモン原作著作者企業（株式会社ポケモンはこの 3 社の共同出資により設立）。ポケモンのトレーディングカードゲーム・ビデオゲームの開発、『ポケットモンスター』シリーズなどの CG モデル・モーションの開発事業などを展開し、ますます広がるポケモンの世界を支えている。

インタビュイー（写真右から）
株式会社ディー・エヌ・エー
・IT 本部 IT 基盤部副部長　天野知樹氏
・ゲームサービス事業本部開発運営統括部第二技術部サーバー
　第一グループエンジニア　柴田佳祐氏

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

radiko: BigQuery と Looker で DMP を刷新、大幅なコスト削減と業務効率化、850 万ユーザーのデータ活用を推進

Fri, 19 Dec 2025 03:00:00 +0000

アプリやウェブでラジオやポッドキャストが聴ける音声配信サービス「radiko」では、ユーザー数が順調に伸びる一方で、 DMP（データマネジメントプラットフォーム）の処理能力やコストに課題を抱えていました。その解決のために導入されたのが、Google Cloud の BigQuery と Looker です。株式会社radiko（以下、radiko）のデータ統括チームと、移行作業をサポートした DATUM STUDIO株式会社（以下、DATUM STUDIO）の担当者に、新時代のデータ活用について話を伺いました。

利用しているサービス:
BigQuery, Cloud Composer, Looker など

従来のシステムでは限界に達していた処理能力とランニングコスト

もともとラジオの難聴取エリアの解消のために始まった radiko は、今では場所・時間・デバイスにとらわれない自由な音声配信サービスとして多くのリスナーを獲得。約 850 万人の MAU（月間アクティブユーザー数）を誇る、一大プラットフォームへと成長しました。これを受けて、近年 radiko ではユーザーの性別、年齢などのセグメント情報や、聴取ログなどの膨大なデータを DMP で収集、分析、活用してきました。しかし 2020 年代に入り、従来の DMP での作業に支障が生じ始めました。当時の事情を、同社のデータ統括チームのリーダー、長谷川史織氏は次のように説明します。

「それまで radiko の MAU は 700 万人ほどだったんですが、コロナ禍の巣ごもり需要をきっかけに跳ね上がり、現在は 850 万人前後で推移しています。radiko ではユーザーごとに 1 分間に 1 回のログをとっているため、月間の総レコード数が 100 億にも上ります。私たちデータ統括チームでは、そのデータの収集から、分析、放送局や広告会社への送信まで、さまざまな作業に DMP を活用しています。しかし既存のサービスでは、容量的にも処理速度の面でも、負荷に耐えきれない状況になっていました。また、データ量の増加に応じて契約額も上がり、コスト的にも見合わなくなってしまったのです。」

2023 年、長谷川氏らは新たな DMP への移行を検討し始めます。その際に候補としてあがったのが Google Cloud の BigQuery でした。検証作業の際には、他社の製品、そして従来のシステムの継続も含め、3 つの選択肢を対象に詳細な比較を実施。BigQuery では、従来よりデータ処理の時間が大幅に短縮できることがわかりましたが、長谷川氏は他にも魅力があったと振り返ります。

「BigQuery を選んだ理由のひとつは、生成 AI や機械学習の活用を想定したとき、最も将来性が感じられたことです。もうひとつは、radiko のアプリ開発チームが、すでに Google Cloud を利用していたことです。私たちの部門でも BigQuery を導入すれば、社内でシームレスな連携ができるという期待が持てました。最後はやはりコストパフォーマンスです。 BigQuery は従量課金制ですが、処理の仕方を工夫すれば、コストをかなり削減できることがわかりました。それらを総合的に考えると、やはり Google Cloud への移行がベストの選択肢でした。」（長谷川氏）

Google Cloud と BigQuery への移行を機に DMP 基盤を一新

検証から実際の移行まで、技術面をサポートしたのが、企業のデータ活用支援で定評のある DATUM STUDIO です。同社のデータエンジニア、信末竜空氏は、radiko のデータ統括チームに協力し、BigQuery を中心とした新しい基盤の構築を支援しました。

「新たな基盤では、Cloud Storage をデータの受け渡し口、BigQuery をデータウェアハウスとしてデータの蓄積・集計を行い、その結果をダッシュボードや外部システム、連携企業へ出力しています。これらのデータフロー全体を制御するオーケストレーションツールとしては、Cloud Composer を利用しています。Cloud Composer はマネージドサービスなので、内部の動作がわからないことがありましたが、Google Cloud のサポートから具体的な提案を受けられたおかげで、効率的で安定した基盤を作ることができました。Google Cloud のツールはエンジニアやデータサイエンティストにとって扱いやすく、将来的に継続的な改善が期待できる点も魅力だと感じています。」

移行作業において、長谷川氏と信末氏が最初に注力したのが、コスト削減の実現です。検証の初期段階では、radiko が扱う全データ量のわずか 1% を処理するだけでも、1 日あたり数十万円規模のコストがかかるという試算結果が出ましたが、そこから地道な工夫を重ねることで、目標を達成していきます。

「BigQuery の場合、膨大なデータをすべて触ってしまうと非常にコストがかかってしまいます。ただしパーティション分割テーブルを活用したり、クラスタリングキーによるクエリ高速化とスキャン削減、必要なカラムのみをセレクトするといったテクニックを使えば、コストを最適化していくことができます。そうした工夫の余地があることも BigQuery の優れた面だと思います。」（信末氏）

実質的な移行作業は約 1 年間で完了し、2025 年 5 月には BigQuery を中心とした DMP 基盤が稼働し始めます。長谷川氏によれば、この新たなシステムは、データ処理費用を約 54% 削減することを可能にしました。

「運用コストだけでなく、放送局や広告会社へデータを送る作業時間も格段に減りました。以前はデータ処理から転送完了まで 6〜7 時間かかっていたのが、BigQuery の導入後は 1〜2 時間で済むようになりました。それまで 1 日かけてやっていた作業が午前中で終わり、空いた時間で新しい仕事にチャレンジできるようになったという面でも、導入したかいがあったと感じています。」（長谷川氏）

Looker によって迅速にフレッシュな情報を提供し、新たなデータ活用も開始

radiko ではリスナーの性別や年代、興味関心など、約 300 項目ものセグメント情報を放送局や広告会社に提供していますが、そのデータの “鮮度” も、BigQuery の採用によって大幅に向上したといいます。

「以前も性別や年代などの基本情報は毎日更新していましたが、処理能力の問題で、それ以外の深い情報の更新は 1 週間に 1 回程度が限界だったんです。しかし今では、基本情報は 30 分に 1 回更新していますし、他のデータもかなり高い頻度で更新できるようになりました。放送局さんからも、『早くデータが届くようになったので活用しやすい』というお言葉をいただいています。」（長谷川氏）

radiko では、より高度なデータ分析と可視化を実現すべく、2025 年 10 月から、BI（ビジネスインテリジェンス）ツールの Looker も活用されています。

「これまでは社内や取引先から『こんなデータがほしい』とリクエストされるたびに、データ統括チームのメンバーがクエリを書いて、データを抽出していました。Looker を使うことでクエリを書く手間が省けたうえに、その指標がどの参照元から引き出したもので、どういう意味を持つかも明確になりました。作業者によって解釈がぶれることもなくなり、生データと抽出したデータの間に一貫性が保てるようになったのです。」（長谷川氏）

さらにデータ統括チームでは社内用と放送局用に、それぞれ必要な情報を可視化したダッシュボードを構築し、運用を開始しました。

「放送局さん向けには、以前より『radiko viewer』というダッシュボードを提供して、番組制作や編成、広告営業にご利用いただいていました。なかには『もう少し詳しく分析したい』というご要望をいただく放送局もあり、そうした局向けに Looker で深掘りできるダッシュボードを個別に提供しています。」（長谷川氏）

さまざまな開発業務のサポートを経て、広告効果の分析などにも携わるようになった信末氏は、今後のデータ活用に強い意欲を見せていました。

「DMP のパフォーマンスが改善されたことで、今まで使い切れていなかったデータも活用できるようになりました。業界全体としてデータドリブンな意思決定を進めていくなかで、radiko さんは中核となれる存在だと思います。個人的にも radiko さんと一緒に、その促進に取り組んでいきたいと考えています。」（信末氏）

最後に、長谷川氏はデータの活用が切り拓く、ラジオと radiko の新たな未来について希望を語ってくれました。

「誰もがデータは貴重な資産であると認識していながら、これまではなかなか活用しきれなかったという現実がありました。しかし今は、BigQuery と Looker を駆使した新しいデータ活用のイメージがいろいろと湧いてきています。ユーザーが楽しい音声コンテンツと出会える場を提供するためにも、もっとデータの活用の幅を広げていきたいと考えています。」（長谷川氏）

株式会社radiko
2010 年設立。スマートフォンやパソコンを使って、時間と場所を選ばずラジオやポッドキャストを聴くことができるサービス「radiko（ラジコ）」を運営する。ラジオの難聴取エリアの解消、リスナーの拡大、若年層への普及のためにスタートし、「タイムフリー」や「エリアフリー」「タイムフリー30」など機能を拡充。今では民放ラジオ全 99 局と、NHK（ラジオ第1・FM）が加盟するメディアプラットフォームとなっている。月間アクティブユーザー数は約 850 万人（2025 年 11 月時点）。

DATUM STUDIO株式会社
（Google Cloud パートナー）
2014 年設立。ビジネスにおけるデータ活用と生成 AI 活用に精通した、経験豊富なデータエンジニア・データサイエンティストが多数在籍するスペシャリスト集団。データ活用に関するコンサルティング、戦略立案から、分析基盤の構築・運用、データ分析、マーケティング活動までを包括的に支援する。特にデータマイニング領域において豊富な経験・技術力を有し、データにあわせた独自のアルゴリズム構築、カスタマイズに定評がある。

インタビュイー（右から）
・株式会社radiko データ統括チームチームリーダー　長谷川史織氏
・DATUM STUDIO株式会社データエンジニアリング本部　信末竜空氏

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

Zeotap: BigQuery ML とベクトル検索が自社の AI モデル構築にどのように役立つか

Thu, 04 Dec 2025 02:00:00 +0000

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

編集者注: この投稿は、色々な組織が Google Cloud 以外のクラウドデータプラットフォームではなく Google Cloud 独自のデータサイエンス機能をどのように活用しているかを紹介するシリーズの一部です。Google Cloud のベクトルエンベディング生成と検索機能は、Google の高度な AI 研究を活用したエンドツーエンドのカスタマイズ可能なプラットフォームであるという点で際立っており、タスクに最適化されたエンベディングモデルやハイブリッド検索などの機能を提供し、セマンティッククエリとキーワードベースのクエリの両方に対して関連性の高い結果を提供します。

Zeotap の顧客インテリジェンスプラットフォーム（CIP）は、ブランドが顧客を理解し、行動を予測して、顧客エンゲージメントを向上させるのに役立ちます。Zeotap は Google Cloud と提携して、プライバシー、セキュリティ、コンプライアンスを提供する顧客データプラットフォームを構築しています。BigQuery で構築された Zeotap CIP を使用すると、デジタルマーケターは AI/ML モデルを構築して使用し、顧客の行動を予測して顧客体験をパーソナライズできます。

Zeotap プラットフォームには、類似オーディエンスの拡張と呼ばれる顧客セグメンテーション機能が含まれています。類似オーディエンスとは、既存の価値の高い顧客ベースと類似した特性や行動を共有する、機械学習アルゴリズムによって特定された新規の見込み顧客のグループです。しかし、ファーストパーティデータがまばらであったり、不完全であったりすると、効果的な類似オーディエンスを作成することが難しくなり、広告アルゴリズムが、類似する新しい見込み顧客を見つけるために必要な、価値の高い顧客の重要な特性を正確に特定できなくなります。このような希少な機能のために、Zeotap は複数の ML 手法を使用しています。これらの手法では、Zeotap のマルチグラフアルゴリズムと高品質のデータアセットを組み合わせて、CDP と類似モデルの間で顧客のオーディエンスをより正確に拡張します。

このブログでは、Zeotap が BigQuery ML やベクトル検索などの BigQuery を使用して、エンドツーエンドの類似ユーザーの問題を解決する方法について詳しく説明します。Google では実用的なアプローチを採用することで、複雑な最近傍探索問題を単純な内部結合問題に変換し、専用のベクトルデータベースを使用せずに、費用、規模、パフォーマンスの課題を克服しました。ここではデータ準備からサービス提供までのワークフローの各ステップを分解し、その過程で BigQuery がどのように主要な課題に対処するかを説明します。ユーザープロファイルデータセットで大部分を占めるカーディナリティの低いカテゴリ列に対処する手法の一つとして、エンベディングを使用したジャカード類似度を紹介します。

フローの概要は次のとおりで、すべて BigQuery エコシステム内で行われます。注: このブログでは、カーディナリティの高い列のフローについては扱いません。

ジャカード類似度

エンベディング空間で最も近いベクトルを返す他の類似性指標がいくつかある中で、Zeotap は、カーディナリティの低い特徴に適合する指標として、ジャカード類似性を好んでいます。これは、2 つの集合間の重複を測定するもので、簡単な式 (A B)/(AB) で表されます。ジャカード類似度は、「2 人のユーザーのいずれかに存在するすべての固有の属性のうち、共有されている属性の割合はどれくらいか？」という質問に答えるものです。少なくとも 1 つのエンティティに存在する特徴（バイナリベクトルの 1 など）のみを考慮し、両方に存在しない属性は無視します。

図式的に示すと次のようになります。

ユーザー	興味 / 関心	バイナリベクトル [映画、スポーツ、音楽、書籍、旅行]	X∩B	X とのジャカード類似度
X	[映画、スポーツ]	[1,1,0,0,0]	-	-
Y	[映画、スポーツ]	[1,1,0,0,0]	2	2/2
Z	[映画、スポーツ、音楽、書籍、旅行]	[1,1,1,1,1]	2	2/5

ジャカード類似度は、エンべディング空間の距離のみを測定する他の多くの複雑な距離指標や類似度インデックスよりもシンプルで説明しやすいため、優れています。まさにオッカムの剃刀です。

実装へのブループリント

ベクトルエンベディングの生成カーディナリティの低い特徴を選択したら、プリミティブ列と配列ベースの列に対して BigQuery のワンホットエンコーディングとマルチホットエンコーディングを使用してベクトルを作成します。

ここでも、サンプルベクトルテーブルを可視化するとわかりやすくなります。

課題: BigQuery ベクトル検索では、ジャカード距離は直接サポートされていない

BigQuery ベクトル検索は、ユークリッド、コサイン、ドット積の 3 つの距離タイプをサポートしていますが、ジャカード距離はサポートしていません（少なくともネイティブには）。ただし、ジャカード距離（1 - ジャカード類似度）が次のようになるバイナリベクトルの選択を表すことができます。

Jd(A,B) = 1 - |A∩B|/|A∪B| = (|A∪B| - |A∩B|)/|A∪B|

ドット積のみを使用すると、次のように書き換えることができます。

つまり、ドット積を使用してジャッカード距離を求めることができます。BigQuery のすぐに使える LP_NORM 関数は、マンハッタンノルムを計算するのに便利です。バイナリベクトルのマンハッタンノルムは、ベクトルとベクトル自身のドット積だからです。つまり、マンハッタンノルム関数を使用することで、BigQuery でサポートされている「ドット積」検索を使用して計算できる方法で、ジャカード距離をサポートできることがわかりました。

ベクトルインデックスの構築

次に、ベクトルインデックスを構築する必要がありました。BigQuery は、IVF（Inverted File Index）と TREE_AH（Tree with Asymmetric Hashing）の 2 つの主要なベクトルインデックスタイプをサポートしており、それぞれ異なるシナリオに合わせて調整されています。TREE_AH ベクトルインデックスタイプは、 Google の ScaNN アルゴリズムをベースに、ツリーのような構造と非対称ハッシュ（AH）を組み合わせています。このアルゴリズムは、さまざまな ANN ベンチマークで優れたパフォーマンスを発揮しています。また、このユースケースは大規模なバッチクエリ（数十万から数百万のユーザーなど）を対象としていたため、他のベクトルデータベースと比較して、レイテンシと費用を削減できました。

類似配信

検索を最適化するベクトルインデックスができたところで、私たちは「BigQuery の VECTOR_SEARCH 関数を使用して直接検索を実行すべきか？」と自問しました。このアプローチを基本テーブルに対して採用したところ、1 社のクライアントだけで 1 億 1,800 万ものユーザーエンコードベクトルが生成されました。さらに、最も重要なこととして、この計算ではデカルト積が必要となるため、インメモリデータサイズがすぐに非常に大きく複雑になりました。すべてのお客様にスケーリングできる戦略を考案する必要がありました。

希少特徴戦略

シンプルながら非常に効果的な戦略は、偏在するユーザーの特徴を検索することを避けることです。2 段階の希少特徴プロセスでは、「遍在する」特徴を特定し、次に、より希少な特徴または判別力のある特徴を少なくとも 1 つ持つユーザーを含む、シグナルが豊富なテーブルを作成します。すぐに、検索スペースを最大 78% 削減できました。BigQuery の VECTOR_SEARCH では、事前フィルタリング を使用してこれを行うことができます。事前フィルタリングでは、サブクエリを使用して検索スペースを動的に縮小します。ただし、サブクエリは従来の結合にすることはできません。そこで、「フラグ」列を導入し、それをインデックスの一部にします。注: 列がインデックスに保存されていない場合、VECTOR_SEARCH の WHERE 句は事後フィルタを実行します。

BQUI またはシステムテーブルを使用して、ベクトルがクエリの高速化に使用されているかどうかを確認する

バッチ戦略

ベクトル検索では、クエリユーザー（N、ターゲットとするユーザー）とベースユーザー（M、ユーザープール全体、この場合は 1 億 1,800 万人）を比較します。複雑さは（M × N）で増加するため、大規模な検索はリソースを大量に消費します。これを取り扱うために、N クエリのユーザーにバッチを適用し、これらをグループごと（例: バッチあたり 500,000）に処理し、M はベースセット全体としました。このアプローチにより、計算負荷が軽減され、各クエリユーザーの上位 100 人の類似ユーザーを効率的にマッチングできるようになりました。次に、グリッド検索を使用して、大規模な要件に最適なバッチサイズを決定しました。

まとめ

Google Cloud とのパートナーシップにより、デジタルマーケターは AI/ML モデルを構築して使用し、顧客セグメンテーションとパーソナライズされたエクスペリエンスを実現して、コンバージョン率の向上と顧客獲得費用の削減を推進できます。BigQuery ベクトル検索ではジャカード距離が直接サポートされていないという課題に対処するため、ドット積とマンハッタンノルムを使用しました。BigQuery ML とベクトルサービスを活用したこの実用的なアプローチにより、1 つの SQL スクリプトだけでカスタムの類似ユーザーモデルを作成し、専用のベクトルデータベースを使用せずに費用、規模、パフォーマンスの課題を克服できました。

BigQuery ML とベクトルサービスを、堅牢なサーバーレスアーキテクチャと組み合わせて使用することで、個々の顧客のドメインとニーズに対応するカスタムの類似ユーザーモデルをリリースできました。Zeotap と Google Cloud は、マーケターがどこでもリーチを拡大できるよう支援するパートナーシップを期待しています。

ISV とデータプロバイダにとっての Built with BigQuery のメリット

Built with BigQuery は、BioCorteX などの企業による、Google のデータクラウドを活用した革新的なアプリケーション構築のお役に立ちます。参加企業には以下のメリットがあります。

専任のエキスパートから、重要なユースケース、アーキテクチャパターン、ベストプラクティスに関するインサイトを得ることによって、プロダクトの設計とアーキテクチャの構築を加速できます。
共同マーケティングプログラムを利用して、認知度の向上、需要の創出、導入の拡大を図り、より大きな成功を実現できます。

BigQuery は、Google Cloud のオープンかつ安全でサステナブルなプラットフォームに統合された、パワフルでスケーラビリティの高いエージェント時代の統合データクラウドのメリットを ISV に提供します。Built with BigQuery の詳細については、こちらをクリックしてください。

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

-Zeotap、最高技術責任者、Sathish KS 氏

新しいコネクタや機能で拡張する BigQuery Data Transfer Service

Wed, 03 Dec 2025 01:02:00 +0000

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

BigQuery の目標は、データの量や出所にかかわらず、データから貴重な分析情報を抽出できるようにすることです。これを実現するうえで重要な役割を担うのが BigQuery Data Transfer Service です。このサービスは、さまざまなソースから BigQuery へのデータ読み込みを自動化し、効率化します。

フルマネージドサービスである BigQuery Data Transfer Service には、次のようなメリットがあります。

シンプル: インフラストラクチャ管理や複雑なコーディングは不要です。UI、API、CLI のいずれからでも、簡単にデータ読み込みを開始できます。
スケーラビリティ: 毎月何万ものお客様が使用する Data Transfer Service は、大量のデータや多数の同時ユーザーを容易に処理でき、負荷の高いデータ転送ジョブにも対応します。
セキュリティ: データの安全性は非常に重要です。Data Transfer Service では、暗号化、認証、認可などの堅牢なセキュリティ対策が採用されています。以下のように、使いやすさを損なうことなく、規制対象のワークロードをサポートする機能も大幅に拡張されています。
費用対効果: Google 広告や YouTube など、多くのファーストパーティコネクタが無料で提供されています。また、サードパーティコネクタの数も増え続ける中、Google では価格競争力の高い使用量ベースの料金を提供しているため、費用対効果の高い方法でデータを統合できます。

さらに、お客様からのフィードバックを基に、BigQuery Data Transfer Service コネクタのエコシステムを拡張しました。あわせて、セキュリティとコンプライアンスを強化するとともに、全体的なユーザーエクスペリエンスも向上させています。最新のアップデートを詳しく見ていきましょう。

主な機能のアップデート

データ接続の拡張

このたび、ご要望の多かったコネクタの一般提供が開始されました。

Oracle: 主要な運用データベースを BigQuery と統合し、分析とレポート作成を強化します。
Salesforce および ServiceNow: 統合された顧客プロファイルを作成し、IT サービス管理データを活用して、運用に関する分析情報を取得します。
Salesforce Marketing Cloud（SFMC）および Facebook 広告: マーケティングと分析のデータを BigQuery に取り込み、包括的な分析とキャンペーンの最適化を実現します。
Google アナリティクス 4（GA4）: マーケティング分析における大きなマイルストーンです。GA4 データを使用して、本番環境のマーケティング分析パイプラインを構築できるようになりました。

これらの新しいコネクタは、Amazon S3、Amazon Redshift、Azure Blob Storage、キャンペーンマネージャー、Cloud Storage、ショッピング比較サービス（CSS）センター、ディスプレイ＆ビデオ 360、Google アドマネージャー、Google 広告、Google Merchant Center、Google Play、MySQL、PostgreSQL、検索広告 360、Teradata、YouTube チャンネル、YouTube コンテンツ所有者など、急速に増え続ける既存のコネクタのリストに追加されます。

プレビュー版の新しいコネクタ

また、エコシステムをさらに拡張する新しいコネクタのプレビュー版もリリースします。

Stripe および PayPal: 財務データやトランザクションデータを BigQuery に取り込み、収益分析、払い戻しの追跡、顧客行動の分析情報に活用します。
Snowflake（移行用コネクタ）: 鍵ペア認証、スキーマの自動検出、3 つの主要クラウド（Google Cloud、AWS、Azure）に保存されているデータの移行サポートなどの機能を使用して、Snowflake からデータを移行します。
Hive マネージドテーブル（移行用コネクタ）: このコネクタは、オンプレミスおよび自己ホスト型クラウドの Hadoop 環境から Google Cloud へ、Hive および Iceberg のメタデータとテーブルの移行をサポートします。これにより、Hive テーブルと Iceberg テーブルの 1 回限りの移行や増分アップデートの同期を実行できます。Iceberg テーブルは BigLake Metastore に登録され、Hive テーブルおよび Iceberg テーブルは Dataproc Metastore に登録されます。

既存のコネクタとプラットフォーム機能の強化

Google Cloud Storage: イベントドリブン転送の GA が開始されました。新しいファイルが Cloud Storage バケットに到着すると、データ転送が自動的にトリガーされるため、準リアルタイムのデータパイプラインを実現できます。
Salesforce: CRM ユーザーは、プレビュー版で利用可能になった増分取り込みにより、効率を向上できます。Data Transfer Service は、新規または変更されたレコードのみをインテリジェントに読み込むため、時間とコンピューティングリソースを節約できます。
検索広告 360: 最近更新された検索広告 360 コネクタで、P-MAX キャンペーンが完全にサポートされるようになりました。Google の最新のキャンペーンタイプからデータを分析できます。
Google アドマネージャー: DT ファイルの増分アップデートを展開することで、Google アドマネージャーコネクタのデータ鮮度を向上させました。Google アドマネージャーは、Google アドマネージャー DT ファイルを Cloud Storage バケットに追加します。転送の実行では、すでに転送されているファイルを再読み込みするのではなく、Cloud Storage バケットから BigQuery テーブルに新しい Google アドマネージャー DT ファイルを増分読み込みします。
Google 広告: Google 広告のカスタムレポートの GA が開始されました。これにより、転送構成で Google 広告クエリ言語（GAQL）によるクエリを使用して、標準レポートや既存のフィールドでは利用できないカスタム Google 広告レポートおよびフィールドを取り込むことができます。
Oracle: Oracle コネクタを大幅に強化し、数百万件のレコードを含むテーブルを取り込めるようになりました。これにより、大規模かつ重要なデータセットも BigQuery に転送できます。

セキュリティとコンプライアンスの強化

Google は、お客様の厳格なセキュリティとコンプライアンスのニーズに応えるため、インフラストラクチャへの投資を強化しています。

アクセスの透明性: BigQuery と連携し、Data Transfer Service の管理者権限の制御範囲を、お客様が特定できるメタデータにまで拡張しました。管理者権限の制御（アクセスの透明性、アクセス承認、担当者管理）は、Google の担当者がユーザーコンテンツにアクセスした日時、理由、方法をリアルタイムで通知する Cloud サービスの機能です。この新機能は、顧客が定義した属性の読み取りや、顧客またはそのワークロードを識別できるあらゆるカスタマーサービス構成に対して、アクセスの透明性管理を適用します。
EU のデータ境界: EU のデータ境界と主権管理コンプライアンスプログラムに対応した Data Transfer Service の GA が発表されました。これには、アクセス正当化によるデータ境界の管理や、パートナーによる主権管理を備えた EU リージョンのサポートが含まれます。これにより、お客様は規制対象の市場においても、Google Cloud 上でワークロードを拡張できます。
FedRAMP High: Data Transfer Service を FedRAMP High コンプライアンスレジームでリリースするために必要なセキュリティ管理を実装しました。これにより、米国政府機関、民間機関、請負業者は、Google Cloud 上で FedRAMP High 規制対象のワークロードの導入を拡張できるようになります。
CJIS コンプライアンス: 刑事司法情報サービス（CJIS）のコンプライアンスに対応した BigQuery Data Transfer Service をリリースしました。Data Transfer Service が CJIS セキュリティポリシーのセキュリティ基準を満たしたことで、米国の州、地方、部族の法執行機関および刑事司法機関は、Google のサービスを使用して機密情報を処理できるようになりました。
カスタムの組織のポリシー: カスタムの組織ポリシーの GA が発表されました。これにより、Data Transfer Service 転送構成に対する特定のオペレーションを許可または拒否することで、組織のコンプライアンスおよびセキュリティの要件を満たすことができます。
リージョンエンドポイント: Data Transfer Service API のリージョンエンドポイントが利用可能になりました。リージョンエンドポイントは、指定したロケーションにリソースが存在する場合にのみリクエストを処理するエンドポイントです。これにより、ワークロードは保存データと転送データを指定したロケーション内に保持し、データ所在地とデータ主権の要件を遵守できます。
鍵トラッキング: 鍵の使用状況トラッキングにより、各 Cloud KMS 鍵で保護されているストレージリソースを確認できるようになりました。詳細については、鍵の使用状況を表示するをご覧ください。
プロアクティブな脅威の軽減: Google は最近、BigQuery Data Transfer Service 全体を対象に、詳細かつプロアクティブな脅威モデリング演習を完了しました。この詳しいレビューにより、優先度の高いセキュリティリスクを特定して軽減するとともに、潜在的な脅威に対するプラットフォームの堅牢性をさらに強化しました。

直感的で統合されたユーザーエクスペリエンス

Google は、シンプルかつ直感的なデータの取り込みを実現するため、BigQuery のユーザーエクスペリエンスに多大な投資を行ってきました。

BigQuery UI の「データを追加」エクスペリエンスは、データ読み込みプロセスをガイドする単一の簡素化されたエントリポイントを提供します。経験豊富なデータエンジニアでも、新任のアナリストでも、このウィザード形式のワークフローにより、あらゆるソースからの転送を簡単に検出して構成できます。これにより、当て推量がなくなり、迅速に分析情報が得られます。

最後に、設定プロセスをさらに合理化するため、新しい BigQuery プロジェクトでは、BigQuery Data Transfer Service API がデフォルトで有効になりました。これにより手動の設定作業が不要となり、BigQuery 利用開始直後からデータ転送機能をすぐに利用できます。

使用量ベースの新しい料金モデル

サードパーティコネクタがプレビュー版から GA 版へ移行するのに伴い、Google は、プロダクションレディな完全サポートサービスとしての位置づけを反映した新しい料金モデルを導入しました。

この新しい使用量ベースのモデルは、サードパーティの SaaS およびデータベースコネクタ（Salesforce、Facebook 広告、Oracle、MySQL など）を対象としており、特定のコネクタが一般提供された時点で適用されます。

モデルの詳細:

プレビュー期間中は無料: プレビュー期間中は、すべてのコネクタを無料でご利用いただけます。これにより、金銭的コミットメントなしで、新しい統合をテスト、実験、検証できます。
競争力のある価格設定: 競争力の高い料金体系により、重要なソースから効率的にデータを取り込めます。
使用量ベース: 料金はデータ転送で消費されたコンピューティングリソースに応じて決まります。使用量はスロット時間で測定されます。

この変更により、Google は、堅牢でスケーラブルなデータ転送プラットフォームの構築に引き続き投資できます。詳細については、BigQuery の料金ページをご覧ください。

今後の対応

取り組みの継続Google は、データパイプラインを合理化し、新たなレベルの分析情報を引き出す機能の構築に取り組んでいます。プレビュー版の幅広いコネクタのリストが示すように、Google は移行、マーケティング分析、オペレーショナルデータベース、エンタープライズアプリケーションの分野で引き続き迅速なイノベーションを推進します。

BigQuery Data Transfer Service の力を体感してください。データ読み込みプロセスを簡素化し、より短時間で分析情報を取得できます。BigQuery Data Transfer Service の今後のプロダクト発表のお知らせや最新情報をご希望の方は、メールグループ（https://groups.google.com/g/bigquery-dts-announcements）にご登録ください。

また、公開バグトラッカーを通じてフィードバックを共有し、機能リクエストを提出していただくこともできます。具体的には、BigQuery に関する新しい不具合や問題をご報告ください。

-Google、シニアプロダクトマネージャー、Piotr Wieczorek
-Google、エンジニアリングマネージャー、Artur Pop

BigQuery

Google Cloud Knowledge Catalog のご紹介

集約: データアセット全体でコンテキストを統合

拡充: 継続的な学習を通じて意味を生成する

検索: 高精度で安全なデータ取得によるエージェント活用の拡大

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

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

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

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

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

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

エージェンティック時代を支える BigQuery の新機能

オープンかつ境界なきクロス クラウドレイクハウスの実現

エンタープライズ エージェントのためのグラフベースの推論

構造化、非構造化データの価値を引き出すネイティブな AI 処理

エージェンティックな体験

圧倒的なパフォーマンスとスケール

BigQuery Graph と Kineviz GraphXR で企業ナレッジの非構造化データを拡張

BigQuery で、断片化されたデータを統合

BigQuery パイプライン: 非構造化データから構造化データへ

Kineviz GraphXR で隠れた分析情報を引き出す

メリット

始める

BigQuery Graph のご紹介: データに潜む関係性を明らかに

業界を問わず企業が直面するグラフ導入の課題

BigQuery Graph の主なユースケース

実際の BigQuery Graph の活用事例

BigQuery Graph の使い方

準備ができたら

Gemini アシスタントの強化により、BigQuery Studio がこれまで以上に便利に

1. コンテキスト アウェアな相互運用性

2. インテリジェントなリソース検出

3. ジョブの即時分析とトラブルシューティング

TVer: 日本最大級の動画配信プラットフォームを支える広告基盤を Google Cloud で内製化

事業成長を加速させるため、ビジネスの心臓部である広告サーバーの内製化を決断

GKE と、Memorystore、Bigtable の適材適所な併用。技術的難題を突破した PSO の支援

安定と革新を両立した配信基盤を武器に、さらなる視聴体験の向上を目指す

BigQuery の自律型エンべディング生成で AI ワークフローを簡素化

エンベディングの管理（従来の方法）

解決策: 自律的に生成されるエンベディング列

ベクトル インデックスやベクトル検索との統合

AI.SEARCH の導入

シンプルな管理

今後の予定

イオンフィナンシャルサービス: BigQuery を軸に全社横断的なデータ分析基盤を構築し、緻密な 1 to 1 マーケティングを強化

緻密な 1 to 1 マーケティングに不可欠な、全社横断型データ マネジメント基盤

膨大な量のデータを高速かつ柔軟に扱える BigQuery をシステム構築の柱に

組織と働き方を変える真の DX、さらには決済サービスのグローバル化も推進

新しい BigQuery グローバル クエリで、単一の SQL ステートメントを使用して分散データを探索

グローバル クエリとは

グローバル クエリの活用

今すぐグローバル クエリを始めましょう

ユーフォリア: Gemini で AI マルチ エージェントを構築し、最先端のスポーツ科学の知見とデータを、すべての人々の健康づくりに活用

トップスポーツの分野で得られたノウハウを、いかに還元していくか

BigQuery と Gemini の導入で実現した、ビジネスモデルの進化

AI エージェントの活用がもたらす、社会全体のエンパワーメント

BigQuery の会話型分析のご紹介

データ プロフェッショナル向けのデータ分析情報を会話形式で提供

質問から信頼できる回答の取得まで数秒

クエリの先へ: 次の展開を数秒で予測する

非構造化データの価値を引き出す

エージェントに命を吹き込む

今すぐデータ分析を変革する

BigQuery AI: Gemini 3.0 対応、エンベディング生成の簡素化、新しい類似度関数

EUC による合理化された設定

一般提供版の次世代テキストと構造化生成関数

エンベディング生成と類似度計算のための新しい簡素化された関数

Gemini 3.0 のサポート

使ってみる

オープンモデルに対する BigQuery マネージド SQL ネイティブ推論の導入

自動管理による SQL ネイティブのワークフロー

仕組み: 実例

使ってみる

BigQuery のフルマネージド リモート MCP サーバーでデータ分析エージェントを迅速に構築

ADK で BigQuery MCP サーバーを使用する

手順 1: 前提条件 > 構成と環境

手順 2: 構成 > ユーザーロールと API

手順 3: サンプル データセットを読み込む > cymbal_pets データセット

手順 4: OAuth クライアント ID を作成する

手順 5: Gemini の API キー

オープンかつ境界なきクロスクラウドレイクハウスの実現

エンタープライズエージェントのためのグラフベースの推論

1. コンテキストアウェアな相互運用性

ベクトルインデックスやベクトル検索との統合

緻密な 1 to 1 マーケティングに不可欠な、全社横断型データマネジメント基盤

新しい BigQuery グローバルクエリで、単一の SQL ステートメントを使用して分散データを探索

グローバルクエリとは

グローバルクエリの活用

今すぐグローバルクエリを始めましょう

ユーフォリア: Gemini で AI マルチエージェントを構築し、最先端のスポーツ科学の知見とデータを、すべての人々の健康づくりに活用

データプロフェッショナル向けのデータ分析情報を会話形式で提供

BigQuery のフルマネージドリモート MCP サーバーでデータ分析エージェントを迅速に構築

手順 3: サンプルデータセットを読み込む > cymbal_pets データセット

手順 6: ADK ウェブアプリケーションを作成する

従来のシステムでは限界に達していた処理能力とランニングコスト

ベクトルインデックスの構築

ISV とデータプロバイダにとっての Built with BigQuery のメリット