Blume は、Markdown または MDX の置かれたディレクトリから文書サイトを作るオープンソースのフレームワークである。 初期設定なしでも、ファイル構成からのナビゲーション、検索、テーマ、検索エンジン向けのメタデータを備えた静的サイトを生成する。 設定を増やさずに始め、必要になったときだけ TypeScript の設定ファイルやコンポーネントで拡張できる。
Blume の特徴は、人間向けのページとエージェント向けの入口を同じ原稿から用意することにある。 標準では、全ページの要約と構造を並べた `llms.txt`、原稿全文をまとめた `llms-full.txt`、各ページの Markdown 版を出力する。 さらに `agent-readability.json` と HTTP の `Link` ヘッダーで、それらの場所をエージェントへ知らせる。 エージェントは HTML を推測して解析する代わりに、文書の構造と原稿を直接取得できる。
対話機能は静的配信の前提を壊さないように分離されている。 ページ内の質問応答と MCP サーバーは任意で有効化する機能であり、どちらもサーバー出力と対応する配備先を必要とする。 質問応答は文書の検索索引から関連ページを取り出し、その内容だけを根拠に回答して出典を示すように設計されている。 したがって、単に AI の窓を置くのではなく、文書を公開時点の内容に結び付けて回答させる。
この構成は、文書の原稿を人間用の表示とエージェント用の知識源で別々に管理したくない場合に向く。 ただし、`llms.txt` や Markdown の公開は内容を取得しやすくするため、公開したくないページは個別に除外するか、そもそも公開サイトへ含めない判断が必要になる。
他の文書フレームワークとの比較
Blume と Starlight は、どちらも Astro を基盤にして静的 HTML を生成する。 Starlight は Pagefind を既定の検索としてビルド時に索引化するため、検索は静的配信だけで動く。 Blume の既定は Orama によるローカル検索で、静的出力にも検索索引を含められる。 小規模から中規模の公開文書では、どちらも外部の検索サービスを用意せずに済む。
Rspress は React を基盤にし、Rsbuild と Rspack で静的サイトを生成する文書フレームワークである。 標準の全文検索は FlexSearch を使い、設定なしで動く。 版ごとの索引も既定で分けられるため、複数版の文書で検索結果を現在読んでいる版に絞れる。 規模が大きくなって外部の検索基盤を使いたくなれば、公式の Algolia プラグインへ差し替えられる。
Blume と Rspress は、どちらも `llms.txt`、`llms-full.txt`、各ページの Markdown 版を出力できる。 違いは既定値にある。 Blume はこれらを標準で出力し、公開面を発見する `agent-readability.json` も標準で置く。 Rspress は SSG-MD という実験的な機能を `llms: true` で有効にする方式で、カスタム部品についても Markdown 用の表現を実装できる。 一方で、今回確認した Rspress の公式資料には、Blume のような MCP サーバーやページ内の質問応答は含まれていない。
Fumadocs は Next.js を基盤にし、既定で Orama を使う検索を提供する。 検索 API をサーバーとして動かす構成と、索引をブラウザへ配る静的構成を選べる。 静的構成では閲覧者が索引をダウンロードするため、文書や日本語などの形態素解析用トークナイザーが大きくなるサイトでは、外部検索サービスの利用を Fumadocs 自身が勧めている。 React と Next.js のアプリへ文書を組み込み、部品を細かく作り替えたいなら Fumadocs が自然である。
Docusaurus は React を基盤にした成熟した選択肢で、公式連携の Algolia DocSearch を第一候補にしている。 これは公開サイトを巡回して外部の索引へ登録する方式なので、大規模サイトでも閲覧者へ索引全体を配らずに済むが、検索結果が更新されるまで巡回を待つ。 ローカル検索も選べるが、公式資料は小さな索引を閲覧者がダウンロードできるサイト向けとしている。
ビルド時間について、Rspress は開発時に訪問したページだけをコンパイルする遅延コンパイルと、再利用する永続キャッシュを既定で有効にする。 Rspress は、キャッシュが効く後続の起動とビルドを30から60パーセント速くできると説明しているが、対象サイトや計測条件は示していない。 Blume は Astro と Vite を使い、生成する内部プロジェクトでは変更されたファイルだけを書き換えると説明しているが、他製品と比較できる公式測定値は公開していない。 Starlight と Fumadocs も、横比較に使える公式測定値は見つからない。 一方、Docusaurus は約二千ページの公式事例で、最適化前の冷間ビルド120秒に対して「Docusaurus Faster」を有効にした冷間ビルド31秒、再ビルド33秒に対して17秒と報告している。 この数値は Docusaurus 内の最適化前後の比較であり、Blume などとの直接比較にはならない。
したがって選定では、最初に検索の責任をどこへ置くかと、React の部品を文書内でどこまで使うかを決めるとよい。 静的ホスティングだけで検索とエージェント向け公開面を持ちたいなら Blume、React のコンポーネント文書で高速な開発時起動と版別検索を重視するなら Rspress、Astro の既存サイトへ素直に文書を加えたいなら Starlight、Next.js の部品体系へ深く合わせたいなら Fumadocs、大規模な公開文書で Algolia の巡回索引や多言語・版管理を使いたいなら Docusaurus が候補になる。
https://useblume.dev/docs/configuration/ai
https://github.com/haydenbleasel/blume
https://rspress.rs/guide/start/introduction
https://rspress.rs/blog/rspress-v2
https://rspress.rs/api/config/config-basic
https://starlight.astro.build/
https://starlight.astro.build/reference/configuration/
https://fumadocs.dev/docs/headless/search/orama
https://docusaurus.io/docs/search