AIに書かせた記事を475本抱えて分かったこと。自動化した部分と、人間に残した部分
このブログをエージェント駆動に切り替えた話は以前書いた。あれは移行そのものの記録だった。あれから記事は475本になり、運用の形もかなり変わったので、いまどう回しているかを書いておく。
結果だけを並べても仕方がないので、判断の理由と、実際に何が壊れたかを中心に書く。
何を自動化して、何を残したか
最初に決めたのは、公開だけは自動にしない、ということだった。
自動化しているのはこのあたりになる。
・記事のビルドとデプロイ。ファイルを置いてトリガーを立てると、systemdのpath unitがビルドして配信先へ反映する
・アクセスログの集計と人気記事の再生成。毎日cronで走る
・GAのplayイベントの集計。これも毎日cron
・公開前の機械的な検証。禁止表現、文字種、リンク切れなど
人間の承認に残しているのはこれになる。
・何を書くか、どのアプリを作るかの決定
・公開してよいかの最終判断
・お金が動く操作。画像生成の実行や、外部APIを叩く構成の採用
線引きの基準は、間違えたときに取り返しがつくかどうかにしている。ビルドは失敗しても再実行すればいい。公開は取り消せるが、その間に読まれる。お金は戻らない。
アプリの中でその場で文章を生成する構成も検討して、やめた。外部通信をしない単一HTMLとして置いているので、APIキーを埋め込むと公開ページに認証情報を晒すことになる。サーバー側に中継を立てれば可能だが、遊ばれるたびに費用が発生する。この判断はブロック崩さないの記事にも書いた。
検証は4点セットにしている
書いた文章をそのまま公開すると事故る。実際に事故ったので、公開前に必ず通す確認を4つ決めた。
・禁止表現。使わないと決めた記号や言い回しが混ざっていないか
・文字種。日本語の文章に、キリル文字やハングルなど別の文字体系が紛れていないか
・箇条書きの改行。連続する行が1段落に結合されていないか
・内部リンク。記事から張ったリンクを実際にHTTPで叩いて、200が返るか
抽象的な話にしても意味がないので、それぞれが実際に何を捕まえたかを書く。
文字種の検査は、記事の中に「自転車」と書いたつもりで、頭一文字がハングルの「자転車」になっていたのを捕まえた。目で読んでも気づけない。表示上ほぼ同じ幅で、意味も通ってしまう。
箇条書きの検査は、もっと大きい取りこぼしを見つけた。このブログは箇条書きに中黒を使っているのだが、中黒はMarkdownのリスト記号ではない。だから中黒で始まる行が連続すると、すべて1つの段落に結合されて、「・項目A ・項目B ・項目C」と1行に潰れて表示される。読者から指摘されて調べたら、44記事303行がこの状態だった。行末に半角スペース2つを入れて強制改行にする方式で一括修正した。
内部リンクのHTTP検査は、記事を書くたびに1件か2件は404を拾う。日付ベースのURL構造なので、リンク先の公開日を1日でも間違えると存在しないURLになる。書いている本人は正しいと思い込んでいるので、機械に叩かせないと気づけない。
禁止表現の検査は、太字が5箇所残っていた記事を止めた。
この4つは、どれも「書いた内容が正しいか」は見ていない。形式だけを見ている。それでも記事を出すたびに何かしら引っかかる。
人気順を勘から実測に切り替えた
いちばん反省しているのがこれになる。
トップページにアプリを並べたとき、それぞれに人気度の初期値を手で振っていた。台風シミュレーターは95、架空株式市場は60、といった具合に。自分の感覚で決めた数字だった。
あとから「これは本当に人気順なのか」と問われて調べたら、実測が乗っていたのは上位の数個だけで、残りの大半は自分が置いた勘の数字で並んでいた。1回も遊ばれていないアプリが、勘の初期値だけで新作より上に表示されていた。
手打ちの数字を全部0にして、GAで実測しているplayイベントの回数だけで並ぶようにした。同点になったものは新着順で拾う。
切り替えてから分かったのは、実測の分布が勘とはまるで違うことだった。いまの28日間の集計はこうなっている。
・台風進路シミュレーター 562
・台風育成シミュレーター 119
・線状降水帯シミュレーター 45
・架空株式市場 44
・締切タイムゾーン時計 28
1位と2位で5倍近い差がある。この差は勘では出せない。
同じことを記事の人気順でもやった。アクセスログを集計して順位を出しているのだが、ここでも問題が起きた。1本の記事が突出しすぎていて、順位を占有し続けてしまう。LightsailにSSLを設定する手順の記事で、PVが1787ある。2位の記事が1602で、3位以下は100台に落ちる。
順位表としては正しいのだが、この2本が常に上にいると、その下にある記事が誰の目にも触れない。そこでLightsail関連の記事を殿堂入りとして別枠に切り出し、通常のランキングからは外した。ランキングは25件表示にして、その下の層を見えるようにしている。
正しい順位を出すことと、順位表として役に立つことは別だった。
失敗を消さずに残す
記事に書く内容の方針も変えた。うまくいった手順だけを書くのをやめて、間違えた過程を残すようにした。
理由は2つある。ひとつは、結果だけの情報は生成できてしまうこと。エラー文とその対処なら、いまはモデルが直接答える。わざわざ検索して読む理由が薄い。
もうひとつは、間違えた過程は再現できないことになる。実際に手を動かして、実際に間違えた人しか書けない。
具体的には、こういうものを消さずに書いている。
・線状降水帯のシミュレーターで、追跡の物理が逆になっていたこと。高気圧が強いほど早く転向する挙動になっていて、実際とは逆だった
・ゲームのバランス調整で、自分の測定コードのほうが2回間違っていたこと。回避する自動プレイヤーが画面の角に貼りついて数秒間動いておらず、それをゲームが難しすぎると誤診した
・台風アプリの発生位置の判定に、到達不能な分岐を書いていたこと。地図の下端が北緯6度なのに、北緯5度未満を弾く条件を書いていた。絶対に通らない
・アニメーションが動かないと判断して実装を書き直したが、原因は検証に使っていたブラウザのタブが非表示で、ブラウザ側がアニメーションを止めていただけだったこと
最後のものは特に、自分の誤診をそのまま書いている。無実のコードを直していた、と記事に残した。
これを書くのは気分のいいものではない。ただ、あとから読み返すと、こういう記述のある記事のほうが自分でも役に立つ。同じ罠に二度はまらずに済む。
効いているのかどうか
正直なところ、まだ判断できる段階ではない。
手元の数字では、制作過程を含む記事のほうがPVの中央値が高い。7月以降に書いたアプリの解説記事7本は中央値25、同時期のエラー対処記事22本は中央値6だった。
ただしこれを根拠に「過程を書くと伸びる」と言うのは早い。アプリの解説記事はトップページとアプリ一覧から内部リンクが張られていて、そもそも露出の条件が違う。エラー記事の6は検索流入だけで取った数字で、アプリ記事の25には内部回遊が含まれている。条件を揃えた比較になっていない。
言えるのは、少なくとも過程を書いたことで下がってはいない、という程度になる。そのうえで、書き手として続けやすいのはこちらだった。
まとめ
・自動化の線引きは、間違えたときに取り返しがつくかどうかで決めた。公開とお金が動く操作は人間に残した
・公開前の検証は禁止表現、文字種、箇条書きの改行、内部リンクのHTTP確認の4点。形式しか見ないが、毎回何か引っかかる
・文字種の検査はハングル混入を、箇条書きの検査は44記事303行の表示崩れを捕まえた
・アプリの人気順は手打ちの勘を全部0にして、GAの実測だけにした。1位と2位で5倍の差があり、勘では出せない分布だった
・記事の人気順は突出した2本を殿堂入りとして別枠に外した。正しい順位と、役に立つ順位表は別
・間違えた過程は消さずに残している。結果だけの情報は生成できるが、失敗の経緯は実際にやった人しか書けない
・過程を書くと伸びるかどうかは、まだ条件を揃えた比較ができていない