🔖 キーワード索引

別名・略称：（なし）

🔖 詳細キーワード索引

🎨 直感で掴む

🎨 直感で掴む（深掘り）

圧縮を一言で言えば「パターンを見つけて短く書く」。 「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')

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

💬 結果の読み方：いちばん多いカンマ（62,826 回）と数字の「0」「1」「2」に 3 bit、「3」〜「8」に 4 bit の符号が割り当てられ、1 バイト 8 bit のままより大幅に短い。平均符号長 3.633 bit/byte は、同じバイト列のエントロピー 3.591 bit/byte（次の #D1 で計算）より約 1.2% 長いだけで、Huffman がほぼ最適であることが分かる。これで元の 359,821 バイトは約 16.3 万バイトになる計算で、gzip の実測（約 15.8 万バイト）とほぼ同じ水準。

📐 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) と比較。

📥 入力データ：前のブロック（#B1）で読み込んだ csv_bytes（元ファイルそのままのバイト列、359,821 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.591 → 3.207 bit/byte と 0.384 bit（約 10.7%）減る。 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 の中身を並べ替えるだけで確かめました。値は 1 つも変えていません。「列ごと」は 112 列を 1 列ずつ 1 行に書き出したもの、「列ごと＋年度差分」は県ごとに年度順に並べ、数値列を「前の年度との差」に置き換えたもの（先頭の年度だけ元の値。累積和で元に戻せる可逆な変換）です。

列ごとに並べると、同じ種類の数値（総人口なら 7 桁、気温なら「11.0」のような 3〜4 文字）が隣り合うため、どの形式でも 5〜10% 小さくなります。さらに年度差分にすると、総人口 5,465,000 が「−27,000」「−28,000」のような短い数字の並びに変わり、gzip では行ごとの 73.6% まで縮みます。SSDSE のようにゆっくり変わる時系列を県ごとに持つ表では、差分符号化がよく効くということです。Parquet などの列指向形式は、この並べ替えと符号化を列ごとに自動で行います。

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

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

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

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

図で見る — 3 つの圧縮形式と Shannon の下限

破線の「下限」は、各バイトを前後と無関係に 1 文字ずつ符号化する場合の限界です。3 つの形式がすべてこの線を下回るのは、「県名や年度の同じ並び」「000 で終わる千人単位の人数」のような何文字もまとまった繰り返しを使っているからで、Shannon の定理に反しているわけではありません。文脈（直前の文字列）まで考えた高次のエントロピーで測れば、下限はさらに低くなります。

🐍 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 は 358,876 バイトを 128,276 バイト（35.7%、約 3 分の 1）まで縮め、bz2 39.3%・gzip 44.0% が続く。 SSDSE のような数値の CSV は、使う文字がほぼ数字とカンマに限られ、「000」の並びなど同じ部分列の繰返しも多いので圧縮が効く。 逆に一様乱数のバイト列はどの方式でもほとんど縮まず、ヘッダの分だけ元より大きくなることさえある。

🐍 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')

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

💬 結果の読み方：分割すると gzip の合計は 158,033 → 176,604 バイトと 18,571 バイト（約 11.8%）増える。 各ファイルが独自にヘッダ・辞書を持つため。 ただし「特定年だけ高速にアクセスしたい」なら分割が有利。 トレードオフ：圧縮率 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 全体（564 行 = 47 都道府県 × 12 年度）を題材にした最小コード：

 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')

💬 元の CSV（cp932 で約 36 万バイト）に対し、gzip 圧縮の CSV は 159,105 バイトで約 44% まで縮み、Snappy の Parquet 392,585 バイトより小さい。Parquet は列ごとの型情報やメタデータを抱え、Snappy は圧縮率より速度を優先する方式なので、564 行ほどの小さな表では「Parquet のほうが小さい」とは限らない。Zstd にすると 281,552 バイトで Snappy より約 28% 減る。Parquet の利点が効いてくるのは行数が増え、特定の列だけを読み出す場面である。

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

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

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

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)
os.makedirs('out', exist_ok=True)   # 書き出し先（作業フォルダ内）

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

💬 同じ 564 行を 5 方式で保存すると、brotli 269.7 KB・zstd 275.0 KB・gzip 298.8 KB・snappy 383.8 KB・lz4 384.1 KB の順になった。snappy と lz4 は速さ重視でほとんど縮まず、brotli と zstd が約 3 割小さい。時間はどれも 0.03 秒以下で、この大きさでは測定誤差の範囲なので、速度の差を比べるなら行数を増やして繰り返し測る。

(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
34
35
36
37
38
39

# ── この抜粋で使うデータを用意します（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.copy()                         # 列ごとの代入で断片化した表をまとめ直す
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

cols = ['総人口', '高齢化率', '都道府県', '地域']
before = df[cols].memory_usage(deep=True, index=False)

# int64 を int32 へ（最大 1,400 万人なので int32 の上限 21 億に収まる）
df['総人口'] = df['総人口'].astype('int32')
# float64 を float32 へ（精度が許せば。有効桁は約 7 桁になる）
df['高齢化率'] = df['高齢化率'].astype('float32')
# object → category：値の種類が少ない列ほど効く
df['地域'] = df['地域'].astype('category')          # 47 行で 4 種類
df['都道府県'] = df['都道府県'].astype('category')  # 47 行で 47 種類（全部違う）

after = df[cols].memory_usage(deep=True, index=False)
print(pd.DataFrame({'変換前(B)': before, '変換後(B)': after,
                    '差(B)': after - before}))
print(f'4 列の合計: {before.sum()} B → {after.sum()} B')

💬 総人口の int32 化と高齢化率の float32 化は、それぞれ 376 B → 188 B とちょうど半分になる（47 行 × 8 B が × 4 B に）。地域列は 4 種類しかないので category にすると 3,358 B → 537 B と大きく縮むが、47 県すべてが違う都道府県列は 3,390 B → 4,988 B とかえって 1,598 B 増えた。category は「種類の少ない文字列」にだけ効く。4 列の合計は 7,500 B → 5,901 B と縮んだが、その大半は地域列の 2,821 B で、都道府県列の増加 1,598 B を差し引いた結果なので、合計だけでなく列ごとの前後を比べる。

(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 量子化 → ベクトルを代表点に丸める、 オートエンコーダの離散版

SSDSE-B-2026 で確かめる — 有効数字を削るとどれだけ小さくなり、どれだけずれるか

「整数データに lossy 圧縮を適用するのは原則 NG」の理由を、数値 109 列すべてを有効数字 k 桁に丸める実験で数字にしました（丸めても値が変わらないものはそのまま）。

サイズを半分にするには有効数字 2 桁まで削る必要があり、そのとき値の 88.8% が変わって、最大 4.8% ずれます。人口の前年差（数千〜数万人）のような小さな変化は 2 桁の丸めで消えてしまうので、差分や増減率を計算する統計データでは致命的です。一方、k = 5 まで残すとサイズは 98.7% とほとんど縮みません。可逆圧縮（図 1 の並べ替え＋差分で 73.6%）のほうが、誤差ゼロで lossy の k = 4（92.0%）より小さくできる、というのがこの実験の結論です。

⚠️ 圧縮率 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 に保存し、 サイズを比較。

📥 入力データ：SSDSE-B-2026 全体をコードの中で読み直した df（564 行 × 112 列）。

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

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

# SSDSE-B-2026 全体（564 行 × 112 列）を読み直す
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])

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})')

📤 実行結果：

💬 結果の読み方：圧縮なし (none) の Parquet は 538,182 バイトで、utf-8 の CSV（358,876 バイト）の 1.5 倍になる。数値を文字列ではなく 8 バイトの固定長で持つうえ、列ごとのメタデータが付くため。 Snappy で 361,420 バイトと CSV とほぼ同じ、brotli 244,545・zstd 249,957 バイトで CSV の約 7 割になり、gzip CSV（約 15.8 万バイト）にはこの大きさでは届かない。 列指向の本領は「列単位の選択読込」と「数億行のデータ」で発揮される。

🌐 機械学習モデルの圧縮

大規模言語モデル (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 全体（564 行 × 112 列 = 47 都道府県 × 12 年度）を CSV / CSV.gz / Parquet+snappy / Parquet+zstd の 4 形式で書き出し、 ファイルサイズと pd.read_* の 所要時間を実測する。 「列指向 + zstd」がテキスト形式に対してどの程度有利かを定量化するのが目的。

📥 入力データ: data/raw/SSDSE-B-2026.csv（359,821 bytes）を skiprows=[1] で読み込んだ df（1 行目の英字コードを列名にし、2 行目の日本語項目名を飛ばす）。564 行 × 112 列。

 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')

📤 実行例（実測、pandas 2.3 / pyarrow 21）:

💬 結果の読み方: → Parquet+zstd は 249,957 B で CSV（358,876 B）の約 70%、Parquet+snappy は 361,420 B と CSV より 0.7% 大きい。いちばん小さいのは gzip CSV の 158,049 B（約 44%）で、564 行・112 列の表では「Parquet なら必ず小さい」とはならない。112 列のうち文字列は都道府県名などごく一部で、ほとんどが桁数の多い整数のため、dictionary encoding が効く余地が小さいからである。読込時間はどれも 2〜3 ms で差は測定の揺れと区別できないので、Parquet の速さを確かめるなら行数を増やし、columns=[...] で列を絞った読込と比べる。

⚠️ ベンチマーク注意: 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 都道府県 × 12 年度 = 564 行 × 112 列) の実ファイルを素材に、 圧縮率の理論的下限を与える 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{,}821$ バイト、 $H(X) \approx 3.591$ bit/byte が実測値なので、 理論最小サイズは $L_{\min} = 359{,}821 \times 3.591 / 8 \approx 161{,}493$ バイト (約 161 KB)。 ところが xz の実測値は 129 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. 仮定) は 161,493 byte だが xz は 129,288 byte で約 2 割下回る。 LZMA が「直前までのバイト列に依存する条件付きエントロピー」を捉え、1 バイトずつ独立とみなした限界より短く書けているため。 gzip も 159,145 byte と限界をわずかに（約 1.5%）下回っており、LZ77 の繰返し参照がすでに i.i.d. の仮定を越えている。 xz の圧縮時間は同じファイルで gzip の 2 倍強（手元で 0.05 秒 vs 0.02 秒）なので、「最小サイズ」を狙うなら xz が第一選択になる。

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

SSDSE-B-2026 の「総人口」列（A1101）だけを取り出し、12 年度分 564 行 × 1 列のテキストにして gzip と xz で圧縮するとどうなるかを実値で計算する。 4 KB 余りの小さなデータだが、 千人単位で丸めた値（末尾が「000」）が並ぶので繰返しが多い。

 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())}')

📤 実行例:

💬 結果の読み方: → 4,409 B の数字列が gzip で 1,509 B（0.342）、xz で 1,180 B（0.268）まで縮み、ファイル全体（gzip 0.442・xz 0.359）より縮みやすい。 使う文字が数字と改行だけで、どの値も末尾が「000」なので繰返しが多いためである。 xz には数十バイトの固定ヘッダがあるが、4 KB 程度あれば文脈をとらえる強みがそれを上回り、gzip より 329 B 小さくなった。

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

⚠️ 落とし穴 (拡張版・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 が省略している工程。省略の代償（落とし穴参照）も含めて比較すると理解が深まる