データ分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

環境を設定する

事前準備：

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

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

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

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

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

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

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

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

5. JupyterLab を起動します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Python に戻って可視化する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. タグ値を作成する

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

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

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

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

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

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

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

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

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

3. テーブルを更新する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

説明から意思決定まで

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

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

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

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

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

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

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

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

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

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

信頼性: generated、verified

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

v0.2 の主な更新内容

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

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

互換性

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

次のステップ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ

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

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

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

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

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

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

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

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

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

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

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

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

Google の Agentic Data Cloud

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

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

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

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

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

不要な手作業を回避する

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

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

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

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

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

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

将来を見据える

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

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

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

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

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

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

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

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

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

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

難易度を測定

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

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

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

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

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

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

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

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

図 2: iSQR の改良ループ。

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

見えていなかった崖

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

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

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

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

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

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

分野全体での傾向

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

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

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

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

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

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

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

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

評価ツールを評価する

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

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

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

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

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

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

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

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

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

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

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

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

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

メンテナンスからイノベーションへ: Checkout における Managed Service for Apache Airflow への移行

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

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

データプラットフォームを構築したデータエンジニアリングチームが、「2 日目」（運用上の現実）に直面することがよくあります。それは、オーケストレーター自体の継続的なメンテナンス作業です。

Checkout.com のデータプラットフォームチームの場合、本来であれば他の作業に費やすことができていた時間を、別のハイパースケーラーでセルフホスト型の Apache Airflow 環境を管理することに費やす必要がありました。サーバー管理、パッチ適用、インシデント対応に気を取られ、パイプラインの構築に集中することができずにいました。

Google Cloud のフルマネージド Airflow サービスである Managed Service for Apache Airflow（第 3 世代）に移行することで、Checkout.com はその信頼性と費用構造を大きく変革しました。今回は、同社がよりスケーラブルで費用効率に優れた、堅牢なデータ基盤を構築した手法をご紹介します。

出発点: セルフマネージド Airflow

移行前、Checkout.com はセルフマネージドインフラストラクチャで Airflow を実行していました。機能には問題がありませんでしたが、基盤となるリソースのメンテナンスには細心の注意が必要でした。パッチ適用、アップグレード、サーバー管理により、定期的にサービスを中断する必要がありました。

過去 1 年間の運用データから、同社が以下のような課題に直面していたことが明らかになっています。

運用面での障害の軽減: セルフマネージド環境にあった Checkout.com は、特に負荷の高い期間に、安定性に関する課題に直面していました。
複雑な依存関係の管理: パッケージのアップグレードと互換性の確保を絶えず手動で行う必要があり、手間がかかっていました。Managed Airflow（第 3 世代）に移行した後は、イメージレベルで依存関係を処理することでこのプロセスを簡素化し、日常的な環境アップグレードの中でシームレスに互換性を確保できるようになりました。
DAG の同期時間: S3 へのデプロイ後、スケジューラへの DAG の同期に約 6 分かかり、イテレーションの速度に影響を与えていました。
手動プロセス: スケーリングには人間による介入が必要で、新しいチームのオンボーディング時には dbt 用のシークレットと変数を手動で作成する必要がありました。

ソリューション: Managed Service for Apache Airflow（第 3 世代）

Checkout.com のチームは、インフラストラクチャに関連する責務を軽減し、Google Cloud のマネージドスケーラビリティを活用するために、Managed Airflow に移行しました。その結果はすぐに表れ、信頼性、費用、開発速度の 3 つの領域で数値で示すことができる成果が上がりました。

動的スケーリングの効果

以前の Elastic Container Service 環境では、ピーク時の負荷に必要な最大数のワーカーを割り当てていました。つまり、実際の使用量に関係なく、常時ピーク時の容量に対応できる料金を支払う必要がありました。

Managed Airflow には動的スケーリング機能が組み込まれているため、リソースを手動で管理する必要がありません。この環境では、ワークロードの具体的な需要に基づいてワーカーの数が自動的に調整されます。システムは、タスクが急増するとスケールアップし、タスクが減少するとスケールダウンしてリソースを節約します。同様に、固定プロビジョニングから動的スケーリングに移行することで、月額費用も推定 30% 削減されました。

信頼性と DAG の分離

Checkout.com による移行の主な目的は、安定性の向上でした。以前は、問題のある DAG が 1 つあるだけで環境全体に影響が及ぶことがあったからです。

Managed Airflow により、アーキテクチャ面での重要な改善点が数多く導入されました。

DAG の分離: 各 DAG は独自の実行環境で実行されます。1 つの DAG が失敗したり、リソースを過剰に消費したりしても、環境全体に影響することはありません。
マネージドオペレーション: Google Cloud がスケジュールに従ってパッチ適用とアップグレードを処理するため、手動でのアップグレード管理が不要になります。
可視性の向上: Google Cloud Monitoring および Cloud Logging とのインテグレーションにより、タスクの実行を明確に可視化できます。エンジニアは、プラットフォームチームに問題をエスカレーションすることなく、個別にデバッグできるようになりました。

デベロッパーワークフローの高速化

この移行により、Checkout.com のデータエンジニアの日常的なワークフローも改善されました。

デプロイの高速化: DAG に Cloud Storage を使用することで、ほぼ瞬時の同期が可能になりました。
オンボーディングの簡素化: チームがオンボーディング前に変数を作成する際に、プラットフォームサポートが不要になりました。
dbt 実行のモダナイズ: 同社の最も大きな成果の一つが、dbt の実行方法の変更です。以前は、サポートされている dbt バージョンごとに、エンジニアが複雑な仮想環境を手動でインストールして管理する必要がありました。Managed Airflow（第 3 世代）は、コンテナ化された dbt 実行を活用することで、依存関係のボトルネックを解消します。これにより依存関係が完全に分離されるため、チームは最小限の設定で、手動によるインフラストラクチャのオーバーヘッドなしに、必要な dbt モデルを実行できます。
環境の更新: 新しいロールを追加したり、Python パッケージを更新したりするために、Airflow 環境全体を再デプロイする必要がなくなりました。
Gemini Cloud Assist による AI を活用したトラブルシューティング: セルフマネージド環境では、タスクが失敗すると、断片化されたログや指標でその原因を必死に探すことがよくありました。Checkout.com は、Managed Airflow を導入したことで、Google Cloud コンソールの Airflow DAG UI から直接 Gemini による調査を開始できるようになりました。

Gemini は一般的なエラーメッセージを提供するだけでなく、裏付けとなる証拠と矛盾する証拠の両方を含む、さまざまな仮説の評価スコアカードを生成します。これにより、平均復旧時間を大幅に短縮できます。

まとめ

Checkout.com にとって、Managed Airflow（第 3 世代）への移行が戦略的転換点となり、エンジニアが価値の提供に集中できる環境を整えることができました。

「Managed Service for Apache Airflow を導入したことで、効率、スケーラビリティ、信頼性が大幅に向上しました。マネージドインフラストラクチャ、自動スケーリング、迅速なデプロイ、分離された実行環境により、業務遂行に変革をもたらすことができました。」- Checkout.com、データプラットフォームエンジニア、Keisi Mancellari 氏

スケーラブルで費用効率に優れた、安定したプラットフォームを導入したことで、Checkout.com は自社のデータパイプラインの将来に集中できるようになりました。今後何が起こっても、自社のオーケストレーションレイヤで対応できると確信しています。

Managed Service for Apache Airflow の詳細と、このソリューションがいかにしてデータプラットフォームをサポートするかをご確認ください。

この投稿にご協力いただいた Serge Bouschet 氏と Keisi Mancellari 氏に心より感謝いたします。

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

- カスタマーエンジニア、Michelle Liu

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

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

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

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

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

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

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

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

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

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

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

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

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

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

影響と結果

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

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

今後の展望

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

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

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

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

エージェントでギアを上げる: ソフトウェア定義車両のセキュリティを確保

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

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

自動車業界は、新しいテクノロジーの導入を加速させるなかで、重要な岐路に立っています。従来のコネクテッドカーの時代は、ソフトウェア定義車両（SDV）の時代へと移行しました。SDV の時代は、多くの新機能が無線で提供され、急速にイノベーションが起こるのが特徴です。

次世代の SDV は、AI とエージェントを統合することで、未加工のテレメトリーをリアルタイムで実用的な分析情報に変換できるようになるため、車両が環境やユーザーとどのようにやり取りするかを根本的に考え直すことが可能になります。SDV のサポートとセキュリティを強化するために、Google Cloud と Valtech は提携して、Google Cloud 上に構築された、スケーラビリティの高い AI 対応のコネクテッドカープラットフォームである Nexus SDV を開発しました。この開発者向けのモジュール式オープンソースソリューションは、最大 1 億台のデバイスを管理できるように設計されており、Android Automotive OS（AAOS）と深く統合されているため、データフローと車内エクスペリエンスを合理化できます。

このたび、Nexus SDV のオープンソースコアの最初のリリースを発表いたしました。このコアは、Arm ベースのコンピューティングと Bigtable を通じて総所有コストをどのように削減できるかを示すとともに、次世代の自動車インテリジェンスを構築するための AI ネイティブ環境を提供します。

Nexus SDV での AI 主導のエクスペリエンス

Nexus AI はプラットフォームのインテリジェントエンジンとして機能し、車両を受動的なデータソースから能動的なエージェントパートナーに変えます。Nexus AI は、Gemini モデルと Gemini Enterprise Agent Platform を使用することで、複雑なテレメトリーをリアルタイムで分析し、自律的な意思決定と高度にパーソナライズされたドライバーサポートのための情報を提供できるため、ユーザーのニーズを予測するインテリジェントエージェントとして効果的に機能します。

重要なのは、この高度なインテリジェンスが、総所有コスト（TCO）の大幅な削減に重点を置いていることです。高効率の Arm ベースのコンピューティングと Bigtable 向けに最適化されたデータストレージを使用することで、このプラットフォームは大量のデータ処理に関連する運用コストを削減します。このモジュール式の AI ネイティブアーキテクチャにより、メーカーは、次世代の車両ソフトウェアに従来関連付けられていた高額なクラウド費用や開発費用をかけずに、フリートインテリジェンスを迅速にスケールできます。

クラウドネイティブな仕組み

Nexus SDV のアーキテクチャは、車両エッジとデータセンターのギャップを埋めるように設計された、モジュール式のクラウドネイティブな基盤上に構築されています。AAOS との深い互換性は、クラウドと車両の緊密な統合の要であり、高忠実度のテレメトリーがリアルタイムで取り込まれ、同期されることを保証します。この堅牢なデータループにより、Nexus AI はインテリジェントなアップデートとサービスを車両に迅速に push できます。

メーカーは、この開発者向けのオープンフレームワークを提供する Nexus SDV により、Google Cloud エコシステムのスケーラビリティと信頼性を活用して、SDV のライフサイクル全体を管理できます。

Architecture for Nexus SDV.

Google Cloud のセキュリティ管理機能による多層防御

安全性を重視した設計やゼロトラストアーキテクチャなど、Google のセキュアな基盤上に構築された Nexus SDV は、コンプライアンスと脅威保護に関わる煩雑な作業をサポートします。これを実現するために、Nexus SDV アーキテクチャは、6 つの主要な要素にわたって包括的な多層防御セキュリティモデルを実装しています。

相互 TLS（mTLS）と公開鍵基盤（PKI）Nexus SDV は、暗号化された信頼チェーンを利用して、データ交換が行われる前に車両を認証します。インフラストラクチャは Google Cloud Certificate Authority Service（CAS）を使用して、個別の CA プール（サーバー、工場、登録の CA）を管理し、可用性とセキュリティに優れたルートオブトラストを確保します。

具体的には、登録サーバーは、初期 TLS handshake 中にクライアントに有効な「工場出荷時」証明書を提示させることで登録を強制し、接続ストリームから直接証明書を抽出して解析することで、車両の ID を明確に証明します。登録中、サーバーは新しい運用証明書を発行する前に、車両から送信された証明書署名リクエスト（CSR）の検証を行います。

Identity and Access Managementこのシステムでは、Keycloak が中央の OpenID Connect（OIDC）ID プロバイダとしてデプロイされる ID ブローカリングを使用します。車両は、mTLS 経由で運用証明書を使用して Keycloak に対して認証を行い、有効期間の短い JSON Web Token（JWT）を受け取ります。

きめ細かいアクセス制御のために、カスタムの NATS 認証コールアウトサービスが動的なサブジェクト権限を提供します。このサービスは、すべてのメッセージングブローカー接続試行をインターセプトし、JWK 公開鍵を使用して Keycloak JWT を検証し、車両のロールを特定の NATS サブジェクトにプログラムでマッピングします。

サービス間のセキュアな通信には Workload Identity 連携を使用し、パイプラインが GitHub OIDC トークンを一時的な Google Cloud アクセス権と交換して静的認証情報を削除するようにします。一方、GKE Workload Identity では、Kubernetes サービスアカウントを Google サービスアカウントにバインドすることで、Kubernetes Pod が Bigtable などのバックエンドサービスにアクセスできるようにします。

制限付き IAM スコープによってセキュリティが強化され、専用のサービスアカウントが最小限の権限でプロビジョニングされます（データ API が Bigtable からの読み取りのみに制限されるなど）。デプロイコンテキストで VPC-SC、組織ポリシーの制約、Private Service Connect（PSC）を使用することも、セキュアな基盤の実現に役立ちます。

シークレット管理Nexus SDV は、一元化されたシークレット管理により、機密情報を保護します。すべての機密性の高い構成、データベースのパスワード、暗号署名鍵は、Terraform インフラストラクチャのプロビジョニング中に動的に生成され、Google Cloud Secret Manager 内に厳重に保管されます。

シークレットをアプリケーションコードやコンテナイメージに組み込むことを避けるために、デプロイ中にシークレットの取得が行われます。代わりに、サービスは署名鍵と認証情報を実行時にのみメモリに直接読み込み、保存時と転送時の両方でデータ漏洩のリスクを最小限に抑えます。

ネットワーク分離ネットワーク分離を強化するため、基盤となるコンピューティングインフラストラクチャは厳重に保護されています。Nexus SDV は、ワーカーノードにパブリック IP アドレスがないプライベート GKE クラスタで実行されるため、データがインターネットに直接公開されることはありません。さらに、Keycloak PostgreSQL データベースでは Cloud SQL IAM 認証が使用されています。これにより、Cloud SQL Proxy は静的なデータベースパスワードに依存したり、IP 許可リストを管理したりすることなく、IAM ロールを使用してセキュアに接続できます。

セキュア AI フレームワークGoogle Cloud は、セキュア AI フレームワーク（SAIF）のガイダンスに基づき、データプライバシー、モデルガバナンス、安全な実行を優先する包括的なエンタープライズグレードのフレームワークを通じて、これらの高度な AI 機能を保護します。Gemini Enterprise Agent Platform では、説明可能性と安全性の専用の管理機能、継続的な評価とモニタリング、セキュアなモデルレジストリなどの機能を通じて、セキュリティとガバナンスが ML ライフサイクルにネイティブに組み込まれています。

Google Cloud での AI の保護について詳しくは、こちらをご覧ください。

Data API Nexus SDV では、ダウンストリームアプリケーションや外部クライアントが Bigtable などのデータストアに直接アクセスすることを許可するのではなく、カスタムの Data API を介してデータ取得をルーティングします。このマイクロサービスは、セキュアな抽象化レイヤとして機能し、特定の車両 ID、センサーデータの種類、事前定義された時間枠のクエリなどを、厳しく制約された Bigtable の行範囲スキャンと列フィルタに厳密に変換します。

これにより、構造化されたデータアクセスパターンを適用するセキュアなゲートウェイとして機能します。

Nexus SDV の利用を始める

Nexus SDV は自動車インテリジェンスの新時代を象徴するものであり、セキュアで費用効率の高いエージェントプラットフォームを提供します。これにより、メーカーはオープンソースフレームワークで AI の力を最大限に活用できます。ソフトウェア定義車両をどのように再定義しているかについて詳しくは、こちらをご覧ください。

- 自動車 EMEA、業界アーキテクトリード、Florian Haubner

- CISO オフィス、シニアサイバーセキュリティアドバイザー、Vesselin Tzvetkov

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お試しください

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

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

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

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

AI の可能性からエージェント型の現実へ: 英国の新たな章を切り拓く

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

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

英国、特にロンドンは、ヨーロッパおよび世界における AI 開発の主要な拠点の一つであり続けています。もちろん、Google DeepMind の本拠地でもあり、Ineffable Intelligence のような重要な AI ユニコーン企業（Google Cloud のお客様）も存在します。Ineffable Intelligence は本日、Google との重要なパートナーシップを発表しました。

1 年前、Google はロンドンサミットに参加し、英国の公務員のスキルアップへの大規模な投資など、生成 AI の大きな可能性を紹介しました。本日、パートナー様を再び歴史ある Tobacco Dock の空間にお迎えするにあたり、その可能性は産業規模の現実となっています。ホワイトホール（政府機関）とシティ（金融街）のリーダーたちとの対話を通じて、焦点がチャットボットやメディアでの実験的な試みから、実運用を伴う本格的な実行へと移っていることを実感しています。今はエージェント型企業の時代です。単に会話するだけのシステムから、自ら推論し、計画を立て、複雑なワークフローを実行できるシステムへと進化を遂げようとしています。

この移行は、2030 年までに AI が英国経済にもたらすと予測される 4,000 億ポンドの経済効果の礎となるものです。Google Cloud は、エージェント型企業を現実のものにするために必要な完全統合スタック（カスタムシリコン、最先端モデル、グローバル規模のインフラストラクチャ）を提供する唯一のプロバイダです。

英国の企業と研究の新たなフロンティア

銀行業界は、この変化を実証する重要な場です。そして、世界最大級かつ極めて重要な金融機関の一つである HSBC は、その先駆者として道を示しています。このたび、Google は HSBC との複数年にわたる変革的なパートナーシップを発表し、HSBC のプロダクトとサービス全体で AI の導入をグローバルに加速させることになりました。この新たなコラボレーションにより、HSBC のグローバルな業務全体で AI を活用した働き方への移行がさらに加速します。

HSBC は、Google Cloud および Google DeepMind のエンジニアリングチームと連携して、新しい AI 搭載ツールとプログラムを共同開発します。これには、Gemini モデルや Gemini Enterprise Agent Platform などの Google の最新のエージェント型 AI 機能へのアクセスが含まれます。初期の展開では、3 つの分野に重点を置きます。具体的には、高度にパーソナライズされた資産管理サポート、金融犯罪リスク管理の強化、そして現場の担当者やリレーションシップマネージャーの顧客サービスを向上させる AI ツールです。

英国のスタートアップは、Ineffable Intelligence のような最先端の研究所の取り組みに示されているように、テクノロジー、特に AI で新たな境地を開拓し続けています。今年初めに設立された同社は、Google Cloud を優先クラウドパートナーとして選び、Google の AI 最適化ハードウェアとツールのフルスタックを活用して、Ineffable の第 1 世代の基盤モデルを構築、トレーニングしています。

AlphaGo プロジェクトで重要な役割を果たした元 Google DeepMind 研究者の David Silver 氏が率いる Ineffable Intelligence は、AI 開発に独自のアプローチを採用しています。このチームは、言語モデルの背後にあるような、人間が生成した大規模なデータセットに依存するのではなく、主に強化学習を通じて独自の経験から学習するシステムを構築しています。その野望は、試行錯誤を通じて知識を深める「スーパーラーナー」を作り出すというものです。今年、Ineffable Intelligence はヨーロッパのシードファンディングラウンドで 11 億ドルの記録を樹立しました。現在、同社は Google Cloud 上の NVIDIA Vera Rubin NVL72 プラットフォームを搭載した A5X の最大規模のクラスタの一つをデプロイすることで、トレーニング作業をサポートし、大規模なコンピューティングスケールを実現しています。

試験運用から本格的な実運用へと移行するには、企業はモデルを導入するだけでなく、明確なロードマップを必要としています。その道筋を示すため、Google は Deloitte とのパートナーシップを強化します。これに伴い、Deloitte はロンドンのキャンパスに新たな AI Studio を開設する予定です。Google Cloud とのコラボレーションで開発されたこのスタジオは、英国の組織が AI の試験運用から一歩進んで、自律的で行動指向の AI システムを大規模にデプロイできるよう支援します。

また、Deloitte は英国の AI およびデータ担当の従業員 1,000 人を対象に、Gemini Enterprise に関するスキルアップを支援することも表明しています。この認定プログラムにより、デロイトの AI およびデータエンジニアが Google の最先端のエージェントアーキテクチャを実装するための技術的専門知識を身につけ、英国のお客様に地域最大規模の認定 AI 人材プールを提供できるようになります。

将来を見据えた公共部門の構築

現代的なデジタル政府の青写真を実現するには、硬直化したレガシーな契約から脱却し、アジャイルで AI 主導の公共サービスへと転換することが求められます。住宅・コミュニティ・地方自治省（MHCLG）、i.AI インキュベーター、Google Deepmind、および Faculty との連携により、英国の「建設を促進する」という国家目標を直接的に支援する、実効性のある公共部門の改革と刷新のためのツールを実現しています。

MHCLG などの行政機関は、Google のテクノロジーを使用して構築された Extract というツールをすでに導入しています。このツールは、文書処理時間を 2 時間からわずか 2 分に短縮することで、計画策定プロセスの変革を推進しています。同時に Google は、バーネット、ドーセット、カムデンの各自治体と共同開発した AI 都市計画ツールの試験運用を支援しています。このツールは、一般的な申請における意思決定時間を 50% 短縮することを目指しています。さらに、英国運輸省（DfT）は、Gemini を活用してパブリックコンサルテーションの分析を効率化しており、年間 400 万ポンドの節約が見込まれています。

この規模のイノベーションには、安全で主権が確保された基盤も必要です。そのため、Google Cloud は英国におけるデータ所在地に関する取り組みを強化しており、その一環として、国内での AI 処理を特徴とする Gemini 3.5 Flash を、2026 年 6 月末までに機密性の高い主権ユースケース向けに提供する予定です。また、英国の組織が厳格なコンプライアンスの境界内でイノベーションを起こせるよう支援しています。

AI やその他のデジタル脅威を利用する悪意のあるアクターがもたらす課題からビジネスを保護するために、Google は最近、包括的な AI 搭載サイバーセキュリティプラットフォームである Google AI Threat Defense を発表しました。このプラットフォームは、Wiz、Mandiant、Gemini、CodeMender を組み合わせて、お客様の脆弱性を発見および修正し、安全を確保します。

小売業界から公共サービスまで、実証されたインパクト

自律型エージェントはもはや将来の予測ではなく、すでに英国経済全体に価値をもたらしています。e コマースソリューションプロバイダである THG Ingenuityとの取り組みでは、AI ショッピングアシスタントを通じてコンバージョン率が 8 倍に向上しました。同様に、Starling は、「支出インテリジェンス」ツールを提供することで、お客様が購入や支出の傾向を即座に分析できるようにしています。また、Rightmove は、Google の Gemini モデルを基盤とした AI 搭載の会話型物件検索ベータ版をリリースし、ユーザーが自分の言葉で物件を検索できるようにしました。

このインパクトの広さはあらゆる分野で確認できます。Kingfisher は小売業に特化したエージェント型アプリケーションを先駆けて開発し、Openreach は通信業界でフィールドサービスの最適化を推進しています。また、Unilever はバリューチェーン全体で AI を大規模に活用し、成長を促進して新時代の消費財において魅力的なブランドを構築しています。

一方、VMO2 は複雑なデータオペレーションを合理化し、Vodafone はネットワークパフォーマンスを再定義する 10 億ドルのパートナーシップを推進しています。また、WPP は、高品質なキャンペーンアセットの迅速かつ大規模な生成、AI エージェントの駆動、ロボットカメラオペレーターのトレーニングなど、クリエイティブワークフロー全体に Gemini を統合しています。

中小企業とスタートアップの成長エンジンを強化

英国の AI の成功の真価は、中小企業とスタートアップのエコシステムにあります。Google の AI Works 調査では、重要な転換点が浮き彫りになっています。AI は、中小企業の生産性を 20% 向上させ、英国経済に 1,980 億ポンドの生産額を創出する可能性を秘めています。小規模企業の 56% がすでに支援を求めていることを受け、Google は、どの企業も取り残されないように、AI Works for Britain スキル向上の取り組みを開始しました。

また、ロンドン AI ハブでは、Tech Nation との継続的なパートナーシップを通じて、次世代の英国ユニコーン企業の育成にも取り組んでいます。この継続的なコミットメントにより、創業者には事業拡大に必要なリソースとコミュニティが提供されます。今年 9 月には、ロンドンで Gemini Startup Forum: Cybersecurity を開催し、スタートアップが設計段階からセキュリティを考慮した AI アプリケーションを構築できるよう支援することで、このミッションをさらに推進します。

Platform 37 の Model Garden

英国の可能性に対する Google の信念は、物理的な拠点にも反映されています。Google は、増大する需要に対応するため、英国のデジタルインフラストラクチャへの投資を継続しています。2025 年 9 月にはウォルサムクロスに最先端のデータセンターを開設しました。これは、英国の AI 経済を活性化するために 2 年間で 50 億ポンドを投資する計画の重要な一環です。また、今年初めには、ロンドンのキングスクロスに新しいオフィス Platform 37 を開設しました。あわせて、AI の理解を深めるための新しい公共スペース「The AI Exchange」の計画も発表しています。

この勢いを活かし、2026 年第 4 四半期には Platform 37 の Model Garden を開設できることを嬉しく思います。ロンドンを拠点とするこのハブは、単なる物理的なスペースではありません。Google の最も重要なお客様との関わり方を根本的に向上させることを目的とした戦略的投資です。時代を超越した英国庭園の美学と、リビングデジタルウォールや 3 階建てのアトリウムなどの没入型ハイテクイノベーションを融合させた Model Garden は、Google の最高のアイデアを物理的に体験できる場所です。

エージェント型企業の青写真

英国の企業、行政リーダー、各種組織が AI の潮流をリードし続けるためには、活用するテクノロジーだけでなく、仕事の進め方の根本的なあり方も再考する必要があります。国内外の数千の組織と数百万のチームをサポートする中で、Google は AI で成功を収めるための 3 つのコア戦略を見出しました。

文化: 将来を見据えて組織を再構築する必要があります。真の変革とは、チームが AI エージェントとまったく新しい方法で協働できるよう、チームの意欲を高め、実行できる体制を整え、必要な環境を完備することです。これは単なる自動化ではなく、人と AI の協働を目指すものです。
責任: 設計段階から安全性とセキュリティを念頭に置いて構築する必要があります。ユーザー、顧客、ブランドの保護は最優先事項です。Google のフロンティアモデルは、厳格な AI 原則と、設計段階からセキュリティを考慮したインフラストラクチャを基盤として構築されています。
サステナビリティ: コンピューティング需要が高まる時代において、経済的に持続可能であり、かつ地球環境に貢献する方法で規模を拡大させる必要があります。Google は、24 時間 365 日カーボンフリーエネルギーを利用することに取り組んでおり、英国の AI の成長が気候変動目標の犠牲にならないよう確実なものにしています。

共に未来を築く

Google Cloud は、英国のエージェント型への移行における主要なパートナーです。私たちは、試験的な試みによる期待先行の段階を脱し、実運用における厳格なフェーズへと足を踏み入れています。キングスクロスの研究室から、小売業界を支える多様な企業まで、私たちは英国のレジリエントで、主権が確保された、繁栄ある未来を設計しています。

昨日、今日、そして未来に向けて、ロンドンで活動を共にしてくださる皆様に感謝申し上げます。今年は、特別なオンデマンドエクスペリエンスをご用意しました。ロンドンサミットの決定的な瞬間を、いつでもどこでもストリーミングで視聴いただけます。

- 英国、アイルランド、サハラ以南のアフリカ担当バイスプレジデント、Maureen Costello

Python で BigQuery を強化: マネージド Python UDF の一般提供を開始

Tue, 30 Jun 2026 02:00:00 +0000

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

SQL は、高パフォーマンスの構造化データ分析における業界標準です。しかし、複雑な手続き型ロジック、科学計算、高度な文字列操作、ML ワークフローを純粋な SQL で表現することは、不可能ではないにせよ、非常に困難な場合があります。このような作業は Python で行う方が適しています。また、データ実務者は、本来の業務に加えてインフラストラクチャの管理まで担うことがよくあります。たとえば、カスタムイメージやコンテナの保守、追加されたコンピューティングサービスの操作など、カスタム Python コードやライブラリで単純なヘルパー関数を実行するだけのために、余分な作業を強いられます。

こうした状況を踏まえ、このたび BigQuery マネージド Python ユーザー定義関数（UDF）の一般提供（GA）を開始しました。

このリリースは、BigQuery の拡張戦略における大きなマイルストーンです。これにより、データサイエンティスト、エンジニア、アナリストは、標準 SQL クエリや Python の BigQuery DataFrames（BigFrames）を使用して、BigQuery 内でカスタム Python コードを直接かつ安全に実行できるようになります。Python UDF は本番環境のエンタープライズワークロードで完全にサポートされ、BigQuery の課金 SKU に完全に統合されます。

SQL と豊富な Python エコシステムとの橋渡し

BigQuery マネージド Python UDF は、BigQuery が管理するサーバーレスリソースで実行され、インフラストラクチャのセットアップやコンテナの管理を必要とせずに、数十億行規模まで自動的にスケールされます。BigQuery は、Python コードのコンパイル、イメージの構築、セキュリティパッチの適用、デプロイ、実行を自動的に処理するため、SQL 内で Python 関数を使用することが極めて簡単になります。

主なメリット

柔軟性: NumPy、SciPy、pandas、scikit-learn などのトップクラスの科学 / 数学ライブラリを含む、広大な Python エコシステムに SQL の SELECT ステートメントから直接アクセスできます。
外部 API との緊密なインテグレーション: クエリ内で外部ウェブ API や Google Cloud サービス（Cloud Translation、Gemini Enterprise Agent Platform、カスタムマイクロサービスなど）を安全に呼び出すことで、BigQuery テーブルをリアルタイムでクリーニングおよび拡充できます。
フルマネージド、サーバーレス: BigQuery が基盤となるコンテナインフラストラクチャを管理し、パフォーマンスを動的かつ自動的にスケールします。

サンプルコード

以下は、よく利用されている Python パッケージである beautifulsoup を利用して、HTML タグを削除する Python UDF の例です。この関数を使用して、

BigQuery の一般公開テーブルに保存されている StackOverflow の回答本文を処理します。

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE FUNCTION `your_project.your_dataset.clean_html`(html_content STRING)\r\nRETURNS STRING\r\nLANGUAGE python\r\nOPTIONS (\r\n runtime_version = \'python-3.11\',\r\n entry_point = \'strip_tags\',\r\n packages = [\'beautifulsoup4>=4.12.0\']\r\n) AS r\'\'\'\r\nfrom bs4 import BeautifulSoup\r\n\r\ndef strip_tags(html_content):\r\n if not html_content:\r\n return ""\r\n soup = BeautifulSoup(html_content, "html.parser")\r\n return soup.get_text(separator=" ")\r\n\'\'\';'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e8c3c3310>)])]>

クエリの実行方法:

code_block: <ListValue: [StructValue([('code', 'SELECT \r\n id, \r\n `your_project.your_dataset.clean_html`(body) AS cleaned_answer_body\r\nFROM \r\n `bigquery-public-data.stackoverflow.posts_answers`\r\nLIMIT 100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e8c3c3370>)])]>

高度な機能

Python UDF には、上級ユーザー向けに、パフォーマンスの調整やモニタリングを行うための機能が追加されています。たとえば以下のようなものがあります。

Pandas PyArrow によるベクトル化処理スループットを最大化するため、GA リリースでは、ベクトル化された入力を PyArrow RecordBatch として直接処理できます。PyArrow は、データを行単位ではなく列単位で一括処理することで、Python のシリアル化や変換にかかるオーバーヘッドを排除し、データ集約型の計算において最大 10 倍のパフォーマンス向上を実現します。

構成可能なコンテナリソースデータサイエンスや ML のデータ準備などの負荷の高い処理において、関数ごとにコンテナのメモリ（最大 16 GB）と CPU（最大 4 vCPU）をプロビジョニングできるようになりました。これにより、メモリ使用量の多いワークロード（大規模なシリアル化されたモデルや地理空間データセットの読み込みなど）をサンドボックス内で直接実行できます。

カスタマイズ可能な同時実行数コンテナあたりの同時リクエスト数（最大 1,000 件の同時オペレーション）を構成することで、スループットとリソース効率を最適化できます。これにより、スケールアウト実行の費用対効果を大幅に向上させ、高負荷の並列処理下でも卓越したパフォーマンスを発揮できるようになります。

ログとリアルタイム指標のストリーミング本番環境のワークロードを簡単にデバッグおよびモニタリングできます。BigQuery コンソールでは、クエリ結果から Cloud Monitoring のリアルタイムの CPU、メモリ、同時実行の指標へ直接リンクできるようになりました。

課金

BigQuery マネージド Python UDF への課金は、BigQuery Services SKU に基づいて行われます。この SKU は、BigQuery の費用ベースの確約利用割引（CUD）の対象となるため、予算効率を最大化できます。

また、INFORMATION_SCHEMA.JOBS を通じて費用のオブザーバビリティを取得することもできます（請求ラベル MANAGED_ROUTINE_EXECUTION と MANAGED_ROUTINE_BUILD を使用）。

詳細については、ドキュメントの料金セクションをご覧ください。

ご利用にあたって

BigQuery Python UDF の使用を開始するには、まずプロダクトドキュメントをご覧ください。

次に、BigQuery 一般公開データセットとして公開されている関数をお試しください。たとえば、BigQuery プロジェクトで次のコードを実行して、BigQuery の一般公開データから国名のデータをトークン化します。内部的には、このトークン UDF は o200k_base トークナイザーライブラリを利用しています。

code_block: <ListValue: [StructValue([('code', 'SELECT \r\n country_code,\r\n country_name,\r\n `bigquery-public-data`.python_udfs.tokenize(country_name) AS name_tokens,\r\n ARRAY_LENGTH(`bigquery-public-data`.python_udfs.tokenize(country_name)) AS token_count\r\nFROM \r\n `bigquery-public-data.census_bureau_international.country_names_area`\r\nORDER BY \r\n country_name'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e8c3c33d0>)])]>

または、こちらの Codelab を試して、より高度なシナリオについてご確認ください。

他の高度な設計パターンを実装する方法については、Google の公式の一般公開ドキュメントガイドをご覧ください。

Google Cloud またはオンラインサービスを呼び出す（接続あり）: Gemini Enterprise Agent Platform や Cloud Translation などのファーストパーティの Google Cloud サービス、または外部 API エンドポイントに Cloud リソース接続を使用して安全に接続する方法については、Python コードで Google Cloud またはオンラインサービスを呼び出すの説明をご参照ください。
BigQuery DataFrames（BigFrames）Python UDF: BigQuery DataFrames を使用して、標準の Jupyter ノートブック環境や Colab 環境からカスタム Python 関数をネイティブに記述、デプロイ、スケールする方法については、BigQuery DataFrames 用の Python 関数のカスタマイズの説明をご参照ください。

今すぐ Python ワークフローを孤立した状態から解き放ち、データウェアハウスの中核に直接組み込みましょう。

- グループプロダクトマネージャー、Sandeep Karmarkar

- テクニカルリード、Chao Shen

Siemens が「象の切り分け」（細分化）により産業用ソフトウェア開発のエージェントワークフローを推進

Thu, 25 Jun 2026 02:00:00 +0000

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

Siemens のようなテクノロジー企業では、ソフトウェアは世界中の工場、エネルギー網、輸送ネットワークを結びつける、人体で言えば神経系のような役割を果たしています。

産業用 AI、産業用ソフトウェア、産業オートメーションのグローバルリーダーである Siemens には、工場やプロセスの自動化、エネルギーインフラストラクチャ、インテリジェントな輸送など、数十年にわたるドメインの専門知識の蓄積があります。これは、既製の AI ソリューションでは再現できないものです。しかし、イノベーションにあたってはレガシーコードが重い足かせとなっています。

10 年以上にわたって開発された数億行に及ぶコードベースを持つ Siemens は、標準的な AI ツールでは解決できない課題に直面していました。それは、このコードと、その上で実行されるアプリケーションを理解し、モダナイズすることです。産業グレードのソフトウェアの規模と複雑さには、根本的に異なるアプローチが必要です。既存のコーディングアシスタントには、複雑な多層構造の産業用コードベースをナビゲートするために必要なコンテキストの深さが欠けており、このギャップを埋める必要がありました。

この問題を解決するために、Siemens と Google Cloud は、ソフトウェア開発ライフサイクルを自動化する AI システムである Knowledge Fabricを作成しました。このエージェントは、Spanner Graph のナレッジグラフ、Google Agent Development Kit、Gemini API、Agent Platform、Gemini CLI、Anthropic Claude Code を使用して構築されました。既存のフロンティアをウェブベースのインターフェースに移行するパイロット版では、Knowledge Fabric によって実装作業が軽減され、エンジニアはシステムとの完全な互換性を維持しながら、顧客のイノベーションに集中できるようになりました。

「ソフトウェアエコシステム全体を、カスタムナレッジグラフを備えたインテリジェントなエージェントシステムに取り込むことで、開発者が開発時間を最適化できるよう支援するだけでなく、自律エージェントが過去を推論して未来を構築できるようにします。これにより、エンジニアは反復作業から解放され、より価値の高い問題解決に集中できるようになります」と、Siemens のプロダクトクリエーションエクセレンス担当シニアバイスプレジデントである Franz Menzl 氏は述べています。

課題: 産業用ソフトウェアの複雑さ

大規模な産業グレードのソフトウェアシステムのモダナイゼーションは、飛行機を飛行中に改修するようなものだとよく言われます。Siemens が直面した課題には次の 4 つの側面がありました。

規模: リポジトリは膨大で、標準的な大規模言語モデルのコンテキストウィンドウをはるかに超えています。
断片化: 重要な知識が、コード、Jira チケット、Confluence ページ、2000 年代初頭にスキャンされた PDF マニュアルに散在していました。
複雑さ: 特定のコード行が 10 年前の機能要件定義書のどこに該当するのか追跡することは、手作業や従来のツールでは効率的に対処できない課題となっていました。これは業界全体が共通して抱えている現実です。
責任: システムは、多くの場合 15～20 年以上にわたる運用期間にわたって、厳格な品質、コンプライアンス、ライフサイクルの要件を遵守する必要があります。そのため、AI によって生成された出力は、説明可能で、追跡可能で、検証可能でなければなりません。ハルシネーションや検証されていない変更は、非効率的であるだけでなく、運用上も許容できません。

「標準の RAG（検索拡張生成）では不十分であることがわかりました。コードは単なるテキストではなく、固有の構造を持っています。クラスはファイルに属し、ファイルはモジュールに属します。これをベクトルデータベースにフラット化すると、コードベースの要素間の関係性の表現が失われてしまいます」と、Google Cloud のテクニカルリードである Agata Gołębiowska は言います。

解決策: ドメインを認識する Knowledge Fabric

この広大なソフトウェア環境を AI 主導のワークフローでナビゲートできるようにするため、チームは Knowledge Fabric エージェントを構築しました。このエージェントは、キーワードの一致だけでなく、アセット間の関係を「理解」します。

Spanner Graph を使用してコードベースの固有の構造をモデル化し、あらゆる形式のドキュメントに対しても同様に厳密なアプローチを適用しています。これらのドメイン間の接続をマッピングすることで、特定のコードスニペットを設計ドキュメントの要件に直接関連付けることができます。次にエージェントは、ツールを使用して Graph Query Language（GQL）で構造をクエリし、このグラフを走査します。

しかし、GQL はその一部にすぎません。セマンティックな理解を可能にするために、Spanner の近似最近傍（ANN）アルゴリズムを使用してすべてのノードのエンベディングを生成し、コードベース全体で効率的なベクトル検索を実行します。最後に、エージェントに全文検索機能を提供します。この機能は GQL と組み合わせて、ノードとエッジを正確に特定できます。

これら 3 つの方法を組み合わせることで、LLM エージェントは「Axis Control Panel のロジックを変更した場合、どの関数を更新する必要がありますか？」といった複雑なクエリに回答できます。システムは、キーワードと意味的類似性を考慮してグラフを走査し、依存関係を特定して関連ドキュメントを取得し、正確な影響分析を提示します。

この正確なコンテキストにより、コーディングエージェントは有効で、使用可能で、保守可能な実装を生成できます。

「象の切り分け」: エージェントワークフロー

このプロジェクトから得られた重要な知見は、AI エージェントは大規模で曖昧なタスクを苦手としているということです。成功を収めるために、チームは「象の切り分け」という設計パターンを採用しました。

このシステムは、「このモジュールをリファクタリングする」のような広範なリクエストを、より管理しやすい小さなタスクに分割します。各タスクは、Google Agent Development Kit（ADK）で構築された専門のエージェントによって処理されます。

検索エージェント: 詳細な調査のスペシャリストとして機能します。ツールを使用してコードグラフを探索し、エージェント検索でドキュメントと調査結果を相互参照します。
ユーザーストーリーエージェント: プロダクトオーナーにインタビューして要件を収集し、既存のシステムコンテキストにリンクされた受け入れ基準を含む詳細なユーザーストーリーの下書きを作成します。
アーキテクチャの影響エージェント: グラフに対して提案された変更を分析し、コード行の記述を開始する前に副作用を予測します。
タスク分解エージェント: アーキテクチャの影響エージェントからの分析結果を使用し、作業を管理しやすい小さなタスクに分解します。各タスクには、特定の変更に関連するすべてのコンテキストが含まれます。
コーディングエージェント: 特定のタスクで説明されている変更を実装します。コンテキストや事前分析なしにこのステップに進んでも、実用可能なコードは生成されません。

このシステムでは、すべてのステップで人間が関与するため、本番環境レベルの信頼性の高い成果が保証され、エンジニアはルーチン的な実装作業から解放され、有意義な作業に集中できます。

Siemens のプロジェクトリードである Alexander Lomakin 氏は次のように述べています。「象の切り分け、つまり、複雑なリファクタリングジョブを、エージェントが主導する小さなタスクに分割することで、生産性が大幅に向上しました。AI の複雑な構造をナビゲートするために必要なロードマップを与えたということです。」

パイロット運用の結果: エンジニアリングの迅速化と効率化を実現

デベロッパーはほぼ即座にその成果を確認できました。

新機能の依存関係を分析するには、以前はシニアエンジニアが数日かけてコードベースと従来のドキュメントを調べる必要がありました。Knowledge Fabric を使用すると、同じ作業にかかる時間が大幅に短縮されます。

最近の試験運用では、従来のコントロールパネルを最新のウェブベースのインターフェースに移行する際に、Knowledge Fabric によってシステムの完全性と産業品質基準を維持しながら、コーディング作業全体が削減されました。

エンジニアは、反復作業に費やす時間を減らし、顧客価値の創出により多くの時間を費やせるようになりました。

使ってみる

Knowledge Fabric は、生成 AI がボイラープレートコードの作成だけでなく、ビジネスが最も依存するレガシーシステムのモダナイゼーションにも役立つことを示しています。

グラフベースのエージェントを構築してレガシーをモダナイズする方法の詳細については、以下をご覧ください。

Spanner Graph について読む。
Agent Platform を確認し、Agent Garden で事前構築済みの本番環境グレードのエージェントを見つける。
Agent Development Kit を確認する。
Siemens が産業用 AI をどのように推進しているか詳細を確認する。

- Google、グループプロダクトマネージャー兼 AI エンジニア、Anant Nawalgaria

- Google、スタッフソフトウェアエンジニア、Tomasz Świtoń

Looker エージェントでダッシュボードをインタラクティブなデータエクスペリエンスに変革

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

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

ダッシュボードは、データからインサイトを引き出すための主要な手段として長年活用されてきましたが、アジャイルな環境では不十分な場合があります。ダッシュボードはインタラクティブではなく、追加の質問をすることもできないため、必要な回答を得るために、ワークフローから離れたり、データアナリストに頼ったりする必要がありました。こうした課題に対処するために、このたび、Looker ダッシュボードエージェント（プレビュー版）を発表しました。これは、インテリジェントな会話型データエージェントをダッシュボードに直接組み込むことで、ユーザーが自然言語を使用してビジネスインテリジェンス（BI）データを探索できるようにするものです。

Looker ダッシュボードエージェントとの会話の例

エージェント主導のインタラクティブな調査

従来のダッシュボードはデータの静的なビューを表示するものでした。Looker のダッシュボードエージェントを使用すると、ユーザーはダッシュボードのインターフェース内で直接データを探索できます。Gemini アイコンをクリックして会話を開始し、自然言語で質問することで、コンテキストに沿ったインサイトを得ることができます。

データエージェントの精度は、提供されるビジネスコンテキストと、ユーザーの問い合わせに対して適切な指標やディメンションをマッピングする能力に依存します。Looker ダッシュボードエージェントは、ユーザーが適用しているフィルタ、クロスフィルタ、事前にキュレートされたタイルについてコンテキストを直接参照できるため、複雑なビジネス上の質問に対しても、極めて関連性が高く正確な回答を生成できます。

クエリにより多くのデータが必要な場合、エージェントは基盤となる Explore にアクセスして追加情報を抽出できます。これらのインサイトには、関連するグラフや自然言語の説明が添えられており、データ探索を簡素化できます。

ダッシュボードの枠を超えてデータを探索し、より深いインサイトを引き出す

ビジネスに合わせてエージェントをカスタマイズ

データアナリストは、ビジネスユーザーが組織のデータを正確に把握できるよう、ダッシュボードをキュレートしています。こうした一貫性と信頼性の高い分析環境を維持するために、Looker ダッシュボードエージェントは高度に構成可能な設計になっています。アナリストは、エージェントに対して自然言語で直接指示することで、Looker のセマンティックレイヤにコンテキストを追加できます。これにより、エージェントが独自のビジネスロジックを解釈する方法や、対象ユーザーに合わせて回答を調整する方法を正確に定義できます。ダッシュボードエージェントは、セルフサービスでのデータ分析を可能にすることで、ビジネスの増大するデータ需要にアナリストチームが対応できるよう支援します。

Looker ダッシュボードエージェントの構成

信頼性と透明性を継承

ユーザーが AI ベースのシステムを採用するには、そのシステムが提供する情報を信頼できる必要があります。Looker ダッシュボードエージェントは、インサイトを生成する際、中間の推論、参照したダッシュボードタイル、適用したフィルタを表示することで、そのプロセスを明示的に示します。さらに、管理者は、ユーザーがアクセスできるデータや分析情報が、そのユーザーに権限が付与されているものだけであることを信頼する必要があります。ダッシュボードエージェントは、標準の権限を通じて管理される Looker のガバナンスモデルによって支えられています。

iframe の埋め込みのサポートなど、Looker ダッシュボードエージェントの追加機能の開発も積極的に進めています。今後、Looker ダッシュボードとともにダッシュボードエージェントを重要なポータルやアプリケーションに組み込めるようにする予定です。

ダッシュボードエージェントを使ってみる

Looker バージョン 26.08.11 以降では、管理者が Gemini in Looker の設定で [ダッシュボードでチャットを有効にする] を切り替えることで、ダッシュボードエージェント機能を有効にできます。有効にすると、権限のあるユーザーには Gemini アイコンが表示され、ダッシュボードのデータとのチャットをすぐに開始できます。詳細については、サポートドキュメントをご覧ください。

- プロダクトマネージャー、Vaibhavi Sonavane

データエージェントの新機能: AI ワークフローの強化

Tue, 23 Jun 2026 02:00:00 +0000

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

AI エージェントの台頭は、アプリケーションや分析システムに根本的な変革をもたらしています。汎用的な AI プラットフォームは通常、企業データベースに保存されているコンテキストにアクセスできません。これは、従来のデータアーキテクチャでは、データ資産全体にわたってエージェント向けのコンテキストが欠如していることが多く、エージェントの精度の低下につながる可能性があるためです。また、きめ細かなアクセス制御が不足しているため、セキュリティギャップが生じやすい傾向もあります。

Google の Agentic Data Cloud は、運用システムと分析システムの両方を備えた、AI ネイティブなアクションシステムです。カスタムシリコンから最先端の Gemini モデルまで、スタック全体に AI を組み込むことで、エージェントがリアルタイムの企業データに基づいてほぼ 100% の精度で推論できる、テンプレートを使用した決定論型のデベロッパーフレームワークと、統合されたガバナンスを提供します。

このたび Google は、より簡単にエージェントを開発できるようにするため、多数のデータエージェントとツールを新たに導入いたしました。具体的には、ビジネスアナリスト向けの会話型分析、自動化とインテリジェンスを強化する、データサイエンティスト、エンジニア、データベース管理者向けの一連の Google 製データエージェント、現在のオープンなエージェントエコシステムとの統合を強化する、デベロッパー向けのデータエージェントツールです。

1. 会話型分析

自然言語を使用してエージェントを構築するデベロッパーを支援するため、データクラウド全体にわたって会話型分析対応を拡充することをお知らせいたします。

BigQuery の会話型分析（プレビュー版提供中）では、高度な AI 推論エンジンが BigQuery Studio に直接組み込まれています。これにより、データチームやビジネスチームは、手動で SQL を記述するだけでなく、ビジネスコンテキストを活用したマルチモーダル統合と詳細な調査を使用して、回答をグラウンディングできます。また、一部のお客様にプレビュー版が提供されている Agentic Workflows は、根本原因分析を自動化し、アクションをスケジュール設定して、企業データをプロアクティブで実用的なインテリジェンスに変換します。

BigQuery の会話型分析でエージェントを作成し、データ分析情報を迅速に取得する

Lakehouse の会話型分析（プレビュー版提供開始）は、Lakehouse の統合インフラストラクチャを拡張し、ユーザーが自然言語を使用して、AWS、Azure、Google Cloud に分散したデータレイクに対してクエリを実行できるようにします。これにより、データを 1 バイトも移動させることなく、クラウドプラットフォーム全体で分析情報を統合することが可能になります。
AlloyDB、Spanner、Cloud SQL の会話型分析（いずれもプレビュー版を提供開始）は、すぐに使える会話型 AI をサポートしているため、誰でもデータにアクセスできるようになります。AlloyDB、Spanner、Cloud SQL のユーザーは、自然言語でデータベースと会話をして、リアルタイムの運用データの可視化や分析情報の取得を行うことができます。

会話型分析を使用して、運用データから回答を得る

Looker 埋め込み会話型分析（一般提供開始）では、ローコードの iframe 実装を介して、エージェントをカスタムアプリケーションや社内ワークフローに直接埋め込むことができるため、プロダクションレディな会話型 AI をあらゆるアプリケーションに簡単に組み込むことができます。さらに、Looker の Conversational Analytics API を使用すると、AI による推奨事項を提供するマルチターンの会話型ワークフローを作成できるだけでなく、その基盤となる SQL クエリの検証と説明も行うことができます。また、すでに一般提供されている Looker の核となる会話型分析エージェントも大幅にアップグレードされ、優れた推論とセマンティックグラウンディングにより、曖昧さを解消できるようになります。

会話型 AI のためにエージェントをアプリケーションに直接埋め込む

2. 新たなデータエージェント

データプロフェッショナルが事後対応型のデータ管理から事前対応型のインテリジェンスに移行し、ビジネスアナリストがダッシュボードをより効果的に操作できるよう、Google は、自動化、インテリジェンス、自然言語機能を日々のワークフローに提供する新たなデータエージェントを発表いたします。

データエンジニアリングエージェント（一般提供開始）は、データパイプラインの構築や維持管理といった手間のかかる作業を自動化します。自然言語の要件を BigQuery と Dataflow 向けに最適化された SQL または Python コードに変換するとともに、パイプラインの障害を事前対応的に特定して修正します。スキーマの改善やパーティショニング戦略を提案することにより、手動で試行錯誤する必要なく、スケーラブルで信頼性の高い、パフォーマンスが調整されたデータ基盤を確保できます。
データサイエンスエージェント（プレビュー版提供開始）は、元データからプロダクションレディなモデルへの移行を加速させます。関連する特徴の提案、ボイラープレートノートブックコードの生成、技術ドキュメント処理の自動化を通じて、データサイエンティストを支援します。
データベースオブザーバビリティエージェント（Cloud SQL、AlloyDB、Spanner、Bigtable の一部のお客様にプレビュー版を提供中）は、データベースのパフォーマンスを事前対応的にモニタリングし、潜在的な問題が深刻化する前に、継続的に特定します。その後、インテリジェントな推奨事項とマルチターンの修復ワークフローを提供し、迅速かつ包括的なトラブルシューティングと最適化を実現します。また、データベースフリート全体のパフォーマンス分析機能は、データベース全体のパフォーマンスを最適化する機会を迅速に特定するのに役立ちます。
データベースオンボーディングエージェント（一部のお客様にプレビュー版を提供中）は、推測に頼らずにデータベースの選択やデプロイができるようにします。単純なユースケースの説明から複雑な企業ニーズまで、さまざまな要件の評価をもとに、最適な Google Cloud データベースを推奨し、プロビジョニングのプロセスを支援します。
Looker ダッシュボードエージェント（プレビュー版提供開始）では、ダッシュボード内のデータと会話形式でやり取りできます。ダッシュボード内で、ユーザーは自然言語で質問し、コンテキストを認識した回答を受け取ることができます。この機能では、ダッシュボードから得られた重要なポイントや分析情報をまとめた、AI 生成による要約も提供されます。
Gemini Enterprise の会話型分析（プレビュー版提供開始）は Looker、BigQuery、Lakehouse に対応しており、データ実務者が構築した、管理されたインテリジェンスをビジネスリーダーに直接提供します。これは、Google データクラウドへの「正面玄関」として機能し、ビジネスユーザーは技術コンソールにアクセスすることなく、BigQuery、Looker、Lakehouse で構築されたエージェントを利用できるようになります。これらのエージェントを Google データから Gemini Enterprise に公開することにより、組織は正確なデータ探索と即時の回答のためのグラウンディングされた単一のインターフェースを、ビジネスユーザーに提供します。
Data Insights エージェント（プレビュー版提供開始）は、構造化されたソース（BigQuery や Snowflake など）と構造化されていないデータ（会議メモや公開ウェブ情報など）を同時にクエリすることで、Gemini Enterprise 内のデータ資産に関する総合的な分析情報を提供します。このエージェントは、日常業務で利用するユーザー向けの迅速な応答エンジンとして機能し、Workspace エコシステム（ドキュメント、スプレッドシート、ドライブ）や、Jira、HubSpot などのサードパーティ製アプリの情報を統合します。このエージェントは、インタラクティブな可視化機能を豊富に備えており、時間の経過とともにユーザーの好みに合わせて継続的に学習します。
Deep Research エージェント（プレビュー版提供開始）は、Knowledge Catalog を使用して、リスクの高い多層的なビジネス上の問題を解決します。単なる検索にとどまらず、社内ドキュメント、BigQuery テーブル、公開ウェブの情報を統合して包括的な調査計画を策定します。その結果、企業のプライバシーとユーザーの権限を常に尊重しながら、動的な可視化と検証可能な引用を使用した詳細なレポートが生成されます。

3. データエージェント向けのツール

エージェント開発向けのオープンソース標準は、AI アプリケーションやカスタムエージェントを構築するデベロッパーに対し、データやツールに一貫性を持って安全にアクセスするための統合フレームワークを提供します。このたび Google は、エージェント開発の取り組みを支援する、以下のツールを発表いたします。

Data Agent Kit（プレビュー版提供開始）は、好きな開発環境（IDE / CLI）内で直接使用できる標準化されたスキルとツールのスイートを提供し、データ実務者が Agentic Data Cloud 機能の規範的なガイダンスを使用して、データを大規模に検出、変換、活用できるようにします。
データベース向けマネージド MCP サーバー（一般提供開始）は、AlloyDB、Spanner、Cloud SQL、Bigtable、Firestore で利用でき、AI モデルをデータに安全に接続するために必要なインフラストラクチャを完全に管理します。そのため、MCP サーバーをお客様ご自身でホスト、保護、スケーリングする必要はありません。これにより、デベロッパーは Google のデータベースポートフォリオ全体から最新のコンテキストをエージェントに提供できるようになり、AI モデルは最新の企業データに基づいて推論や行動ができるようになります。
Looker 向けマネージド MCP サーバー（プレビュー版提供開始）を使用すると、あらゆる MCP クライアントやエージェントプラットフォームで Looker のセマンティックモデルをクエリできるようになり、管理された BI 分析情報をサードパーティ製アプリケーション全体に拡張できるようになります。

マネージド MCP サーバーを介して Looker セマンティックモデルにアクセスする

データベース向け MCP ツールボックス 1.0（一般提供開始）は、安定性における大きなマイルストーンを達成し、本番環境アプリケーションを安心して構築できるようになりました。また、ドキュメントを全面的に見直し、人間の開発者にとっても自律型エージェントにとっても、プラットフォームがはるかに使いやすくなりました。
Cloud SQL、AlloyDB、Spanner 向け QueryData（いずれもプレビュー版提供開始）は、自然言語の質問をデータベースクエリに変換します。各 QueryData はこれらのデータベースにネイティブに組み込まれており、メタデータ、クエリの例、評価を通じて、自然言語から SQL への変換をほぼ 100% の精度で実現します。
BigQuery を活用した Universal Commerce Protocol（UCP）分析（プレビュー版提供開始）により、販売者やデベロッパーは UCP から BigQuery にリアルタイムイベントを直接ストリーミングできるようになります（サンプルを参照）。この統合により、エージェント型コマースでオブザーバビリティ機能がすぐに使えるようになり、チームはコンバージョンプロセスのモニタリング、自動購入手続きのパフォーマンスの追跡、システムエラーの特定が可能になります。BigQuery 内でこれらの指標を標準化することで、企業は AI によるトランザクションと既存のビジネスインテリジェンスワークフローのギャップを埋めることができます。

新しいエージェントやツールへのアクセス方法について詳しくは、このページにある各ドキュメントへのリンク先をご覧ください。また、データエージェントは、Gemini Enterprise と Google Cloud コンソールからもご利用いただけます。

- Google Cloud、プロダクト管理担当、Sean Rhee

- Google Cloud、アウトバウンドプロダクト管理責任者、Geeta Banda

Open Knowledge Format のご紹介

Mon, 22 Jun 2026 02:00:00 +0000

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

基盤モデルは進化を続けていますが、関連するコンテキストが不足していると、特にエージェントシステムの構築に使用される場合に、できることが制限されることがよくあります。これらのモデルは、コードの作成、ドキュメントの要約、データセットの分析に役立ちますが、正確で実用的な結果を生成するには、適切な情報が必要です。

そこで本日は、LLM-wiki パターンを移植可能で相互運用可能な形式にするオープン仕様である Open Knowledge Format（OKF）をご紹介します。これは、最新の AI システムに必要なメタデータ、コンテキスト、キュレートされたナレッジを表すための、ベンダーに依存しない、エージェントと人間にとって扱いやすい標準です。

公開されている OKF v0.1 は、YAML フロントマターを含む Markdown ファイルのディレクトリとしてナレッジを表します。また、少数の合意された規則が用意されているため、さまざまなプロデューサーが作成した Wiki を、さまざまなエージェントが変換なしで利用できます。

それだけです。複雑な圧縮スキーム、新しいランタイム、必要な SDK はありません。OKF ドキュメントのバンドルの特長は次のとおりです。

Markdown のみ - どのエディタでも読み取り可能、GitHub でレンダリング可能、どの検索ツールでもインデックス登録可能
ファイルのみ - tarball としてリリース可能、任意の Git リポジトリでホスト可能、任意のファイルシステムにマウント可能
YAML フロントマターのみ - クエリ可能である必要がある少数の構造化フィールド（タイプ、タイトル、説明、リソース、タグ、タイムスタンプ）用

Obsidian、Notion、Hugo、または過去 1 年間に登場した LLM wiki パターンを使用したことがある方なら、その形式に馴染みがあるでしょう。OKF は、これらのパターンを相互運用可能にするために必要な少数の規則を正式に定めています。

OKF で解決できる組織の問題や、その仕組み、利用開始方法、今後の展開について見ていきましょう。

コンテキストが断片化された現状

ほとんどの組織では、基盤モデルが使用する情報の圧倒的多数が社内ナレッジです。たとえば、テーブルのスキーマ、ビジネスにおける指標の意味、インシデントのランブック、2 つのシステム間の結合パス、古い API のサポート終了のお知らせなどです。

現在、これらのナレッジの原子は、次のような、断片化が進んださまざまなシステムに存在しています。

独自の API があるメタデータカタログ
Wiki、サードパーティシステム、共有ドライブ
コードコメント、ドキュメント文字列、ノートブックセル
数名のシニアエンジニアの頭

AI エージェントが「イベントストリームから 1 週間のアクティブユーザー数を計算するにはどうすればよいですか？」という質問に答える必要がある場合、これらの散在した、相互に互換性のないサーフェスから回答を組み立てる必要があります。各ベンダーは独自のカタログ、独自の SDK、独自のナレッジグラフスキーマを提供しており、ナレッジをプロダクト間や組織間で簡単に移植することはできません。

その結果、エージェント開発者は皆、コンテキストの組み立ての同じ問題をゼロから解決し、カタログベンダーは皆、同じデータモデルを再考し、知識そのものは、それを生成したサーフェスの背後に閉じ込められています。

現実の Wiki としてのナレッジ

開発チームは、AI エージェントの構築方法を変えつつあります。モデルを使用して同じドキュメントで同じ事実を何度も検索する代わりに、エージェントに、時間の経過とともに有用性が高まる共有 Markdown ライブラリを提供できます。これにより、エージェントは自分のファイルを読み取って更新するという面倒な作業を引き受けることができ、チームはコンテンツをキュレートしてコードのように管理できます。

著名な AI 研究者であり教育者でもある Andrej Karpathy 氏は、LLM Wiki の要約でこの考えを最も簡潔に説明しています。「LLM は飽きることがなく、相互参照の更新を忘れることもなく、1 回のパスで 15 個のファイルに触れることができます」と同氏は書いています。人間が個人用 Wiki を放棄する原因となる記帳は、まさに LLM が得意とするところです。

同様の「Wiki としてのナレッジ」パターンは、コーディングエージェントに接続された Obsidian vault、AGENTS.md / CLAUDE.md ファミリーの規約ファイル、エージェントが実際の作業を行う前に参照する index.md と log.md のアーティファクトでいっぱいのリポジトリ、データチーム内の「コードとしてのメタデータ」リポジトリなど、さまざまな名前で繰り返し現れています。

このパターンは魅力的で強力ですが、各インスタンスはカスタムメイドです。Karpathy 氏の Wiki、あなたのチームの Wiki、ベンダーのカタログのエクスポートはすべて似たようなもの（Markdown、フロントマター、クロスリンク）に見えるかもしれませんが、それらのいずれも連携するように意図的に設計されているわけではありません。すべてのドキュメントに含めるべきフィールドやファイル名の意味について、合意された答えはありません。その結果、Wiki にエンコードされたナレッジは元のチーム内でサイロ化されたままとなり、新しいエージェントが構築されるたびに冗長な作業が発生します。

欠けているのは形式であり、別のサービスではない

この問題の解決策は、別のナレッジサービスではありません。次のようなナレッジを表現する方法として、形式が必要です。

SDK なしで誰でも作成できる
統合なしで誰でも利用できる
システム、組織、ツール間を移動しても存続する
記述するコードとともにバージョン管理に保存される
人間が読めてエージェントが解析できる: 同じファイル、変換レイヤなし

OKF は、そのように設計された形式です。

OKF の仕組み: 1 画面でわかる設計

OKF バンドルは、コンセプトを表す Markdown ファイルのディレクトリです。コンセプトとは、テーブル、データセット、指標、ハンドブック、ランブック、API など、キャプチャしたいあらゆるものです。各コンセプトは 1 つのファイルです。ファイルパスはコンセプトの ID です。

code_block: <ListValue: [StructValue([('code', 'sales/\r\n├── index.md\r\n├── datasets/\r\n│ ├── index.md\r\n│ └── orders_db.md\r\n├── tables/\r\n│ ├── index.md\r\n│ ├── orders.md\r\n│ └── customers.md\r\n└── metrics/\r\n│ ├── index.md\r\n └── weekly_active_users.md'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e834477c0>)])]>

各コンセプトドキュメントには、構造化されたフィールド用の YAML フロントマターの小さなブロックと、その他すべてのもの用の Markdown 本文があります。

code_block: <ListValue: [StructValue([('code', '---\r\ntype: BigQuery Table\r\ntitle: Orders\r\ndescription: One row per completed customer order.\r\nresource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders\r\ntags: [sales, revenue]\r\ntimestamp: 2026-05-28T14:30:00Z\r\n---\r\n\r\n# Schema\r\n\r\n| Column | Type | Description |\r\n|---------------|-----------|------------------------------------------|\r\n| `order_id` | STRING | Globally unique order identifier. |\r\n| `customer_id` | STRING | FK to [customers](/tables/customers.md). |\r\n\r\n# Joins\r\n\r\nJoined with [customers](/tables/customers.md) on `customer_id`.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e83447820>)])]>

コンセプトは通常の Markdown リンクで相互にリンクされ、ディレクトリを、ファイルシステムが暗示する親子リンクよりも多様な関係のグラフに変えます。バンドルには、必要に応じて index.md ファイル（エージェントが階層をナビゲートする際の段階的な開示用）と log.md ファイル（変更の時系列履歴用）を含めることができます。

v0.1 の完全な仕様（適合基準、相互リンクのルール、少数の予約済みファイル名を含む）は、1 ページに収まります。

設計の 3 つの原則

1. 制限が最小限。OKF で必要なものは 1 つだけで、それは各コンセプトのタイプフィールドです。それ以外のすべて（どのようなタイプが存在するか、他にどのようなフィールドを含めるか、本文にどのようなセクションがあるかなど）は、プロデューサーに任されます。仕様はコンテンツモデルではなく、相互運用性サーフェスを定義します。

2. プロデューサーとコンシューマーの独立性。OKF では、ナレッジを作成する側とナレッジを利用する側が明確に分けられます。人間が手動で作成したバンドルを AI エージェントが利用できます。メタデータエクスポートパイプラインによって生成されたバンドルをビジュアライザーで閲覧できます。1 つの LLM によって合成されたバンドルを別の LLM でクエリできます。形式は契約であり、どちらの側のツールも個別に切り替え可能です。

3. プラットフォームではなく、形式。OKF は、特定のクラウド、データベース、モデルプロバイダ、エージェントフレームワークに依存しません。読み取り、書き込み、配信に独自の SDK やアカウントは必要ありません。ナレッジ形式の価値は、誰がそれを所有しているかではなく、どれだけの人やシステムがそれを利用しているかによって決まるため、Google は OKF をオープンスタンダードとして公開しています。

仕様とともにリリースされるもの

形式を具体化するために、プロデューサー側とコンシューマー側の両方で参照実装を公開しています。

拡充エージェント: BigQuery データセットを走査し、テーブルとビューごとに OKF のコンセプトドキュメントの下書きを作成した後、信頼できるドキュメントをクロールする 2 回目の LLM パスを実行して、引用、スキーマ、結合パスで各コンセプトを拡充します。
静的 HTML ビジュアライザー: OKF バンドルを、単一の自己完結型ファイル内のインタラクティブなグラフビューに変換します。バックエンド不要、表示側でのインストール不要で、データがページから出ることもありません。
3 つの閲覧可能なサンプルバンドル: 参照エージェントによって生成され、要件を満たした OKF の実際の例としてリポジトリにコミットされた、GA4 e コマース、Stack Overflow、Bitcoin の公開データセット。

これらは意図的に概念実証として作成されています。エージェントは OKF を生成する一例を示しているだけであり、形式のいずれの部分においても特定のエージェントフレームワークや LLM は必要ありません。ビジュアライザーは OKF を利用する一例を示しているだけであり、形式のいずれの部分においても HTML やグラフビューは必要ありません。Google は、プロデューサーとコンシューマーのエコシステムが、Google がリリースしたものをはるかに超えて成長することを期待しています（そして望んでいます）。

今後の展開

OKF v0.1 は出発点であり、完成した標準ではありません。この形式は、プロデューサーとコンシューマーが増えるにつれて、また、実際にエージェントに必要なナレッジ表現をまとめて学ぶにつれて、進化していきます。

Google は OKF を最初からオープンに公開しています。ナレッジカタログ、拡充パイプライン、AI エージェント向けにカスタマイズされた Wiki、AI ナレッジドメイン内のものなど、いずれを構築する場合でも、ナレッジ形式がその名に値するのは、最初からオープンに公開されている場合に限られるからです。

ここから、次のことをおすすめします。

仕様を読む（短いです）
ご利用のソースシステム、データベース、ドキュメントサイト用のプロデューサーを記述する
コンシューマーを作成する: 閲覧者、検索インデックス、バンドルについて推論するエージェント
ご自身のデータでリファレンス実装を試す
問題を報告する、PR を送信する、拡張機能を提案する: 仕様はバージョン管理されており、下位互換性のある成長を考慮して明示的に設計されています。

リポジトリ、仕様、サンプルバンドルは GitHub で入手できます。また、Open Knowledge Format を取り込んでエージェントに提供できるように Google Cloud の Knowledge Catalog を更新しました。関連するコードと例はこちらでご確認いただけます。

形式そのものが貢献です。Google がリリースしたツールは、それを実現し、試すためのコストを下げるために存在します。現在ナレッジがどのような形であっても、OKF は今後そのナレッジを変換できる「共通語」となるように設計されています。

^{Google Cloud データクラウドチームが公開。Open Knowledge Format はオープンな仕様です。Google のプロダクト以外での貢献、代替実装、採用はすべて明示的に歓迎されます。この投稿は、著者のほか、Google の多くのメンバーの重要なアイデアによって完成しました。ご協力に感謝いたします。}

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

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

詳細解説: Lightning Engine が Apache Spark のパフォーマンスを 4.9 倍高速化する仕組み

Wed, 17 Jun 2026 02:00:00 +0000

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

基本的な ETL と分析から最先端の生成 AI まで、Apache Spark はグローバルなデータ処理のアーキテクチャを支える柱として機能します。とはいえ、データ量が増大するにつれて、パフォーマンスとインフラストラクチャ費用の兼ね合いが成長の阻害要因となる可能性があります。自律型エージェントが数千ものマルチホップクエリを同時にトリガーできるエージェントの時代においては、このパフォーマンスのボトルネックがユニットエコノミクスに直接影響します。

このたび、Managed Service for Apache Spark 向け Lightning Engine の一般提供が開始され、サーバーレスとマネージドクラスタの両方のデプロイモードで利用可能になったことをお知らせいたします。上述のようなスケーリングの課題を直接解決するために設計されたこの Lightning Engine は、最新の Spark ワークロードに完全に対応しているため、既存のデータパイプラインに変更を加える必要はありません。

オペレーション不要のシンプルなサーバーレスデプロイモードと、インフラストラクチャを詳細に制御できるマネージドクラスタデプロイモードのどちらを選択しても、Lightning Engine は統合パフォーマンスエンジンとして機能し、ジョブの実行を強力に促進します。100 万件を超える実際のワークロードで Lightning Engine を検証することにより、産業グレードの安定性と信頼性の高いパフォーマンス向上を実現できるようファインチューニングしました。

この一般提供リリースにより、Lightning Engine は以下を実現します。

標準のオープンソース Spark と比較して最大 4.9 倍高速なパフォーマンス
主要な高速 Spark の代替プロダクトと比較して 2 倍の費用対効果

では、Managed Service for Apache Spark がどのようにしてこうした素晴らしい成果を上げているのか、詳しく見ていきましょう。

仕組み: ベクトル化したネイティブ実行

従来の Spark 実行では、JVM 実行のオーバーヘッドとガベージコレクションの一時停止がボトルネックになることが少なくありません。Lightning Engine では、Spark の物理クエリプランを、SIMD（単一命令、複数データ）ベクトル化に最適化されたネイティブ C++ 命令にコンパイルすることで、こうした制限を回避します。

Google 開発の専用拡張機能が組み込まれたオープンソースの Gluten および Velox ランタイム上に構築されたこのネイティブ実行レイヤは、以下の機能を活用して、最も要求の厳しいデータ処理タスクを高速化します。

並べ替えのベクトル化: ネイティブメモリでデータを列状に処理することで並べ替え処理を高速化し、CPU サイクルのオーバーヘッドを大幅に削減します。
ウィンドウ関数の高速化: ネイティブの C++ レイヤ内で直接実行することにより、行セット全体に対して行われる計算（移動平均、集計、重複除去など）を高速化します。
スマートなフォールバック: クエリに、ネイティブサポートされていない演算子やカスタム Java UDF が含まれている場合、エンジンのインテリジェントなプッシュダウンレイヤが、その特定のサブツリーを自動的かつスムーズに JVM に戻し、不要なデータ形式の変換を回避して、全体的な実行の安定性を維持します。

最適化された Cloud Storage と BigQuery のコネクタ

エンジンがデータ不足に陥ると、ハイパフォーマンスコンピューティングも役に立ちません。Lightning Engine では、Cloud Storage と BigQuery からのデータの読み取りがボトルネックにならないよう、ストレージコネクタを以下のように最適化しました。

パスの直接接続: 複数のノードホップをバイパスし、Cloud Storage との双方向ストリーミングを使用します。これにより、ストリームを再オープンしなくてもシーク操作やベクトル化した readV API を実行できるため、複雑で深くネストされた Parquet ファイルや ORC ファイルのスキャン時間を短縮できます。
メタデータ呼び出しの削減: 大規模なパーティション分割テーブルを管理する際は、ただファイルを一覧表示するだけで時間を消費するという、パフォーマンスの隠れた代償を伴うことがよくあります。Lightning Engine は、ドライバで辞書順のリストを利用してメタデータを収集し、それをエグゼキュータに直接送信します。これにより、冗長な Cloud Storage API 呼び出しが排除され、Cloud Storage のメタデータコストが大幅に削減されます。
ネイティブの BigQuery コネクタ: BigQuery データを Arrow 形式で直接使用します。Arrow から JVM UnsafeRow への、コストの高い変換を回避することで、エンジンはシリアル化のオーバーヘッドを排除し、スキャン時間を短縮できます。

ブロードキャスト結合と高度なクエリの最適化

Lightning Engine には、Google の F1 および Spanner クエリエンジンにインスパイアされたコストベースの高度なクエリオプティマイザーが組み込まれており、いくつかのカスタム最適化ルールが導入されています。以下に例を示します。

単一のハッシュテーブルキャッシュ: 標準のブロードキャスト結合では、Spark はタスク間で結合ハッシュテーブルを繰り返し構築します。一方、Lightning Engine では、エグゼキュータごとにハッシュテーブルを一度だけ構築してキャッシュに保存するため、冗長な CPU サイクルが排除され、エグゼキュータのメモリ使用量が減少します。
集計のプッシュダウン: 結合シャッフルの前に部分的な集計を自動的にプッシュします。これにより、ネットワーク経由で転送する必要があるデータ量を最小限に抑え、コストの高いシャッフルステージを大幅に減らすことができます。
自動シャッフルパーティショニング: ランタイム統計情報に基づいてクエリステージごとに最適なシャッフルパーティション数を動的かつ適応的に決定し、過剰なパーティショニングをなくして、メモリ不足（OOM）によるスピルを防止します。

Google Cloud Next ‘26 での Lightning Engine の技術的な詳細と Lowe’s の事例の紹介

使ってみる

これらのアップデートはすでに公開されているため、すぐにご利用いただけます。Lightning Engine を有効にするには、Google Cloud コンソールから直接操作するか、gcloud CLI を使用します。

Lightning Engine を有効にして サーバーレス バッチジョブを送信するには、Spark プロパティでプレミアムティアを指定します。

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc batches submit pyspark my_script.py \\\r\n --region=us-central1 \\\r\n --properties=dataproc:dataproc.tier=premium \\\r\n --properties=spark:spark.dataproc.lightningEngine.runtime=native'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e8c39dc40>)])]>

Lightning Engine とネイティブクエリ実行（NQE）が有効な新しいマネージドクラスタをスピンアップするには、ターミナルで次のコマンドを実行します。

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters create my-optimized-cluster \\\r\n --region=us-central1 \\\r\n --image-version=2.3 \\\r\n --engine=lightning \\\r\n --enable-component-gateway \\\r\n--properties=spark:spark.dataproc.lightningEngine.runtime=native'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e8c395160>)])]>

別の方法として、Google Cloud コンソールで Managed Service for Apache Spark のページに移動します。[クラスタを作成] をクリックし、[Compute Engine 上のクラスタ] を選択して、クラスタ構成設定で [Lightning Engine] を選択すると、ワークロードのクエリ高速化が自動的に有効になります。

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

- Google Cloud、プリンシパルソフトウェアエンジニア、Abhishek Modi

BigQuery Graph で食品サプライチェーンのデジタルツインをモデリング

Wed, 17 Jun 2026 00:40:00 +0000

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

成長中のレストランの例

レストランチェーンを経営している場面を想像してみてください。ビジネスがどのように動いているのかを、実際に一つひとつ見たり触れたりして把握することは至難の業です。ビジネスの健全性を把握するには、その状態を感知するためのツールと、ビジネスのデジタルレプリカが必要です。

成長に伴う摩擦

成長は、スプレッドシートだけでは解決できない特有の摩擦を生み出します。

ブルウィップ効果: 下流の需要の小さな変化が、上流では在庫の大きな変動へと膨らみます。
SOP の逸脱: 標準的な仕込み作業からのわずかな逸脱が、やがてブランド全体の雰囲気を損なっていきます。
食品安全上の影響範囲: 汚染された 1 つの食材が、ネットワーク全体に広がる複雑なリスクを生み出します。
管理外支出: 各店舗のマネージャーが契約外で食材を購入することで発生する「100 万ドル規模の漏れ」です。

デジタルツイン

デジタルモデルは、世界についてより深い問いを立てる力を与えてくれます。一方で、データをどのように構造化するかという重要な選択も迫っています。従来はリレーショナルテーブルが標準でしたが、今でもあらゆる用途に最適なツールといえるのでしょうか。私たちの世界が本質的に相互につながっていることを踏まえると、現実を捉えるためにグラフベースのモデルに移行することは、自然な進化と言えるかもしれません。

数千ものアセット、複雑なサプライチェーン、グローバルなロジスティクスネットワークを管理する場合、従来のリレーショナルデータベースでは、依存関係をたどるためにリソースを大量に消費する大規模な SQL 結合が必要になります。このアーキテクチャでは、現実世界で起きた事象を運用上の認識に反映するまでに、レイテンシのギャップが生じます。

BigQuery Graph でのモデリング

BigQuery Graph を使用すると、既存のデータプラットフォーム内で、サプライチェーン全体のデジタルツインを構築できます。現実世界のアイテム、レシピ、場所を、検索可能なノードとエッジのマップに変換することで、これまで以上に明確に関係性を把握できるようになります。

1. セマンティックレイヤを定義する

データを新しいデータベースに移動する代わりに、既存のテーブル上にグラフビューを作成します。これにより、テーブル同士がどのように関連しているかを BigQuery に正確に伝えることができます。

クエリ言語:

code_block: <ListValue: [StructValue([('code', '# グラフのノードとエッジを構築する\r\nCREATE or REPLACE PROPERTY GRAPH `restaurant.bombod`\r\nNODE TABLES (\r\n `restaurant.item` label item properties all columns,\r\n `restaurant.location` label location properties all columns,\r\n `restaurant.itemlocation` label itemlocation properties all columns\r\n)\r\nEDGE TABLES (\r\n `restaurant.bom`\r\n KEY(bomKey)\r\n SOURCE KEY (childItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n DESTINATION KEY (parentItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n LABEL consists_of properties all columns\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e83d25760>)])]>

BigQuery Graph でモデル化した架空のレストランサプライチェーンの画像

実務で活きる精度

この変化は、日々の業務をどのように変えるのでしょうか。ビジネスを、混乱した対応から精度の高い対応へと移行させます。

外科手術のように正確なリコール対応: サプライヤーからリステリア菌の発生が報告された場合、グラフを前方にたどることで、どのレストランのどのメニュー項目が影響を受けるのかを正確に特定できます。
気象リスク分析: ハリケーンが配送センターに迫っている場合、単なる店舗リストではなく、影響が及ぶ範囲を把握できます。そのハブに大きく依存している拠点を特定し、物資の配送ルートを変更できます。

2. 検索を実行する

グラフクエリは、モデラーやデータサイエンティストがデータをクエリするための新しいツールです。複数のドメインにまたがる複雑なデータ概念を扱いやすくし、クエリを簡素化することで、データ分析を、問題の構造をより自然に表現するものにします。たとえば、鶏肉を扱っているすべての拠点を知りたい場合は、次のようなグラフクエリを実行できます。

特定の苦情やリスクを調査するには、グラフクエリ言語を使用してモデルを検索します。

Graph Query Language

code_block: <ListValue: [StructValue([('code', "# 特定の食材に関する問題の発生源をたどる\r\nGraph restaurant.bombod\r\nMATCH (a:itemlocation)-[c:consists_of]->(b:itemlocation)\r\nWHERE b.itemKey LIKE '%Chicken%'\r\nRETURN to_json([to_json(a),to_json(c),to_json(b)]) as result"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0e83d25970>)])]>

悪臭の発生源をグラフとしてモデル化した例

将来を見据えて

デジタルツインを最大限に活用するには、次の基本原則に沿って進めることが重要です。

構造に重点を置く: 関係性や依存関係にはグラフを使用し、日次売上の合計などはリレーショナルテーブルに保持します。
キーを整備する: データエンジニアリングに時間をかけます。グラフの価値は、その接続の正確さによって決まります。
エッジのプロパティを取得する: リードタイムや送料などのメタデータをエッジに直接保存することで、モデルの有用性を高めます。

まとめ

レストラン業界は、ビジネスデータを単なるリストとして扱うリレーショナルな方法だけでは対応しきれない段階に来ています。BigQuery Graph を使用して、ドメイン間の関係をデジタルツインとして構築することで、事後対応型の問題解決から先を見越したモデリングへと移行できます。ネットワークをリストで管理するのはもうやめて、つながりを数秒で把握できるようにしましょう。

使ってみる

チュートリアルはこちら
BigQuery のドキュメントを見る: 概要とクイックスタートガイドをご覧ください。
フィードバックを共有する: コミュニティに参加するか、bq-graph-preview-support@google.com までお問い合わせください。
関連ブログ: BigQuery Graph のご紹介

- Google Cloud、クラウドトランスフォーメーション技術リード Guru Rangavittal

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

データ分析

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

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

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

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

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

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

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

使ってみる

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

環境を設定する

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

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

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

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

Python に戻って可視化する

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

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

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

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

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

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

使ってみる

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

説明から意思決定まで

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

信頼性: generated、verified

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

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

v0.2 の主な更新内容

互換性

次のステップ

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ

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

不要な手作業を回避する

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

将来を見据える

レポート: 83%の組織がエージェント型 AI に対応するためにインフラストラクチャのアップグレードを必要としている

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

難易度を測定

見えていなかった崖

分野全体での傾向

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

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

評価ツールを評価する

メンテナンスからイノベーションへ: Checkout における Managed Service for Apache Airflow への移行

出発点: セルフマネージド Airflow

ソリューション: Managed Service for Apache Airflow（第 3 世代）

まとめ

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

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

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

影響と結果

今後の展望

エージェントでギアを上げる: ソフトウェア定義車両のセキュリティを確保

Nexus SDV での AI 主導のエクスペリエンス

クラウドネイティブな仕組み

Google Cloud のセキュリティ管理機能による多層防御

Nexus SDV の利用を始める

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

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

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

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

お試しください

AI の可能性からエージェント型の現実へ: 英国の新たな章を切り拓く

英国の企業と研究の新たなフロンティア

将来を見据えた公共部門の構築

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

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

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

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

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

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

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

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

Siemens が「象の切り分け」（細分化）により産業用ソフトウェア開発のエージェントワークフローを推進

「象の切り分け」: エージェントワークフロー

Looker エージェントでダッシュボードをインタラクティブなデータエクスペリエンスに変革

ダッシュボードエージェントを使ってみる

2. 新たなデータエージェント

3. データエージェント向けのツール

BigQuery Graph で食品サプライチェーンのデジタルツインをモデリング