CursorにDeepSeek V4-ProをデフォルトのOpenAI互換設定で接続すると、最初のツール呼び出しで400エラーが返されます。理由は小さいながらも厄介です。V4-Proは`reasoning_content`ブロックを返す思考モデルですが、Cursorはそのフィールドを後続のリクエストから削除し、DeepSeekのAPIは推論チェーンを削除したツール呼び出しメッセージを拒否するためです。yxlao/deepseek-cursor-proxyにあるオープンソースのプロキシは、reasoning contentをキャッシュし、外部へのリクエスト時に再注入します。プロキシが実行されると、V4-ProはCursorのカスタムモデルパネルで他のモデルと同様に動作し、思考トークンは折りたたみ可能なマークダウンとしてレンダリングされます。以下に、完全なセットアップ、コスト計算、およびトラブルシューティングのリストを示します。
要約
- CursorとDeepSeek V4-Proを組み合わせると、V4-Proが思考モデルであり、Cursorがツール呼び出しメッセージから
reasoning_contentを削除するため、デフォルトで400エラーが返されます。 deepseek-cursor-proxy（オープンソース、Python製）はCursorとDeepSeekの間に位置し、各会話のreasoning_contentをキャッシュし、ツール呼び出しが失敗しないように再注入します。- セットアップ：
uvまたはpipでインストールし、deepseek-cursor-proxyを実行し、ngrok URLとDeepSeek APIキーをCursorのカスタムモデル設定に貼り付けます。 - Cursor内でV4-Proを使用する場合、出力トークン100万あたり約$0.87で、GPT-5.5の出力と比較して約34倍安価です。詳しい料金については、DeepSeek V4-Pro 75% Price Cut Is Now Permanentを参照してください。
そもそもプロキシが必要な理由
V4-Proは、すべての応答で2つのものを返します。通常の`content`フィールドと、思考の連鎖を含む`reasoning_content`フィールドです。通常のチャットでは`reasoning_content`は無視できます。問題はツール呼び出しから始まります。
思考モデルに対するDeepSeekのAPI契約では、`reasoning_content`ブロックを含む会話を続ける場合、次のリクエストに`tool_calls`の結果とともにそのブロックを含める必要があります。推論チェーンは会話の状態の一部です。Cursorはこの要件を認識していません。OpenAIスタイルのチャットクライアントを出荷しており、`reasoning_content`はOpenAIスキーマの一部ではないため、そのフィールドを削除します。その結果、次のツール呼び出しはHTTP 400エラーと`reasoning_content`が見つからないというメッセージを返します。
これは厳密にはCursorのバグではありません。APIサーフェスの大部分を共有する2つのプロバイダー間の契約不一致です。CursorがV4-Proのファーストクラスサポートを追加するか、DeepSeekが契約を緩和するまで、この回避策はCursorが忘れたものを記憶するプロキシです。
プロキシの機能（3行で）
- ローカルポート（デフォルト9000番）でCursorからの送信チャットリクエストをリッスンします。
- すべてのV4-Pro応答から
reasoning_contentをキャッシュし、正規化された会話プレフィックスのSHA-256でキー付けします。 - 新しいリクエストごとに、一致するプレフィックスのキャッシュされたreasoning_contentを検索し、DeepSeekに転送する前にメッセージに追加します。
また、Cursorのカスタムモデル設定はHTTPSを要求し、`localhost` URLを受け付けないため、ngrokトンネルを介してローカルポートを公開します。
キャッシュは~/.deepseek-cursor-proxy/reasoning_content.sqlite3に格納されます。SHA-256キーイングにより、2つの並行する会話が衝突することはありません。推論コンテンツはDeepSeekが返したとおりに正確に保存されるため、DeepSeek自身のプロンプトキャッシュは引き続き機能し、これは新しい恒久的な料金設定にとって重要です。
前提条件
開始する前に、次の4つの要素が必要です。
- Cursor 2.0以降。カスタムモデルUIは3.xでも同じで、どちらでも動作します。
- DeepSeek APIキー。お持ちでない場合はplatform.deepseek.comでサインアップしてください。少額の残高で十分です。料金の詳細は以下にあります。
- Python 3.11以降。プロキシは純粋なPythonです。
uvが推奨されますが、pipでも動作します。 - 認証トークンを持つngrokアカウント。無料ティアはソロ開発者には十分です。静的ドメインはオプションですが、プロキシを頻繁に再起動する場合に便利です。
uvをインストールしたことがない場合は、公式のuvインストールドキュメントを参照してください。ngrokについては、ngrokクイックスタートで認証トークンの設定手順が説明されています。
ステップ1：プロキシのインストール
最速のパスはuvです。どのディレクトリからでも：
uv tool install deepseek-cursor-proxy
pipをご希望の場合は、リポジトリをクローンして編集可能なパッケージとしてインストールしてください：
git clone https://github.com/yxlao/deepseek-cursor-proxy.git
cd deepseek-cursor-proxy
pip install -e .
どちらのパスでも、deepseek-cursor-proxyコマンドがPATHに追加されます。deepseek-cursor-proxy --helpで確認してください。
ステップ2：ngrokの設定
Cursorのカスタムモデルフィールドはhttp://localhostを受け付けないため、プロキシには公開HTTPS URLが必要です。ngrokがトンネルを提供します。
ngrok config add-authtoken YOUR_NGROK_AUTHTOKEN
サインアップ後、ngrokダッシュボードから認証トークンを取得してください。無料ティアでは、再起動ごとにランダムなサブドメインが提供されます。これが問題となる場合は、ダッシュボードで予約済みドメインを申請し、--ngrok-url https://your-reserved.ngrok-free.appでプロキシに渡してください。
ステップ3：プロキシの起動
ほとんどのセットアップでは、デフォルトで問題ありません。
deepseek-cursor-proxy
初回実行時に、プロキシは~/.deepseek-cursor-proxy/config.yamlを作成し、トンネルを開き、公開URLを出力します。出力は次のようになります。
Starting deepseek-cursor-proxy
Tunnel: https://random-name.ngrok-free.app
Local: http://127.0.0.1:9000
Cache: /Users/you/.deepseek-cursor-proxy/reasoning_content.sqlite3
便利なフラグ:
--port 9000：9000番ポートが使用中の場合は、ローカルポートを変更します。--verbose：リクエストとレスポンスの本文を出力します。Cursorとの統合をデバッグする際にこれを使用します。--no-ngrok：トンネルをスキップします。http://localhostを受け入れるツールからテストする場合に便利です。--no-display-reasoning：Cursorの表示から折りたたみ可能な思考ブロックを削除します。推論自体は引き続き流れますが、レンダリングのみが抑制されます。
プロキシを別のターミナルで実行し続けるか、macOSではlaunchctlジョブでラップしてください。Cursorはすべてのリクエストでプロキシと通信します。
ステップ4：Cursorの設定
Cursorの設定を開き、「モデル」に移動してカスタムモデルを追加します。必要なフィールドは次のとおりです。
- モデル名:
deepseek-v4-pro。プロキシはこの文字列をDeepSeekに直接転送するため、実際のDeepSeekモデル識別子と一致している必要があります。より安価なバリアントにはdeepseek-v4-flashを使用してください。 - ベースURL: プロキシが出力したngrok URLに
/v1を追加したもの。例：https://random-name.ngrok-free.app/v1。 - APIキー: あなたのDeepSeek APIキー（
sk-で始まる）。プロキシ自体には認証レイヤーがないため、キーはそのまま転送されます。
Cursorは「モデルを検証」チェックを実行します。このチェックは単一のチャット補完を送信します。緑色のチェックマークが表示されれば完了です。接続エラーは通常、ngrok URLに問題があることを示します。プロキシの出力から再度コピーし、/v1で終わっていることを確認してください。
ステップ5：モデルを選択し、ツール呼び出しを試す
チャットパネルでモデルピッカーを開き、新しいカスタムモデルを選択します。最初に試すべきプロンプトは、ツール使用を強制するものです。なぜなら、元の400エラーはツール呼び出しで発生していたからです。
「このリポジトリのREADMEを開き、すべてのコードブロックをリストアップし、どのブロックに言語ヒントが欠けているか教えてください。」
Cursorはread_fileツール呼び出しを発行します。プロキシが正しく機能していれば、応答チェーンは次のようになります。
- Cursorはユーザーメッセージをプロキシに送信します。
- プロキシはDeepSeekに
reasoning_contentなしで転送します（最初のターンであるため）。 - DeepSeekはテキストに加えて
reasoning_contentブロックとtool_callsリクエストを返します。 - プロキシは会話プレフィックスのハッシュをキーとして
reasoning_contentをキャッシュします。 - Cursorはツールを実行し、ツール結果を含むフォローアップを送信します。このフォローアップには、Cursorが削除したため
reasoning_contentが含まれていません。 - プロキシはプレフィックスハッシュでキャッシュされたreasoning_contentを検索し、転送する前に再注入します。
- DeepSeekはリクエストを受け入れ、推論を続け、最終的な回答を返します。
--verboseで実行すると、ログに注入の様子が表示されます。
実際のコストはどうなるか
Cursor内でV4-Proを使用する場合、Cursorのバンドルクレジット料金ではなく、DeepSeekの標準API料金が適用されます。これらの料金は2026年5月現在恒久的なものです。
| トークンタイプ | 100万トークンあたりの料金 |
|---|---|
| 入力 (キャッシュミス) | $0.435 |
| 入力 (キャッシュヒット) | $0.003625 |
| 出力 | $0.87 |
Cursorをヘビーに利用する日は、約50回のチャットターンと20回のツール呼び出しチェーンに相当します。各ターンは平均して8,000プロンプトトークン（ファイルコンテキスト＋システムプロンプト＋履歴）と1,500出力トークンです。これは次のようになります。
- 50ターン × 8,000入力 × $0.435 / 1,000,000 = 最悪の場合$1.74
- 6,000トークンのシステムとコンテキストプレフィックスでキャッシュヒット率60%の場合：約$0.85
- 50 × 1,500 × $0.87 / 1,000,000 = $0.065 出力
合計で、ヘビーな利用日で約1ドルです。Cursor ProのバンドルされているGPT-5.5のクォータを通じて同じワークロードを実行する場合と比較して、クォータスロットリングが始まる前であれば、桁違いに安価です。料金値下げの詳細は、DeepSeek V4-Pro 75% Price Cut Is Now Permanentに記載されています。
DeepSeekの他のラインナップについては、What is DeepSeek V4およびHow to use the DeepSeek V4 APIを参照してください。
Cursor内でのV4-Proの感触
デフォルトのCursorモデルとの違いが3点あります。
- 1. 思考トークンが見える。デフォルトでは、プロキシはDeepSeekの推論を各応答の上にある折りたたみ可能なマークダウンブロックとしてレンダリングします。Cursorのチャットパネルはそれを
<details>要素として表示します。プロンプトのデバッグには役立ちますが、日常業務では煩雑です。--no-display-reasoningで切り替えることができます。 - 2. 最初のツール呼び出しのレイテンシーが高い。V4-Proは思考モデルであり、ツールの呼び出し前に思考チェーンが実行されます。最初のツールが発動するまでに2〜4秒かかり、その後は標準のスループットで後続の処理が行われると予想されます。
- 3. Cursorの「適用」提案が複雑なリファクタリングで改善される。これが最も重要な点です。V4-Proの推論チェーンは、フラットな補完モデルでは見落とされがちな複数ファイルの依存関係を捉えます。GPT-5.5で3回の手順が必要だった名前変更、シグネチャ変更、設定駆動型のリファクタリングが、V4-Proでは1回のパスで完了することがよくあります。
以前のモデル向けに、DeepSeekとCursorの連携に関する他のチュートリアルも存在します。How to use DeepSeek R1 locally with CursorおよびDeepSeek V3 with Cursor: step-by-stepで古いパターンを参照してください。このガイドのプロキシは、これらの記事で文書化されている手動の推論注入ハックを置き換えるものです。
ApidogでDeepSeekのセットアップをテストする
Cursorとの統合は、Cursor内部からのパスを証明するに過ぎません。V4-Proを他のインターフェース（CIボット、バックエンドエージェント、カスタムIDEプラグインなど）に展開する場合、プロキシが転送しているのと同じエンドポイントに対して決定論的なテストハーネスが必要です。
そこにApidogの出番があります。Apidog環境をhttps://api.deepseek.com/v1に向け、APIキーを投入し、OpenAI Chat Completionスキーマをインポートします。次のことができます。
- V4-Proからのゴールデンレスポンスを記録し、プロンプト変更のたびにリプレイして、予期せぬ挙動の変化を検知します。
- JSONスキーマアサーションで
tool_callsの形状を検証し、誤ったシステムプロンプトの編集によって本番環境のエージェントが静かに停止するのを防ぎます。 - Apidogのテストシナリオを使用して、同じ入力バッチでV4-ProとGPT-5.5を並べて比較します。
Apidogをダウンロードし、DeepSeek OpenAPI仕様をインポートすれば、5分で動作するV4-Proテストベンチが手に入ります。How to use the DeepSeek V4 APIで説明しているのと同じワークフローです。
よくある落とし穴
- 最初のツール呼び出し後の400エラー。このプロキシが修正するために作られた典型的な失敗モードです。セットアップ後も発生する場合は、プロキシが実行されていないか、Cursorが間違ったベースURLを指しています。URLが
/v1で終わっていること、およびプロキシのログに受信リクエストが表示されていることを再確認してください。 - ngrokトンネルが再接続を繰り返す。無料ティアのトンネルは再起動時に変更されます。Cursorの検証はパスするものの、数分後に失敗する場合は、トンネルが入れ替わっています。予約済みドメインに移行し（ngrokダッシュボードでワンクリック）、
--ngrok-urlでそれを渡してください。 - 推論コンテンツが重複して表示される。これは、2つのプロキシインスタンスが同じSQLiteキャッシュパスで実行されている場合に発生します。両方を停止し、
~/.deepseek-cursor-proxy/reasoning_content.sqlite3を削除してから、1つのインスタンスを起動してください。 - キャッシュヒット率が低い。DeepSeekのプロンプトキャッシュは、バイト単位で同一のプレフィックスを必要とします。Cursorは一部のシステムプロンプトにタイムスタンプやセッションIDを挿入するため、キャッシュヒットが失われます。この修正はプロキシ内部ではできません。コストを受け入れるか、V4-ProセッションでCursorの「システムプロンプトなし」モードを使用してください。
- Cursorが「モデルが見つかりません」と報告する。Cursorの設定にあるモデル名は、実際のDeepSeekモデルと一致している必要があります。現在有効な値は、
deepseek-v4-pro、deepseek-v4-flash、deepseek-v3-2-pro、およびdeepseek-r1-1です。プロキシは名前を翻訳せず、そのまま転送します。
プロキシが適切でない場合の代替策
現在、プロキシが最もクリーンな方法ですが、2つの代替案があります。
- プロキシなしのV4-Flash。V4-Flashは思考モデルではなく、`reasoning_content`を返しません。Cursorは回避策なしで直接これと通信します。思考の連鎖によるブーストは諦めることになりますが、統合はシンプルになります。料金は100万トークンあたり$0.14 / $0.28です。
- Cline、Continue、またはネイティブで思考モデルをサポートするその他のAI IDEプラグイン。これらのツールは、ツール呼び出しメッセージの`reasoning_content`をネイティブで処理します。Cursorに特にこだわるのでなければ、エディタを切り替える方がプロキシを実行するよりも簡単な場合があります。その分野については、2026年の最高のオープンソースコーディングアシスタント：無料のCursor代替品を参照してください。
その他のCursorモデル統合の詳細については、Claude Opus 4.6 with Cursor、Kimi K2.5 with Cursor、およびGemini 3.0 Pro with Cursorを参照してください。
よくある質問
- なぜCursorはDeepSeek V4-Proをネイティブでサポートしないのですか？ CursorのチャットクライアントはOpenAI Chat Completionsスキーマに準拠しています。`reasoning_content`はそのスキーマの一部ではありません。これはR1ファミリーで登場し、V4-Proにも引き継がれたDeepSeek固有の拡張機能です。Cursorは、このフィールドを通過させるためにプロバイダー固有の処理を追加する必要があります。将来追加されるかもしれませんが、それまではプロキシが回避策となります。
- プロキシはDeepSeek R1またはV3.2で動作しますか？ はい、動作します。`reasoning_content`を返し、ツール呼び出し後のフォローアップでそれを必要とするDeepSeekの思考モデルはすべてサポートされています。Cursorの設定でモデル名を実際のDeepSeekモデル識別子に設定してください。
- プロキシを常時実行しても安全ですか？ はい、ただし1つ注意点があります。SQLiteキャッシュにはセッションからの生の推論コンテンツが含まれています。マルチユーザー設定で運用している場合や、マシンを共有している場合は、キャッシュディレクトリのパーミッションを制限するか、
--no-cache（メモリ内のみ。この場合、プロキシの再起動後にツール呼び出しが失敗します）で実行してください。 - ngrokなしでプロキシを使用できますか？ はい、
--no-ngrokを使用すれば可能です。その場合、プロキシはhttp://127.0.0.1:9000のみを公開します。CursorのカスタムモデルUIは標準リリースではhttp://URLを拒否しますが、一部のサイドロードされたビルドやパッチが適用された設定ではlocalhostを受け入れます。ほとんどのユーザーはngrokまたは同等のもの（Cloudflare Tunnel、Tailscale Funnel）を望むでしょう。 - これはCursor Composer 2.5で動作しますか？ Composerはチャットパネルと同じモデルルーティングパイプラインを使用するため、はい、動作します。Composerエージェント内の最初のツール呼び出しは、同じ`reasoning_content`要件に引っかかり、プロキシが同じ方法でそれを修正します。
- プロキシのレイテンシーオーバーヘッドはどれくらいですか？ 無視できるレベルです。プロキシは、リクエストごとに1回のローカルネットワークホップ、1回のSQLiteルックアップ、数KBのJSON操作を追加します。測定されたオーバーヘッドは1呼び出しあたり5〜15ミリ秒です。ngrokは、最寄りのエッジに応じて30〜80ミリ秒を追加します。プロキシはボトルネックではありません。
- プロキシはどのようにキャッシュする内容を決定しますか？ 会話のプレフィックス（最新のユーザーメッセージまたはツールメッセージの前のすべて）をハッシュ化し、そのハッシュのSHA-256を、DeepSeekの最後の応答からの`reasoning_content`のキーとして設定し、両方をSQLiteに保存します。次のリクエストでは、新しいプレフィックスのハッシュを計算し、一致するエントリを検索します。これは慎重な方法です。部分的なプレフィックスの一致ではキャッシュヒットは発生しないため、ほとんど同じ2つの会話が互いに汚染することはありません。
- Anthropic、OpenAI、またはCursorはこれを壊す可能性がありますか？ AnthropicとOpenAIは関係ありません。Cursorは、ネイティブな思考モデルのサポートを追加するか（その場合プロキシは不要になります）、リクエスト形式を変更してプロキシを壊す可能性があります。リポジトリはメンテナンスされており、互換性更新についてはそのイシューを監視してください。
結論
V4-Proのコーディング能力は、GPT-5.5とベンチマークで数ポイント差の範囲内 (DataCamp比較) であり、出力価格は約34分の1です。Cursorユーザーにとって唯一の障壁は、`reasoning_content`に関するAPI契約の不一致でした。deepseek-cursor-proxyリポジトリは、100行未満の有益なコードと5分間のセットアップでこの問題を解決します。
3つの具体的な次のステップ：
- プロキシをインストールし、リポジトリからの5つの実際のプルリクエストに対して、現在のCursorのデフォルトとサイドバイサイドでテストを実行してください。
- キャッシュヒットを妨げる可変コンテンツ（タイムスタンプ、セッションID）がないか、Cursorのシステムプロンプトを監査してください。そのコンテンツはユーザーメッセージに移動してください。
api.deepseek.comに対してApidog回帰テストスイートを設定し、Cursor経由で毎回再テストすることなく契約のズレを検知できるようにします。
思考トークンによる負担は解消されました。高額な料金はもはやありません。