広告レポートの連携エラー対応｜欠損したまま納品しない運用

広告レポートの連携エラーに気づいたら、表示中の数値をそのまま納品せず、まず通常納品を止めます。取得成功時刻・最終対象日・行数・空欄理由を一つの確認表にそろえ、欠損の疑いが消えた場合だけ通常納品へ戻すのが安全です。疑いが残る場合は、再取得、原因調査、注記付きの暫定報告、納品保留のいずれかに振り分けます。

最終更新の表示だけでは判断材料が足りません。更新日時が見えていても、現在の条件でデータが取り直されているとは限らないからです。では、どの状態なら「欠損なし」と扱えるのか。対象期間のデータがそろった証拠を確認する必要があります。

広告レポートの連携エラーを欠損の有無で判定する

レポートが表示されることと、納品対象のデータがそろっていることは別です。2026年9月21日時点のGoogle Cloud公式資料では、Looker Studioのレポート左下に最終データ更新日時が表示される一方、その日時が現在の表示条件を変更した時刻より前であれば、ページ上の全グラフはメモリから配信されると説明されています（Manage data freshness）。したがって、画面が表示され、最終更新日時が記載されているという理由だけで納品可能とは判断できません。

確認の焦点は、納品範囲に欠損があるかです。連携処理が成功したこと、必要な最終日まで含まれること、明細が不自然に欠けていないこと、空欄に説明できる理由があることを別々に見ます。「更新済み」という表示だけを見ると、接続は成功したものの対象日が足りない状態や、行は取得できたものの値が理由不明で空欄になった状態を見落とします。

連携前の設計を整理したい場合は、広告レポート自動化の進め方も参照できます。ただし、自動化済みであっても納品前の欠損判定は残します。

最初にそろえる4項目

以下の4項目は、代理店が納品可否をそろえて判断するための運用上の提案です。公式製品の仕様を表すものではありません。案件ごとの確認結果を同じ表へ記録します。

• 取得成功時刻：担当者が、対象データの取得成功を確認した時刻。単にレポートを開いた時刻とは分ける。
• 最終対象日：取得済みデータに実際に含まれる最後の日。依頼された集計期間の末尾と照合する。
• 行数：同じ抽出条件で得られた明細の行数。空欄や対象日の欠落を探す入口として使う。
• 空欄理由：空欄が媒体仕様、集計条件、未取得、権限問題などのどれに当たるか。確認できなければ「理由不明」のまま残す。

4項目にはそれぞれ異なる役割があります。取得成功時刻が新しくても、最終対象日が不足していれば納品範囲はそろいません。行数に違和感がなくても、納品上重要な欄だけが空いている可能性があります。理由と影響範囲を確認できた空欄は、接続障害と直ちに断定せず、仕様や集計条件も含めて扱いを決めます。

ここでいう行数確認は、全案件に共通の正常値や減少率を置く方法ではありません。同じ対象期間・媒体・アカウント・抽出条件で比較できる状態を用意し、差が出た箇所を調べるための手掛かりにします。根拠のない閾値で自動判定せず、最終対象日と空欄理由を合わせて読みます。

欠損判定と暫定報告の判断表

次の表も運用上の提案です。4項目の組み合わせごとに、再取得、原因調査、暫定報告、通常納品のどこへ進むかを固定します。

「通常納品しない」は、欠損の可能性を伏せた完成版として渡さないという区分です。報告自体を止めるかは欠損の影響で決めます。クライアントの判断に必要な範囲が欠けているなら納品を保留し、取得済み範囲を共有する必要があるなら暫定報告へ切り替えます。公開・納品の最終判断は担当者が行います。

手動更新で直らなければ鮮度と接続を分ける

2026年9月21日時点の公式資料では、Looker Studioのレポート編集者はいつでもデータを手動更新でき、その操作によりレポート内の全データソース、または更新対象コンポーネントのデータ鮮度がリセットされます。閲覧者が手動更新できるのは、レポート設定で許可されている場合に限られます（Manage data freshness）。そのため、まず編集権限を持つ担当者が更新し、同じ4項目を取り直します。

手動更新の実行後は、最終対象日が伸びたか、行数の差が解消したか、理由不明の空欄が消えたかまで確認します。4項目に変化がなければ接続側の調査へ移り、データ鮮度だけに原因を絞り込まないようにします。

確認順は次のように分けると、同じ操作の繰り返しを避けられます。

• データソースが意図した接続先か、削除や設定変更がないかを確認する。
• フィールド構成と抽出条件を確認し、必要に応じて更新や再接続を検討する。
• 認証情報の主体と、対象データへのアクセス権を確認する。
• 別のデータソースで接続可否を切り分け、再追加が必要か判断する。

2026年9月21日時点のGoogle Cloud公式トラブルシューティングでは、接続エラーの原因例として認証情報の欠落、設定破損、データソース削除、アクセス権の失効が挙げられています。対処手順としては、正しいデータソースの追加、フィールド更新、再接続、データソースの再追加、新規データソースでの接続確認、Googleアカウントへのアクセス権の取り消しと復元などが案内されています（Troubleshoot errors in Data Studio）。これは原因と対処の例であり、すべてを毎回実行する必須手順ではありません。確認結果に対応する操作を選びます。

認証情報は「誰の権限で見るか」まで確認する

空欄や取得停止が続くときは、ログインの可否に加え、どの認証情報がデータアクセスを承認しているかを確認します。2026年9月21日時点の公式資料では、データ認証情報はデータソースを誰が閲覧できるかを決める仕組みであり、オーナー、閲覧者、サービスアカウントの各認証情報では、アクセスを承認する主体が異なると説明されています（Data credentials）。

担当者の画面でデータが見えても、納品用レポートの全閲覧者が同じデータを閲覧できるとは限りません。確認表には、空欄理由とともに「どの認証主体で確認したか」を補足します。この記録は空欄理由を確定する材料として使い、4項目の確認も続けます。

ツール選定や接続方式から見直す段階では、広告レポート自動化ツールの選び方を確認し、現在の運用で誰が接続を保守するかも整理しておきます。

固定の更新間隔を障害と取り違えない

未反映が見つかっても、ただちに連携障害とは断定しません。2026年9月21日時点の公式ページ本文では、Google AdsなどのGoogleマーケティング・計測製品は12時間ごとに更新され、その間隔は変更できないとされています。一方、同じページの表にはGoogle Analyticsの個別のデータ鮮度選択肢も掲載されています（Manage data freshness）。12時間固定という説明を、すべての計測コネクタに一般化してはいけません。

最終対象日が足りない場合は、対象コネクタの公式な更新仕様の範囲内かを先に確認します。範囲内なら、取得成功時刻と再確認条件を記録して待機を選べます。仕様上の間隔を過ぎても対象日が進まない、または接続エラーが出るなら、設定・認証情報・アクセス権の調査へ進みます。待機と障害対応を分けることで、仕様どおりの未反映を復旧作業として扱う混乱を避けられます。

暫定報告には欠けている範囲と再報告条件を書く

復旧を待てない場合は、取得済みの数値を暫定値として扱います。暫定報告には、確認表の内容から少なくとも次を転記します。

• 取得成功を最後に確認した時点
• データに含まれる最終対象日
• 行数差の有無と、未確認ならその状態
• 空欄の場所、確認できた理由、未確定の理由
• 今回の報告に含めない範囲
• 再取得後に差し替える条件

この記載により、クライアントは「取得済み範囲だけを使えるのか」「判断を待つべきなのか」を区別できます。理由不明の空欄をゼロとして扱ったり、対象日が足りない集計を全期間の結果として見せたりしないことが重要です。暫定報告を出せるかどうかも、欠けた範囲が意思決定に与える影響を担当者が確認して決めます。

暫定報告の作成にも、次の記入表を運用上の提案として使えます。実際の時刻、対象日、行数は取得結果から転記し、推測で補いません。

表の全欄が埋まっていても、欠けた範囲がクライアントの判断に影響する場合は納品保留を選びます。暫定報告に進むのは、取得済み範囲と未取得範囲を切り分け、利用できる指標を説明できる場合です。

通常納品へ戻す条件を記録する

復旧作業は、4項目を再確認して欠損の疑いを解消できた時点で終了します。取得成功を確認し、最終対象日が納品範囲を満たし、行数の差を説明でき、空欄理由が確定したら通常納品へ戻します。未確認の項目が残る間は、再取得・原因調査・暫定報告・納品保留の状態を維持します。

確認表には判定と併せて、確認した対象期間と抽出条件も残します。次回の行数比較や空欄調査で基準が混ざらず、同じ接続で再発したときにも、鮮度の待機から始めるのか、認証やアクセス権を調べるのかを選びやすくなります。AIは報告文や確認項目の草案整理に使えますが、取得結果の確認と納品可否の決定は人が担います。

担当者が引き継ぐ際も、取得成功時刻、最終対象日、行数、空欄理由と再確認条件を一緒に渡します。復旧後の確認まで同じ表で追うことで、欠損の疑いが残るレポートを完成版として扱わずに済みます。

関連ガイド：広告代理店のAI活用と業務改善