利用明細の読み方：すべての請求と返金を確認する

残高が自分の計算より180少ない、あるいは180多い。どちらにしても、クライアントに伝える前に理由を知っておきたいところです。その答えはリクエストログにありますが、それは何が記録されているのかを知っていればの話です。リクエストログは成功した生成の一覧ではなく、クレジットの動きの台帳であり、この2つは同じリストではないからです。

動き1つにつき1行

クレジットが動くたびに、1行が書き込まれます。行には、日時、操作、モデルID、符号付きのクレジット数が記録されます。これを表示しているのが、開発者ダッシュボードのリクエストログです。

操作は6種類で、その列に表示される値はこれだけです。

• chat：RP+またはRP miniでの1回の生成です。画像認識を使う場合は、添付画像1枚につき追加される2クレジットも含みます。
• image：1回の画像生成の呼び出しです。4枚のバッチも、4行ではなく1行です。
• video：キューに入った1本のクリップです。
• speech：1回の音声合成の呼び出しで、100文字ごとに課金されます（端数も1ブロックとして計算）。
• transcription：1回の文字起こしの呼び出しで、音声1分ごとに課金されます（端数も1分として計算）。計測された長さは行の詳細に記録されます。
• storage：eroq Storeへのアップロードで、10 MBごとに2クレジットです（端数も10 MBとして計算）。

ログはワークスペース単位なので、チームメイトの呼び出しも含まれます。対象は直近30日分で、50行ずつのページで表示されます。モデルの列には公開モデルID（eroq-image-anime、seedance-2-5、eroq-voice-turboなど）が入ります。これはリクエストで渡した文字列と同じなので、各行を自分のログの特定の呼び出しまでたどれます。

課金は納品時ではなく送信時

わかりにくい明細のほとんどは、このルールで説明できます。クレジットはエンジンが動く前に消費され、後から消費されることはありません。成功したときに課金するほうが公平に聞こえますが、それは実装できません。そうしなければ、ストリームの途中で接続を切るクライアントが、毎回タダで生成を手に入れられてしまうからです。

そのため、請求の行はリクエストが受け付けられた瞬間に作られます。動画クリップは、ファイルが届いたときではなく、ジョブがキューに入った時点で引き落とされます。4枚の画像のバッチなら、最初のピクセルが描かれる前に40クレジットが引き落とされます。それでも公平なのは、ルールのもう半分があるからです。失敗すれば、クレジットは戻ってきます。

マイナスの行は返金

返金は、マイナスの金額を持つ2つ目の行として書き込まれます。表では返金のタグが付き、プラス記号付きで表示されます。明細の上では、返金はあなたのもとに戻ってくるお金だからです。

返金は自動で行われ、生成が届かなかったあらゆるケースをカバーします。エンジンが何も返さなかった、エンジンがプロンプトをブロックした、動画のジョブが10分の期限を過ぎても終わらなかった、チャットのストリームがトークンを1つも出さずに途切れた、課金後にアップロードが失敗した。申請することも、サポートチケットを出すこともありません。

金額を見れば、何が失敗したのかがわかります。動画の返金は、常にクリップの全額です。クリップは届くか届かないかのどちらかだからです。画像の返金は、失敗したテイク1つにつき1単位（10クレジット）です。つまり、4枚のバッチで2枚が失敗した場合、40クレジットの請求と、10クレジットの返金2行が別々に表示されます。この非対称性こそが診断のすべてです。画像の行に部分的な返金があれば、バッチの一部が空で返ってきたということです。

残高照合の実例

1日の始まりに5,000クレジットあったワークスペースで、あるセッションが新しい順に次のように表示されたとします。

video   seedance-2-5      +310   (refund)
video   seedance-2-5      −310
image   eroq-image-one     +10   (refund)
image   eroq-image-one     −40
video   eroq-motion-one   −60

下から上へ読みます。5秒のMotion Oneのクリップは60クレジットで、無事に届きました。4枚の画像のバッチは40クレジットで、1テイクが空で返ってきて10クレジットが返金されたので、画像3枚で30クレジットです。5秒のSeedance 2.5のクリップは310クレジットが請求され、310クレジットが返金されました。届かなかったので、料金はゼロです。

差し引きの動きは90クレジットで、残高は4,910です。5行、納品物は3つ、無料の失敗が1つ。ここから2つのことがわかります。まず、日別グラフの合計は返金を差し引いた数字なので、表示されるのは実際に使った額です。次に、リクエスト数のカウンターが数えるのは正の金額の行、つまり請求だけです（返金はリクエストではありません）。そのため、失敗があった日は、リクエスト数と行数が一致しません。

誰が使ったかを調べる

ログは、使った額を人ごとには分けていません。それをするのは、ワークスペースのメンバータブだからです。各メンバーの行には、今月（暦月）に使ったクレジットが、返金を差し引き、ゼロを下限として表示されます。

この列は、メンバーごとの月間上限の判定にも使われます。返金を差し引くのは意図的です。レンダリングが失敗して自動で返金された外部スタッフは、割り当てを少しも消費していないからです。上限は毎月1日にリセットされ、管理者は誰のロールにも触れずに上限を引き上げられます。

キーごとの集計も、別の列ではなく同じ列で行われます。明細のすべての行には、呼び出しに使われたAPIキーが記録されます（ブラウザのセッションはキーではないので、スタジオからの呼び出しには記録されません）。そして、キーはちょうど1人のメンバーに属し、そのメンバーのロールを引き継ぎます。つまり、メンバーごとの使用額は、キーごとの使用額を持ち主ごとに合計したものです。きれいに分けたいなら、連携ごとに専用のメンバーシートを用意しましょう。各ロールでできることは、ワークスペースのロールと権限で解説しています。

APIから見える範囲はもっと狭い

GET /v1/accountは、残高と30日間のサマリーを返します。

{
  "object": "account",
  "credits": 4870,
  "usage_30d": { "requests": 213, "credits": 9614 }
}

多くの人が午後をつぶす落とし穴がひとつあります。このエンドポイントの範囲はキーを持つアカウントですが、ダッシュボードのログの範囲はワークスペースです。ひとりで使うワークスペースなら、両者は一致します。共有のワークスペースでは一致しません。creditsは全員が使っている共有の残高なのに、あなたのキーのusage_30dには、チームメイトが同じウォレットから使った分がまったく含まれていません。ワークスペースの合計はダッシュボードで、「このキーの持ち主が何をしたか」は/v1/accountで確認してください。

usage_30d.creditsも返金を差し引いた数字で、requestsは請求だけを数えます。グラフとまったく同じです。

予想外の行

「この行は何？」という質問のほとんどは、2つのパターンで説明がつきます。

生成の隣にあるstorageの行。store: trueを渡すと、出力がeroq Storeに保存されてCDNのURLが返され、10 MBごと（端数も10 MBとして計算）に2クレジットが追加で課金されます。これがモデルeroq-storeの2つ目の行です。10クレジットの画像が、ときどき12クレジットに見えるのはこのためです。レンダリングをライブラリに保存するのは無料で、行も一切書き込まれません。行が増えるのはStoreだけです。

1つの会話に複数のchatの行。チャットは生成1回ごとに課金されるので、RP+で12ターンのシーンなら、3クレジットの行が12行並びます。こうした使い方の料金についてはAI APIのクレジット課金で、チームのウォレットについてはチームでAIクレジットを管理する方法で詳しく解説しています。

リクエストログを開いて、直近のセッションを照合してみてください。どの行が返金かがわかれば、1分ほどで終わります。

よくある質問

レンダリングが終わる前に残高が減るのはなぜですか？

クレジットは、納品時ではなくジョブが受け付けられた時点で請求されるからです。放棄されたリクエストがタダで生成を手に入れるのを防ぐには、これしか方法がありません。レンダリングが失敗した、タイムアウトした、ブロックされた場合は、返金の行が自動でクレジットを戻します。どちらにしても、残高は本来あるべき数字に落ち着きます。

クレジットの列のマイナスの数字は何を意味しますか？

ワークスペースのウォレットに戻される返金です。そのため、表ではその行にタグが付き、プラス記号付きで表示されます。どの返金にも、取り消す対象の操作とモデルが記載されているので、その上にある請求と対応させられます。ブロックされたプロンプト、失敗したレンダリング、期限を過ぎたジョブは、いずれも返金の行を生みます。

ダッシュボードの合計がAPIキーの数字と違うのはなぜですか？

ダッシュボードのログはワークスペース全体を対象にし、GET /v1/accountはキーを所有するアカウントだけを対象にしているからです。共有のウォレットでは、チームメイトの使用分はあなたのアカウントに計上されないため、キーの30日間の数字はワークスペースの数字より小さくなります。creditsの残高は共有なので、こちらは常に一致します。

リクエストログはどこまでさかのぼれますか？

30日分で、50行ずつ読み込まれます。日別グラフも同じ期間が対象なので、もっと長い履歴が必要なら、消える前に必要な分をエクスポートしてください。ワークスペースのメンバータブにあるメンバーごとの月間使用額は、今月（暦月）で計算されるので、これはまた別の期間です。