SvelteKitとは？Svelteとの違い・始め方とv3の変更点【2026年9月】

SvelteKit（スベルトキット）は、UIフレームワークのSvelteでWebアプリ全体を作るための公式フレームワークです。ReactにとってのNext.js、VueにとってのNuxtにあたります。この記事では、2026年9月時点の現行版 2.70.3 を使い、sv create で生成されるファイル、ルーティングとフォーム処理、SSR・SSG・CSRの選び方、Vercelなどへのデプロイを実際に動かした結果とあわせて説明します。開発が進んでいる SvelteKit 3 で書き方がどう変わるかも最後に整理します。

まとめ：SvelteKitの要点と2026年9月の現行版

SvelteKitは、Svelteで作った画面部品に、URLごとのページ分け・サーバー処理・ビルド・デプロイを加えるフレームワークです。現行の安定版は 2.70.3（2026年8月18日公開）で、2023年12月の2.0以降、71本のマイナー版を重ねています。

新しく始めるなら npx sv create で作成し、設定は vite.config.ts の sveltekit({...}) に書きます。2.62.0 からこの書き方ができるようになり、2026年9月の sv 0.17.1 は svelte.config.js を生成しません。次期の SvelteKit 3 は 3.0.0-next.29（2026年9月25日）まで進んでおり、svelte.config.js の廃止、$lib から #lib への変更、Node.js 22.17 以上の必須化が入ります。新規開発では設定をVite側にまとめ、Node.jsの要件を満たし、エイリアス変更への対応箇所を把握しておくと移行準備になります。

レンダリングは既定がSSRで、ページごとに prerender・ssr・csr の3つの変数で切り替えます。デプロイ先は「アダプター」で決まり、Vercel・Netlify・Cloudflareなら既定の adapter-auto が自動で判別します。

SvelteとSvelteKitの違いと読み方

Svelteは画面の部品（コンポーネント）を書くためのフレームワークで、SvelteKitはその部品を並べて1つのサイトやアプリに仕上げる土台です。読み方は「スベルトキット」で、「スヴェルトキット」と書かれることもあります。

画面の一部にSvelteの部品を埋め込むだけならSvelte単体で足ります。ページが複数あり、サーバーでデータを取ったりフォームを受けたりするならSvelteKitを使います。Svelte本体の書き方や、React・Vueと比べた採用判断はSvelteの将来性・普及率とReact/Vue比較で扱っています。

SvelteKitのルーティングとサーバー処理

SvelteKitのページは、src/routes 以下のフォルダ構成がそのままURLになります。どのファイルに何を書くかが決まっているので、ファイル名の意味を覚えるのが最初の作業です。

src/routes のファイル規約

たとえば src/routes/about/+page.svelte は /about に、src/routes/blog/[slug]/+page.svelte は /blog/記事名 のような動的URLになります。データベースの接続情報やAPIキーを扱う処理は、ブラウザへ送られない .server.ts 側に置きます。

load関数とフォームアクションの書き方

ページに渡すデータは load 関数で返し、フォームの送信は actions で受けます。次の例は、一覧を表示して1件追加するだけの最小構成です（SvelteKit 2.70.3 で型チェックとビルドを通し、動作を確認しました）。

// src/routes/todos/+page.server.ts
import { fail } from '@sveltejs/kit';
import type { Actions, PageServerLoad } from './$types';

// ローカル学習用：同一プロセスの全利用者で共有され、再起動すると消えます。
// 本番では認証済み利用者ごとにアクセス制御したDBなどへ保存してください。
const todos: string[] = ['SvelteKitを入れる'];

export const load: PageServerLoad = async () => {
	return { todos };
};

export const actions = {
	default: async ({ request }) => {
		const data = await request.formData();
		const text = String(data.get('text') ?? '').trim();
		if (!text) return fail(400, { missing: true });
		todos.push(text);
	}
} satisfies Actions;

<!-- src/routes/todos/+page.svelte -->
<script lang="ts">
	import { enhance } from '$app/forms';
	let { data, form } = $props();
</script>

<ul>
	{#each data.todos as todo}
		<li>{todo}</li>
	{/each}
</ul>

<form method="POST" use:enhance>
	<input name="text" />
	{#if form?.missing}<p>入力してください</p>{/if}
	<button>追加</button>
</form>

フォームは use:enhance を付けなくても通常のHTMLフォームとして動き、JavaScriptが無効な環境でも送信できます。空文字で送ると fail(400, ...) が返り、画面に「入力してください」が出ます。

ここで1点、2.x特有の挙動があります。use:enhance を付けない通常のPOSTではHTTPステータスが400になるのに対し、use:enhance 経由の送信ではレスポンスが200のまま、本文に "type":"failure","status":400 が入ります（手元のpreviewサーバーで確認）。テストやログでステータスコードを見て失敗を判定しているなら、2.xでは本文側を見る必要があります。この挙動はSvelteKit 3で fail に渡した値へ揃います。

APIエンドポイント（+server.ts）

画面を持たないAPIは +server.ts にHTTPメソッド名の関数を書きます。

// src/routes/api/hello/+server.ts
import { json } from '@sveltejs/kit';
import type { RequestHandler } from './$types';

export const GET: RequestHandler = ({ url }) => {
	const name = url.searchParams.get('name') ?? 'SvelteKit';
	return json({ message: `Hello, ${name}` });
};

/api/hello?name=issoh にアクセスすると {"message":"Hello, issoh"} が返ります。なお json ヘルパーはSvelteKit 3で非推奨になるため、3系では標準の Response.json() へ置き換えることになります。

SSR・SSG・CSRの選び方（ページオプション）

SvelteKitは既定で全ページをサーバーで描画し（SSR）、HTMLを返した後にブラウザ側で動く状態へ切り替えます。SSRは検索エンジンが本文を取得しやすくするため、公開ページでは維持するのが基本です。ただし、SSRにしてもページごとの <title> と meta description は自動では入らないので、各ページの <svelte:head> に書きます。ページごとの切り替えは、+page.ts か +layout.ts で次の変数を書き出すだけです。

まず src/routes/about/+page.svelte を作成し、ページ内容を書きます。同じフォルダの +page.ts に export const prerender = true; を置いてビルドすると、.svelte-kit/output/prerendered/pages/about.html が出力されました。

判断基準ははっきりしています。公開ページで ssr = false を全体に掛けるのは避けてください。公式ドキュメントのSPAの章は、HTMLの取得・JavaScriptの取得・データの取得と往復が重なって表示が遅れ、Core Web Vitalsで不利になりSEOを損なうと明記しています。全ページを事前生成できるなら adapter-static によるSSGに、できないならSSRできるアダプターにするのが公式の推奨です。Next.jsのSSG・ISR・SSRとの比較はNext.jsのレンダリング方式の違いと選び方が参考になります。

sv createでの始め方（2026年9月の実測）

プロジェクトの作成は公式CLIの sv で行います。古い記事にある npm create svelte@latest（create-svelte パッケージ）は非推奨になっており、npm上でも sv を使うよう案内されています。以下は macOS・Node.js v26.5.0 で実行した結果です。

プロジェクトの作成と起動

# 対話なしで作成（最小テンプレート＋TypeScript＋npmで依存を導入）
npx [email protected] create my-app --template minimal --types ts --no-add-ons --install npm

cd my-app
npm run dev      # http://localhost:5173/ で起動
npm run build    # 本番ビルド

引数を省くと対話形式になり、テンプレート（minimal・demo・library・addon）、型チェック（ts か jsdoc）、アドオンを順に選びます。作成後の npm run dev で http://localhost:5173/ を開くと「Welcome to SvelteKit」が表示され、npm run build は1.97秒で終わりました。

ビルドの最後に Could not detect a supported production environment と出ますが、これはエラーではありません。既定の adapter-auto がローカルではデプロイ先を判別できないという通知で、ビルド自体は完了しています。

生成されるファイルとNode.jsの要件

最小テンプレートで作られた主なファイルは package.json・vite.config.ts・tsconfig.json・src/app.html・src/app.d.ts・src/lib/index.ts・src/routes/+layout.svelte・src/routes/+page.svelte・static/robots.txt です。以前は必ずあった svelte.config.js が無く、設定は vite.config.ts にまとまっています。

// vite.config.ts（sv 0.17.1 が生成した内容からコメントを除いたもの）
import adapter from '@sveltejs/adapter-auto';
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';

export default defineConfig({
	plugins: [
		sveltekit({
			compilerOptions: {
				runes: ({ filename }) =>
					filename.split(/[/\\]/).includes('node_modules') ? undefined : true
			},
			adapter: adapter()
		})
	]
});

導入されたのは @sveltejs/kit 2.70.3・svelte 5.57.1・vite 8.3.1 でした。Node.jsの要件は、SvelteKit本体の表記（18.13以上）より厳しくなります。Vite 8 は ^20.19.0 || >=22.12.0 を要求し、生成された .npmrc には engine-strict=true が入っているため、Node.js 18系ではインストールの段階で止まります。これから入れるなら、SvelteKit 3の下限と同じ 22.17 以上にしておくと後で入れ替えずに済みます。

sv addで追加できる公式アドオン

後から機能を足すときは npx sv add <アドオン名> を使います。sv 0.17.1 の公式アドオンは次の13種類です。

• 品質：prettier・eslint・vitest・playwright・storybook
• 画面：tailwindcss・mdsvex・paraglide（多言語化）
• サーバー：drizzle・better-auth・sveltekit-adapter
• その他：ai-tools（Claude Code・Cursor等向けのMCP設定やスキル）・experimental（remote functions等の実験機能を有効化）

データベースは drizzle で、PostgreSQL・MySQL・SQLite・Cloudflare D1から選べます。Drizzle自体の使い方はDrizzle ORMの使い方とPrismaとの比較、認証はbetter-authの使い方とauth.jsとの違い、ブラウザ上でのコンポーネントテストはVitest Browser Modeの導入手順にまとめています。

デプロイ先とアダプターの選び方（Vercel・Cloudflare・Node）

SvelteKitは、ビルド結果をデプロイ先ごとの形式に変換する「アダプター」を差し替えて各環境に対応します。既定の adapter-auto は、Cloudflare Pages・Netlify・Vercel・Azure Static Web Apps・AWS（SST経由）・Google Cloud Runを自動で判別します。

Vercelへのデプロイは、GitHubにpushしたリポジトリをVercelの管理画面でImportするだけで動きます。adapter-auto がVercel上で adapter-vercel を選ぶためです。ただし、ISR（一定時間ごとの再生成）、Edge関数、関数の実行リージョンといった設定は adapter-auto では渡せません。npm i -D @sveltejs/adapter-vercel で直接入れて vite.config.ts の adapter を差し替えます。

デプロイ先が決まったら、adapter-auto のまま運用せず専用アダプターへ切り替えるのが公式の推奨です。lockfileに固定され、CIでのインストールも速くなります。Cloudflare向けは wrangler 4系が前提で、自社サーバーやDockerで動かすなら adapter-node を選びます。

SvelteKit 2.x後半の変化とSvelteKit 3で変わる点

「sveltekit」の検索結果で上位に出る日本語の入門記事3本は、いずれも sv にもSvelteKit 3にも触れておらず、うち2本は非推奨の npm create svelte@latest で説明しています。2025年以降の変化で実務に効くものは次のとおりです。

2.27〜2.70で入った機能

remote functionsは、.remote.ts に書いたサーバー関数をコンポーネントから型付きで直接呼べる仕組みで、query・form・command・prerender の4種類があります。便利ですが、2.70.3の公式ドキュメントは「現在は実験機能で、予告なく変わりうる」と明記しており、experimental.remoteFunctions と compilerOptions.experimental.async を有効にしないと使えません。SvelteKit 3の移行ガイドでも実験扱いのままです。業務システムのデータ層をいまremote functionsだけで組むのは勧めません。安定したAPIが要る箇所は load とフォームアクションで書き、remote functionsは差し替えやすい範囲にとどめるのが安全です。

SvelteKit 3の最低要件と主な破壊的変更

SvelteKit 3は 3.0.0-next.0（2026年6月5日）から開発版の公開が続き、2026年9月25日に next.29 が出ています。正式版は9月27日時点でnpmの latest に出ていません。公式の移行ガイド（Migrating to SvelteKit v3）が挙げる最低要件（2026年9月27日確認）は、Node.js 22.17・TypeScript 6・Svelte 5.57.1・Vite 8.0.12・vite-plugin-svelte 7 です。

多くは npx sv migrate sveltekit-3 で自動変換でき、公式は移行前に最新の2.xへ上げて非推奨警告を消しておくよう勧めています。いま2.xで新規に書くなら、svelte.config.js を作らず vite.config.ts に設定を書く、$app/stores ではなく $app/state を使う、Node.jsを22.17以上にする、の3点は移行準備になります。ただし、依存パッケージの更新やエイリアス、削除APIなどへの対応も必要で、残る作業量は利用機能によって異なります。

SvelteKitが向く案件・向かない案件

2026年9月19日〜25日の週間ダウンロード数は、@sveltejs/kit が311万回、next が6,669万回、nuxt が238万回でした。CIでの再インストールも数えるため利用者数とは一致しませんが、SvelteKitはNuxtを約1.3倍上回り、Next.jsとは約21倍の差があります。

向いているのは、初期表示の速さや配信サイズが評価に直結する公開サイトやメディア、少人数で作って自分たちで保守する社内ツールやSaaSの管理画面です。SSR・SSG・CSRをページ単位で混ぜられ、フォームがJavaScriptなしでも動くので、画面数が増えても構成が崩れにくい作りです。

避けるべきなのは、React Nativeとコンポーネントを共有したい案件と、React経験者の採用を前提に体制を組む案件です。引き継ぎ先がReactを標準にしている場合もNext.jsを優先候補にします。外注への引き継ぎがあるだけならSvelteKitを外す理由にはならず、引き継ぎ先にSvelteの開発実績があるかで決めてください。Svelteそのものの採用可否は、Svelteの普及率と採用判断で数字を挙げて検討しています。

よくある質問

SvelteKitの読み方は？

「スベルトキット」と読みます。「スヴェルトキット」と表記されることもあります。Svelteは英語で「ほっそりした」「洗練された」という意味の形容詞です。

SvelteKitは無料で使えますか？

SvelteKit自体の利用料はかかりません。MITライセンスのオープンソースで、商用利用もできます。運用費用は構成によって異なり、ホスティングのほか、独自ドメインや外部サービスの費用が発生する場合があります。

SvelteKitとNext.jsの違いは何ですか？

土台のUIフレームワークが違います。SvelteKitはSvelte、Next.jsはReactの上に作られています。ファイルベースのルーティング、SSR・SSGの切り替え、サーバー処理を持つ点は共通です。フォーム処理はどちらもJavaScriptが無効でも送信できますが、書く場所が違います。SvelteKitは +page.server.ts の actions で受け、Next.jsは 'use server' を付けたServer Actionをフォームの action に渡します。利用規模はNext.jsが週間ダウンロード数で約21倍です。

SvelteKitでPWAは作れますか？

作れます。src/service-worker.js（または src/service-worker/index.js）を置くと、SvelteKitが自動でバンドルしてブラウザに登録します。オフライン対応やビルド済みJS・CSSの事前キャッシュはこのファイルに書きます。Webアプリマニフェスト（manifest.json）は自動生成されないので、static フォルダに自分で置きます。

SvelteKit 3はいつリリースされますか？

2026年9月27日時点で正式版は出ておらず、npmでは 3.0.0-next.29 が next タグで配布されています。本番で使うなら現行の2.70系にとどめ、本記事の「SvelteKit 3で変わる点」の3点を先に済ませておくと、正式版が出たときに移行しやすくなります。

関連記事

• Svelteの将来性は？普及率・デメリットとReact/Vue比較で採用判断
• Next.jsのレンダリング方式｜SSG・ISR・SSR・CSRの違いとApp Routerでの選び方
• Drizzle ORM（ドリズル）とは？使い方・Prismaとの比較・v1.0 RCの変更点【2026年9月】
• better-authとは？auth.jsとの違い・使い方とJWT・Redis対応を解説
• Vitest Browser Modeの導入・セットアップ方法を徹底解説