Shlink#

• 公式: https://shlink.io/
• ドキュメント: https://shlink.io/documentation/
• GitHub: https://github.com/shlinkio/shlink
• 言語: PHP 8.x (Mezzio / Laminas)
• ライセンス: MIT
• GitHub Star: 約 4,000+

YOURLS#

• 公式: https://yourls.org/
• ドキュメント: https://yourls.org/docs/
• GitHub: https://github.com/YOURLS/YOURLS
• 言語: PHP
• ライセンス: MIT
• GitHub Star: 約 9,000+

Kutt#

• 公式: https://kutt.it/
• ドキュメント: https://docs.kutt.it/
• GitHub: https://github.com/thedevs-network/kutt
• 言語: TypeScript / Node.js
• ライセンス: MIT
• GitHub Star: 約 8,000+

Dub#

• 公式: https://dub.co/
• ドキュメント: https://dub.co/docs
• GitHub: https://github.com/dubinc/dub
• 言語: TypeScript / Next.js
• ライセンス: AGPL-3.0
• GitHub Star: 約 18,000+

Polr#

• 公式: https://polrproject.org/
• ドキュメント: https://docs.polrproject.org/
• GitHub: https://github.com/cydrobolt/polr
• 言語: PHP (Laravel)
• ライセンス: GPL-2.0
• GitHub Star: 約 4,000+

Slash (補足)#

• GitHub: https://github.com/yourselfhosted/slash
• 言語: Go
• ライセンス: MIT
• GitHub Star: 約 5,000+

Sink (サーバーレス系)#

• GitHub: https://github.com/ccbikai/Sink
• 公式デモ: https://sink.cool/
• 言語: TypeScript (Nuxt 3)
• ライセンス: MIT
• GitHub Star: 約 6,000+

ここまで紹介してきた OSS は基本的に コンテナ / VM 上で動かす前提 ですが、Sink は Cloudflare ネイティブ (Workers + KV + Analytics Engine) で動作する点が大きく異なります。サーバーを 1 台も立てずに、wrangler deploy 1 コマンドで運用開始できます。

構成パターン#

flowchart LR
    subgraph User
        U[利用者]
    end

    subgraph AWS
        R53[Route 53<br/>独自ドメイン]
        ALB[ALB / CloudFront]
        APP[ECS Fargate or EC2<br/>短縮URL アプリ]
        DB[(RDS<br/>MySQL/PostgreSQL)]
        CACHE[(ElastiCache<br/>Redis)]
        S3[(S3<br/>必要に応じて)]
    end

    U --> R53 --> ALB --> APP
    APP --> DB
    APP --> CACHE
    APP --> S3

パターン 1: 最小構成 (個人〜小規模社内)#

ALB を使わず、Nginx + Let’s Encrypt で EC2 直撮 (Elastic IP) の前提です。 Shlink / YOURLS / Polr / Slash / Kutt (Redis 無し設定) が現実的です。

パターン 2: 中規模 (社内全体・サービス公開)#

Shlink / Kutt あたりに最適。冗長化と CDN を効かせた構成です。

パターン 3: 大規模 (Dub 級の SaaS 品質を内製)#

これに加えて Dub の場合は Tinybird (有料)、Resend (メール送信) などのサードパーティ費用が乗ります。

補足: 短縮URLは「リダイレクトだけ」と侮りがちですが、クリック計測の書き込み量がスループットのボトルネック になります。本格運用では Redis や ClickHouse / Tinybird のようなアナリティクス基盤の検討が早期に必要です。

パターン 4: サーバーレス (Cloudflare / Sink 利用)#

AWS ではなく Cloudflare を使う前提で、Sink を採用する場合の費用感です。 EC2 / RDS / ALB といったリソースが一切不要になるため、桁が変わります。

flowchart LR
    User[利用者] --> CF[Cloudflare<br/>エッジ]
    CF --> W[Cloudflare Workers<br/>リダイレクト + 管理画面]
    W --> KV[(Cloudflare KV<br/>slug → 元URL)]
    W --> AE[(Analytics Engine<br/>クリックログ)]
    W -.->|任意| AI[Workers AI<br/>slug 自動生成]

中規模以上 (1日 10 万リクエスト超 / KV 読み取り 10 万/日超) では Workers Paid プランへの移行が必要です。

AWS のパターン 2 (約 $152/月) と比較すると、Sink + Cloudflare は1桁安く済む ケースがほとんどです。 ただし、Cloudflare 依存・KV の結果整合性・監査ログの粒度 などのトレードオフがあるため、用途と要件次第で AWS 構成と使い分けるのが現実的です。

1. ドメイン戦略#

• 短縮 URL は 独自ドメイン (例: go.example.co.jp) で発行するのが基本
• ブランド毀損や乗っ取り対策のため、ドメインの HSTS preload / CAA レコード / DMARC も同時に検討
• リンクは長期間生き残るので、捨てやすいドメインを使わない

2. リンクの永続性 (Link Persistence)#

• 数年後にもクリックされる前提で、DB バックアップ・サービス停止時の代替案 を必ず用意
• 移行性を考えるなら、カスタム短縮 URL (slug) のエクスポート / インポート がしやすい OSS を選ぶ
• ShortIO 等の SaaS から移行する場合、CSV インポート可否を確認する

3. アナリティクスの粒度と保存期間#

• クリックログは個人情報 (IP) を含むため、保存期間・匿名化方針 を最初に決める
• 大量のリンク + 大量のクリックを扱う場合、RDB だけでは負荷的に厳しい。カラムナ DB (Tinybird / ClickHouse) や Redis、Kinesis との組み合わせを検討
• GDPR / 個人情報保護法を意識するなら、IP のハッシュ化やジオロケーション粒度の制御が必要

4. セキュリティ#

• 短縮 URL は フィッシングや C2 通信の踏み台 として悪用されやすい
• 対策として、事前 URL スキャン (Google Safe Browsing API, VirusTotal API)、禁止ドメインリスト、レート制限、短縮可能ユーザーの認証 をどう実装するか
• 公開短縮 URL を許す場合は、CAPTCHA + WAF + 通報フロー を必ず設計する

5. 可用性・SLO#

• 短縮 URL がダウンすると、過去に配信したすべてのリンクが死ぬ
• 影響範囲が極めて大きいので、Multi-AZ / CDN キャッシュ / 障害時のフォールバック を初期から考慮
• CloudFront でリダイレクト結果を短時間キャッシュ (例: 60秒) するだけでも、原本ダウン時の被害が抑えられる

6. ライセンスと商用利用#

• AGPL-3.0 (Dub) は SaaS として外部提供する場合にソース公開義務が生じる
• GPL-2.0 (Polr) も同様に注意が必要
• 社内利用にとどめる前提なら問題は少ないが、プロダクトに組み込んで顧客提供する場合は法務確認 を

7. 運用負荷#

• 個人で運用するなら 依存サービスが少ない OSS (YOURLS / Slash / Shlink) が無難
• 「フルマネージドに近づけたい」なら App Runner / ECS Fargate + RDS のような構成にして、EC2 直運用を避ける
• 自動デプロイ・自動バックアップ・脆弱性パッチ自動適用までを最初の構築時に組み込んでおく