Make.com URL短縮: 3つのショートリンクシナリオ

Make.comのURL短縮は、1つのモジュール、HTTPのMake a requestで実行できます。Bearer APIキーとdomain_idおよびdestination_urlを含むJSONボディを使ってhttps://api.elido.app/v1/workspaces/{workspace_id}/linksにPOSTすると、Elidoは新しいリンクのslugを返します。そのslugをホスト名に結合すれば、ショートリンクの完成です。仕組みはこれだけで、すべてのMakeプランで動作します。

「make short link module」を検索する人は、通常、モジュールピッカーにブランド付きのElidoカードがあることを期待します。しかし、インストールできるものはまだありません。そこでこのガイドでは、Make独自のHTTPアプリを使います。以下では、リクエストそのもの、実際に運用したい3つのシナリオ、Make内で署名付きWebhookを検証する方法、各シナリオのクレジットコストを説明します。

Elido REST APIを初めて使いますか？まずはAPIとSDKのクイックスタートから始めてください。トークン、ワークスペース、ドメインについて説明しており、この記事ではそれらを理解しているものとして扱います。

現在MakeがElidoのショートリンクに提供しているもの

短く答えると、HTTPアプリです。Elidoの公開リポジトリには、Makeカスタムアプリのソースが実際に含まれており、接続、作成、更新、検索、分析の各モジュールと、リンクイベント用のトリガーがあります。しかし、Makeの公開アプリディレクトリには掲載されていません。読み込むには、自分のMake開発者アカウントに取り込んで、そこで保守する必要があります。

そのため、今は使わないことをおすすめします。HTTPモジュールならすべてのエンドポイントにアクセスでき、好きなヘッダーを設定でき、単なるリクエストなので双方の変更にも対応できます。掲載アプリが提供されたら、両方の方法が同じエンドポイントに同じボディと同じAPIキーでアクセスするため、下記のシナリオは同じデータ形式のまま移行できます。

ここでは標準のMakeアプリであるHTTP、Webhooks、JSON、Google Sheets、RSS、Slackを使います。プラットフォームを比較している場合は、n8nのURL短縮ガイドでn8n上の同じAPIを説明しています。ZapierのウォークスルーではZapierを扱っています。

Makeのショートリンクリクエストを構築する

最初のシナリオの前に、APIキー、ワークスペースID、ドメインIDの3つが必要です。

ElidoのダッシュボードでAPI keysからキーを作成します。キーはelido_で始まり、一度しか表示されないため、そのままMakeに貼り付けてください。HTTPモジュールでAPI keyの認証タイプを選び、Bearer elido_...をAuthorizationという名前のヘッダーに設定する認証情報を作成します。Makeはそれを再利用可能な認証情報として保存します。各モジュールにヘッダーを貼り付けるより、はるかに便利です。

ワークスペースIDはダッシュボードのURLにあります。ドメインIDを取得するには、Run onceを使って/v1/workspaces/{workspace_id}/domainsに一度だけGETを実行します。各アイテムにidとhostnameがあります。両方を控えておいてください。

次のようにMake a requestを設定します。

Module:             HTTP > Make a request
Authentication:     API key (header Authorization = Bearer elido_...)
URL:                https://api.elido.app/v1/workspaces/1/links
Method:             POST
Headers:            Idempotency-Key = {{sha256(1.url)}}
Body content type:  application/json
Body:               {
                      "domain_id": 7,
                      "destination_url": "{{1.url}}",
                      "title": "{{1.title}}",
                      "tags": ["make"]
                    }
Parse response:     Yes

レスポンスはリンクレコードで、id、slug、destination_url、domain_id、tags、タイムスタンプが含まれます。あらかじめ用意された完全なURLフィールドはないため、後続のモジュールで独自のホスト名を使い、https://go.example.com/{{2.data.slug}}のように組み立てます。slugを省略するとElidoが生成し、バニティ用の後半部分を指定したい場合は追加します。MakeのHTTPアプリのドキュメントには、リスト呼び出しのタイムアウトやカーソルページネーションなど、その他のオプションも掲載されています。

シナリオ1: Google Sheetsの行でURLを短縮する

ほとんどのチームはここから始めます。請求額に驚かされるのも、このシナリオです。計画用シートにurl列があり、新しい行ごとにショートリンクをD列へ書き込むものとします。

チェーンは3つのモジュールで構成します。Google SheetsのWatch New Rowsが、前回のチェック以降に追加された各行で起動します。上記のHTTPリクエストで、行のurlセルをdestination_urlにマッピングします。次にGoogle SheetsのUpdate a Rowが、トリガーから渡された行番号を使って、https://go.example.com/{{2.data.slug}}を同じ行に書き戻します。

重要な点は2つあります。空のurlを持つ行を止めるフィルターをトリガーとHTTPモジュールの間に置いてください。空白行は400の典型的な原因だからです。また、Idempotency-Keyは残してください。タイムアウト後にMakeが行を再試行しても、同じキーによって最初のリンクがリプレイされ、重複が作成されません。すべてのリンクにUTMパラメーターが必要ですか？先にSet variableステップで遷移先に組み込んでください。UTMトラッキングガイドに、長く使える命名規則があります。

3,000行を一度に貼り付けますか？Makeに1行ずつ通さないでください。それはクレジットがまったくかからないGoogle Sheetsからの一括インポートの仕事です。

シナリオ2: 新しいブログ記事をソーシャルスケジューラーへ送る

2つ目のシナリオは、フィードを予約投稿に変換します。RSSのWatch RSS feed itemsが、スケジュールに従ってブログフィードを確認します。HTTPモジュールがアイテムのリンクを短縮し、記事のタイトルをtitleにマッピングし、rssのようなタグを付けます。3つ目のモジュールはスケジューラーの投稿作成アクションです。例えばBufferなら、アイテムのタイトルとショートURLをテキストにします。

ここではルーターを追加するのがおすすめです。一方の分岐はスケジューラーへ進み、もう一方は同じショートリンクをSlackチャンネルに送り、公開前にチームが確認できるようにします。両方の分岐でHTTPモジュールからの1つのリンクを再利用するため、アイテムごとに作成呼び出し1回分だけを支払い、2回分にはなりません。

身をもって学んだことが1つあります。フィードは再公開されます。古い記事の日付を編集したCMSが、その記事をフィードに戻すことがあります。Idempotency-Keyがないと、シナリオは数か月前に共有した記事に新しいリンクを発行してしまいます。上の設定のようにアイテムURLをハッシュ化すると、24時間以内の再発行では元のレスポンスがリプレイされます。それより古い再発行には、URLをキーにしたデータストアのチェックが必要です。

毎週火曜日に人がスケジューラーへリンクを貼り付ける作業に費用をかけていますか？無料のElidoワークスペースを作成して、次のセクションを読む時間でこのフィードシナリオを接続できます。

シナリオ3: link.created WebhookをSlackへ送る

最初の2つのシナリオはリンクをElidoに送ります。こちらは受け取る側です。ダッシュボード、API、別のシナリオのいずれからでも、ワークスペース内で誰かがリンクを作成すると、Makeが監査チャンネルに投稿します。

まずWebhooks、Custom webhookの順に選び、Makeから提供されたURLをコピーします。ElidoでWebhooksを開き、そのURLのエンドポイントを追加して、link.createdにチェックを入れます。シークレットは一度だけ表示されます。保管しておいてください。

Custom webhookの詳細設定で、JSON pass throughとGet request headersをオンにします。Elidoはtimestamp.raw_bodyにHMAC-SHA256で署名し、結果をX-Webhook-Signature: v1=<hex>として、タイムスタンプをX-Webhook-Timestampに入れて送信するため、変更されていないボディが必要です。再シリアライズしたボディでは一致しません。Makeのsha256関数はキー引数を受け取りHMACを返すため、フィルターで検証できます。

Filter "signature ok" (after the Custom webhook):
  v1={{sha256(TS.RAW; hex; SECRET)}}   Text operators: Equal to   SIG

TS     = {{get(map(1.headers; "value"; "name"; "x-webhook-timestamp"); 1)}}
SIG    = {{get(map(1.headers; "value"; "name"; "x-webhook-signature"); 1)}}
RAW    = {{1.value}}   (the raw body JSON pass through hands you)
SECRET = the whsec_... secret, in a custom variable if your plan has them

フィルターの後で、JSONのParse JSONが生テキストをフィールドに変換し、SlackのCreate a Messageが{{3.data.slug}}と{{3.data.destination_url}}を投稿します。ペイロードにはtype、workspace_id、data（リンクレコード）、timestampが含まれます。

クリックイベントはありません。これはElido側で意図された仕様です。Webhookはリンクとワークスペースのライフサイクルを対象とし、トラフィックは対象としません。クリック数には、毎日実行するスケジュール済みシナリオが適しています。MakeのWebhooksアプリのドキュメントではCustom webhookの背後にあるキューを説明しており、リンクイベント用Webhookの記事ではペイロードと再試行について詳しく説明しています。

Makeのエラー処理とクレジットコスト

MakeのHTTPモジュールは、デフォルトで4xxまたは5xxをエラーとして扱います。これは望ましい動作です。次に何が起きるかは、どのエラーハンドラーを接続するかによって決まります。

ステータスコードに応じてハンドラーを割り当てます。

• 429または5xx: Retryを接続します。失敗したバンドルを未完了の実行として保留し、後で再試行するため、先にシナリオ設定でStore incomplete executionsを有効にしてください。MakeのRetryエラーハンドラーガイドで試行回数と間隔の設定を説明しています。Elidoはレート制限時にRetry-Afterを送信し、キーによるreplayにより、再試行された作成で重複が発生することはありません。
• 400、401、403、409: 再試行しません。400はdomain_idの欠落またはフォームエンコードされたボディ、401はキー、403は誤ったワークスペースID、409はカスタムslugが使用済みであることを意味します。これらはフォールバック値付きのResume、またはSkipとシートの担当者へのメールにルーティングします。

もう一方がクレジットです。Makeが課金単位を変更して以来、すべてのモジュール実行はバンドルごとに1クレジットかかり、ポーリングトリガーは何も見つからない場合でもチェックごとに1クレジットかかります。詳しくはMakeのoperationsリファレンスを参照してください。このアイドルコストが問題になります。

Makeの無料プランは月1,000クレジットです（2026年9月確認）。Sheetsウォッチャーを15分間隔で動かすと、見るだけでその約3倍を消費します。1時間間隔に延ばしてください。さらによいのは、ソースアプリが提供している場合はWebhookトリガーを使うことです。

そもそも、これはMakeで運用するのが適切でしょうか？マーケティング担当者が管理する少数のフローなら、私は適切だと思います。1日に数千件のリンクを作成するようになったら、Elido APIとSDKを使う短いスクリプトの方が安く、デバッグもしやすく、プッシュ側はElido Webhookで対応できます。レート制限と冪等性のガイドでは、全体で使っている24時間のリプレイウィンドウを説明しています。

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

ブログ内の関連記事

• n8nのURL短縮: HTTP Requestノードまたはコミュニティノード - n8nのクラウドまたはセルフホストから同じAPIを使います。
• ZapierのURL短縮自動化 - 同じ処理をZapierで行う方法です。
• リンクイベント用Webhook - ペイロード、署名、再試行の動作を説明します。
• Slackのリンク短縮ボットとアラート - Slack側に独自のアプリが必要な場合に使います。
• IFTTTのURL短縮アプレット - IFTTTのWebhookで、電話とフィードのトリガーから同じ処理を行います。