はじめに
このサイトは Astro で動く技術ブログである。自分向けに、次の2点を明文化しておきたい。
- このブログをどう活用するか — いつ書き、どのレイヤまで担うのか。
- 実際どう活用しているか — ログから記事になり、サイト上の Markdown で公開できるところまでの流れ。
題材は実装や調査が中心だ。主目的は理解を深めること。 読者への有益さはあるに越したことはないが、優先するのは自分の理解を言語化して確かめることである。
記事作成のフック（いつログを残すか）
記事への素材になりやすいログは、主に次の二つがある。書きどころは、ともに問題を解き終えた直後だ。
案件でつまずき、AI などで解決したとき
設定・ビルド・環境、その他開発で一度手が止まった局面では、調べ終えたあとほど「何を試し、なぜそう決めたか」が抜け落ちやすい。チャットへの投げ込みだけに頼らず、自分があとから辿れる形で 短いログにしておく。これが記事へつながる。
未経験の実装や未知の論点を、AI などと調査したとき
試したこと、効いた前提、外した仮説、参照した一次情報への手がかりをログに載せておく。焦点は「正解の共有」だけでなく 調査の地図を自分側に固定することにある。
ログの置き場所は厳密に一本化していない。気が向いたときに、このリポジトリの記事草稿として書き進めてもよい。
記事作成（ログから言語化へ）
ログは検索には向いても、そのままでは 腑に落ちた説明になっていないことが多い。そこでもう一度並べ替え、「なぜそう結論したか」「次に同じ状況なら何を確認するか」まで 読み物として組み立てる。この工程が、理解を深める主戦場になる。
チャットログの貼り付けだけにせず、見出しで再構成して再利用できる技術説明に寄せる。下書き段階でエディタや AI に手伝ってもらうのは、この方針と両立する。
非公開のナレッジベースとの役割
個人用に、公開していないナレッジベース（メモや整理用の文書も含む）も別に持っている。
そのうえでの役割の目安は次のとおり。
- 非公開側 … 素早く残す・あとから引くことを優先したメモや整理。
- このブログ … 自分や半年後の自分を想定した 再編集と言語化、公開してよいトピックのまとめ。
両方を書き分ける前提にしておくと、「どちらにも全部載せよう」と疲れにくい。
記事の仕様（Astro と Markdown）
コンテンツは Markdown（.md） で書き、このサイトではそのまま本番でも読める形に載せられる。
コレクションとスキーマ
記事は Content Collections の blog コレクションとして読み込む。src/content.config.ts で型付けしている（要約）。
- 必須:
title,description,pubDate - 任意:
updatedDate,heroImage,tags,draft
運用説明の README.md などは glob でコレクションから除外し、本文記事だけを対象にしている。
一覧・RSS の並び
並びは pubDate を Date にしたうえでの新しい順（降順）である。実装は src/utils/sortBlogPostsNewestFirst.ts に任せ、同一瞬間に収束したときだけ slug（ファイル由来の id）の辞書順で安定させる。
注意: pubDate が暦日だけ（例 '2026-05-08'）だと、環境によっては同日の複数記事が同じ瞬間に正規化され、ファイル名の b / c が必ずしも「新しい」とは限らない。同日に意図した順が必要なら、タイムゾーン付き ISO 8601 で時刻まで書く（例 '2026-05-08T20:00:00+09:00'）。画面に出す日付は暦日中心でもよく、時刻は読者向けに載せなくてよい。
draft
draft: true の記事は、本番ビルドでは一覧・RSS・個別 URL を生成しない（開発サーバーではプレビューできる）。公開切り替えはこのフラグで足りる。
ファイル名と URL
慣習として基本形は YYYY-MM-DD.md で、pubDate の暦日とファイル名の日付を揃える。同一暦日に複数本は 2026-05-08b.md のように末尾アルファベット。公開 URL は拡張子を除いたスラッグ（例 /blog/2026-05-08）。
サムネイル（heroImage）
画像は src/assets/blog/hero/（記事サムネ）や src/assets/blog/inline/（本文用）などに置き、frontmatter では記事からの相対パスで参照する。未用意なら heroImage 行をコメントアウトしておき、あとから有効化できる。
おわりに
外向けに書くことと理解を深めることは両立する。目的を自分側に固定しておくと、書かない日への罪悪感や発信至上主義に引っ張られにくい。一覧まわりのブレは pubDate と draft を軸に置いておけば機械的に減らせる。