APIのない業務画面をAIエージェントに操作させる 検証から本番移行まで

この記事の対象読者

API連携できない業務画面を自動化したい企業や、ブラウザ操作AIの導入条件を整理したい実務者を対象にしています。

• API連携できない業務画面を自動化したい企業
• RPAの運用負担を減らしたい企業
• AIエージェントの安全な検証方法を探す企業
• 定型入力や申請業務を効率化したい企業
• ブラウザ操作AIの導入条件を整理したい企業

APIなし画面でできる操作

Computer Useの考え方

海外では、画面を見て次の操作を選ぶComputer Useが議論されています。BinxAIが現場で見る限り、APIの有無よりも、AIに許可する画面上の行動を細かく区切れるかが判断材料でしょう。

Mastraは、AIエージェントを構築・実行する開発プラットフォームとして公式情報を公開しています。Sandbox Computer Useは、古い基幹画面や取引先ポータルを対象にした実験手段として扱うと整理しやすいでしょう。

• 指定したURLを開き、対象画面まで移動する
• 画面上の指定欄へ、検証用データを入力する
• 検索結果や受付番号を読み取り、画面を保存する
• 画面状態に応じて、次の入力画面を選ぶ
• 送信前に処理内容をまとめ、人間の承認を待つ

RPAとの使い分け

定型的で画面構造が安定した処理は、従来型RPAのほうが扱いやすい場合があります。画面の状態に応じて次の手順を変える処理では、AIエージェントとの使い分けを検討する価値があるでしょう。

今すぐ問い合わせる

検証環境と許可範囲

検証では、本番アカウントと本番データを使わない構成を先に作ります。 画面操作は入力ミスだけでなく、誤クリックによる送信や削除にもつながるためです。

• テスト用アカウントでログインできる環境
• 本番と分離したサンドボックスまたは検証用テナント
• 顧客名や金額を置き換えたダミーデータ
• 操作を許可するURLと画面のリスト
• 送信や削除を禁止した初期設定

許可リストには、サイト名だけでなくURL、画面名、操作対象、入力可能な項目を記録します。取引先ポータルのように画面が複数ある場合は、申請入力画面と管理者画面を分けて登録します。

environment: sandbox
allowed_urls:
  - https://test.example.local/application
allowed_actions:
  - open_page
  - fill_form
  - read_result
  - save_screenshot
blocked_actions:
  - submit
  - delete
  - change_permission
approval_required:
  - submit
  - order

この設定は実際の製品設定を示すものではなく、検証前に整理する項目の例です。Mastraなどの実装に合わせて、許可リストと承認処理をアプリケーション側で設計します。

画面操作の検証手順

最初の対象を絞る

最初の対象は、定型入力と結果確認が中心の業務に絞ります。発注や送信まで一気に任せず、読み取りと入力の正しさを段階的に確認するのが基本方針です。

• 1. 業務を1画面または1申請に限定し、開始条件と完了条件を書く
• 2. テスト用アカウントで対象URLを開き、画面の状態を記録する
• 3. AIに入力欄、入力値、保存する結果を操作単位で指示する
• 4. 送信直前で停止させ、画面内容と入力値を人間が確認する
• 5. 操作ログとスクリーンショットを確認し、失敗時の戻し方を試す

指示には、画面上の対象だけでなく、操作してはいけない範囲も含めます。「金額欄を読み取る」だけでなく、「金額欄を変更しない」「送信ボタンを押さない」と書くと、検証時の確認点が明確になるでしょう。

• 認識する対象、例：請求番号、金額、申請者名
• 実行する操作、例：入力、読み取り、スクリーンショット保存
• 承認が必要な操作、例：送信、発注、確定
• 停止する状態、例：画面変更、ポップアップ、ログイン切れ
• 記録する情報、例：URL、入力値、結果、承認者

承認画面には、操作対象、入力値、実行後に起きることを表示します。承認者が元画面を開き直さなくても判断できる情報量にし、承認しない場合は処理を破棄できるようにしておくのが基本です。

停止条件と復旧手順

止まる条件を先に決める

AIに任せる範囲は、成功時の処理だけでなく、失敗時に止まる条件まで含めて決めましょう。 画面レイアウトの変更やログイン状態の失効は、処理を続けるより停止したほうが原因を追いやすくなるでしょう。

• 指定したURLと異なる画面が表示された
• 入力欄やボタンの位置、名称が想定と異なる
• ログイン切れや追加認証が表示された
• 入力値と画面上の確認値が一致しない
• ポップアップ、エラー、警告が表示された

復旧手順は、停止、状態保存、担当者への通知、手動確認、再開判断の順に固定します。再開時は途中から続けず、重複登録や二重送信がないかを確認してから再実行。

本番に近づける前に、画面変更を想定した再テストを行います。ボタン名の変更、必須項目の追加、セッション切れを再現できると、停止条件の抜けを見つけやすくなります。

今すぐ無料相談する

自社検証で詰まる箇所

自社だけで進める場合、画面操作の指示を書く担当者と、業務上の完了条件を判断する担当者が分かれることがあります。担当が分かれると、入力は成功しても申請として不十分な状態を見逃すかもしれません。

• テスト環境がなく、本番データを使いたくなる
• 許可リストがURL単位で止まり、操作単位まで分解できない
• 停止後に誰が確認し、どこから復旧するか決まっていない

外部の支援を使う場合は、ツール選定だけでなく、業務の完了条件と検証範囲を先に整理できます。BinxAI株式会社のみっちゃくんでは、提案の前に現場へ入り、課題の整理と現状の診断を済ませてから要件を固めます。

見積は一式ではなく、要件を整理したうえで詳細を出す方針です。契約後に要件が動いても、決めた範囲の中で優先順位を入れ替えながら進められます。料金は公式ページと無料相談でご確認ください。

• 課題の整理と現状の診断
• 要件定義と設計
• 開発と本番環境への展開
• 運用の引き継ぎと内製化の支援
• 担当者向けの研修

APIなし画面の自動化範囲を無料相談で整理する

よくある質問

APIがない業務画面でもAIエージェントは使えますか？

ブラウザを通じた画面操作を検証する選択肢があります。ただし、ログイン、画面変更、入力ミスに備え、最初はサンドボックスとダミーデータに限定することをおすすめしたいところです。

RPAとComputer Useはどう使い分けますか？

画面構造が安定し、手順が固定された処理はRPAに向く場合があります。画面状態を読み取り、分岐しながら次の操作を選ぶ処理はComputer Use型を検討するとよいでしょう。

送信や発注もAIに最後まで任せられますか？

検証初期は任せず、実行直前で停止して人間が承認する設計にします。金額確定、発注、削除、権限変更は、取り消せるかを確認してから範囲を判断するのがおすすめです。

画面が変わったときはどうしますか？

想定した欄やボタンを認識できない状態を停止条件にします。停止時のスクリーンショットとURLを残し、画面を確認してから許可リストや指示を更新しましょう。

Mastraは業務画面をそのまま操作する製品ですか？

Mastraは公式情報で、AIエージェントを構築・実行する開発プラットフォームと説明されています。業務画面の操作では、対象環境、ブラウザ操作、承認、ログ、復旧を別途設計する必要があります。

APIのない画面をAIに操作させるときは、ツール名から始めず、許可する行動から設計します。まずはテスト用アカウントで1画面を対象にし、送信前の承認、停止条件、ログ、復旧を確認してから範囲を広げてください。