「広告費 管理表 合わない」は誤差として流していいのか

2026年7月、自社で運用しているモール広告（Amazon広告）で、広告管理画面から出力した広告CSVの合計額と、広告API（Ads API）から取得した合計額を突き合わせたところ、21%の差がありました。

最初に立てた方針は次の通りです。

  • 月の広告費上限管理は、金額の大きい方（CSV）を基準に行う
  • どちらの数字が正しいとしても、上限管理という運用上の行動は変わらない
  • したがって差額は記録だけしておき、集計には混ぜない

この判断には一見合理性があります。上限管理に使う数字さえ決まっていれば、日々の運用は回るからです。しかし、この方針には一つ検証されていない前提がありました。「差額の中身が何であっても、行動は変わらない」という部分です。差額が単なる集計タイミングのズレ（たとえば当日分の反映遅延）なのか、それとも特定の広告種別が丸ごと片方の集計に含まれていないのか、これを確認しないまま「行動は変わらない」と結論づけていました。

差額の性質を確かめないまま放置すると、次のいずれかが起きます。

  • 差額がタイミングのズレなら、翌月には解消し実害はない
  • 差額が費目の欠落なら、欠けている費目は毎月同じ規模で発生し続け、上限管理の外に居座り続ける

この2つは対応がまったく異なるため、「差は記録するだけ」という運用は、後者のケースでは事実上の見て見ぬふりになります。

恒等式で内訳を割る――CSVとAds APIの差21%はどこから生まれたか

差額の性質を確かめるために、同一期間の広告費を、広告種別ごとに実測しました。Amazon広告にはスポンサープロダクト（SP）、スポンサーブランド（SB）、スポンサーディスプレイ（SD）の3種別があり、それぞれ管理画面・CSV・Ads APIでの出力範囲が異なる可能性があります。

種別ごとに数字を並べた結果、次の恒等式が成立することが確認できました。

  • 広告CSV ＝ スポンサープロダクト（SP） ＋ スポンサーディスプレイ（SD）
  • 実支出 ＝ 広告CSV ＋ スポンサーブランド（SB）

つまり、広告CSVにはSBの実績が最初から含まれていませんでした。CSVとAds APIの合計に生じていた21%の差は、集計タイミングのズレではなく、費目そのものの欠落だったということです。

ここで重要なのは、「差が21%ある」という事実だけを見ていた段階では、原因の見当がつかなかった点です。合計額同士の突き合わせでは、欠落が起きているのか誤差が乗っているのか区別できません。広告種別という内訳の単位に分解し、それぞれを別々に実測して初めて、どの費目が抜けているかが特定できました。

管理表の数字が合わないときに疑う3点

  • 集計期間のズレ（締め日・反映タイミングの違い）
  • 集計範囲の違い（一部の広告種別・キャンペーンタイプが含まれていない）
  • 手動転記や単位の誤り

このうち、合計額だけを見比べていても切り分けられないのが2番目の「集計範囲の違い」です。範囲の違いを見つけるには、内訳を種別ごとに割って、恒等式が成立するかどうかを確かめる必要があります。

消化率は122%ではなかった――見えていない広告費が上限管理の外にあった

恒等式が示した欠落分、つまりスポンサーブランド（SB）の実績は、月¥10,526・売上¥0でした。金額の絶対値としては大きくありませんが、この数字が持つ意味は金額の大小では測れません。

月の広告費上限に対する消化率を、欠落に気づく前の数字（広告CSVベース）で計算すると122%でした。しかし実支出ベースで計算し直すと143%でした。

最初に立てた「どちらが正しくても行動は変わらない」という判断は、この時点で誤りだったことが分かります。122%という数字を見ていた段階でも、すでに上限超過という異常値であり、本来は警戒すべき水準でした。ところが実際にはそれ以上に、143%という、より深刻な超過が起きていました。しかもその差分にあたるSBは、売上¥0のまま運用ループから完全に見えなくなっていました。売上に貢献していない広告費が、集計の外側で静かに積み上がっていたということです。

ここから得られる教訓は、「上限管理の基準額さえ決めておけば、多少の集計差は無視してよい」という判断は、差が費目の欠落によるものである限り成立しないという点です。基準額の大小に関わらず、見えていない支出は管理された支出ではありません。消化率122%と143%は、どちらも数字としては存在していましたが、後者だけが実態でした。

「取得できない」と判断する前に、手元のコードを確認する

欠落していたスポンサーブランド（SB）の実績値について、取得経路を新たに開発する前に、既存のコードを確認しました。その結果、SBを取得するAPI実装自体はすでに手元のコードに存在しており、単に呼び出されていなかっただけだったことが分かりました。

この事実は、運用上の重要な確認事項を示しています。「このデータは取得できない」という判断は、実際に取得を試みた結果としての結論なのか、それとも「おそらく無理だろう」という推測なのか、これを区別する必要があるということです。今回のケースでは、過去のどこかの時点でSBの取得コードが実装されていたにも関わらず、その後の運用フローに組み込まれないまま放置されていました。取得経路が「存在しない」のではなく「使われていない」状態だったということです。

差を調査するときの確認順

  • 差の原因を恒等式で特定する（前段の内訳分解）
  • 欠けている費目のデータソースが、そもそも取得可能かを確認する
  • 取得可能な場合、既存のコード・スクリプト・APIクライアントの中に、すでに実装済みの取得処理がないかを探す
  • 存在しなければ、その時点で初めて新規実装に着手する

この順番を飛ばして「取得できないから諦める」あるいは「取得できないから新規に作る」と即断すると、既にある資産を見落としたまま重複した実装を作ってしまうリスクがあります。

差を記録する運用から、差を消す運用へ――取得経路への組み込み方

原因が特定でき、取得経路も確認できた段階で、次に行うのは「差を記録して混ぜない」運用から、「差そのものを構造的に消す」運用への切り替えです。

具体的には、欠けていた費目（SB）の取得処理を、日次または週次で走る取得経路に組み込みます。組み込み先は主に次の2パターンです。

  • スプレッドシート＋GASによる定期取得: 既存の広告費集計シートに、SBの実績を取得する処理を追加し、SP・SDと同じ粒度・同じタイミングで記帳する
  • APIから直接取得するスクリプトへの統合: 既に稼働している取得スクリプトのジョブに、SB取得の呼び出しを追加する

どちらの方式を選ぶ場合も、共通して守るべきなのは「SP・SD・SBを同じ集計単位・同じ集計期間で扱う」という点です。片方が日次締め、もう片方が月次締めのように基準がずれていると、せっかく費目を揃えても再び集計期間のズレという別の差が生まれます。

組み込みが完了した後の広告CSV（あるいは集計シート）は、次の状態になっている必要があります。

  • 広告CSVの合計 ＝ SP ＋ SD ＋ SB（欠落分を解消）
  • 実支出 ＝ 広告CSVの合計（差がゼロになる）

この状態まで持っていって初めて、「差額は記録するだけでよい」という運用ではなく、「差額そのものが発生しない」運用に切り替わったと言えます。

恒等式は一度立てて終わりにしない――検算を仕組みに変える

恒等式を一度確認して費目の欠落を解消しても、集計ロジックの変更やAPI仕様の変更によって、同じ種類のズレは再発し得ます。今回のケースでも、SBの取得コードは既に存在していたにも関わらず、いつの間にか運用フローから外れていました。同じことは、他の費目や他のモールでも起こり得ます。

再発を防ぐために、運用に組み込んだのは次の3ステップです。

  • 同一期間で全構成要素（SP・SD・SB、その他該当する広告種別）を実測し、恒等式が成立するかを確認する
  • 恒等式が成立していれば、欠けている要素は無いと判断できる。成立しなければ、どの要素が欠けているかを内訳分解で特定し、取得経路に組み込む
  • 恒等式を継続的に検算する仕組みを用意し、崩れた場合（＝新たな欠落や重複が発生した場合）には警告が出るようにする

このステップの要点は、「恒等式が成立している」という状態を一度の確認で終わらせず、継続的な検算の対象にすることです。広告費の管理表と実支出が合わないという問題は、一度の突き合わせで解消したように見えても、集計ロジックや取得元の仕様変更によって静かに再発します。恒等式を検算の基準として仕組みに組み込んでおけば、差が生まれた瞬間に気づける状態を維持できます。

管理表と実支出が合わないとき、差額をどちらか片方の数字に寄せて記録するだけの運用は、差の原因が集計範囲の欠落である場合、見えない支出を放置し続けることと同じです。合計額同士を見比べるのではなく、費目ごとの内訳に分解して恒等式を立てる。恒等式が崩れたところに、取得経路から漏れている費目がある。この手順自体は、モール広告に限らず、複数の取得元からデータを集計するあらゆる管理表に応用できる考え方です。