AI開発コネクト
AI最新ニュース開発ツール・API

AIがデスクトップアプリを操作。API無しの業務ソフト自動化で確認する4点

10月1日に公開されたGitHub Copilotのコンピュータ操作はパブリックプレビュー。macOSで画面収録権限が要る意味、組織設定で止められること、見積もりで揃える端末・ログ・権限の4点を解説します。

公開: 2026.10.06 / 更新: 2026.10.06

AI 導入の相談で最も早く見積もりから消えるのは、「API の無い既存ソフト」を使う業務である。画面にしか出てこない、CSV も吐かない、ベンダーのサポートも切れている。この手の業務は毎回「対象外」になり、人の手作業として残り続けてきた。

2026 年 10 月 1 日、GitHub が Copilot の「computer use(コンピュータ操作)」をパブリックプレビューで公開した。AI が macOS と Windows のデスクトップアプリを直接操作する機能である。公式の変更履歴は、想定用途として 「API・コマンドライン・MCP 連携を持たない、レガシーソフトや GUI だけのソフトのワークフロー」 を明示している。

発注側にとっての意味は、ツールの新機能ではない。「API が無いから自動化できない」という、これまで見積もりの前提だった一文が、条件付きで崩れ始めたということである。

机の上に置かれたノートPCの画面に、古い様式の業務ソフトのウィンドウが1つ開いている

公表されている事実

GitHub の変更履歴に書かれている内容だけを並べる。

項目 内容
公開日 2026 年 10 月 1 日
提供状態 パブリックプレビュー(正式提供ではない)
対象クライアント GitHub Copilot CLI、GitHub Copilot アプリ
対象 OS macOS、Windows
できること アプリの表示内容と画面の視覚情報の読み取り、クリック、文字の入力と編集、キー操作、スクロール、ドラッグ、複数アプリをまたぐ操作
有効化 CLI は /computer on(状態確認は /computer show、停止は /computer off)。アプリは設定から有効化
実行時の制御 アプリを操作する前に承認を求める。「常に許可」にしたアプリは後から確認・解除できる
組織側の制御 組織の管理設定(organization-managed settings)で機能を無効化できる
macOS で必要な権限 アクセシビリティと画面収録の許可

ここまでが公表されている事実である。以下は見立てになる。

論点 1. 「API が無い」が断りの理由にならなくなる場面がある

AI 開発の見積もりで、連携先システムは次の 3 層に分けられてきた。

層 扱い 見積もりへの影響
API / DB 直結がある 標準的な連携工数 読める
ファイル連携(CSV・PDF)だけ 受け渡しの設計が要る 中程度
画面しか無い 対象外、または RPA を別途導入 見積もりから落ちる

3 層目はこれまで、専用の RPA 製品を別で買い、画面の座標や要素を 1 つずつ指定して作り込む領域だった。作る費用より、画面が変わるたびに壊れて直す費用のほうが重い。

画面の内容を読んで操作する方式は、この「作り込み」の部分を減らす方向に効くと考えられる。ただし減るのは作り込みであって、壊れないことの保証ではない。レイアウトが変われば挙動は変わる。見積書で「RPA の保守費が不要になる」と書かれていたら、何を根拠にそう言えるのかを聞く必要がある。

論点 2. 画面を読むということは、画面に映るすべてを読むということ

macOS で画面収録の許可が要る、という一行が実務上は最も重い。

画面収録の許可は、アプリ単位ではなくその端末の画面全体に対して与えるものである。つまり、操作対象の業務ソフトだけでなく、その裏で開いている次のものが読める状態になる。

  • 別の顧客の画面
  • 社内チャット・メールの通知
  • 人事・会計など、本人の権限で開ける別システム
  • 他社との NDA 下にある資料

承認を求める設計が入っているとはいえ、承認するのは「このアプリを操作してよいか」であり、「画面に何が映っているか」ではない。データの持ち出し可否を業務単位で決めてきた社内ルールと、粒度が合っていない点に注意がいる。外部へ出してよい情報の区分の決め方は外部APIに送ってよいデータの決め方で整理した。

もう 1 つ、画面の文字を読んで動くということは、画面に表示された文章が指示として働きうるということでもある。業務ソフトの備考欄や、取り込んだ PDF の中身に外部の人間が文字を書ける場合、そこが入口になる。仕組みと防御はプロンプトインジェクションとはにまとめている。

論点 3. プレビュー段階の機能を、見積書の前提にしない

パブリックプレビューは、仕様・提供範囲・料金のいずれも変わりうる段階である。提供が止まる可能性も、正式提供時に上位プランだけになる可能性も残っている。

にもかかわらず、この種の機能は提案書に載りやすい。「既存システムの改修は不要です、画面操作で吸収します」という一文は、見積もりの連携工数を大きく下げるからである。

見積書にこの前提が入っている場合、提供状態(プレビューか正式提供か)と、使えなくなったときの代替案を、同じ紙の上に書かせるのが筋だと考えられる。使える前提のモデルやツールが実際には限定提供だった場合の読み方は、限定提供のモデルを前提にした見積書でも扱った。

発注者・企業への影響

第一に、「画面しか無い」ことを理由に見送った業務を棚卸しする。見送り案件の一覧があるなら、そこに「画面操作で届く可能性がある」という列を 1 つ足す。ただし今すぐ発注する話ではなく、次に見積もりを取るときの検討対象に戻す、という意味である。

第二に、組織の管理設定で止められることを、情報システム部門に先に伝える。公式に「組織の管理設定で無効化できる」と書かれている以上、使うか使わないかは会社として決められる。個々の開発者の端末で気づかないうちに有効になる状態を避けるには、先に方針を決めておくほうが早い。ツールの設定を組織側で固定する考え方は組織がAIモデルを固定できる設定と同じ系列である。

第三に、画面操作を含む提案を受けたら、操作する端末を限定させる。業務担当者の日常端末ではなく、対象ソフトだけを入れた専用端末・専用アカウントで動かす構成なら、画面に映る範囲を設計で絞れる。この切り分けは見積もりの環境費として別行に出てくる。

第四に、ログの要件を先に出す。何のアプリを、いつ、どの操作で触ったかの記録が残らない自動化は、後から検証できない。監査や事故対応で必要になる項目は発注側しか決められない。

第五に、失敗したときの扱いを決める。画面操作は、間違ったボタンを押しても「エラー」として返ってこない。承認フローのある業務に入れる場合、取り消せる操作だけに限定する、という範囲の切り方が要る。

見積もりを取るときに揃える 4 点

複数社に聞くなら、次の 4 点を同じ文面で出すと回答が比較できる。

  1. 対象アプリと画面の数(何本のソフトの、何画面を操作するか)
  2. 操作する端末の構成(日常業務端末か、専用端末か)
  3. 残すログの項目(操作履歴・画面の保存有無・保存期間)
  4. 画面が変わったときの直し方と費用(保守に含むか、都度見積もりか)

この 4 点が揃っていないと、A 社は専用端末前提、B 社は担当者端末前提で金額を出す。前提が違う金額は比べられない。無料で相見積もりの案件票では、連携先システムとセキュリティ要件を選択式で揃えているので、各社が同じ構成を前提に出したかを横並びで確認できる。すでに「RPA 不要」「改修不要」と書かれた見積書を受け取っているなら、見積書チェックで根拠の書かれていない行を洗い出せる。

まとめ

今回の発表は、自動化の対象範囲を広げる方向の変更である。一方で、広がった分だけ**「AI に何を見せているか」を会社として管理する必要**が増える。

発注側が今やれることは 2 つある。画面しか無いことを理由に落とした案件を記録に戻すこと、そして画面操作を含む提案が来たときに、端末・ログ・権限の 3 点を見積書の行として要求することである。どちらも機能が正式提供になるのを待つ必要はない。

参考・出典

AI開発の見積もりを、同じ条件で比べる。

条件を整理した 1 枚の案件票で複数のAI開発会社に依頼。初期費用だけでなく、データ整備・API 費・精度検証・保守・権利まで同じ列で比較できます。

無料で相見積もりを始める →
無料で相見積もり30秒で費用診断