Claudeデスクトップアプリを用途ごとに分ける。

「壊さない」ことを最優先にした Rust と Tauri

CSW がいちばん大事にしているのは、いま使っている Claude のデータを壊さないことです。アカウントを切り替えるたびに設定ファイルを入れ替えるので、途中で失敗すれば、会話履歴やアカウントのサインイン情報が消えかねません。そこで、壊すと困る処理は一カ所に集めました。具体的には、環境ごとにデータを分ける、ファイルの置き場所を判断する、いま使っているデータを守る、といった処理です。これらをすべて Rust で書いた共通の部品（crates/core）にまとめ、ターミナルから使う版（csw）も、デスクトップアプリ（crates/desktop）も、この同じ部品を呼び出すだけにしています。危ない処理が一カ所にまとまっていれば、見直す場所もそこだけで済みます。

消す操作では、いま使っているデータの場所だけは、消す対象から必ず外します。共有する設定ファイルを切り替えるときも、元のファイルを一度別の場所へ退避してから、新しいものに差し替えます。Rust を選んだ理由は、こうした守るべき約束を、プログラムを動かす前の準備段階で機械に自動チェックさせられるからです。約束を破るコードを書くと、この段階でエラーになって止まり、配布物を作る工程まで進めません。つまり、決めた約束に反する書き間違いは、世に出る前にはじけます。これをテストと組み合わせて、安全側に倒しています。

GUI は Tauri v2 です。macOS にもともと入っている表示の仕組みである WebKit を借りるので、アプリの中にブラウザの仕組みをまるごと同梱しなくて済みます。そのぶん配布ファイルが小さく、Intel と Apple Silicon の両対応版でも、DMG は約 7MB に収まっています。Apple にアプリの身元を確認してもらう手続きである、コードの署名と公証も、Tauri の標準的な配布の流れで行えます。

macOS のネイティブ UI なら、本来は Apple の Swift と SwiftUI が第一候補です。ただ CSW は、見た目よりも、裏でファイルや設定を安全に入れ替える処理こそが中心で、画面の量は多くありません。だから、その中身の処理が正しいかをコンパイラやテストで確かめやすいことを優先して、Rust と Tauri にしました。作るものが変われば、ふさわしい選択も変わります。

AI エージェントによる自律的な開発との相性

CSW の開発では、複数の AI エージェントを同時に動かし、調査・実装・検証を手分けして進めています。たとえば、あるエージェントが書いたコードを、別のエージェントが「ここは間違っていないか」と批判的に見直します。

このとき、人の好みで言い合っても結論は出ません。そこで判断のよりどころにしているのが、コンパイラの型チェック、書き方の問題を指摘する clippy の警告、テストを走らせる cargo test の合否です。どれも人によって解釈が割れず、通ったか落ちたかが機械の側ではっきり決まります。だから、エージェント同士が議論するときの共通の物差しになります。

Rust は型があり、コンパイルしてから動かす言語です。書いた変更の合否が、早い段階で、しかも細かく返ってきます。この速くて細かい反応が、エージェントが自分で直してまた確かめる、というやり方とよく噛み合います。これは他の言語を否定する話ではありません。人の好みではなく、機械がはっきり合否を出せるものを開発の中心に据えたいから、Rust を選んだということです。

ただし、コンパイルやテストが通っても、それは書いたとおりに動くことの確認にすぎません。そもそも作りたかったものと一致しているかまでは、確かめてくれません。たとえば、ボタンは正しく動くのに、置く場所を間違えている、といったズレは見つけられません。だから、画面を実際に描画して目で確かめる検証や、アプリとドキュメントの食い違いを両方向から突き合わせる監査も、別の関門として併用しています。

デザインと文章の基準を「スキル」として残す

このサイトやアプリの見た目と文章は、思いつきで決めず、リポジトリの中に文章で残した「スキル」と呼ぶ基準に沿って作っています。基準は CLAUDE.md という大もとのファイルを起点に、話題ごとのスキルファイルへ枝分かれしてまとまっているので、誰が、あるいはどの AI が作業しても、同じ基準に立ち戻れます。

たとえば日本語の文字組みは japanese-typography-qa というスキルにまとめています。これを当てる前のトップ見出しは、3 行に割れて最後の行に文字が 1〜2 字だけ残り、フォントも大きすぎて、下のセクション見出しのほうが大きく見える、という崩れ方をしていました。スキルにある規則、つまり意味の切れ目で改行することと、ページ全体の文字サイズを一つの比率でそろえることを当てて、いまの収まりに直しました。

見た目全体は design-taste-frontend や minimalist-ui といったスキルで判断します。たとえばこのコラムも、最初は 3 つの話題を一つずつ枠で囲んでいましたが、枠が増えるほど画面がうるさくなり、どこを読めばよいか目が迷います。そこでスキルにある「むやみに枠で囲まない」「本文の幅は目が一行を追える範囲に抑える」という指針に従い、枠をやめて上の細い線だけで区切りました。いま読んでいるこの文章も、視線が素直に流れる幅に収めています。

文章とアプリのズレは /audit-consistency という監査で見つけます。これはアプリの画面と、ドキュメントやこの LP の記述を、両方向から突き合わせる仕組みです。たとえば以前、LP には「複数の環境を同時に使える」と書いてあったのに、アプリは設定の衝突を防ぐため、複数の Claude を同時には開けない作りになっていました。説明と実際の動きが食い違っていたので、いったんどちらも「一度に1つずつ」にそろえました。その後、何も共有しない「すべて分ける」環境なら安全に並べられると整理でき、完全分離の環境に限って同時に開けるようにして、説明も実装に合わせています。

こうしたスキルは、なぜそう作るのかを文章で書き留めておくための仕組みです。別の人や別の AI が後から手を入れても、同じやり方に立ち戻れます。ただし、品質をひとりでに上げてくれる魔法ではありません。基準を決めて、そこに沿い続けるための土台です。