事業オーナーのための〝後悔しない技術選定〟
「HTMLだけ見ていたい」という感覚には、ソフトウェア工学の正式な名前がある。その名前と、対立するもう1つの原則、Livewireが連なる大きな潮流、そして〝オワコン〟と言われがちなPHPの立ち位置まで——事業オーナーが後悔しない技術選定をするための判断材料を揃える3部作の最終話。
最後にもう一度、言い切っておく。事業オーナーがAIにコードを書かせるなら、TALLスタックがいい。 AIが書いたコードが管理不全に陥らず、本格的なアプリを理解しながら伴走できるハードルが一番低いからだ。この3部作の最終話では、その理由の理論的な裏付けと、この先の可能性を語る。
「HTMLだけ見ていたい」には、実は名前があった
第2話で語った「HTMLだけ見て、全部わかっていたい」という体験。これはソフトウェア工学の世界で、Locality of Behaviour（LoB・局所性）と呼ばれている。
- 名付け親は、htmxというツールを作った Carson Gross
- 元ネタは、Richard Gabrielという研究者の言葉「保守のしやすさを決める一番の要因は、局所性だ」
対して、ソフトウェア工学にはもっと古くからSeparation of Concerns（SoC・関心の分離）という原則がある。「見た目はCSSファイルへ、挙動はJSファイルへ、種類ごとにきちんと分けるべき」という考え方だ。
面白いのは、この2つは対立する、とGross自身がはっきり言っていること。
SoCを徹底すると、ある要素の見た目や挙動が遠く離れたファイルの中身次第でガラッと変わる、という現象が起きる。Grossはこれを「幽霊のような遠隔操作（spooky action at a distance）」と呼んで批判した。TALLスタックが選んでいるのは、この対立の中でLoB側だ。
トリックの種明かし：「まとめる」のに「絡まない」理由
ここで、ずっと気になっていた疑問に答えたい。1箇所に集めているのに、なぜ密結合にならないのか。
答えは、「まとめること」自体がトリックなのではなく、まとめる対象そのものが、外の世界と絡まない語彙でできているからだ。
- Tailwindのユーティリティクラス（
bg-primary）は、他に何が付いているか・DOMのどこにあるかに関係なく、意味が固定されている - Livewire/Alpineのディレクティブは、自分がついた場所の中だけにスコープが閉じている
昔ながらのCSS（.card-header）や、昔ながらのjQuery（$('.foo').on(...)）は、遠くの別ファイルが、不特定多数の要素を横断的に握るという構造だった。これこそが密結合の正体だ。TALLスタックは、この「遠くから握る」仕組みそのものを捨てて、「その場で完結する語彙」に置き換えている。まとめても絡まないのは、絡む余地のある道具を最初から使っていないから、というのが正しい理解になる。
Livewireは孤立した変わり者じゃない
ここまでの話を聞くと「PHPの、しかもLaravelというフレームワークだけの、ローカルな工夫」に聞こえるかもしれない。実際は違う。これはもっと大きな潮流の一角だ。
| 呼び方 | 言語/基盤 | 誰が |
|---|---|---|
| Hotwire / Turbo | Ruby (Rails) | DHH（Railsの作者。むしろLivewireより先行） |
| Phoenix LiveView | Elixir (BEAM) | José Valim周辺 |
| Livewire | PHP (Laravel) | 今回の主役 |
| htmx | 言語非依存 | Carson Gross |
これは「ハイパーメディア駆動アプリケーション」「HTML over the wire」と呼ばれる潮流で、2013〜2020年頃の「何でもSPA化しよう」という時代への反動として広がった。TALLスタックは、この潮流のLaravel/PHPにおける表現形だ。
Livewire vs Inertia：正直な比較
Livewire愛を語る前に、フェアな比較をしておきたい。同じLaravelエコシステムには、Inertia.jsという選択肢もある（VueやReactでSPAを組みつつ、Laravelの資産をそのまま使う仕組み）。
| 観点 | Livewire (wire:navigate) | Inertia.js |
|---|---|---|
| 状態の置き場所 | サーバー | クライアント |
| 永続化不要な一時的UI操作（未保存のドラッグ・開閉トグル等） | Alpine.jsでクライアント完結 | クライアントだけで完結 |
| 永続化が必要な操作 | サーバー通信が必須 | 同じくサーバー通信が必須 |
| 学べば済む言語 | PHPだけ | PHP + Vue/React等 |
| SEO/クロール対応 | 標準で健全 | SSRを別途足す必要あり |
| 既存アプリへの導入コスト | ほぼゼロ（属性を足すだけ） | Bladeの書き直しが必要 |
「SPAこそモダンアプリの常識」とされる昨今、Inertia（＝SPA）の方が体感的に高速だと思われがちだ。だが、それは正確ではない。永続化すべきデータに関しては、体感差は原理的に存在しない。 LivewireだろうとInertiaだろうと、永続化するデータは結局サーバーとの通信が必要になるからだ。体感差が生まれるとしたら、それは保存の必要がない一時的なUI状態（ドラッグ中の座標、開閉トグルなど）に限られ、そこはLivewireでもAlpine.jsで完結させれば同じ話になる。
体感速度という〝コスト〟が実質存在しないなら、話は単純だ。私がLivewireを選ぶのは、「覚える言語が1つで済む」ことの複利効果が、パッケージャーとして事業を回す上で圧倒的に効いてくるからだ。第2話で語った「学習コストの低さが保守・拡張・エコシステムに永続的なリターンを生む」という話は、ここでもそのまま当てはまる。
Livewireには、ページ遷移の体感をさらに底上げするwire:navigateという機能もある。リンクに属性を1つ足すだけで、ページ遷移がフルリロードではなくAJAX的な差し替えになる仕組みだ。サーバー側の設計思想（PHPだけで完結）を変えずに、遷移の滑らかさだけを上乗せする——これもまた、TALLらしい「足し算」の解決だと思う。
おじさんプログラマへ：PHPは〝オワコン〟なのか
正直に、痛いところから話す。PHPは今、業界的にあまりカッコいい扱いをされていない。 PythonがAI/ML分野を席巻し、スタートアップの話題はGo・Rust・TypeScriptに集まる。「PHPなんて今どき」という空気を、感じたことがある人は少なくないはずだ。私自身、その悲哀を否定しない。
でも、ここで視点を反転させたい。「オワコンに見えるほど古くから使われている」ということは、それだけ長く磨かれてきた、という意味でもある。
- Composer（PHPのパッケージ管理）には、何十万というパッケージが積み上がっている
- Laravelエコシステムは、Livewire・Filament・Pest・Horizonなど、成熟した公式/準公式ツールが揃っている
- PHP 8系ではJITコンパイラも入り、パフォーマンスも着実に改善している
これは第1話の「パッケージャー」の話に直結する。成熟したエコシステムとは、パッケージング可能な部品が豊富にある、ということだ。 「枯れている」は悪口ではなく、「組み合わせられる部品の在庫が多い」という意味でもある。
ちなみに、Phoenix LiveViewを支えるElixirも、PHPと同じ動的型付け言語だ。「ゆるふわな型付けが好き」という感覚は、実はPHPだけの特権ではない。違うのはパラダイム（PHPの手続き型/OOP vs Elixirの関数型）であって、型のノリではない。ここは誤解されがちなので、正確に書いておきたい。
「エレガント」は「わかりやすい」とは限らない
同じ処理を、両方の言語で書いてみる。「ユーザーに名前があれば挨拶、なければ「見知らぬ人へ」の挨拶」というだけの、単純な分岐だ。
// PHP：もし〜なら、を素直に書く
function greet($user) {
if (isset($user['name'])) {
return "Hello, {$user['name']}";
}
return "Hello, stranger";
}
# Elixir：受け取る形の違いで、関数そのものを複数定義する
def greet(%{name: name}), do: "Hello, #{name}"
def greet(_), do: "Hello, stranger"
この記事を書きながら、身近な人にElixir側のコードを見せてみた。返ってきた反応はこうだった。
「技術者的にはelegantだけど、わかりにくい。一般的な感覚だと、これはぎょっとするよ。」
正直、これはその通りだと思う。PHPのif/issetは、スプレッドシートのIF関数でも日常会話でも使う、誰もが最初から持っている思考の型に乗っかっている。対してElixirの「関数を形違いで複数定義する」というやり方は、日常のどこにも似た経験がない、まったく新しい思考の型を一から獲得する必要がある。
技術者が「エレガント」と感じるのは、慣れた後に無駄がなく筋が通っていると分かるからで、それは初見のわかりやすさとは別の軸の評価だ。この「ぎょっとする」という率直な一次反応こそ、第2話で語った「学習コストの低さ」の生きた証拠だと思う。
TALLの、これからの可能性
最後に、少し先を見る。
Elixir/Phoenix LiveViewの優雅さは、「接続ごとに専用の長生きプロセスをメモリに持ち続けられる」という、BEAMという実行基盤そのものの性質から来ている。PHPの伝統的な実行モデル（リクエストごとにプロセスが立って死ぬ）は、この点で本質的に不利だ。Livewireは、状態をシリアライズしてブラウザに預け、また受け取って復元する、という力技でこれを埋めている。Laravel Octane（PHPプロセスを常駐させて高速化する仕組み）のような取り組みが、この溝を少しずつ埋めてきているのも事実だ。
だが何よりも、TALLの未来は、AIが生み出すコードを人間が制御し、長期的に保守・運用・拡張していけることを、一番低コストで実現できる点にある。冒頭で言い切った通りだ——事業オーナーがAIにコードを書かせるなら、TALLスタックがいい。LoBという設計原則によって「1箇所を見れば全体がわかる」状態が保たれ、PHPという誰もが最初から持っている思考の型に乗っているからこそ、AIが書いたコードであっても人間が読み、直し、育てていける。これこそがTALLの未来だ。
3部作のまとめ
- 第1話：AI時代のぼくらは、部品を選び組み合わせるパッケージャーだ
- 第2話：TALLスタックの価値は学習コストの低さであり、それが保守・拡張・エコシステムに複利で効いてくる
- 第3話：その体験にはLocality of Behaviourという名前があり、Livewireはこの潮流の一角であり、PHPという〝オワコン〟扱いされがちな言語こそ、パッケージャーに部品を提供し続けてくれる厚みを持っている
事業オーナーがAIにコードを書かせるなら、TALLスタックがいい。 本格的なアプリを理解しながら、AIと共に、長く歩いていける——そのハードルの低さこそが、この3部作を通して語りたかったことだ。