自動化フローの実行エラーを毎日集めて、原因の分類と対応の優先度を出す

処理の起点を決める

トリガーは、エラーを受ける側とまとめる側の2つです。

1つ目は Error Trigger。受け口を1本作り、n8n のワークフロー全部の Settings で Error workflow として指定します。受け口は「受けて、そろえて、台帳に追記する」だけにします。 ここで分類まで行うと大量発生時に詰まります。n8n 以外は Error Trigger を持たないので、Power Automate、Make、Zapier は通知先を受け口の Webhook に向け、Apps Script は通知メールを受け取るフローを作って渡します。

2つ目は Schedule Trigger です。毎朝6時に動き、前日分をまとめて処理します。1回にまとめるのは、大量発生を1つのまとまりにするには時間をためる必要があるためです。 ただし夜間に止まったフローに翌朝まで気づかない状態は避け、「1時間で同じ鍵が20件を超えたら即時通知」の条件を受け口に別で入れます。

入力データを集める

この構成の質を決めるのは、AIでもプロンプトでもなく台帳です。 「止まると何が止まるのか」「再実行してよいのか」は本文から分からず、人が決めて列として持つしかありません。

データの取得方法を決める

n8n： 受け口の最初に「execution があるか」の分岐を置き、無ければ trigger.error.name と trigger.error.cause.message から同じ形に組み直します。この分岐は必ず作ってください。

他のツール： 通知の項目が違うので、受け口の側にツールごとの変換を置きます。「ツール名」「フロー名」「失敗した箇所」「エラー本文」「発生時刻」「実行のリンク」の6つに落とし込めれば十分です。Apps Script は通知メールから同じ6項目を取り出し、 取り出せなければ「取り出し失敗」の印を付けます。

フロー台帳とルール表： スプレッドシートから読み、担当者が中身を見て直せるよう、ワークフローの中に書き込まないでください。

AIへ渡す前に整形する

1. 正規化とマスキング … 形の違う通知を6項目の共通の形にそろえ、本文から顧客名、メールアドレス、電話番号、注文番号、顧客IDを伏せます。AIに渡す前に必ずここを通します（第13章）
2. まとめの鍵を作る … フロー名＋失敗した箇所（execution.lastNodeExecuted）＋エラー本文の型を連結して鍵にします。型はマスキング後の本文から数字と可変部分を取り除いたもので、ルール表と一致したまとまりはAIを呼ばずに区分を確定します
3. まとまりの集計 … 鍵ごとに件数、最初と最後の時刻、影響したフローを機械で数えます。execution.retryOf が入っているものは再実行して再び失敗したものなので、「もう一度回せば通る」の反証として必ず付けます。この集計はAIにさせません
4. 台帳との突き合わせ … 担当部署、業務、重要度、再実行の可否を当てます。台帳に無いフローは「所属不明」の印を付けます

2番目の鍵の作り方が、いちばん技術的な部分です。 本文には実行ごとに違う値（時刻、ID、件数）が混ざるので、数字と括弧の中身を取り除いてから比べます。

AIに処理させる

AIにさせるのは、ルール表に当たらなかったまとまりについて、原因の区分を付けることだけです。 区分は次の6つに固定し、自由に区分名を作らせません。

この表の右の列が、この構成の中心です。 区分そのものよりも、「一時的な失敗」か「直さないと止まったままのもの」かの2択が、その日の行動を決めます。 前者は件数が多くてもやることは「様子を見る」で、後者は1件でも業務が止まっています。データの想定外とレート制限は両方に転ぶので、別項目として判定させます。

AIに任せるのは、区分、一時的かどうかの判定、確からしさ、根拠の引用、影響の1文です。件数を数えること、優先度の順位付け、再実行の可否の最終判断、再実行の実行、直し方を書くことはさせません。実行のボタンは人が押します。

指示内容を固定する

あなたは社内の自動化フローの実行エラーを分類する担当者を支援する立場です。
渡す「エラーのまとまり」について、原因の区分と、一時的な失敗かどうかを判定してください。
この判定は情報システム担当が読んで確認したうえで、担当が対応を決めます。

【厳守事項】
- cause_category は、次の7つからちょうど1つを選んでください。
  credential_expired / permission / remote_spec_change / unexpected_data /
  rate_limit / transient_network / unknown
  新しい区分名を作らないでください。迷ったら unknown を選んでください。

- persistence には transient か needs_fix のどちらかを入れてください。
  transient … 次の実行で通る見込みがあるもの
  needs_fix … 誰かが設定・権限・データ・フローに手を入れるまで通らないもの
  「この鍵が何日連続で出ているか」を必ず考慮し、
  レート制限やタイムアウトでも3日以上連続していれば needs_fix にしてください。

- evidence には、判定の根拠にした本文の部分を原文のまま抜き出してください。
  要約も言い換えもしないでください。抜き出せない場合は空の配列にしてください。

- 件数、発生時刻、影響したフローの数は、渡した値をそのまま使ってください。

- 再実行してよいかどうかの最終判断をしないでください。
  rerun_hint には本文から読み取れる範囲の手がかりだけを書き、
  「途中まで処理が進んだ形跡があるか」が読み取れない場合は unknown にしてください。

- 原因の直し方（どの設定をどう変えるか）を書かないでください。実際の環境を
  見ていないため推測になります。書かれていない製品名や担当者名も出さないこと。

【エラーのまとまり】
まとめの鍵：{group_key}／フロー名：{workflow_name}／ツール：{tool_name}
失敗した箇所：{failed_node}／件数：{count}／連続日数：{consecutive_days}
最初に出た時刻：{first_seen}／最後に出た時刻：{last_seen}
再実行後の失敗が含まれるか：{contains_retry}
つないでいる業務：{business_name}／作った部署：{owner_department}

【エラー本文（マスキング済み・代表例を最大3件）】
{masked_messages}

「新しい区分名を作らないでください」が、いちばん効く制約です。 自由にさせると同じ内容に「認証エラー」「トークン切れ」「OAuth期限切れ」と別の名前が付き、翌日から集計ができなくなります。 レート制限やタイムアウトは字面が一時的なので、「3日以上連続していれば needs_fix」で折り返させないと毎日 transient が付いて誰も見ません。

出力形式を固定する

{
  "group_key": "",
  "cause_category": "credential_expired | permission | remote_spec_change | unexpected_data | rate_limit | transient_network | unknown",
  "persistence": "transient | needs_fix",
  "confidence": "high | medium | low",
  "evidence": [ { "quote": "" } ],
  "impact_note": "",
  "rerun_hint": "partially_processed | no_side_effect | unknown",
  "needs_human_attention": { "flag": false, "reason": "" }
}

この形をJSON Schemaにして、Claude API の output_config の中の format に type を "json_schema"、schema にスキーマ本体を渡すと、制約付きのデコードでスキーマに沿った応答が保証されます。各オブジェクトに additionalProperties を false で付け、required に必須の項目を並べます。 cause_category、persistence、confidence、rerun_hint は enum で値を固定します。enum は文字列を並べる用途で使えるので、この4項目はそのまま書けます。

構造化出力にするのは、集計できる形にするためです。 区分がぶれないので「今週は接続の期限切れが何件あったか」を機械で数えられ、evidence に引用があれば全文を読まずに根拠だけで合否を決められます。初回はスキーマの準備の時間がかかるので、固めたら変えないでください。

rerun_hint は「再実行してよい」という判断ではなく、 本文から「途中まで処理が進んだ形跡があるか」だけを読み取らせた手がかりです。再実行の可否はフロー台帳の列の値で決まり、 食い違えば台帳を正として要確認の印を付けます。

システムへ連携する

各ツールへの書き戻しは行いません。「フローを止める」「設定を直す」「再実行する」は人が各ツールの画面で行います。

人が確認する

全件、人が確認します。まとまりの単位で確認し、件数では確認しません。 順番は、①needs_human_attention が真、②persistence が needs_fix で業務の重要度が高い、③confidence が low、④所属不明のフロー、⑤transient だが連続日数が伸びている、⑥それ以外。

確認の作業は3つです。

• evidence の引用を読み、区分と persistence が妥当かを見る（本文を全部読まない）
• 再実行するかどうかをフロー台帳の値を見て決める（rerun_hint だけで決めない）
• 作った部署へ返すか、情報システムで引き取るかを決める

3つ目は機械にできません。直せる人がいるかどうかは、台帳の担当者列だけでは分かりません。 確認の時間の目標は、1件あたりに割り戻して3分（確認2分＋指示と記録1分）です。

例外に対処する

上の2行は必ず先に作ってください。 受け口が落ちると、エラーを集める仕組みが自分のエラーで止まります。

記録を残す

• 受け口が受け取った生のデータ（ツール名、フロー名、原文のエラー本文、発生時刻）と、マスキング後の本文・伏せた項目の種類と件数
• まとめの鍵、件数、最初と最後の時刻、AIに渡した内容と返ってきたJSON（cause_category、persistence、confidence、evidence）
• 人が区分を直した場合の、直す前と直した後の値。対応した内容（再実行した／部署へ依頼した／引き取った／様子を見た）と、対応した人・日時・その結果

人が直した値を残すと、ルール表が育ちます。 同じ直し方が3回出ればその型をルール表に入れられ、以後はAIを呼ばなくなります。