概要

「このプロダクト、フレームワーク何にします？Next.js？え、なぜですか？」

この定番の問いは、これまで「学習コストが低いから」「人材調達し易いから」「チームが慣れているから」「流行ってるから」といった、"人間にとっての都合" で答えられてきた。

しかし執筆現在、この前提が崩れ始めている。最近のWebフレームワークは、AI向けの AGENTS.md をデフォルト同梱¹するようになり、フレームワーク専用のMCPが用意されて最新ドキュメントはマシンリーダブルになった。

v0 や Lovable のようなAIアプリビルダーはNext.js（React）以外をほぼ出力しない²といった依存度の高いサービスもあるが、「Vue/Nuxt は v3 になって破壊的変更デカすぎだから無し」「とりあえず Next.js でいいよね？」「最近、流行ってるから TanStack Start にしとこう」 という時代ではなくなった。

フレームワーク自体も、「人間がいかに開発し易いか、人間軸でのボトルネックをいかに解消したか」を謳うのではなく、「AI で開発し易いか、AI 機能の搭載がいかに楽なのか」を前提に進化し始めている。

要するに、流行っていなかろうが、人間的に扱いづらかろうが、手動でやるにはメンテが面倒だろうが、AIフレンドリーならば採用する理由が大きくなる。…というパラダイムシフトが起き始めていると感じる。

今は、過去の固定観念や既存のしがらみですぐには変わらずとも、近い将来には技術選定基準が既成事実とともに変化する可能性。そう感じた理由などをざっと記載していく。

「フレームワークの選び方」はどう変わるか？

従来のフレームワークの選び方

これまでの評価軸は、突き詰めると全部「人間都合」だった。

学習コスト（新メンバーがキャッチアップしやすいか）
エコシステムの大きさ（ライブラリ・求人市場・情報量）
パフォーマンス・実行効率
チームの慣れ・過去の採用実績

これらは今も無意味になったわけではない。ただし「AIが実装の主体になる」プロジェクトでは、優先順位が入れ替わりつつある。

AIネイティブ時代のフレームワークの選び方

AIによるコード生成の現場は、ここ数年でニーズそのものが段階的に変化してきた。この変遷をたどると、評価軸を主観ではなく歴史的経緯から導き出せる。

プロンプトエンジニアリング／バイブコーディング期（〜2024年）：「何を言えば意図通りに動くか」が課題だった時代。フレームワークは「AIが知っていそうな有名なもの」であれば十分だった。
コンテキストエンジニアリング期（2025年〜）：Anthropicが2024年11月に公開したMCP³を境に、焦点は「AIに何を見せるか」に移った。フレームワーク公式のドキュメントMCPサーバーやllms.txtの有無が、実装精度を左右する差になった。
エージェンティック／ハーネスエンジニアリング期（2026年〜）：Karpathyが「バイブコーディングは終わった」と表明しAgentic Engineeringという語を提唱⁴。AIが計画・実装・テスト・修正までを自律的にこなすようになり、AGENTS.mdのような「エージェント向け取扱説明書」がNext.jsやReact Router等で標準搭載され始めた。
グラフエンジニアリング期（2026年7月〜）：単一エージェントのループでは扱いきれない規模の仕事を、複数のエージェントや処理単位をノードとエッジでつなぐ「グラフ」として設計する⁵動きが急速に広まった。仕事を複数のエージェント・コンテキストに分割し、安全に受け渡す構造そのものが問われるようになっている。

個人的にバズワードにいちいち便乗するつもりはないのだが、この無視できない変遷を踏まえると、フレームワークに求められる客観的な評価軸は次の3つに整理できる。

コンテキスト供給力（コンテキストエンジニアリング由来）：ドキュメントやAPI仕様をAIが直接読み取れる形で提供しているか。MCPサーバーやllms.txtだけでなく、Agent SkillsやAGENTS.mdのようなカスタムインストラクションを公式にデフォルト同梱しているかもここに含む。
自律実行への耐性（エージェンティック／ハーネスエンジニアリング由来）：規約の強さや型安全性により、エージェントが自己修正しながら人手を介さず実装を完走できるか。
マルチエージェント適合性（グラフエンジニアリング由来）：モジュール境界が明確で、機能を複数のエージェントやツールとして安全に切り出せる構造か。WebMCP⁶（Webページ自体をAIエージェントから呼び出せる「ツール」として公開するW3C草案）のような規格への対応力はこの一例。

なお、SSRか、SPAか、コンテンツ中心のサイトかといったレンダリング戦略の軸は、SEOや更新頻度といったアプリの要件で決まるもので、AIネイティブ時代でも大きくは変わらない。「AIにとっての実装・運用のしやすさ」とは直交する別軸の話なので、あえて上記3軸には含めていない。

象徴的なのがAngularの巻き返しだ。「往年の3大フレームワーク」の一角として長らく「エンタープライズ向けで冗長」という評価だったが、Angular v22（2026年6月）はCLIにMCPサーバーを内蔵し、Agent Skillsも提供してコンテキスト供給力を高め、強力な型安全性で自律実行への耐性を確保しつつ、provideExperimentalWebMcpTools()で実験的にマルチエージェント適合性にも先手を打った⁷。人間向けの使いやすさで劣っていたフレームワークが、この3軸すべてで武装し直して巻き返す構図が生まれている。

開発フレームワークのAIフレンドリースコア

スコアリングの評価軸

以下、Next.jsを含む開発フレームワークを上記3軸（各5点満点、合計15点）で主観評価する。あくまで「AIに実装させる上での扱いやすさ」を軸にしており、採用実績や人材市場の大きさは意図的に評価から外している。

軸	見るポイント
コンテキスト供給力	ドキュメント・API仕様をAIが直接読み取れる形で提供しているか。MCPサーバー、llms.txtに加え、Agent SkillsやAGENTS.mdなどのカスタムインストラクションをデフォルト提供しているか
自律実行への耐性	規約の強さや型安全性により、エージェントが自己修正しながら人手を介さず実装を完走できるか
マルチエージェント適合性	モジュール境界が明確で、機能を複数のエージェントやツールとして安全に切り出せる構造か（WebMCPなどへの対応は一例）

俺俺ランキング｜AIフレンドリースコアリスト

各フレームワークが実際にどんなAIネイティブなアップデートを行っているかも出典付きで記載し、評価軸を用いで、独断と偏見で勝手に評価してみた。

フレームワーク	コンテキスト供給力	自律実行への耐性	マルチエージェント適合性	合計/15	主なAIネイティブアップデート
Next.js	5	4	4	13	`next-devtools-mcp`でApp Routerツリーや Server Actionsに直接問い合わせ可能に、`create-next-app`は`AGENTS.md`を標準同梱（staticmania.com⁸、Next.js公式¹）
Angular	4	3	5	12	`ng`CLIにMCPサーバー内蔵、Agent Skills提供、`provideExperimentalWebMcpTools()`で実験的にWebMCPをサポート（InfoQ⁷）
Nuxt (Vue)	4	4	4	12	公式ドキュメントMCPサーバー（nuxt.com/mcp）に加え、Nuxt MCP Toolkitでアプリ自身をMCPサーバー化できる。同じMCP基盤で動く「Nuxt Agent」も提供（Nuxt公式⁹、Nuxt Blog¹⁰）
TanStack Start	4	4	4	12	2026年3月発表のTanStack Intent¹¹がAgent Skills（`SKILL.md`）をnpmパッケージに同梱し、`npx @tanstack/intent install`で`AGENTS.md`にガイダンスを自動反映する仕組みを構築（TanStack公式¹²）。CLIに`--mcp`フラグで起動できるMCPサーバーも内蔵し、`@tanstack/ai-mcp`でホスト側MCPクライアントを提供し複数MCPサーバーとの接続も構造化されている（TanStack AI公式¹³）
SvelteKit	4	4	3	11	`llms.txt`/`llms-full.txt`/`llms-small.txt`のドキュメント群と、`svelte-autofixer`などのツールを持つ専用MCPサーバーを整備（Svelte公式¹⁴、Svelte Blog¹⁵）
Hono	3	4	4	11	`hono-agents`パッケージでステートフルなAIエージェントをアプリに直接組み込み可能（npm¹⁶）。ただし本番品質チェックでは基準割れも報告¹⁷されており過信は禁物
Encore.ts	5	3	3	11	フレームワーク組み込みの公式MCPサーバー（`encore mcp start`）でCursor/Claude等から実行中アプリを直接イントロスペクト可能（Encore Blog¹⁸）
Remix (React Router v8)	3	4	3	10	`create-react-router`がAgent Skillsを標準搭載、React Router v8としてEOL移行も完了（React Router changelog¹⁹）
Wasp	4	4	2	10	「AIアシスト開発（vibe coding）」を公式に掲げる²⁰config-as-architecture型。専用MCP整備はまだこれから
Reflex	4	4	2	10	フロント〜バックをPython単一言語で完結²¹、AIが言語を跨がなくて済む設計
SolidJS（Solid 2.0）	3	4	2	9	公式ドキュメントに `llms.txt` を用意し、2026年3月のベータ版は「エージェント向けにドキュメントを強化した」と明言。最大の特徴は非同期をリアクティブグラフ自体の一級市民として統合した点で、`createMemo` などの計算がPromiseを直接返せばグラフ側が自動でsuspend/resumeし、`use()` や `startTransition`、`createResource` のような調整APIが丸ごと不要になった。コンポーネントは最初の1回しか実行されず、以降は署名（Signal）が特定のDOMノードだけを直接更新するため「暗黙のマジック」ではなく明示的で決定的なリアクティブグラフとして振る舞う。この予測可能性はAIが自律的に非同期コードを生成・修正する際の事故を減らす方向に働くはずだが、2026年8月にRelease Candidateへ到達したばかりで本番実績はまだ薄く、公式MCPサーバーやAgent Skills/AGENTS.mdの標準同梱もなく、コミュニティ製MCPサーバー（solidJSkills等）に頼る段階
Astro	3	3	2	8	2026年5月に`llms.txt`群を全廃し、専用MCPサーバー（mcp.docs.astro.build）に一本化する方針転換（dacharycarey.com²²）

※ 上記は、完全に主観的評価なので、一般的にそう評価されているものではありません。悪しからず🙏

インフラサービスのAIネイティブ対応

フレームワーク単体の話だけでなく、それを載せるインフラ・PaaS側の動きも見逃せない。特にCloudflareとVercelは、既存のビッグテック（AWS/GCP/Azure）よりもAIエージェント向け機能の実装スピードが頭一つ抜けている印象が強い。

Cloudflare：2026年2月に発表したCode Mode MCPサーバー²³は、DNSからWorkers・R2まで2,500以上あるCloudflare API全体をsearch()とexecute()の2ツールだけで公開し、消費トークンを約1,000トークンに固定する（全記述だと1.17Mトークンでコンテキスト上限を超える）という荒業を実現した（ai-native.jp²⁴）。4月の「Agents Week」では、この仕組みをエンタープライズ向けMCPポータルに統合し、Agents SDK（McpAgent）のトレーシング機能や、AI生成アプリごとに専用DBを持たせるDurable Objects、エージェント向けサンドボックスのegress制御なども一挙に公開²⁵。しかも社内のAI開発スタック自体をこれらの自社製品（Workers AI推論、単一OAuthのMCPサーバーポータル、Code Modeによるサンドボックス実行など）だけで構築している²⁶点が、単なる機能追加ではなく本気度を物語っている。
Vercel：AI SDK²⁷でモデル切り替えを2行で完結させる統一プロバイダAPIを提供し、2026年にはAI SDK 7で推論制御・エージェント単位のツール承認・MCP Apps・durable workflows・サンドボックス実行・ハーネス統合などを一挙に追加し、週間1,600万ダウンロードを記録するまでの「本番用エージェントプラットフォーム」に進化²⁸。さらにCLI・API・MCPサーバー・Git連携を組み合わせ、エージェントがコード生成からPR作成・プレビューURL確認・本番デプロイまでを人手を介さず完走できる「Agentic Infrastructure」²⁹を公式に掲げている。
Firebase：2025年12月にプロンプト・スキーマ・モデル設定をクライアントから引き離しFirebaseのサーバー側に安全に格納できる「サーバープロンプトテンプレート」³⁰を導入し、プロンプトIPの保護と反復開発の高速化を実現。2026年4月にはこのテンプレートにファンクションコーリングや複数モーダル入力への対応を追加³¹し、着実に機能を積み重ねている。

一方、AWS・GCP・Azureの3大ハイパースケーラーはAI基盤への投資額・成長率こそ圧倒的（2026年第1四半期でGoogle Cloud前年比+63%、Azure+39〜40%、AWS+28%、mindstudio.ai³²）だが、その中心はBedrock・Vertex AI・Azure OpenAIといったモデル提供・基盤MLサービスの強化であり、Cloudflare・Vercelのように「MCPサーバーを標準搭載する」「エージェントがデプロイまで完走できる」といった開発者向けのエージェント実行基盤そのものへの投資は、相対的にスピード感が控えめに見える。フレームワーク選びと同様、インフラ選びにおいても「AIエージェントにとっての扱いやすさ」を主戦場に定めた新興プレイヤーが存在感を増している構図がある。

そもそも、AIネイティブ時代でも Next.js のスコアが主観的に高かった理由は、やっぱり運営の Vercel がスピード感もあって強い印象がある。Cloudfare が買収した Astro も好きなのでもっと伸びてほしい気持ちはある。

そして、何より昔から大好きな Angular は結構AIネイティブ対応が地味に盛り盛りなので今後採用されてほしい。笑

VSCode + GitHub時代から、Cursor + Origin時代へ

これもフレームワークの話から脱線するが、「時代が変わる」 という観点で触れたい。

開発体験（DX）の土台であるIDEとコードホスティングにも、AIネイティブ化の波が及んでいる。長い間事実上の業界標準だった「VS Code（エディタ）＋GitHub（リポジトリホスティング）」という二層構造が、Cursor（開発元Anysphere）一社が垂直統合する「Cursor + Origin」スタックに置き換わっていく可能性が、2026年に入って現実的になってきている。

SpaceXという後ろ盾：2026年4月21日、SpaceXはCursor（Anysphere）を600億ドルで将来買収するオプションを取得（もしくは協業対価として100億ドルを支払う）と発表³³し、6月16日には全株式で600億ドル規模の正式買収契約を締結、2026年第3四半期のクローズを見込むと発表³⁴した。AIコーディングツールを提供する一企業の機能拡張ではなく、宇宙・巨大計算インフラを抱える企業が後ろ盾に付くことで、リソース面でも信用面でも一段と引き上げられたものとして注目を集めている。
Cursor 3「Glass」（2026年4月2日）：これまでのチャットパネル中心のUIを廃し、「VS Codeフォークを拡張する」のではなく「エージェントを中心にしてゼロから新しいインターフェースを構築した」とAnysphere自身が明言する「Agents Window」に中心を移した³⁵。既存のIDE（VS Codeベース）は今も並存するが、位置づけは徐々に「フォールバック」側へと重心が移っており、この構成変化を「VS Codeのモデルがエージェントの並列実行に耐えられなくなったというアーキテクチャ上の自己告白」と評する見方もある³⁶。
クラウド中心のマルチタスク開発：Cloud Agentsは隔離されたクラウドVM内でリポジトリをクローンし、フル開発環境を立てて自律的にタスクを遂行し、完了と同時にPRを作成する³⁷。Git Worktreeで互いに分離された最大8エージェントを並列実行でき、ローカル↔クラウドのハンドオフや、エンタープライズのデータ常駐要件に対応した自社ネットワーク内で完結するセルフホスト型クラウドエージェント（2026年3月）も提供されている³⁸。開発者の役割は「コードを書く人」から「エージェントを指揮するオーケストレーター」へと徐々に転換しつつある。
Origin（発表2026年6月16日）：Graphiteの買収を土台に、Cursor自前のGitフォージ「Origin」を発表³⁹。「エージェント時代のためのGitフォージ」を掲げ、並列で動く複数エージェントの作業から生じるマージコンフリクトをネイティブに解決し、S3バックエンドで無限にレプリカを持ち、毎秒22.6コミットまでスケールする設計⁴⁰を売りにする。既存Gitクライアントとの互換性を保ちつつAPI/MCPで拡張でき、2026年8月時点で有料プラン向けの早期ベータが開始され、正式リリースは2026年秋を予定⁴¹している。おそらく最初は大した機能はつかないだろうが、Cursor エディタがそうだったように、徐々に進化して重要なプラットフォーム化をするであろうことが予測できる。
AI学習リソースとしての将来性：ここで注目すべきは、Originが単なるホスティング先ではなく、Cursorが提唱する「Agent Trace」という帰属メタデータ仕様⁴²を通じて、コードの差分だけでなく「誰が起動したか」「どのモデルを使ったか」「どの指示で動いたか」「途中で却下した案」「テストの試行履歴」「自動修正の理由」まで変更履歴と一体で記録できる設計になっている点だ。ある分析では、GitHubの本当の堀はコードそのものではなく「コードを巡る履歴と関係性」にあると指摘し、OriginがこうしたAIエージェント特有の思考過程・判断過程まで蓄積していけば、Pull Requestの最終差分しか持たないGitHubにはない、AIネイティブなコードベースとして独自の厚みを持つ可能性がある⁴³と論じている。これに、SpaceX/xAIの大規模計算基盤「Colossus」を使ってCursor独自のコーディングモデルの事前学習・強化学習を拡大できるという提携内容を重ねると、「Originに蓄積される高品質なAIネイティブコードとエージェントの思考ログ」を燃料に、Cursorが自社モデルをさらに強化し、そのモデルがOrigin上のエージェント群をより賢くする、という好循環（フライホイール）が生まれる可能性は示唆に富む。ただしこれはあくまで期待・観測の域であり、Cursor自身は現時点でOriginのデータを自社モデルの学習に用いる方針を明確には示しておらず、非公開コードの学習利用は契約・プライバシー設定に依存すると留保している⁴³点は差し引いて見る必要がある。

これらを重ねて見ると、「VS Code（エディタ）+ GitHub（リポジトリ）」という長らく定番だった構成が、「Cursor（エディタ〜AIエージェント実行基盤）+ Origin（リポジトリ）」という一社垂直統合型のスタックに置き換わっていく可能性は、現実的になってきている。SpaceXという巨大資本とインフラ後ろ盾を得たことで、これは単なる一スタートアップの機能拡張ではなく、開発インフラの入れ替えを本気で狙った動きとして見るべきだろう。ただし、Pragmatic Engineerの調査ではAIコーディングツールの人気投票でCursorは19%にとどまり、Claude Codeの46%に大差をつけられているという現実もある³⁸。インフラ層の覚悟と市場シェアは必ずしも一致していない。

ローカル中心の開発が前提だった時代から、リポジトリをクラウドのVMに送り込み、複数エージェントを並列に動かし、成果をレビュー・統合するワークフローへと重心が移りつつある今、この新しい開発スタック（CursorのAgents Window、自社ホスト型/クラウド型のCloud Agents、Originのようなエージェント前提のGitフォージ）を経験しておくことも、今後のエンジニアには必須スキルとして求められていくだろう。

まとめ

フレームワークの評価軸自体は明らかにシフトしている。
各フレームワークがAGENTS.mdやAgent Skills、MCPサーバー、WebMCP対応を標準搭載する競争に突入し、「どのフレームワークを使うか」という意思決定そのものが、人間ではなくAIエージェントを根拠に委ねられていくだろう。

また、AIネイティブ化の波はフレームワークの技術選定の話では終わらない。
フレームワークが変われば、それを載せるインフラも追随して変わり、さらにインフラを操作する開発方式そのもの（CursorとOriginに象徴されるIDE・Gitホスティングの再編）まで、同じ地殻変動の延長線上にあることが見えてくる。実はこれは「フレームワーク選定」というミクロな話ではなく、開発スタック全体――言語より上のレイヤーすべて――がAIエージェントを主要な利用者として再設計され始めているという、より大きな地殻変動の一断面にすぎない。

そして、この変化が本当に問いかけているのは、技術選定の作法だけではない。

これまで疑いなく正しいとされてきた従来の判断基準そのものが、もはや人間だけを前提にしたものでは通用しなくなっている。フレームワークもインフラも開発ツールチェーンも、次々と「AIにとっての扱いやすさ」を軸に組み直されていく中で、エンジニア自身の価値観やキャリアの積み方も、同じ前提の入れ替えを迫られているのではないかと感じた。

「自分が書きやすいか」ではなく「AIエージェントに委ねやすいか」、
「自分が理解できるか」ではなく「エージェントが自律的に検証・統合できるか」。

この視点の転換を怠れば、どれだけ手に馴染んだ技術スタックであっても、AIネイティブな競争の中で徐々に周回遅れになっていくし、逆にこれまで選ばなかった技術スタックを選び始めるかもしれない。

フレームワーク選びのキャッチーな問いから始めたが、「エンジニアとしてのAIネイティブな自己変革」というもっと大きな固定観念の壊し方を時代が要求しているように思えたという、ポエミーな技術論でした。

今後も新技術を触って試しながら、いろんな発信をしていきますので、関心ある方はまた Xの投稿でも適当に見てくださいな🙌