当たり前なのではというはてぶが多かったので、画像のファイルフォーマット毎の差異もまとめてみました。

Web APIでJPG画像を送信する際、「バイナリ送信(multipart/form-data)で送るか」「Base64エンコードしてJSONに埋め込むか」で迷うこと、あると思います。

例) multipart/form-data で画像データと、付属パラメータを一緒に送信するサンプル

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----boundary123

------boundary123
Content-Disposition: form-data; name="user_id"

12345
------boundary123
Content-Disposition: form-data; name="resize"
Content-Type: application/json

{"width":800,"height":600}
------boundary123
Content-Disposition: form-data; name="image"; filename="photo.jpg"
Content-Type: image/jpeg

<binary jpg data>
------boundary123--

例) 画像データをBase64エンコードして、付属パラメータと一緒にJSONとして送信するサンプル

POST /upload HTTP/1.1
Content-Type: application/json
Content-Encoding: gzip

{
  "user_id": "12345",
  "resize": {
    "width": 800,
    "height": 600
  },
  "image": {
    "filename": "photo.jpg",
    "content_type": "image/jpeg",
    "data": "4AAQSkZJRgABAQAAAQABAAD..."
  }
}

この場合、クライアントの HTTP圧縮（Gzip/Brotli) も有効化されることが多いでしょう。

実例として、GoogleのVirtual Try-On APIが、画像データをBase64エンコードして、JSONとして送信する実装をしています。

一見すると 「Base64にするとデータサイズが約1.33倍に増えるから、パフォーマンス的に不利である」 ように感じます。

しかし、実際に検証してみると、 「HTTP圧縮（Gzip/Brotli）を有効にしていれば、Base64の増加分はほぼキャンセルされ、バイナリ転送と変わらないサイズになる」 という結果になります。

なぜ、JPG画像に対して、base64エンコードをした後に圧縮をするとサイズが元に戻るのでしょうか？
この記事では、この現象を 情報理論（エントロピーと冗長性） の観点から解説します。

結論

通信量（転送サイズ）:
HTTP圧縮（Gzip等）が有効な環境下では、Base64送信とバイナリ送信の転送サイズに大きな差はない。Base64の増加分は圧縮によって回収される。
CPU・メモリコスト:
サイズは同じでも、Base64方式はエンコード・デコード・圧縮・展開のプロセスが増えるため、CPU負荷とメモリ消費量は高くなる。

謎：なぜJPG画像のBase64文字列がGzipで縮むのか？

一般的に、JPGやPNGなどの画像ファイルは既に高度に圧縮されており、これ以上Gzipをかけてもサイズは減らない（むしろヘッダ分で微増する）と言われています。

しかし、これをBase64エンコードしたテキストデータに対してGzipをかけると、劇的にサイズが減り、元のバイナリサイズとほぼ同じになります。

直感的な疑問

「Base64にすると、ランダムな英数字の羅列になる。ランダムなデータは圧縮が効きにくいのでは？」

答え

Base64の文字列は、人間にはランダムに見えますが、コンピュータ（圧縮アルゴリズム）から見ると「スカスカ（冗長）」なデータだからです。

情報理論による解説

この現象は、エントロピー（平均情報量）とハフマン符号化の仕組みで説明がつきます。

1. 「33%増加」の正体は「冗長性」

元のJPGバイナリデータは、圧縮済みであるためエントロピー（情報の密度）が非常に高い状態です。1バイト（8bit）の中に、ほぼ8bit分の情報が詰まっています。

これをBase64に変換すると、データサイズは4/3倍（約133%）になります。しかし、元の画像が持っている情報の総量は変わりません。
単純に、「情報量が変わらないまま、容器だけが大きくなった」状態です。

バイナリ: 0〜255の256種類 = 8bit の値をフルに使う。
Base64: 8bitの器（ASCIIコード）を使っているが、実際に出てくる文字は A-Z, a-z, 0-9, +, / の64種類 = 6bit しかない。

つまり、Base64のデータは 「1バイトにつき2bit分の『無駄（冗長性）』を含んでいる」 ことになります。

この「2bitの隙間」が、ファイルサイズを33%押し上げている犯人です。

2. ハフマン符号が「隙間」を回収する

Gzip（Deflateアルゴリズム）の後半工程では、ハフマン符号化が行われます。これは「出現頻度の高い文字に短いビット列を割り当てる」仕組みです。

Base64データをGzipに入力すると、ハフマン符号器は極端な「文字の出現頻度の偏り」を検知します。

使われない約190種類の記号: 出現率 0%
使われる64種類の記号: 出現率 100%

情報理論の定理に基づき、64種類の記号しか現れないデータソースは、1文字あたり平均 6 bit で表現可能です。ハフマン符号は、Base64化によって人工的に引き伸ばされた「8bit表現」を、本来の「6bit表現」に再圧縮して詰め直します。

3. 計算上の収支

サイズの変化を計算式で追うと、見事に「行って来い（プラスマイナスゼロ）」になります。

１. 元データ

バイナリ
データ量: 3 MB

２. Base64エンコード (6bitずつに分割して8bitのASCII文字にする)

文字
データ量: 4 MB (ここで33%増加)

３. Gzip圧縮 (偏りを利用して1文字を6bitに詰め直す)

バイナリ
データ量: 3 MB (ここで元に戻る)

これが、Base64画像を圧縮すると元のバイナリサイズに戻るカラクリです。
画像の「中身」を圧縮しているのではなく、Base64という「形式」が持っている無駄を削ぎ落としているだけなのです。

4. 本当に理論通りの結果になるのか実験

こちらの画像を使って理論通りになるのかを実験してみます。

まず、元データのサイズは234KBです。

cat shikun20220402_125829_TP_V.jpg | wc -c
  234186

base64エンコードをすると、データ量が33%増加します。

cat shikun20220402_125829_TP_V.jpg | base64 | wc -c
  312249

そして、その後にgzip圧縮をすると、ほぼ元通りの235KBになっていることが分かります。

cat shikun20220402_125829_TP_V.jpg | base64 | gzip | wc -c
  235393

結局、どっちを採用すべきか？

「通信量が変わらないなら、JSONの方が扱いやすい ≒ Base64 でいいのでは？」と思う方もいるかもしれませんが、その場合 CPUとメモリ という隠れたコストが存在します。

Base64 (JSON埋め込み)

メリット:

リクエストが1つのJSONで完結するため、フロントエンドの実装がシンプル。

デメリット:

CPU負荷: Bin -> Base64 (Client) -> Gzip (Client) -> Gunzip (Server) -> Base64 -> Bin (Server) という変換コストがかかる。
メモリ効率: Base64文字列の生成やJSONパース時に、バイナリサイズの数倍のメモリを消費することがある。

バイナリ送信 (multipart/form-data)

メリット:

CPU負荷: エンコード/デコード処理が不要。右から左へ流すだけ。
メモリ効率: ストリーム処理がしやすく、巨大なファイルでもメモリを圧迫しにくい。

デメリット:

JSONデータと同時に送る場合、multipart/form-data の構築が少し面倒（メタデータはJSON文字列としてパートに含めるなど）。

まとめ

Base64によるサイズ増加（約33%）は、HTTP圧縮によってほぼ帳消しにできる。
したがって、帯域幅（通信速度）だけを理由にBase64を避ける必要はない。
ただし、CPUリソースとメモリ消費の観点ではバイナリ送信（multipart/form-data）が有利。

「Base64は重い」という常識は、半分正解で半分間違いでした。ネットワーク的には重くないが、計算資源的には重い。この特性を理解してアーキテクチャを選定しましょう。