n8n 使い方の本質 — セルフホスト 1 台で 1,300 ページ運用の自動化を支える設計
「n8n 使い方」を検索した人が本当に欲しい答え
「n8n 使い方」と検索する人の多くは、ノード接続のチュートリアルを探している。だがチュートリアルを読み終えた後、ほとんどの人は次の壁にぶつかる。「で、何を自動化すればいいのか」がわからない。
ここではノードの繋ぎ方ではなく、n8n を「実運用に乗せる」ための判断基準を共有する。具体的には、1,300 ページ規模の Web サイトを運用する筆者が、Cloud ではなくセルフホストを選び、Docker で立てた n8n 1 台で Instagram 投稿の自動化を回している実装事例を素材にする。
n8n そのものの概要は公式が詳しい。本記事の独自性は 「なぜその構成にしたか」の判断理由と、自動化対象の選定軸にある。
n8n とは — 公式定義の確認
n8n（エヌエイトエヌ）は、ドイツ発のオープンソースなワークフロー自動化プラットフォームである。公式は「AI Workflow Automation Platform」と位置づけ、400 以上のサービス統合を提供している（出典：n8n 公式サイト、取得日 2026-05-20）。
GitHub stars は 189,000、最新リリースは v2.21.4（2026-05-19、出典：n8n GitHub リポジトリ、取得日 2026-05-20）。技術スタックは TypeScript 91.3% + Vue 7.4% で、Node.js 上で動作する。
ライセンスは「Sustainable Use License」と「n8n Enterprise License」の 2 段構成（fair-code モデル）。Community Edition は GitHub から無料で取得でき、商用利用も可能だが、再販やマネージドサービスとしての提供には Enterprise License が必要になる。
提供形態は 2 つ
| 形態 | 月額 | 実行回数上限 | 用途 |
|---|---|---|---|
| n8n Cloud Starter | €20 | 2,500 executions | 小規模・運用工数を払いたくない |
| n8n Cloud Pro | €50 | 10,000 executions | チーム運用・並列実行 20 |
| n8n Cloud Business | €667 | 40,000 executions | セルフホスト license key 付属 |
| Community Edition（セルフホスト） | 無料 | 無制限 | 商用利用可・運用工数は自分持ち |
出典：n8n 公式 価格ページ、取得日 2026-05-20。
ここで多くの記事は「個人なら Cloud、企業ならセルフホスト」と片付ける。だが実運用の判断軸はもう少し細かい。
なぜセルフホスト + Docker を選んだか — 判断の言語化
筆者は yumesuta.com（1,300 ページ以上）の運用で n8n をセルフホスト構成で立てている。Cloud Starter（€20/月）ではなくセルフホスト Community Edition（無料）を選んだ理由は 3 つある。
理由 1：実行回数の上限がコンテンツ運用と相性が悪い
Cloud Starter の 2,500 executions/月は、1 日あたり約 83 回。Instagram 自動投稿だけなら足りるが、Google Sheets の変更検知・記事 URL の死活監視・サイトマップ pull など、運用系の小さなワークフローを並列で回すと一瞬で枯渇する。Pro（€50・10,000 executions）に上げる選択肢もあるが、年額 €600 を払うなら自宅サーバーや VPS（月 ¥500 程度）で運用したほうが筋がいい。
理由 2：API キーと認証情報を自分の環境に置きたい
Instagram Graph API のアクセストークン、Google Service Account の秘密鍵、Gemini API キー、これらは Cloud に預けるよりローカルに置いたほうが管理しやすい。漏洩時の影響範囲も自分で握れる。SaaS のセキュリティを信用しないわけではないが、「何かあったときに自分で原因を追える」状態のほうが運用上は楽である。
理由 3：n8n の設計思想と自分の運用方針が一致している
n8n は「ワークフローを JSON で export/import できる」のが特徴である。これは Docker volume と組み合わせると、ワークフローをコードと同じようにバージョン管理できることを意味する。1,300 ページ運用の哲学は「判断を CONFIG に切り出して再現性を担保する」というもので、n8n の JSON エクスポートはこの方針と自然に噛み合う。
逆に Cloud は UI で完結する利便性があるが、ワークフロー定義が n8n の管理下にロックインされる。長期運用するなら、定義ファイルが手元にある状態のほうが取り回しがいい。
セルフホストを選ばないほうがいいケース
公平のために逆ケースも書いておく。以下に該当するなら Cloud のほうが合理的である。
- Docker の運用経験がない（学習コストが本業を圧迫する）
- 24/365 の可用性が必要（自宅サーバーが落ちると業務が止まる）
- チーム複数人で同時編集する（権限管理が SaaS のほうが楽）
「セルフホストが正解」ではなく、「自分の運用状況に合っているか」が判断軸になる。
最小構成 — Docker Compose で起動する
セルフホストの最小構成を共有する。Docker Desktop（Windows / Mac）か Docker Engine（Linux）が入っていれば動く。
# docker-compose.yml
version: '3.8'
services:
n8n:
image: n8nio/n8n:latest
container_name: n8n
restart: unless-stopped
ports:
- "5678:5678"
environment:
- N8N_HOST=localhost
- N8N_PORT=5678
- N8N_PROTOCOL=http
- WEBHOOK_URL=http://localhost:5678/
- GENERIC_TIMEZONE=Asia/Tokyo
volumes:
- ./n8n_data:/home/node/.n8n
起動コマンドは docker compose up -d の 1 行。http://localhost:5678 にブラウザでアクセスすると初回登録画面が出る。
ここで注意点が 1 つ。n8n_data ボリュームには認証情報・ワークフロー定義・実行ログがすべて入る。これを git で管理してはいけない（秘密情報が含まれるため）。代わりに、ワークフロー定義だけ手動で JSON export して別 repo に commit する運用が現実的である。
公式ライセンスキー（Community Edition の機能解放）は n8n 公式サイト でメール登録すると無料で発行される。これを設定すると、ワークフロー履歴のフィルタリングや advanced execution view が使えるようになる。
実装事例 — Instagram 自動投稿パイプライン
ここから具体例に降りる。筆者が運用している Instagram 自動投稿の全体像は以下のとおり。
[Google Sheets（投稿予定表）]
↓ Schedule Trigger（毎時実行）
[n8n Workflow]
├ Sheets node：未投稿行を取得
├ Code node：投稿可否判定（投稿予定日時 ≤ 今）
├ HTTP Request：Gemini API で画像生成
├ HTTP Request：Instagram Graph API で投稿
└ Sheets node：投稿済みフラグを更新
ノードを繋ぐだけのチュートリアルなら 1 時間で書ける。だが運用に乗せるには、ここから先の判断が 5 つある。
判断 1：Schedule Trigger の間隔をどうするか
Instagram Graph API のレート制限は 1 ユーザーあたり 200 calls/時。投稿頻度が 1 日 3 回なら、Schedule を 1 時間に 1 回にして「予定時刻を過ぎた未投稿行があれば投稿」する設計が安定する。5 分間隔の polling は API quota の無駄遣いになる。
判断 2：エラー時の挙動
Instagram API は時々 5xx を返す。n8n の各ノードには「Continue On Fail」設定があり、これを on にすると後続ノードが続行される。だが投稿失敗時は 「投稿済みフラグを更新しない」ほうが安全。次回 Schedule で再試行されるからである。フラグを先に更新する設計だと、API 失敗時に投稿が消える。
判断 3：認証情報の管理
n8n は credentials store を持っており、API キーやアクセストークンを暗号化して保存できる。ワークフロー JSON には credential ID しか書かれないので、エクスポートしたワークフローを公開しても秘密情報は漏れない。これが Docker volume を git 管理してはいけない理由でもある（credentials の本体は volume 側にある）。
判断 4：実行ログの保持期間
Community Edition でも実行ログは保存されるが、ログが溜まると n8n_data ボリュームが肥大化する。環境変数 EXECUTIONS_DATA_PRUNE=true と EXECUTIONS_DATA_MAX_AGE=168（時間単位）を入れると、7 日以上前のログは自動削除される。
判断 5：Cloud と同じ画面で動かす運用感
セルフホストでも UI は Cloud と同じである。ワークフロー編集中にエラーが出たら、Cloud の execution view と同じ画面でデバッグできる。「セルフホスト = 不便」ではない。
n8n の限界と向き不向き
n8n を選ぶ前に知っておいたほうがいい限界も共有する。
向いていること
- 「サービス A の変更を検知して、サービス B に転送する」型の単純なワークフロー
- 既存 API を組み合わせた業務自動化（Slack 通知・Sheets 同期・メール送信など）
- AI 機能（ChatGPT・Claude・Gemini ノード）と既存 API の組み合わせ
- ノーコード／ローコード環境でエンジニアと非エンジニアが共同編集する場面
向いていないこと
- 大量データの ETL：n8n は execution ごとにメモリに全データを載せる設計で、数十万行のデータ処理には不向き。これは Python スクリプトのほうが速い
- 複雑な分岐ロジック：if 分岐が 5 段以上ネストするなら、JavaScript で書いたほうが保守しやすい
- ミリ秒単位のリアルタイム処理：n8n の workflow 起動には数百 ms かかる
「n8n でなんでもできる」は誤解で、ノード接続で表現しやすい範囲を見極めることが運用上の鍵になる。
n8n を本格的に学ぶには
n8n のノード仕様、Instagram API 連携、Google Sheets を使ったコンテンツ自動投稿の体系的な手順は、筆者が運用している n8n 自動化講座（全 38 モジュール） にまとめている。Docker セットアップから Reel 投稿、Canva 連携、AI コンテンツ生成、スケジュール投稿まで網羅している。
この記事で n8n の判断軸を掴んだら、講座でハンズオンに進める構成になっている。
まとめ — 使い方ではなく判断軸を持つ
「n8n 使い方」を検索する人に伝えたいのは、ノードの繋ぎ方ではなく 判断軸である。
- Cloud かセルフホストか：実行回数 / 認証情報の置き場所 / 長期運用方針 で決まる
- 自動化対象の選定：ノード接続で表現しやすい範囲かどうか が線引き
- 運用設計：API レート制限・エラー時の挙動・実行ログ管理 が安定運用の鍵
n8n はツールであり、ツールの価値は 何を自動化するか で決まる。チュートリアルが終わったあとに残るのは、その判断軸を自分の現場に当てはめる作業である。
- 関連リポジトリ: 漆畑式 LLMO（GitHub）
- 関連講座: n8n 自動化講座（全 38 モジュール）