コーポレートサイトを静的化するかどうか、ここ2年ほどでお客様から相談を受けることが増えています。「Astroが良いと聞いた」「WordPressのセキュリティが怖い」「Vercelに移行したい」——きっかけはさまざまですが、移行後に「思ったのと違った」という声を聞くことも少なくない。
正直なところ、「静的サイトに移行すれば全部解決」という煽りが多すぎると感じています。私たちが実際に複数のコーポレートサイトを静的化した経験をもとに、得られるものと失うものを数字ベースで整理してみます。
静的化で確実に得られる3つのもの
1. 表示速度の改善
Lighthouseのパフォーマンススコアが60点台から90点台に上がることは、Astro + CloudFront構成であれば現実的な話です。動的サーバーのレスポンスタイムがなくなり、エッジでキャッシュされたHTMLが直接返ってくる。当然速くなります。
ただし、画像を最適化していない状態では90点台はまず出ません。私が担当した案件では、移行直後は85点くらいで、画像のフォーマット変換（WebP化）と遅延ロードを追加して初めて95点を超えました。
2. セキュリティ面の安心感
WordPressをPHP + MySQLで動かしている状態と比べると、攻撃面が劇的に減ります。動的処理がなければSQLインジェクションもXSSも入り込む余地がない。プラグインのCVEに毎月対応しなくていい。運用を考えると、このストレスが消えることの価値は思った以上に大きかったです。
3. 運用コストの変化
これが最も数字で見えやすいところです。
| 構成 | 月額費用（概算） | 備考 |
|---|---|---|
| WordPress + VPS | 3,000〜8,000円 | VPS代 + バックアップ + SSL更新対応 |
| WordPress + 共有サーバー | 1,000〜3,000円 | スペック不足でスロー化しやすい |
| Astro + S3 + CloudFront | 100〜500円 | 月1万PV程度なら300円以下になることも |
ただしこれはあくまでインフラコストだけの話です。移行作業のコストと、移行後のコンテンツ更新フロー再設計のコストは別に発生します。そこを混ぜて「月3,000円が300円になった」と喜ぶのは少し待ってほしいというのが本音です。
静的化で失うもの、代替案の現実
ここからが正直に書きたい部分です。
コーポレートサイトに実装されている機能のうち、静的化で扱いが難しくなるものがいくつかあります。
問い合わせフォーム
「FormspreeやNetlify Formsで十分じゃないですか」という話はよく出ます。確かに単純な問い合わせフォームであれば月100件程度まで無料で使えます。
ただ、以下のケースでは代替が難しくなります：
- スパムフィルタリングを細かくカスタマイズしたい
- 送信内容を社内システムに自動連携したい
- 入力項目が多く、複雑な条件分岐がある
実際に私が経験した案件で、問い合わせ内容を基幹システムのAPIに即時POST連携していたケースがありました。静的化に合わせてこのロジックをAWS Lambda + API Gatewayに切り出す作業が発生し、移行工数が想定の1.5倍になりました。
今思えば、事前にフォームの裏側の処理を全部洗い出すべきでした。「見た目は普通のフォームだけど何かしてる」ケースが思いのほか多い。
サイト内検索
WordPressの検索機能をそのまま持ってくることはできません。代替として考えられる選択肢は大きく3つです：
- Pagefind（静的サイト向け。ビルド時にインデックスを生成。完全無料）
- Algolia（月5万件まで無料。それ以上は課金）
- Google Site Search（外部サイトに飛ぶが設置は簡単）
コンテンツ量がそれほど多くないコーポレートサイトであれば、Pagefindを最初に検討するのが良いと考えています。ビルド時にインデックスを生成するので、動的サーバーが不要なまま検索が実現できます。
// Pagefindの基本的な実装例（※改善の余地あり：ゼロ件時の表示・ローディング状態が未整備）
const pagefind = await import("/pagefind/pagefind.js");
await pagefind.init();
const search = await pagefind.search("キーワード");
search.results.forEach(async result => {
const data = await result.data();
console.log(data.url, data.excerpt);
});動作はしますが、実際のプロダクションに使うなら検索結果ゼロ件の表示制御や、入力中のデバウンス処理などが追加で必要になります。
会員機能・マイページ
これは静的化では対応できないカテゴリです。ログイン・セッション管理・パーソナライズされたページ表示は、どう設計しても動的処理が必要になります。
「サイト全体を静的化する」のではなく「会員機能部分だけ別サブドメインで切り出す」アーキテクチャを検討するほうが、現実的なケースがほとんどです。
どこまで静的で困らないか
実際の経験から言うと、コーポレートサイトの機能の8〜9割は静的化で困らない範囲に収まります。
静的のまま扱いやすい機能の例：
- 会社概要・サービス紹介・採用情報などの静的コンテンツ
- お知らせ・ブログ（MDXやCMSで管理）
- Google Mapの埋め込み
- Googleフォームへのリンク（フォーム本体はGoogleが動的処理）
- チャットボット（Zendeskなどの埋め込みスクリプト）
「Googleやサードパーティが動的処理してくれるもの」は意外に多い。
---
// Google Mapの埋め込み例（Astroコンポーネント）
const mapSrc = `https://www.google.com/maps/embed/v1/place?key=${import.meta.env.MAPS_API_KEY}&q=東京都港区`;
---
<iframe
src={mapSrc}
width="100%"
height="400"
allowfullscreen
loading="lazy"
referrerpolicy="no-referrer-when-downgrade"
></iframe>運用を考えると、「この機能の裏側は誰が動的処理を担うか」を整理するのが静的化判断の本質だと感じています。自社サーバーで動かす必要がある処理はどれか。それを1つずつ確認していくと、残るケースは想定より少ない。
WordPressのままでよかったサイト
最後に、率直に書いておきます。
以下の特徴を持つサイトは、静的化よりもWordPressを継続したほうが合理的だと考えています。
月に何度もコンテンツを更新する非エンジニアがいる場合
Markdownに慣れていない人にとって、GitHubのPRフローはハードルが高い。WordPressのビジュアルエディタのほうが、そのまま続けたほうが全体のコストが低い場合があります。
EC機能・会員機能が中核にある場合
WooCommerceや会員管理を使っているなら、それをBaaSで置き換えようとすると逆に構成が複雑になるケースがあります。静的化を前提にした設計では追加コストが大きくなりやすい。
サポートを外部業者に依頼している場合
担当の制作会社がWordPressを前提にサポートしている環境では、移行によって既存のサポート体制が使えなくなるリスクがあります。移行後の保守体制を先に確定させることが必要になります。
自社のコーポレートサイトをAstroに移行してから1年以上経ちますが、「静的化して後悔した」という声は今のところ聞いていません。ただし、これは事前に「静的化で困ることがないか」を1機能ずつ確認した上での移行だったからだと思っています。
今後は、移行の意思決定を支援する静的化チェックリストのようなものを整備していきたいと考えています。問い合わせフォームの裏側・検索の要件・コンテンツ更新の担当者——この3点を先に押さえれば、移行後の「思ったのと違った」はかなり減らせるはずです。
