Meta広告のMCPサーバーを自作するとどうなるか——Claude Desktopで自然言語取得を試みた話

「Claude Desktop で Meta（Facebook/Instagram）広告のデータを自然言語で触れたら、レポート作業がずいぶん楽になるのでは」——そんな発想から、自前の MCP サーバー構築を検討する方が増えています。

結論から言えば、作れなくはありません。ただ、実際にやってみると想像以上の作業量と保守コストが伴います。本記事では、Meta 広告の MCP サーバーを自作しようとしたときに直面する「各ステップの重さ」を整理します。完全な実装ガイドではなく、「これだけのことをやる必要がある」という分量感をつかんでもらうことが目的です。

Yahoo! 広告版の自作つまずき記事も別途書いているので、合わせて読むと各媒体の特性の違いもわかります。
→ Yahoo広告のMCPサーバーは自作できる？実装でつまずいた6つの落とし穴

そもそも MCP サーバーとは

MCP（Model Context Protocol）は、Claude などの AI に外部データやツールを安全につなぐための共通規格です。MCP サーバーを用意すれば、Claude Desktop から「先月の Meta 広告の ROAS を教えて」と自然言語で聞くだけで、広告アカウントのデータをリアルタイムで引き出せるようになります。

手動でダッシュボードを開いてスクリーンショットを撮り、数字を転記する作業を AI に代替させるイメージです。仕組み自体はシンプルですが、Meta 広告を対象にした場合、実装の前段階に大きな壁が存在します。

自作に必要なステップの全体像

「Meta 広告の MCP サーバーを自作する」とは、大きく次の工程が必要になります。

  • Meta for Developers でアプリを作成し、必要な権限を申請する
  • OAuth フローを実装してアクセストークンを取得・管理する
  • Marketing API を叩いてデータを取得する（ページング・スキーマ整備含む）
  • MCP プロトコルに沿ったツール定義を実装する
  • セキュリティ（読み取り専用の担保・トークン非露出）を設計する
  • これらを継続的に保守する

順番に見ていきます。

壁1：Meta for Developers の本番審査

まず Meta for Developers でアプリを作成する必要があります。ここで最初の大きな壁があります。

広告データを取得するには ads_read という権限が必要ですが、この権限を本番で使うには Meta のビジネス認証を通過し、用途の審査を受ける 必要があります。

  • ビジネス認証：会社情報・担当者情報を提出してアカウントを法人として認証する
  • 権限の申請：ads_read を使う具体的な用途をドキュメントやスクリーンショット付きで説明する
  • 審査待ち：数日から数週間かかることがある。差し戻しも珍しくない

開発者本人のテストアカウントなら審査なしで動かせますが、実際のクライアントの広告アカウントに接続するには本番審査が前提になります。「とりあえず動いた」から「実務で使える」になるまでの距離が遠いです。

壁2：OAuth フロー＋トークン管理

Meta の OAuth は短期アクセストークン（有効期限 1〜2 時間）から始まります。実用のためには長期トークン（最大 60 日）に交換するフローを実装する必要があります。

  • 短期トークンをユーザーに発行させる → 長期トークンに交換するエンドポイントを呼ぶ → 保存・暗号化
  • 60 日を過ぎると失効するため、自動更新のロジックが必要
  • 更新失敗時のリカバリー処理と、ユーザーへの再認証フローの設計

「トークンを ENV に直書きして終わり」にしたい気持ちはわかりますが、それでは複数アカウント対応も更新管理も詰まります。まともに動かすには認証基盤を作ることになります。

壁3：Marketing API のレート制限とページング

Meta Marketing API にはレート制限があります。アカウントの規模や取得データ量によって制限値が変わり、超過すると一定時間 API を叩けなくなります（エラーコード 4 / 17 / 32 / 613 等が返る）。

  • 制限値はレスポンスヘッダーに含まれるため、ヘッダーを読んでスロットリングする実装が必要
  • 複数アカウントを並列で取得すると簡単に制限に引っかかる
  • ページング処理：取得件数が多い場合はカーソルで次ページを取得するループを書く必要がある
  • date_range・インサイトフィールド・ブレークダウン（年齢・性別・配信面等）によってスキーマが変わるため、レスポンスの正規化が必要

たとえば「クリエイティブ別の実績」を取るには、ad レベルのインサイトと creative のメタ情報を別々に取得して結合する必要があります。さらに最適化目標によって「結果（CV）」として参照すべき action_type が異なるため、Ads Manager の表示値に一致させようとすると条件分岐が複雑になります。

年齢・性別・配信面（publisher_platform / platform_position）・時間帯などのブレークダウン別に集計したい場合も、それぞれ個別のパラメータ設計が必要で、組み合わせによっては取得できないフィールドがあります。

壁4：MCP プロトコルの実装

データ取得ロジックができたとして、次にそれを MCP サーバーとして Claude から呼び出せる形にする必要があります。

  • FastMCP などのフレームワークを選定して MCP ツールを定義する
  • ツールの引数バリデーション・エラーメッセージの設計（Claude に意味のあるエラーを返す）
  • 単一エンドポイントで複数ツールを提供する構造設計
  • ローカルでの動作確認 → クラウドへのデプロイ → Claude Desktop から接続確認

「ツールを何個用意するか」も悩みます。アカウント一覧・キャンペーン一覧・広告セット・広告・インサイト・クリエイティブレポート・ブレークダウン別インサイト・動画視聴レポート——Meta 広告の構造を網羅しようとすると、ツール数が増えます。ツールが多すぎると Claude が適切なものを選ぶのが難しくなるため、粒度の設計も必要です。

この段階で初めて「Claude から広告データを取れた」体験になります。ただしここまで来るのに、広告 API の実装コードとは別に、MCP レイヤーの実装が必要です。

「この工程を全部やるのは現実的でない」と感じた方には、既に稼働している MCP サーバーに接続する選択肢があります。→ Harubase を試してみる

壁5：セキュリティ設計

MCP サーバーを外部から接続可能な状態で動かすには、セキュリティ設計も欠かせません。

  • 読み取り専用の担保：広告 API に書き込み操作（作成・更新・削除）を一切しないことをコードレベルで保証する。GET のみ使用、書き込みツールは実装しない
  • トークンの非露出：API から返ってくるレスポンスにアクセストークンが含まれる場合、Claude に渡す前に除去する処理が必要
  • 認証：MCP サーバー自体への不正アクセスを防ぐ Bearer 認証の実装
  • クライアントの広告アカウントトークンをどこに・どう保管するか（ENV 直書きでは複数クライアント対応が困難）

「とりあえず動かす」ところからセキュリティを後付けするより、最初から設計に組み込む必要があります。特に代理店用途で複数クライアントのトークンを管理するなら、それだけで相応の設計コストがかかります。

壁6：保守コスト

実装して動いたとしても、そこで終わりではありません。

  • Meta Marketing API はバージョンアップが定期的にある（現行 v21.0）。古いバージョンはサポート終了になるため追従が必要
  • フィールドの追加・廃止・挙動変更への対応
  • OAuth トークンの失効リカバリー対応
  • レート制限のチューニング（アカウント数が増えると当初の設定では不足することがある）

「動いた」と「運用できる」のあいだには、継続的なメンテナンス工数が必要です。筆者の体験では、最初の動作確認より「半年後もちゃんと動き続けるか」のほうが難易度が高いと感じます。

整理：自作するとこれだけのことが必要になる

ここまでの内容をまとめます。

ステップ 主な難所
Meta アプリ作成 + 権限申請 ビジネス認証・審査待ち・差し戻し
OAuth フロー実装 短期→長期トークン交換・自動更新・失効リカバリー
Marketing API 取得ロジック レート制限・ページング・スキーマ正規化・CV 集計ロジック
MCP プロトコル実装 ツール定義・バリデーション・デプロイ
セキュリティ設計 読み取り専用の担保・トークン非露出・認証
保守 API バージョン追従・フィールド変更・レート制限チューニング

技術的に不可能ではありませんが、「週末に作って月曜から使う」レベルではないのが実態です。審査だけで数週間かかることがあるため、「すぐ使いたい」ニーズには合いません。

Harubase という選択肢

筆者が実際に試したのが Harubase です。Meta / Yahoo!広告 / TikTok に対応した MCP サーバーをクラウド上で運用しているサービスで、ユーザー側の作業はアカウントを登録してトークンを連携し、Claude Desktop の設定ファイルに接続先を書き込むだけです。

上記の壁 1〜6 はすべて Harubase 側で対処済みです。アプリ審査も API 保守も運用者が担う必要はありません。

  • 読み取り専用：広告アカウントへの書き込みは一切なし（GET のみ）
  • トークン非露出：Claude に渡るレスポンスからアクセストークンは除去済み
  • 単一エンドポイント：媒体が増えても Claude 側の接続設定は変わらない

Claude Desktop の設定は以下のような形です。

{
  "mcpServers": {
    "harubase": {
      "type": "http",
      "url": "https://connect.haru-base.com/mcp",
      "headers": { "Authorization": "Bearer <発行されたキー>" }
    }
  }
}

この設定を書けば、Claude Desktop から Meta 広告・Yahoo! 広告・TikTok のデータを自然言語で取得できます。Google 広告は現在審査中で、順次対応予定とのことです。

実際の使い勝手については、Yahoo!広告版のレビュー記事に詳しく書いています。
→ 【実機レポ】ClaudeでYahoo広告を自然言語取得！MCPサーバー「Harubase」セットアップとプロンプト集

自作 vs Harubase、どちらが向いているか

自作が向いているケース：

  • Meta のアプリ審査が既に通っている（審査の壁がない状態）
  • 社内に API 保守の担当者がいて継続的にメンテできる
  • 独自のビジネスロジック（独自の CV 定義・独自の集計ルール）が必要
  • クローズドな環境に閉じて動かしたい

Harubase が向いているケース：

  • すぐに Claude から広告データを触りたい
  • 審査・保守に工数を割きたくない
  • Meta / Yahoo! / TikTok の複数媒体を横断してデータを取りたい
  • 小規模代理店・インハウスで 1〜2 人で運用している

まとめ

Meta 広告の MCP サーバー自作は、MCP プロトコルの実装よりも その前段階（アプリ審査・OAuth 管理・レート制限対応）のほうが工数を食います。技術的には到達できますが、「動いているものを明日から使う」は難しいのが実態です。

時間と工数をかけずにまず試したいなら、既に稼働している MCP サーバーに接続するほうが現実的です。

Harubase は現在アカウント登録を受け付けています。

→ Harubase に無料登録する

広告・マーケティング,広告運用AI,API,Claude,広告データ取得,広告自動化,広告運用,自然言語分析

Posted by Agent