blackって何？一言でいうと「コード自動整形マシーン」
black は、Python のコードを「自動できれいな形に整えてくれるフォーマッタ」です。
flake8 が「ここおかしいよ」と指摘する先生だとしたら、
black は「黙って机をきれいに片付けてくれる人」です。
重要なのは、black は「好み」をほぼ受け付けないことです。
インデント、空白、改行位置、クォートの種類などを、
black のルールに従って“機械的に”揃えます。
「どう書くか」で悩む時間をゼロにして、
「何を書くか」に集中させるためのツールです。
まずは before / after を見てイメージをつかむ
black をかける前のコード
わざと「雑に」書いたコードを用意します。
def add(a,b,c=0):
if a>0 and b>0:
return a+b+c
else:
return a + b
インデントがバラバラ
スペースの有無がバラバラreturn の行も揃っていない
人間が読むと、ちょっとストレスがたまる形です。
black をかけた後のコード
このファイルに対して black を実行すると、こうなります。
def add(a, b, c=0):
if a > 0 and b > 0:
return a + b + c
else:
return a + b
インデントは 4 スペースで統一
カンマの後にスペースが入る
演算子の前後にもスペースが入るreturn の位置もきれいに揃う
「Python らしい読みやすい形」に、自動で整えてくれます。
ここで大事なのは、
「あなたの好みがどうであれ、black のルールに揃えられる」という点です。
black の一番大事な思想：「設定しない勇気」
ほぼ設定できないように作られている
多くのフォーマッタは、
行の長さ
クォートはシングルかダブルか
改行のスタイル
などを細かく設定できます。
でも black は、基本的に「設定させない」方向のツールです。
行の長さ（line-length）くらいは変えられますが、
それ以外は「black の流儀に従ってください」というスタンスです。
これは不親切ではなく、むしろ優しさです。
「どのスタイルにする？」とチームで議論しなくていい
「この書き方はアリかナシか」で揉めなくていい
「とりあえず black に通せば OK」という共通認識を持てる
つまり、「スタイルの議論」を丸ごと捨てられるのが、black の一番の価値です。
「自分の好み」と「チームの一貫性」
最初は、「この改行の仕方、あんまり好きじゃないな」と感じることもあります。
でも、そこをあえて飲み込んで、
「自分の好み」より「チーム全体の一貫性」を優先する
というマインドに切り替えると、一気に楽になります。
コードレビューで、
「ここは改行した方が…」
「ここはシングルクォートで…」
みたいな話を一切しなくてよくなる。
その分、設計やテストの話に時間を使える。
これは、長く開発を続けるほど効いてくるメリットです。
もう少し複雑な例で black の「クセ」を見る
複雑な引数や長い式の整形
例えば、こんなコードを書いたとします。
def create_user(id, name, email, is_active=True, is_admin=False, created_at=None, updated_at=None):
return {"id":id,"name":name,"email":email,"is_active":is_active,"is_admin":is_admin,"created_at":created_at,"updated_at":updated_at}
これに black をかけると、だいたいこうなります。
def create_user(
id,
name,
email,
is_active=True,
is_admin=False,
created_at=None,
updated_at=None,
):
return {
"id": id,
"name": name,
"email": email,
"is_active": is_active,
"is_admin": is_admin,
"created_at": created_at,
"updated_at": updated_at,
}
ポイントは、
引数が多くて長くなると、自動で縦に並べてくれる
辞書リテラルも、1 行が長くなりそうなら縦に展開してくれる
カンマやコロンの前後のスペースも全部揃えてくれる
というところです。
自分で「どこで改行しようかな」と悩まなくていい。
black に任せておけば、「まあ読める形」にしてくれます。
black と flake8 を一緒に使うとどうなるか
役割分担をはっきりさせる
さっきも少し触れましたが、
black と flake8 はセットで使うとかなり強いです。
black
インデント・空白・改行・クォートなど「見た目」を自動整形する
スタイルの統一担当
flake8
未使用の変数・import、危険な書き方、PEP8 違反などを検出する
静的チェック担当
実務では、
black でコードを整形する
flake8（＋mypy など）でコードをチェックする
そのうえで人間がレビューする
という三段構えがよく使われます。
「black を先にかける」習慣
開発フローとしては、
コードを書く
保存時に black が自動で走る（エディタ設定）
テスト・lint を回す
という形にしておくと、
「整形し忘れ」がほぼなくなります。
エディタ（VS Code, PyCharm など）で
「保存時に black を実行する」設定にしておくのがオススメです。
black を導入するときにハマりやすいポイント
既存プロジェクトにいきなりかけると「差分地獄」になる
既存のコードベースに、
いきなり black をかけると、
ほぼ全ファイルが「変更扱い」になります。
Git の差分が真っ白になって、
「どこを本当に直したのか」が分からなくなる、という問題が出ます。
現実的なやり方としては、
プロジェクト全体に一度だけ black をかけるコミットを作る
そのコミットを「整形専用」として扱う
以降は、black を前提に開発する
というステップを踏むことが多いです。
最初の一回は「大掃除」だと思って割り切る。
そこを越えると、あとはずっと楽になります。
自動整形が「壊していないか」が不安なとき
black は「意味を変えない範囲で」整形するように設計されていますが、
最初は「本当に大丈夫かな…」と不安になることもあります。
その不安を消す一番の方法はシンプルで、
black をかけたあとにテストを回す
ことです。
テストが通っていれば、「振る舞いは変わっていない」と言えます。
逆に、テストがないと「整形で壊していないか」を確かめる手段がありません。
ここで、「テストを書くこと」と「フォーマッタを安心して使うこと」がつながってきます。
初心者が black とどう付き合うといいか
「細かいスタイルのこだわり」を一旦捨ててみる
最初は、「この改行の仕方は好きじゃない」「ここはシングルクォートがいい」など、
いろいろ気になると思います。
でも、一度こう割り切ってみてください。
「スタイルは black に丸投げする。自分はロジックと設計に集中する」
これを徹底すると、
驚くほど頭が軽くなります。
どこで改行するか
どのクォートを使うか
空行を何行入れるか
そういう「考えなくていいこと」を全部捨てて、
「何を作るか」「どう設計するか」に脳のリソースを使えるようになります。
「black に怒られないコード」を体で覚えていく
何度か black をかけていると、
この書き方はこう整形されるな
ここはどうせ縦に並べられるな
このスペースは black が入れてくれるな
という感覚がつかめてきます。
そうなると、
最初から「black 後の形」に近いコードを書けるようになってきます。
これは、設計やテストと同じで、
「何度も触っているうちに体に染み込んでくる」タイプのスキルです。
まとめ（black は「考える場所を減らしてくれる相棒」）
black を初心者目線で整理すると、こうなります。
black は、Python コードを自動で整形してくれるフォーマッタで、インデント・空白・改行・クォートなどを「black 流」に統一してくれる。
設定の余地がほとんどなく、「好み」より「一貫性」を優先することで、スタイルの議論や迷いをなくしてくれる。
flake8 などのリンターと組み合わせると、「自動整形 → 静的チェック → 人間のレビュー」という流れが作れて、設計やテストの話に集中しやすくなる。
最初は違和感があっても、「スタイルは black に任せる」と割り切ると、ロジックと設計に集中できるようになり、結果的にコードの品質も自分の成長も加速する。
もしよければ、あなたが今書いている「ちょっと汚いかも」と感じている Python コードを（名前など変えて）貼ってくれれば、
「black をかける前」と「かけた後」のイメージを、一緒に手で整形しながら見ていきましょう。