画像配信の設計が粗利を静かに削る

画像配信の設計が粗利を静かに削る
デジタルの事業で粗利を静かに削るのは、損益計算書に一行で溶けた帯域コストである。画像や動画を無最適化・オリジン直・キャッシュ未効のまま配れば、アクセスが増えるほど転送費が線形に膨らみ、成長がそのまま原価の膨張になる。DDでは粗利率を信じず、月間転送量・キャッシュヒット率・平均オブジェクトサイズの三点と実物の画像一枚を突き合わせ、削れる原価が残っているかを見極める。この余白は、売り手には売る前に閉じられる伸びしろ、買い手には買った後に刈り取れる伸びしろになる。

事業の売買を検討する段階で、買い手がまず取り寄せるべきものの一つに、クラウドの請求明細があります。損益計算書では「サーバー費」として一行にまとまっている金額が、AWSやGoogle Cloudの明細を開くと、コンピュート(計算処理)・ストレージ(保管)・データ転送(配信)という別々の項目に分かれています。そして画像や動画を多く扱う事業ほど、この「データ転送」の一行が、コンピュートの何倍もの額で居座っていることがあります。

気づきにくいのは、この転送費が事業を壊さないからです。障害も出ず、ページも普通に開く。ただ、アクセスが増えるたびに比例して膨らみ、粗利(売上から直接原価を引いた利益)をじわじわ薄くしていく。この請求書の底に静かに沈んでいる原価は、配信設計の粗さから生まれます。それは技術的な欠陥というより、初期設定のまま放置された「設計の不在」から生まれる場合があります。

損益計算書の粗利は「今の粗さ」を隠す ── 帯域は見えにくい原価である

損益計算書の粗利は「今の粗さ」を隠す ── 帯域は見えにくい原価である

デジタルの事業では、画像や動画を利用者に届けるための通信量(帯域、bandwidth)が、製造業でいう材料費に近い変動費になります。売上が伸びれば通信量も増え、通信量が増えれば請求額も増える。にもかかわらず損益計算書上は「通信費」や「サーバー費」に溶けていて、それが売上に対してどれだけの比率を占めているのかが、ぱっと見では分かりません。

やっかいなのは、粗利率という数字が「現時点の粗さ」をそのまま固定して見せてしまうことです。配信設計が粗いまま黒字になっている事業は、粗利率が本来あるべき水準より数ポイント低いところで均衡しています。売り手はそれを「うちのコスト構造はこういうもの」と受け入れており、買い手は損益計算書の粗利率だけを見て「この程度の利益率の事業だ」と評価してしまう。両者とも、削れる原価がそこにあることに気づかないまま値段がつきます。

帯域が見えにくい原価である理由はもう一つあります。失敗として表に出ないことです。データベースが遅ければ苦情が来ますし、決済が落ちれば売上に直結します。ところが配信が非効率でも、利用者は少し重いページを我慢するだけで、事業者の手元には請求書という遅れた形でしか届きません。監視は落ちていないものを警報しないので、この非効率はどのダッシュボードにも表示されないのです。

オリジン直配信という初期設定 ── キャッシュヒット率が粗利の大半を決める

オリジン直配信という初期設定 ── キャッシュヒット率が粗利の大半を決める

画像配信のコストを決める最大の変数は、キャッシュヒット率です。キャッシュとは、一度配信した画像を利用者に近い場所(CDN、コンテンツ配信網のサーバー)に写しを置いておき、次からはそこから返す仕組みです。ヒット率とは、全リクエストのうち、その写しから返せた割合を指します。

ここが粗い事業の典型が、オリジン直配信です。オリジンとは画像の大元が置かれた場所、たとえばS3のようなストレージや自前のサーバーを指します。CDNを噛ませていない、あるいは噛ませていてもキャッシュ設定が効いておらず、毎回オリジンまで取りに行っている状態です。S3のようなストレージは外への転送1GBあたりに課金する従量制で、しかもその単価はCDNの配信単価より割高なことが多い。つまりオリジン直は、一番高い蛇口から水を出しっぱなしにしているようなものです。

数字で言えば、ヒット率が40%の事業と95%の事業では、同じアクセス数でもオリジンが負担する転送量が10倍以上変わります。40%なら6割がオリジン直撃、95%なら5%しかオリジンに届かない。この差がそのまま請求書のデータ転送の一行に出ます。DDでキャッシュヒット率を確認せずに粗利率だけを信じるのは、蛇口の開き具合を見ずに水道代を評価するのに似ています。

無最適化の代償 ── カメラ実寸のJPEGを百万回配る

無最適化の代償 ── カメラ実寸のJPEGを百万回配る

ヒット率と並ぶもう一つの変数が、1枚あたりのサイズです。ここで起こりうるのが、スマートフォンやカメラで撮った実寸のまま、3MBも4MBもある画像を、表示上は幅300ピクセルのサムネイルとして配っているケースです。ブラウザ側で縮小して表示しているので見た目には気づきませんが、通信としては実寸の全バイトが毎回流れています。

画像は、適切に縮小し、WebPやAVIFといった新しい形式(従来のJPEGより軽く保存できる圧縮方式)に変換するだけで、見た目の劣化なしに数分の一から十分の一に落とせます。WebPはJPEGよりおおむね2〜3割、AVIFなら半分近くまで軽くなります。1枚3MBの写真が、リサイズと形式変換で200〜300KBになる。これが月に何百万回配信される事業なら、削減幅は転送量の桁を一つ変えます。

この最適化を外部サービスに任せている事業もあります。CloudinaryやimgixのようなCDN画像最適化サービスは、URLにパラメータを付けるだけでリサイズと形式変換を自動でやってくれます。便利な反面、これは第三者サービスへの依存であり、移管や解約の際にURL構造ごと作り直しになる負債にもなり得ます。この構造の見方はWebサービス売却で効く第三者API依存で扱っています。自前で最適化しているのか、外部に握られているのかは、DDで必ず切り分けます。

キャッシュが効かない設計の見分け方 ── Cache-Control・Vary・クエリ文字列

キャッシュが効かない設計の見分け方 ── Cache-Control・Vary・クエリ文字列

CDNを入れているのにヒット率が上がらない事業には、設定上の原因がある場合があります。第一が、Cache-Controlヘッダの誤りです。これは「このファイルをどれだけの期間キャッシュしてよいか」をサーバーが宣言する指示で、これが no-store や max-age=0 になっていると、CDNは写しを持てず毎回オリジンに取りに行きます。画像のように内容が変わらないファイルは、本来 max-age を長く取り、immutable(変わらない)を付けて恒久的にキャッシュさせるべきものです。

第二が、キャッシュを無駄に分裂させる設計です。画像URLの末尾に ?v=時刻 のようなクエリ文字列を毎回変えて付けていると、CDNはそれを別々のファイルと見なし、同じ画像なのに写しを共有できません。Varyヘッダも同じ罠で、Vary: Accept-Encoding までは妥当ですが、Cookieや利用者の端末ごとにVaryを付けていると、利用者の数だけキャッシュが枝分かれし、ヒット率が構造的に上がらなくなります。

こうした配信の粗さは、コードのバグのように目立たないぶん、技術的負債として静かに積み上がります。買い手から見れば値引き交渉の材料になり、売り手から見れば知らないうちに評価を下げている項目です。負債がどう査定に効くかはSaaS売却で値引きされる技術的負債で整理しています。

動画は別次元の帯域 ── オートプレイと無変換配信

動画は別次元の帯域 ── オートプレイと無変換配信

画像で桁が一つ変わるなら、動画では桁が二つ変わります。動画は1本で数十MBから数GBに達し、しかも配信設計の粗さが画像以上に効きます。起こりやすいのが、トップページに置いた紹介動画をオートプレイ(自動再生)にしている構成です。訪問者全員が、再生する気がなくても動画の読み込みを始めてしまい、その全員分の転送が発生します。

もう一つが無変換配信です。撮影した高解像度の動画を、そのままの1本のファイルとして配っている状態を指します。本来は、回線や画面に応じて画質を切り替えるアダプティブ配信(HLSなど、動画を細切れにして必要な画質だけ送る方式)に変換しておくべきものです。無変換だと、スマートフォンで見ている利用者にも4K相当の全データを送りつけることになり、帯域も体感速度も両方を損ないます。

DDで動画を扱う事業を見るときは、動画がどこから配信されているか(自前ストレージか、YouTube等の外部か)を必ず確認します。外部に載せていれば転送費は事業者にかかりませんが、その分だけ外部への依存が生まれます。自前配信なら安いように見えて、無変換・オートプレイのまま流していると、請求書の転送費を一気に押し上げている主犯になっている場合があります。

DDで請求書のどこを見るか ── 転送量・ヒット率・平均サイズの三点測定

DDで請求書のどこを見るか ── 転送量・ヒット率・平均サイズの三点測定

配信の粗さを定量化するには、三つの数字を測ります。一つ目が月間の転送量です。クラウドの明細で DataTransfer-Out にあたる項目を抜き出し、それが売上に対して何パーセントかを出します。二つ目がキャッシュヒット率。CDNの管理画面に必ず出ている数字で、90%を大きく下回っていれば、それだけで改善余地があると判断できます。

三つ目が平均オブジェクトサイズです。総転送バイト数を総リクエスト数で割るだけで出ます。これが数MB台なら無最適化、数百KB以下なら最適化済み、と当たりがつきます。この三点に加えて、実際の画像URLを curl -I で叩き、返ってくる Content-Type(形式)・Content-Length(サイズ)・Cache-Control(キャッシュ指示)・そしてCDNのキャッシュ状態を示すヘッダ(cf-cache-status や x-cache)を一枚ずつ確かめます。数字の裏を、実物の一枚で裏取りするわけです。

この三点測定から、改善後の姿を逆算します。平均サイズを最適化で3分の1に、ヒット率を95%に引き上げたと仮定すると、転送量がどこまで落ち、原価がいくら軽くなるかがラフに見積もれます。それが、この事業に眠っている原価改善余地です。契約後にこの設定変更を実際に反映していく作業は、引き渡し後の移管の一部として現れます。移管全般で何が起きるかはアプリ売却の事例が語らない移管作業で扱っています。

「帯域が増えた=成長」という誤読が改善を止める

「帯域が増えた=成長」という誤読が改善を止める

配信の粗さが放置される最大の理由は、心理的なものです。アクセスが伸びて請求書の転送費が増えると、事業者はそれを「成長のコスト」と解釈します。売れているから配信も増えている、当然の出費だ、と。この解釈は半分正しく、半分が改善を止めます。増えた分のうち、どこまでが本当に必要な配信で、どこからが最適化を怠った無駄なのかを、分けて見ていないからです。

帯域は成長に比例するべき変数ではありません。最適化された事業では、アクセスが2倍になっても転送費は2倍より緩やかにしか増えません。キャッシュが効くほど、リピート訪問や人気コンテンツの配信はオリジンを介さず捌かれるからです。逆に粗い設計では、アクセスに転送費がほぼ線形で張り付き、成長がそのまま原価の膨張になります。成長を喜ぶほど粗利率が下がっていく事業は、この線形の罠にはまっています。

この誤読は引き渡し後にも尾を引きます。買い手が施策でアクセスを伸ばした瞬間、粗い配信設計は倍返しで請求書を膨らませ、想定していた粗利が出ない。売買の失敗が引き渡し後に始まる典型のひとつで、その構造はサイト売買の失敗は引き渡し後に始まるでも触れています。買う前に配信の伸び方の質を見ておかないと、成長そのものが負債になります。

原価改善余地は「値付けの余白」に変わる ── 売り手の見落とし、買い手の伸びしろ

原価改善余地は「値付けの余白」に変わる ── 売り手の見落とし、買い手の伸びしろ

事業の値段は、多くの場合、利益に一定の倍率を掛けて決まります。だからこそ粗利を数ポイント動かす要素は、掛け算の手前の数字を動かし、評価額そのものを動かします。配信を最適化して原価が軽くなれば、その分だけ利益が増え、同じ倍率でも値段が上がる。逆に粗いまま売れば、下がった粗利率で評価された値段で手放すことになります。

売り手にとって、これは売ると決める前に閉じておける余白です。画像の最適化とキャッシュ設定は、事業の中身を変えずに粗利率だけを上げられる、数少ない打ち手です。時間をかけて数字を整えてから査定に臨めば、同じ事業がより高く評価されます。買い手にとっては逆で、粗い配信は「買った後に自分で刈り取れる伸びしろ」です。売り手が見落としている原価を、値付けの段階で織り込んで交渉できます。

どちらの立場でも、鍵になるのは損益計算書の粗利率をそのまま信じないことです。その数字の下に、削れる原価がまだ残っているのか、それとも既に絞り切られているのか。請求明細とCDNの管理画面、そして実物の画像一枚を突き合わせれば、静かに削られている粗利の正体は、設計の粗さとして姿を現すことがあります。

配信設計が粗利をどれだけ削っているか、買う前・売る前に一度可視化しておきたいときは、AI技術デューデリジェンスで、転送量やキャッシュ効率を含めたコスト構造の見立てを確認できます(登録不要)。

この記事の著者

黒沢 大輔

株式会社studio C 代表取締役

これまで4回の事業譲渡を実現。上場企業にてエンジニア、制作ディレクション、SEO事業立ち上げを歴任。副業で始めた複数の掲示板サイトを国内最大規模まで成長させて事業譲渡。日本のM&Aに透明性と精度をもたらすべく、デジタル事業のM&Aプラットフォーム『RIKKA M&A』を立ち上げ。