データ分析

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

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

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

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

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

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

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

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

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

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

改善結果の評価

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

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

結果

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

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

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

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

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

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

3 つの主な改善点:

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

次のステップ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エージェントとは

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

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

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

ツールと相互運用性

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

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

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

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

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

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

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

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

テストと評価

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

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

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

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

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

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

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

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

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

出発点

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

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

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

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

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

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

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

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

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

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

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

データに眠る可能性

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

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

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

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

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

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

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

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

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

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

統合データに向けた歩み

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI 時代の教訓

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 自動同期

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

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

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

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

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

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

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

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

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

AI.SEARCH の導入

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

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

シンプルな管理

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

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

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

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

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

今後の予定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エージェントを作成する

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

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

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

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

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

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

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

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

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

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

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

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

関数を定義する

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

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

ストリームを処理する

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

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

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

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

質問する

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

コンテキストを確認する

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

Python

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

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

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

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

Python

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

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

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

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

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

Python

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

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

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

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

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

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

始める

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

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

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

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

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

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

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

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

グローバルクエリとは

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

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

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

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

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

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

グローバルクエリの活用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

始める

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

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

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

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

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

BigQuery の会話型分析のご紹介

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

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

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

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

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

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

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

図 1 - BigQuery の会話型分析

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

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

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

図 2 - BigQuery の会話型分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dataflow の ML インフラストラクチャに関する最新情報

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

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

AI の世界は電光石火のスピードで変化しています。Google Cloud は、AI ワークロードと ML ワークロードを強化する最高水準のインフラストラクチャを提供することに尽力しています。Dataflow は、Google Cloud の AI スタックの重要なコンポーネントであり、さまざまな分析や AI のユースケースを支援するバッチパイプラインとストリーミングパイプラインを作成できます。今回は、バッチ ML ワークロードとストリーミング ML ワークロードの実行において、より多くの選択肢の提供、取得可能性の増加、効率性の向上を実現する最新機能をご紹介します。

より多くの選択肢: パフォーマンスが最適化されたハードウェア

Google は、すべての ML ワークロードが同じように作成されているわけではないことを理解しています。そのため、提供するハードウェアを拡大し、お客様が固有のニーズに最適なアクセラレータを柔軟に選択できるようにしています。

新しい GPU: Google は常に最新かつ最高の GPU をラインナップに追加しています。最近では、H100 および H100 Mega GPU のサポートを発表しました。これにより、最先端のハードウェアを活用して AI 推論ワークロードを高速化できます。大手企業は、Dataflow で GPU を活用して、革新的なカスタマーエクスペリエンスを実現しています。たとえば、脅威インテリジェンスプラットフォームプロバイダの Flashpoint はドキュメントの翻訳を強化し、メディアプロバイダの Spotify は大規模なポッドキャストプレビューを可能にしています。
TPU: 大規模な ML タスクには、Tensor Processing Unit（TPU）が強力かつ費用対効果の高いソリューションとなります。Google は最近、TPU V5E、V5P、V6E のサポートを発表しました。これにより、最先端の ML ビルダーは、Dataflow ジョブ内で直接、大容量低レイテンシの ML 推論ワークロードを大規模かつ効率的に実行できます。

アクセラレータの取得可能性の向上

必要なときに必要なハードウェアにアクセスできることは、ML プロジェクトを順調に進めるために不可欠です。Google は、必要なリソースをこれまで以上に簡単に取得できる、アクセラレータの新たな使い方を導入いたしました。

GPU / TPU の予約: このたび Dataflow ジョブの GPU と TPU を予約できるようになりました。これにより、必要なときに必要なリソースを確保できます。これは、リソースが利用可能になるまで待機できない重要なワークロードにとってきわめて重要です。
Flex Start GPU プロビジョニング: 開始時間が柔軟なバッチジョブの場合、GPU は業界全体で需要が高いため、その確保は手動による不確実なプロセスになる可能性があります。Dynamic Workload Scheduler（DWS）によって実現した新しいFlex Start プロビジョニングモデルは、この問題を効果的に解決します。アクセラレータリソースを利用できない場合、Dataflow はジョブをエラーにするのではなくキューに入れ、必要な GPU が利用可能になり次第、自動的にジョブを開始します。これにより、手動で繰り返し再送信する必要がなくなり、リソース不足のリスクが軽減し、デベロッパーの生産性が向上します。

AI ワークロードの効率性が向上

Google は、お客様が AI ワークロードをより効率的に実行できるようにする方法を常に模索しています。最近発表した Right Fitting や ML 対応ストリーミングなどの機能は、AI への投資を最大限に活かせるように設計されています。

ML 対応のストリーミング: ストリーミングエンジンが ML 対応になったため、ストリーミング ML パイプラインの実行方法についてよりスマートな意思決定ができるようになりました。たとえば、Dataflow の水平自動スケーリングは通常、バックログのサイズや CPU の使用率といったさまざまな入力シグナルを利用しています。アクセラレータが ML ワークロード処理用コンピューティングインフラストラクチャの重要な部分になるにつれ、自動スケーリングの判断にアクセラレータを考慮することが必要となってきています。Google は最近、GPU ベースの自動スケーリングをリリースしました。これにより、Dataflow サービスで並列処理度などの GPU 関連シグナルを水平自動スケーリングアルゴリズムの重要な入力として使用し、ストリーミング ML ジョブの効率性を高めることが可能になります。
Right Fitting: Dataflow パイプラインでは、ステージごとに必要なリソースが異なることがよくあります。以前は、最も要求の厳しいステージに対応できる性能を備えた単一のマシンタイプを選択する必要があったため、ジョブのリソース使用量が少ないステージでは非効率的で、費用が無駄になっていました。Right Fitting は、異種混合のリソースプールを使用できるようにすることで、この「ワンサイズですべてに対応」しなければならないという問題を解決します。つまり、ジョブのコンピューティング負荷の高いステージは大容量メモリや GPU を備えた専用のハードウェアで実行し、その他のステージは汎用的な費用対効果の高いワーカーで実行できるということです。これにより、効率性が大幅に向上し、費用が最適化されます。

Google は、Dataflow の ML 機能とお客様にもたらされる可能性に大きな期待を寄せています。今すぐ Dataflow の使用を開始し、これらの機能を活用して、ML の最も困難な課題を解決しましょう。

- Google、プロダクトマネージャー、Efesa Origbo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gemini 3.0 のサポート

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

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

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

使ってみる

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

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

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

Cloud Composer で Apache Airflow 3.1 を活用し、ワークフローオーケストレーションを強化

Fri, 30 Jan 2026 03:00:00 +0000

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

データスタックが分断された世界では、革新的で、移植性と拡張性を備えたワークフローオーケストレーションが求められます。フルマネージドのデータおよび AI / ML 向けワークフローオーケストレーションサービスである Cloud Composer は、Apache Airflow を基盤として、ユニバーサルなコントロールプレーンを提供しています。そしてこのたび、Cloud Composer が Airflow 3.1 をプレビュー版としてサポートすることになりましたのでお知らせします。

11 月にリリースされたこのアップデートは、プラットフォームにとって大きな節目となるもので、ハイパースケーラーが Airflow 3.1 を提供するのは今回が初めてです。

Airflow 3 を基盤に進化

Airflow 3.1 の新機能は、Airflow 3.0 で導入された革新的なアーキテクチャを基盤として構築されています。

疎結合アーキテクチャ: スケジューラと実行レイヤを明確に分離することで、スケーラビリティとセキュリティを向上させます。
DAG のバージョニング: DAG の自動バージョニングをネイティブにサポートし、タスクの削除やロジック変更後も、過去の構造と実行履歴を保持します。
強力なマネージドバックフィル: バックフィル機構を刷新し、スケジューラがフルマネージドで扱う第一級の機能として再設計しました。
イベントドリブンスケジューリングとデータアセット: アセットに基づくトリガーに加え、メッセージキューへの到着などの外部イベントに応じてワークフローを起動できる機能を強化しています。

このほかにも多数の改善が含まれています。

Airflow 3 のアーキテクチャ面の変更点をさらに詳しく知りたい場合は、過去の発表記事「Next Gen Data Pipelines: Airflow 3 Arrives on Google Cloud Composer（次世代データパイプライン: Airflow 3 が Google Cloud Composer に登場）」をご覧ください。

Composer 上の Airflow 3.1 では何が新しくなったのか

Google Cloud 上で Airflow 3.1 の新機能を堅牢かつ信頼性の高い形で提供するため、Google は多大な投資を行ってきました。Airflow 3.1 では特に、可視性の向上、信頼性の強化、グローバルチームの支援を目的とした機能強化が追加されています。

1. 人間参加型（HITL）ワークフロー

AI エージェントや自動化パイプラインが複雑化するにつれ、人による監督の重要性はますます高まっています。Airflow 3.1 では、強力な人間参加型（HITL）機能が導入され、ワークフローの実行を deferred（遅延）状態で一時停止し、Airflow の UI または API 呼び出しを通じて、人が判断を下すまで待機できるようになりました。

HITL により、デプロイの承認、生成 AI モデルの出力のレビュー、パイプラインの挙動を調整するためのフィードバックなど、さまざまな場面で人が主導権を持てます。

このプロセスをさらに円滑にするため、HITL オペレータは Airflow Notifiers とネイティブに連携します。タスクが入力待ちで一時停止した瞬間に、Slack、メール、PagerDuty などを通じて自動通知を送信する Notifier を設定できます。これらのヘルパーメソッドを利用すれば、通知に該当する承認ページへの直接リンクを含めることができ、関係者は UI 内を探すことなく、即座に対応できます。

2. デッドラインアラート

Airflow におけるタスクの SLA 管理は進化しています。Airflow 3.1 では、従来の仕組みに代わり、よりスマートでプロアクティブなデッドラインアラートが導入されました。DAG やタスクについて、開始時刻や論理日付を基準とした具体的な時間ベースのしきい値を設定できるようになっています。

たとえば、長時間実行される ML トレーニングジョブなどの重要なパイプラインが想定される実行時間を超過した場合、Airflow は標準の Notifier を通じて自動的に通知します。これにより、ダウンストリームの目標に影響が及ぶ前に、遅延の兆候を把握できます。

3. ネイティブな多言語対応（国際化）

多くのデータエンジニアリングチームはグローバルに分散しており、メンバーはそれぞれ異なる言語を使用しています。Airflow 3.1 では、最新の React ベース UI 全体が完全にローカライズされ、スペイン語、フランス語、ポーランド語、ドイツ語、中国語（簡体字・繁体字）、日本語、ポルトガル語など、17 言語に対応しています。

4. 現代的な拡張性と開発者エクスペリエンス

中核となるオーケストレーション機能にとどまらず、Airflow 3.1 では開発者エクスペリエンスを向上させるための複数のアーキテクチャ改善が導入されています。これらのアップデートにより、チームはプラットフォームの UI を柔軟に拡張し、より応答性の高い同期型アプリケーションを構築できるようになります。

React プラグインシステム: カスタムダッシュボードや独自ビューを UI に直接組み込めます。
推論の実行: 同期 DAG の完了までを監視できる、新しいストリーミング API エンドポイントを提供します。

クローズドな囲い込み型ではなく、オープンなオーケストレーションが選ばれる理由

一部のオーケストレーションプラットフォームは、取り込みとオーケストレーションを独自の不透明な仕組みに包み込み、すべてを単一の「囲い込み型」に統合しようとします。しかし、プロプライエタリなツールでは、新たなユースケースへの対応をベンダーに依存するため、機能追加が遅れやすいという課題があります。その点、Airflow はオーケストレーションの業界標準として定着しており、ユーザーは市場の最前線に立ち続けることができます。

Google は、このエコシステムの育成に強くコミットしています。単なるプラットフォームプロバイダにとどまらず、Airflow のコードベースに積極的に貢献する立場としても関与しています。Cloud Composer 3 は、マネージドオープンソースの成熟形といえる存在であり、堅牢化された境界によるセキュリティと、オープン標準がもたらすほぼ無限の拡張性を両立しています。このアプローチにより、次のメリットが得られます。

コミュニティ主導のイノベーション: 機能の進化スピードは、単一企業の研究開発予算に左右されるべきものではありません。Airflow 3.1 では、世界中の数千人規模のコントリビューターによる集合的なイノベーションを活用でき、コミュニティによって構築された幅広い Provider エコシステムに迅速にアクセスできます。
ベンダーロックインからの解放: ロジックが特定ベンダーのエコシステムに強く結び付けられるプロプライエタリなプラットフォームとは異なり、Cloud Composer は標準の Apache Airflow 上で動作します。そのため、オーケストレーションのコードは、可搬性の高い Python のまま保たれます。
拡張性: エンタープライズ環境では、レガシーな連携やニッチなツールといった「ロングテール」の統合要件を抱えることが少なくありません。ベンダーがコネクタを提供するのを待つのではなく、Composer では、任意のシステムと連携するためのカスタム Python Operator を自ら実装できます。これにより、社内の独自 API からオンプレミスのハードウェアに至るまで、クローズドなツールにありがちな「ロードマップ上の制約」に縛られることなく、強力な接続性を確保できます。

使ってみる

上記で紹介した、人間参加型（HITL）ワークフローからプロアクティブなデッドラインアラートに至るまでの各機能は、Apache Airflow が持つイノベーションの結晶と言えます。Airflow 3.1 を搭載した Cloud Composer 3 は、現在プレビュー版として提供中です。新しい環境を作成し、これらの新機能を今すぐ体験してみてください。

-Google、シニアプロダクトマネージャー Piotr Wieczorek

-Dataplex Universal Catalog / データ共有 / データ統合担当プロダクトリード Chai Pydimukkala

Palo Alto Networks がマルチテナントのスケーラブルな統合データプラットフォームを構築した方法

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

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

世界中の企業が大量のデータを処理しています。Palo Alto Networks は、同社の製品ポートフォリオ全体で、毎秒数千件のファイアウォールログ、テレメトリーシグナル、脅威イベントを処理しています。この規模に対応するため、Palo Alto Networks は 30,000 個の別個のデータパイプラインを運用しており、それぞれに運用負荷がかかっていました。このシングルテナントアーキテクチャモデルは当初はうまく機能していましたが、最近ではイノベーションの停滞、規模拡大の制限が始まり、新しい分析ユースケースの導入コストの増加につながっていました。

次世代のセキュリティプロダクトをサポートするため、Palo Alto Networks は Google Cloud と提携し、Dataflow、Pub/Sub、BigQuery を活用した統合マルチテナントプラットフォームへとデータ処理環境をモダナイズしました。この変革は、Palo Alto Networks の統合データプラットフォーム（UDP）の基盤となり、現在ではアジリティの向上、運用の簡素化、費用対効果の向上により、毎日数十億件のイベントを処理できるようになりました。

課題: シングルテナントアーキテクチャでは対応しきれない

移行前、Palo Alto Networks のデータプラットフォームは「テナントごとに 1 つのパイプライン」モデルに基づいて構築されていました。テナントパイプラインごとに、独自の構成、トラブルシューティング、オンコールローテーション、キャパシティ調整が必要でした。Palo Alto Networks の利用が増えるにつれて、次のような問題も増加しました。

合計で毎秒約 30 GB のスループットを処理する 30,000 以上のパイプラインをサポートするための脆弱なアラートと毎週の運用オーバーヘッド。
デプロイサイクルの遅さから、新しいテナントのオンボーディングが難しくなっていた。
負荷に関係なく、各テナントに大量のコンピューティングリソースが割り当てられていた。
エンジニアリングの時間が、新しい分析の構築ではなくインフラストラクチャの管理に費やされていた。

このモデルは運用のアジリティを妨げ、新しいプロダクトラインの拡大やデータ量の増加に伴うスケーリングを困難にしていました。

変革: Dataflow による新しいアーキテクチャパラダイムの採用

転機が訪れたのは、Google Cloud Dataflow のサーバーレス自動スケーリングアーキテクチャがまったく異なる運用モデルをサポートできることをチームが認識したときでした。Palo Alto Networks は、数千もの別個のパイプラインを維持する代わりに、ワークロードをマルチテナントシステムに統合し、テナント間でリソースをインテリジェントに共有することができました。

これを可能にしたのは、次のような複数のコア機能です。

1. アーキテクチャの移行Dataflow を使用することで、チームは「テナントごとに 1 つのジョブ」から、単一のアーキテクチャ内で複数のテナントを処理できる「共有リソースプール」に移行できました。この移行により、運用が大幅に簡素化され、新たな効率性が実現しました。

2. 大規模なマルチテナントの実現Dataflow の自動スケーリングエンジンは、変動するワークロードを簡単に管理し、サイバーセキュリティ環境でよくある予測不可能な急増に対応します。これにより、手動でのキャパシティプランニングが不要になりました。

3. 運用の自由度Flex テンプレートと Dataflow のマネージドサービスモデルを使用することで、チームは CI / CD プロセスを、1 週間かかるデプロイサイクルから 1 日で完了するワークフローへと変革しました。エンジニアはインフラストラクチャの管理に時間を費やす必要がなくなり、分析、脅威検出、プロダクトイノベーションに集中できます。

4. 実行の統合すべてのジョブが Dataflow ベースの共有プラットフォームで実行されるため、チームは異なるコードベースを維持しなくても、リアルタイムシステムとバッチシステムの間でワークロードを柔軟に移動できるようになりました。

5. オブザーバビリティDataflow では、チームは組み込みのロギングと指標を利用して、リアルタイムワークロードとバッチワークロードの両方でパイプラインの健全性をモニタリングし、追加のツールを使用せずにパフォーマンスを明確に可視化できます。Dataflow により、オンコールアラートに必要なすべての指標が明らかになるため、PANW コードベースでカスタム指標を構築または維持する必要がなくなります。アラートがトリガーされると、エンジニアは Dataflow UI を使用してパフォーマンスのボトルネックを迅速に特定し、是正措置を講じることができます。

アーキテクチャの概要

Palo Alto Networks の UDP を強化する Dataflow ベースの統合リアルタイムパイプライン

効果: 価値、費用、エンジニアリングの重点の大きな変化

Dataflow への移行は、古いシステムをモダナイズしただけではありません。エンジニアリングチームの働き方を根本的に変え、さまざまな面で効果をもたらしました。

経済的なメリット: パイプラインを統合し、Dataflow の自動スケーリングを利用することで、Palo Alto Networks はコンピューティング費用を約 30% 削減しました。この費用削減は、冗長なパイプラインの削減、共有リソースの利用率向上、手動によるキャパシティ調整の排除によって実現しました。
プラットフォームにとってのメリット: 統合データプラットフォームは、同社全体でリアルタイムデータ処理の長期的な標準となりました。スケーラブルで再現性があり、エンジニアリング作業を重複させることなく新しいプロダクトラインをサポートできる「Dataflow ネイティブ」なブループリントを提供します。
従業員にとってのメリット: Dataflow が運用の複雑さに対処するため、エンジニアはインフラストラクチャの管理ではなく、新しい分析機能の構築に集中できるようになりました。この移行により、士気が向上して、デリバリーサイクルが加速し、アラート疲れが軽減されました。「当社にとって真の差別化要因は、Dataflow が大規模かつ真のマルチテナンシーに対応できることでした。その自動スケーリングエンジンは、1 つのジョブで数千のテナントにまたがるリソースを管理できるほど優れており、これが約 30% の費用削減を実現する鍵となりました。30,000 件以上のジョブを管理する環境から、ほんの一握りのジョブを管理する環境へと移行しました。その結果、チームの業務内容が根本的に変わりました。」- Palo Alto Networks エンジニアリングチーム

モデルの拡張: サイバーセキュリティ以外のユースケース

Palo Alto Networks が採用したアーキテクチャパターンは、マルチテナントのリアルタイムデータを大規模に扱うあらゆる組織に幅広く適用できます。次に例を示します。

e コマース: 単一のマーケットプレイスで数千の販売者向けにリアルタイムダッシュボードを提供する
ゲーム: 数百万人のプレーヤーからのテレメトリーシグナルを処理して、リーダーボードを更新し、不正行為を検出する
フィンテック: 数百の銀行における取引をモニタリングし、不審な行動にリアルタイムでフラグを付ける
IoT とロジスティクス: 車両フリートのデータを分析して、ルーティングとメンテナンススケジュールを最適化する

マルチテナンシー、共有実行、自動スケーリングといった同様の原則は、多くの業界で効率の向上に役立ちます。

持続可能なデータの未来を創る

Palo Alto Networks は、Dataflow を標準化することで、セキュリティ分析プラットフォームの長期的なアジリティの基盤を築きました。統合データプラットフォームは現在、同社のリアルタイムデータ戦略の基盤として機能し、イノベーションの加速と経済効率の高い運用に役立っています。

この事例は、Dataflow のような柔軟で高性能なデータ処理エンジンによって、運用オーバーヘッドを増やすことなくスケールできるという自信を企業に与えられることを示しています。さらに、Google Cloud を使用してリアルタイムアーキテクチャをモダナイズしたいと考えるチーム向けに、再利用可能なハンドブックも提供します。

データパイプラインをモダナイズする方法の詳細については、Dataflow のプロダクトページをご覧ください。

- Google Cloud、データ分析担当カスタマーエンジニア Pavan Paladugu

- Palo Alto Networks、シニアプリンシパルエンジニア Gaurav Mishra 氏

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

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

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

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

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

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

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

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

仕組み: 実例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

バイブクエリ: BigQuery のコメントを SQL に変換する機能を使って SQL クエリをすばやく作成

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

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

複雑な SQL クエリの作成は容易な作業ではありません。エンジニアであれば、SQL のワークフロー内で簡単な英文を使ってデータのニーズを直接表現できないものかと考えることも少なくないでしょう。最近では、自然言語の AI プロンプトを使用してコードを生成する「バイブコーディング」という方法により、誰もがより手軽に開発に取り組めるようになりました。そこでこのたび、BigQuery に「コメントを SQL に変換」機能を導入しました。この機能により、自然言語を使用したクエリの作成（「バイブクエリ」）が可能になります。

簡単な英文を SQL コードに

「コメントを SQL に変換」は、人間の言語を構造化データクエリに変換してくれる AI 機能です。SQL ステートメントに自然言語による表現を直接埋め込んで、それをシステムが実行可能な SQL コードに変換することができます。この変換を自動化することで、複雑なクエリを迅速に記述できるうえ、ボイラープレートコードの記述にかかる時間を短縮できます。

たとえば、週末を含めた 2 つの日付間の営業日数を計算する必要がある場合について考えてみましょう。この機能を使用すれば、2 つの日付間の営業日数を計算するための適切な関数を探す必要がなくなります。「How many business days are there between January 1st and March 15th, excluding weekends?」という自然言語表現を記述すれば、AI が SQL の日付関数を生成してくれます。これにより、SQL を手動で構築する手間が最小限に抑えられ、データから答えを見つける作業に集中できます。

主要な特長:

自然言語の埋め込み: 自然言語表現をコメント内に記述することで、SQL クエリに組み込むことができます。たとえば、「/* average trip distance by day of week */」のように記述します。
コンテキストの理解: BigQuery の AI は、SQL クエリの周囲のコンテキストを分析してコメントを正確に解釈します。これにより、生成される SQL がユーザーの意図に沿ったものになります。
多様な句に対応: さまざまな SQL 句内で自然言語表現を使用できます。たとえば、SELECT、FROM、WHERE、ORDER BY、GROUP BY などの句に対応しています。
複雑なクエリ: 1 つの SQL ステートメント内で複数の表現を使用することで、複雑なクエリを構築できます。たとえば、「SELECT /* average trip distance, total fare */ FROM /* NYC taxi ride public data of 2020 */ WHERE /* day of week is Saturday */ GROUP BY /* pickup location */」といった使い方が可能です。
誰でも利用可能: SQL の専門家でなくても、この機能を使用してデータ分析を実行できます。
その場で改良: 最初の SQL が生成されたら、自然言語表現を改良して、SQL 出力がどのように変化するかをすぐに確認できます。

すべての SQL ユーザーの作業をスピードアップ

Google は、デベロッパーの生産性向上とデータ探索の簡素化を目指しています。この機能は、SQL 初心者から熟練した SQL エキスパートまで、幅広いユーザー層にとって有用です。データアナリスト、ソフトウェア開発者、ビジネスアナリストなど、あらゆる立場のユーザーが、BigQuery データをより効果的に操作できるようになります。たとえば、SQL 初心者は次のように利用できます。

統計情報の要約を生成する: SELECT /* average sales per region */ FROM /* sales_table */ GROUP BY /* region */
条件に基づいてデータをフィルタリングする: SELECT * FROM /* customer_table */ WHERE /* age is greater than 30 and city is New York */
結果を並べ替える: SELECT * FROM /* product_table */ ORDER BY /* price in descending order */

SQL の上級者向けに、さらに高度なユースケースをいくつかご紹介します。

1. 条件付き集計を使用した時系列分析。時系列の集計、条件付きのカウント、日付の抽出を 1 つのクエリで処理します。

自然言語表現:

SELECT /* daily average temperature, and count of days where temperature exceeded 30 degrees Celsius */

FROM /* weather_data */

WHERE /* year is 2023 */

GROUP BY /* day */

ORDER BY /* day */.

生成された SQL:

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n DATE(timestamp) AS day,\r\n AVG(temperature) AS daily_avg_temperature,\r\n COUNT(CASE WHEN temperature > 30 THEN 1 ELSE NULL END) AS hot_days_count\r\nFROM\r\n `weather_data`\r\nWHERE\r\n EXTRACT(YEAR FROM timestamp) = 2023\r\nGROUP BY\r\n day\r\nORDER BY\r\n day;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486f6160>)])]>

2. 複数テーブルの結合と複雑なフィルタリング。複数テーブルの結合、期間のフィルタリング、文字列ベースのフィルタリングを並べ替えと組み合わせて処理する方法です。

自然言語表現: SELECT /* customer name, order total, and product category */

FROM /* customers */ JOIN /* orders */ ON /* customer ID */ JOIN /* products */ ON /* product ID */

WHERE /* order date is in the last month and customer region is 'Europe'*/

ORDER BY /* order total descending */.

生成された SQL:

code_block: <ListValue: [StructValue([('code', "SELECT\r\n c.customer_name,\r\n o.order_total,\r\n p.product_category\r\nFROM\r\n `customers` c\r\nJOIN\r\n `orders` o ON c.customer_id = o.customer_id\r\nJOIN\r\n `products` p ON o.product_id = p.product_id\r\nWHERE\r\n o.order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH)\r\n AND c.region = 'Europe'\r\nORDER BY\r\n o.order_total DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486f6250>)])]>

3. ランキングと移動平均のためのウィンドウ関数。通常は手動で記述すると複雑になるランキングのウィンドウ関数を処理します。日付の要素でデータをグループ化することもできます。

自然言語表現: SELECT /* product name, monthly sales, and rank of products by sales within each category */

FROM /* sales_data */

WHERE /* year is 2023 */

WINDOW /* partition by category order by monthly sales descending */.

生成された SQL:

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n product_name,\r\n SUM(monthly_sales) AS total_monthly_sales,\r\n RANK() OVER (PARTITION BY category ORDER BY SUM(monthly_sales) DESC) AS sales_rank\r\nFROM\r\n `sales_data`\r\nWHERE\r\n EXTRACT(YEAR FROM sale_date) = 2023\r\nGROUP BY\r\n product_name, category, EXTRACT(MONTH FROM sale_date)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486f69d0>)])]>

4. 日付の集計とユーザーセグメントを使ったコホート分析。コホート分析は一般的なデータ分析手法ですが、複雑な手法でもあります。日付の切り捨てやグループ化のほか、時間の経過に伴うユーザー維持率をピボット処理によって表示するといった処理が行われます。

自然言語表現: SELECT /* cohort month, count of active users in each subsequent month */

FROM /* user_activity */

WHERE /* user signup date is between '2022-01-01' and '2022-12-31' */

GROUP BY /* cohort month, activity month */ PIVOT /* activity month */.

生成された SQL:

code_block: <ListValue: [StructValue([('code', "WITH CohortData AS (\r\n SELECT\r\n DATE_TRUNC(signup_date, MONTH) AS cohort_month,\r\n DATE_TRUNC(activity_date, MONTH) AS activity_month\r\n FROM\r\n `user_activity`\r\n WHERE\r\n signup_date BETWEEN '2022-01-01' AND '2022-12-31'\r\n)\r\nSELECT\r\n cohort_month,\r\n COUNT(DISTINCT user_id)\r\nFROM\r\n CohortData\r\nGROUP BY\r\n cohort_month, activity_month\r\nPIVOT(\r\n COUNT(DISTINCT user_id)\r\n FOR activity_month IN (SELECT DISTINCT activity_month FROM CohortData ORDER BY activity_month)\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486f6550>)])]>

ご利用にあたって

私たちのチームでは、BigQuery のコメントで自然言語表現を使用して SQL を生成することで、お客様のワークフローを合理化できる可能性をすでに実感しています。BigQuery ツールキットの価値ある追加機能として、きっと皆様のお役に立つものと確信しております。利用方法は次のとおりです。

BQ Studio を開きます。
SQL 生成ウィジェットが有効になっていることを確認します。

例:

code_block: <ListValue: [StructValue([('code', 'SELECT /* tip and passenger count columns */ FROM /* NYC taxi ride public data */ WHERE /* passenger count greater than 6 and tip is zero */'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe8486f6340>)])]>

3. 変換するコメント付きの SQL を選択します。Gemini のガターボタンをクリックし、[コメントを SQL に変換] をクリックします。

4. 生成ウィジェットが表示され、変換された SQL / 自然言語表現の差分ビューが表示されます。

5. [挿入] を選択するか、改良 / マルチターン機能を使用して改良を続けます。

- ML エンジニアリングマネージャー、Gautam Gupta

Looker の新機能: セルフサービス Explore、タブ付きダッシュボード、カスタムテーマ

Thu, 15 Jan 2026 02:00:00 +0000

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

データチームにとって、統制された信頼できる指標の必要性と、アドホックな分析を迅速に行うことに対するビジネスニーズの兼ね合いは常に課題となっているようです。Google Cloud は、統制されたレポート作成と迅速なデータ探索を両立させるため、Looker にいくつかの新機能を導入し、ユーザーのセルフサービス機能を拡張します。このアップデートによって、統制されたモデルとローカルデータを組み合わせて分析することや、複雑なダッシュボードをより効率的に整理すること、分析レポートのデザインを企業ブランディングに合わせてカスタマイズすることなどを、ユーザーがすべて Looker プラットフォーム内で行えるようになります。

Looker のセルフサービス Explore でアドホックデータを分析する

予算スプレッドシート、販売リスト、非定型の調査ファイルなどの貴重なデータは、しばしば主要なデータベースの外部に存在します。セルフサービス Explore（現在はプレビュー版）では、ユーザーが Looker 内で直接ドラッグ＆ドロップインターフェースを使用して、CSV とスプレッドシートベースのデータをアップロードできます。

この機能を使用し、ローカルファイルを完全にモデル化された Looker データと組み合わせることで、新しい理論のテストと分析情報の強化が可能になります。データのアップロード後、ユーザーはセルフサービス Explore に新しいメジャーとディメンションを視覚的な方法で追加してカスタマイズし、ダッシュボードと Look を介して結果を共有できます。

CSV ファイルをアップロードし、わずか数回のクリックで新しいセルフサービス Explore を作成可能

ガバナンスを維持するため、Looker インスタンスにアップロードされるファイルと、アップロードを実行する権限を持つユーザーについては、管理者が継続的に監視します。さらに、Google Cloud は新しいコンテンツ認定フローを導入しました。これにより、検証済みの信頼できる情報源であるコンテンツをより簡単に示すことができるようになり、ユーザーはアドホックテストデータと認定済みデータを確実に区別できます。

セルフサービス Explore を認定する

データのアップロードとコンテンツ認定は、Looker 25.20 の公開プレビュー版で利用可能になります。

タブ付きダッシュボードを使用して、より明確で一貫性のあるデータストーリーを伝える

新しいタブ付きダッシュボード機能により、ダッシュボード編集者は 1 つのページに情報が密集した状態から脱却し、複雑な情報を整理して論理的なナラティブに変換できるようになりました。編集者は、タブの追加、名前変更、並べ替えの各コントロールを使用して、効率的にコンテンツを作成できます。

また、閲覧者もシームレスに操作できます。フィルタの値は自動的にダッシュボード全体に渡されますが、各タブには現在のビューに関連するフィルタのみが表示されるため、すっきりした外観になります。ユーザーは、特定のタブ固有の URL を共有できます。また、マルチタブダッシュボードの複数のタブをまとめて 1 つの PDF ドキュメントとして扱い、作成スケジュールを設定したりダウンロードしたりできます。

マルチタブダッシュボードの複数のタブ間を移動する

現在、この機能はプレビュー版で利用できます。

ダッシュボードにカスタムスタイルを適用する

社内ダッシュボードを会社のブランディングに合わせてカスタマイズすると、使い慣れた操作でデータを活用できるため、ユーザーエンゲージメントが高まります。Google Cloud は、社内ダッシュボードテーマ設定の公開プレビュー版をリリースします。作成者は、タイルのスタイル、色、フォント、書式設定をカスタマイズし、Looker アプリケーション内で使用されるダッシュボードに直接適用できるようになります。

社内ダッシュボードにカスタムテーマ設定を適用する

この機能を使って事前構成済みのテーマを保存、共有、適用することで、一貫性が確保されます。社内テーマを管理する権限を持つユーザーは、既存のダッシュボード用の新しいテンプレートを作成したり、インスタンス全体に適用するデフォルトのテーマを選択したりできます。

社内ダッシュボードテーマ設定は、[管理者] > [ラボ] ページですぐに有効にできます。

社内ダッシュボードテーマ設定のプレビューを有効にする

使ってみる

Looker のこうした新しいセルフサービス機能は、プレゼンテーションの柔軟性と品質を高め、組織内のすべてのユーザーがデータをより有効に活用できるように設計されています。セルフサービス Explore と社内ダッシュボードテーマ設定をぜひお試しになり、ご意見、ご感想をお寄せください。

- シニアプロダクトマネージャー、Aleks Flexo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud Shell 環境の場合:

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

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

手順 5: Gemini の API キー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gemini CLI を実行します。

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

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

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

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

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

企業データを Google の新しい Antigravity IDE に接続する

Thu, 25 Dec 2025 01:00:00 +0000

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

AI の最先端技術は、単純なチャットインターフェースから、複雑なワークフローを計画、実行、改良できる自律型エージェントへと急速に移行しています。こうした新たな状況においては、これらのインテリジェントエージェントを企業データにグラウンディングする能力こそが、真のビジネス価値を引き出す鍵となります。Google Cloud はこの変革の最前線に立ち、堅牢なデータドリブンアプリケーションを迅速かつ正確に構築できるようお客様を支援しています。

先月、Google は AI ファーストの統合開発環境（IDE）である Antigravity を発表しました。そして今回、Antigravity で構築した AI エージェントに、組織を支える信頼できるデータインフラストラクチャへの直接的かつ安全なアクセスを提供できるようになりました。これにより、抽象的な推論が具体的なデータ認識型アクションへと変わります。Antigravity 内で MCP Toolbox for Databases を利用した Model Context Protocol（MCP）サーバーが利用可能になったことで、開発ワークフロー内で AI エージェントを Google のデータクラウド内の AlloyDB for PostgreSQL、BigQuery、Spanner、Cloud SQL、Looker などのサービスに安全に接続できます。

Antigravity で MCP を使用する理由

Antigravity は、ユーザーがフローを維持できるように設計されていますが、AI エージェントの能力は「知っていること」によって制限されます。本当に役立つアプリケーションを構築するには、エージェントがデータを理解する必要があります。MCP はユニバーサルトランスレータとして機能します。AI 向け USB-C ポートのようなものと考えることができます。これにより、IDE の LLM が標準化された方法でデータソースに接続できるようになります。事前構築済みの MCP サーバーを Antigravity に直接統合することで、手動で構成する必要がなくなります。エージェントがデータベースと直接会話できるようになり、IDE を離れることなくより迅速に構築と反復処理を行えるようになります。

MCP サーバーを使ってみる

Antigravity では、エージェントをデータに接続する作業は UI を使用して行われるため、データベース接続を動作させるためだけに複雑な構成ファイルと格闘するという、誰もが経験したことのある課題が解消されます。使用を開始する方法は以下のとおりです。

1. 発見とリリース

Google Cloud 向け MCP サーバーは、Antigravity MCP ストアで入手できます。「AlloyDB for PostgreSQL」や「BigQuery」など必要なサービスを検索し、[インストール] をクリックして設定プロセスを開始します。

Antigravity MCP ストアのリリース

2. 接続を構成する

Antigravity には、プロジェクト ID やリージョンなどのサービスの詳細を追加できるフォームが表示されます。また、パスワードを入力するか、Antigravity に Identity and Access Management（IAM）認証情報を使用させることで、セキュリティを強化することもできます。これらは安全に保存されるため、エージェントはチャットウィンドウで未加工のシークレットを公開することなく、必要なツールにアクセスできます。

AlloyDB for PostgreSQL MCP サーバーのインストール

エージェントの活用事例を見る

Antigravity に接続すると、エージェントはユーザーを支援するために使用できる「ツール」（実行可能な関数）のスイートを獲得し、さまざまなサービスにわたって開発とオブザーバビリティのエクスペリエンスを変革するのに役立ちます。一般的なシナリオをいくつか見てみましょう。

AlloyDB for PostgreSQL によるデータベースタスクの効率化

PostgreSQL などのリレーショナルデータベースに対して構築する場合、スキーマ名の確認やクエリのテストのために IDE と SQL クライアントを切り替えるのに時間がかかることがあります。AlloyDB MCP サーバーを使用すると、エージェントがそのコンテキストを処理し、データベース管理を実行して、アプリに含めることができる高品質の SQL コードを生成する機能を獲得します。これらすべてが Antigravity インターフェース内で実行されます。

例:

スキーマの探索: エージェントは list_tables と get_table_schema を使用してデータベース構造を読み取り、関係を即座に説明できます。
クエリの開発: エージェントに「上位 10 ユーザーを検索するクエリを作成して」と指示すると、execute_sql を使用してクエリを実行し、結果をすぐに確認できます。
最適化: コードをコミットする前に、エージェントを使用して get_query_plan を実行し、ロジックがパフォーマンスに優れていることを確認します。

MCP ツールを使用した Antigravity エージェント

BigQuery で分析を促進する

大量のデータが必要になるアプリケーションの場合、エージェントは有能なデータアナリストとして機能します。BigQuery MCP サーバーを活用することで、たとえば以下のようなことが可能になります。

予測: forecast を使用して過去のデータに基づいて将来の傾向を予測します。
カタログの検索: search_catalog を使用してデータアセットを検出、管理します。
拡張分析: analyze_contribution を使用してさまざまな要因がデータ指標に与える影響を把握します。

Looker で真実を構築する

Looker は、ビジネス指標における信頼できる唯一の情報源として機能します。Looker の MCP サーバーにより、エージェントはコードとビジネスロジックのギャップを埋めることができます。たとえば、

指標の整合性の確保: フィールド名が total_revenue なのか revenue_total なのかを推測する必要がなくなります。get_explores と get_dimensions を使用して、エージェントに「ネットリテンションの正しい指標は何ですか？」と質問し、セマンティックモデルから正確なフィールド参照を取得します。
ロジックを即座に検証: ダッシュボードをデプロイして理論をテストするまで待つ必要はありません。run_query を使用して、IDE で直接 Looker モデルに対してアドホックテストを実行することで、アプリケーションロジックがライブデータと一致するようになります。
監査レポート: run_look を使用して、既存の保存済みレポートから結果を抽出します。これにより、アプリケーションの出力が公式のビジネスレポートと一致していることを確認できます。

Antigravity でデータを活用して構築する

Google のデータクラウド MCP サーバーを Antigravity に統合することで、AI を使用した分析情報の発見や新しいアプリケーションの開発がこれまで以上に簡単になりました。ビジネスを運営するさまざまなデータソースにアクセスできるようになった今、コードに話しかけるだけでなく、ユーザーに新しいエクスペリエンスを提供できるようになりました。

実際にやってみるには、以下のリソースをご覧ください。

ドキュメント: MCP を使用して AlloyDB に接続する
GitHub: MCP Toolbox for Databases

-データベース向け AI 担当シニアプロダクトマネージャー Rahul Deshmukh

-データベース向け AI 担当スタッフソフトウェアエンジニア Averi Kitsch

キュレートされたデータとコンテキストのための Dataplex Universal Catalog のデータプロダクトのご紹介

Tue, 23 Dec 2025 01:02:00 +0000

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

多くの組織は、断片化されたデータが多すぎて、それがビジネス目標にどのように影響するのかを明確に把握できていません。これは、重大な断絶を引き起こします。データ利用者（分析情報を生成するためにデータを必要とするアナリストやデータサイエンティスト）は、必要なデータを簡単に発見、アクセス、信頼することができません。一方、データプロデューサー（これらのデータアセットを所有するチーム）は、利用者がセルフサービスでデータにアクセスできるようにすることができません。信頼できるコンテキスト豊富なデータに簡単にアクセスできなければ、組織は AI やエージェント技術の導入に苦労する可能性があります。

組織がこれらの課題を克服できるよう、Google はデータプロダクトを、Google Cloud の統合されたインテリジェントデータから AI ガバナンスソリューションである Dataplex Universal Catalog に導入します。データプロダクトとは、特定のビジネス課題を解決するために意図的に組み立てられた、データアセット、ドキュメント、ガバナンス管理からなる、キュレートされたすぐに使用できるパッケージです。データプロダクトは単なるデータではなく、ビジネス価値を実証し、組織内の AI イノベーションを促進するのに役立ちます。データプロダクトは現在プレビュー版として利用可能です。

データプロダクトについて

データプロダクトとは、本質的にアセットのグループがビジネス問題にどのように対処するかをモデル化した、ディストリビューションの論理ユニットです。Google はこれを、棚に並んでいるラベル、説明書、品質保証が付いた商品のデータ版と考えています。元のデータアセットを抽象化して、組織全体で信頼性の高い、検出可能な価値のあるリソースへと変換します。これにより、データチームは以下をより効率的に行えるようになります。

期待値を定義する: データプロデューサーは、同じアドホックな質問に何度も答える代わりに、データ品質、鮮度、想定されるユースケースに関する情報を、データプロダクトのドキュメントや契約書に直接カタログ化できます。
管理トイルを削減する: データプロダクトを使用することで、ユースケースごとにアセットを論理的にグループ化できます。これによりアクセス管理が簡素化され、個々のアセットを管理するために必要な手作業が軽減されます。
価値を実証する: データアセットをそれらが提供するビジネスユースケースに直接リンクすることで、データチームは創出する価値を明確に実証し、履歴データだけでなく影響に基づいて予算支出を正当化できます。

データプロダクトの使用方法

データプロダクトは、大まかに以下の基本的な機能を提供します。

ユースケースに合わせて設計する: ビジネス課題を特定し、そのユースケースを解決するデータプロダクトをモデル化します。
オーナー権限を確立する: データプロダクトのオーナー権限を定義し、アカウンタビリティを確保します。
コンテキストを民主化する: プロダクトが解決する問題を、使用例と期待値とともに文書化します。
契約を定義する: 消費者に信頼を提供し、契約上の保証を伝えます。
アセットを管理する: プロダクトを閲覧できるユーザーを管理し、データアセットへのアクセスを規制します。
発見を可能にする: データ利用者がデータプロダクトを簡単に探してアクセスをリクエストできるよう支援します。
サービスを進化させる: プロダクトを反復的に進化させ、利用者のニーズに応えます。

具体的にはどのような意味があるのでしょうか？あなたはマーケティングチームのデータプロデューサーであるとします。組織のデータサイエンティストなどのデータ利用者は、四半期ごとのキャンペーンのパフォーマンスを分析して、今後の調整を提案することが常に求められています。「マーケティングキャンペーン分析」データプロダクトでデータ利用者を支援する方法は以下のとおりです。

データプロダクトを作成する: まず「マーケティングキャンペーン分析」という名前の新しいデータプロダクトを作成します。ご自身を所有者として割り当て、連絡先情報を入力してください。
プロジェクトを横断してアセットをキュレートする: 次に、分析に必要な関連アセットを追加します。たとえば、BigQuery のテーブルとビュー（ad_spend_daily、customer_conversions、website_traffic_logs など）を含めることができます。
ロールと権限を定義する: データプロダクトのアセットへのアクセスを管理および制御するため、data_scientist グループを作成し、このグループにすべてのアセットに対する viewer アクセス権を付与します。
データ契約を確立する: 信頼構築のため、データプロダクトの更新頻度を指定し、契約条件を伝えます。
詳細ドキュメントを追加する: 最後に、このデータプロダクトがキャンペーン分析における唯一の信頼できる情報源であることを説明する詳細な説明を追加します。SQL クエリの例やその他のアーティファクトへのリンクを含めてください。

画像 1: データプロデューサーは、アセット、権限、契約、コンテキストをパッケージ化してデータプロダクトを作成する

データサイエンティストは、「キャンペーン分析」を検索し、このデータプロダクトを見つけてアクセスをリクエストするだけで、データの品質と出所を確信したうえで業務に必要なすべての情報をすぐに入手できます。

画像 2: データ利用者はデータプロダクトを見つけてそのコンテキストを理解し、アクセスをリクエストする

「私たちは、Google Cloud のデータプロダクトを使用して、Virgin Media O2 のデータ共有機能を強化しています。この進化により、データ契約の豊富なコンテキスト、明確なデータリネージ、強化されたメタデータなど、データが真のプロダクトとして扱われるようになります。この合理化されたワークフローにより、チームは必要なデータをより迅速に取得できるようになり、データに基づく意思決定が加速します。」- Virgin Media O2、データアプリケーション担当ディレクター、Jonathan Ford 氏

データプロダクトは AI とエージェントをどのように強化するか

Google は、データプロダクトは AI とエージェントテクノロジーの導入の基盤であり、組織が個々のデータアセットを管理する段階から、価値主導の論理ユニットを提供する段階へと移行するのに役立つと考えています。データプロダクトは、以下の方法で AI とエージェントによるイノベーションを促進します。

ビジネスですぐに使用できる高品質なデータを提供する: データプロダクトは特定のビジネス課題を解決するアセットで事前にキュレートされているため、AI エージェントが、すでにクレンジング、整理され、ビジネス目標に沿ったデータでトレーニングおよび運用されることを保証するのに役立ちます。
豊富なコンテキストでエージェントをグラウンディングして正確な分析情報を得る: AI の重要な課題の一つに、グラウンディングがあります。グラウンディングとは、モデルの出力を検証可能な情報源に紐付け、虚偽または誤解を招くコンテンツが生成される可能性を低減する機能です。データプロデューサーは、包括的なドキュメント、契約書、その他のメタデータなど、豊富なコンテキスト情報でデータプロダクトを充実させ、AI エージェントがレスポンスの根拠とする強固な基盤を提供できます。
会話型 AI と行動につながるインサイトを強化する: 高品質のデータと豊富なコンテキストを組み合わせることで、データプロダクトは会話型 AI を強化できます。ユーザーがデータプロダクトを活用する AI エージェントと対話する際、エージェントはより関連性が高く、ニュアンスに富んだレスポンスを提供できます。

上記と同様の「マーケティングキャンペーン分析」の例を使用すると、ビジネスコンテキスト、サンプルクエリ、ad_spend_daily と customer_conversions のスキーマ定義を含む詳細なドキュメントを含むデータプロダクトにより、AI エージェントがこのコンテキストを「読み込み」、より正確なレスポンスを提供できるようになります。

準備は整いましたか？Dataplex Universal Catalog のデータプロダクトの詳細については、こちらのドキュメントをご覧ください。

-プロダクトマネージャー Deepinder Dhuria
-プロダクトマネージャー George Verghese

データ分析

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

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

改善結果の評価

結果

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

次のステップ

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

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

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

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

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

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

出発点

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

データに眠る可能性

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

統合データに向けた歩み

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

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

AI 時代の教訓

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

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

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

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

AI.SEARCH の導入

シンプルな管理

今後の予定

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

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

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

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

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

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

始める

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

グローバル クエリとは

グローバル クエリの活用

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

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

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

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

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

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

始める

BigQuery の会話型分析のご紹介

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

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

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

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

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

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

Dataflow の ML インフラストラクチャに関する最新情報

より多くの選択肢: パフォーマンスが最適化されたハードウェア

アクセラレータの取得可能性の向上

AI ワークロードの効率性が向上

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

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

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

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

Gemini 3.0 のサポート

使ってみる

Cloud Composer で Apache Airflow 3.1 を活用し、ワークフロー オーケストレーションを強化

Airflow 3 を基盤に進化

Composer 上の Airflow 3.1 では何が新しくなったのか

クローズドな囲い込み型ではなく、オープンなオーケストレーションが選ばれる理由

使ってみる

Palo Alto Networks がマルチテナントのスケーラブルな統合データ プラットフォームを構築した方法

課題: シングル テナント アーキテクチャでは対応しきれない

変革: Dataflow による新しいアーキテクチャ パラダイムの採用

アーキテクチャの概要

効果: 価値、費用、エンジニアリングの重点の大きな変化

モデルの拡張: サイバーセキュリティ以外のユースケース

持続可能なデータの未来を創る

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

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

仕組み: 実例

使ってみる

バイブクエリ: BigQuery のコメントを SQL に変換する機能を使って SQL クエリをすばやく作成

簡単な英文を SQL コードに

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

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

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

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

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

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

グローバルクエリとは

グローバルクエリの活用

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

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

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

Cloud Composer で Apache Airflow 3.1 を活用し、ワークフローオーケストレーションを強化

Palo Alto Networks がマルチテナントのスケーラブルな統合データプラットフォームを構築した方法

課題: シングルテナントアーキテクチャでは対応しきれない

変革: Dataflow による新しいアーキテクチャパラダイムの採用

Looker のセルフサービス Explore でアドホックデータを分析する

タブ付きダッシュボードを使用して、より明確で一貫性のあるデータストーリーを伝える

ダッシュボードにカスタムスタイルを適用する

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

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

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

キュレートされたデータとコンテキストのための Dataplex Universal Catalog のデータプロダクトのご紹介

データプロダクトについて

データプロダクトの使用方法

データプロダクトは AI とエージェントをどのように強化するか