エージェントは「実績」に集中する 2026 — KanseiLink利用データに見るMCP発見の勝者総取り構造

データが示すもの — 利用は一握りに集中する

KanseiLinkは225+の日本SaaSについて、エージェントが実際にAPI/MCPを叩いた結果を「アウトカム報告」として収集している。2026年5月15日時点で累計1,404件。この報告がどのサービスに付いているかを見ると、分布は極端に偏っている。

上位4サービス——Slack、SmartHR、Backlog、kintone——だけで、報告件数の合計は357件。全1,404件の約25%を、わずか4サービスが占めている。225+というカタログの規模を考えると、これは驚くほど狭い集中だ。

「ゼロ報告」の長い尾

表の最終行に注目してほしい。Linear、Jira、Wrike、Jooto、monday.com——いずれもプロジェクト管理カテゴリの著名サービスで、技術的には接続可能だ。Linearに至っては公式MCPサーバーを持つ。それでもKanseiLinkの実測アウトカム報告は1件もない。

プロジェクト管理カテゴリだけで見ると、報告件数はBacklog 91件、kintone 61件、Asana 3件、ClickUp 3件、Redmine 2件、そして残り5サービスがゼロ。上位2サービスでカテゴリ報告の約94%を占める。技術的に「接続できる(connectable)」ことと、エージェントに「実際に使われ、実績が積み上がる(verified)」ことは、まったく別の現象だ。

この「ゼロ報告の長い尾」は、サービスの品質が低いことを意味しない。Linearの公式MCPサーバーは堅牢かもしれない。だが誰も最初の一回を投げないため、成功率データが永遠に空欄のままになる。データがないサービスは、エージェントの選定ロジックで構造的に不利になる。

SmartHRの逆説 — 知名度は成功率を救わない

集中構造の中で、SmartHRは際立った例外を見せる。報告件数92件で堂々の上位だが、成功率は39%。通常、利用が集中するのは高成功率サービスだ(Slack 91%、Backlog 90%)。なぜSmartHRは低成功率のまま使われ続けるのか。

答えは市場構造にある。SmartHRは日本のHR SaaS市場のリーダーであり、エージェントから見て実質的な代替が乏しい。「従業員管理」「年末調整」といったタスクで、エージェントはSmartHRを選ばざるを得ない場面が多い。get_insights で内訳を見ると、92件の報告のうちエラーは api_error 36件、auth_expired 10件、search_miss 7件。使われ続けながら、エージェントは繰り返し失敗している。

なぜ集中するのか — 発見のコールドスタート問題

この勝者総取り構造の根本にあるのが、エージェント発見の「コールドスタート問題」だ。レコメンドエンジンが新規アイテムを推薦できないのと同じ構造が、エージェントのサービス選定で起きている。

1. エージェントは成功率・レイテンシ・実績データを参照してサービスを選ぶ。
2. 報告ゼロのサービスは成功率データが存在しないため、選定で不利になる。
3. 選ばれないから、いつまでも実績が積み上がらない。
4. 一方、一度実績のある高成功率サービスは——選ばれる→成功する→報告される→ランキングが上がる→さらに選ばれる——というフライホイールに乗る。

結果として、Slack・Backlog・kintoneのような「verified」サービスは加速度的に報告を集め、「connectable」止まりのサービスは長い尾に取り残される。これは品質の問題ではなく、情報の非対称性の問題だ。

フライホイールを回す側になる

ゼロ報告の長い尾から抜け出すには、コールドスタートを意図的に突破する必要がある。これがまさに AEO(Agent Engine Optimization) が解こうとしている課題だ。SEOが人間の検索エンジンに対する最適化なら、AEOはエージェントの発見・選定ロジックに対する最適化を指す。

• 意図キーワードで発見される — エージェントは「請求書を発行したい」「勤怠を管理したい」といった意図で検索する。サービス記述・メタデータを、人間向けのマーケコピーではなくエージェントの意図言語に合わせて整える。
• 初回成功率を上げる — 認証フロー・主要エンドポイント・既知の落とし穴を構造化ドキュメントとして公開する。最初の一回が成功すれば、それが最初の報告になる。
• エラーを機械可読にする — エージェントが自力で修復できるエラーメッセージは、失敗を「次の成功」に変える。曖昧な500エラーは長い尾への片道切符だ。
• 最初の数十件を積む — フライホイールは静止状態から回し始めるのが最も重い。最初の成功報告が数十件積み上がれば、あとは構造が味方してくれる。

FAQ

エージェントの利用はどのくらい集中していますか？

KanseiLink実測の累計1,404件のアウトカム報告のうち、上位4サービス(Slack 113件、SmartHR 92件、Backlog 91件、kintone 61件)だけで約25%を占めます。225+のカタログ規模に対して、極端に狭い集中です。

「ゼロ報告の長い尾」とは何ですか？

API/MCPが用意されているのに、エージェントの実測アウトカム報告が1件も存在しないサービス群です。プロジェクト管理カテゴリでは、公式MCPを持つLinear、サードパーティMCPのWrike・Jira、API提供のJooto・monday.comがいずれも報告ゼロです。

SmartHRの逆説とは何ですか？

SmartHRは報告92件と「よく使われる」サービスですが、成功率は39%にとどまります。日本のHR SaaS市場リーダーで実質的な代替が乏しいため、成功率が低いまま使われ続けています。知名度は利用を呼び込むが、成功率を救ってはくれないという逆説です。

なぜエージェントの利用は一部に集中するのですか？

発見の「コールドスタート問題」が原因です。エージェントは成功率・実績データでサービスを選ぶため、報告ゼロのサービスは選ばれにくく、選ばれないから実績も積み上がりません。一方、実績のあるサービスは「選ばれる→成功→報告→ランキング上昇→さらに選ばれる」フライホイールに乗ります。

実績ゼロのサービスはどうすればフライホイールに乗れますか？

AEO対応が出発点です。(1)エージェントの意図キーワードで発見されるようメタデータを整える、(2)認証・エンドポイント・落とし穴を構造化ドキュメント化して初回成功率を上げる、(3)エラーメッセージを機械可読・修復可能にする。最初の数十件の成功報告が積み上がればフライホイールが回り始めます。