WindsurfAPI レビュー：Windsurf のモデルを OpenAI / Anthropic / Gemini 互換 API に変換するリバースプロキシ
Turn Windsurf / Devin Desktop's 100+ AI models (Claude, GPT, Gemini, DeepSeek, Kimi, GLM, SWE) into OpenAI-, Anthropic- & Gemini-compatible APIs. Zero-dependency self-hosted reverse proxy for Claude Code, Cline & Cursor. 把 Windsurf/Devin 云端 100+ 模型变成三套兼容 API。
ひと目でわかる
- これは何？
- Windsurf（旧 Codeium、現 Devin Desktop）のクラウドモデルを 3 系統の標準 API として自前ホストで公開する、npm 依存ゼロの Node.js 製プロキシ。仕組みと制約、向く用途と向かない用途を整理する。
- 誰に向いている？
- Windsurf のアカウントをすでに持っていて、Claude Code や Cline、Cursor から既存のサブスクリプション経由でモデルを呼びたい個人開発者には向く。逆に、API キーを配って第三者にサービスとして提供する用途や、SLA とサポート契約が必要な業務システムには向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に JavaScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Windsurf のモデルを、手持ちのクライアントから使うための変換層
Windsurf や Devin Desktop のモデルは、そのままでは OpenAI SDK や Claude Code からは呼べない。プロトコルが違うからだ。WindsurfAPI はこの差分を埋める。HTTP サーバーとして立ち上げ、OpenAI 互換の /v1/chat/completions と /v1/completions、/v1/responses、Anthropic 互換の /v1/messages、Gemini 互換の /v1beta/models/* を同じプロセスから公開する。README の説明では、対象は Claude、GPT、Gemini、DeepSeek、Kimi、GLM、SWE など 100 以上のモデルとされている。
想定読者は、Windsurf のアカウントをすでに持っている個人開発者や小規模チームである。新しい API キーを別途契約するのではなく、手元の環境でモデルを呼び出す経路を一本化したい、という動機が README の書きぶりから読み取れる。汎用のゲートウェイ製品ではなく、特定の上流サービスに強く依存した変換アダプタだと考えるのが正確だ。
リクエストは Language Server を経由して gRPC で上流へ抜ける
アーキテクチャは README の図で明示されている。クライアントから届いた HTTP リクエストは、まずプロトコル翻訳層で Windsurf 内部の gRPC 形式に変換される。次にローカルで動く Language Server（Windsurf のバイナリ）へ gRPC で渡り、そこから HTTPS で Windsurf クラウドの server.self-serve.windsurf.com に到達する。DEVIN_CONNECT の経路を使う場合は Devin クラウドへ直接 HTTPS で送る構成も図には描かれている。
翻訳層の隣にアカウントプールがある。複数のアカウントを輪番で使い、レート制限をアカウント単位で分離し、失敗時は別のアカウントへ回し、一定条件で遮断する。README はこれを「輪詢 · 限流隔离 · 故障转移 · 熔断」と表現している。もう一つの層が身份中和で、応答を返す前に上流の Windsurf 由来の識別情報を剥がす。README の例では、モデルが「自分は Anthropic が開発した Claude Opus 4.6 だ」と名乗る状態にすると説明されている。
ここで押さえておきたいのは、モデル自身はファイルを操作しないという点だ。README は、ファイル操作は Claude Code や Cline といったクライアント側のエージェントがローカルで実行すると明記している。プロキシが返すのは tool_use を含む Anthropic SSE であり、実際の edit_file はクライアントのマシンで走る。
起動と接続：ポート 3003 と環境変数スイッチ
README が示す構成では、サービスはポート 3003 で待ち受ける。クライアント側の設定は、既存 SDK の base URL をこのポートに向けるだけで済む形になっている。Anthropic 互換を使うなら Claude Code や Cline、Cursor の接続先を /v1/messages に、Gemini SDK なら /v1beta/models/* に、OpenAI SDK なら /v1/chat/completions に向ける。
設定の入口は環境変数で、README は docs/ENV-SWITCHES.md を参照先として挙げている。アカウントプールやレート制限分離、故障转移の挙動はこのファイルのスイッチで調整する想定だと読める。ただし、この記事の元資料には個々の変数名や既定値までは含まれていない。どの名前の変数に何を入れるかは、リポジトリの docs/ENV-SWITCHES.md 本体で確認する必要がある。ここを推測で埋めるのは避ける。
もう一点、/v1/completions は非ストリーミングのみで、prompt は 1 つの user turn として包まれる。ストリーミングが必要なら chat 側を使う、という切り分けが README に書かれている。/v1/responses には GET と DELETE で保存済みレスポンスを読み書きする経路もあり、こちらは身份 header が必要と注記されている。
Language Server への依存という構造的な制約
このプロジェクトの弱点は、上流の実装に密結合している点に集約される。リクエストは最終的に Windsurf の Language Server バイナリを経由する。つまり、そのバイナリの入手と配置が前提になり、上流がプロトコルやバイナリを変えれば追従が必要になる。README 自身が「Windsurf 逆向」「Codeium 逆向」というキーワードを掲げており、公式に保証された連携経路ではないことを示唆している。
可用性も上流次第だ。Windsurf 側の仕様変更、アカウント側の制限、認証フローの変更は、このプロキシの外側で起きる。アカウントプールと故障转移はそうした揺らぎを緩和する仕組みではあるが、上流が経路そのものを塞げば回避できない。
向かない用途も明確だ。API キーを配布して第三者に提供する、いわゆる中継サービスとしての運用は、README 冒頭の作者の声明で名指しで禁じられている。可用性やサポートの保証が必要な業務システムにも適さない。単一の Language Server とアカウント群に依存する構成は、その前提を引き受ける利用者だけが使うべきものだ。
LiteLLM との違い：汎用ゲートウェイか、単一上流の変換アダプタか
比較対象として自然なのは LiteLLM のような汎用のプロキシだ。LiteLLM は複数のプロバイダの API キーを設定ファイルに並べ、モデル名でルーティングし、コスト集計やフォールバックを一箇所で扱う。上流はあくまで各社の公式 API であり、認証も公式の仕組みに乗る。
WindsurfAPI は方向が逆である。上流は Windsurf クラウド 1 系統に固定され、その内部 gRPC を叩くために Language Server を介在させる。複数プロバイダを束ねるのではなく、1 つのプロバイダを複数の API 形式に見せかける。だから設定の中心はプロバイダの API キーではなく、アカウントプールとレート制限分離になる。既存の Windsurf 契約を活かしたいなら WindsurfAPI、複数の公式 API を横断しコストを可視化したいなら LiteLLM 側が素直だ。両者は競合というより、解いている問題が違う。
MIT ライセンスと、README 冒頭の作者声明という二層構造
コード本体は MIT License で公開されている。通常の MIT であれば、商用利用、改変、再配布、私的利用が許され、著作権表示と許諾表示を残すことが条件になる。
ただし README の冒頭には、これとは別に作者個人の態度が書かれている。Star と Follow を付けていない利用者に対しては、商業使用、転售、代行デプロイ、バックグラウンドでの対外提供、中継サービスとしての包装販売を禁じる、というものだ。Star と Follow を付けた利用者には「随便用」と緩める、という書き方になっている。README 自身が「上面这段是作者个人态度」と注記しており、ライセンス条項そのものではない。
ここは法的な判断をする場ではないが、実務上の論点として整理しておく価値はある。MIT の許諾表示と、作者が別途表明した利用条件が同じリポジトリに同居している状態は、採用時に社内の法務やコンプライアンスへ説明が必要になり得る。商用利用を検討するなら、この二層構造をどう解釈するかを先に決めておきたい。
メンテナンス頻度と、追従コストの見積もり
リポジトリの更新は活発だ。直近のリリースは v3.9.31（2026-09-04）、v3.9.30（同日）、v3.9.29（2026-08-28）で、パッチ番号が細かく刻まれている。最終 push は 2026-09-09 であり、少なくとも資料の範囲では継続的に手が入っている。README には 1311 回のコミット、191 バージョン、72 の PR、179 の issue を可視化した「歴史帳簿」へのリンクも置かれている。
この更新頻度は両刃である。上流の変更に追従している証拠とも読めるが、同時に上流の変化が頻繁に起きていることの裏返しでもある。バージョン番号が 3.9.x の細かい刻みで進むプロジェクトを固定して使うなら、どの版で止めるかを決め、更新時に差分を確認する運用が要る。npm ランタイム依存がゼロである点は、依存の脆弱性追跡や lockfile の更新からは解放される。一方で、Language Server バイナリという npm 管理外の依存が別に残ることは変わらない。
採用を決める前に、自分の環境で Language Server を用意する手順が README のクイックスタートに記載されているかを確認し、docs/ENV-SWITCHES.md でアカウントプールとレート制限の設定項目を把握しておくのが現実的な順序になる。
編集部の結論
Windsurf のアカウントをすでに持っていて、Claude Code や Cline、Cursor から既存のサブスクリプション経由でモデルを呼びたい個人開発者には向く。逆に、API キーを配って第三者にサービスとして提供する用途や、SLA とサポート契約が必要な業務システムには向かない。導入前に確認すべきは 3 点で、第一に LICENSE と README 冒頭の作者独自の利用条件が自分の用途に抵触しないか、第二に Windsurf の Language Server バイナリをどう用意するか（README のクイックスタートに該当手順があるか）、第三にアカウントプールとレート制限分離をどの環境変数で設定するか（docs/ENV-SWITCHES.md）である。
コミュニティノート