はじめに
Next.js 16 × microCMS × Vercelで、個人の技術ブログ 「KAIZEN 技術ブログ」 を作りました。その感想を書いていきます。
なぜ作ったのか
-
プラットフォーム依存ではない発信する場所がほしかった
- プラットフォーム依存ではなく、自分のドメインでコンテンツを育てるメディアを1から設計・構築してみたかったため作成に至りました。
-
Next.jsのレンダリングとキャッシュのアウトプット
- SSR / SSG / ISRやキャッシュの技術、より良いディレクトリ構成の検証、各設計のアウトプットも兼ねて作成しております。
記事を書くだけならQiitaやZennで十分です。それでも自作したのは、サイトそのものも技術や設計を試す場にしたかった からです。機能やデザインも今後も育てていこうと思っています！
作成したアプリの概要
技術ブログ「KAIZEN」は、「学びを記録し、改善を積み重ねる。」をコンセプトに、技術的な課題への取り組みや、Webアプリケーション開発に関する技術情報を発信していく予定です。
＝＝＝＝＝＝＝＝＝＝＝＝
作成したブログはこちら
ソースコードはこちら
＝＝＝＝＝＝＝＝＝＝＝＝
主なページ
◾️トップページ（PC版）
- 記事一覧を表示し、「検索」や「カテゴリー」、「年月」による絞り込みなどから目的の記事を探せるようにしています。
◾️記事詳細ページ（PC版）
- 記事本文に加え、「カテゴリー」や「公開日」などを表示し、技術情報を読みやすい構成にしています。
- 「X」「FaceBook」「はてなブログ」での記事シェア機能もついています。
◾️画像レイアウト（SP版）
主な機能
- 記事一覧・記事詳細
- キーワード検索
- カテゴリーによる絞り込み
- ページネーション
- 年月別アーカイブ
- PWA対応（ホーム画面への追加）
- 記事シェア機能
- プロフィール・ブログ紹介ページ
- プライバシーポリシー・免責事項
ほかに、レスポンシブ対応、SEO（メタデータ・OGP・サイトマップ・robots.txt）、404ページにも対応しています。
技術スタック
| 分類 | 技術 |
|---|---|
| フレームワーク | Next.js 16（App Router）/ React 19 / TypeScript |
| スタイリング | Tailwind CSS v4 / daisyUI v5 / @tailwindcss/typography |
| CMS | microCMS（microcms-js-sdk） |
| セキュリティ | sanitize-html / server-only |
| テスト・CI | Vitest / Testing Library / GitHub Actions |
| ホスティング | Vercel / Cloudflare（ドメイン・DNS） |
mainにpushするとVercelに自動でデプロイされ、同時にGitHub ActionsでLint・型チェック・テストが走ります。記事の公開ではサイトをビルドし直さず、microCMSのWebhookでキャッシュだけを更新します。
ディレクトリ構成
Next.js App Router アーキテクチャの設計思想 を参考に、ブログの規模に合う部分だけを取り入れました。
frontend/src/
├── app/ … ルーティングとページの組み立てだけ
├── features/ … 機能ごとのUIとロジック（記事一覧・記事詳細・サイドバー）
├── external/ … microCMSとの接続点
└── shared/ … 共通の部品・関数
| ディレクトリ | 役割 |
|---|---|
app/ |
URLとページの対応だけを持つ。データの加工や細かいUIは書かない |
features/ |
機能ごとにUI・ロジック・型をまとめる |
external/ |
microCMSの呼び出し、キャッシュ設定、Webhookの署名検証 |
shared/ |
複数の機能で使う部品や関数（日付の整形、サニタイズなど） |
microCMSへの依存は external/ に閉じ込めました。CMSを変えることになっても、この層だけ直せば済みます。
各設計について
実装を始める前に、設計ドキュメントを書きました。詳しい内容は各リンク先にまとめています。
| 設計 | 内容 |
|---|---|
| 要件定義 | 作る機能・作らない機能 |
| ユースケース | 読者と運営者が何をするか |
| ユビキタス言語 | 「記事」「カテゴリ」など用語の定義 |
| UI設計 | ページごとのレイアウトと振る舞い |
| ドメイン設計 | アプリ内で扱うデータの形と型 |
| コンテンツモデル | microCMSのAPIとフィールドの構成 |
| API設計 | microCMSからの取得方法・キャッシュ・Webhook |
作りながら設計が変わったときも、先に設計ドキュメントを直してからコードを直す 順番を守りました。
Next.jsのレンダリングとキャッシュについて
自分の中の整理も兼ねて、Next.jsのレンダリングとキャッシュについてを少し説明します。
3つのレンダリング方式
違いは HTMLをいつ作るか です。
| 方式 | HTMLを作るタイミング |
|---|---|
| SSR | アクセスのたびに作る |
| SSG | ビルド時に1回だけ作る |
| ISR | ビルド時に作り、一定時間ごとに作り直す（SSG＋自動更新） |
このブログでの使い分け
| ページ | 方式 | 理由 |
|---|---|---|
| トップ（記事一覧） | SSR | 検索条件やページ番号をURLのクエリで受け取るため |
| 記事詳細 | SSR | 記事IDの一覧をビルド時に渡していないため |
| 固定ページ | SSG＋ISR | 内容がほとんど変わらないため |
方式は自分で指定していません。searchParams を使うとSSR、使わなければSSG、というように Next.jsがコードから自動で判定 します。結果は npm run build の出力で確認できます。
データのキャッシュとWebhook
SSRのページでも、アクセスのたびにmicroCMSへ問い合わせているわけではありません。fetchの結果は、HTMLとは別に1時間キャッシュしています。
// external/microcms/endpoints.ts
next: {
revalidate: 60 * 60, // 1時間キャッシュする
tags: [endpoint], // Webhookで更新対象を指定するための名札
}
記事を公開すると、microCMSのWebhookから revalidateTag が呼ばれ、該当するキャッシュだけが更新されます。そのため 記事はすぐに反映され、サイトのビルドし直しも不要 です。
大変だったこと・工夫したこと
責務を意識したディレクトリ設計
機能が増えた際にも変更の影響範囲を把握しやすいよう、ページ、機能、外部サービス連携、共通処理の役割を整理しました。個人開発でも、今後の保守や機能追加を見据えて構成を考えることを意識して開発しました!
microCMSとの連携
microCMSから取得したコンテンツを画面に表示するにあたり、データ取得と画面表示の責務を意識して実装しました!
また、コンテンツの更新が公開サイトにどのように反映されるかについても確認し、キャッシュの仕組みや再検証の必要性について理解を深めることができました。
開発サーバーでは、キャッシュの動きを確認できない
next dev では、すべてのページがアクセスのたびに作られます。キャッシュも本番とは違う動きをするため、「ISRになっているか」「Webhookで更新されるか」は開発サーバーでは確かめられません。レンダリングやキャッシュの確認は、npm run build && npm run start で本番と同じ状態にして行う 必要があります。いつもながら、ここが若干面倒でした！
公開後の運用を考慮した実装
ローカル環境で動作することだけでなく、Vercelへのデプロイや独自ドメインの設定まで行い、実際にアクセスできるサービスとして公開しました。SEOや記事の探しやすさなども考慮し、継続的に記事を発信できるブログができたかなと思います！
おわりに
Next.js 16 × microCMS × Vercelで技術ブログを作り、SSR / SSG / ISRとキャッシュを使い分けた話でした。
今後は、記事が増えたときに備えたページ取得の見直しや、E2Eテストの導入に取り組む予定です。何より、このブログで学んだことを発信し続けていきます。
よければブログものぞいてみてください。
最後まで読んでいただき、ありがとうございました！！
参考
- Next.js公式ドキュメント
- microcms公式ドキュメント
- tailwindcss公式ドキュメント
- その他参考記事
JISOUのメンバー募集中！
プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページをのぞいてみてくださ！
▼▼▼