🧪 D-studyLabブログ
🛠️ 開発環境

AIに任せられない作業がひとつだけ残った——画像アップロードの壁

2026年7月25日

ブラウザを操作できるAIを使っていると、たいていのことは任せられます。ページを開く、文章を入力する、ボタンを押す、スクリーンショットを撮る。記事の下書きを作って、タグを入れて、公開まで通すこともできます。

ところが、たったひとつだけ、どうしても超えられない壁がありました。画像のアップロードです。

記事に見出し画像を1枚設定する。ただそれだけの作業が、最後まで自動化できませんでした。思いつくかぎりの方法を試したので、その記録を残しておきます。

試した方法①:アップロード用の入力欄を直接操作する

Webページで画像を選ぶとき、裏側では <input type="file"> という部品が動いています。ここにファイルを渡せば済むはずでした。

ところが対象のページを調べると、その部品がページ上に存在しませんでした。最近のサイトは、ボタンが押された瞬間に部品を作って、選択が終わると捨てます。つかまえる先がそもそも無い。

試した方法②:部品が作られる瞬間を横取りする

無いなら、作られる瞬間を待ち伏せすればいい。ブラウザの内部処理に割り込んで、生成された部品をつかまえ、そこにファイルの中身を流し込んでみました。

部品はつかまえられました。ファイルも入りました。それでも、何も起きませんでした。

試した方法③:ドラッグ&ドロップを再現する

そのサイトはドラッグ&ドロップにも対応していたので、今度は「ファイルを落とした」という一連の動きをプログラムで作って投げ込みました。

すると反応がありました。画面に「ドラッグして見出し画像に設定」という枠が現れたんです。一瞬うまくいったと思いました。

でも枠が出ただけで、アップロードは始まりませんでした。しかも副作用として、ページがドラッグ中の状態のまま固まり、リロードするはめになりました。

ブラウザは、プログラムが作った操作と、人間が実際に手を動かした操作を区別しています。見た目の反応はしても、肝心の処理は動かない。

試した方法④:OSのファイル選択ダイアログを操作する

最後の手段として、ブラウザの外側から攻めました。Windowsの画面そのものを操作できる仕組みを使って、ファイル選択ダイアログを直接動かそうとしたんです。

結果は、想定していなかったものでした。ダイアログがそもそも開きません。

ここで理由がはっきりしました。ファイル選択ダイアログを開くには、本物の人間のクリックが必要なんです。プログラムが作った合成クリックでは、この条件を満たせません。

なぜそうなっているのか

意地悪をされているわけではなく、これはセキュリティの設計です。

もしプログラムから自由にファイル選択を開けて、勝手にファイルを選べたとしたら、悪意のあるサイトはあなたのパソコンから好きなファイルを吸い出せます。それを防ぐために、ブラウザは「ファイルに触る操作は、必ず人間が起点であること」を要求します。

つまりこれは回避策が存在しない類の制限です。工夫が足りないのではなく、そこは通してはいけない場所として設計されている。

それで、分担をこう決めた

できないと分かったので、諦めるのではなく作業の分け方を設計し直しました。

やること担当
本文を書く・推敲するAI
図やスクリーンショットを作るAI
画像ファイルを整理して番号をつけるAI
画像をサイトに貼る人間
公開ボタンを押す人間

そのうえで、人間側の作業をできるだけ短くすることに力を入れました。記事ごとに専用のフォルダを作り、画像を貼る順番どおりに 00_ 01_ と番号をつけて並べる。本文はボタンひとつでコピーできるようにする。フォルダは最初から開いた状態にしておく。

結果として、人間の作業は「ボタンを押してコピー、画像を順番にドラッグ、公開」だけになりました。ファイルを探す時間がゼロになったのが一番大きい変化です。

できないことを早く見つけるほうが、得

4つの方法を試すのに、それなりの時間を使いました。ただ、この時間は無駄ではなかったと思っています。

「たぶんできる」と思ったまま設計すると、毎回そこで詰まって、毎回別の方法を試すことになります。できないと確定した瞬間に、その前提で組み直せる。

自動化を考えるとき、どこまでできるかを調べるのと同じくらい、どこから先ができないかを確かめることに価値がありました。境界線が引けて初めて、その手前を本気で磨けます。

※2026年7月時点の環境での実測です。ブラウザやサービス側の仕様変更によって結果は変わる可能性があります。
© D-studyLab / ブログ一覧運営者情報プライバシーポリシー