JavaScriptフレームワーク選びは、これまで「速いらしい」「開発しやすいらしい」といった空気で語られがちだった。Nolan Lawson はその雰囲気論にずっと引っかかっていて、今度はAI時代にも同じことが起きているのではないかと疑っている。人間が手でコードを書く時代ならDXの好みで片づけられた議論も、エージェントに任せるようになると別の軸で比べ直せるはずだ、というのがこの記事の出発点だ。そこで彼は、フレームワークごとにAIの“コスト”を実測するベンチマークを組み立てた。
Lawson がやったのは、PokéAPI を使った小さめだが無視できないアプリを題材にして、複数のJavaScriptフレームワークや meta-framework でAIエージェントに実装させる実験だった。アプリは Pokémon の一覧を表示し、タイプや技、ゲームごとの情報を見られ、検索や絞り込みもできる。複雑な業務アプリではなく、Wikipedia に近い内容重視のサイトだと本人も認めているが、仕様を切りやすく、結果を検証しやすいので選んだという。
比較対象は Next.js、Nuxt、SvelteKit、Angular、Astro、Qwik、SolidStart、React Router、TanStack Start、Gracile+Lit、Hono+htmx、Vanilla など。各フレームワークについて、Opus 5.5 に高い努力設定で同じ仕様を与え、最新バージョンを使わせたうえで、各条件を5回ずつ実行した。Angular だけは2回うまく測定可能なアプリを作れなかったため、一部の指標は3回分になっている。評価軸は、1回あたりの金額、開発時間、消費トークン数、そして Lighthouse の performance と accessibility だ。
条件はかなり揃えている。公式の MCP や skill があるものはそれを使わせたが、SSR か CSR かのようなアーキテクチャの細部までは指定していないし、最速を目指せとも言っていない。CSS も Tailwind や Bootstrap などは避け、視覚的一貫性のための spec tokens だけを与えた。さらに、テストは DOM そのものではなく accessibility tree に基づく conformance suite で行い、shadow DOM を使う web components も不利にならないようにしている。
結果を見ると、API価格ベースのコストは Hono+htmx が最安で中央値 $2.67、続いて Astro $2.76、Nuxt $2.82、Vanilla $2.98、Next.js $3.14 という順だった。高いほうは SvelteKit $4.28、Gracile+Lit $4.65、Angular $4.97。もっとも、これらは Claude Code のAPI価格をそのまま引用したもので、実際に筆者が支払った額ではない。筆者は Max plan を使っているからだ。
時間もだいたい同じ傾向で、Astro が 8.2分、Hono+htmx が 8.6分、Nuxt が 9.0分あたりに収まり、Angular は 17.2分とかなり長い。トークン消費では Nuxt 3.85M、Astro 4.13M、Hono+htmx 4.26M が少なく、Angular は 9.76M と重い。筆者は、SvelteKit は新しすぎて学習データに薄く、毎回 migration guide を読みに行っていたらしいこと、Gracile はエージェントがよく分からずリポジトリを見に行ったり node_modules のコンパイル済みソースを読んだりしていたこと、Angular はコードサイズの大きさが効いていそうなことを挙げている。
さらに面白いのは、公式の MCP や skill があっても、エージェントがそれをちゃんと使うとは限らなかった点だ。Next.js では skill ファイルを読んだのは1/5回、AGENTS.md は2/5回、Nuxt では MCP が1度も使われなかった。React Router は skill tool を5/5回使った一方、TanStack Start は skill files を2/5回しか見つけられなかった。Hono+htmx の skill は5/5回使われ、SvelteKit の Claude Code plugin は5/5回使われた。つまり、ツールがあっても AI が読まないことがある。筆者はそこに、LLM のランダムさと現場の雑さがそのまま出ていると見ている。
品質面では、内容の少ない小規模アプリであること、そして Lighthouse や Core Web Vitals が SPA に不利になりやすいことを前提にしつつ、それでも比較を続けた。ここは途中までしか本文が載っていないが、少なくとも記事全体の狙いは「どのフレームワークが人気か」ではなく、「AIに作らせたとき、どれが実際に安く、速く、安定して成果を出すか」を測ることにある。
この実験でまず引っかかるのは、フレームワークの優劣より、AIの振る舞いが結果を大きく左右していることだと思う。人間なら慣れたツールを使えば迷いにくいが、エージェントはそうならない。skill や MCP が整っていても、読みにいくとは限らないし、むしろ新しすぎる情報や不慣れな構成にぶつかると、ドキュメントを巡回して無駄にトークンを消費する。つまり「AI向けのフレームワーク」とは、機能のよさだけで決まるのではなく、ドキュメントの見つけやすさ、学習済み知識との噛み合い、足場の分かりやすさまで含めた総合点になる。
ここで面白いのは、Vanilla が意外に強くないことだ。何も使わないほうが軽そうに見えるが、実際にはいくつかのフレームワークに負けている。これは、AIにとっては“道具が少ない”ことが必ずしも有利ではない、という示唆に見える。フレームワークがあると、構造や慣習がある程度固定されるぶん、エージェントの迷走が減るのだろう。逆に言えば、AIに任せる時代でも、抽象化は邪魔ではなく足場になる。ここは人間中心の「軽いほうが正義」という感覚と少し違う。
筆者は Lighthouse の偏りもかなり正直に認めている。Core Web Vitals は SPA に厳しく、MPA 系のフレームワークが有利になりやすい。だから performance で勝ったとしても、それが実利用の快適さをそのまま表すわけではない。とはいえ、こうした標準的な指標を使う以上、ある程度の偏りは避けられないし、そこを無視して「うちのフレームワークは高速です」と言い切るほうがよほど危うい。
この記事を読んで感じるのは、フレームワーク論争がAI時代に入っても、結局は同じ場所を回っていることだ。以前は「virtual DOM は速い」「SSR のほうが有利」といった話が、今回は「AI が使いやすい」「トークンが少ない」に置き換わっているだけで、やっていることはかなり似ている。測れないところを雰囲気で語ると、また同じ失敗を繰り返す。Lawson がベンチマークにこだわるのは、流行りの言い回しより、せめて数字を置けと言いたいからだろう。
個々のフレームワークの勝ち負け以上に、この記事が刺しているのは「移行の意思決定」だと思う。いまフロントエンドは、純粋な技術選好だけでなく、「AIに書かせやすいから」「エージェントがミスしにくいから」といった理由で選ばれ始めている。もしそうなら、その判断はなおさら実測が必要だ。感覚で“AI向き”と決めるのは危ないし、今回のように最安・最速・低トークンの顔ぶれが完全には一致しないなら、何を優先するかを明文化しないといけない。
一方で、私はこの実験を「フレームワークの真の実力ランキング」とは見ない。題材が小さく、AIのランダム性が大きく、しかも一部はツールの発見性に左右されるからだ。だが、それでも意味はある。むしろ実務では、理想的な再現性より、そうした不完全さを含んだうえで何が起きるかのほうが重要だ。AIに作らせたときにドキュメントを拾えるか、仕様を外さないか、余計なトークンを食わないか。そういう地味な差が、積み重なるとかなり効いてくる。この記事は、その差を“気分”から引きずり出そうとしている。
最後に少し意地悪に言うなら、この結果をそのまま「このフレームワークがAIに最適」と受け取るのは早い。AIの挙動はモデルの更新で変わるし、同じモデルでもプロンプト、温度、ツール実装、ドキュメントの書き方で簡単に揺れる。今日は Next.js が skill をあまり読まなくても、明日は別のモデルでは逆転するかもしれない。だからこそ、この記事の価値は順位表そのものより、測り方を公開したところにあると思う。
フレームワーク選びを“好み”で済ませるのは簡単だ。でもAIが制作の一部を肩代わりするなら、その好みがどこから来たのかを点検し直す必要がある。今回の実験は、少なくとも「AIにとって楽そう」という曖昧な印象が、必ずしも安さや速さに直結しないことを示した。私はそこに、かなり健全な警告を感じる。便利そうな流行語より、まずは測る。その姿勢が、AI時代のフロントエンドではいちばん大事なのではないかと思う。
