WordPressとnoteをやめて、AIが読めるブログをAstro + Cloudflare Pagesで作った話

#AI#運用note転載済み

WordPressでブログを運用してきましたが、投稿のハードルが高くて続きませんでした。最近はnoteの投稿の簡単さに惹かれて使い始めたものの、「記事が自分の手元に残らない」ことがずっと引っかかっていました。

そこでブログシステムを根本から見直し、Markdown + Git をマスターにして、Astro + Cloudflare Pages で公開する構成に移行しました。構築の実作業はほぼすべてClaude Codeに任せ、私はPMとして指示を出しただけです。移行はnoteの過去記事の回収まで含めて完了し、いまこの記事自体が新システムからの第1号投稿です。

この記事では、なぜこの構成にしたのか、検討して選ばなかった選択肢、構築と移行で実際にハマった点をまとめます。

判断軸は「AIが読める記事」

きっかけは、ブログ選びの判断軸を「AIが読めるか」に置き換えたことでした。AIとの壁打ちで考えを深め、その内容を記事化する運用が定着してくると、ブログは単なる公開の場ではなく、後でAIに読ませて見直すためのログになります。すると評価基準は次の3つに絞られます。

  1. 記事がプレーンテキスト(Markdown)で存在するか
  2. 全記事・全履歴をローカルで一括取得できるか
  3. 公開ページ自体もAIが解釈しやすいか

この基準で見ると、DBにHTMLを溜め込むWordPressは、後からgrepしたりAIに丸ごと読ませたりするのに最も不向きな形式でした。noteに至ってはマスターが他社のDBにあります。逆に、Markdownファイルの入ったGitリポジトリは、この3基準を素で満たします。

最終的な構成と役割分担

「保存」と「公開」を分離するのが設計の核です。

要素 役割
Markdownファイル 記事の実体。10年後も読める
Gitリポジトリ(非公開) マスター兼永久ログ。git logがそのまま執筆履歴
Astro 静的サイト生成。人間向けHTMLとAI向けMarkdownの二面持ち
Cloudflare Pages ホスティング。push→自動ビルド・デプロイ。保守ゼロ
投稿コマンド(Claude Code製) 貼り付け→整形→commit→push を一撃実行
note 拡散チャネル。届けたい記事だけ転載

構成図: 壁打ちから公開までの流れ

公開サイトはHTMLに加えて、llms.txt(全記事の索引)と各記事のMarkdown原文(記事URL + .md)を配信しています。人間にはHTML、AIエージェントにはMarkdownという二面待ちで、「AIが読めるブログ」を公開面でも実現しています。

日常の運用は2動作だけです。AIと壁打ちして記事Markdownを作り、Claude Codeの /post コマンドに貼り付ける。あとはタグと概要文を1回確認すれば、数分後には公開されています。noteに転載したいときは /note-ver コマンドが、表や脚注をnoteで再現できる形に変換してクリップボードに入れてくれます。

検討して選ばなかった選択肢

WordPressのAI延命。 今はAIがあるので昔は面倒だった保守も楽になるのでは、と当初は考えていました。しかし保守が楽になっても、DBにHTMLが溜まる構造自体は変わりません。保守をAIで楽にするより、保守がほぼゼロの構成をAIで作るほうが筋が良い、という結論になりました。

Ghost・ヘッドレスCMS。 GhostはWordPressよりモダンですが、DB保存でエクスポート依存という弱点は同じです。ヘッドレスCMSはマスターが他社DBにある時点で、今回の判断軸では対象外でした。これらの強み(会員制・課金・共同執筆)は「読者と商売する運営」に効くもので、個人のログには一つも刺さりません。

Quartz(Obsidianベース)。 「後で見直す」重視なら、記事同士をリンクで繋ぐデジタルガーデン型も有力でした。時系列で書き溜めるならAstro、ノートを網目状に育てるならQuartz、という使い分けで、今回は前者を選びました。

GitHub Pages。 アカウントを増やしたくなかったので最後まで迷った選択肢です。ただしGitHub無料プランでは非公開リポジトリからPagesを公開できず、「非公開マスター + Actionsでビルド成果物だけ公開リポジトリへpush」という二段構成が必要になります。認証情報の管理やActionsの静かな失敗など運用中の摩擦が残るため、非公開リポジトリを直結できるCloudflare Pagesを選びました。

余談ですが、かつてWordPressと覇権を争ったMovable Typeは「DBで管理して静的HTMLを書き出す」CMSで、実は静的サイトジェネレータの思想的な先祖にあたります。当時MT派だった人間としては、今回の構成はMTがやろうとしていたことをMarkdown + Gitでやり直す現代版だと感じています。

構築はPM + Claude Codeの分業で

構築作業は4つのPhaseに分け、それぞれをタスクブリーフ(背景・要件・制約・検収基準を書いた指示書)としてClaude Codeに渡しました。

  • Phase 1: Astroセットアップ。Content Collectionsでfrontmatterスキーマを定義し、記事一覧・タグ・RSS・sitemapまで
  • Phase 2: Cloudflare Pages接続と、llms.txt・記事Markdown配信・robots.txtの整備
  • Phase 3: 投稿コマンド3本(/post 公開、/draft 下書き、/note-ver note変換)
  • Phase 4: noteからの過去記事一括移行

人間側の作業は、GitHubリポジトリ作成とCloudflareのGUI操作(合計30分程度)、あとは各Phaseの検収だけでした。ブリーフに検収基準を明記しておくと、Claude Codeが自分で検証してから報告してくるので、受け入れ確認が楽になります。

noteからの移行 — 「エクスポートできない」は過去の話だった

私がnoteを敬遠していた最大の理由は「記事をエクスポートできない」ことでした。ところが調べ直すと、noteは2023年3月に公式エクスポート機能を追加していました。「自分の記事」ページからエクスポートを実行すると、全記事がWXR形式(WordPress形式)のXMLと画像ファイルのZipでダウンロードできます。

エクスポートしたWXRをClaude Codeに渡し、記事ごとのMarkdown変換・画像の取り込み・元の公開日の維持まで一括で処理してもらいました。公開記事は元の公開日順でブログに並び、下書きはリポジトリのdrafts/へ。「移行日に全記事一斉投稿」ではなく、実際の執筆史がそのまま時系列に残る形です。

ただし、エクスポートの品質には注意点がありました。

  • 記事によっては見出しや表が平文化して崩れている。 ある長文記事では、全節見出しが巨大な番号付きリストに潰れ、表が改行の羅列になっていました。「文言は一切変えず、構造(見出し・表・改行)だけ復元する」という指示で修正し、変換前後のテキスト一致をスクリプトで機械検証して原文保全を担保しました
  • アイキャッチ画像は含まれない。 XMLの中身を検査しましたが、アイキャッチに相当するデータは存在しませんでした。必要なら元記事から手動保存するしかありません
  • 埋め込み(YouTube/X等)はURLテキストになる。 公式仕様です。リンクとしては機能するので、埋め込み表示に戻すかは記事ごとに判断

ハマりどころの知見

構築・移行の過程で得た、知らないと詰まりそうな知見です。

  • Cloudflare Pagesは404.htmlがないと、存在しないURLにもトップページを200で返す。 デプロイ検証で誤検知の原因になり、クローラにはsoft-404になります。404ページは最初から作っておくべきでした
  • エッジキャッシュは削除に勝つ。 長いs-maxageでキャッシュされたページは、記事を削除して再デプロイしても消えません。_headers でHTMLを max-age=0, must-revalidate にし、ハッシュ付きアセットだけ長期キャッシュする設定を最初から入れておくのが正解です。なお *.pages.dev のサブドメイン運用では手動キャッシュパージは使えません(独自ドメインのゾーン機能のため)
  • 日本語Markdownでは約物と強調が衝突する。 **「...」**の のような並びはCommonMarkの仕様で強調が成立せず、** が生のまま表示されます。移行時はこの箇所だけ <strong> タグにフォールバックしました
  • Cloudflare連携のGitHub権限は「Only select repositories」で絞る。 デフォルトの「All repositories」はコードの読み書きを含む強い権限を全リポジトリに恒久付与してしまいます

おわりに

移行を終えて、ブログは「運営するもの」から「書いて放り込むもの」に変わりました。WordPress時代に投稿を妨げていた管理画面・整形・保守は人間側の作業から消え、残ったのは壁打ちと貼り付けだけです。

そして何より、過去のnote記事も含めた全記事が、Markdownファイルとして手元のGitに揃いました。この記事もそのリポジトリの1ファイルです。仮に将来AstroやCloudflareをやめたくなっても、フォルダごと次の環境に持っていくだけ。撤退コストが最小の構成は、選定を間違えても傷が浅い構成でもあります。

ブログが続かない理由が「書くのが嫌」ではなく「投稿と管理が嫌」なのであれば、AIに実装と事務を任せてMarkdown + Gitに引っ越す選択肢は、思っているよりずっと現実的になっています。