情報確認日：2026年10月15日
ストリーミングで回答の一部が届いても、回答全体の完成とは限りません。OpenAIのResponses APIでは、文字の追加を示すイベントと、回答全体の完了・失敗・未完了を示すイベントを分けて扱います。途中の文章を表示できたことだけで、完成版として保存・送信しないようにします。
ここではHTTPのstream:trueによるSSEの処理を扱います。SSEは、サーバーが生成の進行に合わせてイベントを送る通信方式です。普段のChatGPT画面の操作手順とは異なります。
ストリーミングは、完成前から受け取る方法
通常の応答では、生成全体を待ってから結果を受け取ります。ストリーミングなら、生成が続いている間に冒頭から表示・処理できます。長い回答の待ち時間を体感上減らせますが、最初の文字が出た時点で最後まで生成済みという意味ではありません。公式ストリーミングガイド
受信側は、到着したデータをすべて同じ文章として貼り付けるのではなく、イベントの種類を読み分けます。作成開始、文字の追加、項目の終了、回答全体の終了など、段階に応じた処理が必要です。
deltaは、通常は追加された部分
Responses APIのresponse.output_text.deltaには、追加された文字列がdeltaとして入ります。すでに表示した全文ではなく、今回増えた部分として扱います。イベントの公式参照
たとえば最初に「本日の」、次に「予定です。」という差分が来たなら、順に追加して「本日の予定です。」と組み立てる考え方です。これは仕組みの説明用の例で、実際の分割位置はこの通りとは限りません。
出力には項目や内容の位置を示す情報もあります。複数の項目がある応答で、異なる文章やツールの引数まで同じ欄へつなぐと、内容を壊します。item_id、output_index、content_indexなど、対象を識別する項目に対応させます。
文章の終了と、回答全体の終了を区別する
イベント名にdoneがあっても、それだけで全処理の正常完了とは判断できません。
| イベントの例 | 表す段階 |
|---|---|
| response.output_text.delta | テキストの追加分 |
| response.output_text.done | そのテキスト内容の確定 |
| response.output_item.done | その出力項目の終了 |
| response.completed | 回答全体の完了 |
| response.failed | 回答の失敗 |
| response.incomplete | 回答が未完了で終了 |
公式参照には、response.incompleteの理由がmax_output_tokensになっている例があります。文章が途中まで読めても、上限などで未完了になった結果を通常の完成版へ混ぜない設計が必要です。
完了状態も、内容が正しいという採点結果ではありません。事実・数値や形式の検証は、回答を受け取った後にも行います。
保存するデータに、途中か完成かを残す
アプリ側では、受信中の表示と完成版の保存を分けると扱いやすくなります。途中まで保存する必要がある場合は、「受信中」「未完了」などの状態も一緒に持たせます。
回答のID、受け取ったイベント、組み立てた内容、終了状態を対応させて記録します。正常完了を確認した後に、用途に必要な形式や内容を検証し、完成版として採用する順序にします。
JSONの生成では、途中の文字列がまだ有効なJSONになっていないこともあります。差分を受け取るたびに、不完全なデータを完成した業務データとして登録しないでください。画面のプレビューと、確定データの更新を分けます。
通信が切れた場合は、正常終了と決めない
ネットワークの切断やアプリ側の例外で、完了イベントを確認できないことがあります。通信のループが終わったという理由だけで、成功と表示する実装は避けます。
受け取れた最後のイベントと回答ID、エラーを保存し、実際に確認できた状態を利用者へ伝えます。取得できるかどうかは保存設定やAPIの利用条件にもよるため、「後から必ず全文を回収できる」とは約束しません。
再生成を行う場合は、別の回答が作られたと分かるようにします。最初の途中回答の末尾へ、新しい回答の冒頭をそのままつなぐと、重複や矛盾が起こり得ます。外部の送信処理が途中にあるアプリなら、その処理が既に実行済みかも別に確認します。
途中の内容を公開する範囲も決める
公式ガイドは、部分的な出力は内容の確認が難しく、ストリーミングではモデレーションが難しくなる点を挙げています。生成時に要求したモデレーションのスコアも、部分的な差分と一緒には届かず、全体ができてから届くと説明しています。
問い合わせ対応や外部公開に使う場合は、途中の文章を誰に見せるか、完成後に確認するかを用途に応じて決めます。完成前の文章を、確認済みの正式回答として自動送信する仕組みにしないことが大切です。
動作確認には、途中終了のケースも入れる
開発担当者は、正常に終わる応答に加え、出力上限、APIの失敗、通信切断、複数項目がある応答を確認します。差分が重複していないか、失敗時に完成表示へ変わらないか、確定した内容と保存した内容が一致するかを点検します。
不具合を問い合わせる際は、利用するAPI、日時、回答ID、最後に受け取ったイベントの種類、エラーを示します。通常のAPIキーは記録から除いてください。ストリーミングの速さと、正常終了・保存・内容確認まで済んだかを、それぞれ追える状態にすることが実務上の要点です。
参照資料
あわせて読みたい記事
執筆・検証：カネさん（政経プラスチャンネル運営）＋ ChatGPT
