「リトライ税」の経済学 2026 — 成功率の低いMCPサーバーが、なぜAPI請求書を静かに膨らませるのか

なぜ「成功率」を財務指標として読むべきか

エージェント運用のコスト議論は、長らく「どのモデルを使うか」「どこにホスティングするか」に偏ってきた。だが2026年に入り、エージェントが実際に叩くMCPサーバーやAPIの成功率そのものがコスト要因だという認識が広がりつつある。

理由はシンプルだ。エージェントはツール呼び出しが失敗しても、そこで止まらない。エラーを読み、原因を推論し、リトライするか代替手段を取るかを判断する。1回の失敗は、追加のLLMターンを1つ以上発生させる。そして会話履歴が伸びるほど、後続ターンの入力トークンも膨らんでいく。成功率が低いサービスは、ユーザーが目にする請求書を静かに、しかし確実に押し上げる。

本記事ではこの追加コストを「リトライ税(Retry Tax)」と呼ぶ。リトライ税は、KanseiLinkが225+の日本SaaSについて集計しているエージェントのアウトカム報告(2026年5月時点で累計1,404件)を背景に、成功率pを仮定したモデルで定量的に試算できる。

リトライ税の計算式 — 期待試行回数は 1/p

各試行が独立で成功確率 p だと近似すると、1回成功させるまでの期待試行回数は 1/p(幾何分布の期待値)で表せる。これがリトライ税の核となる式だ。

注目すべきは曲線の形だ。成功率が91%から80%へ落ちても税率は14%増にとどまるが、50%を切ったあたりから急激に立ち上がる。成功率20%のサービスは、91%のサービスと同じ成果を出すために約4.5倍のツール呼び出しを必要とする。これは「ちょっと不便」ではなく、原価が4倍以上違うという話だ。

モデルケースで見る節約幅 — 4つの切り替え試算

KanseiLinkの audit_cost ツールは、エージェントのAPI支出を4階層(モデル選択・サービス代替・アーキテクチャ・インフラ)で分析し、最適化を提案する。「サービス代替」レイヤーの効果を、成功率pを仮定した4つのモデルケースで試算すると、リトライ税の実額がよく分かる(以下の成功率は仮定値。実名サービスの成功率はKanseiLinkで現在実測データを蓄積中＝観測中)。

最も極端なのが表の1行目だ。成功率20%と仮定したサービスでは、期待試行回数は約5回。一方、成功率91%と仮定したサービスなら約1.1回で済む。この差が、同じ「メッセージを送る」というタスクで約71%のトークン削減として表れる計算になる。

もうひとつ押さえておきたいのは、市場での知名度と、エージェントから見た「叩きやすさ」は別物だという点だ。知名度の高いSaaSでも、エージェント接続の初期データではエラー報告が目立つケースがある(例: あるHR SaaS大手では92件の報告のうち api_error 36件、auth_expired 10件、search_miss 7件)。リトライ税は知名度を考慮してくれない。

リトライ税は「掛け算」で効く

前述の通り、リトライ税は「ツール呼び出しが N 回に増える」だけでは終わらない。失敗1回が連鎖的に複数のコストを生む。

• トークン軸: エラーレスポンス全文がコンテキストに入り、リトライ判断のLLMターンが追加され、会話履歴が伸びた状態で後続ターンが回る。失敗が後半で起きるほど、抱えている履歴が大きく入力トークンが重い。
• LLM呼び出し軸: 1回の失敗につき最低1つ、多くは2〜3つの追加ターン(エラー解析→リトライ実行→結果確認)。モデル単価がそのまま乗る。
• レイテンシ軸: 失敗→リトライは実行時間を積み増す。プローブ実測ではサービス間でレイテンシに2倍以上の開き(例: 337ms vs 163ms)がある。遅いサービスを2回以上叩く構図は、ユーザー体感を二重に悪化させる。

だからこそ、リトライ税対策は「成功率を上げる」だけでなく「失敗1回あたりの単価を下げる」両面で考える価値がある。後者で最も効くのがプロンプトキャッシングだ。

プロンプトキャッシングはリトライ税の「税率」を下げる

Claude APIのプロンプトキャッシングでは、キャッシュ読み取りが基本入力単価の0.1倍(90%引き)になる(2026年5月時点。5分キャッシュの書き込みは1.25倍、1時間キャッシュは2倍)。具体的には、Claude Sonnet 4.6 のキャッシュ読み取りは $3/100万トークンが $0.30 に、Claude Opus 4.7 は $5 が $0.50 になる。

リトライのたびに再送されるのは、システムプロンプト・ツール定義・会話履歴の固定部分だ。これらをキャッシュに載せておけば、リトライが発生しても入力トークンの大半が90%引きで処理される。リトライ税そのものを消すわけではないが、税率を大きく下げる。リトライが避けられないワークロードほど、キャッシュの効果は大きい。

# Claude API: 固定部分をキャッシュに載せる(疑似コード)
messages.create(
  model="claude-sonnet-4-6",
  system=[
    { "type": "text", "text": SYSTEM_PROMPT,
      "cache_control": {"type": "ephemeral"} }   # ← リトライ時もキャッシュ読み取り(0.1x)
  ],
  tools=[ ...TOOL_DEFS, {"cache_control": {"type": "ephemeral"}} ],
  messages=conversation,
)

リトライ税を下げる4階層

KanseiLinkの audit_cost の4階層フレームに沿って、リトライ税の削減策を効果の大きい順に並べる。

• サービス代替(最大効果) — 成功率20%→91%のような桁違いの改善はここでしか得られない。search_services や get_insights で代替候補の成功率を確認し、タスクが許す限り高成功率サービスへ寄せる。
• 初回成功率を上げる — 既知のワークアラウンドを事前に組み込む。例: SmartHRはv1ではなくv2エンドポイントを使う(auth_expired 回避)、kintoneは /records.json の一括APIを使う(個別呼び出しを最大50分の1に)、Chatworkは application/x-www-form-urlencoded でPOSTする(JSON送信で400エラーになる)。get_service_tips でこれらは事前に取得できる。
• 失敗単価を下げる(プロンプトキャッシング) — システムプロンプト・ツール定義・会話履歴の固定部分をキャッシュ。リトライが避けられないワークロードで税率を下げる。
• インフラ層 — Vercel→Cloudflare Workers移行(高トラフィックで最大85%削減)、AWS App Runner利用者はECS Express Mode等への移行検討(App Runnerは2026年4月30日以降、新規受付停止・メンテナンスモード移行)。リトライ税とは別軸だが、運用コスト全体を見るなら同時に点検したい。

FAQ

「リトライ税」とは何ですか？

MCPサーバーやAPIの成功率が低いことで追加発生するトークン消費・レイテンシ・LLM呼び出しコストの総称です。1回成功させる期待試行回数は成功率pに対して 1/p で近似でき、成功率20%なら平均5回、91%なら平均1.1回。成功率20%のサービスは91%の約4.5倍のトークンを同じ成果のために消費します。

成功率が低いと、なぜコストが「掛け算」で増えるのですか？

失敗1回のコストはツール呼び出しの入力トークンだけではないからです。失敗するとエージェントはエラー全文の取り込み・原因推論・リトライ判断という追加LLMターンを回し、会話履歴が伸びるほど後続ターンの入力トークンも増えます。トークン・LLM呼び出し回数・実行時間の3軸が同時に悪化します。

プロンプトキャッシングはリトライ税にどう効きますか？

リトライ税の「税率」を下げます。Claude APIのキャッシュ読み取りは基本入力単価の0.1倍(90%引き)です(2026年5月時点)。リトライ時に再送されるシステムプロンプトやツール定義をキャッシュに載せておけば、リトライが発生しても入力トークンの大半が90%引きで処理されます。

リトライ税を下げる一番効果的な方法は？

成功率の高い代替サービスへの切り替えです。成功率20%→91%のような桁違いの改善はサービス代替でしか得られず、トークン削減効果が最大になります。次点はプロンプトキャッシング、一括API/バッチAPI、既知ワークアラウンドの事前組み込みです。

成功率はどこで確認できますか？

KanseiLink MCPの get_insights で、対象サービスの success_rate・avg_latency_ms・common_errors(既知ワークアラウンド付き)・confidence_score を取得できます。search_services でも各サービスの success_rate が返ります。接続コマンドは npx -y @kansei-link/mcp-server です。