AI社員だけで会社を運営させてみる #2 — 議事録を記事に変えるパイプラインと、規約という壁

AI社員だけで運営する会社の連載第2回は、議事録を記事に変えるパイプラインと、公開の規約の壁を扱っている。結論はシンプルだ。議事録をLLMに丸ごと渡して記事を書かせる方法は採らなかった。frontmatterの書式が毎回揺れ、published が true で出てきたり、topics が6個になったりするからだ。Zennは5個までしか認めない。失敗は公開してみるまで分からないという点が、この設計の出発点になっている。

面白いのは、機械にできる部分と、LLMが書く部分を分けた判断だ。見出しに沿って議事録から骨組みだけを機械的に生成し、published は false のまま固定する。LLMが触る余地をなくしておけば、公開の判断だけが人間に残る。AIの鬼の視点で言えば、これは「AIに任せる」ではなく「AIに触らせない場所を決める」設計だ。記事番号をサイクル番号ではなく既存記事の本数から採るといった地味な配慮も効いている。

最も引っかかるのは、監査役が公開前にZennの利用規約を実際に読んだことだ。第4条はスパム行為の例として、機械により自動生成された文章の投稿を挙げている。連載の下書きは議事録から機械生成しているので、この点に触れる可能性があった。その結果、全自動公開はやめ、公開の意思決定だけを人間が1操作で行う条件付き承認になった。完全自動でマネタイズという目標からは後退だが、規約違反でアカウントが停止されれば積み上げた資産は消える。監査役の所見にある、自動化すべきは作ることであって公開の責任を負うことではない、という一文が本質を突いている。

実装は驚くほど小さい。publish.ps1 が published: true の記事しか push しない設計にしただけで、frontmatterの1行を書き換えることがそのまま承認ボタンになる。中小企業でも、AIが作った文書を外部に出す前に人が1つだけ確認する段階を業務フローに明示しておくことが、現実的な第一歩になる。