毎日1本AI執筆でSEOは上がるのか（自社実験経過報告第2回）

前回、「本数を増やせばSEOは上がる」は、少なくとも2週間では起きなかった、と書きました。

あれから3週間半、開始から数えると5週間が経ちました。同じ実験をそのまま続けています。今日はその経過報告第2回です。

先に結論を書きます。5週間経って累積30本まで積み上げましたが、ページビューの伸び方はゆるやかで、コンバージョンはまだ0のままです。 ただし、この期間で見えたのは数字より運用の壊れ方のほうでした。何を直したかを、順番に書きます。

1. 前回のおさらい
2. 5週間経過の実測値をそのまま出す
3. ラインごとの偏りは、第1回とほぼ同じ
4. この5週間で「壊れた」こと4つ
5. うまくいったこと・見え始めたこと
6. 第3回（3ヶ月時点・10月末）に見る指標

1. 前回のおさらい

第1回（経過報告第1回）で書いたのは次のことでした。

2026年7月22日から8月6日までの16日間で14本を公開し、GA4合計は38ページビュー・38セッション・コンバージョン0。ラインで見ると、住宅ライン5本の27PVがこの期間の約7割を占めて、ほかの3ラインは反応の芽すら出ていない状態。

そこから見えた暫定的な結論が、「AIは「書く速度」を上げる道具ではなく、「一次情報を型にして貯める速度」を上げる道具として使うのが妥当そう」というものでした。

第2回はこの続きです。同じ指標で並べ直すのがこの経過報告の設計なので、指標も第1回と揃えます。

2. 5週間経過の実測値をそのまま出す

2026年7月22日から8月27日までの37日間で、累積30本を公開しました。

GA4（Googleアナリティクス）の合計は、本記事執筆時点で次の通りです。

累積ページビュー: 66
累積セッション: 66
累積コンバージョン: 0

第1回の2週間14本で38PV・0CVでしたから、そこから3週間半で16本増やして、追加分のPVは28、というのが素直な読み方です。本数は倍以上、PVはだいたい1.7倍。新しく足した記事ほど、まだ数字が乗っていない、という状態です。

07-22から08-27までの37日間でAI執筆した公開記事本数と、そのGA4合計ページビューの週次推移（自社実測）

もう少し具体的に見ると、上位3本は次の通りでした。

1位: #4「住宅会社のホームページ集客完全ガイド」（P1ハブ）が14PV
2位: #8「AI検索時代の住宅会社集客ガイド」（P3ハブ）が10PV
3位: #7「GA4計測改修の前後で何が変わるのか」（P2）が9PV

第1回時点でトップだった#4は変わらず1位、2位と3位はどちらも第1回の後に公開したハブ記事とスポーク記事で、ここから伸びていました。逆に、公開して1〜2週間経っても0PVのままの記事も9本残っています。

「本数を増やすほど平均PVが下がる」ようにも見えますが、それは新規サイトでインデックス（Googleの検索対象への登録）に数週間かかるのが一般的な相場だからで（新規サイトのインデックス反映 — freesquare）、公開してすぐの記事は当然まだ数字が乗りません。第1回で公開した記事のうち、この5週間で追加のPVを稼げたのは上位3本にほぼ集中していた、という言い方が正確です。

3. ラインごとの偏りは、第1回とほぼ同じ

ラインで分けて足してみます。

住宅ライン（P）: 11本で48PV（1本あたり4.4PV）
建設ライン（C）: 11本で14PV（1本あたり1.3PV）
AIの学び（A）: 3本で3PV（1本あたり1.0PV）
サービス紹介（S）: 3本で1PV（1本あたり0.3PV）

第1回の時点で「住宅ラインだけが少し反応の芽を出している」と書きましたが、5週間経っても、その偏りはむしろ強くなっている、というのが第2回の読み方です。

住宅ラインが本数の割にPVを稼げている一因は、ハブ記事とスポーク記事の関係で内部リンクが厚くなっていることのようです。#4（P1ハブ）と#8（P3ハブ）に、周辺のスポーク記事から2本ずつリンクを張っているので、新しくスポークを1本足すたびに、ハブ側にも人が回ってきます。

建設ラインは本数を住宅と同じ11本まで積んでも、まだPVは住宅の3分の1以下でした。ここは正直、まだ読み解けていません。読者の検索行動が違うのか、私の書き方が建設読者に届いていないのか、それとも単に本数がもう少しいるのか。第3回までは判断を保留する予定です。

AIの学び（A線）とサービス紹介（S線）は本数がまだ3本ずつと少なく、反応差を語る前にサンプル不足です。両方とも「読んだ人が問い合わせに変わる」ことを直接期待するラインではないので、この2つは指名検索と滞在時間で追うことにします（Search Consoleの数字は第3回から並べる予定です）。

4. この5週間で「壊れた」こと4つ

第1回で書いた通り、AI運用でいちばん怖いのは「動いているように見えるけれど、実は動いていない」状態でした。

第2回の期間でも、同じ類の壊れ方が4回起きました。それぞれ書きます。

① 8月12日、Macがログインしていなくて夜間ジョブが動かなかった。予約公開の準備は毎晩深夜2時にMacで走る設計なのですが、その日はスリープからログインに戻っていなくて、ジョブそのものが呼ばれなかった。この日は09:00の公開枠がまるごと空きました。手作業で穴埋めしたのですが、気づいたのは朝の6時間後でした。

② 8月13〜16日にかけて、3晩中2晩で夜間ループが停止していた。①の直後の週で、別の原因が2つ重なった状態です。「動かなかったこと」を朝の通知に含めていなかったのが根っこで、気づくまでに3日かかりました。この期間で公開できたのは1本だけです。

③ 8月18日、記事は書けたのに予約投稿だけができなかった。夜間タスクは「事前に許可した文字列のコマンドだけが動く」設計なのですが、私が途中でスクリプトの呼び方を「絶対パス」に書き換えていて、その書き方は承認リストに入っていなかった。4回連続で承認拒否になり、記事本文とSNS文までは仕上がったのに、09:00公開の枠は空のままでした。気づくまでに15時間。

④ 8月11日、自分の経歴の年数と氏名の誤字が公開記事に混じっていた。厳密には第1回の期間に混入した誤りを第2回の期間で発見・修正した話です。8本の記事のうち、経歴年数（建設実務20年／22年）の混在が21箇所、氏名の誤字が3件。この件は別記事にそのまま書きました。気づくまでに19日。

4件を並べると、気づくまでの時間が「6時間 → 3日 → 15時間 → 19日」とバラバラなのが分かります。運用の質は、失敗の件数より「気づくまでの時間」で決まる、と第1回で書きましたが、この5週間でそれを実測で確認した形です。

5. うまくいったこと・見え始めたこと

失敗を書いた分だけ、うまくいったことも書きます。

まず、上で書いた4件のうち①②③については、直したうえで再発させていません。それぞれ、次の順番で仕組みを入れました。

①：朝の通知に「昨夜のジョブが走らなかった場合」も含めた（走らなかったこと自体を検知）
②：夜間ループの経路に「事前チェックのタイムアウトで一晩を丸ごと落とさない」ガードを入れた
③：スクリプトの呼び方を絶対パスから相対パスに戻し、承認拒否が2回続いたら粘らず理由をログに書いて終わる、というルールを手順書に書き足した

④はもう少し根っこの直し方をしました。同じ経歴や氏名を毎回書き直すのをやめて、正典を1箇所に置き、記事側からはそこを参照するだけ、という運用に切り替えました。AIに何度も書かせるのではなく、AIが読みにいく側の場所を1つにする、という発想です。これで、少なくとも同じ失敗は起きなくなりました。

次に、「次に書く記事の選び方」を大きく単純にしました。第1回の期間には、記事を選ぶための「印」を設計書のあちこちに散らして、その印を目印にAIが記事を選ぶ、という凝った仕組みで動かしていました。ところが、その印が陳腐化した瞬間に8晩まるごと空振り（第1回で書いた失敗）が起きた。

そこで、曜日ごとに書くラインを固定して、選ぶルールは「予定日が最も早い企画をとる」、これだけに絞りました。仕組みを凝るほど、その仕組みが壊れたときの被害が大きくなる、という当たり前のことを、遠回りして確認した格好です。

そして最後に、AIには「型」を毎回渡すという運用が、この5週間で少しずつ形になってきました。私の場合の「型」は、建設実務22年の経歴、正典化した氏名の表記、ラインごとの禁止事項（採用比較を書かない・派遣と読める表現にしないなど）、記事の構成テンプレといった、書き手側で毎回変わらない部分です。これをAIに毎回渡すようにしてから、「もっともらしく書けるから起きる事故」の発生頻度が下がりました。

ここまでの手応えは、「AIを賢くしようとするより、AIに毎回渡す側を整えるほうが早い」というものです。 これは第3回以降でも同じ指標で追い続ける予定です。