緑のチェックは、仕事が終わった証拠になりません
n8n が教えてくれるのは、実行がエラーなく終わったかどうかまでです。請求書が保存されたか、リードが CRM に届いたか、レポートがシートに書き込まれたかは、そこには含まれません。
自動化の障害は、たいてい音もなく起きます。トリガーが動かなくなる。IF の条件に誰も当てはまらなくなる。認証情報が夜中に期限切れになる。取得元が空のリストを返す。それでも実行は「成功」と表示され、顧客から「データはどこですか」と聞かれるまで誰も気づきません。
そもそも動いていない
編集したあと、スケジュールトリガーが止まったままだった。最新の実行は 4 日前、表示は成功。
動いたが、何もしていない
フィルタを通るデータが 0 件になった。ワークフローは 800 ミリ秒で成功し、どこにも何も書き込まない。
動いたが、途中で終わっている
最後に動いたノードが、データベースではなく HTTP だった。エラーなし、データなし、通知なし。
顧客より先に、気づける。
障害 1 件につきメール 1 通。何を期待していたか、実際に何がいつ観測されたか、どれくらい確かなのかを添えて送ります。
OutcomeGuard が見ているもの
判定はワークフローごとに、そのワークフロー自身の履歴だけを基準にします。よそのデータとは比べません。検出結果には、シグナル名・根拠・時刻・確信度に加えて、理由をひと言で添えます。判定に足りる履歴がないときは、無理に異常を作らず「データ不足」と報告します。
- サイレント障害SILENT_FAILURE
エラーは出ていないのに、仕事が進んでいません。トリガーが沈黙したとき、または成功した実行が以前より手前のノードで終わるようになったときに出します。
- 実行されなかったMISSED_RUN
予定されていた実行がありません。cron も間隔指定もタイムゾーンまで読むので、08:30 JST に動くはずのワークフローは 08:30 JST を基準に判定します。
- 出力ゼロEMPTY_OUTPUT
成功しているのに、出力が 0 件でした。普段は件数が出ているワークフローに限って報告します。
- 失敗FAILED
実行がエラー、クラッシュ、またはキャンセルで終わりました。
- 成果条件を満たさないOUTCOME_FAILED
実行はされましたが、Outcome Contract の条件を 1 つ以上満たしていません。
- 更新が止まっているSTALE_OUTPUT
Outcome Contract で許容した時間を超えて、連携先の内容が更新されていません。
- 件数の異常VOLUME_ANOMALY
実行回数、または 1 回あたりの件数が、そのワークフローの普段の範囲から大きく外れています。
- 実行時間の異常LATENCY_ANOMALY
実行時間が、そのワークフローの普段の時間から大きく外れています。長すぎる場合も、短すぎる場合も報告します。
- 認証エラーAUTH_ERROR
認証情報が拒否されました。OAuth トークンの期限切れ、キーの失効、パスワードの変更が典型です。
- 連携先のエラーDOWNSTREAM_ERROR
ワークフローが頼っている外部サービスが失敗したか、リクエストを拒否しました。
- 設定の変更CONFIG_DRIFT
ワークフローの定義が変更された、またはワークフローが非アクティブになりました。
- 判定不能UNKNOWN
インスタンスに接続できないため、このワークフローは判定していません。推測で状態を決めることはしません。
Outcome Contract：「終わった」の定義を先に書いておく
実行の監視で分かるのは「動いたか、エラーが出たか」までです。Outcome Contract は「仕事が終わったか」に答えます。
ワークフローごとに、期待する結果を書いておきます。期限が来たら OutcomeGuard が条件を 1 つずつ確かめ、すべて満たしたときだけ正常と扱います。
契約の例
正常- 平日は 08:30 JST 以降に必ず実行されている
- 実行が成功で終わっている
- 出力が 1 件以上ある
- 5 分以内に終わっている
- 連携先が実際に更新されたことを、届け先で確かめられる
1 つでも欠ければ、正常とは扱いません。n8n 側に「成功」と記録されていても同じです。
API キーの登録から、最初の検出まで
接続
n8n で API キーを作り、インスタンスの URL と一緒に入力します。OutcomeGuard が触るのは n8n の公開 REST API だけです。セルフホストでも n8n Cloud でも動きます。
基準の学習
ワークフローごとに実行履歴を読み、そのワークフロー自身の「普段」を覚えます。どれくらいの間隔で動くか、どれくらい時間がかかるか、何件出すか、いつもどのノードで終わるか、空の結果が本当に普通なのか。
監視
その後は定期的に n8n を読みに行き、実行ごとの要約を集めます。状態、開始時刻、所要時間、件数、最後に動いたノード、秘密情報を取り除いたエラー文、それにワークフロー定義のハッシュです。
検出
ワークフローごとに、そのワークフロー自身の基準と、トリガーに設定されたスケジュールに照らして判定します。cron も間隔指定もタイムゾーンまで読むので、08:30 JST に動くはずの実行は、08:30 JST の時点で「来ていない」と判定します。08:30 UTC ではありません。
成果の検証
Outcome Contract を設定したワークフローは、期限が来た時点で結果を確かめます。実行されたか、成功したか、件数は足りたか、時間内に終わったか、そして連携先が実際に変わったことを、届け先で確かめられたか。
通知と報告
検出結果は、問題 1 件につきインシデント 1 件にまとめます。同じ問題はまとめ、通知の間隔を空け、段階を踏んで知らせるので、1 回の障害でメールが 40 通届くことはありません。月次レポートは Pro と Agency に含まれます。
死活監視と Error Workflow で拾えるのは、はっきり落ちた障害だけです
死活監視が教えてくれるのは「処理が ping を送った」ことだけ。n8n の Error Workflow が動くのは「ノードが例外を投げた」ときだけ。どちらも役に立ちますが、いちばん高くつく障害には反応しません。始まらなかった実行、何も返さなかった実行、1 つ手前のノードで終わった実行です。
OutcomeGuard は実行履歴から、そのワークフロー自身の実行間隔、所要時間、件数、いつも最後になるノードを覚えます。新しい実行は、その基準と、トリガーが実際に宣言しているスケジュールに照らして判定します。
データの扱いは、あえて地味に
- アクセスは n8n の公開 REST API を読むだけです。ワークフローには書き込みません。
- 保存するのは実行の要約だけです。状態、時刻、所要時間、件数、最後のノード、秘密情報を取り除いたエラー文。ペイロードは保存しません。
- API キーは AES-256-GCM で暗号化して保存します。暗号鍵は実行環境にしか置きません。
- 自動で行う操作は、安全なものだけです。当社側のチェックのやり直しと、通知の再送だけ。ワークフローの書き換えや認証情報の変更はしません。
まず n8n から
現在の対象は n8n（セルフホストと n8n Cloud）です。Make、Zapier、GitHub Actions は今後の予定に入れています。4 つを中途半端に扱うより、1 つをきちんと扱うことを選びました。