RSC時代のESLint：サーバー・クライアント境界を「物理的制約」に変えるアーキテクチャ設計
React Server Components (RSC) の登場により、React開発における「境界」の意識は、単なる設計上の慣習から、アプリケーションの安定性を左右する「物理的制約」へと進化しました。
しかし、`’use client’` を忘れてサーバーコンポーネント内で `useState` を叩き、ランタイムエラーで頭を抱える……そんな経験はもう過去の遺物にするべきです。今回は、ESLintを単なる「構文チェッカー」から「境界強制エンジン」へと昇華させる、現場のテックリード必携の構成を伝授します。
—
1. なぜ「静的解析による境界強制」が不可欠なのか
RSCの設計思想において、サーバーコンポーネントとクライアントコンポーネントは、本来「別世界」の住人です。ランタイムで境界を越えようとすると、Reactは不可解なエラーを吐きます。
これを防ぐための鍵は、「人間が気をつける」という非効率なルールを捨て、「エディタがコードを書き終わる前に警告する」仕組みに置換することです。以下の構成は、意図しないクライアントサイドAPIの漏洩を完全に封殺します。
—
2. 境界を守る最強のESLint構成例
Next.jsプロジェクトにおいて、公式の `eslint-config-next` だけでは不十分です。以下のプラグインを組み合わせ、コンポーネントの記述ルールを厳格化します。
`.eslintrc.json` のベストプラクティス
{
“extends”: [
“next/core-web-vitals”,
“plugin:@typescript-eslint/recommended”
],
“plugins”: [“react-hooks”, “import”],
“rules”: {
// 1. フックはクライアントコンポーネント以外では絶対禁止
“react-hooks/rules-of-hooks”: “error”,
“react-hooks/exhaustive-deps”: “warn”,
// 2. 境界の可視化：サーバー/クライアントの明示をルール化
“import/no-restricted-paths”: [
“error”,
{
“zones”: [
{
“target”: “./src/app/components/server”,
“from”: “./src/app/components/client”,
“message”: “サーバーコンポーネントはクライアントコンポーネントを直接インポートできません。”
}
]
}
]
},
“overrides”: [
{
“files”: [“src/app//.tsx”],
“rules”: {
// RSC内でクライアント専用API使用を検知
“no-restricted-imports”: [
“error”,
{
“paths”: [
{ “name”: “react”, “import”: “useState”, “message”: “useStateはクライアントコンポーネントでのみ使用可能です。” },
{ “name”: “react”, “import”: “useEffect”, “message”: “useEffectはクライアントコンポーネントでのみ使用可能です。” }
]
}
]
}
}
]
}
この設定の「魂」
`no-restricted-imports` をオーバーライド設定で使うのが肝です。これにより、Reactのフックをサーバーコンポーネント（`src/app`配下）で記述しようとした瞬間に、赤波線が表示されます。コンパイルを通すまでもなく、コーディングの最中に境界違反が可視化される。これが開発スピードを劇的に上げる理由です。
—
3. 開発効率を極限まで高める「隠れた武器」
神プラグイン：`eslint-plugin-react-compiler` (Experimental)
Metaが発表したReact Compilerを導入しているなら、`eslint-plugin-react-compiler` は必須です。これがコンパイルされる前のコードの「依存関係の欠落」を教えてくれるため、`exhaustive-deps` の警告に悩まされる時間が激減します。
チーム開発の「暗黙知」を排除する `lint-staged`
CIを通すまで警告に気づかないのはチームの生産性を下げます。コミット時に自動修正を走らせるルールを強制しましょう。
.lintstagedrc.json
{
“.{js,ts,tsx}”: [
“eslint –fix”, // 軽微な警告は自動修正
“prettier –write” // 整形を強制
]
}
—
4. 現場のテックリードが伝授するキーボードショートカット
VS Codeにおいて、以下の設定を `keybindings.json` に追加してください。これだけで、エラー解消のスピードが3倍になります。
[
{
“key”: “cmd+.”,
“command”: “editor.action.quickFix”,
“when”: “editorHasCodeActionsProvider && editorTextFocus”
}
]
なぜこれが必要か？
ESLintの警告が出た際、マウスに手を伸ばす時間は「思考の断絶」です。`Cmd + .` (Windowsは `Ctrl + .`) でクイックフィックスを開き、`Enter` で修正を適用する。このフローを身体に叩き込むことで、コードの品質と実装スピードが両立します。
—
5. 最後に：アーキテクチャをツールに語らせろ
良いアーキテクトは、「規約」をドキュメントに書くのではなく、「コードがそう書けないような制約（ESLint/TypeScript）」を環境に埋め込みます。
今回紹介した「RSC境界の物理的制限」は、新人エンジニアが誤ってクライアントAPIをサーバーコードに混入させるリスクをゼロにします。レビューで「これRSCですよ」と指摘する時間を減らし、機能開発という「本来注力すべき場所」に時間を割いてください。
ツールは、使われるためにあるのではありません。あなたのチームの設計思想を、コードの隅々にまで浸透させるためにあるのです。