生成AIコストの配賦方法3パターン｜キー・タグ・按分

生成AIコストを部署に配賦する方法は、キー・リソース単位、タグ・アカウント単位、按分の3パターンに整理できます。どれか1つを選ぶというより、プロバイダの経路ごとに使える方式が決まり、結果として社内で混在するのが普通です。

この記事では、3方式の仕組みと向き不向き、混在させるときの設計、按分基準の決め方を整理します。配賦の全体像は「生成AIコストの部署別配賦（チャージバック）完全ガイド」を、対応付けの作り方は「組織マッピングとは」を参照してください。

3パターンの全体像

パターン1: キー・リソース単位

APIキー（OpenAI・Claude）やデプロイメント（Azure OpenAI）を、1つの部署・利用者・プロジェクトに紐づける方式です。生成AIの配賦で最も基本的な形です。

仕組み

プロバイダの管理APIから、キー × モデル × 時間の利用量が取れます。キーが部署に紐づいていれば、その部署の利用量とトークン数 × 単価の概算費用がそのまま出ます。OpenAIとClaudeはキーの名前と所有者がプロバイダ側に登録されているため、対応付けの手がかりが最初からあります。

向いている状況

• 部署やチームごとにキーを発行している
• Azureのデプロイメントを用途・部署ごとに分けている
• 利用者個人の内訳まで見たい（OpenAI・Claudeのみ可能）

落とし穴

• 共用キーの扱い: 1本のキーを複数部署で使っていると、この方式では配賦できない。分割（部署ごとにキーを発行し直す）か、按分に回す
• 台帳の陳腐化: キーの発行・失効が台帳に反映されないと、未割当が増える。発行時に台帳へ登録する運用と、月次の棚卸しが必要
• 費用は概算: キー単位の実費は存在しないため、金額はトークン数 × 単価の概算になる。全社・プロジェクト単位の実費と区別して扱う

キーの命名規則（例: 部署略称-用途-環境）を決めておくと、後からの対応付けが楽になります。

パターン2: タグ・アカウント単位

AWS Bedrock・Google Vertex AIのように、利用量がモデル単位までしか取れない経路では、クラウド側のアカウント・プロジェクト・タグで部署を分ける方式を使います。

仕組み

BedrockならAWSアカウント（またはリージョン）、Vertex AIならGCPプロジェクトを部署ごとに用意します。実費はCost ExplorerやCloud Billingからアカウント・プロジェクト単位で取れるため、実費と部署が直接対応するのがこの方式の強みです。

向いている状況

• すでにクラウドのアカウント設計で部署やプロジェクトを分離している
• クラウド費用の配賦をFinOpsの枠組みで運用しており、生成AIもその延長で扱いたい

落とし穴

• 利用者個人までは追えない: モデル単位の集計から「誰が使ったか」は分からない。部署単位で満足できるかを最初に確認する
• アカウント設計の変更コスト: 1つのアカウントを全社で共用している場合、部署ごとに分けるにはクラウド側の作業が要る
• 実費の反映遅れ: Bedrockの実費は約1日遅れ、Vertex AIは請求エクスポートの設定が必要。当日の状況は利用量からの概算で見る

パターン3: 按分

共用のキーやリソース、社内共通の生成AI基盤（SIerが構築した社内GPTなど）を複数部署で使っている場合、費用を何らかの基準で分ける方式です。

按分基準の候補

按分は「配賦しないよりはまし」の方式であり、精度を求める方式ではありません。按分している費用がどれだけあるかを把握し、可能なら分割（キーやアカウントを分ける）してパターン1・2に移すのが長期的な方向です。

落とし穴

• 公平性の議論: 「うちはそんなに使っていない」という反発が最も出やすい方式。基準を文書化して開示し、変更手続きも決めておく
• 按分の根拠が見えない: 画面やレポートで「この費用は按分値」と分かるようにしないと、キー単位の数字と混ざって信頼を失う

経路別の推奨方式 早見表

按分の計算例

共用の検証用キーで、ある月の概算費用が10万円だったとします。利用量比で按分する場合、各部署が使ったトークン数の比率（例: 営業部 50%・開発1課 30%・経営企画 20%）で割ると、営業部5万円・開発1課3万円・経営企画2万円になります。

ここで注意すべきは、共用キー1本では「どの部署が何トークン使ったか」がプロバイダ側から取れないことです。利用量比で按分するには、部署ごとの利用量を別の手段（社内ツールのログなど）で持っている必要があります。それがなければ人数比か固定比率になり、精度は下がります。按分している費用の割合が大きいなら、キーの分割を優先した方が早道です。

方式ごとの月次作業

パターン3だけが「基準の元データ」という手作業を毎月抱えます。運用負荷の面でも、按分は縮小していく方式と位置づけます。

混在させるときの設計

現実の企業では、次のように方式が混在します。

混在すること自体は問題ありません。重要なのは、次の2点です。

1. どの費用がどの方式で配賦されたかを区別して見せる。キー単位の概算、アカウント単位の実費、按分値が同じ列に混ざっていると、経理と経営層への説明ができなくなる
2. 未割当を第4のカテゴリとして持つ。どの方式でも配賦できなかった費用は「未割当」として表示し、月次の棚卸しで減らす

共用キーを分割する手順

按分から抜け出すには、共用キーを部署ごとのキーに分割します。手順は次のとおりです。

1. 共用キーを使っているアプリケーションやツールを洗い出し、利用している部署を確認する
2. 部署ごとに新しいキーを発行し、命名規則（部署略称-用途-環境）に沿って台帳に登録する
3. アプリケーション側の設定を新しいキーに切り替える。切り替え期間中は新旧両方の利用が出るため、台帳で「移行中」と分かるようにする
4. 旧キーの利用量がゼロになったことを確認してから失効する

分割できないケース（SIer構築の社内GPTで設定変更に改修が要るなど）は、次の改修のタイミングまで按分で運用し、改修時に部署識別を組み込みます。

実費と概算の関係

3方式のどれを選んでも、部署別の金額の「出どころ」を意識する必要があります。

• パターン1（キー単位）の金額は概算（トークン数 × 単価）
• パターン2（アカウント単位）の金額は実費と対応しやすい
• パターン3（按分）の金額は、元になる費用が実費でも、按分後は推計値

全社・プロジェクト単位の実費と、部署別の合計を月次で突合し、差を説明できる状態を保ちます。ManageAIでは、Azure・AWS Bedrockの実測で概算と実費の差は1〜1.8%でしたが、差が急に広がったときは単価改定や二重計上の疑いがあり、異常検知のシグナルとして使えます。

方式を選ぶための判断フロー

1. その経路で、キー・デプロイメントが部署ごとに分かれているか → はい: パターン1
2. 分かれていないが、クラウドのアカウント・プロジェクトで部署を分けられるか → はい: パターン2
3. どちらも難しい共用リソースか → パターン3（按分）。ただし基準を文書化し、可能なら分割を計画する

まず全社の実費が見える状態を作り、次に部署別、最後に利用者別へと段階的に広げると、方式の選択も自然に決まっていきます。

よくある質問

Q. 社内GPTをSIerに構築してもらい、Azureのデプロイメントが1つしかありません。 デプロイメント1つでは部署別に分かれないため、パターン3（按分）になります。社内GPT側のログで部署別の利用回数が取れれば利用量比、取れなければ人数比です。次の改修でデプロイメントを部署ごとに分けるか、社内GPT側で部署を識別してログに残す設計を検討してください。

Q. 按分基準を変えたら過去との比較ができなくなりませんか？ なります。基準の変更は年度の切り替えなど区切りで行い、変更前後の数字を両方残します。変更の理由と日付を配賦ルールの文書に記録しておけば、監査でも説明できます。

Q. 3方式を1つの画面で見られますか？ 方式ごとに数字の性質（概算・実費・推計値）が違うため、区別して表示できるかがツール選定の確認点です。「未割当」を含めて4区分で見えていれば、経理と経営層への説明が成り立ちます。

まとめ

• 配賦方式はキー・リソース単位、タグ・アカウント単位、按分の3パターン。経路ごとに使える方式が決まる
• OpenAI・Claude・Azureはパターン1、Bedrock・Vertex AIはパターン2、共用リソースはパターン3が基本
• 混在してよいが、どの方式で配賦したかを区別し、未割当を第4のカテゴリとして持つ
• 部署別の金額は概算か推計値。全社・プロジェクトの実費と突合して差を説明できる状態を保つ

ManageAIは、APIキー・デプロイメント・モデルを組織マッピングで部署・利用者・プロジェクトに対応付け、実費と概算を区別して表示します。共用リソースの按分値は按分である旨を明示し、未割当の費用も隠しません。5プロバイダを横断して1つの画面で見られ、読み取り専用キーの登録だけで導入できます。現在、モニター企業を募集中です。

関連記事

• 生成AIコストの部署別配賦（チャージバック）完全ガイド｜FinOpsの考え方で設計する
• 組織マッピングとは｜APIキーと部署を紐づける設計の基本
• 中堅企業の生成AIコスト配賦｜専任なしで回す設計