Next.js 16.2: AI Improvements

claudejamodel: claude-sonnet-4-20250514

Next.js 16.2: AI機能の改善

投稿者: Jude Gao @ gao_jude、Tim Neutkens @ timneutkens
公開日: 2026年3月18日（水）

Next.js 16.2には、AI支援開発向けに設計されたいくつかの改善が含まれています。これらの変更により、エージェントがプロジェクトを理解し、ターミナルから問題をデバッグし、実行中のアプリを検査することが容易になります — すべてブラウザを必要とせずに実行できます。

Agent対応のcreate-next-app: すぐに使えるAI対応プロジェクトの構築
ブラウザログ転送: エージェント駆動デバッグのためにブラウザエラーをターミナルに転送
開発サーバーロックファイル: 2つ目の開発サーバーが起動しようとした際の実行可能なエラーメッセージ
実験的Agent DevTools: AIエージェントにReact DevToolsとNext.js診断へのターミナルアクセスを提供

Agent対応の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: コーディング前に必ずドキュメントを読む

Next.jsの作業を行う前に、`node_modules/next/dist/docs/`で関連するドキュメントを見つけて読んでください。
あなたの訓練データは古い可能性があります — ドキュメントが真実の情報源です。
<!-- END:nextjs-agent-rules -->

コメントマーカーはNext.js管理セクションを区切ります。マーカーの外側に独自のプロジェクト固有の指示を追加できます — 将来の更新では、マーカー間のコンテンツのみが置き換えられます。

CLAUDE.mdはClaude Codeの指示ファイルです。@ディレクティブは、AGENTS.mdを追加のコンテキストとして含めるよう指示します：

CLAUDE.md

@AGENTS.md

以前のバージョンの場合、codemodを使用してこれらのファイルを自動生成します：

npx @next/codemod@latest agents-md

詳細については、AIエージェント設定ガイドを参照してください。

ブラウザログ転送

Next.jsは開発中にブラウザエラーをデフォルトでターミナルに転送するようになり、ブラウザコンソールに切り替えることなくクライアントサイドエラーを確認できます。これは、主にターミナルを通じて動作し、ブラウザコンソールにアクセスできないAIエージェントに特に役立ちます。

デフォルトでは、エラーのみがターミナルに転送されます。next.config.tsのlogging.browserToTerminalで転送レベルを制御できます：

next.config.ts

const nextConfig = {
  logging: {
    browserToTerminal: true, // 'error' — エラーのみ（デフォルト）
                            // 'warn' — 警告とエラー
                            // true — すべてのコンソール出力
                            // false — 無効
  },
};

export default nextConfig;

開発サーバーロックファイル

Next.jsは実行中の開発サーバーのPID、ポート、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を取得できます — 手動介入は不要です。

ロックファイルは、2つのnext buildプロセスが同時に実行されることも防ぎ、ビルドアーティファクトの破損を回避します。

実験的Agent DevTools

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

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

LLMはDevToolsパネルを読むことはできませんが、next-browser treeを実行し、出力を解析して、次に何を検査するかを決定できます。各コマンドは永続的なブラウザセッションに対する一回限りのリクエストなので、エージェントはブラウザの状態を管理することなく、アプリを繰り返しクエリできます。

これにより、ブラウザはエージェントがアクセスできないUIではなく、エージェントが推論できるものに変わります。

現在できること

機能セットは急速に進化しています。このリリース時点で、next-browserは以下をサポートしています：

Reactコンポーネントツリーの検査 — props、hooks、state、ソースマップされたファイル位置の表示
PPRシェルの分析 — 静的vs動的領域とブロックされたSuspense境界の識別
エラーとログへのアクセス — 開発サーバーからのビルドおよびランタイム問題の取得
ネットワーク活動の監視 — ナビゲーション以降のリクエスト（サーバーアクションを含む）の追跡
ビジュアルのキャプチャ — スクリーンショットの撮影またはローディングフィルムストリップの記録

開始方法

スキル（AIエージェント用の再利用可能な機能）としてインストールします：

npx skills add vercel-labs/next-browser

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

例：静的シェルの拡張

Partial Prerendering（PPR）により、Next.jsはエッジから静的シェル（リクエストごとのデータに依存しないページの部分）を即座に提供し、残りをストリーミングできます。静的シェルに含まれるコンテンツが多いほど、ユーザーは意味のあるページをより早く見ることができます。

実際には、単一のリクエストごとの取得により、ページ全体が誤って動的になることがあります。訪問者カウンター付きのブログ投稿を考えてみましょう：

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); // リクエストごと
  
  return (
    <article>
      <h1>{post.title}</h1>
      <span>{views} views</span>
      <div>{post.content}</div>
    </article>
  );
}

すべてのslugはgenerateStaticParamsで列挙されているため、投稿コンテンツはビルド時にプリレンダリングできるはずです。しかし、getVisitorCountはすべてのリクエストで実行され、コンポーネントのトップレベルにあるため、ページ全体を動的にします。

結果として、ページ全体が段階的にストリーミングされる代わりに、ローディングスケルトンの後ろで待機します。

エージェントはnext-browserを使用してこれを診断できます。PPRモードをロックすると静的シェルのみが表示されます — この場合、ページの何も静的シェルに含まれなかったため、app/blog/[slug]/loading.tsxスケルトンが表示されます：

next-browser ppr lock # PPRモードに入る
next-browser goto /blog/hello # ページ全体がローディングスケルトン

エージェントは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の未来を形作るのにご協力ください：

Summary