1) 用語
Vendor:実際にモデル推論を実行する元プロバイダー。 Authorized Vendors:当社が統合・審査し、トラフィックをルーティングし得るプロバイダー。 Model:呼び出し可能な具体的モデルインスタンス(例:Model X vY)。 Request:単一の推論/API 呼び出し。 Vendor Status:ベンダーの運用状態(例:healthy / degraded / unavailable)。2) モードと可用性の境界
ピン留めモード(vendor を明示)
指定 Vendor が利用不能(“down”)の場合、そのリクエストの利用不能や失敗について当社は責任を負いません。自動モード(vendor=auto、Authorized Vendors 間でルーティング)
当該モデルの すべての Authorized Vendor が利用不能(“down”)の場合、その結果の利用不能や失敗について当社は責任を負いません。
状態判定:ベンダー公開のステータス/告知と当社モニタリング(エラー率/タイムアウト等)を組み合わせます。双方ログの突合も行う場合があります。
3) レスポンスヘッダ検証(stream:false のみ)
非ストリーミング(stream:false)では、実際に応答した Vendor/アカウントの確認のため検証ヘッダを付与します。
X-Vendor-Messages-Id— マスクなし。ベンダーのmessages_idと同一で、突合・追跡に使えます。認証情報ではなく、呼び出し権限を与えるものではありません。X-Vendor-Api-Key— 当該リクエストで使用したベンダーapi_keyからマスク/一方向変換した値。検証/監査用途のみで、呼び出しに利用できません。
stream:true(ストリーミング)では、これらのヘッダは含まれないか空になることがあります。それ自体が侵害や不一致を意味しません。ストリーミングで検証が必要な場合はリクエスト ID を提出いただき、サーバ側ログとベンダー証跡で監査します。
セキュリティと保持
次のみ 3 日間保持します。- 当社内部のリクエスト ID
- 上記検証レスポンスヘッダ
api_key は保持しません。ログにはマスクまたは一方向表現のみが現れます。
X-Vendor-Messages-Id は秘密ではなく、認証や二次呼び出しに使えません。
プロキシ/CDN を利用する場合、X-Vendor-* が剥がされないよう許可/保持してください。
非ストリーミング例
4) モデル一貫性と不一致の扱い
一貫性要件:レスポンス(またはメタデータ)のvendor は、実際に応答した Vendor と一致している必要があります。
不一致の判定(いずれか)
- レスポンスの vendor 値が実際の応答 Vendor と異なる
stream:falseで、検証ヘッダと当社ルーティングログ/ベンダー証跡が整合しない(事前の書面承認付き例外を除く)
救済と補償
確認された「モデル不一致」は、当該リクエスト料金の 2 倍を補償します(既定はクレジット/請求相殺。契約または書面合意により現金も)。 証跡と手続:リクエスト ID、タイムスタンプ、生レスポンス(ヘッダ含む、取得できる場合)を提出ください。検証ヘッダに加え、サーバ側ルーティングログとベンダー証跡/課金記録で確認します。 ヘッダ欠落/異常(非ストリーミング):ベンダー制約やメンテナンスで一時的に欠落する場合、同等の証跡(ベンダー領収 ID、課金記録、署名付き証明、サーバログ等)を提供します。合理的期間内に同等証跡を提供できず、お客様資料が完備されている場合、不一致と推定し 2 倍補償が適用される場合があります。5) 代表的な呼び出し
ピン留め Vendor
自動ルーティング
6) FAQ
Q: ストリーミングはどう検証しますか? A:stream:true では検証ヘッダは付きません。リクエスト ID を添えてチケットを起票ください。ルーティングログとベンダー証跡で監査します。
Q: ベンダーダウンなら常に免責ですか?
A: ピン留めで選択 Vendor がダウンしている場合、そのリクエストの利用不能については責任を負いません。自動モードで当該モデルの Authorized Vendor がすべてダウンの場合も同様です。
Q: X-Vendor-Messages-Id は漏洩しませんか?
A: いいえ。追跡/突合用 ID であり認証情報ではありません。X-Vendor-Api-Key は不可逆にマスクされます。