EC・物販の副業は、売れた後の作業が意外と重くなります。在庫確認、価格チェック、注文通知、発送前の確認、売上集計。ひとつずつは小さな作業でも、毎日続くとかなり時間を取られます。
n8nを使うと、こうした作業を「人が毎回見る」のではなく、「条件に合ったときだけ通知する」仕組みに変えられます。この記事では、EC・物販向けに在庫管理、価格監視、注文通知を自動化する基本設計を、公式ドキュメントで確認できるノードを中心に整理します。
- EC・物販でn8n自動化しやすい作業
- 在庫管理・価格監視・注文通知の基本フロー
- Google Sheetsを管理台帳にする設計
- 自動化しすぎると危ない作業
- ハルシネーションを避けるための確認ポイント
EC・物販で自動化しやすい作業
EC・物販の自動化で最初に狙うべきなのは、判断が明確な作業です。たとえば「在庫が3個以下なら通知」「仕入れ価格が一定以上変わったら記録」「新規注文が入ったらチャットへ送る」といった処理です。
| 作業 | 自動化しやすさ | 理由 | 注意点 |
|---|---|---|---|
| 在庫数チェック | 高い | 数値条件で判定できる | APIや台帳の数値が正しい前提が必要 |
| 価格監視 | 高い | 前回価格との差分を見ればよい | スクレイピングは規約確認が必要 |
| 注文通知 | 高い | 注文発生をトリガーにできる | 個人情報の扱いに注意 |
| 売上集計 | 中 | データ形式が揃えば自動化しやすい | 返品・キャンセルの反映が必要 |
| 発注判断 | 中 | 条件化はできるが、人の確認を残した方が安全 | 過剰発注のリスク |
| 顧客対応 | 低〜中 | 定型文は補助できる | クレームや個人情報は自動返信しすぎない |
基本構成：n8nで作るEC監視フロー
n8nの公式ドキュメントでは、Schedule Trigger、HTTP Request、Google Sheetsなどのノードが提供されています。EC自動化では、この3つを組み合わせるだけでも、かなり実用的な監視フローを作れます。
この流れのポイントは、いきなり全自動で発注まで進めないことです。最初は「通知まで」に止め、慣れてから発注書作成や仕入れ候補リスト作成へ広げる方が安全です。
在庫管理フローの作り方
在庫管理では、Google Sheetsを「商品台帳」として使うと始めやすくなります。商品名、SKU、現在庫数、最低在庫数、仕入れ先URL、最終確認日を列として持たせます。
| 列名 | 内容 | 例 |
|---|---|---|
| SKU | 商品管理番号 | AI-BOOK-001 |
| 商品名 | 管理用の商品名 | AI副業テンプレート集 |
| 現在庫 | 現在の在庫数 | 4 |
| 最低在庫 | 通知を出す基準 | 3 |
| 仕入れ先URL | 確認先 | 仕入れ先の商品ページ |
| 最終確認日 | n8nが更新した日時 | 2026-06-12 |
n8n側では、Schedule Triggerで毎朝1回起動し、Google Sheetsから商品台帳を読み込みます。現在庫が最低在庫以下になった行だけを抽出し、Slackやメールで通知します。
価格監視フローの作り方
価格監視では、前回価格と今回価格の差分を見る設計にします。HTTP RequestでAPIや取得可能な価格データを読み、Google Sheetsに前回値を保存しておけば、差分判定ができます。
注意点として、Webページをスクレイピングする場合は、対象サイトの利用規約やrobots.txt、アクセス頻度への配慮が必要です。APIが用意されているサービスでは、APIを使う方が安定します。
注文通知フローの作り方
注文通知は、ECプラットフォーム側のWebhookやAPIが使えるかどうかで設計が変わります。Webhookが使える場合は注文発生をトリガーにできます。使えない場合は、Schedule Triggerで定期的に新規注文を確認する形になります。
| 方式 | メリット | デメリット |
|---|---|---|
| Webhook | 注文発生後すぐ通知できる | ECサービス側の設定が必要 |
| API定期確認 | 構成がわかりやすい | リアルタイム性は少し落ちる |
| メール受信トリガー | APIがないサービスでも使える場合がある | メール文面変更に弱い |
通知内容には、注文番号、商品名、数量、発送期限だけを入れるのが無難です。氏名、住所、電話番号などの個人情報をチャットに流す設計は、必要性と保存期間を慎重に考えてください。
自動化しすぎると危ない作業
EC自動化で最も危ないのは、人の確認を外しすぎることです。特に、仕入れ発注、価格変更、顧客への自動返信、返金処理は、最初から完全自動にしない方が安全です。
- 発注は「発注候補リスト作成」までにする
- 価格変更は「変更候補の通知」までにする
- 顧客対応は「返信案の作成」までにする
- 個人情報を含む通知は最小限にする
- エラー時に止まる設計を必ず入れる
次に読む記事
EC自動化の考え方を確認したら、n8nの基本、ツール比較、自動化事例へ進むと実装しやすくなります。
副業での現実的な導入ステップ
| 段階 | 作るもの | 目安時間 | 効果 |
|---|---|---|---|
| Step 1 | 在庫低下通知 | 1〜2時間 | 確認漏れを減らす |
| Step 2 | 価格変動記録 | 2〜4時間 | 仕入れ判断がしやすくなる |
| Step 3 | 注文通知 | 2〜5時間 | 発送遅れを防ぎやすい |
| Step 4 | 週次売上レポート | 3〜6時間 | 改善判断がしやすくなる |
| Step 5 | 発注候補リスト | 4〜8時間 | 仕入れ作業を短縮できる |
ハルシネーションチェック
この記事で紹介した構成は、n8n公式ドキュメントで確認できるSchedule Trigger、HTTP Request、Google Sheetsなどのノードを前提にしています。ただし、各ECサービスのAPI、Webhook、注文データ形式はサービスごとに異なります。
- 「すべてのECサイトで同じ方法が使える」とは断定しない
- APIやWebhookの有無は、使うECプラットフォームの公式情報で確認する
- スクレイピングは利用規約、アクセス頻度、robots.txtを確認する
- 個人情報を扱う通知は、保存先と閲覧権限を確認する
- 自動発注や自動返信は、最初から完全自動にしない
EC自動化の基本ワークフロー図解
n8nで最初に作るべきなのは、完全自動で売上を増やす仕組みではなく、確認漏れを減らす小さな監視フローです。下のように、データ取得、条件判定、通知、記録の4段階に分けると設計しやすくなります。
注文・在庫・価格
在庫低下・価格差
Slack・メール
Sheets・DB
自動化前に決める運用ルール
| 項目 | 決める内容 | 失敗しやすい例 |
|---|---|---|
| 実行頻度 | 何分・何時間ごとに確認するか | 必要以上に短い間隔でAPI制限や規約違反に近づく |
| 通知条件 | どの状態になったら通知するか | 全件通知して、重要な通知を見落とす |
| 権限管理 | APIキーやシートを誰が見られるか | 共有リンクを広げすぎて個人情報が漏れる |
| 手動確認 | どこまで人間が最終判断するか | 価格変更や返信をいきなり完全自動にする |
| ログ保存 | いつ、何を、なぜ実行したか残す | エラー原因が分からず復旧に時間がかかる |
特に副業や小規模ECでは、最初から発注・返信・価格変更まで自動化しないほうが安全です。まずは「見落としやすい状態を通知する」段階にとどめ、動作が安定してから次の自動化へ進めます。
費用対効果の見方
自動化の価値は、ツール代だけでなく「毎月どれだけ確認時間を減らせるか」で判断します。たとえば1日15分の確認作業を自動化できれば、月30日で約7.5時間です。時給換算で1,500円なら、月11,250円分の作業を削減できる計算になります。
まとめ
n8nでEC・物販を自動化するなら、最初に作るべきなのは派手な完全自動システムではありません。在庫低下、価格変動、新規注文を検知し、必要なときだけ通知する仕組みです。
通知までの自動化でも、毎日の確認作業はかなり減らせます。まずはGoogle Sheetsを台帳にして、Schedule Trigger、HTTP Request、条件分岐、通知ノードを組み合わせるところから始めるのが安全です。
確認した一次情報
- n8n Docs: Schedule Trigger node
- n8n Docs: HTTP Request node
- n8n Docs: Google Sheets node
- n8n Docs: workflow components and execution concepts
