本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリ第1弾として、ホスティングについて解説する記事です。
モバイルで3秒以上の読み込みで53%が離脱（Google調査）。ホスティング設計はユーザー体験の底を決める領域です。本記事ではCDN・キャッシュ戦略・エッジコンピューティング・画像最適化・Core Web Vitalsを解説し、「Static First」と「Git push = 本番デプロイ」という2大原則を示します。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- CDN前提・Static Firstで設計する
- ファイル名ハッシュ化で長期キャッシュを効かせる（invalidation依存を捨てる）
- Git push=本番デプロイの自動化を最初に作る
- Core Web Vitalsを数値で追う（LCP < 2.5秒 / INP < 200ms / CLS < 0.1）
この記事を読む前に
本記事はブラウザ側（画面側）の仕組みの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「Webサービスが動く仕組み」と「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもホスティングとは何か
ホスティングとは、ざっくり言えば「作ったWebサイトやアプリのファイルを置いて、世界中のユーザーに届ける仕組み」です。
宅配便の配送拠点を想像してください。倉庫（サーバー）が東京に1か所だけだと、北海道や沖縄への配送は時間がかかります。全国各地に中継拠点（CDN）を置けば、最寄りの拠点から素早く届けられます。さらに「よく注文される商品はあらかじめ各拠点に在庫しておく」（キャッシュ）ことで、倉庫に問い合わせる手間すら省けます。
なぜホスティング設計が重要なのか
もしホスティング設計を軽視したらどうなるか。せっかく作った機能もページも、届くのが遅ければユーザーは見てくれません。バックエンドが「サーバー上でロジックを実行する」側なのに対し、フロントエンドは「大量の静的ファイルを世界中のユーザーに届ける」側で、求められる特性が全く違います。CDNを使うか・エッジで処理するか・どうキャッシュするかを決めるのは、数百ミリ秒単位でUXを削り出す作業です。
主要なホスティング形態
| 形態 | 例 | 特徴 |
|---|---|---|
| 自サーバ配信 | Nginx / Apache | 古典的・自由だが運用負荷大 |
| クラウド静的ストレージ | S3 / GCS | 安価で堅牢・CDN連携が前提 |
| CDN配信 | CloudFront / Cloudflare | 世界中のエッジから高速配信 |
| プラットフォーム型 | Vercel / Netlify / Cloudflare Pages | Git連携で自動デプロイ |
| フルスタック型 | Next.js+Vercel | フレームワークとホスティングが一体 |
現代の本命はプラットフォーム型で、git push するだけで自動ビルド・デプロイ・CDN配信まで完結します。個人開発なら無料枠で十分実用的です。CDN製品は、AWS中心ならCloudFront+S3が鉄板構成（本シリーズが置かれているsenkohome.comもこの構成です）、無料枠とエッジ機能・DDoS対策重視ならCloudflareが現代のスタンダードです。FastlyやAkamaiは大手メディア・エンタープライズ向けで、個人や小規模で選ぶ必要はありません。
CDNの基本
CDNは、世界中に分散配置されたエッジサーバーにコンテンツのコピーを置き、ユーザーから最も近いエッジから配信する仕組みです。東京のユーザーが米国サーバに直接アクセスすると往復200ms以上かかりますが、東京エッジでキャッシュヒットすれば10ms以下で返せます。
CDNはレイテンシ削減に加えて、「オリジン負荷の軽減」「DDoS攻撃の吸収」という防御的効果もあります。「速くするため」だけでなく「落ちないため」にも入れる、二重の価値があるインフラです。
キャッシュ戦略 ― ハッシュ化ファイル名が大前提
CDNは「キャッシュをどう管理するか」が設計の肝です。ファイルの種類によって更新頻度が全く違うため、一律のTTLでは最適化できません。原則は「HTMLは短命（数分〜no-cache）+ETag、CSS / JS / 画像は長期キャッシュ（1年）」です。
これを成立させる決定的なテクニックがファイル名ハッシュ化です。
main.abc123.js ← 内容変わればファイル名変わる
→ 長期immutable可能内容が変われば自動的に新URLになるため、「いつキャッシュを破棄するか」を悩む必要がなくなり、CDNの明示的invalidation（全世界伝播に数分・料金も発生）自体が不要になります。Next.js / Vite / webpack等のモダンビルドツールは全てこのパターンを標準装備しています。
エッジコンピューティングと静的/動的配信
CDNのエッジでコードを実行するのがエッジコンピューティング（Cloudflare Workers・Vercel Edge Functions等）です。コールドスタートがほぼゼロ（数ms）で、A/Bテストの振り分け・認証前置フィルタ・国別リダイレクト・画像変換といった「軽い処理を低遅延で」が最適解です。重い処理は依然としてオリジン側で行います。
配信方式は、ビルド時にHTMLを作っておく静的配信（SSG）と、リクエストごとに生成する動的配信（SSR）に分かれます。静的配信はCDNに置くだけなのでサーバ障害の影響を受けず、配信コストも極めて低い。ブログ・ドキュメント・マーケサイトなら静的で十分で、ユーザーごとに内容が変わるログイン後の画面だけSSRにする──この「Static First（まず静的、必要部分だけ動的）」が現代の本命です。
なおドメイン・SSLは現代ではほぼ自動化されています。Vercel等は独自ドメインを設定するだけでSSL証明書を自動発行・更新し、HTTP/2・HTTP/3対応も標準です。
画像最適化とCore Web Vitals
画像は多くの場合、サイト全体の最大のペイロードを占めます。ここを最適化するかどうかで表示速度が数秒単位で変わります。手法は、次世代フォーマット（WebP / AVIFでJPEGの半分〜1/3）、レスポンシブ画像（srcset）、遅延読み込み（loading="lazy"）、CDN変換の4つですが、Next/ImageやAstroの <Image> はこれら全てを自動生成してくれます。手書きの <img> より、フレームワークのコンポーネントに任せるのが圧倒的に効率的です。
成果はCore Web Vitalsの数値で追います。GoogleのSEO判定に直結し、「75%のページビューがGood圏内」にあるかが評価基準です。
※ 2026年4月時点のGoogle公式閾値です。
| 指標 | Good | Poor |
|---|---|---|
| LCP（最大コンテンツ描画） | < 2.5秒 | > 4.0秒 |
| INP（操作の応答性） | < 200ms | > 500ms |
| CLS（レイアウトのズレ） | < 0.1 | > 0.25 |
| JSバンドルサイズ（gzip後） | < 170KB | > 350KB |
LCPはCDN・画像最適化・初期HTMLサイズで、INPはJS実行量の削減で、CLSは画像・広告のサイズ事前指定で改善します。PageSpeed Insights / Search Consoleで週1回計測し、悪化したら即対応するのが運用の鉄則です。
3つのシナリオで考える
個人開発・スタートアップの場合
VercelやNetlify、Cloudflare Pagesの無料枠が本命だと思います。Git pushするだけでSSLもCDNもプレビュー環境も全て自動化されますので、インフラを意識する時間が文字通りゼロになります。数万PVくらいまでは無料枠のままで戦えてしまいますよ。
中小SaaSの場合
マーケサイトやLPはVercelなどのホスティングPaaSに置いて、ログイン後のアプリ本体はECS FargateやCloud Runに寄せる、という分離構成が現実的です。トラフィックが増えてPaaSの従量課金が跳ね上がってきたら、CloudFront + S3への移行を検討するラインと考えてください。
大企業の場合
この規模になると社内基盤や監査要件との整合が優先になりますので、CloudFront + S3（またはAzure Front Door）に自社CI/CDを組み合わせた構成が標準となります。データ主権・IP制限・WAF要件をホスティングPaaSの機能だけで満たせるかを最初に確認して、満たせないのであれば素直に自社クラウドへ寄せるべきでしょう。
AI判断軸 ― Git push=デプロイがAI駆動開発の前提
Git連携デプロイがAIのボトルネックを消す
Vercel・Netlify・Cloudflare PagesのようなGit連携型プラットフォームでは、mainブランチへのpushが即座に本番デプロイになります。AIがコードを生成 → PRを作成 → マージ → 自動デプロイ、という一連のフローが人間の介入なしで回るため、AI駆動開発のデプロイ頻度を最大化できます。手動FTPや独自デプロイスクリプトでは、AIが書いたコードの本番反映に人間の手動操作が挟まり、そこがボトルネックになります。
エッジ関数とAIの組み合わせ
Edge RuntimeはAIが生成したサーバサイドロジックをグローバルに低レイテンシで配信できますが、Node.js互換が部分的（fs モジュールが使えない等）である点に注意が必要です。この制約をプロジェクトルールとして明示しておくと、AIは互換性のあるAPIだけを使ったコードを生成します。
やってはいけないこと
サイト全停止・古い版表示・請求書爆発の原因を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| HTMLを長期キャッシュで配信 | デプロイしても古い版が出続ける → HTMLは短命（s-maxage=60程度）にする |
| ファイル名をハッシュ化せず長期キャッシュ | 更新のたびにinvalidationが必要になる → ビルドツールの自動ハッシュ化を使う |
| CDNを入れずオリジン直接配信 | DDoSに一晩で落とされる → Cloudflare無料枠でも入れる |
| 画像を元サイズのまま配信 | LCP悪化の定番 → Next/Image等で自動変換する |
| 画像のwidth / height属性未指定 | CLS悪化の直接原因 → 必ず固定サイズを指定する |
| 全ページSSRにする | 関数実行料金が線形爆発する → Static Firstで設計する |
CDNは入れるだけでは守りません。設定と運用で価値が決まります。
筆者メモ ― 「CDNがあるから安心」の落とし穴
2019年7月のCloudflare大規模障害は、CDN自体がSPOFになり得ることを示した事件です。単一の正規表現がデプロイされた途端、全エッジでCPU 100%を引き起こし、約30分にわたり全世界のトラフィックに影響が出ました。2021年6月のFastly障害（Amazon・GitHub・Redditが一斉停止）も同系統で、「CDNは落ちない」という前提は成り立たないことが一気に認識されました。
「CDNがあるから安心」と思考停止するのではなく、オリジン直接アクセスのフォールバック経路や障害時のステータスページ運用も合わせて設計しておくべき、というのが共通の教訓です。可用性を極める現場ほど、マルチCDNのような「CDNを信じすぎない設計」に向かっています。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 配信元（S3 / VPS / プラットフォーム型）
- CDN製品（CloudFront / Cloudflare / Fastly等）
- キャッシュTTL戦略（HTML短命・静的長期）
- エッジコンピューティングの利用範囲
- 画像最適化方針（フォーマット・CDN変換）
- Core Web Vitalsの目標値と計測方法
この記事に関連する記事
まとめ
本記事はホスティングについて、CDN・キャッシュ戦略・エッジ・Core Web Vitalsまで含めて解説しました。如何だったでしょうか。
CDN前提・Static First・ハッシュ化ファイル名・Git push = 本番デプロイ。この4点を押さえれば、配信は速く・落ちず・運用が軽くなります。
次回はレンダリング方式（MPA/SPA/SSR/SSG/ISR）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Amazon CloudFront も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（37/95）