前回は Cursor の開発環境を整えました

今回は、Web フレームワークを選ぶ前の話です

どのフレームワークを選ぶか——サイトとして何をするのかをゆるく描いておくと、決めやすくなる
Cursor に相談しながら、選定に効くポイントのお話。フォルダ構成や実装の骨組みの話は次回に回す

フレームワークを選ぶ前に、何を決めるか

いきなりフレームワーク比較から入ると、比較軸がブレます。Cursor に「選定のために最低限決めておくこと」を聞いたところ、だいたい次の5つに整理されました

MVP は「まず最初に公開する最小限の形」のこと。いきなり全部入りを目指さない、くらいの意味で読んでください

全部きっちり決めなくてよくて、「だいたいこういうサイト」 と言えれば十分

サイトの型 — ナレッジベース

最初の問いは「ブログ型か、ナレッジベースか」

作ろうとしているのは DevRev のあるあるを集めるナレッジサイト です。1件＝1つのあるある を並べて、症状やキーワードから探せる——これが出発点でした

時系列の新着より トピックとタグ を軸にする。ここまで決まると、フレームワーク選定の方向性は 読ませる静的サイト寄り になります

次は「何ページ要るか」「何を載せるか」。URL の細かい設計や見た目は、今回は触りません

ページの種類としては、だいたい次が要る——という整理です

コンテンツは2系統

系統	粒度
あるある	短い（症状・原因・対処）
検証してみた	やや長い（試したログ・手順）

短文のナレッジと、少し長い読み物が 同居する——この2点が、フレームワーク選定に効きます

動的機能の有無を決めるうえで、MVP から外すものを先に書き出しました

これらは DB や認証が要る。サーバーで都度つくるような機能 は最初から入れない、という整理です

一覧・詳細・タグ程度なら、まずは静的ページだけで回せそう

「症状やキーワードで探す」はサイトの出発点なので、全文検索は将来ほしい——ただ MVP では タグ別一覧とあるある一覧 でまず足りる、と判断しました

ここでひとつ整理したのは、検索＝サーバー側の動的機能とは限らない という点です。Astro のような静的サイトでも、ビルド時に検索インデックスを作って ブラウザ側で全文検索する やり方は普通にあります。DB も認証も要らず、静的のまま 後から足せる

あるあるの件数が増えて「タグだけでは探しにくい」と感じたタイミングで検索を入れる——MVP では急がない、という線引きです

「誰が・どこから更新するか」で、DB や認証の要否が決まります

今回の方針はシンプルです

「CMS をサイト内に作る」のではなく、静的のまま回す——ここがフレームワーク選定の大きな前提になりました

フレームワークを選ぶために、サイトの方針をゆるく固めた回のメモです