JavaScriptフレームワークに潜むAIコスト

エージェントはコードを1行も書く前に、移行ガイドを読むのに11分を費やしていました。あなたのエージェントではありません。先週、同僚がSvelteKitプロジェクトに同じ指示を出したときのものです。あなたが1時間前にReactアプリで使ったのと同じプロンプトです。あなたのエージェントは約8分、400万トークンほどで終わりました。同僚のほうは17分と1,000万トークン近くを消費し、その差の大部分は、学習時に一度も見たことのないフレームワークのバージョンを、モデルが手探りで学び直していた時間でした。このギャップには今や名前がついています。JavaScriptフレームワークのAIコストです。そして業界では珍しいことに、誰かが主張するのではなく実際に計測してくれたおかげで、ようやく実数が手に入りました。

長年にわたり、フロントエンドの言い伝えを実際のベンチマークで検証し続けてきたNolan Lawsonが、最近、誰もやろうとしなかった当たり前のことを実行しました。検索、絞り込み、詳細ページ、PokéAPIのデータを備えた、小さいながらも単純ではないポケモンアプリを用意し、コーディングエージェントに12通りの方法で作らせたのです。対象はAstro、Next.js、Nuxt、SvelteKit、React Router、SolidStart、Qwik、Angular、TanStack Start、htmxを組み合わせたHono、Litを使うGracile、そしてUIフレームワークを一切使わないプレーンなViteです。各フレームワークは同じプロンプトで5回ずつ独立に実行され、エージェントがズルできないように、各ビルドは適合性テストスイートで検証されました。結果はコスト、時間、トークン、Lighthouseの指標で評価されています。完璧な実験ではないと、Lawson本人も認めています。それでも、多くのチームが雰囲気だけで決めているものに値札をつけようとした、私が見てきた中で初めての誠実な試みです。

ベンチマークが実際に測定したもの

実験の設計は意図的に中立でした。エージェントには仕様が渡され、指定されたフレームワークの最新版を使うよう指示され、SSRにするかCSRにするかなどアーキテクチャは自由に選ばせました。公式のMCPサーバー、エージェント用スキル、プラグインが提供されているフレームワークは、それらも利用できるようにしたので、「学習データで不利に扱われた」と文句を言うフレームワークはありません。適合性テストは生のDOMではなくアクセシビリティツリーに対して実行されました。これは、候補の1つがShadow DOMでレンダリングするため重要でした。各フレームワークは5回ずつ実行され、結果は中央値で報告されています。ただし例外がひとつあり、Angularは2回にわたってテスト可能なアプリを生成できなかったため、一部の数値は3回の実行に基づいています。

• ビルドコストは、アプリあたりの中央値で約2.67ドルから4.97ドルの範囲に収まりました。最安と最高額のフレームワークの間で、約2倍の差です。
• トークン消費も同じ傾向を、より顕著に示しました。最安のスタックでは約400万トークン、最も高いものでは1,000万トークン近くでした。
• 経過時間はコストとほぼ連動しており、速いほうで約8分、遅いほうで17分でした。
• SvelteKit、Gracile+Lit、Angularは一貫して最もコストの高いビルドでした。Astroとhtmx組み合わせのHonoは一貫して安価でした。
• 意外なことに、フレームワークを使わないプレーンなViteのビルドは、実際のフレームワークのいくつかより低い成績でした。エージェントにとっても、何らかの構造があるほうが無いよりよいのです。

ビルド1回あたり2ドルというと大した額に聞こえません。実際、1回だけなら大した額ではありません。しかし、エージェント開発は本質的に反復的です。最初の出力をそのまま採用する人はまずいません。この差に、開発者1人あたり週に数十回のエージェントセッションを掛け、チーム全体で1年分にすると、スタックごとのトークン倍率は無視できない費用項目になります。さらに重要なのは、トークン数はお金以上に私が重視する指標の代理になるという点です。それは、モデルがあなたのフレームワークで正しいコードを生成するために、どれだけ試行錯誤を必要とするかです。トークン数が多いのは、たいていエージェントが混乱してドキュメントを読み直し、何度もリトライしていることを意味します。これは、コストの形をした品質シグナルなのです。

なぜ一部のフレームワークでエージェントは高くつくのか

モデルの訓練や評価に長年携わってきた立場から言うと、結果は見た目ほど不思議ではありません。差のほぼすべては3つの仕組みで説明でき、そのどれも、従来の意味で「どのフレームワークが優れているか」とは関係がありません。

学習データの密度がすべてを決める

エージェント時代におけるReactの最大の強みは、そのプログラミングモデルではありません。10年分のチュートリアル、GitHubのリポジトリ、Stack Overflowの回答が、あらゆる最先端モデルの重みに、そのイディオムとして圧縮されていることです。Reactを書くエージェントは、主に想起しているだけです。一方、Gracileを書くエージェントは、主に探索しています。ベンチマークの実行では、フレームワークを知らないエージェントが、リポジトリをクローンしたり、node_modulesからコンパイル済みのソースを読んだりする場面がありました。ユーザーのコードが存在する前に、基礎の学び直しにトークンを使っているわけです。これは、Stack Overflowの衰退に伴って開発者の知識そのものの扱われ方が変わっているのと同じ力学です。この点については、Stack Overflowが衰えるなかで開発者知識のコーパスに何が起きているかについて書きました。フレームワークの話は、その特殊で鋭い例です。マイナーなツールはコミュニティが小さいだけでなく、モデルそのものの中での存在感も乏しいのです。

APIの頻繁な変更は、繰り返し発生するトークンの税金

SvelteKitの振るわなかった結果には、具体的で、少し笑えるほどの原因があります。SvelteKit v3の移行ガイドが、すべての実行で毎回読まれていたのです。そのバージョンは新しすぎて、モデルの学習データに含まれていなかったからです。フレームワークが破壊的変更を出すたびに、モデルが記憶しているパターンは無効になり、推論時に正しいAPIをドキュメントから導き直す必要が生じます。その代金は、毎回のセッションで、すべてのユーザーがトークンで払うことになります。フレームワークのメジャーバージョンの入れ替わりは、マーケティング上のイベントとして扱われがちです。しかしエージェントを使うユーザーにとっては、継続的な割増料金です。この基準で見ると、3年間APIを壊していない地味なフレームワークは、プレミアム機能なのです。

冗長さはループの中で積み重なる

Angularのコストは、単にコードの総量に比例しているように見えました。生成される行が増えれば、出力トークンが増え、以降の編集のたびに読み直すトークンも増え、エージェントがつまずく箇所も増えます。これはより一般的にも当てはまります。冗長なツール出力、ノイジーなビルドログ、遅いテストコマンドを持つスタックでは、エージェントは毎回の反復でより多くのテキストをかき分けることになり、失敗したlintや型チェックのたびに、高くつく往復が1回追加されます。実務者からも、どこでも同じパターンが報告されています。エージェントの支出を支配しているのは、生成のコストではなく、反復のコストです。高速で静かで厳格なツールチェーンを持つフレームワークは、緩いものよりも運用コストが低くなります。厳格さのおかげで、エージェントのミスが5回ではなく1サイクルで捕まるからです。

フレームワークが出す破壊的変更のひとつひとつが、今やトークンで誰かが払う税金になっている。しかも人間が変更履歴を読むのと違い、モデルはセッションごとに毎回それを払うのです。

エージェントのベンチマークに潜むサイコロの問題

ここで、私が長年のMLの評価で培った習慣が働きます。この研究で最も重要な点は、誤差範囲だからです。LLMの出力は点ではなく分布です。React Routerのビルドコストの中央値は、Hono+htmxより約1ドル高いだけでした。しかしReact Routerの最安の1回の実行は、Honoの最も高かった実行より安く済んでいます。範囲は大きく重なっています。SvelteKitの実行は約3.20ドルから6.80ドルまで振れました。エージェントは時にたまたま低い出目を出し、脇道にそれて、フレームワークとは無関係な理由で数百万トークンを燃やしてしまうのです。

ツールの利用状況のデータも同じことを示しています。フレームワークはMCPサーバーやスキルファイルを提供していて、エージェントはそれを使うこともあれば、使わないこともありました。Nuxtの MCPサーバーは5回の実行でまったく使われませんでした。TanStack Startのスキルファイルは、5回中2回しか見つけられませんでした。React Routerのスキルは毎回使われました。同じプロンプト、同じ環境でも挙動はまったく違います。これがツールの確率的な性質です。つまり、「1日バイブコーディングしたら、フレームワークXはエージェントにとって格段に優れていたので、アプリ全体を書き直した」というTwitterのスレッドは、ノイズを測っているにすぎません。1回の実行は逸話です。もしAIのコストをアーキテクチャの判断に影響させるのであれば、私はそうすべきだと考えますが、何かを信じる前に、繰り返し実行した結果の中央値を求めてください。このベンチマークも例外ではありません。

出力品質は、どれもおおむね十分な水準に収束する

最も意外だったのは、変わらなかった点です。Lighthouseのパフォーマンス、アクセシビリティ、累積レイアウトシフトのスコアは、12のスタックのほぼすべてで飽和していました。ほとんどが99や100だったのです。明確な仕様と適合性テストスイートがあれば、最近のエージェントは、ほぼどのフレームワークでも、まともでアクセシブルな小規模アプリを作れます。品質の下限は十分に上がり、コンテンツ中心のサイトでは、フレームワークの違いが出力にほとんど影響しなくなっています。

差が実際に出た品質指標は、配信されたJavaScriptのバイト数だけでした。アイランド型のAstroとHono+htmxのビルドはゼロKiBで、最も重いSPAの出力は約142KiBまでありました。合計ブロッキング時間はどれもわずかでしたし、LCPはノイズが多すぎて、ほとんど解釈できませんでした。ここには2つの正直な注意点があります。テスト用のアプリはFigmaよりWikipediaに近く、複数ページのアーキテクチャに有利です。また、Lighthouse自体がSPAに対して構造的に不利に偏っています。それでも、プレーンJavaScriptの結果は立ち止まって考える価値があります。フレームワークを使わずプレーンなViteで作るよう指示されたエージェントは、いくつかの実際のフレームワークより低いスコアを出し、どのビルドよりも大きなレイアウトシフトを記録したのです。フレームワークは規約を体現しており、エージェントは規約に強く頼ります。モデルに使い慣れた轍を与えれば、そこから抜け出しませんし、白紙を与えれば、アドリブで作りますが、それが常にうまくいくとは限りません。

このベンチマークでわからないこと

ポケモンのデモに基づいて本番アプリを書き直す前に、対象範囲について正直になっておきましょう。これは小規模で、ほとんどがコンテンツ駆動のアプリです。横断的な状態はほとんどなく、多言語対応もなく、複雑なフォームもなく、5年間保守し続ける人間のチームもいません。これは現実的な制約で、このブログで私がくり返し取り上げている落とし穴と同じです。AIのベンチマークは、実際の仕事の大部分を体系的に取りこぼしています。グリーンフィールドのおもちゃで、エージェントにとってフレームワークを良いものにする性質、つまり馴染みやすさ、単純さ、静的な構造は、混沌とした製品の18か月目に効いてくる性質とは違うのです。

議論のなかでフレームワーク懐疑派が指摘した、より深い点もあります。フレームワークが歴史的に持ってきた価値の多くは、何をできるようにするかではなく、何を禁じるかにありました。Javaがエンタープライズ開発を制したのは、1万人のプログラマーに似たコードを書かせたからという面があります。フレームワークは、入れ替わり、去り、互いに誤解し合う人間のチームのための制約システムなのです。エージェントは退屈さや、履歴書のための技術選択から身を守るガードレールを必要としません。必要なのは、明確な仕様とテストスイートです。ある実務者は、htmxでまさにこの逆転を報告しています。単純なページはすいすい作れたのに、複雑でステートフルなフォームでは苦戦し、状態を落としたり、トグルを壊したりしました。Reactなら一発で済んだような問題です。十分なテストが揃って初めて、エージェントは正直に動くようになりました。エージェントにとって重要な制約はフレームワークではありません。適合性テストスイートなのです。

そして確かに、最も安いビルドが最も安いコードベースとは限りません。チームが深く理解し、何年も保守できるスタックのために、エージェントのセッションごとに2ドル余計に払うのは、明らかに正しい判断です。ただし、その判断には数字が必要だという点に注意してください。AIのコストを測ることの本当の目的は、勝者を決めることではありません。「このフレームワークはエージェントに向いている」という漠然とした印象を、採用市場、エコシステムの成熟度、バンドルサイズと比べられる数値に置き換えることです。DXの議論では雰囲気が負けました。エージェントの議論でも、初期設定で勝たせるべきではありません。

自分のスタックのAIコストを測る方法

ほかの誰かのベンチマーク、このベンチマークを含めて、そこから自分のコードベースを推測しないでください。あなたのリポジトリ、仕様、選んだモデルが、独自の分布を生み出します。幸いなことに、AIのコストを測るのは本当に簡単です。コーディングエージェントは、必要な情報をすでに報告しているからです。計測を始める前に、ループ、コンテキスト、権限がどう関わり合うかを理解したいなら、エージェント型コーディングCLIが実際にどう動くかについての記事が良い出発点になります。そのうえで、次のことをやってみてください。

1. ランディングページではなく、実際の仕事を代表する垂直スライスを選びましょう。データ層、状態管理、UIに触れる機能が対象です。
2. まず適合性テストを書きましょう。テストは品質ゲートであり、ズルを防ぐ仕組みでもあります。テストのないエージェントは、早々に勝利宣言をします。
3. 候補のスタックや構成ごとに、同じプロンプトを最低5回実行しましょう。報告するのは中央値と範囲であり、1回の実行結果は決して報告しないでください。
4. 総トークン数(キャッシュ読み取り、入力、出力に分けて)、経過時間、コスト、ツール呼び出しの回数、リトライループの回数を記録しましょう。
5. ドキュメントの読み込みに使われたトークン数も追跡しましょう。移行ガイド、変更履歴、node_modulesの探索が対象です。これが、学習データ不足によるコストであり、直接計測できます。
6. メジャーアップグレードのあとには、ベンチマークを再実行しましょう。APIが入れ替わり、学習のカットオフが動くにつれて、AIのコストは変わっていきます。

ハーネス自体は、半日ほどのスクリプト作業で済みます。私が使っている骨組みはこちらです。CLIのフラグの細部はエージェントによって異なりますが、全体の形はどれも同じです。

import json
import statistics
import subprocess
FRAMEWORKS = ["astro", "react-router", "sveltekit"]
RUNS = 5
SPEC = open("spec.md").read()
def build_once(framework: str) -> dict:
"""One full agent session: build the app, return usage stats."""
result = subprocess.run(
[
"agent-cli", "run",
"--prompt", SPEC,
"--context", f"Build this with the latest {framework}.",
"--output-format", "json",
],
capture_output=True,
text=True,
check=True,
)
return json.loads(result.stdout)
for framework in FRAMEWORKS:
runs = [build_once(framework) for _ in range(RUNS)]
costs = [r["cost_usd"] for r in runs]
tokens = [r["tokens_total"] for r in runs]
print(
f"{framework}: "
f"median ${statistics.median(costs):.2f} "
f"(range ${min(costs):.2f}-${max(costs):.2f}), "
f"median {statistics.median(tokens) / 1e6:.1f}M tokens"
)

トークンの合計と同じくらい、リトライ回数にも注目してください。私の経験では、「合格したテスト1件あたりのトークン数」が最も正直な指標です。コスト、混乱、正確さを1つの数字にまとめ、実際に痛い失敗パターン、つまりエージェントがコンパイルエラーのループを5回回ってようやく通るものを罰します。エージェントが1回目か2回目の試行で綺麗に通るフレームワークは、見かけ上「安い」けれど何度も修正が必要なフレームワークに、毎回勝ちます。

実践的な結論

では、エージェントにとって安いからといって、AngularのアプリをわざわざAstroに書き直すべきでしょうか。答えはノーです。ドルの差は小さく、ばらつきは大きく、テストアプリはおもちゃにすぎず、移行にかかるエージェントのトークンは、10年かけて節約できる額を上回るでしょう。「エージェントのため」とフレームワーク移行を売り込む人は、業界がいつもやってきた雰囲気だけの推論を、新しい正当化を付けて繰り返しているだけです。

それでも、AIのコストは、採用市場、エコシステムの深さ、バンドルサイズと並んで、意思決定のテーブルに席を得るべきです。グリーンフィールドのプロジェクトでは、証拠は一貫した方向を指しています。学習データに深く表現されていること、APIの入れ替わりが遅いこと、厳格で静かなツールチェーンであること、そしてモデルが何万回も見てきた規約を持つスタックを選びましょう。地味な技術を選ぶことは、もともと実用的な選択でした。エージェントは、それを測定可能にしただけです。フレームワークのバージョンは固定しましょう。モデルが追いつくまでは、アップグレードのたびに推論時の税金がかかるからです。そして、どのフレームワークを選ぶにせよ、適合性テストには投資してください。テストは、あらゆるエージェントのコストを下げ、迷走したときに正直さを保ち、今使っているモデルが時代遅れになったあとも長く役立つ、唯一の資産です。フレームワークは今後も入れ替わり続けます。残るのはテストと、計測する習慣なのです。