AUTOMATION NOTE
n8n実装ポートフォリオ実機 / 5ケースを確認2026-08-13

Webhookから失敗・重複まで1本で処理する

結論：問い合わせ自動化は、再試行と重複防止を分ければ、障害時にも同じ問い合わせを二重作成しにくい。n8nで受付フローを作る人向けに、5つの動作確認結果、構成、再現手順を公開する。

38,000円のワークフロー診断を相談する入力済みメールで相談する

実行が止まる、二重に動く、成功表示と結果が違う。最初は期待した結果・実際の結果・秘密値を除いたエラー文だけ送る。送信だけでは契約・決済にならない。

このページが合う人：受付は動くのに同じ問い合わせが2件できる、APIが一時的に失敗したときの戻り方が分からない、という状態。

分かること：正常、一時障害、重複、継続障害、入力不正の5ケースで、返す応答と保存結果を表で確認できる。

先に用意するもの：受付Webhook、必要な問い合わせ項目、同じ受付を見分けるキー、個人情報を含まないテストデータ。

次の行動：既存ワークフロー1本を見直すなら、ワークフロー診断（38,000円）の対象を見る。最初は期待した結果、実際の結果、n8nのバージョンを送る。実装まで必要な場合は、別の範囲で確認する。

実際に動かす場所が決まっていない場合は、n8n Cloudとセルフホストの違いを先に確認する。止まったときの更新・復旧を誰が担当するかで選ぶ。

38,000円のワークフロー診断を相談するメールで直接相談する

確認した範囲：外部サービスと接続しない検証環境で、合成データを使って動かした技術例。顧客案件の実績ではない。実在の個人情報、資格情報、外部SaaS、AI APIは使っていない。第三者アフィリエイトリンクなし。

結論：5つの状況を分けて動作を確認

n8n 2.33.7のWebhookへ合成問い合わせを送り、正常、一時障害からの復旧、重複、継続障害、入力不正を確認した。上流APIは同じinternal networkのモック。外部ネットワークには出ていない。

正常2021件作成
一時5033回目再試行後に成功
重複0件増既存ticket返却
異常400 / 502入力 / 上流を分離
試験期待実測
正常問い合わせを1件作成202 / created
一時障害503を再試行し復旧503×2 → 3回目created
重複同じcase_idを二重作成しない202 / duplicate / 保存件数不変
継続障害3回失敗後に上流障害を返す502 / upstream_unavailable
入力不正上流APIを呼ばず拒否400 / rejected / API試行0

実装した10ノード

n8n 2.33.7で実装した問い合わせ振り分けワークフロー。Webhook、入力検証、IF、HTTP Request、正常・入力不正・上流障害の応答分岐を表示
実際に読み込み・公開・実行したn8n 2.33.7の編集画面。画面内に資格情報・個人情報なし。撮影後、一時環境はデータ領域ごと削除。
  1. Receive Inquiry：POST WebhookでJSONを受ける。
  2. Validate and Normalize：Code nodeで必須項目、長さ、case_id形式を検証し、4カテゴリへ固定分類する。
  3. Is Valid：正常系と入力不正を分ける。
  4. Route Through Mock API：HTTP Requestで内部APIへ送る。timeout 3秒、最大3回、250ms間隔。
  5. Build Accepted Response：作成・重複の応答を整形する。
  6. Respond Accepted：受付結果を202で返す。
  7. Build Rejected Response：不正項目だけを返し、入力本文を再掲しない。
  8. Respond Rejected：入力不正を400で返す。
  9. Build Upstream Failure：内部エラー詳細を公開せず、固定エラーへ変換する。
  10. Respond Upstream Failure：上流継続障害を502で返す。

再試行と重複防止を分ける

HTTP Requestは503を最大3回まで再試行する。一時障害ケースは1回目・2回目が503、3回目に作成成功。継続障害ケースは3回とも503で、n8nがerror outputへ流し、Webhookには502を返した。

重複防止はcase_idを冪等キーとしてモックAPI側で実装。同じ問い合わせを再送すると新規作成せず、既存チケットとduplicate: trueを返す。HTTP Requestノードの再試行だけでは二重作成を防げないため、受信先でも同じ問い合わせを判定できるようにした。

本番化時：このモックは逐次実行。並列リクエストではDBの一意制約や、競合しても1件だけ登録する処理が必要。外部APIが冪等キー非対応なら、状態変更処理の自動再試行をそのまま有効にしない。

入力と出力

入力はcase_id、subject、bodyの3項目。出力は受付可否、状態、case_id、ticket_id、category、needs_review、duplicateへ限定した。

POST /webhook/portfolio-inquiry-routing
{
  "case_id": "case-normal-001",
  "subject": "請求書の確認",
  "body": "今月分の請求金額を確認したい。"
}
HTTP 202
{
  "ok": true,
  "status": "created",
  "case_id": "case-normal-001",
  "ticket_id": "ticket-case-normal-001",
  "category": "billing",
  "needs_review": false,
  "duplicate": false
}

成果物をダウンロード

GitHubで3つのワークフローを見る再現Dockerラボ / README / 更新履歴workflow.jsonn8n 2.33.7書き出し / 非公開 / 認証情報なしsummary.json5系統の結果 / 8回のAPI試行監査README.md再現・実API置換・限界SHA256SUMSワークフロー・結果概要の完全性確認

ダウンロード用ワークフローは非公開状態。認証情報オブジェクトなし。URLは環境変数PORTFOLIO_MOCK_API_URLから読む。APIキーを使う実装へ変える場合はn8nの認証情報へ登録し、書き出したJSONへ秘密値を入れない。

この実装が示さないこと

  • 顧客案件、受託実績、本番SLA、長期安定性
  • 実在データ、個人情報、外部SaaS、OAuth、APIキー管理
  • AI分類品質、共通ベンチ100件の分類・要約精度
  • 並列実行、DB一意制約、高可用性、監視、夜間復旧

Cowork・Make・n8n共通ベンチは3製品とも実行確認前。このポートフォリオの固定ルール分類を、そのAI比較結果として扱わない。

公式情報

FROM LAB TO PRODUCTION

まず、止まっている
1件を送る。

実行が止まる、二重に動く、成功表示と結果が違う。既存ワークフロー1本の診断は38,000円。問題点、直す順番、確認方法を文章で返す。実装まで必要なら別の範囲で見積もる。

38,000円のワークフロー診断を相談する実装まで必要なら範囲を見る

動作確認：n8n 2.33.7 / 合成データ / 外部ネットワークなし / 顧客データなし / 2026-08-13 JST