生成AIの利用が全社に広がると、経理・情報システム部門に月次のLLM請求書がまとめて届くようになります。金額は伸びるのに、どの部門・案件がどれだけ使ったかが見えず、予算管理と改善判断の両方が止まるのが現状の悩みです。
この記事では、LLMのコストを部門や案件に按分・請求する「配賦」と「チャージバック」の設計を扱います。ショーバックとチャージバックの違い、メタデータ設計、判断軸、実装項目、注意点を整理し、次に決めるべきことが分かる状態を目指します。

生成AIの利用が全社に広がると、経理・情報システム部門に月次のLLM請求書がまとめて届くようになります。金額は伸びるのに、どの部門・案件がどれだけ使ったかが見えず、予算管理と改善判断の両方が止まるのが現状の悩みです。
この記事では、LLMのコストを部門や案件に按分・請求する「配賦」と「チャージバック」の設計を扱います。ショーバックとチャージバックの違い、メタデータ設計、判断軸、実装項目、注意点を整理し、次に決めるべきことが分かる状態を目指します。


| 読者の課題 | 最初に見る指標 | 確認すること | 次の行動 |
|---|---|---|---|
| 月次LLM費用が誰の分か分からない | 部門別トークン消費量 | 全リクエストに部門・ユーザーIDを付与できているか | メタデータ設計を先に決める |
| 経理から予算超過の説明を求められる | 部門別月次コストと予算比 | 予算・閾値・アラートの持ち主が決まっているか | ショーバックから始める |
| 一部部門の使いすぎを止められない | 上位ユーザー・上位ワークロード | チャージバック合意と上限運用が可能か | 段階的にチャージバックへ移行する |
まずは「見せるだけのショーバック」で合意形成し、運用が回ってから「請求するチャージバック」に段階移行するのが実務での現実解です。
用語が近く混同されやすいので、先に整理します。
| 用語 | 意味 |
|---|---|
| ショーバック(Showback) | 各部門の利用量・費用を「見せる」だけの仕組み。請求はしない |
| チャージバック(Chargeback) | 各部門の利用量に応じて社内で「請求する」仕組み。予算から実際に引く |
| コスト配賦 | 全社のIT費用を部門別に按分する会計処理。基準は工数、席数、利用量などがある |
| メタデータ | LLMリクエストに付与する部門ID・案件ID・ユーザーIDなどのタグ |
| ワークスペース | LLMプロバイダー側で部門や案件を分離する管理単位 |
この記事では、LLMを対象にした「利用量ベースの配賦・チャージバック」を扱います。
※LLM関連サービスの料金、データ保持条件、提供機能は変更される場合があります。導入前に公式情報で最新条件を確認してください。
生成AIの全社展開が進むと、月次費用は数万円から数百万円規模に一気に伸びる可能性があります。金額そのものよりも、次の3つが同時に起きる点が問題です。

これは新しい問題ではなく、クラウド費用(AWS、Azure、GCP)で通ってきた道と同じです。クラウドで確立したFinOpsの考え方をLLMに移植することが、2026年後半の現実的な出発点です。
いきなり請求まで踏み込むと部門の抵抗で止まります。段階を分けて考えます。
| 方式 | 一言でいうと | 向くケース | 注意点 |
|---|---|---|---|
| ショーバック | 各部門の利用状況を可視化して見せるだけ | 導入初期、全社展開直後、合意形成中 | 見せるだけでは使いすぎが止まらない |
| チャージバック | 部門別に社内請求し、部門予算から実際に引く | 利用が定着し、予算プロセスと接続できる状態 | 単価設計と例外処理の合意が必要 |
| 比較軸 | 確認すること | 実務上の意味 |
|---|---|---|
| 合意形成 | 部門と経理が単価と請求方法に合意できるか | 未合意でチャージバックを始めると部門が離反する |
| メタデータ整備 | 全リクエストに部門・案件IDが付与できているか | タグが欠けたリクエストは配賦不能になる |
| 予算プロセス | 部門予算にAIコスト枠があるか | 予算がない部門にはショーバック止まりが現実的 |
| 単価の安定性 | モデル切替や割引で単価が動きやすいか | 単価変動が大きいと社内請求が説明困難になる |
| 例外対応 | 全社共通ワークロードや実験費用をどう扱うか | 全部を部門配賦しようとすると設計が破綻する |
配賦の仕組みは、大きく「メタデータ」「集計」「請求」の3層に分かれます。

metadata.user_id、OpenAIのuserパラメータとProject/Workspace、Azure OpenAIのAPIキー・リソース分離、AWS Bedrockのコスト配分タグなど、各社が用意する仕組みを使う配賦・チャージバックは万能ではありません。導入前に次の点を認識しておきます。
Blackford Technologiesでは、LLMコスト配賦を単なる会計処理ではなく、AI活用を止めずに費用の説明責任を持続させるための運用設計として扱います。

具体的な支援視点は次の通りです。
既存クラウドを活かしてAI基盤を段階導入する場合はDataRoid Cloud、社内データをAIが扱える形に整えたい場合はDataRoidが選択肢になります。
営業領域のLLM活用と成果への接続はSalesRoidで扱います。ただし、いずれのプロダクトも配賦単価や監査ログの要件は個別確認が必要です。
月次AIコストが数十万円を超え、複数部門で利用されているタイミングが現実的です。それ以前は、ショーバック(見せるだけ)で合意形成に集中したほうが導入摩擦を減らせます。
技術的には変更可能ですが、過去の集計と接続できないため、実質的にはやり直しになります。部門ID、案件ID、ユーザーIDの3つは、最初に会計コードと揃えて設計するのが安全です。
各社が用意しています。Anthropic Claude APIはmetadata.user_idパラメータ、OpenAIはuserパラメータとProject/Workspace分離、Azure OpenAIはリソース・APIキー分離、AWS Bedrockはコスト配分タグを利用できます。仕様は変更される可能性があるため、導入前に公式ドキュメントで確認してください。
全社利用が数万円規模ならショーバックだけで十分です。事業部門ごとに独立採算で、AI利用が月数十万円を超える場合は、簡易的なショーバックから始めて負担配分の透明性を確保することを推奨します。
透明性重視なら実費、予算管理のしやすさ重視なら社内標準単価が向きます。実費は月ごとの単価変動を部門が受けるため、予算プロセスと相性が悪い場合があります。多くの企業では、月次スナップショットで固定した社内単価が実務的です。
LLMコストの部門別配賦は、単なる会計処理ではなく、AI活用を止めずに費用の説明責任を持続させるための運用設計です。
まずは「見せるだけのショーバック」で全社の合意形成を進め、メタデータ、集計、請求の3層を順に整えてからチャージバックに移行するのが実務的な現実解です。ただし、単価変動、タグ欠損、萎縮効果には注意が必要です。
自社での配賦設計に迷う場合は、現在のAI利用状況、部門予算プロセス、既存クラウドのタグ設計を整理したうえで、専門家に相談することをお勧めします。
\AIコスト管理と配賦設計を相談できます/ Blackfordに相談する








