チームの準備が整ったら、あとは作るだけです。第5回では、WordPress → Astro 移行の全工程を日ごとに振り返ります。
前回までで、CLAUDE.md によるルール定義・Skill/Hook/MCP の設定・サブエージェントチームの編成が完了していました。この状態から、12ページのサイトを実質4日間で完成させ、本番に切り替えました。何をどの順序で進めたか、技術的な決定の理由と一緒に記録します。
Day 1：インフラ設計と技術選定
最初の1日は、ほぼ設計と環境構築に費やしました。
決定した構成はこうです。
dreamsound-ltd.com
├── /* → Cloudflare Pages（Astro SSG）
└── /wp-admin* /wp-json* /wp-content* /graphql*
→ Cloudflare Worker → ConohaVPS（WordPress）Astro を選んだ理由は「ビルド時に全ページを静的生成する」アーキテクチャにあります。WordPress が持つコンテンツ（ブログ・プロジェクト事例）は WPGraphQL で取得し、ビルド時に HTML に焼き込みます。サーバーサイドの処理がゼロなので、Cloudflare のエッジからそのまま配信できます。
WordPress は既存の ConohaVPS でそのまま動かし続けます。コンテンツ管理・MCP 操作・フォームの受け取りはすべて WordPress の仕事です。Astro はその「表示層」だけを担います。
DNS 設定と GitHub Actions デプロイの設計、Cloudflare Worker の実装（WP パスのプロキシ）も Day 1 に済ませました。
Day 2：12ページの全実装
Day 2 は最も作業量が多い日です。
Home / About / Expertise×4 / Projects（一覧・個別）/ Contact / News（一覧・個別）/ Privacy Policy の全12ページを実装しました。コンポーネントは最終的に30以上になりました。CSS は variables.css（デザイントークン）→ global.css → utilities.css → ページ別・セクション別ファイルの階層で管理しています。
設計の原則はひとつ：コンポーネントファーストで作る。ページ内に直書きしてから分解すると、後から再利用できなくなります。CtaPrimary・TestimonialCard・ProjectCard のような再利用コンポーネントは、最初のページを作る時点で src/components/ に切り出しました。
WordPress からのデータ取得は GraphQL クエリ8関数にまとめ、すべて src/lib/queries.ts に集約しました。型安全のために graphql-codegen も導入し、WPGraphQL スキーマから 12,163 行の型定義を自動生成しています。
Day 3：SEO・アクセシビリティ・フォーム
機能的に動くものができたら、品質を上げる作業に移りました。
SEO では JSON-LD を全ページに実装しました。Article（記事）・Organization（組織）・FAQPage・BreadcrumbList など、ページの種類に合わせたスキーマを Layout.astro と各ページに組み込みました。@astrojs/sitemap でサイトマップも自動生成され、WP 記事公開時に Cloudflare Pages が自動再ビルドされる仕組みも整えました。
アクセシビリティ は WCAG 2.1 AA 準拠を目標にしました。スキップリンク・フォーカスアウトライン・コントラスト比修正・キーボードナビゲーション対応、モバイルメニューの inert 属性対応を実施しました。
フォーム は WordPress 側にカスタム REST API エンドポイントを作り、Astro の SSG から fetch() で POST 送信する構成にしました。GA4 の generate_lead イベントも同時に設置し、送信成功時に自動でコンバージョン計測が走ります。
Day 4：本番切り替えとパフォーマンス改善
Cloudflare Pages のステージング URL（pages.dev）で全12ページを確認してから、DNS の CNAME を切り替えました。切り替え自体は5分以内に完了します。Expertise ページのスラグは /expertise/web/ から /expertise/web-development/ のように変更しましたが、ブログやプロジェクト事例の URL はそのまま維持しています。
本番になってから PageSpeed を計測すると、FCP 6.5 秒・LCP 8.0 秒という数字が出ました。CSS バンドル 50.1KB がレンダーブロッキングを 4,800ms 引き起こしていたのが主な原因です。
対策は astro-critters の導入です。ビルド時にクリティカル CSS を自動でインライン化し、残りの CSS を非ブロッキングで読み込む方式に切り替えます。astro.config.mjs の integrations に追加するだけで動きました。
合わせて Google Fonts から @fontsource self-host に移行（フォントを同一ドメインから配信）、Font Awesome CDN を非同期ロードに変更、Cloudflare Email Obfuscation を無効化しました。Cloudflare が Email Obfuscation を有効にしていると email-decode.min.js が同期挿入され、TBT が 310ms 悪化します。
改善後の計測値は FCP 4.8 秒・LCP 5.4 秒・TBT 0ms・CLS 0.006 でした。
4日間で何が変わったか
WordPress のテーマを書き換えていた状態から、Astro + Cloudflare Pages のヘッドレス構成に移行しました。変わったのは「表示の仕組み」だけで、コンテンツ管理・ドメイン・メール・フォームは WordPress がそのまま担い続けています。
本番に切り替えてから問題が見つかってもすぐ直せる、という体制を先に作っておいたことが大きかったと思います。GitHub push → Cloudflare Pages 自動デプロイの仕組みがあったので、修正から反映まで数分です。
次回予告
最終回では、数値で成果を振り返ります。FCP・LCP・TBT の Before/After、SEO 実装の全リスト、そして「AI PM + 並列エージェントで何が変わったか」の総括をまとめます。