ローカルLLMをコーディングエージェントに繋ぐ｜OpenCode × Ollama の設定とモデル選び

この記事の要点

繋いだのに文章しか返らない: 最初に見るのはコンテキスト長の既定値。Ollama がドキュメントで挙げる要件は 64k 以上。
モデル選択リストに名前が出ない: 起動の仕方で見る場所が変わる。opencode 単体なら opencode.json の models と baseURL の宛先を順に見る。
どのモデルを繋ぐか: tools 対応・コンテキスト上限・サイズの 3 条件で絞り込む。特定の 1 モデルは挙げない。

数字はすべて 2026年9月10日に OpenCode と Ollama の公式ドキュメント・モデルページで確認した表示で、本記事では実測していない。速度・VRAM 使用量・生成品質の比較、および MCP サーバやプラグインを含めた外部通信の有無は扱わない。

OpenCode に Ollama を繋ぐ設定
1. インストール
2. Ollama を provider として登録する
ツール呼び出しが動かない（文章だけ返る）ときはコンテキスト長を見る
1. コンテキスト長を変える
モデル選択リストに名前が出てこないとき
1. OpenCode 2（ベータ）の自動検出
繋ぐモデルを選ぶ 3 つの条件
どこまで自動で走らせるか（Build と Plan）
費用とライセンス
まとめ
よくある質問
参考資料

OpenCode に Ollama を繋ぐ設定

OpenCode は端末インターフェース・デスクトップアプリ・エディタ拡張として提供される。ここで扱うのは端末で動かす形で、モデルの供給元に手元の Ollama を指定する。Ollama をまだ導入していないなら、ローカルLLMとは？Ollama × Gemma 4でコードを外に出さず使うAI環境を初心者向けに解説に入り口の手順がある。

インストール

macOS と Linux はインストールスクリプトを実行する。

curl -fsSL https://opencode.ai/install | bash

Windows は npm から入れる。

npm install -g opencode-ai

Windows の導入手段は npm のほかに Chocolatey・Scoop・Mise・Docker・Releases のバイナリがある。あわせて OpenCode 公式は、Windows では WSL の利用を推奨している。

Ollama を provider として登録する

接続の経路は二通りある。Ollama 公式ドキュメントが案内する ollama launch opencode は、選んだ Ollama モデルのインライン設定で OpenCode を起動するコマンドで、~/.config/opencode/opencode.json を上書きしない。既存の OpenCode の設定はそのまま適用される。設定として残す場合は、OpenCode が OpenAI 互換 API を持つ provider を任意に接続できる仕組みを使って自分で書く。

設定ファイルは JSON で、グローバル設定は ~/.config/opencode/opencode.json、プロジェクト単位の設定はプロジェクトルートの opencode.json に置く。Ollama を provider として書く場合の形は次のとおり。

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen3-coder:30b": {}
      }
    }
  }
}

先頭の $schema に https://opencode.ai/config.json を書くと、エディタで補完と検証が使える。npm に指定する @ai-sdk/openai-compatible はエンドポイントが /v1/chat/completions 形式のときの指定で、/v1/responses 形式のときは @ai-sdk/openai を指定する。options.baseURL の http://localhost:11434/v1 が Ollama の宛先にあたる。

models キーに書いたモデル名は、opencode を単体で起動したときのモデル選択リストに表示される。この起動の仕方では、ここに書いていないモデルはリストに並ばない。繋がらないときの切り分けで最初に確認する場所になる。

端末ではなくエディタの中で同じことをしたい場合、OpenCode 自身のエディタ拡張のほかに、別製品を使う経路もある。Cline でローカル LLM を動かして無料・オフラインで AI コーディングする（Ollama 連携）が近い構成にあたる。

ツール呼び出しが動かない（文章だけ返る）ときはコンテキスト長を見る

接続そのものは通っていて、モデルは応答する。ところがファイルの読み書きやコマンド実行が起きず、「こう直すとよい」という文章だけが返る。この症状で最初に見るのはコンテキスト長で、Ollama 公式ドキュメントは、OpenCode には 64k 以上のコンテキスト長が必要だと明記している。

一方、Ollama の既定コンテキスト長は搭載 VRAM で決まる。既定の設定のまま起動した場合の内訳は次のとおり。

搭載 VRAM	既定のコンテキスト長
24GiB 未満	4k
24〜48GiB	32k
48GiB 以上	256k

出所は Ollama 公式ドキュメントのコンテキスト長のページ（2026年9月10日確認）。24GiB 未満の GPU 環境では、既定のままなら 4k で走る。要件として挙げられた 64k 以上とは一桁違うため、ツール呼び出しに必要な指示や履歴が入り切らないまま応答が返る状況が起きる。

Ollama の記述はページによって分かれている。コンテキスト長のページは搭載 VRAM で決まる 4k / 32k / 256k を示し、FAQ は既定のコンテキストウィンドウを 4096 トークンと記載している。24GiB 未満のマシンでは、両方の記述が 4k 前後で一致する。食い違うのは 24GiB 以上で、この範囲でどちらが当てはまるかは判定しない。48GiB 未満なら、いずれの記述でも 64k には届かないため、既定のまま使っているなら上げる。48GiB 以上は、コンテキスト長のページの記述なら 256k で 64k を上回り、FAQ の記述なら 4096 で届かないため、既定のままではどちらに当たっているか分からない。いずれの範囲でも、起動時に OLLAMA_CONTEXT_LENGTH で値を明示すれば既定に依存しない。

コンテキスト長を変える

Ollama の FAQ は、コンテキスト長を変える方法として三つを挙げている。適用される範囲がそれぞれ違うため、目的に合うものを選ぶ。

サーバ全体に適用する: 環境変数を付けて起動する（OLLAMA_CONTEXT_LENGTH=64000 ollama serve）
実行中の対話に適用する: ollama run の実行中に /set parameter num_ctx で指定する
リクエスト単位で適用する: Ollama の API を自分で呼ぶときに、リクエストの options へ num_ctx を渡す（opencode.json の provider に書く options とは別のもの）

OpenCode から使うのはサーバに常駐した Ollama なので、既定を底上げするなら環境変数を付けた起動が扱いやすい。Ollama のアプリを使う場合は、設定のスライダーからも希望のコンテキスト長へ変更できる。

数字については、二つの公式ドキュメントで別々の値が置かれている。Ollama は 64k 以上を OpenCode 利用時の要件として挙げ、OpenCode はツール呼び出しが動かないときの調整の起点として num_ctx の 16k〜32k を挙げている。どちらの数字が正しいかは判定しない。操作としては 16k〜32k を下限、64k 以上を目標に、繋ぐモデルの上限の範囲で動く水準まで上げていく。上限が 64k に届かないモデルを使うなら、目標ではなくそのモデルの上限に合わせる。

ただし Ollama 公式ドキュメントは、コンテキスト長を大きくするとモデルの実行に必要なメモリが増えると記載している。伸ばした分がどこまで載るかは、VRAM 16GBでローカルLLMのコンテキスト長はどこまで伸ばせるか｜KVキャッシュ量子化の実測で確認できる。

モデル選択リストに名前が出てこないとき

ここは入れたものと起動の仕方で挙動が違う。インストール手順で入るのは opencode（1 系）で、opencode を単体で起動した場合に見る順序は決まっている。まず opencode.json の models にそのモデル名を書いたか。provider の models に書いた名前がモデル選択リストに表示される仕組みのため、書き漏らしたモデルは、手元に取得済みでもリストへ出てこない。次に options.baseURL の宛先で、Ollama の待ち受けポートやホストを既定から変えているなら、http://localhost:11434/v1 のままでは宛先が合わない。なお ollama launch opencode で起動している場合は前提が変わる。Ollama 公式ドキュメントは、opencode.json にだけ定義したモデルは ollama launch のモデルピッカーに出てこないと記載している。この経路で名前が出ないときは、opencode を単体で起動する形に切り替えてから確認する。

OpenCode 2（ベータ）の自動検出

モデルを自動で拾う挙動は、OpenCode 2 のドキュメントに書かれたもの。OpenCode 2 のドキュメントは、既定アドレス http://127.0.0.1:11434 の Ollama サーバから言語モデルを自動検出し、context・vision・tool-use の能力を Ollama から読み取ると説明している。あわせて、埋め込み専用モデルはセッションを駆動できないため自動検出の対象から外れる、とも説明している。これは OpenCode 2 のドキュメントの記述で、1 系の説明ではない。

OpenCode 2 のベータは npm install -g @opencode/cli@beta で導入し、opencode2 として実行される。OpenCode 1 の opencode バイナリを置き換えないため、両方を入れたまま並べて使える。ただし OpenCode 2 のドキュメントは、これがベータのもので、動作・API・設定・プラグイン API が変わりうると明記している。ベータの挙動を前提に手順を固めると、次の更新で崩れる余地が残る。

症状の切り分けは排他ではない。モデル名が選択リストに出た後でも、コンテキスト長が既定のままならツール呼び出しが動かないことがある。名前が出るかどうかと、長さが足りているかどうかは、別々に確認する。

繋ぐモデルを選ぶ 3 つの条件

絞り込みの条件は tools 対応・コンテキスト上限・サイズの三つ。順に見ていく。

tools に対応しているか

Ollama のツール呼び出しは、モデルがツールを起動して、その結果を応答へ取り込む仕組み。OpenAI 互換エンドポイントは /v1 配下にあり、/v1/chat/completions は tools に対応している。ただし Ollama の OpenAI 互換は API 全体ではなく、その一部に対する互換として提供されている。互換の範囲に入っていない機能を前提にした構成は、そのままでは動かない。

対応モデルは ollama.com のモデル検索で調べられる。検索結果は tools 能力で絞り込めるため、ツール呼び出しに対応したモデルを一覧で確認できる。coder で検索して tools で絞り込んだ 2026年9月10日時点の結果には、qwen3-coder・qwen2.5-coder・qwen3.6・qwen3.8・devstral-small-2・nemotron-cascade-2 が含まれる（結果は入れ替わる）。

コンテキスト上限とサイズ

次に、絞り込んだ候補のコンテキスト上限とダウンロードサイズを並べる。この検索結果のうち、タグの値まで確認できたものを取り出した。

モデル	サイズ	コンテキスト上限	モデルの上限が 64k 以上か
qwen3-coder:30b	19GB	256K	64k 以上
qwen3.8:27b	18GB	256K	64k 以上
qwen3.6:27b	18GB	256K	64k 以上
devstral-small-2:24b	15GB	384K	64k 以上
qwen2.5-coder	4.7GB（7b）/ 9.0GB（14b）/ 20GB（32b）	32K	64k 未満

サイズとコンテキスト上限は各モデルのタグ一覧、tools 対応は tools 絞り込みの検索結果という別々のページの表示で、いずれも 2026年9月10日時点のもの。表に挙げたモデルはすべて tools 絞り込みの検索結果に並んでいる。nemotron-cascade-2 はタグの値を確認していないため入れていない。qwen3.6 には 35b もあり、こちらは 23GB で 256K。コンテキスト上限はモデルのページが示す最大の長さで、実際に走る長さは、この上限・Ollama に設定した値・重みと合わせて手元のメモリに載るかの三つで決まる。指定する値はモデルの上限の範囲で決める。既定がモデルの上限を上回る組み合わせ（48GiB 以上のマシンで上限 32K のモデルを使う場合など）でも、既定に任せず上限の範囲で明示して指定する。上限を超える値を指定したときの扱いは、2026年9月10日に確認した範囲では公式ドキュメントに見つけられなかった。

読み方で誤解しやすいのが qwen3-coder:30b で、総パラメータ 30B のうち 3.3B だけが活性化する MoE 構成のモデル。名前の 30B はパラメータ総数を指し、モデルページに出る 19GB は配布されるモデルのサイズ。GPU へ全量を載せられるかを考えるときの目安にはなるが、実行時の VRAM 使用量そのものではない。Ollama の API は配布サイズ（size）と実行時の VRAM 使用量（size_vram）を別のフィールドで返しており、実際にどう載ったかは ollama ps で確認する。

qwen2.5-coder のコンテキストは 32K なので、64k を条件に採ると外れる。ただし OpenCode が起点として挙げる 16k〜32k の読み方では下限に収まるため、「動かない」ではなく「64k を条件にすると外れる」という位置づけ。7b が 4.7GB、14b が 9.0GB、32b が 20GB と刻みが細かいため、載せられる範囲を探すときの材料に使える。

Ollama のクラウドモデルはタグが -cloud で終わり、ローカルのモデルと同じ呼び出し方のまま Ollama のクラウドへ自動的にオフロードされる。OpenCode の接続設定は同じままなので、手元で動かすつもりならタグの末尾を見分けてから models に書く。

VRAM 16GB のマシンで選ぶ

表のサイズはモデル本体の大きさの目安で、実行時にはここへコンテキストの分が上乗せされる。VRAM 16GB のマシンでは、モデルページ上 19GB の qwen3-coder:30b と 18GB の qwen3.8:27b・qwen3.6:27b は、GPU へ全量を載せる候補として厳しい。15GB の devstral-small-2:24b も余裕が小さい。ただしこれらは配布サイズで、実行時の VRAM 使用量そのものではないため、全量が載るか、64k のコンテキストまで収まるかは、この数字だけでは確定できない。載り切らない分は CPU へ回して動かせる場合もあり、どう分かれたかは ollama ps の processor 列に 48%/52% CPU/GPU のような形で出る。以上は GPU に全量を収めて使う場合の見方で、CPU へ回す構成はここでは扱わない。その前提で取れる手は三つ。

VRAM 16GB でコンテキスト長をどこまで伸ばせるかを、KV キャッシュ量子化を含めた実測で確認してから決める
64k を条件に採らず、OpenCode が起点として挙げる 16k〜32k の読み方で、コンテキスト 32K の qwen2.5-coder を 7b（4.7GB）か 14b（9.0GB）で使う。32b はモデルページ上 20GB なので、16GB の GPU へ全量を載せる候補からは外す。この場合はサーバに設定する値も 32K の範囲へ合わせる
手元で動かす前提を外して、同じ系統のモデルを Ollama ではないクラウドの API 事業者で使う（Ollama の -cloud タグとは別の経路で、料金もそちらの体系）。Qwen3-Coderはクラウドで使うべきか｜料金・コーディング精度・データ取扱いをClaude・GLM・DeepSeekと比較に料金と扱いの違いがまとまっている

より大きい GPU を前提に 27B クラスを手元で動かす条件については、Qwen3.6-27Bとは？Dense 27BコーディングLLMをローカルGPUで動かすガイドが近い。

どこまで自動で走らせるか（Build と Plan）

OpenCode には組み込みの主エージェントが二つある。Build は既定の主エージェントで、すべてのツールが有効。Plan では、ファイル編集と bash が既定で ask、つまり実行の前に都度承認を求める設定。

「すべてのツールが有効」はツールを使える状態を指すのであって、実行の前に確認を挟むかどうかは設定で決まる。手元のリポジトリを触らせる範囲を絞りたいなら、この二つの区別を押さえてから走らせる。

セッション中は Tab キーで主エージェントを切り替えられる。TUI のスラッシュコマンドでは、/models が利用可能なモデルを一覧表示し、キーバインドは ctrl+x m。/compact は現在のセッションを圧縮するコマンドで、別名は /summarize。長い作業でコンテキストが埋まってきたときの逃げ道にあたる。

費用とライセンス

OpenCode 公式ドキュメントは OpenCode を「オープンソースの AI コーディングエージェント」と説明し、リポジトリのライセンスは MIT。Ollama 本体も MIT ライセンスで公開されている。この MIT はソフトウェア二つの条件で、繋ぐモデルの重みには配布元が定めた条件が別に付く。たとえば devstral-small-2 のモデルページはライセンスを Apache 2.0 と表示している（2026年9月10日時点）。業務で使うなら、繋ぐモデルの条件を個別に確認する。

OpenCode Zen は OpenCode チームが検証したモデルを提供するゲートウェイで、利用は任意であり、OpenCode を使うために必要ではない。課金は使った分だけの従量制で、価格は 100 万トークンあたりで示される。アカウントにクレジットを足して使う。Zen のページには期間限定で無料として掲載されているモデルも並ぶ（2026年9月10日時点）。掲載の内容は入れ替わる。

Ollama の料金ページは、自分のハードウェアで動かす分は、無料のプランを含めどのプランでも無制限と書いている。Ollama 自身が用意するクラウドのモデルを使う分だけがプランごとのクレジットで区切られる（2026年9月10日時点の表示）。

まとめ

手順の順序は、繋ぐ → コンテキスト長を上げる → モデルを絞る。どこで止まっているかで戻る場所が変わる。モデルを決めた後は、設定したコンテキスト長がそのモデルの上限に収まっているかをもう一度見る。

応答は返るのにファイルもコマンドも動かないなら、Ollama のコンテキスト長の設定。モデル名が選択リストに並ばないなら、opencode.json の models と baseURL の宛先（ollama launch で起動しているなら、先に opencode 単体の起動へ切り替える）。重みと指定したコンテキスト長の合計を GPU に載せきる前提なら、載らない時点でモデルのサイズか指定する値のどちらかを下げる（載り切らない分を CPU へ回して動かす構成も残る）。自動で走る範囲が広すぎると感じたら、Build と Plan の切り替え。

同じ Ollama を別の用途へ回すなら、OllamaでローカルRAGパイプラインを構築する方法が派生の一つ。

よくある質問

グローバルの設定とプロジェクトの設定に同じキーを書いたら、どちらが使われるか

複数の設定ファイルは置換ではなくマージされ、衝突したキーは後から読まれた設定で上書きされる。プロジェクトの opencode.json はグローバルの設定より優先される。片方にしか書いていないキーは消えず、両方の内容が合わさった状態で読み込まれる。共通の provider をグローバルに置き、プロジェクトごとに使うモデルだけ差し替える書き方ができる。

モデル名の 30B とダウンロードサイズの 19GB は、VRAM の目安としてどちらを見るか

ダウンロードサイズのほう。名前の 30B はパラメータ総数を指すだけで、配布ファイルの大きさとは対応しない。GPU へ全量を載せられるかを考えるときは、配布サイズの 19GB を粗い目安として使う。ここへ実行時のコンテキスト分が上乗せされるが、配布サイズは実行時の VRAM 使用量と同じではないため、足し合わせた数字で可否を決められるわけではない。実際の使用量は ollama ps で確認する。CPU に分けて動かす構成ではこの見方から外れる。

VRAM 16GB のマシンでは何を見て選ぶか

GPU に収めて使う前提なら、重みだけでなく、実際に指定するコンテキスト長の分を足した合計を見る。Ollama 公式ドキュメントは、コンテキスト長を大きくすると実行に必要なメモリが増えると記載している。モデルページ上 15GB のモデルであっても、そこへ 64k のコンテキストを設定した状態が 16GB の VRAM へ収まるかは、この数字だけでは判断できない。モデルのページに書かれた上限まで使う前提を置かず、指定する値を決めてから見積もる。

ベータの opencode2 を入れると、今の opencode はどうなるか

今の opencode はそのまま残る。別なのはバイナリで、設定ファイルの置き場所は同じ。OpenCode 2 のドキュメントは、V1 と同じ場所から設定を読み、対応する V1 のフィールドと native V2 のフィールドをメモリ上で正規化して扱い、元のファイルは書き換えないと説明している。V1 の形式のまま使い続けてよく、native V2 の形式は任意。ただし native V2 の形へ変換した設定を V1 に向けて使うことは、公式が「するな」と書いている。1 系と 2 系を並行して使うあいだは、この線を越えないようにする。