保存できたか分からない画面操作
APIのない業務アプリでも、画面を読み、入力欄を選び、保存ボタンを押す方式なら自動化を試せる。 Anthropicが2024年10月に公開したcomputer useも、画面を見る、カーソルを動かす、クリックする、文字を入力する操作を提供する一方、実験的で誤りを伴う機能だと説明している。Anthropicの発表
問題は入力できるかだけではない。 保存後に画面が固まった場合、保存は成功したのか、それとも再入力が必要なのか。 判断できないまま同じ操作を繰り返すと、伝票を二重に作る可能性がある。 本稿では請求書入力を想定例に、保存の前後を確認できる単位で画面操作を設計する方法を考える。
管理された作業環境が担う部分
AWSは2026年6月30日、Amazon WorkSpaces for AI agentsの一般提供を発表した。 既存のID管理とネットワーク分離を持つ管理デスクトップで、エージェントが業務アプリを操作する構成である。 実行中の活動を確認し、アクセスを取り消す機能も説明されている。AWSの発表
これは、画面操作モデルに与える場所と権限を管理する仕組みである。 請求額を正しく読み取ることや、保存済みの伝票を見分けることまで保証する機能ではない。 請求書入力に使うなら、管理者は必要なアプリと保存先だけを許可し、業務担当者は対象伝票と完了条件を定める。 実行環境の制限と業務結果の検査には、別々の役割がある。
長い操作の成績を読む際の条件
OSWorld 2.0の初版は、108件の長時間の画面操作課題を評価する。 平均318回というツール呼び出し数は、Claude Opus 4.7のmaximum thinking設定による値であり、業務一般に必要な回数ではない。 主要な完全完了指標では、500ステップ上限でClaude Opus 4.8のmaximum thinkingと一括ツール呼び出しを使った設定が20.6%だった。OSWorld 2.0初版
論文は、制約を忘れる、途中で届いた情報を逃す、確認を省くといった失敗を挙げている。 この結果を自社の請求書入力の成功率に読み替えることはできない。 本稿が設計上の注意として採るのは、クリック単体の正否に加えて、途中の条件と保存結果を確認する必要があるという点である。
請求書入力を三つの区間で確認する
次は導入事例ではなく、保存の不確実さを扱う想定例である。 一つのアプリで取引先、請求番号、金額を入力するとし、まず実データを変更しない検証環境で試す。
- 入力前：対象会社と請求番号を確認し、同じ請求がすでに登録されていないか調べる。画面や資料から対象を一意に決められなければ停止する。
- 保存前：入力欄の値を請求書と照合する。最初の試行では担当者が差分を確認し、保存を許可する。
- 保存後：作成された伝票を開き直し、番号、取引先、金額を照合する。利用できるなら帳票や出力データでも確認する。
同じ画面認識だけで入力と確認を行うと、同じ誤認を繰り返す可能性が残る。 帳票など別の確認手段がないなら、その制約を踏まえて人の確認を残す。 画面に成功と表示されたことだけを、正しい伝票が作られた証拠にはしない。
保存応答が不明な場合は、同じ請求番号を検索して結果を確かめる。 それでも保存の有無を決められなければ、再保存せず、入力済みの項目と最後に確認できた画面を担当者へ渡す。 初期状態へ戻す際も、デスクトップを初期化すれば業務データの書き込みまで取り消せるとは考えない。
無人化の範囲を結果から決める
試験には通常入力に加えて、重複請求、画面配置の変更、期限切れのログイン、保存直後の切断を含める。 正しく登録できた件数と、重複や誤登録、確認不能で止まった件数を分けて記録する。 人の確認時間も測り、手入力より負担が増えていないか比較する。
独立した照合が安定している区間から無人化を検討し、確認できない操作は人に残す。 管理環境と画面操作機能が利用できても、対象アプリの保存結果を検査できなければ、この請求書処理を無人で完了させる根拠は足りない。 導入範囲は、製品がクリックできる対象の広さより、実際に結果を確かめられた作業から決める。