AIの自分語りにブチ切れ。プロンプトを捨ててコードで強制排除した話（Claude Code開発日記）

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

「1人でSaaSを作っている僕からすると、今回のJCBのニュースは……」

画面に表示されたAIの投稿案を見て、僕は頭を抱えた。ニュースの内容はJCBの情報流出だ。それに対してAIが生成したリプライがこれだ。誰もJCBの話を聞きたいのであって、お前の「SaaS開発者としての自分語り」なんて1ミリも求めていない。直近20件の投稿を調べたら、19件がこの自分語りに染まっていた。成功率わずか5%。AIの「自分語りドリフト」という挙動に、僕の堪忍袋の緒が切れた。

AIの「性格」と戦い続けた1週間

今週は、AIの出力品質を人間レベルまで引き上げるために、泥臭い調整を繰り返した。AIに「ウィットに富んだ投稿をして」と頼めば無難な優等生発言を連発し、「トレンドに反応して」と頼めば隙あらば自社製品の宣伝をねじ込んでくる。プロンプトを2,500字まで太らせても、AIは指示の後半を平気で無視した。結局、プロンプトエンジニアリングという魔法の言葉を捨て、コードによる物理的なガードレールを実装した。

今週のサマリー：

• 総コミット数：22件
• 新機能：5件（ウィット投稿自動化、連携顧客リプ等）
• バグ修正：8件（字幕ズレ、自分語り排除等）
• 壊れた回数：12回
• 削減したコスト：API代を約80%カット

今週の僕は、AIを便利なツールとしてではなく、言うことを聞かない新人編集者として教育し直すことに全ての時間を溶かした。

AIの「自分語り」を物理的に殺すガードレール実装

SNSの自動投稿システムを作っていると、AIのサービス精神が仇になる。AIに投稿案を作らせると、頼んでもないのに「僕が」「ThreadPostの開発では」と自分語りの低品質な文章を混ぜてくる。これを業界ではドリフト現象と呼ぶ。プロンプトが長くなるほど、LLMは注意力を失い、学習データに大量に含まれる自己紹介のパターンに引きずられていく。

最初は「自分語りは禁止」とプロンプトに10回書いた。だがClaudeもGeminiも、3日もすれば「1人で開発している僕としては」と元気に語り始める。人間だって校則を厳しくするほど破りたくなる。AIも同じだ。だから僕は、プロンプトで説得するのをやめて、コードで物理的に排除した。

実装したのは「feat(threads-guard): 自分語りドリフトの投稿前ガード追加」だ。仕組みはシンプルだ。AIが生成したテキストを投稿する直前に、detect-self-promo-drift.ts というバリデーターを通す。「自作のSaaS」「僕も開発に」「ThreadPostでは」といった一人称のコロケーションを検出したら、その場で投稿を却下する。

1. AIがテキストを生成する。
2. ガードレールが自分語りを検知する。
3. AIに書き直しを命じる。
4. 3回リトライしてダメなら、その投稿候補ごとゴミ箱に捨てる。

この出力後の物理フィルタを入れた瞬間、SNSのタイムラインからノイズが消えた。プロンプトでお願いするより、コードで消すと決める方が100倍確実だ。開発の仕事は、もうコードを書くことじゃなく、AIの書いちゃいました報告を一切信じずにフィルターをガチガチに組むことにシフトしている。

しんたろー:
過去14件の引用投稿を監査したら、全部に自分語りが入ってた。相手が娘の運動会の話をしていようが「最強のデバッグ」とか返してた。恐怖すら感じる。AIの善意は、時に毒になる。

さらに、格上のアカウントを引用する際のポエム化も深刻だった。「○○が問われる時代ですね」といった、中身のない抽象論評だ。これを直すために「fix(others-quote): 格上引用のポエム退治」をコミットした。2,500文字の巨大な指示書を捨て、わずか100文字程度の「相手の発言の美味しい一点を増幅しろ」という専用プロンプトに差し替える分岐を作った。指示が短いほど、AIは迷わない。

落とし穴：Whisper字幕生成の「幽霊字幕」を退治した泥臭い戦い

AI動画生成において、字幕は命だ。だが、Whisperで生成した字幕には「喋っていないのに文字が消えない」という致命的なバグがあった。セリフが2秒で終わっているのに、次の発話まで20秒空く無音区間でも、前の字幕がずーっと画面に居座り続ける。視聴者からすれば、動画と音声がズレているようにしか見えない。

最初はAIに「無音を検知して字幕を消せ」とプロンプトで指示していた。だが、AIは裏で平気で嘘をつく。タイムスタンプの計算をAIに丸投げした結果、冒頭の3.7秒から喋り始める動画なのに、0.0秒からフライングして字幕が出る始末。Whisperを適当に回せばそれっぽい字幕ができるという幻想は、実装初日で崩れ去った。

原因は、Whisperを --output_format srt で実行した際の仕様にあった。Whisperは、セグメントの開始時刻を発話前の無音区間まで食い込ませて、00:00:00に丸める癖がある。さらに、SRT形式では文字数で時間を均等割りして表示タイミングを推定するため、1セグメント内で単語が離れていると、後半の文が実発話より早く出てしまう。

僕は「fix(subtitle): 文分割を単語時刻ベースに再設計 + Whisper を large-v3-turbo に」をコミットし、字幕パイプラインを根底から書き換えた。

• large-v3-turbo への移行：推論速度を上げつつ、単語単位のタイムスタンプ精度を確保。
• JSON出力の採用：SRTという丸められたデータを捨て、ミリ秒単位の生データを取得。
• MAX_HOLD_DURATION の導入：無音区間での字幕延長に、コード側で強制的に上限を設けた。

AIに丸投げして、それっぽいものを作るのは一瞬だ。だが、こういう細かいズレを人間が泥臭く潰さないと、プロダクトとしての品質にはならない。僕はそれ以来、時間データだけはAIの出力を1ミリ秒も信用しない。AIは物語を作るのは得意だが、計測をさせると途端に嘘つきになるからだ。

しんたろー:
3.7秒開始のセリフが0.0秒から表示される。視聴者はバグってると一瞬で判断して離脱する。AI開発の8割は、AIがついた嘘の後始末でできている。

今日の数字

| 項目 | 今回の数値 | 比較・業界標準 |

| :--- | :--- | :--- |

| APIコスト（100万トークン） | $0.25 | 以前は $1.287。約80%のコスト削減。 |

| 自分語り投稿の発生率 | 0% | ガードレール実装前は 95%。 |

| 字幕のタイミング精度 | ±10ms以内 | Whisperデフォルトでは 数秒単位 のズレが常態化。 |

| リプライ上限数 | 1日15件 | 以前は 6件。運用実績を元に安全圏を拡大。 |

| 実装時間（字幕再設計） | 約2時間 | チーム開発なら要件定義含め 2週間 はかかる重改修。 |

FAQ

Q: なぜGeminiのコストが隠れコストになってしまったのですか？

A: 3つのファイルで共通のコスト記録関数を通さず、直接APIを叩いていたためです。APIクライアントをラップする共通関数を徹底しないと、ログ基盤にデータが飛ばず、請求書を見るまで消費量が可視化されません。

Q: Whisperの単語時刻抽出の具体的なメリットは何ですか？

A: SRT形式の均等割りを回避し、実際の発話タイミングと字幕をミリ秒単位で同期できる点です。これにより、無音区間での字幕の居座りや、冒頭のフライング表示を物理的に防げます。

Q: 複数SNSでガード処理を共通化する際の設計パターンは？

A: SNSに依存しない純粋関数として集約しました。スパム判定や品質チェックのロジックを1箇所にまとめることで、片方のSNSで修正したガードを即座にもう片方にも適用できます。

まとめ

今週学んだのは、AIは信じるものではなく疑って、囲い込んで、強制するものだということ。プロンプトエンジニアリングという名の「お願い」に時間を溶かすなら、その10分の1の時間で検知と排除のコードを書いたほうがいい。AIに自由を与えていいのは、それが遊びの時だけだ。SaaSとして金を稼ぐなら、AIの首輪は人間がガチガチに締め上げる必要がある。

さあ、AIの自分語りにイライラするのはもう終わりだ。次は、この調教済みAIを使って、SNSのタイムラインを僕らの色に染めていく番だ。

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