BigQuery

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: 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 0x7f97e9f59d90>)])]>

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

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

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

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

将来を見据えて

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

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

まとめ

レストラン業界は、ビジネスデータを単なるリストとして扱うリレーショナルな方法だけでは対応しきれない段階に来ています。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

ミリ秒未満の読み取りレイテンシを実現する新しい Bigtable インメモリ階層

Wed, 20 May 2026 02:10:00 +0000

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

デジタルインフラストラクチャの成否が大きく問われる世界では、スピードは単なる指標ではなく、価値そのものです。Google Cloud Next ‘26 で発表した Bigtable インメモリ階層は、フルマネージドのクラウドデータベースサービスに次のような画期的な機能をもたらします。

ミリ秒未満の読み取りレイテンシで時間的制約があるデータを処理
1 ドルあたりのポイント読み取りスループットが最大 10 倍向上、TCO を大幅に削減
ホットスポット耐性により、単一行に対して最大 120,000 クエリ/秒を手間なくサポート

詳しくは、Bigtable のパフォーマンスに関するドキュメントをご覧ください。次に、Bigtable インメモリ階層がワークロードのパフォーマンスと運用プロセスに与える影響を見てみましょう。

キャッシュミスの悪夢: よくあるケース

午前 2 時に、プロモーションキャンペーンが一気に拡散され、トラフィックが急増していると仮定します。あいにく、データベースアーキテクチャはトランプの家のように脆く不安定なため、プライマリデータベースは処理が追いつかず、別のキャッシュレイヤがシールドとして機能している状態です。

そこに突然、アクセス集中の問題が発生しました。拡散された同じコンテンツに皆がアクセスしようとしています。キャッシュノードは飽和状態になっています。より大きなノードにアップグレードするか、リードレプリカを追加するしかありません。チーム全員、疲れ切っています。2 つの異なるシステムを管理し、複雑なキャッシュアサイドのロジックを維持する（そしてキャッシュ内のデータがデータベースと同期していることを祈る）だけでなく、実際のインシデントに対応する必要もあります。そのために、ピーク負荷に対応できるように CPU をオーバープロビジョニングし、すべてがメモリに収まるように RAM を追加し、キャッシュアサイドの複雑さを回避します。これにより、実際にはメモリに保存する必要のないウォームデータに対して、高額な料金を支払うことになります。理論上の 1 ドルあたりのスループットは高いように見えますが、実際にはリソースの 90% がほとんどの時間アイドル状態になっています。

Bigtable のインメモリ階層の登場

Bigtable インメモリ階層はこのサイクルを断ち切ります。RAM、SSD、HDD にまたがるデータ階層化を、ハイブリッドストレージアーキテクチャを備えた単一の統合サービスで実現することで、「仲介役」が不要になります。

その結果、キャッシュの元々のスループットと速度に、Bigtable が設計された目的である耐久性とスケーラビリティが加わります。拡散によりアクセスが急増すると、Bigtable はアクセスが集中している行を自動的にメモリに移動して負荷を処理します。CPU スパイクが発生することも、パフォーマンスが低下することもありません。トラフィックが増加すると、Bigtable クラスタも増加し、インメモリ読み取り能力が向上します。これでアイドル状態の RAM やキャッシュノードに過剰な料金を支払う必要はなくなります。Bigtable がデータをインテリジェントに管理し、ホットデータのみをメモリに保持して、インメモリ階層と SSD ストレージ間のデータ整合性を確保します。

TCO のメリットは明らかですが、おそらく最も重要なのは、それによって得られる安心感です。これはかけがえのないものです。

舞台裏のご紹介

ほぼすべてのデータベースサーバーは、CPU がインデックスや Bloom フィルタなどのレイテンシの影響を受けやすい、頻繁にアクセスされるデータに高速にアクセスできるようにするために、メモリを使用しています。では、この発表のどこが特別なのでしょうか。

その秘密は、リモートダイレクトメモリアクセス（RDMA）にあります。これは、システムのオペレーティングシステムも CPU も関与せずに、コンピュータがあるマシンのメモリから別のマシンのメモリに直接データを転送できる高性能ネットワーキングテクノロジーです。Google のアーキテクチャは、RDMA を使用してサーバーメモリに高速に直接アクセスできるようにします。その結果、インメモリ階層のスループットとレイテンシは、サーバー CPU による制限を受けることがなくなり、大きなメリットにつながります。Data Boost が ML トレーニングなどの負荷の高いワークロードに対してディスクへの直接アクセスを可能にするのと同様に、RDMA はリアルタイム処理においてメモリへの高速な直接アクセスを実現します。

よく利用されているソーシャルメディアサイトを運営しているとします。ユーザーの 98% はフォロワー数 250 人未満ですが、最も人気のあるユーザーはフォロワー数 1 億人以上です。ユーザーの 60% は投稿が週 1 回未満で、上位 10% のユーザーがコンテンツの 80% を生成しています。一般的な投稿の表示回数は 500 回ほどですが、人気のある投稿では数千万回に達します。

このユースケースに効率的に対処するために、次のようなデータ階層化を必要としています。

メモリ: フォロワー数の多いユーザーのプロファイルからのコンテンツ
SSD: 最近のコンテンツ、アクティブなユーザープロファイル
HDD: 古いコンテンツ、非アクティブなユーザープロファイル

幸いなことに、Bigtable ではこれを非常に簡単に行うことができます。クラスタでインメモリを有効にして、データベースリクエストを発行する際にメモリ対応のアプリケーションプロファイルを使用するだけで、ホットデータのライフサイクルを自動的に管理できます。また、エージベースのポリシーを設定して、コールドデータをアクセス頻度の低い階層に分類することもできます。この設定では、コンテンツが読み取られると、そのコンテンツは永続ストレージからメモリ階層に昇格され、それより後に読み取られたアイテムの保存場所を確保するために削除されるまでそこに留まります。この作業に手を煩わせることはありません。5 年前の投稿が突然再浮上して拡散されたとしても、心配無用です。

しかし、キャッシュ保存するものをより細かく制御したい場合はどうすればよいでしょうか。人気のあるコンテンツクリエイターのリストがあり、そのごく一部の投稿にのみメモリ使用量を制限したいとします。そのためには、それらのユーザーに対するトラフィックはメモリ対応のアプリプロファイル経由でルーティングし、他のコンテンツに対してはメモリ対応でないアプリプロファイルを使用するだけです。

キャッシュミスの悪夢を再現

キャッシュミスのシナリオを再現してみましょう。ただし、今回は Bigtable のインメモリ階層を有効にしています。日曜日の午前 2 時に、プロモーションキャンペーンが急速に拡散され、トラフィックが急増しています。今から 1 時間以内に 1 秒あたり 8 万回の読み取りを追加で処理できるようにする必要があります。しかし、通知が来ることはなく、午前 11 時に鳥のさえずりで目覚め、穏やかな朝食と素晴らしい天気で 1 日を始めます。午前 2～3 時の間にトラフィックが急増したことを示す唯一の証拠は、請求額が 0.40 ドル増えていることです。

幅広い業界においてアプリケーションに対するリクエストの分布はべき乗則に従うため、このようなシナリオはソーシャルメディアに限定されません。たとえば、証券取引所では数千の証券が取引されますが、最も活発に取引される上位 30 銘柄が通常、1 日の総取引量の 40% 以上を占めています。同時に、最新のデータポイント（最終取引、売値 / 買値）は頻繁にリクエストされ、低レイテンシのレスポンスが期待されますが、過去のデータへのアクセスははるかに頻度が低く、レイテンシの許容範囲は比較的広くなります。この例のデータを Bigtable のデータ階層に分類してみましょう。

メモリ: 最も人気の高い株式の直近の証券価格
SSD: 最近の履歴、集計指標（時間単位、日単位、月単位など）
HDD: 古いデータ、個々の取引などの未加工のイベント

この機能のユースケースは多岐にわたります。自動取引システムはメモリから最新の価格にアクセスし、個人投資家は SSD のデータからローソク足チャートを作成し、クオンツは Data Boost を使用して HDD の過去のデータにアクセスしてモデルをバックテストします。すべてが 1 つのデータベースに格納されており、互いに干渉することはありません。金融時系列をテレメトリーデータ、センサーネットワーク、デジタルツインに置き換えても、ストーリーはそれほど変わりません。

また、Bigtable のインメモリ階層を使用しても、高可用性、スケーリング、監査、ガバナンス、アクセス制御などの他のエンタープライズ機能が妨げられることはありません。これらの機能は通常、大きなオーバーヘッドを発生させます。このような企業要件を満たしながら、ミリ秒未満のレイテンシを実現していることは非常に印象的です。また、クライアントとネットワークを最適化することで、p50 SSD レイテンシを 2 ミリ秒未満に短縮することもできました。

Bigtable Enterprise Plus を使ってみる

Bigtable インメモリ階層は、新しい Bigtable Enterprise Plus エディションでのみご利用いただけます。このエディションは、多くの追加機能を備えており、最高レベルのパフォーマンスと管理効率を求める組織向けに設計されています。

今すぐスタックを Bigtable Enterprise Plus とインメモリ機能にアップグレードして、インフラストラクチャの管理をやめ、未来の構築を始めましょう。

詳細

Bigtable Enterprise Plus エディションと、そのインメモリ階層以外の機能の詳細をご覧ください。Google Cloud コンソールにアクセスして、新しいクラスタを作成したり、既存のクラスタをアップグレードしたりして、ぜひお試しください。
Bigtable を初めてご利用になる方は、新しい Bigtable 無料トライアルで Google の先駆的な NoSQL データベースをご体験いただけます。専用の Enterprise Edition ノード、500 GB のストレージ、Bigtable の使い方ガイドをご利用ください。
利用開始方法、技術仕様、リージョン別の提供状況について詳しくは、Bigtable の公式プロダクトページをご覧ください。

- Bigtable、シニアプロダクトマネージャー、Anton Gething

- Bigtable、エンジニアリングマネージャー、Sudarshan Kadambi

Google Cloud Knowledge Catalog のご紹介

Fri, 01 May 2026 02:00:00 +0000

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

従来のデータカタログは、技術ユーザー向けの手動インベントリとして作成されており、AI エージェントが必要とする深いコンテキストではなく、テーブル構造に重点が置かれていました。エージェントがビジネス上のセマンティクスやデータ間の関係性を十分に把握できていないと、ハルシネーションや高レイテンシ、古い分析情報の生成につながります。

この問題に対処するため、Google は Dataplex を動的で常時稼働の Knowledge Catalog へと進化させています。企業向けのユニバーサルコンテキストエンジンとして、エージェントが複雑なタスクを高精度で実行できるよう支援するツールです。

Bloomberg Media のようなお客様は、すでに Knowledge Catalog を使用して、信頼できるコンテキストでエージェントを強化しています。

「Knowledge Catalog を通じて Bloomberg Media のエンタープライズメタデータとビジネスコンテキストを統合することで、Data Access AI Agent を無事にリリースできました。この社内ソリューションにより、組織全体の関係者はデータレイクを直感的に探索できるようになり、複雑なビジネス上の問いに対しては、AI が即座にわかりやすく説明します。重要なのは、信頼できる組織内のコンテキストを根拠として AI に提供することで、生成されるあらゆる分析情報の精度と品質に自信を持てるようになることです。」

- Bloomberg Media、CTO、William Anderson 氏

Knowledge Catalog は、次の 3 つの基本的な柱で構成されています。

集約: コンテキストを統合し、定義の不整合を解消
拡充: 継続的に意味を生成し、関係性をマッピング
検索: 高精度の検索でエージェントを支援

集約: データアセット全体でコンテキストを統合

真のコンテキストを構築するには、あらゆる場所に散在する情報を集約する必要があります。Knowledge Catalog は、Google とパートナーのデータプラットフォーム、セマンティックモデル、サードパーティのカタログ全体でネイティブコンテキストを集約し、それらを管理の行き届いた信頼できる情報源に一元化します。

幅広いメタデータの集約 （GA）: 真に包括的なコンテキストエンジンを構築するには、サイロをすべて解消する必要があります。Knowledge Catalog は、BigQuery、AlloyDB、Spanner、Cloud SQL、Firestore（プレビュー版）、Looker（プレビュー版）などの基盤システム全体から技術的メタデータを自動的に収集します。また、Atlan、Collibra、Datahub、Ab Initio、Anomalo などのサードパーティデータベースやパートナーカタログとの統合もサポートしており、レガシーメタデータもエージェントの枠組みに取り込むことができます。
エンタープライズ接続 （プレビュー）: 業務を本当の意味で理解するには、セマンティックコンテキストが企業内の主要システムをすべてカバーしている必要があります。そうしたシステムは、Google Cloud Lakehouse を使用し、コンテキストフェデレーションによって相互接続されます。これにより Knowledge Catalog は、Palantir、Salesforce Data360、SAP、ServiceNow、Workday などのアプリケーション、オペレーティングシステム、AI プラットフォームを迅速かつ詳細に可視化できます。たとえば、SAP のデータプロダクトは自動的に Knowledge Catalog にマッピングされます。
LookML エージェント: ビジネスロジックの定義方法を自動化します。新しい LookML エージェントは、戦略ドキュメントを自律的に読み取り、ビジネスにそのまま活用できるセマンティクスを即座に生成します。これらのセマンティックモデルを Knowledge Catalog に集約することで、コアとなるビジネスロジックを企業全体で連携させ、エージェントがアナリストと同じ定義に基づいて推論を導き出せるようにします。デベロッパーは、LookML セマンティックモデル用の新しい VS Code 拡張機能を利用し、エージェント対応のあらゆる IDE からセマンティックレイヤのライフサイクル全体を扱えます。
BigQuery measures（プレビュー版）: プログラマティックなビジネスロジックを SQL エンジンに直接組み込むことで、データの整合性を再定義します。BigQuery measures により、すべての計算が汎用的に再利用可能になり、かつ数学的に正確であることが保証されます。Knowledge Catalog は最終的なアグリゲータとして機能し、BigQuery measures と LookML を管理の行き届いたセマンティック基盤に一元化します。
データプロダクト（GA）: データプロダクトは、エージェントを支えるデータアセットとコンテキストをパッケージ化し、本番環境での信頼性を高めます。この自己完結型のブロックには、インテント、SLA、ガバナンスの制約が組み込まれており、複雑な AI ユースケースをスケーリングするための基本要素を提供します。

拡充: 継続的な学習を通じて意味を生成する

Knowledge Catalog は継続的にデータを拡充します。手動によるキュレーションに留まらず、構造化スキーマ、クエリログ、BI セマンティックモデルを能動的に分析し、非構造化データからエンティティ間の関係性を抽出します。こうした継続的なデータ拡充機能を、チームが実際に作業する環境に提供します。

スマートストレージおよびオブジェクトコンテキスト API（プレビュー版）: Google Cloud Storage（GCS）にネイティブで組み込まれたスマートストレージは、ファイルがバケットに保存されると、即座かつ自動的にタグ付け、埋め込み、メタデータによる拡充を行います。このインテリジェンス機能を Knowledge Catalog に統合することで、エージェントは非構造化データを即座に発見できるようになります。
高度なマルチモーダルメタデータ抽出（プレビュー）: 複雑な非構造化データの集合に対しては、Knowledge Catalog は Gemini とネイティブで統合されているため、有用なビジネス情報を特定するとともに、非構造化コンテンツから直接エンティティを抽出して、複雑なビジネス関係をマッピングするパイプラインを自動的に構築できます。
コンテキストの自動キュレーション（プレビュー版）: Knowledge Catalog は、データセット、データプロダクト、関係性、検証済みの SQL パターンに対して、ビジネス用語集を含む自然言語の説明を自動生成します。これにより、人間とエージェントの双方が推測に頼ることなくデータを活用できます。こうした隠れた関係性やインテントに基づくパターンを推論することで、データとビジネスの実際の関連性を示す、動的に進化し続けるマップを構築します。
検証済みのクエリとセマンティックガードレール（プレビュー版）: AI の失敗の主な原因の一つは、ハルシネーションによる誤ったロジックや推測に基づく SQL 結合です。これを防ぐために、Knowledge Catalog には検証済みの SQL パターンと事前生成された自然言語の質問が用意されています。

検索: 高精度で安全なデータ取得によるエージェント活用の拡大

膨大なコンテキストレイヤを作成することは重要ですが、エージェント時代では、検索は新しいクエリ経路に進化しています。自律型エージェントは、ユーザーに代わって作業する際に非常に高速に反復処理を行います。エンタープライズ規模での最大の問題は、スピード、関連性、グローバルなリーチ、セキュリティです。

高精度セマンティック検索（GA）: Knowledge Catalog は、Google の数十年にわたるイノベーションを活用したハイブリッド検索スタックを使用します。Google 検索と同じ高度なクエリ書き換え技術と ML 技術を基盤として構築されており、エージェントが必要とする 1 秒未満のレイテンシと的確な関連性を提供します。エージェントがプロンプトを受け取ると、Knowledge Catalog は適切なコンテキストを即座にランク付けし、リアルタイムでエージェントに返します。
アクセス制御対応の検索: エージェント時代には、適切なデータとそのコンテキストを見つけることが重要です。エージェントが間違ったコンテキストを取得すると、ハルシネーションが発生します。信頼性を確保するために、このグローバル検索では、ソースシステムで定義されているメタデータアクセス権限が尊重されます。これにより、エージェントは明示的に閲覧を許可されたアセットのみを取得、操作します。
測定可能なコンテキスト評価: 長期的な精度を確保するために、堅牢な評価フレームワークで検索機能を強化しています。これにより、コンテキスト構築が、当て推量から測定可能なエンジニアリングプロセスへと変わります。そのため、チームはさまざまなコンテキスト構築戦略を定量的に検証して改善を繰り返し、エージェントに提供するコンテキストの関連性と質を継続的に最適化できます。

基盤となるデータプロダクト、高精度の検索、ガードレールを整備することで、信頼性が高い状態で高度な AI をデプロイできます。その代表的な例が、Knowledge Catalog を活用した Gemini Enterprise の Deep Research エージェント（プレビュー版）です。このエージェントは Knowledge Catalog にネイティブで対応しており、ライブのビジネスデータ、社内ドキュメント、ウェブ調査を統合し、非常に複雑な質問にも回答できます。決定論的な精度と詳細な引用を備え、これまで数週間の手作業が必要だったタスクを数分で実行します。

エージェントにビジネスにおける暗黙のルールを推測させるのはやめましょう。コンテキストを一度構築すれば、あとはエージェントに任せることができます。

Knowledge Catalog を今すぐお試しください。

- Chai Pydimukkala、プロダクトリーダー、Google Cloud

- Sam McVeety、テクニカルリーダー、Google Cloud

運用から分析へ: Spanner Graph と BigQuery Graph による統合ソリューション

Fri, 24 Apr 2026 01:00:00 +0000

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

データ内の関係性を理解することは、隠れたインサイトを発見し、インテリジェントなアプリケーションを構築するために不可欠です。しかし、運用（OLTP）と分析（OLAP）のグラフワークロードを管理するには通常、切り離されたデータベースに悪戦苦闘し、脆弱なデータパイプラインを構築し、複雑なインテグレーションを管理することになります。このような断片化により、データサイロが生まれ、運用上のオーバーヘッドが増加し、スケーラビリティが制限されます。

本日は、Spanner Graph と BigQuery Graph を活用した、グラフデータベースと分析の統合ソリューションをご紹介します。このソリューションは、デプロイ方法に関する推奨ブループリントと、代表的なユースケースのスタートガイドの 2 つの部分で構成されています。このブログ記事では、ソリューションの構成要素を確認し、最も一般的なユースケースの概要を説明します。また、実際にソリューションをデプロイしたお客様の声もご紹介します。

運用ワークロード向けの Spanner Graph

Spanner Graph は、グラフ、リレーショナル、検索、生成 AI の各機能を 1 つのデータベースに統合することで、グラフデータマネジメントを刷新します。これは Spanner の特徴である無制限のスケーラビリティ、高可用性、強整合性を基盤としています。

Spanner Graph により、以下のことが可能になります。

テーブルからグラフへの統合マッピング: 既存の Spanner リレーショナルテーブル上に直接グラフを定義し、データを複製することなく、運用データをグラフとして表示およびクエリできます。
相互運用可能なグラフクエリとリレーショナルクエリ: ISO 規格の Graph Query Language（GQL）インターフェースを活用して直感的なパターンマッチングを行い、GQL と SQL を 1 つのクエリに組み合わせてグラフデータと表形式データをまとめて走査できます。
高度な検索と AI のインテグレーション: 組み込みのベクトル検索、全文検索、Vertex AI のインテグレーションを利用して、セマンティックな意味でデータを取得し、データベース内で直接インテリジェントアプリケーションを強化します。

お客様はすでに、Spanner Graph を使用して高スループット、低レイテンシのアプリケーションを強化しており、数百万のエンティティにわたる ID 解決、広大で複雑な環境にわたる依存関係の特定、データリネージ、Customer 360 のユースケース、リアルタイムの不正行為検出の強化などに取り組んでいます。

「Open Intelligence は、クライアント、パートナー、WPP からの数兆ものライブデータポイントをプライバシー最優先で安全に接続する、当社の基盤となるインテリジェンスレイヤです。現在では、WPP のエージェント型マーケティングプラットフォームである WPP Open に統合され、支えています。Google Cloud の Spanner Graph を基盤とする Open Intelligence は、AI を活用したマーケティングにおける大きな進歩であり、BigQuery Graph で分析グラフワークロードのユースケースを拡大できることを嬉しく思います。」- WPP、データ＆インテリジェンス担当戦略責任者、Rob Marshall 氏

分析ワークロード向けの BigQuery Graph

Spanner Graph はアクティブなオペレーションを処理しますが、真に大規模な分析では、数十億のノードとエッジの関係を探索してパターンを特定し、過去のデータをクエリする必要があります。SQL でデータベースとデータウェアハウスにそれぞれ異なるツールが使用されるのと同様に、グラフでもワークロードごとに専用のツールが必要です。そこで、BigQuery Graph を構築しました。

BigQuery Graph は、接続されたデータ分析をデータウェアハウスに直接取り込みます。既存の BigQuery データをグラフスキーマにマッピングし、SQL または GQL でクエリを実行することで、データを移動することなく、膨大なデータセットに隠された関係を明らかにできます。

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

テーブルからグラフへの統合マッピング: 既存の BigQuery テーブルをグラフに即座にマッピングし、ETL パイプラインを構築することも、データを一切移動させることもなく、データウェアハウスに隠された関係を明らかにします。
相互運用可能なグラフクエリとリレーショナルクエリ: GQL の表現力豊かなパターンマッチングを大規模な過去のデータセットに適用し、SQL と GQL を 1 つのクエリに組み込んで、使い慣れたデータウェアハウスと強力なグラフ走査を組み合わせることができます。
高度な検索と AI のインテグレーション: BigQuery AI とのネイティブインテグレーションを利用して予測分析を行うとともに、組み込みのベクトル検索、全文検索、地理空間機能を使用して、数十億件のレコードにわたって接続された情報を見つけます。

統合ソリューションとしての Spanner Graph と BigQuery Graph

各プラットフォームは単体でも強力ですが、一緒にデプロイすることで真価を発揮します。運用環境と分析環境を接続することで、データサイロを排除し、データベースのパフォーマンスを損なうことなく分析情報を得るまでの時間を短縮できます。

「Spanner Graph を使用することで、Yahoo はグローバル規模で接続された基盤にデータを統合し、エージェント型広告プラットフォーム全体でリアルタイムのインテリジェントな意思決定を可能にしています。これにより、AI 主導のアプローチを強化し、最大規模のデジタル広告エコシステムを推進しています。Spanner Graph と BigQuery Graph を連携させることで、より深い分析と予測機能が可能になり、将来のイノベーションを推進できることを楽しみにしています。」- Yahoo、消費者向け収益化責任者、Gabriel DeWitt 氏

例として、金融詐欺の検出について考えてみましょう。アプリケーションは Spanner Graph を使用して不審な接続を即座に特定し、決済時にトランザクションをブロックできます。一方、BigQuery Graph はペタバイト規模の過去のトランザクションデータを分析して、詐欺行為を引き起こした複雑で長期的な詐欺組織を暴きます。

以下では、これら 2 つのエンジンを統合してエンドツーエンドのグラフワークフローを作成する方法について説明します。

1）グラフクエリとスキーマの統合エクスペリエンス

このソリューションの主な利点は、両方のプラットフォームで一貫したスキーマと GQL が共有されることです。共通の言語を使用することで、開発時間を短縮し、コンテキスト切り替えの摩擦を最小限に抑えることができます。

たとえば、特定のアカウントを起点としてつながっている可能性のある詐欺組織をリアルタイムで検出するには、次の Spanner Graph クエリを使用します。

code_block: <ListValue: [StructValue([('code', 'GRAPH FinGraph\r\nMATCH p=(:Account {id: @accountId})-[:Transfers]->{2,5}(:Account)\r\nRETURN PATH_LENGTH(p) AS path_length, TO_JSON(p) AS full_path;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97eab06a30>)])]>

同じ分析を実行して、過去の詐欺組織に関与したすべてのアカウントを特定する場合、BigQuery Graph クエリは、以下のようにほぼ同じです。

code_block: <ListValue: [StructValue([('code', 'GRAPH bigquery.FinGraph\r\nMATCH p=(:Account)-[:Transfers]->{2,5}(:Account)\r\nRETURN PATH_LENGTH(p) AS path_length, TO_JSON(p) AS full_path;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97eab06820>)])]>

2）Data Boost を使用して BigQuery Graph で Spanner データをクエリする

Data Boost を使用すると、トランザクションワークロードのパフォーマンスに影響を与えることなく、BigQuery から Spanner Graph データを直接クエリできます。これにより、データを移動することなく、Spanner のリアルタイムの運用データと BigQuery の過去の分析データを組み合わせた「仮想グラフ」を構築できます。

たとえば、Spanner Graph のリアルタイムの アカウント ノードとユーザー ノードを、BigQuery の過去のログインエッジと組み合わせて、さまざまなデバイスにわたる不審なログインパターンを特定できます。

これを行うには、まず CREATE EXTERNAL SCHEMA ステートメントを使用して BigQuery を Spanner に接続します。

code_block: <ListValue: [StructValue([('code', "CREATE EXTERNAL SCHEMA spanner\r\nOPTIONS (\r\n external_source = 'google-cloudspanner:/projects/PROJECT_ID/instances/INSTANCE/databases/DATABASE',\r\n location = 'LOCATION'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97eab06d30>)])]>

次に、Spanner と BigQuery の両方のテーブルを組み込んだ BigQuery Graph を定義します。

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE PROPERTY GRAPH bigquery.FinGraph\r\n NODE TABLES (\r\n -- Account and Person are stored in Spanner,\r\n -- made available in BigQuery through the `CREATE EXTERNAL SCHEMA` statement.\r\n spanner.Account KEY (account_id),\r\n spanner.Person KEY (person_id),\r\n -- Media is stored in BigQuery.\r\n bigquery.Media KEY (media_id)\r\n )\r\n EDGE TABLES (\r\n -- Transfers and Owns are stored in Spanner.\r\n spanner.Transfers AS Transfers\r\n KEY (transfer_id)\r\n SOURCE KEY(account_id) REFERENCES Account\r\n DESTINATION KEY(target_account_id) REFERENCES Account,\r\n spanner.Owns AS Owns\r\n KEY (person_id, account_id)\r\n SOURCE KEY(person_id) REFERENCES Person\r\n DESTINATION KEY(account_id) REFERENCES Account,\r\n -- LogIn is stored in BigQuery.\r\n bigquery.LogIn AS LogIn\r\n KEY (login_id)\r\n SOURCE KEY(media_id) REFERENCES Media\r\n DESTINATION KEY(account_id) REFERENCES Account,\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97eab063d0>)])]>

最後に、BigQuery Graph でクエリを実行して、Spanner（accounts、users、transfers、owns）と BigQuery（logins、devices）の両方のデータにアクセスし、不審なログインパターンを特定します。

code_block: <ListValue: [StructValue([('code', 'GRAPH bigquery.FinGraph\r\nMATCH p=(owner:Person)-[:Owns]->\r\n (:Account)<-[login:LogIn]-\r\n (media:Media {blocked: true})\r\nRETURN TO_JSON(p) AS full_path\r\nORDER BY login.time\r\nLIMIT 20;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97eab06190>)])]>

3）リバース ETL を使用して BigQuery データを Spanner Graph にエクスポートする

分析データを Spanner に戻して低レイテンシのリアルタイムクエリを実行する必要がある場合は、リバース ETL を使用できます。パイプラインを追加する必要はありません。たとえば、BigQuery から Spanner Graph に過去のデバイスデータ（IP アドレス、デバイス ID）をインポートして、リアルタイムの不正行為検出オペレーションを強化できます。

code_block: <ListValue: [StructValue([('code', 'EXPORT DATA\r\n OPTIONS (\r\n uri = \'https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE/databases/DATABASE\',\r\n format=\'CLOUD_SPANNER\',\r\n spanner_options="""{ "table": "Media" }"""\r\n ) AS \r\nSELECT * FROM Media;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97eab06550>)])]>

4）グラフデータを可視化する

接続されたデータの可視化は、分析、データ探索、調査の要です。Spanner Studio とBigQuery Studio（近日提供開始予定）を使用すると、使い慣れた環境から離れることも、外部ツールを設定することもなく、グラフデータを即座に可視化できます。プログラムによる詳細なデータ探索では、Spanner Graph ノートブックと BigQuery ノートブックを利用して、既存のデータサイエンスワークフロー内でクエリ結果を直接レンダリングすることもできます。

5）グラフ可視化パートナーとのインテグレーション

Spanner Graph と BigQuery Graph は、主要なグラフ可視化パートナーとも統合されており、包括的な探索ツールスイートを提供しています。

Kineviz: GraphXR を介して最先端の可視化と高度な分析を組み合わせます。
Graphistry: GPU アクセラレーションを活用したビジュアルグラフインテリジェンスプラットフォームを使用して、大規模なデータセットから重要な分析情報を抽出します。
G.V(): 高パフォーマンスの可視化とノーコードのデータ探索のための、手軽にインストールできるクライアントを提供します。
Linkurious: Linkurious Enterprise プラットフォームを介して、大量の接続されたデータ内の脅威を検出して分析します。

グラフに関するあらゆるニーズに対応する統合ソリューション

Spanner Graph と BigQuery Graph を組み合わせることで、さまざまなユースケースにわたる運用ニーズと分析ニーズに対応する統合ソリューションが実現します。

分野	Spanner Graph	BigQuery Graph
金融サービス	通常とは異なる、不審なトランザクションを即座にブロックします。	複雑で長期的な詐欺組織を検出します。
小売業、e コマース	パーソナライズされたおすすめの商品情報をその場で提案します。	膨大な購入履歴を分析して需要を予測します。
サイバーセキュリティ	アクティブな脅威を隔離し、攻撃の発生源を即座に追跡します。	過去の脆弱性をモデル化して防御を強化します。
医療	医療現場で臨床判断支援システムを強化します。	公衆衛生の傾向と病気のリスク要因を分析します。
サプライチェーン	世界中で商品を追跡し、チームに中断の発生を即座に知らせます。	システム上のボトルネックを特定し、今後のルーティングを最適化します。
通信	ネットワークのデジタルツインを作成して、異常の検出と根本原因の分析をリアルタイムで行います。	トラフィックパターンを大規模に分析して、将来のインフラストラクチャアップグレードを計画します。

Spanner Graph と BigQuery Graph を今すぐ使ってみる

Spanner Graph と BigQuery Graph を組み合わせることで、運用と分析の両方のニーズを満たす統合されたグラフデータマネジメントを実現できます。

運用ワークロード向けの Spanner Graph のユースケースと設定ガイド、分析ニーズ向けの BigQuery Graph の概要と作成ガイドをご覧ください。この組み合わせを最大限に活用する方法をご体験いただくには、統合ソリューションガイドをご覧になり、Codelab をお試しください。

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

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

エージェンティック時代を支える BigQuery の新機能

Thu, 23 Apr 2026 03:00:00 +0000

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

エージェンティック時代において成功を収めるには、データ戦略の抜本的な変革が不可欠です。それは、人間が処理できる規模から、エージェントファーストのワークロードへと移行することを意味します。また、受動的なインテリジェンスから能動的なアクションへと進化させ、生のデータをエージェントが正確に推論するためのセマンティックな知識へと昇華させなければなりません。

10 年以上にわたり、 BigQuery の継続的なイノベーションは、数万におよぶ組織がスケーラブルなデータと AI の基盤を築き、業界や技術の革新の波を乗り越えるための支援をしてきました。現在、BigQuery は自律型のデータ＆ AI プラットフォームへとさらなる進化を遂げています。 Gemini によるデータ処理量は 30 倍以上に拡大し、非構造化データを処理する AI 関数は 25 倍、さらに Model Context Protocol (MCP) を活用したエージェント構築ツールは 20 倍もの成長を記録しています。

Definity のような先進的な企業は、顧客体験の向上、バックオフィス業務の効率化、そしてデータチームの生産性向上を目指し、データプラットフォームを構築しています。

「当社は Google Cloud 上にデータプラットフォームを構築し、わずか 10 か月ですべての重要な保険データを取り込みました。これは業界平均の約半分という驚異的なスピードです。BigQuery の大規模データを極めて迅速に処理する技術は、実務担当者やエンジニアに高度なツールをもたらし、AI / ML が統合された先進的なプラットフォームを実現しています。その結果、短期間でユーザー数を 2 倍に増やすことができました」 — Definity、チーフテクノロジーオフィサー、Tatjana Lalkovic 氏

本日、 Google Cloud はレイクハウス、組み込み型 AI 処理と推論、エージェンティックな体験の 3 つの軸において、BigQuery の新機能を発表します。これらはすべて、業界をリードする価格パフォーマンスとエンタープライズ対応の信頼性へのコミットメントに基づいています。

オープンかつ境界なきクロスクラウドレイクハウスの実現

企業のデータは多くの場合、アプリケーションや複数のクラウド、オンプレミスに分散しています。初期のレイクハウスソリューションはデータの重複を削減しましたが、エージェンティック時代には、ネイティブにマルチモーダルかつクロスクラウドで、AI に最適化された基盤が求められます。 Google Cloud は、 Apache Iceberg の相互運用性と Google 独自のインフラストラクチャを融合させ、以下の新機能を提供します。

Managed Iceberg tables in Lakehouse（一般提供、旧称 BigLake）: Iceberg のオープン性に、自動テーブル管理、Iceberg パーティショニング、マルチテーブル・トランザクション、CDC（変更データキャプチャ）、高度なベクトル化、履歴ベースの最適化といった BigQuery の高度な機能を融合させます。
Iceberg REST Catalog: BigQuery、Spark、その他 OSS やサードパーティエンジン間において、Iceberg テーブルの読み書きの相互運用性（プレビュー）を実現します。これにより、複雑なエンジンに伴う複雑なトレードオフに悩まされることはありません。
Cross-cloud Lakehouse（プレビュー）: BigQuery の AI と分析機能を、AWS や Azure をはじめとする他のクラウドへ拡張します。Iceberg REST Catalog などのオープンスタンダード、 Cross-Cloud Interconnect による広帯域ネットワーク、透過的なキャッシュ技術を活用することで、他社ネイティブのデータウェアハウスと同等のパフォーマンスと TCO（総保有コスト）を実現。真のクロスクラウド体験を提供します。
カタログフェデレーション（プレビュー）: AWS Glue、Databricks、SAP、Salesforce、Snowflake、Confluent Tableflow（年内公開予定）にわたるデータの探索、分析、ゼロコピー共有を容易にします。
リアルタイムデータレプリケーション：Spanner 、AlloyDB 、Cloud SQL から BigQuery テーブル（一般提供）および Iceberg（プレビュー）へデータを即座に複製可能にすることで、ローデータの取り込みからビジネスアクションまでのサイクルを迅速化します。

SQL または自然言語を使用して、BigQuery と AWS 上の Iceberg テーブルにまたがるデータを分析

レイクハウスに関する最新のイノベーションの詳細はこちらをご参照ください。

エンタープライズエージェントのためのグラフベースの推論

AI が複雑で多段階の運用課題を解決するには、ビジネスロジックがデータプラットフォーム層まで深く浸透している必要があります。このレイヤーでロジックを定義することで、データの取り込みから消費に至るまで、定義の一貫性とガバナンスが担保されます。BigQuery Graph（プレビュー）は、こうしたコンテキストを活性化させる基盤を提供し、データ実務者がエンティティ、リレーションシップ、およびビジネスロジックをデータプラットフォーム内に直接マッピングできるようにします。これにより、 AI エージェントを統制された現実に即した形で定着させ、高度な課題を大規模かつ一貫した精度で解決できるようになります。

AI 推論を強化する新しいグラフ機能を発表します。

BigQuery Graph における指標（メジャー）のネイティブサポート（プレビュー）: 分析指標（メジャー）とデータ間のリレーションシップを、統制された一つのエンティティとして統合できます。これにより、データを「ビジネスマップ」へと変換し、マルチホップな構造的推論を可能にします。エージェントは単なる検索を超えて、あるビジネスイベントが他にどのような波及効果（リップルエフェクト）をもたらすかまでを追跡できるようになります。
BigQuery Conversational Analytics におけるグラフサポート（プレビュー）: 対話型分析エージェントが生のテーブルではなく、確定的なビジネスマップを参照することで、回答精度が飛躍的に向上します。エージェントは指標を用いて正確な KPI を即座に算出すると同時に、複雑な関係性をたどって数値の背景にある理由を明らかにできます。
BigQuery Graph と Looker の統合（プレビュー）: グラフを Looker ビューとして公開することで、BigQuery で定義した指標をデータスタック全体で再利用できます。また、ソース管理と検証機能を備えた Looker を使用して BigQuery Graph を定義することも可能です。この相互運用性により、解約率などの重要指標がダッシュボードと AI エージェントの両方で一致することを保証します。
BigQuery Studio におけるビジュアルモデリング体験（プレビュー）: エージェントのコンテキストを支えるエンティティ、リレーションシップ、ビジネスロジックを直感的に構築および管理できるインターフェースを提供します。

BigQuery Graph を活用した Conversational Analytics Agents による、自然言語でのデータ分析

構造化、非構造化データの価値を引き出すネイティブな AI 処理

データはもはや行と列に限定されません。エージェントが求めているのは、データのコピーや移動を強いることなく、構造化データと非構造化データの双方を大規模に処理できるプラットフォームです。BigQuery AI は、 170 以上の基盤モデルへの組み込みアクセスにより、予測 ML タスク（需要予測、異常検知、レコメンデーションなど）や生成 AI タスク（画像やテキストからのエンティティ抽出、コンテンツ生成、データ拡張など）を容易に実行します。

AI.PARSE_DOCUMENT（プレビュー）: OCR（光学文字認識）、レイアウト解析、チャンク分割を自動化する単一の SQL 関数により、複雑なドキュメント処理ワークフローを簡素化します。
TabularFM モデル（プレビュー）: 大規模な特徴量選択、チューニング、トレーニング、モデル管理を必要とせず、高品質な回帰および分類機能を BigQuery にもたらします。
ObjectRef（一般提供）: SQL および Python を使用して、構造化データとともに非構造化データを処理できます。これにより、ナレッジカタログ上に直接、リッチでマルチモーダルなコンテキストを構築する基盤が整います。
最適化モード（プレビュー）: AI.CLASSIFY や AI.IF などの SQL 優先の AI 共同処理マネージド関数において、タスク固有のモデルをオンザフライでトレーニングし、従来の生成 AI の行単位の処理と比較して、トークン消費量を 230 分の 1 に削減します。
BigQuery ネイティブの Gemma エンベディング（プレビュー）: 標準的な CPU 上で高品質なエンベディングを大規模に生成できます。
自律的なエンベディング生成（一般提供）: 非構造化データのパイプラインをフルマネージド化し、新しいデータが取り込まれる度にベクトルインデックスを自動的に同期します。
BigQuery ハイブリッド検索（プレビュー）: セマンティック検索と全文検索を単一の関数に統合し、 RAG や複雑な探索において極めて高い精度を実現します。
Python UDF（一般提供）: フルマネージドな Python スカラー関数により、データの拡張、変換、クリーニングが可能になります。独自のコードやライブラリを持ち込むことができ、サーバーレスな実行環境によって数百万行規模まで自動スケールします（今後数週間にわたって段階的に展開予定）。
Connected Sheets: BigQuery のスケールを Google スプレッドシート上で利用可能にします。新たに TimesFM モデルによる予測（一般提供）と異常検知（プレビュー）に対応しています。
地理空間分析データセット（プレビュー）: インフラ資産や道路管理のインサイトなどの地理空間データに BigQuery から直接アクセス可能になりました。複雑なデータ加工なしに、エンタープライズデータと組み合わせて深い分析が行えます。

BigQuery における非構造化データへのアクセス、処理および活用

エージェンティックな体験

AI は、定型的で時間のかかるタスクを肩代わりすることで、高度なスキルを持つデータチームがインパクトの大きい戦略的イニシアチブに集中できる環境を整えます。 Google Cloud は、 Google の基盤研究、高性能なモデル、専用ツールを BigQuery に直接統合し、データライフサイクルのあらゆる段階で自動化と支援を提供します。

Conversational Analytics in BigQuery（一般提供）: 自然言語を用いて複雑なデータセットへのクエリが可能になります。安全かつ透明性の高い形でインサイトを得られるだけでなく、予測分析や構造化および非構造化データを横断した推論もサポートします。BigQuery Studio に加え、 Data Studio（プレビュー）、 Gemini Enterprise（プレビュー）、またはカスタムアプリケーション用 API（一般提供）から利用可能です。

Conversational Analytics in BigQuery により、自然言語を用いてデータからインサイトを取得

プロアクティブなエージェンティックワークフロー（プレビュー）: 単なる質問への回答を超えて、指標の変化を検知し、根本原因分析を行って理由を説明し、定期的な調査レポートをメールで直接配信します。

BigQuery におけるプロアクティブなエージェントワークフロー

BigQuery Agent Analytics: ADK（一般提供）および LangGraph（プレビュー）フレームワーク用のプラグインを提供し、エージェントのアクティビティを BigQuery に記録して、トラブルシューティング、最適化、評価に役立てることができます。
BigQuery Studio: リソース探索やトラブルシューティングをサポートするコンテキスト認識型アシスタント（プレビュー）をはじめ、SQL と DataFrames を統合する SQL Cells（一般提供）、ノートブック内で直接ビジュアルを作成する Visualization Cells（一般提供）など、新しい生産性向上のためのツールを追加しました。Files Explorer（一般提供）により、開発者はフォルダ形式でコード資産を整理、共有、管理することが可能になります。さらに、 BigQuery Notebooks における Git 連携とワークフロー（プレビュー）を導入し、データサイエンスのワークフローにおいて GitHub、GitLab、Bitbucket、Azure DevOps を網羅する包括的な SCM カバレッジを提供します。
Data Science Agent（一般提供）: BigQuery ノートブックにおいて、目標を自然言語で入力するだけで、 BigQuery ML 、 DataFrames 、または Spark を使用したデータのロード、クリーニング、視覚化の計画を自動実行します。
Colab Data Apps（プレビュー）: ノートブックでの分析を、共有可能なフルマネージドのインタラクティブ Python アプリケーションに変換します。
BigQuery remote MCP server（一般提供）および BigQuery ADK toolset（一般提供）は、エージェントのための手動によるデータベースコネクタ作成の手間を大幅に軽減します。
Google Cloud Data Agent Kit（プレビュー）: 環境を問わず利用可能な一連のスキル、 Model Context Protocol（MCP）ツール、環境固有の拡張機能、およびネイティブプラグインを統合したスイートを提供します。VS Code、Gemini CLI、Codex、Claude Code など、開発者が普段利用している環境に寄り添うことで、Data Agent Kit は IDE、ノートブック、あるいはターミナルをネイティブなデータ環境へと変貌させます。これにより、使用している環境から広範なデータワークフローのオーケストレーションが可能になり、BigQuery、dbt、Apache Spark、Apache Airflow などの適切なフレームワークを自動的に選択して、本番環境に対応したコードを生成します。

圧倒的なパフォーマンスとスケール

現代の分析ワークロードは予測が難しく、分散化が進んでいます。Google Cloud は、データの増大がコストや運用のオーバーヘッドに直結しないよう、BigQuery のコアエンジンの強化に投資を続けています。

Fluid scaling（一般提供）: コストとパフォーマンスをトレードオフを必要としない、高度なオートスケーリングモデルです。変動の激しいワークロードでも秒単位の課金を実現し、最大 34% のコスト削減を可能にします。
高度なランタイム、小規模クエリ、履歴ベースの最適化（一般提供）: コードやスキーマの変更なしに、ネイティブおよび Iceberg ワークロードを加速させます。BigQuery は、クエリ処理コストを前年比で 40% 削減しつつ、クエリ速度を 35% 向上させました。
新しいワークロード管理機能: 予約グループ（一般提供）、柔軟な動的割り当て（プレビュー）などにより、詳細なコスト配分と価格パフォーマンスの制御を簡素化します。
可観測性の向上（一般提供）: ミッションクリティカルなワークロードに対して柔軟なディザスタリカバリ機能を提供します。エージェントによる可観測性（プレビュー）やセキュリティセンター（プレビュー）により、運用とアクセス制御をさらに簡素化します。

予測困難なワークロードに対応する BigQuery の Fluid scaling

エージェンティック時代において、 BigQuery は単にデータが存在する場所ではありません。データが考え、推論し、行動するための場所です。よりオープンで自律的、そしてパワフルなデータの未来が今ここにあります。

BigQuery へのデータ移行特典を活用して、データと AI ジャーニーを今すぐ始めましょう。皆様のイノベーションの成果を伺えることを楽しみにしています。

BigQuery Graph と Kineviz GraphXR で企業ナレッジの非構造化データを拡張

Wed, 22 Apr 2026 02:20:00 +0000

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

企業データの 80% 以上は、PDF、メール、レポート、規制関連の提出書類など、非構造化形式で存在しています。このようなソースには重要なビジネス情報が含まれていることが多いにもかかわらず、大規模なアクセスや推論は困難です。BigQuery Graph と Kineviz GraphXR を組み合わせることで、意思決定者は単一の合理化されたワークフローを作成して非構造化データを管理し、隠れたビジネスインサイトをはるかに簡単に発見できるようになります。BigQuery がグラフ構造の保持と構築を担い、Kineviz GraphXR がアナリストによる関係性の視覚的検証、分析情報の根拠の追跡、そして対話的な質問への回答を可能にします。

検索拡張生成（RAG）とベクトル検索は、非構造化データを扱うための業界標準のアプローチとなりました。しかし、トレンド分析、エンティティ間の比較、マルチホップ推論、説明可能な意思決定支援においては、グラフが RAG を補完し、コンテキストと関係性をマッピングする役割を果たします。Google の「エビデンスファースト」のナレッジグラフアプローチでは、元のエビデンスのニュアンスを維持し、グラフ内のあらゆる要素のトレーサビリティを確保することを優先しているため、分析結果の検証可能性と信頼性が高まります。この投稿では、BigQuery AI 関数、BigQuery Graph、Kineviz GraphXR を使用して、複雑な ETL パイプライン、データの重複、個別のグラフデータベースなしで、Fortune 500 企業の SEC 提出書類に関するビジネス上の質問に回答する例を紹介します。

BigQuery で、断片化されたデータを統合

従来の非構造化分析パイプラインは、複雑で散漫になりがちでした。通常は、未加工ファイルのオブジェクトストレージ、カスタム解析サービス、個別の AI 抽出レイヤ、スタンドアロンのグラフデータベース、そして分析用の BI ツールなど、複数のステップを要します。この複雑な設定は、データの重複、同期のオーバーヘッド、複数の潜在的な障害点の導入を伴うため、維持が困難になる可能性があります。

BigQuery はこのプロセスを合理化します。未加工のドキュメントは Google Cloud Storage に保存され、テキスト抽出、Gemini を活用した推論、グラフ作成はすべて同じプラットフォーム内で直接行われます。これにより、システム間のデータ移動、複雑なサービスオーケストレーション、同期されていないデータコピーの蓄積が不要になります。

緊密なインテグレーションにより、パイプラインはシンプルで保守しやすく、専用のインフラストラクチャがなくてもデータの完全な来歴を確認できます。

BigQuery パイプライン: 非構造化データから構造化データへ

BigQuery パイプラインを使用して、2020 年から 2024 年までの Fortune 500 企業の SEC 10-K 提出書類を調査しました。各提出書類は、約 100 ページに及ぶ詳細な内容です。

各 Company（企業）が Competitors（競合他社）（COMPETES_WITH）、Risks（リスク）（FACES_RISK）、Markets（市場）（ENTERING / EXITING / EXPANDING）に接続するスキーマを設計し、次の 4 つのステップでプロセスを進めました。

1. 取り込んで解析する。SEC EDGAR から 10-K 提出書類を取得し、階層構造を維持しながら SGML（Standard Generalized Markdown Language）を Markdown に変換して、Cloud Storage 経由で未加工のテキストを BigQuery に読み込みます。

2. 重要なシグナルセクションに注目する。100 ページに及ぶ提出書類全体を処理するのではなく、市場の動向、リスク、競合他社に関連するセクション（具体的には、事業、リスク要因、経営陣の議論と分析のセクション）にのみ抽出を集中させます。BigQuery の各行には、年度、企業名、CIK、セクション ID、原本の提出書類への直接 URL など、重要なメタデータが保持されています。

3. Gemini を使用して抽出する。Gemini 3 Pro で AI.GENERATE_TEXT() を利用して、各セクションを処理し、構造化された JSON を返します。この出力には、競合他社、リスク、市場の動向、機会に関する詳細が記載され、すべての要素は最初の提出書類のエビデンステキストによってグラウンディングされています。このプロセスは、外部のオーケストレーションやデータ移動を必要とせず、BigQuery 内で完結します。

4. グラフを宣言する。 構造化された JSON データは、ノード用とエッジ用の個別のテーブルに分割されます。これらのテーブルは、以下に示すように、1 つのデータ定義言語（DDL）ステートメントを使用して完全に走査可能なグラフにマッピングされ、結合を必要とせずにグラフクエリを可能にします。

code_block: <ListValue: [StructValue([('code', 'CREATE PROPERTY GRAPH sec_filings.SecGraph\r\n NODE TABLES (\r\n nodes_company, nodes_competitor, nodes_risk, nodes_market, nodes_opportunity\r\n )\r\n EDGE TABLES (\r\n edges_competes SOURCE nodes_company DESTINATION nodes_competitor LABEL COMPETES_WITH,\r\n edges_faces_risk SOURCE nodes_company DESTINATION nodes_risk LABEL FACES_RISK,\r\n edges_entering SOURCE nodes_company DESTINATION nodes_market LABEL ENTERING\r\n -- plus EXITING, EXPANDING, PURSUING\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97f428b730>)])]>

このプロセスにより、87,000 個のエンティティと 20,000 件以上の競合他社に関する言及が抽出されました。解決と正規化の後、これらの言及は約 8,100 の個別の競合他社に統合され、非構造化データの SEC 提出書類が、競争環境を示すナレッジグラフに変換されました。

Kineviz GraphXR で隠れた分析情報を引き出す

Kineviz の GraphXR は BigQuery Graph に直接接続し、アナリストがデータをインタラクティブに探索、分析できる環境を提供します。アナリストは、クエリを記述することなく、ローコードワークフローを通じて関係を視覚的にナビゲートし、サブグラフをドリルダウンできます。これは、戦略、コンプライアンス、調査の各チームがデータに直接アクセスして、分析を独自に改善できることを意味します。

GraphXR の AI を活用したワークフローにより、ユーザーは「Apple の競合他社との比較を時系列で表示して」などの自然言語を使用して分析タスクを定義し、ライブグラフビューにリンクされたダッシュボードを生成できます。グラフビューが変更されると、ダッシュボードのグラフが動的に更新されます。たとえば、SEC 提出書類から抽出された構造化データポイントを見ると、Apple を競合他社として挙げた企業の数は、時間の経過とともに 14 社前後で比較的安定していることがわかります。このパターンは個々の提出書類を調査するだけでは明らかになりません。

ダッシュボード: Apple について言及した企業（時系列）

AI を活用したビジュアル分析エージェントは、これらの評価の精度とニュアンスを向上させます。たとえば、GraphXR の「trace neighbor」機能を使用して、Google を競合他社として挙げている企業を特定した後、エージェントの分析により、業界をまたがる複雑な関係が明らかになります。その代表的な例が、エネルギー公益事業会社の AES Corp. です。同社は、競合と協調が入り混じった関係を示す文脈で登場しており、これはクラウドや AI インフラストラクチャの導入に向けた、より広範な市場の変化を浮き彫りにしています。

グラフ構造とノードプロパティの両方について、エージェントの理由を添えて競合分析を行う

私たちのワークフローは、監査可能性に重点を置いています。グラフ内のすべてのノードは、元の SEC 提出書類内のソースに直接リンクされています。アナリストは分析情報をその起源までたどって、コンテキスト内で調査結果を検証できます。たとえば、下の画像では、リスクエンティティを選択すると、そのリスクが特定されたドキュメントの関連する場所に読者を誘導する URL リンクが提供されます。

リスク分析。ソースドキュメント内の抽出された情報の正確な場所への直接リンクをクリックできます。

メリット

BigQuery Graph と Kineviz GraphXR を組み合わせることで、組織は次のことが可能になります。

シンプルさ: システムとコピーの削減 - パイプラインはフルマネージドの統一プラットフォームで実行され、BigQuery に保存されたデータは、データの移動や重複なしに GraphXR で探索、分析されます。
スケーラビリティ: BigQuery は、専用のグラフインフラストラクチャなしで、数百万のドキュメントと数十億の抽出されたファクトを処理します。
説明可能性: すべての分析情報が情報源のエビデンスに遡ることができ、検証はワンクリックで完了します。
柔軟性: 新しい質問やエンティティタイプによって抽出モデルを再構築する必要はなく、スキーマを拡張するだけで済みます。

企業ナレッジの大半は閉じ込められたままです。BigQuery AI 関数、BigQuery Graph、Kineviz の BI ツールを組み合わせることで、グラフベースの推論、エビデンスファーストの分析、インタラクティブな探索を、単一の合理化されたパイプラインに変え、非構造化データに閉じ込められたインテリジェンスを引き出すエンドツーエンドのソリューションが提供されます。

始める

BigQuery Graph の詳細についてはこちらを、ご利用を開始する場合はこちらをご覧ください。Kineviz GraphXR は Google Cloud Marketplace で入手できます。Fortune 500 企業のチュートリアルは、GitHub ノートブックで確認するか、こちらの動画をご覧ください。

BigQuery Graph のご紹介: データに潜む関係性を明らかに

Tue, 21 Apr 2026 02:00:00 +0000

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

このたび、BigQuery Graph のプレビュー版の提供を開始しました。BigQuery Graph は、データエンジニア、データアナリスト、データサイエンティスト、AI デベロッパーが、大規模な関係性をこれまでにない形でモデル化、分析、可視化できるようにする、使いやすく高いスケーラビリティを備えたグラフ分析ソリューションです。

データが変化し、増え続ける中で、人、場所、商品といったさまざまなエンティティが互いにどのようにつながっているのかを把握することはますます重要になっています。結局のところ、エンティティどうしのつながりがわかってこそ、データはより大きな意味を持ちます。従来の SQL では、「友だちの友だちの友だち」を見つけるだけでも、複数の JOIN を入れ子にした処理が必要になり、記述も読解も難しくなりがちです。しかも、規模が大きくなるにつれて、パフォーマンスは急激に低下します。たとえば、嵐によるサプライチェーンの混乱がどこまで影響するのかという「影響範囲」を特定するには、複数ホップにまたがる探索、すなわち本格的なグラフ分析が必要です。こうした課題により適切に対応するため、データはしばしば、私たちを取り巻く現実世界をグラフとして表現する形でモデル化されます。こうした表現は、従来のリレーショナルデータ構造よりも、複雑で見えにくい関係性を見つけ出すのに適しています。

業界を問わず企業が直面するグラフ導入の課題

グラフ技術は、不正検知、レコメンデーションエンジン、サプライチェーン管理、ナレッジグラフアプリケーションなど、さまざまな業界で幅広く活用されています。しかし、グラフを導入するにあたっては、いくつかの大きな課題があります。

データサイロと運用負荷の増大: グラフデータをスタンドアロンのグラフデータベースに保存して管理する必要があるため、データサイロやデータの不整合、追加コストが生じるだけでなく、運用負荷も増大します。
グラフに関する専門知識の不足: グラフ技術を導入するには、新しい言語や考え方、場合によっては新しいデータベースも習得しなければなりません。その一方で、これまで組織が積み上げてきた SQL の知識やスキルを十分に生かしにくいという課題もあります。
パフォーマンスとスケーラビリティへの懸念: 多くのスタンドアロングラフデータベースは、少数のノードを起点としたグラフ走査には適していますが、ビジネスの成長に伴って数十億規模のエンティティまで拡張するのは難しい場合があります。

BigQuery Graph は、次の機能によって、こうした課題の多くに対応します。

組み込みのグラフクエリ機能: より直感的なグラフクエリ言語（GQL）により、最新の ISO GQL 標準に基づいて、異なるデータセット間のパターンを見つけたり、関係をたどったりできます。
リレーショナルデータモデルとグラフデータモデルの統合: グラフデータモデルとリレーショナルデータモデルが緊密に統合されているため、データの重複や移動を行うことなく、単一の信頼できるデータソースをもとに、最適な方法でデータをモデル化できます。さらに、グラフクエリと SQL は完全に相互運用できるため、既存の SQL スキルを生かしながら、グラフクエリの高い表現力も活用できます。
構造化データと非構造化データをまたぐグラフ分析: BigQuery Graph では、豊富な AI 関数に加え、ベクトル検索や全文検索も利用できます。これにより、グラフ上で意味ベースの検索やキーワード検索を行うことができ、構造化データと非構造化データの間を橋渡しできます。
グラフの可視化: BigQuery Studio ノートブックや Jupyter Notebook を使って、データどうしのつながりを直感的なグラフ形式で簡単に探索、調査、説明できます。
業界最高水準の使いやすさ、パフォーマンス、スケーラビリティ: BigQuery Graph は、BigQuery のサーバーレスでスケーラブルかつ費用対効果に優れた分散分析エンジンを基盤として構築されており、数十億規模のノードやエッジにも対応できます。
Spanner Graph とのインテグレーション: これにより、リアルタイムのグラフニーズには Spanner Graph、バッチのグラフニーズには BigQuery Graph という形で、両方をカバーする統一的なグラフスキーマとグラフクエリ言語を利用できます。さらに、連携クエリを使えば、データを移動することなく、Spanner の最新データと BigQuery の履歴データを組み合わせた仮想グラフを構築することもできます。
グラフとの対話: まもなく会話型分析エージェントを使用することで、グラフに直接話しかけるような操作が可能になります（続報をお待ちください）。

BigQuery Graph の主なユースケース

BigQuery Graph は、インテリジェントなアプリケーションを構築するうえで、業界を問わず幅広い可能性をもたらします。

金融詐欺行為の検出: ユーザー、アカウント、トランザクションの間の複雑な関係を分析して、資金洗浄やエンティティ間の異常な接続など、リレーショナルデータベースでは検出が困難な疑わしいパターンや異常を特定します。
Customer 360: 顧客との関係、嗜好、購入履歴を追跡します。各お客様を包括的に把握し、パーソナライズされたおすすめ情報、ターゲットを絞ったマーケティングキャンペーン、カスタマーサービスの利用体験の向上を実現します。
ソーシャルネットワーク: ユーザーのアクティビティとインタラクションをキャプチャし、友だちのおすすめ情報やコンテンツの検出のためにグラフパターンマッチングを使用します。
製造とサプライチェーン管理: グラフパターンを使用して、グラフにパーツ、サプライヤー、注文、在庫状況、欠陥をモデル化し、欠品分析、費用のロールアップ、コンプライアンスチェックを効率的に実施します。
ヘルスケア: 患者の関係性、病状、診断、治療に関する情報を捉え、患者の類似性分析や治療計画の立案に役立てます。
輸送の最適化: グラフで場所、乗り継ぎ、距離、費用をモデル化し、グラフクエリを使用して最適なルートを検索します。

実際の BigQuery Graph の活用事例

さまざまな業界のお客様が、BigQuery Graph を活用して現実のビジネス課題を解決しています。ここでは、その活用例をいくつかご紹介します。

BioCorteX: 創薬

「疾患を理解するということは、単にデータを増やすことではなく、そのデータの中にある関係性を理解することです。BigQuery Graph の経路検索を大規模に活用し、7 ホップを超える深さまで到達できるようになったことで、私たちはついにヒト代謝マップをこれまで以上に見渡せるようになりました。この規模だからこそ、試行錯誤を超えて、複雑な疾患を治療するために働きかけるべき正確な生物学的レバーを特定できます。もはや推測しているのではありません。計算機の速度で生命を再現しようとしているのです。」- BioCorteX、CEO / 共同創業者、Nik Sharma 氏

Curve: 不正検知

「BigQuery Graph を導入したことで、これまでの制約の多い SQL ベースのアプローチから脱却し、不正検知ネットワーク分析のための、よりスケーラブルなソリューションへ移行することができました。これにより、一見無関係に見えるアカウントや取引の間に潜むつながりを明らかにし、高度な不正ネットワークを検出できるようになりました。従来のリレーショナルクエリからグラフベースの分析へ移行したことで、約 910 万ポンドの削減という、測定可能な事業インパクトも得られました。この転換は、不正検知の精度を高めただけでなく、運用負荷を大きく増やすことなく、エコシステムを保護するためのスケーラブルな基盤も提供してくれました。」- Curve、データおよび ML 担当 VP、Francis Darby 氏

Virgin Media O2: 不正検知

「Virgin Media O2 では、ますます巧妙化する不正ネットワークの先を行くために、防御策を絶えず進化させています。すでに堅牢な不正アラートシステムに、新たな強力なレイヤを追加しました。BigQuery Graph を使うことで、アカウント、デバイス、アクティビティの間にある隠れた関係性を可視化する複雑な 4 ホップクエリを実行できるようになりました。この可視性の向上によって、不審な住所のネットワークを特定できるようになりました。これは単に不正を検知するだけではありません。既知のリスクネットワークへの新たな接続を被害が発生する前に検知する早期警戒システムとしても機能します。」- Virgin Media O2、データアプリケーション担当ディレクター、Jonathan Ford 氏

BigQuery Graph の使い方

BigQuery Graph は単なる新機能ではありません。データに対する新しい考え方をもたらし、より大きな問いを立て、より深いインサイトを引き出し、最も難しい課題の解決を可能にします。

次の 3 つの簡単なステップで利用を開始できます。

ステップ 1: 単一コピーのデータをもとに、DDL を使って関係テーブル上にグラフスキーマを作成します。

リレーショナルテーブルを「Account」「Person」「Loan」の各ノードに対応付け、それらの関係を「Transfers」「Owns」「Repays」の各エッジとして定義することで、金融グラフを作成します。

code_block: <ListValue: [StructValue([('code', 'CREATE PROPERTY GRAPH graph_db.FinGraph\r\nNODE TABLES (\r\n graph_db.Account KEY(id),\r\n graph_db.Person KEY(id),\r\n graph_db.Loan KEY(id)\r\n) \r\nEDGE TABLES (\r\n graph_db.Transfers \r\n KEY (id, to_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Account (id)\r\n DESTINATION KEY (to_id) REFERENCES Account (id), \r\n graph_db.Owns\r\n KEY (id, account_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Person (id)\r\n DESTINATION KEY (account_id) REFERENCES Account(id),\r\n graph_db.Repays\r\n KEY (id, loan_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Person (id)\r\n DESTINATION KEY (loan_id) REFERENCES Loan(id)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97f40b4c40>)])]>

ステップ 2: 直感的な SQL / GQL を使ってデータ間の関係をたどり、隠れたつながりを見つけます。

Jacob が所有する口座と、その口座から返済しているローンを見つけます。

code_block: <ListValue: [StructValue([('code', 'GRAPH graph_db.FinGraph\r\nMATCH\r\n (person:Person {name: "Jacob"}) \r\n -[own:Owns]->(account:Account)\r\n -[repay:Repays]->(loan:Loan)\r\nRETURN\r\n account.id AS account_id,\r\n loan.id AS loan_id'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97f40b4910>)])]>

ベクトル検索とグラフトラバーサルを組み合わせて、詐欺師に類似した口座と、その口座に関する送金アクティビティを 1～6 ホップの範囲で見つけます。

code_block: <ListValue: [StructValue([('code', "DECLARE similar_account_to_fraudster DEFAULT ((\r\n SELECT array_agg(base.id)\r\n FROM VECTOR_SEARCH(TABLE graph_db.Account, 'embedding',\r\n (SELECT * FROM graph_db.Account WHERE id=102), 'embedding', \r\n top_k => 6)\r\n));\r\nGRAPH graph_db.FinGraph\r\nMATCH\r\n (person:Person)-[own:Owns]->\r\n (account:Account)-[transfer:Transfers]->{1,6}\r\n (to_account:Account)\r\nWHERE to_account.id IN \r\n UNNEST(similar_account_to_fraudster)\r\nRETURN\r\n person.id AS person_id,\r\n account.id AS src_account,\r\n to_account.id AS to_account"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f97f40b4f40>)])]>

ステップ 3: BigQuery Studio ノートブックでグラフの結果を可視化し、異なるデータどうしのつながりを、より直感的に把握します。

より専門的なグラフ可視化ツールをお探しの場合は、BigQuery Graph は G.V()、Graphistry、Kineviz、Linkurious などの業界をリードするパートナーと統合されています。これらのツールを使えば、Google Cloud コンソールの外でも、BigQuery Graph のクエリ結果を可視化できます。

準備ができたら

データ分析の未来は、つながりの理解にあります。BigQuery Graph を使えば、そのつながりを解き明かし、企業のナレッジに根ざした実用的なインサイトへと変えることができます。今すぐ使い始めて、相互に結び付いたデータの力を引き出しましょう。

BigQuery のドキュメントを見る: 概要とクイックスタートガイドをご覧ください。
チュートリアルを試す: チュートリアルを通じて、BigQuery Graph を実際に体験できます。
フィードバックを共有する: コミュニティに参加し、bq-graph-preview-support@google.com で質問できます。
関連ブログ記事:

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

- BigQuery、プロダクトマネジメント担当ディレクター、Vinay Balasubramaniam

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TVer: 日本最大級の動画配信プラットフォームを支える広告基盤を Google Cloud で内製化

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

民放公式テレビ配信サービス「TVer」は、2025 年に10 周年を迎え、月間再生 6.5 億回、累計 9,000 万 DL 超の巨大プラットフォームへ成長しました。同社はこの成長を支えるべく広告サーバーの内製化を決断。GKE や Bigtable を活用し、1日あたり億単位のリクエストを低遅延で処理する新基盤を構築しました。株式会社 TVer（以下、TVer）大野祐輔氏と髙品純大氏に、内製化の舞台裏と Google Cloud 選定理由を伺いました。

利用しているサービス:
GKE Standard, Bigtable, Memorystore for Redis Cluster, BigQuery, Cloud Logging など

利用しているサービス:
Google Cloud Consulting (PSO)

事業成長を加速させるため、ビジネスの心臓部である広告サーバーの内製化を決断

TVer の広告事業は、サービスの利用者数増加に伴い、非常に大きな規模へと拡大しています。これまで広告配信は外部の配信プラットフォームを利用してきましたが、さらなる機能開発のスピードアップと、配信技術に関する知見を社内に蓄積するため、独自の広告サーバーを構築するフェーズに移行しました。内製化を決断した理由について広告プロダクト本部長の大野氏は、こう説明します。

「TVer にとって広告配信システムは、まさにビジネスの心臓部とも言える重要な事業基盤です。これを内製化することで、新しい広告フォーマット、新機能への挑戦やデリバリー速度の改善といった一連の作業を、従来よりも高速に回せると考えました」

今回のプロジェクトにおける最優先事項は、ビジネスクリティカルなシステムに相応しい「高い可用性」「低レイテンシなパフォーマンス」「スケーラビリティ」の 3 点でした。1 日に数億件という膨大な広告リクエストを遅滞なく処理し、トラフィックが急増しても事業成長を阻害しない強固なインフラが求められたのです。

TVer が Google Cloud を選んだ最大の理由について、システム開発を担当しているプロダクト開発部の髙品氏は、「データの取り回しの良さとコスト効率」が最も重要だったと説明します。

「内製化以前から、広告ログの分析・集計基盤は BigQuery で構築していました。もし広告配信基盤を他のクラウドに構築した場合、毎日発生する億単位の広告ログをクラウド間で転送する必要があり、膨大なアウトバウンドコストが発生します。また、事業価値の高いデータを転送時のトラブルで失うリスクも避けたいと考えました。BigQuery という強力なデータ基盤と同じ場所に配信サーバーを置くことが、コストとリスクの両面で最適だったのです。

また、開発言語として Go を採用したいという現場のニーズと、Google Cloud との親和性の高さも、エンジニアチームにとって大きな後押しとなりました。」

GKE と、Memorystore、Bigtable の適材適所な併用。技術的難題を突破した PSO の支援

構築された新システムは、GKE Standard をコンピューティング基盤とし、データベースには要件に応じて Memorystore for Redis Cluster（以下 MRC）と Bigtable を使い分ける構成を採用しました。

髙品氏は、データベースの選定理由について次のように解説します。

「広告配信 API に求められるミリ秒単位のレイテンシを実現するため、リレーショナルデータベースではなく NoSQL を選択しました。データの整合性が重要で、超高速なレスポンスが必要なものは MRC、ストレージの容量とコスト効率を重視するものは Bigtable と、戦略的に併用しています。GKE Standard を採用したのも、秒間数十万リクエストが集中するリアルタイム配信に耐えうるキャパシティを事前に確保できる柔軟性を評価したからです。」

この複雑なアーキテクチャの実装と、本番環境の広告配信を止めずに新基盤へ移行するという難易度の高いミッションを支えたのが、Google Cloud のプロフェッショナルサービス（PSO）でした。PSO の役割の重要性を大野氏はこう振り返ります。

「PSO の支援がなければ、予定通りのローンチは不可能だったでしょう。インフラの設定にとどまらず、アプリケーションのアルゴリズムやデータ構造にまで深く踏み込んだレビューをいただいたことが、厳しい負荷試験をクリアする決定打となりました。コードレベルの改善案を迅速に提示いただけるなど、その専門性の高さとスピード感に非常に感謝しています。」

安定と革新を両立した配信基盤を武器に、さらなる視聴体験の向上を目指す

新サーバーへの移行によって、TVer の広告事業は「自分たちでコントロールできる」自由を手に入れました。現在は、システムの信頼性やパフォーマンスを損なうことがないように細心の注意を払って機能をリリースしつつも、守りに徹するだけではなく、 Google Cloud のアップデートを積極的に検証しています。

「最新世代マシンへの刷新に加え、Bigtable の継続的マテリアライズドビューによる集計効率化、さらには Memorystore for Valkey への移行など、最新技術を積極的に取り入れ、より強固な配信基盤を目指していきたいと考えています。」と髙品氏は今後の展望を明かします。

最後に大野氏は、このプロジェクトを振り返り、次のように締めくくりました。

「今回のプロジェクトを通じて、Google のサービスを支える信頼性とスケーラビリティを備えた技術を組織の資産にできたことは大きな収穫です。パブリッククラウドの選択肢が増え、相対化できるようになったことで、今後の大規模プロダクト開発に活かせる自信がつきました。TVer 広告は、これからもテクノロジーの力で、ユーザーに素晴らしい視聴体験を提供し続けていきます。そしてこのような最新でエキサイティングな業務を一緒に取り組める仲間も大募集中です。」

株式会社TVer
2006 年に広告代理店および在京民放キー局の共同出資により、株式会社プレゼントキャストとして設立。2015 年に民放公式テレビ配信サービス「TVer（ティーバー）」を開始し、場所や時間に縛られない「見逃し配信」という新たな視聴習慣を国内に定着させた。2020 年の社名変更を経て、現在は在京・在阪の民放 10 社および広告代理店が参画する国内最大級の映像配信プラットフォームへと成長を遂げている。サービス開始 10 周年を迎える 2025 年には、累計アプリダウンロード数 9,000 万、月間動画再生数 6.5 億回を突破。現在は「テレビを開放して、もっとワクワクする未来を　TVerと新しい世界を、一緒に。」をミッションに掲げ、リアルタイム配信やコネクテッド TV 対応を強化し、放送と通信を融合させた次世代のテレビ体験の創出を目指している。

インタビュイー（写真左から）
・広告プロダクト本部本部長大野祐輔氏
・広告プロダクト本部プロダクト開発部髙品純大氏

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

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

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

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

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

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

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

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

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

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

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

2. 自動同期

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

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

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

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

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

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

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

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

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

AI.SEARCH の導入

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

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

シンプルな管理

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

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

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

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

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

今後の予定

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

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

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

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

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

イオンフィナンシャルサービス: BigQuery を軸に全社横断的なデータ分析基盤を構築し、緻密な 1 to 1 マーケティングを強化

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

グループ全体で 18,086 店舗（2025 年 2 月時点）を誇り、総従業員数は 60 万人を超えるイオングループ。その金融事業を担い、クレジットカード「イオンカード」やスマホ決済「AEON Pay」、電子マネー「WAON」など、決済を中心に多様な金融サービスを展開するイオンフィナンシャルサービス株式会社（以下、イオンフィナンシャルサービス）にとって、高精度かつ高速な全社横断型データマネジメント基盤は不可欠の存在となっています。その構築プロジェクトにおいて、Google Cloud が基盤として選ばれた理由、現在の手応え、今後の展望までをプロジェクトの最高責任者に伺いました。

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

利用しているソリューション:
インフラストラクチャのモダナイゼーション

緻密な 1 to 1 マーケティングに不可欠な、全社横断型データマネジメント基盤

総合スーパー「イオン」「ダイエー」や、小型スーパー「まいばすけっと」など国内だけでなく、アジアを中心に 14 か国で小売事業を展開しているイオングループ。80 年代からは金融事業にも進出しており、現在はイオンフィナンシャルサービスを中心に、決済サービスや銀行、保険、リースなど幅広くサービスを提供しています。イオンフィナンシャルサービスの常務執行役員システム担当兼システム本部長兼サイバーセキュリティ担当の光石博文氏は、大規模小売事業者であるイオングループが金融事業部門を持つ意義を、次のように説明します。

「買い物をする店舗と決済のスキームが同一グループ内にあることは、どちらか片方しか持たない事業者と比べて圧倒的なアドバンテージとなります。小売事業が持つ詳細な購入履歴・商品情報と、金融事業が持つお客さま情報を紐付けることで、お客さま一人ひとりに最適化されたアプローチが可能になるためです。具体的にはお客さまが購入した商品に合わせた電子クーポンを発行したり、キャンペーンの告知を行ったりといった 1 to 1 のマーケティング施策を精度高く、クイックに実行できます。」

イオングループは、この決済と小売が融合した環境を「イオン生活圏」と呼んでいます。そのメリットを最大限に引き出すためにはグループ全体のデータを素早く収集し、リアルタイムなマーケティング分析を可能にする DMS（データマネジメントシステム：決済に関連するデータを分析する基盤）が欠かせません。しかし光石氏によれば、以前のイオングループはその点で大きな課題を抱えていました。

「とりわけネックになっていたのが、情報収集・処理速度の遅さです。イオングループには全社をまたぐ DMS が存在せず、それぞれの企業がデータ基盤をオンプレミスで構築していました。他社のデータを利用したい場合、データが同一プラットフォーム上に存在しないため、データの取り寄せが 2 日遅れになることもあり、お客さまの現在の嗜好や行動に合う提案が難しくなっていたのです。また、精度の低いデータではセグメント分けも大まかにならざるを得ず、緻密な 1 to 1 マーケティングを展開できませんでした。しかし我々は、例えばキュウリを買ったお客さまには、ランドセルや自転車のクーポンではなく、やはりマヨネーズのクーポンをお店にいる間にお届けしたい。売上の面だけでなく、顧客のファン化、リピーター化を促進するという意味でも、早期の解決が求められていました。」

膨大な量のデータを高速かつ柔軟に扱える BigQuery をシステム構築の柱に

これらの問題を解決すべく、光石氏は全社横断で使える DMS の構築を決意。2022 年にイオンフィナンシャルサービスが主体となって、プロジェクトをスタートさせました。同プロジェクトでは、DMS 構築の目的として、顧客一人ひとりに寄り添ったサービス提供・提案を可能にすること、情報を素早く収集しリアルタイム性を確保すること、そして、グループ全体で情報を共有し、連携したマーケティング分析を可能にすることの 3 点を掲げました。しかし、これらの目標を会社ごとに分断されたオンプレミス環境で実現するのは実質不可能です。そこで選択されたのがクラウドへの移行でした。

「クラウドへの移行は、プロジェクトのかなり早い段階で決断しました。そのうえで我々の目的に最適なプラットフォームを見つけ出すため、およそ数か月かけて技術検証やコンペティションを行い、2022 年冬に BigQuery を中核とするデータベースを構築する方針を固めました。BigQuery を選んだのは、イオングループの膨大な量のデータを高速かつ柔軟に扱えたからです。Google Cloud が提供する分析基盤なだけあり、イオングループの月数十億に及ぶ商品単位の購買データや、数千万人の会員データをノンストレスで処理できる点においては、素晴らしいパフォーマンスを見せてくれました。また、イオングループでも Google Cloud を利用している会社が多く、グループ内の親和性を期待できる点も決め手になりました。」

なお、DMS の開発にあたっては従来のアプローチを一新。開発手法をウォーターフォールからアジャイルに変更して、サービスや機能を段階的にリリースしていけるようにしたほか、これまで外部に委託することの多かった開発を内製化することにも挑戦しています。

「このプロジェクトを通じ、社内の開発力を高めていきたいという狙いがありました。とは言え、まだ社内メンバーだけでは人数もスキルも足りませんから、外部のパートナー企業にも入ってもらいつつ、皆が対等で意見交換できるワンチーム体制で開発に取り組んでいます。開発体制の変更にはリスクもありましたが、社内開発力アップのためには避けて通れません。Google Cloud に提供してもらった教育カリキュラムを利用するなどしてチームの質を高めていきました。」

プロジェクト推進においては、実際に DMS を利用する現場メンバーも巻き込みました。どういうデータがほしいか、どういう形に出力したいかを開発メンバーと現場メンバーでコミュニケーションをとることで、DMS に対する思い入れも深まり、実用性も大幅に向上するという副次効果も生まれました。

DMS の開発作業は 2023 年 12 月に最初の機能を提供した後、2024 年 7 月から本格的に加速。2025 年 5 月には通常業務に必要な機能をひと通り提供することができました。現在は、既存システムからの完全移行を目指し、まだ移行しきれていない細かな機能の追加が進められています。

組織と働き方を変える真の DX、さらには決済サービスのグローバル化も推進

まだ移行段階とはいえ、すでにイオングループの各現場で活用が始まっているという DMS。光石氏はその成果を次のように説明します。

「これまで 2 日はかかっていたデータ収集・分析が、わずか数分程度で完了するようになり、迅速な顧客アピールができる基盤が整ったと現場から喜びの声が上がっているところです。また、運用コストも従来システムと比べて、劇的に安く抑えることができています。とはいえ、本格的な運用成果が出てくるのはこれから。2026 年度には念願だったリアルタイムの 1 to 1 マーケティングキャンペーンの発信を本格化させ、お客さまそれぞれに、本当に必要な情報をお届けできるようにしていく予定です。」

さらに光石氏は、このプロジェクトを通じ、データ分析システムの刷新だけでなく、組織と働き方を変える真の DX を目指しているとも説明。以前は外注していたダッシュボードを現場の利用者たちが自ら作り始めるなど、すでに新たな動きが始まっていると語ります。

「この取り組みの面白いところは部署内で閉じていないこと。現場から経営陣までが同じダッシュボードを見て、同じ情報を共有する新しい試みをしている点を高く評価しています。こうした挑戦が現場から生まれていることも今回のプロジェクトの大きな成果と言えるでしょう。今後が非常に楽しみですし、できればこういった挑戦を一部のメンバーだけでなく、全従業員ができるようにしていきたいと考えています。」

もちろん今後、DMS の活用範囲はさらに拡大していきます。例えば、BigQuery に蓄積されたビッグデータから顧客の嗜好や行動を把握するために、AI をこれまで以上に活用していくことなどに挑戦していく予定です。

「あとは海外展開です。イオンの決済サービスは今後、より積極的にグローバル化を推進していきますので、Google Cloud にはぜひともアジアに力を入れてほしい。BigQuery を前提とした仕組みを作ったので、それをあらゆる国・地域で快適に使えるようにしてもらいたいですね。Google Cloud の技術力は断トツだと高く評価していますので、今後も世界中で一緒にビジネスを拡大していければと思います。」

イオンフィナンシャルサービス株式会社
イオングループの核となる小売事業と連携し、イオンカードや AEON Pay、電子マネーの WAON などの決済サービスを提供しているほか、銀行、保険、リースなどの事業も展開。従業員数は金融グループ全体で 15,547 人（国内 4,644 人、国際 10,903 人）（2025 年 2 月末時点）。

インタビュイー
常務執行役員
システム担当兼システム本部長兼サイバーセキュリティ担当
光石博文氏

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

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

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

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

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

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

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

グローバルクエリとは

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

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

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

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

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

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

グローバルクエリの活用

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

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

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

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

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

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

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

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

ユーフォリア: Gemini で AI マルチエージェントを構築し、最先端のスポーツ科学の知見とデータを、すべての人々の健康づくりに活用

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

株式会社ユーフォリア（以下、ユーフォリア）は、スポーツテックのリーディングカンパニーとしてプロ・アマや競技種別を問わず、国内外の数多くのアスリートを支援してきました。そんな同社は Google Cloud と Gemini を活用し、長年蓄積してきたデータとスポーツ科学の知見を、一般社会の健康づくりに役立てるプロジェクトを推進しています。この意欲的な試みを主導するキーパーソン 3 名にお話を伺いました。

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

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

トップスポーツの分野で得られたノウハウを、いかに還元していくか

「すべての人の可能性が生きる未来へ」というビジョンの下、ユーフォリアは 2008 年に設立。創業 5 年目の 2012 年から、ラグビー日本代表の強化プロジェクトをデータ分析の分野で精力的にサポートするなど、スポーツテックの分野に本格的に進出しています。このノウハウを反映した「ONE TAP SPORTS」は、選手の身体能力やコンディション、トレーニング状況などを一元管理できるシステムとして、国内外のスポーツ界で高い評価を得てきました。しかし、共同創業者で代表取締役社長の橋口寛氏は、より大きな目標を目指してきたと振り返ります。

「創業時、共同創業者の宮田（誠氏）と考えたのは『人やモノが本来持っているポテンシャルが発揮されていない現状を変えていきたい』ということでした。その一環としてスポーツの分野に関わるようになりましたが、トップスポーツは、宇宙開発などと同様に『イノベーションの苗床』としての側面も持っています。極限の環境で磨かれた最先端の技術やノウハウが、やがて汎用化されて広く普及し、社会全体を変えていくのです。私たちにとっても、トップスポーツの分野で獲得したノウハウを、いかに多くの人にスケーラブルに還元していくかが、究極のテーマになってきました。」

この目標を達成すべく、ユーフォリアは 2017 年に「ONE TAP SPORTS」の分析項目に「睡眠」を追加。スタンフォード大学で、睡眠・生体リズム研究所所長を務める西野精治氏もアドバイザーに起用します。さらに 2023 年 8 月には、国立スポーツ科学センターの研究員として、生体リズムと睡眠を専門分野に、多くの五輪アスリートの国際競技力の向上に携わった安藤加里菜氏を、リサーチャーとして迎えました。安藤氏は、睡眠の大切さとユーフォリアに参画した理由を次のように説明します。

「正しく睡眠を取るのは、誰でも無料でできる健康管理の手段です。また、生体リズムや睡眠の分野は、2017 年に『時計遺伝子』の研究がノーベル生理学・医学賞を受賞した頃から注目されてきました。しかし日本は、OECD が 2021 年に実施した調査では、調査対象となった 33 か国のなかで最も睡眠時間が短いとされるなど、睡眠不足による健康被害や経済損失が深刻な社会課題となってきました。トップスポーツの分野では、私たちのような専門家が個別にカウンセリングや指導を行ってきました。しかし、抱えられるクライアントの数には限界がありますので、テクノロジーの力を借りて、このような状況を変えたいと思っていました。」

BigQuery と Gemini の導入で実現した、ビジネスモデルの進化

安藤氏が入社した 2 か月後には、AI や量子コンピュータの開発に携わってきた田中孝氏も入社し、R&Dセンター長に就任します。田中氏がまず取り組んだのは、Google Cloud と BigQuery を導入し「ONE TAP SPORTS」で蓄積されてきた膨大なデータを活用できる基盤を構築することでした。

「『ONE TAP SPORTS』は他社製のクラウドを使用していたのですが、データ構造がアプリケーション内で閉じていたため、多角的に活用するのが困難でした。しかし各種デバイスから得られる客観データや、アスリートの主観データなどを BigQuery で統合し、Looker Studio で可視化すれば、ユーザーにとっても 10 年近く蓄積したデータの活用度が一気に上がります。」

さらに翌年には Gemini が導入され、睡眠をアドバイスする AI エージェントの開発がスタートします。橋口氏と田中氏にとっては、これも必然的な決断でした。

「BigQuery の導入により、弊社のビジネスモデルは『ONE TAP SPORTS』の販売から、より付加価値の高いデータやダッシュボードの提供へと変化しました。Gemini の導入はその延長線上にあります。AI を活用すれば、物理的なキャパを超えてより多くの人に、より低価格に高品質なサービスを提供できるはずだという考えは、以前からずっとありました。」（橋口氏）

「Gemini は、Google Cloud 環境にあるデータウェアハウスとシームレスに連携でき、マルチクラウドにも対応しています。コスト、性能、将来的な拡張性や進化のスピードを考えても、ほぼ一択だったと言えます。特に初期段階では、Google Cloud のエンジニアと何度もディスカッションして、最適なアーキテクチャやツールの組み合わせを固めてから AI エージェントを開発しましたので、大きな問題や手戻りは発生しませんでした。」（田中氏）

ユーフォリアの AI システムは、先進的なアーキテクチャで構成されています。田中氏によれば、最大の特徴は睡眠を軸に、栄養エージェント、トレーニングエージェントなど、何人もの「専門家」が連携してユーザーを支援する「マルチエージェントシステム」を採用している点にあります。

「人間の体は複雑で、睡眠の悩みひとつをとっても、原因は食事、運動、メンタルなど多岐にわたります。そこで、単一の AI ですべてを処理するのではなく、各分野の専門知識を持つ複数の AI エージェントに、分析とフィードバックの役割を分けることにしました。それらを束ねるオーケストレーター（指揮者）役のエージェントも設け、総合的かつ具体的なアドバイスを導き出すようにしています。」

一方、負荷計算などを行う際には、従来型の数理最適化モデルや同社が長年蓄積してきたデータを用いた計算結果に基づき、Gemini が文章を生成するコンポジット構造を採用しています。これはハルシネーションを回避しつつ、回答の精度を最大限に高める工夫ですが、プロンプトのチューニングでは、安藤氏の知見もフルに活用されました。

「最初はアルバイトの方に指示をするような要領で入力していたのですが、出力される結果はイメージとどこか違っていました。それは私たち人間が無意識のうちに多くの判断をしており、指示書に落とし込めていないからなのです。生成 AI はユーザーに気を使い、データがない状況でも『良い結果ですね』と回答してしまいがちになりますので、この傾向を修正することも必要でした。さらには詳細な分析と読みやすさを両立させるために、文字数の最適なバランスを見つける、シフトワーカーの方に向けて、土日のない勤務体系や分眠（複数回に分けて眠ること）を踏まえたアドバイスができるようにするなど、様々な試行錯誤を重ねました。今後は、海外出張や海外旅行の『行き先と日程を考慮した』最適な過ごし方の提案などに応用することも考えています。」

AI エージェントの活用がもたらす、社会全体のエンパワーメント

AI エージェントは社内テストを完了。四国電力株式会社などの顧客企業との実証実験が始まっています。利用者からは「データに基づいた具体的な改善案が提示されるのでわかりやすい」「行動変容につながりやすい」「AI のアドバイスを実践したことで中途覚醒が減り、睡眠の質が明らかに向上した」などの声が寄せられているとのことです。安藤氏によれば、運用面での定量的な成果も得られ始めています。

「これまではクライアントにアポイントメントを取った後、データの見方など基本的な説明をするのに多くの時間を割いていました。その部分を AI が代行することで、かなり効率化が進んでいます。一人のカウンセラーがアドバイスできるキャパシティも、30 人から 100 人に増やす計画を進めていますし、生成 AI の活用が進めば、1,000 人のクライアントをサポートすることも夢ではありません。将来的には、1 万人規模の企業にも対応できるレベルを目指したいと思っています。」

ユーフォリアでは、企業向けのサービスとして「ONE TAP SPORTS for Biz」を開発し、昼夜を問わず働くシフトワーカーやドライバーなど「産業アスリート」と呼ばれる人々の支援も行ってきました。今後は睡眠だけでなく、食事、運動、メンタルヘルスなど、あらゆる領域で AI エージェントを開発し、互いに連動させることによって、より包括的なサービスを展開していく予定です。橋口氏は、この新たな AI システムを「QUARIA AI」（商標登録 / 特許出願中）と名付けています。そこには、クオリア＝人間らしい感性を大切にしながら、社会的な使命を全うしていきたいという情熱が込められていました。

「QUARIA AI には弊社が培ってきたノウハウが反映されますので、部活動の指導者不足の解消や、地域コミュニティの健康増進、企業の生産性向上など、社会課題の解決に幅広く貢献できると思います。ただし我々が目指しているのは、各分野のエキスパートの方々を代替することではありません。むしろ『エンパワー（元気づける）』することです。新たなソリューションを多くの人に届け、社会全体を変えられるインパクトを持たせるには、最新のテクノロジーが不可欠。Google Cloud とともに、ビジョンの実現に邁進していきたいと考えています。」

株式会社ユーフォリア
2008 年設立。「人とスポーツの出合いを幸福にする。」をミッションに掲げるスポーツテック企業。スポーツ選手のコンディション管理・ケガ予防のためのデータマネジメントシステム「ONE TAP SPORTS」、スポーツスクール・クラブ活動のための運営管理アプリ「Sgrum」（スグラム）、各種団体のためのグループコミュニケーションサービス「らくらく連絡網＋（プラス）」などを開発・提供している。現在はスポーツで培った知見を活かし、企業向けの「ONE TAP SPORTS for Biz」も展開。スポーツ科学と AI の融合により、社会課題の解決に取り組んでいる。

インタビュイー（写真左から）
・R&Dセンター長　田中孝氏
・代表取締役社長　橋口寛氏
・ウェルネスチーム　安藤加里菜氏

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

BigQuery の会話型分析のご紹介

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

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

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

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

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

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

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

図 1 - BigQuery の会話型分析

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

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

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

図 2 - BigQuery の会話型分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gemini 3.0 のサポート

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

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

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

使ってみる

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

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

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

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

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

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

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

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

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

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

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

仕組み: 実例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

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

BigQuery

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

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

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

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

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

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

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

使ってみる

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

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

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

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

Open Knowledge Format のご紹介

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

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

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

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

設計の 3 つの原則

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

今後の展開

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

成長中のレストランの例

成長に伴う摩擦

デジタルツイン

BigQuery Graph でのモデリング

実務で活きる精度

将来を見据えて

まとめ

使ってみる

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

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

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

ご利用にあたって

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

ミリ秒未満の読み取りレイテンシを実現する新しい Bigtable インメモリ階層

キャッシュミスの悪夢: よくあるケース

Bigtable のインメモリ階層の登場

舞台裏のご紹介

キャッシュミスの悪夢を再現

Bigtable Enterprise Plus を使ってみる

詳細

Google Cloud Knowledge Catalog のご紹介

集約: データアセット全体でコンテキストを統合

拡充: 継続的な学習を通じて意味を生成する

検索: 高精度で安全なデータ取得によるエージェント活用の拡大

運用から分析へ: Spanner Graph と BigQuery Graph による統合ソリューション

運用ワークロード向けの Spanner Graph

分析ワークロード向けの BigQuery Graph

統合ソリューションとしての Spanner Graph と BigQuery Graph

グラフに関するあらゆるニーズに対応する統合ソリューション

Spanner Graph と BigQuery Graph を今すぐ使ってみる

エージェンティック時代を支える BigQuery の新機能

オープンかつ境界なきクロス クラウドレイクハウスの実現

エンタープライズ エージェントのためのグラフベースの推論

構造化、非構造化データの価値を引き出すネイティブな AI 処理

エージェンティックな体験

圧倒的なパフォーマンスとスケール

BigQuery Graph と Kineviz GraphXR で企業ナレッジの非構造化データを拡張

BigQuery で、断片化されたデータを統合

BigQuery パイプライン: 非構造化データから構造化データへ

Kineviz GraphXR で隠れた分析情報を引き出す

メリット

始める

BigQuery Graph のご紹介: データに潜む関係性を明らかに

業界を問わず企業が直面するグラフ導入の課題

BigQuery Graph の主なユースケース

実際の BigQuery Graph の活用事例

BigQuery Graph の使い方

準備ができたら

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

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

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

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

TVer: 日本最大級の動画配信プラットフォームを支える広告基盤を Google Cloud で内製化

事業成長を加速させるため、ビジネスの心臓部である広告サーバーの内製化を決断

GKE と、Memorystore、Bigtable の適材適所な併用。技術的難題を突破した PSO の支援

安定と革新を両立した配信基盤を武器に、さらなる視聴体験の向上を目指す

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

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

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

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

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

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

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

オープンかつ境界なきクロスクラウドレイクハウスの実現

エンタープライズエージェントのためのグラフベースの推論

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

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

緻密な 1 to 1 マーケティングに不可欠な、全社横断型データマネジメント基盤

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

グローバルクエリとは

グローバルクエリの活用

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

ユーフォリア: Gemini で AI マルチエージェントを構築し、最先端のスポーツ科学の知見とデータを、すべての人々の健康づくりに活用

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