#playwright

この記事を読んでまず思ったのは、「ようやくその話を正面から書いてくれたな」ということだった。 UI automation って、やろうと思えばできる。でも実際には、仕様を読む、画面を確認する、locator を選ぶ、既存の framework に合わせる、パイプラインで落ちた理由を探す……と、地味な作業がずっと挟まる。そこを AI assistant に手伝わせる、という発想はかなり自然だと思う。 ただ、読んでいて面白かったのは、著者が「AI に test を書かせたい」と言っているようでいて、実際には「証拠集めを先にやらせたい」と言っているところだった。ここはかなり大事だと思う。 単に「invalid email の UI test を書いて」と投げるのと、Jira、Figma、GitLab、Playwright から根拠を集めさせてから test を作らせるのでは、出てくるものの質が全然違う。後者だと、AI が勝手に今の実装に寄せてしまう危険を少し抑えられる。仕様上は blur でエラーが出るのに、実装は typing 中に出ている、みたいなズレを見つけたときに「じゃあ実装に合わせ

What jumped out at me here is not the MCP plumbing. It’s the claim that the hard part of UI automation is mostly *context assembly*. I buy that up to a point, but only up to a point. The article is strongest when it admits that the assistant can gather evidence and save time on the mechanical bits. It gets weaker when it starts to sound like the main bottleneck is just getting Jira, Figma, GitLab, and Playwright into the same room. That part is real, though. If you’ve ever had to reconstruct a f

この症状は、Claude Code の cloud environment や web sandbox でブラウザ系の通信だけが落ちるときに出ています。報告されているのは、Playwright MCP の `browser_navigate` や headless Chromium の `page.goto()` が、どの URL でも `net::ERR_CONNECTION_RESET` になるケースです。対象は `https://example.com` や `www.google.com` のような一般的なサイトでも同じでした。いっぽうで、同じセッション・同じシェル内では `curl` や Node の `fetch`、`https` モジュールが成功している、というのが共通点です。これは [#85757](https://github.com/anthropics/claude-code/issues/85757) と [#73564](https://github.com/anthropics/claude-code/issues/73564) に書かれている症状です。 自