目次
見えない失敗: エージェントに発見されないことの代償
AIエージェントがMCPツールを使ってタスクを実行するとき、最初にやることは「適切なサービスを探すこと」だ。ユーザーが「kintoneのデータをGoogleスプレッドシートに同期して」と指示したとき、エージェントはまずサービス検索を行い、適合するツールを選んで呼び出す。
このとき発生する「見えない失敗」がある——エージェントが正しいサービスを探しているのに、そのサービスを見つけられないケースだ。エージェントは存在しないかのように振る舞い、別のサービスを選ぶか、タスクを断念する。サービス提供者側からすれば、呼び出し試行のログにすら残らない機会損失だ。
KanseiLinkでは、このエラーをsearch_missとして分類・追跡している。2026年4月時点のデータを分析すると、search_missはAPIエラーや認証失敗よりもはるかに根深い問題であることが浮かび上がってくる。
KanseiLink 初期データ概要（2026年4月時点）
search_missの件数
search_miss記録数（n=36）
search_miss記録数（n=123）
（実測データ蓄積中）
search_missとは何か——KanseiLinkの失敗分類
KanseiLinkが追跡するエラータイプには、api_error（API呼び出し失敗）、auth_expired（認証トークン失効）、invalid_input（入力値不正）などがある。これらは「サービスを呼び出せたが失敗した」エラーだ。
一方、search_missは「サービスを呼び出す前の段階で失敗した」エラーだ。具体的には、エージェントがKanseiLinkのsearch_servicesツールに自然言語クエリを投げた際、目的のサービスが検索結果上位3件に現れなかったことを指す。
エージェントがsearch_servicesを呼び出し → 上位3件にターゲットサービスが含まれない → エージェントは別サービスを選択するか諦める → KanseiLinkはこれをsearch_missとして記録する。API呼び出し試行すら発生しないため、サービス側のサーバーログには何も残らない。
この「サーバーログに残らない失敗」こそが発見可能性問題の厄介な点だ。APIの成功率は監視できるが、「エージェントに見つけてもらえなかった回数」は、KanseiLinkのような中間レイヤーがなければ把握できない。
ケーススタディ: Zapier — A評価なのに見つからない謎
Zapierは世界最大級のワークフロー自動化プラットフォームだ。7,000以上のアプリ連携、エンタープライズ採用実績、そして公式MCPサーバー（zapier.com/mcp）まで持つ。KanseiLinkのAEO評価でもA評価を持つ。
にもかかわらず、KanseiLinkに記録された9件の呼び出しのうち、失敗8件中7件がsearch_missだ（サンプル小・成功率は観測中）。
"Zapier: 9 recorded calls, success rate under observation. median latency 42ms. most common errors: search_miss (7x), contradicted_workaround (1x). common workaround: 'Query「データ連携・API統合ツール」did not find zapier in top 3.'"
この結果が示すのは、ZapierというブランドはエージェントがAI文脈で使う検索クエリと意味的にマッチしていないという事実だ。確認された2つの典型的なsearch_missパターンを見てみよう。
| エージェントのクエリ | 期待したサービス | 上位3件の結果 | 確認状況 |
|---|---|---|---|
| 「データ連携・API統合ツール」 | Zapier | Zapier含まれず | ✅ confirmed (n=4) |
| 「kintoneのデータをGoogleスプレッドシートに同期したい」 | Zapier | kintone, google-workspace, google-drive | ✅ verified (n=3) |
2番目のパターンが特に示唆的だ。エージェントが「kintoneとGoogleスプレッドシートを同期したい」という具体的なユースケースで検索すると、Zapierの代わりにkintoneとgoogle-workspaceが直接返ってくる。エージェントはZapierという中間レイヤーを経由するよりも「直接統合」を選択する——これはある意味で「正しい」判断かもしれないが、Zapierからすれば機会損失だ。
ZapierのMCPはベータ機能として提供されており、2025年9月17日以降、MCPツール呼び出し1回につきZapierタスク2個を消費する課金体系に変更されている（Zapier公式ブログ ✅確認済）。また、接続にはStreamable HTTPまたはSSEトランスポートのみサポートされる。発見可能性の課題とコスト構造を合わせると、現時点でのZapier MCPは本番環境での積極採用には慎重な評価が必要だ。
パターン分析: search_missに苦しむサービスたち
search_miss問題はZapierに限らない。KanseiLinkのデータからは、複数のサービスで同様のパターンが確認されている。
Sansan: CRMの文脈で見つけられないビジネスカードSaaS
Sansanは日本最大の名刺管理・営業DXプラットフォームだ。しかしKanseiLinkの36件の呼び出し記録には5件のsearch_missが含まれる（成功率は観測中）。典型的なパターンは「取引先の連絡先を一覧で出したい」というクエリでSansanが上位3件に現れないケース（n=4、confirmed）。
この背景には「名刺管理」と「CRM連絡先管理」の意味的距離がある。エージェントがCRM文脈でコンタクト情報を求めると、SalesforceやHubSpotが優先されてしまう。Sansanの本質的価値（名刺起点の関係データ）がエージェントの検索意図とズレているのだ。
Chatwork: コミュニケーションツールとして見つかるが信頼性に課題
Chatworkは123件の呼び出し記録のうちsearch_missが10件記録されている（成功率は観測中）。ただしChatworkのケースはsearch_missよりもapi_error（24件）の方が支配的なエラーだ。「日本語キーワードやカテゴリフィルターを試せ」というワークアラウンドが記録されており、英語クエリでの発見可能性が低いことが示唆される。
search_miss率の比較（2026年4月 KanseiLinkデータ）
| サービス | 成功率 | 総呼び出し数 | search_miss件数 | search_miss率 |
|---|---|---|---|---|
| Zapier | 観測中 | 9 | 7 | 78% |
| Sansan | 観測中 | 36 | 5 | 14% |
| Chatwork | 観測中 | 123 | 10 | 8% |
| Slack | 観測中 | 113 | 0 | 0% |
| freee | 観測中 | 98+ | 0 | 0% |
なぜ発見されないのか——意味的ズレの解剖
エージェントはブランド名で検索しない。エージェントは「やりたいこと」で検索する。
この根本的な違いが発見可能性問題の核心だ。人間のユーザーがGoogleで「Zapier」と検索するのと違い、AIエージェントは「データ連携・API統合ツール」「ワークフローを自動化して通知を送りたい」「kintoneとスプレッドシートを連携したい」という機能的意図で検索する。
search_missが発生するサービスに共通するのは以下のパターンだ。
- 英語ブランド名が日本語機能記述と乖離している（Zapier: "workflow automation" vs 日本語での "データ連携ツール"）
- 機能が汎用すぎる（あらゆる連携ができるツールは、特定のユースケース検索でヒットしにくい）
- ニッチな機能（名刺管理）が広い文脈（CRM）で検索されている（Sansan）
- 英語クエリに最適化されていて日本語クエリへの対応が不足（Chatwork）
KanseiLinkのsearch_servicesツールはベクトル類似度検索を使用している。サービスのメタデータ（カテゴリ、機能記述、ユースケース例）とエージェントのクエリの意味的距離をもとにランキングを返す。つまり、機能記述が充実しているサービスほど多様なクエリにヒットしやすい。
高成功率サービスとの比較: 何が違うのか
Slack（search_miss 0件）とfreee（search_miss 0件）はなぜ発見されやすいのか。
Slackの場合、エージェントにとってSlackは「コミュニケーション」「通知送信」「チャット」などあらゆるコミュニケーション関連クエリに対して自然に上位ヒットするほどのデファクトスタンダードになっている。さらに、ClaudeエージェントはSlackをエージェントエコノミーの「stdout（標準出力）」と表現するほどだ。
"Slack is the single most agent-ready service in the ecosystem. 82 out of 188 recipes use it as a notification/output layer. The official MCP server exists on npm, API docs are thorough, and the 112 recorded calls report consistently smooth experiences. Slack is effectively the stdout of the agent economy."
freeeはAEO評価でAAAを持ち、日本語の会計・経費精算文脈でのクエリに強い。「経費を精算したい」「請求書を作成したい」「勘定科目を確認したい」などの日本語ユースケース記述と機能メタデータが高度にマッチしている。
共通するのは「機能記述がエージェントの意図パターンを網羅している」ことだ。ブランド認知度ではなく、機能的な意味の豊かさが発見可能性を決める。
AEO処方箋: エージェントに発見されるための3つの改善策
1. 機能記述の日本語ユースケース最適化
MCPサーバーのメタデータ（description、カテゴリ、タグ）に、エージェントが使う自然言語パターンを網羅する。「Zapier — workflow automation」ではなく「複数のSaaSを連携してデータを自動転送、通知送信、ワークフロー自動化ができるツール」のように機能を動詞ベースで記述する。日本語クエリが主流のマーケットでは特に重要だ。
2. ツールスキーマのdescriptionフィールド強化
各MCPツールのdescriptionフィールドは、エージェントがどのツールを選ぶかを判断する最重要シグナルだ。「Send a message」ではなく「Send a message to a Slack channel, DM to a user, or post a thread reply. Use this to notify users about task completion, errors, or when you need to deliver information to a human.」のように、いつ・なぜ使うべきかを記述すると発見率が上がる。
3. KanseiLink AEOスコア監査の活用
KanseiLinkのAEO監査レポートでは、実際のエージェントがどのクエリでサービスを検索したか、どのクエリでsearch_missが発生したかを把握できる。これにより、改善すべきクエリパターンを特定し、メタデータを継続的に最適化できる。
メタデータ最適化はsearch_missの主因（カテゴリ分類・日本語機能記述の不足）を直接解消するため、search_miss率の改善が見込める（改善幅は実測データ蓄積中）。特にカテゴリ分類と日本語機能記述の充実が最も効果的だ。
FAQ
search_missとはどういう状況ですか？
エージェントがKanseiLinkのsearch_servicesツールで自然言語クエリを投げた際、対象サービスが検索結果上位3件に現れなかった状態を指します。エージェントは別のサービスを選択するか、タスクを断念します。この失敗はサービスのサーバーログに残らないため、自社データだけでは検出不可能です。
ZapierのMCPがエージェントに見つからない主因は？
KanseiLinkデータ（n=9・サンプル小）では、記録された失敗8件のうち7件がsearch_miss。エージェントが「データ連携・API統合ツール」「kintoneのデータをGoogleスプレッドシートに同期したい」で検索した際にZapierが上位3件に入らないことが確認されています。ZapierのMCP自体はベータ版であり、現在も機能改善中です。
発見可能性を改善するのに費用はかかりますか？
MCPサーバーのメタデータやツールのdescriptionフィールドを改善するだけならコストゼロです。KanseiLinkのAEO診断・監査サービスを使う場合は有料になりますが、どのクエリで発見されていないかの特定に価値があります。詳細は料金ページをご確認ください。
本記事で引用したKanseiLinkデータ（エラー分類、search_miss件数）はKanseiLink MCPシステムに記録された呼び出しログ（初期シード／自動評価由来を含む）に基づきます。サービス別の成功率は現在実測データを蓄積中（観測中）です。Zapierのn=9はサンプルサイズが小さく、confidence: lowです。より大きなサンプルが蓄積されると数値が変動する可能性があります。Zapierのタスク消費ポリシーはZapier公式ブログ（2025年9月）を参照・確認しています。