スタックの選択はエージェントのコストを左右するレバーだ

中級

What you'll learn

「エージェントにとってどのフレームワークが安いか」に実際の数字を与えた唯一のベンチマークを読む
見出しが取り違えている 3 点、とりわけ逆向きに動くトークン単価に気づく
トークンの請求が、書かれたコードの大きさではなくエージェントの「ループ」に連動する理由を理解する
プロジェクトの寿命を通じて本当に複利で効いてくる数字がどれかを知る (ビルド単価ではない)
いくつかの行を説明しうる統制されていない交絡要因と、それがあなた自身の持つレバーである理由を理解する
LLM のばらつきに耐えるプロトコルで、同じ測定を自分のスタックで行う

20 年間、フロントエンドのフレームワーク選びは、開発体験とバンドルサイズのトレードオフを意味してきました。エージェントはそこに、誰も数字を持っていなかった第三の軸を加えました。モデルがこのコードベースで作業するのは、どれだけ高くつくのか?

2026年10月28日、Nolan Lawson がそれを測る最初の本格的な試みを公開しました。結果は Hacker News のトップに載り、「Angular は 86% 高い」という投稿が 1 週間続きました。見出しは本当です。ですがデータセットの中でいちばん面白くない部分でもあります。

このページは慎重な読み方です。データの中の 3 つの発見が、この数字の引用のされ方と食い違っており、実験全体でいちばん実行に移しやすいレバーは、ベンチマークが検証しようとさえしていなかったものです。

実験

12 のスタック、1 つのアプリ、各 5 回の実行。

Guided walkthrough1 of 4

PokéAPI 上の Pokémon アプリを作る。検索、絞り込み、タイプ表示、複数のゲームバージョンにまたがるわざのデータ。著者はこれを、コンテンツ中心でインタラクティブ性は最小限と評しています。これを覚えておいてください。結果が何に一般化できるかを決めるのはこの点です。

中核となる結果は次のとおりです。コスト、トークン、コードサイズを、コストの中央値で並べています。

スタック	コスト (中央値)	コストのレンジ	トークン	コード行数	配信された JS
Hono+htmx	$2.67	$2.23–$3.19	4.26 M	1,370	18 KiB
Astro	$2.76	$2.16–$3.63	4.13 M	1,461	0 KiB
Nuxt	$2.82	$2.39–$4.25	3.85 M	1,415	84 KiB
Vanilla (Vite)	$2.98	$2.24–$3.37	5.00 M	1,492	7 KiB
Next.js	$3.14	$2.58–$4.13	4.99 M	1,539	142 KiB
Qwik	$3.27	$2.35–$3.80	5.64 M	1,744	40 KiB
TanStack Start	$3.54	$3.11–$3.96	7.07 M	1,697	118 KiB
SolidStart	$3.79	$2.84–$4.81	7.13 M	1,630	40 KiB
React Router	$3.81	$2.82–$3.97	7.58 M	1,564	115 KiB
SvelteKit	$4.28	$3.59–$4.65	8.53 M	1,611	36 KiB
Gracile+Lit	$4.65	$3.92–$5.07	9.04 M	1,717	8 KiB
Angular	$4.97	$3.19–$6.82	9.76 M	2,009	93 KiB

壁時計はコストによく連動しました。速い側では Astro が 8.2 分、Hono+htmx が 8.6 分、遅い側では Angular が 17.2 分です。

発見 1: トークンの請求は成果物ではなくループに連動する

開きを比べてみましょう。

トークン: 3.85 M (Nuxt) → 9.76 M (Angular) = 2.54 倍
コード行数: 1,370 (Hono+htmx) → 2,009 (Angular) = 1.47 倍

トークンの大半がエージェントのコードを書く作業なら、この 2 つの比は近くなるはずです。そうではありません。トークンの開きはコードの開きより 70% 以上広いのです。Angular が余分に消費した 590 万トークンは、余分に生んだ 639 行には使われていません。

それはループに使われました。ファイルを読み、編集のたびに読み直し、適合性スイートを実行し、失敗を解釈し、またやり直す。エージェントのトークン請求は、何回ぐるぐる回らなければならないか、そのたびにどれだけのコンテキストを引きずるかで決まります。 最終的な成果物は誤差です。

これで問い全体が組み替わります。「どのフレームワークがコードを少なく生むか」は弱い代理指標です。本当の問いは、どのフレームワークならエージェントがより少ないターンで収束できるか。それはファイル配置の予測しやすさ、エラーメッセージの読みやすさ、変更に必要な儀式の量、そしてそのフレームワークの現在のイディオムが学習データにどれだけ含まれているかの関数です。

What you'll learn

Angular の 2 回の完全な失敗は、コード品質の失敗ではなくループの失敗です。どちらの実行でも、リバースプロキシ配下でのデプロイが指示されていたにもかかわらず、エージェントは localhost 以外の接続を拒否する SSR アプリを作りました。これはエージェントがデプロイ上の制約を読み違えたもので、より鋭い CLAUDE.md が解決するたぐいの問題です。また、失敗を数えるだけでなく分類すべき理由でもあります。

発見 2: トークンあたりの実効レートは逆向きに動く

これは私が読んだどの要約にも載っていない発見で、誰も割り算しなかった 2 つの列を割ると出てきます。

各行について、コスト中央値 ÷ トークン中央値を取ります。

スタック	トークン	コスト	実効 $/Mtok
Nuxt	3.85 M	$2.82	$0.73
Astro	4.13 M	$2.76	$0.67
Hono+htmx	4.26 M	$2.67	$0.63
Next.js	4.99 M	$3.14	$0.63
Vanilla	5.00 M	$2.98	$0.60
Qwik	5.64 M	$3.27	$0.58
SolidStart	7.13 M	$3.79	$0.53
Gracile+Lit	9.04 M	$4.65	$0.51
Angular	9.76 M	$4.97	$0.51

トークン数が増えるにつれてレートは下がり、ほぼ単調です。最も多くのトークンを燃やすフレームワークが、トークンあたりでは最も少なく払っています。

なぜか。Opus 5.5 の定価は、新規入力が 1 MTok あたり $4、出力が $20、キャッシュ読み取りが $0.20 です。キャッシュ読み取りの倍率は 5% で、プラットフォームの標準は 10% です。$0.51 から $0.73 の混合レートは、$0.20 のキャッシュ読み取りの下限をわずかに上回る程度で、新規入力のレートのおよそ 6 分の 1 です。こうした数字を生む組み合わせは 1 つしかありません。カウントされたトークンの圧倒的多数がキャッシュ読み取りです。 純粋なキャッシュ読み取りに、新規と出力のトラフィックを約 11% 混ぜると $0.62 になり、8% にすると $0.50、つまり Angular の数字になります。

メカニズムはこうです。長いエージェントセッションでは、1 ステップ増えるたびに、増え続ける同じコンテキストが再生されます。その再生が $0.20 のキャッシュ読み取りです。重いフレームワークの限界トークンは、最初のトークンの 20 分の 1 のコストで、だから Angular の 2.54 倍のトークン数は、請求では 1.86 倍にしかなりません。

順位付けより重要な帰結が 2 つあります。

どの行でもプロンプトキャッシュが重い仕事をしています。 このベンチマークは、かなりの部分がキャッシュ読み取り量の測定です。有効なキャッシュを持たないエージェント構成では、同じトークンの開きが最大 20 倍のレートで請求に跳ね返り、フレームワーク間の差は縮まるどころか広がります。冗長なスタックに対する実際のリスクを知りたければ、まずキャッシュヒット率を確認してください。プロバイダー横断のプロンプトキャッシュとプロンプトキャッシュの経済学を参照してください。
ビルド単価は、重いスタックのペナルティを体系的に過小評価します。 キャッシュは、重いスタックが生み出すまさにそのものを吸収するからです。そして、本当に複利で効く数字の話につながります。

Watch out

この算術は著者のものではなく、私のものです。コスト中央値 ÷ トークン中央値は、実行ごとの比の中央値ではありませんし、2 つの列の中央値は別々の実行から来ていることもあります。実行ごとの真実ではなく、おおよその方向性を示す数字として扱ってください。方向は 12 行すべてで一貫しており、それが報告する価値のある理由です。

発見 3: レンジが重なるので、隣り合う組のほとんどは何も証明しない

Angular の最も安い実行は $3.19 でした。Hono+htmx の最も高い実行も $3.19 でした。同じです。

Nuxt は $2.39–$4.25、Astro は $2.16–$3.63、SolidStart は $2.84–$4.81 でした。確率的な 5 回の実行では、フレームワーク内のばらつきは、フレームワーク間の差と同程度か、しばしばそれより大きくなります。このデータセットから擁護できる主張は大まかなものです。

擁護できる: 軽量な MPA クラスター (Hono+htmx、Astro、Nuxt) は、重いクラスター (SvelteKit、Gracile+Lit、Angular) より、おおよそ 1.5〜1.9 倍安い。
擁護できない: 「Astro は Nuxt に勝つ」「SolidStart は React Router に勝つ」など、隣り合う組の主張。その差はノイズの内側にあります。

著者自身もそう述べています。目標は「決定版のベンチマークを書くこと」ではなく、証拠に基づく選定がそもそも可能だと示すことでした。彼の中央値を順位表に変換したブログ記事はレンジを落としており、誠実さが宿っているのはレンジのほうです。これは AI ベンチマークの読み方のページがモデルのリーダーボードに当てはめている規律と同じです。ばらつきのない中央値は、数字の皮をかぶった雰囲気です。

統制されていない交絡要因 — そして実際にあなたが持つレバー

方法論の中に埋もれているのが、実験の中でいちばん実行に移しやすい点です。各エージェントには、フレームワークの公式 MCP サーバーまたはスキルが提供されていました。それを使ったかどうかは大きくばらつきました。

スタック	公式の MCP / スキルを使った実行
SvelteKit	5 回中 5 回
Next.js	5 回中 1〜2 回 (ガイドファイルを読んだ)
TanStack Start	5 回中 2 回 (スキルを発見した)
Nuxt	5 回中 0 回 (MCP は一度も使われず)

少し考えてみてください。60 回の実行を通じて、ばらつきのかなりの部分は「このフレームワークがどれだけ高いか」ではなく、**「エージェントが目の前にあったドキュメントに気づいたか」**かもしれません。SvelteKit は毎回 MCP を使ったのに高コスト側の近くに着地し、Nuxt は MCP にまったく触れなかったのに 3 番目に安かった。この 2 つの事実だけでも、この表をきれいなフレームワークの順位として読むのは止めるべきです。

実務上の逆転はこうです。ドキュメントの発見はあなたが完全に制御できる変数で、フレームワークの選択はほとんど制御できない変数です。ビルドごとに $2 を節約するためにコードベースを移行する前に、ドキュメントを見逃せないものにしてください。

スキルが発見されるのを期待するのではなく、フレームワークの規約を CLAUDE.md に直接書く。CLAUDE.md テンプレートとジェネレーターを参照。
デプロイの制約を明示する。Angular の 2 回の失敗は、まさにこの隙間でした。
自分のフレームワークや社内ライブラリ向けに MCP サーバーやスキルを出しているなら、エージェントが実際に呼び出しているかを測る。5 回中 0 回しか使われないツールは、経済的には存在しないツールと同じです。

複利で効く数字: ビルドのコストではなく編集のコスト

ビルドは一度だけです。その後のすべてのタスクは、変更対象を理解するためにエージェントがコンテキストへ引き込まなければならないコード量に比例する税を払います。

そのため コード行数が持続する量になります。開きはトークンのそれより狭いものの永続的です。Hono+htmx の 1,370 に対して Angular は 2,009、つまり 将来のあらゆるタスクで、固定のコンテキスト税が永遠に約 32% 小さいということです。

これを発見 2 と組み合わせると、正しいメンタルモデルになります。ビルド時には、キャッシュがスタック間の差を圧縮します。保守の寿命全体では、タスクのたびに LOC の差を再び払うことになり、リポジトリのベースライン読み込みの多くは、キャッシュヒットではなく、新しいセッションの最初のターンの新規入力です。一度きりの $2.30 の差は誤差ですが、3 年間抱えるコードが 3 分の 1 多いことはそうではありません。

Watch out

これを「常に最も軽量なスタックを選べ」と読まないでください。コード行数は、コスト関数の 1 項にすぎません。状態同期のバグの一種を防ぐフレームワークは、コンテキストのコストよりはるかに多くのエージェントのループを節約するかもしれません。HN の上位コメントはまさにその主張をしており、AI コード生成のもとで htmx は状態のバグを捕まえるために広範なテストが必要になる一方、React は学習データでの存在感の大きさが、本当にインタラクティブなアプリでエージェントを助けると論じています。これは、このベンチマークのコンテンツ中心のアプリには見えない、実在する効果です。

これが証明していないこと

限界は重要な支えです。著者はその大半を挙げています。報道が落とした分を私が補いました。

限界	なぜ重要か
アプリの種類が 1 つ	コンテンツ中心でインタラクティブ性は最小限。ダッシュボード、エディタ、ゲーム、リアルタイムアプリでは、ここで MPA に有利に働くトレードオフが逆転します。
Lighthouse は MPA に有利	特に LCP はクライアントサイドルーティングを罰します。軽量なスタックがコストと Lighthouse の両方で勝つのは、一部は測定上のアーティファクトであり、独立した 2 つの勝利ではありません。
5 回の実行、高いばらつき	隣り合う行を分けるには足りません。Lighthouse 自体も実行ごとに一貫せず、異なる LCP 要素を選んでいました。
1 つのモデル、1 つの effort レベル	高 effort の Opus 5.5。より安いモデルや低い effort は、絶対額を変え、おそらく順序も変えます。
Chromium + モバイルのスロットリングのみ	CPU 4 倍、Slow 4G、1 つのブラウザ、1 台のノート PC。
保守タスクは測定されていない	上で論じた複利のコストは LOC の列からの推論であり、測定結果ではありません。保守ベンチマークを実行した人はまだいません。
人間の時間は値付けされていない	Angular の中央値 17.2 分と Astro の 8.2 分は、約 9 分の差です。エンジニアが実行を監督するなら、その 9 分間の注意は、$2.30 のトークン差の全額より高くつくでしょう。壁時計を無視して API 請求だけを最適化するのは、誤った目的関数です。

自分のスタックで実行する

このベンチマークの最大の強みは再現可能なことです。ハーネスも生の結果も公開されています。あなたのコードベースは Pokémon アプリではないので、判断を導くべき数字はあなた自身のものです。

Guided walkthrough1 of 6

ゼロからの構築ではありません。それは最もやる機会の少ないケースです。最近クローズした、典型的な大きさのチケットを 3 件選び、タスクセットにしてください。グリーンフィールドのベンチマークが測るのは、一度しかやらないことです。

自分のスタックでタスクのエージェントコストを測る

I want to measure how expensive a task is for you to complete in this codebase,
so I can compare stacks and tooling with evidence instead of vibes.

Task: <paste a real, closed ticket of typical size>

Rules:
1. Work only inside this repo. Do not install new dependencies.
2. Stop when the existing test suite passes for the changed behaviour.
3. Do not optimise for token use — work the way you normally would. I am
 measuring the honest cost, not a best case.

When you are done, report exactly:
- Files read, and how many times each was re-read
- Number of test/build invocations
- Lines added and removed
- Anything in the repo that made you go around an extra time: missing docs,
surprising file layout, an unclear error message, a convention you had to
infer. Be specific and name the file.

That last list is what I am really after. Rank it by how many turns each item cost you.

最後の質問が報われる質問です。あなたの規約のどれが余計に 3 回のループを要したかを知っているのはエージェントだけで、尋ねれば教えてくれます。その答えは CLAUDE.md の行に変わり、良い CLAUDE.md の 1 行はフレームワークの移行より価値があります。

Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。

1 / 8

Check yourself

0/5

ベンチマークでは Angular が Nuxt の 2.54 倍のトークンを消費しましたが、請求は 1.86 倍にとどまりました。この圧縮を説明するのはどれですか?
データセットのうち、実際に擁護できる比較はどれですか?
チームが、ここで成績の悪かったフレームワークからの移行を望んでいます。決断する前に、最もレバレッジの高い確認はどれですか?
寿命の長いプロジェクトで、エージェント時代のスタック判断において最も重く見るべき量はどれですか?
「軽量スタックがコストと Lighthouse の両方で勝った」が、聞こえるより弱い結果なのはなぜですか?

Key takeaways

エージェントのトークンコストは、生み出された行数ではなくループの回数に連動する。コードの開き 1.47 倍に対して、トークンの開きは 2.54 倍。
トークンあたりの実効レートは逆向きに動く ($0.73 → $0.51/Mtok)。追加のエージェントステップは $0.20 のキャッシュ読み取りとして請求されるから。キャッシュがペナルティの大半を吸収している。ビルド単価を信じる前にヒット率を確認すること。
レンジを報告するか、何も報告しない。Angular の最良の実行は Hono+htmx の最悪の実行と等しかったので、残るのは軽量対重量のクラスターという大まかな主張だけ。
ドキュメントの発見は統制されておらず、複数の行を説明しうる。直すのは無料で完全にあなたの制御下にある。移行の前にそれをやること。
複利で効く量を最適化する。一度きりのビルド請求ではなく、将来のタスクのたびに払う、結果のコードサイズ。
人間の監督下での壁時計の約 9 分の差は、トークンの $2.30 の差の全額より高くつく可能性がある。API 請求だけを単独で最適化しないこと。

出典とさらに読む

Nolan Lawson — The AI cost of JavaScript frameworks (2026年10月28日) — 一次情報: 方法論、すべての結果表、Angular の失敗、MCP/スキルの採用数、著者自身の注意書き
nolanlawson/agent-framework-benchmark — ベンチマークのハーネス本体。自分のスタックとモデルで再実行できる
nolanlawson/agent-framework-benchmark-results — 中央値の背後にある、わずかに伏せ字化された実行ごとの生の結果
Hacker News の議論 (item 50323088) — 読む価値のある反論: アプリの複雑さに関する「Figma ではない」という異論、htmx は軽量さから想像されるよりエージェントにとって難しいという主張、フレームワークを避けることの隠れた保守コスト
Anthropic — Prompt caching — キャッシュ読み取りの価格と TTL の挙動。発見 2 の背後にあるメカニズム
AILmanac 内の関連: プロバイダー横断のプロンプトキャッシュ — 適格性のしきい値と、キャッシュがそもそも役に立つかを決める損益分岐の規則
AILmanac 内の関連: プロンプトキャッシュの経済学 — 長いエージェントセッションでキャッシュ読み取りが最大の費目になる理由
AILmanac 内の関連: 騙されずに AI ベンチマークを読む方法 — モデルのリーダーボードに当てはめた同じ統計的規律
AILmanac 内の関連: エージェントがトークンを燃やす理由 — 発見 1 の背後にあるループレベルの仕組み

エージェントがトークンを燃やす理由 — 発見 1 の下にあるメカニズムを、個々のターンのレベルで
プロバイダー横断のプロンプトキャッシュ — このベンチマークで請求の大半を静かに払っているレバー
コーディングとソフトウェア開発 — この判断が収まる、より広いプレイブック
エージェントが書いたコードのための CI/CD — エージェントが安く速くなったら、次に壊れるのはパイプライン

このページを共有

実験​

発見 1: トークンの請求は成果物ではなくループに連動する​

発見 2: トークンあたりの実効レートは逆向きに動く​

発見 3: レンジが重なるので、隣り合う組のほとんどは何も証明しない​

統制されていない交絡要因 — そして実際にあなたが持つレバー​

複利で効く数字: ビルドのコストではなく編集のコスト​

これが証明していないこと​

自分のスタックで実行する​