短縮リンク自動化: Make対IFTTT対n8n対Zapier

Elidoでの短縮リンク自動化については、予算内でビジュアルな多段階シナリオを組みたいならMake、スマートフォンやスマートホームのトリガーを使いたいならIFTTT、セルフホストしたい・コードでwebhook署名を検証したいならn8n、ほかのアプリがすでにZapier上にあるならZapierを選んでください。4つとも内部でやっていることは同じです。Elido APIに1回POSTを送り、返ってきたshort_urlをそのまま渡します。

このリクエストが共通しているからこそ、このページは短くて済みます。トリガーを決めるのはプラットフォーム側です。料金とエラーハンドリングもプラットフォーム側が決めます。しかし、リンクの見た目を決めるのはプラットフォームではありません。そこで以下では、共通のリクエストを一度だけ示し、各ツールについて実際の制約を1段落で説明し、比較表を載せ、各プラットフォームの完全なレシピ記事へのリンクを載せています。このページはツールにできないことを約束していた古いバージョンから書き直したもので、ここに書かれているすべての主張は、2026年9月時点でAPIまたはベンダー自身のページに照らして確認済みです。

APIそのものが初めての方は、URL短縮API・SDKクイックスタートでキーとドメインについて解説しています。このノーコードリンク自動化ガイドの内容は、そちらを読んでいることを前提としています。

すべてのツールが送る、たった1つのリクエスト

どのツールを選んでも、短縮リンクの作成は同じHTTP呼び出しです。POST https://api.elido.app/v1/workspaces/{workspace_id}/links。これはAuthorization: Bearer elido_...ヘッダーと、必須の2つのフィールドdomain_idとdestination_urlを持つJSONボディを伴います。オプションのフィールドにはslug、title、tagsがあります。

どのプラットフォームでも、つまずきやすいポイントが2つあります。

• レスポンスに完全なURLが含まれる。 Elidoが返すリンクレコードには、id、slug、destination_url、domain_idと並んでshort_url（例: https://b.elido.me/4Fr7Eq）が含まれます。カスタムドメインの場合は、GET /v1/workspaces/{workspace_id}/domainsを一度実行し、そのidをdomain_idとして送るために控えておいてください。
• 再試行による重複。 Idempotency-Keyヘッダーを送ってください。遷移先URLのハッシュなどで構いません。24時間以内の再送であれば、双子のリンクを新規作成する代わりに最初のレスポンスが再生されます。このウィンドウについてはレート制限と冪等性ガイドで説明しています。

キーはダッシュボードのAPI keysページから取得します。elido_で始まり、一度しか表示されないため、そのままツールの認証情報ストアに貼り付けてください。自動化ツールごとに専用のキーを発行しましょう。ひとつを失効させても、ほかには影響しません。リンクの作成にはEditor権限で十分です。最小権限のAPIキーガイドでは、webhook管理だけがadmin権限を必要とする理由を説明しています。

逆方向では、Elidoのwebhookがツール側に渡したURLへイベントをプッシュします。イベントはライフサイクル系のもので、link.created、link.updated、link.deleted、link.expired、link.cap_reachedに加え、ワークスペースとメンバーの変更が含まれます。現時点でクリックイベントはありません。クリックトリガーは公式の自動化アプリ向けに計画されていますが、それが実装されるまでは、クリック数は分析APIかダッシュボードから取得することになります。各配信はX-Webhook-Signature: v1=<hex>で署名されており、これは{timestamp}.{raw_body}に対するHMAC-SHA256です。この署名を検証できるかどうかが、各ツール間の大きな違いのひとつになります。

Make.com URL短縮: HTTPモジュールによるビジュアルシナリオ

Makeは、私がまずほとんどのマーケティングチームに勧めるツールです。Make向けの公式Elidoアプリは計画されており、ソースコードはすでに私たちのリポジトリに存在していますが、Makeのディレクトリにはまだ掲載されていないため、誰もインストールをクリックすることはできません。現時点では、MakeのHTTPアプリとHTTPアプリのMake a requestモジュールを使い、Bearerヘッダーを一度だけ保存するAPIキー認証情報を利用します。

Makeが得意とするのは、フローの中間部分です。ルーターが1件の新規リンクをSlackとスケジューラーに分岐させ、フィルターが空のシート行を400エラーの原因になる前に止め、リトライのエラーハンドラーがElidoが429を返したときに失敗したバンドルを後で処理できるよう保留します。受信イベントについては、JSONパススルー付きのCustom webhookが生のボディを保持し、Makeのsha256関数を使ったフィルターで署名を再計算できます。

落とし穴はクレジットです。モジュールが実行されるたびに1クレジットかかり、ポーリングトリガーは新しいものがなくても確認のたびに1クレジットかかります。そのため、15分間隔のSheetsウォッチャーは、ただ見ているだけで無料枠を消費してしまいます。Make.com URL短縮シナリオの記事では、私が実際に構築する3つのシナリオ、署名検証の具体的なフィルター、シナリオごとのクレジット表を紹介しています。

IFTTT短縮リンク: コンシューマー向けトリガー、有料のWebhook

IFTTTにもネイティブのElidoサービスはありません。IFTTTの汎用Webhooksサービスを通じて動作します。Make a web requestがElido APIを呼び出し、Receive a web requestがElidoにイベントを送るためのURLを提供します。

ここではプランがほぼすべてを決めます。2026年9月21日にIFTTTのプランページを確認したところ、Freeではアプレットが2つまでで、Webhooksはまったく使えませんでした。年払いで月額2.99ドル、月払いで4.99ドルのProはWebhooksを追加します。年払いで月額8.99ドル、月払いで14.99ドルのPro+は、JSON-responseクエリとフィルターコードを追加します。この区分は見た目以上に重要です。Proでは、作成の呼び出しは送りっぱなしです。リンクはElido上に存在しますが、アプレットはスラッグを一切見ません。

それでもなぜIFTTTを選ぶのか。ほかにはないトリガーがあるからです。スマートフォンのウィジェット、ある場所への到着、音声コマンド。やりたいことが「ボタンをタップして今夜の短縮リンクを取得する」であれば、これが正解です。ただし、重要な処理を行うアプレットにElidoのイベントを向けるのはやめてください。IFTTTは署名を検証できないため、あなたのMaker URLを知っている人であれば誰でも発火できてしまいます。IFTTT URL短縮アプレットガイドでは、スラッグを読み戻すフィルターコードを含め、3つのアプレットすべてを解説しています。

n8n短縮リンク: セルフホストによる制御と署名検証

データの保存場所が重要な場合、実行あたりの料金が気になる場合、あるいは単にフローの中に本物のコードを書きたい場合、n8nが選択肢になります。HTTP Requestノードは、クラウド版でもセルフホスト版でも、あらゆるn8nのエディションからElido APIに到達でき、Bearerキーを保持するHeader Auth認証情報を使います。

パッケージ化されたコミュニティノードn8n-nodes-elidoも存在します。現在はnpmで公開されており、2026年9月22日時点のバージョンは0.2.0です。LinkリソースでCreate、Get、List、Get Analyticsの各操作を利用できます。これを前提に計画を立てる前に、注意点が1つあります。n8n Cloudは検証済みのコミュニティノードしかインストールできず、これはまだ検証されていないため、セルフホストのn8nでのみ実行できます。n8nのコミュニティノードのインストールガイドでインストール方法を説明しています。Cloudでは、HTTP Requestが基準となる方法であり、いずれにせよそのノードが内部で呼び出すのもこの方法です。

イベント側でのn8nの強みはCodeノードです。WebhookノードでRaw Bodyを有効にし、HMACを再計算して、一致しないものを拒否します。4つのツールの中で、私が「本当に何かを変更するイベント」を任せて信頼できるのはn8nだけです。たとえば、ローンチ週の真っ最中にチーム全員が数字を見ている状況でキャンペーンを一時停止する、といった処理です。n8n URL短縮ノードの記事では、ノードとリトライに加え、コピーして使える3つのワークフローを紹介しています。自分でホストする場合は、n8nによるセルフホスト型リンク自動化がDocker Composeとリバースプロキシ、1台のワーカーでは足りなくなったときのキューモードまでを扱っています。

すでに理解している作業のために4つのツールから選ぶのに疲れましたか。無料のElidoワークスペースを開始し、ツールごとに1つずつキーを発行して、コミットする前に同じリクエストを2つのツールで並べて試してみてください。

Zapier URL短縮: 最大のカタログ、プレミアムWebhook

Zapierの魅力はそのアプリカタログです。フォームツールとCRMの両方がすでにZapier上にあるなら、Zapは「新しい行」から「どこかに短縮リンクを投稿する」までの最短経路になることが多いです。

まず知っておくべきことがあります。Zapier向けの公式Elidoアプリは計画されていますが、2026年9月に確認した時点では、Zapierの公開アプリディレクトリにはまだ掲載されていませんでした。掲載されるまでの確実な方法はWebhooks by Zapierで、Zapierはこれをプレミアムアプリとして扱っているため、有料のZapierプランが必要です。POSTステップは、ほかのツールと同じボディを送信し、後続のステップでは返ってきたshort_urlを使います。

この比較のためにZapierで署名検証を構築したことはありません。そのため、動作するとは主張しません。受信したElidoのイベントがレコードを変更するような用途であれば、私が実際にそれをやっているのを見たことがあるツールはn8nかMakeです。送信側のリンク作成については、Zapier URL短縮ウォークスルーで、マーケターが最初に手を伸ばすZapのパターンを、シートの行からSlackへの投稿まで紹介しています。

Make対IFTTT対n8n対Zapier、比較表

比較を1か所にまとめました。価格は変動します。各行は営業ページではなく、私が実際に確認した内容を示しています。

表の上に、さらに2つのルールがあります。ひとつ目はボリュームです。1日に数千本のリンクを作成するなら、これらのどれも適した居場所ではありません。Elido APIとSDKを使った短いスクリプトの方が安く、デバッグも簡単ですし、一度に大量のリストを貼り付ける作業にはGoogleスプレッドシートからの一括インポートが向いています。2つ目はクリックです。現時点でどのツールもクリックイベントを受け取れません。Elidoがまだそれを送信していないためです。クリック数については、日次で取得するようスケジュールするか、分析ダッシュボードを読んでください。実際にプッシュされる内容はリンクイベント向けwebhookの記事に一覧があります。

もし強制的にひとつだけ選べと言われたら、1〜5人規模のマーケティングチームにはMake、ワークフローのデータがどこにあるのかを誰かが気にし始めた時点でn8n、というのが私自身の基本方針です。マーケター向けソリューションページでは、チャネル横断でリンクを計測するための、より広いプレイブックをまとめています。

コーナーストーン記事を読む → URL短縮API・SDKクイックスタート

関連記事

• Make.com URL短縮シナリオ - 3つのシナリオ、署名付きwebhook、クレジットコスト。
• IFTTT URL短縮アプレット - Webhooksアプレット、フィルターコード、上限アラート。
• n8n URL短縮ノード - HTTP Requestのセットアップ、リトライ、コミュニティノード。
• n8nによるセルフホスト型リンク自動化 - Docker、リバースプロキシ、署名検証。
• Zapier URL短縮自動化 - マーケターが最初に組み立てるZap。
• リンクツール向けAPIキーの権限 - ロールごとの上限、ローテーション、自動化ツール用キー。