OmniRoute/docs/i18n/ja/docs/reference/PROVIDER_PLUGIN_MANIFEST.md

Provider Plugin Manifest (日本語)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

open-sse/config/providerPluginManifest.ts は、JSON セーフなプロバイダー プラグイン契約を定義します。open-sse/config/providerPluginManifestRegistry.ts は、 その契約を、Bifrost、CLIProxyAPI、または将来の Go/Rust ルーターなどのサイドカー向けに、 現在のプロバイダーレジストリへバインドします。TypeScript レジストリは引き続き 信頼できる唯一の情報源ですが、サイドカーは executor コード、OAuth のデフォルト値、 ヘッダー、またはプロセスの環境状態をインポートせずにマニフェストを利用できます。

同じマニフェストは、別プロセスで実行されるサイドカー向けに、HTTP の GET /api/v1/provider-plugin-manifest でも利用できます。

OmniRoute は、X-OmniRoute-Provider-Manifest-Url リクエストヘッダーを介して、 その URL を Bifrost と CLIProxyAPI に通知します。サイドカーがローカルのリクエスト元ではなく、 公開 URL またはコンテナネットワーク URL を必要とする場合は、 OMNIROUTE_PROVIDER_MANIFEST_URL を設定してください。

マニフェストの更新

HTTP エンドポイントは、Cache-Control: public, max-age=60 と強い ETag を返します。サイドカーは最後に検証済みのマニフェストを保持し、更新時にその ETag を If-None-Match で送信する必要があります。304 Not Modified レスポンスには本文がないため、 サイドカーはキャッシュ済みのマニフェストを引き続き使用します。検証済みのキャッシュ済み マニフェストが存在しない場合、サイドカーは 304 を受け入れるのではなく、 条件なしのリクエストを送信しなければなりません。

目標

プロバイダーのメタデータをプラグイン契約へ移行し、将来的に低レイテンシーのサイドカーが 高頻度のリクエストパスを担えるようにする一方で、OmniRoute は TypeScript ルートを ポリシーゲートおよびフォールバックとして維持します。マニフェストは追加的なものであり、 それ自体がリクエストルーティングを変更することはありません。

契約

マニフェストには以下が含まれます。

• プロバイダー ID とエイリアス
• アップストリーム形式と executor 名
• 認証タイプ、認証ヘッダー、および任意の認証プレフィックス
• 静的エンドポイントメタデータ
• サイドカーの適格性、およびプロバイダーを TS 側に残すべき場合の明示的な理由
• コンテキスト長、ビジョン/推論フラグ、未対応のパラメーターなど、JSON セーフなモデルメタデータ
• apikey、oauth、custom-executor、 passthrough-models、responses、sidecar-candidate、usage-fetch、usage-supported を含むケイパビリティタグ

マニフェストでは、以下を意図的に除外しています。

• OAuth クライアントシークレットとデフォルトのシークレット値
• 実行時の環境解決
• リクエストヘッダーと公開認証情報ヘルパー
• 動的 URL ビルダー
• executor 関数
• セッションプールの内部実装

ケイパビリティタグ

capabilities は、レジストリエントリから派生したタグをソートした配列です。インテグレーターは、 TypeScript ソースを読み直すのではなく、「このプロバイダーには何ができるか」に対する 機械可読な回答として扱う必要があります。

タグ	意味
apikey	API キーを受け付けます（authType が apikey または optional）。
oauth	OAuth またはセッションフローを使用します。
responses	OpenAI Responses-API のベース URL を公開します。
passthrough-models	静的カタログではなく、アップストリームから直接モデルを提供します。
custom-executor	デフォルト以外の executor を実行するため、TypeScript パスに残ります。
sidecar-candidate	sidecar.eligible を反映します — サイドカーへのインポート候補として安全に検討できます。
usage-fetch	接続済みの使用量またはクォータ取得機能（getUsageForProvider）があります。
usage-supported	使用量 API がこのプロバイダーを受け入れます（isSupportedUsageConnection）。

usage-fetch は検出専用です。これは、OmniRoute がそのプロバイダーの使用量を読み取る方法を 認識していることを示しますが、取得の有効化、クォータのセマンティクスの変更、 またはそのプロバイダーに対して Dashboard のクォータウィジェットが有効であることを意味しません。 このウィジェットは USAGE_SUPPORTED_PROVIDERS によって別途制御されます。信頼できる唯一の情報源は、 open-sse/services/usage/fetcherProviders.ts の USAGE_FETCHER_PROVIDERS です。

このリストは使用量ディスパッチャーが受け入れる文字列をキーとしているため、正規 ID と エイリアスが混在し、タグ付けされたプロバイダー数よりわずかに長くなっています。 マニフェストレジストリ内のチャットプロバイダーではないエントリ（たとえば firecrawl 検索プロバイダーや amazon-q ACP プロバイダー）には、タグ付けするマニフェストエントリがありません。

usage-supported は、サーバーおよび Dashboard の使用量ルートが、そのプロバイダーの 接続を受け入れるかどうかを示します。これは、USAGE_SUPPORTED_PROVIDERS （open-sse/services/usage/supportedProviders.ts）によって制御される isSupportedUsageConnection()（src/lib/usage/providerLimits.ts）および supportsProviderQuota()（src/shared/utils/providerQuotaVisibility.ts）を反映します。 usage-fetch とは異なり、これはプロバイダー ID のみに対して出力されます。実行時ガードは、 エイリアスを解決せずに USAGE_SUPPORTED_PROVIDERS.includes(providerId) を実行するため、 マニフェストも同じルールを維持します。この 2 つのタグの対象範囲は異なります。 3 つのプロバイダー（opencode、opencode-zen、xai）は usage-fetch のみを持ち、 1 つのプロバイダー（xiaomi-mimo-token-plan）は usage-supported のみを持つため、 一方が他方を意味することはありません。

Sidecar の使用

Sidecar は sidecar.eligible を無条件のルーティング決定ではなく、保守的な候補シグナルとして扱う必要があります。最初のインポート対象は、デフォルトの executor を使用する API キー／静的エンドポイント方式のプロバイダーにすべきです。カスタム Web executor、OAuth／セッションフロー、動的 URL ビルダー、またはプール設定を持つプロバイダーは、Sidecar が同等の動作を実装し、テレメトリによって同等性が実証されるまで、TypeScript のフォールバックパスに残します。

推奨される移行フェーズ：

1. TS レジストリからプロバイダープラグインマニフェストを生成し、検証します。
2. API キー／静的エンドポイント方式のプロバイダー向けに、マニフェストをインポートできるよう Bifrost または CLIProxyAPI を対応させます。
3. TS フォールバックを有効に保ちながら、OMNIROUTE_RELAY_BACKEND の背後で対象プロバイダーを Sidecar 経由にルーティングします。
4. 成功率、p99 レイテンシ、ストリーミング動作、および未サポートパラメーターの処理が TS パスと一致する場合にのみ、プロバイダーを昇格させます。
5. カスタム executor 向けの Sidecar ネイティブプラグインを、プロバイダーファミリーごとに順次追加します。

プロバイダーを Next に直接組み込まない理由

Next フロントエンドは、プロバイダーの実行を担うべきではありません。API 境界を呼び出すようにすべきです。そうすることで、バックエンドは TypeScript executor、Bifrost、CLIProxyAPI、または将来のネイティブ Sidecar のいずれを使用するかを決定できます。これにより、Sidecar に処理を引き渡す前に、リクエスト署名、許可リストのチェック、DB ポリシー、およびフォールバック動作を一元管理できます。