5プロバイダの使用量を一元管理する方法｜管理API横断
OpenAI・Azure OpenAI・Claude・AWS Bedrock・Google Vertex AIの5プロバイダの使用量と費用を一元管理する方法を解説します。共通のデータ形式への正規化、UTCの時間バケットと重複防止、遅れて届くデータの補正、単価表と為替、組織マッピング、認証情報の管理、内製とツールの判断までを設計の観点で整理しました。
5つのプロバイダの使用量を一元管理するには、各社の管理APIから定期的にデータを取得し、共通の形式（キー × モデル × 時間のトークン数）に揃えて1か所に保存します。そのうえで、単価表で概算費用を計算し、実費と突合し、キーを部署に対応付けます。
難しいのは API を呼ぶことではなく、各社で違う粒度・時刻・遅れ・単位を揃え、毎日正しく更新し続けることです。この記事では、一元管理の仕組みを作るときの設計のポイントを説明します。各社の管理APIの違いは「主要5プロバイダの管理API一覧」、全体像は「生成AI APIの利用状況・費用データを取得する方法 完全ガイド」を参照してください。
一元管理の全体像
| 段階 | やること |
|---|---|
| 1. 取得 | 各社の管理API・メトリクス・課金サービスから、利用量と実費を定期的に取得する |
| 2. 正規化 | 共通のデータ形式に揃える（キー・モデル・時間・トークンの種類） |
| 3. 保存 | 重複なく保存し、遅れて届いたデータで補正する |
| 4. 計算 | 単価表でトークン数から概算費用を出し、為替で円換算する |
| 5. 対応付け | キー・疑似キーを部署・利用者・プロジェクトに対応付ける |
| 6. 突合 | 概算の合計と実費を比べ、差を確認する |
| 7. 表示・通知 | 部署別に集計して見せ、予算や急増で通知する |
共通のデータ形式に揃える
各社の利用量を、次のような共通の形に揃えて保存します。
| 項目 | 内容 | 例 |
|---|---|---|
| プロバイダ | 5社のどれか | openai / azure / anthropic / bedrock / vertex |
| キー | APIキー、または疑似キー | APIキーの ID、「リソース/デプロイメント」、「リージョン/モデル ID」 |
| モデル | モデル名 | 各社のモデル名 |
| 時間 | バケットの開始時刻（UTC・1時間単位） | 2026-09-27T03:00:00Z |
| 入力トークン | キャッシュを除く入力 | |
| キャッシュ入力 | 読み取り・作成（取れる社のみ） | |
| 出力トークン | ||
| リクエスト数 | 取れる社のみ | |
| 確定フラグ | 値が確定したか | 速報値か確定値か |
キー以外の単位を「疑似キー」として同じ列に入れるのがポイントです。こうすると、APIキーで取れる社も、デプロイメントやモデルまでの社も、同じ表で集計できます。粒度の考え方は「生成AI利用状況の粒度はプロバイダで違う」を参照してください。
取れない項目（Claude のリクエスト数、Azure のキャッシュ入力など）は、0 ではなく「値なし」として保存します。0 と保存すると、合計やグラフで「使われていない」と誤解されます。
時刻と重複の扱い
時間のバケットは UTC の時刻境界で揃える
各社の API は UTC で時刻を返します。保存する時間のバケットは、UTC の時刻境界（毎時0分）に固定します。取得のたびにバケットの境界がずれると、同じ利用が2つのバケットに入り、二重に数えることになります。日本時間の日付での集計は、保存したデータを表示するときに変換します。
上書きで重複を防ぐ
「プロバイダ × キー × モデル × 時間」を一意のキーにして、同じ組み合わせのデータは上書きします。こうしておけば、同じ時間帯を何度取得しても二重計上にならず、取得の失敗時にも再実行するだけで済みます。
遅れて届くデータを補正する
各社の利用量は、直近の数時間から数日の間に値が変わることがあります。実費はさらに遅れて確定します。
| 対応 | 内容 |
|---|---|
| 直近分の再取得 | 取得のたびに、直近の数時間分をもう一度取得して上書きする |
| 日次の確定処理 | 1日1回、直近の数日分を取り直し、値を確定させる |
| 実費の遅れ | 実費は約1日〜2日遅れて確定する前提で、翌日以降に取得する |
| 表示 | 画面には「最終取得時刻」と「どの日まで確定済みか」を表示する |
見ている数字が速報値か確定値かを利用者に示すと、「昨日の数字が今日変わった」という問い合わせを防げます。
単価表と為替
概算費用は、トークン数に単価を掛けて計算します。
| 管理すること | 内容 |
|---|---|
| 単価表 | プロバイダ・モデル・トークンの種類（入力・キャッシュ・出力）ごとの単価 |
| 適用開始日 | 単価改定に備え、いつからその単価かを記録する。過去の利用は当時の単価で計算する |
| 経路・地域の違い | 同じモデルでも経路や地域で単価が違う場合がある |
| 為替 | 円換算するなら、レートの取り方（日次・月平均など）を決め、使ったレートを記録する |
単価表は、改定のたびに更新が必要です。更新が遅れると、概算と実費の差が大きくなります。月次で概算の合計と実費を比べ、差が広がっていないかを確認します。
組織マッピング
キー・疑似キーを、部署・利用者・プロジェクトに対応付けます。
- 新しく見つかったキーは自動で一覧に追加し、対応付けがなければ「未割当」として集計する
- プロバイダに登録されているキーの名前や持ち主は、定期的に同期する
- 手動で設定した対応付けは、同期で上書きしない
対応付けの設計は「組織マッピングとは｜APIキーと部署を紐づける設計の基本」を参照してください。
認証情報の管理
5社分の管理用の認証情報は、組織全体の利用状況を読める強い鍵です。
| 対策 | 内容 |
|---|---|
| 権限を絞る | 読み取りの権限だけを付け、モデルを呼び出す権限は付けない |
| 保管 | シークレット管理サービスで暗号化して保管する。画面には末尾の数文字だけを表示する |
| 使う場面を限る | 取得処理のときだけ復号して使う |
| 失効の手順 | 各社の管理画面でいつでも失効できる。手順を台帳に書いておく |
内製するか、ツールを使うか
| 観点 | 内製 | ツール |
|---|---|---|
| 初期の手間 | 5社分の取得・正規化・保存・画面を作る | 認証情報の登録と組織マッピング |
| 継続の手間 | API の仕様変更への追随、単価表の更新、障害対応 | ツール側が追随する |
| 柔軟性 | 自社の要件に合わせられる | ツールの機能の範囲 |
| 費用 | 開発と運用の人件費 | 利用料 |
| セキュリティ審査 | 自社内で完結 | 預ける認証情報とデータの扱いを審査する |
プロバイダが1〜2社で、開発の余力があれば内製も現実的です。プロバイダが3社以上、または専任の担当者がいない場合は、仕様変更と単価表の保守の負担が続くことを見込んで判断します。
よくある質問
Q. 最初から5社すべてに対応する必要がありますか？ ありません。費用の大きいプロバイダから1社ずつ始めます。共通のデータ形式を最初に決めておけば、後からプロバイダを足しても同じ表で集計できます。
Q. 取得の間隔はどのくらいが適切ですか？ 利用量は1時間以内の間隔、実費は1日数回程度が目安です。急増に早く気づきたいなら、利用量の間隔を短くします。各社の API の利用上限と料金も考慮します。
まとめ
- 5社の使用量は、定期取得 → 共通形式への正規化 → 保存 → 概算計算 → 対応付け → 突合の流れで一元管理する
- キー以外の単位は疑似キーとして同じ列に入れ、取れない項目は「値なし」で保存する
- 時間は UTC の時刻境界で揃え、上書きで重複を防ぎ、直近分の再取得と日次の確定で遅れを補正する
- 単価表は適用開始日つきで管理し、月次で概算と実費を突合する。認証情報は読み取り専用で厳重に保管する
ManageAIは、5プロバイダの管理APIを横断して利用量を15分ごと、実費を1時間ごとに自動で取得し、日次で直近の数日分を補正して確定させます。APIキー・デプロイメント・モデルの粒度の違いを疑似キーで揃え、部署・利用者・プロジェクト別に1つの画面で可視化します。読み取り専用の認証情報の登録だけで始められます。モニター企業を募集中です。
関連記事
- 生成AI APIの利用状況・費用データを取得する方法 完全ガイド｜5プロバイダの管理API
- 主要5プロバイダの管理API一覧｜取得できる項目比較
- 生成AI利用状況の粒度はプロバイダで違う｜キー・デプロイ・モデル
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ