皆さんは普段、PHPのローカル開発環境をどうしていますか?
初学者の頃は XAMPP や MAMP、実務に入ると Docker や Vagrant が主流ですよね。 私も普段はDockerを使っているのですが、ちょっとした検証やツール作りの時に「正直、Docker立ち上げるの重いな…」と感じることがありました。
そんな時、ふと使ってみたら驚くほど便利だったのが、PHPビルトインウェブサーバーです。
みんな知ってはいるけれど、「本番では使えないでしょ?」とスルーされがちなこの機能。 実は、特定の用途においては最強の時短ツールになり得ます。
今回は、私が実際に「めっちゃ便利だった」と感じたユースケース(Gmail OAuth2.0認証テスト)を交えつつ、意外と知られていない活用法をご紹介します。
PHPビルトインサーバーとは?
意外と知らない基本スペック
PHPビルトインウェブサーバー(Built-in web server)は、PHP 5.4.0 から導入された機能です。 別途 Apache や Nginx をインストールする必要なく、PHP だけで簡易的な Web サーバーを起動できます。
【基本スペック】
- 正式名称: CLI SAPI ビルトインウェブサーバー
- 起動コマンド:
php -S localhost:8000 - 対応バージョン: PHP 5.4.0 以上
- プロセスモデル: 基本的にシングルスレッド(リクエストを1つずつ処理)
- HTTPS: 非対応(ネイティブではサポート外)
なぜあまり使われないのか?
これほど手軽なのに、なぜ多くの入門書や記事では XAMPP や Docker ばかり推奨されるのでしょうか?
最大の理由は、公式ドキュメントにあるこの強力な警告です。
警告 この Web サーバーは、アプリケーション開発の支援用に設計されたものです。 ドキュメント付きで使用法を説明するといった場合にも役立つでしょう。 決して番環境のネットワーク上で使ってはいけません。
この「本番では使うな」という言葉が強すぎて、「じゃあ開発でも実用的じゃないのかな?」と誤解されがちなんですね。
また、.htaccess が使えないため、Rewrite ルールに依存するレガシーなフレームワークだと設定が面倒という点もあります。
しかし、「検証用途」では神ツールだった
しかし、この「機能のシンプルさ」こそが最大の武器になります。
特に以下のようなシーンでは、Dockerを起動して docker-compose.yml を書くよりも圧倒的に速いです。
- ルーティングの動作確認
- 簡易フォームのPOST送信テスト
- API連携の疎通確認
- そして、OAuth認証のコールバック受信
実録:Gmail SMTP (XOAUTH2) テストでの感動
私が「これ神だわ…」と確信したのは、Gmail の送信テストで OAuth2.0 認証 を実装していた時でした。
OAuth2.0 では、Google の認証画面から戻ってくるための 「リダイレクトURI」 が必要になります。 これを XAMPP や Docker でやろうとすると、以下のような手間が発生しがちです。
localhostで受けるために VirtualHost を設定する- 必要なら SSL (HTTPS) の自己証明書を用意する
- ポート競合を確認する
しかし、ビルトインサーバーならこれだけです。
# プロジェクトリポジトリでコマンドを叩くだけ
php -S localhost:8000
これだけで、http://localhost:8000 が立ち上がります。
Google Cloud Console の「承認済みのリダイレクト URI」に以下を登録すれば、即座に疎通確認が完了します。
http://localhost:8000/oauth2callback.php
設定ファイルゼロ、待ち時間ゼロ。 このスピード感は、一度味わうと病みつきになります。

実務で使える小ワザ
ただ php -S するだけでなく、いくつかオプションを知っておくとさらに便利です。
1. ドキュメントルートを指定する -t
Laravel や モダンな構成の場合、index.php が public/ ディレクトリにあることが多いです。
その場合、-t オプションでドキュメントルートを指定できます。
# public ディレクトリをルートとして起動
php -S localhost:8000 -t public
2. ルータースクリプトを使う
.htaccess が使えないため、全てのリクエストを index.php に集めたい(フロントコントローラーパターン)場合は、ルータースクリプトを指定します。
php -S localhost:8000 router.php
router.php の中身はこんな感じです:
<?php
// router.php
if (file_exists(__DIR__ . $_SERVER['REQUEST_URI'])) {
return false; // 静的ファイル(画像やCSS)はそのまま返す
}
// それ以外は index.php を読み込む
require __DIR__ . '/index.php';
これで、簡易的なフレームワークの動作確認も可能です。
3. LAN内のスマホから確認する
デフォルトの localhost 指定だと自分自身のPCからしかアクセスできませんが、IPアドレスを 0.0.0.0 にすると、同じWi-Fi(LAN)内のスマホや他のPCからアクセスできるようになります。
php -S 0.0.0.0:8000
※注意: 公衆Wi-Fiなど、信頼できないネットワークでは絶対に行わないでください。
知っておくべき注意点(デメリット)
もちろん、万能ではありません。以下の点には注意が必要です。
- シングルスレッドである
- 基本的に一度に1つのリクエストしか処理できません。重い処理中に別のタブでアクセスすると、前の処理が終わるまで待たされます。
- アセット(画像やCSS)が多いページだと、読み込みが遅く感じることがあります。
- セキュリティ機能が皆無
- 公式が警告する通り、外部に公開するサーバーとしては脆弱すぎます。あくまで「ローカル開発」「検証」の範囲に留めましょう。
- HTTPSが使えない
- 最近はブラウザのセキュリティ制約で「HTTPS必須」の機能(Geolocation APIの一部やService Workerなど)も増えています。そういった機能の検証には向きません。
まとめ
PHPビルトインサーバーは、XAMPPやDockerの代わりになるものではありません。 しかし、「ちょっとした検証」「APIテスト」「ツール作成」 という文脈においては、これ以上ないほど強力な味方です。
- Docker: 本番環境に限りなく近い環境が必要なとき
- ビルトインサーバー: スピード重視で、ロジックやAPIの挙動だけサクッと確かめたいとき
こんな風に使い分けると、開発のストレスがグッと減るはずです。
「食わず嫌い」していた方は、ぜひ一度ターミナルで php -S と叩いてみてください。その軽快さに驚くと思いますよ。