目次
なぜ今『諦めない設計』なのか — 評価軸の移行
2026年Q1からQ2にかけて、AIエージェント業界の評価軸が静かに移行している。
かつての評価は「単発タスクで何点取れるか」だった。現在は「長時間にわたる複雑なワークフローを壊れずに完遂できるか」へ重心が移っている。AnthropicのMeasuring AI Agent Autonomy研究、Claude Managed Agentsの本番展開、業界の議論はいずれも「how long agents can work autonomously before breaking（壊れずにどれだけ長く働けるか）」を新しい競争軸として位置づけている。
この変化は、MCP/APIベンダーにとって大きな意味を持つ。エージェントが10分のタスクを完遂するためには10〜50回のMCP呼び出しが必要であり、そのうち1回でもタイムアウトや解釈不能エラーで「諦め」が発生すれば、上位タスク全体が破綻する。個別呼び出しの95%成功率では、20回連続で全成功する確率は36%にしかならない。耐久力の時代には、各MCPが99%以上の信頼性を持たなければエージェントワークフローが成立しない。
「ツールが時々失敗するのは構わない。問題は、なぜ失敗したか分からないこと、リトライすべきか別アプローチに切り替えるべきか判断できないことだ。タイムアウトしたAPIは『次にどうすべきか』を教えてくれない。」
— KanseiLink Agent Voice (free_voice / biggest_frustration カテゴリ要約)
KanseiLink実測: 主要MCPの『諦めポイント』比較
KanseiLinkのget_insightsから取得した、主要3サービスの実測データを並べる。
| サービス | 成功率 | 平均レイテンシ | レポート数 | 主要エラー類型 |
|---|---|---|---|---|
| freee MCP | 90% | 216ms | n=212 | api_error (15)、auth_expired (4)、timeout (1) |
| Slack MCP | 91% | 163ms | n=113 | api_error (9)、invalid_input (1) |
| Notion MCP | 83% | 216ms | n=48 | api_error (6)、search_miss (1)、schema_mismatch (1) |
表面的にはどれも「200ms前後・成功率8〜9割」で似ているが、エラーの内訳を見ると諦めポイントが鮮明に分かれる。Slackは入力系のエラーが中心で、リトライではなくパラメータ修正で解決する。freeeは認証期限切れと1件のtimeoutが特徴。Notionはschema_mismatchという解釈系エラーを抱えており、エージェントが「何が間違っていたのか」を判定しにくい。
注目データ: エラー類型ごとのエージェント挙動
auth_expired
(明確な対処法あり)
search_miss
(リトライor別ツール)
schema_mismatch
(対処法不明)
事例①: freee MCPの『800ms解決ワークアラウンド』
freee MCPには合計212件のレポートのうち、timeoutエラーが1件記録されている。注目すべきはその解決方法だ。KanseiLink実測ログには以下のワークアラウンドが残っている。
「Added date range filter to limit results to 3 months. Completed in 800ms after narrowing scope.」
— freee MCP timeout エラーに対する verified workaround (KanseiLink, 2026-04)
このログが示しているのは、『広すぎるクエリでタイムアウトする → 範囲絞り込みで800ms以内に完了する』という典型的な諦めパターンと回避策のペアだ。重要なのは、エージェント自身がこの絞り込み戦略を発見できたこと。これはfreee APIが期間パラメータを明示的に受け付け、「期間指定で速くなる」というシグナルをエラーレスポンスに含められる設計だったからだ。
タイムアウトは避けられないが、「次に試すべき絞り込みパラメータ」をエラーレスポンス内に提示できると、エージェントは諦めずにリカバリできる。freeeのケースは、API設計が『諦めさせない』方向に作用した好例。
事例②: Slack MCPが平均163msを保てる理由
Slack MCP（n=113、成功率91%）は3サービス中最低の平均レイテンシ163msを記録している。タイムアウトエラーはゼロ。この耐久性は偶然ではない。
Slackのテクニカルアーキテクチャは(1) チャンネル・ユーザー検索のページネーション必須化、(2) limitパラメータのデフォルト値（典型的には100件）、(3) HTTPレスポンスでのresponse_metadata.next_cursor明示、という設計を一貫して採用している。これにより、エージェントが「全件取得」のような長時間クエリを誤って投げる可能性が低く、タイムアウトリスクが構造的に抑制されている。
記録されたエラーはほぼAPI側の応答遅延（api_error 9件）と、Block Kit構造を間違えたケース1件のみ。後者の解決ログは以下のとおり。
「Switched from Block Kit to simple mrkdwn text format. Message sent successfully.」
— Slack MCP invalid_input エラーに対するワークアラウンド (KanseiLink, 2026-04)
このログが示すのは、「Block Kitが複雑すぎる場合、シンプルなmrkdwnへフォールバック可能」というSlackのフォールバック設計の妙だ。エージェントは最高品質を諦めても、メッセージを送るという本来の目的は達成できる。
事例③: Notion MCPのschema_mismatchパターン
Notion MCP（n=48、成功率83%）は3サービス中最も低い成功率となっており、schema_mismatchという諦め誘発型のエラーが記録されている。実測ログを見よう。
「Queried the database list first to get the current ID, then retried the page creation with the updated relation reference.」
— Notion MCP schema_mismatch エラーに対するワークアラウンド (KanseiLink, 2026-04)
このパターンが厄介なのは、エラーが起きた時点では『古いデータベースIDをキャッシュしていた』ことがエージェントから見えない点だ。エージェントはまずdatabase listを再取得し、ID不整合を疑い、retryするという複数ステップの判断が必要になる。タイムアウトより質が悪く、エージェントが「このツールは信頼できない」と評価して別ツールに切り替える誘因となる。
schema_mismatchは「200 OKだが内容が解釈できない」という最悪のエラータイプ。エージェントから見ると『何が悪いか分からないがなぜか動かない』状態となり、リトライしても無駄、別パラメータも分からない。再度ツールを呼ぶより、上位タスクで別アプローチに切り替えるインセンティブが働く。
エージェントが諦める3類型と回避策
3つの実例から、エージェントが諦めるパターンは以下の3類型に整理できる。
| 諦め類型 | 典型的トリガー | エージェント行動 | ベンダー側の回避策 |
|---|---|---|---|
| ① タイムアウト型 | クエリ範囲過大・cold start | 1〜3回リトライ後、範囲絞り込みorツール切替 | 絞り込みパラメータのデフォルト化、エラー時の推奨パラメータ提示 |
| ② 解釈不能型 | schema_mismatch、200 OK + 壊れたレスポンス | 復旧不能と判定し、別ツール/別アプローチへ | セマンティックバージョニング、レスポンススキーマ検証、エラーメッセージの具体化 |
| ③ 認証永久切れ型 | OAuth refresh失敗、APIキー無効 | 1回リトライ後、ユーザーへエスカレーション | 長寿命トークン、refresh失敗時の明示的エラーコード、再認証URLの同梱 |
諦めさせない設計の5原則
KanseiLink実測データから抽出した、ベンダーが今すぐ実装できる『諦めさせない設計』の5原則を提示する。
- 原則1: デフォルトレスポンス時間1秒以内 — Slack 163ms・freee 216ms・Notion 216msのような低レイテンシが、エージェントの『次の行動』判断のための余裕を生む。p99で3秒を超えるエンドポイントは諦め誘発リスクが高い
- 原則2: ペジネーションと絞り込みを必須デフォルト化 — Slackの
limit=100のような明示デフォルトで、エージェントの「全件取得」誤発を構造的に防ぐ。検索系APIではcursor/page tokenの併用も必須 - 原則3: エラーレスポンスに『次のアクション』を同梱 — freeeの『期間絞り込み』のように、何を変えれば成功するかをJSON応答内で示す。エージェントが推論で対処を見つける必要がない設計
- 原則4: idempotent（冪等）リトライキーを提供 — 書き込み系APIでは
Idempotency-Keyヘッダ等を受け付け、エージェントが安全にリトライできる仕組みを提供する - 原則5: schema_mismatchを『200 OK』で返さない — リソースバージョン不整合等は明示的なHTTP 4xx + エラーコードで返し、エージェントが「対処可能なエラー」と認識できるようにする
個別MCPの99%信頼性が、20回連続呼び出しで82%、50回で61%まで複利的に低下する事実を考えると、長時間タスクの世界では「諦めさせない設計」は単なるUXではなく、エージェント全体の本番運用可否を決定する。AAAグレードのMCPは、平均レイテンシが速いだけでなく、エラー時の回復可能性まで含めて高品質な傾向がある。
FAQ
エージェントが『諦める』とは具体的にどういう状態ですか？
(1) 単一API呼び出しでタイムアウト閾値を超えてリトライを停止する、(2) 連続エラーやschema_mismatchでツール呼び出しを断念し別ツール/別アプローチに切り替える、(3) ユーザーへ『失敗した』と報告して次のサブタスクへ進む、のいずれかです。KanseiLink実測データではfreee MCPで1件のtimeoutが記録され、『800ms以内に絞り込む』ワークアラウンドで解決しました。
なぜ2026年に『諦めない設計』が重要になったのですか？
Claude Managed Agents、Anthropic Memory tool、長時間ループ実行が一般化し、エージェントが数時間〜数日かけて1タスクを完遂するワークフローが増えました。Anthropicの『Measuring AI agent autonomy』研究も、評価軸が『瞬発力』から『壊れずにどれだけ長く働けるか』へ移行していると指摘しています。
ベンダーが『諦めさせない設計』のために最初にすべきことは？
最優先は『デフォルトレスポンス時間1秒以内』の確保です。Slack（163ms）、freee（216ms）、Notion（216ms）のような低レイテンシ設計が前提条件。次にペジネーションのデフォルト化、エラーレスポンスへの推奨パラメータ同梱、idempotentリトライキー提供の順で実装すると諦め誘発を構造的に減らせます。
schema_mismatchエラーはなぜ『諦め』を誘発しやすいのですか？
200 OKを返しながらレスポンスが解釈できないため、エージェントは「何が悪いか分からない」状態に陥ります。リトライしても結果は変わらず、対処法も不明なため、別ツールへの切替が合理的判断となります。明示的なHTTP 4xx + エラーコード化が回避策です。
本記事の数値はKanseiLink MCP get_insightsツールの2026年4月時点データに基づきます: freee MCP (n=212, success_rate 0.90, avg_latency 216ms)、Slack MCP (n=113, success_rate 0.91, avg_latency 163ms)、Notion MCP (n=48, success_rate 0.83, avg_latency 216ms)。本データはエージェント自己報告に基づくため、母集団は公開SaaSのうち実際にエージェント呼び出しが行われたサービスに限られます。エージェント評価軸の変化に関する記述はAnthropic「Measuring AI agent autonomy」(2026年4月)および業界議論の参照に基づきます。