#14 ScreenPlayとは?UiPathの新機能をTISエンジニアが検証・解説
公開日:2026年5月
近年、生成AIは急速に進化し、ニュースやビジネスシーンで目にする機会も増えています。皆さんも、仕事に限らず日常生活においても、困ったときにChatGPTなどの生成AIに相談することが習慣化されているのではないでしょうか。こうした生成AIの進化は、RPAの世界にも新しい変化をもたらしています。その中でも注目を集めているのが、UiPathから新たに登場した「ScreenPlay」です。
ScreenPlayは、LLM(大規模言語モデル)と画像認識・DOM解析を組み合わせた、次世代の自律型UI操作アクティビティです。従来のアクティビティとは異なり、自然言語によるプロンプトで画面操作を指示できる点が大きな特徴です。
今回のコラムでは、このScreenPlayについて実際にTIS社内で検証を行った結果をもとに、その仕組みや特長、そして導入時のポイントについて、エンジニアの視点から解説します。
目次
1.ScreenPlayとは?その仕組みについて解説
ScreenPlayは、UiPathが提供する新しいUI操作のためのアクティビティです。最大の特徴は、LLMと画像認識・DOM解析(※1)を組み合わせている点にあります。
従来のRPA開発では、開発者が画面上のセレクターを指定し、クリックや入力といった動作を一つ一つ厳密に定義する必要がありました。しかし、ScreenPlayでは、画面操作と「プロンプトによる指示」を組み合わせることでアクティビティを作成します。
またインターフェースも一目で分かりやすい設計となっています。実際にScreenPlayアクティビティを起動した際の画面イメージは以下の図をご確認ください。
※1 DOM解析:Document Object Model解析、HTMLの構造をツリー形式で解析し、UI要素の位置や属性を特定する技術。
ScreenPlayの主なメリットとして、以下の3点が考えられます。
自然言語によるUI操作
従来のRPA開発では、クリックするボタンや入力するフィールドを「セレクター」と呼ばれる技術的な識別子で個々に指定する必要がありました。しかしScreenPlayでは、「会社名を入力・検索して、財務情報を収集して」といったような自然言語の指示(プロンプト)だけで操作を定義できます。専門的な知識がなくても、直感的に自動化の指示が出せるようになります。
参照先のUI変更への耐性の高さ
従来のRPAにおける最大の課題の一つが、システムのUI変更によるロボットの停止でした。ボタンの位置やIDが少し変わるだけで、セレクターの再設定が必要になることが多々ありました。
ScreenPlayは、LLMが人間のように画面を見て「これが検索ボタンだ」「これが入力欄だ」と判断するため、多少のレイアウト変更や属性の変更があっても、ある程度柔軟に対応し続けることができます。これにより、保守運用の負担が大幅に軽減されることが予想されます。
開発スピードの圧倒的速さ
厳密なセレクター設定や、例外処理のための複雑なロジックを組む必要がなくなるため、開発工数を劇的に削減できます。
「条件を検索して、検索結果からこの項目を取得する」といった指示を書くだけで実装が完了するため、従来の開発手法と比較して、プロトタイピングから本番運用までのリードタイムを大幅に短縮することが可能です。
2.ScreenPlayを実際に使ってみた
ここまではScreenPlayの特徴や強みをお伝えしてきましたが、「実際、どんな風に使うの?」と思われる方も多いのではないでしょうか。実際にScreenPlayを使って、簡単な自動化ワークフローを検証してみました。
今回は挙動を分かりやすく示すため、「毎月特定の会社の株価をWeb検索して取得する」例を挙げて検証します。
前提条件
ScreenPlayを利用するためには、以下の環境が必要です(2026年2月時点)。
- UiPath Studioの任意のバージョンで動作(Studio 2025.10を推奨)
- UIAutomationパッケージ 2025.10.20以上がインストールされていること
- Automation Cloudアカウントに接続されていること
- Automation Cloud上でScreenPlayが有効化され、利用可能なモデルが設定されていること
- プロジェクトの互換性が「Windows」または「クロスプラットフォーム」であること
- ScreenPlay Add-Onが有効化されていること
検証ワークフロー
今回は、Google Chromeを使用して弊社「TIS株式会社」の株価情報を取得し、その結果をメッセージボックスに表示させるワークフローを作成しました。
メッセージボックスアクティビティはScreenPlayアクティビティには含まれませんのでご注意ください。
設定内容
ScreenPlayアクティビティの設定は非常にシンプルです。
- 画面選択:Webブラウザ(Google Chrome)を選択
- モデル:Gemini 2.5 Flashを選択
- プロンプト:以下のように具体的な指示を記述しました。
TIS株式会社(TYO: 3626)の株価を取得してください。
詳細手順は以下です。
・Google検索で「TIS株式会社 株価」と検索して以下情報を取得してください。
取得会社名
前日終値
取得日
検証結果
プロンプトのみの指示で、指定通りWeb検索が行われ、必要な情報(会社名、前日終値、取得日)が抽出されることを確認しました。
※補足※ 取得日3月3日の前日終値、つまり3月2日の終値3,092円を取得しており、内容に問題がないことを確認しました。
なお、今回の検証環境では、実行ボタン押下からメッセージボックスの表示まで約1分20秒を要しました。※検証環境(回線・モデル・時間帯)に依存し、実行時間は変動します。
セレクターを一切触ることなく、自然言語の指示だけでUI操作が完結するのは、これまでの開発体験とは全く異なるものでした。
3.ScreenPlayを利用してみて
検証を通じて見えてきた、ScreenPlayの特性を「良い点」「注意点」「導入のポイント」に整理してご紹介します。
良い点
① 直感的な開発体験
プロンプトを書くだけで動作するため、専門的なセレクター知識が不要で、開発のハードルが大きく下がりました。
② 柔軟な対応力
ブラウザ検索のような、参照先の画面構成が変わっても目的の情報を見つけ出す柔軟性は、従来のRPAにはない強みだと感じました。
注意点
① 自動化対象は単一アプリケーションのみの選択を推奨
ScreenPlayは非常に強力な機能ですが、すべての業務に適用できる万能な仕組みではありません。現時点では、小さな操作単位に分割し、必要に応じて複数のScreenPlayを組み合わせる設計が推奨されます。複数のアプリケーションを行き来するような複雑な操作(例:Excelからデータを読み取って基幹システムに入力する等)をScreenPlay単体で行うには適していません。
② 実行速度とコスト
今回の検証では、即時性が求められる処理には不向きと感じられる実行時間でした。従来のRPAに慣れている方では、動作を遅く感じられるかもしれません。
また、ScreenPlay ではLLMを利用するため、従来のRPA開発と比較してLLMの利用に伴うエージェント ユニット/プラットフォーム ユニット(※2)の消費コストも考慮が必要です。
※2 消費するユニットについては以下をご参照ください。
| モデルのティア | フレックス (エージェント ユニット) | Unified Pricing (Platform Units) | 含まれるモデル |
|---|---|---|---|
| 標準モデル | 1 エージェント ユニット/実行 | 0.20 プラットフォーム ユニット/実行 | 高機能モデル (GPT-5 + DOM、GPT-4.1 + DOM など) |
| 基本モデル | 0.25 エージェント ユニット/実行 | 0.05 プラットフォーム ユニット/実行 | 軽量で高速のモデル (GPT-5 Mini + DOM、Gemini 2.5 Flash + DOM など) |
導入のポイント
① 適材適所の「ハイブリッド開発」
ScreenPlayのみで全ての業務を完結させるのではなく、それぞれの特性・強みを考慮した上で従来のアクティビティと組み合わせる「ハイブリッド開発」が現実的な解です。
従来アクティビティと組み合わせることで、今までは自動化の対象となっていなかった非定型業務と定型業務を組み合わせた業務も自動化の対象になります。
| 従来アクティビティ | ScreenPlay |
|---|---|
| 厳密な精度が求められる操作 | 人間が判断するようなUI操作 |
| セレクターの変更が予期できる・安定しているUI(更新を事前に検知できる社内システム等) | セレクターの変更が予期できない・不安定なUI(Webサイトや不定期に更新される社外システム等) |
| 複数のアプリケーションに跨った処理 | 単一のアプリケーションのみによる処理 |
| 大量データの定型処理 | 探索的なデータ収集 |
表1:従来アクティビティとScreenPlayとの特性比較
② 事前のPoCでリスクを洗い出す
LLMを利用する性質上、導入前には必ずPoCを行い、以下の観点で評価を行うことが重要です。
ハルシネーション(嘘の回答)の有無:重要な数値データなどを扱う場合、誤った情報を取得しないか。
実行速度:業務で求められる処理速度を満たせるか(今回の検証では1処理に1分以上要しましたので、従来のRPAに慣れている方からすると遅く感じられるのではないでしょうか)。
費用対効果:エージェント ユニット/プラットフォーム ユニットの消費量に見合う業務価値があるか。
③ プロンプトエンジニアリングの工夫
「詳細な手順」や「出力フォーマット」を明確に指示することで、精度は大きく向上します。
今回の検証でも、単に「株価を教えて」と聞くより、「Google検索をして」と検索エンジンを指定して、「会社名、前日終値、取得日付を取得して」と取得したい項目を明示した方が安定した結果が得られました。人間への作業指示書を作るような感覚で、具体的かつ明確なプロンプトを作成することがコツです。
④ 想定されるユースケースの選定
市場・競合情報の調査:複数のWebサイトを巡回し、特定の製品情報や価格を収集する(ScreenPlayで情報収集を行い従来アクティビティで収集結果を出力する)。
仕様変更が多く、かつAPI連携できないSaaS等の操作:頻繁にUIの配置やIDが変わるクラウドサービスやWebサイトにおいて、見た目(視覚情報)を基準に操作することでエラーを防ぐ(従来アクティビティで変数を取得し、ScreenPlayで当該SaaSに数値を入力する)。
判断を伴う一次振り分け:Web問い合わせの内容を読み取り、適切な担当部署を判断してシステムに入力する(ScreenPlayでWeb問い合わせ内容の読み取りと担当部署を判断させ、従来アクティビティでシステム入力を行う)。
4.まとめ
ScreenPlayは、プロンプトベースで直感的に自動化を実装できる画期的な機能です。市場・競合情報の調査など、非定型な情報収集業務などでの活躍が期待されます。
特に、UI変更が頻繁なWeb操作や、手順が人の判断に依存している業務を自動化したい方にとって、有効な選択肢となるでしょう。
一方で、すべての業務をScreenPlay単体で完結させるものではなく、従来のアクティビティと組み合わせた「ハイブリッド開発」によって真価を発揮するツールだと言えます。まだ登場したばかりの技術ですので、特性を充分に理解した上で、適切な業務領域に適用していくことが重要です。
さいごに
TISでは、UiPathの導入から運用後の課題解決まで、現場に寄り添ったサポートを行っています。今回ご紹介した内容以外にも、実際の現場で得られた知見が多数ございますので、ご関心があればぜひご相談ください。
※本コラムは2026年2月時点の製品情報をもとに、3月に検証を行った結果をまとめたものです。
執筆者:黒田 悠介
※本コラムはTISエンジニアの実体験・知見に基づく内容を記載していますが、記載された情報や手順が全ての環境で同様に動作することを保証するものではありません。万が一、本コラム内容を参考にしたことによる損害等が生じた場合、当社は責任を負いかねますのでご了承ください。また、記載されている情報はコラム公開時点のものであり、予告なく変更される場合があります。
※本文記載の社名・製品名・ロゴは各社の商標または登録商標です。
<TISの[RPA業務自動化ソリューション:UiPath]について確認する>
バックナンバー
RPA開発現場のリアルレポ! #13
テスト設計・管理のAI自動化を現場から徹底検証!~UiPath Test Manager & Autopilot for Testers~
RPA開発現場のリアルレポ! #12
作業の自動化から業務全体の自動化へ~UiPath Maestroの概要と便利機能のご紹介~