※この記事は、個人技術ブログ CodeArchPedia.com の技術メモ（要約）です。
ChromeDriverでexec形式エラーに遭遇した際の話。自動化スクリプトが突然動かなくなり、ログを見たらこのエラーが出ていました。環境構築でハマるあるあるですが、地味に解決に時間がかかるんですよね。特に異なるOS間でのデプロイを試みた時によく問題になります。
何が起きたか（課題）
exec形式エラーが発生すると、Seleniumを使ったウェブ自動化が完全に停止します。現場で確認された主な症状とリスクは以下の通りです。
- Chromeブラウザが起動せず、テストやデータ収集がストップする。
- 特にApple Silicon (M1/M2) やARMベースのサーバー環境で頻発する。
- バイナリファイルがダウンロードされていても、実行権限がないためにOSから拒否されるケースがある。
どう解決したか（概要）
エラーの根本原因は、実行しようとしているChromeDriverバイナリのCPUアーキテクチャやOS形式が、実行環境と一致していないことにありました。手動で修正する方法と、モダンな自動解決策を試しました。
まず、手動で確認すべきポイントは、Chromeのバージョンとシステムのアーキテクチャです。google-chrome --version や uname -m で現状を確認しました。確認後、正しいアーキテクチャに合ったバイナリをダウンロードし直す必要がありました。LinuxやmacOSの場合、ダウンロード後に chmod +x chromedriver を実行し、明示的に実行権限を付与することが決定的に重要です。
しかし、毎回手動で管理するのは非効率です。そこで、Selenium 4.6以降に搭載されたSelenium Managerの利用に切り替えました。これは、実行環境を自動で検出し、適切なWebDriverバイナリをダウンロード・設定してくれるため、手動でバージョンを合わせる手間が一切なくなります。
例えばPythonで標準の webdriver.Chrome() を呼び出すだけで、必要な処理が裏側で走るため、環境差異を意識せずに済みます。これは、特にCI/CDパイプラインの安定化に大きく貢献しました。
効果（Before/After）
Selenium Managerへ移行した結果、exec形式エラーの発生頻度は劇的に低下しました。手動でアーキテクチャやパーミッションをチェックする工数がゼロになったため、開発・デプロイサイクルが高速化しました。安定性が向上し、ウェブ自動化の堅牢性が高まったのが最大の効果です。
🚀 詳細な設定とコードはこちら
具体的なchmodコマンドの例や、Selenium Managerが裏側で実行する検出ロジックの詳細、さらに複雑な環境で有効な代替ライブラリ（undetected-chromedriver）の具体的な初期化コードなどは元のブログで公開しています。