顧客別のAI原価を説明できますか。直接費・共通費・未割当と全体上限をつなぐ台帳設計

編集部の実務提案

全体の請求額と、顧客別の原価は別の問い

AIサービスの請求額が先月より増えたとき、どの顧客の何の処理が増えたかを説明できるだろうか。全体の利用料金が分かっても、顧客ごとの原価、共有基盤の費用、まだ割り当てられていない分が分かるとは限らない。契約の請求額だけを見て採算を判断すると、裏側で増えた再試行や共通処理の費用が見えなくなる。

本稿では顧客を識別する業務上の単位をtenantと呼ぶ。組織、契約、プロジェクトのどれを一つとするかは、サービスの実際の契約と権限に合わせて決める。同じ会社の複数部署を一つへまとめるか分けるかも方針である。利用者が入力した顧客名だけを、そのまま費用の帰属先にしない。

ここで設計するのは、顧客別の原価の説明と、利用を受け付ける枠の接続である。既存のバッチ総額の制御を、そのまま顧客ごとに複製して終わる話ではない。直接費、共通費、未割当を分け、見積から請求照合までの状態を追う。金額の例と配賦ルールは編集部の架空提案で、実際の料金や会計基準を示すものではない。

最初に「何を誰へ説明する数字か」を決めたい。開発チームが障害を調べる内訳、事業責任者が採算を見る原価、顧客へ送る請求明細は、同じ表示とは限らない。元の利用事実を共有しながらも、計算規則、確定時点、閲覧範囲を分ける。数字の一元化と、意味の統一を混同しないことが出発点になる。

編集部の実務提案

公式機能でできる帰属と、時間差を確認する

AWSの資料は、課金タグがBilling画面へ現れるまで最大24時間かかり得ること、タグへ機密情報を含めないことを説明している[1]。タグが付けられるから、すべての利用を即時に顧客別へ確定できると考えない。反映の時間差と、対象となる費用の範囲を確認する。

Bedrockの現行資料では、モデル別のApplication inference profileによるコスト帰属が説明され、InvokeModelやConverseと、AIPの対象外であるResponsesやChat Completionsが区別されている[2]。同じ提供元でも、使うAPIで適用条件が違う。導入時には自分の呼出方式に対応する原典を確認したい。

AWS Budgetsも、費用の発生から通知までに遅延があり、通知前に閾値を超える可能性を説明している[3]。そのため、後追いの費用監視を、各リクエストの受付時に必ず止める仕組みと同じだと扱わない。どの時点の情報で判断しているかを区別する。

自社の台帳は、こうした外部機能の範囲を踏まえて設計する。提供元の費用を再現したいのか、顧客へ割り当てる業務原価を作りたいのか、受付のための見込み額を持ちたいのかを先に決める。機能名だけを選んでから用途を広げると、異なる意味の数値を同じ費用欄へ入れやすくなる。

編集部の実務提案

手順1：顧客識別を、正規の利用権限へ結びつける

利用の入口では、認証された利用者がどのtenantで何を実行できるかを確認し、その確定した識別子を処理へ渡す。画面の表示名や、リクエストの自由入力欄を信頼して帰属先を決めない。利用者が別顧客の識別子を送っても、その顧客へ費用や記録が移らないことを確認する。

tenantの識別子は、顧客名を変更しても同じ契約を追える値にする考え方がある。名称、請求先、内部の識別子を別の項目として持てば、改称や担当者の変更で過去の利用が別顧客へ見えにくい。統合や契約分割がある場合は、いつからどの帰属へ変えるかを履歴として残す。

外部サービスへ渡すタグやメタデータには、必要最小限の識別情報を使う。顧客名、メール、入力文章をそのまま課金タグへ入れる必要はない。内部で対応を管理できる不透明な識別子を使い、誰が対応表を見られるかも決める。原価を追えることと、個人情報を広く外へ送ることを結びつけない。

バックグラウンド処理へ渡した後も、元のtenantと処理種別を失わない。キュー、AI呼出、保存、再試行をまたいで同じ論理的な利用を追えるようにする。途中で識別できなくなった利用を、便宜的に直前の顧客へ付けない。未割当として見つけられる方が、誤った確定値より訂正しやすい。

編集部の実務提案

手順2：見積、予約、計測、請求を別状態にする

受付前の見積は、これから使うかもしれない費用である。予約は、受付のために利用枠を押さえた状態である。計測は、処理後に分かった使用量や計算上の費用である。請求は、提供元の請求情報で確認した額である。この四つを同じ確定原価として足すと、一回の仕事を複数回数えることになる。

台帳には、元の利用識別子と各状態への遷移を残す。見積が実績へ置き換わった場合、見積の履歴を消す必要はないが、現在の合計へ二重に入れない。予約枠を解放した時刻も、実際の費用がゼロになった意味ではない。受付制御の枠と、原価の集計は役割が違う。

計測値には、使用量、単位、採用した単価の版、通貨、計算した時点を持つ。入力と出力、キャッシュ等の区分は、使うサービスの実際の仕様に合わせる。すべてのサービスが同じ計測項目や割引条件を持つとは考えない。未確認の単価を最新として使わず、見込みである範囲を表示する。

顧客向け請求額は、内部原価と別の契約上の計算になり得る。定額、従量、最低料金などを採る場合も、その条件を自社の契約に従って扱う。この記事から請求方式を決めるものではない。原価を更新したら顧客請求も自動で同額変わる、という隠れた結びつきを作らず、両者の関係を明示する。

計測した使用量が分かっても、単価が未確認なら費用の確定値とは呼ばない。どの部分が観測でき、どこが見込みかを別の状態で残す。提供元の請求が届く前の参考値を使う場合も、その表示を保存した資料へ引き継ぐ。画面だけに暫定と書き、出力した表では確定に見える状態を避けたい。

編集部の実務提案

手順3：直接費、共通費、未割当を分ける

直接費は、特定のtenantの利用へ根拠を持って結びつけられる費用と定義する。共通費は、複数の利用へまたがり、方針を決めて割り当てる費用である。未割当は、まだ帰属を確定できない費用である。この区分を明示すれば、顧客別合計が全体請求へ届かない理由を、隠れた誤差として片付けずに説明できる。

架空の一万円の原価に、Aへ直接四千円、Bへ直接二千円、共通三千円、未割当千円があるとする。ここで顧客別に見えている直接費は六千円であり、残り四千円が消えたわけではない。共通費を配賦する前と後で、何の合計を表示しているかを名前に含める。直接費だけの数字を総原価と呼ばない。

未割当を共有費へ自動的に移せば、見た目の合計は揃うかもしれないが、識別の欠落が見えなくなる。共有基盤の正当な費用と、情報不足の費用を区別する。原因が分かったときに正しい顧客へ移せるよう、元の記録と訂正履歴を保つ。帰属が分からないことを、費用が発生していないことへ変えない。

VERSAROCへ費用管理の実装を相談する場合は、どの費用がどこで識別でき、どこから未割当になるかを図にするとよい。顧客別画面だけを作るのでなく、キュー、外部AI、保存、請求レポートの間で対応が切れる箇所を整理する。元の利用台帳から説明できる範囲を、成果物の確認条件へ含めたい。

編集部の実務提案

手順4：共通費は、配賦方針の版を持つ

共通費を割り当てる方法には、利用量、処理回数、契約上の負担など、業務で選ぶ軸がある。どれが常に公平かを技術だけで決めない。何のための原価なのか、どの費用をどの根拠で分けるかを事業の責任者と合意する。費用を説明するための配賦と、顧客へ請求するルールを同じものと決めつけない。

先の架空の共通三千円を、AとBの比率二対一で配賦すると、A二千円、B千円になる。直接費と合わせた配賦後原価はA六千円、B三千円、未割当千円で、全体は一万円のままだ。元の共通三千円をさらに足せば二重計上になる。配賦元と配賦先の関係を残し、どちらの表示かを明確にする。

比率の計算期間や対象も方針へ含める。一日の利用比率で月の共通費を分けるのか、月の実績で分けるのかでは結果が変わる。停止した顧客や新規契約をどう扱うか、少数の利用しかない期間をどう読むかも決める。都合のよい比率を後から選ぶ運用にせず、変更時には理由と適用時点を残す。

共有キャッシュや共通の前処理は、サービスの実際の計測範囲を確認して扱う。再利用されたから費用は必ずゼロ、最初に使った顧客だけへ全額を付けるべき、という一般則を作らない。観測できる費用と、事業上の配賦判断を分ける。計測できない部分があるなら、その範囲を注記し、確定したような細かな数字を作らない。

端数の丸めも配賦方針へ入れる。各顧客へ分けた額を丸めると、元の共通費と小さな差が出る場合がある。その残りを誰へ付けるか、別の調整額として残すかを決め、毎回同じ規則を使う。見た目を揃えるために一顧客へ説明なく差額を寄せず、合計と根拠が追える方法を選ぶ。

編集部の実務提案

手順5：顧客の枠と全体の枠を両方確認する

顧客別の上限があるだけでは、全体の費用は守れない。架空例でAの枠80、Bの枠70を用意し、全体の枠が100なら、両者が各自の範囲で使っても全体へ150の要求が来る可能性がある。単位は説明用の架空枠であり、実際の料金ではない。顧客側とサービス全体の条件を、同じ受付判断で確認する必要がある。

並列処理では、各処理が残額を読んでから別々に使うだけだと、同時に同じ余裕を見てしまう。受付時に必要な枠を確保し、確保できた仕事だけを進める設計を検討する。詳しい予約の実装は既存の予算管理の記事に譲るが、ここでは予約をtenantへ帰属させ、全体との対応を残すことが重要だ。

費用の後追いレポートと、受付の見込み額は更新時点が違う。請求情報へまだ反映されていない処理も、予約枠として残る場合がある。画面では、使ったと確認できた額と、これから使う可能性として押さえている枠を分ける。後追いのアラートが来ていないことを、今すぐ受け付けてよい根拠へ変えない。

上限に達したときの行動も、顧客ごとに勝手に決めない。保留、優先順位、利用者への案内、管理者が変更できる範囲を事業側と合意する。上限を上げた操作は、顧客へ費用を請求してよい承認とは別である。技術上の受付と、契約上の課金判断を区別した運用へつなげる。

編集部の実務提案

手順6：結果不明の呼出を、費用ゼロで閉じない

外部AIへ依頼を送り、応答を受け取れなかった場合、処理が行われなかったとは限らない。タイムアウトや通信切断を、そのまま利用ゼロへ変えない。元の呼出識別子、試行、提供元で確認できる情報を残し、結果不明として照合する。再試行が必要でも、同じ依頼の別試行として追う。

一つの顧客の依頼に複数の試行がある場合、顧客が受け取った結果は一つでも、内部原価は複数回分になり得る。実際に何が計測されたかを確認し、成功した最終試行だけで原価を計算しない。失敗理由や再試行の費用を把握できれば、改善すべき運用と通常の利用増を分けられる。

予約枠をいつ解放するかも、単純な成功・失敗だけでは決めにくい。結果が不明な呼出をすぐ解放すると、実際には費用が発生している間に新しい受付を増やす可能性がある。一方、永久に押さえたままでは利用できない。確認する期限、確認先、解放や訂正の権限を運用条件として定める。

費用照合で後から実績が分かったときは、元の不明状態を消して最初から確定していたようにしない。照合日、確認できた情報、訂正額を残す。顧客へ見せる情報の細かさは別に選べるが、内部ではなぜ数字が変わったかを追える必要がある。結果不明は、費用台帳にも明示したい一つの状態である。

編集部の実務提案

手順7：請求と照合するとき、同じ範囲へそろえる

利用台帳と提供元の請求を比べる前に、期間、通貨、税、返金、割引、対象サービスの範囲をそろえる。内部の税抜見込みと、請求の支払総額が違うことを、すぐ計測漏れと呼ばない。どの範囲を比較しているかを表に書き、差分の説明に必要な項目を分ける。通貨換算を行う場合は、採用した基準と版も残す。

請求の確定前に顧客別の原価を出すなら、暫定であることを示す。確定した後に差額が分かれば、どの期間のどの費用へ訂正したかを残す。後から届いた費用を、今月の最新顧客へ便宜的に寄せない。元の利用期間と、訂正を処理した期間を別に追えると、月次の比較が読みやすくなる。

照合の単位は、すべてを一明細へ無理に合わせる必要はない。提供元が集約した形式しか出さない場合は、その粒度で比較できる範囲を定義する。細かい顧客別の帰属は内部の利用記録から説明し、外部で直接一致を確認できた部分と、方針で割り当てた部分を分ける。完全一致を装うために差額を消さない。

一致した合計にも注意が必要だ。Aへ多く、Bへ少なく付けて合計だけが合う場合がある。全体の一致と、顧客別の帰属の確認を別の試験にする。合計の計算が正しいことだけでは、顧客ごとの説明は完成しない。元の利用識別子から、採用した費用、配賦、表示まで辿れることを確認する。

請求レポートを取り込む処理にも、取込元、対象期間、版を残す。同じレポートを二度取り込んで費用が増えないことと、訂正版を受け取ったとき差分を反映できることを別に確認する。重複を止める仕組みが、正当な訂正まで止めないよう、同一ファイルの再送と新しい版を区別する。

編集部の実務提案

架空ケースA：タグがない分を、ゼロと表示した画面

A社の利用が課金画面に見えず、サービス担当者は今月の原価をゼロと表示したとする。しかし内部の実行台帳には処理があり、提供元の反映待ちか、識別の欠落かをまだ確認していない。ここでゼロと確定表示すると、利用がなかった状態と、まだ確認できない状態が同じになる。

最初に、内部の利用事実と外部の費用情報を別々に確認する。処理があったと分かるなら、その件数や見込みを未確定として残す。課金タグの反映に時間がかかるという公式の条件も考慮するが[1]、遅延だと決めつけて識別不備の調査を省かない。何をどこまで確認したかを台帳へ残す。

未割当が解消したときは、A社へ付いた根拠と時点を記録し、過去の暫定表示から何が変わったかを説明する。以前ゼロと表示してしまったなら、その誤解を直す対応も必要になる。データが増えたことと、既にあった利用へ帰属が付いたことは違う。画面の変更理由を区別すると、利用者への説明が具体的になる。

このケースの受入条件は、表示が最後に合えばよいだけではない。未確認の間にゼロと断定しないこと、帰属が判明した後に二重計上しないこと、訂正の履歴を残すことを見る。反映前、反映後、識別不能の三つのデータ例を用意すると、単純な正常ケースより必要な分岐が明確になる。

編集部の実務提案

架空ケースB：共通費の配賦で、顧客順位が変わる

直接費だけを見るとAが高く、Bが低いサービスが、共通費を配賦すると別の見え方になることがある。共通の前処理を頻繁に使う顧客と、個別の重い処理を使う顧客では、どの軸を採るかで負担が変わる。順位が変わったことを、突然の利用増と読み違えない。方針の変更と実際の利用の変更を分ける。

配賦方針を変える場合は、同じ期間のデータで旧方針と新方針を比較する。何を公平と考えたか、誰が承認したか、どの期間から適用するかを残す。過去のすべての原価を新方針へ黙って置き換えるのでなく、比較した版を保持する。顧客の契約上の請求に影響するかは、別の確認事項として扱う。

小さな顧客の最低限の共通負担をどうするかも、技術だけでは決めにくい。事業の価格設計と、内部で見たい原価の目的を合わせて考える。細かな比率を計算できることと、そのルールが妥当であることは別である。実装チームは方針を記録し再現できるようにし、判断の責任者が内容を説明できる状態を作る。

報告画面では、配賦前の直接費、配賦額、未割当を分けて見られると理由を追いやすい。単一の原価だけを表示して、月ごとの見え方の変化を利用者の推測へ任せない。詳細を常に全員へ公開する必要はないが、適切な担当者が元の計算と方針へ戻れる導線を用意する。

編集部の実務提案

架空ケースC：モデル変更後に、過去の単価が消えた

C社向けの処理でモデルやAPIを変更し、単価表の現在値だけを更新したとする。過去の利用量へその現在値を掛け直す画面では、同じ実行の原価が後から変わって見える。新しい条件で再計算した参考値と、当時の条件で記録した原価が混ざっている。どの問いに答える数字かを分ける必要がある。

台帳では、利用したモデルやAPIの識別と、採用した単価の版を残す。細かな公開価格を記事へ固定するのでなく、運用時に確認した資料と適用日を管理する。提供元の請求と内部計算が違う場合は、その差を説明できるようにする。単価表を更新できる担当者と、過去の確定値を訂正する担当者の権限も区別したい。

モデル変更を試す比較では、同じ評価課題、同じ期間の利用例など、比較できる条件を選ぶ。費用だけが低くても、必要な品質や再試行が変われば、顧客ごとの運用原価が同じ割合で下がるとは限らない。この記事は特定モデルの優劣や削減率を保証しない。計測した結果と見込みを分けて判断する。

過去を新単価で試算する機能は有用になり得るが、参考試算という表示と版を持つ。請求照合の確定額をその数字で書き換えない。結果を共有するときは、実績、再計算、将来見込みのどれかをタイトルへ含める。数字が正しく計算されていても、ラベルが違えば業務の判断を誤らせる。

編集部の実務提案

顧客向け画面と、内部の調査権限を分ける

顧客向け画面へ内部のすべての利用記録を出す必要はない。契約上の請求や利用枠の説明と、原価調査で必要な詳細は異なる。どの情報を本人へ見せるか、どの担当者が全体を見られるかを権限として決める。画面で隠しただけで、取得APIが他の顧客の明細を返していないかも確認する。

tenantのフィルタは、利用者が自由に選べる検索条件だけにしない。正規の権限から見てよい範囲を決め、その範囲内で検索させる。エクスポートやダウンロードも同じ条件で確認する。一覧画面は正しくても、詳細やCSVで別顧客が見えるなら、原価台帳としての境界が守られていない。

内部の運用者には、全額を見る権限と、帰属を訂正する権限を分ける考え方がある。調査のために閲覧できることと、過去の配賦を変更できることは別である。訂正では理由と変更前後を残し、必要な承認へつなげる。機密情報をログへ広く複製する代わりに、必要な識別子で元の記録へ辿る設計を考える。

報告を共有する際は、対象期間、方針の版、確定状態、閲覧範囲を含める。古い出力を後で見た担当者が、最新と誤認しないようにする。再生成した資料と以前の資料の関係も残す。原価の説明は計算だけでなく、誰がどの前提の数字を見ているかという情報管理を含んでいる。

共有リンクを使う場合は、リンク先で最新の閲覧権限を確認する。古い資料へアクセスできた履歴だけを、現在も別顧客の明細を読める許可として使わない。費用の訂正や担当変更の後も、誰がどの範囲を見られるかを確認する。原価の履歴とアクセスの履歴は関連するが、同じ判断ではない。

編集部の実務提案

受入試験は、合計の保存と帰属を両方見る

受入試験では、直接費、共通費、未割当を含む少数の架空データから始める。配賦前後で全体の合計が保存され、元の費用を二重に足していないかを見る。先の一万円の例を使えば、A六千円、B三千円、未割当千円という結果と、その根拠を一緒に確認できる。合計だけでなく各顧客への対応も検証する。

次に、未割当が後で解消する、請求額が訂正される、同じ利用の再配送が来る、結果不明の呼出が後から判明する、といった状態を加える。一度の正常計測で終わらせず、数字が後から変わる条件を扱う。変更履歴が残り、同じ費用を新規として増やさないことを確かめたい。

全体の受付枠については、顧客ごとの条件を満たす同時要求が来た場合を試す。顧客別には余裕があっても、全体には余裕がないという例を用意する。逆に、一顧客の枠が埋まったことだけで他の顧客を不要に止めないかも見る。どこで判断し、誰へ何を返すかを期待結果に含める。

表示と権限も受入条件へ入れる。暫定を確定と見せない、別顧客の明細を返さない、単価改版で過去の原価を黙って変えないことを確認する。本番の秘密や個人情報を試験へ持ち込む必要はない。架空データで意味を確かめ、必要な実データ照合は許可された範囲で別に行う。

編集部の実務提案

運用へ渡すのは、数字の更新ボタンだけではない

運用担当へは、利用の識別、各状態の意味、配賦方針、請求の確認時点、訂正の手順を渡す。誰が未割当を調べ、誰が単価や方針を更新し、誰が請求との差分を確定するかを明示する。画面に更新ボタンがあることだけでは、数字を説明できる運用にはならない。

未割当や結果不明が残る場合の期限と連絡先も決める。すべてを即日解消できると保証するのでなく、現在何が未確定で、いつ再確認するかを見せる。古い未確認が新しい集計の下へ隠れない表示が必要だ。合計が合った月だけを見るのでなく、未解決の項目へ戻れる導線を持つ。

VERSAROCへの相談では、既存の表計算、提供元のレポート、処理ログのどこで対応が切れるかを共有すると話を進めやすい。顧客別ダッシュボード、受付制御、請求照合を一度に大きく作る前に、確認したい原価の意味と境界を決める。段階ごとに実装と受入条件を置き、既存の記録を保持しながら進める。

導入の成果は、グラフの見た目だけでなく、差額の理由、帰属の訂正、枠の判断を担当者が追えることにある。削減率や採算の改善を未確認のまま約束しない。まず、どの顧客の何の費用を、どの方針と時点で見ているかを説明できる状態を目指す。そこから改善すべき利用や運用の候補が見つけやすくなる。

編集部の実務提案

次の一歩は、一つの利用を請求まで追うこと

最初の作業は、すべての費用へ精密な配賦率を決めることではない。一つの顧客の一つの依頼を選び、受付、外部呼出、使用量、費用計算、配賦、請求照合へ辿る。途中で識別できなくなる箇所や、時点が変わる箇所が見つかれば、そこが実装の優先課題になる。分からない部分を平均値で埋めて見えなくしない。

その次に、共通費と未割当を加え、全体の合計がどう保存されるかを見る。顧客別へ見せた数字が全体と一致していても、帰属の誤りがないかを別に確認する。受付の上限は、提供元の後追い通知と役割を分けて設計する。原価の説明と使いすぎを防ぐ制御を、同じ台帳から追える状態へ近づける。

外部の課金機能は、その対象と反映の時間差を理解して使う。すべてのAPIが同じタグを受け、すべての費用が即時に確定するとは考えない。事実として確認できた仕様と、自社が決める配賦や表示の方針を分けて残す。将来の変更時にも、この境界があれば見直すべき箇所を説明しやすい。