結論：画面を操作できることと、取引を正しく完了できることは別
AWSは2026年6月30日、Amazon WorkSpaces for AI agentsの一般提供を発表しました。AIエージェントが管理されたWorkSpaces環境からERP、CRM、mainframe、独自desktop application等を画面操作できるサービスです。
公式説明では、MCP対応、active session timeに応じた価格、MCP tool forwarding、operatorによるreal-time session controlと途中のaccess revoke、Active Directory identityを使うdomain-joined fleet等が示されています。
APIを新設せず、長年使ってきた画面を人と同じように操作できる点は魅力です。しかし、画面座標、表示遅延、pop-up、権限、二重登録、締め処理、取引取消など、業務システム固有の失敗は残ります。画面自動化を、レガシー刷新を永久に先送りする理由にもしないことが重要です。
この記事は、基幹・会計・受発注・保険・医療・物流等のdesktop業務をAIで自動化したい経営者、業務責任者、CIO、情シス向けです。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
公表機能と企業側に残る統制
横にスクロールして確認できます
| 公表機能 | 期待できること | 企業側の設計 |
|---|---|---|
| Managed workspace | agent実行環境を分離・管理 | image、patch、network、data持出し |
| AD identity | 既存identity・policy・audit attributionを活用 | 人とagentのID分離、最小権限、異動 |
| MCP | agent frameworkと連携 | tool、引数、認証、server、信頼境界 |
| Real-time control | live activity確認、mid-session revoke | 誰が監視し、何を見て止めるか |
| Active session pricing | 稼働時間に応じた費用 | idle、再実行、並列、失敗を含む上限 |
レガシー画面自動化で起きる6つの失敗
- 人の共有IDをagentにも使う。 誰の判断・処理か区別できません。
- 画面成功を取引成功とみなす。 backend反映、二重登録、締め、連携先を照合しません。
- 途中停止すれば安全と考える。 revoke前に行った更新は自動で戻りません。
- 正常系だけをPoCする。 timeout、pop-up、桁あふれ、重複、締め後、部分成功を試しません。
- session費だけでTCOを計算する。 監視、例外処理、再実行、照合、保守を除外します。
- 自動化で刷新課題を隠す。 undocumented logicと属人運用がさらに見えにくくなります。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
GXO式「基幹画面AI操作5ゲート100点」
横にスクロールして確認できます
| ゲート | 配点 | 満点の証拠 | レッドフラグ |
|---|---|---|---|
| 業務・取引境界 | 20 | 起点、入力、正本、完了、例外、ownerを定義 | 手順書を読ませただけ |
| ID・環境 | 20 | agent専用ID、最小権限、network、image、secretを分離 | 人の共有IDを流用 |
| 実行・承認 | 20 | 金額、件数、時間帯、画面、更新種別、人承認を制限 | 全画面を自由操作 |
| 照合・証拠 | 25 | 入力、画面、transaction ID、backend、連携先を照合 | screenshotだけ |
| 停止・取消・復旧 | 15 | revoke、処理中断、取消、再実行、手作業を訓練 | 停止＝rollbackと誤認 |
合計点に関係なく本番移行を止める条件
- 人とagentが同じIDを共有する
- 支払、請求、在庫、契約、診療記録等を人承認なしで確定できる
- 同一要求の二重実行を防ぐidempotency keyまたは照合方法がない
- 途中停止時にどこまで更新済みか判定できない
- transaction ID、変更前後、承認、結果を取得できない
仮想記入例：仕入請求のERP登録
横にスクロールして確認できます
| ゲート | 得点 | 不足 |
|---|---|---|
| 業務・取引境界 | 15/20 | 税区分例外と月次締め後の扱いが未定 |
| ID・環境 | 11/20 | 経理共有IDをagentへ付与 |
| 実行・承認 | 12/20 | 100万円超も同じflow |
| 照合・証拠 | 9/25 | 完了画面だけで仕訳連携を未確認 |
| 停止・取消・復旧 | 6/15 | revoke後の部分登録を判定できない |
| 合計 | 53/100 | 下書き登録と照合へ限定 |
agent専用IDを作り、支払確定権限を外します。請求書IDを重複防止keyにし、ERP伝票番号、会計仕訳、承認状態まで照合します。100万円超、税区分例外、締め後処理は人へ戻します。
最小transaction証跡
横にスクロールして確認できます
| 項目 | 記録内容 |
|---|---|
| Request ID | 元申請・document・eventと一意に対応 |
| Agent／User | agent ID、依頼者、承認者、operator |
| Session | 開始・終了、workspace、image、model、workflow版 |
| Input | 入力値、source、validation、機密区分 |
| Action | 画面、field、変更前後、時刻、結果 |
| Transaction | ERP／CRM等の確定ID、連携先、状態 |
| Approval | 閾値、承認者、承認時刻、差戻し |
| Recovery | revoke、取消、再実行、手作業、完了確認 |
ベンダー・開発会社へ確認する12問
- agent専用AD identityと人のIDを分離できるか
- 画面・機能・時間帯・金額・件数で権限を絞れるか
- local drive、clipboard、download、networkを制限できるか
- MCP tool forwardingとcomputer useの使い分けは何か
- 実行中の画面・操作を誰が監視し、何秒でrevokeできるか
- revoke時点までの変更をどう特定するか
- 二重実行・部分成功・timeoutをどう検知するか
- backendのtransaction完了をどう照合するか
- model、画面、workflow、application変更時に何を再試験するか
- session時間、並列数、再実行、idleの費用上限は何か
- system停止時の手作業と復旧目標は何か
- 12〜24か月後にAPI化・刷新すべき部分をどう判断するか
90日で本番可否を決める
- 第1〜2週：1業務のtransaction、例外、権限、正本、完了条件を定義
- 第3〜4週：read／draftだけで画面変化、遅延、失敗、費用を測定
- 第2か月：限定更新、人承認、backend照合、二重実行防止を試験
- 第3か月：revoke、部分成功、取消、manual fallbackを訓練し継続判断
GXOのPoC本番化診断では、AI操作の正確性だけでなく、権限、照合、復旧、費用を判定します。現行業務・レガシー資産の整理と刷新判断はシステム開発セカンドオピニオン、AI導入対象の選定はAI導入可否アセスメントへ接続します。
FAQ
APIがなくてもAIで自動化できますか
画面操作で可能な業務はあります。ただし、transaction照合、画面変更への保守、速度、費用、例外処理を含めてAPI連携と比較します。
sessionを途中でrevokeすれば誤更新も戻りますか
revokeは以後のaccessを止める機能です。すでに行った更新の取消・補正・照合は業務system側で設計します。
画面自動化とレガシー刷新はどちらを選ぶべきですか
短期の省力化に画面自動化を使いつつ、変更頻度、例外、保守費、重要度が高い部分はAPI化・段階刷新を比較します。
出典・確認日
- AWS「Amazon WorkSpaces for AI agents general availability」（2026年6月30日発表、7月14日確認）
- AIコード解析後のレガシー刷新100点監査
機能、対応region、価格、identity、MCP、application互換性は変更される可能性があります。本記事の配点と仮想例はGXO独自であり、AWSの評価・保証ではありません。
