TATSUYA HORIKAWA
July 2, 2026·Engineering·9 min read

Meta Marketing API で踏み抜いた罠10選 — エラーコード付き実戦記録

広告作成をAPIから自動化する過程で実際に踏んだ10個の落とし穴を、症状(エラーコード)→原因→対処の形式でまとめた。JPY予算100倍事故から、ページトークン必須の罠、IG連携の二重構造まで。

Meta Marketing API で踏み抜いた罠10選 — エラーコード付き実戦記録

広告キャンペーンの作成・配信管理を Meta Marketing API から自動化するシステムを作ってきた。 ドキュメントを読めば作れる——と思っていたが、実際にはドキュメントに書いていない(または 見つけられない場所に書いてある)罠を次々に踏んだ。

同じ道を通る人のために、実際に遭遇した10個を「症状 → 原因 → 対処」の形式で置いておく。 エラーコードで検索して辿り着けるように、コードは省略せず書く。

罠1:is_adset_budget_sharing_enabled が実質必須(v21+)

  • 症状:キャンペーン作成で code=100, subcode=4834011。「キャンペーン予算を使用していない場合は、is_adset_budget_sharing_enabled フィールドで True または False を指定する必要があります」
  • 原因:API v21 から、広告セット側で予算を持つ場合にこのフィールドの明示が必須になった
  • 対処:広告セット予算で運用するなら campaign 作成の payload に is_adset_budget_sharing_enabled: false を必ず入れる

罠2:JPY の通貨換算で予算が100倍になる

  • 症状:日予算 ¥3,000 のつもりが ¥300,000 で広告が動く
  • 原因:USD は cent 単位(×100)で送る仕様のため、「JPY も ×100」と思い込みやすい。しかし JPY はゼロ小数通貨で最小単位は ¥1
  • 対処daily_budget には円額をそのまま入れる。×100 しない。通貨ごとの最小単位は公式の Currencies ドキュメントに一覧がある

10個の中で実害が最も大きい罠がこれ。テスト時は必ず少額+即時停止できる体制で。

罠3:Pixel 未指定で OFFSITE_CONVERSIONS が失敗する

  • 症状:広告セット作成時に promoted_object 関連のエラー
  • 原因:最適化目標 OFFSITE_CONVERSIONSpromoted_object.pixel_id が必須。null だと通らない
  • 対処:イベントマネージャで Pixel ID を確認し、広告セット作成時に必ず渡す

罠4:Page が Business Manager 未所属で creative が作れない

  • 症状:creative 作成で code=100, subcode=1443121「ビジネスの Facebook ページを選択してください」
  • 原因:Page が BM に登録されていない、または広告アカウントとは別の BM に所属している
  • 対処:BM 設定 → アカウント → ページ で該当 Page を追加し、広告アカウントと同じ BM 配下に揃える

罠5:Page ID と管理者の個人 User ID を取り違える

  • 症状:Page ID を設定したのに罠4と同じエラーが出続ける
  • 原因:facebook.com の About 等で拾える ID には Page ID と管理者の個人プロフィール ID が混在している。100069... で始まる15桁は個人 ID の可能性が高い
  • 対処:トークンで /me/accounts を叩き、返ってくる data[].id を正とする
curl -s "https://graph.facebook.com/v21.0/me/accounts?fields=id,name,tasks&access_token=$TOKEN" | jq .

tasksADVERTISE が入っていれば、そのページへの広告作成権限もここで確認できる。

罠6:個人の User Access Token で運用してしまう

  • 症状:各所で OAuthException や capability エラー。そして60日後に全部止まる
  • 原因:個人 User Token は60日で失効し、スコープ管理も煩雑
  • 対処:BM のシステムユーザーでトークンを発行する(無期限にできる)。広告運用の自動化に最低限必要なスコープは7つ:ads_management / ads_read / business_management / pages_show_list / pages_read_engagement / pages_manage_ads / pages_manage_metadata

罠7:/adimages の URL アップロードが capability エラー

  • 症状code=3「Application does not have the capability to make this API call」
  • 原因/adimagesurl= で画像URLを渡して Meta 側に取得させる方式は、Standard Access では使えない追加 capability が要る
  • 対処:自前のサーバで画像を fetch してダウンロードし、bytes を multipart/form-data で POST する。URL 渡しを bytes 渡しに変えるだけで通る

罠8:Meta App が Development モードのままで creative 作成不可

  • 症状code=100, subcode=1885183「クリエイティブ投稿は開発モードのアプリにより作成されたものです。広告を作成するには、公開してください」
  • 原因:App が Development モードだと、そのアプリ経由の広告クリエイティブは配信できない
  • 対処:developers.facebook.com で該当 App を「公開中(Live)」に切り替える。必要なのはプライバシーポリシー URL・アプリアイコン(1024×1024)・カテゴリ設定だけ
  • 重要App Review(審査)は不要。 System User + Standard Access の構成なら、Live 切替フォームを埋めるだけで広告 API は全部動く。「審査が必要」と思い込んで数週間止まるのが一番もったいない

罠9:ページ系のエッジはページアクセストークンが必須

  • 症状(#210) A page access token is required to request this resource。投稿一覧(/{page_id}/published_posts)取得やリードフォーム(/{page_id}/leadgen_forms)作成で発生
  • 原因:ページに紐づくエッジは Page Access Token 必須。System User トークンでは弾かれる
  • 対処:System User トークンで GET /{page_id}?fields=access_token を叩いてページトークンを取得し、それでページ系 API を呼ぶ。前提として System User がそのページにロールを持っていること(罠6の7スコープで満たせる)
  • 広告アカウント側(/act_{id}/... の campaign / adset / ad / creative)は従来どおり System User トークンで OK。ページ直下のエッジだけ別扱い、というのがハマりどころ

罠10:Instagram 投稿のブーストは「IG連携」の二重構造を知らないと動かない

  • 症状:投稿ブーストの候補に IG 投稿が出てこない。API で調べると instagram_business_accountconnected_instagram_account も空
  • 原因:Meta の「IG 連携」は二重構造になっている。Facebook アカウント設定の「リンクするアカウント」(クロス投稿用)と、Graph API が参照するビジネス/ページ単位の IG 連携は別物。前者で「リンク済み」でも、後者が無いと API からは一切見えない
  • 対処は3点セット:
    1. トークンに instagram_basic スコープを追加して再発行(標準の7スコープには入っていない)
    2. IG アカウントを BM のビジネス資産として登録し、対象 FB ページに接続する(BM のユーザー一覧に「出ている」だけでは資産登録ではない)
    3. System User に IG アセットを割り当てる(ページや広告アカウントと同様の割当操作)
  • なお IG 投稿のブースト広告は、creative に source_instagram_media_id + object_story_spec.instagram_actor_id を使う。FB 投稿の object_story_id とは別系統

全体を貫く教訓

10個並べて振り返ると、共通するパターンが見える。

  • エラーメッセージは「何が悪いか」は言うが「どこで直すか」は言わない。 対処はほぼ毎回 BM の設定画面側にある
  • 権限は「トークンのスコープ」「BM の資産割当」「アプリのモード」の3層。 どこか1層でも欠けると、別の層のエラーに見える形で失敗する
  • 課金が絡む API は必ず少額でテストする。 罠2のような単位系の事故は、コードレビューでは気づけない

Meta の広告 API は、ドキュメントの整備度に対して運用ノウハウの依存度が異常に高い。 この記事が、subcode=4834011 あたりで検索して途方に暮れている誰かに届けば本望だ。

Thanks for reading.

読んでくれてありがとう。感想や反論、どちらも歓迎します。

SharePost