AIに記事を書かせてみたら、どこか薄っぺらい文章が返ってきた。そんな経験がある人は多いと思う。私も最初はそうだった。
それでも今、私のブログの記事は、下書きまでほとんどAIが作っている。変えたのは使うAIの性能ではなく、頼み方のほうだ。記事づくりを一回の「丸投げ」で済ませるのをやめて、編集部のように役割を分けた。ネタの整理、本文の作成、画像の投入、公開前のチェックをそれぞれ分業させて、最後の判断と公開の許可だけは自分が持つ。今回はこの、個人とAIで作る小さな編集部の話を書いていく。
丸投げが失敗するのは、書く力のせいではない
「AIの記事は薄い」と言われるが、原因は文章力ではないと思っている。丸投げには、本来分けるべき仕事が混ざっている。何を書くかという企画、どう書くかという執筆、これを出してよいかという品質の判断。この3つを一度に任せると、AIはそれっぽい平均点の文章でまとめてしまう。
考えてみれば、人間の編集部が企画・執筆・校閲を分けているのも同じ理由だ。書く人と、直させる人と、載せるかを決める人が同じだと、品質は安定しない。個人ブログだからといって、この構造を無視して一発出力に頼れば、薄くなるのは当然だった。
役割を3つの層に分けた
そこで、記事づくりの登場人物を3つの層に分けた。編集部といっても人を雇ったわけではなく、個人とAIの分業だ。
1つ目は、司令・判断するAI。ネタの整理や記事の方針決め、書き上がった本文の検査、直しの指示を担当する。2つ目は、実行するAI。決まった方針に沿って本文を書き、ブログの下書きを作り、記事どうしのリンクを張り、チェック作業をこなす。そして3つ目が人間で、途中の承認と最終確認、公開の許可だけを持つ。私の場合でいえば、記事の方針はChatGPTと相談して詰め、下書き作成やリンク張りといった実作業はClaude Codeに任せ、下書きの置き場はWordPressにしている。ただ、ここで大事なのは特定のツールではなく、役割の分け方のほうだ。
面白いのは、AIどうしでも「決める側」と「動く側」を分けたほうがうまく回ることだ。方針を考えるAIと、手を動かすAIを分けると、どちらの仕事もぶれにくくなる。丸投げで混ざっていた判断が、層ごとに整理されるからだと思う。
ネタから下書きまでの流れ
実際の流れはこうだ。まずネタは、GitHubとHNでAIネタを集めるRadarを作ったで書いた仕組みが毎日集めてくれる。集まった候補にどれくらい需要がありそうかは、AIにXの反応を調べさせてブログネタを選ぶ仕組みで確かめる。書くネタが決まったら、司令側が「何を入れて、何を入れないか」をまとめた指示書を作り、実行するAIがそれをもとに本文を書いて、ブログの下書きまで作る。
記事がいまどの段階にあるかは、進行管理表で管理している。下書きを作った、画像を入れた、チェックを通った、公開した、という状態を記事ごとに記録しておくと、複数の記事が並行していても迷子にならない。地味だが、編集部らしさをいちばん支えているのはこの表かもしれない。
いきなり反映させない。確認を挟む
実行するAIには、ブログに書き込む前に「これからこう変更する」という計画を先に見せてもらうようにしている。計画を人間が確認して、問題なければ反映する。いきなり本番を書き換えるのではなく、確認をワンクッション挟む運用だ。
あわせて、変更の前には元の状態を控えておき、対象は下書きだけに限定している。AIに任せる範囲を広げるほど、「間違えても戻せる」「触ってよい場所が決まっている」という土台の安心感が効いてくる。任せるために縛る、という感覚に近い。
公開だけは、自動化しない
ここまで任せておいて、と思われるかもしれないが、公開のボタンだけは自動化していない。公開は、記事が世に出る瞬間であり、失敗の取り返しがいちばん効かない操作でもある。だから公開は、人間が内容を確認して、明示的に許可を出したときにだけ行う形にしている。
下書きまでは何度でもやり直せる。だからAIに任せられる。公開はやり直しが難しい。だから人間が持つ。分業の線をどこに引くかは、この「やり直しが効くかどうか」で決めると迷いにくかった。
まとめ：個人でも編集部は作れる
AIに記事を丸投げすると薄くなる。でもそれはAIが書けないからではなく、企画と執筆と判断を混ぜて渡しているからだった。司令・判断するAI、実行するAI、人間、と役割を分けたら、個人のブログでも編集部のような流れが回るようになった。
土台には、M1 Mac miniを監視役、M4を司令塔、RTX 4090をAI工場にした話で書いた機材の役割分担がある。機材を分け、AIの役割を分け、最後の判断だけを人間に残す。任せるのは作業、残すのは判断。この線さえ守れば、AIとのブログ運営は思ったより堅実に回る、というのがここまでの実感だ。
コメント