Cursor OpenAI互換APIの設定：ベースURL、モデル名、使用ログ

CursorのOpenAI互換API設定は、APIキー、ベースURL、モデル名の3つのフィールドだけを考えれば単純に見えます。しかし実際には、Cursorは独自のモデルピッカー、使用量アカウンティング、チームコントロール、プロンプト構築パスを持つ高レベルのコーディングツールであるため、単にコピー＆ペーストするのではなく、検証ワークフローを経る方が安全な設定方法です。

2026年7月8日に確認した現在の公開Cursor APIキードキュメントによると、Cursorは「Cursor設定 > モデル」で指定されたプロバイダーに対してBring Your Own API Key（BYOK）を文書化しています。これにはOpenAI、Anthropic、Google、Azure OpenAI、AWS Bedrockのキーが記載されています。また、カスタムAPIキーはチャットモデルでのみ機能し、Tab補完は引き続きCursorの組み込みモデルを使用し、独自のキーによるリクエストも最終的なプロンプト構築のためにCursorサーバーを経由すると述べられています。公開ドキュメントには、一般的な任意のOpenAI互換ベースURLフィールドに関する記述はありません。

これはFlatkeyユーザーにとって重要です。Flatkeyは、チームに1つのキー、https://router.flatkey.ai/v1にあるOpenAI互換ゲートウェイ、複数のプロバイダーにまたがるモデルアクセス、そして使用量とコストのレビューを1か所で提供します。お使いのCursorのビルド、管理者ポリシー、またはプロバイダー設定でカスタムOpenAIベースURLフィールドが公開されている場合は、このガイドを使用して設定を検証してください。お使いのCursor UIがプロバイダー所有のAPIキーのみをサポートしている場合は、同じチェックを使用して、Cursorを文書化されたプロバイダーフローのままにするか、ClineやClaude Codeルーターワークフローなど、カスタムベースURLを明示的に公開するツールでFlatkeyを使用するかを決定してください。

目標は、すべてのCursorリクエストをゲートウェイ経由で強制することではありません。目標は、すべてのCursor OpenAI互換APIに関する決定を検証可能にすることです。つまり、誰がキーを所有しているか、どのベースURLが実際に使用されているか、どのモデル名が選択されているか、使用量はどこに表示されるか、そしてどのようにロールバックするかを明確にすることです。

Cursor OpenAI互換API設定：最初に検証すべきこと

設定を変更する前に、まず簡単な決定表から始めましょう。

これがCursor OpenAI互換API設定の第一のルールです。APIキーフィールドをゲートウェイルートの証明と見なさないでください。キーフィールドは認証情報の入力を証明するものです。ルーティングを証明するのは、ベースURLフィールド、リクエストログ、そして使用記録です。

Cursorを操作する前に収集すべき値

設定値を小さなワークシートにまとめます。これをUIの変更を行う開発者だけでなく、請求やセキュリティを担当する人と共有してください。

Cursor OpenAI互換APIのテストで最もよくある間違いは、あるシステムのモデル表示名を別のシステムで使用することです。Cursorのモデル名、プロバイダーのモデルID、Flatkeyのルートエイリアスは自動的に互換性があるわけではありません。リクエストを受け取る側の場所からモデル名を選択してください。

最初に外部でスモークテストを実行する

Cursor内でテストする前に、Cursorの外部でゲートウェイの値を検証します。これらのスニペットはテンプレートです。キーとモデルを、お使いの現在のFlatkeyアカウントとカタログの値に置き換えてください。

export FLATKEY_API_KEY="sk-fk-..."
export FLATKEY_MODEL="your-current-model-alias"

curl -sS https://router.flatkey.ai/v1/models \
  -H "Authorization: Bearer $FLATKEY_API_KEY"

modelsレスポンスを使用して、正確なモデルIDまたはエイリアスを確認します。次に、チャットパスをテストします。

curl -sS https://router.flatkey.ai/v1/chat/completions \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$FLATKEY_MODEL"'",
    "messages": [
      {
        "role": "user",
        "content": "Reply with exactly: cursor route probe ok"
      }
    ]
  }'

リクエストのタイムスタンプ、モデル名、HTTPステータス、レスポンスボディ、そしてレスポンスに含まれている場合はusageオブジェクトを保存します。OpenAIのChat Completions APIの形式はmodelとmessagesを中心に構築されており、成功したレスポンスにはトークン使用量が含まれることがあります。OpenAIのmodelsエンドポイントは、アカウントで現在利用可能なモデルを一覧表示します。これら2つの事実により、このスモークテストはCursorを関与させる前に役立ちます。

この外部テストが失敗した場合は、Cursorに進まないでください。まず、キー、モデルエイリアス、クォータ、またはエンドポイントファミリーを修正してください。失敗した外部テストは、Cursorが独自のモデルピッカー、プロンプト構築、リクエストパスを追加した後では、デバッグが容易になることはありません。

ルートが証明された後にのみCursorを設定する

次にCursorを開き、アカウントで利用可能な実際の設定を調べます。

1. Cursorの設定 > モデルを開きます。
2. 組織が個人用APIキーを許可しているかどうかを確認します。エンタープライズ管理者はBYOKの使用を制限できます。
3. Cursorのドキュメントに記載されているBYOKパスを使用している場合は、Cursorがサポートするプロバイダーの行を選択し、そのプロバイダーのキーを入力します。
4. お使いのCursor環境でカスタムのOpenAI互換ベースURLフィールドが公開されている場合は、完全な/chat/completionsパスではなく、ベースURLのルート部分（例：https://router.flatkey.ai/v1）のみを入力します。
5. 受信システムからモデル名を入力または選択します。Flatkeyの場合は、Flatkeyカタログまたは/v1/modelsスモークテストで確認したモデルエイリアスを使用します。
6. 設定を保存し、Cursorがモデルピッカーでターゲットモデルを公開している場合は、そこで選択します。

ここで記事のタイトルがチームを誤解させる可能性があります。CursorのOpenAI互換APIの設定は、設定ページを保存しただけでは完了しません。Cursorから送信したリクエストが、期待される使用履歴に表示されたときにのみ完了します。

Cursorモデルルーティングのためのモデル名チェックリスト

誰かが「どのモデル名を入力すればよいですか？」と尋ねたときに、この表を使用してください。

CursorのOpenAI互換APIの展開では、まずプレーンチャットから始めてください。最初のテストとして、大規模なコードベースのリファクタリング、ツールを多用するエージェントの実行、または長時間のMax Modeセッションを使用しないでください。最初のプロンプトは、使用記録が主な結果となるように、十分に単純なものにしてください。

3か所で利用ログを確認する

テキストを返しても使用履歴が残らないゲートウェイ設定は、本番環境に対応していません。最初のリクエストの後、3つのレイヤーを確認してください。

所有権に関する重要な詳細は、Cursor自身のドキュメントに、最終的なプロンプト構築のために、すべてのown-keyリクエストでAPIキーがCursorのバックエンドに送信されると記載されていることです。つまり、CursorのOpenAI互換APIテストは、ラップトップからプロバイダーへの直接のローカルコールとしてではなく、ツールとゲートウェイを経由するパスとしてレビューする必要があります。

チームがCursorのゼロデータ保持に依存している場合は、独自のキーを使用する前にCursorのBYOKプライバシーノートをお読みください。Cursorは、独自のAPIキーを使用する場合、そのゼロデータ保持ポリシーは適用されないと述べています。データ処理は、選択したプロバイダーのポリシーに従います。Flatkey経由でルーティングする場合は、Flatkeyの現在のポリシー、ダッシュボード、および保持の証拠を同じレビューパケットに追加してください。

ベースURL、キー、モデルの障害に関するトラブルシューティング

ほとんどの障害は、少数の原因に分類されます。

OpenAI独自のエラーガイドでは、認証、レート制限、クォータ、およびサービス過負荷エラーを、所有者が取るべき異なるアクションとして扱っています。Cursorのランブックでもその区別を維持してください。リトライポリシーでは間違ったモデル名を修正できず、新しいモデル名ではBYOKポリシーによるブロックを修正できません。

CursorでFlatkeyを使用すべきでない場合

Cursor OpenAI互換APIに関する最善の決定が、使用を中止することである場合があります。

現在のCursorビルドがベースURLのオーバーライドを公開しておらず、ワークフローで真のカスタムエンドポイントが必要な場合は、CursorをFlatkey経由でルーティングしないでください。エンタープライズ管理者が個人用APIキーを無効にしている場合は、CursorをFlatkey経由でルーティングしないでください。セキュリティレビューが、独自のキートラフィックには適用されないCursorの組み込みモデルのプライバシー管理に依存している場合は、CursorをFlatkey経由でルーティングしないでください。

そのような場合は、Cursorを文書化されたプロバイダーパス上で使用し続け、クライアントがOpenAI互換のベースURLを明示的にサポートしている場所でFlatkeyを使用してください。例えば、アプリケーションSDK、内部ツール、評価スクリプト、Cline、Open WebUI、LangChain、LlamaIndex、その他の統合サーフェスなどです。一般的な移行パターンが必要な場合は、OpenAI互換API移行ガイドから始めてください。コーディングエージェントのルーターパターンについては、Claude Code APIルーター設定とCline OpenAI互換API設定を比較してください。

本番環境チェックリスト

Cursor OpenAI互換APIの設定が完了したと見なす前に、以下の証拠を保存してください：

Cursor OpenAI互換APIの設定は、コーディングツールのトラフィックを、管理されレビュー可能なモデル使用量に変える場合に価値があります。ベースURL、モデル名、および使用ログの証明をまとめて保管してください。1つのゲートウェイキーとモデルトラフィックをレビューする1つの場所が必要な場合は、Flatkeyキーを取得し、まず低リスクのチャットリクエストをテストし、ログがルートを証明した後にのみ移行してください。