はじめに

HTML、CSS、JavaScriptを使ってデスクトップアプリを開発できるフレームワークとして、Electron、Tauri、Wailsがあります。

3つともWeb技術で画面を作成でき、Windows、macOS、Linux向けのデスクトップアプリを開発できます。

しかし、内部の仕組みは同じではありません。

ElectronはChromiumとNode.jsをアプリに組み込みます。一方、TauriとWailsは、基本的にOSが提供するWebViewを利用します。

バックエンドに使用する言語も異なります。

ElectronはJavaScriptまたはTypeScript、TauriはRust、WailsはGoを中心に使用します。

そのため、同じ画面を表示するアプリを作ったとしても、配布サイズ、起動時間、メモリ使用量、OS機能との連携方法、開発の難しさなどに違いが生まれます。

この記事では、Electron、Tauri、Wailsについて、次の項目を比較します。

• 基本的な仕組み
• 使用する言語
• 対応OS
• 開発環境の作りやすさ
• フロントエンド開発
• バックエンド開発
• OS機能との連携
• セキュリティ
• 配布ファイルのサイズ
• 起動時間
• メモリ使用量
• ビルド時間
• エコシステム
• 向いているアプリ

また、起動時間やアプリサイズについては、同じ条件で作成したサンプルアプリを使って測定します。

単純に「どれが一番軽いか」を決めるのではなく、それぞれがどのようなプロジェクトに向いているのかを考えていきます。

比較

Electron・Tauri・Wailsとは

Electronとは

Electronは、JavaScript、HTML、CSSを使ってデスクトップアプリを開発するためのフレームワークです。

ChromiumとNode.jsをアプリに組み込むことで、Webアプリに近い開発方法のままWindows、macOS、Linux向けのデスクトップアプリを作成できます。

Electronでは、アプリ全体を管理するメインプロセスと、Webページを表示するレンダラープロセスを分けて実装します。

バックエンドでもNode.jsを利用できるため、JavaScriptまたはTypeScriptを中心に開発を完結させられる点が特徴です。

React、Vue、Svelteなどのフロントエンドフレームワークに加え、npmで公開されている多数のパッケージも利用できます。

一方で、アプリごとにChromiumとNode.jsを含めるため、配布ファイルやメモリ使用量が大きくなりやすい傾向があります。

Tauriとは

Tauriは、HTML、CSS、JavaScriptなどでUIを作成し、バックエンドにRustを使用できるフレームワークです。

Electronとは異なり、基本的にはブラウザエンジンをアプリへ同梱せず、OSが提供するWebViewを利用します。

Tauriのアプリは、WebViewで動作するフロントエンドとRustで実装されたバックエンドが、メッセージ通信を通して連携する構成です。

アプリ固有のコードとアセットを中心に配布できるため、Electronより小さなバンドルを作りやすいと公式サイトでも説明されています。

また、フロントエンドから利用できるコマンドや機能を制限する仕組みがあり、権限を意識した設計を行いやすい点も特徴です。

Wailsとは

Wailsは、Web技術とGoを組み合わせてデスクトップアプリを開発するフレームワークです。

画面はHTML、CSS、JavaScriptまたはTypeScriptで作成し、アプリのバックエンド処理をGoで実装します。

Wailsもブラウザ全体をアプリへ組み込むのではなく、OSのネイティブなWebViewを再利用します。

WindowsではWebView2を利用し、macOSとLinuxでも各プラットフォームのレンダリング環境を利用します。

Goで定義したメソッドは、生成されたバインディングを通してJavaScript側から呼び出せます。Goの構造体に対応するTypeScriptモデルを生成する機能も用意されています。

本番ビルドでは、フロントエンドのアセットを含む実行ファイルを生成できます。Wailsの公式CLIでは、プロジェクトの作成、開発、ビルド、パッケージ化を行えます。

基本項目の比較

配布サイズやメモリ使用量は、フロントエンドの構成、使用するライブラリ、ビルド設定、対象OSによって変わります。

この表は、各フレームワークの構造から考えられる一般的な傾向です。

内部構造の違い

ElectronはChromiumとNode.jsを同梱する

Electronの大きな特徴は、ChromiumとNode.jsをアプリ内に含めることです。

利用者のOSに入っているブラウザ環境へ依存せず、開発者が指定したElectronのバージョンに対応するChromium上で画面を動かせます。

そのため、Windows、macOS、Linuxの間で、HTMLやCSSの表示を統一しやすくなります。

複雑なWebアプリを移植する場合や、比較的新しいWeb APIを利用したい場合にも有利です。

ただし、アプリごとにブラウザエンジンを含めることが、配布サイズとメモリ使用量の増加につながります。

TauriはWebViewとRustを組み合わせる

Tauriは、OSのWebViewにHTML、CSS、JavaScriptを表示し、システム側の処理をRustで実装します。

Windows、macOS、Linuxの主要なデスクトップ環境に対応するため、WebViewの管理にはWRY、ウィンドウの管理にはTAOなどが使われています。

ブラウザエンジンを毎回同梱しないため、アプリ固有のコードとアセットを中心に配布できます。

その反面、Windows、macOS、Linuxで利用されるWebViewが異なるため、OS間でCSSやWeb APIの動作に差が出る可能性があります。

WailsはWebViewとGoを組み合わせる

WailsもOSのWebViewを使いますが、バックエンドにはGoを利用します。

Goで作成した構造体のメソッドをフロントエンドへ公開すると、生成されたJavaScriptまたはTypeScriptの関数を通して呼び出せます。

Wailsのランタイムには、ウィンドウ、メニュー、ダイアログ、イベント、ブラウザ、ログ、クリップボードなどを操作する機能があります。

WebViewを使って画面を表示する点はTauriと似ていますが、バックエンドの設計や利用できるライブラリはGoのエコシステムが中心です。

開発環境の作りやすさ

ElectronはNode.jsだけで始めやすい

Electronは、Node.jsとパッケージマネージャーがあれば開発を始められます。

Webフロントエンドの開発経験がある人であれば、新しいプログラミング言語を学ばずに進められる点が大きな利点です。

フロントエンドとバックエンドの両方をTypeScriptで統一することもできます。

ただし、Electron本体、ビルドツール、パッケージ作成ツールなどの設定が増えると、プロジェクト構成が複雑になることがあります。

TauriはRustの環境が必要になる

Tauriの開発には、Node.jsなどのフロントエンド環境に加えて、Rustと対象OSに応じたビルド環境が必要です。

Rustを使った経験がない場合、環境構築だけでなく、所有権、借用、エラー処理、非同期処理などを学ぶ必要があります。

一方で、Rustに慣れている開発者にとっては、処理性能や型安全性を活かしたバックエンドを実装できます。

WailsはGoの環境が必要になる

Wailsでは、Go、Node.js、Wails CLIに加えて、OSごとに必要なWebView関連の環境を用意します。

環境が正しく設定されているかは、Wails CLIの診断機能で確認できます。Wailsの本番ビルドにはwails buildを使用します。

Goは文法が比較的コンパクトで、標準ライブラリも充実しています。

Rustと比べて言語機能がシンプルであるため、Web開発者がバックエンド言語を新しく学ぶ場合にも取り組みやすいでしょう。

フロントエンド開発の違い

3つとも主要なWebフレームワークを利用できる

Electron、Tauri、Wailsでは、React、Vue、Svelteなどを使ってUIを構築できます。

同じフロントエンドコードを使用すれば、画面自体の実装方法に大きな違いはありません。

ただし、JavaScriptからバックエンド処理を呼び出す部分は、それぞれ異なります。

ElectronではIPC、Tauriではコマンドやイベント、Wailsでは自動生成されたバインディングやイベントを使用します。

Electronは表示環境を統一しやすい

ElectronはアプリにChromiumを同梱するため、対象OSが異なっても同じバージョンのレンダリングエンジンを利用できます。

新しいCSS機能やWeb APIを使う場合も、Electronが採用しているChromiumの対応状況を基準にできます。

TauriとWailsはOSごとの確認が重要

TauriとWailsはOSのWebViewを利用します。

配布サイズを小さくしやすい一方で、WebViewのバージョンや実装がOSによって異なります。

特に、CSSの細かな表示、ドラッグ・アンド・ドロップ、ファイル関連API、入力操作などは、Windows、macOS、Linuxのすべてで確認したほうがよいでしょう。

バックエンド開発の違い

ElectronはJavaScriptとNode.jsを使う

Electronでは、バックエンドに相当するメインプロセスをJavaScriptまたはTypeScriptで実装できます。

Node.jsの標準APIやnpmパッケージを利用できるため、ファイル操作、HTTP通信、データベース、暗号化などに必要な機能を見つけやすい点が強みです。

フロントエンドとバックエンドを同じ言語で実装できるため、小規模なチームでも開発しやすいでしょう。

TauriはRustを使う

Tauriでは、重いデータ処理、ファイル操作、ネイティブ機能との連携などをRustで実装できます。

Rustは、ガベージコレクションに依存せず、高い処理性能とメモリ安全性を両立することを重視した言語です。

その反面、3つの中では学習コストが最も高くなりやすい選択肢です。

WailsはGoを使う

Wailsでは、バックエンド処理をGoで実装します。

GoはHTTP通信、JSON処理、ファイル操作、並行処理、テストなどの標準機能が充実しています。

APIクライアント、ログビューアー、ダウンロードツール、データ変換ツールなど、ネットワーク処理や並行処理を行うアプリと相性がよいでしょう。

既存のGo製CLIツールにGUIを追加する用途にも向いています。

OS機能との連携

ElectronはAPIとnpmパッケージが豊富

Electronには、ウィンドウ、メニュー、ダイアログ、通知、クリップボード、システムトレイなどを扱うAPIがあります。

npmのパッケージも豊富で、必要な機能を見つけやすいことが利点です。

ただし、レンダラープロセスからNode.jsやOS機能へ無制限にアクセスできる設計にすると、セキュリティ上の問題が起こりやすくなります。

OS機能はメインプロセス側に置き、必要な処理だけを安全な橋渡しを通して公開することが重要です。

Tauriは権限を意識した設計がしやすい

Tauriでは、フロントエンドから呼び出すコマンドやプラグインの権限を限定できます。

必要な機能だけを公開する構成を作りやすく、権限を細かく管理したいアプリに向いています。

独自のネイティブ処理が必要な場合は、Rust側にコマンドを実装してフロントエンドから呼び出します。

WailsはGoのメソッドを公開する

Wailsでは、GoのメソッドをJavaScript側から呼び出せます。

ウィンドウ、メニュー、ダイアログ、イベント、クリップボードなどはWailsのランタイムから操作できます。

Wailsの標準機能にない処理については、GoのパッケージやOS固有の実装を利用します。

JavaScript側へ公開するメソッドを必要最小限にするなど、アプリ側で適切に境界を設計する必要があります。

セキュリティの違い

Electronではプロセス間の境界が重要

Electronでは、画面を表示するレンダラープロセスと、OS機能を扱うメインプロセスを適切に分離する必要があります。

外部コンテンツを読み込むアプリや、利用者が入力したHTMLを表示するアプリでは、特に注意が必要です。

レンダラーに強い権限を持たせず、必要な機能だけを公開する設計が基本となります。

Tauriは権限の制限を組み込みやすい

Tauriは、WebViewから利用できるシステム機能を限定し、フロントエンドとRust側の境界を明確にする設計を取り入れています。

また、TauriはアプリへWebViewを同梱せず、OS側のWebViewを利用する方針です。

ただし、Tauriを使用するだけで自動的に安全になるわけではありません。

公開するコマンド、読み込むコンテンツ、ファイルアクセス、アップデート方法などを適切に設計する必要があります。

Wailsも公開範囲の管理が必要

Wailsでは、Goのメソッドをフロントエンドに公開できます。

便利な仕組みですが、公開したメソッドが自由なファイル操作やコマンド実行を受け付ける場合、実装方法によっては危険になります。

入力値の検証、アクセスできるパスの制限、公開するメソッドの最小化などが重要です。

ベンチマークで比較する項目

配布ファイルのサイズ

配布ファイルのサイズでは、次の2種類を分けて測定します。

1つ目は、アプリ本体の実行ファイルやアプリバンドルのサイズです。

2つ目は、利用者に配布するインストーラーのサイズです。

ElectronはChromiumとNode.jsを含むため、最小構成でも一定の容量が必要です。

TauriとWailsはOSのWebViewを利用するため、アプリ固有のバイナリとアセットを中心に配布できます。

ただし、Windows向けにWebView2の固定ランタイムやインストーラーを同梱する設定では、その分だけサイズが増えます。TauriでもWebView2を配布物に含める方法が用意されています。

Wailsにも、WindowsでWebView2をどのように導入するかを指定するビルドオプションがあります。

起動時間

起動時間は、実行ファイルを起動してから、画面が表示され操作可能になるまでの時間を測ります。

単にプロセスが作成されるまでの時間ではなく、フロントエンドの初期表示が完了するまでを測ることが重要です。

起動時間には、次の要素が影響します。

• フレームワークの初期化
• WebViewまたはChromiumの起動
• JavaScriptバンドルの読み込み
• フロントエンドフレームワークの初期化
• バックエンドの初期処理
• 設定ファイルやデータベースの読み込み
• セキュリティソフトによる検査
• OSのファイルキャッシュ

Electron、Tauri、Wailsの差だけを確認するには、起動時の処理をできるだけ同じにする必要があります。

メモリ使用量

メモリ使用量は、画面の表示が完了し、一定時間待った後に測定します。

Electronは複数のプロセスを起動するため、1つのプロセスだけではなく、アプリに関連するプロセス全体のメモリを合計する必要があります。

TauriとWailsについても、WebView関連の子プロセスが別に動作している場合は合計します。

比較では、次の2つを記録すると分かりやすくなります。

• 起動直後のメモリ使用量
• 30秒待機後のメモリ使用量

ビルド時間

ビルド時間は、キャッシュがない状態と、キャッシュがある状態を分けて測定します。

Rustを使用するTauriは、最初のビルドに時間がかかりやすい一方、変更内容やキャッシュの状態によって2回目以降の時間は大きく変わります。

Wailsでは、フロントエンドのビルドとGoのコンパイルが実行されます。Wailsのwails buildは、設定されたフロントエンドのインストール処理とビルド処理を確認してから本番バイナリを生成します。

Electronでは、JavaScriptのバンドルに加え、Electron本体やアプリのファイルをパッケージへまとめる時間がかかります。

公平に比較するための条件

同じフロントエンドを使用する

3つのフレームワークで、同じフロントエンドを利用します。

例えば、次の条件に統一します。

• ReactとTypeScriptを使用
• Viteでビルド
• 同じHTMLとCSSを使用
• 同じ画像とフォントを使用
• 外部通信は行わない
• 画面サイズを統一
• 開発者ツールは無効
• ソースマップは配布物に含めない

フロントエンドが異なると、フレームワークではなくReact、Vue、Svelteなどの差が結果へ含まれてしまいます。

同じ機能を実装する

比較用アプリには、次の機能を実装します。

• テキストの表示
• 入力フォーム
• ボタン操作
• 100件程度の一覧表示
• JSONデータの読み込み
• フロントエンドからバックエンド関数を呼び出す
• ファイル選択ダイアログを開く
• アプリのバージョンを表示する

画面を表示するだけのアプリでは、バックエンドやIPCの違いを十分に比較できません。

一方で、機能を増やしすぎるとアプリ固有の実装差が大きくなります。

本番ビルドを使用する

測定には、開発モードではなく本番用にビルドしたアプリを使用します。

開発モードでは、ホットリロード、デバッグ情報、開発サーバー、開発者ツールなどが動作します。

Wailsでは、wails buildによって本番用バイナリが生成されます。

TauriとElectronについても、デバッグ用ではなく配布用の設定でビルドします。

今回の測定環境

測定方法

配布サイズの測定方法

配布サイズは、次の値を測定します。

• 展開後のアプリ全体
• 実行ファイルまたはアプリバンドル
• インストーラー
• 圧縮ファイル

Windowsの場合、フォルダーや実行ファイルのプロパティからサイズを確認できます。

macOSでは、.app全体のサイズを測定します。

Linuxでは、実行ファイルだけでなく、AppImage、deb、rpmなど、実際に配布する形式も記録します。

TauriとWailsではWebViewを同梱する設定によって結果が変わるため、WebViewの配布方法も記事に記載します。

起動時間の測定方法

ウィンドウ表示までの時間を3回測定し、中央値を採用。

メモリ使用量の測定方法

アプリを起動して初期表示が完了した後、30秒間操作せずに待機します。

その後、アプリに関連するすべてのプロセスのメモリ使用量を合計します。

ビルド時間の測定方法

次の2種類を測定します。

• 依存関係やコンパイルキャッシュがない初回ビルド
• キャッシュがある状態での再ビルド

ベンチマーク結果

配布サイズ

一般的には、ChromiumとNode.jsを同梱するElectronが最も大きくなりやすく、OSのWebViewを利用するTauriとWailsは小さくなりやすいと考えられます。

ただし、インストーラーにWebView2を含めるか、デバッグ情報を削除しているか、バイナリ圧縮を利用しているかによって結果は変わります。

Wailsには、最終バイナリをUPXで圧縮するビルドオプションもあります。圧縮を使う場合は、圧縮前と圧縮後を分けて記録したほうが公平です。

起動時間

メモリ使用量

ビルド時間

ベンチマーク結果を見るときの注意点

数値だけで優劣を決めない

配布サイズが小さいことや、起動時間が短いことは重要ですが、それだけでフレームワークを選ぶべきではありません。

例えば、Electronのアプリサイズが大きくても、豊富なパッケージによって開発期間を短縮できる可能性があります。

Tauriのアプリが軽量でも、Rustを扱えるメンバーがいなければ、開発や保守に時間がかかるかもしれません。

Wailsが要件に合っていても、必要なプラグインや事例が少なければ、独自実装が必要になることがあります。

OSが違えば結果も変わる

Windows、macOS、Linuxでは、WebView、プロセス管理、ファイルキャッシュ、セキュリティ機能などが異なります。

WindowsでTauriが最も速かったとしても、macOSやLinuxで同じ順位になるとは限りません。

複数のOSへ配布する場合は、対象OSごとに測定するのが理想です。

フロントエンドが重ければ差が小さくなる

ReactやUIライブラリ、大量の画像、エディター、グラフなどを組み込むと、JavaScriptの読み込みと描画に時間がかかります。

アプリが複雑になるほど、フレームワークの初期化時間より、フロントエンド自体の処理時間が支配的になる可能性があります。

小さなサンプルアプリだけでなく、実際のアプリに近い機能を持つ試作品でも測定することが大切です。

開発体験の比較

Electron

Electronは、3つの中で最も情報量が多く、Web開発者が参加しやすい選択肢です。

フロントエンドとバックエンドをTypeScriptで統一でき、npmのエコシステムを幅広く利用できます。

既存のWebアプリをデスクトップ化する場合にも適しています。

一方、メインプロセス、レンダラープロセス、preloadスクリプト、IPCなどを適切に設計する必要があります。

Tauri

Tauriは、軽量な配布物と権限管理を重視したい場合に有力です。

フロントエンドはWeb技術で作成でき、OS機能や重い処理をRustへ分離できます。

Rustを使えるチームであれば、性能と安全性を意識したアプリを構築できます。

ただし、Rustの学習コストや、OSごとのWebView差への対応が必要です。

Wails

Wailsは、GoとWeb技術を組み合わせたい場合に適しています。

GoのメソッドをJavaScriptから呼び出す仕組みが分かりやすく、Goの構造体からTypeScriptモデルも生成できます。

Wailsの開発モードでは、Goコードの変更時にアプリを再ビルドし、フロントエンドの変更時には再読み込みする仕組みが用意されています。

Goで書かれたCLIツールや既存ライブラリを再利用したい場合、特に有力な候補です。

エコシステムの比較

Electronは情報とパッケージが豊富

Electronは長く利用されており、公式ドキュメント、サンプル、技術記事、動画、npmパッケージなどを見つけやすい環境です。

自動アップデート、インストーラー、クラッシュレポート、ネイティブ機能など、デスクトップアプリに必要な事例も豊富です。

Tauriは公式プラグインを利用できる

Tauriには、ファイルシステム、ダイアログ、通知など、デスクトップアプリで利用する機能に対応したプラグインがあります。

Electronより情報量は少ないものの、利用者と周辺ツールは増えています。

必要な機能がプラグインにない場合は、Rustで独自の処理を実装できます。

WailsはGoのライブラリを活用できる

Wails専用のプラグインや技術記事は、Electronと比較すると少ない傾向があります。

一方、HTTP通信、データベース、ファイル処理、画像処理、圧縮、暗号化などについては、Goの標準ライブラリや外部パッケージを利用できます。

Wails自体のエコシステムだけでなく、Go全体のエコシステムを含めて判断する必要があります。

目的別のおすすめ

開発速度と情報量を優先するならElectron

次の条件に当てはまる場合は、Electronが向いています。

• 開発メンバーがJavaScriptまたはTypeScriptに慣れている
• 既存のWebアプリをデスクトップ化したい
• npmのパッケージを利用したい
• Windows、macOS、Linuxで表示を統一したい
• 配布サイズより開発速度を優先したい
• 複雑なWeb UIを利用したい

チャットアプリ、コードエディター、ノートアプリ、管理ツールなど、Webアプリに近い構成のデスクトップアプリに適しています。

軽量性と権限管理を重視するならTauri

次の条件に当てはまる場合は、Tauriが向いています。

• 配布サイズを小さくしたい
• メモリ使用量を抑えたい
• Rustを利用したい
• 利用できる権限を細かく制限したい
• 処理性能や型安全性を重視したい
• 将来的なモバイル対応も検討している

軽量なユーティリティ、ローカルデータを扱うツール、セキュリティを意識した業務アプリなどに向いています。

Goの資産を利用するならWails

次の条件に当てはまる場合は、Wailsが向いています。

• Goをバックエンドに使いたい
• 既存のGoコードを再利用したい
• Go製CLIツールへGUIを追加したい
• ネットワーク通信や並行処理を行いたい
• Electronより軽量な構成にしたい
• Rustよりシンプルな言語を使いたい

APIクライアント、データ変換ツール、ログビューアー、ファイル管理ツール、ダウンロードツール、開発者向けユーティリティなどに適しています。

3つの選び方

JavaScriptだけで開発したい場合

JavaScriptまたはTypeScriptだけで、フロントエンドとバックエンドの両方を実装したいならElectronが適しています。

新しい言語を導入せずに開発を始められます。

Rustを使いたい場合

Rustの安全性や性能を活かしたい場合はTauriが適しています。

Web UIとRustを組み合わせた構成にしたいチームに向いています。

Goを使いたい場合

Goの標準ライブラリ、並行処理、既存コードを活かしたい場合はWailsが適しています。

既存のGo製ツールをデスクトップアプリ化するときにも選びやすいでしょう。

アプリサイズを最優先する場合

一般的な構成では、OSのWebViewを利用するTauriとWailsがElectronより小さくなりやすいと考えられます。

ただし、実際のサイズは、使用するフロントエンド、画像、フォント、ネイティブライブラリ、WebViewの配布方法によって変わります。

TauriとWailsのどちらが小さくなるかは、実際のアプリをビルドして確認する必要があります。

OS間の表示差を抑えたい場合

同じChromiumをアプリに同梱するElectronが有利です。

TauriとWailsでは、OSごとのWebView差をテストする必要があります。

比較結果のまとめ

終わりに

Electron、Tauri、Wailsは、いずれもWeb技術を利用してデスクトップアプリを開発できるフレームワークです。

しかし、内部構造とバックエンド言語には大きな違いがあります。

ElectronはChromiumとNode.jsをアプリに組み込み、JavaScriptまたはTypeScriptを中心に開発します。

配布サイズやメモリ使用量は大きくなりやすいものの、情報量、パッケージ、開発者の多さ、OS間での表示の一貫性が強みです。

TauriはOSのWebViewとRustを組み合わせます。

小さな配布サイズを目指しやすく、フロントエンドから利用できる機能や権限を制限した設計を行いやすい点が特徴です。

WailsはOSのWebViewとGoを組み合わせます。

Goのシンプルな文法、標準ライブラリ、並行処理、既存コードを活用しながら、Web技術でUIを作成できます。

起動時間、配布サイズ、メモリ使用量だけを見ると、TauriやWailsが有利になる場合があります。

しかし、ベンチマークの結果は、対象OS、ハードウェア、WebView、フロントエンド、バックエンドの初期処理、ビルド設定によって変わります。

そのため、インターネット上に掲載されている数値だけでフレームワークを決めるのではなく、実際に作るアプリに近い試作品で測定することが重要です。

開発速度とエコシステムを優先するならElectron、軽量性と権限管理を重視するならTauri、Goの資産や開発体験を活かすならWailsが有力な選択肢になります。

最終的には、性能だけでなく、開発チームが扱える言語、必要なOS機能、保守体制、将来の展開まで含めて選ぶことが、長期的に扱いやすいデスクトップアプリを作るためのポイントです。