For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme

会話の状態

モデルとのやり取りで会話の状態を管理する方法を説明します。

OpenAI では、会話の状態を管理する方法をいくつか用意しています。会話の状態を管理すると、複数のメッセージやターンにわたって情報を引き継げます。

GPT-5.5 が途中経過の報告を最終回答として扱う場合は、API との連携処理でアシスタントメッセージの phase フィールドを正しく保持しているか確認してください。詳しくは、フェーズパラメーターを参照してください。

会話の状態の手動管理

テキスト生成リクエストはそれぞれ独立しており、状態を保持しません。それでも、過去のメッセージをリクエストのパラメーターに含めれば、複数ターンの会話を実装できます。「コンコン」「どなたですか?」という掛け合いで始まるジョークを例に見てみましょう。

過去の会話を手動で再現する例
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input=[
        {"role": "user", "content": "knock knock."},
        {"role": "assistant", "content": "Who's there?"},
        {"role": "user", "content": "Orange."},
    ],
)

print(response.output_text)

user と assistant のメッセージを交互に並べると、それまでの会話の状態を 1 回のリクエストでモデルに渡せます。

生成した応答のコンテキストを手動で引き継ぐには、モデルの前回の応答に含まれる出力を、次のリクエストの入力に追加します。

リーズニングモデルにステートレスなリクエストを送る場合は、応答の output 配列に含まれるすべての項目を保持してください。Responses API はデフォルトで暗号化された推論項目を返します。出力をすべて次のリクエストに渡すことで、推論項目とアシスタントの phase の値をそのまま引き継げます。推論の永続化に対応するモデルでは、reasoning.context: "all_turns" を指定すると、以前のターンでの推論のうち利用可能なものを次の生成時に取り込めます。詳しくは、呼び出し間での推論の保持を参照してください。

推論項目を次のリクエストに渡すときは、その項目の生成に使われた会話履歴もそのまま保持してください。会話履歴を編集すると推論にどのような影響があるかについては、プレフィックスを変更せずに保持するを参照してください。

次の例では、モデルにジョークを 1 つ頼み、続けて別のジョークを頼みます。このように前の応答を新しいリクエストに追加すると、それまでのやり取りを踏まえて自然に会話を続けられます。

Responses API を使った会話の状態の手動管理
from openai import OpenAI

client = OpenAI()

history = [{"role": "user", "content": "tell me a joke"}]

response = client.responses.create(
    model="gpt-6-astra",
    input=history,
    store=False,
)

print(response.output_text)

# Add all response output items, including encrypted reasoning items, to the conversation
history += response.output

history.append({"role": "user", "content": "tell me another"})

second_response = client.responses.create(
    model="gpt-6-astra",
    input=history,
    store=False,
)

print(second_response.output_text)

会話の状態を管理する OpenAI API

OpenAI の API を使うと、会話の状態を自動で管理できるため、ターンごとに入力を手動で渡す必要がなくなります。

Conversations API の利用

Conversations API は Responses API と連携し、会話の状態を固有の永続的な識別子を持つオブジェクトとして長期にわたって保持します。作成した会話オブジェクトは、セッション、デバイス、ジョブをまたいで使い続けられます。

会話には、メッセージ、ツール呼び出し、ツールの出力などのデータが項目として保存されます。

会話の作成
conversation = openai.conversations.create()

複数ターンのやり取りでは、後続の応答を生成するときに conversation を渡すと、状態が保持され、その後の応答でもコンテキストを共有できます。複数の応答項目を自分でつなぐ必要はありません。

Conversations API と Responses API による会話の状態管理
response = openai.responses.create(
    model="gpt-6-astra",
    input=[{"role": "user", "content": "What are the 5 Ds of dodgeball?"}],
    conversation=conversation.id,
)

前回の応答からのコンテキストの引き継ぎ

会話の状態は、previous_response_id パラメーターを使って、生成した応答間でコンテキストを共有する方法でも管理できます。このパラメーターで応答を順につなぐと、一連のやり取りを会話のスレッドとして扱えます。

前回の応答 ID を使ったターン間の応答の連結
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="tell me a joke",
)
print(response.output_text)

second_response = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=response.id,
    input=[{"role": "user", "content": "explain why this is funny."}],
)
print(second_response.output_text)

WebSocket モードでの previous_response_id

Responses API の WebSocket モードでも、会話を続けるときの previous_response_id の働きは HTTP モードと同じです。WebSocket モードではソケット接続を維持し、その接続で response.create イベントを繰り返し送信します。

接続ごとのキャッシュは直近の応答をメモリに保持するため、少ない待ち時間で会話を続けられます。stream_id を使うと、各レーンで最新の応答を保持できます。どの応答から会話が続くかは引き続き previous_response_id で決まるため、別のレーンの応答が利用可能な間は、その応答から新しいレーンをフォークできます。キャッシュにない ID を解決できない場合は、previous_response_id を null に設定し、入力コンテキスト全体を含めて新しいターンを送信してください。

previous_response_id を使う場合も、一連の応答でそれまでに使用した入力トークンは、すべて API の入力トークンとして課金されます。

コンテキストウィンドウの管理

コンテキストウィンドウの仕組みを理解しておくと、会話のスレッドを作成し、モデルとのやり取りを通じて状態を管理しやすくなります。

コンテキストウィンドウは、1 回のリクエストで使用できるトークン数の上限です。この上限には、入力トークン、出力トークン、推論トークンが含まれます。使用するモデルのコンテキストウィンドウの大きさは、モデルの詳細で確認できます。

テキスト生成時のコンテキスト管理

入力が複雑になったり、会話に含めるターンが増えたりすると、出力トークンとコンテキストウィンドウの両方の上限を考慮する必要があります。モデルの入出力量はトークン単位で計測されます。モデルは入力をトークンに分解して内容や意図を分析し、トークンを組み合わせて筋の通った出力を生成します。1 回のテキスト生成リクエストの処理中に使用できるトークン数には、モデルごとに上限があります。

  • 出力トークンは、プロンプトに応じてモデルが生成するトークンです。出力トークン数の上限はモデルによって異なります。たとえば、gpt-4o-2024-08-06 は最大 16,384 トークンを出力できます。
  • コンテキストウィンドウは、入力と出力に使用できるトークンの合計数の上限です。モデルによっては推論トークンもこの合計に含まれます。モデルごとのコンテキストウィンドウの上限を比較できます。たとえば、gpt-4o-2024-08-06 のコンテキストウィンドウは合計 128,000 トークンです。

モデルに渡すコンテキストやデータ、例などを追加してプロンプトが大きくなると、モデルのコンテキストウィンドウの上限を超え、出力が途中で切れることがあります。

トークナイザーツールは tiktoken ライブラリを使って構築されており、任意の文字列のトークン数を確認できます。

たとえば、Responses API に o1 モデルなどの推論に対応したモデルを指定してリクエストを送ると、次のトークン数がコンテキストウィンドウの合計に算入されます。

  • 入力トークン(input 配列に含めて Responses API に渡す入力)
  • 出力トークン(プロンプトに応じて生成されるトークン)
  • 推論トークン(モデルが応答を組み立てるために使うトークン)

生成されたトークンのうち、コンテキストウィンドウの上限を超えた分は、API の応答で切り捨てられることがあります。

コンテキストウィンドウの内訳を示す図

メッセージで使用するトークン数は、トークナイザーツールで見積もれます。

コンパクション

コンパクションの詳しい手順は、コンパクションのガイドに掲載しています。

次のステップ

より具体的な例やユースケースは OpenAI Cookbook をご覧ください。API を使ってモデルの機能を拡張する方法は、次のガイドで説明しています。