Back to Blog — 公開日: 2026-03-18

投稿: Jude Gao (@gao_jude), Tim Neutkens (@timneutkens)

Next.js 16.2：AIの改善

Next.js 16.2 では、AI支援の開発を意識した複数の改善が行われました。これらの変更により、エージェントがプロジェクトを理解しやすくなり、ターミナルから問題をデバッグし、ブラウザを必要とせずに実行中のアプリを検査できるようになります。

主なポイント:

• Agent-ready create-next-app：AI対応プロジェクトを初期からスキャフォールド
• Browser Log Forwarding：ブラウザのエラーをターミナルに転送してエージェントによるデバッグを容易化
• Dev Server Lock File：同一プロジェクトで二つ目の dev サーバーが起動しようとしたときに実用的なエラーメッセージを表示
• Experimental Agent DevTools：AIエージェントに対してReact DevToolsやNext.jsの診断情報へのターミナルアクセスを提供（実験的）

Agent-ready create-next-app

create-next-app はデフォルトで AGENTS.md ファイルを含むようになり、AIコーディングエージェントがプロジェクト起点からバージョンに一致する Next.js ドキュメントにアクセスできるようになりました。これは AGENTS.md に関する調査に基づく改善で、ドキュメントを同梱してエージェントに常時参照させることで、Next.js の評価で 100% の合格率を達成しました。スキルベースのアプローチ（最大 79%）より優れていることが示されています。

主な洞察：常時利用可能なコンテキストはオンデマンド取得よりも有効です。エージェントはしばしばドキュメントを検索すべきタイミングを認識できません。

AGENTS.md は短い指示ファイルで、エージェントに node_modules/next/dist/docs/ に同梱されたドキュメントを必ず読むよう指示します。Next.js の npm パッケージは現在、プレーンMarkdownファイルとして完全なドキュメントを含んでおり、外部フェッチを行わずにローカルで正確なバージョン参照を提供します。

既存プロジェクトのセットアップは Next.js のバージョンに依存します。

• 16.2 以降: ドキュメントは既に next パッケージに同梱されています。プロジェクトルートに次の 2 ファイルを追加してください: AGENTS.md

  <!-- BEGIN:nextjs-agent-rules -->

  Next.js: ALWAYS read docs before coding

  Before any Next.js work, find and read the relevant doc in node_modules/next/dist/docs/. Your training data is outdated — the docs are the source of truth.

  <!-- END:nextjs-agent-rules -->

  コメントマーカーは Next.js 管理領域を区切ります。マーカーの外側にはプロジェクト固有の指示を追加できます — 将来の更新はマーカー間の内容のみを置き換えます。

CLAUDE.md は Claude Code 用の指示ファイルです。@ ディレクティブで AGENTS.md を追加コンテキストとして読み込むよう指示します:

CLAUDE.md
@AGENTS.md

• 以前のバージョンでは、codemod を使ってこれらのファイルを自動生成します。

  npx @next/codemod@latest agents-md

詳細は AI agents setup guide を参照してください。

Browser Log Forwarding

Next.js は開発中にブラウザのエラーをデフォルトでターミナルに転送するようになりました。これにより、ブラウザのコンソールに切り替えずにクライアント側のエラーを確認できます。これは主にターミナル経由で動作する AI エージェントにとって特に有用です。

• デフォルトではエラーのみがターミナルに転送されます。

• 転送レベルは next.config.ts の logging.browserToTerminal で制御できます。

  next.config.ts const nextConfig = { logging: { browserToTerminal: true, // 'error' — errors only (default) // 'warn' — warnings and errors // true — all console output // false — disabled }, };

  export default nextConfig;

Dev Server Lock File

Next.js は実行中の dev サーバーの PID、port、URL を .next/dev/lock に書き込みます。同一プロジェクトディレクトリで 2 つ目の next dev が起動すると、Next.js はロックファイルを読み込んで実用的なエラーを表示します:

Error: Another next dev server is already running.
- Local: http://localhost:3000
- PID: 12345
- Dir: /path/to/project
- Log: .next/dev/logs/next-development.log
Run kill 12345 to stop it.

これは既にサーバーが稼働していることを知らないまま next dev を起動しようとする AI コーディングエージェントに特に役立ちます。構造化されたエラーはエージェントに既存プロセスを終了する PID や接続先の URL を提供し、手動介入を不要にします。

ロックファイルはまた、同時に二つの next build プロセスが走るのを防ぎ、ビルド成果物の破損を避けます。

Experimental Agent DevTools

上記の機能はエージェントがプロジェクトを理解しデバッグするのを助けます。@vercel/next-browser はこれを拡張し、エージェントが実行中の Next.js アプリケーションを検査できるようにします。

next-browser は実験的な CLI で、スクリーンショット、ネットワークリクエスト、コンソールログといったブラウザレベルのデータに加え、React DevTools や Next.js のデベロッパーオーバーレイからのフレームワーク固有の洞察（コンポーネントツリー、props、hooks、Partial Prerendering (PPR) シェル、エラーなど）をシェルコマンド経由で構造化テキストとして返します。

LLM は DevTools パネルを直接読むことはできませんが、next-browser tree を実行して出力を解析し、次に何を調べるかを決定できます。各コマンドは永続的なブラウザセッションに対するワンショットリクエストなので、エージェントはブラウザ状態を自前で管理することなく何度もアプリをクエリできます。これによりブラウザはエージェントが推論可能な「アクセス可能な情報源」になります。

現時点で可能なこと

現時点で next-browser は次をサポートしています:

• React コンポーネントツリーの検査 — props、hooks、state、ソースマップされたファイル位置の表示
• PPR シェルの解析 — 静的領域と動的領域、ブロックされた Suspense 境界の特定
• エラーとログへのアクセス — dev サーバーからのビルド・ランタイムの問題を取得
• ネットワーク活動の監視 — ナビゲーション以降のリクエスト追跡（server actions を含む）
• ビジュアルの取得 — スクリーンショットやロード時のフィルムストリップの録画

Getting started

スキル（AI エージェントが再利用できる能力）としてインストールします:

npx skills add vercel-labs/next-browser

その後、Claude Code、Cursor、またはスキルをサポートする任意の AI エージェントで /next-browser を入力してください。CLI は Chromium インスタンスを管理し、React DevTools が事前ロードされるためブラウザ設定は不要です。

例：静的シェルを大きくする（Growing the static shell）

Partial Prerendering (PPR) により、Next.js はエッジから静的シェルを即時で返し（リクエストごとに変わらない部分）、残りをストリーミングしていきます。シェルに収まるコンテンツが多いほど、ユーザーは意味のあるページを早く見ることができます。

実際には、単一の per-request フェッチが誤ってページ全体を動的にしてしまうことがあります。例えば訪問者カウンターがあるブログ記事を考えてみます:

app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
  const views = await getVisitorCount(params.slug); // per-request
  return (
    <article>
      <h1>{post.title}</h1>
      <span>{views} views</span>
      <div>{post.content}</div>
    </article>
  );
}

generateStaticParams で全ての slug を列挙しているため、記事内容自体はビルド時にプリレンダ可能です。しかし getVisitorCount が各リクエストで実行され、それがコンポーネントのトップレベルにあるためページ全体が動的になってしまいます。その結果、ページ全体がロードスケルトンの後ろで待たされ、逐次的にストリーミングされません。

エージェントは next-browser を使って原因を診断できます。PPR モードをロックすると静的シェルのみが表示されます — この例では app/blog/[slug]/loading.tsx のスケルトンだけが見えるはずです:

next-browser ppr lock
# Enter PPR mode
next-browser goto /blog/hello
# The entire page is a loading skeleton

その後、エージェントは ppr unlock を実行して何が問題かを特定します:

next-browser ppr unlock

出力例:

# PPR Shell Analysis
# 1 dynamic hole, 1 static blocked by:
- getVisitorCount (server-fetch)
  owner: BlogPost at app/blog/[slug]/page.tsx:5
  next step: Push the fetch into a smaller Suspense leaf

このレポートはエージェントに具体的な修正方法を示します: getVisitorCount がブロッカーであり、BlogPost に属している。対処法はそれを小さい Suspense に押し込むことです。エージェントはカウンター部分だけをラップします:

app/blog/[slug]/page.tsx
export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
  return (
    <article>
      <h1>{post.title}</h1>
      <Suspense fallback={<span>— views</span>}>
        <VisitorCount slug={params.slug} />
      </Suspense>
      <div>{post.content}</div>
    </article>
  );
}

再度 ppr lock を実行するとシェルが拡大していることが確認できます — 記事内容がプリレンダされ、訪問者カウントのみがフォールバックを表示します。

next-browser はまだ進化中ですが、エージェントが開発者と同等の可視性でアプリをデバッグ・最適化できる将来を指し示しています。

フィードバックとコミュニティ

フィードバックを共有して Next.js の未来を形作る手助けをしてください:

• GitHub Discussions
• GitHub Issues
• Discord Community