2026年Mojoソースコードのコンパイルに必要なMac統合メモリは？

ビルドは開始するのに、Bazelテストや本地Agentを同時に動かすとMacが重くなる。
最短の判断は、16GBと24GBを「限定的な検証用」、32GBを「Mojoのクリーンビルドの起点」、64GBを「Agent・テスト・複数タスクの同時実行用」として分け、同じ条件で実測することです。

このページは、初めてMojoをソースから構築する開発者、開発ツールと本地Agentを同時に使うAI開発者、短期レンタルでチーム構成を決めたい技術責任者向けです。モデルが読み込めるMacを探しているだけなら、判断軸が異なります。

最終更新：2026年8月28日。Mojoの開発状況と構築手順は、Mojo公式のオープンソース発表、公式リポジトリ、公式のOSリポジトリ構築資料を基準に確認しています。

「起動できる」と「最後まで完了する」は別の判定です

Mojoの構築では、次の作業を同じ「コンパイル」として扱わないでください。

• 事前ビルド済みのMojoツールチェーンを使う。
• 標準ライブラリだけを変更して増分ビルドする。
• コンパイラーをソースからクリーンビルドする。
• Bazelで広い範囲のテストを実行する。
• コンパイラー、モデルサービス、本地Agent、コードインデックスを同時に常駐させる。

公式資料は、事前ビルド済みツールチェーンの利用と、ソースリポジトリから構築する経路を区別しています。したがって「Mojoのコマンドが起動した」「小さな変更を再ビルドできた」だけでは、完全な構築能力の証明になりません。

今回の容量判断の対象は、Apple Silicon Mac上で実行する実際のソース構築です。測定時には、Mojoのコミット、ビルド対象、Bazelの引数、依存関係を初めて取得するか、キャッシュを消したかを必ず記録します。Bazelの引数は公式コマンドラインリファレンスに合わせて固定してください。

第一の指標：ピーク値よりも完了状態を優先する

容量を測るときは、アクティビティモニタでプロセスのメモリ使用量だけを見ないでください。Appleはメモリの余裕を、使用量の単純な合計ではなく「メモリプレッシャー」やスワップ使用量などを含めて確認する考え方を示しています。Appleのメモリプレッシャー説明を基準に、次の項目を同時に記録します。

• ビルド中の最大メモリ使用量。
• システム全体のメモリプレッシャー。
• スワップ使用量が増え続けたか。
• 操作の反応が維持されたか。
• ビルドが正常終了したか。
• 同じ条件で再実行した結果が一致したか。

一瞬だけ大きな値を示しても、処理が完了し、交換領域が増え続けなければ評価は変わります。逆に、コマンドが動き続けていても、交換が継続し、操作不能になり、終了まで異常に時間がかかるなら、実務上は容量不足です。

注意：SSDの空き容量は、交換領域の受け皿にはなりますが、統合メモリの代わりにはなりません。空き容量が多いことを理由に、長時間の交換を正常なビルドとして扱わないでください。

第一歩：測定条件を固定する

最初にMojoのコミットとmacOSのバージョンを控えます。次に、Bazelのビルド対象、起動引数、キャッシュを消すかどうかを決めます。公式リポジトリの構造と構築方法が変われば、過去の結果はそのまま比較できません。

第二歩：clean buildを単独で走らせる

Agentやモデルサービスを停止した状態で、完全なクリーンビルドを実行します。開始前、ピーク時、終了後にメモリプレッシャーと交換使用量を記録し、成功・失敗・異常終了を分けて残します。

第三歩：Bazelの並列度だけを変える

初回の依存関係取得とキャッシュの有無を記録したうえで、まず既定設定を測ります。その後、並列タスク数だけを制御して再測定します。ソース、Mac、コミット、キャッシュ状態を同時に変えると、どの条件がピークを押し上げたのか分からなくなります。

第四歩：Agentの負荷を段階的に追加する

モデルサービスの待機状態、長いコンテキストを処理している状態、ツール呼び出し中、コードインデックス更新中を分けます。MLXはApple Siliconの統合メモリをモデル処理に使うため、MLX公式の統合メモリ資料も確認してください。

第五歩：同時実行を再生する

最後に、Agentを常駐させたままMojoのclean buildとBazelテストを実行します。Agentを先に動かしてから停止し、後でビルドする方法は「錯峰実行」であり、同時実行の合格結果ではありません。コード変更、Agentへの指示、ツール呼び出し、ビルド、テストを同じ手順で再生します。

並列度とキャッシュを変えると、必要容量の見え方も変わります

Bazelの並列度が高いほど、複数の処理が重なる可能性があります。反対に、キャッシュが十分に効いた増分ビルドでは、ソース全体を処理するclean buildより低い負荷に見えます。

ここで避けたいのは、キャッシュが温まった短いビルドを「常用時の必要容量」として扱うことです。初回依存関係の取得、キャッシュを消した状態、既定並列度、制御した並列度を分けて記録してください。所要時間だけでなく、失敗や交換の継続も結果に含めます。

27B級モデルについては、第三者のMLX検証で4-bit量子化などの条件が使われています。ただし、Qwen 3 27Bの第三者検証はモデルの実行条件を示す資料であり、Mojoのソース構築に必要な統合メモリの公式基準ではありません。モデルがロードできることから、コンパイラーのclean buildが安定するとは推定できません。

Mac統合メモリの選択は容量名ではなく、作業の重なりで決める

Appleの現行Mac mini仕様では、構成により16GB、24GB、32GB、64GBなどの統合メモリ選択肢を確認できます。Mac miniのApple公式仕様で、購入またはレンタルする実機の選択肢を確認してください。

• 16GB：事前ビルド済みツールチェーン、限定したターゲット、錯峰実行の検証向けです。clean buildとAgentの同時実行を前提にしないでください。
• 24GB：小規模な変更や、キャッシュが効いた作業の比較候補です。Bazelテスト範囲が広がる場合は、完了状態を厳しく確認します。
• 32GB：Mojoコンパイラーのclean buildを単独で測る起点です。Agentやモデルサービスを残すなら、ピーク余量を実測して判断します。
• 64GB：Bazelテスト、多数のビルド処理、本地Agent、モデルサービスを同時に扱う構成の受け入れ試験に向きます。ただし、64GBでも無条件の保証にはなりません。

条件分岐で決める

次の条件で、購入前の候補を絞ってください。

• clean buildを単独で最後まで完了し、交換が継続しないなら、32GBを基準に比較します。
• clean buildは完了するが、Bazelテストで交換が続くなら、並列度を制御して再測定します。それでも改善しない場合は64GBへ進みます。
• Agentを停止すれば成功し、常駐させると失敗するなら、16GBや24GBを常用構成にしません。
• Agent、モデルサービス、コードインデックス、Bazelテストを同時に使うなら、64GBから受け入れ試験を始めます。
• 16GBや24GBで限定的な検証だけを行うなら、作業範囲とキャッシュ条件を固定し、完全構築が可能だとは記録しません。
• 同じ設定で複数回実行して結果が揺れるなら、容量を決めず、まず並列度とバックグラウンド処理を整理します。

購入前に候補を比較するなら、MacHTMLのコンソール案内で利用環境を確認し、同じスクリプトを容量違いのMacで実行します。短期利用では、測定対象を先に決めておかないと、速い増分ビルドだけを見て判断してしまいます。

FAQ：よくある容量判断の分岐

16GBのMacでMojoをソースからビルドできますか？

限定したビルド対象やキャッシュが効いた増分ビルドなら、16GBでも検証できる可能性があります。ただし、コンパイラー全体のclean buildやBazelテストを安定して完了できるという意味ではありません。同じコミットと設定で交換領域、メモリプレッシャー、終了状態を記録し、失敗や極端な速度低下が出たら上位容量へ切り替えます。

Mojoのコンパイルには32GBと64GBのどちらを選ぶべきですか？

Mojo単体のclean buildを確認するなら、32GBを比較の起点にできます。本地Agent、モデルサービス、コードインデックス、Bazelテストを同時に動かす開発環境なら、64GBから受け入れ試験を始める方が安全です。最終判断は容量名ではなく、ピーク時のメモリプレッシャー、交換の継続、再実行の一貫性で決めてください。

本地Agentを動かしたままMojoのclean buildを実行できますか？

可能かどうかは、Agentのモデル、コンテキスト長、ツール呼び出し、インデックス更新によって変わります。Agentを停止した状態でビルドが成功しても、同時実行の証拠にはなりません。Agentを常駐させ、コード変更からビルド、テスト、ツール呼び出しまでを同じ再生手順で実行し、完了状態と交換圧力を記録します。

レンタルMacでMojoのコンパイルを測るとき、何を記録すべきですか？

統合メモリ容量だけでなく、Mojoのコミット、macOS、Bazelの引数、依存関係の初回取得、キャッシュ状態、ビルド対象、Agentの負荷を記録します。さらに、ピークメモリ、メモリプレッシャー、交換使用量の増加、経過時間、失敗内容、再実行結果を残してください。MacHTMLのヘルプ情報も確認し、環境差による記録漏れを避けます。

コストを含めた最終判断：先に隣接容量を比較する

Mojoの開発を自分のMacだけで進める方法は、環境を固定しやすい一方、統合メモリ不足を確認するために本体を買い替えるまで選択肢を試せません。低容量機で交換を常態化させると、ビルド時間の延長、操作性の低下、Agent停止による作業分断が発生します。逆に、常時大容量が必要ない個人開発では、購入した容量を使い切れない可能性もあります。

クラウド環境だけに寄せる場合も、ファイル転送、接続状態、永続キャッシュ、物理インターフェースの制約が残ります。長期にわたり安定した高負荷を毎日実行するなら購入が合理的です。一方、Mojoのコミット変更やAgentの再生手順を比較する段階なら、MacHTMLのレンタル環境で隣接する容量を短期間ずつ測る方が、推測で購入するより判断材料を作りやすくなります。

まず自分のMojo構築対象とAgent操作を再生スクリプトにし、16GB・24GB・32GB・64GBのうち隣接する候補を同じ条件で比較してください。長期構成を決める前に、MacHTMLの料金案内で利用条件を確認し、ピークメモリ、交換圧力、完了状態、再実行結果が残る環境を選ぶのが安全です。