Claude APIのクレジットは有効期限が1年で返金不可 — Credit Termsを読む
Claude APIで買った前払いクレジットは、購入から1年で失効し、返金も譲渡もできません。Supplemental Credit Termsの条文と自動チャージの範囲を読み解きます。
Claude APIで買った前払いクレジットは、購入から1年で失効します。返金はできず、他のアカウントへ譲ることもできません。この3点は、AnthropicのSupplemental Credit Terms(以下Credit Terms)に条文として書かれています。まとめ買いをする前と、自動チャージを有効にする前に、条文が何を約束していて何を約束していないかを押さえておくと、無駄な失効を避けやすくなります。
Credit Termsは何を定めている規約か
Credit Termsは、Anthropicとの契約(Agreement)にリンクまたは言及される付属条項です。発効日は2024年3月4日と記載されています。定義されていない大文字語は、本体の契約の定義に従います。
構成は2部だけです。
| 部 | 内容 |
|---|---|
| A. Types of Credits | 内容クレジットの種類(Usage Credits / Promotional Credits) |
| B. Terms | 内容返金不可・失効・譲渡禁止・Balance Maintenance Service |
条文は短く、Bの4項目で実務上の論点がほぼ尽きます。Pro・Max・Teamといったclaude.ai側の使用量クレジットの話ではありません。個人プランの使用量クレジットはClaude利用クレジットの購入・管理方法、TeamとEnterpriseはClaude Teamの使用量クレジットが扱っています。ここではConsole組織でAPIを使うときの前払いクレジットに絞ります。
2種類のクレジットはどう違うか
Credit Termsが定義するクレジットは2種類です。
Usage Creditsは購入するクレジットです。条文では、Anthropicが一部のサービスについて、モデル料金ページに従った利用額を賄えるだけのクレジットの前払いを求めることがある、と書かれています。合意が別にあれば、その合意が優先されます。
契約の成立の仕方に特徴があります。顧客がクレジットを注文する行為は「購入の申込み」にあたり、Anthropicが受け入れを通知した時点(Confirmation Notice)でCredit Termsが有効になります。つまり、注文ボタンを押した瞬間ではなく、確認通知が送られた時点が起点です。
Promotional Creditsは、Anthropicが裁量で無償提供するクレジットです。プロモーションの一環か、サービスへの登録時に付与されると書かれています。
| 種類 | 入手経路 | 失効の起点 |
|---|---|---|
| Usage Credits | 入手経路購入(注文 → Confirmation Notice) | 失効の起点確認通知の送付日、または発行日から暦で1年 |
| Promotional Credits | 入手経路無償提供 | 失効の起点発行時に示された期限。指定がなければ発行から1年 |
有効期限と返金は条文でどう書かれているか
Bの最初の項目に、返金・失効・法的性質がまとめて置かれています。要点は次のとおりです。
- Anthropicが発行するクレジットは、Usage CreditsとPromotional Creditsを含めてすべて返金不可
- Usage Creditsは、確認通知の送付日(または発行日)から暦で1年で失効
- Promotional Creditsは、発行時に示された時点で失効。指定がなければ発行から1年
- アカウントを閉じると、クレジットは自動的に失効し、取り戻せない
- クレジットは法定通貨ではなく、現金価値を持たない
- 残高はPlans & Billingページで確認できる
「暦で1年」とは、購入日の1年後の同じ日という読み方が自然です。条文はこの計算方法まで踏み込んでいないので、期限日は購入日(確認通知の日付)を控えておき、自分で管理する形になります。
サポート記事の記述はこれと整合します。購入したクレジットは購入日から1年で失効し、失効日は延長できず、すべての購入は返金不可とされています。失効したクレジットは、ConsoleのBillingページの請求履歴(Invoice history)に表示されます。
ここで見落としやすいのが、アカウントを閉じた場合です。残高が残っていても、閉鎖と同時に失効し、復元できません。組織の整理やアカウント統合を考えているなら、閉じる前に残高を使い切る計画が要ります。
複数回に分けて買った残高の期限はどうなるか
条文が定めているのは購入ごとの1年です。複数回に分けて購入した場合、どの購入分から先に消費されるかについては、Credit Termsにも今回参照したサポート記事にも記載がありません。期限が近い分から使われるのか、購入順なのかは断定できません。購入日ごとに金額と確認通知の日付を記録しておき、それぞれの1年後を自分で把握しておく運用が現実的です。
譲渡できないとはどういう意味か
No Transferの項目は短く、次の2点です。
- 購入分か無償分かを問わず、他の個人・法人へ譲渡・販売できない
- クレジットを使えるのは、そのクレジットが紐づくアカウントの保有者だけ
実務では、グループ会社で余ったクレジットを別のConsole組織に付け替える、外部の開発委託先に使わせる、といった運用ができないことを意味します。委託先にAPIを使わせたい場合は、自組織のアカウントでAPIキーを発行して使わせる形になり、その利用分は自組織のクレジットから引かれます。
Balance Maintenance Serviceで何に同意することになるか
Balance Maintenance Serviceは、残高が一定の水準に達したときにクレジットを自動で追加購入する仕組みです。条文には「オプションとして提供されることがある」と書かれています。水準は顧客がPlans & Billingページで設定します。
有効にすると、次の内容に同意したことになります。
- アカウントに登録した支払い方法に、繰り返し課金することをAnthropicに認める
- 課金の対象は、自動チャージで追加されたクレジットの金額に応じた料金と税
- 同意は、顧客がBalance Maintenance Serviceをオフにするまで続く
- 追加されたクレジットは、追加された日か、その前後に課金される
サポート記事は、この機能をAuto-reloadと呼んでいます。BillingページのAuto-reload欄で「Edit」を選び、オンかオフを切り替えます。オンにすると、購入を起動する最低残高と、そこまで戻す金額の2つを指定します。規約上の名称と画面上の名称が異なる点に注意してください。両者が同じ機能を指すと読めますが、サポート記事はCredit TermsのBalance Maintenance Serviceという語を使っていません。
自動チャージと失効・返金の組み合わせで起きること
自動チャージ自体は便利です。残高が尽きると、API呼び出しもプレイグラウンドも使えなくなるため、本番運用では止まる前に補充したい場面があります。
ただし、規約を組み合わせると次の性質が見えます。
- 自動チャージで追加された分もCreditsなので、返金不可で1年で失効する
- オフにするまで同意が続くので、設定を忘れたまま利用が減ると、使わない分の購入が続く可能性がある
閾値と補充額を消費ペースに合わせて決めておかないと、消化しきれないクレジットを自動で買い足す形になり得ます。補充額を小さめにして頻度で調整するか、月次でBillingページを確認する習慣を付けると、この失効リスクは小さくなります。
前払いクレジットの買い方を消費ペースで決める
規約からの実務的な帰結は、購入額を「1年で確実に使い切れる量」に抑えることです。直近の月間消費の傾向ごとに、購入額の考え方を並べます。
| 直近3か月の消費の傾向 | 1年の見込み | 1回の購入額の考え方 |
|---|---|---|
| 一定で安定 | 1年の見込み月間消費 × 12が上限 | 1回の購入額の考え方数か月分に分けて買う |
| 増加中 | 1年の見込み現在の水準より多い | 1回の購入額の考え方現在の消費ペースで足りる範囲に抑える |
| 波が大きい・案件次第 | 1年の見込み読みにくい | 1回の購入額の考え方少額購入と自動チャージの下限設定の併用 |
まとめ買いの割引がAPIのクレジットにあるとは、今回確認した一次ソースには書かれていません。割引を理由に大きく買う前提は置けません。請求書払い(月末締めの後払い)については、サポート記事に、Salesチーム経由で請求書払いを設定したConsole組織が対象と説明されています。失効を避けたい大口利用では、この選択肢が営業への相談事項になります。
購入時の操作も確認しておきます。サポート記事によると、ConsoleにAdminかBillingのロールでログインし、Settings > Billingで「Buy credits」を選び、金額を入力して確定します。購入したクレジットはすぐに利用可能になり、残高と利用状況は同じBillingページに出ます。
失敗した呼び出しは課金されるのか
前払いの残高が減る条件も、サポート記事に書かれています。課金対象は成功したAPI呼び出しと完了したタスクで、失敗したリクエストは課金されません。ただし、成功する見込みだったリクエストの途中でクライアントが切断またはタイムアウトした場合は、そのリクエストにも課金されます。
タイムアウトを短く設定しすぎると、応答が返らないまま課金されるリスクがあるということです。ストリーミングでの長い生成では、クライアント側のタイムアウト値を見直す価値があります。refusalからの再試行で二重課金が起きる場合の対処は、fallback_credit_tokenで二重課金を防ぐで扱っています。
個人向けの返金条件とは別の話
Credit Termsの「返金不可」は、クレジットという商品の性質についての条項です。日本の消費者向けに提供されるClaudeの有料プランの解約や返金は、別の表示(特定商取引法に基づく表示)で扱われています。Anthropicの特定商取引法に基づく表示を参照してください。APIの前払いクレジットの規約と、個人プランの解約条件は、それぞれ別の文書で決まっています。
製品ごとの追加条項の全体像はService Specific Termsの解説にまとめています。Credit Termsは、その製品別条項とは別立ての、クレジットに特化した付属条項です。
失効前にやっておく確認事項
条文とサポート記事を踏まえると、購入と運用で確認する点は次の4つです。
- Billingページで残高と請求履歴を確認する(失効した分はInvoice historyに載る)。購入日は別に控えておく
- 自動チャージの閾値と補充額が、直近の消費ペースに見合っているか見直す
- アカウントを閉じる前に、残高を使い切る
- Promotional Creditsは発行時に示された期限を確認する(指定がなければ1年)
クレジットの失効は延長できず、返金の道もありません。前払いという仕組み上、使い切れない量を買わないことが、失効を避ける近道になります。
まとめ
Credit Termsの核心は短い4文にまとまります。すべてのクレジットは返金不可で、Usage Creditsは確認通知から1年で失効し、譲渡はできず、自動チャージは同意の取り消しまで続きます。購入額と自動チャージの設定は、1年で確実に消費できる範囲に合わせておくと、この規約による失効の影響を小さくできます。