改稿したら点数が下がる悪夢→自動で戻す仕組みで解決した話

📖 読了目安: 約7分

「AIに記事を書き直してもらったら、85点が75点に下がった…」

以前、記事を採点して自動改稿する仕組みを試したとき、この悪夢のような現象に遭遇しました。開発ログのタイトルが改稿後に逆に悪化し、どう直せばいいのか見当もつかず、結局その仕組み全体をいったん諦めたのです。

でも今回、シンプルすぎて当時は思いつかなかった解決策を実装しました。「改稿前と改稿後で点数を比較して、下がっていたら自動で元に戻す」――たったこれだけのことが、なぜあのとき思い浮かばなかったのか。今回はその実装の記録と、動画制作で遭遇した予想外のトラブルをまとめます。

改稿したのに点数が下がる悪夢――以前の失敗

以前、記事の品質を自動で採点して、点数が足りない部分をAIに書き直してもらう仕組みを試したことがありました。このとき困ったのが「改稿したのに、逆に点数が下がってしまう」という現象でした。

具体例を挙げます。ある開発ログ記事のタイトルを改稿したとき、こんな変化が起きました:

• 改稿前(85点): 「記事を自動で『編集長視点で採点』させた2日間の試行錯誤」
• 改稿後(75点): 「AI編集長による記事採点システムの実装記録」

改稿後のタイトルは確かに簡潔になりましたが、「2日間の試行錯誤」という具体性が失われ、読者の関心を引く力が弱まってしまったのです。採点プロンプトでは「具体性」「読者の興味を引く要素」を重視していたため、結果として点数が下がりました。

このような「改稿して悪化する」ケースが何度か発生し、原因をすぐに直せる見込みが立たず、そのときはいったんこの仕組みに見切りをつけていました。正直なところ、かなり悔しい思いをしました。せっかく時間をかけて作った仕組みが、かえって品質を下げてしまうのですから。

シンプルすぎて当時は思いつかなかった解決策

数週間が経ち、あらためてこの問題に向き合ったとき、ふと思いついたのが「改稿前と改稿後でスコアの合計を比較して、もし下がっていたら自動で改稿前の状態に戻す」という方法でした。

実装は驚くほどシンプルです:

# 改稿前のスコア合計を保存
before_score = sum(scores.values())

# 改稿を実行
revised_content = revise_content(content, feedback)

# 改稿後のスコアを取得
after_scores = evaluate_content(revised_content)
after_score = sum(after_scores.values())

# スコアが下がっていたら元に戻す
if after_score < before_score:
    content = original_content  # 改稿前に戻す
    log("改稿後スコアが低下したため元に戻しました")
else:
    content = revised_content
    log("改稿によりスコアが改善しました")

なぜ以前はこの単純な解決策が思いつかなかったのか。当時は「AIの改稿が必ず改善をもたらすはず」という思い込みがあり、「改稿が失敗する可能性」を想定していなかったのです。また、「改稿プロンプトを改善すれば解決できるはず」と複雑な方向に考えすぎて、この単純な防御策に気づけませんでした。

実際に動かしてみると、改稿後のほうがスコアが低ければ自動で元に戻るようになり、安心して採点→改稿の流れを使えるようになりました。コミットメッセージには「Add score comparison before accepting revisions」と記録しています。

スコア380点→445点の内訳――動画台本への応用

この「採点して、必要なら1回だけ書き直す」というやり方が記事でうまくいくようになったので、今度はYouTube Shorts用の動画の台本にも同じ仕組みを応用してみました。

動画の台本は、8つの項目で採点しています(各項目100点満点、合格ライン60点):

1. 最初の3秒の引き(視聴者を掴む力)
2. 内容の価値(学びや気づきがあるか)
3. ストーリーの流れ(論理的なつながり)
4. 字幕の読みやすさ(一文が短く簡潔か)
5. 視覚的な変化(画像や演出の指示)
6. 感情の起伏(淡々としていないか)
7. 具体性(抽象的でないか)
8. 締めの強さ(行動を促す終わり方か)

実際にテストしてみた結果がこちらです:

8項目すべてが合格ラインに届いたわけではありませんが(特に「締めの強さ」は逆に1点下がっています)、全体としては65点の改善が確認できました。これは記事だけでなく、動画の台本にも同じ考え方が使えることを示す重要な結果でした。

改稿前後の台本の具体例を一部紹介します:

改稿前(最初の3秒部分、45点):
「今日は投資ブログをAIで自動化する方法についてお話しします」

改稿後(58点):
「AIにブログを任せたら、記事が勝手に悪化した…どうする?」

改稿後は具体的な問題提起になり、視聴者の「え、何それ?」という好奇心を引き出す構造に変わりました。数字として改善が確認できたのは今回が初めてで、正直ホッとしました。

動画を再生した瞬間の「あれ?」――音ズレの発見

動画の改善作業を進める中で、実際に動かしてみて初めて気づいたトラブルが2つありました。1つ目は、音声に短い間(ま)を挿入するようにしたら、その分だけ音声と字幕の表示タイミングが少しずつずれていく問題です。

生成された動画をダウンロードして再生した瞬間、違和感に気づきました。「あれ? 字幕の出るタイミングが遅い…?」最初は気のせいかと思いましたが、動画が進むにつれて音声と字幕のズレがどんどん大きくなっていきます。30秒の動画の終盤では、音声が終わってから1秒近く遅れて字幕が表示される状態でした。

原因を探るため、まず音声生成部分のコードを確認しました:

# 文章の終わりに250ms、セグメントの区切りに450msのポーズを挿入
for i, segment in enumerate(segments):
    audio = generate_speech(segment.text)
    if segment.is_end_of_sentence:
        audio += silence(250)  # 250msのポーズ
    if i < len(segments) - 1:
        audio += silence(450)  # 450msのポーズ

次に、字幕のタイミング計算部分を見ると、問題が見えてきました:

# 改修前(ポーズを考慮していない)
for segment in segments:
    duration = len(segment.text) / average_chars_per_second
    subtitles.append({"start": current_time, "end": current_time + duration})
    current_time += duration  # ←ポーズの時間が抜けている!

字幕の表示タイミングを計算する部分で、このポーズの長さを反映し忘れていたのです。結果、動画が進むにつれて音声と字幕がどんどんズレていくという、見ていて気になる状態になってしまいました。

修正では、ポーズの長さを差し引いた実際の発話時間から、各字幕の表示区間を計算し直す処理に置き換えました:

# 改修後(ポーズを考慮)
for i, segment in enumerate(segments):
    speech_duration = len(segment.text) / average_chars_per_second
    pause_duration = 0
    if segment.is_end_of_sentence:
        pause_duration += 0.25
    if i < len(segments) - 1:
        pause_duration += 0.45
    
    subtitles.append({
        "start": current_time,
        "end": current_time + speech_duration
    })
    current_time += speech_duration + pause_duration

この修正をコミット(「Fix subtitle timing by including pause durations」)した後、動画を再生すると、音声と字幕がピッタリ合うようになりました。あの違和感が消えた瞬間の安堵感は、今でも覚えています。

関連記事

• 記事を自動で「編集長視点で採点」させた2日間の試行錯誤
• AIに「単語の途中で改行しないで」と頼んだら、AIが解決策を出してきた話
• ショート動画自動生成の舞台裏|字幕はみ出しと見出しデザインの試行錯誤

今回の開発で得られた学びをまとめます。

• 「改稿したのに悪化する」問題は、改稿前後でスコアを比較して自動で戻す仕組みで解決――シンプルすぎて当時は思いつかなかった
• 動画台本でスコアが380点→445点に改善。特に「内容の価値」は52点→62点、「具体性」は55点→63点と大きく向上
• 音ズレ問題は、ポーズの時間を字幕計算に反映し忘れていたことが原因。実際の動画を見て初めて気づいた
• 画像切り替わり問題は、無限ループを打ち切るフレーム数指定が抜けていた。ログには成功と出ていても、動画は見るに堪えない状態だった
• 自動化の仕組みを作るときは、最終成果物を実際に目で見て確認することが不可欠

次回は、この採点→改稿の仕組みを記事全体に適用して、実際にどれくらい品質が安定するのかを検証する予定です。まだ残っている課題は「改稿が成功する確率が5割程度」という点。この成功率をどう上げるかが、次の大きなテーマになりそうです。

本記事にはアフィリエイト広告・プロモーションが含まれる場合があります。紹介する商品・サービスの購入や申込みは、必ずご自身の判断と責任で行ってください。