※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記です。
SNS運用を自動化しませんか？
ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。
AIが息を吐くように嘘をつく理由と、それを止める唯一の解決策
開発ログからXの投稿を自動生成するパイプラインを作った。
見事に僕っぽい文章が出てきたが、実装した覚えのない「月額決済機能」と「ユーザー数1万人突破」という数字が堂々と書かれていた。
AIが平気で嘘をつくから、それを止めるのに週末が溶けた。
結論から言うと、AIの自律性を信用するのをやめ、生成直後に別のAIモデルにファクトチェックさせる多段パイプラインを組むしかなかった。
一般的に、LLMはプロンプトで具体例を与えすぎると、事実の抽出ではなくパターンの模倣を優先する傾向がある。
「嘘を書くな」と指示しても、自己回帰型モデルの性質上、一度それっぽい文脈を生成し始めると止まらない。
だから僕は、生成ステップの直後に「お前が書いた数字、根拠ある？」と自分自身に問い詰めさせるセルフレビューステップを追加した。
これで捏造は完全に消滅した。
ただし、プロンプト調整で週末の予定は全て吹き飛んだ。
今週の全体像
コミットは36件だった。
新機能が2件で、バグ修正が1件だ。
今週はとにかくAIのハルシネーションとの戦いだった。
自動化で楽をするはずが、逆にAIの監視に時間を奪われるという本末転倒な状態からスタートした。
嘘つきAIとの終わらないいたちごっこ
「dev-logスレッド編集対応 + 「は？」多用問題修正」から作業を始めた。
AIが生成するテキストに「は？」という挑発的な言葉が多用される問題があった。
SNSのエンゲージメントを高めるためのフックとして、AIが勝手に学習してしまった結果だ。
最初はAIに僕の過去の投稿を例文として渡した。
すると、毎回同じタイトルの投稿が生成されるようになった。
AIは例文のパターンを完全にコピーして、考えることを放棄した。
だから僕は「フックプロンプトから具体例を完全削除 — 原理のみで毎回考えさせる」というコミットを入れた。
例文を消すと、今度はAIが暴走し始めた。
存在しない機能を実装したことになり、APIの応答速度が勝手に0.1秒に改善されていた。
「dev-logプロンプトのフック例文を抽象化 — AIが例文をそのまま使う問題を防止」をプッシュした。
さらに「dev-log生成の嘘防止ルール追加 + 画像生成改善」も入れた。
それでもAIは息を吐くように嘘をついた。
「AIレビューステップ追加（Geminiセルフレビュー＋ファクトチェック）」を実装した。
パイプラインにStep 6.8を追加した。
生成直後に、Gemini自身にチェックリストを渡してファクトチェックさせる仕組みだ。
「お前が書いた数字、根拠ある？」と自分自身に問い詰めさせる。
これで生成品質スコアが目標の95/100に安定した。
しんたろー:
まじかよ…プロンプト調整に4時間溶けた。最初からセルフレビュー組めばよかったわ。AIの出力は信じない方が早い。
「dev-logスケジュールを1日5投稿に増加（06:00, 10:00, 14:00, 18:00, 22:00）」に変更した。
Xのタイムラインが最も活発になる時間帯を狙い撃ちにした。
エンゲージメントのデータを集めるための布石だ。
「タイトル40文字制限 + プレビューにコピーボタン追加」を実装した。
タイムライン上で「続きを読む」を押させずに、一目で内容を伝えるための制約だ。
その後、文字数の調整を何度も繰り返した。
「タイトル45文字以内（X記事は日本語1文字=2カウント、上限100）」に変更した。
XのAPIは、全角文字を2カウント、半角文字を1カウントとして計算する仕様になっている。
しかし、URLやメンションが含まれると、この計算ルールが複雑に変化する。
「タイトル文字数制限を50〜60文字に修正」と試行錯誤が続いた。
最終的に「タイトル文字数を48〜50文字（100カウントギリギリ）に変更」で落ち着いた。
「タイトル生成プロンプトにXの正確なカウントルールを反映（95-100狙い）」をプッシュした。
「トミー式X記事タイトルの目標文字数を85カウントに変更」でさらに微調整した。
95〜100カウントだと長すぎたためだ。
Xの文字カウント仕様はAPIのドキュメント通りに動かないからしんどい。
圧倒的なコスト削減とUIの最適化
嘘つきAIの調教が終わった後、スレッドモードのUI改善と画像生成に着手した。
「dev-logスレッドモード対応 — 2パート自己リプライ生成+サムネ画像」を実装した。
SNS Tips記事の画像生成には、これまでGemini 3 Proを使っていた。
品質は申し分ないが、大量に生成するとコストが重くのしかかる。
「Nano Banana 2 (gemini-3.1-flash-image-preview) 画像生成モデル追加」をコミットした。
Flash系の軽量モデルへの切り替えだ。
一般的に、モデル蒸留の技術が進化したことで、タスク特化型であれば軽量モデルでも十分な品質が出せるようになっている。
プレビューやサムネ作成のような定型的なクリエイティブに、高コストなProモデルは過剰だ。
APIのレスポンス形式が違って、画像URLのパースエラーで画面が真っ白になった。
JSONの構造定義をFlash系モデルの仕様に合わせてパーサーを書き直した。
結果として、品質を維持したままコストが半額になった。
なお、浮いたお金は別のAPI課金に消える予定だ。
「dev-logスレッドモードの画像UI改善 — 即時反映+バツボタン+重複解消」でUXも整えた。
「dev-logサムネ画像を4:5縦長に変更（Xタイムラインで目立つように）」も追加した。
一般的に、縦長画像はタイムラインの占有面積が大きく、スクロールを止める効果が高いと言われている。
ProからFlashに変えたけど、画質の違い全然わからん。今まで高い金払ってたの何だったんだ。
「dev-logサムネ画像にキャッチコピー生成ステップを追加」も実装した。
Gemini Flashで10-15文字のキャッチコピーを生成してから画像に入れるようにした。
画像のインパクトを最大化するためだ。
「画像保存をfetch+Blobダウンロードに変更（クロスオリジン対応）」もプッシュした。
外部URLの画像を安全に保存するための対応だ。
「dev-log thread_parts null→undefined 型エラー修正」などの細かいバグも潰した。
「サイドバーにSNS Tips記事リンク追加」も入れた。
管理画面のナビゲーションを改善した。
「SNS Tipsサムネ生成をNano Banana 2 + 21:9直接出力に更新」も完了した。
前回コミットから漏れていたファイルを追加した。
「トミー式X記事ネタ元URL自動収集パイプライン」も構築した。
tommy_source_poolテーブルを新設した。
RSS自動収集cronを日本時間の深夜3時にセットした。
Starter StoryやIndie Hackersから新着を取得し、Gemini Flashでプレスクリーニングする。
「SNS Tips管理画面にソース収集ボタン追加」も入れた。
管理画面から手動でソースを収集できるようにした。
「SNS Tipsソース収集のバッチ上限を10に引き上げ（全件処理）」も対応した。
バッチ処理の上限を引き上げて効率化した。
「insertImagesIntoMarkdown にフォールバック追加（SNS Tips記事対応）」も入れた。
見出し構成がイレギュラーでも画像が挿入されるようにした。
「プレビューHTMLにタイトル(h1)を表示」も追加した。
管理画面のプレビューでタイトルを確認できるようにした。
「ブログシステム全面改善 — SEO・セキュリティ・パフォーマンス・管理機能」も一気に進めた。
3ラウンドのエキスパートレビューで発見された全指摘を修正した。
RLSの再有効化を行った。
users.is_adminベースのポリシーを5つのテーブルに適用した。
一般的に、SaaSのようなマルチテナント環境では、データベースレベルでのアクセス制御が必須となる。
アプリケーション層のバグで他人のデータが漏洩するのを防ぐためだ。
複合インデックスとGINトライグラムインデックスも追加した。
データベースの検索パフォーマンスを底上げするためだ。
PostgreSQLのTrigramインデックスは、文字列を3文字の連続に分割してインデックス化する。
これにより、日本語のような単語の境界が曖昧な言語でも、高速なあいまい検索が可能になる。
「ブログ詳細ページ — 目次をデフォルト展開 + excerpt重複表示を削除」も対応した。
モバイル目次のdetailsタグにopen属性を追加しただけだ。
ユーザーの直帰率を下げるためのUI改善だ。
記事の全体像を最初に提示することで、読了率の向上が期待できる。
「ブログ表示改善 — サムネ画質・引用HTML・アイコン重複修正」もプッシュした。
サムネにunoptimizedを追加して画質劣化を防いだ。
Next.jsのImageコンポーネントの最適化プロセスが、逆に画質を劣化させていたためだ。
「X記事→ブログ自動公開パイプライン完成 + タグ自動生成」も実装した。
記事内容からトピックベースのタグを自動生成する仕組みだ。
コンテンツの再利用性を高めるための重要なマイルストーンだ。
SaaSやメルマガ、ブートストラップ起業などのタグが自動で付与される。
SEOキーワードもタグベースに改善した。
「ブログ記事にLP OGP画像CTAを追加 + 著者情報修正 + タグ最適化」も完了した。
GeminiでLP OGP画像を12枚生成し、記事末尾にランダムCTAとして配置した。
記事を読んだユーザーを、自然な流れでLPに誘導するための導線設計だ。
「ブログ管理機能の完成 — 編集ページ・MarkdownEditor・CRUD・サイドバー」も実装した。
MarkdownEditorコンポーネントを作成し、ツールバー11種を組み込んだ。
「ブログレイアウトを940px幅に変更 + サイドバー240px化」でデザインを整えた。
コンテナの最大幅を1152pxから940pxに縮小した。
「ブログ記事サムネのobject-cover/aspect制約を除去」も対応した。
画像自体が21:9なので、w-fullだけで正しく表示される。
ここまで読んだあなたに
今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。
落とし穴：僕、僕、僕の怪文書生成器
AIに「しんたろー」というキャラクターを完璧に演じさせようとした。
「dev-logプロンプトを全面改訂 — しんたろーのキャラクター強化」をプッシュした時のことだ。
AIが「僕」という一人称を使いすぎて、まるでナルシストの自伝のような投稿ばかり生成するようになった。
一般論化を防ぐために「僕」を最低2回使用するルールを追加したのが原因だ。
ルールを追加したら、今度はAIが「僕、僕、僕」と連呼する怪文書生成器になってしまった。
慌ててプロンプトを修正し、感情表現のバランスを整える羽目になった。
一般的に、ペルソナ設定を細かく指示しすぎると、AIの推論能力が低下する現象が知られている。
これを防ぐには、制約を減らして自然な文脈生成に任せるしかない。
キャラ設定細かくしたらAIがアホになった。Persona-driven degradationとかいうやつ、完全にこれだわ。
今日の数字
| 項目 | 数字 | 比較 |
|---|---|---|
| 総コミット数 | 36件 | 先週の1.5倍のペース。 |
| ファクトチェック実装 | 120分 | 企業開発ならQAチームによる検証で2週間。 |
| 画像生成コスト | $0.067 | 従来モデルなら$0.13以上。 |
一般的に、Flash系モデルのコストは、Proモデルと比較して約半分以下になることが多い。
スケーリング時の経済的優位性が圧倒的だ。
浮いたコストで他の実験ができる。
FAQ
Q: Nano Banana 2導入によるコスト最適化の具体的な計算根拠は？
従来モデルの単価は1枚あたり0.13ドルだったのに対し、Nano Banana 2は0.067ドルで約48.4%のコスト削減になる。月間3000枚生成する場合、189ドルの経費浮きが発生する計算だ。浮いた経費は別のAPI検証に回す予定だ。
Q: 画像生成モデル切り替え時に発生したパースエラーの具体的な原因は？
APIのレスポンス形式が一部異なり、ネストされたJSONから画像URLを抽出するロジックが空振りを起こしていた。JSONの構造定義をFlash系モデルの仕様に合わせてパーサーを書き直す必要があった。修正自体は15分程度で完了した。
Q: ブログのGINトライグラムインデックス追加による具体的な効果は？
記事タイトルや本文のあいまい検索において、シーケンシャルスキャンを回避できるようになった。一般的に、数万件のテキストデータ検索においてクエリ応答時間が数十ミリ秒単位まで短縮される。Supabaseのコンピュート使用量も目に見えて低下した。
まとめ
AIの出力を疑う仕組みを作ったら、ようやく使い物になった。
自動公開パイプラインは稼働し始めたが、画像のクロスオリジン問題がまだ完全に解決していない。
一部のRSSソースから取得した画像が、保存時に弾かれることがあるから、次はプロキシを挟むか別の回避策を考える。
この記事が参考になったら、ThreadPostを試してみませんか？
投稿作成・画像生成・スケジュール管理まで、全てAIにお任せできます。
ThreadPostをもっと知る
関連記事
人気の記事
【2026年覇権交代】1億4,150万人が選ぶ「最強テキストSNS」と2つの高反応時間帯
【2026年版】1人SaaS開発で月10万円稼ぐ5ステップ｜AI活用エンジニアの完全ロードマップ
エンゲージメント2倍！7100万件のデータから導くベスト投稿時間3つの法則
【313億円調達】留学生が北米SaaSを制圧。巨人が捨てた「チップ計算」の痛みを独占せよ
月収18万で廃業寸前だった大学中退フリーランスが「対象を絞っただけ」のメルマガ配信ツールで年商60億円を創った裏側
