作って分かったTauri v2の真価

Tauri v2はElectronの軽量版ではない

実際に使ってみて作ってみて一番大きな気づきはこれだった。

Tauri v2は「軽量なElectron」ではなく、

> **OS操作をRustに集約するためのアプリ基盤フレームワーク**

であること。

1. フロントエンドは消耗品

SvelteでもReactでもいいが、フロントエンドは長期的に必ず変わる。

このため設計の軸は下記の通り：

text id="ui1"
UI → Rust（本体）

UI側にロジックを持たせると、構造的に長期運用で崩れる。
これはMFC/C++とは明確に違うポイント。

2. C++を使う場合の構造（重要）

Tauri v2ではC++を使うこと自体は可能だが、
必ずRustを経由する形にする必要がある。

mermaid
flowchart LR
UI[Svelte / Frontend] --> R[Rust Core]
R --> P[Tauri Plugin
OS機能]
R --> F[FFI Wrapper Layer]
F --> C[C++ Engine]
P --> OS[OS API]

この構造の意味

* UIはRustにしかアクセスしない
* C++はRustの内部からのみ呼ばれる
* OS操作とC++は直接つなげてはいけない
* Rustは「境界のハブ」である

3. OS操作をC++や各所に散らすと設計が壊れる

例えばWindowsには ShellExecute のようなAPIがある。

cpp id="winapi1"
ShellExecute(NULL, "open", "file.txt", NULL, NULL, SW_SHOW);

これはファイルを開いたりアプリを起動するためのOS機能だが、
これをC++の中に直接書いていくと問題が出る。

* OS操作がRust以外の場所に散らばる
* 言語が違うのでどこで何をしているか追えない
* テストや差し替えが難しくなる

つまり問題はAPIそのものではなく、

> OS境界が分散すること

書けるし、動くが、正しくない。

なぜ“正しくないように見えない”のか

この構造は小規模では問題が顕在化しない。

* その場では動く
* 実装が速い
* 違和感が出ない

だから設計としての欠陥が後からしか見えない。

この問題はバグではなく構造の問題で、

> 「動くコード」と「保守できるコード」は別物

4. Tauri v2はそこを逆転している

Tauri v2ではOS操作をすべてここに集約する：

text id="arch2"
UI → Rust → Tauri plugin（OS操作）

* file
* dialog
* shell
* notification

すべてRust側に統一される

5. C++の立ち位置は「計算エンジン」

C++はOSを触る層ではなく、純粋な計算処理に限定するのが適切。

* 数値計算
* 画像処理
* アルゴリズム

text id="cpp1"
Rust → C++（計算専用）

ここにOSやアプリ制御を混ぜると、再び境界が壊れる。

結論

Tauri v2の真価はこうだった：

> **Electronの軽量版ではなく、「OS操作の境界を設計し直したアプリ基盤」**

まとめ

* UIは必ず変わる前提で設計する
* OS操作は分散させずRustに集約する
* C++は計算専用に閉じる
* それによって構造が初めて安定する