AI社員で記事を回す実践記録

researcher、writer、レビュー役、画像、公開後施工。名前だけを並べると、記事を書く前から小さな会社を作る話に見える。今の仕組みだけを見ると、最初から全部の役割を用意しないといけないように見える。でも、今から同じ仕組みを作るなら...

同じ指示文を会話の最初に貼って、記事を作る。最初は、それで困らなかった。ひとり編集長に雑メモを渡し、企画案で止まってもらう。GOを出したら本文とレビューまで進み、WordPressの前でまた止まる。この流れが会話の中で動いている間は、指示文...

本文とレビューまで終わると、あとは公開するだけに見える。俺も最初は、WordPressへ下書きを置いたら記事の仕事はほとんど終わったと思っていた。けれど、下書き保存、アイキャッチ、公開、DBや目次の反映は、同じ種類の仕事ではなかった。前の記...

企画案を確認してGOを出すと、AIはそのまま公開まで進むと思うかもしれない。俺も最初は、本文ができた時点で記事はほとんど完成だと思っていた。でも、本文の完成と公開の準備は同じではなかった。前の記事「雑メモを渡したら、企画案で止まってくれた」...

AIに記事を書かせようとすると、渡すメモまできれいに整えたくなる。タイトルを決める。読者を決める。見出しまで並べる。でも、そこまで人間が決められるなら、最初から編集長に渡す意味が薄くなる。前の記事「最初からAI社員を作らない。コピペでひとり...

AIで記事を作ろうと思うと、最初に役割を増やしたくなる。researcherを作る。writerを作る。レビュー役も作る。でも、始める前からそれを全部そろえると、記事を書く前に仕組みづくりで止まる。俺も最初から編集部を作ったわけではない。最...

記事を書く場所と、画像を作る場所が分かれていた。記事はClaudeで作っていた。アイキャッチはChatGPTで作っていた。最初は、それで困っていなかった。でも、記事を1本作るたびに、画像プロンプトをコピーする。別の画面へ移る。生成した画像を...

S2では、1本の記事ができていく途中で起きたことを、工程ごとに書いてきた。競合分析を先にやったこと。記事制作の情報をカルテ1枚にまとめたこと。writerに本文だけ任せたこと。公開前チェックを分けたこと。下書き保存で止めたこと。公開後にDB...

前の記事「投稿後にDB登録したら、記事が資産として残り始めた」では、公開した記事を`articles.db`へ登録した。DBに記録し、目次へ載せ、`series_s2.md`も更新した。それで公開後の管理は進んだ。でも、投稿ID101の記事...

前の記事「下書き保存で止めたら、公開後の工程が混ざらなくなった」で、下書き保存のあとにも公開後の工程が残っていた話を書いた。公開されたあと、DB、目次、series、内部リンクを別々に進めた。工程を分けたから、どこまで終わったかを追えた。そ...