ESLint/Prettier/型チェックをCIに入れて品質を保つ方法（Next.js対応）

なぜCIでESLint/Prettier/型チェックを回すと「品質」と「コスト」が同時に良くなるのか

Webサイトや業務システムの改修が増えてくると、「小さな修正のはずが、別の画面が壊れた」「担当者が変わるとコードの書き方がバラバラで読みづらい」「レビューで指摘が多くて進まない」といった“地味な手戻り”が積み重なります。これが、納期遅延や追加費用、運用負荷の増大につながります。CI（継続的インテグレーション）にESLint/Prettier/型チェックを組み込み、毎回自動で確認すると、こうした手戻りの原因を早い段階で潰せます。

特にNext.jsは、画面（フロントエンド）とAPI、ビルド設定、ルーティングなどが一体になりやすい分、変更点が波及しやすい特徴があります。そこで、次の3点を“自動の門番”にします。

• ESLint：危険な書き方・バグになりやすい癖を検出する（例：未使用変数、依存配列漏れ、非推奨APIなど）
• Prettier：見た目（インデントや改行）を統一し、レビューでの無駄な指摘を減らす
• 型チェック（TypeScript）：データの形の不一致を実行前に検出し、仕様変更時の事故を減らす

これらは、開発者の“気をつける”に頼るのではなく、仕組みで担保する考え方です。情シスや非エンジニアの管理者視点でも、品質が「人」ではなく「ルール」に依存する状態にできるため、属人化リスクの低減という意味でも効果が大きいです。

Next.jsプロジェクトでの全体像：何を、どのタイミングで、どこまで厳しくするか

導入時に迷いやすいのが、「何を必須にして、どこまで厳しくするか」です。結論から言うと、Next.jsでは次の方針が実務的です。

• ローカル（開発者PC）：保存時にPrettier、コミット前に軽いLint（任意）
• CI（GitHub Actionsなど）：PR（レビュー依頼）時にESLint・型チェック・テストを必須
• マージ（本番反映）条件：CIが全部通らないとマージできないようにする

ポイントは「CIを最終防衛ライン」にしつつ、開発者の手元では邪魔をしすぎないことです。厳しすぎるルールは反発を生み、形骸化しやすくなります。逆に緩すぎると導入した意味が薄れます。

運用でよくある落とし穴は、次の3つです。

• フォーマット指摘がレビューを占領：Prettierを自動化せず、人が指摘して疲弊
• 型が曖昧なまま拡張：anyの濫用で“型チェックしているつもり”になる
• CIが遅すぎる：チェック項目が増えすぎ、待ち時間が長くなり形骸化

本記事では、Next.jsでの標準的な設定例と、CIに載せるための具体手順、そして「厳しさの調整」「失敗回避」をセットで解説します。ベンダー管理の観点では、「CIで何を必須にしているか」を契約や受け入れ基準に落とし込めるのもメリットです。

ESLint：事故を未然に防ぐ“ルール検査”をNext.jsで安定運用する

ESLintは、単なる「書き方の好み」ではなく、バグや保守性低下につながるパターンを検知します。Next.jsでは公式のLintサポートがあり、基本はそれに乗るのが安全です。導入・運用の要点は次の通りです。

推奨の導入（Next.js標準に寄せる）

Next.jsプロジェクトでは、ESLint設定が入っていなければ導入できます。一般に以下の流れになります。

• ESLintの設定ファイル（例：.eslintrc.jsonやeslint.config.mjs）を用意
• Next.js推奨のルールセット（next/core-web-vitals等）を有効化
• CIでnext lintまたはeslintを実行

Next.jsのLintは、React/Next特有の落とし穴（画像最適化、リンク、hooksの依存配列など）に寄った検知が含まれます。まずは標準ルールを有効化し、例外を最小限にするのが現場で揉めにくい進め方です。

現場で効くルールの考え方（厳しさの調整）

経営・情シスの視点では、「ルールが厳しすぎると開発が止まるのでは？」が心配になることがあります。ここは段階導入が有効です。

• 最初はエラー（必須）を絞る：致命的バグにつながるものだけをerrorに
• 警告（warning）で様子を見る：チームが慣れたらerrorへ昇格
• プロジェクト事情の例外を明文化：無効化するなら理由をコメントで残す

例えば、既存コードが多い案件でいきなり全ルールを厳格化すると、警告が大量に出てPRが止まります。そこで「新規・変更ファイルだけ厳格」「段階的に直す」など、運用設計の工夫が重要です。

CIで必須にする場合の注意

CIにESLintを入れると、通らない限りマージできないようにできます。これは品質担保として強力ですが、次の点は事前に決めておくと揉めにくいです。

• 例外対応のルール：緊急障害のホットフィックスは一時的にどう扱うか
• レビュー基準：Lintエラーは「修正必須」、warningは「要相談」など
• 責任分界：ルール改定の承認者（情シス／開発リード）を決める

単にツールを入れるだけでなく、意思決定の手順まで決めると、外部ベンダーや複数チームでも安定して回ります。

Prettier：レビュー工数を減らし、属人性を消す“見た目の統一”

Prettierは、コードの見た目（インデント、改行、カンマの付け方等）を自動で揃えるツールです。非エンジニアの方には些細に見えるかもしれませんが、運用上の効果は大きく、「レビューでの消耗」を減らし、本来見るべきロジックの議論に時間を回せるようになります。

なぜ“見た目”が重要なのか（業務シーンの例）

例えば、担当者Aは「ダブルクォート」、担当者Bは「シングルクォート」、担当者Cは行末カンマの有無が違う、という状態だと、修正のたびに差分（変更箇所）が大きく見えます。すると、レビューアーは「どこが本当に変わったのか」を追いづらくなり、確認漏れが起きやすくなります。

Prettierが入ると、保存時・コミット時・CI時のいずれかで自動整形されるため、差分が読みやすくなります。結果として、次が改善します。

• レビューの指摘が「体裁」から「品質・仕様」に寄る
• 引き継ぎ時にコードが読みやすい
• 軽微修正でも安心してリリースできる

ESLintとの役割分担（よくある混乱を防ぐ）

導入で混乱しやすいのが「ESLintとPrettier、どっちが整形を担当するの？」です。実務では、整形はPrettier、危険検知はESLintと役割を分けるのが一般的です。両方が同じ領域に口を出すと、設定が衝突し、CIで落ち続ける原因になります。

そのため、ESLint側でフォーマット系ルールを抑制する設定（Prettierと競合しないための設定）を入れることが多いです。Next.jsでもこの整理をしておくと、チームが増えても運用が崩れにくくなります。

CIに入れるときの現実的なライン

Prettierは「CIでチェック（差分があれば落とす）」の運用もできますが、現場では次のどちらかが多いです。

• 推奨：開発者の保存時に自動整形＋CIでチェック（ミスの取りこぼし防止）
• 簡易：CIだけでチェック（ローカル環境差を吸収したい場合）

どちらでも良いのですが、CIで落ちた場合に「直し方が分からない」とならないよう、READMEに「整形コマンド」や「エディタ設定（VS Code等）」の案内を用意しておくと、非エンジニアが混じる組織でもトラブルが減ります。

型チェック（TypeScript）：仕様変更に強いNext.jsにするための“保険”

型チェックは、ざっくり言うと「データの形を事前に約束して、ズレたらエラーにする」仕組みです。例えば「金額は数字」「日付は文字列」「顧客IDは必須」といった約束です。人間の目で全ケースを確認する代わりに、コンピュータが自動で矛盾を検出します。

Next.jsはAPIと画面が同じリポジトリで管理されやすく、仕様変更（項目追加・削除）が頻繁に起きます。そのとき型チェックがないと、「APIの返却項目を変えたのに画面側が古いまま」という事故が起きがちです。型チェックをCIに入れると、マージ前に検知できます。

Next.jsで型チェックをCIに入れる基本

TypeScriptを使っている場合、CIでは通常tsc --noEmit（ビルド成果物は出さず、チェックだけ）を回します。Next.jsではnext buildでも型チェックが走ることがありますが、ビルドは重いので、型チェックを独立させると原因切り分けがしやすくなります。

運用上のコツは次の通りです。

• strict（厳格モード）は段階導入：既存コードが多いと一気に直せない
• anyの運用ルール：暫定的に許す場合は期限・範囲を決める
• API境界を型で固定：画面↔API、外部サービス連携の型を明確に

「型があるのにバグが起きる」を減らす考え方

型チェックは万能ではなく、「数値の範囲が不正（マイナス）」や「業務ルール（締め日を過ぎた）」のような内容までは保証しません。ここは、バリデーション（入力値検証）やテストと組み合わせます。ただし、型チェックだけでも、次のような“初歩的だが致命傷になりやすい”事故を減らせます。

• 存在しないプロパティを参照して画面が落ちる
• 文字列として扱っていたものを数値に変更し、計算が壊れる
• 必須項目を追加したのに、保存処理が未対応

情シス・管理者視点では、型チェックは「担当者が変わっても一定品質を保つ」ための仕組みとして捉えると分かりやすいです。

CI（GitHub Actions例）：PRで自動チェックし、通らないとマージできない状態を作る

CIは、GitHubなどにコードを上げたタイミングで自動実行されるチェック機構です。ここでESLint/Prettier/型チェック（必要に応じてテスト）を回し、結果がOKならマージ可、NGなら差し戻しにします。“人の確認”に頼らず、一定の品質ゲートを通過したものだけが本流に入る状態になります。

最低限のチェック項目（Next.jsでの現実解）

• 依存関係のインストール：npm ciやpnpm install --frozen-lockfileなど、ロックファイル前提で再現性を確保
• Lint：next lint（またはeslint .）
• フォーマット：prettier --check .
• 型チェック：tsc --noEmit
• （任意）テスト：ユニットテストやE2Eテストがあるなら追加

「どれを必須にするか」は組織の成熟度で調整しますが、まずはLint＋型チェックを必須にするだけでも効果が出ます。Prettierはローカル整形が徹底できていればCI必須でなくても良いものの、外部ベンダーが複数いる場合はCIでもチェックしておくと揉めにくいです。

GitHub Actionsの例（そのまま使える雛形）

以下はNext.js（Node.js）で、PR時にLint/Prettier/型チェックを回す最小構成の例です。パッケージマネージャはnpm想定ですが、pnpm/yarnに置き換え可能です。

name: quality-check

on:
  pull_request:
    branches: [ "main" ]

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

      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Lint (Next.js)
        run: npm run lint

      - name: Format check (Prettier)
        run: npm run format:check

      - name: Type check (TypeScript)
        run: npm run typecheck

このCIが期待通り動くように、package.jsonに以下のようなスクリプトを用意します（例）。

{
  "scripts": {
    "lint": "next lint",
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "typecheck": "tsc --noEmit"
  }
}

ここまでできたら、GitHubのブランチ保護（Branch protection rules）で「CIが成功しないとマージできない」設定にします。これにより、レビューの抜け漏れや、忙しさによる妥協が起きにくくなります。

CIが遅い・落ち続ける問題への対策

• キャッシュを使う：依存関係のダウンロード時間を短縮
• ジョブを分割しすぎない：並列化は有効だが、管理が複雑になると逆効果
• 失敗の原因が分かるログ：どのコマンドで落ちたか明確に

CIは「入れて終わり」ではなく、開発体験を損なわない速度・分かりやすさが重要です。特に情シス主導で導入する場合、“現場が回る設計”がないと反発を生みやすいため、最初は小さく始め、効果が見えたら強化する流れが現実的です。

導入後の運用：ルールの更新、例外、外部ベンダー管理まで含めて品質を“継続”させる

ESLint/Prettier/型チェックをCIに入れる目的は、短期的にエラーを減らすことだけではありません。中長期で、保守コストを抑え、改修のスピードと安全性を両立することです。そのためには、運用ルールを軽くでも良いので決めておくのが効果的です。

ルールは「固定」ではなく「育てる」

事業や業務が変われば、画面やAPIの作り方も変わります。ルールも同様に、最初の正解がずっと正しいとは限りません。そこで次の運用が効きます。

• 月1回などの見直し：Lintのwarningをerrorにするか、逆に緩めるかを判断
• 変更はPRで：ルール変更こそレビュー対象（影響範囲が広い）
• “なぜ”を残す：無効化・例外の理由を設定ファイルにコメント

例外（緊急対応）をどう扱うか

障害対応で一刻も早い修正が必要なとき、CIが壁になることがあります。ここは「例外を認める」のではなく、例外の手順を決めて、監査可能にするのがポイントです。

• 緊急時は一時的にルールを緩めるのではなく、最小修正でCIを通す
• どうしても難しい場合は、承認者（情シス責任者など）を決めた上で例外マージ
• 例外対応は必ず“後追いチケット”で是正（技術的負債を返す）

外部ベンダー/複数チームでの受け入れ基準にする

ベンダー管理でよくある課題は、「納品物の品質が担当者によって違う」「レビューが属人化する」ことです。CIのチェック項目を受け入れ基準にしておくと、次が明確になります。

• 納品の定義：CIが通っていること（Lint/型チェック/テスト）
• 品質の可視化：PRの履歴とCIログが証跡になる
• 追加費用の抑制：後から直すより、早期に機械的に検出する方が安い

Next.jsのプロジェクトはスピード感が出やすい反面、ルールがないと変更が積み重なって壊れやすくなります。CIを中心に「壊れにくい開発プロセス」を作ることが、結果として事業の安定稼働につながります。

まとめ

ESLint/Prettier/型チェックをCIに入れると、Next.js開発で起きがちな「手戻り」「属人化」「レビュー疲れ」「仕様変更による事故」を、仕組みで減らせます。特に専門知識がない立場から見ると、品質を“人の頑張り”に依存させず、自動チェックを通ったものだけが本番に近づく状態を作れるのが最大の価値です。

• ESLint：バグになりやすい書き方を検知し、事故を未然に防ぐ
• Prettier：見た目を統一し、レビュー工数と差分の読みづらさを減らす
• 型チェック：APIや画面の仕様変更に強くし、実行前に矛盾を見つける
• CI：PR時に自動で回し、通らないものはマージできないようにする

導入のコツは、最初から完璧を目指さず、小さく始めて段階的に厳格化することです。社内開発でも外部委託でも、受け入れ基準としてCIのチェック項目を定義すると、品質とスピードの両方が安定します。