◉CLAUDE LABEN
●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました
記事一覧/API & SDK
⬡ API & SDK/2026-06-24上級

Claude API の従量課金で、Stripe の請求額と自分の帳簿がズレるとき — 使用量イベントの突合運用メモ

Claude API の従量課金は「使った分だけ請求」が理想ですが、実運用ではStripe側の集計と自前の使用量台帳が静かにズレます。Billing Meters の冪等化・突合ジョブ・モデル変更耐性まで、運用で効いた設計を整理します。

claude-api83stripe7metered-billingbilling-metersreconciliation

✦ プレミアム記事

Claude API を組み込んだサービスで従量課金を始めると、最初の数週間は順調に見えます。問題が顔を出すのは月末です。Stripe が確定した請求額と、自分のダッシュボードに出していた「今月の使用量」が、わずかに、しかし確実にズレている。数円のこともあれば、ヘビーユーザーで数百円のこともあります。

このズレは、コードのバグというより、分散した2つの台帳(Stripe 側の meter と自前 DB の使用量カウンタ)を別々に書き込んでいることから生まれる構造的なものです。今回は、その構造を前提にした上で、ズレを「ゼロにする」のではなく「検知して説明できる状態に保つ」ための運用を整理します。設定手順の解説ではなく、本番で課金を1年ほど回して効いた設計の話です。

まず前提:createUsageRecord はもう使わない

少し前まで、Stripe の従量課金は Subscription Item に対して subscriptionItems.createUsageRecord() を送る方式でした。今もマイグレーション期間として動きますが、新規実装では Billing Meters を使うのが現行の作法です。違いは小さく見えて運用上は大きく、meter event は「どの顧客の」「どの指標を」「いくつ」増やすかを、Subscription Item ID を意識せずに送れます。

// lib/claude-metering.ts
import Anthropic from "@anthropic-ai/sdk";
import Stripe from "stripe";
 
const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
 
// 旧方式: stripe.subscriptionItems.createUsageRecord(itemId, {...})  ← 新規では使わない
// 新方式: meter に対して event を送る。顧客IDで紐づくので Subscription Item を引かなくてよい
async function sendMeterEvent(params: {
  stripeCustomerId: string;
  credits: number;
  identifier: string; // 冪等キー(後述)
}) {
  await stripe.billing.meterEvents.create({
    event_name: "claude_credits",
    identifier: params.identifier,
    payload: {
      stripe_customer_id: params.stripeCustomerId,
      value: String(params.credits),
    },
  });
}

event_name は Stripe ダッシュボードで作成した meter の名前と一致させます。meter 側で「value を月内で合算する(sum)」と設定しておけば、送った event がそのまま月間使用量として積み上がります。

トークンを直接送らず、「クレジット」を1枚かませる

ここが運用を楽にする最大のポイントです。Claude のトークン単価は入力と出力で違い、モデルでも違います。2026年6月時点で Sonnet 系と Opus 4.8、さらに上位の Fable 5 では桁が変わります。これを meter にトークン数のまま送ると、価格改定のたびに「過去の event の意味」が変わってしまい、請求ロジックが壊れます。

そこで、トークンを自社単位の クレジット に正規化してから送ります。モデルごとの単価差はクレジット換算係数に吸収させ、Stripe には常に「クレジット数」だけを渡す。こうしておくと、新モデルが出ても係数表に1行足すだけで済みます。

// モデルごとの「1クレジットあたりに丸める係数」を一箇所に集約する
// 値は2026年6月時点の概算。実際の単価は公式の料金ページで必ず確認すること
const MODEL_RATES: Record<string, { inPer1k: number; outPer1k: number }> = {
  "claude-sonnet-4-6": { inPer1k: 0.3, outPer1k: 1.5 },
  "claude-opus-4-8": { inPer1k: 1.5, outPer1k: 7.5 },
  "claude-fable-5": { inPer1k: 3.0, outPer1k: 15.0 },
};
 
// 1クレジット = サービス内部の最小課金単位。ここでは「概算0.1円相当」に寄せて整数化する
const YEN_PER_CREDIT = 0.1;
 
function tokensToCredits(model: string, inTok: number, outTok: number): number {
  const r = MODEL_RATES[model] ?? MODEL_RATES["claude-sonnet-4-6"];
  const yen = (inTok / 1000) * r.inPer1k + (outTok / 1000) * r.outPer1k;
  // 切り上げ。端数を事業者側が負担しないが、1リクエスト最低1クレジットは保証する
  return Math.max(1, Math.ceil(yen / YEN_PER_CREDIT));
}

なぜ整数に切り上げるのか。meter event の value は小数も扱えますが、自前 DB と突合するときに浮動小数の丸め差が生まれると、後述の reconciliation で「本当にズレているのか、丸め誤差なのか」が判別できなくなります。整数クレジットに寄せておくと、ズレが出たら必ず「件数の食い違い」として現れるので、原因を追いやすくなります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦Stripe Billing Meters の meter event を冪等化し、二重計上と取りこぼしの両方を同じ仕組みで防ぐ実装
✦Stripe 側の集計と自前台帳を月内に突合し、ズレを早期に検知する reconciliation ジョブの設計
✦Opus 4.8・Fable 5 のような価格改定をまたいでも請求ロジックを壊さない『クレジット』抽象の作り方
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

⬡ API & SDK2026-05-04
Claude API × Stripe で使用量ベース課金を最小構成で実装する
Claude API のトークン消費量を計測し、Stripe Meter Events で従量課金を実装する最小構成を解説。個人開発者が週末に実装できる Node.js コード例と、本番で詰まりやすい3つのポイントを共有します。
⬡ API & SDK2026-04-28
Claude API × Stripe で月額課金 SaaS を設計する — アーキテクチャから実装まで
Claude API を組み込んだ SaaS の月額課金設計を、Stripe Billing・Usage Metering・Webhook の実装コード付きで解説します。APIコスト管理からティア設計まで、個人開発者が実際に収益化するための設計パターンです。
⬡ API & SDK2026-09-22
PDF の入力トークンは文字数では読めません — 送る前にページ数から上限で挟む
Claude API に PDF を送る前の入力トークンを、文字数ではなくページ数から上限で挟んで見積もる手順です。A4 9 ページの日本語文書で文字数見積もりの 6.6 倍になった実測と、解像度ティアとトークナイザの二重の増分、count_tokens が file_id を数えられない制約までをまとめます。