2026年 Mac 32GB と 64GB：ローカル Agent と Mojo はどう選ぶ？

2026年8月11日にMojo 1.0が公開され、同月18日にはオープンソース化も公式に確認されています。Mojo 1.0のリリース記録 と オープンソース化に関する公式発表 が示す通り、Mojoを本格的に触る開発者は増えています。

結論：短いコンテキストで単一モデルを検証し、Mojoのビルドを時間帯で分けられるなら32GBが候補です。モデルサービスとコンパイルを同時に動かす、長文処理や複数ツールを使う、またはチームで共有するなら64GBが優先です。迷う場合は、モデルファイルの容量ではなく、実際のAgent作業をレンタル環境で比較してください。

この比較を読むべき開発者

個人開発者は、モデルを読み込めるかではなく、ツール呼び出しを含むローカル Agentの一連の処理を完了できるか判断したいはずです。Mojo開発者とオープンソース貢献者は、コンパイル中もモデルサービスを維持できるかが焦点になります。

技術責任者は、購入前に32GBと64GBの納品能力、待ち時間、共有時の失敗リスクを比較する必要があります。この記事では、空きメモリの大きさではなく、最も重い作業を重ねた状態で選びます。

先に見るべき比較条件

AppleシリコンのMacでは、CPU用とGPU用に物理メモリを単純分割するのではなく、統一メモリを複数の処理系が共有します。Appleの統一メモリに関する説明 でも、Metalデバイスが統一メモリを持つ仕組みが説明されています。

したがって、モデルの重みだけを見て「起動できる」と判断するのは危険です。推論中のKVキャッシュ、プロンプトキャッシュ、Agentのツール、IDE、コンテナ、コンパイラーが同じ余白を使います。

作業パターン	32GBを先に試す条件	64GBを先に試す条件	判定時に残す記録
個人のモデル検証	単一モデル、短いコンテキスト、ツール少数	会話を長く保持し、検索やファイル操作も継続	完全タスクの成功率、メモリプレッシャー
Agent試作	1つのAgentを順番に実行	ブラウザー、コード検索、複数プロセスを併用	スワップの増加、失敗後の復帰
Mojo開発	推論を止めてビルド、または作業時間を分離	推論、ビルド、テストを同時に実行	ビルド完了、テスト完了、サービス停止
小規模チーム	利用者を待ち行列に入れられる	利用時間と負荷が読めず、複数サービスを残す	再試行、待ち時間、同時利用時の状態

この表は製品仕様の優劣を示すものではありません。同じ容量でも、量子化方式、コンテキスト長、バックグラウンド処理によって結果は変わります。

個人のローカル Agentは32GBから検証する

単一モデルを読み込み、短い入力に対して回答を返すだけなら、32GBは試作の入口になります。ただし、判定を3段階に分ける必要があります。

• 読み込み：モデルの初期化が完了するか。
• 単発推論：1回の回答を返せるか。
• 完全なワークフロー：ファイル検索、コード編集、コマンド実行、結果確認まで完了するか。

最初の2段階だけで購入を決めると、最後のツール呼び出しで余白を失うことがあります。MLX-LMは量子化モデルだけでなく、生成時のキャッシュや大規模モデルの実行に関する機能を備えています。MLX-LMの公式機能説明 と 生成処理のパラメーター を確認し、使うモデルと設定を固定してから測定します。

個人の試作では、次の条件なら32GBに戻せます。

• Agentは単一プロセスで、複数の実行を同時に開始しない。
• コンテキストを無制限に伸ばさず、古い会話や取得文書を整理する。
• Mojoのビルドとモデル推論を同時に走らせない。
• IDE、コンテナ、コードインデックスなど不要な常駐処理を止められる。

この条件を守れない場合、32GBが「使えるか」ではなく「運用中に何度も余白を失うか」が問題になります。

長文Agentでは64GBの余白を評価する

長い会話、リポジトリの読み込み、RAGによる文書注入では、入力が増えるたびにキャッシュの保持量が変わります。MLX-LMには固定サイズKVキャッシュやプロンプトキャッシュを扱う実装があります。KVキャッシュの実装 と プロンプトキャッシュの公式ツール を読むと、コンテキスト設定が単なる入力文字数の問題ではないことが分かります。

32GBを使う場合は、キャッシュを制限する、取得する文書を絞る、Agentの作業単位を小さくする、といった設計が必要です。これで動作しても、回答の根拠が欠ける、会話の継続性が落ちる、処理を分割する回数が増える、といった品質上の代償があります。

64GBの価値は、同じモデルの生成速度を保証することではありません。完全なタスクを終えるまで、モデル、キャッシュ、ツール、OSの処理を同時に置く余地が広がることです。

注意：第三者によるQwen3.8 27BのMLX検証では、量子化方式や実行環境を含む条件が示されていますが、「24GBが最低条件」という主張をすべてのMacやモデルに一般化する根拠にはなりません。第三者テストの条件と結果 を確認し、同じ量子化とコンテキスト設定で再検証してください。

Mojo開発者はコンパイルとの同時実行で決める

Mojo 1.0の公開とオープンソース化は確認済みですが、ソースからのビルドに必要なメモリ量を一つの固定値で示すことはできません。依存関係の解決、コンパイルの並列度、テスト対象、生成物の状態でピークが変わるためです。

Mojoのコードを試す個人開発者なら、推論を停止してビルドする運用で32GBを試せます。反対に、Agentをサービスとして動かしながら、ソース変更、ビルド、テストを繰り返す開発者は64GBを優先します。失敗したビルドを再実行できるか、モデルサービスが落ちた後に自動復帰するかも確認対象です。

判断の順序は次の通りです。

1. Mojo 1.0の対象リポジトリと依存関係を固定します。
2. 通常のビルドだけでなく、テストと生成物の更新まで同じ手順にします。
3. Agentのモデル、量子化、コンテキスト長を固定します。
4. Agentを起動したままMojoのビルドとテストを実行します。
5. ビルド中のメモリプレッシャー、スワップ、サービス停止を記録します。
6. 同じ手順をもう一方の容量で繰り返し、単発の速度ではなく完了状態を比較します。

複数ツールの開発ではピークを基準にする

ブラウザー自動化、コード検索、IDE、コンテナ、ローカルモデルを同時に使うと、各プロセスの使用量が積み上がります。Agentの数を増やしたからといってモデル容量がそのまま比例するわけではありませんが、システムとコンパイラーに残る安全余量は確実に狭くなります。

典型的には、32GBは作業を順番に処理する構成に向きます。64GBは、複数のツールを止めずに調査と実行を続ける構成、またはMojoのテストを割り込ませる構成で検証する価値があります。

Macのアクティビティモニタでは、メモリプレッシャー、使用済みメモリ、スワップ使用量などを確認できます。Appleのアクティビティモニタ公式ガイド に沿って、アイドル時ではなく、Agentが最も多くのツールを呼び出した時点を記録します。

条件分岐で32GBと64GBを選ぶ

次の条件分岐に当てはめると、モデル名やファイル容量だけに引きずられにくくなります。

• 単一モデル、短いコンテキスト、単一Agent、コンパイルの時間分離をすべて満たすなら、32GBからレンタル検証します。
• コード検索やRAGを使うが、取得文書と会話を制限できるなら、32GBで完全タスクを反復し、スワップ増加が続く場合だけ64GBへ移ります。
• モデルサービスを維持したままMojoのビルドとテストを実行するなら、最初から64GBを比較対象にします。
• ブラウザー、IDE、コンテナ、インデックス、複数Agentを常時起動するなら、64GBのピーク状態を優先して確認します。
• チームで利用時間や負荷を制御でき、タスクを待ち行列に入れられるなら、32GBを複数人で共有する設計も候補です。
• 負荷の発生時間が読めず、複数サービスを止められないなら、64GBを選び、同時実行時の失敗率を測定します。

購入前は同じMac作業をレンタルで再現する

検証用の手順書には、実際に使うモデル、量子化方式、コンテキスト長、取得する文書、ツール呼び出し、Mojoのビルドとテスト手順を記載します。設定を変えたまま32GBと64GBを比べると、容量差ではなくワークロード差を測ることになります。

記録する項目は以下です。

• 完全なAgentタスクの成功数と失敗数。
• メモリプレッシャーが上がった時点。
• スワップ使用量の増加傾向。
• モデル推論、ツール処理、ビルド、テストの完了状態。
• 並行処理後にサービスとIDEが正常に戻るか。
• 同じタスクを再実行した際の失敗や再試行の有無。

レンタル期間や利用条件を確認する際は、ProxyMacの料金案内 と 利用環境の案内 を参照し、先に試験手順を固めておくと比較がぶれません。コンソール操作が必要な場合は、ProxyMacのコンソール から検証環境を管理できます。

よくある判断を短く整理する

32GBでローカル Agentを試す場合

「起動した」「短い質問に答えた」だけでは不十分です。コード検索、ファイル変更、コマンド実行、結果の再確認までを一つの課題として実行し、スワップが継続的に増えないかを見ます。

モデル推論とMojoを同時に動かす場合

同時実行自体は可能ですが、ビルドのピークを事前に固定することはできません。推論を止められる開発者は32GBを試し、サービスを維持したい開発者は64GBを先に比較します。

64GBへ移るべき場合

長いコンテキスト、RAG文書、複数ツール、IDE、コンテナ、コードインデックスが重なる場合です。特に、タスクを分割すると品質が落ちる、またはサービスを止めると開発手順が成立しない場合は、容量を増やす効果を測りやすくなります。

チーム共有での判断

利用者を順番に処理でき、負荷の低い時間帯にビルドを回せるなら、32GBでも運用設計は可能です。利用者が不定期に重いAgentを起動し、バックグラウンドのビルドも残るなら、64GBの方が再試行と待ち時間を抑えやすくなります。

購入対象を決める前に、現在の構成で発生している問題も切り分けます。少ないメモリだけでなく、コンテキスト設計の過大さ、ツールの常駐、ビルドの同時実行、共有スケジュールの不在も原因になります。

それでも、現在のMacでモデル推論、長文Agent、ブラウザー操作、IDE、Mojoコンパイルを重ねると、物理メモリの上限、交換メモリの増加、ビルド中のサービス停止、利用者同士の待ち時間が問題になります。逆に64GBを購入しても、負荷が低い期間には余剰設備を抱えることになります。

そのため、実際のモデルとMojoの手順を持ち込んで32GBと64GBを同じ条件で比べるなら、ProxyMacのMacレンタルは購入前の選択肢になります。まず完全タスクの成功率とメモリプレッシャーを記録し、長期購入、継続レンタル、推論とコンパイルの環境分離のどれが合理的かを決める方法です。