新たに文書化されたMac向け開発環境では、OpenCode、ローカルでホストするOllamaモデル、Dockerサンドボックスを組み合わせ、推論のたびにリモートのモデル提供事業者へデータを送信せずにコーディングエージェントを実行する方法の一例を示している。このワークフローは、およそ300億パラメーター規模のモデルを保持できるだけのユニファイドメモリを備えたApple Silicon搭載マシンを対象としている。

筆者は48GBのMacBook Proでこの構成をテストし、この容量を、有用なコンテキストウィンドウを確保しながら大型のローカルモデルを動かすうえで実用的な水準だとしている。Ollamaがモデルを配信し、現在はAppleハードウェア向けのMLXもサポートしている一方、OpenCodeはコーディングエージェントのインターフェースを提供する。sbxと呼ばれるDockerのサンドボックスツールは、エージェントによるアクセスを各プロジェクト内に限定する。

このガイドは、用途の異なる2つのモデルとして、270億パラメーターのQwen 3.8派生モデルと310億パラメーターのGemma 4派生モデルを推奨している。掲載された量子化版のダウンロードには、それぞれ約32GBと34GBが必要となる。マシンに応じて、標準のMLX版も代替候補として提示されている。これらの推奨は筆者自身の環境を反映したものであり、普遍的な性能比較ではない。

メモリ管理は、この構成の重要な要素だ。モデルの使用によって利用可能なメモリがすべて消費されないよう、Qwenモデルのコンテキストは6万4,000トークンに制限され、サンドボックス用には約3GBが確保される。メモリが少ないユーザーは、より小型のモデルや短いコンテキストを使うか、モデルとコンテナの間で異なる配分を選ぶ必要がある。

サンドボックス層が対処するのは、プライバシーとは別の問題だ。推論をローカルで実行すればモデルへのリクエストはマシン内にとどまるが、コーディングエージェントが誤ったコマンドを実行したり、意図しないファイルを変更したりする可能性は依然としてある。プロジェクト固有のコンテナは、そうした操作が行われる環境を限定する。このガイドではプロジェクトごとにsbxキットが必要とされ、この機能を利用するにはDockerへのサインインが必要だと記されている。

この構成は、ローカルエージェントを実用的に利用するために複数の構成要素が必要であることを示している。言語モデルがメモリの大部分を消費し、Ollamaがモデルの配信を担い、OpenCodeが対話型のエージェントループを管理し、コンテナが運用上の境界を設ける。いずれの要素も、それ単独では完全なワークフローを提供しない。

ローカルモデルには今なお、速度、能力、ディスク使用量、設定の複雑さをめぐるトレードオフがある。特に長いコンテキストや難しい推論が必要な場合、あらゆるコーディング作業でリモートの最先端システムに匹敵するとは限らない。しかし、オープンモデルの進歩とAppleの共有メモリアーキテクチャによって、プライベートな自己ホスト型エージェントのワークフローは、より実現しやすくなっている。文書化されたこの技術スタックは、自動コード実行をサンドボックス内に保ちながら、そうした制御を求める開発者に再現可能な出発点を提供する。