S2では、1本の記事ができていく途中で起きたことを、工程ごとに書いてきた。
競合分析を先にやったこと。
記事制作の情報をカルテ1枚にまとめたこと。
writerに本文だけ任せたこと。
公開前チェックを分けたこと。
下書き保存で止めたこと。
公開後にDB、目次、内部リンクを整えたこと。
でも、最後に見直したかったのは、それぞれの工程そのものではなかった。
以前の記事「目次と内部リンクで、ブログを記事の集まりからサイトに変える」のカルテだった。
あの1枚に、記事がどう作られ、どこで止まり、どこから次へ渡されたのかが残っていた。
この記事では、そのカルテ1枚をもう一度読む。
AI社員がすごかった、という話ではない。
1本の記事を最後まで回したら、判断の流れが見えるようになった話だ。
1本の記事を、カルテ1枚で最後まで追いかけた
その記事は、目次と内部リンクについて書いた記事だった。
ただ、S2で何度も材料にしたのは、公開された本文そのものよりも、その裏側に残った`article_state`だった。
俺はそれをカルテとして使っていた。
そこには、タイトルやslugだけではなく、SEO、記事の狙い、H2構成、内部リンク、writerへの発注、制作状態が並んでいた。
記事を書くためのメモではなく、記事が進んでいく場所だった。
researcherが調べる。
henshuchoが構成を決める。
writerが本文を書く。
content_managerが確認する。
jissouが公開後の施工をする。
それぞれが別々に動いているようで、見ていたファイルは同じだった。
その1本の記事を、カルテ1枚で最後まで追いかけた。
それがS2全体の実験だった。
最初に残ったのは、書く前の判断だった
カルテを読み返すと、最初に残っているのは本文ではない。
書く前の判断だ。
何を狙うのか。
誰に向けて書くのか。
どの検索意図を拾うのか。
何を書いて、何を書かないのか。
本文を書く前に、すでにかなりのことを決めていた。
この段階で決めたことが、あとから何度も効いていた。
writerが迷わないためだけではない。
content_managerが確認するときも、jissouが公開後に施工するときも、最初の判断に戻れるようになっていた。
記事の制作は、本文を書き始めたところから始まるわけではなかった。
カルテの上では、本文の前にもう制作が始まっていた。
むしろ、そこで何を決めたかが、その後の工程をかなり決めていた。
writerの仕事は軽くなり、編集長の判断は前に移った
writerに渡したのは、カルテ1枚だった。
その中には、H2構成、必ず入れる実話、書かないこと、末尾の着地まで書いてあった。
writerは、そこで新しく記事の方向を決める必要がなかった。
だから、writerのログは短かった。
H2構成を反映した。
書かないことを混ぜなかった。
実話が未確認のところは創作しなかった。
それだけを確認して、次へ渡していた。
一見すると、writerの仕事が軽くなったように見える。
実際、writerは本文に集中できた。
ただ、その分だけ、henshuchoの判断は前に移っていた。
主張を決める。
構成を決める。
差別化の切り口を決める。
書かない線を決める。
判断そのものが消えたわけではない。
writerに流れていた迷いを、カルテを書く段階で俺が引き受けただけだった。
分業は、仕事を薄くする仕組みではなかった。
判断の置き場所を前に寄せる仕組みだった。
公開前に止めたことで、工程が混ざらなかった
その記事では、本文ができたあとも、すぐに公開へ進まなかった。
content_managerが確認する。
SEOレビューをする。
下書きファイルのSEOブロックとカルテのSEOレビュー欄を合わせる。
そこまで確認してから、WordPressへ下書き保存した。
ここで止めたことは大きかった。
本文ができたから公開する。
レビューが終わったから公開する。
そういう流れにしなかった。
下書き保存は下書き保存。
公開は人間の判断。
公開後のDB登録や目次反映は、また別の工程。
カルテに残っていたのは、その境目だった。
どこまで終わったのか。
どこから先はまだやっていないのか。
誰のGOが必要なのか。
それが1枚の中に残っていたから、工程が混ざらなかった。
止まる場所を決めることは、作業を遅くするためではなかった。
次の工程を勝手に始めないためだった。
公開後の施工まで、同じカルテに記録が残った
記事は、公開して終わりではなかった。
その記事では、公開後にDB登録があり、目次反映があり、series更新があり、内部リンク施工があった。
それぞれの結果も、カルテに残っている。
DBへ登録した。
目次へ1行追加した。
series_s1.mdを公開済みに変えた。
本文に内部リンクを施工した。
その前の記事「AIにブログを公開させない」の末尾にあった仮リンクも、実際のURLへ差し替えた。
公開後に何をしたかが、本文とは別に記録されていた。
ここで大事だったのは、公開後の作業まで同じカルテから追えたことだ。
記事の本文だけを見ても、どの順番で公開後処理をしたかは分からない。
WordPressだけを見ても、なぜそのリンクを置いたのかは分からない。
DBだけを見ても、記事がどういう判断でそこへ登録されたのかは分からない。
でも、カルテを見るとつながる。
書く前の判断から、本文、確認、下書き保存、公開後施工までが、1本の線として残っている。
これは、記事の完成記録ではなく、運用の記録だった。
カルテ1枚で見えたのは、AI社員ではなく判断の流れだった
S2シリーズのタイトルには、AI社員という言葉が入っている。
でも、その記事のカルテを最後まで読むと、見えてくる主役はAI社員ではなかった。
判断の流れだった。
どこで調べたか。
どこで構成を決めたか。
どこで本文を書くことだけに絞ったか。
どこで公開前に止めたか。
どこで公開後の施工へ分けたか。
AI社員は、それぞれの場所で作業していた。
ただ、記事を前に進めていたのは、AIの賢さだけではなかった。
「ここまでは決めた」
「ここから先はまだやらない」
「これは公開後に回す」
「この変更は本文ではなく施工として扱う」
そういう判断が、工程をつないでいた。
カルテ1枚で見えたのは、誰がすごいかではない。
判断がどこに置かれていたかだった。
今回の実験で分かったのは、そこだ。
AI社員を増やすだけでは、記事制作は回らない。
判断の置き場所が見えていないと、工程だけが増えていく。
もっと賢いAIではなく、迷わない運用が必要だった
S2で書いてきたことを並べると、どれも派手な話ではない。
競合分析を先にする。
カルテ1枚にまとめる。
writerには本文だけ任せる。
公開前に止める。
公開後にDBや目次や内部リンクを整える。
ひとつずつ見ると、地味な運用の話だ。
でも、その記事を最後まで回してみて分かった。
必要だったのは、もっと賢いAIを探すことではなかった。
迷わない運用を作ることだった。
AIに何でも任せるのではなく、任せる前に判断の置き場所を決める。
作業を始める前に、止まる場所を決める。
公開する前に、公開後へ回すものを分ける。
終わったあとに、何をしたかを同じカルテへ残す。
それだけで、記事制作はかなり見通しやすくなった。
S2は、AI社員を増やすシリーズではなかった。
AI社員が迷わず働けるように、判断と工程を1枚に残していくシリーズだった。
1本の記事をカルテ1枚で回してみて、俺はそこに気づいた。
次に考えるべきなのは、AIをもっと賢くすることではない。
迷わず動ける運用を、別の記事でも再現できる形にすることだ。
コメント