BigQuery

非構造化データワークフローのモダナイズ: Alteryx Live Query と Google Cloud BigQuery の連携

Fri, 23 Oct 2026 01:00:00 +0000

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

Alteryx One Live Query と Google Cloud BigQuery は、分断されたツールへの依存を減らし、データの移動を最小限に抑え、ウェアハウスネイティブの実行を可能にすることで、企業が複雑な非構造化データを大規模に処理する方法を一新します。

Live Query は、ビジネスユーザーがコードを 1 行も記述することなく高度なデータパイプラインを構築できる、直感的なブラウザベースの環境を提供します。BigQuery のスケールとパフォーマンスを組み合わせることで、安全な SQL プッシュダウンが可能になります。つまり、データ変換ロジックは、ネットワーク経由でデータを移動させることなく、ウェアハウス内で直接実行されます。この相乗効果は、ドキュメントを多用するワークフローで特に威力を発揮します。Live Query は、BigQuery 環境の厳格なデータガバナンスとセキュリティを維持しながら、Gemini などの Google の高度な AI および ML モデルをオーケストレートして、PDF や画像から情報を抽出できます。

請求書 PDF の処理から、Live Query を使用した BigQuery での例外レポート管理まで

財務チームやオペレーションチームは、ベンダーからの請求書の山に埋もれてしまうことがよくあります。これらのドキュメントは PDF 形式で届きますが、データに一貫性がなく、請求書番号の形式もさまざまであるため、手作業によるエラーが発生するリスクが高くなっています。従来、データチームは手動でデータを抽出するか、分断された複数のツールを使用してデータをウェアハウスに移す必要がありました。このプロセスには、時間がかかるだけでなく、データの重複や金額の不一致が発生しやすいという問題がありました。

Live Query for BigQuery のインテグレーションにより、請求書のライフサイクル全体を自動化できるようになりました。データチームは、BigQuery エコシステム内で直接、PDF の処理、主要なフィールドの抽出、結果の標準化を行うことにより、ドキュメント内の異常やデータの問題といった例外をより迅速に特定できると同時に、BigQuery のきめ細かなアクセスポリシーに基づいて構成、ガバナンス管理された企業データを、ウェアハウスの外部に転送する必要がなくなります。

ソリューションの概要: 抽出、分類、検証、ルーティング、計上

Live Query ソリューションの仕組みについて、さらに詳しく見ていきましょう。請求書 PDF は、非構造化ドキュメントとして Google Cloud Storage に届きます。Live Query ワークフローでは、ドキュメント抽出ツールが、ユーザーが選択したモデル（Gemini や Document AI など）を使用して構造化フィールドを抽出します。その後、結果は信頼性の高い照合が行えるよう標準化され、BigQuery にすでに格納、ガバナンス管理されている請求書の履歴レコードと照合されます。

この自動化されたワークフローは、手作業による介入を最小限に抑えながら、ドキュメントから意思決定へとスムーズに至れるよう設計されています。エンタープライズ規模では、このパターンは少数の PDF を処理するだけにとどまりません。照合ロジックを BigQuery と整合させながら、数百万件もの非構造化ドキュメントに対する分析や AI 活用を可能にします。

AI を活用した抽出と BigQuery ネイティブの実行を組み合わせることで、このソリューションは以下を実現します。

ストレートスルー処理の向上: 手作業を減らし、より多くの請求書を自動的に処理できるようにします。
照合の迅速化と手動例外の削減: 抽出した請求書をプロセスの早い段階で BigQuery データと照合することにより、チームは重複や不一致を早期に特定し、手動での確認が必要な請求書の数を減らすことができます。
監査可能性の強化: ソースから最終的な業務出力まで、データの明確な処理履歴を保持します。
データ移動の削減: データを BigQuery 内にとどめ、その組み込み機能を活用することで、セキュリティ、ガバナンス、管理機能を強化します。

アーキテクチャ: Google Cloud ネイティブパターン

大まかに言うと、請求書 PDF は Cloud Storage にステージングされ、ブラウザ上の Live Query ワークフローで処理された後、BigQuery にすでに格納、ガバナンス管理されている請求書履歴と照合され、ファイナンスチームの最終的な業務出力として書き戻されます。このパターンのアーキテクチャ上の主な利点は、ワークフローの作成をブラウザ上で行える一方、変換や照合のロジックは、プラットフォームサービスを通じて、ガバナンス管理されたデータ環境に対して実行されることです。

Live Query アーキテクチャは、ウェアハウス規模の処理とガバナンス管理された実行を目的として設計されています。安全な SQL プッシュダウンを使用して、変換と照合のロジックを BigQuery 内で直接実行し、Gemini と連携することで、ドキュメントの抽出、分類、要約といった高度な AI 機能を実現します。

Live Query（ブラウザ）: ユーザーはブラウザ上でワークフローを視覚的に作成し、ドキュメントの抽出、分類、クレンジング、検証、ルーティングのロジックを構成します。
Alteryx One Platform Services: 変換サービスは、ブラウザワークフローとお客様のデータ環境の間におけるリクエスト処理、実行計画、結果取得を調整します。また、これらのサービスにより、ワークフローの実行全体にわたるトレーサビリティとオブザーバビリティが向上し、運用モニタリングと監査可能性の両方が強化されます。
お客様の Google Cloud: 請求書 PDF は Google Cloud Storage（GCS）にステージングされ、請求書の履歴データは BigQuery でガバナンス管理された状態で保持されます。AI を活用した抽出はその環境に対して実行され、ワークフローの出力は BigQuery に書き戻されます。

このパターンでは、ブラウザがオーサリングレイヤ、Alteryx One Platform Services が調整レイヤ、Google Cloud がガバナンス管理されたデータおよび実行レイヤとなります。この構成により、Live Query でワークフローロジックを視覚的に作成しながら、BigQuery でガバナンス管理されたデータおよびウェアハウス規模の処理と連携して実行できます。

Live Query ワークフロー解説: PDF から分析情報まで

請求書を例に、Live Query ワークフローが非構造化 PDF をどのように処理するかを詳しく見ていきましょう。

請求書 PDF を取り込むワークフローは、未加工の PDF ファイルが格納されている Google Cloud Storage のディレクトリ入力を指定することから始まります。実際には、このステップではフォルダを特定するだけでなく、PDF の場所を列挙し、絶対ファイルパス、サイズ、作成 / 更新タイムスタンプといったファイルレベルのメタデータを返します。これにより、ワークフローは適切なドキュメントセットをダウンストリームの抽出ステップに確実に渡すことができます。

主要なフィールドを抽出するAlteryx の Document Extract ツールを使用して、ワークフローは Google Cloud Storage に格納されている PDF 請求書を処理し、構造化または半構造化された結果を BigQuery 内で直接抽出します。抽出ステップでは、ワークフローの構成に応じて、ユーザーが選択したモデル（Document AI または Gemini AI）が使用されます。このツールは、内部で入力ドキュメントの URI から一時的な外部オブジェクトテーブルを構築し、適切な関数（Document AI モデルの場合は ML.PROCESS_DOCUMENT、Gemini AI モデルの場合は AI.GENERATE）を実行します。このワークフローでは Gemini の処理ルートが使われており、AI.GENERATE がリクエストされた請求書フィールドをダウンストリームの Live Query ワークフローに返します。

インタラクティブな設計時、Live Query はプレビューのためにドキュメント URI のごく一部のみに処理を制限しますが、ランタイム実行ではすべての請求書 PDF を処理します。

code_block: <ListValue: [StructValue([('code', "-- illustrative pattern only\r\nSELECT *\r\nFROM AI.GENERATE(\r\n MODEL project.dataset.gemini_model,\r\n (\r\n SELECT\r\n uri,\r\n 'Extract invoice_number, invoice_amount, vendor_name, net_amount, tax_amount, and line_items.' AS prompt\r\n FROM project.dataset.temp_invoice_object_table\r\n )\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a495590>)])]>

抽出されたデータの内容を分類する抽出後、ワークフローは Alteryx の Classify ツールを使用して、抽出された請求書テキストにゼロショット分類を適用します。このユースケースでは、BigQuery の AI.CLASSIFY を使用して、明細項目の内容を、工業用品や事務用品などの事前定義されたビジネスカテゴリに分類します。これにより、予測ラベルが新しい列としてダウンストリームワークフローに返されます。このビジネスコンテキストにより、抽出されたデータは、ダウンストリームでの照合、例外処理、レポート作成においてより有用なものとなります。

code_block: <ListValue: [StructValue([('code', "-- illustrative pattern only\r\nSELECT *,\r\n AI.CLASSIFY(line_item_text, categories => ['industrial', 'office']) AS line_item_classify\r\nFROM upstream"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a436d10>)])]>

データを正規化する抽出された請求書番号はクレンジングされ、標準化されます。これにより、空白文字や書式の不一致といった軽微な表記の違いによって照合中に重複の可能性が見落とされることがなくなります。

履歴と比較するワークフローは、正規化された現在の請求書レコードを、すでに BigQuery に格納されている請求書の履歴データと結合します。この照合ステップでは、履歴にすでに存在する請求書番号と一致するレコードを特定し、重複の可能性があるものとしてフラグを立てます。

例外にフラグを立てる次に、数式ステップで、残りのレコードにビジネスルールロジックを適用します。これらのルールはワークフローによって異なり、金額の不一致、必須フィールドの欠落、無効な合計額、その他の財務特有の例外に対するチェックなどが含まれます。この例では、1 つのルールで invoice_amount が net_amount + tax_amount と一致するかどうかを確認し、不一致があれば確認対象としてフラグを立てます。

業務出力を生成するこのワークフローでは 2 つの業務出力が生成されます。1 つは、履歴レコードと一致し、重複の可能性があるとしてフラグが立てられた請求書に関するものです。もう 1 つは、履歴と一致しなかった今回の請求書に関するもので、検証と必要に応じて例外のラベル付けが行われ、未払い請求書の処理に回されます。

その結果得られるのは、単に抽出されたデータにとどまらず、ファイナンスチームがすぐに確認して対応できる、ガバナンス管理された業務出力です。

まとめ: ドキュメントから意思決定まで、ガバナンス管理されたワークフロー

私たちの共通のお客様は、ビジネスプロセスの改善に役立つこれらの新機能に大きな期待を寄せています。

「Alteryx One: Google エディションで特に印象的だったのは、Google Cloud のエクスペリエンスに自然にフィットしている点です。ビジネスユーザーが直感的でガバナンス管理されたエクスペリエンスを通じて BigQuery データを操作できるようにすることで、分析をより身近なものにする機会が得られることを嬉しく思います。」 - Papa Johns、エンタープライズデータおよびコーポレートソリューション担当バイスプレジデント、Michael Wyant 氏

これは、単なる抽出ツールのユースケースにとどまりません。非構造化ドキュメントを実用的な業務出力に変換する、強力な Google Cloud ネイティブパターンを表しています。このワークフローは、分断された準備ツールにウェアハウスデータを移動するのではなく、ストレージ、抽出、照合、出力生成を、BigQuery にすでに格納されているガバナンス管理された企業データと整合させます。Alteryx One Live Query の直感的な設計と BigQuery のスケールおよび AI 機能を組み合わせることで、ファイナンスチームは手作業による負担を減らし、例外処理を迅速化して、より価値の高い戦略的な取り組みに注力できるようになります。

- Alteryx、シニアプロダクトマネージャー、Kira Droganova 氏

- Google、データ分析スペシャリスト、Rama Vundela

BigQuery で多変量時系列予測を行う TimesFM 3.0 のご紹介

Wed, 21 Oct 2026 17:00:00 +0000

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

概要

BigQuery に AI.FORECAST を使用したゼロショット時系列予測が導入されて以来（当初は TimesFM 2.0 を搭載し、後に TimesFM 2.5 にアップグレード）、カスタムモデルのトレーニングや管理を行うことなく、SQL で直接予測を生成できるようになりました。しかし、TimesFM 2.5 までは、これらの基盤モデルは単変量予測に限定されており、単一の時系列の履歴のみから将来の値を予測していました。実際には、現実世界の予測問題のほとんどは多変量であり、関連するターゲットと、天気、プロモーション、休日などの外部要因が組み合わさって将来の結果を形成します。

本日、BigQuery での TimesFM 3.0 プレビュー版のリリースをお知らせできることを嬉しく思います。Google Research が開発した TimesFM 3.0 は、3 億 3,000 万のパラメータを持つ最先端の基盤モデルで、BigQuery SQL 内で直接、組み込みの多変量時系列予測を実現できるように設計されています。TimesFM 3.0 は、GIFT-Eval、FEV-Bench、TIME という 3 つの主要な公開時系列リーダーボードすべてで 1 位を獲得しており、既存の基盤モデルと比較して、共変量予測タスクと多変量予測タスクの両方で最高のゼロショット精度を達成しています。

TimesFM 3.0 は、新しい多変量機能に加えて、AI.FORECAST による単変量予測と AI.DETECT_ANOMALIES による異常検出のドロップインアップグレードとしても機能します。既存のワークフローでも、model => 'TimesFM 3.0' を指定するだけで、向上したベンチマーク精度の恩恵をすぐに享受できます。

新機能: 多変量基盤モデリング

TimesFM 3.0 により、BigQuery では AI.FORECAST を通じて、使い慣れた SQL ワークフローにエンタープライズグレードの多変量モデリングを取り入れることができます。

機能	TimesFM 2.0 / 2.5	TimesFM 3.0
予測の範囲	単変量のみ	単変量と多変量
ターゲット列	単一のターゲット	単一または複数のターゲット
過去の値のみを含む共変量列	非対応	サポート対象
過去と未来の値を含む共変量列	非対応	サポート対象

BigQuery SQL を使用した多変量予測

これらの機能がどのように連携するかを確認するために、NYC Citi Bike の一般公開データセット（bigquery-public-data.new_york.citibike_trips）を使用して、7 日間の通勤（subscriber_trips）とレジャー（casual_trips）の自転車利用を予測してみましょう。

BigQuery は、多変量予測に単一テーブルの入力形式を使用します。この形式では、次の 2 つの行セットが結合されます。

過去の観測行: 開始時間（2016 年 1 月 1 日）から予測カットオフ日（2016 年 6 月 1 日）までのタイムスタンプ。ターゲット指標、過去の共変量、既知の将来の共変量がすべて入力されています。
将来のホライズン行: 7 日間の予測ホライズン（2016 年 6 月 1 日～2016 年 6 月 7 日）にわたるタイムスタンプ。既知の将来の共変量が入力され、ターゲット列と過去のみの共変量は NULL に設定されています。

code_block: <ListValue: [StructValue([('code', "WITH data AS (\r\n SELECT\r\n DATE(starttime) AS date,\r\n IF(MIN(starttime) < '2016-06-01', COUNTIF(usertype = 'Subscriber'), NULL) AS subscriber_trips,\r\n IF(MIN(starttime) < '2016-06-01', COUNTIF(usertype = 'Customer'), NULL) AS casual_trips,\r\n IF(MIN(starttime) < '2016-06-01', AVG(tripduration / 60.0), NULL) AS avg_duration_min,\r\n IF(EXTRACT(DAYOFWEEK FROM MIN(starttime)) IN (1, 7), 1.0, 0.0) AS is_weekend\r\n FROM `bigquery-public-data.new_york.citibike_trips`\r\n WHERE starttime >= '2016-01-01' AND starttime < '2016-06-08'\r\n GROUP BY date\r\n)\r\nSELECT\r\n *\r\nFROM\r\n AI.FORECAST(\r\n TABLE data,\r\n MODEL => 'TimesFM 3.0',\r\n TIMESTAMP_COL => 'date',\r\n TARGET_COLS => ['subscriber_trips', 'casual_trips'],\r\n PAST_COVARIATE_COLS => ['avg_duration_min'],\r\n FUTURE_COVARIATE_COLS => ['is_weekend']\r\n );"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a436f50>)])]>

このクエリは、TimesFM 3.0 でサポートされている 3 つの多変量ディメンションを示しています。

相関するターゲット（target_cols）の予測: 利用者セグメントごとに個別のモデルを実行する代わりに、TARGET_COLS => ['subscriber_trips', 'casual_trips'] を渡すことで、1 回の呼び出しで両方の指標を同時に予測できます。TimesFM 3.0 は、通勤利用者とカジュアル利用者における系列間の動向（天候に対する共通の感度や、週末の利用パターンの違いなど）を捉えます。
過去の共変量（past_covariate_cols）の使用: 平均乗車時間（avg_duration_min）、過去の来店数、計画外のサービス中断など、一部のシグナルは過去にしか観測できず、事前に把握できません。PAST_COVARIATE_COLS => ['avg_duration_min'] を渡す（将来のホライズン行は NULL に設定）ことで、モデルに過去のコンテキストが提供されます。これにより、その特徴量の将来の値を必要とせずに、一時的な変動と根本的な傾向を区別できます。
将来の共変量（future_covariate_cols）の使用: 週末（is_weekend）、休日、予定されているプロモーションなど、その他の外部要因は、履歴ウィンドウと予測ホライズンの両方で事前に把握できます。FUTURE_COVARIATE_COLS => ['is_weekend']（2016 年 6 月 7 日までのすべての行に設定）を渡すことで、TimesFM 3.0 は今後のカレンダーイベントを直接反映して 7 日間の予測を行うことができます。

出力について

関数は、target_cols で指定された各ターゲット列の構造化された予測を返します。target_cols の列ごとに、AI.FORECAST はポイント予測（値）と、予測区間の下限および上限を含む構造体を返します。

日付	subscriber_trips.value	subscriber_trips.prediction_interval_lower_bound	subscriber_trips.prediction_interval_upper_bound	casual_trips.value	casual_trips.prediction_interval_lower_bound	casual_trips.prediction_interval_upper_bound	time_series_type	confidence_level	ai_forecast_status
2016-06-01 00:00:00 UTC	44699.64	32590.76	55723.44	4581.32	1727.91	9189.31	予測	0.95
2016-06-02 00:00:00 UTC	44611.75	30413.05	57209.19	4647.17	1466.23	10273.55	予測	0.95
2016-06-03 00:00:00 UTC	41379.15	26218.65	54940.09	5341.36	1568.23	11805.86	予測	0.95
2016-06-04 00:00:00 UTC	30164.34	14266.43	45075.92	9097.74	2558.27	18452.52	予測	0.95
2016-06-05 00:00:00 UTC	26727.27	10101.44	42239.33	8398.50	1692.15	17768.99	予測	0.95
2016-06-06 00:00:00 UTC	36713.84	19493.00	52679.59	4723.08	400.08	11710.73	予測	0.95
2016-06-07 00:00:00 UTC	39749.97	22157.42	56119.86	4180.97	95.70	10845.74	予測	0.95

BigQuery 会話型分析の TimesFM 3.0

BigQuery 会話型分析では、自然言語を使用して多変量予測を実行することもできます。同じ bigquery-public-data.new_york.citibike_trips データセットで、「2 か月間の過去のデータを使用して、2016 年 6 月 1 日から 7 日までの 1 日あたりの定期利用回数とカジュアル利用回数を予測してください。過去の共変量として平均利用時間、将来の共変量として週末インジケーターを使用してください」と依頼するだけです。会話型分析は、TimesFM 3.0 を使用して基盤となる AI.FORECAST クエリを自動的に生成して実行し、結果の要約、各ターゲットの予測区間を含むインタラクティブな予測グラフ、主要な予測分析情報を返します。

BigQuery 会話型分析で TimesFM 3.0 を使用した多変量予測。自然言語プロンプトから 7 日間の予測、インタラクティブなグラフ、分析情報を生成。

まとめと次のステップ

TimesFM 3.0 の多変量予測がネイティブサポートされたことで、BigQuery は、データの移動、カスタムの特徴量エンジニアリングパイプライン、専用のモデルホスティングインフラストラクチャを必要とすることなく、複雑で相互に関連するエンタープライズデータセットに対して最先端の基盤モデルによる予測機能を提供します。

BigQuery の TimesFM 3.0 で予測を開始するには:

TimesFM 3.0 モデルのアーキテクチャと機能の詳細について、Google Research のブログ投稿を読む。
BigQuery TimesFM のドキュメントを確認する。
多変量予測のチュートリアルの手順に沿って操作する。
BigQuery Studio SQL ワークスペースで `model => 'TimesFM 3.0'` を直接指定して AI.FORECAST を試す。
BigQuery で `model => 'TimesFM 3.0'` を指定して AI.DETECT_ANOMALIES を使用し、単変量時系列の異常検出を試す。
BigQuery で `model => 'TimesFM 3.0'` を指定して AI.EVALUATE を使用し、単変量時系列の評価を試す。

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

- エンジニアリングマネージャー、Haoming Chen

BigQuery で AI 費用を予測可能に: 生成 AI 関数の費用管理のご紹介

Wed, 21 Oct 2026 17:00:00 +0000

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

BigQuery の生成 AI 関数（AI.GENERATE、AI.IF、AI.CLASSIFY、AI.SCORE など）では、大規模言語モデル（LLM）が SQL に直接組み込まれるため、1 つのクエリで数百万件のサポートチケットを分類したり、感情について各商品レビューにスコアを付けたりできます。ただし、これらの関数はトークン単位で課金されるため、大規模なデータセットで使用する場合は、予算を事前に管理することが重要になります。

Google は先日、BigQuery 生成 AI 関数のトークンベースの費用管理の一般提供（GA）が開始されたことを発表しました。これは、管理者が AI トークン消費にセルフサービスのガードレールを設定できる 1 日あたりの割り当てで、チームは予算内でイノベーションを推進できるようになります。このブログ投稿では、BigQuery の生成 AI 関数の費用管理の概要を示し、いくつかの実用的な例と、利用を開始する際に役立つリソースをご紹介します。それでは詳しく見ていきましょう。

費用を管理するための割り当て

Google Cloud Identity and Access Management（IAM）割り当てシステムで管理される 1 日あたりの割り当ては 4 種類あり、プロジェクト レベルおよびユーザーレベルでの管理が可能です。ユーザーごとの上限は、組織全体ではなく、プロジェクト内の各ユーザーに適用されます。

割り当て名	指標	範囲	デフォルト値
1 日あたりの AI 入力トークン数	LLM で使用される入力トークン数	1 日あたり、プロジェクトごと	2,000 億
ユーザーごとの 1 日あたりの AI 入力トークン数	LLM で使用される入力トークン数	1 日あたり、プロジェクトごと、ユーザーごと	1,500 億
1 日あたりの AI 出力トークン数	LLM で使用される出力トークン数と思考トークン数	1 日あたり、プロジェクトごと	200 億
ユーザーごとの 1 日あたりの AI 出力トークン数	LLM で使用される出力トークン数と思考トークン数	1 日あたり、プロジェクトごと、ユーザーごと	150 億

詳細:

割り当てはグローバルです。使用量はすべてのリージョンで合計されるため、監視していないリージョンで費用が気づかないうちに積み上がることはありません。
出力割り当てには「思考」トークンが含まれます。推論トークンは、Gemini プラットフォームの請求にカウントされるのと同様に、出力割り当てにカウントされます。

対象となる関数

割り当ては、LLM を利用した生成を行う以下の BigQuery 関数に適用されます。

AI.GENERATE
AI.GENERATE_TABLE
AI.GENERATE_TEXT（およびそのエイリアス ML.GENERATE_TEXT）
AI.CLASSIFY
AI.IF
AI.SCORE
AI.AGG

対象外: AI.GENERATE_EMBEDDING（ML.GENERATE_EMBEDDING としても利用可能）や AI.EMBED などのエンベディング関数は、大幅に費用が低い別のモデルで実行されるため、これらの割り当ての対象にはなりません。

割り当ての管理

管理者は、ワークロードの変化に応じて、Google Cloud コンソールで直接割り当てを確認、調整できます。サポートケースは必要ありません。

[IAM と管理] → [割り当てとシステム上限] に移動します。
サービスでフィルタし、[BigQuery API] を選択します。
[名前] 列で並べ替えて、4 つの AI 割り当てを一番上に表示します。

[IAM と管理] → [割り当てとシステム上限] で生成 AI トークンの割り当てを確認。

4. 割り当て（1 日あたりの AI 入力トークン数など）を見つけます。

5. その他メニューを開き、[割り当てを編集] を選択します。

次の操作を行います。

費用管理を厳しくするには、割り当てを減らします。これはすぐに有効になり、承認は必要ありません。
使用量の増大に対応するには、同じページから増加をリクエストします。多くのリクエストは自動的に承認されますが、大幅な増加の場合は簡単な審査が行われることがあります。

[IAM と管理] → [割り当てとシステム上限] で生成 AI トークンの割り当てを編集。

適切な権限が必要です。オーナー、編集者 、割り当て管理者（roles/servicemanagement.quotaAdmin）、Service Usage 管理者（roles/serviceusage.serviceUsageAdmin）のいずれかが必要です。

自動化をご希望の場合は、Cloud Quotas API、gcloud CLI、Terraform を使用してこれらの割り当てをプログラムで管理し、プロジェクト全体に一貫したガードレールを適用することもできます。

使用量のモニタリング

[割り当てとシステム上限] ページでは、上限を設定できるだけでなく、トークン消費量の履歴も表示されるため、急増をすばやく検出して予算を適正化できます。これらの傾向から、新しい生成 AI ワークロードとデータパイプラインがトークンの全体的な使用量に与える影響を確認できます。

[IAM と管理] > [割り当てとシステム上限] に表示された、生成 AI トークンの割り当てに対するプロジェクトレベルの 1 日あたりのトークン使用量。

7 日間、14 日間、30 日間、カスタムの期間を選択できる長期的な使用量グラフ。

詳しい手順については、トークン割り当てによる費用の管理に関する BigQuery のドキュメントをご覧ください。

トークン割り当てと費用上限

Google Cloud の費用ガードレールは、トークン割り当てだけではありません。

トークン割り当て（この機能）は、予防的で AI 固有のものです。BigQuery はクエリ実行中のトークン使用量を追跡し、上限に近づくと処理を停止します。上限はプロジェクトごと、ユーザーごとに個別に設定されます。
Cloud Billing の費用上限は、プロジェクトレベルとサービスレベルでドル単位で設定され、しきい値に達すると自動的に使用をブロックできます。これは、使用量を正確に管理するものではなく、財務上の広範な安全策です。また、適用が即座に行われないため、超過料金が発生する場合があります。

AI 費用の最初の防御策としてトークン割り当てを使用し、プロジェクト全体のセーフティネットとして費用上限を使用します。

適用の仕組み

割り当ては、上限を超えてクエリを実行するのではなく、処理を停止することで適用されます。クエリは、必要な割り当てがすでに使い果たされている場合にのみ、事前に拒否され、その際に QuotaExceeded エラーが発生します。それ以外の場合はクエリが開始され、クエリの途中で割り当てがなくなると、BigQuery は新しい LLM 呼び出しの送信を停止します。

max_error_ratio をサポートする関数（AI.IF など）は、未処理の行が比率内に収まっている場合は部分的な結果を返し、そうでない場合は失敗します。
汎用関数（AI.GENERATE など）は成功します。ただし、スキップされた行には生成された値がなく、status フィールドには割り当て超過エラーが含まれます。

詳細については、ドキュメントの割り当ての適用動作をご覧ください。

入力データのサイズ設定: `AI.COUNT_TOKENS`

割り当て値を選択するには、ワークロードがモデルに送信するテキストの量を把握しておくと便利です。それに役立つのが AI.COUNT_TOKENS 関数です。

AI.COUNT_TOKENS は、課金対象の生成呼び出しを行わずに、モデルのトークナイザーがテキスト文字列に対して生成するトークンの数を返します。列に対してこの関数を実行して、入力データを測定します。

code_block: <ListValue: [StructValue([('code', "-- Count the input text tokens for each product review\r\nSELECT\r\n SUM(\r\n AI.COUNT_TOKENS(\r\n CONCAT('Classify the sentiment of this review as positive, negative, or neutral: ', review_text),\r\n\r\n endpoint => 'gemini-3.1-flash-lite').result) AS total_input_tokens\r\nFROM\r\n `my_project.my_dataset.product_reviews`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a482fd0>)])]>

この数は、入力トークンの下限です。出力トークンや思考トークン、各 AI 関数が入力に追加する指示、画像などのテキスト以外の入力は含まれません。次の目的でこの関数を使用します。

ワークロードを起動する前に、ワークロードの入力側を測定する。
実際の入力と出力の使用量を測定する小規模なサンプル実行と組み合わせて、割り当てを適正化する。
モデルについて公開されている Gemini プラットフォームの料金を使用して、トークンをドルに換算する。

トークンから予算まで: 具体例

たとえば、Gemini 3.1 Flash-Lite モデルを使用した、プロジェクトの 1 日あたりの AI 費用を $100 程度に抑えたいとします。現時点で公開されている料金は以下のとおりです（BigQuery はバッチ処理を行うため、50% 割引が適用されます）。

入力トークン: 100 万トークンあたり $0.125
出力トークン（回答 + 推論）: 100 万トークンあたり $0.75

小規模なサンプル実行で、入力トークンと出力トークンの比率が平均 100:1 であることがわかった場合、1 日の予算を次のように計算できます。

code_block: <ListValue: [StructValue([('code', 'Cost: 0.125 × I + 0.75 × O = 100 (I, O in millions of tokens)\r\nRatio: I = 100 × O'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a481b90>)])]>

この計算式で計算すると、1 日あたり約 7 億 5,400 万の入力トークンと 754 万の出力トークンになります。1 日あたりの AI 入力トークン数と 1 日あたりの AI 出力トークン数をこれらの値に設定して、プロジェクトの費用を 1 日あたり約 100 ドルに抑えます。プロジェクトで異なる料金のモデルを使用する場合は、モデルごとに予算を設定するか、平均料金に基づいて予算を設定します。

AI 費用管理のベストプラクティス

ユーザーごとの割り当てから始めます。これにより、1 人のユーザーや暴走したテストによってプロジェクトの予算が使い果たされるのを防ぐことができます。
規模を拡大する前に測定します。AI.COUNT_TOKENS を使用して入力のサイズを測定し、使用量グラフで小規模なサンプル実行を確認してから、上限を設定します。
出力側を意識します。出力トークンは費用が高くなります。関数で max_output_tokens を使用できる場合は、生成の長さを制限するように設定します。
モニタリングと反復処理を行います。実際の使用量と予算の変化に応じて上限を調整します。

使ってみる

トークンベースの費用管理が利用可能になりました。手順は次のとおりです。

Google Cloud コンソールで [IAM と管理] → [割り当てとシステム上限] を開き、[BigQuery API] でフィルタします。
AI 関連の 4 つのトークン割り当てを確認し、予算に合った上限を設定します。
AI.COUNT_TOKENS を使用して、入力データのサイズを測定します。

詳細については、生成 AI の費用の管理に関するドキュメントをご覧ください。

トークンベースのガードレールを導入することで、組織が必要とする費用の予測可能性を確保しながら、BigQuery で生成 AI を使用できます。

- ソフトウェアエンジニア、Tushar Jaiswal

- デベロッパーアドボケイト、Alicia Williams

オーケー: AlloyDB と Database Migration Service で「止められない基幹システム」を移行し、データドリブンな価値創出を加速

Mon, 05 Oct 2026 02:00:00 +0000

小売業界で急速な事業拡大を続けるオーケー株式会社（以下、オーケー）は、ネットスーパーの成長を支えるデータベースの基盤強化と、店舗の「止められない」業務を担うデータベースの刷新という 2 つの課題に挑戦。AlloyDB を軸とする Google Cloud のソリューションを採用し、現場への影響を極小化しながら、新たな基盤の構築に成功しています。このプロジェクトを推進してきたオーケーと KDDIアイレット株式会社（以下、KDDIアイレット）の担当者に、話を伺いました。

利用しているサービス:
AlloyDB, Database Migration Service（DMS）, BigQuery, Firebase, Partner Interconnect, Datastream, Google Workspace, Gemini など

利用しているソリューション:
データベースのモダナイゼーション

ビジネスの急成長を受けて高まった、2 つの基幹データベース刷新の必要性

オーケーは「高品質・Everyday Low Price」を経営方針に掲げ、関東・関西に 180 店舗以上を展開するディスカウントスーパーマーケットです。同社は高品質な商品でありながら、特売日を設けず毎日が低価格の「Everyday Low Price（EDLP）」方針を徹底し、「小売 × IT」の最先端の仕組みづくりに挑戦してきました。2020 年に Google Cloud を導入し、オンプレミスのデータウェアハウスを BigQuery へと刷新したのを皮切りに、2021 年には「オーケーネットスーパー」を開始。会員向けスマートフォンアプリも、Firebase を活用して短期間で構築するなど、デジタル領域での顧客体験向上に注力しています。

しかし、オーケー IT本部副本部長の荒川健児氏は、こうした取り組みの裏側で、システムの心臓部を担う 2 つのコアデータベースの刷新が求められていたと振り返ります。1 つ目は、ネットスーパーの顧客体験向上を担う「ネットスーパー DB」です。

「この領域は将来的には法人利用も視野に入れており、増大するトランザクションに柔軟に対応できるスケーラビリティと、インフラ運用コストの最適化が強く求められていました。従来は他社のクラウド上で稼働しており、データが各システムにサイロ化していたのが実情です。このため高度な分析基盤や AI と連携しながら、お客様に対してパーソナライズされた提案をリアルタイムに行えるようにすることが目標となっていました。」

2 つ目のデータベースは、日々の店舗業務を支える「生鮮 DB」です。これは各店舗のマスター情報や仕入れ、棚卸し、販売実績といったデータを蓄積し、全店舗からのデータ参照や現場の帳票出力などに対応しており、絶対に止めることができないシステムです。

「『生鮮 DB』については長年稼働してきたオンプレミス環境からの脱却を目標にしていましたが、新しいクラウド環境とオンプレミス環境が並存する過渡期に、データ連携と一貫性をいかに維持するかという課題がありました。また『生鮮 DB』は、現場に定着している業務プロセスと密接に結びついているため、一斉停止を伴う全面移行をいかに避けるかも問われていました。」（荒川氏）

AlloyDB の採用により、業務の根幹を支えるデータベースの移行と基盤統一を実現

現行業務への影響を最小限に抑えながら、既存のデータベースからコアデータを安全に切り離し、新たなクラウドに段階的に移行する。この難易度の高いミッションをクリアすべく、オーケーは基本方針の決定からネットワーク構築、PoC（概念実証）、データ移行、本番切り替えまでのサポートを KDDIアイレットに依頼します。評価されたのは、Google Cloud 導入支援と運用最適化を多数手がけてきた実績でした。

これ以降、両社は共に検討を重ね「ネットスーパー DB」と「生鮮 DB」の移行先を統一し、その共通基盤として AlloyDB の採用を決定しました。KDDIアイレットで開発を率いた齋藤寛隆氏は、その選定理由として 5 つのポイントを挙げています。

「まず大前提となったのは高可用性です。AlloyDB は、止められない生鮮業務を支えられる『99.99% のサービスレベル契約（SLA）と約 15 秒のフェイルオーバー』という性能を持っていました。2 つ目は、標準的な PostgreSQL 比で 4 倍以上のトランザクション処理性能、3 つ目は、オートバキュームなどの自動化による運用負荷の削減です。4 つ目はすでに活用されている BigQuery との親和性で、最後は移行支援ツールの充実も決め手になりました。」

AlloyDB への統合にあたっては、「セキュアなプライベート通信の確立」と「種類の異なるデータベース間での無停止移行」という要件がありました。まず通信に関しては、オンプレミスのデータセンターや他社クラウドから Google Cloud へ Partner Interconnect の専用線で接続。インターネットを経由せずに AlloyDB と通信できる閉域網環境が構築されています。

データ移行では、DB ごとに方法が使い分けられました。「ネットスーパー DB」は一部データの移行となり、システムを停止させることが可能だったため、対象データを既存の PostgreSQL からエクスポートし、AlloyDB へインポートする方法が採用されています。これに対して「生鮮 DB」は、システムを止めることができないため、データ移行をアシストする Database Migration Service（DMS）が活用されました。

「『生鮮 DB』の移行では、DMS を用いて従来のデータベースのトランザクションログから差分データを解釈し、新しいデータベースへ継続的にデータ書き込みを行う方式を採用しました。これはクエリを発行しないため、稼働中のデータベースへの負荷を最小限に抑えることができます。また、差分のみの転送で遅延を最小限に抑えつつ、切り替え時のダウンタイムの極小化が実現できると判断し、DMS の採用を決めました。」（齋藤氏）

この移行プロセスでは、KDDIアイレットの知見も活かされています。スキーマ変換では、DMS のコンバージョンワークスペースと Gemini の変換提案を活用して作業の効率化を実現。DMS が対応していない日本語のカラム名では、英数字の仮テーブルを経由して、移行後に再設定する方法が採られています。移行後のデータ検証には、Google Cloud のデータ検証ツールが使用されました。

Gemini や AlloyDB AI も活用しながら、DX と新たな価値創出を追求

今回の移行プロジェクトで得られた技術的な成果を、齋藤氏は次のように総括します。

「『生鮮 DB』は日々の業務を担う『止められないシステム』です。本プロジェクトでは、止められないから移行を諦めるのではなく、ダウンタイムを極小化しながら AlloyDB に移行することで要件をクリアしただけでなく、将来的なデータ活用まで視野に入れることができました。BigQuery との連携では、Datastream を活用することにより、セキュアな通信を維持したまま、AlloyDB から BigQuery へニアリアルタイムにデータを連携できるようにもなりました。」

一方、荒川氏は AlloyDB を軸とした新たなデータベース基盤が、現場における業務を大きく変えつつあると説明します。

「従来、生鮮の現場では、担当者が独自のツールを使って DB からデータを抽出し、手作業で表計算ソフトの集計や状況確認を行っていました。しかし新たなシステムでは、BigQuery 上に生鮮のニアリアルタイムなデータを集約し、さらに天気情報や人流データ、客数予測といった外部データを掛け合わせることが可能になります。店舗での売り上げ情報を即座に反映して『製造の推奨数』を算出することにより、生鮮領域のロスを削減しながら、売り上げを増やすための合理化も図られるようになりました。」

オーケーではデータドリブンな業務改革を定着させるため、環境づくりも進められています。実際に必要とされるデータやシステム運用のリテラシーは職種や部門によって異なるため、AI をエージェント化し、自然言語でデータを活用できるようにする取り組みが始まっています。「自動化できるところは AI で積極的に自動化し、人間は本当に考えるべき業務だけを担う」という発想には、少子高齢化による人手不足に対応する狙いも込められています。

「小売 × IT」で新たなニーズに対応し、事業成長を牽引していく。このアプローチを推進し続けるべく、荒川氏は Google Cloud のエコシステムを活用しながら、DX の推進と顧客体験の向上を図りたいと改めて強調しました。

「デジタル上で店舗の商品を見つけやすくすることは、顧客体験を向上させ、売り上げを伸ばす意味でも重要です。例えば従来のキーワード検索では、『コレステロールが気になる人向けの油は？』といった問いかけに対し、商品を見つけられないことがありました。しかし AlloyDB AI を活用すれば、意味や文脈を汲み取った検索や、類似商品の提案も可能になっていきます。AlloyDB や BigQuery はもとより、Google Workspace や NotebookLM、Gemini をはじめとするツールには、データ連携や集約がシームレスに行えるという大きな魅力があります。今後も KDDIアイレットや Google Cloud のサポートを受けながら先進的な IT を活用し、お客様に提供する価値を高め続けていきたいと考えています。」

オーケー株式会社
1958 年創業。「高品質・Everyday Low Price」を経営方針に掲げ、関東（1 都 3 県）、関西（大阪府・兵庫県）に 180 店舗以上のディスカウントスーパーマーケットを展開。高品質な商品でありながら、特売日を設けず毎日が低価格の「Everyday Low Price（EDLP）」方針を徹底し、ナショナルブランド商品については地域一番の最安値を目指す。2024 年には関西エリアにも進出し、年商 7,500 億円を超える規模へと成長している。

KDDIアイレット株式会社
2003 年 8 月にアイレット株式会社として創業し、2017 年 2 月に KDDI株式会社の傘下に。2026 年 4 月に KDDI Digital Divergence Holdings株式会社との合併により、社名を KDDIアイレット株式会社に変更。クラウドインテグレーション事業、開発事業、デザイン事業、提携事業を展開し、Google Cloud パートナーとして、インフラの移行や新規構築、アプリケーション開発、AI エージェント開発まで数多くの実績を持つ。

インタビュイー（写真左から）

・オーケー株式会社
　IT本部副本部長　荒川健児氏

・KDDIアイレット株式会社
　クラウド・イノベーション本部クラウドインテグレーション事業部グループリーダー
　齋藤寛隆氏

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

ボーダーレスな Lakehouse を加速: クロスクラウドキャッシュのプレビュー版を発表

Fri, 02 Oct 2026 01:10:00 +0000

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

この投稿では、ボーダーレスな Lakehouse の機能強化についてお知らせします。これは、データエンジニア、データサイエンティスト、そして急速に導入が進む AI エージェントが、管理されたデータをその保存場所で直接クエリできるようにするためのソリューションです。

正確な推論を行い、複雑なエンタープライズワークフローを自動化するには、あらゆるタイプのエージェントとデータ利用者が、組織のデータ資産すべてに迅速かつ統合的にアクセスできる環境が必要です。そうした環境であれば、クラウドをまたいで顧客レコード、トランザクションログ、運用テレメトリーを結合することが可能になります。しかし、現代の企業データが 1 か所に収まっていることはほとんどありません。データ資産は、Amazon S3、Azure Data Lake Storage（ADLS）、Google Cloud Storage、オペレーショナルデータベース、さらには Salesforce、SAP、Workday などの SaaS プラットフォームに分散しているのが一般的です。これまで、こうした分散したデータセットの統合には、不安定な ETL パイプライン、ストレージの重複、極めて高額なクロスクラウドデータ転送費用がつきものでした。

組織がクラウドをまたいでデータをクエリして有効活用できるようにするため、今年 Google はボーダーレスな Lakehouse を導入しました。Apache Iceberg REST カタログ仕様を採用することで、Databricks Unity Catalog、AWS Glue、Snowflake Horizon などのカタログとの直接連携が可能になりました。また、他のクラウドプロバイダへの高帯域幅のプライベートリンクを確立する Partner Cross-Cloud Interconnect も導入しました。この接続により、1 ギガバイトあたりの転送費用を公共のインターネットを使用するよりも削減できます。

今回の機能強化では、「そもそもネットワーク経由で転送する必要があるデータの量を最適化する」ことで、マルチクラウドの効率化をさらに一歩進めました。

クロスクラウドデータのクエリ費用をさらに削減する、2 つの新機能をご紹介します。1 つは、Lakehouse 向けのクロスクラウドキャッシュのプレビュー版です。頻繁にアクセスされるデータを Google Cloud 内にローカルキャッシュすることで、ユーザーに意識させることなく BigQuery でのクロスクラウドクエリを高速化し、リモート転送の費用も削減することができます。標準的な Iceberg の列圧縮とクロスクラウドでのキャッシュ保存を組み合わせることで、クラウド間で実際に転送するデータの量を処理データの 5% 未満にまで抑えられることも珍しくありません。これにより、総所有コスト（TCO）を削減して、エンタープライズ規模でのクロスクラウド分析と AI 活用を実現できます。もう 1 つは、BigQuery のクロスクラウド接続のプレビュー版（こちらも提供中）です。この機能を使用すれば、他のクラウドにある Iceberg 以外のデータをクエリしてワークロードを高速化できます。

クロスクラウドキャッシュの仕組み

クロスクラウドキャッシュは、パラメータ調整やストレージ管理を一切必要とすることなくクエリを高速化し、企業が求める高度なパフォーマンスとセキュリティ要件を両立させます。それを実現する内部メカニズムの一部をご紹介します。

サブファイルブロック単位での処理: Apache Parquet などのカラム型フォーマットでは、クロスクラウドキャッシュはサブファイルブロックレベルで動作します。そのため、クエリが数列にしかアクセスしない場合、数ギガバイトに及ぶファイル全体をクラウド間で転送する必要がなくなります。BigQuery は、クエリで指定された特定の列チャンクと辞書ページのみをキャッシュ保存します。キャッシュミスが発生すると、BigQuery はクエリに応答するために必要なデータをリモートクラウドから取得し、将来のクエリのためにコピーをローカルにキャッシュ保存します。これにより、繰り返し発生するワークロードのネットワーク転送とレイテンシを大幅に削減できます。
デフォルトの保存データの暗号化: キャッシュに保存されたデータブロックは、Google が管理する暗号鍵（GMEK）によってデフォルトで暗号化されます。一時的なキャッシュストレージであっても、追加のオーバーヘッドなしで、通常の BigQuery ストレージと同様のエンタープライズグレードのセキュリティポスチャーを維持します。
テナントとリージョンの分離: キャッシュエントリは、プロジェクトとカタログの境界ごとに厳密に分割され、テナント間でのデータ漏洩を防ぎます。Lakehouse は、ローカルキャッシュとクエリ実行の両方を、指定された Google Cloud リージョン（例: us-east4）に厳密に限定します。これにより、リモートクラウドへのクエリ実行時にも、各リージョンのデータ所在地要件への準拠を支援します。
更新頻度チェック: マルチクラウドキャッシュでは、処理速度と鮮度のトレードオフを強いられることがよくあります。ステイル読み取りを防ぐため、BigQuery はキャッシュに保存されたデータを使用する前にリモートオブジェクトのメタデータを取得して、データが変更されておらず、ユーザーが引き続きアクセスできることを確認します。元データのテーブルが変更されると、BigQuery は新しいファイルをフェッチし、参照されなくなったキャッシュブロックは自動的に破棄します。これにより、信頼できる唯一の情報源の正確性を維持しながら、ローカルクエリと同等の速度を実現します。

キャッシュの仕組み、統計カウンタ、リージョンに関する留意事項について詳しくは、Lakehouse のインテリジェントキャッシュに関するドキュメントをご確認ください。

クロスクラウドキャッシュの実際の操作

では、日常業務において、この仕組みはどのように動作するのでしょうか。例として、e コマースチームが、Databricks Unity Catalog から Lakehouse に統合された Amazon S3 の 10 TiB の Iceberg 売上テーブル（aws_lakehouse_catalog.sales.web_sales）に対してクエリを実行する場合を考えてみましょう。夕方のタイムセールの時間帯（午後 8 時～9 時）には、アナリストが過去の取引データをクエリし、購入意向の強いユーザー層において、どのオンライン店舗がピーク時の取引量と収益を押し上げているかを特定します。

code_block: <ListValue: [StructValue([('code', 'SELECT w.web_name, hd.hd_buy_potential, COUNT(*) AS total_transactions, ROUND(SUM(ws.ws_sales_price), 2) AS total_sales\r\nFROM `aws_lakehouse_catalog.sales.web_sales` ws\r\n-- Joins household_demographics, time_dim (8:00-9:00 PM), and web_site.\r\nGROUP BY w.web_name, hd.hd_buy_potential;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a434850>)])]>

初回実行: コールド状態でのカラム型データ取得

この最初のコールド実行では、ローカルキャッシュは空の状態です（cacheBytesRead: "0"）。BigQuery は、パーティションのプルーニングと列投影を適用して、必要な Parquet バイト範囲のみを Partner Cross-Cloud Interconnect 経由で Amazon S3 から転送します。

code_block: <ListValue: [StructValue([('code', '{\r\n "totalBytesProcessed": "230343464114",\r\n "objectStorageStats": [\r\n{"cloudProvider": "AWS", \r\n"objectStorageBytesRead": "25834740486", \r\n"cacheBytesRead": "0"}]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a46f0d0>)])]>

処理される論理データ: BigQuery は、10 TiB のデータセット全体のうち 214.5 GiB を処理します。
標準的な Iceberg の圧縮効率: Zstandard（zstd）を使用した標準的な Iceberg 列圧縮により、BigQuery が S3 から読み取るのは24.1 GiB のみです。これは8.9:1 の圧縮率に相当します。これらのサブファイル Parquet ブロックが Google Cloud に到着すると、BigQuery はそれらのデータをリージョンキャッシュに保存します。

追加の探索: ディメンションの追加

実際には、アナリストやエージェントがまったく同じクエリを 2 回続けて実行することはほとんどありません。フルフィルメントの詳細をさらに深堀りするため、アナリストは配送方法ディメンション（sm.sm_type）を追加してクエリを修正します。

code_block: <ListValue: [StructValue([('code', 'SELECT w.web_name, sm.sm_type, hd.hd_buy_potential, COUNT(*) AS total_transactions, ROUND(SUM(ws.ws_sales_price), 2) AS total_sales\r\nFROM `aws_lakehouse_catalog.sales.web_sales` ws\r\nJOIN `aws_lakehouse_catalog.sales.ship_mode` sm ON ws.ws_ship_mode_sk = sm.sm_ship_mode_sk\r\n-- Reuses existing joins on household_demographics, time_dim, and web_site.\r\nGROUP BY w.web_name, sm.sm_type, hd.hd_buy_potential;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a46da50>)])]>

この後続クエリのジョブ統計は次のようになります。

code_block: <ListValue: [StructValue([('code', '{\r\n "totalBytesProcessed": "287928766472",\r\n "objectStorageStats": [\r\n{"cloudProvider": "AWS", \r\n"objectStorageBytesRead": "1426587648", \r\n"cacheBytesRead": "25834740486"}]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a46e8d0>)])]>

94.8% のキャッシュヒット率: BigQuery は、以前にクエリを実行した列の 24.1 GiB をローカルキャッシュから直接返します。
最小限のリモート取得: BigQuery は、新しい ws_ship_mode_sk 列と ship_mode テーブルを対象に、S3 から 1.33 GiB だけを転送します。
サブファイル単位の柔軟性: キャッシュに保存された列チャンクが再利用されるため、クエリを修正しても新たに必要になったバイトのみが転送されます。

エンタープライズ規模で効率性を向上

クロスクラウドクエリの TCO を検討する際に重要となる、上位 2 つの要素は次のとおりです。

圧縮率: Iceberg でデフォルトの圧縮アルゴリズム（Zstandard / zstd）を使用すると、カラム型データは高い圧縮効果を発揮します。データの圧縮率が 8:1 であると仮定した場合、処理される論理データ 1 TiB ごとに、ネットワーク経由で移動する必要があるデータは約 128 GiB のみとなります。
キャッシュヒット率: 最近アクセスされたデータをネットワーク経由ではなくキャッシュから取得できれば、ネットワーク転送を回避できます。データの 80% がキャッシュヒットになると仮定すると、アクセスされる物理データ 100 GiB ごとに、ネットワーク上を移動するデータは 20 GiB のみとなります。

これらの 2 つの要素と前提条件を掛け合わせると、組織が処理するデータ 1 TiB あたり、ネットワーク経由で転送する必要があるデータ量は約 26 GiB（処理されるデータ全体の 3% 未満）で済みます。この削減効果と Partner Cross-Cloud Interconnect を組み合わせることで、TCO を削減し、ペタバイト規模のクロスクラウド分析や AI 活用を極めて優れた費用対効果で実現できます。

BigQuery クロスクラウド接続のプレビュー版を提供開始

クロスクラウドキャッシュと併せて提供開始となった BigQuery クロスクラウド接続のプレビュー版では、BigQuery を Amazon S3 や Azure Storage のオープン形式データに直接接続することができます。

カタログ連携とクロスクラウド接続のどちらを使うべきかの判断基準はシンプルです。

BigQuery のクロスクラウド接続（元ファイル用）: Iceberg カタログで管理されていないスタンドアロンファイル（CSV、JSON、アドホックな Parquet）の場合、クロスクラウド接続を利用することで、リモートのバケットパスを直接参照する BigQuery 外部テーブルを作成できます。
Lakehouse カタログ連携（Iceberg 向け）: Databricks Unity、AWS Glue、Snowflake Horizon などのカタログで管理されている Iceberg データの場合、Lakehouse がスキーマとテーブルスナップショットを自動的に同期します。これにより、ユーザーエクスペリエンスが簡素化され、ユーザーが常に最新のデータに対してクエリを実行できるようになります。

クロスクラウド接続は、他のクラウドのコンピューティングワーカーではなく、Google Cloud リージョン内の標準 BigQuery コンピューティングワーカーを使用する、最先端のアーキテクチャを採用しています。このアプローチにより、世界各地のリージョンでの利用が可能になるほか、リモートファイルでも BigQuery と同等の機能（BigQuery AI や Gemini を含む）が提供されます。

Lakehouse のクロスクラウドキャッシュ機能は、BigQuery のクロスクラウド接続からクエリされたデータと、Lakehouse カタログ連携のデータの双方に適用されます。接続の作成方法や外部バケットパスへのクエリ実行方法については、BigQuery のクロスクラウド接続の設定に関するドキュメントをご確認ください。

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

- スタッフソフトウェアエンジニア、Jason Ganetsky

電気通信事業者の自律性の拡張: Distributed GraphFlow を使用したグラフニューラルネットワークの活用

Wed, 30 Sep 2026 10:00:00 +0000

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

通信業界は現在、従来の人間による手動運用から、完全な自律型ネットワーク運用へのパラダイムシフトを経験しています。最新のネットワークは複雑性、異種性、大規模性を増しているため、運用の自動化を実現するには、手動で設定したルールによるルールベースの手法や従来型の機械学習（ML）手法だけでは不十分です。従来の ML は大量の構造化データから微妙なパターンを特定してきめ細かな予測を行うことができる一方、データとそれが示すシステムを理解して推論し、最終的に人間のオペレーターと同じような意思決定を行う能力はありません。

AI エージェントの成長とその推論能力は、この課題に対する有望な解決策となります。しかし、人間のオペレーターが大規模なネットワーク中に作成された数十億のデータポイントに分散した統計情報を直接取り込むことができないのと同様に、AI エージェントにもそのような規模のネットワークを運用する能力はありません。この課題に対処するために電気通信事業者が採用しているのがグラフニューラルネットワーク（GNN）です。GNN は、大量の時間データやリレーショナルデータをネイティブに処理するように設計された最新の ML です。電気通信事業者は、GNN を AI エージェントと統合することで、根本原因分析、キャパシティプランニング、トラフィック予測、What-If 分析、リアルタイムの異常検出などの高度な診断を、これらの分析情報を解釈して正当なアクションを実行するために必要な推論能力と組み合わせて利用できます。この強力な組み合わせにより、ネットワークを TM Forum が定義するレベル 5 の自律性（システムが自律的に動作する状態）に安全に移行させることが可能になります。

この投稿では、Google Cloud の自律型ネットワーク運用フレームワークを強化する 3 つのコンポーネント（データ、ML、AI）を紹介します。

Google 自律型ネットワーク運用フレームワークのアーキテクチャ

基盤: Spanner Graph 上のデジタルツイン

Google Cloud の自律型ネットワーク運用フレームワークの中核となるのは、ネットワークデジタルツインです。これは、稼働中の通信ネットワークをリアルタイムで継続的にミラーリングし、細部にわたって忠実に再現する仮想レプリカです。静的なモデルではなく、進化し続けるコンポーネントの状態と関係を経時的に捉える、動的な時系列ネットワークグラフとして表現されます。このアーキテクチャアプローチにより、オペレーターは過去に「戻って」過去のデータで ML モデルをトレーニングおよび評価できると同時に、レベル 5 の自律性を実現するために必要な基本的な運用知識を AI エージェントに提供できます。デジタルツインは、提案されたネットワーク変更の影響をこのデジタル環境内でシミュレートすることで、信頼性の重要なレイヤを確立し、AI エージェントが自信を持って将来の状態を設計し、ネットワークの問題を自動的に解決できるようにします。

Google Cloud の Spanner Graph はこのデジタルツインをホストするのに最適なサービスですが、その理由は以下のとおりです。

スケーラビリティと可用性: Spanner Graph は、最新のアプリケーションに妥協のない基盤を提供します。ネットワークの成長に合わせて事実上無制限にスケーリングでき、RPO と RTO はともに 0 であると同時に、99.999% の可用性を保証します。
マルチモデルのサポート: 単一のプラットフォームで複数のデータモデル（リレーショナル、グラフ、ベクトル、全文検索）をサポートしているため、グラフ走査と最近傍ベクトル検索を組み合わせるなど、複雑な構成の構築が可能です。
グローバルな整合性: Spanner は、グローバルに整合性のあるネットワークビューを提供し、システム開発を簡素化します。

次の図は、ルーター、インターフェース（物理ポート）、VPN（L3VPN サービスインスタンス）、フロー（アクティブなトラフィックセッション）の 4 種類のノードを含むネットワークトポロジを示しています。これらは、ネットワークスタック全体をキャプチャする有向エッジによって接続されます。接続の種類としては、ルーターとインターフェース間の物理的封じ込め、インターフェース間の物理リンク、OSPF/iBGP を介したルーター間のコントロールプレーンピアリング、ルーターと VPN 間のサービスメンバーシップ、フローとインターフェース間およびフローと VPN 間のトラフィックアンカリングが挙げられます。

ネットワークトポロジの概要

ML レイヤ: Distributed Graph Flow（DGF）

ネットワークの動作と反応を予測するために、デジタルツインは Distributed Graph Flow（DGF）を活用した ML レイヤを利用します。このレイヤは、Spanner Graph 内にホストされている膨大な量の過去の構造化データでトレーニングすることで、重要な予測的分析情報を引き出します。これにより、人間のオペレーターと AI エージェントは、事後的ではなく事前的にネットワークを管理できるようになります。

先日オープンソース化された DGF は、GNN モデリングのエンドツーエンドのライフサイクル全体を管理するために設計された Python ライブラリです。Google CoreML と Google Research によって開発されたこのライブラリにより、Google Cloud の企業クライアントは、Google が 10 年にわたり開発してきた社内ツールと専門知識を直接活用できるようになります。さまざまなエンジニアリングニーズに対応するこのライブラリは、高度なチーム向けに高性能でコンポーズ可能な低レベルプリミティブを提供するほか、GNN の専門知識なしで迅速な開発を行うためのシンプルな API も提供しています。

たとえば、高レベル API を使用して GraphFlow で GNN モデルをトレーニングして評価する場合、次のように 5 行のコードを記述するだけで済みます。

code_block: <ListValue: [StructValue([('code', 'import dgf\r\n\r\n# Fetch the data from Spanner Graph\r\ngraph, schema = dgf.io.read_spanner_graph(...)\r\n\r\n# Train a node attribute prediction model\r\nmodel = dgf.learning.train_node_model(graph, schema, target_column="risk_score")\r\n\r\n# Evaluate the model\r\nmodel.evaluate()\r\n# Make predictions\r\nmodel.predict(graph, seed_node_idxs=[0, 1, 2])\r\n\r\n# Save the model for later\r\nmodel.save("/tmp/model")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a446ed0>)])]>

DGF は、自律型ネットワーク運用要件に直接マッピングされる最上位概念を提供します。

ユースケース

DGF と GNN を活用する電気通信事業者は、複数の高度なユースケースを通じて、事後保守から予防保守へと移行できます。

異常検出: GNN は、過去のパターンと現在の状態をカプセル化したノードとエッジのエンベディングを生成します。異常なエンベディングは、サービスの低下につながる前に調査対象としてフラグが立てられます。
根本原因分析（RCA）: DGF は、特定の郵便番号での「接続失敗」など、インシデントに関連するネットワークインスタンスのみを含む特定のサブグラフを出力できます。グローバルネットワーク全体をスキャンする必要性がなくなるため、トラブルシューティングエージェントは、分析を高速で実行できます。
予測メンテナンス: システムは、高速移動する機器の「ハンドオーバー障害」など、デバイスの障害やエッジの切断の可能性を予測し、プロアクティブなロードバランシングやルート変更を可能にします。さらに、エージェントを組み合わせることで、「人間関与型」や「人間参加型」を採用して修復アクションを自動化できます。
What-If 分析: GNN を使用すると、電気通信事業者はファイバーの切断、トラフィックの急増、デバイス構成の変更などのシナリオをシミュレートできます。GNN は、トポロジカルな依存関係をモデル化することで、こうした局所的な変化がネットワーク全体にどのように伝播するかを予測できるため、エンジニアはリスクのないデジタル環境で復元力をテストし、緩和戦略を評価できます。

シナリオ: GNN と DGF を使用した根本原因分析

デジタルツインを作成したら（サンプルコード）、以下の簡単な 5 ステップのプロセスで、GNN と DGF を使用した根本原因分析（RCA）検出を実装できます。

デジタルツインに接続する: DGF Spanner Graph コネクタ（dgf.io.read_spanner_graph）を使用して、Spanner Graph のデジタルツインから DGF 環境にネットワークトポロジを直接読み込みます。
教師ありノード（またはエッジ）予測モデルをトレーニングする: トレーニングデータと目的に応じて、教師ありノード予測モデルをトレーニングしてターゲットノードの特徴を予測するか、エッジ予測モデルをトレーニングして根本原因エンティティノードと影響を受けるエンティティノード間のエッジを予測します。指定されたサンプルデータに対して、高レベルの dgf.learning.train_node_model API を使用して、教師ありノード予測モデルをトレーニングします。
ノード予測モデルを使用して根本原因ノードを予測する: ノード予測モデルを直接使用して、異常のあるノードへの影響スコアを予測できます。異常の影響を受けるエンティティノードのうち、予測される影響スコアが最も高いものが根本原因の最有力候補となります。
Gemini Enterprise Agent Platform（旧称 Vertex AI）にデプロイする: モデルをエクスポートして Gemini Enterprise エンドポイントにホストし、スケーラブルかつ低レイテンシの予測を可能にします。
リアルタイム推論: 異常の日付を入力として、推論エンドポイントに予測呼び出しを行います。エンドポイントは、予測された根本原因のエンティティノードを返します。

使ってみる

Distributed Graph Flow を使用した GNN のネットワーク運用への統合は、単なる技術的なアップグレードではなく、通信業界の重要な進化です。GNN を活用した自律型フレームワークに移行することで、電気通信事業者はサービス停止時間を大幅に短縮し、リアルタイムで容量を最適化できます。さらに、最終的には運用効率の向上を通じて優れたカスタマーエクスペリエンスを提供することにもつながります。

独自のインテリジェントネットワークアプリケーションの構築を始めるには、スケーラブルな GNN トレーニングと推論に不可欠なプリミティブを提供する Distributed GraphFlow（DGF）ライブラリをご覧ください。実践演習を行う場合は、コードサンプルの手順に沿って進めます。また、当社が最近受賞したビジネスアウェア GNN ヒーリングネットワークに関するムーンショットプロジェクトもご覧ください。自己最適化自律ネットワークに対する Google のアプローチについては、こちらのホワイトペーパーをご確認ください。

千葉大学：LMS の Google Cloud 移行で「止まらない教育インフラ」を実現。運用負荷の大幅軽減とデータ駆動型教育への挑戦

Tue, 29 Sep 2026 17:00:00 +0000

2020 年に発足した「スマートオフィス」を中核に、千葉大学は全学的な教育 DX を加速させています。オンプレミスから他社クラウド、そして Google Cloud へ。その歩みは、単なるサーバーの移設ではなく、大学が自ら IT インフラの最適解を見極めながら、Google Cloud とともに教育の質を向上させてきた挑戦の記録でした。

千葉大学では、学習管理システム（LMS）として Moodle を運用し、教育活動の基盤としています。この不可欠なインフラをいかにして「持続可能で高品質なもの」へと進化させたのか。実際にこの取り組みに携わった理事（総括・教育・国際）の小澤弘明氏、当時のスマートオフィス長・副学長（学修支援）の竹内比呂也氏、およびスマートオフィスの皆様にお話を伺いました。

【背景】コロナ禍で露呈したオンプレミスの限界と IaaS の課題

コロナ禍以前、千葉大学の LMS はオンプレミス環境で運用されていました。当時は物理的な機器トラブルやネットワーク障害、さらには停電への対応に追われる日々でした。

「物理的なトラブルに加え、これらに対応できる専門知識を持つ職員が少なく、運用負荷やセキュリティ面での不安が大きな課題でした」と担当者は語ります。

2020 年、コロナ禍によるアクセス急増を受け、まずは他社クラウドへの移行を断行しました。しかし、そこでの構成はすべて IaaS（仮想マシン）であったため、物理的なトラブルからは解放されたものの、OS の管理やパッチ当てといった運用負荷は依然として残ったままでした。

Google Cloud を検討したきっかけは、教育現場での Google Workspace の浸透でした。学生のメールをGmail に移行したり、同時双方向のオンライン授業のためのツールとして Google Meet などの活用が進んだりする中、アカウント認証を統合できるメリットは運用上極めて大きいものでした。

さらに、学術情報ネットワーク（SINET）とのプライベート接続におけるコストパフォーマンスが優れていたため、教育系システムを全面的に移行することになりました。

【プロセス】組織の壁と技術的ハードルを乗り越えた「三者連携」

移行プロジェクトは、事務補佐員を含め約 10 名の職員と 4 名の教員で構成される「スマートオフィス」が主導しました。しかし、当時は学内にクラウドに深い知見を持つ人材が不足しており、大きな壁にぶつかります。

組織内の合意形成： ISMAP などの評価基準が定まる前だったこともあり、機微な学生情報をクラウドへ移行することに対し、学内のセキュリティ面でのすり合わせに苦心しました。
技術的難所（SINET 接続）： セキュリティを担保するため、商用ネットを介さず SINET から直結する構成を目指しましたが、ベンダーとの調整が難航しました。

技術的なハードルの克服に向けては、コンサルタントとして参画していた早稲田大学アカデミックソリューション（WAS）が各者の橋渡し役を担いました。千葉大学、Google Cloud、運用ベンダーの三者間に立ち、Google Cloud の知見も取り入れながら実務レベルの調整を積み重ねることで、難航していたシステム実装を実現しました。

【アーキテクチャ】安定性と先進性を両立する「クラウドネイティブへの道筋」

現在のシステム構成は、単なる「リフト＆シフト（そのまま移行）」ではありません。将来的なサーバーレス化を見据えつつ、現時点での安定性を最大化する工夫が施されています。

安定稼働の追求： 多くの学生が一斉にアクセスするピーク時のパフォーマンスを確保するため、アプリケーションサーバーは Compute Engine（VM）による 3 台構成を採用しています。
PaaS への積極移行： データベースは Cloud SQL (MySQL)、キャッシュ層は Memorystore (Redis) へと PaaS 化。これにより、管理者を苦しめていた OS の管理工数から解放されました。
先進的な試行： Cloud Run を活用したフロントエンド構築も開始しており、「使った分だけ支払う」というクラウドのメリットを最大限に享受しています。
強固な防御： WAF として Cloud Armor を、ファイアウォールとして Cloud Firewall（Cloud NGFW）を活用し、機密性の高い学生データを守っています。

【導入効果】管理工数の削減が、教員と学生の「自由」を生む

導入前に課題となっていた、停電、負荷増大による処理停止や、証明書更新のためのシステム停止等の懸念点については、Google Cloud に移行し、マネージド証明書を利用することによって解決することができました。

システム運用における具体的な効果は以下の通りです。

運用の自動化： SSL 証明書の更新はマネージド証明書で自動化。サーバーごとの個別監視も、ログを BigQuery へ転送して一括管理することで不要になりました。
教育の質の向上： 「課題締切直前にサーバーが落ちるかもしれない」という不安から学生が解放されたことは、学習体験に大きなプラスとなりました。教員側も、小テストの自動採点やオンライングループワークといった LMS の機能をフル活用した、より高度な教育設計に躊躇なく挑戦できるようになっています。
運用工数とコストの削減： 全体で約 20~30 ％の工数削減を達成し、コスト削減と運用効率化の両方を実現しました。

「LMS は、あって当たり前のインフラとして機能することに意味があります。学習の本質とは無関係なストレスを取り除くことで、初めてデータに基づいた教育改善が可能になるのです」

【展望】AI とデータ分析で「次世代の学び」へ

同大は今後、API を利用した学内向け RAG（検索拡張生成）の構築や、LMS の利用ログを BigQuery で蓄積し、Looker で可視化・分析する「ラーニング・アナリティクス」の計画を検討しています。

【メッセージ】「IT に関する判断」をベンダーに委ねない

「クラウドは、ベンダーの報告を自分たちで直接確認し、判断することを可能にします。少ない学習コストで自ら利活用できるからこそ、ベンダー主導では実現しにくい、教育現場に根差した仕組みを構築することができる。IT に関する判断を自らに取り戻すこと。これこそが、クラウド移行で最も重要な視点です。」

プロフィール（敬称略）

国立大学法人千葉大学

理事（総括・教育・国際）：小澤弘明
副学長（教育改革・学修支援）（※2023 年度～2025 年度）：竹内比呂也
スマートオフィスの皆様

利用サービス： Compute Engine, Cloud Run, Cloud SQL, Memorystore, Cloud Storage, Filestore, Cloud Armor, Cloud Load Balancing, BigQuery, Google Workspace, Looker

住友重機械工業: Google Cloud で SDV 開発基盤を構築し、大型機械用ソフトウェア開発の高速化と人材育成を両立

Tue, 29 Sep 2026 02:00:00 +0000

「デジタルの力で、世界中の現場を快適に、携わる人々を幸せに」というビジョンに基づき DX を推進している住友重機械工業株式会社（以下、住友重機械工業）では、製造業 DX と SDV（Software Defined Vehicle）用のロボット開発基盤を Google Cloud で構築。製造業で深刻化している労働力不足の解消にも取り組んでいます。なぜ SDV のために Google Cloud を採用し、いかに人材育成も充実させたのか。AIロボティクスセンターの開発者と責任者に話を伺いました。

利用しているサービス:
Gemini Enterprise, Gemini CLI, Cloud Workstations, BigQuery, Cloud Build, Cloud Run, Identity-Aware Proxy など

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

加速する SDV の流れに対応するために、Google Cloud でプラットフォームを構築

重機械メーカーである住友重機械工業は、減速機や放射線治療装置など、多岐にわたる製品を研究開発しています。その中で、物流・建設機械を扱うロジスティックス＆コンストラクションセグメントを担当しているのが、AIロボティクスセンターです。現在、同センターでは、自動フォークリフト（AGF：Automated Guided Forklift）の開発を推進。技術本部技術研究所 AIロボティクスセンターロボティクスプラットフォームグループの中尾拓真氏は、その背景を次のように説明します。

「製造業は、ハードウェアの性能で製品価値が決まる時代から、ソフトウェアのアップデートで機能が追加され、より便利になる SDV の時代への変革期にあります。自動車ではすでに、OTA と呼ばれるインターネット経由のアップデートで自動運転の性能や燃費が購入後にも向上するようになりました。この流れは物流・建設機械にも広がってきていますので、大型機械の中で動くソフトウェアの開発を、より高速化することが求められています。」

同センターでは、AGF の開発を通じて、SDV に対応したクラウドの開発環境を検証。得られた成果や知見をもとに、ソフトウェア開発を効率化し、油圧ショベルやクレーンなどの他の機種にも展開していく予定です。

「コーディングでは生成 AI を利用して、AGF の動作やアルゴリズムを短時間で実装します。こうして実装した機能は、まずシミュレーターで動作を確認してから実機実験に進みますが、実機実験は時間や場所、安全性の制約が大きいので、可能な限りシミュレーターで不具合を解決しておくことが大切になります。また、そこで得られたデータはクラウド上で分析され、不具合の原因特定や次の改善に活かされます。」（中尾氏）

デジタルツインを活用した事前検証を行い、実機実験を 1 回でクリア

住友重機械工業では基盤となるプラットフォームとして、Google Cloud を採用。決め手となったのは、開発に必要な機能はもちろん、内製化に向けた支援プログラムなどが包括的に提供されることでした。

Google Cloud 上の開発プラットフォームは、生成 AI 開発環境、CI/CD、デジタルツイン、データ分析の 4 つの役割を担っており、検証を終えた機能は Docker イメージで実機にデプロイされます。例えば AGF がパレットを検出してピックアップする自動化機能の開発では、Cloud Workstations 上のデジタルツインでシミュレーションを行った結果、1 回目の実機実験で動作テストを問題なくクリアできました。

「シミュレーターは実機とまったく同じプロトコルで通信できるので、ロボットのプログラムから見ると、接続している相手が実機なのか、シミュレーターなのかを意識する必要がなくなります。だからこそ、動作確認したプログラムが実機でもそのまま動くのです。」（中尾氏）

中尾氏によれば、Google Cloud の導入は個別の開発だけでなく、チーム全体の作業プロセスにも大きな変化をもたらしました。

「クラウドを導入する前は、開発環境や使用ツールが各自バラバラで、ソースコード管理も個々が行っていました。しかし Cloud Workstations で環境を標準化し、ソースコード管理や CI/CD も実現したことにより、シナジーを生むチーム開発へ移行できました。特に Cloud Workstations は、メンバー全員が同一環境で開発できるため、新規メンバーのオンボーディング短縮にもつながっています。新入社員として配属されたメンバーが、配属初日から作業に着手できた例もありました。」（中尾氏）

開発プラットフォームでは、コーディングやデバッグ、ドキュメント作成などの幅広い工程で、Gemini CLI や Gemini Enterprise などの生成 AI が活用されています。中尾氏は、その効果を高めるために独自の仕組みも構築してきました。

「生成 AI でエンジニアの発想をすぐにコード化し、CI/CD と組み合わせて定型作業も自動化したことで、エンジニアが創造的な作業に専念できるようになりました。ただし、AI コーディングエージェントは、同じエラーの解決方法を毎回 1 から探してしまいます。そこで、エラーログをキーにして AI が解決策を自動蓄積・検索する『KAI（Knowledge & AI）』を構築し、チーム全体へナレッジを展開できるようにしました。さらに、AI の学習データに含まれない社内の内製ライブラリの仕様を正しく理解させるため、ソースコードとドキュメントを関連付けて検索できる『GraphRAG』も実装しています。」（中尾氏）

Cloud Workstations と TAP で最適なクラウド人材の育成環境を整備

住友重機械工業は、Google Cloud 上のプラットフォームによって AGF の新機能実装を大幅に効率化しました。しかし意欲的な開発を継続していくには、クラウドに習熟した人材の確保が急務となります。ロボティクスプラットフォームグループでグループリーダを務める藤井北斗氏は、2025 年に入社した中尾氏を例に挙げながら、短期間で優れた人材を育成するうえでも Google Cloud の導入が有用だと語りました。

「SDV をけん引する人材育成には、早い段階で数多くの失敗と成功を体験させることが重要です。しかし弊社のように歴史が古く、規模の大きな組織では、自由にロボット開発を試せるクラウド環境を提供するのは、ガバナンスやセキュリティの観点から難しいのも事実です。この課題を Google Cloud で解決しようと考えました。」

まずガバナンス・セキュリティ面では、Google Workspace の Enterprise エディションを採用し、組織管理アカウントと IAM（権限管理）を連携させることで、少人数でも安全かつ適切なアカウント管理を実現。Security Command Center（SCC）も導入し、脅威の検知から修復までをカバーするセキュアで効率的な運用環境を確保しています。

「開発の経験を積むにはセキュリティガードレール、自由なプレイグラウンド（実験環境）と AI サポート、失敗しても元に戻せるサンドボックスの 3 要素が必要です。Cloud Workstations はコンテナなので壊れても元に戻せますし、IAP（Identity-Aware Proxy）で防護されているので安全も確保できます。生成 AI は Gemini Enterprise で誰が何に使っているかを把握できるようにし、ネットワークやセキュリティは Google Cloud Skills Boost で基礎的なことを学んでから、実装に取り組む体制にしています。中尾も、ガードレールの中で安全に失敗を繰り返すことで、バランスが取れた実装ができるようになりました。」（藤井氏）

一方、組織開発では、外部の知見を入れながら継続的に組織をスケールさせるための取り組みがなされています。そこで利用されたのが、Google Cloud が提供するアジャイル型内製化支援ワークショップ、TAP（Tech Acceleration Program）です。

「ロボット開発基盤のプロトタイピングでは、Google Cloud のエンジニアと 3 日間の合宿を実施していただきました。TAP では、プラットフォームエンジニアリング

やサイト信頼性エンジニアリング（SRE）だけでなく、Google のカルチャーや組織開発についても学ぶことができました。さらには生成 AI を使ったバイブコーディング研修を実施いただき、それを軸に社内教育も実施しています。」（藤井氏）

住友重機械工業は今後、SDV のサービス化に向けた企画やビジネスモデル構築、マイクロサービス開発、デジタルツイン環境の拡張へと取り組みを広げていく計画です。藤井氏は次の目標をすでに見据えていました。

「例えばデジタルツインは、開発やデバッグだけでなく、お客さまに新しいサービスを早く検証していただくための環境も提供します。この技術を基に、すべての住友製品とクラウドでつくったサービスが、仮想空間でつながる世界を実現したいと考えています。また、Gemini Robotics-ER 1.6 が公開されたので、フィジカル AI との統合も検討しています。OTA の仕組みを欧州の規制に適合させる、あるいは Firebase で顧客の操作状況を把握して UX を向上させるなど、弊社には他にも多くの目標があります。これらの実現に向け、今後も Google Cloud を活用した開発の効率化や、労働力不足などの課題を解決できる仕組みづくりに挑戦し続けていきます。」（藤井氏）

住友重機械工業株式会社
1888 年の創業から 130 年以上の歴史がある総合機械メーカー。「住友の事業は住友自身を利するとともに、国家を利し、社会を利する事業でなければならぬ」という住友グループの経営理念に基づき、メカトロニクス、インダストリアルマシナリー、ロジスティックス＆コンストラクション、エネルギー＆ライフラインの 4 つのセグメントを事業領域としてカバーする。連結従業員数は 2 万 5,123 名（2025 年 12 月 31 日現在）で売上高は 1 兆 669 億円（2025 年度）。

インタビュイー（写真左から）
技術本部技術研究所 AIロボティクスセンター
・ロボティクスプラットフォームグループグループリーダ・主任研究員　藤井北斗氏
・ロボティクスプラットフォームグループ　中尾拓真氏

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

JR東日本: Spanner と Cloud Run で「タッチトリガー」を実現し、改札データを起点に新たなコミュニケーションと価値を創出

Mon, 28 Sep 2026 02:00:00 +0000

利用しているサービス:
Spanner, Cloud Run, Cloud Logging, Cloud Tasks, Cloud Scheduler, BigQuery

東日本旅客鉄道株式会社（以下、JR東日本）が開発した「タッチトリガー」は、Suica の改札タッチをトリガー（起点）として、乗客のスマートフォンへタイムリーに情報を届ける新世代のコミュニケーションサービスです。この実現に向け、膨大なデータトラフィックを支えるインフラとして選ばれたのが、Google Cloud の Spanner と Cloud Run でした。開発の背景から、Google Cloud の製品が選ばれた理由、そして活用事例まで、マーケティング本部でプロジェクトを推進する 4 名に話を伺いました。

改札というリアルな接点から生まれる、生活に密着したデータ

日本最大の鉄道事業者として、乗客の移動を支える JR東日本。同社が発行する交通系 IC カード Suica は、2001 年のサービス開始以来、累計発行枚数が 1 億 2,000 万枚を超え、移動・決済のインフラとして、私たちの生活に欠かせないものとなっています。今、同社は Suica の利便性をより高め、活用範囲を広げる「Suica Renaissance」構想を進めています。その核となる技術のひとつが、乗客の改札通過データをもとに、さまざまな情報を提供する「タッチトリガー」です。マーケティング本部の戦略・プラットフォーム部門で副部門長を務める廣瀬道輝氏は、開発の背景にはコロナ禍があったと振り返ります。

「コロナ禍の最中、人々が通勤・通学や外出を控えざるをえなくなり、鉄道の利用者が大きく減るという事態に直面しました。『人の移動』という弊社事業の前提が揺らいだのです。その危機感のなかで、単に移動のインフラを提供するだけでなく、お客様の生活に寄り添い、一人ひとりに新しい価値を提案していく必要があると強く感じました。そこで生まれたのが『タッチトリガー』です。Suica に紐づく改札データを集約し、利用駅や時間帯、行動の文脈などに基づいて分析していけば、パーソナライズされた情報やサービスをお届けできます。私たちは改札タッチのタイミングをお客様とのコミュニケーションのきっかけにしたいと考えています。そのため『タッチトリガー』を、お客様の生活の利便性や快適さを上げていくための『コミュニケーション機能』として位置づけています。」

このような発想を根底で支えるのが、リアルなネットワークです。JR東日本の鉄道網は関東や東北、北陸に広がり、乗降客数は 1 日約 1,600 万人に上ります。ところが従来は、改札を通過した際に発生するデータはオンプレミスを軸にした社内システムで処理されており、巨大なポテンシャルをフルに活かしきれずにいました。この方法は、0.2 秒という超高速処理を実現するうえでは理にかなっていました。しかしマーケティングを担当するデジタルビジネスユニットの村上洋輔氏は、全社横断的なデータ活用が急務だったと振り返ります。

「改札ゲートはお客様の生活に密着したタッチポイントで、物理的な数の多さや、そこから得られるデータは、鉄道事業者ならではの強みだと考えています。また、あらゆる地域には駅を中心に商圏や生活圏が広がり、弊社のグループでもさまざまな部署が事業を展開していますので、データを横断的に活用すれば、大きなシナジーを生み出すことができます。そのためにも、運用基盤をクラウド化していくことが重要になっていました。折しも、Suica 全体をクラウド化していくという動きが全社的に進んでいましたので、『タッチトリガー』も、その流れと足並みをそろえることになりました。」

Spanner と Cloud Run で厳しいトラフィック処理の要件をクリア

ただし、データ処理のシステムをクラウドに移行するためには、厳しい技術要件がありました。まず 1 日のタッチ数は、山手線内の駅だけでも数百万回にのぼり、ラッシュ時には平常時の 10 倍にも跳ね上がります。無数の改札から送られてくるデータを、クラウド上のサーバーで処理するためには、トラフィックの急増に対応するスケーラビリティと、データを瞬時に記録する書き込み性能が鍵を握ります。これを満たすことができるのは、Google Cloud の製品だけだったといいます。

「ほぼすべてのクラウド型データベースで検証したところ、一般的な RDB（リレーショナルデータベース）では処理能力に上限があり、要件を満たせないことがわかりました。しかし Spanner だけは違いました。データを自動で振り分けながら、高い整合性を保つことができますし、Cloud Run と組み合わせることで、乗客の増減に応じてほぼタイムラグなくオートスケールできることもわかりました。テスト実装の段階で、想定どおりのスペックが出たことに開発チームは驚いていました。Spanner と Cloud Run がなければ、『タッチトリガー』を今の形で実現させることは難しかったでしょう。」（廣瀬氏）

実装の際には、いくつかの工夫もなされています。データ活用を行うには、年代や利用駅、購買履歴といった属性と、マーケティングの目標を瞬時に掛け合わせる作業が不可欠となります。ただし Spanner はデータの整合性を維持するために、独自のインデックス設計を採用しており、データ加工が必要となります。そこで技術的な支援を行ったのが、Google Cloud のサポートチームでした。

「本格的に Spanner を使うのは初めてでしたが、あまり試行錯誤することなく、最適解にたどり着くことができたと感じています。現場のエンジニアたちも、処理スピードやコスト最適化の方法や、Data Boost を活用した分析クエリに対するリソースの競合の回避方法など、多くのノウハウを吸収しました。Google Cloud と協働しながら改札システムのクラウド化を進めていけば、改札を抜けてホームに向かう間に、パーソナルな通知が届くような環境も構築していけると思います。」（廣瀬氏）

「タッチトリガー」が活性化させていく、毎日の暮らしと地域コミュニティ

「タッチトリガー」は 2024 年に山手線内の全駅に実装され、その後、JR東日本管内の新幹線停車駅や大井町などへ対象を広げています。最初に活用されたのは、同社が毎年開催している「山手線謎めぐり」というイベントでした。「タッチトリガー」のシステムやオペレーションを担当する、デジタルビジネスユニットの新名恵里佳氏は、盛り上がりを鮮明に覚えていました。

「これは沿線の街を散策しながら、謎解きをしていく体験型のイベントで、毎年多くの方にご参加いただいています。2024 年は Suica をタッチすると、駅に応じたコンテンツが配信される仕組みを採り入れました。参加した方からは『Suica でこんなことができるんだ！』という驚きの声があがっていました。その後、2025年には『みんなのトレインタウン』というスマホゲームでも、ミッションの達成条件に『改札タッチ』を組み込み、アイテムを獲得できるようにする施策なども行っています。」

また、JR東日本が推進する「まちづくり」との連携も進んでいます。同社は駅と接続する大型複合施設「TAKANAWA GATEWAY CITY」を 2025 年にオープン。その「まちびらき」に伴い、実証実験が行われました。同本部まちづくり部門品川ユニットチーフの小坂和広氏は、反響の大きさが想像以上だったと説明します。

「弊社のオフィスでは入館管理に Suica を使っており、この方法を他の用途に活用できないかという声は以前からありました。ちょうど全社的に『タッチトリガー』のプロジェクトが始まっていましたので、アプリと Suica を連携していただいたユーザーの方を対象に、改札を出ると施設内のお店でドリップコーヒーをプレゼントするクーポンを配信しました。アプリはローンチしたばかりでしたが、用意した 800 袋を 4 日間で配り終えるなど、想像以上の効果が得られました。提案する情報や通知のタイミングを含め、テストを重ねてより良い方法を探っていければと考えています。」

2026 年 3 月には大井町駅で、コンビニエンスストアの NewDays と連携し、おすすめ情報やクーポンを配信する施策が開始されています。一方、新幹線では、より踏み込んだ取り組みが行われてきました。村上氏によれば、2025 年には「GunMaaS」（群馬県内のさまざまな交通手段をシームレスに結びつけるスマートフォン向けサービス）と連携し、高崎駅で降りる乗客にタクシーを配車する試みが始まりました。「新幹線は『タッチトリガー』の展開という点で、非常にわかりやすいケースになっています。お客様が利用される便の時間や目的地、車内での滞在時間はあらかじめ把握できますので、乗車中はドラマや漫画などのコンテンツをご案内し、現地についたときには地元のタクシー会社がすでにお待ちしている。観光や宿泊情報のご提案なども、その方のニーズや志向に合わせて実施することができます。これを重ねていくことで、お客様と各事業者双方にとって Win-Win の関係を構築できます。」現在、同社は JRE ID の一本化に取り組んでおり、2028 年に Suica アプリ（仮称）が新たにリリースされれば、本格的な 1 to 1 コミュニケーションも可能になる見込みです。改札ゲートを起点に、データ活用の在り方が変わり、地域社会が変わり、毎日の生活が変わっていく。「タッチトリガー」と JR東日本の挑戦は、さらに加速していきます。

「『タッチトリガー』は、駅商圏を中心にサービスを展開する事業と特に相性が良いので、グループ外の企業とも実証実験を進めていく予定です。むろんお客様に安心してご利用いただけることが何よりも大切ですので、各種アプリと連携する際にはお客様の同意を得たうえで、情報を必要な範囲に限り、適切かつ安全に取り扱います。そのうえで『タッチトリガー』を軸にコミュニケーションを充実させ、すべての駅を、クオリティオブライフの充実や新たな事業展開、そして地域活性化を推進するハブにしていければと考えています。」（廣瀬氏）

東日本旅客鉄道株式会社（JR東日本）
1987 年に日本国有鉄道（国鉄）の分割民営化により設立。首都圏を中心に関東甲信越から東北までの東日本エリアの鉄道網を管轄し、営業キロは 7,418.7 km、輸送人員は 1 日あたり約 1,600 万人を誇る世界最大級の旅客鉄道会社。従来の交通事業に加え、Suica を核とするデジタルトランスフォーメーション、駅ビルや商業施設を中心としたまちづくりを推進。国際交流拠点「TAKANAWA GATEWAY CITY」、都市生活共創拠点「OIMACHI TRACKS」を中心とした「広域品川圏」の都市開発にも取り組む。

インタビュイー（写真右から）:
マーケティング本部
・戦略・プラットフォーム部門副部門長　廣瀬道輝氏
・戦略・プラットフォーム部門デジタルビジネスユニット　村上洋輔氏
・戦略・プラットフォーム部門デジタルビジネスユニット　新名恵里佳氏
・まちづくり部門品川ユニット TAKANAWA GATEWAY CITY（デジタルサービス戦略）チーフ　小坂和広氏

※文中の組織名・役職名は取材当時のものです。

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

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

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

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

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

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

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

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

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

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

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

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

BigQuery で TabFM を使ってみる

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

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

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

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

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

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

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

BigQuery の TabFM の仕組み

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

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

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

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

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

予測 ML が簡単に

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

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

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

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

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

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

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

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

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

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

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

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

ID 列を実装する方法

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

定義のオプション

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

BigQuery Graph の新機能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

グラフとチャットする

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

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

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

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

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

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

BigQuery Graph を今すぐ使ってみる

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

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

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

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

構造化データと非構造化データのインサイトを統合する 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 0x7f5e6a4b9c50>)])]>

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

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

セマンティック（ベクトル）検索は非常に強力です。たとえば、上記のクエリでは、「化学療法」のような概念的に関連する用語も適切に返すことができます。しかし、セマンティック検索だけでは十分でない場合もあります。たとえば、研究者が、非常に専門的な免疫療法薬の具体的な名称（「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 0x7f5e6a44b110>)])]>

これらのハイブリッドクエリを大規模に高速化するには、検索の語彙部分で使用するキーワード列を含めるように 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

列レベルのセキュリティを強化: 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 0x7f5e6a4b9690>)])]>

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

ステップ 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 0x7f5e6a433d50>)])]>

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

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

また、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 0x7f5e6a433e50>)])]>

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

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

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

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

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

ステップ 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 0x7f5e6a430f90>)])]>

「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 0x7f5e6a431450>)])]>

「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 0x7f5e6a432210>)])]>

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

使ってみる

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

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

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

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

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

ガバナンスパイプライン（監査ログ）: 管理アクション（管理アクティビティ）とデータプレーンのオペレーション（グラウンディングデータコネクタのルックアップなどのデータアクセス）をキャプチャします。
包含フィルタ（[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 0x7f5e6a4cf790>)])]>

管理アクティビティログ: デフォルトで常に有効になっています。リソースの変更（カスタムエージェントの作成、更新、削除など）を追跡します。
データアクセスログ: デフォルトではオフになっています。チャット中に発生するユーザーレベルでのデータの読み取り / 書き込み操作をログに記録するには、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 テクニカルリード

Android、Google Cloud、Nexus SDV が実現する AI 定義車両

Wed, 29 Jul 2026 01:00:00 +0000

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

ハードウェア中心のプラットフォームを構築してきた自動車業界は、独自の高度なソフトウェア定義車両（SDV）アーキテクチャの構築へと移行しています。OEM にとって、車両はもはや単なる移動手段ではなく、AI ネイティブなエコシステム内でインテリジェントな接続ノードとして機能する存在です。

Google の Android と Google Cloud は、複数のパートナーと連携し、この移行の最前線に立っています。Android のオープンソース Automotive OS（AAOS）SDV が AI 定義車両を実装し、Google Cloud が包括的な AI 統合ツールを含むスケーラブルなインフラストラクチャを提供します。その際、自動車および製造テレマティクスを大規模に実現する Bigtable などのサービスが活用されています。Google Cloud パートナーである Valtech は、Nexus SDV プラットフォームの一部で Google のテクノロジーを使用し、真のエージェントモビリティを実現するエンドツーエンドの総合的なコネクテッドカーシステムを確立しています。これにより、自動車 OEM は、次世代のコネクテッドカー向けにすぐに使用可能なエンドツーエンドの基盤を手に入れることができます。これらすべてがどのように連携して機能するか、以降でご紹介します。

車両側: AAOS SDV

車載プラットフォームの基盤となる Google のオープンソースの AAOS SDV プラットフォームが、物理ハードウェアに依存しない再利用可能なサービスにコア機能を抽象化し、モジュール式のサービス指向アーキテクチャ（SOA）を確立します。AAOS SDV プラットフォームでは、空調、照明、診断などの安全に関係のない領域を電子制御ユニット（ECU）から分離することで、動的なランタイムサービスディスカバリを導入しています。これにより、SDV は実行中のサービス（走行距離計、HVAC、サンルーフ、電動シート、電動ウィンドウなど）とそのステータスを簡単に検出できます。

開発を加速するために、エンジニアリングチームは Android Cuttlefish エミュレータを活用してクラウドにデジタルツインを構築し、高頻度のセンサーストリームをシミュレートして、物理的なシリコンの準備ができる前にこれらの分離されたサービスをビット単位で検証しています。Valtech Nexus SDV は、この AAOS SDV ミドルウェアレイヤを利用して車両リソースを検出、マッピング、管理し、高頻度のテレメトリーデータを構造化して Bigtable に直接ストリーミングします。これに対し、以前は OEM がシステムソフトウェアをさまざまなサプライヤーにアウトソーシングし、各サプライヤーが独自のパイプライン、プロトコル、データを個別のサイロに保存していました。

重要なのは、このモデルがサービスをメインの重いインフォテインメントスタックから切り離すため、車両の電源がオフの状態で駐車中の場合でも、サービスを独立して実行できる点です。これにより、メインのインフォテインメントシステムの電源が切れていても、車両の遠隔モニタリングなどの機能が有効なままになり、テレメトリーに継続的にアクセスできます。車両の 12 V バッテリーやメインの EV バッテリーパックを消耗させることはありません。

AAOS SDV プラットフォームと Nexus SDV の緊密な統合により、エージェント型 AI と革新的なファーストパーティソリューションが数多く実現しています。従来のサンドボックス化されたインフォテインメントツールとは異なり、マルチモーダル AI エージェントはサービスディスカバリレイヤを利用して物理的な自動車と安全にやり取りし、複雑な意図ベースのリクエストを処理できます。たとえば、運転者との会話に応じて、または気候センサーに反応して、AI エージェントが気候ゾーン、ウィンドウアクチュエータ、室内照明を自動的に調整できます。以下のクリップをご覧ください。

Nexus SDV で管理されるこの車載サービスレイヤを、Bigtable に保存された過去のフリートテレメトリーとリンクすることで、高度に統合されたエクスペリエンスを提供し、新たなモビリティソリューションを実現できます。次に、クラウド側を簡単に見てみましょう。

Google Cloud 側: AI ネイティブなモビリティ

現在、SDV を超えて、AI が車両の運用ロジックの中核となる AI 定義車両（AIDV）へと急速に移行しています。AI ネイティブとは、あらゆるアーキテクチャレベルに AI を組み込み、設計段階から自律性を考慮している、という意味です。このレベルの AI では、システムが環境を認識し、Google Gemini などのエンジンを使用して複雑なシナリオを推論し、アクションをプロアクティブに実行できます。たとえば、Gemini を搭載した車両は、バッテリー残量が少ないと警告するだけではありません。ユーザーのスケジュール、交通状況、充電スポットの空き状況を分析して、あらかじめバッテリーの状態を整えて最大限に効率化できるよう、最適な充電スケジュールを提案します。AIDV の特徴は、このレベルでコンテキストを理解し、プロアクティブに自動化できるという点です。

これを、車両全体のさまざまなシステムから送られてくる大量の多様なデータを取り込めるようには設計されていない、従来のアーキテクチャと比較してみてください。この場合、メンテナンスと安全に関する情報テレマティクスが分離されたデータサイロが生じる可能性があります。さらに、このデータは断片化されているため、システム全体でデータからまとまった価値を得ることが非常に困難です。AI ネイティブなアプローチは、こうしたサイロを解消し、コンテキストを統合的に理解するうえで役立ちます。これにより、OEM の主な課題が解消されます。つまり、SDV テレマティクスなどの複数のソースから得た高帯域幅テレメトリーの管理の複雑さが大幅に軽減されるのです。

Bigtable: 自動車テレメトリーのデータバックボーン

Bigtable は、大量の取り込みレートとミリ秒未満のレイテンシ要件への対応に特化したソリューションであり、ペタバイト規模の自動車および製造テレメトリーデータセットのデータバックボーンとして機能します。実際、Bigtable を活用したビジネスクリティカルな自動車テレメトリーソリューションがすでに存在します。その柔軟なスパースロースキーマにより、OEM はダウンタイムなしでデータモデルを進化させ、高頻度のエンジン指標から LiDAR ポイントクラウドまで、多様なセンサーアレイを単一の統合テーブル構造内に収容できます。また、大量の書き込みと複雑な多次元分析ルックアップの両方を対象にネイティブに最適化された方法で時系列イベントをバージョン管理することで、Bigtable が従来のシステムにありがちなデータ過負荷の回避を支援します。

一方、継続的マテリアライズドビュー（CMV）などの機能を使用すると、ストレージレイヤ内で直接、平均バッテリー温度やフリート全体のトルク分布などの主要な指標を事前に計算できるため、コンピューティングのオーバーヘッドを最小限に抑えることができます。Bigtable と Agent Development Kit（ADK）の統合により、AI エージェントがデータにアクセスできるようになり、データとアクションのギャップがさらに解消されます。このキットと、Apache Spark などのフレームワークとの Bigtable の統合を組み合わせることで、大量に流れてくるライブテレメトリーデータをモニタリングし、自動ワークフローをリアルタイムでトリガーできます。たとえば、特定の劣化パターンが検出された瞬間に、ミッションクリティカルなアラートのロギング、プロアクティブな無線（OTA）ソフトウェア調整の開始、交換部品の事前注文などを実行できます。

すべてを統合した Nexus-SDV プラットフォーム

Google Cloud 上に構築された Nexus SDV プラットフォームは、AAOS SDV と統合してコネクテッドカーの未来を支えます。Nexus は、標準化されたデータ基盤を提供することで、自動車 OEM がインフラストラクチャをゼロから構築する手間を省き、独自のブランドエクスペリエンスに注力できるようにします。

Nexus SDV は、Gemini Enterprise Agent Platform、Bigtable、BigQuery などの Google コンポーネントを使用します。Nexus SDV のセットアップは、迅速、自動、透過的です。OEM は、車両内だけでなく、UI 画面、モバイルアプリ、サービスセンターなどの他の顧客タッチポイントでも、ブランド固有の顧客体験を創出できます。車両への接続には、オープンソースの Synadia NATS インターフェースが利用されます。車両との統合は、クラウドと車両のシンプルな SDK を介して行われるため、両側でサービスディスカバリが容易になります。Nexus SDV は AAOS SDV 向けに最適化されていますが、あらゆる車両フレームワークと統合できます。

セキュリティは「多層防御」モデルを通じて Nexus アーキテクチャに組み込まれています。相互 TLS（mTLS）と Google Cloud Certificate Authority Service（CAS）により、暗号化された安全な ID が車両に提供されます。ネットワーク分離はプライベート GKE クラスタによって維持される一方、Secure AI Framework（SAIF）は ML ライフサイクル全体でデータプライバシーを確保し、機密性の高いユーザーデータと OEM の知的財産を保護します。

迅速なセットアップと統合、標準化されたデータ基盤、組み込みの最先端セキュリティが組み合わさることで、自動車メーカーは測定可能なビジネス上の効果を即座に得られます。

まとめとして、具体的なユースケースについて詳しく取り上げます。

予測メンテナンス

事後対応型のメンテナンスから予測メンテナンスに移行することで、OEM は保証費用を削減し、顧客ロイヤルティを向上させ、車両の稼働時間を長くすることができます。

課題: 多くの場合、従来の定期メンテナンスは非効率的で、不要なサービス訪問や予期せぬ車両の故障につながり、OEM と所有者の両方に多大な費用を発生させます。Nexus SDV、Bigtable、ADK は、AI を活用したプロアクティブなアプローチに移行することで、このエクスペリエンスを変革します。このプロセスではまず、大量に流れてくる車両のテレメトリーデータ（エンジンの回転数、振動、液面、ブレーキ圧など）をモニタリングして取り込み、Bigtable に直接保存します。

リアルタイムの異常検出を可能にするために、エージェント型 AI はテレメトリーストリームが到着すると同時にデータをモニタリングします。Bigtable CMV は、エンジンの平均振動やバッテリー温度プロファイルの急激な変動などのローリング集計を事前に計算します。これらのライブ集計を消費する AI モデルは、通常のパラメータからの微妙な逸脱を検出できるため、ダッシュボードに警告灯が表示されるかなり前に、エンジンの摩耗やバッテリーの急速な劣化の兆候を特定できます。

専門 AI モデルによって異常が検出されると、システムはエージェントによる推論とアクションのフェーズに移行します。Gemini を搭載したエンジンが、走行距離、モデル、メーカー、サービス履歴、今後の移動予定などの要素を考慮して、データの重大度とコンテキストを評価します。このインテリジェントな評価に基づいて、システムは AAOS インフォテインメントシステムを介して運転者にプロアクティブに通知し、近くのディーラーでの最適なサービス予約を提案します。また、到着時にすべてが準備できているように、部品の自動注文をトリガーすることもできます。AI モデルは、偽陰性が発生しないよう対処し、顧客感情の悪化や信頼の低下を防ぎます。また、ソリューション全体としては、車両の稼働時間を向上させ、メンテナンスを事後対応型の負担の大きい作業から、ブランドを定義するサービスエクスペリエンスへと変容させます。

ご利用にあたって

AAOS SDV と統合した AI ネイティブの Nexus SDV プラットフォームはこちらからご利用いただけます。極めて規模が大きく、分析が厳格な最新のモビリティに対応するように設計された、エンドツーエンドの高度なコネクテッドカーエコシステムを実現します。この統合オープンソースアーキテクチャを採用することで、OEM は従来のインフラストラクチャの制限を乗り越え、ブランドを定義する影響力の大きい機能の開発にリソースを再配分できます。

Nexus SDV は、コネクテッドカーサービスをエージェントの時代へと導きます。車両はもはや接続されているだけでなく、運転時のインテリジェントかつプロアクティブなパートナーの役割を果たすようになっています。ぜひ、今すぐお試しください。

詳細

Nexus SDV プラットフォーム、AAOS SDV、Bigtable の詳細については、nexus-sdv@google.com までお問い合わせください。

AAOS SDV は、Android Automotive 26Q2 リリースでご利用いただけます。Nexus SDV のドキュメントはこちらでご覧いただけます。

自動車テレメトリーの時系列データベースとしての Bigtable について詳しくは、こちらをご覧ください。

コネクテッドカーのセキュリティについて検討されている場合は、エージェントでギアを上げる: ソフトウェア定義車両のセキュリティを確保をご覧ください。

- Valtech Mobility、マネージングディレクター、Peter Ivanov 氏

- Google、Android Automotive、グループプロダクトマネージャー、Matt Crowley

BigQuery Graph を使用して不正防止のためにネットワーク分析をスケーリング

Wed, 22 Jul 2026 00:00:00 +0000

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

英国に拠点を置く Curve は、財務スーパーアプリを構築しています。これは、すべてのデビットカードとクレジットカードを 1 つのアプリとカードに統合するスマートウォレットで、数百万人のユーザーの支出、送金、貯蓄の方法を簡素化します。

しかし、この規模で事業を行うということは、件数が多く常に進化する金融犯罪の現状に直面することを意味します。従来の不正行為検出モデルは、疑わしい個々の取引にフラグを立てるのに優れていますが、組織化された不正行為グループの特徴である複雑なネットワークや隠れた関係性といった「全体像」を見逃すことがよくあります。

こうしたつながりを明らかにするには、従来のリレーショナルデータモデリングから脱却する必要があると考えました。Google Cloud と提携して BigQuery Graph を実装したことで、大規模に詳細なネットワーク分析を実施できるようになり、隠れた不正ネットワークを特定して、取引コストを大幅に削減できました。

課題: マルチホップの問題

不正行為者は、単独ではほとんど行動しません。多くの場合、複数のアカウントで、共通のデバイス、特定の資金調達カード、共有の連絡先情報など、共通の特性があります。標準的なリレーショナルデータベースでは、これらの関連性を特定するのに複雑な「マルチホップ」分析が必要です。

標準 SQL を使用してこれをスケールしようとしたところ、2 つの大きなハードルがありました。

計算の複雑さ: つながりのチェーン（ユーザー A がユーザー B とつながり、ユーザー B がユーザー C とつながるなど）を明らかにするには、複数の大規模な自己結合が必要です。数百万人のユーザーと数千万のつながりという規模では、これらのクエリはすぐに計算コストが高くなり、維持が困難になりました。
データの規模: 当社の最も粒度の高いシグナルには、数十億もの潜在的なつながりが含まれています。標準的なリレーショナルアプローチでは、パフォーマンスのボトルネックに達したり、システムリソースを使い果たしたりすることなく、これらの関係を処理することは困難です。

ソリューション: データプラットフォームでのネイティブグラフ分析

ネットワーク分析を BigQuery Graph に移行し、ネイティブの Graph Query Language（GQL）サポートを活用しました。主な利点は、データを移動することをやめて、既存の環境内で直接接続できるようになったことです。以前は他の一般的なグラフデータベースを検討していましたが、BigQuery の既存のデータウェアハウス内にデータを保持できるため、新しいグラフデータベースに移行しなければならない場合と比べて、時間と費用を大幅に節約できました。

プロパティグラフ（ユーザーはノード、共有識別子はエッジ）として支払いエコシステムをモデル化することで、アーキテクチャを大幅に簡素化しました。複雑な JOIN ロジックを何十行も記述する代わりに、直感的な GQL 構文を使用して、データセット全体で不審な動作のパターンを「マッチ」できるようになりました。このアプローチにより、次のことが可能になりました。

数十億のつながりを走査: ユーザーレベル、デバイスレベル、カードレベルのつながりなど、膨大なデータセットを高いパフォーマンスで分析できるようになりました。
データエクスペリエンスを統合: BigQuery Graph はデータプラットフォームに組み込まれているため、1 つのクエリでグラフ走査を標準 SQL 分析、検索、ML ワークフローと組み合わせることができます。そのため、既存の SQL パイプラインを活用してノードテーブルとエッジテーブルを構築し、グラフの走査では GQL に切り替え、標準 SQL で最終的な集計を行うことができました。この柔軟性により、より多くのアナリストが、新しい言語のスキルアップをしなくても、この機能を利用できるようになります。

影響と結果

BigQuery Graph を不正行為防止戦略に統合して以来、運用効率と収益に大きな影響がありました。

財務上の影響: Curve では、グラフベースの分析情報によってトリガーされた自動ブロックにより、2025 年だけで約 1,200 万ドルの取引損失が回避されたと推定しています。
適合率と精度: グラフを活用したクエリにより、不正なユーザーを特定する精度は約 72% に達しました。この高い精度により、不正行為防止の担当者は、偽陽性を追跡するのではなく、確実性の高いケースに手動レビューを集中させることができます。
運用のスピード: GQL に移行したことで、グラフクエリを合理化し、不正行為のルールをより頻繁に更新できるようになりました。以前は、1 時間ごとのルールで 1 ホップのクエリに制限されていましたが、GQL を使用することで、実行速度の遅いスクリプトを最適化し、組織犯罪の一歩先を行くことができるようになりました。
ルールから ML へ: ネットワークの走査にかかる時間が短くなるほど、グラフベースの機能を ML モデルに提供するのに要する時間も短縮されます。グラフを再構築して走査する頻度は、モデルのトレーニングでは 1 日 1 回で十分ですが、トランザクションが 1 秒未満で承認されるような推論時には対応できません。GQL を使用することで、マイクロバッチまたはストリーミングの走査に移行し、不正行為モニタリングモデルに最新のデータを提供できるようになりました。

今後の展望

BigQuery Graph の導入による成功で、データサイエンスチームとセキュリティチームに新たな可能性が広がりました。現在、数十億件の IP アドレス接続を含む、これまでで最も大量のシグナルをリアルタイムの検出ループに完全に組み込む作業を進めています。また、アナリストがより直感的に、不正行為のネットワークを形成時に探索して「確認」できるよう、ネイティブのグラフ可視化も検討しています。

Curve は、データを単なるテーブルの行としてではなく、生きた関係ネットワークとして扱うことで、セキュリティがカスタマーエクスペリエンスと同じくらい効率的で堅牢なものになるようにしています。

- Curve OS、データサイエンティスト、Remy Pereira 氏

- Google、データカスタマーエンジニア、Ewan Zhang

BigQuery の AI.AGG 関数で全体像を把握し、傾向を分析する

Tue, 07 Jul 2026 02:00:00 +0000

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

Google は先日、BigQuery の AI.AGG() 関数のプレビュー版を発表しました。AI.AGG() を使用すると、1 行の SQL 内で自然言語による指示を与えるだけで、数百万行に及ぶ非構造化データやマルチモーダルデータに関する情報を要約、合成できます。

1 行の SQL で数百万行を要約: AI.AGG

BigQuery には、データの個々の行を分析するのに役立つ強力な AI 関数がすでに用意されていますが、非構造化データを大規模に分析するには、別のアプローチが必要となります。 AI.AGG() を使用すると、ログやドキュメントなどの非構造化データに対して、以下のような質問をすることができます。

製品に対する否定的なレビューの中で、要望が多かった機能の上位 3 つはどれですか？
ユーザーが最も頻繁に遭遇しているエラーの種類は何ですか？また、何から調査を始めるべきですか？
当社の自動エージェントが顧客の問題解決に一貫して失敗しているのは、どのようなシナリオですか？

この投稿では、AI.AGG() 関数について詳しく説明するほか、この関数によって実現できるユースケースをいくつかご紹介します。また、複雑かつインテリジェントなデータ分析を行うために、BigQuery の他のマネージド AI 関数と組み合わせて使用する方法についてもご説明します。

AI.AGG() を使用したシステムログの分析

AI.AGG() の威力を示す好例が、システムロギングの分析です。ログメッセージ、警告、エラー、スタックトレースには、サービスを改善するうえで非常に役立つ情報が含まれている可能性がありますが、手動で調査するには時間と労力がかかります。特に、大規模な運用を行っており、確認すべきログが数千件もある場合はなおさらです。

AI.AGG() を使用すると、多数のログを一度に簡単に分析できるため、グループ化や優先順位付けを行って、どのログを最初に詳しく調査すべきかを判断できます。実際、BigQuery エンジニアリングチームは AI.AGG() を開発する際にこのアプローチを採用しており、この機能自体の入力処理に関連するエッジケースを特定するためにこの関数を利用していました。

このことを実証するために、Loghub から入手できる Apache Spark 標準の INFO ログの公開データセットを分析してみましょう。クラスタでは、FATAL エラーがスローされることなく、メモリスラッシング、クロックドリフト、ブロードキャストボトルネックといった問題に直面することがよくあります。AI.AGG() を使用すると、こうした一見正常に見えるログから隠れた非効率性を分析できます。サンプルデータファイルは、UI、CLI、クライアントライブラリなど、対応している任意の方法を使用して BigQuery に読み込むことができます。以下の例では、bq_logs_demo というデータセットと spark_logs_unstructured というテーブルにログファイルを読み込んだことを前提としています。

ここでは、プロンプトをどのように作成しているかに注目してください。モデルに対して「すべて正常」と回答することを明示的に許可することで、エラーのハルシネーションを防ぎながら、特定の異常を検出するように指示しています。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n Component AS spark_component,\r\n COUNT(*) AS log_count,\r\n AI.AGG(\r\n Content,\r\n 'これらの Spark システム INFO ログを分析してください。2 文で簡潔にまとめてください。まず、このコンポーネントの通常の動作を説明してください。次に、隠れた非効率性、レイテンシの急増、再試行の繰り返し、異常なパターンを明示的に特定してください。'\r\n ) AS performance_analysis\r\nFROM\r\n `bq_logs_demo.spark_logs_structured`\r\nGROUP BY\r\n Component\r\nORDER BY\r\n log_count DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6b99c410>)])]>

これらの結果から、AI.AGG() が「正常に動作している」というメッセージを適切に認識しつつ、重要な診断情報を抽出していることがわかります。

クエリ結果のペイン: ログデータセットに対する AI.AGG() が生成した分析情報を表示

非構造化テキストや画像データからのカテゴリ抽出

次に、BigQuery の一般公開データセットの一つである、cymbal_pets（架空のペット用品店）を使用して、AI.AGG() の柔軟性がわかるユースケースをいくつか見ていきましょう。このデータセットには、店舗が取り扱う商品のカタログが用意されています。商品の名前、説明、画像といった非構造化データが含まれているため、非構造化データを処理する AI 関数の威力を示す好例です。

たとえば、データセット内の商品を分類するとします。この場合の最初の課題は、商品にラベルを付けることではなく、商品カタログ全体にどのようなカテゴリが存在するかを把握することです。AI.AGG() を使用すると、元の商品名や説明を分析するようにモデルに指示でき、カテゴリを包括的に特定できます。

code_block: <ListValue: [StructValue([('code', "-- 商品名と説明から商品のカテゴリを特定する\r\nSELECT\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n 'これらの商品の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6b99f6d0>)])]>

このクエリは、カテゴリについてシンプルな平文のリストを返します。

商品データセットに対して AI.AGG() によって特定されたカテゴリの平文の結果。

この最初のクエリは探索には最適ですが、信頼性の高い自動化されたデータパイプラインを構築するには、シンプルな平文の文字列では不十分です。実際にデータをタグ付けするには、AI.AGG() に JSON 配列などの構造化された形式を返すように指示する必要があります。その後、構造化されたカテゴリを別の AI 関数である AI.CLASSIFY() のパラメータとして使用することで、各商品にカテゴリのラベルを実際に付与できます。

以下の SQL ステートメントは、これらの各ステップを 1 つのスクリプトで完了します。

code_block: <ListValue: [StructValue([('code', "-- 1. カテゴリの配列を保持する変数を宣言する\r\nDECLARE generated_labels ARRAY<STRING>;\r\n\u200b\r\n-- 2. 結果を保存するデータセットを作成する\r\nCREATE SCHEMA IF NOT EXISTS categorized_cymbal_pets;\r\n\u200b\r\n-- 3. AI.AGG で JSON 文字列を生成し、変数に抽出する\r\nSET generated_labels = (\r\n SELECT\r\n JSON_VALUE_ARRAY(\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n '主な商品カテゴリを特定してください。文字列の有効な JSON 配列を 1 つだけ返してください。マークダウンのコードブロック、バッククォート、会話テキストは含めないでください。'\r\n )\r\n )\r\n FROM `bigquery-public-data.cymbal_pets.products`\r\n);\r\n\u200b\r\n-- 4. 変数を AI.CLASSIFY に直接フィードする\r\nCREATE OR REPLACE TABLE `categorized_cymbal_pets.categorized_products` AS (\r\nSELECT\r\n product_name,\r\n description,\r\n AI.CLASSIFY(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n generated_labels\r\n ) AS assigned_category\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a4e3d50>)])]>

結果のテーブルが表示されます。このテーブルには assigned_category が含まれています。

AI.AGG() と AI.CLASSIFY() で作成された新しい assigned_category 列を含む categorized_products テーブルのプレビュー。

中間テーブルをよく見ると、構造化されたカテゴリが最初の平文の結果からわずかに変更されていることがわかります。これには 2 つの理由があります。1 つは、LLM が非決定論的であるということです。そのため、同じプロンプトに対してまったく同じ回答を常に返すとは限りません。もう 1 つは、新しい出力構造に対応するようにプロンプトが調整されたことです。

返された商品カテゴリは、プロンプトの一部として要求されたとおり、AI.AGG() によって JSON として構造化されている。

テーブルにカテゴリのラベルが付けられたので、カテゴリごとにグループ化して従来の SQL 集計を行うことも、AI.AGG() を使用して各カテゴリを個別に扱うこともできます。

たとえば、以下のクエリでは、従来の指標（行数など）に加え、グループ化された特定の商品に共通する点について AI が生成した要約も併せて取得します。

code_block: <ListValue: [StructValue([('code', "-- 新しく割り当てられたカテゴリごとに分析情報を統合する\r\nSELECT\r\n assigned_category,\r\n COUNT(*) AS item_count,\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n 'このカテゴリの商品の共通する特徴や目的を簡潔に説明する要約を 1 文で作成してください。'\r\n ) AS category_summary\r\nFROM\r\n `categorized_cymbal_pets.categorized_products`\r\nGROUP BY\r\n assigned_category\r\nORDER BY\r\n item_count DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e6a4e2d10>)])]>

クエリ結果: AI.AGG() による分析と従来の SQL 手法による分析を併せて表示。

非構造化データはテキストに限定されません。AI.AGG() はマルチモーダル入力にネイティブに対応しているため、画像ファイルから、直接集約された分析情報を返すことができます。

cymbal_pets Google Cloud プロジェクトには、商品写真が豊富に含まれた Cloud Storage バケットも用意されています。外部オブジェクトテーブルを作成することで、画像 URI を AI.AGG() に直接安全に渡して、コレクション全体の視覚的コンテンツを要約するようにモデルに指示できます。

code_block: <ListValue: [StructValue([('code', "-- オブジェクトテーブル内の画像コンテンツを要約する\r\nSELECT\r\n AI.AGG(\r\n STRUCT(OBJ.GET_ACCESS_URL(ref, 'r')),\r\n 'これらの画像の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.product_images`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e69edbe50>)])]>

クエリ結果: Google Cloud Storage にある商品画像を分析して、AI.AGG() が商品カテゴリを抽出。

AI.AGG() の仕組みとベストプラクティス

AI.AGG() をご自身の環境で効果的に使用するには、その内部でのデータ処理の仕組みを理解することが役に立ちます。ここでは、コンテキストウィンドウ、エラー処理、パイプラインの最適化について知っておくべきことを紹介します。

1. コンテキストウィンドウとマルチレベル集計LLM には特定のコンテキストウィンドウがあり、大量の入力を処理することが難しい場合があります。AI.AGG() は、入力行を自動的にバッチに分割し、それらのバッチを集計した後、その集計結果を最終的な回答としてまとめることで、この問題を解決します。つまり、大量の行を渡す際に、コンテキストウィンドウを手動で管理する必要はありません。なお、AI.AGG() は、データの行を複数のバッチに分割することはありません。そのため、行がスキップされないように、各行がコンテキストウィンドウよりも小さくなるようにしてください。行数が多く、かつ各行が小さいほど、AI.AGG() は各行のバッチ処理においてより柔軟に対応できます。

2. マルチレベル集計におけるトークン使用量 AI.AGG() はマルチレベルの集計構造を使用するため、モデルに送信される入力トークンの合計数は、開始テーブルの元のトークン数よりも多くなる場合があります（必要な集計のラウンド数によって異なります）。ベストプラクティスとして、LIMIT を使用するか、データを AI.AGG() に渡す前に上流で事前フィルタリングすることで、トークン数を常に減らすようにしてください。

3. モデルエンドポイントの指定モデルエンドポイントを指定しない場合、AI.AGG() はデフォルトで最新のモデルを使用します。ただし、本番環境のパイプラインでは、多くの場合、明示的な制御が必要となります。

短縮形の名称: 短縮形のエンドポイント（例: gemini-2.5-flash）を使用できます。その場合、AI.AGG() はクエリ実行リージョンでそのモデルを使用します。

code_block: <ListValue: [StructValue([('code', "AI.AGG(\r\n input_data,\r\n instructions => '指示をここに入力します。',\r\n endpoint => 'gemini-2.5-flash'\r\n)"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e69ed9d90>)])]>

完全修飾名: 希望するモデルがクエリ実行リージョンで対応していない場合、またはグローバルエンドポイントやマルチリージョンエンドポイントを使用する場合は、モデルを完全修飾名で指定します。

code_block: <ListValue: [StructValue([('code', "AI.AGG(\r\n input_data,\r\n instructions => '指示をここに入力します。',\r\n endpoint => 'https://aiplatform.googleapis.com/v1/projects/[YOUR_PROJECT]/locations/global/publishers/google/models/gemini-3.5-flash'\r\n)"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e69edae90>)])]>

4. 入力と出力のモダリティ

入力: AI.AGG() では、テキスト（文字列またはテキストファイルへの参照）と画像データに対応しています。これらの型の配列にも対応していますが、既知の問題に関するドキュメントをご参照のうえ、画像の配列に関するエッジケースの注意事項をご確認ください。
出力: この関数は常に文字列を返します。モデルに対して、JSON や Markdown の形式で出力するようにプロンプトで指示することは可能ですが、このことがデータベースエンジンで厳密に適用されるわけではないことにご注意ください。マルチモーダル出力（画像の生成など）は、現在対応していません。

5. NULLの処理AI.AGG() は、NULL の入力行を処理せずに自動的にスキップします。ただし、構造化データを渡す場合は注意が必要です。他の BigQuery AI 関数のように、AI.AGG() は標準の CONCAT() 関数と同様に STRUCT フィールドを連結します。つまり、STRUCT 内のフィールドが 1 つでも NULL である場合、その行全体が NULL として扱われ、スキップされます。

最初のカテゴリのクエリをもう一度見てみましょう。たとえば、products テーブルのいくつかの行で description が欠落している場合、NULL の連結ルールにより、これらの行は何の警告もなく分析から完全に除外されてしまいます。以下に、IFNULL() を使用してフォールバック文字列を指定し、説明が空白であってもすべての商品が確実に考慮されるようにする方法を紹介します。

code_block: <ListValue: [StructValue([('code', "-- 商品名と説明（オプション）から商品のカテゴリを特定する\r\nSELECT\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', IFNULL(description, '説明なし')),\r\n 'これらの商品の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5e69edbc50>)])]>

6. エラー処理 AI.AGG() は、無効な入力を受け取った場合や LLM 処理中にエラーが発生した場合に、部分的な結果を提供しようとします。無効な入力を含む行や、LLM モデルによって拒否された行は、最終結果には反映されません。

AI.IF() などのスカラーマネージド AI 関数と同様に、BigQuery ジョブの統計情報を確認することで、処理に失敗した行数を正確に把握できます。

生成 AI 関数エラーの詳細情報の例。

お試しください

上記は、非構造化データの分析に役立つ AI.AGG() の機能のほんの一例です。現在、AI.AGG() 関数は、すべての BigQuery ユーザー向けにプレビュー版として提供しています。ぜひ、ご自身のユースケースでお試しください。

また、BigQuery の他のマネージド AI 関数（AI.CLASSIFY()、AI.IF()、AI.SCORE()）や、AI.GENERATE() などの汎用関数もぜひお試しください。皆様がこれらの関数を活用してどのような成果を達成されるのか、今後を楽しみにしています。

- ソフトウェアエンジニア、Thomas Anchor

- デベロッパーアドボケイト、Alicia Williams

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: Yahoo の事例

Wed, 24 Jun 2026 01:00:00 +0000

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

エージェント型 AI を導入する企業にとって必要なのは、事後対応型のインテリジェンスシステムから、プロアクティブなアクションシステムへの転換です。これは、必要とされるコンテキストとパフォーマンスを備えたエージェントを構築するとともに、すべての意思決定について説明と監査が可能な、規制当局の要求に対応できるレベルの説明責任を担保するためです。

Google Cloud Next ‘26 では、Agentic Data Cloud でアクションシステムを実現する方法について解説しましたが、まさにこのビジョンの好例となるのが Yahoo のデジタルメディア購入プラットフォームです。Yahoo は Google Cloud と提携し、Google データクラウドのグラフ技術を活用して、Seller Agent デジタルメディア購入プラットフォームを構築しました。Seller Agent は、数週間かかる手動プロセスをわずか数秒に凝縮して、完全に管理されたライブキャンペーンを実行できます。自律システムが厳格な説明責任を維持しながら驚異的なスピードで動作できることを証明するこのシステムは、さまざまな業界で活用できる強力なブループリントとなります。

「Yahoo! の使命は、デジタルの世界を案内する、信頼されるガイドになることです。Google Cloud とのパートナーシップを通して迅速性、透明性、効果、信頼性を確保したエージェント型メディア購入を実現することで、私たちは広告主様に対してもこの約束を果たしていきます。」- Yahoo、収益化責任者、Gabriel DeWitt 氏

このブログでは、エージェント型 AI への移行について詳しく説明し、Yahoo の Seller Agent アーキテクチャがメディア購入におけるスピードと信頼性の課題をいかに解決しているかを検証します。また、このグラフベースのパターンを応用して、皆様の組織で信頼できるアクションシステムを構築する方法もご紹介します。

ケーススタディ: エージェント型メディア購入

長年にわたり、プレミアムデジタル広告キャンペーンのような複雑で価値の高いワークフローでは、人手を介した数週間にわたる引き継ぎ、断片化したスプレッドシート、そして手動の分析が必要とされてきました。Yahoo は、エージェント型 AI を使えば、このタイムラインを劇的に短縮し、わずか数秒でキャンペーンを計画して実行できる可能性があることに着目しました。「手動から自律的な実行へ」というこの飛躍は、運用効率を大幅に改善し、投入した予算をより確実に測定可能な成果へと結びつける大きなチャンスでした。

しかし、リスクの高いワークフローに LLM をただ組み込むだけでは問題は解決しません。もし、リアルタイムの広告在庫や、価格設定ルール、ビジネス上の制約を決定論的に理解できていないエージェントが契約や広告掲載の交渉を行えば、ハルシネーションが生じやすくなり、甚大な損失を招く取引となるおそれがあるからです。信頼できるエージェントプラットフォームには、統計的な推測ではなく、確固たる事実に基づいて行動するためのリアルタイムかつ決定版の情報源が不可欠です。

しかも、「スピード」と「事実へのグラウンディング」は必要とされる条件の半分にすぎません。AI エージェントが実際の予算を動かし始めた瞬間、その動作は規制当局の厳しい監視の対象となります。そして規制当局は、特定の決定がなぜ行われ、どのポリシーが適用されたのかについて即座に説明できることを求めてきます。事後にシステムログをさかのぼって調べるような手法は、自律的な実行を管理する手段としては不適切です。実用できるレベルのアクションシステムには、後付けではなくワークフローに直接組み込まれた、規制当局の要求に対応可能なガバナンスと監査可能性が必要です。

信頼できるアクションシステムのアーキテクチャ

Yahoo! の使命は、デジタル世界を案内する、信頼できるガイドになることです。エージェント型メディア購入は、予算を Yahoo に託し、真の説明責任が果たされることを期待する広告主、代理店、パブリッシャー、そして規制当局に対しても、その約束を広げていくものです。課題は、説明可能、管理可能、監査可能な方法でキャンペーンの実施を自動化することでした。

この課題に対処するため、Yahoo は Google Cloud で実行されるマルチエージェントシステムとして Seller Agent を構築しました。バイヤーのリクエストは、Google Kubernetes Engine（GKE）で実行され、Google の Agent Development Kit（ADK）でオーケストレーションされる計画スーパーバイザーエージェントを介して入力されます。スーパーバイザーは、在庫の検出、オーディエンスのマッチング、予測、価格分析、パッケージの推奨、ガバナンスのレビュー、実行など、各リクエストを専門的なタスクに分解します。エージェントは、オープンな Agent2Agent（A2A）プロトコルを介して連携します。一方、Gemini Enterprise Agent Platform は、エンベディング、予測、グラフ学習のためのモデルをホストします。

しかし真のブレークスルーは、自律的な実行における迅速性と完全な透明性を両立させている「デュアルグラフ基盤」のプラットフォームです。このプラットフォームは、行動に最適化されたナレッジグラフと、記憶と学習を担うコンテキストグラフという、意図的に役割を分離した 2 つの特殊なグラフシステムによって支えられています。

ナレッジグラフ: エージェントをビジネスの実態にグラウンディング

Spanner Graph を活用した Yahoo のナレッジグラフは、収益化ビジネスの各要素を相互に関連付けられた運用モデルとして表すことで、エージェントのあらゆる意思決定をビジネスの実態にグラウンディングします。広告サービス、プレースメント、オーディエンスセグメント、広告枠、契約、ガバナンス管理は、それぞれファーストクラスエンティティとして、その相互関係とともにモデル化されます。重要なのは、ポリシーをアプリケーションロジックに埋め込むのではなく、バージョン管理された関係としてグラフ内に直接組み込んでいることです。この設計により、商品、契約上の義務、同意に関する要件、規制上の制約を、単一の統合されたグラフ操作でまとめて評価することが可能になっています。

グラフは、エージェントプラットフォーム全体でセマンティックコントラクトとして機能します。キャンペーンの評価中、エージェントは 1 つのクエリプラン内で、バイヤーの初期要件から対象となるオーディエンスや管理ポリシーまでを横断的に参照できます。Gemini Enterprise Agent Platform のエンベディングは、セマンティック類似性によってこれらのエンティティの情報を拡充し、グラフニューラルネットワークは推論された関係を提供します。これにより、エージェントは単に利用可能な広告枠を取得するだけでなく、広告枠選定の根拠を正確に把握したうえで、あらゆるガバナンス上の制約を確実に遵守できるようになります。

Yahoo のナレッジグラフオントロジー（IAB AdCOM などの業界標準に準拠）

コンテキストグラフ: 監査可能なメモリの作成

エージェント規模での実行が安全なのは、完全な透明性が確保されている場合のみです。その透明性を確保することが、コンテキストグラフの核となる役割です。Seller Agent がアクションを実行するたび、その正確な実行プロセスが BigQuery Agent Analytics プラグインによってキャプチャされます。システムは、未加工のイベントをログに記録するだけでなく、Yahoo の意思決定トレースオントロジーを活用した BigQuery Agent Analytics SDK を使用して、このエビデンスから型付きのクエリ可能なコンテキストグラフを作成し、BigQuery Graph に格納します。

その結果、すべての意思決定ポイント、候補パッケージ、ポリシー評価、スペシャリストエージェントへの委任、実行結果を相互に関連付けた、エビデンスのグラフが出来上がります。このトレースは型付きグラフとして構造化されているため、エージェントの意思決定プロセスを簡単なクエリによって説明することができます。監査人は、元のキャンペーンの概要、割り当てられたすべてのスコア、適用されたポリシーなどの意思決定までのプロセスを即座にトレースできます。これにより、自律的な動作が「不透明なプロセス」から「完全に透明で継続的に改善される意思決定記録」に変わり、絶対的な説明責任を確保するのに役立ちます。

Yahoo のコンテキストグラフオントロジー

人間ができる範囲からエージェントならではの規模へ

このアーキテクチャが実際にどのように機能するのか、具体例として広告キャンペーンの実施を考えてみましょう。従来は計画、販売、運用、コンプライアンスの各部門で数週間を要していた調整作業を、2 つのプロセスを同時進行させることで数秒で完了できるようになっています。

ナレッジグラフに基づくアクションの実行: このパイプラインでは、バイヤーのリクエストからナレッジグラフに基づくキャンペーンの公開まで、直線的に予算を動かしていきます。このプロセスは、以下の 4 つのステップで構成されます。

キャンペーンの概要の送信: バイヤーエージェントは、対象オーディエンス、予算、地域、ビジネス目標を記述したキャンペーン概要を Ad Context Protocol（AdCP）を介して送信します。
ナレッジの検索: Seller Agent は、ナレッジグラフに対してクエリを実行し、関連する広告枠、オーディエンス、契約上の利用可能性、過去のパフォーマンス、管理ポリシーを特定します。
評価とスコアリング: エージェントはこれらの要素を総合的に評価して、メディア購入候補のパッケージを組み立てます。予測モデルが各機会をスコアリングする一方で、ガバナンスエージェントが同意、ブランド保護、規制上の制約を個別に確認します。
承認と実行: パッケージは、ポリシーのしきい値に基づいて自動的に承認されるか、人間による審査のためにエスカレーションされます。承認されるとメディア購入が実行され、配信が開始されます。

コンテキストグラフを使用した監査と学習。実行パイプラインが進行する一方で、この並列ループはシステムの推論プロセスをコンテキストグラフに継続的に記録します。これにより、透明性が確保され、将来のサイクルの改善が可能になります。この監査と学習プロセスには、次の機能があります。

継続的なキャプチャ: 検討されたすべての候補、割り当てられたスコア、適用されたポリシー、ガバナンスの意思決定は、紐付けられた記録としてコンテキストグラフ内で元のキャンペーンセッションにリンクされます。
クローズドループ学習: 配信、アトリビューション、成果のシグナルが届くと、それらが生成元の意思決定に紐付けられ、将来の推奨事項を改善するためのトレーニングデータが作成されます。
即時の説明可能性: 広告主が特定のパッケージが選択された理由や、成果に影響を及ぼしたポリシーについて質問すると、回答がコンテキストグラフに保存され、1 回のクエリでアクセスできます。

これにより、ナレッジ、意思決定、ガバナンス、測定、学習が連携して機能するプラットフォームが実現し、自律的なメディア購入の説明可能性と監査可能性を確保しつつ、継続的な改善を図ることが可能になります。

あらゆる業種に適用できる設計

単なるアドバイザーとしての AI の時代は終わりを迎えつつあります。企業がいま求めているのは、複雑な複数ステップのワークフローを実行できる自律型エージェント、つまり「アクションシステム」です。しかし、規制の厳しい業界では、意思決定の根拠を証明できない場合、AI がもたらすスピードがむしろリスクに変わってしまいます。自律的な実行の主な障壁となるのは、もはやインテリジェンスではなく、信頼性です。

Yahoo と Google Cloud が構築したアーキテクチャは、この問題を解決できる、幅広く適用可能なブループリントを提供します。デジタルメディアの購入におけるボトルネックを解消するために設計されたものではありますが、その基盤となるパターンは、金融取引からサプライチェーンのロジスティクスまで、リスクの高い意思決定を管理するあらゆる業界に適用可能です。エージェントならではのスピードで運用しながら、人間による監督を維持していくために、企業は以下のような新しいアーキテクチャのベースラインを採用する必要があります。

ビジネスの実態に基づく意思決定: 確率モデルだけでエージェントを運用することはできません。ビジネスロジック、有効な契約、コンプライアンスルールを決定論的にマッピングするナレッジグラフによって、エージェントをグラウンディングする必要があります。
監査可能なメモリの構築: 追跡できないものを管理することはできません。エージェントのすべてのアクションをコンテキストグラフに記録し、クエリ可能な不変のレコードを作成して、意思決定の理由や却下された代替案を正確に把握できるようにする必要があります。
オープンな相互運用性の重視: 信頼には透明性が不可欠です。オープンプロトコルと来歴標準を基盤とすることで、エージェントの動作に関する、業界共通の監査可能な枠組みを確立できます。

基盤モデルがコモディティ化するにつれ、企業の競争優位性は変化してきています。長期的に優位性を守る鍵となるのは、デプロイする言語モデルではなく、自社独自のビジネスオペレーショングラフと、統制された履歴データです。同様に、エンタープライズ AI の未来は、単に動作できるシステムではなく、その動作を説明、管理し、責任を負うことができるシステムにあります。

使ってみる

信頼できるアクションシステムを構築する準備はできましたか？まず、Spanner Graph を使用して、エージェントワークフローをビジネスの実態にグラウンディングしましょう。次に、BigQuery Graph を使用して監査可能なメモリを構築すれば、クローズドループ学習と、規制当局の要求に応じられるレベルの説明可能性を実現できます。BigQuery Agent Analytics プラグインと SDK を使用して、これらの運用トレースのキャプチャと分析を今すぐ開始できます。最後に、Ad Context Protocol を確認して、Yahoo のエージェントプラットフォームを支えるオープンコミュニケーション標準をぜひ理解しておきましょう。

- Yahoo、エンジニアリング担当ディレクター、Mikul Bhatt 氏

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

BigQuery

非構造化データ ワークフローのモダナイズ: Alteryx Live Query と Google Cloud BigQuery の連携

請求書 PDF の処理から、Live Query を使用した BigQuery での例外レポート管理まで

ソリューションの概要: 抽出、分類、検証、ルーティング、計上

アーキテクチャ: Google Cloud ネイティブ パターン

Live Query ワークフロー解説: PDF から分析情報まで

まとめ: ドキュメントから意思決定まで、ガバナンス管理されたワークフロー

BigQuery で多変量時系列予測を行う TimesFM 3.0 のご紹介

概要

新機能: 多変量基盤モデリング

BigQuery SQL を使用した多変量予測

BigQuery 会話型分析の TimesFM 3.0

まとめと次のステップ

BigQuery で AI 費用を予測可能に: 生成 AI 関数の費用管理のご紹介

費用を管理するための割り当て

対象となる関数

割り当ての管理

使用量のモニタリング

トークン割り当てと費用上限

適用の仕組み

入力データのサイズ設定: AI.COUNT_TOKENS

トークンから予算まで: 具体例

AI 費用管理のベスト プラクティス

使ってみる

オーケー: AlloyDB と Database Migration Service で「止められない基幹システム」を移行し、データドリブンな価値創出を加速

ビジネスの急成長を受けて高まった、2 つの基幹データベース刷新の必要性

AlloyDB の採用により、業務の根幹を支えるデータベースの移行と基盤統一を実現

Gemini や AlloyDB AI も活用しながら、DX と新たな価値創出を追求

ボーダーレスな Lakehouse を加速: クロスクラウド キャッシュのプレビュー版を発表

クロスクラウド キャッシュの仕組み

クロスクラウド キャッシュの実際の操作

エンタープライズ規模で効率性を向上

BigQuery クロスクラウド接続のプレビュー版を提供開始

電気通信事業者の自律性の拡張: Distributed GraphFlow を使用したグラフ ニューラル ネットワークの活用

基盤: Spanner Graph 上のデジタルツイン

ML レイヤ: Distributed Graph Flow（DGF）

ユースケース

シナリオ: GNN と DGF を使用した根本原因分析

使ってみる

千葉大学：LMS の Google Cloud 移行で「止まらない教育インフラ」を実現。運用負荷の大幅軽減とデータ駆動型教育への挑戦

【背景】コロナ禍で露呈したオンプレミスの限界と IaaS の課題

【プロセス】組織の壁と技術的ハードルを乗り越えた「三者連携」

【アーキテクチャ】安定性と先進性を両立する「クラウドネイティブへの道筋」

【導入効果】管理工数の削減が、教員と学生の「自由」を生む

【展望】AI とデータ分析で「次世代の学び」へ

【メッセージ】「IT に関する判断」をベンダーに委ねない

住友重機械工業: Google Cloud で SDV 開発基盤を構築し、大型機械用ソフトウェア開発の高速化と人材育成を両立

加速する SDV の流れに対応するために、Google Cloud でプラットフォームを構築

デジタルツインを活用した事前検証を行い、実機実験を 1 回でクリア

Cloud Workstations と TAP で最適なクラウド人材の育成環境を整備

JR東日本: Spanner と Cloud Run で「タッチトリガー」を実現し、改札データを起点に新たなコミュニケーションと価値を創出

改札というリアルな接点から生まれる、生活に密着したデータ

Spanner と Cloud Run で厳しいトラフィック処理の要件をクリア

「タッチトリガー」が活性化させていく、毎日の暮らしと地域コミュニティ

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

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

BigQuery で TabFM を使ってみる

BigQuery の TabFM の仕組み

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

予測 ML が簡単に

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

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

ID 列を実装する方法

使ってみる

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

BigQuery Graph の新機能

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

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

BigQuery Graph を今すぐ使ってみる

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

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

実際の活用例

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

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

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

準備ができたら

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

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

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

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

非構造化データワークフローのモダナイズ: Alteryx Live Query と Google Cloud BigQuery の連携

アーキテクチャ: Google Cloud ネイティブパターン

入力データのサイズ設定: `AI.COUNT_TOKENS`

AI 費用管理のベストプラクティス

ボーダーレスな Lakehouse を加速: クロスクラウドキャッシュのプレビュー版を発表

クロスクラウドキャッシュの仕組み

クロスクラウドキャッシュの実際の操作

電気通信事業者の自律性の拡張: Distributed GraphFlow を使用したグラフニューラルネットワークの活用

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

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

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

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

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

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

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

Bigtable: 自動車テレメトリーのデータバックボーン

ソリューション: データプラットフォームでのネイティブグラフ分析

AI.AGG() の仕組みとベストプラクティス

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: Yahoo の事例

信頼できるアクションシステムのアーキテクチャ

コンテキストグラフ: 監査可能なメモリの作成