はじめに

始める前に

• n8n instance（self-hosted または n8n Cloud）。HTTPS で到達できること。
• その instance で n8n API key を作成できる権限。
• execution の履歴がある workflow。基準を学習するために履歴が必要です。1 時間前に作った workflow は、実行回数が足りるまで「データ不足」と表示されます。

手順 1 — instance を接続する

1. 1n8n で Settings → n8n API → Create an API key。
2. 2key をコピーします。
3. 3ダッシュボードで連携を追加し、instance の URL と key を入力します。
4. 4保存します。OutcomeGuard はその場で接続を確認し、URL か key が誤っていればその時点で知らせます。

key は保存前に暗号化し、ログには残しません。URL の条件と切り分けは「n8n を接続する」のページにあります。

手順 2 — 監視する workflow を選ぶ

OutcomeGuard は見えるすべての workflow を一覧にします。プランの上限の範囲で、監視したいものを選んでください。止まったら電話が鳴るもの（請求、リードの振り分け、日次の取り込み、顧客が見るもの）から始めるのが確実です。

選択はいつでも変えられます。選択を外した workflow は監視を止め、ほかには影響しません。

手順 3 — 基準が固まるのを待つ

監視対象の workflow ごとに、直近の execution 履歴から実行間隔、所要時間、件数、成功時にいつも最後になる node、空の結果が本当に普通である頻度を学習します。

エラー、クラッシュ、認証失敗といったはっきりした障害は最初の取得から報告します。統計的な検出は履歴が十分になるまで待ち、その間の workflow は正常でも異常でもなく「データ不足」として並びます。

手順 4 — 通知先を決める

ダッシュボードで workspace のメール通知先を登録します。1 件の incident につきメール 1 通で、根拠が付きます。問題が続く場合は、同じ通知を繰り返すのではなくエスカレーションします。

一度テスト通知を送ってください。どう届くかが分かり、迷惑メールに入るかどうかも今のうちに判明します。

手順 5 — 「終わった」の定義を書く

重要な 2〜3 本には Outcome Contract を書きます。期限、最低件数、最大所要時間、そして必要なら連携先が実際に変わったことを確認する downstream probe。実行されたことを知るのと、仕事が終わったことを知るのは、ここで分かれます。

ルールの種類と完全な例は「Outcome Contract」のページにあります。

初日に起きること

• 数分のうちに：失敗している workflow、認証エラー、非アクティブの workflow、到達できない instance。
• 数時間のうちに：実行漏れ。次の実行がいつだったかを把握できるようになるためです。
• 数日のうちに：サイレント障害、出力ゼロ、件数と所要時間の異常。基準が固まるにつれて出てきます。

接続前に様子を見たい場合は、先に無料ヘルスチェックを実行してください。同じ engine を使い、終了時に API key を破棄します。