生成AI利用状況の粒度はプロバイダで違う｜キー・デプロイ・モデル
生成AIの利用状況がどこまで細かく見えるかは、プロバイダによって違います。OpenAI・ClaudeはAPIキー、Azure OpenAIはデプロイメント、AWS Bedrock・Google Vertex AIはモデルの単位まで。粒度の違いが部署別・利用者別の把握にどう影響するか、違いを揃える「疑似キー」の考え方、粒度を上げるための設計を解説します。
生成AIの利用状況がどこまで細かく見えるか（粒度）は、プロバイダによって違います。OpenAI と Claude は APIキー × モデル × 時間まで見えるため、キーを利用者に割り当てれば個人別まで追えます。Azure OpenAI はデプロイメント × モデル、AWS Bedrock と Google Vertex AI はモデル（リージョン・ロケーションごと）までで、利用者個人の内訳は見えません。
この違いを知らずに「全社で利用者別の費用を出す」ことを目標にすると、一部のプロバイダで必ず行き詰まります。この記事では、プロバイダ別の粒度、粒度の違いを揃える考え方、粒度を上げるための設計を説明します。全体像は「生成AI APIの利用状況・費用データを取得する方法 完全ガイド」を参照してください。
プロバイダ別の粒度
| プロバイダ | 利用量の粒度 | 実費の粒度 | 利用者個人の内訳 |
|---|---|---|---|
| OpenAI | APIキー × モデル × 1時間 | プロジェクト × 日 | キーを利用者に割り当てれば可 |
| Claude（Anthropic） | APIキー × モデル × 1時間 | ワークスペース × 日 | キーを利用者に割り当てれば可 |
| Azure OpenAI | デプロイメント × モデル × 1時間 | リソース × 日 | 不可 |
| AWS Bedrock | モデル（リージョンごと）× 1時間 | リージョン × 日（アカウントごと） | 不可 |
| Google Vertex AI | モデル（ロケーションごと）× 1時間 | プロジェクト × 日 | 不可 |
ここでいう粒度は、各社が提供する管理API・メトリクスで標準的に取得できる単位です。アプリケーション側でログを取るなど、別の仕組みを足せば細かくできる場合もあります。
なぜ違うのか
違いは、各社の認証の仕組みから来ています。
| プロバイダ | 認証の単位 | 結果 |
|---|---|---|
| OpenAI・Claude | 発行した APIキーごと | キーごとに利用量が記録される |
| Azure OpenAI | リソースのキー、または Entra ID | リソースのキーは利用者ごとに分かれないため、デプロイメント単位になる |
| AWS Bedrock・Vertex AI | クラウドの権限（IAM・サービスアカウント） | 利用量のメトリクスはモデル単位で記録される |
粒度の違いが与える影響
| やりたいこと | OpenAI・Claude | Azure OpenAI | Bedrock・Vertex AI |
|---|---|---|---|
| 全社の費用を出す | ○ | ○ | ○ |
| 部署別の費用を出す | キーを部署に割り当てる | デプロイメント・リソースを部署で分ける | アカウント・プロジェクトを部署で分ける |
| 利用者別の費用を出す | キーを利用者に割り当てる | 標準では不可 | 標準では不可 |
| システム別の費用を出す | システムごとにキーを分ける | システムごとにデプロイメントを分ける | システムごとにアカウント・プロジェクトを分ける |
つまり、部署別の費用はどのプロバイダでも出せますが、そのための「分け方」がプロバイダごとに違います。利用者別の費用は、OpenAI と Claude でしか標準では出せません。
実費はどの社でも粗い
実費（請求と一致する金額）は、どの社でもプロジェクト・リソース・アカウントなどの単位までです。APIキー・利用者の単位の実費は存在しません。細かい単位の費用は、利用量（トークン数）に単価を掛けた概算になります。
粒度の違いを揃える——「疑似キー」の考え方
5つのプロバイダを1つの画面・1つの表で見るには、粒度の違いを揃える必要があります。考え方は、各社で最も細かく取れる単位を「キー」として扱うことです。
| プロバイダ | 「キー」として扱う単位 |
|---|---|
| OpenAI・Claude | APIキー（そのまま） |
| Azure OpenAI | リソース名 ＋ デプロイメント名 |
| AWS Bedrock | アカウント ＋ リージョン ＋ モデル ID |
| Google Vertex AI | プロジェクト ＋ ロケーション ＋ モデル |
APIキー以外の単位を疑似キーと呼ぶと、すべてのプロバイダの利用量を「キー × モデル × 時間」という同じ形の表にできます。あとは、実キーも疑似キーも同じように部署・プロジェクトに対応付ければ（組織マッピング）、部署別の集計がプロバイダをまたいでできるようになります。
疑似キーで揃えても、利用者個人の内訳が見えないという限界は残ります。表や画面では、疑似キーの行が「部署単位まで」の粒度であることを明示し、全プロバイダで個人別に見えているかのような見せ方は避けます。
粒度を上げるための設計
| 目的 | 設計 |
|---|---|
| 部署別に見たい | OpenAI・Claude は部署ごとにキーかプロジェクト（ワークスペース）を分ける。Azure はデプロイメント・リソースを、Bedrock・Vertex AI はアカウント・プロジェクトを部署ごとに分ける |
| システム別に見たい | システムごと・環境（本番・検証）ごとにキーや単位を分ける |
| 利用者別に見たい | OpenAI・Claude はキーを利用者ごとに発行する。他の3社はアプリケーション側で呼び出し元を記録する（ログの内容と保管に注意） |
| 部署別の実費まで見たい | 実費が取れる単位（プロジェクト・ワークスペース・リソース・アカウント）を部署に合わせる |
粒度は、後から上げるのが難しいことに注意します。キーやアカウントの分け方は、利用が広がる前に決めておくのが理想です。すでに共用が進んでいる場合は、新しい利用から分け方を揃え、共用分は按分のルールで扱います。
粒度の違いを説明するときのポイント
経営層や経理に部署別の費用を報告するときは、粒度の違いを次のように説明します。
- 部署別の費用は、どのプロバイダも概算である（合計は実費で確認している）
- Azure・Bedrock・Vertex AI の利用は、部署単位までで、個人別は見えない
- どの部署にも対応付けられていない費用は「未割当」として示している
よくある質問
Q. 利用者別に見られないプロバイダは使わないほうがよいですか？ いいえ。部署別に見られれば、費用の管理と予算の統制には十分なことが多いです。利用者別が必要な用途だけ、キー単位で見えるプロバイダを使う、あるいはアプリケーション側で記録する、という使い分けができます。
Q. 同じモデルを複数の経路で使っています。 経路ごとに粒度と単価が違うため、経路を区別して集計します。モデル名だけで合算すると、経路ごとの費用の違いが見えなくなります。
まとめ
- 利用量の粒度は、OpenAI・Claude が APIキー、Azure OpenAI がデプロイメント、Bedrock・Vertex AI がモデルまで
- 実費はどの社もプロジェクト・リソース・アカウント単位まで。細かい単位の費用は概算になる
- 各社で最も細かい単位を「疑似キー」として扱えば、5社を同じ形の表で集計できる
- 部署別に見るための分け方はプロバイダごとに違う。利用が広がる前に決めておく
ManageAIは、5プロバイダの利用量を APIキー・デプロイメント・モデルの粒度のまま取得し、キー以外の単位を疑似キーとして部署・利用者・プロジェクトに対応付けて、1つの画面で可視化します。粒度の限界は画面上で開示します。読み取り専用の認証情報の登録だけで始められます。モニター企業を募集中です。
関連記事
- 生成AI APIの利用状況・費用データを取得する方法 完全ガイド｜5プロバイダの管理API
- 主要5プロバイダの管理API一覧｜取得できる項目比較
- 5プロバイダの使用量を一元管理する方法｜管理API横断
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ