メインコンテンツへスキップ
OpenAI、Google Gemini、DeepSeek、Qwenなど各社のテキストモデルを、OpenAI Chat Completionsという1つのインターフェースで呼び出せます。messages を送り、choices[0].message.content から回答を読み取ります。 任意パラメーターとツールへの対応はモデルによって異なります。アプリケーションがAnthropic MessagesやGeminiの generateContent のリクエスト構造で作られている場合は、ClaudeプロトコルまたはGeminiプロトコルのページを参照してください。3つの形式の比較は、テキスト生成APIのガイドにあります。

リクエストを送る

トークン管理でAPIキーを作成します。課金方式は、従量優先(推奨。コンソールの表示は「按量优先」)または従量課金(「按量计费」)にしてください。作成したキーは、ターミナルで環境変数に設定します。
リクエストは Authorization: Bearer で認証し、本文は model と messages を含むJSONにします。例では gpt-5.4-mini を使います。
このプロンプトなら、connected が返ります。クライアントの設定を確認できたら、プロンプトを自分のアプリケーションのメッセージに置き換えてください。

モデルを選ぶ

モデルはモデルカタログから選びます。model の値を変える前に、そのモデルの行で次の3点を確認してください。
  • Endpoints にOpenAI-compatibleが含まれていること。o3-pro シリーズのようにResponsesだけが表示されているモデルは、代わりに /v1/responses を使います。API接続ガイドのResponses APIの例を参照してください。
  • Token groups に、自分のAPIキーのグループが含まれていること。
  • 1Mトークンあたりの Input、Output、Cache read の価格が、用途に合っていること。
カタログにある代表的なテキストモデルは次のとおりです。
  • gpt-5.4-mini と gpt-5.4
  • gemini-3.8-flash、gemini-3.6-flash、gemini-3.5-flash-lite
モデルIDは、製品名から組み立てずに、カタログまたはコンソールから正確にコピーしてください。これらのモデルの形式と価格はテキスト生成APIのガイドに、Responses専用の o3-pro の呼び出し方はOpenAIモデルにあります。 一般的なランキングだけでは、アプリケーションに合うモデルはわかりません。自分のプロンプトのサンプルを2〜3個の候補モデルに通し、次の点を比べてください。
  • 回答の品質と、指示への従い方
  • 構造化出力の安定性。ツールを使う場合は、ツール呼び出しの成功率も
  • レイテンシと、各リクエストに記録されるトークン使用量
選んだモデルのIDは設定ファイルなどに固定し、モデルの変更を意図的な更新にしてください。

リクエストのフィールド

まずは model と messages だけで始めてください。任意フィールドと指定できる値はモデルによって異なります。未対応のパラメーターで拒否されたリクエストは、フィールドを直してから再送します。上流のフィールド定義は、OpenAI公式のChat Completionsリファレンスを参照してください。

メッセージと会話履歴

各メッセージには role と content があります。ユーザーの入力は user、モデルの過去の回答は assistant で表します。アプリケーションに必要な履歴は、リクエストのたびに送ってください。
system や developer などの指示用ロール、ツールメッセージ、マルチモーダルの内容は、選んだモデルによって異なります。ビジョンモデルに画像を送る方法は、画像理解APIを参照してください。

レスポンスを読み取る

テキストのレスポンスには choices 配列が含まれます。読み取るフィールドだけを残した例です。
回答は message.content から、生成が終わった理由は finish_reason から読み取ります。finish_reason が length なら、回答が出力上限またはコンテキスト上限に達しています。完全な回答が必要なときは、入力を短くするか、モデルが対応する出力上限を調整してください。 ツール呼び出しに対応するモデルでは、通常のテキストの代わりに message.tool_calls が返ることがあります。会話を続けるときは、その呼び出しと対応する結果を残してください。トークン数は usage に含まれることがあります。アカウントの課金額は、呼び出しログで確認します。

レスポンスをストリーミングする

"stream": true を追加すると、モデルが書いた順に、回答を細かく分けて受け取れます。レスポンスはserver-sent eventsのストリームです。
  • 各 data: 行に chat.completion.chunk オブジェクトが入ります。
  • 新しいテキストは choices[0].delta.content に入ります。
  • ストリームは data: [DONE] の行で終わります。
-N を付けると、cURLの出力バッファリングが無効になり、チャンクが届くたびに表示されます。
生のストリームは次のような形です。必要なフィールドだけに省略しています。実際のチャンクには id や model などのフィールドも含まれます。
ストリームを読み取るときの注意点です。
  • delta.content を順に連結すると、回答全体を再構成できます。
  • 最初のチャンクにはロールだけが入っていることがあります。また、最後の使用量のチャンクなど、choices が空配列のチャンクもあるため、読み取る前に確認してください。
  • 最後の内容チャンクに finish_reason が設定され、続く data: [DONE] でストリームが閉じます。Python SDKはこの時点でループを終了します。
  • [DONE] の前に接続が切れた場合は、回答が途中で終わったものとして扱ってください。

エラーへの対処

クライアント側でタイムアウトしたときは、再送する前に、そのリクエストが呼び出しログに記録されているか確認してください。Pythonの例ではSDKの自動リトライを無効にしています。リトライ処理は、アプリケーション側で意図して実装してください。 サポートに連絡するときは、リクエストの時刻、エンドポイント、モデル、トークングループ、認証情報を伏せたエラーメッセージを添えてください。APIキーは送らないでください。

関連ドキュメント