はじめに
前回はRTX 5060 Ti 16GB×2のGPU環境を整えました。今回はWindows上のOllamaで動かすQwen3.8-27BをQwen Code Desktopにつないだ構成と設定をまとめます。
前回の記事はこちらです。
「ローカルLLMは動いたけど、そこから何をするの？」って思ったこと、ない？今回はブログ制作の作業環境として使えるところまでつなぐ話だよ！
今回は接続とモデル登録に絞ります。速度比較やSkills・Contextの深掘りは次回、承認の範囲や秘密ファイルの保護は別の記事で扱います。
1．先に結論
私の環境では、Qwen Code DesktopのCustom ProviderからOllamaのOpenAI互換APIへ接続し、Ollama上のQwen3.8-27Bを利用できました。接続先は http://127.0.0.1:11434/v1 です。
Ollama側で num_ctx を変えた64K用と128K用を別名で作り、Qwen Code Desktopにも別モデルとして登録しました。普段は64K、長い文脈では128Kへ切り替え、64Kを既定にしました。
qwen3.8:27b-64k と qwen3.8:27b-128k は私が付けたローカル名で、公式製品名ではありません。
64K側は num_ctx 65536、128K側は num_ctx 131072 であります！モデル名も分けておけば、Qwen Code側で選ぶときに設定の取り違えを減らせるのであります。
2．Qwen Code Desktopを選んだ理由
ローカルLLMをチャットで応答させるだけでなく、ブログ制作の作業環境に組み込みたくてQwen Code Desktopを選びました。プロジェクト固有の指示を参照しながら複数のファイルを扱い、ShellやSkillsなどのツールを使う一連の作業を、ローカルモデルでどこまでできるか試したかったからです。
いつものブログ制作の指示や道具を、ローカルモデルからどこまで使えるか試してみたかったんだよ！
3．接続構成とOllama側の確認
今回の構成はシンプルです。
Windows → Ollama → Qwen3.8-27B → OpenAI互換API → Qwen Code Desktop
GPU環境は前回構築したRTX 5060 Ti 16GB×2です。今回はソフトウェア側の接続に絞ります。
まず、Ollamaにモデルが存在していることを確認しました。
ollama list次に、OpenAI互換APIからモデル一覧が見えるかを確認しました。
curl.exe http://localhost:11434/v1/models実行中のモデルを確認するときは、次のコマンドも使いました。
ollama ps
Ollamaの公式ドキュメントでもOpenAI API互換のエンドポイントが提供されており、ローカル接続例では http://localhost:11434/v1/ が使われています。2026年10月2日時点で、/v1/models も対応エンドポイントとして案内されています。
Qwen Code側を触る前に、Ollamaでモデル一覧とAPI応答を確認しておくのであります！接続先とモデル名を先に確かめれば、設定ミスの切り分けもしやすくなるのであります。
4．Qwen Code DesktopのCustom Providerを設定する
Qwen Codeは settings.json の modelProviders で複数モデルを登録できます。2026年10月2日時点の公式ドキュメントでは、OpenAI互換APIは modelProviders.openai に定義します。同日時点のGitHub Releasesでは、安定版の最新はv0.24.7です。私が環境を構築したのは2026年9月上旬のため、画面や項目名は版によって異なることがあります。
私の環境で設定した要点は次の通りです。
| 項目 | 設定 | 意味 |
|---|---|---|
| protocol | OpenAI互換 | OllamaのOpenAI互換APIへ接続 |
| base URL | http://127.0.0.1:11434/v1 | ローカルOllamaの接続先 |
| API key | ollama | ローカル接続用のダミー値 |
| id | qwen3.8:27b-64k など | Ollama上の実モデル名と一致させる |
| name | Qwen3.8 27B - 64K - Thinking など | Qwen Code上で見分ける表示名 |
| contextWindowSize | 65536 / 131072 | Qwen Code側で扱うContext容量の設定 |
| approvalMode | default | ファイル編集やShell実行の前に承認を求めるモード（画面表示は Ask before edits、公式資料の呼称は Ask Permissions） |
id はAPIへ送るモデル識別子なのでOllama上の名前と揃え、name は見分けやすい表示名にしました。API keyはOllama公式例と同じ ollama を使用しました。これはクライアント側では必要でもOllama側では無視されるダミー値です。
実際の settings.json は、ユーザー名・ローカルパス・環境変数名の固有部分を出さない形にすると、概念としては次のようになります。
{
"env": {
"OLLAMA_API_KEY": "ollama"
},
"modelProviders": {
"openai": [
{
"id": "qwen3.8:27b-64k",
"name": "Qwen3.8 27B - 64K - Thinking",
"envKey": "OLLAMA_API_KEY",
"baseUrl": "http://127.0.0.1:11434/v1",
"generationConfig": {
"contextWindowSize": 65536,
"extra_body": {
"enable_thinking": true
}
}
},
{
"id": "qwen3.8:27b-128k",
"name": "Qwen3.8 27B - 128K - Thinking",
"envKey": "OLLAMA_API_KEY",
"baseUrl": "http://127.0.0.1:11434/v1",
"generationConfig": {
"contextWindowSize": 131072,
"extra_body": {
"enable_thinking": true
}
}
}
]
},
"security": {
"auth": {
"selectedType": "openai"
}
},
"model": {
"name": "qwen3.8:27b-64k"
},
"tools": {
"approvalMode": "default"
}
}extra_body.enable_thinking=true は私が登録した設定です。Qwen Code側では extra_body を追加パラメータとして渡せますが、ここではOllama側の一般仕様とはせず、私の設定値としてのみ扱います。
id はOllama側の実名、name は人が見分ける表示名であります！contextWindowSize も64Kと128Kで分けておけば、Qwen Code側のモデル定義までセットで切り替えられるのであります。
5．Ollamaで64K／128Kモデルを作る
次に、同じベースモデルからContext設定だけを変えたモデルをOllama側で作りました。64K用のModelfileは次の2行です。
FROM qwen3.8:27b
PARAMETER num_ctx 65536これを使ってモデルを作成します。
ollama create qwen3.8:27b-64k -f Modelfile128K用は num_ctx を 131072 に変えます。
FROM qwen3.8:27b
PARAMETER num_ctx 131072ollama create qwen3.8:27b-128k -f Modelfile
Ollama公式のModelfile資料でも FROM と PARAMETER num_ctx を使う方法が案内されており、num_ctx の既定値は2048とされています（2026年10月2日時点）。長い文脈で使うため、私はこの値を変えたモデルを別名で用意しました。Qwen3.8-27Bの公式モデルカードはネイティブContext長262,144トークンを案内していますが、64K／128Kは私が付けたローカル名です。
ベースは同じ qwen3.8:27b で、変えているのは num_ctx であります！64K／128Kという名前はローカル管理用なので、公式モデルの別エディションと混同しないのがポイントであります。
6．64Kと128Kを別モデルとして登録する
Ollama側に2モデルを作ったら、Qwen Code Desktop側にもそれぞれ登録しました。
| 用途 | Ollama上のid | Qwen Code上の表示名 | contextWindowSize |
|---|---|---|---|
| 常用 | qwen3.8:27b-64k | Qwen3.8 27B – 64K – Thinking | 65536 |
| 長文用 | qwen3.8:27b-128k | Qwen3.8 27B – 128K – Thinking | 131072 |
私は64Kを既定モデルにしました。必要になったときだけ128Kへ切り替える前提です。速度や処理時間の比較はこの回では扱わず、次回に条件を揃えて整理します。
64Kと128Kを“同じモデルの設定違い”として頭の中だけで管理するより、最初から別の選択肢として見える方が迷いにくいよ！
7．承認モードは default（Ask before edits）から始めた
Qwen Codeでは、ツール実行時の承認方法も設定できます。私は tools.approvalMode を default にしました。
今回確認したQwen Code Desktopの画面では、このモードは「Ask before edits」と表示されています。公式ドキュメントでは Ask Permissions と呼ばれ、設定値 default はファイル編集やShell実行の前に承認を求めます。一方、yolo は操作を自動承認します。私はまず「何を編集し、何を実行しようとしているか」を見られる状態から始めました。承認の範囲や .env の保護は、別の記事でまとめます。
approvalMode: "default" なら、編集やShell実行の前に確認を挟む運用であります！ローカルモデルでも“どの操作まで任せるか”は、モデル性能とは別に決めておく意味があるのであります。
8．最初の動作確認で見えたもの
接続後、ブログ制作用の作業環境を開くと、AGENTS.md、CONTEXT.md、プロジェクト、Skills、read、write、edit、grep、glob、shell などが認識されていました。Skillsは画面上で24種を確認しました。
ここで見たかったのは速度ではなく、「ローカルのQwenをブログ制作のルールやファイルを扱うエージェント環境につなげられるか」です。その入口までは作れました。
一方で、Skillsの見え方やCLI追加、Contextの圧縮エラー、探索範囲による処理時間の違いは、実際に使い始めてから見えてきた論点です。ここから先は接続設定とは分けて、次回にまとめます。
すごーい！接続できた、で終わりじゃなくて、ブログ制作の指示や道具が見えるところまで確認したんだよ。次は“見える”と“実用になる”が同じかどうかを確かめる段階だよ！
おわりに
GPU環境を作っただけでは、ローカルLLMをブログ制作の道具として使えるわけではありません。今回はOllamaのQwen3.8-27BをQwen Code Desktopへつなぎ、64K／128Kを別モデルとして登録し、64Kを既定にするところまで進めました。
次回は、64K／128K／256Kを実際にどう使い分けたかに加えて、Skillsの見え方やContext周りで起きたことを整理します。
これで“ローカルLLMを動かす”から、“ブログ制作の作業環境に組み込む”へ一段進んだよ！次は実際の“重さ”を見る回だよ。モデルが重いのか、わたしが重いのかは……ナイショ！
それでは、良きホビーライフを！
コメント