【Linux】freeコマンドの見方とメモリ使用率の確認｜availableとfreeの違い・buff/cacheの意味を徹底解説

コマンドリファレンス

Linuxのfreeコマンドの見方とメモリ使用率の確認方法を徹底解説！availableとfreeの決定的な違い、buff/cache（バッファ・キャッシュ）がメモリを占有する理由、実質メモリ使用率の正しい計算式からスワップスラッシングの調査手順まで完全網羅。

2026.09.13

コマンドリファレンス実務レシピ

483 69 73

Linuxサーバーを運用していて、free コマンドを叩いたときに 「free が数十MBしかない！メモリが枯渇している！」 と青ざめた経験はありませんか？慌ててキャッシュをクリアしようとしたり、サーバー再起動を考えたりしたことがあるなら、ちょっと待ってください。

結論から言うと、Linux環境において 「free の少なさ＝メモリ不足」ではありません。Linuxカーネルは、空いているメモリをファイルアクセス高速化のための「キャッシュ（buff/cache）」として限界まで使い切るように設計されているため、正常稼働中のサーバーでは free が数MB〜数十MBになるのがむしろ当たり前です。

実務で本当に見るべき指標は free ではなく available（実質的な空きメモリ） です。本記事では、free コマンドの出力項目の正確な読み解き方から、available と free の決定的な違い、buff/cache の役割と解放の是非、実質メモリ使用率（%）の正しい計算式、そして危険なスワップスラッシングの特定手順までを徹底解説します。手作業で計算したり目視で悩むのはもうやめましょう。

【結論】3秒でわかる！freeコマンドの見方と初動確認ワンライナー早見表

人間が読みやすい単位で確認（最頻出）: free -h
buffers と cache を分離して正確に把握: free -wh
実質メモリ使用率（%）を即座に計算するワンライナー: free -m | awk '/Mem:/ {printf "実質使用率: %.2f%%n", ($2-$7)/$2*100}'
メモリ消費量 TOP5 プロセスを特定: ps aux --sort=-%mem | head -n 6
スワップスラッシング（I/O頻発）の有無を監視: vmstat 1 5 （si / so がゼロなら健全）
判断基準の鉄則: available に十分な余裕があれば、free が 0 近くてもシステムは安全！

freeコマンドの基本書式と出力項目の見方
1. 基本書式: free -h（単位をGB/MBで読みやすく表示）
2. 出力項目の意味一覧表（total, used, free, shared, buff/cache, available）
ここで迷わない！「free」と「available」の決定的な違い
buff/cacheとは？解放すべきかの判断基準
1. bufferとcacheの役割
2. メモリ不足でキャッシュを強制解放する方法（drop_cachesの注意点）
スワップ（Swap）の発生確認とトラブル対処
1. Swap usedが増えている場合の危険度判断
2. メモリを消費している上位プロセスを特定するコマンド（ps aux –sort=-%mem | head）
まとめ & 関連記事
1. あわせて読みたい関連記事
関連記事

freeコマンドの基本書式と出力項目の見方

free コマンドは、Linuxカーネルが管理する物理メモリ（RAM）およびスワップ領域（Swap）の使用状況を要約表示する標準コマンドです。まずは、現場で最もよく使う実行書式と各出力項目の正確な意味を整理しましょう。

基本書式: free -h（単位をGB/MBで読みやすく表示）

引数なしで単に free を実行すると、値が「キロバイト（KiB）」単位で出力されます。桁数が多すぎて瞬時にギガバイト（GiB）やメガバイト（MiB）換算するのが難しく、目視での判断ミスを誘発します。

# 引数なしの実行（KiB単位で桁数が多く見づらい）
$ free
               total        used        free      shared  buff/cache   available
Mem:        16238692     4194304      524288      262144    11520100    11468800
Swap:        4194300           0     4194300

実務では、必ず -h（–human）オプション を付けて実行するのが鉄則です。適切な単位（G, M, K）が自動付与され、一目でリソース規模を把握できます。

# 実務の基本書式: 人間が読みやすい単位（GiB / MiB）で表示
$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       4.0Gi       512Mi       256Mi        11Gi        11Gi
Swap:          4.0Gi          0B       4.0Gi

さらに、後述するバッファとキャッシュを分けて確認したい場合は、-w（–wide）オプション を併用します。

# -w オプションで buffers と cache を列分離して表示
$ free -wh
               total        used        free      shared     buffers       cache   available
Mem:            15Gi       4.0Gi       512Mi       256Mi       350Mi        10Gi        11Gi
Swap:          4.0Gi          0B       4.0Gi

出力項目の意味一覧表（total, used, free, shared, buff/cache, available）

free -h の出力には 6つの主要な列が存在します。それぞれの役割と、監視・トラブルシューティング時の実務判断基準を以下の対比表にまとめました。

項目名	定義・計算式	実務での意味・詳細	監視・重要度
total	物理RAM総量	OSカーネルが認識している利用可能な物理メモリの合計値。BIOSやカーネル予約分は除外されます。	基本スペック確認
used	プロセス使用中メモリ `total - free - buff/cache`	OSやアプリケーションのプロセスが直接確保して消費しているメモリ。他の用途には即座に転用できません。	中（アプリの肥大化監視）
free	完全な未割り当て領域	いかなる用途（キャッシュを含む）にも使われていない、完全に放置されている空きメモリ。	低（少なくても問題なし）
shared	共有メモリ（主に tmpfs / shm）	複数プロセス間で共有されているメモリ領域や、`/dev/shm` などの tmpfs（RAMディスク）で消費されている領域。	中（tmpfs肥大化を警戒）
buff/cache	バッファ＋ページキャッシュ	ファイル読み書きの高速化のためにOSカーネルが一時的に借用している領域。メモリ逼迫時には自動的に即時破棄されます。	参考情報（I/O頻度で増減）
available	実質的な利用可能メモリ（カーネル3.14以降）	スワップを発生させずに、新しいアプリケーションが即座に確保できる推定空きメモリ量。	最重要！（死活・逼迫監視の基準）

上記の表から明らかなように、インフラ現場で監視アラートの閾値に設定すべき対象は free ではなく available です。これを取り違えていると、「free が枯渇した」という無意味な夜間アラートに悩まされることになります。

ここで迷わない！「free」と「available」の決定的な違い

エンジニアが free コマンドで最も混乱しやすいのが、「free と available は何が違うのか？」という点です。どちらも日本語では「空きメモリ」と訳されがちですが、システム設計上の意味は全く異なります。

free = 「全く使われていないメモリ」

free 列に表示される数値は、文字通り 「何の手も付けられず、完全に放置されているメモリ領域」 です。

サーバー起動直後はこの free が大半を占めますが、Webサーバー（Nginx / Apache）やデータベース（MySQL / PostgreSQL）、バッチ処理などが稼働し始めると、この数値は数分〜数時間で急速に減少します。そして最終的には、数百MBあるいは数十MBといった極めて小さな値で推移するようになります。

初めてこれを見た運用初心者は「メモリリークが発生したのでは？」「サーバーが増強不足か？」とパニックに陥りますが、これは Linux として完全に正常な挙動です。

available = 「新しいアプリが実際に確保できる実質的な空きメモリ」

これに対して available は、「いま新しいアプリケーションを起動したとき、スワップを発生させずに確保できるメモリ量」 を表します。

available は単に free + buff/cache を足しただけの値ではありません。Linuxカーネル 3.14（procps-ng 3.3.10以降）で導入されたこの項目は、以下の要素を考慮してカーネル内部で精緻に推計されています：

完全な空きメモリ（free）
破棄可能なページキャッシュ（ディスクと同期済みのクリーンページ）
回収可能なカーネルスラブメモリ（dentryやinodeキャッシュのうち回収可能な領域）
※除外されるもの: ディスク書き込み待ちのダーティページ（Dirty）や、解放不可能なスラブメモリ、共有メモリ（shared / tmpfs）

実務で使える！実質メモリ使用率の正しい計算式

システムの真のメモリ使用率（%）を算出する計算式は以下の通りです：

# 【誤った計算式】buff/cacheが考慮されず、常に90%超の誤報になる
メモリ使用率(%) = (used / total) * 100

# 【正しい計算式】実質的な空き（available）を考慮した実務計算
実質メモリ使用率(%) = ((total - available) / total) * 100

シェルスクリプトや監視ワンライナーでは、次のように awk で1行で計算できます：
free -m | awk '/Mem:/ {printf "実質使用率: %.1f%% (利用可能: %dMB / 全体: %dMB)n", ($2-$7)/$2*100, $7, $2}'

Linuxがメモリを限界まで使い切る理由（ページキャッシュの仕組み）

なぜ Linux は、わざわざ free を 0近くまで使い切るのでしょうか？その答えは 「使っていないメモリ（RAM）は、電力を浪費しているだけの無駄なリソース」 という設計思想にあります（有名な「Linux Ate My RAM!」の原則）。

ストレージ（SSD / NVMe / HDD）へのアクセス速度は、物理メモリへのアクセスに比べて数百〜数万倍も低速です。そのため、Linuxカーネルはディスクから読み込んだファイルデータを、メモリが許す限り「ページキャッシュ（Page Cache）」としてメモリ上に残しておきます。

次回同じファイルにアクセスする際、ディスクではなくメモリから直接読み出せるため、システム全体のレスポンスが劇的に高速化します。そして、新しいアプリケーションがメモリを要求した瞬間に、カーネルはこのキャッシュをミリ秒未満で即座に破棄・明け渡し を行います。

つまり、「普段は限界までキャッシュで高速化し、必要な時だけ即座にアプリに譲る」という極めて合理的な仕組みが動いているため、free が少ない状態こそが最高のパフォーマンスを発揮している証拠なのです。

buff/cacheとは？解放すべきかの判断基準

free -h の出力でひときわ大きな数値を占める buff/cache。この正体と、現場で時折話題に上る「キャッシュの強制解放」の是非について解説します。

bufferとcacheの役割

free -w で確認できるように、buff/cache は 「buffers（バッファ）」 と 「cache（キャッシュ）」 の合算値です。両者には明確な役割の違いがあります。

項目	管理対象	実務での役割と特徴
buffers （バッファ）	ブロックデバイス（ディスク）のメタデータ・未同期ブロック	ファイルシステムのメタデータ（inode情報、ディレクトリ構造等）や、ディスクへ書き込む前の一時バッファ。比較的サイズは小さめ（数十〜数百MB程度）で推移します。
cache （ページキャッシュ）	ファイルの中身（データ本体）および Slab	ファイルから読み取ったデータそのものをメモリページ単位で保持する領域。ログファイル読み込み、ソースコード実行、Web静的ファイル配信等で大きく増大します。

日常的なサーバー運用において、この2つを厳密に区別して個別チューニングする必要はほとんどありません。どちらも「OSがI/O効率化のために貸し出している領域」であり、必要に応じてカーネルが自動回収します。

メモリ不足でキャッシュを強制解放する方法（drop_cachesの注意点）

Linuxには、カーネルが保持しているページキャッシュやdentry/inodeキャッシュを強制的に破棄するプロシージャ /proc/sys/vm/drop_caches が用意されています。

# 未書き込みデータをストレージにフラッシュした上でキャッシュを全解放
$ sync
$ echo 3 | sudo tee /proc/sys/vm/drop_caches

echo に渡す数値によって、解放対象を以下のように選択できます：

echo 1 > /proc/sys/vm/drop_caches: ページキャッシュ（Page Cache）のみを解放
echo 2 > /proc/sys/vm/drop_caches: 未使用のdentryおよびinodeキャッシュ（Slab）を解放
echo 3 > /proc/sys/vm/drop_caches: ページキャッシュ、dentry、inodeキャッシュのすべてを解放

【実務上の警告】本番環境で drop_caches を定期実行（cron等）してはならない！

「空きメモリを増やしたいから」という理由で、深夜の cron に drop_caches を仕掛ける運用を見かけることがありますが、これは 絶対に避けるべきアンチパターン です。

ディスクI/Oスパイクと性能劣化: キャッシュを全破棄すると、直後にアクセスされたすべてのファイルが低速なディスクから再読み込みされるため、ストレージI/Oが激増しレスポンス遅延（スパイク）を引き起こします。
CPU負荷の上昇: カーネルがメモリページの回収と破棄にCPUリソースを奪われます。
用途は「ベンチマーク測定」のみ: ディスクI/Oやアプリ速度の計測時に、キャッシュの恩恵を排除して公正なコールドスタート状態を再現する目的以外では実行してはいけません。

スワップ（Swap）の発生確認とトラブル対処

メモリの逼迫状況を正確に判断する上で、free コマンドの2行目に表示される スワップ（Swap） の状態確認は欠かせません。

Swap usedが増えている場合の危険度判断

free -h を実行して、Swap: used に数値が入っている（例: 数百MB使用されている）のを見たとき、直ちにシステム障害と判断すべきでしょうか？

答えは 「状況による（使用量単体では危険とは言えない）」 です。スワップには「安全なスワップ」と「致命的なスワップ」の2種類が存在します。

平和なスワップ（静的スワップ）: 起動直後に一度だけ動いて長期間眠っているデーモンや、アクセス頻度の極めて低いプロセスメモリがスワップ領域に退避されている状態。RAMを有効活用するためにカーネルが意図的に退避させたもので、ディスクI/Oが継続的に発生していなければ性能への悪影響はほぼゼロです。
致命的なスワップ（スワップスラッシング: Thrashing）: メモリ不足により、プロセスが必要とするメモリをスワップイン（ディスク→RAM）とスワップアウト（RAM→ディスク）で激しく往復させている状態。ディスクI/O帯域が飽和し、ロードアベレージが急上昇、コマンドの入力すら受け付けなくなります。

この危険度を切り分けるには、vmstat コマンドを使って スワップI/Oの発生頻度 をチェックします。

# 1秒間隔でシステムの仮想メモリ状態を5回表示
$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0 262144 524288 350000 10000000    0    0    10    45  500 1200 10  5 85  0  0
 0  0 262144 524100 350000 10000000    0    0     0     0  420 1100  8  4 88  0  0
 0  0 262144 524000 350000 10000000    0    0     0     0  450 1150  9  4 87  0  0

見るべき列は swap の si（スワップイン）と so（スワップアウト） です：

si / so が 0 のまま推移: スワップ領域は使われていますが、現在I/Oは発生していません。完全に健全 です。
si / so に毎秒数十〜数百以上の数値が継続: スワップスラッシングが発生中。直ちに対処しないと、最終的に OOM Killer（Out of Memory Killer）が発動して主要プロセス（MySQLやJava等）が強制停止されます。

メモリを消費している上位プロセスを特定するコマンド（ps aux –sort=-%mem | head）

available が枯渇しスワップが発生している場合、犯人となっている「大食いプロセス」を特定するのが初動の最優先事項です。

手作業で top をスクロールして探すのは非効率的です。以下のパイプラインを使えば、物理メモリ消費率（%MEM）順にソートされた上位プロセス を一発でリストアップできます。

# メモリ消費率（%MEM）順に上位10プロセスを表示
$ ps aux --sort=-%mem | head -n 11
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1280  2.5 35.4 3456780 1450200 ?     Ssl  Sep01 120:30 /usr/sbin/mysqld
www-data  2341  1.2 12.8 1250400  524288 ?     S    10:00   2:15 php-fpm: pool www
www-data  2342  1.1 12.5 1248000  512000 ?     S    10:01   2:10 php-fpm: pool www
java      4512  3.0 10.2 4560000  418000 ?     Sl   Sep10  45:12 /usr/bin/java -jar app.jar
nginx     1120  0.1  1.5  150000   61440 ?     S    Sep01   1:05 nginx: worker process

出力結果で注目すべき項目：

RSS（Resident Set Size）: プロセスが実際に物理RAM上で消費している実メモリサイズ（単位: KiB）。上記例の mysqld は約1.45GBを物理RAM上で直接占有しています。
VSZ（Virtual Memory Size）: プロセスが確保している仮想メモリサイズ（スワップや共有ライブラリを含む）。
%MEM: システムの全物理メモリに対する実消費割合。

上位に異常なプロセスが見つかった場合は、個別プロセスのログ調査、systemctl restart <サービス名> による再起動、あるいは /etc/systemd/system/ のユニットファイルで MemoryMax= を指定して暴走時の上限を設けるなどの恒久対策を実施しましょう。

まとめ & 関連記事

Linuxにおけるメモリ監視と free コマンドの正しい付き合い方について解説しました。実務で直面した際は、以下の 3原則を思い出してください。

freeコマンド運用の3大鉄則

free が少なくても慌てない: Linuxは空きメモリをキャッシュとして使い切る設計。見るべき数値は常に available。
メモリ使用率は正しく計算する: (total - available) / total * 100 で実質使用率を出す（used/totalの誤報を防止）。
スワップはスラッシングを警戒する: Swap: used の有無ではなく、vmstat 1 の si / so が継続して発生しているかで危険度を即断する。

あわせて読みたい関連記事

サーバーのリソース調査やパフォーマンスチューニングをさらに深めたい方は、以下の実務ガイドもあわせてご活用ください：

【Linux】ディスク容量の確認と調査手順｜dfとduコマンドで容量逼迫の原因ファイルを特定する方法
ディスク使用量（df -h）の確認から、duとsortによる大容量ファイル特定、削除済み掴みファイルの解放までを完全解説。
top – プロセスとシステムリソースの使用状況を動的に表示するコマンド
リアルタイムでCPU・メモリ使用率やプロセス一覧を監視・対話操作するための基本ガイド。
【完全早見表】systemctlコマンドの使い方（start/stop/status/enable）とエラー対処
メモリ肥大化したサービスの再起動（restart）やステータス確認（status）、自動起動設定の逆引き早見表。
free コマンドの使い方｜オプション一覧と出力の見方を解説
freeコマンドの構文仕様や各オプション（-b, -k, -m, -g, -t, -s）の詳細リファレンス。
ps – 実行中のプロセスを表示するコマンド
稼働中のプロセス一覧取得、AUXオプションの意味、PID検索などの基本操作まとめ。
vmstat – 仮想メモリやCPU/IOの状態を要約表示する
スワップイン/アウトやブロックI/O、CPU waitを定期ポーリングしてボトルネックを突き止める監視手法。
【Linuxコマンド一覧・早見表】実務で頻出する主要コマンド・オプション逆引き完全ガイド
インフラ現場で日常的に使う主要Linuxコマンドの機能と逆引き構文を網羅したピラー記事。