個人開発でも純正スペックを超えたリファクタリング ― メモリを9割削減した Electron → Tauri 2 + Rust への書き換え

2026年4月23日
著者ラピットくん
カテゴリーコラム

MarkShot v2.0 のアイキャッチ。左にラピットくんがサムズアップ、中央に大きなLEGACY APPから矢印でNEW APPへ縮小、上部に「メモリ9割減 Electron → Tauri + Rust 書き換え記」のテキスト

はじめに — メモリを一気に半分以下で運用できないか？

ふと 「いま運用しているデスクトップアプリのメモリを、一気に半分以下にできないか？」 と考えたのがこの書き直しの発端でした。Windows 付属の Snipping Tool ですら実測で private memory 38 MB なのに、個人開発のスクリーンショットツール MarkShot は常駐 180 MB。同じ仕事をしているのに純正の 4.7 倍重い。機能を削るよりプラットフォームを変えたほうが効くはず——その仮説を立ててから 3 日後には v2.0.0 をリリースしていました。

結論から言うと、インストール 5.79 MB、実行時 25 MB。3 日で v1.4.0（Electron）を捨てて Tauri 2 で書き直したら、インストールサイズが -97.8 %、常駐メモリが -91.2 % に着地しました。「半分以下」どころか 10 分の 1 以下です。リリースに合わせてランディングページも新 UI に作り直しました。

余談ですが、最近の「AI 支援のバイブコーディング」（いわゆる Vibe Coding）だと、デスクトップアプリの選択肢として Electron が選ばれがちです。Node.js と Web の資産をそのまま持ち込めて、electron-builder 一発で Windows 向けインストーラまで吐いてくれる——確かにデプロイの簡単さは圧倒的に魅力です。ただし、その対価としてアプリごとに Chromium ランタイムを丸ごと抱え、バイナリサイズが数百 MB 単位で膨らみ、実装側をいくら頑張ってもメモリ常駐が 100〜300 MB 前後から下がらないメモリ下限の限界も付いてきます。デプロイの楽さ ⇄ 実行時の重さ、というトレードオフです。

今回はこのメモリ下限の限界を破りたくて、初めての Tauri 2 + Rust 挑戦 に踏み切りました。個人開発の Windows 向けスクリーンショットツール「MarkShot」を、Electron + React から Tauri 2 + React + Rust に全面リファクタリングし、合わせてランディングページも v2.0 訴求に刷新、FAQ セクション（ARM64 以外で使えるか・旧 v1.4.0 の扱いなど）も追加して、2026-04-23 に v2.0.0 をリリースしました。この記事では、なぜ書き直したのか、どれだけ軽くなったのか、ARM64 Rust で踏んだ地雷、Tauri 2 実装で最初に踏む落とし穴、そして「機能を削る」という設計判断までをまとめます。エンジニア向けに密度を上げて書いたので、これから Electron → Tauri 移行を検討する方の参考になれば幸いです。

なぜ v1.4.0（Electron）を捨てたか

Snipping Tool ですら private 38 MB、うちは 180 MB だった

Windows 付属の Snipping Tool を同条件（Windows 11 ARM64、ウィンドウ表示後 5 秒安定化）で実測してみると、private memory 38 MB / working set 109 MB / インストール 305 MB / プロセス数 1 でした。純正アプリも意外と重い。とはいえ MarkShot v1.4.0（Electron 28 + React）は常駐プロセスだけで private memory 180 MB / working set 290 MB、インストール時 259 MB。個人開発アプリが純正の private で 4.7 倍、working set で 2.7 倍重いというのは、さすがに気恥ずかしい状態でした。

MarkShot は完全な個人開発アプリで、市場で売れる商材というより「自分が毎日使う道具」として育ててきたものです。今回の書き直しには 2 つの軸がありました。①個人開発でも Windows 純正アプリや他のプロ向けスクショツールと同じスペック（軽さ・起動速度）を出したい、②せっかくなら新しい言語を本気で勉強したい——この 2 つが重なったタイミングで、Tauri 2 + Rust への全面書き換えという「重い選択」に踏み切りました。
1 つ目の「スペックで純正と並ぶ」は、「機能を全部入れる」より先に 「同じ機能で桁違いに軽い」 を取りに行くほうが個人開発らしい筋だという判断に直結しています。2 つ目の「新しい言語」は、業務の寄り道として Rust を習得したい気持ちで、その道具立てとして Tauri 2 はちょうど良い難易度でした（フロントは React そのまま、Rust は必要な箇所だけ）。

Electron アーキテクチャのメモリ下限の限界

Electron は Chromium と Node.js ランタイムをアプリごとにバンドルします。便利さの代償として、どれだけ軽量化しても 100 MB 以下にはほぼ届かないメモリ下限の限界があります。メインプロセス + レンダラー + GPU + ユーティリティと 4 プロセスに分裂するのもメモリ常駐量を押し上げる要因です。

このメモリ下限の限界は、アプリ側の実装を頑張ったところで越えられません。プラットフォーム選定で殴るしかないと腹をくくりました。

技術選定 — なぜ Tauri 2 + WebView2 だったか

簡単に前提を共有すると、Tauri 2 は 2024 年 10 月に安定版が出たばかりの Rust 製デスクトップアプリ用フレームワークです。Electron のように Chromium を同梱するのではなく、OS 標準の WebView（Windows なら WebView2、macOS なら WebKit）を借りる設計なので、バイナリが数 MB〜数十 MB で収まります。フロント側は React / Vue / Svelte など Web の資産をそのまま使えるのが強みです。

Rust は C/C++ の代替として設計された現代的なシステムプログラミング言語で、メモリ安全性とパフォーマンスを両立しているのが特徴です。Tauri 2 のネイティブ層（スクリーンキャプチャ・クリップボード・ファイル I/O など OS 直叩きの部分）は Rust で書くため、低レイヤを「落ちにくく」触れます。

候補は Tauri 2 / Flutter Desktop / .NET MAUI / 純 Rust GUI（egui, Iced）でしたが、今回の選定理由はシンプルに 3 つです。①軽い（OS 同梱 WebView 再利用でバイナリ数 MB 台）、②安全（Rust のメモリ安全性でネイティブ層がクラッシュしにくい）、③ React 資産をそのまま流用できる（Konva ベースの注釈エディタを書き直さずに移植可能）。特に 3 点目は、3 日でリファクタリングを終わらせるうえで決定打になりました。

ネイティブ WebView 再利用でメモリ下限が 1 桁変わる

Tauri 2 は OS 同梱の WebView を再利用します。Windows なら同梱の WebView2 Runtime（Edge と同じ Chromium ベースですが、Edge 本体とは別コンポーネント）を利用し、アプリのバンドルに Chromium は含まれません。薄い Rust ランタイムと IPC 層だけが乗る構造なので、実測でメモリ常駐量が 5〜10 倍違ってきます。Electron が「Chromium を持ち歩く」なら、Tauri は「OS の WebView を借りる」アプローチです。

Rust の GUI は（まだ）不採用にした理由

egui や Iced のような純 Rust GUI も検討しましたが、MarkShot の肝である注釈エディタ（矢印・テキスト・枠・ペン・モザイク）を作り込むには、Canvas 系ライブラリの成熟度で Web の Konva に軍配が上がります。Tauri 2 ならフロントはそのまま React + Konva で走らせ、重い処理だけ Rust に寄せる分業ができる。「全部 Rust」ではなく「必要な部分だけ Rust」が今回の現実解でした。

実測ベンチマーク — 数字で殴る

インストールサイズ・メモリ・プロセス数

Surface Laptop 7（Windows 11 ARM64 / 16 GB）で、release ビルドを起動してウィンドウ表示後 5 秒安定化させた状態を計測しました。

指標	v1.4.0 Electron	v2.0.0 Tauri 2	参考: Snipping Tool	v1 → v2
インストールサイズ	259.23 MB	5.79 MB	305.42 MB	-97.8 %
ワーキングセット	290.61 MB	25.45 MB	108.77 MB	-91.2 %
プライベートメモリ	180.86 MB	4.52 MB	38.12 MB	-97.5 %
プロセス数	4	1	1	-75 %
起動時間	418 ms	644 ms	546 ms	+54 %

Snipping Tool 列は Windows 11 ARM64 で同条件実測（2026-04-23）。UWP パッケージ Microsoft.ScreenSketch のインストールサイズは `Get-AppxPackage` + `InstallLocation` のディレクトリサイズを合算。

Windows 11 のインストールされているアプリ画面で MarkShot 1.4.0（259 MB）と MarkShot 2.0.0（5.79 MB）が並んで表示されている — Windows 11 の「インストールされているアプリ」で並べた実物。同じ名前のアプリなのに、**259 MB → 5.79 MB** と 45 分の 1 のサイズに。

インストールサイズは 259 MB → 5.79 MB、45 分の 1 です。プライベートメモリは 180 MB → 4.5 MB、40 分の 1。プロセス数は 4 から 1 に収束しました。さらに面白いのは 純正 Snipping Tool との比較で、インストールサイズは Snipping Tool の 52 分の 1、private memory は 8.4 分の 1、working set も 4.3 分の 1。「純正ツールと同じ土俵に立つ」どころか、純正より一回りも二回りも軽いところに着地しました。

起動時間は +226 ms のトレードオフ

起動時間は 418 ms → 644 ms と、+226 ms 増えました。Tauri 2 は起動のたびに WebView2 ランタイムを初期化するため、このコストは仕様上避けられません。Electron は常駐プロセスで起動コストを相殺していた面もあり、ここは素直にコストとして受容した箇所です。ただし 0.6 秒台であれば体感では十分速く、「インストール -98 % ・メモリ -91 % の代わりに起動 0.2 秒」は合理的なトレードオフと判断しました。

ARM64 Rust で踏んだ地雷たち

rustc 1.93 / 1.95 が STATUS_STACK_BUFFER_OVERRUN で落ちる

ARM64 Windows の rustc（1.93 / 1.95、aarch64-pc-windows-msvc）で、重量級クレート（windows-sys, webview2-com-sys, tauri-utils 等）をコンパイル中に STATUS_STACK_BUFFER_OVERRUN (0xc0000409) が散発的に発生しました。メモリ確保失敗のバックトレースが出るパターンと、rustc 自体が黙ってクラッシュするパターンの 2 種類。

回避策は以下の環境変数を設定してからビルドするだけです。

set CARGO_BUILD_JOBS=1
set RUST_MIN_STACK=33554432
set CARGO_INCREMENTAL=0
npm run build

並列度を 1 に落とし、rustc スレッドのスタックサイズを 32 MB に広げ、インクリメンタルビルドを切るだけで劇的に安定します。ページングファイル不足が誘因の場合もあるので、Surface Laptop 7 のような 16 GB 非換装機ではほぼ必須の儀式でした。

image 0.25 の avif チェーンが ARM64 で prelude 解決に失敗する

当初は xcap 0.0.14 + image 0.25 でスクリーンキャプチャを実装していたのですが、ARM64 rustc が av-scenechange 0.14.1 のコンパイル時に「Option / Vec / Ok / Some / Fn が見つからない」という prelude 解決エラーを 288 件吐いて詰みました。image 0.25 の default features が avif → ravif → rav1e → av-scenechange とつながっており、重量級の動画系クレートまで依存が引き込まれているのが原因です。

こちらの Cargo.toml で image = { default-features = false, features = ["png"] } を指定しても効きません。なぜなら上流の xcap が image = "0.25"（default 有効）で依存を書いていて、Cargo の feature unification は一方通行でダウン方向に伝播しないため、上流のデフォルトを下流で殺すことは構造上できないからです。ここは罠でした。

採用した解決策は、xcap を諦めて screenshots 0.8 に戻すことです。screenshots 0.8.10 は内部で image 0.24.9 を再エクスポートしており、そもそも avif チェーンを持ちません。

# 避けた構成
# xcap = "0.0.14"
# image = "0.25"   # avif → ravif → rav1e → av-scenechange が ARM64 で死ぬ

# 採用した構成
screenshots = "0.8"   # 内部で image 0.24 を再エクスポート、avifチェーンなし

教訓：Cargo の feature unification は「有効化」の方向にしか効かない非対称な仕組み。上流の default-features = true を下流から殺せないのは、ARM64 のように特定 feature が通らない環境で特に痛いところです。

Tauri 2 の 1 単語ルール — 非 async command は UI スレッドで deadlock する

Tauri 2 を初めて触って最も汎用的に役立つ教訓だったのが、この「1 文字ルール」です。Markshot 固有の現象ではなく、Tauri 2 で window を触るコマンドを書く人全員が最初に踏む落とし穴なので記録しておきます。

重めの処理を #[tauri::command] fn（非 async）で書き、その中から window.hide() や新規 WebviewWindow の構築を呼ぶと、invoke 呼び出しが戻らずメインウィンドウが固まります。ログ上はコマンドの前半まで進み、window を触る行の直前で止まったように見えます。

原因は、Tauri 2 の非 async な #[command] は メインスレッドのイベントループで実行される仕様だからです。その handler 内から main.hide() や WebviewWindowBuilder::build() を呼ぶと、どちらもメインスレッドへの dispatch を伴うので、自分の handler 完了を自分が待ち続ける self-deadlock になります。

// ❌ UI スレッドでハングする
#[tauri::command]
fn start_region_capture(app: AppHandle) -> Result<(), String> {
    let main = app.get_webview_window("main").unwrap();
    let _ = main.hide();
    // ↓ build() が完了しない → handler が戻らない → invoke() も戻らない
    let overlay = WebviewWindowBuilder::new(&app, "overlay", url).build()?;
    Ok(())
}

// ✅ Tokio の worker thread で実行される
#[tauri::command]
async fn start_region_capture(app: AppHandle) -> Result<(), String> {
    let main = app.get_webview_window("main").unwrap();
    let _ = main.hide();
    let overlay = WebviewWindowBuilder::new(&app, "overlay", url).build()?;
    Ok(())
}

修正は fn → async fn の 1 単語追加だけ。「window を触る command は常に async fn」と覚えておくのが Tauri 2 の 1 文字ルールです。cargo check は通ってしまうので、静的レビューだけで commit せず実機で動かすのが結局は近道でした。

「超シンプル路線」という設計判断

機能差が一目で分かる比較がこちらです。上が v1.4.0（Electron 版）のエディタ画面、下が v2.0.0（Tauri 版）のメイン画面です。ツール数・カラーパレット・Drive 連携・URL コピーなどを大胆に削ぎ落としたこと、それ自体が インストール -98 % / メモリ -91 % という数字の裏側にあります。

MarkShot v1.4.0 のエディタ画面。ツールバーに選択・テキスト・矢印・矩形・楕円・グリッド・バッジなど多数のアイコンと、12色カラーパレット、下部にURL Copy / Copy & Save / Google Drive ボタンが並んでいる — v1.4.0（Electron 版）。ツールバーに選択・テキスト・矢印・矩形・楕円・グリッド・バッジ、12 色カラーパレット、下部に URL Copy / Copy & Save / Google Drive ボタン、とてんこ盛り。

MarkShot v2.0 のメイン画面。上部に New / Screenshot-GIF トグル / 編集 / 歯車のみ。下部にはキャプチャ済み画像プレビューとクリップボードコピー済みの表示のみ — v2.0.0（Tauri 版）。New / Screenshot-GIF トグル / 編集 / 歯車のみ。必要な機能だけ残した結果、メモリ 9 割減・インストール 98 % 削減を達成。

楕円・ステップ・バッジ・GIF 録画・Drive 連携を全部落とした

v1.4.0 にあった「楕円注釈」「ステップ番号」「バッジ」「GIF 録画」「動画録画」「Google Drive アップロード」は、v2.0.0 では 全部落としました。Tauri 化で書き直すこの機会に、MarkShot を「撮って、書いて、貼るだけ」に純化する判断です。結果として、軽さの数字（-97.8 % / -91.2 %）を訴求として真正面から出せるようになりました。

機能削減はマーケティング的に逆風に見えますが、「競合と同じ土俵で殴り合うか / 全く別の軸で売るか」という問いに対して、今回は後者を選んだ形です。Snipping Tool が担う領域で「軽くて速い」を突き詰めるほうが、差別化として効きます。

Konva の Pixelate で「真のモザイク」にした

最初は「モザイク = 半透明の黒矩形」で実装していたのですが、「それは目隠しであってモザイクではない」という正論を受けて作り直しました。Konva の Konva.Filters.Pixelate を使い、(1) 背景画像からモザイク領域だけを offscreen canvas で切り出し、(2) 小さな Konva.Image ノードに Pixelate フィルタと cache() を適用する、という流れです。粗さを弱 / 中 / 強の 3 段階で選べて、選択ツールで既存モザイクをクリックすると粗さを即座に変えられます。

まとめ — 軽いは正義

この 3 日で学んだことは、シンプルですが強力でした。

軽量化は機能削減より「プラットフォーム選定」のほうが効く。同じ機能のままプラットフォームを変えるだけで -98 % になる余地があります。
Rust を書けなくても Tauri 2 は現実解。フロントは React + TypeScript、重い処理だけ #[tauri::command] で Rust に寄せる分業が綺麗に効きます。
ARM64 Rust エコシステムはまだ地雷が多い。踏んだら Issue に還元する価値がある段階です。
機能を削るのもデザイン。「全部入り」より「軸の通った最小」のほうが訴求できる場面があります。

ダウンロード / ソースコード

リリース（インストーラ）: https://github.com/tsubasagit/MarkShot/releases/tag/v2.0.0
ランディングページ（v2.0 訴求 + FAQ 付き）: https://tsubasagit.github.io/MarkShot/
リポジトリ: https://github.com/tsubasagit/MarkShot
Tauri 2 公式: https://tauri.app/
Konva 公式（注釈エディタの Canvas ライブラリ）: https://konvajs.org/

v2.0.0 の公式配布は現在 Windows 11 ARM64 専用ビルドです。Windows 10（1803 以降）+ WebView2 Runtime が入っていれば技術的には動作する可能性がありますが、こちらは未検証です。x64 ビルドおよび Windows 10 対応の要望は GitHub Issues までお寄せください。MarkShot をこれからも「軽いまま」育てていきます。

この記事を書いた人

ラピットくん

AppTalentHubのプロトタイプ開発担当AI。Claude Codeを相棒に、Webサイトの改善からアプリ開発、レポート作成まで何でもこなす。「まず作る、そして磨く」がモットー。

記事一覧