広告枠を募集中 ご相談ください

ContinueでTabコード補完とチャットを別々の専用モデルにルーティングする方法

365Finds Editorial
Wiki 記事 11,430 本収録

あなたの AI で 365 Wiki を使う

下のプロンプトをコピーして、普段使っている AI に貼り付け、そのまま質問してください。

完全版 Skill をダウンロード

まずはプロンプトでお試しください。よく使う場合は完全版 365Wiki Skill をインストールすると、毎回貼り付ける必要がありません。普段使う AI がなければ、Gemini や Microsoft Copilot のウェブ版でも使えます。

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 配列によってタスクのルーティングが制御されます。

設定の基本方針:

  1. FIM に特化した軽量モデルを定義し、roles: [autocomplete] を指定する。
  2. 汎用的なコード理解と対話に適したクラウドモデルを定義し、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

主要パラメータの解説


方法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
  }
}

この構成では:


シナリオ別推奨モデル構成

ハードウェアスペック、プライバシー要件、予算に応じたおすすめの組み合わせを紹介します。

シナリオ A:ローカルとクラウドのハイブリッド構成(推奨・標準構成)

シナリオ B:完全オフライン・高プライバシー構成

シナリオ C:高精度クラウド専用補完構成


エンドポイント最適化とトラブルシューティング

モデルのルーティング設定だけでなく、実行基盤となる推論エンジンの調整も重要です。

1. Ollama の並行処理とメモリ常駐設定

ローカル環境で補完とチャットの両方を動作させる場合、Ollama のデフォルト挙動によりリクエストが直列化(キューイング)されることがあります。

2. デバウンス時間とコンテキスト長のチューニング

3. エディタ内での競合回避

設定後にインライン候補が表示されない場合:


動作確認

設定完了後、IDE 上で次の手順で動作を検証します。

  1. Continue パネルを開き(Ctrl+L / Cmd+L)、画面下部のモデルセレクターに指定した Chat モデル(Claude 3.5 Sonnet など)のみが表示されていることを確認します。
  2. 任意のコードファイルで関数シグネチャを入力し、約 300 ミリ秒停止します。薄い灰色のゴーストテキストが即座に出現し、ローカルの Ollama 側で補完リクエストが処理されていることを確認できれば設定は成功です。

参考文献