中国語の原文をもとに、AI を使って翻訳しています。2026年9月19日更新。

Snap Closet をようやく iOS・Android の両方で公開し、Shipaton にも応募しました！

2年前に作り始めたころは、まだ Handy Closet という名前でした。きっかけは単純で、服はたくさんあるのに、いつも何か足りない気がすること。よく着るのは同じ数着なのに、また似たものを買って帰ってしまう。そんな散らかった服の情報をまとめて、いつでもどこでも眺められるようにしたかったのです。さらに、指先でちょっと操作するだけで、ちゃんと使えるコーディネートの提案も欲しい。でも、昔ながらの手作業での開発は難航し、プロジェクトは丸1年放置することになりました。今年はモデルの進化に助けられ、なんと2〜3か月で作り直せました。自分にとっては、なかなか大きな達成です。

個人開発はスピード重視

最初はごく自然に、会社で慣れた開発の進め方を持ち込みました。デザインは Figma、タスク管理は Atlassian。仕事が終わってからもチケットを作って、自分を追い込んでいました。ひとりで地道にコードを書き、半年かけても完成度は4割に届かず。見た目も気に入らないし、仕事以外の時間で直す余裕もない。それで、いったん放置しました。

再開しようと思ったのは、今年の4〜5月ごろです。Fable や GPT-5.6 などのモデルが大きく進化して、今回は本当に今までと違うと感じました。AI の出力が、とにかく速くてよい。少しエンジニアリングの視点を持ち、繰り返し使える手順を意識してスクリプトや Skill にまとめれば、普段の開発作業の大部分を、ほとんど付きっきりにならずに任せられるようになりました。

改修前に Figma で手作業で設計した Handy Closet の画面とコンポーネント
以前：Figma で画面、コンポーネント、操作の説明をひとつずつ作っていたころ。
その後：Skill で生成した HTML デザインシステム。デザイントークンとコンポーネント集をスクロールで紹介。

たとえば、Figma で細部をこつこつ作り込む作業の代わりに、デザインシステムの Skill を書いてみました。すると、数回のやり取りだけでデザインシステム全体が書き直され、実装済みの部分も新しいルールに合わせて置き換わりました。プロジェクトで決めていた Design Token（色や余白など、名前を付けたデザインの値）、Atomic Component（ボタンや入力欄などの基本部品）、Composed Component（基本部品を組み合わせて機能を持たせた部品）という階層も、きちんと保たれていました[3][4]。Figma の画面で Property や Variable の追加方法を苦労して覚えていたころを思い出すと、あれはもっと思い切って手放してよいサンクコストだったのだと思います。

もちろん、その苦労が全部無駄だったわけではありません。手作業で作っておいた骨組みのおかげで、デザインシステムの原則やコードのルールを説明するプロンプトは、かなり省けたはずです。また、Skill の出来はモデルの能力、プロンプトの質、自分自身の好みや美的感覚が重なって決まるものでもあります。この話は、また別の機会に書けたらと思います。ここで言いたいのは、会社のチームで実務を担う IC から、自分のコードベースのプロダクトオーナーになるには、手放すべき思い込みがかなりあるということです。きれいな中間成果物を作るのは、多くの場合、前後の工程を担当する人に説明し、認識をそろえるための仕事です。ひとりで AI と向き合うなら、入力を渡してから出力を確認するまでの間は、人にとってブラックボックスでもよい。人とエージェント、エージェント同士のやり取りには、別のインターフェースが必要です。それは、数個の Markdown や HTML のファイルのように、とても軽いものでよいと思います。

人に説明したり、見せるために整えたりする作業を減らすと、成果が出たときの手応えを、より直接感じられます。エージェントを並列で動かせば、その手応えが返ってくる間隔もぐっと短くなる。小さな達成感で何度もドーパミンが出るような感覚に後押しされ、3か月もたたないうちに両プラットフォームで公開できました。以前の自分には想像できなかった速さです。「個人開発者にとって、バイブコーディングの最適なワークフローとは？」と考える人もいるでしょう。それを探すのはよいことですが、準備に時間をかけすぎるのも考えものです。助走が長くなるほど、続ける意欲は薄れてしまう[1]。うまく作る方法以上に、最後まで作る方法を考えたいです。よさそうなモデルを選び、agent、harness、MCP、Skills といった話はいったん忘れて、まずはチャット欄から計画を自分ひとりでは出せない速さで進めてみる。そこで最初の達成感を得ることが、完成に向けた第一歩だと思います。

使いやすさにも、手を抜かない

Snap は snapshot に由来します。写真を気軽に撮る、カシャッという軽い感じ。それが Snap Closet で目指したい使い心地です。そのために、画面の細部や操作の流れには、いろいろ工夫をしました。

  • 最短の動線を選ぶ。服を追加するボタンは、画面下のナビゲーションの中央、一番目立つ場所に置きました。途中にメニューを挟まず、服を整理しようと思ったらすぐに始められます。最初に開くホーム画面も、通販アプリのようにカテゴリーをいくつも並べて階層を掘っていく形にはせず、アイテムをそのまま一覧にしました。2列と4列のグリッドを切り替えられるのも、1画面でより多くの服を見渡して、すぐに選べるようにするためです。
  • 時間のかかる処理を意識させない。背景の切り抜きや画像のトリミングは、撮影時に端末上のモデルで済ませます。AI による画像認識や分類はバックグラウンドでまとめて処理し、結果を待たずに次の画像をアップロードできます。分類が終わった服から、順にホーム画面へ並んでいきます。
  • 入力欄の代わりに選択肢を用意する。モデルへ送るプロンプトのほとんどは、選択肢をタップする、写真を撮る、画像をアップロードするといった操作から、バックエンドで組み立てます。AI にコーディネートを相談する「Ask your closet」でも、チャット欄の占める割合を小さくしました。参考画像の雰囲気をもとに提案してもらう選択肢も用意し、文章を考える手間を減らしています。

それから、Snap Closet には親しみやすさや楽しさも感じてほしいです。色とりどりの服のアイコン、カードの動き、実績を獲得したときのアニメーション。そうした細部でアプリに温かみを出したいし、自分の熱意も伝えたいと思っています。

私は、チャットが AI アプリの最終形だとは思っていません。Steve Krug の『Don’t Make Me Think』が掲げる「考えさせない」という原則[2]は、今も UI・UX で目指す価値があります。欲しい結果を出すためにユーザーに呪文を考えてもらうより、もともと日常でしていることに AI の処理を組み込み、その手間を大きく減らしたい。application が本当に applicable、つまり実際に役立つものになるのは、そういうときだと思います。服を整理する、分類する、着こなしを考える、手放すものを選ぶ。自分でもやっていることですが、面倒で効率が悪く、ほかのやらなければいけないことに押されて後回しになりがちです。クローゼットの情報をスマートフォンに入れるだけでなく、その裏側の AI によって、こうした一連の作業がもっと楽しく、気軽になればと思っています。

これからのこと

デジタルクローゼットのアプリは、すでにたくさんあります。でも、作る人によって着眼点は違うはずですし、Snap Closet にもまだいろいろな可能性があります。

バーチャル試着とクレジットの仕組みから考えると、ゲームらしい楽しさやソーシャルな要素を増やす方向があります。服のライフサイクルに目を向ければ、買うときや売るときに、ほかのプラットフォームと連携することも考えられます。あるいは、整理することに引き続き力を入れて、手元にあるものを上手に使えるようにするのもよさそうです。これからどこへ進めるか、引き続き探っていきます。それも、とても面白いところです。

どちらへ進むにしても、Snap Closet はシンプルで操作しやすいままであってほしい。今後少しずつ公開していくほかのアプリでも、目指すところは同じです。人が困っていることを AI の力で解決して、暮らしをもっと楽にしたいと思っています。

製品リンク

参考文献

  1. Woolley, K., & Fishbach, A. (2018). It’s about time: Earlier rewards increase intrinsic motivation. Journal of Personality and Social Psychology, 114(6), 877–890. 論文概要 · DOI。報酬を得るタイミングと内発的動機づけの関係を扱った研究です。個人開発との結びつきは、私自身の経験から考えたものです。
  2. Krug, S. (2014). Don’t Make Me Think, Revisited: A Common Sense Approach to Web (and Mobile) Usability (3rd ed.). New Riders. 著者による書籍紹介。
  3. Design Tokens Community Group. (2025). Design Tokens Format Module 2025.10. 仕様書。Token の定義は、このコミュニティ仕様を参考にしています。W3C の正式な標準ではありません。
  4. Frost, B. Atomic Design, Chapter 2: Atomic Design Methodology. 原著の該当章。原著は Atoms、Molecules、Organisms、Templates、Pages に分けています。本文の3層は、このプロジェクトでの整理方法であり、原著の階層そのものではありません。