「顧客が本当に必要だった物」PythonではなくてAHK V2だった
せっかく学習中のPythonを使ってRPA、PC作業を自動化させようとして色々調べた結果、RPA事情を深く探ることになってしまった。今日結論が出たので軽くまとめることにした。脱UWSCのため結論。
(約 5,800文字の記事です。)なぜかこの文字数。どうして……。
調べたソフト一覧
アルファベット順に。
Auto Hot Key, Py AHK
AutoIt, PyAutoIt
PyAutoGUI
PyWinAuto
Selenium
これらのついての検討内容をつらつら書いてもしょうがないので要点だけ。
レコーダー機能が重要なのにまともなツールが少ない
上記でレコーダーが正常動作するのはAutoItとSeleniumくらいだ。この3日間で色々検証したが、PyAutoGUI, PyWinAutoはレコーダーが使い物にならない。
一般ユーザーが作業を自動化するためには、
録画
再生
おかしいところを調整
この3ステップで十分なのだ。だがその最初の入り口の録画機能がお粗末なRPAツールが多い。その点UWSCは優秀だった。作者逝去が惜しまれる。
なので調べまくってもレコーダー機能がまともに動くものはかなり少ない。AutoItが一番まともだろう。
Seleniumは除外
Webブラウザを制御するならば逆にSelenium一択だろう。ほぼ間違いない。だが私がやりたいことは別にWebスクレイピングなどではないのでそんなにWeb要素に限ったピンポイント制御は必要ない。またRPAツールの宿命として「超絶細かく正確に動作するほど」命令の指示が超絶細かく必要なのだ。なのでとにかく手間がかかる。そしてそこまでして超絶正確に作り込んでもWebサイトリニューアルや細かなバージョン変更ですぐにまた挙動をフルチェックしなければならない。まるでF1カーの如く繊細だが、正常動作していれば完璧に動作する類いのツール。要するにブラウザ(ドライバ)のアプデとサイトのアプデに弱い。小まめなメンテが必要。
AutoItも除外
まずコミュニティーが古すぎる。情報が2009年代のものがごろごろ出てくる。AutoItも10年前はRPA界の主力の一つだったが今はオワコン臭がひどい。またPythonとの連携もほぼ絶望的なのでこちらも早々に検討から除外。
PyWinAuto、レコーダーが絶望的
実はかなり検討していたPyWinAuto。期待のレコーダーだがこれが絶望的だった。まず実行ファイルのexeがアンチウィルスソフトでウィルス認定。多分ウィンドウなどの情報を取得する挙動がマルウェアなどの挙動とほぼ同じだからだろう。ならば自分でソースファイルから動作させてみては?と思って四苦八苦しながらPythonのパッケージを入れて色々試行錯誤し、exeファイルではなくてPython上でそのレコーダーを動作させてみたのだが、どうにもバグだらけ。画面の位置もずれている。
だが機能がまともならいいかな、と思って実際にマウス操作を録画してみたがまぁひどかった。全然役に立たない。
というわけで4~5時間の格闘はまったく無意味で水の泡となった。
またレコーダーなしだとこれまたSeleniumと同じ類いで、詳細にWindow制御をできる代わりに、これまた詳細にPyWinAutoの仕様をドキュメントとにらめっこしながら体得する羽目になる。この学習コストの高さがRPAソフトの最大のネックなのだ。もっと簡単に、さっと録画してさっと再生して、さっとバグ修正してそれで「さっさと実際の運用に入っていきたい」のだ。それがサッとできないRPAソフトは、はっきり言ってお呼びじゃない。業務用のハイリスク・ハイリターンな堅いソフトを仕上げようってんじゃぁないのだ。
なのでPyWinAutoもお蔵入り。結構期待していただけに残念。
PyAutoGUI、シンプル過ぎてレコーダーがない
あるにはあるがメンテされておらず、使われてもいないものが2、3見つかった。趣味で作ってみました系のソースコードがGitHubで見つかったくらい。まぁシンプルだからレコーダーすら要らない気がする。PyAutoGUIの存在価値は画像を使った認識&クリック位置の取得ができる点。地味にこれが重要。というのもテキストベースのRPAだとどうしても画像認識というチカラ技を採用しない場合がほとんどだ。それだけ意固地にテキスト指定にこだわらなくてもいいと思うのだが、なぜかそうなっている。
なのでPyAutoGUIはもしPythonでRPAをやる場合には補助的に活躍する予定。(ただし画像認識の精度と認識時間が果たして使い物になるのか?という問題もある。なので将来的な予備手段として今は検討を保留した。実験もしていない。画像認識&クリックはかなりのチカラ技であり最終手段にしておきたい。できれば使いたくない。)
結局、消去法でAHK V2
結局は残ったのはAHK。ただしここでも検討材料がたくさんあった。まずAHKはV1.1とV2の2種類ある。互換性はない。記法もガラッと変わった。そして過去資源はV1系がかなり多い。V2系は少な目。これから増えるだろう。AHK公式も2023年にV2を主流にする宣言を発表している。V1は徐々に過去の遺産になる流れ。
これが気になって結構試行錯誤したし、1.5日くらい費やした。結果としては、確かにV2はV1とはまったく異なる言語になったものの、動作としてはかなり安定していた。ここが嬉しいポイント。常用しているAHKソースを四苦八苦しながらV2に修正して動作させてみたらビックリ。今まで不満だった「挙動の怪しさ」がピタリと収まった。これだけでもV2を選ぶ価値がある。また動作も速くなった気がする。
未だに根強いV1.1系。現行V2はこれから。
だが危惧する点も一つ。AHKのコミュニティーの大勢は基本的にレコーダー非推奨派。プログラマ派が多い印象。なのでAHKのレコーダーも過去に何種類も作られてはメンテなし放置で消えていった。今残っているのはPulover’s Macro Creator(PMC)のみだ。だがPMCはAHK V1.1のみの対応。だからいずれはV2にソースをコンバートする手間が発生する。なのでレコーダーでの記録とテストと仮運用はV1で。そしてある程度枯れたらV2にコンバートして運用という、ちょっとした工夫が必要。
だがその問題がない場合にはV2運用が必須。今のPC環境に合わせて進化できているので、逆に古すぎるV1系はだんだんと挙動が怪しくなってくきた。今のPCハードや他のソフトとの競合?など、色々と不具合が顕在化しつつあるのがV1系の悩みどころ。まぁ確かにもう15年以上前の資産だから無理もない。
心細いがとりあえずレコーダーはある。
PMCについてもこれまた2~3時間かけて色々いじくり回した結果、とりあえず現用のUWSCのレコーダー並かそれ以上のまともな動作を確認した。エクスポートがAHK V1系なのが辛い。(ちなみにGitHubで公開されている、誰かが改造したV2対応PMCだが、バグで保存できない。保存が「開く」クラスで実装されているため。初歩的すぎるミス。信用できないので却下)
なのでPMC本家を使う分には記録はまとも。ただしV1系。なので運用ルールでカバーしつつ安定運用したらV2にコンバートして運用にすれば、まぁ安定させられるだろう。
とりあえずAHKで運用してもレコーダーはまぁ普通にUWSC並に使えるワークフローは作れそうなので、次に進もう。
PythonでもAHKを使える
PythonからAHKの.ahkファイルを直接読み込んで実行させることもできる(IDE環境側での設定必須)。またAHKのラッパーとしてPython構文で直接AHKを動作させるPIPパッケージも存在する。そしてV1, V2両方サポート。
またAHK本家もこのラッパーも十分詳細なドキュメントが有志によって作成されている。このコミュニティーの活発さがAHKの魅力だ。
なので作戦としては基本的にAHKで作業を自動化し、画像認識クリックが必要ならばPyAutoGUIをPythonで動かして作業を自動化するという合わせ技を検討している。
あれ?結局ほとんどAHK V2でRPA完結?
そしてよくよく考えると、AHK V2は新規言語みたいなほどにV1との違いがあるので、実際問題、AHKをV2で運用するならば新規でプログラミング言語を覚えることとほぼ同じ。またPythonラッパーを使ってPython上で実現させるにしてもPython構文とは別にAHKパッケージのメソッド(関数)リファレンスに習熟しないと思い通りの作業をコーディングできない。
またPMCでレコーディングした内容をカスタムするためにもAHK構文を多少は学ばなければならないし、V2への機械的なコンバート後の細かいチューニングは結局はAHK V2の言語を理解しないと詰まる。
結局、RPAはほとんどがAHK V2で構築され、どうしてもテキストベースでAHKで何ともならない「画面上の見た目ベースでクリックする」場合のみ、PyAutoGUIの画像認識でクリックさせることになる気がする。
でもこの2種類、連続的に作業することがあるか?という問題。そもそも画像認識で失敗した場合には目視で人間が作業を修正して続きをAHKにやらせるとなるので、そうなると連続性がないならば「ここまでは.ahk、ここからは.py」となるならば、わざわざAHKをPython上で実行させる必要もない=AHKラッパーの学習をしなくていい=AHK V2に習熟すればいい。
あれ?Python、どこ行った?😭
PyAutoGUIだけなら120時間もPython学ばなくても使えるぞ!多分2~3時間もあれば実装までいける気がする。ずいぶん遠回りした。
面倒な事はAHKにやらせばいい
別にPythonじゃなくていいぞ、むしろWindow制御ならAHKのほうがV1時代から培われたノウハウがある。それがV2になって構文的に多少変わったが機能はむしろ安定し、プログラミング言語としてはかなり堅くなった印象だ。
第2手段としてPythonでもAHKを記述できるし、Pythonから.ahkを直接読んで実行もさせられるという連携度の高さは安心できる。あとは今はとりあえずPMCレコーダーで何とか「お気楽録画&再生」ができるので、AHKのV1系とV2系との運用ルールを決めれば特に問題ないだろう、面倒だが仕方がない。
そうなるとRPAのほとんどは実はAHKで完結できる。あえてPythonを使わずともよい。Webブラウジングの自動化ならSelenium+Pythonで決まりだが、GUIベースのWindowsアプリならば、ガッチガチのエラーなし処理の自動化システムを目指さない限り、AHKで十分な気がする。
サッと録画して
サッと再生して
サッと修正して
サッと実運用に導入できる
こういったフットワークの軽さこそが実はRPAで最も重要。その点ではUWSCはかなり完成度の高いソフトだった。実に惜しまれる。これに一番近いワークフローはAHKだろう。V2対応だけがちょっと手間になるが、その後の安定度は魅力。ただし学習コストはV2を新規言語として習得する必要があるのでそこだけがネック。だがRPAソフトとしてはあと5年は堅いだろう。
結局、やろうとしていたイメージがRPAだとハッキリ認識できないままえいやっとPython学習に入ったが、精査してみれば実は必要だったのはAHK V2の習得だったという、まさに「顧客が本当に必要だった物」みたいなオチになってしまった😭
明日からPython集中講座から日常に復帰
というわけで大きくモチベがなくなったw なので今日までほぼ3週間ほど強行したPython集中学習もいったん終了。明日からは少し計画を見直してPython一色の生活から変える必要がある。今必要なのはPythonよりもAHK V2だったので。といってもかつて使っていたV1から「できること自体は大きく変わっていない」ので、主に構文だけについて何がどう変わったかチェックすれば割と早く習得できそう。まとめサイトなんかも探せばでてきそう。
あとはPythonならばPyAutoGUIによる画像認識クリックの精度や遅延について検証する必要がある。
とりあえずここまで詰め込んだPythonなのでここで放り出さずに「1日1学習」などと計画的に継続的にPythonをいじる日々を維持したい。使わないと忘れるのが言語の宿命だから。まだPythonにはポテンシャルを感じるし、Blenderアドオン開発の道も残されているので。
とにかく明日からはまずはAHK V2のリファレンスを速読だ。
今日はこれまで。
明日からは通常通り、夜のnote更新はしない日常に戻る予定。やはり夜はダラダラと、読みづらい日記を垂れ流す癖がある。誰得だし睡眠時間も減るし。こういう悪い習慣は切り捨てるに限る。飲酒然り、SNS然り。
今回の創作活動は約1時間30分(累積 約3,831時間)
(1,087回目のnote更新)
今日の一杯はこちら。スーパーで投げ売りだったが納得。後味がとても薬臭いです。昔の防虫剤の香りを思い出した😖