TauriTavern：SillyTavern を Rust バックエンドでネイティブアプリ化した移植版をどう評価するか

SillyTavern の「Node.js を入れてもらう」問題を消しにいった移植

SillyTavern 本体は Node.js 上で動くサーバーで、利用者はまずランタイムを用意し、コマンドラインから起動する必要がある。TauriTavern が解こうとしているのはこの導入障壁そのものだ。README は「不需要安装 Node.js，不需要命令行，安装即用」と述べており、対象は自分でランタイムを管理したくないデスクトップおよびモバイルの利用者になる。

注目点は、UI を書き直していないことだ。フロントエンドは上流 SillyTavern を同期 1.18.0 の状態で保ち、データ形式とディレクトリ配置も互換とされる。つまり利用者から見た操作感は本家のままで、置き換わるのはプロセスを動かす側だけ、という設計になっている。キャラクターカードやチャット履歴、プリセット、ワールドブックをそのまま持ち込めるという主張は、この方針の帰結として読める。

ただし README 自身が「TauriTavern は独立维护的开源项目，并非 SillyTavern 官方客户端」と明記している。互換性は移植元の資産に対するもので、上流プロジェクトの公式サポートがあるわけではない。互換を前提に運用を組むなら、この区別は最初に押さえておきたい。

Rust 側は Clean Architecture の Cargo workspace に分かれている

リポジトリの構成として README が示すのは、`src-tauri/crates/` 配下の Cargo workspace だ。役割は次のように列挙されている。`tauritavern` が Tauri host、コマンド層、コンポジションルート。`tt-application`、`tt-ports`、`tt-domain`、`tt-contracts` がユースケース、ポート、ドメインモデル、crate 間の契約。`tt-adapter-*` がストレージ、HTTP、メディア、同期、拡張、トークン化などの実装。

ここから読み取れるのは、Tauri のコマンドハンドラに処理を直接書き込むのではなく、ポートとアダプタで外部依存を切り離す方針を取っていることだ。同期や拡張のように差し替えが想定される領域が個別のアダプタ crate に分かれている点は、後から対象を増やす前提の分割に見える。

フロントエンド側は上流 SillyTavern に「模块化 Tauri 注入层（`src/tauri/main/`）」を足した構造で、`window.__TAURITAVERN__` というプラットフォーム ABI を通じて Rust 側と通信する。既存の Web 資産を保ったままネイティブ機能を生やすには素直な筋だが、ABI の境界がそのまま互換性の責任範囲になる。上流を追従してフロントを取り込むたび、この注入層の追随コストが発生する構造だ。詳細は `docs/BackendStructure.md` と `docs/FrontendGuide.md` に分けて書かれている。

導入経路はパッケージマネージャ経由まで用意されている

配布は公式サイトのダウンロードページと GitHub Releases が入口で、加えて各 OS のパッケージマネージャ向けの手順が README に列挙されている。Windows は Scoop で `scoop bucket add Darkatse https://github.com/Darkatse/Scoop-Darkatse.git` の後に `scoop install Darkatse/TauriTavern`。macOS は `brew install --cask tauritavern`。Arch Linux は AUR の `tauritavern-bin` を AUR ヘルパーで入れる。

Debian、Ubuntu、Fedora、openSUSE、NixOS 向けにはスクリプトが用意されている。`curl -fsSL https://raw.githubusercontent.com/Darkatse/TauriTavern/main/scripts/install-linux.sh | sh` を実行すると、システムを判定して適切な方式を選ぶとされる。Nix 利用者は `nix profile add github:Darkatse/TauriTavern#tauritavern`、Flatpak は `flatpak remote-add --user --if-not-exists tauritavern https://flatpak.tauritavern.com/tauritavern.flatpakrepo` の後に `flatpak install --user tauritavern com.tauritavern.client` という手順が示されている。

チャンネルは安定版と Canary の二本立てで、Canary は毎日更新される代わりに安定性が劣る可能性があると README が断っている。Linux で Canary を使う場合はインストールスクリプトに `--channel canary` を渡すか、Nix なら `github:Darkatse/TauriTavern/Canary#canary` を指定する。Windows のポータブル版は WebView2 ランタイムが別途必要で、iOS は TestFlight 経由、iOS 16 以上という条件が付く。TestFlight 版には Apple 側の規則による利用制限があることも明記されている。

Node-only バックエンドプラグインは動かないという線引き

README の機能一覧には「内置原生 Git」による拡張のインストール、更新、ブランチ切り替えが挙げられている。一方で同じ行に「不支持上游 Node-only 后端插件」と書かれている。これがこの移植版の最も実務的な制約だ。

SillyTavern の拡張には、フロントエンドだけで完結するものと、Node 側のプロセスで動くことを前提とするものがある。TauriTavern はバックエンドを Rust に置き換えている以上、後者は原理的に動かない。UI 上の拡張管理機能があっても、それはフロントエンド拡張の話であって、Node 前提のプラグインを救うものではない。

自分の運用がどのプラグインに依存しているかを先に棚卸しする必要がある。フロントエンド拡張だけで足りているなら移行の障害は小さい。逆にバックエンド側の処理を前提にした拡張を常用しているなら、TauriTavern は本家の代替にならない。ここは性能や安定性の問題ではなく、アーキテクチャ上の非対応として扱うべき線引きだ。

同期と Agent フレームワークは本体に抱え込む方針

機能一覧には、LAN 内の暗号化ペアリングによる同期、または遠端の TT-Sync v2 経由の自動アップロードが挙げられている。データはローカルに保存され、ポータブルモードも選べる。同期を外部サービスに委ねずアプリの機能として持つ設計は、データの置き場所を自分で決めたい利用者には噛み合う。

もう一つ、Agent フレームワークとしてツール呼び出し、Skills、サブエージェント、実行タイムラインが挙げられているが、README はこれを「持续演进中」と表現している。完成した仕様として提示されているわけではないので、これから導入する側は、この領域が動いている前提で接するのが妥当だ。

性能面では分階段起動とチャットの仮想 DOM 読み込みが挙げられ、長いチャットログでも動作するとされている。ただし README に数値はなく、条件も書かれていない。この主張は設計意図の説明として読み、実測は自分の環境で行うべき性質のものだ。

自分でビルドする場合の前提と、Tauri Pilot という開発補助

ソースから動かす場合、README が挙げる前提は Rust stable（edition 2024 対応）、Node.js 20.19.x または 22.12 以降、pnpm、Tauri CLI だ。手順は `git clone https://github.com/Darkatse/TauriTavern.git`、`cd TauriTavern`、`pnpm install`。

コマンドは目的別に分かれている。`pnpm run check` はフロントエンドの guardrails、型、契約の検査に Rust の dev check を足したもの。`pnpm run web:build` は Rspack でフロント資産をビルドする。`pnpm run tauri:dev` と `pnpm run tauri:build` がデスクトップの開発と配布物作成、`pnpm run android:dev` と `pnpm run ios:dev` がモバイルになる。

開発補助として Tauri Pilot が組み込まれている。`cargo install tauri-pilot-cli` を一度実行し、`pnpm run tauri:dev:pilot` で起動すると、AI Agent がアクセシビリティスナップショット経由でデスクトップの WebView を検査、操作できる。`tauri-pilot ping`、`tauri-pilot snapshot -i`、`tauri-pilot click @e3` といった流れが README に例示されている。通常の開発コマンドとリリースビルドではこの権限は有効にならないとされている点は、配布物にデバッグ用の口が残らないという意味で押さえておきたい。

上流 SillyTavern との違いは「置き換えた層」に集約される

比較対象は当然ながら本家 SillyTavern になる。両者の違いは UI ではなく、その下で何が動いているかだ。本家は Node.js ランタイムを前提とし、バックエンド側の拡張もその上で動く。TauriTavern は同じフロントエンドを保ちつつ、バックエンドを Rust の Cargo workspace に置き換え、配布形態も OS ごとのネイティブパッケージにしている。

この違いが効くのは導入と配布の場面だ。Node.js のインストールを利用者に求めずに済み、Windows、macOS、Linux、Android、iOS に同じ体験を配れる。効かないのはバックエンド拡張の場面で、前述のとおり Node-only プラグインは対象外になる。

もう一つの違いがライセンスだ。TauriTavern は AGPL-3.0 で、README も「请在使用前仔细阅读许可条款」と促している。本家のライセンス条件とは別物なので、社内配布や改変を伴う利用を想定している場合は、どちらの条件が自分の用途に掛かるかを先に確認する必要がある。ここでは法的助言はできない。条文そのものを読むべき領域だ。

保守の観点では、フロントエンドが上流 1.18.0 に同期されている以上、上流が動けば注入層 `src/tauri/main/` と `window.__TAURITAVERN__` ABI の追随が必要になる。Canary が毎日更新されているのは、この追随を継続的に回している運用の現れと読める。逆に言えば、上流の変化に追従し続ける前提のプロジェクトであり、凍結された安定版として扱うものではない。

どの拡張に依存しているかを先に確かめる

導入判断で最初に潰すべきは、拡張の依存関係だ。フロントエンド拡張だけで運用が成り立つなら、TauriTavern は本家の代替として成立する。Node-only バックエンドプラグインが運用の中核なら、この移植版では再現されないので、乗り換えではなく併用か見送りになる。

次に移行経路。README は SillyTavern のデータを書き出すスクリプトとアプリ内インポートを「一键迁移」として挙げている。ただし手順の詳細は README には書かれておらず、ドキュメント側に委ねられている。実際に移す前に、書き出したデータのディレクトリ構造がアプリ側の期待と一致するかを確認しておきたい。互換をうたっていても、確認せずに本番のチャットログを動かすのは避けるべきだ。

三つ目はライセンス。AGPL-3.0 の下で、改変したものを配布する予定があるかどうかで条件が変わる。個人利用の範囲なら論点は小さいが、組織で配るなら条文の確認が先になる。

最後に、Canary を試すかどうか。安定版で問題が出たときに Canary で既に直っているかを確かめる、という使い方が README には示されている。常用するチャンネルではなく、切り分けの手段として位置づけるのが素直な読み方だ。

編集部の結論

すでに SillyTavern のデータ資産（キャラクターカード、チャットログ、プリセット、ワールドブック）を持ち、Node.js のセットアップを配布先の端末に求めたくない場合、TauriTavern は検討対象になる。逆に、上流の Node バックエンドに依存するプラグインを運用の中核に置いている場合、この移植版はその部分を再現しないため、乗り換えではなく併用か見送りが妥当になる。導入前に確認すべきは、自分の拡張がフロントエンド拡張と Node-only バックエンドプラグインのどちらに属するか、そして本家のデータディレクトリを移行スクリプトで書き出したうえでアプリ内インポートが通るかどうか。AGPL-3.0 のため、改変して配布する予定があるならソース開示の条件を先に読んでおく必要がある。

公式情報源

1. Darkatse/TauriTavern on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases