本文とレビューまで終わると、あとは公開するだけに見える。
俺も最初は、WordPressへ下書きを置いたら記事の仕事はほとんど終わったと思っていた。
けれど、下書き保存、アイキャッチ、公開、DBや目次の反映は、同じ種類の仕事ではなかった。
前の記事「GOを出したら、本文とレビューまで進んだ」で第2停止まで進めたあとも、次のGOで公開まで一気に進むわけではない。
WordPressには下書きを置く。
アイキャッチを設定する。
そこで、もう一度止まる。
本文が完成しても、公開はまだ人の判断だった
前の記事で終えたのは、本文、self_check、内容レビュー、SEOレビュー、auditである。
ここで確認したのは、記事の中身だった。
企画の主張からずれていないか。
手元にない事実を足していないか。
タイトルやSEO情報が本文と食い違っていないか。
それらがそろっても、公開してよいかどうかは別の判断として残る。
公開すると、読者から見える記事になる。
公開URLへ読者がアクセスできるようになり、次の記事から正式にリンクできるようになる。
だから、第2停止で出す次のGOは、公開の許可ではない。
WordPressの下書きとアイキャッチの工程へ進んでよい、という許可である。
本文完成と公開判断は、同じではない。
第2停止後のGOで、WordPressには下書きだけを置く
関連記事：下書きだけを置く
GOを受けたら、content_managerは本文とSEO情報を確認してからWordPressへ保存する。
ただし、保存する状態は`draft`である。
記事は管理画面で読めるようになる。
それでも、公開ページにはまだ出ない。
この状態にすると、WordPressの編集画面でタイトル、本文、カテゴリ、SEO情報を見直せる。
本文を作った場所と、読者に見せる場所を一度つなぐための工程である。
ここで公開まで進めないのは、AIを信用していないからではない。
記事の内容を確認する判断と、公開する判断を一つにしないためだ。
下書きは、未完成の記事ではない。
公開前の確認ができる状態に置いた記事である。
下書きは、公開前に記事を置く場所。
アイキャッチを設定しても、公開前で止まる
下書き保存のあと、creative_directorがアイキャッチを作る。
記事の内容に合う方針を決め、プロンプトを残し、画像を生成してWordPressのアイキャッチへ設定する。
画像が付くと、記事は公開に近づいたように見える。
だが、この時点でも投稿の状態は下書きのままである。
公開前に人間が見るのは、本文と画像が同じ記事を指しているか、公開してよい状態か、まだ直したいことが残っていないかだ。
アイキャッチを作る仕事と、公開ボタンを押す仕事も分けておく。
画像が整った勢いで、公開まで流れていかないようにするためである。
公開するかどうかは、俺が決める。
画像が付いても、公開は人が決める。
公開したあと、jissouは施工planを出して止まる
公開を終えると、記事は読めるようになる。
ここで初めて、公開後施工の対象を確認できる。
jissouは、いきなりDBや目次を書き換えない。
まず、公開URLと投稿状態を確認する。
そのうえで、何を更新し、何を更新しないかを施工planにまとめる。
たとえば、DB、目次、series、前後ナビ、本文内リンク、draft archiveが候補になる。
すべての記事で、すべてを変えるわけではない。
既存ルール、前後記事、公開URL、本文の状態を確認してから対象を決める。
planが出たら、第3停止で人間のGOを待つ。
公開後の仕事にも、勝手に進めない停止がある。
公開後施工は、公開の続きではなく別工程。
DB、目次、series、前後ナビ、本文内リンク、archiveを別工程にした
関連記事：DB、目次、series、前後ナビ、本文内リンク、archive
記事が公開されたあとには、見た目だけでは分からない仕事が残る。
DBへ登録すると、あとで記事を探したり、制作状態を追ったりできる。
目次、前後ナビ、本文内リンクを整えると、読者が関連記事へ進める。
seriesを更新すると、制作側でも記事の並びを追える。
前後ナビや本文内リンクは、公開済みのURLと実際の文章を確認してから決める。
draft archiveは、公開後施工が終わり、記録がそろった最終稿だけを移す。
どれも記事に必要な仕事だが、公開前には確定できない情報を使う。
だから、下書き保存や公開と一つの命令に混ぜない。
公開後に何が残っているかをplanで見て、GOを受けてから一つずつ施工する。
記事の周りを整える仕事は、公開後に始まる。
ローカルを直しても、公開ページは変わらなかった
以前、`prompt-generator.html`をローカルで直せば、固定ページも変わると思っていた。
実際に表示していたのは、WordPressの固定ページID 37だった。
ローカルのHTMLを直しても、公開ページには何も反映されなかった。
そこで初めて、作業するファイルと、読者が見る実体を同じものだと思い込んでいたと分かった。
公開後施工を分ける理由は、作業を遅くするためではない。
今どこを直すのか。
何が公開ページへ反映されるのか。
その確認を飛ばさないためである。
ローカル、WordPress、DB、目次には、それぞれ別の役割がある。
同じ記事に関わっていても、勝手に同期するとは限らない。
直した場所と、反映される場所は別だった。
公開と施工を分けると、記事が今どこにあるか分かる
記事は、本文ができたら終わりではない。
下書きになったのか。
アイキャッチが付いたのか。
公開されたのか。
DBや目次まで整ったのか。
状態を分けると、次に誰が動くかも分かる。
本文とself_checkはwriter。
内容・SEOレビューとWordPress下書き保存はcontent_manager。
アイキャッチはcreative_director。
公開は人間が行う。
公開後に残った施工は、jissouがplanを出してから扱う。
最初から全部を自動化する必要はない。
どこで止まり、何を確認してから次へ進むかが見えれば、ひとり編集長でも1本の記事を最後まで追える。
公開を分けると、残りの仕事が見える。
コメント