Cursor、Cline、Roo Code で外部モデルを使う：設定マトリクス

先に結論

3 つとも接続できます。違いは 3 点です：

一言で分けると：Cursor は IDE 内蔵の AI、Cline / Roo Code はプラグイン形態の agent。前者はエディタをあなたと奪い合い、後者はあなたのエディタの中で作業を手伝います。

設定マトリクス

3 つのツールで入力する値は同じセットです：

• Base URL：https://api.kimiseek.app/v1
• API Key：ks- で始まる key
• Model ID：catalog の完全な id（例：deepseek-v4-pro-0813）

Base URL に /v1 を付ける点に注意してください。この 3 つのツールはいずれも自分で /chat/completions を連結します。

Cursor

1. 設定を開き、Models パネルに移動します。
2. OpenAI API Key を入力し、Override OpenAI Base URL を有効にして https://api.kimiseek.app/v1 を入力します。
3. Base URL の上書きを有効にすると、Cursor はカスタムモデルを OpenAI 互換モデルとして扱うため、モデル名を手動で追加する必要があります。
4. 保存後に新しい会話を開き、「あなたは何のモデルですか」と聞いて経路を確認します。

Cursor の落とし穴はモデル名です。内部にモデル一覧を持っており、リストにない名前は入力できても効かないことがあります。「保存はできるのに質問に反応しない」場合は、まず標準的な命名の id に変えて試してください。

Cline

1. Cline パネルの Settings を開きます。
2. API Provider で OpenAI Compatible を選びます。
3. Base URL に https://api.kimiseek.app/v1、API Key に ks- で始まる key を入力します。
4. Model ID に deepseek-v4-pro-0813 を入力します。
5. 保存後にメッセージを 1 通送って確認します。

Cline の落とし穴は context 長です。モデル名から context window を推測し、推測できないときは保守的な値（多くは 128K、ひどいと 64K）を割り当てます。その結果、1M の context があるのにクライアント側で早々に打ち切られます。コミュニティにもこの件を扱った issue があります。「タスクの途中で context 不足と言われた」ら、まず設定で手動で大きくしてください。モデルを疑う必要はありません。

Roo Code

Roo Code は Cline のフォークで、手順はほぼ同じです：

1. API Provider で OpenAI Compatible を選びます。
2. Base URL、API Key、Model ID は Cline と同じです。
3. モデル設定で context window と最大出力 tokens を手動で設定します。

Roo Code で増えるのはモード設定（Code / Architect / Ask など）で、モードごとに別のモデルを指定できます。コストを抑えたいなら、軽量なモードを deepseek-v4.1-flash に向けてください。

避けられない 2 つの問題

context window がクライアント側で固定される

3 つのツールに共通する問題で、症状は「モデルは 1M まで対応しているのに、クライアントが 128K で打ち切る」です。

原因：クライアントは履歴をいつ圧縮するかを決めるために context 長を知る必要があります。多くのクライアントはモデル名で内蔵テーブルを引き、一致しないと保守的な既定値を使います。

対処：手動で指定する。Cline と Roo Code は設定で変更できます。Cursor はモデル名からの推測なので、context の表示がより大きいモデル名を選んでから上書きするのが現実的な回避策です。

tool call 形式の非互換

agent は tool call で作業します。ファイルを読み、書き、コマンドを実行する。モデルごとに tool call の形式には細かな差があり、ゲートウェイが正規化を担います。

症状はエラーではなく、「モデルはファイルを直すと言うが、違うファイルを直す」「同じファイルを何度も読む」という形で現れます。こうなったら、まずネイティブなプロトコル経路を使っているかを確認し、次に別のモデルを試してください。モデルごとに tool call の品質差は大きく、reasoning 型モデルのほうが一般に安定します。

検証チェックリスト

設定が終わったら順に確認します：

1. 普通の質問を送って返答がある → 認証とネットワークが通っている。
2. ファイルを 1 つ読ませる → tool call が通っている。
3. ファイルを 1 つ修正させる → 書き込み権限と diff が通っている。
4. テストコマンドを 1 つ実行させる → 実行チェーンが通っている。

どこかで失敗したら、エラー対照表 を参照してください。

ツールを乗り換えるべきとき

• 補完と単一ファイルの変更だけで足りる → Cursor で十分、軽い。
• 複数ファイルのリファクタリングやテストのクローズドループが必要 → Cline / Roo Code が適切。もともと多段タスク向けに設計されています。
• ターミナルで長いタスクを回したい → Claude Code か Codex を使う。

対応バージョンと検証

• Cursor 1.x、Cline 3.x、Roo Code 3.x
• 検証日：2026-10-26
• 事実の出典：3 ツールの公式設定ドキュメントと実際の UI フィールド。context 固定の問題はコミュニティの issue 議論を参照