推論モデルの労力(Reasoning Effort)の制御 (Chat Completions)
エンドポイントの説明
プロンプトが与えられると、モデルは1つまたは複数の予測される補完応答を返します(推論モデルの思考の労力(reasoning effort)の制御をサポートします)。
- 公式ドキュメントリファレンス:OpenAI Reasoning Guides
- エンドポイントのステータス:
リリース済み (released)
リクエスト仕様
- HTTPメソッド:
POST - リクエストURL:
https://api.codingplanx.ai/v1/chat/completions
リクエストヘッダー (Headers)
| パラメータ名 | 必須 | データ型 | サンプル値 | 説明 |
|---|---|---|---|---|
Content-Type | 必須 | string | application/json | データフォーマット |
Accept | 必須 | string | application/json | 受信フォーマット |
Authorization | 任意 | string | Bearer {{YOUR_API_KEY}} | 認証情報(クレデンシャル) |
リクエストボディパラメータ (Body)
データフォーマット:application/json
| パラメータ名 | 必須 | データ型 | 説明 |
|---|---|---|---|
model | 必須 | string | 使用するモデルのID(例:o4-mini など)。 |
messages | 必須 | array | これまでの会話を構成するメッセージのリスト。role(user/assistantなど)と content(メッセージ内容)を含みます。 |
tools | 必須 | array | モデルが呼び出せるツール(関数)のリスト。モデルがJSON入力を生成できる関数を提供するために使用します。 |
tool_choice | 必須 | object | モデルがどの関数を呼び出すかを制御します。none は呼び出さないこと、auto は自動選択を意味します。 |
reasoning_effort | 任意 | string | コアパラメータ:応答生成時の推論モデルの労力(思考の深さ)を制御します。一般的な選択肢は low、medium、high です。 |
temperature | 任意 | number | サンプリング温度。0から2の間で指定します。高い値(例:0.8)は出力をよりランダムにし、低い値(例:0.2)はより集中的で決定論的にします。top_p との併用ではなく、どちらか一方のみを変更することを推奨します。 |
top_p | 任意 | number | ヌクレアスサンプリング(Top-pサンプリング)。0.1は上位10%の確率質量を構成するトークンのみを考慮することを意味します。temperature との併用ではなく、どちらか一方のみを変更することを推奨します。 |
n | 任意 | integer | デフォルトは1。各入力メッセージに対して生成するチャット補完の選択肢の数。 |
stream | 任意 | boolean | デフォルトはfalse。trueに設定すると、Server-Sent Events (SSE) 形式でメッセージの差分(チャンク)をストリーム送信し、data: [DONE] でストリームを終了します。 |
stop | 任意 | string | APIがトークンの生成を停止する最大4つの文字列シーケンス。 |
max_tokens | 任意 | integer | チャット補完で生成される最大トークン数。入力トークンと生成トークンの合計長は、モデルのコンテキスト長の制限を受けます。 |
presence_penalty | 任意 | number | -2.0から2.0の間の数値。正の値は、新しいトークンがテキスト内に既に存在するかどうかに基づいてペナルティを与え、モデルが新しいトピックについて話す可能性を高めます。 |
frequency_penalty | 任意 | number | -2.0から2.0の間の数値。正の値は、これまでのテキストにおける頻度に基づいて新しいトークンにペナルティを与え、同じ内容を繰り返す可能性を低下させます。 |
logit_bias | 任意 | object | トークンIDをバイアス値(-100から100)にマッピングするJSONオブジェクトを受け入れ、指定されたトークンが補完に現れる可能性を変更するために使用します。 |
user | 任意 | string | エンドユーザーを表す一意の識別子。システムによる乱用の監視と検出に役立ちます。 |
response_format | 任意 | object | モデルが出力しなければならないフォーマットを指定します。例えば {"type": "json_object"} はJSONモードを有効にします。 |
seen | 任意 | integer | ベータ版機能(seedに類似)。指定すると、システムは可能な限り決定論的にサンプリングを行い、同じパラメータで同じ結果が返るようにベストエフォートで試みます。 |
リクエストサンプル
{
"model": "o4-mini",
"max_tokens": 500,
"messages": [
{
"role": "user",
"content": "こんにちは、量子コンピューティングの原理について詳しく説明してください。"
}
],
"temperature": 1.0,
"stream": false,
"reasoning_effort": "medium"
}
レスポンス仕様
レスポンスボディパラメータ
データフォーマット:application/json
| パラメータ名 | データ型 | 説明 |
|---|---|---|
id | string | このリクエストの一意の識別子。 |
object | string | オブジェクトタイプ。通常は chat.completion。 |
created | integer | 作成時のUnixタイムスタンプ。 |
choices | array | 補完結果のリスト。 |
└ index | integer | リスト内における現在の選択肢のインデックス。 |
└ message | object | モデルによって生成された応答メッセージの本体。role と content を含みます。 |
└ finish_reason | string | 生成が停止した理由(例:stop, length)。 |
usage | object | トークン消費量の統計。 |
└ prompt_tokens | integer | プロンプトで消費されたトークン数。 |
└ completion_tokens | integer | モデルの生成で消費されたトークン数。 |
└ total_tokens | integer | 合計消費トークン数。 |
レスポンスサンプル (HTTP 200 OK)
{
"id": "chatcmpl-123",
"object": "chat.completion",
"created": 1677652288,
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "\r
\r
Hello there, how may I assist you today?"
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 9,
"completion_tokens": 12,
"total_tokens": 21
}
}
FAQ(よくある質問)
1. reasoning_effort パラメータの役割は何ですか?
reasoning_effort は、高度な推論機能(Reasoning)を持つモデル(OpenAIのo1/o4シリーズなど)が、最終的な回答を出す前にどれだけの計算リソースと時間を費やして内部的な思考を行うかを制御するために使用します。通常、low、medium、high の3つのレベルをサポートします。high に設定すると、モデルはより深い論理的推論を行い、複雑な数学やプログラミングの問題解決に適していますが、それに応じて応答時間も増加します。
2. stream: true を有効にすると、標準のJSONレスポンスが受信されないのはなぜですか?
ストリーミング(stream: true)を有効にすると、APIはServer-Sent Events(SSE)プロトコルを使用してデータチャンク(Chunks)を継続的に返します。各チャンクは data: {...} の形式で送信され、すべてのコンテンツの送信が完了すると、data: [DONE] というメッセージが送信されます。開発者は、完全な応答を構築するために、1行ずつ読み取り、data: に続くJSON文字列を解析して結合する必要があります。
3. ドキュメントでは temperature と top_p のどちらか一方のみを変更することが推奨されていますが、なぜですか?
これら2つのパラメータは、モデルの出力内容のランダム性と多様性を制御するために使用されます。temperature はロジットをスケーリングすることで確率分布を変化させ、top_p(ヌクレアスサンプリング)は累積確率が低い語彙を切り捨てることで候補プールを制限します。これら2つのパラメータを同時に調整すると、モデルの動作が予測・制御しにくくなるため、ベストプラクティスは一方を固定(通常はデフォルトのまま)し、ランダム性の制御要件を満たすためにもう一方のみを調整することです。
4. finish_reason が "length" を返した場合、どういう意味ですか?
これは、モデルの応答が強制的に切り捨てられたことを意味します。原因は通常2つあります。1つ目は、生成されたトークン数がリクエストパラメータで設定された max_tokens の上限に達したこと。2つ目は、リクエストのプロンプト(Prompt)とモデルが生成した応答の合計トークン数が、該当モデルで許可されている最大コンテキストウィンドウ制限を超えたことです。この場合、過去の会話履歴を短くするか、max_tokens パラメータを増やすことをお勧めします。
5. モデルにJSON形式のデータを強制的に返させるにはどうすればよいですか?
リクエストボディに "response_format": {"type": "json_object"} を渡すことで、JSONモードを有効にできます。非常に重要:このモードを有効にすると同時に、messages(通常はsystemまたはuserプロンプト内)において、モデルにJSONを出力するように自然言語で明示的に指示する必要があります。そうしないと、モデルはトークン制限に達するまで空白文字を無限に生成する無限ループに陥る可能性があります。