モダン Elixir & Phoenix 2026 — Elixir 1.18 / Phoenix 1.8 / LiveView 1.0 / Oban / Broadway / Bumblebee / Nx / Livebook 徹底ガイド

プロローグ — 30 年もののVM が 2026 年に再注目される理由

Elixir は新しい言語ではない。2012 年に José Valim が Erlang/OTP の上に人間にやさしい構文を載せて始めた。そしてその Erlang は 1986 年にエリクソンで電話交換機のために生まれた — つまり BEAM（Erlang VM）は実質 40 歳である。

2026 年、その 40 歳の VM があらためて注目されている。理由は一行で言える。

「並行性・分散・耐障害性を初日から組み込んだ VM は BEAM だけで、マルチコア・リアルタイム・AI 推論の時代がついにそちらの形を強いている。」

Elixir 1.18（2024 年 12 月） — set-theoretic types の初プレビュー。漸進的静的型付けの道が開いた。
Phoenix 1.8（2024 年 12 月） — Scope API で認証コンテキストを関数シグネチャに刻み、daisyUI と Tailwind v4 がデフォルトに。
LiveView 1.0（2024 年 11 月） — 5 年超の 0.x ベータを経て、ついに正式 1.0。サーバ描画 HTML とリアルタイム双方向通信を一つの抽象に。
Bumblebee + Nx + Axon — Hugging Face Transformer モデルを Elixir 上で動かし、GPU 加速まで効かせる。
Tidewave（2025 年 9 月） — José Valim が公開した Elixir 用 LLM サービングプラットフォーム。BEAM 上で LLM を配る。

本稿は 2026 年の Elixir スタックを最初から最後まで — VM のアクターモデルから LiveView、Oban、Broadway、Membrane、Bumblebee、Tidewave、そして韓国・日本の採用事例まで — 一読でまとめる。

1 章・なぜ BEAM か — アクター・ソフトリアルタイム・耐障害性

最初にはっきりさせる。Elixir が魅力的な理由の半分は 言語そのもの ではなく、その下の VM にある。

BEAM の三本柱。

軽量プロセス（アクター） — 一ノードに数百万のプロセスが共存する。各プロセスはメモリ（既定で約 2 KB のヒープ）とメールボックスを持つ独立した単位。OS スレッドではない。
プリエンプティブスケジューリング — スケジューラが一定 reduction ごとにプロセスを強制スワップする。一つのプロセスが無限ループしても他が餓死しない — これが「ソフトリアルタイム」。
let it crash + スーパーバイザツリー — プロセスが死ぬと隔離単位の中で死に、上のスーパーバイザがあらかじめ宣言した戦略（one_for_one、rest_for_one ほか）で再起動する。防御コードの代わりに回復コードを書く。

絵にするとこうなる。

                  [Application Supervisor]
                          |
            +-------------+-------------+
            |             |             |
     [DB Pool Sup]   [Web Sup]    [Worker Sup]
            |             |             |
       [Pool Worker]  [Endpoint]   [Job Worker x N]
                          |
                   [LiveView Conn x M]

このツリー一枚で Elixir アプリの運用はほぼ説明がつく。LiveView 接続が一つ落ちてもその接続だけが死ぬ。DB プールが揺らげば Pool Sup が立て直す。ワーカーが OOM すれば Worker Sup が新しいのを立てる。

覚える一行：「BEAM は死なない VM ではなく、死んでも大丈夫な VM である。」

2 章・Elixir 1.18（2024 年 12 月）— set-theoretic types プレビュー

2024 年 12 月 19 日にリリースされた Elixir 1.18 は、それ自体で十分大きな出来事である。

2.1 set-theoretic types — 漸進的静的型付けへの一歩

長年 Elixir 利用者からの最頻質問は「なぜ静的型がない」だった。答えは (1) Dialyzer がある (2) BEAM の並行性とホットコードリロードは動的型と相性が良い、の 2 つだった。コアチームはその答えがもう十分でないと判断した。

1.18 は本格的な答えの第一歩である。set-theoretic types を関数シグネチャとパターンマッチに適用し始めた。union（A or B）・intersection（A and B）・negation（not A）を第一級として扱う型システム。

# コンパイラが自動推論 — アノテーションなしで
defmodule Numbers do
  def add(x, y) when is_integer(x) and is_integer(y), do: x + y
  def add(x, y) when is_float(x) and is_float(y), do: x + y
end

# 不正な呼び出しはコンパイル時に検出
Numbers.add(1, 2.0)
# warning: incompatible types — integer/float の組のいずれにも属さない

今はとても限定的な範囲（シグネチャ・パターンマッチ・一部ガード）だが、ロードマップ上は 1.19〜1.20 で本格的な型注釈構文が入る。

2.2 mix の改善

1.18 は mix にも手を入れた。mix test --partitioned が安定化、mix format が prettier 風に import 整列まで対応、mix deps.tree が SAT ソルバ診断を出して依存衝突の原因を示す。

2.3 Elixir のバージョン方針

Elixir は意図的に 1.x を長く引っ張る。2.0 が出る可能性は低い。代わりに毎年 12 月に 1.x のマイナーリリースを出す — 1.15（2023）、1.16（2024 初頭）、1.17（2024 中頃）、1.18（2024 末）、1.19 は 2025 年 12 月予定。

3 章・Phoenix 1.8（2024 年 12 月）— Scope API、daisyUI デフォルト

Phoenix は Elixir の標準 Web フレームワーク。Rails の比喩で入る — コントローラ・ビュー・ルータの構造は似ている — が、核は別物。Phoenix は LiveView を一級 に置き、Plug ミドルウェアの上に乗り、PubSub でノード間メッセージをルーティングする。

3.1 Scope API — 認証コンテキストを関数シグネチャに刻む

1.8 の目玉は Scope。従来は認証済みユーザを conn.assigns.current_user から取り出し、これがコントローラ内でしか使えなかった。Scope はそのユーザ（と所属する organization や tenant）を第一引数として明示的に受ける。

defmodule MyApp.Posts do
  alias MyApp.Accounts.Scope

  # スコープを第一引数に — 認証コンテキストがシグネチャに刻まれる
  def list_posts(%Scope{user: user, org: org}) do
    Post
    |> where(org_id: ^org.id)
    |> where(author_id: ^user.id)
    |> Repo.all()
  end

  def create_post(%Scope{} = scope, attrs) do
    %Post{}
    |> Post.changeset(attrs)
    |> Ecto.Changeset.put_change(:org_id, scope.org.id)
    |> Repo.insert()
  end
end

なぜ重要か？ コントローラだけでなく、LiveView、Oban ジョブ、バックグラウンドタスク、GenServer まで同じ認証コンテキストを一貫して受け取れる。 従来は LiveView が mount で user を別途 assign しなければならず、Oban ジョブは args に user_id を入れて再 fetch する必要があった。

3.2 daisyUI + Tailwind v4 がデフォルト

1.8 から mix phx.new の既定 UI スタックは Tailwind v4 + daisyUI。Heroicons も既定。特別な設定なしに即座にモダンな UI が立つ。

# 1.8 既定テンプレート
<.button class="btn btn-primary" phx-click="save">保存</.button>
<.input field={@form[:title]} class="input input-bordered" />

以前は Tailwind だけで、コンポーネントは自作だった。1.8 は daisyUI のコンポーネントクラス（btn、card、modal、alert など）を即使える。

3.3 新規プロジェクト作成

mix archive.install hex phx_new
mix phx.new my_app --live   # LiveView 同梱
cd my_app
mix ecto.create
mix phx.server

この 4 行で LiveView・Tailwind v4・daisyUI・Ecto・Postgres が揃ったプロジェクトが 4000 番ポートで立ち上がる。

4 章・LiveView 1.0 — 5 年のベータの先にある正式リリース

LiveView は Elixir の代表技術である。2018 年の ElixirConf で Chris McCord がデモして以来、5 年超の 0.x ベータを経て 2024 年 11 月に 1.0 が正式リリースされた。

4.1 LiveView が解く問題

既存の SPA（React、Vue）スタックの恒常的コストは 2 つ。

API を二度作る — REST/GraphQL バックエンド + それを呼ぶフロント。
状態同期 — サーバ状態とクライアント状態が分かれ、その差がバグの根源。

LiveView はこの両方を消す。状態はサーバだけにある。UI はサーバで描画した HTML が WebSocket でプッシュされる。 ユーザイベント（click、submit、keypress）は WebSocket でサーバに戻り、サーバが状態を変更して変わった DOM の一部だけを再 push する。

defmodule MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

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

  def handle_event("inc", _params, socket) do
    {:noreply, assign(socket, count: socket.assigns.count + 1)}
  end

  def render(assigns) do
    ~H"""
    <div>
      <h1>カウント: <%= @count %></h1>
      <button phx-click="inc" class="btn btn-primary">+</button>
    </div>
    """
  end
end

これで全部だ。100ms 以内にサーバ往復が起き、変わったテキストノードだけが patch される。JS は一行も書いていない。

4.2 1.0 の主な変更

Streams — 大量リストの効率的な更新。追加/削除/移動をサーバが宣言し、クライアントは DOM キーだけで処理する。無限スクロールのニュースフィードをメモリ爆発なしに作れる。
Async assigns — assign_async(:user, fn -> ... end) で非同期データ読み込みが一級市民に。Suspense ライクな UX。
Function components + slots — React の children prop と同じスロットパターンが安定化。
JS Commands — 単純なトグル/非表示/フォーカスはサーバ往復なしに JS.toggle("#menu") のようなクライアント側コマンドで処理。

4.3 LiveView が向かないケース

LiveView は万能ではない。

オフラインファースト PWA — WebSocket が切れたら使えない。
極端にインタラクティブな UI — 60fps ドラッグ/スクラブのようなミリ秒応答はクライアント側が良い。
CDN エッジ描画 — サーバ状態が必要なのでエッジに散らしにくい。

そういう場合は LiveView Hooks で一部をクライアント JS に出すか、いっそ React へ。

5 章・Ecto — DB 層の標準

Ecto は Elixir の ORM ではなく DB クエリ・検証・マイグレーションのライブラリ である。ActiveRecord 比較は表面的で、本質は別物。

Ecto の 4 モジュール。

Repo — DB プールと実行インタフェース。Repo.all、Repo.insert、Repo.transaction。
Schema — テーブルと Elixir 構造体のマッピング。ActiveRecord と違い モデルではなくマッピングだけ。
Changeset — 入力の検証・変換のパイプライン。これが Ecto の真の武器。
Query — コンパイル時に検査される DSL。生 SQL より安全。

5.1 Changeset — 真の武器

Changeset は「この入力を受け、これらの検証を経て、この形で DB に入れる」を一つのパイプラインで表す。

def changeset(post, attrs) do
  post
  |> cast(attrs, [:title, :body, :published_at])
  |> validate_required([:title, :body])
  |> validate_length(:title, min: 3, max: 200)
  |> validate_format(:title, ~r/^[^<>]+$/)
  |> unique_constraint(:slug)
  |> put_change(:slug, slugify(attrs["title"]))
end

これは単なるフォーム検証ではない。すべての DB 書き込みが changeset を経由する。 だからビジネスルール違反はコンパイル時ではなくデータ層の一箇所で遮断される。

5.2 Multi — トランザクションビルダー

複雑なトランザクションは Ecto.Multi で。

Multi.new()
|> Multi.insert(:post, Post.changeset(%Post{}, attrs))
|> Multi.update(:user, User.bump_post_count(user))
|> Multi.insert(:notification, fn %{post: post} ->
  Notification.new_post(post)
end)
|> Repo.transaction()

各段階は前段の結果を読め、どこかで失敗すれば全体がロールバックされる。

5.3 Ecto 3 — 安定の標準

2024〜2026 年の Ecto は安定期。3.x が事実上の標準で、大きな変化はなく漸進的な改善が続く。Postgres の配列・jsonb・LISTEN/NOTIFY、MySQL 8、SQLite — どれもよくサポートされている。

6 章・Oban — ジョブ処理と「Pro 999 ドル」騒動

Oban は Elixir 界隈の標準ジョブキュー。Postgres ベース が核 — Sidekiq のように Redis を別途立てず、すでにある Postgres にジョブ用テーブルを一つ足す。

6.1 なぜ Postgres ベースか

ビジネスデータとジョブ enqueue が同一トランザクションでコミットされる。 Sidekiq は「Redis にキュー入れて DB にデータ保存」の間に失敗するとデータだけ/ジョブだけが残る。Oban は両方同じトランザクション。
運用インタフェースが SQL。 ジョブ状態をクエリで直接見る。別途の管理 UI が必須ではない。
バックアップ・レプリケーション・HA が Postgres そのまま。 ジョブキュー専用インフラがない。

# ジョブ定義
defmodule MyApp.Workers.EmailWorker do
  use Oban.Worker, queue: :emails, max_attempts: 5

  @impl Oban.Worker
  def perform(%Oban.Job{args: %{"user_id" => user_id, "kind" => kind}}) do
    user = Repo.get!(User, user_id)
    MyApp.Mailer.deliver(user, kind)
    :ok
  end
end

# ビジネスロジックと同じトランザクションで enqueue
Multi.new()
|> Multi.insert(:user, User.changeset(%User{}, attrs))
|> Oban.insert(:email_job, fn %{user: user} ->
  EmailWorker.new(%{user_id: user.id, kind: "welcome"})
end)
|> Repo.transaction()

6.2 Oban Pro 999 ドル騒動

Oban 本体は無料/OSS。だが運用でよく必要になる機能 — Cron、Batch Jobs（N 個のジョブが全部終わったらコールバック）、Workflow、Smart Engines — は Pro 側にある。2024 年中頃に Pro のシングルライセンス価格が 年 999 ドルに引き上げ られ、コミュニティが騒いだ。

賛否はあった。

賛成側 — Oban メンテナ一人がフルタイムで張り付くからこそ BEAM 界隈にこの品質のジョブキューが維持される。年 999 ドルはシニア時給 1〜2 時間ぶん。
反対側 — Sidekiq Pro は年 219 ドル。999 ドルは高すぎるし、Pro 限定機能の一部は OSS にすべきだった。

結局コミュニティは Pro 派、OSS 本体だけで自作派、Quantum + 自前 GenServer 派に分かれた。2026 年時点では 新規プロジェクトはほぼ Pro を買う — 年 999 ドルはエンジニア数日ぶんの価値しかない。

7 章・Broadway — Kafka・RabbitMQ・AMQP・SQS パイプライン

Oban が「DB ジョブキュー」なら Broadway は「データパイプライン」。外部メッセージシステム（Kafka、RabbitMQ、AMQP、AWS SQS、Google PubSub）からメッセージを引き、バッチ処理し、バックプレッシャを管理する抽象。

7.1 Broadway が解く問題

ストリーミングデータ処理に必要なのは以下。

コンシューマグループ — 複数ノードが同じトピックを分担して読む。
バッチ処理 — 1 件ずつではなく 100/1000 件単位でまとめて処理。
バックプレッシャ — 下流が遅ければ上流から取らない。
リトライ/デッドレター — 失敗メッセージの隔離。

Broadway はこれを BEAM の GenStage の上にすべて載せた標準解。

defmodule MyApp.KafkaPipeline do
  use Broadway

  def start_link(_opts) do
    Broadway.start_link(__MODULE__,
      name: __MODULE__,
      producer: [
        module: {BroadwayKafka.Producer, [
          hosts: [localhost: 9092],
          group_id: "my_group",
          topics: ["events"]
        ]},
        concurrency: 1
      ],
      processors: [
        default: [concurrency: 10]
      ],
      batchers: [
        default: [batch_size: 100, batch_timeout: 1_000]
      ]
    )
  end

  @impl true
  def handle_message(_, message, _) do
    # メッセージ 1 件を変換
    message
  end

  @impl true
  def handle_batch(:default, messages, _, _) do
    # 100 件まとめて DB INSERT
    Enum.map(messages, &Message.update_data(&1, transformed(&1)))
  end
end

これで全部だ。Kafka・RabbitMQ・SQS・PubSub は producer モジュールを差し替えるだけ。

7.2 事例 — イベント ETL

EC プラットフォームで注文イベント（毎秒数千件）を Kafka から読み、エンリッチして ClickHouse に取り込むパイプライン。Broadway で書くと BEAM 一ノードで producer 1、processor 64、batcher 8 で毎秒万件級を余裕で捌く。ノードを足せばコンシューマグループがパーティションを自動再分配する。

8 章・Membrane — 音声/動画パイプライン

Membrane は Software Mansion 社が作る音声/動画処理フレームワーク。WebRTC SFU（Jitsi/LiveKit のようなもの）からライブストリーミングのトランスコード、RTSP カメラ統合、HLS セグメント生成までやる。

8.1 なぜ BEAM がメディア処理に合うか

同時ストリーム数千 — 各ストリームが独立プロセス。一通話が切れても他に影響なし。
バックプレッシャ組み込み — 処理が遅い段があれば前段は送らない。
分散 — 複数ノード間で負荷分散が自然。

もちろんコーデック（H.264/VP9/Opus）自体のエンコード・デコードは C/Rust（NIF）に落ちる。Membrane はそのパイプラインを組み、ライフサイクルを管理し、流量を制御する。

8.2 シンプルなパイプライン

defmodule MyApp.AudioPipeline do
  use Membrane.Pipeline

  @impl true
  def handle_init(_ctx, opts) do
    structure = [
      child(:file_src, %Membrane.File.Source{location: opts.input}),
      child(:mp3_decoder, Membrane.MP3.MAD.Decoder),
      child(:opus_encoder, %Membrane.Opus.Encoder{}),
      child(:rtp, Membrane.RTP.PayloadFormatResolver),
      child(:udp_sink, %Membrane.UDP.Sink{destination: opts.dest})
    ]

    {[spec: structure], %{}}
  end
end

MP3 ファイルをデコードして Opus に再エンコード、RTP でパケット化して UDP で送る。各ノードは独立プロセスでバックプレッシャが自動で流れる。

8.3 実際の使われ方

Jellyfish — Membrane チーム製の WebRTC SFU サーバ。Zoom 的な多人数会議を BEAM 上で。
Veedo — Membrane ベースのライブストリーミングプラットフォーム。

9 章・Igniter — コード変換ツール

Igniter は比較的新しい（2024 年）プロジェクト。Elixir コードを安全に自動修正するツールで、ライブラリのインストール/アップグレード時に必要なボイラープレートを自動で挿し込む。

9.1 何を解くか

従来の mix deps.get はライブラリを落とすだけ。それを使うには config/config.exs に設定を書き、application.ex に supervisor child を加え、router に plug を追加する — これを全部 README を読んで手でやっていた。

Igniter はこれを自動化する。ライブラリが Igniter Recipe を提供すれば、mix igniter.install <lib> が AST レベルで安全に全ファイルを修正する。

mix igniter.install ash_authentication
# config/config.exs を自動修正
# lib/my_app/application.ex に supervisor child を自動追加
# lib/my_app_web/router.ex にルートを自動追加

9.2 直接使うケース

Igniter は単純なライブラリインストールだけでなく、マイグレーションツールとしても使う — 例えば LiveView 0.20 から 1.0 へ移行する際、deprecated API を自動変換する。Phoenix 1.7 → 1.8 マイグレーションの一部も Igniter recipe で提供される。

10 章・Bumblebee — Elixir で HF Transformers

ここから「Elixir も AI をやる」の話になる。

Bumblebee は Hugging Face Transformers の Elixir 移植。同じモデルアーティファクト（safetensors）と同じトークナイザ設定をそのまま読み、Elixir から推論する。

10.1 BERT を一行で推論

{:ok, model} = Bumblebee.load_model({:hf, "bert-base-uncased"})
{:ok, tokenizer} = Bumblebee.load_tokenizer({:hf, "bert-base-uncased"})

serving = Bumblebee.Text.fill_mask(model, tokenizer)
Nx.Serving.run(serving, "The capital of [MASK] is Paris.")
# => [%{token: "France", score: 0.97}, ...]

これで全部。CPU でも普通に動く。GPU 加速したければバックエンドを EXLA（XLA、JAX のあれ）に切り替える。

10.2 バックエンド — Nx → EXLA / Torchx

Bumblebee 自体は Nx の上に乗っている。Nx は NumPy ライクなテンソル API。実際の計算はバックエンドが担う。

EXLA — Google XLA を介した CPU/GPU/TPU。速いものが多い。
Torchx — LibTorch（PyTorch コア）を介した CPU/GPU。PyTorch モデル互換性が良い。

# config/config.exs
config :nx, default_backend: EXLA.Backend
config :nx, default_defn_options: [compiler: EXLA]

10.3 Stable Diffusion、Whisper、Llama

Bumblebee が対応するモデル群は着実に増えた。

Stable Diffusion XL — テキスト → 画像。
Whisper — 音声 → テキスト。ライブ字幕によく使う。
Llama 3、Mistral、Gemma — 7B〜70B の LLM。量子化でノート PC でも動く。
CLIP — 画像/テキスト埋め込み。

10.4 Phoenix と組み合わせる — Nx.Serving

Bumblebee の推論は Nx.Serving という抽象の中で走る。これが決定的 — Phoenix アプリの supervisor ツリーに child として置くだけで、自動で バッチ/キューイング/タイムアウト を処理してくれる。

# application.ex
children = [
  MyAppWeb.Endpoint,
  {Nx.Serving,
   serving: build_whisper_serving(),
   name: WhisperServing,
   batch_size: 8,
   batch_timeout: 200}
]

# どこからでも呼ぶ
Nx.Serving.batched_run(WhisperServing, audio_input)

10 件の同時リクエストが来ても batch_size: 8 が自動で 8 件ずつまとめて GPU に投げる。GPU 使用率が上がる。

11 章・Nx + Axon + Explorer — BEAM データサイエンス

Bumblebee の一行推論を見たので、その下の層を見る。

11.1 Nx — NumPy for BEAM

Nx はテンソルライブラリ。NumPy/PyTorch に近い API。

import Nx.Defn

defn softmax(t) do
  Nx.exp(t) / Nx.sum(Nx.exp(t))
end

Nx.tensor([1.0, 2.0, 3.0]) |> softmax()
# => Nx.Tensor f32[3] [0.09, 0.24, 0.67]

defn は 数値専用関数。普通の Elixir 関数ではなく JIT コンパイルされる — EXLA で XLA に下りて GPU/TPU で動く。

11.2 Axon — ディープラーニングライブラリ

Axon は Nx の上のニューラルネットワークライブラリ。Keras スタイルの関数型 API。

model =
  Axon.input("input", shape: {nil, 784})
  |> Axon.dense(128, activation: :relu)
  |> Axon.dropout(rate: 0.2)
  |> Axon.dense(10, activation: :softmax)

# 学習
model
|> Axon.Loop.trainer(:categorical_cross_entropy, :adam)
|> Axon.Loop.metric(:accuracy)
|> Axon.Loop.run(train_data, %{}, epochs: 10)

小さなモデルは BEAM ノードで直接学習する。大きなモデルは PyTorch で学習し Bumblebee で配るのが定石。

11.3 Explorer — DataFrame、Polars バックエンド

Explorer は Pandas/Polars の Elixir 版。内部的に Polars（Rust）を NIF で呼ぶ。 だから速い。

require Explorer.DataFrame, as: DF

df = DF.from_csv!("sales.csv")

df
|> DF.filter(col("amount") > 100)
|> DF.group_by("region")
|> DF.summarise(total: sum(col("amount")), n: count(col("id")))
|> DF.sort_by(desc: "total")

これを Livebook で可視化すれば Jupyter 相当のデータ分析環境になる。

12 章・Livebook — Elixir ノートブック

Livebook は José Valim 製の Elixir 版 Jupyter。ただし Jupyter と違う点が 2 つある。

コラボレーションが一級 — 一つのノートブックを複数人で同時編集。Google Docs 的。
バージョン管理がクリーン — ノートブックは .livemd（markdown）。git diff が人間に読める。

# Mac/Linux 一行インストール
mix escript.install hex livebook
livebook server
# http://localhost:8080

12.1 Livebook が合う場所

データ探索 — DB クエリ、Explorer、Vega-Lite チャート。
ML 推論実験 — Bumblebee モデルをノートブックで立ててハイパーパラメータ調整。
運用ノートブック — 「プロダクション DB にこのクエリを一度走らせたい」をレビュー可能な形で。
チュートリアル/教材 — .livemd は実行可能な文章。

12.2 Smart Cells

Smart Cell は UI フォームでコードを生成するセル。チャート、DB クエリ、ニューラルネット可視化などがフォーム入力だけで該当コードセルを生成する。

[Smart Cell: SQL Query]
  Connection: prod_replica
  Query: SELECT * FROM users WHERE created_at > $1
  Variables: cutoff_date = ~D[2026-01-01]

→ セル下に Ecto/Postgrex コードが自動生成される

13 章・Tidewave（2025 年 9 月、José Valim）— Elixir LLM サービング

2025 年 9 月、José Valim と Dashbit チームが Tidewave を公開した。「BEAM 上の LLM サービングプラットフォーム」だ。

13.1 何を解くか

LLM サービングに必要なのは以下。

同時推論リクエスト数百〜数千を GPU にうまく束ねる — vLLM が解く問題。
ストリーミング応答 — トークン単位でクライアントに push。
セッション/状態管理 — マルチターン会話、コンテキスト。
障害隔離 — 一ユーザの不正リクエストが他に影響しない。
分散 — 複数 GPU ノードにルーティング。

このうち 3・4・5 は BEAM が 30 年前から得意な領域。1・2 も Nx.Serving + Phoenix Channels の上に自然に乗る。

13.2 アーキテクチャ

Tidewave はだいたいこんな形。

              [Phoenix Endpoint]
                      |
              +-------+-------+
              |               |
        [HTTP /chat]    [WS /stream]
              |               |
              v               v
        [Session Sup]   [Stream Channel]
              |               |
              v               v
        [Session GenServer x N]
              |
              v
    +---------+---------+
    |                   |
[Nx.Serving]      [Tool Runtime]
    |                   |
    v                   v
[GPU Workers]   [DB / HTTP / RAG]

各ユーザセッションは独立した GenServer。一つが壊れても他に影響しない。Nx.Serving が GPU バッチを管理する。ツール呼び出しは別の supervisor サブツリー。

13.3 vLLM 比較

Tidewave は vLLM と正面衝突するというより 別の問題を解く。vLLM は GPU 効率で群を抜く。Tidewave は GPU 効率は vLLM に及ばないが、運用性・セッション管理・障害隔離・分散 が BEAM の強み。

選定基準はシンプル。

単一ノードで短い応答を最大スループットで — vLLM。
多セッション・長時間会話・複雑なツール呼び出し・高可用性 — Tidewave。

14 章・BEAM 運用 — Observer、recompile、ホットリロード

Elixir アプリを運用した人だけが知る楽しみがいくつかある。

14.1 Observer — ライブノードを覗く

iex --sname dev --remsh my_app@hostname
iex> :observer.start()

GUI が立つ。プロセスツリー、メールボックス長、メモリ使用量、CPU スケジューラ状態 — すべてライブで見える。あるプロセスのメールボックスが異常に長ければそこにボトルネックがある。

14.2 IEx リモートシェル

iex --sname remote@host --cookie SECRET --remsh prod@host

プロダクションノードへリモート IEx シェルを張る。そこで Repo.get(User, 1)、Phoenix.PubSub.broadcast(...) 全部できる。運用デバッグの極み。

14.3 ホットコードリロード

iex> r MyApp.SomeModule

稼働中のノードにモジュールを再コンパイル/再ロードする。全体再起動なしに一関数だけ差し替えても即反映。ただしプロダクションでは慎重に。 普通は新リリースを切ってローリング再起動する。

15 章・韓国・日本での Elixir 採用

Elixir は巨大企業のメインスタックではないが、特定領域で強い。

15.1 韓国

Toss（トス） — フィンテックのメインスタックは Kotlin/JVM だが、一部のリアルタイム系統（通知、チャット、一部決済ワークフロー）に Elixir/Phoenix が入っているとされる。
BabyDragon（ベビードラゴン） — 韓国モバイルゲーム会社。Elixir/Phoenix をゲームバックエンドとマッチメイキングサーバに広範に使う。
Banksalad — 家計簿アプリ。初期に一部バックエンドを Elixir でやったとされる資料がある。
個人開発者/スタートアップ — リアルタイムチャット・コラボ・ゲームバックエンドを単一 BEAM ノードで捌く小チームが安定して存在する。

韓国での Elixir 普及は遅め。第一の理由は 採用プールが小さい こと。JVM/Kotlin/Node に比べて韓国語資料も少ない。ただし一度採用したチームは離れにくい。

15.2 日本

ドリコム — モバイルゲーム会社。ゲームサーバ一部に Elixir/Phoenix。
DMM — 一部のリアルタイム系統。
任天堂 — 公式発表は少ないが、一部オンラインサービスのバックエンドに BEAM 系（Erlang を含む）が入っているとされる。
Cookpad — Ruby 本拠地だが、一部バックエンド実験で Elixir を見る資料がある。
サイバーエージェント — 広告/AdTech のリアルタイム部分。

日本は Erlang の伝統が早くからあった（NTT・エリクソン日本の影響）。なので Elixir への移行が韓国より自然。日本語資料（Qiita、Zenn）も韓国語より豊富。

15.3 世界

Discord — Erlang/Elixir でメッセージルーティング。一チャネル数百万同時接続を BEAM クラスタで処理。
WhatsApp — Erlang。Meta 買収前まで小規模チームで数億ユーザを運用した伝説。
Pinterest — 一部の通知/SMS 系統。
Heroku — ルーティング層を一時 Erlang で。
Bleacher Report — トラフィックスパイク対応を Elixir 一本で。

16 章・誰が Elixir を選ぶべきか

最終章。決定マトリクス。

Elixir/Phoenix がよく合うケース

リアルタイム並行性が核 — チャット、ゲーム、ライブストリーム、コラボツール、トレーディング。
長期接続を多数維持 — WebSocket 数万本、IoT デバイス数万台。
ソフトリアルタイム・耐障害性が要件 — 通信、決済通知、メディア。
小チームでフルスタックを素早く — LiveView 一抽象でバック+フロントを同時処理。
メッセージパイプライン — Broadway で Kafka/SQS/RabbitMQ ETL。

Elixir が合わないケース

CPU 集約的な重い単発計算 — JS エンジン/ネイティブより BEAM は遅い。NIF で逃げられるが、単純な処理は Go/Rust の方が良い。
巨大な ML 学習のメインスタック — PyTorch エコシステムが圧倒的。Elixir はサービング/MLOps の補助に近い。
豊富なライブラリエコシステムが核 — npm/PyPI のような量はない。Hex パッケージ数は万単位。
採用/チーム編成が一番の制約 — 韓国で Elixir のシニアを短期間に 5 人雇うのは難しい。

一行ガイド

「同時接続 1 万以上、もしくはリアルタイムが核、もしくは運用安定性が最優先なら Elixir は検討に値する。CRUD 中心の SaaS なら Phoenix は魅力的だが、Rails/Django/Next でも十分うまくいく。」

17 章・参考 / References

Elixir 公式: https://elixir-lang.org/
Elixir 1.18 リリースノート: https://elixir-lang.org/blog/2024/12/19/elixir-v1-18-0-released/
Phoenix Framework: https://www.phoenixframework.org/
Phoenix 1.8 リリースノート: https://www.phoenixframework.org/blog/phoenix-1.8-released
Phoenix LiveView: https://github.com/phoenixframework/phoenix_live_view
LiveView 1.0 発表: https://www.phoenixframework.org/blog/phoenix-liveview-1.0-released
Ecto: https://github.com/elixir-ecto/ecto
Oban: https://github.com/oban-bg/oban
Oban Pro: https://oban.pro/
Broadway: https://github.com/dashbitco/broadway
Membrane Framework: https://membrane.stream/
Igniter: https://github.com/ash-project/igniter
Bumblebee: https://github.com/elixir-nx/bumblebee
Nx: https://github.com/elixir-nx/nx
Axon: https://github.com/elixir-nx/axon
Explorer: https://github.com/elixir-explorer/explorer
Livebook: https://livebook.dev/
Tidewave: https://tidewave.ai/
Dashbit（José Valim の会社）: https://dashbit.co/
Fly.io Elixir ガイド: https://fly.io/docs/elixir/
The BEAM Book（VM 内部）: https://github.com/happi/theBeamBook
Erlang Solutions ブログ: https://www.erlang-solutions.com/blog/
ElixirConf US: https://elixirconf.com/
ElixirConf EU: https://www.elixirconf.eu/
Code BEAM: https://codebeamamerica.com/
ElixirForum: https://elixirforum.com/
Awesome Elixir: https://github.com/h4cc/awesome-elixir
Thinking Elixir ポッドキャスト: https://thinkingelixir.com/
BeamCommunity Slack: https://erlef.org/slack-invite
Discord エンジニアリングブログ: https://discord.com/category/engineering
WhatsApp Erlang 事例（過去）: https://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf
ドリコム TechCon Elixir トラック: https://tech.drecom.co.jp/
Toss 技術ブログ: https://toss.tech/
BabyDragon: https://babydragon.com/