課題
毎ターン LLM を叩く設計で、応答が返るまで待たされる。ストリーミングが未実装のため、回答が一括で出るまで画面が固まって見え、体感が重い。
Before(現状)
- 1ターンで、構造化抽出(
extract)+次質問生成(followup)+3ターン毎のギャップ計算が同期実行され、すべて終わってから JSON がまとめて返る。
- 次の質問(assistant メッセージ)もストリーミングされず、確定後に一括表示。
After(あるべき姿)
- 次の質問文が生成され次第、逐次(ストリーミング)表示され、待ち時間が体感で短くなる。
- 重い処理(ギャップ計算など)を応答表示のクリティカルパスから外し、体感を優先する。
技術的な着手ポイント
lib/server/openai.ts
openai.chat.completions.parse を使用(非ストリーミング・Structured Outputs)。質問生成のストリーミング化にはストリーム API への切替が必要(choices が structured 出力な点との両立は要検討)。
lib/server/interview/followup.ts
generateAdaptiveQuestion:response_format: zodResponseFormat(...) で構造化受信。本文(content)をストリームしつつ choices を確定させる方式の設計が要る(要調査)。
lib/server/routes/sessions.ts
POST /api/sessions/:id/messages(handleUserTurn 呼び出し)。SSE/ストリームレスポンスへの変更候補。Hono のストリーミングを利用。
components/session/SessionView.tsx
sendMessage(fetch 後に全文 JSON を待つ)。逐次受信+逐次描画への変更。
- 分割案:質問生成は同期のままでも、ギャップ計算を応答後の非同期に回すだけで体感が改善する可能性(段階実装の余地)。
受け入れ条件
優先度
中。体感改善に効くが、内容の正しさ(UX1/2)より後。段階実装(ギャップ計算の非同期化)から着手できる。
このIssueは Slack #gov_ai_agent での議論(Yuki Kawabe / sunagawa)に基づき起票されました。
課題
毎ターン LLM を叩く設計で、応答が返るまで待たされる。ストリーミングが未実装のため、回答が一括で出るまで画面が固まって見え、体感が重い。
Before(現状)
extract)+次質問生成(followup)+3ターン毎のギャップ計算が同期実行され、すべて終わってから JSON がまとめて返る。After(あるべき姿)
技術的な着手ポイント
lib/server/openai.tsopenai.chat.completions.parseを使用(非ストリーミング・Structured Outputs)。質問生成のストリーミング化にはストリーム API への切替が必要(choices が structured 出力な点との両立は要検討)。lib/server/interview/followup.tsgenerateAdaptiveQuestion:response_format: zodResponseFormat(...)で構造化受信。本文(content)をストリームしつつ choices を確定させる方式の設計が要る(要調査)。lib/server/routes/sessions.tsPOST /api/sessions/:id/messages(handleUserTurn呼び出し)。SSE/ストリームレスポンスへの変更候補。Hono のストリーミングを利用。components/session/SessionView.tsxsendMessage(fetch後に全文 JSON を待つ)。逐次受信+逐次描画への変更。受け入れ条件
優先度
中。体感改善に効くが、内容の正しさ(UX1/2)より後。段階実装(ギャップ計算の非同期化)から着手できる。