ActionViewを外したRailsビューの行方：Inertia/Reactと小さな構成

背景

ERBはよく設計されている。読み込み順序が見通せず崩れるタイプのスパゲッティではないし、長く積み上げた資産があるならそのまま使い続ける理由もある。ただ、コードベースが50万行程度までの小さなサービスでは、別の選択が現実味を帯びてきた。

何を残し、何を外すか

Railsの泣き所はヘルパやデコレーターの散在にある。ViewComponentで整えようとしても、分岐の重さは残りやすい。Turboが目指したバインディングも、HTMLとJSの境界をまたぐ調整が続く。ここをすべて外し、Reactに渡す役割に徹する構成に寄せると、責務の境界が一線で引きやすくなる。

パーシャルも同じだ。歴史があるコードベースでは「これは何か」「消してよいか」が判然としない断片が積み上がる。うっかり消せば実行時に落ちるし、RSpecで守れることもあるが、テストを書けない人や創業メンバー以外が重ねたコードほど乱れやすい。サーバ側のフラグメント依存を減らし、画面側に構造を集約することで、この揺らぎを減らせる。

小さなサービスでの選択

ActionViewを捨て、TSXに渡すだけのコントローラにすれば、レンダリングの層が消え、メモリとレイテンシの揺らぎも減る。Inertiaを使えばルーティングや認証はRailsのまま、APIクライアントも薄いままにできる。UIはTSXのコンポーネントで組み替え、サーバはJSONとリダイレクトだけに集中する。小さなチームでも流れが単純化し、速度の落ち込みを避けやすい。

境界とAI

境界が整っていれば、LLMのコーディングエージェントにERBからTSXへの移し替えを任せられる。渡す契約だけを明示し、既存のビューを写経させるだけで、古いUIを一気に現代化できる。手作業でヘルパやデコレーターを追うより、境界を示し、AIに変換させる方が筋がよい。

余白

ActionViewはかつて小さな組織に寄り添ったが、今は別の道もある。資産が豊富で人員も多いならERBを使い続ければよい。小さなリソースで速度を優先するなら、ActionViewを終わらせ、ReactとAIに委ねる方が呼吸が合うと思う。