Next.jsのバンドル削減をAIエージェントに任せる｜next-bundle-optimizerの試し方と任せる範囲

「サイトが重い」と言われたとき、どのファイルが何KBで、なぜ読み込まれているのかを説明できる人は、保守の現場でもそう多くありません。Next.jsは2026年10月28日の公式ブログで、この調査をAIエージェントに任せるための仕組みを公開しました。next-bundle-optimizer というエージェント用スキルと、人が使うBundle Analyzerの新機能です。

この記事では、公式の手順を確かめたうえで、私たちの自社サイト（このnextjs.zetlinker.com）を実際に監査して何が出たかを示し、AIに任せてよい範囲と人が決める範囲を整理します。Next.jsで動くシステムを保守している、または保守を外部に頼んでいる情シス担当の方に向けた内容です。

先に、要点をまとめます（2026年11月10日確認）。

• 条件は Next.js 16.4以降とTurbopack（16系の既定バンドラー）です。導入は npx skills add vercel/next.js --skill next-bundle-optimizer の1コマンドで、エージェントからは /next-bundle-optimizer で呼びます
• 既定は 監査（audit）モード で、コードは変えません。候補と根拠を報告するところで止まり、修正は fix を明示したときだけ行います
• 自社サイトを監査したところ、記事ページでMarkdownの解析処理（圧縮後約58KB）がブラウザ側に入っていること、package.json にある3つの重いライブラリがどのページでも使われていないことが分かりました。どちらも「直すかどうか」は人の判断が要る種類の発見でした

next-bundle-optimizerは何をするスキル？

Turbopackのモジュール依存グラフをエージェントに読ませ、ブラウザに送るJavaScriptのうち「初期表示に要らないのに読み込まれている塊」を見つけて、切り離す境界まで提案するスキルです。

Next.jsは16.1でTurbopackのBundle Analyzer（next analyze）を出し、16.4でその解析データを next analyze export でJSON Lines形式に書き出せるようにしました。スキルは、この書き出しをエージェントに読ませる手順書です。公式ブログの例が分かりやすいので引用します。

'use client';
import { lazy } from 'react';

export const HeavyComponentLoader = lazy(() => import('./HeavyComponent'));

このように遅延読み込みにしたつもりでも、同じバンドルの中の別のモジュールが ./HeavyComponent を普通に import していれば、そのコードは最初から読み込まれます。人が目視で全ファイルの import を追うのは現実的でないため、エージェントに依存グラフを渡して探させる、というのがこのスキルの発想です。

スキルの中身（SKILL.md）を読むと、手順は次の6段階です。

1. 範囲を決める: 既定は全ルート。監査か修正かを決め、監査が既定
2. 計測して書き出す: next analyze --output --snapshot <名前> で保存し、next analyze export でグラフを書き出す
3. 読み解く: インストール済みNext.jsのスキーマ定義を参照して、ルートごとのクライアント／サーバーの寄与を数える
4. 候補を説明する: 大きな塊（コミュニティ）を見つけ、どの import を切れば切り離せるか（最小カット）を求め、実際のソースで裏を取る
5. 1件ずつ直して再計測する（修正モードのみ）: 別名のafterスナップショットを取り、同じ尺度でbeforeと比べる。型チェックと動作テストを通す
6. 報告して止まる: スナップショット名、差分、該当箇所、テスト結果、確認できなかった点を分けて書く

探す対象は、公式ブログとスキルの参照資料によると次の4種類です。

公式ブログには、Vercel社内でこのスキルを使った結果として、v0とvercel.comのページから合計で約2MB（圧縮後）のJavaScriptを削った、または遅延させたとあります。v0の例では、実験中のコードエディタがほぼ全ページで読み込まれていて150KB、ダイアログの登録表が重いダイアログを先読みしていてページにより40〜650KB、といった内訳が示されています。これはVercel社の数字で、自社のアプリで同じ量が出るわけではありません。

使う前に満たす条件は？

Next.js 16.4以降で、Turbopackでビルドしていること、そしてスキルを読めるコーディングエージェント（Claude Code・Cursor・Codexなど）があることです。16.3以前のアプリは、先に16.4へ上げる必要があります。

• Next.js 16.4以降: next analyze export とスキルは16.4.0で追加されました。2026年11月9日に16.4.6が出ており、記事執筆時点の最新安定版はこれです（16.4.6の内容はRoute Handlerの応答の自動圧縮と、開発時のTurbopackのメモリ回収の修正で、セキュリティ修正ではありません）
• Turbopack: 解析器はTurbopackのモジュールグラフを使うため、webpackでビルドしている構成では使えません。16系ではTurbopackが既定なので、next.config で明示的にwebpackへ戻していなければ条件を満たします
• エージェント: スキルの導入に使う skills CLIは、Claude Code・Cursor・Codexを含む複数のエージェントに対応しています。私たちはClaude Codeで試しました。-a claude-code を付けて実行すると、./.claude/skills/next-bundle-optimizer/ に SKILL.md と参照資料3ファイルが置かれ、skills-lock.json が作られました。導入時には第三者のセキュリティ評価（Gen・Socket・Snyk）の結果が表示され、最後に「スキルはエージェントと同じ権限で動くので、使う前に内容を確認してください」という注意が出ます

16.3系や15系で止まっているアプリは、まず16.4へ上げることになります。上げ方はNext.js 15から16への移行手順と、16.4で変わった点と既存アプリでやることにまとめています。11月3日のセキュリティ修正も、16系では16.4.5にしか入っておらず16.3系向けの修正版は出ていません（15系は15.5.29）。バンドル削減のためというより、セキュリティ修正を受け取るために上げる、と考えたほうが順番として自然です。

自社サイトで監査すると何が出た？

記事ページでMarkdown解析のライブラリ群（圧縮後約58KB）がブラウザ側に入っていること、package.json にある3つの重いライブラリが14ルートのどこでも使われていないことが分かりました。一方で、ページ固有のコードはどのルートも数KB台で、削る余地の中心はアプリ側の書き方ではなく「置き場所」でした。

Next.js 16.4.4で動いている自社サイトに対して、2026年11月10日に次を実行しました。解析は2.3秒で終わり、書き出しは18,393行（14ルート分）でした。

npx next analyze --output --snapshot before --experimental-app-only
npx next analyze export --snapshot before > graph-before.jsonl

書き出したグラフから、ルートごとのクライアントJavaScript（圧縮後）を集計した結果が次の表です。

ここから読み取れたことが3つあります。

1つ目は、記事ページのMarkdown解析です。 記事本文を描画するコンポーネントが 'use client' で、react-markdown とその依存（micromark・mdast・hastなど）がブラウザに送られていました。本文はビルド時に決まる静的な内容なので、サーバー側で変換してHTMLだけ送れば、この約58KBはブラウザから消せます。これは公式ドキュメントが「重いクライアント処理」として挙げている型そのものでした。ただし、見出しにidを付ける処理がこのコンポーネントに同居しているため、移す際は目次リンクが壊れないことの確認が要ります。

2つ目は、使われていない依存です。 package.json にある three（3D描画）、chart.js、@tiptap/*（エディタ）は、14ルートのどのクライアント出力にも現れませんでした。ソースを検索しても import している箇所がなく、過去に使って外した名残と分かりました。バンドルには影響していませんが、使っていない依存にも npm audit の警告は付きます。これは「バンドル削減」ではなく「依存の棚卸し」の課題として、別に扱うことにしました。

3つ目は、数字の読み方への注意です。 解析結果には、next/font が生成した149個のフォントファイル（woff2、合計約5.8MB）が全ルートに紐づいて出てきます。これはビルド成果物としての紐づきで、ブラウザが実際に取得するのはページ内の文字に必要な範囲だけです。スキル自身も「解析結果はビルド上の証拠であり、ブラウザの通信量や表示時間の主張には別の証拠が要る」と明記しています。AIの報告に大きな数字が出ても、転送量や体感速度の改善量とは分けて読む必要があります。

今回は監査モードで止め、修正は入れていません。1つ目の候補は、次の保守作業で動作確認とセットで対応する予定です。

人の作業はどこに残る？

「直すかどうか」「見た目や動きが変わる変更を許すか」「直した結果を本番相当で確かめたか」の3つは、スキルの規定上も人の側に残ります。AIが肩代わりするのは、依存グラフを読んで候補と根拠を揃える部分です。

スキルの SKILL.md には、エージェントの振る舞いを縛る記述がいくつもあります。保守を任せる側が知っておくと、報告の読み方が変わります。

特に3行目は、AIに任せるときに見落としやすい点です。遅延読み込みに変えた機能は、操作したときに初めて読み込まれるようになります。検索欄の入力遅延、編集画面の初回表示、ダイアログを開いた直後の動きなど、人が実際に触って確かめないと分からない変化が出ます。スキルも、ソースの目視・型チェック・ビルド成功だけでは動作を確認したことにならない、と書いています。

AIに任せる作業の粒度をどう切るかは、Claude Code × Next.js 16で受託開発はどう変わったかで書いた「1回の指示を1つの機能に区切り、都度レビューを挟む」という運用と同じです。このスキルは、その運用をバンドル最適化という作業に対して、手順の形であらかじめ書いてくれているものと捉えています。スキルや AGENTS.md のような「AIへの指示ファイル」がフレームワーク側から配られるようになった流れは、Next.js 16.2のAGENTS.mdとブラウザログ転送で整理しています。

発注側は保守会社に何を頼み、何を確認する？

頼むのは「監査レポート」で、確認するのは「ルートごとの圧縮後KB」「候補ごとの根拠と動作確認の方法」「実測の表示速度とは別の数字であること」の3点です。削減量の約束を先に求めると、根拠の薄い変更を増やす動機になります。

バンドル削減は、見積もりに「○○KB減らします」と書ける種類の作業ではありません。候補が出るかどうかはアプリの作り次第で、私たちの自社サイトでも、ページ固有のコードは数KB台で削る余地がほとんどなく、残ったのは「置き場所」の問題でした。保守会社に頼むなら、次の順番が現実的です。

1. まず監査だけを頼む: next analyze --output と next analyze export の結果と、スキルの監査レポートを受け取る。ここではコードを変えないので、本番への影響はありません
2. レポートで3つを見る: ルートごとのクライアントJS（圧縮後KB）、候補ごとの根拠（どのファイルがどの import 経由で入っているか）、修正したときに動作確認をどうするか。数字が「ビルド上の寄与」なのか「ブラウザの転送量」なのかも分けて書かれているかを見ます
3. 直す候補を一緒に選ぶ: 利用者が多いページ、初期表示に効く候補、動作確認の手間が小さい候補から。管理画面のように利用者が限られるページは後回しでかまいません
4. 修正は1件ずつ、本番相当の環境で確認してから: afterスナップショットの差分と、触って確かめた結果の両方を受け取ります

画像・データ取得・バンドルという3つの切り口のうち、どこから手を付けるかの全体像はNext.jsのパフォーマンス改善はどこまで自動かで整理しています。バンドルの削減は、そのうちの1つが機械の助けを借りやすくなった、という位置づけです。

まずは、保守を頼んでいる会社に「next analyze の結果を見せてもらえますか」と聞いてみてください。16.4以降で動いていれば、解析自体は数秒から数分で終わります。その結果を一緒に見ることが、何をAIに任せ、何を人が決めるかを話し合う最初の材料になります。

まとめ

• next-bundle-optimizer は、Turbopackの依存グラフをAIエージェントに読ませて、初期表示に要らないJavaScriptの候補と切り離す境界を提案させるスキルです。条件はNext.js 16.4以降とTurbopack
• 既定は監査モードでコードを変えません。修正は明示したときだけで、1件ずつ直して別名のスナップショットで再計測し、動作テストを通したものだけ残す手順が定められています
• 自社サイトの監査では、記事ページのMarkdown解析（約58KB）のサーバー側への移動と、使われていない依存3件の棚卸しが候補として出ました。フォントのように、ビルド上の数字と実際の転送量が違う項目もあります
• 発注側が確認するのは、ルートごとの圧縮後KB、候補ごとの根拠、動作確認の方法の3点です。削減量の約束より先に、監査レポートを受け取ることから始めます

自社のアプリで next analyze の結果をどう読めばよいか分からない、16.3以前で止まっていて上げ方から相談したい、という場合は、現状のバージョンと構成を伺うところからお手伝いしています。

※本記事は、2026年11月10日時点のNext.js公式ブログ「Ship less JavaScript in Next.js with your AI agent」（2026年10月28日）、公式ドキュメント「Optimizing package bundling」、Next.js CLIリファレンス、skills.shのnext-bundle-optimizerのページ、vercel/next.jsリポジトリの skills/ ディレクトリ、v16.4.6のリリースノートと、自社サイト（Next.js 16.4.4）での実行結果に基づいています。自社サイトの数字は圧縮後のサイズで、解析結果の集計値です。ブラウザの実際の転送量や表示時間の計測値ではありません。