Rebrandlyから移行：エクスポートからDNS切り替えまで

Rebrandlyから移行するには、3つのことを行います。Rebrandly APIでリンクを取り出し、Elidoで自分が管理するドメイン上に各slashtagを再作成し、そのドメインのDNSをElidoに向けます。ElidoにはRebrandlyインポーターが組み込まれており、対応するフィールド（slashtag、遷移先、タイトル、タグ）については最初の2つを処理します。DNSの切り替え、クリック履歴、ルーティングルールは自分で対応する必要があります。

人が意外に思うのはドメインの部分です。自分のホスト名上のリンクは、URLがそのまま保たれるので、訪問者が月曜日に受け取るリダイレクトは、金曜日に受け取ったものと同じです。rebrand.ly上のリンクは移せません。そのホストを所有していないからです。このガイドでは、エクスポート、マッピング、インポート、DNSの切り替え、301の維持、検証、ロールバック、分析で期待できることを、順を追って説明します。以下のElidoに関する内容はすべてインポーターのソースとダッシュボードで確認したもので、Rebrandlyに関する内容はすべて同社のヘルプセンターと開発者ドキュメント（accessed 2026-10-02）によるものです。

そもそも乗り換えるかどうかを検討している段階なら、まずElidoとRebrandlyの比較から始めてください。決めているなら、このまま読み進めてください。

Rebrandlyの移行の概要

詳細の前に計画を知りたい方のための、短いまとめです。

1. GET /v1/linksですべてのリンクをJSONLファイルにダンプし、監査用の記録として保管する。
2. ドメインごとに判断する。自分のホスト名はCNAMEの変更で移り、rebrand.lyのリンクは新しいURLになる。
3. Elidoに移行先ドメインを追加し、TXTの検証レコードを公開する。
4. スラッグを黙って変えてしまわない衝突ストラテジーで、インポーター（または一括API）を実行する。
5. CNAMEを切り替え、パブリックなリゾルバーから確認し、主要なリンクをテストする。
6. ロールバック用に、Rebrandlyを30日間そのまま稼働させておく。

数千件のリンクなら、インポートは数分で終わります。カレンダー上の時間は、DNSのTTL、テスト、そして30日間の並行運用に使います。

ステップ1：Rebrandlyからリンクをエクスポートする

RebrandlyはREST APIでリンクを公開しており、Elidoのものを含め、すべての移行ツールがこの経路を使います。GET /v1/linksは1ページ最大25件のリンクを返し、createdAtで並べ替えられ、domain.idまたはdomain.fullNameで絞り込めます。ページングはカーソル方式で、最後に受け取ったリンクのidをlastとして渡します（ページングのドキュメントのとおり）。

ファイルでの扱いはもう少し面倒です。Rebrandlyのリンクを新しいドメインに移す方法の記事には、組み込みの切り替え機能はないとあります。回避策は、APIでCSVにエクスポートし、ドメイン列を編集して再インポートすることです。インポートガイドは逆方向（1ファイル最大400,000件のCSV、独自ドメインが必須）を扱っています。したがってAPIを使い、自分用のコピーを保管してください。

# Dump every link to links.jsonl (25 per page, cursor = id of last link)
last=""
while :; do
  page=$(curl -s -H "apikey: $REBRANDLY_KEY" \
    "https://api.rebrandly.com/v1/links?limit=25&orderBy=createdAt&orderDir=asc${last:+&last=$last}")
  [ "$(echo "$page" | jq 'length')" -eq 0 ] && break
  echo "$page" | jq -c '.[]' >> links.jsonl
  last=$(echo "$page" | jq -r '.[-1].id')
done
wc -l links.jsonl

このファイルは件数の基準であり、元の作成日の出典であり、スクリプトによる修正の入力にもなります。落とし穴が1つあります。RebrandlyのAPIキーは、そのユーザーが所属するすべてのワークスペースのすべてのリンクを参照できます。クライアントのワークスペースを5つ持つ代理店は、通常1クライアントずつ移したいはずで、リスト取得の呼び出しもElidoのインポーターもワークスペースのフィルターを受け付けます。

各プランがどのクリックのフィールドを返すかは、公開ドキュメントからは確認できませんでした。過去の分析を誰かに約束する前に、自分のアカウントの実際のレコードを1件開いてください。

ステップ2：何が移るかを決める - rebrand.lyと自分のドメイン

移るのはパスで、ホストが移るのは自分のものである場合だけです。go.acme.com/summerのようなリンクは、切り替え後もそのまま動作し続けられます。rebrand.ly/summerは無理です。そのホスト名はRebrandlyのものであり、アカウントがある限り同社のサービス経由で解決され続けるからです。ほとんどのアカウントは次の3つのケースに当てはまります。

• 自分のドメインで、DNSを自分で管理している。 最良のケースです。Elidoの同じホスト名ですべてのslashtagを再作成してから、DNSを向け直します。印刷済みのQRコード、メールのアーカイブ、プロフィールのリンクは動作し続けます。
• Rebrandly経由で購入したドメイン。 Rebrandlyのヘルプ記事には、Transfer outを使ってメールでコードを請求するとあり、ほとんどのドメインは登録後60日間のロックがかかるとも書かれています。この期間は早めに開始し、CNAMEの変更をより安全な最初の手として扱ってください。
• 無料のrebrand.lyドメイン。 slashtagは新しいホストに引き継げますが、古いURLはRebrandlyに残ります。それらが印刷物に載っている場合は、その資料が出回っている間、アカウントを有効にしておいてください。

新しいホスト名については、短縮リンクの独自ドメインをご覧ください。

ステップ3：Rebrandlyのフィールド、タグ、ワークスペースをElidoに対応付ける

インポーターは意図的に絞られています。Rebrandlyのリンクごとに4つ（slashtag、遷移先、タイトル、タグ）を読み取り、選んだドメイン上のElidoのリンクに書き込み、タグを1つ追加します。それ以外は、自前のスクリプトか手作業が必要です。

作成日はもう一度確認する価値があります。一括エンドポイント（POST /v1/workspaces/{id}/links/bulk、1リクエスト100件）が受け取るのはスラッグ、遷移先、タイトル、タグだけなので、インポートされたリンクはインポート日の順に並びます。Dubのインポーターは作成日を保持するため、元の日付がレポートに必要なら、JSONLファイルを保管しておいてください。ダッシュボードのフォームに表示されるのはキー、移行先ドメイン、衝突ストラテジーだけです。ワークスペースのフィルターは現状ではAPI経由で動作し、ダッシュボードの入力欄は計画中です。

Elidoにはフォルダーがありますが、インポーターはそれを作成しません。構造は自前の前処理でタグ（client:acme、campaign:summer）として引き継ぐか、後からimported:rebrandlyで絞り込んでタグの一括編集を使ってください。RebrandlyのUTMテンプレートにはきれいなエクスポートがないため、キャンペーンルールとして再構築し、ばらばらな命名はUTM命名規則で整えてください。インポートされたリンクにはElidoのデフォルトのQRコードが付きます。カスタムのQRデザインは再適用が必要です。

ステップ4：ElidoのRebrandlyインポーターを実行する

インポーターは、Integrations、続いてRebrandly to Elidoにあります（POST /v1/workspaces/{id}/imports/rebrandlyでも利用できます）。先にワークスペースに移行先ドメインを追加しておくと、選択欄に表示されます。

1. Rebrandlyの「Account」から「API」でキーを作成します。ジョブに必要なのは読み取り権限だけです。
2. キーをフォームに貼り付けます。Elidoは実行中だけプロセスのメモリに保持し、その後は破棄します。ジョブの記録には書き込まれません。
3. 移行先ドメインを選びます。キーが参照できるすべてのリンクがこの1つのドメインに入り、ドメインごとのフィルターはないため、複数のRebrandlyドメインがあってslashtagが重複しているアカウントでは衝突します。
4. 衝突ストラテジーを選んでジョブを開始します。ページは2秒ごとにポーリングし、閉じても構いません。

Rebrandlyは1ページ25件に制限されており、Bitlyは100件を返すため、同じアカウントでもRebrandlyからのほうが時間がかかり、ボトルネックはベンダー側にあります。5,000件の場合、当社のエンジニアリングの見積もりは6〜10分です。ワーカーはページが空で返ってくるまでlastカーソルをたどり、1ジョブを50,000件までに制限し、30分で打ち切ります。スキップされた行と失敗した行は、ジョブのエラーログ（先頭1,000件）に記録されます。

衝突ストラテジーは開始時に3つから選びます。suffix（デフォルト）はmylink-2、mylink-3と順に最大50候補まで試し、それでもだめならエラーを報告します。skipは既存のElidoのリンクに手を付けず、その行をログに記録します。failは最初の衝突でジョブを中止します。suffixが付いたスラッグは問題としてログに残りませんが、URLは変わっています。そのため、同じドメインでの引き継ぎでは、空の移行先ドメインに対してskipかfailを使い、スキップまたは失敗の件数が0でなければ対応すべき作業として扱ってください。

さらに細かく制御したい場合は、JSONLを一括エンドポイントに渡してください。行ごとに成功かエラーが報告されます。ElidoのAPIとSDKも同じスラッグと遷移先のペアを受け付けます。先に試したい方は、Elidoのワークスペースを作成して、余っているドメインにインポーターを向けてください。Rebrandly移行ページには、引き継がれるものと残されるものの同じ一覧があります。

ステップ5：DNSの切り替えと301の維持

順序が重要です。Elidoは2つのDNSレコードでドメインを検証し、実際のトラフィックが切り替わるのは2つ目のレコードが変わったときだけだからです。1つ目は_elido-verify.<hostname>のTXTレコードで、値はverify=<token>です。2つ目はホスト名からElidoのエッジのターゲット（デフォルトはedge.elido.me）へのCNAMEです。独自ドメインの機能ページをご覧ください。

1. 2日前に、現在のCNAMEのTTLを300秒に下げ、Elidoにドメインを追加してTXTレコードを公開します。実際のトラフィックには影響しません。
2. そのドメインにインポーターを実行し、インポート数をwc -l links.jsonlと比較します。
3. 切り替えの時間帯に、CNAMEをElidoのエッジのターゲットに変更します。Elidoは両方のレコードをポーリングして証明書を発行します。詳しくは5分で設定する独自ドメインのTLSにあります。
4. 少なくとも2つのパブリックなリゾルバーに問い合わせます（dig @8.8.8.8 go.acme.com CNAME、続いて@1.1.1.1）。手元のマシンで確認できるのは、自分のキャッシュだけだからです。
5. Rebrandlyには手を付けないでください。ドメインもアカウントもまだ削除しません。

Rebrandlyのリンクを作成しているZapier、Make、スクリプトの向き先を変えるのは、インポートを確認してからにしてください。

自分のドメインでは、ホスト名とパスが同一なので、同じURLがそのままElidoから応答するようになります。守るべきはリダイレクトの種類です。Rebrandlyのリンクが恒久的だったなら恒久的なままにしてください。長く使われているリンクを一時的なものに切り替えると、検索エンジンやキャッシュの扱いが変わるからです（301と302のリダイレクト）。ホスト自体が変わる場合は、古いものから新しいものへの301がユーザーを導き、RFC 9110セクション15.4.2はクライアントが保存済みの参照を更新してよいと定めていますが、それには古いホスト名が必要で、rebrand.lyでは自分で管理できません。

ステップ6：移行を検証する

ジョブ画面が緑だというだけで移行を告知しないでください。インポート数とスキップ数と失敗数の合計が、JSONLの行数（置いていくドメインを除く）と一致していること、スキップと失敗が0であるか、各ログの項目に説明がつくこと、Rebrandlyにはなかった-2のsuffixがスラッグに付いていないことを確認します。リンク一覧をimported:rebrandlyで絞り込んで目を通してください。その後、上位100件のリンクのLocationヘッダーを、JSONLの遷移先と比較します。

while read -r slug dest; do
  got=$(curl -s -o /dev/null -w "%{redirect_url}" "https://go.acme.com/$slug")
  [ "$got" = "$dest" ] || echo "MISMATCH $slug -> $got (expected $dest)"
done < top100.tsv

すべての特殊なスラッグまでは試していないため、大文字小文字が混在するslashtagや特殊文字は手作業で抜き取り確認してください。印刷済みのQRコードを1つ、モバイル回線でスマートフォンからスキャンしてください。リンクを壊さずBitlyから移行する方法にはより厳格な失敗パターンの一覧があり、TinyURLからの移行ガイドは別の移行元での進め方を示しています。

ステップ7：ロールバック、分析、切り替えるべきでない場合

本当のロールバックは、まだ稼働している元の環境です。Rebrandlyがドメインとリンクを保持している間は、元に戻すのはCNAMEを以前のターゲットに戻す1行の変更で、TTLが300秒なら大半の訪問者は数分で追随します。Elido内では、imported:rebrandlyタグが取り消しの手がかりです。バッチを絞り込んでタグを付け替え、移動または削除し、再インポートします。再実行はskipなら安全です。suffixでは-2のコピーが作られるため、2回目はskipを使ってください。

ワーカーはElidoのアプリケーション内で動くため、インポートの途中でデプロイやクラッシュが起きると停止します。5分ごとのスイープが、30分間進捗のないジョブを、理由付きで失敗に切り替えます。現時点では、保存されたカーソルはありません。ジョブを再起動します。Rebrandlyの最後のカーソルからの再開は計画中で、およそ1万件を超える規模で特に役立ちます。

クリック履歴はRebrandlyに残るため、ダウングレードする前に必要なレポートをエクスポートし、切り替えの時刻を控えてください。新しいクリックは、CNAMEがElidoに解決された瞬間からElidoに記録されます。リゾルバーがキャッシュしたレコードを破棄する速度はまちまちなので、両方のダッシュボードが数える短い重複期間があります。アクセスの多いリンクが1時間経っても何も表示されない場合は、ダッシュボードを疑う前にcurlのループを実行してください。キャンペーンの系列を途切れさせないためには、UTMをエンドツーエンドで追跡するをご覧ください。静かな30日が過ぎたら、Rebrandlyをダウングレードするか閉じてください。

インポーターは、デバイスや地域によるルーティングルール、UTMテンプレート、QRのスタイルを再構築しません。チームメンバーの情報も移りません。DubのRebrandlyインポーターも同様にデバイスと地域のターゲティングをスキップするため、Elido固有ではなく一般的な制約です。設定がルーティングルールやQRのブランディングに依存しているなら、最初の1か月は両方の製品を並行して運用してください。Rebrandlyの比較ページとRebrandlyの代替サービスで、料金と機能を比較しています。

ブログの関連記事

• ElidoとRebrandlyの比較：2026年の料金、EUデータ所在地、ブランドリンク
• Rebrandlyの代替サービス：ランキング上位9つのブランドリンクツール
• BitlyとRebrandlyの比較：ブランドリンク、料金、向き不向き
• Bitly移行プレイブック：棚卸しから30日間の監視まで
• ブランド短縮リンクの設定：ドメインを選んで、午後のうちに公開