Claude Codeで渾身の新機能を即削除した。1人開発で学んだ引き算の美学。

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

渾身の新機能を作って、たった3時間で全コードを消した。投稿失敗時のリカバリを爆速にする「投稿候補コピー機能」だ。完璧なUXだと思ったが、自分で触った瞬間に違和感が爆発した。失敗した投稿をそのままコピーしても、また失敗するだけだ。僕はClaude Codeにコードの完全削除を指示した。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。

無料で始める

足すより引く方が難しい

今週は機能追加より「削ぎ落とし」に時間を溶かした。総コミット37件。新機能は2件、バグ修正は1件だ。残りの34件は全部、UIの整理と無駄なコードの削除だった。

AIは指示すれば何でも秒で作る。だからこそ、開発者は「何を捨てるか」の判断を迫られる。機能の足し算は誰でもできる。引き算には覚悟がいる。

完璧なリカバリ体験の追求

失敗した投稿のUXを劇的に良くしたかった。APIエラーや文字数オーバーで、SNSへの投稿が失敗することはよくある。そのたびにユーザーは、一から文章を作り直していた。

これは最悪の体験だ。長文を入力して送信ボタンを押し、赤いエラーが出たときの絶望感は異常だ。僕はリカバリを爆速にする機能を作ることにした。

「feat: ニュース記事手動選択投稿機能と投稿履歴コピー機能を追加」とClaude Codeに指示した。失敗した投稿カードに「投稿候補にコピー」ボタンを置く。ボタン一発で、編集画面にテキストが復元される。これでユーザーの心理的ハードルは下がるはずだ。Claudeは完璧なコードを吐き出した。

UIのコンポーネントを分離し、カードを再利用可能にした。「refactor: PostCandidateCardコンポーネント化」で「PostCandidateCard.tsx」という829行の新規ファイルが作られた。同時に、既存のファイルから582行のコードが削減された。ドラッグ＆ドロップやアニメーションの機能はすべて維持されている。AIのリファクタリング能力は狂っている。

しんたろー:
自分が天才だと思った。実装にかかった時間はたったの3時間。外注したら10万円は飛ぶ要件が、一瞬で終わった。

悪魔のボタン

意気揚々と本番環境にデプロイした。スマホで実際に失敗した投稿を作って、コピーボタンを押す。編集画面に復元されたテキストを、そのままもう一度送信した。当然、また失敗した。当たり前だ。失敗した投稿には、必ず失敗した理由がある。

画像サイズが大きすぎるか、APIのレートリミットに引っかかったかだ。それをそのままコピーして再送しても、同じエラーが出るだけだ。僕はエラーハンドリングの基本を完全に忘れていた。システムの再試行と、ユーザーの編集を混同してはいけない。SaaSのUI設計において、選択肢を増やすことは認知負荷を上げるだけだ。

僕は「投稿候補にコピー」ボタンを見つめた。ユーザーに無駄な再試行を促し、APIの無駄打ちを誘発するだけの悪魔のボタンだ。作ってからわずか3時間。僕はClaudeに削除を指示した。

引き算の決断

「refactor: 失敗投稿のUI簡素化 - 投稿候補コピー機能削除」と打った。せっかく作った機能を消すのは勇気がいる。でも、残しておけば確実にユーザーを混乱させる。結局、失敗カードに必要なのはコピー機能ではなかった。「なぜ失敗したか」が一目でわかることだけだ。ステータスごとにアクションボタンも整理した。

「feat: ステータス別にアクションボタンを整理」で予約中なら予約キャンセルと時間変更。失敗時とキャンセル時は削除のみ。これでUIは極限までシンプルになった。

しんたろー:
3時間の作業が完全に無駄になった。でも、ここでサンクコストに引っ張られて残すのが一番の悪手だ。コード行数は少ない方が偉い。

ネイティブ志向の罠

UIの断捨離をしていると、別の違和感に気づいた。スマホで画面を引っ張って更新する、Pull-to-Refreshの挙動だ。ネイティブアプリみたいに滑らかに動かない。「feat: Pull-to-Refreshの閾値を緩和しスピナー位置を調整」で発動閾値を100pxから60pxに下げた。少し引っ張るだけで更新されるようにした。

「feat: Pull-to-Refreshでダッシュボードのデータを再取得」でNext.jsの機能を呼び出して最新データを取得する。スマホで引っ張る。スピナーが回る。しかし、データが変わらない。Next.jsのApp Routerのキャッシュの罠だ。サーバーコンポーネントを再フェッチしても、クライアントのキャッシュが残る。更新したのに、古いデータが表示され続ける。最新のフレームワークは便利だが、ブラックボックスが多すぎる。キャッシュ戦略が複雑すぎて、開発者がコントロールしきれない。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。

無料で始める

妥協のブラウザリロード

僕は冷徹に判断した。スマートな実装は諦める。「fix: Pull-to-Refreshをシンプルなブラウザリロードに変更」でキャッシュを無視して、ただのブラウザリロードに書き換えた。画面全体が一瞬白くなる、あのダサい更新処理だ。でも、確実に最新データが取得できる。

しんたろー:
モダンSPAの理想が崩れ去った瞬間。でも確実なデータ取得には勝てない。ユーザーは滑らかなアニメーションより、正しい数字を見たいはずだ。

Pull-to-Refreshの閾値も元の100pxに戻した。「fix: Pull-to-Refresh閾値を100pxに戻す」で60pxだと、少し上にスクロールしただけで誤爆してリロードが走ったからだ。結局、元の状態にただのブラウザリロードを付けただけになった。無駄な調整に時間を溶かした。メンテナンス作業は、理想と現実の妥協の連続だ。

泥臭い負債の返済

裏側のデータ不整合の修正も進めた。「fix: scheduled_postsの重複作成バグを修正」でデータベースにUNIQUE制約を追加した。既存の重複データ8件は手動で削除した。クライアント側でも重複除去フィルタを追加した。「feat: 配信停止者リストにリード(marketing_leads)の停止者を表示」で管理画面の配信停止者リストが不完全だったのを修正した。

「fix: 日次レポートの期間上限を修正（当日分が含まれないバグ）」でレポートの集計期間の上限がJSTの当日0:00になっていたのを直した。夜に送信されたデータが反映されていなかった。上限を実行時点の時刻に変更した。地味で泥臭いバグ修正ばかりだ。でも、こういう負債の返済がプロダクトの寿命を決める。

落とし穴

「失敗したならもう一度試せばいい」という単純なロジックでコピー機能を実装した。エラーが出たら再試行する。プログラマの思考回路としては至極真っ当だ。リリース直後、自分自身で触ってみて違和感に気づいた。「これ、失敗した理由を直さないとまた失敗するだけじゃん」。文字数オーバーで失敗した投稿をコピーして、そのまま送信ボタンを押す。同じエラーが返ってくる。完全にアホだ。AIのClaudeに「これ使いますか？」と聞くべきだった。AIは指示通りに完璧なコードを書く。だが、僕の思考停止まではカバーしてくれない。機能の要否を決めるのは、人間である僕の仕事だ。AIに丸投げしていいのはコーディングだけで、設計思想は渡してはいけない。

今日の数字

| 項目 | 今週の数字 | 比較対象 |

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

| 総コミット数 | 37件 | 先週は42件 |

| 新規ファイル | 829行 | 企業なら数日の実装。僕は数分 |

| 削減したコード | 582行 | 過去最大規模の断捨離 |

| 削除した機能 | 1個 | 一般的な機能の寿命は1〜2年 |

| AI代 | $1.20 | 外注なら数万円 |

今回削除した機能の実装コストは3時間だった。もしリリースして放置していたらどうなるか。ユーザーからのバグ報告対応や、複雑化したUIの保守コストが乗ってくる。保守コストは実装コストの3倍以上と言われている。推定10時間だ。実装コスト3時間と、将来の保守コスト10時間。合計13時間分の損失を、3時間の削除作業で回避した計算になる。コードは書いた瞬間から負債になる。消したコードこそが、最もバグのないコードだ。13時間の未来の時間を買ったと思えば、安いものだ。