前回 は、WordPress Playground をきっかけに WebAssembly（WASM）と php-wasm を知り、サーバー側に PHP を用意せずに「お散歩トラッカー」を試作してみました。
ただ、「PHPをブラウザで動かせる」という技術的な興味や、実際にアプリを作ってみるところが中心で、「実務の場合に何がうれしいの？」というメリットについて触れていませんでした・・・。
ですので、今回は続きとして
「すでにPHPサーバーがある案件に、php-wasm を別用途で使えると何がうれしいのか？」
という視点で考えてみます。
さきに結論から言うと、php-wasm を本番環境の完全な代替とすることは難しそうです。実務で期待どおりに使えるのは、現状では次の2点に集約されると思います。
- サンドボックス — 本番とは切り離した検証環境（WordPress ならテーマ／プラグインの確認程度）
- 小さなデモ／ツールの公開 — PHP-FPM 用サーバーを増やさず、静的配信＋ブラウザ内 PHP でデモやツールを公開する
php-wasm は「PHP サーバーをなくす技術」ではなく、「PHP 用サーバーを増やさず、本番とは別用途で PHP を動かす技術」 です。
１）既存案件との距離感
⚪︎本番・ステージングの代替ではない
普段の PHP 案件では、Apache、PHP-FPM、MySQL など、サーバー側で PHP が動いています。php-wasm は ブラウザ内で動く別系統の PHP 実行環境であり、PHP-FPM に追加する拡張でも、本番 PHP の代わりでもありません。
そのため、本番 DB にそのままつなぐ、本番と同じ PHP 拡張・サーバー設定を再現する、いま動いているシステムを wasm 上でそのまま試す etc. といった使い方は現実的ではありません。VPS やレンタルサーバーなど、仮想ホスト上の Apache + PHP-FPM + MySQL 構成とも、php-wasm は別系統として切り分けて考える必要があります。
⚪︎既存の PHP コードが全部そのまま動くわけでもない
DB、curl 、特定の PHP 拡張、サーバー上のファイルパスなどに依存するコードは、ブラウザ上の php-wasm とは相性がよくありません。たとえば、次のような話は、現状では難しそうです。
- 既存のPHPフレームワーク / CMS の本番を wasm で再現して検証する
- 既存画面から処理を切り出して、後付けで wasm に載せ替える
- PHP バージョンアップ前に、既存環境を wasm 上の別 PHP バージョンで試す
２）実務で使えそうなケース
⚪︎サンドボックスとして使う
php-wasm 系の環境は、本番・ステージングとは別の、切り離された検証環境として使えます。
ここで言うサンドボックスは、「いま本番で動いている案件そのもの」を丸ごと試す環境ではありません。中身は別の PHP 実行空間（ブラウザ内）です。本番を汚さず、別の場所で触ってみる etc. という用途に向いています。
WordPress案件の場合であれば、以下くらいまでが現実的なところだと思います。
- テーマ改修後の表示確認
- プラグイン同士の組み合わせ確認
- デモや学習用に、ブラウザだけで触れる WordPress 環境の用意
⚪︎小さなデモ／ツールの公開
PHP で新しく何かを公開しようとすると、VPS やレンタルサーバー、PHP-FPM、DB etc. と準備がついて回ります。
php-wasm を使えば、PHP の処理をブラウザ内で完結できるものは、静的ホスティング（Cloudflare Pages など）に載せて公開できます。前回のお散歩トラッカーがこのパターンです。
ここで言う「サーバー不要」とは、PHP-FPM など PHP 用のアプリサーバーを新たに用意しなくてよいという意味です。インフラがゼロになるわけではありません。
- 静的ファイルを配信する場所（Pages など）は必要
- 外部 API を使う場合は、CORS 回避などのためにプロキシ用 Functions が必要になることもある
加えて、php-wasm 本体（ .wasm ）は十数 MB 級で、初回の読み込みは重め、というトレードオフもあります。
お散歩アプリでは、アプリの PHP はブラウザ内で動いています。Overpass API 向けには、PHP サーバーではなく Cloudflare Pages Functions を1本だけ置いています。
こちらも次くらいまでが現実的と考えます。
- 提案用の動くデモ（本番とは別物）
- 小さなブラウザツール（計算・変換など、DB 不要なもの）
- @php-wasm で作った小さなアプリ（お散歩トラッカー型）
前回のお散歩トラッカーは JSON ファイルでセッションを保存するシンプルな構成でしたが、フォームや軽い CRUD 程度なら、php-wasm 内の SQLite を使い、データの永続化に OPFS や IndexedDB などブラウザ側の保存と組み合わせたアプリケーションも作成可能かと考えます。
３）まとめ
触ってみて分かったのは、php-wasm は「PHP サーバーをなくす技術」ではなく、本番環境とは別用途の PHP 実行環境を置ける技術だということです。サンドボックスで触るか、小さなデモやツールを出すか・・・実務でうれしいのは、だいたいこの2つに収まりそうです。
正直、既存の LAMP 案件を wasm で置き換える話は、まだ現実的ではないと思います。本番 DB や拡張、サーバー設定まで再現するのは別世界です。前回のお散歩アプリも、最初から wasm 前提で役割分担した別物だったからうまくいった、という感じです。
前回は「動かしてみた」話でした。今回は「実務ではどこまで使えそうか」を整理してみました。万能ではないけれど、切り分けて使う分には、ちゃんと役に立つ技術だと思っています。
