2026年版：AIエージェントに渡すNext.js用ルールファイルの実例と書き方

なぜルールファイルが必要なのか

Claude CodeやCursor、GitHub Copilot Workspaceなどのエージェントは、会話ごとにコンテキストをリセットする。「App RouterではServer Componentを優先して」「anyは禁止」といった方針を毎回伝えるのは非現実的だ。CLAUDE.md・.cursorrules・AGENTS.mdはその解決策で、リポジトリに置くだけでエージェントが読み込み、ルールを前提として動くようになる。

ただし「書けば万能」ではない。ルールが長すぎると無視されやすく、矛盾した指示があると挙動がぶれる。実用上は短く・具体的に・優先順位つきで書くのが原則だ。

ファイルの使い分け

ファイル	読み込むツール
`CLAUDE.md`	Claude Code
`.cursorrules`	Cursor
`AGENTS.md`	OpenAI Codex系、汎用

内容はほぼ共通化できる。プロジェクトルートにCLAUDE.mdを置き、.cursorrulesからそれを参照する形にすると管理が楽だ。

Next.js App Router向けの実例

# Project Rules

## Stack
- Next.js 15 App Router / TypeScript strict mode
- Tailwind CSS v4 / Prisma / Zod

## Component rules
- デフォルトは Server Component。クライアント操作が必要な場合のみ `"use client"` を追加する
- `app/` 配下のファイルは page.tsx / layout.tsx / loading.tsx / error.tsx のみ
- 共有UIは `components/` に置き、ロジックは `lib/` に分離する

## TypeScript
- `any` 禁止。不明な型は `unknown` + 型ガードで処理する
- Prismaの返り値は必ず Zod スキーマで検証してからAPIレスポンスに使う

## API Routes (Route Handlers)
- `app/api/` の Route Handler は必ず `NextRequest` / `NextResponse` を使う
- 認証チェックは `lib/auth.ts` の `requireSession()` を必ず先頭で呼ぶ
- エラーは `{ error: string }` 形式で返し、HTTPステータスを明示する

## 禁止事項
- `pages/` ディレクトリへの新規ファイル追加
- `console.log` のコミット（デバッグは `logger.ts` 経由）
- `fetch` の直書き（`lib/api-client.ts` のラッパーを使う）

## コード生成時の優先順位
1. 既存の型定義・ユーティリティを再利用する
2. 新規ファイルを作る前にコンポーネントの分割を検討する
3. テストは Vitest + React Testing Library で書く