このサイトで使っている技術と、公開までの流れ

このサイト自体の構成を書いておきます。同じような個人サイトや小規模なコーポレートサイトを作る場合、ほぼそのまま流用できる構成のためです。

要点は3つです。Astro で作る、TypeScript で書く、GitHub に反映すると自動で公開されます。

全体像

手元のPC
  │  文章を書く、コードを直す
  ↓
Git（バージョン管理）
  │  変更を記録する
  ↓
GitHub（置き場）
  │  反映をきっかけに、次の工程が自動で動く
  ↓
Cloudflare Pages（公開の仕組み）
  │  HTMLを組み立て、世界中の拠点に配る
  ↓
公開（独自ドメイン）

手作業でファイルをアップロードする工程がありません。 GitHub に反映した時点で、あとは自動で進みます。

Astro とは

Webサイトを作るための仕組み（フレームワーク）の一つです。特徴は、あらかじめHTMLを組み立てておく点にあります。

2つの作り方の違い

このサイトは後者です。記事もプロフィールも、見る人によって変わりません。であれば、毎回作る必要がありません。

作り置きしたHTMLを配るだけなので、表示が速く、サーバーの費用もかかりません。

JavaScriptを送らない

Astro の特徴として、必要のないJavaScriptをブラウザに送らないという設計があります。

一般的なフレームワークでは、画面を組み立てるための処理がブラウザ側でも動きます。その分、読み込むファイルが増えます。Astro は組み立てを公開前に済ませるため、動きが必要な部分だけをJavaScriptとして送ります。

このサイトでJavaScriptが動いているのは、次のところだけです。

• ダークモードの切り替え
• スマホのメニュー開閉
• 記事一覧の絞り込みと追加読み込み
• アクセス解析のタグ

書き方

.astro という拡張子のファイルに、HTMLとほぼ同じ形で書きます。上部の --- で囲んだ部分に、データを準備する処理を書けます。

---
// ここは公開前に一度だけ動く（ブラウザでは動かない）
const posts = await getCollection('post');
---

<ul>
  {posts.map((post) => <li>{post.data.title}</li>)}
</ul>

部品として切り出して使い回せます。 ヘッダーやカードのように何度も出てくる要素を1か所で管理できます。

記事はMarkdownで書く

記事は .md ファイルで書いています。冒頭に決まった形式で情報を書き、その下に本文を書きます。

---
title: '記事のタイトル'
publishDate: 2025-01-02T00:00:00Z
category: 'design'
---

本文をここに書く。

管理画面もデータベースもありません。ファイルを1つ置けば記事が1本増えます。

この形式は、後から別の仕組みに移すときにも扱いやすいです。文章がテキストファイルとして手元に残るためです。

TypeScript とは

JavaScript に型を足したものです。書いている時点で、多くのミスに気づけます。

型があると何が変わるか

// JavaScript：実行するまで気づけない
function getPrice(item) {
  return item.price * item.quantity;
}

getPrice({ price: 1000 });   // quantity がない → 実行時にエラー

// TypeScript：書いている時点でエラーとして表示される
type Item = {
  price: number;
  quantity: number;
};

function getPrice(item: Item) {
  return item.price * item.quantity;
}

getPrice({ price: 1000 });   // ← ここで「quantity がありません」と出る

エラーに気づくタイミングが前倒しになります。 公開してから気づくのと、書いている最中に気づくのとでは、直す手間がまるで違います。

記事の形式も型で守る

このサイトでは、記事の冒頭に書く項目にも型を定義しています。

const post = defineCollection({
  schema: z.object({
    title: z.string(),
    publishDate: z.date(),
    category: z.string().optional(),
    tags: z.array(z.string()).optional(),
  }),
});

タイトルを書き忘れた記事があると、公開前のビルドで止まります。間違ったまま公開されることがありません。

そのほか使っているもの

テンプレートをもとにしています。 ゼロから組むより、既存のテンプレートを土台にして、配色・文言・構成を自分用に差し替えるほうが早いです。

ディレクトリの構成

src/
  assets/images/   画像（記事のサムネイルなど）
  components/      部品（ヘッダー、カードなど）
  data/post/       記事のMarkdownファイル
  layouts/         ページ全体の枠
  pages/           URLになるファイル
  utils/           共通の処理
  config.yaml      サイト名やメタ情報
  navigation.ts    メニューの項目

pages/ の中のファイル構成が、そのままURLになります。 pages/about.astro を置けば /about で見られます。

記事を追加する手順

1. src/data/post/ に .md ファイルを作ります
2. 冒頭にタイトル・公開日・カテゴリ・タグを書きます
3. サムネイル画像を src/assets/images/ に置く（16:9）
4. 手元で確認する（npm run dev）
5. 問題なければ Git に記録し、GitHub に反映します

4を飛ばさないでください。 表記の崩れや画像のパス違いは、手元で見ればすぐ分かります。

公開までの流れ

自動で公開される仕組み

GitHub に反映すると、Cloudflare Pages がそれを検知して次を実行します。

1. 変更を受け取る
2. 必要なものを取ってくる（npm install）
3. HTMLを組み立てる（npm run build）
4. できたファイルを配信拠点に配る
5. 公開

1〜2分ほどで反映されます。 手元での操作は、変更を記録して反映するところまでです。

ビルドが通らなければ公開されない

3で失敗した場合、そこで止まり、公開中のサイトはそのままになります。壊れたものが公開されることがありません。

止まる主な原因は次のとおりです。

エラーの内容は管理画面のログで確認できます。多くは、手元で確認していれば起きません。

失敗したときに戻せる

公開のたびに履歴が残ります。管理画面から過去の状態に戻せます（ロールバック）。

このため、多少思い切った変更を入れても、直せなくなる状態にはなりにくいです。

本番前に確認できる

作業用の枝（ブランチ）を作って反映すると、本番とは別のURLで確認用のサイトが作られます。大きめの変更はこの形で確認してから本番に入れます。

ドメインとSSL

独自ドメインは、公開の仕組みと同じ事業者で取得しています。同じ場所で管理すると、接続の設定が自動で済みます。

SSL（https:// で表示されるようにする仕組み）も自動で設定され、更新も自動です。ここは何もしていません。

費用

年間のドメイン代だけで運用できています。 記事が増えても、この構成では費用はほぼ変わりません。

この構成に向いているもの

最後の点は重要です。管理画面がないため、更新にはファイルを扱う操作が必要になります。社内の誰でも更新する必要があるなら、別の仕組みを検討したほうがよいです。

まとめ

• Astroで、公開前にHTMLを作り置きします。表示が速く、費用がかかりません
• 必要のないJavaScriptを送らない設計
• 記事はMarkdownファイルです。1ファイル＝1記事
• TypeScriptで、ミスを書いている時点で見つけます。記事の形式も型で守ります
• GitHubに反映すると自動で公開されます。1〜2分
• ビルドが通らなければ公開されないため、壊れたまま出ることがありません
• 失敗しても過去の状態に戻せます
• 費用は年間のドメイン代のみ

小規模なサイトであれば、この構成で十分に回ります。手作業でのアップロードをなくすところが、いちばん効いています。