なぜいま「思想の話」をするのか

フレームワークを選んでから後悔した経験はないでしょうか。「流行っているから」「事例が多いから」という理由で導入したものの、プロジェクトが進むにつれて設計の違和感が積み重なっていきます。開発の後半になってようやく「このフレームワークはこういうプロジェクトを想定していなかったのか」と気づかされます。このような経験は、思いのほか多くの現場で繰り返されています。

AstroやNext.js、SvelteKitなど、Webフロントエンドのメタフレームワークの選択肢は増え続け、バージョンアップのたびに設計変更を重ねています。「結局、どれを選べばいいのか」という問いに、機能比較やベンチマーク結果だけでは答えを出しにくい時代になりました。

このシリーズでは、各メタフレームワークが「何のために作られたのか」という背景と思想に目を向けます。どのツールが優れているかではなく、どんな前提・価値観のもとで設計されたかを理解することで、自分のプロジェクトやチームに適した選択ができるようになることを目指します。第1回目となる本稿では、なぜそのような視点が必要なのかを考えていきます。

フレームワークは「問題への回答」である

道具は目的のために作られています。たとえば左利き用のハサミは、一般的な右利き用のハサミでは左手で使いにくいという問題を解決するために生まれました。それを右利きの人が「ハサミだから」と何も考えずに右手で使えば、かえって使いにくくなります。また、髪をすくためのすきバサミで紙を切ろうとしても、きれいには切れません。同じ「切る」道具だからといって、解決しようとしている問題を意識せずに使うと、使い勝手はよくなりません。

フレームワークやライブラリも、中立な道具ではありません。どんな設計も、解決すべき課題と変えたかった従来のアプローチを踏まえて生まれています。

Next.jsを例に取れば、ReactでのSSR（サーバーサイドレンダリング）を誰でも扱いやすくすることが、当初の大きな目標でした。当時、React単体でSSRを実現するには、サーバーとクライアントの両方で動くコードを自前で管理する複雑な仕組みが必要でした。その負担をフレームワーク側が引き受けることで、開発者がアプリケーションロジックに集中できる環境を作ったのがNext.jsです。

Astroはまた別の問いに答えています。コンテンツ中心のWebサイト（ブログ、ドキュメント、マーケティングサイトなど）に、なぜJavaScriptのランタイムを大量に届ける必要があるのか。テキストが中心の読み物ページにSPAの仕組みを適用すると、必要以上に処理が重くなります。AstroはHTMLを主体にし、JavaScriptは必要な箇所にだけ「アイランド（島）」として配置するというアプローチで、この問いに答えました。

このように、フレームワークを知ることは、それが誰の、どんな問題への回答なのかを理解することです。この視点をもつだけで、フレームワークの設計上の判断が「なぜそうなっているのか」見えてきます。

思想を知らずに選ぶ失敗

フレームワークの背景を理解しないまま選定すると、どんな失敗が起きるのでしょうか。

よく見られるのは、プロジェクトの性質とフレームワークの前提がズレているケースです。更新頻度が低く、インタラクティブな要素もほとんどないコーポレートサイトに、複雑なサーバーサイドのデータフェッチを前提とした構成を持ち込むと、シンプルでよいはずの実装が不必要に複雑になります。逆に、ユーザーの操作に応じてリアルタイムでデータが変化するダッシュボードに、静的サイト生成を主体とするツールを選ぶと、そのツールが想定していない実装部分で戦い続けることになります。

チームのスキルや文化との衝突も起きます。フレームワークにはそれぞれ「こう考えてほしい」という設計思想があります。その前提を共有しないままチームが使い始めると、開発者によって実装のアプローチがバラバラになり、コードレビューのたびに「これは正しいのか」という議論が繰り返されます。

問題はフレームワークそのものではありません。思想を知らないまま導入することが、失敗の根本にあります。

AIが「作れてしまう」からこそ失敗する

近年、この問題はより深刻になりつつあります。Claude CodeやCodexなどのコーディング支援AIが普及し、どのフレームワークを選んでもAIが実装を助けてくれる時代になったからです。

フレームワーク側もAI時代への適応を進めています。たとえばAstroは公式のBuild with AIページで主要なAIツールとの連携方法を案内し、AIが常に最新のドキュメントを参照できるMCPサーバーを提供しています。こうした動きはAstroに限らず、Next.jsやSvelteKitも公式MCPサーバーを提供しています。AIに最適化されたドキュメント形式であるllms.txtを公開するフレームワークも増えています。こうした取り組みにより、AIが「そのフレームワークらしいコード」を生成する精度は確実に高まっています。

しかし、生成されたコードがプロジェクトの要件や設計方針に合っているかどうかは、また別の問題です。AIはディレクトリ構造の提案から、ルーティングの実装、データフェッチのパターンまで、フレームワークにかかわらず一定の成果物を生成できます。フレームワークの思想とプロジェクトの前提がズレていても、動くコードを強引に作ってしまいます。たとえば、Astroが想定していない使い方をAIは何の抵抗もなく実装します。Next.jsのApp Routerが前提とするデータフェッチのパターンを無視した構成も、AIは平然とコードに落とし込みます。

初期開発のフェーズでは問題が見えにくく、プロジェクトが進むにつれて構造的な歪みが露呈します。「なぜこの設計になっているのか」と問われても説明できない箇所が増え、運営フェーズに入ってから変更が困難になります。この種の問題は、あとで気づくからこそ修正コストが高くなります。

AIは設計の是非を判断しません。どの選択が自分たちのプロジェクトに合っているかを判断するのは人間の役割です。その判断を支えるのが、フレームワークの思想の理解です。

「人気」だけでは選べない

「あのフレームワークが流行っているらしい」という理由だけで導入を決めてしまう。このパターンは以前からありましたが、AI時代においてリスクがさらに高まっています。

人気のフレームワークには、それだけ多くの学習素材やコミュニティの知見が蓄積されています。AIの学習データにも多く含まれるため、AIがコードを書きやすくもなります。その意味では、「人気」は確かに1つの有効なパラメータです。

とはいえ、AIが書きやすいことと自分のプロジェクトに適していることは、別の話です。Next.jsはReactエコシステムで多くの採用実績があり、AIによるサポートも充実しています。しかしNext.jsが前提とするサーバーサイドのデータフェッチの仕組みは、完全に静的なコンテンツサイトには過剰です。コンテンツの多いドキュメントサイトでは、Astroの思想のほうがしっくりくることもあります。

「チームがReactに慣れているから」という選定も同じです。AstroもNext.jsもコンポーネントとしてReactを利用できます。Reactが使えることと、そのフレームワークがプロジェクトに合っていることは、別の問題です。

「なぜこのフレームワークを選ぶのか」という問いに答えられることが重要です。人気や採用事例、使い慣れた技術は参考情報であり、選定の決め手にはなりません。

思想の理解が判断軸になる

では、フレームワークの思想を理解すると何が変わるのでしょうか。

まず、AIの提案を取捨選択できるようになります。「このフレームワークはサーバーサイドでのデータ取得を前提としている」という理解があれば、AIがクライアントサイドで全データを取得するコードを提案してきても「これはフレームワークの前提に反している」と判断して採用を見送れます。思想の理解は、AI活用のブレーキであり、ハンドルでもあります。

チーム内での合意形成も変わります。「AはBより優れている」という議論は収束しにくいですが、「Aはこの価値観を重視し、Bはこちらを重視している。自分たちのプロジェクトはどちらに近いか」という問いに変えると、議論に軸ができます。フレームワークの選定が、チームの設計思想を確認する機会にもなります。

さらに、将来の判断にも強くなります。バージョンアップで設計が変わったとき、その意図を「思想のアップデート」として読み解けると、単なる機能変更の追いかけではなく、変化の方向性を理解しながら実装を調整できます。

読み解く3つの視点

このシリーズでは、各フレームワークを「出発点・経過・現在」の3つの視点で読み解いていきます。いずれも公式ドキュメントやリリースノート、公式ブログから読み取れる情報をもとにしています。

取り上げるのはAstro、Next.js、SvelteKitの3つです。いずれも筆者が実際のプロジェクトで使ってきた、あるいはこれから採用を検討する際に選択肢に入るフレームワークです。WebフロントエンドにはほかにもNuxt、TanStack Start、Solid Start、Qwik Cityなど有力な選択肢があります。今回のシリーズではこの3つに絞りますが、各回で示す「思想を読み解く視点」はどのフレームワークにも応用できます。

なぜ作られたのか

創設期にどんな問題意識があったのか。公式サイトのWhyページや、もっとも初期のブログ記事には、そのフレームワークがどんな課題意識から生まれたかが書かれています。ここを読むと、設計上の判断の多くが腑に落ちます。

どのように育ってきたか

リリースノートや公式ブログをたどると、何が追加され、何が変わったかがわかります。AstroがSSRを後から加えたように、フレームワークはコミュニティの声や時代の要請に応じて変化します。その変化の文脈を知ることで、現在の姿の意味が見えてきます。

現在どんな問題を解決するか

今日の公式ドキュメントのトップには、そのフレームワークが想定する用途と対象ユーザーが明記されています。Astroであれば「コンテンツ重視のWebサイト向け」と書かれています。これが、プロジェクトとの相性を判断するもっとも直接的な手がかりです。

次回以降は、この3つの視点を軸に各フレームワークの思想を読み解いていきます。

まとめ

メタフレームワークは、ある問題への回答として生まれています。「人気だから」「事例が多いから」という理由だけで選ぶと、プロジェクトの前提と噛み合わない選択になりがちです。AI時代においてはその危険性がさらに増します。AIは動くコードを生成しますが、設計の是非を判断するのは人間の役割だからです。

適切な選択には、機能比較より先にそのフレームワークの思想を理解することが近道です。次回以降、この視点からAstroをはじめ各フレームワークを読み解いていきます。

次回はAstroを取り上げます。AstroがなぜJavaScriptをデフォルトで排除する方向を選んだのか。アイランドアーキテクチャはどんな問題意識から生まれたのか。具体的に掘り下げていきます。