Leon Journal
with-sanity-blog
技術

Next.jsブログのCMSにSanityを選んだ理由と実際の使用感

by Leon

このブログを作るとき、CMSの選定にそれなりに時間をかけた。フロントエンドをNext.jsで組む以上、APIで柔軟にデータを取れるヘッドレスCMSが前提だった。ただ、ヘッドレスCMSといっても選択肢は多い。どこを重視するかで答えは変わる。

ここでは、自分が候補に挙げたCMSとそれぞれを外した理由、そして最終的にSanityに落ち着いた判断軸を整理しておく。同じような構成でブログを始めようとしている人の参考になれば嬉しい。

候補から外れたCMS

最初に検討したのは、microCMSとContentfulの2つだ。

microCMSは国産で日本語ドキュメントが充実している点が魅力だった。スキーマもGUIで定義できて、初学者にとってはおそらく一番取っ付きやすい。ただ、セキュリティ周りで気になる点があり、サポートに質問したところ、返信の内容が要領を得なかった。プロダクトの印象は最終的にサポートで決まることが多い。技術的な評価よりも、こうした一次対応の質に違和感を覚えた段階で、長く付き合うのは難しいと判断した。

Contentfulはエンタープライズ向けにシフトしていて、無料プランの次の課金ティアがかなり高額になる。一度ハマると移行コストが重い類のサービスで、個人ブログでそのコスト構造に乗るのは現実的ではないと判断した。プロダクトとしての完成度は高いと思うが、ターゲットが明確に自分ではない。

Sanityを選んだ理由

残ったのがSanityだった。決め手はいくつかある。

まず、スキーマ設計の柔軟性。コードでスキーマを定義するため、必要なフィールドを自由に追加できる。このブログでは、SEO用タイトル・ディスクリプションをCMS側で持ちたかった。実際のスキーマはこうなっている。

defineField({
  name: "seoTitle",
  title: "SEOタイトル（32字以内）",
  type: "string",
  validation: (Rule) => Rule.max(32),
}),
defineField({
  name: "seoDescription",
  title: "SEO ディスクリプション（120字以内）",
  type: "text",
  rows: 2,
  validation: (Rule) => Rule.max(120),
}),

記事タイトルとは別に、検索結果に表示するSEO用のタイトル・ディスクリプションをCMS側で管理している。validationでバリデーションも定義できるため、文字数制限を超えたまま公開するミスが防げる。スキーマがコードでバージョン管理できるという点は、後から見返したときに「なぜこのフィールドを足したか」を追える意味でも効いてくる。

次に、TypeScriptおよびNext.jsとの相性。型定義を自分で管理できるので、フロントエンドとCMSのデータ構造を一致させやすい。GROQという独自のクエリ言語も、慣れるとREST的に書くより取り回しが良く、必要なフィールドだけをピンポイントで取得できる。App Routerのキャッシュ戦略との組み合わせも素直で、ISRやon-demand revalidationに乗せやすかった。

無料枠の内容も十分だった。ユーザー数20人、月間APIリクエスト10万回、CDNリクエスト50万回、ストレージ10GB、帯域幅10GB。個人ブログであれば、無料枠だけで運用できる水準だ。期間制限もない。試用ではなく、そのまま運用に入れる無料枠というのは精神衛生上ありがたい。

それから、CLIが発達していること。これは後述するが、自分の使い方にとって重要な点だった。

加えて、AI駆動開発との相性が良い。自分の今の執筆フローは、Claude Codeで記事の内容を壁打ちしながら整理して、まとまったらClaude CodeのSkills機能を使ってそのままSanityへ投稿する、という流れになっている。CLIベースで全工程が完結するSanityとの組み合わせで、記事投稿にかかる手間が大幅に短縮できている。GUIのCMSではこのフローは成立しない。

もう一点、Next.jsと組み合わせることでブログ自体のカスタマイズ性がかなり高い。UIのデザイン、記事一覧の動線、カテゴリページの構成——すべてコードで自由に作れる。WordPressのテーマやプラグインの制約に縛られることなく、メディアとして必要な動線を自分で設計できるのは、長期的に運用するうえで重要な点だと思っている。

実際に使ってみて

使い始めてから不便を感じたことは、今のところない。

特に良かったのは、画像投稿を除くほぼすべての操作をCLI経由で行えることだ。記事の投稿、本文の修正、メタデータの設定——これらをターミナルから完結できる。データセットの複製、スキーマのデプロイ、ドキュメントの一括取得や書き換えまで、ほとんどがコマンドで叩ける。

自分はClaude Codeを執筆に活用している。記事の構成を相談しながら書いて、メタデータを整えて、そのままSanityに挿入する。このフローがCLIベースで完結するのは、AI駆動の開発・執筆スタイルとの相性が良い。Studio（管理画面）を開かなくても記事が書けるというのは、思っていた以上に快適だった。GUIに切り替える心理的なコストがゼロというのは、書くテンポを保つ上で地味に大きい。

加えて、Portable Textという独自のリッチテキスト形式は、HTMLでもMarkdownでもない構造化データとして本文を持てる。最初はとっつきにくく感じたが、コードブロックの言語指定や独自コンポーネントの埋め込みなど、後から拡張する余地があるのは結果的に正解だった。

まとめ

CMSの選定は、何を重視するかで答えが変わる。自分の場合は、柔軟なスキーマ設計、TypeScriptとの親和性、無料枠の充実、そしてCLI経由でのAI駆動開発との相性、この4点でSanityが最も条件に合致した。

逆に言えば、日本語情報を重視するならmicroCMSの方が情報は多いし、GUIで完結したい人にとってもそちらの方が学習コストは低い。規模が大きくなってきたときにSanityのコスト構造がどう変わるかは、まだ見えていない部分もある。ただ現時点では、選んで正解だったと思っている。

CMSは数年単位で付き合う基盤だ。短期的な手軽さよりも、自分の開発スタイルと噛み合うかで選ぶのが、結局のところ近道なのかもしれない。