n8n インターフェースガイド：キャンバス、ノード、実行履歴はそれぞれ何を示すか
n8n をインストールしてログインすると、最初は戸惑う：左側にアイコンだけの細いバー、中央に大きなドットグリッド、右上にグレーアウトした「公開」、下部にオレンジ色の「実行」がある。どこもクリックできそうで、クリックしても先ほど何が起きたのか説明できない。
この記事では、実際に進む順序で一通り見ていく：まず左側、次にキャンバス、その後ノードをダブルクリックし、最後に実行履歴を確認する。
目標は具体的だ——読み終えたときに、次の3つを区別できるようになる：自分が変更しているのはフロー、自分が実行しているのはある1回の実行、自分が確認したいのはどの実行でエラーが出たかこの3つを区別できれば、後でノードを学ぶときの労力が半分で済む。
n8n を開けるようになったが、まだワークフローを一度も正常に実行できていない人向け。前の記事に従ってインストールしたばかりの人に最適で、コードを書く必要はない。
- 左側のアイコン列
- キャンバス上で実際に使えるもの
- ノードを追加する：検索ボックスに英語を入力する
- ノードをダブルクリックした後：4つのタブ
- 実行履歴が何を伝えているか
- 手動実行と本番実行を混同して見ない
- 4つの操作で、本当に理解できたかを確認する
- ハマりやすい6つの落とし穴
- UIに関する2つのセキュリティ問題
UIは3つの概念に沿って配置されている
n8nで本当に覚えておくべきものは3つだけ：ワークフロー（あなたが書いたそのフロー）、ノード（フロー内の1ステップ）、実行（このフローが1回実行されたもの）。
UIはこの3つの投影だ。左側はリソースを管理し、ワークフロー、認証情報、実行履歴はすべてそこに保存される；中央はフロー自体；ノードパネルは「このステップで何をするか」に答える；実行履歴は「前回どのように実行されたか」に答える。配置は乱れて見えるが、実際にはこれに基づいて分けられている。
最も混同しやすいのは「ワークフロー」と「実行」だ。ワークフローを変更しても、すでに完了した実行履歴は変わらない。1回実行してもワークフローは変わらない。2つは別物だ。
私のこのインスタンスはセルフホストの2.43.7で、UI言語は簡体字中国語に設定している。先に1つ細かい点を明確にしておく：中国語化されているのは外側だけで、ノードパラメーターは依然として英語だ——Mode、Fields to Set、Include Other Input Fields といった一連。見ても言語パックが間違っていると思わないでほしい。ノード検索も同じで、英語名を入力したほうがヒット率が高い。
左側のアイコン列
デフォルトでは折りたたまれていて、アイコンだけが表示され、マウスを近づけるとツールチップが出る。一番上にある矢印付きのボタンをクリックすると展開でき、展開後はこうなる：
90%の時間は「個人」の中だけにいることになります。自分のワークフロー、認証情報、実行履歴、変数、データテーブルはすべて「個人」のページにあり、タブで切り替えられるので行き来する必要はありません。
「概要」ページは上司に見せるためのもので、本番実行回数、本番実行の失敗数、故障率、平均実行時間を表示します。インストール直後のインスタンスではすべて0で正常です。本番実行だけを集計し、手動でクリックした数回は含まれません。初めて0の並びを見たときは、インスタンスが動いていないのかと思いました。
翻訳について補足すると、「製品実行」のカードは英語原文が production executions で、本番公開後にトリガーによって実行されるものを指します。「製品」という意味ではありません。
設定は一番下にあり、最も見つけにくい場所です。パスワード変更、言語変更、バージョン確認はすべてそこから入ります。
キャンバス上で実際に使えるもの
ワークフローを開くと、中央のこのドット状の領域がキャンバスです。私のこのデモフローは3つのノードで構成されています：
上部の行：一番左は「個人 / ワークフロー名」で、名前をクリックすると直接変更できます。中央は3つのタブ「エディター / 実行 / 評価」、右上は「公開」です。
中央のこのタブ列は説明する価値があります。「エディター」はフローを描く場所、「実行」はこのワークフローの過去の実行、「評価」はテストデータのバッチで繰り返し実行し、結果が安定しているかを見る機能です。3つ目はAIワークフローを作っている友人が使っていますが、私は今までまともに触ったことがないので、いったん置いておきます。
右上の「公開」は 2.x で変更された設計です。古いチュートリアルにある Active スイッチはもうありません。編集時は自動で下書きを保存し、通常1〜5秒以内にディスクへ書き込み、「公開」をクリックして初めて現在のバージョンを本番に反映します。本番実行は公開済みのバージョンだけを対象にします。ボタンがグレーなのは公開できる変更がないという意味で、壊れているわけではありません。
右側の縦一列の5つのボタン：ノード追加、コマンドバー（Ctrl/Cmd + K、ノードもアクションも検索できます）、付箋、フォーカスパネル、AI。左下はビューに合わせる、拡大、縮小、接続線を整理（Tidy up）で、中央下のオレンジ色の「実行」がフロー全体を走らせるものです。
ノード上にもボタンがあり、マウスを乗せたときだけ表示されます。このステップだけ実行、無効化、削除、その他です。無効化（Deactivate）は削除よりはるかに使いやすく、デバッグ時に触りたくないノードをオフにするとフローはそれをスキップし、戻すときはクリック1回で復元できます。削除すると再作成が必要です。
ノード追加：検索ボックスに英語を入力
キャンバス上のプラス記号をクリックする、または N、右側にノードパネルがスライド表示されます：
グループ化は閲覧を便利にするだけなので、本当に速くしたいなら直接検索します。よく入力する3つは：set（フィールド編集）、code（JS を書く）、if（条件分岐）。中国語で「编辑字段」と検索しても出てきますが、ノードが多くなると、中国語のマッチでは無関係なものがよく出てくるので、英語のほうが正確です。
あの「別のトリガーを追加」は飾りではありません。同じフローを毎日定時で実行しつつ、webhook で起動もさせたい場合は、ここから2つ目の入口を追加すればよく、2つのワークフローを作る必要はありません。
ノードをダブルクリックした後：4つのタブ
任意のノードをダブルクリックすると、ノード詳細が開きます。これは n8n で最も長く滞在する画面です：
4つのタブについて、1つずつ説明します。
入力は上流からこのノードに渡されたデータで、上部で「スキーマ / テーブル / JSON」を切り替えられます。スキーマは最初の1件のフィールド構造だけを表示するので見やすいですが、フィールドが抜ける可能性があります；全体を表示するのはテーブルと JSON です。「上流が結局何を渡したか」を確認するとき、私はほぼ JSON の欄を見ています。
パラメータここはあなたが入力するものです。各値の右側には小さなボタンが2つあり、「固定値」は固定で、「式」に切り替えてからでないと書けません {{ }}。「変更したのに反映されない」という問題の多くは、最終的に固定値に入力していたことが原因です。
設定設定はノードレベルのスイッチで、普段はあまり使いませんが、問題が起きたときに助けになるものです：Always Output Data（データがなくても空の項目を1つ強制出力）、Execute Once（データが何件あっても1件だけ実行）、Retry On Fail（失敗時に再試行）、On Error（エラー後にフロー全体を停止するか、そのまま下へ進むか）。Notes ではノードにメモを書け、「フロー内に表示」にチェックするとキャンバス上に表示されるので、他人のフローを引き継ぐときに便利です。
出力はこのノードの実行が終わって出力されるものです。
初心者が最も詰まりやすいのは出力が空の場合です。原因は通常それほど複雑ではありません：このノードがまだ実行されていないからです。右上の「ステップを実行」をクリックすると、前段のノードもまとめて1回実行し、結果を右側に表示します：
この小さな文字は少し見ておく価値があります。それが言っているのは：上流は確かに空のデータを1件渡しており、ただこのデータにはフィールドがないということです。なのであなたのフローは先へ進めますが、取得 $json.xxx すると undefined になります。初めて遭遇するとトリガーが壊れたと勘違いしやすいですが、実際にはもともとそういうものです。
「1 項目」という数字は、これから毎日のように見ることになります。上流が10件渡せば、ここに10項目と表示され、ノードは10件それぞれに対して1回ずつ実行します。最初の1件だけを処理するのではありません。これを覚えておけば、この後の「なぜ1件しか処理されないのか」の大半は自分で説明できます。
実行が終わると右下に「ノードは正常に実行されました」という通知がポップアップします。これが見えれば、このステップの設定に問題はありません。見えなければ、まずポップアップしたエラーの原文を見てください。慌ててパラメータを変更しないでください。
実行記録が何を言っているのか
フロー全体の実行が終わると、キャンバスはこうなります：ノードにチェックが付き、接続線には「1 項目」と表示され、左下に「実行をクリア」が増えます。
ただし、これらの色は最新の 1 回だけを表す。履歴を見るには実行記録へ。入口は 2 つ：ワークフロー上部の「実行」タブではこのフローだけを表示；左側の「個人 → 実行」ではサイト全体のすべてのフローを表示。
列は分かりやすい：ワークフロー、状態、開始時間、実行時間、実行 ID。失敗した行は行全体が赤くなるので、一行ずつ探す必要はない。右上にはフィルターもあり、状態・時間・ワークフローで絞り込める——フローが増えたら必須だ。
実行時間の単位は 毫秒。上の数件は、最速 106 毫秒、最遅 250 毫秒で、いずれもローカルの数十行のコード規模。外部 API を接続したフローでは、数百 毫秒 から数秒も正常で、3 桁だから遅いと思わないこと。
クリックすると単回実行：
最上部の行は情報密度が高い：時間、エラー は 106 毫秒 内、5KB、ID#13、自動保存。5KB は今回の実行で保存されたデータサイズ、ID は一覧のその列。ID の後ろの「自動保存」は、今回がワークフロー設定に従って自動保存されたもので、手動で保存したものではないことを示す。
左の列はこのワークフローの他の実行で、クリックすると前後比較ができる。中央のキャンバスは実行を押さなくても、どこが赤くなっているかを見るだけで何番目の段階で切れたか分かる。右上の「エディターでデバッグ」は、今回の実行の入力をエディターに戻して再実行できるので、上流を再トリガーする必要がない——時間を節約でき、API 呼び出しのクォータの無駄も省ける。
下部には「ログ」パネルもあり、展開すると各ノードの開始時間と終了時間を確認できる。「どこが遅いのか」を調べるならこれを見るのが、一覧で実行時間を推測するより確実だ。
手動実行と本番実行は混同して見ない
手動実行は「実行」を押して走らせた回。結果はエディターのキャンバスに直接描画され、ステップごとにデータを見られるので、変更しながら試すのに向いている。
本番実行はフロー公開後にトリガー自身が実行した回。それはしないエディターのキャンバスに表示され、「実行」タブでしか確認できない。
なので、「ちゃんと動かせたのに、なぜ本番で反応しないのか」という類の問題は、八割方、手動実行を本番公開と勘違いしている。手動で動かせたのはロジックが正しいことの証明にすぎない；定期実行や webhook を実際に有効にするには、「公開」をクリックする必要がある。この点で古いチュートリアルは多くの人を誤解させた。というのも、それらは 1.x の Active スイッチを説明しているからだ。
さらに厄介な落とし穴がある：キャンバス上には「1 項目」と表示されるが、その item が空、あるいはそもそも 0 項目ということがある。0 項目のとき、後続のノードはまったく実行されないが、この実行はそのまま「成功」と表示される。この「成功したが何もしていない」が最も調査しづらく、後で別途書く。
4つの操作で、本当に理解したかを検証する
図を見ただけでは不十分で、実際に手を動かして一通りやってみる：
- 3つのノード（手動トリガー → フィールド編集 → コード）を作成し、「実行」をクリックする。3つのノードがすべて緑になり、接続線上に「1 項目」が表示され、左下隅に「実行をクリア」が表示される。
- 最後のノードをダブルクリックし、出力タブにフィールドと値が表示されることを確認する。「出力データなし」ではない。表示されない場合は「ステップを実行」をクリックして再試行する。
- 「実行」タブに切り替えると、先ほどの実行がリストにあり、ステータスは成功、実行時間は数十から数百毫秒である。
- コード内のフィールド名を故意に間違える。たとえば、上流にまったく存在しないフィールドを参照して、もう一度実行する。そのノードが赤くなり、右下にエラーがポップアップ表示され、実行リストに赤い項目が1つ増える。
第4ステップを飛ばさないこと。失敗がどんな見た目かを理解するほうが、成功を理解するよりはるかに役立つ。
踏みがちな6つの落とし穴
Active スイッチが見つからない。2.x では「公開」に変わった。1.x のチュートリアルに従って探しても永遠に見つからず、自分がインストールしたのは本当に n8n なのかと疑い始める。
言語パックが正しくインストールされていないと思い込む。UI が中国語で、パラメーターが英語なのは正常な状態である。Mode、Fields to Set、Include Other Input Fields などは英語のままで、中国語版はない。
出力がずっと空です。ノードはまだ実行されていません。「実行ステップ」をクリックするか、入力エリアの「前段ノードを実行」をクリックしてください。実行記録内の履歴データはエディタへ自動で反映されません。2つのデータは別々です。
报 Cannot read properties of undefined (reading 'toUpperCase')。原文をそのまま写したものです。意味は、あるフィールドが存在しないのに、そのフィールドに対してメソッドを呼んでいるということです。9割は上流のフィールド名の書き間違いか、少数のデータが元々このフィールドを持っていないことです。前のノードに戻って出力を見るほうが、コード内で推測するより10倍速いです。
撮影用にわざと壊して書いたコードは次のとおりで、上流がまったく渡していないフィールドを参照しています：
return items.map(item => ({
json: { order: item.json.order_no.toUpperCase() }
}));
実行記録は数日すると見えなくなります。既定では削除対象になります：14日を超えるか、総数が10000件を超えると、古いものが削除されます。証拠を残したい場合はその実行にタグを付けます（実行詳細の「タグを追加」）。タグを付けたものは削除対象外です。
ノードを削除すると元に戻せません。キャンバス上の削除にはごみ箱がありません。不確かなときは無効化を使って、削除しないでください。
UI に関係する2つのセキュリティ問題
実行記録に保存されるのは各ノードの入出力の生データ。パラメータに書いた平文パスワード、ついでに貼り付けた API key、検索で取得した顧客の携帯番号は、一度でもノードを通れば実行データに完全に残ります。実行記録を開ける人は、これらを見られます。
そのため資格情報は必ず Credentials を使い、Set ノードやコードに詰め込まないでください；デバッグで機密データを使った場合は、実行後にその実行を削除してください。Credentials が保存するのは参照で、実行記録が保存するのは値です。この違いを覚えておいてください。
もう1つ忘れやすいこと：スクリーンショットを送る前に、実行詳細にメールアドレス、token、内部ネットワークアドレスがないか先に確認してください。今回の撮影では一時的なデモ用ワークフローを使い、撮影後に削除したのは、まさにこの理由です。
まとめ
この画面で本当に覚えるべき位置は3つだけ：左がリソース管理、中央がフロー管理、右上が公開管理。ノードをダブルクリックするとデータを確認でき、「実行」タブに切り替えると履歴を確認できる。
残りの項目——変数、データテーブル、評価、エージェント——は、今開いても混乱が増すだけなので、本当に必要になってからでよい。
順序としては、まず実行履歴をよく見慣れてからExpressionを学ぶことを勧める。1回の実行がどのステップで止まったか、上流が何を渡したかを一目で見分けられれば、その後どのノードを学ぶのも速くなる。
次の記事
続いて選定：n8n、Zapier、Makeの違いがどこにあるのかを、価格、自由度、保守コストで一度計算する。全体の構成を知りたい場合は講座の全体目次。
前回の記事はn8nのインストール方法、初心者向けローカルデプロイと初回実行の完全チュートリアルインストール時に詰まったら、あの記事に戻って確認してほしい。
参考資料
- Save and publish workflows（公式）
- Work with nodes（公式）
- 手動実行、部分実行、本番実行の違い（公式）
- キーボードショートカット（公式）
- データ保持とプルーニングを実行する（公式）
最終更新：2026年10月23日、n8n 2.43.7 を使用。
