データ分析

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

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

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

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

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

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

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

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

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

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

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

実際の活用例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

準備ができたら

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

移行コネクタ

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

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

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

BigQuery Data Transfer Service を選ぶ理由

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パイプラインフロー

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

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

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

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

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

パイプラインの実装

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

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

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

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

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

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

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

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

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

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

3. Dataflow DAG の組み立て

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

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

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

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

1. 大幅なコスト削減

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

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

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

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

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

重要ポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

- Malachyte、CEO、Sidd Motwani 氏

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

課題

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

マルチモーダルの利点

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

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

課題

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

マルチモーダルの利点

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

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

課題

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

マルチモーダルの利点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関係が重要な理由

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

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

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

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

仕組み

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

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

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

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

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

デベロッパーとビジネスユーザーの双方が、これらの関係ネットワークをスムーズに管理、デプロイできるように、直感的なネイティブ運用ツールを BigQuery Studio に直接組み込みました。

視覚的なグラフモデラー: BigQuery Studio 内のノーコードのドラッグ＆ドロップインターフェースで、複雑な DDL スクリプトを手動で記述することなく、プロパティグラフ、ノード、エッジを視覚的に構築、編集、マッピングできます。

会話型分析（CA）のインテグレーション: ユーザーはグラフと自然にやり取りできます。会話型分析エージェントは、テーブル結合を推測するのではなく、グラフの決定論的な関係認識マップをナビゲートし、自然言語の質問を、境界が制約された正確な GoogleSQL クエリまたは ISO GQL クエリに変換します。これにより、モデルのハルシネーションを防ぎ、セマンティックな一貫性を確保します。

統合されたセマンティクス: Looker とのネイティブなインテグレーション

断片化されたロジックスタックの維持を避けるために、ビジネス指標はデータレイヤに存在する必要があります。Looker（LookML）を、データベース内分析モデルとしての BigQuery Graphs とネイティブに統合することで、コアでロジックを一度定義するだけで済みます。

データベース管理モデル（sql_analytic_model_name）: sql_analytic_model_name を使用して、Looker にデータベース定義の BigQuery Graph を直接参照させ、標準の LookML のディメンションとメジャーをグラフプロパティに直接マッピングします。
Looker 管理モデル（derived_analytic_model）: derived_analytic_model を使用して、LookML ビュー内で BigQuery Graph スキーマを直接定義します。Looker は、SQL DDL ステートメントを動的に生成して実行し、BigQuery 内のグラフを維持します。
エンタープライズ DevOps ワークフロー: Looker IDE、Git ベースのバージョン管理、継続的インテグレーション（CI）を使用して、グラフのライフサイクル全体を管理します。主要な KPI（離脱率など）は、検証済みで、信頼できる、まったく同じものが維持されます。

- Google Cloud、グループプロダクトマネージャー、Deepak Dayama

- ソフトウェア開発マネージャー、Yun Zhang

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SOAP の経済性

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

次のステップ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Looker ベースのユーザー認証

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

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

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

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

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

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

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

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

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

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

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

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

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

痛手となる影響:

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

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

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

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

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

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

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

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

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

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

メリットの比較

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

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

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

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

まとめ

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

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

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

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

Spanner Graph で小売商品の検索性能を強化し、データベースのメンテナンス工数半減を達成した Target の取り組み

Thu, 20 Aug 2026 01:10:00 +0000

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

現代の小売環境における買い物客は、高度にパーソナライズされた商品発見体験と、自然で本物らしく、心から役に立つと感じられる会話型アシスタンスを期待しています。今日、優れた商品検索には、商品、カテゴリ、顧客の意図の密接な関係やセマンティックな意味を理解することが求められます。キーワードや基本的なブラウジングだけでは不十分です。

Target でこの作業を担当しているのがゲストプロダクトコンフィデンスプラットフォームチームです。評価、レビュー、AI を活用したデジタルショッピングアシスタントなど、信頼を確立し、購入の意思決定を導く機能を構築する責任を担っています。その好例が、2025 年のホリデーシーズンにオンラインストアと Target アプリにリリースされた Gift Finder チャットエージェントです。このエージェントは、親しみやすい会話を通じて、買い物客がぴったりの商品を見つけるのをサポートします。

このようなリアルタイムのパーソナライズとコンテキストリッチなセマンティック応答をグローバル規模で提供するには、断片化されたデータエコシステムを脱却し、統合型のデータプラットフォームに移行するという重要なアーキテクチャ上の課題があることがわかりました。当社は、高スループットのトランザクションワークロード、高度に接続されたグラフ関係、ベクトル類似度検索、全文キーワード検索をまとめてサポートできるソリューションを必要としていました。

この投稿では、これら 4 つのすべてを実現するうえで Spanner が果たした役割について説明します。

断片化されたアーキテクチャからの脱却

従来の Target のディスカバリーデータエコシステムは、検索と転置インデックス用の Elasticsearch クラスタと、トランザクションデータ用の個別の NoSQL データストアの組み合わせで構成されていました。この断片化されたアーキテクチャは機能はするものの、運用上および技術上の大きな課題を抱えていました。

コンテキストの分断: 検索、ベクトル、トランザクションの各データベースの完全同期は常に課題でした。情報がサイロ化されていることで、コンテキストの欠落、属性間の関係の断絶、クエリ結果の不整合が発生していました。
運用上のオーバーヘッドの増大: 独立したクラスタの管理、検索インデックスのチューニング、複雑なカスタム同期と集計ロジックの処理を実行するには、エンジニアリングチームによる集中的な手動介入が必要でした。
拡張のボトルネック: 小売データドメインを拡張するには、新しいデータベースコレクションの追加、複雑な結合の維持、検出システムとコアトランザクションシステムにおける弱いトランザクション保証への対処が必要でした。
サイロ化されたインテリジェンス: グラフの関係、ベクトル類似度、キーワード検索インデックスを 1 件のトランザクションでクエリする機能が欠如していました。

AI を活用した次世代のゲストエクスペリエンスを構築するには、1 つのプラットフォームに統合する必要がありました。

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

スタンドアロンのベクトルデータベースやニッチなグラフデータベースなど、複数の専用テクノロジーを評価しました。しかし、単一目的のデータベースを追加すると、運用の複雑さとデータ同期パイプラインのパフォーマンスが悪化するだけでした。

最終的に選択した方法が、Spanner Graph を利用してエンタープライズオントロジーを構築することでした。これは「グラフのグラフ」パラダイムであり、生成 AI を活用した大規模なショッピンググラフの構築を可能にします。

データを統合することで、セマンティックデータ、グラフ関係、ベクトルエンベディング、運用トランザクションを 1 つの屋根の下に集約します。これにより、トランザクションの状態とセマンティックインテリジェンスの両方について、Spanner が信頼できる唯一の情報源となります。

当社のハイレベルなアーキテクチャは、以下の 3 つの主要な柱で構成されています。

1. エンタープライズ拡張このレイヤは、当社のエンタープライズ小売カタログをキャプチャし、複数のバックエンドソースから関連するメタデータを集約し、エージェントによるデータ拡充に生成 AI を活用して、取り込む商品データの品質と深さを大幅に向上させます。

2. グラフ、ベクトル、検索の統合ストアSpanner Graph では、複数のデータベース間でデータを移動させるのではなく、エンティティノード、関係エッジ、ベクトルエンベディングを同じデータベースエンジンに保存します。Spanner Graph は、リレーショナルテーブルに対するマルチホップグラフ探索、セマンティックベクトル類似検索、全文キーワードクエリをネイティブにサポートしています。このマルチモデルシナジーはネイティブであるため、脆弱な外部同期パイプラインを介さずに分散ワークロード全体で厳格な ACID トランザクションを実現し、絶対的な正確性を確保できます。

3. オーケストレーションと AI レイヤこのレイヤは、会話型ゲストインターフェースを強化し、Spanner Graph から直接供給される豊富な構造化コンテキストを利用して LLM をグラウンディングします。責任ある AI プロセスを管理し、生成された出力を評価しながら、非常に具体的な商品関係を抽出することで Gift Finder などのツールを強化します。

ダウンタイムなしでスムーズに段階的に移行

当社の検索と見つけやすさのインフラストラクチャは何百万人もの顧客が利用する重要なものであるため、移行にあたってはダウンタイムをゼロにする慎重なアプローチが必要でした。この移行は、4 つの構造化されたフェーズで実行されました。

スキーマとオントロジーのマッピング: Spanner Graph スキーマ内で、商品、カテゴリ、ブランド、顧客の好みなどの特定の小売エンティティと、それらに対応する関係を定義しました。
データ統合と並列リプレイ: ミューテーションベースのデータ統合を並列パイプラインで構築しました。これにより、リアルタイムのトランザクションの更新を継続的にリプレイし、スキーマ変換を適用して、エンベディングを生成し、リアルタイムで Spanner Graph に直接書き込むことができました。
カナリアデプロイ: ライブの読み取りトラフィックを新しい Spanner Graph ベースのプラットフォームに徐々に移行し、実際の小売ワークロードでクエリのパフォーマンス、セマンティックの精度、データベースの安定性を検証しました。
カットオーバーとクリーンアップ: パフォーマンスを徹底的に検証した後、すべての検索と見つけやすさのトラフィックを Spanner に完全に移行し、以前の Elasticsearch スタックを廃止することで、Elasticsearch クラスタのメンテナンスの負担を完全に排除しました。

ビジネスへの影響

Spanner Graph 上で直接構築することで、技術面とビジネス面で測定可能な成果を達成できました。

究極の GraphRAG 基盤: 従来の RAG はフラットなベクトル類似度に依存しているため、たとえば特定のおもちゃと互換性のあるアクセサリーや年齢適合性の照合など、商品間の構造化された関連性を見落としがちです。統合された GraphRAG アーキテクチャ内で深いグラフ探索とセマンティックベクトル検索を組み合わせることで、LLM を高精度のコンテキストでグラウンディングしました。これにはおすすめの関連性を直接改善する効果があり、顧客の満足度とネットプロモータースコアの向上につながりました。

SQL と GQL の相互運用性の統合: Spanner Graph を使用すると、デベロッパーは標準 SQL と GQL（Graph Query Language）を使用して、1 回のクエリで構造化されたリレーショナルカタログデータと接続されたグラフ関係に対して処理を要求できます。これにより、これらのパラダイムを橋渡しするためのデータの重複、レイテンシ、複雑な ETL パイプラインが不要になります。

成長の上限がないサーバーレスのスケーラビリティ: Spanner は、ブラックフライデーやサイバーマンデーなどの小売イベントのピーク時に、予測不可能な大規模なトラフィックの急増を自動的に処理します。Spanner に組み込まれたオートスケーラーがコンピューティング容量を動的に調整し、期間限定のプロモーション特典期間中に発生した高負荷のバーストトラフィックを、パフォーマンスを犠牲にすることなく処理しました。

インフラストラクチャのメンテナンス工数の半減: トランザクション NoSQL データベースと検索インデックスデータベースを 1 つのマネージド Google Cloud サービスに統合することで、別々のデータベースクラスタを維持する運用上の負担がなくなりました。開発者がデータベース管理とインフラストラクチャの維持に費やす時間が 50% 削減され、顧客向けの新しい AI 機能をより迅速に構築してデプロイできるようになりました。

Spanner Graph への移行により、当社の生成 AI ロードマップは加速しました。これは、適切なデータ基盤の構築が提供する価値を証明する究極の例となりました。

AI アプリの強化を目指しているのであれば、まずは、適切なグラフ機能を備えたデータベースを事実上無制限の規模で利用することから始めましょう。Spanner Graph で組織のデータをアクションに変える方法をご確認ください。

- プリンシパルエンジニア Sayanti Dey

- Target 社シニアエンジニアリングマネージャー Kaushik Shelat 氏

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

Wed, 19 Aug 2026 01:30:00 +0000

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

的確な意思決定を行うために、企業は社内データと公開リファレンスデータを接続し、実世界の事物とその関係性を可視化するナレッジグラフを作成する必要に迫られることがよくあります。しかし、パブリックとプライベートのデータをつなぐには、従来、非常に複雑なプロセスを要していました。このたび、Spanner Graph でのデータコモンズの一般提供と、新しいデータコモンズプラットフォームのプレビュー版のリリースにより、これらの接続を効率化し、独自のナレッジと公開データセットのナレッジグラフを統合できるようになりました。

包括的なデータコモンズプロジェクトは、世界中の情報を整理し、世界中の人がアクセスできて使えるようにするという Google の使命を後押ししています。データコモンズは、国連、世界銀行、米国国勢調査局、ユーロスタット、WHO、NOAA など、100 を超える信頼できるデータ提供元の断片化された公開データセットを統合しており、標準化された Schema.org 定義で構造化された 4,000 億を超えるデータポイントを網羅しています。データコモンズは、クリーンなデータセットにアクセスして統合するためのデータ探索ツール、MCP ツール、クラウドベースの API を提供します。

データコモンズは、農業、人口統計、経済、環境、保健など、複数の分野にわたる公開情報を統合します。この標準化されたアプローチにより、強力なユースケースが可能になります。たとえば、国の GDP トレンドの分析、地域的な煙による汚染レベルのマッピング、地方自治体レベルでの健康の公平性の追跡、人口分布の経時的な変化の把握など、これらすべてを、事前処理と正規化が済んだデータを使用して行うことができます。

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

ディメンション	サイズ	技術的な説明
統計的観測	4,000 億以上	個々の指標データポイント
グラフのエッジ	26 億以上	関係
ナレッジグラフのノード	17 億以上	標準化されたエンティティ
データソース	100 以上の提供元	信頼できる機関

データコモンズは、膨大な公的行政データを、即座に活用可能なクラウドベースのインフラストラクチャを通じてユーザーに提供します。

Spanner Graph を活用したモダンなインフラストラクチャ

データコモンズを最初に構築した際、Google が目指したのは、当時利用可能だったツールを用いて、膨大かつ多種多様な公開データセットを統合することでした。このプラットフォームは、キャッシュレイヤとして Bigtable を利用していました。これは、ネイティブのグラフデータベーステクノロジーが利用できなかった当時、大規模なルックアップを処理するための効果的な手法でした。

現在、Google はアーキテクチャをネイティブのグラフモデルである Spanner Graph に移行しました。これにより、SQL ライクなインターフェースの利便性とグラフの表現力が Spanner に備わるとともに、Spanner の強みである高可用性、水平スケーリング、マルチリージョンでのトランザクション整合性、そしてネイティブの ISO/IEC 39075 Graph Query Language（GQL）サポートが活用可能になりました。

マルチエンティティ Spanner Graph スキーマを採用することで、エンティティをノードとして、ドメインリンクを動的なグラフエッジとして表現できるようになりました。これにより、事前計算されたキャッシュ構造から脱却し、GQL を用いてデータベース内で直接、複雑な関係性クエリを実行することが可能になりました。

このアーキテクチャでは、費用のかかるインメモリでの再構築や複数のスナップショットを必要とする、複雑な事前計算インデックスが不要になるため、パイプラインも簡素化されます。Spanner Graph では、データベース全体を更新せずに特定のデータセットを増分更新できます。また、ステイル読み取りにより、データの取り込み中も一貫したデータスナップショットが維持されます。

Spanner Graph への移行による主なメリット

統合ストレージと増分更新: Spanner Graph のマルチエンティティスキーマを利用することで、複雑なキャッシュを増分データのインポートをサポートするモデルに置き換え、特定のデータセットに絞った更新を実現しています。
GraphRAG による動的なグラフトラバーサル: 大陸 → 国 → 州 → 郡 → 市といった階層をその場で辿るような、マルチホップクエリを実行します。これにより、静的キャッシュへの依存が解消され、データベースが自然言語クエリを構造化されたパスマッチングトラバーサルに直接マッピングする GraphRAG ワークフローが可能になります。
整合性のあるデータスナップショット: Spanner の TrueTime とステイル読み取りを活用することで、バージョン整合性のあるデータスナップショットを提供し、バッチ取り込みサイクル後も分散ノード全体でデータの一貫性を維持します。
大規模なオペレーショナル分析: Spanner のカラム型エンジンは、必要なフィールドのみを読み取ることで、大規模な時系列データセットを効率的にスキャンします。一方、Spanner の Data Boost テクノロジーを活用した BigQuery 連携 により、隔離された環境で EXTERNAL_QUERY を介して複雑な集計を実行できるようになり、本番環境のトラフィックを分離するのに役立ちます。

SDMX 3.0 の相互運用性によるシステムの橋渡し

複雑な統計データの活用を容易にするため、データコモンズでは、Statistical Data and Metadata eXchange（SDMX）技術標準のリーン実装を採用しています。SDMX は ISO 仕様として、統計データと記述的な統計メタ情報を記述および交換するための一貫したアプローチを提供します。

今回のデータコモンズプラットフォームのアップデートでは、SDMX 技術標準バージョン 3.0 のサポートが追加されました。これにより、多次元データセットにおいて、Tableau、Flourish、Observable などのサードパーティツールとの即座の連携が可能になります。これは、API 標準の SDMX-JSON および SDMX-CSV 2.0 形式を使用して、2 つの重要なエンドポイントを介して可能になります。

アベイラビリティ API: 生のデータを読み取ることなく、既存のディメンション、変数、日付範囲を特定するための、プログラムによる検出メカニズム。
データ API: 実際の観測データとメタデータを取得します。名前付きパラメータを使用することで、ディメンションが追加された際にコードが壊れるのを防ぐことができます。

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

データコモンズプラットフォームのプライベートインスタンスを構築したい組織にとって、この新しいモダンなアーキテクチャは、従来のスケーリング制限を解消し、データスキーマ化を簡素化します。デベロッパーは、Google のデータコモンズインスタンスを支えるのと同じスケーラブルなテクノロジーを活用して、データコモンズプラットフォームのプライベートインスタンスをインスタンス化できます。プライベートインスタンスでは、ユーザーは自身のデータを完全に管理し、アクセスを制限することができます。その一方で、自然言語クエリを活用して、独自のプライベートデータと Google データコモンズインスタンス上の公開データをシームレスに組み合わせて表示することも可能です。Google の公開ナレッジグラフと、お客様独自のデータを含むプライベートナレッジグラフを連携させることで、データの分離を維持し、データの重複を回避しながら、魅力的な新しいユースケースを実現できます。

たとえば、小売企業は、国の GDP 推移、地域の人口構成の内訳、雇用統計などの公開データと、販売履歴、店舗のパフォーマンス指標、サプライチェーンのロジスティクスといった自社データを組み合わせることができます。これにより、アナリストはマクロ経済の公開指標と自社の取引データを照らし合わせて、商品の流通を最適化し、未開拓の市場を特定することが可能になります。

データコモンズプラットフォームのプライベートインスタンスに保存されている商業情報統計局（DGCIS）の統計データと、Google データコモンズのパブリックインスタンスに保存されている世界銀行の世界開発指標を組み合わせた自然言語クエリの実行例。

ユーザーが、国内の年平均気温の推移についてデータエージェントに問い合わせを行っている様子。エージェントはデータコモンズから情報を取得し、過去のデータが利用可能であることを説明した上で、予測される気温変化、気候要因、CMIP6 気候モデルシナリオ（SSP）を提供し、生成されたレポートをエクスポートするオプションを提示します。

ユーザーがデータエージェントに対し、ある国の農村部と都市部における男性の就業者人口比率（WPR）を比較するよう指示している場面。エージェントは、データコモンズからデータを取得し、WPR（総人口に対する就業者の割合）を定義して、両グループを分析および比較するために利用可能な人口統計変数の概要を示します。

早速始めましょう

データコモンズを探索する: datacommons.org にアクセスして、グローバルな統計知識を検索してみましょう。
ナレッジグラフ向けの Spanner Graph のユースケースと設定ガイドをご覧ください。
データコモンズプラットフォームをデプロイする: support@datacommons.org に連絡して、プレビューアクセスをリクエストし、デベロッパーツールをご確認ください。

- データコモンズ、シニアテクニカルプログラムマネージャー、Randeep Toor

- データベース担当グループプロダクトマネージャー、Piyush Mathur

Cortex Framework v7 の一般提供を開始: SAP の運用を中断せずにエージェント型ワークフローを構築する

Wed, 19 Aug 2026 01:00:00 +0000

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

企業は、ミッションクリティカルな ERP システムを中断することなく、AI エージェントを迅速かつ安全にデプロイして、収益の拡大、リスクの軽減、資本の最適化を図りたいと考えています。AI エージェントを強化するには、元データだけでは不十分です。信頼できる単一の再利用可能な情報源として機能し、難解なソースシステムのレコードを明確なビジネス用語に変換する、相互運用可能なデータプロダクトが必要です。

このたび、Google Cloud Cortex Framework バージョン 7 の一般提供を開始しました。このリリースでは、データアーキテクチャをエージェント対応に向けてモダナイズすることで、堅牢なデータプロダクトの迅速なデプロイ、カスタマイズ、拡張を支援します。それと同時に、オーケストレーションを簡素化し、従来のアプローチにおけるインフラストラクチャのオーバーヘッドを削減します。

ERP システムには豊富な基礎データが保持されていますが、これらのトランザクションレコードを AI 対応のデータプロダクトに変換することは、特にコア業務を停滞させずに実現するのは容易ではありません。Cortex Framework v7 は、SAP 向けに特化したデータプロダクトアクセラレータによってこの問題を解決します。BigQuery と Knowledge Catalog に直接デプロイされるこれらのデータプロダクトは、正確なビジネスコンテキストを Gemini Enterprise Agent Platform に提供し、AI エージェントが高い精度で業務を遂行できるようにします。また、Dataform を活用したモジュール式でスケーラブルなデプロイアーキテクチャにより、データオーケストレーションを簡素化します。Dataform は、データチームが BigQuery でワークフローの構築、バージョン管理、オーケストレーションを行うためのエンドツーエンドの環境を提供します。

Cortex Framework v7 の内容、最近リリースされた SAP Business Data Cloud Connect for BigQuery との統合方法、お客様の声、利用開始方法について、詳しくは以下をご覧ください。

Cortex Framework v7 の新機能

1. エージェント対応のデータプロダクトを提供する

従来のビジネスインテリジェンス（BI）ダッシュボードは、前四半期に何が起きたかを振り返るためのものでしたが、最新の AI モデルとエージェントは、リアルタイムでの行動を支援します。この移行を促進するために、Cortex Framework v7 は、AI に適したメタデータを含む、セマンティクスが豊富なデータプロダクトにエンタープライズデータをパッケージ化します。これにより、エージェントは影響力の大きいワークフローを推論、オーケストレート、実行できるようになります。

このフレームワークは、SAP の未加工のテーブルを明確なビジネス用語に変換し、カスタムフィールドを動的に取り込み、高度なロジック（SAP TCURX の通貨の小数点の移動など）をネイティブに処理することで、大規模言語モデル（LLM）との対話やエンタープライズ分析に必要な高いデータ精度を担保します。

BigQuery 内にデプロイされた SAP ERP 向け Cortex Framework v7 のデータプロダクトを示す画像。フィールド名や説明文などの、組み込みの説明メタデータが含まれている。

これらの SAP ERP と SAP Business Data Cloud 向け専用データプロダクトアクセラレータは、BigQuery に直接デプロイされます。デプロイが完了すると、Knowledge Catalog への自動登録が実行され、データを簡単に見つけ出して AI エージェントに接続できるようになります

説明文とラベルの組み込みメタデータを備え、Knowledge Catalog に登録された Cortex Framework v7 データプロダクトを示す画像。

カスタム AI プロジェクトを加速させるため、このリリースには、データエンジニアやナレッジエンジニアが自然言語を使用してカスタムデータプロダクトを生成できるようにするエージェント型データプロダクトビルダー向けのエージェントスキルも搭載されています。フレームワークが提供するコンテンツを活用することで、AI エージェントは、特定のソースデータ要件やカスタマイズへの適応を含め、ビルドプロセスを自動的に実行することができます。

Cortex Framework v7 で提供されるエージェント型データプロダクトビルダーのスキルを、Google Antigravity と Gemini を使用して実際に活用し、自然言語プロンプトを使用して新しいデータプロダクトのビルドとデプロイを自動化する様子を示す GIF。

v7 では、Cortex Framework を拡張して、Cortex Framework 標準のコンテンツとカスタムモデルを明確に分離した状態で管理することも可能です。これにより、独自のカスタマイズに影響を与えることなく、最新のコード更新を取り込むことができます。

2. モジュール式デプロイで迅速に構築する

Dataform は、Cortex Framework v7 のモダナイズされたデータパイプラインを支える基盤であり、バージョン管理された SQL やネイティブの依存関係管理機能を提供します。デプロイ対象のパッケージ化されたデータプロダクトを選択すると、Cortex Framework は必要なテーブルのみを取得して処理します。依存関係の解決により、実行順序が自動的に管理され、効率的な処理を可能にする依存関係グラフが生成されます。また、標準モデルに影響を及ぼすことなく、独自のフィールドやロジックを追加可能です。

Dataform の Cortex Framework v7 データプロダクトを示す画像。データアセットとテーブルの依存関係を示す自動依存関係グラフと、自然言語タグなどの組み込みメタデータが表示されている。

このモジュール式のアプローチは、複雑なマルチシステム SAP 環境にもネイティブに対応しています。Dataform は、組み込みのロジック差別化を使用して、SAP ECC、SAP S/4HANA、SAP BDC ソースシステム用の Cortex Framework データプロダクトを並行してコンパイルおよびデプロイします。また、動的スキーマ検出により、Z フィールドなどのカスタム SAP フィールドを自動的に取り込んで処理します。これらの機能を組み合わせることで、複数のシステムから同時にデータを取り込めるようになり、パイプラインを手動でリファクタリングする手間を削減できます。

3. 柔軟な処理で費用対効果の高いスケーリングを実現する

Cortex Framework では、BigQuery の増分読み込みと非破壊的なスキーマ更新がデフォルト設定になりました。これにより、新規または変更されたデータのみが処理されます。このアプローチにより、コンピューティング時間を最小限に抑え、運用費用を大幅に削減できます。オーケストレーションは Dataform のサーバーレスかつ BigQuery ネイティブな実行環境を利用しているため、インフラストラクチャのオーバーヘッドを増やすことなくデータ処理をスケールできます。

また、お客様独自の（BYO）変更データキャプチャ（CDC）アプローチを使用することも可能です。このアプローチを使用すると、組み込みの CDC データ処理をバイパスして、既存の CDC 処理済みパイプラインを直接接続できます。

SAP Business Data Cloud との相互運用性

SAP Business Data Cloud Connect for BigQuery の先日の一般提供開始に伴い、Cortex Framework v7 は SAP BDC の標準データプロダクトとカスタムデータプロダクトをネイティブにサポートするようになりました。Cortex Framework で提供されるデータプロダクトと SAP BDC データプロダクトを組み合わせることで、新たなビジネスチャンスを見出すことができます。これを加速するために、v7 には SAP BDC と SAP ERP の両方のデータにわたるソリューションサンプルが含まれており、セールスパイプラインの健全性の評価や調達の非効率性の特定など、幅広い重要な課題に迅速に対応できます。

SAP Business Data Cloud Connect for BigQuery のインテグレーションを介して、SAP BDC をソースとするデータプロダクトにデプロイされた Cortex Framework v7 の消費データプロダクトソリューションサンプルを示す画像。

業界のリーダーとの共同イノベーション

Google は、Professional Services Organization や業界のリーダーと緊密に連携して、これらの新機能をテストしてきました。これらの組織は、Google のライトハウスカスタマーとして貴重なフィードバックを提供し、エンタープライズ規模のアジリティと AI への対応力を備えたフレームワークの形成に貢献してくれました。

「Cortex Framework の既存顧客として、最新の v7 リリースで導入された機能に非常に期待しています。Google Cloud AI 機能で複雑な SAP ECC 環境と S/4 環境を橋渡しするには、正確なビジネスコンテキストを備えた信頼できるデータ基盤が必要です。エージェント型データプロダクトビルダーを含む Cortex Framework v7 で発表された機能に基づき、分析とエージェント型 AI のユースケース向けにエンタープライズデータプロダクトの構築を加速し、スケールさせる大きな可能性が見込まれます。このプラットフォームの方向性は、SAP データをよりアクセスしやすく、セマンティックに意味のあるものにし、将来のレポート作成や AI イニシアチブをサポートする体制を整えたいと考えている組織にとって、特に有望です。」 - SLB、データおよび分析担当ディレクター、Jwan Ibrahim 博士

使ってみる

Cortex Framework v7 は、企業が AI エージェント向けに最も重要なデータを運用化する方法を変革します。Google Cloud は、サーバーレス実行、AI 対応のセマンティクス、ネイティブの SAP インテグレーションを組み合わせることで、複雑なエンタープライズデータを戦略的アセットに変えるための支援を提供します。実際にやってみるには、以下のリソースをご覧ください。

デプロイを実行する: Cortex Framework のデモデプロイ（事前定義されたサンプルデータセットを使用）を試して、最初の v7 データプロダクトを今すぐお試しください。
詳細: Cortex Framework v7 の包括的な技術ドキュメントで、本番環境へのデプロイ手順、構成、拡張性、ソースシステムのインテグレーション、パッケージ化されたデータプロダクトについて詳しくご確認ください。
エキスパートに相談する: Google Cloud のアカウントチームにお問い合わせいただき、Cortex Framework v7 がお客様固有のデータから AI への活用プロセスをどのように加速できるかをご確認ください。

- Google Cloud、Cortex Framework GTM 担当マネージングディレクター、Snehanshu Shah

SAP Business Data Cloud Connect for BigQuery の一般提供開始のお知らせ

Fri, 07 Aug 2026 01:00:00 +0000

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

従来のデータレプリケーション手法では、最新のワークフローで必要とされるデータの鮮度を維持することが困難な場合が多くあります。こうした課題を克服できるよう、このたび、SAP と Google Cloud は、SAP Business Data Cloud Connect（BDC）for BigQuery の一般提供を開始しました。

両社の長年にわたるパートナーシップの新たなフェーズを示す SAP BDC Connect for BigQuery は、SAP Business Data Cloud と BigQuery にまたがるデータプロダクトへのゼロコピーでのアクセスを可能にするもので、これにより、サイロを削減できるほか、貴重なビジネスコンテキストを保持したまま、分析や AI を高速化できます。また、最新の意味的に豊富なデータを両方の環境で利用できるようになり、AI エージェントが複雑なビジネスタスクを実行できるようになる一方で、チームは引き続き自ら管理を行うことができます。

AI プロジェクトのためのデータコピー作業が不要に

ゼロコピーアーキテクチャをサポートするように構築された SAP BDC Connect for BigQuery は、SAP Business Data Cloud と Google のデータおよび AI エコシステムとの間に、セキュアな双方向接続を確立します。BigQuery や Knowledge Catalog（旧称 Dataplex）から、SAP テーブル、メタデータ、ビジネスセマンティクスに直接アクセスでき、その逆も可能です。これにより、AI エージェントを、元データや孤立したデータベースフィールドではなく、実際の業務状況に基づいて運用できます。SAP BDC Connect for BigQuery により、以下のことが可能になります。

信頼できるデータに基づいた AI のスケーリング: SAP Business Data Cloud と BigQuery にまたがるデータプロダクトへのライブかつゼロコピーでのアクセスにより、意味的に豊富なデータ基盤にグラウンディングされた、ガバナンスが確立された信頼性の高い AI を構築します。
マルチエージェントワークフローのデプロイ: Gemini Enterprise Agent Platform と SAP Joule を使用して、SAP と Google 全体でインテリジェントエージェントによるワークフローをオーケストレートします。
より深いパターンを発見: ミッションクリティカルな SAP データと、Google トレンドや Google マップの地理空間データなどの独自のデータセットと組み合わせて、より優れたビジネスコンテキストを作成します。この拡充されたデータは、SAP に直接公開することもできます。
ビジネス分析の改善: Gemini Enterprise や Joule を使用して、自由回答形式のビジネス上の質問を自然言語で行うと、SAP と Google Cloud のデータに基づいた、コンテキストを考慮した回答を即座に受け取ることができます。

費用を抑えながらデータの価値を拡大

SAP BDC Connect for BigQuery のゼロコピーアーキテクチャは、データの複製、保存、重複コピーの維持管理の必要性を最小限に抑えることで、他のデータプラットフォームと比較して総所有コスト（TCO）を低減できます。データをその場でクエリできるため、データ共有の料金は発生しません。これにより、予期しない追加料金を防ぎ、組織にとって予測しやすい課金モデルを実現できます。

共有データを行動に変える

SAP BDC Connect for BigQuery のプレビュー版を利用している多くのお客様が、すでにこのゼロコピーアーキテクチャを活用して、より複雑な運用上の課題を解決しています。たとえば、データパイプラインを高速化することで、グローバルなデータサイロを解消し、サプライチェーンの混乱を予測して、変動する顧客需要に迅速に対応しています。これに対し、従来のデータ連携ではデータ接続の構築に数週間を要し、AI プロジェクトが停滞することがありました。SAP と Google のデータを直接やり取りすることで、機能的なプロトタイプを迅速に構築できるほか、AI 投資の回収を加速できます。

ElringKlinger は、複数の国にまたがる複雑な製造およびサプライチェーンデータを管理するグローバルな自動車部品サプライヤーであり、ゼロコピーを使用してデータサイロの解消を進めています。同社は、データを複製することなくリアルタイムの ERP データをクエリすることで、データインフラストラクチャの複雑さを軽減しつつ、地域ごとの在庫レポートを含む迅速な生産分析を支援することを目指しています。

「グローバルに自動車事業を展開するということは、膨大で複雑なサプライチェーンと生産データを管理することを意味します。現在、そのデータの大部分は、当社が確立したレポート機能のバックボーンである SAP BW/4HANA に集約されています。SAP BDC Connect for BigQuery をテストしたところ、強力な新しい道が開けました。既存の BW/4HANA アセット上に分析レイヤとして BigQuery を使用することで、データのコピーや移行を必要とせずに、これまでの投資を完全に維持しながら、AI ベースの会話型分析が可能になりました。また、サプライチェーンプロセスを自動化するエージェントユースケースの基盤も整い、世界中の製造状況をリアルタイムで可視化できるようになりました。」- ElringKlinger、プロジェクトマネージャー Cleve Bankston 氏、IT アーキテクチャ責任者 Dirk Brümmer 氏

パートナーとの連携: データを統合してスマートなワークフローを構築

SAP と Google Cloud のグローバルパートナーネットワークでは、SAP BDC Connect for BigQuery を活用したユースケースが積極的に構築されています。こうしたユースケースは、孤立した AI の実験段階から脱却するのに役立ち、手動での管理が困難な変動の激しいタスクに対処できるようチームの能力を強化できます。これを実現するために、多くのパートナーが信頼性の高い SAP データと幅広いデータソースを組み合わせて、エージェント型 AI や自律的な運用を展開できるよう支援しています。この統合的なアプローチにより、チームは分散したシステムを連携させ、ガバナンスを維持しつつ、収益に直接貢献する業務を推進できます。

「企業が変革の取り組みを加速させるなか、ビジネスシステム全体のデータを統合する能力は、エージェント型 AI をスケールするための基盤となります。その点において、SAP Business Data Cloud Connect for BigQuery は非常に強力であり、信頼性の高い財務、運用、サステナビリティのデータにリアルタイムでアクセスできるようになることで、従来のデータサイロを解消できます。これに、Accenture が持つ業界の深い専門知識と Gemini Enterprise を組み合わせることで、組織はインテリジェントエージェントを構築できるほか、自律的な運用を推進して、デジタルコアをより迅速にモダナイズしながら、新たなレベルのビジネス価値を引き出すことができます。」– Accenture Google ビジネスグループ、グローバルプラクティスリード、Chetna Sehgal 氏

「組織が求めているのはデータサイエンスプロジェクトではなく、運転資本の改善や運用コストの削減といった具体的なビジネス成果です。当社は、このゼロコピー統合を活用して、クライアント向けの自律型調達エージェントを構築しました。このエージェントは、BigQuery 内の SAP の在庫レベルと市場データを同時に読み取るため、サプライヤーを最近変更した際も、注文の再ルーティングを自律的に行うことができました。これにより、数百万ドルもの損失に及ぶ可能性があるダウンタイムを回避できたほか、リアルタイムデータに結び付けられたエージェント型 AI が収益に直接的な影響をもたらすことを実証できました。」 - Deloitte Consulting LLP、マネージングディレクター、Piyush Bhandari 氏

「KPMG メンバーファームのエネルギー業界のお客様の最近の評価とプロトタイピングの結果から、SAP BDC Connect for BigQuery には、企業の計画業務、分析、データ統合をスケーラブルな基盤の上でモダナイズするうえで大きな可能性があると考えています。KPMG ファームの評価では、この統合により、エンタープライズ規模で大量の分析ワークロードをサポートできるほか、将来の AI やエージェントのユースケースを探求するための重要なデータ基盤を提供できることが示されています。あらゆる変革と同様に、ビジネス価値を最大限に引き出すには、実装のアプローチ、データ品質、組織の準備状況が重要になります。」 - KPMG US、Google 部門プリンシパル、アドバイザリー、バンキング、テクノロジーおよびデータエンジニアリング担当、Mark Shank 氏

「お客様は、単に多くの情報を求めているのではなく、より適切なビジネス上の意思決定を求めています。PwC は、SAP のビジネスデータを Google Cloud 内のより広範なエンタープライズデータソースと統合できるよう支援しています。これにより、AI のための単一かつ信頼性の高い基盤が構築され、分析が強化され、堅牢なガバナンスとコンプライアンスがサポートされ、企業全体でインテリジェントなワークフローが推進されます。この統合的なアプローチによって、組織は孤立した AI の実験段階から脱し、真の全社的なビジネス変革へと移行できるようになります。」- PwC US、グローバルおよび米国アライアンスおよびエコシステムリーダー、Patrick Pugh 氏

エージェント型データの力: SAP と Google Cloud の視点

「あらゆる企業が、事業運営の中核にインテリジェンスと自動化を組み込もうとしています。SAP Business Data Cloud と BigQuery、そして Gemini を統合することで、私たちはエンタープライズデータにおける最大級の壁を打ち破ろうとしています。データ共有コストをゼロに抑えながら、意味的に豊富なメタデータやエージェントコンテキストをプラットフォーム間で積極的に共有することで、単なる元データへのアクセスをはるかに超える価値を提供できるようになります。これにより、両社共通のお客様は、リアルタイムのビジネス状況を完全に把握しながら動作する自律型 AI エージェントをデプロイでき、その結果、複雑なサプライチェーンや財務プロセスを極めて高い精度で実行できるようになります。」- Google Cloud、Agentic Data Cloud 担当バイスプレジデント兼ゼネラルマネージャー、Andi Gutmans

「SAP Business Data Cloud Connect for Google BigQuery は、リアルタイムかつ双方向のゼロコピーデータ共有を実現し、SAP のミッションクリティカルなデータを Google BigQuery に取り込んで、Google Gemini や Gemini Enterprise Agent Platform からアクセスできるようにします。SAP BDC Connect を利用することで、複雑なデータ抽出やカスタム API を必要とせずに SAP データと非 SAP データを統合でき、データの複雑性を軽減し、ガバナンスを強化し、AI を活用した信頼性の高いビジネス成果を加速させることができます。」- SAP、データ分析担当プレジデント兼最高製品責任者、Irfan Khan 氏

ご利用いただけるリージョン

SAP Business Data Cloud: オーストラリア（シドニー）、ブラジル（サンパウロ）、インド（ムンバイ）、イスラエル（テルアビブ）、ドイツ（フランクフルト）、日本（大阪）、サウジアラビア（ダンマーム）、米国（アイオワ）の Google Cloud リージョンでご利用いただけます。
SAP BDC Connect for BigQuery: すべての Google Cloud のお客様を対象に、グローバルに一般提供されています。
クロスクラウドサポート: SAP BDC Connect for BigQuery は、Google Cloud と AWS でホストされている SAP Business Data Cloud インスタンスに対応しています。Microsoft Azure でホストされている SAP Business Data Cloud インスタンスのサポートは近日提供予定です。

使ってみる

詳しくは、Google のウェブサイトをご覧いただくか、Google Cloud アカウント担当者にお問い合わせください。SAP BDC Connect for BigQuery の使用方法とゼロコピー接続の詳細については、ドキュメントページをご覧ください。

- Google Cloud、Cortex GTM 担当マネージングディレクター、Snehanshu Shah

- SAP Business AI Platform、最高収益責任者、Jan Bungert 氏

BigQuery と %%bqsql マジックで SQL と Python のギャップを埋める

Tue, 04 Aug 2026 01:00:00 +0000

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

データサイエンティストとデータエンジニアは SQL と Python の使い分けに頭を悩ませることがよくあります。特に BigQuery のような強力なエンジンと組み合わせて大規模データを処理する場合に、SQL はより直感的に使えると感じる人がいる一方、ライブラリやランタイムの豊富なエコシステムを活用できる Python の方が使いやすいと感じる人もいます。従来、1 つのノートブックでこれらの言語を併用するには、まずデータを SQL の結果からインメモリに移動し、Python のメモリから一時テーブルに書き込んだうえで、SQL からアクセスする必要がありました。

この手間を解消するため、Google Cloud チームは Colab Enterprise に SQL セルを導入しました。このたび、そのシームレスな体験を、より広範なオープンソースエコシステムへと拡大しました。今後は %%bqsql IPython セルマジックを使用して、SQL と Python のコードセル間でデータ処理ワークロードを簡単に連携させることができます。

Jupyter、pandas、BigFrames、BigQuery サンドボックスなどのオープンソースパッケージのおかげで、このガイドに記載されたすべての手順は無料で*クレジットカードなしで実行していただけます。

* 制限事項については、BigQuery サンドボックスのドキュメントをご確認ください。

環境を設定する

事前準備：

1. BigQuery サンドボックスを有効にします。Google Cloud プロジェクト ID をメモしておきます。

2. ローカルの Python 開発環境を設定するか、Python 環境がすでにインストールされている Colab でこのノートブックを開きます。

ローカルの Python 環境を設定する方法については、Google Cloud ドキュメントの手順をご確認ください。ローカルの Python 環境を設定する場合は、次の手順に進みます。設定しない場合は、次のセクションにスキップしてください。

3. 前のステップで作成した venv を有効にして、Python の依存関係を分離します。

Linux または macOS では、次のコマンドを使用します（お好みの Python バージョンに更新してください）。

code_block: <ListValue: [StructValue([('code', '. ./env/bin/activate'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304a60>)])]>

4. Jupyter、bigframes、python-calamine パッケージをインストールします。

code_block: <ListValue: [StructValue([('code', 'pip install --upgrade jupyterlab bigframes python-calamine'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304220>)])]>

5. JupyterLab を起動します。

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

6. ウェブブラウザを開き、出力に表示された URL にアクセスします。表示される URL は、http://localhost:8888/lab?token=somesupersecretvaluehere のような形式になります。

7. Jupyter Lab UI を使用して新しいノートブックを作成します（[File] > [New] > [Notebook]）。または、BigQuery DataFrames GitHub リポジトリからこのチュートリアルに関連付けられたノートブックをダウンロードして開きます。

ローカルデータにアクセスして準備する

このチュートリアルでは、USDA の小麦データを分析します。Pandas はデータをダウンロードし、一般的なローカルデータ分析ワークフローを模倣します。

code_block: <ListValue: [StructValue([('code', 'url = "https://www.ers.usda.gov/media/5706/wheat-data-all-years.xlsx?v=52690"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304910>)])]>

次に、データをローカルの pandas DataFrame に読み込みます。SQL 処理用のローカルの pandas データを準備する際は、pyarrow dtype_backend を使用します。これにより、データを BigQuery SQL エンジンに渡す際の NULL 値の処理で一貫性が維持され、スキーママッピングもシームレスに行えるようになります。この例では、小麦の年間供給量と消失量のデータが含まれている「Table05」シートを読み込みます。

code_block: <ListValue: [StructValue([('code', 'import pandas as pd\r\n\r\ndf = pd.read_excel(\r\n url,\r\n sheet_name="Table05",\r\n dtype_backend="pyarrow",\r\n engine="calamine",\r\n header=1, # Skip the first row.\r\n)\r\ndf'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304040>)])]>

SQL でローカルの DataFrame に対してクエリを実行する前に、SQL に適した列名になっているか確認してください。BigQuery は柔軟な列名をサポートしており、ほとんどの Unicode 文字を使用できますが、"/" や "" などの特殊文字は削除または置き換えておく必要があります。

code_block: <ListValue: [StructValue([('code', 'df.columns = [name.replace("/", "") for name in df.columns]\r\ndf'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e3042b0>)])]>

標準的な Python と pandas の構文を使用して基本的なフィルタリングを行い、欠損データのある行を削除します。これは、処理チェーンにおける最初の Python のみのステップとなります。

code_block: <ListValue: [StructValue([('code', "full_rows = df[~df['Beginning stocks'].isna()]\r\nfull_rows"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304b80>)])]>

BigQuery SQL マジックを初期化する

BigQuery DataFrames ライブラリには、Python 環境と SQL 環境の橋渡し役となる %%bqsql マジックが用意されています。このマジックを使うことで、BigQuery クエリエンジンがローカルの pandas DataFrame（一時テーブルとして暗黙的にアップロードする）だけでなく、実際の BigQuery テーブルや、GCS（Parquet、Iceberg、CSV）内の外部テーブルを直接参照してクエリできるようになります。

ノートブックでこの統合を有効にするには、bigframes 拡張機能を読み込みます。

code_block: <ListValue: [StructValue([('code', '%load_ext bigframes'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304940>)])]>

注: この拡張機能は、BigQuery Studio 環境と Colab 環境にプリロードされています。

無料枠内での利用を含め、クエリの使用料が適切な Google Cloud プロジェクトに対して課金されるように、マジックで使用するプロジェクト ID を設定します。無料のサンドボックスティアであっても、クエリリソースを割り当てるにはプロジェクト ID が必要です。明示的に設定しない場合、BigFrames は環境（アプリケーションのデフォルト認証情報など）から検出を試みます。

code_block: <ListValue: [StructValue([('code', 'import bigframes.pandas as bpd\r\n\r\nbpd.options.bigquery.project = "your-project-id-here"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304250>)])]>

SQL を使用したローカルの pandas DataFrame にクエリを実行する

プロジェクトの設定が完了し、ローカルの pandas DataFrame（full_rows）に対して BigQuery のテーブルと同様に、SQL クエリを直接実行できるようになりました。SQL クエリ内で、変数名を波括弧 {full_rows} で囲んで記述するだけです。認証コードの入力を求められる場合がありますが、その場合は同じメッセージに含まれているリンクをクリックして認証コードを取得してください。

code_block: <ListValue: [StructValue([('code', '%%bqsql\r\nSELECT * FROM {full_rows}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304d90>)])]>

SQL と Python のチェーン: SQL の結果を保存する

%%bqsql マジックの真の力は、処理を連結できる点にあります。%%bqsql の引数に保存先の変数名を指定すると（例: %%bqsql destination_var）、クエリ結果が BigQuery DataFrame としてその変数に保存されます。

この DataFrame は BigQuery エンジン上で処理されますが、Python では pandas DataFrame と同じように操作できます。この結果は、後続の Python セルですぐに使用したり、別の SQL セルから再度参照したりできます。これにより、マルチステップのハイブリッドな処理パイプラインを構築できます。

SQL を使用してデータをフィルタリングし、年単位のエントリのみを抽出して、その結果を「yearly」という名前の新しい BigFrames DataFrame に保存します。

code_block: <ListValue: [StructValue([('code', "%%bqsql yearly\r\nSELECT *\r\nFROM {full_rows}\r\nWHERE STARTS_WITH(`Time period`, 'MY')"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304e20>)])]>

これで、別の SQL オペレーションをチェーンできます。作成したばかりの年単位の BigFrames DataFrame を参照し、SQL の正規表現を使用して年を抽出します。それをタイムスタンプにキャストして、結果を timeseries という名前の新しい BigFrames DataFrame に保存します。

code_block: <ListValue: [StructValue([('code', "%%bqsql timeseries\r\nSELECT\r\n * EXCEPT (`Marketing year 1`),\r\n TIMESTAMP(CONCAT(\r\n REGEXP_EXTRACT(`Marketing year 1`, r'([0-9]+)\\/'),\r\n '-01-01')) AS `year`\r\nFROM {yearly}"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304d30>)])]>

Python から SQL、そして再び Python へと処理のチェーンが構築されていることに注目してください。

Python に戻って可視化する

SQL 変換が完了したので、次は Python へとチェーンを戻して可視化を行います。BigFrames の DataFrame は pandas API を実装しているため、データセット全体を事前にダウンロードすることなく、標準的な可視化メソッド（.plot.line() など）を時系列 DataFrame で直接呼び出すことができます。計算は BigQuery で行われ、要約されたグラフデータのみがノートブックに返されます。

code_block: <ListValue: [StructValue([('code', "timeseries.set_index('year').sort_index().plot.line()"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304cd0>)])]>

または、時系列を pandas DataFrame としてダウンロードして、選択した可視化ライブラリで使用することもできます。

code_block: <ListValue: [StructValue([('code', "pddf = timeseries.set_index('year').sort_index().to_pandas()"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304b20>)])]>

ハイブリッドパイプラインが重要である理由

BigQuery DataFrames と %%bqsql マジックを組み合わせることで、SQL と Python をシームレスに橋渡しする強力で相互運用性に優れたパイプラインが構築されました。

ローカルの pandas df と full_rows DataFrame
SQL フィルタへ
BigFrames の yearly DataFrame へ
SQL 変換へ
BigFrames の timeseries DataFrame へ
Python によるデータ可視化へ
ローカルの pandas DataFrame へ

このアーキテクチャの主な利点:

最適なツールの使い分け: SQL が得意な処理（大規模な集計、ウィンドウ関数、複雑な結合）は SQL に、Python が得意な処理（可視化、統計モデリング、ML オーケストレーション）は Python に任せられます。
コードの可読性が向上: 数十もの共通テーブル式（CTE）が連なる巨大な SQL クエリを書いたり、SQL に比べて複雑になりがちな pandas API で集計を行ったりする代わりに、パイプラインを論理的なステップに分割し、SQL と Python を交互に組み合わせて記述できます。
シームレスなスケーリング: %%bqsql コードは、ローカルの小さな pandas DataFrame から本番環境の BigQuery テーブルの数十億行まで、まったく同じコードでスケールできます。最初のローカルの pandas DataFrame を BigQuery DataFrame 参照に置き換えるだけです。

次のステップとスケールアップ

BigFrames API リファレンスサイトでその他のノートブックもご確認ください。%%bqsql セルマジックに加えて、BigFrames は標準の pandas DataFrame に BigQuery Accessor も登録します。これにより、ローカルの pandas データに対して SQL スカラー関数を直接実行できるようになります。

たとえば、df.bigquery.sql_scalar(...) を使用して、BigQuery Utils、BigFunctions、CARTO Analytics Toolbox for BigQuery などで公開されている Google Cloud コミュニティの強力な UDF を呼び出すことができます。

code_block: <ListValue: [StructValue([('code', 'import pandas as pd\r\nimport bigframes.pandas as bpd # Registers the accessor\r\n\r\nbpd.options.bigquery.project = "your-project-id"\r\ndf = pd.DataFrame({"x": [1, 2, 3]})\r\npandas_s = df.bigquery.sql_scalar("`bqutil`.fn.cw_setbit({x}, 2)")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e3048e0>)])]>

BigQuery サンドボックスは、これらのハイブリッド Python-SQL ワークフローを無料でテストできる強力な環境ですが、BigQuery Machine Learning（BQML）などの高度な機能は制限されています。請求先アカウントを Google Cloud プロジェクトに接続すると、bigframes.bigquery.ai.forecast 関数などの高度な機能を利用できるようになります。この関数を使用すれば、SQL と Python のチェーンで Google 最先端の基盤モデルを直接使用して時系列データを予測できます。

code_block: <ListValue: [StructValue([('code', 'forecasted_pandas_df = (\r\n pddf\r\n .reset_index(drop=False)\r\n .bigquery.ai.forecast(\r\n data_col="Production",\r\n timestamp_col="year",\r\n horizon=10,\r\n )\r\n)\r\n\r\n# Plot the results\r\nforecasted_pandas_df_sorted = forecasted_pandas_df.sort_values(by=\'forecast_timestamp\')\r\nplt.plot(pddf.index, pddf[\'Production\'], label=\'Real Production\', color=\'blue\')\r\nplt.plot(forecasted_pandas_df_sorted[\'forecast_timestamp\'], forecasted_pandas_df_sorted[\'forecast_value\'], label=\'Forecasted Production\', color=\'red\', linestyle=\'--\')\r\nplt.fill_between(\r\n forecasted_pandas_df_sorted[\'forecast_timestamp\'],\r\n forecasted_pandas_df_sorted[\'prediction_interval_lower_bound\'],\r\n forecasted_pandas_df_sorted[\'prediction_interval_upper_bound\'],\r\n color=\'red\',\r\n alpha=0.2,\r\n label=\'Confidence Interval\'\r\n)\r\n# ...\r\nplt.show()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e304c10>)])]>

ハイブリッド Python-SQL エクスペリエンスに関するフィードバックを BigFrames チームまでぜひお寄せください。

メール: bigframes-feedback@google.com
問題: オープンソースの BigFrames リポジトリでバグ報告や機能リクエストを提出してください。
最新情報: ニュースや最新情報を受け取るには、BigFrames のメーリングリストにご登録ください。
詳細: ドキュメントで BigFrames API リファレンスとユーザーガイドをご確認ください。

- BigQuery DataFrames チームリーダー、Tim Swena

列レベルのセキュリティを強化: BigQuery で IAM データガバナンスタグを使用する

Tue, 04 Aug 2026 01:00:00 +0000

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

BigQuery のお客様の多くは、機密情報を保護するためにポリシータグを利用しています。ポリシータグは、列レベルのアクセス制御を適用するための主要なソリューションであり、適切な権限を持つユーザーのみが個人情報（PII）などの機密性の高い列を表示できるようにするものです。当時の環境においては、堅牢で効果的なシステムでした。

しかし、データエコシステムは複雑化しており、そのセキュリティを確保するために使用するツールも、それに応じて進化する必要があります。新たな課題としては、複数のリージョンとロケーションにわたって複数のタグをサポートする分類の作成と管理、障害復旧の実現、広範な一元化されたガバナンス戦略との統合などが挙げられます。

今日のデータエコシステムのニーズに対応するため、BigQuery でデータガバナンスタグのプレビューが導入されました。Google Cloud の Identity and Access Manager（IAM）の Resource Manager インフラストラクチャ上に構築されたデータガバナンスタグは、スケーラブルで堅牢な方法を提供することで、アクセス制御の管理と BigQuery 列データの保護を支援します。

IAM データガバナンスタグとは

データガバナンスタグは、特殊なタイプの Resource Manager タグです。このタグは、IAM でタグキーを作成するときに、目的フィールドを DATA_GOVERNANCE に設定することで作成し、BigQuery の列レベルのセキュリティで使用するように指定します。列データのガバナンスを目的としたデータガバナンスタグの階層ツリーを作成し、BigQuery 列に直接適用できます。

列レベルのセキュリティにデータガバナンスタグを使用する理由

グローバルスコープ、リージョンごとの適用: ポリシータグ（リージョンのみ）とは異なり、データガバナンスタグはグローバルに適用されます。組織レベルで 1 つのタグキーと値のペア（「data_sensitivity:high」など）を定義し、組織内のあらゆるプロジェクトやリージョンで使用できます。
マネージド障害復旧: セキュリティポリシーはフェイルオーバー中も維持する必要があります。データガバナンスタグとそれに関連するデータポリシーは、セカンダリリージョンに自動的に複製されます。必要に応じてリージョンを切り替えても、セキュリティポスチャーは自動的に移行されます。
階層型セキュリティ: タグのツリーを最大 5 階層まで構築できるようになりました。これにより、継承とより詳細な分類（PII > Financial > CreditCardNumber など）が可能になります。
ガバナンスの分離: セキュリティを適用する前に、データをタグ付けして整理、分類できます。アクセス制御は、そのタグのデータポリシーを定義した後にのみ適用されるため、データのオンボーディング時に柔軟に対応できます。

列レベルのセキュリティを実装する 3 つのステップ

ステップ 1: タグキーと値を作成する

1. データガバナンスタグキーを作成する: まず、コンソール、gcloud CLI、または API で IAM タグキーを作成します。このタグキーの目的フィールドを --purpose=DATA_GOVERNANCE と指定するだけで、データガバナンスタグキーになります。このキーの変更により、このタグが BigQuery の列レベルのセキュリティに使用されることが Google Cloud に通知されます。

code_block: <ListValue: [StructValue([('code', '# Example: Creating a Data Governance tag key named "data_class"\r\ngcloud resource-manager tags keys create data_class \\\r\n --parent=projects/my-governance-project \\\r\n --purpose=DATA_GOVERNANCE'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b45b0>)])]>

2. タグ値を作成する

データガバナンスタグキーを作成したら、そのキーの下に、列データの分類に使用するタグ値を設定する必要があります。データガバナンスタグの便利な機能の一つが、タグ値の階層ツリーを構築できることです。タグ値のツリーでは、まず大まかなカテゴリを作成し、そこからデータタイプに基づいてより詳細なカテゴリにドリルダウンしていくことができます。最大 5 階層の深さまでのツリーを構築できるため、きめ細かいアクセス制御が可能になります。

code_block: <ListValue: [StructValue([('code', '# Level 1: Create a tag value called "pii"\r\ngcloud resource-manager tags values create pii \\\r\n --parent=my-governance-project/data_class\r\n\r\n\r\n# Level 2: Create a child value under "pii" for "private" data\r\ngcloud resource-manager tags values create private \\\r\n --parent=my-governance-project/data_class/pii\r\n\r\n\r\n# Level 3: Create another child tag value for "email" under "private"\r\n# You can go up to 5 levels deep for granular control\r\ngcloud resource-manager tags values create email \\\r\n --parent=my-governance-project/data_class/private'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b45e0>)])]>

ステップ 2: JSON スキーマを使用して列にタグを付加する

1. 既存のスキーマをエクスポートする

既存のテーブルの場合、タグを管理する最も効率的な方法は、JSON ファイルを使用して API または bq CLI でテーブルスキーマを更新することです。これにより、複数の列に一度にタグを付けることができます。

code_block: <ListValue: [StructValue([('code', '# Save the current table schema to a local JSON file.\r\nbq show --schema --format=prettyjson my_project:my_dataset.my_table > schema.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b4fa0>)])]>

2. dataGovernanceTags を JSON ファイルに追加する

schema.json を開き、機密性の高い列へのタグマッピングを追加します。名前空間付きのキーと値の略称が使用されていることに注意してください。

code_block: <ListValue: [StructValue([('code', '[\r\n {\r\n "name": "user_email",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "email" \r\n }\r\n }\r\n },\r\n {\r\n "name": "phone_number",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "private"\r\n }\r\n }\r\n },\r\n {\r\n "name": "government_id",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "pii"\r\n }\r\n }\r\n }\r\n]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b47f0>)])]>

3. テーブルを更新する

スキーマを BigQuery テーブルに適用します。

code_block: <ListValue: [StructValue([('code', '# Overwrite the table schema with your newly tagged JSON file.\r\nbq update --project_id=my-data-project --schema=schema.json my_dataset.my_table'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b46d0>)])]>

また、SQL を使用してデータガバナンスタグを BigQuery テーブルの列にバインドすることもできます。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE TABLE my_dataset.my_table(\r\n user_email STRING\r\n OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'email')]),\r\n );\r\nALTER TABLE my_dataset.my_table\r\nALTER COLUMN phone_number\r\n SET OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'private')]);\r\nALTER TABLE my_dataset.my_table\r\nADD COLUMN government_id\r\n STRING\r\n OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'pii')]);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b44f0>)])]>

また、列タグを削除するには、次のように [] に設定します。

code_block: <ListValue: [StructValue([('code', 'ALTER TABLE my_dataset.my_table\r\nALTER COLUMN phone_number\r\n SET OPTIONS (\r\n data_governance_tags = []\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b4ee0>)])]>

information_schema COLUMNS ビューを使用して、列タグを確認できます。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n column_name,\r\n data_governance_tags[SAFE_OFFSET(0)].key AS tag_key,\r\n data_governance_tags[SAFE_OFFSET(0)].value AS tag_value,\r\nFROM `my_project.my_dataset.INFORMATION_SCHEMA.COLUMNS`\r\nWHERE table_name = 'my_table'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b4f10>)])]>

次のような結果になります。

code_block: <ListValue: [StructValue([('code', '+---------------+----------------------------------+-----------+\r\n| column_name | tag_key | tag_value |\r\n+---------------+----------------------------------+-----------+\r\n| user_email | my-governance-project/data_class | email |\r\n| phone_number | my-governance-project/data_class | private |\r\n| government_id | NULL | NULL |\r\n+---------------+----------------------------------+-----------+'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b42b0>)])]>

ステップ 3: データポリシーを作成する

最後に、BigQuery のデータポリシーを定義して、タグ付けされた列へのアクセスを管理します。これらのポリシーは、以前に付加したタグ値を明示的に参照します。データガバナンスタグはグローバルですが、データポリシーはリージョンに適用される点に注意してください。

データを保護するため、ポリシーは BigQuery テーブルと同じリージョンで作成する必要があります。ポリシーが定義されると、指定されたユーザーのみにアクセス権が付与され、それ以外のすべてのユーザーは機密性の高い列データへのアクセスが拒否されます。

また、BigQuery のセキュリティは階層化されていることに留意してください。データポリシーを有効にするには、ユーザー（被付与者）がまずテーブル自体への基本レベルのアクセス権を持っている必要があります（通常は roles/bigquery.dataViewer などのロールを介して付与される）。これによりデータポリシーは 2 つ目のセキュリティレイヤとして機能し、ユーザーに応じて機密性の高い列の未加工のデータを表示するか、マスクにより難読化されたバージョンを表示するかを決定します。

「pii」タグ付き列データのマスキングポリシー（SHA256 マスキング）

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "DATA_MASKING_POLICY",\r\n "dataMaskingPolicy": { "predefinedExpression": "SHA256" },\r\n "grantees": [ "principalSet://goog/group/grp-sales@corp.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "pii" }\r\n },\r\n "dataPolicyId": "masking_policy_for_data_class_pii"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b43d0>)])]>

「pii」タグ付き列データに対する未加工データアクセスポリシー

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "RAW_DATA_ACCESS_POLICY",\r\n "grantees": [ "principal://goog/subject/abc@xyz.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "pii" }\r\n },\r\n "dataPolicyId": "raw_access_policy_data_class_pii"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b4580>)])]>

「private」タグ付き列データのマスキングポリシー（NULL マスキング）

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "DATA_MASKING_POLICY",\r\n "dataMaskingPolicy": { "predefinedExpression": "ALWAYS_NULL" },\r\n "grantees": [ "principal://goog/subject/abc@xyz.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "private" }\r\n },\r\n "dataPolicyId": "null_policy_data_class_private"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e0b4d00>)])]>

以上の 3 つのステップで、列データの保護は完了です。次回プリンシパルが BigQuery テーブルをクエリすると、Google の認可エンジンが自動的にプリンシパルの ID をデータポリシーと照合して評価します。プリンシパルがポリシーに含まれている場合、ポリシーに従ってマスクされたデータまたは未加工のデータのいずれかが表示されます。プリンシパルがポリシーに含まれていない場合は、アクセスが拒否されます。

使ってみる

データガバナンスタグは、BigQuery のデータセキュリティとガバナンス戦略を強化する強力な新しいツールです。Google は、BigQuery のデータガバナンス機能を強化するために継続的に取り組んでいます。今後のアップデートでは、SQL を使用してタグとタグベースのポリシーを作成する機能、1 つの列に複数のタグを付加する機能、タグの組み合わせに基づいてポリシーを定義する機能、Knowledge Catalog などのサービスとのより深い統合が予定されています。

まずは列へのタグ付けと、きめ細かいアクセス制御を大規模に定義することから始めましょう。詳しくは、データガバナンスタグのドキュメントをご覧ください。

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

- ソフトウェアエンジニア、Pramod Busam

Open Knowledge Format v0.2 におけるエージェントの信頼性担保の取り組み

Fri, 31 Jul 2026 02:30:00 +0000

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

2026 年 6 月に Open Knowledge Format（OKF）を導入した際、Google は「エージェントに必要なコンテキスト（テーブルスキーマ、指標の定義、ランブック）は特定のサービスや非構造化テキストに散在させるのではなく、単一の標準形式として定義されるべきだ」と提言しました。こうした方針のもと、OKF v0.1 はマークダウン、YAML フロントマター、そしていくつかの規則のみで構成されるシンプルな形でスタートしました。

デベロッパーコミュニティからの多大な反響と貢献は、次期バージョンの重点事項を決める指針となりました。リリース以来、コントリビューターによって拡張機能の提案（型付き関係エッジ、エージェントルーティングヒントフィールド、オプションの消去適合性プロファイル、.okfignore 規則など）が作成され、新しいサンプルバンドルが提供されたほか、Google 以外で構築された OKF エコシステムツールのカタログ化も始まりました。こうした貢献やフィードバックの多くは、OKF に関するある大きな懸念を示していました。それは「エージェントによるコーパスへの書き込みは本当に信頼できるのか」という点です。

最も価値のある OKF バンドルは、一度手作業で作成して、その後は読み取られるだけというものではありません。エージェントによって継続的に書き込まれ、また別の一連のエージェントによって使用されるものです。人間が作成した Wiki ページには、暗黙の保証が伴います。それは、人間が書いたものであり、誤りがあった場合は執筆者に責任を問えるという点です。エージェントが一晩で 1 万個のコンセプトを生成する場合、その保証はありません。説明責任を確保するため、コンシューマ（多くの場合、別のエージェント）は、人間に頼る代わりに明示的なシグナルに基づいて各コンセプトを判断し、次の 5 つの質問に答える必要があります。

何をもとに作成されたのか？（来歴）
どの程度信頼できるか？（信頼）
この内容は今でも有効か？（鮮度）
最新のバージョンか？（ライフサイクル）
この数値は指定した方法で生成されたものか？（証明）

OKF v0.2 では、形式は v0.1 と同様に設計上の制約は最小限に抑えながら、フロントマターの情報だけで上の 5 つの質問すべてに回答できるようになりました。追加されるのはルールではなく語彙です。type が唯一の必須フィールドである点は変わらず、新しく追加されたフィールドはすべて任意となります。カスタムキーも拒否されず保持されるため、新しいフィールドを一切使わないバンドルも v0.1 のときと同様に有効なものとして扱われます。新機能のフィールドはすべて任意ですが、フィールドが存在しないこと自体も意味（未検証であること）を持つようになります。これにより、未検証と検証済みのコンセプトを識別できるようになりますが、未検証だからといってエラーとして扱われることはありません。

説明から意思決定まで

v0.1 では、type、title、description、resource、tags といったメタデータがすでにフロントマターに含まれていました。従来のフィールドがコンセプト（それが何であるか、何を指しているか）を説明するものであるのに対し、v0.2 では、コンセプトを読む前にそのコンセプトの妥当性を判断するための新たなフロントマターフィールドが追加されました。たとえば、誰が作成したか、検証済みか、まだ最新か、報告する値をどのように計算すべきかなどの情報がここに含まれます。

これらのフィールドがフロントマターに含まれているのは、コンセプトとのやり取りのほとんどが本文の情報を読み込む手前の段階で終わるためです。コンシューマ（人間、決定論的コード、検索や探索の過程でスキャンを行うエージェントなど）は、まずそのコンセプトにそもそも関連性があるかどうかを判断しなければなりません。コンセプトのあらゆる要素は簡潔であるべきですが、フロントマターの役割はさらに限定的で、関連性と信頼性を判断するために必要なシグナルのみを的確に抽出することに絞り込まれています。そのため、説明文にトークンを費やすことなく、安価かつ頻繁に判断を下すことができます。全文を読み込む必要があるコンテンツは本文に格納され、コンセプトが選択された場合にのみアクセスされます。信頼性は、実際に読み込む前にフィルタリングできるものになります。

以降のセクションの内容を具体的にイメージしていただけるよう、ここからはこの投稿の補足として用意した acme_retail という小規模な OKF v0.2 バンドルから引用した例を使って説明していきます。acme_retail は、BigQuery で AI を活用して分析を行っている架空の米国小売企業の共有ナレッジです。

code_block: <ListValue: [StructValue([('code', 'acme_retail/\r\n├── index.md, log.md\r\n├── tables/ orders.md\r\n├── metrics/ revenue.md, gross-margin.md, gross-margin-legacy.md\r\n├── computations/ revenue-ytd.md, gross-margin-period.md\r\n├── skills/ run-on-bq.md\r\n├── attesters/ sql_equality.py\r\n└── policies/ revenue-recognition.md, margin-standard.md'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e88a0d0>)])]>

以降の各セクションは、対応するファイルの内容を示します。以下は新しいシグナルを伝えるコンセプトである tables/orders.md です。

code_block: <ListValue: [StructValue([('code', "---\r\ntype: BigQuery Table\r\ntitle: Customer Orders\r\ndescription: One row per completed customer order across web, mobile, and marketplace channels. The grain is the order, not the line item.\r\nresource: https://bigquery.googleapis.com/v2/projects/acme/datasets/sales/tables/orders\r\ntags: [sales, orders, revenue]\r\ngenerated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }\r\nverified:\r\n - { by: human:kliu@acme, at: 2026-07-01T16:00:00Z }\r\nstatus: stable\r\nstale_after: 2026-12-31\r\nsources:\r\n - id: warehouse-schema\r\n resource: https://wiki.acme.internal/data/warehouse/schemas/sales\r\n title: Acme Retail warehouse schema — sales dataset\r\n author: team:data-platform\r\n usage_count: 1240\r\n last_modified: 2026-06-15\r\n - id: revenue-policy\r\n resource: policies/revenue-recognition.md\r\n title: Revenue Recognition Policy (FY2026)\r\n author: human:jsmith@acme\r\n last_modified: 2026-06-15\r\n---\r\n\r\n# Schema\r\n\r\n| Column | Type | Description |\r\n|----------------|---------------|----------------------------------------------------------------------------------------|\r\n| `order_id` | STRING | Globally unique order id. [^warehouse-schema] |\r\n| `order_ts` | TIMESTAMP | Order placement time in UTC; drives fiscal-year assignment. [^revenue-policy] |\r\n| `order_status` | STRING | Revenue is recognized only at `'delivered'` and after the 30-day return window. [^revenue-policy] |\r\n| `net_amount` | NUMERIC(18,4) | `gross_amount - discount_amount`. The recognized-revenue amount per policy. [^revenue-policy] |"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e88ae50>)])]>

各ファミリーは 5 つの質問の 1 つに回答します。

来歴: スコアではなくソースを記録

新しい sources フィールドは、コンセプトの派生元となる資料を記録します。外部ドキュメント、バンドル相対パスのほか、「プロジェクト X のすべてのクエリ」といった範囲も指定できます。同時に、各エントリは客観的な信頼性シグナル（author、usage_count、last_modified）を保持できます。

ここで意図的に行ったのは、あえて追加しないという選択です。OKF は信頼性スコアではなく、シグナルを記録します。スコアは主観的なものであり、コンシューマ間での汎用性に欠け、書き込まれた瞬間に古くなってしまいます。その代わりとなる信頼性は、コンシューマがシグナルから推測します（必要に応じて、コンシューマが動的にスコアを付けることもできます）。これは、「匿名ソースよりも、利用頻度が高く最近更新された信頼できるソースを優先する」という人間側の判断基準と同様の考え方です。本文で特定のソースを引用する際は、ソースの id（[^export-schema]）をキーとする通常の Markdown 脚注を使用します。このため、出典情報を最後にまとめてリスト化するのではなく、個々の主張に直接紐付けることができます。

信頼性: generated、verified

信頼性の確立には、意図的に区別された 2 つのフィールドを使用します。これは、作成者と確認者は別人であってもよいという考えに基づいています。

generated: { by, at }: 現在のコンテンツがどのように生成されたか、および最後に実質的な変更が加えられたのはいつかを示します。
verified: [ { by, at } ]: ソースまたは基盤となるリソースに対する独立した確認のリスト。人間の承認、夜間の財務プロセス、またはその両方を指します。

verified から、コンシューマは信頼性ティアを導き出します。verified キーがない場合は未確認、マシンアクターによる確認のみの場合はマシン確認済み、人間:<id> アクターによる確認の場合は人間によるレビュー済みとなります。ティアはアクセス制御ではなく、参考情報です。これにより、コンシューマは「経営幹部向けダッシュボードには人間によるレビュー済みの指標のみを表示する」といったフィルタリングをフロントマターで指定できるようになります。

acme_retail の例: metrics/revenue.md はリファレンスエージェントによって作成され、財務担当バイスプレジデントによって検証されるため、人間によるレビュー済みティアに分類されます。信頼性ティアフィルタが構成されたエグゼクティブダッシュボードのコンシューマは、その条件を満たすデータのみを抽出して表示します。一方、破棄前提のテスト環境では、下位ティアのコンセプトを取り込むことも可能です。

code_block: <ListValue: [StructValue([('code', 'type: Metric\r\ntitle: Revenue\r\ngenerated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }\r\nverified:\r\n - { by: human:jsmith@acme, at: 2026-07-01T09:00:00Z }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e88ac70>)])]>

鮮度とライフサイクル: stale_after, status

OKF v0.2 では、stale_after フィールドと status フィールドを使用して鮮度とライフサイクルを定義します。status は、コンセプトを draft → stable → deprecated の順に遷移させます（指定がない場合は stable とみなされます）。stale_after は単一の絶対日付を指定します。相対的な TTL ではなくあえて絶対日付を採用したのは、コンセプトがいつ読み取られたかの情報に関係なく、単純な日付の比較だけで鮮度を判定できるようにするためです。こうした決定論的な動作は、LLM 以外のコンシューマにとってまさに必要とされるものです。

acme_retail の例: metrics/revenue.md と metrics/gross-margin.md の両方に stale_after: 2026-12-31 が指定されています。これは、Acme の財務チームが毎年 1 月に基本ポリシーを再承認することを踏まえた日付です。2027 年 1 月 1 日以降、これら 2 つのコンセプトをサービングするには、2027 年度のポリシーに照らした再検証が必要になります。

また、metrics/gross-margin-legacy.md は status: deprecated とされています。Acme は 2026 年 2 月に費用配賦基準を変更しました（以前の計算式では、売上原価に配送費とフルフィルメント費が含まれていませんでした）。以前の定義は、過去のクエリの再現性を確保するために保持されますが、新しい作業で利用されることはありません。

code_block: <ListValue: [StructValue([('code', 'type: Metric\r\ntitle: Gross Margin (legacy, pre-FY2026)\r\nstatus: deprecated'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e88aeb0>)])]>

証明: この数値は正規の手法で計算されたものか？

来歴は、その主張の出所を明らかにするものです。証明は、エージェントが金額を報告する際に重要となる、より踏み込んだ質問（この数字は指示された方法に沿って生成されたものなのか、それともエージェントが独自の SQL を即興で作成したのか）に答えるものです。

OKF v0.2 では、新しいコンセプトタイプである証明付きコンピューティングが導入されています。値の意味だけでなく、その値を計算する正規の計算手法と、その手法が実際に実行されたことを確認する手段が含まれています。acme_retail/computations/revenue-ytd.md の記述例を以下に示します。

code_block: <ListValue: [StructValue([('code', "---\r\ntype: Attested Computation\r\ntitle: Revenue for a fiscal year\r\nruntime: bigquery\r\nparameters:\r\n - { name: year, type: integer, required: true }\r\nexecutor:\r\n resource: skills/run-on-bq.md\r\n receipt: [job_id, executed_sql, result]\r\nattester:\r\n resource: attesters/sql_equality.py\r\ngenerated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }\r\nverified:\r\n - { by: human:jsmith@acme, at: 2026-07-01T09:00:00Z }\r\nstatus: stable\r\nstale_after: 2026-12-31\r\nsources:\r\n - id: revenue-policy\r\n resource: policies/revenue-recognition.md\r\n title: Revenue Recognition Policy (FY2026)\r\n author: human:jsmith@acme\r\n last_modified: 2026-06-15\r\n---\r\n\r\n# Computation\r\n\r\nSELECT\r\n SUM(\r\n CASE\r\n WHEN o.currency = 'USD' THEN o.net_amount\r\n ELSE o.net_amount * fx.rate_to_usd\r\n END\r\n ) AS revenue_usd\r\nFROM `acme.sales.orders` AS o\r\nLEFT JOIN `acme.finance.fx_daily_rates` AS fx\r\n ON fx.currency = o.currency\r\n AND fx.rate_date = DATE(o.order_ts)\r\nWHERE o.order_status = 'delivered'\r\n AND DATE_DIFF(CURRENT_DATE(), DATE(o.order_ts), DAY) >= 30\r\n AND EXTRACT(YEAR FROM o.order_ts) = @year"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e88a070>)])]>

エージェントは、宣言されたparameters を入力することはできますが、計算方法の作成や編集はできません。コンシューマは executor を介して計算を実行すると、receipt（ここでは BigQuery の job_id、実際に実行された SQL、結果）が返されます。次に、LLM を使用しない決定論的な attester がそのレシートを検査し、判定を返します。具体的には、実行されたクエリが指定のパラメータにバインドされた正規の計算方法と等しいか、そして表示された値はレシートの信頼できるソースと一致するか、という判定です。比較は機械的に行われるため、クエリの書き換え、計算ファイルの入れ替え、依存関係の変更があると、チェックは失敗します。

acme_retail の例: attesters/sql_equality.py の attester は、両方の SQL を正規化（コメントの削除、空白の集約、既知のキーワードの大文字化）し、正規化された形式が異なる場合は ok を返さないようにします。テーブル名の差し替え、フィルタの追加、JOIN の削除が行われると、いずれも証明に失敗します。判定結果が false の場合、コンシューマはその値を表示しません。

この例では BigQuery（および SQL）を使用しましたが、この抽象化の仕組みには意図的に柔軟性を持たせてあります。証明済みの計算方法は、セマンティックモデル（Looker、AtScale、その他のシステム）の呼び出し、構造化されたナレッジグラフへのクエリ、さらには任意の API 呼び出しなど、さまざまな処理に適用できます。

重要なのは、OKF は計算方法とその確認方法を記録するだけで、それ自体は何も実行しないということです。また、証明は検証とは異なります。verified は、定義がポリシーと一致していることを確認します（低速、ドキュメントレベル、バンドルに保存）。証明では、1 回の実行で値が正しく生成されたことを確認します（呼び出しごと、ランタイム、バンドルに保存されない）。定義が古くなっていても、証明自体は問題なく行われることがありますが、たとえ検証されたばかりの定義であっても、実行のたびに証明を行う必要があります。そのため、証明と検証の両方があります。

v0.2 の主な更新内容

v0.1 と同様、リファレンス実装は意図的に概念実証として提供されています。OKF を利用するうえで、これらの実装は必須要件ではありません。GitHub リポジトリの変更点は次のとおりです。

reference_agent は、生成時に来歴と信頼ファミリーを出力するようになりました。これにより、新たに作成されたバンドルも生成ソースと引用が組み込まれた状態で提供されます。
静的ビジュアライザーには、コンセプトグラフとともに信頼性ティア、ステータス、鮮度が表示されるため、これらのシグナルを解析できるだけでなく、視覚的に把握できるようになります。
アップデートされたサンプルバンドル（GA4 e コマース、Stack Overflow、Bitcoin、このブログ投稿で使用されている Acme Retail の例）には、v0.2 のフィールドが実装されています。
Knowledge Catalog のデモでは、Google Cloud の Knowledge Catalog（旧称 Dataplex）を介したバンドルのラウンドトリップを紹介しています。ディスク上のクリーンな OKF が、カタログを経由して戻ってくる際も、信頼と来歴のシグナルがそのまま保持される様子を確認できます。

互換性

v0.2 は後方互換性を維持したマイナーアップデートですが、2 つのフィールド名が変更されています。timestamp は generated.at に置き換えられ、本文の # Citations リストは sources に置き換えられていますが、いずれも v0.2 のコンシューマは引き続き v0.1 の形式を利用できます。v0.1 のバンドルも、そのまま利用可能です。

次のステップ

仕様書は短くまとめられていますので、ぜひご一読ください。ソースシステムのトラストシグナルを出力するプロデューサーを記述しましょう。さらに、それらをフィルタリングするコンシューマを記述します。ご自身の財務定義を使って、証明付きコンピューティングをお試しください。問題の報告、PR の送信、拡張機能のご提案をお待ちしております。共通言語の価値は、それを利用するコミュニティの広がりによって高まります。v0.2 では、その言語を通じて互いの情報を検証し合うこともできるようになりました。

OKF v0.2 の仕様、サンプル、リファレンス実装: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

- データクラウド、エンジニアリング、データ分析担当テクニカルリーダー、Sam McVeety

- データクラウド、エンジニアリング、BigQuery 担当テクニカルリーダー、Amir Hormati

BigQuery を使用して Gemini Enterprise app の大規模な使用状況を分析および管理する方法

Fri, 31 Jul 2026 01:00:00 +0000

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

Gemini Enterprise app を組織全体にデプロイすることは、従業員の生産性を飛躍的に向上させる変革の第一歩です。従業員は、エージェント AI ツール、検索グラウンディングアシスタント、NotebookLM などの専用ソリューションで構成される、驚くほど高性能なスイートを利用できるようになります。大規模な導入が進むにつれて、大量のテレメトリーを手作業のオーバーヘッドに悩まされることなく監査および管理して、分析情報を抽出する方法について、管理上の重大な課題に直面することがあります。管理者の成功を支援するため、Google Cloud は、事前計算されたダッシュボードを介して、日々の導入、ユーザーエンゲージメント、アクティブユーザーの指標を追跡するための、すぐに使える包括的な分析を提供しています。この方法では、Gemini Enterprise app の使用状況をプロダクト中心の視点から確認できますが、エージェント型 AI の効果を把握するために、組織中心のより詳細な視点から、組織の内部コンテキストに合わせてカスタマイズされた分析が必要になる場合があります。このような場合に Google BigQuery を使用すると、組織全体で詳細なフォレンジックを実行し、エージェント型 AI の導入を分析および管理できるため、管理者にとっての秘密兵器となります。

Gemini Enterprise app と BigQuery がもたらす変革

ログシンクを使用して Gemini Enterprise app を BigQuery で補強すると、少人数の管理チームでも大規模なデプロイを分析および管理できます。具体的には、IT チーム、データチーム、セキュリティチームが次のことを行えるようになります。

導入と行動の微妙な違いをプロファイル化: 部門ごとに使用パターンをセグメント化して、カスタムエージェントを構築しているチームを確認し、NotebookLM の利用状況を追跡して、エージェントと従業員の比率を計算します。
組織における価値を定量化: 会話ログを人事部門や事業部門のデータセットと組み合わせて、従業員が実際に節約した時間を計算し、価値創造を追跡して、経営幹部向けの Looker ダッシュボードを構築します。
正確なコンプライアンス監査を実施: Google ドライブフォルダと企業ディレクトリ全体でグラウンディングクエリを監査し、データ漏洩を防止して企業の知的財産を保護します。
安全に関するアラートを即座に調査: セキュリティフィルタによりプロンプトにフラグが立てられた場合に、履歴ログをクエリし、Model Armor のブロックをトリガーしたテキストを特定して、コンプライアンスアラートを解決します。

これらのユースケースをサポートするために、テレメトリーは BigQuery の 5 つの異なるログテーブルに分割され、固有のデータフィールドがキャプチャされます。

BigQuery の宛先テーブル	キャプチャされるテレメトリー
生成 AI のユーザーメッセージ `discoveryengine_googleapis_com_gen_ai_user_message`	ユーザーが入力した実際のプロンプト
生成 AI の選択肢 `discoveryengine_googleapis_com_gen_ai_choice`	実際のモデルからの回答、終了した理由、LLM の推論ステップ
ユーザーアクティビティのテレメトリー `discoveryengine_googleapis_com_gemini_enterprise_user_activity`	企業 ID（IAM メール）とグラウンディングファイルのアクセスパス
Cloud Audit のアクティビティ `cloudaudit_googleapis_com_activity`	コントロールプレーンの構成変更と管理者権限を持つユーザーのログ
Cloud Audit のデータアクセス `cloudaudit_googleapis_com_data_access`	大量のデータプレーンのインタラクションと検索クエリ
OOB 指標の集計（バッチエクスポートテーブル）	過去 30 日間の事前集計されたシートの利用、シートの購入、およびエンゲージメント指標。導入と費用の概要ダッシュボードを構築するため、`analytics:exportMetrics` API のカスタムの日次バッチ実行によって非同期的にプルされます。

取り込みパイプラインとアーキテクチャ

スケーリングに対応したオブザーバビリティを実装するために、管理者は自動化されたテレメトリーパイプラインを確立します。Gemini Enterprise のデータを BigQuery に移行する際に、複雑なカスタムソフトウェアを開発する必要はありません。その代わりに、会話ログには継続的な Cloud Logging ログルーターシンクが利用され、集計シート指標の概要には非同期バッチエクスポート API が利用されます。

下の図は、取り込みパイプラインと、テレメトリーが BigQuery にマッピングされる方法を示しています。

これが、Gemini Enterprise を BigQuery に接続して、組織の究極の分析とガバナンスの基盤を構築するためのブループリントです。

ルーティングパイプライン: 継続的なロギングと監査シンク

テレメトリーをキャプチャするには、Cloud Logging 内にログシンクを確立して、ランタイムイベントをインターセプトし、BigQuery にルーティングします。

ストリーミングパイプライン（詳細ログ）: 会話データを 1 行ずつストリーミングします（ユーザープロンプト、モデルの選択、グラウンディングイベント）。Gemini Enterprise 管理コンソールで、プロンプトと回答のロギングが有効になっていることを確認します（使用状況と監査ログの設定を参照）。
包含フィルタ（[PROJECT_ID] を Google Cloud プロジェクト ID に置き換えます）:

code_block: <ListValue: [StructValue([('code', 'logName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgemini_enterprise_user_activity" OR\r\nlogName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgen_ai.user.message" OR\r\nlogName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgen_ai.choice"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e98a8e0>)])]>

ガバナンスパイプライン（監査ログ）: 管理アクション（管理アクティビティ）とデータプレーンのオペレーション（グラウンディングデータコネクタのルックアップなどのデータアクセス）をキャプチャします。
包含フィルタ（[PROJECT_ID] を Google Cloud プロジェクト ID に置き換えます）:

code_block: <ListValue: [StructValue([('code', 'logName:"projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com" AND \r\nprotoPayload.serviceName="discoveryengine.googleapis.com"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f785e98ad00>)])]>

管理アクティビティログ: デフォルトで常に有効になっています。リソースの変更（カスタムエージェントの作成、更新、削除など）を追跡します。
データアクセスログ: デフォルトではオフになっています。チャット中に発生するユーザーレベルでのデータの読み取り / 書き込み操作をログに記録するには、Discovery Engine API の GCP IAM 設定で有効にする必要があります。

BigQuery で高度なインテリジェンスを実現

未加工のテレメトリーを分析情報に変換

BigQuery では、テレメトリーの理解とナビゲーションを容易にする AI 搭載の分析ツールが提供されています。管理者は、Gemini in BigQuery を活用することで、手動で推測することなく、未加工のログストリームを視覚的な分析情報と明確なドキュメントに変換できます。

ノーコードの会話型分析（BigQuery CA）BigQuery の会話型分析（BQ CA）を使用すると、ネストされた JSON スキーマのクエリを簡単に実行できます。BQ CA は BigQuery Studio 内のインテリジェントエージェントとして機能し、スキーマ、ビジネスメタデータ、検証済みのクエリ / UDF にグラウンディングされた SQL を自動的に生成して実行し、指標の一貫性を保ちます。また、生成されたコードとともに「思考プロセス」が提示されるため、管理上の信頼性が高まります。

たとえば、下のスクリーンショットに示すように、「oob_metrics を使用して、NotebookLM、Deep Research、カスタムエージェントの使用状況を比較して」というプロンプトを入力すると、正しい SQL が生成され、クエリが実行されて、結果が数秒で出力されます。

下のスクリーンショットに示すように、BQ CA では、従来のクエリや標準 SQL 生成に加え、ユーザーがコンソール内で高度な AI および ML タスクを直接実行できます。管理者は、これらのネイティブ機能を活用して、ユーザープロンプトの感情の分類や今後の導入傾向の予測などの高度な分析を実行し、ガバナンスプロセスを合理化できます。

スキーマのドキュメントと分析情報の自動生成

適切な分析情報を抽出するには、useriamprincipal、finish_reason、groundedContent などのテレメトリーフィールドを理解することが非常に重要です。BigQuery では、スキーマのドキュメントの自動生成と AI によるコンテキストにより、このプロセスが簡素化されます。

自動プロファイリングとメタデータ: Knowledge Catalog のデータプロファイリングと Gemini を組み合わせることで、元テーブルの一意の値の数、null の割合、データの分布を評価できます。ワンクリックするだけで、データ分析情報により、テーブルとネストされた個々の列の両方に関する記述的なメタデータが生成されます。
統合データ分析情報: Gemini はこの豊富なコンテキストを活用して、データ資産全体から分析情報を抽出します。単一のテーブル（gen_ai_user_message など）内の異常や安全性の問題を検出するためのクエリを自動的に提案します。データセットレベル（プレビュー版）では、テーブル間の結合パスをマッピングするインタラクティブな関係グラフを生成し、ユーザーアクティビティやモデル出力などのデータを組み合わせてタスクの複雑さを計算するクエリを提案します。
エージェントのシームレスなインテグレーションと用語集: テーブルとデータ分析情報が BigQuery Conversational Analytics（BQ CA）エージェントの UI に直接統合されるため、エージェントは拡充されたメタデータと少数ショットの例にすぐにアクセスできます。エージェントがドメイン固有のプロンプトを正確に解釈できるように、BQ CA ではビジネス用語集もサポートされています。エージェント用のカスタム用語を直接定義するか、Knowledge Catalog から既存の用語集をインポートして、標準化された語彙を確立できます。

管理者は、コンプライアンス監査のために、プロファイリング、拡充されたメタデータ、分析情報を活用して、ログに記録されたフィールドをナビゲートし、テレメトリー構造を理解して、データをカタログ化できます。以下のスクリーンショットに示すように、Gemini を活用したスキーマ、説明、関連付けの自動生成により、Gemini Enterprise app でのエージェントのやり取りによって出力される複雑な関係とテレメトリーデータを簡単に理解できます。

データポータルダッシュボードによる可視化

経営幹部クラスのステークホルダー向けには、未加工のログテーブルをインタラクティブで効果の高いビジネスインテリジェンスダッシュボードに変換できます。データポータルを BigQuery に直接接続することで、次のものをモニタリングするダッシュボードを構築できます。

ユーザーの導入とシートの費用対効果: 部門別の使用状況の傾向をセグメント化し、従業員数に対する構築されたカスタムエージェント数の比率をハイライト表示します。
データグラウンディングトラフィック: SharePoint、Google ドライブ、Gmail など、最も利用率の高いエンタープライズコネクタをマッピングします。
コンテンツの安全性と違反: Model Armor のサニタイズブロックと感情フィードバックループを長期にわたって追跡し、安全基準を維持します。
BQ 会話分析エージェントの共有: データポータルを介して構築した BQ CA エージェントを共有し、ビジネスユーザーがデータについてさらに質問できるようにします。

Gemini Enterprise app で組織を強化し、BigQuery で管理者を支援

Gemini Enterprise app をデプロイ: Google AI の最先端機能を、すべての従業員が利用できます。
プロンプトと回答のロギングを有効化: 管理コンソールでプロンプトと回答のロギングを有効にして、ユーザーアクティビティのテレメトリーの記録を開始します。
ログルーターのシンクを構成: テレメトリーを BigQuery にストリーミングするシンクを確立します。
指標を追跡し、分析をエクスポート: コンソールで事前計算されたすぐに使えるダッシュボードにアクセスし、集計統計の履歴をエクスポートします。
テーブルレベルとデータセットレベルの分析情報を抽出: なじみのないログテーブルを探索し、関係結合パスを自動的に検出します。
会話型分析でクエリ: データ推論エージェントを構築し、BigQuery Studio 内で自然言語クエリを活用します。
データポータルによる可視化: データポータルを BigQuery に接続して、経営幹部レベルのダッシュボードを構築し、ビジネスユーザーが BQCA エージェントにアクセスできるようにします。
上記の分析設定における費用対効果が最も高く安全な構成については、Google Cloud カスタマーエンジニアにご相談ください。

この記事の基盤となる作業にご協力いただいた Google Forge チーム、特に Vicky Falconer、Dharini Chandrashekhar、Adhaar Gupta に感謝します。

- Aishwarya Prabhat、Google Cloud、Google Forge、ソリューションアクセラレーションアーキテクト

- Sudipto Guha、Google Cloud、データ分析および AI テクニカルリード

Borderless Lakehouse: AWS、Databricks、Snowflake のデータを AI エージェントで活用

Thu, 30 Jul 2026 02:00:00 +0000

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

現在、データレイクハウスは単なるデータリポジトリではなく、常時稼働する自律型 AI エージェントを通じて積極的にタスクを実行する「アクションシステム」としての役割を強めています。これらのエージェントは、静的なレポートの出力を待つのではなく、リアルタイムの推論ループを絶え間なく回し続けます。サプライチェーンをモニタリングして異常をいち早く察知し、ビジネスワークフローを自律的に実行します。このモデルをスケールさせるには、AI エージェントがデータ資産全体にアクセスできる環境に加え、どのデータをいつ活用すべきかを判断するための適切なコンテキストが不可欠です。しかし、コストの増大、セキュリティの分断、ガバナンスの欠如といった問題を抱える従来のデータアーキテクチャでは、これを容易に実現することはできません。

このたび、Google は Next Tokyo で、これらの課題を解決する Borderless Lakehouse を発表いたします。オープンな Apache Iceberg を基盤とするこの仕組みは、オンプレミス、クロスクラウド、SaaS アプリケーションをシームレスに接続します。これにより、データを移動させることなく、保存場所を問わずにクエリを実行し、データを活用できるようになります。

Iceberg REST で複数のカタログを統合

Borderless Lakehouse は、データの物理的な場所に関係なく、Gemini Enterprise と会話エージェントがデータを分析して行動に移すことを可能にします。Iceberg REST カタログ上に構築されているため、リモートデータを瞬時に見つけ出してクエリを実行できます。これにより、データパイプライン構築に伴う膨大なコストや遅延といった課題を根本から解決します。この接続性を可能にしているのが、AWS Glue、Databricks Unity、Snowflake Horizon のカタログフェデレーション（現在プレビュー版）です。BigQuery、Managed Service for Apache Spark、さらに Iceberg 互換のあらゆるエンジンを介して、セキュアな双方向アクセスを提供します。

このオープンなアプローチはアプリケーションレイヤにも広がっており、SAP、Salesforce、Workday といった主要な SaaS アプリケーションとのゼロコピーデータ統合を可能にします。BigQuery からこれらのプラットフォーム上のライブデータに直接クエリを実行できるため、複雑な ETL パイプラインはもう不要です。同時に、BigQuery の AI エンジンを自社データに直接適用できるため、財務、人事、顧客データを簡単に統合できます。これらの機能は、次の 3 つの大きなメリットをもたらします。

ゼロコピーのクロスクラウド分析: ファイルを複製することなくプラットフォームをまたいで企業データを即座に検出してクエリを実行できるため、さまざまなデータチームが同一の Apache Iceberg データを共有して分析することができます。
双方向の相互運用性: 環境をまたいだデータの読み書きが可能です。BigQuery や Managed Spark から外部テーブルをクエリし、Google AI で強化した派生データセットをパートナーシステムへ戻すことで、後続のアクションに活用できます。
統合されたガバナンスとアクセス制御: 信頼できるコンテキストと Gemini の分析情報を活用して、エージェントのガバナンスを特別な設定なしで実現できます。どのプラットフォームからクエリが実行されても、認証情報の自動払い出しをサポートし、テーブルレベルでセキュアなアクセス制御を実現します。

Borderless Lakehouse の機能は Google Cloud のデータベースポートフォリオにまで広がっており、トランザクションシステムとデータレイクハウスの統合を実現します。Spanner Omni によるマルチクラウド環境での高スケーラブルなデータベース実行や、AlloyDB 向け Lakehouse Federation によるウェアハウスへの直接クエリなど、活用の幅が大きく広がります。費用のかかるデータ移動が不要になるため、ライブの運用データと過去のデータをセキュアかつ効率的にリアルタイムで一元的に分析できるようになります。これで、レイクハウスが真の意味でボーダーレスになります。

Google AI を AWS と Azure のデータに直接活用

これまで、クラウドをまたいで高度な分析を実行したり、ML モデルをトレーニングしたりするには「クラウド間の税金」、つまり高額な外向き料金、ネットワークレイテンシ、脆弱な ETL パイプラインが必要でした。Borderless Lakehouse は、Cross-Cloud Interconnect でこれを解決します。これらの専用のプライベートリンクは、従来のクロスクラウド接続のわずか数分の一のコストで、パブリックインターネットよりも安定した帯域幅と低いレイテンシを提供します。

Borderless Lakehouse では、AWS からデータにアクセスする際、従量課金の外向きデータ転送料はかかりません1。パートナー Cross-Cloud Interconnect の料金体系なら、SLA で保護された接続を予測可能な月額料金で利用できます。このマネージドなプライベート接続は、定額制のサブスクリプションモデルを採用しており、1 G から 100 G までのプロビジョニングを簡素化します。

さらに、Borderless Lakehouse のインテリジェントなクロスクラウドキャッシュ機能は、リモートデータの断片を Google Cloud 内に一時的かつセキュアに保存します。これにより、アドホッククエリや BI クエリのたびに発生していた高コストなデータ転送の繰り返しを排除できます。これらの機能に、BigQuery のベクトル化処理やマルチモーダル分析用の BigQuery AI 関数、Spark の Lightning Engine ランタイム、スケーラブルなメタデータストレージと組み合わせることで、パフォーマンスを犠牲にすることなくペタバイト規模までデータを拡張して以下のような高度な処理も実現できます。

インプレース AI と ML: データを移行することなく、AWS や Azure 上のデータに強力な AI モデルや Gemini を直接適用できます。メタデータとコンテキストをデータがある場所でそのまま取り込むことで、グラウンディングの精度を高め、市場投入までの時間を短縮できます。
データコピーの費用と遅延を解消: 他のクラウドに保存されているライブデータを直接クエリし、データをエージェントがすぐに活用できる環境を整えます。
統合された分析エクスペリエンス: マルチクラウドコンピューティングを Google Cloud のインフラストラクチャに一元化することで、BigQuery、Spark、オープンソースエンジン全体で、ハードウェアに最適化された一貫したパフォーマンスを実現します。

ユニバーサルコンテキストでエージェントの信頼性のギャップを解消

ハルシネーションを防ぐには、AI エージェントに技術的なメタデータだけでなく、ビジネスに関する深いコンテキストを提供する必要があります。ボーダーレス Lakehouse は、常時稼働のエージェントコンテキストエンジンである Knowledge Catalog を利用して、物理ファイルを移動することなく、マルチクラウド環境での企業コンテキストの一元管理を実現します。

これをサポートするために、Borderless Lakehouse のランタイムカタログは、AWS Glue、Databricks Unity Catalog、Snowflake Horizon と自動的に同期されます（すべてプレビュー版）。Knowledge Catalog はこれらのフィードを取り込んでメタデータを集約、抽出、インデックス化し、未加工のスキーマをわかりやすいビジネス用語に変換して、検索可能な列レベルのリネージを作成します。スキーマが変更されると、それを即座にビジネス定義へ反映し、以下のメリットを実現します。

コストとオーバーヘッドの削減: 膨大なコストと時間を要するデータ移行パイプラインを最小限に抑えつつ、マルチクラウド環境全体の統合ビューを構築できます。
信頼できる AI の意思決定: エージェントに明確なセマンティックレイヤとリネージトラッキングを提供し、データの迅速な特定、信頼性の確認、そして正確な解釈を可能にします。
自動化されたガバナンス: セキュリティをメタデータレイヤに直接組み込むことで、AI エージェントによるコンプライアンスガードレールとアクセス権限の厳格な遵守を徹底します。

Gemini Enterprise によるエージェントの構築とスケーリング

オープンソースの Google Cloud Data Agent Kit と Conversational Analytics API を連携させることで、Borderless Lakehouse で動作するカスタムデータエージェントを構築し、Gemini Enterprise に直接公開できます。これにより、ビジネスユーザーは自然言語を使用してデータと対話できるようになります。Data Agent Kit は、エージェント構築機能のフルスタックコレクションです。開発者は使い慣れた IDE（VS Code など）内で、事前にコード化された分析スキルや Model Context Protocol（MCP）ツールをパッケージ化できます。Borderless Lakehouse では、エージェントがデータ資産全体を対象に動作し、以下を支援します。

統合されたデータとエージェントのエコシステム: 組み込みの MCP ツールが BigQuery、Managed Spark、Cloud Storage へのセキュアな直接接続を確立します。これにより、複雑なパイプラインコードを記述したり、大規模なテーブルスキーマを LLM プロンプトにコピー＆ペーストしたりする必要がなくなります。
セルフサービス分析: ビジネスユーザーが静的なダッシュボードに頼ることなく、Gemini Enterprise インターフェース内でマルチクラウドデータセットを平易な言葉で即座にクエリして可視化できます。
グラウンディングされた高精度なエージェント出力: Knowledge Catalog 上でエージェントを実行することで、自然言語から SQL への変換が精査されたビジネススキーマに基づいて行われます。これにより、高度なセキュリティと厳格なガバナンスに裏打ちされた正確な結果が得られます。

Borderless Lakehouse とエージェントの経済性

ボーダーレスなレイクハウスは、データ転送、コンピューティング、トークン消費の各領域で相乗的なコスト削減を実現することで、エンタープライズ AI の経済性を再定義します。Cross-Cloud Interconnect とゼロコピー共有を利用することで、脆弱なデータパイプラインや予測不可能な外向き料金を回避し、予測可能な定額料金でリモートデータセットをクエリできます。Knowledge Catalog は、各プロンプトに必要な正確かつ最小限のビジネスコンテキストをフィルタして提供することで、トークンの肥大化を防ぎ、不要な推論ループを排除します。BigQuery AI は、組み込みのトークン制御により、クエリ前にトークン使用量を推定し、厳格な上限を適用して、より小さな蒸留モデルを自動的に使用する最適化モードを活用することで、エージェントによる予期せぬ課金増加を防ぎます。実際、BigQuery のコスト最適化済みの組み込み AI 関数を利用することでトークン消費量を 230 分の 1 に削減できたケースもあります。

次のステップ

未来は「アクションシステム」の時代です。Borderless Lakehouse で、AI エージェントがデータが保存されている場所を問わず安全かつ迅速に、費用対効果の高い方法で、データのクエリ、推論、アクションを実行できるようにしましょう。構築を開始するには、公式の Google Cloud Lakehouse の概要ガイドをご確認ください。また、ボーダーレスなレイクハウス構築の Codelab もぜひお試しください。

-プロダクトマネジメント担当バイスプレジデント、Sirish Chandrasekaran

-グループプロダクトマネージャー、Will Ochandarena

^{1. 相互接続サービスの時間単位の料金はかかります}

AI エージェントの準備は完了。では、データは？

Thu, 30 Jul 2026 01:00:00 +0000

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

組織による AI イニシアチブの拡張を妨げている最大のボトルネックの一つは何でしょう？それは、現在のモデルの機能ではありません。ビジネスコンテキストとセマンティックな意味へのアクセスです。

エージェントの時代における企業は、単にデータを保存するだけでなく、信頼できるコンテキストでデータを有効活用し、受動的な記録システムから能動的な「アクションシステム」へと移行する必要があります。

しかし、AI エージェントは非線形的な速度で動作します。たとえば、1 つのプロンプトでエージェントが複数のシステムを対象に自律的にブラウジングを行い、クエリを発行して処理を実行する場合、基盤となるインフラストラクチャに負荷をかけることがあります。コンピューティング、ネットワーキング、ストレージの各レイヤがエージェント型 AI 向けに最適化されていない場合、その上に位置するデータプラットフォームは崩壊します。

Google のインフラストラクチャの現状に関するレポートによると、本番環境グレードのエージェント型 AI システムをサポートするにはインフラストラクチャのアップグレードが必要だと考える組織が 83% を占めています。

この問題を解決するために、Google は Google Cloud Next 2026 で Agentic Data Cloud を発表しました。これは、データ、AI モデル、運用データベースを単一の「アクションシステム」に統合するソリューションです。Agentic Data Cloud を機能させるには、チップからモデルまで、すべてが AI ネイティブである必要があります。基盤となるインフラストラクチャは、エージェントの負荷に対応できる必要があります。

Google の Agentic Data Cloud

適切なインフラストラクチャ基盤を整えることで、組織が現在直面している最大のデータ課題を Agentic Data Cloud がいかに解決できるか、以降で見ていきましょう。

コンテキストの欠如を克服する

エージェント型システムを効果的に機能させるにはコンテキストにアクセスする必要がありますが、こうしたコンテキストは、多くの場合、断片化されたデータシステムや従来のアーキテクチャに存在します。このため、エージェントがこうしたコンテキストを把握することが難しくなり、不完全かつ不正確な結果につながる可能性があります。実際、Google のレポートによると、43% の IT リーダーが「従来の API やデータソースとの統合の難しさ」をエージェント型 AI インフラストラクチャの最大のギャップとして挙げています。

しかし、組織が膨大なデータセットを移動して AI に接続しようとする場合、必ず複雑さと費用の増大が伴います。

Agentic Data Cloud は、オープンかつ柔軟なインフラストラクチャ上で実行されるボーダーレスなレイクハウスを活用することで、この問題を解決します。エージェントは、オープンスタンダード（Apache Spark、Apache Iceberg）を介して BigQuery や Spanner などの強力なネイティブエンジンにアクセスすることで、従来の環境で発生するレイテンシと費用を回避しながら、まるでローカルであるかのように複数の環境間でデータを読み取り、推論し、有効活用できます。

不要な手作業を回避する

分断されたシステムの寄せ集めにエージェントをスケールすると、大きなボトルネックが生じる可能性があります。Google の調査では、AI をスケールする際の予期せぬ費用の筆頭として、81% のリーダーが運用の複雑さとエンジニアリングのオーバーヘッドを挙げています。その例として、エンジニアが異なるシステムにまたがる AI エージェントを手動でつなぎ合わせる作業に費やす時間が挙げられています。

「考える」エージェントから「実行する」エージェントに移行するには、分析ソースと運用ソースの両方でリアルタイムデータを接続できなければなりません。これには垂直統合が必要です。モデル、データシステム、基盤となるアクセラレータが共同設計された AI ネイティブインフラストラクチャ上に Agentic Data Cloud を構築すると、ネットワークホップが減り、ツールがより適切に統合されます。この統合システムにより、エージェントは典型的なエンジニアリングのオーバーヘッドなしで分析情報を取得し、安全なトランザクションをトリガーできます。

データに信頼と知識をもたらす

エージェントに必要なのは、データを検出してクエリを実行する機能だけではありません。安全かつ正確なアクションを実行するには、豊富なコンテキストとビジネスロジックも必要です。しかし、36% のリーダーが、AI モデルのグラウンディングに使用される専門的な高スループットのベクトルデータベースの不足を、インフラストラクチャの主要なギャップとして挙げています。このギャップにより、エージェントにコンテキストを提供する能力が損なわれます。

エージェントがその可能性を最大限に発揮するには、レガシー ERP やサードパーティ CRM を含むデータシステムに対してリアルタイムで読み書きを実行できるように構築された基盤が必要です。また、複雑なタスクを実行する際に、たとえば 3 週間前のユーザーの好みを「思い出す」ことができる長期記憶も必要です。こうしたリアルタイムの自動化がない場合、エージェントはクエリごとにデータを再処理する必要があります。

AI にコンテキストを提供するために、組織は Knowledge Catalog を使用してデータレイク内のデータを集約して拡充し、エージェントによる検索を可能にしています。非構造化データから意味を抽出してセマンティクスを自動生成することで、カタログはアクティブな推論レイヤとして機能するようになります。そして、そのカタログは、エージェントが適切なコンテキストを取得できるように、高スループットのインフラストラクチャによって支えられている必要があります。

将来を見据える

今こそ、AI によって真の競争優位性を獲得するために、接続されたアクティブなデータエコシステムを構築する絶好のタイミングです。試験運用から本番環境に移行するには、エージェントがすべてのデータにシームレスにアクセスできるようにする必要があります。また、エージェントの時代の要求に対応できるインフラストラクチャで、これを支える必要があります。2026 年以降に勝利を収められるのは、必ずしも高度にスマートなエージェントを備える企業とは限りません。これらのエージェントに適切な知識を、安全かつ費用対効果の高い方法で大規模に提供できる企業が勝利するでしょう。貴社のデータは、エージェントの時代に対応する準備ができていますか？

エージェント型 AI 時代におけるインフラストラクチャの現状に関するレポートで、アーキテクチャに対して AI に最適化されたアプローチを採用しているリーダーたちの手法をご確認ください。

- プロダクト管理、データ分析担当バイスプレジデント、Sirish Chandrasekaran

Frontier and Center: 誰が評価ツールを評価するのか？

Thu, 30 Jul 2026 01:00:00 +0000

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

編集者注: AI に関する最も興味深い問いとして、新たなクラスの AI エージェントにコンテキストを提供する方法に関して情報理論家が提起しているものがあります。数週間前、Google は Open Knowledge Format に関するブログ記事で、この問題に踏み込みました。Open Knowledge Format は、最新の AI システムを動作させるために必要なメタデータ、コンテキスト、キュレートされた知識を表すために、LLM-wiki パターンを移植可能で相互運用可能な形式に形式化する仕様です。このブログ記事は大きな関心を集めたため、同様のコンテンツを新しい「Frontier and Center」シリーズとして提供する運びとなりました。今回は、Google データクラウドのフロンティア AI チームに属する 2 人のメンバーから、エージェントがコンテキストに基づいて効果的に質問に回答できるかどうかをどのように体系的に評価するかという、繰り返し直面する課題について話を聞きます。詳しくは、記事全文をご覧ください。また、このチームによる今後のブログ記事にもご期待ください。

試験に関して合格点だけを知っても、それほど意味はありません。生徒が合格したかどうかはわかりますが、不合格だった場合は合格点からどれだけ離れていたのか、合格だった場合はどれだけ余裕があったのか、次回のために何を教えるべきなのかはわかりません。しかし、AI エージェントはまさにこのように評価されています。固定のベンチマークを実行し、スコアを計算して、進歩したと宣言しているのが現状です。このような評価では、エージェントに合格 / 不合格の試験を行っているのと同じです。必要なのは、エージェントの能力がどの部分でどの程度不足しているのかを正確に表す地形マップです。

データエージェントにとって、このマップは検索と取得におけるデータ探索に極めて重要です。このプロセスは、エージェントが曖昧な人間の質問と、数千のテーブルとファイルからなるデータウェアハウスまたはデータレイクを受け取った後、推論を行うための前段階として適切なデータセットを見つけなければならないという、地味な最初のステップです。探索は「干し草の山から針を探す」ようなものです。実際のユーザーからの質問は完璧に表現されたものではないため、どのデータセットを取得すべきかを推測するのはエージェントにとって非常に困難です。そのため、真に問うべきことは「エージェントは合格できるか」という点ではないのです。真に問うべきことは、「質問がどれだけ曖昧になるとエージェントが機能しなくなるか」という点です。試験ではこの問いに簡単に答えることはできませんが、マップでなら可能です。

このブログ投稿では、情報理論に基づいたアプローチをご紹介します。このアプローチは、ベンチマークに詳細とニュアンスを追加して忠実度を高めるために活用されており、評価の一環としてエージェントのパフォーマンスをより深く理解できるようになります。忠実度を高めたことで、発生した評価ケース自体の品質に関するより深い問題も明らかになりました。

難易度を測定

取得に関しては、評価ケースは多くの場合、難易度に応じて階層化されます。こうした階層化は、自然に生じることもあります。たとえば、広範囲で発生し、失敗が繰り返されるシナリオが「困難」と判断される場合などです。また、たとえばクエリで提供されたコンテキストに基づいて、エージェントが正しく回答する難易度が低いか高いかについて、人間やマシンが適用したラベルに基づいて、質問を分類することもできます。このような感情ベースのラベル付けは、テストケースにラベルを付ける唯一の方法ではありませんが、再現が難しいなどの欠点があるにもかかわらず、頻繁に使用されています。

すべての評価ケースを手作業で評価する方法も業界では一般的ですが、規模が大きくなれば現実的な方法ではなくなります。必要なのは、評価ケースの難易度を調整できる厳格なアプローチです。Google は、Discovery Bench と呼ばれるメタベンチマークの改良を重ねています。このベンチマークは、すべてのケースの「低難易度」バリエーションと「高難易度」バリエーションを生成することで評価ケースを調整するフレームワークです。これにより、エージェントがこれらのケースで成功からどれだけ離れているかを監査できます。

入力クエリの難易度を調整する手段は、情報理論と ML の分野で実績があり、信頼できるコンセプトであるサプライザル（意外性）、あるいは、ある一連の入力に対する出力の可能性によって実現されます。今回のケースでは、クエリのサプライザルとは、与えられたクエリから正しいデータセットを特定するうえで、依然として残っている不確実性を表します。

このアプローチの背後にある考え方はシンプルです。評価クエリの用語やフレーズは、コーパス内の他のすべてのものからターゲットを明確に特定できる場合、高い情報提供力を持つとみなされます。そのため、さまざまな情報提供力を持つ用語を追加または削除することにより、評価ケースの難易度を調整できます。

一般公開されているベンチマークである KramaBench の実際の例を見てみましょう。KramaBench のデータセットの一つには、地球を周回する衛星に関する情報が含まれます。スイートからのサンプルクエリには、次のテキストが含まれています。「…TLE 履歴を使用して、2024 年に衛星 48445 の高度が大きく変化した合計回数。」

トークン "TLE" が指定されているため、データセットの TLE_____48445 テーブルがほぼ一意に特定されます。これを削除すると、クエリは「衛星 48445 の高度の回数」のように曖昧なフレーズとなり、密度テーブル、精密軌道ファイル、減衰ログなどにも一致します。サプライザルはこれを定量化します。出現頻度の低い、的を絞った用語は、一般的な用語よりも情報量（ビット数）が多くなります。

クエリの残存サプライザルとは、その回答を得るために依然として残っている不確実性の量のことです。サプライザルがゼロに近づくにつれて、クエリはデータセットを 1 つ特定するのに十分な情報量があるとみなされるようになります。

Discovery Bench のアイデアの中核となるのは、この改良ループです。これは、サプライザルベースの反復クエリ改良（iSQR）と呼ばれ、情報提供力の高いケースと低いケースを生成して、エージェントがクエリに正しく回答できるようになる地点をテストします。

図 2: iSQR の改良ループ。

重要なのは、評価ケースに組み込まれた課題を調整によって制御できるようにすることです。質問ごとに 1 つの固定された表現を使用するのではなく、同じ質問を調整された 3 つの曖昧性レベル（高、中、低）で生成し、それぞれを（主観的な意見ではなく）ビット数に基づいてグラウンディングします。単語が追加または削除された理由を、用語ごとに説明することもできます。難易度は、感情や分類に基づくプロパティではなく、構築されるプロパティになります。

見えていなかった崖

次に、Discovery Bench の難易度ダイヤルで明らかになったことと、単一フレーズのベンチマークでは構造的に不可能であったことを説明します。

Google には、再現率を重視して構築された F1 エージェント（Gemini 3.1 Pro 上）があります。これを KramaBench に対して、曖昧性レベルのスイープを実行すると、曲線が得られます。曖昧性が高の場合は 0.34、標準の場合は 0.76、中の場合 0.81、低の場合 0.78 です。

図 3: F1 をすべての曖昧性レベルでスイープ - 点対曲線。

すぐに 2 つの知見が得られました。これらはどちらも、従来の評価では得られなかったものです。

まず、崖があるということです。このクエリは、標準のフレーズでは F1 = 1.00 の完璧なスコアが得られましたが、曖昧性が高いフレーズでは 0.00 が得られました。これは、上述の衛星 48445 のケースです。識別トークン「TLE」を削除すると、エージェントはテーブルを検出できなくなります。同じクエリ、同じエージェント、同じグラウンドトゥルースでも、少しでも曖昧になると崖から落ちてしまいます。静的なベンチマークは、標準的な表現をテストし、「解決済み」のスタンプを押して平地であると報告しますが、実際には断崖があります。合格 / 不合格の評価では、崖が見逃されるだけでなく、平地であると報告されるため、特に誤解を招きやすくなります。

2 つ目は、スイートスポットです。Discovery Agent では、曖昧性が中のプロンプトの方が標準プロンプトよりも結果が良い場合や、曖昧性が低のプロンプトの方が標準プロンプトよりもパフォーマンスが低い場合がありました。評価対象のシステムにとって、特異性は高いほど良いというわけではなく、最適な調整量があるということです。これは、評価された、実用的なシグナルです。これが、スカラー評価には欠けていた「どれだけ離れているか、どれだけ難易度が高いか」という特性です。これにより、エージェントのどの部分を改良すべきかがわかります。このケースでは、時間でシャーディングされたテーブル（回答が 2 つのテーブルである場合にエージェントがほぼ同一のシャード 21 個を過剰に取得すると、精度が約 8% に低下）や、コンテキストの急増（クエリが長い検索チェーンをトリガーすると、F1 が 0.75 から 0.32 に低下）などの具体的な失敗モードが直接示されます。このマップには、エージェントが失敗したことだけでなく、その場所と理由も示されます。（用語の調整により）曖昧さを減らし、コンテキストを増やすことで取得が改善するという仮説は一般的には当てはまりますが、今回使用した特定の Discovery Agent では、特有の「スイートスポット」があることから、実装におけるトレードオフが明確に示されました。

分野全体での傾向

この分野はメタベンチマークを使用する方向に収束しつつあり、エージェントにどのように負荷をかけ、評価するかをより細かく制御できるようになってきています。項目反応理論（標準化されたテストの背後にある潜在能力モデル）を使用して、難易度をラベルではなく測定量として扱う研究が増えています。tinyBenchmarks と metabench は、少数の情報量の多い項目でモデルのフルスコアを再現できることを示しており、PSN-IRT はベンチマークの品質自体にも同じ考えを適用しています。また、グラウンドトゥルースを直接監査する研究もあります。MMLU-Redux では、大規模マルチタスク言語理解（MMLU）の質問の 6.49% に誤ったラベルが付けられていることがわかりました。Platinum Benchmarks では、ラベルエラーと曖昧さの両方を最小限に抑えるために 10 個のデータセットを再クリーニングしました。これらは、Google がスイープするのと同じ 2 つの軸です。また、曖昧性はノイズではなく本質的なものとして扱われることが増えています。AmbigQA では、実際の質問の大部分に複数の解釈があることが示され、後の研究では、見かけ上のハルシネーションは、モデルの失敗ではなく、クエリの曖昧さに起因することが多いと報告されています。他では見られないのは、情報理論的な曖昧性をエンタープライズのライブデータに対してメタベンチマークとして適用するという組み合わせです。

信頼していたベンチマークが機能しなくなった

最初の評価は、この分野で確立されたベンチマークである kramabench-astronomy を基に構築しました。他のチームも、独自の評価にこのベンチマークを利用していました。チームはこのデータセットからベンチマークを派生させていましたが、時間の経過とともに微妙な問題が発生するようになった可能性があると仮定しました。Gemini の助けを借りて、チームが使用したベンチマークを実際に読んでみると、重要な問題があることがわかりました。グラウンドトゥルーステーブルがクエリに回答しない、質問の 124 個のシャードテーブルが一部のチームの検索 API で返せる数を超えている、正確な日付が必要なのに月が指定されているなどです。グラウンドトゥルースが気づかないうちに壊れていたということは、今回だけでなく、それに基づいて構築されていた以前の分析についてもすべて、結果が間違っていたということです。

これが一般的な問題の核心です。評価自体が欠陥のあるアーティファクトであり、それを評価する人はほとんどいません。エージェントを計測し、計測ツールを信頼しますが、その計測ツールが正しいことはどこで検証すればよいのでしょうか。

2 つのマップが一致しない場合

ここに再帰的な問題があります。難しさが生成されるものであるなら、生成器自体を評価する必要があります。生成器を盲目的に信頼すべきではありません。

そこで、同じ曖昧性スイープを 2 つの方法で構築しました。1 つは純粋な LLM の推測から用語を調整する方法、もう 1 つは TF-IDF サプライザルに基づいて用語をグラウンディングする方法です。この 2 つの結果は大きく異なりました。曖昧性が高い場合、LLM で構築されたスイープでは F1 のエージェントのスコアは約 0.34 でしたが、グラウンディングされたスイープでは約 0.85 でした。これらのマップのどちらかが大きく歪んでいます。予想どおり、グラウンディングされた方法の方がより堅牢です。サプライザルにより、グラウンディングされていない LLM にはない基盤が与えられるからです。

これは「評価ツールの評価」を具体化したものです。情報理論の視点からは、エージェントを連続軸に沿って評価するだけでなく、ベンチマーク自体の構築も評価し、両者を判定します。

評価ツールを評価する

Google は何年もかけて、測定したことのない測定ツールに対してエージェントを最適化してきました。皮肉なことに、モデルが優れているほどこの問題は悪化します。エージェントが大まかなベンチマークをクリアすると、スコアは上限近くで飽和し、試験によってエージェントの改良可能な部分を示すことができなくなります。

そのため、必要な行動は心地よいものではなく、遅きに失しています。評価ツールを評価することが必須です。グラウンドトゥルースを確認することが重要です。難易度をラベルではなく測定量として扱い、スイープしてプロットし、システムが機能しなくなるビット幅を見つけます。「合格したか」だけでなく、「合格からどれだけ離れていたか、どれだけの余裕を持って合格できたか、少し曖昧な質問をしたらどうなるか」を尋ねます。判定だけではなく、シグナルを生成する評価を構築します。

ここで、じっくりと考えるべき対立があります。難易度をエントロピーと捉えると、その信頼性はエントロピーを推定するモデルの信頼性に依存します。測定可能な代理の指標を過度に重視すると、エージェントではなく評価ツールを最適化することになるというリスクがあります。でも、これは合格 / 不合格の試験に後退する理由にはなりません。評価対象となるエージェントと同じ精密な調査を、評価ツールにも適用する必要があるということです。誰が評価ツールを評価するのか尋ねるのをやめれば、マップは再び役に立たないものになります。

^{1. Maia Polo, F. 他著『tinyBenchmarks: Evaluating LLMs with Fewer Examples』 ICML 2024 年、arxiv.org/abs/2402.14992}

^{2. Kipnis, A. 他著『metabench: A Sparse Benchmark of Reasoning and Knowledge in Large Language Models』 ICLR 2025 年、arxiv.org/abs/2407.12844}

^{3. 『Lost in Benchmarks? Rethinking Large Language Model Benchmarking with Item Response Theory』（PSN-IRT）、AAAI 2026 年、arxiv.org/abs/2505.15055}

^{4. Gema, A. P. 他著『Are We Done with MMLU?』（MMLU-Redux）、2024 年、arxiv.org/abs/2406.04127}

^{5. Vendrow, J. 他著『Do Large Language Model Benchmarks Test Reliability?』(Platinum Benchmarks)、2025 年、arxiv.org/abs/2502.03461}

^{6. White, C., Dooley, S. 他著『LiveBench: A Challenging, Contamination-Limited LLM Benchmark.』 2024 年、arxiv.org/abs/2406.19314}

^{7. Min, S. 他著『AmbigQA: Answering Ambiguous Open-domain Questions.』 EMNLP 2020 年、aclanthology.org/2020.emnlp-main.466}

^{8. Lai, E., Vitagliano, G. 他著『KramaBench: A Benchmark for AI Systems on Data-to-Insight Pipelines over Data Lakes』 2025 年、arxiv.org/abs/2506.06541}

- データクラウドフロンティア AI、ソフトウェアエンジニア、Manav Garg

- データクラウドフロンティア AI、テクニカルリード、Sunil Pedapudi

データ分析

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

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

実際の活用例

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

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

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

準備ができたら

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

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

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

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

移行コネクタ

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

BigQuery Data Transfer Service を選ぶ理由

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

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

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

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

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

パイプライン フロー

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

パイプラインの実装

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

重要ポイント

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

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

使ってみる

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

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

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

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

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

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

仕組み

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

統合されたセマンティクス: Looker とのネイティブなインテグレーション

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

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

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

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

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

SOAP の経済性

次のステップ

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

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

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

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

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

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

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

Looker ベースのユーザー認証

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

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

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

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

メリットの比較

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

まとめ

Spanner Graph で小売商品の検索性能を強化し、データベースのメンテナンス工数半減を達成した Target の取り組み

断片化されたアーキテクチャからの脱却

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

ダウンタイムなしでスムーズに段階的に移行

ビジネスへの影響

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

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

Spanner Graph を活用したモダンなインフラストラクチャ

Spanner Graph への移行による主なメリット

SDMX 3.0 の相互運用性によるシステムの橋渡し

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

早速始めましょう

Cortex Framework v7 の一般提供を開始: SAP の運用を中断せずにエージェント型ワークフローを構築する

Cortex Framework v7 の新機能

1. エージェント対応のデータ プロダクトを提供する

2. モジュール式デプロイで迅速に構築する

3. 柔軟な処理で費用対効果の高いスケーリングを実現する

SAP Business Data Cloud との相互運用性

業界のリーダーとの共同イノベーション

使ってみる

SAP Business Data Cloud Connect for BigQuery の一般提供開始のお知らせ

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

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

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

パイプラインフロー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. エージェント対応のデータプロダクトを提供する

ハイブリッドパイプラインが重要である理由

列レベルのセキュリティを強化: BigQuery で IAM データガバナンスタグを使用する

IAM データガバナンスタグとは

列レベルのセキュリティにデータガバナンスタグを使用する理由

ルーティングパイプライン: 継続的なロギングと監査シンク

ユニバーサルコンテキストでエージェントの信頼性のギャップを解消