静的ホスティングでも成立するインタラクティブサイト構成

静的ホスティングは、文章だけのサイトに限定されません。サーバーで毎回HTMLを作らなくても、診断、計算、検索、テーマ切替、URL状態共有はブラウザ内で実装できます。

重要なのは、サイト全体をアプリにするのではなく、HTMLとして配る情報と、ブラウザで変化する状態を分離することです。React公式も、既存ページを全面rewriteせず、必要な場所へinteractive componentを追加できると説明しています（2026年9月1日確認）。

先に結論：静的HTMLを本体、操作を小さな島にする

Astroの静的生成では、本文、見出し、検索入口、診断の説明、リンク、metadataをbuild時にHTMLへ出します。Reactは検索結果の更新、質問への回答、URL stateの復元など、状態が変わる場所だけに使います。Astro公式も、ページの大部分を静的HTMLにし、必要なインタラクティブUIだけへJavaScriptを追加するIslands Architectureとして説明しています（2026年9月1日確認）。

BUILD ORBITの実装境界は次のように整理できます。

JavaScriptがなくても読者が「何のサイトか」「何を選べるか」「次にどこへ進むか」を理解できるなら、静的配信との相性がよいと言えます。操作がないと本文も検索入口も存在しない構成なら、別の配信方式を検討します。

静的生成を情報の本体にする

Astroのbuildは、ルートごとのHTML、CSS、必要なJavaScript chunkをdist/へ出力できます。記事、見出し、パンくず、関連記事、メタデータはbuild時に確定させます。

静的HTMLへ置くものは次です。

• title、description、canonical、OG。
• 見出し、本文、表、注意事項。
• 記事一覧、Project一覧、主要ナビゲーション。
• no-JS時にも必要な結論。
• structured data、RSS、sitemap、robots。

これらをクライアントレンダリングへ移す理由はほとんどありません。初期JavaScriptを減らし、直接URLを開いた時点で内容が存在する状態にします。

3つの境界を実例で再現する

「インタラクティブ」を一括りにせず、入力・判定・説明の三つを分けます。Project Atlasの実データをこの順に当てると、動かす場所と残す場所をレビューできます。

1. 入力：利用者が変えられる条件だけを、label付きのフォームや操作へ置く。
2. 判定：同じ入力から同じ結果を返すルールを、UIと別の純粋関数として保つ。
3. 説明：結果の理由、前提、停止条件、次の読み物を初期HTMLへ残す。

ここで「説明」を結果画面の後から生成しないことが重要です。判定が動かなくても、読者が条件を理解し、別のガイドへ進めるなら、静的配信の失敗範囲を局所化できます。結果の出所と限界を記録する方法は複数サイト運営の知見を再利用するデータ設計で確認します。

Islands Architectureで状態を局所化する

Astro公式ドキュメントのIslands architectureは、ページの大部分を静的HTMLとして保ち、必要なインタラクティブUIだけを独立して読み込む考え方です。

BUILD ORBITでReactを使うのは、Project Orbit、Build Simulator、Command Palette、Performance Observatoryのように状態を持つ場所です。記事本文、一覧、パンくず、フッターはAstroコンポーネントのまま配ります。

読み込み条件も分けます。

• ヘッダー操作: client:idleで初期描画後に準備。
• ファーストビューの操作: 必要ならclient:load。
• 画面下の実験: client:visibleで近づいてから読み込む。

Islandを増やす前に、「HTMLのdetailsや小さなscriptで十分か」を確認します。

Reactを使う場所・使わない場所

「Reactを使えるか」ではなく、「HTMLの役割をReactへ移す必要があるか」で決めます。

検索と診断はブラウザ内で完結できる

小〜中規模のコンテンツなら、build時にタイトル、要約、タグ、URLの検索データを作り、Command Paletteへ渡せます。全文検索の大きな索引を初期読込する必要はありません。

診断や計算は、入力を型付きオブジェクトへ正規化し、純粋関数で結果を返します。UIと判定を分けると、ルールをunit testできます。

type Profile = "content-first" | "tool-first" | "experience-first";

function evaluate(input: SimulatorInput) {
  const normalized = normalizeInput(input);
  return normalized.purpose === "article" ? "content-first" : "tool-first";
}

ランダムな文章生成にしないため、同じ入力は同じ結果になります。APIキーも外部DBも不要です。

この例は判定の考え方だけを示す最小形です。実装では、入力の正規化、結果の説明、次に読むリンクを別データに分けます。結果だけをクライアントで作り、判断基準や代替経路をHTMLから消す設計は避けます。

URL状態共有は、秘密情報を入れない

Simulatorの状態はURLSearchParamsへ短いキーで保存できます。ページを再読込しても同じ条件になり、リンクを共有できます。

注意点は、URLが履歴、アクセスログ、共有先へ残ることです。氏名、メール、相談内容などの個人情報を入力項目にしません。条件は目的、記事量、配信環境のような設計情報だけに限定します。

不正な値や古い値が来た場合は、schema相当の正規化関数で既定値へ戻します。URL文字列をHTMLとして直接描画しません。

FTP配信ではdistの先を品質ゲートにする

FTP型ホスティングでは、buildが成功しても、古いファイルがupload/へ残る、必要な404がない、サブディレクトリを直接開けない問題が起きます。

安全な流れは次です。

1. npm run buildでdist/を生成する。
2. route、内部リンク、sitemap、OG画像をdist/で確認する。
3. prepare:uploadでdist/をupload/へ同期する。
4. ファイル数とhashを比較する。
5. 本番FTP反映は別の明示作業として行う。

手動コピーを繰り返すより、同期スクリプトを一つにします。ただし削除対象は必ずプロジェクト内のupload/と確認し、予期しないパスを再帰削除しないようにします。

キャッシュと直接アクセス

ハッシュ付きのJS/CSSは長期キャッシュに向きます。HTML、sitemap、RSSは更新時に新しい内容が届く設定が必要です。サーバー設定を変更できないFTP環境では、まずファイル名と配置だけで成立する構成を選びます。

末尾スラッシュ方針も統一します。/notes/example/を採用するなら、出力はnotes/example/index.htmlになり、ディレクトリの直接アクセスで読めるか確認します。

相対パスへ一律変換するとcanonicalやOGまで壊れるため、サイト内assetはルート基準、検索向けURLは本番絶対URLと役割を分けます。

静的構成が向かないケース

次の要件では、サーバーや外部サービスが必要になる可能性があります。

• ユーザーごとの非公開データ。
• 決済後だけ見せるコンテンツ。
• 頻繁に変わる在庫や予約。
• 大規模な全文検索。
• 信頼できるサーバー側判定が必要な認証。

これらを無理にlocalStorageへ置くと、セキュリティと整合性を失います。静的構成を選ぶことは、すべてをクライアントへ移すことではありません。

no-JSと配信前の確認

JSを無効にしても、本文、入力条件、診断の観点、関連記事、Patternへの導線を読めるようにします。診断結果の再計算だけが止まるなら、noscriptで「操作にはJavaScriptが必要」と説明し、静的な基本方針へリンクします。

公開前はnpm run build、npm run test:routes、npm run check:links、npm run prepare:upload、npm run check:deliveryを順に確認します。これらはBUILD ORBITのコマンド名なので、別環境ではpackage.jsonの実際のスクリプトへ置き換えてください。Astroの構成判断を実装へ落とすときは、静的な本体に操作だけを重ねる設計のチェックリストも使えます。

構成を決めるチェックリスト

• 主要情報はbuild時に確定できるか。
• 状態を持つUIだけをIslandにできるか。
• APIキーなしで主要機能が成立するか。
• 共有URLへ秘密情報が入らないか。
• 直接アクセスと404を配信先で再現できるか。
• distと納品物の一致を自動確認できるか。
• サーバーが必要な要件を見落としていないか。

静的サイトの強みは、動かないことではありません。動かす場所を限定できることです。情報の本体を静的にし、状態を小さなIslandへ閉じ込めると、リッチな体験と軽い配信を同時に保てます。

自分の要件で境界を確認する場合は、Build Simulatorへ記事量、操作密度、配信環境を入力し、出力された構成候補とpreflightをこのチェックリストに照らしてください。Simulatorは条件に基づく設計補助であり、server要件や運用責任を自動で確定するものではありません。

よくある質問