ブログ記事を書くために新しい画面を作る必要はありません。src/content/blog/ の下にMarkdownファイルを1つ追加すると、ビルドが記事ページを作り、言語別の一覧・RSS・サイトマップにも一緒に反映します。書き手が管理するのは本文とfrontmatterだけで、繰り返し使う画面やつなぎ込みはサイトのコードが受け持ちます。
なぜ管理画面を作らなかったのか
このブログの主な作業は、記事を書いて公開することです。先に管理画面を作ると、ログイン・権限・保存API・エディタまで一緒に運用しなければなりません。一方でMarkdownなら、変更履歴をgitで確認でき、記事とコードが同じリポジトリにあるので、一度のビルドで公開結果を確かめられます。
そこで、記事の入力の単位を小さく決めました。
ファイルの先頭にfrontmatterを書き、その下に本文と、必要なら d3-flow のような図のブロックを置きます。この構造を記事ごとに繰り返せば、別のエディタがなくても同じ描画ルールを使えます。
ファイル1つが記事1つです。ファイル名はURLのslugになるので、最初に決めた名前をそのまま使い続けます。記事を直しても、アドレスは変わりません。
frontmatterの役割
本文の上のfrontmatterには、タイトル・説明・公開日・タグを書きます。lang を省略すると韓国語の記事になり、ほかの言語の記事は lang と韓国語の原文を指す pair を書くことで、言語メニューとhreflangのつながりを作れます。
---
title: 記事のタイトル
description: 検索結果に表示する一行の要約
pubDate: 2026-10-24
tags: [Astro, Markdown]
---タイトルと説明の長さは、contentスキーマがビルド時に検査します。必須の値が抜けていたり、許可していない言語が入っていたりすると、公開前にエラーで気づけます。記事ごとにルールを覚えて確認するのではなく、コンテンツを読み込む境目で確認する方式です。
1つのファイルが複数の結果になる流れ
ビルドのとき、Astroのcontent collectionが src/content/blog/*.md を読み込みます。draft: true の記事は一覧から外し、言語別の記事は公開日の新しい順に並べます。同じタグの記事が十分に増えると、関連記事も自動でつきます。
この流れの利点は、つなぎ忘れが起こりうる場所を減らせることです。記事一覧に別途登録したり、RSSファイルを手で直したりはしません。新しい記事がコレクションに入れば、各結果は同じ原本から作られます。
図も本文の中に置く
長い説明には、自作のD3図をコードブロックとして入れます。たとえば上のフロー図は、d3-flow ブロックの中にJSONを書いたものです。ビルドプラグインがこれをSVGに変換するので、外部の画像やキャプチャファイルは要りません。
図に入れる文も、本文と同じ基準で書きます。確認していない数値や運用情報は入れず、記事の流れを説明するのに必要な名前だけを置きます。JSONが間違っていれば、ビルドログの警告を見て直せます。
記事を追加するときの確認点
新しい記事を書くときは、次の4つだけを確認します。
- ファイル名が、小文字の英数字とハイフンでできた一意のslugになっているか。
- タイトル・説明・公開日がfrontmatterにあるか。
- 本文に
# H1を書いていないか。 - D3の図とMarkdownの記法が、ビルドで正常に処理されるか。
最後の確認は、次のコマンドで行います。
pnpm --filter site30cut build記事ファイルを1つ追加する方式は単純ですが、その単純さを保つには、自動のつなぎ込みを信頼して手作業の登録を増やさないことが大切です。記事の内容はMarkdownに、記事に共通する動作はサイトのコードに置けば、両者の責任が混ざりません。
よくある質問
後から管理画面を追加する必要はありますか。
記事を書いたりレビューしたりする人が増えたとき、または非開発者の編集が必要になったときに検討できます。今のようにgitで記事を管理する流れで足りるなら、管理画面にはリポジトリ・権限・エディタを追加で運用する負担が生じます。
記事を一時的に隠せますか。
frontmatterに draft: true と書くと、ビルド結果から除外されます。公開するときは、その値を消すか false に変えて、もう一度ビルドしてください。
記事ごとにページのコードを作る必要がありますか。
作りません。コレクションの記事データを、共通のブログページコンポーネントが読み込みます。記事ごとに変わるのは、Markdownファイルとfrontmatterだけです。