目次

「MCP サーバーでお金は稼げるのか」。答えは「稼げる。ただし MCP の仕様そのものには課金の仕組みが無いので、お金を受け取る仕組みは自分で選んで組み込む必要がある」だ。

ネットでは「公開 MCP サーバーは12,000本以上、収益化に成功しているのは5%未満」という数字がよく出回っている。だが発行元をたどっても、元の調査が見つからない。そこで本記事は、この数字を使わない。代わりに使うのは、公式レジストリの件数を自分で数えた結果、MCP 仕様の原文、各マーケットプレイスの規約とドキュメントの原文だ。確認日はすべて 2026年9月30日。

MCP サーバーの数 · 出典ごと

「何本あるか」は、誰が何を数えたかで桁が変わる

— そして「何本が稼いでいるか」を数えた一次データは見つからない

MCP 公式レジストリ
37,619 件
API で全件を数えた（最新版のみ）。2026-09-30
Anthropic の発表
10,000 超
「稼働中の公開 MCP サーバー」。2025-12-09
Glama のディレクトリ
94,143 件
サイト上の表示。2026-09-30
MCPize（有料販売の場）
1,050 超
サイト上の表示。無料と有料の両方を含む。2026-09-30

公式レジストリの登録情報（server.json）には料金の項目が無い。
だから「全体の何%が有料か」は、公式のデータからは数えられない。

1. MCP サーバーは何本あるのか——数え方で桁が変わる

まず「市場の大きさ」から確かめる。数え方の違う4つの数字を並べると、桁がそろわないことが分かる。

出典数字何を数えているか時点
MCP 公式レジストリ（API を当サイトで集計）37,619 件登録されたサーバーの最新版（うち稼働中 37,170・非推奨 449、リモート接続先を持つもの 23,247・パッケージで配るもの 15,759、両方 1,843）2026-09-30
Anthropic の発表10,000 超「稼働中の公開 MCP サーバー」2025-12-09
Glama94,143 件Glama が集めて載せているサーバー2026-09-30
MCPize1,050 超MCPize のマーケットに載っているサーバー（無料と有料の両方）2026-09-30

公式レジストリは、名前空間（GitHub アカウントやドメイン）の持ち主であることを確かめてから登録させる。GitHub に置かれたリポジトリを広く拾うディレクトリとは、数える対象がそもそも違う。「MCP サーバーは何本」という数字を見たら、まず「誰が、何を数えたか」を確かめるのが最初の判断軸になる。

では「そのうち何本が稼いでいるか」は数えられるか。公式レジストリの登録情報（server.json）が持つのは、名前・説明・バージョン・パッケージの置き場所・リモート接続先の URL などで、公式の説明にも料金の項目は無い。有料か無料か、いくら売れているかは、公式のデータからは分からない。「収益化に成功しているのは○%」と言い切る数字を見かけたら、それが何をどう数えたものかを確かめてから使うべきだ。

そのうえで言えるのは、MCP は「作ること」より「お金を受け取る仕組みの選択」のほうが難しいということだ。理由は次の章の仕様にある。

2. なぜ MCP は「無料」に寄りやすいのか——仕様にあるもの・無いもの

MCP のサーバーが無料で配られやすいのには、構造的な理由が3つある。

  • ① プロトコルがオープン: MCP は2025年12月に、Linux Foundation の傘下に作られた Agentic AI Foundation（AAIF）へ寄贈された（Anthropic の発表）。誰でも実装できるので、差別化はサーバーが届けるデータやロジックでしかつけられない。
  • ② 真似しやすい: サーバーのコードを公開すれば、同じ機能のものは誰でも作れる。オープンソースであることが、独占的な収益を難しくする。
  • ③ 仕様に課金の標準が無い: MCP の仕様が定めているのは「つなぐ」「認可する」までで、料金・決済・利用量の数え方は定めていない（下の表）。

③を仕様の原文で確かめる。最新の仕様（2026-07-28 版の Authorization）と、公式ドキュメントの一覧（llms.txt）を読んだ結果が次の表だ。

項目仕様にあるか原文で確かめたこと（2026-09-30）
認可（誰に使わせるか）ある（ただし任意）認可は OPTIONAL（任意）で、使う場合は OAuth 2.1 をもとにした流れになり、MCP サーバーは OAuth のリソースサーバーとしてアクセストークンを確かめる
対象の通信方式HTTP のみHTTP 系の通信は仕様に従うのが推奨で、ローカルの STDIO 接続はこの仕様に従わず、環境から資格情報を取る（＝API キーを環境変数で渡す形）
サーバーの発見・登録あるサーバーは OAuth 2.0 Protected Resource Metadata（RFC 9728）で認可サーバーの場所を示し、クライアント登録は Client ID Metadata Documents が推奨（Dynamic Client Registration は後方互換のために残されている）
料金・決済無い仕様にも公式の拡張（MCP Apps・認可の拡張・Tasks・Skills）にも、料金や決済を扱うものは見当たらない
利用量の数え方（従量課金の基礎）無いクライアント側で呼び出し回数を数えて請求する標準は無く、数えるのはサーバー側（またはマーケットのゲートウェイ）の仕事
レジストリの料金表示無い公式レジストリの server.json に料金の項目は無い（レジストリ自体も「プレビュー」段階）

つまり、お金を受け取るには 「MCP の外側」で仕組みを持つしかない。やり方は大きく2つで、(a) 自社サービスのアカウント（OAuth や API キー）にひもづけて、自社側で数えて請求するか、(b) 決済・認証・ホスティングをまとめて持つマーケットプレイスに載せるかだ。次の章の4パターンは、この2つの組み合わせと考えると整理しやすい。

3. マネタイズの4パターン

MCP サーバーでお金を受け取る形は、次の4つに分けられる。

4 PATTERNS

MCP サーバーでお金を受け取る4つの型

① サブスク型
月額・年額で機能や上限を分ける。21st.dev は MCP での部品の取り込みを有料プランの機能として売っている。プラン間の差がはっきりしているほど効く。
② 従量課金型
呼び出しやイベントごとに課金する。Apify は「イベントごとの課金」、MCPize は従量課金とツール呼び出しごとの USDC 課金を用意している。数えるのはサーバー側。
③ APIキー型
MCP サーバーは無料で配り、裏側の有料 API（Bright Data・Exa・Tavily など）の利用で稼ぐ。既存 SaaS の入口として働く。
④ フリーミアム + 上位プラン
無料枠で配り、月間の上限・高度な機能・サポートで有料にする。③と組み合わせることが多い。

③の「APIキー型」は、実際の提供者のドキュメントを読むと形がよく分かる。どれもMCP サーバー自体には値段をつけず、無料枠で試させてから、本体の API の利用で課金する作りになっている。

提供者MCP サーバーの使い始め方お金になるところ
Bright Data新規アカウントに月5,000リクエストの無料枠（リモートでも手元でも動かせる）MCP サーバーは Web Unlocker API の上で動くので、無料枠はアカウント全体の枠と共通で、超えた分が API の利用料になる
ExaAPI キー無しで使える「キー無し」モード（回数制限つき）、OAuth での自分のアカウントへの接続、新規アカウントへの無料クレジット本番利用はアカウントにつないで、Exa の API 料金で払う
Tavilyリモートの MCP サーバーの URL に自分の API キーを付けて使う形（キーが無ければサインインを求められ、キー無しの無料利用も案内あり）Tavily の API の利用料

この形の強みは、MCP の仕様に課金の標準が無いことが弱点にならない点だ。課金はもともと持っている API の仕組みで済むので、MCP サーバーは「使ってもらう入口」に徹すればよい。逆に言えば、売れる API をまだ持っていない個人開発者には、そのままは真似できない。

4. どこで売るか——手数料と支払い条件の比較

稼ぎ方が決まったら、次は売る場所だ。各社の規約・ドキュメントの原文から、手数料と支払い条件を並べた（取得日はすべて 2026-09-30。規約は変わるので、出品する前に必ず原文を読み直す）。

売る場所手数料・取り分課金の形支払い条件出典
MCPize取引総額の20%（2026-06-10以降に課金を始めたサーバーが対象で、それより前に始めたサーバーは15%のまま固定、Stripe の決済手数料も含む）サブスク・従量・買い切り（ツール呼び出しごとの USDC 課金もある）Stripe Connect で毎月（本人確認と税務書類、最低支払額などの条件つき、最低額の金額は規約に書かれていない）利用規約（2026-04-12 更新）・開発者向けページ
Apify Storeイベントごとの課金の場合、開発者の取り分は売上の80%から、実行にかかったプラットフォーム費用を引いた額イベントごとの課金（ほかに、プラットフォーム利用料だけで使わせる形などもある）毎月11日に前月分の請求書が自動で作られ、14日に自動承認（最低支払額は PayPal・Wise が$20、それ以外は$100、届かなければ翌月に繰り越し）料金と費用・支払い
自社サイト + StripeStripe の決済手数料は国ごとに違う（日本の料金ページでカード決済1件あたり3.6%）うえ、サブスクの請求に Stripe Billing を使うと別に Billing 取引額の0.7%自由（自分で作る）Stripe の入金スケジュールに従う（税務・返金・サポートは自分で持つ）Stripe の料金（表示は閲覧する国で変わる）
Smithery公開ページに、作者への収益分配の記載は見当たらない——smithery.ai（「Arcade.dev の一部になった」と告知）
Glama公開ページに、作者への収益分配の記載は見当たらない——glama.ai

数字の読み方を1つ例にする。月 $10 のサブスクを1件売ったときの取り分は、MCPize なら $8（20%の手数料に Stripe の決済手数料が含まれる。入金時の手数料が別にかかる場合がある）。日本で自社サイト + Stripe Billing なら、$10 から 3.6% と 0.7% を引いて約 $9.57（当サイトの計算。通貨換算が要る場合はさらに手数料がかかる）。差は約 $1.57 だが、自社サイトではホスティング・税務・返金・サポートを全部自分で持つ。判断軸は「手数料の差額」と「自分で持つ作業の重さ」の比較で、どちらが得かは売上の規模と、すでに持っている仕組みで逆転する。

Smithery と Glama は、少なくとも公開ページを見る限り「売る場所」ではなく「見つけてもらう場所」として使うのが現実的だ。売る場所と、流入を集める場所は分けて考える。

5. 名前の出ている事例——その数字は誰が言ったか

「○○は6週間で月$10K」のような成功談は多いが、本人や会社の発言までたどれるものは少ない。ここでは、発言者か一次のページまでたどれたものだけを載せる。

事例一次情報で確かめられること確かめられないこと
21st.dev料金ページで、有料の Builder（年払いで月$6・四半期払いで月$8）に「MCP での部品の取り込み無制限」が含まれる（ほかに AI クレジットつきの Builder + AI、チーム向けの Team）売上の数字（よく引かれる「6週間で $10K MRR」は、本人・会社の発言が見つからなかった）
Apify StoreApify の MCP 開発者向けページに、開発者（Twenty の Guillaume Lancrenon 氏）の「ほかの副業では月$500だったが、Apify Store で $2,000 超になった」という声（同じページで Apify は「開発者への支払いは毎月 $500k 超」と表示）この $2,000 は Apify Store 全体の話で、MCP サーバーだけの数字ではない（支払い総額も Apify 自身の表示）
Bright Data・Exa・Tavily公式ドキュメントに MCP サーバーの使い方と無料枠が書かれている（前の章の表）MCP 経由の売上（公表されていない）
Notion・Linear・Sentry・Stripe自社の公式 MCP サーバーを出している（Notion・Linear・Sentry・Stripe）MCP による効果（公表されていない）

見えてくる共通点は2つある。(1) MCP サーバー単体に値段をつけている例より、すでにある有料サービスの一部として MCP を出している例のほうが、はるかに確かめやすい。(2) 単体で売る例は、Apify や MCPize のように決済と支払いを肩代わりする場の上に乗っている。

6. 稼げない構造——よくある失敗パターン

「何%が失敗するか」を示す一次データは無い。ただ、ここまでの仕様と規約から、稼げなくなる構造ははっきりしている。

よくある失敗

無料公開→放置パターンの末路

① 汎用化しすぎ
「ファイル読み書き」「Web取得」など、大手が無料で配っている領域と重なる。差別化できない
② 課金が後付け
仕様に課金の標準が無いので、認可と利用量の数え方を後から入れると、既存の利用者の設定をやり直させることになる
③ 流通戦略なし
GitHub に置いて終わり。レジストリ・ディレクトリへの登録、ドキュメント、発信をどれもやっていない
④ アップデート停止
MCP の仕様は数か月〜1年ごとに改訂されてきた（最新は 2026-07-28 版）。追従しないと動かなくなる
⑤ サポートなし
バグ報告や質問に答えず、信頼を失う。有料で使い続けてもらう理由が消える
⑥ 競合分析なし
同じ領域にすでに何本もある中で「もう1本」を足しても埋もれる。ニッチを狙う

どれも根は同じで、「便利なら誰かが払ってくれる」という前提に立っている。MCP は便利だが、仕様の上では「つなぐ」までしか面倒を見てくれない。お金を受け取る仕組みは、最初から自分で選ぶ必要がある。

7. 個人開発者のプレイブック

「いま個人で MCP マネタイズに挑戦するなら」を、現実的な手順で書く。

① ニッチを決める（最重要）

「すべての SaaS と統合できる MCP」のような汎用品は避ける。「特定の業界 × 特定の作業」を狙う。例: 「会計事務所向けの会計ソフト連携」「不動産の登記書類の読み取り」「歯科医院の予約データの要約」。狭いほど、誰に売るかがはっきりして課金しやすい。

② お金を受け取る仕組みを最初に選ぶ

第2章で見たとおり、MCP の仕様には課金の標準が無い。だから v0.1 の時点で、次のどちらかに決めておく。

  • マーケットに任せる: MCPize（手数料20%・Stripe の決済手数料込み）や Apify Store（売上の80%から実行費用を引いた額）。決済・支払い・ホスティングを肩代わりしてもらえる。
  • 自分で持つ: リモートの MCP サーバーに OAuth 2.1 の認可を付け（仕様の Authorization に従う）、自社のアカウントと Stripe で請求する。手数料は安いが、利用量の数え方も含めて全部自分で作る。

「無料で公開してから後で有料化」は、認可の仕組みを後から入れ直すことになるので避けたい。

③ ドキュメントを動画 + テキストで

「なぜ必要か → 何ができるか → 3分で始められる」を短い画面録画にする。接続の設定は MCP クライアントごとに違うので、主要なクライアントごとの設定例を README に並べておくと問い合わせが減る。

④ 公式レジストリとディレクトリに登録する

MCP 公式レジストリは、ディレクトリやマーケットが情報を取りに来る「元データ」の位置づけだ。登録には GitHub・DNS・HTTP のいずれかで名前空間の持ち主であることを証明する。注意点は2つ。一度公開したサーバーは今のところ削除・非公開にできないこと、同じバージョンの情報は後から書き換えられない（新しいバージョン番号で出し直す）ことだ（公式 FAQ）。そのうえで Smithery・Glama・PulseMCP などのディレクトリにも載せる。売る場所と、見つけてもらう場所は別と考える。

⑤ コミュニティに「住む」

MCP の公式リポジトリの議論、MCP 関連のコミュニティ、X などで、アップデートや使い方の例を定期的に発信する。仕様の改訂や新しい拡張もそこで最初に話題になるので、④のアップデート停止を防ぐ役にも立つ。

⑥ 期限を決めて続ける

最初の数か月で結果が出ないことは珍しくない。ただ、だらだら続けるのでもなく、「いつまでに何人の有料ユーザー」という目安を自分で決め、届かなければニッチを変える。

8. 企業の戦略——MCP は「製品の一部」

個人開発者と企業では戦略がまったく違う。企業は 「MCP サーバー単体で稼ぐ」よりも、既存 SaaS の入口として MCP を提供するのが王道だ。

典型例:

  • Notion / Linear / Sentry / Stripe: 既存のユーザーが AI から操作できるよう、公式の MCP サーバーを出している。狙いは本体のサービスを使い続けてもらうこと。
  • Bright Data / Exa / Tavily: 検索・スクレイピング API の新しい売り場として MCP を使う。無料枠で試させ、API の利用で課金する（第3章の表）。
  • AI モデルの提供元: MCP 自体には課金しないが、MCP でできることが増えるほど、自社のモデルや API が使われる間接的な収益になる。

これらは皆、「MCP は無料で出して、本体の有料サービスに送る」パターンだ。企業にとって MCP は、新しい顧客獲得の入口と考えると判断がはっきりする。

9. これから見ておくべき変化

数年後の市場規模を当てるより、前提を変えうる動きを追うほうが役に立つ。2026年9月30日時点で見えているものは次のとおり。

  • 仕様に課金の仕組みが入るか: いまの仕様と公式の拡張（MCP Apps・認可の拡張・Tasks・Skills）に、料金や決済を扱うものは無い。拡張の仕組み自体はあるので、課金の拡張が出れば前提が変わる。拡張の一覧を見ておく。
  • 公式レジストリの正式版: いまは「プレビュー」で、正式版の前にデータのリセットや互換性の無い変更がありうると明記されている。
  • マーケットの統合と規約の変更: Smithery は Arcade.dev の一部になったと告知している。MCPize は手数料を15%から20%に上げた（2026-06-10以降に課金を始めたサーバーから）。売る場所の条件は変わる前提で、規約の更新日を定期的に確かめる。

逆に言えば、「仕様の外で課金する」形は、仕様がどう変わっても使える。自社のアカウントと API で課金する③の型が企業に選ばれているのは、この安定さのためでもある。

まとめ

  • MCP サーバーでマネタイズはできる。ただし MCP の仕様には料金・決済・利用量の数え方の標準が無い（認可は OAuth 2.1 ベースで任意）ので、お金を受け取る仕組みは MCP の外で選ぶ。
  • 「12,000本中5%未満が収益化」という数字は発行元が見つからない。公式レジストリには料金の項目が無く、有料の割合は公式のデータからは数えられない。
  • サーバーの数は数え方で桁が変わる: 公式レジストリ 37,619 件・Glama 94,143 件（どちらも 2026-09-30）、Anthropic の発表で「稼働中の公開サーバー10,000超」（2025-12-09）。
  • 稼ぐ4パターン: サブスク / 従量課金 / APIキー型 / フリーミアム。確かめやすい成功例は、既存の有料 API の入口として出す APIキー型。
  • 売る場所: MCPize（手数料20%・2026-06-10より前に始めたサーバーは15%）/ Apify Store（売上の80%から実行費用を引く）/ 自社 + Stripe（日本でカード3.6%・Billing 0.7%）。Smithery・Glama は「見つけてもらう場所」。
  • 個人開発者のプレイブック: 狭いニッチ + お金を受け取る仕組みを最初に選ぶ + 動画ドキュメント + 公式レジストリとディレクトリに登録 + 発信 + 期限を決めて続ける。
  • 企業の戦略: 既存 SaaS の入口として MCP を無料で出し、本体の収益に送る。

MCP は HTTP や OAuth と同じ「インフラ」の層になりつつある。インフラそのものに値段をつけるのは難しい。だがインフラの上に、お金を受け取る仕組みまで含めた「家」を建てることはできる。

FAQ

Q1. プログラミング初心者でも MCP マネタイズに参入できる？

条件付きで可能。公式の Python・TypeScript の SDK を使えば、動くサーバーを作るところまでは難しくない。ただし「動くサーバー」と「お金を受け取れるサーバー」の差は大きい。認可と課金はマーケット（MCPize・Apify など）に任せ、最初は自分の業務で使えるものを作って、実際の利用者の声を集めてから有料化するのが現実的だ。

Q2. 自社サイト + Stripe と MCPize、どちらがいい？

手数料だけなら自社サイトが安い（日本で Stripe のカード3.6% + Billing 0.7% に対し、MCPize は20%）。ただし MCPize の20%には決済手数料・ホスティング・税務対応が含まれ、自社サイトではそれを全部自分で持つ。「手数料の差額」が「自分で持つ作業のコスト」を上回るかどうかで決める。売上が小さいうちはマーケット、大きくなってから自社に移すのが一般的な考え方だが、移るときは利用者に接続先と認可をやり直してもらう手間が出る。

Q3. オープンソースで公開して、有料サポートで稼ぐモデルは？

成立する。Linux ディストリビューションの有料サポートと同じ型だ。ただ個人開発者には難しい——サポート対応に時間を取られて開発が止まる。本業の傍らなら、サブスクか従量課金のほうが向く。

Q4. 既存の有料 SaaS（Notion など）を競合にする MCP サーバーで稼げる？

原理的に厳しい。Notion が公式の MCP サーバーを出している以上、それより便利なものを作るのは難しい。「公式が手薄な機能」を補うなら可能性はある（高度な分析、特定業界向けのテンプレート、連携先の拡張など）。

Q5. 公式の MCP レジストリに載せれば、そこで売れる？

売れない。公式レジストリはサーバーの情報（メタデータ）を置く場所で、料金の項目も決済の仕組みも無い。公式の説明でも、主な利用者はディレクトリやマーケットなどの「下流の集約サービス」とされている。売るのはマーケットか自社サイト、見つけてもらう入口の1つが公式レジストリ、という役割分担になる。

Q6. AI が自動で MCP サーバーを生成する時代になったら、開発者の収益は消える？

「動くだけのサーバー」は自動で作れるようになる。だが「利用者に信頼されるサーバー」は別だ。稼働の保証、サポート、業界の専門知識、仕様の改訂への追従——これらは AI が作っただけでは満たせない。「最初の動くものは AI が作り、運用・改善・信頼づくりは人間」という分担になっていくと考えられる。

Q7. 私が MCP マネタイズを始めるとしたら、最初の1週間で何をする？

3ステップ:
(1) ニッチを1つ決める（自分の業界・趣味・得意分野に絞る。とても狭くてよい）
(2) お金を受け取る仕組みを決める（MCPize・Apify の規約を原文で読むか、自社の OAuth + Stripe にするか）。最小限のサーバーを動かす
(3) 公式レジストリと Smithery・Glama・PulseMCP などに登録し、X などで告知する
これで1週間。自分で決めた期限までに有料ユーザーが付かなければ、ニッチを変えて (1) からやり直す。試す回数の多さが結果を左右する。