Meta Ads Creative Manager — Behind the Scenes

Preflight

Verifies auth, destination folder, and sheet columns up front; aborts in seconds on misconfiguration

List ads

Pulls ads per account with their ad set and campaign names attached

Resolve creatives

Walks single-image, carousel, and dynamic creatives to locate the real asset URLs

Name & dedupe

Derives names from each asset's own ID or hash; skips anything already on Drive

File to Drive

Auto-creates per-account and per-ad folders; generates fallback docs for unavailable videos

Write back to sheets

Matches rows by ad name and writes the link into one designated column only

Report

Outputs the run result, unmatched rows, and any failed assets

「何が本当に面倒なのか」を先に特定する

最初の相談は「広告素材を一元管理したい」という広い要望でした。ヒアリングを重ねて、実際に時間を食っているのは『管理表の行から実物のクリエイティブに辿り着けないこと』だと切り分け、そこだけを解く構成に絞り込みました。範囲外にしたもの（成果数値の集計、他サービスに散っている資料の統合）も、その場で合意して書面に残しています。

権限の通し方をAPIで先に検証する

実装前に、クライアント本人名義のアプリ＋読み取り専用の権限で必要なデータに届くかを実APIで確認しました。ここで通ることを確かめておくと、審査申請が不要になり着手が数週間早まります。逆にここを飛ばすと、作り終えてから「権限が下りない」で全部止まります。

取得ロジックの実装

広告一覧から、単体画像・カルーセル・動的クリエイティブそれぞれの構造をたどってアセットを解決します。動画はアカウントの動画ライブラリ経由でまとめて引く必要があり（個別に問い合わせると権限エラーになる）、ここは実際に叩いて分かった仕様に合わせています。

冪等に動く命名規則を設計する

再実行しても二重取得しないよう、Drive上の同名ファイルの有無で「取得済み」を判定しています。つまりファイル名の決め方がそのまま欠落の有無に直結するため、名前の決定ロジックだけを独立したモジュールに切り出し、アセット固有のID・ハッシュを必ず名前に含める方式に統一しました。

非エンジニアが自力で回せる状態にする

実行はバッチファイルのダブルクリック、エラーは日本語の指示文に変換。重い処理に入る前に認証・保存先・シート構造をまとめて確認し、設定ミスがあれば最初の数秒で止めます。手順書は初回セットアップ・Google認証・トークン更新・受け入れチェックなど7本に分けてPDFで納品しました。

納品後に見つかった運用要件へ追加対応

初回納品後、管理シートが1枚ではなく案件ごとに複数枚あることが判明。取得とDrive格納は1回のまま、リンクの書き込みだけをシートの枚数分繰り返す形に拡張しました。対象シートの指定はクライアント自身が設定ファイルを編集する運用にし、シートが増減するたびにこちらへ依頼が発生しない形にしています。

Problem

ファイル名を「取得できた順の連番」で付けていたため、広告の構成が変わると新しい素材が『取得済み』と誤判定され、静かに欠落する経路があった

Solution

名前を「アセット自身の情報（画像のハッシュ・動画のID）だけで決まる」方式に変更。同じ題名の動画に差し替えられても別ファイルとして扱われます。名前をその時の集合に依存させないことが冪等性の条件だと分かり、この原則を設計メモに明文化して以降の変更で崩さないようにしました。

Problem

アクセストークンをURLのクエリに載せていたため、通信エラー時のログにトークンが平文で残っていた。しかもそのログは「詰まったら送ってください」と案内しているファイルだった

Solution

トークンをAuthorizationヘッダー送信に変更し、加えてログ出力の直前でマスクする二重の防御にしました。別モデルによるクロスレビューで見つかった問題で、以降は出荷前のクロスレビューを工程に組み込んでいます。

Problem

APIの仕様上、どうしても本体を取得できない動画が全体の約半分あった。しかも先に「動画も全部ドライブに入ります」と伝えてしまっていた

Solution

取得できない条件を切り分けて、権限を足しても解決しないことを実測で確定させたうえで、正直に訂正しました。そのうえで代替として高解像度サムネイルと、動画ごとの直接リンクを並べた案内ドキュメントを自動生成する形に変更。できないことを早く言い切って代替案を出すほうが、曖昧なまま引っ張るより結果的に信用されると実感しました。

Problem

Windowsのパス長上限を超え、名前の長い広告のファイルだけが毎回失敗していた。再実行しても同じ場所で落ちるため、利用者から見ると原因不明のまま永久に取得できない

Solution

一時作業フォルダの階層を浅くして回避しました。開発環境（Linux）では絶対に踏まない不具合で、納品先の環境で実際に動かして初めて出る種類の問題です。以降、納品前の実機確認は工程から外さないことにしています。