JavaScriptフレームワークのAI開発費用：比較と自分で測る方法
Nolan Lawsonが12種類のフレームワークを比べた実験では、Claude Codeが示す推定API費用の中央値はHono+htmxが最小、Angularが最大でした。費用、所要時間、トークン数、ソースコード行数を読み解き、MCPやスキルの利用状況と効果を区別します。キャッシュ、失敗した試行、受け入れテストを記録し、自分のプロジェクトで比較する手順も紹介します。
目次
コンテンツ中心のアプリでAIによる開発費用を抑えたいなら、Hono+htmxとAstroを比較候補にしてください。Nolan Lawsonのベンチマークでは、推定API費用の中央値が最も低かったのはHono+htmxの$2.67で、Angularは$4.97でした。既存のプロジェクトでは、フレームワークを変える前に代表的な変更作業で比較してください。
AI開発費用が最も低かったフレームワーク
この結果は、コンテンツ中心のアプリで試す候補を選ぶために使えます。Lawsonは2026年10月28日に実験を公開しました。公開された実行記録と測定結果では、Claude Code 2.1.310でclaude-opus-5-5を使い、effortをhighに設定しています。
各エージェントは、検索、絞り込み、詳細ページを備えた同じPokéAPIアプリを作成しました。次の表は、2026-11-06時点で公開されていた結果をまとめたものです。記載したバージョンは実験で使ったパッケージを示します。現在のインストールに推奨するバージョンではありません。
| フレームワークと検証時のバージョン | 推定API費用、USD中央値（最小–最大） | 所要時間（分） | トークン数（百万） | ソースコード行数 |
|---|---|---|---|---|
| Hono 4.13.14 + htmx 2.0.11 | $2.67 ($2.23–$3.19) | 8.6 | 4.26 | 1,370 |
| Astro 7.4.2 | $2.76 ($2.16–$3.63) | 8.2 | 4.13 | 1,461 |
| Nuxt 4.6.2 | $2.82 ($2.39–$4.25) | 9.0 | 3.85 | 1,415 |
| Vanilla（Vite 8.3.5使用） | $2.98 ($2.24–$3.37) | 10.1 | 5.00 | 1,492 |
| Next.js 16.4.3 | $3.14 ($2.58–$4.13) | 10.9 | 4.99 | 1,539 |
| Qwik 1.20.2 / 1.20.3 | $3.27 ($2.35–$3.80) | 10.7 | 5.64 | 1,744 |
| TanStack Start 1.169.4 | $3.54 ($3.11–$3.96) | 10.3 | 7.07 | 1,697 |
| SolidStart 2.1.0 | $3.79 ($2.84–$4.81) | 11.2 | 7.13 | 1,630 |
| React Router 8.5.0 | $3.81 ($2.82–$3.97) | 12.5 | 7.58 | 1,564 |
| SvelteKit 3.1.0 | $4.28 ($3.59–$4.65) | 10.8 | 8.53 | 1,611 |
| Gracile 0.11.0 + Lit 3.3.3 | $4.65 ($3.92–$5.07) | 12.1 | 9.04 | 1,717 |
| Angular 22.2.3 | $4.97 ($3.19–$6.82) | 17.2 | 9.76 | 2,009 |
各指標の中央値は個別に求めています。そのため、表の1行が、特定の1回の実行結果をそのまま示しているわけではありません。費用、所要時間、トークン数には、各フレームワークの5回の試行が含まれます。Angularのコード量は、3つのアプリから求めています。残る2つは、リバースプロキシ経由で測定できなかったためです。
トークン数には、セッション全体の未キャッシュ入力、キャッシュへの書き込み、キャッシュからの読み取り、出力を含めています。セッション中の累計であり、1回の入力の長さを表す値ではありません。ソースコード行数では、空行、JSON、ロックファイル、テスト、自動生成ファイル、提供されたデザインファイルのコピーを除外しています。コメント行は数えています。
ドルで示した数値は、Claude Codeが報告した推定API費用です。Lawsonはサブスクリプションを使っていたため、アプリを作るたびに実際に支払った金額ではありません。ホスティング費用や、人がレビューする時間も含まれていません。
丸められた中央値で計算すると、Angularとの差額は$4.97 − $2.67 = $2.30です。比率は4.97 / 2.67 ≈ 1.86で、この課題ではHono+htmxより約86%高い結果でした。
Next.jsとAstroの差は1回の開発あたり$0.38で、観測された費用の範囲は重なっています。Hono+htmxとAstroの差も$0.09にとどまります。この差を一般的な順位とみなすより、自分の課題で小さな比較実験を始める根拠にしてください。
SvelteKitとAngularの費用が高かった理由
追加の資料調査や、生成したアプリのコード量が影響した可能性はあります。ただし、この実験では、それぞれの要因が費用に与えた影響を切り分けていません。
Lawsonは、SvelteKitのエージェントが毎回v3移行ガイドを読んだと報告しています。その理由として、v3がモデルの学習データより新しい可能性を挙げています。公式の移行ガイドには、設定をViteへ移すなどの変更が記載されています。ただし、その資料からモデルの学習内容を確認することはできません。
Gracileでは、エージェントがリポジトリを複製したり、node_modules内のコンパイル済みファイルを調べたりしたとLawsonは報告しています。これは追加の調査作業です。このベンチマークは、その読み取りが費用の差のどれだけを占めたかまでは測っていません。
Angularのソースコード行数の中央値は2,009で、Hono+htmxは1,370でした。後者は前者の約68%で、Lawsonによる「約70%」という比較と整合します。ファイルが大きければ、将来の変更で読む量や編集する量が増える可能性があります。ただし、この実験では保守費用を測定していません。
合計トークン数の解釈にも注意が必要です。Nuxtは中央値が3.85百万トークンで最小でしたが、費用の中央値は最小ではありませんでした。キャッシュの使われ方によって、合計トークン数と費用の関係が変わります。費用を比較するときは、トークンの種類を分けて記録してください。
フレームワークのMCPサーバーやスキルは役立つのか
このベンチマークだけでは、MCPサーバーやスキルが費用を下げるかは判断できません。利用できるツールの使われ方には差がありましたが、各フレームワークで有効・無効を対にした比較は行っていません。
Lawsonは、公式ツールがある場合にはそれを導入しました。公式ツールがないフレームワークもありました。報告された利用状況には、次のような差があります。
| フレームワーク | 5回の試行で観測された利用状況 |
|---|---|
| Hono+htmx | HonoのSkillツールを5/5で使用 |
| SvelteKit | MCPを5/5で使用 |
| Nuxt | MCPを0/5で使用 |
| Next.js | スキルファイルを1/5で読み取り、AGENTS.mdを2/5で読み取り |
| TanStack Start | 同梱されたスキルファイルを2/5で発見 |
NuxtのMCPが使われなかったことは、そのMCPに効果がない証拠にはなりません。SvelteKitの費用が高かったことも、MCPが差を生んだ証拠にはなりません。ツールを導入したこと、実際に呼び出したこと、課題を完了する費用が下がったことは、別々に確認する必要があります。
現在のNext.jsの案内では、導入したバージョンに対応する資料と、作業を進めるためのスキルを区別しています。資料の読み取りをすべてMCP呼び出しとして数えるのではなく、エージェントが実際に使った情報源を記録してください。
自分で試すときは、claude mcp listまたは/mcpでサーバーが利用できるか確認し、その後で実際のツール呼び出しを調べてください。同じフレームワークについて、ツールなし、利用可能、利用を明示的に指示した場合を比較します。MCPのコンテキスト使用量を測るガイドでは、この比較を詳しく扱っています。
この実験だけでは判断できないこと
この結果は、コンテンツ中心の小さなアプリで候補を絞るための予備評価として使ってください。適用範囲を判断するときは、次の4点を考慮する必要があります。
- 対象の課題： 操作が少ないカタログは、複雑なエディター、ダッシュボード、ゲームを代表しません。画面をどのように描画するかという設計も、エージェントに任されていました。
- 試行数： 5回の結果から具体例や費用の範囲は分かりますが、差が小さい順位には不確実さが残ります。表の範囲は観測された最小値と最大値であり、統計的な信頼区間ではありません。
- 実行環境： 検証したモデル、エージェント、effortの設定はそれぞれ1種類です。Qwikは最初の試行後に
1.20.2から1.20.3へ変わりました。また、Gracile+Litを指定しても、Litを使わない実装が2つできました。 - 評価対象： モバイル向けのLighthouseによるページ読み込み測定では、すべての操作や本番環境の要件を評価できません。ソースコード行数は規模を示しますが、保守費用の予測精度を実証した指標ではありません。
Angularの例外にも注意してください。公開記録では、5回すべての受け入れテストが合格しています。一方、本番向けの測定は2回失敗しました。自分の実験でも、テストへの合格とデプロイの成功を分けて記録してください。
自分のプロジェクトでClaude Codeの費用を測る方法
まず候補を2つ選び、それぞれ新しい状態から3回ずつ試してください。結果が近ければ5回に増やします。これは小規模な比較実験の提案であり、新たに実施したベンチマークの結果ではありません。
1. 課題と開始時の状態をそろえる
範囲を限定した1つの機能を、同じ受け入れ条件で比較してください。既存の製品なら、現在のフレームワークを候補の1つに含めます。変更作業を測る場合は、両方の開始用プロジェクトを用意してから時間を測ります。ゼロからの開発を比べたい場合は、どちらも初期設定から測ってください。
SPEC.mdに具体的な課題を書きます。たとえば、同等のカタログページと同じ商品データのフィクスチャを用意し、次のように依頼します。大文字と小文字を区別しない検索を追加し、既存の商品データを使う課題です。再読み込み後もURLの検索条件を保持し、該当する商品がない場合も利用しやすく表示します。既存のルートと受け入れテストは変更しない条件です。
Add case-insensitive name search to the catalog.
Read products from the existing fixture.
Persist the search query in the URL across reloads.
Show an accessible empty state when nothing matches.
Keep existing routes and the acceptance tests unchanged.依存関係のバージョンを固定し、ロックファイルを保持してください。変更作業の試行では、開始前に依存関係をインストールします。どちらのプロジェクトでもnpm run buildとnpm testを実行できるようにしてください。受け入れテストは、変更されていないコピーを別に残します。
繰り返す試行では、開始時のソース、指示文、モデル、effort、権限、使用予定のフレームワーク用ツール、課金経路をそろえます。試行ごとに新しいコピーから新しい会話を始めてください。フレームワークの実行順を交互にし、キャッシュの使用状況も記録します。
挙動を変えうるユーザー指示、フック、プラグインも記録してください。元のアプリと既存の検証項目を使いたければ、Lawsonのベンチマーク実行基盤から始められます。
2. 実行記録と最終結果を保存する
Bashを使い、認証済みのClaude Codeとjqを用意してください。claude auth status --textで認証状態を確認します。必要なら、試行前にclaude auth loginでログインしてください。
試行は使い捨ての開発用コンテナで実行します。以下の許可リストは、ファイルの変更とシェルコマンドの実行を自動で許可します。予定しているMCPツールの呼び出しも、各試行環境で読み込まれる権限ルールで事前に許可してください。サーバーを接続するだけでは、呼び出しの許可にはなりません。
比較する条件ごとに、異なるtrial_labelを設定してください。この例は、公式資料にある非対話型CLIを使います。実行ごとに固有の出力ディレクトリを作り、記録を保存します。
trial_label=astro-01
trial_dir=$(mktemp -d "/tmp/${trial_label}.XXXXXX") || exit 1
claude --version > "$trial_dir/claude-version.txt"
git rev-parse HEAD > "$trial_dir/commit.txt"
trial_status=0
CLAUDE_CODE_EFFORT_LEVEL=high claude -p \
--model claude-opus-5-5 \
--max-budget-usd 10 \
--allowedTools "Read,Edit,Write,Bash" \
--output-format stream-json --verbose \
"Implement SPEC.md without changing dependencies or acceptance tests. Run npm run build and npm test. Report incomplete work." \
> "$trial_dir/session.jsonl" 2> "$trial_dir/stderr.log" \
|| trial_status=$?
printf '%s\n' "$trial_status" > "$trial_dir/exit-code.txt"
jq -s '
[.[] | select(.type == "result")] | last
| if . == null then error("No final result; record an incomplete run")
else {
session_id,
subtype,
is_error,
estimated_usd: .total_cost_usd,
reported_wall_minutes: (.duration_ms / 60000),
modelUsage,
permission_denials
} end
' "$trial_dir/session.jsonl" > "$trial_dir/summary.json"
cat "$trial_dir/summary.json"
printf 'Results: %s\n' "$trial_dir"$10という値は、予算の設定例です。--max-budget-usdは推定API費用を基に動作します。指定した上限を超えることもあります。すべての条件に同じ上限を適用し、予算による停止があれば記録してください。
2026-11-06時点では、CLAUDE_CODE_EFFORT_LEVELが--effortより優先されます。ただし、組織のeffort上限が設定されていれば、その制限は残ります。モデルを読み込めない場合は、比較を続ける前にOpus 5.5の設定を確認してください。
集計結果にはestimated_usd、reported_wall_minutes、modelUsage、およびpermission_denialsが含まれるはずです。estimated_usdは推定費用、reported_wall_minutesは報告された所要時間を分単位で示します。JSONL形式の実行記録には、確認用のツールイベントが保存されます。意図したモデルが記録されているか確認し、ほかのモデルも使われていれば記録してください。
3. 合格した結果を比較し、失敗した試行も残す
エージェントとサブエージェント全体のトークンを集計するには、modelUsageを使ってください。inputTokens、outputTokens、cacheReadInputTokens、cacheCreationInputTokensは、それぞれ分けて扱います。最終結果のusageフィールドには、サブエージェントの活動は含まれません。
最終結果の合計値は1回だけ読み取ってください。累積した結果同士を足し合わせると、重複して数えてしまいます。再開したセッションを、新しい試行として扱わないでください。
エージェントの報告とは別に、変更されていないテストと本番用ビルドを実行してください。依存関係やテストのファイルが変わっていないことも確認します。エージェントが成功を報告しても、アプリが仕様を満たした証拠にはなりません。
最終結果がない、または形式が壊れている場合は、stderr.logを確認してください。費用が不明な未完了の試行として記録し、費用をゼロと入力しないでください。MCPが使われなかった理由をエージェントの判断とみなす前に、権限拒否を解消してください。
各フレームワークについて、全試行に対する合格数、合格した試行の中央値と範囲、全試行の推定費用の合計を報告します。失敗した試行の費用も含め、合格した結果1件あたりの費用を次の式で求めてください。
Total quoted cost of all attempts / Number of accepted results
どれか1回でも費用が分からなければ、試行全体の費用は不完全だと明記してください。合格した結果がなければ、結果1件あたりの金額を算出せず、失敗と報告します。人がレビューに使った時間は別に記録してください。
手動のセッションでも、現在のClaude Codeの費用表示は/usageで同種の推定値を示します。コマンド一覧では、2026-11-06時点で/costをその別名として記載しています。サブスクリプションの利用枠や、接続先から実際に請求される料金は、この推定値と分けて考えてください。
小さなトークン節約よりレビューや移行の負担が大きければ、既存の技術構成を維持してください。別の候補が同じ検証に繰り返し合格し、維持管理を含む費用も許容できるなら、この判断を見直せます。
フレームワークを選んだ後で、別のモデルや接続経路を独立した実験で試してください。コーディングモデルの比較記事を使えば、フレームワークの試行で複数の条件を同時に変えずに、次の候補を選べます。
