はじめに
2026年10月19日〜10月25日の Google Cloud データ分析カテゴリでは、AlloyDB から BigQuery のデータを直接クエリする Lakehouse federation が一般提供（GA）となり、BigQuery では文書を分割する AI.CHUNK_DOCUMENT 関数と、テキストを翻訳する AI.TRANSLATE 関数が GA になりました。Looker では、Knowledge Catalog によるメタデータの自動カタログ化が GA となっています。
本記事では、この期間に公開されたデータ分析カテゴリの更新のうち、主要な8件を「アップデート詳細」で取り上げます。
各トピックでは「何が変わったのか」「どんな業務シーンで使えるのか」「どんなメリットがあるのか」を、業務担当者・IT 部門・経営層の方に向けて整理し、公式ドキュメントへのリンクを添えています。
| 対象期間 |
2026年10月19日〜2026年10月25日 |
| 対象製品 |
Google Cloud |
| 対象カテゴリ |
データ分析 |
| アップデート件数 |
8件（主要トピック） |
今回のアップデート一覧
アップデート詳細
1. AlloyDB — BigQuery のデータを直接クエリできる Lakehouse federation が一般提供に（GA・2026年10月19日）
AlloyDB（Google Cloud の PostgreSQL 互換データベース）の Lakehouse federation が一般提供（GA）になりました。bigquery_fdw 拡張機能を使い、BigQuery にあるデータを移動・複製せずに、AlloyDB から直接クエリできます。
🔍 何が変わったのか
- AlloyDB から、BigQuery の最新のデータをそのままクエリできます。データを AlloyDB にコピーする必要はありません
- 公式ドキュメントでは、AlloyDB の業務データと、BigQuery や Cloud Storage にある過去のデータ・分析用のデータを同時にクエリする HTAP（トランザクション処理と分析処理の併用）のワークロードが用途として説明されています
- 公式ドキュメントには制限として、外部テーブルの作成時に AlloyDB は BigQuery 側のテーブルの存在やスキーマを検証しないこと、BigQuery のテーブルへのアクセスはクラスタのサービス アカウントで確認され、個々のユーザーの IAM 権限は確認されないことが記載されています
💼 こんな場面で活用できます（ユースケース）
AlloyDB で受注や在庫などの業務データを扱い、過去の実績データを BigQuery に蓄積しているアプリケーション開発者が、両方のデータを1つのクエリで参照する場面で使えます。BigQuery から AlloyDB へデータを取り込む処理を別に用意しなくても、AlloyDB の SQL から BigQuery のデータを読めます。
✨ 導入メリット
- データを移動・複製せずに参照できるため、AlloyDB へコピーする処理を用意する必要がありません
- BigQuery の最新のデータを AlloyDB から参照でき、業務アプリケーションでのデータ活用の選択肢が広がります
- 一般提供（GA）となり、本番のシステムへの組み込みを計画できます
📚 公式ソース
2. Firestore — テキスト検索・地理空間検索と、DML 操作が一般提供に（GA・2026年10月19日・22日）
Firestore（Google Cloud のドキュメント型 NoSQL データベース）で、2件の機能が一般提供（GA）になりました。10月19日には テキスト検索と地理空間検索が、Firestore と Firestore with MongoDB compatibility（MongoDB 互換の API で使う Firestore）の両方で GA となりました。10月22日には、Firestore のパイプライン操作で使う DML（データを変更する操作）が GA になり、insert と upsert にも対応しています。
🔍 何が変わったのか
- テキスト検索・地理空間検索（10月19日）: Firestore と Firestore with MongoDB compatibility で、テキスト検索と地理空間検索が GA になりました
- DML 操作（10月22日）: Firestore のパイプラインでデータを変更する DML 操作が GA になり、新たに insert（追加）と upsert（更新または追加）に対応しました
- DML 操作の公式ドキュメントでは、これらの操作に Firestore Enterprise エディションが必要であることと、DML のステージはパイプラインの最後に置く必要があることが説明されています
💼 こんな場面で活用できます（ユースケース）
Firestore でアプリケーションのデータを管理している開発者が、保存した文書をキーワードで探す機能や、位置情報をもとに対象を絞り込む機能を作る場面で使えます。DML 操作は、パイプラインで条件に合うドキュメントを選び、その結果を追加・更新する処理に使えます。
✨ 導入メリット
- テキスト検索と地理空間検索が GA となり、本番のアプリケーションに組み込む計画を立てられます
- MongoDB 互換の API を使う場合も、同じく GA となった検索機能を使えます
- パイプラインの中でデータの追加・更新まで行えるようになり、読み出しと書き込みを1つの処理にまとめられます
📚 公式ソース
3. Spanner — 近似集計関数に対応（2026年10月20日）
Spanner（Google Cloud のグローバル分散データベース）が、GoogleSQL と PostgreSQL の両方の言語で近似集計関数に対応しました。近似集計関数は、重複を除いた件数（distinct count）を統計的な推定値として求める関数です。
🔍 何が変わったのか
- GoogleSQL と PostgreSQL のどちらの言語でも、近似集計関数を使えます
- 大規模なデータセットでは、正確な集計に比べて結果を速く求められ、リソースも節約できます
- 公式ソースでは、近似集計関数とあわせて HyperLogLog++ 関数と Sketches（データの集計結果をコンパクトにまとめたもの）のドキュメントが案内されています
💼 こんな場面で活用できます（ユースケース）
Spanner に蓄積した大量のアクセス記録や取引データから、利用者数などの重複を除いた件数を集計しているデータ担当者が使えます。厳密な値でなく概数で足りる集計を、正確な集計より短い時間で求められます。
✨ 導入メリット
- 大規模なデータセットでの重複排除の集計を、正確な集計より速く実行できます
- 集計に使うリソースを節約できます
- GoogleSQL と PostgreSQL のどちらの言語を使っていても利用できます
📚 公式ソース
4. BigQuery — 文書を RAG 向けのチャンクに分割する AI.CHUNK_DOCUMENT 関数が一般提供に（GA・2026年10月21日）
BigQuery の AI.CHUNK_DOCUMENT 関数が一般提供（GA）になりました。非構造化の文書を、意味のまとまりを保ったテキストの断片（チャンク）に分割する、テーブル値関数（結果を表として返す関数）です。
🔍 何が変わったのか
- 非構造化の文書を、意味のまとまりのあるテキストのチャンクに分割できます
- 分割したチャンクは、ベクトル埋め込み（文章の意味を数値の並びで表したもの）と RAG（Retrieval-Augmented Generation。検索した情報をもとに生成 AI が回答する仕組み）のワークフロー向けに最適化されています
💼 こんな場面で活用できます（ユースケース）
社内の規程やマニュアルなどの文書をもとに、生成 AI で質問に回答する仕組みを作るデータエンジニアが、文書を埋め込みの前にチャンクへ分割する工程で使えます。分割の処理を BigQuery の SQL の中で行えます。
✨ 導入メリット
- RAG のための文書の前処理を、BigQuery の SQL で書けます
- 意味のまとまりを保って分割するため、埋め込みや検索に使いやすいチャンクを用意できます
- 一般提供（GA）となり、本番の AI 活用の仕組みに組み込む計画を立てられます
📚 公式ソース
5. Dataflow — Streaming Engine のジョブで複数ゾーンに状態を複製するストリーミング高可用性（Preview・2026年10月21日）
Dataflow（ストリーミング・バッチのデータ処理パイプラインを実行するサービス）で、Streaming Engine を使うジョブのストリーミング高可用性が Preview として使えるようになりました。requires_high_availability サービス オプションを有効にすると、Dataflow はリージョン内の複数のゾーンにバックエンドの状態を複製し、1つのゾーンの障害からジョブを保護します。
🔍 何が変わったのか
- requires_high_availability サービス オプションを有効にすると、ジョブのバックエンドの状態がリージョン内の複数ゾーンに複製されます
- 公式ドキュメントでは、対象は Streaming Engine を使うストリーミング パイプラインであること、高可用性を有効にしたジョブで特定のワーカーゾーンを指定すると拒否されることが説明されています
- 高可用性の有効・無効は、パイプラインのインプレース更新では切り替えられません。公式ドキュメントでは、変更するには自動の停止・置き換えによる更新を行うか、パイプラインを停止またはドレインして新しいジョブを開始する必要があると説明されています
- データの処理と複数ゾーンへの複製が終わってからウォーターマークが進むため、ウォーターマークの遅延が数秒増える場合があります
- 料金について公式ドキュメントでは、高可用性を有効にしたジョブは常にリソースベースの課金になること、Preview の期間中は高可用性の利用に追加料金がかからないこと、GA 後は複製分の使用量も主となる状態と同じ料金で課金されることが説明されています
💼 こんな場面で活用できます（ユースケース）
注文やセンサーのデータを Dataflow のストリーミング パイプラインで処理し、ゾーン障害による処理の停止を避けたいデータエンジニアが使えます。Preview のため、検証用のジョブで動作を確かめる使い方が考えられます。
✨ 導入メリット
- 1つのゾーンの障害からストリーミング ジョブを保護でき、データ処理基盤の可用性を高められます
📚 公式ソース
6. Looker — Knowledge Catalog によるメタデータの自動カタログ化が一般提供に、LookML ダッシュボードやエージェントも対象に（GA・2026年10月21日）
Looker (Google Cloud core) のメタデータを Knowledge Catalog（旧 Dataplex Universal Catalog。メタデータを保存・管理するデータカタログのプラットフォーム）で自動的にカタログ化し、取り込む機能が一般提供（GA）になりました。より細かなメタデータと、新しい種類のアセットにも対応しています。
🔍 何が変わったのか
- ディメンション・メジャーの定義、既定のクエリ、リレーションシップなど、より細かなメタデータを取り込めるようになりました
- 新しいアセットの種類として、LookML ダッシュボード、LookML ダッシュボードの要素、エージェントが加わりました
- データリネージ（データの出どころと流れの記録）との連携は、引き続き Preview です
- 公式ドキュメントでは、連携は Looker (Google Cloud core) インスタンスで既定で有効であること、有効にしてから Looker のデータが表示されるまでに最大1日かかる場合があることが説明されています
💼 こんな場面で活用できます（ユースケース）
Knowledge Catalog で組織のデータ資産を管理しているデータ管理部門が、BigQuery のテーブルなどとあわせて、Looker のダッシュボードやメジャーの定義を検索できるようにする場面で使えます。利用者は、目的の指標がどのダッシュボードやエージェントにあるかを、カタログから探せます。
✨ 導入メリット
- Looker のメタデータが自動でカタログに取り込まれ、手作業で一覧を作る手間を減らせます
- ディメンション・メジャーの定義やリレーションシップを、カタログ上で確認できます
- 一般提供（GA）となり、データ ガバナンスの運用に組み込む計画を立てられます
📚 公式ソース
7. BigQuery — テキストを翻訳する AI.TRANSLATE 関数が一般提供に（GA・2026年10月22日）
BigQuery の AI.TRANSLATE 関数が一般提供（GA）になりました。テキストの文字列を別の言語に翻訳する関数で、標準の NMT（Neural Machine Translation。ニューラル機械翻訳）のワークロードと、Translation LLM（TLLM）の機能に対応しています。
🔍 何が変わったのか
- BigQuery の SQL の中で、テキストの文字列を言語間で翻訳できます
- 標準の NMT のワークロードと、Translation LLM（TLLM）の機能の両方に対応しています
💼 こんな場面で活用できます（ユースケース）
海外の顧客から届いた問い合わせやレビューを BigQuery に蓄積しているカスタマーサポートやマーケティングの担当者が、分析の前に1つの言語へそろえる処理で使えます。
✨ 導入メリット
- 翻訳を SQL のクエリの中で実行でき、多言語のデータをそのまま分析の流れに組み込めます
- 一般提供（GA）となり、定期的な分析処理への組み込みを計画できます
📚 公式ソース
8. Data Studio — BigQuery Graph に接続し、グラフのメジャーを指標としてレポートで使用可能に（2026年10月22日）
Data Studio（旧 Looker Studio。データをダッシュボードやレポートにまとめるツール）の BigQuery コネクタで、BigQuery Graph に接続できるようになりました。カスタム SQL クエリでグラフを照会することもでき、グラフのメジャーは指標（metrics）として取り込まれ、レポートで使えます。
🔍 何が変わったのか
- BigQuery コネクタから BigQuery Graph に接続するか、カスタム SQL クエリでグラフを照会できます
- グラフに定義されたメジャーは、データソースの指標として取り込まれます
- 公式ドキュメントでは、グラフのメジャーの集計方法は BigQuery のグラフ定義で決まり、Data Studio では変更できないこと、データ型と説明は Data Studio のデータソースで編集できることが説明されています
💼 こんな場面で活用できます（ユースケース）
BigQuery Graph でデータの関係（ノードとエッジ）をモデル化しているデータ分析の担当者が、そのグラフのメジャーを Data Studio のレポートで可視化し、関係者と共有する場面で使えます。
✨ 導入メリット
- BigQuery Graph で定義したメジャーを、そのまま Data Studio の指標として使えます
📚 公式ソース
まとめ
2026年10月19日〜25日のデータ分析カテゴリでは、AlloyDB から BigQuery のデータを直接クエリする Lakehouse federation と、BigQuery の AI.CHUNK_DOCUMENT・AI.TRANSLATE 関数が一般提供（GA）になりました。Firestore のテキスト検索・地理空間検索と DML 操作、Looker の Knowledge Catalog 連携も GA となっています。
関連 XIMIX 記事
Google Cloud アップデート情報をシリーズでご覧になりたい方は、アップデート情報一覧から過去の記事もご確認いただけます。
XIMIX からのご案内
XIMIX（サイミクス）は NI+C が運営する Google Cloud プレミアパートナーサービスです。Google Cloud / Google Workspace の導入・活用支援、データ活用、AI 活用などをご支援しています。本記事で取り上げた BigQuery や Looker、AlloyDB、Dataflow を活用したデータ基盤の構築・移行・運用にご関心がありましたら、お気軽にご相談ください。
お問い合わせはこちら
参考資料