僕はいま、AIチームと一緒に、昔書いたブログ記事をリライトしています。
リライトといっても、文章をきれいに書き直すだけではなく。
Search Consoleを見る。
人気記事を見る。
公開記事を読み直す。
タイトル、description、導入、見出し、画像alt、内部リンク、アフィリエイトまで確認する。
保存したら、公開後チェック。
そのあと、ドキュメントに残して、7日、14日、28日で観測する。
やっていることは、古い記事をもう一度、今のメディア資産に戻す作業に近い。
書きっぱなしの記事を、もう一度見に行く
ブログ記事は、公開したら終わりではない。
定期的に記事を見直す、リライトは特に重要。
よく聞く話だけど、それはそうなわけで。
昔書いた記事でも、今も検索からアクセスされているものがあります。
たまにDiscoverに出るものもある。
商品リンクがクリックされているものもある。
別の記事への入口になっているものもある。
自分では少し古い記事だと思っていても、読者にとっては今読んでいる記事。
そこに古い情報が残っている。
導入が弱い。
画像altが設定されていない。
内部リンクがない。
アフィリエイトの商品が今の検索意図とずれている。
そういう状態だと、せっかく読まれている記事がもったいない。
記事を書き足すことも大事。
でも、すでに読まれている記事を育て直すことも、同じくらい大事なわけで。
数百記事をひとりでリライトするのは無理だった
ただ、現実的な問題が。
とにかく記事が多い。
20年以上続けてきているブログ。このブログだけでなく、moss.fish にも、isLog にも数百本単位で記事があります。
これをひとりで全部見直すのは、正直かなり無理がある。
タイトルを見る。
本文を読む。
検索意図を見る。
古い情報を調べる。
内部リンクを考える。
画像altを直す。
アフィリエイトを見直す。
WordPressで編集する。
公開面で確認する。
ドキュメントに残す。
1本の記事でも、ちゃんとやるとそれなりに時間がかかる。
それを何百本もやる。
しかも、新規記事も書く。
日々の事業集計も見る。
X投稿もする。
サイトの改善もする。
普通に考えると、回らない。
だから、AIチームで進めることにした。
AIに丸投げするのではなく、役割を分けて、リライト作業の編集部として動いてもらう。
それなら、少しずつ回せる。
全てを一気に直すのではなく、見るべき記事から順番に直していける。
AIに文章を書かせているわけではない
ここでやっているのは、AIで記事を量産することではなく、むしろ逆。
すでに自分が書いた記事を、AIチームと一緒に読み直している。
釣った魚の記事。
食べたものの記事。
旅先で歩いた場所の記事。
使ってきた道具の記事。
WebやAIで試したことの記事。
そういう、自分の体験が入っている記事を、今の読者に届きやすい形へ整えている。
AIにゼロから書かせるのではない。
人間が体験した記事を、AIと一緒に育て直している。
この違いはかなり大きい。
Codex appを、編集部の作業場所にしている
リライト作業では、Codex appを使用。
ひとつのスレッドに、全部をまとめて頼むわけではない。
候補を選ぶ。
公開記事を読む。
検索意図を整理する。
変更方針を出す。
WordPressで編集する。
公開HTMLを確認する。
ドキュメントに残す。
こういう作業を、Codex appのスレッドや役割ごとに分けて進めている。
たとえば、リライト候補を整理するスレッドがある。
Search Consoleを見て、今どの記事に検索需要があるかを考える。
人気記事一覧を見る。
ASPクリックなどの可能性を見る。
AI referralの兆しも見る。
次に、対象記事を読む。
公開URLを開いて、今のtitle、description、H1、H2、画像、内部リンク、商品導線を見る。
そのうえで、どこを変えるかを先に整理する。
いきなりWordPressで編集しない。
高アクセス記事ほど、先に方針を出す。
どこを直すか。
どこを触らないか。
どこは現状維持するか。
ここを決めてから編集する。
この流れがあるだけで、リライトがかなり落ち着く。
Codex appは、単なる文章生成の場所というより、編集、実装、確認、記録を進める作業場所になっている。
まず見るのは、Search Consoleと公開記事
リライト候補は、思いつきだけでは選ばない。
まず見るのは、Search Consoleです。
特に検索クエリを見る。
直近でどんな検索ワードが出ているか。
表示が増えているテーマはどこか。
クリックにつながっている記事はどれか。
そこを見る。
あわせて、各サイトの人気記事も見る。
昔の記事だけど、今も読まれている。
検索流入が残っている。
ASPクリックなどにつながっている。
AIサービス経由の流入が出ている。
そういう記事は、優先して見直す候補になる。
ただ、数字だけでは決めない。
公開記事を読む。
今読んで、ちゃんと使える記事になっているか。
古い情報が邪魔していないか。
読者が知りたいことに先に答えているか。
体験文として残したほうがいい部分はどこか。
数字と本文を両方見る。
そこから始めるようにしている。
人気記事ほど、壊さないように直す
リライトで怖いのは、直しすぎること。
特に、検索流入がある記事。
クリックがある記事。
昔から読まれている記事。
そういう記事は、何かしら読まれている理由がある。
タイトルかもしれない。
体験の具体性かもしれない。
写真かもしれない。
古いけれど、読者が知りたい情報に当たっているのかもしれない。
そこを大きく壊すと、よかれと思って直したのに、記事の良さを消してしまうことがある。
だから、高アクセス記事ほど小さく直す。
URLは変えない。
本文の核は残す。
検索意図に合っている部分は残す。
古くなった情報だけ補う。
導入とdescriptionを整える。
内部リンクを足す。
画像altを自然文にする。
改善より先に、壊さない。
この感覚は大事だと思っている。
タイトル、description、導入を今の読者に合わせる
まず直すことが多いのは、タイトル、description、導入。
昔の記事は、タイトルが少し日記寄りだったりする。
それはそれで、その時のブログらしさでもある。
ただ、今検索から来る読者には、何の記事なのかが少し分かりにくいことがある。
たとえば、釣りの記事なら、何を釣ったのか。
どう食べたのか。
どんな道具を使ったのか。
初心者向けなのか、
実体験レビューなのか。
そこがタイトルや導入で見えると、読者は入りやすい。
descriptionも同じ。
長すぎる説明を短くする。
記事で分かることを先に出す。
古い言い回しを今の表現にする。
導入では、読者が知りたいことに先に触れる。
本文の体験は残す。
でも、入口だけは今の読者に合わせる。
そのくらいの距離感で直している。
古い情報と画像altを直す
古い記事でよくあるのが、事実情報のズレ。
店舗情報。
営業時間。
料金。
交通。
サービス仕様。
商品ラインナップ。
アプリの画面。
外部サービスの条件。
このあたりは、時間が経つと変わる。
だから必要なときは、公式サイトや信頼できる情報源で確認する。
公開本文には、内部数値や管理画面の情報は出さない。
読者に必要な範囲で、今読んでも困らないように直す。
画像altも見直す。
昔の記事では、altが古かったり、空だったりすることがある。
今は、できるだけ自然文にしている。
「何の写真か」が分かるようにする。
検索のためだけではなく、記事としてちゃんと読むための整えです。
内部リンクで、点の記事を面にする
リライトでかなり効くのが、内部リンク。
1本ずつの記事を直すだけだと、まだ点のまま。
でも、関連記事をつなぐと、面になる。
釣る。
捌く。
刺身にする。
寝かせる。
料理する。
道具へ広げる。
旅の親記事から、個別の見どころへ行く。
個別記事から、全体記事へ戻る。
こういう内部リンクを足すと、過去記事がばらばらの記録ではなく、読めるまとまりになっていく。
これは、ブログをメディアとして育てる上でかなり大きい。
新しい記事を書くことだけがメディア運用ではない。
既存の記事同士をつなぐことも、メディア運用、と。
アフィリエイトは検索意図に合うものだけ残す
収益導線も見直す。
ただし、むやみに商品リンクを増やすわけではなく。
アフィリエイトは、検索意図に合うものだけ残す。
読者が道具を探している記事なら、商品リンクが自然に役立つことがある。
テントの長期レビューなら、本体や実際に使った周辺道具への導線は意味がある。
釣具の記事なら、使った道具や近い選択肢があると便利です。
でも、記事の流れと関係ない商品を置くと、ただの広告に見える。
それは避けたい。
収益導線は、隠さない。
でも、記事の意図とずれているなら外す。
残すときは、読者の判断に役立つものだけにする。
このあたりも、AIチームと一緒に見ている。
mossでは、シリヤケイカの記事をクラスターで見直した
実際の例でいうと、moss.fish ではシリヤケイカ関連記事をまとめてリライトした。
釣行の記事。
刺身の記事。
料理の記事。
改造エギの記事。
沖漬けの記事。
単独の記事をそれぞれ直すだけではなく、クラスターとして見た。
シリヤケイカを釣る。
捌く。
刺身にする。
寝かせる。
料理する。
改造エギや沖漬けへ広げる。
こうすると、1本の記事だけではなく、シリヤケイカというテーマ全体が読みやすくなる。
やったことは地味。
タイトルとdescriptionを整える。
導入に、何が分かる記事かを足す。
釣行、料理、道具記事の内部リンクを追加する。
画像altを自然文にする。
アイキャッチのサイズを見る。
でも、これをまとめてやると、点の記事が面になっていく。
ブログの過去記事が、少しずつメディア資産に戻っていく感じがある。
isLogでは、古い実用記事を今読める記事に戻した
isLog では、成田空港第3ターミナルのフードコート記事をリライトした。
こういう記事は、かなり実用寄り。
今どの店があるのか。
保安検査前に食べられるのか。
保安検査後はどうなのか。
空港に行く前に、読者が何を判断したいのか。
古い店舗情報が残っていると、記事として使いにくい。
だから、現行情報を確認し、導線を整理した。
descriptionを短くする。
導入とまとめを、読者が判断しやすい形に直す。
画像altを自然文にする。
関連する成田空港記事への内部リンクを意識する。
公開HTMLで反映を見る。
これは、古い実用記事を、今の読者に使える記事へ戻す作業。
同じisLogでは、鋸山関連記事も親記事と子記事のクラスターとして整理。
親記事で全体像を受ける。
子記事で、地獄のぞき、日本寺大仏、東海千五百羅漢、燈籠坂大師などの個別の見どころを受ける。
検索から来た読者にも、AI経由で見つけた読者にも、記事同士の関係が分かりやすくなるようにする。
ここでも、やっていることは派手ではなく。
でも、旅と街歩きの記事が、ただの過去ログではなく、シリーズとして読めるようになっていく。
taupeでは、古いノウハウ記事を現在仕様に合わせる
このブログでも、人気記事上位を見直しています。
PCでLINEを2アカウント同時に使う記事。
PC版LINE通知の記事。
漫画系広告の非表示記事。
AdSense広告レビューセンターの記事。
逆ジオコーディングの記事。
Evernote端末制限の記事。
こういう記事は、仕様変更の影響を受けやすい。
古い画面。
古い手順。
古いサービス条件。
今は使えない前提。
それが残っていると、記事の信頼が落ちる。
だから、2026年時点で確認できる範囲に合わせて整える。
古いスクリーンショットは、当時の画面として扱うのか。
今の仕様に合わせて説明を補うのか。
関連する記事へ内部リンクを足すのか。
アフィリエイト導線を残すのか外すのか。
そういう判断を、1本ずつやっている。
このブログは、AIやGAS、WordPress、作業環境の記事が多い。
だからこそ、古いノウハウを放置しないようにしたい。
ツーリングドームLXでは、壊さないことを優先した
もうひとつ、分かりやすい例。
moss.fishのコールマン ツーリングドームLXの記事。
これはアクセスがあるキャンプギア記事。
こういう記事は、直すときにかなり気を使う。
検索されている。
読まれている。
商品導線もある。
だから、いきなり大きく作り替えない。
URLは変えない。
既存の設営レビュー本文は大きく壊さない。
タイトルは長期レビュー寄りに整える。
descriptionを短くする。
導入に、ソロやデュオで使いやすいこと、3人利用は窮屈なこと、現行モデル確認の必要性を入れる。
2026年時点でLXとLDX比較の補足を入れる。
アイキャッチとaltを整える。
関連するキャンプ記事への内部リンクを足す。
アフィリエイトは、記事意図に合うものを維持する。
高アクセス記事は、改善より先に壊さない。
この判断をAIチームと確認しながら進めた。
保存したら、公開HTMLまで見る
WordPressで保存したら終わり。
以前は、そうなりがちだった。
でも今は、保存後に公開HTMLまで見る。
titleが反映されているか。
descriptionが変わっているか。
H1が意図通りか。
OG画像やTwitter画像が出ているか。
内部リンクが正しく入っているか。
画像altが入っているか。
編集画面では見えていても、公開面で崩れていることがある。
キャッシュの影響もある。
テーマ側の出力もある。
OG画像が古いままのこともある。
だから、最後は公開URLを見る。
ここまでやって、ようやくリライト完了にする。
このQA担当としても、Codex appを使っている。
ドキュメントに残して、7日・14日・28日で観測する
リライトは、直した瞬間に成功かどうか分かるものではない。
検索はすぐ動かない。
Discoverも読めない。
Pochippクリックも日によって揺れる。
AI referralも、ある日突然出ることがある。
なので、docsに残す。
どの記事を直したか。
何を変えたか。
何を変えなかったか。
どの指標を見るか。
次にいつ観測するか。
そして、7日、14日、28日で見る。
7日は異常検知。
計測が壊れていないか。
表示が崩れていないか。
クリック導線が消えていないか。
14日は初期傾向。
検索ワードがどう動いたか。
回遊が出ているか。
関連記事同士が読まれているか。
28日は初期評価。
検索、回遊、収益導線、AI visibilityを見ながら、次にどの記事を直すか考える。
リライトは、編集して終わりではない。
観測まで含めて、ひとつの作業。
AIチームは、文章生成ではなく編集部に近い
この運用を続けていると、AIチームは文章生成ツールというより、編集部に近いと感じる。
候補を選ぶ編集者。
公開記事を読むリサーチャー。
検索意図を見る調査担当。
タイトルや導入を整える編集者。
WordPressで作業するオペレーター。
画像altや内部リンクを見る実装担当。
公開HTMLを見るQA担当。
ドキュメント担当。
7日、14日、28日で見る分析担当。
もちろん、全部が完璧に自動で動くわけではない。
最終判断は自分がする。
この記事は大きく変えない。
この商品リンクは残す。
この内部リンクは足す。
このタイトルはやりすぎ。
これは今は触らない。
そういう判断は、人間側に残す。
でも、AIチームがいることで、見られる記事の数が増える。
一人では手が回らなかった記事に、少しずつ手を入れられる。
これはかなり大きい。
まだ途中。でも、記事が資産に戻っていく感覚がある
今やっているリライトは、まだ途中。
全部の記事を直したわけではない。
むしろ、数百記事ある中の一部を、少しずつ見ているだけ。
それでも、感覚は変わってきた。
昔の記事を、ただの古い記事として見なくなった。
検索から今も読まれている記事。
季節が来ると動く記事。
商品導線になっている記事。
AIに見つかり始めている記事。
別の記事へ読者を連れていける記事。
そういう資産として見られるようになってきた。
ブログは書きっぱなしにしない。
新しく書く。
昔の記事を見る。
直す。
つなぐ。
公開面で確認する。
docsに残す。
また数字を見る。
この流れを、Codex appのAIチームと一緒に回している。
まだ完成した仕組みではない。
でも、記事が少しずつメディア資産に戻っていく。
今は、その手応えがある。
ポチップ