Svelteの2026年9月更新には、安定版Svelte 5.57の使い勝手を整える変更と、SvelteKit 3 Release Candidate（RC）の移行準備が並んでいます。同じ月次更新に見えても、既存アプリへ入れるときの判断は同じではありません。

Svelte 5.57だけを取り込みたいなら、注目点は小さなAPI改善です。一方のSvelteKit 3は、Node.jsやTypeScript、Viteの最低バージョンに加え、設定ファイル、インポート、フォーム遷移まで見直すメジャー移行になります。

では、今すぐ使える変更と検証ブランチで試す変更を、どこで分ければよいのでしょうか。実装例と移行順をつなげて整理します。

SvelteMapの「取得または初期化」で分岐を一つ減らせる

Svelte 5.57.0では、SvelteMapにgetOrInsertとgetOrInsertComputedが加わりました。SvelteMapは組み込みのMapをリアクティブにしたクラスで、getやhas、反復処理で読んだ内容は、マップの更新に応じてeffectやderivedで再評価されます。型シグネチャはSvelteのリアクティビティAPIで確認できます。

たとえば、ラベル別のカウンターを初めて触るときだけ0で初期化する処理は、hasとsetを分けずに書けます。

import { SvelteMap } from "svelte/reactivity";

const counts = new SvelteMap<string, number>();

function increment(label: string): void {
  const current = counts.getOrInsert(label, 0);
  counts.set(label, current + 1);
}

初期値の生成に計算が必要なら、getOrInsertComputed(key, callback)を使うと、キーが存在しない場合だけコールバックが呼ばれます。ただし、SvelteMapに入れたオブジェクトや配列は深くリアクティブにはなりません。内側だけを変更して表示更新まで期待する設計では、リアクティブな値を使うか、新しい値をsetし直す必要があります。

同じ5.57.0では、createContextが[get, set, has]の3関数を返すようになりました。Contextの公式ドキュメントにある通り、hasなら未設定時にgetのエラーを起こさず存在確認できます。<select defaultValue>のフォームリセット対応や、svelte/serverのレンダー出力・CSP関連型の公開も、既存コードの小さな分岐や独自型を減らす方向の更新です。

SvelteKit 3 RCでは依存条件とアプリの境界が同時に変わる

Svelte 5.57の改善とは対照的に、SvelteKit 3は2026年9月1日時点でRCの@next系列です。2026年8月13日のRC告知後もプレリリースは更新され、3.0.0-next.17からnext.25では、ページをまたぐform action、アダプターのViteプラグイン、defineParamsの公開場所などに破壊的変更が入りました。RCは安定版と同義ではない、と分かります。

さらに、SvelteKit 3移行ガイドが示す最低条件はNode.js 22.17、TypeScript 6、Svelte 5.56.4、Vite 8.0.12、@sveltejs/vite-plugin-svelte 7です。アプリのソースだけでなく、CI、ビルドイメージ、エディターや型チェックまで同じ検証単位に入ります。

大きな構造変更は、SvelteKitの設定がvite.config.jsへ移り、svelte.config.jsが非対応になることです。$app/stores‘\text{の}\text{削}\text{除}\text{、}‘$app/environmentから$app/envへの改名、shallow routingのgotoへの統合、エラー処理やservice worker APIの変更もあるため、依存パッケージの更新だけで完了したとは判断できません。

$libから#libへの変更はNode.jsの解決規則へ乗り換える

移行後は、SvelteKitが独自に生成していた$libエイリアスの代わりに、package.jsonのimportsで#libを宣言します。これはNode.jsのsubpath importsをViteとTypeScriptでも共通に解決する構成です。

{
  "imports": {
    "#lib": "./src/lib/index.js",
    "#lib/*": "./src/lib/*"
  }
}

ここは単純な先頭文字の置換ではありません。移行ガイドでは、#lib/foo.jsや#lib/foo/index.jsのように曖昧でない拡張子付きの指定が必要とされています。バレルファイル、ディレクトリインポート、テスト設定、SvelteKit外のスクリプトも含めて、解決できるかを確かめたいところです。

また、enhanceされたform actionが別ページをactionに持つ場合、送信の成功時と失敗時にそのページへ移動するようになりました。ネイティブフォームに挙動を合わせる変更ですが、現在の画面に留まる前提でエラー表示や状態保持を作っているアプリでは、画面遷移のテストが必要です。

sv@nextは機械変換の後に確認タスクを残す

既存アプリは、まず最新のSvelteKit 2.xへ上げることが移行ガイドで推奨されています。2.x側の非推奨警告を先に拾ったうえで、RCの検証ブランチでは次のコマンドを使えます。

npx sv@next migrate sveltekit-3 --tasks all --confirm

この移行は依存関係を更新し、$libを#libへ書き換え、自動化できない変更をTODOとして残します。変換後はTODOを消すこと自体をゴールにせず、設定、型チェック、ルーティング、form action、利用中のアダプター、実際のデプロイ結果をプロジェクトのテスト手順で追う必要があります。

なお、新しいai-toolsアドオンは従来のmcpアドオンを置き換え、公式プラグインまたはMCPサーバー、skills、sub-agentsなどの個別ツールを選べる形になりました。導入方法はai-toolsの公式ドキュメントにまとまっており、npx sv add ai-toolsから設定できます。これは移行を必須にする機能ではなく、生成された確認タスクを扱う開発環境の選択肢です。

安定版の改善は個別採用し、SvelteKit 3は移行リハーサルに分ける

Svelte 5.57は、SvelteMapやcreateContextのAPIを必要な箇所から使い、通常の依存更新として互換性を確かめられます。SvelteKit 3はRCなので、既存の本番アプリを一気に置き換えるのではなく、最新2.xを起点に、要求ランタイムとツールチェーンをそろえた検証ブランチで移行リハーサルを始める段階です。

2026年9月1日時点でSvelteKit 3安定版の具体的な公開日は示されていません。ただ、sv@nextが機械変換と残作業の切り分けを担うため、今から差分の量と難所を測ることはできます。今回の更新が意味するのは「すべてを今すぐ上げる」ことではなく、安定版の小さな価値を取り込みながら、次のメジャー版に必要な作業を先に見える形へ変えることです。

出典

• Title: What’s new in Svelte: September 2026
• URL: https://svelte.dev/blog/whats-new-in-svelte-september-2026