データ分析

Knowledge Catalog に新しい自己学習型コンテキストエンリッチメントを導入

Mon, 02 Nov 2026 03:00:00 +0000

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

このたび、Google Cloud のエージェント向けコンテキストエンジンである Knowledge Catalog で、自己学習型のコンテキストエンリッチメント（プレビュー版）と、刷新された Knowledge Studio エクスペリエンス（プレビュー版）をリリースしました。自己学習型のエンリッチメントは、Knowledge Catalog 既存の Gemini によるエンリッチメントをベースにしており、エージェントとユーザー間のやり取りを分析してギャップを特定することで、ビジネスコンテキストを正確かつ最新の状態に保ちます。Knowledge Studio は、コンテキストエンジニアとデータスチュワードのための新しいコマンドセンターです。会話形式でデータ資産を探索したり、視覚的なコンテキストグラフ上で関係性を把握したりできるほか、コンテキストグラフへの変更案をユーザーやエージェントに公開する前に確認することもできます。

エージェントの性能は、その推論のベースとなる組織全体の定義、ルール、関係、すなわちコンテキストの質に左右されます。そのため、コンテキストのキュレーションは企業における AI エージェント活用において最も重要な取り組みの一つとなっています。現在、キュレーションの大部分は手作業で行われています。コンテキストエンジニアはエージェントごとにプロンプトとマッピングを記述し、データスチュワードは数千ものアセットにわたり定義を手動で更新して最新の状態に保とうとします。しかし、組織のエージェントが数個から数千個、そして最終的には数百万個へと拡大していくと、この方法では対応できなくなります。

Knowledge Catalog の Gemini を活用した自己学習型エンリッチメントは、手動によるメンテナンス作業を、継続的なフィードバックループへと進化させます。エージェントとユーザーのやり取りを分析することで、不足している情報や古くなったコンテキストを的確に特定します。さらに、ハンドブック、コードリポジトリ、ビジネスドキュメントから検証済みの定義を抽出して、ガバナンスの効いた再利用可能な「コンテキストセット」として集約します。また、最適化された検索により、各エージェントは肥大化したプロンプトや未加工のスキーマから推論するのではなく、必要なコンテキストを正確に取得して、組織全体で蓄積された学習成果を活用できます。社内ベンチマークによると、Knowledge Catalog の使用により、AI エージェントは精度が約 4 倍向上、レイテンシは最大 33% 短縮、トークン使用量も最大 75% 削減されます。

Gemini を活用した自己学習型のエンリッチメントでコンテキストを最新の状態に維持

Gemini エージェントに「前四半期の EMEA の純収益はいくらだった？」という簡単な質問をするとします。正しく回答するには、会社が純収益をどのように定義しているか、受注データがどのテーブルに保持されているか、そしてそれらがどのように結合されているかを把握している必要があります。しかし、そうした知識は通常、Google ドキュメントの財務ハンドブック、GitHub のデータモデル、Confluence ページなどに分散しています。従来の静的なデータカタログでは、エージェントが適切なデータを効果的にクエリできるように、現場のエキスパートがビジネス定義、指標、その他のコンテキストを手動で集めて更新する必要があります。しかし、実際にはエキスパートがすべてのアセットを文書化する余裕などありません。そのため、財務チームが翌四半期のパートナークレジットの処理方法を改訂した瞬間、静的な定義と実態にずれが生じ、数式がハードコードされたすべてのエージェントが間違った回答を返すようになります。

Knowledge Catalog のエンリッチメント機能は、チームのすべてのドキュメント、リポジトリ、テーブルといったビジネスナレッジがすでに保存されている場所で機能します。自社やサードパーティのソースにわたる構造化データはもちろん、Cloud Storage、Google Workspace、GitHub、Confluence、SharePoint の非構造化データとも連携します。ビジネスナレッジの検出、抽出、体系化、維持を自動で行い、ハンドブックや Wiki などの非構造化ソースとそのコンテキストを Knowledge Catalog のテーブルやスキーマといった構造化メタデータに紐づけます。これにより、構造化データの検出と活用が大幅に容易になります。また、オンデマンドまたはスケジュール実行により、ビジネス定義、テーブルや列の説明、結合関係、ゴールデンクエリ、タスク固有のエージェント指示などを、それぞれのソースの引用と信頼スコアを添えて自動提案します。実行のたびにソースでの変更を検出し、古くなった定義を廃止するとともに競合をフラグ付けして、確認を促します。

エンリッチメント機能は、ユーザーとエージェント双方のインタラクションから学習します。エンリッチメントを構成すると、PII を秘匿化しながら、Gemini エージェント、BigQuery の会話型分析、カスタムエージェントからのインタラクショントレースを分析できます。また、曖昧な列のルックアップ、グラウンディングされていない指標、定義の欠落、ユーザーによる質問の言い換えなど、エージェントがつまずいた箇所を特定できます。その後、エンリッチメント機能は信頼できる回答を見つけて修正案をステージングし、同じ間違いが繰り返されないようにします。コンテキストエンジニアリングはこのようにして何百万ものエージェントのやり取りに追従し、エキスパートが定義をゼロから記述しなくても、提示された変更をレビューするだけで済むようにします。

接続されたソース、評価、自己学習によってエンリッチメントタスクを構成

自動化とは、制御を放棄することではありません。自動公開はいつでも有効または無効にできます。また、提案された変更を自動的に承認する信頼スコア（例: 85%）を自由に設定することもできます。しきい値を下回る変更や、削除などの影響の大きい更新は、変更リクエストとしてスチュワードによる承認、編集、拒否の判断に回されます。独自の評価セットを提供して、提案された更新をエンドツーエンドでテストすることもできます。また、すべての変更は完全な来歴とともにログに記録され、元に戻すことができます。もちろん、Google がお客様のデータをモデルのトレーニングに使用することはありません。

公開前にエンリッチメントの提案、信頼スコア、変更の差分を確認

コンテキストセットによりオーディエンスごとに適切なコンテキストを設定

その性質上、エンタープライズコンテキストグラフは非常に広範なデータを網羅したものになりますが、個々のタスクにおいてエージェントとユーザー双方が必要とするのは、信頼できる適切なセグメントのみであることがよくあります。Knowledge Catalog は、コンテキストセットによってそれに対応します。コンテキストセットとは、コンテキストグラフの中から、特定のドメイン、チーム、エージェント、またはエンドユーザーグループの定義、指標、結合ロジック、ゴールデンクエリのみを厳選して管理するサブセットです。たとえば、セールスエージェントであればセールス用のコンテキストセット、財務アナリストのアシスタントであれば財務用のコンテキストセットにバインドできます。「純収益」は、グループによって当然意味が異なるため、すべてのドメインは同じカタログ内で独自の定義を維持します。ただし、エージェントは 1 つのセットだけに限定されるわけではありません。Knowledge Catalog の検索機能を使用すれば、任意のタスクに適したコンテキストセットを動的に探し出すことも可能です。

コンテキストセットには、組み込みのデータガバナンスときめ細かいアクセス制御機能も備わっています。各コンテキストセットへのアクセスは IAM で管理されるため、どのエージェントとユーザーに読み取り、使用、編集の権限を与えるかをスチュワードが制御できます。エージェントは使用を許可されているセットからのみコンテキストを取得し、基盤となるデータへのアクセスは既存の権限に従って行われます。すべての更新は遡って追跡したり、元に戻したりできます。また、コンテキストセットは Open Knowledge Format（OKF）を基盤としているため、OKF バンドルをインポートしてコンテキストセットに変換し、それを再び OKF としてエクスポートすることで、コンテキストのポータビリティを維持できます。

承認されたエンリッチメントを管理されたコンテキストセットに公開

Knowledge Studio ですべてを探索、管理

上述の機能はすべて、エージェントのコンテキストをキュレートして管理するコンテキストエンジニアとデータスチュワード向けに構築された、刷新された Knowledge Catalog エクスペリエンスに統合されています。

Knowledge Studio でコンテキストグラフを視覚的に操作

新しい Knowledge Studio は、Knowledge Catalog を静的なインベントリのリポジトリからインタラクティブなコマンドセンターへと変貌させます。これにより、以下が可能になります。

コンテキストカバレッジを一目で確認: オペレーショナルデータベースやウェアハウスから、セマンティックモデル、コンテキストセット、ドキュメントまで、クロスクラウドデータ資産をビジュアルマップ上で俯瞰できます。
対話形式でコンテキストを探索: 自然言語でビジネスに関する質問をしたり、エンタープライズコンテキストグラフ全体で関係性をたどったりできるほか、エージェントがメタデータをどのように推論しているかを正確に把握できます。
エンリッチメントを 1 か所で確認、検証: 提案された各変更、ソースの引用、信頼スコアを精査できます。実際の質問を用いてコンテキストセットをテストし、ソフトウェア開発のようなバージョン管理機能で変更リクエストの承認、編集、ロールバックを行えます。
エンリッチメント実行をモニタリング: 各エンリッチメントタスクのスケジュール、結果、トークン使用量、実行時間を追跡できるほか、実行が完了するとメールで通知を受け取れます。

使ってみる

Knowledge Catalog の自己学習型エンリッチメントがエンタープライズ AI エージェントをグラウンディングする仕組み

デモを見る: Knowledge Catalog の自己学習型エンリッチメントがエージェントをグラウンディングする仕組み

これらの機能は、今後数週間以内にお客様へ順次公開される予定です。即時アクセスをリクエストするには、ご登録ください。詳細な手順については、ドキュメントをご確認ください。

- データ分析担当グループプロダクトマネージャー、Firat Elbey

- プロダクトリード、Vasiya Krishnan

BigQuery ObjectRef の一般提供を開始: 会話分析用のマルチモーダルデータプラットフォームをすべて SQL で構築

Fri, 30 Oct 2026 02:30:00 +0000

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

データサイエンス、データエンジニアリング、ML を担当する各チームにとって、画像、動画、音声、ドキュメントなどの非構造化データの価値を引き出すということは、これまで、サイロ化されたデータパイプラインを管理することを意味していました。構造化データと非構造化データを別々に、さらには、分析と AI / ML のユースケースを別々に扱う必要があると考えられてきました。たとえファイルが Cloud Storage 内にあっても、推論を実行するには外部の ML ワークロードをオーケストレートする必要があり、その後、構造化された推論出力を再度データウェアハウスに結合させるという、複雑で脆弱な課題に取り組まなければなりません。この事後的なデータ結合は、運用上のオーバーヘッドを増大させるばかりか、データベースの整合性も危うくします。

この問題を解決するために、このたび、BigQuery の ObjectRef とマルチモーダルデータ分析が一般提供（GA）となり、BigQuery が包括的なマルチモーダルエージェントデータプラットフォームとして確立されました。

ObjectRef を使用すると、Cloud Storage と分析エンジンのギャップを BigQuery でネイティブに埋めることができます。非構造化データを ObjectRef 列としてネイティブに取り込み、従来のリレーショナルデータベースの構造化データ列と並列で扱うことが可能になったのです。会話分析において、単一の SQL クエリまたは自然言語クエリでマルチモーダル、複数列の入力を Gemini モデルに直接受け渡せるので、スタンドアロンモデル API と比較しても大きなメリットが得られます。BigQuery AI、BigQuery の会話型分析、そして Gemini Enterprise で ObjectRef を使用できるようになったことで、Cloud Storage のファイルを、構造化データベースの豊富なコンテキストや、メタデータ、タイムスタンプ、カスタムエージェントへの指示などと簡単に組み合わせることができます。

これにより、完全なサーバーレスコンピューティング、低い総所有コスト、大規模な処理が可能な組み込みの推論といった、BigQuery ならではの強みを活用しながら、非構造化から構造化、非構造化から非構造化、そしてマルチモーダルからマルチモーダルへの高度なパイプラインをフルに構築、実行、管理できるようになりました。しかも、これらに個別のコンピューティングクラスタは必要ありません。重要なのは、ObjectRef を非構造化オブジェクトと同じ行に保存することで、抽出された特徴とアノテーションを非構造化オブジェクト自体と直接組み合わせることができる点です。この結合されたデータを会話分析と AI エージェントで直接使用することで、非構造化ファイルを純粋な構造化形式に変換する際に発生しがちな、データやコンテキストのニュアンスの喪失を回避できます。多くのお客様はすでにこのアプローチを使用して、マルチモーダルベクトル検索用のエンベディングを生成し、生成 AI を使用して大規模な分類を実行し、膨大なドキュメントやメディアのアーカイブから正確なデータと特徴を抽出しています。これらは、以下のように、すべて標準 SQL で実行できます。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\nAI.AGG(image_ref, "Summarize the major categories of pictures")\r\nFROM\r\n`bigquery-public-data.cymbal_pets.products`;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93488cfe10>)])]>

ObjectRef で非構造化データも構造化データ同様に処理

ObjectRef は、BigQuery の外部オブジェクトを参照する（ポインタとなる）組み込みの事前定義された STRUCT データ型です。

code_block: <ListValue: [StructValue([('code', '-- ObjectRef is a special STRUCT in BigQuery \r\nSTRUCT<\r\n uri STRING,\r\n version STRING,\r\n authorizer STRING,\r\n details JSON'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93488cc6d0>)])]>

これらのポインタを従来の構造化データの列とともに標準の BigQuery テーブルにネイティブに保存することで、BigQuery は非構造化ファイルを第一級オブジェクトのデータとして扱います。さらに、このアーキテクチャは独立したデータライフサイクルをサポートします。これは、GCS データと BigQuery テーブルが、他のシステムの基盤となるデータに影響を与えることなく、独立して変更できることを意味します。

このアプローチは、複数のデータペルソナに対し、大きなメリットをもたらします。

ゼロコピーアーキテクチャ: 大量のメディアファイルを Cloud Storage に安全に保管し、BigQuery で即座にクエリを実行できます。データグラビティを尊重し、コストのかかるデータ重複を回避できます。
SQL と Python の相互運用性: 標準 SQL または BigQuery DataFrames を使用して非構造化データをクエリできます。重要なのは、ObjectRef を BigQuery Python UDF に受け渡すことができる点です。これにより、OpenCV などのオープンソース Python ライブラリをデータに直接適用し、データを移動することなくカスタムロジックを実行できます。
独立したライフサイクルとバージョニング: ObjectRef は、特定の GCS 世代番号を追跡することで、推論の再現性を確保します。基盤となる GCS ファイルが変更された場合でも、クエリは、行が書き込まれたときに存在していたファイルの正確なバージョンを参照できます。
ガバナンスの統一: BigQuery の既存のセキュリティポリシーと IAM 制御を使用して、構造化された列とそれに関連する非構造化ファイルの両方へのアクセスを保護、監査、共有できます。

SQL で完全な忠実度の ETL を構築

ObjectRef のプレビュー版をリリースして以来、ユーザーの間で、SQL のみで完全な忠実度の ETL パイプラインを構築する、盤石で非常に効果的なパターンが醸成されています。

データや ML の担当チームは BigQuery のサーバーレスアーキテクチャを活用して、AI / ML をデータ環境に直接統合できます。データの移動や推論の処理のために個別のコンピューティングクラスタを用意する必要はありません。GCS 内の非構造化データを標準の BigQuery 列として管理することで、べき等性のあるパイプラインの構築、再現性の確保、シームレスなバックフィルの実行といったデータエンジニアリングの基本的なベストプラクティスを、画像、動画、音声、ドキュメントに直接適用できます。

このようにデータを盤石の状態で準備できたら、いつでも BigQuery 内で Gemini を使用して、完全な忠実度の ETL を実行できます。元の ObjectRef を同じ行に固定したまま、特徴を抽出して非構造化データにアノテーションを付けることで、2 層式の分析が可能になります。つまり、構造化された出力が高速フィルタリング、レポート、BI ダッシュボードを可能にし、アタッチされた非構造化オブジェクトは、コンテキストを重視した詳細な推論に利用できます。たとえば、顧客との通話録音のアーカイブから感情スコアとトピックタグを抽出し、BI ダッシュボード（構造化レイヤ）でリスクのある顧客アカウントにすばやくフラグを立てることも可能です。同時に、エスカレーションプロセスを評価する会話分析エージェントは、元の音声ファイルにシームレスにフォールバックして、発信者とカスタマーサービス担当者のやり取りを分析できます。これにより、非構造化から構造化への ETL パイプラインで発生しがちな、重要なニュアンスの喪失を防ぐことができます。

業界リーダーの声（実証済みユースケース）

「Snap では、コミュニティの安全を最優先に考えており、コミュニティガイドラインに違反するコンテンツをユーザーから遮断できるよう取り組んでいます。そこで、公開投稿のサンプルを定期的に審査しているのですが、ObjectRef と BigQuery AI の活用により、単純なランダムサンプリングから事後層別サンプリングへの移行を実現しました。この移行により、人間による審査プロセスの効率が向上し、時間と労力が節約できて新しいワークフローや既存ワークフローの拡充に再投資できるようになったため、有害リスクのコンテンツを検出して対処する能力がさらに向上しました。」 - Snap、データサイエンティストCarlos Ortiz 氏

BigQuery ObjectRef は、すでにプレビュー段階において多岐にわたる重要なワークロードに導入されています。お客様は、これらの試験運用パイプラインを本番環境に移行し、非構造化データを実用的な構造化されたインサイトに変換することに成功しています。代表的な事例をいくつか挙げます。

コンテンツの管理: 各種オンラインプラットフォームが、BigQuery を活用してマルチメディアアセットを標準テレメトリーデータとともに単一パイプラインに統合し、管理機能と安全性を抜本的に向上させています。
プロアクティブな脅威検出: 多くの企業では、セキュリティチームが BigQuery を使用して、ウェブの視覚的要素と構造的要素をネットワークログとともに分析し、脅威をプロアクティブに特定する仕組みを劇的に進化させています。
インベントリコンプライアンス: 各種オンライン小売業者が、膨大な画像リポジトリからテキストとコンテキストを直接抽出して、規制やブランドコンプライアンスに関わる問題の大規模な自動フラグ付けを実現しています。
カスタマーエクスペリエンスの向上: サービス指向の企業は、BigQuery AI を使用してサポートエージェントと顧客の音声によるやり取りを分析し、顧客の感情評価をサービスの向上につなげています。

一般提供で追加された新機能

一般提供リリースでは、お客様の幅広いユースケースのサポートに重点を置き、デベロッパーエクスペリエンスを効率化しました。

柔軟な認証:
- 一般提供（GA）では、ObjectRefs のエンドユーザー認証情報（EUC）サポートが導入されました。ユーザーが自分の IAM ID を使用して非構造化データを直接すばやくクエリ、探索できるアドホック分析が可能になりました。
- プレビュー版では、非構造化ファイルに対してクエリを実行するには、ObjectRef 用に明示的な BigQuery 接続の設定が必要でした。この接続は、サービスアカウント主導の堅牢な本番環境パイプラインの推奨ベストプラクティスとして引き続き完全にサポートされますが、追加設定の手間を省くため、GA ではアドホック分析サポートが追加されました。
Cloud Storage メタデータの統合サポート: 非構造化データのメタデータは、Google Cloud のさまざまな場所に存在します。ObjectRef は、これらのデータソースをすべてネイティブにサポートするようになりました。メタデータが現在 BigQuery オブジェクトテーブルにあろうが、Cloud Storage Insights データセット、あるいは標準 BigQuery テーブル内の生文字列 URI として存在していようが、ObjectRef をシームレスに作成、管理でき、基となるデータを分析することができます。
比較分析のための配列サポート: 配列に含まれる ObjectRef の処理をネイティブにサポートできるようになりました。これにより、複数ドキュメントを相互比較したり、一連の画像を分析したり、1 回のセマンティック呼び出しで複数アイテムをバッチ処理したりするなど、これまでできなかったタイプのワークロードを処理できます。

実用例: エンドツーエンドのマルチモーダル分析

これらの GA アップデートの機能性を確認するために、簡素化された SQL 演算子を使用して実践的なマルチモーダルパイプラインを構築する方法を見てみましょう。

完全な忠実度の ETL: コールセンターの音声分析

カスタマーサービスの通話分析において、従来は、音声ファイルを文字起こしと自然言語処理のための専用クラスタに移動する必要がありました。しかし、ObjectRef を使用すると、音声ファイルを解析して構造化されたビジネスインテリジェンスを抽出し、標準的なリレーショナルデータベースの列として直接追加できます。

GA で追加された OBJ.MAKE_REF() 関数を使用して、生文字列 URI から音声形式を自動的に検出し、一般的なユースケースに BigQuery のマネージド AI 関数を適用できます。たとえば、AI.CLASSIFY() を使用して顧客の通話タイプを分類することができます。BigQuery は AI 関数向けに最適化モードをデフォルトで使用して、消費されるトークン数を削減します。

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE TABLE call_center.annotated_call_logs AS\r\nSELECT \r\n customer_id,\r\n call_date,\r\n OBJ.MAKE_REF(audio_uri) as ref,\r\n AI.CLASSIFY(\r\n OBJ.MAKE_REF(audio_uri), [\r\n "Lost or stolen card", \r\n "Declined card payment", \r\n "Activate my card",\r\n "Order physical card",\r\n "Cancel transfer",\r\n "Password or pin forgotten",\r\n "Virtual card not working",\r\n "Card swallowed by ATM",\r\n "Balance not updated after bank transfer",\r\n "Balance not updated after check or cash deposit",\r\n "Extra charge on statement",\r\n "Transfer fee charged"\r\n ]\r\n ) AS customer_issue_type,\r\n FROM \r\n call_center.raw_call_logs;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93488cf310>)])]>

このテーブルは、BigQuery 会話型分析エージェントのマルチモーダルデータソースとして機能します。エージェントは自然言語クエリを SQL に変換しますが、追加情報が必要な場合は BigQuery AI 関数を使用して音声ファイルを分析します。

2.大規模な生成 AI フィルタリング: プロダクトコンプライアンス

データエンジニアは、画像やドキュメントの内容に基づいて大規模データセットのフィルタリングを頻繁に行う必要があります。そこで GA では、重い生成クエリを実行してテキスト出力を解析する代わりに、WHERE 句で標準 SQL とともに宣言型の AI.IF() 演算子をネイティブに使用できるようになりました。デフォルトの最適化モードでは、消費されるトークンの数が削減され、ワークロードもさらに最適化されます。

code_block: <ListValue: [StructValue([('code', 'SELECT \r\n product_id,\r\n seller_id,\r\nFROM \r\n ecommerce.vendor_uploads\r\nWHERE \r\n upload_date >= CURRENT_DATE() - 1 AND\r\n AI.IF(("Does this product image contain a restricted item or policy violation?", OBJ.MAKE_REF(image_uri)))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93488cde10>)])]>

3. 複数オブジェクトの推論: プロアクティブな脅威検出

GA で配列がネイティブにサポートされたことで、Gemini を 1 度だけ呼び出して ObjectRef の配列を受け渡し、複数のファイルを同時に分析できるようになりました。

これにより、複雑な比較ロジックを SQL で直接実行することができます。たとえば、セキュリティチームは、公式ログインページのスクリーンショットと、新たに発見された不審なウェブページのスクリーンショットを同時に Gemini に渡すことで、フィッシングの検出を大規模に実施できます。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n uri,\r\n size,\r\n updated,\r\n result.animal_type,\r\n result.item_color\r\nFROM (\r\n SELECT\r\n uri,\r\n size,\r\n updated,\r\n AI.GENERATE(\r\n ("What type of animal is this pet product for, and what is its primary color?", ref),\r\n output_schema => \'animal_type STRING, item_color STRING\'\r\n ) AS result\r\n FROM\r\n OBJ.LIST(\'gs://cloud-samples-data/bigquery/tutorials/cymbal-pets/images/*.png\')\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93488cf5d0>)])]>

code_block: <ListValue: [StructValue([('code', 'SELECT \r\n log_id,\r\n suspect_domain,\r\n assessment.is_phishing,\r\n assessment.visual_discrepancies\r\nFROM (\r\n SELECT \r\n log_id,\r\n suspect_domain,\r\n AI.GENERATE(\r\n (\r\n "Compare these two web UI screenshots. The first is our official, trusted login page. The second is a suspected spoofed page. Identify any visual discrepancies, missing logos, or fake elements, and determine if it is a phishing attempt.", \r\n [OBJ.MAKE_REF(trusted_ui_uri),OBJ.MAKE_REF(suspect_ui_uri)]\r\n ),\r\n output_schema => \'is_phishing BOOLEAN, visual_discrepancies STRING\'\r\n ) AS assessment\r\n FROM \r\n cybersecurity.network_ui_logs\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93488cd390>)])]>

ObjectRef を使用して今すぐ分析を開始する

BigQuery ObjectRef は、BigQuery のすべてのエディションとオンデマンド料金ティアで一般提供されています。

現在 Cloud Storage ファイルで ML 推論を実行するためだけに断片化された複雑なインフラストラクチャを管理されているのなら、ぜひ統合を検討することをおすすめします。AI はストレージに直接組み込めます。既存のデータエンジニアリング手法を活用して、堅牢でスケーラブルかつ安全なマルチモーダル分析パイプラインを BigQuery 内に直接構築しましょう。

ObjectRef およびマルチモーダル分析のご利用を開始するには、以下のリソースをご覧ください。

ハンズオンチュートリアルで、合成データを使用して画像キャプションを生成し、商品カテゴリを割り当てる方法をご確認ください。
Cloud Next のライブデモで、非構造化データと構造化データの統合と、LLM を使用したテキストの生成とベクトル検索の実行をご覧ください。
BigQuery ドキュメントで ObjectRef の操作方法をご確認ください。

- エンジニアリングマネージャー、Guarav Soni

- プロダクトマネージャー、Jamy Su

Gemini のイノベーションで、ボーダーレス Lakehouse をエージェントの時代へ導く

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

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

企業が AI の利用を試験運用的な chatbot から自律型エージェントへと移行するにつれ、チームは重大なボトルネックに直面しています。それは、複数のクラウド、SaaS プラットフォーム、オンプレミスシステムに分散したデータへのアクセスと、そのデータに基づく推論です。AI エージェントを真の「アクションシステム」に変えるには、データ移動に伴うセキュリティリスクを負うことなく、ペタバイト規模の推論を処理できる基盤が必要です。先週開催された Gemini at Work イベントでは、Gemini がビジネスワークフローの変革にどのように役立つかをご紹介しました。皆様がエンタープライズデータを活用してエージェントを強化できるよう、Gemini とボーダーレス Lakehouse の新たな連携について詳しく解説し、データ資産全体にわたって機能するエージェントの構築、保護、スケーリングを支援します。

Gemini を通じて Google Cloud の外部にあるデータにアクセスする

ボーダーレス Lakehouse の真価は、Gemini をフロントドアとして組織を変革するために構築するエージェントを通じて発揮されます。Gemini との新たな連携により、事前構成されたデータやボーダーレス Lakehouse に保存されたデータを、Gemini に直接取り込んで活用できるようになりました。現在プレビュー版として提供されているこの機能により、Gemini から直接、Lakehouse カタログ連携を通じて Databricks Unity Catalog や Snowflake Horizon などの新しいデータソースへのアクセスを設定できるようになります。

これで、ビジネスユーザーは自然言語を使ってクラウド全体に分散して存在するレコードをクエリできるようになり、AI エージェントは同じデータを根拠として推論を行い、コードを生成できるようになりました。これらはすべて、データを移動することなく実行できます。ボーダーレス Lakehouse 全体にわたり AI エージェントに直接コンテキストを提供することで、重要な情報へのアクセスを簡素化しながら、組織の AI 導入を加速させることができます。

ビジネスユーザーが呼び出した Gemini エージェントは、BigQuery と Databricks Unity Catalog に格納されているデータにアクセスし、包括的なレポートを提供するとともに、自然言語を使用して分析情報を取得できます。

ボーダーレス Lakehouse の進化

このたび、Gemini との新しいネイティブ連携に加えて、ボーダーレス Lakehouse でデータ基盤を強化するために今年初めに導入したいくつかの機能の一般提供が開始されたことをお知らせします。

AWS および Azure 向けの Cross-Cloud Interconnect とクロスクラウドキャッシュのサポート
BigQuery での Apache Iceberg V3 仕様のサポート
BigQuery と Managed Service for Apache Spark の両方における Apache Iceberg テーブルの読み取り / 書き込みの相互運用性
Lakehouse ランタイム連携を使用した、AWS Glue、Databricks Unity Catalog、Snowflake Horizon カタログとの双方向キャッシュ
Knowledge Catalog とのインテグレーション
Salesforce、SAP、Workday、そして新たに Confluent Tableflow とのゼロコピーデータ統合
Dataflow を使用した Lakehouse コンソール経由での Databricks Delta Lake アセットの同期

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

ペタバイト規模のパフォーマンスと推論

エージェントのコンテキストウィンドウは通常、一度に取り込めるデータ量が数百キロバイトに制限されていますが、エンタープライズワークフローでは、複数のクラウドにわたりペタバイト規模のデータを結合することがあります。製品データや顧客データといったさまざまなソースのデータを、CRM クラウドやウェアハウスのテレメトリーと結合する必要があるエージェントネイティブなデータプラットフォームは、大規模なデータ処理が可能でなければなりません。MCP を使用してこれを行う場合、コンテキストウィンドウとペイロードサイズの制約により、処理の規模がメガバイト単位に制限されます。ボーダーレス Lakehouse は、データと AI スタックをあらゆるレイヤで連携させることで、エンタープライズグレードのスケーラビリティを提供します。これにより、エージェントはペタバイト規模のデータをローカルに保存されている場合と同様のパフォーマンスで推論できます。

ネットワーキングレイヤでは、Cross-Cloud Interconnect とクロスクラウドキャッシュにより、AWS と Azure への高スループット、低レイテンシのパスが提供され、変動する外向きデータ送信料金が不要になります。エージェントが Amazon や Azure Data Lake Storage の Iceberg テーブルを BigQuery のデータと結合すると、スキャンするキャッシュ保存されていないバイトがすべてクラウドの境界を越えるため、ネットワークにより処理速度が決まります。Cross-Cloud Interconnect は、Google Cloud と AWS または Azure の間に、1 接続あたり 10 Gbps または 100 Gbps の専用プライベート接続を Lakehouse に提供します。Lakehouse のクエリは、パブリックインターネットではなく、この接続を介して送信されるため、低レイテンシの予測可能な状態が維持されます。また、クロスクラウドキャッシュは、Google Cloud 内から繰り返し行われる読み取り処理に対応するため、エージェントは他のクラウドのデータを移行することなく直接クエリできます。

ボーダーレス Lakehouse には、Iceberg メタデータをクエリエンジンに統合するための重要な最適化がいくつか盛り込まれています。BigQuery で、バイナリ削除ベクトルや並べ替え順など、Apache Iceberg V3 仕様がサポートされるようになりました。これらの機能により、データファイル全体を書き換える必要がなくなるため、エンジンは行レベルの更新や削除をより効率的に処理できるようになります。また、BigQuery の実行エンジンをアップグレードし、新しい FlatBuffers ベースの Parquet リーダーと並列化された I/O を導入しました。これにより、CPU オーバーヘッドやシリアル化によるボトルネックを軽減し、オープンフォーマットとネイティブストレージのパフォーマンスの差を縮めました。

これは、エージェントのワークロードをサポートするように設計されたクエリエンジンの最近のパフォーマンスイノベーションに基づいています。エージェントのワークロードは一斉に大量発生することが多く、小規模なクエリを迅速かつ費用対効果の高い方法で処理することが求められます。BigQuery の流動的なスケーリングと履歴ベースの最適化により、Apache Iceberg とのオープン性を維持しながら、スケーラブルかつ効率的なエージェントワークロードを実行できます。

一方、BigQuery と Managed Service for Apache Spark の両方で Apache Iceberg テーブルの読み取り / 書き込みの相互運用性が確保されているため、すべてのデータチームが Google Cloud Storage 内の同じ Iceberg テーブルを簡単に利用できます。この垂直方向に最適化されたスタックは、BigQuery と Lightning Engine の力を活用してデータを移動することなく有効化し、エージェントの高速化と費用対効果の向上を実現します。Lakehouse の分析能力をさらに拡張するため、BigQuery の Iceberg 向けグラフ機能のサポートにより、サプライチェーンなどの関係ネットワークをオープンテーブルデータセットで直接分析できるようになりました。

エージェント向けの包括的なコンテキストとデータアクセス

AI エージェントの能力は、アクセスできるコンテキストに左右されます。ハルシネーションを防止し、メタデータレイヤの精度を向上させるために、ボーダーレス Lakehouse は Lakehouse ランタイムカタログを使用してエンタープライズデータを統合します。Apache Iceberg REST カタログをベースに、AWS Glue、Databricks Unity Catalog、Snowflake Horizon Catalog との双方向のカタログ連携を実現します。Lakehouse ランタイムカタログには、新たな標準の Hive Metastore 互換エンドポイントも含まれており、Apache Spark、Trino、Presto などのエンジンがアーキテクチャを変更することなくメタデータを参照できます。

ボーダーレス Lakehouse は、分散したデータアセットを自動的にインデックス化する Knowledge Catalog とも直接連携しており、エージェントがエンタープライズコーパス全体（Cloud Storage 内の非構造化データを含む）を推論するために必要な、正確なビジネスメタデータとセマンティック定義を提供します。これにより、エージェントはトークン費用を抑えながら、正確性を確保するのに十分なコンテキストを得られるため、インテリジェントで持続可能なエージェント活用戦略を策定できます。

ボーダーレス Lakehouse は、Salesforce、SAP、Workday などの SaaS アプリケーションとのゼロコピーデータ統合を実現し、より広範なパートナーエコシステムと連携することにより、Knowledge Catalog を通じてエンタープライズデータをキャプチャし、エージェントのための単一のコンテキストエンジンとして機能します。このたび Google は、パートナーエコシステムを拡大し、Confluent Tableflow との新たな連携機能の一般提供を開始しました。これにより、Lakehouse ランタイムカタログと同期され、生成された Iceberg テーブルが BigQuery に直接表示されるようになります。コピーや追加の ETL は不要です。

最後に、Databricks 中心のリポジトリを持つ組織は、Lakehouse コンソール経由で Dataflow を使用して、Delta Lake アセットを Lakehouse に簡単にインポート、変換、同期できるようになりました。

モダナイゼーションを容易に

2025 年初頭以降、Apache Iceberg の利用は 3 倍以上に増加しており、Google Cloud のボーダーレス Lakehouse を使用してデータ基盤を構築している企業は、大きな成果を上げています。

Etsy: ボーダーレス Lakehouse を活用して、3 ペタバイトのデータを統合し、データを移動させずに結合することで、パイプラインクエリを 60% 高速化しました。
Commerzbank: 分散している生データを、ガバナンス管理されたエージェントがすぐにアクセスできるデータへと変換しています。
Hightouch: ボーダーレス Lakehouse と直接連携しているため、チームはオープンな Iceberg Lakehouse 上で直接マーケティング活動を強化し、Google Cloud エコシステム全体でそのデータを活用できます。
Roundel: ボーダーレス Lakehouse を活用して Target Product Ads の技術スタックを徹底的にモダナイズし、データの取り込み、処理、測定のパイプラインを完全に再構築しました。

組織でボーダーレス Lakehouse に移行する準備ができているなら、そのプロセスは難しくありません。現在、従来の Dataproc Metastore をご利用中の組織向けに、サーバーレス Lakehouse ランタイムカタログへの自動化されたダウンタイムゼロの移行パスが用意されています。これにより、既存のスキーマやリネージを維持したまま、ボーダーレス Lakehouse の AI 対応機能を活用できるようになります。その結果、インフラストラクチャの管理から解放され、エージェントの活用に注力できるようになります。

ボーダーレス Lakehouse 構築の Codelab を今すぐお試しください。詳細については、Google のウェブサイトをご覧ください。

- プロダクトマネジメント担当ディレクター、Gaurav Saxena

- エンジニアリング担当ディレクター、Ahmet Altay

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

概要

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

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

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

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

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

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

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

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

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

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

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

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

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

出力について

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

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

BigQuery 会話型分析の TimesFM 3.0

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

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

まとめと次のステップ

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

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

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

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

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

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

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

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

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

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

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

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

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

詳細:

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

対象となる関数

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

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

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

割り当ての管理

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

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

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

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

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

次の操作を行います。

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

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

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

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

使用量のモニタリング

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

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

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

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

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

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

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

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

適用の仕組み

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

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

Looker を活用した Agentic Data Cloud 向けの信頼できるデータアプリ

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

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

ビジネスインテリジェンスユーザーの皆様なら、このような状況に心当たりがあるのではないでしょうか。ほとんどのダッシュボードは標準化されたキャンバスと決められたグラフライブラリしか提供しておらず、「分析」といえば CSV をエクスポートして別のシステムへ持っていく作業に過ぎない、というケースです。あるいは、ダッシュボードのデザイン自体が課題となる場合もあります。エグゼクティブブリーフィング、顧客向けポータル、インタラクティブな説明コンテンツなどの理想像は頭にあっても、用意されているグリッドタイルだけではそれを具現化できない、というケースです。

いずれにしても、これまでの解決策はカスタムアプリケーションを構築することでした。AI の登場によりこのプロセスは加速し、今や動作するプロトタイプなら半日で作れるようになりました。しかし、最初のデモで味わう興奮はすぐに冷めてしまいます。ガバナンスの効いたデータ、行レベルのセキュリティ、インフラストラクチャの責任者、そして明確なセキュリティレビューのプロセスがなければ、LLM によって生成されたツールは、本番環境に移行できない単なるプロトタイプに過ぎません。

このギャップを埋めるため、このたび Looker Data Apps（プレビュー版）を発表いたしました。これは、エージェント生成アプリケーションのスピード感と、既存の Looker フレームワークが持つガバナンス、セキュリティ、信頼性を兼ね備えたソリューションです。必要なものを平易な言葉で説明するだけで、エージェントが Looker 内でネイティブにホストされる、本番環境グレードの本格的なアプリケーションを構築します。

データアプリとは

データアプリとは、AI エージェントによって生成され、Looker 内でネイティブにホストされる、カスタムメイドのインタラクティブなウェブアプリケーションです。ダッシュボードがトップダウンでの可視性を提供するのに対し、データアプリは特定の業務ワークフローに沿って設計された、直接アクションを起こせるシステムとして機能します。データアプリには、次のような特長があります。

標準的なグリッドタイルの枠を超え、特定の業務役割や具体的なジョブに合わせて構成された、ピクセルパーフェクトなカスタムレイアウトを実現します。
ビジネスユーザーがパラメータの入力、シナリオのテスト、ライブシミュレーションの実行、さらには基盤データの更新までを行えるようにします。
データ分析を、ソースレコードの更新やツール（Salesforce や Jira など）へのイベント送信といった業務実行タスクと直接連動させ、エンドツーエンドのビジネスプロセスを統合します。

Looker のセマンティックレイヤに直接グラウンディングされた Claude Code や Antigravity CLI などの AI デベロッパーツールを活用し、ピクセルパーフェクトなインターフェースを構築できます。

セマンティックレイヤをアプリケーションプラットフォームへ拡張

データアプリはダッシュボードを置き換えるものではなく、既存のダッシュボードやセマンティックレイヤの上に構築できる「可能性」をさらに広げるものです。

ダッシュボードが得意とするのは、集計データの可視化や受動的なレポート作成です。データアプリは能動的な業務実行に対応しており、ユーザーがパラメータを変更して後続のビジネスタスクを実行できるようにします。
ダッシュボードは、標準化されたグラフライブラリによって一貫性をもたらします。一方、データアプリは高い柔軟性を備えており、カスタムウェブコンポーネントや特有のインタラクションを実現できます。
データアプリは正確性を担保するため、ガバナンスの効いたデータに基づいています。ユーザーが KPI ダッシュボードで数値を確認するときも、データアプリで予算を調整するときも、すべてのロジックは LookML セマンティックレイヤで一元管理されます。そのため、指標の不一致やハルシネーションを排除できます。

カスタマイズ可能なマルチページのウェブアプリエクスペリエンスと組み込みの運用ワークフローにより、分析をアクションに変換します。

エンタープライズ規模に対応

Looker Data Apps は、高度な要件と厳格なガバナンスが求められる企業向けに設計されています。

すべてのメジャーがセマンティックレイヤに基づく設計。構築したすべてのアプリは、既存のセマンティックモデルや行レベルのセキュリティ、アクセス制御をそのまま継承します。社内全体で計算の一貫性が維持されるほか、組み込みのクエリ検査機能により、チームは生成された SQL を 1 行ずつ監査して指標のハルシネーションを排除できます。
デフォルトでノーコード。エージェントが生成した React アプリケーションを、コードを書くことなく Looker 内に直接デプロイできます。また、Claude Code や Antigravity CLI などの LLM ツールを活用してインタラクティブなアプリを構築し、わずか数分でデータアプリとしてデプロイすることも可能です。
ランタイムトークンの費用は不要。LLM トークンが消費されるのは、アプリの設計や生成のときだけです。一度作成すれば、エンドユーザー操作はすべて、ネイティブな Looker API とモデルで実行されます。データアプリを利用するユーザーが 50 人でも 5,000 人でも、追加コストは発生しません。
ダッシュボードの埋め込みと同じくらい簡単。ダッシュボードを埋め込む際と同じワークフローで、データアプリを外部ポータルにデプロイできます。新しいパイプラインも、カスタムアプリケーションコードも、2 つ目の権限モデルも必要ありません。

プロトタイプから本番環境までわずか数分

基本的なダッシュボードで我慢するか、貴重なエンジニアリング時間を費やしてカスタムシステムを構築するか、どちらかを選ぶ必要はもうありません。コンプライアンスやセキュリティの障壁によってプロトタイプがサンドボックス内でとん挫することはありません。Looker Data Apps を使えば、ガバナンスの効いた本番環境グレードのツールをわずか数分でデプロイできます。

Looker Data Apps は現在プレビュー版でご利用いただけます。ぜひ実際にお試しください。

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

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

Apache Iceberg を自動管理して大規模展開する: Spanner を活用した Lakehouse ランタイムカタログ

Wed, 14 Oct 2026 02:35:00 +0000

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

企業がレイクハウスアーキテクチャへとモダナイズを進めるなかで、Apache Iceberg などのオープンフォーマットに準拠した共有データ資産を作成し、複数のエンジンで使用できるようにするという動きが広がっています。このように、AI ネイティブなレイクハウスを構築すれば、データをセマンティックな知識に変換したり、プロアクティブにアクションを実行したりするなど、エージェントの規模での運用が可能となります。

レイクハウスの主要コンポーネントの一つはカタログであり、Apache Iceberg 環境では通常、Iceberg REST カタログがこれに該当します。Apache Iceberg カタログは、テーブルポインタの維持や、アトミックコミットの処理といった役割を担うほか、テーブルの場所に関する信頼できる唯一の情報源となります。しかし、大規模なエンタープライズがレイクハウスへとモダナイズするにしたがって、スケーラビリティと可用性を備えたマネージドカタログがレイクハウスアーキテクチャの一部として必要であるという認識が生まれつつあります。エージェントによるクエリの量が増えるにつれて、この重要性はさらに増していきます。エージェントが繰り返し実行する大量の細かなクエリに対応するために、基盤のマネージドカタログには、アトミック性、整合性、可用性、同時実行性を大規模なスケールで提供する能力が求められます。

このブログ投稿では、エージェント規模へと広がる最新のクラウド環境においてマネージドカタログが直面する課題を考察するとともに、Google Cloud のサーバーレスの Lakehouse ランタイムカタログがこうした課題の解決にどのように役立つかについて説明します。Lakehouse ランタイムカタログは、Google Cloud の常時稼働データベースである Spanner（実質的に無制限で拡張可能）を基盤とし、オープンな Apache Iceberg REST カタログ仕様に準拠しています。これにより、エージェントの時代に必要なスケーラビリティと可用性を提供する基盤となります。

レイクハウスのマネージドカタログが直面する課題

データエンジニアやインフラストラクチャ責任者の方々に話を伺うと、レイクハウスで大規模に本番環境の分析を行うことに関して、以下のような共通した課題を抱えています。これらはすべて、マネージドカタログにおいて解決すべきものです。

アトミックコミットと同時実行制御: Iceberg は、オプティミスティック同時実行制御（OCC）により、ACID トランザクションを保証しています。したがって、マネージドカタログに強固なアトミック比較交換（CAS）オペレーションを実装し、現在のメタデータポインタをスワップする必要があります。

高可用性と運用保守: カタログがダウンすると、クエリはその瞬間からエラーとなります。そのため、マネージドカタログは最重要な Tier-1 サービスに位置付けられます。

カタログを支えるデータベースのスケーリング: カタログの設計者は往々にして、テーブルのメタデータおよび状態の保存用データベースの選択において、難しいジレンマに陥ります。従来のスケールアップ型のリレーショナルデータベースは SQL に対応しており、ACID トランザクションを提供しますが、読み取り / 書き込みの同時実行処理が増えると、CPU、メモリ、ストレージ、接続数が垂直方向の限界に達します。これを回避するには、手動でのシャーディングが必要となりますが、その場合は、運用上のオーバーヘッドが膨大になります。一方、スケールアウト型のデータベースシステムは、即時整合性が得られない、管理が困難、エンタープライズに対応できない、といった問題があります。

テーブルのメンテナンス作業: カタログは、データの最適化まではしてくれません。人間の担当者が、データの圧縮、古いスナップショットの消去、マニフェストの書き換え、孤立ファイルのクリーンアップといった補助パイプラインを構築して運用する必要があります。

ガバナンスとセキュリティ: カタログは、セキュリティの門番として、以下を実装して維持することが求められます。

認証プロトコル（OAuth2 トークン交換、IAM 連携など）
名前空間からテーブルレベルまでのアクセス制御
一時的なストレージ認証情報（例: クエリエンジンに対して、広範なストレージに直接アクセスできる認証情報ではなく、有効期間の短いトークンを生成する）

Lakehouse ランタイムカタログ

これらの課題を解決するために、Google は Iceberg REST カタログをサポートする Lakehouse ランタイムカタログ（一般提供）を構築しました。Lakehouse ランタイムカタログは、高可用性を備えた完全にサーバーレスな統合メタデータレジストリであり、Apache Iceberg などの最新のオープンなテーブルフォーマットをサポートするようにゼロから設計されています。 Lakehouse ランタイムカタログでは、Apache Iceberg REST カタログ仕様をネイティブに実装することで、メタデータ検出をコンピューティングエンジンから分離しています。これにより、複数の Iceberg 互換エンジンが共有データ資産にアクセスできるようになり、ワークロードを迅速に本番環境に移すことが可能となります。Google はすでに、多くのお客様がマネージドカタログの移行をスムーズに行えるよう支援してきました。たとえば、Etsy は Lakehouse ランタイムカタログへと移行し、データを動かさずに結合することで、パイプラインクエリを 60% 高速化しています。

このアプローチには、アーキテクチャ上のメリットが以下のように多数あります。

オープン API: Iceberg REST カタログがサポートされているため、ユーザーは単一の統合データセットに対してさまざまな分析ツールを自由に使用できます。
マルチエンジンの相互運用性: 登録されたテーブルは、標準の REST インターフェースを介して、Google Cloud Managed Service for Apache Spark、BigQuery、オープンソースエンジンで即座に検出やクエリが可能になります。
Iceberg テーブルの読み取り / 書き込みの相互運用性: BigQuery、Managed Spark などの Iceberg 互換エンジンを使用して、Lakehouse ランタイムカタログに登録されている Iceberg テーブルに書き込めます。また、Managed Spark を使用して、外部カタログの Iceberg テーブルに書き込むこともできます。
エンタープライズグレードの機能を備えたフルマネージドの Iceberg ストレージ: Google 独自のインフラストラクチャを使用し、Iceberg テーブルでパフォーマンスの高い分析を実行できます。これにより、オープンソースの柔軟性に加え、パフォーマンス、スケーリング、ガバナンス、マルチモーダル処理のメリットが得られます。
データコピー不要: テーブル定義は、基盤となるオブジェクトストアの既存データを直接参照します。基盤となるデータの移動、書き換え、複製を行う必要はありません。
クラウド間の双方向のカタログ連携: 一時的な認証情報と OIDC トークン交換がサポートされており、Databricks Unity、Snowflake Horizon、AWS Glue のデータにアクセスできます。これにより、Google AI を AWS や Azure のデータに直接適用することが可能です。
一時的な認証情報によるセキュアなアクセス: カタログは複数の認可メカニズムに対応しており、一時的な認証情報とエンドユーザー認証情報のいずれかを選択できます。そのため、一時的な認証情報などの最新方式を使って、基盤となるオブジェクトストア（Cloud Storage、AWS S3、Azure Blob Storage）内のファイルに直接アクセスすることなく、テーブルにアクセスすることが可能です。
AI を活用したコンテキストとガバナンス: Lakehouse ランタイムカタログは、Knowledge Catalog および Cloud IAM と直接統合されているため、エージェント用の信頼できるコンテキストを定義したり、すべてのコンピューティングエンジンにテーブルレベルのセキュリティを一貫して適用したりできます。また、カタログ内の Iceberg テーブルの検索や、リネージや分析情報の取得にあらかじめ対応しています。
アトミックコミットによる同時実行制御、高可用性、スケーラビリティ: Google の地球規模のインフラストラクチャと Spanner を基盤としたアーキテクチャによって、データに合わせてメタデータをスケールするために必要な高可用性、同時実行性、スケーラビリティが得られます。たとえば、Cloud Storage のデュアルリージョンバケットとマルチリージョンバケットのサポートにより、フェイルオーバーのユースケースに対応できます。また、サーバーレスな NoOps 環境によって TCO 削減につながるほか、あらゆるサイズのワークロードに対応可能なスケーラビリティを得られます。

Lakehouse ランタイムカタログの原動力

Lakehouse ランタイムカタログは Spanner 上に構築されているため、高可用性、同時実行性、スケーラビリティに優れているのに加えて、強整合性が保証されています。従来のスケールアップ型のリレーショナルデータベースが、単一ノード内で垂直方向の限界に達するのに対し、Spanner は、読み取りと書き込みの両方で水平方向にスケールアウトできるという NoSQL システムならではの柔軟性に加え、完全なリレーショナル SQL のセマンティクス、複数テーブルでの ACID トランザクションというメリットを提供します。

Spanner のリージョン構成では最大 99.99% の可用性が得られ、Lakehouse ランタイムカタログにおいて高可用性を実現できます。さらに、Spanner が自動的なスケーラビリティを Lakehouse ランタイムカタログに提供します。Spanner は水平方向にスケーラブルなデータベースであるため、手動でのシェーディングは必要なく、コンピューティングおよびストレージのリソースが自動的かつ透過的にスケールされます。具体的には、Spanner がデータ量とクエリ負荷を動的にモニタリングし、データ範囲を分割して、ノード間で再分配します。コンピューティングノードは、CPU 使用率とストレージのしきい値に基づいて、動的にスケールされます。また、スプリットレベルで過負荷を自動検出し、過負荷状態のノードから重いスプリットを移動します。また、Spanner によって、「リレーショナルの整合性」と「分散によるスケーラビリティ」の間の従来のトレードオフが解消され、Lakehouse ランタイムカタログのユーザーは業界最高水準の整合性保証を享受できます。Lakehouse のトランザクションはシリアル化されており、データベース内のトランザクションの順序は、クライアント側でトランザクションのコミットが観察される順序と一致します。この基盤によって、Lakehouse ユーザーは、エージェント規模での運用を実現できます。

さらに、エージェントユースケースへの対応を強化するため、Lakehouse ランタイムカタログは Knowledge Catalog と直接統合されており、レイクハウス内の Iceberg テーブルを簡単に検出して、信頼できるコンテキストをエージェントに提供することができます。Spanner が提供する全文検索とネイティブのベクトル検索という効率的な組み合わせを Knowledge Catalog で活用して、単一のクエリ内で語彙キーワード検索とセマンティックエンベディングを併用し、検索の再現率を高められます。これらの 2 種類のインデックスタイプは同じベースデータセット上に構築されており、ベーステーブルが DML で操作されると、トランザクションの ACID 整合性を厳密に保ちながらインデックスが更新されます。そのため、運用上のオーバーヘッド、たとえば、同期パイプライン、外部ベクトル、全文検索システムの管理といった作業が発生しません。簡潔に言うと、Lakehouse ランタイムカタログを使用すると、エージェントのユースケースを迅速に市場に投入することが可能となります。

分析と運用のワークロードを組み合わせる

Apache Iceberg をベースにした、Google Cloud のボーダーレスな Lakehouse なら、分析データを運用ワークロードと組み合わせることができます。ユースケースとしては、Lakehouse のデータアセットと Spanner からの OLTP データを組み合わせて分析を実行する、Spanner やその他の運用データベースからレイクハウスのアセットにアクセスして低レイテンシのアプリケーションを実現する、ファーストパーティおよびサードパーティのエージェントで会話型分析を行う、など多岐にわたるものがあります。

Lakehouse ランタイムカタログと Spanner の動作の例を以下に示します。この例では、マンハッタンのタクシー運行に関する分析データ（Apache Iceberg）と、タクシーのゾーンに関する運用データ（Spanner）を組み合わせて、最も混雑している交通経路を特定しています。さらに、会話型分析エージェントを使ってこの同じデータにアクセスし、二次的な分析情報を取得しています。

マンハッタンで最も混雑している交通ルートを調べる

ボーダーレスな Lakehouse にモダナイズ

Google Cloud の Lakehouse にモダナイズすることによって、分析エンジンやエージェント間のデータサイロを最小限に抑える、マルチエンジンのガバナンスを統合する、信頼できるコンテキストをエージェントに提供する、運用コストを大幅に削減する、といったメリットが得られます。Spanner ベースの Lakehouse ランタイムカタログを活用し、最新のクラウド環境をエージェント規模で運用する基盤を整えましょう。詳細および無料トライアルについては、

Lakehouse のウェブページをご覧ください。Spanner の詳細についてはこちらをご覧ください。

- プロダクトマネージャー、Vinod Ramachandran

- ソフトウェアエンジニアリングマネージャー Mina Mikhail

地理空間コーディングを加速する Google Earth Engine の新機能「Ask」のご紹介

Fri, 09 Oct 2026 00:10:00 +0000

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

Google Earth Engine では、スクリプトを記述することで、地球全体の森林面積を確認したり、建造環境の変化を検出したり、農作物の収穫量をモニタリングしたりでき、分析情報を得るための強力なツールとなります。Google Earth Engine は、地理空間モデルとデータセットのコレクションである Google Earth AI の一部を構成するプラットフォームです。Google Earth AI によって、地球規模の情報を実用的なインテリジェンスに変換することができます。この地球規模のインテリジェンスにさらに簡単にアクセスできるよう、このたび、新しい質問機能「Ask」を導入しました。

複雑な地理空間ロジックをコードに変換するのには、時間がかかります。また、特定の Google Earth Engine API 関数を記憶したり、ドキュメントを検索したり、構文エラーやメモリ不足エラーをデバッグしたりすると、作業の流れが中断されることがあります。「Ask」は、Gemini の機能を Google Earth Engine コードエディタに直接統合することで、行動につながるインサイトをより迅速に取得できるように設計されています。

早速、本日からでも、コードエディタから直接「Ask」を利用して、地理空間クエリの作成、デバッグ、理解、最適化に活用しましょう。

図 1: コードエディタの右側に新しい [Ask] パネルがあり、作業中のスクリプトに沿ってチャットベースの AI アシスタンスを利用できます。

仕組み: コンテキストアウェアなアシスタント

コードエディタで直接質問すると、以下のようなワークスペースのコンテキストに基づいて、回答が表示されます。

作業中のスクリプト全文
インポートしたアセットとジオメトリ
進行中のセッションのチャット履歴

Gemini in Google Earth Engine は、ユーザーの作業を自動的に理解するため、質問にコードを追加したり、データセットを説明したりする必要はありません。Gemini はこれらの詳細をすでに把握しており、より関連性の高い、有益な回答を提供します。さらに、Gemini が提示したスクリプトとの差分を自動表示して自分のスクリプトにマージすることもでき、コピーして貼り付ける必要はありません。

また、「Ask」をパーソナライズして、より包括的でニーズに合った回答を得ることもできます。たとえば、以下のことを実現できます。

最新の Gemini モデルにアクセス: ニーズに合った Gemini モデルを選択できます。現在、利用可能なモデルは、Gemini 3 Flash プレビュー版、Gemini 3.1 Pro プレビュー版、Gemini 3.5 Flash です。
ドキュメント検索: AI を使用して、公式ドキュメントから最新の構文と関数を検索できます。
データセット検索: AI による Earth Engine Data Catalog の検索を可能にして、必要なデータセットを確実に見つけて参照できます。
Google 検索: Google 検索によるグラウンディングで、最新の公開ウェブ検索の結果で回答をグラウンディングします（ドキュメント検索およびデータセット検索とは併用できません）。

活用方法の例

どのように利用を開始したらよいかわからない場合は、ワークフローで Ask を使用する 4 つの方法を以下に紹介しますので、参考にしてください。

1. 自然言語からコードを生成する

NDVI（正規化植生指標）を計算したり、雲マスクを実行したり、グラフを作成したりしたいのに、正確な構文を思い出せないことはありませんか。そのような場合は、Ask にリクエストするだけで、Earth Engine が JavaScript コードを生成してくれます。チャットでコードを直接確認し、[挿入] をクリックしてスクリプトに追加するか、[コピー] をクリックしてクリップボードにコピーできます。エディタですでにコードの下書きを記述中の場合、チャットからコードを挿入すると、変更を適用する前に違いを確認できるよう、差分が並列表示されます。

プロンプトの例: 「2025 年のコロラド州ボルダーの Sentinel-2 画像を読み込み、雲マスクを適用して NDVI を計算し、中央値合成を地図に追加するスクリプトを記述してください。」

2. 複雑なコードを解説させる

同僚が作成したスクリプトを扱う場合や、コミュニティからのサンプルを応用する場合は、Gemini の機能を使用して構成やロジックを解説してもらうことができます。「このスクリプトの動作を説明してください」と尋ねるだけで、使用されているロジックと Earth Engine 関数の詳細な説明が得られます。

3. ワンクリックでトラブルシューティングとデバッグを実行する

デバッグはコーディングに不可欠なプロセスです。Google Earth Engine でスクリプトにエラーが生じると、コンソールにエラーメッセージが表示されます。このメッセージに [トラブルシューティング] ボタンが追加されました。クリックすると、エラーメッセージを引用しながら問題の診断と修正案を求めるプロンプトが [Ask] パネルに自動的に入力されます。

図 2: コンソールの [トラブルシューティング] ボタンを使用すると、エラーのデバッグを迅速かつスムーズに実施できます。

4. クエリを最適化する

たとえば、スクリプトの実行速度が遅い、リソースの消費効率が悪い、「計算がタイムアウトしました」や「同時集計が多すぎます」というエラーが発生するなどの場合は、最適化のヒントを求めましょう。Gemini には、早期のフィルタリングや計算ステップの削減、あるいはクライアントサイドのループをサーバーサイドでの処理に変換するなどのベストプラクティスを提案する機能があります。

利用を開始するための 2 ステップ

Ask は現在、世界中でご利用いただけます。Gemini API キーがあれば、すぐに利用を開始できます。

API キーを取得する: Gemini API キーをまだお持ちでない場合は、Google AI Studio にアクセスして作成してください（無料オプションがあります。有料プランの API キーを選択した場合は、使用量に応じて課金されます）。詳しくは、Gemini API の利用規約をご覧ください。
API キーを Google Earth Engine に追加する: Google Earth Engine コードエディタを開き、右側のパネルで、[Ask] パネルをクリックしてください。左下隅にある鍵アイコンをクリックして、API キーを入力します。

ご意見、ご感想をお聞かせください。コードエディタの [フィードバック] ボタンを使用してフィードバックをお寄せいただければ幸いです。エクスペリエンスの向上にご協力のほどよろしくお願いいたします。

- プロダクトリード、Joel Conkling

- ソフトウェアエンジニア、Katie Friis

分析の高速化: PayPal の Managed Service for Apache Spark 導入事例

Thu, 08 Oct 2026 02:00:00 +0000

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

データドリブンな世界において、PayPal が優位性を維持するためには、タイムリーで実用的な分析情報を提供できる機能が不可欠です。PayPal では、不正行為の検出からユーザーエクスペリエンスの向上まで、あらゆる場面でデータを活用しています。データは、エージェントソリューションとエクスペリエンスの可能性を引き出すためにも中心的な役割を果たします。

しかし、当社の分析環境は、増大し続ける需要に対応していくうちに、時間の経過とともに、さまざまなテクノロジーとソリューションをオンプレミスで組み合わせた複雑なエコシステムになっていました。このアプローチでその時点でのニーズに対応することはできましたが、スケーリングとメンテナンスの面で新たな課題が生じ始めました。

困難な分析環境を乗り切る

急激な成長と買収により、当社のデータ分析プラットフォームは徐々に不均一な状態になっていきました。新しいプラットフォームや統合の導入により特定のビジネスニーズには対応できましたが、それらが組み合わさることで、運用上のオーバーヘッドが増加し、パフォーマンスのボトルネックが生じていました。スケーリングがますます困難になり、プロセスが複雑になるにつれて分析情報を得るまでの時間が長くなりました。

複雑さにより生じた停滞

PayPal の従来のデータ分析プラットフォームは、毎日ペタバイト規模のデータを処理する強力なものでしたが、急速な成長に伴い、柔軟性が失われていきました。小売業のピークイベントやグローバルなリリース時にスケールアップするには、数か月にわたる計画と時間のかかるハードウェアの手動プロビジョニングが必要であり、多くの場合、スピードとコストの間で妥協を余儀なくされていました。

PayPal がグローバルに拡大を続けるなか、データの効率性を高め、イノベーションを加速させるために、合理化された統合インフラストラクチャが必要であると認識しました。

ソリューション: 統合されたクラウドネイティブな分析

これらの問題を克服するために、分析ワークロードを従来の Hadoop オンプレミスプラットフォームから Google の Managed Service for Apache Spark に移行しました。

この選択の主な理由は次のとおりです。

迅速なプロビジョニングと柔軟なスケーリング: Managed Spark により、クラスタを数分でデプロイし、処理ニーズに応じてスケーリングできるようになったため、時間のかかる設定やアイドル状態のリソースのコストが排除されました。
統合されたインフラストラクチャ: Apache Spark に標準化することでチーム間に一貫性が生まれ、Managed Service for Apache Spark やその他のマネージドサービスを活用することで運用の複雑さが軽減されました。
シームレスな統合: Google Cloud Storage（GCS）、BigQuery、その他の Google Cloud サービスへのネイティブフックにより、エンドツーエンドのデータ移動が効率化されました。

PayPal は、この移行により、クラウドネイティブソリューションの柔軟性、スケーラビリティ、信頼性を活用して、データ処理機能をモダナイズできました。以前は複数のプラットフォームでばらばらに実行されていたワークフローとバッチジョブを、単一のクラウドベースの分析プラットフォームに統合することで、データサイロを削減し、より迅速で豊富な分析情報を提供する統合データ基盤を構築しました。

これにより、開発者とアプリケーションチームは、インフラストラクチャに制限されることなく、ビジネス価値を創出することに集中できるようになりました。重要なのは、この移行が単なるプラットフォームの再構築にとどまらなかったことです。新しい実験の文化を育成し、変化するビジネスニーズに応じて、チームが分析ワークロードを迅速にテスト、調整、デプロイできるようにしました。

結果: 分析情報の迅速な取得、オーバーヘッドの低減

Managed Spark を活用した最新の Google Cloud ベースのエコシステムは、大きな効果をもたらしました。

コア分析ワークロードの処理時間が 25% 短縮され、主要なビジネスオペレーションに関する分析情報をほぼリアルタイムで取得できるようになりました。
季節限定のセールイベントなど、トラフィックが急増する期間でも、SLA の遵守率が 30% 向上しました。
ツールの統合と手動メンテナンスの削減により、運用コストが低下しました。

しかし、おそらく最も重要な改善点は、エンジニアが問題対応に費やす時間が減り、イノベーションに費やす時間が増えたことです。これにより、顧客やパートナーに価値をもたらす新しい分析機能を迅速にプロトタイピングできるようになりました。

断片化された環境から、一貫性のあるクラウドネイティブなプラットフォームに移行したことで、PayPal の分析機能は根本から強化されました。ビジネスニーズが進化するなか、スケーラブルで統合されたデータ基盤に投資することで、迅速かつ正確で、有益な分析情報を提供できるようになり、世界中のお客様に継続的なイノベーションをもたらすことができます。Managed Service for Apache Spark の導入は、最新の分析基盤を構築するうえで重要なステップでした。

Managed Service for Apache Spark と BigQuery を使用して、Agentic Data Cloud を構築する方法を今すぐご確認ください。

- PayPal、分析信頼性エンジニアリング担当ディレクター、Vinod Ganesan 氏

- PayPal、ビッグデータプラットフォームエンジニアリング担当シニアマネージャー、Raghu Agani 氏

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ML レイヤ: Distributed Graph Flow（DGF）

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

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

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

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

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

ユースケース

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

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

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

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

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

使ってみる

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

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

Dataflow での一時停止 / 再開と NVIDIA RTX PRO 6000 Blackwell GPU のサポートを発表

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

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

概要

企業は AI とエージェントワークフローを拡大するにつれて、モデルのトレーニング、評価、推論のためのデータ準備を簡単かつ効率的に行えるサーバーレスプラットフォームが必要になります。Dataflow は、Google Cloud による AI スタックにおける重要なコンポーネントです。Dataflow を使用すると、さまざまな分析や AI のユースケースを支援するバッチパイプラインとストリーミングパイプラインを作成できます。

このたび、Dataflow に大幅な機能強化が施されました。これにより、長時間実行されるバッチジョブのコンピューティング効率を最大化し、最も要求の厳しい AI ワークロードにさらなる推論能力を提供するという、お客様の最大の課題に直接対応できるようになりました。その一環として、このたび、Dataflow バッチジョブの一時停止 / 再開機能の一般提供を開始し、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載した G4 VM のサポートを開始したことをお知らせいたします。これらの機能により、AI 開発ライフサイクルを加速し、コストを最適化できます。

Dataflow バッチジョブの一時停止 / 再開機能で無駄なコンピューティングを削減し、デベロッパーの生産性を向上

Dataflow のお客様は、大規模なバッチワークロードを頻繁に実行しており、場合によっては数日間実行されることもあります。これらのジョブが失敗すると、Dataflow ユーザーは現在、ジョブが失敗する前にすでに処理されていたデータにアクセスできなくなります。代わりに、ジョブ全体を再試行する必要があるため、コンピューティングリソースが無駄になり、エンジニアリングの生産性が低下してしまいます。

大規模なジョブの障害に対処するだけでなく、AI ワークロードを抱える Dataflow のお客様は、すでに実行されている優先度の低い Dataflow バッチジョブから、特徴量エンジニアリングや AI 推論などの優先度の高いワークロードに GPU や TPU などのアクセラレーテッドコンピューティングリソースを動的に再割り当てすることで、それらのリソースの使用率を高めたいと考えることがあります。

こうしたユースケースをより適切にサポートするために、Dataflow バッチジョブの一時停止 / 再開機能の一般提供を開始します。Google 内部のイノベーションを活用したこの機能により、Dataflow のお客様は、失敗した長時間実行ジョブを最初からやり直すのではなく、再開できるようになります。また、お客様はそれぞれのビジネス要件に基づいて Dataflow バッチジョブを一時停止、再開することもできます。

詳細については、Dataflow ジョブを手動で一時停止するをご覧ください。

NVIDIA RTX PRO 6000 GPU で AI 推論ワークロードを高速化

Dataflow はすでに、AI 推論ワークロードを高速化するための幅広い GPU と TPU をサポートしていますが、さらに一歩進めて、NVIDIA RTX PRO 6000 Blackwell GPU を搭載した G4 VM のサポートを発表します。

NVIDIA RTX PRO 6000 Blackwell GPU は、NVIDIA L4 GPU と比べて大幅な性能向上を実現しており、96 GB の vGPU メモリと 1.6 TB/秒の帯域幅を提供します。つまり、最大 700 億以上のパラメータを持つモデルを使用して、Dataflow ジョブ内で直接 AI 推論を実行できるということです。これは、RunInference、Right Fitting、GPU 対応の自動スケーリングなどのネイティブ Dataflow ML 機能を継続して利用しながら行うことができます。これらの機能により、基盤となるインフラストラクチャを管理したり、チューニングや自動スケーリングなどの難しい問題に手動で対処したりすることなく、AI 推論ジョブを簡単にオンボーディングしてスケールできます。

次のステップ

一時停止 / 再開機能と RTX PRO 6000 Blackwell GPU を組み合わせることで、要求の厳しい AI ワークロードを実行しながら、バッチジョブのコストを最適化できます。Google は、Dataflow の機能とお客様にもたらされる可能性に大きな期待を寄せています。今すぐ Dataflow の使用を開始し、これらの機能を活用して、AI の最も困難な課題を解決しましょう。皆様が構築されるサービスを楽しみにしております。

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

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

Data Agent Kit でエージェントを駆使した問題分析

Fri, 18 Sep 2026 01:00:00 +0000

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

想像してみてください。月曜の朝、出社早々、上司からチャットメッセージが入ります。曰く、「1 月の平均注文額は 7% 減だけど、総収益は横ばいだね。なんでかな？」

データ実務者であれば、このような質問が一筋縄ではいかないことは、よくご存じなのではないでしょうか。しかも、答えは単純明快ではありません。根本原因を示す単一のダッシュボードがあるわけでもありません。ウェブのログにエラーが記録されているのか。プロモーションコードの設定に誤りがあったのか。深掘りするまで皆目見当がつかないし、1 か所や 2 か所、調べただけでは答えはまず見つからないでしょう。

答えにつながる鍵は、環境内のさまざまな領域に散在しています。

販売履歴（注文と明細項目）はデータウェアハウスに保存されています。
有効な顧客レコードは本番環境の PostgreSQL インスタンスに保存されています。
マーケティングキャンペーンルールは、オブジェクトストア内の未加工 JSON ファイルに保存されています。

これらの情報を引き出すクエリを 1 つだけ作成するなら簡単です。実際には、同じクエリを何度も記述し、WHERE 句を調整したり、サブクエリを追加したりして、答えを見つけ出す必要があります。1 つのシステムが終わったら次のシステムに移動し、別の方法で再びクエリを行います。気づけばブラウザのタブが 10 個も開いていて、1 つの質問に答えるだけで丸一日がつぶれてしまいます。

Data Agent Kit

まさにこのような問題を解決するために構築されたのが、Data Agent Kit です。MCP サーバーとエージェントスキルを組み合わせた Data Agent Kit を使用することで、データデベロッパーは IDE からデータワークフローを実行できるようになります。VS Code フォーク（Antigravity IDE、Cursor）の拡張機能としても、他のツール（Antigravity 2.0、Antigravity CLI、Claude Code、Codex）のプラグインとしても利用できるため、IDE を離れることなく、答えを見つけ出せます。

Data Agent Kit は、次の 2 つのコアメカニズムを基盤としています。

Model Context Protocol（MCP）: エージェントをツール、データベース、リモートクラウドインフラストラクチャに接続するオープンスタンダード。
エージェントスキル: AI エージェントに特定スタックとのやり取りの方法を教え、エージェントの知識を補強する Markdown ファイル。

Data Agent Kit を使用すると、SQL スニペットを生成してコンソールにコピーして貼り付ける代わりに、エージェントがクエリを実行して結果を読み取ることができます。

これを平均注文額（AOV）のシナリオに適用したら、どのようになるのか見てみましょう。この場合、データウェアハウスには BigQuery が、Postgres インスタンスには Cloud SQL が相当し、キャンペーンルールは Cloud Storage に保存されています。

Data Agent Kit のサンプルアーキテクチャ

事象を把握する

調査は、まず IDE のチャットペインで、次の自然言語プロンプトを使用して、基本的な数値の確認から始めます。

code_block: <ListValue: [StructValue([('code', 'BigQuery の orders テーブルと order items テーブルを使用して、2025 年 8 月から 2026 年 1 月までの月間平均注文額を計算してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f933ba63550>)])]>

結果を確認する

エージェントがプロンプトを処理し、関連スキルを呼び出して、データのクエリを開始する準備をします。しかし、まだ実行はせず、IDEを一時停止して必要な MCP ツール（execute_sql_readonly など）の使用許可を求めます。ユーザーは、監査のために 1 回だけ許可することも、[常に許可] を選択してワークフローを継続することもできます。許可すると、エージェントはクエリを送信します。

チャットでエージェントスキルと BigQuery MCP を呼び出す

エージェント IDE では、実行トレイルを検査して、各 MCP ツール呼び出しの記録や BigQuery に送信された未加工 SQL などを確認できます。エージェントが生成したコードは人間の目で再確認する必要がありますが、不慣れなスキーマに対して一からクエリを記述するの比べれば、大幅な時間の節約になるはずです。

数値を深掘りする

数値を見ると、平均注文額（AOV）は 8 月から 12 月まで 110 ドル前後を維持していましたが、1 月には 103 ドルに減少しています。この理由を調べるために、エージェントにドリルダウンを依頼します。

code_block: <ListValue: [StructValue([('code', '1 月の AOV を注文タイプ別に分類して、詳細を確認してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f933bad2bd0>)])]>

結果は、ビジネスの衰退ではなく、平均値の偏りを示しています。オンライン注文とオフライン注文は約 110 ドルで堅調に推移していますが、1 月に B2B-Wholesale という新しいチャネルが登場し、その AOV はわずか 75 ドルほどでした。注文が減少したのではなく、プロダクト構成の変化が AOV の見た目を押し下げました。

Cloud SQL に調査を広げる

AOV の低下につながった要因がわかりました。次に、卸売業者のバイヤーの実体を把握する必要があります。顧客レコードは Cloud SQL Postgres の運用データベースに保存されています。同じチャットスレッドで、次のように続けましょう。

code_block: <ListValue: [StructValue([('code', 'B2B のお客様はどのような事業者ですか。Cloud SQL データベースで、アカウントの詳細と作成日を確認してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f933ba0fbd0>)])]>

エージェントは MCP を Cloud SQL MCP に切り替え、customers テーブルを調査します。100 件の卸売アカウントはすべて、過去 30 日以内に作成された新しい事業体です。12 月には、これらの事業体はいずれも存在していませんでした。

Cloud SQL で運用顧客レコードをクエリする

コードを探求する

BigQuery で B2B 注文を簡単に確認すると、92% が promo_code = BIGORDER25 を適用していることがわかります。次に、エージェントにそのコードを追跡してキャンペーンファイルを確認するよう依頼すると、エージェントは Google Cloud Storage MCP サーバーを使用してファイルにアクセスします。

マーケティングキャンペーンでは、25% 割引コードにより低価格の卸売注文が大量に発生し、総収益は横ばいだったものの、総合的な AOV は減少しました。

このように、エージェントは、1 回のチャットセッションで、分析データ（BigQuery）、運用記録（Cloud SQL）、非構造化メタデータ（Cloud Storage）をクエリして、根本原因を特定しました。

調査結果を報告する

調査が終わったので、上司に短いエグゼクティブサマリーを提出するようエージェントに指示します。

エージェントが生成したエグゼクティブサマリー

これで完了です。IDE から直接、自然言語のプロンプトをいくつか入力するだけで、上司からの一筋縄ではいかない質問に答えることができました。

しかし、このような根本原因の分析作業は、日常業務のごく一部であり、その都度、時間を費やすわけにはいきません。次にまた作業が必要になったときに、同じプロセスを繰り返すのは非効率です。代わりに、この調査を再現可能なデータモデルに変換すると便利です。

再現可能なパイプラインを構築する

エージェントに、アドホック分析を永続的な dbt プロジェクトに変換するよう依頼することができます。AOV はペット関連商品の平均注文額なので、ここでは顧客のペットプロファイルを分析に組み込みます。

code_block: <ListValue: [StructValue([('code', 'BigQuery ステージングモデルを Cloud SQL の顧客レコードおよびペットのプロファイル属性と結合する dbt プロジェクトを構築してください。さらに、order_id に一意性テストを追加し、dbt build を実行してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f933ba0fdd0>)])]>

エージェントは、1 つのプロンプトから dbt-bigquery を使用して仮想 Python 環境を作成し、プロジェクトモデルとテストを記述します。しかし、dbt build は、一意性テストで order_id の重複が検出され、失敗に終わります。

これは、顧客によっては複数のペットを飼っている場合があるためです。モデルの最初のバージョンでは、これらのプロファイルを各注文に直接関連付けたため、3 匹のペットを飼っている世帯からの注文は 3 行になりました（一意ではありませんでした）。

エージェントは自身のターミナル出力を読み取り、失敗を検出します。その後、dbt ロジックを書き換え、ビルドが成功するまで再実行を繰り返します。

これは、エージェントワークフローに関して特記すべき点です。エージェントは大量のコードを記述できますが、パイプラインへのデータ品質チェックの適用は不可欠です（幸い、エージェントはそれも記述できます）。

次に上層部から平均注文額の変動理由を尋ねられたときには、dbt モデルが回答を準備してくれます。

まとめ

エージェント IDE を使用すると、ウェアハウス、データベース、オブジェクトストア、ターミナルを行き来する必要がなくなります。

MCP などのオープンスタンダードと、柔軟な構成と編集が可能なエージェントスキルを組み合わせることで、Data Agent Kit は質問と回答をスムーズに連動させて問題解決へと導きます。不慣れなスキーマを調べたり、多様なコードを使い分けたりすることはもちろん、これまで何度も記述してきた結合の生成も、これからはすべてエージェントに任せられます。エージェントが行う調査の指揮をするのが、あなたの役目です。

実際に試す

Data Agent Kit は現在プレビュー版で提供され、Antigravity（2.0、CLI、IDE）、Claude Code、Codex、Cursor、その他の一般的なツールでネイティブに動作します。

シナリオを試す: Data Agent Kit と Antigravity IDE を使用した分析の Codelab で、詳しい設定手順を確認する。
ドキュメントを読む: Google Cloud Data Agent 拡張機能のドキュメントで詳細を確認する。
プラグインを試す: GitHub のオープンソースリポジトリでスキルとツールを確認する。

- Google、デベロッパーアドボケイト、Jeff Nelson

Yahoo が Managed Service for Apache Spark のフレキシブル VM でリソースを最適化している方法

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

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

Yahoo は、数億人のユーザーを金融、スポーツ、エンターテイメントのプラットフォームに接続するグローバルなメディアおよびテクノロジー企業として、分析ワークロードを高速で継続的に実行する必要がある大規模なデータインフラストラクチャを運用しています。期限が重視されるデータ環境では、固定の仮想マシン（VM）構成に依存すると、システムが脆弱になります。特定のマシンシェイプがリージョンの容量制限に直面すると、Managed Service for Apache Spark（旧称 Dataproc）でのクラスタプロビジョニングが遅延し、重要なデータパイプラインが停止する可能性があります。

Yahoo は、Managed Service for Apache Spark クラスタでフレキシブル VM を利用し、許容可能な VM シェイプのランク付けされたリストを定義することで、これらのリソースの変動に自動的に対応しています。これにより、システムはリージョンゾーンを動的に検索し、手動による介入なしでパイプラインの実行を維持できます。リージョン全体で容量を検索するには、自動ゾーンプレースメントも有効にする必要があります。

この最適化は、オンプレミスの Hadoop とビッグデータ資産を Google Cloud に直接移行する、Yahoo のより広範なデータモダナイゼーションの取り組みを基盤としています。これらのレガシーワークロードを移行することで、チームは動的なリソースの柔軟性を備えた、大規模なバッチ分析とストリーミング分析を実行できるクラウド基盤を確立しました。

この投稿では、Managed Service for Apache Spark でフレキシブル VM インスタンスのランキングを構成し、容量の制約を自動的に管理してパイプラインの実行を維持するための技術的なブループリントをご紹介します。

静的構成の運用上のトレードオフ

特定のゾーンで固定された単一のマシンタイプを使用してクラスタを構成すると、リージョンゾーンの容量が変動した場合に制約が生じ、クラスタのプロビジョニングに影響する可能性があります。カスタムの再試行ロジックや手動による介入によってこれらの容量の変動を管理するのではなく、柔軟な構成を使用することで、インフラストラクチャを自動的に適応させることができます。柔軟な構成により、複数の VM シェイプを受け入れ、選択したリージョン内のゾーン全体で検索を行うことで、プロビジョニングを合理化し、大規模な分析ワークロードをより適切にサポートできます。

柔軟なクラスタを構成するためのルール

柔軟な構成をデプロイするには、一連の設計上の選択を調整する必要があります。

自動ゾーンプレースメントを有効にする: Managed Spark がリージョン全体で利用可能な容量を検索できるように、リージョン（--region=${REGION}）または空のゾーン文字列（--zone=""）を渡す必要があります。
コアとメモリの均一性を維持する: Managed Spark クラスタで自動スケーリングを使用する場合、フレキシブルリスト内のすべてのマシンタイプは、異なる VM ファミリーのものであっても、同様のコア数とメモリサイズを共有する必要があります。プライマリワーカーとセカンダリワーカーで CPU とメモリの比率を統一すると、最小の比率によって有効なコンテナのサイズが決まるため、パフォーマンスの低下を防ぐことができます。
コンポーネントプロパティを調整する: Managed Spark は、VM のコアとメモリに基づいてシステムプロパティを計算します。マシンシェイプを混在させる場合、YARN と Spark のリソース割り当てをワーカーの想定される動作に合わせるために、プロパティの明示的なオーバーライドが必要になることがあります。

フレキシブル VM が大規模なワークロードをサポートする 2 つの方法

大規模なデータ環境の場合、柔軟な構成は次の 2 つの方法で運用をサポートします。

クラスタ作成の成功率の向上: 優先 VM タイプが利用不可の場合に失敗せず、Managed Spark がランク付けされたリストから代替の VM タイプを選択してプロビジョニングを継続します。
リージョンリソースの使用効率の向上: 自動ゾーンプレースメントでは、リージョン全体が検索され、容量が検出されるため、需要が高い期間のプロビジョニングの摩擦が軽減されます。

gcloud の例

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters create analytics-cluster \\\r\n --region=us-central1 \\\r\n --zone="" \\\r\n --num-workers=10 \\\r\n --master-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --master-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f933baa4f50>)])]>

API の例

この容量ポリシーは、Dataproc API の instanceFlexibilityPolicy フィールドを使用して、自動化されたパイプラインまたは Managed Service for Apache Airflow DAG に組み込むこともできます。

code_block: <ListValue: [StructValue([('code', '{\r\n "projectId": "PROJECT_ID",\r\n "clusterName": "analytics-cluster",\r\n "config": {\r\n "gceClusterConfig": {\r\n "zoneUri": ""\r\n },\r\n "secondaryWorkerConfig": {\r\n "numInstances": 8,\r\n "instanceFlexibilityPolicy": {\r\n "instanceSelectionList": [\r\n {\r\n "machineTypes": ["n2-standard-8"],\r\n "rank": 0\r\n },\r\n {\r\n "machineTypes": ["e2-standard-8", "t2d-standard-8"],\r\n "rank": 1\r\n }\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f93488cde50>)])]>

この API ポリシーは、同じ目標を達成します。つまり、優先するシェイプを確立し、有効なフォールバックを文書化し、自動化スクリプトを中断することなく、Managed Spark がリソースの制約を解決できるようにします。

インフラストラクチャポリシーの確立

この規模のデータを管理するには、固定された単一のマシンタイプに依存するのではなく、明確なリソースポリシーを標準化する必要があります。構成基準では、以下を規定する必要があります。

セカンダリワーカーの優先 VM ファミリーとフォールバック VM ファミリー。
柔軟なプロビジョニングを可能にするためのデフォルトの自動ゾーンプレースメント。
自動スケーリングを使用する場合のコアとメモリの同一構成。
コンテナのサイズを予測可能に保つためにすべてのワーカーグループで統一された CPU とメモリの比率。
異なるマシンライン間で一貫したランタイム動作を保証するための、YARN または Spark プロパティの明示的なオーバーライド。
Spot または弾力性の高い容量で実行される Spark ワークロード向けのシャッフルセーフパターン。

柔軟な構成を採用することで、インフラストラクチャのリソース不足が解消され、予測可能なフォールバックプランが適用されるため、重要なデータパイプラインを稼働させ続けることができます。

Yahoo の影響と結果

Yahoo は、Managed Service for Apache Spark にフレキシブル VM を実装することで、リージョンの容量不足が原因で発生していたクラスタプロビジョニングの失敗を 85% 削減することに成功しました。この柔軟な構成により、データインフラストラクチャは容量の制約に自動的に対処し、手動による介入を必要とせずにリソースを正常にプロビジョニングできます。その結果、Yahoo はワークロードを継続的に実行できるようになり、大規模なデータパイプライン全体でダウンストリーム処理の遅延を防止しています。

「Yahoo で大規模なデータ分析を管理するには、復元力のある自動化されたインフラストラクチャが必要です。Managed Service for Apache Spark のフレキシブル VM に移行したことで、当社のアプローチは一変しました。特定のマシンシェイプが容量の制約に直面したときに処理が停止するのではなく、クラスタがランク付けされたフォールバックオプションに自動的に切り替わるようになりました。これにより、プロビジョニングの失敗を 85% 削減し、グローバルメディアプラットフォームをスムーズに運用し続けるために必要な信頼性を確保できました。」- Yahoo!、シニアソフトウェアデベロッパーエンジニア、Akshay Jain 氏

柔軟なインフラストラクチャの戦略上のメリット

柔軟なコンピューティングスタックを採用することで、環境を運用ニーズに適応する動的なリソースプールへと変革できます。固定された単一のマシンタイプ構成に縛られないため、供給の変動に関係なく、ワークロードが必要なコンピューティングに確実にアクセスできるようになります。この移行により、ワークロードの入手可能性と信頼性が最大限に高まるだけでなく、古いタイプの VM を信頼性の高いフォールバックオプションとして維持しながら、新しい世代の VM を優先できるため、シームレスなハードウェアのモダナイゼーションが促進されます。

復元力のあるデータパイプラインを構築する

流動的なコンピューティング戦略に移行することで、リージョンリソースが変化しても、重要な分析を継続できます。インフラストラクチャの最適化を今すぐ始める方法を以下に示します。

ワークロードを検証する: 特定の VM ファミリーやゾーンに緊密に結合されているアプリケーションを特定し、実行可能な代替ハードウェアシェイプをマッピングします。
リソースポリシーを標準化する: Managed Spark のフレキシブル VM のドキュメントを読んで、優先 VM ファミリーとフォールバック VM ファミリーを確立します。
財務戦略を調整する: ワークロードが代替マシンタイプに動的に移行する場合に、フレキシブル確約利用割引（フレキシブル CUD）を利用して費用の予測可能性を維持します。
クレジットを獲得する: 新規のお客様は、Managed Service for Apache Spark や他の Google Cloud プロダクトを無料で試すことができる $300 分のクレジットを獲得できます。

- Yahoo、シニアソフトウェアエンジニア Akshay Jain 氏

- Google Cloud、データ / AI エンジニア Surjit Singh

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

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

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

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

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

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

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

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

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

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

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

BigQuery で TabFM を使ってみる

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

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

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

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

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

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

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

BigQuery の TabFM の仕組み

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

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

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

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

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

予測 ML が簡単に

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

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

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

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

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

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

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

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

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

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

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

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

ID 列を実装する方法

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

定義のオプション

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

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

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

使ってみる

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

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

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

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

数週間から数分へ: データパイプラインの新たなエージェント時代

Thu, 10 Sep 2026 16:00:00 +0000

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

データパイプラインは現代の企業のバックボーンですが、オーケストレーションには参入障壁があり、多くのデータ専門家がこの重要な機能を利用できない状況にあります。Google Cloud NEXT ’26 での発表で Orchestration Pipelines フレームワークを紹介したことで、この状況は根本的に変わろうとしています。

この強力なフレームワークを実務担当者に直接提供するため、Google は Data Agent Kit を提供しています。これは、データエンジニアリングとデータサイエンスのツールを統合した、自由に利用できるオープンソースのコレクションで、お好みの IDE や CLI（VS Code、Claude Code、Codex など）に直接統合できます。

Data Agent Kit は、Orchestration Pipelines フレームワークを 2 つの異なる方法でワークフローにシームレスに組み込みます。まず、包括的なパイプライン管理のための専用の [データエンジニアリング] タブが用意されています。2 つ目は、自然言語を使用して本番環境グレードの Apache Airflow® DAG を作成、デプロイ、トラブルシューティングできるように設計された、専門的なエージェントスキルです。

これらの専門的なエージェントスキルを宣言型の YAML DSL と組み合わせることで、アナリストから ML エンジニアまで、あらゆるデータ担当者が複雑な Python Airflow ボイラープレートを回避できます。このフレームワークは、高レベルのオーケストレーションロジックを基盤となるコンピューティング実行から切り離し、データ組織全体で強力な MLOps 機能へのアクセスを民主化します。

この投稿では、MLOps の模範的なユースケースを例に、これを簡単に実現する方法を説明します。

環境設定

最初のオーケストレーションパイプラインを作成する前に、ローカル開発環境を設定する必要があります。2 分もかからずに開始できます。

1. 拡張機能をインストールして構成する

VS Code、VS Code フォーク、Antigravity、Claude Code、Antigravity CLI、Codex など、お好みの IDE または CLI に拡張機能をインストールし、Google Cloud アカウントで認証するには、公式ドキュメントの Google Cloud Data Agent Kit インストールガイドに記載されている手順に沿って設定します。

2. オーケストレーションパイプラインのスキルを確認する

インストールしたら、必要なエージェントスキルが有効になっていることを確認します。

VS Code アクティビティバーで [Google Cloud Data Agent Kit] パネルを開きます。
[設定] > [スキル] の順に移動します。
「gcp-pipelines-orchestration」スキルが有効になっていることを確認します。

このスキルにより、エージェントは、パイプライン構文、変数置換、シークレット管理、Airflow 実行の自動インシデント診断に関する深い背景知識を得ることができます。

3. 最初のパイプラインを構築する

自然言語プロンプトを使用して、VS Code 互換の IDE 内で直接オーケストレーションパイプラインの作成、構築、検証を開始するには、公式の構築ガイド（パイプライン構築ガイド）をご覧ください。

ビジネス上の問題の例: プロアクティブなサプライチェーン管理

ビジネス上の問題の例を見ていきましょう。物流および小売業界では、顧客満足度は正確な配達予定に左右されます。注文が予告なく遅延すると、顧客離れが急増し、サポート費用が膨らむ可能性があります。

これに対処するため、倉庫の場所、顧客の場所、注文の特性に基づいて正確な配送日数（日数単位）を予測するエンドツーエンドの MLOps アーキテクチャを構築しています。出荷前にこうした遅延を予測することで、運用チームはサービスレベル契約（SLA）に違反する前に、顧客に事前に通知したり、配送レベルを自動的にアップグレードしたりできます。

このアーキテクチャを完全に再現可能にするため、BigQuery の一般公開データセットである bigquery-public-data.thelook_ecommerce を使用します。デモの目的上、この静的データセットをトレーニングセットと推論セットに分割します。実際のシナリオでは、推論は新たに入ってくるデータに対して行われます。このデータセットは、実際の運用上の複雑さを提供します。

地理データ: 顧客の住所（users）と配送センター（distribution_centers）の緯度と経度。
時間データ: 注文ライフサイクルの詳細なタイムスタンプ（created_at、shipped_at、delivered_at）。
注文属性: 商品カテゴリ、価格、フルフィルメントステータス（orders、order_items）。

このデータセットを BigQuery、Managed Service for Apache Spark サーバーレス、Gemini Enterprise Agent Platform、dbt と組み合わせることで、トレーニング、毎日のバッチ推論、モデルドリフト評価を処理する、自動化された自己修復型の MLOps ループを構築する方法を実証します。

エージェントワークフロー: プロンプトからパイプラインまで、わずか数分で

拡張機能を構成すると、DAG 作成用のボイラープレート Python を完全にバイパスできます。VS Code 内で Data Agent Kit チャットを開き、単一の自然言語プロンプトを入力するだけで、継続的な MLOps フィードバックループを定義しました。

注: 詳細なプロンプトは、このブログ投稿のために、再現性を考慮して作成されました。実際のシナリオでは、パイプラインごとに、より会話調で同じ結果を達成できます。完全なプロンプトと生成されたすべてのファイルは、Orchestration-pipelines GitHub リポジトリで入手できます。

注: Orchestration Pipelines スキルを備えたフロンティアモデルは、多くの場合、1 ステップで完全なワークフローを骨組みを作成できますが、LLM のレスポンスは、モデルのバージョン、ワークスペースのコンテキスト、トークンの深さによって当然異なります。最初のパスで特定のパラメータ、データセットパス、依存関係が省略された場合は、短いフォローアッププロンプトを入力します。

数分以内で、Data Agent Kit が、基盤となる PySpark スクリプト、dbt 構成、3 つの宣言型 YAML パイプラインを生成しました。

生成された YAML パイプラインと、その視覚的な図を以下に示します。このパイプラインは、Orchestration Pipelines の機能を説明するために簡略化した例です。実際には、本番環境の MLOps の推奨設定は、具体的なユースケースや運用上のニーズによって異なります。

パイプライン 1: トレーニングエンジン

このパイプラインは、高負荷のコンピューティングエンジンとして機能します。エージェントは、まず BigQuery にクエリを実行して過去に完了した注文を抽出する YAML 定義を生成しました。その後、Managed Spark サーバーレスクラスタを動的にプロビジョニングして、地理的な距離を計算し、本番環境で使用するモデルをトレーニングします。最後に、トレーニング済みモデルを Gemini Enterprise Agent Platform Model Registry に push します。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "training-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - sql:\r\n name: "extract_training_data"\r\n engine:\r\n bigquery:\r\n location: "US"\r\n destinationTable: "your-project-id.mlops.training_dataset"\r\n query:\r\n path: "blogpostdemo/training_query.sql"\r\n\r\n - pyspark:\r\n name: "train_model_dataproc"\r\n dependsOn:\r\n - "extract_training_data"\r\n engine:\r\n dataprocServerless:\r\n location: "us-central1"\r\n resourceProfile:\r\n inline:\r\n runtimeConfig:\r\n version: "2.3"\r\n properties:\r\n "spark.dataproc.driverEnv.PYTHONPATH": "./libs/lib/python3.11/site-packages"\r\n "spark.executorEnv.PYTHONPATH": "./libs/lib/python3.11/site-packages"\r\n mainFilePath: "blogpostdemo/train_model.py"\r\n environment:\r\n requirements:\r\n inline:\r\n list:\r\n - "tensorflow==2.14.1"\r\n - "numpy<2.0.0"\r\n - "protobuf<5.0.0dev"\r\n - "google-cloud-storage"\r\n\r\n - ai:\r\n name: "upload_model_vertex"\r\n dependsOn:\r\n - "train_model_dataproc"\r\n agentPlatform:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n modelUpload:\r\n modelName: "transit_days_predictor"\r\n modelArtifactUri: "gs://your-bucket-name/models/tf_transit_days_model"\r\n servingContainerImageUri: "us-docker.pkg.dev/vertex-ai/prediction/tf2-cpu.2-14:latest"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f933bdcde90>)])]>

パイプライン 2: 日次推論

日々の運用ワークフローでは、この軽量なパイプラインが、トレーニング済みのモデルを現在配送中のすべての注文に適用します。BigQuery ジョブを介してデータセットをクエリし、Gemini Enterprise Agent Platform を介して推論ジョブを実行し、結果を BigQuery テーブルに書き戻して、カスタマーサポートチームに SLA 違反の可能性を通知します。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "inference-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - sql:\r\n name: "extract_inference_data"\r\n engine:\r\n bigquery:\r\n location: "US"\r\n destinationTable: "your-project-id.mlops.inference_dataset"\r\n query:\r\n path: "blogpostdemo/inference_query.sql"\r\n\r\n - ai:\r\n name: "run_vertex_batch_prediction"\r\n dependsOn:\r\n - "extract_inference_data"\r\n agentPlatform:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n batchInference:\r\n jobDisplayName: "inference_job"\r\n modelName: "projects/your-project-id/locations/us-central1/models/your-model-id"\r\n bigquerySource: "bq://your-project-id.mlops.inference_dataset"\r\n bigqueryDestinationPrefix: "bq://your-project-id.mlops"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f933bd0d650>)])]>

パイプライン 3: 自動評価と分岐

日次評価パイプラインは、自動品質ゲートとして機能します。dbt モデルをトリガーして予測を実際の配送タイムスタンプと結合し、絶対誤差と SLA 違反を計算します。

パイプラインは、組み込みのロジックを使用して、これらの指標を自動的に評価します。モデルのエラー率が許容しきい値を超えた場合、条件に応じて「training-pipeline」がトリガーされ、新しいモデルが生成されます。

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "evaluation-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - pipeline:\r\n name: "run_dbt_models"\r\n framework:\r\n dbt:\r\n airflowWorker:\r\n projectDirectoryPath: "blogpostdemo/dbt_project"\r\n\r\n - python:\r\n name: "check_retraining_condition"\r\n dependsOn:\r\n - "run_dbt_models"\r\n mainFilePath: "blogpostdemo/evaluate_drift.py"\r\n pythonCallable: "check_drift"\r\n engine:\r\n local: {}\r\n\r\n - orchestrationPipeline:\r\n name: "trigger_retraining_pipeline"\r\n dependsOn:\r\n - "check_retraining_condition"\r\n pipelineId: "training-pipeline"\r\n bundleId: "my-first-bundle"\r\n waitForCompletion: false'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f933ba70690>)])]>

Managed Service for Apache Airflow への自動デプロイ

パイプラインロジックの作成は、作業の半分にすぎません。本番環境に安全かつ確実にデプロイする段階で、データチームはこれまで貴重な時間を失ってきました。

Orchestration Pipelines を使用すると、標準的な CI / CD プラクティスを通じてデプロイが合理化されます。デプロイスクリプトを手動で作成したり、複雑な環境境界を構成したりする必要はありません。Data Agent Kit が、ワークスペースに必要な継続的インテグレーションワークフロー（GitHub Actions など）を自動的に生成します。

つまり、commit をクリックするだけで、フレームワークが Orchestration Pipelines Bundle をシームレスにパッケージ化し、Managed Airflow 環境に直接デプロイします。

これらの自動化されたワークフローを既存の CI / CD パイプラインに統合するための包括的なガイドについては、公式ガイド「Orchestration Pipelines のデプロイ」をご覧ください。

Day 2（2 日目からの）運用: モニタリングとエージェントによるトラブルシューティング

これらのパイプラインのメンテナンスは、構築と同じくらい直感的に行えます。Data Agent Kit は、オーケストレーションコントロールプレーンを IDE に直接組み込むことで、ブラウザタブを頻繁に切り替えることなく、Managed Airflow の実行をリアルタイムでモニタリングできるようにします。

Data Agent Kit を使用すると、IDE 内で直接、Managed Airflow の実行をリアルタイムでモニタリングできます。

Data Agent Kit が、作成されたパイプラインを可視化します。

インフラストラクチャやデータの問題は避けられません。たとえば、季節的なデータの急増により Managed Spark クラスタでメモリ不足の例外が発生したり、BigQuery の割り当ての上限に達したりすることがあります。これらの問題を解決するために、何千行もの未加工の実行ログを調べる必要はもうありません。

パイプラインが失敗した場合、Data Agent Kit はすぐに使えるエージェント型トラブルシューティングを提供します。IDE で [トラブルシューティング] ボタンをクリックするだけで、データエンジニアリングエージェントが失敗のコンテキストを分析します。インフラストラクチャの割り当て上限とコードレベルのバグを正確に区別し、根本原因の概要を即座に提供して、インライン修正（コンピューティングテンプレートのスケールアップなど）を提案します。

エージェント型トラブルシューティングにより、パイプラインの障害を即座に診断し、インフラストラクチャのボトルネックを特定して、インライン修正を提案します。

まとめ: 価値創出までの時間を短縮

レジリエントな MLOps アーキテクチャの構築（過去のデータの抽出、dbt 変換の実行、Managed Spark ML コンピューティングのプロビジョニング、モデルレジストリと推論のための Gemini Enterprise Agent Platform のインテグレーション、DAG 間の条件付きトリガーの構成）には、従来、プラットフォームエンジニアリングチームが複雑な Python Operator ロジックを記述するのに数週間かかっていました。

Orchestration Pipelines と Data Agent Kit を使用することで、このライフサイクル全体を数分で作成、デプロイ、簡単にメンテナンスできました。ボイラープレートインフラストラクチャコードを、宣言型の、エージェント対応の標準に置き換えることで、データ組織がパイプラインのオーケストレーションに費やす時間を減らし、具体的なビジネス価値の創出に多くの時間を割けるようにしています。

使ってみる:

Orchestration Pipelines のドキュメントを確認する。
お好みの IDE または CLI に Data Agent Kit をインストールし、ワークスペースを構成する。
エコシステム全体の詳細については、最近のブログ投稿「Data Agent Kit は IDE または CLI にデータ処理のスキルとツールを提供」を確認する。
Data Agent Kit のドキュメントでリファレンスアーキテクチャを確認する。

- リードプロダクトマネージャー、Piotr Wieczorek

- ソフトウェアエンジニア、Alexandre Moueddene

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

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

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

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

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

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

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

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

BigQuery Graph の新機能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

グラフとチャットする

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

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

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

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

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

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

BigQuery Graph を今すぐ使ってみる

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

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

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

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

Google Cloud 上でのサーバーレス Apache Spark: アーキテクチャの選択と AI によるトラブルシューティング

Tue, 08 Sep 2026 00:30:00 +0000

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

現代のエンタープライズデータエンジニアリングにおいて、Apache Spark は大量のデータセットを大規模に処理するための基盤となるフレームワークであり続けています。しかし、クラスタのプロビジョニング、YARN 構成のチューニング、アイドル状態のハードウェアのコスト回避といったインフラストラクチャの管理に追われ、最も重要である「復元力のあるデータパイプラインの構築」に集中できなくなることが少なくありません。Google Cloud は、Managed Service for Apache Spark を通じてこの運用上のオーバーヘッドに対処し、特定の運用ニーズに合わせたサーバーレスおよびマネージドクラスタの柔軟なデプロイモードを提供しています。

この技術ガイドでは、Google Cloud で Spark をデプロイするためのアーキテクチャに関する意思決定マトリックスに加え、リソースと費用を最適化する手法を詳しく解説します。また、組み込みの Gemini Cloud Assist を適用して、サーバーレスバッチパイプラインの障害を迅速にトラブルシューティングし、解決する方法を実演します。これら 3 つのパートは順番に読むとより理解が深まりますが、それぞれを個別に読んでも、Google Cloud での Spark 開発を進めるうえでの有用なヒントが得られます。

パート 1: Apache Spark デプロイモデルの選択

Managed Service for Apache Spark で Spark ワークロードを起動する際の最初の大きな意思決定ポイントは、従来のマネージドクラスタを構築するか、管理不要のサーバーレスインフラストラクチャフットプリントに移行するかを評価することです。

検討事項 1: マネージドクラスタかサーバーレスか

* Gemini Enterprise Agent Platform の Nano Banana 2 を使用して作成

従来の Managed Spark クラスタとサーバーレスのどちらを選択するかは、エコシステムの要件、そしてコスト効率を左右するリソースの利用パターンによって決まります。

ワークロードの頻度、レイテンシの影響を受けやすいワークロード、コストの適合性: クラスタノードの使用率ベースラインが常に高く（80% 以上）、継続的で予測可能性の高い24 時間 365 日のストリーミングまたはバッチ処理パイプラインや、ワークフローの起動時間が積み重なることで SLA 目標の達成が危ぶまれるような場合は、カスタム YARN 自動スケーリングルールを使用してファインチューニングした従来型クラスタを常時実行する方が、費用の予測可能性が高まります。一方、断続的、バースト的、アドホック、またはオーケストレータートリガーのパイプラインの場合は、Managed Spark サーバーレスが極めて有効です。運用管理の手間が省けるだけでなく、計画にかかる時間を短縮でき、アイドル状態のコンピューティング時間に対して料金を支払う必要がありません。
エコシステムとコンポーネントの要件: Managed Spark サーバーレスは、Apache Spark 3.x 以降のコードベースに完全に最適化されています。処理パイプラインが Apache Flink、Presto / Trino、Hive LLAP、Apache HBase などの他のエコシステムコンポーネントに依存している場合、または以前の Spark 2.x コードベースにロックインされている場合は、Managed Spark クラスタを使用する必要があります。
インフラストラクチャのカスタマイズのニーズ: Managed Spark サーバーレスは、基盤となる仮想マシン（VM）レイヤを抽象化します。ワークロードで、OS レベルでの高度なハードウェアチューニング、カスタム OS の初期化アクション、インスタンスへの root SSH アクセス、特定のローカル SSD 構成、カスタムマシンシェイプが必要な場合は、従来のクラスタが必要です。なお、サーバーレスは特定のアプリケーションレベルのライブラリをバンドルするためのカスタム Docker コンテナイメージをサポートしています。

検討事項 2: サーバーレスインタラクティブセッションとサーバーレスバッチ

* Gemini Enterprise Agent Platform の Nano Banana 2 を使用して作成

サーバーレスデプロイモードを選択したら、開発ステージと運用要件に基づいて適切な実行モデルを選択する必要があります。Managed Service for Apache Spark には、サーバーレスワークロードを実行するための 2 つのオプションがあります。

サーバーレスインタラクティブセッション

インタラクティブセッションは、反復的なユースケースや試験的なユースケースに最適です。コードブロックを記述し、中間 DataFrame を検査し、変数を変更し、データセットをメモリに保持したままビジュアリゼーションを生成します。

プライマリインターフェース: 人間参加型のインタラクション向けに設計されています。デベロッパーは、Colab、Gemini Enterprise Agent Platform Workbench、Antigravity、Jupyter ノートブックなどの好みの IDE を使用して、コードをセルごとに実行します。
アイドル時のコスト: コンピューティングリソースは、デベロッパーが検討している間も即座に実行できるようにアクティブな状態を維持します。セッションを非アクティブなままにすると、アイドル状態のコンピューティング料金が発生する可能性があります。

サーバーレスバッチ

バッチは、実行する内容がわかっていて、非インタラクティブな自動化された実行が必要な場合に便利です。このエンジンは、完成済みのパッケージ化された PySpark スクリプト（.py）または Java / Scala アプリケーションファイル（.jar）を、人間の手作業による介入なしに最初から最後まで実行します。

主なインターフェース: Managed Service for Apache Airflow、Cloud Scheduler、CI / CD パイプラインなどの自動オーケストレーターによって管理されます。
アイドル時のコスト: 実行時間に対してのみ、厳密に課金されます。コンピューティングリソースはオンデマンドでプロビジョニングされ、スクリプトを実行し、完了するとすぐにシャットダウンして、アイドル状態のコストを防止します。

開発から本番環境までのライフサイクル

これらの実行オプションは、自然なパイプラインライフサイクルとして連携するように設計されています。開発の初期段階では、ノートブックインターフェース内でサーバーレスインタラクティブセッションを開き、データセットの探索、スキーマのクリーンアップ、変換のプロトタイピングを行います。ロジックが検証され、変換が完了したら、コードを Python スクリプトにパッケージ化し、本番環境での実行のために Managed Service for Apache Airflow によってオーケストレートされるサーバーレスバッチジョブとしてスケジュールします。この移行により、運用の信頼性を確保しつつ、継続的な開発コストを最小限に抑えることができます。

パート 2: 高度なパフォーマンスチューニングと DCU コストの最適化

サーバーレスの Managed Spark は、クラスタメンテナンスの運用オーバーヘッドを解消してくれますが、デフォルト設定のまま本番環境でエンタープライズグレードのパイプラインを実行すると、パフォーマンスのボトルネックや予算の浪費を招く恐れがあります。効率的なデータコンピューティング単位（DCU）のバーンレートを維持するには、送信時にランタイム構成プロパティを使用してリソース割り当てを明示的に宣言する必要があります。

Google は最近、履歴ベースの自動チューニングを導入しました。サーバーレスの環境においては、この機能がベストプラクティスや過去の実行履歴に基づいて、最適化を自動的に適用します。これは、繰り返し実行されるバッチワークロードを、Google がコホートと呼ぶものにグループ化することで実現されます。自動チューナーが、同じコホート名で以前に実行された際のテレメトリーと統計情報を分析して、ボトルネックがどこにあるかを特定します。

ドライバとエグゼキュータのシェイプのカスタマイズ

デフォルトでは、サーバーレスバッチは一般的な仕様（4 コア、16,000 MB RAM）を割り当てます。これは、アプリケーションの性質によっては、効率性に重大な問題を引き起こす可能性があります。

メモリバウンドジョブ: 圧縮されていない大量のデータを処理するパイプラインは、メモリ不足（OOM）エラーが発生してクラッシュする可能性があります。これに対処するには、spark.driver.memory と spark.executor.memory を使用してヒープサイズを個別に増やします。
コンピューティングバウンドジョブ: 数学モデリングや大量のトークン化を実行する処理集約型のジョブでは、CPU が飽和状態になる一方で、高価な RAM がアイドル状態になる可能性があります。spark.driver.cores と spark.executor.cores を明示的に調整して、インスタンスごとの処理の同時実行をファインチューニングします。

デフォルトでは、コア数を増やすと、vCPU と RAM の比率に見合ったベースラインメモリが自動的にプロビジョニングされることに注意してください。そのため、コアとメモリの両方の値をオーバーライドすることが重要です。

自動スケーリングの境界の制御

Managed Spark サーバーレスは、未処理のタスクに基づいて、アクティブなエグゼキュータの数を動的にスケールアップおよびスケールダウンします。ただし、制約のないスケーリングは、不正なコードループや最適化されていないデカルト結合が導入されると、予算超過につながる可能性があります。

防御的なガードレールとして、spark.dynamicAllocation.maxExecutors を使用して常に明示的な上限を宣言してください。これは、予算超過を防ぐための安全装置として機能します。妥当な上限に制限することで、コードが最適に動作しない場合でも、ジョブが固定のインフラストラクチャフットプリントを超えてスケールすることはありません。

高優先度（SLA 主導）: maxExecutors で上限を高く設定して、リソースのバーストを可能にし、全体的なランタイム期間を最小限に抑えます。
低優先度（夜間バッチ）: maxExecutors で上限を低く、厳しく設定します。ワークロードの実行時間は長くなりますが、DCU の消費は予測可能な一定のペースに保たれ、コスト効率に優れた運用が可能になります。

シャッフルストレージの効率の管理

groupBy()、join()、distinct() などのワイド変換を伴う処理では、ネットワーク全体にデータを再配布する必要があり、シャッフルストレージと呼ばれる中間ディスク書き込みが発生します。

Spark はデフォルトで、パーティション数が 200 に静的設定されています（spark.sql.shuffle.partitions）。数ギガバイトに及ぶ大規模なデータセットを処理する場合、パーティション数が 200 個のままだと、個々のチャンクが大きくなりすぎてしまいます。パーティションのサイズが利用可能なエグゼキュータ RAM を超えると（たとえば、1 GB のパーティションを、割り当てられたヒープ領域 0.5 GB 内で処理しようとする場合）、データがディスクにあふれ出します。これにより、実行速度が低下し、プレミアムまたは標準のシャッフルストレージブロックの追加料金が発生します。目安として、各パーティションがメモリ内で約 100 MB ～ 200 MB のデータを処理できるように、合計データサイズに基づいてパーティションパラメータを動的にスケールするとよいでしょう。最適な結果が得られるまで、何回か繰り返す必要が生じる場合があります。

上述のプロパティは、主なチューニング可能なプロパティです。その他のサーバーレスランタイム構成プロパティについては、こちらのリンクをご覧ください。

パート 3: Gemini Cloud Assist による運用診断

本番環境で自動データパイプラインが失敗した場合、データエンジニアは従来であれば、ドライバとエグゼキュータにまたがる冗長で断片的なログファイルを何時間もかけて精査する必要がありました。Managed Service for Apache Spark は、Gemini Cloud Assist を Google Cloud コンソールにネイティブに統合することで、こうした手間を取り除きます。これにより、エンジニアは自然言語を使用して障害を診断し、解決できます。

この運用スタイルの変化を具体的に示すため、ある PySpark ETL パイプラインの事例を見ていきましょう。このパイプラインは、Google Cloud Storage（GCS）バケットから顧客トランザクションデータを読み取り、変換を適用する過程で、予期せぬランタイムエラーにより失敗したものです。この事例を通して、一般的なトラブルシューティングの流れを解説します。

ステージ 1: 欠落している実行パラメータの診断

新しいパイプラインの最初の実行試行中、バッチジョブのステータスが保留中から実行中に切り替わり、最終的には一般的な終了メッセージ「アプリケーションは終了コード 1 で失敗しました（Application failed with exit code 1）」とともに失敗状態になっています。

エンジニアは、Cloud Logging を手動でクエリしたり、コンソールの複数のセクションを移動したりするのではなく、エラーログを見つけて [ログを調べる] オプションを選択できます。この操作により、ネイティブの会話ペインが開き、Gemini Cloud Assist によってドライバのテレメトリーとシステムログが自動的に分析されます。

このシナリオでは、送信時に必要なランタイム引数（ソース GCS バケットパスなど）が省略されたために PySpark スクリプトが失敗したことを、アシスタントがわかりやすい英語で説明してくれます。Gemini Code Assist は、これらの引数を想定しているスクリプト内の正確な行を即座に特定するため、スタックトレースを読み取る必要がなくなります。

ステージ 2: スキーマとデータ型の異常を解決する

不足している引数を解決してジョブを再送信すると、パイプラインは実行されますが、2 回目のデータ異常が発生します。大量のデータを取り込むパイプラインでは、アップストリームのソースファイルに破損したレコードや形式の不整合が含まれていることがよくあります。

2 回目の失敗後、エンジニアは再び Gemini Cloud Assist にログの調査を指示します。アシスタントは TypeError を特定し、クラッシュの原因となっている正確な DataFrame 変換を特定します。これは、スキーマが列を文字列として自動推論したために失敗した除算演算（df['amount'] / df['transaction_id']）です。

さらに、アシスタントは基盤となる GCS ファイルデータをスキャンして、根本原因を特定します。この場合は、ソースデータセット内の非数値の異常（数値セル内のテキスト文字列など）です。

ステージ 3: 検証済みのコード修正の生成とデプロイ

エンジニアは、スキーマタイプをキャストして null 値をキャッチする PySpark ロジックを手動で書き換えるのではなく、Gemini Cloud Assist に直接プロンプトを入力して、復元力のあるソリューションを生成させることができます。

ユーザープロンプト: 「transaction_id ではなく、quantity で amount を割るようにコードを書き換える方法を提案して。さらに、プロセスを失敗させることなく無効なレコードをスキップするロジックを追加して。」

アシスタントは、復元力のあるキャストと null 処理関数（coalesce や try_cast など）を使用して、修正された PySpark コードブロックを生成します。

この修正されたスクリプトを実装することで、オーケストレーションパイプラインは、バッチ実行全体をクラッシュさせることなく、不良なソースレコードをスムーズに除外できます。後続の実行は正常に完了し、データの更新速度に関する SLA が維持されます。

サーバーレス Apache Spark の活用: メリットと次のステップ

データ処理パイプラインの管理に、インフラストラクチャ構成に関する高度な専門知識は必要ありません。サーバーレスバッチのハンズオフスケールと、動的割り当て上限やシャッフルサイズの計算など、リソースの明示的なチューニングを組み合わせることで、データチームはパフォーマンスとコストのプロファイルを厳密に管理できます。障害が発生しても、Gemini Cloud Assist をロギングワークフローに直接統合することで、複雑なトラブルシューティングのあり方が一変します。手動でログを精査する手間がなくなり、迅速で自動化されたサイクルへと進化させることができます。

これらのアーキテクチャを実際に使用するには、Managed Service for Apache Spark のドキュメントを確認し、Google Cloud コンソールでサーバーレスバッチを直接実行してください。

これらのコンセプトのアーキテクチャ分析の詳細については、エージェントの時代における Apache Spark® の実務担当者向けガイドを今すぐご覧ください。このガイドには、Codelab、ステップバイステップのワークフロー、GitHub リポジトリから直接実行できる PySpark と Terraform のテンプレートが含まれています。Google Cloud を初めてご利用になる場合は、$300 分のクレジット付き無料トライアルに登録することで、サーバーレスクラスタやマネージドクラスタ上でこれらのブループリントを無料でお試しいただけます。

- Google Cloud、データ分析担当カスタマーエンジニア、Lior（Leo）Ginzberg

データ分析

Knowledge Catalog に新しい自己学習型コンテキスト エンリッチメントを導入

Knowledge Catalog の自己学習型エンリッチメントがエンタープライズ AI エージェントをグラウンディングする仕組み

BigQuery ObjectRef の一般提供を開始: 会話分析用のマルチモーダル データ プラットフォームをすべて SQL で構築

Gemini のイノベーションで、ボーダーレス Lakehouse をエージェントの時代へ導く

Gemini を通じて Google Cloud の外部にあるデータにアクセスする

ボーダーレス Lakehouse の進化

ペタバイト規模のパフォーマンスと推論

エージェント向けの包括的なコンテキストとデータアクセス

モダナイゼーションを容易に

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

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

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

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

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

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

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

概要

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

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

BigQuery 会話型分析の TimesFM 3.0

まとめと次のステップ

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

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

対象となる関数

割り当ての管理

使用量のモニタリング

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

適用の仕組み

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

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

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

使ってみる

Looker を活用した Agentic Data Cloud 向けの信頼できるデータアプリ

データアプリとは

セマンティック レイヤをアプリケーション プラットフォームへ拡張

エンタープライズ規模に対応

プロトタイプから本番環境までわずか数分

Apache Iceberg を自動管理して大規模展開する: Spanner を活用した Lakehouse ランタイム カタログ

レイクハウスのマネージド カタログが直面する課題

Lakehouse ランタイム カタログ

Lakehouse ランタイム カタログの原動力

分析と運用のワークロードを組み合わせる

ボーダーレスな Lakehouse にモダナイズ

地理空間コーディングを加速する Google Earth Engine の新機能「Ask」のご紹介

仕組み: コンテキストアウェアなアシスタント

活用方法の例

利用を開始するための 2 ステップ

分析の高速化: PayPal の Managed Service for Apache Spark 導入事例

困難な分析環境を乗り切る

複雑さにより生じた停滞

ソリューション: 統合されたクラウドネイティブな分析

結果: 分析情報の迅速な取得、オーバーヘッドの低減

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

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

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

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

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

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

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

ML レイヤ: Distributed Graph Flow（DGF）

ユースケース

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

使ってみる

Dataflow での一時停止 / 再開と NVIDIA RTX PRO 6000 Blackwell GPU のサポートを発表

概要

Dataflow バッチジョブの一時停止 / 再開機能で無駄なコンピューティングを削減し、デベロッパーの生産性を向上

NVIDIA RTX PRO 6000 GPU で AI 推論ワークロードを高速化

次のステップ

Data Agent Kit でエージェントを駆使した問題分析

Data Agent Kit

事象を把握する

結果を確認する

数値を深掘りする

Cloud SQL に調査を広げる

コードを探求する

調査結果を報告する

再現可能なパイプラインを構築する

まとめ

実際に試す

Knowledge Catalog に新しい自己学習型コンテキストエンリッチメントを導入

BigQuery ObjectRef の一般提供を開始: 会話分析用のマルチモーダルデータプラットフォームをすべて SQL で構築

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

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

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

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

セマンティックレイヤをアプリケーションプラットフォームへ拡張

Apache Iceberg を自動管理して大規模展開する: Spanner を活用した Lakehouse ランタイムカタログ

レイクハウスのマネージドカタログが直面する課題

Lakehouse ランタイムカタログ

Lakehouse ランタイムカタログの原動力

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

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

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

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

インフラストラクチャポリシーの確立

復元力のあるデータパイプラインを構築する

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

数週間から数分へ: データパイプラインの新たなエージェント時代

ビジネス上の問題の例: プロアクティブなサプライチェーン管理

エージェントワークフロー: プロンプトからパイプラインまで、わずか数分で

パート 2: 高度なパフォーマンスチューニングと DCU コストの最適化