Cloudinary の自動アップロードでアップロードプリセットを適用してみた
ベルリンから伊藤です。
クラスメソッド・ヨーロッパ（ドイツ法人）では、パートナー SaaS である Cloudinary のプリセールス・導入支援を行っています。
本記事では、既存の外部ストレージの画像を初回アクセス時に自動で Cloudinary へ取り込む Auto Upload と、その取り込み時に Upload Presets を適用してみた検証内容を紹介します。
プリセットでフォーマット変換や上限サイズを効かせられれば、取り込みと同時に元画像を軽量化でき、ストレージ消費の削減にもつながります。
Auto Upload とは
Auto Upload を使用するには、Cloudinary 上のフォルダ（プレフィックス）を外部サーバの URL に対応づけるマッピング設定をしておきます。
該当パスの URL へリクエストがあると、Cloudinary はアカウント内のアセットを探します。アセットがまだ存在しない場合、Cloudinary はリモート元からアセットを取得して自分のアカウントに保管し、変換を適用して配信します。
アセットを事前に移行する必要がなく、アクセスされたものだけを遅延的に取り込めるのが利点です。
👉🏻 基本的な設定手順（S3 をリモート元にした例）はこちらの記事で解説しています。
Upload Presets とは
Cloudinary にアセットをアップロードする際の処理（保存先フォルダ、リサイズ、命名規則、形式変換など）を 事前定義しておける「設定のテンプレート機能」 です。
API や Media Library などのアップロード時にプリセット名を指定するだけで設定を丸ごと適用できます。
👉🏻 具体的なユースケースや Signed/Unsigned の違いはこちらの記事で解説しています。
Auto Upload Mapping 設定方法
Console の Settings → Upload → Auto Upload Mapping から追加します。今回は2つの方法を検証するために、ターゲットフォルダの異なる2つのマッピングを設定しました。
ターゲットフォルダは呼び出す画像 URL に影響します。
| 項目 | Src URL prefix | ターゲットフォルダ |
|---|---|---|
| 設定1 | https://thumb.wikimedia.org/wikipedia/commons/thumb/ |
wikimedia |
| 設定2 | 同上 | thumb.wikimedia.org |
Auto Upload にプリセットを適用するには
Auto Upload で取り込む画像にプリセットを効かせる方法は2つあります。
方法1：ターゲットフォルダと同名のプリセット
プリセット（Unsigned で作成）の名前をマッピングの Target Folder と同じにすると、そのマッピング経由の取り込みに自動適用されます。
逆に異なる名前のものを選んで指定することはできません。同じ名前のプリセットを作成するだけで、先ほどの Auto Upload Mapping の設定画面の「Associated Upload Preset」に表示され、自動的に適用されます。
もし大量にある Auto Upload マッピングに対して共通のプリセットを適用したい場合には、この方法ではなく次の方法が向いています。
方法2：API のデフォルトプリセット
Settings → Upload → Upload Defaults で画像・動画・raw ごとに デフォルトのアップロードプリセットを指定できます。
今回 API の Image のデフォルトプリセットを設定することで、API アップロードだけでなく Auto Upload の画像にもデフォルトで適用させることができます。
では、それぞれの方法で実際に Auto Upload にプリセットが適用されるかを検証します。
動作確認
方法1：マッピングごとのプリセット
プリセット名は Target folder と同じである必要があるため、今回「wikimedia」というプリセットを作成しました。
この方法では、Signing mode は Unsigned を選択する必要があります。
取り込みの設定は次のようにしています。通常の Auto Upload の挙動に合わせて、ファイル名をパブリックIDとし、一意のランダムサフィックスも付与しません。
変換とタグに次を設定し、保存します。
- Transform → Incoming transformation：
c_fit,h_250,w_250/q_auto - Manage and Analysis → Tags：
auto-upload-test
これにより、Cloudinary へ取り込む時点で縦横 250px 以下で品質を最適化する変換を適用し、タグ付けします。
◼️ 配信画像の確認
Cloudinary で呼び出す画像 URL は次の形式です。
https://res.cloudinary.com/<cloud_name>/image/upload/- Cloudinary のドメインやパスwikimedia/- マッピングで指定したターゲットフォルダpath/to/image.jpg- マッピングしたプレフィックス移行のパス
テスト用のリモート画像には Wikimedia Commons のサンプルを使いました。初回アクセスで取得・保存がトリガーされます。URL 末尾の ?utm_... は追跡用パラメータなので外します。
# Wikipedia 上の画像URL：
https://thumb.wikimedia.org/wikipedia/commons/thumb/5/58/Shiba_inu_taiki.jpg/960px-Shiba_inu_taiki.jpg?utm_source=de.wikipedia.org&utm_campaign=imageinfo&utm_content=thumbnail
→ サイズは 960 x 1131px、159.95 KiB
https://thumb.wikimedia.org/wikipedia/commons/thumb/7/78/Kamikochi_Marsh.jpg/960px-Kamikochi_Marsh.jpg?utm_source=de.wikipedia.org&utm_campaign=imageinfo&utm_content=thumbnail
→ サイズは 960 x 984px、333.98 KiB
# Cloudinary Auto Upload で指定する画像URL：
https://res.cloudinary.com/<cloud_name>/image/upload/wikimedia/5/58/Shiba_inu_taiki.jpg/960px-Shiba_inu_taiki.jpg
https://res.cloudinary.com/<cloud_name>/image/upload/wikimedia/7/78/Kamikochi_Marsh.jpg/960px-Kamikochi_Marsh.jpg
Cloudinary の画像URLを開いた結果、いずれも縦横の最大サイズ250pxで変換されたものが表示されました。
※ 確認には Cloudinary の Media Inspector (Chrome 拡張機能) を利用しています。
◼️ Media Library の確認
Cloudinary 上では wikimedia フォルダ配下で、取り込まれたオリジナルが250px以下に変換され、auto-upload-test タグが付与されていることを確認できました。
検証の結果、プリセットは意図どおり適用され、取り込みと同時に元画像が軽量化されることを確認できました。
方法2：デフォルトプリセット
方法1と同じ変換・タグを設定したプリセットを用意しました。ただし、デフォルトプリセットに使えるのは Signed のみなので、こちらは Signing mode を Signed で作成します。プリセット名は任意です。
作成後、Settings → Upload → Upload Defaults のAPIの画像デフォルトに指定します。
◼️ 配信画像の確認
設定2のマッピングを検証するため、ターゲットフォルダ thumb.wikimedia.org経由でアクセスして検証します。
# Cloudinary Auto Upload で指定する画像URL：
https://res.cloudinary.com/<cloud_name>/image/upload/thumb.wikimedia.org/5/58/Shiba_inu_taiki.jpg/960px-Shiba_inu_taiki.jpg
https://res.cloudinary.com/<cloud_name>/image/upload/thumb.wikimedia.org/7/78/Kamikochi_Marsh.jpg/960px-Kamikochi_Marsh.jpg
同じ Incoming Transformation を設定していたため、ブラウザでの確認結果は先ほど同じになりました。
◼️ Media Library の確認
こちらは thumb.wikimedia.org フォルダ配下で、先ほどと同様にサイズ・タグが確認できました。
◼️ API アップロードの確認
デフォルトプリセットとしての挙動を確かめるため、通常の API アップロードも試してみました。
import pprint
import cloudinary
import cloudinary.uploader
cloudinary.config(
cloud_name="xxxxx",
api_key="123456789012345",
api_secret="xxxxxxxxxxxxxxxxxxxxxxxxxxx",
secure=True
)
SOURCE = "https://thumb.wikimedia.org/wikipedia/commons/thumb/7/78/Kamikochi_Marsh.jpg/960px-Kamikochi_Marsh.jpg?utm_source=de.wikipedia.org" # 960 x 984px
res = cloudinary.uploader.upload(SOURCE)
pprint.pprint(res)
結果、width/heightが250px以下、タグが付与された画像がアップロードされてたことを確認できました。
{'access_mode': 'public',
'api_key': '376847451446853',
'asset_folder': '',
'asset_id': 'f3db1eb3deabd85fb5ddd955aef624b3',
'bytes': 11237,
'created_at': '2026-11-09T09:27:59Z',
'display_name': '960px-Kamikochi_Marsh',
'etag': 'b42a359c9f69c1f2df09c0a2411bb559',
'format': 'jpg',
'height': 250,
'info': {'visual_search': {'clip': {'status': 'pending'}}},
'original_filename': '960px-Kamikochi_Marsh',
'pages': 1,
'placeholder': False,
'public_id': '960px-Kamikochi_Marsh.jpg',
'request_id': 'e3bf16b0a60e67a78c1952fa39af3e49',
'resource_type': 'image',
'secure_url': 'https://res.cloudinary.com/<cloud_name>/image/upload/v1794216479/960px-Kamikochi_Marsh.jpg.jpg',
'signature': 'dbbf55235248d763a8dd80fe01f734a6d65edb0c',
'tags': ['auto-upload-test'],
'type': 'upload',
'url': 'http://res.cloudinary.com/<cloud_name>/image/upload/v1794216479/960px-Kamikochi_Marsh.jpg.jpg',
'version': 1794216479,
'version_id': 'd37641719d1fa97e17d0c4f4bab548ff',
'width': 244}
検証の結果、同名プリセットを紐づけていないマッピングでも、デフォルトプリセットが Auto Upload の取り込みに適用されることを確認しました。
方法1との違いは、マッピングごとにプリセットを用意しなくても、1つのデフォルト設定で横断的に適用できる点です（反面、プリセット未指定の API 画像アップロード全体に効くため、影響範囲には注意）。
プリセット適用による効果
取り込んだ画像に変換をかけて配信するだけなら、次のように配信 URL へ変換パラメータを組み込む方法でも実現できます。
https://res.cloudinary.com/<cloud-name>/image/upload/c_fit,h_250,w_250/q_auto/wikimedia/5/58/Shiba_inu_taiki.jpg/960px-Shiba_inu_taiki.jpg
ただしこの方法では、Cloudinary に保管されるオリジナルは元サイズのままで、 必要以上のストレージを消費してしまいます。
一方、プリセットの Incoming transformation で変換しておくと、 保管されるオリジナル自体が縮小され、ストレージを削減できます。
今回の検証では、取り込み時点での変換により Cloudinary のストレージを合計 476.59 KiB 節約することができました。
| オリジナル | 変換後 | 効果 | |
|---|---|---|---|
| 画像1 | 960 x 1131px、159.95 KiB | 212 x 250 px、6.67 KiB | 153.28 KiB 節約 |
| 画像2 | 960 x 984px、333.98 KiB | 244 x 250 px、10.67 KiB | 323.31 KiB 節約 |
リモート元画像が大きいほど、削減効果は大きくなります。
注意点として、同じ画像を他の用途でも使う場合は、Incoming の変換は全用途をカバーできる大きめのサイズにとどめ、配信時に必要なサイズへ再変換します。取り込み時に小さくしすぎると、後から大きいサイズが必要になっても元に戻せないためです。
おわりに
Auto Upload Mapping を使えば、既存アセットを一括移行せずに、アクセスされたものから順に Cloudinary へ取り込めます。さらにプリセットを組み合わせれば、取り込みと同時に変換やタグ、モデレーションなどを自動的に適用することができます。
今回のように最適化やフォーマット統一、サイズ上限を効かせれば、ストレージ削減でユニット節約の設計ができます。
同じように大量の既存画像を Cloudinary から配信したい方の参考になれば幸いです。
クラスメソッド・ヨーロッパでは、Cloudinary をはじめとする欧州拠点のメディア配信・バックオフィス運用を、自社の実運用知見をもとにご支援しています。お気軽にご相談ください。
