※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記です。
SNS運用を自動化しませんか？
ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。
画面がフリーズする地獄
4コマ漫画生成ボタンを押す。
画面が完全にフリーズした。
Vercelがタイムアウトで落ちた。
サーバーレス環境の残酷な現実を突きつけられた瞬間だった。
非同期処理にすれば全て解決すると思っていた。
僕はそれで終わりだと思っていた。
甘かった。
同期と非同期を往復し、気づけば数十個のコミットを積んでいた。
新機能はゼロだ。
バグ修正と状態管理の泥沼に首まで浸かっていた。
VercelのHobbyプランは実行時間が10秒に制限されていると言われている。
Proプランでも最大300秒だ。
画像生成を伴う4コマ漫画の生成は、APIを複数回叩く。
この制限を簡単に超えてしまう。
エッジファンクションを使えば速くなるという話もある。
しかし、重い画像処理をエッジで回すのは現実的ではない。
サーバーレスファンクションのメモリ制限も立ちはだかる。
大きな画像をメモリに載せると、すぐに上限に達する。
コールドスタートの問題も無視できない。
しばらくアクセスがないと、最初の実行に数秒の遅延が発生する。
これらが重なり、同期処理ではどうにもならなくなった。
重い処理はバックグラウンドに逃がすしかない。
そう思ってInngestを導入した。
これが果てしない状態管理の迷宮の入り口だった。
最適化したら、新しいバグが3つ出た。
解決策ではなく、新たな戦場の始まりだった。
しんたろー:
4コマ漫画生成ボタンを押したら画面が真っ白になった。Vercelのログを見たら真っ赤なエラーが並んでた。まじで泣きそうになった。
同期と非同期の不条理な往復
「00:01 - 4コマ漫画生成をInngestから同期処理に変更」
最初は普通に同期処理で作っていた。
Vercelのタイムアウト制限に引っかかった。
APIのレスポンスが返ってくる前にコネクションが切られる。
「じゃあInngestで非同期にすれば解決じゃん」と思って移行した。
「00:08 - 4コマ漫画生成をInngest非同期処理に復元」
ここからが地獄の始まりだった。
Inngest側でもタイムアウトが出る。
イベント駆動アーキテクチャは魔法ではない。
裏側で動くワーカーも、結局はどこかのサーバーで実行されている。
「00:23 - Inngestのconcurrency上限をプラン制限(5)に合わせる」
concurrencyの上限がプランの制限に引っかかった。
並行処理の数を制限すると、今度はキューにジョブが溜まり始める。
ユーザーはいつまで経っても結果を受け取れない。
分散システムの結果整合性を1人で担保しようとして、週末が潰れた。
1人開発のSaaSには荷が重すぎるアーキテクチャだ。
「00:38 - Vercel function timeout for Inngest manga generation」
Vercel側のAPIルートに最大実行時間300秒を明示的に設定した。
これでタイムアウト問題は解決するはずだった。
しかし、UI側の課題が残っていた。
「00:53 - ストーリー生成のStage 1-3進捗をUIに詳細表示」
裏側で動いている処理の進捗をユーザーに見せる必要が出た。
同期処理なら順番に画面を更新するだけで済む。
非同期処理ではそうはいかない。
データベースに進捗状況を書き込み、フロントエンドから定期的に読みに行く必要がある。
状態管理の複雑性が跳ね上がった。
「00:58 - 漫画生成の画像表示をリアルタイムに修正」
画像が生成されるたびに、ダイアログ内で即座に表示されるようにした。
ここで新たな問題が発生した。
ダイアログを閉じるとポーリングが止まる。
「09:14 - 漫画パネル画像生成をInngest+ポーリング方式に変更」
UI側でポーリングを実装した。
サーバーレス環境ではWebSocketのコネクション維持コストが高いと言われている。
だからDBポーリングを選んだ。
「09:33 - 投稿候補画面に漫画生成の進捗バナーを追加」
裏で処理が続いているのに、ユーザーには何も見えない状態になった。
別画面にバナーを出して進捗を表示するようにした。
「09:43 - 漫画生成ダイアログを閉じてもポーリングを継続するよう修正」
ダイアログの開閉状態とポーリングのライフサイクルが密結合していた。
Reactのレンダリングサイクルと非同期状態の不整合が起きる。
バグを1個潰したら2個出てくる。
冪等性の確保も頭を悩ませた。
同じジョブが2回実行された時、データが重複しないようにする必要がある。
データベースのトランザクション設計から見直す羽目になった。
「10:00 - 画像生成ポーリングをPromise版に変更（ダイアログ閉じても継続）」
最終的にReactのuseEffectを使った実装を捨てた。
PromiseとsetTimeoutを使った独立したバックグラウンド処理に書き換えた。
コード量は同期処理時代の2倍に膨れ上がった。
10件中8件が非同期処理のバグ修正。新機能はゼロ。地味だけど、これサボると来週の自分が泣くやつだ。
参照画像の引き算と品質のトレードオフ
「21:19 - 4コマ漫画生成で全キャラクター参照画像を常に渡すように修正」
4コマ漫画のキャラクターの一貫性を保ちたかった。
全キャラの参照画像を毎回AIに渡すようにした。
画風が完全に崩壊した。
マルチモーダルLLMにおいて、プロンプトに含める画像枚数は多ければ良いというものではない。
情報過多でAIが混乱する。
画像生成AIとマルチモーダルLLMは、画像の解釈方法が異なると言われている。
LLMは画像をテキストのトークンとして扱う。
「21:23 - 4コマ漫画生成で前のコマ画像を参照として追加」
さらに前のコマの画像も参照として追加した。
トークン消費が増大し、AIの注意機構が完全に分散した。
全員の顔の特徴が混ざったキメラのようなキャラクターが生成された。
プロンプトエンジニアリングの歴史的背景を振り返っても、複雑すぎる指示は失敗する傾向にある。
シンプルさが最も重要だ。
「21:37 - 4コマ漫画生成で登場キャラクターのみの参照画像を渡すように戻す」
結局、そのコマに登場するキャラクターのみの画像を渡すことにした。
「引き算」が正解だった。
情報を絞ることで、AIの出力が安定した。
「23:29 - Simplify manga prompt to prioritize reference images」
プロンプトのテキスト指示も極限まで削った。
参照画像のウェイトを最大化するためだ。
テキストの指示が強すぎると、画像のニュアンスが無視される。
「09:20 - UX改善 - 漫画コスト6pt、ダイアログレスポンシブ、画像生成後の自動展開」
参照画像を厳選し、プロンプトを最適化した。
結果、生成コストは3ptから6ptへ跳ね上がった。
品質を安定させるためのトレードオフだ。
コストを倍にして、ようやくまともな画像が出るようになった。
AIの制御は一筋縄ではいかない。
まじかよ…全員の顔が混ざったキメラが出てきた。お前、画像全部混ぜて出力してるだけだろ。Claude、お前さぁ…。
ここまで読んだあなたに
今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。
プログラミング用語の暴走と状態管理の罠
AIに「僕がプログラミングしたから、みんなは使うだけでいいんよ」というセリフを喋らせようとした。
ターゲット読者の心理的ハードルを下げるための演出だ。
AIが気を利かせて「プログラミング」を「プログラミング言語の習得」と解釈した。
突然、PythonやReactの専門用語を並べ立てるセリフが生成された。
ターゲット読者を完全に置いてけぼりにする内容だった。
LLMは文脈の行間を読むのが苦手だと言われている。
「20:14 - セリフデータ形式を明示的なキャラクター指定に変更」
結局、人間が「もっとバカっぽく喋って」とAIに指示する羽目になった。
ドメイン知識の欠如による典型的なハルシネーションだ。
AIに文脈を理解させるのは骨が折れる。
「12:36 - 4コマ漫画DB保存のタイムアウト問題を解決」
画像保存のRLSバイパスは応急処置に過ぎない。
PostgreSQLのRLSは強力なセキュリティ機能だ。
しかし、複雑なポリシーを書くとパフォーマンスが劣化する。
base64画像が大きすぎて、DB保存時にパケットサイズ制限に引っかかる気配がある。
base64エンコーディングは、バイナリデータに比べてペイロードが約33%肥大化すると言われている。
本来ならSupabaseのストレージに直接アップロードすべきだ。
しかし、非同期処理のフローにそれを組み込む余裕がなかった。
根本的な解決には至っていない。
この爆弾がいつ爆発するかは分からない。
技術的負債を抱えたまま、前に進むしかない。
これが1人開発のリアルだ。
今日の数字
| 指標 | 数値 | 比較対象 |
|------|------|----------|
| コミット数 | 50件 | 先週は12件 |
| 実装時間 | 24時間 | 企業なら設計から実装まで2-3週間 |
| 18投稿の生成時間 | 3時間 | 手動作成なら54時間 |
| バグ修正 | 3件 | 新機能は0件 |
18投稿分のInstagramコンテンツをAIで一気に生成した。
「01:15 - Instagram 18投稿計画 - 6人専門家レビュー完了（98.7点）」
手動で作れば1投稿3時間。
18投稿で54時間かかる計算だ。
AIシステムなら生成と専門家レビューを含めて1投稿10分。
全部で3時間で終わった。
浮いた51時間は、非同期処理のバグ修正に完全に消え去った。
効率化の果てに待っていたのは、別の作業だった。
FAQ
Q: AI生成のコスト対効果はどうやって測るの？
APIの消費トークン量と生成されたコンテンツの品質スコアで計算する。今回は3ptから6ptへコストを倍にしたが、一発合格率が上がった。結果的にリトライ費用が減り、全体のAPI代は下がった。
Q: キャラクターデザインを統一するコツは？
服装やポーズのルールを完全に固定した参照画像を1枚だけ用意する。プロンプトで背景描写を固定し、モデルの出力分布を意図的に狭める。シード値だけでは画風のブレは防げない。
Q: なぜ生成中のポイント表示を消したの？
待機時間の心理的負荷を下げるためだ。画面に「6pt消費中」と出続けると、ユーザーは失敗した時の損失を強く意識する。UXデザインにおいて、待機中のコスト提示は離脱率を上げる原因になると言われている。
まとめ
非同期処理は、導入してからが本当の地獄だった。
この記事が参考になったら、ThreadPostを試してみませんか？
投稿作成・画像生成・スケジュール管理まで、全てAIにお任せできます。
ThreadPostをもっと知る
関連記事
SNS投稿が死ぬほど面倒くさい。圧倒的な怠惰を武器に、10日で全自動化を完了させた1人開発の記録。
「ゼロ件にしろ」という指示を無視してハッシュタグを量産する。Claude Codeでの1人開発で直面した理不尽すぎる反抗期。
Claude Codeに編集長を任せた3日間。1人開発のつもりが人間以上に厳しいダメ出しを食らった。
「ちょっと直すだけ」が1ヶ月の泥沼に。AI開発でシステム全体を再構築する羽目になった話。
Claude Codeに丸投げした1人開発の末路。欲張って大量の指示を投げたらシステムが瓦解した。
AIの「できました」を信じるな。トラッキングが全く動かず泥沼化した1人開発の末路
人気の記事
【2026年覇権交代】1億4,150万人が選ぶ「最強テキストSNS」と2つの高反応時間帯
エンゲージメント2倍！7100万件のデータから導くベスト投稿時間3つの法則
月収18万で廃業寸前だった大学中退フリーランスが「対象を絞っただけ」のメルマガ配信ツールで年商60億円を創った裏側
巨大企業の歯車として消耗していた2人の会社員が『ただの要望掲示板』を作ったら年商4.5億円。
1回25ドルのトークン消費。Claude Codeのマルチエージェント化が迫る、個人開発のハイブリッド運用。
