MacとWindowsの両方で動くデスクトップアプリを作るとき、よく候補にあがるのがElectron(エレクトロン)とTauri(タウリ)です。どちらもWebサイトと同じ技術で画面を作れますが、中身の仕組みが違うため、向いている用途も変わります。
この覚え書では、二つの違い、メリットとデメリット、データベースを使うときの注意点、用途別の選び方を順に整理します。
ElectronとTauriはどんな道具か
どちらも、HTML、CSS、JavaScript(TypeScript)といったWebの技術で画面を作り、それをパソコン用のアプリとして配布できる仕組みです。一度作れば、MacでもWindowsでも同じ画面を使えます。
大きく違うのは、次の2点です。
- 画面を表示する部品:Electronは、Google Chromeの中身にあたるChromiumをアプリに同梱します。Tauriは、OSに最初から入っている表示部品(WindowsはWebView2、MacはWKWebView)を借りて使います。
- 裏側の処理を書く言語:ファイルの読み書きやデータベースなど、画面の裏で動く処理を、ElectronはNode.js(JavaScript)で、TauriはRustという言語で書きます。
この2つの違いが、容量、速さ、作りやすさの差につながっています。
比較表で見る違い
| 観点 | Electron | Tauri |
|---|---|---|
| 画面の作り方 | HTML / CSS / TypeScript | HTML / CSS / TypeScript(同じ) |
| 裏側の処理 | Node.js(TypeScript) | Rust |
| 画面を表示する部品 | Chromiumを同梱 | OSのWebViewを使う |
| インストーラーの容量 | 大きい(目安で100MB前後) | 小さい(目安で数MB〜十数MB) |
| メモリ使用量 | 多め | 少なめ |
| MacとWindowsでの見た目 | ほぼ同じ | 細かな差が出ることがある |
| 情報や事例の多さ | 非常に多い | 増えているが、Electronより少ない |
| セキュリティの初期状態 | 自分で設定を固める必要がある | 使う機能を許可する方式で、最初から厳しめ |
| 開発環境 | Node.jsだけで済む | Node.jsに加えてRustが必要 |
| スマートフォン対応 | なし | Tauri 2でiOS・Androidに対応 |
Electronのメリット・デメリット
メリット
- 画面も裏側もJavaScript(TypeScript)で書けるため、Web制作に慣れた人がそのまま作れます。
- Chromiumを同梱するので、MacとWindowsで表示がほぼ同じになり、OSごとの確認作業が減ります。
- VS CodeやSlackなど有名なアプリでも使われていて、情報が多く、困ったときに解決策を探しやすいです。
- Node.js向けの豊富なライブラリ(便利な部品)をそのまま使えます。
デメリット
- アプリが重く、インストーラーは100MB前後になり、メモリも多めに使います。古いパソコンやメモリの少ないパソコンでは不利です。
- セキュリティの設定を正しく組む必要があります。設定を誤ると、画面側から危険な操作ができてしまうおそれがあります。
- 同梱しているChromiumの弱点(脆弱性)に対応するため、定期的にバージョンを上げる保守が欠かせません。
Tauriのメリット・デメリット
メリット
- 軽く、容量もメモリも小さいので、古いパソコンでも動かしやすいです。
- 許可した機能しか使えない設計なので、安全な構成を作りやすいです。
- インストーラーが小さく、配布や導入が楽です。
- Tauri 2からは、同じ仕組みでスマートフォン向けのアプリも作れます。
デメリット
- 裏側の処理はRustで書きます。JavaScriptに比べて覚えることが多く、不具合を直すハードルが上がります。
- OSの表示部品を使うため、MacとWindowsで表示や動きに差が出ることがあり、両方での確認が必要です。
- 古いWindows 10の環境では、WebView2が入っているかを確認する必要があります。
- Electronに比べると、事例や情報がまだ少ないです。
どちらでも共通する注意点
どちらを選んでも、配布するときに同じ手間がかかる部分があります。
- コード署名:アプリに「誰が作ったか」を示す署名がないと、MacではGatekeeper、WindowsではSmartScreenという仕組みが警告を出します。Macで警告なしに配布するには、Apple Developer Program(有料)への登録と公証という手続きが必要です。
- 自動更新:どちらも自動更新の仕組みはありますが、更新ファイルを置いておく場所を用意して運用する必要があります。
- OSごとのビルド:MacとWindowsそれぞれ向けに、アプリを作り分ける(ビルドする)必要があります。Mac 1台からWindows向けをまとめて作るのは難しく、Windows機を使うか、GitHub Actionsのような自動化の仕組みで作るのが一般的です。
データベースを使うアプリの場合
顧客台帳やメモ帳のように、データを保存して検索するアプリでは、SQLite(エスキューライト)という、1つのファイルで動く小さなデータベースがよく使われます。
「ネイティブモジュールのビルドでつまずく」とは
ElectronでSQLiteを使うときの定番は better-sqlite3 というライブラリです。これは中身がC/C++で書かれた部品(ネイティブモジュール)で、動かす環境ごとにコンパイルしたファイルが必要になります。つまずきやすいのは次の3点です。
- Electron用に作り直す必要がある:Electronの中のNode.jsは、パソコンに入れたNode.jsとは版が違います。そのまま入れると「バージョンが合わない」というエラーでアプリが落ちるため、
electron-rebuildなどでElectron向けに作り直します。 - OSとCPUごとに別のファイルが要る:MacのApple SiliconとIntel、Windowsでは、それぞれ別のファイルが必要です。
- Electronを更新するたびに作り直しになる:Electronのバージョンを上げると、作り直しも必要になります。
とはいえ、多くの場合はビルド済みのファイルが配布されていて、設定が正しければ自動で入ります。「最初の環境づくりで一度つまずきやすい」くらいに考えておけば十分です。
Electronはデータベースを使うアプリに向いていないのか
向いていない、ということはありません。データベースを使うElectronアプリは数多くあります。
- TauriのRust部分も、OSごとにコンパイルが必要です。OSごとにビルドする手間は、どちらを選んでもほとんど変わりません。
electron-builderなどの配布用ツールに作り直しの手順を組み込んでおけば、あとは自動で処理されます。- ネイティブモジュールを避ける方法もあります。SQLiteをWebAssemblyという形式にした
sql.jsはビルド不要です。ただし、データはメモリ上で扱い、ファイルへの保存は自分で書く必要があるため、小規模なデータ向きです。また、新しいNode.jsには組み込みのSQLite(node:sqlite)も入り始めていますが、まだ試験的な扱いです。
アプリを更新してもデータが消えない仕組み
Electronでは、アプリ本体とユーザーのデータを別の場所に保存するのが標準の作り方です。
| アプリ本体 | ユーザーのデータ | |
|---|---|---|
| Mac | アプリケーションフォルダ | ライブラリ内のApplication Supportフォルダ |
| Windows | Program Filesなど | ユーザーフォルダ内のAppDataの中のRoamingフォルダ |
| アプリ更新時 | 新しい版に置き換わる | 触られない |
Electronには app.getPath('userData') という、データを置くための決まった場所を教えてくれる仕組みがあります。たとえばメモ帳アプリなら、メモを保存するSQLiteファイルをここに置けば、アプリを何度更新してもメモは残ります。
ただし、次の点に気をつけないと「データが消えたように見える」ことがあります。
- アプリ本体の中に保存しない:本体のフォルダに置くと、更新で丸ごと置き換わります。
- アプリ名を途中で変えない:保存場所のフォルダ名はアプリ名から決まるため、名前を変えると新しい空のフォルダを見に行きます。
- データの形を変えるときは移行処理を入れる:たとえばメモに「タグ」欄を足す場合、既存のデータベースに欄を追加する処理(マイグレーション)を更新版に入れておきます。
- アンインストール時の扱いを決めておく:Windowsのインストーラーは、設定によってデータを残すか消すかを選べます。
- 端末の故障には備えが要る:更新では消えなくても、パソコンが壊れればデータも失われます。書き出し機能や定期的なバックアップを用意しておくと安心です。
この設計の呼び方
この作り方だけを指す決まった名前はありませんが、「アプリ本体とユーザーデータの分離」と言えば通じます。関連する言葉には次のようなものがあります。
- 永続化(パーシステンス):アプリを閉じたり更新したりしても、データが残るように保存すること。
- ユーザーデータディレクトリ:OSが用意しているデータ用の置き場所。MacのApplication SupportやWindowsのAppDataがこれにあたります。
よく聞くMVCは、コードを「データの扱い(Model)」「画面(View)」「操作の受け付け(Controller)」に分ける考え方で、保存場所の話とは別物です。ただし、どちらも根っこには「役割ごとに分けて、片方を変えてももう片方に影響しないようにする」という関心の分離の考え方があります。
コードの側では、データベースを読み書きする処理を一か所にまとめるリポジトリパターンという設計がよく使われます。画面のコードから直接データベースを触らないようにしておくと、あとで保存先をSQLiteからクラウドのデータベースへ替えるときも、画面側を直さずに済みます。
用途別の向き・不向き
| 用途の例 | 向いている方 | 理由 |
|---|---|---|
| 顧客管理・予約台帳・在庫表 | Electron | TypeScriptだけで作れて保守しやすい。小規模なデータなら重さはほぼ問題にならない |
| Notionなど外部サービスと連携するツール | Electron | JavaScript向けの公式ライブラリをそのまま使えることが多い |
| 見積書・請求書などの印刷やPDF出力 | Electron | 同梱のChromiumでPDFを作るため、MacとWindowsで仕上がりがそろう |
| ExcelやCSVの取り込み・変換 | Electron(Tauriでも可) | JavaScriptのライブラリが豊富 |
| レシートプリンタなどUSB・シリアル機器との接続 | Electron | 事例やライブラリが多い |
| 常駐する小さなツール(タイマー、通知など) | Tauri | 一日中起動していてもメモリをほとんど使わない |
| 古いパソコン・メモリの少ないパソコン | Tauri | 動作が軽く、端末の負担が小さい |
| 大量の画像やファイルの一括処理 | Tauri(少量ならElectronでも可) | Rustは処理が速い |
| メール添付やUSBメモリで配布したい | Tauri | インストーラーが小さい |
| 将来スマートフォン版も出したい | Tauri | iOS・Androidにも対応している |
なお、バーコードリーダーはキーボードとして動くものが多く、その場合はどちらでも問題なく使えます。
判断の目安
迷ったときは、次の順で考えると決めやすくなります。
- スマートフォン版が必要か:必要ならTauri。最初からWebアプリにする選択肢も検討します。
- 端末が古い、常駐させたい、容量を小さくしたいか:当てはまるならTauri。
- それ以外の一般的な業務ツールか:Electronが無難です。
まとめ
Electronは「重いけれど作りやすく、どのOSでも見た目がそろう」道具、Tauriは「軽くて安全だけれど、Rustの知識とOSごとの確認が要る」道具です。
検索や登録、帳票の出力といった一般的な業務ツールならElectron、軽さやスマートフォン対応が大事ならTauri、というのがひとつの目安になります。データベースを使う場合も、データをアプリ本体と別の場所に保存する基本さえ押さえれば、どちらでも安心して作れます。
容量などの数字は一般的な目安です。実際に作るときは、小さな試作でインストーラーの大きさや、署名・更新の手順を確かめておくと確実です。
