短縮URLの中には元のURLが入っている？

雑記Topに戻る

短い符号を、サーバーが元の行き先へ対応させる

一般的な短縮URLは、長いURLを短い文字列の中へ丸ごと圧縮して詰め込んだものではありません。短い識別子と移動先URLの対応をサービス側で管理し、アクセスが来ると本来の行き先へ案内します。利用者の端末は、短縮URLの文字列だけから元のURLを計算しているとは限りません。

仕組みをたとえるなら、長い住所そのものを極小の紙に書くより、住所録を引くための短い番号を配る方法に近いものです。ただし短縮サービスの実装は一種類ではありません。以下は、HTTPのリダイレクトと対応表を使う典型的な方式の説明です。

アクセスしたときの流れ

HTTPの3xx応答では、Locationという項目で移動先を伝える方法があります。301、302などの状態コードにはそれぞれ意味があり、キャッシュや要求方法の扱いも異なります。すべての短縮サービスが同じコードを使うと考える必要はありませんが、ブラウザーが「別の場所へ進むよう案内された」と理解すると流れを追えます。

短い文字列だけでは、元URLが分からないことがある

識別子が連番由来か、ランダムに作られたものか、ハッシュなどを利用するものかは実装次第です。見た目が英数字だからといって、ある進数で戻せば元の文章になるとは限りません。仮に番号へ戻せても、その番号とURLを結び付けた対応表がなければ行き先は分かりません。

短縮URLの長さにも限りがあり、同じサービス内で識別子が重ならないよう管理する必要があります。複数の短縮リンクが同じページを指すこともあります。元URLと短縮URLが、常に一対一の変換式で対応するわけではないのです。

同じ短縮URLの行き先が変わる場合もある

サービスによっては、短縮URLをそのまま残し、移動先だけを変更できます。例えばBitlyは、対応するプランでリンクの移動先を変更する機能を案内しています。印刷したQRコードや配布済みのリンクを変えずに、新しいページへ誘導できるのは便利な点です。

一方で、以前確認した行き先が将来も同じであるとは限らないことになります。短い文字列を保存しただけでは、確認時点の内容を保存したことにはなりません。引用や記録に使うなら、最終的なURL、ページ名、確認日などを併せて残す方が確かです。

短縮サービスが止まると、元サイトが生きていても届かない

対応表を持つサービスが停止したり、リンクが削除されたり、短縮用ドメインが使えなくなったりすると、その入口からは本来のページへ進めなくなる可能性があります。元のサイト自体の障害とは別に、途中の案内役にも依存しているためです。

長く使う資料では、短縮URLだけを唯一の手掛かりにせず、公式の通常URLや文書名も書いておくと探し直しやすくなります。反対に、アクセス解析や配布場所ごとの管理が目的なら、短縮URLの役割は単なる文字数の節約にとどまりません。どの情報が記録されるかは、各サービスの説明を確認します。

短いから安全、長いから危険とは判断できない

短縮URLでは行き先のドメインが見えにくくなります。心当たりのないログイン要求や支払い案内では、リンクをたどる代わりに、正規のアプリやブックマークから確認する方法があります。短縮リンクであることだけを理由に悪意があると決めつける必要はありませんが、表示された短い名前だけで信用するのも避けましょう。

展開やプレビューの機能もサービスによって異なります。確認用サイトへURLを入力すると、そのURLを第三者へ渡すことになるため、非公開の共有リンクやトークン付きURLを不用意に送らないことも大切です。仕組みを知った上で、送信元、移動先、何を求められているかを合わせて判断してください。

参考資料

• RFC 9110：HTTP Semantics、Locationとリダイレクト
• Bitly：リンクの移動先を変更する仕組み
• Bitly：リンクに関する問題と対処

資料確認日：2026年10月2日

雑記Topに戻る