コンピュータユース（Computer Use）とは？AIが画面を操作して業務を自動化する仕組み

コンピュータユース（Computer Use）とは、AIエージェントが人間と同じように画面を見て、マウス操作やキーボード入力でアプリケーションを操作し、API のない業務まで自動化する技術である。従来の RPA が「決められた手順の再生」だったのに対し、コンピュータユースは画面の状況を理解して次の操作を自分で判断する点が異なる。

本記事は、タイで事業を営む B2B 企業の情報システム担当者や DX 推進担当者に向けて、仕組み・適用業務・導入手順・セキュリティ対策までを一気通貫で解説する。読み終えたときには、自社のどの業務から着手し、どこに人間の確認を残すべきかを判断できる状態を目指す。

コンピュータユースは、AI エージェントに「目（画面認識）」と「手（操作実行）」を与え、API が用意されていないシステムでも人間の代わりに操作させる仕組みだ。 まずは定義と、よく混同される RPA・API 連携型エージェントとの違いから整理する。

コンピュータユースは、スクリーンショットとして取得した画面をモデルが解釈し、「次にどこをクリックし、何を入力するか」を判断して操作を生成する。事前に座標やセレクタを固定せず、画面のレイアウトが多少変わっても目的から逆算して操作を組み立てられるのが特徴だ。

結論として、三者は「変化への強さ」と「接続方法」で住み分けられる。 従来型 RPA は座標やオブジェクト ID を記録して再生するため安定する一方、画面の変更に弱い。API 連携型のAIエージェントは、システム側が API を公開していれば最も高速・確実だが、API がなければ使えない。コンピュータユースはその隙間 — API がなく、かつ画面が変わりうる業務 — を埋める。

実務では「RPA かコンピュータユースか」の二択ではなく、API があれば API、定型で画面が安定していれば RPA、それ以外をコンピュータユースで補完する、という組み合わせが現実的だ。

注目の背景には、マルチモーダルモデルの画面理解精度が業務に耐える水準へ近づいたことがある。スクリーンショットから UI 要素を読み取り、ボタンやフォームを識別できるようになったことで、これまで API 化を諦めていた業務が自動化の射程に入った。

調査会社の予測でも、エンタープライズ領域でのエージェント活用は今後数年で急拡大すると見込まれている。Gartner は、企業向けアプリケーションのうちタスク特化型 AI エージェントを搭載する割合が、2026 年までに 5% 未満から 40% へ拡大すると予測している（出典: Gartner, 2025）。一方で、パイロットは進んでも本番稼働まで到達した企業はまだ限られるという指摘も多い。「動くデモ」から「任せられる運用」までの距離が、いま各社が直面している壁だ。

タイをはじめ ASEAN の B2B 現場では、基幹システムやサプライヤー側のポータルに API が用意されていないケースが多い。だからこそ、画面操作で隙間を埋めるコンピュータユースの実用価値が相対的に高くなる。

コンピュータユースは「画面を見る → 操作する」を高速に繰り返すループで動く。 ここでは、1 回の操作がどう生成されるかという基本フローと、タスク全体を完遂するための計画・実行・検証のサイクルに分けて説明する。

基本となる 1 サイクルは、おおむね次の流れで進む。

1. 画面取得: 現在の画面をスクリーンショットとして取り込む。
2. 状況理解: モデルが画面内のテキスト・ボタン・入力欄を読み取り、いまどの状態にあるかを把握する。
3. 操作決定: ゴールと現状の差分から、「この要素をクリックする」「この欄に入力する」といった次の一手を決める。
4. 操作実行: マウス移動・クリック・キー入力・スクロールなどの実際の操作に変換して実行する。
5. 結果確認: 操作後の画面を再取得し、意図どおり進んだかを確認する。

このループを 1 操作ごとに回すため、ボタンの位置が前回と少しずれていても、画面を見直して追従できる。一方で、1 ステップごとに画面理解が入るぶん、API を直接呼ぶ方式より時間がかかり、複雑な画面では誤クリックも起こりうる。だからこそ後述する検証と人間確認の設計が品質を左右する。

単発の操作がつながっても、それだけでは「請求書を 30 件処理する」のような複数手順のタスクは完遂できない。実務で安定させるには、上位に計画と検証のループを重ねる。

• 計画（Plan）: タスクをサブゴールに分解する。例として「ログイン → 対象一覧を開く → 1 件ずつ入力 → 保存 → 次へ」と段取りを立てる。
• 実行（Act）: サブゴールごとに前述の操作ループを回す。
• 検証（Check）: 各サブゴールの完了条件（「保存完了の表示が出たか」など）を確認し、失敗していれば再試行するか人間にエスカレーションする。

この「計画 → 実行 → 検証」を多段で設計する考え方は、複数のエージェントや手順を協調させるAIエージェント・オーケストレーションと地続きだ。また、ミスを個人の注意ではなく仕組みで防ぐ発想はハーネスエンジニアリングとも共通する。検証を省くと、途中で 1 つ操作を間違えたまま最後まで突き進み、誤ったデータを大量に登録する事故につながりやすい。

コンピュータユースが効くのは「API がない × 画面操作が定型に近い × 量が多い」業務だ。 代表的な 2 つの領域 — レガシーシステムの操作と、情報収集・レポート作成 — に分けて見ていく。

最も価値が出やすいのが、API が公開されていない社内システムや外部ポータルの操作だ。タイの B2B 現場では、長く使われてきた基幹システム、サプライヤー各社の受発注ポータル、政府機関の申請サイトなど、「画面からしか操作できない」業務が依然として多い。

たとえば、複数のサプライヤーポータルに同じ発注情報を入力する、行政ポータルで申請ステータスを毎朝確認して一覧化する、レガシー ERP に届いた請求書の内容を転記する、といった作業だ。これらは人手では単調で時間がかかり、転記ミスも起きやすい。

API 連携が可能な調達フローであれば、画面操作に頼らず API ベースで組むほうが確実だ（この領域はAIエージェントによる B2B 調達自動化で扱っている）。コンピュータユースは、その API が「どうしても用意できない相手」に対する最後の手段として位置づけると、役割が明確になる。

もう 1 つの定番が、複数のサイトやシステムをまたいで情報を集め、比較し、定型レポートにまとめる業務だ。競合価格の定点観測、複数ベンダーの在庫・納期確認、社内ダッシュボードのスクリーンショット取得と要約などが該当する。

これらは「人間が毎日同じ画面を巡回してコピー&ペーストしている」典型例で、コンピュータユースの自動化効果が見えやすい。ブラウザ操作が中心になるため、対象サイトのレイアウト変更に追従しやすい点も相性が良い。

ただし、収集したデータをそのまま意思決定に使うのは危険だ。画面の読み取り違いや古いキャッシュ表示を拾う可能性があるため、出力には「いつ・どの画面から取得したか」を必ず残し、重要な数値は人間が裏取りする運用にしておきたい。

導入は「小さく検証して、人間の確認を残したまま広げる」のが鉄則だ。 対象業務の選定、PoC から本番への進め方、人間の確認（HITL）の組み込みという 3 つのステップで進める。

最初の関門は「どの業務から始めるか」だ。次の条件を多く満たす業務ほど、初期の成功確率が高い。

• 手順がある程度決まっていて、判断の分岐が少ない
• 画面操作が中心で、API での代替が難しい
• 量がまとまっており、自動化の効果が金額換算しやすい
• 失敗しても致命的でない（金銭・契約・法対応に直結しない）

費用対効果は、対象業務の現状工数（人数 × 時間 × 頻度）と、構築・運用コストを並べて見積もる。投資判断の枠組みはAIエージェント導入後の効果測定が参考になる。

逆に、契約金額の確定や支払実行のような高リスク業務をいきなり全自動化の対象に選ぶと、事故時の損失が大きく、社内の信頼も失いやすい。最初は「単調だが間違えても取り返せる」業務を選ぶのが定石だ。

対象が決まったら、いきなり全面展開せず小さな PoC から始める。具体的には、対象業務の一部（たとえば 1 拠点・1 サプライヤー・数十件）に絞り、成功率・所要時間・人間の介入回数を計測する。

PoC で見るべきは「うまくいった回数」ではなく「失敗の起き方」だ。どの画面でつまずくか、どんな例外（ポップアップ、セッション切れ、想定外のエラー表示）で止まるかを洗い出し、本番ではそれらに備えた分岐とリトライを用意する。

PoC から本番への移行は、エージェント運用全般に共通する論点が多い。パイロットを量産化につなげる進め方はAIエージェントを本番運用に乗せるで詳しく扱っているので、あわせて参照したい。検証段階で「成功率が業務要件に届かない」と分かったら、無理に広げず対象業務を絞り直す判断も重要だ。

コンピュータユースを安全に運用する鍵は、すべてを自動化しようとしないことだ。リスクの高い操作の手前に人間の確認（HITL）を挟む設計が、事故を防ぎつつ自動化範囲を広げる現実解になる。

• 自動で進めてよい操作: 閲覧・転記・下書き保存など、取り返しがつく操作。
• 人間の承認を挟む操作: 送信・確定・支払・外部への発注など、後戻りしにくい操作。

この線引きの考え方はヒューマン・イン・ザ・ループ（HITL）で体系的に解説している。承認待ちの操作を増やしすぎると自動化のメリットが薄れるため、「どこまで任せ、どこから人を呼ぶか」をリスクと量のバランスで調整する。運用が安定してきたら、確認の閾値を少しずつ緩めて任せる範囲を広げる、という段階的な進め方が安全だ。

コンピュータユースは「人間の操作権限をそのまま AI に渡す」ため、権限設計とリスク対策を後回しにすると被害が大きい。 最小権限とサンドボックス隔離、そして誤操作・規約面の備えを押さえておく。

コンピュータユースのエージェントは、画面を操作できるアカウントの権限をそのまま使う。つまり、そのアカウントでできることはすべてエージェントにもできてしまう。したがって、エージェント専用アカウントを用意し、業務に必要な最小限の権限だけを与えるのが出発点だ。この考え方はAIエージェントの権限設計（最小権限）で詳しく扱っている。

さらに、操作の実行環境を本番ネットワークや機密データから隔離するサンドボックスを併用すると、万一エージェントが想定外の動作をしても被害を局所化できる。隔離環境の作り方はAIエージェントを安全に動かすサンドボックスが参考になる。「画面が見えている = その裏にある全データに触れられる」前提で、見せてよい範囲・操作させてよい範囲を物理的にも絞り込むことが重要だ。

技術リスク以外にも、運用で注意すべき点が 3 つある。

第一に誤操作。画面の読み取り違いで隣のボタンを押す、同じ操作を二重に実行する、といったミスは起こりうる。重要操作の前後にスクリーンショットと操作ログを残し、後から検証・巻き戻しができるようにしておく。

第二に自動化バイアス。エージェントの出力を人間が無批判に信じ込む傾向のことで、確認役を置いても「どうせ合っているだろう」と素通りすれば意味がない。対策はAI 自動化バイアスの対策にまとめている。

第三に利用規約・コンプライアンス。外部サイトやポータルを自動操作する行為は、相手側の利用規約で禁止されている場合がある。実際に、エージェントによる自動ブラウジングをめぐる法的な係争も表面化している。対象サイトの規約を事前に確認し、許諾の範囲内で運用することが欠かせない。

ASEAN の現場では「多言語の画面」と「現地のデータ保護法」が、コンピュータユース活用の固有論点になる。 タイを中心に、現地特有の留意点を整理する。

タイをはじめ ASEAN の B2B 環境では、システムの画面がタイ語・英語・日本語など複数言語で混在することが珍しくない。画面を視覚的に理解するコンピュータユースは、こうした多言語 UI でも比較的対応しやすいが、言語によって読み取り精度が変わるため、対象言語ごとに検証しておきたい。

データ保護の観点も外せない。タイの個人情報保護法（PDPA）をはじめ、ASEAN 各国は個人データの取り扱いに規制を設けている。エージェントが顧客情報や従業員情報の表示された画面を扱う場合、その画面データやスクリーンショットも保護対象になりうる。ログやスクリーンショットの保存範囲・保存期間を最小化し、アクセスを限定する設計が必要だ。タイでの具体的な順守項目はタイ PDPA 対応と AI 活用のチェックリストを参照してほしい。

コンピュータユースの導入検討で頻繁に挙がる質問をまとめた。

必ずしも乗り換える必要はない。画面が安定していて手順が完全に定型な業務は、従来型 RPA のほうが速く確実なことが多い。コンピュータユースが有利なのは、画面変更が多い、例外パターンが多い、対象システムが多岐にわたるといった、RPA のメンテナンス負荷が高い業務だ。両者は競合ではなく、業務特性に応じて使い分けるのが現実的で、RPA と AI の協働という観点はAIハイブリッド BPOも参考になる。

「単調で量が多く、間違えても取り返せる」業務から始めるのが鉄則だ。具体的には、API のないポータルへの情報入力、複数サイトからの情報収集とレポート化、レガシーシステムへの転記などが入口に向く。逆に、支払確定や契約締結のような高リスク業務は、人間の確認を厚くした一部自動化から慎重に始めるとよい。

最低条件は 3 つだ。第一に、高リスク操作の手前に人間の確認（HITL）を必ず挟むこと。第二に、操作ログとスクリーンショットを残し、失敗を検証・巻き戻しできるようにすること。第三に、エージェント専用アカウントを最小権限で運用し、実行環境を隔離すること。この 3 つを欠いたまま全自動化に踏み込むと、1 つの誤操作が大量のデータ汚染につながりやすい。

コンピュータユースは、AI エージェントが画面を見て操作することで、API のない業務まで自動化を広げる技術だ。従来型 RPA が苦手としてきた「画面が変わる・例外が多い」業務や、API を持たないレガシーシステム・行政ポータルの操作で特に価値を発揮する。

一方で、人間の操作権限をそのまま引き継ぐ以上、最小権限・サンドボックス隔離・人間の確認（HITL）・操作ログという土台を欠けば、効率化どころか大きな事故を招きかねない。「単調だが取り返せる」業務から小さく始め、失敗の起き方を見極めながら任せる範囲を広げていく — この段取りが、デモで終わらせず本番で使い続けるための近道になる。

当社では、タイ・ASEAN の B2B 業務に合わせた AI エージェント導入を支援している。どの業務から着手すべきか整理したい場合は、お気軽にご相談いただきたい。