フロントエンドでデスクトップアプリを開発する際、これまでは常に二者択一を迫られてきました。
開発が簡単でエコシステムが成熟していることを求めるなら、Electron を選びます。ただしその代償として、アプリ内に Chromium + Node.js 一式をそのまま詰め込むことになり、インストーラーのサイズ、メモリ、起動速度のいずれも真の意味で軽くすることは困難です。
より小さいサイズと高いパフォーマンスを求めるなら、Tauri を選びます。Tauri は完全な Chromium をバンドルせず、システム標準の WebView を利用します。しかし本質的には依然として次のような構成です：
HTML + CSS + JavaScript
↓
システム WebView
↓
Rust ネイティブ機能
しかし今、Vercel Labs が第三の答えを提示しました。
そのプロジェクトの名前は Native SDK です。
これはブラウザー、WebView、JavaScript エンジンを直接回避し、フロントエンドのテンプレートに似た .native 構文で UI を記述し、さらに Zig で状態とビジネスロジックを処理します。最終的には自社開発のレンダリングエンジンによって、ピクセルをシステムのウィンドウに直接描画します。
公式が公表しているデータも非常に印象的です。
完全なアプリケーション：6 MB 未満
起動から最初のフレームまで：約 100 ms
内蔵ブラウザー：0
JavaScript エンジン：0
ランタイムインタープリター：0
Vercel Labs は今回、デスクトップアプリのテーブルをひっくり返したと言えるでしょう。
Electron はなぜますます重くなるのか？
Electron の最大の強みは、フロントエンド開発者なら誰もが理解しているところです。
Vue、React、Svelte を自由に選べ、HTML、CSS、JavaScript を直接記述できます。ブラウザーで動くものは、基本的にそのままデスクトップアプリに持ち込めます。
そのアーキテクチャも非常にシンプルです：
フロントエンドページ
↓
Chromium
↓
Node.js
↓
Windows / macOS / Linux
これが VS Code、Discord、Slack が Electron を選んだ理由です：
開発効率が高く、プラットフォーム間の差異が小さく、Web のエコシステムが完備していることです。
しかし、問題も同じくこのアーキテクチャに起因します。
すべてのアプリがブラウザーの実行環境一式を同梱しなければなりません。単純な Markdown エディター、ファイルツール、あるいはステータスバーアプリを作るだけであっても、Chromium と Node.js を一緒に起動する必要があります。
アプリはますます大きくなり、メモリ消費はますます増え、起動速度も真のネイティブレベルにはなかなか達しません。
端的に言えば、Electron の最大の強みはブラウザーであり、最大の負担も同様にブラウザーなのです。
Tauri はすでに軽いが、まだ WebView から抜け出していない
Tauri のアプローチはもっと賢いものです。
完全な Chromium をインストーラーに組み込むのではなく、OS が提供する WebView を直接呼び出します：
Vue / React / Svelte
↓
HTML + CSS + JavaScript
↓
システム WebView
↓
Rust
そのため、Tauri アプリは通常 Electron よりはるかに小さく、バックエンドの機能も Rust に任せられるため、セキュリティとパフォーマンスが明確に向上します。
既存のフロントエンドプロジェクトにとって、移行コストも比較的低くなっています。最終的に HTML、CSS、JavaScript にコンパイルできるものであれば、基本的に Tauri にそのまま組み込めます。
しかし、それでも WebView を避けることはできません。
Windows は主に WebView2（基盤は Edge Chromium）を使用し、macOS は WKWebView、Linux は WebKitGTK に依存しています。
プラットフォームごとにブラウザーのバージョン、レンダリング結果、対応機能が異なる可能性は依然として残ります。
つまり、Tauri は「完全なブラウザーをバンドルすると重すぎる」という問題は解決しましたが、ブラウザーレンダリングから完全に抜け出したわけではありません。
Native SDK はさらに急進的です。
Native SDK：UI を直接アプリにコンパイル
Native SDK はデフォルトで次の 2 種類のファイルを使用します：
src/app.native
src/main.zig
.native は UI を担当します：
<column gap="12" padding="16"><row gap="8" main="center" cross="center" grow="1"><button variant="secondary" on-press="decrement">-</button><text>{count}</text><button variant="primary" on-press="increment">+</button></row><status-bar>count: {count}</status-bar></column>
どこか見覚えがあると思いませんか？
コンポーネント、属性、イベント、データバインディングが備わっており、全体的な記法は HTML や最新のフロントエンドフレームワークのテンプレート構文に非常に近いものです。
しかし、DOM を生成することはなく、ブラウザーに実行させることもありません。
ビルド時に .native の UI は実行ファイルへ直接コンパイルされ、Native SDK 自身のエンジンがレイアウト、描画、イベント処理を完結させます。
リリース後のアプリが同梱する必要があるものは、次のいずれでもありません：
・ブラウザー
・WebView
・テンプレートパーサー
・スクリプトインタープリター
・JavaScript エンジン
ビジネスロジックは Zig に記述します：
pub const Msg = union(enum) {
increment,
decrement,
reset,
};
pub const Model = struct {
count: i64 = 0,
};
pub fn update(model: *Model, msg: Msg) void {
switch (msg) {
.increment => model.count += 1,
.decrement => model.count -= 1,
.reset => model.count = 0,
}
}
状態モデル全体は非常にシンプルです：
ユーザー操作
↓
Msg を送信
↓
update が Model を変更
↓
UI を再計算
Redux、Elm、Pinia あるいは単方向データフローに精通したフロントエンド開発者なら、基本的にひと目で理解できるでしょう。
UI は状態を読み取ってメッセージを送信するだけで、異なるコンポーネント内で自由にデータを変更することはできません。すべての状態変更は update に集約されるため、デバッグ、テスト、AI 生成がより安定します。
6MB、100ms —— その優位性はどれほど明確か？
Native SDK の公式が公開している複数の完全なアプリは、リリースバイナリのサイズがいずれも 6 MB を超えていません：
Calculator：3.6 MB
Markdown Viewer：3.5 MB
Notes：3.5 MB
Soundboard：5.7 MB
System Monitor：3.7 MB
macOS ARM64 環境において、これらのサンプルはプロセス起動から最初のフレーム表示までのウォーム起動時間が約 71–131 ms です。
完全な Markdown エディターのサンプルであれば、バイナリはわずか 3.4 MB です。
理由は極めて直接的です：
Chromium なし
Node.js なし
システム WebView なし
JavaScript エンジンなし
ランタイムのテンプレートインタープリターなし
リリースされる成果物の主な中身は次のとおりです：
あなたのビジネスロジック
+
Native SDK レンダリングエンジン
+
システムネイティブフレームワーク
ファイルツール、デスクトップクライアント、生産性向上ツール、Markdown エディター、データベース管理ツール、システムモニター、社内ワークベンチといったアプリにとって、このサイズと起動速度は確かに非常に魅力的です。
もちろん、これらのデータはプロジェクト側が指定したデバイスとサンプルアプリでテストしたものであり、「Electron より数十倍速い」と直接結論づけることはできません。
両者が提供する実行環境、ブラウザー機能、エコシステムの規模は、そもそも比較になる規模ではありません。
しかし、ひとつ確かなことがあります：
アプリがブラウザーのランタイムを同梱しなくなれば、サイズと起動速度が自然と大幅に軽くなるということです。
Electron、Tauri、Native SDK はどう選ぶべきか？
3 つのアプローチの技術ロードマップはすでに非常に明確です：
【比較表】
Electron：UI技術＝HTML / CSS / JS、実行環境＝Chromium + Node.js、最大の強み＝エコシステムが成熟し互換性が高い、主なコスト＝パッケージサイズとリソース消費が大きい。
Tauri：UI技術＝HTML / CSS / JS、実行環境＝システムの WebView + Rust、最大の強み＝サイズが小さくフロントエンドプロジェクトを再利用できる、主なコスト＝依然として WebView とプラットフォーム間の差異の影響を受ける。
Native SDK：UI技術＝.native + Zig、実行環境＝自社開発のネイティブレンダリングエンジン、最大の強み＝ブラウザー不要でサイズが小さく起動が速い、主なコスト＝エコシステムは初期段階で Zig を学ぶ必要がある。
Electron は今なお、複雑な Web プロダクトの移行や、ブラウザーのエコシステムに大きく依存するアプリに適しています。
Tauri は、Vue や React を引き続き使いつつ、インストーラーのサイズとリソース消費を抑えたいチームに適しています。
Native SDK が狙っているのは、別の種類のプロジェクトです：
宣言型 UI の開発効率を維持しつつ、ブラウザーのランタイムから真に脱却したいと考えるプロジェクトです。
これは開発者に煩雑な AppKit、Win32、GTK に戻ることを求めず、UI を WebView に押し込むこともせず、両者の間に新しいレイヤーを一から作り直したものです。
フロントエンド開発者はどうやってすぐに始められるか？
インストールは非常に簡単で、npm を直接使用します：
npm install -g @native-sdk/cli
プロジェクトを作成します：
native init my_app
cd my_app
native dev
実行が完了すると、実際のシステムウィンドウが開きます。
プロジェクトのデフォルト構成も非常にクリーンです：
src/app.native # 画面、レイアウト、バインディング、イベント
src/main.zig # 状態とビジネスロジック
src/tests.zig # UI テスト
app.zon # アプリ設定、権限、ウィンドウ、パッケージ情報
assets/icon.png # アプリアイコン
開発中に src/app.native を変更すると、ウィンドウは自動的に更新され、現在の状態が可能な限り保持されます。
コードに間違いがあっても、以前の UI がそのままクラッシュすることはなく、具体的なファイル名、行番号、列番号が返されます。
プロジェクトをチェックします：
native check
テストを実行します：
native test
リリース版をビルドします：
native build
アプリをパッケージ化します：
native package --target macos
native package --target windows
native package --target linux
CLI は SDK のパスと、バージョンが一致する Zig ツールチェーンの処理も行います。
開発者は最初から複雑な build.zig を保守する必要はありません。プロジェクトで本当にカスタムビルドが必要になった場合にのみ、native eject を使って完全なビルドファイルを引き継ぎます。
フロントエンド開発者にとって、この一連の体験は非常に馴染み深いものです：
CLI をインストール
↓
プロジェクトを初期化
↓
開発サーバーを起動
↓
画面を変更
↓
自動更新
↓
ビルドしてパッケージ化
ただし今回は、最終的に動作するのはもはや Web ページではありません。
5 つのプラットフォーム、1 つの実行モデル
Native SDK は現在、以下をすでにカバーしています：
macOS
Windows
Linux
iOS
Android
デスクトップ版は現在、最も成熟している部分です。
macOS
macOS は現在サポートが最も完全なプラットフォームであり、Metal を使用して描画を行うとともに、システムのスクロール効果、メニュー、トレイ、ダイアログ、インプットメソッドにも対応しています。
Windows と Linux
Windows と Linux はすでに完全なアプリの実行、テスト、パッケージ化が可能ですが、現時点では主に CPU ソフトウェアレンダリングを使用しており、GPU レンダリングバックエンドはまだ改善中です。
なお、Linux は現時点ではシステムトレイに対応しておらず、Windows と Linux の一部のシステム機能も macOS ほど完全ではありません。
iOS と Android
モバイル側も同様にビルドパイプラインがすでに整備されています：
native dev --target ios
native dev --target android
native package --target ios
native package --target android
iOS は完全な Xcode プロジェクトを生成でき、Android は完全なホストプロジェクトとデバッグ用 APK を生成できます。
開発者はプロジェクト内で Swift、Kotlin、Java のホストコードを別途保守する必要はありません。
ただし注意が必要なのは、iOS と Android は現時点ではまだ実験的なサポートであり、主にエミュレーター環境で検証されています。ツールチェーン、API、GPU レンダリング、実機のワークフローは引き続き改善が進められています。
したがって、現時点でデスクトップツールとしてこれを使うことには十分な議論の価値がありますが、成熟した Flutter や React Native を直接置き換えるにはまだ時期尚早です。
それは AI エージェント向けにさえなっている
Native SDK の最も特別な点は、おそらく 6 MB というサイズではないでしょう。
それは AI の自動化機能をランタイムに直接組み込んでいます。
エージェントは実行中のアプリの画面を読み取り、アクセシビリティツリーを確認し、ボタンを検索し、テキストを入力し、コンポーネントをクリックし、状態を検証し、操作を記録し、決定的なスクリーンショットを生成できます。
native automate wait
native automate snapshot
native automate screenshot
プロジェクトは公式の Agent Skills も提供しています：
npx skills add vercel-labs/native
インストール後、Claude Code や Codex などのエージェントは、現在の Native SDK バージョンに一致した開発手順を取得できます。
エージェントは画面を書き終えた後、アプリを直接起動し、ウィンドウを操作し、結果を検証してから、コードを修正することもできます。
このクローズドループは非常に重要です：
AI が画面を生成
↓
コンパイルして実行
↓
実際のウィンドウを読み取る
↓
クリックとテスト
↓
問題を発見
↓
自動修正
以前は、AI がデスクトップアプリを書いても、コードが「一見動作しそう」というレベルにとどまることが少なくありませんでした。
Native SDK は、エージェントが自分で作り出したアプリを実際に「見る」ことができるようにすることを目指しています。
コンポーネントの由来情報を通じて、あるボタンがどの .native ファイルのどの行のコードに由来するのかを特定し、自動的に修正を完了することさえできます。
これこそが、真に AI エージェント向けのアプリ開発パイプラインです。
フロントエンドのデスクトップ開発に、ついに第三の道が現れた
これまでデスクトップアプリを作る際、フロントエンド開発者の選択肢は多くありませんでした。
Electron のサイズとリソース消費を受け入れ、成熟したエコシステムと非常に低い学習コストと引き換えにするか、Tauri を使って Web 技術スタックを維持しつつ、システムの WebView と Rust によってより軽いアプリを手に入れるかのどちらかでした。
Native SDK は、より急進的な路線を選択しました：
宣言型 UI を維持
コンポーネントベース開発を維持
データバインディングを維持
ホットリロードを維持
フロントエンドに馴染みのある開発体験を維持
そして、ブラウザーを削除する。
現時点ではまだ pre-1.0 であり、API は今後も変更され続け、エコシステムも Electron や Tauri には遠く及びません。
Windows、Linux、モバイルのレンダリング機能も、同様に今後の改善が必要です。
しかし、この方向性はすでに十分に興味深いものです。
6 MB 未満で、起動に約 100 ms、5 つのプラットフォームをサポートし、AI エージェントが直接操作してテストできるネイティブアプリフレームワークです。
今回こそ、Electron と Tauri の対抗馬が本当に登場したのです。
Native SDK 公式サイト：https://native-sdk.dev/