自社LMSをフルスクラッチで作る判断

TeachableやThinkific、国内ならAirCourseやlearningBOXなど、成熟した選択肢があります。月額数万円で、開発費ゼロ、保守もゼロ。この前提を覆すには、明確な理由が必要です。

自社開発を正当化する条件は3つです。第一に、LMSが事業の中核であり、差別化の源泉になる場合。私たちの場合、外国人材向けの日越二言語学習体験と、受け入れ企業側の管理機能の組み合わせが商品そのものであり、既存SaaSでは表現できませんでした。第二に、他システムとの統合要件が深い場合。第三に、開発コストの構造が変わったこと。AIエージェントによる開発で、LMSのような枯れたドメインの実装コストは従来の数分の一になりました。

この3条件に当てはまらないなら作るべきではありません。「SaaSの月額費用が高いから」だけを理由にした自社開発は、保守コストの見積もり漏れでほぼ確実に後悔します。

LaravelのAPI認証には主にPassportとSanctumがあり、SPAとの組み合わせではSanctumが標準解です。OAuth2の全機能が必要になるのは外部開発者にAPIを公開する場合であり、自社フロントエンドだけが相手ならPassportは過剰装備です。

実装上の要点は3つです。第一に、トークンをローカルストレージに置かず、HttpOnlyクッキーによるステートフル認証を使うこと。XSSでトークンが盗まれるリスクを構造的に排除できます。第二に、CORS設定とSANCTUM_STATEFUL_DOMAINSの整合。「ローカルでは動くのに本番でログインできない」の典型原因です。第三に、ロール設計です。受講者、企業管理者、システム管理者の3ロールをミドルウェアで制御し、さらにポリシークラスで「自組織のデータしか見えない」というテナント境界を強制します。

マルチテナントのデータ漏洩は、LMSにおいて最も起こしてはならない事故です。認可のテストはE2Eテストの最優先項目に置いています。

基本構造は、courses、lessons、users、organizations、そして進捗を記録するlesson_user（受講者×レッスンの中間テーブル）です。設計の分かれ目は、この中間テーブルに何を持たせるかにあります。

私たちは、状態、完了日時、視聴位置、そして完了条件のスナップショットを持たせています。最後の項目が重要です。コースの内容は改訂されます。レッスンが追加されたとき、改訂前に修了した受講者の「修了」は維持されるべきか。この問いに答えるには「修了した時点で何が完了条件だったか」を記録しておく必要があります。進捗を単なる現在状態として持つと、コース改訂のたびに過去の記録の整合性が壊れます。

もう一つの設計判断は、集計の持ち方です。受講者数×レッスン数が数十万行程度まではリアルタイム集計で十分です。私たちは管理画面のレポート表示にのみ集計テーブルを使い、日次バッチで更新しています。最初から非正規化に走ると整合性バグに苦しみます。遅くなってから最適化する、が正しい順序です。

完成後に発生した作業は、機能追加だけではありません。Laravelのメジャーバージョン追従、依存パッケージの脆弱性対応、PHPのバージョンアップ、動画配信のコスト最適化、細かなUI改善要望。SaaSなら意識しなくてよいこれらの作業が、確実に発生します。

それでも自社開発を選んで良かったと言えるのは、LMSが「売り物」であると同時に「自社の技術力の実証の場」でもあるからです。本サイトの技術文書で扱うテーマの多くは、このLMS開発から生まれています。

意思決定の材料として、着手前に答えるべき問いを挙げます。

動画配信は、自社サーバーからの直接配信を推奨しません。外部の動画プラットフォームに限定公開でホストし、LMS側は埋め込みと視聴位置の記録を担う分業が、規模が小さいうちの現実解です。

修了証の発行は、修了判定と証書PDFの生成を分離しています。証書には発行日・コース版・検証用IDを埋め込み、再発行時も同一内容が出るよう、発行時点のデータを保存しています。

スモールスタートの最小構成は、認証、コース閲覧、進捗記録、管理者の進捗一覧の4機能です。逆に、最初から作り込んではいけないのは通知機能と分析ダッシュボードです。運用が始まると要件が必ず変わります。