多くの大規模モデルサービスは「OpenAI 互換」の API を提供しています。実際に接続するとき、まず確認すべきことは 2 つです。
BASE_URL: サービス提供者が用意した API アドレス。OPENAI_API_KEY: あなたのアクセスキー。
サービスが Chat Completions API と互換であれば、リクエストの形は通常 OpenAI の /v1/chat/completions に近くなります。ただし、OpenAI は現在 Responses API も推進しています。Chat Completions は今でもよく使われ、特にサードパーティの互換 API では一般的ですが、OpenAI 公式の機能を直接使う新規プロジェクトでは Responses API も確認しておくべきです。
公式参考:
最小リクエスト例
最小の Chat Completions リクエストは、おおよそ次のようになります。
|
|
サードパーティの OpenAI 互換サービスを使う場合、通常は 1 行目を相手の BASE_URL に置き換えるだけです。
|
|
間違いやすい点は 3 つあります。
BASE_URLに/v1を多く付けたり、逆に付け忘れたりする。AuthorizationにBearerを付け忘れる。- サービス側が実際には対応していない
modelを指定する。
リクエストボディで重要なフィールド
Chat Completions のリクエストボディは JSON オブジェクトです。基本的でよく使うフィールドは次のとおりです。
model
model は必須フィールドで、呼び出すモデル ID を指定します。
|
|
OpenAI 互換のサードパーティサービスでは、モデル ID が gpt-4o-mini とは限りません。deepseek-chat、qwen-plus、llama-3.1-70b のような独自のモデル名を使うサービスもあります。ここはサービス提供者のドキュメントやモデル一覧に従ってください。
messages
messages は必須フィールドで、最初から現在までの会話履歴を表します。配列で、各要素が 1 つのメッセージです。
よく使う role は次のとおりです。
system: アシスタントの振る舞いを定義するシステム指示。user: ユーザーのメッセージ。assistant: モデルの前回までの応答。tool: ツール呼び出しの結果。
単純な複数ターンの会話は次のように書けます。
|
|
system message
system メッセージは通常先頭に置き、モデルにどの役割を担うべきか、どの規則に従うべきかを伝えます。
|
|
主なフィールド:
role:system固定。content: システムプロンプトの内容。name: 任意。参加者名を示すために使います。
互換サービスがすべて同じ system behavior を実装しているとは限りません。システムプロンプトが効いていないように見える場合は、まずサービス側が role の扱いを変更していないか確認します。
user message
user メッセージはユーザー入力を表します。最も一般的なのはテキストです。
|
|
マルチモーダル入力をサポートするモデルでは、content を配列にして、テキストと画像を同時に渡すこともできます。
|
|
互換 API が画像をサポートするかどうかは、具体的なモデルによります。エンドポイントの形が OpenAI 互換だからといって、必ずマルチモーダルに対応しているとは限りません。
assistant message
assistant メッセージは通常、複数ターンの履歴に含め、モデルが以前に何を返したかを表します。
|
|
モデルがツール呼び出しを選ぶ場合、assistant メッセージには通常のテキストではなく tool_calls が入ることがあります。
tool message
tool メッセージは、ツールの実行結果をモデルに返すために使います。前の assistant メッセージ内のいずれかの tool_calls.id に対応している必要があります。
|
|
これは Agent シナリオでよく使います。モデルがまず呼び出す関数を決め、アプリケーションが実際にその関数を実行し、その結果を tool メッセージとしてモデルに返し、モデルが最終回答を生成します。
tools と tool_choice
tools は、モデルが呼び出せるツールを伝えるために使います。最も一般的なのは関数ツールです。
天気を問い合わせる例です。
|
|
モデルがツールが必要だと判断すると、レスポンスに次のような内容が含まれることがあります。
|
|
ここで重要なのは 2 点です。
- モデルは「関数を呼ぶべきだ」と提案しているだけで、あなたのプログラムの代わりに本当に関数を実行するわけではありません。
argumentsはモデルが生成した JSON 文字列です。使う前に必ず検証してください。
tool_choice はモデルがツールを呼び出すかどうかを制御します。
"none": ツールを呼ばず、テキストだけを生成する。"auto": テキスト生成かツール呼び出しかをモデルに選ばせる。"required": 1 つ以上のツール呼び出しを要求する。- 特定の関数を指定: 具体的なツール呼び出しを強制する。
旧 API の functions と function_call は、tools と tool_choice に置き換えられています。古いプロジェクトを保守しているとまだ見かけるかもしれませんが、新しいコードでは新しい書き方を優先するのがおすすめです。
stream ストリーミング出力
stream は任意の boolean 値です。true にすると、API は SSE で内容を少しずつ返します。リアルタイムチャット UI に向いています。
|
|
非ストリーミング応答は、モデルが最後まで生成してからまとめて返します。ストリーミング応答は chunk を継続的に返します。典型的な断片は次のようになります。
|
|
フロントエンドまたはバックエンドは data: 行を読み続け、それぞれの delta.content を連結し、[DONE] を受け取ったら終了します。
非ストリーミング応答の読み方
非ストリーミングの Chat Completions 応答には、通常次のようなフィールドが含まれます。
|
|
よく使うのは次のフィールドです。
choices[0].message.content: モデルの最終応答。choices[0].message.tool_calls: モデルが呼び出したいツール。choices[0].finish_reason: 停止理由。usage: token 使用量。
finish_reason のよくある値:
stop: 自然停止。length: token 上限に到達。tool_calls: モデルがツール呼び出しを要求。content_filter: 内容がフィルタリングされた。
互換 API 接続時のチェックリスト
サードパーティの OpenAI 互換サービスに接続するときは、パスが同じかどうかだけで判断しないほうが安全です。次の項目を確認しましょう。
BASE_URLに/v1が含まれているか。OPENAI_API_KEYが現在のサービス提供者に対応しているか。modelが有効なモデル ID か。systemメッセージをサポートしているか。- マルチモーダル
image_urlをサポートしているか。 toolsとtool_choiceをサポートしているか。stream: trueをサポートしているか。- token 制限フィールドが
max_completion_tokensか、古いmax_tokensか。 - エラー応答の形式が OpenAI と完全に同じか。
- 追加のレート制限、同時実行制限、地域制限があるか。
「OpenAI 互換」は通常、呼び出し方が似ているという意味です。すべてのモデル能力、フィールドの意味、エラー形式が完全に同じという意味ではありません。
結論
最も基本的なチャット用途だけなら、Chat Completions の中心フィールドは実質的に 3 つです。
|
|
Agent や業務自動化を作るなら、さらに次を理解する必要があります。
tools: 使える関数をモデルに伝える。tool_choice: モデルがツールを呼ぶかどうかを制御する。tool_calls: モデルが何を呼びたいかを読み取る。toolmessage: 実際のツール結果をモデルに返す。stream: 応答をリアルタイム出力にする。
OpenAI 互換 API では、まず最小のテキストリクエストを通し、次にストリーミングを追加し、最後にツール呼び出しを接続するのが最も安全です。能力を 1 つ追加するたびに、本物のモデルと本物のサービス提供者で検証してください。フィールド名だけで互換性を推測しないことが大切です。