投稿案を作るだけだったAIが、週次会議をする広報部になった

前回の反応を見て週次会議で次の投稿案を決めるAI広報部の図解 ブログを会社化する設計

最初は、AIに投稿案を作らせれば広報になると思っていた。

記事がある。

紹介したいURLがある。

そこからThreads向けの短い文章を作る。

それだけでも、何もないところから考えるよりは楽になる。

ただ、何本か続けると別の迷いが出てきた。

前回、何を出したのか。

どんな切り口で出したのか。

次も同じ記事でよいのか。

反応が少なかったとき、やめるのか、続けるのか。

AIに毎回「投稿案を作って」と頼むだけでは、この判断が残る。

投稿案は増える。

でも、広報として次に何を届けるかは決まらない。

俺が作りたかったのは、自動で投稿する仕組みではなかった。

前回を見て、次を決める場所だった。

投稿案を作るだけでは、広報にならなかった

投稿案だけを作るAIは、便利だった。

記事タイトルを渡す。

URLを渡す。

読者に伝えたいことを少し書く。

すると、それらしい投稿文は出てくる。

でも、その投稿案が今出すべきものかどうかは、別の話だった。

前回と切り口が近すぎないか。

同じ記事リンクばかり続いていないか。

読者がいきなり専門語から入ることになっていないか。

反応が小さかった投稿を、失敗として捨ててよいのか。

こういう判断は、投稿文の中には入っていない。

投稿案を作るAIは、文章を出せる。

しかし、順番や役割までは勝手に決めてくれない。

だから、投稿案を作るだけでは広報にならなかった。

広報に必要だったのは、次に何を届けるかを決める場所だった。

最初は、noteとSNSの仕事が分かれていた

広報部ができる前は、noteとSNSの仕事も分かれていた。

noteにはnoteの編集方針があった。

SNSにはSNS用の投稿案があった。

Threads、X、noteの候補も、それぞれ別のものとして扱っていた。

この状態でも、単発の投稿案は作れる。

ただ、全体として見ると、どの媒体で何を届けるのかが見えにくい。

noteの記事を作る仕事。

Threadsで記事を届ける仕事。

前回の反応を見る仕事。

次の投稿順を考える仕事。

これらが別々に動くと、広報というより、投稿作業の寄せ集めになる。

そこで、広報部という場所を分けた。

記事を作る編集部とは別に、届ける仕事を見る場所を作った。

ここで大事だったのは、元データを移すことではない。

広報部は、記事制作の本体を壊さない。

公開済み記事や方針を参照し、次にどう届けるかを考える。

作る仕事と届ける仕事を分けると、広報で考えることが少し見え始めた。

広報部を作って、届ける仕事を別の場所へ出した

広報部に置いたのは、投稿ボタンではなかった。

最初に置いたのは、方針だった。

投稿は手動確認を前提にする。

自動投稿しない。

いいね、返信、フォローも自動実行しない。

既存のnoteや記事情報は、参照元として扱う。

この線を引くと、AIに頼む仕事が変わった。

投稿して、ではない。

次に出す候補を整理して、である。

反応を見て、次の切り口を出して、である。

今週の順番を考えて、である。

前の記事「仕組みを増やしたのに、最後は前より静かになった」では、迷う場所を減らすために、仕事の境界を決めた。

広報部でも同じだった。

AIに任せる仕事を増やす前に、AIが触ってよい仕事を分けた。

届ける仕事を別の場所へ出したことで、投稿案はただの文章ではなく、広報の材料になり始めた。

前回の反応を見るだけでは、次の投稿は決まらなかった

広報らしくしようとすると、次に見たくなるのは前回の反応である。

表示数。

いいね。

返信。

プロフィール閲覧。

記事リンクへの反応。

こういう数字や反応を見れば、次が決まるような気がする。

でも、実際には見るだけでは決まらなかった。

反応が少ない。

では、やめるのか。

同じテーマを続けるのか。

別の入口へ変えるのか。

記事リンクを出しすぎていないか。

専門語から入りすぎていないか。

数字は材料にはなる。

しかし、数字そのものは方針ではない。

しかも、毎回すべての数字が取れるわけでもない。

取得できない値は、0ではない。

取得不可である。

ここを間違えると、見えない数字を勝手に失敗扱いしてしまう。

だから、前回の反応を見る仕事と、次を決める仕事を分ける必要があった。

見るだけでは、次の投稿は決まらない。

見たあとに、何を届けるかを決める場所が必要だった。

週次会議を置くと、毎回考えることが減った

そこで、週次会議を置いた。

会議といっても、大げさなものではない。

先週何を出したかを見る。

反応を見る。

今週、何を届けるかを決める。

月曜、水曜、金曜の投稿の役割を分ける。

日々の投稿案は、その方針から作る。

この順番にしただけで、毎回考えることが減った。

投稿案を作るたびに、ゼロから「何を出すか」を考えなくてよい。

今週のテーマがある。

月曜の役割がある。

水曜の役割がある。

金曜の役割がある。

候補資産も、誘導先も、狙いも先に置かれている。

あとは、その日の投稿案を作る。

数字が取れない日があっても、週の方針まで消えるわけではない。

前回値が取得不可なら、取得不可と書く。

それを0として扱わない。

そのうえで、今週の方針が残っているなら、投稿案作成そのものは止めない。

週次会議は、AIに長い会議をさせるためのものではなかった。

毎回その場で迷わないために、先に決める場所だった。

実行だけは、最後まで人間に残した

広報部という名前にすると、自動投稿まで任せたくなる。

投稿案がある。

スケジュールもある。

前回の反応も見る。

なら、そのまま投稿まで自動化すればよさそうに見える。

でも、そこは分けた。

投稿するか。

返信するか。

いいねするか。

フォローするか。

この実行判断は、人間に残した。

理由は、操作が難しいからではない。

外へ出た結果を引き受けるのが人間だからである。

AIは候補を作れる。

前回の反応を整理できる。

今週の方針から投稿案を出せる。

返信候補も、いいね候補も作れる。

ただし、実際に押すのは人間である。

この線があると、AIへ任せる区間も見えやすくなる。

候補作成までは任せる。

整理までは任せる。

実行前に止める。

広報部が怖くなりにくいのは、この停止位置が決まっているからだった。

広報部とは、自動投稿する場所ではなかった

振り返ると、広報部で増えたものは多い。

投稿案。

反応確認。

週次会議。

投稿順。

取得不可の扱い。

手動実行の線。

並べると、仕組みは増えている。

でも、毎回の投稿は前より考えやすくなった。

投稿案だけを作っていたときは、その場で判断していた。

今は、前回を見る場所がある。

週の方針を決める場所がある。

日々の投稿案を作る入口がある。

最後に人間が実行を決める場所がある。

AIが投稿するようになったのではない。

AIが広報会議の材料を出すようになった。

それが、俺にとってのAI広報部だった。

自動で外へ出す場所ではない。

次に何を届けるかを、人間が決めやすくする場所である。

コメント