Slack通知やCRM連携、Webhook経由のAI処理など、サービス間を繋ぐ自動化基盤を運用している方に向けた内容です。ZapierやMake.comのタスク課金に違和感を持ち始めたエンジニアの判断材料として整理しました。
ZapierやMake.comは「タスク実行回数」に応じて課金される仕組みです。ワークフロー（複数のアプリ連携処理を一つの自動化として組んだもの）が月1万回実行されると、プランが月100〜300ドル超に跳ね上がるケースがあります。これは事業が成長してAPI呼び出しが増えるほど負担が重くなる構造で、個人開発者やブートストラップ（外部資金に頼らない）スタートアップにとって無視できないコストです。
ここで選択肢に挙がるのがn8n（エヌエイトエヌ、ノードベースのビジュアル自動化ツール）です。オープンソース・フェアコード（商用利用に一部制限があるライセンス形態）で提供されており、400以上の統合ノードを持ち、自前のサーバーに無料でセルフホストできます。本記事では、n8nがどういう仕組みで動き、どこを確認すれば自分のプロジェクトに適用できるかを解説します。
n8nの技術的な仕組みと構成要素
n8nはNode.js製のワークフローエンジンで、Dockerコンテナとして配布されています。各「ノード」がSlack・Postgres・OpenAIなどのAPI呼び出しを表現し、ノード同士をキャンバス上で繋ぐことでワークフローを組み立てます。ここはZapierの「Zap」やMakeの「シナリオ」と役割が近い部分です。
大きな違いは実行環境です。Zapierはクラウド上の共有リソースでタスクを実行し、その使用量に応じて課金します。n8nは自分で用意したVPS（仮想専用サーバー）上でコンテナを起動し、実行回数に上限を設けない運用が可能です。つまり課金モデルが「実行回数ベース」から「サーバーの固定費ベース」に変わる点が本質的な違いです。
セルフホスト構成では、n8n本体に加えてリバースプロキシ（外部からのHTTPSリクエストを内部コンテナへ中継する役割）としてCaddyを組み合わせるのが定番です。CaddyはLet's Encryptから無料のSSL証明書を自動取得・更新してくれる軽量Webサーバーで、Nginxのような手動証明書設定が不要になります。docker-compose.ymlにcaddy:2-alpineイメージを記述し、reverse-proxy --from https://your-domain.comを指定するだけでHTTPS化が完了します。
AI連携を使う場合は、n8n内のLangChain系ノードを使ってOpenAIやAnthropicのAPI、PineconeやChromaのようなベクターデータベース（埋め込みベクトルを検索するためのDB）、あるいはローカルLLMまでチェーンできます。APIキーや顧客データがすべて自前のサーバー内に留まるため、プライバシー要件が厳しい業務にも向いています。
既存の自動化ツールとの比較軸
n8nを検討する際の比較軸は大きく3つあります。
| 観点 | Zapier / Make.com | セルフホストn8n |
|---|---|---|
| 課金モデル | タスク実行回数に比例 | VPSの固定費（月12ドル程度〜） |
| 運用負担 | ほぼゼロ(SaaS) | サーバー・証明書・更新を自分で管理 |
| カスタムコード実行 | タイムアウト制限あり | JS/Pythonを制限なく実行可能 |
運用負担が増える代わりに、実行回数の天井とコードのタイムアウト制約から解放される、というトレードオフです。小規模な自動化しか動かさないならZapierの手軽さが勝ちますが、Webhookを大量に受けるプロダクトや、AIエージェントのように長時間処理が発生するワークフローではセルフホストの自由度が効いてきます。
日本の現場で近いポジションにあるのはGASベース（Google Apps Script）のスプレッドシート連携や、AWS Step Functionsのようなマネージド型のワークフローオーケストレーションです。ただしStep Functionsはコード中心でビジュアルエディタの手軽さに欠け、GASは外部API連携の自由度が限定的です。n8nはその中間、つまり「ノーコードに近い操作感」と「任意のコードを実行できる自由度」を両立している点が特徴といえます。
導入前に確認すべきこと
セルフホストに踏み切る前に、自分のプロジェクトが該当するか次の基準で判断できます。
- 月あたりのタスク実行数がZapierの上位プラン(数千〜数万タスク)に近づいているか
- APIキーやDB接続情報を外部SaaSに預けたくない社内規定があるか
- ワークフロー内で数十秒を超える処理（大きめのLLM呼び出し等）が発生するか
- サーバーのOSアップデートや証明書更新を自分たちで対応できる体制があるか
実際に試す場合は、DigitalOceanなどのクラウドでUbuntu 24.04 LTSのDropletを作成し、2GB RAM/1vCPU程度のプランから始めるのが現実的です。この構成であれば月12ドル前後で、同時実行を伴うワークフローにも耐えられます。
導入手順の骨子は次の通りです。
# Dockerとdocker-composeのインストール
sudo apt update && sudo apt upgrade -y
sudo apt install -y docker.io docker-compose
# バージョン確認
docker --version && docker-compose --versionその後、作業ディレクトリにdocker-compose.ymlを作成し、n8n本体のコンテナとCaddyのリバースプロキシ設定を記述してからdocker-compose up -dで起動する流れになります。ドメインのDNSにAレコードでサーバーIPを指定しておく点も忘れずに確認してください。
導入後は、n8nの管理画面からワークフローのバージョン（n8nは頻繁にアップデートされるため）や、使用中のノードが最新のAPI仕様に対応しているかを定期的に見直す必要があります。特にOpenAIやAnthropicのAPI側でモデル名が変更された場合、ノードの設定を手動で更新しないとワークフローが失敗する点は留意しておくべきです。
まとめ
n8nのセルフホストは、Zapierのタスク課金から固定費モデルへ切り替える選択肢です。
月1万回規模の実行があるなら、2GB RAMのVPSに月12ドル前後でn8nとCaddyを組み合わせる構成が現実的な出発点になります。
判断基準としては、実行回数の伸び、データ主権の要件、長時間処理の有無、そして証明書更新やOSパッチを自前で回せる運用体制があるかどうかです。
まずは小さなワークフローを1つ移植してみて、実行の安定性とコスト差を比較するところから始めてみてください。