Makeとは？
Make（旧Integromat）は、世界をリードする高度なビジュアル自動化プラットフォームで、パワーユーザー、開発者、および単純な「これが起きたら、あれをする」シナリオを超えた高度なワークフロー自動化を必要とする企業向けに設計されています。2022年にCelonisに買収され、IntegromatからMakeへとリブランドされたこのプラットフォームは、複雑な自動化ニーズのためのソリューションとなりました。
主要機能：
- ビジュアルワークフロービルダー: 完全なデータフローを表示する直感的なドラッグアンドドロップインターフェースで複雑な自動化シナリオを設計
- 高度なロジックとルーティング: 条件分岐、イテレーター、アグリゲーター、ルーターを実装して複雑なビジネスルールを処理
- データ変換: 異なる形式（JSON、XML、CSV、テキスト）間でデータを解析、フォーマット、変換するための組み込みツール
- エラー処理: ロールバック、再試行ロジック、代替実行パスを持つ高度なエラー回復
- HTTPとAPI連携: 高度なリクエスト構築、認証、レスポンス解析を備えたネイティブHTTPモジュール
- リアルタイム実行: リアルタイムワークフロー実行のための即座トリガーとウェブフック
- スケジューリングとタイミング: cron式、遅延、スリープ機能による柔軟なスケジューリング
- データストレージ: 一時ストレージとシナリオ間データ共有のための組み込みデータストア
パワーユーザーがZapierよりMakeを選ぶ理由：
Makeは、Zapierのようなシンプルな自動化ツールとは根本的に異なります。Zapierは直線的な単一ステップの自動化に優れていますが、Makeは複雑さのために構築されています：
- ビジュアルデータフロー: データがワークフローを通してどのように移動するかをビジュアルマップで正確に確認でき、デバッグと最適化が直感的
- 無制限の分岐: 人為的な制限なしで必要なだけ多くの条件パスを作成
- 高度な操作: イテレーターを使用して配列を処理し、アグリゲーターを使用してデータを結合し、ルーターを使用して実行パスを分割
- 優れた価格設定: Makeの操作ベースの価格設定は、高ボリュームワークフローの場合、通常Zapierより40〜60%安い
- 詳細な制御: 強力なマッピングインターフェースで個々のデータポイントにアクセスして操作
- 「Zap」制限なし: すべての有料プランで無制限のアクティブシナリオを実行（ZapierはプランごとにアクティブなZapを制限）
一般的な使用例：
- 条件ルーティングを持つ複雑な多段階メール検証ワークフロー
- CRMデータエンリッチメントと検証パイプライン
- 不正検出を伴う電子商取引注文処理
- 複数のデータソースを持つリードスコアリングシステム
- 自動化されたデータ移行と同期
- SaaS統合のためのAPIワークフローオーケストレーション
- エラー処理を伴う大規模データセットのバッチ処理
Makeを使用する人々：
- 複雑なリードルーティングが必要なマーケティング自動化スペシャリスト
- 顧客オンボーディングワークフローを構築するSaaS企業
- 高度な注文検証を持つ電子商取引ビジネス
- ETL（抽出、変換、読み込み）プロセスを自動化するデータチーム
- コーディングなしでビジュアル自動化を望む開発者
- 複雑なクライアントワークフローを管理する代理店
しかし、最も洗練された自動化ワークフローでさえ、データ品質に依存します。無効なメールアドレスは複雑なシナリオでカスケード障害を引き起こす可能性があります。これが、メール検証サービスをMakeと統合することで、ワークフローが最初からクリーンで検証されたデータで動作することを確保する理由です。
なぜBillionVerifyをMakeと統合するのか？
Makeの力は、複雑なワークフローをオーケストレートする能力にありますが、それらのワークフローは、それらを通って流れるデータと同じくらい信頼性があります。メール検証は、複数のダウンストリームプロセスに影響を与える重要なコンポーネントです：
メール検証なしで、深刻な問題に遭遇します：
- ❌ ワークフロー障害: 無効なメールは跳ね返りを引き起こし、自動化されたメールシーケンスと顧客ジャーニーを壊します
- ❌ データ品質の問題: 悪いデータは複数のシステムを通じて伝播し、データエコシステム全体を破損します
- ❌ 無駄な操作: Makeは操作ごとに課金します - 無効なメールは操作を無駄にし、コストを膨らませます
- ❌ 複雑なデバッグ: 多段階ワークフローで無効なメールによって引き起こされた障害を追跡するのは時間がかかります
- ❌ 低いROI: ダウンストリームマーケティング自動化、CRM更新、メールキャンペーンはすべて未検証データから苦しみます
ソリューション
BillionVerify + Make統合により、次のことが可能になります：
- ✅ ルーティング前に検証: データが高価なダウンストリームシステムに流れる前に、エントリーポイントでメールを検証
- ✅ 条件ロジック: 有効、無効、リスクのあるメールを異なる処理パスに自動的にルーティング
- ✅ バッチ検証: Makeのイテレーターとアグリゲーターモジュールで大規模なデータセットを効率的に処理
- ✅ リアルタイム検証: リアルタイムアプリケーションのためのウェブフックトリガーシナリオでメールを即座に検証
- ✅ エラー防止: 複雑なワークフローでカスケード障害を防ぐために早期に無効なメールをキャッチ
- ✅ コスト最適化: すべてのMakeシナリオで無効な連絡先に対する操作の無駄を避ける
仕組み
統合はMakeで次のワークフローアーキテクチャに従います：
- データエントリ: メールがMakeシナリオに入る（ウェブフック、API、フォーム送信、またはスケジュール経由）
- BillionVerifyモジュール: Makeが検証のためにBillionVerify APIにメールを送信
- 包括的な検証: 当社のAPIは多層チェックを実行：
- 構文検証（RFC 5322準拠）
- DNS検索（ドメインが存在し、設定されている）
- MXレコード検証（メールサーバーが存在する）
- SMTPハンドシェイク（メールボックスが存在し、メールを受け入れる）
- 高度なリスク検出（使い捨て、Catch-All、ロールベース、不正パターン）
- データエンリッチメント: BillionVerifyはリスクスコアを持つ詳細な検証結果を返します
- インテリジェントルーティング: Makeのルーターモジュールは検証結果に基づいて実行を分割：
- ✅ 有効なメール（低リスク）: CRM、メールマーケティング、またはメインワークフローにルーティング
- ❌ 無効なメール: 拒否パス、ログ記録、または抑制リストにルーティング
- ⚠️ リスクのあるメール: 手動レビューキュー、代替検証、またはスコアリングシステムにルーティング
- ダウンストリーム処理: 各パスは適切なアクションで続行（CRM更新、ウェルカムメール送信、レビューのためのフラグ付けなど）
このアーキテクチャは、クリーンなデータが自動化エコシステム全体を通って流れることを保証します。
統合方法
方法1: MakeネイティブHTTPモジュール（推奨）
Makeの組み込みHTTPモジュールを使用して、完全な制御と柔軟性でBillionVerify APIに直接接続します。
前提条件
- BillionVerify APIキー（こちらで取得）
- Makeアカウント（無料または有料プラン）
- Makeシナリオとモジュールの基本的な理解
アーキテクチャ概要
Makeトリガー（ウェブフック/スケジュール/フォーム）
↓
BillionVerify HTTPモジュール（POSTリクエスト）
↓
ルーターモジュール（条件分岐）
├─ 有効な分岐 → CRM更新 / メール送信
├─ 無効な分岐 → 抑制リスト / ログ
└─ リスクのある分岐 → 手動レビューキュー
セットアップ手順
ステップ1: 新しいシナリオを作成
- Makeにログイン（make.com）
- 「新しいシナリオを作成」をクリック
- トリガーモジュールを追加（例：ウェブフック、Googleスプレッドシート、Airtableなど）
ステップ2: BillionVerify HTTPモジュールを追加
- 「+」ボタンをクリックして新しいモジュールを追加
- 「HTTP」を検索し、「HTTP > リクエストを作成」を選択
- HTTPモジュールを設定：
- URL:
https://api.billionverify.com/v1/verify - メソッド:
POST - ヘッダー:
Authorization:Bearer YOUR_BILLIONVERIFY_API_KEYContent-Type:application/json
- ボディタイプ:
Raw - リクエストコンテンツ:
{ "email": "{{trigger.email}}" } - レスポンスを解析:
はい（レスポンスデータにアクセスするために有効にする）
- URL:
ステップ3: 条件ロジックのためのルーターを追加
HTTPモジュールの後にルーターモジュールを追加
フィルター付きの3つのルートを作成：
ルート1: 有効なメール
- フィルター条件:
{{BillionVerify.status}}がvalidに等しく、{{BillionVerify.risk_level}}がlowに等しい - アクション: CRMに追加、ウェルカムメール送信など
ルート2: 無効なメール
- フィルター条件:
{{BillionVerify.status}}がinvalidに等しい - アクション: 抑制リストに追加、スプレッドシートに記録、アラート送信
ルート3: リスクのあるメール
- フィルター条件:
{{BillionVerify.risk_level}}がmediumまたはhighに等しい - アクション: 手動レビューキューに追加、検証チームに送信
- フィルター条件:
ステップ4: レスポンスデータをマッピング
BillionVerifyは、ダウンストリームモジュールで使用できる詳細情報を返します：
{
"email": "user@example.com",
"status": "valid",
"risk_level": "low",
"is_disposable": false,
"is_catch_all": false,
"is_role_account": false,
"mx_records": [...],
"smtp_response": "250 OK",
"verification_date": "2025-11-23T10:30:00Z"
}
これらのフィールドをCRM、データベース、または他のシステムにマッピングします。
ステップ5: テストとアクティベート
- 「1回実行」をクリックしてサンプルデータでテスト
- ルーティングロジックが正しく動作することを確認
- 有効、無効、リスクのあるメールが正しいパスに流れることを確認
- シナリオを自動実行するためにアクティベート
方法2: イテレーターによる一括検証
メールのリスト（CSVアップロード、データベースエクスポート、CRM一括更新）を含むシナリオの場合、バッチ処理のためにMakeのイテレーターモジュールを使用します。
セットアップ手順
ステップ1: データソースを追加
- メールの配列を提供するトリガーを追加（Googleスプレッドシート、Airtable、CSVパーサーなど）
ステップ2: イテレーターモジュールを追加
- 「ツール > イテレーター」モジュールを追加
- データソースからのメールの配列をマッピング
- イテレーターは各メールを個別に処理します
ステップ3: BillionVerify HTTPモジュールを追加
- イテレーターループ内に「HTTP > リクエストを作成」を追加
- 方法1と同じ方法で設定しますが、メール値として
{{iterator.email}}を使用
ステップ4: アグリゲーターを追加（オプション）
- 検証後、「ツール > 配列アグリゲーター」を追加してすべての結果を収集
- ステータス（有効/無効/リスク）ごとに検証済みメールをグループ化
- スプレッドシート、データベース、またはCRMに出力
ステップ5: レート制限（重要）
APIを圧倒しないように、小さな遅延を追加：
- HTTPリクエスト後に「ツール > スリープ」モジュールを追加
- 遅延を
0.1秒（100ms）に設定してAPIレート制限内に収まるようにする
方法3: ウェブフックトリガーリアルタイム検証
リアルタイム検証（フォーム送信、サインアップフロー、リードキャプチャ）の場合、Makeのウェブフックトリガーを使用します。
セットアップ手順
ステップ1: ウェブフックトリガーを作成
- トリガーとして「ウェブフック > カスタムウェブフック」を追加
- Makeが提供するウェブフックURLをコピー
ステップ2: フォーム/アプリケーションを設定
フォーム送信またはアプリケーションをMakeウェブフックURLにデータを送信するように設定：
// 例: MakeウェブフックへのフォームHuman: 翻訳を続けてください。現在のファイル（make.mdoc）を完成させてから、次のファイル（pipedrive.mdoc）に進んでください。