失敗検知とリカバリ

複数工程のワークフローでは、途中の失敗をどう扱うかが信頼性を決めます。検知できなければ、誤った結果のまま最後まで進みます。

検知は完了条件から

失敗を検知するには、各工程に完了条件が定義されている必要があります。条件がなければ「終わったかどうか」を判定できません。

横にスクロールできます→

失敗の見え方	検知方法
ツールが例外を返す	エラーとして検知できる
処理は成功したが出力が要件を満たさない	完了条件との照合が必要
何も起きずに次へ進む	完了条件がないと検知できない

この表は横方向にスクロールできます。キーボードでは、表にフォーカスして左右の矢印キーを使用してください。

危険なのは2番目と3番目です。エラーが出ないため、仕組みで確認しない限り気づけません。フックで工程の直後に検証を走らせるのが確実な方法です。

戻り先は原因で変える

失敗したとき、常に最初へ戻るのは非効率です。原因に応じて戻り先を変えます。

graph TD
    F["工程が失敗"] --> C{"原因はどこか"}
    C -->|入力が不正| Prev["前工程の出力を修正"]
    C -->|手順が不適切| Same["同じ工程を条件を変えて再実行"]
    C -->|前提が崩れた| Plan["計画そのものを見直す"]
    C -->|外部要因| Wait["時間を空けて再試行"]

横にスクロールできます→

原因	戻り先
入力の不備	前工程
手順や指示の問題	同じ工程を条件を変えて再実行
前提の崩れ	計画の見直し
一時的な外部要因	同じ工程を時間を空けて再試行

この表は横方向にスクロールできます。キーボードでは、表にフォーカスして左右の矢印キーを使用してください。

上限を決めて人へ渡す

自動リカバリには上限を設けます。同じ工程が上限回数まで失敗したら、続行せず人へエスカレーションします。

エスカレーションのときに渡す情報は次の3点です。

1. どの工程で、何回失敗したか
2. 失敗時のエラーまたは完了条件との差分
3. どこまでの成果物が残っているか

これがないと、人が状況を把握するところからやり直しになります。

途中結果を捨てない

失敗しても、それまでの工程の成果物は残します。状態管理で進捗を保持していれば、成功した工程をやり直す必要はありません。全体をロールバックする設計は、長いワークフローでは損失が大きくなります。

まとめ

• 失敗検知には、各工程の完了条件が必要
• エラーが出ない失敗こそ危険で、仕組みによる検証が要る
• 戻り先は原因によって変える（前工程・同じ工程・計画の見直し）
• 上限を超えたら人へエスカレーションし、状況と残存成果物を渡す

関連リンク

• オーケストレーションとは
• 状態管理と引き継ぎ
• ツールのエラー処理