すべてをローカルで — オフラインAIワークスペース構築記
(instavm.io)- ローカル LLM 実行とコードサンドボックス環境を使い、クラウド依存なしでAIワークスペースを構成する方法
- OllamaでローカルLLMを起動し、Apple Containerを使って分離されたVMでコードを実行、Playwrightでヘッドレスブラウザーを用いた自動化とインターネットアクセスを可能にする
- UIは
assistant-uiをベースにし、モデル選択ドロップダウンとai-sdk統合、**MCP(Model Context Protocol)**を介した安全なコード実行環境を実装 - MCPで接続したCoderunner VM内でJupyterサーバーとブラウザーを実行し、チャート生成・画像/動画編集・GitHubツールのインストール・Web検索などをプライバシー保護状態で処理可能
- 現在はApple Silicon 専用で、UI改善やブラウザー検知回避、ツール管理機能強化が将来の課題
要件と背景
- 目標: クラウドおよびリモートコード実行なしで、すべてをローカルで実行すること
- 既存のLLMチャットアプリ（例: ChatGPT、Claude）は、クラウドベースのLLMチャット、クラウド/ローカルコード実行、インターネットアクセス機能を提供する
- オープンソースLLMの普及拡大により、これらすべてを完全にローカルで実行できるかを検討
- ローカルLLMだけでは不十分なため、分離された環境でコードを実行する必要があり、ブラウザー経由でコンテンツにアクセスすることも必要
アイデアの構想
- LLMを完全にローカル環境で実行
- 軽量VM（仮想マシン）内でのみコード実行を処理し、ホストシステムのリスクを遮断
- ヘッドレスブラウザーを追加し、自動化と新規情報・ツール探索をサポート
- AIの企画立案からコード実行まで完全にローカルで行われるプライバシー保護中心のワークフローを構築
- 外部サービスへデータを提供せず、ローカルで画像編集、動画編集など多様な作業を可能に
技術スタック
- LLM: Ollama（ローカルモデルおよび一部外部モデルに対応）
- UI:
assistant-ui+ ai-sdk（モデル選択機能を追加） - VM ランタイム: Apple
container（分離されたVM環境を提供） - オーケストレーション:
instavm/coderunner（MCP経由でJupyterサーバーを接続） - ブラウザー自動化: Playwright（MCPツールとして公開）
Macアプリの試行と切り替え
a0.devを使ってネイティブMacアプリ開発を試みたが、iOS中心で難航- Electron + NextJSによるラッピングも試したが複雑性の問題で断念
- 最終的にローカルWebベースの
assistant-uiへ切り替え
Assistant-UIのカスタマイズ
- モデル選択ドロップダウンなど複数LLM対応機能を提供するものとして期待されたが、限定的だった
- サンプルを参照後、ai-sdkでマルチモデル選択機能を自前で実装
- 初期はOpenAI/Anthropicのようなクラウドモデルもサポートし、段階的にローカル化へ誘導する戦略
Tool-callingとモデル対応の課題
- Tool-callingをサポートするモデルが必要だったが、Ollamaなど一部は実際には未対応
- 公式ドキュメントでツール対応が明記されていても、実装が不足しているケースが多い
- オープンソースエコシステムの変化が速いため、ツール対応状況やトークン単価などの変動が大きい
コンテナベースの隔離コード実行
- AppleのContainerツールを使用すると、Dockerと比べてコンテナごとに完全な分離VM環境を提供するため、AI生成コードをより安全に実行できる
- VM環境にJupyterサーバーをデプロイし、Model Context Protocol(MCP)で公開して、さまざまなツール（Claude Desktop、Gemini CLIなど）からすぐに利用可能
coderunnerMCPサーバーコードを公開し、外部ツールと連携するサンプルを提供- Apple Containerツールはまだ不安定で、ビルド/イメージの問題時には再試行が必要になることがある
- 実際の動画編集テストなどでUI + LLM + Coderunner構成の正常動作を確認
ヘッドレスブラウザー統合
- コンテナ内にPlaywrightベースのヘッドレスブラウザーをデプロイし、MCPツールとして公開
- 新規ツール・情報探索、Githubの使い方検索、リサーチの自動化などの活用を想定
- 基本ワークフロー: ローカルLLM + サンドボックスコード実行 + ヘッドレスブラウザーの組み合わせを構築完了
可能な作業例
- 特定テーマの調査と要約
- 自然言語コマンドでCSVチャート作成とレンダリング
- ffmpegを使った動画編集（区間のトリミングなど）
- 画像のリサイズ、トリミング、形式変換
- Githubツールのコンテナ内インストール
- ヘッドレスブラウザーによるウェブページクローリングと要約など
ファイルボリュームのマウントと隔離
- ホストの
~/.coderunner/assetsをコンテナの/app/uploadsにマッピングし、ファイルを安全な共有領域に保管 - 実行されたコードはホストシステムに直接アクセス不可とし、セキュリティを確保
制約と今後の課題
- Apple Silicon環境でのみ動作、macOS 26はオプション
- ツール管理、出力ストリーミングなどUI改善が必要
- ヘッドレスブラウザーが一部サイトでボット検知によりブロックされる問題が存在
結論
- 本プロジェクトは単なる実験を超え、コンピューティング主権およびプライバシー保護を重視したモデルである
- クラウドやリモートサーバー依存なしで、個人ローカルマシン上でデータを安全に処理する体験を提供する
- 最高性能のLLMは大規模クラウドに留まる可能性があるが、個人プライバシーを守ることができるローカルAIツールの発展を志向する
- オープンソースの
coderunner-uiはGitHubで利用可能で、フィードバックとコラボレーションを歓迎
2件のコメント
HNの「単なる趣味に近い」という意見に同意します。
いくらいろいろいじってみても、商用と同等の便利さと速度には到底かないませんでしたね。。
Hacker Newsコメント
こうした考え方には、私は昔から惹かれるものの、最終的には自分が使えるモデル性能やクラウドをオンデマンドで動かした時のコストを考えると、実務的な戦略よりも単なる趣味寄りだと思う。
ハードウェアは加速度的に進化するため、中古機を買っても同じ速度で価値が下がるので、実際にハードウェアへ投資する正当性が見いだしにくい。
さらにローカル環境で動作するウェイトの性能もかなり低下するため、今はその価値が薄い。
いずれ状況は変わるだろうと予想していて、優れたウェイトが公開された時にローカル推論スタックへ投資するのは楽しみだ。
それまでは、価値が早く減価する高価な資産をただ抱え込むことになるだけだ。
最近のローカルLLMエコシステムは本当に面白く、みんなが何をしているのか見るのが楽しい。
ただ、私のMacBook Proの巨大なRAMでローカルLLMを動かすたび、フロンティア（最新SaaS LLM）との差がはっきりする。
月20ドル程度で、トークン単位で課金して多数の高性能モデルを使えるのに対し、速度も品質もローカルモデルはまだ差が大きい。
ベンチマークのグラフだけ見るとこの差は見えにくいが、実際にはフロンティアモデルの方がはるかに優れている。
OpenAIやAnthropicのモデルも時に遅くエラーが多いと感じるが、ローカルだとさらに顕著だ。
プライバシー重視の趣味や実験用途なら良いが、私はむしろ次世代Mac（128GB RAMのような本物のハード）が出るまで待った方がいいと思う。
APIの裏側にいるモデルは、最終的にアウトプットで収益を上げ始めると品質がさらに落ちるだろうと考えている。
これは時間の問題だ。
「ハードウェアはすぐ進化するから、中古で買ってもすぐ価値が落ちる」という主張には疑問がある。
場合によっては、最高スペックでなくてもモデルは継続的に動かせると思う。
最終的には古典的なOPEX（運用費）とCAPEX（資本支出）の議論で、経済的に見てもクラウドが有利なのは本当にごく特定のケース（インフラを即座に立ち上げる必要があるが需要予測が難しい場合）に限られる。
LLMはそこにほとんど当てはまらない。
OPが約600ドル投資したというのは、EC2と比べると約3か月分の価格だ。
この観点から、OPの主張を数値でどこまで支持できるか疑問だ。
私も将来変わると期待している立場だ。
最近はClaude Codeのようなものを作業にますます使っており、毎日コーディングを会社に頼りたいとは思わない。
プラン上限、APIコスト、毎月100〜200ドル払う不安、使うデータがAI企業に収集・監視されるリスクが嫌だ。
スマートホーム製品もすべてローカル制御のものだけ使い、外部からアクセスする必要がある場合は自分でソフトを設定して自サーバーで動かしている。
いつでも会社がサービスを停止したり、値上げしたり、データを使ったりする可能性があるので、そういうことに縛られたくない。
それでも現時点でLLMを自宅ハードやVPSで動かす動機、費用、知識、運用の気力はない。
Anthropicに月20ドル払うことに満足しており、現在公開されているオープンモデルは、フロンティア級SaaSには追いつけないレベルだ。
それでもいつか変化が来ることを願っている。
この状況は絶対に変わらないと思う。
2年後にGPT-5級のローカル選択肢が出ても、その頃にはクラウド側でさらに優れた選択肢が生まれており、結局同じ悩みが続くはずだ。
ローカルかつサンドボックス化された実行レイヤーにフォーカスしたこの取り組みは、プライベートAIワークスペースを実現する大きなパズルの1ピースだと評価している。
coderunnerツールはかなり有用そうに見える。
ただ、もう1つの課題は、AIがメール・ノート・ファイルなど個人データを理解する「知識レイヤー」の構築だ。
RAGで数年分のメールを扱うだけでも、ベクトルDBの保存容量は簡単に50GBを超える。
（ちなみに、私はこの問題に取り組むBerkeleyのチームの一員だ。）
我々はLEANNというベクトルインデックスを作り、埋め込み自体を保存せずに、ストレージを約97%削減することに成功した。
そのため、デジタルライフ全体をローカルでインデックス化することが現実的になった。
この超軽量な知識インデックスとローカル実行エンジンを組み合わせることが、本当の「ローカルJarvis」への道だと感じる。
コード: https://github.com/yichuan-w/LEANN
論文: https://arxiv.org/abs/2405.08051
2025年時点では、メール数年分のベクトルDBが50GB程度という要件はむしろ控えめだと思う。
LEANNの情報をありがとう。
RAGをLLMエージェントやパイプライン、実行エンジンの知識レイヤーとして使うことに特に興味がある。
大規模コードベースとLLMを連携できるか以前から気になっていて、RAGソリューションがすでにClaude Codeと連携しているという点が実験のハードルを下げてくれるので楽しみにしている。
もしRAGとLLMを組み合わせて大規模コードベースで実際に作業した人がいれば聞きたい。
まずはフロントエンドモデル（LM）はクラウドで使う形から始め、実際に試してみる予定だ。
参考: https://github.com/yichuan-w/LEANN/blob/main/packages/leann-mcp/README.md
埋め込みやベクトル保存構造についてほとんど知らない。
クラウド側の埋め込みでも、この「剪定グラフ（pruned graph）」手法を使っているプロジェクトがあるか気になる。
インデックスが元データより大きくなるのは違和感がある。
通常インデックスは高速アクセスのための効率的な形式だと考えていたのに、ここまで膨張するのはやや不自然だ。
「世界最高のLLM」を使っても想像通り滑らかでない理由の1つは、これらのモデルがステップを省略したり、プラットフォーム固有の要件を見落としたり、逆に問題を拡大するハルシネーションを出したりするからだ。
これはネイティブアプリ開発に関する学習データ不足をよく示している。
ネイティブアプリ設計についてのブログやMediumの長文記事はほとんどなく、オープンソースのデスクトップアプリのプロジェクト数もモバイル/Webに比べて非常に少ない。
1990年代にはMSが専門ライターを雇ってWindowsコーディングの良い本（代表例はCharles Petzoldなど）を公開していたが、そのような専門産業自体が今ではほぼ消滅している。
このため、今後トレーニングデータの空白はさらに拡大すると考える。
最終的には、ソフトウェアエンジニアリング全体の流れと同様で、ネイティブデスクトップアプリを作りたい人が少なく、キャリア的にも「行き詰まり」の道だからだ。
1990年代、Windowsデスクトップアプリ開発者は中産階級の生活が保証され、敷居が高かった（C/C++が難しくWindows APIの学習もハードルが高く、MSが教育に膨大な資金を投入していた）が、今では状況は大きく変わった。
今やOSベンダー（Microsoft、Apple）や一部のレガシーソフト会社（Adobe、Autodeskなど）を除けば、デスクトップアプリ開発需要は極めて少ない。
OllamaのmacOSアプリを試しに使ってみたところ、起動直後に何かのGoogleドメインへ接続を試みるのを見つけた。
「完全なプライバシー」という言葉を信じるのが難しい。
https://imgur.com/a/7wVHnBA
自動更新チェックが原因だ。
https://github.com/ollama/ollama/blob/main/docs/faq.md
この種のネットワーク呼び出しは監査可能なので、むしろ信頼できるとも思う。
更新ごとにネットワーク呼び出しを自動追跡すれば十分管理可能。
vscodeのcline拡張、copilot拡張でも同じ現象を見た。
ローカルollamaのみを使う設定にしてアウトバウンド接続を遮断すると、動作自体がしなくなる。
設定でtelemetryをオフにしても、clineは外部通信を試み続ける。がっかりした。
このテーマは意外と頻繁に思い浮かぶ。
プライバシーを確保するにはかなりの摩擦と難しさが伴うと感じている。
私は依然としてローカル方式を好むのだが、それは主に多くの場合AI推論速度が遅いか、ローカルとの違いがほとんどないと感じるからだ。
最近cerebras（あとでgroqも聞いた）を使い、1000トークン/秒という速度を体感したことで、待機に対する忍耐の基準が完全に変わった。
cerebrasはデータを保存しないと述べており、私は彼らと一切スポンサー関係がないことを信じてほしい（むしろスポンサーがあればよいのに）。
本当に良いサービスだ。
でもいつか速度面でも本当に意味のある進歩があることを期待している。
diffusionモデルのアーキテクチャはとくに高速だと感じる。
今の段階でのボトルネックは、ソフトウェアよりハードウェアだと思う。
ローカルで使えるLLMを回すには、少なくとも2,000ドル程度のハード（たとえばStrix Halo、AI Max 395）が必要。
Strix Haloが何度かアップグレードされれば、かなり楽になるだろうと期待している。
そのような変化は実際かなり速く起きている。
https://simonwillison.net/2025/Jul/29/space-invaders/
実際にこの価格帯のハードを揃えても、「実用的」という基準自体が曖昧だと思う。
この技術が本当に役立つには、まるで魔法のようにすぐに使える体験が必須だ。
遅くてあいまいな結果を見ながら、ずっと設定をいじり続けると、ほぼ全ての価値が失われる。
ローカルモデルもかなり改善したが、コーディングスキルだけ比べるとまだClaudeのようなモデルには及ばない。
最近OpenRouterの最新QwenとGLMモデルをclineで直接動かしてみたが、Claude 3.0程度に見える。
ベンチマークは現実をうまく反映していないと思う。
製品名とブログ記事の説明が少し混乱する。
ホームページではクラウドでVMを立てる（例えばFirecrackerのように）と見えるのに、
ブログではMac専用のローカルVMを実行するという読み取り方になる。
以前それを作っていた立場から、後者をgpt-ossの新作と組み合わせて試したいと思っている。
OPへ、https://github.com/assistant-ui/assistant-ui のリンクが機能していないことを知らせる。
本当に素晴らしく、よく設計されたプロジェクトだと思う。
私も似たものを作っていて、肝心なのはクラウドと完全ローカル環境を1キーで自由に行き来できるように簡単にすることだ。
すべてのデータ/設定/プロンプトはローカルにのみ保存され、API呼び出しも自社サーバー経由ではなく、直接プロバイダへルーティングされる。
現在はmlc-llmでブラウザ上で完全ローカル推論を実現しており（Qwen3-1.7bがかなりよく動作している）、
https://hypersonic.chat/