SvelteKit 3.0 プレリリースを読む — 壊れるもの、締まるデフォルト、そしていまだexperimentalなもの

はじめに — 発表記事なしに、npmへ先に上がった
タイムライン — まず2.xがどこまで走ってきたか
v3が上げる土台 — ランタイムとツールチェーンの最低ライン
削除されるAPI — 2年分の廃止予告の清算
静かに変わるデフォルト — セキュリティ関連が多い
いまだexperimentalなもの — v3は機能メジャーではない
隣の芝との対比 — メジャーがやっている仕事が違う
では、今何をすべきか
おわりに
参考資料

はじめに — 発表記事なしに、npmへ先に上がった

svelte.devのブログには「SvelteKit 3を紹介します」といった記事はまだありません。ですがnpmレジストリにはすでにはっきりと痕跡があります — @sveltejs/kitの3.0.0-next.0が2026年6月5日に上がり、本稿執筆時点(2026-07-17)での最新プレリリースは7月14日の3.0.0-next.8です。6週間足らずのあいだに9回のプレリリースが出て、安定版2.69.3(7月13日)と並んで2本のトラックでリリースが回っています。

リポジトリ側の証拠も同じ方向です。sveltejs/kitにはversion-3ブランチが開かれており、3.0マイルストーンは本日時点でクローズ済みイシュー107件、オープンなイシュー27件です。正式リリース日は発表されていません — つまり本稿の内容も「next.8時点のスナップショット」として読むべきものです。プレリリースなので、ここからさらに変わり得ます。

ですがversion-3ブランチのチェンジログをnext.0からnext.8まで通読すると、一つはっきりすることがあります。このメジャーには新機能がほとんどありません。代わりに2年分の廃止予告を清算し、ツールチェーンの土台を上げ、デフォルトを締めています。そしてコミュニティがSvelteKit 3の顔として期待しているもの — remote functions、コンポーネント内のawait — は、v3プレリリースでもいまだexperimentalです。この構図を理解することが、移行判断の半分を占めます。

タイムライン — まず2.xがどこまで走ってきたか

v3を読むには、2.x後半の流れを知っておく必要があります。日付はすべてnpmレジストリのpublish時刻基準です。

2024-12-16  kit 2.12   $app/state 追加(ルーンベース — $app/storesの後継)
2025-07-14  svelte 5.36  コンポーネントawait(experimental.asyncフラグ)
2025-07-24  kit 2.26   $app/pathsにresolve()/asset()追加(旧base/assetsの代替)
2025-07-31  kit 2.27   remote functions(experimentalフラグ)
2026-01-22  svelte 5.48  ← のちにkit v3の最小Svelteバージョンとなるリリース
2026-05-01  kit 2.59   query.live 追加(experimental)
2026-05-22  kit 2.61   query.liveが非同期イテラブル化、クエリの.run()削除(破壊的)
2026-06-02  kit 2.62   svelte.config.jsなしでVite プラグインに設定を渡せるように
2026-06-04  kit 2.63   明示的な環境変数(experimental)
2026-06-05  kit 3.0.0-next.0  ← プレリリース開始
2026-07-14  kit 3.0.0-next.8  ← 現在

2つ目立つ点があります。第一に、2.62と2.63はv3直前に出た「予告編」です — 7月のダイジェストの表現を借りれば、設定をvite.configに移すことと明示的な環境変数は、どちらも「Kit 3ではこうなるというプレビュー」として2.xに先に載りました。第二に、2.61に見られるように、experimentalの札が付いた機能はマイナーリリースでも破壊的変更が起き続けます。.run()の削除、requested(...)のシグネチャ変更といったものがsemverマイナーで出ています — フラグをオンにしたなら、semverが守ってくれない領域に入ったということです。

v3が上げる土台 — ランタイムとツールチェーンの最低ライン

next.0のチェンジログが明記する最低要件です。

Node 22以上(#12548)
TypeScript 6以上(#15930) — npmには6.0.2・6.0.3の安定版があり、その上にはTypeScript 7.0がすでにGAしています(7.0.2、2026-07-08)。参考までに、svelte-check 4.7.0にはtsgo(ネイティブTS)サポートがexperimentalとして入っています。
Vite 8 — 当初はVite 8要件(#15371)でしたが、next.5でvite@^8.0.12に締められました。チェンジログの文言をそのまま移すと「安定版rolldown 1.0.0をバンドルした最初のVite 8リリース」だからです(#16134)。npmの日付で突き合わせると、rolldown 1.0.0が2026-05-07、vite 8.0.12が2026-05-11 — 4日差でかみ合っています。つまりSvelteKit 3はRust製バンドラーの上でしか動きません。
@sveltejs/vite-plugin-svelte 7(#15371)
Svelte 5.48.0以上 — ここが重要です。Svelte 6ではありません。 5.48は2026年1月に出た普通のマイナーです。v3はSvelteの世代交代とはカップリングしていません。

チェンジログはVite 8要件の根拠として「Vite hook filterによるより速いビルドと、Vite environment APIを使うより強力なアダプター」を挙げています — 具体的なビルド時間の数値はどこにも公開されていないので、ここではあくまでプロジェクト自身の言い分だという点だけ記しておきます。

削除されるAPI — 2年分の廃止予告の清算

v3で削除される、あるいは名前が変わるものです。いずれも後継APIが先に2.xへ入っていたものばかりで、「突然の削除」は事実上ありません。

消えるもの	後継	後継が入った時期
`$app/stores`モジュール全体(#15499)	`$app/state`	kit 2.12(2024-12)
`$app/paths`の`base`・`assets`・`resolveRoute`(#15507)	`resolve()`・`asset()`	kit 2.26(2025-07)
`invalidateAll`(deprecated)(#16289)	`refreshAll`(`goto`のオプションにも適用)	v3 next.8で新設
`$app/environment`	`$app/env`へ改名(エイリアスは維持、next.1)	v3
`$env/*` 4種のモジュール	明示的な環境変数(`$app/env/private`・`$app/env/public`)	kit 2.63(experimental)
`svelte.config.js`必須	Viteプラグインに設定を渡す(#16007)	kit 2.62から可能
フォルダ内のparamファイル	`params.js/ts`単一ファイル(#16189)	v3
`preloadStrategy`オプション	常に`modulepreload` + `output.linkHeaderPreload`	v3
CSRFの`checkOrigin`	`trustedOrigins`	kit 2.xですでにdeprecated
`@sveltejs/kit/node/polyfills`、アダプター用`createEntries`	なし(削除)	—

いくつか触れておきたい点があります。

$app/storesの削除は、ルーン移行の句点です。Svelte 5のルーンがストアを押しのけて久しいですが、SvelteKitのpage・navigating・updatedストアは後方互換のために生き残っていました。後継の$app/stateが出てから1年半が経っているので、清算のタイミングとしては穏当なほうです。

invalidateAll → refreshAllは語彙の統一です。PR #16289を読むと意図がわかります — remote functionsの世界でデータ更新はquery.refresh()であり、load関数の世界の「無効化(invalidation)」と用語が分かれていました。refreshAllはこの2つを一つの単語に束ねる名前であり、load関数を常に再実行させるオプションも合わせて整理されました。注意点として、refreshAllは2.69.3にはありません。v3へ上がるときに切り替える話であって、今日できることではありません。

環境変数は、モジュールの魔法から明示的な宣言へ移ります。ドキュメントの予告文言は明確です — 明示的な環境変数がv3のデフォルトになり、$env/*モジュールと$app/environmentは削除されます。新方式はsrc/env.tsで宣言します。

// src/env.ts — kit 2.63+ではexperimental.explicitEnvironmentVariablesで先取りして試せる
import { defineEnvVars } from '@sveltejs/kit/hooks';

export const variables = defineEnvVars({
	API_KEY: {}, // デフォルトはprivate — $app/env/privateからのみインポート可能
});

これまで$env/static/privateが「インポート位置で露出可否を強制する」巧妙な仕掛けだったとすれば、新方式はアプリに存在する環境変数の一覧そのものを、型とともに1つのファイルに固定します。どんな変数があるかコードだけでは分からない問題は消える代わりに、変数を1つ足すたびに宣言が1行増えます。

静かに変わるデフォルト — セキュリティ関連が多い

削除より静かですが、実際に挙動が変わるものです。移行で時間を食うのは、たいていこちらです。

外部リダイレクトがデフォルトで禁止されます(#16198)。外部URL(およびjavascript: URL)へredirectするには、externalオプションを明示的に渡す必要が出てきます。ログイン後に?next=パラメータでリダイレクトするコードがあれば — オープンリダイレクトの定番の落とし穴ですが — v3ではそのままにすると壊れます。壊れるのが狙いです。
クッキーのデフォルトpathが'/'になります(#15398)。これまでは現在のパス基準で、「クッキーを設定したのに別のページで見えない」という定番の質問の原因になっていました。cookie v1の採用によりクッキー名もASCIIに制限されます(#13386)。
form actionの失敗が、fail()に載せたHTTPステータスコードを実際のレスポンスコードとして使います(#16200)。これまでは成功の200に乗って返ってきていたものが変わるので、ステータスコードを見て動くプロキシ・監視があれば影響を受けます。204レスポンスは本当にボディなしで出ていきます。
handleErrorがレスポンスのステータスコードに影響できるようになります(#16162)。
gotoが、アプリのルートとして解決できないURLでreject するようになります(#16164) — 外部URLですでにそうだった挙動に合わせた形です。
ナビゲーション中のinvalidate呼び出しがナビゲーションを中断しなくなります(#16188)。

参考までに、remote functionsのレスポンスにcache-control: private, no-storeを強制して、個人化されたクエリ結果が共有キャッシュに残らないようにする修正は、v3ではなく2.65.2にすでに入っています — セキュリティ関連デフォルトの引き締めはv3限定のテーマではなく、ここ数か月一貫した方向です。

いまだexperimentalなもの — v3は機能メジャーではない

ここが本稿でいちばん重要な節です。

Remote functionsはv3でもexperimentalのままです。公式ドキュメントには今も「currently experimental… subject to change without notice」とあり、kit.experimental.remoteFunctionsとcompilerOptions.experimental.asyncの2つのフラグを要求します。より示唆的なのはv3プレリリースの方向性です — next.7はむしろフラグなしで*.remote.ts/jsファイルを置くことを禁止しました(#16247、2026-07-07マージ)。安定化が目前なら出てこない変更です。2025年7月に2.27として出てから1年近く経ち、そしてv3メジャーを越えてもなお、remote functionsのAPI安定性の保証はありません。

コンポーネントのawaitも同様です。 Svelte 5.36(2025-07-14)からexperimental.asyncフラグで使えるようになっていますが、ドキュメントはフラグが外れる時期を明記しています — 「The experimental flag will be removed in Svelte 6.」そしてSvelte 6はnpmに存在しません — 6.xは正式版もプレリリースも一度も発行されておらず、svelteのlatestは5.56.6(2026-07-16)です。kit v3の最小要件がSvelte 5.48であること自体が、この構図を要約しています。SvelteKitのメジャーとSvelteのメジャーは、切り離された別々の列車です。 コンパイラ側のexperimentalリストには、fork API(5.42)とasync SSR(5.39)もそのまま残っています。

逆方向の卒業も一つあります — OpenTelemetryトレーシングはnext.7でexperimentalの名前空間を抜け、正式なAPIになりました(#16260)。

まとめると、v3の正体はこうです。話題性のある機能はすべてexperimentalトラックのまま2.xとv3に同時に載っており、メジャーバージョンはその下の土台 — ランタイム、バンドラー、名前、デフォルト — を入れ替えるために使われています。「v3に上げればremote functionsが安定する」という期待は、現時点の証拠では成り立ちません。

隣の芝との対比 — メジャーがやっている仕事が違う

同じ週にReactエコシステムを賑わせたニュースがReact CompilerのRustポーティングだったのは、対比として興味深い点です。Reactは手動メモ化をなくすためにコンパイラ基盤を新しく組み直している最中で — それも実験的なWIP段階です — Svelteは最初からコンパイラがフレームワークだったので、その段階自体がありません。代わりにSvelte側のメジャーは、バンドラー(rolldown)とランタイムの土台を上げるために使われます。2026年、両フレームワークとも「新機能の大放出」ではなく基礎工事にメジャー級のエネルギーを注いでいるという共通点があり、どちらもアプリ開発者のコードを当面大きく変えることはありません。

では、今何をすべきか

今日、2.xで先にできること — すべてv3移行の前払いです。

$app/storesのインポートを$app/stateへ移す。1年半使われているAPIなので、参考資料も十分です。
$app/pathsのbase・assetsの文字列結合をresolve()・asset()に置き換える。
設定をvite.configのプラグインオプションに移してみる(2.62+)。新規プロジェクトなら、sv CLI 0.16はすでにそうスキャフォールディングします。
Node 22、Vite 8、vite-plugin-svelte 7へ先に上げてみる — これはv3なしでも今できる検証です。
invalidateAllの使用箇所を把握しておく。切り替え自体はv3でですが、どこで使っているかを知るのは今できます。

やってはいけないこと。

3.0.0-next.*を本番に載せること。プレリリースはnext.8に至るまでも破壊的変更が出続けました($app/storesの削除はnext.7、refreshAllはnext.8で登場しています)。
remote functionsを安定APIとみなして、チーム標準や公開ライブラリを組み立てること。2.61の.run()削除のようなことが再び起きない保証はありません — それがexperimentalの定義です。
「Svelte 6が出たらまとめて」とv3対応を先送りすること。上で見たとおり2つのメジャーは切り離されているので、待つべき対象がそもそも別々です。

アダプター・ライブラリの作者なら、もう少しやることがあります。createEntriesが消え、アダプターがViteプラグインを直接提供できるようになり(#16206)、Vite environment APIを基盤にアダプターが再編されます。アプリ側のコードより、こちらのエコシステムがv3リリース時点の実質的なボトルネックになる可能性が高いです。

おわりに

SvelteKit 3.0プレリリースのチェンジログは派手ではありません。そして、それはいい兆候だと思います。学び直しを要求するメジャー — ルーターが変わり、データロードのモデルが変わる類 — ではなく、廃止予告を履行し、土台を上げ、デフォルトを締めるメジャーです。ルーンを学び直す必要も、load関数を書き直す必要もありません。

その代わり、期待値は正確に持つ必要があります。remote functionsとコンポーネントのawaitが「正式」になる出来事はSvelteKit 3ではありません — 前者はまだ見通しが立っておらず、後者はドキュメント上Svelte 6の仕事です。v3は、その未来が乗っかる土台(rolldownベースのVite 8、Node 22、整理されたAPI表面)を敷くリリースとして読むのが、チェンジログと整合する読み方です。プレリリースは進行中なので、正式リリース時には本稿の細部の一部が変わっている可能性があります — その時にまた確認することを前提に書かれたスナップショットです。