BigQuery

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ML レイヤ: Distributed Graph Flow（DGF）

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

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

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

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

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

ユースケース

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

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

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロフィール（敬称略）

国立大学法人千葉大学

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BigQuery で TabFM を使ってみる

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

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

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

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

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

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

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

BigQuery の TabFM の仕組み

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

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

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

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

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

予測 ML が簡単に

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

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

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

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

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

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

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

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

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

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

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

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

ID 列を実装する方法

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

定義のオプション

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

BigQuery Graph の新機能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

グラフとチャットする

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

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

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

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

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

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

BigQuery Graph を今すぐ使ってみる

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

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

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

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

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

Fri, 28 Aug 2026 00:10:00 +0000

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

現代の企業は膨大な量の非構造化データを保有しており、その管理や価値の抽出において大きな課題に直面することがよくあります。これまで、PDF、音声ファイル、画像、非構造化テキストに埋もれたインサイトを引き出すには、ウェアハウスからのデータ移動、複雑な LLM パイプラインの統合、散在する検索インデックスの管理といった、断片化されたアーキテクチャを前提とする必要がありました。

BigQuery は、こうした非構造化データを理解するために多くの企業で活用されています。たとえば、数千件に及ぶ臨床試験ドキュメント（PDF）を管理する先進的なヘルスケア企業では、BigQuery を使用することで、アクセス、処理、グラウンディング、関連付け、活用というシンプルな 5 段階のライフサイクルを通じて、これらのドキュメントから価値あるインサイトを抽出できます。

この投稿では、このフレームワークの「グラウンディング」のフェーズに重点を置いた 3 つの主要なマイルストーンを紹介します。

自律型エンベディング生成（一般提供版）
単一クエリのパフォーマンスが大幅に向上する AI.SEARCH（一般提供版）
ハイブリッド検索（公開プレビュー版）

これらの機能が連携して AI アーキテクチャを簡素化する仕組みを、実際の臨床試験研究プラットフォームを例に詳しく見ていきましょう。

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

検索拡張生成（RAG）パイプラインや検索アプリケーションを構築するには、通常、複雑で非同期なエンベディングインフラストラクチャの管理が必要であり、新しいレコードが到着するたびに、再試行、エラーロギング、パイプラインのオーケストレーションを自分で行わなければなりません。

このたび、自律型エンベディング生成の一般提供が開始されたことで、BigQuery がユーザーに代わってこれらをすべて管理できるようになりました。スキーマで列を定義するだけで、新しいデータが取り込まれるたびに BigQuery が非同期かつ継続的にエンベディングを生成します。外部モデル（Vertex AI テキストエンベディングなど）を選択することも、BigQuery 内で Gemma エンベディングモデルをネイティブに直接利用することもできます。

実際の活用例

たとえば、Google Cloud Storage に保存されている臨床試験の PDF を分析する研究プラットフォームを構築しているとします。研究のタイトルや疾患領域をテーブルに抽出すると、そのタイトルを自動的に埋め込むことができます。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE TABLE mydataset.clinical_trials\r\n(\r\n trial_id STRING,\r\n study_title STRING,\r\n study_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>\r\n GENERATED ALWAYS AS (AI.EMBED(\r\n study_title,\r\n connection_id => 'myconnection',\r\n endpoint => 'text-embedding-005'\r\n ))\r\n STORED\r\n OPTIONS( asynchronous = TRUE )\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f874c0fe110>)])]>

BigQuery は、1 つの構成でエンタープライズ規模の処理を管理することで、複雑なサードパーティのベクトルデータベースを不要にします。この自律的なエンベディング生成により、ソーステキストの変更に合わせてデータが自動的に同期されるため、手動による ML パイプラインが不要になります。この統合アプローチにより、動的なデータセットのワークフローが効率化され、カスタムデータスクリプトの維持管理にかかる運用上の負担が軽減されます。

さらに、この一般提供の開始に伴い、自律型エンベディング生成では ObjectRefs を使用して画像からネイティブにエンベディングを生成できるようになり、真のマルチモーダル検索と分析が可能になりました。

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

会話型分析エージェントや快適なユーザーエクスペリエンスを真に実現するには、基盤となる検索インフラストラクチャが直感的かつ高性能である必要があります。

データをシームレスに埋め込むことができたら、次は、それらを効率的にクエリする手段が必要となります。このたび一般提供が開始された AI.SEARCH() は、自然言語に焦点を当てた合理的な検索エクスペリエンスを提供するもので、これにより、検索パスでエンべディングを生成することなく、意味的に関連するレコードを簡単に見つけることができます。また、自律型エンベディング生成と組み合わせることで、データセットで使用しているエンベディングモデルをそのまま検索にも利用できるため、利便性がさらに高まります。

さらに、昨年実施した効率化への投資の一環として、AI.SEARCH を単一クエリの実行向けに大幅に最適化しました。その結果、オンラインアプリケーションや単一クエリ検索（エージェント検索で最も一般的なもの）において、スロット効率が最大 133 倍向上したことが確認されています。

このことは、BigQuery 上のデータに対して、ユーザー向けの自然言語検索を高い同時実行性で処理しつつ、従来よりも高速かつ費用対効果の高い方法で提供できることを意味しています。

code_block: <ListValue: [StructValue([('code', 'SELECT base.trial_id, base.study_title, distance\r\nFROM\r\n AI.SEARCH(\r\n TABLE mydataset.clinical_trials,\r\n \'study_title\',\r\n "What treatments are available for advanced tumors?"\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f874cf32fd0>)])]>

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

セマンティック（ベクトル）検索は非常に強力です。たとえば、上記のクエリでは、「化学療法」のような概念的に関連する用語も適切に返すことができます。しかし、セマンティック検索だけでは十分でない場合もあります。たとえば、研究者が、非常に専門的な免疫療法薬の具体的な名称（「MK3475」など）を検索した場合はどうなるでしょうか。この英数字の文字列には広い意味的な文脈がないため、純粋なベクトル検索だけでは正しく順位付けすることが難しい場合があります。

BigQuery のハイブリッド検索は、語彙検索と既存のセマンティック機能を統合することで、キーワードの類似性とその根底にある意味の両方に基づいてデータを取得できます。このアプローチは、セマンティックベクトル検索の概念的な深さと、語彙マッチングの高い精度を統合するものであり、Reciprocal Rank Fusion や BM25 などのアルゴリズムを利用しています。これにより、検索結果の精度が大きく向上するほか、キーワードの出現頻度や意味的な関連性に基づく再ランキングを通じて、LLM のハルシネーションに伴う費用を抑えることができます。ユーザーは、AI.SEARCH 関数や VECTOR_SEARCH 関数で HYBRID モードや lexical_search_columns パラメータを利用することで、この仕組みを実装できます。さらに、ベクトルインデックスを拡張してキーワードデータを含めることで、パフォーマンスを最適化し、語彙検索プロセスを高速化できます。

以下のように、AI.SEARCH() 関数のモードを HYBRID に設定するだけで、ハイブリッド検索を簡単に実行できるようになりました。

code_block: <ListValue: [StructValue([('code', 'SELECT base.trial_id, base.study_title, distance\r\nFROM\r\n AI.SEARCH(\r\n TABLE mydataset.clinical_trials,\r\n \'study_title\',\r\n "Cancer treated by MK-3475",\r\n mode => \'HYBRID\'\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f874cf321d0>)])]>

これらのハイブリッドクエリを大規模に高速化するには、検索の語彙部分で使用するキーワード列を含めるように CREATE VECTOR INDEX DDL を拡張するだけで、インデックスをネイティブに統合できます。

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

ここで紹介した検索機能とエンベディング機能は、より大きなビジョンの一部にすぎません。Google は、エンドツーエンドの非構造化データ分析プラットフォームを構築しています。非構造化データの代表例のひとつがドキュメントであり、BigQuery は、以下のようなワークフローをエンドツーエンドで管理するための完全なツールセットを提供しています。

アクセス: オブジェクトテーブルを使用して、Google Cloud Storage に保存されている非構造化 PDF やドキュメントを直接クエリすることで、ゼロ ETL のワークフローを実現します。
処理: レイアウト対応のチャンキング（RAG に最適）には AI.PARSE や AI.CHUNK_DOC（近日リリース予定）などの組み込み AI 機能を利用するほか、エンティティ抽出 / 要約には AI.GENERATEを、SQL パイプラインで基盤モデルを直接使用してレコードを即座に分類するには AI.CLASSIFY を利用します。
グラウンディング: 自律型エンベディングとハイブリッド検索を使用して、精度の高いコンテキストを構築します。ハイブリッド検索は、セマンティックベクトル検索による概念的な理解と、語彙的なキーワードマッチングによる高い精度を組み合わせたものです。意味的な関連性とキーワードの出現頻度の両方に基づいて結果を再ランキングすることで、検索結果の精度が大きく向上するほか、LLM のハルシネーションも抑制できます。
関連付け: 抽出されたエンティティ（スポンサー、臨床試験、医薬品など）を BigQuery Graph にマッピングすることで、隠れたマルチホップのインサイトを発見できます。特別なグラフデータベースは必要ありません。
活用: BigQuery の会話型分析エージェントを活用して、これらすべてを統合します。AI.AGG などの関数を使用すると、複雑なデータと直接やり取りしたり、可視化を生成したり、大規模なトレンド分析を実行したりできます。

BigQuery において非構造化データが第一級のデータとして扱われるようになったことで、未加工のドキュメントと会話型 AI との間のギャップを埋めることが可能になりました。

準備ができたら

コードを確認する: BigQuery のドキュメント分析 GitHub リポジトリで、臨床試験に関するエンドツーエンドのデモの完全版をご覧ください。
ドキュメントを読む: 自律型エンベディングとハイブリッド検索の公式ドキュメントを読み、独自の統合データパイプラインの構築を今すぐ始めましょう。

- Google、プロダクトマネージャー、Joe Malone

- Google、エンジニアリングマネージャー、Francis Lan

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

Fri, 28 Aug 2026 00:00:00 +0000

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

急速に変化するデジタルエコノミーにおいて、データは最も重要なエンジンです。しかし、多くの企業は、脆弱な社内 ETL パイプラインの構築や修正に週 100 時間以上をかけたり、予測不可能なサードパーティツールと格闘したりといった犠牲を払う逆説的な状況に陥っています。

毎日、数千社のお客様が信頼して利用する BigQuery Data Transfer Service（DTS）は、このようなエンジニアリングの負担を解消します。フルマネージドのノーコードデータ移動ソリューションである BigQuery DTS は、BigQuery へのデータの取り込みを自動化し、チームがパイプラインのメンテナンスから戦略的なデータサイエンスへと数分で移行できるようにします。

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

BigQuery DTS は、データベース、広告、マーケティングプラットフォームにわたりデータサイロを排除するために、統合環境を急速に拡大しています。最新の追加機能と拡張機能は以下のとおりです。

オープンレイクハウスの取り込み

Apache Iceberg マネージドテーブルへの直接取り込み（プレビュー版）: Google Cloud Storage、Amazon S3、Azure Blob Storage などの一般的なソースから Iceberg マネージドテーブルにデータを直接取り込めるようになりました。これにより、BigQuery のトップレベルのパフォーマンスチューニングを活用しながら、マルチクラウドストレージと他のクエリエンジンとの完全な相互互換性を維持できます。

次世代のエージェント型アーキテクチャ

フルマネージドのリモート Model Context Protocol（MCP）サーバー（プレビュー版）: これにより、開発者は AI アプリケーションや AI エージェントを DTS に接続し、プログラムを使ってデータソースを検出したり、ユーザーに代わって転送を構成、実行したりできます。

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

Microsoft SQL Server（プレビュー版）: トランザクションテーブル、スキーマ、運用データを BigQuery 内の分析環境に直接転送し、簡単に一元化できます。
PostgreSQL（一般提供版）と MySQL（一般提供版）: データ配信を自動化し、大量のウェブワークロードやアプリケーションワークロードを一元的なデータウェアハウスに数分で簡単にレプリケートできます。オンプレミス環境、Cloud SQL、その他のクラウドからのデータレプリケーションに対応しています。

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

Shopify（プレビュー版）: 粒度の高い注文履歴、在庫ログ、顧客プロファイルを分析スキーマに直接抽出するプロセスを自動化します。
Klaviyo（プレビュー版）: 詳細なメールと SMS のエンゲージメントログ（クリック、送信、開封など）を抽出して、正確なマルチチャネルライフサイクル属性を構築します。
HubSpot（プレビュー版）: パイプライン、連絡先のトラッキング、インバウンドマーケティングの指標を同期して、収益オペレーションチームの連携を維持します。
Mailchimp（プレビュー版）: キャンペーンのパフォーマンスとオーディエンスリストの属性をデータウェアハウスに直接、自動的に移動します。

移行コネクタ

Snowflake（一般提供版）: 増分転送、スキーマの自動検出、プライベート接続、3 つの主要クラウド（Google Cloud、AWS、Azure）に保存されているデータの移行サポートなどの機能を使用して、Snowflake からデータを移行できます。

主要なコネクタの機能強化

ServiceNow、Salesforce、Oracle: ネイティブの増分更新サポートが強化され、エンタープライズ規模の CRM、ITSM、財務ワークフローの大規模なパイプライン更新が高速化されました。

BigQuery Data Transfer Service を選ぶ理由

エンタープライズアーキテクチャ内でデータを移動する際に、費用、管理オーバーヘッド、パイプラインの健全性の間で複雑な妥協を求められるべきではありません。BigQuery DTS は、次の 3 本の柱にわたって独自のメリットを提供します。

1. 比類のないコスト効率

主要なソースの取り込み費用はゼロ: Google 広告、Google アナリティクス 4、キャンペーンマネージャー、YouTube、Google Cloud Storage など、Google Play を除く Google のソースすべてのデータの取り込みが無料です。Amazon S3、Azure Blob Storage、Amazon Redshift、Teradata の取り込み費用も無料です。
サードパーティ SaaS は使用量ベースの低料金: サードパーティソースからの取り込みは、すべて柔軟な使用量モデルに基づきます。コンピューティング料金は、主要なリージョンでスロット時間あたり 6 セント未満です。料金は行数ではなくコンピューティングフットプリントに応じて変動するため、ソースデータの圧縮形式と利用可能なネットワーク帯域幅によっては、大量のデータを効率的に転送できます。

2. スムーズなセキュリティとネイティブ管理

中継サーバーや、外部のセキュリティと API の構成が不要になります。BigQuery DTS は Cloud IAM と完全に統合されています。データ転送は、追加の構成オーバーヘッドなしで、宛先データセットの列レベルのセキュリティ、行レベルのセキュリティ、顧客管理の暗号鍵（CMEK）を即座に継承します。ストリームは、ネイティブの Google Cloud 境界内で安全に流れます。

3. 業界トップクラスのパフォーマンスとレジリエンス

エンタープライズ規模でデータを管理する場合、ダウンタイムはビジネスの機会損失を意味します。BigQuery DTS は、高い復元力を持つ取り込みフットプリントを提供し、これは厳格な Google Cloud サービスレベル契約（SLA）に裏付けられています。システムは月間稼働率 99.99% 以上を実現し、分析、自動化されたパイプライン、運用ダッシュボードの更新を確実に保証します。

データ運用の変革を始めましょう

手動の取り込みスクリプトにビジネスの成長を制限される状況はもう終わりにしましょう。Google のネイティブクラウドレイクハウスデータ移動アーキテクチャを利用して、最新のスケーラブルなデータスタックを構築している数千社もの企業の仲間に加わってください。

今すぐプラットフォームをお試しください。BigQuery Data Transfer Service コンソールに移動し、コネクタを選択して、数回クリックするだけで最初の自動転送をデプロイできます。

次に構築すべきコネクタは？

Google は、お客様のビジネスニーズに基づいて、ネイティブ統合ライブラリを常に拡大しています。現在、手動で抽出せざるを得ないソースはあるでしょうか。次にレプリケートする必要がある特定のリレーショナルデータベース、NoSQL エンジン、リージョン SaaS プラットフォームについて、機能リクエストでお知らせください。

機能リクエストは、公開 Issue Tracker からお送りいただけます。

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

- エンジニアリングマネージャー、Pallavi Palleti

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. タグ値を作成する

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

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

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

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

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

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

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

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

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

3. テーブルを更新する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

車両側: AAOS SDV

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

予測メンテナンス

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

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

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

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

ご利用にあたって

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

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

詳細

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

影響と結果

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

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

今後の展望

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お試しください

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

豊田自動織機ITソリューションズ: Gemini Enterprise を一斉展開し、業務効率化とナレッジ集積、人材の育成・確保を実現

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

生成 AI の社内展開は、部署を限定して段階的に進めていくのが定石とされています。しかし、株式会社豊田自動織機ITソリューションズ（以下、TIIS）は、500 ライセンスの Gemini Enterprise を全社員に一斉提供するという方法を選択。情報の集積と活用による業務拡大、人材確保、新たな価値の創出などを図っています。その詳細を、同社代表取締役社長鈴木洋氏をはじめとする今回の取り組みのコアメンバーに伺いました。

利用しているサービス:
Gemini Enterprise, BigQuery など

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

激変する IT 業界の中でスタートした業務改革「TIIS-X プロジェクト」

TIIS は豊田自動織機グループ（従業員数約 8 万人 / 関連企業数約 300 社）における国内唯一のシステムインテグレーターです。社員約 450 名のうち、400 名ほどが IT 業務に従事しており、生産現場における設計業務からシステム開発、サーバーネットワークなどのインフラ構築、セキュリティ管理、組込みソフトウェアの開発まで、幅広い領域でグループの課題と向き合い、解決してきました。そんな同社の優位性と現況について鈴木氏は、こう胸を張ります。

「弊社は豊田自動織機グループの一員として、IT 戦略立案から参画し、超上流の要件定義から開発、運用保守まで、IT に関する全ライフサイクルに携わっています。その幅の広さと奥行きの深さ、そしてグループ現場の業務知識と IT スキルの両方を備えていることが我々の強みです。特にこの 3 年間は、新型コロナ禍を経て豊田自動織機からの IT 需要が爆発的に増加し、売上規模が倍以上に拡大しています。」

しかし、これと同時に IT 業界全体を取り巻くビジネス環境が激変。人材の流動性が高まった結果、長期的に活躍できる環境の整備が喫緊の重要課題となってきました。一方、運用面では、既存システムの老朽更新がリソースを圧迫し、新たな価値創造を難しくしつつありました。

このような状況を受けて始まったのが、社内変革活動「TIIS-X プロジェクト」です。2022 年に始まった本プロジェクトは、「テクノロジー推進」「ワークスタイル・制度変革」「コミュニケーション活性化」の三本柱で構成され、多角的な問題解決を目指すものとなっていました。鈴木氏と共にこの取り組みを推進してきた、執行職の小形健一氏は、その "伏線" が、すでに 10 年ほど前から張られていたと語ります。

「2017 年ごろに、散在していた社内ファイルサーバーを今後どのように運用していくかという議論が起きました。その際重視したのが、情報の検索性です。まず、弊社には過去に開発したアプリや業務システムの膨大なデータがありますので、これらを集約していかに活用するかは、将来の事業展開に向けた鍵となります。また、情報の整備は、人材の流出や業務の外注化などが進む中、個々人に蓄積した知見やノウハウを共有・活用していくという意味でも有効です。そこで 2018 年、社内ファイルサーバーを、優れた検索性を備える Google ドライブに統合しました。」

当時はまだ生成 AI が話題になる以前でしたが、Google ドライブを選んだ背景には、そう遠くない未来に AI 技術が劇的に進化するだろうという読みもあったといいます。

「例えば 2022 年末に対話型 LLM が大ブレイクした後、社内でさまざまな生成 AI サービスを検証しました。この際、焦点となったのが学習です。学習効果を最大限に得るには、500 万ファイルを超える社内データをすべて外部に送出して学習させる必要がありましたが、現実的ではありませんし、セキュリティの観点からも実施したくありません。しかし Google Cloud の生成 AI サービスであれば、Google ドライブに統合済みの社内データを安全かつシームレスに活用できます。2024 年末に、企業向け AI エージェントプラットフォームである Gemini Enterprise（当時の名称は Google Agentspace）が発表された時には、待ち望んでいたツールがついに登場したなと思いました。」（小形氏）

Gemini Enterprise が選ばれた理由は、データの連携性だけではありません。小形氏のもと、TIIS の技術戦略推進を担ってきた同社デジタル情報技術戦略部部長丹羽宏太氏は、グラウンディング（回答根拠の提示）によって情報の正確性を担保できることや、他社サービスと広く連携できることも大きな優位点だったと言います。

「Gemini Enterprise は、Google Cloud の各種サービスだけでなく、豊富に用意されたコネクタによって、多くの外部ソースとつなげることができます。弊社では業務にさまざまなサービスを日常的に利用しているので、このオープンさはとても魅力的でした。現在、TIIS では Outlook やSharePoint、OneDrive、GitHub などを含む合計 9 個のコネクタで社内サービスと接続しており、社内の知見を広く共有することに成功しています。」

PoV の成功を踏まえて、500 ライセンスを全社員に一斉に展開

こうして TIIS は、2025 年 4 月に Gemini Enterprise の導入を決定。8 月から開始された PoV（Proof of Value / 価値実証）では、間接部門も含めた各部署から選別された 12 名の「CHAMPION（活用の牽引役）」と協力するかたちで、Gemini Enterprise の活用方法と、運用における注意点などを集中的に検証・解決。その3か月後には、500 ライセンスを契約し、約 450 人の全社員に一斉展開することを決定しました。

「全社一斉展開を決意したのは、少しでも早く、より多くの社員に生成 AI の便利さを実感し、活用してもらいたかったからです。もちろん、そのコストは決して小さいものではありません。しかし TIIS なら誰でも最先端の生成 AI サービスを使えるという話が広まれば、就職活動を始める学生にも大きなアピールになります。そうした副次的効果を含めれば、十分にリターンのある投資だと考えました。」（鈴木氏）

Gemini Enterprise の現場への展開を担当したデジタル情報技術戦略部デジタル戦略推進課 BX 推進 1 グループグループリーダーの堀尾一孝氏は、現場への展開に向けた取り組み、工夫について、次のように振り返ります。

「PoV に協力してくれた 12 名の CHAMPION をそのまま推進チームとし、ワークショップやハンズオン体験会を繰り返し開催しました。また、社内チャットツールを使った日常的な情報発信や見やすいドキュメントの整理、チャンピオンたちが作った便利な AI エージェントの紹介・共有など、さまざまなかたちで興味を促し、実際に使ってもらえるよう手を尽くしました。」

なお、導入に際する一連の取り組みにおいては、Google Cloud のコンサルティングサービスと技術支援を活用。専門家集団による手厚い支援を受けながら、Gemini Enterprise を業務プロセスに組み込んでいくことができました。

「導入に際しては、まず業務的にインパクトの大きなものを対象にする、そこから業務プロセスを細かく分解して、それぞれに適切に AI を活用していくアプローチなど、私たちが持っていなかった知見を惜しみなく共有いただけたことで、無駄なステップを踏まずに導入できました。困った時に Google Chat ですぐに相談できることも心強かったですね。」（丹羽氏）

「技術的な支援もたくさんしていただいています。例えば、社内の課題を解決する AI エージェントを作る際は、ADK（Agent Development Kit）やローコードの対話型エージェントなど、さまざまな選択肢があるのですが、課題ごとに、どのような構成を取れば効率的なのかもアドバイスいただきました。コンサルティングチームの伴走は社内のナレッジ蓄積でも極めて有用でした。」（堀尾氏）

Gemini Enterprise の活用は、新たなる価値創造に向けた切り札になる

導入後、Gemini Enterprise は驚くべき速度で TIIS の現場に浸透しています。社員によって作成された AI エージェントは 1,300 以上にもなり、契約条項の精査や誤字・脱字のチェック、請求書・領収書の確認、議事録の要約、スライド作成、過去のシステム問い合わせ台帳の検索など、これまでマニュアルで行われてきた作業が劇的に効率化されているとのことです。もちろん、経営面でも大きなインパクトが生まれています。

「Gemini Enterprise の導入後、会社全体の平均残業時間は、前年度比で約 10% 減少しました。退職者数も前年度比で約 30% 減少しています。Gemini Enterprise 以外のさまざまな取り組みの成果も含めた数字ではあるのですが、想定していた以上の成果を得られています。」（鈴木氏）

TIIS では、Gemini Enterprise を業務プロセスの中にシームレスに組み込む取り組みが加速しています。BigQuery とLooker を活用したデータプラットフォームを整備し、コネクタで連携できない ERP や Excel データも含めたあらゆる社内資産を扱える環境を構築中です。

「中長期的な目標は、数年に一度、大型案件を受託・開発する『一括構築型モデル』から、長いライフサイクルの中で、小さな改善を速く回す『継続的な改善モデル』への転換を推進し、工数のすべてを価値向上に直結させていくことです。簡単なことではありませんが、まるで複雑な問題を一発で解決する "銀の弾丸" のように、想像以上の働きをしてくれるツールが登場したことで、その実現は夢物語ではなくなりつつあると強く感じています。また、我々が Gemini Enterprise で成果を出していけば、横展開もしやすくなります。弊社の取り組みをモデルケースに、豊田自動織機グループ全体で Gemini Enterprise を使っていこうという気運が高まると、さらなる業務効率化が実現できるのではないかと期待しているところです。」（鈴木氏）

株式会社豊田自動織機 IT ソリューションズ
1991 年に株式会社豊田自動織機の情報システム部門が独立して設立。国内唯一のシステムインテグレーター子会社として、グループ内の IT 課題解決を一手に担うほか、外部一般企業へのソリューション提供も拡大中。従業員数は 496 名（2026 年 4 月現在）。

インタビュイー（写真左から）
・デジタル情報技術戦略部デジタル戦略推進課 BX 推進 1 グループグループリーダー
　堀尾一孝氏
・代表取締役社長　鈴木洋氏
・執行職　小形健一氏
・デジタル情報技術戦略部部長　丹羽宏太氏

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

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

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

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

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

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

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

将来を見据えて

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

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

まとめ

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

使ってみる

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

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

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

ペタバイトから予測へ: 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

BigQuery

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

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

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

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

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

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

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

ML レイヤ: Distributed Graph Flow（DGF）

ユースケース

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BigQuery で TabFM を使ってみる

BigQuery の TabFM の仕組み

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

予測 ML が簡単に

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

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

ID 列を実装する方法

使ってみる

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

BigQuery Graph の新機能

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

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

BigQuery Graph を今すぐ使ってみる

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

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

実際の活用例

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

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

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

準備ができたら

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

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

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

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

移行コネクタ

主要なコネクタの機能強化

BigQuery Data Transfer Service を選ぶ理由

データ運用の変革を始めましょう

次に構築すべきコネクタは？

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

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

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

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

使ってみる

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

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

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

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

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

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

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

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

車両側: AAOS SDV

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

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

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

予測メンテナンス

ご利用にあたって

詳細

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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