Elixir/Phoenixの現在地 - LiveView、OTP、Phoenix 1.8

8分 で読める | 2026.01.12

公式ドキュメント
プログラミングWeb開発Network

ElixirはErlang VM（BEAM）上で動作するプログラミング言語です。PhoenixはElixir製のWebフレームワークで、通常のHTTP処理に加え、ChannelsやLiveViewを利用した双方向通信・画面更新を提供します。

この記事の結論

記事情報: 2026年1月12日初出。本文は2026年7月25日にElixir・Phoenix・LiveViewの公式資料で再確認しています。

Elixir/Phoenixの特徴は、「同時接続数の大きな数字」だけでは説明できません。BEAM上の軽量プロセス、メッセージ送受信、Supervisorによる監視を組み合わせ、失敗する処理を分離しながらアプリケーションを動かす設計にあります。

Phoenix LiveViewを使うと、主要な画面状態をサーバー側のElixirで管理し、接続後は差分をクライアントへ送ってUIを更新できます。ただしJavaScriptが不要になるわけではなく、ブラウザ固有APIや高度なクライアント側操作にはJavaScript Hookなどを使います。

BEAMのプロセスを理解する

ElixirのプロセスはOSプロセスとは異なり、BEAMが管理する軽量な実行単位です。それぞれが独立した状態を持ち、メッセージを送受信します。

parent = self()

spawn(fn ->
  send(parent, {:completed, 42})
end)

receive do
  {:completed, value} ->
    IO.puts("result: #{value}")
after
  1_000 ->
    IO.puts("timeout")
end

spawn/1は新しいプロセスを作り、send/2は対象プロセスのmailboxへメッセージを送ります。receiveはパターンに一致するメッセージを処理します。この仕組みにより、共有メモリを直接書き換える設計とは異なる形で並行処理を組み立てられます。

ただし、プロセスを作るだけで耐障害性が完成するわけではありません。予期せず終了した処理を誰が検知し、どの条件で再起動するかを設計する必要があります。

OTPとSupervisor

OTPは、Elixir/Erlangアプリケーションで長時間動く処理や監視構造を作るためのライブラリと設計原則です。Supervisorは子プロセスを起動し、終了時の再起動方針を適用します。

children = [
  {Task.Supervisor, name: MyApp.TaskSupervisor},
  MyApp.Worker
]

Supervisor.start_link(
  children,
  strategy: :one_for_one,
  name: MyApp.Supervisor
)

:one_for_oneでは、終了した子だけを再起動します。ほかにも、ある子の終了後にそれ以降の子を再起動する:rest_for_one、すべてを再起動する:one_for_allがあります。

再起動はエラーを隠す機能ではありません。同じ入力で即座に失敗し続けると、Supervisorは再起動強度の上限に達して自身も終了します。外部サービス障害ならbackoffを入れる、恒久的な入力エラーなら再試行しない、状態復元が必要なら永続化先を決める、といった設計が必要です。

Phoenixが担当する範囲

Phoenixはルーティング、Controller、HTMLコンポーネント、PubSub、Channelsなどを提供します。一般的なHTTPリクエストはRouterからpipelineを通り、ControllerやLiveViewへ渡されます。

Phoenixプロジェクトでは、Web層と業務ロジックを分ける「context」が重要です。ControllerやLiveViewからデータベースへ直接アクセスする処理を増やすより、たとえばAccountsやCatalogのようなcontextへ操作をまとめると、HTTP以外の処理やテストからも呼びやすくなります。

defmodule MyApp.Catalog do
  import Ecto.Query
  alias MyApp.{Repo, Catalog.Product}

  def list_products(limit \\ 20) do
    Product
    |> order_by([product], asc: product.id)
    |> limit(^limit)
    |> Repo.all()
  end
end

Ectoはデータ検証、クエリ、データベース操作を担う別ライブラリです。Phoenixと一緒に使われることが多いものの、Phoenixそのものと同一ではありません。

LiveViewの画面更新

LiveViewは、最初のHTTPレスポンスでHTMLを返し、その後は接続を確立してサーバー側の状態変化を画面へ反映します。開発者はmountで初期状態を設定し、イベントをhandle_eventなどで処理します。

LiveViewの接続後、ブラウザの操作をサーバーへ送り、サーバー側の状態更新に応じた画面の差分をブラウザへ返す図

defmodule MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

  def mount(_params, _session, socket) do
    {:ok, assign(socket, count: 0)}
  end

  def handle_event("increment", _params, socket) do
    {:noreply, update(socket, :count, &(&1 + 1))}
  end

  def render(assigns) do
    ~H"""
    <button phx-click="increment">Count: {@count}</button>
    """
  end
end

この例ではボタン操作をサーバーへ送り、更新後の状態から必要な差分が描画されます。フォーム、検索、管理画面など、サーバー側データと密接なUIで選択肢になります。

一方、接続品質の影響を受ける操作、オフライン中心のアプリ、ブラウザ内で高頻度に描画する処理は、クライアント側実装が適する場合があります。LiveViewを採用するかは「JavaScriptを書かずに済むか」ではなく、状態をサーバーに置く設計が用途に合うかで判断します。

Phoenix 1.8の主な変更

Phoenix 1.8.0は2025年8月5日に正式リリースされました。公式発表で挙げられた主な変更は次のとおりです。

  • 新規プロジェクトにElixir/Phoenix向けのAGENTS.mdを生成
  • Tailwind CSS連携へdaisyUIを加え、ライト・ダークテーマを初期提供
  • phx.gen.authがmagic link認証を既定で生成
  • 認証済みユーザーや組織などを渡すscopeのパターンを導入
  • generatorとlayoutを簡素化

なかでもscopeは、現在のユーザーや組織をcontext関数の第1引数へ渡し、クエリやPubSubをその範囲へ限定するための構造です。

def list_posts(%Scope{} = scope) do
  Repo.all(
    from post in Post,
      where: post.user_id == ^scope.user.id
  )
end

これは認可を自動的に完成させる魔法ではありません。scopeに何を含めるか、管理者操作をどう分けるか、URLのIDを変更されたときにもcontext側で範囲を絞れるかをテストします。

Phoenix 1.8はErlang/OTP 25以降を必要とします。既存アプリの更新ではElixir、Erlang/OTP、Phoenix、LiveView、関連ライブラリの対応版をまとめて確認してください。

採用時に見るポイント

Elixir/Phoenixが合いやすいのは、多数の独立した接続やジョブを扱い、リアルタイム更新と障害分離を重要視するサービスです。LiveViewは、サーバー中心の画面状態とHTMLベースのUIが合う場合に開発範囲をまとめやすくします。

一方で、採用言語を増やす運用コスト、チームの学習時間、依存ライブラリ、監視・デプロイ環境も判断材料です。BEAMのプロセスやSupervisorを理解せず、RubyやNode.jsと同じ構造をそのまま移しても特徴を生かしにくくなります。

小さな検証では、次を確認すると判断しやすくなります。

  1. 通常のHTTP画面とLiveView画面を1つずつ作る
  2. DB接続を含むcontextのテストを書く
  3. WebSocket切断と再接続時のUIを確認する
  4. Workerを意図的に失敗させ、Supervisorの再起動を観察する
  5. ログ、メトリクス、デプロイ、ロールバックまで試す

性能の採用事例や接続数だけで結論を出さず、実際の業務処理とチーム構成で評価してください。Elixir/Phoenixの中心価値は、BEAMとOTPの考え方をWebアプリの構造へつなげられる点にあります。

参考リソース

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR