広告 MCP サーバーのセキュリティ体制の大部分は、OAuth の画面が表示される前に、ブラウザで約十分で確認できます。サーバーのドメインに対して七つのチェックを実行します。二つの OAuth ディスカバリーファイル、security.txt、MCP サーバーカード、公開された書き込み制御モデル、セッションの取り消し経路、レジストリの照合です。このガイドでは、各チェックを PaidSync の実際の URL で示し、合格がどのようなものかを正確に確認できます。すべて 2026 年八月 1 日に取得しました。安全な Google Ads MCP サーバーの管理項目の一覧は、PaidSync.ai のセキュリティページにあります。
これらのチェックに開発者は必要ありません。どれも、ブラウザに貼り付ける URL か、公開ドキュメントで検索する語句です。サーバーが最初の四つに合格しなければ、確認できるものが何もなく、その欠如自体が答えです。
このページが存在する理由を示す二つの事例
postmark-mcp、2025 年九月、実際に確認された初の悪意ある MCP サーバー
Koi Security の研究者が、Postmark の本物のメールライブラリになりすました postmark-mcp という npm パッケージを発見しました。バージョン 1.0.16 から、経由して送信されるすべてのメールを攻撃者のアドレスにこっそり BCC で送るコードが一行追加されました。削除されるまでに 1,643 回ダウンロードされました。詳しい報告は The Hacker News をご覧ください。
広告主にとって重要な点は、ローカルにインストールされた npm パッケージはセキュリティ体制を一切公開しないため、postmark-mcp は以下のチェックに一つも合格しなかったはずだということです。OAuth ディスカバリーも、セキュリティ連絡先も、サーバーカードも、レジストリで検証されたドメインもありません。攻撃は名前のなりすましで成立し、名前を照合できる固定のアドレスには何もありませんでした。ディスカバリードキュメントを公開するリモート MCP サーバーは、どの npm install も提供しないもの、つまり運営者が訪問者ごとにこっそり変えられない URL 上の検証可能な主張を提供します。
二つ目の事例はより曖昧で、正直にそう言う必要があります。2026 年春、広告担当役員たちがオンラインの議論で、AI ツールを連携した後に Meta の広告アカウントが制限または停止されたと主張しました。Digiday は 2026 年四月 29 日に報じ、「両者の間に公式な関連は確認されていない」とし、Meta は広告アカウントの措置を特定の AI ツールと結び付ける声明を出していません。この停止の波は未確認として扱ってください。ただし、主張された事例に共通していた形には注目してください。生の API トークン、無人で動くエージェント、モデルと稼働中のアカウントの間に承認の段階がないことです。以下のチェック 5 と 6 は、何かを接続する前に、まさにその形を除外するためにあります。
七つのチェックの概要
各チェックは URL か、文書化された挙動です。右の列は PaidSync の実際の結果で、合格した状態を確認できます。これらのチェックへの合格が PaidSync だけの特徴だからではありません。適切に運営されている広告 MCP サーバーなら、七つすべてに合格できますし、合格すべきです。
| チェック項目 | 確認する場所 | PaidSync の結果(2026 年八月 1 日) |
|---|---|---|
| 1. OAuth サーバーメタデータ | /.well-known/oauth-authorization-server | 200、JSON、PKCE S256 |
| 2. 保護リソースメタデータ | /.well-known/oauth-protected-resource | 200、JSON、読み取りと書き込みのスコープを分離 |
| 3. security.txt | /.well-known/security.txt | 200、連絡先 + Expires 2027 |
| 4. MCP サーバーカード | /.well-known/mcp/server-card.json | 200、認証必須、PKCE 必須 |
| 5. 書き込み制御モデル | 公開ドキュメント、名前のある仕組み | dry_run + confirm_destructive を文書化 |
| 6. セッションの取り消し | ドキュメントまたはダッシュボード | ダッシュボードからいつでも取り消し可能 |
| 7. レジストリの整合性 | 公式 MCP レジストリ | 有効な登録、ドメインはカードと一致 |
チェック 1。OAuth メタデータ
次のパターンをブラウザに貼り付け、サーバーのドメインに置き換えます。
https://<server-domain>/.well-known/oauth-authorization-serverRFC 8414 がこのファイルを定義しています。サーバーが、OAuth をどう行うかを固定のアドレスで宣言するものです。認可エンドポイントとトークンエンドポイントの場所、サポートするグラントタイプ、PKCE(コード横取りへの対策)を必須とするかどうかを示します。S256 が code_challenge_methods_supported の下にあるか確認してください。このファイルがあるサーバーは、標準化された OAuth を行っています。ないサーバーは、別の方法でアクセスを扱っており、多くの場合、長期間有効な生のトークンの貼り付けを求めます。これが 2026 年の恐ろしい話の大半の背景にあるパターンです。
PaidSync の実際のファイル、2026 年八月 1 日に取得:
https://paidsync.ai/.well-known/oauth-authorization-serverチェック 2。保護リソース情報
RFC 9728 は対になるファイルで、リソースが、どの認可サーバーがそのトークンを発行でき、どのスコープが存在するかを宣言するものです。ここで読むべき点は二つあります。一つ目は、読み取りと書き込みが別々のスコープかどうかです。分離されていれば、サーバーは変更権限を与えずにレポートのアクセスだけを付与できます。二つ目は、記載されているドメインが、Claude や ChatGPT で設定しようとしているエンドポイントと一致しているかどうかです。現在の MCP の認可モデルはこの二つのディスカバリードキュメントを土台としており、2026-07-28 の MCP 仕様は認可をさらに厳格にしました。
PaidSync の実際のファイル、2026 年八月 1 日に取得:
https://paidsync.ai/.well-known/oauth-protected-resourceチェック 3。security.txt
RFC 9116 は、運営者が脆弱性の報告方法を公開するファイルを定義しています。Contact の行と、将来の日付の Expires があるか確認してください。期限切れの日付は、誰も保守していないことを意味します。ファイルがない場合、広告アカウントを預かるサーバーの欠陥を見つけた研究者には、誰かに知らせる正式な手段がありません。これは三十秒でできるチェックで、趣味レベルのサーバーのかなりの割合を除外できます。
PaidSync の実際のファイル、2026 年八月 1 日に取得:
https://paidsync.ai/.well-known/security.txtチェック 4。MCP サーバーカード
サーバーカードは、サーバーが自分自身を機械可読な形で記述したもので、名前、エンドポイント、ドキュメント、認証の仕組みを含みます。三つのフィールドを読みます。authentication.required が true になっているか。OAuth の方式が、チェック 1 と 2 のディスカバリーファイルを指しているか。エンドポイントのドメインが、実際に接続する先と一致しているか。広告サーバーのカードが認証を必要としていなければ、それだけで危険信号です。広告アカウントの前に置かれた認証のないエンドポイントは、存在すべきではないからです。
PaidSync の実際のカード、2026 年八月 1 日に取得:
https://paidsync.ai/.well-known/mcp/server-card.jsonチェック 5。書き込み制御の公開
ランディングページに「エンタープライズ級のセキュリティ」と書くことは誰にでもできます。探すべきなのは違うものです。書き込みを制御する具体的な仕組みを名指ししているドキュメントです。名前のあるパラメータは、検証できる主張だからです。サーバーの公開ドキュメントで、dry_run、承認、破壊的アクションの確認といった語句を検索します。ドキュメントが制御の仕組みを一切挙げていなければ、書き込みに制御がないものとして、それに応じて行動してください。
PaidSync の公開モデル、2026 年八月 1 日に取得、セキュリティページは 2026 年九月 23 日に再確認: paidsync.ai/security は、MCP 経由では PaidSync が承認カードを書き込まないため、人によるチェックはアシスタント自身の確認プロンプトであると明記しています。Meta 一括操作のドキュメントは、両方の仕組みを挙げています。ほとんどの書き込みツールで dry_run のプレビューを使えるため、確認の前に予定されている変更を確認できます。また、稼働中のキャンペーンを変更するすべてのアクションには confirm_destructive のパターンが適用されます。読み取りアクションは確認を必要としません。
チェック 6。セッションの取り消し経路
接続する前に、切断する方法を把握しておいてください。問いはこうです。広告プラットフォームのパスワードをローテーションせずに、このサーバーのアクセスを一分以内に切断できるか。信頼できるサーバーは、二つの層を提供します。ツール側では、セッションとキーを取り消せるダッシュボード。プラットフォーム側では、接続が OAuth ベースなので、Google や Meta のセキュリティ設定からも切断できます。長期間有効な生の API トークンの貼り付けを求めるサーバーは、構造的にこのチェックに不合格です。唯一の対処は認証情報のローテーションで、時間がかかり、忘れやすいからです。
PaidSync の公開されている経路、2026 年八月 1 日に取得: paidsync.ai/connect-mcp は、アクセスはいつでも PaidSync のダッシュボードから取り消せると明記しています。
チェック 7。レジストリ登録の整合性
公式の MCP レジストリでサーバーを検索し、レジストリの記載内容を、チェック 4 のサーバーカードと比較します。
https://registry.modelcontextprotocol.io/v0/servers?search=paidsync検索語は、評価しているどのサーバーに置き換えても構いません。一致していなければならないのは、エンドポイントのドメインと認証方式です。PaidSync のレジストリエントリは、2026 年八月 1 日に取得した時点で有効で、2026 年四月 8 日に公開され、mcp.paidsync.ai を指し、API キーを必須かつ秘密としています。そのすべてがサーバーカードと一致しています。
学ぶ価値のある、正直な小さなずれが一つあります。レジストリエントリの説明には、四月時点のテキストが残っており、200+ のツールと書かれていますが、実際のサーバーカードは、14 のプラットフォームにまたがる現在の 630+ のツールのカタログを反映しています。これが無害なずれの姿です。説明や件数は、レジストリの更新の間に古くなります。ドメインは古くなりません。古い数字は見た目の問題にすぎませんが、ドメインの不一致はなりすましの手口であり、postmark-mcp はまさに名前のなりすまし攻撃でした。ドメインを照合し、そこに食い違いがあれば失格として扱ってください。
公式 MCP を使えばよいのでは
もっともな疑問です。Google が自社の MCP サーバーを出しているのに、なぜ第三者サーバーを確認する必要があるのでしょうか。それは公式サーバーの性質によります。Google は、オープンソースの Google Ads API MCP サーバーを 2025年10月7日に Google Ads Developer Blog で発表しました。リポジトリが公開しているツールは三つで、検索、リソースのメタデータ、アクセス可能な顧客の一覧です。すべて読み取りのみで、一時停止も、予算変更も、除外キーワードの追加も、いかなる変更もできません。
That makes the official server a safe choice for reporting: since its 2 Nov 2026 release its writes cover assets and labels, each proposed first and confirmed second. The moment you want an AI to act on what it finds, you are choosing a third-party server whether you planned to or not. Meta, for its part, is opening its ad ecosystem to third-party AI tools, as Digiday covered in April 2026. So "just use the official one" does not remove the verification problem. It narrows it to the exact category where verification matters most: servers that can write. Running Google's read-only server for diagnostics alongside a verified write-capable server is a reasonable pairing, not a contradiction.
このチェックリストにできないこと
正直な限界、利用前にお読みください
これらのチェックで確認できるのは、コードではなく姿勢です。合格したサーバーは、確認できる形でセキュリティ対策を公開しており、見えない部分の対策もしている可能性は高まりますが、それを証明するものではありません。このチェックリストでは、サーバー内部の監査も、依存パッケージのスキャンもできず、広告プラットフォームが自動化された操作をアカウント上で検知しないことも保証できません。また、これらの文書を公開しない、ローカルにインストールする npm ベースの MCP サーバーにはほとんど当てはまりません。その場合の対策はパッケージの出所確認と依存関係のスキャンで、別の分野の話になります。PaidSync についても同じ基準で述べておきます。Search Console のツールは読み取り専用です。TikTok、Snapchat、Reddit、Pinterest は既存キャンペーンの管理と最適化に対応しますが、新規作成には対応していませんが、Microsoft Ads は検索キャンペーンとパフォーマンス最大化キャンペーンを一時停止状態で作成します。このページの筆者が合格したチェックリストでも、ご自身で実行してください。URL はすべて上に記載しています。
チェック 1 から 4 に不合格の場合：実際の広告費があるアカウントは接続しないでください。確認できるものが何もなく、その欠如こそが結論です。
1 から 4 に合格し、5 に言及がない場合：レポート用途のみにしてください。書き込みの制御方法をドキュメントで明示しないサーバーに、書き込み権限を与えないでください。
七つすべてに合格した場合：説明のつく構成です。承認ゲートを有効にし、読み取り権限から始めて、慎重に広げてください。
ChatGPT に追加：ChatGPT のプラグインディレクトリで PaidSync.ai を開き、インストールしてからサインインします。
Claude に追加：Claude のコネクタディレクトリで PaidSync.ai を開き、「接続」をクリックしてからサインインします。
よくある質問
Claude を広告アカウントに接続しても安全ですか？
すべては Claude ではなく、間に入るサーバー次第です。Claude は MCP サーバー経由で広告アカウントとやり取りし、アクセス権を持つのはそのサーバーです。接続する前に、上の七つのブラウザチェックを実行してください。二つの OAuth ディスカバリーファイル、security.txt、MCP サーバーカード、書き込みの制御方法を明記したドキュメント、セッションの取り消し手段、公式 MCP レジストリでの一貫した掲載です。七つすべてに合格し、すべての書き込みに人の承認が必要なサーバーなら、説明のつく構成です。最初の四つに不合格なら確認できるものが何もなく、それが答えです。
MCP サーバーカードとは何で、どこで見つかりますか？
リモート MCP サーバーが /.well-known/mcp/server-card.json で公開する機械可読な JSON ファイルで、サーバーの名前、エンドポイント、ドキュメント、認証方式を記述します。URL をブラウザに貼り付ければ読めます。PaidSync のカード（paidsync.ai/.well-known/mcp/server-card.json）は、14 のプラットフォームにまたがる 630+ のツールを宣言し、認証を必須とし、OAuth フローに PKCE を求めています。リモートの広告 MCP サーバーにカードも OAuth ディスカバリーファイルもなければ、自分について何も語らないエンドポイントに接続することになります。
広告 MCP サーバーは、確認なしにキャンペーンを変更できますか？
技術的には可能です。サーバーが制御のない書き込みツールを公開し、書き込み権限を付与した場合です。だからチェック 5 があります。ドキュメントに制御の仕組みが明記されている必要があります。PaidSync は、書き込みごとの人によるチェックをアシスタント自身の確認プロンプトに任せており（paidsync.ai/security に記載）、ほとんどの書き込みツールで dry_run によるプレビューに対応し、稼働中のキャンペーンを変更する操作には confirm_destructive パターンを適用しています（paidsync.ai/docs/meta-bulk-operations に記載）。ドキュメントが「安全」「セキュア」と書くだけで、テストできるパラメータを示していないなら、書き込みは制御されていないと考えてください。
postmark-mcp の事件とは何でしたか？
2025年9月、Koi Security の研究者が、実際に確認された初の悪意ある MCP サーバーを見つけました。postmark-mcp という npm パッケージで、Postmark の正規ライブラリになりすましていました。バージョン 1.0.16 から、送信されるすべてのメールを攻撃者のアドレスにブラインドコピーする一行のコードが追加されていました。削除されるまでに 1,643 回ダウンロードされました（The Hacker News による）。広告主にとっての教訓は、このパッケージは確認可能なチェックにひとつも通らなかったということです。ローカルにインストールするパッケージはセキュリティ上の姿勢をまったく公開しないためです。OAuth ディスカバリーファイル、security.txt、レジストリへの掲載を公開しているリモートサーバーなら、接続前に確認できる材料があります。
Meta は 2026 年に AI ツールを接続した広告主を停止しましたか？
未確認です。2026年春、一部の広告担当役員がオンラインの議論で、AI ツールを導入した後に Meta の広告アカウントが制限または停止されたと主張しました。Digiday は2026年4月29日に、両者の公式な関連は確認されていないと報じており、Meta も広告アカウントへの措置を AI ツールと結びつける声明を出していません。主張されたケースに共通していたのは、生の API トークン、無人で動くエージェント、承認ステップなしという形でした。承認制の書き込みと取り消し可能なセッション（チェック 5 と 6）は、まさにその形に備えて作られています。
公式の Google Ads MCP サーバーは、サードパーティのものより安全ですか？
It carries less write risk: its README (read 7 Nov 2026) lists writes for assets and labels, each proposed first and confirmed second. Google's open-source Google Ads API MCP server, announced October 7, 2025, exposes seven tools in its repository since its 2 Nov 2026 release: search, resource metadata, an accessible-customers list, and four that create assets and manage labels. That makes it a solid reporting companion. The moment you want an AI to actually pause an ad, add negatives, or shift budget, you are choosing a third-party server, and that is precisely when this checklist matters most.
MCP サーバーによる広告アカウントへのアクセスを取り消すには？
層に分けて考えます。ツール側では、信頼できるサーバーは自身のダッシュボードからセッションとキーを解除できます。PaidSync は paidsync.ai/connect-mcp で、アクセスは PaidSync ダッシュボードから随時取り消せると明記しています。プラットフォーム側では、OAuth ベースのツールなら、広告プラットフォーム自体からもアクセスを遮断できます。Google ではセキュリティ設定のサードパーティアクセス、Meta では Business 設定の連携です。長期有効な生の API トークンを貼り付けさせるツールでは、認証情報をローテーションし続けることになり、遅く、忘れやすくなります。