WordPressから移行して、Coding Agentと書けるブログを作った

はじめに

私は2017年からブログを書いている。2018年には、論文から化学物質名を抽出する自然言語処理のベンチマークにも取り組んだ。この定点観測については、LLMに推論させるより実装させろにも書いた。いまAI for Scienceを事業にしているが、その出発点の一つは、学生の頃から論文を対象に機械学習を試してきたことにある。

そのブログを、WordPressから移行した。

WordPressが嫌いになったわけではない。長い間使ってきたし、ブラウザから記事を書いて公開するには十分便利だった。ただ、Coding Agentを開発だけでなく執筆にも使うようになると、前提が変わった。

Coding Agentが力を発揮するのは、ファイルを読み、差分を作り、テストを実行し、履歴を残せる環境だ。一方、WordPressはGUIを開き、エディタやメディアライブラリを操作することが中心になる。APIをつなぐ方法もあるが、既存のプラグインやサーバーの状態まで含めて、エージェントが安全に扱える形とは言いにくい。

そこで、ブログを「記事を入力する画面」ではなく、自分とCoding Agentが一緒に運用する執筆基盤として作り直すことにした。

移行先をどう選んだか

最初に決めたのは、技術名ではなく要件だった。

記事がMarkdownとして保存され、Gitで差分を確認できる
タイトル、公開日、タグ、出自、旧URLなどが構造化されている
記事の追加やURLの生成を機械的に検証できる
動的なサーバーを運用せず、個人のドメインを継続して使える

この要件に対して、フロントエンドには Astro、配信には Cloudflare Workersのstatic assets を選んだ。Astroはcontent collectionsによって、Markdownのfrontmatterをスキーマとして検証できる。記事を単なるテキストではなく、AIが読み書きしやすいデータとして扱える点が決め手だった。

候補を比較した2026年7月24日時点で、AstroはGitHub Starsが61,259、npmの週間ダウンロード数が435万だった。Next.jsはアプリケーション基盤としては強力だが、静的な個人ブログには過剰だった。Hugoも有力な選択肢だったが、すでに社内の別サイトでAstroを使っており、知見と検証資産を共有できる。普及度と必要性の両方を見て、Astroに決めた。

配信は、記事をビルドして静的アセットとして置ければよい。データベースもログインも必要ないため、Cloudflare Workersで十分だった。ブログのドメインは2017年から使ってきたroy29fuku.comを継続し、個人のCloudflareアカウントに分離した。

ブログではなく、執筆基盤として設計する

今回の移行で大事だったのは、Astroを選んだことだけではない。記事がどこで生まれ、どこで公開されるかを分けたことだ。

下書きはpersonal repoのoutput/に置く。ここをpreprintサーバーとみなし、考え途中の記事も含めて集約する。完成した記事をblog repoへ投稿し、公開後の正版はblog repoで管理する。下書きと公開版を双方向に同期しないことで、「どちらが正しい記事か」が曖昧にならない。

blog repoの記事には、本文だけでなく次のような情報を持たせる。

title: "記事のタイトル"
date: 2026-08-19
tags: ["Astro"]
source: "wordpress"
oldUrl: "/旧ブログのURL/"

sourceがあれば移行元を追跡できる。oldUrlがあれば、旧URLから新URLへの301リダイレクトを生成できる。人間が管理画面を見ながら一つずつ対応表を作るのではなく、記事データからサイトの振る舞いを生成する設計にした。

これは、Coding Agentにとっても重要だ。Agentは「この画面を開いて、この記事を探して、画像をアップロードして」と指示されるより、スキーマのあるファイル群とテストを渡された方が、変更の影響範囲を把握しやすい。

7月24日から25日未明までにやったこと

長々と全過程を説明する必要はないが、実際にどう進めたかは残しておきたい。移行は次の順序で進めた。

時期	作業
7月24日	ブログの役割、掲載基準、URL方針を決める
7月24日夕方	Astro + Cloudflare Workersのrepoを立ち上げる
7月24日夜	WordPressのエクスポートを解析し、記事と画像のインベントリを作る
7月24日夜〜25日未明	移行対象を選別し、Markdown化・画像移行・301生成を行う
7月25日	astro checkとビルドを通し、移行結果を確認する

WordPressのエクスポートはWXR形式で、12MB、2,055 itemあった。主な内訳は公開記事184、下書き49、固定ページ10、添付1,809だった。しかも、XML宣言より前にPHPのWarningが混入し、本文には不正な制御文字も含まれていた。そのままでは正しくパースできないので、入力を正規化してから解析した。

画像はWXRに含まれず、記事から参照されるURLしか残らない。X Serverを解約する前に、uploadsを2,518ファイル、260MBのミラーとして保全した。移行対象の記事が参照する画像は、そのミラーから1,166点を新ブログへコピーした。

記事はすべて移したわけではない。サイトの役割を「Science Aidの活動と、私の仕事の哲学を伝える場」と定め、技術記事は過去からの専門性を示すものとして残した。一方、役割に合わないものや空のページは削除した。Swampdogの33回、SummerEyeの14回の連載は、そのまま記事を増やすのではなく、それぞれ一つのまとめ記事に集約した。

最終的に、WordPress由来の記事は133本になった。旧ブログのURL構造は整理されていない部分があったため、そのまま引き継がず、スラッグを再設計した。旧URLからの301リダイレクトは、記事・連載の集約・固定ページなどを含めて最終的に194件になった。

移行後はastro checkを通し、ビルドも成功した。WordPressの管理画面を再現するのではなく、記事データと生成処理に置き換えたことで、移行作業そのものもテスト可能になった。

Coding Agentに任せたこと、人間が決めたこと

Coding Agentには、エクスポートの解析、インベントリ作成、Markdown化、画像URLの書き換え、リダイレクト生成、チェックとビルドを担当させた。133本の記事を人間が管理画面から手で移すのは、時間がかかるだけでなく、抜け漏れの検出も難しい。

一方で、何を残すかはAgentに決めさせなかった。技術記事を残すのか、連載をまとめるのか、旧URLを維持するのか、個人のサイトと会社のサイトをどう分けるのか。これらはサイトの役割と、これから何を伝えたいかに関する判断だからだ。

私がやったのは、すべての作業を自分で抱えることではない。判断が必要なところを先に決め、機械的に処理できる部分はAgentに任せ、結果をテストと差分で確認できる状態を作ることだった。

これはWordPressの置き換えではない

今回の移行によって、非技術者が管理画面から記事を編集できるというWordPressの利点は失われた。複数人で日々更新するメディアなら、WordPressや別のGUIベースのCMSの方が適しているだろう。

私の場合は、記事を書く場所とコードを書く場所を分ける理由がなくなっていた。執筆も開発も、調査し、ファイルを変更し、レビューし、履歴を残す仕事になったからだ。

だから、必要だったのは「最新の技術でブログを作ること」ではない。自分の仕事の進め方に対して、古い道具がどこでボトルネックになっているかを見つけ、そのボトルネックを取り除くことだった。

まとめ

2017年から続けてきたブログを、WordPressからAstro + Cloudflare Workersへ移行した。2018年から論文のNLPに取り組んできた経験も、今のAI for Scienceの仕事も、同じ場所に蓄積していく。

これからは、記事をブラウザの管理画面へ貼り付けるのではなく、Gitで管理されたMarkdownとして書く。Coding Agentには、文章の推敲だけでなく、リンクの整合性や構造の検証、公開に必要な実装まで任せられる。

AI Agentという新しい技術が登場したときに重要なのは、Agentに何を尋ねるかだけではない。Agentが仕事をしやすい環境を、自分の仕事に合わせて用意できるかどうかだ。今回の移行は、その環境をブログにも適用した最初の一歩になった。