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