Step 2: Browser & SPA
13. Astroの静的ホスティング：HTMLの配信と404・更新の確認
このプロジェクトはAstroでURLごとのHTMLを生成し、画像加工はブラウザのJavaScriptで行います。静的ホスティングでは、ビルドしたファイルを配信します。まずローカルのビルドとプレビュー、次に公開先のURL応答を別々に確認します。
1. 静的ホスティングとは何か？
これまでのWeb開発では、Webサイトを公開するために「Webサーバー（ApacheやNginx）」を自ら構築し、運用するのが一般的でした。しかし、静的ホスティング（Cloudflare Pages, Vercel, Netlifyなど）は、私たちがビルドしたHTML/CSS/JSといった「静的ファイル」を直接預かり、世界中のエッジサーバー（CDN）を通じて配信してくれるサービスです。
「猫の手ツール」はAstroでURLごとのHTMLを生成する構成です。画像加工はブラウザのJavaScriptで動きますが、サイト全体を１枚のHTMLで扱うSPAとは区別できます。静的ホスティングは、こうした複数HTMLのサイトにも利用できます。
2. メンテナンスからの解放：Before / After
インフラエンジニアの視点で、従来のサーバー運用とモダンな静的ホスティングを比較してみます。
【Before】従来のVPS/専用サーバー運用
# OSのアップデートとパッチ適用
sudo apt update && sudo apt upgrade
# Nginxの設定ファイルを編集してSSL証明書（Certbot）を更新
sudo nano /etc/nginx/sites-available/default
sudo certbot renew --nginx
# サーバーの死活監視と負荷に応じたリソース調整が必要【After】静的ホスティング（Cloudflare Pagesなど）
# Git連携・ビルドコマンド・出力ディレクトリを設定済みの場合
git add .
git commit -m "Add new feature"
git push origin main
# 1. 自動的にビルドが開始される
# 2. ビルド成功後、ホスティング側の配信手順に従って公開される
# 3. SSL証明書も自動で維持される3. 静的配信の利点と管理の範囲
単に「楽だから」という理由だけではありません。静的ホスティングには技術的に非常に優れた側面が3つあります。
- 配信負荷の分散： CDNに配信を任せることで、自前の１台へアクセスが集中する構成を避けられます。ただし配信サービスの障害、利用上限、外部APIの停止は起こり得るため、無停止の保証ではありません。
- 運用費の見通し： 無料枠があるサービスもありますが、転送量、ビルド回数、独自ドメインや追加機能の費用はサービスごとに確認します。利用条件は変わるため、公開時の料金表を基準にします。
- 強固なセキュリティ： サーバーサイドに動的なロジック（PHPやRubyなど）が存在しないため、自前のアプリサーバーがSQLやOSコマンドを実行する入口を減らせます。ただし、外部API、配信するJavaScript、依存パッケージ、管理アカウントの保護は別途必要です。
4. 注意点：初心者がハマる「SPAの404エラー」
クライアント側でURLを切り替えるSPAでは、画面内の移動では動くのに、そのURLへ直接アクセスすると404になる場合があります。
SPAではJavaScriptがルーティング（画面遷移）を制御しているため、/notes/page1 のようなURLでブラウザの更新ボタンを押すと、ホスティングサーバーは実在しないディレクトリを探しに行き、エラーを返してしまいます。
SPAではアプリのルートに限って入口のHTMLへ書き換える設定を使う場合があります。URLを変えるリダイレクトと、URLを保つ内部書き換えは別です。AstroでページごとのHTMLを生成するサイトでは、存在するHTMLを配信し、存在しないURLには404を返す構成を基本にします。すべてをトップへ書き換えると、存在しない記事でも正常応答になってしまいます。
公開前に確認する３種類のURL
- 実在する記事：直接開いて正しい本文が表示され、HTTP 200になるか。
- 移転した記事：対応する新URLへ恒久転送し、転送がループしないか。
- 存在しない記事：トップページを200で返さず、404ページとHTTP 404を返すか。
HTMLを生成できることと、公開先がそのURLをどう返すかは別の確認です。Cloudflare Pagesなどの既定動作もサービスごとに異なるため、配信設定と実際の応答を両方調べます。
このプロジェクトの公開対象は、Astroのビルド結果
確認した採用版はAstro 6.0.7です。package.jsonのbuildはastro build、previewはastro previewを実行します。設定にはサイトのドメインとサイトマップ生成があり、公開先用のサーバーアダプターは設定していません。これは採用設定の確認で、公開サービスの管理画面を検証したという意味ではありません。
npm.cmd run build
npm.cmd run previewプロジェクトのフォルダーでビルドを行い、成功後にターミナルへ表示されるプレビューURLを開きます。例えば画像変換ツールも、URL用のHTMLとブラウザ側の処理を配信します。画像を変換する専用サーバーが必要になる構成ではありません。画像変換の制作解説で入力から保存まで確認できます。
5. まとめ：実務でどう役立っているか
ブラウザ側の画像処理と静的配信を分けると、公開するものはHTML・JavaScript・CSSなどのファイルになります。配信の設定、依存パッケージ、公開権限を管理する作業は残ります。
静的配信でもドメイン、公開権限、ソースコード、依存ライブラリは管理対象です。ビルドの成功と、公開先で期待するURLが返ることを別々に確認します。
参考資料
既定の出力はdistです。公開先へ渡すディレクトリとビルドコマンドは、Astro公式の公開ガイド（英語）（別タブで開く）で確認します。Cloudflare Pagesを選ぶ例ではCloudflare公式のAstro設定（英語）（別タブで開く）にnpm run buildとdistが示されています。Git連携や本番ブランチは公開先で設定する条件で、このソースから確認できる内容とは区別します。