記事は自動で増えるようになりました。でも、増やして終わりではありません。第6章では「1コマンドを勝手に叩き続ける」定期実行と安全装置までまとめました。ここからは、増えた記事を"育てる"側の話です。数字を見て伸びる記事を見つけ、リライトで押し上げていく。連載の最終章として、この「作った後」の運用と、連載全体を通じてたどり着いた結論を書きます。
作りっぱなしにしない——データで記事を見る
自動化で下書きが増えていくのは気持ちがいいのですが、それだけでは記事の価値は測れません。「本当に読まれているか」「どう見つけられているか」を数字で見る必要があります。
トリヴィペディアでは、2つの無料ツールを組み合わせて使っています。
- Google Search Console（GSC）：Googleの検索結果で、自分のサイトが「どのキーワードで」「どのくらい表示されて」「どのくらいクリックされたか」「平均で何位に表示されているか」を見るツール
- Google Analytics 4（GA4）：サイトに来た人が「どのページを見て」「どのくらい滞在して」「どんな経路で来たか」を追いかけるツール
GSCは"入り口"のデータです。検索結果に何回表示されて（表示回数・インプレッション）、そのうち何回クリックされたか（CTR＝クリック率）、平均で何位か——"読まれる前"の話が全部ここに集まっています。
GA4は"入ってきた後"のデータ。どのページが人気で、どのくらいの時間読まれて、どこから流入してきたか——"読まれた後"の話を追いかけます。
この2つを組み合わせると、記事の状態がだいたい見えてきます。「表示は多いのにクリックされない記事」「クリックされるが滞在時間が短い記事」「滞在時間は長いが、そもそも見つけられていない記事」——それぞれ抱えている問題が違うので、打ち手も違う。数字を見ると、直感で判断していた頃には見えなかった記事のクセが浮かび上がってきます。
「なんとなく順調」と思っていた記事が、数字上は全然クリックされていなかった、という気づきは、私自身も何度も経験しました。数字はときに厳しいですが、そこを見ないと打ち手が空振りします。
伸びしろのある記事を選んで書き直す——リライトの判断
分析データが手元にあると、次に決めるのは「どの記事から手をつけるか」です。ここが実は、自動化しにくい、いちばん人の判断が要る部分でした。
全記事を均等にリライトするのは非効率です。「あと一歩で上位に届く記事」に集中投下するのが基本方針になります。GSCの数字から、私は次のような記事を"伸びしろ枠"として扱っています。
- 表示回数は多いのに、クリック率がやたら低い記事：検索結果に出ているのに選ばれていない状態。タイトルとメタディスクリプションが弱い可能性が高い。ここが直せれば、既存の表示回数がそのままクリック増に化けます。伸びしろが数字で見える瞬間はここが一番テンションが上がります
- 掲載順位が10〜20位あたりで停滞している記事：Googleに「まあ悪くない」と思われている位置。あと少し情報を厚くしたり見出しの狙いを明確にすれば、1桁順位に食い込める可能性がある枠
- クリックはされているのに滞在時間がやたら短い記事：期待と中身のズレか、本文の情報密度が薄い。読者の満足度を上げる書き直しが要る枠
私のブログの例を1つ言うと、ある漢字系のまとめ記事は、表示回数がかなり多いのにCTRが1%を大きく下回っていた時期がありました。数字を見て「タイトルの訴求が弱い」と判断し、タイトルとメタディスクリプションだけを微調整するリライトを入れたら、クリック数がじわじわ伸び始めた。"本文を全部書き直す"だけがリライトではない、という体験でした。数字が「どこを直せば効くか」を教えてくれる感覚です。
もう一つ大事なのは、伸びしろの見えない記事に時間を溶かさない、という判断です。表示回数がほぼゼロで、順位も測定圏外という記事は、直してもすぐには効きません。そういう記事は「今は触らない」と決めて別の記事に時間を使う。リライトは、直せる記事を選ぶところで9割決まるというのが、私の正直な実感です。
自動化の先にある「人の仕事」
連載を通して、私がいちばん大事だと思っていることを、最後にお伝えします。
序章で書いた「私の役割は"書く"から"確認・判断・改善"に変わった」という一節を、覚えているでしょうか。ここまでお読みいただいた方には、この主張の"改善"の部分が、まさに今回の分析とリライトの運用に対応することが、見えたかと思います。
作る自動化はもう出来上がりました。書く手間はほぼゼロになった。でも、「何を書くべきか」「どれを伸ばすか」「サイトをどこへ向けるか」の判断は、依然として自分の仕事として残っています。 GSC/GA4の数字を眺めて仮説を立てる、リライトの優先順位を決める、新しいテーマ設計にリソースを回す——これらは、AIが代替できないものです。
そしてここが、連載でいちばん伝えたかったことなのですが、自動化のゴールは"全部AIに任せること"ではなく、"人がやるべき判断に集中できる状態を作ること" でした。書くのを任せた分、人はメディアを設計する側の仕事に集中できる。手を空けるためではなく、手を頭側に持っていくために自動化を組む。 これが、7章を通じて私がたどり着いた結論です。
だから、これから自動化を組む方には、こう伝えたいと思います。「全部おまかせできる仕組み」を目指すより先に、「自分がやるべき判断は何か」を見極めることに、時間を使ってください。判断さえ手元に残っていれば、実行の自動化はあとから積み上げれば済みます。この順番を逆にしないこと——それが、7章を書き切った私からの、いちばんの申し送りです。
まとめ——連載の完結にあたって
全7章の連載、ここで完結します。振り返りとして、各章が何だったかを1文ずつ並べておきます。もう一度読み返したい章があれば、以下のリンクからどうぞ。
- 序章：「1コマンドで記事が増える」システムの全体像と、公開だけは自動化しない理由
- 第1章：APIキー管理の落とし穴と、環境構築の鉄則
- 第2章：
bash run.shの内側で回っている記事生成パイプラインの流れ - 第3章：司令塔ファイルCLAUDE.mdとサブエージェント分業の設計思想
- 第4章：WordPressへの自動投稿の仕組み——REST APIと変換の裏側
- 第5章：画像の自動取得と、著作権フリー画像を扱うライセンス設計
- 第6章：定期実行の仕組みと、暴走を防ぐ安全装置の設計
- 第7章（本章）：分析とリライトで記事を育てる運用と、連載の結び
なお、この連載全体で触れた run.sh・CLAUDE.md・各サブエージェント指示書・wp-post.sh・md2html.py・image-fetcher.py などの実ファイル一式、そして具体的な設定値やスキルファイルについては、まとめて別途公開する予定です。動く形で手元に置いてご自身のブログで再現してみたい方は、その段になったらまた見に来てください。
ここまでお付き合いいただき、ありがとうございました。連載を追いかけながら「自分もやってみようかな」と思ってくれた方が1人でもいたら、この7章を書いた意味があります。
