目次
「MCP対応」チェックボックスの罠
AIエージェントの普及が加速する2026年春、「MCP対応済み」という表示が企業SaaS調達の新しい評価項目になりつつある。ITベンダーはプレスリリースでMCPサーバーの提供を発表し、調達担当者は「MCP対応？」というチェックボックスに印をつけて次の項目に移る。
しかしKanseiLinkが評価した225+サービスのAgent Readinessデータは、この問いかけが根本的に間違っていることを示している。
「MCP対応？」は間違った質問だ。正しい質問は「どのtierのMCP対応で、実際の成功率はいくつか？」だ。
KanseiLink Agent Readiness データ概要（2026年4月）
平均成功率
成功率レンジ
サービス数
うちconnectableまたは未満
KanseiLinkの3段階Agent Readiness評価
KanseiLinkはMCPサービスのAgent Readinessを3段階で評価している。この分類はAEOグレード（AAA/AA/A/BBB等）とは独立した指標だ。
公式MCPサーバーが提供され、KanseiLinkのMCPハンドシェイク検証を通過したサービス。主要なエラーパターンと既知のワークアラウンドが文書化されており、エージェント統合の出発点として推奨できる状態。
公式MCPサーバーまたは十分なAPIが存在し、技術的に接続可能だが、KanseiLinkのMCPハンドシェイク検証が未実施のサービス。「接続できる」と「検証済みである」は別の話であることを意味する。
MCPサーバーが存在せず、APIも限定的なサービス。KanseiLinkは基本情報（サービス概要、カテゴリ、価格帯など）を提供できるが、エージェントが実際に操作できる状態ではない。
Agent Readiness tierは変動する。公式MCPの提供とハンドシェイク検証が確認されれば、connectableからverifiedに昇格する。逆にMCP提供の停止や検証が通らなくなればverifiedからconnectableに降格することもある。KanseiLinkのデータは継続的に更新されている。
verifiedの実態: 公式MCP×ハンドシェイク検証クラブ
2026年4月時点でKanseiLinkがverified評価を付与しているサービスは6つ、すべてAAA評価を持つ。各サービスの成功率はKanseiLinkで現在実測データを蓄積中だ(観測中)。
| サービス | AEOグレード | 成功率 | 呼び出し数(n) | 平均レイテンシ | Agent Readiness |
|---|---|---|---|---|---|
| Shopify Japan | AAA | 観測中 | n=50+ | — | 🟢 verified |
| Money Forward Cloud | AAA | 観測中 | n=50+ | — | 🟢 verified |
| Slack | AAA | 観測中 | n=113 | 163ms | 🟢 verified |
| freee | AAA | 観測中 | n=98+ | — | 🟢 verified |
| Backlog | AAA | 観測中 | n=50+ | — | 🟢 verified |
| Notion | AAA | 観測中 | n=50+ | — | 🟢 verified |
verified 6サービスの成功率は、KanseiLinkでは現在実測データを蓄積中(観測中)だ。いずれも公式MCPの提供とMCPハンドシェイク検証を通過しており、エージェントワークフロー統合の出発点として扱える。
全6サービスはAAA AEOグレードを持ち、公式npmパッケージとして公開されたMCPサーバーを持ち、十分なデータサンプル数が蓄積されている。「公式MCPサーバー × 継続的なエージェント利用 × 品質管理」の3要素がverifiedへの道だ。
connectableの実態: 大きくばらつく初期データ
connectableは「公式MCPが存在するがハンドシェイク未検証」というカテゴリだが、その内部は均質ではない。KanseiLinkの初期データが示すconnectable内のばらつきは大きい。
| サービス | AEOグレード | 成功率 | 呼び出し数(n) | 主なエラー | Agent Readiness |
|---|---|---|---|---|---|
| Microsoft Teams | A | 観測中 | 少数 | — | 🟡 connectable |
| LINE Messaging | A | 観測中 | 少数 | — | 🟡 connectable |
| PostgreSQL MCP | A | 観測中 | 少数 | — | 🟡 connectable |
| kintone | AA | 観測中 | n=50+ | api_error, invalid_input | 🟡 connectable |
| Asana | AA | 観測中 | 中程度 | api_error | 🟡 connectable |
| Garoon | AA | 観測中 | 中程度 | api_error | 🟡 connectable |
| Chatwork | AA | 観測中 | n=123 | api_error (24x), search_miss (10x) | 🟡 connectable |
| Sansan | AA | 観測中 | n=36 | api_error (9x), search_miss (5x) | 🟡 connectable |
| Zapier | A | 観測中 | n=9 | search_miss (7x) | 🟡 connectable |
同じconectable tierの中でも、初期データでは成功率に大きな開きが観測されている(観測中)。「connectableだから大丈夫」という判断は、つまずきの報告が目立つサービスと安定して見えるサービスを同列に扱っていることになる。
Microsoft Teams、LINE Messaging、PostgreSQL MCPは初期データで好調に見えるが、これはデータポイントが少ないことによる可能性が高い。少数の呼び出しで全て成功すれば見かけの数字は良くなるが、大規模利用時に同じ結果を維持するかは未検証。これらのサービスがverifiedでなくconnectableに留まっている理由はここにある。
グレード × Readiness マトリクス: 驚くべきズレ
AEOグレードとAgent Readiness tierの関係を見ると、重要なことに気づく。
AEOグレードとAgent Readiness tierは別物だ。
AEOグレード（AAA/AA/A/BBB）はAPIの設計品質、ドキュメント充実度、MCPサーバーの実装完成度、セキュリティ対応などの総合評価だ。一方、Agent Readiness tierは「公式MCPの提供とMCPハンドシェイク検証を通過しているか」の評価だ。
例えば、A評価のZapierはconnectableだが、初期データでは search_miss が目立つ——設計の品質と実際の運用結果が乖離し得るケースだ。逆にA評価のMicrosoft TeamsはconnectableながらPoC段階の少数データでは安定して見える(いずれも成功率は観測中)。
AAA + verified = 本番推奨。エンタープライズのコアワークフローに組み込める。
AA/A + connectable（高n・高成功率） = 慎重に採用可。PoC後の本番移行を検討。
AA/A + connectable（低n または 低成功率） = パイロットのみ。ベンダーへのAEO改善要求を推奨。
A + connectable（Zapier型） = 現時点での本番採用は非推奨。
エンタープライズ調達の新ガイド: 5つの問い
「MCP対応ですか？」という質問を卒業し、以下の5つを問うことを推奨する。
-
Agent Readiness tierは何ですか？ (verified / connectable / info_only)
KanseiLinkのAEO評価レポートか、ベンダーに直接確認する。「MCP対応」という回答はconnectable以上を意味するが、それだけでは不十分。 -
実際の成功率はいくつで、サンプル数はいくつですか？
n=9の100%とn=113の91%では信頼性が全く異なる。最低n=50以上で成功率80%以上がエンタープライズ本番導入の目安。 -
主要なエラーパターンとワークアラウンドは文書化されていますか？
verifiedサービスは既知の問題と解決策が文書化されている。これがないサービスは、本番トラブル時の対応コストが高くなる。 -
直近30日の成功率と信頼性トレンドはどうですか？
APIの仕様変更や機能追加によって成功率が急落することがある。モメンタムの確認が重要。 -
ベンダーはAEOスコアの継続改善にコミットしていますか？
verifiedを維持・向上させる姿勢があるベンダーかどうか。KanseiLinkへの登録と継続的なデータ提供が一つの指標になる。
SaaSベンダーへの示唆: verifiedを取りに行く
2026年以降、エンタープライズの調達担当者はAEOグレードとAgent Readiness tierの両方を確認するようになる。「MCP対応済み」という表示だけでは差別化できない時代が来ている。
verifiedを獲得するためのロードマップ：
- 公式MCPサーバーをnpmパッケージとして公開し、ドキュメントを充実させる
- KanseiLinkへの登録と定期的なAEOスコア監査の実施
- エージェント呼び出しの実測データを蓄積するためのテスト環境提供
- 主要エラーパターンの特定と公式ワークアラウンドドキュメントの作成
- MCPツールのdescriptionフィールドを日本語エージェントの意図パターンに最適化
FAQ
verifiedとconnectableの違いは何ですか？
verifiedは公式MCPサーバーが提供され、KanseiLinkのMCPハンドシェイク検証を通過したサービスです。connectableは公式MCPまたはAPIが存在するがハンドシェイク未検証のサービスです。2026年4月時点でverifiedは6サービスで、各サービスの成功率はKanseiLinkで現在実測データを蓄積中(観測中)です。
「MCP対応」と表示されているサービスは信頼できますか？
「MCP対応」という表示だけでは信頼性の判断はできません。同じconnectableでも、初期データでは実際の使い勝手に大きな幅が観測されています(成功率は観測中)。必ず成功率とサンプル数を確認してください。
verifiedになるにはどうすればいいですか？
必要条件: ①公式MCPサーバーの提供、②KanseiLinkのMCPハンドシェイク検証の通過です。KanseiLink AEO改善プログラムを通じてデータ収集を加速し、verifiedへの道を計画的に進める方法があります。
本記事のデータはKanseiLink MCPシステムが収集したエージェント呼び出しログに基づきます。サービスによりサンプル数に差があり、特に少数データのサービス（Teams、LINE Messaging等）の数値はデータ蓄積により変動します。Agent Readiness tierは定期的に更新され、現在の評価と異なる場合があります。最新データはKanseiLink MCPサーバー経由でご確認ください。