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

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

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

原因は、自作コードのバグではありません。ブラウザが勝手にアップデートされたためでした。社内のPCはセキュリティの都合上、Chromeが自動で最新版に更新されます。昨日は動いていたツールが、突然止まります。ある朝、ピクリとも動かなくなってしまうのです。

まず、手入力の転記作業は1日180分でした。自動化後は20〜35分まで短縮しています（自部署実測）。この成果に周囲は喜んでくれました。しかし、魔法が解けたあとの現実は過酷です。システムが止まると視線を感じます。「今日は手作業なの？」と言われているようです。胃の奥が重く沈むのを感じながら、急いで対応するのが常です。

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

Chrome更新後の復旧には時間がかかります。1回あたり30〜90分を要しました（自部署実測）。業務の合間に作ったツールの保守です。これにより、本来の業務時間が削られていきます。自動化は手作業を楽にするはずです。しかし、今は新たな精神的負担となっています。

この苦痛は、組織特有かもしれません。非エンジニアが現場で開発・運用を担うゆえの状況です。専任の担当者がいれば、すぐに対処できます。しかし、総務や経理が片手間で保守をするのは困難です。外部要因による「突然死」は、あまりにリスクが高いと感じます。自動化の恩恵を維持する仕組みが必要です。止まらない仕組み、または即座に復旧する仕組みが欠かせません。

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

次に、現場の自動化で名前が挙がるのがSeleniumです。長い歴史を持ち、ネット上には解説記事が溢れています。しかし、非エンジニアの長期保守は困難です。特有の構造が、大きな壁として立ちはだかります。

これは外部からブラウザを操る仕組みです。間に、仲介役のChromeDriverを挟んでいます。本体と仲介役のバージョンを一致させる必要があります。一致しないと、一切の操作を受け付けません。前述した突然死の原因はまさにここにあるのです。

安定稼働には、いくつかの必須手順があります。要素待機や整合性の確認などは欠かせません。特に厄介なのが要素待機です。古い社内システムは、応答時間が不安定です。ボタンを押した後の表示時間が、日によってバラバラになります。

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

画面が読み込まれる前に、操作を実行することがあります。その結果、空振りエラーが起きてしまいます。これを防ぐため、一時停止の命令を仕込みます。コードのあちこちに、苦肉の策として記述するのです。結果として、不格好なシステムになります。無駄な待ち時間が多く、動作も遅くなってしまいます。

コードが正しくても、「揺らぎ」を吸収できません。動かす環境や通信状態の影響を受けてしまいます。画面裏の動きを想像し、例外をコードで縛る作業が必要です。これは、文法を覚えるよりも遥かに難易度が高いです。Selenium自体が劣っているわけではありません。片手間の保守体制という環境に、噛み合っていないだけでしょう。

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

近年、運用の限界を感じた方々の間で、Playwrightが支持されています。このツールはMicrosoftが開発しています。ブラウザとの通信方式が、根底から異なります。仲介役のドライバーには依存しません。ブラウザ内部と直接やり取りする構造を採用しています。

最大の違いは、ツール側が自動で見張ってくれる点です。画面の読み込みや通信状態を監視してくれます。Playwrightでは、特定の型を組み込みます。要素の待機設定や、失敗時の画像保存などです。これだけで、不安定なシステムでもエラーが激減します。

要素が表示されるまで賢く待ちます。表示後にすぐ動くため、手動で待機時間を調整する苦労もありません。ブラウザの実行環境は、ツールが内包しています。そのため、PCのアップデートの影響を受けにくい利点があります。

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

しかし、Playwrightも魔法の杖ではありません。待機機能が優れていても、工夫は必要です。社内システム特有の仕様には、対応が求められます。

例えば、フレーム構造や特殊なメニューボタンなどです。こうした複雑な構造を解析しなければなりません。HTMLやCSSの基礎知識は、どのツールでも必須の関門です。エラーが減っても、複雑さは消えません。システム自体の難しさは、依然として残ります。

復旧速度の差

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

実際にコードを走らせてみました。感想は「どちらも十分に速い」というものでした。人間が手で入力するスピードとは比較になりません。画面を待って入力する挙動に、大差はありません。テキストボックスを埋める動きは、どちらも正確です。

しかし、真の差はエラー時に現れました。システムの仕様変更が起きた日のことです。レイアウトが修正され、ボタンIDが変わりました。その際に、明確な違いが出たのです。

Seleniumのスクリプトは、突然停止しました。無言のまま動かなくなってしまいます。ログには、エラーメッセージがあるだけでした。「要素が見つからない」という内容です。原因特定のため、コードを手動で実行し直します。どのボタンで躓いたかを探すのに、小一時間かかりました。

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

一方、Playwrightは息絶える瞬間に情報を残しました。失敗時の画像を保存する設定にしていたためです。詳細なトレースログも、自動で残してくれました。画像を見れば、状況は一目瞭然です。レイアウトが崩れた画面で、ツールが立ち往生しています。原因特定にかかった時間はわずか3分です。この復旧スピードこそが、現場の負荷を下げる要因となります。

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

導入時に、機能や速度の比較表を作りがちです。つい、数値上の性能に目を向けてしまいます。しかし、非エンジニアの組織では、その比較は重要ではありません。総務や人事などの現場では、別の軸が必要です。最優先の基準は「保守性」です。自分が異動したあと、残された人が対応できるかに尽きます。

コメントのないコードを引き継ぐのは絶望的です。前任者の負債を抱えるのは、言葉にできない苦痛です。どこで何をしているのかわからないブラックボックス。停止のたびにドライバを入れ直す「儀式」も発生します。手動でパスを通す作業は、非効率でしかありません。意味もわからず作業する担当者は疲弊します。いつしか自動化を諦め、手作業に戻ってしまいます。

属人化を防ぐための環境と設計

属人化を防ぐ工夫が必要です。環境構築や原因究明の難易度を、極限まで下げるべきです。実行するだけで環境が整う仕組みは助かります。停止場所を画像で教える機能も、非常に有用です。書きやすさよりも「直しやすさ」が重要です。壊れた際の修正のしやすさが、設計の鍵となります。保守負荷が下がれば、余裕が生まれます。その分、新しい業務の自動化に挑戦できるはずです。

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

ツール選びの輪郭は見えてきたはずです。ここまでの比較で、判断材料は揃いました。しかし、いきなり大々的に導入してはいけません。業務に合うかは、動かさないとわかりません。実際に手を動かして、確かめる部分が多いからです。

確実なのは、まず自分の手元の作業から始めることです。検証は3日連続で同一シナリオを回しました。失敗ログの件数で、安定性を判断します。時間を変えて何度も実行しましょう。システムの応答変化に、ツールが耐えられるかを確認します。安定の確証を得てから、提案しましょう。隣の部署へ伝えるのは、それからです。

エラーで冷や汗を流す日々は終わります。手作業より時間をかけて直す必要はありません。技術の進化は、現場の悩みを解消する方向へ向かっています。コピペを繰り返す時間は、本来の仕事ではありません。システムとにらめっこする毎日は、変えられます。迷いを断ち切り、新しい道具を手に取りましょう。手元の業務を、ひとつでも多く自動化してください。その小さな一歩が、将来の働き方を変える起点になります。

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

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