音声インターフェースの世界では、「1秒の沈黙」が致命的なUXの低下を招きます。ユーザーはシステムがフリーズしたのか、自分の声が聞き取れなかったのか不安になり、即座に対話を放棄してしまうからです。VUIデザインにおけるこの「間（ま）」の設計に対する厳しさは、コンバーサショナルAIを用いたテキストベースのチャットUIにおいても全く同じことが言えます。
ユーザーが送信ボタンを押してから回答が表示されるまで、ローディングスピナーを何秒回し続けているでしょうか。
大規模言語モデル（LLM）の推論には時間がかかり、複雑なタスクであれば回答生成に10秒以上かかることも珍しくありません。しかし、アクセシビリティやUXの観点から見ると、10秒の待機はユーザーにとって非常に大きなストレスとなります。
この待機ストレスを解消し、スムーズな対話体験を提供するための技術的な解決策が「ストリーミングレスポンス」です。
便利なSDKやライブラリを利用するケースは多いものの、本番環境で予期せぬ挙動やネットワークエラーに悩まされる事例も少なくありません。プロトコルの仕組みを理解せずに実装することは、安定したコンバーサショナルAIの運用においてリスクを伴います。
本記事では、ライブラリのブラックボックスを排除し、HTTP標準技術であるServer-Sent Events (SSE) とブラウザネイティブの ReadableStream API に立ち返って、堅牢で高速なチャットUIの実装方法を解説します。
1. アーキテクチャ概要：なぜストリーミングがUXの生命線なのか
まず、技術選定の根幹となるアーキテクチャについて整理します。なぜ従来のREST APIではなく、ストリーミングが必要とされるのでしょうか。
TTFT（Time to First Token）と体感速度の相関
LLMアプリケーションのパフォーマンス指標として最も重要なのが TTFT (Time to First Token) です。これはリクエストを送信してから、最初の文字（トークン）が表示されるまでの時間を指します。
従来の「ブロッキングレスポンス（Request-Responseモデル）」では、サーバー側でLLMが全ての回答を生成し終えるまで、クライアントには一切データが送られません。生成に10秒かかればTTFTも10秒となり、ユーザーにとってこの時間は「システムが応答していない」と感じられる空白の時間になります。
一方、「ストリーミングレスポンス」では、LLMがトークンを生成するたびに即座にクライアントへ送信します。全体の生成に10秒かかっても、最初のトークンが0.5秒で届けばTTFTは0.5秒です。ユーザーは「AIが応答を開始している」ことを視覚的に確認できるため、心理的な待機時間は劇的に短縮されます。
音声UI設計においても、回答の準備中に「えーと」「少々お待ちください」といったフィラー（つなぎ言葉）を入れることで待機ストレスを軽減する手法が取られます。テキストチャットにおけるストリーミング表示は、これと同じ心理効果をもたらし、より自然な対話のテンポを生み出します。
WebSocket vs Server-Sent Events (SSE)
リアルタイム通信の手段としてWebSocketがよく知られていますが、コンバーサショナルAIのテキスト生成においては、Server-Sent Events (SSE) の方が適しているケースが多く見られます。
- WebSocket: 双方向通信が可能ですが、プロトコルが複雑で、ファイアウォールやプロキシの設定でトラブルになりやすい傾向があります。また、チャットの回答生成は基本的に「サーバーからクライアントへの一方通行」のデータフローです。
- Server-Sent Events (SSE): HTTPプロトコル上で動作する標準技術です。単方向通信に特化しており、通常のHTTPリクエストと同様に扱えるため、インフラとの親和性が高く、実装もシンプルです。
特に、HTTP/2やHTTP/3環境下では、SSEは単一のTCPコネクションを効率的に利用できるため、モバイルネットワークなどの不安定な環境でも高いパフォーマンスを発揮します。アクセシビリティの観点からも、多様な通信環境のユーザーに安定した応答を届けるために、LLMのストリーミングにはSSEの採用が推奨されます。
2. APIインターフェース仕様とデータ構造
VUIデザインやチャットUIにおいて、ユーザーを待たせないレスポンスは体験の質を大きく左右します。堅牢なクライアントを実装するには、まずサーバー側の仕様を明確に定義し、変化に強い設計を取り入れる必要があります。
現在、主要なAIサービスでは、古い世代のモデルが段階的に廃止され、より処理速度や推論能力に優れた最新モデルへの統合が進められています。旧バージョンの廃止によるシステムエラーを防ぐためにも、APIリクエスト時に特定の古いモデル名をハードコードするのではなく、環境変数などを利用して柔軟に最新モデルへ移行できる設計にしておくことが重要です。
ここでは、最新のAPI仕様を参考にしつつ、汎用的なストリーミングAPIのインターフェース設計について解説します。
エンドポイント設計とヘッダー要件
ストリーミング通信（Server-Sent Events: SSE）を確立するためには、サーバーからのレスポンスヘッダーに以下の設定が不可欠です。
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
各ヘッダーには、それぞれ重要な役割があります。
Content-Type: text/event-stream: ブラウザに対して、これがSSE形式のデータストリームであることを宣言します。Cache-Control: no-cache: 中間プロキシやブラウザによるデータのバッファリングを防ぎます。ユーザーに1文字でも早く応答を返すための、リアルタイム性確保に欠かせない設定です。Connection: keep-alive: 持続的な接続を維持し、細切れに送られてくるデータを途切れることなく受信し続けられるようにします。
チャンクデータ構造（Delta形式）
データペイロードは、data: という接頭辞で始まり、ダブル改行 \n\n で終わるのがSSEの標準的なフォーマットです。各メッセージには、前回からの差分（Delta）を含めるのが一般的なアプローチとなります。
data: {"id": "chatcmpl-123", "object": "chat.completion.chunk", "choices": [{"delta": {"content": "AI"}}]}
data: {"id": "chatcmpl-123", "object": "chat.completion.chunk", "choices": [{"delta": {"content": "は"}}]}
data: {"id": "chatcmpl-123", "object": "chat.completion.chunk", "choices": [{"delta": {"content": "ストリーミング"}}]}
data: [DONE]
ここで設計上の鍵となるのは、JSON全体を毎回送るのではなく、生成されたテキストの差分（delta）のみを送るという点です。
これにより通信の転送量を最小限に抑え、ユーザーの画面への描画や、音声UIにおける読み上げエンジンへのテキスト受け渡しを即座に開始することが可能になります。
また、ストリームの終了を示す特別なシグナル（例: [DONE]）を明確に定義しておくことも忘れないでください。これにより、クライアント側で安全かつ確実に接続をクローズし、次のユーザーアクションに備える状態へとスムーズに移行できます。
参考リンク
3. クライアント実装リファレンス：ReadableStreamの処理
ここからはクライアント側の実装について見ていきます。一般的に EventSource APIが紹介されることが多いですが、EventSource はPOSTリクエストでボディ（JSONなど）を送信できないという制約があります。コンバーサショナルAIではプロンプトをPOSTで送る必要があるため、Fetch API と ReadableStream を組み合わせる方法が推奨されます。
以下に、TypeScriptとReactを使用した、外部ライブラリに依存しないストリーム受信のコアロジックを示します。
Fetch APIによるストリーム取得
interface ChatMessage {
role: 'user' | 'assistant';
content: string;
}
async function fetchStream(
messages: ChatMessage[],
onUpdate: (content: string) => void,
onComplete: () => void,
onError: (error: Error) => void,
signal: AbortSignal
) {
try {
const response = await fetch('/api/chat', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify({ messages }),
signal, // 生成中断用
});
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
if (!response.body) {
throw new Error('Response body is null');
}
// ストリームリーダーの取得
const reader = response.body.getReader();
const decoder = new TextDecoder('utf-8');
let buffer = '';
while (true) {
const { done, value } = await reader.read();
if (done) {
break;
}
// バイナリチャンクをテキストにデコード
const chunk = decoder.decode(value, { stream: true });
buffer += chunk;
// SSEフォーマットのパース処理
const lines = buffer.split('\n');
// 最後の行は不完全な可能性があるためバッファに残す
buffer = lines.pop() || '';
for (const line of lines) {
if (line.startsWith('data: ')) {
const data = line.slice(6);
if (data === '[DONE]') {
onComplete();
return;
}
try {
const parsed = JSON.parse(data);
const content = parsed.choices[0]?.delta?.content || '';
if (content) {
onUpdate(content);
}
} catch (e) {
console.warn('JSON parse error', e);
}
}
}
}
} catch (error: any) {
if (error.name === 'AbortError') {
console.log('Stream aborted by user');
} else {
onError(error);
}
}
}
コードの解説
- response.body.getReader(): レスポンスボディをストリームとして読み取るためのリーダーを取得します。これがストリーミング処理の核となります。
- while(true) ループ:
reader.read()はチャンクが到着するたびにPromiseを解決します。doneが true になるまでループを回し続けます。 - バッファリング戦略: TCPパケットの分割により、JSONデータが途中で途切れた状態で届くことがあります（例:
{"conで終わるなど）。そのため、改行コードで分割し、最後の行だけは次回の処理のためにバッファに残す処理が必須です。 - AbortController: ユーザーが「生成を停止」ボタンを押した際などに、即座に通信を切断できるよう
signalを渡しています。
この実装パターンは、特定のフレームワークに依存せず、ブラウザ標準APIのみで完結しているため、非常に軽量かつ堅牢です。
4. UI/UX実装リファレンス：逐次レンダリングの最適化
データを受信するだけでは不十分であり、それをどのように画面に描画するかがユーザー体験の質を決定づけます。ここでは、チャットUI特有の課題とその解決策について解説します。
Markdownの逐次パースとちらつき防止
AIの回答は多くの場合Markdown形式ですが、ストリーミング中はMarkdown構文が不完全な状態（例: **強調 の閉じタグがまだ来ていない）で表示される瞬間があります。これをそのままレンダリングすると、文字がガタガタと揺れたり、スタイルが激しく変化する「ちらつき」が発生します。
これを防ぐためには、以下のアプローチが有効です。
- React.memo の活用: メッセージコンポーネントの再レンダリングを制御します。
- ストリーミング対応のMarkdownパーサー: 一部のライブラリは不完全なMarkdownを補完してレンダリングしてくれますが、基本的には「未確定部分はプレーンテキストとして扱う」か、CSSで高さを固定するなどの工夫が必要です。
自動スクロールとスティッキー制御
新しいテキストが追加されるたびに画面最下部へスクロールさせる必要がありますが、ユーザーが過去のログを読もうとして上にスクロールしている時に強制的に最下部へ飛ばす挙動は、アクセシビリティやUXの観点から避けるべきです。
これを制御するためのロジック（スティッキー制御）は以下のようになります。
const ChatContainer = () => {
const scrollRef = useRef<HTMLDivElement>(null);
const [isAutoScroll, setIsAutoScroll] = useState(true);
// スクロールイベントの監視
const handleScroll = () => {
const div = scrollRef.current;
if (!div) return;
// 最下部付近にいるか判定（遊びとして10px程度の余裕を持たせる）
const isAtBottom =
div.scrollHeight - div.scrollTop - div.clientHeight < 10;
setIsAutoScroll(isAtBottom);
};
// メッセージ更新時の副作用
useEffect(() => {
if (isAutoScroll && scrollRef.current) {
scrollRef.current.scrollTop = scrollRef.current.scrollHeight;
}
}, [messages, isAutoScroll]); // messagesが更新されるたびに発火
return (
<div
ref={scrollRef}
onScroll={handleScroll}
className="overflow-y-auto h-full"
>
{/* メッセージリスト */}
</div>
);
};
このロジックにより、「ユーザーが一番下にいる時だけ自動スクロールし、少しでも上にスクロールしたら自動スクロールを解除する」という、直感的で邪魔にならない挙動を実現できます。
「考え中」から「生成中」へのスムーズな遷移
TTFTを短縮しても、ネットワーク遅延などで数秒のラグが発生することはあります。この時、何も表示しないのではなく、以下のようなステータス遷移をUIで表現することが重要です。
- 送信直後: ユーザーのメッセージを表示し、AIのアイコンの横に小さなローディングアニメーション（3点リーダーなど）を表示。
- First Token受信時: ローディングを消し、テキストの表示を開始。
- 生成中: 末尾に点滅するキャレット（カーソル）を表示し、現在進行形で書いていることを演出。
特に「キャレットの点滅」は、ユーザーに対してシステムが応答中であることを伝える強力なアフォーダンスとなります。VUIにおける非言語的なフィードバックと同様に、視覚的な手がかりを提供することで安心感を与えられます。CSSの ::after 擬似要素と animation で簡単に実装可能です。
5. エラーハンドリングと再接続戦略
最後に、商用プロダクトとして欠かせないのが防御的なエラーハンドリングです。ストリーミングは接続時間が長くなるため、ネットワークエラーのリスクも高まります。
ストリーム途中でのネットワーク切断検知
fetch のストリーム読み込み中にネットワークが切断された場合、reader.read() はエラーをスローします。この時、単に「エラーが発生しました」と表示して終わるのではなく、「ここまで生成されたテキスト」は保持したまま、エラーメッセージを表示したり、再試行ボタンを提示したりする配慮が必要です。
JSONパースエラー時のリカバリー
LLMは稀に不正なJSONを出力したり、SSEのフォーマットが崩れたりすることがあります。先ほどのコード例の try-catch ブロックにあるように、1つのチャンクのパースに失敗しても、ストリーム全体をクラッシュさせずに、該当チャンクのみをスキップ（またはログ出力）して処理を継続する設計にすべきです。
レート制限（429）時のバックオフ処理
APIのレート制限に達した場合、サーバーは 429 Too Many Requests を返します。この場合、即座にリトライするのではなく、Exponential Backoff（指数関数的バックオフ） アルゴリズムを用いて、再試行間隔を徐々に延ばしながらリトライするロジックを組み込むのがマナーであり、システムの安定性を守る手段です。
まとめ：技術で「対話」をデザインする
ストリーミングレスポンスの実装は、単なる通信技術の枠を超え、ユーザーとAIの間の自然な「対話のリズム」を構築するVUIデザインの延長線上にあります。
HTTP標準のSSEとReadableStream APIを正しく理解し実装することで、ライブラリの制限に縛られることなく、TTFTを極限まで短縮し、ユーザーの感情に寄り添ったチャット体験を提供できます。
- SSEの採用: HTTP標準でシンプルかつ効率的な単方向通信を実現。
- ReadableStreamの活用: ブラウザネイティブAPIで細やかな制御が可能。
- UXの作り込み: 逐次レンダリングとスクロール制御でストレスを排除。
「応答が遅い」という課題は、適切な技術選定とUI設計によって解決可能です。本記事で解説した技術仕様やアクセシビリティへの配慮をベースに、ユーザーを「待たせない」高品質な対話体験の実現に役立てていただければ幸いです。
コメント