保存ボタンの後に、画面が止まったら

請求書から取引先、番号、金額を読み、業務アプリへ入力する。 AIが保存ボタンを押したところで画面が止まった。 登録は終わったのか。 もう一度押せば進むのか、それとも二重の伝票を作るのか。 これは仕組みを考える想定例であり、実際の事故や導入効果の報告ではない。

APIがないアプリにも届く画面操作は、手入力を減らす選択肢になる。 ただし、ボタンを押すまでの自動化と、正しい登録を確かめる仕事は続いている。 入力を任せた後に、人が毎件の保存を調べ直すなら、担当者の仕事がどこまで減ったかを別に考える必要がある。

2026年6月30日までの資料を比較すると、視覚による操作、管理された作業場所、業務結果の照合という三つの役割が見える。 私の判断は、これらを接続できる短い区間から任せる、というものだ。 対象アプリの広さに加えて、入力の意味と保存結果を人が説明できる範囲を導入の基準にしたい。

画面を見るモデルは、何を観測しているか

Anthropicの2024年10月の研究説明では、Claudeがスクリーンショットを解釈し、移動すべき画素数を求めてマウスやキーボードを操作する。 個々のアプリに専用の接続処理を用意しなくても、画面から操作を選べることがこの方式の価値だ。

同じ説明は、連続した映像ではなく画像を順に見るため、短く表示される通知を見逃し得ることも挙げる。 請求書の例では、保存通知が消えた後の画面だけを見ても、登録の有無を決められない場合がある。 観測した画面、判断した入力値、実際の保存結果を別々に残す理由はここにある。

画面には依頼者以外が作った文章も表示される。 Anthropicは、そこに含まれる悪意ある指示によって本来の依頼から逸れる危険も説明している。 請求書を読む目的で開いた画面の文章が、送信先や処理手順を自由に変える権限まで持つとは扱わない。

AWSは業務アプリを動かす場所を管理する

AWSの6月30日の一般提供発表は、Amazon WorkSpaces for AI agentsを、ERP、CRM、メインフレームなどを操作する管理デスクトップとして説明する。 既存のID管理やネットワーク分離に加え、実行中の活動の確認とアクセスの取り消し、Active DirectoryのIDを使う構成を挙げている。

発表には、画面操作に加えて、MCPの呼び出しをアプリやOSへ転送する機能もある。 管理デスクトップを選ぶことと、すべての処理をマウス操作で行うことは別の判断になる。 利用できる構造化された操作があれば、それと画面操作を組み合わせる余地がある。 精度、遅延、費用の改善はAWSの説明であり、対象の請求書処理で測定された比較ではない。

この環境を使う場合、管理者は操作できる場所と身元を管理し、業務担当者は正しい取引先、金額、完了条件を定める。 アクセスを取り消せても、すでに作った伝票が正しいかは別に調べる必要がある。 環境の管理は、入力内容の判断や登録後の照合を置き換えるものではない。

Microsoftでは作業場所と操作ツールを分けて読む

Microsoftは5月1日、Windows 365 for Agentsの米国限定公開プレビューを発表した。 Intuneで管理するCloud PCを、エージェントの実行場所として提供する。 1月の設計説明には、プールからPCを借りて返す仕組みと、途中で人が操作を引き継ぐ構成がある。

一方、5月13日のCopilot Studio発表は、画面操作機能の一般提供を説明する。 許可したサイトやアプリ、認証情報、承認が必要な場面、人へ戻す確認箇所、実行履歴を扱う。 Cloud PCの提供状態と操作ツールの提供状態を一つの「一般提供」にまとめると、選ぶ機能や利用条件を取り違える。

AWSとMicrosoftから共通に読み取れるのは、エージェントの作業場所やアクセス、途中介入を管理する方向である。 ただし、同じ名前の承認機能でも、請求書のどの項目を誰が見るかは業務側で定める必要がある。 確認できる画面と権限がそろったことから、保存内容まで正しいとは結論できない。

Graebelの報告では、画面入力の前にも仕事がある

同じCopilot Studioの発表は、Graebelのサービス注文処理を紹介している。 APIで接続できないGlobal Connectへ、自由形式のメールから情報を取り出し、業務ルールを検査して画面から入力する。 例外や確信度の低い案件は人へ戻す、という構成だ。

これはMicrosoftが紹介する導入報告である。 手作業の削減や処理の迅速化も述べるが、同じ入力条件での誤登録率や確認時間を比較した測定ではない。 それでも、資料の解釈、業務上の検査、画面入力、人への引き継ぎを分けた具体例として読める。

請求書の想定例にも、この分解が役立つ。 税抜額と請求総額のどちらを入れるかは、クリックする場所を探す問題とは異なる。 入力欄を正しく押せるモデルでも、入れる値の意味を誤れば伝票は誤る。 どの段階で人の判断が必要だったかを残すと、画面認識だけを改善すべきか、資料や業務ルールを見直すべきかを分けられる。

長い課題では、途中まで進むことと完了が離れる

OSWorld 2.0の初版は、108件の長い画面操作課題を評価する。 500ステップを上限に、Claude Opus 4.8をmaximum thinkingと一括ツール呼び出しで動かした設定では、完全完了率が20.6%、部分得点が54.8%だった。 完全完了は、最終状態がすべての採点項目を満たした場合に数える。 途中の進捗と終わった仕事の量は、同じ数値にならない。

論文の経費精算課題では、規程、メールの領収書、銀行の記録、過去の申請から必要な情報を集め、申請を提出する過程を示す。 提出まで進んでも、項目や添付の不足によって部分得点にとどまる。 これは研究課題の実行例であり、企業の本番運用実績ではない。

この研究から、自社の請求入力の成功率を予測することはできない。 課題、環境、操作予算が異なるためだ。 私が設計に採るのは、画面をまたいで必要な条件を保ち、保存後の結果まで検査するという点である。 「提出済み」と「必要な情報が正しくそろった」を別に確かめる。

請求書入力を、三つの確かめられる区間にする

入力前には、対象会社、取引先、請求番号を特定し、同じ請求が登録済みでないか調べる。 番号の表記揺れや複数の候補を扱えなければ、該当なしと断定して新規登録へ進まない。 対象を選び直す仕事を、人へ戻す条件に含める。

保存前には、入力欄の取引先、金額、税、期日を資料と照合する。 最初の試行では担当者が差分と根拠を見て保存を許可する。 確認後に入力値や対象が変わった場合は、その変更を含めて再確認する。 以前の確認を、変更後の内容へそのまま流用しない。

保存後には、作成した伝票を開き直し、対象と主要項目を照合する。 利用できるなら帳票や出力データも使う。 同じ画面認識だけで入力と検査を行うと、同じ誤認を繰り返す可能性がある。 別の照合手段を得られない場合は、その制約を明示して人の確認を残す。

この三分割は請求書処理の提案であり、すべての画面操作に同じ順序を求めるものではない。 読み取りだけの作業なら保存前の承認は不要な場合がある。 更新のある作業では、クリック数に加えて、何が確定し、どの記録で結果を確かめるかを決める。

止める操作と、元に戻す作業を区別する

保存直後に通信が切れたら、同じ請求番号で登録の有無を調べる。 見つからなくても、検索の遅れや別の表示条件が考えられるため、検索結果だけで未保存と断定しない。 それでも決められなければ再保存せず、最後の画面、入力値、試みた操作、結果が不明な点を担当者へ渡す。

人が途中で操作を引き継いだ場合も、返却後に現在の画面と登録内容を読み直す。 人が修正した対象へ、引き継ぎ前の計画をそのまま適用すると、正しい修正を上書きする恐れがある。 介入する機能に加えて、再開時に何を読み直すかが必要になる。

アクセスの取り消しやCloud PCの初期化は、その後の操作や作業環境を管理する手段である。 外部の業務システムへ済ませた書き込みまで取り消すとは限らない。 重複や誤登録が起きた場合は、担当者が対象を確認して訂正や取消の手順を選ぶ。 停止できたことと、業務データの復旧が終わったことを分けて記録する。

受入試験では、人が調べ直す時間まで数える

次は本稿が提案する評価観点であり、四つの指標で測定済みの製品比較ではない。 Anthropicの評価説明も、実行記録、最終結果、採点方法の限界を区別する。 請求入力では、正常な保存の件数に加えて、どこで不明になり誰が直したかを残したい。

入力の意味

取引先と伝票を選び、金額、税、期日を正しく解釈したか。曖昧な候補を人へ戻した件数も残す。

実際の結果

保存した伝票を照合できたか。正しい登録、誤登録、重複、結果不明を分ける。

中断と復旧

切断、画面変更、期限切れのログイン、途中介入から停止や再開ができたか。済んだ操作を重ねていないか。

担当者の負担

確認、対象の選び直し、根拠の調査、訂正にかかった時間を測る。停止件数だけで負担を評価しない。

実データを変更しない環境で、通常の請求と、重複、似た取引先、画面配置の変更、保存直後の切断を試す。 同じ初期状態と資料で手入力や既存の自動化と比較する。 日本語と英語の資料、短い請求書と複雑な明細を分ければ、平均に埋もれる誤りも見つけやすい。

任せる範囲は、確かめられる仕事から広げる

固定された画面や入力形式なら、既存のRPAや一括取込の方が扱いやすい場合がある。 APIが一部でも使えるなら、照合や保存はその経路を利用し、画面操作を必要な部分へ絞る選択もある。 あらゆる業務を視覚モデルへ移すこと自体を目標にしない。

まず読み取りと入力候補を任せ、人が確認して保存する構成で、修正負担を測る。 対象の特定と保存後の照合が安定する区間から、保存まで任せる範囲を検討する。 不明な結果を残す作業は、担当者が判断できる情報とともに引き継ぐ。

画面操作AIの価値は、改修しにくいアプリにも仕事をつなげられることにある。 その価値を現場で確かめるには、操作できる場所、入力の意味、登録後の証拠を一緒に設計する必要がある。 保存ボタンの後で担当者が困らない区間から、仕事を任せていく。