Tauri 2の選び方 - Capabilities、モバイル対応、IPCの安全設計

中級 | 8分 で読める | 2026.04.23

公式ドキュメント
Rust

Tauri 2は、HTML・CSS・JavaScriptで作るfrontendとRustのapplication coreを組み合わせ、Windows、macOS、Linux、Android、iOS向けapplicationを構築するframeworkです。各OSのWebViewを利用し、frontendからRust commandやplugin APIを呼び出します。

先に結論

記事情報: 2026年4月23日初出。Tauri 2公式documentを2026年7月25日に再確認しています。

TauriをElectronの「常に小さく速い代替」とだけ考えると、重要なtradeoffを見落とします。TauriはChromiumとNode.jsをapplicationごとに同梱せずsystem WebViewを使うため、package構成を小さくできる可能性があります。一方で、OSごとにWebView engine・versionが異なり、browser互換性のtestが必要です。

選定で重要なのは次の4点です。

  • frontendから呼べるnative機能を最小権限にできるか
  • Rust側で入力検証とerror handlingを設計できるか
  • desktopとmobileで必要plugin・APIが対応するか
  • 各OSのWebViewと配布・署名をtestできるか

条件不明のbundle sizeやmemory削減率ではなく、自分のapplicationを各targetでbuildして測定します。

Tauri applicationの構造

frontendはWebView内で動き、Rust codeとはIPC（process間通信）を通じてやり取りします。Rust functionへ#[tauri::command]を付け、builderへ登録するとfrontendから呼べます。

TauriのWebView内FrontendがIPCとCapability・Permissionを通してCore・Application・Plugin Commandを呼び、入力検証をしてNative機能への範囲を絞る図

#[tauri::command]
fn greet(name: String) -> Result<String, String> {
    let trimmed = name.trim();

    if trimmed.is_empty() {
        return Err("name is required".into());
    }

    Ok(format!("Hello, {trimmed}!"))
}

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("failed to run application");
}

import { invoke } from "@tauri-apps/api/core";

const message = await invoke<string>("greet", {
  name: "Ada",
});

TypeScriptのgenericはclient側の期待する型を表すだけで、Rustのreturn値をruntimeで検証するものではありません。commandのargumentはuntrusted inputとしてRust側で検証します。

file path、shell argument、SQL、URLを受け取るcommandでは、許可範囲をallowlist化します。frontendにXSSが起きた場合でも被害を限定できるよう、任意command実行のような広いAPIを作らないことが重要です。

CapabilityとPermission

Tauri 2のcapabilityは、どのwindow・webviewが、どのcore commandやplugin commandを呼べるかをまとめる設定です。capability fileは通常src-tauri/capabilitiesに置きます。

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "main-window",
  "description": "Permissions for the main window",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "dialog:allow-open"
  ]
}

dialog:allow-openのようなpermissionを追加して初めて、対象windowからplugin commandを呼べます。pluginのdefault permission setが何を含むかはpluginごとに異なるため、名前だけで安全と判断せずgenerated schemaと公式permission一覧を確認します。

Capability設計の原則

  • window名を"*"にせず、必要なwindowへ限定する
  • plugin全体ではなく必要なcommandだけ許可する
  • file system scopeは対象directoryへ絞る
  • shell pluginではprogramとargumentを限定する
  • remote URLへ権限を与えないことを基本にする
  • development用permissionをproductionへ残さない

Capabilityはfrontend codeが信用できるという宣言ではなく、侵害時の影響範囲を縮める境界です。Content Security Policy、依存関係更新、入力validation、OS sandbox・署名も別に必要です。

モバイル対応

Tauri 2はAndroidとiOSをtargetに含み、同じfrontendとRust coreを共有できます。ただし、desktop projectをcommand 1つで完全に同じmobile appへ変換できるわけではありません。

mobile開発にはAndroid Studio・SDK・NDK、またはmacOS上のXcodeなどplatform toolchainが必要です。permission prompt、background execution、deep link、notification、file picker、store signingはOSごとに扱いが異なります。

公式pluginにも対応platformの違いがあります。利用予定のpluginについて次を確認してください。

  1. Android・iOSがsupport対象か
  2. platform別の初期設定が必要か
  3. OS manifestやentitlementに何を追加するか
  4. runtime permissionをいつrequestするか
  5. application storeのreview policyに適合するか

画面もdesktop幅を縮めるだけでは不十分です。touch target、safe area、keyboard、back navigation、orientation、offline、suspend/resumeをmobile実機でtestします。

Pluginの役割

Tauri 2はfile system、dialog、shell、notification、storeなどの機能をpluginへ分けています。Rust crateとJavaScript packageの両方を追加し、必要なpermissionをcapabilityへ加えるのが基本です。

npm run tauri add dialog

pluginを導入しただけではfrontendからすべての操作が許可されるわけではありません。Capabilityに必要permissionを追加し、対象platformの設定を行います。

第三者pluginでは、Tauri 2への対応、mobile support、Rust dependency、保守状況を確認します。native codeを含むpluginはapplicationの権限内で動くため、通常のfrontend package以上に慎重なreviewが必要です。

System WebViewのtradeoff

TauriはOSのWebViewを使います。一般にWindowsはWebView2、macOS・iOSはWKWebView、LinuxはWebKitGTK、Androidはsystem WebViewが基盤になります。

この構成はbrowser engineを丸ごと同梱しない利点がある一方、次の差が出ます。

  • CSS・Web APIの対応version
  • media codecとfont rendering
  • cookie・storage・proxy
  • accessibility behavior
  • WebView update policy
  • Linux distributionごとのlibrary

Chrome 1種類での確認では不十分です。最低support OSとWebView versionを決め、各platformのCI buildと実機testを用意します。高度なbrowser extension APIやNode.js APIをfrontendで直接使っていたElectron applicationは、そのまま移せません。

Sidecarと外部process

既存のCLIやlanguage runtimeをsidecar binaryとして同梱する構成も可能です。ただしtarget OS・CPUごとのbinaryを用意し、署名、update、標準入出力、終了処理を管理します。

user inputをshell command文字列へ連結しないでください。許可するprogramとargumentを明示し、capabilityのshell scopeも限定します。sidecarを使うほどpackage sizeとattack surfaceは増えるため、Rust commandとして実装する場合との比較が必要です。

Web applicationから移す手順

既存Web frontendをTauriへ入れる前に、server依存とbrowser依存を分類します。

  1. static buildできるfrontend部分を確認する
  2. server-only APIをRust commandまたはremote APIへ分ける
  3. 必要なnative操作を一覧化する
  4. commandとpluginごとにminimum permissionを定義する
  5. desktopの各OSでWebView互換性を確認する
  6. mobile targetがあるならplugin対応と実機UIを別に確認する
  7. installer、code signing、update、rollbackをtestする

frontend dev serverを読むdevelopment設定と、bundled assetだけを読むproduction設定を混同しないようにします。remote contentを表示するwindowへnative権限を与える設計は避けます。

採用判断

Tauri 2は、Web技術でUIを作りつつ、必要なnative機能をRust commandとpermissionで限定したいapplicationに向きます。既存frontend資産を共有できる可能性がありますが、Rust、platform toolchain、signing、WebView差異を運用するcostは残ります。

Electronからの移行では、bundle sizeだけでなく、Node.js API、native addon、auto update、crash report、accessibility、enterprise配布を比較します。mobile対応も「同じcodebase」という利点と「platformごとの仕上げ」を分けて評価してください。

参考リソース

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR