[ blog · deep-dive ]7 min read

API は成功時にだけ課金すべき理由 — HTTP 200 課金の論拠

Sarah Choy公開: 2026年5月3日読了 7 分

ほとんどの API は課金対象の呼び出しごとに課金する。AI エージェントは不安定な上流サービスに対して絶えずリトライする — つまり旧来の『常に課金』モデルは、実質的にレジリエンスへの課税だ。HTTP 200 のときだけ課金する論拠と、それがエージェントの設計をどう変えるかを示す。

要点

•AI エージェントは一時的な失敗（5xx、タイムアウト、レートリミット）に対して合理的にリトライする。『常に課金』では、すべてのリトライが本物の課金になる — 稼働率 99.5% の上流を、悪い 0.5% の間は 5 倍のコストペナルティに変えてしまう。
•『HTTP 200 のときだけ課金』は、プロバイダーのインセンティブを顧客のそれと一致させる：プロバイダーは不安定さを直し、顧客はそれにお金を払わない。
•さらに、設計パターンも解放する — 積極的なリトライ予算、楽観的プリフェッチ、冗長呼び出し — 『常に課金』ではこれらが法外に高くつく。
•ほとんどのプロバイダーがこれをやらないのは、レガシーインフラが課金をレスポンスではなく上流呼び出しに紐づけているからだ。それはポリシーを装った課金システムの制約にすぎない。

我々が促そうとしている振る舞い

AI エージェントは新しい種類の API クライアントだ。エラーを 1 つ捕まえてオンコールのエンジニアにメールしていた 2015 年の慎重なエンタープライズ統合とは違う。彼らはループであり、何かが失敗すると少し眠ってからもう一度試す — ときに 5 回も 10 回も — そして結果を人間にいっさい見せない。ループの要点はまさに、一時的な失敗をエンドユーザーから見えなくすることにある。

これは素晴らしいパターンだ。レジリエントな製品を生む。パブリックインターネットの散らかった現実をユーザーから隠す。問題は、API の課金モデルが、リトライがまれで、デフォルトで思いとどまらせるほど高コストだった時代に定められたことだ。今もそのように動いている。すべてのリトライが課金対象の呼び出しで、何かを返したかどうかに関係ない。

具体的には：稼働率 99.5% の API を叩き、一時的な失敗に対して最大 5 回までリトライするエージェントは、悪い 0.5% の間に最大 5 倍の呼び出しを生み — そして 5 倍の請求を生む。エージェントは正しいことをした。顧客は上流の不安定さの代金を払う。

よりシンプルな代替案

HTTP 200 のときだけ課金する。具体的には、ドキュメント化されたレスポンス形状を伴う成功レスポンスのときだけ。それ以外はすべて — 呼び出し側エラーの 4xx、我々のエラーの 5xx、タイムアウト、レートリミット、部分的だが不正なレスポンス — は無料だ。

小さな変更に聞こえる。そうではない。これは両側で経済的に合理的なものを変える：

プロバイダーは今や、不安定さを直す直接の金銭的インセンティブを持つ。すべての不安定な 503 は、ただ飯ではなく逃した売上だ。我々の経験では、成功時のみ課金の採用は、信頼性の仕事をロードマップの先頭へ引き上げた唯一最大の力だった — それらの呼び出しの売上を放棄しているとき、ダウンタイムを問題なく見せかけるスプレッドシートの小細工は存在しない。
顧客はリトライ予算を積極的に設定できる。一時的な失敗の最悪ケースが、6 回（試行ごとに 1 回課金）ではなく 1 回の課金呼び出し（最終的な成功）で済むなら、指数バックオフ 5 回リトライのループは即断で採用できる。
市場は、API を「試行 1 回あたりのドル」ではなく「成功した呼び出し 1 回あたりのドル」で比較できる。それが正しい単位だ。2 つの API がどちらも「1 回 $0.001」と謳っていても、一方が稼働率 99.9% でもう一方が 95% なら、ユーザーに見えるコストは常に課金で 5 倍違い、成功時のみ課金ではちょうど 0% 違う。買い手がどちらを選ぶべきかは明らかだ — そして成功時のみ課金はそれを可視化する。

エージェントの作り方について何が変わるか

1. リトライ予算が無料になる

常に課金では、一時的失敗ハンドラの正しいリトライ予算はおおむね 1〜2 回だ — それを超えると、繰り返す失敗のコストが効いてくる。成功時のみ課金では、予算は「ユーザーが待てる限り」になる。我々は、レガシー課金では無謀だったであろう、指数バックオフ・ジッター付き 5 回リトライのエージェントループを日常的に見ている。

2. 楽観的プリフェッチが安くなる

常に課金では法外に高くつくパターン：ユーザーがまだ入力している間に、予測クエリが当たっている場合に備えて検索呼び出しを投機的に発火させる。予測が外れたら結果を捨てる。成功時のみ課金ではこれは安い。キャンセルされた / 使われなかった呼び出しは成功を返すが、あなたはレスポンスを破棄する — つまり予測可能性とレイテンシのために小さなプレミアムを払うだけだ。常に課金では、外れた予測のすべてが課金呼び出しになるので、このヒューリスティックは出荷するには高すぎる。

3. 冗長呼び出しが信頼性のツールになる

最も安い信頼性戦略が、2 つの異なる API に 2 つのリクエストを撃ち、先に返ってきた方を取り、遅い方を捨てることである場合がある。常に課金ではそれは請求を倍にする。成功時のみ課金では、捨てられた呼び出しは無料だ（レスポンスを使わなかったので、料金も払わない）。突如として、高価な抽象でしかなかったヘッジ戦略が実用的になる。

「成功」が意味しなければならないもの

このモデルは「成功」が曖昧でないときにのみ機能する。我々はそれを厳密に定義する：

ドキュメント化されたレスポンススキーマを伴う HTTP 200 — 課金対象。
レスポンスボディにエラーが包まれた HTTP 200 — 課金対象外（これがモデル全体を壊す抜け穴になる）。
HTTP 4xx — 課金対象外。これには 401（認証）、402（credit 不足）、422（バリデーション）、404（文脈によっては見つからない）が含まれる。
HTTP 5xx — 課金対象外。
HTTP 429（レートリミット）— 課金対象外。
我々のエッジに届く前のネットワークエラー / タイムアウト — 課金対象外。

バッチエンドポイント（たとえば 1 回の呼び出しで 25 URL を扱う URL Extract）では、いずれかの URL が成功すれば呼び出し全体は 1 つの HTTP 200 となり、URL 単位のレートで課金される。URL 単位の status フィールドが、どの URL が失敗したかを呼び出し側に伝える。仕事は行われた。だから課金対象だ。

なぜほとんどのプロバイダーはこれをやらないのか

理由は 3 つ、それぞれがどれだけ効くかの順に：

課金インフラ。標準的なパターンは、レスポンスが分かる前に API ゲートウェイで計測することだ。ゲートウェイが課金イベントを Kafka に流し、課金システムがそれを集計し、請求が送られる。上流サービスがステータスコードで応答した後で計測を発火させるよう配線し直すには、(a) ゲートウェイをバックエンドの健全性に結合する（新しい障害モードを生む）か、(b) 失敗した呼び出しを遡及的に返金する突合パイプラインを書く、のいずれかが必要になる。どちらも本物のエンジニアリング作業だ。
習慣。このパターンは信頼できるバックエンド — Twilio、AWS、Stripe — が定めた。上流が稼働率 99.99% なら問題なく機能する。LLM をラップしたり、web をスクレイピングしたり、遅いデータパートナーを呼んだりする API ははるかに信頼性が低いが、課金パターンは信頼できた時代から受け継がれ、更新されなかった。
売上。常に課金は単純に金が増える。ほとんどの顧客はこれまでエージェントトラフィックではなかったので、ほとんどのプロバイダーはこの軸で競争する必要がなかった。そして同期的な人間ユーザーは、課金モデルを読まされるよりも、たまの失敗の方をうまく許容する。

最初のものは本物のエンジニアリングだ。2 つ目と 3 つ目は惰性だ。どちらも、エージェントトラフィックが API 消費の大半になるにつれて崩れていく — トレンドラインによれば、それはほとんどのパブリック API について 18 か月以内に起きつつある。

買い手として何を見るべきか

エージェントワークロード向けにデータ API を評価しているなら、明示的な質問が 3 つ：

「課金は HTTP 200 のときだけですか、それとも課金対象の試行ごとですか？」 — はっきりした答えが必要。「たいてい」や「プラン次第」は受け入れないこと。
「HTTP 207 / 部分成功はどう課金されますか？」 — 抜け穴の答えをあぶり出す。
「公表している稼働率はいくつで、それを下回った場合の SLA 返金メカニズムは何ですか？」 — 成功時のみ課金は強いシグナルだが、実際の SLA の代わりにはならない。両方そろっているべきだ。

これが指し示す変化

AI エージェントは、触れるすべての API のユニットエコノミクスを変える。エージェント時代に向けて設計された API は見た目が違う — よりシンプルな形状、予測可能なスキーマ、機械に優しい認証、透明な価格 — そして課金モデルも違って見える。成功時のみ課金は、よりシンプルな変化の 1 つだ。より難しいもの、まだ我々の前途にあるものは、フルパスを単一の当事者が所有しないときに、マルチステップのエージェントワークフローがプロバイダーをまたいでどう価格付けされるかを解明することだ。

当面は、可能なプロバイダーには成功時のみ課金を要求しよう。それを活かすエージェントを作ろう。そして API を物色するときは、「試行 1 回あたりのドル」ではなく「成功した呼び出し 1 回あたりのドル」で計算を回そう。

よくある質問

『成功時のみ』はプロバイダーに、成功を失敗と誤分類するインセンティブを与えないか？

理屈の上では。だが逆方向の圧力の方が強い：開発者は API を「実世界での有用な呼び出し 1 回あたりのドル」で比較し、まさにそれを成功時のみ課金が測る。成功をこっそり失敗に再分類するプロバイダーは、数日のうちに怒りのサポートキューと公開レビューの足跡に直面する。市場はこれが自己修正する程度には小さい。

呼び出しが部分的に成功したら？ — たとえばバッチ抽出で 25 URL のうち 2 つが失敗した場合は？

妥当なモデルが 2 つある。(a) いずれかの URL が成功すれば呼び出し全体は HTTP 200。URL 単位の失敗は URL 単位のステータスで報告される。仕事は発生したので課金対象だ。(b) 部分成功には HTTP 207（multi-status）を使い、各 URL を個別に課金する。我々は (a) を選んだ。価格が予測可能になるからだ — エージェントは、成功した HTTP 200 が返れば最悪でも告知された credit コストで済むと分かる。(b) はより「公平」だが、予算を立てにくい。

何が失敗にあたるのか？

我々のルール：明らかに呼び出し側の責任である HTTP 4xx（不正なボディ、認証欠如、credit 不足）は課金しない。HTTP 5xx は決して課金しない — それは我々の問題だ。我々の側でのネットワークエラーやタイムアウトも決して課金しない。レートリミット（429）も決して課金しない。課金されるのは、告知されたレスポンス形状を伴う HTTP 200 だけだ。

なぜほとんどのプロバイダーは呼び出しごとに課金するのか？

理由は 3 つ、おおむね歴史的なものだ。(1) レガシーな課金システムは、レスポンスが分かる前に API ゲートウェイで計測する。レスポンスステータスに応じて遡及的に課金を発火させる配線は簡単ではない。(2) このパターンは信頼できるバックエンドの時代に Twilio と AWS が定めた。LLM をラップしたり web をスクレイピングしたりする API ははるかに信頼性が低いので、その前提が成り立たなくなる。(3) その方が売上が増える。最初の 2 つは言い訳で、3 つ目が本音だ。

『常に課金』が理にかなうケースはあるか？

結果に関係なく、呼び出しごとに固定コストを実際に消費する場合だ — たとえばハードウェアの呼び出し（SMS 送信）、境界でアトミックなミューテーション（DNS 更新）、あるいは「試みて失敗した」と「実行したがあなたが気づかなかった」をバックエンドが区別できないサービスなど。読み取り型のデータ API や検索 API には、このモデルは合わない。