データ分析

Google Cloud Knowledge Catalog のご紹介

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

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

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

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

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

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

- Bloomberg Media、CTO、William Anderson 氏

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agentic Data Cloud の新機能：「System of Action」を実現

Wed, 22 Apr 2026 03:50:00 +0000

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

企業は単に質問に答えるだけの生成 AI から、自律的に状況を認識し、推論し、ユーザーに代わって行動する「自律型エージェント」へと転換期を迎えています。これらのエージェントをレガシースタック上で拡張しようとすると、ガバナンスの断片化、信頼性の欠如、寸断された推論ループといった構造的な問題が露呈し、コストの急増を招くことがあります。

これらの課題を解決するために、 Google Cloud は Agentic Data Cloud を発表します。これは、エンタープライズデータプラットフォームを静的なリポジトリから動的な推論エンジンへと進化させる、 AI ネイティブアーキテクチャです。これにより「思考」と「行動」の間のギャップを埋め、 AI エージェントがビジネスデータとコンテキストに基づいて自律的に行動することを可能にします。前世代のシステムオブインテリジェンス（System of Intelligence）は人間が扱う規模を想定し構築されていましたが、Agentic Data Cloud はエージェントによる大規模な処理を前提とした「行動のシステム（System of Action）」へと進化させました。

すでに多くの先進的な企業が、Agentic Data Cloud を使用して具体的な価値を創出しています。

Vodafone は、顧客にシームレスなサービスを提供すべく、数百のエージェントを導入し、年間数百万ユーロのコスト削減を見込んでいます。
American Express は、基幹オンプレミスデータウェアハウスと数百の本番アプリケーションを BigQuery に移行し、大規模で信頼性の高い「エージェンティックコマース」を推進しています。
Virgin Voyages は、1,000 以上の専門 AI エージェントを活用しており、そのうちの 1 つは大規模な旅程の再予約にかかる時間を 6 時間からわずか 11 分に短縮しました。

本日、 Google Cloud は Agentic Data Cloud を強化する 3 つの新しいイノベーションを発表します。

ユニバーサルコンテキストエンジンは、エージェントに信頼性の高いビジネスコンテキストを提供し、精度を向上させます。
エージェントファーストの開発者体験により、データ担当者や開発者の役割をエージェントのオーケストレーターへと進化させます。
AI ネイティブなクロスクラウドレイクハウスがデータ資産全体を接続し、データサイロを排除します。

ユニバーサルコンテキストエンジンでエージェントを強化

AI の有用性は、そのコンテキストに依存します。エージェントが企業独自の「粗利」の定義や、複雑なサプライチェーンの相関関係を理解していなければ、正確な判断は下せません。エージェンティックエンタープライズの時代において、データだけでは不十分であり、従来のガバナンスモデルも十分ではありません。Google Cloud は、Dataplex Universal Catalog を Knowledge Catalog へと進化させました。これは、集約、継続的なエンリッチメント、および検索という厳格なフレームワークを用いて、データ資産全体にわたるビジネス上の意味をマッピングし、推論します。

仕組みは以下の通りです。

集約：真のコンテキストを構築するには、あらゆる場所から情報を集める必要があります。Google Cloud およびパートナーのデータプラットフォーム全体からネイティブコンテキストを集約しています。これには、サードパーティのカタログ、アプリケーション、オペレーティングシステム、および Palantir、Salesforce Data360、SAP、ServiceNow、Workday（プレビュー）などの AI プラットフォームが含まれます。Google Cloud のレイクハウスを使用することで、サードパーティのデータ資産を Knowledge Catalog へ自動的にマッピングします。Google Cloud のデータソースについては、戦略ドキュメントからセマンティクスを自律的に生成する新しい LookML Agent（プレビュー）や、ビジネスロジックをプラットフォームにネイティブに埋め込む BigQuery measures（プレビュー）によって、ビジネスロジックの自動化を実現します。
継続的なエンリッチメント： Knowledge Catalog は、組織全体の利用ログの分析とバックグラウンドでのデータをプロファイリングを通じて、継続的なエンリッチメントを提供します。これにより、データが「何であるか」だけでなく、企業内で「実際にどのように使用されているか」を学習します。この機能は非構造化データにも対応します。Google Cloud Storage にファイルが保存された瞬間に、Smart Storage（プレビュー）が瞬時に画像にタグを付け、エンリッチメントを実行します（PDF オブジェクトも近日対応予定）。また、Knowledge Catalog は有用な非構造化データのコレクションを特定し、Gemini を使用して欠落しているスキーマを自動生成して複雑な関係性をマッピングすることで、AI がコンテキストを把握できない「視界不良」の状態を防ぎます。
検索とリトリーバル： 膨大なコンテキストレイヤーの構築は重要ですが、エージェント時代において、検索は新しいクエリパスへと進化しました。エンタープライズスケールにおける大きな課題は、速度、関連性、グローバルなリーチ、そしてセキュリティです。これらを解決するため、Knowledge Catalog は Google 検索のイノベーションを基盤とした高度なハイブリッド検索スタックを採用しています。高い関連性を実現するために、セマンティックマッチングとレキシカル（語彙）マッチングを、機械学習ベースのインテリジェントなリランキングと組み合わせています。また、信頼性を確保するため、アクセス制御を考慮した検索によってセキュリティ権限をネイティブに適用しており、エージェントは権限を持つ資産のみを取得し、操作することができます。この高精度なインフラストラクチャにより、信頼できるコンテキストを即座に特定し、特化型エージェントに提供することが可能になります。

Knowledge Catalog は Deep Research Agent（プレビュー版）を強化しています。Gemini Enterprise で利用可能なエージェント群の一部であるこのエージェントは、 BigQuery などの Google Cloud データプラットフォーム、社内文書、ウェブ資産にわたって多段階の推論を行い、これまで数週間の手作業を要していた複雑な問いに対し、引用元を伴う正確な回答を提示します。

エージェントファーストな開発者体験

この新しいアーキテクチャへの移行に伴い、データ担当者の役割は、手動でパイプラインを構築することから、「意図（インテント）」に基づいたエンジニアリングをオーケストレーション（統括および制御）することへとシフトします。

この移行を加速させるため、 Google Cloud Data Agent Kit（プレビュー版）を提供します。これは新しいインターフェースを導入するのではなく、 VS Code、 Gemini CLI、 Codex、 Claude Code といった開発者が使い慣れた環境に組み込めるポータブルなスキル、ツール、環境固有の拡張機能、および組み込みプラグインのスイートを提供します。これにより、 IDE やノートブック、またはエージェント型ターミナルがネイティブなデータ環境となり、 dbt、 Apache Spark、 Apache Airflow などの適切なフレームワークを自動選択し、 Google のベストプラクティスに基づいた本番環境対応のコードを生成しながら、幅広いビジネス成果を自律的に運用できます。

このキットは単にツールを接続するだけではなく、データを移動させることなく、ペタバイト規模まで拡張可能な高パフォーマンスな機能を開発者のフローに直接組み込みます。Data Agent Kit は、Google 独自のビルトインエージェントを動かしているものと同じ次のスキルやツールが含まれています。

Data Engineering Agent（一般提供）：複雑なパイプライン変換をゼロから構築し、不良データが本番環境に混入しないようガバナンスルールを自動適用します。
Data Science Agent（一般提供）：データの前処理からトレーニングまで、モデルのライフサイクル全体を自動化し、BigQuery Dataframes および Serverless Apache Spark 上でスケーラブルに処理を実行します。
Database Observability Agent（プレビュー版）：24 時間 365 日体制でインフラを監視し、根本原因の診断とデータベースの修復を実行します。

さらに、エージェントのスムーズな実行を支援するため、Google Cloud は Model Context Protocol（MCP）を全面的に採用しました。MCP はあらゆるエージェントがデータ資産を検出および利用できる、セキュアなユニバーサルインターフェースを提供します。対応するコアエンジンには、BigQuery、Spanner（プレビュー版）、AlloyDB、Cloud SQL（一般提供）、 Looker MCP（プレビュー版）が含まれます。また、 Google Cloud 向け MCP は Google のセキュリティスタックを使用しており、既存の IAM ポリシー、 VPC Service Controls 、およびデータレジデンシー要件に基づいて、エージェントのインタラクションを管理します。

また、Conversational Analytics によってビジネスユーザー体験を再定義します。BigQuery（一般提供）、Cloud SQL、Spanner、 AlloyDB（プレビュー版）、および Looker（一般提供）に対応しており、組織はこれらのカスタム分析エージェントを Gemini Enterprise で公開するだけで、従業員が使い慣れたインターフェースでライブデータと対話できるようになります。技術的な障壁を取り除くことで、手動レポート作成に費やしていた数週間という待ち時間を排除し、ビジネスを「思考のスピード」で加速させます。

エージェントスケールに合わせて構築されたクロスクラウド基盤

エージェントが行動するには、オープンな基盤が必要です。エージェントがクラウド間の遅延によってブロックされたり、特定のベンダー環境に囲い込まれた場合、その自律性は損なわれます。そのため、データがどこに存在していてもその価値を解き放つことができる、真に境界のないクロスクラウドレイクハウスを導入します。

分析基盤の接続：Cross-Cloud Interconnect（CCI）をデータプレーンに直接統合します。 CCI の専用高速プライベートネットワークと Apache Iceberg REST Catalog を組み合わせることで、低遅延で膨大なエグレス費用なしにクラウド間の接続を実現します。その結果、エージェントは AWS や Azure 上のデータを、まるで Google Cloud のローカルデータであるかのようにシームレスなクロスクラウドアクセスで利用できます。
独自サイロの解消：特定ベンダーに依存したカタログの時代に終止符を打つべく、オープンフェデレーションを推進し、双方向フェデレーション（プレビュー版）を開始します。Iceberg REST Catalog により強化された、Amazon S3 上の Databricks Unity Catalog（プレビュー版）、 Snowflake Polaris（プレビュー版）、および Amazon S3 上の AWS Glue Data Catalog（プレビュー版）からエンジンが直接読み取れるようになります。これは強化された Lakehouse Governance（プレビュー版）によって補強され、セキュリティポリシーとアクセス制御がこの境界のない環境全体に即座に適用されます。
運用データの解放：世界で最もスケーラブルかつグローバルに一環したデータベースを、あらゆる場所で利用できるようにする Spanner Omni（プレビュー版）を発表します。これにより初めて、Googleの運営を支える Spanner エンジンをクラウド、オンプレミス、あるいはあなたの PC など、あらゆる場所で、実行可能にします。
インサイトからアクションへのギャップを埋める：インサイトとアクションの間のギャップも解消します。多くの「統合」データプラットフォームでは、複雑な ETL パイプラインの作成を必要とし、エージェントがリアルタイムデータにアクセスすることを妨げています。 AlloyDB 向けレイクハウスフェデレーション（プレビュー版）により、プロトコルレベルのゼロ ETL 同期を提供することでこれらのパイプラインを排除し、エージェントが運用トランザクションにおいて低遅延で蓄積された膨大な分析データにアクセスできるようにします。

未来の自動化に向けて

エージェント規模への移行により、ワークロードは桁違いに増加します。これをサポートするため、 Google は 4 つの主要なパフォーマンスのブレークスルーを発表します。

Lightning Engine for Apache Spark は、市場の競合製品と比較して、最大 2 倍のコストパフォーマンスを実現します。
Managed Lustre は、最大 10 TB/s のスループットを実現し、要求の厳しいモデルに対してデータを十分な速度で処理します。
Bigtable のインメモリティアにより、リアルタイムアプリケーション向けにミリ秒未満の読み取り遅延を提供します。これにより、個別のキャッシュ層が不要になります。
BigQuery fluid scaling により、オートスケーリングが適用されるワークロードにおいて、コストを平均で最大 34% 削減します。エージェントの行動に合わせて瞬時にリソースをスケールアップし、不要な時にはスケールダウンします。

System of Action で成功を築く

受動的なデータ観察の時代は終わりました。これからのビジネスは、Google Cloud の Agentic Data Cloud が実現する「System of Action」によって思考と同じ速さで動きます。

Agentic Data Cloud の詳細や、System of Action を通じて自律型エージェントを加速させるためのデータ準備については、戦略ワークショップにお申し込みください。

Agentic Data Cloud の詳細については、受動的なデータを能動的なアクションへと変えるための設計図についてご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メリット

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

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

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

始める

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

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

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

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

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

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

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

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

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

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

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

BigQuery Graph の主なユースケース

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

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

実際の BigQuery Graph の活用事例

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

BioCorteX: 創薬

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

Curve: 不正検知

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

Virgin Media O2: 不正検知

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

BigQuery Graph の使い方

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

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

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

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

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

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

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

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

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

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

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

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

準備ができたら

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

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

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

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

大手消費者インサイトブランドが Dataproc を使用して高度なパーソナライズを加速している方法

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

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

RVU には、人々を支援し、業界を変革するという明確かつ重要な使命があります。

当社が展開している Confused.com、Uswitch、Tempcover、Money.co.uk、Mojo Mortgages などの市場をリードする家計管理ブランドや乗り換え支援ブランドにおいて、何よりも重要なのは透明性と正確な情報です。昨今の消費者は、単純な比較表以上のものを求めています。つまり、各消費者の状況に合わせたパーソナライズされたおすすめを求めているのです。

その期待に応えるには、すべてのブランドを支える真のパーソナライズエンジンを構築する必要があります。また、それを実現するには高度な ML モデル向けに膨大で複雑なデータセットを処理できるデータ基盤が必要です。現在、当社のプラットフォームはすべてのブランドから収集した数十億のデータポイントを活用して最適化した、数百もの自動化されたパーソナライズキャンペーンを支えています。この大規模なプラットフォームの構築には、Google Cloud と、Google Cloud が提供する Apache Spark 向けの 2 つのソリューション（Dataproc と Google Cloud Serverless for Apache Spark）を活用しました。Google Cloud を採用したことで、当社の使命は現実のものになりつつあります。

特徴量エンジニアリングのための高速エンジン

当社と Google Cloud の関係は今に始まったものではありません。当社は 10 年以上にわたり、統合データプラットフォームとして BigQuery を使用しています。パフォーマンスマーケティングのバックグラウンドを持つ当社では、常に大量のデータを扱ってきました。しかし、自社はデジタルインフラストラクチャ企業ではないという認識は早い段階からありました。どこに価値があるのかに常に注目しなくてはならないため、インフラストラクチャやキャパシティの問題に悩む必要がなくなる BigQuery のようなマネージドソリューションは、創業当初から私たちにとってまさにうってつけでした。

主な課題は、全ブランドにわたり、顧客の行動を意味のある一貫した全体像にまとめることでした。無数の断片的なインタラクションを、ユーザーの行動、クリック、意思決定の方法をそのまま反映したデータに変換する必要があったのです。単独のイベントや集計ビューを頼りにするのではなく、これらのシグナルを、当社の ML モデルが活用できる有用なナラティブとして取り込むことができるプラットフォームを構築する必要がありました。

これを実現するために Dataproc を利用できたことは、実に画期的でした。Dataproc が最も効果を発揮したのは、主に ML モデル開発の特徴量エンジニアリングを目的とした、高速 Spark 処理エンジンとしての役割です。膨大な未加工の顧客データをデータサイエンスモデルが活用できる形へと変えていく「特徴量エンジニアリング」は、まさに当社の価値を高める要素であり、Google が大きな競争優位性を持つ分野です。

その結果、イノベーションの速度が大幅に向上しました。Serverless for Apache Spark を使用することで、わずか数日で特徴量エンジニアリング用に顧客データを整形できるようになりました。以前は数週間かかっていた作業です。製品化までの時間も、数週間かかっていたのが大幅に短縮されました。今では、チームに新たに加わった契約社員でも、探索的データ分析やすべての特徴量エンジニアリングを含むモデルをわずか 1 週間半で提供することができます。これはものすごいスピードです。

パーソナライズされたエクスペリエンスの提供

イノベーションのスピードを向上させることで、お客様やパートナーに、よりパーソナライズされたユーザーエクスペリエンスを提供できるようになりました。

Spark への移行後、高度なパーソナライズへの取り組みは加速しました。膨大な行動データやコンテキストデータを処理する大規模なデータ処理ジョブを実行して、真に有意義な予測を生成するモデルを構築できるようになりました。

これらのモデルは、お客様に何を言うべきかだけでなく、いつ、どのように言うべきかを理解できるようサポートしてくれます。これにより、適切なタイミングと適切なチャネルを選んで、お客様の心に響くパーソナライズされた情報を提供することができます。

未来のビジョンを築く

Google のデータクラウドは、価値を優先するという当社の文化とまさに合致しており、ビジネスに大きな影響を与えています。私はこれを、すべてが同じエコシステム内でシームレスに接続されるネットワーク効果と呼んでいます。当社のデータは BigQuery に存在し、そのデータを検証、拡充、変換する能力は Dataproc と Serverless for Apache Spark に紐付けられ、ML モデルをデプロイする機能はこのネットワーク全体に及んでいます。すべてが連携し統合されているため、当社の消費者ブランドのリアルタイムでの精度を高め、競争優位性を確保することができるのです。

エンジニアにとっての大きなメリットは、インフラストラクチャを扱う必要がないことです。クラスタやサーバーのネットワークを設定して相互に通信させる必要はなく、ボタンを押すだけで 10 分以内にすべてのデータを処理できます。非常に効率的で、データプロダクトの構築やイテレーションなど、より価値の高い作業に時間を割くことができます。

Dataproc のおかげで、スピード、スケール、アジリティが向上しました。また、AI を活用してイノベーションを起こし、高度なパーソナライズの未来を築くためのツールも提供されます。現在、RVU の最先端のテクノロジーとデータは、英国の何百万人もの消費者がよりスマートに十分な情報に基づいて意思決定できるようサポートし、まさに業界を変革しようとしています。

RVU の成功から何かヒントを得られましたでしょうか。Dataproc を使用した永続的なクラスタが必要な場合も、サーバーレス Spark のアジリティが必要な場合も、Google Cloud ならインフラストラクチャではなく価値に集中できるマネージドソリューションを見つけることができます。ユースケースに適した Google Cloud 上の Spark をご確認ください。

- RVU、データエンジニアリング責任者、Siddharth Dawara 氏

Looker の埋め込み分析環境で会話型分析が利用可能に

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

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

Looker の埋め込み分析アナリティクスは、多くの次世代データプロダクトの中核をなすもので、ライブ指標とカスタマイズ可能なユーザーエクスペリエンスによる収益化を可能にします。AI 時代において、ユーザーはアプリに高度なインタラクティブ性と会話性、データにコンテキスト、アクセシビリティ、直感性を求めています。このたび、一般提供が開始された Conversational Analytics API を使用して、Looker の埋め込み分析環境で会話型分析が提供されるようになりました。これにより、ユーザーが Looker に期待する自然言語エクスペリエンスを、お客様の想像力次第で、より多くのサーフェスに拡張できるようになりました。

コンポーズ可能なエージェント型 BI への移行を牽引

組織は、ユーザーが作業する場所でユーザーのニーズを満たす統合データエクスペリエンスを構築しようとしています。これは、デベロッパーが AI エージェントを使用して複雑なエンジニアリングタスクを計画、コーディング、実行するエージェント IDE の台頭と並行して進んでいます。このような環境で Looker の埋め込みアーキテクチャを活用すると、次のような多くのメリットが得られます。

差別化されたエージェントエクスペリエンス: 独自の会話エクスペリエンスを構築して製品を差別化し、高い需要を生み出します。
データ収益化とデベロッパー拡張性の向上: 元データを高度な埋め込みプロダクトに変換して、データアセットを高利益率の収益源に変えます。
IDE における AI 対応: Looker のセマンティックレイヤを使用してハルシネーションを抑制し、市場投入までのスピードを最大化することで、自信を持ってエージェント IDE での開発を進められます。

埋め込みユーザー向けに会話型分析を一般提供

Looker の既存の埋め込みフレームワークと管理されたセマンティックレイヤを基盤として、ローコードの iframe 実装または拡張可能な SDK を介して、Gemini を活用した自然言語クエリと AI レコメンデーションを統合できるようになりました。これにより、あらゆるアプリケーション内で、プロダクションレディな会話型 AI を簡単にリリースできます。

複数の Looker Explore のクエリ、埋め込みのコードインタープリタ、カスタマイズ可能なテーマをネイティブにサポートしているため、コア機能と並行して、プライベートブランドの高度な推論エージェントエクスペリエンスを提供できます。これにより、複雑なデータモデルと直感的なユーザーによる発見のギャップを埋めることができます。

iframe を使用して、アプリケーションの任意の場所に Looker の会話型分析を組み込む

Looker API から会話型分析が利用可能に

Google の会話型分析 API を使用すると、Looker Explore を基盤とする会話型エクスペリエンスを、顧客向けのアプリケーション内に直接構築できます。Looker API を活用することで、AI による推奨事項を提供するマルチターンの会話型ワークフローを作成できるだけでなく、基盤となる SQL クエリの検証と説明も行えます。Looker API は、ユーザー認証と管理のために Looker SDK を使用するため、アプリのどこにでもエージェントによる会話を簡単に統合できます。

Looker API エンドポイントの会話型分析を使用したカスタム UI の構築

データ探索は会話の時代へ

静的で柔軟性に欠けるダッシュボードから、AI を活用した探索への移行は、企業が顧客に価値を提供する方法を変革し、企業がより多くのことを行えるようにします。これらの新しい会話機能を Looker のセマンティックレイヤにグラウンディングすることで、Looker で常に信頼してきた分析情報の精度がサードパーティアプリケーションでも得られます。これにより、分析情報の根拠が常に検証可能になります。

埋め込み iframe オプションを使用する場合でも、Looker SDK を使用する場合でも、情報を表示するだけでなく、ユーザーが対話できるデータエクスペリエンスを構築できるようになりました。Looker の埋め込み分析を使用して、独自のプロダクトで会話エクスペリエンスの構築を開始するには、ドキュメントとベストプラクティスガイドをご覧ください。

- Google Cloud、シニアアウトバウンドプロダクトマネージャー、Ani Jain

- Google Cloud、プロダクトマネージャー、Sharon Zhang

Google のデータクラウドでデータキュレーションを加速

Mon, 20 Apr 2026 02:00:00 +0000

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

エンタープライズ環境では、データが複数のソースシステムに細かく断片化されていることがよくあります。データキュレーションは、元データを整理、クリーニング、拡充して、高品質な AI 対応データアセットに変換するプロセスです。ETL ツール、手動の SQL、Python を使用して元データのマージやクリーンアップを行い、ダッシュボードを構築するという従来の方法では、このプロセスは AI と分析にとって主なボトルネックになります。

Google のデータクラウドには、分析情報が得られるまでの時間を短縮し、これらのワークフローを自動化するために設計されたキュレーションアクセラレータがいくつか用意されています。

1. 半構造化データに対する Cloud Storage での自動検出

最新のキュレーションの最初のステップは、Cloud Storage 内のダークデータのカタログ化を手動で行う手間を省くことです。

自動データ検出: Dataplex Universal Catalog の自動検出機能は、GCS バケットをスキャンして、自動的に構造化データ用の外部テーブルを作成し、メタデータをカタログ化します。
アドホック分析: バイブクエリを介して Gemini を活用した分析を即座に行い、価値と品質を評価できます。従来の ETL プロセスでデータを読み込む必要がありません。
ガバナンスの統合: きめ細かいアクセス制御と自動メタデータ生成を元データのストレージレイヤに直接適用でき、最初からセキュリティとガバナンスを組み込めます。

2. メタデータのキュレーションと拡張

キュレーションの加速では、列と行からデータのセマンティック理解への移行が重要なポイントとなっています。

自動インサイト: データ分析情報機能は、列の説明、リレーションシップのグラフ、自然言語で提案された質問を自動的に生成します。これにより、メタデータのドキュメント化が迅速化され、新しいデータや未知のデータに直面した際の初期の探索と分析が加速されます。
会話型分析のグラウンディング: これらの分析情報は、後でデータ内の会話型分析のグラウンディングに役立ち、エージェントはアセットがビジネスにどのように関連しているかを理解するための追加のコンテキストを得ることができます。これにより、自然言語を使用してデータとチャットする際の回答の精度が向上します。

3. 統合ガバナンス: 品質、プロファイリング、リネージ

信頼できるキュレーションには、データの健全性と移動を追跡する堅牢なメタデータフレームワークが必要です。

データプロファイリング: データプロファイリングは、統計的特性（null の数、分布など）を自動的に特定して、異常を早期に検出します。
品質管理: ユーザーはデータ品質チェックを定義して実行し、データが組織の品質基準を満たしていることを確認できます。自動データ品質を使用すると、スキャンの自動化、ルールに照らしたデータの検証、データが品質要件を満たしていない場合のアラートの記録を行うことができます。
リネージ追跡: テーブルレベルと列レベルのリネージにより、エンジニアはデータが変換を通じてどのように移動しているかを追跡できます。この透明性により、キュレーションが加速され、パイプラインエラーのデバッグが容易になります。

4. パイプライン開発のためのエージェントワークフロー

Google のデータクラウドには、取り込みと変換のための高負荷のコード生成を処理する AI エージェントが導入されています。

データエンジニアリングエージェント: このエージェントを利用すると、Gemini in BigQuery を活用して、自然言語を使用するか、技術設計ドキュメントを渡すことでパイプラインを構築および管理できます。
データサイエンスエージェント: このエージェントは Colab Enterprise ノートブックと BigQuery ノートブックに統合されていて、探索的データ分析（EDA）の自動化や、複雑な ML 対応パイプラインの Python / PySpark コードの生成に利用できます。

5. カタログ主導のアセット検出とデータプロダクト

大規模な組織で作業の重複をなくすには、キュレーションでの再利用と社内マーケットプレイスに重点を置く必要があります。

まず検出: 新しいパイプラインを構築する前に、チームは Dataplex Data Catalog を使用して既存のアセットを検出します。
データプロダクト: データは、データアセットの論理的グループ化で拡充されたデータプロダクトとして公開され、特定のビジネス上の問題を解決するために、検出可能で信頼性が高く、アクセス可能であることを保証するために正式にパッケージ化されます。
BigQuery Sharing（旧称: Analytics Hub）: この機能により、インプレース共有が可能になり、社内チームとサードパーティチームがデータを移動またはコピーすることなく、キュレートされたデータにアクセスできるようになり、信頼できる唯一の情報源が維持されます。

6. マルチモーダルデータのキュレーションのための組み込み AI 機能

企業が生成するマルチモーダルデータが増加するにつれて、キュレーションは画像、音声、ドキュメントなどの非構造化形式にも及ぶようになりました。以下に示す機能は、こうした進化するニーズに対応します。

生成 AI 関数で再定義された SQL: データチームは、標準 SQL 演算子を使用することで、ML の専門知識がなくても品質や基準によってデータを分類、ランク付けできます。BigQuery の AI 関数を使用すると、ユーザーは感情分析、要約、エンティティ抽出を SQL ステートメント内で直接実行できます。
エンベディングの生成: キュレーションパイプラインでベクトルエンベディングを生成できるようになり、類似検索、プロダクトレコメンデーション、ログ分析、エンティティ解決、重複除去などのユースケースを大規模なデータセット全体で実現できます。
マルチモーダルテーブル: これを使用すると、非構造化データを標準テーブルに統合し、SQL を使用してマルチモーダルデータを操作できます。

7. 継続的クエリによるリアルタイムのキュレーション

リアルタイムのキュレーションを実現するために、BigQuery には、データが継続的に移動する場合もノーコードの取り込みと SQL ベースの変換を可能にする簡単な方法が用意されています。

Pub/Sub から BigQuery へ: 直接サブスクリプションにより、ストリーミングデータを BigQuery テーブルにノーコードで取り込むことができます。
継続的クエリ: これは、継続的に実行される SQL ステートメントであり、受信データをリアルタイムで処理します。キュレートされた出力は、Pub/Sub、Bigtable、または Spanner に即座にストリーミングでき、ダウンストリームアプリケーションやリアルタイムダッシュボードの強化につながります。

まとめると、これらのキュレーションアクセラレータは、最も時間のかかるステップを自動化することで、データのクリーニングと整理という低速な手作業をなくします。準備にかかる時間を短縮し、意思決定に費やす時間を増やしましょう。これらのキュレーションアクセラレータを今すぐお試しください。

- データ分析担当プリンシパルカスタマーエンジニア、Manpreet Singh

Honeylove が BigQuery を活用して製品の品質とサービスの効率を向上させた方法

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

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

完璧なブラの制作には、数千ものデータポイントが利用されます。

Honeylove が単なる下着ブランドではない理由はそこにあります。当社は、優れたブラジャー、トップス、補正下着、ボディスーツを製造するテクノロジー企業です。顧客からのフィードバックに基づいて製品を反復的に改良する方法から、数千ものデータポイントにわたってサイズを最適化する方法まで、テクノロジーは当社のあらゆる業務の基盤となっています。

2018 年に Honeylove が誕生した当時、当社のデータはまだ統合されていませんでした。Shopify で分析を行い、あるプラットフォームでメールキャンペーンのパフォーマンスを確認し、別のプラットフォームで広告の指標を確認するといった状況でした。データはバラバラな状態で、効果的につながっていませんでした。

そんな折、心を捉えたのが BigQuery でした。この投稿では、Honeylove が BigQuery と Gemini を活用してデータを統合し、重要なビジネスインサイトを自動化し、AI を活用して製品の品質とサービスの効率を向上させている方法をご紹介します。また、データを最大限に活用したいとお考えの他の組織の皆様が、当社の手法をどのように応用できるかについてもご説明します。

BigQuery と Gemini でインサイトを変革

最初のステップは、すべてのデータを 1 か所に集めることでした。BigQuery は、当社がまさに求めていたもの、つまり、チームが Google エコシステム内ですでに使用しているツール（Google 広告や Google スプレッドシートなど）とシームレスに統合できる、パフォーマンスが高く経済的な統合データプラットフォームを提供してくれました。これにより、手作業によるデータサイロが解消され、ビジネス全体で AI と ML の機能を迅速に導入できるようになりました。

真の変革が実現したのは、貢献度分析に BigQuery ML 関数を活用し始めたときでした。当社は、コンバージョン率、顧客満足度スコア、ウェブサイトのパフォーマンス、返品率など、最も重要な指標の背後にある主な要因を分析するモデルを構築しました。

とても便利なことに、これらの貢献度分析の結果を Gemini に直接フィードすれば、アクセスしやすいレポートと要約を生成できます。この手法を導入するまでは、重要な会議の前に 10～15 人が 1 時間かけて手作業でダッシュボードを確認し、データを詳しく調べて有用なインサイトを探そうとしていました。Gemini でこのプロセスを自動化するだけで、年間数百時間を節約できました。

さらに、BigQuery と Gemini の効果は、時間の節約だけにとどまりませんでした。これらのツールを活用することで、完全に見逃していたであろうパターンやインサイトを発見することができました。優秀なマーケティングアナリストがダッシュボードを監視したとしても、このようなレポートと同じようにデータを切り分けることはできないでしょう。

また、以前は手作業によるプロセスが主流だった在庫予測と需要計画の分野も変革できました。BigQuery ML の ARIMA 単変量予測モデルをデプロイしてトレーニングすることで、季節性や最近の変化に合わせて自動的に調整される、SKU レベルの高精度な需要予測を利用しました。

この自動化された予測と手動で計算した予測との誤差は、常に 5% 以内に収まっています。これは、20～30% の誤差が生じることもあったサードパーティベンダーの予測と比べると、大きな改善です。こうしてチェックポイントが追加されたことで、より自信を持って在庫に関する重要な決定を下せるようになりました。

マルチモーダルエンベディングで価値と創造性を引き出す

カスタマーサービスのチケットは、e コマースブランドにとって貴重なフィードバックや情報の宝庫となります。ただし、データから分析情報を抽出できる場合に限ります。Google Cloud ならそれが可能です。

当社は、Gemini エンベディングモデルと BigQuery ベクトル検索を活用して、チケットの非構造化テキストを行動につながるデータに変換しています。簡単な SQL コマンドを使用して、データウェアハウスにすでに存在するチケットのベクトルエンベディングを生成し、それらのベクトルを検索拡張生成（RAG）によるセマンティック検索に使用しています。

これにより、「お客様は当社のブラのどのような点を気に入っているか」や「ボディスーツのどのような点を改良したらよいか」といったように、正確で自然な言葉で質問できます。これに応えて、Gemini は類似するユースケースを即座に特定し、キーワードのマッチタイプだけにとどまらず、微妙なニュアンスを伴うことが多い問題の根本原因を迅速に見つけられるようにします。こうして製品の改良を積極的に進めて、サービスの効率性を高めることができます。節約できる時間はチケット 1 件あたり約 30 秒ですが、やり取りが数千件あることから、乗算すればその効果が絶大であることがおわかりになるでしょう。

当社はまた、広告とインフルエンサーコンテンツのライブラリ全体で動画アセットを検索するために、マルチモーダルエンベディングのテストも行っています。「犬の動画を探して」や「赤いドレスの動画を探して」といったクエリをテストして、それが実際に機能するのを見るのは楽しいものでした。次のステップでは、これらのエンべディングを使用して、新しいクリエイティブアセットを既存のものと比較し、過去のデータに基づいてパフォーマンスを予測します。

成長分野のクリエイティブは、これまで数値分析ではなく直感に頼っていましたが、今後は既存の広告クリエイティブの大規模なライブラリを使用して、テストする内容や今後のクリエイティブの作成に役立てることで、この状況を変えたいと考えています。

Google Cloud を使用して未来に向けて構築

Google Cloud と BigQuery は、今では当社の中心的な柱となっています。これにより手作業に費やす時間が減り、実世界の問題を解決する価値の高い作業に時間を割くことができ、小規模なチームで非常に効率的に働けるようになりました。

Google Cloud チームとの連携は非常に役立っています。Google は真のパートナーであり、当社のロードマップを継続的にサポートしてくれています。そして BigQuery ML の機能をさらに活用し、データサイエンスの作業をオフライン分析ではなく、常時利用可能な自動化されたモデルへと移行しています。

また、Vertex AI RAG Engine を使用して社内ナレッジボットを開発し、Google ドライブでホストされている社内ドキュメントに直接接続して、社内ポリシーやプロセスに関する質問に即座に回答できるようにしています。さらに、当社は Conversational Analytics API のテストを行っており、「セルフサービス BI」エクスペリエンスを提供して、チームがアナリストを必要とせずに、書式なしテキストで質問して指標とグラフを取得できるようにしたいと考えています。

テクノロジーファーストの企業として、この変革は Honeylove の事業に大きな影響を与え続けています。これにより、製品品質のイノベーションが加速し、業務効率が向上し、お客様によりインテリジェントで一貫したサービスエクスペリエンスを提供できるようになりました。

- Honeylove、データ責任者、Erik Fantasia 氏

- Honeylove、最高技術責任者、Daniel Upton 氏

FM Logistic が AlphaEvolve を使って倉庫規模の「巡回セールスマン問題」を解決

Wed, 08 Apr 2026 03:00:00 +0000

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

巡回セールスマン問題とは、「すべての地点を 1 回ずつ訪問する最短ルートは何か」という、一見すると単純な問題です。これはコンピュータサイエンスにおける最も難しい問題の一つであり、数学者は 1 世紀近くもこの問題に取り組んでいます。また、FM Logistic のポーランドの倉庫作業員が日々直面している課題でもあります。

倉庫は全体でサッカー場 8 面分の広さがあり、ピッキングポイントの数は 17,700 を超えています。シフトごとの作業員数は数十人にのぼり、その各人が電動車両に乗ってフロアを縦横に駆け巡り、1 度の巡回で数十か所の保管場所を回って段ボール箱を回収します。こうした作業において、不要な経路が積み重なっていくと、時間が無駄になるだけでなく、車両の劣化や、納品の遅延にもつながります。

14 か国以上でグローバル事業を展開する物流プロバイダの FM Logistic は、すでにルーティングを最適化する仕組みを有していました。既存のモデルは、費用優先の高速なルート割り当てロジックに基づき、リアルタイムで応答を得られるようなものです。これはこれでうまく機能していましたが、ルートの判断がその都度行われる仕組みになっており、倉庫全体から見たルート調整能力に限界がありました。一度のシフトで同時に働く作業員数が数十人にのぼることを考えると、ルートがわずかでも改善されれば、大きな効果に直結します。

そこで導入されたのが、Google Cloud の AlphaEvolve です。

AI に、もっと優れたアルゴリズムを書いてもらう

AlphaEvolve は、Gemini モデルを使ってアルゴリズムを自律的に生成、改良する進化型のコーディングエージェントです。固定ルールからスケジュールを計算するのではなく、コーディングパートナーのように動作するのが特徴で、新しいコードを記述し、スコアを付け、最初のコードよりも優れたソリューションが見つかるまで反復処理を行います。

この取り組みをゼロから始めたわけではありません。既存のアルゴリズムを AlphaEvolve に「シード」プログラムとして提供しました。このアルゴリズムは、各ステップごとに、最善と思われるルートをその都度採用するというものです。この実際に使用されているアルゴリズム（すでに問題を解決しており、まだ最適化の余地があるもの）をベースラインとして使用し、Gemini を使って変更や新しいロジックを加えて新たなコードを生成して、人間が設計した元のコードを上回ることができるかどうかを調べました。

改善結果の評価

AlphaEvolve によって改善するには、各アルゴリズムのパフォーマンスを測定する方法が必要となります。そこで、60 件の巡回（合計 1 時間以上の作業員データ）を代表的なデータセットとして使ってカスタム評価関数を設計し、生成された数千のアルゴリズムを実際の状況下でテストしました。

この評価では、「ピックごとの平均移動距離を最小に抑える」という基本的な目標に基づいてコードをスコア付けします。また、運用上の問題を回避するため、フォークリフトの容量超過や、注文品の回収漏れ、同じ箱の重複割り当て、注文の先入れ先出しルール違反、リアルタイム運用で許容される計算時間の超過といった事象にそれぞれペナルティを設け、不適切な解を避けられるようにしています。

結果

新しいルーティングロジックでは、過去最良だったベースラインからの改善をただちに数値で確認できました。

過去最良のソリューションと比較して、ルーティング効率が 10.4% 向上。
全体で、倉庫内の移動距離が年間 15,000 km 以上削減。

この効率化により、人員や車両を増やすことなく、従来と同じ作業員数および設備でより多くの注文を処理できるようになりました。

FM Logistic のグループ CIO である Rodolphe Bey 氏は、次のように述べています。「Google Cloud と協力して AlphaEvolve および Gemini を実装したことで、このスピードが要求される業務においてルーティングアプローチをさらに最適化することができました。既存のアルゴリズムもすでに高度に最適化されていたため、そのベースラインを超えることは困難と思われましたが、上乗せで 10.4% の改善を実現しました。この改善は、納品のスピードアップや、労働条件の改善、車両の劣化軽減に直結しています。」

最終的に勝ち残ったアルゴリズムの動作

AlphaEvolve の実験を繰り返し、実験のたびに数百の候補プログラムを生成するという方法によって、人間が設計した最良のアルゴリズムを上回る新しいアルゴリズムが生み出されました。この新しいアルゴリズムは、人間が解読可能なルールセットとなっており、倉庫チームが内容を確認して適宜調整することが可能です。

3 つの主な改善点:

密度ベースの開始点（アンカー選択）: 旧システムでは、最も多くのピッキングが必要な一か所を開始点として選択していました。新しいアルゴリズムでは、開始点を広く捉えるようになっています。具体的には、互いに近くにあるアイテム同士をクラスタ化して、アイテムが密集しているエリアを開始点（基点アンカーグループ）として使用します。この方法によって、すべての巡回において開始点の効率が高められます。
距離シミュレーションにおけるフィルタリング: リアルタイムに通用する速度を維持するため、2 段階の処理プロセスを使用しています。まず、クイックフィルタによって、ルートロジックに適さない注文を除外します。続けて、残った適切な候補に対してのみ厳密な距離シミュレーションを実行することで、スピードを落とすことなく最も効率の良い経路を見つけています。
柔軟なルート構築: ある出発点から初めて、トラックを効率的に満載にできなくなった場合、無駄なルートを強制することはありません。メインプールにいったん積み荷を戻し、後でもっと良いルートでピックすることで、倉庫全体で効率を向上させています。

次のステップ

ポーランドでの試験運用（現在は本番環境に移行済み）では、倉庫規模の複雑なルーティングにおいて、進化型 AI が役立つことが示されました。FM Logistic は現在、大量の商品を扱っている他の e コマース施設にもこのアルゴリズムを適用することを計画中です。また、AlphaEvolve を道路輸送にも応用し、トラックが積載量に満たない場合の効率化に役立てられないかどうか探っています。さらに、倉庫内の商品配置にも AI を活用して移動距離をさらに短縮できないかどうか検討中です。

^{このプロジェクトは、FM Logistic チーム（Mateusz Klimowicz、Jarosław Urbański、Florent Martin、Alberto Brogio）、Google Cloud の AI for Science チーム（Kartik Sanu、Laurynas Tamulevičius、Nicolas Stroppa、Chris Page、Gary Ng、John Semerdjian、Skandar Hannachi、Vishal Agarwal、Anant Nawalgaria、他）、Google DeepMind の協力によって実現しました。}

- FM Logistic、シニアソフトウェアエンジニア、Mateusz Klimowicz 氏

- Google、シニアスタッフ ML エンジニア兼プロダクトマネージャー、 Anant Nawalgaria

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

Google Cloud のお客様が構築した優れたソリューション（2 月版）: Team USA のテック、通信会社のデータ刷新、ゴールデンステートの「G.O.A.T.T.」

Tue, 17 Mar 2026 01:30:00 +0000

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

AI とクラウドテクノロジーは、世界中のあらゆる業界のあらゆる分野を変革しています。お客様がいなければ、Google Cloud は存在しなかったでしょう。お客様こそが Google のプラットフォームで未来を築いている存在だからです。このシリーズでは、ビジネスを根本から変え、業界を形作り、新しいカテゴリを生み出しているエキサイティングなプロジェクトの数々を取り上げます。

今回の最新号では、Google Cloud がスキー＆スノーボード米国代表向けに AI 搭載のトレーニングツールをどのように構築したのかをはじめ、Vodafone と Fastweb の新しいデータ活用の取り組み、John Lewis Partnership のデベロッパープラットフォームの評価、ゴールデンステートウォリアーズの AI 活用ハンドブック、Hackensack Meridian Health における健全で安定したネットワーク運用、そして Ab Initio が AI 用のデータにより良いコンテキストをもたらす取り組みまで幅広く取り上げます。

来年改めてチェックして、さらに多くの業界のリーダーや注目のスタートアップが Google Cloud テクノロジーをどのように活用しているかをご確認ください。また、まだご覧になっていない場合は、Google のお客様による 1,001 件の実際の生成 AI ユースケースのリストをご確認ください。

AI で米国代表チームをさらに強く

対象: Google Cloud は、今年 2 月にイタリアで開催される冬季オリンピックに向けて、スキー＆スノーボード米国代表チームのための AI 搭載トレーニングツールの開発に取り組みました。

取り組み: スノーボーダーの Maddie Mastro 選手やフリースキーヤーの Alex Hall 選手など、米国代表チームのアスリートたちが競技で優位に立てるようにするとともに、オリンピックに向けて彼らの大胆なトリックに潜む物理法則を解き明かすため、Google Cloud は業界初となる AI 搭載の動画分析プラットフォームを構築しました。このプラットフォームでは、空間知能に関する研究を基に Google DeepMind が開発した独自モデルが活用されています。このツールの目的は、スキー＆スノーボード米国代表チームの選手たちが、トリックの完成度を高めると同時に自信を深められるよう支援することです。

意義: Google Cloud ツールを使用すると、リフトで山頂に戻るまでの間に、各技の完全な分析、過去の取り組みとの比較、次回改善できる点に関する膨大なメモやヒントを確認できます。このツールを開発した主な理由はアスリートのパフォーマンス向上でしたが、安全性の確保もそれに次ぐ重要な目的でした。身体の動きをより正確に把握できるようになれば、事故やけがの予防にもつながります。240 人の選手を擁するチームでは、数十人がけがで離脱する可能性もあるため、これは極めて重要です。

コメント:「以前は、友人に電話して『5 年前のあのトリックの映像、持ってる？』と聞き、ビデオを行き来しながら比較していました。でもこのツールなら違います。過去の滑走を取り込み、今の分析に生かすことができます。スロー再生して、その瞬間に頭や体がどの位置にあるのかを正確に確認できるのです。重要なのは、そうした細かな動きをリアルタイムで見て理解できることです。」– 米国オリンピック代表 5 回参加者 / 金メダル 3 回受賞者、Shaun White 氏

Google Cloud × Team USA - 技術の舞台裏

Fastweb + Vodafone: データワークフローを再構築

対象: 2025 年に Swisscom が Vodafone Italy を買収したことを受け、欧州の通信業界をリードする両社は、顧客へのサービス提供のあり方を見直し、モバイル、ブロードバンド、デジタルの各チャネルで、タイムリーかつパーソナライズされた体験を届けたいと考えました。

取り組み: 両社はすでに BigQuery を使って顧客データワークフローのモダナイズを進めていましたが、エコシステムを統合したことで、既存構成の限界が見えてきました。そこで、すべてのチャネルが正確な顧客データにリアルタイムでアクセスできるよう、Spanner をサービスおよびガバナンス層として導入しました。これにより、低レイテンシでの参照、水平方向のスケール、高可用性を実現し、運用負荷をほぼゼロにできるフルマネージド環境を整備しました。また、Gemini を活用し、コードから直接分かりやすいドキュメントを生成することで、手作業にかかっていた時間を大幅に削減しています。

意義: Spanner Graph を利用することで、プラットフォームが実際にどう動いているかに即した形で、データリネージを可視化できるようになりました。具体的には、どのテーブルがどのジョブを動かしているのか、変換処理がどのように連鎖するのか、依存関係がどこにあるのかといった点を把握できるようになっています。コールセンターでは、より完全で最新の顧客情報を確認できるようになり、デジタルチャネルでは、カスタムインテグレーションなしでも整合性のあるデータを利用できるようになりました。また、パートナーは、Apigee を通じて必要な情報に低レイテンシでアクセスできるようになりました。

Fastweb + Vodafone のコメント:「Google Cloud サービスで Customer 360 プラットフォームを再構築したことで、Fastweb + Vodafone の業務の仕組みは大きく変わりました。ワークフローのモニタリングが簡素化され、パイプラインがより効率的になり、リアルタイムのサービス提供が一般的になりました。」– Fastweb + Vodafone、IT AI 導入およびプラットフォームエンジニアリングリード、 Vincenzo Forciniti 氏

John Lewis がデベロッパープラットフォームの価値を測定

対象: John Lewis Partnership は、John Lewis の百貨店と Waitrose のスーパーマーケットを展開する英国の大手小売企業です。同社はデジタルトランスフォーメーションを推進するため、John Lewis Digital Platform（JLDP）を構築し、johnlewis.com 向けに高品質なソフトウェアを開発する数十のプロダクトチームを支えています。

取り組み: John Lewis は、単純な利用状況の指標にとどまらず、プラットフォームが生み出す本当の価値を測るための、より高度で多段階の手法を整備しました。当初は「オンボーディングに要する時間」のようなスピード重視の指標で測っていましたが、その後は DORA 指標に加え、DX プラットフォームを通じたエンジニアの主観的なフィードバックも組み合わせた包括的なモデルへと移行しました。さらに、35 以上の健全性指標（Kubernetes のベストプラクティス、セキュリティ、運用準備状況など）を小規模な自動ジョブで継続的にモニタリングする独自の「Technical Health（技術的健全性）」機能も導入しています。これにより、各チームは「信号機」を見るかのようにサービスの状態をリアルタイムで把握できます。

意義: 活動量ではなく価値に焦点を当てたことで、必須だから使うツールであることにとどまらず、開発者の手間やつまずきを実際に減らしていることを確認できました。また、自動化された Technical Health チェックにより、プロダクトチームは技術的負債やセキュリティ上の脆弱性を先回りして管理できるようになりました。その結果、中央の運用チームが個々のサービス運用に集中する必要が減り、インシデント解決（MTTR）の短縮、障害の減少、そして大幅なコスト削減につながっています。

コメント:「測定は、到達点ではなく旅の過程です。まずは関係者にとって意味のある指標を測ることから始めつつ、プラットフォームの進化に合わせて柔軟に見直していく準備もしておくべきです。プラットフォームの実現可能性を示す段階で重要だったことが、数年後に機能が成熟した段階でも同じように重要とは限りません。」– John Lewis Partnership、プリンシパルプラットフォームエンジニア、 Alex Moss 氏

Hackensack Meridian Health、VPC Flow Logs でネットワーク移行のリスクを低減

対象: Hackensack Meridian Health（HMH）は、ニュージャージー州最大の医療機関病院システムを擁する大手の非営利医療機関です。病院、救急医療センター、診療所からなる広大なネットワークを運用しているため、システムの信頼性は同組織にとって中核となる価値です。

取り組み: 新しい Google Cloud のネットワーク設計へ大規模に移行する準備として、HMH は VPC Flow Logs と Flow Analyzer を活用し、ハイブリッド環境のトラフィックが「ブラックボックス」になってしまう問題を解消しました。具体的には、Cloud Interconnect の VLAN アタッチメントでログを有効化し、送信元 / 宛先 IP、ポート、プロトコルなど、粒度の細かいテレメトリーを取得しました。その後、このデータをエクスポートし、「誰が誰と通信しているか」を可視化したマップを作成しました。これにより、オンプレミスのデータセンターと、特定の Google Cloud リージョン、VPC、アプリケーションとの間にある重要なトラフィックパターンを特定できるようになりました。

意義: 医療の現場では、ネットワークのわずかな途切れでさえ、重大な影響につながりかねません。トラフィックを事前にマッピングしておくことで、Hackensack Meridian Health は、カットオーバーのどの局面でリスクが最も高まるのかを正確に特定できました。この準備により、移行時の問題をわずか 3 分で検知し、5 分以内に解決できました。従来であれば数時間かかっていた可能性のある作業です。さらに移行にとどまらず、この水準の可視化によって、ハイブリッドインフラ全体にわたるキャパシティ計画、コスト配賦、セキュリティコンプライアンスをより適切に管理できるようになります。

コメント:「相互接続のトラフィックはこれまでブラックボックスのようなものでした。VPC Flow Logs を有効にして Flow Analyzer にフィードすることにより、求めていたマップをようやく入手できるようになりました。ルートを変更する前に、このような重要なトラフィックフローを特定することが、移行全体のリスクを軽減するうえでの鍵でした。」— Hackensack Meridian Health、クラウドエンジニアリングマネージャー、Randall Brokaw 氏

ゴールデンステートウォリアーズの AI 活用バックオフィス

対象: ゴールデンステートウォリアーズは、NBA の中でも近年特に成功を収めているフランチャイズの一つです。そしてコート上の勝利を陰で支えているのが、組織の「G.O.A.T.T.」とも呼べる専門の運用チームです。「G.O.A.T.T.（Greatest of All-Time Technologies）」は、データと AI を活用したプラットフォームで、試合中のインサイト、トレード判断、ファン体験の向上を後押しします。

取り組み: ウォリアーズは、Google Cloud 上に社内の「デジタル頭脳」を構築し、これまでの「勘と経験」に頼る文化から、「分析を起点とする」戦略へと舵を切りました。BigQuery と Gemini を活用することで、試合前のスカウティングレポート作成など、以前は数時間かかっていた複雑な業務フローを自動化できるようになりました。さらに ML を用いて、個々の選手の単純な成績よりも「チームへの適合性」を重視したトレードシミュレーションを数千回実行しています。加えて、コンピュータビジョンにより、NBA におけるすべてのシュートについて「ショットの質」を追跡しています。ビジネス面でも、Discovery API を使ったコンテンツ推薦エンジンを構築し、世界中のファンに対してパーソナライズされたデジタル体験を提供しています。

意義: AI を軸にしたこのアプローチによって、経営陣が検討すべき選択肢をあらかじめ絞り込めるようになり、人間の専門性を実現可能性の高い案に集中させられます。データ処理という「科学」の部分を自動化することで、コーチやスカウトは、対面での指導や戦略立案、選手育成といった「職人技」により多くの時間を割けるようになります。この統合は、3 ポイント革命のようなコート上の戦術に影響を与えただけではありません。業務面でも効率が向上し、従業員はトップダウンの指示を待つのではなく、AI によるアイデアを自発的に IT チームへ持ち込むようになりました。

コメント:「人間か機械のどちらかがすべての意思決定を担うような段階に到達することはありません。大事なのは、直感とデータが同じ結論に行き着くちょうどよい中間点を見つけることです。データは、具体的な選択肢を評価し始める前の段階で、意思決定ツリーを絞り込むのに役立ちます。」— ゴールデンステートウォリアーズ、消費者向け製品および新興テクノロジー担当シニアディレクター、 Nick Manning 氏

Ab Initio がエージェント型 AI 時代に向けて企業データ活用を推進

対象: Ab Initio は、大量データの統合とガバナンスを得意とするエンタープライズ向けソフトウェア企業です。同社のプラットフォームは、ハイブリッドおよびマルチクラウド環境にまたがる複雑なデータライフサイクルを管理するため、大規模組織から信頼されています。

取り組み: AI エージェントが正確なデータに基づいて動けるようにする（グラウンディングする）という課題を解決するため、Ab Initio は Google Cloud と連携し、自社のデータファブリックを BigQuery、Dataplex Universal Catalog、Gemini と統合しました。さらに、メインフレーム、COBOL、SAS などのレガシー環境と、最新のクラウド環境の間をつなぐ、500 以上のメタデータおよびデータコネクタ群も提供しています。この統合により、フィールド（項目）単位でエンドツーエンドのデータリネージを把握できるようになり、Gemini はデータの所在に左右されることなく、十分に文書化された「AI ですぐ使える」データにアクセスできるようになります。

意義: AI エージェントの有効性は、アクセスできるデータの質と範囲に大きく左右されます。Ab Initio を「中立的なハブ」として使うことで、企業はデータそのものを移動させることなく、オンプレミスやマルチクラウドのデータを単一の統合レイヤに連携できます。その結果、Gemini が根拠に基づき、説明可能な形で推論するために必要となる、豊かな意味的コンテキスト（セマンティクス）とリネージを提供できるようになります。企業にとっては、テスト段階の AI から、監査可能でコンプライアンスにも対応し、複雑な意思決定を自動で行えるプロダクションレディなエージェント型ワークフローへより速く移行できるということです。

コメント:「エージェント型 AI には、信頼できる AI 対応のデータとメタデータが必要です。情報の出所、品質、意味を理解することは、データそのものと同じくらい重要です。Gemini はエージェントレイヤの重要なコンポーネントとして機能し、このコンテキストを使用して説明可能かつ監査可能な意思決定を行います。」— Ab Initio、開発責任者 Scott Studer 氏および Google Cloud、データガバナンス、共有、統合担当プロダクトリード、Chai Pydimukkala 氏

- Google Cloud コンテンツおよび編集担当編集長

プロダクションレディな AI エージェントに関するデベロッパーガイド

Tue, 17 Mar 2026 00:00:00 +0000

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

この 1 年間で、デベロッパーコミュニティに変化が生じました。AI エージェントは、「興味深い研究コンセプト」から「チームが実際に構築しているもの」へと進化したのです。プロトタイプは機能しています。デモが示す可能性には目を見張るものがあります。ところが、ここで難題が持ち上がります。AI エージェントをどのようにリリースすればよいのでしょうか？

この問いは多面的です。エージェントは従来のソフトウェアのようには動作しません。推論し、行動し、適応するという性質から、エージェントにはテスト、メモリ、オーケストレーション、セキュリティに対して異なるアプローチが求められます。決定的なコードで有効だったパターンをそのまま適用することはできません。

開発者がこれらの課題を解決できるよう、Google はエージェントのライフサイクル全体を網羅したガイド集を公開しました。これらのリソースは、Kaggle の 5 日間 AI エージェント集中講座で初めて公開されました。そこで非常に高い人気と有用性が確認されたことから、より多くのユーザーに向けて公開する運びとなりました。

これらのガイドでは、実用的なフレームワークとコードサンプルが提供されており、自身のプロジェクトに合わせて柔軟に適用できます。以下では、エージェントのアーキテクチャから本番環境へのデプロイまで、主要なコンセプトを順を追って説明します。それに基づき、どのテーマについてより深掘りすべきかを判断してください。

エージェントとは

エージェントの中核をなすものは、推論、行動、経時的な改善を行う自律的なエンティティです。エージェントの頭脳は大規模言語モデルです。これは、タスクを理解し、回答を生成し、コンテキストに基づいて意思決定を行う認知エンジンです。エージェントは静的なツールとは異なり、動作する中で適応します。思考、行動、観察という再帰的なループに基づいて機能します。各サイクルでエージェントは進歩し、その過程でアプローチを洗練させます。

この中核の周囲にあるのがオーケストレーションレイヤであり、これは通信とデータフローを管理する神経系の役割を果たします。専門的なツールや外部サービスを調整する指揮者のようなものです。これには、即座に思い出すための短期記憶（セッションの状態）、過去のインタラクションを保持するための長期記憶（メモリサービス）、情報検索（RAG）、外部の世界でアクションを実行するためのモジュール（ツールの使用）などが含まれます。セキュリティフレームワークにより、エージェントが安全に、意図された境界内で動作することが保証されます。このアーキテクチャの目的は、インテリジェントで有用かつ信頼できるアシスタントを作成することです。

これらの基本コンセプトの詳細については、エージェントの概要に関するガイドをご覧ください。

ツールと相互運用性

エージェントが真に有用であるためには、ツール、データソース、他のエージェントとやり取りできる必要があります。2 つの新しいプロトコルが、そうした接続に対する標準化されたアプローチを提供します。

Anthropic の Model Context Protocol（MCP）により、エージェントは外部のデータソースやステートレスツールに標準化された方法で接続できます。デベロッパーは、サービスごとにカスタム統合を構築する代わりに、MCP の標準化されたインターフェースを使用して開発を簡素化し、相互運用性を向上させることができます。

Google の Agent2Agent プロトコル（A2A）はさらに一歩踏み込み、基盤となるフレームワークにかかわらずエージェント間の直接通信を可能にします。A2A を使用するエージェントは、安全かつ構造化されたメッセージの交換を通じて、互いの能力を把握し、やり取りの方法を交渉し、連携してタスクを処理します。

これらのプロトコルを組み合わせることで、ツール、データ、他のエージェントとの接続を通じてより広範なエコシステム内で動作するエージェントの基盤が構築されます。ツールと MCP による相互運用性に関するガイドでは、実装例とともにこれら 2 つのプロトコルについて詳しく説明しています。

コンテキストエンジニアリング

LLM がエージェントの脳であるとすれば、コンテキストエンジニアリングは、適切な情報を適切なタイミングで LLM に提供する手法です。これには、プロンプト設計、検索メカニズム、ツールの選択、会話履歴など、エージェントが各リクエストを理解して応答する方法を形作るすべてのものが含まれます。

コンテキストエンジニアリングにより、汎用モデルがパーソナライズされたアシスタントに変わります。コンテキストエンジニアリングは、どのメモリを取得するか、どのツールを提供するか、各インタラクションをどのように構成するかを決定します。効果的なコンテキストエンジニアリングにより、複数のセッションをまたいで一貫性を保持する有用なエージェントが作成されます。コンテキストエンジニアリングが実装されない場合、エージェントは記憶を忘却したり、同じことを繰り返したり、的外れな回答を返したりすることになります。

コンテキストエンジニアリングガイドでは、コンテキストエンジニアリングのフレームワークと実装のための実用的な手法について説明しています。

テストと評価

自律エージェントには、品質保証に対する新しいアプローチが必要です。エージェントが独自の判断を下す場合、その成否は正しい出力を生成できるかという点だけでなく、プロセス全体にわたって正しい判断ができているかという点にもかかっています。

エージェントを評価するにあたっては、最終的な回答の正しさだけでなく、エージェントが結果に至るまでに行う一連の意思決定と行動の軌跡に重点が置かれます。2 つのエージェントがまったく異なる経路で同じ結論に達する可能性があり、その経路を理解することが重要です。優れた評価では、ツールの選択、推論の質、エラー回復、エージェントが明確化のための質問をすべきときに質問したかどうかを調べます。

実用的な評価アプローチには、個々のコンポーネントの単体テスト、複数ステップの意思決定シーケンスの軌跡分析、サンドボックスからカナリア、本番環境への段階的な公開が含まれます。各ステージでは、より多くのユーザーに公開する前に、エージェントの動作のさまざまな側面を検証します。

評価フレームワークとテスト方法の詳細については、エージェントの品質ガイドをご覧ください。

エージェントの本番環境へのデプロイ

プロトタイプから本番環境に移行するには、エージェント固有のニーズに合わせて設計されたインフラストラクチャが必要です。状態を維持し、ツールを動的に使用し、自律的に動作するシステムを実現するには、従来型のデプロイパターンに適応性を持たせることが求められます。

本番環境のエージェントには、インタラクション全体でコンテキストを維持するためのセッション管理、長期記憶のための永続的なメモリシステム、適切な認証と権限によるツール統合、エージェントの意思決定とアクションを追跡するためのリアルタイムのロギングが必要です。

ほとんどのチームは、内部テスト用のサンドボックス、限定的な実環境でのテスト用のカナリア、完全なロールアウト用の本番環境という段階でデプロイします。各ステージでパフォーマンスを検証し、アクセスを拡大する前に問題を検出します。

プロトタイプから本番環境へのガイドでは、プロダクションレディなエージェントインフラストラクチャを構築するためのアーキテクチャに関するガイダンスとコードサンプルを提供しています。

出発点

どこから始めるべきかは、お客様の取り組みの段階によって異なります。エージェントの概要ガイドでは基本的なコンセプトを説明し、ツールと MCP による相互運用性やコンテキストエンジニアリングのガイドでは構築の実践的な課題を取り上げます。検証とリリースを行う準備ができた段階では、エージェントの品質とプロトタイプから本番環境へのガイドが役立ちます。

エージェントの分野は急速に進化していますが、一人で解決する必要はありません。現在の課題に合ったリソースを選んで、構築を始めましょう。

- テクニカルソリューションマネージャー、Kanchana Patlolla

- Google、シニアスタッフ ML エンジニア兼生成 AI 集中講座創設者、Anant Nawalgaria

PayPal 史上最大規模のデータ移行が生成 AI イノベーションの基盤に

Mon, 09 Mar 2026 01:30:00 +0000

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

生成 AI 時代の到来により、企業には革新的なプロダクトを生み出す前例のない機会が訪れており、それに対応するため、テクノロジーインフラの戦略的な見直しが求められています。数年前、数億人の顧客にサービスを提供するデジタルネイティブ企業である PayPal は、大きな課題に直面していました。同社は 25 年にわたりサービスと機能を拡大してきましたが、その結果、データ分析インフラは複雑化していました。さらに、規模拡大の制約や Venmo、Braintree などの企業買収の影響により、約 400 ペタバイトものデータが 12 のサイロ化されたシステムに分散していました。

成長とイノベーションで成功を重ねた結果、複雑さが増し、それが次の進化の足かせになりかねない状況でした。

金融サービス分野における次なるイノベーションの波を引き続き牽引していくために、私たち PayPal はデータ基盤のモダナイゼーションが不可欠だと判断しました。今回は、PayPal が、おそらく史上最大級のデータ移行の一つを成功させ、最終的に分析基盤を Google Cloud のエンタープライズ向けデータウェアハウスである BigQuery に移行した経緯をご紹介します。この取り組みは、事業の重点領域を拡大および推進し、絶えず変化するお客様の金融ニーズに応えていくために必要となる強固なデータ基盤を構築するうえで、大きな前進となりました。

この移行は不可欠でしたが、規模の大きさは圧倒的でした。実際、（すでに運用を終了した）Teradata システムをはじめ、いくつかの指標で見ても、これは史上最大級のデータ移行の一つだったと私たちは考えています。こうした規模の移行にふさわしく、私たちがどのようにこの移行を進めたのか、また皆さんが自社で大規模な移行に取り組む際に検討すべき点は何かについて、いくつかの示唆を共有したいと思います。

データに眠る可能性

デジタル決済の草分け的存在の一つとして、PayPal は数十億件の取引を処理し、数十年にわたる貴重なお客様インサイトを蓄積してきました。当社には、お客様や加盟店のために十分活用しきれないまま、何十年もかけて蓄積されてきた膨大なデータがあります。まさに「山」ではなく「山脈」と呼ぶべき規模です。

買収や新サービスの追加によって有用な機能は増えましたが、その一方で新たなデータ課題も生まれました。たとえば、小規模事業者がオンライン販売では PayPal を、地域での取引では Venmo を使うといったことがあります。しかし、事業全体を一元的に把握できる形で見せるには、コストも時間もかかる複雑な処理が必要でした。

データが分断されていたため、消費者一人ひとりに合わせた体験を提供しにくくなり、その結果、利用者がお金の価値を最大限に引き出せる可能性も小さくなっていました。加えて、データからより深いインサイトを得ることも難しくなっていました。

生成 AI の時代が始まるにつれ、この分断は単なる技術的な不便さでは済まなくなってきました。金融サービスにおいて AI が大きな変革をもたらし、費用対効果も大きいと見込まれる中、データが断片化したままでは、お客様が期待する高度で賢い体験を生み出す力が大きく制約されてしまうことは明らかでした。具体的には、業界をリードする不正検知モデルをさらに強化することから、競争の激しいグローバル経済で加盟店が成功できるよう最高水準のコマース基盤を提供することまで、幅広い取り組みが含まれます。

そこに到達するには、まず分散していたデータ基盤を整える必要がありました。

レガシーシステムとこれからの目標

対象範囲は非常に大規模でした。世界最大規模とされる Teradata 環境に加え、Hadoop クラスタ、Redshift、Snowflake、さらにペタバイト級の取引データを処理するさまざまなシステムを含む、複数のデータプラットフォームを統合する必要がありました。しかもこの移行は、お客様が求めるセキュリティと信頼性を損なうことなく、サービスを止めずに実行しなければなりませんでした。

テクノロジー企業として PayPal には相応の社内リソースがあるため、まずはこの課題に自前で取り組むべきかどうかを判断する必要がありました。コストと効果を比較検討した結果、将来のニーズに対応するためにオンプレミス基盤を統合し、拡張していくやり方では、費用も完了までの期間も現実的ではないと分かりました。さらに、AI のイノベーションはクラウド上で急速に進んでいました。データの力を真に活用するには、そのイノベーションが生まれている場所に身を置く必要がありました。

私たちはさまざまなデータウェアハウスソリューションを評価した結果、多くの利点を備えた BigQuery を選択しました。BigQuery は、コンピューティングとストレージが分離され、それぞれを独立してスケールできる、フルマネージドのクラウドネイティブプラットフォームです。また、私たちが必要としていた規模とパフォーマンスに対応する強力な機能を備えており、使い慣れた SQL インターフェースを利用できるため、開発者コミュニティにとっても学習のハードルが比較的低いという利点がありました。

最も重要なのは、BigQuery が AI とネイティブに統合されている点です。これにより、データ分析をシームレスかつ効率的に行えます。

統合データに向けた歩み

データパートナーとして Google Cloud を選定したのち、私たちはこの歴史的なデータ移行プロジェクトに着手しました。大げさに聞こえるかもしれません。しかし、PayPal の事業規模、展開する地域の広さ、地域ごとに異なる規制、そしてこのデータが高い機密性を持ち、文字どおり大きな価値を有することを踏まえると、この取り組みがいかに大規模で難易度の高いものだったかが見えてきます。

Google Cloud コンサルティングのパートナーや専門家の支援を受けながら、私たちは 300 ペタバイト超のデータを移行し、運用を効率化しました。同時に、全体の約 25% に相当するワークロードを廃止しました。そしてこれらを、事業運用のダウンタイムを一切発生させることなく、またお客様への影響もなく実現しました。成功につながった主な要因は、次のとおりです。

連携: 大規模な変革を実現するうえで最初のハードルは、関係者の間で共通の目標に対する認識をそろえることです。そこで私たちは、この取り組みを全社的な最優先事項と位置付けました。

調査と分析: 移行の範囲、作業量、予算見込みを定義するためには、データ、ワークロード、入出力のデータストリームについて詳細な棚卸しを行うことが不可欠です。データリネージを確立することで、さまざまなコンポーネントの起点や相互関係を追跡できるようになり、依存関係の構造を明確かつ包括的に把握できるようになりました。

戦略: 移行プロセスの基本原則を定めることも重要です。たとえば、リフト＆シフトを採用するのか、それともモダナイゼーションを進めるのかを判断すること、セキュリティ原則を定義すること、ガバナンスのガードレールを設定すること、利用状況をどのように追跡するかを決定することなどが含まれます。

実行: 可能な限りあらゆる作業を自動化し、移行の進捗を継続的に把握できるよう、リアルタイムのダッシュボードも構築しました。また、移行プロセス全体に FinOps を組み込み、利用状況とパフォーマンスを明確に可視化できるようにしました。

BigQuery で得られた成果とその先にある価値

より迅速にインサイトを得られるようになりました。データサイエンティストが用いる複雑なクエリも含め、クエリの実行速度は 2.5 倍から 10 倍に向上しました。これによりリアルタイムの分析情報が得られるようになり、PayPal は商品レコメンド、オファー、カスタマーサポートをより個別化できるようになりました。

新たな AI の土台も整いました。モデルのトレーニングに利用できるデータは、鮮度が 16 倍向上しました。AI 開発上重要な工程である特徴量エンジニアリングも、整備されたガバナンス下のクリーンなデータに即時アクセスできるようになったことで改善されています。その結果、個人および企業の双方に向けた、パーソナライズされた金融ガイダンスや予測分析の開発が加速しました。

業務の最適化も実現しました。BigQuery への移行により、データインフラのベンダーは 4 社から 1 社に集約され、運用が簡素化されるとともに複雑さも大きく軽減されました。また、プラットフォーム間で発生していたデータの重複も完全に解消されました。

BigQuery 上に構築した新しい統合データプラットフォームは、PayPal の次なるイノベーションを支える基盤となっています。これにより、エコシステム全体にわたって、より直感的でパーソナライズされた体験を提供できるようになり、生成 AI の力も最大限に活用できるようになりました。

AI を活用したイノベーションの可能性

今後、この統合データプラットフォームを基盤として、これまで実現できなかった AI を活用した体験の提供を検討しています。たとえば、次のような取り組みです。

お客様に影響が及ぶ前に潜在的な問題を検知する予測型の不正防止。
加盟店がビジネスを最適化できるよう支援するパーソナライズされた金融インサイト。
お客様一人ひとりの好みや行動パターンに合わせて最適化されるシームレスな決済体験。
より高度なリスク評価を通じた、これまで十分な金融サービスを受けられていなかったコミュニティに対する金融アクセスの拡大。

さらに、エージェント型コマースをはじめとする新たな可能性も見据えています。

AI 時代の教訓

私たちの移行は規模の面で特別な取り組みに見えるかもしれませんが、抱えている課題や目指している方向性は、決して私たちだけのものではありません。今まさに自社のデータ基盤を見直そうとしている金融サービス業界の企業はもちろん、それ以外の業界にとっても、参考になる論点は数多くあります。

まず、データがどれほど十分に活用されていないか、そしてどれほど整理されていないかを過小評価しないことです。

データを一元化し、正確性と整合性を担保できれば、AI の実験や本番投入に向けた土台が整います。データファブリックの整備に時間を投じる組織ほど、ML や生成 AI のアプリケーションを、より早く、しかも大規模に市場へ投入できるようになります。

次に重要なのは、適切な統制のもとで、組織内の誰もがデータにアクセスできる状況を整えることです。これにより、多くの可能性が開かれます。データオーケストレーションとエンタープライズ検索を生成 AI と組み合わせれば、長年固定化してきた部門間のサイロを取り払い、組織全体の意思決定を加速できる可能性があります。これは、AI 活用の中でも特に有望な領域の一つです。

金融の世界は、新たなテクノロジーと変化する顧客の期待に後押しされ、今後も進化し続けるでしょう。PayPal のデータ変革は、老舗企業であっても、立ちはだかる根本課題に正面から向き合う意思さえあれば、この変化に先回りする形で自らを再構築できることを示しています。

その結果、私たちはデジタル決済のパイオニアとしての地位を守っただけでなく、デジタルコマースにおける次なるイノベーションの波を牽引し続けるための基盤も整えることができました。

- PayPal、SVP 兼データ、AI、ML テクノロジー担当グローバルヘッド、Mani Iyer 氏

- PayPal、データ分析担当シニアディレクター、Vaishali Walia 氏

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

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

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

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

シンプルな管理

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

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

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

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

Conversational Analytics API を使用して BigQuery で会話型エージェントを構築する

Wed, 04 Mar 2026 01:10:00 +0000

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

データを BigQuery に取り込むことで情報は一元化できますが、真の課題はそのデータを利用できるようにすることです。技術的な障壁のために、知りたいことがある人（経営幹部からアナリストまで）が必要な回答を得られない、ということが少なくありません。

Gemini を搭載した Conversational Analytics API を使用すれば、複雑なシステムを使わなくてもインサイトが得られます。この API は、自然言語を理解し、BigQuery データをクエリして、テキスト、テーブル、グラフで回答を提供する、コンテキスト認識型エージェントの構築を支援するよう設計されています。

現在、API と連携できるソリューションであれば、どのようなものでも構築できます。たとえば、Agent Development Kit（ADK）と統合してマルチエージェントシステムを構築したり、以下のようなデータ戦略を実装したりすることができます。

運用担当者向けのセルフサービストリアージ: サポートチームやセールスチームなどに、データに関する質問に即座に回答するエージェントを提供します。「Why did signups drop last week?（先週、登録者数が減ったのはなぜ？）」といった質問をチケットで問い合わせなくても、すぐに回答を得ることができます。
SaaS プロダクトを差別化: 優れたチャットインターフェースをプラットフォームに直接埋め込むことで、プラットフォームを差別化できます。お客様は平易な英語を使用して、独自の使用状況データをクエリ、可視化できます。
動的なレポート: 静的な PDF を超えるレポート機能です。核となるレポート機能を自動化し、レポートをリアルタイムの会話バージョンに効果的に置き換え、関係者が微妙なニュアンスのフォローアップの質問をしてより詳細な調査ができるようにします。

この投稿では、Conversational Analytics API を使用して BigQuery で会話型エージェントを構築する方法をご紹介します。

ステップ 1: エージェントを構成して作成する

データ分析エージェントをデプロイするには、最終的な作成呼び出しを行う前に、アクセス、コンテキスト、環境を構成する必要があります。

ご紹介する例では Python SDK を使用していますが、Conversational Analytics API はユーザーの好みや環境に応じて他の多くの言語にも対応しています。

クライアントを初期化し、BigQuery ソースを定義する

まず、API とのやり取りに必要なクライアント（DataAgentServiceClient）をインスタンス化します。このクライアントは、明示的な BigQueryTableReference オブジェクトと組み合わせて使用します。BigQueryTableReference オブジェクトは、エージェントが特定のテーブル（project_id、dataset_id、table_id で定義）にアクセスすることを承認します。こうした個々の参照は、bq フィールドの下の DatasourceReferences オブジェクトに集約されます。

code_block: <ListValue: [StructValue([('code', 'from google.cloud import geminidataanalytics\r\n\r\n# Set project-specific variables (client, location, project IDs)\r\ndata_agent_client = geminidataanalytics.DataAgentServiceClient()\r\nlocation = "global"\r\nbilling_project = "your-gcp-project-id"\r\ndata_agent_id = "google_trends_analytics_agent"\r\n\r\n# Define the BigQuery table sources\r\nbq_top = geminidataanalytics.BigQueryTableReference(\r\n project_id="bigquery-public-data", dataset_id="google_trends", table_id="top_terms"\r\n)\r\nbq_rising = geminidataanalytics.BigQueryTableReference(\r\n project_id="bigquery-public-data", dataset_id="google_trends", table_id="top_rising_terms"\r\n)\r\ndatasource_references = geminidataanalytics.DatasourceReferences(\r\n bq=geminidataanalytics.BigQueryTableReferences(table_references=[bq_top, bq_rising]))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3093840cd0>)])]>

エージェントコンテキストを設定する

system_instruction（エージェントの動作 / ロールを定義）と datasource_references（エージェントがアクセスできるデータを定義）をバンドルして、コンテキストオブジェクトを構築します。完成したコンテキストは、最終オブジェクト DataAgent の DataAnalyticsAgent 構造体の中でネストされます。

文字列ベースのシステム指示を与えることもできますが、より堅牢なコンテキストオブジェクトを使用してエージェントに指示を与えることをおすすめします。さらに、オブジェクトに追加のシステム指示を与えて、補足ガイダンスを提供できるようにすることもできます。

code_block: <ListValue: [StructValue([('code', '# Set the context using our system_instruction string\r\npublished_context = geminidataanalytics.Context(\r\n system_instruction=system_instruction,\r\n datasource_references=datasource_references\r\n example_queries=example_queries\r\n)\r\n\r\ndata_agent = geminidataanalytics.DataAgent(\r\n data_analytics_agent=geminidataanalytics.DataAnalyticsAgent(\r\n published_context=published_context\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3093840580>)])]>

エージェントを作成する

data_agent_client.create_data_agent を呼び出します。このリクエストには、親リソースパス（projects/{billing_project}/locations/{location}）、一意のdata_agent_id、デプロイを完了できるようにすべて構成された data_agent オブジェクトが含まれます。

code_block: <ListValue: [StructValue([('code', '# Create the agent\r\ndata_agent_client.create_data_agent(request=geminidataanalytics.CreateDataAgentRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n data_agent_id=data_agent_id,\r\n data_agent=data_agent,\r\n))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3093840880>)])]>

これで、エージェントが作成され、published_context によって定義されます。

ステップ 2: 会話を作成する（ステートフルとステートレス）

Conversational Analytics API は、以下の 2 つの方法で会話を処理できます。

ステートレス: 質問とエージェントコンテキストを送信します。会話履歴は自身のアプリケーションで管理し、新しいリクエストごとに送信する必要があります。
ステートフル: サーバーで「会話」を作成します。API が履歴を管理します。これにより、ユーザーはフォローアップの質問をすることができます。

ここでは、ステートフルな会話を構成します。新しいエージェントに関連付けられた会話オブジェクトを作成します。

code_block: <ListValue: [StructValue([('code', 'def setup_conversation(conversation_id: str):\r\n data_chat_client = geminidataanalytics.DataChatServiceClient()\r\n conversation = geminidataanalytics.Conversation(\r\n agents=[data_chat_client.data_agent_path(\r\n billing_project, location, data_agent_id)],\r\n )\r\n request = geminidataanalytics.CreateConversationRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n conversation_id=conversation_id,\r\n conversation=conversation,\r\n )\r\n try:\r\n # Check if it already exists\r\n data_chat_client.get_conversation(name=data_chat_client.conversation_path(\r\n billing_project, location, conversation_id))\r\n except Exception:\r\n response = data_chat_client.create_conversation(request=request)\r\n print("Conversation created successfully.")\r\n\r\nconversation_id = "my_first_conversation"\r\nsetup_conversation(conversation_id=conversation_id)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3093840910>)])]>

ステップ 3: ストリーミングチャットループを作成する

インタラクティブな分析を可能にするため、会話フローを管理する関数 stream_chat_response を実装します。Data Analytics Agent API は、レスポンスをストリームとして返すように設計されています。この処理は、エージェントの最新の進捗状況をリアルタイムで提供するために不可欠です。

一般的なレスポンスストリームには、以下のような個別のコンポーネントが含まれます。

スキーマ: テーブルの解像度の確認。
データ（クエリ）: 生成された SQL クエリ（デバッグと透明性の確保に適しています）。
データ（結果）: 結果のデータ構造体（Pandas のような DataFrame など）。
グラフ: データ可視化のための Vega-Lite JSON 仕様。
テキスト: 合成された自然言語での最終的な要約。

関数を定義する

この関数は、ユーザーの質問を受け付けるように定義されています。内部では、DataChatServiceClient を初期化し、ストリーミング完了後にグラフをレンダリングする必要があるかどうかを追跡するための単純なフラグ（chart_generated_flag）を定義します。ユーザーの質問は、API リクエストに必要な Message オブジェクトにラップされます。

code_block: <ListValue: [StructValue([('code', "def stream_chat_response(question: str):\r\n data_chat_client = geminidataanalytics.DataChatServiceClient()\r\n chart_generated_flag = [False] # Flag to help with visualization\r\n \r\n # Format the user's question into an API-ready Message object\r\n messages = [\r\n geminidataanalytics.Message(\r\n user_message=geminidataanalytics.UserMessage(text=question)\r\n )\r\n ]"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f30938400d0>)])]>

ストリームを処理する

ConversationReference は必須です。ステートフルな会話に関連付け、先ほど作成した特定の data_agent にリンクします。親パス、メッセージ、参照を使ってリクエストオブジェクトを完全に構築したら、data_chat_client.chat を呼び出します。

次に、返されたストリームを反復処理します。ここでは、ユーティリティ関数 show_message を使用して、さまざまなレスポンスタイプ（テキスト、グラフ、データ）を解析し、ユーザーに合わせて適切にフォーマットしています。最後に、ストリーム内で chart_generated_flag が設定されていた場合は、後処理ユーティリティ（preview_in_browser）が可視化のレンダリングを処理します。

code_block: <ListValue: [StructValue([('code', '# Reference the stateful conversation and the created Data Agent\r\n conversation_reference = geminidataanalytics.ConversationReference(\r\n conversation=data_chat_client.conversation_path(\r\n billing_project, location, conversation_id\r\n ),\r\n data_agent_context=geminidataanalytics.DataAgentContext(\r\n data_agent=data_chat_client.data_agent_path(\r\n billing_project, location, data_agent_id\r\n ),\r\n ),\r\n )\r\n \r\n # Prepare the chat request\r\n request = geminidataanalytics.ChatRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n messages=messages,\r\n conversation_reference=conversation_reference,\r\n )\r\n \r\n # Process the streaming response\r\n stream = data_chat_client.chat(request=request)\r\n for response in stream:\r\n # \'show_message\' is a utility function that formats\r\n # and prints the different response types (text, data, chart)\r\n show_message(response, chart_generated_flag)\r\n\r\n # If a chart was generated, \'preview_in_browser\'\r\n # is a utility to save and serve it as HTML\r\n if chart_generated_flag[0]:\r\n preview_in_browser()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3093840640>)])]>

ステップ 4: エージェントと会話する

質問する

では、成果を見てみましょう。stream_chat_response 関数を使用して会話できます。

コンテキストを確認する

まず、エージェントがそのコンテキストを理解しているかどうかを確認しましょう。

Python

code_block: <ListValue: [StructValue([('code', 'question = "Hey what data do you have access to?"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3093840970>)])]>

エージェントは、system_instruction で指定した説明を使用して、top_terms テーブルと top_rising_terms テーブルの概要を返します。

自然言語から SQL、そしてグラフへ

今度は、複雑なクエリを見てみましょう。平易な英語でグラフをリクエストしていることに注目してください。

Python

code_block: <ListValue: [StructValue([('code', 'question = "What are the top 20 most popular search terms last week in NYC based on rank? Display each term and score as a column chart"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3093840c40>)])]>

エージェントは、このプロセスを以下のようにストリーミングします。

生成された SQL クエリを表示します。このクエリは、top_terms テーブルにアクセスし、dma_name = 'New York NY' と直近の 1 週間でデータをフィルタします。
結果のデータをテーブルとして出力します。
Vega グラフの仕様を生成します。
preview_in_browser ユーティリティがこれを、縦棒グラフを表示する index.html ファイルとして提供します。

ステートフルなフォローアップ

ここで、ステートフルな会話（ステップ 2）が力を発揮します。

Python

code_block: <ListValue: [StructValue([('code', 'question = "What was the percent gain in growth for these search terms from the week before?"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f30938409d0>)])]>

エージェントは、「these search terms（これらの検索語句）」が質問 2 の結果を指していることを記憶しています。新しいクエリを生成し、今回は（join_instructions の指示に沿って）top_terms テーブルと top_rising_terms テーブルを INNER JOIN して、同じ語句リストの percent_gain を取得します。

ステップ 5: エージェントを管理する

エージェントとメッセージのライフサイクル管理について詳しくは、Conversational Analytics API ドキュメントの、実行できるさまざまな API リクエスト（HTTP / Python）に関するページをご確認ください。エージェントの管理方法、SetIAM API、GetIAM API 経由で新たにユーザーを招待して共同作業を行う方法などについても説明しています。

上級者向けのヒント: データと人のギャップを埋める

明確なシステム指示とスキーマ説明を与えることで、単なる会話型エージェントではなく、該当分野のエキスパートとなるエージェントを構築できます。このインタラクティブなアプローチは、静的なダッシュボードを越え、真に利用できるデータ分析を実現します。

始める

- デベロッパーリレーションズエンジニア、David Tamaki Szajngarten

- デベロッパーアドボケイト、Wei Hsia

新しい 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 0x7f30909b3760>)])]>

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

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

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

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

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

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

企業データを活用してエージェント型 AI を加速させる: Ab Initio の取り組み

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

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

AI エージェントの性能は、その背後にあるデータによって決まります。エージェント型 AI を構築する企業チームにとって、これはチャンスであると同時に、核心的な問題でもあります。最新のクラウドサービスから従来のメインフレームまで、数十ものシステムにデータが分散している場合、Gemini や他の AI モデルに正確で十分に文書化されたデータへのアクセスをどのように許可すればよいのでしょうか。

これは多くの組織が積極的に取り組んでいる問題です。Gemini やその他の AI モデルは、エージェントワークフローをサポートするために、大量の AI 対応データに依存しています。

現在、ほとんどの企業は、さまざまなクラウドプロバイダ、オンプレミスサーバー、レガシーシステムなど、多くの場所にデータを保存しています。効果的な AI エージェントを実現するために必要なデータとメタデータをまとめるには、それらすべてを接続する必要があります。

AI 時代のデータに関する課題に対処するため、Google Cloud と Ab Initio は、新しいデータコネクタ、メタデータコネクタ、エージェントを含む一連のプロダクトを発表します。これらを組み合わせることで、自律的なアクションと、迅速な人間参加型の意思決定を可能にするエージェント型 AI エクスペリエンスを構築できます。Ab Initio のデータ統合、ガバナンス、アクティブメタデータ、エージェント型 AI の機能は、Google Cloud プラットフォーム（特に BigQuery、Dataplex Universal Catalog、Gemini）と直接統合されます。

Google のデータクラウドがエージェント型 AI をどのように強化するか

Google のデータクラウドは、エージェント型 AI を強化するために必要なデータとコンテキストを提供できるように構築されています。BigQuery は、Google Cloud 内でデータストレージを提供するとともに、スケーラブルな分析と処理を実現します。Dataplex は、Google Cloud 全体のデータ、AI アセット、メタデータを整理し、AI のカタログとして機能します。AI が大規模に推論して行動するために必要な、定義、制約、関係などの検出可能性と重要なビジネスコンテキストを提供する動的な記録システムを提供します。

しかし、多くの組織はデータが分散したマルチクラウド環境で運用されています。外部データが利用可能であっても、その出所、信頼性、ビジネス上の意味を説明するメタデータが不足している場合があります。Ab Initio とのパートナーシップにより、このような障害が克服されています。

ハイブリッドエンタープライズ向け統合ハブ

Ab Initio は、マルチクラウドエンタープライズデータファブリックを作成するニュートラルなハブとして機能します。特に、Ab Initio は 500 以上のソース間で双方向のメタデータ交換を行うことで Dataplex を拡張します。この範囲が重要です。最新のクラウドサービスから従来のメインフレームまで、あらゆるものがカバーされます。

この統合により、COBOL、DataStage、Informatica、SAS などの最新のテクノロジーと、長年にわたって使用されてきた複雑なレガシーシステムの両方に対応するネイティブコンバータを含む、100 以上のエクストラクタからフィールドレベルのエンドツーエンドのリネージが提供されます。

Google Cloud のお客様向けに、Ab Initio はオンプレミス環境とマルチクラウド環境のデータを単一の統合レイヤにフェデレーションし、エージェントアプリケーションを実現します。

コンポーネントが連携して動作する仕組みは次のとおりです。

Ab Initio は、リネージと変換のコンテキストを提供しながら、システム全体でデータとメタデータへのアクセスを統合します。このリネージ履歴を使用すると、任意の時点に遡ってメタデータの状態に関する質問に答えることができるため、監査可能性とコンプライアンスがサポートされます。
BigQuery は、データを保存し、大規模な分析とモデリングを実行します。これには、外部の分散データも含まれます。つまり、分析はデータがどこにあっても実行できます。
Dataplex Universal Catalog は、自動化されたガバナンス基盤を拡張し、AI エージェントのグラウンディングとデータ分析情報の迅速化に必要な、信頼できるセマンティックコンテキストを提供します。Ab Initio Metadata Hub との統合により、マルチクラウド環境全体でメタデータを管理できます。
Gemini は、グラウンディングされた説明可能な推論とエージェント活動のために、包括的なデータとメタデータを使用します。コンテキストが豊富であるほど、AI はデータをより適切に推論できます。

図 1. ハイブリッドクラウドとマルチクラウドのデータおよびメタデータのハブとして機能する Ab Initio

データと AI のライフサイクル全体にわたるガバナンス

このモデルでは、データは分散された異種データとして残りますが、メタデータは統合されて標準化されます。Ab Initio のアーキテクチャは、世界最大規模の企業の本番環境で実績を上げています。

Ab Initio は、変換、品質、リネージ、ガバナンス、オーケストレーションなど、データエンジニアリングのライフサイクル全体を包括的にカバーし、すべてが連携して機能します。これにより、正確で説明可能な Gemini の推論をサポートできる、より豊富なメタデータが生成されます。

エージェント型 AI の基盤としてのコンテキスト

エージェント型 AI には、信頼できる AI 対応のデータとメタデータが必要です。情報の出所、品質、意味を理解することは、データそのものと同じくらい重要です。Gemini はエージェントレイヤの重要なコンポーネントとして機能し、このコンテキストを使用して説明可能かつ監査可能な意思決定を行います。

Ab Initio と BigQuery、Dataplex、Gemini の統合は、マルチクラウド企業がその理解を深めるのに役立ちます。Ab Initio をハブとして使用することで、透明性とコントロールを維持しながら、分散データで機能するエージェントをデプロイできます。このハブは、説明可能性、コンプライアンス、運用の信頼性をサポートします。

始める

データ機能を拡張し、エージェント型 AI をワークフローに組み込むにつれて、データソース全体で接続されたコンテキストを維持することが不可欠になります。Ab Initio は、Google Gemini エージェントがハイブリッド環境とマルチクラウド環境全体で効果的に動作できるように、データとコンテキストを提供します。

統合の詳細については、Ab Initio の Google Cloud パートナーページをご覧いただくか、Google Cloud の担当者にお問い合わせください。

Ab Initio は、大規模なデータ処理とガバナンスのためのエージェントデータプラットフォームを提供しており、世界で最も要求の厳しい企業から信頼されています。また、アクティブメタデータと透明性の高い高性能なデータ統合を組み合わせることで、AI 主導の分析と自動化をサポートし、組織が複雑なシステムをモダナイズしてリスクを軽減し、信頼できるデータプロダクトをより迅速に提供できるようにします。

- Ab Initio、開発責任者、Scott Studer 氏

- Google Cloud、データガバナンス / 共有 / 統合担当プロダクトリード、Chai Pydimukkala

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

データ分析

Google Cloud Knowledge Catalog のご紹介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agentic Data Cloud の新機能：「System of Action」を実現

ユニバーサル コンテキスト エンジンでエージェントを強化

エージェント ファーストな開発者体験

エージェント スケールに合わせて構築されたクロス クラウド基盤

未来の自動化に向けて

System of Action で成功を築く

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

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

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

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

メリット

始める

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

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

BigQuery Graph の主なユースケース

実際の BigQuery Graph の活用事例

BigQuery Graph の使い方

準備ができたら

大手消費者インサイト ブランドが Dataproc を使用して高度なパーソナライズを加速している方法

特徴量エンジニアリングのための高速エンジン

パーソナライズされたエクスペリエンスの提供

未来のビジョンを築く

Looker の埋め込み分析環境で会話型分析が利用可能に

コンポーズ可能なエージェント型 BI への移行を牽引

埋め込みユーザー向けに会話型分析を一般提供

Looker API から会話型分析が利用可能に

データ探索は会話の時代へ

Google のデータクラウドでデータ キュレーションを加速

1. 半構造化データに対する Cloud Storage での自動検出

2. メタデータのキュレーションと拡張

3. 統合ガバナンス: 品質、プロファイリング、リネージ

4. パイプライン開発のためのエージェント ワークフロー

5. カタログ主導のアセット検出とデータ プロダクト

6. マルチモーダル データのキュレーションのための組み込み AI 機能

7. 継続的クエリによるリアルタイムのキュレーション

Honeylove が BigQuery を活用して製品の品質とサービスの効率を向上させた方法

BigQuery と Gemini でインサイトを変革

マルチモーダル エンベディングで価値と創造性を引き出す

Google Cloud を使用して未来に向けて構築

FM Logistic が AlphaEvolve を使って倉庫規模の「巡回セールスマン問題」を解決

AI に、もっと優れたアルゴリズムを書いてもらう

改善結果の評価

結果

最終的に勝ち残ったアルゴリズムの動作

次のステップ

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

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

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

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

Google Cloud のお客様が構築した優れたソリューション（2 月版）: Team USA のテック、通信会社のデータ刷新、ゴールデン ステートの「G.O.A.T.T.」

プロダクション レディな AI エージェントに関するデベロッパー ガイド

出発点

PayPal 史上最大規模のデータ移行が生成 AI イノベーションの基盤に

データに眠る可能性

レガシーシステムとこれからの目標

統合データに向けた歩み

BigQuery で得られた成果とその先にある価値

AI を活用したイノベーションの可能性

AI 時代の教訓

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

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

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

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

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

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

ユニバーサルコンテキストエンジンでエージェントを強化

エージェントファーストな開発者体験

エージェントスケールに合わせて構築されたクロスクラウド基盤

大手消費者インサイトブランドが Dataproc を使用して高度なパーソナライズを加速している方法

Google のデータクラウドでデータキュレーションを加速

4. パイプライン開発のためのエージェントワークフロー

5. カタログ主導のアセット検出とデータプロダクト

6. マルチモーダルデータのキュレーションのための組み込み AI 機能

マルチモーダルエンベディングで価値と創造性を引き出す

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

Google Cloud のお客様が構築した優れたソリューション（2 月版）: Team USA のテック、通信会社のデータ刷新、ゴールデンステートの「G.O.A.T.T.」

プロダクションレディな AI エージェントに関するデベロッパーガイド

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

ステップ 3: ストリーミングチャットループを作成する

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

グローバルクエリとは

グローバルクエリの活用

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

ハイブリッドエンタープライズ向け統合ハブ

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