定義
Make（メイク） とは、ノーコードでアプリケーション同士を連携させ、マーケティングやバックオフィスの業務フローを自動化できるビジュアル自動化プラットフォームです。旧称は Integromat（インテグロマット）。キャンバス上に「モジュール」と呼ばれる処理ブロックをドラッグ＆ドロップで配置し、線でつなぐだけで複雑なシナリオ（ワークフロー）を構築できます。
DTC・EC文脈では、Shopify、WooCommerce、BASE、楽天市場などのECプラットフォームと、Klaviyo、Meta広告、Google Sheets、Slack、Chatwork、freee、kintone などを接続し、「受注→在庫更新→顧客タグ付け→LINE配信→広告オーディエンス同期」といった一連の処理を人手ゼロで回す用途で多用されます。
Zapier が「トリガー→アクション」の直線的な1対1連携を得意とするのに対し、Make は 分岐・ループ・反復・エラーハンドリング・データ変換 を視覚的に組めるため、より複雑なオペレーションに向きます。
类比（たとえるなら）
Make は 「EC運営のための配線盤（スイッチボード）」 です。
- モジュール = 各従業員（「注文を取得する人」「在庫を引く人」「メールを送る人」）
- コネクション（線） = 社内の稟議ルート
- フィルター = 「VIP顧客だけ通す」受付の関所
- ルーター = 部署ごとに振り分ける仕分け係
- イテレーター = 明細行を1件ずつ処理する伝票めくり
つまり、「人を雇わずに業務マニュアルをそのまま絵に描いて実行させる」 感覚です。Excelマクロの視覚版＋クラウド連携版と考えると、日本のEC担当者にはイメージしやすいでしょう。
公式（処理量とコストの考え方）
Make の課金は「オペレーション数」で決まります。1モジュールが1回実行されるたびに1オペレーション消費します。
月間オペレーション数 = Σ (各シナリオの実行回数 × 1実行あたりのモジュール通過数)
具体例：
- シナリオ：Shopify新規注文 → 顧客をKlaviyoに登録 → Slack通知 → Google Sheetsに追記
- 1実行あたりのモジュール通過数 = 4
- 1日の注文数 = 150件
- 月間オペレーション = 150 × 4 × 30 = 18,000 オペレーション
Make の Core プラン（月10,000オペレーション）では足りず、Pro プラン（月10,000〜）または上位プランへの昇格が必要になります。「注文1件＝4オペレーション」という原単位を最初に把握することが、DTC現場では最重要です。
比較表：Make vs 主要ツール
| 項目 | Make | Zapier | n8n | Shopify Flow |
|---|---|---|---|---|
| 操作UI | キャンバス型（視覚的） | リスト型（直線的） | ノード型（技術者向け） | Shopify管理画面内 |
| 分岐・ループ | ◎ 標準対応 | △ パス機能で限定的 | ◎ | ○ 条件分岐のみ |
| 学習コスト | 中 | 低 | 高 | 低 |
| 無料枠 | 月1,000オペレーション | 月100タスク | セルフホストで無制限 | 無料（Shopify契約内） |
| 日本語UI | ○ 対応 | ○ 対応 | △ 一部 | ○ |
| 向く用途 | 複雑なEC業務自動化 | シンプルな連携 | 開発チーム主導 | Shopify内完結 |
| 月額目安 | 約$9〜 | 約$20〜 | 無料〜 | 無料 |
DTCの実務結論： 「Shopify内で完結する在庫・タグ操作」は Shopify Flow、「外部SaaSを3つ以上またぐ複雑フロー」は Make、という併用が最もコスパが高い構成です。
応用シーン（DTC/ECでの具体例）
1. カゴ落ちリカバリの自動化
Shopifyで「checkout abandoned」を検知 → 30分後にKlaviyoへ顧客同期 → 2時間後にLINE公式でリマインド → 24時間後にクーポンコード付きメール。回収率は手動運用比で平均+15〜25% と言われます。
2. 在庫切れ→広告停止の連動
在庫数が閾値（例：5以下）を下回ったら Meta広告の該当商品キャンペーンを自動一時停止。無駄なクリック課金を月3〜8万円削減 した事例も。
3. VIP顧客の自動タグ付けとCRM同期
累計購入額が 30,000円以上 になった顧客に VIP タグを付与 → kintoneの顧客マスタへ同期 → 専用クーポンを自動発行。
4. 返品処理のバックオフィス連携
返品申請フォーム送信 → freeeに売上返還を記帳 → 在庫を+1に戻す → SlackでCSチームに通知。
よくある誤解（アンチパターン）
- 「Makeに全部やらせればいい」 → リアルタイム性が求められる処理（決済・与信）には不向き。遅延やAPI制限で失敗します。
- 「オペレーション数は無制限」 → ループ処理を多用すると1実行で数百オペレーションを消費。気づかず月額が跳ね上がる典型パターン。
- 「ノーコードだから誰でも保守できる」 → 属人化しやすく、担当者退職でブラックボックス化するリスク大。命名規則とドキュメント化が必須。
- 「エラーは起きない」 → API仕様変更や認証切れで毎月必ず数回は停止。Error Handler とSlackアラートを必ず組み込みましょう。
- 「Zapierの完全上位互換」 → 単純な1対1連携ならZapierのほうが速く安いケースも多い。
関連用語
- シナリオ（Scenario）：Makeにおける1つの自動化フロー単位
- モジュール（Module）：処理ブロック。トリガー／アクション／検索／変換に分類
- オペレーション（Operation）：課金単位。モジュール1回実行＝1
- Webhook：外部からMakeを起動するHTTPエンドポイント
- ルーター／フィルター／イテレーター：分岐・条件・繰り返しの3種の神器
- Zapier：最大手の競合。直線型連携に強い
- n8n：セルフホスト可能なOSS系。エンジニア向け
- Shopify Flow：Shopifyネイティブの自動化。Makeと併用が定石
- Klaviyo：DTC定番のCRM。Make経由でセグメント同期が可能
まとめ： Make は「EC運営の複雑な分岐と繰り返しを、絵で描いて自動実行させる」ためのプラットフォームです。導入前にオペレーション原単位を試算し、Shopify FlowやZapierと役割分担させること。これがDTC現場でMakeを失敗させない最大のコツです。