ServiceDock
2026年8月17日 更新
約4分で読めます
AIにパソコンの画面を見せて、マウスとキーボードを操作させる。それがComputer Useです。APIが用意されていないシステムでも自動化できるため、応用範囲が広く見えます。
今回は手数を数えました。同じ業務（申請1件の承認）を画面操作とAPIで行った場合の比較です。結果を先に言うと、14手と2手、100件処理したときの失敗見込みは24.6件と4.0件でした。
画面のスクリーンショットを見て、マウスとキーボードを操作させる仕組みです。人が使う画面をそのまま自動化の対象にできます。
Computer Useは、AIがパソコンの環境とやり取りするための仕組みです。公式の説明によれば、スクリーンショットの取得と、マウスとキーボードの操作を提供します。
処理の流れは人と同じです。画面を撮る、何が写っているか判断する、クリックや入力を行う、また画面を撮る。この繰り返しで作業を進めます。
この仕組みの価値は、連携用の窓口が用意されていない相手でも自動化できる点にあります。社内の古い業務システムや、外部提供されていない管理画面が対象になります。
逆に言えば、APIが用意されている相手には使う理由がありません。次の節で、その差を数字で見ます。
公式ドキュメントには、この機能がベータ版であることと、いくつかの制約が明記されています。本番の業務に組み込む前に、そこを把握しておく必要があります。
画面を操作して自動化するという発想自体は、RPAとして以前から存在します。違いは、画面の中身を都度判断できることです。従来のRPAは座標や要素を事前に指定しますが、Computer Useは画面を見て判断します。その代わり、判断を誤る余地も生まれます。
Claude can interact with computer environments through the computer use tool, which provides screenshot capabilities and mouse/keyboard control for autonomous desktop interaction.原文Claude Docs「Computer use tool」 この内容の有効期限2026-11-17
同じ業務を両方式で行ったときの手数を数えました。手数の差がそのまま成功率の差になります。
Computer Useの位置づけを確かめるため、手数を数えました。題材は申請を1件承認するという単純な業務です。
画面操作では、ログインから承認の確定まで人と同じ手順を踏みます。APIなら認証して1回呼ぶだけです。
同じ業務（申請1件の承認）を、画面操作とAPIで行った場合 画面操作の手数: 14手 APIの手数 : 2手 差 : 7.0倍 壊れる原因になりうるもの 画面操作: 5種類（ボタンの位置 / ボタンの文言 / 画面の構成 / 読み込みの速さ / 画面の解像度） API : 1種類（APIの仕様変更） 1手あたり98%成功するとき、最後まで通る確率 画面操作（14手）: 75.4% API（2手） : 96.0% 100件処理したときの失敗見込み: 24.6件 → 4.0件
開きました。24.6件と4.0件です。1手あたりの成功率は同じ98%と仮定していますが、通す手数が7倍あるので結果が変わります。
もう1つの差が、壊れる原因の多さです。画面操作はボタンの位置・文言・画面構成・読み込み速度・解像度のどれが変わっても影響を受けます。
APIの場合、影響するのは仕様変更だけです。しかも仕様変更は告知されることが多く、画面の微修正のように予告なく起きるものではありません。
手数が多いということは、時間もかかるということです。公式ドキュメントも、現在の応答速度は人が直接操作する場合と比べて遅すぎる可能性があると明記しています。
そのうえで、速さが重要でない用途を選ぶよう推奨されています。背景での情報収集や、自動テストといった例が挙げられています。
手数が増えるほど、最後まで通る確率は下がる。1手あたりの精度が同じでも差が出る。
Latency: The current computer use latency for human-AI interactions might be too slow compared to regular human-directed computer actions.原文Claude Docs「Computer use tool」 この内容の有効期限2026-11-17
APIが無く、速さも重要でなく、信頼できる環境。この3条件がそろったときです。1つでも欠けるなら他の方法を探します。
Computer Useを使うかどうかは、公式が示す推奨条件に沿って判断できます。速さが重要でない用途を、信頼できる環境でという条件です。
例として挙げられているのが、背景での情報収集と自動テストです。どちらも即座の応答が求められず、失敗しても被害が小さい用途になります。
公式ドキュメントには、実行前に操作を確認する仕組みや、記録を残す仕組みについての記述があります。間違いや幻覚が起きうることが前提になっているためです。
特に取り消せない操作については、承認を挟む形が推奨されます。この考え方はエージェントのセキュリティの記事で扱っている権限設計と同じです。
APIがあるなら画面操作は選ばない。3条件がそろったときだけ検討する。
どうしても画面操作が必要な場合、手数そのものを減らす方向で改善できます。ログイン状態を保持しておく、一覧の絞り込みをURLで指定する、といった方法です。
前の節の計算が示すとおり、手数は成功率に直接効きます。14手を7手にできれば、失敗見込みは半分近くまで下がります。
Focus on use cases where speed isn't critical (for example, background information gathering, automated software testing) in trusted environments.原文Claude Docs「Computer use tool」 この内容の有効期限2026-11-17
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る