n8nで何が作れるのか｜自動化できる業務と、向いていない業務
n8n が得意なのは、複数のSaaSの間でデータを受け渡す処理です。ひとつの出来事を合図に、別のサービスへ書き込む。この形に当てはまる業務なら、画面上でノードをつなぐだけで組めます。
n8nのワークフローは「何が起きたら（トリガー）」「どう加工して（処理）」「どこへ書くか（アクション）」の3段でできている。組む前に、この3つを言葉で書けるかを確かめる。
図1 ── 注：処理段は0個でも成立する。加工が不要ならトリガーとアクションを直結できる。
向いている業務・向いていない業務
判断の分かれ目は「分岐の数」。一本道の受け渡しなら n8n が速く、分岐が増えるほどコードで書いた方が保守しやすくなる。
大きい中程度やや小さい小さいほぼ無い
表1 ── 注：判定は構成と件数に依存する。実行数の上限は選ぶプランで変わる。
「ノーコードで完結する」は限定的です簡単な連携は画面操作だけで組めます。ただし実務では、日付の形式をそろえる、配列を1件ずつに割る、といった加工で Code ノードに数行書く場面が出てきます。まったくコードを書かない範囲は、想像より狭いと考えておくのが安全です。
この節は一次情報での裏取りが未了です。
n8n 公式ドキュメント（ノード一覧・実行モデル）（2026-08-13 記載）
n8nでよくある失敗｜動いたのに運用で壊れる3つの原因
n8n で作ったワークフローが止まる原因は、多くの場合 n8n の外側にあります。作った直後は動くのに、数か月後に静かに壊れているという形で現れます。
- 連携先のAPI仕様が変わった ── 項目名の変更やバージョン廃止。予告なく変わることもある
- 認証が切れた ── OAuthトークンの期限切れ。再認証しないと以降すべて失敗する
- 失敗しても誰も気づかない ── エラー時の通知を設定していないため、止まったことに気づくのが遅れる
3つ目が最も実害が大きいです。止まったこと自体より、気づくのが遅れることが問題になります。対策は単純で、失敗時に通知を飛ばすワークフローを別に用意しておくことです。
最初に設定すべきエラー通知
n8n には失敗時に呼ばれる Error Workflow の仕組みがあります。本番で動かす前に、これだけは設定してください。
Error Trigger
↓
Slack ノード
メッセージ: 「{{$json.workflow.name}} が失敗しました」
「{{$json.execution.error.message}}」
↓
（任意）担当者へメンション
実行ログの保持期間に注意失敗の原因を追うには実行ログが要りますが、保持期間には上限があります。気づくのが数週間後だと、ログが消えていて原因がわからないという事態になります。通知を先に作る理由はここにもあります。
この節は一次情報での裏取りが未了です。
実運用でのヒアリングと検証（一次情報での裏取りは未了）（2026-08-13 記載）
n8nは商用利用できるのか｜Sustainable Use Licenseで許される範囲
本節の扱いについてライセンスの解釈を誤ると契約上の問題になります。本節は構造の説明にとどめ、判断の前に必ず原文と自社の法務に確認してください。条項は改訂されることがあります。
n8n は無料で使えますが、OSI が承認したオープンソースライセンスではありません。Sustainable Use License という独自のライセンスで、公式には fair-code と表現されています。ソースは公開されているものの、使える用途に条件が付きます。
社内の業務で使う分には制限がない。制限がかかるのは、n8n そのものを他社に使わせて対価を得る形の利用。
表2 ── 注：本表は条項の構造を示すもので、法的助言ではありません。原文（Sustainable Use License）と自社法務で確認してください。／ 出典：n8n 公式ライセンス文書（2026-08-13 時点・裏取り未了）
ServiceDock で自作ワークフローを販売する場合は、上の表の3行目に当たります。売っているのは n8n 本体ではなく、自分が作った設定ファイルだからです。ただし、ワークフローが呼び出している外部APIの規約は別途確認が必要です。
この節は一次情報での裏取りが未了です。
ライセンス条項は改訂されることがある。導入前に必ず原文を読むこと。（2026-08-13 記載）
セルフホストとn8n Cloudはどちらが得か｜損益分岐の考え方
n8n のセルフホストは、ソフトウェアの費用が無料になる代わりにサーバー費と運用工数が発生します。Cloud は月額が固定でかかる代わりに、運用を見なくて済みます。
セルフホストが有利になるのは、実行数が多い場合に限られる。しかも節約できるのはソフトウェア費だけで、運用工数は消えない。
図2 ── 注：セルフホスト側には運用工数の人件費を含めている。含めずに比較すると、必ずセルフホストが有利に見える。／ 金額は構造を示すための想定値であり、実際の料金表で再計算が必要。
セルフホストを選んでよい条件
n8n のセルフホストは、次の3つが揃っているときだけ勧められます。1つでも欠けると、安くなったはずのコストが障害対応で消えます。
- サーバーの更新と障害対応を担当できる人が決まっている
- 止まっても翌営業日まで待てる業務である（受注処理などは不可）
- 月間の実行数が多く、Cloud のプラン料金を上回っている
この節は一次情報での裏取りが未了です。
料金は改定される。試算前に最新の料金表を確認すること。（2026-08-13 記載）
作ったn8nワークフローを販売して収益化する方法
n8n のワークフローは JSON として書き出せます。つまり設定ファイル1つが商品になります。実務で使えるものを作った経験があれば、そのまま販売できる形にできます。
売れる形にするための作業は、動くものを作った後の整備が中心。動作すること自体は出発点にすぎない。
図3 ── 注：期間は1本目の目安。2本目以降は整備の型ができるため短くなる。
認証情報の混入が最大の事故ワークフローの JSON には、設定によって認証情報が含まれることがあります。書き出したファイルを開いて、キーやトークンが残っていないか目で確認してください。気づかずに出品すると、購入者に自社の鍵を配ることになります。
価格を決める材料は、買う側が自作した場合の工数です。作るのに3日かかる処理なら、その3日を買っていることになります。自分がかけた時間ではなく、買い手が節約できる時間から考えると値付けが安定します。
この節は一次情報での裏取りが未了です。
ServiceDock 出品フロー（2026-08-13 記載）
よくある質問
n8n はプログラミングができなくても使えますか？
簡単な連携なら画面操作だけで組めます。ただし実務では、データの形を整えるために JavaScript を数行書く場面が出てきます。まったくコードを書かずに完結する範囲は、想像より狭いと考えておくのが安全です。
n8n と Zapier はどちらが安いですか？
実行数が少ないうちは Zapier の無料枠や下位プランが安く、実行数が増えるほど n8n のセルフホストが有利になります。ただしセルフホストにはサーバー費と運用工数が乗るため、単価だけの比較では判断を誤ります。
n8n を止めたくないのですが、可用性はどう考えればよいですか？
セルフホストの単一構成では、サーバーが落ちればワークフローも止まります。夜間バッチのように遅延が許容できる用途なら問題になりませんが、受注処理のように止まると業務が止まる用途では冗長化か Cloud を検討してください。
作ったワークフローは他社に売ってもよいのですか？
自分が作成したワークフロー（JSON）の権利は作成者にあります。n8n 本体の再配布とは別の話です。ただし内部で使っている外部APIの規約は別途確認が必要です。
まとめ
- n8n の判断軸は機能ではなく「サーバーを誰が見るか」。ここが決まらないと料金比較にも意味がない
- 得意なのはSaaS間のデータ受け渡し。複雑な業務ロジックを載せると保守できなくなる
- 壊れる原因は n8n の外側（API仕様変更・認証切れ・エラー時の無通知）にある
- ライセンスは社内利用なら問題ないが、再提供型のビジネスには制限があるため事前に原文を読む
今日から始められること
- 自動化したい業務を書き出し、SaaS間の受け渡しか業務ロジックかを分類する
- 対象SaaSのAPIに n8n のノードが存在するか確認する（無ければ HTTP ノードで自作）
- 月間の実行回数を見積もり、Cloud の料金表と突き合わせる
- セルフホストを選ぶ場合、障害時に誰が対応するかを決めておく
作りたい自動化を、既製のワークフローで済ませる
ServiceDock では、実務で使われている n8n ワークフローやMCPサーバーを購入できます。自分で組む前に、同じ処理が既にあるか探せます。
業務自動化のワークフローを見る