静的サイト生成による独立系サイト構築：JAMstack、ビルド時間、CDN配信とSEO

静的サイト生成による独立系サイト構築：JAMstack、ビルド時間、CDN配信とSEO

1. JAMstackが解決する課題とは

JAMstackの3文字はJavaScript、API、Markupを表します。従来の構成は「ユーザーのリクエスト→サーバーがデータベースクエリを実行→HTMLをレンダリング→返却」という流れで、各ステップに時間がかかります。JAMstackはこの3ステップをビルド段階で前倒しして完了させ、デプロイ時に生成済みのHTMLファイルを世界中のCDNに配置します。ユーザーがアクセスするとCDNが直接ファイルを返し、バックエンドを経由しません。

直感に反する判断ですが、JAMstackの最大のメリットはセキュリティやコストではなく、SEOと初回表示速度です。データベースで動的に生成されるページのTTFBは通常300〜800ミリ秒で、さらにJavaScriptのダウンロードと実行を待つ必要があります。静的HTMLはCDNから直接返されるため、TTFBは100ミリ秒未満になることも多く、クローラーは完全にレンダリングされたコンテンツを取得できます。Core Web Vitalsの測定方法はこちらをご覧ください。Core Web Vitalsの最適化。

ただし静的とは「動かせない」という意味ではありません。ページ上でインタラクションが必要な部分（問い合わせフォーム、リアルタイム在庫、為替換算）はJavaScriptでAPIを呼び出し、ブラウザ側で処理します。HTMLの静的配信には影響しません。これが「APIで動的要素を補う」という意味です。CDNの選び方はこちらをご覧ください。CDNグローバル高速化。

2. ビルド時間：ページ数が増えたときの最初のボトルネック

ページ数が少ないうちはビルド時間は問題になりません。50ページのHugoならビルドは数秒です。しかし500ページを超えると、フレームワークごとのビルド時間の差が開き始めます。Hugoは依然として30秒以内、Next.jsは3〜5分かかることもあり、Gatsbyは10分を超えることもあります。ビルド時間は2つのことに直結します。コンテンツを公開するまでの待ち時間と、誤字を1つ直すたびに数分待たされる開発体験です。

ケース1：2年で300記事を蓄積したB2BブログサイトをNext.jsで構築。記事1本のタイトルを変えるたびに全量ビルドで4分かかり、チームは頻繁な更新を避けるようになりました。解決策はNext.jsのISR（インクリメンタル静的再生成）を有効にするか、コンテンツレイヤーキャッシュに切り替えて影響を受けるパスだけを再ビルドすること。ビルド時間は4分から20秒に短縮できます。

ケース2：2000のSKUがあり、SKUごとに詳細ページを持つ製品カタログサイト。Next.jsの全量ビルドは12分かかり、毎日1回自動ビルドしています。この規模ならHugoかEleventyへの移行をおすすめします。ビルド時間は1分以内に抑えられます。画像の一括圧縮方法はこちら画像SEOとWebP。

3. CDNデプロイ：コミットから全世界に反映されるまでどれくらいかかるか

JAMstackのデプロイはシンプルです。git push→プラットフォームが自動ビルド→静的ファイルを生成→世界中のCDNノードに配信。VercelとNetlifyはNext.jsとEleventyをネイティブサポートし、Cloudflare PagesはHugoと純粋な静的ファイルのサポートに優れています。コミットから全世界でアクセス可能になるまでのデプロイ時間は、通常30秒〜3分です。

ここでつまずきやすい落とし穴があります。CDNキャッシュの無効化です。製品価格を変更して再デプロイしても、一部のエッジノードに古いバージョンが残り、最長24時間キャッシュされることがあります。解決策は、デプロイ完了後にCDNの全量リフレッシュを能動的に実行するか、URLにコンテンツハッシュを付けることです（ファイル名にhashを付与、例：style.abc123.css）。新しいファイルが古いファイルを自動的に置き換えます。キャッシュ戦略の設定方法はこちらサイトのキャッシュ戦略。

具体例：海外展開する照明ブランドがNext.js SSGを採用し、200の製品ページの全量ビルドに3分かかっていました。マーケティング担当が製品画像を1枚変更し、コードをコミットして3分のビルド、さらに1分のCDN反映を待って、ようやくユーザーが新しい画像を見られる状態でした。その後ISRを有効にし、各ページ60秒で再検証する設定にしたところ、画像変更後は最短60秒で新バージョンが表示され、ビルド時間も3分から40秒に短縮されました。

四、SEOの観点:静的サイトが本質的に有利な理由

GoogleのクローラーはJavaScriptを実行できるようになりましたが、実行時間とリソースには限りがあります。静的HTMLは最初のリクエストで完全な内容を返すため、クローラーはJSの実行を待つ必要がなく、JSの読み込み失敗で内容を取得できないこともありません。SEO上の直接的なメリットは、インデックスが速い、レンダリングエラーが少ない、構造化データが確実に読み取られることです。

もう一つの利点は、sitemapとURL構造をビルド時に一度に生成でき、データベースへの動的クエリが不要なことです。ファイル名、ディレクトリ階層、canonicalタグはすべてビルドスクリプトに固定でき、動的サイトでよくある「タグページと記事ページの内容重複」も起きません。sitemapの最適化方法はこちらXML sitemapの最適化。

ただし直感に反する点が一つあります。静的サイトがすべてのSEO指標で優れているわけではありません。内容の更新が頻繁な場合(毎日価格や在庫が変わるなど)、静的化するとデータが古くなり、ユーザーが開いたページには24時間前の価格が表示され、直帰率が上がります。こうしたページはクライアント側APIでリアルタイムに取得すべきで、静的HTMLに無理に埋め込んではいけません。

もう一つの実務的なポイントは、静的サイトの画像処理です。WordPressは画像をアップロードすると自動で複数サイズを生成しますが、Hugoや11tyではビルドスクリプトに自分で書く必要があります。この手順を忘れると、ユーザーは4000ピクセル幅の原画像をスマホでダウンロードすることになり、LCPが1.5秒から4秒に跳ね上がります。画像圧縮とフォーマット変換の設定方法はこちら画像SEOとWebP形式。

FAQ よくある質問

最後に

JAMstackは新しい概念ではありません。本質は「前もってできることはすべて前もって済ませておく」ことです。コンテンツ表示が中心のB2B独立系サイトにとって、このアーキテクチャは性能、コスト、SEOの3つを同時に満たせるため、選ばない理由はほとんどありません。唯一のハードルは、チームが「ビルド時に生成する」という働き方を受け入れることです。コンテンツを変更してもビルドを待つ必要があり、WordPressのように変更後すぐに反映されるわけではありません。

導入は最小構成から始めましょう。まずHugoかEleventyでブログ部分だけを静的サイトに移し、既存のWordPress本体はそのままにします。1か月運用して、移行前後のLCP、インデックス速度、サーバーコストを比較します。効果が明確なら、製品ページやトップページも順次移行します。この段階的な移行なら、いつでも元に戻せます。

覚えておきたい一言：静的サイトの強みは「静的」であることではなく、「クローラーとユーザーが同じ時点で同じ完全なコンテンツを受け取れる」ことです。動的レンダリングが主流の時代では、むしろこれは貴重です。