先に要点
- Qwik は Resumability(再開可能性) という概念で動く新世代の UI フレームワーク。「サーバが完全に状態を含んだ HTML を出力 → クライアントは Hydration せずにそのまま再開」 という発想。
- 従来の SSR + Hydration では、「どんなに小さなページでもクライアント側で全コンポーネントを再実行する」 必要があった。Qwik は Hydration を捨てて、必要になったところだけ後から JS を読み込む 設計で、初回表示の JS 量をほぼゼロにする。
- 書き味は React に近い JSX だが、$ 接頭辞(「onClick$」 「component$」) でコンパイラがコード分割の境界を見つける。「書く側は普通の JSX」 だが、「動く側は超細粒度に分割された JS」。
- 本命の使い所は 初回表示速度が UX の核となるサイト(EC / メディア / マーケサイト / SEO 重視)。SPA / アプリ的 UI には Qwik の利点が薄れる、というのが採用判断の中心。
Qwik ってよく聞くけど、Next.js と何が違うの？ 「Resumability って何？」 「普通の Hydration はそんなにダメなの？」 ── 2023 年に v1.0 が出てから注目され続けている Qwik は、「SSR 系フレームワークの常識を覆す」 と言われる存在です。
ざっくり言うと、Qwik は SSR + Hydration を 「Resumability」 に置き換えた 新世代の UI フレームワークです。 `サーバで全部 HTML を組んで、クライアントには 「必要になったら部分的に JS を読み込む」 アーキテクチャを」 という設計で、「初回表示時にクライアントに送る JS はほぼゼロ」 を実現します。
この記事では、2026 年 5 月時点の Qwik v1 系をベースに、Resumability の仕組み・React との違い・Qwik City・採用判断軸 を整理します。 仕様は活発に変化しているので、最終確認は 公式 を見るのが安全です。
Resumability とは — Hydration の何が問題か
Qwik を理解する鍵が Resumability という言葉です。「なぜ生まれたか」 を見ます。
従来の SSR + Hydration
「 サーバで HTML を作る → クライアントで JS を読み込んで再実行 → イベントハンドラを再装着」 という流れ。全コンポーネントを再実行するコストと 全 JS をダウンロード / パース / 実行するコスト がかかる。
問題は規模で爆発する
「1000 個のコンポーネントを持つ複雑なサイト」 で、Hydration が秒単位になる。LCP / TBT が悪化し、SEO スコアにも影響。
Qwik のアプローチ
「 Hydration を完全に捨てる」。サーバが出した HTML には 「 全状態 + どこに何が起きうるか」 がシリアライズ済み で含まれていて、クライアントは ユーザーが触ったらその部分だけ JS をダウンロード する。
結果
「 初回表示時にクライアントに送る JS はほぼゼロ」。ユーザーがクリック / スクロール / ホバーした瞬間に、その操作に必要な JS だけが取得される。「サイト全体の規模に依存しない初回表示速度」 が手に入る。
「SSR + Hydration を捨てる」 という発想自体が革新的で、Qwik は 「フレームワークの新しい問い」 を立てたとも言えます。
基本の書き方 — 「$ 接頭辞」
Qwik のコードは React の JSX に近いですが、$ 接頭辞 が独特です。
import { component$, useSignal } from '@builder.io/qwik';
export default component$(() => {
const count = useSignal(0);
return (
<button onClick$={() => count.value++}>
クリック: {count.value}
</button>
);
});
「component$」
「 Qwik のコンポーネントを宣言する関数」。$ 接頭辞 がコンパイラに 「ここがコード分割の境界」 と教える役。
「onClick$」
「 通常の onClick」 ではなく 「onClick$」 と書く。クリックされた瞬間に、このハンドラのコードだけが lazy load される 仕組みになる。
「useSignal」
「Solid.js」 と似たシグナルベースの状態管理。「count.value」 で読み書き。値が変わると、DOM の該当箇所だけが更新される。
「$ がコンパイル時に魔法をかける」 のが Qwik の体験を一言で表す部分です。
Qwik City — フルスタックメタフレームワーク
「Qwik 単体」 ではコンポーネントを書くだけですが、「実用アプリ」 には Qwik City が使われます。
ファイルベースルーティング
「src/routes/」 配下のファイル構造で URL を表現。「Next.js を触ったことがあれば違和感ゼロ」。
routeLoader$ / routeAction$
「 データ取得とフォーム送信」 が 「routeLoader$」 「routeAction$」 として書ける。「サーバで動く関数 → クライアントから呼び出し」 が Server Actions と似た形で完結。
マルチデプロイ
「 adapter」 で Node / Vercel / Cloudflare Pages / Netlify / Deno / 静的 SSG」 に出せる。Cloudflare Workers + Qwik City の組み合わせが特に人気。
「Qwik を実用にするなら Qwik City」 が事実上のスタンダードです。
React / Next.js との比較
「Next.js / React と Qwik、何が違う？」 を表で並べます。
| 軸 | React + Next.js | Qwik + Qwik City |
|---|---|---|
| レンダリングモデル | SSR + Hydration(RSC で改善中) | SSR + Resumability(Hydration なし) |
| 初回 JS | 大きい(全コンポーネント分) | ほぼゼロ(必要なときだけ) |
| LCP / TBT | 規模が大きいほど悪化 | 規模に関わらず安定 |
| 記述スタイル | JSX + hooks | JSX + $ 接頭辞 + シグナル |
| エコシステム | 圧倒的 | 発展中 |
| 学習コスト | React の概念全部 | $ と Resumability の感覚 |
| 主な選び所 | SPA / リッチ UI / 既存資産 | 初回表示速度が UX の核 |
要点は 初回表示速度を取りに行くか、エコシステムを取るか のトレードオフです。 Qwik は 「性能で React に勝ちにいく」 設計、React は 「エコシステムと採用実績で勝つ」 構造、というのが2026年現在の住み分けです。
どんな案件で効くか
Qwik が 「効く」 場面と 「効かない」 場面を整理します。
向いている
① EC / メディア / マーケサイトなど 「初回表示速度が UX の核」 になるサイト、② コンテンツ重視 + SEO 重視、③ 大規模で Hydration コストが問題になっている案件、④ 「Next.js の RSC で改善しきれない」 重量級ページ。
向かない
① SPA / アプリ的 UI(初回表示の優位が薄れる)、② 既存 React チームでの再採用、③ React 系 AI ツール(v0 等)を使い倒したい、④ 学習コストをかける余裕がないチーム。
RSC との関係
React 19 の RSC も 「クライアント JS を減らす」 方向。RSC は React の中で改善、Qwik はゼロから設計し直し という違いで、目指す方向は近いが手段が違う。
「性能要件が明確に Qwik を必要としているか」 を冷静に判断するのが大事です。
どこで詰まりやすいか
便利な反面、現場で踏みやすい注意点もあります。
①$ の付け忘れ
「 onClick」 と書いてしまうと Hydration 的な動きになり、Resumability のメリットが失われる。「onClick$」 を常に書くルール / Linter の整備が必要。
② シリアライズ可能なものだけ
「 クロージャでキャプチャした値」 は シリアライズ可能でないといけない。「関数 / クラスインスタンス / DOM ノード」 を直接持つと、ビルド時に怒られる場面がある。
③ エコシステムの未成熟
React 専用ライブラリは使えない。「Qwik 用に書かれた UI ライブラリ」 を選ぶ必要がある(「Qwik UI」 「flowbite-qwik」 など)。「React 流の知識がそのまま使えない」 ケースもある。
④ チームの教育
「 Resumability の世界観」 を理解しないと、「React のつもり」 で書いて性能が出ない / 動かないコードが量産される。Qwik を採用する = チーム全体で世界観を学ぶコストを払う。
「新規プロジェクトで明確に Qwik を選ぶ意思があるチーム」 でないと、運用後に 「結局 React に戻したい」 になりやすいです。
AI 時代の Qwik
AI 連携の文脈で Qwik の立ち位置を見ます。
AI チャット UI のような SPA
「 AI とチャットする」 系の UI は SPA 寄りなので、Qwik の Resumability 優位は薄い。React + Next.js のほうがツールが揃う。
AI 生成コンテンツのコーポレートサイト
「 AI で大量に生成した記事を SEO 重視で配信する」 場合は、Qwik が活きる。「コンテンツが多い + JS 重い」 状況で差が出る。
Builder.io との統合
Qwik は Builder.io(ビジュアルエディタ + CMS)の開発元が作っており、「Builder.io で組んだサイト → Qwik で出力」 が標準フロー。AI で UI を組む × CMS で配信、という構成と相性◎。
「AI で大量配信する SEO サイト」 のような領域で、Qwik は静かに強い選択肢になっています。
Qwik に関するよくある質問
Q. Qwik と Next.js、結局どっち？
A. 初回表示速度が UX の核なら Qwik、それ以外はほぼ Next.js。「SaaS / SPA / 中小規模アプリ」 は Next.js のエコシステムのメリットが大きく、「大規模 EC / メディア / マーケサイト」 で Qwik の性能が活きます。
Q. Qwik は本番運用に耐えますか？
A. 採用事例は増えているが、まだ React / Next.js ほどではないです。Builder.io 自身を含め、本番採用は確実に増えていますが、「コミュニティで困ったときの情報量」 は React 比で少なめ、と理解しておくのが安全です。
Q. React からの移行コストは？
A. 概念学習に数日、実装の書き換えはほぼ全部書き直しです。書き味は近いですが、「Resumability の前提」 を理解しないと正しく動かないため、「React 既存資産を活かしながら一部だけ」 のような中途半端な導入は難しいです。
Q. RSC との関係は？
A. 目指す方向は近いが手段が違うです。RSC は 「React の枠内で改善」、Qwik は 「Hydration を捨てる別アプローチ」。「React で改善し切れない場合の選択肢」 として Qwik を見るのが現実的です。
Q. Astro との違いは？
A. Astro = MPA + Islands、Qwik = SPA + Resumability。Astro は 「ページ単位で別の JS フレームワークを混ぜられる」、Qwik は 「Qwik の世界観で統一する」。「ページ間遷移をフル SPA で繋ぐ」 必要があるなら Qwik、「ページ単位で別フレームワークを使い分けたい」 なら Astro。
Q. Qwik の学習コストは？
A. React 経験者で 1〜2 週間程度です。「$ 接頭辞」 「シグナル」 「Resumability の制約」 を理解し、「React のクセを抜く」 のに時間がかかります。「MVP を作る」 程度なら数日でも書けますが、「本番に出す」 までの理解には時間が必要です。
Q. Qwik を学ぶ最短ルートは？
A. ① 公式チュートリアル(「qwik.dev/tutorial」)で 「$ の使い方」 を体感、② 「useSignal / useStore」 で状態管理、③ 「routeLoader$ / routeAction$」 でデータ取得とフォーム、④ Cloudflare adapter でデプロイ、の4ステップが王道です。「触らないと感覚が掴めない」 タイプのフレームワークです。