しんたろーのITアカデミー
開発日記

AIに投稿を10本生成させたら画面が死んだ。1人開発でぶち当たった非同期処理という絶望

AIに投稿を10本生成させたら画面が死んだ。1人開発でぶち当たった非同期処理という絶望
しんたろーしんたろー
12分で読めます
この記事の内容(目次)
※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記です。

10本の投稿をAIに一気に作らせようとした。

画面が完全に固まった。

ブラウザのタブが応答なし。Macのファンが爆音で回り始める。

ただAIにリクエストを投げただけなのに、フロントエンドが悲鳴を上げた。

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

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

限界突破の代償

今週はUXの限界に挑んだ。結果として、44件のコミットを積んだ。

非同期処理の壁と10本生成の負荷
非同期処理の壁と10本生成の負荷

  • 総コミット: 44件
  • 新機能: 1件
  • バグ修正: 2件
  • 壊れた回数: 数え切れない

ユーザーに「10本一気生成」という体験を提供したかった。

裏側にある非同期処理の壁に激突した。

AIアプリ特有の「待ち時間」をどう処理するか。その答えを探す泥臭い記録だ。

速度という名の劇薬

モーダルの表示速度を上げるため、「02:32 - CreatePostModalのデータ取得を並列化して高速化」をコミットした。

ペルソナ、アカウント、パターン、生成状況。4つの独立したクエリをPromise.allで並列実行した。

直列で待たされていた時間が4分の1になった。

本日の開発スタッツ
本日の開発スタッツ

ここまでは完璧だった。

実際に10本の投稿生成を走らせた途端、画面が完全にフリーズした。

フロントエンドのステート管理が崩壊していた。

並列でAPIを叩きまくると、Reactのレンダリングサイクルが追いつかなくなる。

非同期の更新が激しく競合する、いわゆるRace Condition(競合状態)が発生した。

「生成中」のステートがあちこちで上書きされ、UIが不整合を起こした。

しんたろーしんたろー:
プログレスバーが0%から100%の間を激しく反復横跳びしていた。並列化は劇薬だ。速さと引き換えに状態管理の難易度が跳ね上がる。

業界標準ではReact QuerySWRのようなキャッシュ戦略を使う。

企業開発なら、これで大半の非同期バグは防げる。

だが今回は「AIによる生成」というリアルタイム性が極めて高い処理だった。キャッシュでは全く解決できない。

Zustandによる厳密なグローバルステート管理を導入した。

02:39 - 投稿生成時のプログレスバー表示を修正」をコミットした。

生成進捗を視覚的なプログレスバーとして正しく表示させるためだ。

さらに「02:03 - PostGenerationServiceにonProgressコールバックの型定義を追加」を実装した。

続けて「02:07 - generatePostsWithConcernsにonProgressコールバックのサポートを追加」も押し込んだ。

これで裏側の進捗がフロントエンドに正確に伝わる。画面が固まることはなくなった。

プログレスバーが滑らかに伸びていく。

同時に、生成のペース自体にも手を入れた。

11:38 - 投稿候補生成の段階的ペース調整と0.1pt消費を実装」をコミットした。

ペルソナ作成当日は24件、翌日以降は16件とベースペースを調整した。

非アクティブ日数に応じて生成量を段階的に減らすロジックも組んだ。

無尽蔵にAIを回せば、APIコストが爆発して僕が破産するからだ。

12:08 - 手動生成のポイント消費を1pt/件に変更、UIに消費pt表示」も追加した。

ユーザーには消費ポイントを明示する。無駄な連打はこれで防げる。

フロントエンドの最適化とビジネスロジックの制限。この両輪が揃って、初めて「10本一気生成」が実用レベルになった。

しんたろーしんたろー:
最適化がキマった時の脳汁は異常だ。でも直後にAnthropicのAPI請求ダッシュボードを見て真顔になった。速く作れる=速くお金が溶ける。

消えたユーザーデータ

予約投稿一覧の画面も爆速にしたかった。

16:51 - Optimize scheduled posts filters with SQL-level filtering」をコミットした。

ペルソナ名でのフィルタリングをDBレベルのSQLクエリに移行した。

さらに「16:54 - Move account filter to SQL level in scheduled posts」も追加した。

アカウントの絞り込みもSQLで直接行うようにした。

クライアントサイドで配列をこねくり回すより、DBに任せた方が速い。そう信じて疑わなかった。

テストしてみると、画面から投稿が消滅した。

同一の投稿候補が複数アカウントに紐付いている場合の挙動がおかしい。

片方のアカウントでフィルタをかけると、もう片方の予約まで見えなくなる。

表示漏れのバグが多発した。ドメインモデルの複雑さを完全に舐めていた。

投稿とアカウントは多対多の関係にある。

SQLのJOINで単純に絞り込むと、意図しない行までごっそり除外されてしまう。

パフォーマンスを追い求めた結果、ユーザーのデータが消えたように見える最悪のUXを生み出した。

しんたろーしんたろー:
速さを求めて正確さを捨てた。SQLのパズルに夢中になりすぎて、ユーザーの顔を忘れていた。元の実装に戻すだけの作業に数時間を溶かした。まじかよ。

SQLでのフィルタリングは諦めた。

20:01 - 予約投稿のアカウントフィルタをクライアントサイドに移動」をコミットした。

SQLレベルのアカウントフィルタを全削除し、クライアントサイドでのフィルタリングに回帰した。

投稿候補画面と同じフィルタ動作に統一した。

DBレベルのフィルタリングは確かに速い。だが、ユーザーの直感と乖離するなら全く意味がない。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

落とし穴:「スマホで使いやすくして」の代償

「スマホで使いやすくして」とClaudeに全投げした。

PC版のUIがほぼ完成し、あとはレスポンシブ対応だけだと思っていた。

AIから返ってきたコードはエラーが一つもない。完璧に動いた。

実機で触ってみて絶望した。

ボタンが指の腹で押せないほど小さく、誤タップを誘発する配置になっていた。

Appleのガイドラインではタップ領域は最低でも44×44pt必要だと言われているが、AIが書いたコードは見た目の美しさを優先してそれを完全に無視していた。

ドロップダウンが外側のクリックで閉じない。グラフのY軸ラベルが見切れている。

チャートの文字が小さすぎて読めない。上部の余白が完全にズレている。

僕が自分でスマホを触り、気になった箇所をリストアップした。

13:16 - ドロップダウンの外側クリックで閉じる&リライトメニュー改善」をコミットした。

17:04 - increase chart text size for mobile readability」も追加した。

17:12 - Y軸ラベルが切れる問題を修正(SVG viewBox調整)」も直した。

15:12 - 投稿候補ページの上部余白を改善」でマージンも泥臭く調整した。

出てきた修正項目は10個を超えた。

AIに一瞬でコードを書かせた後、人間が10個のUI修正を手動でやる。

これがAI開発の現実だ。魔法の杖は、最後の1ミリを埋めてはくれない。

今日の数字

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

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

| 総コミット数 | 44件 | 先週の平均は1日15件 |

| UX修正数 | 10箇所 | 企業開発なら3人日相当。僕は数時間 |

| API並列化 | 4クエリ同時実行 | 以前は直列で4倍の待ち時間 |

| 手動生成コスト | 1pt/件 | 無制限の時はAPI代が青天井 |

10個のUI修正を1人で完遂した。

一般的な企業のチーム開発なら、デザイナー・フロントエンドエンジニア・QAテスターが関わる。最低でも3人日はかかる作業量だ。

僕はそれを数時間で終わらせた。

Claude Codeのおかげでコードを書く時間自体は圧倒的に短い。

ただ、実機で触って「ここが使いにくい」と判断するUX検証の遅さがボトルネックになる。

AIの生成スピードに、人間の確認スピードが全く追いつかない。

1人で何人分ものコードを生み出せるからこそ、テストの負担が1人に重くのしかかる。

よくある質問

Q: Race Conditionはどうやって検出したの?

プログレスバーが0%→100%→0%と暴れているのを目視で発見した。

React DevToolsでステートの更新タイミングを追ったら、複数の非同期コールバックが同じステートを同時に書き換えていた。

検出自体は5分。直すのに2時間かかった。

Q: SQLフィルタをやめてクライアントサイドに戻したら、パフォーマンスは落ちないの?

今のデータ量では体感できるほどの差はない。

予約投稿が数万件規模になったら再設計が必要だが、今は正確さを優先した。

多対多のJOINを正しく書くより、まず動くものを出す方が先だ。

Q: AIが書いたレスポンシブコードはなぜタップ領域を無視したの?

Claudeはコードの構文的な正しさは知っているが、「人間の指の太さ」はプロンプトで明示しないと考慮しない。

「Appleのタップ領域ガイドライン44×44ptを守って」と最初から指示すれば防げた。

次からはモバイル対応の指示にガイドライン番号を入れる。たぶん。

まとめ

並列化して速くなった。Race Conditionで画面が死んだ。SQLで速くした。データが消えた。AIにレスポンシブを任せた。指で押せないUIが出てきた。

44コミット、全部そういう話だった。

👉 ThreadPostでSNS運用を自動化する

ThreadPost — SNS投稿をAIが自動化

この記事が参考になったら、ThreadPostを試してみませんか?投稿作成・画像生成・スケジュール管理まで、AIがサポートします。

無料で始める

この記事をシェア

XはてブLINE
しんたろー

ThreadPost開発者・個人開発エンジニア

AI × SaaS個人開発者。Cursor / Claude Code を使った効率的開発、SNS自動化について実体験から発信。

人気の記事