DocsDigest
Back to listLanguage: JA
OpenAINext.jsFeb 12, 2026, 12:00 AM

Building Next.js for an agentic future

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

openaienmodel: gpt-5-mini-2025-08-07

Building Next.js for an agentic future

next.jsagentsmcpdevtoolsloggingcodemoddocs

Key Points

  • MCP exposes runtime and framework state to agents
  • Vector prototype proved visibility + framework knowledge matters
  • Run npx @next/codemod to generate agents.md

Summary

Next.js teams focused on making frameworks visible and useful to AI agents. They prototyped an in-browser agent (Vector), then shifted to surfacing runtime and framework state directly from Next.js via MCP and devtools so external agents can discover and act on live app context. Key practical outcomes: structured error/log visibility, an agents-oriented docs index, and tooling to make agent workflows repeatable.

Key Points

  • Problem: general coding agents can’t see browser runtime state (runtime errors, client-side warnings, rendered segments), so prompts like “fix the error” lack necessary context.
  • Prototype: built Vector (in-browser chat agent) to select elements, view source, and suggest fixes; useful but redundant with external coding agents, so it was sunset.
  • MCP integration: next-devtools-mcp exposes internal Next.js state (errors, routes, rendered segments) and enables agent discovery and communication with running dev servers.
  • Visibility and knowledge: added structured error forwarding (browser → terminal), Server Action invocation logging, and a compressed docs index (agents.md) and Next.js skills to reduce agent hallucination.
  • Tooling and adoption: npx @next/codemod can generate a docs index for projects; an expanded eval suite will measure which Next.js 16 APIs help agents most.
  • Roadmap: integrate agent-aware context into next dev so agents receive the right runtime and docs context automatically.

Practical steps for engineers

  • Generate a project docs index: run npx @next/codemod to produce agents.md.
  • Enable or adopt next-devtools-mcp to expose runtime state to external agents and devtools.
  • Forward browser logs and enable Server Action logging in your dev environment so agents can read runtime hints.
  • Monitor the Next.js eval suite updates and plan to adopt integrated agent-context features when they land in next dev.

Full Translation

Translations

A translation section that keeps the flow of the original article.

openaijamodel: gpt-5-mini-2025-08-07

エージェント主導の未来のための Next.js の構築

Building Next.js for an agentic future

Posted by Jiachi Liu (@huozhi)

ここ1年、私たちは Next.js におけるエージェント体験の改善に取り組んできました。その過程で、ブラウザ内エージェントを構築して終了させ、MCP 統合を出荷し、より良いエージェントサポートの答えは“エージェントの視点から考えること”にあると学びました。

エージェントはブラウザを“見ていなかった”

今年の初めごろ、Next.js の devtools を改善しているときにあるパターンに気づきました。開発者はブラウザでエラーを見て、その詳細をコピーして AI エディタに貼り付け、エージェントに修正を依頼します。しかし問題は、エージェントはブラウザの内容を見られないことでした。ランタイムエラー、クライアント側の警告、レンダリングされたコンポーネントはすべてエージェントには見えません。

ユーザーが「エラーを直して」と言っても、エージェントはどのエラーを指しているのかを理解できません。

最初の対応として、コピー用ボタンを更新して構造化されたエラー情報を取得するようにしました。さらにブラウザログをターミナルに転送する機能も追加しました。小さな改善でしたが、より大きな気づきにつながりました。Next.js 自体をエージェントに“見える化”する必要がある、ということです。

ブラウザ内エージェントの実験

そこで大胆なアイデアが生まれました。Next.js の中に、スマートな devtools のように動くエージェントを作ったらどうか――というものです。私たちは Vector というブラウザ内チャットエージェントを作りました。react-grab に似ていますが Next.js と統合されており、ページ上の要素を選択してそのソースコードを見たり、変更を促したりできます。ハルシネーションを避けるために Next.js のベストプラクティスが組み込まれていました。

キャプション: Vector のインターフェース（エラー検出と提案修正の表示）

Vector は有用でしたが、Cursor や Claude Code といった汎用コーディングエージェントと重複する部分がありました。多くの開発者は Next.js に限らず既にこれらのツールをプロジェクト全般で使っており、UI の要素選択は特定箇所を指し示すのが簡単になる一方で、日常的に必要とされる機能ではありませんでした。結果として Vector は終了しましたが、有用だった要素（構造化された可視性とフレームワーク固有の知識）を抽出し、それらを Next.js 本体に組み込むことにしました。

MCP が Next.js の状態をエージェントに見せるようにした

2025年10月の Next.js v16 周辺で、ユーザーはエージェントでのデバッグに苦戦していました。典型的なプロンプトは「fix the error」のようなもので、ブラウザのオーバーレイから問題を解決するよう求められていました。しかしエージェントがページの HTML を要求しても問題点が見つかりません。ランタイムの失敗、ブラウザの JavaScript エラー、非同期のエラーはすべてブラウザ側にあり、HTML 上には現れないからです。レンダリングされたページ、レイアウトのセグメント、ルート、その他の内部状態はエージェントからは見えませんでした。

MCP はこのデータを公開する手段を与えてくれました。最初のバージョンではエラー、ルート、レンダリングされたセグメントなどの内部状態が表出されましたが、単にデータを公開するだけでは不十分でした。エージェントは実行中の dev サーバーを発見して通信する必要があり、これが next-devtools-mcp につながりました。

キャプション: Next.js の MCP が「whats use cache?」にドキュメントとコンテキストで応答している様子

MCP はまた、アップグレードやキャッシュコンポーネント移行を支援するプロンプトやツール群もパッケージ化しています。MCP 統合に関する詳細な講演もあります（興味があれば参照してください）。

回答は“エージェントのように考える”こと

MCP は Vector が教えてくれたことを裏付けました。エージェントは Next.js が何をしているかを可視化する必要がありますが、それだけでは不十分です。より深い教訓は、エージェントを Next.js のファーストクラスのユーザーとして扱い、その視点から考えることでした。

  • 彼らはどんな情報を必要としているのか？
  • いつその情報が必要なのか？
  • どのようにその情報を消費するのか？

このマインドセットが実践的な変更につながりました。開発中にエージェントがターミナル出力を読むなら、Server Action の呼び出しをログに残しブラウザのエラーを転送することで、エージェントは必要な手がかりを得られます。訓練データに含まれていないフレームワーク固有の概念でエージェントが苦戦するなら、圧縮したドキュメントインデックス agents.md を埋め込む、あるいは構造化されたワークフロー（Next.js skills）を提供することが、単なるドキュメントよりも有益です。

この問いは私たちが作ったすべてに貫かれています。可視性の必要性はより良いロギングにつながり、知識の必要性は agents.md を生み、発見の必要性は MCP を生み出しました。エージェントをファーストクラスのユーザーとして扱い、彼らがいる場所に合わせることで、デバッグはコード、ランタイム、AI の間に緊密なフィードバックループを形成します。

今後の展望

導入をより簡単にする取り組みを進めています。すでに npx @next/codemod を実行してプロジェクト用の最新のドキュメントインデックスを生成できますし、エージェントに実際に効果があるものを測定するために Next.js 16 の API をカバーする eval スイートを拡張しています。

長期的には、これを next dev に組み込み、追加のセットアップなくエージェントが自動的に適切なコンテキストを得られるようにしたいと考えています。Next.js をエージェントとより良く連携させるためのフィードバックやアイデアをお待ちしています。