ブログを書き続けていると、記事を書くこと以外の作業が増えていきます。
公開後にどの記事を直すか、関連記事をどこへ追加するか、CTAを出すべきか、公開前に何を確認するか。これらを毎回その場で判断していると、記事を書く前後の管理だけで時間がかかります。
私も、ChatGPTやCodexを使って記事作成を効率化していましたが、記事台帳、内部リンク、公開後の確認、サイト側の修正は別々に考える必要がありました。そこで、記事本文と運営情報を分け、AIと人間の役割も整理しました。
この記事では、Astroへ移行した後に整えたブログ運営環境を紹介します。記事台帳、内部リンク、CTA、ChatGPT・Codex・人間の分担、公開前確認を、実際に使っている管理方法に沿ってまとめています。AstroやCloudflareの設定手順ではなく、個人ブログを改善し続けるための仕組みが中心です。
移行した理由や、はてなブログ時代に残っていた作業については、Codexにブログ運営をもっと任せたい｜はてなブログからAstro＋Cloudflareへ移行した理由で詳しく書きました。今回は、その移行後に運営環境をどう整えたかを続きとしてまとめます。
1. 記事を書く以外の管理情報を整理した
記事本文だけを管理していると、公開した後に必要な情報が散らばりやすくなります。
たとえば、次のような情報です。
- どの記事が公開済みか
- 正式URLはどれか
- どの記事からどの記事へリンクしているか
- 公開後に確認することは何か
- 次に改善する候補は何か
そこで、本文とは別に、記事の状態や運営上の判断を管理する場所を分けています。
| 管理するもの | 役割 |
|---|---|
| 記事本文 | 読者が読む内容を管理する |
| 記事台帳 | 記事ID、タイトル、状態、URLを確認する |
| 内部リンク台帳 | 記事間のリンクと候補を管理する |
| Next Actions | 次に行う作業を管理する |
| Weekly | その時点の判断や経過を履歴として残す |
| 公開後同期 | 公開日、URL、関連記事、次回確認事項を反映する |
この分け方にしておくと、本文を修正しない作業も管理しやすくなります。
たとえば、記事を公開した後に正式URLを台帳へ反映する作業と、本文へ新しい内部リンクを追加する作業は、同じ「公開後の作業」でも別の判断が必要です。管理情報を分けておけば、どこまで終わっていて、何がまだ残っているかを確認できます。
記事台帳や公開後同期の詳しい考え方は、ブログ公開後にCodexへ情報を同期する運用で扱っています。今回の環境では、公開して終わりにせず、公開後の情報を次の改善へ戻すことを重視しています。
2. 読者導線を役割ごとに分けた
内部リンクやCTAは、数を増やせばよいわけではありません。同じ記事へのリンクを本文、自動関連記事、CTAで何度も強調すると、読者にとっては何を優先すればよいのか分かりにくくなります。
そこで、リンクの目的ごとに役割を分けています。
| 導線 | 役割 |
|---|---|
| 本文リンク | 文章の流れの中で補足記事を案内する |
| RelatedLinks（自動関連記事） | 記事末尾で関連する記事をまとめて案内する |
| NextArticleBox（次に読む記事の案内） | 読了後に次に読む1記事を示す |
| ArticleCTA（記事用の主導線） | 記事全体として促したい主な行動を案内する |
| ProductCTA（商品用の導線） | 商品やテンプレートを紹介する |
たとえば、ChatGPTとCodexの役割分担を説明している段落で、詳しい解説記事を1本だけ本文リンクとして案内します。そのうえで、記事末尾に同じ記事をもう一度NextArticleBoxで表示するかどうかは、全体の導線を見て判断します。
商品を紹介する記事ではProductCTAを主導線にします。一方、運用方法を説明するpractical記事では、商品CTAを無理に置かず、本文の理解を助ける関連記事を優先します。
こうした役割分担は、見た目の整理だけが目的ではありません。読者が「次に何を読めばよいか」「商品を確認する場面なのか」「補足情報を読む場面なのか」を判断しやすくするためです。
3. ChatGPT・Codex・人間の役割を整理した
Astroへ移行した後も、ChatGPTとCodexを同じ用途で使っているわけではありません。作業の段階によって、担当を分けています。
| 担当 | 主に任せていること |
|---|---|
| ChatGPT | 調査、記事設計、論点整理、判断材料の整理、レビュー |
| Codex | ファイル確認、記事作成、既存ファイルの修正、差分確認、build確認 |
| 人間 | 実体験の確認、事実確認、表示確認、公開判断 |
ChatGPTには、記事で何を主張するか、既存記事とどこで差別化するか、どの情報が不足しているかを相談します。Codexへ依頼する前に、作業の目的や変更範囲を整理する役割です。
Codexには、対象ファイルを確認し、決まった方針に沿って記事や管理情報を作成・修正してもらいます。必要に応じて、変更差分やbuild結果も確認します。
最後に、実際に自分が経験したことか、事実と合っているか、表示が意図どおりかを人間が確認します。AIが自然な文章を作れても、それが自分の経験として正しいとは限らないからです。
ChatGPTで整理してからCodexでファイル作業を行う往復の流れは、ChatGPTとCodexをブログ運営でどう使い分けているかで詳しく説明しています。この記事では、その役割分担をAstro移行後の管理環境に組み込んだ点に絞ります。
4. 変更しやすいブログ環境を作った
移行後に意識したのは、何でも自由に変更できることではありません。どこを変更すれば、どこに影響するのかを確認しやすくすることです。
共通部分はComponentで管理する
記事ごとに同じ表示用HTMLを直接書くのではなく、共通して使うものはComponentとして管理します。
現在は、新規記事で記事タイプや用途に応じて、InfoBox、ArticleCTA、ProductCTA、NextArticleBox、RelatedLinksなどを使い分ける構成にしています。
たとえばCTAの表示を変更したいとき、各記事の本文を一つずつ探して修正するのではなく、共通Componentの責務と記事側の設定を分けて考えられます。新規記事からこの方式を使い、既存記事は一括変更せず、必要なリライト時に段階的に扱う方針です。
frontmatter（記事の設定情報）で記事ごとの設定を持つ
記事本文とは別に、記事タイプや関連記事、CTAの設定をfrontmatter（記事の先頭に置く設定情報）で管理します。
記事本文は読者が読む内容、frontmatterはその記事をサイト上でどう扱うかという設定です。この境界を分けておくことで、文章の修正とサイト上の表示設定を別々に確認できます。
ただし、設定項目を増やせば管理しやすくなるわけではありません。使わない項目や、意味が重複する設定を増やすと、かえって確認対象が増えます。必要な記事だけに任意設定を追加し、既存記事へ一括適用しないことも重要だと考えています。
Git・build・previewで確認する
Codexに変更を依頼する場合は、変更後の状態を確認できることが欠かせません。
基本的には、次の流れで確認します。
- 変更したい内容と対象範囲を決める
- Codexに関連ファイルを確認してもらう
- 変更差分を確認する
- build（公開用サイトの生成）でエラーがないことを確認する
- preview（公開前のプレビュー）で表示を確認する
- 事実関係と公開可否を人間が判断する
Gitは変更履歴を残すために使っています。buildが成功したから内容が正しいとは限らず、previewで表示できたから公開してよいとも限りません。それぞれを別の確認として扱うことで、確認漏れを減らしやすくしています。
5. AIを使うほど確認ルールが重要になった
AIに任せる範囲を広げると、作業そのものは依頼しやすくなります。一方で、依頼内容が曖昧なままだと、意図しないファイルまで変更されたり、既存ルールと矛盾する提案が出たりします。
そのため、依頼時には次のような情報を明確にするようにしています。
- 何を達成したいか
- どのファイルを対象にするか
- 変更してよい範囲はどこか
- 変更してはいけないものは何か
- 完了後に何を確認するか
たとえば、記事の設計を決める段階であれば、本文やAstroコードを変更しないと明記します。実装を依頼する段階であれば、変更対象を限定し、buildや表示確認までを完了条件に含めます。
AIにすべてを任せて、人間が結果だけを受け取る運用にはしていません。AIが作業し、人間が確認するという単純な分担でも、確認項目が決まっていなければ、確認したつもりになってしまうからです。
Codexに任せない作業と、人間が確認を残す理由については、ブログ運営でCodexに任せない作業｜完全自動化にしない理由と人間が確認するポイントで詳しく整理しています。
6. まだ検証中のこと
移行後は、記事やサイトを同じ作業の流れで扱いやすくする構成にしています。ただし、それだけで成果が改善したとは判断していません。
現時点では、次の項目を検証中です。
| 検証項目 | 現時点の扱い |
|---|---|
| 長期的な作業時間 | 確定した短縮効果はまだ測定していない |
| 検索流入・SEO | 移行後の変化を長期比較していない |
| 記事間の回遊 | 回遊率の改善を確認できるデータは未整理 |
| CTAクリック | CTAごとの十分な比較期間がない |
| 収益 | 移行による増加とは判断していない |
| 記事数増加後の管理負荷 | 新規記事を増やしながら継続確認する |
Astroへ移行したことや、Codexに作業を依頼できるようになったことだけを、PVや収益の原因とは考えないようにしています。検索順位や収益には、記事内容、公開時期、検索環境、導線、読者の状況など複数の要因が関係するためです。
今後は、記事数が増えたときにも管理情報や導線の整理が維持できるか、実際の運用を続けながら確認していきます。
まとめ：移行後に改善し続けられる環境を整えた
Astro移行の目的は、ブログを引っ越すことだけではありませんでした。記事の追加、過去記事の修正、内部リンクの整理、サイト側の変更を続けやすい運営環境を作ることが目的でした。
そのために、記事本文と管理情報を分け、読者導線を役割ごとに整理し、ChatGPT・Codex・人間の担当を分けました。Component、frontmatter、Git、build、previewも、技術要素として個別に導入したのではなく、変更範囲と確認工程を管理しやすくするために使っています。
もちろん、完全自動化や放置運営になったわけではありません。実体験、事実関係、表示、公開可否を確認する役割は人間に残しています。
現時点で言えるのは、移行後のブログを改善するための土台を整えたということです。PV、SEO、回遊、収益、作業時間がどう変わるかは、これからの運営で検証していきます。