この記事の内容
  1. 毎晩の照合に必要な結果を決める
  2. Cloudの実行数を業務へ当てはめる
  3. Starterと保守費を別の行に置く
  4. 自己ホストでは復旧まで引き受ける
  5. 版と用途に合う権限を選ぶ
  6. 空の結果と未処理を見分ける
  7. フローの保存とサービスの移行を分ける

毎晩の照合に必要な結果を決める

例として、注文APIと発送記録を毎晩照合し、発送待ちだけを担当者へ渡す業務を考えます。実行時刻は午前一時でも、対象を前日分にするか、最後に完了した期間以降にするかで結果は変わります。時刻の基準、注文ID、取消の扱い、遅れて届く記録を先に決めてください。最初は本番の発送状態を書き換えず、手作業の集計と照合する一覧を出します。処理画面の成功ではなく、未発送を正しく説明できることを開始条件にします。

Cloudの実行数を業務へ当てはめる

n8n Cloudの料金は月間ワークフロー実行数を軸にしており、通常の各ステップを別々に数える方式とは違います。ただし、何を一回の実行にまとめるかは設計次第です。一日一回の取得と、注文ごとの入口では開始回数が変わります。実行枠に収まっても、同時実行、処理時間、履歴の条件が十分とは限りません。通常日と月末の量を分け、APIのページ分割や遅延を含む実行で必要な条件を確認します。長い図だから自動的に安いとは判断しません。

Starterと保守費を別の行に置く

確認したStarterは2,500実行で、年払い時は月額換算20ユーロ、基本年額240ユーロです。月払いは24ユーロという条件で比較します。税、別契約のAPI、AI利用などを含む総額ではありません。Cloudを選んでも、注文項目の変更や認証切れへの対応は自社に残ります。誰が毎朝結果を見て、どの条件なら修正を依頼するかまで予算へ含めてください。年払いを選ぶ前に、必要な枠と管理機能が一年間続けて役立つかを確認します。

自己ホストでは復旧まで引き受ける

Community版を自分たちで運営するなら、サーバー、更新、保存量、監視、バックアップの担当を決めます。n8nは認証情報を暗号化する鍵を使うため、データベースだけ保存して復旧できると思わないでください。鍵を安全に管理し、別の環境で接続が使える状態まで戻す手順を確認します。復旧環境が本番と同時に発送や通知を実行しない設定も必要です。ソフトウェア代が不要な範囲でも、毎朝の締め切りを守れる体制まで無償になるわけではありません。

版と用途に合う権限を選ぶ

自己ホストできることと、複数担当者への共有や管理機能をすべてCommunityで使えることは別です。公式の共有機能説明では、Cloudと自己ホストの対象区分に違いがあります。作る人、実行結果を見る人、接続を管理する人を分けて確認してください。Communityの公式FAQは、社内で作成・変更する自動化と、社外の人へ編集機能を提供する場合を区別しています。顧客が自分でフローを編集する製品へ組み込むなら、その用途に必要な契約を提供元へ確認します。

空の結果と未処理を見分ける

注文がゼロ件だった日と、認証や抽出条件が誤ってゼロ件になった日を区別します。前日の件数に必ず合わせるのではなく、取得期間、ページ数、除外、未処理を確認できるようにします。二ページ目で止まる例、同じ期間の再実行、確定後に届く注文を見本へ入れてください。再実行で発送状態や通知を重ねないため、完了済みの注文を調べる方法も決めます。作成者以外の担当者が結果と修正先を説明できれば、継続運用を評価しやすくなります。

フローの保存とサービスの移行を分ける

公式にはフローをJSONで書き出す方法があり、接続の名前やID、cURL由来のヘッダーなどが含まれる場合は共有前に点検します。書き出しだけで、認証情報、履歴、外部サービスの記録がすべて移るわけではありません。移行先では最後に完了した期間を引き継ぎ、同じ入力で照合結果が一致するか確認してください。Cloud契約の終了と自己ホストへの移行は別の手続きです。必要な記録を確保し、旧処理の停止と新処理の開始を決めてから契約変更へ進みます。

利用量から費用を確かめる

月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。

費用を試算する

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について