CLAUDE LABEN
CONFERENCE — 年次開発者会議「Code w/ Claude」が6/22から開催。Claudeを作るチームと直接対話できる場が設けられましたLIMITS — Claude Codeのレート上限が倍増、OpusのAPI上限も引き上げ。安定して規模を出しやすくなりましたDESIGN — Claude Designが更新。デザインシステム整合・Claude Code同期強化・キャンバス直接編集に対応しましたSANDBOX — Claude Managed Agentsが自前サンドボックス+プライベートMCPサーバー接続に対応しましたMODEL — Claude Fable 5は100万トークン文脈・常時アダプティブ思考・128K出力を備えますLINEUP — 主力はOpus 4.8・Sonnet 4.6・Haiku 4.5。用途に応じて使い分けられますCONFERENCE — 年次開発者会議「Code w/ Claude」が6/22から開催。Claudeを作るチームと直接対話できる場が設けられましたLIMITS — Claude Codeのレート上限が倍増、OpusのAPI上限も引き上げ。安定して規模を出しやすくなりましたDESIGN — Claude Designが更新。デザインシステム整合・Claude Code同期強化・キャンバス直接編集に対応しましたSANDBOX — Claude Managed Agentsが自前サンドボックス+プライベートMCPサーバー接続に対応しましたMODEL — Claude Fable 5は100万トークン文脈・常時アダプティブ思考・128K出力を備えますLINEUP — 主力はOpus 4.8・Sonnet 4.6・Haiku 4.5。用途に応じて使い分けられます
記事一覧/API & SDK
API & SDK/2026-06-24上級

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

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

claude-api70stripe6metered-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-06-24
毎朝のバッチでプロンプトキャッシュが毎回ミスしていた — 1時間TTLを延命するウォーミング間隔と損益分岐の出し方
数時間おきに走る定期実行では、1時間TTLのプロンプトキャッシュでも毎回コールドミスします。中身を変えずにTTLを延命するウォーミングの間隔をTTLから逆算し、読み取りコストを織り込んだ損益分岐を式で出す方法を、4サイトの自動生成パイプラインの実測とともにまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →