---
title: "PEP8とは？Pythonコーディング規約の基本ルールとチェックツール（Ruff対応）"
url: "https://www.issoh.co.jp/tech/details/3032/"
published: 2024-07-11
updated: 2026-07-18
categories: ["Python"]
publisher: "株式会社一創"
---

# PEP8とは？Pythonコーディング規約の基本ルールとチェックツール（Ruff対応）

PEP8（読み方はペップエイト）は、Pythonコードの書き方をそろえるための標準コーディング規約です。名称は「Python Enhancement Proposal 8」の略で、Pythonの改善提案（PEP）のうち番号8の文書です。2001年7月5日にGuido van Rossumらが公開して以来、Pythonコミュニティで事実上の共通ルールとして使われてきました。この記事では、PEP8の定義と目的、インデントや1行の文字数といった基本ルール、snake\_caseなどの命名規則、Ruffを中心としたチェックツール、VSCodeでの設定、Google Python Style Guideとの違い、そして「どこまで守るべきか」までを一度に整理します。

## まとめ：PEP8の要点

- **正体**：PEP8 = Python Enhancement Proposal 8。Python公式のコーディングスタイルガイドで、読み方はペップエイト。
- **基本ルール**：インデントは半角スペース4つ、1行は79文字（コメント・docstringは72文字）、演算子まわりの空白、importは1行1つでグループ分け。
- **命名規則**：変数・関数・メソッドはsnake\_case、クラスと例外はCapWords、定数はUPPER\_CASE、モジュール名は小文字（必要ならアンダーバー）。
- **チェックは自動化が前提**：2026年時点の主流はRuff。従来のflake8・pycodestyle・black・isortの役割を1本に統合し、桁違いに速い。旧「pep8」パッケージは2016年にpycodestyleへ改称済み。
- **守り方**：PEP8自身が「無分別な一貫性は避けよ」と述べている。厳守が目的ではなく、プロジェクト内の一貫性と可読性が優先。

以下で、それぞれのルールと現在のツール事情を具体的に見ていきます。

## PEP8とは何か（定義・読み方・略称）

PEPは「Python Enhancement Proposal（Python拡張提案）」の頭字語で、Python本体の仕様変更や指針をまとめた文書群です。番号が振られており、PEP8は番号8の文書としてコーディングスタイルを扱います。読み方は「ペップエイト」が一般的で、「PEP」の部分を「ペップ」と読みます。

作成は2001年7月5日、著者はPythonの生みの親であるGuido van Rossumに加え、Barry Warsaw、Alyssa Coghlanの3名です。PEP8が定めるのは「正しい書き方」ではなく「読みやすさをそろえるための取り決め」であり、文書の冒頭でも可読性（readability）を最優先に置くと明言しています。1人で書き捨てるスクリプトより、複数人が長期間触れるコードほど効果が大きいルールです。

## PEP8の主要ルール（インデント・行の長さ・空白・import）

PEP8で問い合わせの多い基本ルールは、性質の異なる複数の項目に分かれます。用途ごとに分けて押さえます。

### インデントは半角スペース4つ

1段のインデントに半角スペースを4つ使います。タブとスペースの混在は禁止で、Python3ではインデントにタブとスペースを混ぜると構文エラーになります。新規コードはスペースを使い、タブで書かれた既存コードに合わせる場合のみタブを許容する、という順序でPEP8は整理しています。

### 1行は79文字まで（コメント・docstringは72文字）

コード行は最大79文字、コメントとdocstringのような文章ブロックは最大72文字が上限です。古い端末の幅80文字に由来しますが、現在でもエディタを左右に分割したときやコードレビューの差分表示で効果があります。ただしこの数値は現場で最も緩められる項目でもあり、コードフォーマッタのBlackは既定88文字、Ruffのフォーマッタも88文字を既定にしています。チームで88や99に統一する運用も一般的です。

### 空白の入れ方

二項演算子の前後にはスペースを1つ入れ（`x = a + b`）、カンマの後ろにはスペース、前には入れません。関数呼び出しの丸括弧の直前や、インデックスの角括弧の直前にはスペースを置きません。キーワード引数のイコールの前後は、型注釈が無い場合はスペースを入れないのが原則です。

### importは1行に1つ、グループで分ける

import文はモジュールごとに行を分け、「標準ライブラリ → サードパーティ → 自作モジュール」の3グループに空行を挟んで並べます。`from module import *` のワイルドカードインポートは、名前空間に何が入るか不明瞭になるため避けます。この並べ替えは後述のツールが自動化してくれます。

```
# 悪い例
import sys, os
from mymodule import *

# 良い例
import os
import sys

import requests

from myapp import config
```

## PEP8の命名規則（snake\_case・CapWords・定数）

命名規則は、名前を見ただけで「変数か・クラスか・定数か」を区別できるようにするための取り決めです。対象ごとに使うスタイルが決まっています。

| 対象         | スタイル                    | 例                              |
| ---------- | ----------------------- | ------------------------------ |
| 変数・関数・メソッド | snake\_case（小文字＋アンダーバー） | user\_name, calculate\_total   |
| クラス・例外     | CapWords（PascalCase）    | DataProcessor, ValidationError |
| 定数         | UPPER\_CASE             | MAX\_RETRY, DEFAULT\_TIMEOUT   |
| モジュール      | 短い小文字（必要ならアンダーバー）       | data\_loader.py                |
| パッケージ      | 短い小文字（アンダーバー非推奨）        | myapp                          |

### 変数・関数はsnake\_case

変数名・関数名・メソッド名は、すべて小文字にして単語の区切りをアンダーバーでつなぎます。`getData` のようなcamelCaseはPythonでは使いません。短縮形や1文字名は避け、役割が分かる名前を選びます。

### クラスと例外はCapWords

クラス名と例外名は、各単語の頭文字を大文字にして連結するCapWords（PascalCaseとも呼ばれます）を使います。CapWordsとは、この「頭文字を大文字にして単語を続ける」書き方の呼び名です。例外クラスは末尾を `Error` でそろえると役割が伝わります。

```
class OrderProcessor:
    def process(self, orders):
        return [o for o in orders if o.is_valid]


class OrderValidationError(Exception):
    pass
```

### 定数とモジュール名

定数はモジュールの先頭でまとめて定義し、すべて大文字とアンダーバーで書きます。モジュール名（ファイル名）は短い小文字で、可読性が上がる場合だけアンダーバーを使います。パッケージ名（ディレクトリ名）は同じく小文字ですが、アンダーバーは避けるのが推奨です。「モジュール名にアンダーバーを使うべきか」という疑問には、**単語区切りで読みやすくなるなら使ってよい**のが公式の立場です。

## PEP8をチェック・自動整形するツール（Ruff・flake8・black）

PEP8は文書であって、それ自体がコードを検査するわけではありません。準拠しているかは専用ツールで自動チェックします。ここは数年で勢力図が変わった領域なので、現在の選択肢を役割で分けて押さえます。

### Linter（検査）とFormatter（整形）の違い

ツールは大きく2種類あります。**Linter**はスタイル違反や潜在的なバグを「指摘」するもの、**Formatter**はコードを規約どおりに「書き換える」ものです。flake8・pylint・pycodestyleはLinter、black・autopep8はFormatterに分類されます。両者は併用するのが一般的でした。

### 現在の主流はRuff

2026年時点でPythonのスタイル管理の中心になっているのがRuffです。Astral社がRust言語で開発したツールで、flake8・pycodestyle・isort・pydocstyle・pyupgrade・blackといった従来ツールの役割を1本に統合し、900種類以上のルールを備えます。既存のLinterやFormatterより10〜100倍速く、大規模なコードベースでも短時間で全ファイルを検査・整形できるのが採用が進んだ理由です。導入と実行はコマンド3つで完結します。

```
pip install ruff

# スタイル違反を検査
ruff check .

# 規約どおりに自動整形
ruff format .
```

### 従来ツールとpep8パッケージの改称

Ruff以前は、flake8（pycodestyle＋pyflakes＋複雑度チェックの統合）でLintし、blackやautopep8で整形し、isortでimportを並べ替える、という組み合わせが定番でした。今も広く使われており、既存プロジェクトで無理に乗り換える必要はありません。注意点として、かつて `pep8` という名前だったチェックツールは、規約そのものと紛らわしいため2016年にpycodestyleへ改称されています。現在 `pip install pep8` を案内する記事は情報が古いので、pycodestyleかRuffを使ってください。

| ツール         | 役割               | 特徴                        |
| ----------- | ---------------- | ------------------------- |
| Ruff        | Linter＋Formatter | Rust製・非常に高速・多くのツールを統合     |
| flake8      | Linter           | pycodestyle＋pyflakesの定番統合 |
| pycodestyle | Linter           | 旧pep8パッケージ。スタイル検査に特化      |
| black       | Formatter        | 設定を削ぎ落とした自動整形（既定88文字）     |
| autopep8    | Formatter        | pycodestyleの指摘を自動修正       |

## VSCodeでPEP8を適用する設定

VSCodeでは拡張機能と設定でPEP8チェックを常時働かせられます。現在はMicrosoft公式の「Ruff」拡張機能を入れ、保存時の自動整形とimport整理を有効にするのが最短です。`settings.json` に次を追加します。

```
{
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
      "source.organizeImports.ruff": "explicit"
    }
  }
}
```

従来のflake8で運用する場合は、Microsoftの「Flake8」拡張機能を入れ、1行の文字数上限などをワークスペース設定で調整します。いずれの場合も、保存のたびに違反が可視化・修正されるため、レビューでスタイルを指摘する手間が減ります。

## PEP8とGoogle Python Style Guideの違い

Pythonのスタイルガイドには、PEP8のほかにGoogleが公開するGoogle Python Style Guideがあります。大枠は共通しますが、細部が異なります。どちらか一方を採用し、社内で統一するのが実務上の答えです。

| 項目          | PEP8          | Google Python Style Guide   |
| ----------- | ------------- | --------------------------- |
| 1行の長さ       | 79文字          | 80文字                        |
| docstring形式 | 形式は限定しない      | ArgsやReturnsを明記するGoogleスタイル |
| 位置づけ        | Python全体の共通規約 | Google社内向けに調整した規約           |

公開ライブラリや一般的なプロジェクトはPEP8を基準にすれば十分です。docstringを機械的に整形したい、型注釈を厳密に運用したいといった要件がある場合に、Googleスタイルの一部を取り入れると扱いやすくなります。

## PEP8はどこまで守るべきか

PEP8を「絶対のルール」と捉えると、かえって可読性を損ないます。PEP8自身が冒頭で「A Foolish Consistency is the Hobgoblin of Little Minds（無分別な一貫性は狭量な精神の悪癖）」という有名な一節を掲げ、規約を破ってよい場面を明示しています。守るべきかを判断する基準は次のとおりです。

- **可読性が下がるとき**：ルールに従うことで逆に読みにくくなるなら、従わない方がよい。
- **既存コードと食い違うとき**：周囲がPEP8非準拠でも、一貫性のためその流儀に合わせる場面がある。
- **後方互換のため**：古いPythonバージョンと互換を保つ必要がある箇所。

優先順位は「プロジェクト内の一貫性 ＞ PEP8との一貫性」です。特に1行の文字数（E501）は、Black／Ruffの既定88文字やチーム標準の99文字に合わせて緩めるのが実務では普通です。そして、守るかどうかを人が毎回議論するのではなく、Ruffやpre-commitで自動化してレビューの争点から外すのが、最も生産的な付き合い方です。スタイルの正しさは機械に任せ、人はロジックのレビューに集中すべきです。

## よくある質問

### PEP8の読み方は何ですか？

「ペップエイト」と読みます。PEPの部分を「ペップ」、末尾の8を「エイト」と読むのが一般的です。

### PEP8とは何の略ですか？

「Python Enhancement Proposal 8」の略です。Pythonの改善提案（PEP）の8番目で、コーディングスタイルを定めた文書を指します。

### PEP8は必ず守らないといけませんか？

必須ではありません。PEP8自身が可読性を損なう場面や既存コードに合わせる場面では従わなくてよいと述べています。目的は厳守ではなく、プロジェクト内で一貫した読みやすいコードにすることです。

### pep8・pycodestyle・flake8・Ruffの違いは？

「pep8」は規約の名前であり、同名だったチェックツールは2016年にpycodestyleへ改称されました。flake8はpycodestyleなどを束ねたLinter、RuffはLinterとFormatterを1本に統合した高速なツールです。これから始めるならRuffが扱いやすい選択肢です。

### Pythonの1行は何文字までですか？

PEP8ではコード行が79文字、コメントとdocstringが72文字までです。ただしBlackやRuffのフォーマッタは既定で88文字を採用しており、チームで88や99に統一する運用も広く行われています。

## 関連記事

- [ESLintとは？VSCodeでの設定からflat config・Prettier連携まで解説【ESLint v10対応】](/tech/details/3286/)
- [Python 3.13の新機能まとめ｜JIT・フリースレッド・対話型シェルの要点と3.14との違い【2026年版】](/tech/details/4042/)
- [Python pathlibの使い方｜resolve・絶対パス取得・Path(\_\_file\_\_).resolve().parentとos.pathの違い](/tech/details/5986/)

---

出典: [PEP8とは？Pythonコーディング規約の基本ルールとチェックツール（Ruff対応）](<https://www.issoh.co.jp/tech/details/3032/>)（株式会社一創）