Zapier & Make パターン

ノーコード自動化はワークフロー構築を民主化します。Zapier と Make (旧 Integromat) により、開発者でなくてもコードを書かずにビジネスプロセスを自動化できます。ただし、ノーコードは複雑でないことを意味しません。これらのプラットフォームには独自のパターン、落とし穴、限界があります。

このスキルでは、どのプラットフォームを使用するべきか、信頼できる自動化を構築する方法、コードベースのソリューションにアップグレードするタイミングについてカバーします。重要な洞察：Zapier はシンプルさと統合性 (7000 以上のアプリ) に特化し、Make は力とコスト効率 (ビジュアルブランチング、操作ベースの価格設定) に特化しています。

重要な区別：ノーコードは機能しなくなるまで機能します。限界を知りましょう。

原則

• シンプルに始め、必要な場合にのみ複雑さを追加する
• ライブになる前に実データでテストする
• わかりやすいネーミングで各自動化を文書化する
• エラーを監視 - 95% エラー率で自動的に Zap が無効になる
• コードベースのソリューションにアップグレードするタイミングを知る
• Operations/tasks にはコストがかかります。効率的に設計しましょう

機能

• zapier
• make
• integromat
• no-code-automation
• zaps
• scenarios
• workflow-builders
• business-process-automation

スコープ

• code-based-workflows → workflow-automation
• browser-automation → browser-automation
• custom-integrations → backend
• api-development → api-designer

ツール

プラットフォーム

• Zapier - 使用時期：シンプルな自動化、最大限のアプリカバレッジ、初心者 注：7000 以上の統合、線形ワークフロー、タスクベースの価格設定
• Make - 使用時期：複雑なワークフロー、ビジュアルブランチング、予算に配慮したい場合 注：ビジュアルシナリオ、操作ベースの価格設定、強力なデータハンドリング
• n8n - 使用時期：セルフホスト、コードフレンドリー、無制限の操作 注：オープンソース、カスタムコードを追加可能、技術ユーザー向け

AI_features

• Zapier Agents - 使用時期：AI 駆動の自律型自動化 注：自然言語指示、7000 以上のアプリへのアクセス
• Zapier Copilot - 使用時期：AI 補助による Zap の構築 注：ワークフローを記述、AI が構築
• Zapier MCP - 使用時期：Zapier アクション へアクセスする LLM ツール 注：AI モデルで利用可能な 30,000 以上のアクション

パターン

基本的なトリガー-アクション パターン

単一のトリガーが 1 つ以上のアクションに至ります

使用時期：シンプルな通知、データ同期、基本的なワークフロー

基本的なトリガー-アクション：

[Trigger] → [Action]
  例：New Email → Create Task

Zapier の例

Zap 名：「Gmail New Email → Todoist Task」

TRIGGER：Gmail - New Email
  - From：specific-sender@example.com
  - Has attachment：yes

ACTION：Todoist - Create Task
  - Project：Inbox
  - Content：{{Email Subject}}
  - Description：From：{{Email From}}
  - Due date：Tomorrow

Make の例

Scenario：「Gmail to Todoist」

[Gmail：Watch Emails] → [Todoist：Create a Task]

Gmail Module：
  - Folder：INBOX
  - From：specific-sender@example.com

Todoist Module：
  - Project ID：(ドロップダウンから選択)
  - Content：{{1.subject}}
  - Due String：tomorrow

ベストプラクティス：

• わかりやすい Zap/Scenario 名を使用する
• 実際のサンプルデータでテストする
• フィルターを使用して不要な実行を防ぐ

マルチステップ連続パターン

順序に従って実行されるアクションのチェーン

使用時期：マルチアプリワークフロー、データエンリッチメントパイプライン

マルチステップ連続：

[Trigger] → [Action 1] → [Action 2] → [Action 3]
各ステップの出力は後続ステップで利用可能

Zapier マルチステップ Zap

Zap：「New Lead → CRM → Slack → Email」

1. TRIGGER：Typeform - New Entry
   - Form：Lead Capture Form

2. ACTION：HubSpot - Create Contact
   - Email：{{Typeform Email}}
   - First Name：{{Typeform First Name}}
   - Lead Source：「Website Form」

3. ACTION：Slack - Send Channel Message
   - Channel：#sales-leads
   - Message：「New lead：{{Typeform Name}} from {{Typeform Company}}」

4. ACTION：Gmail - Send Email
   - To：{{Typeform Email}}
   - Subject：「Thanks for reaching out!」
   - Body：(パーソナライゼーション付きテンプレート)

Make シナリオ

[Typeform] → [HubSpot] → [Slack] → [Gmail]

- 各モジュールはデータを次へ渡す
- {{N.field}} を使用してモジュール N の出力を参照
- 重要なステップ間にエラーハンドラーを追加

条件付きブランチング パターン

条件に基づいて異なるアクション

使用時期：異なるデータタイプの異なる処理

条件付きブランチング：

              ┌→ [Action A] (条件満たし)
[Trigger] ───┤
              └→ [Action B] (条件未満たし)

Zapier Paths (Pro+ 必須)

Zap：「Route Support Tickets」

1. TRIGGER：Zendesk - New Ticket

2. PATH A：If priority = 「urgent」
   - Slack：Post to #urgent-support
   - PagerDuty：Create incident

3. PATH B：If priority = 「normal」
   - Slack：Post to #support
   - Asana：Create task

4. PATH C：Otherwise (キャッチオール)
   - Slack：Post to #support-overflow

Make Router

[Zendesk：Watch Tickets]
      ↓
[Router]
   ├── Route 1：priority = urgent
   │     └→ [Slack] → [PagerDuty]
   │
   ├── Route 2：priority = normal
   │     └→ [Slack] → [Asana]
   │
   └── Fallback route
         └→ [Slack：overflow]

# Make のビジュアルルーターは複雑なブランチングを明確にする

ベストプラクティス：

• 常に fallback/else パスを持つ
• 各パスを独立してテストする
• どの条件がどのパスをトリガーするか文書化する

データ変換パターン

アプリ間でデータをクリーンアップ、フォーマット、変換

使用時期：アプリが異なるデータ形式を期待する場合

データ変換：

Zapier Formatter

一般的な変換：

1. テキスト操作：
   - テキストを分割：「John Doe」→ First：「John」, Last：「Doe」
   - 大文字化：「john」→ 「John」
   - 置換：特殊文字を削除

2. 日付のフォーマット：
   - 変換：「2024-01-15」→ 「January 15, 2024」
   - 調整：7 日を日付に追加

3. 数値：
   - 通貨をフォーマット：1000 → 「$1,000.00」
   - スプレッドシート公式：=SUM(A1:A10)

4. ルックアップテーブル：
   - ステータスコードをマップ：「1」→ 「Active」, 「2」→ 「Pending」

Make データ関数

Make には強力な組み込み関数があります：

Text：
  {{lower(1.email)}}           # 小文字
  {{substring(1.name; 0; 10)}} # 最初の 10 文字
  {{replace(1.text; "-"; "")}} # ダッシュを削除

Arrays：
  {{first(1.items)}}           # 最初のアイテム
  {{length(1.items)}}          # アイテム数をカウント
  {{map(1.items; "id")}}       # フィールドを抽出

Dates：
  {{formatDate(1.date; "YYYY-MM-DD")}}
  {{addDays(now; 7)}}

Math：
  {{round(1.price * 0.8; 2)}}  # 20% 割引、小数第 2 位

ベストプラクティス：

• ワークフローの早い段階で変換する
• フィルターを使用して無効なデータをスキップする
• デバッグのために変換をログする

エラーハンドリング パターン

エラーの適切な処理

使用時期：あらゆる本番自動化

エラーハンドリング：

Zapier エラーハンドリング

1. 組み込みリトライ (自動)：
   - Zapier は失敗したアクションを自動的にリトライします
   - 一時的なエラーの場合、指数バックオフ

2. エラーハンドリングステップ：
   Zap：
     1. [Trigger]
     2. [失敗する可能性があるアクション]
     3. [Error Handler]
        - エラーの場合 → [Slack：Alert team]
        - エラーの場合 → [Email：Send report]

3. パスベースのハンドリング：
   [Action] → Path A：Success → [Continue]
            → Path B：Error → [Alert + Log]

Make エラーハンドラー

Make にはビジュアルエラーハンドリングがあります：

[Module] ──┬── Success → [Next Module]
           │
           └── Error → [Error Handler]

エラーハンドラータイプ：
1. Break：シナリオを停止、通知を送信
2. Rollback：完了した操作を元に戻す
3. Commit：部分的な結果を保存、続行
4. Ignore：エラーをスキップ、次のアイテムに続行

例：
[API Call] → Error Handler (Ignore)
           → [Log to Airtable：「Failed：{{error.message}}」]
           → シナリオを続行

ベストプラクティス：

• 外部 API 用にエラーハンドラーを常に追加する
• エラーをスプレッドシート/データベースにログする
• 重大な失敗に対して Slack/メールアラートをセットアップする
• 成功シナリオだけでなく、失敗シナリオもテストする

バッチ処理パターン

複数のアイテムを効率的に処理

使用時期：データのインポート、一括操作

バッチ処理：

Zapier ループ

Zap：「Process Order Items」

1. TRIGGER：Shopify - New Order
   - Returns：order with line_items array

2. LOOPING：line_items の各アイテムに対して
   - インベントリ調整を作成
   - 製品カウントを更新
   - スプレッドシートにログ

注：各ループイテレーションはタスクとしてカウントされます！
10 アイテム = 10 タスク消費

Make Iterator

[Webhook：Receive Order]
      ↓
[Iterator：line_items]
      ↓ (各アイテムを処理)
[Inventory：Adjust Stock]
      ↓
[Aggregator：Collect Results]
      ↓
[Slack：Summary Message]

Iterator は各アイテムごとに 1 つのバンドルを作成します。
Aggregator は結果を再び組み合わせます。
処理されたアイテムを収集するために Array Aggregator を使用します。

ベストプラクティス：

• Aggregator を使用して結果を組み合わせる
• バッチ制限を考慮 (一部の API は 100 に制限)
• コスト用の Operation/task カウントを監視する
• レート制限 API の遅延を追加

スケジュール自動化パターン

イベントの代わりに時間ベースのトリガー

使用時期：日次レポート、定期的な同期、バッチジョブ

スケジュール自動化：

Zapier スケジュールトリガー

Zap：「Daily Sales Report」

TRIGGER：Schedule by Zapier
  - Every：Day
  - Time：8:00 AM
  - Timezone：America/New_York

ACTIONS：
  1. Google Sheets：Get rows (昨日の売上)
  2. Formatter：Calculate totals
  3. Gmail：Send report to team

Make スケジュール済みシナリオ

Scenario Schedule オプション：
  - 1 回実行 (手動)
  - 定期的なインターバル (X 分ごと)
  - Advanced：Cron 式 (0 8 * * *)

[Scheduled Trigger：毎日午前 8 時]
      ↓
[Google Sheets：Search Rows]
      ↓
[Iterator：各行を処理]
      ↓
[Aggregator：合計を集計]
      ↓
[Gmail：Send Report]

ベストプラクティス：

• タイムゾーンの違いを考慮する
• 長時間実行ジョブのバッファ時間を追加する
• 監視用に実行時間をログする
• 真夜中ちょうどにスケジュール設定しない (ピーク時間)

危険な落とし穴

ドロップダウンフィールドでテキストの代わりに ID を使用

重要度：致命的

状況：アクションをドロップダウン選択で構成する

症状： 「Bad Request」エラー。「無効な値」メッセージ。正しく見えるにもかかわらずアクションが失敗。ドロップダウンから選択すると機能し、動的値では失敗。

これが原因で機能しなくなる理由： ドロップダウンメニューは人間が読める形式のテキストを表示しますが、ID を API に送信します。「Marketing Team」とテキストを入力する代わりに選択すると、Zapier はそのテキストを ID として送信しようとしますが、API はそれを認識しません。

推奨される修正：

ドロップダウンから選択する場合は常にドロップダウンを使用し、タイプしない

動的値が必要な場合：

Zapier アプローチ：

1. 最初に「Find」または「Search」アクションを追加

   • HubSpot：Find Contact → contact_id を返す
   • Slack：Find User by Email → user_id を返す

2. 後続のアクションで返された ID を使用

   • ドロップダウン：Use Custom Value を使用
   • 検索ステップから ID を選択

Make アプローチ：

1. 最初に Search モジュールを追加

   • Search Contacts：メールでフィルター
   • Returns：contact_id

2. ID を後続モジュールにマップ

   • Contact ID：{{2.id}} (検索モジュールから)

人々を困らせる一般的な ID フィールド：

• Slack、Teams のユーザー/メンバー ID
• CRM の連絡先/会社 ID
• プロジェクトツールのプロジェクト/フォルダー ID
• コンテンツシステムのカテゴリー/タグ ID

95% エラー率で Zap が自動無効化

重要度：致命的

状況：頻繁なエラーで Zap を実行する

症状： Zap が突然実行を停止します。自動無効化についてのメール通知。「This Zap was automatically turned off」メッセージ。データ同期が停止。

これが原因で機能しなくなる理由： Zapier は 7 日間で 95% 以上のエラー率を持つ Zap を自動的に無効にします。これにより、暴走状態の自動化の失敗がタスククォータを消費し、データの問題を作成するのを防ぎます。

推奨される修正：

予防：

1. エラーハンドリングステップを追加：

   • Path を使用：エラーの場合 → [Log + Alert]
   • 失敗に対する fallback アクションを追加

2. フィルターを使用して悪いデータを防ぐ：

   • メールが存在する場合のみ続行
   • 金額 > 0 の場合のみ続行
   • テスト/無効なエントリをフィルターする

3. タスク履歴を定期的に監視：

   • 繰り返しエラーを確認
   • 95% の閾値に達する前に問題を修正

リカバリー：

1. タスク履歴でエラーパターンを確認
2. 根本原因を修正 (認証、悪いデータ、API 変更)
3. サンプルデータでテスト
4. Zap を手動で再度有効化
5. 次の 24 時間、密接に監視

一般的な原因：

• 期限が切れた認証トークン
• API レート制限
• 接続されたアプリのフィールド名が変更
• 無効なデータ形式

ループが予期しないタスク数を消費

重要度：高

状況：配列または複数のアイテムを処理する

症状： タスククォータが予期せず枯渇。1 つの Zap 実行が 100+ タスクとして表示。月次制限が数日で到達。「You've used X of Y tasks」という驚き。

これが原因で機能しなくなる理由： Zapier では、ループの各イテレーションは別のタスクとしてカウントされます。ウェブフックが 50 個のラインアイテムで注文を配信し、各アイテムをループしている場合、これは 1 つの注文に対して 50 以上のタスクです。

推奨される修正：

数学を理解：

10 個のアイテム、アイテムあたり 5 つのアクションの注文： = 1 トリガー + (10 アイテム × 5 アクション) = 51 タスク

タスク使用量を削減する戦略：

1. 可能な場合、バッチ操作：

   • ループ + 作成の代わりに「Create Many Rows」を使用
   • バルク API エンドポイントを使用

2. 送信前に集計：

   • すべてのアイテムを収集
   • アイテムごとに 1 つではなく、1 つのサマリーメッセージを送信

3. ループする前にフィルター：

   • アクションが必要なアイテムのみを処理
   • 変更なし/重複アイテムをスキップ

4. 大量処理には Make を検討：

   • Make はアクションごとのタスクではなく、操作を使用
   • ループにはより費用効率的

Make アプローチ：

[Iterator] → [Actions] → [Aggregator]

• 操作 (モジュール実行) の支払い
• Zapier のようにアクションごとではない

アプリ更新が既存の Zap を破裂

重要度：高

状況：接続しているアプリがリリース更新

症状： 機能している Zap が突然失敗。「Field not found」エラー。出力の異なるデータ形式。昨日機能していたアクションが今日失敗。

これが原因で機能しなくなる理由： 接続されたアプリが API を更新するとき、フィールド名が変更できます、新しい必須フィールドが表示できます、またはデータ形式が変更できます。Zapier/Make 統合は API との変更にすぐに更新されない場合があります。

推奨される修正：

アプリ更新後に Zap が破裂するとき：

1. 具体的なエラーについてタスク履歴を確認
2. Zap エディターを開いてフィールドマッピングの問題を確認
3. トリガー/アクションを再度選択してスキーマをリフレッシュ
4. 「不明」として表示されるフィールドを再マップ
5. 新しいサンプルデータでテスト

予防：

1. 重要なアプリの changelog にサブスクライブ
2. 接続認可をリフレッシュに保つ
3. 主要なアプリ更新後に Zap をテスト
4. フィールドマッピングを文書化
5. 実験用にテスト/複製 Zap を使用

統合が古い場合：

• Zapier/Make ステータスページを確認
• サポートに問題を報告
• 一時的に webhook の代替案を検討

一般的な犯人：

• CRM フィールド再構成
• API バージョンアップグレード
• OAuth スコープ変更
• 新しい必須パーミッション

認証トークンの有効期限

重要度：高

状況：アプリへの OAuth 接続を使用する

症状： 「Authentication failed」エラー。「Please reconnect」メッセージ。週間機能した後に Zap が失敗。複数のアプリが同時に失敗。

これが原因で機能しなくなる理由： OAuth トークンは有効期限が切れます。一部のアプリでは 60～90 日ごとに再認証が必要です。アプリを接続したユーザーが会社を去った場合、その接続は機能しなくなる場合があります。

推奨される修正：

直ちに修正：

1. 設定 → アプリに移動
2. 問題のあるアプリを検索
3. 再接続 (再認可)
4. 影響を受けた Zap をテスト

予防：

1. サービスアカウントを接続に使用

   • 個人アカウントで接続しない
   • 共有チームメール/アカウントを使用

2. 接続の正常性を監視

   • Apps ページを定期的に確認
   • 既知の有効期限のカレンダーリマインダーを設定

3. 何が何を接続したかを文書化

   • スプレッドシートで追跡
   • 人々が去ったときのハンドオフプロセス

4. 有効期限が切れない接続を優先

   • OAuth が利用可能な場合は API キーを優先
   • 長期間のトークン

Zapier Enterprise：

• 接続の管理に関する管理者コントロール
• SSO 統合
• 一元化された接続管理

Webhook がイベントを欠落または重複

重要度：中

状況：webhook をトリガーとして使用する

症状： 一部のイベントが Zap をトリガーしません。同じイベントが複数回トリガーします。矛盾した自動化動作。「Works sometimes」。

これが原因で機能しなくなる理由： Webhook はファイアアンドフォーゲットです。Zapier の受信エンドポイントが遅いか利用不可の場合、webhook が失敗する場合があります。一部のシステムは webhook を再試行し、重複を引き起こします。ネットワークの問題はイベントを失います。

推奨される修正：

重複を処理：

1. 重複排除ロジックを追加：

   • フィルター：ID が Airtable に存在しない場合のみ続行
   • 最初のアクション：既に処理されている場合は確認

2. 冪等性を使用：

   • 処理された ID を保存
   • ID が存在する場合はスキップ

Zapier の例：

[Webhook Trigger] ↓ [Airtable：Find Records] - event_id で検索 ↓ [Filter：見つからない場合のみ続行] ↓ [Process Event] ↓ [Airtable：Create Record] - event_id を保存

欠落したイベントを処理：

1. 重要なデータにはポーリングトリガーを使用

   • リアルタイムではありませんが、より信頼できます
   • ダウンタイム中のイベントをキャッチします

2. 調整を実装：

   • スケジュール済み Zap でギャップをチェック
   • ソースデータと処理されたデータを比較

3. ソースシステムの再試行設定を確認：

   • 一部のシステムは失敗時に再試行
   • 再試行回数/タイミングを構成

Make Operations がエラー再試行によって消費

重要度：中

状況：失敗するモジュールを持つシナリオ

症状： Operations クォータが急速に枯渇。シナリオ実行が「succeeded」であるが、多くの操作を使用。同じシナリオが予想以上に実行。

これが原因で機能しなくなる理由： Make はモジュール実行ごとに操作をカウントします。これは失敗した試行と再試行を含みます。エラーハンドラーモジュールは操作を消費します。失敗して再試行するシナリオは、期待される 3～5 倍の操作を使用できます。

推奨される修正：

操作カウントを理解：

成功実行：各モジュール = 1 操作 失敗 + 再試行 (3x)：そのモジュールに対して 3 操作 エラーハンドラー：ハンドラーモジュールごとに追加操作

操作の無駄を削減：

1. エラーハンドラーを追加して早期に中断： [Module] → Error → [Break] (1 追加操作) 対 [Module] → Error → [Log] → [Alert] → [Update] (3+ 操作)

2. 必要に応じて無視を再試行の代わりに使用：

   • 失敗が予想される場合 (レコード存在)
   • 再試行が役に立たない場合 (悪いデータ)

3. 高価な操作の前に事前検証： [Check Data] → Filter → [API Call]

   • 高価な操作を消費する前に失敗

4. シナリオスケジューリングを最適化：

   • 毎分実行する必要がない場合は時間ごとに実行
   • 可能な場合は webhook ほど頻繁にポーリングしない

使用量を監視：

• Operations ダッシュボードを確認
• 使用量アラートをセットアップ
• 高消費シナリオを確認

スケジュール済みトリガーのタイムゾーン不一致

重要度：中

状況：スケジュール済み自動化をセットアップする

症状： Zap が誤った時間に実行されます。「9 AM」トリガーが午後 2 時に発火。異なる日の異なる動作。DST は時間シフトを引き起こします。

これが原因で機能しなくなる理由： Zapier は時刻をローカルタイムゾーンで表示しますが、UTC で保存する場合があります。タイムゾーンを変更するか DST が発生すると、スケジュール時刻がシフトします。異なるゾーンのチームメンバーは異なる時刻を見ます。

推奨される修正：

ベストプラクティス：

1. スケジュールのタイムゾーンを明示的に設定：

   • ブラウザー検出に依存しない
   • ビジネスタイムゾーンを使用、個人用ではない

2. Zap 名で文書化：

   • 「Daily Report 9AM EST」
   • 説明にタイムゾーンを含める

3. DST 遷移の周辺でテスト：

   • DST の境界でスケジュール変更
   • 変更前後の時刻を確認

4. グローバルチーム向け：

   • 標準として UTC を使用
   • 説明で現地時間に変換

5. バッファ時間を検討：

   • 正確に真夜中にスケジュール設定しない
   • 時間ごと (ピーク時間) に避ける

Make タイムゾーン処理：

• シナリオはアカウントタイムゾーン設定を使用
• formatDate() 関数がタイムゾーンを尊重
• parseDate() を明示的なタイムゾーンで使用

コラボレーション

委任トリガー

• 自動化にはカスタムコードが必要 -> workflow-automation (Inngest、Temporal などのコードベースのソリューション)
• ワークフローでブラウザー自動化が必要 -> browser-automation (Playwright/Puppeteer 統合)
• カスタム API 統合を構築 -> api-designer (API 設計と実装)
• 自動化が AI 機能を必要 -> agent-tool-builder (AI エージェントツールと Zapier MCP)
• 大量データ処理 -> backend (カスタムバックエンド処理)
• セルフホスト自動化が必要 -> devops (n8n またはカスタムワークフロー展開)

関連スキル

連携：workflow-automation、agent-tool-builder、backend、api-designer

使用時期

• ユーザーが言及または示唆：zapier
• ユーザーが言及または示唆：make
• ユーザーが言及または示唆：integromat
• ユーザーが言及または示唆：zap
• ユーザーが言及または示唆：scenario
• ユーザーが言及または示唆：ノーコード自動化
• ユーザーが言及または示唆：trigger action
• ユーザーが言及または示唆：ワークフロー自動化
• ユーザーが言及または示唆：アプリを接続
• ユーザーが言及または示唆：自動化

制限事項

• 上記のスコープに明確に一致するタスク場合にのみこのスキルを使用してください。
• 出力を環境固有の検証、テスト、または専門家のレビューの代わりとして扱わないでください。
• 必要な入力、パーミッション、安全性の境界、または成功基準が不足している場合は、停止して明確化を求めてください。