※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記です。
SNS運用を自動化しませんか?
ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。
直したはずが別の場所で崩壊する無限ループ
直した。崩れた。直した。また崩れた。これを20回繰り返した。
画面のプログレスバーを直すと、隣の画像グリッドの高さが狂う。

グリッドの表示を直すと、今度は参考画像のサムネイルが消滅する。
サムネイルを復活させると、プレビュー画面が開かなくなる。
どこかを直すたびに、別の場所が連鎖的にぶっ壊れていく。
AIコーディングは爆速だと思っていたが、現実は無限モグラ叩きだった。
Reactのコンポーネントツリーは複雑だ。
親要素のFlexboxの設定をAIがいじると、子要素のレイアウトがドミノ倒しのように崩壊する。
Tailwind CSSのクラス名が長くなりすぎると、AIは文脈を見失う。
画面の右端の余白を直すために、左端のボタンを画面外に吹き飛ばしてくる。
人間なら絶対にやらないような、空間認識の欠如した修正を平気でコミットしてくる。
その尻拭いをするのは、結局人間の僕だ。
完璧な設計図がゴミに変わるまでの今週の全体像
画像生成ダイアログの大規模な改修に取り組んだ。
複数の画像を管理し、参考画像をもとに新しい画像を生成する機能だ。
Gemini 1.5 ProのAPIを叩き、プロ写真品質の画像を生成するパイプラインを構築しようとした。
マルチモーダルの力を借りて、ユーザーの投稿画像をベースにバリエーションを無限生成する計画だった。

結果として、44日間新しい機能はリリースできていない。
AIへの指示範囲を間違えると、システム全体が崩壊する。
- 総コミット数: 40件
- 新機能: 0件
- バグ修正: 3件
- 壊れた回数: 計測不能
画像をBase64でエンコードして送るか、URLで渡すかのアーキテクチャ設計から始まった。
フロントエンドの非同期処理と、バックエンドのジョブキューが複雑に絡み合う。
AIはコードを大量に書いてくれる。
しかし、そのコードが本番環境で動く保証はどこにもない。
Gemini APIのネスト構造とプロンプトエンジニアリングの沼
「参考画像付きAI画像生成機能の設計ドキュメント追加」から始まった。
機能要件、ユーザーフロー、UI配置を定義した。
モデル別の対応状況も調査し、実装設計を詳細化した。
「参考画像付きAI画像生成機能を実装」をコミットした。
Gemini 1.5 ProとImagen 3を使って、参照画像APIを叩く。
既存の投稿候補画像を参考画像として選択できるようにした。
ローカル画像のアップロードにも対応した。
ただし、アップロード中のローディングスピナーはまだ回らない。
しんたろー:
まじかよ…1時間で設計、30分で実装完了。企業なら2週間かかるやつだ。AI最高じゃんって、この時は本気で思ってた。
ぶっ壊れた。
「Gemini 1.5 Pro Image APIのaspectRatio設定を修正」というコミットが全てを物語っている。
Google AI StudioのAPIが未知の名前だというエラーを吐き続けた。
ドキュメント通りにパラメータを渡しているのに、APIがリクエストを弾く。
原因は単純だった。
アスペクト比の設定場所が、画像設定オブジェクトの中にネストされていた。
パラメータの階層が1段深かっただけだ。
TypeScriptの型定義をサボっていたため、コンパイル時にはエラーが出ず、実行時に初めて落ちた。
この1行の修正を見つけるのに3時間を溶かした。
さらに地獄はプロンプトエンジニアリングで待っていた。
「配置変更プロンプトに自然な微細変化を追加」しようとした。
皿やカップの向きを微妙に回転させ、食材の溶け方や垂れ方に自然な差異を出したかった。
「配置を変えて」と指示した。
結果、料理の皿ごと別の食べ物にすり替わった。
「元の画像を参考にして」と強く指示した。
今度は全く同じ画像を出力してきた。
「配置も変えるモードにカメラアングル変更も追加」し、プロンプトを大幅に強化した。
具体的な配置変更指示として、左右の入れ替えや90度から180度の回転などを明記した。
違うレストランで撮った写真という比喩まで使って期待値を明確化した。
それでも安定しない。
「配置も変えるモードにプロ写真品質の指示を追加」した。
浅い被写界深度、美しいボケ、プロのスタジオ照明、シネマティックな色調を要求した。
しんたろー:
プロンプトの試行回数は40回を超えた。1回生成するのに15秒かかる。10時間ぶっ通しで画像を見比べ続けた。API代だけがチャリンチャリンと溶けていく。
最終的に配置変更とアングル維持を分離した。
「角度だけ変えるモードで元の構図を維持するよう修正」し、クローズアップ指示を削除した。
広角なら広角、クローズアップならクローズアップを維持するようにした。
プロンプトの微調整だけで、休日の半分が消えた。
ここまで読んだあなたに
今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。
落とし穴:SupabaseのRLSが引き起こした恐怖のサイレント失敗
画像生成の裏側で、もう一つの沼が進行していた。
「generation_jobsテーブルにUPDATE権限を追加してプログレスバーを修正」というコミットだ。
プログレスバーを動かすだけの簡単な作業のはずだった。
ジョブのステータスをデータベースに保存し、クライアント側でポーリングして進捗を表示する。
Supabaseを使えば、リアルタイムリスナーで一瞬で終わると思っていた。
実際には、APIからのステータス更新が完全に無視されていた。
エラーは出ない。
ただ、データベースの値が更新されない。
「Inngest関数内のSupabaseクライアント作成を改善して進捗更新を修正」を試した。
サーバーサイドの非同期処理でデータベースのクライアントを使い回すと、トークンの期限切れが起きる。
関数ごとにインスタンスを再生成するように変更した。
それでも動かない。進捗バーは0%のままピクリともしない。
原因はデータベースの行レベルセキュリティ(RLS)だった。
しんたろー:
エラー出ないのまじでやめてくれ。システムは「成功しました!」って顔してるのにDB空っぽ。非同期処理のデバッグ、ログ仕込まないと完全に詰むわこれ。
セキュリティポリシーに更新権限が欠落していた。
管理者権限を持たないクライアントサイドの処理で更新しようとすると、権限がなくてもエラーを返さない。
単に0行更新しましたという結果が返ってくるだけだ。
これをサイレント失敗と呼ぶ。
PostgreSQLのポリシー構文は強力だが、設定を間違えるとデバッグが極めて困難になる。
マイグレーションファイルを追加して更新ポリシーを設定した。
これでようやくAPIからステータスを処理中に更新できるようになった。
たった1つの権限設定を見落としただけで、半日を無駄にした。
AIのコンテキスト崩壊が招いたUIコンポーネントの連鎖崩壊
Claude CodeにUIを綺麗にしてと指示した。
画像生成ダイアログのスタイルグリッドが、スマホで見ると画面いっぱいになっていた。
下の生成ボタンに到達できない問題があった。
「AI画像生成ダイアログのスタイルグリッド高さをスマホで縮小」するためだ。
画面の高さが固定値でハードコーディングされていた。
直すためにここをこうしてと指示を出した。直った。
しかし今度は別の場所が崩れた。
Tailwind CSSのクラスを追加・削除する際、親要素の文脈を無視して子要素だけを修正してきた。
プログレスバーを直したらグリッドの高さが狂う。
グリッドを直したらサムネイルが消える。
200Kトークンのコンテキストがあっても、直近のプロンプトに引っ張られる。
初期の制約条件を忘れて、目の前のDOM要素だけをいじり回す。
次からは変更範囲を小さく区切って指示する。たぶん。
このコンポーネントだけ、この関数だけと。
1回の指示で触らせる範囲を絞ったら、連鎖崩壊がほぼ止まった。
僕がもっと早くそうしていれば、20回ではなく5回で済んでいた。
今日の数字:開発コストとAI依存度の現実
今週の開発データをまとめる。
| 項目 | 今回の数値 | 比較対象 |
|---|---|---|
| 総コミット数 | 40件 | 先週は12件。無限モグラ叩きの証拠。 |
| 開発時間 | 10時間 | 企業で画像生成統合とUI構築なら2〜3週間。 |
| API費用 | 約15ドル | 外部の画像生成SaaSを契約すれば月額30〜50ドル。 |
| 実装コスト比率 | AI生成10% | 人間による修正・デバッグ90%。 |
AIによるコード生成は、人間が書くより5倍速い。
しかし、デバッグ時間は人間が書くより3倍かかる。
最初のモックアップは一瞬でできる。
ただし、そこから本番品質に引き上げるための最後の10パーセントに、全体の90パーセントの時間を奪われる。
APIのパラメータ階層の修正。
データベースのサイレント失敗のデバッグ。
連鎖崩壊するUIの修復。
これらはすべて人間が泥臭くログを追いかけ、ドキュメントを読み込んで解決した。
500行のコードを一瞬で生成した。
その代償として、5行のバグを直すための終わらない徹夜が待っていた。
AI画像生成実装に関するFAQ
Q: なぜDALL-E 3は非対応にしたの?
参照画像APIの仕様がGemini 1.5 Proと大きく異なり、統合コストが跳ね上がる。モデルごとにAPIのインターフェースが異なるため、共通化しようとすると抽象化層が肥大化する。今回はGeminiの性能を最大化するという優先順位に基づき、あえて非対応として警告を出す判断をした。
Q: 画像生成の待ち時間のUXはどう工夫した?
生成に15秒以上かかるため、単なるスピナーではなく段階的なプログレスバーを実装した。バックグラウンドのInngestジョブからSupabase経由でステータスを細かくクライアントに通知している。ユーザーが途中で離脱しても、裏で生成が継続される仕組みにした。
Q: 無料プランに透かしを入れる技術的な難しさは?
生成後の画像データに対して、サーバーサイドでオーバーレイ処理を行う必要がある。クライアント側で処理するとユーザーに透かしを簡単に消されてしまう。今回は生成パイプラインの最終段に、12パーセントのサイズで10パーセントの不透明度の透かしを右下に合成する処理を組み込んだ。
モグラ叩きしながら作った画像生成機能、試してみて。

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