WordPressをやめて、会社サイトをAzureの静的サイトに移しました。決めてから切り替えまで2日で何をしたか

当サイトBizMeowの運営会社サイト（株式会社テクノスイッチ）は、2026年10月9日の午前に WordPress から Azure へ移りました。見た目も URL も変わっていないので、気づいた方はいないと思います。変わったのは中身で、WordPress も PHP もデータベースも、もうこのサイトにはありません。

もともと 11月17日に切り替える計画でした。それを 5 週間前倒しして、10月8日に着手し、翌 9日に切り替えました。この記事では、なぜ急いだのか、2 日間で何をしたのか、何がうまくいかなかったのかを、時刻と数字を添えて書きます。「うちの会社サイトも WordPress だけど、誰が面倒を見ているのか分からない」という経営者・総務の方に向けた記事です。

なぜ急いだのか

理由は 2 つあります。

1 つ目は、WordPress を公開面に置いておくリスクが、この数か月で一段上がったと判断したことです。

直接のきっかけは 2026年10月7日でした。この日の未明、IDCフロンティアのクラウドサービス「IDCFクラウド」がランサムウェア攻撃を受け、495 の企業・自治体に影響が出ました。翌 8日には、被害を受けた 4 つのゾーンの顧客データは取り出しも復元も難しく、顧客側のバックアップで別環境に作り直すよう案内が出ています（IDCフロンティアの発表、日経クロステックの報道）。自治体のサイトが見られなくなり、物流会社の入出荷が止まったとも報じられました。国内の、名の知れたクラウド事業者です。お客様の環境でも使われていておかしくないところで、こういうことが突然起きる時期に入った、と受け止めました。

WordPress 自体も、以前から狙われやすい CMS でした。日本のサイトの 8 割以上が WordPress という調査もあり、攻撃する側から見れば「同じ手口が一番多くのサイトに効く」対象です。そこに 2026年7月、WordPress 本体の認証不要の脆弱性（通称 wp2shell、CVE-2026-60137 と CVE-2026-63030）が公表され、IPA が注意喚起を出しました（IPA: WordPressの脆弱性対策について）。修正版が出たその日から、この脆弱性を狙う通信が前日の数百倍に増えたという観測も出ています。

私は 20 年間、社内の情シスとして会社のサーバーを守る側にいました。その経験から言うと、WordPress の守り方は「プラグインを減らす」「更新を欠かさない」「ログインを制限する」「WAF を入れる」の積み重ねで、どれもやっていました。それでも、10月8日に棚卸しをしたら、有効なプラグインは 26 本、そのうち更新待ちが 9 本。管理画面の /wp-login.php と REST API の /wp-json/ は外から見える状態でした。週 1 本の記事を出すためだけに、この攻撃面を抱え続ける理由が見つかりませんでした。

2 つ目は、移す側のハードルが下がったことです。WordPress をやめて静的サイト（HTML と画像をそのまま配信する形）にする話は、以前からありました。やらなかったのは、97 ページ分の HTML を取り出して、URL・メタ情報・画像パスを一つも変えずに作り直し、さらに検索エンジンから見て同じサイトであることを検証する作業が、1 人でやるには重すぎたからです。今回はこの作業のほとんどを Claude Code（Anthropic の AI エージェント）に任せました。私がやったのは判断と、お金と DNS に関わる操作だけです。

2 日間の時間割

先に全体を表にします。時刻は日本時間です。

日時	やったこと	担当
10/8 日中	本番サーバーの棚卸し（SSH 1 回、読み取りのみ）。ページ数・URL・プラグイン・DNS・容量を洗い出し、移行計画書を作成	Claude Code
10/8 日中	計画書を読んで方式を決定。Azure サブスクリプション作成、GitHub リポジトリ作成、問い合わせフォームを Zoho Forms で作成、さくらの DNS レコードを控える	私
10/8 夜（〜23:25）	記事・固定ページ・メタ情報・メニュー・画像 94MB を書き出し、Eleventy で全 97 ページを生成。Azure Static Web Apps にパスワード付きで配置	Claude Code
10/9 早朝（6:18〜7:42）	セミナー一覧・RSS・XML サイトマップ・構造化データの生成、旧テーマ由来の見た目の補正、リンク切れ 5 件の修正、Azure DNS ゾーンの作成（28 レコード）	Claude Code
10/9 午前	DNS の検証用レコード追加（証明書発行まで約 20 分）、最終差分の書き出し、WordPress の最終バックアップ 730MB を Azure Storage へ保管、プレビューを確認して承認	私＋Claude Code
10/9 09:00	Azure 側のパスワード保護を本番環境だけ解除。続けて、さくらの DNS で A レコードを Azure に向ける。TTL が 1 時間なので、1 時間以内に全員が新サイトを見る状態に	Claude Code → 私
10/9 午前	切替後の確認。本番ドメインの全 URL をクロールして手元のビルドと 84 本すべて一致。問い合わせフォームのテスト送信で表示の不具合を 1 件見つけて修正	Claude Code＋私

私自身の作業時間は、要所での判断と操作を合わせて 1 時間以内です。計画書を読んで方式を決める、Azure のサブスクリプションと GitHub のリポジトリを作る、Zoho Forms を作る、さくらの DNS を控えて書き換える、プレビューを見て承認する。この 5 つを、別の仕事の合間に挟みました。残りの時間はすべて Claude Code が動いています。

何をしたか

棚卸し：移す前に「今、何があるか」を 1 回で取る

最初にやったのは本番サーバーの棚卸しです。公開しているページ数、URL の規則、使っているプラグイン、画像の実容量、DNS のレコード。これを把握しないまま移すと、移した後に「あのページが無い」「メールが止まった」が起きます。

さくらのレンタルサーバーは SSH の連続接続に制限があるので、確認コマンドを 1 本のスクリプトにまとめて 1 回の接続で全部取りました。分かったことの一部を挙げます。

• 公開 URL は 92 本（固定ページ 15、記事 33、セミナー 8、カテゴリ・タグ・著者 36）
• 画像の実体は約 94MB、1,364 ファイル。uploads フォルダーは 10GB あったが、そのうち 10GB はバックアップ用プラグインが溜めた tar ファイルだった
• 有効プラグイン 26 本、更新待ち 9 本
• DNS はさくら。メールは Microsoft 365、ほかに Intune・Zoho・Google の認証レコードが混在

10GB のうち画像が 94MB しかなかった、という発見は象徴的でした。WordPress は使い続けるうちに、自分では把握していないものが増えていきます。

方式：WordPress を「移す」のではなく「やめる」

Azure に WordPress をそのまま載せる選択肢（App Service ＋ MySQL）もありました。採りませんでした。環境を変えても、PHP とデータベースと管理画面が公開面に残るのは同じで、守る作業も同じだけ残るからです。

採ったのは、静的サイトジェネレーターの Eleventy で HTML を生成し、Azure Static Web Apps（Standard プラン）で配信する形です。ソースは GitHub のプライベートリポジトリに置き、main ブランチに変更が入ると GitHub Actions が自動で本番に反映します。公開面に残る動的な部品は、問い合わせフォーム（Zoho Forms）とチャット（Zoho SalesIQ）だけで、どちらも自社サーバーでは動いていません。

費用は上がります。これまでは「さくらのレンタルサーバ スタンダード」で月 660 円でした。移行後は Static Web Apps の Standard プランが約 9 米ドル、Azure DNS が約 0.5 米ドルで、合わせて月およそ 1,500 円です。差額の 800 円強は、WordPress の更新作業とログインの監視をしなくてよくなる対価だと考えています。さくらは 30 日後に WordPress を削除してから解約します。

再現：URL・メタ情報・画像パスを一つも変えない

移行で一番気を使ったのはここです。会社サイトは検索からの流入が頼りで、URL やタイトル、説明文、構造化データが変わると順位に響きます。

方針は「訪問者と検索エンジンから見て同じサイト」にすること。具体的には次を守りました。

• 公開 URL 92 本を同じパスで生成する。記事は /archives/725 のような数字の URL のまま
• 画像は /wp-content/uploads/... のパスをそのまま残し、全ファイルをコピーする
• <title>、description、canonical、OGP、JSON-LD は旧サイトの出力と同じ値を出す
• 末尾スラッシュの扱い、旧ページからの 301 転送、RSS、XML サイトマップも同じ URL で返す
• /wp-login.php /wp-json/ /xmlrpc.php は明示的に 404 にする

一方で、WordPress・Elementor・テーマが出していた CSS と JavaScript は全部落としました。1 ページあたり 140KB を超える HTML の大半がそれでした。

同じかどうかは目視では分からないので、比較ツールを作って旧サイトのクロール結果と突き合わせました。95 URL 中 88 本が title・description・canonical・OGP・JSON-LD・画像・内部リンクまで一致。残り 7 本は意図した差分（セミナー一覧の URL 統合、日付アーカイブの廃止など）です。見た目は 1280px で 21 ページ、375px で 7 ページのセクション高さを数値で比較して、本番と一致させました。

DNS：止めずに切り替える順番

ドメインの DNS はさくらから Azure DNS に移します。Static Web Apps でルートドメイン（www 無し）を使うには ALIAS レコードが必要で、さくらの DNS にはそれが無いからです。

ただし DNS の移管は、メール（Microsoft 365）や Intune、Zoho の認証レコードを全部作り直す作業を含みます。ここで間違えるとメールが止まります。そこで、順番を次のようにしました。

1. 先に Azure DNS にゾーンを作り、さくらの 28 レコードを全件再作成して突き合わせる
2. さくらの DNS に検証用の TXT レコードだけ追加し、Azure 側でドメインの所有確認と証明書発行を済ませる（トラフィックはまだ旧サイト）
3. 切り替え当日は、さくらの DNS の A レコードを Azure の固定 IP に向けるだけ。TTL が 3600 秒なので 1 時間で全員が新サイトに移り、問題があれば元の IP に戻すだけで 1 時間で戻る
4. 新サイトで問題がないことを確認してから、ネームサーバーを Azure DNS に変更する

最初の計画では「切り替え当日にネームサーバーを変える」一発勝負でした。10月9日の朝に手順を見直して、A レコードで先に切り替え、ネームサーバー変更は後に回す段階方式に変えました。戻す手段が 1 時間で済む状態を作ってから本番に触る、という考え方です。

バックアップ：戻れる状態を残してから消す

切り替えの前に、WordPress のデータベース（6.7MB）と wp-content（624MB、バックアップ用プラグインの 10GB は除外）を tar にまとめ、Azure Storage の Cool 階層に保管しました。合計 730MB、md5 で照合済みです。さくら側の WordPress は 30 日間そのまま残し、問題が無ければ削除します。

うまくいかなかったこと、途中で変えたこと

全部が一直線に進んだわけではありません。

書き出しスクリプトを 1 回やり直した。 WordPress のデータを JSON に書き出す処理を wp-cli の eval-file で動かしたところ、関数のスコープの都合で global 変数が効かず、空のデータが出ました。原因を突き止めて再実行するまで SSH を 1 回余分に使っています。

問い合わせフォームの戻り先で 2 回つまずいた。 Zoho Forms の送信後に /inquiry/thanks へ戻す設計にしましたが、このページは新サイトにしか無く、DNS 切り替え前は旧 WordPress が応答するため、テスト送信で 404 が出ました。切り替え前に Zoho 側も WordPress 側も触らないと決め、確認を切り替え直後に回しました。切り替え後にもう一度テスト送信すると、今度はサンクスページがフォームの iframe の中に、ヘッダーもフッターもチャットも付いた 1 ページとして表示され、サイトが二重に見えました。対処は、iframe の中で開かれたら親ウィンドウごとサンクスページへ移動する処理を足すこと。同じドメインなのでこれができます。GA4 の計測は移動後の通常ページで 1 回だけ行うようにして、二重計上を避けました。

性能スコアは上がらなかった。 モバイルの Lighthouse で、トップページの転送量は 3,889KB から 1,493KB、リクエスト数は 111 から 58 に減り、LCP（最大コンテンツの描画）は 21.6 秒から 11.0 秒に半減しました。それでも性能スコアは 54 のままです。遅い要素が Google Fonts の CSS の読み込み待ちで、これは旧サイトと同じ構造だったからです。フォントの非同期読み込みと gtag.js の遅延は、切り替え後の宿題にしました。

旧サイトのバグを 2 つ見つけた。 ブログ一覧の 2 ページ目に同じ記事が重複して出ていたこと（テーマの件数設定と WordPress のページ数計算が食い違っていた）と、著者ページの見出しに HTML タグがそのまま表示されていたこと。どちらも新サイトでは直っています。移行は、普段見ないページを全部見る機会でもありました。

リンク切れが 5 件あった。 フッター以外の場所にあった /sotoduke/ への古いリンク、資料ダウンロードページの旧 URL、古い記事 3 本に埋め込まれていた WordPress の oEmbed の iframe。全件チェックで見つけ、元から直しました。

切り替え後に残っていること

切り替えから 1 時間以内に、本番ドメインの全 URL をクロールして手元のビルドと突き合わせ、84 本すべて一致を確認しました。旧 URL の 301 転送、www から www 無しへの転送、http から https への転送、/wp-login.php の 404 も想定どおりです。この記事を書いている時点で残っているのは次です。

• ネームサーバーを Azure DNS に変更する（委任の TTL が 1 日なので、完全に切り替わるまで最長 1 日。それまではさくらの DNS が Azure を指しているので表示は同じ）
• Search Console にサイトマップを再送信し、主要ページを URL 検査する
• Content-Security-Policy を Report-Only から強制に切り替える
• 30 日後にさくらの WordPress を削除する
• 3 週間後に順位・クリック・登録ページ数を移行前と比較する

情シスのいない会社の WordPress はどうするか

この記事を読んでいる経営者・総務の方の会社サイトも、WordPress である可能性が高いと思います。制作会社に頼んで作り、更新はたまに、プラグインの更新は誰がやっているか分からない。私が見てきた中小企業の会社サイトは、たいていこの状態でした。

全部の会社が静的サイトに移すべきだとは言いません。会員機能や予約、EC があるなら WordPress のままのほうが合理的です。ただ、「会社案内と記事と問い合わせフォーム」だけのサイトなら、WordPress を抱え続ける理由はもう薄い、というのが今回の実感です。

判断の材料として、まず次を確認してみてください。

• 有効になっているプラグインの数と、更新待ちの数
• https://自社ドメイン/wp-login.php を開いて、ログイン画面が誰にでも見える状態か
• 最後にバックアップを取ったのはいつか、それはどこにあるか

この 3 つが答えられない状態なら、移すかどうかの前に、まず誰かが面倒を見る体制が要ります。「うちのサイトは誰が守っているのか分からない」という段階で、お問い合わせください。