はじめに
2025年1月にOpenAI Operatorが米国限定で公開され、OpenAI初のAIエージェントとして注目されました。その後、2月には日本でも解禁され、楽天や食べログを自動操作する機能が話題になりました。
そのOperatorとは一体どんなものなのでしょうか。
OpenAI Operatorは、CUA（Computer-Using Agent）というエージェントモデルを採用しており、GPT-4o Visionの視覚認識能力で画面状況を把握し、CoT（Chain-of-Thought）という推論能力で次の操作を決定するというプロセスを繰り返すことで、自律的にブラウザを操作しつつ目的達成を行います。
詳しくは、OpenAI CUA公式ページを参照頂ければと思いますが、簡単に言うと「人が画面を見て次にすべき事を考えて操作をする」という事を代わりにやってくれる機能です。
この機能は、Webブラウザ上のHTMLやDOM構造にはアクセスせず、あくまで画面(スクリーンショット)を視認して操作判断するということから、今後はブラウザ画面に限らずパソコン画面やスマホ・タブレット画面等もすべて自動操作対象になることが見込まれます。
当社もWeb自動化サービスを提供する事業者として、この革新的な機能に注目してきました。Operator公開当日から色々と触ってみたり、その挙動からCUAの仕組み、活用方法等を調査・検討してきました。
このOperatorを実現するCUAモデルは近日中にAPI提供される事も予告されていました。
そして、とうとう本日OpenAIからAgent構築プラットフォームとしてResponses APIとAgent SDKが公開されました。
公開されたResponses APIの機能は下記の３点です。
- Web search
- File search
- Computer use
このうち、「Computer use」がOperatorを構成するベースモデルとなります。
つまり、このComputer useを組み込んだ独自のエージェントを構築する事で当社サービス「クラウドBOT」にOperator機能を実装する事が可能となります。
そこで、早速開発に着手するとともに、今回の実装方式についてとりまとめ記事として公開する事としました。
また、今回開発するOperator機能はプレビュー版として無料提供を予定しておりますので、興味のある方は是非先行受付にお申し込み下さい。
開発の目的
RPAとOperatorを組み合わせる意味は？
Operatorが自然言語による指示通りに自動的にブラウザを操作して目的を達成してくれるなら、それはもうOperatorだけで十分だと考えるかもしれません。
もしそうであれば、OperatorはクラウドBOTにとって脅威と言えるでしょう。
しかし、実際に公開されているOperatorのベンチマーク結果を見ると、Operatorが最も得意とするWebVoyager(Webサイト上でのタスク成功率)で87%となっています。
プライベートな用事を依頼するのであれば９割程の成功率でも１割の失敗に対して再度指示をし直したり手動操作をしたりする事で活用できるかもしれません。
しかし、業務自動化用のBOTとして１割失敗するというのは致命的です。
基本的に業務オペレーションはマニュアル化された手順に従って、決まった画面で決まった操作をする必要があります。
その中で1%未満の例外をどのように処理するかが、自動化効率に大きく影響します。
そういう意味では、業務オペレーションを全てOperatorに委ねるという方法は適切とは言えません。
例えば、Operatorの主な活用方法として紹介されている航空券や電車のチケット購入、レストラン予約の場合はAIができるだけ目的達成を試みて、難しかったら諦めてユーザに操作を委ねるという使い方になります。
ところが、業務オペレーションを任せる場合、そう簡単では無いという事が分かります。
Operatorは一操作毎に細かな指示をしなくても、何をして欲しいかという目的を伝えると「目的」「画面状況」「操作履歴」から、もっともそれらしい操作を推論し順次操作を進めてくれます。細かい手順をすべて説明しなくてもよいというのがOperatorの最大のメリットと言えます。
しかし、業務システムのオペレーションにおいては「なんとなく、それらしい操作を試してみる」という事を許されないケースが往々にしてあります。
適宜、自己判断するよりマニュアルに忠実な操作を求められる事が多いのです。
もし、マニュアル通りに確実に操作をするように一手順ごとの操作を記したプロンプトを作ればある程度正確な操作をしてくれるかもしれません。しかし、それではOperatorを利用する意味がありません。
検討の余地の無い定型操作をAIに推論させながら実行するのはAIの無駄遣いである上に、プロンプト作成コストが跳ね上がる事にもなります。
近いうちに、マニュアルPDFをOperatorに渡すだけでその通り操作してくれるとか、AIに口頭説明しながら実践操作をしてみせる事で操作内容を学習してくれるような機能も実装される可能性があります。
しかし、当面の間は「手順に忠実な操作が必要」というシーンでは、その手順をRPAで明確に記録する方が高速かつ確実であると言えます。
クラウドBOTの強みと限界
クラウドBOTは、クラウド上で利用可能なRPAサービスであり、ノーコードでBOTを作成しブラウザを自動操作できます。専用のアプリやプラグインのインストールが不要で、Webブラウザがあればすぐに利用できます。
主な特徴としては、
・操作の自動記録によりBOTを作れる（ノーコード）
・様々なBOT実行手段を提供(手動、定期実行、API、メール受信、HTTP等)
・複数メンバーで共同管理できる
・各種iPaaSやkintone等の外部連携機能を提供
これらの機能を活用し、導入後すぐにブラウザ操作を自動化できます。
しかし、RPAである以上はすべての操作手順を事前に定義しておく必要があり、予期しないポップアップやボタンの配置変更が発生すると異常停止します。
Operatorがもたらす革新性
Operatorは、冒頭に述べた通り「画面を視覚的に認識→次の操作を推論→操作を実施」を繰り返しながら目的達成を目指します。
目的を達成する為にはどこをクリックして、何を入力して、どのページへ遷移すればいいか等、ユーザーの意図を汲みながら適切なアクションを推論・操作します。
プライベートであればチケット購入やレストラン予約等が挙げられますが、業務においては名刺登録、在庫引き当て、請求書発行、備品調達などを自然言語で指示しOperatorに業務を委託するといったイメージです。
つまり、画面状況を把握し、次の操作を考え、誤った操作があれば戻して再試行するなど、人間の操作に近いプロセスで自律的に画面を操作します。
今後、Operatorの精度は急速に向上する事が予想されており、そうすると今まで人にしかできなかった業務がOperatorへ移行される事になるでしょう。
組み合わせるメリット
上記で述べた通り、クラウドBOTのRPA機能とOperatorのエージェント機能を組み合わせることで、
- 定型化可能な操作はクラウドBOTで高速かつ安定的に実行
- 定型化が難しい操作はOperatorがAIエージェントとして自律的に自動操作
というハイブリッドな自動化の実現を目指します。
例えば、クラウドBOTがルーチン作業を自動化しつつ、Operatorが例外処理や臨機応変な判断を担うことで、カスタマーサポートの自動応答や、経理業務における仕分け処理など、幅広い業務をこなすことが可能になります。
システムアーキテクチャと実装方式
クラウドBOTの構造
クラウドBOTの構成は下図の通りです。
・クライアントPCのブラウザで画面操作をする事でクラウド上にBOTを作成
・BOTはクラウド上に自動操作用の仮想ブラウザを起動
・BOTに定義された手順に従い仮想ブラウザを自動操作
この図は利用者のクライアントがBOTを作成し、実行状況を閲覧しながら手動実行している構成ですが、既存BOTの実行時はクライアントがなくても、スケジュール実行、API実行、メール受信、HTTPリクエストなどの様々な実行手段で実行することができます。
OperatorのCUAモデル構造
Operatorの基盤となっているCUAモデル(Computer-using Agent Model)の構造は、公式サイトでは下図のように示されています。
これだけを見ると無限ループになっているように見えるので、下図のように処理の流れを整理してみました。
画像の番号に沿って流れを説明します。
(1)自動操作をしたいコンピュータの環境情報とプロンプトをCUAモデルに引き渡します。
(2)CUAモデルはプロンプトの目的を達成する為にスクショ画像を見て、必要な操作を推論し、結果として「X,Y座標をクリック」等のアクション指示を出力します。
初回の推論でスクショ画像が無い場合は、アクション指示としてスクショ取得指示が出力されます。
(3)出力結果のアクション指示（マウス操作、キー入力等）に従いブラウザを制御しアクションを実行します。
(4)操作後画面のスクショを取ります。
(5)操作後画面のスクショをCUAモデルに引き渡し、次の推論を依頼します。
この(2)〜(5)のプロセスをぐるぐる回す事で連続的な操作を行います。
また、推論時には最新の画面だけではなく過去の画面や操作履歴も含めて推論するため、例えば「前の画面に戻った方が良い」「既に試したが違っていた操作を回避する」といった事が可能になります。
推論結果の出力情報に新たなアクション指示があれば(2)〜(5)を繰り返しますが、アクション指示が無い場合は「タスク完了」や「タスク中断」として(6)操作終了となります。
(6)出力結果を元に成功したのか中断したのかを判断します。
この流れの詳細なサンプルコードは公式サイトをご確認下さい。
クラウドBOTからCUAモデルを呼び出す場合
上記のCUAモデルの構成図のブラウザ環境をクラウドBOTの仮想ブラウザと繋ぎこみます。
ただ、仮想ブラウザの制御権は全てBOTがつかんでいるため、仮想ブラウザに対してアクションを実行する場合はBOTの制御部を通して実行する事になります。
つまり、クラウドBOTとCUAモデルをつなぐ場合の構成は下図のようになります。
(1)BOTのワークフローで「Operator」というタスクが実行された場合、そのタスクのプロンプトや仮想ブラウザの環境情報を入力情報としてCUAモデルに引き渡し推論を実行します。この後、CUAモデルの繰り返し操作が完了または中断するまではBOT側は次のタスクに進まず待機します。
(2)CUAモデルはプロンプトの目的を達成する為にスクショ画像を見て、必要な操作を推論し、結果として「X,Y座標をクリック」等のアクション指示を出力します。
初回の推論でスクショ画像が無い場合は、アクション指示としてスクショ取得指示が出力されます。
(3)出力結果のアクション指示（マウス操作、キー入力等）に従いブラウザを制御する必要がありますが、仮想ブラウザを直接制御する事はできないので仮想ブラウザの制御権をつかんでいるBOT制御部にアクションの実行を依頼します。
(4)アクション実行完了後、画面のスクショ取得もBOT制御に依頼しスクショ画像を取得します。
(5)操作後のスクショ画像をCUAモデルに引き渡し、次の推論を依頼します。
この(2)〜(5)のプロセスをぐるぐる回し、次のアクション指示が無くなった場合、「タスク完了」や「タスク中断」として(6)操作終了となります。
(6)出力結果をBOTのOperatorタスクの実行結果として処理し、ワークフローの次のタスクを継続実行します。
これにより、目的のWebアプリ上でログインする所まではRPAの通常タスクで実行、ログイン後はOperatorにログイン後画面を引き渡し継続操作、Operatorのタスクが完了したらRPAの通常タスクでログアウト操作をするといったハイブリッドな自動操作が可能となります。
OperatorをBOT化することでBOTの連携機能を活用
Operator機能を内包したBOTは、BOTの下記機能をそのまま利用できます。
- 作成したBOTはAPIとして呼び出す事ができます
- BOT実行結果をWebhookとして通知する事ができます
- BOTを各種iPaaS（Make、Zapier、IFTTT、Power Automate、Workato、Yoom）のトリガー/アクションとして利用できます
- kintoneプラグインによりkintoneアプリからBOT実行ができます
- メール受信をトリガーとしてBOTを実行できます
- Cloud BOT Agentを利用すると社内ネットワークへのアクセスも可能になります
まとめ
CUAモデルの公開に伴い、即日RPA×AIエージェントの開発実装に着手しました。Operator機能は今後様々な活用方法が想定されますが、RPAと組み合わせて活用する事例としてご紹介しました。
きっと、他のRPAベンダーやiPaaSベンダー等もAIエージェント機能を自社サービスに取り込むべく研究・開発を進めている事でしょう。
Operatorの登場は、RPAの存在意義や価値観自体をくつがえす可能性をも秘めていると思います。
自社サービス「クラウドBOT」が提供している価値は何なのか、生成AIやAIエージェントが発展していく事によってどのような機能や役割がAIに代替されていくのか、それらを見極めながらも便利なものは積極的に取り入れていく。
それが新たな自社サービスの価値に繋がっていくと考えています。
無料体験の先行受付について
現在開発中のクラウドBOT×Operatorは完成次第、無料公開を予定しています。
この無料体験は、クラウドBOTとOperatorの組み合わせによる業務自動化の可能性を実際に体験していただくことを目的としています。特に、RPAとAIエージェントの連携に興味のある企業や開発者の方に最適な機会となります。
負荷状況や利用状況等を見ながら、お申込み順で順次機能開放を予定しています。ご興味のある方は、ぜひこちらのページよりお申し込みください。