flake8 って何？一言でいうと「コードの赤ペン先生」
flake8 は、Python のコードを自動でチェックしてくれる「リンター（Linter）」です。
「文法的には動くけど、読みづらい・バグの元になりそう」なところを機械的に見つけて、番号付きで指摘してくれます。
具体的には、PEP 8 というスタイルガイドに沿っているか、未使用の変数や import がないか、行が長すぎないか、などをチェックします。
人間のコードレビューの前に flake8 を通しておくと、「機械でチェックできるところ」は先に片付くので、レビューでは設計や仕様の話に集中しやすくなります。
まずは動かしてみるイメージから
わざと「ダメなコード」を書いて flake8 に怒らせてみる
例として、こんなファイルを用意します。
# bad_sample.py
import os, sys # 未使用の import をわざと書く
def add(a,b):
return a+b
def sub(a, b):
return a-b
long_variable_name = "これはとてもとても長い文字列で、80文字を余裕で超えてしまうような例です。だからflake8に怒られます。"
このコードには、典型的な「flake8 に怒られるポイント」が詰まっています。
未使用の import（os, sys）
インデントが揃っていない（add の中身）
関数定義の間に空行が足りない
1 行が長すぎる
ここで flake8 を実行すると、だいたいこんな感じのメッセージが出ます（イメージ）:
bad_sample.py:3:1: F401 'os' imported but unused
bad_sample.py:3:5: F401 'sys' imported but unused
bad_sample.py:5:1: E302 expected 2 blank lines, found 0
bad_sample.py:5:12: E231 missing whitespace after ','
bad_sample.py:6:3: E111 indentation is not a multiple of four
bad_sample.py:8:1: E501 line too long (120 > 79 characters)
この「F401」「E302」「E501」みたいなコードが、flake8 の指摘の種類です。
最初は意味が分からなくても大丈夫です。
よく出るものから少しずつ覚えていけば十分です。
よく見るエラーコードを、初心者向けにかみ砕く
E501: 行が長すぎる（line too long）
E501 line too long (120 > 79 characters) は、「1 行が長すぎるよ」という指摘です。
PEP 8 では「1 行は 79 文字まで」が推奨なので、それを超えると E501 が出ます。
さっきの例だと、長い日本語文字列が原因でした。
対処としては、例えばこう分割します。
long_variable_name = (
"これはとてもとても長い文字列で、80文字を余裕で超えてしまうような例です。"
"だからflake8に怒られます。"
)
カッコで囲んで複数行に分けると、Python は自動で連結してくれます。
URL や長いメッセージなども、このパターンでよく直します。
どうしても分割したくない場合は、設定で E501 を無視することもできますが、
「基本は分割して読みやすくする」がオススメです。
F401: 未使用の import
F401 'os' imported but unused は、「import したけど使ってないよ」という指摘です。
これはかなり重要で、未使用の import が多いと、
どのモジュールが本当に必要なのか分かりにくい
リファクタリング時に「本当に使っているのか」が判断しづらい
といった問題が出ます。
対処はシンプルで、「使っていないなら消す」です。
# before
import os, sys
# after（どちらも使っていないなら削除）
# import os, sys
もし将来使う予定でも、「使うときに import する」で十分です。
flake8 に怒られたら、「今は本当に必要か？」を一度立ち止まって考える癖をつけると、コードがスッキリしていきます。
E302: 関数の前に空行が足りない
E302 expected 2 blank lines, found 0 は、「トップレベルの関数やクラスの前には空行を 2 行入れてね」という PEP 8 のルールです。
さっきの例だと、こうなっていました。
def add(a, b):
return a + b
def sub(a, b):
return a - b
これを、こう直します。
def add(a, b):
return a + b
def sub(a, b):
return a - b
「関数と関数の間は 2 行空ける」と覚えておくと、読みやすさも上がります。
コードが「かたまり」として視覚的に分かれるので、スクロールしながらでも追いやすくなります。
flake8 とフォーマッタ（black など）の関係
flake8 は「指摘」、black は「自動整形」
よく一緒に名前が出てくるのが、フォーマッタの black です。
ざっくり役割を分けると、
flake8
コードをチェックして「ここおかしいよ」と教えてくれる
自動では直さない（あくまで指摘）
black
コードを自動で整形してくれる
インデントや空白、改行位置などを「いい感じ」に揃えてくれる
という違いがあります。
実務では、
black で自動整形 → flake8 で残りの問題をチェック
という流れがかなり定番です。
インデントや空白の細かいルールは black に任せてしまい、
flake8 では「未使用の変数」「危険な書き方」「スタイル違反の残り」を見る、というイメージです。
「うるさすぎる」と感じたときの付き合い方
全無視は危険、でも「調整」はしていい
flake8 を入れた直後は、警告が多すぎて「うるさい…」と感じることがよくあります。
特に E501（行が長い）は、コメントや長い文字列で頻発しがちです。
そういうときにやりがちなのが、「全部無視する」ですが、
それをやると flake8 を入れた意味がなくなってしまいます。
現実的には、
プロジェクト全体で「無視するルール」と「守るルール」を決める
設定ファイル（.flake8 など）で ignore や max-line-length を調整する
どうしても例外にしたい行だけ # noqa で個別に無視する
といった「チューニング」をします。
例えば、行の長さだけ少し緩めたいなら、設定でこう書けます。
# .flake8
[flake8]
max-line-length = 100
あるいは、「この行だけは長くても許してほしい」というときは、末尾に # noqa: E501 を付けます。
url = "https://example.com/very/very/long/url/that/is/hard/to/wrap/properly" # noqa: E501
大事なのは、「なぜ無視するのか」を自分で説明できる状態にしておくことです。
「面倒だから全部無視」ではなく、「ここは例外にする理由がある」と言えるかどうかが、設計・品質のセンスにもつながります。
flake8 を「上達の道具」として使う
エラーコードを「学習のきっかけ」にする
初心者のうちは、flake8 のメッセージを「怒られている」と感じがちですが、
実はかなり優秀な先生です。
E501 をきっかけに「行の分割の仕方」を覚える
F401 をきっかけに「未使用の import を残さない癖」がつく
E302 をきっかけに「空行でコードをブロック分けする感覚」が身につく
こうやって、一つひとつのエラーコードが「設計・可読性のレッスン」になっていきます。
慣れてくると、コードを書いている時点で
「これ E501 出そうだな」「ここ F401 になるな」
と予測できるようになり、自然と「lint に怒られない書き方」が身についていきます。
コードレビューの前に flake8 を通す習慣
チーム開発では、プルリクエストを出す前に、
テストを回す
flake8（＋フォーマッタ）を通す
をセットにしておくと、レビューがかなりスムーズになります。
レビューで「インデントずれてます」「未使用の import 消してください」と言われるのは、正直もったいないです。
そういう「機械でチェックできるところ」は flake8 に任せて、
人間同士のレビューは「設計」「仕様」「テストの観点」に時間を使った方が、あなたの成長にもつながります。
まとめ（flake8 は「うるさいけど、めちゃくちゃ優秀な先生」）
初心者目線で flake8 を整理すると、こうなります。
Python コードを PEP 8 や基本的な品質ルールに照らしてチェックしてくれるリンターで、未使用の import や行の長さ、インデントなどを番号付きで指摘してくれる。
E501（行が長い）、F401（未使用 import）、E302（空行不足）など、よく出るエラーをきっかけに「読みやすい書き方」が身についていく。
うるさく感じたときは、設定ファイルや # noqa で「どこまで厳しくするか」を調整しつつ、意味のあるルールはちゃんと守るのが大事。
black などのフォーマッタと組み合わせて、「自動整形 → flake8 でチェック → 人間のレビュー」という流れにすると、設計やテストに集中しやすくなる。
もしよければ、あなたが今書いている Python ファイルの一部を（名前などを変えて）貼ってくれれば、
「flake8 がどう指摘しそうか」「それをどう直すと読みやすくなるか」を、実際のコードを使って一緒に見ていきましょう。