エージェント向け手順書のカタログ skills.sh で next-dev-loop を見つけました。最初は、フロント実装を監視してエラーを拾ってくれる仕組みだと思いました。自分のブログ redamoon.net に入れるか調べて、入れないと判断しました。理由は単純です。これはアプリに入れるライブラリではありません。コーディングエージェント向けの手順書でした。
最初に思っていたこと
見た目の印象は、開発中の画面を見て、落ちたところを直してくれる道具でした。Playwright MCP（AIエージェントからブラウザ操作できる仕組み）で QA させる発想にも近いです。半分は当たっていました。外していたのは対象です。ユーザー向けアプリの例外処理でも、本番の監視 SaaS でもありません。動かす相手はコーディングエージェントです。
Vercel が Next.js 16.3 向けに出した公式スキルです。中身は「編集したあと、型が通ったか」ではなく「動いている画面で本当に動くか」を確認する手順です。ドキュメント知識を教えるスキルではありません。Next.js 16.3 では、その手の知識は AGENTS.md 経由でパッケージに同梱されます。残っているのは作業手順のほうです。
実際に何をするか
エージェントは、同じアプリを2つの視点で突き合わせます。
| 視点 | 何を見るか |
|---|---|
/_next/mcp（Next.js 側） |
ルート、RSC（React Server Components）、Server Actions、サーバーログ、コンパイルエラー |
agent-browser（ブラウザ側） |
実 Chrome の DOM、console、network、React ツリー、Web Vitals |
確認する失敗は4種類あります。
- コンパイルできるか（Turbopack の
get_compilation_issues） - 実行時エラーがないか（サーバーとブラウザの両方）
- 意図どおり動くか（クリック、遷移、表示）
- React として正しいか（余分な再レンダー、server/client 境界、Suspense）
入れ方は次のとおりです。
npx skills add vercel/next.js --skill next-dev-loop
npm i -g agent-browser@latest
エージェントへの指示例はこうなります。
After every edit, verify the page still works at runtime using the next-dev-loop Skill.
セッションでは、実ブラウザを開きます。次に /_next/mcp の生存を確認し、ルート一覧を取ります。今の画面を描画しているファイルだけを探し、編集後に上記4観点で検証します。ログインが必要なら、人が操作してから続行します。
自動で例外を握って直してくれる仕組みではありません。エージェントに「編集したら必ず実行確認しろ」と教えるものです。
前提が硬い
スキル側が作業を止める条件があります。足りないとソースを grep して代替しません。
- Next.js 16.3 以上
- Turbopack（webpack は拒否）
agent-browser0.31.1 以上next devが起動していること
Next.js 未満、Pages Router、webpack のまま、では動きません。フレームワーク非依存の「ブラウザで確認する道具」ではありません。
公式の置き場は AI coding agents ガイド と Next.js 16.3 の AI 改善 にあります。スキル本体は vercel/next.js の SKILL.md です。
自分の置き場で判定した
入れるかどうかは、リポジトリのスタックで決まります。3箇所を見ました。
| 置き場 | スタック | 判定 |
|---|---|---|
| Obsidian Vault | Markdown と textlint | 入れない。アプリではない |
| redamoon.net | Astro 7 と Cloudflare Workers | 入れない。/_next/mcp がない |
| Next.js のアプリ | 16.3 以上なら候補 | 条件を満たせば入れる |
家計簿アプリのような Next.js リポジトリなら、エージェントに UI を書かせる前提で候補になります。このブログには入れません。
ブログの中身を開けて確認した
package.json に next はありません。astro は ^7.0.0、アダプタは @astrojs/cloudflare です。中身は2プロダクトです。
- サイト本体
redamoon-site。pnpm devでhttp://127.0.0.1:4321 scrap-api。Hono、D1、R2。pnpm scrap-api:devで:8787
記事は src/content/log/ に128本あります。本文は Astro 標準 Markdown ではなく zenn-markdown-html で描画しています。配信は Cloudflare Workers です。ルートの netlify.toml は現行の本番経路ではありません。
静的ブログだけでは終わっていません。ページの一部だけをブラウザで動かす island と、SSR（サーバー側で HTML を出す方式）が混ざっています。
- 検索は
Search.tsxをclient:load（あいまい検索の Fuse.js） - Scraps の一覧・編集・ログイン・画像アップロードは React
- 詳細は
prerender = falseの SSR で、描画だけclient:only="react" - 管理は
localStorageのトークン。本番は Cloudflare Access
ここは「ビルドが通った」だけでは足りません。画面とログイン状態と API 到達を見ないと壊れます。実行確認が欲しくなる場所ではあります。道具が next-dev-loop ではない、というだけです。
似たことをするなら agent-browser
Astro 側で同じ系統の確認をするなら、フレームワーク非依存の agent-browser になります。next-dev-loop の半分、ブラウザ視点だけを使う形です。検証するなら、検索、Scraps の詳細、ログインから管理画面、の順です。公開したあと、壊れが目立つ場所です。
今回は入れません。必要になったら、そのリポジトリで入れます。スキルは予備として置いておく対象ではありません。スタックと作業手順が噛み合った場所に置きます。
スキルは動詞、リポジトリは名詞
前回、フォルダ管理で決まる、Claude Codeのループ品質 に書いた判定基準があります。Claude が知っておくべきことは名詞なのでファイルに置きます。実行すべきことは動詞なのでスキルにします。
next-dev-loop は動詞です。「編集した画面が実行時に動くか確認する」。それを Astro のリポジトリに置くと、実行できない手順書になります。名詞と動詞が逆転する、と前回書いた話そのものでした。
フロントの監視だと思って開いたリンクが、エージェントの実行確認でした。自分のブログに入れる話ではありませんでした。入れる場所は、Next.js 16.3 で UI をエージェントに書かせているリポジトリです。
参考