OpenAI 互換 API：「そのまま置き換え可能」と呼ぶ前にテストすべきこと
リクエスト形状・レスポンス意味論・エラー・制限と、アプリケーションが実際に依存する機能のための実践的な互換性テスト。
互換性はインターフェースの話であり、すべての挙動の話ではない
OpenAI の公式リファレンスは、POST /chat/completions が会話メッセージを受け取り choices を含む chat completion を返すことを文書化しています。stop・length・content_filter・tool_calls といった finish reason も定義されています。これらのフィールドが互換性テストの具体的な基準線になります。
サードパーティのエンドポイントは、同じパスと主要フィールドを受け入れつつ、すべてのパラメータ・イベント・エラー・モデル能力・運用ルールが一致するとは限りません。「OpenAI 互換」というラベルは、交換可能なサービスの証明ではなく、アプリケーションの契約に対して検証すべき仮説として扱います。
アプリケーションが実際に使う経路をテストする
まず認証の拒否とモデルの一覧取得を確認し、次に最小の非ストリーミング completion を送ります。ステータスコード・コンテンツ位置・モデル値・利用する usage フィールド・finish reason を検証します。ストリーミングはアプリケーションが使う場合だけ繰り返し、イベントの終端と部分コンテンツの扱いを確認します。
次に、移行を壊しうる機能をテストします。システム指示、ツール呼び出し、JSON や構造化出力、画像入力、stop の挙動、トークン上限、キャンセルです。FreeToken.link の Models エリアは候補の特定に、Playground は本番コードを変える前にリクエストを試せる境界のある場所として使えます。
失敗もテストする
資格情報の欠落・無効なモデル・不正な入力・意図的に制約したリクエストという負のケースを実行します。アダプターには予測可能なステータスコードと解析可能なエラーが必要です。成功だけのデモでは、リトライ・フォールバック・ユーザー向けメッセージが正しく動くかは分かりません。
JSON が似ていても運用ルールは異なり得ます。Groq は複数の組織レベル制限次元、HTTP 429 応答、レート制限ヘッダーを文書化しています。互換性レビューでは、別の API から前提を引き継がず、プロバイダーの現在の制限範囲とリトライのシグナルを記録すべきです。
マトリクスで判断する
機能ごとに、無変更で合格・アダプター必要・非対応の 3 つの結果のいずれかを記録します。リクエストのフィクスチャとマスキングしたレスポンス例を添え、プロバイダー・SDK・モデルが変わったときに再実行できるようにします。
アプリケーションが必要とするすべての挙動が adaptation なしで合格する場合にだけ「そのまま置き換え可能」と呼びます。そうでなければ「非ストリーミングのテキストについて chat-completion 互換」のような、より狭い事実を述べ、そのルートを FreeToken.link の Watchlist に登録して今後の検証に備えます。
よくある質問
- Q. OpenAI 互換 API は OpenAI API と同じですか？／A. いいえ。似たインターフェースを実装していても、それだけでは同一の機能・レスポンス・制限・サービス挙動を意味しません。
- Q. 最小限で役に立つ互換性テストは？／A. 認証拒否、モデル一覧、最小の completion、利用するレスポンスフィールド、少なくとも 1 つの失敗ケースを検証します。
- Q. アダプターはいつ許容されますか？／A. 差異が明示され、テストされ、隔離されているときです。下層のエンドポイントを完全な drop-in 互換として見せるのではなく、アダプターを文書化します。
刊行上の開示
初稿は、公式ソースに基づく固定のファクトパックから、ローカルホストの basketikun/chatgpt2api ラッパーで生成されました。このラッパーは ChatGPT のウェブセッション経路を使うものであり、公式の OpenAI API ではありません。人間の編集者が保持した主張をリンク先リファレンスと突き合わせて確認し、公開前に成功・失敗・機能テストのマトリクスを加えました。