下書きを自動で作る仕組みはできた。次に決めるのは、その下書きを誰が世に出すかだ。技術的には、生成から投稿まで人を挟まず全自動にできる。実際、最初はそのつもりで作り始めた。けれど途中で立ち止まり、一か所だけ人を残すことにした。投稿する直前の、承認だ。
生成、承認、投稿という三段
流れはこうなった。夜のうちに機械が下書きを作り、一覧に溜める。担当者はスマホで承認画面を開き、画像と文章を眺めて、良ければ承認を押す。投稿されるのは、承認されたものだけ。気に入らなければ、その場で文章を直すことも、作り直しを指示することも、捨てることもできる。
一回の作業は一分もかからない。手間のほとんどは機械が済ませていて、人は最後の一目だけを受け持つ。
なぜ、その一目を残したか
会社の名前で出る発信は、間違えたときの取り返しがつきにくい。消しても、見た人の記憶からは消えない。AIの文章は九分九厘まともでも、残りの一厘で妙な言い回しを混ぜてくる。その一厘を止められるのは、会社の文脈を知っている人だけだ。たとえば、業界では使わない言い回しや、お客に対して微妙に上から聞こえる敬語。機械には、その温度の違いが分からない。
全自動は、うまく回っているときは美しい。けれど発信のように外へ出ていくものは、失敗の値段が高い。だから自動化の目標を、人をゼロにすることではなく、人の仕事を一目に減らすことに置き直した。ゼロと一目の間には、見た目以上に大きな安全の差がある。
曜日で、目的を切り替える
投稿の頻度は週三回と決めた。週の頭と末は施工を頼みたい人向け、真ん中の日は仲間の店の募集、と曜日で目的を固定した。サーバの定時実行が、その日の目的に合わせて下書きを作る。
目的を交互にしたのは、どちらか一方に偏らせないためだ。人が計画表を管理するのではなく、曜日という単純な決まりに計画を埋め込む。決まりが単純なほど、仕組みは壊れにくい。後から頻度を変えたくなっても、触るのは曜日の割り当て一か所で済む。
鍵の期限という、地味な落とし穴
もう一つ、無人運用の敵がいた。投稿に使う接続の鍵に、六十日の有効期限があることだ。放っておくと、二か月後のある朝、何の前触れもなく投稿が止まる。エラーの通知すら、気づかれないかもしれない。
そこで月に一度、鍵を自動で更新する処理を定時実行に足した。華やかさのかけらもない一手間だが、無人の仕組みは、こういう地味な切れ目から死ぬ。命綱は先に結んでおくものだ。更新が失敗したときのために、結果は毎回記録へ残し、あとから追えるようにもしてある。
次の回は、写真しかないのに動画の投稿を作った話と、公開してから気づいた、一枚目が白紙という間抜けな失敗について書く。