設計職がGemini・Claude・Claude Codeを使い分けて、写真ファイラーをリリースした話
はじめに — 設計職とソフトウェア開発の意外な相性
本業は設備系の設計職だ。AutoCADを使い、図面を引き、仕様を決める仕事である。
なのでプログラミングは専門外だった。いや、正確には「専門外だと思っていた」んだよね。
転機はある日、自分の写真ワークフローへの不満が限界に達したことだった。RAWファイルを管理したい。評価値をつけたい。でも既存のアプリは重すぎる、余計な機能が多すぎる、あるいは高すぎる。サブスクもかさばる。「こういうアプリが欲しい」という解像度が上がるほど、「なければ作ればいい」に気持ちが傾いていった。
設計職の思考は、意外なほどソフトウェア開発に転用できた。作りたいものを先に決め、それを要件に分解し、順番に片付けていく。
軽くて扱いやすいファイラーを作ろうと思い立ったワケだ。
このプロダクトの名前は Feather。Windows向けの写真特化ファイラーだ。TauriとRustで作った。開発期間はPhase 1の着手から約2週間。AIを実装パートナーに据えながら、完全にソロでv1.0.0をリリースした。
この記事では、技術的な詳細よりも「なぜこれを作ったのか」「どう考えて作ったのか」を中心に書く。コードが読めなくても、設計の話として読んでもらえれば嬉しい。
なぜ既存アプリじゃダメだったのか
写真を撮る人間なら一度はぶつかる壁がある。
RAWファイルの管理だ。
撮影から帰ってくると、SDカードの中には数百、酷い時には1000枚単位のRAWが溜まっている。動き回る息子を連射したときは1時間もあれば簡単に超えてくる枚数。
これを見返して、良いカットに星をつけて、現像に回す。シンプルな作業のはずなのに、既存のアプリがことごとく邪魔をしてくれる。
- Lightroom — 高機能すぎる。カタログ管理の概念を覚えるコストが高い。月額課金もきつい。
- FastStone — 動作は軽いが、UIが古く評価ワークフローが微妙。
- エクスプローラー — RAWのサムネが出ない。論外。
「☆をつけながらRAWをサクサク見たい」だけなのに、どのアプリもそこに辿り着くまでのコストが高すぎる。
決定的だったのは起動時間だ。Lightroomはライブラリの読み込みだけで数秒かかる。撮影から帰ってきてすぐ見返したいのに、アプリが開く前に気持ちが冷める。
「重いアプリ、開く前に終わらせる。」
これがFeatherのコンセプトになった。大げさだが。
TauriとRustを選んだ理由
最初に「Windowsアプリを作る」と決めたとき、選択肢はいくつかあった。
Electronはすぐ候補から外れた。メモリが重い。「重いアプリ、開く前に終わらせる。」というコンセプトと真逆だ。そもそもそんなの知らなかった。
WPFやWinFormsも考えたが、UIの自由度の低さがネックだった。
残ったのがTauriだった。
Tauriはバックエンドをrust、フロントエンドをReact + TypeScriptで書く構成だ。WebViewベースなのでUIは自由に作れる。なによりバイナリが軽い。Electronと比べると起動速度もメモリ使用量も別次元だ。
Rustは正直、最初から得意だったわけじゃない。でも実は今回が初めてでもなかった。前身となるFlashFinderというNAS向けファイル検索ツールをRustで作っていて、そこで培ったインデクサーの設計資産（bincode + Rayon + jwalk + fuzzy-matcher）をそのままFeatherに持ち込めた。「Rustを学ぶ」のではなく「すでに動いているものを拡張する」感覚で進められたのが大きかった。
技術スタックをまとめるとこうなる。
| レイヤー | 技術 |
|---|---|
| フレームワーク | Tauri v2 |
| フロントエンド | React + TypeScript |
| 状態管理 | Zustand |
| バックエンド | Rust |
| 並列処理 | Rayon / jwalk |
| 検索エンジン | fuzzy-matcher (SkimMatcherV2) |
競合との比較もしておく。
| ソフト | 価格 | 速度 | UI |
|---|---|---|---|
| Windows Explorer | 無料 | 遅い | 重い |
| Directory Opus | ~$90 | 速い | 複雑・古い |
| Files App | 無料 | 遅い | モダン |
| Feather | $34 | 速い | モダン |
Directory Opusは速いし機能も豊富だ。でも$90出してXP時代のUIと格闘したい人はそう多くない。そこに隙間があると判断した。（Gemini曰くだが）
AIとの役割分担 — 三者協業の実際
このプロジェクトでは3つのAIを明確に役割分担して使った。
Gemini（DeepResearch）→ Claude → Claude Code
市場調査 仕様化 実装
Geminiで「欠陥」を先に洗い出す
最初にやったのは市場調査だ。「買い切り型デスクトップアプリで収益を得られるか」というテーマでGeminiのDeepResearchを走らせた。
返ってきたのは背中を押す言葉ではなく、構造的な欠陥の指摘だった。
- 「Everythingという最強の無料検索ツールが既にある。$30の価値をどう説明するか」
- 「NASユーザーはインデックスに数時間かかる。これはクレーマー予備軍になる」
- 「Perpetual Fallback Licenseという既存モデルがある。JetBrainsも採用している」
特に「Perpetual Fallback License」という名前はこの会話で初めて知った。自分がやろうとしていたビジネスモデルに既に名前がついていて、実績もある。これだけでも調査の価値があった。
Geminiは壁打ち相手としても機能した。「サブスク疲れの層はどこで情報収集しているか」「$30という価格帯の危うさ」など、リリース後に後悔しそうな盲点を開発前に潰せた。
Claudeで仕様を「文書」に落とす
Geminiの調査結果を持ってClaudeに移った。ここでの役割は仕様の壁打ちと文書化だ。
「こういう機能を入れたい」「こういうユーザーに向けて作りたい」という断片的なアイデアを話しながら、要件を整理していった。右クリックメニューの設計方針、ペイン構成、ライセンス管理の実装方針——決めなければならないことが山ほどあった。
会話の最後にClaudeが出力したのがSPEC.mdだ。技術スタック・機能要件・非機能要件・開発フェーズが一枚に整理された仕様書。これをそのままリポジトリに置いた。
Claude Codeに仕様書ごと渡す
SPEC.mdをリポジトリに配置した状態でClaude Codeを起動した。
「SPEC.mdを読んで」と一言言えば、コンテキストが揃った状態で実装が始まる。フェーズ単位でタスクを切って渡すと、Rustのコードが出てくる。
重要なのは何を作るかはAIが決めないという点だ。Geminiが指摘した欠陥をどう捌くか、Claudeとの壁打ちでどこを削るか——その判断は全部自分でやった。AIはあくまで実装と調査のパートナーだ。
ここが鬼ほど大事な部分で、『こうしてほしい、ああしてほしい』といった曖昧な指示ではなく、こういう機能を作るためにああしてほしいくらいの粒度で要件を伝えること。意思決定はすべて自分にあると思うこと。
開発の変遷 — 作りながら変わっていったもの
Phase 1からPhase 5まで、約2週間で駆け抜けた。コードだけじゃなくて、名前もデザインも途中で変わった。
「AI臭さ」の正体に気づいた日
最初のデザインは、正直かなり良かった。Glassmorphismベースの半透明UI、モダンで洗練されていて、「これは売れる」と思っていた。
ある日、自分がGeminiで雑に作った個人用ツールと並べて気づいた。
ガワが似てる
同じ色使い、同じ半透明感、同じ角丸。AIが「良いデザイン」として出力するものが、実は全部同じ方向を向いていた。これがAI臭さの正体だと思った。
Claudeに正直に告げた。「このデザイン、AI臭い気がする」と。
そこから方針を変えた。Adobe・Figma・Linearのような、色相を排したSolid & Neutralのデザインシステムへ。角丸を削り、余白を詰め、密度を上げた。プロが使うツールは、主張しすぎないほうがいい。俺はプロじゃないが。
名前が「Feather」になるまで
開発当初のアプリ名はFlashFilerだった。前身のFlashFinderから引き継いだ命名で、特に深く考えていなかった。
ある時ふと思った。「なんかダサい」。
Claudeと壁打ちした。「写真ファイラーらしい名前にしたい、軽さと速さのイメージで」みたいなことを話していたら出てきたのがFeatherだった。
羽根。軽い。速い。そしてFの字に複数の意味を持たせられる——Filer、Foto、Fast。一文字で世界観が作れる名前だった。
FeatherRoomという案もあったが、某社商標との類似懸念で即却下。シンプルにFeatherで確定した。
Phase 1〜5の変遷
Phase 1（3/09）: コアエンジン — インデクサーと検索が動く
Phase 2（3/09）: 基本UI — 2ペイン・タブ・フォルダブラウジング
Phase 3（3/13）: 操作性 — D&D・サイドバー・右クリック・写真基盤
Phase 4（3/16）: 写真特化 — RAWプレビュー・評価値・インデクサー改善
Phase 5（3/24）: リリース仕上げ — ライセンス・インストーラー・オンボーディング
Phase 4が一番濃かった。RAWプレビューの4段フォールバック、インデクサーのv2→v3への軽量化、XMPサイドカーへの評価値永続化。「写真家向けファイラー」として出すと決めてから、機能の解像度が一気に上がった。
リリースまでにやったこと
販路：Lemon SqueezyからPolar.shへ
当初の販売プラットフォームはLemon Squeezyを予定していた。Merchant of Recordとして国際税務を代行してくれる点が魅力だった。
方針転換のきっかけはリリース直前に見つけた記事だ。Lemon Squeezyの本人確認（KYC）に時間がかかるケースがあると書いてあった。リリースのタイミングで足止めを食らうのは避けたい。
調べるとPolar.shが条件を満たしていた。KYC即日完了、APIレイテンシも良好、オープンソースというのも信頼感につながった。販売価格は$34、Perpetual Fallback Licenseは維持。
インストーラーとLP
インストーラーはNSISで構築した。tauri iconでアイコンの全サイズを生成し、インストール時に「Featherで開く」をWindowsの右クリックメニューに登録する仕組みも入れた。
ちなみにLPはこちら → https://feather.ena-dri.dev
個人開発でここまで出来る時代かぁという気持ちも大きい。
振り返り — 設計職出身だからこそ
意思決定は全部自分でやった
AIを使って開発していると、「どこまでAIに任せていいのか」という問いが常についてまわる。
自分の答えはシンプルだった。意思決定は全部自分でやる。
Geminiが欠陥を指摘してくる。割といい頻度でハルシネ起こす。Claudeが仕様の懸念を言ってくる。Claude Codeが「コード長くなってきたのでリファクタリング（責務の分割）しますか？」とそれを聞きながら、最終的に「やる」「やらない」「後回し」を決めるのは全部自分だった。
ぶっちゃけ「本当に大丈夫かな」と都度確認しながら進んだ。でもその確認をしていたのはAIではなく自分自身だ。
AIは鏡として機能した。自分の考えを言語化して投げると、整理されて返ってくる。その繰り返しで仕様が固まっていった。
エンジニア畑じゃないからこその思い切り
設計職出身には、エンジニア的な「これは技術的に難しい」という先入観がない。
詰むまで走る。詰んだら考える。
それだけだった。右クリックメニューの実装がTauriで難所だと分かったのも、実際に触り始めてからだ。事前に「難しいからやめておこう」という判断をしていたら、Windowsネイティブのコンテキストメニュー連携は実装されていなかった。
というのも、元々右クリックメニューをWindowsネイティブのコンテキストメニューに寄せる発想を得ていたのだけど、流石にきついというのがわかり、「ほんならWindowsの右クリックメニューを出したらいいのでは」って思ってClaudeに聞いたりもした。
設計職で身についた「やることを分解して整理する」という習慣が、SPEC.mdという形でそのまま機能した。作りたいものを先に決めて、分解して、順番に片付ける。諸々の設計をするのと、やることは同じだった。
「重いアプリ、開く前に終わらせる。」
2週間で作ったアプリが、自分のワークフローに完全に組み込まれている。SDカードを挿したら自動で起動して、RAWをさっと見て、星をつけて、現像に回す。それだけのことが、既存のアプリでは重くて遅くてストレスだった。
しかも撮って出しJPGからRAWもマッチングしてくれるし、Markdownのビューワも兼ねてる。
そう、自分が欲しいものを作って、自分が一番使っている。それがソロ開発の一番の動機になると思う。
もし同じような不満を持っている写真好きのWindowsユーザーがいれば、ぜひ触ってみてほしい。