ブログを追加しました
開発の現場で取り組んだことを、備忘録として少しずつ残していく場所を用意しました。肩肘張らず、自分の振り返りも兼ねて、ゆっくり綴っていけたらと思います。
構成の方針
ホームページ https://nsys.dev は表示速度を優先しており、PageSpeed Insights で各指標 100 点を維持しています。ブログを足すにあたっても、その方針は崩さないことを前提に設計しました。
- ページは Markdown から静的 HTML を生成
- CSS はビルド時に HTML へインライン化し、外部リクエストをゼロに
- クライアント側の JavaScript は使わない（コードのハイライトもビルド時に処理）
既存のビルド基盤（Node + Docker）にそのまま乗せる形にしたため、新しいランタイムやデータベースは増えていません。
よくあるブログ構成にしなかった理由
ブログというと、CMS とデータベースを用意し、管理画面から書いて公開する構成が一般的です。多人数での運用や、コメント・検索といった動的な機能が得意で、用途が合えばとても便利な仕組みだと思います。
要するに——CMS は「多人数で動的に運用する」のが得意。今回は「速い・簡素・書いたものが長く残る」を優先したので、軽い静的な構成を選びました。優劣ではなく、向き不向きの話です。
一般的な構成と今回の構成は、得意なところがこう分かれます。
| 一般的な CMS＋DB | 今回（Markdown＋静的化） | |
|---|---|---|
| 得意なこと | 管理画面・多人数編集・コメントや検索 | 表示速度・簡素さ・記事の長期保存 |
| 配信 | 閲覧のたびに生成（動的） | ビルド時に生成（静的） |
| 向く場面 | 編集者が多い・動的機能が要る | ソロで書く・速度最優先の備忘録 |
- 得たもの：表示速度（各指標 100 点）／基盤の簡素さ／仕組みを変えても記事は無傷
- 手放したもの：管理画面の手軽さ／標準で付く動的機能（コメント・検索）
「記事は無傷」は実際にそうで、ホームページでも公開の仕組みを途中で見直しましたが、記事そのものには手を入れずに済みました。CMS がよくないということではなく、この小さな備忘録には、こちらの方が素直に収まった、というだけの話です。
技術構成
ブログを実現するために使っている主な技術は次のとおりです。特別なものは使わず、既存サイトの基盤にそのまま乗せられる構成を選んでいます。
| 役割 | 採用技術 | メモ |
|---|---|---|
| 配信サーバー | Go（標準ライブラリ net/http） |
静的ファイル配信。gzip・キャッシュ対応。フレームワークなし |
| ビルド | Node.js | 記事を静的 HTML に変換する一連の処理を担当 |
| Markdown 変換 | markdown-it | 記事本文の Markdown を HTML 化 |
| メタ情報の解析 | gray-matter | 記事先頭の frontmatter を読み取る |
| コードのハイライト | highlight.js | ビルド時に着色（クライアント JS 不要） |
| 図の描画 | Mermaid CLI | 図をビルド時に SVG 化（クライアント JS 不要） |
| HTML/CSS/JS の最小化 | html-minifier-terser / Lightning CSS / esbuild | 配信容量を抑えて表示を速く |
| コンテナ化 | Docker（マルチステージ） | 実行イメージは scratch で最小構成 |
| CI/CD | GitHub Actions | main への push で自動ビルド・デプロイ |
コードの着色や図の描画はいずれも「ビルド時」に済ませているのがポイントです。閲覧時に動く JavaScript を増やさずに済むため、表示速度を落とさずに表現の幅を広げられます。
記事の書き方
記事は src/blog/posts/ に Markdown を置くだけです。先頭に、一覧や OGP に使う最低限のメタ情報（frontmatter）を書きます。
---
title: 記事のタイトル
date: 2026-06-09
description: 一覧やOGPに使われる短い説明
tags: [タグ1, タグ2]
---
- 必須：
title（タイトル）、date（公開日。一覧はこの降順で並ぶ） - 任意：
description（一覧・OGP・検索結果に表示）、tags（タグ）
あとは本文を普通の Markdown で書くだけです。コードブロックはビルド時に着色されます。
func handleHealthCheck(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Write([]byte("OK"))
}
公開までの流れ
記事を書いてから公開されるまでは、おおむね次のような流れです。Markdown を置いてプッシュすれば、あとは自動で進みます。記事の更新ではアプリ本体を作り直さず、コンテンツだけをビルドして配信する形にしているので、公開は軽く速く済みます。
ちなみに、この図自体も Mermaid で書いたものをビルド時に SVG へ変換しています。画像として埋め込むのでクライアント側の JavaScript は増えず、表示速度はそのままです。
これから
技術的な詰まりどころや、その解決までの過程を中心に書いていければと思います。実務で触れた範囲のささやかな覚え書きですが、同じところでつまずいた方の手がかりになれば嬉しいです。