先に要点
- 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』</strong> という言葉です。なぜ生まれたか』 を見ます。
従来の 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 の核 |
要点は 初回表示速度を取りに行くか、エコシステムを取るか』</strong> のトレードオフです。 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』</strong>。SaaS / SPA / 中小規模アプリ』 は Next.js のエコシステムのメリットが大きく、`大規模 EC / メディア / マーケサイト』 で Qwik の性能が活きます。
Q. Qwik は本番運用に耐えますか？
A. 採用事例は増えているが、まだ React / Next.js ほどではない』</strong>です。Builder.io 自身を含め、本番採用は確実に増えていますが、コミュニティで困ったときの情報量』 は React 比で少なめ、と理解しておくのが安全です。
Q. React からの移行コストは？
A. 概念学習に数日、実装の書き換えはほぼ全部書き直し』</strong>です。書き味は近いですが、Resumability の前提』 を理解しないと正しく動かないため、`React 既存資産を活かしながら一部だけ』 のような中途半端な導入は難しいです。
Q. RSC との関係は？
A. 目指す方向は近いが手段が違う』</strong>です。RSC はReact の枠内で改善』、Qwik は Hydration を捨てる別アプローチ』。React で改善し切れない場合の選択肢』 として Qwik を見るのが現実的です。
Q. Astro との違いは？
A. Astro = MPA + Islands、Qwik = SPA + Resumability』</strong>。Astro はページ単位で別の JS フレームワークを混ぜられる』、Qwik は Qwik の世界観で統一する』。ページ間遷移をフル SPA で繋ぐ』 必要があるなら Qwik、`ページ単位で別フレームワークを使い分けたい』 なら Astro。
Q. Qwik の学習コストは？
A. React 経験者で 1〜2 週間』</strong>程度です。$ 接頭辞』 シグナル』 Resumability の制約』 を理解し、React のクセを抜く』 のに時間がかかります。MVP を作る』 程度なら数日でも書けますが、`本番に出す』 までの理解には時間が必要です。
Q. Qwik を学ぶ最短ルートは？
A. ① 公式チュートリアル(qwik.dev/tutorial』)で $ の使い方』 を体感、② useSignal / useStore』 で状態管理、③ routeLoader$ / routeAction$』 でデータ取得とフォーム、④ Cloudflare adapter でデプロイ、の4ステップが王道です。`触らないと感覚が掴めない』 タイプのフレームワークです。