n8nのワークフローをJSONでバックアップ復元・認証の確認手順

JSONで戻せるのは、処理の組み立て。認証や履歴は分けて考える。

ワークフローは「どの処理を、どんな設定で、どの順番につなぐか」という組み立てです。JSONは、その情報を文字として保存する形式。ダウンロードしたファイルがあれば、別の編集画面へ処理の形を持ち運べます。

ただし、GoogleやSlackへ接続するためのCredential（認証情報）の名前が見えても、接続に使う秘密値まで移ったという意味ではありません。公式のExport and importも、ワークフローJSONに認証情報の名前・IDが含まれることと、共有時の点検を案内しています。

確認した2.38.4のJSON出力処理にはpinDataや設定が含まれます。一方、File Importの処理は保存項目をすべてそのまま復旧するものではありません。「ファイルに入る範囲」と「取り込んで戻る範囲」を分けて確認します。

サーバー故障から環境全体を戻す話は、ここで扱う1件のJSON取り込みとは別です。データベースと暗号化キー、実ファイル、設定、導入ノードまで含めた計画が必要になります。まずは、元のn8nがまだ開ける状態での保存練習から始めます。

活用例：ブログの下書き情報を作る2ノードで練習する。

いきなり本番の投稿フローを取り込むと、古い宛先へ送信するおそれがあります。ここでは、記事の識別用コード・仮タイトル・確認状態の3項目を作るだけにします。これはブログ自動化の一部分を切り出した教材で、AIに本文を作らせる工程は含みません。

必要なのは、すでに利用できるn8nと、新しいワークフローを作成・編集・手動実行できる権限、JSONを保存できるPCです。この練習には外部サービスのAPIキーやAIモデルは不要です。n8nの利用料・実行上限は契約次第なので、無料とは一律に扱いません。所要時間は未計測です。

1. 1

   新しい練習用フローを作る

   ワークフロー一覧から新規作成し、名前を「ブログ下書き情報・保存練習」にします。最初のトリガーで手動開始を選び、Manual Triggerを置きます。本番フローの中身は変更しません。

2. 2

   Edit Fieldsを接続する

   Manual Triggerの後ろへEdit Fields（Set）を追加します。ModeでJSONを選び、JSON欄に下の入力例を入れます。項目名も値も固定値です。式や外部データを使わず、Include Other Input FieldsをOFFにして、今回作る項目だけを出します。

3. 3

   実行前にノードを数える

   Manual TriggerとEdit Fieldsの2個だけが、1本の線でつながっていることを確認します。HTTP Request、メール、AIモデル、Schedule Triggerなどがあれば、この練習用の構成とは別です。追加ノードのまま実行せず、空の練習フローへ戻ります。

公式Docsや旧画面ではModeがJSON Outputと案内されることがあります。また、Include in Outputという選択欄がある旧版ではNo Input Fieldsを選びます。上の手順は2.38.4の新規ノードの設定名に合わせています。

{
  "case_id": "LAB-RESTORE-001",
  "article_title": "来週のブログ案",
  "review_status": "draft"
}

この練習の「同じ入力」とは、Edit Fieldsに入れたこの固定JSONです。実行のたびに別ファイルやイベントを渡す必要はありません。ボタンで開始すると、同じ3項目を1件作ります。

Manual Triggerは手動開始、Edit Fieldsは値を作成・上書きするノードです。Manual Triggerを選んでも後段の処理が自動で安全になるわけではないため、この例では外部操作を含めていません。

一度出力を確かめて保存し、空の別フローへ取り込む。

完成形が決まったら、保存前の出力を比較の基準にします。ここからは同じ練習用フローだけを扱い、「保存元」と「取り込み先」を混ぜないことが大切です。

1. 1

   保存前に手動で実行する

   2ノードの出力がピン留めされていないことを確認します。表示がある場合は次の章のUnpin手順で解除します。キャンバスのExecute Workflowで開始し、Edit FieldsのOUTPUTをJSON表示に切り替えます。下の出力例と同じ3項目・値が1件出ることを確認します。

2. 2

   保存状態を確認してDownloadする

   現行の公式案内では編集内容は自動保存されます。保存中やエラーの表示が残っていないことを確認し、右上の三点メニューからDownloadを選びます。PCへ保存されたJSONを「blog-draft-before-change-2026-09-09.json」など、用途と日付が分かる名前で保管します。

3. 3

   保存した対象をメモする

   元フローの名前、ノード2個、n8nのバージョン、保存日時、直前の出力を一緒に残します。Downloadは現在の編集内容を保存する操作です。公開中の版と編集中の版が違う本番フローでは、どちらを残したか分からないまま「本番バックアップ」と呼ばないでください。

4. 4

   空の新規フローへImport from Fileする

   一覧へ戻って別の新規ワークフローを開きます。File Importは現在のキャンバスへノードを追加するため、必ず空の状態で進めます。右上の三点メニューからImport from Fileを選び、先ほどDownloadしたファイルを指定します。この記事の入力JSONではなく、n8nから保存したフロー全体のJSONです。

5. 5

   名前・ノード・接続を確認する

   取り込み先を「ブログ下書き情報・復元確認」に変更し、元フローとは別物として残します。2個のノード、1本の接続、Edit FieldsのJSONが保存前と一致するか見ます。この段階ではまだ「取込を確認」で、実行確認は次です。

[
  {
    "case_id": "LAB-RESTORE-001",
    "article_title": "来週のブログ案",
    "review_status": "draft"
  }
]

メニューの根拠は公式のエクスポート・インポート手順、保存と公開の区別はSave and publish workflowsです。古い版の画面とボタン名が異なる場合は、その版の案内を確認します。練習用フローをPublishする必要はありません。

戻したフローで実行し、3項目を一つずつ照合する。

取り込み後も、Manual TriggerとEdit Fieldsだけの構成を確認します。各ノードを開き、OUTPUT上部にThis data is pinnedというバナーがあれば、その中のUnpinを選んで解除します。保存前の確認でも同じ操作です。公式のピン留め解除手順

解除後にExecute Workflowを押し、Edit FieldsのOUTPUTをJSON表示にして値を見ます。手動実行では、ピン留めされたノードを動かさず固定出力を使うことがあるためです。過去の出力ではなく、新しい実行で照合します。手動実行とPin Dataの仕様

• 件数は1件か空でも2件でもなく、この練習の入力に対応する1件を確認。
• case_idはLAB-RESTORE-001かどのテストデータかを見分ける識別用コード。
• article_titleとreview_statusは一致するか「来週のブログ案」と「draft」を文字列として照合。
• 新しい実行の結果か実行日時・実行IDなどで、保存前の結果と区別。

値が一致したら、「この2ノードの設定を取り込み、同じ出力を確認できた」と記録できます。Google認証の復旧、記事公開、AIの回答品質、サーバー全体の復元は、この練習では確かめていません。合格の範囲を小さく書くほど、次に試すものが明確になります。

実際の自動化へ応用するときは、認証と参照先を先に見る。

練習ができたら、実フローでは何が増えるかを点検します。たとえば「Google Sheetsから記事案を読む → 文章を整える → Slackへ送る」なら、ノードだけでなく、Googleの接続、シートの場所、Slackの接続と送信先が必要です。

別のn8nなら必ず未接続になる、とも限りません。確認した2.38.4の認証情報の自動選択処理では、ノードによって既定の接続が選ばれる経路があります。取り込み後は、認証欄の名前だけでなく、接続先アカウントと実際の宛先を確認します。

本番フローの複製は、手動実行でも送信や更新を起こせます。「Publishしていないから安全」とは判断しません。まず外部操作と依存先を洗い出し、許可されたテスト環境が用意できるまで実行しないでください。

また、現行公式資料には、公開済みフローの設定だけを更新すると自動で再公開される場合があると記載されています。確認のために本番のSettingsを変えるのではなく、別の未公開フローで進めます。保存・公開の公式仕様

復元後に動かないときは、ファイル・構成・接続の順に分ける。

エラーが出ても、元の認証情報を削除したり、フローを何度も取り込んだりする前に、止まった段階を確認します。下の表は切り分けの出発点で、表示されたエラーだけから原因を断定するものではありません。

確認票には「戻ったもの」と「まだ試していないもの」を残す。

次の改修時に役立つのは、ファイル名だけでなく、どの条件で何が動いたかの記録です。先ほどの練習なら、実行して値が一致した後に「2ノード・接続1本・出力1件・3項目一致」と書けます。試す前から成功欄を埋めないでください。

記録に迷ったら、まず実行ボタンを押した時刻をPCの時計でメモし、その直後の出力を残します。実行IDは確認できる場合だけ併記すれば十分です。n8nの版が分からないときは推測せず「未確認」とし、別環境へ移す前に管理者へ確かめます。

確認日時 / n8nのバージョン:
元のフロー名 / 保存した版・時刻:
ファイル名 / 保管先（秘密値を書かない）:
取込先のフロー名:
ノード名・本数・接続は一致したか:
固定データ（Pin）の有無と解除:
使用したテスト入力 / 期待する出力:
実際の出力 / 実行日時または実行ID:
認証・参照先・送信先で未確認のもの:
今回確認できた範囲:
次に確認する項目:
本番の自動実行を再開したか: いいえ / はい（別判断）

自分用のバックアップと、他人に渡す共有用コピーも分けます。共有前には、認証情報名、HTTPヘッダー、URLのクエリ、ノードに直書きした鍵、pinDataの固定出力、業務上の内容を点検します。秘密値が含まれないと確認する前に、GitHubやチャットへ貼りません。