Zapier/Make連携でSMMパネル注文を自動化する方法｜ノーコード導入ガイド

結論：ZapierとMakeは「HTTPアクション」経由でSMMパネルAPIに繋げられる

ZapierにもMakeにも「SMMパネル」専用の公式コネクタは基本的に存在しません。しかし両サービスとも、任意のURLへHTTPリクエストを送れる汎用アクション(Zapierは「Webhooks by Zapier」、Makeは「HTTP」モジュール)を備えています。SMMパネルのリセラー向けAPI(APIキー認証・フォーム形式でaction/service/link/quantityを送信する方式が一般的)は、この汎用アクションと相性が良く、コードを書かずに「スプレッドシートに行が追加されたら発注」「フォーム送信で注文」といった自動化が組めます。

前提として、パネルの管理画面(アカウント設定→APIキー発行の画面が一般的です)でリセラー用APIキーを発行しておく必要があります。キーは作成時に一度だけ表示されるため、Zapier/Make側の設定を始める前に安全な場所(パスワードマネージャー等)へ控えておきましょう。

具体的な連携手順

Zapierの場合(Webhooks by Zapier)

1. 新規Zapを作成し、トリガーを選択(例: Google Sheetsの「新しい行」)。
2. アクションで「Webhooks by Zapier」→「POST」を選択。
3. URLにパネルのAPIエンドポイントを入力。
4. 「Payload Type」をFormに設定(多くのSMMパネルAPIはform-urlencoded形式を要求します)。
5. Dataフィールドに以下のキーを追加:
   • key: 発行したAPIキー
   • action: add(新規注文の場合)
   • service: サービスID(パネルのサービス一覧から事前に控える)
   • link: 注文対象URL(トリガー元のスプレッドシート値を差し込む)
   • quantity: 数量
6. 「Test action」で1件だけ実際に送信し、レスポンスに注文IDが返ることを確認。
7. 問題なければZapを「On」にして本番稼働へ。

Makeの場合(HTTPモジュール)

1. シナリオを新規作成し、トリガーモジュールを配置(例: Googleフォームの「新しい回答」)。
2. 「HTTP」→「Make a request」モジュールを追加。
3. URLにエンドポイントを指定し、メソッドはPOST。
4. Body typeをx-www-form-urlencodedにし、key・action・service・link・quantityをKey-Value形式で入力。値には前段モジュールの出力(マッピング)を差し込みます。
5. 「Run once」でテスト実行し、レスポンスのJSONを確認。
6. レスポンスの注文IDを後続モジュール(Google Sheetsへの書き戻しや通知)に接続すれば、発注と記録が1シナリオで完結します。

どちらのツールでも共通のポイントは、APIキーをハードコードせず、可能な限り「接続情報」や「環境変数」的な機能で分離管理することと、テスト実行は必ず少量・低コストの注文で行うことです。

活用シナリオ

• スプレッドシート一括発注: 営業や運用担当がGoogleスプレッドシートに注文リスト(URL・数量・サービス)を入力するだけで、行の追加をトリガーに自動発注。手作業でのコピペ発注をなくせます。
• 注文受付フォームの自動化: 顧客向けにGoogleフォームやTypeformで簡易注文フォームを用意し、送信内容をそのままAPIへ流す。フォームの回答をパネル側の正式な注文導線と組み合わせる場合は、価格計算や不正入力のチェックをフォーム側かZapier/Makeのフィルター機能で挟むと安全です。
• ECサイトの注文と連動した発注: Shopifyなど外部ECの「注文作成」イベントをトリガーに、商品オプションに応じたサービスIDへ振り分けて自動発注。物理商品とSNS施策をセット販売している場合に有効です。
• 定期発注のスケジュール実行: Zapierの「Schedule」やMakeの「Scheduling」機能を使い、毎週決まった曜日に同じ注文を自動送信する定期実行も組めます。

注意点

• APIキーの管理: Zapier/MakeにAPIキーを平文で保存することになるため、共有アカウントでの利用や退職者アクセスの見直しなど、アクセス権限の管理を徹底してください。不要になった連携のキーはパネル側で失効(ローテーション)させましょう。
• : トリガー元のデータが重複したり、シナリオが再実行されたりすると同じ注文が複数回送信される恐れがあります。可能であればトリガー側に一意なIDを持たせ、送信済みかどうかを別列やフィルターで判定する仕組みを入れると安全です。