WebSocket は接続するのに結果が届かない：プロンプトごとの終了状態を追跡する

症状と対象範囲

ソケットが接続し、キュー要求が受け付けられても、それだけでは結果が返ったことにはなりません。client_id、prompt_id、終了イベント、履歴を合わせて確認します。

検索の手掛かりとなるエラーの断片です。ID、値、ファイル名は環境によって変わります。

execution_error
execution_success
executed
executing

出典から確認できること

公式メッセージ仕様では、開始、キャッシュ、成功、エラー、中断が区別されています。executed はノードが UI 更新を返した場合にのみ送信され、完了したすべてのノードについて送信されるわけではありません。POST /prompt はキューに入れる前に無効なワークフローを拒否する場合もあり、その場合は prompt_id ではなく error と node_errors を返します。バージョンを固定した API の例では、JSON メッセージとバイナリプレビューを分け、プロンプトごとの履歴と /view を使って保存済みの出力を取得します。出典 1（英語） 出典 2（英語） 出典 3（英語）

区別すべき状況

1. ソケットと送信で異なるクライアント ID を使っている。または、別のタスクのイベントを対象のイベントと取り違えている。

2. クライアントが executed だけを待ち、キャッシュ済み、UI 出力なし、失敗の経路を無視している。

3. プロキシがソケットを切断している、バイナリプレビューを JSON として解析している、または切断によって最後のイベントを取り逃している。

確認手順

以下は引用した資料に基づく編集上の手順です。あなたの環境で原因が確定したことを意味しません。

手順 1. POST /prompt が prompt_id を返したか確認します。error と node_errors が返った場合は検証エラーとして処理し、ソケットを待ち続けないでください。受け付けられたプロンプトでは、送信時とソケットの client_id を記録し、全体の最新メッセージではなく prompt_id でタスクイベントを絞り込みます。

手順 2. 成功、エラー、中断をそれぞれ別に処理し、失敗したノードと理由を記録します。終了状態の失敗を受け取ったら待機を終了します。

手順 3. 上限を設けたタイムアウトと再接続のロジックを使います。再接続した後は、新しい送信が必要かを判断する前に、既知のプロンプトの履歴を照会します。

手順 4. 該当するノードが実際に返した出力構造を読み取り、出力スキーマが一つだと決めつけず、保存済みの結果には /view のパラメーターを使います。

完了の確認

受け付けられたすべてのプロンプトが、定義された成功、エラー、中断のいずれかの状態に到達します。検証エラーは別に報告され、再接続してもタスクが重複しません。

制限と注意点

プロキシとクライアントライブラリの動作は、デプロイ環境ごとにテストする必要があります。この記事は、このサイトでサーバーに接続してテストした SDK ではありません。

参照した原文資料

• ComfyUI の実行メッセージ（英語）（原文資料の確認日：2026-09-21、再確認日：2026-09-25）
• ComfyUI Server API のルート（英語）（原文資料の確認日：2026-09-21、再確認日：2026-09-25）
• ComfyUI v0.37.0 WebSocket API の例（英語）（確認日：2026-09-25）

資料とバージョンを固定した API の例は 2026-09-25 に再確認しました。上記の 2026-09-21 は初回の確認日です。サーバーに接続した実行、GPU 実行、最小メモリの測定、実行時の保証はありません。

関連するトラブルシューティング記事とガイド

• ComfyUI のワークフローをネイティブ API から送信し、prompt_id を追跡する
• タスク履歴と /view から ComfyUI API の出力を取得する
• キューがすぐ完了するのに新しいファイルがない：キャッシュと出力先を確認する