Snapshot

APIがないから画面操作を使う。その判断は、自動化の終点ではなく審査の始点である

企業の重要業務には、APIがない、利用できるAPIが不足している、改修が高額である、といった理由で人が画面を操作し続けているシステムが多い。 2026年6月30日までの Amazon WorkSpaces for AI agents、Windows 365 for Agents、Microsoft Copilot Studio / Foundry、OpenAI、Anthropic の公開資料では、AIエージェントがブラウザやデスクトップアプリを操作する機能が、隔離された作業環境、企業ID、途中介入、監査と結び付けられている。 画面をクリックできることと、本番業務を任せられることの間には、明確な設計差がある。

24

Primary sources

公式資料と画面操作エージェントの評価論文を横断した。

2 modes

Execution model

無人実行と有人実行を業務ごとに選ぶ。

7 controls

Production minimum

隔離、身元、制限、承認、停止、初期化、照合をそろえる。

20.6%

Long-horizon caution

OSWorld 2.0の主要設定で、最良モデルでも長時間課題の完了率は限定的だった。

What Changed

6月末の変化は、computer use が「モデル機能」から「管理された作業場所」へ広がったことにある

Amazon WorkSpaces for AI agents は、ERP、CRM、メインフレーム、独自アプリなどを、既存のID、ネットワーク分離、順守境界の内側で操作する管理環境として一般提供された。 MicrosoftはWindows 365 for Agentsで、エージェント用Cloud PCの貸出・返却、Entra IDとIntuneによる管理、有人・無人実行、リアルタイム介入を明示する。 OpenAIのCodex Remoteは、実行環境を外部公開せずにスマートフォンから出力、差分、試験結果、承認を確認できる設計を示し、AnthropicとOpenAIのcomputer-use資料は、画面操作がプロンプトインジェクションや意図しない操作を伴うことを警告している。

今週の主論点

APIがない業務を操作できること自体は新しい出発点にすぎない。誰の権限で、どの作業環境を、いつ人が止められる状態で使うかが、導入可否を決める。

Seven Conditions

本番候補にする前に、少なくとも7つの条件を決める

1. 隔離された作業環境

人の普段使いのPCではなく、作業ごとに初期化または再現できるCloud PC、仮想マシン、コンテナを使う。誤操作や不正な画面内容の影響範囲を限定する。

2. 専用の身元

誰の代行かを識別しつつ、エージェント専用IDまたは短期資格情報で操作する。共有アカウントでは、操作主体と承認者を追跡できない。

3. アプリと通信先の制限

利用できるアプリ、URL、ファイル領域、クリップボード、外部通信を業務に必要な範囲へ絞る。画面操作が可能でも、任意サイトへの移動を許す必要はない。

4. 有人・無人実行の選択

定型で低リスクの処理は無人、高額取引、個人情報、法的判断を含む処理は有人または混合型にする。自律度を製品全体で一つに決めない。

5. 承認と途中停止

送信、確定、削除、支払、患者情報更新などの直前に承認を置き、異常時は実行中でも資格情報やセッションを取り消せるようにする。

6. 再現可能な初期状態

画面配置、アプリ版、ログイン状態、入力資料を固定または記録する。再試行のたびに状態が変わると、失敗原因も評価結果も比較できない。

7. 実行後の照合

「完了しました」という自己申告ではなく、対象システムを再読込し、変更された値、作成された記録、送信結果を決定論的に確認する。

Execution Modes

無人実行と有人実行は、利便性ではなく失敗時の影響で選ぶ

無人実行に向く業務

  • 入力形式と完了条件が固定された低リスクの照合
  • 失敗しても自動で巻き戻せる定期処理
  • 読取中心の情報収集や報告書作成
  • 件数が多く、人の待ち時間が律速になる業務

有人実行に向く業務

  • 金銭、医療、法務、雇用に影響する更新
  • 画面上の情報だけでは判断根拠が不足する処理
  • 曖昧な入力や複数候補が頻繁に発生する業務
  • 一度確定すると取消や復旧が難しい操作

混合型の基本形

エージェントが無人で資料収集と入力候補作成を行い、人が対象、差分、根拠を確認し、その後の書き込みを再びエージェントが実行する。重要な境界だけを人に戻す。

Concrete Workflows

導入可否は「何をクリックするか」ではなく、どこで確定操作が起きるかで分ける

保険金請求

申請書と添付を開き、契約番号を照合し、入力候補を作るところまでは自動化しやすい。支払区分や金額の確定は、根拠資料と差分を人に提示してから実行する。

患者情報更新

予約変更や連絡先修正と、診断・投薬に関係する更新を分ける。画面の患者IDと依頼元を再確認し、臨床判断を含む変更は対象外または専門職承認とする。

取引照合

複数画面から数量、価格、期日を収集し、不一致を一覧化する。取引の訂正や確定は、対象件数と金額に応じた承認段階を通す。

請求書入力

請求書から取引先、金額、税、支払期日を抽出して入力する。重複請求、取引先変更、閾値超過を検出した場合は保存前に停止する。

Research Evidence

長時間の画面操作では、局所的なクリック精度より、状態管理と検証の失敗が支配的になる

WebArena、VisualWebArena、WorkArena、OSWorld、AndroidWorldは、実際に近いWeb・デスクトップ・モバイル環境で、エージェントが人より大きく低い完了率を示すこと、画面変化や長い操作列に弱いことを報告してきた。 6月28日公開のOSWorld 2.0は、平均318回のツール呼び出しを要する長時間課題を含み、主要設定の最良モデルでも完全完了率は20.6%だった。 失敗は基本的なクリックだけでなく、途中で届く情報、暗黙状態、確認不足、推測による続行に集中している。

この結果から読み取れるのは、短いデモの成功率をそのまま本番の自動化率へ置き換えられないということである。業務を短い検証可能な区間へ分割し、区間ごとに状態を確認する方が現実的である。

Evaluation

評価セットはスクリーンショットではなく、初期状態と最終状態を持つ

完了状態

対象システムの値、作成レコード、送信履歴を直接検査する。画面上の完了メッセージだけを正解にしない。

禁止操作

承認前の保存、対象外顧客への移動、外部サイトへの送信、機密ファイルの持出しが一度でも発生していないかを確認する。

復旧能力

セッション切断、ダイアログ表示、画面配置変更、資格情報期限切れから、安全に停止または再開できるかを試す。

人への戻し方

どの判断が必要か、現在の状態、実行済み操作、残りの選択肢を短く提示できるかを測る。単なる「失敗しました」では不十分である。

Rollout

最初の本番化では、1業務・1環境・1確定操作に範囲を絞る

導入初期は、対象アプリを一つにし、入力資料を固定し、確定操作を一種類に限定する。 最初は読取と入力候補作成だけを無人化し、保存前に人が確認する。実行ログと最終状態の照合が安定した後に、低リスクの保存を自動化する。 画面変更への耐性を高めるために権限や対象業務を広げるのではなく、失敗時の停止と再現性を改善することが先になる。

Takeaway

APIのない業務システムをAIエージェントに触らせる条件は、画面を操作できることではない。隔離された場所で、限定された身元と権限を使い、人が途中で止められ、最終状態を照合できることである。