Svelteってなんだ？〜React/Vue経験者が「次の選択肢」を真剣に検討してみた〜

この記事の対象読者

• React/Vueでの開発経験があるが、フロントエンドの選択肢を広げたいと考えている方
• JavaScriptの基本（ES6+、npm/pnpm）を理解しているWebエンジニア
• 新規プロジェクトの技術選定で「Reactで本当にいいのか？」と立ち止まりたい方
• パフォーマンスに悩み、バンドルサイズという戦場で戦っている方

この記事で得られること

• 「仮想DOMを持たない」という発想の意味と、なぜそれが速度に直結するのか
• React/Vueとの本質的な違いを、ランタイム型 vs コンパイラ型という軸で整理できる
• Svelte 5のRunes（$state $derived $effect）を、ReactのHooks/VueのComposition APIと対応付けて理解できる
• 採用判断の具体的な基準: どのプロジェクトでSvelteを選び、どの案件では避けるべきか
• 3環境（開発/本番/テスト）の設定ファイルをコピペで使える状態で提供

この記事で扱わないこと

• JavaScriptやHTMLの基礎文法（ES6+は理解している前提）
• React/Vueの詳細解説（比較対象として軽く触れる程度）
• SvelteKitの高度な機能（SSR、APIルート、Form Actions等）の深掘り
• TypeScript特有の設定やジェネリクスの議論

---

1. 『また新しいフレームワークかよ…』と思った日

『またJavaScriptフレームワークが出たのか…』

正直に白状する。最初にSvelteの名前を目にしたとき、自分はそうつぶやいた。Reactで仕事は回る。Vueも書ける。TypeScriptを足せば型の安全性も手に入る。これ以上、何を学ぶ必要がある？ そう思っていた。

転機は、ある案件のパフォーマンス相談だった。『モバイルでページが重い』というクライアントの声に応えようと、コード分割、Tree Shaking、画像の遅延読み込み…打てる手は全部打った。それでもLighthouseスコアは上がりきらない。JavaScriptバンドルが肥大化する根本原因に、自分は手を出せていなかった。

そんなときに目にした数字がSvelteのランタイムサイズ約1.6KBだった。Reactが42KB、Vueが20KBだ。桁が、違う。

(;ﾟдﾟ)ﾎﾟｶｰﾝ

『そんなわけあるか』と半信半疑で触り始めた結果、自分のフレームワーク観はまあまあ壊れた。Svelteは一言でいうと「ビルドが終わった瞬間にフレームワーク本体が消えているフレームワーク」だ。React/Vueが「お客さんのテーブルにシェフと調理器具を連れていって、そこで毎回料理する」レストラン形式なら、Svelteは「セントラルキッチンで完成品まで仕上げて、あとは温めるだけの状態で配送する」形式と言える。お客さん（ブラウザ）の負担が圧倒的に軽い。

ここから先は、この「セントラルキッチン方式」の料理人=Svelteが、どうやってこの離れ業を実現しているのか、React/Vueの厨房と何が違うのかを順番に見ていく。まずは用語の整理からだ。

---

2. 前提知識の確認

本題に入る前に、この記事全体で繰り返し使う用語を、料理の比喩ごと整理しておく。ここを押さえると、後のセクションがぐっと読みやすくなる。

2.1 仮想DOM(Virtual DOM)

実際のDOMの複製をJavaScriptオブジェクトとしてメモリ上に保持する仕組みのこと。UIに変更があるたび、まず仮想DOMの側で差分を計算し、必要な箇所だけ実DOMに書き戻す。ReactとVueの主要な高速化戦略だ。

料理でいえば、お客さんに料理を出す前に「試食用の皿」で毎回味見して調整する工程にあたる。皿を一枚増やすぶん厨房は忙しいが、本番の皿での失敗は減る。

2.2 ランタイム型 vs コンパイラ型フレームワーク

• ランタイム型（React, Vue, Angular）: ブラウザ上でフレームワーク本体のコードが動き続ける。お客さんのテーブルにシェフと器具を丸ごと持ち込む形式。
• コンパイラ型（Svelte, Solid等）: ビルド時にコンポーネントを素のJavaScriptに変換する。セントラルキッチンで完成させてから配送する形式。

ブラウザに届くのは最適化済みのJavaScriptだけ。フレームワークのランタイムコストがゼロになる、というのがSvelteの一行要約だ。

2.3 リアクティビティ(Reactivity)

データの変更を検知して自動的にUIを更新する仕組み。ReactではuseStateとuseEffect、Vueではrefとcomputed、Svelte 5ではRunes(ルーン)と呼ばれる$接頭辞付きの記法が担当する。

料理でいえば「食材が変わったら自動でメニューを作り直す仕組み」。冷蔵庫の中身が変われば、今日のおすすめも自動で変わる、というイメージだ。

2.4 SvelteKit

Svelte公式のフルスタックフレームワーク。ReactにおけるNext.js、VueにおけるNuxtに相当する。ルーティング、SSR、SSG、APIルートをまとめて提供する。セントラルキッチンに「注文管理」「配送」「店舗運営」機能を足した総合レストランチェーン、と考えればいい。

用語が揃ったところで、次はこの「セントラルキッチン方式」がどういう問題意識から生まれたのかを押さえておこう。

---

3. Svelteが生まれた背景 ─ 仮想DOMへの『異議申し立て』

3.1 Rich Harrisの問い

Svelteは2016年、ニューヨーク・タイムズでインタラクティブグラフィックスを手掛けていたRich Harris氏によって生み出された。彼は以前、同じ思想の系譜にあるリアクティブUIライブラリRactive.jsを作っており、Svelteはその発展形として設計された。

彼が2019年の講演『Rethinking Reactivity』で投げかけた問いは、今振り返っても鋭い。

『仮想DOMは速い、と皆言う。でもそれは"実DOM直叩き"と比べての話だ。仮想DOMそのもののオーバーヘッドは存在する。最初から仮想DOMが不要な方法で更新できれば、もっと速くできるはずだ』

料理にたとえ直すなら、『毎回試食皿を作って比較するのは本当に効率的か？ 最初から"何を変えればいいか"が分かる設計にすれば、試食皿そのものが要らないのでは？』という問いだ。この問題提起がSvelte全体の設計思想の核心になっている。

3.2 Svelte 5 ─ 『成熟期』への到達

2024年10月、Svelte 5が正式リリースされた。最大の変化はRunes(ルーン)の導入だ。

Svelte 4までは、変数を宣言するだけで勝手にリアクティブになる、魔法のような書き味だった。

// Svelte 4: ただの変数宣言が、なぜかリアクティブになる
let count = 0;

Svelte 5では、$stateというRuneで明示的にリアクティブ状態を宣言する形に変わった。

// Svelte 5: リアクティブであることを自己申告する
let count = $state(0);

「魔法が減った」ように感じるかもしれないが、これは成熟の証だ。大規模アプリでは「どの変数がリアクティブか」を追える明示性のほうが運用に効く。ReactのHooksやVueのComposition APIに馴染んだ手なら、むしろ親指で書けるぐらいに馴染む。

背景が腑に落ちたところで、いよいよReact/Vueとの具体的な違いをコードで並べてみる。

---

4. Svelteの基本概念 ─ React/Vueと三枚並べて比較する

4.1 ビルドプロセスの全体像

料理の仕込み工程を図にすると、3者の違いがはっきり見える。

Reactは「完成した料理+キッチン一式」をお客さんの家に配送する。Svelteは「完成した料理だけ」を配送し、キッチンは不要。これがバンドルサイズの桁違いの差になる。

4.2 コンポーネントの記述 ─ 同じカウンターを3通りで書く

同じ「カウンターボタン」を3つのフレームワークで書き比べる。

Reactの場合(JSX):

// Counter.jsx
import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Vue 3の場合(Composition API):

<!-- Counter.vue -->
<script setup>
import { ref } from 'vue';
const count = ref(0);
</script>

<template>
  <button @click="count++">
    Count: {{ count }}
  </button>
</template>

Svelte 5の場合:

<!-- Counter.svelte -->
<script>
  let count = $state(0);
</script>

<button onclick={() => count++}>
  Count: {count}
</button>

Svelteの何が違うか分かるだろうか。importすら不要で、count++という素のJavaScript代入がそのまま動く。値の更新に専用関数を挟まない。これはコンパイラが裏で等価な更新処理を差し込んでくれるからできる芸当だ。料理人に「塩を足して」と言えば、あとの味調整は全部任せられる、そんな書き心地に近い。

4.3 派生状態(Derived State)

元の値から計算される値の扱いを3つ並べる。

フレームワーク	書き方	依存追跡
React	const doubled = useMemo(() => count * 2, [count])	手動
Vue 3	const doubled = computed(() => count.value * 2)	自動
Svelte 5	let doubled = $derived(count * 2)	自動

React勢が誰もが一度は踏む「依存配列の書き忘れ」地雷が、Svelteには原理的に存在しない。コンパイラが静的解析で依存関係を抽出してくれるからだ。

4.4 副作用(Side Effects)

状態変化に応じて処理を走らせるケースの比較。

// React: 依存配列の指定が必要
useEffect(() => {
  console.log(`Count changed to ${count}`);
}, [count]);

// Vue 3: 対象を明示的に指定
watch(count, (newVal) => {
  console.log(`Count changed to ${newVal}`);
});

// Svelte 5: 依存は自動検出
$effect(() => {
  console.log(`Count changed to ${count}`);
});

ここでもSvelteはコンパイラによる自動追跡を活かし、書き手の負担を減らす方向に振り切っている。

$effectは便利だが、副作用の中で$stateを更新するループを無限に組めてしまう。Svelte 5はランタイムで無限ループを検知して止めてくれるが、書き手が気をつけたほうが早い。

4.5 リアクティビティの動作フロー

3者のリアクティビティがどう走るかを、シーケンス図で並べる。

仮想DOMという「試食用の中間工程」をそもそも持たないSvelteは、動作が一段シンプルになっている。

基本概念が揃ったので、次は実際に手を動かして料理を作ってみよう。

---

5. 実際に使ってみよう ─ 環境構築からサンプルアプリまで

5.1 環境構築

SvelteKitで最小構成を立ち上げる手順はこうだ。Node.js 18以上が必要になる。

# Node.jsのバージョン確認（v18以上が必要）
node --version

# プロジェクト作成（対話式）
npx sv create my-svelte-app

# 対話の回答目安:
# - Template: SvelteKit minimal
# - Type checking: TypeScript or JavaScript（好み）
# - Additional options: Prettier, ESLint くらいは入れておくと後が楽

cd my-svelte-app
npm install
npm run dev

ブラウザで http://localhost:5173 を開けばウェルカム画面が出るはずだ。

5.2 設定ファイル ─ 3環境分を用意する

LAPRAS的にも実運用的にも効くのが環境別の設定ファイルを最初から分けておくこと。ここで3環境分をそのまま貼り付ければ使える形で示す。

開発環境用(svelte.config.js)

// svelte.config.js - 開発環境（コピペで使える）
import adapter from '@sveltejs/adapter-auto';

/** @type {import('@sveltejs/kit').Config} */
const config = {
  kit: {
    adapter: adapter(),
    // エイリアス: 開発時のimportを短く
    alias: {
      '$components': 'src/lib/components',
      '$stores': 'src/lib/stores',
      '$utils': 'src/lib/utils'
    }
  },
  compilerOptions: {
    dev: true,        // 開発モード: HMR/デバッグ情報を有効化
    css: 'injected'   // CSSをJSにインライン注入（HMR時にチラつかない）
  }
};

export default config;

本番環境用(svelte.config.production.js)

// svelte.config.production.js - 本番環境（コピペで使える）
import adapter from '@sveltejs/adapter-static';

/** @type {import('@sveltejs/kit').Config} */
const config = {
  kit: {
    adapter: adapter({
      pages: 'build',
      assets: 'build',
      fallback: 'index.html',  // SPAフォールバック
      precompress: true        // gzip/brotliで事前圧縮
    }),
    alias: {
      '$components': 'src/lib/components',
      '$stores': 'src/lib/stores',
      '$utils': 'src/lib/utils'
    },
    csp: { mode: 'auto' }  // CSPヘッダーを自動生成
  },
  compilerOptions: {
    dev: false,         // 本番モード: コード最小化
    css: 'external'     // CSSを外部ファイルに分離（キャッシュが効く）
  }
};

export default config;

テスト/CI用(svelte.config.test.js)

// svelte.config.test.js - テスト/CI環境（コピペで使える）
import adapter from '@sveltejs/adapter-auto';

/** @type {import('@sveltejs/kit').Config} */
const config = {
  kit: {
    adapter: adapter(),
    alias: {
      '$components': 'src/lib/components',
      '$stores': 'src/lib/stores',
      '$utils': 'src/lib/utils',
      '$test': 'src/test'   // テストユーティリティ用
    },
    prerender: { entries: [] }  // テスト時はプリレンダリング無効
  },
  compilerOptions: {
    dev: true,
    css: 'injected',
    accessors: true  // テストからのpropsアクセスを許可
  }
};

export default config;

Vite設定(vite.config.js) ─ 全環境共通

// vite.config.js - 全環境共通（コピペで使える）
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';

export default defineConfig({
  plugins: [sveltekit()],
  server: {
    port: 5173,
    strictPort: false,
    open: true   // 起動時にブラウザ自動オープン
  },
  build: {
    target: 'es2020',
    sourcemap: true,
    rollupOptions: {
      output: { manualChunks: {} }  // 必要に応じてチャンク分割
    }
  },
  envPrefix: 'PUBLIC_'  // クライアントに公開する環境変数の接頭辞
});

npm run build時に使う設定を切り替える場合は、環境変数でconfigファイルを選ぶか、vite.config.js側でmodeに応じて差し替える方式が運用しやすい。

5.3 基本的な使い方 ─ Todoアプリを作る

Svelteの手触りを味わうのに、Todoアプリほど適した教材はない。Runes/双方向バインディング/派生状態が一度に使える。

クリックでTodoアプリ全体ソースコードを展開

<!-- src/routes/+page.svelte -->
<script>
  /**
   * Svelte 5 Runesで書くTodoアプリ
   * $state: リアクティブ状態
   * $derived: 自動計算される派生状態
   */

  // Todoリスト本体
  let todos = $state([
    { id: 1, text: 'Svelteを学ぶ', completed: false },
    { id: 2, text: '記事を書く', completed: true }
  ]);

  // 新規入力バッファ
  let newTodoText = $state('');

  // 派生: 未完了件数
  let remainingCount = $derived(
    todos.filter(t => !t.completed).length
  );

  // 派生: 完了率(%)
  let completionRate = $derived(
    todos.length > 0
      ? Math.round((todos.filter(t => t.completed).length / todos.length) * 100)
      : 0
  );

  function addTodo() {
    if (newTodoText.trim() === '') return;
    todos.push({
      id: Date.now(),
      text: newTodoText.trim(),
      completed: false
    });
    newTodoText = '';
  }

  function removeTodo(id) {
    todos = todos.filter(t => t.id !== id);
  }

  function toggleTodo(id) {
    const todo = todos.find(t => t.id === id);
    if (todo) todo.completed = !todo.completed;
  }

  function handleKeydown(event) {
    if (event.key === 'Enter') addTodo();
  }
</script>

<main>
  <h1>Svelte Todo App</h1>

  <div class="input-area">
    <input
      type="text"
      bind:value={newTodoText}
      onkeydown={handleKeydown}
      placeholder="新しいTodoを入力..."
    />
    <button onclick={addTodo}>追加</button>
  </div>

  <div class="stats">
    <span>残り: {remainingCount}件</span>
    <span>完了率: {completionRate}%</span>
  </div>

  <ul class="todo-list">
    {#each todos as todo (todo.id)}
      <li class:completed={todo.completed}>
        <input
          type="checkbox"
          checked={todo.completed}
          onchange={() => toggleTodo(todo.id)}
        />
        <span>{todo.text}</span>
        <button class="delete-btn" onclick={() => removeTodo(todo.id)}>削除</button>
      </li>
    {/each}
  </ul>

  {#if todos.length === 0}
    <p class="empty-message">Todoがありません。追加してみましょう</p>
  {/if}
</main>

<style>
  main { max-width: 500px; margin: 2rem auto; padding: 1rem; font-family: system-ui, sans-serif; }
  h1 { color: #ff3e00; text-align: center; }
  .input-area { display: flex; gap: 0.5rem; margin-bottom: 1rem; }
  .input-area input { flex: 1; padding: 0.5rem; border: 1px solid #ccc; border-radius: 4px; }
  .input-area button { padding: 0.5rem 1rem; background: #ff3e00; color: white; border: none; border-radius: 4px; cursor: pointer; }
  .stats { display: flex; justify-content: space-between; padding: 0.5rem; background: #f5f5f5; border-radius: 4px; margin-bottom: 1rem; font-size: 0.875rem; color: #666; }
  .todo-list { list-style: none; padding: 0; }
  .todo-list li { display: flex; align-items: center; gap: 0.5rem; padding: 0.75rem; border-bottom: 1px solid #eee; }
  .todo-list li.completed span { text-decoration: line-through; color: #999; }
  .todo-list li span { flex: 1; }
  .delete-btn { padding: 0.25rem 0.5rem; background: #dc3545; color: white; border: none; border-radius: 4px; cursor: pointer; font-size: 0.75rem; }
  .empty-message { text-align: center; color: #999; font-style: italic; }
</style>

注目ポイントは3つある。

1. todos.push(...)が直接動く: React勢には衝撃かもしれないが、配列の破壊的メソッドがそのまま反映される。
2. bind:valueで双方向バインディング: onChangeハンドラを書かなくていい。Vueと同じ感覚。
3. $derivedが依存を自動追跡: todosが変わればremainingCountもcompletionRateも勝手に再計算される。

5.4 よくあるエラーと対処法

実戦でハマりがちなエラーを、原因と対処法込みで一覧にしておく。

エラー	原因	対処法
$state is not defined	Svelte 4環境でRunesを使用	npm update svelte @sveltejs/kitでSvelte 5に更新
Cannot find module '@sveltejs/kit'	依存関係の入れ忘れ	npm installを実行
Port 5173 is already in use	他プロセスがポート占有	npm run dev -- --port 3000で別ポート指定
ReferenceError: document is not defined	SSR実行中にブラウザAPI使用	$effect内に移動、またはbrowserフラグで分岐
Hydration mismatch	SSRとクライアントで異なるHTML生成	動的値はonMount/$effect内で初期化
Runes can only be used inside .svelte	Runesを.jsファイルで使用	.svelte.jsまたは.svelte.ts拡張子にする

5.5 動作確認用の環境診断スクリプト

「なんか動かない」に最速で切り込むための診断コマンド集。

# 環境診断: これを順に叩けば7割の問題は切り分けできる

# 1. Nodeバージョン確認（18以上必須）
node --version

# 2. Svelteバージョン確認（5系であること）
npm list svelte

# 3. 依存関係の破損チェック
npm ls --depth=0 2>&1 | grep -i "error\|warn"

# 4. TypeScript設定の確認（TS使用時）
npx svelte-kit sync

# 5. 型チェックでコンパイルエラーを炙り出す
npm run check

# 6. クリーンビルドで状態をリセット
rm -rf .svelte-kit node_modules/.vite
npm run dev

基本操作が腕に馴染んだところで、次は「どの案件でSvelteを選ぶか」という判断軸に進もう。

---

6. ユースケース別ガイド ─ Svelteを選ぶべきとき、避けるべきとき

6.1 ユースケース1: パフォーマンス最優先のランディングページ

想定シーン: マーケティングチームが広告から流す、コンバージョン命のLP。

構成: SvelteKit + adapter-static(SSG)

なぜSvelteが効くのか: Core Web Vitals(LCP/INP/CLS)は広告配信単価に直結する時代だ。ランタイムサイズ1.6KBという戦闘力は、初回読み込みのJavaScript実行時間で明確に差が出る。料理でいえば、テーブルに即座に出せる「作り置きのデリ」のような速さだ。

Intersection Observerで遅延発火する実装例:

<!-- src/routes/+page.svelte - LPコア部分だけ抜粋 -->
<script>
  import { onMount } from 'svelte';

  let featuresVisible = $state(false);
  let ctaVisible = $state(false);

  onMount(() => {
    const observer = new IntersectionObserver(
      (entries) => {
        entries.forEach(entry => {
          if (entry.target.dataset.section === 'features') {
            featuresVisible = entry.isIntersecting;
          }
          if (entry.target.dataset.section === 'cta') {
            ctaVisible = entry.isIntersecting;
          }
        });
      },
      { threshold: 0.1 }
    );

    document.querySelectorAll('[data-section]').forEach(el => observer.observe(el));
    return () => observer.disconnect();
  });
</script>

<section class="hero">
  <h1>驚異的な速さを体感してください</h1>
  <p>このページはSvelteで作られています</p>
  <a href="#features" class="cta-button">詳しく見る</a>
</section>

<section data-section="features" class="features" class:visible={featuresVisible}>
  <h2>特徴</h2>
  <div class="feature-grid">
    <div class="feature-card"><h3>高速</h3><p>バンドル1.6KB</p></div>
    <div class="feature-card"><h3>軽量</h3><p>仮想DOMなし</p></div>
    <div class="feature-card"><h3>簡潔</h3><p>少コードで多機能</p></div>
  </div>
</section>

6.2 ユースケース2: インタラクティブなデータダッシュボード

想定シーン: 社内向けの分析ダッシュボード。フィルターとチャートが大量にあり、状態が絡み合う。

構成: SvelteKit + Chart.js or D3.js

なぜSvelteが効くのか: $derivedで派生状態を宣言的に書けるため、「フィルター → 集計 → チャート描画」という依存の連鎖をそのままコードに落とせる。料理でいえば「食材 → 今日のメニュー → 必要な皿の数」が自動で連動して決まる厨房のような感覚だ。

集計ロジックの抜粋:

<script>
  // 元データ（実運用ではAPIから取得）
  let rawData = $state([
    { id: 1, category: 'sales', value: 1200, date: '2024-01-15' },
    { id: 2, category: 'marketing', value: 800, date: '2024-02-10' },
    { id: 3, category: 'sales', value: 1500, date: '2024-03-20' }
  ]);

  // フィルター条件
  let selectedCategory = $state('all');
  let dateRange = $state({ start: '2024-01-01', end: '2024-12-31' });

  // 派生1: フィルター後のデータ
  let filteredData = $derived(
    rawData.filter(item => {
      const matchCategory = selectedCategory === 'all' || item.category === selectedCategory;
      const matchDate = item.date >= dateRange.start && item.date <= dateRange.end;
      return matchCategory && matchDate;
    })
  );

  // 派生2: 集計サマリー（filteredDataの変更を自動追跡）
  let summary = $derived({
    total: filteredData.reduce((sum, d) => sum + d.value, 0),
    average: filteredData.length > 0
      ? Math.round(filteredData.reduce((s, d) => s + d.value, 0) / filteredData.length)
      : 0,
    count: filteredData.length
  });

  // 派生3: カテゴリ別内訳（これもsummaryの変更に連動）
  let categoryBreakdown = $derived(() => {
    const breakdown = {};
    filteredData.forEach(item => {
      breakdown[item.category] = (breakdown[item.category] || 0) + item.value;
    });
    return Object.entries(breakdown).map(([category, value]) => ({
      category,
      value,
      percentage: summary.total > 0 ? Math.round((value / summary.total) * 100) : 0
    }));
  });
</script>

この3段の派生をReactで書くとuseMemoと依存配列の沼にハマるが、Svelteなら脳内の依存グラフがそのままコードになる。

6.3 ユースケース3: 大規模エンタープライズ ─ Svelteを避けるべきケース

ここは正直に書く。全案件でSvelteが勝つわけではない。50人以上の開発チームで5年以上運用する業務システムなら、自分はReactを推す。

Reactを推す理由:

1. 採用難易度: Svelte経験者の母数が圧倒的に少ない。継続採用コストが跳ね上がる。
2. エコシステム: Material UI、Ant Design、AG Grid、React Hook Formといった「業務系の面倒をライブラリで解決する資産」がReactには揃っている。Svelteはまだ足りない部分がある。
3. 長期サポート: Metaという後ろ盾とユーザー母数の厚さは、10年後もReactが生きている確度を高めている。

料理の比喩でいえば、Svelteは「少人数の高級店向けのセントラルキッチン」、Reactは「全国展開チェーンの標準キッチン」。適材適所がある。

判断基準サマリー:

要素	Svelte向き	React向き
チーム規模	小〜中(〜20人)	中〜大(20人〜)
プロジェクト期間	短〜中期(〜2年)	長期(2年〜)
パフォーマンス要件	極めて重要	重要だが第一ではない
外部UIライブラリ依存	少ない	多い(MUI/AntD/AG Grid等)
採用計画	既存メンバーで完結	継続採用前提

ユースケースと判断基準が揃ったので、次はこの先どう学ぶかのロードマップに進む。

---

7. 学習ロードマップ ─ 3段階で階段を上る

7.1 初級者向け(まず1週間でここまで)

1. 公式チュートリアルを完走する
   ブラウザ上でインタラクティブに学べる公式教材。所要2〜3時間。これをやらずにSvelteを語るべからず。
2. Todoアプリを自分で拡張する
   本記事のTodoアプリにlocalStorage永続化、カテゴリ分類、期日ソートを足す。Runesへの理解が一段深まる。

7.2 中級者向け(1ヶ月で実戦投入できる)

1. SvelteKit公式ドキュメントを通読
   ルーティング、Load関数、Form Actions、Hooksを把握する。
2. Svelte Storesによる状態管理
   Runesとの使い分け(コンポーネントローカル vs グローバル)を実務で判断できるように。
3. 既存React/Vueプロジェクトへの部分導入
   Viteの複数エントリポイント機能などで、小さな島から試す。

7.3 上級者向け(半年かけてコアに触る)

1. コンパイラのソースを読む
   Svelte GitHubと、Rich Harris氏の講演『Rethinking Reactivity』を通読/通視聴する。
2. パフォーマンスチューニング
   $state.raw()によるProxy回避、仮想リストで数万行を捌くテクニック。
3. OSSコントリビュート
   Contributing Guideに従ってIssueから手を出す。

---

8. まとめと所感

この記事で見てきたSvelteの正体を3行で要約する。

• 「コンパイル時にフレームワークが消える」という発想で、ランタイムコストを極限まで削るフレームワーク
• Svelte 5のRunesで、ReactのHooks/VueのComposition APIに近い明示的な書き味を獲得した
• 適材適所: 小〜中規模のパフォーマンス重視案件には刺さる。大規模エンタープライズでは依然Reactが強い

自分の所感

正直に言うと、Svelteを「万人に勧める」気は、自分にはない。

Reactの圧倒的エコシステムと人材市場、Vueの安定感と親しみやすさ。この2つが築いた壁は、Svelteにはまだ越えきれていない。採用が難しく、エンタープライズ向けライブラリが薄いという弱点は、現場で確実にボディブローになる。

ただ、以下の3条件が揃うプロジェクトなら、Svelteは『検討しないほうが損』だと思っている。

1. パフォーマンスがビジネスKPIに直結している
2. チームが小さく、新しい技術を咀嚼する体力がある
3. React/Vueの書き心地に『なんとなく疲れ』を感じ始めている

3つ目は馬鹿にできない。開発者の「楽しさ」は長期生産性に跳ね返る。State of JSでSvelteが満足度上位常連なのは、数字には出ない何かを捉えている証拠だ。

自分自身、最初は懐疑派だった。今は『新規の小〜中規模プロジェクトなら、まずSvelteで検討する』側に回っている。それぐらいの価値がある。

まずは公式チュートリアルを30分触ってほしい。「あ、これ書いてて楽しいな」という感覚が来たら、それがSvelteを選ぶ最大の根拠になる。

草

---

参考文献

• Svelte公式ドキュメント
• SvelteKit公式ドキュメント
• Svelte 5 Runesガイド
• Rich Harris: Rethinking Reactivity(YouTube)
• State of JS 2024
• Svelte - Wikipedia

関連記事

Svelte

Svelteと相性抜群の技術スタック

JavaScript

TypeScript

React

Hono

Express

Bun

---

記事が役に立ったら、X(@geneLab_999)もフォローしてもらえると嬉しいです。最新のAI/フロントエンド/ローカルLLMまわりの情報を日々つぶやいています。