同じOAuth 2.0でも成功率は二極化する — MCP成功率を分けた3つの構造要因 (KanseiLink 7サービス比較 2026)

7サービス比較 — 一覧

KanseiLink MCPの225+サービスデータベースから、レポート数40件以上の高使用MCPサーバー7つを抽出した。全てOAuth 2.0系認証(OAuth 2.0 / OAuth 2.0+PKCE)で、エージェント市場で十分使われている『成熟MCP』に絞っている。なお成功率の実測データはKanseiLinkで現在蓄積中のため、本表では「観測中」と表記する。

重要な視点: 7サービス全てが 同じOAuth 2.0系認証 を採用しているにも関わらず、エラー・つまずきの報告パターンには大きな幅がある。「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 から取得できる。

要因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が示す発見可能性の危機で深掘りしている。

なぜShopifyの評価が高いのか

同じOAuth 2.0でShopifyの評価が頭一つ抜けている理由は構造的だ。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サーバー型よりツール選択の迷いが起きにくい傾向がある。

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レベルで自動的に指数バックオフ + ジッターを組み込む。エージェント側に対策を求めるのではなく、ベンダー側で『成功するまで自動で待つ』振る舞いをデフォルトにする。詳細実装はレート制限実装ガイドを参照。

FAQ

Q1. 同じOAuth 2.0なのにサービス間でエージェント体験に差が出る理由は?

認証方式は同じでも、(1) レート制限の厳しさ、(2) エラーメッセージの明瞭度、(3) 発見可能性、の3要因がエージェント体験を分けている。OAuthそのものは『認証パス』が確立しているだけで、その後のエージェント体験は実装ごとに大きく異なる。

Q2. ShopifyとMoney Forwardの評価が高いのは構造的に何が違うのですか?

Shopifyは4MCPサーバー分離型でツール選択精度が高い。Money Forwardは2026年3月から全プランでRemote MCPを提供し、API成熟度が高くエラーパターンが少ない。両者とも『エージェント側で迷う場面が少ない』ことが高評価を支えている。

Q3. Chatworkの伸び悩みは救済可能ですか?

はい、構造的に可能。3要因(レート制限・エラー設計・発見可能性)はそれぞれ独立に改善できる。例えば、蓄積されている100ms delay workaroundをドキュメントに明記するだけでも初回成功率が改善する見込み。OAuth実装の書き直しは不要。

Q4. NotionとChatworkの差はどこから来ますか?

Notionはエラーレスポンスが比較的詳細(API errorに具体的なblock_id/property名を含む)。一方rate_limitエラーは少なく、search_missもChatworkほど多くない。3要因のうち1つだけ弱いNotion vs 3要因全て弱いChatwork、という違いがエージェント体験の差を生む。

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で公開。