データ分析

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

これらの結果から、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 0x7f23a8169070>)])]>

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

商品データセットに対して 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 0x7f23a8169e20>)])]>

結果のテーブルが表示されます。このテーブルには 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 0x7f23a8169730>)])]>

クエリ結果: 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 0x7f23a8169d90>)])]>

クエリ結果: 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 0x7f23a8169520>)])]>

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

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

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

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

クエリの実行方法:

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

高度な機能

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

または、こちらの 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 0x7f23a808d3a0>)])]>

各コンセプトドキュメントには、構造化されたフィールド用の 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 0x7f23a808d1c0>)])]>

コンセプトは通常の 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 0x7f23a80f64f0>)])]>

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

別の方法として、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 0x7f23a8197dc0>)])]>

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

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

将来を見据えて

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

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

まとめ

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

使ってみる

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

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

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

サーバーレス Managed Service for Apache Spark の新機能

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

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

データ準備、リアルタイムのインタラクティブクエリ、AI モデルのトレーニングなど、Apache Spark の用途はさまざまですが、大規模での実行は負担が大きく、そのうえさらに基盤となるインフラストラクチャの管理もするとなれば大変な労力が必要になります。

昨年末、Google はサーバーレス Managed Service for Apache Spark ランタイムバージョン 3.0 の一般提供（GA）を発表しました。速度、シンプルさ、信頼性に重点を置いたバージョンです。それ以来、データサイエンス分野のお客様によるご利用が、前年比でほぼ倍増しました。これは、Google Cloud を使用すると、Apache Spark ワークロードをより簡単、スマート、迅速に実行できるという Google の信念を裏付けるものです。

このブログ記事では、特徴量エンジニアリング、GPU によるモデルのトレーニングやチューニングの高速化、セマンティック検索、RAG、AI エージェントや AI アプリケーションの構築などの幅広いワークフローに Google Cloud のサーバーレス Apache Spark サービスがどのように適しているのか、その重要な機能をいくつか取り上げて詳しく説明します。

セットアップ不要のオンボーディング

クラウドサービス導入における最大の障壁は、多くの場合、「感動の瞬間」までの時間、つまりプロジェクトの作成から最初のワークロード実行までの時間が長いことです。以前は、サーバーレス Spark を使用する場合でも、1 つのジョブを送信する前に、IAM ロール、VPC ネットワーキング、ファイアウォールルールを手動で構成する必要がありました。

サーバーレス Spark 3.0 ランタイムバージョンでは、セットアップ不要のオンボーディングにより、サーバーレス Spark で最初のワークロードを起動させるまでの時間が大幅に短縮されます。これは、次の手順を自動化することで実現されます。

権限: 必要な IAM のロールと権限が、適切なサービスアカウントに自動的にプロビジョニングされます。
ネットワーキング: サブネットでプライベート Google アクセスが自動的に有効になり、システムファイアウォールポリシーが自動的に構成されます。
API 管理: API の有効化がより効率的になりました。以前のように複数の異なる API を手動で有効にする必要はなく、Managed Service for Apache Spark API を有効にするだけで済みます。

SLA の影響を受けやすいワークロードの高速起動

インタラクティブなデータサイエンスのパイプラインや、SLA の影響を受けやすいバッチパイプラインでは、レイテンシが特に重要です。従来、サーバーレス Spark の起動には数分かかることがありました。3.0 ランタイムでは、標準ティアとプレミアムティアの両方で起動時間が 75% 短縮されました。これは、コードや構成の変更なしで自動的に実現し、追加費用も必要ありません。

この大幅な改善により、サーバーレス Spark は、SLA の影響を受けやすい、より広範囲のワークロードに適したものとなります。起動時間については、今後も継続して最適化を目指していきます。

「サーバーレス Spark を使用することで、きめ細かいマシン管理の必要性がなくなり、迅速にメリットを得ることができました。これにより、モデル開発が迅速化され、データ処

GPU の入手可能性の向上

サーバーレス 3.0 ランタイムバージョンでは Dynamic Workload Scheduler（DWS）の Flex Start モードがサポートされることで、サーバーレス Spark は、GPU が利用できない場合に、構成可能な期間中、お客様のリクエストをキューに入れることができます。この機能は、リージョン内で頻繁に不足する NVIDIA A100 や L4 などの需要の高いアクセラレータの入手可能性に関する課題を解決します。DWS で必要な GPU 容量が利用可能になるまでワークロードを一時停止することで、レイテンシの影響を受けやすい AI / ML ワークロードの入手可能性と信頼性を大幅に高めることができます。

トップクラスの Apache Spark 4.x サポート

サーバーレス Spark 3.0 ランタイムバージョンは、現在、そして今後の Apache Spark 4.x のイノベーションをサポートします。たとえば Spark Connect は、分離されたクライアントサーバーアーキテクチャをサポートし、あらゆるクライアントからのリモート接続を可能にします。

マルチゾーンサポートの強化

サーバーレス Spark 3.0 ランタイムでは、グローバルなエンタープライズワークロードをゾーンの停止やハードウェアの在庫切れから保護するために、デフォルトでマルチゾーンサポートが強化されています。現在、単一リージョン内の複数のゾーンにわたって実行ノードを自動的に割り当て、入手可能性を確保できるようになっています。

重要な点として、リージョン内のノード間のクロスゾーンネットワークトラフィックは課金されません。そのため、従来のようなマルチゾーンの追加料金なしで高可用性を実現できます。この点も、グローバルな Apache Spark ワークロードを Google Cloud に移行することで実現できるメリットの一つです。

今後の展望

上述に加えて、履歴ベースの自動チューニングや目標ベースの自動スケーリングなど、使いやすさの限界を押し広げるイノベーションを継続していきます。

ご利用にあたって

これらの機能は、バッチワークロードまたはインタラクティブセッションで runtime_version: 3.0 を指定することで、今すぐご利用いただけます。サーバーレス Spark で最初のワークロードを実行するには、次の簡単な手順を行ってください。

Managed Service for Apache Spark API を有効にします。
プロジェクトオーナーでない場合は、プロジェクトに対するサーバーレス Managed Service for Apache Spark 編集者（roles/dataproc.serverlessEditor）ロールの付与をプロジェクト管理者に依頼してください。

これで、サーバーレス 3.0 ランタイムバージョンでワークロードの実行を開始できます。詳細については、更新されたドキュメントをご覧ください。サーバーレス Managed Service for Apache Spark には、Google Cloud コンソールからアクセスしてください。

- ソフトウェアエンジニアリングマネージャー、Vinay Londhe

- シニアプロダクトマネージャー、Bhooshan Mogal

Managed Service for Apache Spark クラスタの新機能

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

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

Google Cloud は、お客様が大規模な分析ワークロードやデータサイエンスワークロードを最大限の効率で実行できるようにすることを目指しています。これにより、大規模なデータパイプライン、ML、ETL のタスクを処理できます。

最近、Dataproc サービスが Managed Service for Apache Spark に変更されたことを発表いたしました。これは、Agentic Data Cloud との緊密なインテグレーションを反映したものです。

現代のデータチームのアーキテクチャに対する多様なニーズに対応するため、このサービスはサーバーレスとマネージドクラスタの 2 つの異なるデプロイモードで提供されます。サーバーレスデプロイモードでは、エフェメラルなジョブやアドホックジョブ向けにインフラストラクチャ管理が完全に抽象化されます。一方、マネージドクラスタデプロイモードは、インフラストラクチャのきめ細かいカスタマイズ、永続的な環境、長時間実行されるステートフル処理、またはカスタムの Compute Engine ハードウェア構成とのネイティブなインテグレーションを必要とするチーム向けに設計されています。

マネージドクラスタでのデプロイに関しては、3 つの主要な柱に焦点を当てて、エクスペリエンスをゼロから再構築しました。具体的には、実行速度を向上させて Spark を高速化し、リソースの入手可能性を最大化して運用オーバーヘッドを削減することで Spark の実行をより簡単にし、開発と運用のライフサイクルに AI を直接組み込むことで Spark をよりスマートにしています。

このブログ投稿では、Managed Spark クラスタデプロイモードについて Google Cloud Next ‘26 で発表した内容を紹介します。このモードでは、ネイティブ実行エンジン、よりスマートなスケーリングポリシー、Gemini を活用した拡張機能により、パフォーマンスと費用を微調整できる柔軟性が向上しています。サーバーレスデプロイモードの最新情報については、こちらのブログ記事をご覧ください。

ネイティブ実行エンジン Lightning Engine で高速化

Managed Spark クラスタの最大のアップデートは、Lightning Engine でしょう。Lightning Engine は、Spark DataFrame / Dataset API や負荷の高い Spark SQL クエリのパフォーマンスを大幅に向上させます。また、Velox と Gluten をベースに構築されたネイティブの C++ ベクトル化実行エンジンと、専用の内部機能強化を備え、クエリプランを SIMD（単一命令複数データ）ベクトル化向けに最適化されたネイティブ命令にコンパイルすることで、JVM 実行のボトルネックを回避します。

このネイティブ実行エンジンは、以下を実現します。

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

重要な点として、こうしたパフォーマンス向上を利用するために、既存の Spark アプリケーションのコードを変更する必要はありません。ジョブがより高速で完了することが、Compute Engine の合計ランタイム時間と全体的な費用の削減にそのままつながります。

マネージドクラスタで Lightning Engine を有効にするには、クラスタの作成時に Lightning Engine オプションを指定するだけです。

Lightning Engine の技術的な詳細と Lowe’s の事例の紹介

より簡単に: フレキシブル VM でリソースの入手可能性を最大化

特定のマシンタイプがローカルで一時的に不足し、クラスタの作成や自動スケーリングが滞ることがあります。こうした容量の制約に対するクラスタの復元力を大幅に向上させるために、Managed Spark クラスタ向けのフレキシブル VM の一般提供が開始されました。

フレキシブル VM では、マスターノード、プライマリワーカーノード、セカンダリワーカーノードに最大 10 個のランク付けされたマシンタイプを定義できます。Managed Service for Apache Spark は、この設定と、リージョン内のゾーン自動配置を組み合わせ、リージョン全体を動的にスキャンしたうえで、利用可能な最適なハードウェアレイアウトを使用して容量リクエストを満たします。これにより、パイプラインを予測どおりにスピンアップできるようになり、リソースの可用性エラーが大幅に削減され、需要がピークに達する期間に費用対効果の高い Spot VM 容量を最大限に活用できるようになります。

より簡単に: ゼロスケールクラスタとスケジュール設定による停止

永続的な環境と開発環境の財務管理を強化するため、Google は最近、特に要望の多かった 2 つの FinOps 機能（ゼロスケールクラスタとスケジュール設定によるクラスタの停止）の一般提供を発表しました。

ゼロスケールクラスタ: セカンダリワーカー（Spot VM）のみを使用する環境をプロビジョニングできるようになりました。処理がアクティブでないとき、クラスタはワーカーノードを完全にゼロまで自動的にスケールダウンし、メタデータを保持するためにマスターノードのみをオンラインのままにします。
スケジュール設定によるクラスタの停止: この機能を使用すると、特定のアイドル時間制限または正確な将来のタイムスタンプに基づいて、クラスタの自動シャットダウンポリシーを構成できます。

これらの機能はネイティブに統合されているため、環境を削除して再構築しなければならないという運用上の負担が軽減されます。また、夜間や週末に生じるアイドル状態のコンピューティングオーバーヘッドに対する支払いを停止できます。

よりスマートに: Managed Service for Apache Spark MCP サーバー

生成 AI とデータエンジニアリングのギャップを埋めるために、Google は Managed Service for Apache Spark 向け Model Context Protocol（MCP）サーバーをリリースしました。このオープンスタンダードなインテグレーションにより、LLM と AI アシスタントは、自然言語を使用して安全かつ動的に Managed Spark クラスタとやり取りできます。

MCP サーバーを利用することで、AI エージェントは既存の IAM 権限でデータプラットフォームに安全に接続できます。そのため、エージェントはクラスタの作成、ジョブの送信、自動スケーリングポリシーの調整などのクラスタベースの処理を、AI アプリケーションから直接実行できます。

よりスマートに: Data Agent Kit で AI 導入を加速

Google Cloud Data Agent Kit は、データサイエンティスト、エンジニア、デベロッパーが、任意の開発環境内でデータワークロードのライフサイクル全体を直接管理できる拡張機能です。Managed Spark クラスタでこの拡張機能のネイティブサポートをロールアウトしたため、コード生成とデータラングリングのための専用のデータエージェントをシームレスに構築、デプロイできるようになりました。

デベロッパーは、Google のスタンドアロンのエージェント型開発プラットフォーム Antigravity 2.0 を使用するか、Data Agent Kit の拡張機能やプラグインを使用して、これらのエージェント機能を VS Code、Claude Code、Codex など任意の IDE に取り込むことができます。この効率化されたワークフローと、マネージドクラスタに備わる処理能力を組み合わせることで、これらのインテリジェントエージェントは、ペタバイト規模のデータレイク上で直接、複雑なワークフローを安全に実行できます。具体的には、デベロッパーは Data Agent Kit を使用して、次のことができます。

パイプラインの構築とオーケストレーション: 自然言語を使用してマルチノードのデータパイプラインを作成し、包括的なコードドキュメントを生成できます。
リアルタイムでデバッグを実行: Gemini Cloud Assist を活用して、エグゼキュータのログを精査し、ジョブ失敗の根本原因を特定して、実行可能な修正案を検討できます。
Spark リソースに簡単に接続: 手動によるネットワーク構成やローカルでの Spark インストールなしで、サーバーレス Spark ランタイムやマネージドクラスタに即座に接続できます。
Git と CI / CD の管理を合理化: 任意の IDE から直接コードを commit、マージ、デプロイし、自動でのテストとデプロイのパイプラインをスムーズにトリガーできます。

よりスマートに: 次世代の Lakehouse

Google は最近、Managed Service for Apache Spark や BigQuery などのエンジン間で読み取り / 書き込みの相互運用を可能にする Lakehouse をリリースしました。統合されたサーバーレスのメタデータレイヤとして Lakehouse ランタイムカタログが活用されることで、データサイロが解消され、複雑な変換レイヤが不要になります。このエージェントファーストのアプローチにより、組織は Google Cloud Storage からオープンフォーマットを直接処理したり、新たに導入されたクロスクラウド Lakehouse を使用してリモートの AWS データセットをクエリしたりできます。その際には、セキュリティとガバナンスのための信頼できる唯一の情報源が維持されます。

Managed Spark クラスタをご利用のお客様には、このインテグレーションにより、いくつかの強力な新機能が提供されます。データチームは、最適化された Lightning Engine を使用して、最も要求の厳しい ETL やデータサイエンスのワークロードを最大 4.9 倍高速化できます。

次世代ランタイム: Spark 4.1 を搭載したクラスタイメージ 3.0

オープンソースエコシステムにペースを合わせ、Google はクラスタイメージ 3.0 をプレビュー版としてリリースしました。これは Apache Spark 4.1 で構築され、デフォルトの Java ランタイムが Java 21 にアップグレードされています。Spark 4.1 では、構造化ストリーミングのリアルタイムモードなど、一連の主要なオープンソース機能が導入されています。これにより、1 秒未満のレイテンシで継続的に処理されるリアルタイムストリーミングを Spark 環境でサポートできるようになります。

使ってみる

これらのアップデートは公開済みであり、Managed Spark クラスタで今すぐご利用いただけます。新機能を有効にするには、Google Cloud コンソールを操作するか、gcloud CLI を使用します。

新しいマネージドクラスタをスピンアップし、Lightning Engine のパフォーマンスをネイティブに引き出すには、ターミナルで次のコマンドを実行します。

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 \\'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f239f7b5850>)])]>

別の方法として、コンソールで Managed Service for Apache Spark のページに移動します。[クラスタを作成] をクリックして、クラスタ構成で [Lightning Engine を有効にする] を選択すると、Spark ジョブ向けに Lightning Engine が自動的に有効になります。

Managed Service for Apache Spark クラスタとして、皆様がどのような環境を構築、実行するのか、ご報告をお待ちしております。

- Google Cloud、シニアプロダクトマネージャー、Qiqi Wu

フルマネージドの AlloyDB 向けリモート MCP サーバーが一般提供開始

Tue, 16 Jun 2026 15:30:00 +0000

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

AI エージェントは優れた推論能力を備えており、ますます複雑なアクションを実行できるようになっています。しかし、エージェントによる成果の信頼性は、アクセスできるコンテキストの品質に大きく左右されます。そして、そのコンテキストは多くの場合、オペレーショナルデータベースの中に閉じ込められています。

このギャップを埋めるため、Google は AlloyDB 向けリモート Model Context Protocol（MCP）サーバーの一般提供を開始しました。

Model Context Protocol（MCP）は、LLM を外部データソースに安全かつ一貫した方法で接続できるようにするオープンソース標準です。Google Cloud が最近リリースした 50 以上の Google マネージド MCP サーバーの一部として提供されるこの新しい統合により、対話型エージェントと自律型エージェントのどちらも企業データの力をこれまで以上に簡単かつ安全に活用できるようになります。たとえば、AI エージェントを AlloyDB 内のリアルタイムロジスティクスデータに接続することで、配送フリートの最新状況をミリ秒単位で確認できます。これにより、古いデータによる不正確さを避け、手動でレポートを作成する必要も減らせます。

AlloyDB がエージェント型アプリの強固な基盤となる理由

MCP を AlloyDB に接続すると、エージェントはエンタープライズグレードの AI 向けに構築された高性能なデータベースにアクセスできます。AlloyDB は、要求の厳しいエージェント型ワークロードに必要なスケール、スピード、インテリジェンスを提供します。

強化されたベクトルパフォーマンス: ScaNN インデックスにより、100 億を超えるベクトルにスケールし、ベクトルクエリでは標準の PostgreSQL の最大 6 倍、フィルタ付きクエリでは最大 10 倍の速度を実現できます。
高度な検索と再ランキング: プレビュー版の RUM によるハイブリッド検索と、Reciprocal Rank Fusion（RRF）または Gemini Enterprise Platform モデルによるインテリジェントな再ランキングにより、マルチモーダルアプリケーションを強化できます。
リアルタイムインテリジェンス: 組み込みの AI Functions を使用して数百万件のエンベディングを効率的に生成し、低レイテンシのリアルタイムエージェント体験を実現できます。
統合されたデータアクセス: エージェントに単一の PostgreSQL インターフェースを提供し、Lakehouse Federation を通じて、AlloyDB の運用データ、BigQuery の分析データ、Iceberg テーブル内のアーカイブデータをシームレスに結合できるようにします。
エンタープライズグレードのスケール: 99.99% の SLA、Autopilot によるデータベース最適化、最大 20 ノードまで自動スケーリングできる読み取りプールにより、安心して運用できます。

AlloyDB にとってリモート MCP が重要な理由

ローカル MCP サーバーはローカル開発には最適ですが、本番環境のワークロードにスケールさせる場合、標準入出力（stdio）ストリームを介した通信は難しくなります。機密性の高い運用データを扱う高価値のユースケースでエージェントを実行するには、必要なインフラストラクチャやセキュリティガードレールをすべてプロビジョニングし、管理しなければなりません。これはアーキテクチャ上複雑で、管理面でも大きな負担になります。

AlloyDB 向けリモート MCP サーバーは、フルマネージドの Google Cloud インフラストラクチャ上で実行され、AI アプリケーションをデータに接続する HTTP エンドポイントを公開します。これにより、PostgreSQL 上でエージェントを構築するチームが直面する主な課題を解決できます。

一元的な検出: Agent Registry を使用して、データベースの MCP サーバーを検出、保護、管理できます。
フルマネージド HTTP エンドポイント: 接続に必要なインフラストラクチャをデプロイしたり維持したりする必要はありません。エージェントでそのエンドポイントを使用するよう構成するだけで、すぐに使い始められます。
きめ細かい認可: 共有データベースパスワードや API キーを使用する代わりに、Identity and Access Management（IAM）を使用して、エージェントのアクセスを特定のテーブル、スキーマ、ビューに制限できます。読み取り専用の SQL 実行ツールを使用すれば、エージェントが誤ってデータベースに変更や削除を加えることを防げます。
運用インスタンス管理: AlloyDB ツールセットにより、エージェントはクエリの実行だけでなく、インスタンスの更新、データのエクスポートとインポート、バックアップの作成、クラスタの復元も行えます。
Model Armor による保護: Model Armor は、プロンプトとレスポンスに対する任意のセキュリティ機能を提供し、データをスクリーニングおよびフィルタリングします。これにより、プロンプトインジェクションや偶発的なデータの引き出しから保護できます。
監査ロギング: すべてのクエリ、アクション、ツール呼び出しが Cloud Audit Logs に記録されるため、セキュリティチームは完全な監査証跡を得られます。

動作を確認してみる: 簡単なデモ

AlloyDB リモート MCP サーバーは、簡単な手順で使い始めることができます。ご自身の環境で実際の動作を確認するには、新しい Codelab に沿って、以下の主要な手順を実行します。

API と環境の準備: Google Cloud プロジェクトで AlloyDB、Compute Engine、Gemini Enterprise の各 API を有効にします。
データベースのプロビジョニング: AlloyDB クラスタをデプロイし、データベースを作成して、サンプルデータをインポートします。
データアクセス API の有効化: AlloyDB インスタンスでデータアクセス API を許可します。
エージェントの接続: リモートエンドポイント（https://alloydb.googleapis.com/mcp）を指定して MCP クライアントを構成します。HTTP Authorization ヘッダーで OAuth 2.0 ベアラートークンを使用し、Google Cloud IAM 認証情報を渡します。

接続が確立されると、エージェントはリアルタイムの運用データを使用して、複雑なビジネス上の質問に対して、信頼性が高く根拠に基づいた回答を提供できます。エージェントはイントロスペクションクエリを実行することで、テーブルや列を含むデータベーススキーマを自動的に理解します。これにより、ユーザーのリクエストに正確に応えるための高度な結合やクエリを構築できます。

エージェントが AlloyDB ツールセットにアクセスできるようになると、クエリの実行、運用傾向の分析、AI.RANK() などの AlloyDB AI Functions を使用したテキストデータの動的なランク付けが可能になります。

セキュリティは引き続き最重要事項です。AlloyDB 向けリモート MCP サーバーは Model Armor とシームレスに統合されます。これにより、エージェントのサービスアカウントがデータベース内で広範なアクセス権限を持っている場合でも、機密データの漏洩を防ぐことができます。

デモの全編を以下でご覧ください。

AI エージェントをエンタープライズデータに直接接続する方法: AlloyDB リモート MCP サーバーのご紹介

次のステップ

トランザクションデータとの安全なやり取りを可能にすることで、AI エージェントは企業の信頼できる唯一の情報源にアクセスし、それに基づいて行動できるようになります。

構築を始める準備はできましたか。30 日間の無料トライアルで AlloyDB をお試しください。また、Remote MCP for AlloyDB Codelab を活用して、エンタープライズ向けエージェント型アプリケーションの構築を今すぐ始めましょう。

- Google Cloud、AlloyDB / Cloud SQL 担当プロダクトマネージャー Paul Ramsey

- Google Cloud、データベース担当クラウドアドボケイト Gleb Otochkin

ペタバイトから予測へ: Google スプレッドシートで簡単に BigQuery の分析情報を取得

Mon, 15 Jun 2026 01:00:00 +0000

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

多くの組織において、信頼できる唯一の情報源となるデータは、Google の管理された安全なペタバイト規模のデータプラットフォームである BigQuery に保存されています。しかし、アドホック分析、モデリング、レポート作成の「ラストワンマイル」は、多くの場合、ビジネスユーザーが最も使い慣れた Google スプレッドシートで行われています。

このギャップを埋めるには、通常はデータを CSV 形式でエクスポートする必要があります。しかし、この方法は非効率的であり、データサイロ、バージョン管理の問題、セキュリティとガバナンスのリスクをもたらします。コネクテッドシートは、このトレードオフを解消する機能です。使い慣れた Google スプレッドシートのインターフェースが、BigQuery データプラットフォームにリアルタイムで直接つながるウィンドウに変わり、ペタバイト単位のデータを迅速、安全、かつ簡単に分析できるようになります。

この投稿では、コネクテッドシートの概要を簡単に説明し、実際のユースケースを紹介します。また、Google スプレッドシートで BigQuery を直接使用して、エンタープライズグレードのデータ分析を行う方法も説明します。

信頼できる唯一の情報源をリアルタイムで確認

ビジネスユーザーは、簡単なレポートを数日間や数週間も待つことがよくあります。コネクテッドシートを使用すると、SQL を使わずに、数十億行のライブデータへの安全な直接接続を介して重要なデータを分析できるため、この問題を解決できます。

データ管理者にとって、このアーキテクチャの魅力は、強力なセキュリティとガバナンスの体制を維持できる点です。基盤となるデータをコネクテッドシートから変更することはできないため、特定のテーブルやビューへのアクセス権を安心してプロビジョニングできます。また、管理者は Google Workspace のエンタープライズデータ保護を利用して、データのライフサイクル全体にわたってデータの読み取り、共有、コピーを管理することもできます。

エンドユーザーにとってのメリットは、即座にアジリティを確保できる点と使いやすい点です。ピボットテーブル、グラフ、計算された列、数式などの使い慣れたツールを使用して、数十億行のライブデータをローカルファイルのように分析できるため、一元管理と、ビジネスに求められるスピードのバランスがとれます。エンドユーザーは、データベース、スキーマ、テーブル、SQL などのクエリ言語といった技術的な概念を学ばずに、データのアクセス、分析、可視化が可能です。

主なユースケースと取り組み

業界を問わず、コネクテッドシートの主なユースケースとして、よく聞くのは次の 3 つです。

1. セルフサービスの探索的分析: データチームが、BigQuery 内のキュレートされたテーブルとデータセットへのアクセスを提供します。セールス、オペレーション、財務、マーケティングのビジネスアナリストは、独自のピボットテーブルやグラフを作成し、スプレッドシートから直接、ライブデータソース全体に対して実行してから、データをフィルタして日常的な問題について確認できます。これにより、データチームは、リクエストが随時、絶え間なく届き、たまっていく状況から解放されます。

例: 詳細な調査

シナリオ: 営業マネージャーが、世界中の数百万件の取引を分析して四半期のパフォーマンスを確認します。
アクション: コネクテッドシートのピボットテーブルを使用して、地域別と商品ライン別の収益を要約するピボットテーブルをすばやく作成します。異常（たとえば、EMEA での予期しない収益の急増）を発見した場合は、要約値をダブルクリックするだけで、ドリルダウンして、その値につながった原因を正確に把握できます。
成果: コネクテッドシートが、要約値の根拠となった正確で詳細な取引の行を即座にクエリして取得するため、根本原因の特定が簡単かつ迅速になります。

2. 運用レポート: ビジネスユーザーが、ライブデータを表示、更新できる、わかりやすいダッシュボードのようなデータビューを作成できます。パートナーチームはこれを信頼し、経営幹部やリーダーと共有できます。

例: エグゼクティブサマリーの自動化

シナリオ: 運用責任者が、数百万行の BigQuery データセットに基づいて、販売請求書に関する状況報告を経営陣に毎週提出します。
アクション: 運用責任者は、コネクテッドシートを作成し、請求書の経時的な傾向を可視化する一連のグラフを作成します。次に、毎週月曜日の朝に自動的に更新されるようにシートを構成し、経営陣によるレビューに備えます。
成果: データをエクスポートしてワークブックに貼り付けるという手作業が完全に不要になります。経営陣は、最新のウェアハウスデータを利用した信頼性の高いレポートと分析を入手できます。

3. ハイブリッドデータモデリング: データの実務担当者は、多くの場合、管理されたデータウェアハウスのデータと、リアルタイムの手動入力やアノテーションを融合する必要があります。たとえば、財務チームが BigQuery から収益データを抽出し、それを別のタブで ERP システムに手動で入力された調達データと組み合わせ、VLOOKUP を使用して月末レポート用の統合ビューを作成する場合が考えられます。

例: カスタムビジネス指標

シナリオ: 財務アナリストが、CRM システムのライブ販売データに基づいてカスタムのコミッション支払い額を計算します。コミッションの階層ロジックは頻繁に変更され、中央のデータウェアハウスでモデル化されていません。
アクション: アナリストは、データチームに新しいデータパイプラインをリクエストする代わりに、コネクテッドシート内に計算列を直接追加できます。このとき、標準的なスプレッドシートの数式（IF や IFS など）を使用して、カスタムビジネスロジックを BigQuery データに直接適用します。
成果: アナリストは、管理された BigQuery データを信頼できる唯一の情報源として維持しながら、シナリオをモデル化し、指標を迅速に計算できる柔軟性を確保できます。

ご利用にあたって

Google スプレッドシートと BigQuery の接続は簡単で、Google Workspace アカウントと、課金が有効な Google Cloud プロジェクトがあれば可能です。接続を確立してコネクテッドシートを作成する方法は、主に 2 つあります。

パス 1: スプレッドシートから始めるこれは、主にスプレッドシートで作業するユーザー向けの一般的なワークフローです。

新しい Google スプレッドシートを開きます。
[データ] > [データコネクタ] > [BigQuery に接続] を選択します。
課金が有効になっている Google Cloud プロジェクトを選択します。
利用可能なデータセットをブラウジングします。カスタム SQL クエリを入力するか、すぐに接続するには保存済みクエリを選択します。
[接続] をクリックします。

パス 2: BigQuery から始めるこのワークフローは、Google Cloud コンソールから開始するデータアナリストに一般的です。

コンソールで BigQuery の UI を開きます。
[エクスプローラ] ペインで、分析するテーブルまたはクエリ結果を見つけます。
アセットの横にある [エクスポート] メニュー（またはその他メニュー）をクリックします。
[次で開く] > [コネクテッドシート] を選択します。

コネクテッドシートでペタバイト単位のデータから予測を生成

コネクテッドシートは、クラウドのスケーラビリティとスプレッドシートの柔軟性のギャップを埋めるために設計されました。コネクテッドシートを使用することで、組織はこれまで以上に簡単にデータを必要な人に提供できるようになります。

これらの機能を試すには、今すぐ BigQuery データを Google スプレッドシートに接続してください。技術的な詳細については、コネクテッドシートのドキュメントをご覧ください。

- BigQuery シニアプロダクトマネージャー Tarak Parekh

- Workspace シニアプロダクトマネージャー Laura Gagliano

データレイクの高速化: gcs-analytics-core で Apache Iceberg と Spark を最適化

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

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

データエンジニアの多くは、複数の分析エンジンでの互換性の管理や、最適なパフォーマンスの確保のために多大な時間を費やしています。Google はこの課題を解決するために、gcs-analytics-core を発表しました。これは、Google Cloud Storage（GCS）の分析の最適化を一元化して高速化するように設計された新しいオープンソースの Java ライブラリです。

GCS 上で高いパフォーマンスを実現しつつ、好みの分析エンジンを柔軟に選択できるほか、gcs-analytics-core ライブラリは、現在 GCS で使用されているさまざまな分析エンジン（Iceberg Spark エンジンなど）にわたって最適化を実現します。今年末までに他の分析エンジンにも拡張する予定です。

このライブラリは、バージョン 1.11.0 以降の Apache Iceberg Java ランタイムでネイティブに利用できます。Apache Spark などの主要なデータ処理フレームワーク間で共有できるように構築されており、GCS 上の分析ワークロードのパフォーマンスを統合し、向上させるほか、Parquet などの列形式の読み取りオペレーションを改善します。

gcs-analytics-core ライブラリとは

gcs-analytics-core ライブラリは、Apache Spark、Trino、Apache Hive などの分析エンジンと、基盤となる GCS Java SDK との間に位置する一元化された最適化レイヤです。読み取り呼び出しをインターセプトしてパフォーマンスを向上させ、フレームワーク固有のチューニングを必要とせずに一貫したエクスペリエンスを提供します。

Apache Iceberg では GCSFileIO 実装に統合され、従来の順次読み取りを並列化された戦略に置き換えることで、レイテンシを最小限に抑え、スループットを最大化します。

主な技術的最適化

このライブラリには、I/O に費やす時間とエンドツーエンドの実行時間を短縮するために設計された、特別な最適化機能が導入されています。

ベクトル化された I/O（スレッド化）: 1 回のオペレーションで複数のデータ範囲を並行してフェッチすることで、読み取りパフォーマンスを向上させ、GCS 呼び出しのオーバーヘッドを削減します。この機能がない場合、システムはデータ範囲ごとに個別の呼び出しを発行する必要があるため、各リクエストにおけるオペレーションの数とファイルを開く操作のレイテンシの両方が増加します。
スマート Parquet プリフェッチ: Parquet データを読み取る際、分析エンジンは通常、データの構造や特定のデータ範囲の場所に関する情報を含むファイルのフッターを最初に読み取ります。このライブラリは、このフッターデータを単一のチャンク（通常 50 KB～100 KB）として自動的にプリフェッチすることで、多くのエンジンで発生しがちな、メタデータを取得するために後方へ何度もシークして複数回ネットワーク呼び出しを行う処理を回避できます。

注目点: Apache Iceberg のインテグレーション

このライブラリ初の重要インテグレーションとして、Apache Iceberg とのインテグレーションを実現しました。Iceberg 1.11.0 以降では、Iceberg の GCSFileIO を利用する分析エンジンで、これらのパフォーマンスの向上を活用できます。ご使用の環境にこのライブラリを導入する際は、Iceberg カタログがネイティブの GCS FileIO を使用するように構成されていることを確認してください。

code_block: <ListValue: [StructValue([('code', '# Spark 構成の例\r\nspark.sql.catalog.my_catalog.io-impl=org.apache.iceberg.gcp.gcs.GCSFileIO'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f239f4ec520>)])]>

このライブラリの中核となるこれらの最適化は、更新された Iceberg ランタイムと GCS コネクタアーキテクチャに組み込まれているため、Parquet フッターのプリフェッチや、マルチスレッドによるベクトル化された読み取りのメリットを自動的に享受できます。複雑なカスタムチューニングは必要ありません。

インテグレーションの具体的な詳細については、Apache Iceberg の問題 #14326 をご覧ください。

カタログの互換性

gcs-analytics-core ライブラリは、REST カタログ、Hive、その他のメタデータ管理システムなど、すべての Iceberg カタログと互換性があります。パフォーマンスの最適化をカタログ管理レイヤから切り離すことで、既存のインフラストラクチャ設定を調整することなく、一貫した読み取り性能の向上を実現するほか、さまざまなデータレイクアーキテクチャにわたるスケーリングを可能にします。

Spark を使用した TPC-DS パフォーマンスベンチマーク

これらの改善効果を検証するために、オープンソースの Apache Spark クラスタを使用してエンドツーエンドのベンチマークを実施しました。このクラスタでは、gcs-analytics-core ライブラリとともに GCSFileIO を使用するように Iceberg カタログが構成されています。

このベンチマークでは、業界標準の TPC-DS スキーマをさまざまなデータセットサイズ（1 GB から 10 TB まで）で使用し、ベクトル化された順次読み取りを使用するデフォルトの GCSFileIO 実装と、新しいライブラリの最適化機能を重点的に比較しました。

ストレージレイヤでの I/O ボトルネックが解消されることで、コンピューティングエンジンがネットワーク応答を待つ時間（スキャン時間）が短縮され、データ処理（実行時間）に費やす時間が増えます。

以下に、このエンドツーエンドの TPC-DS ベンチマーク結果を示します。gcs-analytics-core を有効にした場合の改善率をご確認ください。

TPC-DS スキーマサイズ	スキャン時間の改善率	実行時間の改善率
1 GB	71.51%	32.61%
10 GB	48.48%	18.94%
100 GB	40.98%	10.95%
1 TB	35.86%	3.38%
10 TB	18.40%	1.58%

上記のデータが示すように、すべてのデータセットサイズで一貫した改善が見られました。このライブラリは、TPC-DS の複雑なクエリパターンに効果的であり、スキャン時間の短縮により、クエリの実行時間全体を直接短縮します。

使ってみる

Spark ワークロードを実行する前に、以下の要件を満たした構成であることを確認してください。

Apache Iceberg Spark ランタイム 1.11.0 以降と iceberg-gcp-bundle 1.11.0 以降を使用する。
GCSFileIO を使用するようにカタログを構成する。
gcs-analytics-core 最適化フラグを有効にする（spark.sql.catalog.$CATALOG_NAME.gcs.analytics-core.enabled=true）。

ベクトル化された I/O（spark.sql.iceberg.vectorization.enabled=true）を有効にして、読み取りパフォーマンスを向上させる。

code_block: <ListValue: [StructValue([('code', 'spark-submit \\\r\n --packages org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.11.0,org.apache.iceberg:iceberg-gcp-bundle:1.11.0 \\\r\n --conf spark.sql.catalog.$CATALOG_NAME=org.apache.iceberg.spark.SparkCatalog \\\r\n --conf spark.sql.catalog.$CATALOG_NAME.io-impl=org.apache.iceberg.gcp.gcs.GCSFileIO \\\r\n --conf spark.sql.catalog.$CATALOG_NAME.gcs.analytics-core.enabled=true \\\r\n --conf spark.sql.iceberg.vectorization.enabled=true \\\r\n <your-application-jar-or-script>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f239f4ec1f0>)])]>

gcs-analytics-core ライブラリはオープンソースです。デベロッパーの方はプロジェクトに貢献したり、ソースコードを調べたりできます。Google の実装とマイクロベンチマーク構成はこのリポジトリの一部であり、貢献や検証の際に参照できます。

GitHub リポジトリ: GoogleCloudPlatform/gcs-analytics-core
ドキュメント: アーキテクチャの詳細については、設計ドキュメントをご覧ください。

ぜひ実際にお試しになり、ご意見、ご感想をお聞かせください。ご自身のデータセットでお試しになった際は、GitHub で報告して、コミュニティに結果を共有していただければ幸いです。皆さまがデータレイクを最適化するうえで、この機能がどのように役立っていくか、今後を楽しみにしています。

- ソフトウェアエンジニア、Ajay Yadav

- エンジニアリングマネージャー、Nivedita Aggarwal

Next ‘26 でのストリーミング AI に関する発表

Wed, 03 Jun 2026 00:00:00 +0000

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

データは、ありとあらゆるデバイス、ユーザー、マイクロサービスで生成されます。このデータを取り込み、意味とインサイトを抽出し、リアルタイムでビジネス上の意思決定を推進することで、変革的なビジネス価値を生む可能性が高まります。リアルタイム分析に内在する課題も、エージェント型 AI の急発展で克服のチャンスが現実のものとなっています。エージェント型 AI は導入加速の大きな可能性を秘めていますが、ユーザーはリアルタイムデータを効果的に活用するうえで、以下の新しい課題に直面しています。

コンテキストのリアルタイム実装が困難。開発チームは通常、データベースの定期的な同期やスケジュールされた更新など、バッチ処理的アプローチでデータを取り込みます。このため、エージェントは、古いデータに依存するか、メモリを大量に消費するコンテキストウィンドウを必要とします。この「コンテキストの時差」は、不正行為の検出、e コマースの動的なおすすめ表示、サプライチェーンの自律的な調整など、せっかくのリアルタイムエージェントタスクの効果を帳消しにしてしまいます。
リアルタイムシステムは柔軟性に欠ける。エージェントツールには、お客様固有の要件に適応するためのモジュール性が欠けており、組織は難しいアーキテクチャの選択を迫られます。データ実務者は、レイテンシ、精度、費用のトレードオフを自由に選択できるプラットフォームを必要としています。

これらの課題に対応するために Google Cloud は、緊密に統合された統一ストリーミングデータプラットフォームを提供しています。このプラットフォームは、フルマネージドの Google Cloud ネイティブサービスとオープンソース互換サービスの両方を提供し、大規模な AI トレーニングと推論をサポートします。このプラットフォームを構成する 5 つの主要サービスは以下のとおりです。

Pub/Sub: メッセージングとイベントストリーミングのための、信頼性の高いサーバーレスなフルマネージドサービスで、BigQuery、Dataflow、Cloud Storage と統合されています。Pub/Sub は Anthropic をはじめとする多くの組織で利用されています。
Dataflow: バッチ、ストリーミングのための、そして今やエージェント型 AI を支えるサーバーレスエンジンです。Waymo や Google マップなどの Google サービス同様、Palo Alto Networks などの大手企業にも採用されています。たとえば、Waymo 車両は Dataflow を使用して周囲の状況を「把握」し、ルートを計画したり、障害物を予測したりします。自動車が実際に道路を走行する前に、シミュレータで数百万マイルを「走行」し、Dataflow でトレーニングデータセットを生成して自動運転に使用されるモデルを検証します。
Managed Service for Apache Kafka: 信頼性、安全性、費用対効果に優れたオープンソースのストリーミングストレージ兼データ統合システム Apache Kafka を、Google Cloud 上で実行するためのフルマネージドサービスです。大企業からスタートアップまで、Apache Kafka は重要なトレーニングデータと AI エージェントコンテキストのリアルタイム更新のステージングロケーションとして利用されています。
BigQuery: リアルタイムの取り込みと分析のための統合プラットフォーム。Storage Write API が、1 回限りの配信セマンティクスとストリームレベルのトランザクションで、BigQuery と Lakehouse for Apache Iceberg のテーブルに高スループットストリーミングを提供します。さらに、BigQuery の継続的クエリでは、AI.GENERATE_TEXT などの生成関数を呼び出すことで、データパイプライン内で直接リアルタイムの AI 推論が可能になり、データが取り込まれると同時に分析情報を得ることができます。
Bigtable: Google の NoSQL リアルタイムデータベース。継続的なマテリアライズドビューを使用して Pub/Sub と Dataflow からのストリーミングデータを自動的に処理し、結果を数秒で提供します。Bigtable のインメモリ階層を使用して低レイテンシでサービス提供できるようにします。

インサイトから自律的アクションへと進化

Google Cloud Next '26 では、ストリーミング AI 機能セットの Agentic Data Cloud への追加が発表されました。これにより、自律型エージェントに即座にコンテキストが提供され、リアルタイムのアクションが可能になります。つまり、組織は AI エージェントにリアルタイムのコンテキストをフィードできるようになります。

たとえば、サプライチェーンエージェントは、IoT データをモニタリングするだけでなく、悪天候を避けてルートを自律的に変更したり、配送先の倉庫と納期の許容範囲を再調整して顧客のポータルを更新したりできます。しかも、これらすべてが、人間の監督者が問題に気づく前に実行されるのです。また、金融サービスエージェントは、不正なトランザクションパターンを特定し、即座にアカウントを凍結して、お客様が希望する手段で連絡を取ってから新しいカードの発送を手配してくれます。これらすべてが、不審なアクティビティが発生してから数秒以内に遂行されます。これらの機能は、検索を強化するためにストリーミングデータのエンベディングを作成する場合でも、マルチエージェントによる高度な不正行為検出システムを構築する場合でも、強力な新しい武器となります。

これらの新機能について詳しく見ていきましょう。

新しいストリーミング AI 機能

Next ‘26 で発表された新機能は、Google Cloud のストリーミングデータプラットフォームに 3 つの主要分野にわたって緊密に統合されています。

1. エージェントにリアルタイムで豊富なコンテキストを提供

1.1. Pub/Sub AI 推論 SMT（一般提供）: Pub/Sub を介してストリーミングされたメッセージに対して推論を実行できるようになりました。データ実務者は、Gemini Enterprise Agent Platform で利用可能なモデルを自由に選択できます。Pub/Sub が推論を呼び出し、各メッセージに結果を追加してダウンストリームへと送ります。Pub/Sub のシンプルさと Gemini Enterprise のフルマネージドツールとが効果的に融合します。

1.2. Pub/Sub Bigtable サブスクリプション （プレビュー版）: Pub/Sub データを Bigtable に直接ストリーミングします。Pub/Sub Bigtable サブスクリプションは、Pub/Sub トピックからイベントデータを直接 Bigtable テーブルにマテリアライズするため、カスタムパイプラインが不要になり、ストリーミングアーキテクチャを大幅に簡素化します。たとえば、ベクトルエンベディングを Bigtable に簡単に取り込み、セマンティック検索ワークロードを強化できます。

1.3. BigQuery 継続的クエリのステートフルデータ処理（プレビュー版）: BigQuery の継続的クエリで JOIN を使用して複数のデータストリーム間の複雑な相関関係を特定し、タンブリングウィンドウ集計を使用して一定の時間間隔で指標を計算できるようになりました。たとえば、30 分間の平均値の計算や、異なるストリーム間のイベントの関係付けなどの高度な分析を、データが BigQuery に取り込まれると同時に直接行うことができます。さらに、AI.GENERATE_TEXT などの生成関数を呼び出すことで、AI をデータパイプラインに直接統合できます。また、継続的クエリの SQL 結果を BigQuery テーブルにマテリアライズしたり、リアルタイムのリバース ETL のために Bigtable、Spanner、Pub/Sub などの運用シンクにエクスポートしたりできます。

2. エージェントに指示してリソースを管理

2.1. Pub/Sub、Managed service for Apache Kafka、Bigtable、BigQuery の Model Context Protocol（MCP）サポート（一般提供）: エージェントが、フルマネージドの MCP エンドポイントを使用して、Pub/Sub、Managed service for Apache Kafka サービス、BigQuery を管理できるようになりました。エージェントは Pub/Sub にメッセージをパブリッシュすることもできます。

2.2. ADK インテグレーション（一般提供）: エージェントが、事前構築された ADK インテグレーションを通じて、Pub/Sub、Bigtable、BigQuery、その他の Google Cloud サービスに保存されたリアルタイムデータとやり取りできるようになりました。このため、デベロッパーはリアルタイムのコンテキストに基づいて動作するエージェントを、複雑な構成やパイプライン調整の作業なしで構築できます。

3. マルチエージェントシステムとデータ処理の統合

3.1. イベントドリブンな自律エージェント: ワークフローの中核をエージェントが担うようになると、リアルタイムのデータパイプラインを進化させてエージェントをストリームに直接組み込む必要が生じます。Google Cloud では、エージェントロジックを Dataflow パイプライン内で第一級の対象として扱うことで、これを実現しました。これにより、Agent Development Kit（ADK）を使用してエージェントコードを組み込み、RunInference 変換と新しい ADKAgentModelHandler を使用して、特別ノードとしてデプロイできるようになりました。このアプローチには主に次のメリットがあります。

優れたスケーラビリティ: Dataflow のアーキテクチャを活用して、アップストリームで高速のイベントを処理し、数百のエージェントセッションを同時にアクティブに保ちます。各セッションは個々に特定の受信イベントによって起動されます。
事前処理の効果: Dataflow が複雑なデータ拡充の作業を一手に引き受け、エージェントに「すぐに行動可能」のコンテキストを受け渡して、エージェントが推論に集中できるようにします。

3.2. Dataflow 統合エンベディングシンク: 統合エンベディングの生成プロセスをデータストリーム内に直接組み込み、「コンテキストのタイムラグ」を解消しました。これにより、Dataflow を使用して、受信データを高次元ベクトルに低レイテンシで変換できるようになりました。さらに、このリアルタイムエンベディングは、Cloud Spanner（組み込みベクトル検索の新機能を搭載）と AlloyDB を含む、拡張された高スループットのベクトルシンクスイートにシームレスにマテリアライズされます。これにより、セマンティック検索のニーズに対応する最新のベクトルデータベースが利用可能になります。また、RAG 呼び出しを行う自律エージェントは、即座に検索可能で完全に同期された長期記憶を利用できるようになります。この機能は、リモートモデルとローカルモデルの両方で動作します（例: Gemma）。

Google Cloud は今後もプラットフォームを拡充し続け、より緊密な統合とより強力な機能をお客様にお届けしてまいります。皆様がこれらの新機能を活用して次に何を生み出すのか、楽しみにしております。

- プロダクト管理担当ディレクター、Jagdeep Singh

- グループプロダクトマネージャー、Prateek Duble

エージェント型開発の未来: Data Agent Kit でデータ実務担当者のライフサイクルを再定義

Sun, 31 May 2026 16:00:00 +0000

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

現代のソフトウェア開発は、単一の場所で完結するものではなく、エージェント型ツールのエコシステム全体に広がっています。エージェントはかつてない規模で開発されており、コンテキストとグラウンディングのために、企業データに直接アクセスする必要があります。

しかし、エージェントの構築やデータ管理に使用される現在のツールは大きく断片化されています。そのため、データへのアクセスが難しくなり、セキュリティリスクが高まるだけでなく、開発者体験が損なわれ、イノベーションの妨げになる可能性があります。

この課題に対処するため、Google は最近、Data Agent Kit をリリースしました。これは、データエンジニアリングとデータサイエンスのスキル、ツール、プラグインをまとめた統合型のオープンソースコレクションです。VS Code、Claude Code、Codex、Gemini CLI、Antigravity CLI など、実務担当者がすでに使用している環境に直接統合できます。こうした中核的なツールやスキルを企業データとシームレスに結び付けることで、Data Agent Kit は、エージェントに必要なコンテキスト、メモリ、パーソナライズを支える包括的な基盤として機能します。Data Agent Kit には、以下が含まれます。

エージェント型スキル: クエリ最適化、ML のベストプラクティス、データ検証、データドリフトチェック、ガバナンス、トラブルシューティングなど、データ資産とやり取りするためのあらかじめコード化された手順。
Model Context Protocol（MCP）ツール: エージェント型ワークフローと、BigQuery、AlloyDB、Google Cloud Storage などのクラウドデータプラットフォームを安全に接続するツール。デベロッパーは、複雑な手動のパイプラインコードを管理しなくても、クラウドデータセットやデータ処理エンジンの接続パラメータを構成できるようになります。
プラグインと拡張機能: コンテキストを踏まえた高度な開発者体験を可能にするネイティブ IDE 統合。

これらの Data Agent Kit の機能を組み合わせることで、データ実務担当者は、手作業でコードを記述する従来の作業から、インテントドリブンなデータサイエンスとエンジニアリングへと移行できます。つまり、実現したいビジネス成果、制約、成功基準を定義すれば、AI で強化されたシステムがその実行方法を判断できるようになります。この変化は非常に重要です。現在、複雑なデータアーキテクチャを扱うエージェント型アプリケーションを構築する際には、多くの場合「コンテキストウィンドウ税」とも言える負担が発生します。つまり、デベロッパーは膨大な量のスキーマメタデータを手作業でプロンプトに貼り付ける必要があり、トークン上限を消費し、レイテンシも増加します。一方で、データ実務担当者は、クラウドデータを効率的にクエリ、最適化、トラブルシューティングする方法について十分なガイダンスを得られないことが多く、専門化され断片化した開発環境では、データ資産全体を見渡すことができません。Data Agent Kit は、こうした課題をはじめとするさまざまな問題に対応し、データ実務担当者が新しいエージェント型の働き方に移行するために必要な基盤機能を提供します。

Data Agent Kit の機能とメリット、インストール方法、ローカル環境をデータ資産に接続する方法、インテントドリブンエンジニアリングの例について、以下で詳しく説明します。

データ資産とライフサイクルを統合するハブ

Data Agent Kit を使用すると、データ資産全体を 1 つのビューで利用できるようになります。これは、BigQuery、AlloyDB、Spanner などのデータベース向けに単純なカタログを提供するだけのものではありません。データエンジニアリングとデータサイエンスのタスク、オーケストレーションパイプライン、ジョブを単一のインターフェースに統合します。これにより、実務担当者は、検出から本番環境への移行まで、データワークフロー全体をコンテキストを切り替えることなく管理できます。Data Agent Kit のインテリジェントなルーティングは、タスクに最適なコンピューティングエンジンを自動的に選択します。たとえば、SQL ネイティブな分析や ELT には BigQuery、カスタムの Python 変換や分散 ML トレーニングには Spark を選択できます。

データ資産とライフサイクルを統合するハブ

エコシステム主導のインテリジェンス: 体系化されたエージェント型スキル

Data Agent Kit は、Google Cloud のデータエンジニアリングとデータサイエンスの専門知識に基づき、事前定義されたエージェント型スキル（ML のベストプラクティス、ELT、データアプリの構築など）のライブラリを提供します。汎用的な LLM プロンプトに頼るのではなく、規範的なガイドラインをワークフローに組み込みます。これにより、エンタープライズグレードのデータインテリジェンスを IDE や CLI に直接取り込むことができます。

事前定義されたデータエンジニアリングおよびデータサイエンスのエージェント型スキル一覧を確認する

自然言語によるデータ探索の変革

Data Agent Kit は、この統合されたデータを基盤として、ワークスペース内でネイティブの会話型分析を直接提供し、データを簡単に探索できるようにします。Conversational BigQuery や Looker などのファーストパーティエージェントにも採用されている Gemini の自然言語から SQL への変換技術を活用することで、自然言語クエリを実行し、データセットのプロファイリング、検索、可視化を行うことができます。

Data Agent Kit では、会話型分析を使用してデータを探索できます。

実践的なチュートリアル: データの統合とモデルの構築

Data Agent Kit のスキルと MCP ツールがどのように連携するのかを確認するために、金融サービスのシナリオを考えてみましょう。ある企業で不正請求が増加しているとします。Cloud Storage に保存されたトランザクションデータを使用して、信頼性の高い不正検出モデルを構築し、オーケストレーションパイプラインをスケジュールする必要があります。従来であれば、複数のコンソールをまたいで何時間もデータラングリングを行う必要がありました。Data Agent Kit を使用すれば、この作業を IDE や CLI 内で直接、数分で完了できます。では、その方法を見ていきましょう。

オンボーディング: 1 分でセットアップ

統合されたセットアッププロセスにより、Data Agent Kit は 1 分以内に使い始めることができます。

IDE のマーケットプレイス（VS Code）で「Google Cloud Data Agent Kit」を検索するか、後述の「使ってみる」セクションにあるリンクから CLI（Gemini、Antigravity、Claude、Codex）向けの GitHub リポジトリにアクセスします。Data Agent Kit は依存関係を自動的に構成し、Google Cloud へのログインステータスを確認します。

アクティビティバーの Google Cloud アイコンをクリックし、IAM 経由で認証します。ログインすると、Cloud Storage、データベース、カタログアセットがワークスペースにすぐに表示されます。

設定メニューを使用してプロジェクト ID とリージョンを設定し、MCP のステータスを確認して、すべてのバックエンドサービスに必要な権限が付与されていることを確認します。Data Agent Kit には、ツールとスキルの使用方法を説明するクイックスタートガイドも含まれています。

インテントドリブンなデータエンジニアリングの例

Data Agent Kit をインストールすると、手動による ETL の定型作業を省き、コーディングアシスタント（Claude Code、GitHub Copilot など）に自然言語で大まかな目標を直接伝えることができます。アシスタントは Data Agent Kit のスキルを活用して、ワークフローを計画し、実行します。

プロンプト:

未加工のトランザクションログが GCS バケット gs://fin-clearing-raw/ に保存されています。

まず、Spark ノートブックを作成し、（1）これらのログを BigQuery の Iceberg テーブルに取り込みます。

次に、dbt プロジェクトを作成して、（2）重複を除去し、（3）無効なトランザクション ID を持つトランザクションを削除して別の Iceberg テーブルに保存し、（4）タイムスタンプを標準化して、その他の必要なクリーンアップタスクを実行し、（5）出力を別の Iceberg テーブルに同期し、（6）この出力テーブルを、支払い者と受取人の ID を含むテーブルと結合して、最終的な Iceberg テーブルに書き込みます。

3 つ目として、ノートブックを使用して Spark で ML モデルをトレーニングし、出力テーブル内の不正なトランザクションを検出したいと考えています。LightGBM モデルを検討していますが、他に提案があればそれも検討します。プロジェクト内の関連データセットを使用してください。

最後に、上述のパイプラインに Spark ノートブックを使用した推論ステップを作成し、バッチ推論を実行して、フラグが付けられたトランザクションを Spanner テーブルに書き込んでください。

まず取り込みを実行し、次に dbt、最後に推論ノートブックを実行するオーケストレーションパイプラインを作成してください。

内部の仕組み: データパイプラインの手順

Data Agent Kit は、探索から推論まで、データライフサイクル全体にわたる堅牢な複数ステップのオーケストレーションを背後で計画します。

ステップ 1: ノートブックの作成、取り込み、初期保存

ブロンズデータ、つまり金融取引に関する未加工でフィルタされていないデータを見つけ、変換を行う前に Iceberg テーブルに取り込みます。

Cloud Storage から未加工のログを取り込むためのノートブックを自動的に作成します。
必要な SQL を記述し、取り込んだデータを BigQuery の Iceberg テーブルに保存します。

Ingestion into a bronze table

ステップ 2: 変換（dbt プロジェクト）

次に、ブロンズデータをクリーニングし、シルバーテーブルとゴールドテーブルに変換します。

データの準備: トランザクションログの重複を除去します。
無効な ID のフィルタリング: 無効な ID を持つトランザクションを特定し、別の Iceberg テーブルに保存します。
クリーンアップと標準化: タイムスタンプを標準化し、その他の必要なクリーンアップタスクを実行します。
同期: BigQuery MCP サーバーを活用して、クリーニング済みのデータを別の Iceberg テーブルに出力します。
エンリッチメント: クリーニング済みのテーブルを、支払い者と受取人の ID 情報を含むテーブルと結合します。
最終出力: 結合したデータセットを最終的な Iceberg テーブルに書き込みます。

シルバーテーブルとゴールドテーブルを作成するためのデータ変換

ステップ 3: ML と推論

ゴールドテーブルができあがったら、次はデータサイエンス、つまりモデルのトレーニングと推論に進みます。ここでは、エージェントが前のステップでクリーンアップしたデータをモデルに渡し、不正のパターンを検出します。

トレーニング: Spark ノートブックを使用して ML モデルをトレーニングします。
推論: バッチ処理用の Spark ノートブック推論ステップを作成します。
保存: Spanner MCP を活用して、フラグが付けられた不正なトランザクションをすべて Spanner テーブルに書き込みます。

ML と推論

ステップ 4: オーケストレーションと実行

最後に、本番環境への移行に向けて、取り込み → 変換 → 推論というオーケストレーションパイプライン全体をスケジュールします。

オーケストレーションパイプラインと実行スケジュール

予期せぬ問題が発生した場合: エージェント型インシデント管理とインテリジェントな復旧

オーケストレーションパイプラインが失敗しても心配はいりません。Data Agent Kit は、インテリジェントなインシデント管理機能を使用して、解決までのプロセスを効率化します。

インテリジェントな診断: 根本原因分析を自動的に実施し、障害の発生源を特定します。
自律的な修復: 手動デバッグを介さずに、修正案を作成してテストします。
自動復旧: 自動化された Git ワークフローを通じて修正を検証し、デプロイします。

問題の診断と修復

これで、元データの探索から、完全に自動化された不正検出の仕組みの構築まで、同じ UX 内でわずか数分のうちに完了できます。複数のブラウザタブや IDE インターフェースを行き来したり、データエンジニアリングやデータサイエンスのベストプラクティスを一から学んだりする必要はありません。Data Agent Kit は、さまざまな MCP ツールと体系化されたスキルを活用し、クリーンなエンドツーエンドのフローをオーケストレートします。最終的に、このアプローチにより、最も重要なこと、つまり革新的で高性能なデータアプリケーションを大規模に提供することに集中できます。

使ってみる

Data Agent Kit は、このたびプレビュー版の提供を開始いたしました。まずは、お好みの IDE または CLI にインストールしてください。

詳細を確認して使い始めるには、ドキュメントをご覧ください。

- データクラウド担当グループプロダクトマネージャー、Brahm Kohli

- データクラウド担当エンジニアリングディレクター、Dinesh Chandnani

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ

Fri, 22 May 2026 03:00:00 +0000

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

Google Cloud Next ’26 において、Google は AI や分析などのデータ集約型ワークロード向けのオブジェクトストレージ機能ファミリーである Cloud Storage Rapid を発表しました。Cloud Storage Rapid は登場時点で、高パフォーマンスのゾーンオブジェクトストレージサービスである Rapid Bucket（旧称: Rapid Storage）と、オンデマンドで読み取りを高速化し、既存のバケットのワークロードのコンピューティングとデータをコロケーションする Rapid Cache（旧称: Anywhere Cache）で構成されています。

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ

組織が AI を中核に据えて構築を進めるなか、Google は次世代の要請に応えるために Cloud Storage Rapid を開発しました。チームは、数兆個のパラメータを持つモデルをトレーニングし、グローバル規模で推論をデプロイし、膨大な量のエンタープライズデータについて推論する自律エージェントを構築しています。GPU や TPU といったアクセラレータが注目を浴びがちですが、それらには極めて重要な依存関係があります。それがストレージです。

ストレージは、トレーニング中にアクセラレータにデータを供給するエンジンであり、リアルタイム推論を応答性の高いものにする高速アクセスレイヤです。しかし、モデルの規模が大きくなるにつれて、ストレージのパフォーマンスがボトルネックになる可能性があります。AI / ML クラスタがデータの読み取りを待機したり、チェックポイントの書き込みを停止したりするたびに、有用な作業を行っていない高価なコンピューティングサイクルに対して料金を支払うことになります。

これまで、AI / ML の実務担当者は、ニッチなゾーンストレージシステムの専門的なパフォーマンスと、Google Cloud Storage のようなグローバルオブジェクトストアの信頼性とスケーラビリティのどちらかを選択する必要がありました。多くのデベロッパーは、Cloud Storage のシンプルさ、スケーラビリティ、信頼性、費用対効果を高く評価していますが、AI 時代の進展に伴い、より負荷の高いワークロードを Cloud Storage に投入し、何千もの GPU や TPU を使用してトレーニングや推論のワークロードを実行しています。従来のオブジェクトストレージでは対応できないパフォーマンスの転換点に達しているのです。Rapid ファミリーは、コンピューティングワークロードを高パフォーマンスのゾーンストレージと直接コロケーションするための複数のオプションを提供します。これにより、アクセラレータをブロックする可能性のある I/O ボトルネックを最小限に抑え、GPU と TPU をフル稼働させて生産性を維持できます。このブログ投稿では、Cloud Storage Rapid の機能について詳しく見ていきましょう。

Rapid Bucket

Rapid Bucket（一般提供）は、Cloud Storage が大規模な生成 AI、分析、その他の高パフォーマンスワークロードの進化する需要に対応できるよう支援します。これは、Gemini や YouTube を支える Google の分散ストレージシステムである Colossus を活用することで可能になっており、専用のオブジェクトストレージゾーンバケットにおいて、膨大な読み取り / 書き込みパフォーマンスと超低レイテンシを実現します。

超高速パフォーマンスブロック型ストレージのミリ秒未満のレイテンシ、並列ファイルシステムのスループット、オブジェクトストレージのスケーラビリティと使いやすさを兼ね備えた Rapid Bucket は、お客様がよくご存じの Cloud Storage と同じ環境で高パフォーマンスを提供します。

主な機能は次のとおりです。

超低レイテンシ: 最大 2,000 万の秒間クエリ数とミリ秒未満のレイテンシを実現します。
優れたスケーラビリティ: Rapid Bucket は、単一の Rapid ゾーンバケットから 15 TB/秒以上の合計読み取りスループットを実現します。
新しいセマンティクス: ネイティブな追加、無制限のリーダー（書き込み中も可能）、ベクトル化された読み取りなどの新機能により、パフォーマンスを向上できます。

AI と分析向けに最適化Rapid Bucket は、AI / ML データ準備、トレーニング、チェックポイント処理、バッチおよびストリーミング分析処理、分散データベースアーキテクチャの最適化など、さまざまな要求の厳しいシナリオで使用できます。

主な利点は次のとおりです。

アクセラレータ使用率の最適化: Rapid Bucket を使用すると、マルチモーダルトレーニング実行で GPU ブロック時間が 50% 削減され、データ読み込みが最大 2.5 倍高速化されることが確認されました。
高速なチェックポイント処理: Rapid Bucket を使用すると、従来のオブジェクトストレージと比較して、最大でチェックポイントの復元が 5 倍、書き込みが 3.2 倍高速化されます。これにより、ワークロードの中断からの復旧が迅速になり、アクセラレータ時間の無駄が最小限に抑えられ、全体的な効率が向上します。

Rapid Bucket によりチェックポイントの復元が最大 5 倍高速化

Rapid Bucket により、チェックポイントの書き込みが最大 3.2 倍高速化

Rapid Bucket の使用を開始するには、こちらをご覧ください。

Rapid Cache

Cloud Next ‘25 で最初に発表された Rapid Cache は、データ準備、トレーニング、推論用のバースト性の高いモデルの読み込みなど、AI / ML ワークロードの帯域幅を高速化し、コードを変更することなく、既存のバケットに対して 2.5 TB/秒の合計読み取りスループットを実現します。推論ワークロードの場合、Rapid Cache を使用すると、モデルの読み込みが最大 2.1 倍（114%）高速化され、TCO が 47% 削減されることが確認されています。

マルチリージョンバケットと組み合わせることで、単一のバケット名前空間を維持しながら、地理的なリージョン間に分散された GPU と TPU に柔軟にアクセスできます。これにより、バケット間のデータ移動を手動でオーケストレートする必要がなくなり、ゾーン内にコロケーションされた高パフォーマンスのメリットを享受できます。

新機能: 書き込み時の Rapid Cache 取り込み世界最大規模の最先端 AI / ML ラボのお客様から、チェックポイントの復元ワークロードや、トレーニングにフィードするデータ準備パイプラインなど、書き込み直後の読み取りを高速化する方法を探しているという声が寄せられました。以前は、データをキャッシュに保存するには、まず読み取りを行って取り込みをトリガーする必要があり、その際は、標準のパフォーマンスでバケットから直接提供されていました。

Rapid Cache の新しい書き込み時の取り込み機能は、Cloud Storage バケットへの書き込みと同時に Rapid Cache にデータを書き込むことで、この問題を解決します。このプロアクティブなアプローチにより、最初のキャッシュミスのペナルティが排除され、ワークロードは最初の読み取りで即座にキャッシュヒットの恩恵を受けることができます。これにより、チェックポイントの復元時間が最大 2.2 倍高速化され、トレーニングクラスタが中断からより迅速に復元できるようになります。

書き込み時の取り込みを有効にするには、既存の Rapid Cache の取り込み基準を変更するだけです。

Rapid Cache のシンプルさとパフォーマンスは、爆発的な導入につながっています。一般提供開始からわずか 1 年で、お客様は数千の Rapid Cache をデプロイし、デプロイされたキャッシュは 20 倍に増加しました。実際、Rapid Cache は Cloud Storage のグローバル外向きトラフィックの最大 20% を処理しています。最先端の AI / ML を利用するお客様は、ワークロードを Rapid Cache にデプロイしています。その一例が Anthropic です。同社は Rapid Cache を使用して、単一のゾーンに TPU とデータを配置し、最大 2.5 TB/秒の動的にスケーラブルな読み取りスループットを提供することで、クラウドワークロードの復元力を向上させています。

事例紹介: Thinking Machines LabThinking Machines Lab は、AI の研究とプロダクト開発を行う企業です。その使命は、適応性とカスタマイズ性に優れた AI システムを構築し、誰もが独自のニーズや目標に合わせて AI を活用できる知識やツールにアクセスできる未来を築くことです。

Next ‘26 では、Thinking Machines Lab のテクニカルスタッフである James Sun 氏が、セッション「Cloud Storage Rapid: AI と分析のための高速オブジェクトストレージ」に登壇し、Thinking Machines Lab が大規模な高パフォーマンスストレージのために実行する、データを大量に消費する AI / ML ワークロードのニーズについて発表しました。

Thinking Machines Lab は、Dataflow、Kafka、Spark でのデータ処理、マルチモデルトレーニング、オープンソースモデルのファインチューニング用の柔軟な API である Tinker のサービングなど、さまざまなワークフローを実行しています。Sun 氏の説明によると、Thinking Machines Lab のワークロードは Google Cloud Storage で実行されています。このようなデータ集約型の AI / ML ワークロードを大規模に実行すると、インフラストラクチャに大きな課題が生じます。

1 つ目の課題は、ハブアンドスポーク型のデータアーキテクチャの管理です。このアーキテクチャでは、データ処理ハブは 1 つのプライマリリージョンに配置され、トレーニング GPU は複数のリージョンに分散されます。これまで、手動によるデータの移動とライフサイクル管理は、運用上の大きな懸念点となっていました。さらに、Thinking Machines Lab のワークロード（データ準備や事前トレーニングのワークフローなど）は、マルチモーダルデータセットを準備するために大規模な Spark ワークロードに依存しており、コールドからホットに瞬時に急増することがよくあります。以前は、このような急増により、データ処理と読み込みが停滞し、重要なトレーニングサイクルが中断されるという、破壊的な 429 エラーが発生していました。

これらのボトルネックを最小限に抑えるため、Thinking Machines Lab は AI / ML パイプライン全体に Rapid Cache を統合し、良好な結果を得ました。

「Rapid Cacheは、当社の AI / ML データインフラストラクチャの中核的な基盤となっており、データの準備から、事前トレーニング、実際のトレーニング、モデルの読み込みに至るまで、重要なワークフローを支えています。重要な帯域幅のシールドおよびブースターとして機能し、迅速なイノベーションに必要なオンデマンドの高帯域幅と一貫した安定性を提供してくれるため、当社はフリート全体でデータ集約型のワークロードを妥協することなくスケールできます。」- Thinking Machines Lab、テクニカルスタッフ、James Sun 氏

要約すると、Cloud Storage と Rapid Cache によって、Thinking Machines Lab は次のメリットを得ています。

簡単、即時、スケーラブル、オンデマンドの帯域幅: チームは現在、1.8 TB/秒を超える安定した読み取りスループットのピークを達成しています。
安定性の向上: Rapid Cache により、テールエンドのレイテンシと 429 エラーが大幅に削減され、マルチモーダルトレーニングに必要な一貫したパフォーマンスが提供されます。
フリート全体のスケーラビリティ: マルチリージョンバケットと組み合わせることで、データ集約型ワークロードをフリート全体にわたってスケールできるようになりました。手動でデータを移動する手間をかけずに、急速に拡大するコンピューティング規模の需要に対応しながら、ゾーンでコロケーションされたストレージによる高パフォーマンスのメリットを享受できます。
運用効率: 階層型名前空間（HNS）の使用により、ディレクトリ名の高速変更をサポートし、クラスタをスケールアウトする際に QPS をより迅速にランプアップできるようになり、データ準備のための大規模な Spark ワークロードが最適化されました。Rapid Cache の「書き込み時の取り込み」機能により、チェックポイントの復元時にキャッシュヒットが即座に発生します。

ビジネスを加速させる最適なプロダクトをお選びください

データ準備、大規模なトレーニング、低レイテンシの推論のいずれを実行する場合でも、Cloud Storage Rapid は、Cloud Storage の特徴である信頼性とスケーラビリティとともに、高いパフォーマンスを提供します。

Rapid Bucket は、Cloud Storage のスループットと秒間クエリ数が最も高く、分析、AI トレーニング、チェックポイント処理、モデル提供などの読み取り / 書き込みのユースケースでレイテンシが最も低くなります。これにより、ストレージのボトルネックを減らし、コンピューティングの利用率を高めることができます。
Rapid Cache は、コードを変更することなく、既存のバケットで読み取り帯域幅の向上とテールレイテンシの安定化を実現します。主なユースケースには、AI トレーニング、チェックポイントの復元、サービング、マルチリージョンバケットによるアクセラレータのオプションなどがあります。

Cloud Storage Rapid ファミリーの利用を今すぐ開始しましょう。

- シニアプロダクトマネージャー、Marco Abela

- シニアプロダクトマネージャー、Luigi Pontes

Looker が実現するエージェント型 BI の時代

Fri, 15 May 2026 01:10:00 +0000

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

詳細な分析が可能な Looker と Google のエージェント型データクラウドを組み合わせることで、データのモデリング、データとのやり取り、データに基づく行動のあり方を変革する可能性が無限に広がります。今週開催される Google Cloud Next では、BigQuery とのより緊密なインテグレーションを皮切りに、AI 時代に向けて Looker を使用したビジネスインテリジェンス（BI）スタックの再構築をどのように行っているかをご紹介します。

Google のプロダクト戦略は、信頼できるデータと処方的なインサイトを提供し、誰もがエージェント型 BI を通じて行動を起こせるようにすることに重点を置いています。

Google は Gemini を使用して Looker を再構築し、AI エージェントの新時代を切り開きます。信頼できるデータ基盤を Looker が提供することで、チームは精度を損なうことなく迅速にイノベーションを起こすことができます。

会話型 BI とエージェント: 会話からアクションへ

Next ‘26 では、静的な回答を提供するだけでなく、Looker のセマンティックレイヤと既存のエンタープライズガバナンスフレームワークに基づいてダウンストリームのビジネスアクションをトリガーする Looker BI エージェントを発表します。

このたび、多くのエージェントが Looker に新たに導入されました。

ダッシュボード内で直接データに関する回答を生成できるダッシュボードエージェント。

会話エージェントのアップグレード（プレビュー版）: すでに一般提供されている Google の主要なエージェントである会話型分析エージェントを大幅にアップグレードしました。優れた推論とセマンティックグラウンディングを実現することで、曖昧さを解消します。新しい可視化ツールにより、管理者はエンドツーエンドのオブザーバビリティを実現し、パフォーマンスの傾向をモニタリングして、モデルの精度を大規模に向上させることができます。また、チームは Looker の会話型分析を Gemini Enterprise に直接パブリッシュして、信頼できるデータをより広範なワークフローに組み込むこともできます。
ダッシュボードエージェント（プレビュー版）: 会話機能を BI ワークフローに直接組み込んだダッシュボードエージェントは、即座に要約を確認し、ダッシュボード内で直接質問することを可能にします。
組み込みの会話機能（一般提供版）: 会話型分析エージェントをカスタムアプリケーションや社内ワークフローに直接組み込めるようになりました。これにより、ユーザーは専用ツールを離れることなく、UI や API を介してデータをクエリできます。
Looker のエージェントワークフロー（プレビュー版）: エージェントが重要な指標の異常をモニタリングし、隠れた相関関係と「次のステップ」の推奨事項を特定できるようになりました。これにより、収益に影響が及ぶ前にビジネスの変化に対応できるようになります。

「YouTube は、クリエイターの成功を支援し、クリエイターの創造性を世界に広げることに注力しています。これまで行ってきた Looker の会話型分析機能のテストを通じて、パートナーマネージャーが即座に行動に移せるデータを入手できるようにしました。パートナーマネージャーは、そのデータを使ってクリエイターに助言を迅速に提供し、クリエイターサポートを最適化します。」- YouTube ビジネス、テクノロジーおよびインサイト担当シニアディレクター、Thomas Seyller

セルフサービスの再構築: AI の力、UI コントロール

AI を活用した Google の簡単な探索で、使いやすさとシンプルさを実現。

ビジネスユーザーとアナリストの双方にとって、Looker がより直感的で使いやすくなります。

さらに、Looker の Explore に新しい AI アシスタントが導入されたことで、BI の難しさが解消され、複雑なワークフローが Google 検索と同じくらい使い慣れた自然言語のやり取りに変わりました。今回新たにリリースされた AI アシスタントは以下のとおりです。

新しくモダンな Looker インターフェース（プレビュー版）: モダンで Google らしく使いやすいドラッグ＆ドロップインターフェースが AI を活用したセルフサービス Explore に実装されました。タブ付きダッシュボード（一般提供版）とページネーション形式のレポート（一般提供版）が特徴です。
ビジュアリゼーションアシスタント（一般提供）: 自然言語を使用してグラフを作成、改良します。下書きされたビジュアルを積み上げ棒グラフに変更したり、地域別に色分けしたりするよう指示するだけで、Gemini が必要な処理を行います。
Expression Assistant（プレビュー版）: 必要なロジックを記述するだけで、カスタムディメンション、メジャー、フィルタを生成できます。構文を覚える必要はありません。
インサイトアシスタント（プレビュー版）: インサイトアシスタントは、単にデータを表示するだけでなく、レポートの要約生成と主要な傾向の強調表示を自動的に行い、「だから何なのか」を数秒で把握できるようにします。
セルフサービス Explore（一般提供版）: CSV ファイルや Excel ファイルの個人データと企業データを統合できます。新しいインターフェースにより、モデルを視覚的かつ簡単に構築できます。Looker はバックグラウンドで LookML コードを処理します。両者を組み合わせることで、スプレッドシートの俊敏性とエンタープライズプラットフォームの厳格なバージョン管理が実現し、アドホックなデータ分析も管理された状態を維持できます。

「ユーザーやお客様は Excel の柔軟性を気に入っていますが、ガバナンスの欠如を懸念しています。Looker のセルフサービス Explore を使用すれば、両者の長所を活かすことができます。アドホックな CSV をアップロードして迅速に仮説分析を行うことができますが、そのデータは LookML ディメンションとともに分析されるため、基盤となるビジネスロジックは依然として正確であることがわかります。」 - Promevo、最高技術責任者、John Pettit 氏

信頼できるオープンなプラットフォーム

堅牢で管理されたセマンティックレイヤは、AI のハルシネーションを防ぎ、信頼できる唯一の情報源を確保するための強力な方法です。この分野で、Google は重要な新機能を発表しています。

オープン BI と MCP（プレビュー版）: Looker は MCP ツールボックスを介してオープンソースの Model Context Protocol（MCP）をサポートしていますが、このたび、お客様が簡単に管理できるように、Looker ネイティブの新しいマネージド MCP サーバーを提供することになりました。このオープンな BI アプローチにより、AI による変革をユーザーにどう提供するかを柔軟に選択できるようになります。
Looker Extension for VS Code（プレビュー版）: 新しいインテリジェントな設定ウィザードと、ビジネスインテントをプロダクションレディなコードに直接変換する専用の LookML AI エージェントにより、デベロッパーのライフサイクルを加速します。VS Code と Agentic IDE 向けのこの新しいプラグインを使用すると、LookML でバイブコーディングが行えます。ユーザーは、AI を活用したオーサリングエクスペリエンスにより、望ましい結果を記述するだけで LookML モデルを構築できます。

Gemini 搭載の IDE から Gemini のサポートで LookML を更新

継続的インテグレーション（CI / CD）（一般提供版）: 一般提供が開始されたこの高度な CI 機能は Looker に完全に統合されており、開発ワークフロー内の SQL 検証とコンテンツテストを自動化します。本番環境に到達する前に潜在的な互換性を破る変更を特定することで、Looker はモデルの更新の信頼性と正確性を確保します。
Knowledge Catalog のインテグレーション（プレビュー版）: Looker は Knowledge Catalog を使用してメタデータをセマンティックグラフに変換し、AI エージェントがタスクを自律的に完了するために必要なコンテキストを提供します。

データの未来は、分析情報を確認するだけでなく、それに基づいて行動することにあります。Gemini の持つ力と Looker の信頼できるセマンティックレイヤを組み合わせることで、すべてのユーザーが、あらゆるワークフローで、日常的にデータドリブンな行動を実現できるようになります。

エージェント型 BI の時代へようこそ。

Looker を使ってエージェント時代に合わせたビジネス変革を実現する取り組みを cloud.google.com/looker で始めましょう。また、デベロッパーエクスペリエンスには https://docs.cloud.com/looker/docs/api-sdk からアクセスできます。

- データクラウドのプロダクト管理ディレクター、Sean Zinsmeister

- データクラウドのエンジニアリング担当バイスプレジデント、Karthik Ramakrishnan

データ分析

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

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

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

影響と結果

今後の展望

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

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

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

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

Nexus SDV の利用を始める

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

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

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

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

お試しください

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

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

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

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

Platform 37 の Model Garden

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

共に未来を築く

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

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

サンプルコード

高度な機能

課金

ご利用にあたって

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

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

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

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

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

使ってみる

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

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

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

信頼性と透明性を継承

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

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

1. 会話型分析

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

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

Open Knowledge Format のご紹介

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

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

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

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

設計の 3 つの原則

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

今後の展開

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

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

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

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

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

使ってみる

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

成長中のレストランの例

成長に伴う摩擦

デジタルツイン

BigQuery Graph でのモデリング

実務で活きる精度

将来を見据えて

まとめ

使ってみる

サーバーレス Managed Service for Apache Spark の新機能

セットアップ不要のオンボーディング

SLA の影響を受けやすいワークロードの高速起動

GPU の入手可能性の向上

トップクラスの Apache Spark 4.x サポート

マルチゾーン サポートの強化

今後の展望

ご利用にあたって

Managed Service for Apache Spark クラスタの新機能

ネイティブ実行エンジン Lightning Engine で高速化

Lightning Engine の技術的な詳細と Lowe’s の事例の紹介

より簡単に: フレキシブル VM でリソースの入手可能性を最大化

より簡単に: ゼロスケール クラスタとスケジュール設定による停止

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

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

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

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

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

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

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

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

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

マルチゾーンサポートの強化

より簡単に: ゼロスケールクラスタとスケジュール設定による停止

次世代ランタイム: Spark 4.1 を搭載したクラスタイメージ 3.0

コネクテッドシートでペタバイト単位のデータから予測を生成

Spark を使用した TPC-DS パフォーマンスベンチマーク

インテントドリブンなデータエンジニアリングの例

内部の仕組み: データパイプラインの手順

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ