10月26日、OpenAIが新しいモデル「GPT-6.1 Terra」を出しました。売りは、画面のスクリーンショットを見て、クリックしたり文字を打ち込んだりする「コンピューター操作（computer use）」が速くて安いこと。OpenAIの発表では、届いた請求書を読んで会計ソフトに入力する、という例がそのまま挙がっています。
中小企業やお店の現場には、「APIなんてない古いシステムに、毎日手で転記している」作業がまだまだあります。予約サイトの管理画面から顧客台帳へ、紙やPDFの請求書から会計ソフトへ。こういう作業がAIに任せられる、という話は正直ワクワクします。
ただ、システムを作る側の目線で言うと、「画面操作できるようになったから全部画面操作でやろう」は危ない。ここでは、何が変わったのかと、自分ならどういう順番で使うかを整理します。
01｜何が変わったのか
画面操作をするAI自体は前からありました。変わったのは「実務で回せるコストと速さになってきた」ことです。
OpenAIの発表で書かれているのは、ざっくりこんな内容です。
- API料金は前のGPT-5.6 Terraより50%安い（報道では入力100万トークンあたり1ドル、出力100万トークンあたり5ドル）
- 業務タスクのベンチマーク（Agents' Last Exam）で、上位モデルのGPT-6 Astraと同じくらいの成績を、トークン単価10分の1で出した
- タスクを終えるまでの時間は、GPT-6 AstraやGPT-6.1 Solの3倍以上速い
- 間違いを誘いやすい質問での誤り率（OpenAI社内の評価）が、低い推論設定で53.6%から16.7%に下がった
数字はどれもOpenAI自身の発表なので、そのまま信じるより「自分の業務で試して測る」が前提です。それでも、今まで「高いし遅いからデモ止まり」だった画面操作が、毎日の転記作業に使うかどうか検討できるところまで来た、というのは大きいと思っています。
02｜画面操作は「最後の手段」にする
ここが一番言いたいところです。AIに業務システムを触らせるとき、自分は次の順番で手段を探します。
- API：システムが公式にデータの読み書き口を用意しているなら、まずこれ
- CSVなどの取り込み・書き出し：APIはなくても、一括インポートやエクスポートがあるならこっち
- 画面操作：上の2つがどうしてもないときだけ
理由はシンプルで、画面操作は壊れやすいからです。
- システム側が画面のデザインを少し変えただけで、ボタンの位置や項目名がずれる
- 読み込みが遅い日、ポップアップが出る日など、毎回同じ画面になるとは限らない
- 1件ずつスクリーンショットを撮って考えるので、APIで一括送信するより時間もトークンもかかる
APIなら「この項目にこの値を入れる」が毎回同じ形で通ります。前に書いた「AIの出力に型を付ける」話と同じで、仕組みに組み込むなら決まった形でやり取りできるほうが圧倒的に楽です。
実際、うちで作っている予約・顧客管理のトレフルでも、Squareとの連携は画面操作ではなくSquareのAPIと通知（Webhook）でやっています。こういう公式の口があるところに、わざわざ画面操作を持ち込む理由はありません。
03｜それでも画面操作が活きる場面
逆に、画面操作がハマるのはこういうところです。
- 10年以上前に入れた業務システムで、APIもCSV取り込みもない
- 取引先や業界団体のWebシステムに、毎月同じ内容を入力しないといけない
- 件数はそこまで多くないけど、毎日少しずつ発生していて、人の時間を確実に削っている
- 本格的にシステムを入れ替えるほどの予算はまだない
「システムを作り直すほどじゃないけど、手でやるのはしんどい」という、中小企業によくある隙間です。今まではRPAツールで画面の座標や手順を細かく決めて自動化するのが定番でしたが、AIの画面操作なら「この請求書の内容を、この画面に入れて」と指示でき、画面が少し変わっても見て判断してくれる余地があります。
ただし「判断してくれる」は「間違えることもある」の裏返しです。なので次の決めごとがセットになります。
04｜任せる前に決めておくこと
OpenAIの開発者向けドキュメントにも、安全に回すための注意がはっきり書かれています。自分なりに中小企業向けに言い換えると、こうなります。
専用の環境で動かす
普段使っているPCや、何でも見られる管理者アカウントでは動かさない。そのAI専用のブラウザや仮想マシンを用意して、入っていいサイトとできる操作を絞ります。
画面に書いてあることを指示として扱わない
Webページやメールの本文に「この操作をしてください」と書いてあっても、それは指示ではありません。ドキュメントでも、画面の内容は信用できないものとして扱うよう書かれています。
取り返しがつかない操作の前は人が確認する
購入、送信、削除、外部へのデータ送信は、最後に人がOKを押す。ドキュメントでは、フォームに機密情報を打ち込むことも「送信」として扱う、とまで書いてあります。
回数・時間・お金の上限を決めて、結果を自分で確かめる
AIが「完了しました」と言っても、それを信じて終わりにしない。実際に会計ソフトに入った金額や件数を、プログラムか人が照合します。
コードにすると、AIが出してきた操作を実行する前に「許可した操作か」をチェックする関数を1枚かませるイメージです（簡略化した例です）。
// AIが出してきた操作を実行する前に通すチェック（イメージ）
async function allowed(action) {
// 画面を見るだけならOK
if (action.type === "screenshot") return true;
// 入力とクリックだけ許可。キー操作やドラッグは不可
if (!["type", "click"].includes(action.type)) return false;
// 「登録」ボタンを押すときは人の承認を待つ
if (action.type === "click" && (await isSubmitButton(action))) {
return await askHumanApproval(action);
}
return true;
}
OpenAIのSDKのサンプルでも、操作の前に許可するかどうかを判定する関数を渡し、実行回数の上限を決めて、最後にページの状態を確認してから「成功」と表示する作りになっていました。考え方は同じです。
05｜まずは1つの作業で、手作業と比べてみる
いきなり全部の転記作業をAIに任せるのはおすすめしません。自分なら、こう始めます。
- 毎日発生していて、APIもCSVもない転記作業を1つだけ選ぶ
- 過去の実データから10件くらい、正解がわかっているものを用意する
- AIに画面操作でやらせて、正解と照らし合わせる（まちがい件数・かかった時間・API料金）
- 本番でも、最初の数週間は「AIが入力 → 人が確認して登録」にする
この答え合わせで「人が確認するだけで済むなら十分楽になる」と思えたら続ける。思えなかったら、そもそもAPIのあるシステムへの乗り換えを考えるほうが早い、という判断もアリです。
画面操作AIは、古いシステムを延命させる道具にもなるし、乗り換えまでのつなぎにもなります。どちらにするかを決めるのはAIではなく、こっちの仕事だと思っています。
「うちのこの作業、AIに任せられる？」「APIがあるか調べてほしい」といった相談も受けているので、気軽に聞いてください。