「http://localhost:20128/v1」をCursorとClaude Codeの両方へ入力したら、片方だけ404や認証エラーになる。
最短解は、同じOmniRouteインスタンスを使いながら、Claude CodeにはルートURL、Cursorにはクライアント別の互換入口を指定することです。Cursorデスクトップ版、Cursor CLI、MCPも同じ扱いにしません。
最終更新:2026年8月12日。コマンドと接続仕様は、OmniRoute公式リポジトリ、公式CLI連携ガイド、Cursor公式ドキュメント、Anthropic公式ドキュメントを確認しています。
同時にCursorとClaude Codeを使い、認証情報やモデル切り替えを一元化したい個人開発者向けの記事です。リモートMac上でAI Gatewayを常時稼働させたいエンジニアや、小規模チームの接続ルールを決める担当者にも向いています。
注意:OmniRouteが公表する無料枠、プロバイダー数、圧縮率はプロジェクト側の資料に基づく値です。独立した性能測定や、すべてのモデルでの可用性を示す数字として扱わないでください。
同じゲートウェイでもURLは共通ではない
典型的な失敗は、次のような構成です。
- OmniRoute:
http://127.0.0.1:20128 - OpenAI互換API:
http://127.0.0.1:20128/v1 - Cursor:
http://127.0.0.1:20128/v1 - Claude Code:
http://127.0.0.1:20128/v1
CursorのOpenAI互換接続では/v1が必要になる場合があります。一方、Claude CodeのANTHROPIC_BASE_URLはゲートウェイのルートURLを指定し、Claude Code側がメッセージ用のパスを組み立てる設計です。AnthropicのLLM Gateway公式仕様でも、Claude Codeからゲートウェイへ接続するための環境変数と認証方式が説明されています。
接続経路は次のように分けて考えてください。
- Cursorデスクトップ版、Cursor CLI、またはClaude Codeがリクエストを送信します。
- OmniRouteがOpenAI互換またはAnthropic互換の入口で受け取ります。
- OmniRouteが登録済みのプロバイダーとモデルへ変換して転送します。
- 失敗条件やクォータ状況に応じて、別の接続先へfallbackします。
つまり「ゲートウェイを共用する」と「クライアントへ同じURLを入力する」は別の話です。OmniRouteのCLIツール別設定でも、Claude Code、Cursor、その他のCLIは個別の設定方式として扱われています。
起動確認と最小構成
まず、余計な連携を増やさず、OmniRoute単体の到達性を確認します。OmniRoute公式クイックスタートでは、npm経由でインストールした後、標準ポート20128でダッシュボードとAPIを起動する構成が案内されています。
npm install -g omniroute
omniroute
次の順番で確認してください。
1. プロセスとポートを確認する
omniroute doctor
doctorで設定、データベース、ポート、ランタイム、稼働状況を調べます。ダッシュボードが開いていても、APIが正常とは限りません。
2. プロバイダーを接続する
ダッシュボードのProvidersで、少なくとも1つのOAuthまたはAPIキー方式のプロバイダーを接続します。次にEndpointsから推論用APIキーを作成します。
3. モデル一覧を取得する
curl http://127.0.0.1:20128/v1/models \
-H "Authorization: Bearer <OMNIROUTE_API_KEY>"
空の配列、401、接続拒否のいずれかなら、クライアント側を触る前にプロバイダー接続とAPIキーを直します。
4. 最小の推論を送る
curl http://127.0.0.1:20128/v1/chat/completions \
-H "Authorization: Bearer <OMNIROUTE_API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"model": "auto",
"messages": [
{"role": "user", "content": "Return only: gateway-ok"}
]
}'
レスポンス、HTTPステータス、OmniRouteのログに成功記録が出れば、ゲートウェイの最小閉ループは完了です。画面が表示されるだけでは合格にしません。
5. リモート接続へ切り替える
同じMac上でクライアントを動かす間は、127.0.0.1またはlocalhostで問題ありません。別のMacやチーム端末から使う場合は、リモートMacの到達可能なアドレスへ変更します。
管理画面と推論APIをインターネットへ無制限に公開するのは避けてください。APIキー認証、ファイアウォール、VPNや安全なトンネルを組み合わせ、利用者ごとにキーを分けると、漏えい時の停止範囲を限定できます。
Claude CodeのルートURL設定
Claude Code側は、ANTHROPIC_BASE_URLに/v1を付けないのが要点です。
export ANTHROPIC_BASE_URL=http://127.0.0.1:20128
export ANTHROPIC_AUTH_TOKEN=<OMNIROUTE_API_KEY>
export ANTHROPIC_MODEL=<MODEL_ID>
claude
ANTHROPIC_AUTH_TOKENは認証トークンとして送信されます。認証変数の名前や優先順位を混同しないでください。環境変数を変更した後は、Claude Codeのプロセスを終了して起動し直します。既に起動しているプロセスが、後から変更したシェル変数を自動的に読み直すとは限りません。
OmniRouteのランチャーを使う方法もあります。
omniroute launch --api-key <OMNIROUTE_API_KEY>
手動設定を使う場合でも、中心になる設定は次の3つです。
ANTHROPIC_BASE_URL:http://127.0.0.1:20128ANTHROPIC_AUTH_TOKEN:OmniRouteのAPIキーANTHROPIC_MODEL:明示的なモデルIDまたはルーティング対象
モデル一覧が空になる場合は、Claude Codeのゲートウェイモデル検出を確認します。非Claude系モデルを使う場合は、一覧に表示されることを前提にせず、ANTHROPIC_MODELで明示指定してください。モデル名の対応関係は、OmniRouteのカタログと接続先プロバイダーの両方で確認します。
Cursorデスクトップ版とCLIの使い分け
Cursorは一つの接続方式として扱わないでください。
Cursorデスクトップ版
CursorのAPIキー設定に関する公式資料では、カスタムAPIキーは標準チャットモデル向けであり、Tab補完などの特殊モデルを使う機能はCursor内蔵モデルを継続利用すると説明されています。
デスクトップ版で確認する範囲は次の通りです。
- Models設定でOpenAI互換の接続先を登録する。
- Base URLはOmniRouteのOpenAI互換入口に合わせる。
- APIキーを検証する。
- 通常のチャットでリクエストを確認する。
- Tab補完や特殊機能までOmniRoute経由になると期待しない。
OmniRouteのsetup-cursorは、現在の公式CLI連携表では設定ファイルを書き換えず、アプリ内で行う手順を表示する方式です。Cursorの設定がアプリ側に保存されるため、CLIの自動設定がClaude Codeと同じように完了すると考えないでください。
Cursor CLI
Cursor CLIは別ルートです。Cursor CLIの認証資料では、APIキー認証と--endpointによるカスタム接続先が案内されています。
export CURSOR_API_KEY=<CURSOR_API_KEY>
cursor-agent --endpoint http://127.0.0.1:20128/v1 \
"Return only: cursor-ok"
ここで使うCursorの認証キーと、OmniRouteの推論APIキーは同じものとは限りません。利用するCLIモードに応じて、どの認証情報が必要かを確認してください。
MCPも別の経路です。Cursor公式のMCP資料では、stdio、SSE、Streamable HTTPなどの接続方式が説明されています。MCPサーバーを登録しただけで、Cursorのチャットリクエスト全体がOmniRouteへ移るわけではありません。
条件別の接続判断
次の条件分岐をそのまま設定前のチェックに使ってください。
-
Cursorデスクトップ版の標準チャットだけを使う
→ OpenAI互換の/v1入口を登録します。Tab補完や特殊機能まで外部化できるとは考えません。 -
Claude Codeを主に使う
→ANTHROPIC_BASE_URLへOmniRouteのルートURLを指定します。/v1は付けません。 -
Cursor CLIを自動処理やCI/CDで使う
→--endpointによるCLI経路を優先し、認証、終了コード、ログを個別に検証します。 -
MCPツールだけを接続したい
→ CursorのMCP設定を使います。チャットAPIのBase URL設定と同じ作業だと考えません。 -
複数プロバイダーへ切り替えたい
→ 2つ以上の接続先を登録し、固定モデルではなくComboまたは自動ルーティングを使います。 -
同じMacで短時間だけ試す
→ localhost運用で十分です。外部公開は不要です。 -
端末をまたいで継続利用する
→ 常時稼働するリモートMacへ移し、アクセス制御と再起動後の復旧を確認します。
モデル切り替えとfallbackの検証
単一モデルを指定する構成と、多モデルfallbackは別物です。
modelに固定モデルを指定する:そのモデルへの直通に近い構成です。autoを指定する:OmniRouteの自動ルーティング対象になります。- Comboやfallbackチェーンを作る:先頭失敗時の次候補を明示できます。
OmniRoute公式リポジトリでは、auto系の自動ルーティングと、プロバイダー障害やクォータ枯渇時の切り替え機能が案内されています。ただし、無料トークン量、プロバイダー数、圧縮率はプロジェクト側の公表値です。独立実測として引用しないでください。
fallbackを検証する手順は次の通りです。
- 先頭モデルと次候補モデルを別プロバイダーへ登録します。
- Comboまたは自動ルーティングの対象を作ります。
- Cursor CLIまたはcurlで、毎回同じ短いリクエストを送ります。
- 先頭プロバイダーのキーを一時的に無効化するか、対象モデルを利用不能にします。
- OmniRouteのログで失敗理由、次のターゲット、最終モデルを確認します。
- 先頭プロバイダーを戻し、通常経路へ復帰するか確認します。
利用枠が尽きても、次の接続先が未認証なら切り替え先はありません。また、固定モデルを直接指定していると、Comboの設定を作ってもそのルールを通らない場合があります。ログでルーティング判断を確認することが重要です。
FAQ:接続前に確認する点
OmniRouteはCursorとClaude Codeで同時に使えますか
同じOmniRouteインスタンスを2つのクライアントから利用できます。ただし、Claude CodeはAnthropic Messages形式、CursorはOpenAI互換入口を使う構成が基本です。サーバーは共用できますが、クライアントへ入力するURL形式は共通ではありません。
Claude CodeのURLに/v1を付けますか
通常は付けません。ANTHROPIC_BASE_URLには、たとえばhttp://127.0.0.1:20128のようなOmniRouteのルートURLを指定します。/v1を付けると、クライアントがさらにパスを追加し、存在しないURLへ接続する可能性があります。
Cursorデスクトップ版とCursor CLIは同じ方法ですか
同じではありません。デスクトップ版は設定画面から標準チャット用のAPIキーを登録します。Cursor CLIは--endpointで接続先を指定できます。MCPはさらに別の接続経路なので、どの機能を検証しているかを分けて記録してください。
利用枠が尽きてもfallbackしない理由は何ですか
単一モデルを直接指定している、fallbackチェーンが作成されていない、次の接続先が未認証、またはエラーが切り替え条件として処理されていない可能性があります。2つ以上のプロバイダーで停止演習を行い、ログ上の最終モデルを確認してください。
OmniRouteをリモートMacに置けますか
可能ですが、localhostのままでは別端末から接続できません。Mac側で到達可能なアドレスを使い、APIキー認証、ファイアウォール、VPNや安全なトンネルを組み合わせます。管理画面を無制限に公開せず、必要なAPI経路だけを許可してください。
リモートMacの引き渡し条件
リモートMacへ移す場合は、OmniRouteを起動してIPアドレスを渡すだけでは不十分です。次の項目を合格条件にします。
- [ ] Cursorデスクトップ版の標準チャットが指定経路へ届く。
- [ ] Cursor CLIが指定endpointへ接続できる。
- [ ] Claude CodeがルートURLからメッセージAPIへ到達する。
- [ ]
GET /v1/modelsが認証付きで応答する。 - [ ] 先頭モデル停止後、次のモデルへ切り替わる。
- [ ] 長時間のストリーミング中にMacがスリープしない。
- [ ] SSH切断後もゲートウェイが稼働する。
- [ ] OmniRoute再起動後に設定とAPIキーが保持される。
- [ ] APIキーを利用者ごとに分離し、不要な管理権限を与えない。
リモートMacの利用形態や接続管理は、MacHTMLのコンソール案内とMacHTMLのヘルプも確認してください。個人の短時間検証なら手元のMacで十分ですが、端末のスリープ、ネットワーク変更、移動中の切断が頻発するなら、常時稼働する環境へ移した方が運用を組みやすくなります。
ローカル構成の利点は、設定が速く、ネットワーク経路を増やさずに試せることです。欠点は、Macのスリープ、ユーザーセッション終了、Wi-Fi変更、電源断がそのままAI Gatewayの停止につながることです。
リモートMacの利点は、CursorとClaude Codeを複数端末から同じ構成で利用しやすく、接続先や認証を固定できることです。一方で、アクセス制御、監視、再起動、キーの失効管理が必要になります。長期的に固定負荷をかける場合は自前のMac購入も比較し、短期検証やチーム共有ならレンタル環境を候補に入れると判断しやすくなります。
まずは手元のMacで、Claude CodeのルートURL、Cursorの互換入口、2つのプロバイダーによるfallbackを確認してください。そのうえで、端末のスリープや回線変動を避けたい、複数端末から同じ環境へ接続したい、チームで認証を分けたいという条件が出たら、MacHTMLのリモートMac環境を検討してください。自宅Macを常時起動する方法より、継続稼働する環境へ切り替えた方が、AI Gatewayとコーディングエージェントの復旧条件を管理しやすくなります。
よくある質問
MacHTMLで開発環境の検証を始めませんか
MacHTMLのリモートMacなら、ブラウザから本格的なmacOS開発環境へ接続できます。 必要な期間だけMacを利用できるため、新しい開発環境の検証や比較に適しています。 手元の端末に環境を構築することなく、実際のMac上で設定や動作を確認できます。 複数の開発ツールを組み合わせたワークフローを、MacHTMLで効率よくお試しいただけます。