Reasoning best practices は「考えてと書けば賢くなる」を止めに来ている

要点

要点まとめ

この guide の一番大事な点は、モデルに「もっと考えて」と書くことと、複数手順のあいだで必要な考えの続きを残すことは別だと示していることだ。
単発の質問なら大げさな工夫がいらない場面もあるが、tool をまたぐ仕事では「前の判断を次へ持ち越せるか」が効く。
OpenAI はそのために、推論モデルへの指示をむやみに飾るより、主命令の置き場と状態の持ち方を整えろと勧めている。
読後にやるべきことは、自分の workflow を「その場で終わる質問」と「途中状態を持ち越す仕事」に分けることだ。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 作る前に確認したい

API や設定を試す前に、先に落とし穴を知りたい人向け。

同じテーマで読む LLM API

Responses API、Gemini API、モデル更新、構造化出力、SDK。

次の記事 GPT-Realtime-2 は、音声UIを「会話」から実行ワークフローへ寄せる

OpenAI は GPT-Realtime-2、GPT-Realtime-Translate、GPT-Realtime-Whisper という音声向け API モデル群を発表した。

読解

何が変わったのか

guide は `reasoning model` を内部で多段の推論を進める前提の model として扱い、`think step by step` や `explain your reasoning` のような演出用指示を推奨していません。次に、`developer message` を system message 相当の主命令の置き場として明示しています。さらに重要なのは、`Responses API` を前の応答や推論状態を持ち越しやすい経路として使う話です。`o3` と `o4-mini` では function call に隣接した `reasoning items` を文脈へ含めて性能改善に使う一方、Chat Completions は stateless なので複数 function call をまたぐケースで token 使用量と性能の面で不利になりうるとされています。

日本の文脈

なぜ重要か

日本語圏では reasoning が「賢い model を選ぶ話」か「丁寧な prompt の書き方」に縮みやすいです。しかし実運用では、どの workflow が本当に reasoning continuity を必要とするかを分けないと、コストだけ増えて成果が安定しません。特に engineer にとって重要なのは、reasoning を model の能力論から execution architecture の話へ戻せる点です。単発 QA は stateless でもよいが、tool-heavy workflow は stateful に寄せる。ここを分けるだけで API 選定、token 予算、ログの持ち方が変わります。

技術ポイント

技術的ポイント

reasoning model は内部で reasoning するため、`think step by step` のような chain-of-thought 誘導は不要で、時に逆効果になりうる。
`developer message` は reasoning model に対する主命令の置き場で、制約や出力形式を user message に寄せすぎないほうが安定する。
Responses API では `store=true` と `reasoning items` の継続渡しにより、複雑な function-calling workflow の性能と token 効率を改善しやすい。
Chat Completions は stateless なので reasoning items を文脈へ含められず、複数 function call をまたぐ agent loop ではこの差が効く。

用語

英日キーワード

英語	日本語	補足
reasoning model	推論モデル	複雑な問題で内部推論に多くの計算を使うモデル。速度・費用と正答率のトレードオフを明示して使う。
developer message	開発者メッセージ	system message 相当の主命令の置き場。user prompt と別に durable な制約を書く層。
chain-of-thought prompt	思考手順を明示させる指示	step by step のような推論誘導。reasoning model では不要または逆効果になりうる。
reasoning items	推論状態アイテム	前回までの reasoning の一部を次へ渡すための項目。
stateful	状態保持あり	途中状態を次の呼び出しへ持ち越す設計。
stateless	状態保持なし	各呼び出しが独立している設計。

試す

試すなら

自分の prompt に `step by step` や過剰な思考指示がないか確認し、まず削って比較する。
workflow を「単発回答」と「複数 tool call をまたぐもの」に分ける。
後者だけ Responses API で reasoning continuity を持たせ、`previous_response_id` や output items の継続を試す。
token 使用量だけでなく、function call 後の取りこぼし、再説明回数、誤判定率も比較する。

注意

注意点

すべての task に stateful 設計が必要だとは言っていない。単純タスクでは複雑化のほうが損になりうる。
reasoning continuity を持つほどログや保存データも増えるため、保存ポリシーや監査要件を後回しにしないほうがよい。
`Published date` は docs page 上で確認できなかった。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。