Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

プロローグ — SSG は死んでいない、定義し直された
1 章 · 比較軸 — 何を見て選ぶか
2 章 · Hugo — Go の速度、11 年の安定性
3 章 · Eleventy(11ty) — JS 陣営のミニマリスト
4 章 · Astro — コンテンツファーストの新標準
5 章 · MkDocs(Material) — Python ドキュメントの事実上の標準
6 章 · Docusaurus — Meta の React+MDX ドキュメントフレームワーク
7 章 · Mintlify — SaaS ドキュメントの「デザインはこちらで」モデル
8 章 · Starlight — Astro 陣営の急伸ドキュメント強者
9 章 · Nextra — Next.js 陣営のドキュメントテーマ
10 章 · VitePress — Vue 陣営の MkDocs
11 章 · Gatsby · Jekyll · Zola — 残存組
12 章 · カテゴリマトリクス — 一目で見る
13 章 · シナリオマトリクス — どのツールを選ぶか
14 章 · AI 時代のドキュメント — 新しい変数
15 章 · 移行コスト — 道具を替えるということ
16 章 · エピローグ — 意思決定チェックリストとアンチパターン
参考 / References

プロローグ — SSG は死んでいない、定義し直された

2026 年春、誰かが「SSG は終わった、みんな Next.js Server Components に移った」とツイートした。そのツイートは 1 万人に届き、9 千人が同意しなかった。実際の風景は逆である。静的サイトジェネレータ — Static Site Generator、略して SSG — はここ 5 年で死ぬどころか、二つに分かれて強くなった。

一方は コンテンツサイト だ。会社ブログ、マーケティングサイト、個人ポートフォリオ、ニュースレターのアーカイブ。Hugo は Go の速度で 1,000 ページを数秒でビルドし、Eleventy 3 は JavaScript 陣営のミニマリズムを再定義し、Astro は「コンテンツファースト」というカテゴリを作った。こちら側の優先事項は SEO、ページ速度、RSS、多言語、まともな Markdown ワークフロー。

もう一方は ドキュメントサイト だ。OSS ライブラリのドキュメント、SaaS の API リファレンス、社内 Wiki、チェンジログ。MkDocs Material は Python 陣営の事実上の標準になり、Docusaurus は Meta の React + MDX 組み合わせで数万の OSS プロジェクトのドキュメントを支え、Mintlify は「お金を払うからデザインは任せろ」と SaaS の API ドキュメント市場を獲り、Astro の Starlight は新しい強者として浮上した。Nextra は Next.js でドキュメントを書きたい人の選択、VitePress は Vue 陣営の答え。

そして死んだか死にかけている陣営もある。Gatsby — かつて React 陣営の SSG だったが、Netlify に買収された後ほぼメンテナンスモード。2026 年に新規プロジェクトで Gatsby を選ぶ人はほとんどいない。Jekyll — Ruby の元祖 SSG、GitHub Pages のデフォルト。まだ動いてはいるが勢いは完全に失った。Hexo — Node 陣営のかつての強者、現在は韓国・中国の一部に残存。Zola — Rust 製の高速 SSG、勢いはあるがエコシステムは薄い。

この記事は 11 個の SSG を同じ軸で正面比較する。比較の後、四つのシナリオ — 会社ブログ、個人ブログ / ポートフォリオ、OSS ライブラリのドキュメント、SaaS の API ドキュメント — でどの道具を選ぶべきかを問う。さらに 2026 年の新変数 — AI 検索・翻訳・自動コンテンツ — が選択をどう変えるかも見る。

同じカテゴリの道具でも、コンテンツモデル と 運用モデル が違うと結果は完全に変わる。1 年運用した後に道具を替えるコストは、初期導入コストの 10 倍かかる。

価格や機能の数字はすぐに動く。本稿の数字はすべて 2026 年 5 月時点 で、構造的な違いに焦点を置く。半年後に数字が変わっても、意思決定フレームは有効でなくてはならない。

1 章 · 比較軸 — 何を見て選ぶか

11 個の道具を 9 軸に分解する。軸そのものが意思決定フレームだ。

軸 1 · カテゴリ適合性 コンテンツサイトに強いか、ドキュメントサイトに強いか、両方か。Hugo と Eleventy はコンテンツ寄り、MkDocs と Docusaurus と Mintlify はドキュメント寄り、Astro は両方、Next.js 自体はフルスタック。カテゴリを無視すると半年後に後悔する。

軸 2 · ビルド速度 ページ数が増えたときのビルド時間カーブ。Hugo は圧倒的に速い(Go コンパイル + 並列処理)。Zola が次点(Rust)。それ以外の JavaScript 系はだいたい同じ帯で競う。1,000 ページを超えると差は大きく開く。

軸 3 · コンテンツモデル Markdown のみか、MDX(Markdown 中の JSX)か、AsciiDoc や reStructuredText も受けるか。自由な表現が必要な場合は決定的。MDX は本文に React コンポーネントを埋め込めるのでインタラクティブな部品に強いが、コンテンツがコードに結合して移行が難しくなる。

軸 4 · テーマとデザインの自由度 自由形式か、テーマありか。MkDocs Material、Mintlify、Starlight はデザインがほぼ固定。Hugo、Eleventy、Astro は白紙から。自由度と立ち上げ速度はトレードオフ。

軸 5 · 検索 内蔵か、外部連携か、AI 検索か。MkDocs Material は lunr.js ベースのクライアント検索を内蔵。Docusaurus は Algolia DocSearch を推奨。Mintlify は AI 検索を標準提供。Inkeep / Kapa.ai のような AI 検索 SaaS との連携も急速に標準化中。

軸 6 · 多言語(i18n) 多言語ルーティングと翻訳ワークフローの対応。Docusaurus、Astro、Hugo はファーストクラス。Eleventy はプラグイン。MkDocs は i18n プラグインが必要。Jekyll は難しい。多言語が必要なら候補は半減する。

軸 7 · デプロイとホスティング どこにホストできるか。静的出力を吐くツールはすべて GitHub Pages、Cloudflare Pages、Vercel、Netlify に置ける。Mintlify は SaaS 専用でセルフホスト不可。セルフホスト対 SaaS はコスト・統制・スピードのトレードオフ。

軸 8 · 価格 OSS、一部有料、完全 SaaS。Mintlify は有料(Starter 無料、Pro 月額約 150 ドル、Growth 月額約 550 ドル、2026 年時点、変動あり)。MkDocs Material は OSS だが Insiders スポンサー枠あり。残りは概ね OSS + 自前ホスティング。

軸 9 · AI 連携 / 将来適合性 コンテンツモデルが LLM 親和的か、AI 検索を付けやすいか、llms.txt のような新標準を支持しているか。Mintlify が最も先行、Docusaurus と Starlight も急追。2026 年のドキュメントサイトで最大のトラフィック源の一つは検索エンジンではなく LLM だ。

この 9 軸を頭に入れて、各ツールを同じフォーマットで見ていく。

2 章 · Hugo — Go の速度、11 年の安定性

カテゴリと強み Go 製の SSG。初回リリース 2013 年、2026 年は v0.140+ 系。一語で言うと速い。1 万ページを 1 分以内でビルドする。JS 陣営が届かない領域だ。さらに外部依存ゼロの単一バイナリなので CI のキャッシュも再現も楽。

コンテンツモデル Markdown + YAML / TOML フロントマター。ディレクトリベースのルーティング。content/posts/ 配下に Markdown を置けばツリーに自動で入る。多言語は content.ko/ content.en/ のような別ディレクトリかファイル名サフィックス。Shortcode で本文にウィジェットを埋められるが、MDX ほどは自由ではない。

テーマ 公式テーマが豊富。PaperMod、Hello Friend、Stack、Doks など。自作も簡単 — Go テンプレートは初見では不慣れだが一貫性は高い。

検索内蔵なし。Fuse.js、Lunr.js、Pagefind、Algolia を後付け。2026 年は Pagefind が人気 — ビルド時に静的インデックスを生成しクライアントで検索。

弱点 Go テンプレート構文が JS 開発者には違和感。JSX や MDX はないので本文に React コンポーネントは埋められない。ビルド速度の真価が出るのは 1 万ページ以上で、100〜500 ページの帯では Astro と体感差は小さい。

典型ユーザー 大規模会社ブログ、大型ニュースサイト、ニュースレターアーカイブ。1Password Docs、Smashing Magazine の一部、そして膨大な数の個人ブログが Hugo。

3 章 · Eleventy(11ty) — JS 陣営のミニマリスト

カテゴリと強み 2018 年登場の JS 製 SSG。2024 年に 3.0 が ESM、Edge 関数、より速いビルドとともに正式リリース。哲学は 「フレームワークなし」 — サイトはあなたのもの、Eleventy は Markdown を HTML に変換するだけの道具。JAMstack 純粋主義者の愛。

コンテンツモデル Markdown、Liquid、Nunjucks、Handlebars、EJS、JavaScript、TypeScript、HTML — ほぼ全テンプレート言語を受け付ける。同じサイト内でページごとに違うエンジンを使ってもよい。その自由度がアイデンティティ。

テーマ 公式テーマはほぼなし。スターターが数種類あり、ほとんどのユーザーは自作。eleventy-base-blog、eleventy-excellent などが人気。

検索内蔵なし。Pagefind、Lunr.js、Algolia を後付け。Eleventy 公式ドキュメント自体も Pagefind を使用。

弱点 React / JSX / MDX 系のインタラクティブコンポーネントワークフローがない。Web Components や islands パターンを自作する。「Markdown だけでよい」サイトには最適だが、本文にチャートウィジェットを置きたい用途には道具が足りない。

典型ユーザー 個人ブログ、小規模会社サイト、OSS のランディング。Google Chrome Developer の一部、web.dev の一部、独立系 JS 開発者のブログ多数。

4 章 · Astro — コンテンツファーストの新標準

別記事で深掘りしているため、ここでは比較用の要約のみ。

カテゴリと強み 2021 年登場、2024 年に 5.0、2025 年後半に 6.x 系。コンテンツファースト、islands architecture(部分ハイドレーション)、MDX ファーストクラス、マルチフレームワーク(React / Vue / Svelte / Solid を同一サイトで混在) が核。デフォルトでビルド出力は JavaScript 0 バイト、インタラクションが必要なコンポーネントのみクライアントへ。

典型ユーザー 2026 年で最も人気のある SSG の一つ。会社ブログ、OSS のランディング、マーケティングサイト、そして Starlight テーマ(8 章)を通じてドキュメントサイトまで侵食中。

弱点と詳細は別記事を参照。

5 章 · MkDocs(Material) — Python ドキュメントの事実上の標準

カテゴリと強み Python 製の静的サイトジェネレータ。本体は非常に単純な道具だが、Material for MkDocs テーマが事実上の標準となり「ドキュメントサイト = Material for MkDocs」という認識が定着。清潔なデザイン、良い検索、豊富な拡張 — そして何より 書きやすい。YAML ファイル 1 つにサイト構造と設定が収まる。

コンテンツモデル Markdown + フロントマター。ディレクトリ構造がそのままサイト構造。mkdocs.yml に nav を明示するか awesome-pages プラグインで自動整列。

テーマ Material が事実上のデフォルト。Insiders スポンサー枠でより多くの機能を提供するが、コア機能はやがて無料版にも降りてくる(時差リリース)。

検索 lunr.js ベースのクライアント検索を内蔵。多言語検索も対応。検索品質は平均以上、追加設定なしで動く。

弱点 React / JSX / MDX なし。本文にインタラクティブな部品を置くには素の JS か iframe。コンテンツモデルは Markdown + pymdown-extensions の世界に閉じる。

典型ユーザー Python OSS ライブラリのドキュメントの 6〜7 割。FastAPI、Pydantic、Pelican、Material 自身など。インフラ OSS の OpenStack、Cilium、k3s なども MkDocs Material。

6 章 · Docusaurus — Meta の React+MDX ドキュメントフレームワーク

カテゴリと強み 2017 年に Meta(当時 Facebook)が作った React ベースのドキュメント SSG。2022 年に v2、2024〜2025 年で v3 系が安定。React + MDX + i18n + バージョン管理 がファーストクラス。OSS ライブラリが韓国語・日本語・中国語のドキュメントを並走し、v1 / v2 / v3 を並列ホストするのに最も検証された道具。

コンテンツモデル MDX ファーストクラス。本文に React コンポーネントを埋める。コード例の隣にインタラクティブデモが置ける。Sidebars は sidebars.js に JS で明示 — 動的サイドバー生成も可能。

テーマ 公式 Classic テーマがデフォルト。デザインは平易だが安定。カスタマイズは swizzling(テーマコンポーネントを自分のプロジェクトにコピーして編集)モデル。

検索 Algolia DocSearch が公式推奨(OSS には無料提供)。他に lunr、typesense、Mendable(AI)も。2026 年は Kapa.ai、Inkeep のような AI 検索が急上昇。

弱点 1,000 ページを超えるとビルドが遅くなり、分単位に伸びる — React 系 SSG 共通の弱点。多言語 + バージョン管理 + 検索を全部入れると設定の複雑度が一気に上がる。

典型ユーザー React Native、Jest、Babel、Redux、Yarn、Storybook、Prisma — Meta と主要 OSS 陣営のドキュメント標準。SaaS の API ドキュメントにもよく使われる(Supabase は以前 Docusaurus、現在はカスタムビルド)。

7 章 · Mintlify — SaaS ドキュメントの「デザインはこちらで」モデル

カテゴリと強み 2022 年登場の 有料マネージドドキュメントプラットフォーム。OSS の SSG を自前運用するコストはデザイナー一人分の人件費に匹敵する、という洞察から始まった。デザインは最初から完成、AI 検索が標準内蔵、OpenAPI スペックを投げると API リファレンスが自動生成される。2026 年では SaaS の API ドキュメントの事実上の標準の一つ。

コンテンツモデル MDX。独自コンポーネントライブラリ(Accordion、Card、Tabs、Steps など)が豊富。mint.json(または docs.json)1 つにサイト構造、テーマ、SEO メタが集まる。

テーマ ほぼ固定。色、ロゴ、フォントを変える程度。それは弱点というより長所 — デザイナー不在でも即座に格好良く見える。

検索 / AI 検索 + AI チャットボット(検索結果から LLM が回答を合成)が標準。llms.txt の自動生成、OpenAPI 自動レンダリング、API プレイグラウンドを内蔵。AI 時代に最も積極的な道具。

弱点と価格 SaaS — セルフホスト不可。価格はすぐ上がる。2026 年時点で Starter は無料だがページ数とメンバー数に制限、Pro が月額約 150 ドルから、Growth が月額約 550 ドルから(数字は変動)。大企業の大型サイトでは年 1 万ドルを超えやすい。

典型ユーザー Anthropic Docs、Mintlify 自身のドキュメント、Cursor、Linear API、そして多数の YC スタートアップの API ドキュメント。AI 時代の「ドキュメントを速く、格好良く、AI 検索付きで」パッケージを買いたい会社が選ぶ。

8 章 · Starlight — Astro 陣営の急伸ドキュメント強者

カテゴリと強み 2023 年に Astro チームが出した 公式ドキュメントテーマ。Astro 上で動くフルスタック SSG だが、ユーザー視点では「ドキュメントサイトを始めるための一行コマンド」。2024〜2025 年で急速に成熟し、2026 年現在は Docusaurus と MkDocs Material の真剣な代替。

コンテンツモデル MDX + Astro コンポーネント。Astro のコンテンツコレクションで型安全なフロントマター。サイドバー、検索、i18n、バージョン管理のほぼ全機能を標準装備。

テーマ デザインは最初から清潔。ライト / ダーク、サイドバー、検索 UI まで設定済みで「5 分スタート」が現実になる。

検索 Pagefind を標準内蔵(静的インデックス + クライアント検索)。Algolia、Inkeep、Kapa.ai 連携も簡単。AI 検索連携ガイドが公式ドキュメントにある。

弱点エコシステムはまだ Docusaurus ほど厚くない。プラグイン数も少なく、大規模 OSS プロジェクトでの採用例は Docusaurus より少ない。ただしその差は毎四半期縮まっている。

典型ユーザー Cloudflare Wrangler の一部、Bun の一部、そして数十の新興 OSS — 2026 年に Starlight で始まる新規 OSS が急増中。

9 章 · Nextra — Next.js 陣営のドキュメントテーマ

カテゴリと強み Vercel が作った Next.js ベースのドキュメントテーマ。すでに Next.js でサイトを運用している会社がドキュメントも同じスタックで動かしたい場合の選択。2024 年に v3、2025 年に v4。Server Components 上で動く SSG / SSR ハイブリッド。

コンテンツモデル MDX + Next.js App Router。サイドバーはディレクトリごとの _meta.json で定義。検索は FlexSearch か Algolia。

テーマ Docs テーマと Blog テーマ。デザインは平易だが Next.js の全機能を使えるのが利点。

弱点 Next.js 依存が重い。単純なドキュメントのために Next.js のビルドチェーン全体を引き込むのは過剰なことが多い。ビルド速度も軽量 SSG より遅い。

典型ユーザー SWR、Turborepo、その他 Vercel 寄りの OSS。すでに Next.js を採用している会社の社内ドキュメント。

10 章 · VitePress — Vue 陣営の MkDocs

カテゴリと強み Vue コアチームによる Vite ベースのドキュメント SSG。MkDocs Material を JS 陣営で作り直したような 道具 — 清潔なデフォルトテーマ、速いビルド、本文に Vue コンポーネントを埋めるための Markdown 拡張。2024 年に v1、2025 年に v2 系。

コンテンツモデル Markdown + Vue コンポーネント(MDX ではないが類似機能)。サイドバーは設定ファイルから。Vite 上でビルドが速い。

テーマ Vue 公式ドキュメント風がデフォルト。デザインは固く一貫性がある。カスタマイズは Vue コンポーネントのオーバーライドモデル。

弱点 Vue 圏外で勢いは弱い。本文に React コンポーネントは埋められない。i18n は 1.x 後半で入ったが Docusaurus ほど成熟していない。

典型ユーザー Vue.js、Vite、Pinia、Nuxt の一部、Vitest。Vue OSS の標準。Vue を使わない会社が VitePress に行くことはほぼない。

11 章 · Gatsby · Jekyll · Zola — 残存組

Gatsby — 実質的に終了 2015 年、React SSG の出発点だった。GraphQL データレイヤ、プラグインエコシステム、上手いマーケティング。2020〜2022 年は React SSG の標準。だが Next.js が SSG / SSR を取り込み、Astro がコンテンツサイトを取り、Netlify が Gatsby を買収して以降は会社がほぼメンテナンスモードへ。2024 年以後の新規採用は急減。既存サイトは維持されるが、2026 年に新規で Gatsby を選ぶ決定はほぼない。

Jekyll — 生きてはいるが 2008 年に GitHub 共同創業者 Tom Preston-Werner が作った Ruby 製 SSG。GitHub Pages のデフォルト SSG として個人ブログ・ドキュメント多数が Jekyll の上にある。安定はしているが勢いは失った。Ruby 依存が重く、MDX / JSX / Vue がなく、ビルドも遅い。既存 Jekyll はそのままでよいが、新規には誰も勧めない。

Zola — Rust の新星 Rust 製 SSG。単一バイナリ、非常に速いビルド、Tera テンプレート。Hugo に最も近い位置。短所はエコシステムが薄いこと — テーマ数、プラグイン数、コミュニティ規模が Hugo と比べ物にならない。勢いはあり、「Hugo はもう大きすぎる、シンプルが欲しい」層に人気。

Hexo — 韓・中陣営の残存 Node 陣営の旧強者。中国・韓国の一部で残存するが、グローバルな勢いはほぼない。

12 章 · カテゴリマトリクス — 一目で見る

ツール	カテゴリ	言語	コンテンツモデル	ビルド速度	デザイン自由度	検索	i18n	価格
Hugo	コンテンツ	Go	Markdown + Shortcode	非常に速い	高	外部	ファーストクラス	OSS
Eleventy 3	コンテンツ	JS	Markdown + 多テンプレート	速い	非常に高	外部	プラグイン	OSS
Astro	両方	JS/TS	MDX + Astro	速い	高	外部 / Pagefind	ファーストクラス	OSS
MkDocs Material	ドキュメント	Python	Markdown	普通	低(固定テーマ)	内蔵	プラグイン	OSS + Insiders
Docusaurus	ドキュメント	JS/TS	MDX	遅め	普通	Algolia	ファーストクラス	OSS
Mintlify	ドキュメント	(マネージド)	MDX	即時	低(固定テーマ)	AI 内蔵	対応	有料 SaaS
Starlight	ドキュメント	JS/TS	MDX + Astro	速い	普通	Pagefind 内蔵	ファーストクラス	OSS
Nextra	ドキュメント	JS/TS	MDX	普通	普通	FlexSearch / Algolia	ファーストクラス	OSS
VitePress	ドキュメント	JS/TS	Markdown + Vue	速い	普通	内蔵	部分	OSS
Gatsby	両方	JS	MDX(別)	遅い	高	外部	ファーストクラス	OSS(衰退)
Jekyll	両方	Ruby	Markdown + Liquid	遅い	高	外部	困難	OSS
Zola	コンテンツ	Rust	Markdown + Tera	非常に速い	高	外部	ファーストクラス	OSS

これは大きな絵だ。ツールごとに強いシナリオが違うので、次章のシナリオマトリクスと併読すること。

13 章 · シナリオマトリクス — どのツールを選ぶか

四つのシナリオを定義し、各シナリオでの 1 位・2 位を見る。

シナリオ A · 個人ブログ / ポートフォリオ 要件: Markdown 執筆、速いビルド、GitHub Pages や Cloudflare Pages に無料デプロイ、RSS、整った SEO、ダークモード。

1 位: Astro — 豊富なスターターテンプレート、清潔なコンテンツコレクション、軽量な出力。
2 位: Hugo — 記事が増えてくるとビルド速度の差が見える。
3 位: Eleventy — JS 陣営のミニマリストなら。

シナリオ B · 会社ブログ / マーケティングサイト 要件: デザインの自由度、インタラクティブな部品、多言語、CMS 連携(Notion / Sanity / Contentful)、Vercel / Cloudflare へのデプロイ。

1 位: Astro — MDX、マルチフレームワーク、i18n、CMS 連携すべて強い。
2 位: Next.js + コンテンツソリューション — フルスタックが必要なら。
3 位: Hugo — デザインの自由度が高く多言語も実績豊富。

シナリオ C · OSS ライブラリのドキュメント 要件: Markdown 執筆のしやすさ、i18n、バージョン管理(v1 / v2 / v3 並走)、検索、OSS フレンドリーなライセンス、コミュニティ貢献のしやすさ。

Python 陣営: MkDocs Material — 事実上の標準。他を選ぶと後悔しやすい。
React / JS 陣営: Docusaurus — Meta と OSS コミュニティの検証。
新規プロジェクト: Starlight — 小さく速く始める用途で有利。
Vue 陣営: VitePress — 他にまともな選択肢なし。

シナリオ D · SaaS の API ドキュメント 要件: OpenAPI 自動レンダリング、API プレイグラウンド、AI 検索、速く格好良く、デザイナー工数削減。

1 位: Mintlify — お金で時間を買う道具。デザイン、AI 検索、OpenAPI 自動化が全部入り。
2 位: Docusaurus + redocusaurus + Algolia + Kapa.ai — セルフホスト + 連携。コストは抑えられるが手間は増える。
3 位: Starlight + OpenAPI プラグイン — 勢いあり。

シナリオ E · 社内 Wiki / チェンジログ

1 位: MkDocs Material または Docusaurus — どちらも実績あり。チームの言語が Python なら前者、JS なら後者。
2 位: Starlight — 小チームで速く始めたいとき。

14 章 · AI 時代のドキュメント — 新しい変数

2026 年にドキュメントサイトを作るとは「人が読むページを作る」だけではない。LLM が読んで答える。だから新しい変数が三つある。

変数 1 · llms.txt / llms-full.txt サイトのルートに llms.txt を置くと LLM がサイト構造を素早く理解する。2025 年後半に事実上の標準となった。Mintlify は自動生成。Docusaurus、Starlight もプラグイン対応。なければ ChatGPT や Perplexity がサイトを上手くインデックスできない。

変数 2 · サイト内 AI 検索 ページ検索だけでは足りない。「どうやって X をしますか?」と聞かれたら LLM がドキュメントから答えを合成すべきだ。Mintlify は標準内蔵。それ以外は Kapa.ai、Inkeep、Mendable、Algolia AI の SaaS を後付け。コストは月額 200〜1,000 ドル。月間 10 万を超えるドキュメントトラフィックがあるなら導入検討。

変数 3 · 構造化されたコンテンツ LLM がよく引用するページは title、h1、コードブロックの言語、メタ説明、Open Graph タグが正確だ。SSG がこのメタデータを自動生成するか、著者が手で書くかが LLM フレンドリー度を決める。Mintlify、Starlight、Docusaurus は強い。自前ビルドはしばしば弱い。

2026 年のドキュメントトラフィックの 30〜50% は LLM が合成した回答経由だ。人間の直接ページビューは減り、LLM 引用ページビュー が増える。この変化に対応しないドキュメントサイトは半年後に埋もれる。

15 章 · 移行コスト — 道具を替えるということ

1 年運用した SSG を替えるコストは初期導入の 10 倍だ。だから最初の選択が重要。移行作業を分解すると。

コンテンツ変換 · Markdown 同士は比較的容易だが、フロントマターのフィールド名、shortcode、MDX コンポーネントが違うと一括変換スクリプトが必要。大規模サイトでは数日。
URL の保存 · 古い URL が変わると SEO が崩れる。ルーティング規則を慎重に移し、1 年分のリダイレクトを置く。
検索インデックスの再構築 · Algolia や自前インデックスを作り直す。検索品質が変わってユーザーが文句を言う。
デザインの再現 · ピクセル完全一致は不可能。一部のページで微差が出て、しばらく「以前のほうが良かった」と言われる。
ビルドパイプライン · CI 設定、キャッシュ、デプロイフック、preview 環境を新ツールに合わせて作り直す。
執筆者の再教育 · 既存著者が新しい Markdown 拡張と MDX コンポーネントを覚える。1 週間は見込む。

最善は移行しないこと。やるなら 同じカテゴリ内で 動かす(例 · MkDocs Material → Starlight は比較的容易、MkDocs → Docusaurus は難しい、MkDocs → Mintlify は自動移行ツールが一部あるが検収必須)。

16 章 · エピローグ — 意思決定チェックリストとアンチパターン

選ぶときのチェックリスト

サイトのカテゴリは何か — ブログ / マーケティングサイトか、技術ドキュメントか、両方か。答えで候補が半減する。
コンテンツモデルは何か — Markdown のみか、MDX が必要か、インタラクティブなウィジェットが必要か。
著者は誰か — Markdown に慣れたエンジニアか、一般のコンテンツライターか、マーケターか。CMS 連携の要否が決まる。
言語は何個か — 韓国語 1 つなら自由に、5 つなら i18n ファーストクラス対応のツールだけが候補。
ビルド時間 / ページ数 — 100 ページならどのツールも速い。1 万ページなら Hugo / Zola。
検索 / AI 検索が必要か — 必要なら Mintlify、MkDocs Material、Starlight が有利。
デプロイとホスティング — セルフホスト可か、SaaS 専用か。Mintlify は SaaS 専用。
年 1 万ドルの予算を出せるか — 可なら Mintlify、不可なら OSS。
これから 5 年運用できるか — すでに衰退しているツール(Gatsby)は避ける。

よくあるアンチパターン

「Next.js フルスタック」で単純なブログを始める — 5 ページのブログに App Router・Server Components は要らない。Astro や Hugo のほうが小さく安定。
AI 系の新ツールばかり追う — Mintlify が良く見えても年 1 万ドルを出せないなら、MkDocs Material や Starlight で始め徐々に AI 検索を足すのが合理。
カテゴリを無視する — ブログ向け SSG(Hugo)で巨大なドキュメントサイトを建てたり、ドキュメント向け SSG(MkDocs)でインタラクティブなマーケティングサイトを建てる。
多言語を後回しにする — 韓国語コンテンツを作ってから英語・日本語を足そうとして、ツールが i18n をファーストクラスで持っていないため全部やり直し。最初から i18n を決定因子に。
検索を後回しにする — Algolia DocSearch の申請をせず自前検索を書いていたら半年経つ。早い時期に決めて統合せよ。
衰退したツールで新規に始める — 2026 年に Gatsby / Hexo / Jekyll で新規を始めるのは 5 年後を考えると危険。既存サイトは維持してよいが、新規は勢いのあるツールで。
移行を軽く見る — 「別の SSG に替えればいい」が 1 週間の作業に見えて実際は 1〜3 か月。
ビルド速度を無視する — 100 ページで始めて 1 年後に 3,000 ページになると CI ビルドが 30 分かかり全 PR が遅くなる。ページ数の増加曲線を予測せよ。

次回予告

次回は MkDocs Material で社内ドキュメントサイトをゼロから運用へ — ディレクトリ構成、多言語、検索、権限、CI ビルド、そして AI 検索を載せる実際の手順まで見る。

その次は Astro Starlight 対 Docusaurus 正面移行 — 同じ OSS ドキュメントを両ツールでビルドして何が違うかの定量記録。