はじめに
最近、新しく発売されたMac mini M6が気になり、ローカルLLMの実行性能について調べてみました。
前回の記事では、公式情報やベンチマーク、SNSの実測報告を整理し、32GBモデルでも量子化した20〜35BクラスのMoEモデルが動作することを確認しました。
ただ、私がMac miniを購入したい理由は、単にローカルLLMとチャットするためではありません。
できれば、ローカルLLMに長時間コーディングを任せる環境を作ってみたいのです。
例えば、開発したい機能を指示すると、AIが設計を考え、コードを書き、テストを実行し、問題があれば修正する。
さらに、複数のエージェントが役割を分担してくれたら、かなり便利そうです。
もちろん、32GBというメモリ制限の中で、どこまで実現できるかは分かりません。
そこで今回は、もしMac mini M6を購入したら、どのようなローカルLLM・マルチエージェント環境を構築するかを妄想してみます。
1. まず、どんな環境を作りたいのか？
私が目指したいのは、次のような開発環境です。
- 開発したい機能を自然言語で指示する
- AIが内容を理解し、必要な作業に分解する
- エージェントが調査・実装・テストを担当する
- 問題が発生したら原因を調査して修正する
- 最終的な変更内容をまとめて報告する
これらの処理を、できるだけローカルLLMで完結させたいと考えています。
理想のアーキテクチャ
この構成で重要なのは、エージェントとLLMを分けて考えることです。
エージェントは、ファイル操作やテスト実行などの作業を管理する仕組みです。
一方、LLMは指示の解釈やコード生成などの推論を担当します。
そのため、複数のエージェントが存在していても、必ずしも複数のLLMをロードする必要はありません。
この仕組みを利用すれば、メモリが限られたMac miniでも、複数エージェントによる開発を実現できるかもしれません。
2. 購入するMac miniの構成
まず、購入するなら次の構成を考えています。
| 項目 | 構成 |
|---|---|
| チップ | Apple M6 |
| ユニファイドメモリ | 32GB |
| 内蔵SSD | 256GB |
| 追加ストレージ | 外付けSSD |
| 主な用途 | ローカルLLM・AIエージェント開発 |
なぜ32GBなのか？
今回の用途では、メモリ容量を最も優先したいと考えています。
LLMを実行するには、モデルの重みだけでなく、KVキャッシュや推論中の作業領域も必要です。
さらに、エージェントが複数のタスクを処理する場合は、コンテキスト長や同時リクエスト数も重要になります。
16GBでは選択できるモデルが限られるため、今回は最大構成の32GBを選びたいです。
SSDは256GBで十分なのか？
ここは少し迷っています。
ローカルLLMのモデルファイルは、量子化しても数GBから数十GBになることがあります。
複数モデルを比較したい場合、256GBの内蔵SSDだけでは不足する可能性があります。
そこで、モデルファイルは外付けSSDへ保存する構成を考えています。
ただし、外付けSSDで増やせるのはストレージ容量です。
外付けSSDを追加しても、LLMを使用できるユニファイドメモリが32GBから増えるわけではありません。
モデルのロード時間やストレージの発熱なども、実機で確認したいところです。
3. どのLLMを動かすか？
次に考えたいのが、使用するモデルです。
できれば、単一のモデルだけでなく、タスクに応じてモデルを使い分けたいと思っています。
現時点で気になっているのは、次の3つです。
| モデル | 想定する役割 |
|---|---|
| Qwen3.6-35B-A3B | 複雑な設計・実装 |
| Qwen3.5-9B | 軽量な調査・整理 |
| gpt-oss-20b | コーディングエージェントとの連携検証 |
3.1. メインモデルはMoEを使いたい
特に気になっているのが、Qwen3.6-35B-A3Bです。
このモデルは総パラメータ数が約35Bですが、1トークンの処理では約3Bのパラメータを活性化するMoEモデルです。
前回調べたベンチマークでは、M6 Mac mini・32GB環境で60 tok/s以上の生成速度が報告されていました。
生成速度だけを見ると魅力的ですが、コーディングエージェントとしての実用性は別問題です。
特に、ツール呼び出しの正確性や長時間タスクの成功率を確認したいと考えています。
3.2. 小型モデルを組み合わせたい
一方、すべてのタスクに大きなモデルが必要だとは思いません。
例えば、単純なファイル分類やログの整理であれば、小型モデルでも十分に処理できる可能性があります。
そこで、Qwen3.5-9Bのようなモデルを軽量なタスクに使用する構成を考えています。
理想としては、処理するタスクの内容に応じて、使用するモデルを自動的に変更する仕組みです。
ただし、モデルを切り替える際にはロード時間が発生します。
複数のモデルを同時にメモリへ載せられない場合、頻繁な切り替えはかえって非効率になるかもしれません。
そのため、最初から複数モデルを同時運用するのではなく、単一モデルの構成から試したいと考えています。
4. ローカルLLMをCodexから使いたい
次に、エージェントの実行環境です。
最初に試したいのは、CodexとLM Studioを組み合わせる方法です。
調べてみると、LM Studioの公式ドキュメントにCodexとの連携方法が紹介されていました。
4.1. LM Studioとは？
LM Studioは、ローカルLLMのダウンロード、実行、管理などを行えるアプリケーションです。
Apple Silicon上で、対応するGGUF形式やMLX形式のモデルを利用できます。
また、ローカルAPIサーバーとして動作させることもできます。
4.2. Codexと接続する
LM Studioでローカルサーバーを起動します。
lms server start --port 1234
続いて、Codexをローカルモデルモードで起動します。
codex --oss
LM Studioの公式ドキュメントでは、この方法でCodexをローカルLLMと連携させる手順が紹介されています。
利用したいモデルを明示する場合は、次のように指定できます。
codex --oss -m <モデルID>
これで、CodexがローカルLLMを推論バックエンドとして利用できる構成になります。
ただし、接続できることと、実際にコード修正を安定して実行できることは違います。
まずは小さなテストプロジェクトで、ファイルの読み取り、コード変更、テスト実行まで確認したいです。
5. マルチエージェント環境を作りたい
ここからが、今回最も妄想している部分です。
理想としては、親エージェントが開発タスクを受け取り、複数のサブエージェントに仕事を任せる構成を作りたいと考えています。
5.1. 役割を分担する
例えば、次のような役割です。
| エージェント | 仕事内容 |
|---|---|
| 親エージェント | 計画・タスク分解・結果統合 |
| 調査・実装担当 | コード調査・実装 |
| レビュー・テスト担当 | テスト・問題点の確認 |
親エージェントは、依存関係のないタスクをサブエージェントに委任します。
例えば、コードの調査とテスト結果の分析は、同時に進めやすい作業です。
一方、同じファイルを複数のエージェントが同時編集すると、変更が競合する可能性があります。
そのため、担当ファイルや作業範囲は明確に分ける必要があります。
5.2. 32GBで本当に並列実行できるのか？
ここが大きな課題です。
仮に大型モデルを複数ロードすると、32GBのメモリでは不足する可能性があります。
そこで、複数エージェントで同じLLMを共有する方式を考えています。
ただし、エージェントが並列で作業できることと、LLMの推論を完全に同時実行できることは別です。
例えば、次のような動作も考えられます。
- サブエージェントAがLLMへリクエストを送る
- サブエージェントBもリクエストを送る
- LLMサーバー側で処理を調整する
- 順番に結果を返す
この場合、エージェント側では複数のタスクが進んでいても、LLMの推論自体は順次処理される場合があります。
また、同時リクエスト数が増えると、KVキャッシュなどのメモリ使用量も増加します。
そのため、まずは以下の順番で検証したいです。
- 1モデル・1エージェント
- 1モデル・2エージェント
- 1モデル・3エージェント
- 必要であれば複数モデルの使い分け
最初から複雑な構成にせず、段階的に試すのがよさそうです。
6. タスクによってモデルを自動選択したい
もうひとつ試したいのが、モデルを選択するルーターです。
例えば、次のような構成です。
単純なタスクは小型モデルに任せ、複雑な設計やコード修正は大型モデルに任せるという考え方です。
タスク分類には、小型の分類モデルやルールベースの判定を使えそうです。
ただし、この方式には問題もあります。
それは、モデルを切り替えるコストが、本来の処理時間より大きくなる可能性があることです。
さらに、どのタスクを小型モデルで解決できるかを正しく判断する必要もあります。
そのため、まずは次の2つを比較してみたいと考えています。
方式A：単一モデルですべて処理する
構成が単純で、モデルのロードや切り替えによる待ち時間を減らせます。
方式B：タスクごとにモデルを切り替える
小型モデルを使える場面では、推論時間を短縮できる可能性があります。
どちらが効率的かは、実際に測定してから判断したいです。
まとめ
今回は、Mac mini M6を購入したら構築してみたい、ローカルLLM・マルチエージェント開発環境について妄想してみました。
現時点で考えている方針は、次のとおりです。
- 32GBのM6 Mac miniを中心に構成する
- Qwen3.6-35B-A3BなどのMoEモデルを試す
- LM StudioとCodexを組み合わせる
- 複数エージェントで単一モデルを共有する構成から始める
- 最終的には、タスクに応じてモデルを使い分ける仕組みを作る
もちろん、すべてが想定どおりに動くとは限りません。
特に、32GBというメモリ制限の中で、長いコンテキストや複数エージェントをどこまで利用できるかは、実機での検証が必要です。
それでも、小型のMac miniで自分専用のAI開発環境を構築できたら、かなり面白そうだと感じています。
まずは、単一のローカルLLMでCodexを動かし、簡単な開発タスクを最後まで完了できるかを試してみたいです。
そして、そこから少しずつエージェントの数やモデルの種類を増やしていきたいと思っています。