自作の広告レポートが誰も直せなくなる日｜スプレッドシートで積み上げた集計環境の寿命と畳み方

自分で組んだ集計シートなら、自分が一番わかっている。数式の意図も、なぜこの列を別扱いにしたかも、頭に入っている。少なくとも作った直後はそのとおりです。実際、媒体の管理画面から書き出したCSVを貼り付けて関数で整えるやり方は、初期費用ゼロで自分の見たい形に届くという点で強力な選択肢です。問題は、そのシートが1年後も同じように動くと暗黙に前提していることのほうにあります。広告運用者の方から「引き継ごうとしたら誰も直せなかった」という相談を受けるとき、原因はたいてい作った人の技術力ではありません。

自作レポートが壊れるのは、作った人の能力とは関係ない

壊れるきっかけは、ほぼ外側から来る

自作の集計環境が動かなくなる引き金は、シートの内部ではなく外部の変化です。媒体側がレポートの列名を変える。CSVの出力仕様が変わって、これまで3列目にあった項目が5列目に移る。管理画面の統合で、そもそもダウンロードできるレポートの種類が変わる。2026年のLINEヤフー広告の統合のように、媒体側の構造が大きく動く年には、この種の変化がまとめてやってきます。関数側は列の位置や名前を前提に組まれているため、前提が動けば結果は静かにずれます。エラーになって止まってくれればまだましで、厄介なのは数字が出続けるのに中身が間違っているパターンです。

直せなくなるのは、判断の理由が残っていないから

壊れたシートを開いて手が止まる理由は、数式が読めないことではありません。読めば何をしているかはわかります。わからないのは「なぜそうしたか」のほうです。特定のキャンペーンだけを集計から除外している。ある月だけ手入力の値が入っている。CVの列に媒体ごとに違う係数がかかっている。どれも当時は理由があった処理ですが、理由はシートに書かれていません。結果として、直すには元の判断を再現するしかなくなり、それができるのは作った本人だけになります。これは属人化と呼ばれる現象そのもので、1人で運用を担当することの構造的な問題と同じ根から出ています。

寿命が縮んでいく3つの兆候

シートが増えるのではなく、シートの中に例外が増える

危ないのはシート数ではありません。1つのシートの中で、特定の行だけ違う扱いをする分岐が増えていく状態です。IF関数の入れ子が3段を超えたあたりから、修正のたびに他の条件を壊すリスクが上がります。月商500万円規模の案件を5社担当している運用者のシートを見ると、クライアントごとに「この媒体だけCV定義が違う」「この月から手数料率が変わった」といった例外が積もっていて、共通部分より例外部分のほうが長いという逆転がしばしば起きています。この段階になると、正しく動いているかを確認する作業自体が、レポートを作るより時間がかかります。

更新手順が、毎月やっている人の頭の中にしかない

もう一つの兆候は、手順書がないことではなく、手順書があっても足りないことです。「①各媒体からCSVをダウンロード ②rawシートに貼り付け ③更新ボタンを押す」と書かれていても、実際には「Metaだけは日付形式を直してから貼る」「Googleは前月分が重複するので古い行を消す」といった補正が入っています。書かれていない補正は、やっている本人にとっては手順ではなく反射なので、書き出す発想自体が生まれません。誰かに渡した瞬間に、数字が合わなくなる原因はここに集中します。

兆候	現れ方	放置したときに起きること
例外の増殖	条件分岐が入れ子になり、共通処理より長い	1箇所直すと別の条件が壊れる
暗黙の補正	手順書に書かれていない前処理がある	担当が変わった月から数字が合わない
検算の消失	管理画面と突き合わせる工程が省略される	誤った数字のまま数か月報告が続く

3つ目の検算の消失がいちばん見えにくく、いちばん高くつきます。作りたてのころは管理画面と付き合わせて確認していたのに、正しく動く月が続くと確認をやめてしまう。やめた後に前提が変わると、気づくのは報告先からの指摘です。

3つの兆候はどれも、シートが複雑になったから起きるわけではありません。運用が続いているから起きます。担当する媒体が増え、クライアントの事情が個別化し、計測の定義が途中で更新される。健全に運用が回っているアカウントほど、集計側に持ち込まれる変更は多くなります。つまり、自作環境の寿命は「うまくいっていない案件」ではなく「長く続いている案件」から先に尽きます。この順番は直感に反しますが、相談を受けて開く集計シートは大抵そうなっています。

ADminiの媒体データ1画面集約とピボット集計で、CSVを貼り直さずに媒体横断の数字を確認できます。ADminiなら無料で始められます。無料で試してみる →

作り直すと決めたときに、先に決めること

全部を移さず、意思決定に使っている数字だけを移す

自作環境から移行するときに失敗する典型は、今あるシートの機能を全部再現しようとすることです。何年も積み上げたシートには、もう誰も見ていない集計が必ず含まれています。移行の前に、直近3か月の間に実際に施策の判断根拠として使った数字を書き出してみると、たいていは想像より少なく収まります。移す対象をそこに絞れば、移行にかかる時間も、移行後に維持する対象も一気に減ります。スプレッドシート管理の限界を感じた段階で全面刷新に踏み切ると、範囲が広すぎて途中で止まりがちです。使っている数字から順に移すほうが、途中で止まっても損をしません。

• その数字を見て、直近3か月で何かを止めたり増やしたりしたか
• その数字がなくても、クライアントへの説明は成立するか
• その数字は媒体の管理画面でそのまま見られるか、それとも加工が要るか

3つ目が移行の優先順位を決めます。管理画面で素のまま見られる数字は、無理に集計環境へ持ち込む必要がありません。移す価値が高いのは、複数媒体をまたぐ集計や、自社の売上データと突き合わせて初めて意味を持つ数字のほうです。逆に言えば、単一媒体の数字を並べ直しただけのシートは、移行先でも同じ手間を再生産します。

例外処理は、仕組みの中ではなく外に出す

移行後に同じ袋小路へ入らないための分かれ道は、例外をどこに置くかです。「このクライアントだけCV定義が違う」という事情を集計の中に埋め込むと、また同じ構造ができます。代わりに、集計は媒体から取れた素のままで持ち、例外は別の列や別の表として横に置く。こうしておくと、例外が正しいかどうかを集計と独立に確認できます。Looker Studioが重くなる問題も、根っこは似ています。1つの場所に処理を積み上げるほど、どこが遅いのか、どこが間違っているのかを切り分けられなくなる。ADmini（アドミニ）のようなツールを使う場合も、この原則は変わりません。例外そのものは残り続け、変わるのはそれを置く場所だけです。

まとめ

たとえば3年使ったシートが媒体の列名変更で崩れ、復旧に週末2日かかったとします。復旧できたのは作った本人が動けたからで、もし体調を崩していれば、その月の報告は止まっていたはずです。自作環境の本当のコストは、作る時間でも維持する時間でもなく、こういう日に一人しか対処できないことのほうにあります。では、ツールへ移せばこの構図が消えるかというと、そうとは限りません。取り込みの設定だけを移して、CVの定義も除外の基準も誰とも共有しないまま運用を続ければ、壊れた日に開ける人がいないという状態はそのまま再現されます。ADmini（アドミニ）を含めて、どのツールを選ぶかより先に、決めた内容がどこに残るかを意識するほうが効きます。まず今週やることを1つ挙げるなら、いま使っている集計シートを開いて、直近3か月で実際に判断に使った数字がどれかに印をつけてみてください。移す価値のある範囲が、そこで見えます。

ADminiの媒体データ1画面集約と1日1回の自動更新で、貼り付け作業なしに前日までの数字が揃います。ADminiなら無料で始められます。無料で試してみる →

よくある質問

スプレッドシートで広告レポートを自作するのはやめたほうがいいですか

初期段階では合理的な選択です。費用がかからず、見たい形にすぐ届きます。問題になるのは、媒体側の仕様変更に追随し続ける必要が出てからで、担当が1人しかいない状態で例外処理が積み上がったときに限界が来ます。自作をやめる判断は、シートの規模ではなく「壊れたときに自分以外に直せる人がいるか」で考えるのが実務的です。

自作の集計シートが壊れる主な原因は何ですか

外部の変化が最も多い原因です。媒体側でレポートの列名や出力仕様が変わると、列の位置や名前を前提に組まれた数式が静かにずれます。エラーで止まらず数字だけが間違うケースが最も危険で、管理画面との突き合わせをやめた後にこれが起きると、誤った数字のまま報告が続きます。

自作レポートからツールへ移行するとき、何から手をつけるべきですか

直近3か月で実際に施策判断の根拠にした数字を書き出し、その範囲だけを先に移してください。長く使ったシートには誰も見ていない集計が必ず含まれており、全機能を再現しようとすると移行が途中で止まります。使っている数字から順に移す進め方なら、途中で止まっても損失が出ません。

ツールを導入すれば属人化は解消されますか

自動的には解消されません。取り込み設定や指標の定義を決めるのは人であり、決め方が共有されていなければ場所が変わっただけになります。効果が出るのは、決めた内容が設定として仕組みに残り、他の人が開いて確認できる状態になったときです。特に、クライアント固有の例外処理を集計の中に埋め込まず、別の列や表として分けて持つ設計が有効です。