AIエージェントを一日中PCで動かすようになると、そのPCを使うのはもはやあなた一人ではありません。エージェントはブラウザを開き、開発サーバーを立ち上げ、大量のファイルを書き出し、作業が終わってもすべてを動かしたままにしがちです。PCが重くなると、Mac mini、Mac Studio、あるいはNVIDIAのシステムの価格を調べたくなるものです。しかしエージェントの負荷は追加した余裕を埋めるように膨らむ傾向があり、より速いチップやより多くのメモリで問題が長く解決することはまずありません。安上がりな最初の一歩は、今持っているPCで何がメモリとディスクを消費しているのかを突き止めることです。
モデルはクラウドで動いても、散らかるのは手元のPC
ClaudeやCodexのようなエージェントに作業を任せると、言語モデルの応答は通常、提供企業のデータセンターから返ってきます。ただし、その周辺の作業の多くはローカルで動きます。開発サーバー、ヘッドレスブラウザ(画面を表示せずに動くブラウザ)、コンパイラ、テストスイートなどです。Google ChromeでClaudeを使いながらZenブラウザで閲覧し、Codexにタスクを送り、ローカルの文字起こしモデルを動かすと、メモリプレッシャーはすぐに高まります。Claude CodeにBlenderで動画をレンダリングさせながら、Codexに別のコードを書かせる場合も同じです。

▲ クラウドの推論とローカルの負荷
GitHubに公開されたCodexのバグ報告が示すように、発展途上のエージェントソフトウェアが知らないうちにディスク容量を食いつぶすこともあります。
| 報告された問題 | 規模 |
|---|---|
| macOSで整理されずに膨らむCrashpadのクラッシュレポートフォルダ | 50GB超 |
| セッションのターンごとに保存されるGitのチェックポイントデータ | 100GB超 |
| あるCodex環境がSSDに書き込んだデータ | 21日間で約37TB |
これほどの書き込み量は、SSDの物理的な摩耗にもつながりかねません。OpenAIも対応を進めています。2026年6月と10月のCodexのアップデートではログの書き込みに手を入れ、Codex 0.160.0では使われていないログデータベースの領域を回収する仕組みを加えました。さらに10月13日には、ChatGPTとCodexのデスクトップアプリのディスク使用量を60%削減する最適化を発表しています。とはいえ、1社の修正だけでは、Qwen、Claude、Codexを並行して動かす環境を片付けることはできません。
同じリポジトリに対してエージェントごとに別の作業フォルダを用意するgit worktreeは、それぞれが独自のビルドキャッシュと依存関係を持つため、ディスク使用量について明確なルールを決めておく必要があります。1980年代のように、メモリとストレージを再び慎重にやりくりしなければならなくなりました。
買い物の前に点検を
使用量ではなくメモリプレッシャーを見る
MacではActivity Monitorを開き、「メモリ」タブを選びます。注目すべきはメモリプレッシャーのグラフです。緑はメモリが効率よく使われている状態、黄色はメモリが足りなくなるかもしれない状態、赤はRAMが不足している状態を示します。WindowsではCtrl+Shift+EscでTask Managerを開き、「パフォーマンス」タブを確認します。メモリ使用量の数値が高くても、新しいPCが必要だという証拠にはなりません。動いているソフトウェアを点検するきっかけと捉えましょう。
ストレージとスワップを確認する
Appleメニューから「システム設定」、「一般」、「ストレージ」の順に開きます。RAMが進行中の作業をこなす作業台だとすれば、ストレージはファイルやアプリのコードを保管する倉庫です。RAMが足りなくなると、macOSはドライブの一部をスワップメモリとして借ります。カード会社が支払いをつなぐために一時的に確保する仮押さえのようなものです。
エージェントに読み取り専用の点検を任せる
最初の点検で何も変更しないのであれば、調査はエージェントに任せられます。プロンプトには次の3点を盛り込みます。
- 何も変更せずにPCの状態を調べる。
- メモリを最も使っているプロセスと、容量を最も占めているストレージのパスを見つける。
- それぞれの発生源を説明し、具体的な対処法を提案する。
ハードウェアを買う前や、自動のクリーンアップスクリプトを走らせる前に、まずこれを実行します。過去のプロジェクトや放置したサイドプロジェクトのローカル開発サーバーが、忘れられたまま動いているのが見つかるかもしれません。止める前に、そのサーバーがどのアプリを提供しているのか、プロジェクトが終わっているのか、何を後から再生成できるのかを確認します。その後は、git worktreeやエージェントの一時フォルダを定期的に確認し、古くなったビルドキャッシュ、チェックポイント、クラッシュログを削除します。
エージェントとPCを共有するための4つのハウスルール
エージェントとPCを共有するのは、ルームメイトと家をシェアするのに似ています。暮らしやすさを保つのは次の4つのルールです。
| ルール | 実際に意味すること |
|---|---|
| 作業がどこで動くかを知る | クラウドでの推論と、ローカルで動くサーバー、ブラウザ、ビルドを切り分ける |
| すべてのエージェントに停止の合図を出す | タスクの完了条件を決め、プロセスがきれいに終了するようにする |
| 同時に発生する負荷を管理する | 重い作業はキューに入れ、一度に1つか2つだけ実行する |
| 保守計画を持つ | 定期点検をスケジュール化し、多くはエージェントに実行させる |
すべてのエージェントに停止の合図を
人が見ていないエージェントの作業は途中で止まりがちで、Chromeのタブやチャットセッション、開発サーバーが動いたまま残ります。最近のエージェントは、検証可能な報酬による強化学習(RLVR)で重点的に訓練されています。結果を検証できるときにモデルに報酬を与えるこの手法は、タスクが完了するまで粘り続けるようエージェントを駆り立てます。境界がなければ、その粘り強さはPCを際限なく使い続けることにつながります。各タスクを終わらせる成果物やマイルストーンを明示し、そこに達したらプロセスを終了するようエージェントに指示しましょう。孤立したプロセスがたまり続ける限り、ハードウェアを増やしても得られるのは一時的な余裕だけです。
重い作業はキューに並べる
エージェントに12件の文書を処理させるなら、キューに並べて一度に1件か2件だけを実行させます。負荷の測定はエージェント自身に頼めます。まず1つのタスクから始めて2つに増やし、メモリ使用量と完了までの速さを比べます。エージェントはPCの内部から使用状況を監視し、限界に近づいたら知らせることができます。動作が遅くなったら、同時実行を減らすよう指示しましょう。
コア数は処理能力の目安になりません。クラウドのモデルからの応答を待っているエージェント2つはプロセッサにほとんど負荷をかけませんが、動画をレンダリングしたり大規模なビルドを実行したりするエージェント2つは、すべてのコアを使い切ることがあります。コアやユニファイドメモリを増やして効果が出るのは、ソフトウェアが実際に作業を並列に分割できる場合だけです。負荷を測っておけば、エージェントがAPIの応答を待つ間に遊んでいるハードウェアにお金を払わずに済みます。作業を段階に分けるのも有効です。
- 軽量なエージェントが、クラウドのモデルを使って調査と計画を担当する。
- ローカルで行う重い作業はキューに入れる。
- 大きなローカルビルドは一度に1つずつ実行する。
既存のプロジェクト、ブラウザのセッション、フォルダ構成を作り直さずに再利用するよう、エージェントに指示しましょう。
ローカルの実行環境を調整する
- **Docker Desktop:**仮想マシンにメモリの上限を設定し、Resource Saverモードを有効にしてアイドル状態のリソースを解放します。
- **OllamaとLM Studio:**コンテキスト長(モデルが一度に扱えるテキストの量)、並列リクエスト数、モデルをメモリに読み込んだままにしておく時間を調整します。
モデルをメモリに常駐させておけば次のプロンプトにすぐ応答できますが、そのRAMは他のアプリが使えなくなります。複数のモデルを切り替えて使う場合は、モデルを解放するまでのタイムアウトと再読み込みにかかる時間のバランスを考えましょう。
保守計画を持つ
自分が操作しているPCでは、リソースが不足したときにすぐ通知が必要です。一方、バックグラウンドで動くPCは、もっとゆるやかなスケジュールで保守すれば十分です。今のモデルはファイルシステムやターミナルのツールを十分に扱えるため、定期的な状態チェック、ディスクのクリーンアップ、パフォーマンスの監視を任せられます。たとえば、Linuxの仮想マシンの面倒を見る専任のエージェントを置く方法があります。定期点検では、ディレクトリを追跡して許可のない変更を知らせ、保存していない作業中のデータを守り、人を優先してエージェントの作業はバックグラウンドに回すようにします。
それでも新しいハードウェアが必要なら
購入するのは、今の環境を点検して負荷を測ったあとにし、エージェントの作業が今後数年でどう増えるかも見据えましょう。
| 項目 | 目安 |
|---|---|
| メモリ | 一般的なエージェント作業なら24~32GB。16GBでも動くが、手作業でのこまめな調整が必要 |
| ストレージ | 512GBから。大きなデータセット、高解像度のメディア、複数のローカルモデルを扱うなら1TB以上 |
大規模言語モデルをローカルで動かす場合は、エージェントの作業とは別に、そのモデルのための固定的なメモリ消費が加わります。メモリを大量に積んだワークステーションが見合うのは、主にローカルのオープンウェイトモデル(学習済みのパラメータが公開されたモデル)に頼る場合や、大きなデータファイルとツールを同時に読み込む必要がある場合です。
Macが先に候補に挙がる理由
AIエージェントのツールは、Windowsより6~8カ月早くmacOSに登場する傾向があり、主要なAI研究機関も主にMacで先に開発しています。ChatGPTのデスクトップアプリは2024年5月にMac版、同年10月にWindows版が登場し、Coworkも2026年1月にmacOSに登場して、その1カ月後にWindowsに対応しました。Apple Siliconのユニファイドメモリも、一般的なWindows環境に比べてローカルモデルに有利です。
2026年10月16日時点のAppleの販売価格では、M6チップを搭載したエントリーモデルのMac miniが$899で、メモリ16GB、ストレージ256GBです。メモリは最大32GBまで選べます。M5 Pro搭載のMac miniは$1,699からで、メモリを最大64GBまで積めるため、より大きなモデルに向いています。16GBと256GBの基本構成は余裕が少なく、規律あるシステム管理が欠かせません。また、Appleは後からのメモリ増設を認めていないため、購入時に決めて、その費用も払う必要があります。単体のベンチマークの数字ではなく、自分のワークフローを基準に選びましょう。
NPUは近道ではない
NPU(AIの計算に特化したチップ)は専用のシリコンにすぎず、複数のエージェントを動かす負荷を解決する特効薬ではありません。性能を左右するのは、メモリ帯域幅から高速なSSDストレージ、プロセッサのパイプラインまで、システム全体の連携です。ローカルでの推論では、アクセラレータが使えるメモリの量が最も重要な制約になります。
Apple、NVIDIA、AMDのどれを選ぶか
プラットフォーム選びは、オートマチック車とマニュアル車のどちらを選ぶかに似ています。
| プラットフォーム | 使い勝手 | 向いている用途 |
|---|---|---|
| Apple Silicon(メモリを多く積んだMac Studioなど) | 最も技術的な手間が少ない | 1台でローカルのオープンウェイトモデルと日常のMacアプリを同時に使う |
| CUDA対応のNVIDIA GeForce RTX | 中間 | モデルのファインチューニングとGPU開発ツール |
| AMD Ryzen AI HaloまたはOmarchy | 最も細かく制御できる | 最大192GBのユニファイドメモリで、LinuxやWindows上の大規模モデルを動かす |
NVIDIAのアクセラレーテッドコンピューティング基盤であるCUDAは、本格的なローカルでのファインチューニング、つまり既存のモデルを特定のタスク向けに追加で学習させる作業の標準的なエコシステムです。UbuntuベースのNVIDIA DGX OSで動くNVIDIA DGX Sparkや、エージェント中心のOSであるOmarchyは、独自のエージェント向けインフラを構築する人に向いています。現在、AI用途でAMDの構成を使う人は多くありませんが、非常に大きなメモリが必要な人にとっては有力な選択肢です。
古いPCを働かせる
選択肢は3つです。今のPCを使い続けて負荷を測る、ハードウェアが許す範囲で部品をアップグレードする、あるいは新しいPCを買って古いPCをエージェントに任せる、のいずれかです。PCを家にたとえると、OSは建物、CPUのコアは部屋、メモリとストレージは共有のリビングスペースです。もっと大きな家にお金を払う前に、今の家を片付け、裏庭の物置、つまり古いPCを活用しましょう。バックグラウンドのエージェント作業を物置に回せば、母屋が散らかって動きが鈍くなるのを防げます。

▲ エージェント用に転用した古いPC
家と物置をつなぐのがTailscaleです。Tailscaleは、ポートを開放することなく、自宅のPCと外出先のデバイスを暗号化されたプライベートなメッシュネットワークで結びます。使っていないIntel搭載やMシリーズのMac mini、古いWindowsノートPC、古いMacBookは、重い作業を24時間こなすヘッドレスのエージェント用ワーカーになり、出先のノートPCから自宅のマシンに重い作業を送ることもできます。Raspberry Piでさえ、軽い作業や小さなローカルAPI、電子ペーパーのステータス表示を担えます。最上位のワークステーションを買う場合と比べ、数百ドルから数千ドルを節約できる可能性があります。
まとめ:まず診断、購入はその後
お金をかけるだけでは、エージェントによる動作の遅さからは抜け出せません。プロセスを管理しないまま大きなマシンに替えても、暴走するプロセスの居場所が広がるだけです。バックグラウンドの作業がすでにメモリを埋め尽くしていれば、普通のアプリを1つ開いただけでシステム全体が固まることもあります。まずは次のことから始めましょう。
- メモリプレッシャー、スワップ、ストレージ、コアごとのCPU負荷を確認する。
- 何かを止める前に、エージェントに読み取り専用の点検を依頼する。
- エージェントのタスクごとに明確な終了点を決め、重い作業は一度に1つか2つずつ実行する。
- Docker Desktop、Ollama、LM Studioを調整し、定期点検をスケジュールに組み込む。
- それでも足りなければ、メモリ24~32GB、ストレージ512GB以上を目安にし、古いマシンはTailscale経由でエージェント用のワーカーにする。