AIの原価が顧客別に出ない：金額より先に数える単位を決める
AIの原価を顧客別に出すには、上限の金額より先に、顧客・機能・モデルのどれで分けて数えるかを決めます。
この記事の要点
- 分ける単位を決めない上限では、全員の利用が一つの予算にまとまる
- 顧客・機能・モデルのどれで分けるかを、金額より先に決める
- 分け方は要求に付けるラベルで決まるので、単位を決めた日から付け始める
- 組み合わせの数には上限があるので、分け方は一度に一つ増やす
全体像図を準備中
目次
分ける単位を決めない上限では一つの予算にまとまる
A&Aの考え方
分ける単位とは、原価の合計をどの切り口で分けて数えるかを指します。
A&Aの考え方
この記事では、モデルへの呼び出しを要求と呼びます。
A&Aの考え方
会社の仕事をAI前提に組み直すと、モデルの利用料は自社がまとめて払い、顧客にはサービスとして渡す形になります。月末に請求が来ると、合計は一目で分かります。
A&Aの考え方
分からないのは内訳です。どの顧客のどの機能が、その合計を押し上げたのか。
仮想例
問い合わせへの下書き、議事録の要約、見積もりの草案を、同じ仕組みで出しているとします。どれも同じAPIキーで同じモデルを呼んでいれば、請求書にはまとめて一つの数字で載ります。
A&Aの考え方
この記事を書いているAutomate & Augment（A&A）は、会社の仕事の進め方をAI前提に作り替えることを請け負う会社です。A&Aはこれを、記録が足りない状態ではなく、集計の単位をまだ決めていない状態だと読みます。
出典に基づく事実
Cloudflareは、AIの呼び出しを中継するサービスを提供している会社です。費用の上限を置く機能について、文書を公開しています。その文書は、回数の上限とは数えている対象が違うと書いています。費用の上限は、モデルの価格に基づく実際の金額を要求ごとに追う、とあります。
A&Aの考え方
A&Aはこれを、こう読みます。分けないのは、何もしないことではありません。全員分の利用を一つの予算に入れる設定を選んだ、ということです。
A&Aの考え方
止めること自体はできます。合計が上限に達すれば、その先の要求は止まります。分からないのは、誰のために止まったのかです。
仮想例
たとえば、三社に同じ下書きサービスを出しているとします。上限に達して止まった時、原因が一社の試し打ちなのか、三社の平常の利用が重なったのかは、一つの予算のままでは分かりません。
分ける単位は金額より先に決める
A&Aの考え方
上限をいくらにするかより先に、その金額を何の単位で数えるかを決めます。
出典に基づく事実
Cloudflareの文書は、単位ごとに二つのやり方があると書いています。一つは、値ごとに別々の予算を持たせるやり方です。もう一つは、特定の値のときだけ規則を効かせるやり方です。はじめのやり方では、値ごとに独立した予算がつく、とあります。
A&Aの考え方
顧客を見分ける番号（識別子）を単位にして値ごとに分ければ、顧客ごとの予算になります。
A&Aの考え方
単位の候補は三つあります。顧客、機能、モデルです。A&Aは、まず一つだけ選ぶことを勧めます。
A&Aの考え方
顧客で分けると、粗利を押し下げている相手が分かります。来月に値上げの相談を持っていく先が決まります。
A&Aの考え方
機能で分けると、採算の合わない機能が分かります。その機能を有料の枠へ移すか、安いモデルに落とすかの判断になります。
A&Aの考え方
モデルで分けると、費用がどのモデルに寄っているかが分かります。置き換えの候補は出ますが、顧客別の内訳は出ません。
A&Aの考え方
どれを選ぶかは、次に打つ手で決まります。値上げの相手を探しているなら顧客、やめる機能を探しているなら機能です。
A&Aの考え方
もう一方のやり方は、特定の値のときだけ規則を効かせるものです。一社だけ利用が突出しているなら、その顧客の識別子を指定して、その相手にだけ上限を掛けられます。
仮想例
たとえば、問い合わせへの下書き、議事録の要約、見積もりの草案の三つを出しているとします。機能で分ければ、三つのうちどれが赤字なのかが翌月には分かります。
A&Aの考え方
迷う場合、A&Aは顧客を勧めます。値上げも、利用の制限も、相談の相手は顧客だからです。これは出典の記述ではなく、A&Aの判断です。
| 分ける単位 | 分かること | 次に打てる手 |
|---|---|---|
| 顧客 | どの相手が原価を押し上げているか | 値上げか、利用の制限を相談する |
| 機能 | どの機能の採算が合わないか | 有料の枠へ移すか、安いモデルに落とす |
| モデル | 費用がどのモデルに寄っているか | 置き換えを検討する |
分け方は要求に付けるラベルで決まる
A&Aの考え方
分けられるかどうかを決めるのは、集計の側ではなく、要求を送る側です。
A&Aの考え方
要求に添えるこの短い目印を、この記事ではラベルと呼びます。
出典に基づく事実
同じ文書は、ラベルの付け方を二通り挙げています。入口の認証と結びついている場合は、認証された利用者の識別子が自動で付く、とあります。そうでない場合は、自前の識別子を要求に渡す、とあります。
A&Aの考え方
A&Aはここから、分け方は遡れないと読みます。ラベルは要求を送るその瞬間に付くものなので、付けずに送った過去の要求を、後から顧客ごとに割り振ることはできません。
A&Aの考え方
この記事で引く二つの文書は、遡れるとも遡れないとも書いていません。ラベルの置き場所から導いた読みです。
A&Aの考え方
だから、単位を決めた日と、ラベルを付け始める日は同じ日になります。先にラベルを付け始めておけば、上限の金額は後から決め直せます。
仮想例
たとえば、顧客の識別子を要求に添え始めるとします。上限の規則をまだ作らなくても、翌月には顧客ごとの内訳が見える状態になります。
A&Aの考え方
ラベルの中身は、自社の顧客台帳にある識別子をそのまま使えば足ります。請求書と自社の記録を突き合わせる時に、同じ番号で引けるからです。
A&Aの考え方
ラベルを増やすこと自体にも費用があります。要求ごとに付ける項目が増えれば、実装と保守の対象が増え、取り違えたときに影響する範囲も広がります。これもA&Aの判断で、出典にある記述ではありません。
組み合わせの数には上限がある
A&Aの考え方
分ける細かさには、仕組みの側に上限があります。
出典に基づく事実
Stripeは、決済と課金の仕組みを提供している会社です。利用量をAPIで記録する方法について、文書を公開しています。その文書は、設定した単位の組み合わせを受け付ける数に上限があると書いています。
出典に基づく事実
同じ文書は、その数も挙げています。利用量の計器（メーター）一つにつき、1時間に受け取る組み合わせは最大10,000通りです。顧客ごとに見ると、これまでに送った組み合わせを合わせて最大100通りです。
出典に基づく事実
上限に達した後の扱いも書かれています。すでに数えられている組み合わせの処理は続きます。上限に達した後は、新しい組み合わせを含む送信が無効になり、専用のエラーコードが付いて報告に載る、とあります。
A&Aの考え方
記録されないのではありません。拒否されます。A&Aはこの違いを重く見ます。記録されないだけなら後から足せますが、拒否された分は、気づくまで報告の中にたまります。
仮想例
たとえば、顧客10社、機能3つ、モデル2つで分けるとします。組み合わせは最大60通りです。ここに日付や版を足すと、掛け算で増えます。これは仮の数字で、実際の構成によって変わります。
A&Aの考え方
A&Aが勧めるのは、分け方を一度に一つ増やすことです。増やす前に、今の構成で何通りになるかを数えます。
A&Aの考え方
二つの文書は、どちらも発行元自身の製品文書です。独立した検証でも、どの分け方が効くかを比べた試験でもありません。組み合わせの数値は、その課金の仕組みを使う場合の制約で、変わることがあります。
まとめ
A&Aの考え方
分ける単位を決めない上限では、全員の利用が一つの予算にまとまります。
A&Aの考え方
顧客・機能・モデルのどれで分けるかを、金額より先に決めます。
A&Aの考え方
分け方は要求に付けるラベルで決まるので、単位を決めた日から付け始めます。
A&Aの考え方
組み合わせの数には上限があるので、分け方は一度に一つ増やします。
分ける単位を決めない上限では、全員の利用が一つの予算にまとまります。顧客・機能・モデルのどれで分けるかを、金額より先に決めます。分け方は要求に付けるラベルで決まるので、単位を決めた日から付け始めます。組み合わせの数には上限があるので、分け方は一度に一つ増やします。
よくある質問
顧客が3社しかなくても、分けて数える必要がありますか。
社数では決まりません。決め手は、来月に値上げや利用の制限を相談する相手を名指しできるかです。名指しできるなら、月末の合計と作業の記憶で足ります。できないなら、ラベルだけ先に付け始めます。
上限に達する前に、超えそうなことは分かりますか。
費用の上限の文書は、集計が結果整合だと書いています。要求がまとまって届くと、止める処理が追いつくまでの間は一時的に上限を超えることがある、とあります。上限は厳密な保証ではない前提で置きます。
分ける単位を後から変えたくなったら、どうしますか。
新しい単位のラベルを付け始めた日から数え直します。過去の分は遡れないので、切り替えの前後を比べる間は、古い単位での集計も残します。これはA&Aの進め方で、出典の記述ではありません。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Spend limits
Cloudflare · 2026-09-30 (last updated, stated on the page)
確認日 2026-10-26 - Record usage for billing with the API
Stripe · undated documentation page; no visible publication date
確認日 2026-10-26