毎朝のバックアップとバッチ処理の実行結果を集め、失敗と警告を原因の種類で分類して、当番への連絡文まで作る

処理の起点を決める

トリガーは2つに分けます。 結果メールは夜間に1通ずつ届くので、Email Trigger（IMAP）で受け取るたびに Data Table へ書いておきます。 朝の点検は Schedule Trigger で毎朝7時に動かし、夜のうちにたまった結果を読みます。

Email Trigger（IMAP）は、公式ページでは指定したメールボックスからメールを受け取るトリガーで、受け取ったときに既読にするかを選べ、取得するメールを node-imap の検索条件で絞れるとされています。結果メールの送り元で絞り、既読にする設定にします。 当番が共有メールボックスを開いたときに、未読で残っているものは n8n が受け取れなかったものになります。

Schedule Trigger は Days の間隔で、7時0分を指定します。 公式ページでは、Schedule Trigger はワークフローを保存して公開しないと動かないとされ、タイムゾーンはワークフローの設定、無ければインスタンスの設定に従い、自分でサーバーに置く場合の既定は America/New York です。ワークフローの設定で Asia/Tokyo を選びます。

休日も毎朝動かします。 土日の朝の一覧は当番の携帯に届き、未着とその他が無ければ月曜にまとめて見ます。月曜に2晩分を一度に見るより、毎朝の一覧が積み上がっているほうが追いやすくなります。

入力データを集める

質を決めるのは、ジョブの台帳の「放っておいてよい警告の文」の列です。 毎晩同じ警告を出し、担当も承知しているものがあります。この列が空だと、毎朝同じ警告が一覧に並び、当番は一覧を読まなくなります。 長く担当している人の頭の中にある判断を、ここに書き出します。

「動く曜日」と「終わるはずの時刻」は、未着の判定に使います。 月末だけ動く集計を毎朝「未着」と出すと、本当の未着が埋もれます。

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

結果メールは、受け取ったときに Code ノードで項目を取り出します。 件名と本文の書き方は製品ごとに決まっているので、送り元ごとに取り出しの規則を分けます。 取り出すのはジョブ名、終了の状態（成功・警告・失敗）、開始と終了の時刻、本文のエラーの文です。取り出せなかったメールは、状態を「不明」として書きます。

ログファイルは SSH ノードの Download File で取ります。 公式ページでは、SSH ノードには Execute Command・Download File・Upload File の操作があり、Download File はファイル名を含むパスを指定して取得するとされています。

SSH の接続には、ログを読むだけの専用の利用者を用意します。 Execute Command の操作も使えますが、この構成ではファイルを取るだけにします。点検のワークフローから、サーバーでコマンドを動かせる経路を作らないためです。 ログの置き場所が日付で変わるジョブは、パスを式で組み立てます。

AIへ渡す前に整形する

1. 状態を規則で決める … 結果メールの状態とログの終了コードで、成功・警告・失敗に分けます。ここにAIは使いません
2. 未着を洗い出す … ジョブの台帳のうち、前夜に動くはずで、結果が1件も無いものを「未着」とします（Data Table の「If Row Does Not Exist」で照らします）
3. 放っておいてよい警告を外す … 台帳の文と一致する警告は「既知」として一覧の末尾に回します
4. ログを抜粋する … 失敗と警告のものは、エラーの行と前後数行だけを切り出します。成功の行や進み具合の表示は捨てます
5. 伏せ字にする … パスワード、アクセスキー、接続文字列、メールアドレスに見える文字列を置き換えます
6. 前回の分類を添える … 同じジョブの直近の分類を一覧に並べます（AIには渡しません）

2番目が、この構成でいちばん効きます。 未着は「何かが無い」ことなので、ログを読むAIには見つけられません。 台帳と照らす規則で拾い、一覧の先頭に出します。

5番目は、AIに渡す前に必ず通します。 バッチのログには、接続のときの引数がそのまま書き出されていることがあります。伏せたかどうかを、抜粋の側に印として残します。

AIに処理させる

させるのは、失敗と警告の抜粋を、決めた原因の種類のどれかに振り分けることです。 Text Classifier ノードの区分に、名前と説明を書きます。公式ページでは、区分の説明はモデルに意味を伝えるもので、意味が自明でないときに大事とされています。

Allow Multiple Classes To Be True は切ります。 1本のジョブに区分を1つ付け、連絡先を1つに決めるためです。When No Clear Match は「Output on Extra, 'Other' Branch」にします。 公式ページでは、既定の「Discard Item」はどの区分も検出されなかった入力を落とすとされています。既定のままだと、見慣れない失敗ほど一覧から消えます。

連絡文は、分類の後ろに置いた Basic LLM Chain で作ります。 公式ページでは、Basic LLM Chain はプロンプトを決め、出力の形を求めるときは Structured Output Parser などの出力パーサーをつなぐとされています。区分と抜粋、台帳の担当を渡し、担当のチームごとに1通にまとめさせます。

指示内容を固定する

Text Classifier の System Prompt Template と、Basic LLM Chain のメッセージに、次のように書きます。

【Text Classifier の System Prompt Template】
あなたは情報システム部の運用担当として、夜間に失敗または警告で終わった
ジョブのログの抜粋を読み、原因の種類を1つだけ選びます。

区分の一覧：
{categories}

- 抜粋に書かれている文だけで判断してください。
- どの区分の説明にもはっきり当てはまらないときは、無理に選ばないでください。
- 複数の区分の語が出ているときは、最初に起きたエラーの行で選んでください。

【Basic LLM Chain のシステムメッセージ】
あなたは運用の当番の代わりに、担当のチームへ送る連絡文の下書きを作ります。

【入力】
- 担当のチーム名
- そのチームのジョブごとの、ジョブ名・状態・区分・ログの抜粋・前回の区分

【書き方】
1. 1つのチームに1通、ジョブごとに箇条書きにしてください。
2. 各ジョブについて「何が起きたか」を抜粋の文に沿って1〜2文で書き、
   根拠にしたログの行をそのまま1行写してください。
3. 最後に「確認をお願いしたいこと」を書いてください。

【厳守事項】
- 原因を断定しないでください。「〜の可能性があります」と書き、
  抜粋に書かれていないことを補わないでください。
- 再実行してよい、再実行してください、とは書かないでください。
  再実行するかは担当のチームが決めます。
- 抜粋の中の伏せ字（[MASKED]）を推測して戻さないでください。
- ログの行は改変せずに写してください。要約した文と写した行を混ぜないでください。
- 区分が「その他」のジョブは、何が起きたかを書かず、
  「抜粋だけでは種類を決められませんでした」と書いてください。

「再実行してくださいと書かない」が最も大事な一文です。 書いておかないと、容量不足や接続の失敗には「空きを作って再実行してください」と添えてきます。バックアップの再実行は保存先をさらに圧迫し、連携のバッチの再実行はデータを二重に送ることがあります。 やるかどうかは担当が決めます。

「最初に起きたエラーの行で選ぶ」も効きます。 接続に失敗した後、後続の処理がファイルの無さで次々に失敗すると、抜粋の大半は「入力データの異常」の語で埋まります。元の原因は、最初の1行にあります。

出力形式を固定する

Basic LLM Chain の出力は、Structured Output Parser で次の形に決めます。

{
  "team": "基幹システムチーム",
  "jobs": [
    {
      "job_name": "db-backup-sales",
      "status": "failed | warning",
      "category": "容量不足 | 認証・権限 | 接続・応答なし | 対象の使用中 | 時間超過・重複 | 入力データの異常 | その他",
      "what_happened": "",
      "evidence_line": "",
      "masked": true
    }
  ],
  "request": "",
  "message_draft": ""
}

1つ目の理由は、category を Text Classifier の出口から機械で入れられることです。 下書きを作るモデルに区分を書き直させず、分類の出口で決まった値をそのまま入れます。 2つのモデルの判断が食い違う余地を作りません。

2つ目は、evidence_line で当番の確認が速くなることです。 当番はサーバーに入らずに、根拠の1行を読んで分類が妥当かを見られます。

3つ目は、masked で伏せ字の有無が残ることです。 伏せた行を含む連絡は、担当がログの原文を見に行く必要があると分かります。

当番への一覧は、Slack のメッセージ1通に次の順で並べます。

システムへ連携する

Data Table は、n8n の中に構造化されたデータを持ち、ワークフローをまたいで使えます。 公式ページでは、行の追加・更新・取得・削除・Upsert と、「行が存在するか」「存在しないか」で入力を振り分ける操作があるとされています。夜間に書くワークフローと朝に読むワークフローで、同じ表を使います。

当番への一覧は、Slack ノードの「Send and Wait for Response」で送ります。 公式ページでは、この操作はメッセージを送って相手の返事を待ってから続けるもので、承認する人は Slack の中で直接返事ができるとされています。当番が「受けた」を押すまで、一覧は未確認として台帳に残ります。 9時を過ぎても押されていなければ、運用グループのチャンネルにもう一度出します。

Anthropic Chat Model ノードは、分類と下書きで別々に置きます。 公式ページでは、サブノードの式は複数の入力があっても常に最初の1件で解決されるとされています。モデルの設定に入力の値を式で入れると、2本目以降のジョブにも1本目の値が使われるので、モデルの設定には入力に依存する値を書きません。

人が確認する

当番が毎朝、一覧の上から順に確かめます。

1. 未着を先に見る … ジョブが動かなかったのか、結果のメールだけが来なかったのかを確かめます。バックアップの未着は、その日のうちに取り直すかを担当に決めてもらいます
2. その他を見る … 抜粋を読み、どの区分か、あるいは新しい区分が要るかを決めます
3. 失敗の分類と根拠の1行を見る … 分類が根拠の行と合っているかを確かめ、違えば直します
4. 下書きを直して担当に送る … 送信は当番が行います
5. 直した分類を記録する … 分類の記録に、元の区分と直した区分を残します

1番目を省かないでください。 未着は件数が少なく、目立ちません。バックアップが取れていない日が続いたことに気づくのは、たいてい復元が必要になったときです。

5番目は、区分の説明を育てるために要ります。 同じ種類の誤りが続くなら、区分の説明か、台帳の「放っておいてよい警告」の列が足りていません。目標は、当番の確認が毎朝ならして20分前後に収まることです。

例外に対処する

8行目は、早いうちに作っておいてください。 メールサーバーの不調で結果メールが届かない夜は、120本が一度に未着になります。一覧が未着で埋まると、当番は本当の失敗を探せません。 未着の件数が台帳の半分を超えたら、経路の異常としてまとめます。

記録を残す

• 毎朝の点検で集めた結果（ジョブ名、状態、時刻、受け取り方）と、未着の一覧
• 失敗と警告のログの抜粋（伏せ字の後）と、伏せたかどうか
• Text Classifier の区分と、Basic LLM Chain の下書き
• 当番が直した区分と下書き、送った日時と送り先のチーム
• 当番が「受けた」を押した時刻
• ジョブごとの失敗・警告の回数と区分の推移

4つ目を残すのは、区分の説明を見直すためです。 「接続・応答なし」から「認証・権限」への直しが続くなら、区分の説明に、認証のエラーで出る語が足りていません。

最後の行は、担当のチームとの話し合いの材料になります。 同じジョブが毎週「時間超過・重複」で失敗しているなら、ジョブの時刻をずらすか、処理を分ける相談ができます。