zudo-paper

Tauriでドキュメントビューアを作った感想

Author: Takazudo | 作成: 2026/03/19

概要

最近Electronをいじっていたが、Tauriのほうが良いのではという話を聞いて、実際にTauriでドキュメントビューアを作ってみた。その感想。

以前Claude Codeと相談して「ElectronのほうがTauriより良さそう」という結論を書いた記事がある。

ただ、Claude Codeが全部やってくれるなら、メモリ消費が少ないほうを選んでも良い。DiscordやSlackのようなリッチなアプリであれば、OS間の細かい差異が問題になるだろうが、ドキュメントビューアならほぼ何もしない。しかも自分はMacしか使わない。ということで、Tauriを試してみることにした。

作ったのはClaude Code Resourceビューア。最近作っているzudo-docをベースにしていて、~/.claude/doc/にあるClaude Codeのリソースを閲覧するためのアプリ。

Tauriを使ってみたが

最初のTauri移行トライとしては、正直かなり厳しい開発体験だった。Claude Codeにコードを書かせても、「できた」と言うが動かない。この繰り返し。端的にいうと、Electronのほうがずっと楽だった。

例えば、Tauriの初期準備ステップをフロントエンドで検知する必要があるらしく、Claude CodeはカスタムメイドのAPIをフロントエンドからポーリングして検知しようとしていた。詳細はよくわからないが、Tauriの準備完了を何らかの方法で捕捉しなければならないようだった。

以下はその過程のスクリーンショット。check_readyというAPIをフロントエンドからひたすらポーリングしている。

check_readyのポーリングが延々と続いている

サーバーに接続できず真っ白な画面、というのもよくある状態だった。

サーバー接続失敗で真っ白な画面

Claude Codeが数時間トライ・アンド・エラーを繰り返したが、うまくいかなかった。その後、Webリサーチをさせたところ、Tauri公式ドキュメントに紹介されている正しい方法を見つけてきた。

これはつまり、LLM側にこのニッチな領域の開発知識が十分に蓄積されていないということ。自分たちでキュレーションしていく必要がある。

Tauri開発で気づいたこと

この開発で一番の気づきは、Electronが裏側で多くのことを自動的にやってくれているということだった。

例えば、ViteでReactアプリのようなSPAを動かすとする。少なくともNode.jsが必要になる。TauriからNode.jsプロセスを起動すること自体は可能だが、ローカルにインストールされたNode.jsのバージョン、pnpmのようなパッケージマネージャー、場合によってはHomebrewでインストールしたユーティリティなどに依存することになる。

brewでインストールしたものはこの開発とは切り離すべきだが、Node.jsアプリに関するそれ以外のもの全てがTauriには含まれていない。一方、Electronには含まれている。だから、この自分専用の小さなアプリであっても、別のMacBookでは動かない可能性がある。ElectronにはWebKitとNode.jsが同梱されているので、そのあたりを気にする必要がない。

また、このアプリは現状Mac専用。Windowsでは使わないが、Claude CodeにWindows対応に何が必要か聞いてみた。回答としては、プロセスハンドリングがMacのユーティリティに依存しているとのことだった。ファイル監視、プロセスのkill、プロセスの起動……これらが全てOS間で完全に異なる。全てに分岐処理を書く必要がある。

これがElectronを使っていたときに見えていなかった部分。Electronを使う場合、ほぼ全てをNode.js経由でやる。開発者のマインドセットは「OK、Nodeでできることをやろう」になる。つまり、アプリケーション開発においてこの部分を自分は理解していなかったということになる。

テストが難しい

最終的に一番難しかったのはテストだった。Next.jsなどNode.jsベースのものを作る場合、「いつものやつ」的な開発ユーティリティのセットがある。しかし今回のケースではそれがない。

理由の一つとして、自分はフロントエンド開発者だが、ここはNode.jsアプリとネイティブOSのプロセスハンドリングのブリッジ部分であること。この領域はテストしにくい。

一般的なテスト方針としては、Node.jsアプリ自体をできるだけそれ単体で完結するように開発すべき。これを正しくやらないと、エラーの上にエラーが重なって、どのレイヤーが問題なのかほとんど判別不能な状態に深く落ちていく。落とし穴のようなもの。

今回については、自分でテストコードを書いたわけではないが、Claude Codeにアプリ終了後にプロセスがちゃんとkillされているかを確認するテストや、起動時に画面が表示されたかを検証するテストを書かせて、デバッグを繰り返させた。

まとめ

結果として、アプリのビルド経験を一つ積んだので、Tauriに対して少し距離が近くなった。個人プロジェクトで使っていこうかなという気持ちはある。

ただ、この種のアプリ開発、特にリッチなUIベースのアプリを考えた場合、Electronが1stクラスの技術選択であることは間違いない。少なくとも、この種のアプリ開発の入門者にとっては。AI搭載の開発環境がある今でも、Tauriのような環境ではOSの差異やブラウザの差異に苦しめられることは確実。フロントエンド開発者としては、Safariは嫌われる側のブラウザなわけで。

関連リソース

今回の開発で得た技術的なTipsは別の記事にまとめてある。Node.jsバイナリのバンドル、SSEライブリロード、ポート占有対策など、具体的なコードと解説はそちらを参照。

作成したTauriアプリや関連スクリプトはclaude-resourcesリポジトリで公開している。

また、この開発の後にClaude Code用のスキルとして知見をまとめた。今後同じようなTauriアプリを作るときに、Claude Codeがこのスキルを参照することで同じ問題に引っかかりにくくなるはず。

オマケ: Q&A

開発中にClaude Codeに聞いた質問をまとめておく。以下はボツにした記事から持ってきたもので、Claude Codeとの会話ログそのもの。フロントエンドの人間がTauriを初めて触るときに気になるであろうことが含まれている。

アプリを起動するたびにcargo tauri devを実行する必要がある?

いいえ。cargo tauri buildで一度.appバンドルをビルドすれば、/Applications/にコピーしてダブルクリックで起動できる。ビルドの流れはこう。

cd app && cargo tauri build
cp -r target/release/bundle/macos/Claude\ Resources.app /Applications/

TauriはアプリのなかにNode.jsを含んでいるの?

いいえ。TauriはNode.jsをバンドルしない。Rustバイナリが/bin/zsh -l -c "pnpm dev:stable"を呼び出して、ホストマシンにインストールされているpnpm/Node.jsを使う。つまり、このアプリを動かすにはNode.jsがマシンにインストールされている必要がある。

配布用のスタンドアロンアプリにするなら、Tauriの「sidecar」機能でNode.jsバイナリをバンドルする必要があるが、そうするとTauriの軽量さという利点がなくなる。

TauriにDevToolsはある?

ある。Cmd+Option+Iで切り替えられる。Cargo.tomlfeatures = ["devtools"]を有効にしているため、リリースビルドでも使える。

起動時に何が起きるのか、具体的には?

Rustがサイドカープロセスを起動 → dev-stable.jsがHTTPサーバーを即座に起動(ビルド中はローディングページを配信) → Astroサイトをビルド → ビルド完了後にdist/をアトミックにスワップ → TauriウィンドウのローディングページがIPC経由でRustに「準備完了?」とポーリング → 200が返ったらRustのwindow.navigate()でドキュメントページに遷移。

このアプリはWindowsの.exeも作れる?

Tauriは仕組み上Windowsビルドをサポートしているが、このアプリはWindowsでは動かない。理由は以下。

  • /bin/zshをハードコード(Unixシェル)
  • Unixシグナル(SIGTERM)とprocess_groupを使用
  • ~/.claude/doc/パスはmacOS固有
  • シェルPATH経由でpnpm/nodeが利用可能であることを前提

これは個人用のmacOS開発ツールとして設計されている。クロスプラットフォーム対応には大幅な書き換えが必要。

そもそもTauriとElectronの違いは?

  • Tauri: 5-10MB程度。OSのWebKit(macOS)を使用。Rustバックエンド。軽量だがプラットフォーム差異は自分で対処する。Node.jsをバンドルしない
  • Electron: 150MB程度。Chromium + Node.jsをバンドル。重いがどこでも同じ動作

個人開発ツール(ホストにNode.jsがある前提)ならTauri、配布アプリならElectronが向いている。

クロスプラットフォーム対応は自分でやる必要がある?それがElectronとの違い?

その通り。Tauriは軽量なネイティブシェルを提供するが、プラットフォーム差異はすべて自分で処理する。Electronはバッテリー込み(Chromium + Node.jsを同梱)なので、どこでも同じ動作が保証される。Tauriのトレードオフは「ハッピーパスは軽量、エッジケースは手動作業」ということになる。

スタンドアロンアプリとして配布するなら、Node.jsバイナリをアプリに含める必要がある?

そう。Tauriには外部バイナリをバンドルする「sidecar」機能がある。Node.jsバイナリ + node_modules + ドキュメントソースをバンドルすることになる。ただ、そうすると軽量という利点がなくなり、「追加の手間がかかるElectron」のような状態になる。個人開発ツールならホストのNode.jsに依存するのが正解だろう。