エラーとリトライに対処する

サービスのタイムアウト、見つからないレコード、API からの拒否。外部とやり取りする以上、失敗は避けられません。このガイドでは、ステップが失敗してもフローを続ける方法、失敗に応じて処理を変える方法、ときどき失敗するリクエストをリトライする方法を説明します。

失敗したときの動き

既定では、ステップが失敗すると実行は停止し、失敗 として記録されます。この動作はステップごとに ノード設定 の エラーハンドリング で変更できます。ステップを選び、設定パネル上部の歯車アイコンをクリックすると開きます。

選択肢	動作
フローを停止（既定）	失敗したステップで実行が終わります。
フローを続行	ステップは失敗として記録されますが、実行は次のステップへ進みます。

トリガー、パス、停止のステップにはエラーハンドリングの設定がありません。

1. 失敗してもフローを続ける

1. HTTP リクエストや CRM の検索など、失敗する可能性のあるステップを選びます。
2. 設定パネル上部の歯車アイコンをクリックして ノード設定 を開き、エラーハンドリング を フローを続行 にします。
3. 保存 をクリックします。

ステップが失敗すると、その出力に失敗の理由を表す error が加わります。

{
  "error": {
    "errorCode": "HTTP_ERROR",
    "message": "Not Found (404)"
  }
}

出力のほかの部分には、ステップが返せたデータがそのまま入ります。たとえば HTTP ステップなら statusCode と body も残ります。

2. エラーで分岐する

ステップの直後に パス を追加し、失敗したときは別のルートに進めます。

1. ステップを追加 をクリックし、組み込み を開いて パス を選びます。
2. 最初の分岐の パスモード を 条件に基づく にし、次の条件を設定します。
   • フィールド: $.<ステップ ID>.output.error。$ の一覧には error が表示されないため、参照を入力します。$ の一覧でステップの横にあるコピーボタンからステップ ID をコピーし、.output.error を付け足してください。
   • 演算子: 存在する
3. この分岐に、失敗したときのステップ（Slack への通知や 停止 など）を追加します。
4. 2 つ目の分岐を追加して パスモード を フォールバック にし、通常のステップをそこに追加します。

HTTP ステップなら、statusCode を 数値: 等しい 404 で確認して、「見つからない」と「サーバーが落ちている」を分けて扱うこともできます。

3. 失敗を知らせる

問題が見過ごされないよう、失敗の分岐に通知を置きましょう。理由と、どの実行かがわかる情報を含めます。

注文の同期に失敗しました（Current Trigger.orderId）: HTTP ステップ.error.message

実行 ID は単独の項目として追加するか、コードのステップでメッセージを組み立ててください。$execution.runId は項目全体として使ったときだけ値に置き換わります。通知を送る を参照してください。

失敗した後に実行を続けても意味がない場合は、失敗の分岐の最後に 停止 を置きます。

ときどき失敗するリクエストをリトライする

タイムアウトやサービスの一時的な停止など、もう一度試せば成功する失敗もあります。HTTP と 大規模言語モデル のノードは、こうした失敗を自動でリトライします。HTTP のステップでは、リクエストの設定の下にある リトライ有効 からがリトライの設定です。LLM のステップでは リトライ設定 にあります。

設定	HTTP の既定値	LLM の既定値	内容
リトライ有効	オン	—	繰り返してはいけないリクエストではオフにします。
最大リトライ回数	3	3	試行する回数。HTTP では最初のリクエストを含むため、1 にするとリトライしません。
初期間隔	1 秒	1 秒	最初のリトライまでの待ち時間。
倍率	2	2	待ち時間を毎回この倍数で延ばします。
最大間隔	60 秒	10 秒	1 回あたりの待ち時間の上限。
最大経過時間	15 分	30 秒	試行回数が残っていても、この時間が過ぎたらあきらめます。

HTTP ノードがリトライするのは、リクエストがタイムアウトしたとき、接続が切れたとき、API が 408・502・503・504 を返したときです。400・401・404 などほかのエラーは、同じリクエストを送っても同じ結果になるため、すぐに失敗します。ステップの出力の retries に、すべての試行が記録されます。

何かを作成するリクエストではリトライをオフに

注文を作成する POST がタイムアウトしても、注文自体は作成されている可能性があります。リトライすると注文が 2 件になります。このようなリクエストでは リトライ有効 をオフにするか、冪等キーのヘッダーなどで API が重複を無視するようにしてください。

ほかのノードは自動ではリトライしません。必要な場合は、ステップを 数値ループ（1 から 3）の ループ に入れ、ステップのエラーハンドリングを フローを続行 にし、その後に error がないときに 停止 するパスを置きます。ループ内の停止はループを抜けるため、成功した時点で試行が終わります。試行の間隔を空けるには、ループ内に 指定時間待機 のステップを追加します。

「見つからない」が想定内の場合

結果が空でも、エラーとは限りません。存在しないキーに対する 値を取得 は空の値で成功し、フィルター は一致する項目がないと、空の結果でも続行 をオンにしない限り実行を止めます。これらはエラーハンドリングではなく、パスの 空である で確認してください。

関連ページ

• 失敗した実行を調査する
• フローとノード: ステップが失敗したとき
• 外部 API を呼び出す
• HTTP ノード と 大規模言語モデルノード