プライベートで動画配信システムを内製化して2年運用した話 #PERSOL CAREER Advent Calender2025

はじめに

こんにちは、新規サービス開発統括部エンジニアの今井です。

本記事は、筆者がプライベートで開発している動画配信システムについてご紹介するものです。弊社での事例ではありませんのでご留意ください。

親族の会社（教室ビジネス）では、生徒向けに動画オンデマンド配信を行っており、当初はVimeoを利用していました。しかし、年間1,000件規模のアップロードがあり、月額コストが高額になっていたことが課題でした。

「動画配信システムを自前で開発できないか？」という話が持ち上がり、開発に着手。約2年間運用してきた中での試行錯誤と学びを共有します。

開発前は、以下のようなシンプルな構成でした。

Vimeoは使いやすく安定していましたが、アップロード件数が増えるにつれてコストが課題となりました。

そのためVimeoに変わるシステムを内製で開発することになりました。

開発の第一歩として、以下の構成でシステムを構築しました。

コンポーネント	技術選定
管理画面（Frontend）	Vercel
認証・DB・バックエンド	Supabase
動画保存先	ストレージサービス
動画変換処理	AWS Lambda + ffmpeg（Lambdaレイヤー）

動画ファイル（mp4, mov）をHLS形式に変換し、ストレージに格納する構成です。

Lambdaの処理時間上限（15分）に抵触

数GBの動画ファイルでは、ffmpegによるHLS変換処理が15分を超えてしまい、処理が完了しないケースが発生しました。これは致命的な問題であり、動画変換処理の見直しが必要となりました。

Lambdaの制限を回避するため、動画変換処理をAWS MediaConvertに移行しました。

コストが月額数万円に

MediaConvert自体は非常に安定していましたが、件数が増えると月額数万円規模のコストが発生しました。Vimeo時代と比較すれば安価ではあるものの、さらなるコスト削減を検討することにしました。

コスト削減を目指し、VPSを契約してffmpegによるCPU処理（h264エンコード）を行う構成に変更しました。

処理性能の限界

CPU処理ではスケーラビリティに限界があることを痛感しました。

現在は、オフィス内に自前のGPUマシンを設置し、GPU処理による高速化を実現しています。

現状は1社での利用に限定されており、ある程度のダウンタイムは許容される環境のため運用できていますが、商用化を見据えると安定性の向上が必要です。

今後は以下の改善を検討しています。

2年間の動画配信システム開発を通じて、以下のような変遷をたどりました。