目次
話題のクレーム: 「2,181エンドポイント中52%死亡」
2026年4月後半、AIエージェント開発者コミュニティで一つの数字が拡散している。
「リモートMCPサーバー2,181エンドポイントを調査したところ、52%が完全に死亡し、健康なものはわずか9%だった」
この数字は、2026年4月公開のApigene社「Host MCP Server: The 2026 Deployment Guide」が初出として広く引用されている。Cloudflareのエンタープライズ向けMCPアーキテクチャ発表（2026年4月22日、InfoQ報道）と時期を同じくしており、「MCPブームの裏側でゴーストサーバーが激増している」というナラティブを補強する形で拡散している。
同じ4月にはRapid Claw社も別の調査結果を公表しており、「監査した1,847サーバーのうち52%が放棄状態（abandoned）、31%が軽微なメンテナンスのみ、本番品質基準を満たすのは17%」と報告している。両調査とも「52%死亡・放棄」という数字で奇妙に一致している。
2026年4月の2大調査（数字の比較）
完全死亡（n=2,181）
劣化状態
完全に健康
本番品質（n=1,847）
出典の検証: ApigeneとRapid Clawの2調査
クレームの妥当性を判断するため、両調査の以下の点を確認した。
① 出典の独立性
ApigeneとRapid Clawは独立したベンダー・出版主体であり、両者が同月に「52%死亡・放棄」という数字を出していることは偶然の一致か、あるいは類似の母集団（パブリックなMCPレジストリ）からのスクレイピング結果が収束した可能性がある。少なくとも一方が他方を引用した形跡は確認できなかった。
② サンプリング方法
両調査ともサンプリング方法の詳細は公開されていない。一般的にこの種のスクレイピングは、modelcontextprotocol.io/serversや各種MCPレジストリ、GitHubで公開されているリモートMCPエンドポイントを巡回する形で実施される。これは「すべてのMCPサーバー」ではなく、「公開レジストリに掲載されたMCPサーバー」という偏ったサンプルである点に留意が必要だ。
③ 健康判定基準
Apigeneは「ヘルスチェック実行で200 OKかつ有効なJSONレスポンスを返す」を健康の定義としているとされる。「死亡」はタイムアウト、5xxエラー、接続不能を含む。Rapid Clawの「本番品質」基準はより厳しく、ヘルスチェックに加えて「直近30日のコミット」「ドキュメント完備」「セマンティックバージョニング」などを求めている。
検証結果: 「公開MCPサーバーの過半数が死んでいる」は概ね正しいが、母集団に注意が必要
Apigene・Rapid Claw双方の独立調査が「52%死亡・放棄」で一致している点から、公開レジストリ上のMCPサーバーの過半数がメンテナンスされていない実態は信頼に足る。ただしこれは「すべてのMCPサーバー」ではなく「公開レジストリ掲載のサーバー」の話であり、エンタープライズの自社運用やクローズドなサーバーには適用できない。また「健康9%」と「本番品質17%」の差は判定基準の厳格さの違いを反映しており、両者は矛盾していない。
KanseiLink 225+サービスデータとの照合
KanseiLinkは225+サービス（日本SaaS中心）を対象にAgent Readiness評価を実施している。外部調査の数字と直接比較はできないが、構造的に近い指標を並べると以下のようになる。
| 指標 | Apigene (n=2,181) | Rapid Claw (n=1,847) | KanseiLink (n=225+) |
|---|---|---|---|
| 「健康」または最高品質 | 9% | 17% | 約3% (verified 6社) |
| 接続可能だが品質未確定 | 39% | 31% | 大多数 (connectable) |
| 事実上利用不可 | 52% | 52% | 約30% (info_only) |
KanseiLinkは「ベンダー公式に存在を確認できたサービス」を対象としているため、「完全に死亡」の比率は外部調査より低い。一方、verified比率（約3%）は「実際にエージェントが使って成功する」という厳しい基準のため、Apigeneの「健康9%」より低い。母集団と判定基準を揃えれば、3つの調査は同じ結論を指している: MCPサーバーの大多数は『接続できるが信頼できない』状態にある。
KanseiLinkデータでは、AAA評価のサービスはほぼすべてverified（成功率80%以上）に到達している一方、AA以下のサービスでは成功率が大きくばらつく。これは「公式MCPサーバーをリリースした」と「エージェントが本番で使える」の間に大きなギャップがあることを示しており、外部調査の数字とも整合する。
なぜMCPサーバーは死ぬのか — 3大原因
Apigeneと業界の指摘、KanseiLinkのエラーログを総合すると、MCPサーバーが「死ぬ」主な原因は3つに集約される。
原因①: 認証情報の期限切れによる放棄サーバー
個人開発者がデモ用に立てたMCPサーバーが、APIキーやOAuthトークンの期限切れ後にメンテナンスされず放置されるパターン。レジストリには登録されたままで、健康調査では「死亡」とカウントされる。
原因②: アップストリームAPIのサイレント破損
SaaSベンダーがAPIの仕様を変更した際、MCPサーバーが追従せず、レスポンスのスキーマが壊れる。HTTP 200を返すため死亡判定はされないが、エージェントから見ると「呼べるけど結果が解釈できない」状態になる。KanseiLinkではapi_errorとして記録されるエラー類型の多くがこれに該当する。
原因③: サーバーレスのコールドスタートタイムアウト
Cloudflare Workers以外のサーバーレス（Lambda、Vercel Functions等）でMCPサーバーをデプロイすると、低頻度アクセス時にコールドスタートで初回リクエストが10秒以上かかり、エージェントがタイムアウトで諦める。健康調査では時刻によって結果が変動する不安定なサーバーとなる。
日本SaaSが今すぐすべき7つの予防策
「公開レジストリ上の死亡率52%」というデータは、日本SaaSベンダーへの警鐘でもある。MCPサーバーをリリースしたあとに「死なせない」ための7つの予防策を提示する。
- ヘルスチェックエンドポイントの実装と外形監視 — 5分間隔のpingでアップストリームAPIまで疎通確認し、ダウンタイムを即検知する
- アップストリームAPIバージョンのピン留め — `v1` 等のメジャーバージョンに固定し、スキーマドリフトを検知する単体テストをCIに組み込む
- セマンティックバージョニングの徹底 — MCPサーバー自身もv0.x系から早期にv1に移行し、互換性のシグナルを明確化する
- Cloudflare Workers等のエッジ採用 — V8 isolateベースでコールドスタート問題を回避し、グローバルにレイテンシを安定させる
- レジストリ情報の四半期更新 — modelcontextprotocol.ioや各種レジストリへの掲載情報を四半期ごとに再確認し、廃止サーバーは明示的に削除する
- KanseiLink等のAEO評価への登録 — 第三者によるAgent Readiness評価を受け、verified tierを目指す。エージェントの実利用データが品質シグナルになる
- エラーパターンの公式ワークアラウンド文書化 — `search_miss`や`api_error`を起こすエッジケースを公式ドキュメントに記載し、エージェント開発者の手戻りを減らす
「MCPサーバーを公開しました」というプレスリリースを出した後、半年間更新がないサーバーは、外部調査で「死亡」とカウントされ、ベンダーの信頼性スコアを毀損する。MCPサーバーは継続的に運用するソフトウェア資産であり、APIと同じ品質管理ライフサイクルが必要だ。
FAQ
「2,181エンドポイント中52%死亡」の出典はどこですか？
2026年4月公開のApigene社「Host MCP Server: 2026 Deployment Guide」が広く引用されています。同月にRapid Claw社も「1,847サーバー中52%放棄」を公表しており、独立した2調査が同じ結論に到達しています。ただし両調査ともサンプリング方法と判定基準の詳細は完全には公開されていません。
KanseiLinkデータでも同じ傾向ですか？
KanseiLinkは225+サービス（日本SaaS中心）が対象で、外部調査と母集団が異なります。verified（成功率80%以上）はわずか3%（6サービス）で、外部調査の「健康9%」「本番品質17%」と同様に「実際に信頼して使えるサーバーは少数」という結論が一致しています。
MCPサーバーが死ぬ主な原因は何ですか？
(1) 認証情報の期限切れによる放棄、(2) アップストリームAPIのサイレント破損（200 OKを返しながら壊れたレスポンス）、(3) サーバーレスのコールドスタートタイムアウト、の3つが主因です。日本SaaSベンダーは継続的なヘルス監視とAPIバージョンピン留めで対策できます。
本記事はApigene社およびRapid Claw社が2026年4月に公表した第三者調査データを引用しています。両調査のサンプリング方法と判定基準の詳細は完全には公開されておらず、母集団（公開MCPレジストリ掲載サーバー）に偏りがある可能性があります。KanseiLinkデータは225+サービスのエージェント呼び出しログに基づき、外部調査と直接比較はできない点にご留意ください。