Tailwind CSS を使った開発は、ユーティリティファーストの考え方によって驚くほどスピーディにスタイリングできるのが魅力ですよね。しかし、プロジェクトが大きくなるにつれて「存在しないクラス名を書いてしまった」「クラス名の順序がバラバラで読みにくい」といった問題が発生しがちです。そんな運用上の課題を解決してくれるのが、eslint-plugin-tailwindcss というプラグインなのです。

本記事では、eslint-plugin-tailwindcss の導入から具体的な設定方法、実際のエラー検出例まで、初心者の方にもわかりやすく解説していきます。

背景

Tailwind CSS の普及と運用課題

Tailwind CSS は、ユーティリティクラスを HTML に直接記述することで、CSS ファイルを書かずにスタイリングできるフレームワークです。近年、Next.js や React プロジェクトでの採用が急速に広がっており、開発スピードの向上に大きく貢献しています。

しかし、便利さの裏側には運用上の課題も存在します。

よくある運用トラブル

Tailwind CSS を使っていると、以下のような問題に遭遇することがあります。

• 存在しないクラス名の使用: text-center を text-centre と誤記してもビルドエラーにならない
• クラス名の順序の不統一: 同じスタイルでも人によって p-4 m-2 や m-2 p-4 など順序が異なる
• 推奨されないクラスの使用: 廃止予定のクラスや、より適切な代替クラスがあるケースに気づけない
• 重複したクラス名: p-4 p-2 のように同じプロパティのクラスが重複してしまう

以下の図は、Tailwind CSS プロジェクトで発生しがちな品質課題を示しています。

mermaidCopy codeflowchart TD
  dev["開発者がコードを記述"]
  typo["タイポ・誤字"]
  order["クラス順序バラバラ"]
  duplicate["重複クラス"]
  deprecated["非推奨クラス"]

  dev --> typo
  dev --> order
  dev --> duplicate
  dev --> deprecated

  typo --> runtime["実行時に気づく"]
  order --> review["レビュー時に指摘"]
  duplicate --> confusion["意図しない挙動"]
  deprecated --> maintenance["メンテナンス性低下"]

  runtime --> problem["品質問題"]
  review --> problem
  confusion --> problem
  maintenance --> problem

図の要点:

• 開発時には気づきにくいミスが複数のルートで品質問題につながる
• 実行時やレビュー時まで問題が発見されない非効率性
• 早期検出の仕組みが必要

これらの問題は、実行時まで気づかないことが多く、レビュー時の負担増加やバグの原因となります。そこで登場するのが ESLint による静的解析 です。

課題

人的チェックの限界

Tailwind CSS のクラス名は非常に多く、公式ドキュメントに掲載されているものだけでも数百種類以上あります。これらすべてを人間がチェックするのは現実的ではありません。

具体的な課題

プロジェクト運用において、以下のような課題が顕在化します。

#	課題	影響	発見タイミング
1	タイポや誤字によるクラス名ミス	スタイルが適用されない	実行時・目視確認時
2	クラス順序の不統一	コードの可読性低下	レビュー時
3	同一プロパティの重複クラス	予期しない優先順位	バグ発生時
4	非推奨クラスの使用	将来的な破壊的変更リスク	バージョンアップ時
5	カスタム設定との不整合	設定値が反映されない	実装後の確認時

チーム開発での問題拡大

個人開発であればミスに気づきやすいですが、チーム開発では以下の理由で問題が拡大します。

• メンバーごとにクラス名の記述順序が異なる
• 新しいメンバーが Tailwind CSS のベストプラクティスを知らない
• レビュアーがすべてのクラス名の妥当性をチェックできない

以下の図は、課題が発見されるまでの時間軸と影響範囲を示しています。

mermaidCopy codeflowchart LR
  write["コード記述"] --> commit["コミット"]
  commit --> review["レビュー"]
  review --> merge["マージ"]
  merge --> deploy["デプロイ"]
  deploy --> user["ユーザー利用"]

  write -.->|理想の検出| early["早期発見<br/>影響小"]
  review -.->|現状の検出| middle["レビュー発見<br/>手戻り中"]
  user -.->|最悪の検出| late["本番発見<br/>影響大"]

  style early fill:#90EE90
  style middle fill:#FFD700
  style late fill:#FF6B6B

図の要点:

• コード記述時に検出できれば影響は最小限
• レビュー時の検出は手戻りコストが発生
• 本番環境での発見は最も影響が大きい

これらの課題を解決するために、自動化された検証の仕組みが必要になります。

解決策

eslint-plugin-tailwindcss の導入

eslint-plugin-tailwindcss は、Tailwind CSS のクラス名を ESLint で静的に解析し、コーディング時にリアルタイムでエラーや警告を表示してくれるプラグインです。

このプラグインを導入することで、前述の課題をコーディング段階で自動的に検出できるようになります。

主な機能

eslint-plugin-tailwindcss が提供する主要な機能は以下の通りです。

#	ルール名	機能	効果
1	classnames-order	クラス名を推奨順序で並べ替え	可読性向上、統一性確保
2	no-custom-classname	存在しないクラス名を検出	タイポ防止
3	no-contradicting-classname	矛盾するクラスの組み合わせを検出	バグ防止
4	enforces-negative-arbitrary-values	負の値の記法を統一	記述方法の統一
5	enforces-shorthand	省略記法の利用を推奨	コード簡潔化

解決の仕組み

eslint-plugin-tailwindcss は、以下のフローで問題を検出します。

mermaidCopy codeflowchart TD
  code["コード記述"] --> eslint["ESLint 実行"]
  eslint --> plugin["eslint-plugin-tailwindcss"]

  plugin --> parse["HTML/JSX からクラス名抽出"]
  parse --> config["tailwind.config.js 読み込み"]

  config --> check1["存在チェック"]
  config --> check2["順序チェック"]
  config --> check3["矛盾チェック"]
  config --> check4["推奨記法チェック"]

  check1 --> result["検証結果"]
  check2 --> result
  check3 --> result
  check4 --> result

  result --> error["エラー表示"]
  result --> warn["警告表示"]
  result --> auto["自動修正（--fix）"]

図の要点:

• プロジェクト固有の tailwind.config.js を参照して検証
• 複数の観点から同時にチェック
• 自動修正機能により手動修正の手間を削減

導入のメリット

eslint-plugin-tailwindcss を導入することで、以下のメリットが得られます。

開発効率の向上: エディタ上でリアルタイムにエラーが表示されるため、ブラウザで確認する前に問題を修正できます。これにより、開発のフィードバックループが大幅に短縮されるでしょう。

コード品質の均一化: 自動修正機能により、チーム全体で統一されたクラス名の順序が保たれます。レビュー時の指摘事項が減り、本質的な議論に時間を使えるようになりますね。

学習コストの低下: 新しいメンバーがプロジェクトに参加した際、ESLint の警告を通じて Tailwind CSS のベストプラクティスを学べます。ドキュメントを読む時間が削減されるのです。

具体例

インストール手順

まずは、プロジェクトに eslint-plugin-tailwindcss をインストールします。

パッケージのインストール

typescriptCopy codeyarn add -D eslint-plugin-tailwindcss

このコマンドで、eslint-plugin-tailwindcss が開発依存関係としてプロジェクトに追加されます。

ESLint 設定ファイルの編集

次に、ESLint の設定ファイルにプラグインを追加します。プロジェクトに .eslintrc.js または .eslintrc.json があるはずです。

.eslintrc.js への追加

javascriptCopy codemodule.exports = {
  // 既存の設定...
  extends: [
    // 既存の extends 設定
    'plugin:tailwindcss/recommended',
  ],
  plugins: [
    // 既存の plugins 設定
    'tailwindcss',
  ],
};

extends に plugin:tailwindcss​/​recommended を追加することで、推奨されるルールセットが自動的に適用されます。

個別ルールのカスタマイズ

必要に応じて、個別のルールを上書きできます。

javascriptCopy codemodule.exports = {
  extends: ['plugin:tailwindcss/recommended'],
  plugins: ['tailwindcss'],
  rules: {
    // クラス名の順序を強制（autofix 有効）
    'tailwindcss/classnames-order': 'warn',

    // カスタムクラス名の使用を警告
    'tailwindcss/no-custom-classname': 'warn',

    // 矛盾するクラスの組み合わせをエラー
    'tailwindcss/no-contradicting-classname': 'error',
  },
};

ルールの重要度は error（エラー）、warn（警告）、off（無効）から選択できます。

tailwind.config.js との連携

eslint-plugin-tailwindcss は、プロジェクトの tailwind.config.js を自動的に読み込みます。カスタム設定がある場合でも、正しく検証してくれるのです。

tailwind.config.js の例

javascriptCopy code/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ['./src/**/*.{js,ts,jsx,tsx}'],
  theme: {
    extend: {
      colors: {
        brand: '#3B82F6',
      },
    },
  },
  plugins: [],
};

この設定ファイルで colors.brand を追加した場合、text-brand や bg-brand といったクラス名が有効として認識されます。

実際のエラー検出例

ここからは、実際にどのようなエラーが検出されるかを見ていきましょう。

ケース 1: 存在しないクラス名の使用

jsxCopy code// ❌ エラー: 'text-centre' は存在しないクラス名
<div className='text-centre p-4'>Hello World</div>

ESLint はこのコードに対して以下のような警告を表示します。

csharpCopy code'text-centre' is not a valid Tailwind CSS class

正しいクラス名は text-center です。

jsxCopy code// ✅ 修正後: 正しいクラス名を使用
<div className='text-center p-4'>Hello World</div>

ケース 2: クラス名の順序不統一

jsxCopy code// ⚠️ 警告: クラスの順序が推奨されていない
<div className='p-4 m-2 text-blue-500 flex'>Content</div>

eslint-plugin-tailwindcss は、Tailwind CSS の公式で推奨されるクラス順序を基準に並べ替えを提案します。

jsxCopy code// ✅ 自動修正後: 推奨順序に並び替え
<div className='flex m-2 p-4 text-blue-500'>Content</div>

--fix オプションを使えば、自動的に修正されます。

bashCopy codeyarn eslint --fix ./src

ケース 3: 矛盾するクラスの組み合わせ

jsxCopy code// ❌ エラー: 'flex' と 'block' は矛盾する
<div className='flex block p-4'>Content</div>

flex と block は同時に指定できません。ESLint はこの矛盾を検出してエラーを表示します。

sqlCopy codeClassnames 'flex', 'block' are conflicting

jsxCopy code// ✅ 修正後: どちらか一方を使用
<div className='flex p-4'>Content</div>

ケース 4: 重複したクラス名

jsxCopy code// ⚠️ 警告: 同じプロパティのクラスが重複
<div className='p-4 p-2 m-4'>Content</div>

同じプロパティ（padding）のクラスが重複している場合、後ろのクラスが優先されますが、意図的でない限り避けるべきです。

jsxCopy code// ✅ 修正後: 必要なクラスのみを記述
<div className='p-2 m-4'>Content</div>

エディタとの統合

eslint-plugin-tailwindcss は、VSCode や WebStorm などの主要なエディタと統合できます。

VSCode での設定

VSCode に ESLint 拡張機能をインストールしている場合、リアルタイムでエラーや警告が表示されます。

以下の図は、開発フローにおける検出タイミングを示しています。

mermaidCopy codesequenceDiagram
  participant Dev as 開発者
  participant Editor as エディタ
  participant ESLint as ESLint
  participant Plugin as eslint-plugin-tailwindcss

  Dev->>Editor: コードを入力
  Editor->>ESLint: ファイル保存
  ESLint->>Plugin: クラス名を解析
  Plugin->>Plugin: tailwind.config.js 読み込み
  Plugin->>Plugin: ルール検証
  Plugin-->>ESLint: 検証結果を返す
  ESLint-->>Editor: エラー/警告を表示
  Editor-->>Dev: 赤線・黄線で通知
  Dev->>Editor: 修正を実施
  Editor->>ESLint: 再検証
  ESLint-->>Editor: OK
  Editor-->>Dev: エラー解消

図の要点:

• ファイル保存のタイミングでリアルタイム検証
• エディタ上で即座にフィードバック
• 修正後すぐに再検証されるため、開発効率が向上

settings.json の推奨設定

VSCode の settings.json に以下を追加すると、保存時に自動修正が実行されます。

jsonCopy code{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ]
}

この設定により、ファイル保存時に自動的にクラス名の順序が整えられます。

CI/CD パイプラインへの組み込み

開発環境だけでなく、CI/CD パイプラインにも ESLint チェックを組み込むことで、品質を保証できます。

GitHub Actions の例

yamlCopy codename: Lint

on:
  pull_request:
    branches: [main]

jobs:
  eslint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: yarn install

      - name: Run ESLint
        run: yarn eslint ./src

このワークフローにより、プルリクエスト作成時に自動的に ESLint チェックが実行され、問題があればマージをブロックできます。

高度な設定例

より細かい制御が必要な場合は、ルールごとに詳細な設定を行えます。

ホワイトリストの設定

特定のカスタムクラスを許可したい場合は、ホワイトリストを設定できます。

javascriptCopy codemodule.exports = {
  extends: ['plugin:tailwindcss/recommended'],
  plugins: ['tailwindcss'],
  rules: {
    'tailwindcss/no-custom-classname': [
      'warn',
      {
        whitelist: ['custom-scrollbar', 'legacy-button'],
      },
    ],
  },
};

custom-scrollbar や legacy-button といったクラス名は、Tailwind CSS に存在しなくても警告が表示されなくなります。

特定のファイルを除外

一部のファイルで ESLint チェックをスキップしたい場合は、.eslintignore を使用します。

bashCopy code# サードパーティライブラリ
node_modules/

# 生成されたファイル
dist/
build/

# レガシーコード（段階的移行中）
src/legacy/

これにより、指定したディレクトリやファイルが ESLint のチェック対象から除外されます。

まとめ

本記事では、Tailwind CSS プロジェクトにおける運用課題と、それを解決する eslint-plugin-tailwindcss の導入方法について解説しました。

重要なポイント

早期検出の重要性: タイポや矛盾するクラスの組み合わせは、コーディング時に検出することで修正コストを大幅に削減できます。実行時やレビュー時まで問題を持ち越さないことが、開発効率向上の鍵となるでしょう。

自動化による品質向上: ESLint の自動修正機能により、クラス名の順序統一が自動化されます。チーム全体でコーディングスタイルが統一され、レビュー時の指摘が本質的な部分に集中できるようになりますね。

学習ツールとしての活用: 新しいメンバーにとって、ESLint の警告はベストプラクティスを学ぶ絶好の機会です。ドキュメントを読むだけでなく、実際のコードで学べるため、習得スピードが向上します。

導入の流れ

eslint-plugin-tailwindcss の導入は、以下のステップで完了します。

1. yarn add -D eslint-plugin-tailwindcss でパッケージをインストール
2. .eslintrc.js に plugin:tailwindcss​/​recommended を追加
3. エディタの ESLint 拡張機能を有効化
4. CI/CD パイプラインに ESLint チェックを組み込む

これだけで、Tailwind CSS のクラス名に関する多くの問題を自動的に検出できるようになるのです。

段階的な導入のすすめ

既存の大規模プロジェクトに導入する場合は、以下のような段階的なアプローチが効果的でしょう。

まずは警告レベルで導入し、既存のコードベースへの影響を最小限に抑えます。チームメンバーが警告に慣れてきたら、徐々にエラーレベルに引き上げていくのです。新規ファイルから厳格なルールを適用し、レガシーコードは .eslintignore で一時的に除外することも検討できますね。

最後に

Tailwind CSS は素晴らしいツールですが、適切な運用ルールがなければその恩恵を十分に受けられません。eslint-plugin-tailwindcss を活用することで、開発体験を損なうことなく、コード品質を維持できるようになります。

ぜひ、あなたのプロジェクトにも eslint-plugin-tailwindcss を導入して、より快適な Tailwind CSS 開発を実現してください。

関連リンク

• eslint-plugin-tailwindcss - GitHub
• Tailwind CSS 公式ドキュメント
• ESLint 公式ドキュメント
• Prettier と Tailwind CSS の併用ガイド