記事を自動で「編集長視点で採点」させた2日間の試行錯誤

📖 読了目安: 約4分

今回は、このブログの自動投稿システムに「記事を編集長の目線で自動採点し、点数が低ければ書き直す」という仕組みを組み込もうとして、うまくいかなかった2日間の話です。

8月3日の朝から夜まで、何度もコードを書き換えて自動投稿を動かしてみたのですが、最終的にはこの機能を諦めることになりました。どこで詰まって、なぜ断念したのか、実際のコミット履歴をもとに振り返ります。

記事を書く前に「設計図」を作らせる

まず朝いちばんに取り組んだのが、記事の書き方そのものを変える試みでした。これまでは「こういうテーマで記事を書いて」とClaude Codeに頼むだけだったのですが、それだと記事の構成がぶれることがあったんです。

そこで、本文を書く前に「editorial_blueprint」という設計図を先に作らせることにしました。想定読者が何に困っていて、記事で何を伝えるべきか、どんな順番で説明すれば分かりやすいか、といった骨組みを1回のやり取りの中で先に出力させてから、その設計図に沿って本文を書かせるという流れです。

これは比較的うまく動いて、記事の構成が安定しました。次はこの記事の「質」を自動でチェックできないか、という欲が出てきたんです。

編集長ペルソナで記事を採点させる

午前中のうちに、記事を公開する前にAIが自分で採点する機能を追加しました。「検索意図に応えているか」「初心者にも分かりやすいか」「読みやすいか」といった7つの観点でそれぞれ100点満点で点数を付けさせ、どこか1つでも90点未満があれば、足りない部分を指摘して書き直させる、という仕組みです。

最初は2回まで書き直しを試みて、それでも90点に届かなければそのまま公開する設定にしました。3回に増やしてみたりもしましたが、後の問題でまた2回に戻しています。

この採点機能自体は動いたのですが、ここから先が長い戦いになりました。

タイムアウトでシステムが止まる

夕方、自動投稿が動く時間になって実際に動かしてみたところ、採点のところでシステムが止まってしまい、記事が公開されないという事態が起きました。

原因を調べると、Claude CodeのAPIを呼び出すときにタイムアウト(制限時間切れ)が発生して、それをプログラムが想定していなかったため、処理全体が止まってしまっていたんです。

急いでコードを修正して、タイムアウトが起きても「採点なし」として投稿を続けられるようにしました。採点・改稿は「あれば嬉しい」機能なので、失敗しても記事の公開そのものは止めたくなかったからです。

改稿が途中で切れる問題

タイムアウトを回避できるようにしたので、次は改稿がうまくいくかどうかです。ところが、実際に動かしてみると、改稿が3回とも失敗していました。

理由は「トークン数の上限」でした。Claude CodeのAPIには1回の出力で生成できる文字数の上限があって、当時は8000トークンに設定していました。ところが、改稿というのは「元の記事に加えて、足りない部分を補う」作業なので、元の記事よりボリュームが増えるんです。その結果、出力の途中で打ち切られてしまい、記事データの形式が壊れて読み込めなくなっていました。

上限を16000トークンに引き上げてみましたが、今度は別の問題が起きました。

今度は生成が間に合わない

トークン数を倍にしたことで、生成に時間がかかるようになりました。今回使っているAPIの呼び出し方は「すべて書き終わってから一気に返す」方式なので、途中経過が見えません。タイムアウトは180秒(3分)のままだったので、生成が完了する前に制限時間が来てしまい、また失敗していました。

制限時間を420秒(7分)に延ばしてみましたが、それでも安定しませんでした。改稿が必要な記事ほど内容が増えるため、トークン数と制限時間のバランスが取りづらかったんです。

改稿を諦めて、採点だけ残すことにした

夜、いろいろ試した結果、改稿機能は一旦諦めることにしました。トークン数を増やせば時間がかかり、時間を延ばせば他の処理も遅くなる。改稿がうまくいく設定を見つけるより、まずは記事を安定して公開できる状態を優先すべきだと判断しました。

最終的には、採点機能だけ残して、点数と改善点をログに出力するだけにしました。改稿はせず、そのまま公開します。将来、別の方法(ストリーミング形式のAPIや、もっと軽い改稿方法など)を試すときの材料として、採点結果は記録しておくことにしました。

当初の設定を元に戻して、この日の試みは一区切りです。

関連記事

• AIに「単語の途中で改行しないで」と頼んだら、AIが解決策を出してきた話
• ショート動画自動生成の舞台裏|字幕はみ出しと見出しデザインの試行錯誤
• 画像を流用して画面が壊れた話|ヘッダーロゴとファビコンの失敗から学んだこと

今回の試みはうまくいきませんでしたが、記事の設計図を先に作る仕組みは残りました。また、採点結果をログに残すようにしたことで、将来また改稿に挑戦するときの材料ができました。

• 記事を書く前に設計図(editorial_blueprint)を作らせることで、構成が安定した
• 編集長視点の採点機能を追加したが、改稿ループはタイムアウトとトークン不足で安定しなかった
• 最終的に改稿は諦め、採点結果を記録だけ残す方針に変更
• 自動化は「うまくいかないときも止まらない」設計が大事だと実感

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