ホーム自己紹介ブログ
NO.217
DATE2026. 01. 04

Playwright MCPでCSSの修正が楽になった

最近、AI エージェントに Playwright MCP を設定した状態で、CSS の調整作業を行っていました。
デザイン上どうしても原因を特定できず、修正に行き詰まっていたスタイルがあったのですが、Playwright MCP を使って調査を進めたことで解決に至りました。
本記事では、そのときの経緯と、CSS の修正がどのように進めやすくなったかを振り返ります。

罫線付きノート風レイアウトの調整

今回対象としていたのは、次のページのような罫線付きノート風のレイアウトです。
ブログサイトのリニューアル作業中のページになります。

Playwright の POM を Storybook 上で確認してから E2E テストを書く

はじめに Playwright で E2E テストを書く際、playwright codegen や、近年では Playwright MCP を利用して、テストコードの雛形を作成することが多いと思います。 ただし、生成したテストコードが正し

ジブンノート

このレイアウトでは、横罫線の上に文字が自然に配置されることを前提としてデザインしています。
一見すると単純な構造ですが、文字と罫線の位置関係がわずかに崩れるだけでも、ノートとしての印象が損なわれてしまいます。

この横罫線と文字配置の調整を進める中で、Playwright MCP が CSS 修正の手助けになる場面がありました。

技術的な構成

記事本文は Markdown で記述し、Next.js の Markdown パーサを使って HTML に変換しています。
変換後のコンテンツは、Chakra UI の Prose コンポーネントを利用して表示しています。

https://nextjs.org/docs/app/guides/mdx
https://chakra-ui.com/docs/components/prose

Markdown を使うことで記述自体は簡潔になりますが、表示上は複数の要素が混在する構成になります。

罫線デザインと Markdown

罫線の上に文字を載せるためには、罫線の間隔、文字サイズ、行の高さが適切に対応している必要があります。
テキストのみで構成されている場合であれば、line-height や margin、padding を罫線間隔の倍数に揃えることで、比較的整った見た目になります。

一方で、Markdown にはテキスト以外にも、画像、テーブル、コードブロックなど、さまざまな要素が含まれます。
これらを含んだ状態でも、罫線が途切れず、文字の位置がずれないことを目標に実装を進めていました。

罫線と文字のズレに気づく

実装を進める中で、特定の要素を境に罫線と文字の位置が合わなくなる箇所があることに気づきました。

  • テーブルの直下から罫線の位置がずれる
  • 画像の下から罫線の位置がずれる
  • コードブロックの下から罫線の位置がずれる

上下方向の余白や行の高さに影響する CSS プロパティについては、すべて罫線間隔の倍数になるように調整していました。
それにもかかわらず、特定の箇所から整合性が崩れ、原因を特定できない状態が続いていました。

Playwright MCP による調査

調整に行き詰まったため、次のような内容で AI に相談しました。

  • 「http://localhost:3000/blog/contents/xxx の本文途中から、罫線の上に文字が載らなくなる。原因が分からない」

すると、Playwright MCP が起動し、ブラウザが立ち上がって該当ページへアクセスし始めました。
スナップショットの取得や DOM 要素の確認などを行いながら、表示状態を段階的に確認していく様子が見られました。

これまでは、記述した CSS の内容や JSX の構造をコンテキストに渡し、それを前提に調査してもらうことがほとんどでした。
一方で Playwright MCP を使った今回の調査では、実際の描画結果を起点として、画面上の状態を確認しながら原因を追っていく流れになっていた点が印象的でした。

判明した原因と修正

調査の結果、コードブロック内で使用している Mono フォントと、本文で使用しているフォントが異なっていることが分かりました。
フォントの字面の違いにより、同じ line-height を指定していても、実際の表示高さが揃っていませんでした。(たぶん)

その差分が積み重なり、コードブロック以降で罫線と文字の位置がずれて見える状態になっていました。
コードブロックのフォント指定を本文と揃えることで、罫線の上に文字が自然に配置されるようになりました。

Mono フォントの使用を検討していましたが、今回は調整が難しかったため見送っています。

技術スタックと MCP

現在の開発では、公式に MCP が提供されている次のライブラリやフレームワークを利用しています。

  • Next.js
    https://nextjs.org/docs/app/guides/mcp
  • Playwright
    https://github.com/microsoft/playwright-mcp
  • Storybook
    https://storybook.js.org/addons/@storybook/addon-mcp
  • Chakra UI
    https://chakra-ui.com/docs/get-started/ai/mcp-server

CSS の修正で行き詰まった際に、実際の画面を確認しながら原因を一緒に探れる点は、開発を進める上でとても助かりました。
既存の知識に加えて、MCP による補助を受けながら作業できる体験は、安心感のある開発体験につながっていると感じています。

フロントエンド
AI

-

読者になる

|

シェアする

|

silverbirders

silverbirder

Webソフトウェアエンジニア

ブログを応援する

この記事がよかったら、お布施という形で応援してもらえるとうれしいです。

おふせぼたん

※ ログイン不要で投稿できます。

※ 同じブラウザから投稿を削除できます。

0

読み込み中...

次の記事へ前の記事へ

関連する記事

タグ「フロントエンド」の記事

Webフロントエンドのコードレビューメモ

Webフロントエンドのコードレビューをしているときに考えていることについて書きます。 毎日1記事投稿、1記事30分という制約を課していますので、本記事は完璧ではありません。(言い訳) また希望的な考えもあるので、実践していないものもあります

2026年03月12日

フロントエンド
AIの書いたコードの手直しを減らすお作法

AI にコードを書かせた後、余計なコードを見つけて消す作業があります。 不毛なことなので、それらの作業を減らすためのお作法を紹介します。 未使用コードを消す 以下でも書きましたが、未使用コードの検査に knip を使うことが多いです。 ht

2026年02月25日

AI
フロントエンド
iframeの難しさ

最近、iframeを使っています。 クライアントサイドで埋め込む想定で、iframeを使おうとしています。 色々と苦労したことがあったので、書いて残しておこうと思います。 レスポンスヘッダー 前提として、ウェブアプリケーションをプロダクショ

2026年02月18日

フロントエンド
ブラウザ

タグ「AI」の記事

AIが書いた重厚なプルリク説明文、読んでますか?

Claude Code や Codex 等の AI にプルリク(以下、PR)を書かせて効率化することができます。 けれど、その書かれたプルリク説明文、ちゃんと全部読んでいますか? レビュワーの負担になっていませんか? ノイズが多い プルリク

2026年03月06日

AI
仕事
個人ブログ記事の執筆にAIを使わない理由

個人ブログ記事の執筆に AI を使わなくなりました。 その理由について、経緯などを含めて紹介します。 ChatGPTが流行り出した時代 その当時は、ブログ記事の粗い原稿を ChatGPT に渡して推敲を依頼していました。 粗い原稿とは、以下

2026年03月05日

AI
仕事
AIの書いたコードの手直しを減らすお作法

AI にコードを書かせた後、余計なコードを見つけて消す作業があります。 不毛なことなので、それらの作業を減らすためのお作法を紹介します。 未使用コードを消す 以下でも書きましたが、未使用コードの検査に knip を使うことが多いです。 ht

2026年02月25日

AI
フロントエンド
← ブログ一覧へ