Next.js 16.3 は AI エージェントに何を渡すのか: docs 同梱からエラー修正・Skills まで

はじめに

Next.js 16.3 の安定版が 2026 年 8 月 3 日に公開されました。公式が 16.0（2025 年 10 月）以来最大のアップデート と位置づけるリリースです。目玉は Instant Navigations ですが、この記事で取り上げるのは AI コーディングエージェント向けの機能のほうです。next dev を実行するだけで、Claude Code や Cursor に読ませるルールファイルと、インストールしたバージョンに合ったドキュメントをフレームワーク側が用意してくれます。この記事ではその仕組みと使い方を紹介します。

本記事の情報は 2026 年 9 月時点のものです。執筆時点の npm の latest は 16.3.4（2026 年 8 月 31 日公開）です。Next.js は頻繁にアップデートされるため、仕様が変わっている場合があります。 最新情報は Next.js 16.3 のリリースノート と 公式の AI エージェント向けガイド をご確認ください。

想定する読者は、Next.js を業務で使いながら、Claude Code や Cursor、Codex も日常的に使っている開発者です。本記事の内容は、create-next-app@latest（next 16.3.4）で検証用のプロジェクトを作り、実際に next dev を実行して確認しました。

公式ガイドが整理する 4 つのステップ

16.3 の AI 関連アップデートをまとめた公式ブログは、次の問いを立てています。

What would Next.js look like if it were designed primarily for agent-driven development? We're not all the way there yet, but we're getting closer with every release.

「エージェント駆動開発のために設計されていたら、Next.js はどんな姿になるのか。まだそこまで到達してはいないが、リリースごとに近づいている」という趣旨です。16.3 は、その問いに対する現時点の回答をまとめたリリースにあたります。

この流れは 16.3 で急に始まったものではありません。16.0 では、エージェントが Next.js の情報を取得するための Next.js DevTools MCP サーバーが追加されました（以下、DevTools MCP サーバー）。16.2 ではドキュメントのパッケージ同梱と実験的な next-browser が加わりました。16.3 の機能群は、その延長線上にあります。

これらの機能をどう組み合わせるかは、公式の AI エージェント向けガイドが 4 つのステップとして整理しています。

1. 同梱されたドキュメントの場所を教える（学習時の記憶ではなく、同梱された一次情報を読ませる）
2. ランタイムを見せる（動いているアプリの実際の状態を確認させる）
3. エラーを修正の起点にする（発生したエラーをそのまま修正の指示として渡す）
4. 複数ステップの作業を Skills に渡す（手順の決まった作業を手続きとして任せる）

ここからは、この 4 ステップの順に説明します。

next dev が書き出す AGENTS.md と CLAUDE.md

ステップ 1 で使うのが、パッケージに同梱されたドキュメント（bundled docs）です。next をインストールすると、node_modules/next/dist/docs/ にドキュメントが同梱されます。中身は 01-app/ 02-pages/ 03-architecture/ 04-community/ index.md で、公式サイトと同じ構造です。数えてみると .md / .mdx は 452 ファイルありました。オフラインでも読めますし、Next.js をアップグレードすれば docs も一緒に更新されます。

この docs の場所をエージェントに教えるのが AGENTS.md です。公式ガイドは create-next-app@canary を案内しています。実際に試したところ、@latest（next 16.3.4 が入ります）でも AGENTS.md と CLAUDE.md が生成されました。不要なら --no-agents-md を付けます。CLAUDE.md は @AGENTS.md の 1 行だけ、AGENTS.md は次の管理ブロックだけです。

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

# This is NOT the Next.js you know

This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in `node_modules/next/dist/docs/` (resolved from this file's directory; in monorepos the `next` package may not be visible from the repo root) before writing any code. Heed deprecation notices.

This block is written and re-added by `next dev` — verify at `node_modules/next/dist/server/lib/generate-agent-files.js`. Removing it from a diff only re-creates the uncommitted change; committing it with your work keeps the tree clean.

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

このブロックが伝えているのは「このバージョンはあなたの学習データとは違う、コードを書く前に node_modules/next/dist/docs/ を読め」という 1 点だけです。ブロックを消しても next dev が作り直すため、公式は差分から外さずそのままコミットすることを勧めています。既存プロジェクトでも扱いは同じで、管理ブロックがなければ next dev の起動時に生成されます。そのときのログは次のとおりです。

▲ Next.js 16.3.4 (Turbopack)
✓ Generated AGENTS.md and CLAUDE.md for AI agents. Set `agentRules: false` in next.config to disable.

上書きではなく upsert です。# Project rules とだけ書いた AGENTS.md を置いて next dev を実行すると、既存の内容はそのまま残り、末尾に管理ブロックが追記されました。このとき CLAUDE.md は作られませんでした。ログも Generated AGENTS.md for AI agents. と、AGENTS.md だけを報告します。generate-agent-files.js の分岐を読むと、AGENTS.md が既にあればそちらだけを更新し、両方が無いときにだけ両方を作る実装になっています。2 回目以降の起動では、ブロックが現行と同じなら何も変更しません。

生成条件は 12 種のエージェント検出

公式ガイドは、生成の条件を「AI コーディングエージェントが検出されると」としか書いていません。何をもって検出とするのか、実装を追いました。書き込み担当の generate-agent-files.js にあるのは、マーカー間を upsert する処理だけです。判定は server/lib/app-info-log.js の ensureAgentRulesForDev() にあります。エージェントでなければ何もせず、現行ブロックが既にあっても何もしません。

検出の本体は、Next.js が同梱する @vercel/detect-agent の determineAgent() です。次の 12 の条件を上から順に調べ、最初に一致したものを採用します。

順	見る環境変数 / 条件	判定
1	AI_AGENT（値がそのまま名前になる）	任意の名前
2	CURSOR_TRACE_ID	cursor
3	CURSOR_AGENT / CURSOR_EXTENSION_HOST_ROLE=agent-exec	cursor-cli
4	GEMINI_CLI	gemini
5	CODEX_SANDBOX / CODEX_CI / CODEX_THREAD_ID	codex
6	ANTIGRAVITY_AGENT	antigravity
7	AUGMENT_AGENT	augment-cli
8	OPENCODE_CLIENT	opencode
9	CLAUDECODE / CLAUDE_CODE	claude
10	REPL_ID	replit
11	COPILOT_MODEL / COPILOT_ALLOW_ALL / COPILOT_GITHUB_TOKEN	github-copilot
12	ファイル /opt/.devin の存在	devin

筆者の Claude Code のシェルには、AI_AGENT=claude-code_2-1-259_agent と CLAUDECODE=1 の両方が設定されていました。前者は Claude Code がバージョン付きで設定する値です。determineAgent() を呼ぶ 1 行を変数に入れておき、環境変数を 1 つずつ外しながら実行すると、表の優先順位どおりに結果が変わります。next を require するため、node_modules/next のあるプロジェクトのルートで実行します。

$ DETECT="require('next/dist/compiled/@vercel/detect-agent').determineAgent().then(r=>console.log(JSON.stringify(r)))"
$ node -e "$DETECT"
{"isAgent":true,"agent":{"name":"claude-code_2-1-259_agent"}}
$ env -u AI_AGENT node -e "$DETECT"
{"isAgent":true,"agent":{"name":"claude"}}
$ env -u AI_AGENT -u CLAUDECODE -u CLAUDE_CODE node -e "$DETECT"
{"isAgent":false}

1 回目は AI_AGENT の値がそのまま名前になり、AI_AGENT を外すと 9 番目の CLAUDECODE で claude と判定されます。両方を外すとエージェントではないと判定されます。

環境変数をすべて外した状態で next dev を実行すると、Generated ... の行は出ず、ファイルも作られませんでした。検出対象のエージェント経由で起動したときだけ生成されます。挙動を試したいだけなら AI_AGENT=anything next dev で十分です。

生成を止めたいときは next.config.ts に agentRules: false を書きます。公式はオンのままにすることを勧めています。

同梱 docs にないページの取り方

• nextjs.org/docs 配下は、URL の末尾に .md を付けるだけで plain Markdown として取得可能（Accept: text/markdown ヘッダーでも同様）
• 同梱 docs に含まれない /docs/messages 配下のページも、.md を付けることで Markdown として取得可能
• インデックスは /docs/llms.txt、全文の一括取得には /docs/llms-full.txt（いずれも llms.txt 規約に準拠）

たとえばインストール手順のページなら、/docs/app/getting-started/installation.md がそのまま Markdown で返ります。

冒頭の version: には、nextjs.org が配信している最新バージョン（執筆時点では 16.3.4）が入ります。読んでいる記述がどのバージョンのものかは、ここで分かります。ただし、プロジェクトに入れた Next.js のバージョンと一致するとは限りません。同梱 docs にあるページは、同梱 docs を読むほうが確実です。

ここまではエージェントに読ませる静的な情報でした。次は、動いているアプリの状態をどう取り出すかです。

エージェントにランタイムを見せる

同梱 docs が教えるのは、Next.js の仕様という静的な情報です。一方、いま動いているアプリの状態は dev サーバーとブラウザの中にあり、エージェントからは直接見えません。Next.js 16.3 はこの状態を、端末の出力、DevTools MCP サーバー、agent-browser の 3 つの経路でテキストとして取り出せるようにしています。エージェントに近いものから順に説明します。

まず端末で分かること

エージェントが最初に読むのは next dev の端末出力です。16.3 の端末出力には、次の 2 つの情報が含まれます。

1 つは接続先です。next dev は自分の PID とポート、URL を .next/dev/lock に書きます。

{"pid":42809,"port":3000,"hostname":"localhost","appUrl":"http://localhost:3000","startedAt":1789027497080}

同じプロジェクトで 2 つ目の next dev を起動すると、空いているポートでいったん立ち上がった直後に lock を検出し、終了コード 1 で終了します。そのとき既存サーバーの URL と PID、ログの場所を表示するので、エージェントは既存サーバーに接続するか kill して立て直すかを選べます。

⚠ Port 3000 is in use by process 42809, using available port 3001 instead.
▲ Next.js 16.3.4 (Turbopack)
- Local:         http://localhost:3001
✓ Ready in 326ms
⨯ Another next dev server is already running.
- Local:        http://localhost:3000
- PID:          42809
- Dir:          /path/to/project
- Log:          .next/dev/logs/next-development.log
You can access the existing server at http://localhost:3000,
or run kill 42809 to stop it and start a new one.

もう 1 つはブラウザの console です。console に出たエラーと警告は、既定で端末にも転送されます（16.2 の時点ではエラーのみでした）。next.config.ts の logging.browserToTerminal を true にすれば、すべての出力まで範囲を広げられます。エージェントがいつも読んでいる端末出力に、クライアント側の失敗も流れてくるわけです。

ただし端末に流れるのは、すでに起きたことの記録です。「このルートはいまコンパイルが通るか」のように現在の状態を知りたければ、問い合わせ先が別に必要です。

DevTools MCP サーバーに問い合わせる

その問い合わせ先が、dev サーバーの中で動く /_next/mcp エンドポイントです。next dev を実行するだけで起動し、ルートの一覧、サーバーログ、コンパイル状況などを返します。

16.3 では knowledge 系のツールを取り除き、MCP サーバーを小さくしました。代わりに入ったのが、プロジェクト全体を見る get_compilation_issues と、単一ルートだけを対象にする compile_route です。next build を実行しなくても、動いている dev サーバーがコンパイルの可否を答えます。実際に compile_route を呼ぶと、対象ルートの問題の有無だけが返りました。

$ curl -s -X POST http://localhost:3000/_next/mcp \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json, text/event-stream' \
    -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":
         {"name":"compile_route","arguments":{"routeSpecifier":"/products/[slug]"}}}'
event: message
data: {"result":{"content":[{"type":"text","text":"{\"routeSpecifier\":\"/products/[slug]\",\"issues\":[]}"}]},"jsonrpc":"2.0","id":1}

自前のエージェントクライアントから使う場合は、プロジェクト直下の .mcp.json に next-devtools-mcp を追加します。動いている dev サーバーはクライアント側が自動で見つけます。後述の Skills はこのエンドポイントを直接呼ぶため、この設定は必要ありません。

{
  "mcpServers": {
    "next-devtools": {
      "command": "npx",
      "args": ["-y", "next-devtools-mcp@latest"]
    }
  }
}

MCP が答えられるのは、フレームワークから見える範囲です。実際に何が描画され、クライアント側で何が起きているかは、ブラウザ側で確かめるしかありません。

agent-browser で描画結果を確かめる

agent-browser（vercel-labs）は、DOM、console、network、Web Vitals を構造化テキストで返す CLI です。16.2 の実験的な next-browser を統合したものです。

導入と起動

導入は、CLI 本体と、CLI が操作するブラウザの 2 段階です。後述の next-dev-loop skill は 0.31.1 以上を必要とします（執筆時点の npm の最新は 0.37.1）。

npm install -g agent-browser
agent-browser install

next dev が動いている URL を開くときに --enable react-devtools を付けると、React DevTools 相当の情報もテキストで取れます。skill 経由で起動する場合は自動で付きます。

agent-browser open http://localhost:3000/products/shoes --enable react-devtools

react tree でコンポーネントの構成を見る

開いたページの React ツリーは react tree で取り出せます。出力は次のとおりです（全 122 行のうち冒頭のみ）。

$ agent-browser react tree --json | jq -r .data.tree
# React component tree
# Columns: depth id parent name [key=...]
# Use `react inspect <id>` for props/hooks/state. IDs valid until next navigation.
0 12 - Root
1 13 12 HeadManagerContext.Provider
2 14 13 Root
3 15 14 ServerRoot
4 16 15 Context.Provider
5 17 16 AppRouter

ヘッダー行には、props や hooks は react inspect <id> で見ること、ID は次のナビゲーションまで有効であることが書かれています。読み手をエージェントと想定した出力です。

なお 0.37.1 では、--json を付けない react tree は ✓ Done の 1 行しか表示しませんでした。ツリー本体は JSON 出力の data.tree に入っているため、上の例では jq で取り出しています。

react suspense で修正の結果を検証する

ツリーを眺めるだけなら DevTools のパネルと変わりません。エージェントにとって役に立つのは、判断材料を返してくれるコマンドのほうです。

次の章で扱う Cache Components のエラーには、[stream] という修正候補があります（fetch を子コンポーネントに移して <Suspense> で包む）。これを適用すると端末のエラーは消えます。しかし、それで本当に静的なシェルが先に描かれるかは、端末と MCP のどちらを見ても分かりません。修正後のページで react suspense --only-dynamic を実行すると、まだ動的な境界がどこに残っているかと、その原因が返ります。

$ agent-browser open http://localhost:3000/products-stream/shoes --enable react-devtools
$ agent-browser react suspense --only-dynamic
# Suspense Boundary Analysis
# 1 dynamic holes (static boundaries hidden; pass without --only-dynamic to see them)

## Summary
- Top actionable hole: ProductPage - fetch (server-fetch)
- Suggested next step: Push the request-bound async work into a smaller leaf or split static siblings out of this boundary.
- Most common root cause: fetch (server-fetch) affecting 1 boundary
（以下、境界ごとの表と読むべきファイルの一覧が続く。全 22 行）

エラーを消しただけでは fetch を抱えた境界が 1 つ動的なまま残ること、そして次の一手（fetch をさらに小さなコンポーネントに移す、またはキャッシュする）が 1 コマンドで分かります。後述の Copy prompt が手順の 5 番と 6 番で求めている「再読み込みして描画を確認する」「シェルが空になっていないか確かめる」は、この出力で検証できます。

ここまでのコマンドは、エージェントも同じように実行します。端末の出力と agent-browser はエージェント自身のシェルで実行するだけで、特別な接続設定はありません。ただし、DevTools MCP サーバーだけは、skill を使わない場合に .mcp.json への登録が必要です。3 つをどの順で使うかまで含めてエージェントに渡すのが、後述の next-dev-loop skill です。

ここまでは状態を読ませる工夫でした。Next.js 16.3 はエラーそのものの形も、エージェント向けに作り替えています。

エラーを修正の起点にする

この章で扱うのは、Cache Components を有効にしたアプリで起きるエラーです。<Suspense> の外で、キャッシュしていないデータを await すると、そのルートはプリレンダーできず、エラーになります。Next.js 16.3 はこのエラーに、3 つの修正候補を必ず添えるようにしました。端末でも dev overlay でも next build でも、同じ 3 択が出ます。dev overlay ではさらに、選んだ修正をエージェント向けのプロンプトにまとめる Copy prompt ボタンが付きます。

端末に出る 3 択のエラー

next.config.ts に cacheComponents: true を書き、<Suspense> の外で await fetch() を呼ぶページを置きます。それを next dev で開いて確かめました。ページ自体は HTTP 200 で描画されますが、端末には次の出力が出ます。

Error: Route "/products/[slug]": Next.js encountered uncached data during prerendering.
`fetch(...)` or `connection()` accessed outside of `<Suspense>` prevents the route from being prerendered, blocking the page load and leading to a slower user experience.
Ways to fix this:
  - [stream] Provide a placeholder with `<Suspense fallback={...}>` around the data access
  - [cache] Cache the data access with `"use cache"` (does not apply to `connection()`)
  - [block] Set `export const instant = false` to allow a blocking route
Learn more: https://nextjs.org/docs/messages/blocking-prerender-dynamic
    at ProductPage (app/products/[slug]/page.tsx:5:21)

3 択の中身は次のとおりです。

• stream は <Suspense> で包んでプレースホルダーを出す
• cache は "use cache" でデータ取得をキャッシュする（connection() には使えない）
• block は export const instant = false でブロッキングを許容する

どれもトレードオフのある設計判断で、機械的な正解はありません。エラーが失敗の報告ではなく、ラベル付きの選択肢になっています。

Learn more の先の blocking-prerender-dynamic は、修正候補ごとに Patterns / Trade-offs / Gotchas という定型で書かれています。エージェントが読む前提の構成です。

dev overlay の Copy prompt

dev overlay の issues を開くと、同じ 3 つが横並びのカードで表示されます。各カードにコード例と Copy prompt ボタンが付きます。

Stream の Copy prompt を押したところ、クリップボードに入ったのは 49 行のプロンプトでした。冒頭はこの 1 行です。

Apply the [Stream] "Wrap in or move into Suspense" fix to the Next.js Insight raised in this project.

続く Steps には、次の 7 つの手順が並びます。

1. ブラウザを操作できる状態にする（未設定なら next-dev-loop skill を入れる）
2. 失敗箇所を特定し、勝手にスコープを広げない
3. 該当するエラーページの Patterns と Gotchas を読む
4. パターンを適用する
5. ブラウザで再読み込みして実際の描画を確認する
6. シェルが空になっていないか確かめる（<Suspense> を高い位置に置きすぎると、シェルはあるのに中身が全部ストリーミングになる）
7. 共有コード（レイアウトやサイドバー）を触ったなら、兄弟ルートも確認し直す

末尾には、エラー本体がそのまま埋め込まれます。メッセージ、3 つの修正候補、コードフレーム、Next.js version: 16.3.4 (Turbopack) までが 1 つのプロンプトに入ります。修正の対象と方針、そして検証の手順までが、まとめてエージェントに渡ります。

なお 公式ブログ の掲載例は、next-dev-loop の案内先として skills.sh を挙げています。検証した 16.3.4 が生成したプロンプトは GitHub のソース を指していました。

next build と CI ログでの見え方

同じコードで next build を実行すると、プリレンダーに失敗して exit 1 になります。ここでも同じ 3 つのラベル付きの修正候補が出ます。dev 版とは文言が少し違い、build 版は cookies() / headers() / params / searchParams まで列挙します。ソース位置の代わりに、next build --debug-prerender を使うよう促します。dev overlay のない CI ログを読むエージェントも、同じ修正候補を受け取れます。

ここで渡せるのは、エラー 1 件に対する修正です。複数のステップにまたがる作業には、Next.js 16.3 は別の受け皿を用意しています。

複数ステップの作業を Skills に渡す

Next.js 16.3 は Skills の位置づけも整理しました。方針は「フレームワークの知識は同梱 docs から得る。Skills は lookup ではなく workflow のためにある」です。App Router の規約やキャッシュ API を解説していた旧来の knowledge 系 Skills（vercel-labs/next-skills）は廃止されました。npx skills update を実行すると、インストール済みのものから削除されます。公式は、都度外部から取りに行く方式よりも、あらかじめ同梱した情報の方がベンチマーク成績で優れているという結果を挙げています（nextjs.org/evals）。

4 つの first-party Skills

代わりに提供されるのは、手順が決まった作業を回す 4 つの first-party Skills です。

Skill	何をするか
next-dev-loop	編集 → ブラウザ操作 → console / network / React ツリーの確認、という検証ループを回す。DevTools MCP と agent-browser の両方を使う
next-cache-components-adoption	Cache Components を有効化し、機能単位でルートを直していく。1 ブランチでまとめて進めるか、PR を分けるかを選べる
next-cache-components-optimizer	対象ルートについて「クリック時に見せたい UI」を失敗する instant() テストとして書き、それが通るまでリファクタする。通ったテストは一緒にコミットされる
next-partial-prefetching-adoption	Partial Prefetching を有効化し、全リンクが共通のローディングシェルを再利用する状態まで進める

導入コマンドはいずれも共通で、npx skills add vercel/next.js --skill <name> を実行します。Skills のソースは vercel/next.js の skills ディレクトリにあり、skills.sh からも参照できます。

next-dev-loop がまとめる 3 つの情報源

ランタイムの章で見た端末、DevTools MCP サーバー、agent-browser を、エージェントの作業手順として 1 つにまとめたのが next-dev-loop です。

作業の前に、skill はまず /_next/mcp を curl で直接呼び、使えるツールの一覧を取得します。MCP クライアントを経由しないため、.mcp.json の設定は必要ありません。続けて agent-browser を --enable react-devtools 付きで起動します。要求するバージョンは 0.31.1 以上です。

編集のたびに、skill は次の 4 つを順に確かめます。

1. コンパイルが通るか（get_compilation_issues）
2. サーバーとブラウザにエラーが出ていないか（/_next/mcp）
3. ページが意図どおりに動くか（agent-browser でページを操作する）
4. React の描画、状態、Suspense の境界がどうなっているか（React DevTools）

ランタイムの章で個別に実行した compile_route や react suspense は、この手順の中で使われるコマンドです。導入後は、エージェントに次のように指示します。

After every edit, verify the page still works at runtime using the next-dev-loop skill.

エラーから検証までを 1 ループにする adoption skill

next-cache-components-adoption は、前章の 3 択エラーとこの検証ループをつないだものです。機能 1 つごとに、次のループを回します。

1. ルートを開き、dev overlay に出た blocking のエラーを読む
2. エラーに付いた nextjs.org/docs/messages のページを開き、そこに書かれたパターンで修正する
3. 修正のたびにブラウザで確かめる

skill の本文は、ビルドが通ることや overlay からエラーが消えることを「ルートが実際に動く証明ではない」と書いています。静的なシェルと、その後にストリーミングされる中身という Cache Components の動作は、ランタイムでしか確認できないためです。この検証には next-dev-loop を使うことが強く推奨されています。使えない場合の代替手段（別のブラウザ自動化、ビルドのみ、人間への引き継ぎ）も優先順に列挙されています。

進め方は Incremental と Direct の 2 つから選びます。Incremental は、codemod で全ページとレイアウトをいったん検証対象から外してビルドを通します。そこでユーザーの確認を挟み、機能ごとのループへ進みます。Direct は cacheComponents: true を書いてそのままループに入り、ビルドが報告するブロッキングなルートを順に処理していきます。

同梱 docs でフレームワークの仕様を教え、ランタイムを読める形にし、エラーに修正候補を付ける。前の章までの 3 つの要素は、Skills の中では 1 つの手順として組み合わさっています。

まとめ

Next.js 16.3 の 4 ステップは、情報提供からランタイムの可視化、エラー訂正、作業委任までを一続きにするものです。その前提として、next dev が起動元のエージェントを環境変数から見分けます。同梱の docs は、その場所を AGENTS.md / CLAUDE.md が伝えます。DevTools MCP と agent-browser がランタイムを読める形にし、エラーは修正方針と Copy prompt を添えて出ます。複数ステップの作業は Skills が引き取ります。

最初の一歩は、自分のプロジェクトで next dev を実行して AGENTS.md が生成されるかを見ることです。生成されなければ、エージェント環境の外から起動しているか、agentRules: false が効いているか、すでに現行のブロックが入っているかのいずれかです。生成を確認できたら、複数ステップの作業を任せるために next-dev-loop を入れる段階に進めます。

ルールファイルを書いてフレームワークの癖を教え込むのは、これまで開発者の仕事でした。エージェント向けの情報提供をフレームワーク側が担う流れは、Next.js だけで終わらないのではないかと見ています。

参考リンク

• Next.js 16.3 リリースノート
• Next.js 16.3 の AI 向け改善の解説
• AI コーディングエージェント向けセットアップガイド（公式ドキュメント）
• Next.js DevTools MCP サーバー（公式ドキュメント）
• first-party Skills のソース（vercel/next.js）

hiraoku

暇があったらクライミングしているフロントエンドエンジニアです。

シナジーマーケティング株式会社では一緒に働く仲間を募集しています。