■ 導入：別々に作られた2つの自動操作を「同時に回したい」
この案件で相談を受けたのは、
異なる2つのブラウザ繰り返し操作のAHKを、1本に統合して運用したい
という内容でした。
もともと依頼者の方は、
「ブラウザ上で行う自動操作A」と「自動操作B」を別々のAHKとして持っていて、
それぞれ単体では動いている状態でした。
ただ、実際の運用としては「AとBをできるだけ並行して回したい」というニーズが強く、
2本のスクリプトをどう組み合わせて動かすか が課題になっていました。
■ 課題：AHKは“フォーカスを取り合う”ので、本質的に同時には動かせない
ブラウザ操作の自動化では、
どのウィンドウにフォーカスがあるか で挙動が決まります。
そのため、単純に
自動操作A用のAHK
自動操作B用のAHK
を同時起動すると、
互いにフォーカスを取り合う
片方が操作中にもう片方が割り込む
結果として、どちらも意図した動きにならない
という問題が起こります。
さらに厄介なのは、
AとBで使うページが同じブラウザ（Chrome）上にあり、
Aをすべきページ
Bをすべきページ
を取り違えると、誤操作のリスクが非常に高いという点です。
加えて、
自動操作の間隔や「1バッチの繰り返し回数」には上限もあり、
どの程度のペースで回すか という設計も見直す必要がありました。
■ 改善①：2つの自動操作を1本のAHKの中で“順番よく回す”方式に再設計
まず行ったのは、
「AとBを別々のAHKで動かす」という前提をやめて、
1本のAHKの中でAとBを制御する
という形に設計を切り替えることでした。
どのタイミングでAを動かすか
その待ち時間のあいだにBをどこまで進めるか
AとBの順序をどう並べると一番効率がいいか
といった「運転スケジュール」を組み直し、
片方の待ち時間にもう片方を進める ことで、
2つの処理を“見かけ上並列”に動かす構成にしています。
■ 改善②：A用ページとB用ページを確実に識別し、正しいブラウザだけを操作する
次に重要だったのが、
「今どのページにいるのか」を間違えずに判定すること
です。
AとBはどちらも同じブラウザ（Chrome）を使いますが、
開いているページはそれぞれ違います。
もしここを取り違えると、
本来はAをすべきページでBの操作をしてしまう
新しくChromeを開いた場合に、別のウィンドウを触ってしまう
といった誤作動につながります。
そこで、
Aを行うべきブラウザ
Bを行うべきブラウザ
を識別できるようにし、
両方のページが開いていても、新規でブラウザが開いても、
常に“正しいほう”を選んで操作する 制御を組み込みました。
これにより、
Aをすべきときは必ずAのページに
Bをすべきときは必ずBのページに
という形で、
操作対象を取り違えない自動化 が実現できました。
■ 改善③：バッチの間隔・回数上限を設計して“無理なく回し続ける”
依頼の中には、
自動操作の間隔や1バッチの速度、
その繰り返し回数上限といった条件もありました。
そこで、
AとBそれぞれに対して、
「1回の処理にかかる時間」と「待機すべき時間」を整理
そのうえで、
1バッチあたり何回まで繰り返すか をパラメータとして持たせる
という形で、
無理なく回し続けられるペース設計を行いました。
これにより、
必要以上に高頻度で回しすぎない
条件に合わせて上限を守った運用ができる
という、現実的な自動運転が可能になっています。
■ 成果：2つの自動操作を“ぶつけずに”、かつ“時間も無駄にせず”動かし続ける仕組み
こうした設計の結果、
本質的に同時実行できない2つのブラウザ操作を、
1本のAHKの中で効率よく交互に回せるようになった
Aの待ち時間にBを進めることで、
PCの待ち時間をほぼゼロに近づけられた
A用ページとB用ページの識別を誤らず、
誤操作のリスクを抑えた
という、“生産性と安全性のバランスが取れた自動化” に仕上がりました。
この案件では特に、
「2つの独立したスクリプト」をどう統合し、
どんな順番で回せば、一番ムダがないか
を設計する部分が、一番のポイントだったと感じています。
■ まとめ：複数の自動化を「どう運転させるか」まで含めて設計する
今回の案件は、
単に「2つの自動処理を足す」のではなく、
同時には動かせない前提を理解したうえで
待ち時間の活用や順番の組み替えによって
1本のスクリプトとして最大限効率よく回す
という、運転設計そのものを作り直した例でした。
今後も、
「既にある自動化同士をどう組み合わせるか」
「どんな順番で動かすと現場の生産性が一番上がるか」
といった視点も含めて、実例を紹介していきます。
▶「複数の自動化をまとめて運用したい」「今あるスクリプトの“運転設計”を見直したい」という方はこちら
