なぜ赔付ルールを客服のトークではなくプロダクトに書き込んだのか

提供状況（2026-07-09 更新）：本記事は補償体系の完全な設計を説明しています。ルールとアルゴリズムは記載どおり適用されます。現在は申請制です——サポートへ申請後、公開アルゴリズムに基づき審査・確定して残高へ入金します（申請方法はこちら）。自動監視は稼働中、自動計算・自動入金・月次メールは段階導入中です。それまで本文中の全自動入金や月次メールの記述は目標状態を指します。

世の中の SLA はどんなものか

主要な API サービス 10 社の SLA 文を読むと、ほぼ同じ形をしています：

• 可用率のコミット（よくあるのは 99.9% / 99.95%）
• 不可用時間に応じた賠償比率の表（月額の 5%–50%）
• 「ユーザーが自ら証拠を添えて申し立てること」という条項
• 「不可抗力は除外」という条項

これらの文の 実際の利用率は？ 同業数社に聞きました——ほぼゼロ。問題が起きたユーザーの第一反応は乗り換えであって、SLA を読むことではありません。

理由は単純です：申し立てプロセスのコストが、得られる賠償を上回る。 ログインして、チケットを起票して、スクリーンショットを上げて、7 営業日の審査を待ち、最後に月額 15% のクーポンが手に入るかどうか——時間コストを含めればマイナスです。

私たちがやったこと

私たちは赔付を「問題が起きてから読みに行く文書」から、プロダクト内の自動ロジックに変えました——ルール、計算、入金にあなたの操作は一切不要です。

1. 暦月 + SKU 大区分 + 三段階の賠付

各暦月（UTC+8）が締まると、その月の SKU 大区分ごと（Claude / Claude Code / GPT / Gemini / Qwen / 国産 5 割引一組 / Doubao）に可用率で独立して賠付を計算します：

• ≥ 99% — 賠付なし
• 98% – 99% — その SKU の当月注文額の 2%
• 95% – 98% — 5%
• < 95% — 10%（月上限も 10%）

段を独立計算する意味は：今月 Claude 96% / GPT 99.5% / Gemini 100% なら、Claude 部分だけ 5% で賠付し、他の SKU は動かしません。 なぜ連続式やより細かい中間段にしないか？ 顧客も BD も頭の中で計算できる必要があるからです。毎回顧客に「あなたの 96.3% は 5pp + 0.3 × X」と説明するのは時間の無駄です。三段の跳躍は「95% を守る」という目標ラインも強化します——oncall 自身がこれは下限だと分かっています。

2. 月末に自動精算、問題に気づく必要はない

月末処理の後、翌月 3 日 9 時に影響を受けた全顧客にメールが届きます：各 SKU 大区分の当月可用率、賠付金額、計算明細。金額はまず予備アカウントに入ります——メールと後台で見えますが、まだ使えません。 7 日間の異議申立期間（翌月 3–10 日）に、あなたか私たちのいずれかが計算に異議を出せます。期間が終わり成立した申立がなければ、金額は自動的に利用可能な残高になります。期間超過は既定で承諾です。 単件 ≥ ¥5000 の賠付は、まず 24 時間凍結して運営が複核し（dashboard のバグによる誤賠を防ぐ）、複核通過後に予備アカウントへ入ります。

極小サンプルは賠付を起動しない：単 SKU の月間呼び出しが 100 回未満、またはある SKU の全プラットフォーム月間サンプルが 1000 件未満の場合、規則上その月は賠付を起動しません——50 回の呼び出しから出した「94%」は統計ノイズが大きすぎ、賠付の根拠にできません。SLA の対象関係は変わらず、この場合に計算可能な賠付がないだけです。

3. 失敗の口径は私たちが責任を持てる硬エラーのみ——ここには張力がある

「不可用」の分子に入るのは、この 3 種のリクエストだけです：

• 上流サーバーが 5xx を返す（500/502/503/504）
• 上流が 60 秒以内に最初のバイトを返さない（タイムアウト）
• 当方ゲートウェイの 5xx（ルーティング / 課金層のクラッシュ）

能動的なレート制限、上流の 401 / 429、クライアント 4xx、残高切れは含めません。 これは議論を呼ぶ選択で、張力をはっきり述べねばなりません：

クライアントは「明らかに使えないのに SLA 数字は 99% のまま」に遭遇しえます——例えば単一キーが QPS 制限に触れた（429 を返し再試行を促す）、または上流のあるアカウントのトークンが切れて切替中、など。あなたが感じるのは「サービスが不安定」ですが、SLA 数字は動きません。

この口径を選んだのは数字を守るためではなく、当方ゲートウェイ + 上流サーバーの硬エラーだけが、SLA という意味が責任を持てる事柄だからです。レート制限はプロダクト戦略（接続ドキュメントに記載）、クライアント 4xx はリクエスト層のエラー。この 2 種を可用率に詰め込むと、SLA は当方にも意味の分からない数字になります。 実際にあなたのコード実行に影響するレート制限 / 401 / 429 の問題には、私たちの戦略は oncall が能動的に告警を見て 30 秒で切替であって、あなたのチケットを待つことではありません。

4. メンテ窓の控除は制約付きで、数字の美化には使えない

計画メンテは分母から控除できますが、同時に 3 条件を満たす場合のみ：≥ 7 日告知 + 単回 ≤ 4h + 月累計 ≤ 8h。8h を超えた分は分母に戻して故障計上。上流が主体のメンテ（事前告知でも）は控除不可——それは上流の問題で当方の問題ではありません。 このルールは意図的に厳しく書いています。運用がメンテ窓を SLA 美化ツールにするのを防ぐためです。

このやり方の代償

• 財務予測を作り直す必要がある — 賠付は実コストになり、「兌現されない約束」ではなくなりました。過去の障害データから賠付準備金率を立て、売上の約 0.4% です。
• 監視精度の閾値が上がる — 故障を誤判定すれば、ユーザーにお金を配ることになります。当方の故障判定アルゴリズムは内部で二人のコードレビューを行い、shadow を 1 か月走らせてから公開しました。
• 故障のナラティブをごまかせない — 以前は「偶発的な揺れ」と言えましたが、今は請求に賠付金額が白黒で書かれており、誠実さを欠けば自分の顔を叩くことになります。

なぜ今これを書くのか

最近いくつかのチームと話して、API サービスの SLA への期待がすでに非常に低いと分かりました——「書いてもどうせ無意味」。私たちが言いたいのは：SLA は法律文でなくてもよく、プロダクトそのものでありうる。 これは私たちが賢いのではなく、業界標準が低すぎるだけです。

この記事で「えっ、こういうやり方もあるのか」と思ってもらえたら、それで十分です。