公開したばかりのWordPressサイトをAIと一緒にAstroへ移行してみた【前編】環境構築とデータの取り出し
はじめに
WordPressで作ったWebサイトを公開したばかりなのですが、Astroへの移行を始めました。
「えっ、公開したばかりなのに？」
自分でもそう思います。
WordPressに大きな不満があったわけではありません。これまでWebサイト制作で使ってきましたし、テーマやプラグインの便利さも知っています。ただ、最近の脆弱性対応をきっかけに、ひとつ疑問が生まれました。
本当に、このサイトにはWordPressが必要なのだろうか？
今回のサイトは、記事の投稿が中心です。会員機能や複雑なデータベース処理が必要なわけではありません。それなら、静的HTMLで運用する方法もあるのでは？
そこで調べていて、Astroという静的サイトジェネレーターを知りました。今回はAIにも相談しながら、WordPressのサイトをAstroに移行してみることにしました。この記事は、その作業記録です。
Astroに詳しい人向けの解説ではなく、私と同じようにWordPressの制作経験はあっても、Astroは初めてという人に向けて書いています。
前編では、Astroの環境構築と、WordPressから移行用のデータを取り出し、AIに分析してもらうところまでを扱います。
1. なぜWordPressからAstroへ？
WordPressは便利。でも保守は必要
WordPressには、記事管理、画像管理、カテゴリー、メニュー、テーマなど、多くの機能が備わっています。一方で、WordPress本体、テーマ、プラグイン、PHPなどの更新や管理が必要です。もちろん、WordPressやPHPそのものが危険という意味ではありません。適切に管理すれば、WordPressは十分に実用的なCMSです。
ただし、更新頻度が少なく、主に文章を公開するだけのサイトでも、同じように保守が必要になります。静的HTMLにすれば、公開サーバー上でWordPressやPHPを実行する必要がなくなり、WordPress固有の攻撃対象を減らせます。そこで、今回はAstroを試してみることにしました。
Astroって何？
Astroは、Webサイトを構築するためのフレームワークです。今回利用するのは、ビルド時にHTMLを生成する静的サイトとしての機能です。例えば、WordPressでは通常、サーバー側でPHPなどを実行してページを表示します。Astroでは、ローカルの開発環境でページを生成し、完成したHTMLやCSSなどを公開サーバーに配置できます。
また、記事をMarkdown形式で管理できることも魅力でした。Markdownとは、次のような記法で文章の構造を表現する形式です。
# 記事タイトル
## 見出し
ここに本文を書きます。
- 項目1
- 項目2
WordPressの管理画面を使わずに、記事をファイルとして管理できます。
2. まずNode.jsを準備する
Astroを使用するには、対応するバージョンのNode.jsが必要です。Node.jsは、ブラウザの外でもJavaScriptを実行できる環境です。npmは、JavaScriptのパッケージを管理するためのツールで、通常Node.jsと一緒に導入されます。
最初に、Macのターミナルで確認します。
node -v
npm -v
両方のバージョンが表示されれば、ひとまずコマンドは使える状態です。ただし、Astroが要求するNode.jsのバージョンを満たしているかも確認してください。インストールされていない場合は、Node.jsの公式サイトを確認します。
Node.jsのバージョンを切り替えたい場合は、nvmという管理ツールを使う方法もあります。
今回はnvmを利用する環境で作業しました。
3. ブログ用テンプレートを使ってAstroをインストールする
今回はWordPressで運用していたブログをAstroへ移行するので、最初からブログ用のテンプレートを使用することにしました。
Astroには、プロジェクト作成時にテンプレートを指定する機能があります。
今回実行したコマンドはこちらです。
npm create astro@latest -- --template blog
--template blog は、ブログ用のテンプレートを指定するオプションです。
最初からすべてのファイルを作るのではなく、用意されたブログの構成をベースにして、必要な部分を変更していくことにしました。
プロジェクトを作成したら、作業ディレクトリに移動します。
cd プロジェクト名
開発サーバーを起動します。
npm run dev
ブラウザに表示されたローカルURLへアクセスし、Astroのページが表示されれば、ひとまず準備完了です。Git管理をしているので、ここで最初のコミットを行いました。
なお、今回は最終的にWordPressのSWELLのデザインを再現する方針から、オリジナルデザインへ変更しました。そのため、ブログ用テンプレートはあくまで開発の出発点として利用しています。
4. Macを再起動したらnpmが使えなくなった！
Astroを一度導入し、作業を進めていました。ところが、Macを再起動してターミナルを開き、作業を再開しようとしたところ、次のエラーが出てきました。
zsh: command not found: npm
昨日まで使えていたのに、どうして？
最初は、Node.jsのインストールに問題があったのかと思いました。でも、再インストールする前に、原因を調べることにしました。
4-1. コマンドが見つかるか確認
まず、次のコマンドを実行します。
command -v node
command -v npm
どちらも見つかりません。ただし、これはNode.jsがインストールされていないことを意味するわけではありません。現在のターミナルが、実行ファイルの場所を認識できていない可能性があります。
4-2. PATHを確認する
echo $PATH
PATHは、ターミナルがコマンドを探す場所の一覧です。Node.jsがよく配置される場所も確認しました。
ls -l /opt/homebrew/bin/node
ls -l /usr/local/bin/node
どちらにも見つかりませんでした。ただし、nvmなどを使用している場合、Node.jsは別の場所にインストールされます。
4-3. nvmは存在していた
次に、nvmのインストール状況を調べました。
ls -ld ~/.nvm
ls -l ~/.nvm/nvm.sh
すると、nvmのファイルはいました。つまり、nvmが削除されたわけではなさそうです。そこで、ターミナルを起動したときにnvmを読み込む設定を確認しました。
4-4. .zshrc が存在しなかった
Macの標準的なシェルであるzshでは、.zshrc という設定ファイルが使用されます。
次のコマンドで確認しました。
cat ~/.zshrc
すると、次のエラーが表示されました。
cat: /Users/ユーザー名/.zshrc: No such file or directory
.zshrc がありません。今回の環境では、ここにnvmの読み込み設定を追加することにしました。
4-5. .zshrc を作成する
まず、設定ファイルを作成します。
touch ~/.zshrc
続いて、ファイルを編集します。
nano ~/.zshrc
以下の内容を追加します。
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
これは、~/.nvm にインストールされたnvmを読み込むための設定です。保存したら、現在のターミナルに反映します。
source ~/.zshrc
nvmが使えるか確認します。
command -v nvm
nvm と表示されれば読み込み成功です。
続いて、インストール済みのNode.jsを確認します。
nvm ls
利用可能なLTS版があれば、次のように選択できます。
nvm use --lts
LTS版がインストールされていない場合は、Astroが要求するバージョンを確認したうえで、必要に応じてインストールします。
nvm install --lts
今後のターミナル起動時にも同じバージョンを自動選択したい場合は、次のようにデフォルトを設定できます。
nvm alias default 'lts/*'
これで、再度確認してみます。
node -v
npm -v
無事にバージョンが表示されるようになりました。新しくターミナルを開いても使えることを確認できました。
4-6. 今回の教訓
今回分かったのは、インストールが成功したことと、次回のターミナル起動時にも使えることは別だということです。
Node.jsが使えなくなったとき、すぐに再インストールするのではなく、PATHやnvm、シェルの設定を確認する必要があります。
なお、今回の修正で解決したことは確認できましたが、最初のセッションでnvmがどのように読み込まれていたのかまでは特定していません。
5. WordPressから何のデータを取り出せばいい？
Astroの環境ができたら、いよいよWordPressのサイトを移行していきます。ただし、ここで最初の疑問が出ました。
WordPressから、何を持ってくればいいのでしょうか？
記事だけ取り出せばいいのか。画像はどうするのか。SWELLのデザインはどうしたらいいのか。そこで、AIにサイトの構造を分析してもらいながら進めることにしました。
まず、移行に必要なものを整理します。
| 必要なもの | 取り出す方法 |
|---|---|
| 投稿記事 | WordPressのエクスポート |
| 固定ページ | WordPressのエクスポート |
| カテゴリー・タグ | WordPressのエクスポート |
| 画像 | メディアファイルを別途取得 |
| トップページのデザイン | スクリーンショット |
| ヘッダー・フッター | スクリーンショット・設定情報 |
| メニュー | 設定画面とリンク先を確認 |
| URL一覧 | サイトマップなどを取得 |
ここで注意したいのは、WordPressのエクスポートデータだけでは、サイトの見た目まで再現できないことです。記事データとデザイン資料は、別々に用意する必要があります。
5-1. WordPressからXMLをエクスポートする
WordPressの管理画面を開きます。
「ツール」→「エクスポート」へ移動します。
ここで「すべてのコンテンツ」や「投稿」「固定ページ」などを選択できます。今回は、内容も少なく、コメントも無いので「すべてのコンテンツ」を選びました。
エクスポートファイルをダウンロードすると、XML形式のファイルが保存されます。この形式は、WordPress eXtended RSS（WXR）と呼ばれています。XMLには、記事本文、タイトル、公開日、カテゴリーなどの情報が含まれます。
ただし、画像ファイルの実体やテーマのデザイン設定を丸ごと保存するものではありません。
5-2. 画像も別に取得する
画像は、WordPressのメディアライブラリで管理されています。通常は wp-content/uploads/ 以下に保存されていますが、サイトの設定によって異なる場合があります。
FTPやサーバーのファイルマネージャーなど、利用可能な方法で画像を取得します。元のファイルを消さずに、バックアップとして保管しておきます。
また、画像を取得しただけでは移行完了ではありません。記事本文に記述されている画像URLを、Astro側の配置先に合わせて変更する必要があります。
5-3. デザインはスクリーンショットで記録する
新たにデザインをし直す場合は、修正後のデザインをPNG等の画像にしておきましょう。それかAIにお任せ。（今回は最終的にAIにお任せになりました）
今回のサイトでは、WordPressのSWELLを使用していました。ただし、SWELLのテーマファイルをそのままAstroに移しても、同じようには動きません。
そこで、デザインを確認できる資料を用意します。Chromeのページ丸ごとスクショがとれる拡張機能を使って、トップページ、記事ページ、ヘッダー、フッターなどを、PCとスマートフォンの両方で画像を撮っておきましょう。
特に次の部分は、スクリーンショットが役立ちます。
- ファーストビュー
- ヘッダーとナビゲーション
- 記事一覧
- 記事本文のデザイン
- フッター
- スマートフォン表示
元のデザインを参考にしながら、Astroで再構築していきます。
6. WordPressのXMLをAIに渡してみる
ここからが、今回の移行でAIを活用する部分です。最初から「Astroのサイトを全部作って」と頼むのではなく、まずWordPressのデータを分析してもらいます。その方が、AIも必要なファイル構造やデータの扱い方を判断しやすくなります。
6-1. AIに渡す前に確認する
WordPressのXMLには、公開記事以外のデータも含まれる場合があります。
下書き、非公開コンテンツ、コメント投稿者の個人情報、ユーザー情報、カスタムフィールドなどです。公開されているサイトであっても、XMLに含まれる情報がすべて公開情報とは限りません。
AIにアップロードする前に、不要な情報や個人情報が含まれていないか確認します。クライアントのサイトを扱う場合は、契約やデータの取り扱い条件も確認してください。
6-2. AIに分析を依頼する
必要な情報を確認したら、XMLファイルをAIに添付して、次のように依頼します。
AIへの指示文
このファイルは、WordPressからエクスポートしたXMLです。WordPressで作ったWebサイトを、Astroの静的サイトへ移行したいと考えています。私はWordPressでのWeb制作経験はありますが、Astroは初心者です。
まず、ファイルを分析して以下を教えてください。
- 投稿記事と固定ページの件数
- カテゴリーとタグの一覧
- 公開日とURLの構造
- 画像の参照方法
- WordPress固有のブロックやショートコードの有無
- Markdownへ変換する際に注意する点
この段階では変換しないでください。
まず移行に必要な作業を整理し、問題になりそうな箇所を教えてください。
確認できない情報は推測で補わないでください。
最初から大量のコードを生成させるのではなく、まず今の時点でできることを確認します。
この作業は、人間がWordPressのデータベース構造をすべて把握していなくても、移行の方針を立てやすくするためのものです。ただし、AIの分析結果が必ず正しいとは限りません。元データと照合して確認しましょう。
7. 記事が大量にある場合は？
数件の記事なら、AIにひとつずつ変換してもらう方法もあります。でも、100件、500件と記事がある場合はどうでしょうか。すべての記事をAIに貼り付け、1件ずつMarkdownに変換してもらうのは非効率です。ファイルが大きすぎて、一度に処理できない場合もあります。そこで、大量の記事がある場合は、作業方法を変えます。
AIには変換ルールとプログラムを作ってもらい、記事の変換そのものはプログラムで一括処理する方法です。
例えば、次の流れです。
WordPressからXMLを取得
↓
記事の構造を分析
↓
代表的な記事を1件変換
↓
Astroで表示確認
↓
AIに一括変換プログラムを作成してもらう
↓
すべての記事をMarkdownへ変換
↓
変換できなかった記事を確認
これなら、記事の数が増えても同じ変換ルールを適用できます。ただし、WordPress独自のショートコードやSWELL固有の装飾などは、個別の対応が必要になる場合があります。
大量の記事を変換するときほど、いきなり全件を処理せず、まず1件の変換結果を検証することが大切です。さらにXMLが非常に大きい場合は、最初にローカルのプログラムで記事数や特殊な記法を調べ、代表的なデータだけをAIに渡す方法もあります。
前編のまとめ
今回は、WordPressからAstroへの移行に向けて、環境構築とデータの準備方法を整理しました。
特に印象に残ったのは、一度使えていたnpmが、Macの再起動後に使えなくなったことです。普段WordPressで制作していると、Node.jsやシェルの設定を意識する機会はそれほどありません。ですが、Astroのような開発環境を使うには、こうした部分も理解する必要があります。そして、WordPressのデータを移行するためには、記事本文だけでなく、画像やデザインも別々に考える必要があることが分かりました。
次回の後編では、Markdownへの変換、Astroの記事ページ、トップページ、共通パーツの構築、ビルドと確認までを進めていきます。