変更点
移行は次の 4 段階です。
- payload の形式を維持する。
- ベース URL と API キーの参照元を切り替える。
- モデル ID と OpenRouter 固有のヘッダーを確認する。
- トラフィックを段階的に移し、レイテンシ、出力、コストを比較する。
開始前の準備
- 現在の OpenRouter 統合コードとデプロイ設定へのアクセス。
- 開発、ステージング、本番環境で
PHASEO_API_KEYを利用できること。 - 本番で使うモデル ID と代表的なプロンプトの短い一覧。
1) OpenRouter の現在の使用箇所を洗い出す
URL、キー、モデル ID、プロバイダー固有のヘッダーなど、OpenRouter に関する参照をすべて探します。openrouter.aiのエンドポイントを検索します。- コード、CI、ホスティング環境変数から
OPENROUTER_API_KEYを検索します。 HTTP-RefererやX-Titleなど OpenRouter 固有のヘッダーを検索します。- 有効なモデル ID とフォールバックのロジックを記録します。
- アプリ内で重複させず Gateway のプリセットに移すべき、共有プロンプト、プロバイダー、パラメーターの既定値を特定します。
2) ベース URL と認証情報を切り替える
最初はリクエスト payload を変えずに、最適化の前に動作の同等性を確認します。3) モデル ID を検証し、OpenRouter 固有の動作を対応付ける
以前のエイリアスがすべて有効だとは限りません。/v1/models を参照して本番モデル ID を確認します。標準の応答には現在公開ルーティング可能なモデルのみが含まれます。無効または提供予定の対応付けを調べる場合に限り availability=all を使います。
Authorization: Bearerの形式を維持します。- 呼び出し元アプリの識別に使う場合は
HTTP-RefererとX-Titleを維持します。Phaseo は小文字のhttp-refererとx-titleも受け付けます。 - OpenRouter 固有の応答フィールドに依存する呼び出し元がある場合は、1 つの互換レイヤーで対応します。
- 許可・拒否プロバイダーリストやルーティング既定値は、呼び出し側に散在させずプリセットとルーティングとフォールバックに移します。
プロバイダー制御を対応付ける
地域制御が必要な場合、Phaseo は
provider.required_execution_region と provider.required_data_region もサポートします。リクエスト全体はプロバイダーを固定または除外するとEU または ZDR 対応プロバイダーのみにルーティングするを参照してください。
4) OpenRouter との同等性チェックリスト
まとまったトラフィックを切り替える前に、次を確認します。- ベース URL を
https://api.phaseo.app/v1に更新した。 - すべての環境で
OPENROUTER_API_KEYをPHASEO_API_KEYに置き換えた。 - 本番のすべてのモデル ID を
/v1/modelsで確認した。 /v1/chat/completionsまたは/v1/responsesで非ストリーミング要求を検証した。- 本番と同じアプリ統合経路でストリーミング要求を検証した。
GET /v1/generations?id=<request_id>を再確認した。replay_supported=trueの場合、保存されたreplay_requestから失敗した要求を再実行できます。- 実際のプロンプトでツール呼び出しと構造化出力を再確認した。
- ステージングで無効なキーとモデルのエラーを確認した。
- OpenRouter 固有のヘッダーや応答フィールドを削除、または明示的に正規化した。
- 共有プロンプトやルーティングの既定値を必要に応じてプリセットに移した。
エージェント向け移行チェックリスト
コーディングエージェントには、次の範囲を限定した手順を渡します。- 実行コードとデプロイ設定から
openrouter.ai、OPENROUTER_API_KEY、sk-or-v1、HTTP-Referer、X-Titleを検索する。 - 秘密値をソース管理に追加せず、クライアント境界を
https://api.phaseo.app/v1とPHASEO_API_KEYに変更する。 GET /v1/modelsを照会し、旧モデルから新モデルへの対応表を記録する。- OpenRouter 固有のルーティング設定や応答フィールドを、1 つの互換モジュールで調整する。
- 下記の health、models、通常要求、streaming、エラー経路を確認する。
- 変更ファイル、シークレット名の変更、モデル対応表、テスト結果、同等性の差、ロールバック方法を報告する。
5) 安全に段階展開する
開発環境、小規模な本番トラフィックの順に切り替え、メトリクスが安定してから全量を移行します。- 最初は社内トラフィックだけで始めます。
- 本番の 5〜10% に増やし、品質、レイテンシ、コストを比較します。
- 同等性を確認できたら 100% に増やします。
- 切り替えが安定するまで、URL とキーだけで戻せるようにします。
検証コマンド
- アプリの統合テスト経由でストリーミング要求を 1 件実行します。
- 無効なキーまたはモデルの異常系テストを実行します。
- 小さな基準プロンプトセットを再実行し、出力を比較します。