[2025年7月21日から]BigQueryのスケジュールされたクエリについてオーナー以外が更新する際の仕様が変更されます

[2025年7月21日から]BigQueryのスケジュールされたクエリについてオーナー以外が更新する際の仕様が変更されます

Clock Icon2025.05.08

4月末ごろに配信されたGoogleからのメール[推奨処理] 2025 年 7 月 21 日までに、BigQuery のスケジュールされたクエリの更新ワークフローをご確認ください / [Action Advised] Review your BigQuery scheduled query update workflows before July 21, 2025について要点や対応方法についてまとめてみました。

概要

  • 2025年7月21日以降、スケジュールされたクエリのオーナー限定フィールド(SQLテキストや宛先テーブル/データセットなど)を更新するには、原則としてそのクエリのオーナーであるか、サービスアカウントを使用することが求められるようになります
    • この変更は、セキュリティを強化し、認証情報の不正使用を防止するためとのことです。
  • APIやCLIでスケジュールされたクエリのオーナー以外のユーザーがこれらのフィールドを変更しようとすると、PERMISSION_DENIED エラーが発生するようになります

オーナーとは
メールに記載のオーナーとは、スケジュールされたクエリを作成(更新)するときに設定する認証情報(サービスアカウントまたは作成したユーザ)を指しています。
スクリーンショット 2025-05-07 20.57.21.png
スクリーンショット 2025-05-07 21.00.02.png

明示的にサービスアカウントを指定している場合は、問題ありませんがオーナーにユーザが設定されている場合は今回の変更の影響を受ける可能性があります。

影響を受けるユースケース

APIやCLIでスケジュールされたクエリのSQL本文や宛先データセットなどを更新している場合

  • APIやCLI(bq update --transfer_config コマンドなど)を利用してスケジュールされたクエリを更新する自動化スクリプトがある場合、そのスクリプトがどの認証情報で実行されているか確認が必要です。オーナー・サービスアカウント以外のユーザの認証情報で実行されている場合、2025年7月21日以降はエラーになる可能性があります。スクリプトをサービスアカウントで実行している場合、またはスクリプトをオーナーの認証情報で実行されている場合・手動操作でオーナー自身がSQLなどを更新する場合は問題ないようです。
ユースケース 説明 影響の有無 対応方法
1. スケジュールされたクエリの更新をオーナー以外のユーザーがAPI/CLIで実行している bq update --transfer_configprojects.locations.transferConfigs.patch を使用して、SQLや宛先データセットを更新している 影響あり 2025年7月21日以降、PERMISSION_DENIED エラーが発生 スクリプトをオーナーの認証情報またはサービスアカウントで実行するように変更。または認証情報の更新をスクリプトないで実施
2. スケジュールされたクエリのオーナーがサービスアカウントになっている 作成時にサービスアカウントを指定している 影響なし 現状維持でOK
3. UIから手動でスケジュールされたクエリを更新しようとするが、オーナーではない BigQuery UIでSQLや宛先を変更しようとする 影響あり。「認証情報の更新」が求められる UI上で「認証情報を更新」ボタンを使用して、オーナーまたはサービスアカウントに切り替える
4. スケジュールされたクエリのSQLや宛先を更新しない クエリの内容を変更しない運用 影響なし 特に対応不要。ただし将来的な変更に備えてオーナーの確認は推奨
5. スケジュールされたクエリを新規作成する 2025年5月19日以降に作成されたプロジェクトでの新規作成 影響あり。即座に新仕様が適用される 作成時にサービスアカウントを明示的に指定することを推奨

確認観点:

  1. 影響を受ける可能性のあるスケジュールされたクエリの特定
    • 現在、スケジュールされたクエリの オーナー を確認してサービスアカウント以外のユーザが設定されていないか確認
    • スケジュールされたクエリを実行するスクリプトがSQLや宛先テーブル/データセットを更新するような運用になっていないか確認(なっている場合はオーナーを要確認)
    • オーナーは、Google Cloudコンソールの [BigQuery] -> [データ転送] (または古いUIでは [スケジュールされたクエリ]) を開き、該当の転送設定の [構成] タブのユーザにて確認
      • または後述のスケジュールされたクエリに設定されているオーナー(ユーザ(認証情報))の一覧取得スクリプトを実行
  2. 自動化スクリプト/アプリケーションの確認
    • APIやCLI(bq update --transfer_config コマンドなど)を利用してスケジュールされたクエリを更新する自動化スクリプトがある場合、そのスクリプトがどの認証情報で実行されているか確認が必要です。オーナー以外の認証情報で実行されている場合、2025年7月21日以降はエラーになる可能性があります。
  3. 該当するスケジュールされたクエリの更新の検討
    • サービスアカウントの使用を検討: サービスアカウントを使用するようにスケジュールされたクエリ構成を変更することが推奨されています。これが最も安全で柔軟なアプローチとのことです。
      • スケジュールされたクエリを実行するサービスアカウントに必要なIAMロール(例: BigQuery データ編集者, BigQuery ジョブユーザーなど、および転送設定の更新権限)が付与されているか確認しましょう。
    • オーナーによる更新/認証情報の更新: オーナー自身がサービスアカウントへの更新作業を行うか、API・CLIなどのスクリプトを実行するユーザがオーナーとなる様にスケジュールされたクエリを再認証します

タイムライン:

  • 2025年4月23日~2025年7月21日:
    • 2025年5月19日より前に作成された既存プロジェクト : 一時的に以前の動作が保持されます(許可リスト状態)
    • 2025年5月19日以降に作成された新規プロジェクト : 本仕様がすぐに適用されます
  • 2025年7月21日以降: 新しい動作がすべてのプロジェクトに適用されます

スケジュールされたクエリに設定されているオーナー(ユーザ(認証情報))の一覧取得

指定したプロジェクト・リージョンのスケジュールされたクエリでだれがオーナーなのか・サービスアカウントが紐づいているかを出力するスクリプトを作成してみました。

#!/bin/bash

PROJECT_ID="プロジェクトID"
TRANSFER_LOCATION="リージョン" #asia-northeast1"

CONFIG_IDS=$(bq ls --transfer_config --project_id=${PROJECT_ID} --transfer_location=${TRANSFER_LOCATION} | awk 'NR>2 {print $1}')

echo "transfer_config_id,display_name,owner_email,destinationDatasetId,query"

for FULL_ID in $CONFIG_IDS; do
  INFO=$(bq show --format=prettyjson --transfer_config "${FULL_ID}")
  DISPLAY_NAME=$(echo "$INFO" | jq -r '.displayName')
  OWNER_EMAIL=$(echo "$INFO" | jq -r '.ownerInfo.email // empty')
  DEST_DATASET=$(echo "$INFO" | jq -r '.destinationDatasetId')
  QUERY=$(echo "$INFO" | jq -r '.params.query' | tr '\n' ' ' | tr -d '\r' | cut -c1-100)
  echo "${FULL_ID},${DISPLAY_NAME},${OWNER_EMAIL},${DEST_DATASET},\"${QUERY}\""
done

上記を実行すると以下のような出力がされます。owner_emailにGoogleアカウントまたはサービスアカウントのメールアドレスが出力されるのでここを元にだれがオーナーなのか・サービスアカウントを紐付けているか判断できると思います。SQLは参考として出しています(100文字まで)

transfer_config_id(クエリID) display_name(表示名) owner_email(オーナー(クエリを所有している人のメールアドレス)) destinationDatasetId(宛先データセット) query(SQL)
projects/project-number/locations/asia-northeast1/transferConfigs/66d58b7c-0000-2ea8-baac-c82add6fba98 test1 Googleアカウントのメールアドレス データセット名 SELECT 1
projects/project-number/locations/asia-northeast1/transferConfigs/678d0315-0000-21b8-b822-34c7e93d57f7 mysql-dts-test サービスアカウントのメールアドレス データセット名 null

所感

スケジュールされたクエリのSQLや宛先データセットなどを更新するスクリプトなどを運用していて、かつオーナーにサービスアカウント以外のユーザアカウントを設定している場合は要対応となりそうです。
基本的に、本番環境ではサービスアカウントを設定していると思いますがこれをきっかけに今一度スケジュールされたクエリにサービスアカウントが設定されているか確認するのも良いなと思いました。

Googleからのメール(抜粋)

主な変更点:

2025 年 7 月 21 日以降、既存のスケジュールされたクエリの「オーナー限定フィールド」(クエリの SQL テキストや宛先テーブル / データセットなど)を更新するユーザーには、そのクエリのオーナーであること、またはサービス アカウントを使用することが求められます。スケジュールされたクエリの設定は、サービス アカウントを使用して行えます。スケジュールされたクエリの現在のオーナーは、スケジュールされたクエリの詳細ページの [構成] タブで確認できます。

BigQuery UI の [編集] または [スケジュールされたクエリを更新] 機能を使用して、スケジュールされたクエリを編集しようとするユーザーがそのクエリを所有していない場合は、認証情報を更新するか、サービス アカウントを選択する必要があります。

API または CLI の利用においては、認証情報が更新されていない、またはサービス アカウントが使用されていない場合、オーナー以外のユーザーが次の API またはコマンドを使用してフィールドを変更しようとすると、PERMISSION_DENIED エラーが表示されます。

projects.locations.transferConfigs.patch API
bq update --transfer_config コマンド
可能性のある影響:

スケジュールされたクエリのクエリテキストまたは宛先テーブル / データセットを現在のオーナー以外のユーザーが更新する処理が現在のプロセスに含まれている場合、そうしたプロセスは 2025 年 7 月 21 日より後は失敗する可能性があります。

API / CLI を使用する自動化スクリプトやアプリケーションが機能しなくなる可能性があります。
UI を介した手動更新で、明示的な認証情報更新の手順が必要になります。
ご対応のお願い
推奨処理:

適用日までに、スケジュールされたクエリの更新ワークフローを確認することをおすすめします。

スケジュールされたクエリのうち、オーナー以外のユーザーがクエリテキストや宛先テーブル / データセットを更新することが必要になる可能性があるものを特定します。
スケジュールされたクエリのオーナーは、Google Cloud コンソールの [構成] タブ([BigQuery] -> [パイプラインと統合] -> [データ転送(または [スケジュールされたクエリ]))で確認できます。
更新戦略を選択します。
サービス アカウントを使用するように、スケジュールされたクエリ構成を変更します。一般的に、これはチームのコラボレーションにとって最も安全で柔軟なアプローチです。
制限付きフィールドを変更する際に、認証情報を更新するユーザー / スクリプトを準備します。UI を介する場合は [認証情報を更新] ボタン、API / CLI を介する場合は特定のパラメータを使用して、認証情報を更新できます。
オーナー アクセス権を取得する必要がある場合は、こちらの手順に沿って操作します。
タイムライン:

2025 年 4 月 23 日:このお知らせが送信され、ロールアウトが段階的に開始されます。
2025 年 4 月 23 日~2025 年 7 月 21 日:
2025 年 5 月 19 日より前に作成された既存のプロジェクトは、一時的に以前の動作が保持されます(許可リストに登録された状態)。
2025 年 5 月 19 日以降に作成された新規プロジェクトには、新しい厳格な動作がすぐに適用されます。
2025 年 7 月 21 日より後: 新しい動作がすべてのプロジェクトに適用されます。既存のプロジェクトの許可リストは削除されます。サービスの中断を避けるため、この日付までにご対応いただく必要がございます。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.