Question 1

メンバーシップ限定配信の環境を自前で構築しようとした理由と要件は何か？

Accepted Answer

通常回とプレミアム限定回を1つの公式サイト上で時系列にまとめて表示したかった ポッドキャストアプリで限定回を購読可能にし、解約時には即座に聴取不可にする制御を行いたかった 個人開発の意欲があり、未経験の技術スタックに挑戦する良い機会だと考えたためフルスクラッチを選んだ

Question 2

自前実装の初期段階（フェーズ1〜2）で直面したセキュリティや設計上の壁は何か？

Accepted Answer

既存配信サービスの埋め込みプレイヤーが限定フィードに対して404エラーを返すため、標準オーディオタグでの直接再生に切り替える必要があった クライアント側で処理すると、開発者ツール等で限定フィードのURLや音声ファイルパスが露出してしまう問題が生じた サーバー側に処理を移動させても、取得できる音声ファイルのURL自体が直リンクのため、URL共有による無断聴取を防げなかった

Question 3

既存の外部プラットフォーム（MemberfulやPatreon等）の導入を見送った理由は何か？

Accepted Answer

Memberfulなどの知名度の高いサービスは月額25ドルなどの固定費がかかり、個人運営には負担が重かった Patreonなどはポッドキャスト専用ではなく、不要な機能に対してもコストが発生してしまう フォロワー数や売上が未知数な段階で、毎月高額な固定費を払い続けるリスクを避けたかった

Question 4

Cloudflare Workersを用いた認証プロキシ構成ではどのような工夫がされたか？

Accepted Answer

Firebaseで会員・決済状態を管理し、Cloudflare WorkersとKVでアクセス権限を瞬時に判定する二段構えを構築した 期限付き署名入りURLとKVによる二重チェックを導入し、URLが流出しても即座に無効化できる仕組みを作った Cloudflare Workersは起動待ち時間がほぼゼロで処理速度が速く、シーク再生や無料利用枠の広さにおいても優秀だった

Question 5

最終的に自作システムを破棄し、Substackへ移行を決断した理由と学びは何か？

Accepted Answer

技術的な問題ではなく、インフラの維持管理やサプライチェーン攻撃などのセキュリティリスクを個人一人の責任で背負い続ける負担が大きすぎた 本来の目的は「音声の配信」であり「インフラの運用」ではないため、管理コストを外部サービスに押し付ける判断をした デザインの自由度低下や手数料の増加というトレードオフを受け入れ、Substackに一本化することで構成を極限までシンプルにした 苦労して作ったものを捨てるサンクコストの葛藤はあったが、技術のキャッチアップという学びを得られたため勉強代として割り切った

Podcast振り返り

Season 5-7. メンバーシップ限定配信の基盤を自前で作ったら沼すぎて，最終的に全部捨てた話