フロント検証を自動化するなら、最初に入れておきたいPythonツールとGit

Claude を使って操作しながらフロント確認を進めるなら、最初に入れるべきなのは Playwright Beautiful Soup Pillow Git の4つです。
理由は単純です。コードが正しくても、ユーザーの画面が正しいとは限らないからです。

WordPress でもフロントエンドでも、こういうズレはよくあります。
CSS は新しいものが返っている。HTML も更新したつもり。
それなのに、ユーザー画面だけ古い。関連記事だけ古い。下の方だけ崩れている。
このとき必要なのは、コード確認だけではありません。実際のブラウザ表示、取得された HTML、見えている画像、その差分を管理する道具です。

Claude に操作を任せつつ、自分は画面確認と切り分けを早くやりたいとき、この4つがあるとかなりラクです。
この記事では、Pillow Playwright Beautiful Soup Git を、単なるツール紹介ではなく、ユーザーに見えている現実を確認するための最小構成として整理します。

フロント検証で最初に入れるべき4つ

先に役割だけ並べると、こうです。

Playwright: 実際のブラウザで表示された画面を取る
Beautiful Soup: 取得した HTML の構造を読む
Pillow: スクリーンショットの見たい部分だけ切り出す
Git: 検証コードと差分を戻せる状態で管理する

この4つがあると、コードは合っているのに表示が違う という問題を、だいぶ構造で追えるようになります。

Pillowはスクリーンショットの必要部分だけ切り出せる

Pillow は、昔から知られている PIL の実質的な後継です。
公式ドキュメントでも Pillow (PIL Fork) として案内されています。
Python で画像を扱うときの定番で、切り抜き、保存、軽い加工をやるにはちょうどいいです。

実務で強いのは、フルページスクリーンショットを撮ったあとに、下部だけ切り出す 使い方です。
たとえば WordPress の関連記事、フッター直前、追従要素の解除後の見え方などは、ページ下部に問題が出やすいです。
Playwright でページ全体を撮り、Pillow で必要部分だけ切ると、確認がかなり速くなります。

画像比較の大がかりな仕組みを最初から入れなくても、保存する 切る 別名で残す だけで、かなり実用になります。
GitHub の Pillow リポジトリを見ておくと、更新状況や issue も追いやすいです。

画像の出どころ

Playwrightはユーザーに見えている画面を取りにいける

Playwright は、Python から使えるブラウザ自動化ツールです。
公式ドキュメントでも、Chromium、Firefox、WebKit を単一の系統で扱えることが案内されています。
つまり、1つの道具で複数ブラウザの見え方を追いやすいです。

フロント検証で便利なのは、次の3つです。

フルページスクリーンショットを撮れる
クリップ指定や要素単位のスクリーンショットを撮れる
JavaScript 実行後の状態を見たうえで HTML を取れる

ここが大事です。
curl で HTML を見るだけでは、ユーザーに見えている最終状態とずれることがあります。
特に WordPress では、キャッシュ済み HTML、遅延読込、関連記事ウィジェット、テーマ側の差し込みなどで、コード上の正しさと画面上の現実がずれる ことがあります。

Playwright は、そうしたズレの確認と相性がいいです。
公式の Screenshots ガイドでも、full_page=True や要素単位の撮影が案内されています。
GitHub では microsoft/playwright が本体で、必要なら playwright-cli や playwright-mcp も追えます。

画像の出どころ

Beautiful SoupはHTML構造の答え合わせに向く

Beautiful Soup は、HTML と XML を扱うための定番ライブラリです。
公式ドキュメントでも、HTML/XML からデータを取り出す Python ライブラリとして説明されています。

フロント検証で便利なのは、DOM を読んで、特定要素の存在確認や抽出をやる役 です。
たとえば次のような確認に向いています。

関連記事ブロックが実際に出ているか
想定した class や id が残っているか
見出しや CTA が古い HTML のまま残っていないか
キャッシュされた断片だけ差し替わっていないか

特に相性がいいのは、Playwright と組み合わせる形です。
Playwright で JavaScript 実行後の HTML を取得して、Beautiful Soup で必要部分だけ読む。
この流れにすると、取得したソースは合っているのに、欲しい要素だけ違う という確認がしやすくなります。

ロゴ素材を無理に使うより、公式ドキュメント画面のキャプチャを画像にしたほうが安全です。
今回は GitHub リンクを無理に足すより、公式ドキュメント中心で組み立てるほうが自然です。
本文でロゴ断定を避けたいテーマなので、ドキュメント画面キャプチャ前提で扱うのが筋がいいです。

画像の出どころ

Beautiful Soup 公式ドキュメント
ロゴ素材ではなく、上記ドキュメント画面のキャプチャを推奨

Gitは検証スクリプトを戻せる状態にする

ツール導入だけで終わると、検証はすぐ散らかります。
だから Git も最初に入れておいた方がいいです。

Git の役割は派手ではありません。
でも実務ではかなり効きます。

変更履歴を残せる
前回との差分を見られる
うまくいかなかった検証を巻き戻せる
チームや将来の自分と共有しやすい

たとえば wait を増やした セレクタを変えた スクリーンショット保存位置を変えた という小さな修正も、Git があれば意図ごと残せます。
検証コードは一度で完成しません。だからこそ、戻せることが大事です。

公式サイトでは Git を free and open source の distributed version control system と説明しています。
学習用には Pro Git が無料公開されていて、ソースは git/git でも追えます。

画像の出どころ

4つをどう分担すると迷いにくいか

4つを並べるだけだと、結局どこから使うのかが曖昧になりがちです。
役割を固定すると、検証の流れがかなり見やすくなります。

役割	見る対象	答えられること
Playwright	ブラウザ画面	ユーザーには何が見えているか
Beautiful Soup	HTML構造	どの要素が出ているか
Pillow	画像の一部	どこが崩れているかを切り出せるか
Git	検証コードの履歴	何を変えて表示が変わったか

この順番で見ると、見た目 構造 画像 履歴 が分かれます。
全部を一気に疑わずに済むので、キャッシュ問題や stale HTML の切り分けが速くなります。

最初に入れるコマンドはこれで十分

導入は最小でかまいません。
まずは Python ライブラリと Playwright のブラウザを入れます。

python -m pip install pillow playwright beautifulsoup4
playwright install

Git をまだ入れていないなら、最初のセットアップはこのくらいで十分です。

git init
git add .
git commit -m "Add frontend verification scripts"

すでに Git 管理中のプロジェクトなら、まず見るのは git status と git diff です。
検証スクリプトを増やすときも、既存ファイルを壊していないかをすぐ確認できます。

まず作るべき最小の確認フロー

初心者なら、最初から全部自動化しなくて大丈夫です。
次の流れだけ作れば、かなり戦えます。

Playwright で対象ページを開く
フルページスクリーンショットを保存する
page.content() で HTML を取る
Beautiful Soup で関連記事や確認したい要素だけ抜く
Pillow で下部や問題箇所だけ切り出す
Git で差分を残す

この形なら、Claude に作業を進めさせながらでも、表示がおかしい を感覚ではなくファイルで残せます。

見るべきなのはコードだけではなく、ユーザーの画面

フロント検証で本当に見るべきなのは、コードそのものだけではありません。
ユーザーに見えている画面です。

その確認を安定させる最小構成として、Playwright Beautiful Soup Pillow Git はかなり筋がいいです。
Playwright で現実の画面を取り、Beautiful Soup で HTML 構造を読み、Pillow で見たい部分を切り出し、Git で検証の差分を残す。
この4つがあるだけで、Claude を使っているときでも コードは合っているのに表示が違う にかなり冷静に向き合えます。

次の一歩としては、関連記事だけ自動で切り出す構成 に進めるのがおすすめです。
Playwright でページを開き、Beautiful Soup で関連記事ブロックだけ抜き、Pillow でその部分のスクリーンショットを切り、Git で変化を追う。
WordPress の stale HTML やキャッシュ問題に刺さるのは、こういう小さく具体的な自動化です。