Playwrightのブラウザ自動化が突然クラッシュしたときの切り分け記録

自動化していたはずの仕組みが、ある日突然動かなくなる。Claude Codeやスクリプトで業務を自動化している方なら、一度は経験したことがあるかもしれません。この記事では、前日まで問題なく動いていたブラウザ自動化が突然クラッシュした実例と、実際に試した確認作業、切り分けられたこと、最後までわからなかったことを紹介します。

前日まで普通に動いていたのに、ある日突然クラッシュした

noteへの記事投稿には、公式の投稿APIが存在しないため、ブラウザを直接操作する仕組み（Playwright経由のChromium）を使って自動化しています。この仕組みは、それまで何週間も特に問題なく動作していました。

ところが、ある日を境に、投稿のたびにブラウザがクラッシュするようになりました。コード自体は変更していない状態での出来事だったため、「昨日まで動いていたのに、なぜ今日から急に」という状態に直面しました。

原因の切り分けで試したこと

疑い①：コード側の変更点

まず疑ったのは、Claude Codeで組んだスクリプト側の変更です。ただし、直近でこの部分を触った記録はなく、原因としてはすぐに除外できました。

疑い②：ブラウザ本体の状態

次に疑ったのは、ブラウザ本体（Chromium）のキャッシュや内部ファイルが壊れている可能性です。キャッシュをクリアしてみましたが、症状は変わらず同じようにクラッシュが再発しました。

疑い③：実行環境の違い

スクリプト経由の自動操作ではなく、ブラウザを単体で操作して同じ手順を手動再現できるかも確認しました。単体操作では問題なく動く場面もあったため、「スクリプトからの自動操作に特有の条件で落ちているのではないか」というところまでは絞り込めましたが、それ以上の特定には至りませんでした。

結局どこまでしかわからなかったか

最終的に手がかりとして残ったのは、クラッシュが起き始めたタイミングとOSのバージョンでした。断定はできないものの、「macOSの新しいバージョンと、ブラウザのビルドとの間で何らかの相性問題が起きているのではないか」というところまでしか切り分けられませんでした。原因を完全に特定できないまま終わるケースがある、というのも自動化の現実だと感じています。

API経由の自動化との対比

同じ時期、WordPressへの投稿は公式のREST API（アプリケーションパスワード認証）で自動化していましたが、こちらは何の問題もなく動き続けていました。

これだけで「APIなら壊れない」とは言い切れませんが、今回の環境では、ブラウザ操作の方がOSやブラウザ側の変化の影響を受けやすいと感じました。ブラウザ操作は画面上の操作をそのまま再現する仕組みのため、画面描画やOSの内部挙動が変わるだけで影響を受けやすいのだと考えられます。

今はどう運用しているか

根本原因を解消できていないため、noteへの投稿は一時的に手動へ切り替えて対応しています。もともとnoteは「下書き保存までを自動化し、公開は手動で行う」という運用にしていたため、影響は最小限に抑えられました。自動化の踏み込み方に、あらかじめ段階を持たせておいたことが、結果的にここで効いた形です。

よくある質問（FAQ）

Q. ブラウザ自動化がクラッシュしたら、まず何を確認すればいいですか？

A. まず直近のコード変更の有無を確認し、次にブラウザのキャッシュクリア、それでも直らなければ実行環境（スクリプト経由か単体操作か）を切り分けて確認するのがおすすめです。

Q. 原因が完全にわからないまま運用を続けても大丈夫ですか？

A. 致命的な処理でなければ、一時的に手動運用へ切り替えて様子を見るのも一つの方法です。今回もこの方法で被害を最小限に抑えました。

まとめ

前日まで問題なく動いていたブラウザ自動化が、突然クラッシュするようになった実例を紹介しました。原因を完全に特定できないケースもありますが、API経由の自動化とブラウザ操作に頼る自動化とでは、壊れやすさに明確な違いがあることを実感しました。自動化の仕組みを設計する際は、この違いを踏まえて踏み込み方に段階を持たせておくと、いざという時の被害を抑えられます。