SeleniumとPlaywright、2026年の社内自動化ではどちらが扱いやすいか

Chrome更新と自動化停止、現場の苦悩

朝9時、いつものようにPythonスクリプトのアイコンをダブルクリックする。黒いコンソール画面が一瞬立ち上がり、すぐに消え去った。嫌な予感とともにログファイルを開くと。画面いっぱいに無機質なエラー文字列が並んでいる。背筋が冷たくなる瞬間だ。ブラウザすら立ち上がっていありません。

原因は自作したコードのバグではない。ブラウザ本体がバックグラウンドで勝手にアップデートされたことだ。社内のPCはセキュリティ対策の都合上、Chromeが自動で最新版に更新される。昨日までは機嫌よく動いていた自動化ツールが、ある朝突然ピクリとも動かなくなる。

まず、手入力で1日180分かかっていた転記作業が。自動化後は20〜35分まで短縮した（自部署実測）。この輝かしい成果に周囲は喝采を送ったが、魔法が解けたあとの現実は過酷である。システムが止まるたび。周囲から「今日は手作業でやるしかないの？」という冷たい視線が突き刺さる。胃の奥が重く沈むのを感じながら、急いで対応作業に取り掛かる。

非エンジニア現場の自動化の病理

このChrome更新直後の不具合確認と復旧に。手運用では1回あたり30〜90分を要した（自部署実測）。業務の合間を縫って作られたスクリプトのメンテナンスに。本来の業務時間が削られていく。手作業を楽にするはずの自動化が、新たな精神的負担を生み出している。

この苦痛は、非エンジニアが現場で開発・運用を担う組織特有の病理だ。専任の保守担当者がいればすぐに対処できるかもしれない。しかし、総務や経理の担当者が片手間で保守を続けるには。この「外部要因による突然死」はあまりにもリスクが高い。自動化の恩恵を享受し続けるためには、止まらない仕組み。あるいは止まっても一瞬で息を吹き返す仕組みが不可欠になる。

Selenium保守、非エンジニアの壁

次に、現場の自動化で真っ先に名前が挙がるのがSeleniumだ。長い歴史を持ち、ネット上には無数の解説記事が転がっている。しかし、非エンジニアが長期間保守しようとすると。特有のアーキテクチャが大きな壁として立ちはだかる。

Seleniumはブラウザを直接動かしているわけではない。外部からブラウザを操るため。間にChromeDriverという仲介役を挟む仕組みになっている。本体とこの仲介役のバージョンが完全に一致していないと、一切の操作を受け付けない。前述した突然死の原因はまさにここにある。

安定稼働を目指すなら。Seleniumでは要素待機・例外処理・ChromeDriverバージョン整合の確認を必須手順にする必要がある。特に厄介なのが要素待機だ。古い社内システムは。ボタンをクリックしてから次の画面が表示されるまでの応答時間が日によってバラバラになる。

コードと環境の不一致。システム遅延と空振りエラー。

一方で、画面が完全に読み込まれる前にスクリプトが次の操作を実行しようとして。空振りエラーを起こす。これを防ぐために。苦肉の策としてコードのあちこちに一時停止の命令を仕込むことになる。結果として、無駄な待ち時間だらけの不格好で遅いシステムが出来上がる。

コードそのものは正しくても。動かす環境や通信状態という「揺らぎ」を吸収しきれない。画面の裏側で何が起きているのかを想像し、あらゆる例外をコードで縛り付ける作業は。プログラミング言語の文法を覚えるよりも遥かに難易度が高い。Seleniumというツール自体が劣っているわけではない。単に、片手間の保守体制という前提条件と噛み合っていないだけです。

Playwright：待機自動化とDOM理解の壁

運用の限界を感じた担当者たちの間で。近年急速に支持を集めているのがPlaywrightである。Microsoftが主導して開発しているこのツールは。ブラウザとの通信方式が根底から異なる。仲介役のドライバーに依存せず。ブラウザの内部と直接やり取りを行うアーキテクチャを採用している。

そのため、最大の違いは。画面の読み込みやネットワークの通信状態をツール側が自動で見張ってくれる点だ。Playwrightではwait_for_selectorと明示的タイムアウトを設定し。失敗時にスクリーンショットを保存する。この手順を基本の型として組み込むだけで。不安定な社内システム相手でも空振りエラーが激減する。

要素が表示されるまで賢く待ち、表示された瞬間に次の動作に移る。無駄な待機時間を手動で調整する苦労から解放される。さらに、ブラウザの実行環境をツール自体が内包しているため。PC本体のアップデートの影響を受けにくい。

魔法の杖なし、基礎知識は必須

しかし、すべてを自動で解決してくれる魔法の杖ではない。どれほど優れた待機機能を持っていようと。社内システム特有の奇妙な仕様にはやはり工夫が求められる。

しかし、例えば、見た目はひとつの画面なのに。内部に別のページが埋め込まれているフレーム構造。あるいは、マウスのカーソルを乗せないと出現しない特殊なメニューボタン。こうした複雑なDOM構造を解析し。適切な指示を出すためのHTMLやCSSの基礎知識は。どのツールを使っても逃げられない関門だ。エラーが出なくなったからといって。システムそのものの複雑さが消え去るわけではありません。

復旧速度の差

ツールの違いが実務にどう影響するのか。GoogleフォームからCSVを取得し。社内システム画面へ項目転記する一連の流れを同条件で比較する。対象としたのは、経理部門で毎月発生する数百件のデータ入力業務です。

コードを書き上げ。実際に走らせてみた直後の感想は「どちらも十分に速い」というものだった。人間が手で入力するスピードとは比較にならない。画面の描画を待って確実にテキストボックスを埋めていく挙動そのものに。決定的な差は見られなかった。

さらに、真の差が浮き彫りになったのは、システムの仕様変更でエラーが発生した日だ。社内システムのレイアウトが微修正され、ボタンのIDが変更された。

Seleniumで作ったスクリプトは、突然停止して無言のまま動かなくなった。エラーログには「要素が見つからない」という趣旨のメッセージが残されているだけだ。どの画面の、どのボタンでつまずいたのか。それを特定するために、手動でコードを1行ずつ実行し直し。原因の画面にたどり着くまでに小一時間を浪費した。

Playwright自動記録による超速復旧

一方、Playwrightは息絶える瞬間に「遺言」を残していた。失敗時に画面のスクリーンショットと詳細なトレースログを自動保存するよう設定していたためだ。保存された画像を見れば。レイアウトが崩れた画面でツールが立ち往生している様子が一目瞭然だった。原因特定にかかった時間はわずか3分。この復旧スピードの差こそが、現場の運用負荷を劇的に下げる最大の要因となる。

異動後も保守可能か」ツール選定の軸

まず、新しいツールを導入する際。つい機能の豊富さや実行速度の比較表を作ってしまいがちだ。しかし、総務や人事といった非エンジニアの組織において。その比較はほとんど意味を持たない。最優先すべき基準は「自分が異動したあと、残された人間が保守できるか」に尽きる。

前任者が残したコメントのない自動化コードを引き継いだときの絶望感は筆舌に尽くしがたい。どこで何をしているのかわからないブラックボックス。動かなくなるたびにドライバーを手動でダウンロードし。パスを通し直すという謎の儀式。意味もわからず手順書通りに作業するだけの担当者は。いつしか自動化そのものを放棄して手作業に戻ってしまう。

属人化を防ぐためには。環境構築のハードルとエラー時の原因究明の難易度を極限まで下げる必要がある。環境に依存せず、実行するだけで必要なブラウザ環境が整う仕組み。どこで止まったかを画像で視覚的に教えてくれる機能。

次に、コードの書きやすさよりも。壊れたときに直しやすい設計になっているかどうかが問われる。保守の負荷が下がるということは。それだけ新しい業務の自動化に挑戦する余裕が生まれることを意味する。技術的な壁にぶつかって挫折する人を減らすことこそが。組織全体の生産性を底上げする確実なアプローチになる。

まずは小さな一歩から自動化

ここまでの比較を経て、どちらのツールを選ぶべきかの輪郭は見えてきたはずだ。しかし、いきなり全社の標準ツールとして大々的に導入してはいけない。業務の実態に合っているかどうかは。実際に手を動かしてみないとわからない部分が多い。

確実なのは、まず自分の手元にある小さな作業から始めることだ。検証は本番前に3日連続で同一シナリオを回し、失敗ログ件数で判断した。朝、昼、夕方と時間を変えて実行し。社内システムの応答速度の変化にツールが耐えられるかを確認する。安定して動く確証が得られてから。初めて隣の部署に「こんな便利なものがある」と提案する。

一方で、エラーのたびに冷や汗を流し。手作業の何倍もの時間をかけてコードを修正する日々は終わりに近づいている。技術の進化は、現場の泥臭い悩みを確実に解消する方向へ向かっている。

無機質なシステムと毎日にらめっこしながら。コピーとペーストを繰り返すだけの時間は人間の本来の仕事ではない。選定の迷いを断ち切り、新しい道具を手に取って。手元の業務をひとつでも多く自動化のレールに乗せてほしい。その小さな一歩が、数年後の働き方を劇的に変える起点になる。

関連リンクとチェックリスト

学習サービスとアンケート