要求定義から進めた自社サイトのリニューアル ― WordPress から Astro・Cloudflare Pages へ

2026年10月2日に、弊社の Webサイトをリニューアルしました。

弊社は、システムを「何で作るか」を決める前に、「何を、なぜ実現したいか」を整理する要求定義から関わることを仕事にしています。今回のリニューアルも、同じ進め方で行いました。この記事では、リニューアルを決めた理由と、ゴールの設定から、手段の選定、既存コンテンツの移行、公開後の改善までの流れと、それぞれの判断の理由をご紹介します。Webサイトやシステムの作り直しを検討されている方の参考になれば幸いです。

リニューアルを決めた理由

以前のサイトは WordPress で運用していました。

リニューアルを決めた一番の理由は、ブログからの相談の流れにあります。特に CS-Cart では、ブログ記事を読んでいただき、資料請求、お問い合わせ、デモ、導入へと進んでいただく流れが多くあります。ところが、AI が質問に直接答える検索が広がる中で、この「ブログから資料請求・お問い合わせへ」という入口が、AIO（AI による検索への最適化）の面で十分に整っていないのではないか、という課題を感じていました。記事が AI に正しく読まれ、紹介され、そこから資料請求や相談に進んでいただける形になっていなければ、これまで書いてきた記事が相談につながりません。

あわせて、WordPress での運用では、ここ数年で次の問題も大きくなっていました。

• 記事の更新と運用の負荷が、年々上がっていた: 記事を公開するたびの作業に加えて、本体・テーマ・プラグインの更新と、そのたびの動作確認、サーバーの保守など、記事を書くこと以外の作業が増え続けていました。
• SEO・AIO の面で、WordPress を使う利点が分からなくなっていた: 検索エンジンや、AI が回答を作る検索（AIO は、こうした AI による検索への最適化のことです）で評価されるのは、内容と、速く正しく読めるページです。WordPress であることが有利に働く場面が見えなくなり、運用の負荷に見合っているのか判断できなくなっていました。
• 表示速度の評価が低かった: Google の PageSpeed Insights と同じ評価の仕組み（Lighthouse）で計測すると、以前のサイトのトップページは、スマートフォンで100点中28点でした（2026年7月計測）。
• 作り直しそのものの負荷も高かった: WordPress のままデザインと構成を一新するには、テーマの作り込みと約1,180ページの見直しが必要で、少人数では簡単に踏み切れませんでした。

そこで、生成AIを活用したリニューアルを検討しました。量の多い作業を AI に任せられれば、WordPress を続けるか離れるかも含めて、ゼロから検討し直せると考えたからです。

ゴールは「相談・問い合わせにつながるサイト」

最初に決めたのは、デザインや使う製品ではなく、リニューアルのゴールです。

ゴール: システムやWebサイトの検討を「何を、なぜ実現したいか」の整理から始めたい企業に弊社を見つけていただき、相談・お問い合わせにつなげること

会社のWebサイトには、会社案内や情報発信などいろいろな役割がありますが、弊社にとって最も大切なのは、新しいご相談のきっかけになることです。特に、CS-Cart の「ブログ → 資料請求・お問い合わせ → デモ → 導入」という流れの入口を、確実につなげることを重視しました。そこで、このゴールを達成するために満たすべき条件を、次の4つに整理しました。

1. 見つけていただける: 10年以上にわたって書いてきたブログ記事や CS-Cart のオンラインマニュアルなど、約1,180ページを一つも失わない。検索から記事を読んで弊社を知っていただく方もいるため、URL も含めて残す。あわせて、検索エンジンや AI に記事の内容を正しく読み取ってもらえる形にする。
2. 考え方が伝わる: 要求定義から関わり、課題に合った手段を選ぶという弊社の考え方が、最初に伝わる構成にする。
3. 相談しやすい: ブログ記事から資料請求・お問い合わせへ自然に進めるようにし、サービス・事例への道筋も分かりやすくする。フォームも使いやすくする。
4. 続けられる: 少人数でも更新と運用を続けられるようにし、速く安全に表示できるようにする。

ゴールを決めたことで、条件の優先順位もはっきりしました。最も優先したのは「1. 見つけていただける」です。考え方を伝えるにも、相談していただくにも、まずサイトを訪れていただく必要があるからです。この順位が決まっていたことで、後の判断で迷わずに済みました。

手段は、ゴールと条件が決まってから選んだ

ゴールと条件が決まったので、次に手段を比べました。WordPress を続ける選択肢も、十分に現実的でした。実際、当初は WordPress を使い続ける方針で、テスト環境でデザインの刷新を進めていました。比べたのは次の3つです。

• 案A: WordPress を続け、デザインを刷新する: 管理画面から誰でも記事を書け、長年の運用の経験も活かせます。URL も記事もそのまま残るので、移行のリスクがありません。一方で、更新と保守の負荷はそのまま残ります。
• 案B: WordPress で作り、HTML に書き出して公開する: 記事は今までどおり WordPress で書き、公開するのは書き出した HTML だけにする方法です。表示は速く安全になりますが、WordPress 本体の更新や保守は残り、書き出しの手順も増えます。
• 案C: 静的サイトとして作り直す: ページをあらかじめ HTML として作っておく「静的サイト」の仕組みに、まるごと切り替える方法です。移行の手間はかかりますが、更新と保守の負荷を根本から減らせます。

4つの条件に照らすと、「1. 見つけていただける」はどの方法でも満たせます（作り直す場合も URL を残せば守れます）。差が出たのは「4. 続けられる」です。案A と案B では WordPress の更新と保守が残り、そもそもの課題が解決しません。そこで案C を選びました。

なぜ Astro と Cloudflare Pages の構成にしたのか

静的サイトを作る道具と公開する場所はいくつもあります。その中から、サイトを作る道具に Astro、公開する場所に Cloudflare の配信サービス Cloudflare Pages を選びました。

Astro を選んだ理由

• WordPress の記事をそのまま活かせる: WordPress が出力した記事の HTML を、変換せずに新しいデザインの中へ流し込めます。記事を別の形式に変換すると、数百件分の変換ミスを確認する必要がありますが、この方法ならその心配がありません。「1. 見つけていただける」を最優先にした弊社には、これが決め手でした。
• ページが軽い: Astro は、必要な場合を除いてブラウザで動くプログラム（JavaScript）をページに含めません。表示が速くなり、「速く安全に」という条件に合います。
• ページ数が多くても扱いやすい: 約1,180ページ全体を作り直す処理が、10秒ほどで終わります。修正してすぐに確認できるので、作業が進めやすくなりました。
• ファイルだけで完結する: 記事もデザインもすべてファイルで管理するため、生成AIに作業を任せ、変更点を人が確かめる、という進め方と相性が良い構成です。管理画面が無くても、AI を使えば記事の追加や修正ができます。

Cloudflare Pages を選んだ理由

• 必要な機能が一か所にそろう: ページの配信に加えて、画像の保管（R2）、問い合わせフォームや資料ダウンロードの処理（Pages Functions と D1）、迷惑な送信の防止（Turnstile）、ドメインの管理（DNS）まで、同じ Cloudflare の中で用意できます。サービスを組み合わせる手間と、管理する場所が減ります。
• 速く届けられる: できあがった HTML を世界中の配信拠点から届けるため、表示が速くなります。
• 安全: 攻撃を受けやすい管理画面やデータベースを、インターネットに公開する必要がありません。
• 小さく始められる: 無料プランから始められ、必要に応じて機能を足していけます。

一方で、静的サイトには「管理画面から気軽に記事を書けない」という弱点があります。弊社は管理画面を使わない更新の運用に切り替えることを前提に採用を決め、記事を Markdown で書いて変換する仕組みを用意しました。問い合わせフォームや資料のダウンロードのように、サーバーでの処理が必要な機能は、Cloudflare の機能を使って作っています。

どの手段にも向き不向きがあります。今回の判断は「既存の記事を一つも失わない」「少人数でも続けられる」という弊社の条件に対するものです。管理画面から複数の人が記事を書く体制であれば、WordPress を続けるほうが合う場合も当然あります。

移行で大切にしたこと：URL を変えない

既存の記事を活かすうえで最も気を配ったのが、URL です。URL が変わると、検索結果や他のサイトからのリンクがつながらなくなり、これまで積み上げてきた評価を失ってしまいます。

そこで、記事約690件と固定ページ約270件を含む約1,180ページを、原則として以前と同じ URL のまま移行しました。どうしても変わるページは、新しい URL へ自動で転送するよう設定しています。

移行後は、全ページのリンクを機械的に調べて、リンク切れや表示されない画像をすべて直しました。あわせて、主要なページを複数の画面幅で確認し、公開前に検証用の環境で何度も見直しています。

広告・アフィリエイト・計測も途切れさせない

URL と同じくらい気を配ったのが、ブログの広告やアフィリエイト、アクセス解析や広告の効果測定（トラッキング）です。これらは記事の本文とは別の仕組みで動いているため、本文を移しただけでは引き継がれません。見た目には問題がなくても、収益や計測が知らないうちに途切れてしまうおそれがあります。

• 広告とアフィリエイト: ブログ記事に表示していた Google の広告（AdSense）の枠と、Amazon のアフィリエイトリンクを、新しい記事ページにも同じように組み込みました。
• 問い合わせの効果測定: Google 広告やアクセス解析では、問い合わせや資料請求の完了ページが表示されたことを「成果」として数えています。この設定は完了ページの URL を条件にしているため、新しいサイトでも完了ページを以前と同じ URL にしました。これにより、計測の設定を変えずに、公開した日から成果を数え続けられました。公開直後には、成果が正しく記録されることを確認しています。
• 二重計測と計測漏れの防止: アクセス解析（Google アナリティクス）は、計測タグを一元管理する Google タグマネージャー経由だけで読み込むようにし、同じ訪問が二重に数えられないようにしました。また、テスト用の環境では計測しないようにし、作業中のアクセスが数字に混ざらないようにしています。
• 古い計測の整理: 提供が終了した旧バージョンのアクセス解析のタグが残っていたため、公開後に削除しました。
• 表示速度との両立: 計測タグは表示速度に影響します。後で説明するとおり、公開後に計測タグの読み込みをページの表示後に遅らせました。ただし、成果を確実に数えたい完了ページはこれまでどおりすぐ読み込み、広告の表示にも影響が出ないようにしています。

広告や計測は、止まっても画面上では気づきにくいものです。移行の計画の段階で「何が動いているか」を洗い出しておくことが大切だと感じました。

問い合わせフォームと資料請求の作り直し

サイトの中で最も慎重に扱ったのが、問い合わせフォームと資料請求です。特に資料請求は、実際のご契約につながることが多い、弊社にとって最も大切な入口です。ところが、ここは仕組みが大きく変わる部分でもありました。以前は WordPress のフォーム用プラグインが、入力の受け付け、内容の保存、メールの送信をまとめて担っていましたが、静的サイトにはその仕組みがありません。そのため、フォームまわりはすべて作り直す必要がありました。主な課題と、その解決方法は次のとおりです。

1. 課題: 静的サイトでは、送信された内容を受け付けて処理できない
   解決: Cloudflare のサーバー側の機能で、受け付け・保存・メール送信の仕組みを作り直しました。4種類の資料請求は、1つの共通の仕組みで処理しています
2. 課題: 資料請求からのご相談を途切れさせたくない
   解決: 各資料の申し込みページの URL、入力項目、申し込みから資料を受け取るまでの流れは、以前と変えないようにしました
3. 課題: メールが届かない、迷惑メールに振り分けられる
   解決: メールの送信には新しい送信サービスを使い、送信元を証明する設定（なりすまし対策の認証）を整えました。公開前のテストでは迷惑メールに振り分けられることがあったため、メール内のリンクを本番のドメインにそろえるなどの調整を重ね、受信できることを確かめました
4. 課題: 自動返信の内容や対応が変わってしまう
   解決: 自動返信メールは以前の文面を引き継ぎ、お客様が返信するとそのまま担当者に届くようにしました。返信までの目安（3営業日以内）は、ページとメールで表記をそろえました
5. 課題: 資料の PDF が、申し込みをしていない人にも出回る
   解決: 申し込んだ方だけが、期限付きのリンクからダウンロードできる仕組みにしました。ダウンロードされた回数も分かるようになりました
6. 課題: ボットなどによる迷惑な送信
   解決: 人による送信かを自動で確かめる仕組みと、短時間の連続送信を制限する仕組みを入れました。確認の表示が幅の狭いスマートフォンで画面からはみ出す問題も、表示を小さく切り替えて解消しました
7. 課題: 入力の誤りで、せっかくの入力が無駄になる
   解決: 入力に誤りがあったときは、入力内容を保ったまま画面上でお知らせするようにしました
8. 課題: どこから来た方の問い合わせか分からない
   解決: 問い合わせの直前に見ていたページや、広告などの流入元を、問い合わせと一緒に記録するようにしました

テストのしかたにも注意が必要でした。本番の完了ページを開くと、それだけで広告の成果として数えられてしまいます。そのため、完了画面の表示は本番では確認せずテスト用の環境で確かめ、本番での送信テストで登録したデータは確認後に削除しました。

フォームは、画面を見ただけでは正しく動いているか分かりません。送信から、保存、メールの到着、資料のダウンロード、成果の計測まで、一連の流れを実際に通して確かめることが欠かせませんでした。

約1,180ページの移行は、AI を使っても簡単ではなかった

ページ数の多いサイトを、仕組みごと移し替えてリニューアルするのは、負荷の高い作業です。生成AIを使ったからといって、簡単に終わったわけではありません。7月末に WordPress を続ける方針から切り替えてから公開まで、約2か月かかりました。手間がかかったのは、例えば次のような点です。

• 見えていなかった機能の再現: 記事の末尾の関連記事、ブログカード（記事内の他記事へのリンクを画像付きで表示する部品）、マニュアルの章ごとのナビゲーションは、記事の本文ではなく WordPress のテーマが自動で付けていたものでした。本文を移しただけでは消えてしまうため、新しい仕組みで作り直しました。
• 大量の画像の移し替え: 記事で使っている画像、約10,600点（約870MB）を新しい保管場所に移し、すべてのページで表示されることを確かめました。
• 使ってみて初めて分かる不具合: サイト内検索は、試験的に作った段階では問題なく見えましたが、全ページを入れて試すと、例えば「マーケットプレイス」で約260ページが該当するのに4件しか見つからないことが分かりました。カタカナの長い言葉を正しく探せない問題で、検索の仕組みを手直ししました。
• 止めてはいけないものの引き継ぎ: 前の節の広告・計測に加えて、ドメインの管理を移すときは、会社のメールが止まらないよう、設定を1件ずつ照合しました。
• 確認の量: 全ページのリンクを機械的に調べたうえで、主要なページはスマートフォンからパソコンまで5つの画面幅で、公開前に何度も見直しました。

そして、これだけ確認しても、公開後に表示速度の問題が見つかりました（次の節で説明します）。ページ数が多いほど、移す前に何があるかを洗い出し、移した後に一つずつ確かめる作業が増えます。リニューアルの負荷の大部分は、作ることよりも、この洗い出しと確認にあると感じました。

生成AIは作業を速くするが、決めるのは人間

今回のリニューアルでは、生成AI（Claude など）を積極的に活用しました。既存ページを取り込む仕組みの作成、全ページのリンク確認、画面の検証、公開後の計測と原因の調査など、量が多く手間のかかる作業を AI に任せています。AI がなければ、少人数でこの規模の移行に取り組むことは難しかったと思います。

それでも、決めるのは人間です。AI は選択肢を並べ、作業を進めてくれますが、何を目指し、何を優先し、何を受け入れるかは決めてくれません。今回、人が決めたことの例を挙げます。

• ゴールと優先順位: 「相談・お問い合わせにつなげる」をゴールにし、「記事を一つも失わない」を最優先にしたこと
• 手段: WordPress を続ける案と比べたうえで、静的サイトへの作り直しを選んだこと
• 何を残し、何を残さないか: 記事はすべて残す一方、利用の少なかった記事のタグ一覧ページは移さない、といった線引き
• 伝え方: トップページの文章や、特定の製品を前面に出さないという表現の方針
• トレードオフ: 表示速度を上げるために本文のフォントを端末のものに切り替えたことや、計測タグの読み込みを遅らせ、表示直後に離れた訪問の一部が計測されなくなることを受け入れたこと
• 公開の判断: 本番に公開してよいかどうか

また、AI の作業結果や報告が実際と違っていたことも一度ではありませんでした。そのため、AI の報告をそのまま信じず、実際の画面や数値で確かめることを徹底しました。AI を使うと作業は速くなりますが、決めることと確かめることは減りません。むしろ、AI が速く大量に作業する分、人が決め、確かめる量は増えるとも言えます。

これは、弊社が仕事の中心にしている要求定義と同じ考え方です。「何を、なぜ実現したいか」を決めるのは、AI ではなく、事業に責任を持つ人です。

公開後に、表示速度を改善した

公開後に、Google の PageSpeed Insights（表示速度を評価するツール）でトップページを計測したところ、スマートフォンでの評価は 100点満点中 56点 でした。公開前の検証環境ではもっと良い値が出ていたため、原因を調べました。

原因は2つありました。

1. 日本語のWebフォント: 本文用の日本語フォントを、トップページだけで約1.27MB読み込んでいました。日本語は文字の種類が多いため、フォントのファイルが大きくなりがちです。本文は端末に入っている日本語フォント（ヒラギノ角ゴシック、游ゴシックなど）で表示するように変え、見出しの明朝体だけを Webフォントで読み込むようにしました。これでフォントの読み込みは約0.19MBになりました。
2. 計測用のタグ: アクセス解析や広告の計測に使うタグが、ページの表示と同時に読み込まれていました。ページの表示が終わってから読み込むように変えました。問い合わせの完了画面など、確実に計測したいページは、これまでどおりすぐ読み込みます。

この2つの改善で、評価は 56点から85点 になりました。

項目（スマートフォン・トップページ）	改善前	改善後
PageSpeed Insights の評価	56点	85点
最初に内容が表示されるまで（FCP）	10.4秒	2.9秒
主要な部分が表示されるまで（LCP）	10.4秒	3.5秒

※ 2026年10月6日・7日に計測。PageSpeed Insights の値は、計測するたびに多少変わります。

公開前の環境と本番では、読み込むものが違うことがあります。公開した後にも実際の環境で計測して、問題があれば直すことが大切だと改めて感じました。

新しいサイトで変わったこと

最初に決めた4つの条件に対して、新しいサイトでは次のように対応しました。

1. 見つけていただける: 約1,180ページを原則として同じ URL のまま移行し、日本語で検索できるサイト内検索も設けました。記事には、検索エンジンや AI が記事の種類・公開日・ページの位置づけを読み取れる情報（構造化データ）を付け、表示も軽くしました。
2. 考え方が伝わる: トップページの冒頭で、要求定義から関わる弊社の考え方をお伝えするようにしました。
3. 相談しやすい: ブログ記事の最後に、記事の分野に合わせた案内を出すようにしました。例えば CS-Cart や EC の記事では、資料請求や EC 構築のご相談へ進めるようにしています。記事の下には関連記事も表示し、サービスの選び方、導入事例、資料請求、お問い合わせへの道筋も整理しました。フォームは、入力に誤りがあった場合に入力内容を保ったまま画面上でお知らせします。
4. 続けられる: 静的サイトに切り替えて更新と保守の手間を減らし、公開後の改善で表示速度も高めました。

ゴールに近づいているかどうかは、今後、ブログからの資料請求・お問い合わせの件数と、検索や AI からの訪問数で確かめていきます。AIO の効果は、まだ見えるまで時間がかかると考えています。

Webサイトやシステムの作り直しをご検討の方へ

リニューアルや移行は、「何を使うか」から考え始めると、後から要求に合わないことに気づいて手戻りが起きがちです。まず「何を、なぜ実現したいか」を整理し、優先順位を決めてから手段を選ぶことで、判断に迷わずに進められます。

また、ページ数の多いサイトやシステムの移行では、今あるものの洗い出しと、移した後の確認に大きな手間がかかります。生成AIは作業を速くしてくれますが、この手間をなくしてくれるわけではありません。何を残し、何を確かめるかを、人が最初に決めておくことが、移行を成功させる鍵になります。

弊社は、要求定義から、手段の選定・構築・公開後の改善まで一貫してお手伝いしています。Webサイトやシステムの作り直しをご検討の際は、お気軽にお問い合わせください。