Svelte MCP × typescript-eslint 連携

AI 時代の Svelte 5 開発では、Svelte MCP、eslint-plugin-svelte、typescript-eslint の三点セットで品質保証を構築するのが 2026 年時点のベストプラクティスです。それぞれ異なる層で動作し、重複することなく互いを補完します。

この記事では、三者の役割分担、具体的なフル構成 eslint.config.js、Claude Code や Cursor との統合方法、CI/CD 連携、よくあるトラブルシューティングを解説します。

この記事で学べること#

• Svelte MCP、eslint-plugin-svelte、typescript-eslint の役割分担
• 2026 年 4 月時点の安定性と実用判断
• フル構成の eslint.config.js（業務プロジェクト向け）
• Claude Code / Cursor / AGENTS.md との統合
• CI/CD での活用と pre-commit フック
• トラブルシューティング

三点セットの役割分担#

三つのツールはそれぞれ異なる層で動作します。一言でまとめると：

• Svelte MCP は「AI がコードを書く 時」の品質保証
• eslint-plugin-svelte は「人間が保存・push する 時」の静的解析
• typescript-eslint は「TypeScript 固有の問題」の検出

詳細な役割比較#

検出能力の重複とユニーク領域#

同じコード問題でも、複数のツールが検出できる領域と、片方しか検出できない領域があります。これを理解しておくと「どこまでを何に任せるか」の設計判断ができます。

重複領域: $: 反応的宣言、<slot /> 構文、export let プロパティ、on:click など Svelte 4 のレガシー構文は、ESLint と MCP 両方で検出できます。この領域は「二重の安全網」として機能します。

ESLint のみ検出: 未使用変数、any の使用、a11y 違反、認知的複雑度、import 順序、命名規則など、汎用的な品質問題は ESLint の独壇場です。

MCP のみ検出: $state.eager のような最新ルーン、公式ドキュメントとの整合性、AI 生成時のコンテキスト保持、Svelte 4 → 5 移行支援は MCP が強みを発揮する領域です。

2026 年 4 月時点の安定性評価#

三点セットそれぞれの安定性を整理します。

フル構成の eslint.config.js#

業務プロジェクト向けのフル構成を示します。基本の ESLint + Prettier 設定 に、typescript-eslint の型情報ベースルールと Svelte MCP との整合性設定を加えたものです。

// eslint.config.js
import js from '@eslint/js';
import ts from 'typescript-eslint';
import svelte from 'eslint-plugin-svelte';
import prettier from 'eslint-config-prettier';
import globals from 'globals';
import svelteConfig from './svelte.config.js';

export default ts.config(
  // 1. JavaScript 標準ルール
  js.configs.recommended,

  // 2. TypeScript の型情報ベース推奨ルール（strictRecommended）
  ...ts.configs.strictTypeChecked,
  ...ts.configs.stylisticTypeChecked,

  // 3. Svelte 推奨ルール
  ...svelte.configs.recommended,

  // 4. Prettier 衝突回避（必ず最後）
  prettier,
  ...svelte.configs.prettier,

  // 5. グローバル変数の宣言
  {
    languageOptions: {
      globals: {
        ...globals.browser,
        ...globals.node
      },
      parserOptions: {
        projectService: true,
        tsconfigRootDir: import.meta.dirname
      }
    }
  },

  // 6. .svelte / .svelte.ts / .svelte.js 固有設定
  {
    files: ['**/*.svelte', '**/*.svelte.ts', '**/*.svelte.js'],
    languageOptions: {
      parserOptions: {
        projectService: true,
        extraFileExtensions: ['.svelte'],
        parser: ts.parser,
        svelteConfig
      }
    }
  },

  // 7. プロジェクト固有ルールのカスタマイズ
  {
    rules: {
      // TypeScript
      '@typescript-eslint/no-explicit-any': 'error',
      '@typescript-eslint/consistent-type-imports': [
        'error',
        { prefer: 'type-imports', fixStyle: 'separate-type-imports' }
      ],
      '@typescript-eslint/no-unused-vars': [
        'error',
        { argsIgnorePattern: '^_', varsIgnorePattern: '^_' }
      ],

      // Svelte 5 Runes 関連
      'svelte/no-at-html-tags': 'error',
      'svelte/valid-compile': 'error',
      'svelte/no-reactive-literals': 'error',
      'svelte/prefer-style-directive': 'warn',

      // Svelte a11y
      'svelte/a11y-missing-attribute': 'error',
      'svelte/a11y-no-redundant-roles': 'error'
    }
  },

  // 8. 除外パターン
  {
    ignores: [
      'build/',
      '.svelte-kit/',
      'dist/',
      'node_modules/',
      '.eslintcache',
      'pnpm-lock.yaml'
    ]
  }
);

重要な設定ポイント#

projectService: true と tsconfigRootDir#

projectService: true は typescript-eslint v8 以降の推奨方式で、プロジェクト全体の TypeScript 設定を自動検出します。これにより型情報ベースのルール（strictTypeChecked）が高速かつ正確に動作します。

tsconfigRootDir: import.meta.dirname は、モノレポや複雑な構造のプロジェクトで tsconfig の基点を明示するための設定です。

parserOptions.svelteConfig が必須#

.svelte および .svelte.ts / .svelte.js ファイルでは、必ず parserOptions.svelteConfig を指定してください。これがないと Runes が未定義シンボル扱いされます。

// NG
{
  files: ['**/*.svelte'],
  languageOptions: {
    parserOptions: { parser: ts.parser }
  }
}

// OK
import svelteConfig from './svelte.config.js';
// ...
{
  files: ['**/*.svelte', '**/*.svelte.ts', '**/*.svelte.js'],
  languageOptions: {
    parserOptions: {
      parser: ts.parser,
      svelteConfig  // ← これ
    }
  }
}

strictTypeChecked と stylisticTypeChecked の採用#

typescript-eslint には複数のプリセットがあります。業務利用では以下の組み合わせが推奨されます。

svelte-autofixer と ESLint の役割切り分けルール#

プロジェクト固有ルールの設定では、MCP と ESLint の重複を意識的に設計します。

{
  rules: {
    // MCP が得意な領域（Svelte 5 固有）は warn に留めて、MCP での修正を推奨
    'svelte/prefer-style-directive': 'warn',

    // ESLint が得意な領域（汎用品質）は error で強制
    '@typescript-eslint/no-explicit-any': 'error',
    '@typescript-eslint/no-unused-vars': 'error'
  }
}

この設計にすることで、保存時の赤線は「ESLint でしか直せないもの」に絞られ、Svelte 5 構文の移行は AI（Claude Code 等）経由で MCP に任せる、という役割分担が自然に確立します。

Claude Code / Cursor との統合#

AGENTS.md / CLAUDE.md での設定#

Claude Code（CLAUDE.md）や Cursor（AGENTS.md または .cursorrules）で、以下のように MCP と ESLint の役割を明記しておくと、AI が一貫した挙動を取れます。

## コード品質チェック

このプロジェクトは以下の三点セットで品質保証しています：

1. **Svelte MCP**: AI にコード生成・修正を依頼する際、必ず `svelte-autofixer` で検証すること
2. **eslint-plugin-svelte**: 保存時・CI で自動実行される
3. **typescript-eslint**: `@typescript-eslint/no-explicit-any` は error。any 使用時は必ず理由をコメントで明記

### 優先順位
- Svelte 固有のレガシー構文（`$:`、`<slot />`、`export let`、`on:click`）の検出で MCP と ESLint が衝突した場合は MCP を優先
- その他は ESLint のルールを優先

VS Code / Cursor 設定#

.vscode/settings.json で、MCP と ESLint の両方が気持ちよく動く設定例：

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  "[svelte]": {
    "editor.defaultFormatter": "svelte.svelte-vscode"
  },
  "eslint.validate": [
    "javascript",
    "typescript",
    "svelte"
  ],
  "svelte.enable-ts-plugin": true,
  "typescript.tsdk": "node_modules/typescript/lib"
}

CI/CD 統合#

典型的な CI パイプラインは以下のようになります。

GitHub Actions の例#

.github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint-and-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup pnpm
        uses: pnpm/action-setup@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: pnpm

      - name: Install dependencies
        run: pnpm install --frozen-lockfile

      - name: Run svelte-check
        run: pnpm check

      - name: Run ESLint
        run: pnpm lint

      - name: Run Prettier check
        run: pnpm exec prettier --check .

pre-commit フック#

husky + lint-staged の組み合わせで、コミット前に三点セットを走らせます。

.husky/pre-commit:

pnpm exec lint-staged

package.json:

{
  "lint-staged": {
    "*.{ts,js,svelte}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{md,json,yml,yaml}": [
      "prettier --write"
    ]
  }
}

バージョン固定運用#

eslint-plugin-svelte と svelte-eslint-parser はリリース頻度が高く、patch アップデートで挙動が微妙に変わることがあります。業務プロジェクトでは package.json でバージョンを固定し、明示的なアップグレードタイミングをコントロールすることを推奨します。

{
  "devDependencies": {
    "eslint-plugin-svelte": "3.17.0",
    "svelte-eslint-parser": "1.6.0",
    "typescript-eslint": "8.20.0",
    "eslint-config-prettier": "10.0.1"
  }
}

アップグレード時は以下のチェックリストで確認します。

1. CHANGELOG.md で breaking changes がないか確認
2. ローカルで pnpm lint を実行し、新しい警告が出ていないか確認
3. CI でフルパイプラインを走らせる
4. svelte-autofixer のルールとの整合性を確認

トラブルシューティング#

.svelte.ts が解析されない#

flat config の files パターンに **/*.svelte.ts を明示的に含める必要があります。

{
  files: ['**/*.svelte', '**/*.svelte.ts', '**/*.svelte.js'],
  // ...
}

Runes が未定義シンボルとして検出される#

parserOptions.svelteConfig の設定漏れが原因です。svelte.config.js を読み込んで parserOptions に渡してください（前述）。

typescript-eslint が非常に遅い#

型情報ベースのルール（*TypeChecked）は遅い傾向があります。以下を試してください。

{
  languageOptions: {
    parserOptions: {
      projectService: true,      // v8 推奨方式（v7 以前の project: '...' より高速）
      tsconfigRootDir: import.meta.dirname
    }
  }
}

また、CI では eslint --cache を使用してください。

pnpm eslint . --cache --cache-location .eslintcache

MCP と ESLint で挙動が違う#

基本的に MCP を優先 してください。MCP は公式ドキュメントと同期しているため、最新の Svelte 仕様に対してより正確です。ESLint プラグインは追随が遅れることがあります。

矛盾を検出したら、eslint-plugin-svelte の該当ルールを無効化するか、MCP を信用して ESLint の警告を // eslint-disable-next-line でローカル無効化します。

<script lang="ts">
  let count = $state(0);
  // MCP 推奨の書き方だが、ESLint のスタイル系ルールと衝突する場合の例
  // eslint-disable-next-line svelte/prefer-style-directive
  let doubled = $derived(count * 2);
</script>

<button onclick={() => count++}>{count}</button>
<p>{doubled}</p>

eslint.config.js の rules で該当ルール自体を 'off' にする方法もあります。プロジェクト全体で MCP を優先したい場合はこちらが現実的です。

{
  rules: {
    'svelte/prefer-style-directive': 'off'  // MCP が推奨する書き方を許容
  }
}

ESLint プラグインのメジャーアップデート#

eslint-plugin-svelte の major バージョンアップ時は breaking changes が多く、ルール名や挙動が変わることがあります。必ず以下を確認：

1. 公式リリースノート を熟読
2. プロジェクト全体で pnpm lint を走らせて、新しい違反が出ないか確認
3. svelte-autofixer との整合性を再確認

役割分担チートシート#

最後に、三点セットの役割分担を 1 枚にまとめます。

まとめ#

Svelte MCP × eslint-plugin-svelte × typescript-eslint の三点セットは、AI 時代の Svelte 5 開発における品質保証の完成形の一つです。それぞれ異なる層で動作し、冗長性によって互いの弱点をカバーします。

• Svelte MCP は AI 対話時の Svelte 5 準拠保証
• eslint-plugin-svelte は保存時・CI 時の静的解析
• typescript-eslint は TypeScript 固有の問題検出
• 役割分担を意識した設定 で、エディタの赤線を意味のあるものに絞る
• バージョン固定運用 で安定した開発体験を維持
• CI での二重チェック で PR 品質を担保

2026 年時点で全て実務投入可能な安定性に達しています。

次のステップ#

• Svelte MCP セットアップ — MCP 本体のインストール
• ツール詳解 — svelte-autofixer の詳しい挙動
• 開発環境との統合 — VS Code / Claude Code / CI/CD 統合
• ESLint + Prettier 設定 — 基本セットアップの復習