VS Code や JetBrains で Continue 拡張機能を利用する開発者は、しばしばアーキテクチャ上のジレンマに直面します。キーストローク単位の Tab コード補完には極めて低いレイテンシ(最初のトークン生成までの時間 TTFT が 300ms 未満)が求められる一方で、サイドバーでのチャットやリファクタリングには広大なコンテキストと高度な推論能力を備えたフロンティアモデルが不可欠です。Claude 3.5 Sonnet や GPT-4o のような重量級モデルを Tab 補全に使用すると、入力時のカクつきと膨大な API コストが発生します。逆に、軽量な補完モデルを会話に流用すると、複雑なアーキテクチャ設計やバグ調査に対応できません。
この課題を解決するのが「ロールベースのモデルルーティング」です。Continue は、インラインのリアルタイム補完と探索的な対話推論を疎結合に分離する設計を備えています。本ガイドでは、最新の config.yaml 規格および従来の config.json 環境において Tab 補完モデルとチャットモデルを切り分けて設定し、ローカルおよびクラウドのエンドポイントを最適化する手順を解説します。
アーキテクチャ分離:Tab 補完とチャットの違い
Tab 自動補完とチャット対話は、要求されるパフォーマンス制約とモデル構造が根本から異なります。
| 評価軸 | Tab 自動補完 | チャット対話および編集 (Chat & Edit) |
|---|---|---|
| 最重要指標 | 初回トークン生成速度(TTFT < 300ms)、タイピングの快適性 | 論理的推論の深さ、複数ファイルにまたがる文脈理解力 |
| 呼び出し頻度 | 極めて高頻度(タイピングの一時停止ごとに発生、1時間に数百回) | 中・低頻度(開発者がプロンプトを整えて送信、1日に数十回) |
| モデルアーキテクチャ | Fill-In-The-Middle (FIM) 特化型の軽量モデル (1B–7B) | 密結合大規模モデルまたは MoE フロンティア推論モデル (14B–70B+ / クラウド API) |
| 推奨デプロイ環境 | ローカル推論エンジン (Ollama, vLLM, llama.cpp) または極低遅延クラウド | フロンティアクラウド API (Anthropic, OpenAI, Mistral) または高スペック専用機 |
| コンテキスト構成 | カーソル前後のコード行と AST/LSP 定義 | 会話履歴、複数コードファイル、Agent システムプロンプト |
タスクごとにモデルを分離することで、ローカルモデルによるゼロコストかつプライバシーを保護したミリ秒単位の入力支援を受けつつ、サイドバーでは最高峰モデルの知見を活用できます。
方法1:最新規格(config.yaml)による設定
最新バージョンの Continue では、設定ファイルは ~/.continue/config.yaml に統一されています。各モデルに付与される roles 配列によってタスクのルーティングが制御されます。
設定の基本方針:
- FIM に特化した軽量モデルを定義し、
roles: [autocomplete]を指定する。 - 汎用的なコード理解と対話に適したクラウドモデルを定義し、
roles: [chat, edit]を指定する。
実践的な設定例
name: Continue Hybrid Routing
version: 0.0.1
schema: v1
models:
# 1. Tab 補完専用モデル(ローカル Ollama 経由)
- name: Qwen2.5 Coder 1.5B (Autocomplete)
provider: ollama
model: qwen2.5-coder:1.5b
roles:
- autocomplete
autocompleteOptions:
debounceDelay: 250
maxPromptTokens: 1024
# 2. 高度な推論・リファクタリング用チャットモデル(Anthropic API)
- name: Claude 3.5 Sonnet (Chat & Edit)
provider: anthropic
model: claude-3-5-sonnet-latest
apiKey: YOUR_ANTHROPIC_API_KEY
roles:
- chat
- edit
# 3. 代替クラウドチャットモデル(OpenAI)
- name: GPT-4o (Chat)
provider: openai
model: gpt-4o
apiKey: YOUR_OPENAI_API_KEY
roles:
- chat
主要パラメータの解説
roles:モデルが割り当てられる機能を定義します。autocompleteが含まれるモデルはインラインのゴーストテキスト生成専用となり、サイドバーのチャット切り替えプルダウンには表示されません。chatを指定したモデルがチャットセレクターに配置されます。autocompleteOptions.debounceDelay:キー入力停止から推論を開始するまでの待機時間(ミリ秒)。200ms〜350ms の設定が推奨され、高速タイピング時にローカル GPU へ不要な推論リクエストが殺到するのを防ぎます。autocompleteOptions.maxPromptTokens:補完モデルに送信されるコンテキストトークンの上限。1024〜2048 に絞ることで、マシンスペックに応じた最高速度のトークン生成を維持できます。- 思考プロセスの無効化:Reasoning / Thinking 対応モデル(qwen3 や deepseek-r1 系など)を補完に使用する場合、必ず
extraBodyProperties: { think: false }を追加してください。インライン補完中に思考トークンが出力されると、コードの構文が破壊され激しい遅延が発生します。
方法2:レガシー規格(config.json)による設定
旧バージョンの Continue を運用している環境では、設定は ~/.continue/config.json で行われます。この場合、トップレベルの独立プロパティである tabAutocompleteModel を利用してチャット用モデルと切り離します。
[!NOTE]
config.jsonおよびトップレベルのtabAutocompleteModelキーは非推奨(Deprecated)となっています。移行期間中は互換性が保たれていますが、将来的な更新に向けてconfig.yamlへの移行が推奨されます。
レガシー設定例
{
"models": [
{
"title": "Claude 3.5 Sonnet",
"provider": "anthropic",
"model": "claude-3-5-sonnet-latest",
"apiKey": "YOUR_ANTHROPIC_API_KEY"
},
{
"title": "GPT-4o",
"provider": "openai",
"model": "gpt-4o",
"apiKey": "YOUR_OPENAI_API_KEY"
}
],
"tabAutocompleteModel": {
"title": "Qwen2.5-Coder 1.5B",
"provider": "ollama",
"model": "qwen2.5-coder:1.5b"
},
"tabAutocompleteOptions": {
"debounceDelay": 250,
"maxPromptTokens": 1024
}
}
この構成では:
"models"配列内のモデルがチャット UI のセレクターに表示されます。"tabAutocompleteModel"オブジェクトがインライン補完専用として独立して動作します。- 補完オプションは
"tabAutocompleteOptions"に記述します。
シナリオ別推奨モデル構成
ハードウェアスペック、プライバシー要件、予算に応じたおすすめの組み合わせを紹介します。
シナリオ A:ローカルとクラウドのハイブリッド構成(推奨・標準構成)
- Tab 補完:ローカル Ollama による
qwen2.5-coder:1.5bまたはqwen2.5-coder:7b。レイテンシ 150ms 未満、API 費用ゼロで動作。 - チャット:Anthropic
claude-3-5-sonnetまたは OpenAIgpt-4o。高品質なコード生成と深い文脈把握を実現。
シナリオ B:完全オフライン・高プライバシー構成
- Tab 補完:ローカルの Ollama / vLLM による
qwen2.5-coder:1.5b(Q4 または Q8 量子化)。 - チャット:ローカル配置の
qwen2.5-coder:32bまたはdeepseek-coder-v2:16b。16GB〜32GB 以上のメモリまたは VRAM を搭載したマシン向け。
シナリオ C:高精度クラウド専用補完構成
- Tab 補完:Mistral API 経由の
codestral-latest。80 以上のプログラミング言語に対応し、FIM をネイティブサポートした高性能補完モデル。 - チャット:OpenAI
gpt-4oまたは Claude 3.5 Sonnet。
エンドポイント最適化とトラブルシューティング
モデルのルーティング設定だけでなく、実行基盤となる推論エンジンの調整も重要です。
1. Ollama の並行処理とメモリ常駐設定
ローカル環境で補完とチャットの両方を動作させる場合、Ollama のデフォルト挙動によりリクエストが直列化(キューイング)されることがあります。
- 環境変数に
OLLAMA_NUM_PARALLEL=2以上を設定し、チャットの応答生成中にも Tab 補完リクエストを同時に処理できるようにします。 - 環境変数に
OLLAMA_KEEP_ALIVE=24hを指定します。デフォルトの 5 分間でモデルが VRAM から解放されるのを防ぎ、作業再開時のコールドスタートによる 5〜10 秒のフリーズを回避します。
2. デバウンス時間とコンテキスト長のチューニング
- タイピングが速い開発者(80+ WPM):
debounceDelayを 300ms〜350ms に引き上げ、打鍵途中の無駄なリクエスト破棄を防ぎます。 - 慎重にコーディングを行う場合:200ms〜250ms に設定します。
maxPromptTokensは 1024〜2048 に留めます。過大なプレフィックス計算は軽量モデルの TTFT を無駄に悪化させます。
3. エディタ内での競合回避
設定後にインライン候補が表示されない場合:
- Continue の設定で Enable Tab Autocomplete が有効になっているか確認します。
- GitHub Copilot、Supermaven、または VS Code 組み込みの補完機能など、競合する他のインライン補完拡張機能を一時的に無効化してください。複数の補完エンジンが同時に稼働すると競合が発生し、Continue のゴーストテキストが抑制されることがあります。
動作確認
設定完了後、IDE 上で次の手順で動作を検証します。
- Continue パネルを開き(
Ctrl+L/Cmd+L)、画面下部のモデルセレクターに指定した Chat モデル(Claude 3.5 Sonnet など)のみが表示されていることを確認します。 - 任意のコードファイルで関数シグネチャを入力し、約 300 ミリ秒停止します。薄い灰色のゴーストテキストが即座に出現し、ローカルの Ollama 側で補完リクエストが処理されていることを確認できれば設定は成功です。
参考文献
- Autocomplete Role in Continue Models | Continue Docs
- Chat Role | Continue Docs
- Continue Autocomplete Setup and Configuration Guide | Continue Docs
- How to Understand Configuration | Continue Docs
- Migrating Config to YAML | Continue Docs
- config.json Reference (Deprecated) | Continue Docs
- Using Ollama with Continue: A Developer's Guide | Continue Docs