シュリンクとは｜ビジネス・ITでの意味とDBが縮まない理由を実測

「シュリンク」は、何が縮むのかで意味が決まる言葉です。会議で聞いたのか、設計書やコマンドで見たのか、商品の説明で見たのかで、次のように読み分けます。この記事で実際に動かしたものは、SQLite と PostgreSQL のファイルサイズの計測、開いたままのファイルを消したときの空き容量、resize2fs でのファイルシステムの縮小、JavaScript と画像の縮小です。

flowchart TD
    A[シュリンクと聞いた] --> B{何が縮むか}
    B --> C[市場<br>売上]
    B --> D[ファイル<br>DB・領域]
    B --> E[フィルム]
    C --> F[規模の縮小]
    D --> G[容量の縮小]
    E --> H[包装]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Python 3.13.18 に同梱の SQLite 3.53.1、PostgreSQL 16.15（127.0.0.1 だけで待ち受け、autovacuum は計測のため off）、e2fsprogs 1.47.0 の mke2fs・resize2fs・e2fsck（マウントせず、通常のファイルをイメージとして使用）、Node.js v22.23.4 と terser 5.51.2、Pillow 12.3.0 を動かし、ファイルサイズと出力を記録しました。ディスクの空きの確認は tmpfs（/dev/shm）で行っています。SQL Server の DBCC SHRINKDATABASE と Windows の「ボリュームの縮小」は手元で動かしておらず、Microsoft Learn の記載の範囲で書いています。言葉の意味はデジタル大辞泉、プログレッシブ英和中辞典、Merriam-Webster で確かめました（確認日 2026年11月11日）。

シュリンクとは（意味と語源）

この節では、シュリンクという言葉のもとの意味と、英語 shrink の語源・活用が分かります。

シュリンクは、英語の shrink をカタカナにした言葉で、「縮むこと・縮小すること」を表します。 デジタル大辞泉は「縮むこと。萎縮すること。」と説明しています。日本語では「市場がシュリンクする」「ボリュームをシュリンクする」のように「する」を付けて動詞として使うことが多く、縮む（自動詞）にも縮める（他動詞）にも使われます。

語義と活用はプログレッシブ英和中辞典（第5版）、語源は Merriam-Webster の記載です。Merriam-Webster は動詞の最初の用例を「12世紀より前」としており、もともとは体を縮こまらせる意味でした。「小さくなる」「量や価値が減る」という意味はそこから広がったものです。

カタカナの「シュリンク」が使われる場面

日本語の文章では、ふつうは「縮小」「減少」と書けば通じます。カタカナのシュリンクがよく出てくるのは、次の3つの場面です。

分野別のシュリンクの意味（一覧表）

この節では、分野ごとに「何が縮むのか」を1つの表で見比べられます。

シュリンクの意味を取り違えないための問いは、「何が縮むのか」の1つだけです。 ふだんの意味と、ビジネス・IT・包装などでの意味を並べます。

ビジネスでのシュリンクの意味と使い方（市場・売上・予算）

この節では、ビジネスの会話で使うシュリンクの意味と、数字で話すときの計算が分かります。

ビジネスでのシュリンクは、市場・売上・予算・サービスの規模が小さくなることです。 「減った」という1回の結果より、「縮んでいく流れ」を言うときに使われます。たとえば「紙のカタログの市場はシュリンクしている」は、需要の総量が年々小さくなっているという意味です。

市場のシュリンクと、自社のシェアは別の話

市場が縮むことと、自社の売上が減ることは同じではありません。市場規模 × シェア ＝ 売上 と分けると、どちらが原因かを話しやすくなります。市場規模を 1,000（単位は億円でも件数でも同じ）として、年率で縮む場合を計算しました。

シェアが20%のまま、市場が年率3%で5年縮むと、売上は 200 から 171.7 になります。売上 200 を保つには、シェアを 23.3% まで上げる計算です。「売上が落ちた」という報告に対して、市場がシュリンクしたのか、シェアが下がったのかを分けて見る、というのがこの言葉の使いどころです。

予算・サービスのシュリンク

自分たちで規模を小さくする場合にも使います。「来期は広告の予算をシュリンクする」「利用の少ない機能をシュリンクして保守の手間を減らす」のような言い方です。この場合は意図して縮めているので、「縮小する」「絞り込む」と書いたほうが、理由と範囲が伝わります。

• 何が：市場全体か、自社の売上か、予算か、提供する範囲か
• どれだけ：金額・件数・割合と、いつからいつまでの比較か
• なぜ：外の要因（需要の変化）か、自分たちの判断か

この3点を添えると、「シュリンク」という1語で済ませたときの行き違いを防げます。

シュリンクの例文と言い換え（縮小・減少・圧縮・スケールダウンとの違い）

この節では、シュリンクの使い方の例文と、言い換えの言葉との違い、対義語が分かります。

社外向けの文書や議事録では、「縮小」「減少」と日本語で書くほうが誤解されにくくなります。 カタカナのまま使うなら、主語（何が縮むのか）を必ず書きます。

例文

言い換えの言葉との違い

シュリンクと圧縮の違いは、「枠を小さくする」か「中身の表し方を変える」かです。 100GB のボリュームを 60GB にシュリンクしても、中のファイルの内容は変わりません。zip で圧縮すると、中身の表し方が変わり、使う前に展開が要ります。サーバーの規模を下げる話は、関連記事「スケールアップとスケールアウトの違い｜負荷分散方式の一覧と選び方」で扱っています。

対義語

シュリンクの反対は、ビジネスでは「拡大」「成長」、ITの操作では「拡張」です。英語では expand（広げる）、grow（育つ・増える）、extend（延ばす）が対になります。Windows の「ボリュームの縮小」の反対の操作は「ボリュームの拡張」です。

ITでのシュリンクの意味（何を縮めるかの一覧）

この節では、ITでシュリンクと呼ばれる操作の種類と、共通する考え方が分かります。

ITのシュリンクは、「確保してある枠」を小さくして、空いた分をほかで使えるようにする操作です。 対象は大きく4つあります。

1〜3に共通するのは、「中身を消すこと」と「枠が小さくなること」が別々に起きるという点です。データを消しても、枠（ファイルや区画の大きさ）はそのまま残ります。枠を小さくするには、別の操作（シュリンク）を実行します。次の節から、この動きを実際に測った数字で確かめます。

1. 1データを書く → 枠が広がるファイルは必要に応じて自動で大きくなる
2. 2データを消す → 枠はそのまま空いた場所は「再利用できる」という印が付くだけ
3. 3また書く → 空いた場所が先に使われる枠は広がらない
4. 4シュリンクする → 枠が小さくなる中身を前へ詰め、末尾を OS へ返す。時間とロックがかかる

ファイルを消してもディスクの空きが増えない理由（実測）

この節では、ファイルを削除したのに空き容量が戻らないときの仕組みと、戻し方が分かります。

Linux では、ファイルを rm で消しても、そのファイルを開いているプロセスが残っている間は、領域が解放されません。 rm が消すのは名前（ディレクトリの中の項目）で、中身は「名前が0個・開いているプロセスも0個」になった時点で初めて消えます。100MB のファイルで確かめました。

0 作る前                 :   0 MB used
1 100MB のファイルを作成  : 100 MB used
2 rm（プロセスが開いたまま）: 100 MB used   ← 消したのに減らない
  $ ls app.log
  ls: cannot access '/dev/shm/t347/app.log': No such file or directory
  $ ls -l /proc/<PID>/fd
  3 -> /dev/shm/t347/app.log (deleted)
3 : > /proc/<PID>/fd/3    :   0 MB used   ← 開いたまま中身だけ空にした
4 プロセスを終了          :   0 MB used

2の時点で、ls ではファイルが見えないのに、df の使用量は 100MB のままでした。/proc/<PID>/fd には (deleted) と付いた項目が残っています。プロセスを終了するか、3のように中身を空にすると、使用量は 0MB に戻りました。

原因の探し方と対処の手順は、関連記事「Linuxでrmしても容量が減らない原因と対処法」で、df と du の読み方は関連記事「Linuxメモリ・ディスク確認｜free・df・du・vmstat・iostat見方」で扱っています。

データベースのシュリンク：SQLiteのVACUUMでファイルサイズを測る

この節では、行を削除してもデータベースのファイルが縮まないことと、VACUUM で縮むことを、SQLite の数字で確かめられます。

SQLite は、行を削除してもファイルを小さくしません。空いたページは「フリーリスト」に入り、次の INSERT で再利用されます。ファイルを小さくするのは VACUUM です。 公式ドキュメントは、auto_vacuum が無効のとき「the database file remains the same size」「the database file does not shrink」と説明しています。10万行（1行あたり100文字）で測りました。

2で行を9割消しても、ファイルは1バイトも縮みませんでした。3で3万行を足してもファイルは大きくならず、空きページが 2,378 から 1,564 に減っています。消したあとの空きは、無駄になっているのではなく、次の書き込みのために取ってある場所です。 実行したコードは次のとおりです。

import sqlite3, os
c = sqlite3.connect("a.db", isolation_level=None)
c.execute("create table t(id integer primary key, payload text)")
c.execute("begin")
c.executemany("insert into t values(?,?)", ((i, "x" * 100) for i in range(1, 100001)))
c.execute("commit")
c.execute("delete from t where id % 10 <> 0")
print(os.path.getsize("a.db"), c.execute("pragma freelist_count").fetchone())
c.execute("vacuum")
print(os.path.getsize("a.db"), c.execute("pragma freelist_count").fetchone())

11108352 (2378,)
1118208 (0,)

VACUUM の仕組みと注意点

公式ドキュメントによると、VACUUM は内容を一時的なデータベースファイルへ写し、元のファイルを上書きします。そのため、実行中は元のファイルの最大2倍の空き容量が要ります（「as much as twice the size of the original database file is required in free disk space」）。大きなデータベースほど、縮めるための空きが先に要る点に注意します。

auto_vacuum と incremental_vacuum

SQLite には、コミットのたびに自動でファイルを切り詰める auto_vacuum の設定があります。同じ10万行で3つの設定を比べました。

FULL では、DELETE をコミットした時点でファイルが 1,372,160 バイトまで縮みました。ただし VACUUM 後の 1,122,304 バイトより大きく、ページの中の隙間までは詰めていません。公式ドキュメントも、auto_vacuum は断片化を進めることがあり、VACUUM のようにページを詰め直さないと説明しています。INCREMENTAL では PRAGMA incremental_vacuum(1000) で約1,000ページ分（11,124,736 → 7,024,640 バイト）だけ縮み、引数なしで残りの空きページをすべて返しました。auto_vacuum はテーブルを作る前に設定します（あとから変えるときは、設定してから VACUUM を実行します）。SQLite の基本操作は、関連記事「SQLiteの使い方｜コマンド早見表とPython連携を実行例で解説」で扱っています。

PostgreSQLのVACUUMとVACUUM FULLの違い（実測）

この節では、PostgreSQL で「VACUUM したのにテーブルのファイルが縮まない」理由と、縮む条件が分かります。

PostgreSQL のふつうの VACUUM は、空いた場所を「再利用できる」状態にするだけで、原則として OS には返しません。ファイルを小さくするのは VACUUM FULL です。 公式ドキュメントは、標準の VACUUM について「it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free」と説明しています。10万行のテーブルで測りました。

3の VACUUM のあとも、サイズは 14,131,200 バイトのままでした。VACUUM (VERBOSE) の出力は「pages: 0 removed, 1725 remain」で、1ページも減っていません。どのページにも生きている行が残っているためです。4で5万行を足してもサイズが変わらないのは、空いた場所が再利用されたからです。6の VACUUM FULL で 1,417,216 バイト（約10%）になり、インデックスも 2,260,992 から 245,760 バイトになりました。

SELECT pg_relation_size('t') AS table_bytes,
       pg_relation_size('t_pkey') AS index_bytes,
       pg_relation_filepath('t') AS file;

-- VACUUM FULL の前
 table_bytes | index_bytes |       file
-------------+-------------+------------------
    14131200 |     2260992 | base/16384/16385

-- VACUUM FULL のあと
 table_bytes | index_bytes |       file
-------------+-------------+------------------
     1417216 |      245760 | base/16384/16392

ファイルの名前が 16385 から 16392 に変わっています。VACUUM FULL は、テーブルを詰め直した新しいファイルを書き、前のファイルと入れ替える動きです。公式ドキュメントは、VACUUM FULL が ACCESS EXCLUSIVE ロックを取ること（実行中はそのテーブルの読み書きができない）、新しい写しのぶんの空き容量が要ることを挙げています。

ふつうの VACUUM でも縮む場合（末尾が空いたとき）

公式の説明にある「特別な場合」も確かめました。同じ10万行のテーブルで、後ろ半分（id が 50,000 より大きい行）を消してから VACUUM を実行した結果です。

INFO:  table "u": truncated 1725 to 863 pages
 after_vacuum
--------------
      7069696

ファイルの末尾のページがまるごと空いたので、ふつうの VACUUM で 14,131,200 から 7,069,696 バイトに切り詰められました。縮むかどうかは、消した量ではなく、空いた場所がファイルの末尾にまとまっているかで決まります。 また、テーブルの中身をすべて消すなら、TRUNCATE を実行した直後にサイズが 0 バイトになりました。

autovacuum の監視と設定は、関連記事「PostgreSQLのVACUUMとautovacuum｜監視SQLと設定値の目安」で扱っています。

SQL ServerのDBCC SHRINKDATABASEと注意点（断片化）

この節では、SQL Server でデータベースをシュリンクするコマンドと、Microsoft が示している注意点が分かります。ここは手元で動かしておらず、Microsoft Learn の記載の範囲です。

DBCC SHRINKDATABASE は、指定したデータベースのデータファイルとログファイルのサイズを縮小するコマンドです（Microsoft Learn「Shrinks the size of the data and log files in the specified database.」）。 ファイル単位で縮めるコマンドとして DBCC SHRINKFILE もあります。

-- 構文（Microsoft Learn より。主な部分）
DBCC SHRINKDATABASE
( database_name | database_id | 0
     [ , target_percent ]
     [ , { NOTRUNCATE | TRUNCATEONLY } ]
)

「詰める」と「末尾を返す」が別の引数になっている点は、前の節までで見た SQLite・PostgreSQL と同じ考え方です。Microsoft Learn は、シュリンクについて次の注意を挙げています。

• 1通常の保守作業として扱わない「Don't consider shrink operations a regular maintenance operation.」日々の処理で大きくなったファイルは、縮小を要しないとしている
• 2インデックスの断片化が進むことがある断片化の状態は保たれず、大きな範囲を読むクエリの読み取り性能が下がる場合があるとしている
• 3縮めてもまた大きくなるなら、その空きは必要な空き繰り返し縮めるのは逆効果で、ファイルを広げ直す処理が性能の妨げになるとしている
• 4AUTO_SHRINK は、特別な理由がなければ ON にしない「Unless you have a specific requirement, don't set the AUTO_SHRINK database option to ON.」
• 5最小サイズより小さくはならない10MB で作って 100MB に増えたデータベースは、全部消しても 10MB までしか縮まないと説明されている

断片化とは、関係するデータがファイルの中で離れた場所に散らばることです。シュリンクは末尾のページを前の空いた場所へ移すので、もともと順に並んでいたページの並びが崩れることがあります。縮小のあとに読み取りが遅くなったと感じたら、インデックスの断片化の状態を確かめる、という順で考えます。

ボリュームの縮小（Windows）とresize2fs（Linux）

この節では、ディスクの区画を縮める操作の手順と、Linux の resize2fs を実際に動かした結果が分かります。

ボリュームやファイルシステムのシュリンクは、区画を末尾から縮めて、未割り当ての領域を作る操作です。 作業の前に、必ずバックアップを取ります。

Windows：ディスクの管理の「ボリュームの縮小」

Microsoft Learn の手順は次のとおりです（手元では動かしていません）。

コマンドでは、diskpart を開いて list volume → select volume 番号 → shrink desired=サイズ（MB） の順に実行します。Microsoft Learn は次の点を挙げています。

• 縮小できるのは、ファイルシステムのないベーシック ボリュームか、NTFS のベーシック ボリューム
• ページング ファイルやシャドウ コピーの保存領域のような移動できないファイルがあると、その位置までしか縮められない
• データベースのファイルなどを直接置いている生のパーティション（ファイルシステムなし）は、縮小でデータが壊れるおそれがある

Microsoft Learn の日本語版は、ページの見出しを「ベーシック ボリュームを圧縮する」、メニュー名を［ボリュームの縮小］と表記しています。この操作は、前の節の表でいう「圧縮（compress）」ではなく「縮小（shrink）」です。

Linux：resize2fs で ext4 を縮小する（実測）

resize2fs は、ext2・ext3・ext4 のファイルシステムの大きさを変えるコマンドです。マニュアルは、縮小はマウントしていない状態で行うこと、resize2fs はパーティションの大きさを変えないので、縮小するときは「先にファイルシステム、次にパーティション」の順に行うことを説明しています。64MB のイメージファイルに ext4 を作り、9MB のファイルを入れて試しました。

$ resize2fs fs.img 32M
Resizing the filesystem on fs.img to 8192 (4k) blocks.
The filesystem on fs.img is now 8192 (4k) blocks long.

$ resize2fs -P fs.img
Estimated minimum size of the filesystem: 4274

$ resize2fs fs.img 4M
resize2fs: New size smaller than minimum (4274)

$ resize2fs -M fs.img
Resizing the filesystem on fs.img to 4274 (4k) blocks.
The filesystem on fs.img is now 4274 (4k) blocks long.

$ e2fsck -f -n fs.img
fs.img: 17/16384 files (5.9% non-contiguous), 4267/4274 blocks

中のファイル（9MB）より小さい 4MB を指定すると、「New size smaller than minimum (4274)」で止まりました。-P は最小のブロック数の見積もりを表示し、-M はそこまで縮めます。縮小のあとも e2fsck は異常を報告せず、6個のファイルは残っていました。マニュアルは、最小サイズの見積もりが正しくない場合があること（特にブロックサイズが 1k・2k のとき）も注意として挙げています。-M で限界まで縮めると空きが7ブロックしか残らないので、ふだん使う区画には向きません。

ログの切り詰めと、コード・画像の縮小（minify）

この節では、ログを小さくする操作と、配信するファイルを小さくする操作を、測った数字で見比べられます。

ログの切り詰め（SQLite の WAL で実測）

ログのシュリンクは、「反映し終わって要らなくなった部分を切り捨てる」操作です。 SQLite の WAL モード（変更をいったん別のファイルに書く方式）で、2万行を書いたあとのファイルサイズを測りました。

PASSIVE のチェックポイントで中身は本体へ反映されましたが、WAL のファイルは 2,253,672 バイトのままでした。TRUNCATE を指定すると 0 バイトになります（公式ドキュメント「the WAL file is truncated to zero bytes upon successful completion」）。ここでも「反映する」と「ファイルを短くする」は別の動きです。なお、DBCC SHRINKDATABASE の NOTRUNCATE はログファイルには働かないと Microsoft Learn に書かれています。

JavaScript の minify（terser で実測）

minify は、プログラムの動きを変えずに、空白・コメント・名前を短くしてファイルを小さくする処理です。22行の JavaScript を terser 5.51.2 で処理しました。

// 元（一部）
function calculateTotalPrice(itemList, taxRate) {
  let totalPrice = 0;
  for (const currentItem of itemList) {
    const subTotal = currentItem.unitPrice * currentItem.quantity;
    totalPrice = totalPrice + subTotal;
  }
  ...

// terser -c -m --toplevel の出力（一部）
function(t,n){let o=0;for(const n of t){o+=n.unitPrice*n.quantity}const u=Math.floor(o*n);return{totalPrice:o,taxAmount:u,grandTotal:o+u}}

857 バイトが 339 バイト（40%）になりました。minify（書き方を短くする）と gzip（圧縮）は重ねて使え、両方で 269 バイトです。unitPrice のようなプロパティ名は、外から参照されるかもしれないので既定では短くなりません。

画像の縮小（Pillow で実測）

画像は、縦横のピクセル数を減らす（リサイズ）と、ファイルが小さくなります。2400×1800 の画像を JPEG（品質85）で保存して比べました。

800×600 を WebP（品質80）で保存すると 89,612 バイトでした。一方、同じ画像を PNG で縮小したところ、904,154 バイト（2400×1800）が 1,077,950 バイト（1200×900）に増えました。なめらかな模様に、縮小で中間色が増え、PNG の圧縮が効きにくくなったためと考えられます。ピクセル数を減らせば必ずファイルが小さくなるとは限らず、形式との組み合わせで結果が変わります。

シュリンクするかどうかの判断表と、よくあるエラー／つまずき

この節では、ITで「縮めるべきか、そのままにするか」の判断と、実行時に出るエラーの原文と直し方が分かります。

判断の軸は「その空きは、また使われるか」です。 また使われる空きを縮めても、次の書き込みで広げ直すことになり、手間と負荷だけが残ります。

よくあるエラー／つまずき（原文つき）

包装のシュリンク・シュリンクラップ契約・シュリンクフレーション（言葉の紹介）

この節では、ビジネスとIT以外で出会う「シュリンク」の付く言葉の意味が分かります。ここは言葉の紹介までにとどめます。

シュリンクフレーションで縮むのは内容量です。たとえば 100g の商品が同じ価格で 90g になると、1g あたりの価格は計算上 11.1% 上がります（100 ÷ 90 − 1）。シュリンクラップ契約は方式の名前で、個々の契約の扱いは、それぞれのソフトウェアの提供元が示す利用条件で確かめます。

よくある質問

この節では、シュリンクについてよく調べられる疑問の答えが分かります。

Q. シュリンクとは、簡単に言うと何ですか。
A. 「縮むこと・縮小すること」です。英語の shrink から来ています。ビジネスでは市場や売上の規模が小さくなること、ITではボリュームやデータベースのファイルを小さくする操作を指します。

Q. 「シュリンクする」はビジネスでどう使いますか。
A. 「国内の市場がシュリンクしている」のように、規模が縮んでいく流れを言うときに使います。社外向けの文書では「縮小している」「減少している」と書き、何が・どれだけ・いつと比べて、を添えると伝わりやすくなります。

Q. シュリンクの言い換えと対義語は何ですか。
A. 言い換えは「縮小」「減少」「収縮」です。対義語は「拡大」「成長」「拡張」で、英語では expand・grow・extend が対になります。

Q. シュリンクと圧縮は同じですか。
A. 違います。シュリンクは区画やファイルの「枠」を小さくすること、圧縮は中身の表し方を変えて量を減らすことです。圧縮したファイルは、使う前に展開が要ります。

Q. データを削除したのに、データベースのファイルが小さくならないのはなぜですか。
A. 空いた場所を、次の書き込みで再利用するために残しているからです。手元の SQLite では、10万行の9割を消してもファイルは 11,108,352 バイトのままで、VACUUM を実行して 1,118,208 バイトになりました。

Q. PostgreSQL の VACUUM と VACUUM FULL の違いは何ですか。
A. VACUUM は空いた場所を再利用できる状態にする処理で、OS に返すのは末尾のまるごと空いたページだけです。VACUUM FULL はテーブルを新しいファイルに書き直して小さくしますが、実行中は排他ロックを取り、追加の空き容量が要ります。

Q. データベースのシュリンクは定期的に実行したほうがよいですか。
A. Microsoft Learn は、SQL Server のシュリンクを通常の保守作業として扱わないよう案内しています。縮めてもまた大きくなるなら、その空きはふだんの処理に必要な空きです。一度だけ大量に削除したあとなど、理由があるときに実行します。

Q. シュリンクでデータは消えますか。
A. 正しく実行できれば、中のデータは残ります。手元の resize2fs でも、縮小のあとに6個のファイルが残り、検査で異常は出ませんでした。ただし区画の操作は失敗すると戻しにくいので、先にバックアップを取ります。Microsoft Learn は、ファイルシステムのない生のパーティションではデータが壊れるおそれがあると注意しています。

Q. Windows の「ボリュームの縮小」で、空きがあるのに少ししか縮小できません。
A. 移動できないファイル（ページング ファイルやシャドウ コピーの保存領域など）が区画の後ろのほうにあると、その位置までしか縮小できません。Microsoft Learn は、イベント ID 259 のログで妨げているファイルを調べる方法を案内しています。

Q. シュリンクと minify は同じ意味ですか。
A. どちらも「小さくする」ですが、対象が違います。minify は JavaScript や CSS の空白・コメント・名前を短くして、動きを変えずにファイルを小さくする処理です。手元では 857 バイトが 339 バイトになりました。

Q. シュリンクの過去形は何ですか。
A. shrink の過去形は shrank（shrunk とも）、過去分詞は shrunk（shrunken とも）です。shrunken は「縮んだ」という形容詞としても使われます。

まとめ

この節では、この記事の要点を5つで振り返れます。

• シュリンクは「縮むこと・縮小すること」。 何が縮むのか（市場・ファイル・フィルム・内容量）で意味が決まる。
• ビジネスでは規模の縮小。 市場のシュリンクとシェアの低下を分け、何が・どれだけ・なぜ、を添える。年率 −3% でも5年で −14.1% になる。
• ITでは「消す」と「縮む」が別の動き。 SQLite も PostgreSQL も、9割削除してファイルは1バイトも縮まず、VACUUM・VACUUM FULL で約10%になった。
• 縮めるかどうかは「その空きがまた使われるか」で決める。 Microsoft Learn も、シュリンクを通常の保守作業としない方針を示している。
• 区画の縮小は順番とバックアップ。 縮めるときは先にファイルシステム、次にパーティション。最小サイズより小さくはできない。

参考・出典

この節では、この記事で確かめた一次情報の場所が分かります（確認日 2026年11月11日）。

• 小学館「デジタル大辞泉」シュリンク／シュリンクラップ契約（Weblio 辞書に収録）：https://www.weblio.jp/content/シュリンク
• 小学館「プログレッシブ英和中辞典（第5版）」shrink（コトバンクに収録）：https://kotobank.jp/ejword/shrink
• Merriam-Webster「shrink」：https://www.merriam-webster.com/dictionary/shrink
• Merriam-Webster「shrinkflation」：https://www.merriam-webster.com/dictionary/shrinkflation
• SQLite「VACUUM」：https://www.sqlite.org/lang_vacuum.html
• SQLite「Pragma statements」（auto_vacuum・incremental_vacuum・wal_checkpoint）：https://www.sqlite.org/pragma.html
• PostgreSQL 16「Routine Vacuuming」：https://www.postgresql.org/docs/16/routine-vacuuming.html
• Microsoft Learn「DBCC SHRINKDATABASE (Transact-SQL)」：https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-shrinkdatabase-transact-sql
• Microsoft Learn「Shrink a basic volume」：https://learn.microsoft.com/en-us/windows-server/storage/disk-management/shrink-a-basic-volume
• resize2fs(8) マニュアル：https://man7.org/linux/man-pages/man8/resize2fs.8.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。