BigQuery（Google Cloudのデータ分析基盤）を2010年代から使い、当時書いたレガシーSQLのバッチや帳票をそのまま動かしている日本企業のデータ基盤担当に、見落としやすい期限が来ている。複数の事業部がそれぞれのプロジェクトで集計処理を持ち、年に一度しか動かない決算関連の処理を抱える企業ほど危うい。
Googleは、2025年11月1日から2026年6月1日までを評価期間とし、その間にレガシーSQL（BigQuery初期のSQL方言）を使わなかった組織とプロジェクトでは、期間終了後にレガシーSQLを使えなくする仕組みを導入した[1]。使っていた組織でも、残るのは期間中に実際に使った機能だけだ[1]。
つまり、評価期間中に一度も動かなかった処理は、次に動いた日に失敗する可能性がある。本稿は公式ドキュメントをもとに、どの単位で機能が残るのか、どう棚卸しするのかを整理する。
予備知識
- レガシーSQL: BigQueryが当初採用していた独自のSQL方言。現在の標準はGoogleSQL
- GoogleSQL: ANSI標準に準拠したBigQueryの推奨SQL方言。DMLやDDL、共通テーブル式などが使える
- 組織: Google Cloudで複数のプロジェクトを束ねる最上位の単位。会社全体を1つの組織にすることが多い
- INFORMATION_SCHEMA.JOBS: BigQueryで実行されたジョブの履歴を、SQLで検索できるシステムビュー
BigQueryを中心にした分析基盤の全体像を、構築の流れに沿って確認したい担当者に向く。
何が制限されたのか——使われた機能だけが残る仕組み
今回の制限は、廃止ではなく「使われなかった機能の停止」だ。BigQueryは評価期間中のレガシーSQLの利用を監視し、使わなかった組織とプロジェクトでは、6月1日の期間終了後にレガシーSQLそのものが使えなくなる[1]。
使っていた組織では、期間中に使った機能セットに限って引き続き使える[1]。判定は組織単位で集計され、どれか1つのプロジェクトが使った機能は、同じ組織の全プロジェクトで使える[1]。組織に属さないプロジェクトは、プロジェクト単位で判定される[1]。
レガシーSQLの処理をGoogleSQLへ書き換える前に、GoogleSQLの基本構文を手を動かして確かめられる。
どの単位で判定されるのか——基本機能、拡張機能、関数グループ
判定の単位は3種類ある[1]。基本機能は、SELECT、JOIN、WHERE、GROUP BYなどの中核の構文で、評価期間中にレガシーSQLのクエリを1本でも実行していれば全体が残る[1]。
拡張機能は、1つずつ個別に判定される[1]。論理ビュー、テーブルデコレータ（時間や範囲を指定して過去の状態を読む書き方）、ユーザー定義関数、TABLE_DATE_RANGEなどのワイルドカード関数、FLATTENなど16項目がこれにあたる[1]。関数は25のグループに分かれ、グループ内の関数を1つでも使えば、そのグループ全体が残る[1]。
ここで注意したいのは拡張機能だ。論理ビューもこの中に入り、判定は組織単位で行われる。組織内でレガシーSQLのビューが評価期間中に1本も参照されていなければ、どのレガシーSQLのビューも失敗する可能性がある。日付ごとに分割したテーブルをTABLE_DATE_RANGEで束ねる書き方も、古い集計処理でよく使われていた。
拡張機能のうち、古い処理で使われやすいものを挙げる[1]。
| 拡張機能 | どんな書き方か | 古い処理での典型的な使われ方 |
|---|---|---|
| 論理ビュー | レガシーSQLで定義したビュー | 帳票やBIツールの参照先 |
| テーブルデコレータ（時間） | 過去の時点のテーブルを読む | 誤削除時の復元や差分確認 |
| TABLE_DATE_RANGE | 日付別テーブルを期間でまとめて読む | 日次に分割したログの月次集計 |
| GROUP BY EACH／JOIN EACH | 大きな集計や結合の指定 | 大量データの夜間バッチ |
| ユーザー定義関数 | JavaScriptで独自関数を定義 | 独自の変換ロジック |
どれも、10年近く前に作られた処理ほど残っている可能性が高い書き方だ。
公式ドキュメントの例では、SIN関数を使ったことで数学関数グループ全体が残り、COS関数も使える。一方、統計の集計関数グループを誰も使っていなければ、STDDEVを使うクエリは期間後に失敗する[1]。
Google CloudのメタデータカタログサービスであるData Catalog（テーブルやファイルを横断検索し、タグで分類情報を付けるサービス）は、2026年6月1日から段階的なシャットダウンに入っている[1][2]。後継は、同年4月[…]
自社の利用状況をどう確かめるか
特定の機能の利用状況を監査する専用ツールはない[1]。公式ドキュメントが示す手段は、INFORMATION_SCHEMA.JOBSでレガシーSQLのジョブ数を数える方法と、Cloud Loggingのクエリログで構文を確かめる方法の二つだ[1]。
プロジェクトごとのレガシーSQLのジョブ数は、次のクエリで確認できる[2]。REGION_NAMEは自社のリージョンに置き換える。
SELECT
project_id,
COUNTIF(query_dialect = 'DEFAULT_LEGACY_SQL') AS default_legacysql_query_jobs,
COUNTIF(query_dialect = 'LEGACY_SQL') AS legacysql_query_jobs,
FROM
`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
query_dialect = 'DEFAULT_LEGACY_SQL'
OR query_dialect = 'LEGACY_SQL'
GROUP BY
project_id
ORDER BY
default_legacysql_query_jobs DESC,
legacysql_query_jobs DESC;
DEFAULT_LEGACY_SQLは、方言を指定しないまま既定値のレガシーSQLで実行されたジョブを指す[2]。本人が意識しないままレガシーSQLで動いている処理を見つける手がかりになる。
評価期間中に動かせなかった処理は、例外を申請できる[1]。申請はGoogleのフォームで行い、使えない場合はbq-legacysql-support@google.comへ、組織ID、現在の利用量、直近の利用日、移行の課題、GoogleSQLへの移行見込み時期を送る[1]。
Google CloudのCloud Runで、Node.js 20ランタイム（ランタイムID nodejs20）が2026年10月30日に廃止される[1]。廃止日を過ぎると、このランタイムでは新しいワークロードの作成も既存ワークロードの[…]
決算期の処理を抱える日本企業で起きやすい事故
同じ制限は日本企業にも一律に適用されるが、事故の起き方には日本特有の偏りがある。評価期間の2025年11月から2026年6月までに、年に一度か半年に一度しか動かない処理が入っていたかどうかが分かれ目になる。
| 観点 | 海外で想定される状況 | 日本企業で起きやすいこと |
|---|---|---|
| 処理の頻度 | 日次・週次の分析が中心 | 中間決算や年次の帳票など、年1〜2回の処理が残る |
| 処理の作り手 | 社内のデータチーム | 構築したSIerや退職者。レガシーSQLだと認識されていない |
| 組織の構成 | 1つの組織に集約 | 事業部やグループ会社ごとに組織やプロジェクトが分かれる |
| 変更の手続き | 気づいた人がすぐ修正 | 帳票の改修は変更管理の承認と再テストが必要 |
たとえば9月末の中間決算後、10月にだけ動く集計処理は評価期間の外にある。その処理だけが使う拡張機能や関数グループがあれば、今年の10月に初めて失敗が表に出る。組織を事業部ごとに分けている企業では、他部門の利用実績に頼れない点も不利に働く。
移行先のGoogleSQLには利点もある。公式ドキュメントは、高度な実行エンジンによる費用対効果の改善と、DMLやDDL、共通テーブル式、マテリアライズドビュー、検索インデックス、生成AI関数といったレガシーSQLにない機能を挙げている[1]。書き換えを単なる後始末ではなく、処理の見直しの機会として説明できれば、稟議も通しやすくなる。
IT部門の判断としては、年次・半期の処理を優先してレガシーSQLの利用を洗い出し、GoogleSQLへ書き換えるか例外を申請するかを処理ごとに決める。決裁側の判断としては、書き換えと再テストの工数を今期の予算で認めるかどうかを決める。
SnowflakeとBigQueryを事業部ごとに使い分け、両者をまたぐデータ統合基盤の刷新を検討している数千人規模企業のデータ基盤担当者は、部門横断の分析を行うたびにETL（Extract-Transform-Load、データを抽出・変[…]
まとめ
BigQueryのレガシーSQLは、評価期間中に使われた機能だけが残る仕組みに変わった。拡張機能は16項目が個別に判定され、論理ビューもその中に含まれる。評価期間の外でしか動かない処理は、次に動いた日に失敗する可能性がある。
IT部門の次の一手は、INFORMATION_SCHEMA.JOBSでレガシーSQLのジョブを洗い出し、年次・半期の処理を特定することだ。決裁側の判断材料は、書き換えの工数と、例外申請で稼げる時間、決算処理が止まった場合の業務影響の三点になる。
移行は必須ではないとされるが、使える機能が固定された以上、レガシーSQLに新しい処理を足す理由はもうない。
よくある質問（FAQ）
Q. レガシーSQLは完全に廃止されたのですか。
A. 廃止ではない。評価期間中に使われた機能は、その組織で引き続き使える。
Q. 新しく作ったプロジェクトでもレガシーSQLは使えますか。
A. 評価期間中に組織内で使われた機能なら、新しいプロジェクトでも使える。
Q. GoogleSQLへの移行は必須ですか。
A. 公式ドキュメントでは必須ではないが推奨とされている。
出典
[1] Google Cloud Documentation「Legacy SQL feature availability」（2026-09-24更新） https://docs.cloud.google.com/bigquery/docs/legacy-sql-feature-availability[2] Google Cloud Documentation「JOBS view」（Legacy sql query jobs count per project） https://docs.cloud.google.com/bigquery/docs/information-schema-jobs
