Cloudinary の usage APIを徹底解説 — フィールド仕様や集計ロジックを深掘りしてみた

Cloudinary の usage APIを徹底解説 — フィールド仕様や集計ロジックを深掘りしてみた

Cloudinary Admin API の usage メソッドのレスポンス仕様を詳しく解説。各フィールドの意味、Storage・Bandwidth・Transformations のクレジット換算方法、請求期間ごとの正しい集計ロジック、Impressions プランでの注意点まで、実際の検証をもとにまとめています。
2026.04.07

先日公開したこちらのブログで、Cloudinary の料金体系と使用量の確認方法を紹介しました。

https://dev.classmethod.jp/articles/cloudinary-pricing-and-usage-monitoring-guide/

その中でも触れた usage() メソッドについて、検証の中で確認した内容を深掘りします。

なお、本記事の内容の多くは、公式ドキュメントに記載のない挙動について実際に検証して確認した情報をまとめています。仕様は予告なく変更される場合があるため、重要な判断の際はお手元での確認と Cloudinary サポートへの問い合わせを推奨します。

usage メソッドとは

  • アカウントの利用量クレジット/ユニット消費量を日次で取得
  • API 実行(API キー発行はクラウド環境ごと)のため、取得データは環境単位
  • 過去90日まで指定可能

90日より前のデータが必要な場合は、コンソールの Usage Reports(過去12ヶ月まで、消費ユニット数含まず)や Quota Dashboard(現在の請求サイクル期間のみ)を参照するか、Cloudinary サポートへの問い合わせが必要です。

usage() を含む Admin API は1時間あたり500リクエストレート制限があります。Enterprise プランの場合は 2,000 リクエスト以上です(Settings > Security から実際値を確認可能)。


呼び出し方

date パラメータはオプションで省略可能です。前日以前の過去90日を指定してデータ取得、または省略して当日時点のデータを取得できるようです。

Python

import cloudinary, cloudinary.api
result = cloudinary.api.usage(date = "2026-04-01")

Node.js

const cloudinary = require("cloudinary").v2;
const result = await cloudinary.api.usage({ date: "2026-04-01" });

他の環境はドキュメントをご参考ください。


レスポンス

フィールド解説

レスポンスは以下のフィールドで構成されます。

Enterprise プランの場合もフィールド名は「credits」が使われます。Enterprise 以外のプランでは表内の「ユニット」→「クレジット」と読み替えてください。

フィールド 説明
plan 契約プラン名
last_updated データの最終更新日(リクエスト前日の日付)
date_requested データのリクエスト指定日(省略時は当日の UTC 0:00)
transformations 変換処理の回数(usage)、変換処理の消費ユニット数(credits_usage)、処理タイプ別の内訳(breakdown
objects アセット総数(usage = オリジナルアセット数 + 派生アセット数)
bandwidth 配信済みデータ量(usage、bytes)と消費ユニット数(credits_usage
storage ストレージ使用量(usage、bytes)と消費ユニット数(credits_usage
impressions 画像の配信回数(usage)と消費ユニット数(credits_usage) ※ 2024年1月以降の Enterprise のうち、画像を bandwidth でなく配信回数で計測する契約でのみ使用
seconds_delivered 動画配信秒数(usage)と消費ユニット数(credits_usage) ※ Enterprise のうち、動画を bandwidth でなく秒数で計測する契約でのみ使用
credits 全項目の消費ユニット合計(usage) — 呼び出し時に日付オプションを指定しない場合のみ、クレジット上限または契約ユニット数(limit)と使用率(used_percent)も含まれる
resources オリジナルアセットの総数
derived_resources 派生アセット(変換アセット)の総数
requests API リクエスト数
(アドオン) aws_rek_tagginggoogle_taggingcloudinary_aiobject_detection など、利用があった場合のみ、それぞれ使用量(usage)と上限(limit
media_limits 契約プランの画像/動画/その他のファイルサイズ上限(image_max_size_bytesvideo_max_size_bytesraw_max_size_bytes、bytes)、画像/その他のピクセルサイズ上限(image_max_pxasset_max_total_px
rate_limit_allowed Admin API のレートリミット(呼び出し回数上限)
rate_limit_reset_at レートリミットのリセット時刻
rate_limit_remaining レートリミットの残り回数

transformationsbandwidthimpressionsseconds_delivered およびアドオンの usage はその日の使用量を示しています。storage のみ例外で、指定日時点の累積使用量です。詳細は後述の「各項目の集計方法」をご参照ください。

レスポンス例

{
  "plan": "Free",
  "last_updated": "2026-04-01",
  "date_requested": "2026-04-02T00:00:00Z",
  "transformations": {
    "usage": 26,
    "credits_usage": 0.03,
    "breakdown": {
      "transformation": 26
    }
  },
  "objects": {
    "usage": 541
  },
  "bandwidth": {
    "usage": 9227721,
    "credits_usage": 0.01
  },
  "storage": {
    "usage": 295753639,
    "credits_usage": 0.28
  },
  "impressions": {
    "usage": 41,
    "credits_usage": 0
  },
  "seconds_delivered": {
    "usage": 0,
    "credits_usage": 0
  },
  "credits": {
    "usage": 0.32,
    "limit": 25,
    "used_percent": 1.28
  },
  "resources": 130,
  "derived_resources": 411,
  "requests": 43,
  "aws_rek_tagging": {
    "usage": 1,
    "limit": 50
  },
  "cloudinary_ai": {
    "usage": 20,
    "limit": 15
  },
  "media_limits": {
    "image_max_size_bytes": 10485760,
    "video_max_size_bytes": 104857600,
    "raw_max_size_bytes": 10485760,
    "image_max_px": 25000000,
    "asset_max_total_px": 50000000
  },
  "rate_limit_allowed": 500,
  "rate_limit_reset_at": "2026-04-02T09:00:00.000Z",
  "rate_limit_remaining": 499
}

ユニット消費の計算ルール

利用量のユニット換算

1クレジット/ユニットあたりの各項目の換算レートはプランと契約によって異なります。

例えば無料プランの Storage は次の通りクレジット換算され、小数第二位で四捨五入されていることが分かります。

295753639 ÷ 1,073,741,824 ( 1 GiB) = 0.275.. → 0.28 ✅

"storage": {
  "usage": 295753639,
  "credits_usage": 0.28
},

プランごとの換算レートや詳細なユニット換算については、前回の記事をご参照ください。

なお、換算レートに記載の「GB」や「TB」は、サポートへの確認の結果、実際には「GiB」「TiB」で計算されているようです。

各項目の集計方法

他の項目が日次の利用量なのに対し、Storage は指定日時点の累積量で、通常ゆるやかに増加していきます。

以下はあるアカウントの1日と30日時点の結果のうちユニット数をまとめたものです。

項目 3/1 時点のユニット数 3/30 時点のユニット数
transformations 0.44 0.36
bandwidth 0 0
storage 5.36 5.94
impressions 0.25 0.26
credits(合計) 6.05 6.56

消費ユニットは1日あたり6前後ですが、このアカウントにおけるひと月のユニット消費は 25.29 でした。単純に日次の合計を足し合わせた場合(約6 × 30日 = 180)とは大きく異なります。これは毎日の合計のうち大部分を占める Storage(約5.4)が、日次の合計ではなく期間内の最大値(ひと月で1度だけ)でカウントされるためです。

期間内の実際の計算は以下のようにして導き出すことができました。

  • sum( transformations + bandwidth + impressions ) + max( storage )
    • storage はひと月の最終日の値(最大値)
    • それ以外はひと月の日次合計

⚠️ ただし、アセットを大量に削除してストレージ利用量を減らした場合の挙動は確認できておりません。

請求サイクルの区切り

上記で消費ユニット/クレジット数を参照する期間を「ひと月」と呼んでいますが、暦月ではなく、環境によって区切りが異なります。

  • 通常プラン:常に過去30日間で参照。
  • Enterprise プラン:契約によって billing cycle(請求サイクル)が異なり、それを1か月で区切ったものをひと月として参照。

👉🏼 例えば Enterprise 契約の請求サイクルが「2025年6月17日〜2026年6月16日」なら、ひと月は毎月17日〜翌月16日となります。

Quota Usage のページからも実際の月区切りが確認できます。

cl_unit_by_metric

Image Impressions または Video Seconds を使用するプランの場合

これらのプランの場合、impressions なら画像、seconds_delivered なら動画がこれらでユニット換算されるため、それぞれの Bandwidth(帯域幅) はユニット消費が発生しません。

ただし、システムの仕様上 bandwidth の使用量 usageには引き続き画像・動画の配信量も集計されるようです。そのため、実際にユニット換算してみると credits_usage の値と乖離する場合があります。

Image Impressions プランでの例:

"bandwidth": {
  "usage": 25760033270, // 画像により使用量が計測されている
  "credits_usage": 0    // 動画・その他での帯域幅利用がないため、ユニット消費はゼロ
},
...
"impressions": {
  "usage": 1328582,
  "credits_usage": 0.XX  // 画像の配信は impressions でユニット消費している
},

請求サイクル1ヶ月分を集計するスクリプト

上記の計算ルールをもとに、ひと月分のユニット数を計算するスクリプトを実装してみました。

Python スクリプト:

from datetime import date, timedelta

import cloudinary, cloudinary.api

cloudinary.config(
    cloud_name="クラウド名",
    api_key="APIキー",
    api_secret="APIシークレット",
)

START = "2026-02-17"
END   = "2026-03-16"

d0, d1 = date.fromisoformat(START), date.fromisoformat(END)
dates  = [(d0 + timedelta(n)).isoformat() for n in range((d1 - d0).days + 1)]

rows = []
for day in dates:
    r = cloudinary.api.usage(date=day)
    t, b, s, i = r["transformations"], r["bandwidth"], r["storage"], r["impressions"]
    rows.append({
        "t_credits": t["credits_usage"],
        "b_credits": b["credits_usage"],
        "s_credits": s["credits_usage"],
        "i_credits": i["credits_usage"],
    })

total_t = sum(r["t_credits"] for r in rows)
total_b = sum(r["b_credits"] for r in rows)
total_s = max(r["s_credits"] for r in rows)
total_i = sum(r["i_credits"] for r in rows)
print(f"t_credits: {total_t:.2f}")
print(f"b_credits: {total_b:.2f}")
print(f"s_credits: {total_s:.2f}")
print(f"i_credits: {total_i:.2f}")
print(f"total:     {total_t + total_b + total_s + total_i:.2f}")

結果:

t_credits: 11.51
b_credits: 0.00
s_credits: 5.97
i_credits: 7.81
total:     25.29

Quota Usage との比較・使い分け

前回のブログでご紹介した Quota Usage はベータ版ではありますが、アカウント全体のユニット消費量を確認するのに最適です。コンソールからグラフで簡単に分析できます。

cl_quota_usage

ただし、利用には Master admin 権限が必要です。

コンソールの Usage/Delivery Reports では Admin 権限でも環境ごとの使用量を分析できます。より柔軟な値の操作が必要な場合や、Master admin 権限なしで消費ユニット数を確認したい場合に usage API が活躍しそうですね。

usage() API Quota Usage Usage / Delivery Reports
アクセス方法 API(スクリプト) コンソール(Beta) コンソール
取得単位 クラウド環境ごと アカウント全体(一部環境別) クラウド環境ごと
データ期間 過去90日(日次) 現在の請求サイクル 過去12ヶ月
取得粒度 1日単位 月単位・サイクル単位 月単位
ユニット消費数 表示あり ✅ 表示あり ✅ 表示なし ❌
使用量 含む ✅ 概要のみ ✅ 含む ✅
グラフ表示 なし ❌ あり ✅ あり ✅
必要な権限 対象環境の API キー Master admin 権限 Admin 権限
備考 Beta・監査用途には非保証 CSV/PDF エクスポート可

以上、ご参考になれば幸いです!

この記事をシェアする

関連記事