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

変数名・関数名・メソッド名は、すべて小文字にして単語の区切りをアンダーバーでつなぎます。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を使ってください。

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を基準にすれば十分です。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対応】
• Python 3.13の新機能まとめ｜JIT・フリースレッド・対話型シェルの要点と3.14との違い【2026年版】
• Python pathlibの使い方｜resolve・絶対パス取得・Path(__file__).resolve().parentとos.pathの違い