「APIがない？」VB.net製の社内システムをPythonで無理やり動かしてみた日

老朽システムと手作業入力の無間地獄

社内のシステム事情は、どこも似たような悩みを抱えているのではないでしょうか。私の会社も例外ではありません。導入から十数年が経過した顧客管理システム。グレーの背景色に、角張った3Dベベルのボタンが無骨に並ぶ。いかにも2000年代のVB.netで組まれた代物です。この化石のようなデスクトップアプリに対する私の日々の業務は。別システムから吐き出された情報をひたすら手で入力し直すことでした。

なぜそのような作業が必要だったのか。理由は極めてシンプルで。外部からデータを流し込むためのAPIが存在しなかったからです。

手入力の苦悩とシステム改修の壁

CSVデータを一括でインポートする機能すら実装されていません。つまり、どんなに優れた外部ツールを後から持ってきても。人間が画面に直接触れなければデータを1レコードも入れられない仕組みでした。毎日数百件の顧客情報を転記する作業に追われ、酷使した指先は痛み。夕方には目が激しく霞んでしまいます。情シス部門の担当者に「なんとかAPI化かCSVインポート機能を追加してほしい」と頼み込んだこともあります。

しかし「開発したベンダーがすでに倒産しているため。ソースコードは絶対に触れない」と1分で却下されました。その瞬間、目の前がスッと暗くなり。自席に戻ってまた数百件のコピー＆ペーストを再開したときの。あのズシリと重い胃の感覚は今でも忘れられません。APIがないなら、プログラムからのシームレスな連携は諦めるしかないのでしょうか。多くの非エンジニアがここで絶望し。

人力という名のマンパワーでレガシーシステムの穴を埋めようとします。私もその一人でした。来る日も来る日も無機質なキーボードを叩き続けながら。どうにかしてこの無間地獄から抜け出す方法はないかと、必死に考えていたのです。

RPA導入提案、予算却下

まず、手作業の限界を悟った私は、画面操作を自動化するソリューションに目を向けました。世の中ではRPAがもてはやされています。ロボットに画面操作の動きを記憶させれば。APIのない古いシステムでも人間とまったく同じように操作できるはずだと考えました。

提案却下、次なる一手

さっそく有名どころのツールを調べ始めました。WinActorやUiPathなど、国産から海外産まであらゆる情報を収集し。導入メリットをまとめた提案書を作成しました。上司のデスクに持っていき。これで部署全体の業務時間がどれだけ削減できるかを一生懸命説明しました。しかし、返ってきた言葉は冷酷なものでした。「年間ライセンス料が高すぎる。

完全に予算オーバーだ」
実測値: WinActorの年間ライセンス料の概算（約100万円/年）。確かに、企業の経費としてすぐに決裁できる金額ではないのかもしれません。ですが、私が毎月費やしている残業代や。ヒューマンエラーによるデータ修正の事後対応コストを総合的に考えれば。決して無駄な投資ではないはずです。それでも会社という組織は、目に見える大きな出費を極端に嫌う傾向があります。

提案却下、次なる一手（続き）

「お前が手で打った方が安い」と直接言われたわけではありません。ですが、上司の冷たい視線からそのメッセージを強烈に読み取ってしまいました。時間をかけて作った提案書は無惨にも引き出しの奥へと追いやられました。会社が予算を出さないなら、自力でどうにかするしかない。怒りと悔しさが入り混じった感情が、私をまったく別の解決策へと向かわせました。

💡 ここで一度立ち止まって考えてみてくださいPythonやExcel自動化スキルを持ったまま。ITエンジニアとして転職したい方には「EBAエデュケーション」が選択肢です。企業が求めるエンジニア像に合わせたカリキュラムで。実務直結のスキルを習得できます。ITエンジニア転職・EBAエデュケーション →

RPA却下、Python学習の始まりと小さな感動

次に、会社にRPA導入を却下され、絶望しかけた私を救ったのは。怒りと悔しさから生まれた「自力で何とかするしかない」という強い決意でした。手元の資料を片っ端から漁り、ネットの海を彷徨い。あらゆるキーワードで情報を検索し続けました。RPAのように高価なツールが使えないなら、他にどんな方法があるのでしょうか。

まず頭に浮かんだのは、プログラミングという選択肢でした。しかし、私はエンジニアではありません。HTMLを少しいじった経験がある程度で。本格的なコードを書いたことなど一度もありませんでした。プログラミングと聞けば、画面に黒い文字が羅列され、理解不能な記号が並ぶ。まるで異世界の言語のように感じられました。本当に自分にできるのかという不安が先行しましたが、もはや背に腹は代えられません。

この地獄のような手作業から解放されるためなら、なんでもやる覚悟でした。

Python学習の幕開けとエラーの洗礼

「自動化 プログラミング」「業務効率化 言語」「Excel マクロ以外」といった検索ワードで調べると。頻繁に登場する特定の名前がありました。それがPythonです。Pythonは、初心者にも比較的学習しやすい言語として知られています。文法がシンプルで、コードの記述量が少ないため。非エンジニアでもとっつきやすいと言われているようです。

さらに、Pythonそのものが無料で使えるオープンソースである上に。インターネット上には学習リソースが豊富に存在します。有料のRPAツールとは違い、初期費用が一切かからない点は。当時の私にとって唯一の希望の光でした。

Python学習の始まり、エラーとの格闘

しかし、実際にPythonを始めようとすると、また別の壁にぶつかりました。どの学習サイトがいいのか、どんな本を読めばいいのか。そもそも何から手をつければいいのかもわかりません。ネットの情報は膨大すぎて、かえって混乱を招くことも多かったです。結局、まずは評判の良いオンライン学習サイトの無料コンテンツと。

書店で見つけた「いちばんやさしいPython入門」といったタイトルの薄い書籍から始めることにしました。

プログラミング第一歩とエラーの洗礼

退勤後や週末の限られた時間を見つけては、PCに向かいました。「print(‘Hello, world!’)」というたった一行のコードを実行し。画面に「Hello, world!」と表示されただけでも。なぜか大きな感動を覚えたことを今でもはっきりと記憶しています。これがプログラミングの第一歩でした。しかし、次の瞬間から壁が立ちはだかりました。変数、関数、条件分岐、繰り返し処理。

聞き慣れない専門用語が次々と登場し、頭の中はすぐにパンク状態になりました。コードを少し書けばすぐにエラーが発生し。何が間違っているのかもわからず途方に暮れる日が続きました。エラーメッセージをそのままコピーしてGoogle検索にかけるのが日課になりました。なぜこんなにもエラーが出るのか。なぜ自分の書いたコードは動かないのかと苛立ちながらも、少しずつ調べては修正し。またエラー、そして検索の繰り返し。

この地道な作業こそが、プログラミング学習の第一歩なのだと。後になってから知りました。この時点で、「本当にこの学習が。あのVB.netアプリの自動化に繋がるのだろうか」という疑念も常に心の片隅にありましたが。もう後戻りはできませんでした。

pyautoguiによる画面操作自動化と座標の課題

Pythonの基本をある程度理解し始めると。いよいよ具体的な「業務自動化」への道筋を考え始めました。目的は明確です。APIもCSVインポート機能もないVB.net製のデスクトップアプリを。人間が画面に触るのと同じように操作すること。しかし、どうすればPythonでPCの画面を操作できるのでしょうか。

一方で、再びネット検索を開始しました。「Python GUI 自動化」「Python マウス キーボード操作」などのキーワードで調べていると。「pyautogui」というライブラリの存在を知りました。これはPythonでマウスの移動やクリック、キーボード入力といった。GUI（Graphical User Interface）操作を自動化するためのライブラリだそうです。

まさに、私が求めていた機能でした。希望が確信に変わった瞬間でした。

pyautogui自動化、立ちはだかる二つの壁

pyautoguiは、まるで目からウロコでした。マウスカーソルを特定の座標に移動させたり、クリックしたり。特定のテキストを入力したり、キーボードの任意のキーを押したりできます。さらには、画面の一部をスクリーンショットとして保存し。その画像と一致する場所を画面内で探し出す「画像認識」の機能まで備えていました。

さっそく、VB.netアプリの画面操作を自動化するための試行錯誤を始めました。まず最初にぶつかった壁は「座標の特定」です。ボタンや入力フィールドの位置を、X軸とY軸の絶対座標で指定する必要がありました。pyautoguiには、現在のマウスカーソルの座標を取得する`pyautogui.position()`という便利な関数があります。

この関数を使って、VB.netアプリのボタンや入力欄にマウスを合わせては、その座標を地道にメモしていく作業を繰り返しました。

自動化の道のり：課題と模索

しかし、この座標指定には大きな問題がありました。デスクトップアプリは、ウィンドウのサイズが変わったり。画面解像度が異なったりすると、UI要素の表示位置も変動してしまうからです。例えば、ウィンドウを最大化した場合と、半分に縮小した場合では。同じボタンでも画面上のピクセル座標は全く異なります。これは、OSがウィンドウの描画を管理する際に。アプリケーションが指定した相対的な位置情報を。

現在のウィンドウサイズや画面解像度に合わせて変換して表示するためです。結果として、苦労して特定した座標も。別の環境や状況では使い物にならなくなることが頻繁に起きました。

pyautogui画像認識と入力の試行錯誤

そこで次に試したのは、pyautoguiの「画像認識」機能でした。これは、自動化したいボタンやテキストボックスの画像を事前にキャプチャしておき、プログラム実行時に画面全体からその画像と一致する場所を自動で探し出して操作するというものです。`pyautogui.locateOnScreen()`という関数を使えば、座標に依存しない、より頑健な自動化が期待できました。

なぜなら、画像認識は特定のピクセル座標に縛られず、相対的な位置を検出できるからです。たとえウィンドウの位置が変わっても、画面内に同じ画像があればそれを発見してくれます。

しかし、ここにもまた新たな課題がありました。VB.netアプリのボタンの色が少しでも変わったり。フォントのレンダリングがわずかに異なったりするだけで。画像として認識されなくなることがありました。また、画面上に複数のウィンドウが開いている場合。意図しない別の場所にキャプチャした画像と似たピクセルパターンが存在すると。誤認識するリスクも潜んでいました。

自動入力と早打ち問題の解決

そのため、入力作業では、`pyautogui.write()`や`pyautogui.press()`といった関数が活躍しました。これは、特定のテキストをキーボードから入力したり、TabキーやEnterキーといった特殊キーを押したりする機能を再現するものです。

これで、顧客情報の入力フィールドにデータを流し込み、Tabキーで次のフィールドへ移動し、Enterキーで確定するといった、人間が行う一連の操作を再現できるようになりました。

早打ち問題解決、自動入力の喜び

しかし、ここでも「早打ち問題」という壁に直面しました。プログラムから驚くほどの速度でキー入力を行うと、VB.netアプリ側がその処理に追いつかず、一部の文字が入力されなかったり、次のフィールドへの遷移が正常に行われなかったりするのです。なぜそうなるのか。これは、アプリケーションがキー入力イベントを受け取り、それを処理するまでにわずかなタイムラグがあるためです。

人間が入力する速度であれば問題ありませんが、機械的な速度では、システムがイベントを完全に処理する前に次のイベントが来てしまい、取りこぼしが発生してしまうのです。この問題は、各操作の間に`time.sleep()`という関数を使って数ミリ秒から数秒の待機時間を設けることで解決できました。

度重なる試行錯誤の末、たった1レコード分の顧客情報を。Pythonのコードで自動的にVB.netアプリに入力させることに成功しました。手動で数十秒かかっていた作業が、プログラムではわずか数秒で完了します。その瞬間、夜中に一人、PCの前で小さくガッツポーズをしたことを今でも忘れません。たったこれだけのことですが、とても感動したのを覚えています。しかし、これは数百件のレコードを処理する道のりの。ほんの始まりに過ぎませんでした。

関連リンクとチェックリスト

学習サービスとアンケート