WordPressからAstroへ。ブログの移行とAIによる編集補助の注意点

WordPressからAstroへ移行し、ブログの記事をMarkdownファイルで管理する形に変えた。記事やサイトの修正にはAIエージェントも使った。ただし、ファイルの編集や公開処理を省力化できることと、記事の内容を確かめることは別の作業だ。

記事をファイルとして管理する

WordPressでは、管理画面とデータベースを使って記事を管理していた。移行後は、本文、タイトル、公開日などをMarkdownファイルへ保存し、Astroで表示用のページを生成する。

移行前	移行後
管理画面で記事を編集する	Markdownファイルを編集する
記事データをデータベースへ保存する	記事ファイルを保存する
サーバーでページを組み立てる	ビルド時に静的ページを生成する

ファイルで管理すると、変更箇所を比較しやすくなる。一方で、ビルド設定、リンク、画像、公開先の確認は残る。静的サイトにしただけで保守が不要になるわけではない。

AIの下書きと、公開できる原稿を区別する

AIは文章や修正案を出せるが、もっともらしい文章に誤った事実や存在しない出典が含まれることがある。生成結果をそのまま記事として採用せず、運営者が内容を理解して判断する必要がある。

記事の確認では、少なくとも次を分けて扱う。

• 数値、日付、サービスの仕様を、公式資料や一次情報と照合する。
• 引用元が実在し、記述の根拠になっているかを読む。
• 体験談は実際に提供された経験に限り、未経験の利用や成果を作らない。
• 画像や文章の利用条件、引用の範囲、個人情報の扱いを確認する。
• 読者の疑問に具体的に答えているか、内容の重複や根拠のない断定がないかを編集する。

リンクが開くことや、ビルドが成功することだけでは、本文の正しさを確認できない。AIに「正しいか」と聞き直すだけでも、独立した裏づけにはならない。根拠を確認できない記述は掲載を保留する。

公開処理を自動化しても、内容の責任は残る

移行当時は、合図のファイルをサーバーが検知してビルドと配信を行う構成だった。2026年10月現在の公開経路は、非公開GitHubリポジトリのmainへのpushをCloudflare Pagesが受け取ってビルド・配信する形に変わっている。

どちらも、承認された原稿を配信するための処理であり、原稿の品質を保証する仕組みではない。公開前には原稿と変更差分を確認し、公開後には対象ページが表示されることを確かめる必要がある。

AIへ渡す権限を狭めることは、誤操作の影響を抑える助けになる。しかし、公開権限があれば誤った情報を配信できる。権限制限だけで安全を保証せず、対象の確認、変更履歴、復旧方法も用意する。

公開済みURLを維持する

移行では、既存の記事URLと公開日を維持した。仕組みを変えるたびにURLまで変えると、検索結果や他サイトからのリンクが届かなくなるためだ。

内部の構成を変える場合も、読者が記事へ到達できることを確認する。今回の訂正でも、この記事のURLと初回公開日は変更していない。

記事をファイルで管理する方式には、変更を追いやすい利点がある。その利点を活かすには、生成や配信の速さだけを追わず、原稿の根拠を確かめ、誤りがあれば訂正する作業を続ける必要がある。