GitHub Copilot に Computer Use が登場 (2026 年 10 月 1 日、公開プレビュー)
2026 年 10 月 1 日、GitHub は changelog で、GitHub Copilot CLI と macOS/Windows 版 GitHub Copilot アプリに Computer Use を追加したと発表しました。デスクトップアプリの画面を読み取り、操作できるようにする機能で、現時点は公開プレビューです。
対応するクライアントは、GitHub Copilot CLI と macOS/Windows 版の GitHub Copilot アプリの 2 つです。Linux や Web 版の GitHub Copilot への言及は changelog にありません。
最初に明示しておきたいのは、対象プラン・料金・一般提供 (GA) の時期が、現時点の公式情報のどこにも記載されていないことです。GitHub Copilot には Business・Enterprise 向けの管理者向け変更が続いており、新機能の既定ポリシー もその 1 つですが、今回の Computer Use が対象プランのどこまでを含むかは、公式ドキュメントを読んでも分かりません。本記事では、確認できない部分を「記載なし」と明示したうえで進めます。
注意
GitHub のドキュメントには "Computer use is in public preview and subject to change." と明記されています。仕様は今後変わる可能性があり、現時点の挙動が そのまま一般提供版に引き継がれるとは限りません。
Computer Use で何ができるようになったか
Computer Use がやっていることは大きく 2 つです。ひとつは画面を読み取ること、もうひとつはその画面を操作することです。
読み取りは、アクセシビリティツリーとスクリーンショットの両方を通じて行われます。操作は、クリック・入力・キー操作・スクロール・ドラッグ、そして複数ステップのワークフロー実行まで含まれます。この仕組みは 公式ドキュメント に説明されています。
想定されている用途は、API・CLI・MCP 連携を持たないレガシーソフトウェアや GUI 専用ソフトウェアの自動化です。挙げられている使用例は、ブラウザ内の通知をまとめて要約する、プレゼン資料のスライドを更新する、デスクトップアプリ内のワークフローを処理する、の 3 つです。
共通しているのは、画面を見ながら手で操作する以外に連携手段がないソフトウェアを対象にしている点です。API や MCP サーバーを持つシステムなら、そちらを使うほうが速く確実です。Computer Use が候補に挙がるのは、その選択肢が無いときに限られます。
有効化の手順と事前準備
有効化の方法は、CLI とアプリで分かれています。
GitHub Copilot CLI では、公式ドキュメント に記載された次の 3 つのコマンドを使います。
| コマンド | 動作 |
|---|---|
/computer on | Computer Use を有効にする |
/computer show | 現在の状態を表示する |
/computer off | Computer Use を無効にする |
GitHub Copilot アプリでは、Settings から Computer Use の項目を開いて有効にします。画面遷移の細かいクリック手順は changelog に記載がありません。
macOS で使う場合は、事前に 2 つの権限を許可しておく必要があります。アクセシビリティ権限と、スクリーン録画権限です。どちらも OS 標準のプライバシー設定から許可します。許可していないと、Computer Use は画面を読み取れません。
操作中の承認・中断の仕組み
操作はアプリ側が勝手に進め続けるわけではありません。各操作の前に承認が求められ、選べる選択肢は Allow (今回だけ許可)・Always allow (このアプリは常に許可)・拒否の 3 つです。Always allow にしたアプリは、あとから見直したり、設定をリセットしたりできます。
CLI にはさらに 2 つの操作が用意されています。Esc キーを 2 回押すと、実行中の操作を中断できます。 /permissions show を実行すると、現在どの承認モードが有効になっているかを確認できます。
要点
公式ドキュメントは "Configured deny rules still take precedence." と説明しています。設定済みの拒否ルールは、ほかの承認設定より常に優先される という意味です。Always allow にしていても、拒否ルールに触れた操作は止まります。
FIXIT操作が暴走しそうになったら、途中で止める方法はあるの？
Hayateあります。CLI なら Esc を 2 回押すだけで中断できます。
FIXITじゃあ、そもそも触らせたくないアプリはどうするの？
Hayate拒否ルールを先に設定します。ほかの承認設定より常に優先されます。
使う前に知っておきたいリスクと限界
公式ドキュメント は、リスクと限界の両方を明記しています。
リスクとして挙げられているのは、曖昧な指示や想定外の画面内容によって、意図しない操作が実行されてしまう可能性です。あわせて、機密情報が表示されるアプリでの使用は避けるべきだという趣旨も記載されています。画面を読んで次の操作を決める以上、画面に映っているものが、そのまま判断材料になります。
限界として挙げられているのは、インターフェイスの変更への対応と、複雑なワークフローでの精度です。対象アプリの画面レイアウトが変わったときにどこまで追従できるか、何ステップにもまたがる複雑な手順をどこまで正確にこなせるかは、公式ドキュメントも言い切っていません。
導入時に考えておきたい線引き (提案)
ここから先は公式の基準ではなく、本記事が提案する線引きです。
- 送金・決済・個人情報・認証情報を扱う画面は、最初から対象外にする
- 「いい感じに整理して」のような曖昧な指示ではなく、対象アプリと制約を具体的に書く
- 常時 Always allow にせず、扱う業務が固まるまでは都度承認で挙動を確認する
コツ
高権限のアプリを対象外にし、指示を具体化し、常時オンにしません。この 3 つは Claude in Chrome の運用アドバイスとも重なります。画面を操作する AI 機能に共通する、無理のない始め方です。
公式の記載を確認する
よくある疑問をまとめて確認しておきます。
| 項目 | 公式の記載 |
|---|---|
| 対象プラン | 記載なし |
| 料金 | 記載なし |
| GA (一般提供) の時期 | 記載なし (現時点は公開プレビュー) |
| 提供地域 | 記載なし |
| 対応 OS | macOS・Windows (Linux・Web 版への言及なし) |
対象プラン・料金・GA の時期・提供地域は、changelog と公式ドキュメントの 2 か所のどちらにも記載がありません。「そのうち分かる」ものとして扱わず、今の時点では分からないと認識しておくのが安全です。
Claude の画面操作系機能との違い
「AI がブラウザやデスクトップを操作する」という機能は、GitHub Copilot だけのものではありません。Anthropic も複数の機能を持っています。Claude Browser Use ツールの解説 と Claude in Chrome の解説 で扱った内容と並べると、違いが見えてきます。
| 観点 | GitHub Copilot Computer Use | Claude Computer Use・Browser Use (API) | Claude in Chrome |
|---|---|---|---|
| 提供形態 | GitHub Copilot CLI・macOS/Windows アプリに組み込み (公開プレビュー) | 開発者がプロダクトに組み込む Claude API のクライアントツールセット | 利用者の Chrome に入れる拡張機能 (一般提供) |
| 操作対象 | デスクトップアプリ全般 | デスクトップ全体 (Computer Use) またはブラウザのビューポート (Browser Use) | ブラウザ内に限定 |
| 承認の仕組み | 操作ごとに Allow・Always allow・拒否を選択。CLI は Esc 2 回で中断可能 | 実行系はアプリ側の executor に任され、承認の仕組みは組み込む開発者が設計する | 都度承認・自動承認・承認を飛ばすの 3 段階、サイト単位の継続許可 |
| 利用する主体 | GitHub Copilot の利用者 | 自社プロダクトに組み込む開発者 | 業務端末の利用者・情報システム部門 |
| 管理者による制御 | 組織管理設定で機能自体を無効化できる | ツールの有効化・実行系の実装は開発側の判断 | 組織のトグル・ロール単位権限・許可リストと拒否リスト |
スコープで見ると、GitHub Copilot の Computer Use は最初からデスクトップアプリ全般を対象にしています。Claude 側は、ブラウザ内だけなら Browser Use か Claude in Chrome、OS やネイティブアプリをまたぐなら Computer Use、というように、対象範囲でツールが分かれています。
FIXIT結局、どれを覚えればいいの？
Hayate使い分けの目安はスコープです。ブラウザ内で閉じるなら Claude 側、デスクトップアプリ全般なら両方が候補になります。
FIXIT「AI が画面を触る」でひとくくりにしないほうがいいんだ。
Hayateはい。組み込む相手と操作範囲が違うので、検討する相手も変わります。
レガシーシステムの自動化にどう使えるか
Computer Use の想定用途は、API・CLI・MCP 連携を持たないレガシーソフトウェアや GUI 専用ソフトウェアの自動化でした。これは、仕様書のないレガシーシステムを AI で読み解く で扱った「API を持たない古い基幹システム」という課題と地続きです。
ただし、役割ははっきり分かれています。Computer Use は、いま稼働している画面をそのまま操作する機能です。暗黙の業務ルールを読み解いたり、仕様を復元したり、システムを作り直したりする機能ではありません。刷新そのものの代わりにはなりません。
一方で、刷新を検討する前段階の、日々の定型操作を減らす選択肢の 1 つにはなり得ます。画面を見ながら手で繰り返している作業があり、API も MCP 連携も用意できない事情があるなら、対象を絞って試す価値はあります。その場合も、前述のとおり高権限のアプリや機密情報が表示される画面は対象外にし、都度承認で挙動を確認してから範囲を広げてください。
刷新そのものを計画する段階に進んだら、読み解きの手順は 仕様書のないレガシーを AI で読み解く に、刷新の進め方は システム刷新・リプレイス に整理しています。
管理者が確認すべきこと
公式の changelog によると、組織管理者は Computer Use という機能自体を管理設定で無効化できます。個別の操作を都度止めるのではなく、機能そのものを使わせない選択です。
対象プラン・料金・提供地域の記載が無い現状では、まず自社の契約がこの機能の対象になっているかどうかを、GitHub Copilot の管理画面で確認するところから始めることになります。そのうえで、現場での利用を許可するか、検討期間を設けて管理設定でいったん止めておくかを選んでください。
まとめ
GitHub Copilot の Computer Use は、2026 年 10 月 1 日に公開プレビューとして追加された、デスクトップアプリを操作する機能です。アクセシビリティツリーとスクリーンショットで画面を読み取り、クリック・入力・スクロール・ドラッグ・ワークフロー実行ができます。対象プラン・料金・GA の時期・提供地域は公式に記載が無く、現時点では確認できません。
承認はアプリの Always allow と、CLI の Esc 2 回・拒否ルール優先で制御できます。公式ドキュメントが挙げるリスクと限界を踏まえ、高権限のアプリを対象外にし、指示を具体化し、常時オンにしない運用から始めるのが無理のない進め方です。Claude の画面操作系機能とはスコープと承認の仕組みが異なるため、「AI が画面を操作する」でひとくくりにせず、対象範囲で選んでください。
AI 駆動開発のクリエイティブスタジオである FIXIT の AI 開発ツール定着支援 では、GitHub Copilot や Claude をはじめとする AI 開発ツールの使い分け・権限設計・社内ルール作りをご相談いただけます。API を持たない古いシステムの扱いまで含めて検討したい場合は、システム刷新・リプレイス もあわせてご覧ください。ご相談は お問い合わせ からご連絡ください。