LASSIC Media らしくメディア
データ圧縮とは｜gzipなど仕組みと使いどころ
Webサイトの表示が遅い、通信量や保存容量がひっ迫している。システム開発の発注担当者やプロジェクトマネージャーが、開発会社との打ち合わせでよく耳にする悩みです。その対策としてしばしば挙がるのが「データ圧縮」ですが、gzipやZIP、JPEGといった語が並ぶだけで、何がどう小さくなっているのかまで説明できる方は限られるでしょう。設定の妥当性を自分では判断できず、開発会社の提案をそのまま受け入れるしかない、という状況になりやすいテーマでもあります。
本記事では、データ圧縮の基本的な仕組みと、可逆圧縮・非可逆圧縮という2つの方式の違い、Webや通信・保存の現場での使いどころを整理します。データを保存・転送用の形式に変換するシリアライズや、クラウドの転送量に伴うコスト最適化は対象外とし、圧縮そのものの仕組みに絞って解説を進めます。開発会社との会話やレビューで、設定の妥当性を判断する材料としてお使いください。専門的な実装の詳細ではなく、発注側が押さえておきたい勘所に絞って解説します。
この記事のポイント
- データ圧縮は、繰り返しや規則性を利用してデータの容量を抑える処理です。
- 可逆圧縮と非可逆圧縮では、展開したときに元のデータへ戻るかどうかが異なります。
- Webの表示速度は、gzipやBrotliによる転送データの圧縮と画像形式の選び方に左右されます。
データ圧縮とは何か
データ圧縮とは、データの中にある繰り返しや規則性を利用して、元の内容を保ったまま、または一部を削って、データの大きさを小さくする処理です。
なぜこの処理が必要になるのでしょうか。理由は大きく3つに整理できます。ネットワークを流れる通信量を抑えること、ディスクやストレージの保存容量を抑えること、そして画面表示にかかる時間を縮めることです。この3つは互いに独立した効果ではなく、転送量が減れば表示も速くなる、というようにつながっている点にも注目したいところです。
発注担当者やプロジェクトマネージャーの立場からは、開発会社が提示する設計や構成のなかに、圧縮の扱いが適切に組み込まれているかを見る視点が欠かせません。転送データ量が膨らんだままだと、通信費や表示速度に跳ね返ってくるからです。
逆に言えば、圧縮の基本的な考え方さえ押さえておけば、専門的な実装の詳細を知らなくても、開発会社の提案が理にかなっているかどうかを判断する手がかりになります。次の章から、その考え方を順に見ていきましょう。
近年はスマートフォンやタブレットなど、回線速度が変わりやすい端末からのアクセスが増えています。同じページであっても、通信環境によって表示までの時間に差が出やすくなっているのです。転送データ量をあらかじめ抑えておくことは、こうした差を小さくし、閲覧環境によらず表示の体感速度を安定させるための土台になるでしょう。
保存容量の面でも、圧縮の扱いは無視できません。ログデータやバックアップファイルのように、日々積み上がっていく種類のデータでは、圧縮の有無によって必要なストレージ容量が大きく変わってきます。運用が長期化するシステムほど、初期段階で圧縮の方針を決めておく意味は大きくなるでしょう。
クラウドのストレージサービスを利用する場合、保存容量や転送量に応じて費用が発生する契約が一般的です。圧縮によってデータの容量を抑えておくことは、こうした費用の増減にも間接的に関わってきます。ただし料金体系そのものの見直しやプラン選定は、本記事が扱う圧縮の仕組みとは別の検討事項として扱う必要があります。
可逆圧縮と非可逆圧縮の違い
データ圧縮には、大きく分けて可逆圧縮と非可逆圧縮という2つの方式があります。何を優先するかによって、使い分けが変わってくるのです。
可逆圧縮は、圧縮したデータを展開すると、元のデータがそのまま復元される方式です。ZIPやgzipが代表例で、テキストファイルやプログラムのソースコードなど、1ビットの違いも許されないデータに使われます。
非可逆圧縮は、人の目や耳で認識しにくい成分を削り、展開しても元とは異なるデータになる方式です*1。JPEGやMP3が代表例で、画像・音声・動画のように、細部が多少変わっても実用上支障が出にくいデータに向いています。
| 観点 | 可逆圧縮 | 非可逆圧縮 |
|---|---|---|
| 復元性 | 展開すると元のデータに戻る | 展開しても元には戻らない |
| 代表形式 | ZIP・gzip | JPEG・MP3 |
| 向くデータ | テキスト・プログラムのソースコード | 写真・音声・動画 |
| 圧縮の度合い | データの規則性に左右され、比較的小さい | 品質設定を下げるほど大きくでき、比較的大きい |
| 主な用途 | 文書・設計データ・ソフトウェアの配布 | Web掲載用の写真・配信用の動画や音声 |
この違いを押さえておくと、発注時の要件整理や仕様レビューがしやすくなります。数値データや契約書のPDFなど、内容が変わってはいけない資料には可逆圧縮を、写真や動画のように情報量を多少削っても業務に支障がない素材には非可逆圧縮を、という判断軸が立てられるでしょう。逆の組み合わせを選んでしまうと、後から気づいても取り返しがつかない場合があります。
たとえば、注文データをCSV形式でやり取りする場面を考えてみましょう。数値や項目名が少しでも変わってしまうと、受け取った側のシステムが誤動作しかねないのです。こうしたデータは可逆圧縮でやり取りするのが基本だといえます。一方、商品ページに載せる写真のように、多少の情報量を削ってもファイルサイズを優先したい素材では、非可逆圧縮で容量を抑える判断が成り立つでしょう。どちらを選ぶかは、データの性質を基準に決めることが大切です。
なお、可逆圧縮の中にも複数の方式があります。ZIPは複数のファイルをまとめて1つの圧縮ファイルにする用途でよく使われ、gzipは主に単一のファイルやデータの中身を圧縮する用途で使われる、という違いがあります*2。用途に応じて選ばれている点は覚えておくとよいでしょう。
非可逆圧縮についても、削る成分の選び方に幅があります。写真であれば色の細かな階調を、音声であれば人の耳で聞き取りにくい周波数帯を、それぞれ優先的に削る、という考え方が採られています。削り方の巧拙によって、同じ圧縮率でも見た目・聞こえ方の粗さに差が出るのです。
非可逆圧縮の設定には、たいてい「品質」を示す数値やレベルが用意されています。この数値を高くするほど元の情報を多く残せる一方でファイルサイズは大きくなり、低くするほどファイルサイズは小さくなる代わりに粗さが目立ちやすくなる、という関係にあります。用途に応じてどのあたりで折り合いをつけるかが、実務上の判断どころです。
データが小さくなる仕組み
圧縮というと難しい計算を思い浮かべるかもしれませんが、考え方の骨格は意外にシンプルです。大きく2つの発想が土台になっています。
1つ目は、繰り返しの置き換えです。「AAAAA」のように同じ値が連続する部分を「Aが5回」という短い表現に置き換えることで、データ全体の長さを縮めます。文章や画像には、こうした繰り返しの部分がしばしば含まれています。
2つ目は、出現頻度に応じた符号化です。よく出てくる値には短い符号を、めったに出てこない値には長い符号を割り当てることで、全体のデータ量を減らす考え方です。gzipはこうした発想をもとに設計された、可逆圧縮の代表的な形式の1つで、IETFの仕様として定義されています*2。細かなアルゴリズムの違いは発注担当者が押さえる範囲を超えるため、ここでは深追いしません。
身近な例で考えると分かりやすいかもしれません。文章の中で「の」や「は」のようによく出てくる文字には短い符号を割り当て、めったに出てこない文字には長い符号を割り当てれば、文章全体を表すのに必要な符号の長さは短くなります。
図の上段が可逆圧縮、下段が非可逆圧縮の流れです。どちらも元データを圧縮して小さくする点は同じですが、展開したときの結果が異なります。可逆圧縮は元通りに戻り、非可逆圧縮は一部の情報が戻らないまま確定する、という違いを覚えておくとよいでしょう。
こうした置き換えや符号の割り当ては、人が手作業で行うものではなく、圧縮のプログラムが機械的かつ大量のデータに対して実行しています。だからこそ、私たちは意識しないまま、日々圧縮の恩恵を受けているといえるでしょう。
データの中身によって、どれだけ小さくなるかも変わってきます。同じ値が長く続く単調なデータは大きく縮みやすく、値がばらばらに変化するデータはあまり縮みません。圧縮率が期待したほど出ない場合、データそのものの性質に原因があることも少なくないのです。
この性質は、開発会社から「このデータは思ったほど圧縮できない」と説明を受けたときの理解にも役立ちます。すでに情報が整理・要約されたデータや、暗号化済みのデータは、繰り返しや規則性が乏しいため、圧縮をかけてもサイズがあまり変わらない傾向があるのです。
Webでの使いどころ
Webの世界では、データ圧縮はページの表示速度を左右する要素として扱われています。代表的な使いどころを見ていきましょう。
HTMLやCSS、JavaScriptといったテキストベースのファイルは、サーバーとブラウザの間でgzipやBrotliという方式によって圧縮され、転送データ量を縮めた状態でやり取りされます*3。これはHTTPのContent-Encodingという仕組みで実現されていて、ブラウザが対応する方式をサーバーに伝え、サーバーが選んだ方式で応答する、という手順が踏まれます*4。
| 方式 | 特徴 | 向く場面 |
|---|---|---|
| gzip | 対応環境が広く、実績が長い方式 | 幅広いクライアントへの配信 |
| Brotli | 同程度の設定でgzipより小さくなりやすい*5 | 主要ブラウザ向けの配信 |
画像についても、形式の選び方が転送量を左右します。写真のように色や濃淡が複雑な画像はJPEGなどの非可逆圧縮形式が向き、ロゴやアイコンのように単色主体の画像は、可逆圧縮のPNGが向く、といった使い分けが一般的です。
近年はWebPやAVIFといった、従来のJPEGやPNGより小さい容量で同程度の見た目を保ちやすい画像形式も使われるようになりました。対応するブラウザは広がっているものの、古い環境での表示を考えると、非対応時にJPEGへ切り替える設定と組み合わせて使うのが実務的です。新しい形式への切り替えは、既存の画像資産を作り直す作業を伴うことがあるため、対象範囲と作業量を事前に見積もっておくとよいでしょう。
CDNを利用する構成では、配信元のサーバーではなく、CDNのエッジ側で圧縮を担う設定もよく使われます。どちらの層で圧縮を担わせるかによって、キャッシュの動き方や運用の手間が変わってくるため、構成図とあわせて確認しておくとよいでしょう。複数のCDN・サーバーが連なる構成では、どの層で圧縮済みかを取り違えると、二重圧縮や設定漏れに気づきにくくなる点にも注意が必要です。
動的コンテンツと静的コンテンツで扱いを分ける
HTMLのように都度生成されるコンテンツと、画像や動画のようにあらかじめ用意しておける静的なコンテンツとでは、圧縮の組み込み方が違います。静的コンテンツは配信前に圧縮済みのファイルを用意しておく方法が広く使われ、都度の処理負荷を抑えられるでしょう。動的コンテンツは生成のたびに圧縮するため、負荷試験の対象に含めておくことが欠かせません。
圧縮の状態は開発者ツールで確認できる
配信データが実際に圧縮されているかどうかは、ブラウザの開発者ツールでレスポンスヘッダーのContent-Encodingを見れば分かります*4。圧縮されていない場合はこの項目が表示されないか、identityという値になっているため、公開後の確認項目として組み込んでおくとよいでしょう。
ここで見落とされがちなのが、圧縮と処理負荷のトレードオフです。圧縮率を上げるほど、圧縮や展開にかかるCPUの負荷は増えていきます。アクセスが集中する場面で圧縮設定を上げすぎると、サーバー側の処理が重くなり、かえって応答が遅くなることもあるため、転送量の削減と処理負荷のバランスを見て設定する必要があります。
通信そのものが暗号化されている場合でも、圧縮の扱いは別途考える必要があります。暗号化と圧縮を組み合わせる順序や設定によっては、想定した圧縮効果が得られないことがあるため、開発会社に構成の意図を確認しておくとよいでしょう。
発注・レビューで押さえる点
データ圧縮そのものを一から実装する場面は多くありません。ほとんどは、Webサーバーやフレームワークに備わる圧縮機能を有効にし、画像・動画の扱い方を方針として決める作業になります。発注・レビューの段階で確認しておきたい点は次の通りです。
配信データの圧縮設定を確認する
WebサーバーやCDNの多くは、gzipやBrotliによる圧縮を設定で有効にできます。開発会社に依頼する際は、この設定が有効になっているか、対応方式は何かを、仕様に明記してもらうとよいでしょう。設定漏れがあると、圧縮できるはずの転送量がそのまま残ってしまいます。
特にAPI連携でやり取りするJSON形式のレスポンスは、同じキー名や似た構造の繰り返しが多く、圧縮の効果が出やすいデータです。画面表示用のHTMLだけでなく、API応答の圧縮設定が漏れていないかも、あわせて確認しておく必要があります。社内システムどうしの連携では見落とされがちな設定なので、外部公開の有無にかかわらず点検の対象に含めておくとよいでしょう。
画像・動画の形式と品質の方針を決める
画像・動画は非可逆圧縮を使う場面が多く、圧縮の度合いを上げるほど見た目の粗さが増します。どこまで品質を落とせるかはサイトの用途によって変わるため、公開前に確認用の画面で見え方をチェックする工程を組み込むことが望まれます。
動画については、配信前にエンコード設定で解像度やビットレートを調整する工程が入ります。撮影した素材の解像度をそのまま使うと、実際に視聴される画面の大きさに対して過剰な容量になっている場合があるため、配信用途に応じた設定を開発会社に確認しておくとよいでしょう。
圧縮解凍の処理負荷を見積もる
圧縮率の高い設定は、サーバー側の処理負荷を押し上げます。アクセスが集中する時間帯を想定した負荷試験の対象に圧縮処理を含めておくと、公開後の想定外の遅延を防ぎやすくなるでしょう。
動的にページを生成するシステムでは、圧縮処理がリクエストのたびに発生します。あらかじめ圧縮済みのファイルを用意しておくやり方と、都度その場で圧縮するやり方とでは、サーバー側の負荷のかかり方が異なるため、アクセス規模に応じた選択が求められます。
非可逆で品質が要る素材を見分ける
契約書のPDFや数値データのように、内容が変わってはいけない資料には可逆圧縮を使う必要があります。誤って非可逆圧縮の設定で扱うと、後から内容の欠落に気づいても元には戻せません。素材の性質ごとに圧縮方式を分けて管理する運用が欠かせないのです。
医療画像や設計図面のように、細部の情報がそのまま業務の判断材料になる素材も、可逆圧縮を選ぶべき対象です。見た目が似ていても、拡大した際の粗さが業務に影響するかどうかを基準に、圧縮方式を選び分ける視点を持つとよいでしょう。判断に迷う素材については、あらかじめ関係者間で「戻せなくなっても構わないか」を確認しておくと、後工程での認識違いを防げます。
圧縮の方針を仕様書に落とし込む
ここまでの確認事項は、口頭の合意だけで終わらせず、仕様書やチェックリストに明文化しておくことが望まれます。担当者が変わっても同じ基準で判断できるようにしておけば、後工程での認識違いを防ぎやすくなるでしょう。特に複数の開発会社が関わるプロジェクトでは、圧縮方式や品質基準の認識が会社間でずれていないかを、要件定義の段階で突き合わせておくことが望ましいといえます。
まとめ
ここまでの内容を、判断に使える形で振り返ります。データ圧縮は仕組みそのものが難解というより、可逆・非可逆という2つの方向性と、転送量・処理負荷のバランスをどう取るかという判断の積み重ねだといえるでしょう。
- データ圧縮は、繰り返しや規則性を利用してデータを小さくする処理で、通信量・保存容量・表示速度の節約につながる。
- 可逆圧縮は元通りに復元でき、非可逆圧縮は一部の情報が戻らない。資料の性質に応じて使い分ける。
- Webではgzip・Brotliによる転送データの圧縮と、画像形式の選択が表示速度を左右する。
- 圧縮率と処理負荷はトレードオフの関係にあり、設定を上げすぎると応答が重くなる場合がある。
- 発注・レビューでは、配信データの圧縮設定、画像・動画の品質方針、処理負荷の見積もりを確認する。
- 複数の開発会社が関わる場合は、圧縮方式・品質基準の認識を要件定義の段階で仕様書に落とし込んでおく。
よくある質問
データ圧縮すると、画質や音質はどの程度落ちますか。
落ち方は圧縮の方式と設定しだいです。可逆圧縮であれば画質・音質は変わりません。非可逆圧縮の場合は、圧縮率を上げるほど元との違いが大きくなり、極端に上げるとブロックノイズのような粗さが目立つようになります。素材の種類や用途によって許容できる粗さは異なるため、一律の基準ではなく個別に見え方を確かめることが大切です。公開前に見え方・聞こえ方を確認する工程を挟んでおくとよいでしょう。
gzipとBrotliは、どちらを選べばよいですか。
Web表示速度の観点では、Brotliのほうが同じ内容でも転送データを小さくしやすい方式です*5。ただし対応状況はサーバーやCDNの設定に左右されるため、両方に対応したうえでBrotliを優先し、対応していないクライアントにはgzipで応答する構成が現実的でしょう。モバイル回線など通信環境が不安定な場面ほど、転送データを小さくできる利点を実感しやすくなります。既存のサーバー構成にBrotliを追加する場合は、対応バージョンの確認や設定変更が必要になるため、開発会社と作業範囲をすり合わせておくと進めやすくなります。
圧縮を強めるほど、サイトは軽くなりますか。
転送データ量は小さくなりますが、軽くなるとは言い切れません。圧縮の設定を上げるほど、圧縮や展開にかかるサーバー側の処理負荷も増えるためです。アクセスが集中する場面では、この処理負荷が応答時間を押し上げることがあり、転送量と処理負荷のバランスを見て設定する必要があります。具体的な圧縮レベルは、CPU使用率と応答時間を計測しながら段階的に調整するのが現実的な進め方です。
すでに圧縮済みのファイルを、さらに圧縮する意味はありますか。
ほとんど意味がありません。JPEGやZIPのようにすでに圧縮された形式は、繰り返しや規則性がすでに取り除かれているため、重ねて圧縮してもサイズはほとんど変わらないのです*4。むしろ処理の手間が増えるだけになりやすいため、圧縮済みの形式には追加の圧縮をかけない設定にしておくのが実務的です。動画や音声も同様で、非可逆圧縮された配信用ファイルをZIPでまとめても、容量はほとんど縮みません。WebサーバーやCDNの設定を見直す際は、こうした「すでに圧縮済みの拡張子」を圧縮対象から除外できているかも、あわせて確認しておくとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、Webサーバーの圧縮設定の見直しから画像・動画の配信方針の整理、実装後の負荷確認までを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。既存システムの構成を把握したうえで、圧縮設定や画像・動画のエンコード方針を段階的に見直す進め方にも対応します。表示速度や転送量の見直しでお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
出典
- Wikipedia「データ圧縮」
- IETF RFC 1952「GZIP file format specification version 4.3」
- MDN Web Docs「HTTP の圧縮」
- MDN Web Docs「Content-Encoding」
- web.dev「Reduce network payloads using text compression」
