結論：16GBは軽量構成の出発点、迷うなら実測する
ブラウザー、エディター、数個のコンテナを動かす軽量なWeb開発なら、16GBで足りる場合があります。 一方、複数サービス、データベース、IDE、オンライン会議、ローカルKubernetesを同時に動かすなら、32GBの余裕が効きやすくなります。
ただし、コンテナの個数だけで必要量は決まりません。小さなWebサーバー10個より、大きなデータベースやJavaプロセス1個の方が多く使うこともあります。 購入前に、現在のPCで最も重い普段の作業を再現して測るのが確実です。
| 測定結果 | 判断の目安 |
|---|---|
| 作業中も十分なavailableメモリが残り、スワップが増えない | 同じ使い方なら16GBを選びやすい |
| availableが少なく、操作中にスワップが継続して増える | 32GBを優先して検討する |
| ローカルKubernetes、VM、エミュレーターも常用する | 現在の実測値に将来分を加え、32GB以上を検討する |
測定前：普段の作業を再現する
PCを起動した直後の数字ではなく、負荷が高くなる日の状態を再現します。
- 普段使うブラウザーのタブ、チャット、IDEを開く
docker compose up -dなどで開発用サービスをすべて起動する- データベースへ実際に近いデータを読み込む
- ビルド、テスト、コード解析など重い処理を実行する
- 必要ならオンライン会議や画面共有も同時に開始する
起動しただけでは、遅延ロードされる処理やキャッシュが反映されません。10〜20分ほど普段どおり操作し、最も重い場面を測ります。 機密情報を含む業務環境では、コマンド出力を外部へ公開しないよう注意してください。
手順1：ホスト全体のメモリを確認する
Linuxでは、まず次のコマンドを実行します。
free -h
主に見るのはusedだけではなく、availableとSwapです。
Linuxは空きメモリをファイルキャッシュにも使うため、freeが小さいという理由だけでメモリ不足とは判断しません。
| 項目 | 見る理由 |
|---|---|
available | 新しいアプリケーションが利用できる見込みのメモリを確認する |
Swap used | RAMからディスクへ退避が発生しているか確認する |
buff/cache | 単純な「使用済み」とアプリケーションの消費量を混同しないために見る |
作業中の変化を見る場合は、2秒おきに表示します。
watch -n 2 free -h一度スワップされたデータは負荷が下がっても残ることがあります。そのため「Swap usedがゼロでない」だけで判断せず、重い操作中に増え続けるか、操作の引っかかりが同時に起きるかを見ます。
手順2：コンテナごとの使用量を確認する
実行中のコンテナを1回だけ一覧にするには、次のコマンドを使います。
docker stats --no-stream
MEM USAGE / LIMITでコンテナごとの使用量と上限を確認できます。Docker公式ドキュメントによると、Linux上のCLI表示ではキャッシュ分を差し引いた値が使われます。
そのため、ホストのfree -hとコンテナの数値を単純に合計して一致させるものではありません。
名前、CPU、メモリだけに絞ると比較しやすくなります。
docker stats --no-stream \
--format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"特定のコンテナだけが大きい場合は、PCを買い替える前に設定も確認します。 Javaヒープ、データベースのバッファ、開発時に不要なサービスなどを調整できる可能性があります。
Dockerは、指定しなければコンテナがホストで利用可能な範囲のメモリを使えます。開発環境の暴走を防ぐ目的なら、Composeの設定やdocker run --memoryによる上限も検討できます。
ただし、必要量より低い上限はコンテナの異常終了や性能低下につながるため、測定後に設定します。
手順3：Docker以外の大きなプロセスを探す
Dockerだけを見ていると、ブラウザー、IDE、言語サーバー、会議アプリの負荷を見落とします。Linuxでは次の例で、メモリ使用率の高いプロセスを確認できます。
ps -eo pid,comm,%mem,rss --sort=-rss | head -20
rssは常駐している物理メモリ量の目安で、通常はKiB単位です。ブラウザーなどは複数プロセスに分かれるため、1行だけでなく関連する行をまとめて見ます。
共有メモリなどの影響もあるので、ここでも全行の単純合計をホスト全体の値として扱わないでください。
WSL2・Docker Desktopではホスト側も見る
Windows＋WSL2やDocker Desktopでは、Linux環境が仮想化層の中で動きます。WSL内のfree -hだけでなく、WindowsのタスクマネージャーでもPC全体のメモリを確認してください。
%UserProfile%\.wslconfigでWSL2に割り当てるメモリを制限している場合、その上限も判断に影響します。
macOSのDocker Desktopも同様に、コンテナの合計だけではなく、アクティビティモニタとDocker Desktopのリソース設定を確認します。 「PCには32GBあるがDockerへ割り当てた上限が小さい」という状態では、増設しても設定を変えなければ効果を得られません。
測定結果を記録する
最低でもアイドル時、通常作業時、最大負荷時の3回を記録します。別の日にも測ると、一時的な処理に左右されにくくなります。
| 場面 | available | Swap used | 最大のコンテナ | 操作感 |
|---|---|---|---|---|
| 起動後・アイドル | GB | GB | — | — |
| 通常の開発中 | GB | GB | GB | 問題なし／遅い |
| ビルド・テスト・会議中 | GB | GB | GB | 問題なし／遅い |
現在16GBのPCで、最大負荷時にも余裕が残り、スワップ増加や操作遅延がなければ、同じ使い方では16GBが候補になります。 反対に、IDEとコンテナを起動するたびに余裕がなくなり、スワップと待ち時間が増えるなら、32GBへ予算を配分する根拠になります。
16GBと32GBの最終判断
16GBを選びやすい条件
- 軽量なWeb開発が中心で、同時に動かすサービスが少ない
- 実測でavailableメモリに余裕があり、スワップが増え続けない
- ビルドや大きなテストはCIやクラウドへ任せる
- 購入後にメモリを増設できる
- 価格、重量、バッテリー持続時間を優先したい
32GBを選びやすい条件
- 複数サービス、DB、IDE、ブラウザー、会議アプリを同時に使う
- ローカルKubernetes、仮想マシン、Androidエミュレーターも使う
- 現在の16GB環境でスワップ増加や操作遅延を確認した
- メモリを増設できないPCを数年間使う予定である
- 今後、担当サービスやローカル処理が増える可能性が高い
32GBにすれば、CPU不足、遅いSSD、コンテナの設定不良まですべて解決するわけではありません。 実測でメモリが原因と確認してから優先順位を決めることが、過不足のないPC選びにつながります。