BigQuery

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

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

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

さらに、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 0x7f3d82c9b5b0>)])]>

シンプルな管理

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

エンベディングステータスメタデータ: テーブル内の 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 0x7f3d82c9b6a0>)])]>

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

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

ご覧のとおり、これはすべて標準 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 0x7f3d62e490a0>)])]>

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

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

続けて、次のクエリを実行します。このクエリでは、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 0x7f3d62e49d90>)])]>

結果は次のようになります。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 0x7f3d62e49f70>)])]>

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

さらに、新しい 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 0x7f3d62e49100>)])]>

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

これは、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 0x7f3d782969a0>)])]>

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

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

負荷の高いワークロードの場合は、デプロイ設定（マシンタイプ、レプリカ数、エンドポイントのアイドル時間）をカスタマイズすることで、スケーラビリティを向上させ、費用を管理できます。また、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 0x7f3d84cad220>)])]>

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

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

モデルを使い終わったら、後は削除するだけです。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 0x7f3d84cad7f0>)])]>

使ってみる

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

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

手順 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 0x7f3d80345c40>)])]>

手順 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 0x7f3d8028ed60>)])]>

手順 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 0x7f3d8028e5e0>)])]>

注 [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 0x7f3d8028ee20>)])]>

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

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

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

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

ブラウザを起動し、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 0x7f3d8028ebe0>)])]>

次に、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 0x7f3d83c87d00>)])]>

Gemini CLI を実行します。

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

エージェント用の 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 の新しい MATCH_RECOGNIZE 関数なら可能です。

Thu, 27 Nov 2025 01:03:00 +0000

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

データ内のパターンとシーケンスを特定することは、より深いインサイトを得るために非常に重要です。ユーザー行動の追跡、金融取引の分析、センサーデータのモニタリングなど、各イベントの具体的なシーケンスを認識する機能で、豊富な情報と行動につながるインサイトを引き出すことができます。

あなたは e コマース企業のマーケティング担当者として、購入履歴から最も価値の高い顧客を特定しようとしているとします。少額の注文から始めて中程度の購入に進む顧客は、最終的には高額購入者となり、最も忠実なセグメントになることをあなたは知っています。このデータを集計して結合する複雑な SQL を考え出すのは、非常に難しい作業です。

そこで、BigQuery の新機能である MATCH_RECOGNIZE をご紹介します。この新機能では、SQL クエリ内で直接、データに対して複雑なパターンマッチングを実行できます。

MATCH_RECOGNIZE とは

MATCH_RECOGNIZE は、基本的には指定されたパターンに一致する行のシーケンスを識別するために GoogleSQL に直接組み込まれたツールです。正規表現の使用に似ていますが、テキスト文字列のパターンとの一致を見るのではなく、テーブル内の行のシーケンスのパターンとの一致を検出することになります。この機能は、時系列データや、行の順序が重要なデータセットを分析する際に特に効果を発揮します。

MATCH_RECOGNIZE を使用すると、複雑なパターンを表現し、それらを分析するカスタムロジックを定義でき、これらすべてを 1 つの SQL 句内で行えます。これにより、煩雑な自己結合や複雑な手続き型ロジックの必要性が軽減されます。また、データの処理で Python に依存する度合いが低くなり、Teradata の nPath やその他の外部の MATCH_RECOGNIZE ワークロード（Snowflake、Azure、Flink など）の経験があるユーザーには使い慣れたものになります。

仕組み

MATCH_RECOGNIZE 句は高度に構造化されており、パターンマッチングロジックを定義するために連携するいくつかの主要コンポーネントで構成されています。

PARTITION BY: この句は、データを独立したパーティションに分割し、各パーティション内で別個にパターンマッチングを実行できるようにします。
ORDER BY: 各パーティション内で、ORDER BY は行を並べ替えて、パターンが評価される順序を確立します。
メジャー: ここでは、出力に含める列を定義できます。多くの場合、集計関数を使用して、一致したデータを要約します。
PATTERN: これは MATCH_RECOGNIZE 句の中核となる部分で、一致を構成する記号のシーケンスを定義します。「*」、「+」、「?」などの数量詞を使用して、各記号の出現回数を指定できます。
DEFINE: この句では、パターン内の特定の記号として分類されるために行が満たす必要のある条件を定義してください。

簡単な例を見てみましょう。上記の架空のシナリオから、販売データのテーブルがあるとします。マーケティングアナリストとして、顧客の購入パターンを特定したいと考えています。そのパターンとは、支出が最初は低く、中程度の範囲に増加し、その後高レベルに達するというものです。MATCH_RECOGNIZE を使用すると、次のようなクエリを記述できます。

code_block: <ListValue: [StructValue([('code', 'SELECT *\r\nFROM\r\n Example_Project.Example_Dataset.Sales\r\nMATCH_RECOGNIZE (\r\n PARTITION BY customer\r\n ORDER BY sale_date\r\n MEASURES\r\n MATCH_NUMBER() AS match_number,\r\n ARRAY_AGG(STRUCT(MATCH_ROW_NUMBER() AS row, CLASSIFIER() AS symbol, \r\n product_category)) AS sales\r\n PATTERN (low+ mid+ high+)\r\n DEFINE\r\n low AS amount < 50,\r\n mid AS amount BETWEEN 50 AND 100,\r\n high AS amount > 100\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d8355d400>)])]>

この例では、データを顧客ごとにパーティション分割し、sale_date で並べ替えています。PATTERN 句は、1 つ以上の「低」売上イベント、その後に 1 つ以上の「中」売上イベント、その後に 1 つ以上の「高」売上イベントを探すように指定します。DEFINE 句では、販売額が「低」、「中」、「高」と見なされる条件を指定します。MEASURES 句は、各一致をどのように要約するかを決定します。ここでは、match_number を使用して、1 から始まる各一致にインデックスを付け、すべての一致を順番に追跡する「sales」配列を作成します。

以下は、マッチしたお客様の例です。

customer	match_number	sales.row	sales.symbol	sales.product_category
`Cust1`	`1`	`1`	`low`	`Books`
		`2`	`low`	`Clothing`
		`3`	`mid`	`Clothing`
		`4`	`high`	`Electronics`
		`5`	`high`	`Electronics`
`Cust2`	`2`	`1`	`low`	`Software`
		`2`	`mid`	`Books`
		`3`	`high`	`Clothing`

このデータは、いくつかの販売傾向を浮き彫りにしています。市場アナリストは、これらの傾向に基づいて、支出額の少ない顧客をより価値の高い販売に転換するための戦略を立てるためのインサイトを得ることができます。

MATCH_RECOGNIZE のユースケース

MATCH_RECOGNIZE の可能性は広大です。この強力な機能の使用例をいくつかご紹介します。

ファネル分析: ウェブサイトやアプリでのユーザージャーニーを追跡して、よくある経路と離脱ポイントを特定します。たとえば、コンバージョンプロセスの成功パターン（view_product -> add_to_cart -> purchase など）を定義し、それを完了したユーザーの数を分析できます。
不正行為の検出: 不正行為の可能性を示す疑わしい取引パターンを特定します。たとえば、新しいアカウントから、少額の取引が複数回行われた後に高額の取引が行われるパターンを探すことができます。
財務分析: 株式市場のデータを分析して、W 字回復や V 字回復などの傾向やパターンを特定します。
ログ分析: アプリケーションログを精査して、エラーやセキュリティ上の脅威を示す可能性のある特定のイベントシーケンスを見つけます。
離脱分析: 顧客の離脱につながるデータ内のパターンを特定し、離脱を減らして顧客のセンチメントを改善するための行動につながるインサイトを見つけます。
ネットワークモニタリング: 連続したログインの失敗を特定して、問題や、潜在的な脅威を追跡します。
サプライチェーンのモニタリング: 一連の出荷イベントの遅延にフラグを立てます。
スポーツ分析: 連勝や連敗、先発メンバーの変更など、試合ごとのさまざまな選手やチームの成績の連勝や変化を特定します。

使ってみる

では、ご自身のクエリで MATCH_RECOGNIZE を使ってみましょう。この機能は、すべての BigQuery ユーザーに現在ご利用いただけます。構文と高度な機能についての詳細は、Colab、BigQuery、GitHub で利用できる公式のドキュメントとチュートリアルをご覧ください。

MATCH_RECOGNIZE は、BigQuery でのシーケンシャル分析の可能性を広げるものであり、お客様にはこの機能でご自身データからより深い分析情報を引き出していただきたいと思っています。

-クラウドデータコンサルタント、Annie Leindecker
-BigQuery ソフトウェアエンジニア、Sarah Kwon

Data Cloud の TimesFM: BigQuery と AlloyDB における予測の未来

Fri, 21 Nov 2025 03:00:00 +0000

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

Google は、TimesFM を Google の主要なデータプラットフォームである BigQuery と AlloyDB に統合することを発表いたします。これにより、大規模な事前トレーニング済み予測モデルの能力が Google Data Cloud 内のデータに直接もたらされ、将来のトレンドをかつてないほど簡単かつ正確に予測できるようになります。

TimesFM は、Google Research が開発した強力な時系列基盤モデルで、4,000 億を超える実世界のタイムポイントの膨大なデータセットで事前トレーニングされています。この広範なトレーニングにより、TimesFM は「ゼロショット」予測を実行できます。つまり、再トレーニングしなくても、特定のデータに対して正確な予測を生成できます。予測モデルの作成とデプロイのプロセスが大幅に簡素化されるので、時間とリソースを節約できます。

では、これが BigQuery と AlloyDB でどのような意味を持つのかを見ていきましょう。

BigQuery の TimesFM

Google は、Google Cloud Next ‘25 で AI.FORECAST 関数のプレビュー版をリリースしました。今回発表する内容は以下のとおりです。

AI.FORECAST と AI.EVALUATE の一般提供（GA）が開始されました。
AI.DETECT_ANOMALIES が公開プレビュー版で利用可能になりました。
AI.FORECAST は、以下を含む複数のオープンソースフレームワークでサポートされています。

では、これらについて詳しく見ていきましょう。

AI.FORECAST と AI.EVALUATE

GA リリースに含まれる主なアップグレードは以下のとおりです。

TimesFM 2.5 がサポートされるようになりました。「model => “TimesFM 2.5”」を指定すると、最新の TimesFM モデルを使用して、予測精度の向上とレイテンシの短縮を実現できます。
AI.FORECAST は最大 15,000 の動的コンテキストウィンドウをサポート: 「context_window」を指定することで、64 から 15,000 までの複数のコンテキストウィンドウがサポートされます。指定しない場合は、時系列入力サイズに一致するように 1 つのコンテキストウィンドウが選択されます。
AI.FORECAST は履歴データの表示をサポート: 「output_historical_time_series」を true に設定することで、予測とともに履歴データを表示できます。このオプションを使用すると、より簡単かつ優れたビジュアリゼーションが可能になり、ユーザビリティが向上します。
モデル評価用に AI.EVALUATE が追加されました。予測値の精度を評価するために実際のデータを指定できます。

以下の例では、TimesFM 2.5 モデルを使用し、AI.FORECAST で context_window = 1024 を指定して、最新の 1024 ポイントを履歴データとして使用できます。output_historical_time_series = true を指定すると、予測とともに履歴データが表示されます。

code_block: <ListValue: [StructValue([('code', "WITH citibike_trips AS (\r\n SELECT EXTRACT(DATE FROM starttime) AS date, COUNT(*) AS num_trips\r\n FROM `bigquery-public-data.new_york.citibike_trips` GROUP BY date)\r\nSELECT *\r\nFROM\r\n AI.FORECAST(\r\n TABLE citibike_trips, -- History Table\r\n data_col => 'num_trips',\r\n timestamp_col => 'date',\r\n horizon => 300,\r\n output_historical_time_series => TRUE,\r\n model => 'TimesFM 2.5',\r\n context_window => 1024);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d83518be0>)])]>

最初の 10 日間の予測値は以下のとおりです。

[可視化] タブをクリックして結果を可視化することもできます。結果は以下のようになります。

以下の AI.EVALUATE の例では、「2016-08-01」より前のデータを履歴として使用し、「2016-08-01」以降の実際のデータと予測された自転車の利用状況を比較して評価できます。

code_block: <ListValue: [StructValue([('code', 'WITH citibike_trips AS (\r\n SELECT EXTRACT(DATE FROM starttime) AS date, usertype, COUNT(*) AS num_trips\r\n FROM `bigquery-public-data.new_york.citibike_trips` GROUP BY date, usertype)\r\nSELECT * \r\nFROM\r\n AI.EVALUATE(\r\n (SELECT * FROM citibike_trips WHERE date < \'2016-08-01\'), -- History time series\r\n (SELECT * FROM citibike_trips WHERE date >= \'2016-08-01\'), -- Actual time series\r\n data_col => \'num_trips\',\r\n timestamp_col => \'date\',\r\n id_cols => ["usertype"]);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d835183d0>)])]>

SQL は、各「usertype」に基づいて評価指標を生成します。

AI.DETECT_ANOMALIES

AI.DETECT_ANOMALIES を追加すると、予測値に対する異常を検出するターゲットデータを指定できます。

以下の AI.DETECT_ANOMALIES の例では、「2016-08-01」より前のデータを履歴として使用し、「2016-08-01」以降のターゲットデータで異常を検出できます。

code_block: <ListValue: [StructValue([('code', 'WITH citibike_trips AS (\r\n SELECT EXTRACT(DATE FROM starttime) AS date, usertype, COUNT(*) AS num_trips\r\n FROM `bigquery-public-data.new_york.citibike_trips` GROUP BY date, usertype)\r\nSELECT * \r\nFROM\r\n AI.DETECT_ANOMALIES(\r\n (SELECT * FROM citibike_trips WHERE date < \'2016-08-01\'), -- History time series \r\n (SELECT * FROM citibike_trips WHERE date >= \'2016-08-01\'), -- Target time series\r\n data_col => \'num_trips\',\r\n timestamp_col => \'date\',\r\n id_cols => ["usertype"]);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d83518f70>)])]>

SQL は、「2016-08-01」以降の各データポイントについて、ユーザータイプごとの異常を生成します。結果の 10 行の例は以下のとおりです。

AlloyDB の TimesFM

AI.FORECAST がAlloyDB でプレビュー版として利用可能になりました。AlloyDB 内から直接予測を行うための TimesFM の組み込みサポートが提供されます。これにより、データをエクスポートすることなく、販売予測、在庫需要予測、運用負荷モデリングなどのユースケースで、運用データと分析データを活用して予測を行うことができます。

AlloyDB を使用した売上予測

AlloyDB に保存されたデータを活用して売上を予測する方法の例を見てみましょう。従来は、AlloyDB からデータを抽出してデータサイエンス環境に取り込み、予測モデルをデプロイしてモデルの予測を実行し、その予測を保存するために、ETL パイプラインを設定して維持する必要がありました。しかし、時間的制約のあるアプリケーションの場合、これらの手順はコストがかかる可能性があります。

代わりに、運用ワークロードに AlloyDB を活用すると仮定します。販売、在庫、価格のデータとメタデータは、retail_sales というテーブルに保存してあります。先週の売上は把握していますが、来週の売上を予測して、需要に応じて計画を立てたいと考えています。

AlloyDB の最新の統合により、わずか 2 つの簡単なステップで開始できます。

1. モデルを登録します。モデルがホストされている Vertex AI エンドポイントを指すように、AlloyDB のモデルエンドポイント管理内のモデルエンドポイントとして TimesFM モデルを登録します。これにより、AlloyDB は時系列データを安全にモデルに送信し、予測を受け取ることができます。以下の例では、Vertex AI にデプロイされた TimesFM モデルを指定し、モデル ID として「timesfm_v2」を選択します。

code_block: <ListValue: [StructValue([('code', "CALL\r\n ai.create_model(\r\n model_id => 'timesfm_v2',\r\n model_type => 'ts_forecasting',\r\n model_provider => 'google',\r\n model_qualified_name => 'timesfm_v2',\r\n model_request_url => ‘https://<REGION>-aiplatform.googleapis.com/v1/projects/<PROJECT_ID>/locations/<REGION>/endpoints/<ENDPOINT_ID>:predict’ -- endpoint in Vertex AI Model Garden\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d835181c0>)])]>

2. AI.FORECAST で予測を生成します。モデルを登録すると、AI.FORECAST 関数を利用できます。この関数は、時系列データと予測パラメータ（予測期間など）を受け取り、予測値を返します。

以下の例では、データベースに保存されている販売データに基づいて、信頼レベル 0.80 で次の 11 日間の販売を予測します。

code_block: <ListValue: [StructValue([('code', "SELECT * FROM ai.forecast(\r\n model_id => 'timesfm_v2',\r\n source_table => 'retail_sales',\r\n data_col => 'sales',\r\n timestamp_col => 'timestamp',\r\n horizon => 11,\r\n conf_level => 0.8\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d83518640>)])]>

この統合アプローチにより、データを高性能な AlloyDB インスタンス内に安全に保持し、Google の最先端の予測機能をすぐに活用できます。AlloyDB の低レイテンシと TimesFM のゼロショット予測機能により、運用ワークロードのリアルタイム予測分析が実現します。Google の統合について詳しくは、こちらのブログ投稿をご覧ください。

エージェントと MCP での AI.FORECAST

SQL インターフェースを介した TimesFM（AI.FORECAST）のサポートに加えて、Agent Development Kit（ADK）、データベース向け MCP ツールボックス、Google Data Cloud 向け Gemini CLI 拡張機能などのエージェントインターフェースを介して、BigQuery と AlloyDB で TimesFM の予測機能を活用できます。

BigQuery の組み込み予測ツールを使用する

このブログ投稿では、ADK の組み込み BigQuery 予測ツール（TimesFM を使用）でエージェントを記述し、データを使用した予測タスクを実行する方法を紹介しています。以下に示すのは、ADK で構築されたエージェントを使用して自然言語で予測タスクを実行する方法の一例です。

このブログ投稿では、MCP 拡張機能をインストールして設定し、Gemini CLI で BigQuery 予測ツールを使用する方法について説明しています。

次のステップ

TimesFM モデルが BigQuery で一般提供されました。詳しくは、チュートリアルと、AI.FORECAST、AI.EVALUATE、AI.DETECT_ANOMALIES のドキュメントをご覧ください。また、AlloyDB で TimesFM の使用を開始することもできます。

-BigQuery ML、ソフトウェアエンジニア Haiyang Qi

-AlloyDB、プロダクトマネージャー Tabatha（Tabby） Lewis-Simo

BigQuery の仕組み: Google がエンべディングを分析に導入した方法

Tue, 18 Nov 2025 03:00:00 +0000

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

エンべディングは、データと AI が交差する場所にある重要なコンポーネントであり、データ構造として、それらが表すデータの固有の意味をエンコードします。その重要性は互いに比較すると明らかになります。ベクトル検索は、共有スペース内のエンベディング間の距離を評価することで、それらの相対的な意味を明らかにする手法です。

2024 年初頭、Google は BigQuery データプラットフォームでベクトル検索をリリースし、その高度な機能をすべての BigQuery ユーザーが利用できるようにしました。これにより、専用のデータベースや複雑な AI ワークフローが効率的に除外されました。Google はベクトル検索を普及させるための継続的な取り組みを通じて、BigQuery のユーザーが期待するスケーリング、簡素性、費用対効果を実現する独自のアプローチを開発しました。この記事ではこの 2 年間を振り返りながら、プロダクト開発とお客様とのやり取りから得られた知見をご紹介します。

過去: 困難なベクトル検索の構築

BigQuery でベクトル検索がネイティブにサポートされる前、スケーラブルなベクトル検索ソリューションを構築するには、複雑な多段階のプロセスが必要でした。データ担当者は次の作業を行う必要がありました。

データウェアハウスからデータを抽出する
特殊な ML インフラストラクチャを使用してエンベディングを生成する
エンベディングを専用のベクトルデータベースに読み込む
サーバーのプロビジョニング、スケーリング、インデックス管理など、追加のインフラストラクチャを維持する
ベクトル検索の結果を中核となるビジネスデータに結合するためのカスタムパイプラインを開発する
インデックスの再構築中のダウンタイムに対処する（本番環境システムにとって重大な課題）

このアーキテクチャはまとまりがなく高額でメンテナンスも大変なため、多くのチームにとって導入の障壁となっていました。

始まり: 簡素性を重視

Google は、市場で最もシンプルなベクトルデータベースを作るという目標を掲げて BigQuery ベクトル検索をスタートさせました。この時点での主要な設計要件は次のとおりです。

完全にサーバーレスであること: Google は早い段階から、ベクトル検索をすべての BigQuery ユーザーに提供する最善の方法がサーバーレスにすることであるとわかっていました。そこでまず、クラスタリングとインデックス登録の利点を組み合わせた IVF インデックスを BigQuery 内に構築しました。こうすると、BigQuery でベクトル検索を使用するために新しいサーバーをプロビジョニングする必要は一切ありません。つまり、ベクトルデータベースの基盤となるインフラストラクチャを管理する必要がないため、チームは最も重要なもの、つまりデータに集中できます。BigQuery は、スケーリング、メンテナンス、信頼性に自動的に対処します。数十億のエンべディングを処理するように簡単にスケールできるため、ビジネスの成長に合わせてソリューションを拡大できます。
インデックスのメンテナンスができる限りシンプルであること: BigQuery のベクトルインデックスは、この簡素性を実現する重要な要素です。インデックスは、簡単な CREATE VECTOR INDEX SQL ステートメントで作成でき、残りは BigQuery が処理します。新しいデータが取り込まれると、インデックスは自動的かつ非同期的に更新されて変更が反映されます。また、取り込んだデータによってデータセットのデータ分布が変化し、検索精度が低下した場合でも、モデルの再構築機能を使用すれば、インデックスのダウンタイムなしで 1 つの SQL ステートメントだけでインデックスを完全に再構築できます。
GoogleSQL と Python に統合されること: 簡単な VECTOR_SEARCH 関数を使用して、既存の SQL ワークフロー内で直接、ベクトル検索を実行できます。そのため、セマンティック検索を従来のクエリや結合と簡単に組み合わせることができます。データサイエンティストにとって、LangChain や BigQuery DataFrames などのツールや Python との統合は、高度な ML アプリケーションを構築するうえで自然な選択肢となります。
整合性が保証されること: 新しいデータは、取り込み直後に VECTOR_SEARCH 関数で検索可能になり、検索結果の精度と整合性が確保されます。
使用した分だけを支払うこと: BigQuery ベクトル検索の料金モデルは、柔軟性を重視して設計されています。この「従量課金制」モデルは、アドホック分析と費用対効果の高いバッチクエリの両方に最適です。このモデルでは、多額の初期投資なしで機能を簡単に試せることが重視されています。
セキュリティが確保されていること: BigQuery のセキュリティインフラストラクチャでは、行レベルのセキュリティ（RLS）と列レベルのセキュリティ（CLS）を通じて、堅牢なデータアクセス制御が可能です。この多層アプローチにより、ユーザーは承認されたデータにのみアクセス可能になり、それによって保護が強化され、コンプライアンスが確保されます。

黎明期: お客様とともに成長

お客様は初期のプロジェクトで成果を挙げ、より多くのデータを BigQuery に移行する中で、新しいエンベディングベースのアプローチを使用するために「更新」している多くのデータサイエンスワークフローについて教えてくださいました。ベクトル検索で強化できるさまざまなアプリケーションの例をいくつかご紹介します。

検索拡張生成（RAG）を使用した大規模言語モデル（LLM）アプリケーション: 関連するビジネスデータを提供することで、ベクトル検索は LLM から正確で根拠のある回答を得るのに役立ちます。
ビジネスデータのセマンティック検索: 内部ユーザーと外部ユーザーの両方に対して、高度な自然言語検索機能が提供されます。たとえば、マーケティングチームは「ジェーンと似た購入履歴を持つ顧客」を検索して、意味的に類似する顧客プロファイルのリストを受け取ることができます。
Customer 360 と重複除去: 名前や住所などの詳細が多少異なる場合でも、エンべディングを使用して類似する顧客レコードを特定できます。これは、データをクリーンアップして統合し、顧客の単一ビューをより正確にするための効果的な方法です。
ログ分析と異常検出: ログデータをエンべディングとして取り込み、テキストが完全に一致しない場合でも、ベクトル検索を使用して類似するログエントリをすばやく見つけることができます。これは、セキュリティチームが潜在的な脅威や異常を非常に迅速に特定するのに役立ちます。
商品レコメンデーションの強化: 視覚的またはテキスト的に類似した商品（衣料品など）や、意味的に関連する補完的な商品が提案されます。

現在: スケーリングと費用対効果の向上

お客様による使用が増えるにつれて、RAG や生成 AI のワークロード以外にもバッチ処理に対する大きな需要があることがわかり、Google はサービスを強化しました。従来のベクトルデータベースとは異なり、BigQuery の改良されたバッチベクトル検索は、大規模なデータセットに対する高スループットの分析類似検索に優れています。これにより、データサイエンティストは既存のデータ環境内で数十億件のレコードを同時に分析し、これまで不可能だった次のようなタスク行えるようになりました。

大規模なクラスタリング: 行動エンべディングに基づいてデータベース内のすべての顧客をグループ化します。
包括的な異常検出: 金融台帳のすべてのアカウントで最も異常な取引を検出します。
アイテムの一括分類: 数百万のテキストドキュメントや商品画像を同時に分類します。

Google は開発の第 2 フェーズにおいて、ベクトル検索のエクスペリエンスをさらに向上させるために多くの新機能をリリースしました。

ScaNN インデックスを使用して構築された TreeAH は、価格とパフォーマンスにおいて大きな差別化要因となります。お客様のデータサイエンスチームは、レコメンデーション、クラスタリング、データパイプラインの多くをベクトル検索を使用するように移行していきました。TreeAH を使用したことで、大きな改善が見られました。
トレーニングとインデックス登録のパフォーマンスおよびユーザビリティの向上に役立つさまざまな内部改善を行いました。たとえば、非同期インデックストレーニングを追加しましたが、これにより大規模なインデックストレーニングジョブがバックグラウンドに移動されるため、ユーザビリティとスケーラビリティが向上しました。また、インデックス登録のパフォーマンスを向上させ、レイテンシを短縮するために、ユーザーに対する追加費用を発生させることなく、さまざまな内部最適化も実施しました。
保存された列は、ベクトル検索のパフォーマンスを向上させるのに役立ちます。

ユーザーは、ベクトル検索クエリで保存された列に事前フィルタを適用して、検索精度を損なうことなく検索パフォーマンスを大幅に最適化できます。
ユーザーがベクトル検索クエリで保存された列のみをクエリする場合、ベーステーブルとの高額な結合を回避することで、検索パフォーマンスをさらに向上させることができます。

パーティション分割されたインデックスでは、無関係なパーティションをスキップして I/O コストを大幅に削減し、クエリのパフォーマンスを向上させることができます。これは、日付や地域などのパーティショニング列で頻繁にフィルタを使用する場合に特に効果的です。
インデックスモデルの再構築は、ベクトル検索の結果が時間の経過とともに正確かつ関連性を維持できるようにするのに役立ちます。ベースデータが進化するにつれて、モデルドリフトをプロアクティブに修正できるようになり、インデックスのダウンタイムなしでベクトル検索アプリケーションの優れたパフォーマンスを維持できます。

今後: あらゆるものをインデックスに登録

企業がエージェント AI を検討する中、データプラットフォームの重要性はかつてないほど高まっています。Google は、すべての企業が生産性向上のための独自の AI モードを確保し、関連データの取得が生産性の中心となる世界を想像しています。これには、AI と分析を自動化するためのすべての関連する企業データ（構造化データおよび非構造化データ）のインテリジェントなインデックス登録が含まれます。インデックス登録と検索は Google の中核です。今後も、関連する技術革新について皆様にお伝えしてまいります。

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

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

リネージで AI の信頼とコンテキストを構築（列レベルの粒度に対応）

Tue, 11 Nov 2025 00:10:00 +0000

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

効果的な AI システムは、コンテキストと継続的な信頼を基盤として動作します。Google Cloud の統合データガバナンスプラットフォームである Dataplex Universal Catalog では、データを記述するメタデータが静的ではなくなります。AI アプリケーションは、このカタログでデータの場所と信頼できるデータを把握できます。

しかし、データパイプラインが複雑になると、データの流れがわかりにくくなり、情報の出所から最終的な影響までを追跡することが難しくなります。この課題を解決するために、Google は Dataplex のリネージ機能をオブジェクトレベルから列レベルに拡張し、まずは BigQuery のサポートから開始します。

「AI 戦略を推進するには、データに対する絶対的な信頼が必要です。列レベルのリネージは、それを実現します。これは、責任を持って確実にデータを管理するための基盤です。」- Verizon、データおよび AI ガバナンスエンジニアリング担当 AVP、Latheef Syed 氏

オブジェクトレベルのリネージは、テーブル全体の最上位の接続を追跡しますが、列レベルのリネージは、単一のデータ列が移動・変換される特定の経路をきめ細かくチャート化します。これにより、データから AI へのエコシステムを管理するための動的で詳細なマップが提供され、エージェント AI アプリケーションをコンテキストに応じて根拠づけできるようになります。リネージが追加料金なしで列レベルにアップグレードされます。

データに関する重要な質問に答える

データプロフェッショナルは、BigQuery データセットの複雑な関係について正確な回答を必要とすることがよくあります。列レベルのリネージは、データフローのグラフを提供し、このグラフをたどることで、これらの答えをすばやく見つけることができます。次のことを行えるようになりました。

AI モデルで使用される列が信頼できるソースからのものであることを確認する
変更を行う前に、1 列への変更が下流の他の列にどのように影響するかを把握する
列の上流の変換を調べることで、列の問題の根本原因を追跡する
組織全体で列レベルのセンシティブデータが正しく使用されていることを確認する

「列レベルのリネージは、当社のデータエコシステムの信頼できるマップを次のレベルに引き上げます。変更の影響を完全に理解し、問題の原因をたどり、コンプライアンスを最も詳細なレベルまで確保するために必要な精度の高いツールです。」 - Verizon、データ / AI およびプロダクトエンジニアリング担当 AVP、Arvind Rajagopalan 氏

リネージを視覚的に探索

Dataplex では、列レベルのリネージ関係をインタラクティブに視覚的に表現できるようになりました。テーブル内の 1 つの列を選択すると、その列の上流と下流のすべての接続のグラフが表示されます。アセットレベルでグラフを操作する際に、列レベルにドリルダウンして、プロセスによって影響を受ける特定の列を確認できます。また、2 つの異なるアセットの列間の直接的なリネージパスを可視化して、それらの関係に焦点を当てたビューを表示することもできます。

AI モデルの列レベルのトレース

AI および ML モデルのトレーニングに使用されるテーブルには、さまざまなソースからさまざまなパスをたどってデータが取り込まれることが多く、データの流れを詳細に把握することが重要です。たとえば、複雑な AI/ML 特徴テーブルでは、モデルトレーニング用の単一のテーブルに多数の列が含まれる場合があります。列レベルのリネージでは、ある列が信頼できる監査済みの財務システムから派生したものであり、別の列が一時的なウェブログから派生したものであることを検証できます。テーブルレベルのリネージでは、この重要な違いが不明瞭になり、すべての特徴が同じ信頼レベルで扱われます。

コンテキストアウェア AI エージェントの実現

タスクを自動化し、データに関する複雑な質問に回答するために AI エージェントを開発する企業が増えています。これらのエージェントが効果を発揮するには、ビジネスと組織のコンテキストを深く理解する必要があります。列レベルのリネージによって提供される詳細なメタデータが、この必要なコンテキストを提供します。たとえば、エージェントは、名前が似ている指標を区別できます。各列のパス（使用頻度や鮮度など）をトレースすることで、変更の影響を受けた場合の列の重要性や、トラブルシューティング時の影響の重大度に関するコンテキストをエージェントに提供します。データアセットとその関係に関する豊富な事実に基づいたマップに AI エージェントをグラウンディングすることで、より正確で信頼性の高いエージェントワークフローを構築できます。

使ってみる

BigQuery の列レベルのリネージは、Dataplex で今すぐご利用いただけます。

-プロダクトマネージャー、Paulina Trzeciak

データエンジニアリングエージェントのプレビュー版を提供開始

Fri, 07 Nov 2025 03:10:00 +0000

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

データは現代の企業にとって生命線ですが、それを有効活用するプロセスには多くの摩擦が伴います。データエンジニア、アナリスト、データサイエンティストは、組織の中でも最も専門性が高く価値のある人材ですが、その多くの時間を反復的で影響の小さい作業に費やしています。パイプラインを手作業で構築、維持する代わりに、それを自動化するためのベストプラクティスやルールの定義に集中できたらどうでしょうか。

本日、Google はこの課題を解決するための大きな転換点となる発表を行いました。Gemini のテクノロジーを活用し、最も複雑で時間のかかるデータエンジニアリング作業を自動化するように設計されたファーストパーティエージェント、BigQuery データエンジニアリングエージェントのプレビュー版を発表しました。

この Data Engineering Agent は単なる機能改善にとどまりません。真に自律的なデータエンジニアリングオペレーションによって、私たちの働き方そのものを変革します。IDC によると、「生成 AI やその他の自動化ソリューションにより、2026 年までに企業は 1 兆ドルを超える生産性向上を実現する見込みです1」と報告されています。

現在利用できる強力な機能を詳しく見ていきましょう。

パイプラインの開発とメンテナンス

Data Engineering Agent を使えば、堅牢なデータパイプラインを簡単に構築、維持できます。このエージェントは BigQuery パイプラインで利用でき、次の作業をサポートします。

自然言語によるパイプラインの作成: パイプラインの要件を自然な言葉で説明するだけで、エージェントが必要な SQL コードを自動生成します。生成されたコードは、指示ファイルを使ってカスタマイズできるデータエンジニアリングのベストプラクティスに準拠しています。たとえば、「customer_orders バケットからデータを読み込み、日付形式を標準化し、重複を削除して clean_orders という名前の BigQuery テーブルにロードするパイプラインを作成して」といった指示です。
インテリジェントなパイプラインの変更: 既存のパイプラインを更新する場合は、変更する内容をエージェントに伝えるだけで OK です。エージェントが既存のコードを分析し、必要な変更を提案してくれるので、ユーザーはそれを確認して承認するだけで済みます。たとえば、「customer_orders バケットからデータを取り込み、日付形式を標準化し、重複を削除して clean_orders という名前の BigQuery テーブルにロードするパイプラインを作成して」といった指示です。エージェントは、ベストプラクティスに基づいた設計原則に従い、既存のパイプラインを最適化、再設計して冗長な処理を排除し、さらにパーティショニングなどの BigQuery のクエリ最適化機能を活用できるようにします。
Dataplex Universal Catalog との統合: このエージェントは、Google Cloud のデータガバナンスサービスである Dataplex を活用します。Dataplex からビジネス用語集やデータプロファイルなどの追加メタデータを自動取得し、新しいテーブルのメタデータ生成やパイプラインの関連性、パフォーマンスを向上させます。
カスタム指示とロジックの組み込み: カスタム指示を設定し、パイプライン内でユーザー定義関数（UDF）を活用することで、独自のビジネスロジックやエンジニアリングのベストプラクティスを組み込むことができます。
コードドキュメントの自動生成: エージェントは、パイプラインの明確で簡潔なドキュメントを列の説明とともに自動生成します。これにより、チーム全体のパイプラインに対する理解が進み、保守も容易になります。

スペイン語のニュースとエンターテイメントグループである PRISA Media は、早期アクセスのお客様として、データエンジニアリングエージェントを試用し、良好な成果を上げています。

「このエージェントは、新しい開発アプローチを模索できるソリューションを提供し、複雑なデータエンジニアリングタスクに対応できる大きな可能性を示しています。SCD Type 2 ディメンションの作成といった高度なデータモデリングタスクでも、要件を正確に解釈する優れた能力を発揮します。現時点でも、メンテナンスや小規模な最適化の自動化によってすでに価値をもたらしており、将来的には真に際立ったツールへと進化するための基盤が整っていると考えています。」- スペイン語のニュースとエンターテイメントグループ PRISA リードデータエンジニア Fernando Calo 氏

データの準備、変換、モデリング

データプロジェクトの最初のステップは、多くの場合、最も時間がかかるフェーズです。それは、未加工データの理解、準備、クリーニングです。たとえば、データエンジニアリングエージェントを使えば、Google Cloud Storage に保存された未加工ファイルにアクセスできます。エージェントは、提供された指示に基づいてデータを自動的にクリーンアップし、重複を削除し、フォーマットや標準化を行います。Dataplex との統合により、Dataplex リポジトリで定義されたルールに基づいてデータ品質アサーションを生成し、個人情報（PII）を含むとフラグ付けされた列を自動的に暗号化できます。データ品質の問題を特定したり、形式を標準化したりするために、複雑なクエリを作成する必要はもうありません。

さらに、エージェントは必要なコードを生成して主要なデータ変換タスクを実行し、分析用データの準備にかかる時間を大幅に短縮します。このプロセスでは、データセットの結合や集計などの操作を自動化します。

また、複雑なデータモデリングもサポートします。自然言語のプロンプトを使用して、ソーステーブルから直接、データボールトやスタースキーマといった高度なスキーマを生成できます。

パイプラインのトラブルシューティング

問題が発生した場合は、データエンジニアリングエージェントが迅速な特定と解決を支援します。ログやコードを手作業で調べる代わりに、エージェントを呼び出して問題を診断できます。このデータエンジニアリングエージェントは Gemini Cloud Assist と統合されており、実行ログを分析して障害の根本原因を特定し、解決策を提案します。これにより、パイプラインをこれまでにない速さで復旧、再稼働させることができます。

パイプラインの移行

データスタックのモダナイズを進めたいと考えているチームでは、データエンジニアリングエージェントが、統合された Google Cloud データプラットフォームへの移行を大幅にスピードアップできます。Vodafone が BigQuery に移行した際も、その効果が発揮されました。

「Dataform 環境への移行の過程で、データエンジニアエージェントは既存のすべてのデータと変換スクリプトを 100% 自動的に複製し、手作業による介入なしで処理することに成功しました。この取り組みにより、手作業による ETL 移行に通常かかる時間を 90% 短縮し、移行プロセスを大幅に加速させることができました。」- Vodafone エンジニアリング責任者 Chris Benfield 氏

お客様はすでに BigQuery パイプラインに移行し、次のような成果を上げています。

コードの標準化と統合: 処理エンジンを統合する場合は、エージェントが BigQuery パイプラインの標準化を支援します。既存のコードをエージェントに渡すだけで、同等の最適化済み BigQuery パイプラインが自動生成され、運用の複雑さやコストを削減できます。
レガシーツールからの移行: エージェントは、レガシーデータ処理ツールで使用されている独自形式や構成を、ネイティブな BigQuery パイプラインに変換します。

今後の展望

データエンジニアリングエージェントの歩みは、まだ始まったばかりです。Google は、データエンジニアリングチームが直面するさまざまな課題に対応できるよう、機能拡張を継続的に進めています。今後は、Cloud Composer におけるパイプラインのオーケストレーション、プロアクティブなトラブルシューティング、IDE との統合など、エージェントの対応領域がさらに広がっていく予定です。

使ってみる

BigQuery データエンジニアリングエージェントは今すぐご利用いただけます。この新しいインテリジェントパートナーを、日々の業務でどのように活用していただけるのかを楽しみにしています。

データエンジニアリングワークフローを次のステージへ進めましょう

エージェントへのアクセス: BigQuery Studio の BigQuery Pipelines または Dataform UI に移動し、画面の [エージェントに質問] ボタンから利用できます。
詳細: 設定手順やベストプラクティスは公式ドキュメントをご覧ください。
フィードバック: ご意見やご要望は bigquery-dea-feedback@google.com までメールでお寄せください

1. IDC Market Perspective、GenAI's Impact on Enterprise Software、#US52547624、2024 年 9 月

-データエンジニアリングエージェント担当プロダクトマネジメント Tim Bezold

-データエンジニアリングエージェント担当エンジニアリングマネージャー Varun Chandr

BigQuery

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 キー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ジャカード類似度

実装へのブループリント

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

類似配信

希少特徴戦略

バッチ戦略

まとめ

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

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

主な機能のアップデート

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

今後の対応

パターンは検出できますか？BigQuery の新しい MATCH_RECOGNIZE 関数なら可能です。

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

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

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

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

グローバルクエリとは

グローバルクエリの活用

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

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

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

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

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

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

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

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

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

コンテキストアウェア AI エージェントの実現

データエンジニアリングエージェントのプレビュー版を提供開始