前提：公開されているのは、ただのファイルです
ホームページというと、サーバーの中でプログラムが動いていて、アクセスがあるたびに データベースから記事を取り出してページを組み立てる——という作りを思い浮かべる方が多いと思います。 長らく主流だった作り方で、WordPress もこの形です。
このサイトは違います。ページは公開する前に全部作り終えてあり、 閲覧者に届いているのは出来上がったHTMLと画像だけです。 アクセスされた瞬間に動いているプログラムは、原則としてひとつもありません。
記事を書いてから公開されるまで
- 1
書く
/admin/ の管理画面（Decap CMS）で、お知らせの日付・タイトル・本文を入力します。見た目は普通のブログ管理画面です。
- 2
コミットされる
保存すると、その記事が1つのテキストファイルとして GitHub のリポジトリに直接コミットされます。保存＝コミットです。
- 3
自動でビルド
リポジトリの変更を Netlify が検知し、Astro がサイト全体のHTMLを組み直します。ここまで数十秒です。
- 4
公開
できあがった静的ファイルが配信されます。以降、閲覧者のアクセスで動くプログラムはありません。
ポイントは手順2です。管理画面（Decap CMS）はデータベースに書き込むのではなく、 GitHub のリポジトリに直接コミットします。 お知らせを1本書けば、リポジトリにJSONファイルが1つ増える。それだけです。 画像も同じで、アップロードするとリポジトリの中に入ります。
つまり Gitがこのサイトの正本（マスターデータ） です。 デザインもプログラムも原稿も画像も、全部が同じ1つの履歴の中にあります。 別々の場所にバックアップを取って回る必要がありません。
よくあるCMS構成との違い
| 比較項目 | 一般的なCMS構成 サーバー＋データベースで、アクセスのたびに生成する | このサイト 採用 Gitを正本にして、公開前に生成しておく |
|---|---|---|
| ページの生成 | アクセスのたびにサーバーが組み立てる | 公開前に組み立て済み。配信するだけ |
| 記事の保管場所 | データベース | Gitリポジトリの中のテキストファイル |
| 表示に必要なもの | Webサーバー、PHP等の実行環境、データベース | 静的ファイルだけ |
| 攻撃されうる面 | 管理画面・データベース・プラグインが常時公開される | 公開側に動くプログラムがほぼ無い |
| 保守作業 | 本体とプラグインの更新を止められない | 公開後のサイトに更新作業は発生しない |
| 元に戻す | バックアップから復元する | Gitの履歴から任意の時点に戻せる。誰がいつ何を直したかも残る |
| 費用 | サーバーの月額が継続的にかかる | 無料枠が中心。独自ドメイン代が主な費用 |
色を敷いた2行が、この構成を選んでいる主な理由です。
どちらが優れているという話ではありません。 会員登録や在庫連動のように、閲覧者ごとに違う画面を出す必要があるサイトなら、 サーバーとデータベースを持つ構成のほうが素直です。 一方このサイトのように 「全員に同じものを見せればよい」サイト では、 アクセスのたびに組み立て直す仕組みは、速度と安全性を差し出して何も得ていないことになります。
それでも動かす必要がある部分
とはいえ、完全に静止したサイトというわけにもいきません。 このサイトでサーバー側が動くのは、次の3か所だけです。 「動かす必要がある部分だけを、必要な瞬間だけ動かす」 という切り分けをしています。
- お問い合わせフォーム：Netlify Forms が受け取ります。送信が発生したときだけ関数が起動し、内容をGoogleスプレッドシートへ転送します（Netlify側にも記録が残るので二重に保存されます）
- 社内向けの一覧ページ：フォーム送信の一覧を表示するページだけは、その場でデータを取りに行きます。ここは静的化せず、サーバー処理として動かしています
- ログイン：管理画面と社内ページは Netlify Identity で認証します。ログインしていなければデータは返しません
実際に踏んだ罠：APIトークンの書き方ひとつでビルドが落ちる
社内向けページが使うAPIトークンを、フレームワークの一般的な環境変数の読み方
（import.meta.env）で参照したところ、ビルドが失敗しました。
この書き方は ビルド時に値を実際のファイルへ埋め込んでしまう ため、
Netlify の秘密情報スキャンが「トークンが公開ファイルに混入している」と正しく検知して止めたのです。
正解はサーバー側でのみ評価される process.env を使うこと。
ビルドが落ちてくれたおかげで気づけましたが、これは検知されなければ
そのまま世界中に公開されていた類のミスです。
静的サイトでは「どこで評価される値なのか」を常に意識する必要があります。
構成一覧
- サイト生成Astro（静的出力。一部のページだけサーバー処理）
- ホスティングNetlify（ビルドと配信、CDN、SSL）
- 原稿の保管GitHub リポジトリ（src/data/news/ に1記事1ファイル）
- 管理画面Decap CMS（Gitベース。データベース不要）
- ログインNetlify Identity（管理画面と社内ページの認証）
- フォームNetlify Forms ＋ イベント関数でスプレッドシートへ転送
- 実行環境Node.js 22
この構成の副産物として、サイトの引っ越しが容易という利点もあります。 サイトの中身が丸ごとGitのリポジトリに入っているので、 ホスティング先を変えても、持っていくものはリポジトリだけです。 特定の会社のサーバーやデータベースに縛られません。