エージェンティックな未来に向けたNext.jsの構築

2026年2月12日（木）
投稿者: Jiachi Liu @ huozhi

私たちは過去1年間、Next.jsのエージェント体験の改善に取り組んできました。その過程で、ブラウザ内エージェントを構築し、その後廃止し、MCP統合を出荷し、より良いエージェントサポートの真の答えは、エージェントの視点から考えることだと学びました。

エージェントはブラウザを見ることができなかった

この夏の初め、Next.jsの開発ツールの改善に取り組んでいた際、あるパターンに気づきました。開発者はブラウザでエラーを見て、詳細をコピーし、AIエディターに貼り付けて、エージェントに修正を依頼していました。

問題は、エージェントがブラウザを見ることができないことでした。ランタイムエラー、クライアントサイドの警告、レンダリングされたコンポーネントは、すべてエージェントには見えません。ユーザーが「エラーを修正して」と言っても、エージェントはどのエラーを指しているのかわかりません。

最初の対応は、構造化されたエラーデータをキャプチャするようにコピーボタンを更新することでした。次に、ブラウザのログをターミナルに転送する機能を追加しました。小さな修正でしたが、より大きな気づきを示していました。Next.js自体をエージェントに見えるようにする必要があったのです。

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

これが野心的なアイデアにつながりました。スマートな開発ツールのように動作するエージェントをNext.js内に直接構築したらどうでしょうか？

Vectorと呼ばれるブラウザ内チャットエージェントを構築しました。react-grabに似ていますが、Next.jsと統合されており、Vectorではページ上の要素を選択し、そのソースコードを確認し、変更をプロンプトできました。エージェントの幻覚を避けるために、Next.jsのベストプラクティスが組み込まれていました。

Vectorのインターフェース：エラー検出と修正提案を表示

Vectorは有用でしたが、CursorやClaude Codeのような汎用コーディングエージェントと重複していました。ほとんどの開発者は、Next.jsだけでなく、すべてのプロジェクトでそれらのツールをすでに使用していました。UI選択により、変更したいものを正確に指定することは簡単でしたが、毎日必要なものではありませんでした。

Vectorは廃止しましたが、有用だった部分（構造化された可視性とフレームワーク固有の知識）を取り入れ、それらをNext.js自体に組み込むことにしました。

MCPによりNext.jsの状態がエージェントに見えるようになった

2025年10月のNext.js v16リリース頃、ユーザーはエージェントでのデバッグに苦労していました。よくあるプロンプトは「エラーを修正して」で、ブラウザオーバーレイからの問題をエージェントに解決してもらうものでした。しかし、エージェントはページのHTMLを要求しても何も問題を見つけられませんでした。

ランタイム障害、ブラウザのJavaScriptエラー、非同期エラーはすべてブラウザ内に存在し、HTMLには含まれていませんでした。レンダリングされたページ、レイアウトセグメント、ルート、その他の内部状態は、エージェントには見えませんでした。

MCPにより、このデータを公開する方法が得られました。最初のバージョンでは、エラー、ルート、レンダリングされたセグメントなどの内部状態を表面化しましたが、データを公開するだけでは十分ではありませんでした。エージェントは実行中の開発サーバーを発見し、それらと通信する必要もあり、これがnext-devtools-mcpにつながりました。

Next.js MCPが「whats use cache?」に対してドキュメントとコンテキストで応答

MCPは、アップグレードやキャッシュコンポーネントの移行を支援するプロンプトとツールもパッケージ化しています。MCP統合について詳しく学びたい場合は、詳細な講演があります。

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

MCPは、Vectorが教えてくれたことを確認しました。エージェントはNext.jsが何をしているかの可視性が必要ですが、それは話の一部に過ぎません。より深い教訓は、エージェントをNext.jsのファーストクラスユーザーとして扱い、彼らの視点から考えることでした。

彼らはどのような情報が必要でしょうか？いつ必要でしょうか？どのように消費するでしょうか？

この考え方が実用的な変更につながりました。エージェントが開発中にターミナル出力を読むなら、Server Actionの呼び出しをログに記録し、ブラウザエラーを転送することで、必要なヒントを提供できます。エージェントがトレーニングデータにないフレームワークの概念に苦労するなら、圧縮されたドキュメントインデックスagents.mdを埋め込んだり、構造化されたワークフロー（Next.jsスキル）を提供することで、ドキュメント単体よりも良いコンテキストを提供できます。

これらの質問は、私たちが構築したすべてのものに通じています。可視性の必要性はより良いログ記録につながり、知識の必要性はagents.mdにつながり、発見の必要性はMCPにつながりました。エージェントをファーストクラスユーザーとして扱い、彼らがいる場所で出会うとき、デバッグはコード、ランタイム、AIの間の密接なフィードバックループになります。

今後の展開

現在、これをより採用しやすくすることに取り組んでいます。すでにnpx @next/codemodを実行してプロジェクト用の最新のドキュメントインデックスを生成でき、実際にエージェントに役立つものを測定できるよう、より多くのNext.js 16 APIをカバーするように評価スイートを拡張しています。

長期的には、これをnext devに組み込み、エージェントがセットアップなしで自動的に適切なコンテキストを取得できるようにしたいと考えています。

Next.jsをエージェントとさらに良く連携させる方法について、皆様のフィードバックとアイデアをお聞かせください。