AIに記事を書かせる仕組みを、社内に作った

「AIに記事を書かせる」という話は、たいてい執筆の部分だけが語られます。実際にやってみると、詰まるのはそこではありませんでした。今日は何を書くのかを決めること、書いたものを公開してよいか判断すること、公開した結果を次の判断へ戻すこと。この三つが埋まっていないと、生成の速さは意味を持ちません。

社内で動かしている仕組みを、設計の考え方ごと公開します。

一日の流れ

毎朝、次の順で処理が走ります。

1. 収集 — Hacker News・GitHub・arXiv から、直近数日の材料を取る
2. 採点 — 5つの観点（検索需要・競合・収益化・自社との相性・新規性）で候補に点を付ける
3. 執筆 — 上位のテーマだけを実際に調べ、記事にする
4. 点検 — 別のモデルが「公開させない理由を探す」立場で読む
5. 公開 — 通ったものだけが記事として追加される

最後の公開は、リポジトリへのプルリクエストとして出ます。マージすると本番へ反映される。人が握っているのはこのボタンひとつです。

外せなかった三つの制約

順位はコードで決める

採点でモデルにさせているのは、観点ごとに点を付けることだけです。最終的な順位はコード側で計算します。

理由は再現性です。「最近この分野が伸びているので高めに」といった文脈をモデルに渡すと、モデルはその説明に引きずられて観点の点数自体を歪ませます。同じ材料からは同じ順位が出てほしい。そうでないと、あとから「なぜこのテーマを選んだのか」を検証できません。

学習した重みを掛けるのはコードの仕事、観点に点を付けるのはモデルの仕事、と分けています。

重複は数値で止める

複数の媒体を運営すると、同じ出来事を別の角度から書くことになります。角度を変えたつもりでも、本文は少しずつ寄っていきます。

そこで、公開前に既存記事との近さを文字3-gramの余弦類似度で測り、しきい値を超えたものは止めています。モデルに「これは重複していませんか」と尋ねる方法も試しましたが、たいてい通ります。判断が揺れない場所は、揺れない方法で守るべきでした。

実績が無いときは学習しない

重みの更新には二つの歯止めを入れています。1回の更新で動かせる幅を制限すること（急に振り切らない）、そして一定の本数が溜まるまでそのキーを動かさないこと（偶然を学習しない）。

売上だけを指標にすると、まだ売り物を置いていない媒体の評価が常にゼロになり、「売っている媒体をさらに増やす」方向にしか学習が働きません。読まれた量にも内部レートで値を付けて、両方を見るようにしています。

自動化しなかったところ

新しい媒体を立ち上げるかどうかは、AIが提案し、人が決めます。提案はファイルとして置かれるだけで、アカウントが勝手に増えることはありません。

外部サービスへの投稿も、既定では何もしません。何を投稿するつもりだったかを予定表として書き出して終わります。実際に投稿するには、環境変数で明示的に有効化する必要があります。

外向きの操作と、あとから取り消せない操作は、既定で止まっている。この線引きだけは、便利さと引き換えにしませんでした。

いま分かっていること

動かしてみて一番はっきりしたのは、生成の速さは律速ではないということです。詰まるのは、書く前（何を書くか）と、書いた後（公開してよいか、次にどうするか）でした。

そして、その二つはどちらも「判断」です。判断を自動化するとは、判断を消すことではなく、判断の根拠を毎回同じ形で残すことでした。仕組みの大半は、生成ではなく、その記録のために書かれています。