GitHub Copilot、デスクトップアプリの操作に対応 - 既定は無効だが、保存した許可はCLIとアプリで共有される

GitHubは2026年10月1日、GitHub Copilot CLIとGitHub Copilotアプリに、デスクトップアプリをCopilotが操作する機能（computer use）をpublic previewとして追加した。対象OSはmacOSとWindowsである¹。

Copilotが利用者の代わりに行うのは、アクセシブルなアプリの内容と視覚的な文脈の読み取り、コントロールのクリック、テキストの入力と編集、キー押下、スクロール、ドラッグ、そして複数のアプリをまたいだワークフローの移動である¹。読み取りの経路は、OSのアクセシビリティツリーか、視覚的な文脈が必要なときのスクリーンショットになる²。

GitHubが狙いとして挙げているのは、API・コマンドラインインタフェース・MCP統合を持たないレガシーおよびGUIのみのソフトウェアのワークフローを含め、自動化できる作業を広げることである¹。社内の古い業務システムのように、画面しか入口がない相手が対象になる。

GitHub自身が「他の手段があるならそちらを」と書いている

ドキュメントには使い分けの線が引かれている。API・MCPサーバ・ターミナルコマンド・ファイルシステムツール・専用のブラウザツールでその作業が直接できるなら、そちらのほうが構造化された情報と予測可能な結果を与えるのが普通だ、という書き方である²。computer useは視覚的なインタフェースとのやり取りが必要な作業のための手段だと位置づけられている。

どのツールを使うかはエージェントが処理の途中で自分で選ぶ。ツールの活動はセッションで確認できるとされている。AIエージェントに判断を委ねる範囲が、画面操作まで広がるということでもある。

既定は無効、承認を求めるかはサーフェスの設定次第

computer useは既定で無効で、エージェントがツールを使う前に有効化が必要である²。有効化の操作は面ごとに違い、Copilot CLIでは/computer onで有効、/computer showで状態確認、/computer offで無効にする。Copilotアプリでは Settings から Computer Use を選び Enable Computer Use をオンにするか、同じく/computer onを使う¹。

承認の求め方は固定ではない。ドキュメントは、computer useはセッションが動いているCopilotサーフェスのツール権限設定に従い、その設定がアプリを操作する前に承認を求めるかどうかを決めると書いている。この設定は面ごとに変えられる²。承認を求められたときに選べるのは、現在のセッションのみ許可・今後のセッションにも保存・拒否の3つである。

なお、Copilotの機能には10月22日に発効する「新機能の既定ポリシー」があるが、こちらはプレビュー中の機能には適用されない。public previewの段階にあるcomputer useは、その自動有効化の対象にはならない。

保存した許可はCLIとアプリで共有される

設計上もっとも効いてくるのはここである。特定のアプリに Always allow を選ぶと、その判断はローカルに保存され、同じコンピュータ上のCopilot CLIとCopilotアプリの両方に適用される²。CLIで一度与えた許可が、アプリ側のセッションにもそのまま効く。

取り消しも同じ範囲で動くが、ひとつ非対称がある。Copilotアプリで常時許可アプリの一覧を開いて個別に削除すると、アプリとCLIの両方で今後のセッションから保存済み承認が消える。ただし実行中のセッションで既に与えたアクセスは取り消されない²。走っているエージェントを止めたいなら、設定を直すのではなく実行自体を中断する必要がある。中断の操作はCopilot CLIでEscを2回、CopilotアプリではStopをクリックするかEscである。

優先順位も明示されている。ツールを拒否する権限ルールは、自動承認や保存済み承認より優先される²。管理側では、エンタープライズの管理者がmanaged settingsでcomputer useを無効にでき、ローカルで有効化してもエンタープライズのポリシーを上書きしない。Changelogも、管理された設定でこの機能を無効にできると書いている¹。エージェントの操作をブロック・承認必要・確認なしに振り分ける管理が9月に入っていたのと同じ向きで、利用者側の有効化が管理側の判断を越えない形になっている。

この共有の仕方は、同じCopilotでも機能によって違う。9月に入ったCopilotアプリのローカルサンドボックスは、アプリとCLIでサンドボックス設定を別々に構成する必要があるという設計だった。制限のほうは面ごと、許可のほうは面をまたいで共有される。どちらも既定は無効だが、一度触ったあとの広がり方が逆である。

macOSでは2つのOS権限を渡すことになる

macOSの場合、computer useは2つの権限の付与を案内する。アプリのコントロールを操作するための Accessibility と、視覚的な文脈が必要なときにアプリのウィンドウを調べるための Screen Recording である²。

画面収録の権限を渡すということは、その時点で見えているものが入力になりうるということでもある。ドキュメントもその前提で書いていて、アプリのウィンドウには他人に関する情報を含む機微な情報が表示されうるため、見える内容をCopilotに文脈として渡してよいアプリと作業にだけ使うよう求めている。

リスクの記述が具体的である

ドキュメントの Warning ブロックには、曖昧な指示や予期しない画面上の内容が意図しない動作を引き起こし、端末・データ・接続済みアカウント（個人・金融・企業のシステムへのアクセスを含む）に影響することがあると書かれている。そのうえで、computer useは人間の判断の代わりではないとし、データを変更する動作や他人に影響する動作を許可する前は特に、対象アプリ・要求された権限・結果を確認するよう求めている²。

技術的な限界も並んでいる。インタフェースはアプリのバージョン・OS・ウィンドウ状態で変わりうるため、誤ったコントロールを選ぶ、誤った場所にテキストを入れる、非標準や動的なコントロールや複雑なワークフローで苦労することがある。タイミングやウィンドウ状態の変化で結果が変わり、動作を繰り返す、あるいは継続できなくなることもあるとされている。

Always allow についても明示的な注意がある。一度選ぶと以後のcomputer useの操作は確認なしにそのアプリを操作できるため、機微な情報を含むアプリや影響の大きい操作ができるアプリでは選ばないよう勧めている。

有効化の前に決めることが増えた

前日のChangelogに載ったVS CodeでのHydraFusionがモデルの使い方の話であるのに対し、computer useは手元の端末で何に触れるかの話である。public previewであり変更の可能性があるとされている段階なので、仕様はまだ動く。

試すかどうかを決める前に整理しておきたいのは3点ある。どのアプリに Always allow を与えるか（与えた判断はCLIとアプリの両方に効く）、managed settingsで組織として止めるのか個人の判断に委ねるのか、そしてmacOSならScreen Recordingの権限を渡してよい端末かどうか。GUIしかない業務システムを自動化できる余地は確かに開くが、その入口は画面に映るものをすべてモデルに渡す経路でもある。

Sources

1. GitHub Copilot can now interact with desktop apps with computer use - GitHub公式Changelog（2026年10月1日）
2. About computer use in GitHub Copilot - GitHub Docs（確認日2026年10月2日）