従来の自動化は動くか動かないかのどちらかです。ZapierのZapはAからBにデータを移動します——API呼び出しが失敗すれば、リトライします。出力は毎回同じです。
AIワークフローは異なります。モデルは負荷の下でタイムアウトするかもしれません。レート制限がリクエストをスロットリングするかもしれません。出力は有効だが的を外しているかもしれません。そしてAIワークフローは複数のステップを持つことが多いため、ステップ3の障害でステップ1と2の成功した結果が失われるべきではありません。
これらの現実に合わせた設計が、チームが信頼するworkflowと最初の悪い経験で放棄されるworkflowの違いを生みます。
自動リトライとバックオフ
JieGouは失敗したrecipeステップを指数バックオフで自動的にリトライします。一時的なエラー——レート制限（429）、サーバーエラー（502、503）、タイムアウト——によりステップが失敗した場合、システムは待機してリトライし、指数的にバックオフします（2秒、4秒、8秒、最大30秒）。サンダリングハード問題を避けるためランダムジッターが加えられます。
ステップごとに最大リトライ回数を設定します。ほとんどのrecipeでは、2〜3回のリトライで一時的なエラーを処理でき、workflowの大幅な遅延はありません。レート制限が一般的な大量workflowでは、より高いリトライ回数を設定するかもしれません。
永続的なエラー——無効な入力、認証の失敗、モデルの拒否——はリトライを完全にスキップします。毎回同じ方法で失敗するリクエストをリトライする意味はありません。
エラー分類が重要
すべての障害が同等ではありません。JieGouはエラーをカテゴリに分類し、workflowが適切に応答できるようにします：
- 一時的なエラー（リトライ可能）：レート制限、サーバー過負荷、ネットワークタイムアウト。リトライで自然に解決します。
- 永続的なエラー（リトライ不可）：不正な入力、認証の失敗、コンテンツポリシー違反。人間の介入または入力の変更が必要です。
- 部分的な成功：AIが出力を返したが、期待されるスキーマと完全に一致しない。workflowは持っているものを使って続行するか、レビュー用に問題をフラグできます。
この分類は自動的です。エラー処理ロジックを書く必要はありません——エグゼキューターがどのHTTPステータスコードが一時的でどれが永続的かを知っています。
セーフティネットとしての承認ゲート
承認ステップはビジネスプロセスの承認だけのものではありません。信頼性のチェックポイントでもあります。
出力品質が下流のステップにとって重要な場合、その後に承認ゲートを配置してください。例：
- 見込み客を調査する（recipeステップ）
- 調査品質をレビューする（承認ゲート）
- 調査に基づいてアウトリーチを起草する（recipeステップ）
調査ステップが薄い結果を返した場合——企業が小さくて公開情報が限られているかもしれない——承認ゲートにより、人間が利用可能なもので続行するか、アウトリーチ起草前に追加のコンテキストを提供するかを決定できます。
ゲートがなければ、アウトリーチステップは不完全な調査に基づいてメールを生成し、自動化の目的を果たさない汎用メッセージを作成してしまいます。
出力検証のための条件ステップ
条件ステップを使用して、続行前に出力品質をチェックします：
- 請求書データを抽出する（recipeステップ）
- 条件：total_amountが存在し、line_itemsが空でない場合（条件ステップ）
- Then：差異チェックに続行
- Else：手動処理にフラグ
これにより、AIが主要フィールドの抽出に失敗したケースを捕捉します——請求書のフォーマットが異常だったか、テキストのスキャンが不良だったかもしれません。不完全なデータを次のステップに渡す代わりに、workflowは人間にルーティングします。
失敗時のWebhook通知
workflowは完了時（成功でもエラーでも）にwebhook通知を送信できます。workflowが失敗した際にチームに通知する出力webhookを設定します：
- スケジュールされたworkflowがエラーに遭遇した際にSlackチャネルに投稿
- 即座の注意が必要な重要なworkflowにPagerDutyに送信
- workflowのヘルス状態でステータスダッシュボードを更新
webhookペイロードにはラン ID、ステータス、どのステップが失敗したか、エラーの詳細が含まれます。チームは「何かが壊れた」だけでなく、実用的な情報を受け取ります。
並列実行と部分的な障害
並列ステップは複数のブランチを同時に実行します。1つのブランチが失敗しても、他のブランチは続行します。これは設計上の意図です——独立した1つのブランチの障害が関連のない作業をブロックすべきではありません。
並列実行が完了した後、どのブランチが成功し、どのブランチが失敗したかを確認できます。並列ブロック後の条件ステップにより、すべてのブランチが完了したか一部が失敗したかに基づいてworkflowをルーティングできます。
95パーセンタイルの設計
ほとんどのAI呼び出しは最初の試行で成功します。ほとんどの出力は期待されるスキーマに一致します。ほとんどのworkflowは問題なく実行されます。しかし、結果に依存するチームのために毎日workflowを実行している場合、「ほとんど」では不十分です。
5%のケースに合わせてworkflowを設計してください：
- すべてのrecipeステップにリトライを追加する。失敗時の数回の追加API呼び出しのコストは、失敗したworkflow実行のコストに比べてごくわずかです。
- ハイステークスな出力の前に承認ゲートを追加する。workflowが顧客やエグゼクティブに届くコンテンツを生成している場合、人間が検証すべきです。
- 抽出ステップの後に条件チェックを追加する。必要なデータをAIが実際に抽出したことを確認してから前方に渡してください。
- スケジュールされたおよびトリガーされたworkflowにwebhook通知を設定する。UIを誰も見ていない場合、問題が発生した際のアラートが必要です。
目標は優雅に劣化するworkflowです——無音で悪い出力を生成する代わりに、問題を人間に表面化させます。