――ストリーミング、同時接続、スケールの現実を踏まえた “規模別ベストプラクティス” LLMのAPIは一見「リクエストを投げてレスポンスを受け取る」だけですが、実運用では次の要件が重なります。 **体感速度（TTFT：Time To First Token）**を良くしたい 生成が数秒〜数十秒に及び、 レスポンスが長い **キャンセル（中断）**が必要（コストにも直結） tool-call / progress / usage / error など、 イベントを流したい 同時利用者が増えた時の接続維持コスト （FD/メモリ/LBのidle timeout/再接続嵐） そこで候補に挙がるのが： 通常のHTTPS（リクエスト/レスポンス） SSE（Server-Sent Events：サーバ→クライアントの一方向ストリーム） WebSocket（双方向の常時接続） ※厳密には SSE も HTTPS 上で動きます。ここでは実務上の比較として (A) 通常HTTPS vs (B) HTTPS+SSE vs (C) wss(WebSocket) という意味で扱います。 1. まずは一言でまとめる 方式 一言で言うと LLMで向いている用途 通常HTTPS 「送って、終わったら一回で受け取る」 短い応答 / 最大スループット / 運用が簡単 SSE 「1回送る → サーバがイベント/トークンを流し続ける（片方向）」 トークンストリーミング / 進捗や状態イベント WebSocket 「1本の接続で双方向にメッセージを継続送受信」 セッション型エージェント / リアルタイム双方向 2. LLM通信で重要な評価軸 LLMは “RPS（秒間リクエスト数）” だけ見ても本質を外しやすいです。特に重要なのは： 同時生成（アクティブな待ち） = 流入率 × 平均生成時間 接続維持コスト = 同時接続数 ×（FD/メモリ/バッファ/keepalive） 再接続嵐 （障害・通信揺れ・モバイル切替） キャンセルの実効性 （UIキャンセルが推論停止に直結するか） 3. 機能・運用・性能の比較表 3-1. 機能（UX/プロトコル）観点 項目 通常HTTPS SSE W...