すべてのカテゴリ

■ 導入：最初はキー操作だけで動かそうとする依頼だった今回紹介する案件は、ブラウザ上で同じ操作を繰り返していく作業を自動化したいという依頼でした。依頼者から最初に提示された方法は、「すべてキー操作でカーソル移動して自動化する」というものでした。また、キーワードについても「Excelのリストを順番に読みながら進めていく」という方針が示されていました。ただ、この時点では“どう読むのか”“どのタイミングで渡すのか”など、運用の詳細はまだ固まっていない状態でした。■ 課題：キー操作だけでは、ブラウザバックや画面遷移でズレが発生する実際に画面遷移があるブラウザ操作では、ブラウザバック別ページへの遷移読み込み速度の違いによって、カーソル位置が簡単に飛んでしまうという問題があります。最初の指示どおりに「すべてキー操作」で進めると、フォーカス位置が毎回同じとは限らないタイミングによって動作がズレる一度ズレると連続処理が破綻するという不安定さが避けられませんでした。さらに、依頼者自身が気づいていない“想定外の挙動”もいくつかあり、これらをそのままにすると「動く時と動かない時が混ざるスクリプト」になってしまう状況でした。■ 改善：画像認識とキー操作を、操作ごとに最適に組み合わせる方式へそこで私は、「全部キー操作」「全部画像認識」いずれにも寄せないハイブリッド方式を提案しました。毎回位置が変わらない操作 → キー操作ブラウザバック後など位置がズレやすい操作 → 画像認識で確実に押す画像認識は類似度調整・補正・リトライで安定化というように、操作の種類ごとに最適な手段を選ぶ設計にしました。この方式により

■ 導入：ページ数の多いテキストを、読みやすいMarkdownに整えたいこの案件は、「ページ数の多いテキストデータを、ChatGPTでMarkdownに整えたい。ただ、量が多すぎて手作業では現実的じゃない」という相談から始まりました。元データには「page 1」「page 2」のような区切りが入っていて、ある程度ページ構造は見えているものの、どこからどこまでをまとめて投げるかどれくらいの分量なら安定して処理できるかどこまで処理済みかをどう管理するかといった部分は、すべて人力でなんとかしている状態でした。■ 課題：長いテキストを「どこで切るか」と「どこまで済んだか」が曖昧ChatGPTでMarkdownに整えていく作業を、もし手作業でやると、テキストファイルを開くコピーする範囲を決めるChatGPTに貼り付けて整形してもらう結果を別のファイルに貼り直す次のページへ…という流れを延々と繰り返すことになります。ここで問題になるのは、毎回「どのページからどのページまでコピーするか」を目で判断するどこまで処理したかを自分で覚えておかないといけない分量が多いと、途中で抜けや重複が発生しやすいという、人間の記憶力と根気頼みの部分でした。「ページ構造はあるのに、それを自動処理にうまく活かせていない」というのが、この案件の一番のポイントでした。■ 改善：ページ番号を起点に、“2ページ単位”で自動分割 → ChatGPT連携そこで用意したのが、1つのテキストファイルを「page ○○」ごとに解析し、指定範囲を Nページごと（デフォルトは2ページ）に自動で分割しながら、それぞれをChatGPTに送っ

■ 導入：大量の画像をまとめてOCRしたいという相談今回の相談は、フォルダに入った大量のJPEG画像を、ChatGPTで順にOCRし、テキストとしてまとめたい。できれば途中で止まらず動いてほしい。というものでした。依頼者は ChatGPT のOCR精度を評価しており、これを“実務でも使える形”に落とし込みたいというニーズがありました。■ 課題：ChatGPTのUIは環境差が大きく、固定的な自動化では“止まりやすい”ChatGPT の画面は、画像アップロードの位置アップロード後の待ち時間返信の表示テキストコピーの挙動などが環境によって微妙に違うため、単純な時間待ちで自動化すると、遅延やUI変更で止まってしまいやすい問題がありました。また、画像が多いと 1枚止まる＝全体が止まる という致命的な状況になります。依頼者が求めていたのは、“枚数が多くても、できる限り止まらず処理を進められる仕組み”でした。■ 改善①：アップロード操作を“安定しやすい方法”に統一画像添付は、UIの変化に影響されやすい“ボタン操作”ではなく、画像を貼り付ける方式最小限のキー操作で確実に添付できる方法に切り替えることで、アップロード操作の安定性を大きく高めました。“どこの環境でも同じ動きになる”という視点を最優先にした設計です。■ 改善②：ChatGPTの回答取得も“状態を見て判断する”方式へOCR結果の取得も、固定スリープではなく、ChatGPTが回答を出したタイミングコピーが可能になったタイミングを“状態として確認”しながら進めることで、ネットワークが遅い日でも早い日でも、比較的安定して処理が進むようにしま

■ 導入：既にある「手動フロー」を、まるごと自動化してほしいという相談この案件は、最初からゼロの状態ではなく、依頼者の方がすでにブラウザから HARファイルを作成（手動）その HAR を Pythonスクリプトで解析・抽出（手動実行）という流れを運用されているところからスタートしました。新たな要望としては、抽出したデータ（複数の文章）に対してChatGPTで1件ずつ返事を書きたい。それも含めて一連の流れを自動化したいというものでした。つまり、「HAR作成 → Python抽出 → ChatGPTで整形 → CSVに蓄積」というすでに存在しているフロー全体を、できるだけ人の手を介さず回したいという相談です。■ 課題：工程が分かれているうえに、どこか一つ失敗すると全体が止まってしまうもともとの運用は、HARファイルを作るPythonスクリプトを実行して抽出する抽出したテキストをChatGPTに貼って、返事を書いてもらうそれをまた別の形にまとめるという形で、**工程ごとの区切りはあるものの、連携は完全に“手作業”**でした。この状態だと、実行のたびにファイルを指定してPythonを叩く必要があるChatGPTへのコピペと結果の保存が繰り返し作業になるどこか一つで失敗すると、どこまで完了しているか追いかけるのが大変といった、**「フローの長さ」「人手の介入」「失敗時の復旧のしづらさ」**が課題になっていました。■ 改善①：処理をStep1〜6に分解し、Masterスクリプトで一括制御する設計へここで私が最初に考えたのは、すべてを一気に自動化する前に、工程を“ステップ”として分けて設計す

■ 導入：別々に作られた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の順

■ 導入：一覧から順に、自動で返信していきたいという相談今回紹介するのは、あらかじめ用意したリストに基づいて、ブラウザ上で自動返信操作を行っていくスクリプトの案件です。依頼者の方は、返信対象ごとに「URLに入れる文字列」とそれに対応する「返信文」を replies.tsv にまとめており、それを元に intent URL を開いて返信画面を出し、送信まで自動化したいという要望でした。見た目はシンプルな「自動返信」の相談ですが、実際には ネットワーク遅延や画面の状態変化に左右されない“確実な動作” が求められる案件でした。■ 課題：時間待ちだけでは、ネットワークや画面の揺らぎに対応できない自動化でよくやりがちなのは、「intentで画面を開く → ○秒待つ → Tabで移動 → 送信」という、“決め打ちの時間待ち”だけで流れを作る方法です。しかし、この方法には大きな弱点があります。回線状況やサーバーの混雑によって、画面の表示時間が変わる返信入力欄が出てくるタイミングが一定ではない送信が終わるまでの時間も毎回同じとは限らないつまり、「○秒待ったから大丈夫だろう」では、いつかズレる ということです。依頼者も「できるだけ確実に送りたい」という意識を持っていたので、ここは時間待機だけに頼らず、画面の状態そのものを見て判断できる仕組みが必要でした。■ 改善①：intentウィンドウの“差分”を見て、今の状態を判定するこの案件でまずこだわったのは、intentウィンドウの状態を「差分」で判定することです。具体的には、ウィンドウタイトルの変化などを利用して、「返信入力が可能な状態」 なのか、「

■ 導入：当初の指示は「Alt+Tabを回数で回してほしい」だけだった今回紹介する案件は、複数のChromeウィンドウに対して同じ操作を順番に行っていくという依頼でした。最初にいただいた指示はとてもシンプルで、「Alt + Tab の回数をカウントアップすることで複数ウィンドウを順番に切り替えて操作Aをしていきたい」という内容でした。ただ、この段階で聞けていたのは“表面上のやりたいこと”だけ。ヒアリングを重ねるうちに、この案件の本質はもっと深いところにあることが分かっていきました。■ 課題：Alt+Tab方式では順番が安定せず、本当にやりたいことが達成できない依頼者がやりたいことの中で、実は最も重要だったのは、「各ウィンドウで操作Aを行い、その途中で発生する待ち時間を活かして、他のウィンドウでもAを進めていき、途切れなくAを回し続けたい」という点でした。この“本当の目的”は、最初の指示では表に出ていませんでした。実際、操作Aには途中で必ず n秒の待ち時間 が生じます。1つのウィンドウだけでAを行うと、この待ちのたびに時間が止まる。そこで依頼者は、複数ウィンドウを並列的に使い、無駄な時間を無くしたい と考えていました。しかし Alt+Tab は、ウィンドウの順番が保証されない新しいウィンドウを開くと並びが変わる「1→2→3→4…」のように確実に回せないという特徴があるため、並列処理の前提が崩れてしまう方法でした。ここで初めて、Alt+Tab方式では依頼者の本当の目的を実現できないことが明確になりました。■ 改善：複数ウィンドウを正確に列挙し、“n秒の待ち”と“並列操作”を両立させ

■ 導入：最初は「画像認識がうまくいかない」という相談だった今回紹介するのは、ココナラで受けた最初期のAHK案件のひとつです。依頼内容はとてもシンプルで、「Windowsのトースト通知が出たら、自動でクリックしたい。ただ、自分で書いたコードではうまくいかない」という相談でした。すでに依頼者の方はAHKでコードを書いていて、やりたいこと自体は明確でした。ただ、想定した動きにならず困っている、という状態でした。■ 課題：自作の画像認識コードが安定せず、思ったように動作しなかった依頼者が抱えていた課題はただひとつ。「自分で書いた画像認識コードがうまく動かない」というものでした。認識が成功しない、クリックまでつながらない、そういった形で、狙った動作が発生しなかった というのが実際の問題でした。まずはその原因を整理し、「どういう状況で通知を扱いたいのか」をヒアリングしながら、改善の方向性を固めていきました。■ 改善：外部ライブラリの利用と、通知の出方を踏まえた設計最初の改善ポイントは、画像認識の方法そのものを見直すこと でした。依頼者が使っていた標準的な画像検索関数では難しい部分があったため、私は 外部AHKライブラリを #Include で読み込む方法 を提案しました。これは、目的に合った手段を選んだほうが、結果として精度も安定するためです。さらに、この案件で重要だと感じたのは、「通知は必ず一つずつ出るわけではない」という点でした。連続して通知が出るケースや、短時間に複数の通知が溜まるケースもありえるため、そこまで含めて設計を考える必要がありました。そこで、通知が出たときだけ反応する同