Next Native とは、Vercel が予告している Next.js に“ネイティブ言語”サポートを入れる方向性のことです。Guillermo Rauch（Vercel CEO）が「Next Native is coming」と投稿し、Tim Neutkens（Next.js リード）が試作を公開しました。やろうとしているのは、Route Handler（サーバー側の API）を JS/TS の代わりに Go などネイティブ言語で書き、ネイティブの実行ファイルにコンパイルして動かすことです。名前は紛らわしいですが、スマホのネイティブアプリを作るフレームワークではありません——Next.js でネイティブアプリ化する方式の違い（Capacitor/Expo/Flutter）とは別の話です。
狙いは、React アプリと並行してサーバー上で CPU 負荷の高いワークロードを、ネイティブ言語で効率よく捌く選択肢を増やすこと（Rauch いわく「safe, performant, and cost-efficient」）。この記事は、仕組み・現状・立ち位置を、一次情報である vercel/next.js の PR #100130 を軸に整理します。これは実験段階で未リリースです。
HOW A route.go RUNSroute.go が動く流れ
Node が受けて、Go ワーカーへ回す
-
route.go を書く
Go の package main が Methods []string と Handle(http.ResponseWriter, *http.Request) を export（告知例では func GET(...) の形も）
-
Turbopack がネイティブ実行ファイルに
ハンドラ＋兄弟ソース＋取り込んだ Go パッケージ＋埋め込み資産をコンパイル（キャッシュあり）
-
Node サーバーが前段で受ける
ルーティング・rewrites・proxy.ts は Node のまま。該当パスを Go へ渡す
-
Go ワーカーが処理
監視下の Go ワーカーがプライベートなループバック HTTP で処理して応答。CPU 重い処理を React と並行して捌く
30秒でわかる
- ・Next Native は Next.js の Route Handler を Go などネイティブ言語で書く方向性。Turbopack がネイティブ実行ファイルにコンパイル。
- ・モバイルアプリの話ではない。サーバー上で CPU 負荷の高い処理を React と並行してネイティブで捌くのが狙い。
- ・Node が前段（ルーティング・rewrites・proxy.ts）、Go ワーカーがループバック HTTP で処理。JS/TS・React は Node のまま。
- ・実験段階・未リリース。PR #100130 は Draft・CI 失敗中、
experimental.goRoutesフラグが要る。CEO が予告した段階。
何をするものか：Route Handler を Go で書く
Next.js の App Router では、app/api/.../route.ts にサーバー側の API ハンドラを書きます。Next Native が足すのは、そのネイティブ言語版です。一次情報の PR #100130 によると、experimental.goRoutes: true を立てると route.go が使えるようになります。
JS/TS VS GO HANDLERどこで動くか
JS/TS は Node、route.go はネイティブ実行
従来の route.ts（JS/TS）
route.go（Next Native）
従来の route.ts（JS/TS）: Node.js ランタイムで実行
route.go（Next Native）: Turbopack がネイティブ実行ファイルにコンパイル
従来の route.ts（JS/TS）: React ページ・Pages Router も Node のまま
route.go（Next Native）: Node が前段、Go ワーカーがループバックで処理
従来の route.ts（JS/TS）: I/O 中心の API に向く
route.go（Next Native）: CPU 負荷の高いワークロードの選択肢が増える
route.go は Go の package main で、Methods []string（扱う HTTP メソッド）と Handle(http.ResponseWriter, *http.Request)（処理本体）を export する形です。Vercel の告知のスクリーンショットでは、func GET(w http.ResponseWriter, r *http.Request) のようにメソッドごとの関数を書く形も示されていました。実験中のため、この API の形はまだ流動的だと見ておくのが安全です。
重要なのは、ここで書いた Go を Turbopack がネイティブの実行ファイルにコンパイルする点です。ハンドラ本体だけでなく、兄弟ソース・取り込んだ Go パッケージ・埋め込み資産までまとめてビルドし、結果はキャッシュされます。つまり「JS にトランスパイルして Node で動かす」のではなく、本物のネイティブバイナリを作って動かすのが肝です。
どう動くのか：Node が前段、Go ワーカーが処理
実行時のモデルも PR に書かれています。dev と自前の next start では、ルーティング・rewrites・proxy.ts は Node.js サーバーのままです。Node が前段でリクエストを受け、route.go に当たるパスを、監視下の Go ワーカーへ渡します。ワーカーとの通信はプライベートなループバック HTTP（同じホスト内の閉じた経路）で行われます。これがツイートにあった「Go での Proxy」の正体です。React ページや Pages Router は Node のまま動き続けます。
アダプタ経由のデプロイでは、各 Go ハンドラが runtime: 'go' と実行ファイルの filePath を持つ独立した APP_ROUTE として扱われます。構図としては、React/JS の部分はこれまで通り、CPU を食う一部の API だけをネイティブの Go に“逃がす”、という設計です。
向くのは、Node.js の単一スレッドだと詰まりやすいCPU バウンドな処理です。たとえば画像のリサイズ・変換、圧縮・展開、暗号処理、大きなデータのパースや集計といった、I/O 待ちではなく計算そのものが重い API。こうした処理を Go のネイティブ実行ファイルに切り出せば、Node のイベントループを塞がずに捌ける余地が生まれます。逆に、DB アクセスや外部 API 呼び出しが中心の I/O バウンドな処理は、従来どおり route.ts（JS/TS）のままで十分です。Next Native は「全部を Go にする」ものではなく、重い所だけネイティブ言語に置ける選択肢を増やすものだと捉えるのが正確です。
| 観点 | 従来の route.ts | route.go（Next Native） |
|---|---|---|
| 実行 | Node.js ランタイム | Turbopack がネイティブ実行ファイルにコンパイル |
| 前段 | Node が処理 | Node が前段、Go ワーカーがループバックで処理 |
| 向く用途 | I/O 中心の API | CPU 負荷の高いワークロード |
| React/Pages Router | Node のまま | Node のまま（変更なし） |
モバイルの「ネイティブアプリ」と何が違うか
「ネイティブ」という言葉が同じでも、指しているレイヤーがまったく違います。混同しやすいので、ここで切り分けます。
| 観点 | Next Native（本記事） | モバイルの“ネイティブアプリ”化 |
|---|---|---|
| どこの話か | サーバー（Next.js の Route Handler） | クライアント（スマホの画面・端末機能） |
| 「ネイティブ」の意味 | ネイティブ言語（Go）でネイティブ実行ファイルを作る | OS ネイティブのアプリ（iOS/Android）として動かす |
| 代表例 | route.go＋experimental.goRoutes（Vercel 予告） |
Capacitor・Expo（React Native）・Flutter |
| 狙い | サーバーの CPU 負荷の高い処理を効率化 | スマホアプリとして配布・端末機能の利用 |
| Next.js との関係 | Next.js の一機能として統合される方向 | Next.js を“包む”か、別スタックへ乗り換える |
つまり、スマホアプリを作りたいなら Next Native は答えになりません。その用途はNext.js でネイティブアプリ化する方式の違い（WebView ハイブリッド／React Native／Flutter）で整理しています。Next Native は、あくまでサーバー側の実行を速くするための実験です。同じ Next.js の話でも、片方はユーザーの端末で動く画面の話、もう片方はサーバーで動く API の話——というのが、両者の最大の違いです。
現状と注意：まだ実験、予告段階
期待の大きい方向性ですが、冷静に現状を押さえる必要があります。
STATUS & LIMITS現状と注意
まだ実験。予告段階で未リリース
-
1.ステータスは Draft・CI 失敗中
PR #100130 は Draft で open。Turbopack テスト等が失敗中。CEO が『Next Native is coming』と予告した段階で、安定版ではない
-
2.有効化は experimental.goRoutes
実験フラグが要る。API は流動的（Methods/Handle 形と func GET 形が併存）
-
3.対象は Go の Route Handler だけ
まず Go。Go の pages/middleware・CGO・Webpack・standalone/static 出力・workspaces は対象外
-
4.“ネイティブアプリ”ではない
モバイルアプリ化（Capacitor/Expo 等）とは別物。サーバー上でネイティブ言語を動かす話
- ステータス：PR #100130 は Draft（下書き）で open。Turbopack のテストなどで CI が失敗しています。Rauch が「Next Native is coming」と予告し、Neutkens が試作している段階で、安定版ではありません。
- 使うには：
experimental.goRoutesという実験フラグが要ります。API の形（Methods/Handleかfunc GETか）も流動的です。 - 範囲：まず Go の Route Handler だけ。Go の pages/middleware・CGO・Webpack・standalone/static 出力・workspaces は対象外です。
- 用語の整理：繰り返しになりますが、これはモバイルアプリのフレームワークではありません。サーバー上でネイティブ言語を動かす話です。
追うときの注意
- ・本番採用の段階ではない（Draft・CI 失敗・実験フラグ）。方向性と設計を見るものと割り切る。
- ・API・設定は変わりうる。採用検討は、PR と Next.js のリリースノートで最新を確認してから。
- ・「ネイティブ」はサーバーの言語の話。モバイルの“ネイティブアプリ”と混同しない。
まとめ
この記事の結論
- ・Next Native＝Next.js の Route Handler を Go などネイティブ言語で書き、Turbopack がネイティブ実行ファイルにコンパイルする方向性（Vercel が予告）。
- ・Node が前段（ルーティング・rewrites・proxy.ts）、Go ワーカーがループバック HTTP で処理。React/JS はそのまま、CPU 重い処理だけ Go へ逃がす。
- ・狙いはサーバーの CPU 負荷の高い処理を安全・高速・低コストに。モバイルアプリの話ではない。
- ・現状は実験・未リリース（PR #100130 は Draft・CI 失敗・experimental.goRoutes）。方向性として追い、本番採用はまだ。
- ・一言でいえば、Vercel の Next Native は「Next.js に Go の route handler を足して Turbopack でネイティブ実行する」話。Next.js のネイティブ言語サポートの最初の一歩で、Turbopack と Go の組み合わせが鍵になる。
参照ソース
- vercel/next.js PR #100130「[experiment] support App Router route.go handlers」（一次。experimental.goRoutes・Methods/Handle・Turbopack でネイティブ実行・Go ワーカーのループバック・対象外の範囲・Draft/CI 失敗）
- Next.js Route Handlers（公式ドキュメント）（従来の route.ts の位置づけ）
