APIキーごとの費用を把握する｜プロバイダ別に見える粒度
生成AIのAPIキーごとの費用をどこまで把握できるかを、OpenAI・Azure OpenAI・Claude・AWS Bedrock・Google Vertex AIの5プロバイダ別に解説します。利用量と実費で見える粒度の違い、キー別の費用が概算になる理由、部署別に費用を紐づけるためのキーの持ち方までをまとめました。
API キーごとの費用を把握できるかどうかは、プロバイダによって違います。OpenAI と Claude（Anthropic）は API キーごとの利用量が取れるため、キーを部署や利用者に紐づければ、キー別・個人別の費用が出せます。Azure OpenAI はデプロイメント、AWS Bedrock と Google Vertex AI はモデルの単位までしか利用量が分かれないため、「キー」の代わりにその単位で費用を紐づけます。
もう 1 つの注意点は、キー別の費用は多くの場合「概算」になることです。プロバイダが請求の根拠として出す実費は、プロジェクトやリソースなど、キーより粗い単位でしか取れないためです。この記事では、プロバイダ別に見える粒度と、概算と実費の使い分け、部署別に費用を出すためのキーの持ち方を説明します。
「利用量」と「実費」で粒度が違う
API キーごとの費用を考えるときは、2 種類のデータを分けて考えます。
| データ | 中身 | 粒度 |
|---|---|---|
| 利用量 | トークン数（入力・出力）、モデル名、時刻など | 細かい（キーやデプロイメント × モデル × 1 時間など） |
| 実費 | プロバイダの請求系のデータに基づく金額 | 粗い（プロジェクト・リソース・アカウント × 日など） |
キーごとの費用は、キーごとの利用量（トークン数）にモデルごとの単価を掛けて計算します。これが「概算」です。実費は請求の根拠になる金額ですが、キー単位には分かれていません。
つまり、「キー別の費用」は、細かい粒度の利用量から計算した概算で出し、合計は実費で確かめる、という二段構えになります。
プロバイダ別に見える粒度
| プロバイダ | 利用量の単位 | 実費の単位 | キー別・個人別の費用 |
|---|---|---|---|
| OpenAI | API キー × モデル | プロジェクト | キーを利用者に割り当てれば出せる（概算） |
| Claude（Anthropic） | API キー × モデル | ワークスペース | 同上（概算） |
| Azure OpenAI | デプロイメント × モデル | リソース | 利用者個人は不可。デプロイメント単位で部署に紐づける |
| AWS Bedrock | モデル（リージョンごと） | リージョン（アカウントごと） | 利用者個人は不可。アカウントやモデル単位で紐づける |
| Google Vertex AI | モデル（ロケーションごと） | プロジェクト | 利用者個人は不可。プロジェクトやモデル単位で紐づける |
OpenAI と Claude
利用量が API キーごとに取れるため、キーの持ち方次第で細かく見られます。1 人 1 本のキーなら個人別、チーム 1 本ならチーム別の費用が出ます。実費はプロジェクト（Claude はワークスペース）の単位なので、プロジェクトを部署ごとに分けておくと、部署別の実費まで取れます。
Azure OpenAI
Azure OpenAI のキーはリソースに付くもので、利用者ごとに分かれていません。そのため、デプロイメント（リソースの中に作るモデルの配置）を「キーの代わり」として扱います。部署ごとにデプロイメントやリソースを分けておけば、部署別の費用が出せます。実費はリソースの単位で取れます。
AWS Bedrock と Google Vertex AI
利用量が見えるのは、リージョン（ロケーション）とモデルの組み合わせまでです。誰がそのモデルを呼んだかは、利用量のデータには出てきません。部署別に見たい場合は、AWS アカウントや Google Cloud のプロジェクトを部署ごとに分けるのが最も確実な方法です。
キー別の費用が「概算」になる理由
キー別の費用を計算するには、トークン数にモデルごとの単価を掛けます。このとき、実際の請求と差が出る要因があります。
- 単価の改定: プロバイダが単価を変えると、計算に使う単価表も追随させる必要がある
- 割引やキャッシュ: キャッシュされた入力の割引など、単価表だけでは表しきれない要素がある
- リージョンや契約による単価の違い: 同じモデルでも、使う経路や契約で単価が変わることがある
- 為替: 円で報告する場合、換算レートの取り方で差が出る
このため、キー別の費用を報告するときは「概算」と明記し、合計は実費と突き合わせるのが原則です。概算の合計と実費が大きくずれていれば、単価表の更新漏れや、把握していない利用がある可能性を疑います。
部署別に費用を紐づけるためのキーの持ち方
キー別の費用を部署別の費用にするには、キーと部署の対応付け（組織マッピング）が必要です。後から対応付けやすいように、キーの持ち方を最初に決めておきます。
| 原則 | 理由 |
|---|---|
| キーを部署をまたいで共用しない | 共用キーの費用は、按分しないと部署に分けられない |
| システム用のキーはシステムごとに分ける | 用途別の費用が出せる。停止時の影響範囲も絞れる |
| 本番と検証でキーを分ける | 検証の費用が本番に混ざらない |
| OpenAI・Claude はプロジェクト（ワークスペース）を部署に合わせる | 部署別の実費まで取れる |
| Azure・Bedrock・Vertex AI はリソース・アカウント・プロジェクトを部署に合わせる | 利用者単位が見えない経路でも部署別に分けられる |
すでに共用キーがある場合は、分割するまでの間は代表部署に付けておき、分割の予定を台帳に書いておくのが現実的です。共用キーの按分は、配賦ルールの 1 つとして決めることもできます。
キー別の費用で分かること
キー別の費用が見えると、次のことが判断できるようになります。
- どのシステム・誰の利用が大きいか: 費用の大きい順に並べるだけで、最適化の優先度が決まる
- 使われていないキー: 費用がゼロのキーは、棚卸しで失効の候補になる
- 急に費用が増えたキー: 漏えいや設定ミスの早期発見につながる
- 部署別の費用: キーと部署の対応があれば、部署ごとに集計して報告できる
キーの管理（台帳・棚卸し）と費用の管理は、別々に行うと二度手間になります。キーごとの費用を軸に、棚卸しと費用確認を 1 つの場で行うと、両方が回りやすくなります。
よくある質問
Q. 概算と実費はどのくらいずれるものですか？ 単価表が最新で、把握していない利用がなければ、差は小さく収まるのが普通です。差が大きい月は、単価の改定、キャッシュや割引の扱い、リージョンによる単価の違いのどれかを疑います。概算と実費のずれそのものが、見落としに気づく手がかりになります。
Q. 経理にはどちらの数字を報告すればよいですか？ 請求額の説明には実費を使います。部署別やキー別の内訳は概算で示し、「内訳は概算、合計は実費」と明記します。内訳の合計と請求額が一致しないことを先に伝えておくと、問い合わせが減ります。
Q. 共用キーの費用を部署に分けるには？ 利用者数や業務量の比率で按分するルールを決めるか、キーを部署ごとに分割します。按分は説明の手間がかかるため、可能であれば分割を優先します。
まとめ
- API キーごとの利用量が取れるのは OpenAI と Claude。Azure はデプロイメント、Bedrock と Vertex AI はモデル単位まで
- キー別の費用は利用量 × 単価の概算。実費はプロジェクト・リソースなど粗い単位で、合計の確認に使う
- 概算の合計と実費のずれは、単価表の更新漏れや把握していない利用のサイン
- 部署別に見たいなら、キーやプロジェクト、アカウントを部署に合わせて分けておく
- キーごとの費用を軸にすると、棚卸しと費用確認を 1 つの場で行える
ManageAI は、5 プロバイダの利用量を API キー（Azure はデプロイメント、Bedrock・Vertex AI はモデルの単位を疑似キーとして）ごとに集め、部署・利用者・プロジェクトに割り当てて集計します。キー・利用者別は概算、プロジェクト・全社は実費と、画面上で常に区別して表示します。読み取り専用キーの登録だけで始められます。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ