OutcomeGuard の仕組み
API キーを登録してから、すぐ対応に移れる通知が届くまでの 6 段階です。n8n のインスタンスの中で動かすものはなく、インスタンスへ書き戻すものもありません。
- 1
接続
n8n で API キーを作り、インスタンスの URL と一緒に入力します。OutcomeGuard が触るのは n8n の公開 REST API だけです。セルフホストでも n8n Cloud でも動きます。
- 2
基準の学習
ワークフローごとに実行履歴を読み、そのワークフロー自身の「普段」を覚えます。どれくらいの間隔で動くか、どれくらい時間がかかるか、何件出すか、いつもどのノードで終わるか、空の結果が本当に普通なのか。
- 3
監視
その後は定期的に n8n を読みに行き、実行ごとの要約を集めます。状態、開始時刻、所要時間、件数、最後に動いたノード、秘密情報を取り除いたエラー文、それにワークフロー定義のハッシュです。
- 4
検出
ワークフローごとに、そのワークフロー自身の基準と、トリガーに設定されたスケジュールに照らして判定します。cron も間隔指定もタイムゾーンまで読むので、08:30 JST に動くはずの実行は、08:30 JST の時点で「来ていない」と判定します。08:30 UTC ではありません。
- 5
成果の検証
Outcome Contract を設定したワークフローは、期限が来た時点で結果を確かめます。実行されたか、成功したか、件数は足りたか、時間内に終わったか、そして連携先が実際に変わったことを、届け先で確かめられたか。
- 6
通知と報告
検出結果は、問題 1 件につきインシデント 1 件にまとめます。同じ問題はまとめ、通知の間隔を空け、段階を踏んで知らせるので、1 回の障害でメールが 40 通届くことはありません。月次レポートは Pro と Agency に含まれます。
各段階は、証明できたことだけを次へ渡します。根拠が足りない段階は「データ不足」と報告してそこで止まります。
検出結果は、判断の過程まで出します
検出結果はラベルだけではありません。シグナルの種類、判断のもとになった根拠、時刻、0 から 1 の確信度、そして判断をひと言で言い表した理由が付きます。
- シグナル
- どの障害パターンに一致したか。たとえば SILENT_FAILURE、MISSED_RUN。
- 根拠
- 判断の材料。最後の実行、想定していた間隔、件数、最後のノード、秘密情報を取り除いたエラー文。
- 確信度
- 判定エンジンがどれくらい確かだと見ているか。読めた履歴が多いほど高くなります。
- 理由
- そのまま同僚に転送できるひと言。読み替えは要りません。