Claude CodeでUIを丸投げしたら「動くゴミ」が完成した。1人開発で学んだ残酷な真実。

※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記です。

3回作り直したメニュー画面

メニューを3回作り直した。最初はフラットなリスト。次は全部折りたたまれた階層構造。最後は縦に長すぎる全展開リストだ。

AIは指示通りにコードを書いた。そして完璧な「動くゴミ」を作り続けた。

32回のコミットが残した爪痕

ダッシュボードのUIを直感的にしようとした。結果として、32回のコミットを積み重ねた。

新機能は2件。バグ修正は0件だ。UIの迷走と、管理者機能の裏側の格闘がすべての時間を溶かした。

忠実すぎるAIがもたらす悲劇

ダッシュボードのメニュー構造を整理すれば、操作性は向上するはずだった。最初はフラットなリストで作った。

ホーム、投稿候補、スケジュール、SNS連携、設定、プラン。これらがすべて同じ階層に並んでいた。

ページが増えたら見づらくなった。だから階層構造に変えた。「06:41 - ダッシュボードメニューを階層構造に改善」を実行した。ダッシュボード、投稿管理、設定、アカウントという大項目を作った。

その下にネストする形でメニューを配置した。今度は全部折りたたまれていて、どこに何があるかわからない。ユーザーは目的の機能を探すために、一つ一つクリックして開く必要がある。これはUXの観点から最悪だ。

「全部展開すればいいじゃん」と思って全展開を指示した。「07:02 - ダッシュボードメニューを初期状態で全展開」をコミットした。今度は縦に長すぎて、スクロールが終わらない。AIに指示を出すたびに「はい、直しました」と無思考に実装される。

UXの最適解をAIが提案してくれることはない。指示された構造を忠実に再現するだけだ。UI設計において、AIは認知負荷を考慮しない。

ヒックの法則というものがある。選択肢が増えるほど、ユーザーの決定時間が伸びるという法則だ。一般的なSaaSでは、一度に表示する選択肢は5〜7個が限界だ。

階層が深すぎるとユーザーは迷子になる。浅すぎると情報過多になる。これはSaaS開発において典型的な罠だ。AIに丸投げすると、この肥大化が光の速さで進む。

LLMは文脈を理解するが、ユーザーの視線の動きまではシミュレートしない。コードとしての正しさと、プロダクトとしての正しさは別物だ。

僕は3回目の作り直しでようやく気づいた。「07:05 - サイドメニューをアコーディオン式に変更」をコミットした。複数メニューの同時展開をやめ、1つのメニューのみ展開する方式にした。

しんたろー:
Claude、お前さぁ。最初から「アコーディオンにしますか？」って言えよ。僕が指示するたびに「わかりました」って作り直すの、止めてくれ。一回でいいから提案してほしい。

結局、アコーディオンという古典的なUIに落ち着いた。階層化によりクリック数は減ったが、視認性が低下した。アコーディオン化で「操作数」と「視認性」のバランスが最適化された。

AIは「実装の代行者」としては優秀だ。しかし「プロダクトの責任者」ではない。ユーザーの文脈を理解している開発者が設計しないとダメだ。そうしないと、AIはただの「動くゴミ」を量産する機械になる。

ただ、3回やったおかげでニュースソース設定のUI設計はスムーズだった。ペルソナ単位でソースを管理する構造が、一発で決まった。「07:08 - ニュースソース設定ページを実装」でベースを作った。最初の2回の失敗が頭に残っていた。

だから設計を先に固めてから指示できた。デフォルトカテゴリ選択、積極的に採用するキーワード、除外するキーワード。これらをペルソナごとに管理する。「07:15 - ニュース設定を正しい設計に修正（ペルソナ単位管理）」で完璧に仕上がった。

しんたろー:
設計書を先に書いたら一発で通った。AIへの指示がクソだとクソコードが返ってくる。当たり前の事実を3回目でようやく理解した。

UIの見た目を作るのは一瞬だ。でも、その裏にある「なぜその構造なのか」を考えるのは人間の仕事だ。AIにUIを丸投げしてはいけない。僕の貴重な睡眠時間が削られるだけだ。

力技でねじ伏せた状態管理

管理者権限でユーザーになりすます「Impersonate機能」の実装だ。「19:53 - 管理者Impersonate（代理閲覧）モード実装」をコミットした。単にセッションを切り替えるだけの簡単な実装だと思っていた。

甘かった。Next.jsのルーターがURLパラメータを消し去る。ページ遷移のたびに「誰になりすましているか」を見失う無限ループに陥った。「20:31 - Impersonate時にwindow.location.hrefで遷移」という力技に出た。

Next.jsの内部処理をバイパスして直接遷移させた。それでも状態が消える。Next.jsのApp Routerはクライアントサイド遷移時にクエリパラメータを保持する設計だ。しかしMiddlewareやServer Actionとの組み合わせで状態が競合しやすい。

特にService Role Clientへの切り替え時は厄介だ。セキュリティ境界を越えるため、単なる状態管理以上の厳密な同期が求められる。通常のユーザーセッションと、管理者としての代理セッション。この2つがブラウザの中でコンフリクトを起こす。

僕はキレた。「20:44 - Impersonateモードでナビゲーション時にURLパラメータを維持」を実装した。そして「21:07 - ImpersonateパラメータをURLからストアに同期」を叩き込んだ。URLパラメータとZustandストアを強制的に同期させるフックだ。

ページ遷移時にURLのimpersonateパラメータを読み取る。それをZustandのグローバルストアに書き込む。全ページで状態を維持することに成功した。実装コストは当初の想定の5倍に膨らんだ。

しんたろー:
Next.jsの仕様に真っ向から喧嘩を売って勝った。ZustandとURLの強制同期。フロントエンドの教科書には絶対載ってない邪悪なコードだ。でも動くから正義だ。

落とし穴

Impersonateモードでユーザーになりすましてデバッグしようとした。ページ遷移するたびに「誰だっけ？」とシステムがなりすまし状態を忘れる。僕はそのたびにURLパラメータを手動で打ち直した。

管理者権限でログインしているのに、自分の権限すら忘れる「記憶喪失システム」が完成した。30分間、僕はただひたすらURLを修正するbotになっていた。システムを自動化するはずが、僕自身が手動スクリプトに成り下がった。

今日の数字

| 指標 | 結果 | 比較対象 |

|------|------|----------|

| コミット数 | 32件 | 企業チームなら3日分。僕は1日 |

| 新機能 | 2件 | 先週は0件。今日は2件 |

| メニュー作り直し | 3回 | プロのデザイナーなら1回。僕は3回 |

| Impersonate実装 | 4時間 | 外注なら20万円。僕はAI代1.5ドル |

32回のコミットで機能刷新を完了させた。この速度は、従来の開発手法の約4倍のペースだ。人件費換算で数週間分の作業を、AIとのペアプロで数時間で圧縮した。ただし、その数時間の精神的疲労は数週間分に匹敵する。

よくある質問

Q: Impersonate機能でService Role Clientを使うリスクは？

Service Roleは行レベルセキュリティをバイパスする強力な権限を持つ。悪用されると全データが流出する。だから管理者権限のチェックをMiddlewareレベルで二重に実装した。

Q: なぜClaude Codeに任せきりにせず、自分で設計を固めたのか？

AIは実装の代行者としては優秀だが、プロダクトの責任者ではない。UIの階層構造のようなUXの根幹は、ユーザーの文脈を理解している開発者が決めるべきだ。

Q: 32件のコミットのうち、最も時間がかかったのは？

Impersonate時の状態同期だ。URLパラメータとZustandストアの強制同期に4時間を費やした。Next.jsの仕様と真っ向から戦う羽目になった。

ThreadPostは今日も進化した。開発の裏側を覗き見たいなら、ThreadPostをチェックしてくれ。