10月27日、latent.spaceが「Coding From the Himalayas With an Offline AI Agent」と題した記事を公開した。ネットワークが不安定な環境でもOpenCode＋Ollama＋Qwenを組み合わせてオフラインでAIコーディングエージェントを動かす具体的な手順を紹介する内容だ。クラウドAPIへの依存を断ち切ってローカルLLMだけで開発支援を完結させる構成は、地方・海外・セキュアな閉域網など「接続が保証されない環境で開発する」すべてのエンジニアに参考になる。
著者はThomson ReutersのPrincipal Engineerとして、コーディングレビューを日常業務とする人物だ。1年前にヒマラヤ山麓に移住し、頻繁なネットワーク障害・停電に直面するようになった。「普段当たり前に使っていたコーディングエージェントをオフラインで使えるか？」という疑問から、本記事の実験が始まった。
構成：3つのツールの役割分担
オフライン環境でのAIコーディングを実現するために使うツールは以下の3つだ。
- OpenCode: オープンソースのコーディングエージェント。ファイルの読み取り・編集提案・コマンド実行（テストスイートなど）をこなす。実行前に必ずユーザーへの確認プロンプトを挟む設計になっている
- Ollama: ローカルでLLMを動かすためのランタイム。OpenCodeからのリクエストをOpenAI互換APIとして受け付ける
- Qwen3.5 9B: 今回使用するオープンウェイトモデル。コード生成とツール呼び出しの両方を評価するベンチマークで4Bより高いスコアを記録している（※Qwen3.5は本記事公開時点のモデル名に従う）
OpenCodeの代替として**Aider**も挙げられているが、本記事ではOpenCodeに統一して検証している。
モデル選定の根拠
Qwenには複数のサイズがある。今回9Bを選んだ理由は、コード生成を測るLiveCodeBench v6とツール呼び出しを測るBFCL-V4の公開スコアが4Bを明確に上回るためだ。
| モデル | LiveCodeBench v6 | BFCL-V4 |
|---|---|---|
| Qwen3.5 4B | 55.8 | 50.3 |
| Qwen3.5 9B（今回使用） | 65.6 | 66.1 |
| gpt-oss-20b | 74.6 | 非公開 |
（スコアはQwen公式モデルカードに掲載されたもの。ローカル実行時の速度は別途確認が必要）
なお表中のgpt-oss-20bは、OpenAIが公開したオープンウェイト系モデルとして元記事に登場する比較対象であり、商用APIとは異なるローカル実行可能なモデルとして位置づけられている。本構成では採用していないが、将来的な選択肢として参考値として掲載されている。
ダウンロードサイズは約6.6〜7.6GB。RAMは12〜16GBが目安だが、OpenCodeの64kトークン設定を使う場合はさらに余裕を持たせる必要がある。
セットアップ手順
元記事に示された手順の概要は以下のとおりだ。
Terminal BでOllamaを起動する。OLLAMA_NO_CLOUD=1でクラウド機能を無効化し、ローカルのみで動かす。
OLLAMA_HOST=127.0.0.1:11434 OLLAMA_NO_CLOUD=1 OLLAMA_CONTEXT_LENGTH=65536 ollama serve
Terminal AでQwenをダウンロードする。
ollama pull qwen3.5:9b
opencode.jsonではbaseURLをOllamaのローカルアドレス（http://127.0.0.1:11434/v1）に向け、Webツールを無効化している。これが「完全ローカル動作」の肝だ。OllamaはOpenAI互換のAPIエンドポイントを提供するため、OpenCodeからは通常のAPIクライアントとして透過的に扱える。
オフラインでバグ修正を実際に試す
サンプルとして、支出合計を計算するPythonスクリプト（expense_total.py）のバグ修正タスクを実行した。正しい合計は25.50だが、バグのある実装は最後の支出額の8.00しか返さない。
Wi-Fiを切断後、ローカルAPIと外部接続をそれぞれ確認する。
curl --noproxy '*' --fail http://127.0.0.1:11434/api/tags
# → Ollamaが応答しqwen3.5:9bが確認できる
curl --noproxy '*' --connect-timeout 5 --max-time 10 --head https://example.com
# → Could not resolve host（外部接続は確実に切れている）
オフライン状態でOpenCodeに以下を指示する。
Fix the bug in expense_total.py so the existing tests pass.
Don't change the tests or install anything.
Run the tests and explain your fix.
Qwenが提案した修正は1行だった。
# 修正前
total = Decimal(amount)
# 修正後
total += Decimal(amount)
代入演算子を+=に変えるだけのシンプルな修正だ。エージェントは編集前にユーザー承認を求め、修正後に5つのテストをすべて通過させた。著者がターミナルで手動確認した結果も同様にパスした。
OpenCodeのベンチマーク上の特性
元記事では、コーディングエージェントのスキャフォールディング（実行環境の構造）がベンチマーク結果に与える影響を論じた研究として、OpenCode・Goose・OpenHands-SDKを50タスクで比較した内容が引用されている。OpenCodeのパス率はGooseより高い結果が出た一方、1タスクあたりのトークン消費量はGooseの約40倍と報告されている。ローカルモデルでは処理速度に直結するため、長いコンテキストを扱う場合は注意が必要だ。
オフラインで現実的にできること・できないこと
新規パッケージのインストールやWeb検索は当然できない。一方、以下のタスクはオフラインで完結できる。
- 既存コードの説明・解析
- 失敗しているテストの原因調査と修正
- 小規模なリファクタリング
- 機能の実装補助（依存ライブラリが既にローカルにある場合）
事前にモデル・プロジェクト依存・テストツールをすべてローカルに揃えておくことが前提条件だ。ヒマラヤという極端な例を除いても、オフィスの閉域網・飛行機内・セキュリティポリシー上クラウドAPIが使えない現場など、「接続が保証されない開発環境」は珍しくない。ローカルLLM活用の実用的な構成例として、幅広い読者に参考になるはずだ。
詳細はCoding From the Himalayas With an Offline AI Agentを参照していただきたい。
