n8nの実行と履歴を理解する｜保存・公開・Executionsの基本

n8nでWorkflowを作れるようになったら、次に理解したいのが「そのWorkflowは今どの状態にあるのか」です。

画面上にnodeを並べ、Execute Workflowで正常に動かせても、それだけで自動化が稼働しているとは限りません。

Workflowを編集した
≠ 本番で使われている

手動実行に成功した
≠ 自動的に動き続ける

n8nでは、編集内容の保存、手動テスト、本番公開、自動実行、実行履歴の確認を分けて考える必要があります。

この記事では、Save、Active、Publish、manual execution、production execution、Executionsの関係を整理します。

今日の到達点

この記事を読み終えると、次の違いを説明できるようになります。

• Workflowの編集内容が保存されることと、本番公開されることの違い
• Execute Workflowによる手動実行と、triggerによる本番実行の違い
• 旧UIで使われるActiveと、現在のPublishの関係
• Executions画面で成功・失敗・実行中などの状態を確認する方法
• 過去の実行から失敗したnodeと入出力を追跡する方法

Workflowには複数の状態がある

Workflowの状態は、単純な「完成」「未完成」の2種類ではありません。

少なくとも、次の4つを分けて考える必要があります。

この区別が曖昧だと、「直したはずなのに本番の動作が変わらない」「保存したのに自動実行されない」といった混乱が起きます。

Saveとは何か

現在のn8n公式ドキュメントでは、Workflowの変更は編集中に自動保存され、通常は1〜5秒程度でDraftへ反映されます。基本的に、編集のたびに手動でSaveボタンを押す必要はありません。

ただし、自動保存された変更はDraftです。

nodeを変更する
→ Draftへ自動保存される
→ Publishするまで本番版は変わらない

ここでいう「保存」は、編集内容を失わないための処理です。「この変更を本番で使う」という指示ではありません。

環境やn8nのバージョンによってはSaveボタンや保存操作が表示されることがあります。その場合でも、次の2つを分離して確認してください。

• 編集内容が保存されたか
• 保存された内容が本番へ公開されたか

ActiveとPublishの関係

過去のn8n記事や旧UIでは、Workflowを自動実行可能にする操作として「Activeにする」「Active toggleをONにする」と説明されていることがあります。

現在の公式ドキュメントでは、Workflowを本番稼働させる操作は主にPublishとして説明されています。

Publishすると、Workflowの特定versionが本番用として固定されます。以後のproduction executionは、編集中の最新Draftではなく、現在Publishedになっているversionを使います。

Draft v3 ──Publish──> Production v3

その後Draft v4へ編集
→ Productionはv3のまま
→ v4をPublishすると本番がv4へ更新

この仕組みにより、動いている本番Workflowへ編集中の変更が即座に混入するのを防げます。

「Active」という言葉が出てきた場合

利用環境にActiveの表示がある場合は、「triggerを待ち受けて自動実行できる状態」という意味で使われている可能性があります。

ただし、現在のUIではPublish／Published／Unpublishという表現が中心です。古い記事のActiveをそのまま操作名として探すのではなく、次を確認します。

• WorkflowがPublishedになっているか
• triggerが自動起動に対応しているか
• 未公開の変更が残っていないか
• production用URLやscheduleが有効になっているか

手動実行とは何か

手動実行は、エディター上でExecute Workflowを選択してWorkflowを動かす方法です。

主な目的は、Workflowを作成・変更している途中のテストです。

人がExecute Workflowを選択
→ Workflowが実行される
→ キャンバス上でデータの流れを確認する

手動実行では、各nodeのINPUTとOUTPUTを見ながら、条件分岐、データ変換、繰り返しなどを確認できます。

特定nodeだけを試したい場合は、node詳細画面からExecute stepを使います。これはpartial executionと呼ばれ、対象nodeと、その入力を準備するために必要な前段nodeを実行します。

手動実行は、PublishedになっていないWorkflowでも使用できます。

本番実行とは何か

production executionは、外部イベントや設定時刻などをtriggerとして、自動的に開始される実行です。

たとえば、次のような実行が該当します。

• Schedule Triggerが指定時刻に起動した
• Webhookへリクエストが届いた
• 外部アプリで対象イベントが発生した
• polling triggerが新しいデータを検出した

本番実行には、Manual Trigger以外の適切なtriggerを接続し、WorkflowをPublishする必要があります。

trigger条件が成立
→ Published versionを読み込む
→ production executionを開始
→ 結果をExecutionsへ記録

PublishedになっていないWorkflowは、trigger条件が成立しても本番用Workflowとして自動実行されません。

手動実行と本番実行の違い

実行数の計算方法や保存期間は、利用planや運用環境によって異なる場合があります。Cloud版とself-hosted版を同じ条件だと決めつけず、使用環境の設定を確認してください。

Executionとは何か

executionとは、Workflowが1回動いた記録です。

同じWorkflowを3回実行すれば、基本的には3件のexecutionが発生します。

1回目：Success
2回目：Success
3回目：Failed

Workflowは設計図、executionはその設計図を使った1回分の実行結果と考えると分かりやすいでしょう。

Executions画面で確認できること

Workflowを開き、上部メニューのExecutionsタブを選択すると、そのWorkflowの実行一覧を確認できます。

OverviewまたはProject内のExecutionsからは、アクセス可能な複数Workflowの実行を横断して確認できます。

現在の公式ドキュメントでは、Executionsを次のstatusで絞り込めます。

• Failed
• Running
• Success
• Waiting

さらに、実行開始時刻、Workflow名、保存済みのcustom dataなどで絞り込める場合があります。custom dataによる検索はplanや環境によって利用条件が異なります。

Successだけで正常と判断しない

Successは、Workflowがエラーで停止せず最後まで実行されたことを示します。

しかし、業務上期待した結果が得られたことまで保証するものではありません。

たとえば、次の状態でもexecution自体はSuccessになる可能性があります。

• 対象データが0件だった
• 条件分岐が想定と違う経路へ進んだ
• 誤った値を正常にデータベースへ保存した
• 通知文面に必要なfieldが含まれていなかった

したがって、statusだけでなく、重要なnodeのINPUT／OUTPUTと最終結果も確認します。

Failed executionの読み方

失敗したexecutionを開いたら、次の順序で確認すると原因を絞り込みやすくなります。

失敗したnodeを特定する

最初に、どのnodeで処理が停止したかを確認します。

エラーメッセージを確認する

エラーの種類、status code、認証エラー、必須値不足など、表示された事実を読みます。

INPUTを確認する

失敗したnodeへ、想定していたfield、値、型が渡されているか確認します。

node設定を確認する

Expression、credential、URL、operation、条件式などを確認します。

OUTPUTまたは直前nodeを確認する

問題が発生したnodeだけでなく、直前のnodeが誤ったデータを出力していないか確認します。

失敗node
← そのINPUT
← 直前nodeのOUTPUT
← さらに前のデータ変換

エラーが表示されたnodeだけが原因とは限りません。前段で作られた不正なデータが、そのnodeで初めて問題として表面化する場合があります。

実行履歴とWorkflow履歴は別物

ExecutionsとWorkflow historyは異なります。

「昨日の実行がなぜ失敗したか」を調べる場合はExecutionsを確認します。

「昨日はどのnode構成だったか」を調べる場合はWorkflow historyを確認します。

過去のexecutionを使ってデバッグする

対応planや環境では、過去executionのデータを現在のエディターへ読み込み、再現確認に利用できます。

失敗したexecutionではDebug in editor、成功したexecutionではCopy to editorを利用できる場合があります。

過去データを読み込むと、同じ入力に近い条件でnode設定を修正し、再実行できます。外部サービスから同じデータを再取得できない場合や、再現しにくい本番エラーの調査に有効です。

ただし、execution dataの保存設定やredaction設定によっては、過去のINPUT／OUTPUTが保存されていない、または非表示になっている場合があります。

実行履歴が残らない場合に確認すること

Executionsに期待した履歴が表示されない場合は、Workflow settingsを確認します。

n8nには、次のような保存設定があります。

• failed production executionを保存するか
• successful production executionを保存するか
• manual executionを保存するか
• 各nodeのexecution progressを保存するか
• production／manual execution dataをredactするか

保存設定は、障害調査のしやすさ、ストレージ使用量、処理負荷、データ保護のバランスに関係します。

すべてを無期限に残すのではなく、どの履歴が必要かを運用目的から決める必要があります。

意図的に成功と失敗を作る最小実習

Day 1で作成したWorkflowを使い、同じWorkflowを複数回実行します。

Manual Trigger
→ Edit Fields

まず、そのまま2回実行し、Successになったexecutionを確認します。

次に、学習用として一時的にCode nodeを追加し、明示的なエラーを発生させます。

throw new Error('Day 2 practice failure');

Manual Trigger
→ Edit Fields
→ Code（意図的なエラー）

この状態で手動実行すると、Code nodeで失敗するはずです。実際のn8n画面でFailed executionとエラー内容を確認してください。

確認が終わったら、学習用のCode nodeを削除するか無効化し、元のWorkflowへ戻します。

デバッグ時の最小チェックリスト

Workflowが想定どおりに動かない場合は、次の順番で確認します。

• 対象executionはManualかProductionか
• 実行された日時とstatusは何か
• 本番ではどのPublished versionが使われたか
• 最初に失敗したnodeはどこか
• エラーメッセージには何と表示されているか
• 失敗nodeのINPUTに必要なfieldがあるか
• fieldの値とデータ型は正しいか
• 直前nodeのOUTPUTは正しいか
• Draftだけを直してPublishを忘れていないか
• execution dataの保存・redaction設定で情報が隠れていないか

推測で設定を変更する前に、executionへ残された事実を上流から順番に確認することが重要です。

実務での考え方

実務では、Workflowの編集と本番反映を明確に分けます。

安全な基本フローは次のとおりです。

Draftを編集
→ 手動実行で確認
→ INPUT／OUTPUTを確認
→ 必要なら失敗条件も確認
→ Publish
→ production executionを監視

本番障害が起きたときは、「今のDraft」ではなく「そのexecutionが実際に使ったPublished version」を確認します。

また、外部APIへの書き込み、メール送信、データ削除などを含むWorkflowでは、テスト実行でも実処理が発生する可能性があります。テスト用データ、送信先、実行範囲を制御できる構成にしておくと、確認作業を繰り返せます。

今日の実習で確認すること

実際のn8n環境では、次の項目を確認してください。

• Day 1のWorkflowを2回以上手動実行する
• 編集内容が自動保存されるタイミングを確認する
• Publishまたは利用環境のActive設定の位置を確認する
• DraftとPublished versionの違いを確認する
• 意図的に1回失敗させる
• ExecutionsからSuccessとFailedを開く
• 失敗node、エラーメッセージ、INPUTを確認する
• 実際のUIと記事の表現に差があれば記録する

実習結果は、次のように構造化して残せます。

workflow_name: "n8n Practice Day 1 - First Workflow"

manual_executions:
  success_count: 2
  failed_count: 1

save_behavior: "observed result"
production_state_label: "Publish or Active label shown in UI"
failed_node: "observed node name"
error_message: "observed message"
execution_data_available: true
ui_differences: []
questions: []

まとめ

n8nでは、Workflowを編集したこと、保存したこと、手動実行したこと、本番公開したことを分けて考える必要があります。

現在のn8nでは、編集内容はDraftへ自動保存され、Publishした特定versionがproduction executionで使用されます。古い記事や環境にあるActiveという表現は、自動実行可能な状態を示す用語として理解し、現在のPublish状態と対応づけて確認します。

Executionsは、Workflowの実行結果を追跡するための記録です。SuccessやFailedというstatusだけでなく、実行されたversion、失敗node、INPUT、OUTPUT、エラーメッセージを確認することで、原因を推測ではなく事実から追跡できます。

作る
→ 保存される
→ 手動で試す
→ Publishする
→ 自動実行を履歴で追う

この流れを理解すると、Workflowを「一度動いた処理」から「継続的に管理できる自動化」へ進化させられます。

参考資料

• n8n公式：Create and run workflows
• n8n公式：Save and publish workflows
• n8n公式：Understand executions
• n8n公式：Types of executions
• n8n公式：View executions for a single workflow
• n8n公式：Debug executions
• n8n公式：Configure workflow settings