xdotool、ydotool、dotool、それともPlaywright：ヘッドレスサーバーに適した自動化ツールはどれか？

Linuxマシン上で自分に代わってクリック、入力、投稿を行うスクリプトが必要になったことがあるなら、xdotool、ydotool、dotool、Playwrightという4つの名前に出会ったことがあるでしょう。一見似ているように見えますが、その仕組みは大きく異なります。2026年10月20日現在、多くのLinuxデスクトップが従来のX11システムではなくWaylandを採用するようになっているため、そもそもどのツールが動作するかが変わり、この問題は以前にも増して重要になっています。

この記事では、ある中小企業の毎日のソーシャルメディア投稿ジョブを自動化する中で得られた知見を共有します。このジョブは外部から見えない専用の仮想スクリーンを備えたサーバー上で実行され、1日1本の記事を複数のサイトに投稿します。私たちはこれらのツールの間で選定を行い、あるステップをあるツールから別のツールへと切り替えて、そのコストを測定しました。

手短な結論

非表示のX11スクリーン上でのジョブには、 Playwright を対象サイトが通常のWebページである場合に使用し、 xdotool をバックアップとして保持してください。ydotoolとdotoolは異なる課題のために作られています。CPUとメモリに関しては、Playwrightとxdotoolの差はわずかです。信頼性のほうがはるかに重要です。

各ツールの実際の動作

xdotool はX11ディスプレイと通信します。マウスの移動、クリック、入力、キー押下、名前によるウィンドウの検索が可能です。指定したディスプレイにのみ入力を送信します。画面を見ることはできないため、画面に何が表示されているかを知る必要がある場合は、自分でスクリーンショットを撮る必要があります。

ydotool および dotool はより低レイヤーで動作します。カーネルの入力デバイス（uinputと呼ばれます）に書き込みを行うため、マシン全体に物理的なキーボードやマウスを接続したかのように動作します。そのため、xdotoolが動作しないWayland上でも機能します。その代償として、特定のウィンドウを選択することはできず、実際のデスクトップでフォーカスされている対象に入力を送信してしまいます。また、通常は入力デバイスを使用するための追加の権限が必要です。

Playwright は根本的に性質が異なります。マウスやキーボードを擬似操作するのではなく、ブラウザに接続してWebページ自体を直接制御します。ボタンが表示されるのを待機したり、入力ボックス内のテキストを読み取ったり、メッセージが表示されたかどうかを通知したりできます。

スクリーンの種類が成否の大半を決定づける理由

今回のジョブは、メモリ上にのみ存在し誰にも見られない専用の仮想ディスプレイ上で動作します。これはX11であるため、xdotoolが動作します。ydotoolとdotoolはマシン全体に入力を送信するため、実際のコンソールデスクトップに入力が届いてしまう可能性があります。今回のケースでは、他の管理者がその画面を見ることができるため、コンソールデスクトップはロックされた状態を維持する必要があります。そのため、この2つのツールは速度ではなく安全性の理由から除外されました。

今回のテストではydotoolやdotoolを実行していないため、これらに関するCPUやメモリの測定値はありません。ここで述べている内容は、それぞれの動作原理に基づいています。

ステップ1：従来の手法がどこで失敗するかを突き止める

最初のバージョンでは、xdotoolと画面読み取り（OCR）を組み合わせて使用していました。投稿ページを開き、キーを押して送信した後、スクリーンショットを撮ってテキストを読み取り、"Your post was sent"という文字列を探していました。

問題は確認処理にありました。投稿が公開されたにもかかわらず、スクリプトがメッセージを見逃して"FAILED"と報告することが何度も発生しました。そのため、人間が手動でプロフィールを確認しなければなりませんでした。これが入力を送信するだけのあらゆるツールにおける最大の弱点です。何が起きたかを把握できないため、画像から推測するしかありません。

ステップ2：そのステップをPlaywrightへ移行する

ローカルデバッグポート経由で、専用スクリーン上ですでに動作していたブラウザにPlaywrightを接続しました。スクリプトは投稿作成ボックスの表示を待機し、テキストが入力されていることを確認し、Postボタンが有効であることを確認してクリックし、確認メッセージを待ちます。メッセージを見逃した場合でも、失敗と判定する前にプロフィールを確認して新しい投稿が存在するかをチェックします。

従来のxdotoolによるルートはフォールバックとして残しました。何らかの理由でPlaywrightのステップが失敗した場合、警告が送信され、代わりに従来のルートが試行されます。

ステップ3：コストを測定する

最後に投稿を破棄する形で各ルートのドライランを1回実行し、標準の time コマンドで測定しました。

/usr/bin/time -f "wall %es  cpu %U+%Ss  peak RAM %M KB" <command>

	Playwright	xdotool plus OCR
Wall time	9.3 seconds	20.2 seconds
CPU time (user plus system)	1.4 seconds	1.1 seconds
Peak memory	about 165 MB	about 51 MB

これらは平均値ではなく単一の測定値であるため、大まかな目安として捉えてください。

PlaywrightはNodeプロセスを起動するため、メモリを約110 MB多く消費します。CPU使用時間はほぼ同等です。Playwrightのほうが早く完了するのは、ページが準備完了になるまでのみ待機するのに対し、xdotoolルートでは固定待機を使用しているためです。

最大のコストはどちらのツールでもありませんでした。ブラウザ自体がプロセス全体で約4.6 GBを消費しており、両ルートともこれを共有しています。どちらのツールを選択してもその数値は変わりません。

ステップ4：シンプルなルールで判断する

1. 対象がWebページでありブラウザが利用可能な場合は、Playwrightを使用してください。ページを読み取れるため、何が起きたかを把握できます。
2. X11ディスプレイ上でWebページ以外のものを制御する必要がある場合は、xdotoolを使用し、画面を読み取って結果を確認してください。
3. 実際のWaylandデスクトップを制御する必要がある場合は、ydotoolまたはdotoolを使用し、入力がマシン全体に送られることを許容してください。
4. サイトが無料の公式APIを提供している場合は、いずれのツールよりも先にそれを使用してください。

まとめ

リソースの面では、xdotoolのほうがメモリ消費量が約110 MB少なく、CPUの差は問題にならないほどわずかです。信頼性の面では、画像から推測する代わりにページを確認できるPlaywrightが明確に優れています。1日1回実行されるジョブにとって、1秒のCPU時間やわずかなメモリは実質的なコストではありません。人間が手動で確認せざるを得なくなる"failed"という誤判定の報告こそが、真のコストです。

メリット

• Playwrightはページを読み取るため、操作が正常に機能したことを確認できる。
• Playwrightは画面上の位置に固定されないため、わずかなレイアウト変更で動作しなくなることが少ない。
• xdotoolは非常に軽量であり、X11以外の追加ソフトウェアを必要としない。
• xdotoolは選択したディスプレイにのみ入力を送信するため、ロックされたデスクトップの安全性を維持できる。
• ydotoolとdotoolは、xdotoolが動作しないWayland上でも動作する。
• セカンドルートをフォールバックとして保持することで、1つの失敗でジョブ全体が停止するのを防ぐことができる。

デメリット

• Playwrightはシンプルなxdotoolの呼び出しに比べてメモリを多く消費する。
• Playwrightはページの要素名に依存しており、サイト側で予告なく変更される可能性がある。
• xdotoolは画面を見ることができないため、OCRやスクリーンショットが必要となり、失敗の誤判定を報告することがある。
• ydotoolとdotoolはマシン全体に入力を送信し、特定のウィンドウを選択することができない。
• ydotoolとdotoolは通常、カーネルの入力デバイスへのアクセス権限を必要とする。
• サイトに対するブラウザ自動化はそのサイトの利用規約に抵触する可能性があるため、実行頻度は低く抑える必要がある。

注意点

本記事は教育を目的としたものであり、特定の環境構成の一例を説明しています。記載されている数値は1台のマシンでの単一のドライランに基づくものであり、お使いの環境によって異なります。プレースホルダーの値はご自身のものに置き換え、運用に組み込む前にご使用のディスプレイシステムで各ツールがどのように動作するかを確認し、自動化するサイトの利用規約を確認してください。ydotoolやdotoolの測定は行っていないため、そのコストはご自身で検証してください。

よくある質問

• Linuxサーバーでの自動化にはどれが最適ですか？ — WebページにはPlaywright、X11ディスプレイ上の非Webプログラムにはxdotoolです。選択は制御対象によって異なります。
• xdotoolはWaylandで動作しますか？ — 実際のWaylandデスクトップでは動作しません。仮想ディスプレイなどのX11ディスプレイが必要です。
• ydotoolとdotoolの違いは何ですか？ — どちらもカーネルの入力デバイスに書き込みを行い、Wayland上で動作します。主な違いは、コマンドの指定方法とセットアップ方法にあります。
• CPUとRAMの消費が少ないのはどちらですか？ — 今回のテストでは、xdotoolのほうがメモリ消費量が約110 MB少なく、CPU時間はほぼ同等でした。
• Playwrightのほうが遅いですか？ — いいえ。固定待機に依存しないため、今回のテストでは20.2秒に対して9.3秒で完了しました。
• これらのツールはモニターなしで実行できますか？ — はい。Xvfbなどの仮想ディスプレイを使用することで、メモリ上にのみ存在する画面を提供できます。
• なぜフォールバックルートを残すのですか？ — サイトはいつでもページを変更する可能性があります。セカンドルートがあれば、最初のルートを修正している間もジョブを完了させることができます。
• 共有デスクトップ上でこれらを実行しても安全ですか？ — 注意が必要です。カーネル入力デバイスを使用するツールはマシン全体に入力を送信するため、専用の仮想ディスプレイを使用することをお勧めします。

タグ

#automation #linux #playwright #xdotool #ydotool #dotool #wayland #x11 #browserautomation #devops