Svelte 5正式リリース後のエコシステム：Runesで何が変わった？周辺ライブラリの対応状況を徹底調査

Svelte 5は2024年10月19日に正式リリースされたんだけど、最大の変更がRunesという新しいリアクティビティシステムなんだ。18ヶ月もの開発期間をかけて、Svelteの根幹を作り直したんだよ。

簡単に言うと、「データが変わったら画面も自動で更新される」仕組みのことだね。Svelte 4までは、letで変数を宣言すると自動的にリアクティブになってた。でもSvelte 5からは、明示的に$state()を使って「これはリアクティブな変数です」って宣言するようになったんだ。

いや、実は逆なんだ。確かに一見面倒に見えるけど、明示的にすることでどこでもリアクティビティが使えるようになったんだよ。

Svelte 5で導入された主なRunesは次の4つだよ。

1. $state: リアクティブな状態を宣言する
2. $derived: 他の状態から計算される値を作る
3. $effect: データが変わったときに実行する処理を書く
4. $props: コンポーネントのプロパティを受け取る

これらを使うことで、.svelteファイルの外でもリアクティビティが使えるようになったんだ。

例えば、utils.svelte.jsみたいなファイルを作って、そこでリアクティブなロジックを書けるようになったんだ。今までは、Svelteファイルの外に出すとリアクティビティが失われて、Storeを使うしかなかったんだけど、Runesならそれが不要になる。

しかもパフォーマンスも改善されてる。バンドルサイズが15-30%小さくなって、ツリーシェイキング（使わないコードを削除する最適化）も改善されたんだよ。

そうなんだ。でも、大きな変更だから、周辺ライブラリがちゃんと対応できてるか気になるよね。じゃあ、実際のエコシステムを見ていこう。

そう！Svelte 5のリリース後、主要なUIライブラリは続々と対応を進めてる。大きく分けて「完全対応済み」「部分的対応」「Headlessライブラリ」の3つに分類できるね。

まず、完全にSvelte 5に対応したライブラリから紹介するね。

Svelte Material UI、通称SMUIは、Googleのマテリアルデザインを実装したライブラリなんだ。バージョン8からSvelte 5必須になってる。

そう。SMUIはバージョンで対応を分けてる。

• SMUI v8: Svelte 5専用
• SMUI v7: Svelte 4対応の最終バージョン

新しいイベントシステムにも対応してるから、Svelte 5の機能を最大限活用できるようになってるんだよ。

Skeletonは、バージョン3.0でSvelte 5とTailwind CSS v4の両方に対応した。しかもモジュラー構造になって、必要なコンポーネントだけ選んで使えるようになったんだ。

必要なものだけインポートできるから、バンドルサイズが小さくなるんだ。全部入りのライブラリだと、使わないコンポーネントまで含まれちゃうでしょ？モジュラーならそれを避けられる。

shadcn-svelteは、React界隈で人気のshadcn/uiのSvelte版だね。Svelte 5対応に加えて、Tailwind CSS v4のサポートと新しいチャートコンポーネントも追加されてる。

shadcn/uiはReactエコシステムでめちゃくちゃ人気なんだ。コピペで使えるコンポーネント集って感じで、カスタマイズしやすいのが特徴だね。

Flowbite Svelteも対応済みで、60以上のUIコンポーネントを提供してる。ボタン、モーダル、ドロップダウンなど、Webアプリでよく使うものが一通り揃ってるよ。

Carbon Components Svelteは、IBMのCarbon Design Systemを実装したライブラリなんだ。現在v0.93.0まで更新されてて、Svelte 5の互換性修正も行われてる。

いや、使えるよ。v0.83.0でSvelte 5対応の修正が入ってるから。ただ、関連パッケージが複数あって、それぞれ対応状況が少し違うんだ。

• Carbon Components Svelte: v0.93.0（対応済み）
• Carbon Icons Svelte: Svelte 4/5両方サポート
• Carbon Charts Svelte: Svelte 5.20+推奨

という感じだね。

ハハハ、面白い発想だね。Headlessライブラリは、スタイルがないUIライブラリのことなんだ。機能とアクセシビリティだけ提供して、見た目は自分で自由にカスタマイズできる。

良い質問だね。例えば、アクセシブルなドロップダウンメニューを作るって、実はすごく大変なんだ。キーボード操作、スクリーンリーダー対応、フォーカス管理...考えることがたくさんある。Headlessライブラリは、そういう難しい機能部分だけを提供してくれるんだよ。

Bits UIは、Svelte 5専用に設計されたHeadlessライブラリだね。Melt UIという別のライブラリの上に構築されてて、より使いやすいコンポーネントAPIを提供してる。フルアクセシビリティサポートも売りの一つだよ。

Melt UIは、Svelte 5のRunes（$state、$derived）をサポートしてる。こっちはコンポーネントビルダーって感じで、より低レベルな制御ができるんだ。

Melt UIが低レベルで柔軟性が高い代わりに使いこなすのが難しくて、Bits UIがその上に構築された使いやすいバージョンって感じかな。料理で言えば、Melt UIは食材を選んで自分で調理する感じで、Bits UIは半調理済みの便利なキットって感じだね。

SVARは、エンタープライズグレードのアプリケーション向けに設計されたライブラリだね。v2.1でDataGridとGanttチャートが追加されたんだ。

Excelみたいな表を表示できるコンポーネントだよ。大量のデータを表示して、ソートしたりフィルタしたりできる。業務アプリケーションには欠かせない機能だね。

SvelteKitは完全に対応してるよ。実は、Svelte 5はほぼ完全にSvelte 4と後方互換性があるんだ。

そう！既存のSvelte 4のコンポーネントは、ほとんどそのままSvelte 5でも動く。しかも、SvelteKit 2を使うとSvelte 5への移行がさらにスムーズになるんだ。

SvelteKitのルーティングシステムは、Svelte 4でもSvelte 5でも同じなんだ。ファイルシステムベースのルーティングで、src/routes以下のディレクトリ構造がそのままURLになる。

例えば、src/routes/about/+page.svelteを作ると、自動的に/aboutというURLでアクセスできるようになる。Next.jsとかNuxtと同じ考え方だね。しかも<a>タグで普通にリンクするだけでいい。フレームワーク固有の<Link>コンポーネントとか不要なんだ。

SvelteKit 2.12では、Svelte 5のRunes APIをベースにした$app/stateが追加されたんだ。従来の$app/storesの機能を提供しつつ、より柔軟になってる。

$app/stateはRunesベースだから、より直感的にリアクティブな状態を扱えるんだ。Storeのsubscribeとかsetとか、ちょっと複雑だったでしょ？Runesなら普通の変数みたいに扱えるから、コードがシンプルになるよ。

いや、Storeは非推奨ではないよ。引き続き使えるし、特定のケースでは今でも有効なんだ。

そう。Svelteチームは後方互換性を大切にしてるからね。ただ、多くのケースでRunesのほうが便利だから、新しいコードではRunesを使うのがおすすめだよ。

Runesが特に便利なのは、次の3つのケースだね。

1. ロジックの抽出: コンポーネントから共通ロジックを切り出すとき
2. 共有状態: 複数のコンポーネントで同じ状態を使うとき
3. TypeScriptファイルでの使用: .svelte.jsや.svelte.tsファイルで状態管理したいとき

今まではこういうケースでStoreを使うしかなかったけど、Runesなら普通の関数として書けるんだ。

逆に、Storesがまだ有効なのは、こういうケースだよ。

1. 複雑な非同期データストリーム: WebSocketとか、リアルタイムで更新されるデータ
2. 細かい制御が必要: 値の更新やリスニングを細かく管理したいとき

例えば、チャットアプリでメッセージがリアルタイムで送られてくる場合とか、株価が刻々と更新される場合とかだね。そういう複雑な非同期処理では、Storeの方が扱いやすいこともあるんだ。

フォームライブラリは、正直まだ過渡期って感じだね。既存のライブラリの対応状況と、新しい選択肢を紹介するよ。

Felteは、Svelteのストアとアクションをベースにしたフォームライブラリだね。yup、zod、superstruct、vestなど、人気のバリデーションライブラリと組み合わせて使えるのが特徴だよ。

zodは、TypeScriptのスキーマバリデーションライブラリだね。「このフィールドは文字列で、最低5文字以上」みたいなルールを型安全に定義できるんだ。フォームのバリデーションによく使われるよ。

ただ、FelteのSvelte 5対応については、明確な情報が見つからなかったんだ。ストアとアクションをベースにしてるから、後方互換性で動くはずだけど、明示的なサポート表明はまだみたいだね。

svelte-forms-libは、ReactのFormikライクなAPIを持つ軽量ライブラリだね。初心者にも優しいドキュメントが特徴なんだけど...

最終更新が4年前（v2.0.1）なんだ。だから、Svelte 5への明示的な対応はまだないと思われる。後方互換性で動く可能性は高いけど、新しいプロジェクトにはあまり推奨できないかな。

でも、Svelte 5時代の新しい選択肢もあるんだ！

Superformsは、SvelteKit専用のフォームライブラリなんだ。サーバーサイドとクライアントサイドの両方でバリデーションできるのが大きな特徴だよ。

セキュリティのためだね。クライアント側のバリデーションだけだと、悪意のあるユーザーがブラウザの開発者ツールで回避できちゃう。だから、サーバー側でも必ずチェックする必要があるんだ。Superformsは、この二重チェックを簡単に実装できるようになってる。

Formsnapは、SuperformsとZodの上に構築された高レベルコンポーネントライブラリだね。より宣言的にフォームを書けるようになってる。

プログラムで「どうやるか」じゃなくて「何がほしいか」を書くスタイルのことだね。例えば、「このフィールドはメールアドレスで、必須です」って宣言するだけで、バリデーションやエラー表示を自動でやってくれる感じだよ。

アニメーション関連は、正直まだ課題があるんだ。特に人気だったsvelte-motionが、現状Svelte 5に対応してないんだよ。

svelte-motionは、ReactのFramer Motionにインスパイアされた人気ライブラリだったんだけど、最終更新が約1年前で、メンテナンスが停滞してるんだ。

大丈夫、代替案があるよ！

@animotion/motionは、シンプルなSvelteアニメーションライブラリだね。時間経過とともに変化する値を使って、どんなプロパティでもアニメーション化できるんだ。

いや、必要な機能は揃ってるよ。svelte-motionほど高機能じゃないけど、基本的なアニメーションなら十分できる。しかもSvelte 5対応だから安心して使えるね。

あと、Tailwind CSSを使ったアニメーションも選択肢の一つだよ。Tailwindには豊富なアニメーションユーティリティが組み込まれてるから、簡単なアニメーションならライブラリなしでもいけるんだ。

svelte-motionからの移行を考えてる人向けに、Motion-Startという移行パスもあるよ。svelte-motionのコンポーネントをSvelte 5対応に変換するのを助けてくれるんだ。

テストライブラリは、比較的対応が進んでるよ。特に**@testing-library/svelte**が、実験的ながらSvelte 5サポートを開始してる。

@testing-library/svelteは、Svelte 3、4、5すべてをサポートしてる。推奨される組み合わせはVitestと一緒に使うことだね。

Vitestは、Vite（ヴィート）というビルドツールのための高速テストランナーだよ。Jestと互換性があるAPIを持ってるから、Jestから移行しやすいんだ。しかも、めちゃくちゃ速い。

Svelte 5でテストを始めるには、いくつかのパッケージをインストールする必要があるんだ。

1. @testing-library/svelte
2. @testing-library/jest-dom
3. @sveltejs/vite-plugin-svelte
4. vitest
5. jsdom

そして、vite.config.tsにsvelteTestingプラグインを追加する必要があるよ。

jsdomは、Node.js環境でブラウザのDOM（Document Object Model）をシミュレートするライブラリだね。つまり、実際のブラウザを起動しなくても、ブラウザっぽい環境でテストできるようになるんだ。

最近、新しいアプローチも登場してるんだ。Vitest Browser Modeっていって、jsdomのシミュレーション環境じゃなくて、実際のブラウザでテストを実行するんだよ。

確かに少し遅くはなるけど、その分より現実に近い環境でテストできるんだ。jsdomは完璧じゃないから、たまに「テストは通るのに、実際のブラウザでは動かない」ってことがある。Vitest Browser Modeなら、そういう問題を減らせるんだよ。

そう、現在は実験的な機能だから、APIが今後変わる可能性があるんだ。プロダクションで使うなら、Vitestのバージョンを固定しておくのがおすすめだね。

正直に言うと、プロジェクトの規模や使ってるライブラリによって大変さは変わってくるね。実際に移行した人たちの経験をまとめてみよう。

Svelte 5のエコシステムは、まだ完全に成熟してるとは言えないんだ。多くのライブラリ作者が、正式リリースを待ってから対応を始めたから、対応状況にばらつきがあるんだよ。

でも、主要なライブラリはほとんど対応してるから、普通のWebアプリなら十分開発できるよ。むしろ、ニッチなライブラリを使ってる場合に注意が必要って感じだね。

Svelte 5には、自動でコードを移行してくれるスクリプトがあるんだけど、完璧じゃないんだ。特に、$:（リアクティブステートメント）を$derived()に変換すべきか、$effect()に変換すべきか、判断を間違えることがあるんだよ。

Svelte 4までの書き方で、「この変数が変わったら、この計算を自動でやり直す」っていう宣言だったんだ。でもSvelte 5では、計算なら$derived()、副作用なら$effect()と、明確に分けるようになった。自動スクリプトは、この使い分けを完璧に判断できないことがあるんだよね。

すべてを直す必要はないよ。移行スクリプトが8割くらいはやってくれるから、残りの2割を手作業で調整する感じだね。テストをしっかり書いておけば、問題のある箇所はすぐ見つかるよ。

移行中は、古いStoreベースのコードと新しいRunesベースのコードが混在することになるんだ。チームで開発してる場合、「どっちのパターンを使えばいいの？」って混乱することがあるみたいだね。

明確なガイドラインを決めておくのがおすすめだよ。例えば、「新しいコードは全部Runesで書く」「既存のStoreコードは、大きな変更のタイミングで移行する」みたいな感じでね。

Svelte 5のリリース後、かなり頻繁にアップデートがあったんだ。バグ修正や改善が次々と入ってくるから、本番環境に投入するタイミングが難しいって声もあるね。

良いことなんだけど、本番環境ではできるだけ安定してるバージョンを使いたいでしょ？頻繁にアップデートがあると、「今アップデートしても、来週また新しいバージョンが出るかも」って悩んじゃうんだよね。

2025年11月時点では、十分プロダクションレディだと言えるよ。実際に移行したチームからは、パフォーマンス向上が確認されたって報告が多いんだ。

Svelte 5に移行するメリットは次の通りだよ。

1. パフォーマンス向上: バンドルサイズ15-30%削減、実行速度も向上
2. 開発体験の改善: Runesによる明示的で予測可能なコード
3. エコシステムの成熟: 主要ライブラリはほぼ対応済み
4. 後方互換性: 既存のSvelte 4コードもほぼそのまま動く

ただ、移行するなら次のことに注意してね。

1. 依存ライブラリの確認: 使ってるライブラリがSvelte 5に対応してるか事前チェック
2. 段階的な移行: 一度に全部変えるんじゃなくて、少しずつ移行する
3. テストカバレッジ: 移行前にテストを充実させておく
4. チームガイドライン: StoreとRunesの使い分けルールを決めておく

例えば、新しい機能はSvelte 5とRunesで書いて、既存のコードは動いてる限りそのままにしておく。そして、バグ修正や大きな変更のタイミングで、少しずつSvelte 5の書き方に移行していく感じだね。

Svelte 5とそのエコシステムについて、ずいぶん長く話したね。最後にポイントをまとめよう。

まず、Svelte 5は2025年時点で十分プロダクションレディだ。Runesという新しいリアクティビティシステムは、最初は戸惑うかもしれないけど、慣れればより明示的で理解しやすいコードが書けるようになる。

エコシステムも成熟してきてる。UIライブラリ（SMUI、Skeleton、shadcn-svelte、Flowbite）、SvelteKit、テストライブラリは完全対応済み。状態管理はRunesが基本だけど、Storesも引き続き使える。

注意が必要なのはアニメーションライブラリだね。svelte-motionが対応してないから、代替案（@animotion/motion、Tailwind CSS）を検討する必要がある。フォームライブラリも、新しい選択肢（SuperformsやFormsnap）を検討したほうがいいかもしれない。

そうだね。ただ、移行は段階的に、テストを書きながら慎重に進めるのがおすすめだよ。急いで全部変える必要はないからね。

どういたしまして。Svelte 5は本当に良いフレームワークだから、ぜひ試してみてね！