何が起きたか

ゲームのビルドを配信に反映する作業でした。手順は3つです。

1と2は自動で通りました。3だけ、何をやっても反映されません。

試したことと結果：

いちばん困ったのは、エラーが出ないことです。「押した」という反応が返ってくるのに、画面の状態が変わらない。ログを見ても成功しているように見えるので、原因を探すのに時間を使いました。

座標クリックには、そもそも罠があった

座標で押しにいくときに、もう1つ引っかかったので共有します。

スクリーンショットの幅と、ページの表示幅は一致しません。

このときは、ブラウザ側の幅が2880px、スクリーンショットの幅が1478pxでした。素直に 2880 ÷ 1478 = 1.949 で割れば座標が出る、と思いますよね。

出ません。 実際にはページの中身は左の約983pxにしか描かれていなくて、残りは余白でした。正しい倍率は約2.93倍。1.949で計算すると、まったく違う場所を押します。

確実にやるなら、getBoundingClientRect() でボタンのCSS座標を取って、スクリーンショット上で実際にボタンが写っている位置と突き合わせて倍率を出すしかありません。

とはいえ、この計算を正しくやっても今回は反映されませんでした。座標が合っていても押せないものは押せない。

原因の追究をいったん止めて、設計のほうを変えました。

さっきの手順3は、専用のURLを持っています。

https://.../previewbuildchange/<アプリID>/<ビルドID>?betakey=default

このURLを開くと、確定ボタンがある画面にいきなり着きます。つまり、

こうしたら、人間側の作業は10秒になりました。手順を説明する文章もいらなくなります。「このリンクを開いて、このボタンを押してください」で終わりです。

私は最初、100%自動化しないと負けみたいな気持ちで座標クリックを繰り返していました。でも実際に価値があったのは、

人間の作業を「10分の手順」から「1クリック」に減らしたこと

のほうでした。1クリック残っていても、実用上はほぼ困りません。

確定・送信・購入・削除みたいな取り返しのつかない操作ほど、自動操作を弾く仕組みが入っています。これはバグではなくそういう設計であることが多いです。

だとすると、正面から突破しようとするのは筋が悪い。**「人が押す前提で、そこまでを最短にする」**ほうが設計として素直です。

多くのWebアプリは、途中の画面にも直接飛べるURLを持っています。自動操作が詰まったら、まずそのURLがあるか探す。 今回はこれで解決しました。

見つけ方は簡単で、手で1回その画面まで進んで、アドレスバーを見るだけです。IDが入っているだけの素直なURLなら、次からはそこへ直行できます。