n8n・自動化
n8nワークフローの作り方｜業務フローから安全な自動化へ落とす手順
公開日： 更新日：
n8nの画面でノードをつなぐ前に、現行業務を「入力・処理・判断・出力・例外」に分けます。自動化が止まる原因の多くは、API接続より「入力が想定と違う」「誰が例外を判断するか決まっていない」といった業務設計の不足です。
ステップ1：現行業務を5要素で書く
| 要素 | 確認する質問 | 例 |
|---|---|---|
| 入力 | 何をきっかけに、どんなデータが来るか | フォーム送信、定時実行 |
| 処理 | 転記・整形・照合のどれを行うか | 日付形式を統一 |
| 判断 | 条件と判断者は誰か | 未承認なら担当へ戻す |
| 出力 | どこへ何を保存・通知するか | 台帳へ追記、チャット通知 |
| 例外 | 失敗時に止めるか続けるか | 必須値欠落なら停止 |
ステップ2：一つの目的に絞る
最初のワークフローへ受付、承認、集計、レポート、AI判定をすべて入れないでください。「承認済み申請を毎日一覧化する」のように、完了条件が一文で言える単位にします。長くなったらサブワークフローへ分割し、入出力を固定します。
ステップ3：ノード名で業務を説明する
- 「Google Sheets」ではなく「承認済み申請を取得」
- 「IF」ではなく「必須項目がそろっているか」
- 「HTTP Request」ではなく「顧客台帳へ登録」
- 「Slack」ではなく「経理担当へエラー通知」
ツール名ではなく業務上の動作を書くと、n8nに詳しくない担当者でも処理を追えます。ワークフロー名には対象業務、起動頻度、本番／検証の区分を含めます。
ステップ4：正常系より先に例外を書く
| 例外 | 止める条件 | 対応 |
|---|---|---|
| 必須値欠落 | 対象IDや処理日がない | 登録せず担当へ通知 |
| 重複 | 同じ受付IDが存在 | スキップして履歴を残す |
| 外部API失敗 | 規定回数の再試行後も失敗 | エラー用フローへ送る |
| 部分成功 | 保存済みだが通知失敗 | 保存処理を繰り返さず通知だけ再試行 |
| 判断不能 | 条件に当てはまらない | 人の確認キューへ送る |
ステップ5：テストケースを用意する
- 正常な入力1件
- 必須項目が欠けた入力
- 同じIDの重複入力
- 想定外の文字・長い文字列・空欄
- 外部サービスが応答しない場合
- 途中まで処理済みのデータ
ステップ6：運用情報をワークフローと一緒に残す
- 目的と対象業務
- 所有者と障害時の連絡先
- 起動条件と実行頻度
- 利用するCredentialと権限
- 入力元・出力先
- 停止方法と手作業への切替手順
- 変更履歴と最終テスト日
本番稼働後は実行履歴を定期的に確認し、失敗件数、処理時間、手動対応件数を見ます。ワークフローを削除すると実行履歴も削除されるため、削除前に必要な記録の保管方針を確認してください。
給与計算へ応用するときの境界
給与計算のように個人情報と重要な金額を扱う業務では、通知・回収・差異抽出から始め、最終確定は人が承認します。具体的な構成は給与計算をn8nで自動化する設計を参照してください。