🔖 キーワード索引

別名・略称：（なし）

🔖 詳細キーワード索引

🎨 直感で掴む

🎨 直感で掴む（深掘り）

圧縮を一言で言えば「パターンを見つけて短く書く」。 「AAAAA」と書く代わりに「A×5」と書けば短くなる、 という発想です。

日本語にも例えれば「あいうえおあいうえおあいうえお」を「[あいうえお]×3」と表現できる。 アルゴリズムごとに「どんなパターンを探すか」が異なります：

• LZ77 系（gzip, zstd）：前出の同じ文字列を「○○行前の□□文字」とポインタで表現
• Huffman 符号：頻繁な文字には短い符号、 稀な文字には長い符号を割り当て
• BWT（bzip2）：文字列を並べ替えて圧縮しやすい形に変換
• 算術符号：1 ストリームを 1 つの小数として表現
• 変換符号（JPEG）：人間の目に分からない高周波成分を捨てる

📐 定義 / 数式

📐 情報理論的限界（Shannon エントロピー）

どんなに優れた可逆圧縮でも、 Shannon エントロピー以下にはできません。 確率分布 $p(x)$ を持つ情報源の理論的下限：

$$ H(X) = -\sum_i p_i \log_2 p_i \quad [\text{bits/symbol}] $$

例：8 ビット文字でも、 ASCII 英文の実効エントロピーは約 4.7 bit/char。 つまり理論上 1.7 倍圧縮できる。 実際の gzip でも 2〜3 倍程度に収まります。

乱数や既に圧縮されたデータはエントロピーが高く、 さらなる圧縮はほぼ不可能。 「圧縮できる」＝「データに冗長性がある」ということです。

📖 事例：センサーデータの圧縮戦略

工場で 1 kHz の振動センサーが 100 台稼働する場合、 1 日 8.64 億行。 CSV のままなら 30 GB／日、 月 1 TB。

• 差分符号化：隣接時刻の差を保存 → 値の幅が縮小
• 列指向化（Parquet）：時刻列とセンサー値列で別圧縮
• zstd レベル 3：適度な圧縮率と高速デコード
• 結果：30 GB → 約 1.5 GB／日（20 倍圧縮）
• 月コスト：S3 で約 30 ドル、 1 年で 360 ドル → 元の数百分の一

📜 歴史

• 1948 年：Shannon の情報理論、 エントロピーの概念
• 1952 年：Huffman 符号化、 可変長符号
• 1977 年：LZ77（Lempel-Ziv）アルゴリズム、 後の gzip の基礎
• 1992 年：JPEG 標準化、 不可逆画像圧縮
• 1996 年：bzip2、 ブロックソート＋Huffman
• 1998 年：LZMA、 7-Zip / xz の基礎
• 2011 年：Google snappy、 速さ重視
• 2016 年：Facebook zstd、 速さと圧縮率を両立
• 2020 年代：列指向（Parquet, Arrow）＋zstd が主流

❓ よくある質問

📐 各圧縮アルゴリズムの仕組み

1. Huffman 符号 — 出現頻度に応じた可変長符号

頻出する文字には短い bit 列、 稀な文字には長い bit 列を割り当てる。 平均符号長 L は：

$$ L = \sum_i p_i \cdot \ell_i, \qquad H(X) \leq L < H(X) + 1 $$

数式を言葉で読み解く：平均符号長 L は、 Shannon エントロピー H(X) 以上、 H(X)+1 未満。 最適な符号長は文字頻度の負の対数 $-\log_2 p_i$ に近い。

2. LZ77 — 過去のパターンを参照

「N バイト前の M バイトをコピー」というポインタで繰返しを表現。 例：「ABABAB」→ 「AB」+「2 バイト前から 4 バイトコピー」。 gzip / DEFLATE はこの方式と Huffman の組み合わせ。

3. Burrows-Wheeler 変換 (BWT) — 並べ替えてから符号化

文字列を回転させて辞書順ソートし、 末尾文字列だけ取り出す。 同じ文字が隣り合いやすくなり、 後続の Move-to-Front + Huffman で圧縮率向上。 bzip2 の核心。

4. LZMA — 大きな辞書 + 範囲符号化

LZ77 の発展形。 辞書サイズが数 MB と大きく、 範囲符号化（算術符号化に類似）で各シンボルを実数値で表現。 xz / 7z で使用、 最高圧縮率と引き換えに展開も低速。

5. Snappy / LZ4 / Zstd — 速度優先

Google Snappy、 Facebook Zstandard、 Yann Collet の LZ4 は「圧縮率より展開速度」を優先する現代的圧縮。 Parquet / Avro / Hadoop / Kafka の標準として広く使われる。

🐍 Python 実装 #B1: Huffman 符号の手動構築

🎯 このコードでやること：SSDSE データのバイト頻度から Huffman 木を構築し、 各バイトの符号長を表示。

📥 入力データ：csv_bytes の各バイトの頻度カウント。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import collections
import heapq

# ── この抜粋だけで動くように、圧縮の対象になるバイト列を読み込む ──
# SSDSE-B-2026.csv をそのままバイト列として扱う（約 36 万バイト）
with open('data/raw/SSDSE-B-2026.csv', 'rb') as _f:
    csv_bytes = _f.read()
total = len(csv_bytes)
print(f'対象データ: {total:,} バイト')

freq = collections.Counter(csv_bytes)
heap = [[w, [byte, '']] for byte, w in freq.items()]
heapq.heapify(heap)

while len(heap) > 1:
    lo = heapq.heappop(heap)
    hi = heapq.heappop(heap)
    for pair in lo[1:]: pair[1] = '0' + pair[1]
    for pair in hi[1:]: pair[1] = '1' + pair[1]
    heapq.heappush(heap, [lo[0]+hi[0]] + lo[1:] + hi[1:])

codes = sorted(heap[0][1:], key=lambda x: (len(x[1]), x[0]))
print('頻出 10 バイトの Huffman 符号:')
for byte, code in codes[:10]:
    try: ch = chr(byte) if 32 <= byte < 127 else f'\\x{byte:02x}'
    except: ch = '?'
    print(f"  '{ch}' ({byte:>3}): freq={freq[byte]:>6}, code='{code}' ({len(code)} bits)")

avg_len = sum(freq[b]*len(c) for b,c in codes) / total
print(f'\n平均符号長: {avg_len:.3f} bits/byte')

📤 実行結果（イメージ）：

💬 結果の読み方：「0」「,」「2」など SSDSE で頻出する数字記号には 3-4 bit の短い符号。 Huffman の平均符号長 3.60 は Shannon 下限 3.57 のわずか 1% 上 → ほぼ最適。

📐 Shannon エントロピー — 圧縮の理論限界

離散確率変数 $X$ について、 出力の不確実性を測る Shannon エントロピー：

$$ H(X) = -\sum_{i=1}^{n} p_i \log_2 p_i \quad \text{[bit/symbol]} $$

数式を言葉で読み解く：各シンボルの確率に「自身の負の対数」を掛けて足す。 確率が小さい（稀な）シンボルほど $-\log p$ は大きく、 確率 1/2 のシンボルは 1 bit 寄与する。

エントロピーの直感

• 全シンボルが等確率：H は最大 = $\log_2 n$。 ランダムバイト列は H=8。
• 1 つだけ確率 1、 他 0：H = 0。 完全に予測可能、 圧縮で 0 bit に。
• SSDSE-B-2026 (実測)：H ≈ 3.57 bit/byte。 つまり「平均 3.57 bit / バイト」あれば情報を保持できる。

Shannon の情報源符号化定理

ある情報源を可逆に符号化したとき、 平均符号長 $L$ は次を満たす：

$$ L \geq H(X) $$

つまり、 H(X) 未満には圧縮できない。 これが圧縮の理論的下限。 Huffman 符号は $L < H(X) + 1$ で「ほぼ最適」。

条件付きエントロピーとマルコフ情報源

「前のシンボルが分かっているとき」の不確実性：

$$ H(X_t \mid X_{t-1}) = -\sum_{i,j} p(x_i, x_j) \log_2 p(x_i \mid x_j) $$

数式を言葉で読み解く：直前のシンボルを観測した後の不確実性の平均。 通常 $H(X_t \mid X_{t-1}) \leq H(X_t)$ で、 「予測可能性が高い」テキストや CSV は条件付きエントロピーが大きく下がる。 LZ77 / LZMA はこれを活用。

🐍 Python 実装 #D1: マルコフ条件付きエントロピー

🎯 このコードでやること：SSDSE データのバイト列を 2 グラム（連続 2 バイト）の頻度から条件付きエントロピー H(X|X_prev) を計算し、 単純な H(X) と比較。

📥 入力データ：csv_bytes (358,876 bytes)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

from collections import Counter
import math

# 単純 H(X)
c1 = Counter(csv_bytes)
N = len(csv_bytes)
H1 = -sum((c/N)*math.log2(c/N) for c in c1.values())

# 2-gram 頻度
c2 = Counter(zip(csv_bytes[:-1], csv_bytes[1:]))
N2 = sum(c2.values())

# 条件付き H(X_t | X_{t-1})
prev = Counter(csv_bytes[:-1])
H_cond = 0
for (a,b), n_ab in c2.items():
    p_ab = n_ab / N2
    p_a  = prev[a] / N2
    H_cond -= p_ab * math.log2(n_ab/prev[a])

print(f'H(X)         = {H1:.3f} bit/byte')
print(f'H(X|X_prev)  = {H_cond:.3f} bit/byte')
print(f'削減量       = {H1-H_cond:.3f} bit/byte')

📤 実行結果：

💬 結果の読み方：直前 1 バイトが分かれば、 不確実性が 3.57 → 3.20 と約 10% 削減。 SSDSE のテキストには「カンマの後は数字」「改行の後は数字」など強いパターンがあるため。 LZMA はさらに数百〜数千バイトの文脈を使うため、 Shannon 1 階下限を下回る。

📐 数式を言葉で読み解く — 主要関係式

情報量の定義（自己情報）

$$ I(x) = -\log_2 p(x) \quad \text{[bit]} $$

数式を言葉で読み解く：確率 p の事象が起きたときの「驚き」を bit で表す。 p=1/2 なら 1 bit、 p=1/256 なら 8 bit。 確率が小さい（稀な）事象ほど情報量が多い。

相互情報量（mutual information）

$$ I(X;Y) = \sum_{x,y} p(x,y) \log_2 \frac{p(x,y)}{p(x)p(y)} $$

数式を言葉で読み解く：X と Y が独立なら 0、 強く相関するほど大きい。 圧縮では「シンボル間の依存」をどれだけ活用できるかの上限を与える。

符号長の上限と Kraft 不等式

前置符号（prefix code）の符号長 $\ell_i$ は次を満たす：

$$ \sum_{i=1}^{n} 2^{-\ell_i} \leq 1 $$

数式を言葉で読み解く：各符号語の「占める空間」を 2 進木で見ると、 合計が 1 を超えてはいけない。 Huffman 符号はこの制約下で平均符号長を最小化する。

レート歪み関数（lossy 圧縮の理論）

$$ R(D) = \min_{p(y|x): E[d(X,Y)] \leq D} I(X;Y) $$

数式を言葉で読み解く：許容歪み D 以下で送るのに必要な最小ビット数 R(D)。 D=0 のとき R(0) = H(X)（lossless と一致）。 D 増えれば R 減る。 JPEG や MP3 はこの理論の応用。

コルモゴロフ複雑性（理論的究極）

$$ K(x) = \min \{ |p| : U(p) = x \} $$

数式を言葉で読み解く：万能チューリング機械 U に与えれば x を出力する最短プログラム p の長さ。 実用上計算不可能だが、 「データの本質的非冗長性」の理論的指標。 lossless 圧縮はこの近似を試みている。

🔬 記号・式を言葉で読み解く

可逆圧縮

完全に元に戻せる。 テキスト・プログラム・数値データ用。

非可逆圧縮

完全には戻せないが、 知覚的に問題ない範囲で大幅圧縮。 画像/音声/動画用。

Huffman 符号

出現頻度の高い記号に短い符号を割り当てる古典手法。

辞書式（LZ77/LZ78）

繰り返しパターンを「ここまで戻って何文字コピー」と表現。 gzip 内部で使用。

カラムナ形式

Parquet/ORC。 列毎にデータ型と分布が一様 → 圧縮率が良い。

🔬 専門用語の解説

🎯 圧縮の設計指針（決定木）

1. 用途は？ ── 分析（読み多）／アーカイブ（保存多）／転送（速度重視）
2. 分析なら ── 列指向必須（Parquet/ORC）、 圧縮は snappy or zstd（速）
3. アーカイブなら ── 圧縮率重視、 xz / brotli / zstd level 19 等
4. 転送なら ── lz4 / snappy（CPU負荷小）、 ネットワーク 1 GbE 未満なら zstd
5. 更新が多いなら ── 列指向は不向き、 行指向（Avro）も検討
6. SQL/BI で頻繁にクエリ ── Parquet＋パーティション＋snappy が王道
7. ストリーミング ── 行指向 Avro＋snappy がKafka 連携で便利

📊 圧縮ベンチマーク参考値

SSDSE-B 程度の表形式データを各方式で圧縮した場合の代表的な数値（実測値は環境依存）：

🛠 主要な圧縮アルゴリズム

圧縮は 可逆（lossless） と 不可逆（lossy） に大別されます。 データサイエンスでは可逆が基本：

2025 年現在、 大量データのデフォルトは Parquet + zstd または Parquet + snappy。 zstd は近年急速にシェア拡大。

📊 列指向ストレージと圧縮の相乗効果

分析データは 列指向（columnar） 形式で保存すると圧縮率が劇的に向上します。 同じ列に並ぶ値は型と分布が似ているため、 アルゴリズムが効きやすくなるからです。

$$ \text{圧縮率} = \frac{\text{元サイズ}}{\text{圧縮後サイズ}} $$

🔬 SSDSE-B-2026 を実際に圧縮して比較

SSDSE-B-2026 の生 CSV (約 359 KB) を、 gzip / bz2 / xz / Parquet の各形式で圧縮し、 サイズと展開時間を比較します。 「lossless 圧縮」の実態を体感するのが目的。

🧮 圧縮率の比較表（実測値）

観察：xz が最も圧縮率高（35.7%）、 Shannon 限界（44.6%）すら下回るのは「バイト単位でなく長い文字列の繰り返しを使う」LZMA の利点。 Parquet (snappy) は CSV より大きい（メタデータ + 列ごとのオーバーヘッド）が、 多数列・大規模なデータでは大幅に効くようになる。

🐍 Python 実装 #A1: 各種圧縮を実測

🎯 このコードでやること：SSDSE-B-2026 を読み、 gzip / bz2 / xz のメモリ内圧縮サイズを直接計測。

📥 入力データ：SSDSE-B-2026.csv (約 359 KB)、 564 行 × 112 列。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import pandas as pd
import gzip, bz2, lzma, os

df = pd.read_csv('data/raw/SSDSE-B-2026.csv',
                 encoding='cp932', skiprows=[1])
csv_bytes = df.to_csv(index=False).encode('utf-8')
orig = len(csv_bytes)

print(f'CSV (utf-8 in mem): {orig:>9,} bytes (100.0%)')
for name, fn in [('gzip', gzip.compress),
                  ('bz2', bz2.compress),
                  ('xz',  lzma.compress)]:
    comp = fn(csv_bytes)
    print(f'{name:>4}: {len(comp):>9,} bytes ({len(comp)/orig*100:5.1f}%)')

# raw file on disk
disk = os.path.getsize('data/raw/SSDSE-B-2026.csv')
print(f'\n元ファイル (cp932): {disk:,} bytes')

📤 実行結果：

💬 結果の読み方：xz は元の 3 割未満に圧縮。 SSDSE のような構造化数値テキストは、 列ヘッダの繰返し・整数の桁集中・空白パターンが多いため、 圧縮効率が高い。 一方、 ランダムバイト列ならどの圧縮も 95% 程度までしか小さくならない。

🐍 Python 実装 #A2: Shannon エントロピー

🎯 このコードでやること：バイト単位の出現頻度から Shannon エントロピー（bit/byte）を計算し、 「理論最小圧縮サイズ」を導く。

📥 入力データ：先ほどの csv_bytes（utf-8 でエンコードしたバイト列、 358,876 bytes）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import collections, math

counts = collections.Counter(csv_bytes)
total = len(csv_bytes)
entropy = -sum((c/total) * math.log2(c/total)
               for c in counts.values())

print(f'Shannon entropy = {entropy:.3f} bits/byte')
print(f'(理論上は最大 8.0 bits/byte = 完全ランダム)')
print(f'理論最小サイズ = {entropy * total / 8:,.0f} bytes')
print(f'実 gzip サイズ = 158,033 bytes')
print(f'実 xz サイズ   = 128,276 bytes (Shannon を下回る！)')

📤 実行結果：

💬 結果の読み方：Shannon 限界（159,902 bytes）はあくまで「バイト単位の独立同分布」を仮定した下限。 xz は「複数バイトの繰り返しパターン」を辞書化してエントロピーを下げるため、 この限界を 下回ることが可能。 gzip は限界とほぼ同じ（159K vs 158K）。

🧮 実データで計算してみる

🧮 SSDSE 12 年パネルの圧縮戦略

SSDSE-B-2026 は 2012-2023 の 12 年分（564 行 = 47 県 × 12 年）。 全体を一度に保存するか、 年ごとに分割するかで圧縮効率が変わります。

🐍 Python 実装 #F1: 単一ファイル vs 分割保存

🎯 このコードでやること：SSDSE 全体を 1 ファイルに保存した場合と、 年ごとに 12 ファイルに分けて保存した場合の合計サイズを比較。

📥 入力データ：df 全件（564 行 × 112 列）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

import io, gzip
import pandas as pd

all_df = pd.read_csv('data/raw/SSDSE-B-2026.csv',
                     encoding='cp932', skiprows=[1])

# 単一ファイル
buf_one = io.BytesIO()
all_df.to_csv(buf_one, index=False)
one_size = len(gzip.compress(buf_one.getvalue()))
print(f'単一 CSV gzip: {one_size:,} bytes')

# 年ごとに 12 個に分割
total_split = 0
for year in sorted(all_df['SSDSE-B-2026'].unique()):
    yr = all_df[all_df['SSDSE-B-2026']==year]
    buf = io.BytesIO()
    yr.to_csv(buf, index=False)
    sz = len(gzip.compress(buf.getvalue()))
    total_split += sz
print(f'年別 12 CSV gzip 合計: {total_split:,} bytes')
print(f'差: {total_split - one_size:+,} bytes')

📤 実行結果（イメージ）：

💬 結果の読み方：分割すると圧縮効率が悪化（+25%）。 各ファイルが独自にヘッダ・辞書を持つため。 ただし「特定年だけ高速にアクセスしたい」なら分割が有利。 トレードオフ：圧縮率 vs アクセス性能。 多年データは Parquet パーティション (year=YYYY) が最適。

🐍 Python 実装 #F2: Parquet パーティション

🎯 このコードでやること：年ごとにパーティション化した Parquet を作成し、 特定年だけ高速読込できることを示す。

📥 入力データ：all_df 全件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import os
os.makedirs('out', exist_ok=True)   # 書き出し先を先に作る
import os, glob
import pandas as pd
import pyarrow            # Parquet の読み書きに必要（ブラウザ版 Python には入っていない）

all_df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])

# パーティション化保存
# to_parquet(partition_cols=...) は既存ディレクトリに *追記* する。
# 消さずに再実行するとファイルも行数も増え続けるので、毎回作り直す。
import shutil
shutil.rmtree('out/ssdse', ignore_errors=True)
all_df.to_parquet('out/ssdse', partition_cols=['SSDSE-B-2026'],
                  compression='zstd')

# 2023 年だけ読込（filter で高速化）
yr2023 = pd.read_parquet('out/ssdse',
                          filters=[('SSDSE-B-2026','=',2023)])
print(f'2023 年だけ: {len(yr2023)} 行')

# ファイル一覧
files = sorted(glob.glob('out/ssdse/**/*.parquet', recursive=True))
total = sum(os.path.getsize(f) for f in files)
print(f'\n総ファイル数: {len(files)}')
print(f'総サイズ: {total:,} bytes')

📤 実行結果（イメージ）：

💬 結果の読み方：Parquet パーティションは年単位でファイルが分かれ、 filter 指定で必要パーティションだけ読み込む。 12 年データなら 1/12 の I/O で済む。 大規模データ（数十億行）では必須の最適化技法。

🧮 数式に値を入れて手で計算する: 圧縮率と節約容量

合成データで元 100MB → 各圧縮形式の節約容量を計算する。

Step 1: 形式別圧縮率

Step 2: 最良形式

🐍 Python で再現

1
2
3
4
5
6
7
8

import numpy as np
orig = 100
comp = np.array([30, 22, 18, 27])
save = orig - comp
ratio = comp / orig
print(f"圧縮率: {ratio}")
print(f"節約: {save} MB")
print(f"最良 index: {save.argmax()} ({save.max()} MB)")

📤 実行結果

💬 手計算 (Step 2) xz 82MB と Python 出力が完全一致。

🐍 Python 実装

SSDSE-B-2026（47 都道府県・2023 年データ）を題材にした最小コード：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

import os
os.makedirs('data', exist_ok=True)   # 書き出し先を先に作る
import os
import pandas as pd
import pyarrow            # Parquet の読み書きに必要（ブラウザ版 Python には入っていない）

os.makedirs('data/processed', exist_ok=True)   # 保存先が無いと書き込みは失敗する

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=1)

# gzip 圧縮で保存
df.to_csv('data/processed/ssdse.csv.gz', index=False, compression='gzip')

# Parquet（Snappy 圧縮、 デフォルト）
df.to_parquet('data/processed/ssdse.parquet', index=False)

# Parquet + Zstd（より高圧縮）
df.to_parquet('data/processed/ssdse_zstd.parquet', compression='zstd')

for _f in ('ssdse.csv.gz', 'ssdse.parquet', 'ssdse_zstd.parquet'):
    print(f'{_f:22s} {os.path.getsize("data/processed/" + _f):>10,} bytes')

🐍 Python 実装（パフォーマンス比較）

(1) 各圧縮方式の比較：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

import pandas as pd
import os, time
import pyarrow            # Parquet の読み書きに必要（ブラウザ版 Python には入っていない）

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=1)

for comp in ['snappy', 'gzip', 'brotli', 'zstd', 'lz4']:
    t = time.time()
    df.to_parquet(f'/tmp/test_{comp}.parquet', compression=comp)
    sz = os.path.getsize(f'/tmp/test_{comp}.parquet')
    print(f'{comp}: {sz/1024:.1f} KB, {time.time()-t:.2f}s')

(2) DataFrame の dtype 最適化で圧縮率を上げる：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# ── この抜粋で使うデータを用意します（SSDSE-B の 47 都道府県・最新年度）──
import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', header=1)
df = df[df['地域コード'].astype(str).str.match(r'^R\d{5}$', na=False)].copy()
df['年度'] = pd.to_numeric(df['年度'], errors='coerce')
df = df[df['年度'] == df['年度'].max()]
for _c in df.columns[3:]:
    df[_c] = pd.to_numeric(df[_c], errors='coerce')
df['高齢化率'] = df['65歳以上人口'] / df['総人口'] * 100

# 見本でよく使われる仮の列名を、実データから作っておく
df['income'] = df['消費支出（二人以上の世帯）']
df['population'] = df['総人口']
_region = {'北海道': '北海道', '青森県': '東北', '岩手県': '東北', '宮城県': '東北',
           '秋田県': '東北', '山形県': '東北', '福島県': '東北', '茨城県': '関東',
           '栃木県': '関東', '群馬県': '関東', '埼玉県': '関東', '千葉県': '関東',
           '東京都': '関東', '神奈川県': '関東'}
df['region'] = df['都道府県'].map(_region).fillna('その他')
df['地域'] = df['region']

import numpy as np

# int64 を int32 へ
df['総人口'] = df['総人口'].astype('int32')

# object → category
df['都道府県'] = df['都道府県'].astype('category')

# float64 を float32 へ（精度が許せば）
df['高齢化率'] = df['高齢化率'].astype('float32')

print('メモリ使用量:', df.memory_usage(deep=True).sum() / 1024, 'KB')

(3) ストリーミング圧縮（巨大ファイルでメモリ節約）：

1
2
3
4
5
6
7
8
9

import gzip, shutil

# 大きな CSV を gzip 圧縮
with open('large.csv', 'rb') as f_in:
    with gzip.open('large.csv.gz', 'wb', compresslevel=6) as f_out:
        shutil.copyfileobj(f_in, f_out)

# pandas で直接読める
df = pd.read_csv('large.csv.gz', encoding='utf-8')

⚠️ よくある落とし穴

⚠️ 落とし穴（さらに）

⚠️ Lossless vs Lossy — どちらを選ぶか

Lossless（可逆圧縮）

• 用途：テキスト、 ソースコード、 CSV、 医療画像、 金融データ、 公文書
• 代表：gzip / bz2 / xz / Brotli / Zstandard、 PNG / FLAC
• 原則：1 ビットも失わず復元可能
• SSDSE-B-2026 のような統計データ：必ず lossless（数値が変わったらデータでない）

Lossy（非可逆圧縮）

• 用途：写真、 動画、 音声、 ストリーミング
• 代表：JPEG / WebP / HEIC、 MP3 / AAC / Opus、 H.264 / H.265 / AV1
• 原則：人間の知覚で気づかない情報を捨てて高圧縮
• 注意：医療診断、 機械学習の前処理で lossy 画像を使うとモデル性能が落ちることがある

数値データの「lossy 化」

SSDSE のような整数データに lossy 圧縮を適用するのは原則 NG だが、 機械学習用の特徴量化済みデータでは：

• FP32 → FP16 (BFloat16) で半分のサイズ、 ニューラルネットワーク学習で標準
• INT8 量子化 → 1/4 サイズ、 推論専用モデルで標準
• K-means 量子化 → ベクトルを代表点に丸める、 オートエンコーダの離散版

⚠️ 圧縮率 vs 速度 — 実務での選択基準

よくある選択基準

• ネットワーク転送：gzip（ブラウザ標準）か Brotli（HTTP 2.0 標準）
• ディスク保存（頻繁にアクセス）：Zstd 標準
• ディスク保存（アーカイブ）：xz
• データレイク（Parquet）：Snappy（デフォルト）または Zstd
• DB のページ圧縮：LZ4（PostgreSQL TOAST など）

⚠️ 圧縮の落とし穴 — 実務で踏みがちな罠

1. ランダムデータは圧縮不可：暗号化済みファイル、 乱数列、 すでに圧縮済みのバイト列はほぼ圧縮できない。 「JPEG を再 zip しても小さくならない」のはこのため。
2. 小さいファイルは効率悪い：数 KB のファイルでは圧縮ヘッダ・テーブルのオーバーヘッドで逆に大きくなることも。 多数の小ファイルは tar+gzip でまとめる。
3. 浮動小数点の精度：FP64 をそのままテキスト化すると重複が少なく圧縮率悪。 必要な精度に丸めてから保存（df.round(6) など）すると 30-50% 削減できることがある。
4. 整数 vs 浮動小数：SSDSE のような整数主体データは圧縮率高。 浮動小数主体だと尾数部がランダム的で圧縮率低。 列指向ストレージ + 整数 quantize の組み合わせが有効。
5. 圧縮チェーン：複数アルゴリズムを直列で適用しても、 2 回目以降はほぼ効果なし。 zip + zip より xz 単発の方が小さい。
6. JIT/学習データの圧縮：機械学習のミニバッチ毎に展開する場合、 圧縮率より展開速度を優先（LZ4/Snappy）。
7. ハードウェアアクセラレーション：Intel QAT, ZSTD ハードウェア実装などで高速化可能だが、 対応環境を要確認。
8. セキュリティ — CRIME / BREACH 攻撃：HTTPS + gzip 圧縮で、 圧縮率の変化からトークンを推測する攻撃あり。 認証情報を含む応答は圧縮しない、 または別途防御策が必要。

🌐 関連手法・この用語を使う論文

🌐 関連手法・派生

• 辞書符号化 — categorical 列を ID に置換、 Parquet/ORC の核
• エンコーディング — UTF-8, base64, Avro
• バイナリ形式 — Protocol Buffers, FlatBuffers, MessagePack
• 列指向 DB — ClickHouse, Vertica の内部圧縮
• ベクトル化（Arrow） — メモリ内でも列指向＋圧縮
• 差分プライバシー — ノイズを足して情報を制御

🌐 Parquet — 統計データに最適な列指向圧縮

CSV は「行指向（1 行ずつ書く）」だが、 Parquet / ORC / Arrow は「列指向」。 同じ列に同じ型の値が並ぶため、 列ごとに別々の最適圧縮を適用できる。

列指向の利点

• 同じ型 → 圧縮効率高（整数の繰返し、 文字列の辞書化）
• 必要な列だけ読める（SELECT col1, col2 が高速）
• Dictionary encoding（categorical の自動辞書化）
• Run-Length Encoding（連続する同じ値の圧縮）

🐍 Python 実装 #C1: SSDSE を Parquet に変換

🎯 このコードでやること：SSDSE-B-2026 を異なる圧縮設定で Parquet に保存し、 サイズを比較。

📥 入力データ：先ほどの df (564 行 × 112 列)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import pyarrow  # parquet の読み書きに必要（ブラウザには無い）
import io

for comp in [None, 'snappy', 'gzip', 'brotli', 'zstd']:
    buf = io.BytesIO()
    try:
        df.to_parquet(buf, compression=comp)
        print(f'Parquet ({comp or "none":>6}): {buf.tell():>9,} bytes')
    except Exception as e:
        print(f'Parquet ({comp}): skipped ({e})')

📤 実行結果：

💬 結果の読み方：Parquet 単体 (none) は CSV より大きい（メタデータが多い）。 Snappy は速度優先で CSV と同程度。 gzip / brotli / zstd 圧縮を組み合わせると 75% 程度に。 列指向の本領は「列単位の選択読込」と「数億行のデータ」で発揮される。

🌐 機械学習モデルの圧縮

大規模言語モデル (LLM) や画像認識モデルは数 GB〜数 TB あり、 ストレージ・転送・推論コストが膨大。 モデル圧縮の主要技法：

1. Quantization（量子化）

• FP32 → FP16 / BF16：精度は維持しつつ半分のサイズ。 推論で標準
• FP32 → INT8：1/4 サイズ、 推論専用モデルで標準
• FP32 → INT4：1/8 サイズ、 LLM 推論（GPTQ, AWQ）
• FP32 → 1bit (Binary)：1/32 サイズ、 BinaryNet 等の特殊ケース

2. Pruning（枝刈り）

絶対値の小さい重みを 0 にする。 スパース行列で保存し、 専用ハードウェア（NVIDIA Ampere の 2:4 sparsity 等）で推論加速。

3. Knowledge Distillation（蒸留）

大きな「教師モデル」の出力を、 小さな「生徒モデル」が真似ることで圧縮。 DistilBERT、 TinyBERT、 MobileBERT などが代表例。

4. Low-rank decomposition

重み行列 $W$ を $W \approx UV$ と低ランク分解。 SVD / Tucker / Tensor Train などを使用。 LoRA の基礎技術。

🐍 Python 実装 #E1: SSDSE 列を INT8 量子化

🎯 このコードでやること：SSDSE の人口列（int64）を量子化して保存サイズを比較。 量子化前後の誤差も確認。

📥 入力データ：A1101 (47 都道府県人口、 値域 5e5 〜 1.4e7)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# ── この抜粋で使うデータを用意します（英字の項目コードで読み込み）──
import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', header=0)
df = df[df['Code'].astype(str).str.match(r'^R\d{5}$', na=False)].copy()
for _c in df.columns[3:]:
    df[_c] = pd.to_numeric(df[_c], errors='coerce')
df = df[df['SSDSE-B-2026'] == df['SSDSE-B-2026'].max()]

import numpy as np

x = df['A1101'].values.astype(np.float64)
print(f'元: {x.dtype}, size = {x.nbytes} bytes ({x.nbytes/len(x)} bytes/要素)')

# FP32
x32 = x.astype(np.float32)
print(f'FP32: size = {x32.nbytes} bytes ({x32.nbytes/len(x)} bytes/要素)')

# FP16（そのまま入れると桁あふれする）
x16 = x.astype(np.float16)
print(f'FP16: size = {x16.nbytes} bytes ({x16.nbytes/len(x)} bytes/要素)')
_over = np.isinf(x16).any()
print(f'  そのまま変換: 桁あふれが起きたか = {_over}'
      '  ← 総人口は float16 の上限 65504 を超えるので表現できない')

# スケーリングしてから FP16
sc16 = x.max()
x16n = (x / sc16).astype(np.float16)
err16 = np.max(np.abs(x - x16n.astype(np.float64) * sc16))
print(f'  最大値で割ってから変換: max |x - x16| = {err16:.0f}'
      f'  (相対誤差 {err16/x.max():.2e})')

# INT8 (min-max 量子化)
mn, mx = x.min(), x.max()
scale = (mx - mn) / 255
x8 = np.round((x - mn) / scale).astype(np.uint8)
print(f'INT8: size = {x8.nbytes} bytes ({x8.nbytes/len(x)} bytes/要素)')
print(f'  誤差: max = {np.max(np.abs(x - (x8 * scale + mn))):.0f}')

📤 実行結果：

💬 結果の読み方：FP64 → FP16 でサイズは 1/4 になるが、 総人口（最大 1,409 万）は float16 の上限 65,504 を超えるため そのまま変換すると inf に振り切れる。 最大値で割ってから変換すれば誤差は 1,663 人（相対誤差 1.2×10⁻⁴）に収まる — 量子化で「スケールを揃えてから型を落とす」のはこのためである。 INT8 はさらに半分だが、 誤差 26,400 人（最大値域の 0.2%）と無視できないため、 統計データには不向き。 ニューラルネットワークの重みのように「相対的に小さい値が多い」場合は INT8 でも精度を保てる。

🌐 用語の英語対応

🎯 まとめ — データ圧縮完全強化版

本ページでは「データ圧縮」を 12 必須セクション（🔖 索引 / 💡 結論 / 📍 文脈 / 🎨 直感 / 📐 数式 / 🔬 数式を言葉で読み解く / 🧮 実値計算 / 🐍 Python / ⚠️ 落とし穴 / 🌐 関連手法 / 🔗 関連用語 / 📚 グループ教材）で整理しました。 SSDSE-B-2026 の生 CSV (359 KB) を gzip (44%) / bz2 (39%) / xz (36%) / Parquet (各種) で実測し、 Shannon エントロピー (3.57 bit/byte) と理論最小サイズ (160 KB) を比較。 xz は Shannon 限界すら下回る (128 KB)、 これは「マルコフ的依存」を取り込む LZMA の利点。 統計データ分析コンペでは「テキストなら xz、 列指向なら Parquet+zstd、 配布は Brotli」を選択基準として覚えておけば十分です。

🧪 追加検証: Parquet 列指向 (zstd) と gzip CSV のサイズ・読込時間を SSDSE-B-2026 で比較

🎯 このコードでやること: SSDSE-B-2026 (47 都道府県 × 100 列前後) を CSV / CSV.gz / Parquet+snappy / Parquet+zstd の 4 形式で書き出し、 ファイルサイズと pd.read_* の 所要時間を実測する。 「列指向 + zstd」がテキスト形式に対してどの程度有利かを定量化するのが目的。

📥 入力データ: data/raw/SSDSE-B-2026.csv (359,034 bytes 想定) を pd.read_csv() で読み込んだ df。 1 行目が日本語ヘッダ、 2 行目が変数コード、 3 行目以降が 47 都道府県 × 多列の数値データ。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import os, time, pandas as pd
import pyarrow            # Parquet の読み書きに必要（ブラウザ版 Python には入っていない）

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', skiprows=[1], encoding='cp932')

paths = {}
paths['csv']        = 'tmp_b.csv';            df.to_csv(paths['csv'], index=False)
paths['csv.gz']     = 'tmp_b.csv.gz';         df.to_csv(paths['csv.gz'], index=False, compression='gzip')
paths['parq.snap']  = 'tmp_b_snap.parquet';   df.to_parquet(paths['parq.snap'], compression='snappy')
paths['parq.zstd']  = 'tmp_b_zstd.parquet';   df.to_parquet(paths['parq.zstd'], compression='zstd')

for k, p in paths.items():
    sz = os.path.getsize(p)
    t0 = time.perf_counter()
    if k.startswith('parq'): _ = pd.read_parquet(p)
    else:                    _ = pd.read_csv(p)
    dt = (time.perf_counter() - t0) * 1000
    print(f'{k:10s}  size={sz:>7d} B   read={dt:6.1f} ms')

📤 実行例 (Apple M2 / Python 3.12 / pandas 2.2 / pyarrow 16):

💬 結果の読み方: → Parquet+zstd は CSV の約 11.7% (1/8.6) まで縮み、 同時に 読込が 3 倍以上速い。 これは「列ごとに型が揃う → dictionary encoding + RLE + zstd」の三段重ねが効いているため。 一方 gzip CSV は約 44% 止まりで読込はむしろ遅い (テキストパースが律速)。 大規模統計表は迷わず Parquet+zstd で永続化、 配布だけ CSV を別途用意するのが 2026 年現在のベストプラクティス。 なお SSDSE-B-2026 のように「整数 + 小数の混在 + 都道府県カテゴリ列」を持つ表では、 Parquet の dictionary encoding が都道府県名カラムに対し劇的に効き、 zstd の前段でデータ量が既に 3-4 割に落ちている。

⚠️ ベンチマーク注意: Parquet の読込時間には pyarrow 初回 import のキャッシュ効果が含まれる。 厳密な比較では timeit で 3-5 回平均を取る、 OS のページキャッシュをクリアする (sudo purge on macOS) などの配慮が必要。 また Parquet は ランダムアクセス・列射影に強く、 全件読込ベンチマークでは Parquet の本来の強みは半分しか出ない。 pd.read_parquet(path, columns=['総人口']) のように列指定するとさらに 5-10 倍の高速化が見込める。

📐 圧縮率と Shannon 限界 — 数式と実測で確かめる

データ圧縮の効きは「平均値・分散・分布形」といった統計量に直結する。 ここでは SSDSE-B-2026 (47 都道府県 × 100 列前後) の実ファイルを素材に、 圧縮率の理論的下限を与える Shannon エントロピーを数式で確認し、 gzip / bz2 / xz の実測サイズと突き合わせて「理論限界 vs 実測」の差を体感する。

📐 数式を言葉で読み解く — 圧縮率と Shannon 限界の関係

圧縮可能な最小サイズ $L_{\min}$ は、 元データのバイト列を確率変数 $X$ とみなしたときの Shannon エントロピー $H(X)$ で次のように決まる。

$$L_{\min} = N \cdot H(X) = -N \sum_{i=1}^{256} p_i \log_2 p_i \quad [\text{bit}]$$

記号の意味: $N$ は元データのバイト数、 $p_i$ は値 $i \in \{0, 1, \dots, 255\}$ の出現確率、 $H(X)$ は単位 bit/byte で表したエントロピー。 SSDSE-B-2026 の場合、 $N = 359{,}034$ バイト、 $H(X) \approx 3.57$ bit/byte が実測値なので、 理論最小サイズは $L_{\min} = 359{,}034 \times 3.57 / 8 \approx 160{,}219$ バイト (約 160 KB)。 ところが xz の実測値は 128 KB でこの限界を下回る。 これは Shannon 限界が「i.i.d. = 各バイトが独立」を仮定しているのに対し、 SSDSE のような実データはマルコフ的な依存 (隣接バイトに強い相関) を持つため、 LZMA や Brotli が条件付きエントロピー $H(X_n | X_{n-1}, X_{n-2}, \dots)$ を使うことで Shannon 限界を「実質的に」突破できているからである。

🐍 Python 実装 — 圧縮率と Shannon エントロピーの一致確認

🎯 このコードでやること: SSDSE-B-2026 のバイト列の Shannon エントロピーを計算し、 gzip / bz2 / xz の実測圧縮サイズと並べて「理論限界 vs 実測」の差を可視化する。 マルコフ依存を持つ実データに対し、 xz だけが Shannon 限界を下回ることを再現する。

📥 入力データ: data/raw/SSDSE-B-2026.csv (実ファイル、 約 359 KB)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import gzip, bz2, lzma, math
from collections import Counter

# 実データ読み込み (バイト列のまま扱う)
with open('data/raw/SSDSE-B-2026.csv', 'rb') as f:
    raw = f.read()

# Shannon エントロピー (bit/byte)
N = len(raw)
freq = Counter(raw)
H = -sum((c/N) * math.log2(c/N) for c in freq.values())
L_min = N * H / 8  # 理論最小サイズ (byte)

# 3 アルゴリズムで実測
sizes = {
    'raw':  N,
    'gzip': len(gzip.compress(raw, compresslevel=9)),
    'bz2':  len(bz2.compress(raw,  compresslevel=9)),
    'xz':   len(lzma.compress(raw, preset=9)),
}

print(f'N         = {N:>8d} byte')
print(f'H(X)      = {H:.3f} bit/byte')
print(f'L_min     = {L_min:>8.0f} byte  (Shannon 限界)')
for k, v in sizes.items():
    ratio = v / N
    print(f'{k:6s}    = {v:>8d} byte   ratio={ratio:.3f}')

📤 実行例:

💬 結果の読み方: → Shannon 限界 (i.i.d. 仮定) は 160 KB だが xz は 128 KB。 これは LZMA の文脈モデリングが「直前バイトに依存する条件付きエントロピー」を捉え、 i.i.d. 仮定を上回る効率を達成している証左。 gzip (LZ77+Huffman) は文脈長が浅いため Shannon 限界に届かない。 統計データ分析コンペで「最小サイズ」を狙うなら xz が第一選択、 ただし圧縮時間が gzip の 10 倍以上かかる点に注意。

🧮 実値で計算してみる — 47 都道府県人口列の単体圧縮

SSDSE-B-2026 の「総人口」列だけを取り出して圧縮するとどうなるかを実値で計算する。 47 行 × 1 列の非常に小さいデータだが、 整数の桁数が揃っているため Parquet+dictionary encoding が特に効く。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

import pandas as pd, io, gzip, lzma

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', skiprows=[1], encoding='cp932')
col = df['A1101'].astype('int64')  # 564 行 = 47 県 x 12 年ぶんの総人口

# CSV 形式でバイト列化
buf = io.BytesIO()
col.to_csv(buf, index=False, header=False)
raw = buf.getvalue()

# 圧縮
gz = gzip.compress(raw, compresslevel=9)
xz = lzma.compress(raw, preset=9)

print(f'rows         : {len(col)}')
print(f'CSV bytes    : {len(raw)} B')
print(f'gzip         : {len(gz)} B  ratio={len(gz)/len(raw):.3f}')
print(f'xz           : {len(xz)} B  ratio={len(xz)/len(raw):.3f}')
print(f'min,max,mean : {col.min()}, {col.max()}, {int(col.mean())}')

📤 実行例:

💬 結果の読み方: → 47 行と非常に小さいため、 xz のヘッダオーバーヘッド (LZMA は約 60 byte の固定ヘッダ) が効いて gzip より大きい。 小データでは gzip、 大データでは xzという経験則の根拠。 1 MB 以下のデータでは gzip 一択、 10 MB 以上では xz が逆転する。

📋 追加: 圧縮アルゴリズム選定の意思決定表 (詳細版)

⚠️ 落とし穴 (拡張版・8 件)

• 圧縮後の再圧縮はほぼ意味がない: gzip → xz と二重に圧縮しても 2-3% しか縮まない。 既に圧縮されたデータはランダムに近いため、 2 回目以降の圧縮で取れる余地は理論的にほぼゼロ。 むしろ展開時に CPU を 2 回使うのでネット負荷増。
• 暗号化と圧縮の順序を間違えると圧縮が効かない: 必ず「圧縮 → 暗号化」の順。 逆にすると暗号化済みデータはランダムに見えるため、 圧縮率がほぼ 1.0 になる。 HTTPS では gzip 適用は TLS 内部 (TLS 圧縮は CRIME 攻撃で廃止) ではなく Content-Encoding で行う。
• 小データで xz / brotli を使うと逆に大きくなる: 1 KB 以下のデータでは LZMA / Brotli のヘッダオーバーヘッド (各 60-200 byte) が支配的で、 元データより圧縮後の方が大きくなる。 小データなら gzip か無圧縮を選ぶ。
• lossy 圧縮は累積劣化する: JPEG を編集 → 保存を繰り返すと毎回再量子化が走り、 ブロックノイズが累積。 写真編集中は PNG / TIFF などの lossless を維持し、 最終出力だけ JPEG にする。
• Parquet の圧縮は列ごと選べる: 列によって特性が違うので、 全列同じアルゴリズムを使うのは最適ではない。 整数列は DELTA_BINARY_PACKED + zstd、 文字列列は DICTIONARY + zstd、 浮動小数列は BYTE_STREAM_SPLIT + zstd など列ごとの最適化が効く。
• 展開速度を考慮しないと SLA を割る: 圧縮率だけ見て xz を選ぶと展開が遅く、 API レスポンス時間が劣化することがある。 リアルタイム配信では「展開速度 > 圧縮率」で zstd / lz4 を選ぶ。
• 圧縮済みファイルの md5 / sha は中身ではなくバイト列に対するもの: 同じ元データでも圧縮ライブラリのバージョンが違うとハッシュが変わるので、 中身の同一性確認には展開後のデータでハッシュを取る。
• NaN / 欠損値が多い列は思ったほど縮まない: NaN は IEEE 754 の特殊値で 8 byte ごとに繰り返す形になるが、 zstd の dictionary には登録されにくく、 圧縮率は期待の半分程度しか出ない。 NaN を 0 や sentinel 値に置換してから圧縮する方が効率的なケースがある (ただし区別が必要な場合は危険)。

🔬 数式を言葉で読み解く — Kraft 不等式と平均符号長

可変長符号 (Huffman など) が「一意復号可能」であるための必要十分条件は、 符号語長 $\{\ell_1, \ell_2, \dots, \ell_n\}$ に対する Kraft 不等式:

$$\sum_{i=1}^{n} 2^{-\ell_i} \le 1$$

言葉での読み解き: 各記号 $i$ に長さ $\ell_i$ ビットの符号を割り当てるとき、 そのコストの「指数和」が 1 以下なら一意に復号できる。 等号成立 ($= 1$) は「完全に効率的な符号」を意味する。 シャノンの符号化定理は、 平均符号長 $L = \sum p_i \ell_i$ がエントロピー $H = -\sum p_i \log_2 p_i$ にいくらでも近づけることを保証する: $H \le L < H + 1$ (Huffman の場合)、 算術符号ではさらに $L \to H$ に漸近する。

🌐 関連手法・派生 (拡張)

• 無損失圧縮系: 情報エントロピー / Huffman 符号 / 算術符号 / LZ77 / LZ78 / LZMA / DEFLATE
• 列指向ストレージ: DWH / Parquet / ORC / Arrow / Apache Iceberg
• 次元削減 (情報圧縮): PCA / SVD / Autoencoder / t-SNE / UMAP
• モデル圧縮 (ML): 量子化 (int8/int4) / 蒸留 / Pruning / LoRA / GGUF
• 画像・動画: JPEG / WebP / AVIF / H.264 / H.265 / AV1 / VP9
• 音声: MP3 / AAC / Opus / FLAC / Vorbis
• 時系列: Gorilla 圧縮 / Delta-of-Delta / TimescaleDB compression

📚 関連グループ教材 (拡張)

• データ収集・整備グループ — 永続化フォーマットとしての圧縮戦略
• 情報理論グループ — Shannon エントロピーと符号化定理
• データエンジニアリンググループ — DWH と列指向ストレージ
• AI システム開発グループ — モデル圧縮と推論高速化

✅ 理解度チェック (10 問)

1. Q1: 「lossless 圧縮」と「lossy 圧縮」の本質的な違いを、 SSDSE-B-2026 のような統計データに使えるのはどちらか、 理由とともに述べよ。
   → A: lossless は完全可逆 (展開後に元データと bit 単位で一致)、 lossy は知覚的に許容できる範囲で情報を捨てる。 統計データは 1 bit でも値が変わると分析結果が変わるため lossless 必須。 写真や動画は人間の知覚で許容できる範囲で lossy を使う。
2. Q2: SSDSE-B-2026 (359 KB) の Shannon エントロピーが 3.57 bit/byte だったとき、 理論上の最小サイズは何 KB か。
3. Q3: xz の実測サイズが 128 KB と Shannon 限界 160 KB を下回る理由を一言で述べよ。
   → A: Shannon 限界は i.i.d. (各バイト独立) を仮定するが、 実データはマルコフ依存を持つため、 文脈モデルを使う LZMA はその仮定を超えられる。
4. Q4: Parquet で dictionary encoding が特に有効な列タイプを 2 つ挙げよ。
   → A: (1) カテゴリ列 (都道府県名、 性別、 業種分類など)、 (2) 重複値の多い整数列 (年度、 大分類コードなど)。
5. Q5: 「圧縮 → 暗号化」と「暗号化 → 圧縮」、 正しい順序とその理由を述べよ。
   → A: 必ず「圧縮 → 暗号化」。 暗号化済みデータはランダムに近いため圧縮率がほぼ 1.0 になり、 逆順は無意味になる。
6. Q6: 1 KB 未満の小データに xz を使うとどうなるか、 理論的根拠とともに述べよ。
   → A: LZMA のヘッダ (約 60-200 byte) と辞書テーブルのオーバーヘッドが支配的で、 元データより大きくなる場合がある。 小データなら gzip か無圧縮。
7. Q7: Parquet+zstd と CSV+gzip でファイルサイズが 5 倍以上違う典型的な理由を 3 つ挙げよ。
   → A: (1) 列指向で型が揃う、 (2) dictionary encoding でカテゴリが激減、 (3) RLE で連続値が圧縮、 さらに (4) ヘッダの日本語が削減、 (5) 数値が文字列でなくバイナリで保持、 など。
8. Q8: 「圧縮率」と「展開速度」のトレードオフで、 リアルタイム配信に向くアルゴリズムは何か。
9. Q9: JPEG を編集 → 保存を繰り返すと品質が劣化する現象を何と呼ぶか、 また防ぐ方法を述べよ。
   → A: 世代劣化 (generation loss)。 編集中は PNG / TIFF などの lossless を保持し、 最終出力だけ JPEG にする。
10. Q10: 機械学習モデルの圧縮で int8 量子化 (8-bit quantization) によって何が起きるか、 メリットと注意点を述べよ。
    → A: float32 → int8 で重みサイズが 1/4、 推論速度が 2-4 倍に高速化。 ただし量子化誤差で精度が 1-2% 程度低下することがあり、 QAT (Quantization-Aware Training) や calibration で緩和する。

📐 補遺 A: 圧縮アルゴリズムの内部動作 (LZ77 / Huffman / 算術符号)

現代の汎用圧縮アルゴリズム (gzip / zstd / brotli / xz) はすべて、 大きく分けて 2 段階の処理を経る: (1) 辞書ベースの冗長性除去 (LZ77 / LZ78 系列) と (2) エントロピー符号化 (Huffman / 算術符号 / ANS)。 ここではそれぞれの本質を SSDSE-B-2026 の具体例で見る。

A-1: LZ77 — スライディングウィンドウで「過去に出た文字列」を参照

LZ77 は「直前の N バイトを辞書として、 今読んでいる位置から先頭一致する最長文字列を見つけ、 (offset, length, next_char) の 3 つ組で置き換える」という極めてシンプルなアルゴリズム。 SSDSE-B-2026 の冒頭で考えると、 ヘッダ行に「人口」「世帯」などの語が繰り返し現れる箇所で長い一致が発生し、 1 ヘッダ行 (約 800 byte) が 200 byte 程度まで縮む。 gzip のスライディングウィンドウは 32 KB だが、 zstd では 128 MB まで拡張可能で、 これが zstd が長距離反復に強い理由。 xz の LZMA はさらに「動的辞書サイズ + 確率推定 + 距離符号化」を組み合わせ、 数 GB 規模の文脈を考慮できる。

実装上の注意: ウィンドウサイズを大きくするほど圧縮率は上がるが、 メモリ使用量とエンコード時間が線形に増える。 zstd の --long=27 オプションは 128 MB ウィンドウを使うが、 これだけで RAM を 1-2 GB 消費する。 統計データ分析コンペで Parquet+zstd を使う場合は compression_level=3, dict_size=8MB 程度が現実的な落としどころ。

A-2: Huffman 符号 — 出現頻度の高い記号に短い符号を割り当てる

Huffman 符号は「文字の出現頻度を見て、 頻度の高い文字には短いビット列、 低い文字には長いビット列を割り当てる」前置符号 (prefix code) の一種。 SSDSE-B-2026 では数字 0-9、 カンマ、 改行が圧倒的に多いため、 これらは 3-4 bit、 漢字 (UTF-8 3 byte) は 18-20 bit という形で符号長が決まる。 Huffman 符号は Kraft 不等式の等号を整数長で達成する最適符号だが、 「整数 bit でしか符号長を割り当てられない」という制約からエントロピーとの間に最大 1 bit/symbol のギャップが生じる。

A-3: 算術符号と ANS — 整数長制約を取り払う

算術符号 (arithmetic coding) は「データ列全体を [0, 1) の区間として 1 つの実数で表現」する手法で、 整数 bit 長制約を取り払い、 漸近的にエントロピー限界に到達できる。 zstd / brotli は ANS (Asymmetric Numeral Systems) という算術符号の高速変種を採用し、 Huffman 並みの速度で算術符号並みの圧縮率を達成している。 これが「zstd が gzip より 10-20% 縮む」主要因の 1 つ。

📐 補遺 B: Parquet ファイルフォーマットの内部構造

Apache Parquet は「列指向 + 階層的メタデータ + 任意の圧縮コーデック」を組み合わせた現代的な列指向ストレージフォーマット。 内部構造は次のように階層化されている。

• File: 物理ファイル全体。 末尾に Footer (メタデータ) を持つ。
• Row Group: 行を 64-128 MB 程度のチャンクに分けたもの。 並列読込の単位。
• Column Chunk: Row Group 内で 1 列分のデータ。 列指向の本体。
• Page: Column Chunk をさらに 1 MB 程度に分けたもの。 圧縮・暗号化の単位。 Data Page / Dictionary Page / Index Page の 3 種類。
• Footer: File 全体のスキーマ・統計量 (min/max/null_count)・圧縮コーデック情報を含むメタデータ。

この階層構造により、 列射影 (必要な列だけ読む)、 述語プッシュダウン (where 条件を統計量で枝刈り)、 並列読込 (Row Group 単位) が可能になる。 SSDSE-B-2026 のような小規模データでは Row Group が 1 つしかないため恩恵は限定的だが、 12 年パネル × 全市町村 (約 100 万行) まで拡張すると Parquet の真価が発揮される。

📐 補遺 C: 圧縮レベル (compression level) の選び方

ほとんどの圧縮ライブラリには「圧縮レベル」(1-9 や 1-22 など) が存在し、 数値が大きいほど圧縮率は上がるが速度は下がる。 SSDSE-B-2026 で gzip / zstd の各レベルを試した結果は次の通り (Apple M2, Python 3.12, pandas 2.2)。

💬 表の読み方: zstd は level=3 で gzip level=9 を上回る圧縮率を 1/6 の時間で達成する。 level=9 と level=22 の差はわずか 4% に対し圧縮時間が 35 倍。 統計データ分析コンペでは zstd level=3 が黄金比と言われる所以がここにある。 「展開時間」が圧縮レベルに依存しないのも zstd の重要な特徴で、 「書込時に時間をかけても読込は常に高速」というワークロードに最適。

📐 補遺 D: SSDSE-B-2026 圧縮の実務チェックリスト

統計データ分析コンペで SSDSE-B-2026 を扱う際の圧縮戦略を、 ステップごとにチェックリスト化する。 初学者がそのまま順番に実行できるレベルの粒度。

1. 受領時の検証: pd.read_csv('data/raw/SSDSE-B-2026.csv', skiprows=[1]) でヘッダの整合性を確認。 行数 = 47 (都道府県数)、 列数 = 100 前後を想定。
2. 型推論の固定化: dtypes を取得して data/processed/ssdse_b_2026_dtypes.json に保存。 整数列は int32 に、 浮動列は float32 に変換するとサイズが半分になる。
3. カテゴリ列の最適化: 「都道府県」「年度」など重複が多い列は astype('category') に変換。 Parquet の dictionary encoding が自動で適用される。
4. 欠損値の sentinel 化: 浮動小数の NaN は圧縮効率が悪いので、 業務上区別不要なら -1 や 0 に置換。 ただし「欠損 = 未測定」と「0 = 値ゼロ」を区別する必要がある場合は NaN を維持。
5. Parquet 書き出し: df.to_parquet('data/processed/ssdse_b_2026.parquet', compression='zstd', compression_level=3)。 359 KB → 約 40 KB に縮む。
6. 列射影テスト: pd.read_parquet(path, columns=['都道府県', '総人口']) で「全体読込」と「列指定読込」の時間差を計測。 通常 5-10 倍の高速化。
7. パーティショニング (時系列拡張時): 12 年パネルなら df.to_parquet(path, partition_cols=['年度']) で年度別ディレクトリに分割。 一部年度だけ読む場合の IO が桁違いに減る。
8. 配布用の CSV.gz: 教育素材として「人間が見られる形」で配る必要がある場合は df.to_csv(path, compression='gzip') を併用。 Parquet は GitHub プレビューで開けないが gzip CSV は zcat で確認できる。
9. 整合性確認: 圧縮後に pd.read_parquet で読み戻し、 pd.testing.assert_frame_equal(df, df2) で完全一致を確認。 万一の dtype 変換ミスがここで検出できる。
10. ベンチマーク記録: 元サイズ・圧縮後サイズ・圧縮時間・展開時間を data/processed/compression_benchmark.csv に記録。 後続の改善で改悪していないかを継続監視。

🌐 補遺 E: 業界別の圧縮プラクティス事例

統計データ以外でも、 業界ごとに「定番の圧縮戦略」が存在する。 SSDSE を扱う際の参考として、 代表的な業界事例を整理する。

• 金融 (高頻度取引データ): マイクロ秒単位の取引ログを Apache Avro + Snappy で永続化。 Snappy は圧縮率は控えめだが展開速度が桁違いに速いため、 リアルタイム分析向き。 1 日 100 GB → 30 GB 程度。
• 気象 (NetCDF/HDF5): 多次元配列を HDF5 内で zlib/szip 圧縮。 衛星画像は JPEG2000 (lossless モード) で約 1/3。 気象庁の数値予報モデル GPV ファイルは GRIB2 形式 (内部で JPEG2000 採用)。
• ゲノム解析 (FASTQ/BAM): 塩基配列データは ACGT の 4 文字なので 2 bit/symbol が理論限界。 CRAM (Compressed Read Alignment Map) で約 60% 削減。 数 TB → 数百 GB スケール。
• 科学計算 (シミュレーション結果): 浮動小数点配列に対し ZFP / SZ のような「精度を保証する lossy 圧縮」を採用。 「絶対誤差 < 1e-6」を保証しつつ 1/10 - 1/100 のサイズ削減。
• Web ログ (Apache/Nginx): 1 日数 GB のテキストログを zstd で深夜バッチ圧縮。 1/8 サイズ + ストリーミング検索可能 (zgrep, zstdgrep)。 ログローテーションと組合せて 90 日保持で TB 級ストレージを節約。
• 動画配信 (Netflix/YouTube): H.265 / VP9 / AV1 を視聴環境ごとに切り替え、 同じ動画を 10-20 の品質バリアントで保持 (per-title encoding)。 視聴開始時に最適なバリアントを ABR (Adaptive Bitrate) で選択。
• 機械学習 (大規模言語モデル): 数百 GB のモデル重みを GGUF/AWQ で 1/4 - 1/8 に量子化。 推論側で動的に展開しつつ実行。 ローカル LLM (llama.cpp) で必須の技術。

📐 補遺 F: SSDSE-B-2026 を題材にした圧縮 FAQ (追加 15 問)

圧縮を扱う上で実務担当者・教育現場で頻出する疑問を、 SSDSE-B-2026 を題材に追加 15 問でまとめた。 既存の FAQ セクションと重複しないように、 やや専門的な視点を中心に選んでいる。

1. Q11: Parquet ファイルを Excel で直接開けないが、 代わりに何を使えば良いか?
   → A: pandas / DuckDB / Apache Arrow の Python スクリプト、 もしくは parquet-tools CLI、 さらに最近では VSCode の Parquet Viewer 拡張で GUI 確認できる。 業務ユーザー向けには「Parquet → CSV 変換スクリプト」をワンクリックで動かせるバッチを用意する慣行が一般化している。
2. Q12: 同じ SSDSE-B-2026.csv でも、 OS や Python バージョンによって圧縮後サイズが微妙に変わる理由は?
   → A: 圧縮ライブラリ (zlib/zstd) のバージョン差、 改行コード (LF vs CRLF) の差、 文字コード正規化 (NFC vs NFD) の差で 0.1-1% 程度のサイズ差が生じる。 再現性が必要な場合は compression_level と改行コードを明示的に指定する。
3. Q13: 圧縮ファイルが破損した場合、 部分的な復元は可能か?
   → A: gzip / xz は基本的に「ストリーミング型」なので破損箇所以降は復元不能。 一方 Parquet は Row Group ごとに独立しているため、 破損 Row Group をスキップして他の Row Group は読める。 重要データには Parquet 形式 + チェックサム必須。
4. Q14: SSDSE-B-2026 を Parquet 化したファイルを GitHub にコミットして良いか?
   → A: 50 MB 以下なら問題ないが、 バイナリファイルは diff が取れず履歴肥大化の原因になる。 Git LFS の利用、 もしくは「再現スクリプト + 元 CSV のみコミット、 Parquet は .gitignore」が推奨。
5. Q15: zstd の「辞書圧縮 (dictionary compression)」とは何か? いつ使うか?
   → A: 大量の小さなファイル (例: JSON ログ数千ファイル) を圧縮する際、 事前に共通辞書 (約 100 KB) を学習しておくと、 個々のファイルの圧縮率が劇的に上がる。 zstd --train で辞書生成可能。 SSDSE のような単一大ファイルでは不要。
6. Q16: 「Brotli」と「zstd」は機能的にほぼ同じだが、 使い分けの目安は?
   → A: Brotli は Web 配信専用 (HTTP Content-Encoding 標準、 ブラウザサポート充実)、 zstd は汎用ストレージ・ストリーミング向け。 圧縮率は同等、 圧縮速度は zstd の方が 2-3 倍速い。
7. Q17: Parquet ファイルのスキーマ進化 (schema evolution) はどう扱われるか?
   → A: 新しい列の追加は後方互換、 既存列の型変更は厳密 (int32 → int64 は OK、 逆は NG)。 列の削除は読込時にスキップ可能。 SSDSE が年度更新で新指標を追加する場合に重要。
8. Q18: 機械学習モデルの圧縮で「Pruning」と「Quantization」の違いは?
   → A: Pruning は「重みの 0 に近い要素を 0 に丸めて疎行列化」、 Quantization は「重みの精度を float32 → int8 に下げる」。 両者は併用可能で、 LLM の場合は「Pruning 50% + Quantization int4」で 1/16 サイズが現実的。
9. Q19: 圧縮率の理論限界を超えるアルゴリズムは存在するか?
   → A: Shannon 限界は i.i.d. を仮定するため、 マルコフ依存を考慮するアルゴリズムは「みかけ上」限界を超えられる。 ただし真の意味でのコルモゴロフ複雑性 (記述長最小) は計算不能。
10. Q20: SSDSE-B-2026 を圧縮してクラウドに保存する場合のコスト見積もりは?
    → A: S3 標準で 1 GB あたり月 0.023 ドル。 359 KB の CSV を Parquet+zstd (約 40 KB) に圧縮すると年間コストは 0.00001 ドル → 実質ゼロ。 ただしリクエスト数が課金の主因になるため、 「ファイル数を増やさない (Row Group で分割)」設計が重要。
11. Q21: 「Snappy」が Parquet のデフォルト圧縮だった時代があるが、 なぜ zstd に置き換わったか?
    → A: Snappy は速度最優先で圧縮率が低い (約 50%)、 一方 zstd は同等速度で圧縮率 30-40% を達成。 2020 年頃から「速度を犠牲にせず圧縮率を上げられる」アルゴリズムとして zstd が業界標準になった。
12. Q22: pandas で to_parquet を使うと pyarrow と fastparquet のどちらが選ばれる?
    → A: デフォルトは pyarrow (Apache Arrow ベース)。 fastparquet は純 Python 実装で互換性が異なる箇所がある。 統計データ分析コンペでは engine='pyarrow', compression='zstd' を明示推奨。
13. Q23: 圧縮済みファイルのインプレース更新 (一部だけ書き換え) は可能か?
    → A: 基本不可。 1 文字でも変更すると全体を再圧縮する必要がある。 Parquet なら Row Group 単位で書き換え可能だが、 ファイル全体の Footer は再書き込みが必要。 頻繁な更新がある用途では「Delta Lake」「Iceberg」のようなレイヤを別途使う。
14. Q24: SSDSE-B-2026 を 100 倍 (4700 行に拡張) して圧縮するとどうなるか?
    → A: gzip / xz は線形にサイズが増えるが、 Parquet+zstd は「dictionary が再利用される」ため線形以下 (80-90%) で済む。 大規模データほど列指向 + dictionary の恩恵が大きい。
15. Q25: 圧縮アルゴリズムの「特許」状況は?
    → A: 主要 OSS アルゴリズム (gzip/zstd/brotli/xz/snappy) はすべて特許フリー。 一方、 動画コーデック (H.264/H.265) は特許プールが存在し商用利用に料金が発生。 AV1 / VP9 は特許フリーで Web 標準化。 統計データ分析コンペの素材として動画を扱う場面は稀だが、 配信プラットフォームでデモを公開する場合はコーデックのライセンス条項を必ず確認。 教育用途であれば AV1 / VP9 を選んでおけば法務リスクを最小化できる。 これは大学や高専の演習資料を作成する際にも同様で、 OSS ライセンスのコーデックを採用しておけば配布範囲を気にせず授業展開できる。 また Apache 2.0 / MIT / BSD ライセンスのライブラリを優先することで、 後年の特許主張リスク (いわゆるパテントトロール対策) も低減できる。

🎯 まとめ — 図解強化版で押さえるべき 7 点

1. 圧縮率は「列の標準偏差」と log-linear に並ぶ (図 1 で実証)
2. SSDSE のような実データは Shannon エントロピー 3.5-4.0 bit/byte の領域に集中 (図 2)
3. アルゴリズム別では zstd が安定、 xz は最高圧縮だが外れ値も多い (図 3)
4. 列間相関が高いデータは「次元圧縮」で圧縮率を桁違いに上げられる (図 4)
5. 時系列データは delta encoding + zstd で 1/10 以下に縮む (図 5)
6. マルコフ依存を持つ実データでは xz が Shannon 限界を下回る
7. 用途別ベストプラクティス: 統計表 → Parquet+zstd、 ログ → zstd、 配布 → Brotli、 バックアップ → xz

🎮 触って理解する

圧縮の本質は「冗長さ（繰り返し・偏り）を見つけて短く書き直す」こと。ここでは 3 つのミニ実験で、(1) 繰り返しが多いほど縮む、(2) 頻出文字ほど短い符号が割り当てられる、(3) 非可逆圧縮は「誤差と引き換えに」縮む、という 3 原理を手を動かして確認します。

実験 1：ランレングス符号化（RLE）ライブデモ

テキストを自由に編集してください。「同じ文字が続く区間」を「文字＋回数」に置き換えるのが RLE です。繰り返しが多いほど縮み、バラバラだと逆に膨らむ（A→A1 と 2 文字になる）ことを体感できます。

実験 2：ハフマン符号 — 頻度で符号長が変わる

5 文字 A〜E の出現頻度をスライダーで変えると、ハフマン木がリアルタイムに組み替わります。頻出文字ほど木の浅い位置（短い符号）、稀な文字ほど深い位置（長い符号）に配置されるのが最適符号の原理です。平均符号長 L は必ず Shannon エントロピー H 以上、H+1 未満に収まります。

実験 3：可逆 vs 非可逆 — 丸めの粗さと誤差のトレードオフ

滑らかな数値列（人工生成データ 64 点）を「刻み幅」で丸めると、値の種類が減ってエントロピー（＝理論上の必要ビット数）が下がる代わりに、元の値との誤差（RMSE）が増えます。スライダーを右へ動かす（またはグラフ上を左右にドラッグする）と、非可逆圧縮の「圧縮率と情報損失のトレードオフ」を体感できます。

💡 実験から読み取るべきこと

• 直感：圧縮とは「冗長さを削る」こと。実験 1 で繰り返しの多いテキストほど縮んだのは、RLE が「連続」という冗長さを利用するから。実験 2 の頻度の偏りも冗長さの一種（偏り＝低エントロピー）。
• 落とし穴 1（ランダムは縮まない）：実験 1 の「ランダム生成」ボタンで確認できる通り、パターンのないデータは逆に膨らむことすらある。既に圧縮済みの zip/JPEG を再圧縮しても縮まないのは、圧縮後のデータが乱数に近い（高エントロピー）ため。
• 落とし穴 2（非可逆は戻せない）：実験 3 で丸めた値は元に戻せない。JPEG を何度も保存し直すと劣化が蓄積するのはこのため。測定値・統計値には必ず可逆圧縮（gzip / zstd / Parquet）を使う。
• 発展（エントロピー限界）：どの実験でも Shannon エントロピー H が「これ以上は縮まない」理論下限として現れた。詳細は 情報量・エントロピー を参照。実験 2 の L が H+1 未満に収まるのがハフマン符号の最適性。
• 発展（列指向圧縮）：Parquet が CSV より縮むのは、列ごとにまとめると「同じ型・似た値が連続」して実験 1 と同じ状況が作れるから（辞書符号化＋RLE＋汎用圧縮の三段構え）。データレイク 設計の基本もここにある。
• 発展（zip の中身）：zip / gzip の DEFLATE は「LZ77（実験 1 の一般化：過去の文字列参照）＋ハフマン符号（実験 2）」の組み合わせ。本ページで触った 2 つの原理がそのまま実用アルゴリズムの部品になっている。

🔗 関連用語（前提・並列・発展）

役割で色分け：前提／並列／発展

⚡ パフォーマンスのトレードオフ

圧縮レベルを上げると 圧縮率は向上するが、 CPU 時間が増加します。 全体スループットは IO ボトルネックの解消量とのバランス：

$$ T_{\text{総}} = T_{\text{圧縮}} + T_{\text{IO}} + T_{\text{解凍}} $$

$T_{\text{IO}}$ が支配的（ネットワーク・HDD 書き込み）なら圧縮で総時間短縮。 メモリ内処理が中心なら圧縮はオーバーヘッドになる場合も。

SSD：3GB/s → snappy/lz4 で十分（CPU が追いつく）
HDD/Network：100MB/s 程度 → zstd レベル 3〜6 で IO 短縮効果が CPU コストを上回る

🔗 関連用語（前提・並列・発展）— 拡張版

前提となる用語

• ビット / バイト — 情報の最小単位
• 2 進数 — コンピュータの基本表現
• エンコーディング — 文字 → バイト変換
• 情報量 — Shannon の定義
• 確率 — エントロピーの基盤

並列・同類の概念

• 暗号化 — 圧縮後は暗号化（順序重要）
• ハッシュ — 一方向変換、 復元不可
• 符号化 — エラー訂正符号など
• シリアライズ — オブジェクト → バイト列

発展・上位の概念

• 情報理論 — Shannon が確立した分野
• コルモゴロフ複雑性 — 究極の「データの非冗長性」尺度
• レート歪み理論 — lossy 圧縮の理論
• 辞書符号化 — LZ77/78 系の理論
• 算術符号 — Huffman より緻密な符号化
• Parquet — 列指向ストレージ
• ORC — Hive 標準
• Apache Arrow — メモリ内列形式

📜 圧縮の歴史

📚 関連グループ教材

• 📚 情報理論教材グループ — Shannon エントロピー・符号化定理
• 📚 データエンジニアリンググループ — CSV / JSON / Parquet / Arrow
• 📚 ビッグデータ教材グループ — Hadoop / Spark / Parquet エコシステム
• 📚 データレイクグループ — 圧縮形式の選定基準
• 📚 用語集トップ

• RFC 1951 (DEFLATE 仕様)（https://datatracker.ietf.org/doc/html/rfc1951）— gzip / zip の中核アルゴリズム正本
• RFC 7932 (Brotli)（https://datatracker.ietf.org/doc/html/rfc7932）— Web 標準の圧縮形式
• RFC 8478 (zstd)（https://datatracker.ietf.org/doc/html/rfc8478）— Facebook 開発の高速圧縮
• Apache Parquet 公式（https://parquet.apache.org/docs/）— カラム指向圧縮形式の標準
• Apache Arrow（https://arrow.apache.org/）— インメモリ列指向データフォーマット
• Squash Compression Benchmark（https://quixdb.github.io/squash-benchmark/）— 30+ 圧縮アルゴリズムの実証比較

📋 圧縮チートシート — 用途 → アルゴリズム

🏆 統計データ分析コンペでの圧縮利用

SSDSE データ取扱いの圧縮戦略

• 提出物のサイズ削減：付録の生 CSV を csv.xz で配布、 README に展開コマンド明記
• Jupyter Notebook の高速化：中間結果を pickle.gz か parquet.zstd で保存し、 再実行を高速化
• クラウド転送料の削減：S3 / GCS への upload 前に zstd 圧縮
• Git LFS / DVC：大規模データは Git の替わりに DVC で版管理、 内部で zstd 使用
• Slack/Drive 共有：ファイルサイズ制限を回避するため zstd or xz

よく使う pandas 圧縮イディオム

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import pandas as pd

from sklearn.linear_model import LinearRegression

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
# pickle 圧縮の例で保存する model もここで作る
_d = df[df['SSDSE-B-2026'] == 2023]
model = LinearRegression().fit(_d[['A1101']].astype(float), _d['A4101'].astype(float))

# CSV を gzip 付きで保存・読込
df.to_csv('out.csv.gz', index=False, compression='gzip')
pd.read_csv('out.csv.gz', compression='gzip')

# Parquet (zstd 圧縮) は最速 + 高圧縮
df.to_parquet('out.parquet', compression='zstd', compression_level=3)
pd.read_parquet('out.parquet')

# pickle 圧縮（任意のオブジェクト）
import joblib
joblib.dump(model, 'model.joblib', compress=('zlib', 3))

# HDF5（巨大ndarray）
df.to_hdf('out.h5', key='df', complib='blosc:zstd', complevel=5)

🗺 データ圧縮 概念マップ

データ圧縮 (data compression)
├── 可逆圧縮 (lossless)
│   ├── エントロピー符号化
│   │   ├── Huffman 符号 (1952)
│   │   ├── 算術符号 (1984)
│   │   └── 範囲符号化
│   ├── 辞書ベース
│   │   ├── LZ77 (1977)      ← gzip, DEFLATE
│   │   ├── LZ78 (1978)      ← UNIX compress, GIF
│   │   ├── LZW (1984)       ← TIFF
│   │   └── LZMA / LZMA2     ← xz, 7z
│   ├── BWT 系
│   │   └── BWT + MtF + RLE  ← bzip2
│   └── 速度優先
│       ├── Snappy           ← Hadoop, Parquet
│       ├── LZ4              ← Kafka, ClickHouse
│       └── Zstandard        ← Linux, Facebook
├── 非可逆圧縮 (lossy)
│   ├── 画像: JPEG / WebP / AVIF / HEIC
│   ├── 音声: MP3 / AAC / Opus
│   ├── 動画: H.264 / H.265 / AV1 / VP9
│   └── 数値: FP16, INT8, K-means 量子化
└── 列指向ストレージ (Parquet, ORC, Arrow)
    ├── 列単位圧縮（型ごとに最適化）
    ├── Dictionary encoding
    ├── Run-Length Encoding
    └── Bit-packing
  

🔗 隣接手法への橋渡し

データ圧縮は情報理論と AI モデルの橋渡し。

• 上流: エントロピー — 情報量の理論的下限を与える
• 並列: 符号化 — 符号化全般との位置関係
• 下流: モデル圧縮 — AI 推論高速化のためのモデル側適用

形式選択 (CSV/Parquet) → 圧縮アルゴリズム選択 (gzip/snappy/zstd) → パーティション設計 → 検証の流れで、 圧縮率と速度の両立を測る。

🌳 手法選択フロー

データ圧縮は可逆/非可逆の判定 → アルゴリズム選択 → モデル圧縮への拡張で考える。

1. 可逆圧縮が必要か？ Yes → ハフマン符号、 No → LZ77 を先に確認
2. 非可逆で十分か？ Yes → JPEG、 No → MP3 を先に確認
3. モデル圧縮も視野か？ Yes → モデル圧縮、 No → 量子化 を先に確認

アーカイブなら gzip、 解析中間ファイルなら snappy、 列指向なら Parquet + zstd、 と「アクセス頻度と圧縮率」で選ぶ。

🧭 解説深化 — 圧縮を「ものさし」として使う（NCD と MDL）

ここまでのセクションは圧縮を「容量を減らす道具」として扱ってきた。この深化セクションでは視点を反転させ、圧縮後のサイズそのものを測定値として使うという、本ページの他の節では扱っていない使い方を紹介する。圧縮器は「データの規則性を探すエンジン」なので、その出力サイズは データの複雑さ・データ同士の類似度 の実用的な推定量になる。

💡 直感

圧縮サイズ C(x) は、計算不能なコルモゴロフ複雑性（このページの「数式」節参照）の実行可能な近似である。ここから面白い性質が出る: 2 つのデータ x, y を連結して圧縮したとき、共通パターンがあれば圧縮器は 2 回目の出現を「参照」で済ませられるので C(xy) は C(x)+C(y) よりずっと小さくなる。この「浮いた分」を正規化したのが正規化圧縮距離 NCD（Cilibrasi & Vitányi, 2005）:

NCD(x, y) = ( C(xy) − min(C(x), C(y)) ) / max(C(x), C(y))

特徴量設計もモデルも距離関数の設計も不要で、「gzip や bz2 に突っ込むだけ」で任意のデータ間の類似度が出る。実際に SSDSE-B-2026.csv（2012–2023 年、47 都道府県パネル）から 7 都府県分の全 109 数値列 × 12 年をカンマ区切りテキスト化し、bz2 (level 9) で NCD を実測した結果（Python で実測・転記）:

ラベルも教師データも与えていないのに、「規模と構造が近い県ほど NCD が小さい」という妥当な順位が出た（比較 7 都府県: 東京・神奈川・大阪・秋田・青森・鳥取・島根、全 21 ペア中の抜粋）。数値が桁の並びとして共有されるほど連結圧縮が効く、という仕組みがそのまま類似度になっている。

1
2
3
4
5
6
7
8
9

import pandas as pd, bz2
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
cols = [c for c in df.columns if c not in ('SSDSE-B-2026','Code','Prefecture')]
def pref_bytes(p):
    sub = df[df['Prefecture']==p].sort_values('SSDSE-B-2026')
    return '\n'.join(','.join(str(r[c]) for c in cols) for _, r in sub.iterrows()).encode()
def C(b): return len(bz2.compress(b, 9))
def ncd(x, y): return (C(x+y) - min(C(x), C(y))) / max(C(x), C(y))
print(ncd(pref_bytes('鳥取県'), pref_bytes('島根県')))   # 0.959（実測）

⚠️ 落とし穴（重要）

• NCD(x, x) は 0 にならない。 理論上は同一データの距離 0 だが、実在の圧縮器は理想的でない。実測では東京都データ同士の NCD(x, x) = 0.372（bz2）。bz2 はブロック単位で処理するため、連結しても 2 個目を完全には「参照」しきれない。NCD の絶対値ではなく相対的な順位だけを使うこと。
• 短いデータでは完全に壊れる。 上と同じ都府県で、総人口 (A1101) の 12 年分だけ（1 県あたり約 90–110 バイト）に絞って NCD を実測すると、東京–神奈川 0.451、東京–秋田 0.451、東京–鳥取 0.427 となり、増加都市ペアと減少県ペアの区別がつかないどころか順位が逆転する。圧縮ヘッダや符号表のオーバーヘッドが数十バイトあり、データ本体より固定費が支配するため。NCD は最低でも数 KB 規模のデータで使う。
• どの圧縮器を使うかで結論が変わる。 A1101 列全 564 行をテキスト化して「都道府県コード×年で整列」と「シャッフル (seed=42)」を比較した実測: zlib (level 9) は整列 1,499 バイト vs シャッフル 1,590 バイトで並び順に敏感だが、bz2 (level 9) は 1,404 vs 1,397 バイトとほぼ無反応（元テキスト 4,408 バイト）。bz2 は内部の Burrows-Wheeler 変換が自分で並べ替えてしまうため、行順序の情報を「見ない」。測りたい構造をその圧縮器が検出できるかを先に確認すること。
• ウィンドウ幅の外は見えない。 gzip (DEFLATE) の参照窓は 32KB。連結した 2 つのデータの類似部分が 32KB 以上離れると検出されず、NCD が不当に大きく出る。大きなデータには zstd の long モードや bz2/xz など窓の広い圧縮器を使う。

🚀 発展

• MDL（最小記述長）原理: 「良いモデルとはデータを最も短く圧縮するモデルである」という統計的モデル選択の原理（Rissanen, 1978）。総記述長 = モデル自体の記述長 + そのモデルの下でのデータの記述長、を最小化する。複雑なモデルはデータ項を縮めるがモデル項が膨らむ——これは情報量規準（AIC/BIC）と同じ過学習抑制の構造で、BIC は MDL の近似形として導出できる。「圧縮＝理解」という視点の、統計モデリング側の対応物。
• gzip でテキスト分類: Jiang et al. (2023, ACL Findings) は「gzip の NCD + k 近傍法」だけの分類器が低リソース設定でニューラルモデルに匹敵すると報告し話題になった。ただしその後の再検証で、評価方法（タイブレークの扱い）により精度が過大に見積もられていたとの指摘があり、主張はやや割り引かれている。「前処理ゼロの強力なベースライン」として使うのが現在の妥当な位置づけ。
• 圧縮によるクラスタリング: NCD の距離行列をそのまま階層クラスタリングに与えると、言語系統樹・ゲノム分類・楽曲ジャンル分類などが特徴量設計なしで再現できることが知られている（Cilibrasi & Vitányi の原論文のデモ）。上の都道府県 NCD 表も、47 県すべてで距離行列を作ればデンドログラムにできる。
• 異常検知への応用: 正常データで「辞書を温めた」圧縮器に新規データを追記圧縮し、圧縮率が急に悪化した点を異常とみなす手法。モデル学習なしで使えるため、ログ監視やセンサー監視の軽量ベースラインになる。

🔗 関連ページ

• 情報エントロピー — C(x) の理論限界。NCD の分母・分子の挙動を支える基礎
• 階層クラスタリング — NCD 距離行列を入力にすればそのまま接続できる
• クラスタリング / k-means — 特徴量ベースの類似度と NCD の対比
• コサイン類似度 — ベクトル化してから測る類似度。NCD は「ベクトル化しない」対極のアプローチ
• AIC / モデル選択 — MDL 原理と同じ「複雑さへのペナルティ」構造
• 正則化 — 記述長のモデル項を抑えることに対応
• 特徴量エンジニアリング — NCD が省略している工程。省略の代償（落とし穴参照）も含めて比較すると理解が深まる