はじめに
「機械学習モデルを学習させなくても、表形式のデータから予測を得られる」——そんな選択肢が、データウェアハウスの標準機能として現実味を帯びてきました。2026年8月31日〜9月6日の期間は、BigQuery の TabFM 対応や BigQuery Graph の一般提供（GA）、Looker の Semantic Search の GA、Cloud Storage のバッチ処理の大幅強化など、データ分析基盤の「使いやすさ」を一段引き上げるアップデートが数多く発表されました。
本記事では、この期間に発表された Google Cloud のデータ分析カテゴリのアップデートから、特に注目したい主要トピック16件を厳選し、業務担当者・IT 部門・経営層の方々にわかりやすく解説します。ドライバの更新やマイナーリリースなどは、記事末尾の「その他のアップデート」でまとめてご紹介します。
特に BigQuery の TabFM（表形式データ向け事前学習済み基盤モデル） と 会話型分析のマーケットバスケット分析対応は、専門人材に頼らずデータ活用を広げたい組織にとって見逃せない内容です。一方で Cloud Trace のトレースシンクの提供終了 や Looker の OpenJDK 11 サポート終了予告 のように、自社の構成を点検しておきたい告知も含まれています。
| 対象期間 |
2026年8月31日〜2026年9月6日 |
| 対象製品 |
Google Cloud |
| 対象カテゴリ |
データ分析 |
| アップデート件数 |
16件（主要トピック） |
今回のアップデート一覧
アップデート詳細
1. BigQuery — 表形式データ向け基盤モデル「TabFM」に対応（Preview・2026年8月31日）
BigQuery（Google Cloud のクラウド型データウェアハウス）が、Google の TabFM——表形式データ（行と列で構成された、いわゆる表のかたちのデータ）向けに事前学習された基盤モデル——をサポートしました。AI.PREDICT や AI.EVALUATE といった関数を通じて利用でき、モデルの学習やハイパーパラメータ調整（精度を高めるための設定の試行錯誤）を行わずに、回帰（数値の予測）や分類（カテゴリの判定）を実行できます。本機能は Preview（プレビュー）段階です。
🔍 何が変わったのか
- BigQuery が、Google の表形式データ向け事前学習済み基盤モデル TabFM をサポートしました
- AI.PREDICT / AI.EVALUATE などの関数経由で利用できます
- in-context learning（文脈内学習。与えた例からその場で学び取る方式）により、モデルを学習させることなくゼロショットで予測を行えます
- 本機能は Preview（プレビュー）段階での提供です
💼 こんな場面で活用できます（ユースケース）
「解約しそうな顧客を見極めたい」「来月の受注数を見積もりたい」といったニーズを持つ営業企画やマーケティングの担当者が、データサイエンティストの手を借りずに予測を試したい場面で活用できます。BigQuery に蓄積した既存の顧客テーブルや売上テーブルに対して、SQL から関数を呼び出すだけで結果を得られるため、まずは小さく試してから本格導入を検討するという進め方が取りやすくなります。
✨ 導入メリット
- モデル学習とハイパーパラメータ調整が不要なため、予測を試すまでのリードタイムを大幅に短縮できます
- 機械学習の専門人材が限られている組織でも、SQL の知識でデータ活用を前に進められます
- 学習用インフラの準備や運用が不要で、試行にかかるコストと運用負荷を抑えられます
📚 公式ソース
2. BigQuery — BigQuery Graph が一般提供（GA）、CALL 文とパス検査関数に対応（2026年8月31日）
BigQuery Graph（BigQuery でグラフデータを扱う機能）が一般提供（GA）になりました。あわせて CALL 文 と、GQL（Graph Query Language。グラフ構造を問い合わせるための標準的な言語）の パス検査関数——IS_ACYCLIC（同じノードを2度通っていないかを判定）、IS_SIMPLE（同じノードを2度通っていないか、あるいは重複が始点と終点だけかを判定）、IS_TRAIL（同じエッジを2度通っていないかを判定）——がサポートされました。グラフデータとは、データを「点（ノード）」と「線（エッジ）」の関係として表したもので、人と人のつながりや取引の連鎖といった関係性の分析に向いています。
🔍 何が変わったのか
- BigQuery Graph が一般提供（GA）になりました
- CALL 文がサポートされました
- GQL のパス検査関数（IS_ACYCLIC / IS_SIMPLE / IS_TRAIL）がサポートされました
- なお公式ドキュメントでは、GQL クエリの実行に Enterprise または Enterprise Plus エディションの予約が必要である旨が案内されています（オンデマンド料金の場合は SQL クエリでの GRAPH_EXPAND 関数の利用が案内されています）
💼 こんな場面で活用できます（ユースケース）
金融機関の不正検知担当者が、口座間の送金の連鎖から不自然な資金の循環を見つけたい場面や、製造業の調達担当者が、サプライチェーンの多階層の取引関係をたどってリスクの集中点を特定したい場面で活用できます。パス検査関数を使えば「同じ口座（ノード）を二度通っていないか」「同じ送金（エッジ）を重複してたどっていないか」といった条件で経路を絞り込めます。
✨ 導入メリット
- 関係性の分析を BigQuery 内で完結でき、専用のグラフデータベースを別途構築・運用する必要性を下げられます
- GA として提供され、本番環境での利用を計画しやすくなります
- 表形式では見えにくかったつながりを可視化でき、リスク把握や意思決定の精度向上に寄与します
📚 公式ソース
3. BigQuery — テーブルに自動採番列（identity column）を作成できるように（Preview・2026年8月31日）
BigQuery のテーブルに identity column（自動採番列）を作成できるようになりました。行を追加すると、BigQuery が一意の整数値を自動で生成してくれる列です。テーブルの 主キー（各行を一意に識別するための列）の生成と維持に利用できます。本機能は Preview（プレビュー）段階です。
🔍 何が変わったのか
- テーブルに identity column（自動採番列）を作成できるようになりました
- 公式ドキュメントでは、常にシステムが値を割り当てる GENERATED ALWAYS AS IDENTITY と、値を省略した場合のみ自動生成する GENERATED BY DEFAULT AS IDENTITY の 2 つの方式が案内されています
- 生成される値は一意ですが、厳密な連番ではなく、途中の整数が飛ぶ場合があると案内されています
- 1 テーブルに作成できる identity column は 1 つまでなど、いくつかの制限が公式ドキュメントに記載されています
- 本機能は Preview（プレビュー）段階での提供です
💼 こんな場面で活用できます（ユースケース）
基幹システムのデータを BigQuery 上でモデリングしているデータエンジニアが、ディメンションテーブル（マスタ系のテーブル）にサロゲートキー（業務的な意味を持たない識別子）を持たせたい場面で活用できます。従来は文字列の UUID を生成する方法が一般的でしたが、整数値の識別子を使えるようになり、テーブル結合の効率やストレージ効率の面で有利になると公式ドキュメントで案内されています。
✨ 導入メリット
- 識別子の採番をデータベース側に任せられ、アプリケーションや ETL 処理側の実装をシンプルにできます
- 整数値の主キーを使えるため、結合処理やストレージの効率面で有利になります
- 採番ロジックが個々の処理に散らばる状態を避けられ、属人化の解消に寄与します
📚 公式ソース
4. BigQuery — フォルダを使ったパイプラインの作成・管理が一般提供（GA）、Git フォルダは Preview（2026年8月31日）
BigQuery で、フォルダを使ったパイプライン（データの取り込み・加工処理を順序立てて実行するしくみ）の作成・保存・管理が一般提供（GA）になりました。あわせて、Git フォルダでのパイプライン管理が Preview（プレビュー）で利用できます。Git はソースコードの変更履歴を管理するしくみで、複数人での開発に広く使われています。
🔍 何が変わったのか
- フォルダを使ったパイプラインの作成・保存・管理が一般提供（GA）になりました
- Git フォルダでのパイプライン管理が Preview（プレビュー）で利用できます
- 公式ドキュメントでは、フォルダには個人用フォルダとチーム用フォルダがあり、IAM（アクセス権限管理）のポリシーが階層的に継承されると案内されています
- Git リポジトリは Developer Connect を使って接続する構成が案内されています
💼 こんな場面で活用できます（ユースケース）
データ基盤の担当者が複数名でパイプラインを開発している組織で、「誰がどのパイプラインを管理しているのか分からない」「同じような処理が乱立している」といった状態を整理したい場面で活用できます。チーム用フォルダに整理すればアクセス権をまとめて管理でき、Git フォルダを使えば変更履歴とレビューのプロセスを開発フローに組み込めます。
✨ 導入メリット
- パイプラインの所在と管理責任が明確になり、運用の見通しが良くなります
- フォルダ単位でアクセス権を管理でき、権限設定の作業負荷と設定漏れを減らせます
- Git 連携により変更履歴が残り、レビュー文化の定着や監査対応に寄与します
📚 公式ソース
5. BigQuery — 生成 AI 関数の日次トークンクォータ設定機能が復元（2026年8月31日）
BigQuery の 生成 AI 関数（AI.GENERATE_TEXT や AI.CLASSIFY など、SQL から大規模言語モデルを呼び出す関数群）について、日次のトークンクォータを設定する機能が復元されました。トークンとは AI が文章を処理する際の単位で、使用量に応じて課金される仕組みになっています。
🔍 何が変わったのか
- BigQuery の生成 AI 関数向けに、日次トークンクォータを設定する機能が復元されました（不具合修正としてのアナウンスです）
- 公式ドキュメントでは、プロジェクト単位・ユーザー単位で、入力トークンと出力トークンそれぞれに 1 日あたりの上限が設けられていることが案内されています
- クォータは Google Cloud コンソールの「IAM と管理 > 割り当てとシステム上限」ページから、上限の引き上げ申請や利用抑制のための上限設定（オーバーライド）が可能と案内されています
- なお AI.EMBED のような埋め込み・セマンティック検索系の関数は、課金モデルが異なるため対象外と案内されています
💼 こんな場面で活用できます（ユースケース）
生成 AI を使った分析を社内に開放したいデータ基盤担当者が、「想定以上に使われて費用が膨らむ」リスクを抑えたい場面で活用できます。プロジェクト単位・ユーザー単位で 1 日あたりの上限を設定しておけば、特定の利用者や誤った大量実行によって予算を超過する事態を防ぎやすくなります。
✨ 導入メリット
- 生成 AI の利用コストに上限を設けられ、予算管理の予見性が高まります
- 費用面の懸念を抑えられるため、社内展開の意思決定を進めやすくなります
- ユーザー単位の上限設定により、一部の利用が全体に影響を及ぼす事態を避けやすくなります
📚 公式ソース
6. Cloud SQL for PostgreSQL — pgAudit で機密情報のログ出力を抑止できるように（2026年8月31日）
Cloud SQL for PostgreSQL（Google Cloud のマネージド PostgreSQL データベース）の pgAudit 拡張機能（SQL の実行内容を監査ログとして記録するしくみ）で、パスワードなどの機密情報を示す可能性のある文字列が、ログのクエリ結果に出力されるのを防げるようになりました。対象は [PostgreSQL バージョン].R20260712.01_06 以降です。
🔍 何が変わったのか
- pgAudit 拡張機能により、パスワードなどの機密情報を示す可能性のある文字列が、ログのクエリ結果に出力されるのを防止できるようになりました
- 公式ドキュメントでは、cloudsql.pgaudit_mask_literals フラグを使うことで、文字列定数や数値などのリテラル値が位置を示すプレースホルダに置き換えられて記録されると案内されています
- 対象バージョンは [PostgreSQL バージョン].R20260712.01_06 以降です
💼 こんな場面で活用できます（ユースケース）
金融・医療・公共など、監査ログの取得が求められる一方で個人情報の取り扱いに厳しい制約がある業界のデータベース管理者が、「監査要件は満たしつつ、ログ自体が機密情報の漏洩経路にならないようにしたい」という場面で活用できます。監査ログの取得範囲を狭めることなく、記録される値だけを伏せられます。
✨ 導入メリット
- 監査ログを取得しながら機密情報の露出を抑えられ、セキュリティ強化とコンプライアンス対応を両立しやすくなります
- ログの取り扱いに関する運用ルールを簡素化でき、管理負荷を軽減できます
- ログ閲覧権限の設計をシンプルにでき、内部統制の説明がしやすくなります
📚 公式ソース
7. Cloud Trace — トレースシンクの新規作成・編集が不可に（破壊的変更・2026年8月31日）
Cloud Trace（Google Cloud のアプリケーション動作追跡サービス）の トレースシンク（トレースデータを BigQuery へエクスポートするしくみ）について、2026年8月31日より新規作成と編集ができなくなりました。本機能は2026年2月18日付で非推奨（deprecated）となっており、今回その運用上の制限が実施されたかたちです。
本項目は、読者が「自社の構成に影響があるか」を判断する必要があるため、以下の 3 つの観点で整理します。
✨ 使えるようになる機能
- 本項目は提供終了に向けた変更の告知であり、新機能の追加ではありません。公式にハイライトされた新機能はありません
- 移行先として、公式ドキュメントでは Observability Analytics によるトレースデータの SQL 分析、およびリンクされた BigQuery データセットへのクエリが案内されています
⚠️ 使えなくなる機能 / 変更点
- 2026年8月31日より、トレースシンクの新規作成と編集ができなくなりました
- トレースシンクを使った BigQuery へのスパンデータのエクスポートは、2026年2月18日付で非推奨となっています
- 公式ドキュメントでは、エクスポート用のシンクは 2027年2月18日以降に削除されると案内されています（同日にサービス自体が停止する旨も、非推奨告知ページに記載されています）
🤔 判断観点
自組織の利用状況に照らして、以下の観点をご確認いただくとよいでしょう。XIMIX として一律の対応を推奨するものではなく、状況に応じたご判断の材料としてご参照ください。
- 影響範囲: トレースシンクを使って BigQuery へトレースデータをエクスポートしている構成があるか、という確認の観点があります
- 時間的猶予: 新規作成・編集は既に不可となっている一方、サービス停止・シンク削除の期日は2027年2月18日と案内されているため、それまでの期間に移行の検討をどう組み込むかという観点があります
- 移行方式の検討: Observability Analytics での SQL 分析、またはリンクされた BigQuery データセットへのクエリという選択肢のうち、既存の分析ダッシュボードやクエリ資産をどこまで流用できるかという観点があります
- 下流への影響: エクスポートしたトレースデータを参照している BI レポートやアラート設定がある場合、その改修範囲を洗い出す必要があるという観点があります
- 運用体制: 移行作業を担う担当者と検証環境の確保をいつ計画するか、という観点があります
📚 公式ソース
8. Bigtable — 集約カラムファミリーをコンソールから作成・管理できるように（GA・2026年9月1日）
Bigtable（Google Cloud の NoSQL 大規模データベース）の 集約カラムファミリー（aggregate column families。書き込みのたびに合計や最大値などを自動で計算して保持する列のグループ）を、Google Cloud コンソールから作成・管理できるようになりました。Bigtable Studio での参照とクエリにも対応しています。本機能は一般提供（GA）です。
🔍 何が変わったのか
- Google Cloud コンソールから、テーブルの集約カラムファミリーを作成・管理できるようになりました
- Bigtable Studio での参照・クエリにも対応しました
- 公式ドキュメントでは、合計（Sum）・最小値（Minimum）・最大値（Maximum）・HyperLogLog（おおよその件数を推定する方式）といった集約タイプが案内されています
- 本機能は一般提供（GA）です
💼 こんな場面で活用できます（ユースケース）
Web サービスやアプリの運営担当者が、広告の表示回数・コンテンツの閲覧数・週間アクティブユーザー数といった指標をリアルタイムに集計・参照したい場面で活用できます。公式ドキュメントでは、こうした指標を事前の ETL 処理（データの抽出・変換・格納）なしに更新・参照できる用途が案内されています。従来はコマンドやコードで設定する必要があった集約カラムファミリーを、画面操作で扱えるようになりました。
✨ 導入メリット
- 画面操作で設定できるため、集約の導入・変更にかかる作業と学習コストを下げられます
- Bigtable Studio でそのまま参照・クエリでき、確認作業のためにツールを行き来する手間が減ります
- 集計処理を別途組まずに済み、リアルタイム指標の提供までのスピードを高めやすくなります
📚 公式ソース
9. AlloyDB for PostgreSQL — BigQuery へのリアルタイムアクセスに limit pushdown と runtime projects を追加（Preview・2026年9月2日）
AlloyDB for PostgreSQL（Google Cloud の PostgreSQL 互換の高性能データベース）から BigQuery のデータへリアルタイムにアクセスする機能（Preview）に、limit pushdown と runtime projects の 2 つが追加されました。前者は外部テーブルへのクエリの LIMIT 句・OFFSET 句（取得する行数や開始位置を指定する構文）を BigQuery 側で処理させる仕組み、後者はデータの格納先とは別に、クエリ実行とコスト管理を行うプロジェクトを指定できる仕組みです。
🔍 何が変わったのか
- limit pushdown により、外部テーブルへのクエリの LIMIT 句・OFFSET 句を AlloyDB から BigQuery 側へ引き渡して処理させ、ネットワーク転送量とレスポンス時間を改善できるようになりました
- runtime projects により、データを格納しているプロジェクトとは別に、クエリの実行とコスト管理を担うプロジェクトを指定できるようになりました
- 公式ドキュメントでは、runtime project はサーバー単位（関連するすべての外部テーブルに適用）またはテーブル単位で指定できると案内されています
- 本機能（BigQuery へのリアルタイムデータアクセス）は Preview（プレビュー）段階での提供です
💼 こんな場面で活用できます（ユースケース）
業務アプリケーションの画面上で「直近の取引履歴を 20 件だけ表示したい」といった要件を持つ開発担当者が、BigQuery に蓄積した分析データを AlloyDB 経由で参照する場面で活用できます。limit pushdown により必要な行数だけが返るため、画面の表示速度を改善しやすくなります。また runtime projects を使えば、部門ごとにクエリ実行のプロジェクトを分け、コストを部門別に把握するといった運用が取りやすくなります。
✨ 導入メリット
- 不要なデータ転送を減らし、応答時間の短縮とネットワークコストの抑制につながります
- クエリ実行のプロジェクトを分離でき、コストの可視化と部門別の管理がしやすくなります
- 業務データと分析データを ETL なしに突き合わせられ、意思決定スピードの向上に寄与します
📚 公式ソース
10. Looker — OpenJDK 11 のサポートを2027年1月14日で終了（2026年9月2日）
Looker（Google Cloud の BI・データ可視化プラットフォーム）が、OpenJDK 11（Looker の実行基盤となる Java 実行環境のオープンソース版）のサポートを 2027年1月14日 で終了することを告知しました。カスタマーホスト型インスタンス（自社が用意したサーバー上で Looker を稼働させている構成）では、OpenJDK 21 へのアップグレードが必要になります。
本項目は、読者が「自社の構成に影響があるか」を判断する必要があるため、以下の 3 つの観点で整理します。
✨ 使えるようになる機能
- 本項目は非推奨化（サポート終了）の告知であり、新機能の追加ではありません。公式にハイライトされた新機能はありません
- 移行先として OpenJDK 21 が案内されています
⚠️ 使えなくなる機能 / 変更点
- OpenJDK 11 のサポートは2027年1月14日で終了します（該当期日: 2027年1月14日）
- カスタマーホスト型インスタンスは、OpenJDK 21 へのアップグレードが必要です
- Google がホストする Looker インスタンスをご利用の場合、この告知はカスタマーホスト型を対象としたものである点にご留意ください
🤔 判断観点
自組織の利用状況に照らして、以下の観点をご確認いただくとよいでしょう。XIMIX として一律の対応を推奨するものではなく、状況に応じたご判断の材料としてご参照ください。
- 影響範囲: Looker をカスタマーホスト型で運用しているか、その場合に稼働中の OpenJDK バージョンはいくつか、という確認の観点があります
- 時間的猶予: 該当期日は2027年1月14日であり、現時点で即時の影響はないため、年度計画のどこに移行作業を組み込むかという観点があります
- 検証推奨事項: OpenJDK 21 への切り替えに伴い、カスタム可視化・埋め込み利用・外部連携が正常に動作するかを検証する観点があります
- ロールアウト戦略: 検証環境で先行して切り替え、その後に本番環境へ適用する段階的な進め方を検討する観点があります
- 運用方式の見直し: この機会に、Google がホストする Looker（Google Cloud core）への移行を選択肢に含めるかどうかを検討する観点があります
📚 公式ソース
11. Spanner — PostgreSQL 特有の構文で TABLESAMPLE によるランダムサンプリングに対応（2026年9月2日）
Spanner（Google Cloud のグローバル分散リレーショナルデータベース）の PostgreSQL 特有の構文データベース（PostgreSQL の文法で操作できるモード）で、TABLESAMPLE 演算子を使ったデータセットのランダムサンプリング（無作為抽出）に対応しました。
🔍 何が変わったのか
- PostgreSQL 特有の構文のデータベースで TABLESAMPLE 演算子を使用できるようになりました
- これにより、データセットからランダムにサンプルを抽出できます
💼 こんな場面で活用できます（ユースケース）
大量の取引データを扱う分析担当者が、全件をスキャンせずに傾向を素早く確認したい場面で活用できます。また、開発担当者が本番相当のデータ構造を持つ検証用データセットを用意する際、全件をコピーする代わりに一部を無作為に抽出するといった使い方も考えられます。
✨ 導入メリット
- 全件スキャンを避けられるため、探索的な分析の応答時間を短縮できます
- 処理するデータ量を絞れるため、コンピューティングリソースの効率的な利用につながります
- PostgreSQL の標準的な構文で記述でき、既存のスキルをそのまま活かせます
📚 公式ソース
12. BigQuery — 会話型分析がマーケットバスケット分析に対応（GA・2026年9月3日）
BigQuery の 会話型分析（conversational analytics。自然言語でデータに問いかけられる機能）が、マーケットバスケット分析に関する質問をサポートしました。マーケットバスケット分析とは、「一緒に買われやすい商品の組み合わせ」を見つける分析手法で、アソシエーションルール学習とも呼ばれます。本機能は一般提供（GA）です。
🔍 何が変わったのか
- 会話型分析が、マーケットバスケット分析（アソシエーションルール学習）に関する質問をサポートしました
- 公式ドキュメントでは、組み込みの SQL テンプレートが使用され、leverage・support・confidence・lift といった指標を含む結果が返ると案内されています
💼 こんな場面で活用できます（ユースケース）
小売業や EC 事業のマーチャンダイジング担当者が、「どの商品を組み合わせて販売するのが効果的か」を検討する場面で活用できます。公式ドキュメントでは「2025年のデータに基づく最適な商品バンドルの機会」といった問いかけの例が示されています。従来は分析用の SQL を組み立てるか、専門ツールを使う必要がありましたが、自然言語での質問から結果を得られるようになりました。
✨ 導入メリット
- SQL や統計の知識がなくても併売分析を実施でき、施策検討のスピードが上がります
- 組み込みの SQL テンプレートが使われるため、分析ロジックの品質を一定に保ちやすくなります
- クロスセル・バンドル販売の企画に定量的な裏付けを与え、売上向上の打ち手を検討しやすくなります
📚 公式ソース
13. Cloud Storage — Storage batch operations が大幅強化（2026年9月3日）
Cloud Storage（Google Cloud のオブジェクトストレージ）の Storage batch operations（大量のファイルに対する一括処理機能）が大幅に強化されました。Storage Insights データセット（ストレージの利用状況をメタデータとして蓄積するしくみ）のメタデータをもとに、CEL（Common Expression Language。条件を簡潔に記述するための言語）のフィルタで対象オブジェクトを動的に選べるようになったほか、1 つのバッチジョブで最大 1,000 バケットを対象にできるようになりました。
🔍 何が変わったのか
- Storage Insights データセットのメタデータに基づく CEL フィルタで、対象オブジェクトを動的に選択できるようになりました（CSV のマニフェストファイルや BigQuery のエクスポートクエリを用意する必要がありません）
- 1 つのバッチジョブで、最大 1,000 バケットを対象にできるようになりました
- ストレージクラスの一括移行（保存コストの異なる保管階層への一括変更）が可能になりました
- ACL の一括パッチ（アクセス制御リストの一括更新）が可能になりました
- dry run（試験実行）で設定を検証し、そのまま本実行へ移行できるようになりました
💼 こんな場面で活用できます（ユースケース）
データレイクを運用するインフラ担当者が、「1 年以上アクセスされていないファイルを、より安価なストレージクラスへ移したい」といったコスト最適化を進める場面で活用できます。Storage Insights のメタデータを条件にできるため、対象ファイルの一覧を事前に作成する手間が不要です。また、組織再編に伴って多数のバケットのアクセス権を一括で見直す場面でも役立ちます。dry run で影響範囲を確認してから実行できる点も、大規模な変更では重要です。
✨ 導入メリット
- ストレージクラスの一括移行により、保存コストの最適化を実務的な工数で進められます
- マニフェストファイルの作成が不要になり、一括処理の準備工数を大幅に削減できます
- 最大 1,000 バケットを 1 ジョブで扱えるため、大規模環境でも運用を標準化しやすくなります
- dry run で事前検証できるため、誤操作による影響のリスクを抑えられます
📚 公式ソース
14. Cloud SQL — インスタンスのインプレースアップグレード・ダウングレードに対応（MySQL / PostgreSQL / SQL Server・2026年9月4日）
Cloud SQL（Google Cloud のマネージドリレーショナルデータベース）のインスタンスで、インプレースアップグレード・ダウングレード——インスタンスを作り替えずに、その場で構成を変更する方式——に対応しました。変更できるのはエディション、マシンタイプ、ストレージタイプ、データベースバージョンです。MySQL・PostgreSQL・SQL Server の 3 つのエンジンで同日に発表されています。
🔍 何が変わったのか
- インスタンスのエディション（Cloud SQL Enterprise / Enterprise Plus）を変更できるようになりました
- マシンタイプ、ストレージタイプ、データベースバージョンの変更にも対応しました
- 公式ドキュメント（MySQL 版）では、Enterprise から Enterprise Plus へのアップグレードは数分で完了し、ダウンタイムはほぼ発生しないと案内されています。一方、ダウングレードやストレージタイプの変更内容によってはダウンタイムが長くなる場合があると案内されています
- エンジンごとに前提条件や制限が異なるため、公式ドキュメントでの確認が案内されています
💼 こんな場面で活用できます（ユースケース）
本番データベースの性能不足に直面したインフラ担当者が、より上位のエディションやマシンタイプへ移行したい場面で活用できます。従来のように新しいインスタンスを作成してデータを移行し、接続先を切り替えるといった段取りを踏まずに、既存インスタンスのまま構成を変更できます。繁忙期に合わせて構成を上げ、閑散期に戻すといった柔軟な運用も検討しやすくなります。
✨ 導入メリット
- インスタンスの移行作業が不要になり、構成変更にかかる工数とリスクを大幅に削減できます
- Enterprise Plus へのアップグレードはダウンタイムがほぼ発生しないため、業務への影響を抑えて性能を高められます
- 需要に応じて構成を上げ下げしやすくなり、コスト最適化の選択肢が広がります
📚 公式ソース
15. Looker — Semantic Search が一般提供（GA・2026年9月4日）
Looker の Semantic Search（セマンティック検索）が一般提供（GA）になりました。キーワードの一致ではなく、検索した言葉の意味を理解して保存済みコンテンツを探せる、AI を活用した検索機能です。
🔍 何が変わったのか
- Looker の Semantic Search が一般提供（GA）になりました
- 公式ドキュメントでは、キーワード一致を超えて検索クエリの概念的な意味を理解し、「total customer acquisition cost」のようなビジネス寄りの言葉での検索が可能になると案内されています
- 利用にあたっては、Looker 管理パネルの Platform セクションにある「Gemini in Looker」ページで Semantic Search を有効にする必要があると案内されています
💼 こんな場面で活用できます（ユースケース）
ダッシュボードや Look（保存済みの分析結果）が社内に数百件蓄積している組織で、業務担当者が「知りたい数字がどのダッシュボードにあるのか分からない」という状態を解消したい場面で活用できます。作成者が付けた名称を正確に知らなくても、業務で使っている言葉で探し当てられるようになります。
✨ 導入メリット
- 目的のコンテンツを探す時間が短縮され、データを見る習慣の定着につながります
- 既存のダッシュボード資産が見つけられるようになり、同じ分析を重複して作る無駄を減らせます
- 「詳しい人に聞かないと分からない」状態の解消に寄与し、属人化の緩和につながります
�� 公式ソース
16. Looker — Admin Assistant が Preview で提供開始（2026年9月4日）
Looker の Admin Assistant（管理アシスタント）が Preview（プレビュー）で提供開始されました。自然言語で Looker のロール（利用者に与える権限のまとまり）を管理できる機能です。
🔍 何が変わったのか
- 自然言語で Looker のロールを管理できる Admin Assistant が Preview で利用できるようになりました
- 公式ドキュメントでは、ロール・パーミッションセット・モデルセットの検索や新規作成、既存構成の分析とベストプラクティスの提案、利用可能なパーミッションや LookML モデルの一覧表示といった操作に対応すると案内されています
- 利用には Gemini in Looker の有効化や管理パネルでの設定など、いくつかの前提条件があると案内されています
- 本機能は Preview（プレビュー）段階での提供です
💼 こんな場面で活用できます（ユースケース）
Looker の管理者が、部門追加や組織変更に伴って権限設定を見直す場面で活用できます。「特定のパーミッションを含むロールを探す」といった調査を対話的に進められるため、管理画面を何度も行き来する必要が減ります。管理業務の引き継ぎを受けた担当者が、既存の権限構成を把握したいときの助けにもなります。
✨ 導入メリット
- 権限設定の調査・作成を対話的に進められ、管理業務の工数を削減できます
- 既存構成の分析と提案を得られるため、権限設計の見直しに着手しやすくなります
- 管理ノウハウが特定の担当者に依存する状態の緩和に寄与します
- なお Preview 段階の AI 機能であり、公式ドキュメントでも生成された内容を検証してから適用するよう案内されています
📚 公式ソース
その他のアップデート
上記の主要トピック以外にも、この期間には開発ツール・データベース基盤・Looker のリリース情報が発表されています。自組織の利用状況に応じてご確認ください。
BigQuery・データ基盤関連
Cortex Framework 関連
- Cortex Framework — Release 7.0.5（2026年9月1日）: テストから、廃止済みのレビュー項目チェックリストが削除されました。Release notes - September 01, 2026
- Cortex Framework — Release 7.0.6（2026年9月2日）: SAP Data Foundation で論理 SAP テーブルのリマッピング（対応付けの変更）がサポートされ、開発者スキル向けに custom/ ディレクトリのスキャフォールディング（ひな形の自動生成）が追加されました。SAP データの分析基盤を Google Cloud 上に構築している組織に関わる更新です。Release notes - September 02, 2026
Cloud SQL 関連
Looker 関連
- Looker — Looker Mobile（レガシー）アプリの提供が終了（2026年8月31日）: レガシー版の Looker モバイルアプリが App Store / Play Store から入手できなくなり、サポートも終了しました。すでに端末に導入済みの場合は引き続き利用できますが、公式では非レガシー版の Looker モバイルアプリへの切り替えが案内されています。Release notes - August 31, 2026
- Looker 26.16 のロールアウトがスケジュールされました（2026年9月4日）: ロールアウトは2026年9月8日に開始し、9月20日に完了する予定として案内されています。多数の不具合修正が含まれ、iframe 内での Workforce Identity 認証の失敗、ヒストグラム可視化の不具合、アラート作成モーダルの通知方法の表示不具合、埋め込みダッシュボードのフィルタのオーバーフロー、カスタムテーマが適用されない問題、LookML ダッシュボード URL のエンコードの問題、フィルタの編集ができない問題、Word Cloud 可視化でのクラッシュ、PNG ダウンロード時にフィルタやタイムゾーンが保持されない問題、マージクエリのピボットの不具合、ボード上のピン留めした Look の壊れた URL、マルチセレクトフィルタでの検索文字列の残留、ボックスプロット可視化の表示不具合、IAM 管理者の認証失敗などが対象として挙げられています。ご利用中の環境で該当する症状があった場合は、修正内容をご確認ください。Release notes - September 04, 2026 / Looker release notes
まとめ
2026年8月31日〜9月6日のデータ分析カテゴリは、「専門スキルがなくてもデータから答えを引き出せる」方向への進化が目立った週でした。BigQuery の TabFM 対応（Preview） は、モデル学習もハイパーパラメータ調整もなしに予測を試せるという点で、機械学習の導入ハードルを大きく下げる可能性があります。会話型分析のマーケットバスケット分析対応（GA） と Looker の Semantic Search の GA も、現場の担当者が自ら数字にたどり着くための実務的な一手です。
基盤側では、BigQuery Graph の GA、Cloud Storage の Storage batch operations の強化、Cloud SQL のインプレースアップグレード対応が、それぞれ関係性分析・ストレージコスト最適化・データベース運用の柔軟性という異なる課題に応えています。一方で、Cloud Trace のトレースシンクの提供終了（2027年2月18日にサービス停止予定と案内） と Looker の OpenJDK 11 サポート終了（該当期日: 2027年1月14日） は、いずれも即時の影響はないものの、自社の構成を棚卸しし、移行計画をいつ検討するかを見極めておきたい告知です。それぞれ自組織の状況に照らしてご判断いただくとよいでしょう。
関連 XIMIX 記事
Google Cloud アップデート情報をシリーズでご覧になりたい方は、アップデート情報一覧から過去の記事もご確認いただけます。
XIMIX からのご案内
XIMIX（サイミクス）は NI+C が運営する Google Cloud プレミアパートナーサービスです。Google Cloud / Google Workspace の導入・活用支援、データ活用、AI 活用などをご支援しています。本記事で取り上げた BigQuery や Looker、Cloud Storage、Cloud SQL などを活用したデータ基盤の構築・運用にご関心がありましたら、お気軽にご相談ください。
お問い合わせはこちら
参考資料