Lerdで広がるLaravel開発環境の選択肢：Herd、Sailとの違いと導入判断

PHPとLaravelのローカル開発環境に、オープンソースのLerdという選択肢が加わりました。
LerdはLinuxとmacOSを主対象とし、WindowsではWSL2ベータとして提供されています。
HerdやLaravel Sailから機械的に乗り換えるのではなく、チームのOS、サービスの分離単位、環境定義の共有方法で選ぶと判断しやすくなります。

Lerdがまとめるローカル開発の機能

Lerdは、Nginx、PHP-FPM、データベースなどをrootless Podmanコンテナで動かす、Herdに近い操作感を目指したローカルPHP開発環境です。
Lerdの公開リポジトリでは、PHPプロジェクトへの自動的な.testドメイン割り当て、HTTPS、プロジェクト別のPHPとNode.jsのバージョン管理、各種サービス、キューやスケジューラのワーカー管理が案内されています。

個々の機能より実務に効くのは、開発者がWebサーバー、PHP、証明書、DNSを別々に組み立てる作業を減らせる点です。
既存プロジェクトではlerd linkでサイトを登録でき、チームで共有する設定は.lerd.yamlに記述できます。
ただし、設定ファイルがあるだけで本番環境との差が消えるわけではありません。

対応OSと導入前に知っておきたい条件

Lerdの動作要件によると、Linuxではsystemdのユーザーセッションとrootless Podman 4.5以降が前提です。
macOSではmacOS 13以降に対応し、Podman Machine上でコンテナを動かします。
Windows対応はWSL2ベータなので、Windowsを標準端末とする組織では、業務利用に必要な安定性と社内サポート手順を小規模な検証で確かめる必要があります。

「rootlessなら導入時も管理者権限が一切不要」という意味ではありません。
公式のインストール手順では、80番と443番ポートの利用、ログアウト後も続くsystemdユーザーサービス、DNS操作、ローカルCAの信頼設定などに関する初期処理が説明されています。
社給端末では、インストールスクリプトの確認に加え、端末管理ポリシー、証明書ストア、外部コンテナイメージの取得可否を管理担当者と確認すべきです。

Herd、Sailとの構成の違い

三つの環境は、同じLaravel開発を支援していても、実行単位が異なります。
Laravelのインストール文書はHerdをmacOSとWindows向けのネイティブ環境として案内し、Laravel Sailの公式文書はプロジェクトごとのcompose.yamlとDockerコンテナを中心に説明しています。
Lerdはrootless Podman上の共有スタックを使うため、ネイティブ実行とプロジェクト単位の完全なコンテナ構成の中間に位置します。

Lerdの比較資料も、Lerdを共有基盤、Sailをプロジェクト別基盤として整理しています。
共有基盤は複数案件を素早く起動しやすい一方、案件ごとに異なるデータベース版や拡張機能まで厳密に分けたい場合には、Sailの構成が理解しやすいことがあります。
この差は性能の優劣ではなく、どこまでを案件固有の構成として管理するかの差です。

チーム導入で先に揃える判断軸

開発端末のOSを一覧にする

最初に、開発者、デザイナー、テスト担当者が使うOSとCPUアーキテクチャを一覧にします。
LinuxとmacOSが中心ならLerdを共通候補にできますが、Windowsネイティブ利用が多い組織ではHerd、複数OSをまたいで同じコンテナ定義を使いたい組織ではSailも残して比較します。

分離したいものを決める

PHPのバージョンだけを案件ごとに変えたいのか、MySQL、Redis、検索エンジンまで案件ごとに固定したいのかを決めます。
前者は共有スタックと相性がよく、後者はプロジェクト別コンテナの利点が大きくなります。
顧客案件を並行して扱う場合は、同名データベース、ポート、メール捕捉、キューワーカーが別案件に影響しないことも確認します。

本番との差を検査項目に変える

ローカル環境の使いやすさだけで採用を決めると、公開直前に差分が見つかります。
PHP本体と拡張機能、php.ini、データベースの版と照合順序、タイムゾーン、キュー、スケジューラ、ファイル保存先、メール送信、HTTPSを検査項目にします。
PHPやLaravelのバージョン選定から運用までの全体像は、既存記事のPHPとLaravelによる業務Webアプリの設計と運用ガイドで確認できます。

小規模な導入検証の進め方

1. 代表的な案件を一つ選ぶ：データベース、キュー、フロントエンドビルドを使う案件を選び、単純な新規プロジェクトだけで判断しません。
2. 同じ確認手順を使う：初回構築時間、再起動後の復旧、テスト実行、Viteの更新、メール捕捉、Xdebug、キューとスケジューラを候補環境ごとに確認します。
3. 端末を替えて再現する：別の開発者がREADMEとリポジトリ内の設定だけで起動できるかを試します。口頭説明が必要だった手順は文書へ戻します。
4. 障害時の戻し方を試す：コンテナ、DNS、証明書、データベースを停止した状態から復旧できるか、アンインストール後に既存環境へ戻せるかを確かめます。
5. 採用範囲を限定して始める：新規案件だけ、Linux端末だけなど適用範囲を決め、既存案件を一斉に移行しません。

エディタ連携も検証する場合は、補完機能がローカルのPHP実行経路を正しく認識するか確認します。
Laravel固有の補完と診断については、Laravel LSPの対応エディタと導入手順も参考になります。

導入判断で避けたい思い込み

• 新しい環境なら本番も再現できる：ローカルの起動方法と本番構成は別の設計です。差分を列挙し、CIとステージングで検証します。
• rootlessなら安全確認は不要：権限を抑える設計でも、取得するバイナリ、コンテナイメージ、ローカルCA、共有機能の管理は残ります。
• 全員が同じ環境を使うべきだ：共通化の効果より移行負担が大きい案件では、実行コマンドと検証条件だけを揃える方法もあります。
• 起動が速ければ保守しやすい：更新手順、障害調査、データ退避、担当交代まで再現できて初めて、チームの保守負担を評価できます。

よくある質問

LerdはLaravelの公式製品ですか

Lerdはlerd-env組織が公開するMITライセンスのオープンソースプロジェクトです。
Laravelの公式文書が案内するHerdやSailとは提供主体が異なるため、採用時はLerdのリリース、課題一覧、更新方針を継続して確認します。

LinuxならLerdを選べばよいですか

Linux対応はLerdの明確な利点ですが、それだけでは決まりません。
systemdとPodmanの要件、社内端末への導入可否、案件ごとのサービス分離、既存のDocker運用との重なりを確認して選びます。

SailからLerdへ置き換えられますか

多くのLaravel開発作業はLerdでも実行できますが、構成は同一ではありません。
Sailのcompose.yamlで案件固有のサービス版、ボリューム、ネットワークを定義している場合は、移行前に対応表を作り、データの退避と復旧を試します。

最初の検証にはどれくらいの範囲が必要ですか

画面表示だけでは判断できません。
依存関係の導入、マイグレーション、テスト、フロントエンドビルド、キュー、スケジューラ、メール、デバッグ、再起動後の復旧までを一周させると、日常運用に近い差が見えます。

開発環境はチームの運用条件で選ぶ

Lerdは、LinuxやmacOSで複数のPHP案件を扱い、Herdに近い手軽さとコンテナによる分離を両立したいチームに検討価値があります。
一方、macOSやWindowsでネイティブ実行を優先するならHerd、案件ごとの構成をDocker Composeで明示したいならSailが自然です。
候補を一つに決める前に代表案件を移し、起動の速さだけでなく、再現、障害対応、更新、担当交代まで試すことで、長く使える開発環境を選べます。

参考資料

• Lerdの公開リポジトリ
• Lerdの動作要件
• Lerdと他のローカル開発環境の比較
• Laravel 13.xのインストール文書
• Laravel Sail公式文書
• 株式会社greeden公式サイト