結論：多くの開発は32GB、複数環境を並行するなら64GB
Webアプリケーションの開発で、IDE、ブラウザー、Docker Composeによる数個から十数個のコンテナを動かすなら、まず32GBを検討します。 64GBが有効なのは、ローカルKubernetes、複数の仮想マシン、大きなデータベース、Androidエミュレーターなどを同時に動かす場合です。
| 主な開発環境 | 選びやすい容量 | 判断理由 |
|---|---|---|
| IDE、ブラウザー、軽量なDocker Compose | 32GB | ホスト側のアプリとコンテナ用の余裕を両立しやすい |
| 複数サービス、DB、検索エンジン、オンライン会議 | 32GBから検討 | 同時起動するサービスの上限と実際の構成を確認する |
| ローカルKubernetes、複数VM、複数案件を並行 | 64GBを検討 | 環境ごとの予約量とピークが重なりやすい |
| 大規模データ処理、複数エミュレーター、AI開発 | 64GB以上も候補 | メモリ以外にGPUや帯域も個別に確認する |
コンテナ数だけでは必要メモリを決められない
同じ10コンテナでも、静的Webサーバー中心の構成と、データベース、検索エンジン、Javaアプリケーションを含む構成では負荷が異なります。 Docker以外にも、ホストOS、ブラウザー、IDE、言語サーバー、チャット、オンライン会議が同じ物理メモリを使います。
購入前には、次の3層へ分けて考えると整理しやすくなります。
- ホスト側：OS、ブラウザー、IDE、会議アプリなど
- 仮想化層：Docker Desktop、WSL2、仮想マシンなど
- 開発サービス：アプリ、DB、キャッシュ、検索、監視など
Kubernetesでは、Podのメモリ要求量と上限はコンテナごとの値を合計して考えます。 ただし、要求量は常に実使用量と一致するわけではありません。 ローカルクラスタを使う場合は、ワークロードに加えてクラスタを維持するコンポーネントの余裕も必要です。
32GBを選びやすい開発スタイル
次の条件が中心なら、64GBへ上げる前に32GB構成を検討できます。
- 同時に扱うプロジェクトは基本的に1つ
- Docker Composeのサービスを必要なときだけ起動する
- ローカルKubernetesや複数VMを常用しない
- 大きなビルドやテストはCIへ任せられる
- データベースへ本番相当の巨大なデータを置かない
- メモリを購入後に増設できる
32GBを選ぶ場合も、販売ページでは「最大32GB」ではなく、実際に32GBを搭載している構成か確認します。 オンボードメモリは購入後に交換できないため、容量と増設可否を別々に確認してください。
64GBを検討したい開発スタイル
64GBは、単に将来が不安という理由ではなく、次のように同時実行する環境が明確な場合に選びやすくなります。
- ローカルKubernetesと通常のDocker環境を併用する
- 複数案件のコンテナ群を切り替えずに起動しておく
- 複数のデータベース、検索エンジン、監視基盤を含む
- 仮想マシンやAndroidエミュレーターを同時に使う
- IDEを複数開き、大規模なコード解析や並列ビルドを行う
- 増設不能なPCを長期間使う予定がある
ただし、64GBにしてもCPU、SSD、冷却性能が不足すればビルドや仮想環境は快適になりません。 32GBから64GBへの差額によってCPUやSSDを大きく妥協するなら、処理時間や保存容量も含めて優先順位を見直します。
WSL2・Docker Desktopでは割り当ても確認する
WindowsでWSL2を利用する場合、物理メモリを増やすだけでなく、WSL2仮想マシンへどれだけ割り当てるかも確認します。
Microsoftの資料では、%UserProfile%\.wslconfigのmemoryで上限を設定できます。
初期値はWindows搭載メモリの50％とされています。
[wsl2]
memory=16GB
processors=8
swap=4GB上記は設定例であり、すべての32GB PCへ推奨する固定値ではありません。 WSL2へ割り当てすぎるとWindows側のIDEやブラウザーが苦しくなり、少なすぎるとコンテナ側が不足します。 Docker Desktop公式資料でも、WSL2モードのCPU、メモリ、スワップはWSL2側で調整するよう案内されています。
実測なしで購入前に判断する書き出し方
現在のPCで測れない場合は、購入後に同時起動するものを次の表へ書き出します。
| 分類 | 書き出す内容 | 確認先 |
|---|---|---|
| ホスト | IDEの数、ブラウザー、会議、デザインツール | 各アプリの推奨要件 |
| コンテナ | Composeの全サービスとメモリ上限 | Composeファイル、開発手順書 |
| Kubernetes | Podのrequests・limits、クラスタ数 | マニフェスト、Helm values |
| 仮想環境 | WSL2、VM、エミュレーターの割当量 | 各環境の設定 |
| 余裕 | 今後追加するサービス、急なビルド負荷 | 利用予定と増設可否 |
Kubernetesマニフェストがあるなら、resources.requests.memoryとresources.limits.memoryを一覧にします。
Docker Composeで上限を設定している場合も同様です。上限値をすべて単純合計した数字が常時必要とは限りませんが、同時起動範囲を確認する材料になります。
メモリと一緒に確認する仕様
- SSD：コンテナイメージ、ビルドキャッシュ、仮想ディスクを保存できるか
- CPU：並列ビルドや複数VMに必要なコア数があるか
- 冷却：高負荷を継続したときに性能を維持できるか
- 増設性：メモリスロット数、最大容量、オンボード構成を確認したか
- 端子：外部ディスプレイ、ドック、有線LANを接続できるか
- OSとCPUアーキテクチャ：使用するイメージや開発ツールに対応するか
特にSSDは、空き容量が少ない状態で開発を続けると、イメージ整理や環境の作り直しに時間を取られます。 複数案件やローカルKubernetesを想定するなら、メモリだけでなく1TB以上のSSDも比較対象にします。
購入前チェックリスト
- 同時に開くIDE、ブラウザー、会議アプリを書き出した
- ComposeやKubernetesで起動するサービスを数ではなく種類で確認した
- WSL2、VM、エミュレーターの割当量を確認した
- 32GBから64GBへの差額と、CPU・SSDの差を比較した
- メモリを購入後に増設できるか確認した
- 同じ製品名でも搭載メモリやキーボード配列が違うことを確認した
- 64GBが必要な具体的な同時作業を説明できる