---
title: "低関与ウェブの静的生成とHTMLキャッシュ基準"
locale: ja
category: knowledge_base
category_name: "ナレッジベース"
translation_status: reviewed
license: cc_by
author: "Injoys 編集部"
source_url: https://injoys.com/ja/articles/low-involvement-web-static-generation-html-cache
published_at: 2026-11-05T07:45:55+09:00
---
# 低関与ウェブの静的生成とHTMLキャッシュ基準
> 低関与ウェブの技術設計では、初期HTMLに含まれる本文とCDNのHTMLキャッシュを併せて確認する必要があります。TTFB 0.8秒は性能改善の参考値で、キャッシュの適用範囲と修正後の更新も設計の対象です。
## Key Points
- 初期HTMLに本文の主要部分を含めると、JavaScriptの実行への依存を減らせます。
- GoogleはJavaScriptを実行するため、Reactを使っているという理由だけで検索エンジンのクロールが失敗すると判断することはできません。
- TTFB 0.8秒以下は性能改善の参考値であり、ページ全体の読み込み時間を意味するものではありません。
- Cloudflare CDNは標準ではHTMLをキャッシュしないため、公開ページのキャッシュルールを確認する必要があります。
- HTMLキャッシュには、ログインページの除外とコンテンツ修正後の更新ポリシーが必要です。
低関与型ウェブの検索クロールを助けるには、初期HTMLに主要な本文を含める必要があります。公開コンテンツには、静的生成とCDNのHTMLキャッシュが役立ちます。ただし、TTFB 0.8秒の達成だけでは、検索結果への表示を保証できません。
TTFBの数値の根拠は、2025年11月18日に更新されたweb.devのドキュメントです。
## 低関与型ウェブで最初に確認する技術的な条件
この記事では、必要な情報を短時間で確認するウェブサイトを低関与型ウェブと呼びます。レンダリングと転送速度は、こうしたサイトで技術的に点検する項目です。ただし、この2項目だけで検索結果への表示の違いをすべて説明できるわけではありません。
検索クロールは、ロボットがページを取得する過程です。インデックス登録は、取得した内容を検索対象として処理する過程です。Googleは、クロールされたすべてのページがインデックスに登録されるわけではないと説明しています。[Googleのクロールバジェットに関するガイド](https://developers.google.com/crawling/docs/crawl-budget)
| 点検項目 | 確認する内容 | 解決したい問題 |
| --- | --- | --- |
| 初期HTML | タイトルと主要な本文がレスポンスに含まれているか | 本文を読むための追加実行への依存 |
| レンダリング | JavaScriptの実行後に内容が正常に表示されるか | 実行エラーやブロックによる欠落 |
| TTFB | 最初のレスポンスが届くまでにかかる時間 | 接続とサーバーレスポンスの遅延 |
| HTMLキャッシュ | 公開ドキュメントをCDNで再利用しているか | オリジンサーバーへ繰り返しリクエストするコスト |
| インデックスの状態 | GoogleがそのURLをどのように処理したか | クロールの成功と検索への登録を混同する問題 |
## Reactページが空のHTMLに見える理由
Reactページの初期HTMLは、実装方法によって異なります。ブラウザで本文を生成する方式をCSRと呼びます。この方式では、最初のレスポンスに本文がなく、実行用コードだけが含まれる場合があります。
GoogleはChromiumを使ってJavaScriptを実行します。ページは、クロール後にレンダリングを待つ場合があります。ブロックされたページやファイルは、レンダリングの対象から除外される場合があります。すべてのロボットがJavaScriptを実行するわけでもありません。[GoogleのJavaScript SEOの基本ガイド](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
そのため、画面が正常に表示されるという事実だけで、クロールの状態を判断しないでください。まず、初期レスポンスに本文があるかを確認してください。Googleがレンダリングした結果は、Search ConsoleのURL検査で確認できます。
## 静的生成とサーバーレンダリングの比較
公開する本文の更新方法に応じて、HTMLの生成方法を選べます。静的生成は、リクエストを受ける前にHTMLを生成する方式です。サーバーレンダリングは、リクエストを受けたときにサーバーでHTMLを生成します。Reactでも、こうした方式を使えます。[web.devのレンダリング方式ガイド](https://web.dev/articles/rendering-on-the-web)
| 方式 | HTMLを生成するタイミング | 検討に適した状況 | 運用上の確認点 |
| --- | --- | --- | --- |
| クライアントレンダリング CSR | ブラウザでJavaScriptを実行するとき | ユーザー操作が多い画面 | 本文表示までに必要な実行とリクエスト |
| 静的生成 SSG | ビルド時やコンテンツ生成時 | 訪問者に同じ内容を表示する公開ドキュメント | 修正後の再生成とデプロイ |
| サーバーレンダリング SSR | ページリクエストを処理するとき | リクエストごとに最新の内容を組み立てる画面 | データ取得とHTML生成の時間 |
| プリレンダリング | デプロイ前にアプリを実行してHTMLを取得するとき | 既存アプリの初期本文をあらかじめ提供するとき | その後の機能に必要なJavaScript |
静的生成とCDNは、それぞれ役割が異なります。静的生成は、HTMLを生成するタイミングについての選択です。CDNは、コンテンツを配信し、再利用する仕組みです。サーバーで生成したHTMLも、条件を満たせばCDNにキャッシュできます。
## TTFB 0.8秒は何を意味しますか？
TTFBは、ページ遷移の開始からレスポンスの最初のバイトが届くまでの時間です。web.devは、ほとんどのサイトに対して**0.8秒以下**を大まかな目標として示しています。これは、ページ全体が表示されるまでの時間とは異なります。TTFB自体はCore Web Vitalsの項目でもありません。[web.devのTTFBの説明](https://web.dev/articles/ttfb)
TTFBには、サーバー内部の処理以外の遅延も含まれます。DNSルックアップは、ドメインの接続先アドレスを調べる過程です。TCPとTLSの接続にも時間がかかる場合があります。別のアドレスへ転送するリダイレクトも影響します。
- DNSルックアップと接続準備の時間
- ネットワークを通じてリクエストとレスポンスが移動する時間
- オリジンサーバーでのデータ取得とHTML生成の時間
- 最初のレスポンスまでに発生するリダイレクトの時間
サーバーがソウルにあるという事実だけで、0.8秒を超えると断定することはできません。接続する場所や接続を再利用するかどうかによって、結果は変わります。Googleのクローラーは、主に米国のIPアドレスを使います。ただし、ほかの国のIPアドレスからアクセスする場合もあります。[Googleクローラーの技術的な特性](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en)
継続的なレスポンスの遅延は、Googleのクロール処理能力に影響します。サーバーエラーも、クロール量が減る原因になります。だからといって、0.8秒を一度超えるとクロールが停止するというルールではありません。クロールの需要には、ページの品質や更新頻度も関わります。[Googleのクロールバジェットに関するガイド](https://developers.google.com/crawling/docs/crawl-budget)
## CDNでHTMLキャッシュを確認する必要がある理由
Cloudflare CDNは、デフォルトではHTMLをキャッシュしません。画像やCSSがキャッシュされていても、本文のドキュメントは別途確認する必要があります。ほかのCDNのデフォルトの動作は、そのサービスのドキュメントで確認してください。
> Cloudflare CDNは、デフォルトではHTMLやJSONをキャッシュしません。
>
> Cloudflare, Default cache behavior
この文は、HTMLとJSONがデフォルトのキャッシュ対象ではないことを意味します。公開HTMLは、Cache Rulesでキャッシュ対象に含められます。実際に保存されるかどうかには、レスポンスヘッダーやCookieなどの条件も関わります。[Cloudflareのデフォルトのキャッシュ動作](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)
キャッシュは、保存しておいたレスポンスを再利用する機能です。CDNに接続したからといって、すべてのドキュメントが世界中に即座に複製されるわけではありません。Cloudflareは、リクエストを処理するデータセンターにコンテンツをキャッシュします。キャッシュにないリクエストでは、オリジンサーバーへの問い合わせが必要になる場合があります。[Cloudflareのキャッシュの導入ガイド](https://developers.cloudflare.com/cache/get-started/)
公開HTMLにキャッシュルールを適用するときは、パーソナライズされたページを除外してください。Cloudflareは、動的HTMLのキャッシュによって、ほかの人の情報が配信されるおそれがあると警告しています。ログインページやアカウントページはキャッシュしないでください。[CloudflareのCache Everythingの注意事項](https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/)
## ページの条件別のキャッシュ適用基準
訪問者に同じ内容を表示するかどうかが、キャッシュの範囲を決める出発点です。公開された説明文は、共通で再利用しやすい対象です。ログイン状態によって内容が変わるレスポンスは、別に処理する必要があります。
| ページの条件 | 検討する構成 | あわせて確認する事項 |
| --- | --- | --- |
| 訪問者に同じ説明文を提供 | 静的生成と公開HTMLキャッシュ | 修正後の再生成・キャッシュ更新 |
| 公開本文に頻繁に変わる数値を含む | 本文と変動データの更新方法を分離 | 数値の基準時点と失敗時の表示 |
| リクエスト時点の最新の公開情報が必要 | サーバーレンダリングと条件付きキャッシュを検討 | 許容できる情報の遅延 |
| ログイン・アカウント・決済画面 | 共有HTMLキャッシュから除外 | 認証Cookieとユーザーごとのレスポンス |
| 言語別の公開ドキュメントを提供 | 言語別のURLと各ドキュメントのキャッシュ | 翻訳文の関連付けと言語別の更新 |
リアルタイムデータを後から読み込むと、静的な本文を維持しやすくなります。ただし、検索に必要な主要な内容をすべて後回しにしないでください。初期HTMLを提供する目的と矛盾するおそれがあるためです。
## よくある間違いと確認基準
技術の名前や設定画面だけで結果を判断すると、エラーを見落としやすくなります。実際のHTMLとレスポンスヘッダーをあわせて確認してください。以下は、それぞれ区別する必要がある状態です。
| よくある判断 | 確認すべき基準 |
| --- | --- |
| Reactサイトは検索ロボットには読み取り不可 | 初期HTMLとGoogleのレンダリング結果 |
| TTFBが0.8秒なら画面もすべて表示済み | 最初のレスポンスから本文表示までにかかる時間 |
| CDNに接続したのでHTMLもキャッシュ済み | HTMLリクエストのキャッシュ状態 |
| 静的ファイルなら常に最新の内容 | 最後に生成した時点とデプロイされた内容 |
| 高速に応答すれば検索への登録も完了 | Search Consoleのインデックス処理状態 |
| キャッシュヒットの結果1つでグローバルな速度を判断 | 接続地域とキャッシュヒットの有無ごとの測定結果 |
Cloudflareの`CF-Cache-Status`は、キャッシュ状態を示すヘッダーです。`HIT`は、キャッシュ内にレスポンスが見つかったことを意味します。`MISS`は、リクエスト時にキャッシュになく、オリジンから取得したことを意味します。`DYNAMIC`は、キャッシュ対象として処理されていない状態です。[Cloudflareのキャッシュレスポンスの説明](https://developers.cloudflare.com/cache/concepts/cache-responses/)
## コンテンツ修正後のキャッシュ更新
静的ファイルとCDNキャッシュは、修正内容を反映するまでの流れも設計する必要があります。オリジンを修正しても、以前のキャッシュが残っていれば古い内容が配信されます。HTMLとJSONを一緒に公開する場合は、両形式の内容も揃える必要があります。
以下は、ドキュメントとデータファイルを一緒に運用するときの点検手順です。
1. 元のデータで変更内容を確定してください。
2. 同じ変更版からHTMLとデータファイルを再生成してください。
3. 新しいファイルをデプロイした後、変更したURLのキャッシュを更新してください。
4. 各URLを再度リクエストし、修正内容が一致しているか確認してください。
Cloudflareは、URL単位でのキャッシュ削除を推奨しています。キャッシュ削除は、保存されたレスポンスを取り除く作業です。静的HTMLを再生成する作業は、別途必要です。そのため、ファイル生成とキャッシュ更新を同じデプロイ手順に組み込んでください。[Cloudflareのキャッシュ削除ガイド](https://developers.cloudflare.com/cache/how-to/purge-cache/)
更新間隔は、そのコンテンツで許容できる情報の遅延に合わせて決めてください。説明文とリアルタイムの数値に、同じ周期を適用する必要はありません。キャッシュの有効期間を短くするだけでは、すべての更新の問題を解決できません。
## 多言語サイトのhreflangの基準
`hreflang`は、同じコンテンツの言語・地域別のアドレスを関連付ける情報です。翻訳文を作成する機能ではありません。Googleが訪問者に適した言語版を見つけるのを助けます。
| 実装場所 | 表示方法 | 選ぶときの確認点 |
| --- | --- | --- |
| HTML | ドキュメントの`head`に代替言語のリンクを表示 | 各ページのテンプレートで管理できるか |
| HTTPヘッダー | レスポンスの`Link`ヘッダーに表示 | サーバーでヘッダーを管理できるか |
| サイトマップ | 言語別URLの関係をサイトマップに表示 | ドキュメントの一覧を一括管理できるか |
Googleは、これらの方法を同等に扱います。そのため、HTML内にだけ記述しなければならないわけではありません。各言語のドキュメントには、自分自身を含め、代替言語のドキュメントを示す必要があります。対応するページ同士の関連付けも確認してください。[Googleの多言語ページに関するガイド](https://developers.google.com/search/docs/specialty/international/localized-versions)
## デプロイ結果の確認手順
デプロイ後は、本文の配信とキャッシュの動作を別々に検証してください。速度の測定値には、測定地域とキャッシュ状態も記録してください。次の順序で確認すると、問題のある箇所を区別しやすくなります。
1. ブラウザの開発者ツールでHTMLドキュメントのレスポンスを確認してください。主要な本文がレスポンスに含まれているか調べてください。
2. Search ConsoleのURL検査で、レンダリングされたHTMLを確認してください。実際のインデックス処理状態も別途点検してください。
3. HTMLレスポンスのキャッシュヘッダーを確認してください。Cloudflareでは`CF-Cache-Status`を読み取ってください。
4. 主なアクセス地域から同じドキュメントを測定してください。キャッシュにないリクエストと、キャッシュにヒットしたリクエストを区別してください。
5. コンテンツを修正した後、更新結果を確認してください。ログインページがキャッシュから除外されているかも点検してください。
Cloudflareは、動的HTMLを過度にキャッシュすると、ログインが正常に動作しなくなるおそれがあると警告しています。ログインフォームと認証済みページはキャッシュしないでください。修正後は、認証Cookieが維持されているかも確認してください。[Cloudflareのログイン問題に関するガイド](https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/)
## AIコーディングに伝える実装条件
AIには、技術の名前とともに、検証できる結果を求めてください。初期HTMLの内容と、キャッシュから除外する範囲を明記する方法が役立ちます。以下の文面は、公開ナレッジページを作る場合の依頼例です。
```text
公開ナレッジページの主要な本文を初期HTMLに含めてください。
公開ドキュメントは静的生成を優先して検討してください。
変動データの更新方法を別途説明してください。
CDNのHTMLキャッシュが適用されているか確認してください。
ログイン・アカウント・決済ページは共有キャッシュから除外してください。
コンテンツの修正時には、静的ファイルの再生成とキャッシュ更新を連動させてください。
多言語ページがある場合は、hreflangの関連付けを設定してください。
初期HTML、キャッシュ状態、修正の反映状況を確認する方法を示してください。
```
## FAQ
### 低関与ウェブは特定のフレームワークで作る必要がありますか？
特定のフレームワークが必須というわけではありません。主要な本文が初期HTMLに含まれているか確認してください。公開コンテンツのキャッシュと更新の方法もあわせて検討する必要があります。
### GoogleはJavaScriptを実行しないのですか？
GoogleはChromiumでJavaScriptを実行します。ただし、レンダリングの待ち時間やブロックされたリソースが処理に影響する場合があります。初期HTMLに本文を含めると、追加の実行への依存を減らせます。
### Reactで作ったサイトも静的生成できますか？
Reactでも静的HTMLを生成できます。サーバーでHTMLを作る方法にも対応しています。Reactを使っているかどうかだけで、初期HTMLの内容を判断することはできません。
### TTFBが0.8秒以下なら、ページ全体が表示されたということですか？
TTFBは、応答の最初のバイトが届くまでの時間です。画像のダウンロードや画面の構成は、その後も続く場合があります。ページ全体の読み込み時間とは区別する必要があります。
### TTFBが0.8秒を超えると、Google検索から除外されますか？
0.8秒は、web.devが示したおおよそのパフォーマンス目標です。これを超えると検索から除外されるというルールではありません。継続的な応答の遅延やサーバーエラーは、クロールの処理能力に影響する場合があります。
### 韓国のサーバーを使うと、グローバルサイトには不利ですか？
遠く離れた場所からアクセスするユーザーには、ネットワークの遅延が発生する場合があります。ただし、場所だけで特定の応答時間を断定することはできません。主なアクセス地域での実測値で判断してください。
### Cloudflareを接続すると、HTMLも自動でキャッシュされますか？
Cloudflare CDNは、デフォルトではHTMLとJSONをキャッシュしません。公開HTMLに適用するCache Rulesを確認してください。ルールを適用した後は、応答ヘッダーで実際のキャッシュ状態を確認する必要があります。
### CDNキャッシュにない最初のリクエストも、常に速いのですか？
キャッシュにないリクエストでは、オリジンサーバーから応答を取得する必要がある場合があります。そのため、キャッシュにヒットしたリクエストとは遅延時間が異なる場合があります。2つの状態を分けて測定してください。
### ログインページにもHTMLキャッシュを適用してよいですか？
ログインページや認証済みのHTMLはキャッシュしないでください。Cloudflareは、過度なキャッシュによってログインが正常に動作しなくなるおそれがあると警告しています。ユーザーごとの情報が別の訪問者に渡るリスクもあります。
### 静的サイトの記事を修正したのに、以前の内容が表示される場合はどうすればよいですか？
まず、新しいHTMLが生成され、デプロイされたか確認してください。その後、変更したURLのCDNキャッシュを更新してください。キャッシュを削除するだけでは、静的ファイルは再生成されません。
### hreflangはHTMLにだけ記述する必要がありますか？
Googleは、HTML、HTTPヘッダー、サイトマップによる方法に対応しています。3つの方法は、Googleの観点では同等です。運用しやすい方法を選び、言語ごとのリンクを一貫して維持してください。
### 小規模なサイトでも、クロールバジェットを重点的に管理する必要がありますか？
Googleのクロールバジェットに関する案内は、主に規模が大きく、頻繁に更新されるサイトを対象としています。ページ数が多くなければ、サイトマップの更新とインデックス登録レポートの確認から始めてください。サーバーエラーや本文の欠落がある場合は、その問題を先に解決してください。
## Sources
- [Google Search Central: JavaScript SEO の基本を理解する](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- [web.dev: ウェブでのレンダリング](https://web.dev/articles/rendering-on-the-web)
- [web.dev: Time to First Byte (TTFB)、2025年11月18日更新](https://web.dev/articles/ttfb)
- [Google: Google のクローラーとフェッチャーの概要](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en)
- [Google: クロールバジェットを最適化する](https://developers.google.com/crawling/docs/crawl-budget)
- [Cloudflare: デフォルトのキャッシュ動作](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)
- [Cloudflare Cache: 利用を開始する](https://developers.cloudflare.com/cache/get-started/)
- [Cloudflare: Cache Level (Cache Everything)](https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/)
- [Cloudflare のキャッシュレスポンス](https://developers.cloudflare.com/cache/concepts/cache-responses/)
- [Cloudflare: キャッシュをパージする](https://developers.cloudflare.com/cache/how-to/purge-cache/)
- [Cloudflare: 動的コンテンツとログインの問題](https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/)
- [Google Search Central: ページのローカライズ版について Google に伝える](https://developers.google.com/search/docs/specialty/international/localized-versions)
## Images
