Playwright MCP を開発で使うのをやめた話

エンジニアの中には一部、揚げ足取りや攻撃的な人もいる。 SNSで技術記事を書くと、本文より先に「言葉の定義」や「お前の前提が違う」みたいなツッコミから入ってくる人が一定数いる。 なので、本題に入る前に補足を書かせてほしい。

まず、MCP はプロトコルの名前であって、ここで話すのは「Playwright 系のブラウザ操作 MCP を、開発中の更新系作業で使うのはやめた」という、かなり限定された話。

以前、「MCPはほとんど使ってない。使うとしてもブラウザ操作（Playwright）くらい」と書いたが、今日はその最後の砦も、開発フェーズでは外した。

理由は単純で、更新系・登録系の処理で信用しきれない。

画面を勝手に触ってデータを壊したり、意図しないタイミングでクリックしたり、DOM変化で暴走したり。 もちろん、単純な表示確認やスクリーンショット用途なら今でも便利。

決定打になったのは、AIが自分でデータを壊しておいて、

「データが壊れています」

と報告してきたこと。

いや、お前が壊したんだろ、と。

さすがにその時は、本当に「ふざけるな」と怒鳴った。

もちろんAIに悪意があるわけではない。 単純に、状態遷移を理解しないままUIを機械的に操作しているだけ。

でも、更新系の開発でそれをやられると、普通に危険。

「環境分離すればいいのでは？」への先回り

ここで先に答えておくと、もちろん dev DB をスナップショット運用したり、専用のサンドボックスを用意すれば防げる話ではある。

実際それも試した。

ただ、開発初期は DB スキーマ自体が毎日変わる。 スナップショット復元用のシードや fixture を維持するコスト自体が、curl で叩く時間を簡単に上回ってきた。

「環境を固めるコスト」と「curl で済ませるコスト」を比べたとき、少なくとも私のフェーズでは後者が圧倒的に安かった、というだけの話。

「Playwright の使い方が悪いだけでは？」への先回り

これも一理ある。 data-testid を整備し、role セレクタを使い、waitForResponse で同期を取れば、Playwright 自体は十分安定する。

ただし開発初期は、そもそも UI が毎日変わる。 testid を貼って回るコストは、UI が固まってからまとめてやった方が圧倒的に安い。

つまり、Playwright が悪いのではなく、「UIが固まる前のフェーズで AI に UI 経由で状態変更させる」のが筋が悪い、という話。

なぜ curl なら許せるのか

「AIに curl を渡しても、DELETE を叩けば同じく壊すのでは？」というツッコミは正しい。 本質的なリスクは確かに同じ。

ただ、curl は決定的に違う点がある。

• 何を送ったかが文字列として残る
• 同じコマンドを貼れば再現する
• AIにも人間にも読める
• 壊した責任範囲がコマンド単位で明確
• shell 履歴・ログとして自然に残る

ブラウザ操作は、同じ「クリックして」という指示でも、DOMの状態次第でまったく違うアクションになる。 つまり、リスクの量より、リスクの追跡可能性の話。

私はフロントとバックエンドをAPIで分離しているので、curl で大半の更新系は再現できる。 （逆に、SSR/RSC や SSO リダイレクトが絡む構成だと curl だけでは詰むので、これは「API 分離アーキテクチャだから成立する話」という前提付き。）

curl -X POST http://localhost:3000/api/user \
  -H "Content-Type: application/json" \
  -d '{"name":"test"}'

これなら：

• 何を送ったかわかる
• 再現性がある
• ログも追いやすい
• AIにも読ませやすい
• 壊れた時の責任範囲が明確

「API直叩きでは UI 層のバグを取り逃す」もその通り

これも正論で、フォームバリデーション、debounce、楽観的UI、CSRFトークンの埋め込みなどは、curl が通っても画面で動かないことがある。

なので私の運用は、

• 状態変更を伴うロジックの検証 → API直叩き
• UIレイヤ固有の振る舞いの検証 → 自分でブラウザを開いて確認
• 仕上げの回帰確認 → Playwright（人間が書いたシナリオ）

という分担にした。

AIに UI を経由させて状態変更まで一気通貫させる、という発想自体を一旦やめた、という方が正確かもしれない。

ログ側で殴る

さらに、フロント側のログは別途ログサーバに飛ばして記録しているので、ブラウザをAIに操作させなくても挙動は追える。

• APIログ
• フロントログ
• サーバログ

これらを分離して見た方が、原因調査は楽だった。

結論

• 開発中の更新系 → API直叩き
• UIレイヤの確認 → 自分で開く
• E2E/結合テスト → Playwright あり
• 本番監視 → あり

「Playwright MCP 不要論」ではなく、「UIが固まる前のフェーズで、状態変更まで AI に UI 経由で任せるのが筋悪」というだけの話。

AI時代、何でも自動化したくなるが、結局一番重要なのは「どこを固定して、どこを変動させるか」の設計なのだと思う。 そして開発初期は、固定すべきは UI ではなく API のほうだった、というのが今回の結論。