RailsからPhoenixへ：AIツールが変えた私の技術スタック

この1年で、個人プロジェクトのスタックは曲がりくねった道を辿りました：素のRailsとHotwire → RailsとInertia、React → Phoenix LiveView。

Railsは今でも素晴らしいフレームワークですが、Phoenixを探求する中で—特にTidewave.aiのようなAIツールと一緒に使うことで—自分の個人プロジェクトに最適なスタックを再考するようになりました。

ここまでの道のり：HotwireからReactへ

Railsでインタラクティブなサイドプロジェクトを構築する際：

Hotwire：サーバーレンダリングの哲学は気に入っていましたが、複雑なUIウィジェット（コンボボックスや多状態ダイアログ）を構築するのは、CSSスキルが限られているため苦痛でした。
Rails + React（Inertia.js）：Reactに移行したことでshadcn/uiを利用でき、AIによる高速なコンポーネントプロトタイピングが可能になりました。しかし時間が経つにつれて、React疲れが襲ってきました：クライアントとサーバーの境界をまたぐ状態管理、Node.jsビルドパイプラインの処理、そしてRubyとTypeScriptの間での絶え間ないコンテキスト切り替え。

私はサーバーレンダリングHTMLの単一言語シンプルさを求めつつも、現代的なリアルタイムインタラクティブ性と、優れたデフォルトUIコンポーネントも欲しかったのです。

Phoenix LiveViewがしっくりきた理由

1. 単一パラダイム、ビルドステップ不要

LiveViewのメンタルモデルは明快です：状態はサーバープロセス（軽量なBEAMプロセス）に存在し、UI更新はWebSocket接続を通じてストリーミングされます。

クライアント側の状態同期ライブラリも、RESTやGraphQLのグルーコードも、待つべきフロントエンドバンドルのコンパイルもありません。すべてがElixirで書かれています。

2. 組み込みのTailwindとDaisyUI

PhoenixにはTailwind CSSとDaisyUIが最初から同梱されています。DaisyUIのデフォルトの見た目が万人向けとは言えませんが、あらかじめ配線されたスタイル済みコンポーネント（タブ、モーダル、アラート、バッジ）があることで、私をReactへと駆り立てたスタイリングのボトルネックが解消されました。

3. AIコード生成との相性が良い

これは予想外の部分でした。Claude CodeやTidewave（Phoenix向けに特化したMCPツール）のようなAIコーディングツールを使うと：

単一コンテキスト：LiveViewコンポーネントは状態、ライフサイクルコールバック、HTMLテンプレートをElixir内にカプセル化するため、AIはコントローラーやシリアライザー、Reactコンポーネントにまたがるのではなく、1つのファイルに全コンテキストを持てます。
明示的な状態とパターンマッチング：Elixirの関数型の性質とイミュータブルなデータ構造により、ビジネスロジックが明確になります。AIモデルは、多層的なJavaScriptの状態グラフよりもElixirの方が、幻覚による状態バグを生み出す傾向が少ないです。

最近の個人プロジェクトでは、Tidewaveが高レベルの機能プロンプトに基づいてLiveViewのCRUDとUIワークフローのほぼ全体を生成し、デバッグは最小限で済みました。

トレードオフ

Phoenixにも摩擦がないわけではありません：

エコシステムの規模：Railsのエコシステムは巨大で、ニッチなサードパーティサービスとの統合が必要な場合、Railsにはほぼ確実に成熟したgemがあります。Elixirでは、時々自分でラッパーを書く必要があります。
学習曲線：関数型プログラミング、OTP、パターンマッチングは、オブジェクト指向のRubyに長年携わってきた場合、考え方の転換が必要です。

まとめ

Phoenix LiveViewへの移行により、個人開発において両方の良いところを得られました：Reactから欲しかったコンポーネントの便利さと、バニラRailsで懐かしく思っていたサーバーレンダリングの単一言語のシンプルさを兼ね備えています。開発速度とメンテナンスの負荷の低さを最優先する個人プロジェクトでは、これが私の頼りになる選択肢になりました。