目次
7サービス成功率比較 — 一覧
KanseiLink MCPの225+サービスデータベースから、レポート数40件以上の高使用MCPサーバー7つを抽出した。全てOAuth 2.0系認証(OAuth 2.0 / OAuth 2.0+PKCE)で、エージェント市場で十分使われている『成熟MCP』に絞っている。
| サービス | 認証 | レポート数 | 成功率 | レイテンシ | AEOグレード |
|---|---|---|---|---|---|
| Shopify Japan | OAuth 2.0 | 53 | 94.3% | — | AAA |
| Money Forward Cloud | OAuth 2.0 | 42 | 92.9% | — | AAA |
| Slack | OAuth 2.0 | 113 | 91.2% | 163ms | AAA |
| Backlog | OAuth 2.0 | 91 | 90.1% | — | AAA |
| freee | OAuth 2.0+PKCE | 212 | 90.1% | 216ms | AAA |
| Notion | OAuth 2.0 | 48 | 83.3% | — | AAA |
| Chatwork | OAuth 2.0 | 123 | 65.9% | 378ms | AA |
📊 二極化の数値ハイライト
(同じOAuth 2.0なのに)
(7サービス合計)
重要な発見: 7サービス全てが 同じOAuth 2.0系認証 を採用しているにも関わらず、成功率は28.4ポイントもの幅がある。「OAuth対応していれば安心」という業界通説は明確に否定される。差を生んでいるのは認証ではなく、認証の後ろにある実装品質だ。
要因1: レート制限の厳しさ
最大の分岐点は レート制限の設計。Chatwork MCPの123件レポート中、rate_limitエラーが 8件 発生している。Slackの113件レポートでは0件。エージェントは同じユースケースで動かしているのに、片方は引っかかる。
Chatwork APIは公開仕様で 300req/5min/user と厳格なレート制限を設けている。一方Slackはmethod-tierベース(Tier 1: 1+/min、Tier 2: 20+/min、Tier 3: 50+/min、Tier 4: 100+/min)で、ユースケースに応じた緩急がある。エージェントの典型的な行動パターン(『一括メッセージ取得 → フィルタ → 投稿』)では、Slack側で詰まることはほぼない。
注目すべきは、Chatwork MCPのworkaroundデータ:
workaround: "Add 100ms delay between calls"
verification: verified
reported_count: 2
workaround: "Implemented 500ms delay between messages.
All messages delivered successfully with throttling."
verification: unverified
reported_count: 1これは エージェントが試行錯誤で学んだ知識。ベンダー公式ドキュメントに「100ms以上のディレイを推奨」と明記していれば、初回成功率が大幅に上がるはず。実際にKanseiLinkでは、このworkaroundは verified扱いで get_service_tips から取得できる。
『レート制限値は仕様書に書いてある』だけでは不十分。エージェント向けには『この値を守るための実装パターン(ジッター付き指数バックオフ、トークンバケット)』『典型ユースケース別の推奨ディレイ』までドキュメント化する必要がある。詳細はMCPサーバー レート制限・指数バックオフ実装ガイド 2026で深掘りしている。
要因2: エラーメッセージの明瞭度
第2の要因は エラー応答の情報量。Chatwork MCPは123件中 api_error が 24件(19.5%)、Notionは48件中 api_error系が複数発生。一方Slackは113件中 api_error が9件(8.0%)、freeeは212件中 api_error が15件(7.1%)。同じエラー名でも、レスポンスに含まれるヒントの量が違う。
成功率の高いサービス(Slack・freee・Money Forward)は、エラーレスポンスに以下を含む傾向がある:
- 具体的なフィールド名(『
channel_not_found: channel "C123" doesn't exist or isn't visible』) - 修正の方向性(『
missing_scope: needed=channels:read, granted=channels:write』) - リトライ可否の明示(
error.retryable: true/false)
一方、低成功率サービスは『{"error": "Bad Request"}』だけで原因が不明、エージェントは推測で再試行 → タイムアウトで諦める、という失敗パターンに陥る。
freeeで発見したauth_expiredパターン
興味深いケース: freee MCPでは auth_expired が4件発生したが、workaroundとして『OAuth tokenをリフレッシュ — token expires every 24h』が verified状態で3件報告されている。トークンの寿命がドキュメント化されていれば、エージェントは事前に refresh フローを組める。Chatworkの場合、24h以上のセッションでトークン期限切れに遭遇するパターンが報告されているが、解決workaroundが verifiedで蓄積していない。
要因3: 発見可能性 (search_miss問題)
第3の要因は そもそも見つけてもらえるか。これは認証や実装と関係なく『discoverability』の問題で、Chatworkでは search_miss が 10件 発生している(全レポートの8.1%)。
KanseiLinkの verified確認済みworkaroundデータ:
query: "business chat messaging tool"
result: did not find chatwork in top 3
verification: verified, reported_count: 2
query: "リモートワークで使えるツール"
result: did not find chatwork in top 3
verification: unverified, reported_count: 1これはMCPの実装品質とは別レイヤーの問題: メタデータ・description・タグの設計。エージェントが検索クエリから到達できなければ、どんなに認証が完璧でも使われない。Slackは「business messaging」「team communication」等の自然なユースケース語彙でほぼ確実に上位3に入る。Chatworkは「日本企業向けビジネスチャット」というポジショニングをメタデータに反映できていない可能性がある。詳細はエージェントが見つけられないMCP: search_missが示す発見可能性の危機で深掘りしている。
3要因(レート制限 × エラー設計 × 発見可能性)は 独立に成功率を押し下げる。Chatworkの66%は、各要因が 個別に 5-15ポイントずつ削った合計値と読める。逆に、これらを個別に改善するだけで段階的に85%超えは可能。OAuth実装そのものに手を入れる必要はない。
なぜShopify 94%が最高なのか
同じOAuth 2.0でShopifyだけが94.3%という頭一つ抜けた成功率を出している理由は構造的だ。Shopifyは 4つの専用MCPサーバー(Dev、Storefront、Customer Account、Checkout)を用途別に分離して提供している。
- Dev MCP: 開発者向けAPI・GraphQL Storefront等のドキュメント参照
- Storefront MCP: 商品検索・カート操作
- Customer Account MCP: 顧客情報・注文履歴
- Checkout MCP: 決済フロー
これにより、エージェントが『どのMCPで何ができるか』を 明確に判断できる。汎用1サーバー型(freeeの5ドメイン統合、Slackの全機能統合APIなど)よりも、サービス境界が明示的でツール選択ミスが起きにくい。加えて『Every store exposes /api/mcp endpoint』という標準パターンも、エージェントが新しい店舗に対しても予測通り動作できる安心感を生む。
これは大規模MCP実装の 『専用化 vs 汎用化』のトレードオフ を示す重要な実例で、KanseiLink分析でもツール選択精度がfree-form 1サーバー型より15-20%高い傾向がある。
SaaSベンダーが取るべき優先アクション
P0 (即時, 1ヶ月以内): エラーレスポンスにworkaround_hintを含める
最も投資対効果が高い改善。429エラーなら『Retry-Afterヘッダー値 + ジッター推奨秒数』を明示する。404なら『候補となる近いリソースID』をsuggestionsとして返す。実装コストは小さく、成功率への影響は大きい。Chatworkの場合、verifiedで蓄積されている『100ms delay』workaroundをドキュメント化するだけで、初回成功率の数ポイント改善が見込める。
P1 (短期, 3ヶ月以内): search_missを減らすメタデータ設計
サービス名だけでなくユースケース語彙(『リモートワーク』『社内チャット』『ビジネスメッセージング』等)で見つかるよう、メタデータ・description・タグを充実させる。日本SaaSは特に英語キーワードでの発見性が低い傾向があるため、ja/en両言語のメタデータを揃える。
P2 (中期, 6ヶ月以内): SDKレベルでバックオフを組み込む
レート制限を緩和できないなら、公式SDK/MCP serverレベルで自動的に指数バックオフ + ジッターを組み込む。エージェント側に対策を求めるのではなく、ベンダー側で『成功するまで自動で待つ』振る舞いをデフォルトにする。詳細実装はレート制限実装ガイドを参照。
AEO Aグレード(成功率85%+)が2026年Q3-Q4の事実上の業界スタンダードになる見通し。現在80%帯のサービスは、上記P0-P2の改善で90%超は実現可能。OAuth 2.0実装そのものを書き直す必要はない。
FAQ
Q1. 同じOAuth 2.0なのにSlackとChatworkで25ポイント以上差が出る理由は?
認証方式は同じでも、(1) レート制限の厳しさ、(2) エラーメッセージの明瞭度、(3) 発見可能性、の3要因が成功率を分けている。OAuthそのものは『認証パス』が確立しているだけで、その後のエージェント体験は実装ごとに大きく異なる。
Q2. ShopifyとMoney Forwardが90%超なのは構造的に何が違うのですか?
Shopifyは4MCPサーバー分離型でツール選択精度が高い。Money Forwardは2026年3月から全プランでRemote MCPを提供し、API成熟度が高くエラーパターンが少ない。両者とも『エージェント側で迷う場面が少ない』ことが90%超を支えている。
Q3. Chatworkの66%は救済可能ですか?
はい、構造的に可能。3要因(レート制限・エラー設計・発見可能性)はそれぞれ独立に改善できる。例えば、verifiedで蓄積されている100ms delay workaroundをドキュメントに明記するだけでも初回成功率が改善する見込み。OAuth実装の書き直しは不要。
Q4. Notion 83%とChatwork 66%の差はどこから来ますか?
Notionはエラーレスポンスが比較的詳細(API errorに具体的なblock_id/property名を含む)。一方rate_limitエラーは少なく、search_missもChatworkほど多くない。3要因のうち1つだけ弱いNotion vs 3要因全て弱いChatwork、という違いが17ポイント差を生む。
Q5. 認証方式以外で成功率を予測する指標はありますか?
KanseiLinkデータでは『エラーレスポンスにworkaround_hintを含むか』『公式ドキュメントにレート制限実装パターンが書かれているか』『英語+日本語両方のメタデータを揃えているか』の3つが、認証方式よりも強い予測変数。詳細はAEO格付け方法論を参照。
Q6. KanseiLinkのデータはどう取得しますか?
MCP経由で npx -y @kansei-link/mcp-server で接続し、get_insights(service_id)で各サービスの実測データを取得できる。225+サービスのAEOグレード一覧はAEO Readiness Ranking Q2 2026で公開。
本記事の成功率データは2026年5月11日時点のKanseiLink MCPデータベース実測値(get_insights取得値)で、各サービスとも累積レポート数40件以上の高使用MCPサーバーのみ抽出しています。サンプル数の偏り(Chatwork 123件 vs Money Forward 42件)による統計的不確実性は残ります。レート制限値(Chatwork 300req/5min/user、Slackのmethod-tier等)は2026年5月時点の各社公開ドキュメント値で、変更される可能性があります。エラーパターン頻度はKanseiLinkユーザー由来のレポート集計値であり、各サービスの全エージェントを代表するものではありません。本記事の改善提言はKanseiLinkリサーチチームの分析であり、各社の実装事情に応じた調整が必要です。