Electron をやめて Wails を使おう：Go で作るデスクトップアプリ 2026 年版

社内ツール、データベースクライアント、ログビューアなど、小規模から中規模のデスクトップアプリを作るなら、Electron ではなく Wails を選んでください。Wails は Go のバックエンドと、OS にもともと入っている webview を組み合わせます。そのため、空のアプリのサイズは 295〜384 MB ではなく約 8〜11 MB に収まります（Elanis のベンチマーク、2026 年）。Web のフロントエンドはそのまま使い、Node を Go に置き換えます。手書きの IPC は自動生成されるバインディングになり、webview は OS が用意するので Chromium を同梱する必要もありません。ただし、Wails がすべてのベンチマークで勝つわけではなく、今でも Electron のほうが適しているアプリもあります。

要約

• サイズでは明確に勝っています。 空のアプリを CI で比較したベンチマークでは、Windows、macOS、Linux のいずれでも Wails のビルドは Electron の 30〜40 分の 1 のサイズでした（Elanis のベンチマーク、2026 年）。
• メモリと起動時間では圧勝とはいきません。 同じベンチマークで、Wails のメモリ使用量は macOS と Linux では少なかったものの、Windows では多くなりました。起動は 3 つの OS すべてで Electron のほうが速い結果でした。
• より大きな利点は構造面にあります。 配布するのは Go のバイナリ 1 つだけです。バックエンドは Go の標準ライブラリと goroutine で書き、型付きの自動生成バインディング経由で呼び出します。ページ内で Node を動かすこともありません。
• Electron のメジャーバージョンを追いかけなくて済みます。 Electron は 8 週間ごとに新しいメジャーバージョンを出し、サポートするのは最新の 3 つだけです（Electron、2026 年）。Wails では、webview のパッチはアプリの外側で当てられます。Windows では Evergreen WebView2 のアップデーター（Microsoft Learn、2026 年）、macOS では OS のアップデート、Linux ではディストリビューションのパッケージが担います。
• それでも Electron が正解になる場面があります。 どこでも同じ Chromium のレンダリングが必要な場合、Node のネイティブモジュールに依存している場合、すでに大規模な Electron のコードベースがある場合です。

Electron はすべてのアプリに何を同梱しているのか？

Electron アプリは、それぞれが独自のブラウザと独自の JavaScript ランタイムを同梱しています。Electron のドキュメントには「Chromium と Node.js をバイナリに組み込むことで、Electron は 1 つの JavaScript コードベースを維持できるようにしている」とあり、これはプラットフォームをまたいだ話です（Electron ドキュメント、2026 年）。代わりの選択肢が 3 つのネイティブコードベースだった時代には、理にかなった取引でした。ただしその結果、インストールするアプリのひとつひとつが Chromium を丸ごと 1 セット抱えることになります。

プロセスモデルも Chromium 由来です。Node.js を動かすメインプロセスが 1 つあり、それに加えて「開いている BrowserWindow ごと（および Web の埋め込みごと）に別々のレンダラープロセス」があります（Electron のプロセスモデル、2026 年）。バックエンドのロジックはメインプロセスに、UI はレンダラーに置かれ、その 2 つを手書きの IPC メッセージでつなぎます。

さらにリリーススケジュールの問題があります。「Electron のメジャーバージョンのリリース間隔は 8 週間」で、サポートされるのは最新の安定版メジャー 3 つだけです（Electron のタイムライン、2026 年）。Electron 44.0.0 は 2026 年 8 月 25 日に安定版となり、Chromium M152 と Node v24.18.1 を搭載しています。Electron 45 は 2026 年 10 月 20 日にリリース予定です（Electron のリリース、2026 年）。Chromium のセキュリティ修正をユーザーに届けるには、このスケジュールに合わせて新しいビルドを出し続ける必要があります。

Wails はどのように動くのか？

Wails は自らを「Go のための軽量で高速な Electron の代替」と説明しています（Wails ドキュメント、2026 年）。ブラウザを同梱する代わりに、「プラットフォームのネイティブなレンダリングエンジンを再利用」します。README には「ネイティブのレンダリングエンジンを使用。ブラウザは埋め込まない！」とあります（GitHub の Wails、2026 年）。使われるエンジンは OS によって異なります。

• Windows では Microsoft WebView2 で UI を描画します。
• macOS では WebKit で描画します。
• Linux では WebKitGTK で描画します。

Wails アプリは「webkit のフロントエンドを持つ、標準的な Go アプリケーション」です（Wails の仕組み、2026 年）。フロントエンド（React、Svelte、Vue、または素の HTML）は //go:embed で Go のバイナリに埋め込まれるので、アプリ全体を 1 つの実行ファイルとして配布できます。

2 つの部分をつなぐのは Bind オプションで、これは「どの struct のメソッドをフロントエンドに公開するかを指定」するものです。wails dev を実行すると、Wails はそれらのメソッドを読み取り、JavaScript のラッパーと TypeScript の型宣言を生成します。フロントエンドからは、Go のメソッドを async 関数のように呼び出せます。逆方向にデータを送るときは、Go がランタイムのイベントを発行し、JavaScript がそれを受け取ります。

安定版の系列は Wails v2 で、2026 年 8 月 10 日に v2.14.0 がリリースされました（Wails のリリース、2026 年）。ライセンスは MIT で、GitHub のスター数は約 3.63 万です。Wails で作られたアプリには、スター数約 1.3 万の Redis GUI である Tiny RDM（Tiny RDM、2026 年）や、gRPC クライアントの Wombat（Wails のショーケース、2026 年）があります。

Wails vs Electron：アプリはどれだけ小さく、軽くなるのか？

ずっと小さくなりますが、常に軽くなるわけではありません。公開されている中で最も参考になる数値は、Elanis の web-to-desktop フレームワーク比較です。これは各フレームワークで空のアプリを GitHub CI 上でリリースモードでビルドし、サイズ、メモリ、起動時間を計測したものです。最終更新は 2026 年 9 月 4 日です（Elanis のベンチマーク、2026 年）。

出典：Elanis web-to-desktop-framework-comparison、2026-09-04 更新。空のアプリ、リリースビルド、GitHub CI。フレームワーク同士の比較は同じ OS の中だけで行ってください。README にはフレームワークのバージョンが記載されていません。

サイズでは Wails の完勝です。空の Wails アプリは Electron と比べて、Windows で約 35 分の 1、macOS で約 40 分の 1、Linux で約 33 分の 1 のサイズです。ホテルの遅い回線だと、11 MB なら数秒で済むダウンロードが、384 MB では数分かかります。ノート PC のツールがそれぞれ自前の Chromium を抱えていれば、その差は積み重なります。

メモリは OS によって変わります。macOS では、Wails のメモリ使用量は Electron の約 3.7 分の 1 でした。Linux では約 1.6 分の 1 でした。Windows では逆に多く、Electron の 278 MB に対して約 323 MB でした。ベンチマークでは内訳まで示されていませんが、WebView2 は Chromium ベースの Microsoft Edge のエンジンを使い、独自のブラウザプロセスを動かします。そのため Windows では、Chromium エンジンを同梱しなくても、メモリ上ではおそらくその分を負担しています。

このベンチマークでは、どの OS でも Electron のほうが速く起動しました。Windows では Electron が約 206 ms、Wails が 559 ms でした。macOS では 640 ms 対 1,740 ms の差がありました。Linux では 204 ms 対 263 ms と、両者は近い値でした。CI ランナー上の空のアプリはあくまで大まかな目安で、ユーザーの環境での結果とは一致しません。それでも、Wails のほうが常に速く起動するという主張は、このデータからは裏付けられません。

Windows についてはもう 1 つ注意点があります。Wails アプリには Microsoft WebView2 Runtime が必要です。これは Windows 11 に同梱されており、Microsoft は「Windows 10 デバイスの大多数にはすでに WebView2 Runtime がインストールされている」と述べています（Microsoft Learn、2026 年）。残りの環境はブートストラッパーを埋め込めばカバーでき、増えるサイズは約 150 KB です（Wails の Windows ガイド、2026 年）。ただし、エンジンのバージョンを固定したい場合、Microsoft は「Fixed Version のバイナリは 250 MB を超え、その分だけアプリのパッケージが大きくなる」と警告しています。そうなると、Windows でのサイズの優位性はほとんど消えてしまいます。

Wails のコードはどのようなものか？

ここでは、チーム向けに作るような小さなログビューアを例にします。ログファイルを選び、最後の 200 行を表示し、その後は書き込まれた新しい行をストリーミングで表示します。さらに、サービスのヘルスチェック用エンドポイントにも ping を送ります。処理はすべて Go で実行し、フロントエンドは描画するだけです。

Go 側は、エクスポートされたメソッドを持つ普通の struct です。TailLog は os と bufio でファイルを読みます。CheckHealth は net/http を使い、タイムアウト付きで HTTP エンドポイントを呼び出します。net/http については HTTP コース で扱っています。以下のコードは Wails v2.14.0 でコンパイルできます。

example.gogo
// app.go
package main

import (
	"bufio"
	"context"
	"fmt"
	"net/http"
	"os"
	"sync"
	"time"
)

const tailLines = 200

type App struct {
	ctx        context.Context
	mu         sync.Mutex
	stopFollow context.CancelFunc
}

func NewApp() *App { return &App{} }

// startup is called by Wails once the app is running. Keep the context:
// runtime calls like EventsEmit need it.
func (a *App) startup(ctx context.Context) {
	a.ctx = ctx
}

// TailLog returns the last 200 lines of the log file at path.
func (a *App) TailLog(path string) ([]string, error) {
	f, err := os.Open(path)
	if err != nil {
		return nil, fmt.Errorf("open log: %w", err)
	}
	defer f.Close()

	lines := make([]string, 0, tailLines)
	sc := bufio.NewScanner(f)
	sc.Buffer(make([]byte, 0, 64*1024), 1024*1024) // allow long JSON log lines
	for sc.Scan() {
		if len(lines) == tailLines {
			lines = lines[1:]
		}
		lines = append(lines, sc.Text())
	}
	if err := sc.Err(); err != nil {
		return nil, fmt.Errorf("read log: %w", err)
	}
	return lines, nil
}

// CheckHealth calls a service's health endpoint and returns the status code.
func (a *App) CheckHealth(url string) (int, error) {
	ctx, cancel := context.WithTimeout(a.ctx, 3*time.Second)
	defer cancel()

	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return 0, fmt.Errorf("build request: %w", err)
	}
	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		return 0, fmt.Errorf("health check %s: %w", url, err)
	}
	defer resp.Body.Close()
	return resp.StatusCode, nil
}

main はビルド済みのフロントエンドを埋め込み、struct を Bind に渡します。Wails v2 のモジュールパスは github.com/wailsapp/wails/v2 です。

example.gogo
// main.go
package main

import (
	"embed"
	"log"

	"github.com/wailsapp/wails/v2"
	"github.com/wailsapp/wails/v2/pkg/options"
	"github.com/wailsapp/wails/v2/pkg/options/assetserver"
)

//go:embed all:frontend/dist
var assets embed.FS

func main() {
	app := NewApp()

	err := wails.Run(&options.App{
		Title:  "Log Viewer",
		Width:  1100,
		Height: 720,
		AssetServer: &assetserver.Options{
			Assets: assets,
		},
		OnStartup: app.startup,
		Bind:      []interface{}{app},
	})
	if err != nil {
		log.Fatal(err)
	}
}

wails dev を実行すると、Wails が frontend/wailsjs/go/main/App.js と App.d.ts を生成します。型宣言は次のようになります。

example.tsts
export function TailLog(arg1: string): Promise<Array<string>>;
export function CheckHealth(arg1: string): Promise<number>;

バインドされたメソッドはすべて Promise を返します。Go のメソッドが nil 以外の error を返すと、Promise はそのエラーで reject されます。そのため、フロントエンドでは普通に await と try/catch を使えます。

example.tsts
import { TailLog, CheckHealth } from "../wailsjs/go/main/App";

async function openLog(path: string) {
  try {
    const lines = await TailLog(path);
    renderLines(lines);
  } catch (err) {
    showError(`Could not read ${path}: ${err}`);
  }
}

async function refreshStatus(url: string) {
  try {
    const status = await CheckHealth(url);
    setStatus(status === 200 ? "healthy" : `HTTP ${status}`);
  } catch (err) {
    setStatus(`down: ${err}`);
  }
}

チャネル名を手作業でそろえたり、メッセージの形を手で確認したりする作業はなくなります。Go のメソッドのシグネチャを変えれば、再生成される型宣言も一緒に変わるので、型チェックを行うフロントエンドのビルドで古くなった呼び出しが見つかります。

ランタイムイベントで新しい行をストリーミングする

書き込み中のファイルを追いかける処理は、Go の並行処理が活きる場面です。FollowLog はファイルの末尾までシークし、その後 goroutine が新しい行をポーリングして、1 行ずつ runtime.EventsEmit でフロントエンドに送ります。別のファイルを開くと、それまでの追跡処理はキャンセルされます。

example.gogo
// follow.go
package main

import (
	"bufio"
	"context"
	"fmt"
	"io"
	"os"
	"strings"
	"time"

	"github.com/wailsapp/wails/v2/pkg/runtime"
)

// FollowLog streams lines appended to path as "log:line" events.
func (a *App) FollowLog(path string) error {
	f, err := os.Open(path)
	if err != nil {
		return fmt.Errorf("open log: %w", err)
	}
	if _, err := f.Seek(0, io.SeekEnd); err != nil {
		f.Close()
		return fmt.Errorf("seek log: %w", err)
	}

	a.mu.Lock()
	if a.stopFollow != nil {
		a.stopFollow()
	}
	ctx, cancel := context.WithCancel(a.ctx)
	a.stopFollow = cancel
	a.mu.Unlock()

	go a.follow(ctx, f)
	return nil
}

func (a *App) follow(ctx context.Context, f *os.File) {
	defer f.Close()

	r := bufio.NewReader(f)
	var partial strings.Builder
	ticker := time.NewTicker(500 * time.Millisecond)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			return
		case <-ticker.C:
			for {
				chunk, err := r.ReadString('\n')
				partial.WriteString(chunk)
				if err != nil {
					break // no complete line yet, try again on the next tick
				}
				line := strings.TrimRight(partial.String(), "\r\n")
				runtime.EventsEmit(a.ctx, "log:line", line)
				partial.Reset()
			}
		}
	}
}

フロントエンドでは、EventsOn で一度だけ購読します。

example.tsts
import { FollowLog } from "../wailsjs/go/main/App";
import { EventsOn } from "../wailsjs/runtime/runtime";

EventsOn("log:line", (line: string) => appendLine(line));

await FollowLog("/var/log/payments-api/app.log");

Electron で同じ機能を作るなら、メインプロセスで fs を使い、読み込み用に ipcMain.handle を、新しい行ごとに webContents.send を書き、さらにその両方を contextBridge 経由で公開する preload スクリプトが必要です。Wails なら、Go の struct 1 つとイベント名 1 つで済みます。なお、このバージョンはログローテーションに対応していません。本番環境向けの追跡処理なら、ファイルサイズが小さくなったときにファイルを開き直すようにします。

Wails v3 では形が少し変わります。サービスを application.NewService(&LogService{}) で application.Options.Services に登録し、フロントエンドは wailsjs ではなく bindings ディレクトリから生成コードを import します（Wails v3 のバインディング、2026 年）。フロントエンドが呼び出すのが Go の型のメソッドである点は変わりません。

セキュリティモデルはどう違うのか？

Electron のセキュリティはチェックリスト頼みですが、Wails は最初から攻撃対象領域が小さくなっています。Electron 自身のセキュリティガイドは、リモートコンテンツに対して Node integration を無効のままにすること（5.0.0 以降のデフォルト）、コンテキスト分離を有効のままにすること（12.0.0 以降のデフォルト）、プロセスのサンドボックス化を有効のままにすること（20.0.0 以降のデフォルト）、すべての IPC メッセージの送信元を検証すること、Content Security Policy を設定すること、そしてページに API を公開するときは contextBridge だけを使うことを求めています（Electron のセキュリティ、2026 年）。

今ではこれらのデフォルトは適切です。しかし、どれもコード側で無効にできるフラグです。さらに、どのアプリも Chromium を同梱しているため、ブラウザのバグは、パッチ適用済みの Electron でビルドしたアップデートを出すまで、インストール済みのアプリに残り続けます。

Wails は、こうした項目のいくつかを設計の段階でなくしています。ページ内に Node.js がないので、設定を誤る nodeIntegration もありません。ページが受け取るのは、バインドした Go のメソッドと Wails のランタイム API だけで、ホストからそれ以外のものは渡りません。メソッドのどれかがそれを行わない限り、ページはファイルを読むこともプロセスを起動することもできません。webview は OS のものなので、そのセキュリティ修正は自分たちのリリースパイプラインではなく、Windows では自動更新される Evergreen WebView2 ランタイム、macOS では OS のアップデート、Linux ではディストリビューションのパッケージを通じて届きます。ただし Windows で Fixed Version のランタイムに固定した場合、パッチ適用は再び開発側の責任になります。

リスクが残る部分もあります。バインドしたメソッドはどれも API であり、それを呼び出すページが、自分で管理していないコンテンツを表示している可能性もあります。先ほどのログビューアでは、TailLog はどんなパスでも受け付けます。アプリが信頼できない HTML を表示することがあれば、これはファイルを読み取るための足がかりになります。HTTP ハンドラーの入力を検証するのと同じように、Go 側で引数を検証してください。パスは許可したディレクトリに、URL は既知のホストに限定します。CSP も引き続き重要です。ページは普通のブラウザのページと同じように、ネットワークリクエストを送れるからです。

Node の依存パッケージがインストール時に何をできるのかという関連する疑問については、Go は Node.js よりサプライチェーン攻撃に対して安全なのか？を参照してください。

Wails の弱点はどこにあるのか？

Wails は同梱のブラウザ 1 つの代わりに、3 種類の webview を相手にすることになります。Microsoft は、Evergreen WebView2 Runtime を使う場合、アプリの下でエンジンが更新されるため、前方互換性のテストを用意するよう勧めています（Microsoft Learn、2026 年）。macOS では Safari の背後にあるエンジンである WebKit が対象になるので、Chrome でしか確認していない CSS や Web API はそこでテストしてください。

最も粗が目立つのは Linux です。Wails の Linux ガイドには既知の問題が挙げられています。WebKitGTK のバグにより video の ended イベントが発火しないこと、「GStreamer element autoaudiosink not found」と表示される場合があること、そして「WebKit がインストールするシグナルハンドラーが Go の panic リカバリーの仕組みに干渉する」ことです（Wails の Linux ガイド、2026 年）。ABI の分裂もあります。Debian 11、Ubuntu 20.04、RHEL 8〜9 では旧来の WebKitGTK 4.0 が必要なため、ビルドタグ webkit2_41 と webkit2_40 のどちらかを選ぶことになります（Wails のディストリビューション対応、2026 年）。2026 年 2 月の v3 の issue では、Nvidia 環境の X11 でウィンドウが真っ白になる問題が報告されており、WEBKIT_DISABLE_DMABUF_RENDERER=1 で回避されています（Wails issue #4985、2026 年）。

ほかにも知っておくべきコストがあります。

• v2 はシングルウィンドウです。 v3 の移行ガイドによると、v2 は「アプリケーションごとに 1 つのウィンドウしかサポートしていなかった」のに対し、v3 は「コア機能としてネイティブのマルチウィンドウ対応を導入」しています（Wails v2 から v3 への移行ガイド、2026 年）。
• v3 はまだベータ版です。 最新は 2026 年 9 月 22 日の v3.0.0-beta.25 です。リリースノートには「API は安定しているが、3.0 の正式リリースまでは問題に遭遇する可能性がある」とあります（Wails のリリース、2026 年）。移行ガイドにも「v2 が引き続き現行の安定版である」と書かれています。
• エコシステムが小さめです。 プラグインは少なく、変わったバグに遭遇したとき、誰かがすでに解決策を書いてくれている可能性も低くなります。
• 移行ドキュメントが手薄です。 v3 のドキュメントにある「Electron から」のページは、現時点ではプレースホルダーです。

Tauri はどうなのか？

Tauri は、webview を使うもう 1 つの主要なフレームワークです。自らを「主要なデスクトップとモバイルのすべてのプラットフォーム向けに、小さく高速なバイナリを作るためのフレームワーク」と説明しており、「すべてのユーザーのシステムですでに利用できる web view」を使い、バックエンドは Rust です（Tauri、2026 年）。Tauri 2.0 は 2024 年 10 月 2 日に安定版になりました（Tauri ブログ、2024 年）。

Elanis のベンチマークでは、Tauri のビルドが最も小さく（約 3〜5 MB）、Linux でのメモリ使用量も最少でした。一方で、起動はすべての OS で最も遅く、Linux の CI ランナーでは約 30 秒かかりました。Tauri と Wails は webview に関して同じトレードオフを抱えているので、選択はほぼバックエンドの言語で決まります。チームが Rust を書くなら Tauri を、Go を書くなら Wails を使ってください。

Electron アプリを Wails に移行するには？

フロントエンドはそのままにして、メインプロセスを置き換えます。Wails にはまだ公式の Electron 移行ガイドがないので、Electron の各要素を Go の対応物に対応づけて作業を計画してください。

現実的な進め方は次のとおりです。

1. フロントエンドをそのまま移します。 Wails の参照先を、既存の Vite や webpack のビルド出力に向けます。ほとんどのコンポーネントは変更不要です。変更が必要なのは preload の API とやり取りしている呼び出し箇所だけで、それはステップ 2 で対応します。
2. IPC チャネルを 1 つずつ移植します。 ipcMain.handle はそれぞれ Go のメソッドになります。対応する preload のエントリを削除し、呼び出し箇所を生成された import に切り替えます。
3. プッシュ型のメッセージをイベントに置き換えます。 webContents.send で送っていたものは、すべて runtime.EventsEmit になります。
4. パッケージングを作り直します。 wails build は「本番環境向けのバイナリ」をコンパイルし、-nsis、-webview2、-platform などのフラグでインストーラー、WebView2 の配布方法、クロスターゲットを扱えます（Wails CLI、2026 年）。署名ガイドでは、GitHub Actions での実行も含め、macOS の公証と Windows の SignTool を解説しています。
5. 3 つの webview すべてでテストします。 このステップは Electron と比べて新たに発生する作業なので、時間を確保しておきましょう。

ステップ 2 で書く Go のコードは、ほとんどが標準ライブラリを使ったものです。os、net/http、encoding/json に慣れていないなら、HTTP コースとデータフォーマットのコースで、デスクトップのバックエンドで使う部分を学べます。

LevelUpGo の役割

上のログビューアは、関数、複数の戻り値、エラー処理、標準ライブラリといった Go の基礎に支えられています。LevelUpGo の Go Basics コースでは、すべてのレッスンの横に本物のエディタがあり、先に進むにはコードがテストに通る必要があります。FollowLog での goroutine と context の扱いは Concurrency Fundamentals で学べます。もっと手を動かして練習したいときは、Training Ground に単独の演習が用意されています。

Go に時間をかける価値があるかまだ迷っているなら、Go 言語は 2026 年に学ぶ価値があるか？から読んでみてください。Go がすでに本番環境でどこに使われているかは Go 言語はどこで使われている？ で、サーバーサイドについてはバックエンド開発におすすめのプログラミング言語で紹介しています。

よくある質問

Wails は Electron より優れているのか？

小規模から中規模のデスクトップアプリの多くでは、優れています。Elanis のベンチマークでは、空の Wails アプリは Electron アプリの 30〜40 分の 1 のサイズでした（Elanis のベンチマーク、2026 年）。さらに、型付きのバインディングを備えた Go のバックエンドが手に入ります。ただし、同一の Chromium レンダリングや Node のネイティブモジュールが必要な場合は、今でも Electron のほうが適しています。

Wails は Electron よりメモリ使用量が少ないのか？

OS によって異なります。同じベンチマークで、Wails のメモリ使用量は macOS では Electron の 369 MB に対して約 100 MB、Linux では 586 MB に対して 360 MB でした。Windows では逆に多く、278 MB に対して約 323 MB でした。WebView2 が Chromium ベースの Microsoft Edge のエンジンを使い、独自のブラウザプロセスを動かしていることが原因だと考えられます。

Wails は本番環境で使えるのか？

Wails v2 が安定版で、2026 年 8 月 10 日に v2.14.0 がリリースされています（Wails のリリース、2026 年）。Tiny RDM のようなアプリが v2 の上で動いています。Wails v3 はベータ版です。ドキュメントには、v3 を使ったアプリケーションがすでに本番環境で動いているとある一方、デプロイ前に十分にテストするよう勧めています。

Wails アプリは Windows 10 で動くのか？

はい、WebView2 Runtime がインストールされていれば動きます。Microsoft によると、Windows 10 デバイスの大多数にはすでにインストールされています（Microsoft Learn、2026 年）。残りの環境向けには、-webview2 ビルドフラグを使って、Wails にブートストラッパーを埋め込ませるか、インストール時にランタイムをダウンロードさせることができます。

Wails に移行しても React のフロントエンドはそのまま使えるのか？

はい。Wails は Go のバイナリに埋め込まれたファイルから、ビルド済みのあらゆる Web フロントエンドを配信します。そのため React、Vue、Svelte、素の HTML のいずれも動きます。変わるのは、フロントエンドがバックエンドとやり取りする方法です。IPC 呼び出しは生成された関数の import になり、プッシュされるメッセージはランタイムのイベントになります。

出典

• Elanis, web-to-desktop-framework-comparison (updated 2026-09-04)
• Wails, Introduction
• Wails on GitHub
• Wails, How does it work?
• Wails v2.14.0 release
• Wails v3.0.0-beta.25 release
• Wails v3, Migrating from v2
• Wails v3, Binding methods
• Wails CLI reference
• Wails signing guide
• Wails Windows guide
• Wails Linux guide
• Wails Linux distro support
• Wails issue #4985, blank window on Linux X11 with Nvidia
• Wails showcase
• Tiny RDM
• Microsoft Learn, Distribute your app and the WebView2 Runtime
• Electron docs
• Electron, Process model
• Electron, Release timelines
• Electron release schedule
• Electron, Security checklist
• Electron apps showcase
• Tauri, Start
• Tauri 2.0 announcement (2024)