最終更新: 2026年9月10日

How Compression Works Inside EPUB, DOCX, XLSX, & PPTX: The Hidden ZIP Architecture

EPUB、DOCX、XLSX、そして PPTX の内部で圧縮がどのように機能するか

.docx、.xlsx、.pptx、または.epubファイルの名前を.zipに変更してダブルクリックすると、驚くべきことにエラーが発生しません。オペレーティングシステムはそれをサブディレクトリ、XML設定ファイル、スタイルシート、フォント、埋め込み画像が詰まったフォルダーとして開きます。

モダンな文書アーキテクチャは何十年も前に単一のバイナリブロブを廃止しました。その代わりに、業界標準—具体的には Microsoft Office 用の Open Packaging Conventions (OPC) と EPUB 用の Open Container Format (OCF) —が驚くほどエレガントな基盤、つまり控えめな ZIP アーカイブ を採用しました。

これらのフォーマット内で圧縮がどのように機能するかを理解することで、モダンな文書がなぜこれほど耐久性があり、軽量で、拡張性があるのか、そしてなぜあるファイルは 90% 圧縮できるのに、他のファイルはほとんど縮まらないのかが明らかになります。

1. コンテナアーキテクチャ: 偽装された ZIP パッケージ

圧縮アルゴリズム自体を理解する前に、モダンな文書フォーマットが単独の生ファイルではなくパッケージとして構成されている理由を理解することが役立ちます。

レガシーバイナリ形式の問題

1990 年代から 2000 年代初頭にかけて、Microsoft Office は独自のバイナリ形式（.doc、.xls、.ppt）を使用していました。これらのファイルは本質的に、Compound File Binary Format（CFBF）を基盤としたメモリダンプでした。これらは非常に壊れやすいことで悪名高かったです：

  • 1 ビットの反転だけでファイル全体の構造が破損する可能性があります。
  • 画像を埋め込むと、ファイルサイズが予測不可能に急増しました。
  • 解析には、密集したバイナリ仕様のリバースエンジニアリングが必要でした。
  • クロスプラットフォームの相互運用性は悪夢のようでした。

オープンでモジュラーなコンテナへのシフト

2000年代半ばに、2つの平行した進化が起こりました。

  1. Office Open XML (OOXML / ISO/IEC 29500): Microsoft は x で終わる XML ベースのフォーマット（DOCX、XLSX、PPTX）を導入しました。内部では、これらのファイルは Open Packaging Conventions (OPC) に従っています。
  2. EPUB (IDPF / W3C): デジタル出版は、独自のリーダーフォーマットから、標準的なウェブ技術（HTML、CSS、SVG）を EPUB Open Container Format (OCF) にまとめた形へと移行しました。

両方のアーキテクチャは標準の PKZIP 2.0 / ZIP 仕様 に依存しています。ファイル拡張子は、期待されるスキーマ、デフォルトのビューアアプリケーション、そして MIME タイプの宣言を単に示すだけです。

Sample DOCX File (Unzipped):
├── [Content_Types].xml        <-- Registry of MIME types for parts
├── _rels/                     <-- Package-level relationships
│   └── .rels
├── docProps/                  <-- Core and extended metadata
│   ├── app.xml
│   └── core.xml
└── word/                      <-- Main content payload
    ├── document.xml           <-- Text, paragraphs, and tags
    ├── styles.xml             <-- Typography and presets
    ├── numbering.xml          <-- Lists and counters
    ├── media/                 <-- Embedded images (PNG, JPG)
    └── _rels/
        └── document.xml.rels  <-- Internal hyperlinks & resource pointers

2. フードの下のエンジン: DEFLATE アルゴリズム

ソフトウェアアプリケーションが DOCX や EPUB ファイルを保存する際、単にファイルを非圧縮アーカイブに格納するだけではありません。内部資産を DEFLATE（RFC 1951 で規定）を使用して圧縮します。

DEFLATE は、2 つの基本的なコンピュータサイエンスアルゴリズムを組み合わせた二層のロスレス圧縮システムです。

ステップ 1: LZ77 (Lempel-Ziv 1977) — スライディングウィンドウによる冗長除去

XML と HTML は非常に冗長です。標準的な document.xml や chapter1.xhtml ファイルでタグがどれだけ頻繁に出現するか考えてみてください。

  • <w:p><w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t> は Word で何千回も繰り返されます。
  • row r=\"1\" spans=\"1:15\"><c r=\"A1\" t=\"s\"><v> は Excel で数万のセルにわたって繰り返されます。
  • <p class=\"calibre1\"><span class=\"body-text\"> は EPUB 書籍の章全体で繰り返されます。

LZ77 はスライディング辞書ウィンドウ（通常は 32 KB）を使用してデータストリームを走査します。最近見た文字列に遭遇すると、重複したテキストを小さな逆方向ポインタに置き換えます：

  • (distance, length) — 例: “142 バイト戻り、28 バイトコピー”。

冗長なマークアップを何度も保存する代わりに、LZ77 は何千もの繰り返し XML タグをコンパクトな座標参照に圧縮します。

ステップ 2: ハフマン符号化 — 可変長周波数エンコーディング

LZ77 が冗長なシーケンスを長さ-距離トークンに置き換えた後、ハフマン符号化 はストリーム内のすべてのシンボルの出現頻度を解析します：

  • 頻繁に出現するシンボル（一般的な文字 e、t、スペース、または一般的な距離マーカーなど）は、短いバイナリビットコード（例: 2〜4 ビット）に割り当てられます。
  • まれに使用されるシンボルは、より長いバイナリビットコード（例: 12〜16 ビット）を受け取ります。

結果は可変長ビットコードのストリームで、プレーンテキストXMLを 75% から 88% 圧縮します。

3. フォーマット別の内訳: 各フォーマットが圧縮をどのように処理するか

DOCX、XLSX、PPTX、EPUB はすべて同じ ZIP コンテナを使用しますが、内部データの特性は大きく異なります。

A. DOCX: テキストとスタイリングのバランス調整

  • 内容: プレーンXML（word/document.xml）、フォントテーブル、スタイル、リレーションシップカタログ、そして word/media/ フォルダー。
  • 圧縮の動作:
    • 生テキストとXMLマークアップは大幅な圧縮率を示します（しばしば 5 MB の生XMLが 500 KB にまで減少します）。
    • しかし、最新の文書にはスクリーンショット、イラスト、写真が埋め込まれることが多いです。JPEG および PNG ファイルは すでに圧縮されている ため、DEFLATE ではそれ以上縮小できません。実際、すでに圧縮された画像に DEFLATE を適用しても実質的に 0% の節約しか得られず（圧縮ヘッダーによりサイズがわずかに増加することさえあります）。
    • その結果、画像を含まない DOCX ファイルは非常に小さく、画像が多いレポートは含まれる画像ファイルのサイズとほぼ同じ大きさになります。

B. XLSX: 大容量数値データと共有文字列

スプレッドシートは独自の課題を抱えています。シートには数十万行が含まれることがあり、賢く処理しないと XML ファイルサイズが天文学的に大きくなります。

  • 共有文字列戦略（xl/sharedStrings.xml）:
    • スプレッドシートで「United States」や「In Progress」のようなテキストラベルが 50,000 回出現する場合、<c t="inlineStr"><is><t>United States</t></is></c> を 50,000 セルに保存すると、圧縮されていない XML がギガバイト単位に膨れ上がります。
    • Excel は圧縮前にテキストを重複排除し、すべてのユニークな文字列を共有文字列テーブルに一度だけ格納し、数値インデックス（例：<v>0</v>, <v>1</v>）で参照します。
  • XLSX が劇的に圧縮される理由:
    • 数値行レコード（sheet1.xml）は繰り返し可能で予測可能な構文に従います。
    • DEFLATE は表形式 XML の繰り返しパターンを簡単に検出します。120 MB の生の sheet1.xml ファイルが XLSX アーカイブ内で 6 MB 未満に縮小することは一般的です。

C. PPTX: メディアが多いスライドデック

プレゼンテーションは文書やスプレッドシートとは根本的に異なります：

  • 画像のジレンマ: PPTX ファイルは通常、ベクターシェイプ、背景グラフィック、ビデオクリップ、高解像度スライドが中心です。
  • 圧縮プロファイル: ppt/slides/slide1.xml から slideN.xml までが効率的に圧縮される一方、メディアペイロード（ppt/media/）は全体のアーカイブ重量の 85% から 95% を占めます。
  • PPTX を再圧縮しても何も変わらない理由: 7-Zip や WinRAR で既に保存された PPTX ファイルを圧縮しようとしても、サイズの減少はほとんど見られません。内部はすでに DEFLATE 圧縮された ZIP アーカイブで、事前に圧縮された JPEG と MP4 を含んでいるため、エントロピーはすでにほぼ最大です。

D. EPUB: 必須の非圧縮ヘッダーを伴うウェブ技術

EPUB ファイルは本質的に、XHTML 章、CSS スタイルシート、TTF/WOFF フォント、メタデータを含むレスポンシブなパッケージ化されたマイクロウェブサイトです。ただし、EPUB には Microsoft Office ファイルと区別する厳格なパッケージング規則が 1 つあります。

EPUB Internal Structure:
├── mimetype                    <-- MUST be uncompressed (Stored) & at byte offset 38
├── META-INF/
│   └── container.xml           <-- Tells reader where the OPF manifest lives
└── OEBPS/ (or EPUB/)
    ├── content.opf             <-- Manifest of all book assets
    ├── toc.ncx / nav.xhtml     <-- Table of contents navigation
    ├── styles/style.css        <-- CSS formatting
    ├── images/                 <-- Book cover & illustrations
    └── text/                   <-- chapter1.xhtml, chapter2.xhtml
  • 魔法の mimetype ファイル:
    • 電子書籍リーダーは、アーカイブ全体を展開したり解凍パイプラインを実行したりせずに、EPUB を即座に識別する必要があります。
    • Open Container Format (OCF) は mimetype ファイルが以下を満たすことを義務付けています：
      1. ZIP アーカイブ内で最初のファイルでなければなりません。
      2. 正確に文字列 application/epub+zip を含んでいなければなりません。
      3. 圧縮してはいけません (ZIP 圧縮方式 0 / “Stored”).
      4. 余分なフィールドデータがなく、MIME 文字列が常に物理ファイルのバイト 38 から開始することを保証します。
  • テキスト圧縮: 残りのすべてのファイル (.xhtml, .css, .opf) は標準 DEFLATE (ZIP 方法 8) を使用して圧縮され、フルレングスの小説を数百キロバイトまで縮小できます。

4. フォーマット間の圧縮比較

形式コアペイロード主要冗長ソース典型的な圧縮率（テキスト/マークアップ）メディア処理
DOCXWordprocessingML（document.xml）繰り返しのXML段落/ランタグ75% – 85%word/media/ に保存（主に事前圧縮）
XLSXSpreadsheetML（sheet*.xml）繰り返しのセル/行タグ; 共有文字列80% – 92%まばら; xl/media/ 内の画像/チャート
PPTXPresentationML (slide*.xml)スライドレイアウトメタデータ、シェイプ座標70% – 80%重い ppt/media/ ペイロードが全体の節約を制限します
EPUBXHTML, CSS, OPF, NCXHTMLタグ、繰り返しのCSSセレクタ65% – 80%mimetype は圧縮されていません; メディアはサブフォルダにあります

5. 実践的な要点: ドキュメントの最適化方法

内部パッケージングの仕組みが分かったので、圧縮メカニズムを活用して実際の問題を解決できます:

  1. 文書の破損修正: 文書が開かない場合、拡張子を .zip に変更すると、内容を抽出し、document.xml から生のテキストや、EPUB の text/ ディレクトリ内の個別章を復元できます。
  2. 巨大なOfficeファイルの縮小: XML 圧縮はすでに最適化されているため、巨大なファイルはほとんどの場合、media/ 内の最適化されていない画像が原因です。サードパーティの PDF や DOCX 圧縮ツールを使用するのではなく、ZIP コンテナを開き、画像を抽出し、画像最適化ツール（WebP、TinyPNG、MozJPEG など）で圧縮し、アーカイブ内に置き換えてください。
  3. ドキュメント生成の自動化: 開発者はレポート作成に重厚なオフィススイートは必要ありません。生の XML テンプレートを生成し、標準の zlib/ZIP ライブラリでバンドルし、数ミリ秒で有効な DOCX または XLSX ファイルをプログラム的に出力できます。

6. よくある質問 (FAQ)

DOCX または EPUB をファイル拡張子を変更するだけで ZIP ファイルに変換できますか？ はい; 拡張子を .zip に変更すると、7-Zip、macOS Archive Utility、Windows Explorer などの標準アーカイブツールで内部ファイルを直接開いて確認できます。

DOCX または PPTX を 7-Zip で圧縮しても目立って小さくならないのはなぜですか？ ファイルはすでに内部で圧縮された ZIP アーカイブで、DEFLATE でエンコードされた XML と事前に圧縮された画像を含んでいるため、外部ツールが除去できる冗長性がほとんどありません。

なぜEPUB仕様では mimetype ファイルを圧縮しないことが要求されるのですか？ これにより、eリーダーソフトウェアは圧縮エンジンを初期化することなく、固定バイトオフセットでMIME文字列をチェックして、ファイルが正規のEPUBであることを検証できます。

Excelでセルの書式設定を変更すると、圧縮されたXLSXファイルのサイズが増加しますか？ はい。広範なカスタム書式設定はセル間の均一なパターン繰り返しを壊し、より長いXML定義を生成してDEFLATEの圧縮効率を低下させます。

WordやPowerPointファイルから品質を損なうことなく高解像度のオリジナル画像を抽出することは可能ですか？ はい。ファイル名を .zip に変更し、word/media または ppt/media フォルダーを開くと、挿入時と同じオリジナルの非圧縮画像が見つかります。

関連項目