かつて、URL短縮サービスのセルフホストは週末のプロジェクトでした。PHPとMySQL、リダイレクトコントローラーさえあれば、2010年頃のBitlyのようなものが作れました。しかし、このカテゴリーは進化を続けており、現代のオープンソースの選択肢はYOURLSよりも高性能である一方、週末のプロジェクトよりも運用負荷が高くなっています。さらに、分析機能の面ではマネージドサービスに依然として大きな差をつけられています。この記事では、各オープンソースの選択肢が実際に何を提供し、マネージドベンダーと比較して何を諦める必要があるのか、そして、いつ自分自身でリダイレクト層を運用するのをやめて、コストを払って他社に任せるべきかという判断基準について、率直に解説します。
この記事は、セルフホストを検討しているエンジニアチームやテクニカルオペレーターを対象としています。より広範な比較についてはbitlyの代替サービスに関する記事をご覧ください。また、サードパーティの代替サービスではなく、Elido自体をセルフホストしたい場合は、Elidoのk3s環境へのセルフホスト・プレイブックを参照してください。
運用することになる範囲#
URL短縮サービスは、一見すると小さなシステムに見えます。データベース、リダイレクト処理、リンク管理用のダッシュボード。しかし、本番環境においてこの単純な構成は、4つの運用面を隠しています。
リダイレクト層： これは最も重要なホットパスです。インターネット上のどこかでクリックされた短縮URLは、最終的にすべてこのコードを通過します。ユーザー体験を重視するならば（p95で15ms以下という）高速性が求められ、また、出荷したすべてのリンクを機能させるためには高い可用性が必須となります。ユーザーが特定の地域に限定されない場合は、地理的な分散も必要です。リダイレクトのp95を15ms以下にするための記事では、高速なレスポンスの実現方法について詳しく解説しています。
クリック分析パイプライン： クリックイベントの記録、保存、クエリ機能です。トラフィック量が増えると、リダイレクト層とは別のシステムが必要になります。通常は取り込みにKafkaやRedpanda、保存にClickHouseやBigQuery、クエリ用に別APIが必要です。多くのオープンソース短縮サービスはこれらを省略し、リンクを保持する同じリレーショナルデータベースにクリック情報を保存します。これは小規模な環境では機能しますが、月間数百万クリックを超えると破綻します。
ダッシュボード： リンクの作成、編集、整理、分析を行うためのUIです。多くのオープンソースプロジェクトがこの機能開発に注力しており、マネージド製品との差が最も小さい部分でもあります。
カスタムドメインの仕組み： TLS発行、DNS検証、証明書の更新、新しいドメインがクラスターに向けられた際のオンデマンド証明書プロビジョニングです。これは運用コストが最も増大する部分であり、ACMEを大規模に運用するのは非常に困難です。
セルフホスト環境では、これら4つのすべての層を運用する必要があります。マネージド製品を利用する場合、これらの運用はベンダーが行います（その代わり、費用を支払い、ベンダーのデータ所在地ポリシーを受け入れる必要があります）。どちらのトレードオフが貴社の状況に適しているかを見極めることが重要です。
現在のオープンソースの選択肢#
2026年5月22日時点で活動が見られる、検討に値する5つのプロジェクトです。
YOURLS#
この分野のパイオニアです。PHP、MySQL、単一サーバー、プラグインアーキテクチャを採用しています。YOURLSは2009年から存在し、オープンソース短縮サービスの中で最も広く導入されています。強みは、インストールが簡単でPHPが動作する場所ならどこでも動き、プラグインエコシステムが成熟している点です。弱みとしては、分析機能が最小限（リンクごとのクリック数のみ、地理情報は外部サービス経由）であること、複数インスタンスを動かす以外に標準的なカスタムドメイン機能がないこと、APIレート制限がないこと、チームやロールの概念がないことが挙げられます。
YOURLSは、個人的な利用や、小規模なトラフィックで単一の管理者が運用するツールとしては適しています。チームでの利用、クライアント用のカスタムドメイン、長期保存が必要な分析機能が必要な場合には適していません。ElidoとYOURLSの比較記事で、機能のギャップについて詳しく解説しています。
Shlink#
PHPベースですが、よりモダンな設計です。Shlinkは、REST API、マルチドメインサポート、別UIのウェブダッシュボード、Mercureベースのリアルタイム更新機能を備えています。分析機能はYOURLSよりも高性能で、訪問ごとの地理情報、デバイス情報、時系列データを確認できますが、リンクと同じMySQL/Postgresデータベースに保存されます。Shlinkチームはレスポンスが早く、2019年から一貫してリリースを続けています。
PHP-FPMとMySQL/Postgresの環境を運用する用意があり、月間数百万クリックを超えるスケーリングが必要ない場合、Shlinkは妥当な選択肢です。単一プロセスのリダイレクト層は、高負荷時にはボトルネックとなるため、水平スケーリングにはロードバランサーと共有キャッシュをフロントに配置する必要があります。
Polr#
軽量なPHP製短縮サービスです。Polrは2017年から2019年頃にかけて人気がありましたが、現在はプロジェクトのメンテナンスがほぼ停止しています。YOURLSと機能的には似ていますが、よりクリーンなAPIを持っています。今日新たに導入するには、メンテナンスの欠如が懸念されます。セキュリティパッチが定期的に提供されないためです。
Kutt#
Node.js、Postgres、Redisを採用しています。Kuttは、最も活発な「モダンスタック」の短縮サービスです。カスタムドメイン、パスワード保護リンク、有効期限設定、基本的な分析機能を備えています。分析機能の使い勝手はYOURLSより優れていますが、依然としてリレーショナルデータベースベースです。
Kuttの運用構成はYOURLSよりも重く、Node + Postgres + Redisという3つのサービスを運用する必要がありますが、モダンなスタックにより、中程度のボリュームにおいてコスト対効果の高いパフォーマンスが得られます。チームがNode.jsに慣れている場合、今日「モダンなオープンソース短縮サービス」を選択するなら、Kuttが最も安全な選択肢です。
Dub-self-hosted#
Dub.coは、同社のマネージド製品をセルフホスト版として公開しています。Dubは、Next.js + Postgres + Redis + Tinybirdというスタックで、洗練されたダッシュボードと優れた分析機能を提供します。運用の複雑さは今回紹介する5つの中で最も高く、デフォルトのデプロイメントでTinybird（マネージドなClickHouseサービス）が使われているため、これを自己ホスト型のClickHouseに置き換えるには、かなりの労力が必要です。
Dub-self-hostedは、モダンなウェブスタックの運用に慣れており、最新のマネージド製品のようなルック＆フィールを求めるチームに適しています。運用予算に限りがある場合や、Next.jsに精通していないチームには適していません。
ベンダー比較マトリックス#
分析機能、運用、カスタムドメイン、スケーリングの余裕という4つの軸で評価します。評価はAからDで、プロジェクトが標準で提供する機能に基づいています（カスタム開発は含みません）。
| プロジェクト | 分析機能 | 運用 | カスタムドメイン | スケーリング | スタック |
|---|---|---|---|---|---|
| YOURLS | D | A | C (手動) | D | PHP + MySQL |
| Shlink | C | B | B | C | PHP + Postgres |
| Polr | D | B | C | D | PHP + MySQL |
| Kutt | C | C | B | C | Node + Postgres + Redis |
| Dub-self-hosted | B | D | A | B | Next.js + Postgres + Redis + Tinybird |
| Elido-self-hosted | A | C | A | A | Go + Postgres + Redis + ClickHouse + Redpanda |
このマトリックスから2つの傾向が見て取れます。まず、分析機能はスタックの複雑さに比例して向上します。リンクと同じリレーショナルデータベースにクリック情報を保存するプロジェクトよりも、専用の分析パイプラインを備えたプロジェクトの方が評価が高くなります。次に、カスタムドメイン機能はYOURLS以外では概ね良好です。これは、ACMEによる自動化がコモディティ化したためです。
隠れたコスト：スケーリングする分析機能#
クリックイベントは予想よりも早く蓄積されます。1日100クリックのリンクであれば、年間36,500クリックであり、どのリレーショナルデータベースでも管理可能です。しかし、1日100,000クリックのリンクであれば、年間3650万クリックに達し、ここでMySQLやPostgresは悲鳴を上げ始めます。1日平均1,000クリックのリンクが1,000個ある小さなSaaS製品では、年間10億クリックに達します。この規模になると、適切な調整なしではリレーショナルデータベースは破綻します。
上記の5つのオープンソースプロジェクト（DubとElidoを除く）は、リンクと同じデータベースにクリック情報を保存します。また、クエリパターンも一般的なOLTPとは異なります。「過去30日間の、このリンクの1日あたりのクリック数」といったクエリは、範囲スキャンと集計が必要であり、OLTP向けに最適化されたデータベースにとって最悪のケースです。
これを解決することは可能です。ClickHouseは10億イベント規模の分析ワークロードを快適に処理します。ClickHouseによるクリック分析の理由についての記事では、その理由を解説しています。しかし、スタックにClickHouseを追加するということは、運用するサービス、バックアップパイプライン、監視項目が一つ増えることを意味します。リンクのトラフィック量が少ない場合（月間1,000万クリック未満）、リレーショナルデータベースでの運用で数年間は問題ありませんが、それを超えるボリュームでは、分析層自体が大きなプロジェクトになります。
隠れたコスト：エッジPOPとレイテンシ#
単一サーバーのセルフホスト型短縮サービスは、一つの地理的な場所からリダイレクトを返します。もしユーザーが3つの大陸に分散している場合、遠方からのレイテンシは200-300msに達し、ユーザー体験を損ないます。
解決策は以下の通りです：
- 複数のPOPのフロントにAnycast IPを配置する。 自社でASとBGP環境を持っている場合のみ現実的です。一般的なセルフホスト環境では現実的ではありません。
- DNSベースの地理的ルーティング。 Cloudflare、Route53、NS1を使用して、最も近いPOPにユーザーをルーティングします。機能しますが、リダイレクトに加えてDNS解決のレイテンシが加わります。
- CDNの活用。 リダイレクト処理のフロントにCloudflareやFastlyを配置します。CDNはGETレスポンスをキャッシュしますが、リンク先が変更された際のキャッシュ無効化ロジックは単純ではありません。
- 地域ごとにPOPを配置する。 Frankfurt、Ashburn、Singaporeなどでリダイレクト処理を実行し、それらの間でデータベースを共有するか、結果整合性を確保します。これが本番環境における標準的なパスですが、単一リージョンのセルフホスト環境よりもはるかに多くの作業が必要です。
エッジPOPとDNSルーティングに関する記事では、この選択肢について詳しく解説しています。ほとんどのセルフホスト環境は単一リージョンで留まります。マルチリージョンへの対応はそれ自体が大きなプロジェクトとなるからです。
セルフホストが合理的な場合#
3つのシナリオがあります：
データ主権が譲れない場合。 医療、金融、政府などの規制産業では、データが自社のインフラ内に存在することが求められます。マネージド製品（たとえEU内にあるとしても）では、データがセキュリティ境界の外部に出てしまうため不十分です。この場合、セルフホストが正解です。メンテナンスコストはコンプライアンスの代償です。
トラフィックが少なく、技術力がある場合。 内部利用目的でセルフホスト環境を運営しており、月間100万クリック未満、外部顧客向けのカスタムドメインは不要、そしてDocker Composeスタックを自力で維持できるエンジニアがいる場合、YOURLSやShlinkは清潔にフィットします。この規模ではマネージドサービスはオーバーキルです。
派生製品を構築している場合。 短縮URLが構築中の大規模製品のフロントエンドである場合（例：イベントチケットプラットフォームで、短縮URLがチケットを指す場合など）、セルフホストであれば、マネージドベンダーでは不可能な方法でリダイレクト層とビジネスロジックを結合できます。Dubのセルフホスト版を利用しているユーザーの多くは、このカテゴリーに分類されます。
セルフホストが合理的でない場合#
反対に、3つのシナリオがあります：
高度な分析が必要な場合。 利害関係者から「これらの50のキャンペーンについて、過去90日間の国別クリック分析はどうなっているか？」と尋ねられると、リレーショナルデータベースでの保存は破綻します。分析パイプラインを一から構築する（数ヶ月かかるプロジェクト）か、最初から分析機能が備わっているマネージドベンダーに料金を支払うことになります。
多くの顧客向けのカスタムドメインが必要な場合。 1つのドメインのACME設定は簡単です。しかし、10,000もの顧客が提供するドメインに対して、取り消し、更新、オンデマンド発行を伴うACME運用を行うことは、重大なエンジニアリング領域です。カスタムドメインTLSの記事で解説していますが、これを自社で構築するのは数日ではなく、数ヶ月の工数がかかるプロジェクトです。
チームの時間がボトルネックである場合。 セルフホスト型短縮サービスは、セットアップ完了後も、安定稼働時に月に約4〜8エンジニア・時間を消費します。さらに、アウトエイジやアップグレードにかかる時間も加算されます。エンジニアの時給を100ドルとすると、四半期ごとの2週間のトラブルシューティングを含めずとも、月額400〜800ドルのコストがかかります。月額300〜500ドルのマネージドベンダーは安く見え始めます。
損益分岐点の計算は、チームの時間の価値と、運用上の問題がどれくらいの頻度で発生するかという2つの入力要素に敏感です。すでにk3sクラスターを運用しているチームであれば、短縮サービスを追加する限界コストは低いです。しかし、現在インフラを運用していないチームにとっては、短縮サービスをホストすることで、監視、ログ、バックアップといった周辺コストが引きずり込まれ、請求額が膨れ上がります。
実用的な意思決定ツリー#
5つの質問による意思決定：
- 規制やポリシーにより、リンクデータを自社制御下のインフラに保持する必要がありますか？ はいの場合、セルフホストしてください。以上です。
- クリックボリュームが、現在または24ヶ月以内に月間5,000万クリックを超える見込みですか？ はいの場合、専用の分析層を計画する必要があります。これは、Dub-self-hosted、Elido-self-hosted、またはClickHouseベースの分析を備えたマネージドベンダーのいずれかに偏ります。
- 10社以上の顧客に対してカスタムドメインが必要ですか？ はいの場合、ACME自動化のコストは無視できません。上記と同じプロジェクト、またはマネージドサービスを検討してください。
- 貴社のチームは現在、オンコール体制で他の本番サービスを運用していますか？ いいえの場合、セルフホストの運用コストは見た目よりも高くなります。
- 短縮リンクは製品の戦略的な領域ですか（例：インテグレーションプラットフォームを構築している）、それともサポート的なユーティリティですか（例：チーム内のリンク共有）？ 戦略的な領域であればセルフホストまたは深い統合が可能なマネージドサービス、単なるユーティリティであれば安い方を選んでください。
多くのチームは、この意思決定ツリーを通すことで、最終的にマネージドサービスを選択することになるでしょう。それで問題ありません。セルフホストは、制約が明確である場合にこそ正しい答えとなります。制約が明確でない場合、セルフホストをデフォルトにすべきではありません。
関連資料#
- Bitlyの代替サービス — 実際の機能ギャップ — 広い範囲のマネージドベンダーの比較。
- k3s環境へのElidoのセルフホスト — プレイブック — Elido側での運用ガイド。
- Elido vs YOURLS — 最も普及しているオープンソースオプションとの直接対決。
- ClickHouseによるクリック分析の理由 — 分析層に関する論理。
- エッジPOPとDNSルーティング — マルチリージョンへの道。
- 製品の表面:
/solutions/developersおよび/pricing。 - アーキテクチャ: edge-redirect ドキュメント。