Cloudflare 31：Images と Stream ― 画像と動画を見る人に合わせて配る

自前でやると：大きさ × 形式の数だけ画像を作る

Images を使わずに、画像を見る人に合わせて配ろうとすると、どうなるでしょうか。

まず、大きさの違う版が要ります。スマホ用、PC 用、一覧のサムネイル用。次に、形式の違う版が要ります。昔ながらの JPEG に加えて、より小さくできる WebP や AVIF。新しい形式は多くのブラウザで読めますが、全部ではないので、元の形式も残しておきます。

3つの大きさ × 3つの形式で、写真1枚につき9ファイルです。アップロードのたびにこれを作る処理を書き、保存し、HTML ではブラウザに合ったものを選ばせる必要があります。デザインが変わって「幅 800 の版も欲しい」となったら、過去のすべての写真を作り直します。

動画はさらに大変です。

どれも専門の知識が要る仕事です。Images と Stream は、これらを Cloudflare の側で引き受けます。

Images：元の画像1枚から、必要な形をその場で作る

Cloudflare Images の中心にあるのは、「必要になったときに、エッジで作る」という考え方です。

元の画像は1枚だけ置いておきます。置き場所は、Images の中（Images に保存する方法）でも、R2（22号）や自分のサーバーでも構いません。見る人から「この画像を、幅 400 で、AVIF で」と頼まれたら、Cloudflare のエッジがその場で元の画像を変換して返します。

一度変換した結果はキャッシュされる（02号）ので、同じ形の2回目からは変換の処理も走りません。新しい大きさが必要になっても、URL を変えるだけで済み、過去の画像を作り直す必要はありません。

Images の機能は、大きく2つの使い方に分かれます。すでにどこかにある画像を変換して配る（Transformations）と、Images に画像を保存して配る（保存と配信）です。次のページから順に見ていきます。

変換：URL に「幅 400・切り抜き」と書くだけ

いちばん手軽な使い方は、URL で変換を指定する方法です。Cloudflare を通っているサイトなら、画像の URL の前に /cdn-cgi/image/ と変換の指定を足すだけです。

https://example.com/cdn-cgi/image/width=400,fit=cover,quality=80/img/photo.jpg

これで、/img/photo.jpg を幅 400 ピクセルにし、枠いっぱいに切り抜き、画質 80 で返します。主な指定は次のとおりです。

使う前に、管理画面の Images の項目で、そのゾーン（ドメイン）の変換を有効にする必要があります。また、別のドメインにある画像を変換したいときは、そのドメインを許可しておきます。誰の画像でも勝手に変換できてしまわないようにするためです。

HTML では、srcset に幅の違う URL を並べておけば、ブラウザが画面に合ったものを選んでくれます。

形式：ブラウザが読める、いちばん軽い形式で返す

画像を軽くするもう1つの方法が、形式を変えることです。

JPEG や PNG は古くからある形式で、どのブラウザでも読めます。これに対して、WebP や AVIF は新しい形式で、同じくらいの見た目なら、ファイルをかなり小さくできることが多いです。ただし、すべてのブラウザ・すべての古い端末が読めるわけではありません。

そこで使うのが format=auto です。ブラウザは画像を頼むときに、「自分はこういう形式を読める」という情報（Accept ヘッダー）を送ってきます。Cloudflare はそれを見て、読める中でいちばん軽い形式を選んで返します。AVIF が読めるなら AVIF、読めなければ WebP、それも読めなければ元の形式です。

作る側は、形式のことを考えずに1つの URL を書くだけで済みます。

なお、Cloudflare には Polish という、古くからある画像の自動最適化の機能もあります。Pro 以上のプランのゾーンで、ページの画像を自動で圧縮したり WebP にしたりするものです。大きさの変更はできないので、新しく組むなら、この号で見ている変換（Transformations）を使うのが基本です。

保存して配る：Images に置き、「バリアント」で呼ぶ

もう1つの使い方は、画像を Images に保存して配る方法です。利用者がアップロードした写真を置く場所として、そのまま使えます。

画像をアップロードすると、画像 ID が振られます。配るときは、次のような URL になります。

https://imagedelivery.net/{アカウントのハッシュ}/{画像ID}/thumbnail

最後の thumbnail の部分がバリアントです。バリアントは、「幅 200 で切り抜き」「幅 1200 で縮めるだけ」のような変換の設定に名前を付けたものです。管理画面で、thumbnail・public・hero のように、アプリで使う形をいくつか作っておきます。

利用者からのアップロードは、サーバーで「一度きりのアップロード URL」を発行し、ブラウザがそこへ直接送る形が使えます。大きなファイルがあなたの Worker を通らないので、処理が軽くなります。

使い方：Worker から変換を指定する

URL での指定と同じことを、Worker（18号）の中から行うこともできます。fetch の cf.image に変換の指定を書きます。

export default {
  async fetch(req: Request): Promise<Response> {
    const url = new URL(req.url);
    // 幅は利用者に自由に決めさせず、決め打ちの数種類から選ぶ
    const width = url.searchParams.get("w") === "s" ? 400 : 1200;
    return fetch(`https://assets.example.com${url.pathname}`, {
      cf: { image: { width, fit: "scale-down", format: "avif" } },
    });
  },
};

Worker を挟むと、「ログインしている人にだけ大きな画像を見せる」「利用者の端末に合わせて幅を選ぶ」「元の画像の置き場所を隠す」といった判断を、変換の前にできます。

このほか、Worker の中で画像のデータそのものを変換する Images のバインディングもあります。R2 から読んだ画像を変換して別の場所に保存する、といった処理に向いています。書き方は公式の Images binding のページで確かめてください。

コードの中で、幅を決め打ちの数種類にしていることに注目してください。理由は料金と落とし穴のページで説明します。

動画は、もっと難しい

ここから図の舞台は同じまま、中身が動画の Cloudflare Stream に入れ替わります。

画像なら「大きさと形式を変えて返す」で済みました。動画では、それに加えて次のことが必要になります。

自前でそろえるなら、エンコードのサーバー、動画の保存場所、配信用の CDN、プレイヤーを別々に用意し、つなぎ合わせることになります。

Stream は、この一式をまとめて引き受けるサービスです。あなたがやるのは、動画をアップロードして、ページにプレイヤーを貼ることだけです。

エンコード：1本の動画から、画質の違う版を作る

動画を Stream にアップロードすると、Stream はまずエンコードをします。元の動画から、画質（解像度とビットレート）の違う版を何種類も作り直す処理です。

たとえば 1080p で撮った動画から、1080p・720p・480p・360p のような版を作ります。高い画質はきれいですがデータ量が多く、低い画質は粗いですが軽くなります。

エンコードは、コンピューターにとってとても重い処理です。自前でやるなら、専用のサーバーや、クラウドの動画変換サービスを用意し、処理が終わるのを待つ仕組みを作ることになります。

Stream では、この処理はアップロードすれば自動で行われます。しかも、動画の取り込みとエンコードそのものには料金がかかりません。払うのは、保存している動画の長さと、見られた動画の長さです（料金のページで詳しく見ます）。

アップロードの方法は、管理画面から、API から、ほかの場所にある動画の URL を指定して取り込む、利用者のブラウザから直接、などいくつかあります。

配信：数秒ずつの細切れを、回線に合わせて選んで送る

エンコードした動画は、数秒ずつの断片に切り分けられ、目次（マニフェスト）と一緒に配られます。この方式を HLS（Apple が作った方式）や DASH（国際標準の方式）と呼びます。Stream はどちらにも対応しています。

見る人のプレイヤーは、まず目次を取りに行きます。目次には「この動画は何秒ずつの断片でできていて、画質ごとにこういう URL がある」と書いてあります。プレイヤーは、今の回線の速さを測りながら、ちょうどよい画質の断片を次々に取りに行きます。

これをアダプティブ・ビットレートと呼びます。途中で画質が変わっても、再生は止まりません。断片は Cloudflare の網から配られ、キャッシュもされるので、大勢が同時に見ても耐えられます。

ライブ配信も同じ仕組みです。配信ソフトから RTMPS や SRT、WebRTC（WHIP）で Stream に送ると、Stream がその場でエンコードして断片にし、視聴者に配ります。

使い方：アップロードして、iframe を貼る

Stream を使う基本の流れは、次のとおりです。

利用者がブラウザから動画を投稿するアプリなら、サーバー側で一度きりのアップロード URLを発行します。API トークンを利用者のブラウザに渡さずに済みます。

POST https://api.cloudflare.com/client/v4/accounts/{account_id}/stream/direct_upload

プレイヤーは、iframe を貼るだけです。

<iframe src="https://customer-{コード}.cloudflarestream.com/{動画ID}/iframe"
  allow="autoplay; fullscreen" allowfullscreen></iframe>

自分の好きなプレイヤー（hls.js など）を使いたいときは、.../{動画ID}/manifest/video.m3u8（HLS）のような目次の URL を渡します。

会員だけに見せたい動画は、署名付き URL（期限付きのトークン）を必須にする設定にします。

料金と制限：画像は「変換の数」、動画は「分数」

2026年9月時点の料金の骨格です。

Images の変換は「種類」で数えます。同じ画像の同じ指定（幅・形式など）は、何回配っても1種類です。逆に、幅が 400 と 401 なら別の種類です。

Stream の再生は、動画の長さで数えます。画質は関係ありません。10分の動画を 100 人が最後まで見れば、1,000 分です。

数字は変わることがあるので、公式の Pricing のページで確かめてください。

よくある落とし穴

Images と Stream でつまずきやすい点です。

とくに最初の点は、料金にも、キャッシュの効き具合にも響きます。キャッシュは同じ URL にしか当たらないので、幅の種類が多いほど、変換の処理も増えます。

他の機能とのつながり

画像と動画の配信は、いくつもの機能の組み合わせです。

よくある組み合わせは、「利用者の写真は R2 に置き、表示するときは変換の URL で幅と形式を合わせる」という形です。R2 は置く場所、Images は配るときの形を整える場所、と役割を分けて考えると分かりやすくなります。