画面操作型AIエージェントを試して見えた可能性と、実用化までの壁
生成AIは、旅行先を提案するだけの存在ではなくなりつつある。出発地、目的地、日程、人数、希望条件を伝えると、交通手段を調べ、ホテルを比較し、予約サイトへ入力し、最後に行程をまとめる。人間の画面操作まで引き受ける、画面操作型AIエージェントの実験が始まっている。
「明日、横浜から福岡へ1泊で行きたい」とスマートフォンから送る。AIは地図で移動の成立性を確かめ、交通・宿泊を探し、クラウド上のブラウザで候補を絞り、予約確定の直前で人間へ戻す。
これは便利な旅行デモに見える。だが本当の論点は、AIが人間向けの画面を使って、複数の既存システムをまたぐ業務を進められることにある。企業に残るAPIのない画面業務にも、同じ構造を適用できる可能性がある。
一方で、画面を操作できることは、自由に操作してよいことを意味しない。認証情報、個人情報、利用規約、CAPTCHA、決済、二重実行、操作ログをどう扱うかが、実用化の中心になる。
AIが「提案」から「実行」へ進む
従来の旅行AIは、交通やホテルの候補、概算予算、観光地を文章で返すことが中心だった。その後、利用者は予約サイトを開き、同じ出発地、日付、人数を何度も入力する必要があった。
画面操作型AIエージェントは、この分断を埋める。
スマートフォンから自然言語で依頼
↓
AIが条件を解釈し、旅行全体の計画をつくる
↓
専用のクラウドPC上でブラウザを操作
↓
地図・交通・宿泊・観光の候補を調べて入力を進める
↓
高リスクな地点で人間へ確認を依頼
↓
旅程と、確認すべき予約内容を利用者へ返す
スマートフォンは、処理を実行する端末ではなく、指示と結果をやり取りする窓口になる。実際のブラウザ操作は、クラウド上に用意した専用環境で行う。
Windows 365のようなCloud PCは、Windowsのデスクトップ、アプリ、設定、コンテンツをクラウドから配信する仕組みとして提供されている。Windows 365の公式FAQ こうした環境は、エージェントに日常利用のPCを直接渡さず、実行環境を分ける選択肢になる。
APIがない画面も扱える。ただし、APIの代わりではない
システム連携の第一選択は、今もAPIである。APIは入出力が構造化され、処理が速く、エラー処理・認可・監査を組み立てやすい。大量処理や基幹連携で、画面操作をAPIより優先すべき理由はない。
それでも、全てのサービスが必要なAPIを公開しているわけではない。
- 予約まで実行できるAPIがない
- 利用条件が限定されている、または高コストである
- 社内の古いWebシステムやデスクトップアプリにAPIがない
- 個人固有の画面上の手順を経由する必要がある
- API整備・システム刷新まで時間がかかる
画面操作型エージェントは、人間が見て操作できる画面を使う。画面上の文字、ボタン、入力欄、操作結果を認識し、マウスやキーボードに相当する操作を行う。だから、APIのないシステムにも接続できる可能性がある。
ただし、画面操作は長期的な正式連携を不要にする魔法ではない。画面変更、認証、ポップアップ、遅い画面遷移、利用規約に影響される。短期的な業務改善、API整備までの橋渡し、例外的な手順の支援として使い、安定した大量連携はAPIへ寄せる。この使い分けが現実的だ。
一文から予約直前まで、何を進めるのか
旅行予約のデモでは、AIは最初から最安値の検索を始めない。旅行が成立するかを確認し、条件に沿って段階的に進める。
1. 自然言語の依頼を、制約へ分解する
「明日、横浜から福岡へ1泊で行きたい」という一文には、出発地、到着地、日程、宿泊数が含まれる。さらに、利用者が持つ制約を組み合わせる。
- 朝8時より前には出発できない
- 予算は上限以内にしたい
- 乗り換えを減らしたい
- 禁煙、朝食付き、駅から徒歩圏内がよい
- ポイントサイトを経由したい
- 予約確定は必ず自分で確認したい
従来のフォームでは別々に入力する情報を、AIは依頼文と利用者設定から抽出する。ただし、推測で補う項目と、確認が必要な項目を分ける必要がある。出発空港や予算が曖昧なら、勝手に確定せず質問を返す方が安全だ。
2. 地図で、旅程そのものが成立するかを見る
目的地までの距離、移動時間、接続、到着後の導線を地図で確認する。しまなみ海道を自転車で渡る旅行のように、単一の交通検索では成り立たない旅程では特に重要だ。
AIがここで考えるべきなのは、「予約できるか」より先に「この日程で現実に移動できるか」だ。途中宿泊が必要か、最終便に間に合うか、到着時刻にホテルへ入れるかを確かめる。利用者の目的に合う計画をつくるには、個別予約の最適化だけでは足りない。
3. 交通・宿泊を探し、入力を進める
条件が固まったら、航空会社、鉄道、宿泊予約サイトなどを開き、必要な情報を入力する。ポイントサイトを経由する、会員サイトへログインする、複数候補を比較する、といった利用者固有の手順も扱える可能性がある。
ここで重要なのは、AIが一つの画面を自動入力するだけではないことだ。画面遷移、検索結果、ログイン状態、前後の選択を踏まえながら、複数サービスをまたいで作業を進める。
4. 不可逆な操作の手前で、人間へ渡す
予約の確定、決済、利用規約への同意、個人情報の最終送信は、AIが止まるべき地点である。
AI：候補の検索・比較・入力
↓
人間：金額・条件・個人情報・規約を確認
↓
人間の明示承認後にだけ、確定操作を実行
この設計なら、AIは面倒な検索・転記・比較を引き受け、人間は責任を伴う判断へ集中できる。
「スキル」は、操作手順ではなく業務ルールとして書く
画面操作型AIは、目的と制約を記した自然言語のスキルを参照して動く。旅行予約なら、スキルには次のような内容を置ける。
- 最初に地図で移動可能性を確認する
- 指定時刻より早い便を選ばない
- 宿泊予約は指定されたポイントサイトを経由する
- CAPTCHAが表示されたら停止する
- 確定前に、金額・取消条件・個人情報を利用者へ示す
- 最後に、交通・宿泊・観光を一つの行程へまとめる
従来のRPAは、特定のボタンや座標を順に操作する定義へ寄りやすい。画面操作型AIでは、より抽象的な目的とルールを与え、状況に応じて具体的な操作を選ばせられる。
ただし、自然言語のスキルを渡せば運用できるわけではない。スキルには、正式な業務ルール、例外条件、禁止操作、エスカレーション先、根拠文書の版を含める必要がある。熟練者の癖や古い回避策を、そのまま自動化してはいけない。
RPAとAIエージェントは、得意な場所が異なる
| 観点 | 従来型RPA | 画面操作型AIエージェント |
|---|---|---|
| 指示方法 | 詳細な操作手順 | 目的・条件・ルール |
| 判断 | 定義済みの分岐が中心 | 文脈を踏まえた候補選定 |
| 画面変更 | 影響を受けやすい | 対応できる可能性はあるが保証されない |
| 再現性 | 高めやすい | 確率的な揺らぎを前提にする |
| 向く業務 | 安定した定型処理 | 半定型の探索・比較・転記 |
| 重要な統制 | 手順・例外処理 | 権限・観測・承認・復旧 |
RPAは、決められた処理を高速かつ正確に繰り返すことが得意だ。画面操作型AIは、情報を読み、状況に応じて次の操作を考えることが得意である。両者は競合するものではない。AIが候補を選び、確定した定型操作はRPAやAPIで実行する、といった組み合わせも考えられる。
長時間処理では、止まることと再開できることが重要になる
複数サイトをまたぐ予約は、人間でも時間がかかる。講演で紹介されたデモでも、予約全体には約1時間を要したという。この時間は講演紹介値であり、サイト、認証、候補数、ネットワークによって大きく変わる。
画面操作では、ページ読み込み、画面認識、候補比較、ログイン、エラー復旧が積み重なる。価値は「数分で終わること」ではなく、その間に利用者が画面へ張り付かなくてよいことにある。
長時間の処理では、次の設計が不可欠になる。
- 実行計画と現在の処理状態を保存する
- 画面遷移ごとにチェックポイントを残す
- タイムアウト、リトライ、待機上限を設ける
- セッション切れやサイト障害を検出する
- 人間へ引き継ぐ画面と、再開条件を明確にする
- 予約番号や会員ページを確認し、二重予約を防ぐ
- 途中で止める緊急停止と、後始末の手順を持つ
「最後まで自動完走する」ことよりも、想定外で安全に停止し、正しい地点から再開できることが、実運用では重要になる。
CAPTCHAは、突破すべき障害ではなく引き継ぎ地点である
CAPTCHAは、人間と自動化プログラムを区別する目的で使われる仕組みである。W3Cも、CAPTCHAを人間かソフトウェアロボットかを見分けるためのテストとして説明している。W3CのCAPTCHA解説
エージェントがCAPTCHAを検出したら、勝手に突破を試みるのではなく、処理を停止して利用者へ引き継ぐ。多要素認証、本人確認、規約同意、高額な決済、返金できない予約も同じである。
適切に止まれることは、エージェントの失敗ではない。サービス提供者のセキュリティ境界と、利用者が負う責任を尊重するための機能である。
最も危険なのは、AIに日常利用PCを渡すこと
クラウドPCに航空会社、旅行サイト、ポイントサイト、メール、決済サービスの認証情報があると、エージェントは多くの操作を行える。便利さと引き換えに、誤操作や侵害時の影響範囲も大きくなる。
画面を読むAIは、悪意あるページ上の文章を命令として誤解するプロンプトインジェクションにもさらされる。商品ページや検索結果に埋め込まれた文が、保存済み情報の入力や不要な購入を促す可能性がある。
対策は、AIに「悪い指示を無視して」と頼むことではない。AI専用環境を作り、権限と到達可能な操作を外側で狭めることだ。
最小権限の実行環境をつくる
旅行予約用のエージェント環境なら、普段使いのPCや社内PCとは分ける。
| 許可するもの | 許可しないもの |
|---|---|
| 承認した旅行・地図サービス | 社内システム、管理者画面 |
| 旅行専用のメールアカウント | 個人クラウドストレージ |
| 利用目的に必要な決済手段 | 金融機関・投資サービス |
| 限定したダウンロード先 | 開発環境、機密文書 |
さらに、URL許可リスト、ダウンロード・クリップボード・ファイル転送の制限、支出上限、操作時間制限、画面録画、緊急停止を組み合わせる。認証情報も、プロンプトへ書き込まず、認証基盤やパスワードマネージャーが管理する。
画面操作の記録は、運用と監査の土台になる
実務利用では、後から「何が起きたか」を追えなければならない。最低限、次を記録する。
- 利用者の依頼と、AIが解釈した条件
- 参照したスキル、マニュアル、データ源
- アクセスしたサイトと、実行した操作
- 入力した項目、候補比較、選定理由
- 人間へ承認を求めた内容と、承認結果
- 予約番号、決済・送信結果、エラー、再試行
画面録画やスクリーンショットは調査に役立つが、個人情報や決済情報を含みうる。保存前のマスキング、暗号化、アクセス制御、保存期間、削除手順を先に決める。ログを取ること自体が新しい漏えい経路にならないようにする。
企業導入は、五段階で進める
画面操作型AIを、いきなり本番の基幹業務へ入れてはいけない。権限と影響を少しずつ広げる。
- 閲覧と提案：AIは画面を読み、次の操作を提案する。人間が操作する。
- 入力するが確定しない：AIが転記・入力を行い、人間が内容を確認して保存する。
- 低リスク業務の自動実行：検証環境や取り消し可能な定型処理だけを自動化する。
- 承認付きの本番操作：AIが処理を進め、送信・保存・予約の直前で承認を求める。
- 条件付きの自律実行：実績があり、上限・対象・復旧方法が明確な業務だけを自律化する。
旅行予約であれば、候補検索や経路比較はAI、CAPTCHAと規約同意は人間、予約確定と決済は人間の明示承認後に限定する、といった分担が現実的だ。
AI時代のUIは、人間だけのものではなくなる
画面操作型AIが広がると、UIを使う主体にAIが加わる。これは「AIが読める画面だけを作る」ことを意味しない。むしろ、人間にも支援技術にも理解しやすいUIを整えることが、エージェントの安全性にも効く。
- 目的が分かるラベルと一貫した用語
- 明確な入力項目、エラー、完了状態
- 確定操作と取消操作の明確な区別
- 適切なHTML構造とアクセシビリティ情報
- APIや構造化された代替経路の提供
- 自動化の可否を示す利用規約と技術的な境界
画面操作型AIは、APIの不在を補う手段になり得る。しかし、長期的には、機械にも人間にも分かる構造化された連携を用意する方が、速く、安全で、監査しやすい。
結論：一文で旅行を進める未来は、統制設計とセットで実用になる
スマートフォンから旅行条件を一文で送り、AIが地図、交通、宿泊、観光を調べ、予約直前まで進める。この体験は、すでに完全な空想ではない。
一方で、画面変更、長時間処理、認証、CAPTCHA、二重予約、個人情報、プロンプトインジェクション、利用規約という壁がある。実用化の鍵は、AIへPCを丸ごと渡すことではない。
- 専用の実行環境を用意する
- 最小権限とアクセス先の制限を設ける
- 不可逆・高リスクな操作で人間へ戻す
- 操作ログ、再開、停止、二重実行防止を実装する
- サービスごとの利用規約と自動化可否を確認する
旅行予約は、画面操作型AIの可能性を最も分かりやすく見せる題材だ。その先には、APIがなく、人間がマニュアルを見ながら画面を操作している企業業務がある。
AIが業務を進める未来は、画面を操作できることだけでは実現しない。どこまで任せ、どこで止め、何を記録し、誰が責任を持つか。その設計があって初めて、AIは既存システムと新しい働き方を安全につなげられる。
作成日：2026年7月25日