n8n 変数で詰まる人へ、環境変数・Credential・式の違いを一気に整理

「n8n 変数」と検索している人の多くは、たぶん “ワークフロー内で同じ値を使い回したい”、または “APIキーやWebhook URLをどこに書けば安全なのか知りたい” という悩みを持っているはずです。n8nには、画面上のVariables、サーバー側の環境変数、認証情報を管理するCredential、そしてノード間の値を参照する式・特殊変数があり、ここを混同すると一気にわかりにくくなります。

この記事では、n8nの変数まわりを「何をどこに置くべきか」という実務目線で整理します。加えて、n8nとは何か、何に使うのか、どこの国のツールなのか、環境変数の設定例、Codeノードで使う $input や $json、Webhook URLやCloud Run構成で詰まりやすい設定、安全に運用するための考え方まで、初めての人にもわかるようにまとめます。

この記事のポイント
✅ n8n 変数は「Variables」「環境変数」「Credential」「式」を分けて理解する
✅ APIキーやトークンはワークフローへ直書きせず、Credentialや環境変数で管理する
✅ Codeノードでは `$input` や `$json` などの特殊変数を使って前ノードの値を扱う
✅ セルフホストでは `N8N_ENCRYPTION_KEY` や `WEBHOOK_URL` などの設定が重要になる

今日のセールをまとめてチェック！

本日のセール・タイムセールをまとめてチェックできます。

＼最大7.5%ポイントアップ！／

Amazon

楽天市場

Yahooショッピング

メルカリ

ポチップ

n8n 変数の基本理解と使い分け

n8n 変数は4種類に分けると迷わない
n8nとは何ですか？への答えはワークフロー自動化ツールである
n8nは何に使うのですか？への答えは外部サービス連携の自動化である
n8nでできることはAPI連携・データ整形・AI連携まで広い
n8nは何の略ですか？は公式情報だけでは断定しにくい
n8n 変数 AI回答を見る前に確認すべき点は用途の切り分けである

n8n 変数は4種類に分けると迷わない

n8nで「変数」と呼ばれがちなものは、実は1種類ではありません。ここを最初に分けておくと、かなり理解しやすくなります。大きく見ると、Variables、環境変数、Credential、式・特殊変数 の4つです。

まず、画面上の「Variables」は、ワークフローで共通的に使える値を設定する機能として紹介されています。ただし、調査した範囲では、セルフホスト環境ではEnterpriseプラン向けの機能として扱われるケースがあるようです。そのため、個人利用や小規模なセルフホストでは、Variablesを前提に設計するよりも、環境変数やCredentialを使うほうが現実的な場合があります。

一方で、環境変数はサーバーやDocker、Cloud Runなどの実行環境に設定する値です。たとえば、WEBHOOK_URL、N8N_ENCRYPTION_KEY、DB_POSTGRESDB_HOST のような設定が該当します。n8n全体の挙動を変えたり、APIトークンのような値をワークフローから参照したりするときに使われます。

Credentialは、APIキーやOAuth認証、アクセストークンなどをn8n内で安全に保存するための仕組みです。HTTP Request、Google Sheets、Slackなどのノードで認証が必要なとき、毎回キーを直接書くのではなく、Credentialとして登録して使います。秘密情報はCredential、環境ごとの固定値は環境変数、ノード間のデータは式・特殊変数 と考えると整理しやすいです。

🧭 n8nの変数まわりの分類表

種類	使う場所	主な用途	注意点
Variables	n8n画面上	共通値の管理	プランや環境により利用制限がある可能性
環境変数	サーバー・Docker・Cloud Run	n8n全体の設定、環境別の値	設定後に再起動が必要な場合が多い
Credential	n8nの認証情報管理	APIキー、OAuth、トークン	`N8N_ENCRYPTION_KEY` の設定が重要
式・特殊変数	ノード内、Codeノード内	前ノードの値参照、データ加工	書き方を間違えると値が取れない

📌 使い分けの目安

やりたいこと	選ぶ候補	理由
APIキーを安全に保存したい	Credential	認証情報として暗号化・再利用しやすい
本番と開発でWebhook URLを変えたい	環境変数	環境ごとに値を分けやすい
前のHTTP Requestノードの結果を使いたい	式・特殊変数	ノード間のデータ参照に向いている
ワークフロー全体で同じ固定値を使いたい	Variablesまたは環境変数	利用環境により選択する

n8nの公式ドキュメントでは、セルフホスト時にn8nの設定を変えるための環境変数一覧が案内されています。
引用元：https://docs.n8n.io/hosting/configuration/environment-variables/

ここで重要なのは、「n8n 変数」という検索語だけで1つの答えに飛びつかないことです。検索して出てくる情報が、画面上のVariablesの話なのか、Dockerの環境変数の話なのか、Codeノードの $input の話なのかで、やるべき設定がまったく変わります。

n8nとは何ですか？への答えはワークフロー自動化ツールである

n8nとは、複数のサービスや処理をつなげて、自動化の流れを作るためのワークフロー自動化プラットフォームです。たとえば、HTTP Requestで外部APIからデータを取得し、取得した値を整形し、Google Sheetsへ保存し、さらにAIノードへ渡す、といった処理を画面上で組み立てられます。

「ノーコードツール」と紹介されることもありますが、調査した内容を見る限り、n8nは単なるノーコードというより、ノードで組み立てながら必要に応じてコードも書ける自動化ツール と考えるほうが近いです。CodeノードではJavaScriptやPythonを使ってデータ加工ができます。ただし、Pythonについてはバージョンや実行方式により注意点があります。

初心者が最初に触る画面としては、Workflows、Credentials、Executionsが中心になります。Workflowsは処理の流れを作る場所、Credentialsは外部サービスの認証情報を設定する場所、Executionsは実行履歴やエラーを確認する場所です。ここにVariablesやSettingsなどが加わります。

n8nの便利な点は、処理の途中結果を見ながら組み立てられるところです。HTTP Requestノードで取得した値を、Edit Fieldsノードで必要な項目だけに絞る、といった流れを画面上で確認できます。実行結果やエラーもExecutionsやLogsで確認できるため、どこで詰まったかを追いやすい設計です。

🧩 n8nの主要画面と役割

画面	役割	初心者が見るポイント
Workflows	自動化の流れを作る	ノードをつないで処理を作る
Credentials	認証情報を管理する	APIキーやトークンを登録する
Executions	実行履歴を確認する	成功・失敗・エラー内容を見る
Variables	共通変数を扱う	利用できるプランや環境を確認する
Settings	ユーザーやAPI設定	n8n APIキーなどを管理する

🔰 初心者が最初に理解したい用語

用語	かんたんな意味
ノード	1つの処理ブロック
ワークフロー	ノードをつなげた自動化の流れ
トリガー	ワークフローを開始するきっかけ
Credential	認証情報を保存する場所
Execution	ワークフローの実行結果

n8nは、オープンソースのワークフロー自動化プラットフォームとして説明されています。
引用元：https://jvndb.jvn.jp/ja/contents/2025/JVNDB-2025-023702.html

つまり、「n8nとは何ですか？」への短い答えは、外部サービスやデータ処理をつなぐ自動化ツール です。ただし、実務で使うなら、Credential、環境変数、実行履歴、エラー確認まで含めて理解したほうが安全です。

n8nは何に使うのですか？への答えは外部サービス連携の自動化である

n8nは、単純な作業の自動化から、複数サービスをまたぐ業務フローの構築まで幅広く使えます。たとえば、フォームに入力されたデータを受け取り、内容を整形し、スプレッドシートに保存し、Slackへ通知する、といった流れを作れます。

特に使いやすいのは、外部APIとの連携です。HTTP Requestノードを使えば、指定したURLへリクエストを送り、返ってきたJSONデータを次のノードで加工できます。調査したハンズオン記事でも、GitHub APIからOctocatのプロフィール情報を取得し、Edit Fieldsで必要な値だけを取り出す例が紹介されていました。

また、データの加工にも使えます。たとえば、一覧データから重複を除く、日付順に並べ替える、必要な件数だけ取り出す、といった処理です。Codeノードを使えば、JavaScriptで柔軟に処理できます。ノーコードだけでは難しい処理も、Codeノードを挟むことで対応しやすくなります。

AI連携にも使われます。AIノードやBasic LLM Chainのような処理に、前段で取得・整形したデータを渡すことで、要約、分類、文章生成などの自動化が可能になります。ただし、AI連携ではAPIキーや入力データの扱いが重要になるため、Credentialや環境変数を正しく使う必要があります。

🚀 n8nの代表的な使い道

使い道	例	変数が関係する場面
API連携	外部サービスからデータ取得	API URL、トークン、取得値
通知自動化	Slackやメールへ通知	通知先、メッセージ本文
データ保存	Google SheetsやDBへ保存	保存先ID、認証情報
データ加工	重複削除、並べ替え、抽出	`$input` や `$json`
AI連携	要約、分類、文章生成	APIキー、プロンプト、入力値

🧪 よくあるワークフロー例

流れ	内容
Trigger → HTTP Request → Edit Fields	APIから取得したデータを必要項目だけに絞る
Webhook → Code → Google Sheets	外部から受けたデータを整形して保存する
Schedule → HTTP Request → AI Node → Mail	定期的に情報取得して要約メールを送る
Manual Trigger → HTTP Request → Code	手動実行でデータを検証・加工する

ここで変数が必要になるのは、「同じ値を何度も使う」「環境によって値を変える」「前のノードの結果を次に渡す」「秘密情報を隠す」といった場面です。つまり、n8nにおける変数は、単なる便利機能ではなく、ワークフローを安全に運用するための土台でもあります。

n8nでできることはAPI連携・データ整形・AI連携まで広い

n8nでできることは、単に「サービス同士をつなぐ」だけではありません。外部APIからのデータ取得、HTMLの解析、配列データの処理、重複排除、日付順の並び替え、件数の絞り込み、Google Sheetsへの出力、AIノードへの連携など、かなり広い範囲をカバーできます。

調査したワークフロー例では、ブログ記事一覧を取得し、HTMLノードで解析し、Codeノードで重複チェックや日付順ソートを行う流れが紹介されていました。Codeノードでは、Run Once for All Items と Run Once for Each Item のような実行モードを選び、入力データ全体を一度に処理するか、1件ずつ処理するかを切り替えられます。

このとき重要になるのが、Codeノード内で使う特殊変数です。$input.all() で全アイテムを取得したり、$input.first() で最初のアイテムを取ったり、$json で現在のアイテムのJSONを参照したりできます。つまり、n8nの「変数」は、サーバー設定だけでなく、実際のデータ処理にも深く関係します。

また、過去のノードの出力を参照することもできます。たとえば、$('HTTP Request') のように書くことで、指定したノードの出力値にアクセスできる場合があります。ただし、ワークフローの見た目の流れを無視して過去ノードを参照しすぎると、後から見たときに処理の流れがわかりにくくなるため注意が必要です。

🛠️ n8nでできる処理の広がり

カテゴリ	できること	代表ノード
取得	API、Webhook、HTML取得	HTTP Request、Webhook
加工	項目抽出、重複排除、並べ替え	Edit Fields、Code
分岐	条件によって処理を変える	IF、Switch
保存	DB、Sheets、外部ツールへ保存	Google Sheets、DB系ノード
AI連携	要約、分類、生成	AIノード、LLM Chain

💡 Codeノードでよく出る特殊変数

特殊変数	意味	主な使い方
`$input.all()`	入力された全アイテム	全件をループ処理する
`$input.first()`	最初のアイテム	1件目だけ確認する
`$input.last()`	最後のアイテム	最新・最後の値を見る
`$json`	現在アイテムのJSON	各項目を参照する
`$('ノード名')`	指定ノードの出力	過去ノードの値を参照する

Codeノードでは、入力値にアクセスするために $input などの特殊変数を利用できると紹介されています。
引用元：https://blog.future.ad.jp/n8n-hands-on-06-03

n8nは、画面上でつなぐだけでも使えますが、変数や式を理解すると一気にできることが広がります。特に「前のノードのこの値を次で使いたい」という場面では、式と特殊変数の理解がほぼ必須になります。

n8nは何の略ですか？は公式情報だけでは断定しにくい

「n8nは何の略ですか？」という検索もよくある疑問です。一般的には、n8nという名前について「nodemation」に由来するという説明を見かけることがあります。ただし、今回の調査資料内では、その由来を公式に確認できる本文はありませんでした。そのため、ここでは断定せず、一般的にはそのように説明されることがある という扱いに留めます。

実務上、名前の由来より大切なのは、n8nが「ノードをつなげて自動化するツール」だという理解です。n8nの画面では、Trigger manually、HTTP Request、Edit Fields、Codeなどのノードを順番につなぎ、処理の流れを作ります。名称の由来を知らなくても、ノード単位で処理を分けて考えれば使い始められます。

ただし、初心者にとって「n8n」という名前は少し覚えにくいかもしれません。読み方も含めて迷いやすいため、検索時には「n8n 変数」「n8n 環境変数」「n8n Credential」「n8n Code node」など、目的語を足して調べるほうが情報にたどり着きやすいです。

また、n8nはセルフホストできる点が大きな特徴です。公式クラウド版もありますが、Docker、Cloud Run、Supabaseなどと組み合わせて自分で運用する例もあります。セルフホストでは自由度が高い一方、環境変数、DB接続、Webhook URL、暗号化キーなどの管理が必要になります。

🔎 名前より先に押さえたいn8nの理解

疑問	実務上の答え
何の略？	一般的には由来説明があるが、今回資料だけでは断定しない
どう読む？	一般的には「エヌエイトエヌ」と読まれることが多い
何をするもの？	ノードをつないで業務を自動化する
何が重要？	ノード、Credential、環境変数、実行履歴の理解

📚 検索するときのおすすめ語句

知りたい内容	検索語句
共通値の使い方	n8n 変数
サーバー設定	n8n 環境変数
APIキー管理	n8n Credential
前ノードの値参照	n8n expressions `$json`
コード処理	n8n Code node `$input`

ここで注意したいのは、「n8n 変数」と検索しても、求めている答えが1つにまとまって出てくるとは限らないことです。Variables機能の話、環境変数の話、Codeノードの特殊変数の話が混ざりやすいため、自分がどの意味の変数を探しているのかを最初に決めるのが近道です。

n8n 変数 AI回答を見る前に確認すべき点は用途の切り分けである

検索結果に「n8n 変数 AI回答を見る」のような導線が出る場合、AIの要約だけを読んで設定を進めたくなるかもしれません。しかし、n8nの変数まわりは文脈によって答えが変わるため、AI回答を見る前に、まず自分の用途を切り分けるのが安全です。

たとえば、「APIキーを変数にしたい」という相談でも、答えは1つではありません。APIキーをHTTP Requestノードで使うならCredentialが向いている場合があります。一方、独自のトークンを環境ごとに切り替えたいなら、環境変数として持つ選択もあります。画面上のVariablesを使いたい場合は、利用プランや環境で使えるかを確認する必要があります。

また、「前のノードの値を変数として使いたい」という意味なら、環境変数ではなく式や特殊変数の話です。たとえば、HTTP Requestで取得した login や url をEdit Fieldsで取り出す場合、前ノードの出力を参照します。この場合は、サーバー側の .env を編集しても解決しません。

AI回答は便利ですが、古い情報や別バージョンの情報が混ざることがあります。n8nはバージョンアップや機能変更もあり、Basic認証の環境変数が古い情報として残っている例も調査資料にありました。セルフホスト構成では、公式ドキュメントや現在の実行環境を確認することが重要です。

✅ AI回答を見る前の確認リスト

確認項目	見るべきポイント
何を変数化したいか	APIキー、URL、前ノードの値、固定値
どこで使うか	ノード設定、Codeノード、n8n全体設定
秘密情報か	秘密ならCredentialや環境変数を優先
環境ごとに変えるか	開発・本番で違うなら環境変数が便利
利用プランは何か	Variables機能の利用可否に注意

🧠 目的別の最短回答

目的	まず見る場所
APIキーを隠したい	Credential
Webhook URLを正しくしたい	`WEBHOOK_URL` や `N8N_EDITOR_BASE_URL`
前ノードの値を使いたい	Expressions、`$json`、`$input`
ワークフロー共通の値を使いたい	Variablesまたは環境変数
DB接続を設定したい	n8n環境変数

「n8n 変数」で迷ったら、まずは “それは秘密情報か、設定値か、処理中のデータか” と分けてください。この切り分けだけで、調べるべきページも、設定する場所も、かなり絞り込めます。

忘れる前に！【ふるさと納税】今年もお得に！

ふるさと納税のポイント付与は2025年10月に廃止になりました。

＼最大7.5%ポイントアップ！／

Amazon

楽天市場

Yahooショッピング

メルカリ

ポチップ

n8n 変数の安全運用と詰まりやすい設定

n8n 変数で秘密情報を扱うならCredentialを優先する
環境変数はセルフホストのn8n設定を変えるために使う
Webhook URLやCloud RunではURL系の環境変数が詰まりやすい
Codeノードの変数は $input と $json を理解すると扱いやすい
n8n どこの国？への答えは一般的には欧州発とされるが運用では所在地より設定確認が重要である
セキュリティ対策では暗号化キーとCodeノードの扱いが重要である
総括：n8n 変数のまとめ

n8n 変数で秘密情報を扱うならCredentialを優先する

n8nでAPIキー、アクセストークン、パスワードのような秘密情報を扱う場合、まず検討したいのはCredentialです。HTTP RequestノードやGoogle Sheetsノードなど、認証が必要なノードではCredentialを作成し、それを選択して使う形が基本になります。

秘密情報をワークフロー内に直接書くと、いくつかのリスクがあります。ワークフローをエクスポートしたときに値が残る可能性、Gitで管理したときに漏れる可能性、チームで共有したときに不要な人へ見えてしまう可能性などです。特に自動化ツールは複数サービスと接続するため、1つのキー漏洩が広い影響につながることがあります。

Credentialを使うメリットは、認証情報を再利用しやすいことです。一度登録しておけば、複数のワークフローで同じCredentialを選択できます。メンバーが増えたり、ワークフローが増えたりしたときも、APIキーを各ノードに散らばらせるより管理しやすくなります。

さらに、セルフホスト環境では N8N_ENCRYPTION_KEY が重要です。この値を設定しておくことで、Credentialデータの暗号化に関わります。調査資料でも、Credential情報を安全に扱うために N8N_ENCRYPTION_KEY を必ず設定する考え方が紹介されていました。

🔐 秘密情報の置き場所比較

置き場所	向いている情報	おすすめ度	理由
Credential	APIキー、OAuth、トークン	高	認証情報として管理しやすい
環境変数	環境ごとの固定トークン	中〜高	ワークフローに直接書かずに済む
Variables	非秘密の共通値	中	利用可否に注意
ノードへ直書き	一時的なテスト値	低	共有・エクスポート時に危険

🛡️ 秘密情報管理のチェック表

n8nでは、環境変数とCredential機能を使って安全なデータ管理ができると紹介されています。
引用元：https://note.com/mellow_launch/n/ne2dc8851b0fb

秘密情報は「動けばいい」で済ませると後から危険になります。最初は少し面倒でも、Credentialと環境変数を使い分けておくと、ワークフローを増やしたときの管理負担が小さくなります。

環境変数はセルフホストのn8n設定を変えるために使う

n8nの環境変数は、セルフホスト時にn8n本体の動作を変えるために使います。公式ドキュメントでも、セルフホスト時に利用できる環境変数のカテゴリが案内されています。対象はAI Assistant、Binary data、Credentials、Database、Executions、Logs、Security、Timezoneなど幅広いです。

環境変数は、Docker Composeの .env、Cloud Runの環境変数設定、サーバーの起動設定などに書きます。ワークフロー内だけで完結するものではなく、n8nを動かす土台側の設定です。そのため、変更後は再起動や再デプロイが必要になることがあります。

代表的なものとして、N8N_ENCRYPTION_KEY、WEBHOOK_URL、N8N_EDITOR_BASE_URL、DB関連の DB_POSTGRESDB_HOST や DB_POSTGRESDB_PORT などがあります。Cloud RunとSupabaseを使う構成では、DB接続方式、SSL、エディタURLなどが詰まりやすいポイントとして紹介されていました。

また、環境変数はワークフロー内から参照できる場合があります。調査資料では {{$env.API_TOKEN}} のような参照例が紹介されていました。ただし、すべての値を環境変数に入れればよいわけではありません。認証情報として扱えるものはCredentialに寄せたほうが管理しやすい場面もあります。

⚙️ よく出てくるn8n環境変数

環境変数	役割	注意点
`N8N_ENCRYPTION_KEY`	Credential暗号化に関わるキー	初期構築時に設定したい
`WEBHOOK_URL`	Webhookの外部URLに関係	公開URLとずれると動作に影響する場合
`N8N_EDITOR_BASE_URL`	エディタのベースURL	HTTPS環境で重要になる場合
`DB_TYPE`	DB種類	PostgreSQL利用時などに設定
`DB_POSTGRESDB_SSL`	PostgreSQLのSSL接続	クラウドDBでは必要な場合がある

📦 環境変数が向いているもの

値の種類	例
n8n本体の設定	実行履歴、ログ、セキュリティ設定
接続先DB情報	ホスト、ポート、DB名、SSL
公開URL	Webhook URL、Editor URL
環境ごとに違う値	開発URL、本番URL
ワークフローに直接書きたくない固定値	独自APIのベースURLなど

n8n公式ドキュメントでは、セルフホスト環境で設定を変更するための環境変数一覧が案内されています。
引用元：https://docs.n8n.io/hosting/configuration/environment-variables/

環境変数は便利ですが、「サーバー設定」と「ワークフロー中のデータ」を混同しないことが大切です。HTTP Requestの結果を次のノードで使うなら式、APIキーを安全に使うならCredential、n8n自体のURLやDB接続を変えるなら環境変数、という分け方が実務では扱いやすいです。

Webhook URLやCloud RunではURL系の環境変数が詰まりやすい

n8nをセルフホストするとき、特に詰まりやすいのがURL系の設定です。Webhookを外部から受ける場合、n8nが自分自身の公開URLを正しく認識していないと、生成されるWebhook URLが期待とずれることがあります。

Cloud Runのような環境では、外部からはHTTPSでアクセスしていても、アプリケーション内部では別の見え方をしている場合があります。調査資料では、ライセンス登録時にHTTPS関連の問題が出て、N8N_EDITOR_BASE_URL を設定することで解決した可能性がある例が紹介されていました。

また、Cloud RunとSupabaseを組み合わせる場合、DB接続でも詰まりやすい点があります。SupabaseにはDirect Connection、Transaction Pooler、Session Poolerのような接続方式があり、Cloud Runのようなサーバーレス環境ではTransaction Poolerが合う場合があると紹介されていました。DBポートもDirect Connectionでは5432、Transaction Poolerでは6543のように変わることがあります。

ここで大切なのは、n8nの変数設定は単体で見るのではなく、実行環境、公開URL、DB接続方式、SSL設定 をセットで見ることです。Webhookだけ直してもDBがつながらない、DBだけ直してもEditor URLがずれる、ということが起きる可能性があります。

🌐 URL・DBまわりで詰まりやすい設定

症状	見直す候補	補足
Webhook URLが想定と違う	`WEBHOOK_URL`	公開URLと一致しているか確認
HTTPSなのにエラーが出る	`N8N_EDITOR_BASE_URL`	Cloud Runなどで重要になる場合
DB接続が不安定	DB接続方式	SupabaseではPooler利用が合う場合
初回起動が遅い	DBマイグレーション	数分待つ必要がある場合
SSL接続で詰まる	`DB_POSTGRESDB_SSL=true`	クラウドDBで必要な場合

🧱 Cloud Run × Supabase構成の設定例

項目	例
n8n本体	Cloud Run上のn8nコンテナ
DB	Supabase PostgreSQL
DB接続方式	Transaction Pooler
DBポート	6543
URL設定	`N8N_EDITOR_BASE_URL=https://...`
SSL	`DB_POSTGRESDB_SSL=true`

Cloud RunとSupabaseでn8nを構築する例では、Transaction Pooler、N8N_EDITOR_BASE_URL、SSL設定などが重要なポイントとして紹介されています。
引用元：https://zenn.dev/deskrex/articles/c3c71288b62e69

WebhookやURL関連で詰まったときは、「n8nの画面で見えているURL」と「外部から実際にアクセスするURL」が一致しているかを確認してください。特にリバースプロキシ、Cloud Run、独自ドメイン、HTTPS終端が絡むと、環境変数の設定が効いてきます。

Codeノードの変数は `$input` と `$json` を理解すると扱いやすい

n8nのCodeノードでデータを加工するなら、まず $input と $json を理解するのが近道です。Codeノードは、前のノードから渡されたデータをJavaScriptやPythonで処理できるノードです。調査資料では、JavaScriptを使って記事データの重複排除、日付変換、降順ソート、件数絞り込みを行う例が紹介されていました。

$input は、Codeノードへ入ってきたデータにアクセスするための特殊変数です。Run Once for All Items の場合は、$input.all() で全アイテムを取得できます。複数件のデータをまとめて処理したいときに便利です。

一方、Run Once for Each Item の場合は、アイテムごとに処理が実行されます。このときは $json を使って現在のアイテムの値を参照する考え方がわかりやすいです。1件ずつ加工したいならEach Item、全体を並べ替えたり重複排除したりするならAll Itemsが向いています。

さらに、$('ノード名') のような書き方で過去ノードの出力を参照できる場合があります。これは便利ですが、使いすぎるとワークフローの見た目と実際のデータ参照がずれて、後から読みにくくなります。基本はノードの流れに沿ってデータを渡し、必要なときだけ過去ノード参照を使うほうが保守しやすいです。

🧑‍💻 Codeノードの実行モード比較

モード	動き	向いている処理
Run Once for All Items	入力全体に対して1回実行	重複排除、ソート、件数制限
Run Once for Each Item	アイテムごとに実行	1件ずつ項目追加・変換

🧾 特殊変数の使いどころ

書き方	役割	例
`$input.all()`	全アイテム取得	全件を配列で処理
`$input.first()`	先頭アイテム取得	サンプル確認
`$input.last()`	最後のアイテム取得	最新っぽい値の確認
`$json`	現在アイテムのJSON	`$json.articleTitle`
`$('HTTP Request')`	指定ノード参照	過去ノードの出力利用

Codeノードでは、$input や $('前処理ノード名') などの特殊変数を使い、前ノードや過去ノードの出力にアクセスできると紹介されています。
引用元：https://blog.future.ad.jp/n8n-hands-on-06-03

Codeノードの変数は、環境変数とはまったく別物です。$input や $json は、実行中のワークフロー内で流れているデータを扱うためのものです。APIキーやWebhook URLの管理ではなく、データ加工のための変数だと考えると混乱しにくくなります。

n8n どこの国？への答えは一般的には欧州発とされるが運用では所在地より設定確認が重要である

「n8n どこの国？」という検索意図は、ツールの信頼性や運営元を確認したい気持ちから来ている可能性があります。一般的には、n8nは欧州発、特にドイツ・ベルリン周辺の文脈で語られることがあります。ただし、今回提供された調査資料の本文だけでは、運営国や法人所在地を明確に確認できる記載はありませんでした。そのため、ここでは断定を避けます。

実務上は、どこの国のツールかと同じくらい、どのように運用するかが重要です。n8nはセルフホストできるため、自分のサーバー、Cloud Run、Docker環境などに置いて運用できます。つまり、データをどこに保存するか、DBをどこに置くか、誰がアクセスできるかは、構成次第で変わります。

n8nをセルフホストするなら、国や運営元だけでなく、DB、認証情報、ログ、Webhook URL、外部APIキーの扱いを確認する必要があります。特に個人情報や顧客情報を扱うワークフローでは、どのサービスにどのデータが渡るのかを把握しておくべきです。

また、n8nはオープンソースのワークフロー自動化プラットフォームとして紹介されています。オープンソースであることは透明性の面で利点がありますが、セルフホストではアップデートやセキュリティ対応も利用者側の責任になりやすいです。運用するなら、バージョン管理と脆弱性情報の確認も必要になります。

🌍 「どこの国？」より確認したい運用ポイント

確認項目	理由
n8nをどこにホストするか	データの保管場所に関わる
DBをどこに置くか	実行履歴やCredential管理に関わる
外部APIに何を送るか	個人情報・機密情報の扱いに関わる
誰がワークフローを編集できるか	CodeノードやCredential利用に関わる
どのバージョンを使うか	セキュリティ修正に関わる

🔍 初期確認マトリクス

観点	小規模利用	チーム利用
認証情報	Credentialに集約	権限管理も検討
環境変数	`.env` で管理	本番・開発を分離
実行履歴	必要分だけ保存	監査・保持期間を確認
Codeノード	最小限で利用	編集権限を制限
アップデート	手動確認	定期確認が望ましい

「n8nがどこの国のツールか」は入口の疑問として自然です。ただ、実際に業務で使う段階では、所在地だけで安心せず、自分の構成でデータがどこを通るのかを確認するほうが重要です。

セキュリティ対策では暗号化キーとCodeノードの扱いが重要である

n8nのセキュリティで特に注意したいのは、Credentialの暗号化キーとCodeノードの扱いです。CredentialにはAPIキーやトークンが保存されるため、N8N_ENCRYPTION_KEY の設定はかなり重要です。これを設定していない、または適切に管理していない場合、認証情報の保護が弱くなる可能性があります。

もう1つの注意点がCodeノードです。Codeノードは柔軟にデータ加工できる強力な機能ですが、そのぶん扱いには注意が必要です。JVN iPediaでは、n8nのPython Code Nodeに関する脆弱性情報が掲載されており、バージョン1.0.0以上2.0.0未満に影響する内容として紹介されています。2026年5月20日時点で参照した情報では、2.0.0で修正されたとされています。

この脆弱性情報では、回避策としてCode Nodeを無効化する NODES_EXCLUDE、Pythonサポートを無効化する N8N_PYTHON_ENABLED=false、タスクランナーベースのPythonサンドボックス利用に関する環境変数などが挙げられています。実際にどの対策を取るべきかは、利用バージョンや構成により変わるため、公式・ベンダ情報を確認する必要があります。

チーム利用では、誰にワークフロー作成・編集権限を与えるかも重要です。Codeノードを編集できる人は、データ加工だけでなく、場合によっては実行環境へ強い影響を与える可能性があります。便利さとリスクをセットで見て、必要な人だけが編集できる状態にするのが無難です。

🛡️ セキュリティ優先度の高い設定

項目	優先度	理由
`N8N_ENCRYPTION_KEY`	高	Credential保護に関わる
Credential管理	高	APIキー漏洩を防ぐ
Codeノード権限	高	実行環境への影響が大きい場合がある
バージョン更新	高	脆弱性修正を取り込む
実行ログ管理	中	情報の残り方を確認する

🚨 Codeノード関連の確認表

確認項目	見るポイント
n8nのバージョン	影響範囲に入っていないか
Python Code Nodeの利用	必要性があるか
Codeノードの編集権限	誰が編集できるか
環境変数による制御	無効化や制限が必要か
ワークフロー共有	危険なコードが含まれていないか

JVN iPediaでは、n8n 1.0.0以上2.0.0未満のPython Code Nodeに関する脆弱性と、回避策としての環境変数設定が紹介されています。
引用元：https://jvndb.jvn.jp/ja/contents/2025/JVNDB-2025-023702.html

n8nは便利な自動化基盤ですが、APIキー、DB、外部連携、Code実行が集まる場所でもあります。変数を正しく使うことは、単なる作業効率化ではなく、セキュリティ対策そのものです。

総括：n8n 変数のまとめ

最後に記事のポイントをまとめます。

n8n 変数は、Variables、環境変数、Credential、式・特殊変数に分けて考えるべきである。
APIキーやアクセストークンは、ノードへ直書きせずCredentialで管理するのが基本である。
環境変数は、セルフホスト時にn8n本体の設定や接続先を変えるために使うものである。
N8N_ENCRYPTION_KEY はCredential保護に関わるため、初期構築時に重視すべき設定である。
WEBHOOK_URL や N8N_EDITOR_BASE_URL は、Cloud Runや独自ドメイン運用で詰まりやすい項目である。
前ノードの値を使いたい場合は、環境変数ではなく式や $json、$input を確認すべきである。
Codeノードで複数データをまとめて処理するなら、Run Once for All Items と $input.all() の理解が重要である。
1件ずつデータを加工するなら、Run Once for Each Item と $json の使い方が重要である。
画面上のVariablesは便利だが、利用環境やプランにより使える範囲を確認すべきである。
Cloud RunとSupabase構成では、DB接続方式、SSL、URL系環境変数をセットで確認すべきである。
n8nはワークフロー自動化ツールであり、API連携、データ整形、通知、AI連携まで幅広く使える。
n8nの名前の由来や国よりも、実際の運用ではデータの保存場所、認証情報、権限管理を確認すべきである。
セキュリティ面では、Codeノードの利用権限とn8nのバージョン確認が重要である。
「n8n 変数」で迷ったら、秘密情報、設定値、処理中データのどれを扱っているのか最初に切り分けるべきである。

記事作成にあたり参考にさせて頂いたサイト

各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

AI 業務効率化職場

当サイトについて

当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。迅速に対応をさせていただきます。その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応することができますのでそちらもご協力いただけますと大変幸いでございます。今後とも当サイトをよろしくお願いいたします。

n8n 変数で詰まる人へ、環境変数・Credential・式の違いを一気に整理