OpenAI 互換ゲートウェイを介して VS Code AI コーディング アシスタントを実行する

AI コーディング アシスタントを採用するエンジニアリング チームは通常、ローカルのセットアップ手順から開始します。つまり、プロバイダー キーを貼り付け、モデルを選択し、ツールで許可されている場合はベース URL を設定して、次に進みます。これは 1 人の開発者にとってはうまくいきます。すべての開発者が異なるプロバイダー アカウント、モデル リスト、支出制限、デバッグ トレイルを持っていると、操作が難しくなります。

実際的な解決策は、エディタ アシスタントを共有の OpenAI 互換 API ゲートウェイのクライアントとして扱うことです。各ツールは引き続き開発者ワークフロー内で実行されますが、リクエストは、請求、キー、モデル ポリシー、分析、インシデント対応のための 1 つのコントロール ポイントを通過します。

このガイドでは、ゲートウェイに対して一般的な VS Code AI コーディング ツールを構成する方法と、ローカル開発者の人間工学を損なうことなく運用制御を階層化する方法を説明します。

事実、推奨、予測とは何か

事実: いくつかのコーディング ツールは、OpenAI 互換エンドポイントまたはプロバイダーが構成可能なエンドポイントに接続できます。 VS Code BYOK は、チャット モデル ピッカーで複数のプロバイダーのモデルをサポートします。 GitHub Copilot アプリの BYOK ドキュメントには、サポートされているプロバイダーとして OpenAI 互換の HTTP エンドポイントがリストされています。 Continue では、オーバーライドされた API ベースを使用した OpenAI プロバイダー構成が可能になります。 Cline は、ベース URL、API キー、モデル ID を備えた OpenAI 互換プロバイダーをサポートしています。 Roo コードは、オプションの OpenAI ベース URL と一部のモデルの高度なモデル コントロールをサポートします。

推奨事項: 1 つのゲートウェイ ベース URL、開発者ごとに 1 つのゲートウェイ API キー、少数のコーディング タスク モデル プロファイル、明示的なモデルのホワイトリスト、支出制限、およびプロンプトで編集された分析を使用します。可能な限り、プロバイダー キーをローカル エディターの設定に含めないようにしてください。

予測: Editor AI トラフィックはよりエージェント的になり、実行時間が長くなり、セッションあたりのコストが高くなります。早期にルーティングを一元化したチームは、モデルの移行、コストのレビュー、インシデントの処理が容易になります。これらは結果を保証するものではなく、計画の前提として扱ってください。

ターゲット アーキテクチャ

ターゲットの状態は単純です:

• 開発者は、https://gateway.example.com/v1 などの OpenAI 互換ゲートウェイ ベース URL を使用してエディタ ツールを構成します。
• 各開発者は、共有プロバイダ キーではなく、個人のゲートウェイ API キーを使用します。
• 編集者は、生のプロバイダー モデルではなく、承認されたコーディング プロファイルを表すモデル ID を選択します。
• ゲートウェイは、これらのプロファイル ID をバックエンド プロバイダーとモデルにマッピングします。
• 使用状況分析により、各リクエストが開発者、チーム、ツール、リポジトリ、モデル プロファイル、トークン数、コスト、エラー タイプに結合されます。

ゲートウェイは、すべてのエディター機能を置き換える必要はありません。一部のホストツール機能は、ネイティブ統合、埋め込み、セマンティック検索、または独自の補完に関連付けられたままになる場合があります。目標は、OpenAI 互換のチャット、エージェント、または完了スタイルのエンドポイントを使用できるトラフィックを、管理されたパスを通じてルーティングすることです。

ステップ 1: ゲートウェイ エンドポイントの形状を定義する

ほとんどの OpenAI 互換クライアントは、/v1 で終わるベース URL を想定し、/chat/completions などのパス、またはプロバイダー固有の同等のパスを呼び出します。エディタ ツール用に文書化された 1 つのベース URL を標準化します。

ベース URL: https://gateway.example.com/v1
API キー: mg_dev_alex_...
モデル ID: code-fast

明確な理由がない限り、同じ環境に対して複数の URL を公開しないでください。ステージングと本番の両方が必要な場合は、それらに明示的に名前を付けます。

本番環境: https://gateway.example.com/v1
ステージング: https://gateway-staging.example.com/v1

最も一般的なロールアウトの失敗は、ベース URL の不一致です。ツールが https://gateway.example.com/v1 を予期しているときにユーザーが https://gateway.example.com を入力するか、ゲートウェイがサフィックスを予期しているのにツールが内部的にサフィックスを追加します。各クライアントを 1 回テストし、機能する正確な値を文書化します。

ステップ 2: 開発者ごとのゲートウェイ キーを使用する

チーム全体に 1 つの共有エディタ キーを与えないでください。共有キーにより、コストの帰属が弱く、オフボーディング中の失効が遅れ、漏洩への対応が複雑になります。

開発者ごとに 1 つのゲートウェイ キーを発行し、作成時にメタデータを添付します:

• user_id: 開発者または請負業者の ID
• チーム: プラットフォーム、製品、データ、セキュリティ、または別の内部所有者
• allowed_tools: VS Code BYOK、Continue、Cline、Roo Code、Copilot アプリ BYOK、または別のクライアント
• allowed_profiles: code-fast や code-review などの承認されたモデル プロファイル
• monthly_budget: ハードまたはソフトの支出上限
• 環境: 運用開発者の使用、ステージング、サンドボックス、または CI

クライアントがカスタム ヘッダーをサポートしている場合は、ツールとリポジトリのラベルを追加します。そうでない場合は、キー スコープ、モデル プロファイル、ソース IP 範囲、または開発者オンボーディング フォームからラベルを推測します。重要な部分は、デフォルトで生のプロンプトを保存しなくても、リクエストを責任者とポリシーのコンテキストまで追跡できることです。

ステップ 3: コーディング タスク モデル プロファイルを作成する

開発者は、長いプロバイダー モデルのリストから選択する必要はありません。タスクを説明する安定したモデル ID の小さなセットを公開します。

<テーブル> プロファイル IDユースケースゲートウェイ ポリシー <本体> コード高速短い編集、簡単な説明、ローカル チャット低遅延モデル、適度なコンテキスト制限、ほとんどのユーザーのデフォルト code-agent複数ファイル エージェントの作業とツールの使用ツール呼び出し対応モデル、より厳格な支出上限、セッション ログ コードレビューPR レビュー、アーキテクチャに関する質問、ハイコンテキストのデバッグコンテキスト モデルの拡大、リクエストごとの予算の増加、チームの承認はオプション コードエコノミー低コストのフォールバックと日常的な Q&A安価なモデル、低いコンテキスト上限、幅広い可用性 コード実験新しいコーディング モデルのオプトイン テスト制限された許可リスト、低い月次予算、明確な所有者

その後、ゲートウェイはこれらのプロファイルをバックエンド モデルにマッピングします。例:

{
  "モデルプロファイル": {
    "コードファースト": {
      "プライマリ": "provider_a/coding-small",
      "フォールバック": "provider_b/general-fast",
      "max_context_tokens": 32000、
      「最大出力トークン」: 4096
    }、
    "コードレビュー": {
      "プライマリ": "provider_c/ロングコンテキストコード",
      "フォールバック": "provider_a/coding-large",
      "max_context_tokens": 128000、
      「最大出力トークン」: 8192
    }
  }
}

これにより、バックエンド モデル名が変更された場合でも、エディターの構成が安定した状態に保たれます。また、プラットフォーム チームは、プロバイダーのインシデントやモデルの廃止時に、すべての開発者にローカル設定の編集を依頼することなくトラフィックを移動できます。

ステップ 4: 各ツールをゲートウェイ クライアントとして構成する

VS コード BYOK

プロバイダーのセットアップ フローを使用してモデル プロバイダーを追加し、チャット モデル ピッカーからそれを選択します。インターフェイスがベース URL を受け入れる場合は、ゲートウェイ /v1 エンドポイントを使用します。開発者ゲートウェイ キーを API キーとして使用し、code-fast や code-review などの承認されたモデル プロファイル ID を公開します。

操作上の注意: プロバイダー支援モデルの BYOK トラフィックは、GitHub Copilot クォータではなく、構成されたプロバイダー パスによって課金されます。これが、編集者とバックエンド プロバイダーの間にゲートウェイの請求と帰属を置く理由の 1 つです。

GitHub Copilot アプリ BYOK

Copilot アプリの BYOK の場合、表示名、ベース URL、API キーを使用して OpenAI 互換の HTTP エンドポイントを構成します。 Company AI Gateway など、ルーティング パスが明確になる表示名を使用します。モデル ID をゲートウェイ プロファイルと一致させてください。

Copilot を利用したすべての機能がこのパスを経由することを想定しないでください。一部のセマンティック検索、インライン提案、または埋め込みに依存する動作は、GitHub または Copilot 固有のサービスに関連付けられたままになる可能性があります。

続行

Continue では、オーバーライドされた API ベースで OpenAI プロバイダー構成を使用できます。最小限の構成では、プロバイダーをゲートウェイに向け、プロファイル ID をモデルとして使用する必要があります。

{
  「モデル」: [
    {
      "title": "コードファスト",
      "プロバイダー": "openai",
      "モデル": "コード高速",
      "apiBase": "https://gateway.example.com/v1",
      "apiKey": "${GATEWAY_API_KEY}"
    }
  】
}

キーをドットファイルやリポジトリローカル構成にコミットするよりも、環境変数やシークレットストレージを優先します。

クライン

Cline は、ベース URL、API キー、モデル ID を使用して OpenAI 互換プロバイダーをサポートします。ベース URL をゲートウェイ エンドポイントとして設定し、開発者キーを入力して、エージェント ワークフローの code-agent などのモデル プロファイルを選択します。

エンタープライズ展開の場合は、利用可能な場合は管理者構成を使用して、OpenAI 互換エンドポイントを組織全体に適用します。これにより、特にカスタム ヘッダー、Azure 関連の設定、または一元管理された認証パスを必要とするチームにとって、ドリフトが軽減されます。

Roo コード

Roo コードは、オプションのベース URL を使用した OpenAI 構成をサポートします。ベース URL をゲートウェイに設定し、承認されたモデル ID を使用します。ツールがサポートされているモデルの推論作業などの高度なコントロールを公開する場合、それらのコントロールがユーザー構成可能であるか、ゲートウェイ ポリシーによって固定されているかを決定します。

ステップ 5: 許可リストから始める

オープン モデルへのアクセスは実験中には魅力的ですが、IDE エージェントは大量のトークンを迅速に生成できます。ホワイトリストから始めます:

• デフォルト ユーザーは code-fast と code-economy を利用できます。
• エージェント ユーザーはオンボーディング後に code-agent を取得します。
• レビューを重視するチームは、より高額かつ明示的な予算で コードレビュー を受けます。
• 実験モデルには所有者、有効期限、使用量の上限が必要です。

ポリシーは、ローカルのセットアップ メモに埋もれるのではなく、ゲートウェイに表示される必要があります。拒否されたリクエストは、開発者、キー、モデル プロファイル、理由、次のステップなどの明確なエラーを返す必要があります。

ステップ 6: ロールアウトの質問に対する分析を構築する

一般的なトークンの合計では十分ではありません。開発者ツールのロールアウトには、運用上の質問に答える分析が必要です。

• 開発者とチームによる支出
• ラベルが利用可能なリポジトリまたはプロジェクトごとに支出する
• エディター ツールによるモデル ミックス
• プロファイルごとの平均コンテキスト サイズと出力サイズ
• エンドポイントの形状、モデル ID、ステータス コードごとにグループ化された失敗した通話
• トークン使用量が異常に多い異常値セッション
• プロンプト キャッシュがサポートされている場合のキャッシュ ヒット率
• 予算アラートを Telegram またはチーム運営チャネルにルーティングする

デフォルトでプロンプト編集されたログを使用します。リクエストのメタデータ、トークン数、モデル ID、タイミング、エラー タイプ、コスト台帳を保持します。未加工のプロンプトは、文書化されたデバッグ ワークフロー、短期間の保存、および適切なアクセス制御がある場合にのみ保存してください。

ステップ 7: エンドポイントと機能の不一致のトラブルシューティング

OpenAI 互換とは、動作が同一であることを意味するものではありません。チャットの完了、応答 API、ストリーミング、ツール呼び出し、推論制御、モデルのメタデータ、プロバイダーのエラー形式間の違いが予想されます。

ツールが失敗した場合は、このチェックリストを使用します。

• 接続エラー: ローカル プロキシ、ファイアウォール、DNS、TLS インスペクション、およびツールがゲートウェイ ホストに到達できるかどうかを確認してください。
• 401 または無効なキー: 開発者キーがアクティブであり、スコープがツールに設定されており、空白なしで貼り付けられていることを確認します。
• 404 またはモデルが見つかりません: ツールが生のバックエンド モデル ID ではなく、ゲートウェイ プロファイル ID を使用していることを確認します。
• 間違ったエンドポイント: クライアントがベース URL に /v1 を予期しているのか、内部的に追加しているのかを確認します。
• ツール呼び出しの失敗: 選択したプロファイルが、クライアントが送信する形式でツール呼び出しをサポートするモデルとアダプターにマップされていることを確認します。
• ストリーミングの失敗: 非ストリーミング モードをテストし、ゲートウェイがクライアントが期待するサーバー送信イベントの動作を保持していることを確認します。
• 予期しない出力: プロファイルによってバックエンド モデルが変更されたかどうか、システム プロンプトがツールによって異なるかどうか、バックエンドがサポートしていない推論設定をクライアントが使用していないかどうかを確認します。

ステップ 8: 段階的に展開する

すべての開発者とすべての編集者が最初から始める必要はありません。段階的ロールアウトを使用します。

<オル>

パイロット: AI コーディングを積極的に使用しているチームを 1 つ選択します。開発者ごとにキーを発行し、2 つまたは 3 つのプロファイルを有効にし、プロンプトで編集されたログを収集します。

ベースライン: 1 ～ 2 週間後に、ユーザー、モデルの組み合わせ、障害の種類、コンテキスト サイズごとの支出を確認します。

ポリシー: デフォルトの予算、許可されるプロファイル、例外ルールを設定します。

自動化: SSO、SCIM、パートナー API ワークフロー、または内部オンボーディング スクリプトを通じてキーをプロビジョニングします。

拡張: サポートされている各ツールのセットアップ スニペットを公開し、ツールがサポートする組織全体のリモート構成を使用します。

段階的なアプローチにより、開発者は早期に作業パスを得ることができると同時に、プラットフォーム チームは実際の使用状況データを使用してガバナンスを強化できます。

実用的な結論

運用モデルは単純です。すべての VS Code AI コーディング アシスタントをゲートウェイ クライアントのように見せ、開発者ごとに 1 つのゲートウェイ キーを発行し、タスク指向のモデル プロファイルを公開し、エディターのトラフィックを一元的に分析します。これにより、開発者は同じローカル ワークフローを利用できると同時に、組織には請求、モデルへのアクセス、トラブルシューティング、インシデント対応を 1 か所で管理できるようになります。

パイロット、小規模な許可リスト、即時編集されたログ、予算アラートから始めます。ゲートウェイがロールアウトの基本的な質問、つまり誰がどのツールを使用しているか、どのモデル プロファイルがコストを増加させているのか、どのエンドポイントの不一致が障害の原因となっているのか、正当な作業にはどの開発者がより高い制限を必要としているのか、に答えることができた後でのみ拡張してください。

関連資料

• 開発者ごとの API キー管理の実践
• ゲートウェイ トラフィックのプロンプト編集された使用状況分析
• モデル プロファイルの移行と非推奨の計画