Next.js DevTools MCP で「AI任せのデバッグ」はどこまで実用的か｜中小企業のフルスクラッチ受託

Next.js DevTools MCP は、開発中の Next.js アプリのエラーやページの状態を、AIコーディングエージェントが直接読み取れるようにする仕組みです。本記事では、2026年6月時点の公式情報をもとに、この機能が中小企業向けフルスクラッチ受託の「デバッグ工数」に何をもたらすかを、現場目線で整理します。

中小企業向けに Next.js のフルスクラッチ受託をやっていると、AI駆動開発の話題はいつも「どれだけ速くコードを書けるか」に偏りがちです。Cursor や Claude Code でコードを書く速度は確かに上がりました。けれど、実際の受託案件で時間を食うのは「書く」工程よりも、むしろ「動かして、エラーを読んで、直す」というデバッグの往復だったりします。

2025年10月21日に公開された Next.js 16 には、ここに効く機能が入っていました。Next.js DevTools MCP です（出典: Next.js 16、2025年10月21日公開）。一覧の新機能としては地味ですが、AIに実装だけでなくデバッグまで任せようとすると、この「AIがアプリの状態を直接見られるか」が効いてきます。結論から言うと、これは「AIが速くコードを書く」のではなく、「AIが状況を正しく把握してから直す」ための足回りです。本記事では、何ができて、何がまだできないのかを、受託の現場感で正直に書きます。

そもそも、AIのデバッグは何で詰まっていたのか

AIにデバッグを任せるとき、一番のボトルネックは「AIが画面を見られない」ことでした。

ターミナルで動く Claude Code のようなエージェントは、ブラウザのコンソールも、エラーオーバーレイも、実際に表示されている画面も見られません。だから、これまでの実務はこうでした。開発者がブラウザでエラーを再現し、コンソールのスタックトレースをコピーし、AIのチャットに貼り付けて「これ直して」と頼む。AIは貼り付けられたテキストだけを頼りに推測する——という、人間が「AIの目」を肩代わりする往復が必ず発生していました。

このコピペの往復は、地味に工数を食います。エラーが複数あれば全部貼る必要があるし、貼り忘れれば AI は間違った前提で直そうとします。受託では、こうした小さな手戻りの積み重ねが、そのまま見積りに乗ってきます。AI駆動開発の見積りがどう変わるかは Next.js 16.2 で Turbopack が安定版に｜中小企業の受託開発の見積りはどう変わるか でも触れましたが、デバッグの往復はその「見えにくいコスト」の代表格です。

Next.js DevTools MCP は、この「AIが画面を見られない」という制約に正面から答えた機能です。

Next.js DevTools MCP とは何か：AIにアプリの状態を直接読ませる

Next.js DevTools MCP は、Model Context Protocol（MCP）という標準を使って、AIコーディングエージェントが開発中の Next.js アプリの内部状態にリアルタイムでアクセスできるようにする仕組みです。

公式ドキュメントの説明では、Next.js DevTools MCP は AIエージェントに次のものを提供します（出典: Next.js 16）。

• Next.js の知識: ルーティング・キャッシュ・レンダリングの挙動
• 統合ログ: ブラウザログとサーバーログを、コンテキストを切り替えずに参照
• エラーへの自動アクセス: 詳細なスタックトレースを手動コピーせずに取得
• ページの把握: 現在表示中のルートを文脈として理解

つまり、これまで人間がコピペで AI に渡していた「エラーの内容」「どのページで起きているか」「コンソールに何が出ているか」を、AIが自分で読みにいけるようになります。公式は「これにより、AIエージェントが開発ワークフローの中で直接、問題を診断し、挙動を説明し、修正を提案できる」と説明しています。

仕組みの要は、Next.js 16以降の開発サーバーにビルトインの MCP エンドポイント /_next/mcp が組み込まれた点です（出典: Next.js MCP Server ガイド、最終更新 2026年3月3日）。next-devtools-mcp というパッケージがこのエンドポイントを自動的に見つけて通信し、AIエージェントに統一的なインターフェースを提供します。複数のポートで動いている Next.js インスタンスにも接続できる設計です。

ポイントは、これがブラウザ拡張やスクリーンショットの解析ではなく、フレームワーク自身が状態を構造化テキストで差し出す点にあります。AIは「画面を見る」のではなく、「アプリの内部状態を読む」のです。

導入は .mcp.json に数行：実際のセットアップ

セットアップは拍子抜けするほど簡単です。前提は Next.js 16以降 であること。プロジェクトルートの .mcp.json に次を書くだけです（出典: Next.js MCP Server ガイド）。

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

あとは npm run dev で開発サーバーを起動すれば、next-devtools-mcp が起動中の Next.js インスタンスを自動で見つけて接続します。Claude Code や Cursor のような MCP 対応エージェントなら、設定を読み込んだ時点で使えるようになります。

エージェントが使えるツールも公式に定義されています。たとえば次のようなものです（出典: Next.js MCP Server ガイド）。

• get_errors: 現在のビルドエラー・ランタイムエラー・型エラーを取得
• get_logs: ブラウザのコンソールログとサーバー出力を含む開発ログのパスを取得
• get_page_metadata: ルートやコンポーネント、レンダリング情報などページのメタデータを取得
• get_routes: ファイルシステムを走査してルート一覧を取得（appRouter / pagesRouter に分類）
• get_server_action_by_id: Server Action を ID から逆引きし、ソースファイルと関数名を特定

公式ドキュメントの実例では、ユーザーが「ページのエラーを直して」と頼むと、エージェントが get_errors を呼び、/about ページのハイドレーションエラー（サーバーが "server"、クライアントが "client" をレンダリングして不一致になる典型例）を自分で見つけ、修正のためのTODOを立てて直しにいく様子が示されています。エラーを人間がコピペしていない、というのがこの機能の核心です。

なお、.mcp.json という設定の置き方自体は、AIに最新ドキュメントを読ませる AGENTS.md の運用とも相性が良いものです。Next.js 16.2 のAI向け改善とあわせた現場の使い分けは Next.js 16.2 の AGENTS.md とブラウザログ転送で、AI駆動開発の受託はどう速くなるか にまとめています。

受託の現場で、どこまで実用的か（正直なところ）

ここからは、受託する側として「どこまで使えて、どこは過信しないか」を正直に書きます。

効くのは「再現できているエラーを直す」工程です。 ハイドレーションエラー、型エラー、ビルドエラーのように、開発サーバーが状態として持っているものは、AIが get_errors で自分で拾って直せます。人間が「どのページで」「何が」を説明する手間が省けるぶん、デバッグの往復が短くなります。型エラーやテストまでAIに任せる設計の話は Next.js × AI駆動開発でテストをどう書くか｜中小企業の受託で品質を落とさない進め方 とも地続きです。

一方で、過信してはいけない範囲もあります。第一に、これは開発時（next dev）の仕組みであり、本番環境のエラーを覗くものではありません。get_errors や get_logs といったランタイム系のツールは、Next.js 16以降で開発サーバーが起動していることが前提です。第二に、AIが状態を読めても、「なぜそうなったか」の業務的な正解はAIには分かりません。たとえば認可ロジックの不備のように、エラーは出ていないが仕様として間違っている、という種類のバグは、この仕組みでは検知されません。セキュリティや認可の担保は、AI任せにせず人間が設計責任を持つべき領域です（この観点は 中小企業のNext.jsフルスクラッチで、セキュリティをどう担保するか｜2026年版チェックリスト で詳しく書いています）。

私たちの受託でのスタンスは、こうです。DevTools MCP は「エラーの収集と一次診断」をAIに任せ、「直し方の判断」と「本番に出す前のレビュー」は人間が握る。 AIがエラーを正しく拾ってくれるぶん、人間はより上流の判断に時間を使えます。AIに任せる範囲とレビュー体制をどう線引きするかは、フルスクラッチ受託の品質を左右する設計判断そのものです。

中小企業のフルスクラッチに落とすと、何が変わるか

最後に、中小企業向けフルスクラッチの目線でまとめます。

Next.js DevTools MCP がもたらすのは、「AIが速くコードを書く」ことではなく、「AIがアプリの状態を正しく把握してから直す」ことです。コピペでエラーを渡す往復が減り、AIが自分でエラーを拾って一次診断するぶん、デバッグにかかる人間の介入回数が減ります。これは派手な機能ではありませんが、AIに任せる時間が長い案件ほど、納期とコストにじわじわ効いてきます。

私たちが実務でやろうとしているのは、次のあたりです。

• Next.js 16以降のプロジェクトでは、.mcp.json に next-devtools-mcp を入れ、AIがエラーを自分で拾える状態を作る
• AGENTS.md でAIに最新ドキュメントを読ませる運用とセットで使い、「古い知識で書かせず、正しく状態を読ませる」を両立させる
• エラーの一次診断はAIに任せつつ、認可・セキュリティ・業務仕様の正しさは人間が握る
• 本番環境のエラー監視は、これとは別に専用の仕組みで担保する（DevTools MCP は開発時の仕組みなので）

AIで速く作ることと、品質を落とさないことは両立できます。むしろ DevTools MCP のような「足回り」の整備は、その両立を支える方向に効いています。中小企業の業務システムを Next.js でフルスクラッチするなら、こうしたAI前提の作り方を、最初から設計に織り込んでおくのが現実的です。DevTools MCP のようなAI前提の開発フローを、業務システム全体の設計にどう落とし込むかは 【2026年版】中小企業の社内業務をNext.jsで作り直す実務ガイド で詳しく解説しています。

AI駆動開発での受託を検討している方へ

「自社の Next.js プロジェクトでも、AIに安全にデバッグや実装を任せられるのか」を整理するところから始めたい場合は、まずは15分のカジュアル相談でご相談ください。要件が固まっていなくても構いません。AIに任せる範囲とレビュー体制の作り方を、現実的な進め方として一緒に整理します。営業目的のご連絡はしません。具体的なご相談は info@zetlinker.com でも受け付けています。 </content>

デバッグの往復が減ってAIに任せられる範囲が広がれば、当然ウェブ制作全体の工数や納期にも波及します。AIとNext.jsの組み合わせが制作工程そのものをどう短縮するかは、AIとNext.jsの連携でウェブ制作の工数を削減し短納期を実現する で詳しく解説しています。