「BigQueryの認証情報が無効です」が消えない真因と解決4ステップ｜Google Ads Data Manager

Google Ads Data Manager で BigQuery からオフラインコンバージョンを連携していると、ある日いきなりこのエラーに突き当たります。

BigQuery の認証情報が無効です

「認証情報が無効」と書いてあるので、まず接続を削除して作り直す。OAuth を再認証する。それでも消えない。むしろ何度作り直しても同じエラーが返ってくる。ここで多くの人が半日、ひどいときは数日を溶かします。

このエラーには大きな落とし穴があります。「認証情報が無効です」という文言は、実際には別々の原因をひとくくりにした総称で、メッセージそのものからは原因を絞り込めません。そして真因の多くは、あなたの OAuth ではなく、裏で動いている Google 管理のサービスアカウントの権限不足です。

この記事は、「BigQuery の認証情報が無効です」が接続を作り直しても直らない人に向けて、何が本当に起きているのか、どの順番で何を直せば解決するのかを書きます。後半では、こうした広告とデータ基盤をまたぐ権限設計を、自社で持つか外注に回すかの判断材料も置いておきます。

なお、サービスアカウントという用語が何度も出てきます。サービスアカウント（＝人ではなく、プログラムやシステムに発行される Google アカウント）と読み替えてください。人がログインして使うアカウントとは別物、という点だけ押さえておけば後半は読めます。

結論：文言は「認証情報」だが、真因の大半は Google 管理サービスアカウントの権限不足

エラー文言に引っ張られると遠回りします。先に診断の軸だけ示しておきます。

• 「BigQuery の認証情報が無効です」は、OAuth 失敗・権限不足・データ形式エラーをひとまとめにした総称。文言で原因は判断できない
• Data Manager は接続を作ったあなたの OAuth ではなく、Google 管理のサービスアカウントで BigQuery にアクセスしている
• だから接続を削除して作り直しても、そのサービスアカウントの権限は変わらず、エラーも消えない
• 必要な権限は「参照する全 dataset の dataViewer」と「プロジェクトの bigquery.jobUser」の両方

接続の作り直しで消耗する前に、まず疑うべきは Google 管理サービスアカウントの権限です。なぜそう言い切れるのかを、順に解きほぐします。

最大の誤解：「Data Manager は自分の OAuth で動いている」

つまずく人がほぼ全員、最初に立てる仮説はこれです。

接続を作ったときの OAuth トークンが切れたから認証エラーになっている。再認証すれば直るはず。

この仮説が外れています。実際にデータを読みに来ている主体を観測すると、別の正体が見えてきます。

Data Access Log（＝誰がいつどのデータに触れたかを記録する BigQuery の監査ログ）を有効にして、BigQuery への実アクセスを覗いてみました。すると、ビューを読みに来ていたのは接続を作ったユーザーではなく、Google が所有するプロジェクトのサービスアカウントでした。観測した環境では Compute デフォルトサービスアカウントで、形式としては次のようなアドレスです。

<数字>-compute@developer.gserviceaccount.com

環境によっては google-ads-data-manager@... のような別形式のサービスアカウントが使われることもあるため、実際の主体名は必ず自分の Data Access Log で確認してから権限を付与してください。

このサービスアカウントが、30分から2時間ほどの間隔で、自動的に BigQuery のジョブを叩いていました。接続作成者の OAuth 名義でのアクセスは0件。つまり、あなたが再認証しているアカウントは、そもそもこの処理に出てきていないわけです。

整理すると、こうなります。

• もし主体がユーザー OAuth なら、再認証や接続作り直しで直るはず
• 実際の主体は Google 管理サービスアカウントなので、そちらの権限を直さない限り永遠に直らない

「接続を削除して作り直しても認証情報が無効ですが消えない」のは、作り直しても Google 管理サービスアカウントの権限がまったく変わらないからです。直す対象を間違えている、というのがこのエラーの正体になります。

なぜ「権限不足」が「認証情報が無効」と表示されるのか

ここがメッセージ設計の罠です。

サービスアカウントが BigQuery のビューを SELECT しようとして、権限が足りずにジョブが失敗する。すると Google Ads 側の画面は、その「権限不足によるジョブ失敗」を「BigQuery の認証情報が無効です」と表示します。OAuth トークンの失効と権限不足を区別せず、同じ文言にまとめてしまうわけです。

実際に観測した「BigQuery の認証情報が無効です」の真因は、少なくとも4パターンありました。表示はどれも同じです。

文言が4つとも同じなので、画面を眺めていても見分けはつきません。「どの dataset の、どの table で失敗したのか」を Data Access Log で確認しない限り、原因の特定は運任せになります。

必要な権限の全体像：dataViewer と jobUser はセット

Data Manager のサービスアカウントが BigQuery のビューを正常に読むには、2種類の権限が両方そろっている必要があります。片方だけだと、やはり「BigQuery の認証情報が無効です」になります。

① 参照する全 dataset の roles/bigquery.dataViewer

ビューが読むすべての dataset に対して、サービスアカウントへ dataViewer（＝データの中身を見る権限）が要ります。とくに見落とすのが、ビュー定義の中で JOIN している別 dataset です。

たとえばビューがこういう定義だとしましょう。

CREATE OR REPLACE VIEW your_project.analytics_main.conversions AS
SELECT c.*, ad.gclid
FROM your_project.analytics_main.counseling c
INNER JOIN your_project.analytics_ads.click_stats ad  -- ★ 別datasetをJOIN
  ON c.click_id = ad.click_id

このビューを読むには、サービスアカウントは analytics_main だけでなく analytics_ads の dataViewer も必要です。片方しか付与されていないと、JOIN 先の読み取りで失敗します。

ある案件では、稼働中のビューに JOIN を1本足しただけで、5日連続で取り込みが止まりました。クエリは管理画面で問題なく動くのに、Data Manager 経由だけ落ちる。「ビューを変えただけなのになぜ」が起きる典型がこれです。

② プロジェクトの roles/bigquery.jobUser

dataset の dataViewer がすべてそろっていても、プロジェクトに bigquery.jobUser（＝クエリのジョブを実行する権限）が無いと SELECT できません。

ここは混同しやすいので分けて覚えてください。dataViewer は「データを見る権限」、jobUser は「クエリのジョブを動かす権限」。BigQuery ではこの2つが別の概念で、両方そろわないとビューは読めない仕組みになっています。

dataViewer は全 dataset そろっているのに止まり続ける、という状況に陥ったことがあります。原因を追ったら、欠けていたのは jobUser でした。dataViewer だけ追いかけていると、まず見つかりません。

解決4ステップ

直す順番が決まっています。推測で動くと作り直しの無限ループに入るので、Data Access Log で主体と失敗箇所を確定させてから手を入れます。

ステップ1：Data Access Log を有効化して、失敗している dataset を特定する

まず、サービスアカウントがどの dataset、どの table の読み取りで失敗しているかを観測します。BigQuery の Data Access Log（ADMIN_READ / DATA_READ / DATA_WRITE）を有効にしてください。

# 現在の監査ログ設定を確認
gcloud projects get-iam-policy your_project --format=json | python3 -c "
import json,sys
for a in json.load(sys.stdin).get('auditConfigs', []):
    print(a)
"

ログを読むと、サービスアカウントがどこへのアクセスで弾かれているかが見えます。「認証情報が無効です」がどの dataset 由来なのか、ここで初めて確定します。

ステップ2：必要な dataset に dataViewer を付与する

ビューが JOIN や FROM で読むすべての dataset に、サービスアカウントの dataViewer を付けます。

SA="<数字>-compute@developer.gserviceaccount.com"
for ds in analytics_main analytics_ads analytics_calls; do
  bq show --format=prettyjson your_project:$ds > /tmp/$ds.json
  # access[] に追加:
  #   {"role": "roles/bigquery.dataViewer", "userByEmail": "<SA>"}
  bq update --source /tmp/$ds.json your_project:$ds
done

dataset レベルの ACL（＝アクセス権の設定）はおおむね即時から数分で効きます。

ステップ3：プロジェクトに jobUser を付与する

gcloud projects add-iam-policy-binding your_project \
  --member="serviceAccount:<数字>-compute@developer.gserviceaccount.com" \
  --role="roles/bigquery.jobUser"

dataViewer を全部そろえたのに止まる場合、欠けているのはたいていこれです。ステップ2とステップ3はセットで確認してください。

ステップ4：翌日のスケジュール実行で疎通を確認する

Data Manager は数十分から数時間の間隔で自動リトライします。権限を付与しておけば、次の実行サイクルで自然に復旧します。すぐ手動で何かを叩く必要はありません。

復旧したかどうかは、Google Ads 管理画面の「コンバージョン > 診断」タブで確認できます。影響を受けた conversion action と、最終アップロード日を見れば、再び取り込めているかが分かる。翌日のスケジュール実行が通っていれば疎通完了です。

副次の落とし穴：日付フォーマットとクリック期間

権限以外でも、Data Manager の診断画面には警告が出ます。よく遭遇する2つを補足しておきます。どちらも、エラー文言と実態がズレている点では同じ。

「無効な日付 - 日付が遅すぎます」

ビューの conversion_date_time が TIMESTAMP 型のまま（タイムゾーンのオフセットなし）だと出ます。Google 広告のオフライン CV では、conversion_date_time はオフセット付きの文字列が必須です。

FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S+09:00', ts, 'Asia/Tokyo') AS conversion_date_time

「IDが古すぎます」

クリックスルーコンバージョンの計測期間より前のクリックを送ろうとすると出るエラーだ。問い合わせから成約までのラグが長い業種、たとえば検討期間が数週間から数か月に及ぶサービスでは、Google 広告側の計測期間を延ばす必要があります。広告クリックから成約までをつなぐ計測の全体像は、広告クリックから成約までを計測するパイプラインの設計で別途整理しています。

ここまでが、目の前の「BigQuery の認証情報が無効です」を消すための話。ここからは、このトラブルを二度起こさないための運用と、そもそもこの権限設計を内製で抱えるか外注に出すかの判断材料に移ります。

ビュー変更時のチェックリスト（再発を防ぐ）

このエラーの再発は、ほぼ「ビューを変えたとき」に集中します。Data Manager 用のビューを CREATE OR REPLACE する前に、毎回この3点を確認するだけで、5日間の取り込み停止のような事故はほぼ防げます。広告運用を外注している場合は、そのまま外注先への確認項目としても使える。

3番目の impersonate（＝サービスアカウントになりすまして実行する仕組み）での事前テストは少し手間ですが、本番のスケジュール実行が止まってから気づくより圧倒的に早く済みます。「ビューを変えるときは、新しく読む dataset の権限を先に付ける」を運用ルールにしてしまうのが、いちばん確実です。

この権限設計、自社で持つか外注に回すか

オフライン CV と BigQuery の連携は、一度組んでしまえば月々の運用費はほとんどかかりません。判断が割れるのは、止まったときに誰が直すか、ビューを変えるたびの権限管理を誰が見るか、という運用の部分です。安さではなく、運用責任とリスクの軸で考えてください。

判断の分かれ目は、結局「止まったとき自力でログから真因を切り分けられるか」に集約されます。この記事のような診断を社内でできるなら自社運用で問題ありません。「認証情報が無効」を見て接続を作り直す対応しか出てこないなら、その都度数日の停止と取りこぼしが発生するので、設計と監視を外に持つほうが安く済むことが多いです。

この連携を無理に内製しなくていいケース

正直なところ、何でも自社で抱えればいいわけではありません。次のような場合は、内製にこだわらないほうが結果的に安全です。

• オフライン CV の件数が少なく、数日止まっても広告判断に響かない規模。手間に対して得るものが小さい
• BigQuery 自体をこの連携のためだけに使っていて、社内に IAM やビューを継続して見る人がいない。組んだ本人が抜けると誰も直せなくなる
• 広告データ基盤の設計がまだ固まっておらず、ビューや dataset 構成が今後も大きく動く見込み。権限まわりの事故が頻発しやすい

逆に、オフライン CV が広告予算の配分に直結していて、ビューも継続的に育てていく方針なら、権限設計ごと内製で握る価値は十分にあります。

まとめ：エラー文言を信じず、ログで主体と失敗箇所を見る

Google Ads Data Manager の「BigQuery の認証情報が無効です」は、OAuth 失敗・権限不足・データ形式エラーをひとくくりにした総称です。文言だけで判断すると、接続の作り直しを繰り返して消耗します。

正しい順番はこうなります。

1. Data Access Log で、実際のアクセス主体（Google 管理サービスアカウント）と失敗箇所を特定する
2. ビューが JOIN で読む全 dataset に、そのサービスアカウントの dataViewer を付与する
3. プロジェクトに jobUser を付与する。dataViewer とセットで確認する
4. ビューを変更するときは、新しく読む dataset の権限を先に付ける

「BigQuery の認証情報が無効です」と言われたら、まず疑うのは自分の OAuth ではなく、Google 管理サービスアカウントの権限。この順序を知っているだけで、作り直しの無限ループから抜け出せます。

広告データ連携・オフラインCV設計でお困りなら

「連携が止まったのに、代理店も社内も原因が分からない」。Google 広告のオフライン CV を BigQuery から連携していると、権限モデル・ビュー構造・日付フォーマットなど、ドキュメントに書かれていない落とし穴で止まる相談をよくいただきます。エラー文言は「認証情報が無効」でも、真因は権限設計だった、というケースがほとんどです。

f2t.jp では、広告データ基盤の設計から、こうした連携トラブルの診断・恒久対策、ビュー変更時の権限運用ルールづくりまで一貫してお手伝いしています。まずは「どこで止まっているか・ビュー構成・誰が権限を持っているか」を一緒に切り分けるところから始められます。お問い合わせフォームからご相談ください。