Next.js DevTools MCPを使ってNext.jsアプリの開発を効率化!Bridge MCP Serverの仕組みとAI時代のフレームワーク生存戦略について考えてみた
リテールアプリ共創部 マッハチームのるおんです。
先日ついにNext.js 16がリリースされました!
その際、Cache Componentsなどの新機能や、Turbopackのstable化が大きな話題になりました。私はそれと同時に発表された Next.js DevTools MCP に注目しました。MCPのサポートが組み込まれたことでNext.jsのAIコーディングアシスタントとの開発体験が大きく変わりました。
今回は、Next.js DevTools MCP を実際に使ってみたので、その導入から検証結果までをまとめます。
また、検証を進める中で、その背後にあるbridge MCP serverの仕組みが予想以上に興味深いことに気づきました。AI時代のフレームワーク設計として示唆に富んでいると感じたため、アーキテクチャについても深掘りしてみました。
先に結論
Next.js DevTools MCP(パッケージ名:next-devtools-mcp)は、MCPの設定ファイルに追加するだけで導入でき、以下の3つの主要機能を提供します。

3つの主要機能
- Runtime Diagnostics & Live State Access (Next.js 16+): 実行中のアプリケーションの内部情報にアクセス(Version 16 以上 から使用可)
- Development Automation: 公式codemodを使った自動アップグレードや、Cache Componentsなどのセットアップ(Version 16以前から使用可)
- Next.js 16 knowledge base: 最新の公式ドキュメントへの直接アクセスや事前設定済みプロンプトの使用(Version 16以前から使用可)
特に印象的だったのは、1つ目のAIエージェントが開発サーバーで実行中のNext.jsのエラーやルート情報などの内部情報にリアルタイムでアクセスできる点です。これにより、エラーの原因を即座に把握し、適切な修正提案を受けることができました。
Next.js 16から、フレームワーク自体にMCPサーバーが構築され、 /_next/mcpエンドポイント が追加されました。 そのNext.js 16内MCPサーバーとCursorなどのMCPクライアントを繋ぐ役割として今回のNext.js DevTools MCPが機能します。
Next.js DevTools MCPは、他のMCPサーバーと同じく、stdioとHTTP APIをつなぐプロキシとして機能します。そのためMCPとしては一般的なアーキテクチャなのですが、面白いと思ったのがNext.jsというフレームワーク自体にMCPが組み込まれることで開発サーバーとリアルタイムにやり取りができるようになったという点です。
Next.js 16以降でできること vs 16以前からできること
Next.js DevTools MCPは、特にNext.jsのバージョンによらず使用することができますが、先ほどの説明の通り一部機能(内部情報アクセス系)はNext.js 16でないと使用出来ません。
| 機能 | Next.js 16以降 | 16以前から可能 |
|---|---|---|
| ドキュメント検索 | ✅ | ✅ |
| アップグレード支援 | ✅ | ✅ |
| ブラウザテスト | ✅ | ✅ |
| リアルタイムエラー取得 | ✅ | ❌ |
| ルート情報取得 | ✅ | ❌ |
| ログファイルアクセス | ✅ | ❌ |
| Server Action検索 | ✅ | ❌ |
Next.js 16からの/_next/mcpエンドポイントにより、AIエージェントは 実行中のアプリケーションの内部状態にリアルタイムでアクセスできる ようになるからです。
How It Works(仕組みの解説)
以下仕組みの解説ですが、少し細かい内容になるので、先に検証結果をみたい方は飛ばして先に検証セクションからご覧ください。
Next.js DevTools MCPがどのように動作しているのか、アーキテクチャを理解しておくと、より効果的に活用できます。
公式ドキュメントによると
This package provides a bridge MCP server that connects your coding agent to Next.js development tools:
Coding Agent
↓
next-devtools-mcp (this package)
↓
├─→ Next.js Dev Server MCP Endpoint (/_next/mcp) ← Runtime diagnostics
├─→ Playwright MCP Server ← Browser automation
└─→ Knowledge Base & Tools ← Documentation, upgrades, setup automation
Key Architecture Points:
For Next.js 16+ projects: This server automatically discovers and connects to your running Next.js dev server's built-in MCP endpoint at http://localhost:PORT/_next/mcp. This gives coding agents direct access to runtime errors, routes, logs, and application state.
For all Next.js projects: Provides development automation tools (upgrades, Cache Components setup), documentation access, and browser testing capabilities that work independently of the runtime connection.
Auto-discovery: The nextjs_runtime tool scans common ports (3000, 3001, etc.) to find running Next.js servers, so you don't need to manually specify ports in most cases.
日本語訳(DeepL翻訳)
このパッケージは、コーディングエージェントをNext.js開発ツールに接続するブリッジMCPサーバーを提供します:
Coding Agent
↓
next-devtools-mcp (this package)
↓
├─→ Next.js Dev Server MCP Endpoint (/_next/mcp) ← Runtime diagnostics
├─→ Playwright MCP Server ← Browser automation
└─→ Knowledge Base & Tools ← Documentation, upgrades, setup automation
主要なアーキテクチャのポイント:
Next.js 16 以降プロジェクトの場合: このサーバーは、実行中の Next.js 開発サーバーの組み込み MCP エンドポイント(http://localhost:PORT/_next/mcp)を自動的に検出し接続します。これによりコーディングエージェントが、実行時エラー、ルート、ログ、アプリケーション状態に直接アクセスできるようになります。
すべてのNext.jsプロジェクト向け: 開発自動化ツール(アップグレード、Cache Componentsの設定)、ドキュメントへのアクセス、およびランタイム接続に依存しないブラウザテスト機能を提供します。
自動検出: nextjs_runtime ツールは、動作中の Next.js サーバーを見つけるために一般的なポート(3000、3001 など)をスキャンします。そのため、ほとんどの場合、ポートを手動で指定する必要はありません。
構成図
上の説明をもう少しわかりやすく構成図にしてみました。

今回少しややこしいのですが、登場人物として 2つのMCPサーバー が登場します。
-
1つ目は、Next.js 16から組み込まれたフレームワーク内のMCPサーバーです(右下)。
-
2つ目は、今回紹介するNext.js DevTools MCPです(真ん中)。
1つ目のNext.js 16内MCPサーバーは、実行中の開発サーバーのログなどから内部にアクセスし、リアルタイムに情報を発見します。そして、このNext.js 16内MCPサーバーと、CursorなどのMCPクライアントの繋ぐ役割(bridge MCP server)として二つ目のNext.js DevTools MCPが存在します。
bridge MCP serverとは
公式ドキュメントや上の説明にあるように、Next.js DevTools MCPは bridge MCP server と表現されています。
This package provides a bridge MCP server that connects your coding agent to Next.js development tools
では、bridge MCP serverとはなんでしょうか。特に一般的な呼び名ではなさそうですが、この「bridge(橋渡し)」という表現が重要で、MCPクライアントとNext.js 16内MCP間を連携するために 異なる通信方式を変換 する役割を担っています。
つまり、CursorなどのMCPクライアントと、先ほど紹介した1つ目のMCPサーバー(Next.js 16からフレームワーク自体に組み込まれたMCP)をつなぐ役割として、Next.js DevTools MCPが機能します。そういう意味でNext.js DevTools MCPは bridge MCP server と言われているようです。
そして、Next.js 16からは、_next/mcpエンドポイントが追加されました。これによりHttp経由でNext.js 16内のMCPサーバーと接続することができます。
とはいえ、フレームワーク内にMCPエンドポイントが立っており、bridgeと表現されるので新しく見えますが、よく考えると従来のAPIを呼び出すMCPサーバーの役割としては大きくは変わりません。
そして、Next.js DevTools MCPは説明したbridgeサーバーとしての機能だけでなく、従来のドキュメントやツール群を呼び出す一般的なMCPサーバー的な役割を持っています。
まとめると、Next.js DevTools MCPの役割とは
- Next.jsの最新ナレッジベースや、
nextjs_docs、upgrade_nextjs_16などのツール群としての役割。(Next.jsのバージョンや開発サーバーの起動状態に 関係なく 利用できる。) - Next.jsの開発サーバーの
/_next/mcpエンドポイントとのbridge(橋渡し)としての役割。(Next.js 16以降かつ開発サーバーが起動中のみ 利用可)
なぜbridgeが必要なのか
一見すると、CursorなどのMCPクライアントが直接Next.jsの/_next/mcpエンドポイントに接続すれば良いように思えますが、そうはいきません。理由は 通信プロトコルの違い にあります。これは一般的なMCPサーバーにも言えることです。
| レイヤー | 通信方式 | プロトコル |
|---|---|---|
| MCPクライアント(Cursor) | stdio(標準入出力) | MCPプロトコル |
| ↕️ bridge(Next.js DevTools MCP) | ||
| Next.js 16内MCPサーバー | HTTP | MCPプロトコル over HTTP |
Next.js DevTools MCPの実装
Next.js DevTools MCPの実装を簡単にみてみました。
https://github.com/vercel/next-devtools-mcp/tree/main/src/tools 内にNext.js DevTools MCPが提供するツール群が見て取れますが、この中にnextjs-runtime.tsがあります。
そしてこのnextjs-runtimeこそがまさにbridgeとしてNext.js 16内のMCPサーバーと通信するためのツールになっています。そしてその中にdiscover_servers、list_tools、call_toolなどのアクションが定義されており、これらを用いてNext.jsと通信していることがわかります。
| アクション | 役割 | 説明 |
|---|---|---|
discover_servers |
サーバー検出 | localhost:3000-10000をスキャンして実行中のNext.jsサーバーを発見 |
list_tools |
ツール一覧 | 接続したNext.jsサーバーから利用可能なMCPツールを取得 |
call_tool |
ツール実行 | 特定のNext.jsツール(get_errors, get_logsなど)を呼び出し |
これらにより、Next.js 16内MCPサーバーとやり取りを行います。
Next.js 16内MCPの実装
一方、Next.js 16内のMCPは、既に起動している HTTPサーバー に/_next/mcpというエンドポイントを追加する形で実装されています。こちらも実際のソースを確認してみます。
実際のNext.js 16.0.1内のソース
このコードから HTTPエンドポイント(/_next/mcp)でリクエストを受信し、StreamableHTTPServerTransport でHTTP ↔ MCPメッセージを変換してNext.js内部の MCPサーバーインスタンス と接続していることがわかります。
実際にリクエストを送ってみると
実際に起動中の/_next/mcpエンドポイントにHTTPリクエストを送信して、MCPプロトコルが動作することを確認できます
curl -X POST http://localhost:3000/_next/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","method":"tools/list","id":1}'
レスポンス:
event: message
data: {"result":{"tools":[{"name":"get_project_metadata","description":"Returns the the metadata of this Next.js project, including project path, dev server URL, etc.","inputSchema":{"type":"object","properties":{},"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}},{"name":"get_errors","description":"Get the current error state from the Next.js dev server, including Next.js global errors (e.g., next.config validation), browser runtime errors, and build errors with source-mapped stack traces","inputSchema":{"type":"object","properties":{},"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}},{"name":"get_page_metadata","description":"Get runtime metadata about what contributes to the current page render from active browser sessions.","inputSchema":{"type":"object","properties":{},"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}},{"name":"get_logs","description":"Get the path to the Next.js development log file. Returns the file path so the agent can read the logs directly.","inputSchema":{"type":"object","properties":{}}},{"name":"get_server_action_by_id","description":"Locates a Server Action by its ID in the server-reference-manifest.json. Returns the filename and export name for the action.","inputSchema":{"type":"object","properties":{"actionId":{"type":"string"}},"required":["actionId"],"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}}]},"jsonrpc":"2.0","id":1}
↑の結果から、Next.js 16内のMCPサーバーはget_project_metadata get_errors get_page_metadata get_logs get_server_action_by_idなどのToolsを持っていることが確認できます。
MCPクライアントとNext.js 16内MCPサーバーは同じMCPプロトコルを使用していますが、通信方式が異なるため 今回のNext.js DevTools MCPを中間層(bridge)として使用するということですね。
ちなみにさらにソースを深ぼると、Next.js 16内MCPサーバーはHMRの仕組みや既存のログファイルなどを活用して内部情報にアクセスしていることがわかりました。
検証
今回はNext.js DevTools MCPを使用して以下の機能を試してみようと思います。

- Next.js 16への自動アップグレード機能
- Next.jsナレッジベースへのアクセス
- 実行中のアプリケーションの情報取得(ルート、エラーなど)
自分は個人開発でちょうどNext.js v15.3で運用している実アプリケーションがあるので、今回はそのリポジトリを対象に検証およびNext.js v16を試してみたいと思います。検証用に作るようなサンプルアプリと違い、実際の運用中のアプリでも本MCPが活用できるかどうかという観点でも検証してみたいと思います。
MCPセットアップ
今回はMCPクライアントとしてCursorを使用しました。モデルはclaude-4.5-sonnetです。
Cursor Settings の Tools & MCP 欄からNext.js DevTools MCPを追加します。
{
"mcpServers": {
"next-devtools": {
"command": "npx",
"args": ["-y", "next-devtools-mcp@latest"]
}
}
}
オプションにあるように、next-devtools-mcp@latestを使用するため、ユーザーが意識せずとも最新の情報を参照できるような仕組みになっていることがわかります。

設定画面で有効化されていることが確認できれば完了です。
検証① - Automated Next.js 16 upgrades
まずは、公式codemodeによるNext.js 16の自動アップグレードを試してみます。

これに関してはbridgeの機能は使わないので、Next.jsのバージョン15の状態でも使用可能です。
やってみた
アップグレードガイドにも載っている、MCPを活用したプロンプト例をそのままCursorに渡してみます。
Next Devtools, help me upgrade my Next.js app to version 16
すると、AIエージェントがNext.js DevTools MCPの「upgrade_nextjs_16」ツールを使用していることが確認できます。正しくMCPサーバーが動いていますね。

以下、実際のCursorからの出力です(長いので折りたたみ)
1. 現在のNext.jsバージョンや環境の事前チェック

2. 公式codemod `npx @next/codemod@canary upgrade latest`の実行

3. 変更ファイルの確認

4. ビルド実行

変更内容の確認
実際にNext.jsがv16.0.1にアップデートされているのが確認できました。

また、Next.js 16からは従来のmiddleware.tsがproxy.tsにリネームされました。
その変更などもcodemodeにより反映されていることが確認できました。
- export default async function middleware(req: NextRequest) {
+ export default async function proxy(req: NextRequest) {
...
}
所感
手動で行うとドキュメントの確認とアップデートで数十分かかりそうなアップグレード作業が、プロンプト一つで自動化されたのは非常に便利でした。特に、事前アップデートのための事前チェックや、今回は発生しませんでしたがエラーの自動修復などは助かります。
ただし、カスタムなコードについては手動での確認が必要な場合もあるので、完全に任せきりにせず、差分を確認しながら進めることをお勧めします。
検証② - Curated Next.js 16 knowledge base
次に、Next.jsの機能についてのナレッジベースへのアクセス機能を試してみました。こちらもbridgeの機能は使わずに回答されるはずです。
![]()
やってみた
以下のプロンプトで、Cache Componentsについて質問してみました。
Next Devtools MCPを使ってCache Componentsのドキュメントを確認して使い方を教えてほしい
AIの応答
最初に起動中のサーバーを確認するツールが発火してしまいましたが、それをスキップしたら以下の回答が得られました。
Next.js 16のCache Componentsについて説明させていただきます。MCPツールには完全な知識ベースが組み込まれていますので、そこから重要な情報をお伝えします。

最新のCache Componentsの仕様について回答が得られました。また、疑問に思った点なども壁打ちできるのでNext.jsのようなアップデートが早くハルシネーションを起こしがちな機能についても正式なナレッジベースから回答が得られるので大変助かりました。以下、壁打ち例:

所感
ブラウザで公式ドキュメントを開いて検索する手間が省け、コーディング中にすぐに情報を得られるのは非常に便利です。特に、Next.js 16の新機能について調べる際に、確実に最新情報が得られる点が安心できます。
検証③ - Application routes, pages, and component metadata
次に、Next.js 16の目玉機能である、実行中のアプリケーションの内部情報へのアクセス を試してみました。今回はbridgeとしてNext.js DevTools MCPが機能しそれを使ってルーティング情報やメタデータにアクセスされるはずです。

やってみた
開発サーバーを起動しておき、Cursorで以下のプロンプトを入力しました。
Next Devtools MCPを使ってApplication routes, pages, and component metadataの情報について教えて
AIの応答
すると、Next.js DevTools MCPが使用され、早速「nextjs_runtime」ツールが呼び出され、「discover_servers」アクションで開いている開発サーバーのポートを探し始めました。

そしてポートが開くと、今度は「nextjs_runtime」ツールの「list_tools」アクションを使用して、Next.js 16内MCPのツール一覧を探し始めます。
そして、「nextjs_runtime」ツールの「call_tool」アクションを使用して、Next.js 16内MCPのツールの「get_project_metadata」ツールと「get_page_metadata」ツールを呼び出し始めました。
はい、MCPがMCPを呼び出すのでかなりややこしくなってきましたね。
これにより、最終的にプロジェクト全体のメタデータとページ単位のメタデータの情報が実際の開発サーバーの情報から取得できました。

所感
これがNext.js 16 + MCPの最大の価値だと感じました。従来は、プロジェクトの情報やエラーを確認するためにブラウザのコンソールを開いたり、ターミナルのログを見たりする必要がありましたが、AIエージェントが代わりにそれらの情報を取得してくれます。
特に、複数のエラーが発生している場合や、エラーの原因を特定するためにファイルを跨いで確認する必要がある場合に、この機能の威力を発揮すると思います。
まとめ
Next.js DevTools MCP(next-devtools-mcp)を実際の運用中のアプリケーションで検証してみて、以下の点で開発体験が大きく向上することが確認できました。
良かった点
- セットアップが非常に簡単 -
.mcp.jsonを作成するだけで導入完了 - 開発時間の大幅な節約 - Next.js 16への自動アップグレードやCache Componentsの実装支援により、数十分かかる作業が数分に
- デバッグ効率の向上 - 実行中のアプリケーションからエラー情報をリアルタイムに取得し、AIが原因を特定
- 正確な情報へのアクセス - 公式ドキュメントの最新情報に直接アクセスでき、ハルシネーションを回避
特に、開発サーバーの内部状態に直接アクセスできる点は、従来のコード解析ベースのAI支援とは一線を画す体験でした。
おわりに
今回発表されたNext.js 16のアップデートでは、Cache Componentsなどの新機能が注目されていますが、このNext.js DevTools MCPは公式ドキュメント内で軽く紹介されているだけでした。しかし、これは AIエージェント時代において極めて重要な戦略的取り組み だと感じています。
AIエージェントが開発の主要なツールとなる中で、フレームワークには以下のような対応が求められます:
- 最新かつ正確なドキュメントへのアクセス提供 - ハルシネーションを防ぐ信頼できる情報源
- 高速にアップデートされるフレームワークへの追従支援 - 自動アップグレードやマイグレーション支援
- 実行時情報への直接アクセス - 静的解析では得られないリアルタイムな状態把握
Next.js 16は、フレームワーク自体に MCP(Model Context Protocol)サーバーを組み込む という形でこれらの課題に応えています。これは、AI時代のフレームワークの生存戦略 を明確に反映した設計判断だと言えるでしょう。
従来のフレームワークは「人間の開発者」を主な対象としてきましたが、これからは「AIエージェントとの協調」を前提とした設計が求められます。Vercelがいち早くこの流れに対応し、MCPという標準プロトコルを採用して実装した点は、さすがだと感じました。
今後、Next.js以外のフレームワークやツールでも同様の仕組みが実装されることで、AI駆動開発の可能性はさらに広がっていくでしょう。フレームワーク側がAIとの接続を標準化することで、開発体験が一段と向上することを期待しています。
以上、どなたかの参考になれば幸いです。
参考








