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

会話の状態

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

OpenAI は、会話の状態を管理する方法をいくつか提供しています。会話の状態の管理は、複数のメッセージやターンにわたって情報を保持するために重要です。

GPT-5.5 が途中の状況報告を最終回答として扱う問題を調べる際は、 連携実装でアシスタントメッセージの 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)

userassistant のメッセージを交互に並べることで、過去の会話の状態をモデルへの 1 回のリクエストに含められます。

生成されたレスポンス間でコンテキストを手動で共有するには、モデルの前回のレスポンスの出力を入力に含め、その入力を次のリクエストに追加します。

リーズニングモデルへのステートレスなリクエストでは、レスポンスの output 配列に含まれるすべての項目を保持してください。Responses API は、デフォルトで暗号化された推論項目を返します。出力全体を再度渡すことで、推論項目とアシスタントの phase 値をそのまま保持できます。推論の永続化をサポートするモデルでは、reasoning.context: "all_turns" を使用して、以前のターンで得られた利用可能な推論を次の生成に含められます。詳しくは、呼び出し間での推論の保持をご覧ください。

次の例では、モデルにジョークを話すよう依頼し、続けて別のジョークをリクエストします。このように過去のレスポンスを新しいリクエストに追加すると、以前のやり取りのコンテキストを保持し、自然な会話を続けやすくなります。

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 APIResponses 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,
)

前のレスポンスからのコンテキストの引き継ぎ

会話の状態を管理するもう 1 つの方法は、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)

次の例では、モデルにジョークを話すよう依頼します。その後、別のリクエストで、そのジョークがなぜ面白いのか説明を求めます。モデルには適切な回答に必要なコンテキストがすべて揃っています。

Responses API による会話の状態の手動管理
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 モードと同じですが、持続的なソケット接続上で response.create イベントを繰り返し送信します。

接続ごとのローカルキャッシュは、低レイテンシで会話を継続できるように、直近のレスポンスをメモリに保持します。stream_id を使用すると、各レーンで最新のレスポンスを保持できます。レスポンスの継承関係は引き続き previous_response_id によって決まるため、別のレーンのレスポンスが利用可能な間は、そのレスポンスからフォークして新しいレーンを作成できます。キャッシュされていない ID を解決できない場合は、previous_response_idnull に設定し、入力コンテキスト全体を渡して新しいターンを送信してください。

previous_response_id を使用する場合でも、連結されたレスポンスに含まれる過去の入力トークンはすべて、API の入力トークンとして課金されます。

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

コンテキストウィンドウを理解すると、スレッド形式の会話を作成し、モデルとのやり取り全体で状態を適切に管理しやすくなります。

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

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

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

  • 出力トークン は、モデルがプロンプトに応じて生成するトークンです。出力トークン数の上限はモデルごとに異なります。たとえば、gpt-4o-2024-08-06 は最大 16,384 の出力トークンを生成できます。
  • コンテキストウィンドウ は、入力トークンと出力トークン(一部のモデルでは推論トークンも含みます)に使用できるトークンの総数を表します。モデルごとのコンテキストウィンドウの上限を比較してください。たとえば、gpt-4o-2024-08-06 のコンテキストウィンドウは合計 128k トークンです。

モデルに渡すコンテキスト、データ、例などを追加してプロンプトが大きくなると、モデルに割り当てられたコンテキストウィンドウを超えるおそれがあり、出力が途中で切れる可能性があります。

テキストに含まれるトークン数を確認するには、tiktoken ライブラリで構築されたトークナイザーツールを使用してください。

たとえば、o1 モデルのような推論が有効なモデルで Responses API に API リクエストを送信する場合、次のトークン数がコンテキストウィンドウの合計に算入されます。

  • 入力トークン(Responses APIinput 配列に含める入力)
  • 出力トークン(プロンプトに応じて生成されるトークン)
  • 推論トークン(モデルがレスポンスを計画するために使用するトークン)

コンテキストウィンドウの上限を超えて生成されたトークンは、API レスポンスで切り捨てられる場合があります。

コンテキストウィンドウの可視化

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

コンパクション

コンパクションの詳しいガイダンスは、現在 コンパクションに掲載されています。

次のステップ

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