──「つなぐだけ」から「設計する」へ。堅牢な自動化への第一歩

n8nにおけるPRDとは、ノードを配置し始める前に「何を入力し、どう加工し、何を出力するか」を定義する設計図です。 特にn8nは「前のノードの出力結果（JSON）」を次のノードが受け取るバケツリレー形式であるため、データ構造の定義が成功の鍵を握ります。

n8nは「直感的にノードをつなげば動く」という手軽さが魅力ですが、業務で本格運用する場合、その手軽さが仇となることがあります。設計図なしに継ぎ足しで作ったワークフローは、エラー時の挙動が不明だったり、担当者が変わると誰も触れなくなる「スパゲッティ状態」になりがちです。

これを防ぐのが、n8nに特化したPRD（製品要件定義書）です。 「データの流れ（JSON）」と「エラー処理」を中心に据えた、エンジニアリング視点での作成手順とテンプレートを解説します。

PRD作成の4ステップ

Step 1. ビジネスロジックの定義（Why & What）

いきなり「Webhookノードを置いて…」と考え始めてはいけません。まずは「何のために、何を実現するか」を言語化します。

  • 目的 (Objective): この自動化で誰のどんな時間を削減するのか？
  • トリガー (Trigger): 何がきっかけで動くのか？（定時実行？ フォーム送信？ メール受信？）
  • 成果物 (Output): 最終的にどうなっていれば成功か？（Slackに通知？ DBに行を追加？）

Step 2. データフロー設計（JSON Schema）

n8n特有の最も重要なステップです。各フェーズでデータがどのような形（JSON）になっているかを想定します。

  • 入力データ構造: Webhookで受け取るデータは { "name": "...", "email": "..." } なのか、配列なのか？
  • キー（Key）の統一: 複数のソース（Google SheetsとTypeformなど）からデータをマージする場合、共通のキー（例: email をユニークIDにする）を何にするか決める。

Step 3. ノード構成とロジック（Logic & Nodes）

ここで初めて具体的なn8nのノード選定に入ります。

  • 条件分岐: If ノードや Switch ノードでどのような条件判定を行うか。
  • 繰り返し処理: 複数のデータを処理する場合、Loop (Split in Batches) が必要か、それともAPI側が一括処理に対応しているか。
  • 外部API連携: HTTP Request ノードを使う場合、認証方式（Header Auth / OAuth2）とメソッド（GET/POST）は何か。

Step 4. エラーハンドリングと制約（Error & Constraints）

「正常に動く場合」だけでなく、「失敗した場合」を設計します。

  • エラー時の挙動: 途中でAPIがタイムアウトしたら？ エラー通知用のWorkflowを呼ぶか、無視して進む（Continue on Fail）か。
  • 制約事項: 外部APIのRate Limit（1分間に60回まで等）はあるか？ その場合 Wait ノードを入れるか。

n8n特有の設定上の留意点

PRDには、n8nの仕様に合わせた以下の「技術的制約」を明記する必要があります。

1. データの「配列（Array）」処理

n8nはデータを「オブジェクトの配列」として扱います。

  • 留意点: トリガーが「1件のデータ」を返すのか、「100件のリスト」を返すのかで、その後のノードの挙動が変わります。
  • PRDへの記載: 「入力がN件の場合、Loopノードを使用して1件ずつ後続処理を行う」等と明記する。

2. 認証情報（Credentials）の管理

  • 留意点: APIキーやパスワードを Set ノードに直接書き込んではいけません（セキュリティリスク）。
  • PRDへの記載: 「接続にはn8nのCredentials機能を使用し、キー名は Google_Sheets_Production とする」のように、使用するCredential名を定義する。

3. 冪等性（Idempotency）の確保

  • 留意点: ネットワークエラーなどでワークフローが誤って2回実行された場合、同じメールが2通飛んだり、二重請求が発生したりしないか？
  • PRDへの記載: 「処理済みIDをSpreadsheetで検索し、存在する場合は処理をスキップするロジックを組む」といった二重実行防止策を定義する。

n8nワークフローPRD テンプレート

# [Workflow Name] 要件定義書 (PRD)

## 1. 概要 (Overview)
* **目的:** [例: 問い合わせフォームからの内容を分類し、Slack通知とNotion保存を自動化する]
* **オーナー:** [作成者名]
* **更新日:** YYYY/MM/DD

## 2. フロー全体図 (High-Level Flow)
1. **Trigger:** Webhook (Typeform送信時)
2. **Process:** ChatGPTで内容を「クレーム」「質問」「要望」に分類
3. **Branch:** * クレーム → 緊急チャンネルへ通知 ＆ 上長へメール
    * その他 → 通知のみ
4. **Action:** 全件をNotionデータベースに追加

## 3. 技術仕様 (Technical Specs)

### A. トリガー (Trigger)
* **ノード種別:** Webhook / Schedule / App Trigger
* **頻度/条件:** [例: リアルタイム / 毎朝9:00]
* **想定入力データ (JSON):**
    ```json
    {
      "form_id": "xyz",
      "submitted_at": "2025-01-01...",
      "answers": { ... }
    }
    ```

### B. 主要ロジック & データ加工
* **データ整形:** Typeformの複雑なJSONを、フラットな `{name, email, body}` 形式に変換（Setノード）。
* **AI活用:** OpenAIノードを使用。プロンプトは「あなたはカスタマーサポートの責任者です...」と設定。
* **キーID:** ユーザーの特定には `email` を使用し、重複チェックを行う。

### C. 外部連携・認証 (Credentials)
* OpenAI API (Credential Name: `OpenAI_Prod`)
* Slack API (Credential Name: `Slack_Bot_User`)
* Notion API (Credential Name: `Notion_Integration`)

## 4. エラー処理 (Error Handling)
* **Global Error Workflow:** 使用する (Error Triggerノードを持つ別フローへ飛ばす)
* **HTTP Request:** タイムアウト時は3回までリトライ設定を行う。
* **通知:** エラー発生時は `alert-dev` チャンネルへ、エラー箇所のスクリーンショットURLと共に通知。

## 5. テスト項目 (Test Cases)
* [ ] 正常系：全てのデータが揃っている場合、Notionまで到達するか
* [ ] 異常系：メールアドレスが空の場合、適切にスキップされるか
* [ ] 境界値：AIが分類不能なテキストを返した場合、デフォルト値（"その他"）が入るか

PRDは「未来の自分」への手紙

n8nの画面を開く前に、このドキュメントを1枚書く。それだけで、手戻りは劇的に減ります。

特に、「どんなJSONが入ってきて、どう変わっていくか」を事前に書き出すことは、n8n習得の最短ルートでもあります。 PRDを書くことは、面倒な事務作業ではなく、自動化エンジニアとしての「設計力」を高めるためのトレーニングでもあると言えるでしょう。