MCPでAIアシスタントをSMMパネルに連携する方法

MCP（Model Context Protocol）とは、AIアシスタントが外部のサービスを「道具」として呼び出すための公開された接続規格であり、Panel Followsにおいては、あなたのパネルアカウントをAIアシスタントから直接操作できるようにする仕組みを指します。パネルの画面を開いてサービスを探し、数量を入れて金額を確かめる、という一連の作業を、アシスタントとの会話の中で完結させられます。

この記事は宣伝ではなく、接続の手順書です。どのツールがどんな名前で用意されているか、権限をどこまで絞れるか、トークンが何時間で切れるか、失敗したときに何が返るか。実装されている動作だけを、確認できる形で書いていきます。画面に出ている文字は日本語表示のものをそのまま「」で囲みました。

先に結論を3つ書いておきます。ひとつ目、**接続にパネルのパスワードは使いません。**OAuth 2.1の流れで、承認はパネル側の画面で行われ、AIクライアントにパスワードが渡ることはありません。ふたつ目、**アシスタントは残高を入金できません。入金、出金、価格の変更、サポートチケットの作成は、ツールとして存在しません。3つ目、「閲覧のみ」を選ぶと、注文系のツールはアシスタントから見えなくなります。**呼ばないようにお願いするのではなく、一覧から取り除きます。

拾い読みで構いませんが、「アシスタントはどの順番で注文を出しますか？」と「料金の読み違いはなぜ起きるのですか？」の2章だけは、実際に注文させる前に目を通してください。金額の事故はこの2つに集中します。

MCPとは何か、SMMパネルでは何を意味するのか

MCPは、AIアシスタントと外部システムのあいだをつなぐ規格です。従来、モデルに何かをさせたければ、開発者がAPIを呼ぶコードを書き、結果を整形してプロンプトに戻していました。MCPはこの往復を標準化し、サーバー側が「どんな道具があるか」「各道具はどんな引数を取るか」を機械可読な形で公開します。クライアントはそれを読み取り、モデルに提示します。

つまり、パネル側が「サービスを検索する道具」「金額を先に計算する道具」「注文を出す道具」を定義して公開しておけば、対応したAIクライアントであればどれでも、追加の実装なしにその道具を使えるということです。あなたが書くコードはゼロです。

SMMパネルの文脈では、これは次のような日常の作業に効きます。

• カタログの中から条件に合うサービスを探す（プラットフォーム、カテゴリー、補充対応の有無、価格帯で絞り込む）
• 注文を出す前に、正確な請求額と注文後の残高を確認する
• 進行中の注文の残数や状態を、履歴ページを開かずに確認する
• 完了した注文について、補充（リフィル）が使える条件を満たしているかを判断する
• 複数の注文をまとめて出す

Panel Followsのパネル画面では、左側のメニューに「AIアシスタント」という項目があり、アドレスは /dashboard/mcp です。ページの説明文はこう書かれています。「Claude や ChatGPT などのAIアシスタントをアカウントに接続します。サービス検索、料金確認、注文、進捗確認まで行えます。」

ここで正直に線を引いておきます。MCPは「AIがあなたの代わりに賢く運用してくれる仕組み」ではありません。**アシスタントは、パネルが公開している道具を、あなたの指示に従って呼び出すだけです。**どのサービスが自分の目的に合っているか、その数量が妥当か、その価格が納得できるかを判断するのは、これまでどおりあなたです。この記事でも「自動で最適化される」「任せておけば増える」といった書き方はしません。

パネル自体の操作手順、注文フォームの構成、残高チャージの流れについてはPanel Followsの使い方ガイドにまとめてあります。MCPはその上に載る接続層なので、パネルの基本動作を知っていたほうが理解が速くなります。

「MCPサーバー」という言葉の意味

MCPの用語では、道具を提供する側を「MCPサーバー」、道具を使う側（AIアプリ）を「MCPクライアント」と呼びます。名前に「サーバー」と付いていますが、あなたが何かをインストールしたり起動したりする必要はありません。Panel Follows側ですでに動いており、あなたがすることは、クライアントに接続先のアドレスを1行登録するだけです。

接続先は次のアドレスです。

https://panelfollows.com/api/mcp/user

このアドレスは、ログイン後の「AIアシスタント」ページの「接続アドレス」という見出しの下にも表示され、「コピー」ボタンが付いています。子パネル（ホワイトラベル）の顧客としてログインしている場合は、そのパネル自身のドメインのアドレスが表示されます。

パネルにはMCPサーバーが2つあります。どちらがあなたのものか？

Panel Followsは、まったく別の目的を持つ2つのMCPサーバーを運用しています。名前が似ているため混同されやすいので、最初に切り分けておきます。

	ユーザー用サーバー	管理用サーバー
エンドポイント	POST /api/mcp/user	POST /api/mcp
接続するのは誰か	パネルの利用者（あなた）	パネルの運営者
認証の方法	OAuth 2.1のトークン、またはアカウントのAPIキー	単一の秘密鍵（MCP_SECRET）
できる範囲	自分のアカウントのみ、18個のツール	パネル全体、57個のツール
監査ログ	aiAuditLog（アカウントIDが入る）	aiAuditLog（アカウントIDは空）

**この記事が扱うのは左側、ユーザー用サーバーです。**あなたが接続できるのはこちらだけで、右側の管理用サーバーはパネル運営者専用です。2つは同じ中核部品（src/lib/mcp/transport.ts）の上に載っていますが、公開されているツールも認証方式もまったく別です。

利用者側のサーバーは、1回のリクエストにつき常にひとつのアカウントに紐づいています。ツールは他の利用者のデータを見ることができず、価格設定、仕入先、他アカウントといった運営側の機能には一切到達できません。これは「見えないようにしている」のではなく、そもそもツールとして定義されていません。

通信のしくみ：Streamable HTTP と JSON-RPC 2.0

技術的な中身を短く書いておきます。自分でクライアントを実装する場合以外は読み飛ばして構いません。

• 通信は Streamable HTTP 上の JSON-RPC 2.0 です。**状態を持ちません。**セッションIDは発行されず、各リクエストが独立しています。
• SSE（Server-Sent Events）のストリームはありません。GET でアクセスするとHTTP 405が返り、「SSEは非対応、JSON-RPCにはPOSTを使うこと」という趣旨の応答になります。ブラウザでアドレスを開いて405が出るのは、故障ではなく仕様です。
• 対応しているメソッドは initialize、tools/list、tools/call、prompts/list、prompts/get、ping、resources/list、resources/templates/list です。後ろの2つは空のリストを返します。
• プロトコルのバージョンは 2025-06-18 が本来のもので、後方互換として 2025-03-26 と 2024-11-05 も受け付けます。どれを使うかは initialize の時点で折り合いがつきます。
• JSON-RPCのバッチ（配列でまとめて送る形）に対応しています。通知だけを含むリクエストには、本文なしのHTTP 202が返ります。
• ツールのエラーはプロトコルのエラーではありません。isError: true を含むテキストとして返るため、モデルがエラーメッセージを読んで自分で直せます。
• ツールの出力は100,000文字で打ち切られます。
• tools/list の応答には、各ツールに readOnlyHint と destructiveHint というヒントが付きます。クライアントはこれを見て「確認を挟むべき操作かどうか」を判断できます。

アシスタントが使える18個のツールは何ですか？

ユーザー用サーバーが公開しているツールは18個です。分野ごとにまとめます。ツール名は英語のまま、以下の表記が実際の名前です。

分野	ツール
アカウント	get_account
カタログ	list_platforms、list_categories、search_services、get_service
注文	preview_order、create_order、create_orders_bulk、list_orders、get_order、cancel_order、refill_order
補充	list_refills、get_refill
自動化	list_events、list_webhooks、create_webhook、delete_webhook

このうち**12個は読み取り専用、6個が書き込みを行います。**書き込み側だけを取り出すと、create_order、create_orders_bulk、cancel_order、refill_order、create_webhook、delete_webhook の6つです。

さらに「破壊的」という別のヒントが付いているものがあります。破壊的として印が付くのは create_order、create_orders_bulk、cancel_order、delete_webhook の4つです。refill_order と create_webhook は書き込みを行いますが、既存のものを壊さないため破壊的の印は付いていません。

ヒント	対象ツール	クライアント側の扱われ方
読み取り専用	上記12個	確認なしで呼ばれることが多い
書き込み・非破壊	refill_order、create_webhook	何かを新しく作るが、既存を消さない
書き込み・破壊的	create_order、create_orders_bulk、cancel_order、delete_webhook	多くのクライアントで実行前の確認が入る

主要ツールの中身

get_account は、アカウントの識別子、メールアドレス、利用可能な残高（USD）、リクエスト制限を返します。注文の前に残高が足りているかを確かめるためのツールです。

search_services はカタログの検索です。絞り込みに使えるのは search（サービス名に含まれる文字）、platform、category、type、refill、cancel、dripfeed、min_rate、max_rate です。1ページの件数は既定が20件、最大50件です。返る価格は、あなた自身の価格設定に基づいた金額です。

get_service は1件のサービスの詳細です。価格、最小値と最大値、補充・キャンセル・ドリップフィードの対応状況、平均所要時間、そして**注文に必要な入力項目の一覧（fields）**が返ります。ここが地味に重要で、どの項目が必須かをモデルに推測させず、サーバーから読ませるための仕組みです。

preview_order は、注文を出さずに内容を検証し、金額を計算します。返るのは charge（請求額）、balance_after（注文後の残高）、sufficient_balance（残高が足りているか）です。引数は create_order とまったく同じなので、同じ内容をそのまま本番に流せます。

create_order は実際に注文を作成し、残高から差し引きます。実際のお金を使い、取り消せません。

create_orders_bulk は1回の呼び出しで最大50件の注文を出します。各項目は順番に処理され、途中の1件が失敗しても残りは処理されます。項目ごとに結果が個別に返ります。

list_orders はアカウントの注文一覧を新しい順に返します。状態での絞り込みに使える値は pending、in_progress、completed、partial、canceled、refunded、failed です。既定20件、最大100件です。

cancel_order は、そのサービスがキャンセルに対応していて（get_service の features.cancel）、かつ注文がまだ完了していない場合にのみ動きます。非対応なら cancel_not_supported が返ります。

refill_order は、完了済みかつ補充保証のある注文にのみ使えます。無料で、残高には影響しません。

create_webhook で新しい送信先を登録すると、署名用の秘密鍵（secret）が応答に一度だけ表示されます。その場で控えないと再表示できません。delete_webhook は送信先を削除し、待機中の送信も破棄します。

一覧系のツールはカーソルでページングします。引数に starting_after を渡し、応答の next_cursor を次のページに使います。

引数の名前はAPI v3と同じです

各ツールはAPI v3のエンドポイントを鏡写しにしたもので、引数の名前もv3とまったく同じです。service、link、quantity、runs、interval、comments、username、posts、min、max、usernames、hashtag、hashtags、answer_number、groups、keywords、media がそのまま使われます。

つまり、開発者向けAPIドキュメントに書かれている項目名は、MCP側でもそのまま通用します。2つの辞書を覚える必要はありません。すでにAPI連携を作っている人にとっては、MCPは同じ機能への別の入口です。

AIアシスタントを接続する手順は？ 3ステップで終わります

パネルの「AIアシスタント」ページには、次の3ステップが日本語で書かれています。実際の画面の文言をそのまま引用します。

1. 「アドレスをコピーし、AIクライアントにMCPサーバーとして追加します。」
2. 「クライアントがこのページへ誘導します。接続を承認してください（閲覧のみも選べます）。」
3. 「あとは『Instagramフォロワーの料金を見せて』『最近の注文の状況は？』と話しかけるだけです。」

補足すると、実際の流れはこうなります。

1. パネルにログインし、メニューの「AIアシスタント」を開きます。アドレスは /dashboard/mcp です。
2. 「接続アドレス」の欄に出ているURLを「コピー」ボタンで取得します。
3. お使いのAIクライアントに、MCPサーバーとしてそのURLを登録します。書き方はクライアントごとに違うので、次の章の表を見てください。
4. クライアントが初回の接続を試みると、ブラウザが開き、Panel Followsの承認画面に移動します。ログインしていなければ先にログイン画面に送られ、ログイン後に同じ承認画面へ戻ります。
5. 承認画面で内容を確認し、必要なら「閲覧のみを許可（注文はできません）」にチェックを入れ、「接続を承認」を押します。
6. ブラウザがクライアントへ戻り、接続が完了します。以後、そのクライアントからアカウントのツールが使えるようになります。

ページの説明文は「このアドレスをAIクライアントに追加してください。承認はこのパネルで行われ、パスワードがクライアントに渡ることはありません。」です。ここが重要な点で、**AIクライアント側にパネルのパスワードを入力する場面はありません。**入力するのはURLだけです。

つまずきやすいのはどこか

経験上、最初の接続で止まるのは次の3か所です。

• **ログインしていない状態でクライアントを起動した。**この場合は承認画面ではなくログイン画面が出ます。ログインすれば元の承認画面に戻るので、クライアント側の操作をやり直す必要はありません。
• **ドメインを取り違えている。**子パネルの顧客アカウントは、その子パネルのドメインからしか有効ではありません。本体パネルのアドレスで接続しようとしてもアカウントは見つかりません。
• **承認画面を開いたまま長く放置した。**認可コードの有効期間は10分です。時間切れになると「接続リクエストが無効か、有効期限が切れています。クライアントからやり直してください。」と表示されます。もう一度クライアント側から始めれば済みます。

クライアント別の設定はどう書きますか？

パネルの「クライアント別の設定」の欄には、コピーできる4種類の例が並んでいます。説明文は「OAuth 2.1 に対応したMCPクライアントであれば利用できます。ヘッダーを送れるクライアントはAPIキーも使えます。」です。

例のラベル	用途
Claude Code	コマンド1行でサーバーを登録する
Cursor / VS Code	設定ファイルにJSONで書く
API key	ヘッダーにAPIキーを載せて登録する
curl	接続を手元で試す

Claude Codeの場合はコマンド1行です。

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user

CursorやVS Codeのように設定ファイルへ書く形式のクライアントでは、次のJSONを使います。

{ "mcpServers": { "panel": { "type": "http", "url": "https://panelfollows.com/api/mcp/user" } } }

APIキーで接続する場合は、ヘッダーを添えます。

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user \
  --header "Authorization: Bearer pf_live_..."

接続が生きているかを確かめたいだけなら、curl でツール一覧を取ってみるのが早いです。

curl -s https://panelfollows.com/api/mcp/user \
  -H "Authorization: Bearer pf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

APIキーの作成場所については、ページ内に「キーで接続したい場合はこちらで作成できます:」という案内と「APIキー」というリンクがあり、APIキーのページへ移動します。

**ここに挙げていないクライアントでも、OAuth 2.1に対応したMCPクライアントであれば同じアドレスで接続できます。**特定の製品向けの専用実装はしていません。逆に言えば、MCPに対応していないアプリからは接続できません。その場合はAPIを直接呼ぶ形になります。設計の考え方はSMMパネルAPIのページにまとめてあります。

OAuth 2.1 は裏側で何をしているのですか？

「URLを登録しただけで、なぜ自分のアカウントに繋がるのか」を説明します。手作業でキーをコピーしていない以上、どこかで身元の確認が行われているはずです。その仕組みがOAuth 2.1です。

流れは6段階です。

1. **クライアントが身元なしでリクエストを送り、401 を受け取ります。**この応答には WWW-Authenticate: Bearer error="...", resource_metadata=".../.well-known/oauth-protected-resource/api/mcp/user" というヘッダーが付きます（RFC 9728）。クライアントはここから「どこを見れば認証の作法が分かるか」を知ります。
2. 探索。/.well-known/oauth-protected-resource を読み、そこから /.well-known/oauth-authorization-server へ辿ります（RFC 8414）。認可の窓口、トークンの窓口、対応している方式などが書かれています。
3. 動的クライアント登録。POST /api/mcp/oauth/register で、クライアントが自分自身を登録します（RFC 7591）。秘密鍵を持たない公開クライアントとして登録され、本人確認はPKCEで行います。この登録はIPあたり1時間に10回までに制限されています。
4. ブラウザが開きます。GET /api/mcp/oauth/authorize から、パネル自身の承認画面 /mcp/connect に転送されます。ログインしていなければ先にログインへ送られ、その後同じ承認画面に戻ります。
5. **あなたが承認します。**必要なら「閲覧のみを許可（注文はできません）」にチェックを入れます。
6. POST /api/mcp/oauth/token で、認可コードがトークンに交換されます。ここでPKCEのS256が必須です。plain は受け付けません。OAuth 2.1の規則にそのまま従っています。

探索の応答に書かれていること

/.well-known/oauth-authorization-server が返す内容のうち、実装するときに効いてくる項目を挙げます。

項目	値	意味
response_types_supported	["code"]	認可コード方式のみ
grant_types_supported	["authorization_code", "refresh_token"]	コード交換と更新のみ
token_endpoint_auth_methods_supported	["none"]	公開クライアント。秘密鍵は使いません
code_challenge_methods_supported	["S256"]	PKCEはS256のみ。plain は非対応
authorization_response_iss_parameter_supported	true	応答に発行元が入ります（RFC 9207）
resource_indicators_supported	true	どの資源向けのトークンかを指定できます（RFC 8707）

PKCEの検証子（code verifier）は43文字から128文字である必要があります。短すぎても長すぎても拒否されます。

戻り先アドレスの制限

登録できる redirect_uris（認可後に戻る先）には制限があります。受け付けるのは、https のアドレス、ループバックのhttp（127.0.0.1 または localhost）、そして cursor:// や vscode:// のようなカスタムスキームです。外部のアドレスへの平文httpは拒否されます。

戻り先は登録済みのリストと一致しなければなりません。唯一の例外がループバックのポート番号で、ここだけは可変を許しています（RFC 8252）。ローカルで動くクライアントは起動のたびに空いているポートを取るためです。

アドレスはリクエストの発信元から作られます

探索文書に載る各アドレスは、リクエストが来たオリジンから生成されます。**子パネルが自分のドメインから接続した場合、発行元（issuer）もそのドメインになり、本体パネルのアドレスは顧客に一切見えません。**ホワイトラベルの前提を、認証まわりでも崩さないための作りです。

APIキーで接続したほうがいいのはどんなときですか？

OAuthの流れはブラウザを開きます。ブラウザが開けない環境、たとえばサーバー上で動かす常駐スクリプトや、CI上の自動処理では、この流れは使えません。そういう場合はAPIキーで接続します。

サーバーが受け付けるBearerの値は3種類です。

値の形	何のキーか	権限
pf_mcp_...	OAuthで発行されたアクセストークン	承認時に選んだ範囲
pf_live_...	API v3のキー	常にフルアクセス
64桁の16進数	従来のリセラーAPIキー	常にフルアクセス

Authorization: Bearer のほか、X-Api-Key ヘッダーでも渡せます。どの経路で来たかは先頭の文字列だけで判別しています。

ここに大事な違いがあります。キーで接続した場合は常にフルアクセスです。「閲覧のみ」の制限が意味を持つのはOAuthの場合だけで、APIキーには権限の絞り込みがありません。読み取りだけをさせたいなら、キーではなくOAuthで接続し、承認画面でチェックを入れてください。

	OAuthで接続	APIキーで接続
ブラウザが必要か	必要（初回のみ）	不要
パネルに残る記録	「接続中のアシスタント」に一覧表示	APIキーのページで管理
権限の絞り込み	「閲覧のみ」を選べる	できません（常にフルアクセス）
有効期間	アクセストークンは8時間、自動で更新	取り消すまで有効
解除の方法	パネルから1クリック、または失効の窓口	キーの再生成で古いキーが無効になる
向いている場面	手元のAIアシスタント	サーバー常駐、ヘッダーを送れるクライアント

APIキーの発行と再生成については、パネルの「API」ページで行います。再生成すると古いキーはその場で無効になるので、稼働中の連携がある状態では気を付けてください。

承認画面では何を見て、何を承認するのですか？

接続の途中で開く承認画面は、パネル自身のページです。アドレスは /mcp/connect で、OAuthの認可の窓口がここへ転送します。検索エンジンには登録されない設定になっており、クライアントが始めた流れの中でしか意味を持ちません。ブックマークして直接開いても、必要な情報が揃っていないため機能しません。

画面には次の要素が並びます。

1. 見出しに「（クライアント名）がアカウントへの接続を求めています」。クライアント名は、そのクライアントが登録時に申告した名前です。
2. 説明文「承認すると、このアプリはあなたに代わって以下の操作を行えます。」
3. 「アカウント」の行に、いま接続しようとしているアカウントのメールアドレス。
4. 「移動先」の行に、承認後に戻る先のアドレス。
5. 「アシスタントにできること」として、権限の一覧。
6. 「閲覧のみを許可（注文はできません）」のチェックボックス。
7. 「接続を承認」と「拒否」のボタン。

権限の一覧には、パネルの他の場所と同じ3行が表示されます。

• 「サービスの検索、料金の計算、注文と残高の確認。」
• 「注文の作成・キャンセル、補充（リフィル）の申請。注文前に必ず確認を求めます。」
• 「残高の入金、出金、パスワードの閲覧、他アカウントへのアクセスはできません。」

この画面で確認すべき2点

**ひとつ目は「アカウント」の行です。**表示されているメールアドレスが、意図したアカウントかどうかを確かめてください。複数のアカウントを使い分けている場合、ブラウザに残っているセッションのアカウントで承認が進みます。

**ふたつ目は「移動先」の行です。**ここには承認後に戻る先のホスト名が出ます。自分が起動したクライアントと関係のないアドレスが出ていたら、承認せずに「拒否」を押してください。とはいえ、戻り先は登録済みのリストと一致しなければならないため、まったく無関係なアドレスがここに現れる余地は構造的に限られています。

承認画面が「接続リクエストが無効か、有効期限が切れています。クライアントからやり直してください。」と表示する場合は、認可コードの10分が切れたか、クライアントの登録が見つからないかのどちらかです。クライアント側で接続をやり直せば解決します。

なお、承認を押した後は「移動しています…」と表示され、自動的にクライアントへ戻ります。処理が途中で失敗した場合は「処理を完了できませんでした。もう一度お試しください。」が出ます。

「閲覧のみ」は具体的に何を止めるのですか？

権限（スコープ）は2種類しかありません。account:read と account:write です。クライアントが何も要求しなかった場合は両方が付与されます。多くのMCPクライアントはスコープを送ってこないためで、そのぶん承認画面であなたが選べるようにしてあります。

承認画面で「閲覧のみを許可（注文はできません）」にチェックを入れると、発行されるトークンには account:read だけが入ります。このとき何が起きるかが、この章の本題です。

サーバーは、その接続に対して書き込み系のツールを一切表示しません。「呼ばないでください」と指示するのではなく、tools/list の応答からツールそのものを取り除きます。

	フルアクセス	閲覧のみ
見えるツールの数	18個	12個
search_services、get_service	使える	使える
preview_order（金額の計算）	使える	使える
list_orders、get_order	使える	使える
create_order、create_orders_bulk	使える	一覧に出ません
cancel_order、refill_order	使える	一覧に出ません
create_webhook、delete_webhook	使える	一覧に出ません

この設計には理由があります。指示に従うかどうかをモデルの善意に委ねるのは、信頼できる方法ではありません。「このツールは呼ばないでください」と書いておいても、長い会話の途中で守られる保証はありません。存在しないツールは呼べないので、一覧から外すほうが確実です。

加えて、閲覧のみの接続では、サーバーがモデルへ渡す説明文に次の趣旨の注記が加わります。「この接続は読み取り専用です。注文の作成、キャンセル、補充のツールはこのセッションに存在しません。注文したい場合は、パネルで『閲覧のみ』の設定を外して接続し直す必要があります。」

つまり、閲覧のみの接続でユーザーが「注文して」と頼んだ場合、アシスタントは黙って失敗するのではなく、「この接続では注文できないので、パネル側で権限を変えてください」と案内できます。

使い分けの目安

閲覧のみが向いているのは、金額を計算させたいが発注はしたくない場面です。たとえば、複数のサービスを比較して見積もりを作らせる、進行中の注文の状況を毎朝まとめさせる、といった用途では読み取りだけで足ります。preview_order は読み取り専用のツールなので、閲覧のみでも金額の計算はできます。ここが実用上ありがたい点です。

逆に、会話の流れでそのまま発注まで済ませたいなら、フルアクセスを選びます。その場合でも、注文の前に確認を求めるようサーバー側の指示が入っています（次章）。

権限を後から変えたい場合は、いったん接続を解除して、承認画面でチェックの状態を変えて接続し直します。既存の接続の権限を編集する画面はありません。

なお、クライアントが openid、profile、email といった見慣れないスコープを要求してきた場合、それらは認識されず静かに落ちます。付与されるのは上の2つのうちの該当分だけです。

アシスタントはどの順番で注文を出しますか？

サーバーはモデルに対して、注文の手順を明示的に指示しています。この指示は接続時にモデルへ渡されるもので、あなたが毎回プロンプトに書く必要はありません。手順は5段階です。

1. **search_services で適切なサービスを探し、サービス番号（id）を控えます。**プラットフォーム、カテゴリー、検索語で絞り込みます。
2. **get_service で詳細を読みます。**最小値と最大値、補充とキャンセルの対応状況、平均所要時間、そして必須の入力項目（fields）を確認します。
3. **preview_order で金額を計算します。**応答の charge（請求額）と sufficient_balance（残高が足りているか）を、利用者にはっきり伝えるよう指示されています。
4. **利用者から明確な承認を得ます。**承認なしに create_order を呼ばないよう指示されています。注文は実際のお金を使い、取り消せないためです。
5. create_order で注文を出し、返ってきた注文番号を利用者に伝えます。

実際の会話は、たとえばこう進みます（あくまで一例で、実際の応答は状況によって変わります）。

あなた: インスタのフォロワーを1000人、補充保証つきで探して

アシスタント: search_services を実行します...
（platform=instagram, refill=true で検索し、候補を提示）

あなた: 3番目のやつで1000人お願い

アシスタント: get_service で詳細を確認し、preview_order を実行しました。
  サービス: （サービス名）
  数量: 1000
  請求額: （金額）USD
  注文後の残高: （金額）USD
  残高は足りています。
  この内容で注文してよろしいですか？

あなた: お願いします

アシスタント: create_order を実行しました。注文番号は （番号） です。

手順を飛ばせないようにしてある理由

3番目の preview_order は、単なる親切ではありません。金額を先に確定させ、利用者の目に触れさせるための段階です。この段階がないと、モデルが自分でカタログの単価から掛け算して「たぶんこのくらい」と言い、それが実際の請求額とずれる可能性があります。

preview_order は create_order とまったく同じ引数を受け取り、注文を作らずに検証だけを行います。ここでエラーになれば、そのまま本番でもエラーになります。つまり、数量が範囲外、必須項目が足りない、残高が不足している、といった問題は、お金が動く前に見つかります。

モデルに伝えられているその他の注意

サーバーの指示には、次の点も含まれています。

• 金額はUSDで、小数を含む文字列として返ります。浮動小数点に変換して丸めないよう指示されています。
• 数量は常にサービスの最小値と最大値のあいだでなければなりません。
• 注文を出した後の進捗は、get_order で開始時のカウンターと残数を読み、list_events で状態の変化を追います。
• **残高の入金、出金、価格の変更、サポートチケットの作成は、これらのツールではできません。**その場合は利用者をパネルへ案内するよう指示されています。
• ツールがエラーを返した場合、エラーコードは固定（例：insufficient_balance、quantity_out_of_range）で、メッセージは利用者の言語で返ります。モデルはメッセージをそのまま伝え、勝手な解決策をでっち上げないよう指示されています。

最後の項目は地味ですが重要です。**AIに一番やらせたくないのは、「たぶんこうすれば直ります」という当てずっぽうの助言です。**エラーの文面をそのまま見せてもらったほうが、あなたが判断できます。

料金の読み違いはなぜ起きるのですか？ per_1000 と per_order の違い

これはMCP固有の話ではなく、SMMパネル全般の落とし穴ですが、AIに計算させるときは特に危険なので独立した章にします。

サービスの価格には2つの単位があります。応答の pricing.unit に、どちらであるかが入っています。

pricing.unit の値	意味	計算のしかた
per_1000	表示価格は1,000個あたり	価格 ÷ 1000 × 数量
per_order	表示価格はパッケージ全体	価格 × 数量

**この区別を見落とすと、金額を1000倍間違えます。**サーバーはモデルに対して、この点を明示的に警告しています。パッケージ型のサービスでは、表示されている数字がそのまま1件分の値段であり、1,000で割ってはいけません。

パネルの画面でも同じ問題があり、情報ボックスのラベルは「1,000個あたりの価格」のまま変わりません。画面から注文する場合の対処法は「合計」の行を読むことですが、MCPの場合の対処法は**preview_order の charge を読むこと**です。ここには実際に請求される金額が入ります。

言い換えると、アシスタントが自分で掛け算した金額を信用しないということです。信用すべきなのは、サーバーが計算して返した charge の値だけです。この記事で繰り返し preview_order を挟むよう書いているのは、そのためです。

コメント型のサービスは数量を送りません

もうひとつの例外があります。カスタムコメント系のサービスでは、quantity を送りません。**コメントを1行に1件ずつ書き、その行数が数量になります。**サーバーの指示にもこの点が書かれています。

たとえば10行のコメントを送れば、数量は10です。数量欄に別の数字を入れる余地はありません。行数を増やしすぎると、意図しない金額になる可能性があるので、送る前に行数を数えてください。

金額は文字列で返ります

細かい話ですが、実装する人向けに書いておきます。金額はUSDの小数を文字列として返します。JavaScriptの Number() に通して丸めると、下位の桁が変わることがあります。モデルにもそのまま扱うよう指示されていますが、自分でクライアントを書く場合は、文字列のまま表示するか、十進の演算を使ってください。

一括注文、ドリップフィード、特殊タイプはどう扱われますか？

一括注文（create_orders_bulk）

1回の呼び出しで最大50件の注文を出せます。各項目は create_order と同じ形式で、順番に処理されます。

重要な性質が2つあります。**ひとつ目、途中の1件が失敗しても、残りの処理は止まりません。**5件目でエラーが出ても、6件目以降は通常どおり処理されます。**ふたつ目、項目ごとに個別の結果が返ります。**どれが成功してどれが失敗したかが、応答から分かります。

合計金額を先に知りたい場合は、項目を1件ずつ preview_order に通してください。一括のツール自体に「合計をプレビューする」機能はありません。手間はかかりますが、50件をまとめて出す前に総額を把握できます。

ドリップフィード（runs と interval）

分割配信は、注文の引数 runs（繰り返し回数）と interval（繰り返しのあいだの分数）で指定します。**ドリップフィードに対応しているサービスでのみ有効です。**対応の有無は get_service の応答で確認できます。

ここで、パネル画面と同じ落とし穴があります。分割配信を指定した場合、quantity は合計ではなく1回あたりの数です。quantity が1000で runs が10なら、届くのは10,000個で、請求も10,000個分になります。金額の確認は、やはり preview_order の charge で行ってください。

分割配信そのものの考え方、速度を落とすことの意味と限界については分割配信と自動サービスの記事で扱っています。配信の速さを変えることは時間の設計であり、安全性の保証ではありません。

特殊なサービスタイプの入力項目

標準的なサービスは link と quantity だけで注文できますが、タイプによって追加の項目が必要です。引数の名前はAPI v3と共通です。

引数	何を入れるか
comments	1行に1件のコメント。行数が数量になります
username	ユーザー名（サブスクリプション型など）
posts	サブスクリプション型で、今後の何件の投稿に適用するか（1から100）
min / max	サブスクリプション型で、投稿ごとの下限と上限
usernames	1行に1つのユーザー名（メンション系）
hashtag	ハッシュタグを1つ
hashtags	1行に1つのハッシュタグ
answer_number	投票で選ぶ選択肢の番号
groups	1行に1つのグループのリンク
keywords	1行に1つのキーワード（SEO系）
media	メディアのリンク（必要なタイプで）

**どの項目が必須かは、サービスごとに違います。**だからこそ get_service の fields を読む段階が手順に入っています。モデルに推測させないための仕組みです。ここを飛ばすと、必須項目が抜けたまま create_order が呼ばれ、エラーになります（お金は動きませんが、往復が増えます）。

サービスタイプごとの入力項目の全体像は、Panel Followsの使い方ガイドの該当章に一覧があります。画面から出す場合と同じ構造なので、そちらを見ておくとMCPからの注文も理解しやすくなります。

アシスタントにできないことは何ですか？

できることより、できないことのほうが大事です。パネルの画面にも、権限の説明として次の一文が出ています。「残高の入金、出金、パスワードの閲覧、他アカウントへのアクセスはできません。」

具体的に、次の操作はツールとして存在しません。

できないこと	補足
残高の入金	支払い方法の選択も決済も、パネルの画面でのみ行えます
出金	引き出しの仕組みに触れるツールはありません
価格の変更	自分の価格設定も、他人への価格も変えられません
サポートチケットの作成	チケットはパネルの「サポート」から作成します
他のアカウントの閲覧	接続は常に1アカウントに固定されています
パスワードの閲覧・変更	パスワードはそもそもこの経路に流れません
管理機能への到達	利用者、仕入先、設定などのツールは公開されていません

「アシスタントがうっかり残高を使い果たす」という心配は、注文についてのみ考えれば足ります。そして注文については、次の3つの歯止めがあります。

1. サーバーがモデルに対し、preview_order で金額を出してから明確な承認を得るよう指示しています。
2. create_order と create_orders_bulk には破壊的のヒントが付いており、多くのクライアントが実行前に確認を挟みます。
3. 「閲覧のみ」で接続すれば、注文のツールはそもそも見えません。

3番目がいちばん強い保証です。1番目と2番目は、モデルとクライアントの挙動に依存します。確実に発注させたくないなら、権限で止めてください。

もうひとつ、当然のことを書いておきます。**アシスタントは、あなたのSNSアカウントにログインしません。**必要なのは公開されているプロフィールや投稿のリンクだけで、SNSのパスワードを求める場面はありません。もしどこかでSNSのパスワードを要求されたら、それはこの仕組みとは無関係です。

セキュリティ：トークンの種類と有効期間はどうなっていますか？

この仕組みで発行される秘密の値は5種類あります。それぞれ用途と寿命が違います。

種類	接頭辞	有効期間
認可コード	pf_mca_	10分、1回だけ使用可能
アクセストークン	pf_mcp_	8時間
リフレッシュトークン	pf_mcr_	90日、使うたびに新しくなります
クライアント識別子	mcpc_	期限なし
APIキー（v3）	pf_live_	取り消すまで有効

いずれも32バイト（256ビット）の乱数をbase64urlで表現したものです。接頭辞が付いているのは、値を見ただけで種類が分かるようにするためで、認証側もこの接頭辞だけで経路を判別しています。

保存のしかた

**データベースには、HMAC-SHA256のダイジェストだけが保存されます。平文はどこにも残りません。**ダイジェストを作るときの鍵（ペッパー）は PANEL_SECRET_KEY から取り、設定されていない場合は BETTER_AUTH_SECRET から導出されます。

これが意味するのは、データベースの中身を見てもトークンの本体は復元できないということです。パネル側の管理画面でも、発行済みのアクセストークンの値を後から表示することはできません。同じ理由で、Webhookの署名用の秘密鍵も作成時に一度だけ表示されます。

使い回しが検知されたとき

トークンの取り扱いで、もっとも危険なのは「同じ認可コードが2回使われる」状況です。正常な流れでは、認可コードは1回だけトークンに交換されます。2回目が来たということは、どこかで値が漏れて第三者が使おうとしている可能性があります。

そのため、**認可コードが2回目に使われた場合、または取り消し済みのリフレッシュトークンが提示された場合、そのクライアントがそのアカウントに対して持っているトークンをすべて取り消します。**部分的に無効にするのではなく、全部です。安全側に倒した動作で、正当な利用者にとっては「接続し直す」だけで復旧します。

リフレッシュトークンは使うたびに新しい値に置き換わります。古い値はその時点で無効になるので、盗まれた古い値は使えません。

アクセストークンが8時間で切れることの意味

アクセストークンの寿命は8時間です。**通常、あなたが何かをする必要はありません。**クライアントがリフレッシュトークンを持っているので、期限が来たら自動的に新しいアクセストークンを取得します。90日間まったく使わなかった場合はリフレッシュトークンも期限切れになるので、その場合はパネルから接続し直します。

もし何らかの理由でクライアントが更新に失敗すると、401 invalid_token が返ります。多くの場合、クライアントを再起動すれば解決します。それでも直らなければ、パネルの「接続中のアシスタント」から一度解除し、接続をやり直してください。

接続をやめたいとき

接続の取り消しには2つの経路があります。ひとつは POST /api/mcp/oauth/revoke という失効の窓口で、クライアント側から呼ぶものです。もうひとつはパネルの画面で、「接続を解除」のボタンを押すだけです。どちらを使っても、そのクライアントのトークンは無効になります。

すべての呼び出しは記録されますか？ 監査ログの中身

はい。**ツールの呼び出しは1件ずつ aiAuditLog というテーブルに記録されます。**記録される項目は次のとおりです。

記録される項目	内容
クライアント	接続してきたクライアントの識別（User-Agent）
アカウント識別子	どのアカウントの操作か
ツール名	呼ばれたツールの名前
引数	ツールに渡された値
結果	応答の内容（後述の例外あり）
エラー	失敗した場合の内容
所要時間	処理にかかった時間

いくつか、実装上の判断が入っている点があります。

**秘密に見える項目は伏せられます。**引数の中に apikey、api_key、secret、password、passphrase、token といった名前の項目があれば、値は *** に置き換えて保存されます。ログを見た人に秘密が漏れないようにするためです。

**読み取り系ツールの結果は保存されません。**カタログの検索結果や注文一覧をすべて保存すると、量が膨大になるわりに後から役に立ちません。一方、**書き込み系ツールの結果は保存されます。**注文が作られた、キャンセルされた、といった記録は残ります。

**引数と結果のJSONは8,000文字で打ち切られます。**長大なコメントのリストなどで、ログが際限なく膨らむのを防ぐためです。

**ログの書き込みは best-effort です。**何らかの理由でログが書けなかった場合でも、本来の処理は止まりません。ログのために注文が失敗する、という事態は起きないようになっています。

何の役に立つのか

いちばん実用的な効果は、ある注文が「AIから出されたのか、パネルの画面から出されたのか」を後から区別できることです。複数人でアカウントを使っている場合や、自動化を組んでいる場合に、原因の切り分けが速くなります。

ユーザー用サーバーからの呼び出しと管理用サーバーからの呼び出しは同じテーブルに入りますが、アカウント識別子が入っているかどうかで区別できます。利用者からの操作にはアカウント識別子が入り、運営側の操作には入りません。

接続中のアシスタントはどこで確認し、どう解除しますか？

パネルの「AIアシスタント」ページ（/dashboard/mcp）の最後の欄が「接続中のアシスタント」です。ここに、いまアカウントに接続されているクライアントが一覧表示されます。まだ何も接続していなければ「接続済みのAIアシスタントはまだありません。」と出ます。

各行には次の情報が並びます。

表示	意味
クライアント名	登録時にクライアントが申告した名前
「フルアクセス」または「閲覧のみ」	承認時に選んだ権限
「接続日」	最初に承認した日
「最終利用」	最後にツールが呼ばれた日。一度も使われていなければ「なし」
「接続を解除」	そのクライアントのアクセスを止めるボタン

「接続を解除」を押すと確認が出ます。文言は「このアシスタントはアカウントにアクセスできなくなります。続行しますか？」です。実行すると「接続を解除しました。」と表示され、そのクライアントのトークンは無効になります。

定期的に見ておくとよい理由

**「最終利用」の欄は、棚卸しに使えます。**試しに繋いだきり使っていないクライアントや、もう使っていないツールがそのまま残っていることがあります。使わない接続は解除しておくのが単純に安全です。

もうひとつ、「フルアクセス」と表示されている接続が、本当にフルアクセスである必要があるかを見直す価値があります。読み取りしかさせていないなら、解除して「閲覧のみ」で繋ぎ直せば、事故の余地がひとつ減ります。

なお、この一覧に出るのはOAuthで接続したものです。APIキーで接続している場合はここには出ず、キーの管理はAPIキーのページで行います。キーを止めたい場合は、キーの再生成が手段になります。

イベントとWebhookで自動化するにはどうしますか？

注文の状態が変わったことを知る方法は2つあります。イベントの一覧を読む方法と、Webhookで通知を受ける方法です。

イベントの種類は次の8つです。名前は翻訳されず、そのままの英語です。

イベント名	いつ発生するか
order.created	注文が作成されたとき
order.processing	注文が処理に入ったとき
order.completed	注文が完了したとき
order.partial	一部完了で終わったとき
order.canceled	注文がキャンセルされたとき
order.updated	注文の内容が更新されたとき
refill.created	補充の依頼が作られたとき
refill.updated	補充の状態が変わったとき

list_events：受け取る側の準備がいらない方法

list_events は、アカウントのイベントを古い順に読み出すツールです。カーソル（starting_after と next_cursor）で前回の続きから読めるので、状態の変化を取りこぼさずに追えます。既定20件、最大100件です。type を指定すれば、特定の種類だけに絞れます。

**この方法の利点は、受け取る側の準備が一切いらないことです。**Webhookを設置するには、公開されたアドレスと、そこで動くサーバーが必要です。手元の端末で開発している場合や、固定のIPアドレスがない場合、Webhookは現実的ではありません。list_events なら、必要なときに読みに行くだけで同じ情報にたどり着けます。

Webhook：3つのツール

Webhookを使う場合は、list_webhooks、create_webhook、delete_webhook の3つを使います。

create_webhook には、イベントを送る先の https アドレス、購読するイベントの種類（省略すると全種類）、任意の説明を渡します。**応答に含まれる署名用の秘密鍵は、そのとき一度だけ表示されます。**この値は後から見られないので、その場で安全な場所に保存してください。署名の検証にこの鍵を使います。

delete_webhook は送信先を削除し、待機中の送信も破棄します。停止したいのに削除したくない場合は、購読するイベントの種類を絞り直すほうが安全です。

list_webhooks では、登録済みのアドレス、購読しているイベント、直近の送信結果が確認できます。届いていないと思ったときは、まずここを見ると原因が絞れます。

Webhookの署名の検証方法やペイロードの形式は開発者向けAPIドキュメントにまとまっています。MCPのツールは同じ仕組みへの入口なので、仕様はそちらと共通です。

定型コマンド（order_status、find_service、reorder）は何をしますか？

サーバーは、よく使う操作を「定型コマンド」として3つ用意しています。MCPの用語では prompt と呼ばれるもので、クライアントによってはスラッシュコマンドやメニューとして表示されます。prompts/list で一覧が取得できます。

コマンド	何をするか	引数
order_status	最近の注文をまとめ、止まっているものや未達のものに印を付けます	count（既定10）
find_service	要望に合うサービスを3件から5件比較し、金額を出します。注文はしません	request（必須）、quantity（任意）
reorder	過去の注文と同じ内容を、確認を取ったうえで出し直します	order_id（必須）

order_status は、指定した件数の注文を読み込み、番号、サービス名、状態、数量、残数、金額を一覧にします。完了していないものや仕入先側でエラーが出ているものは特に強調し、それぞれに何ができるか（キャンセル、補充、待機）を添えるよう指示されています。毎朝の確認をひとことで済ませたい人向けです。

find_service は比較専用です。search_services で候補を探し、価格、最小値と最大値、補充保証の有無、平均所要時間を並べた比較表を作ります。quantity を渡した場合は、いちばん妥当と判断したサービスについて preview_order で金額まで出します。**このコマンドは注文を出しません。**選択肢と金額だけを提示し、判断はあなたに残す作りです。

reorder は、指定した注文番号の内容を get_order で読み、同じサービス、同じリンク、同じ数量で preview_order を実行し、現在の金額を見せて承認を求めます。承認があれば create_order を実行し、なければ何もしません。加えて、同じリンクにまだ進行中の注文がある場合は先に警告するよう指示されています。**価格は変動するため、以前と同じ金額とはかぎりません。**だからこそ、注文のたびに金額を出し直します。

定型コマンドは、これらの操作を毎回自分で説明する手間を省くためのものです。使わなくても、同じことは普通の会話でお願いできます。

リセラーと子パネルのオーナーには何が変わりますか？

子パネル（ホワイトラベル）を運営している場合と、その顧客である場合の話をします。

**顧客側から見ると、違いはほとんどありません。**子パネルの利用者も、自分のAIアシスタントを自分のアカウントに接続できます。「AIアシスタント」のページは同じように表示され、同じ18個のツールが使えます。

ただし、接続アドレスはその子パネル自身のドメインになります。/dashboard/mcp の「接続アドレス」に出るのは、本体パネルのアドレスではなく、あなたが運営しているドメインのアドレスです。

さらに踏み込んで言うと、**OAuthの探索文書に載る発行元（issuer）も、そのドメインになります。**認可の窓口、トークンの窓口、登録の窓口、すべてがその子パネルのドメインで表現されます。アドレスはリクエストが来たオリジンから生成される作りなので、本体パネルのアドレスが顧客の目に触れる箇所はありません。ホワイトラベルの前提が、認証の層でも保たれています。

顧客に案内するときの注意

ひとつだけ、運営者が把握しておくべき制約があります。**子パネルで作られたアカウントは、その子パネルのドメインでのみ有効です。**顧客が本体パネルのアドレスで接続しようとしても、アカウントは見つかりません。案内する際は、必ず自分のドメインのアドレスを伝えてください。

これはMCPに限った話ではなく、ログインでも同じ制約です。ドメインを取り違えたときのエラーは、パスワードが違う場合と同じ文面になるため、原因の切り分けが難しくなりがちです。

自動化としての使いどころ

代理店やリセラーの立場では、MCPは「顧客ごとの見積もりを速く作る道具」として使えます。find_service のようなコマンドで、要望に対する候補と金額を短時間で並べられます。**注文まで自動化するかどうかは別の判断です。**単価と粗利の管理を人の目から外すと、事故の規模が大きくなります。

事業としての設計、原価と価格の考え方についてはゼロから始めるリセラー事業の記事、組織として運用を回す段階の話はSNS代理店のスケーリングの記事にまとめてあります。制度面の詳細は子パネルの案内ページを見てください。

パネル運営者側の管理サーバーはどうなっていますか？

この章は、あなたが接続する対象ではありません。「パネルそのものも同じ protocol で運用されている」という事実を知っておくと、全体像がつかみやすくなるので短く書きます。

管理用サーバーのエンドポイントは POST /api/mcp で、認証は単一の秘密鍵（MCP_SECRET）です。公開されているツールは57個で、ユーザー用の18個とはまったく別の集合です。

• **秘密鍵が設定されていない場合、エンドポイントは完全に閉じています。**HTTP 503を返し、何も応答しません。
• 認証の形式は Authorization: Bearer、X-MCP-Secret ヘッダー、?key= のクエリパラメーターの3つです。比較は一定時間で行われます。
• ツールの守備範囲は、全体の把握と検索、監査、利用者、注文、注文の依頼、サービス、カテゴリー、仕入先、支払い、サポートチケット、クーポン、設定です。
• 歯止めとして、最後に残った有効な管理者は権限を落とすことも停止することもできません。金額に関わる処理はトランザクションと行ロックで原子的に行われます。そしてすべての呼び出しが監査ログに記録されます。

要するに、利用者側と運営者側で、同じ通信の仕組みの上に別々の道具立てが載っています。利用者側から運営側のツールに到達する経路はありません。

MCPとAPIとパネル画面、どれをいつ使うべきですか？

同じ操作に3つの入口があるので、選び方を整理します。

	パネルの画面	API v3	MCP
向いている作業	単発の注文、内容の確認	自社システムからの連携、定型の自動化	会話しながらの検索、見積もり、発注
必要なもの	ブラウザ	コードとAPIキー	対応したAIクライアント
コードを書くか	書きません	書きます	書きません
実行の確実性	高い（自分で操作します）	高い（決まった処理）	モデルの挙動に依存します
一括処理	「一括注文」ページ	まとめて呼べます	1回50件まで
権限の絞り込み	該当しません	ありません	「閲覧のみ」を選べます
記録の残り方	通常の注文履歴	注文履歴	注文履歴に加えて監査ログ

判断の目安はこうです。

• 毎日同じ処理を確実に回したいなら、APIです。決まった手順を決まったとおりに実行することにかけては、これがいちばん確実です。仕様は開発者向けAPIドキュメントにあります。
• その場で調べて、比べて、決めたいなら、MCPです。カタログを検索して条件で絞り、金額を出すところまでを会話で済ませられます。
• 1件だけ出したい、内容をじっくり見たいなら、パネルの画面がいちばん速いことも多いです。カタログはサービス一覧からログインなしで見られます。

3つは排他ではありません。定型処理はAPIで回し、調べものと単発の発注はMCPで、という組み合わせが現実的です。どちらの経路から出した注文も、同じ「注文履歴」に並びます。

うまく動かないとき：エラーの意味と対処

実際に起きる症状と、その原因を並べます。

症状	原因	対処
401 invalid_token	アクセストークンの8時間が切れました	通常はクライアントが自動で更新します。直らなければパネルから接続し直してください
ブラウザで開くと 405	GETでSSEを試みています	このプロトコルはPOSTしか受け付けません。故障ではありません
429	1分あたり600リクエストを超えました	Retry-After の秒数だけ待ってください
「接続リクエストが無効か、有効期限が切れています。」	認可コードの10分が切れたか、クライアントが未登録です	クライアント側から接続をやり直してください
トークンの窓口が400を返す	クライアントが plain のPKCEを送っています	受け付けるのは S256 だけです
戻り先が拒否される	redirect_uri が登録済みのリストと一致しません	一致が必要です。可変を許すのはループバックのポート番号だけです
エンドポイントが503	管理用サーバーで MCP_SECRET が未設定です	運営者側の設定の話で、利用者には関係ありません
アカウントが見つからない	子パネルのアカウントは、そのパネルのドメインでのみ有効です	正しいドメインのアドレスから接続してください

リクエストの上限について

アカウントあたり1分間に600リクエストが上限です。これはAPI v3と共通の上限で、**同じアカウントの操作がMCPから来たかHTTPから来たかは区別されません。**両方を並行して使う場合は、合算されると考えてください。超えるとHTTP 429が返り、Retry-After: 60 が添えられます。

これとは別に、API v3の層でIPあたり1分間に900リクエストの制限もあります。通常の会話で使うぶんには、どちらの上限にも届きません。カーソルでカタログ全体を一気に読み出すような処理を書くときだけ意識してください。

「ツールがエラーを返した」場合

先に書いたとおり、ツールのエラーはプロトコルのエラーとしては返りません。エラーの内容がテキストとして返るので、アシスタントはそれを読んで自分で直せます。数量が範囲外だった、必須項目が抜けていた、といった軽い間違いは、たいてい会話の中で自動的に修正されます。

一方、insufficient_balance（残高不足）のように、あなたが行動しないと解決しないものもあります。**残高の入金はツールにないので、アシスタントは何もできません。**パネルの「残高チャージ」から入金してください。

よくある質問

MCPとは何ですか、短く教えてください。

MCP（Model Context Protocol）は、AIアシスタントが外部のサービスを道具として呼び出すための公開された接続規格です。Panel Followsではこの規格に沿ったサーバーを公開していて、あなたのアカウントのカタログ検索、金額の計算、注文、進捗確認をAIアシスタントから直接行えるようにしています。あなたが書くコードはありません。接続先のアドレスをクライアントに1行登録するだけです。

アシスタントにパネルのパスワードを渡す必要がありますか。

いいえ。接続はOAuth 2.1の流れで行われ、承認はPanel Follows側の画面で完結します。パネルの説明文にも「承認はこのパネルで行われ、パスワードがクライアントに渡ることはありません。」と書かれています。AIクライアントに入力するのは接続先のURLだけで、パスワードは一切この経路を通りません。SNSのアカウントのパスワードも同様に不要です。

アシスタントは私の許可なく注文を出せますか。

構造としては、フルアクセスで接続していれば注文のツールは使えます。ただしサーバーはモデルに対して、金額を preview_order で出したうえで明確な承認を得るよう指示しており、注文のツールには破壊的のヒントが付いているため多くのクライアントが実行前に確認を挟みます。**確実に発注させたくない場合は、承認画面で「閲覧のみを許可（注文はできません）」にチェックを入れてください。**その接続では注文のツールがそもそも一覧に現れません。

どのAIクライアントに対応していますか。

OAuth 2.1に対応したMCPクライアントであれば利用できます。パネルの設定例にはClaude Code、Cursor、VS Code、curlの4種類が載っていますが、これは書き方の例であって、対応の範囲を限定するものではありません。ヘッダーを送れるクライアントであればAPIキーでの接続もできます。MCPに対応していないアプリからは接続できないので、その場合はAPIを直接呼ぶ形になります。

接続を解除するにはどうしますか。解除すると何が起きますか。

パネルの「AIアシスタント」ページの「接続中のアシスタント」の欄で、対象の行の「接続を解除」を押します。確認が出て、実行すると「接続を解除しました。」と表示されます。そのクライアントのトークンは無効になり、以後アカウントにアクセスできません。すでに出した注文は取り消されず、そのまま処理が続きます。

アクセストークンはどのくらい有効ですか。毎回つなぎ直す必要がありますか。

アクセストークンの有効期間は8時間ですが、通常あなたが何かをする必要はありません。クライアントが持っているリフレッシュトークン（90日、使うたびに新しくなります）で自動的に更新されます。90日間まったく使わなかった場合や、更新に失敗した場合だけ、パネルから接続し直してください。

アシスタントに残高をチャージさせられますか。

できません。入金、出金、価格の変更、サポートチケットの作成は、ツールとして存在しません。パネルの権限説明にも「残高の入金、出金、パスワードの閲覧、他アカウントへのアクセスはできません。」と明記されています。残高が足りない場合、アシスタントは insufficient_balance のエラーを伝えることしかできないので、入金はパネルの「残高チャージ」から行ってください。

APIキーとOAuth、どちらで接続すべきですか。

手元のAIアシスタントから使うならOAuthです。ブラウザで一度承認するだけで済み、権限を「閲覧のみ」に絞れて、パネルの一覧で管理と解除ができます。ブラウザを開けない環境（サーバー上の常駐処理など）ではAPIキーを使いますが、**キーで接続した場合は常にフルアクセスになり、権限の絞り込みはできません。**読み取りだけをさせたいならOAuthを選んでください。

アシスタントが出した注文はパネルで見られますか。

見られます。MCPから出した注文も、パネルの画面から出した注文も、同じ「注文履歴」に並びます。加えて、ツールの呼び出しは監査ログに記録されるため、その注文がAI経由で出されたのかパネルの画面から出されたのかを後から区別できます。記録される項目は、クライアント、アカウント識別子、ツール名、引数、結果、エラー、所要時間です。

子パネルの顧客も自分のアシスタントを接続できますか。

できます。子パネルの利用者にも同じ「AIアシスタント」のページが表示され、同じ18個のツールが使えます。ただし**接続アドレスはその子パネル自身のドメインになり、OAuthの発行元もそのドメインです。**本体パネルのアドレスが顧客に見えることはありません。子パネルのアカウントはそのドメインでのみ有効なので、案内するときは必ず自分のドメインのアドレスを伝えてください。

ツールがエラーを返したらどうなりますか。

ツールのエラーはプロトコルのエラーとしてではなく、isError: true を含むテキストとして返ります。そのためアシスタントはエラーの内容を読んで、数量の修正や必須項目の追加といった軽い間違いを自分で直せます。エラーコードは固定（例：insufficient_balance、quantity_out_of_range）で、メッセージは利用者の言語で返ります。サーバーはモデルに対し、メッセージをそのまま伝えて勝手な解決策を提案しないよう指示しています。

MCPを使うのに追加の料金はかかりますか。

**注文そのものの代金以外に、追加の料金はかかりません。**MCPは既存のアカウントへの別の入口であり、利用に対する課金はありません。注文を出せばその注文の金額が残高から引かれますが、それはパネルの画面から出した場合とまったく同じ金額です。リクエストの上限もAPI v3と共通で、MCPを使うために別枠を買う必要はありません。

補充（リフィル）やキャンセルはいつでも使えますか。

いいえ。どちらもサービス側の対応状況に依存します。refill_order が使えるのは完了済みかつ補充保証のある注文だけで、cancel_order が使えるのはそのサービスがキャンセルに対応していて、かつ注文がまだ完了していない場合だけです。対応していないサービスでは cancel_not_supported のような結果が返ります。対応の有無は get_service の応答で事前に確認できます。減少と補充の関係はフォロワー減少と補充保証の記事で詳しく扱っています。

まとめ：接続する前のチェックリスト

最後に、実際に操作するときに見返せる形でまとめます。

1. パネルにログインし、メニューの「AIアシスタント」（/dashboard/mcp）を開いたか
2. 「接続アドレス」のURLをコピーしたか。子パネルの利用者なら、自分のパネルのドメインになっているか
3. 使うクライアントの書き方（コマンド1行か、JSONの設定ファイルか）を確認したか
4. 承認画面で「アカウント」のメールアドレスが意図したものか確認したか
5. 「移動先」が、自分が起動したクライアントのものか確認したか
6. 読み取りだけで足りるなら、「閲覧のみを許可（注文はできません）」にチェックを入れたか
7. 注文させる前に、preview_order の charge を必ず見せてもらう習慣にしたか
8. パッケージ型のサービスでは、価格が1,000個あたりではなくパッケージ全体である可能性を理解しているか
9. 分割配信を使う場合、quantity が1回あたりの数であることを理解しているか
10. 使っていない接続が「接続中のアシスタント」に残っていないか、ときどき見直しているか

この10項目を通しておけば、この記事で挙げた失敗のほとんどは避けられます。仕様の細部で迷ったらよくある質問のページを確認し、それでも解決しなければパネルの「サポート」からチケットを開いてください。まだアカウントをお持ちでない場合は、新規登録から始めて、そのままAIアシスタントを接続できます。