AI API アクセスを再販できますか?立ち上げる前にプロバイダー権利マトリックスを作成する
有効なプロバイダー キーは、その API を再配布できることを証明するものではありません。バージョン管理された権利マトリックスを構築し、顧客の受付およびリクエストのルーティング中に商用許可を強制します。
プロバイダーが API リクエストを受け入れても、同じアクセスを顧客に販売する権限があることを意味するわけではありません。技術的な可用性と商用ライセンスは別個の条件です。
この区別は、AI API 再販プラットフォームを運用する場合、互換性のあるエンドポイントを公開する場合、または 1 つのキーの背後に複数のプロバイダをバンドルする場合に重要です。上流の条件では、モデル出力を使用するアプリケーションを許可したり、生のパススルー アクセスを禁止したり、再販契約を要求したり、顧客の所在地を制限したり、顧客所有の資格情報のみを許可したりする場合があります。
実際的な解決策は、配布権をルーティング機能として扱うことです。顧客を承認する前、またはプロバイダー ルートを選択する前に、ゲートウェイは、関連するアカウント、モデル、配信モード、顧客の地域が文書化された許可の対象であることを確認する必要があります。
範囲: これは運用アーキテクチャと問題発見のガイダンスであり、法的なアドバイスではありません。最終的な許可は、締結された契約、購入チャネル、製品設計、適格な法的審査によって異なります。
有効な API キーでは十分ではない理由
プロバイダ契約では、通常、いくつかの商業関係が区別されます。
- アプリケーションはモデルを使用して、エンド ユーザーに機能を提供します。
- プラットフォームは、モデルに実質的なワークフロー、ポリシー、またはオーケストレーション機能を追加します。 inference.
- 再販業者は、認定パートナー プログラムに基づいてプロバイダ サービスを提供します。
- ゲートウェイは、未加工のプロバイダ エンドポイントまたはわずかに変更されたプロバイダ エンドポイントを公開します。
- 顧客は、Bring-your-own-key（BYOK）を通じて独自のプロバイダ アカウントに接続します。
これらの取り決めは互換性がありません。統合された請求、分析、ルーティング、および顧客向けキーは実際の価値を生み出しますが、未加工の再配布を承認された顧客アプリケーションに自動的に変換するわけではありません。
資格情報ルールも配布権限とは別のものです。アプリケーションがエンド ユーザーにサービスを提供することを契約で許可している場合でも、アップストリーム キーやアカウント アクセスの販売または譲渡が禁止されている場合があります。ダウンストリームの顧客は、プールされたプロバイダの認証情報ではなく、ゲートウェイが発行した認証情報を受け取る必要があります。
現在のプロバイダ規約の説明
以下は、使用前に現在の文書および独自の契約と照らし合わせて確認する必要がある実際の例です:
- OpenAI: そのサービス契約により、顧客への API の統合が許可されています。エンドユーザーが利用できるアプリケーション。 API キーの購入、販売、譲渡、およびアカウントまたはエンドユーザー アカウントへのアクセスの再販またはリースは別途禁止されています。
- Anthropic: その商務条件では、顧客およびユーザーに提供される製品およびサービスを強化するためにサービスを使用することを顧客に許可していますが、明示的な承認なしに Anthropic サービスを再販することは禁止しています。
- Microsoft Azure: Azure カスタマー ソリューション ガイダンスでは、そのルートではモデル推論 API の単純な再販は許可されていないと記載されています。これは、未加工の出力または薄くラップされた出力、未変更のエンドポイント公開、および出力を整形せずに推論プロバイダー間のルーティングを不適格な例として識別します。適格なソリューションでは、主要な重要な機能を追加し、推論 API をプラットフォーム内に保持する必要があります。実際の Azure の再販を求める企業は、クラウド ソリューション プロバイダー プログラムを対象としています。
- Google クラウド: その一般規約では、サービスの販売、再販、サブライセンス、譲渡、配布を禁止しています。サービス固有の条件には、準拠協定によりパートナーまたは再販プログラムによる供給が承認されるパートナー条項が含まれます。
地理によっても決定が変わる可能性があります。 OpenAI は、サポートされている国や地域以外で API にアクセスしたり、アクセスを提供したりすると、ブロックまたは停止につながる可能性があると述べています。したがって、顧客の入場は、ゲートウェイ会社がプロバイダー アカウントを登録した国だけに依存することはできません。
重要な結論は、すべてのプロバイダーが 1 つのルールに従っているわけではないということです。その逆です。provider_enabled などのプロバイダ全体のブール値は、関連する権限を表すことはできません。
権利を確認する前に配信モードを定義します
顧客がモデルの機能を受け取る方法について制御された語彙を作成します。実際の最初のバージョンでは、次の 5 つのモードを使用できます:
- 組み込みワークフロー: モデルは、ドキュメント分類、サポート草稿、構造化抽出などの定義された製品ワークフロー内で動作します。
- 付加価値のある開発者プラットフォーム: 顧客は API を受け取りますが、プラットフォームはマテリアル オーケストレーション、ポリシー適用、変換、評価、または機能を追加します。アプリケーション サービス。
- 未加工の互換性のあるエンドポイント: プラットフォームは、主に共通の API スキーマを通じてモデルのリクエストと応答を渡します。
- 認定されたクラウド再販: オペレーターは、提案された供給モデルを契約に含むプロバイダーまたはクラウド再販プログラムに参加します。
- 顧客所有BYOK: 顧客はプロバイダと契約し、ゲートウェイ経由で使用する認証情報を提供します。
マーケティング用語からモードを推測しないでください。製品が実際に何を行うかを記録します。たとえば、モデル ID の名前を変更し、使用状況ダッシュボードを追加しても、ランタイム サービスは未加工のエンドポイントと機能的に同等のままになる可能性があります。
バージョン管理されたプロバイダー権限マトリックスを構築する
レジストリは、プロバイダーやモデル カタログよりも細分化する必要があります。各権利レコードには次のものが含まれている必要があります:
- プロバイダーおよび契約主体
- プロバイダー アカウント、プロジェクト、ワークスペース、サブスクリプション、請求先アカウント
- 直接、マーケットプレイス、クラウド プログラム、再販プログラムなどの購入チャネル
- 対象モデル、モデル ファミリー、サービス、または導入
- 許可される配信モード
- 許可される顧客およびユーザー地域
- 顧客タイプの制限
- 必要な製品機能またはブランド
- 禁止されるアクセス形式
- 契約またはプログラム名および発効日
- ソース スナップショット、審査担当者、審査日
- 承認範囲、交渉された例外、更新日
- 下書き、承認、制限、期限切れ、一時停止などのステータス
承認後は記録を不変に保ちます。修正と権限の更新により、発効日が設定された新しいバージョンが作成される必要があります。これにより、ルートが過去のリクエストの対象となった理由を説明できるようになります。
{
"rights_record_id": "rr_azure_042_v3",
"provider": "cloud_provider_a",
"account_id": "acct_042",
"purchasing_channel": "customer_solution",
"service_scope": ["model-family-x"],
"delivery_modes": ["embedded_workflow"],
"customer_regions": ["approved-region-set-1"],
"prohibited_modes": ["raw_compatible_endpoint"],
"effective_from": "2026-09-01",
"effective_to": "2027-08-31",
"status": "approved",
"evidence_id": "ev_9182"
}プロバイダを選択する前に権利を強制する
権利許可ステージを AI API コントロール プレーンに追加します。健全性、価格、遅延、容量のランキングよりも前に実行する必要があります。商用利用資格がリクエストに対応していない場合、高速かつ安価なルートは不適格のままです。
決定入力には少なくとも以下が含まれている必要があります:
- テナントと顧客の組織
- 確認された顧客とユーザーの地理
- 製品または配信モード
- リクエストされたモデル能力
- 候補プロバイダー アカウント
- 現在の権利レコード バージョン
- 該当する例外または承認の参照
一般的な承認エラーではなく、構造化された決定を返します:
{
"eligible": false,
"reason_code": "DELIVERY_MODE_NOT_PERMITTED",
"rights_record_id": "rr_azure_042_v3",
"requested_mode": "raw_compatible_endpoint",
"permitted_modes": ["embedded_workflow"],
"fallback_modes": ["customer_owned_byok"]
}権利レコードが欠落している場合、期限切れである場合、レビュー待ちの場合、またはデフォルトで拒否の動作を使用する地理的に曖昧。アカウントが同じ顧客およびモードに対して個別に有効な権限を持っている場合を除き、別のプールされたアカウントをサイレントにルーティングしないでください。
通常の承認から権限チェックを分離します
テナント承認は、呼び出し元がモデルを使用できるかどうかに答えます。権利許可は、オペレーターが特定のアカウントおよび製品を通じてそのモデルを提供できるかどうかを答えます。両方とも合格する必要があります。
この分離により、顧客向けの仮想キーも便利になります。このキーは、上流の認証情報を公開したり転送したりせずに、テナント、予算、モデル ポリシーを識別できます。
明示的なフォールバックとして BYOK を使用する
プールされた認証情報に明確な再配布権限がない場合、直接契約した顧客アカウントが実行可能なルートを提供する可能性があります。 BYOK モードでは、プロバイダ関係の所有者、プロバイダへの支払い者、引き続き適用されるゲートウェイ料金、割り当てやプロバイダの一時停止を誰が処理するかを記録します。
BYOK では、すべての義務が削除されるわけではありません。ゲートウェイには、安全な資格情報のストレージ、権限チェック、正常性プローブ、テナントの分離、プロバイダー ポリシー変更のプロセスが引き続き必要です。また、容量が断片化され、価格の一貫性が低下します。したがって、運用設計では、BYOK を隠れた実装の詳細としてではなく、独自の認証情報および課金モードとして扱う必要があります。
すべてを無効にすることなく、条件の変更と一時停止に対処します
プロバイダ契約、プログラム ドキュメント、製品条件、サポート対象国のリストを監視します。レビューされた文書の日付付きコピーまたはハッシュを保存し、重要な条項、購入チャネル、契約主体、または製品設計が変更された場合は再承認を必要とします。
一時停止ランブックは、次のような狭い制御をサポートする必要があります。
- プロバイダをグローバルに無効にすることなく、1 つのプロバイダ アカウントを無効にします。
- アカウントの対象ルートから 1 つのモデルまたはサービスを削除します。
- 承認済みの状態を維持したまま配信モードをブロックします。
- 影響を受ける顧客リージョンからのアドミッションを停止します。
- 対象となる顧客を認証情報を公開せずに BYOK に移行します。
- 影響を受ける顧客に通知し、以前のトラフィックに使用されたアドミッション証拠を保存します。
アカウントをプールすると、統合と請求の複雑さが軽減されますが、停止リスクがテナント全体に集中します。 BYOK はプロバイダーとの関係を分離しますが、オンボーディングとサポートの作業が増加します。認定再販プログラムでは、より明確な許可が提供される場合がありますが、プログラム規則、報告義務、または商業上の義務が課されます。これらは、単なるルーティング設定ではなく、ビジネス上のトレードオフです。
実装チェックリスト
- すべてのプロバイダー アカウントと購入チャネルをインベントリします。
- 顧客向け製品を配信モードごとに分類します。
- 曖昧な権限または交渉された権限については法的審査を受けます。
- 作成証拠に裏付けられたバージョン管理された権利レコード。
- 欠落または期限切れのレコードをフェールクローズします。
- プロバイダーの健全性、コスト、待ち時間の前に権利を評価します。
- アップストリームキーを転送する代わりにゲートウェイ資格情報を発行します。
- 顧客の地理を確認し、決定情報を保持します。
- BYOK を定義する請求と責任を明確にします。
- アカウント、モデル、地域、およびモード固有の停止制御をテストします。
- ライブ ルートをスケジュールに従って権利レジストリと照合します。
- 適用される制限を顧客条件とオンボーディング制御に組み込みます。
期待される内容next
予測: モデル カタログ、クラウド チャネル、エージェント サービス、および地域管理が拡大するにつれて、プロバイダの配布ルールはさらに細分化される可能性があります。アカウントおよび配信モード レベルで権利をエンコードするゲートウェイは、単一のプロバイダー対応フラグを中心に構築されたシステムよりも適応しやすくなります。これは設計上の予測であり、現在のプロバイダー ポリシーを表明するものではありません。
AI API アクセスを再販する前に、すべての運用ルートに対して、証拠とともに 1 つの質問に答えることを要求してください。どのような契約、アカウント、配信モード、地理的範囲に基づいてこのリクエストを処理できますか?システムがその答えを生成できない場合、ルートは顧客トラフィックに対応する準備ができていません。