「PHP＝レガシー」と言われて久しい今、Laravelは日本でも世界でも現役バリバリのフレームワーク。 とりあえず動く、けど意外と拡張も効く。でも「PHPだから」と選ばれないこともしばしば。

この記事では、「何を作りたいか」という視点から、Laravelと他の代表的フレームワークを目的別に比較し、 適材適所の選択を考えるためのヒントをまとめます。

技術選定に役に立ったら幸いです。

PHPの現在

「レガシー」「動的型」「なんとなく古い」

PHPにはどうしてもこんなイメージがつきまとう。

でも、冷静に見れば今でも使う理由はちゃんと残っている。

静的型付けっぽいこともできる時代

PHPは動的型ですが、phpstanやPsalmのような静的解析ツールを導入することで、

型チェックやコーディング規約の徹底がかなり現実的にできるようになりました。

もちろん、型そのものが言語レベルで守ってくれるわけではないけど、

「型定義できない」「プリミティブが貧弱」という課題は、

値オブジェクトや独自のDTO（Data Transfer Object）を用意することで十分対応できる。

PHPの地味な強さと今どきの現場適性

• 情報・知見が圧倒的に多い
  • たいていの問題はググれば日本語記事・フォーラムで何かしら見つかる
• LaravelをはじめとしたモダンFWの登場で、今も進化中
  • 型補助・属性・enum・readonlyなど、「ちゃんと新機能も追える」
• 「枯れている」ことは悪じゃない
  • 長く動き続けるプロダクト＝意外とPHPばかり
• 人材調達がしやすい
  • 学習コストが低く、歴史も長いので、現場にとっつきやすい人が多い
• コミュニティ活発・エコシステム豊富
  • サードパーティ製ライブラリ、公式パッケージ、学習教材も充実

技術選定は目的比較で行う方が幸せ

• フレームワーク選びは宗教戦争ではなく、目的との相性の話
• 「何を最優先したいか」＝初期開発の速さ？ 保守性？ 拡張性？ パフォーマンス？ チーム体制？
• どれだけ有名なフレームワークでも、使いどころを間違えると地獄になる
• 筋の通った技術選定をチームで合意できるのが一番！

フレームワーク比較表（目的別）

目的	適したフレームワークや言語	補足	Laravelとの比較
初期構築の速さを重視	Laravel / Rails	scaffoldやCLIが充実。画面付きWebアプリを即作れる	◎ Laravelはこの分野で無双。即納期の要件なら最強
API中心で構築したい	FastAPI / NestJS / AdonisJS	軽量で設計明快。APIサーバー特化	◯ Laravelでも十分可能だが、「API専用」感はやや弱い
設計パターンに明確な制約がほしい	Symfony / Spring Boot	フレームワーク自体が設計を“強制”	△ Laravelは自由なので“野良設計”になりがち。良くも悪くも自分次第
自由度を重視したい	Go / Node.js	フレームワークが過干渉しない	◯ Laravelはそこそこ自由。ただ「型」はなく“枠”は用意される
静的型や性能を優先したい	Rust / Kotlin	型安全・高パフォーマンス	× Laravel/PHPはこの観点は弱い。重いAPIやバッチ処理はやや不利

シーン別・Laravelが「光る／曇る」瞬間

🙆 Laravelが真価を発揮するシーン

• 社内ツールや業務システム（中小規模）
  • 要件がよく変わる
  • 開発人数が少ない、もしくは新人も入る
  • 「とにかく画面を生やす」「爆速で試す」が正義
• プロトタイピングや受託案件
  • コストとスピード重視、品質は後追いで調整
• WordPressや既存PHP資産との連携が必要な場合
  • 既存環境との親和性を取るならLaravelが便利

🙅 Laravelでは辛いシーン

• 超大規模・マイクロサービス群
  • チームごとに厳密な設計と責務分離が必要
  • 仕様のカタを求める場合は、SymfonyやSpringなどの型が強いFWが向く
• 厳密な型安全・パフォーマンスが生命線
  • リアルタイム系・並列処理・重たいAPIサーバー
  • Rust, Go, Kotlinなどの型が守ってくれる世界のほうがストレスない

Laravelを選ぶ／選ばない、その基準

• 「納期優先」「PoCや試作」「少人数チーム」ならLaravelで即決しても困らない
• 「長期保守」「組織での標準化」「型・設計の厳格さが必要」なら、もっと重いフレームワークを検討
• 「とりあえずLaravelで始めて、詰まったら他を検討」も現場ではよくある選択肢

よくある誤解

• Laravelは設計思想が薄い？
  • 実は薄いのではなく、選べる幅が広い
  • 「MVC」「サービス層」「リポジトリパターン」など、必要なら設計ガチ勢にも寄せられる
  • ただし、現場では大半が「最短ルート」で組まれるため、結果的に“設計思想が薄く見える”現象が起きる

おわりに：目的と現場にフィットする選択を

「Laravelが万能」も「〇〇のほうが正義」も、すべて自分の現場と目的次第。

大切なのは、「今、この案件で何を優先したいのか？」を素直に考えること。

Laravelは柔軟に、速く作りたい現場の最適解になりえる可能性がある。

とにかく大事なのは筋の通った選択をすること、そしてそれをチームで合意できることです。

FAQ