GitHub Copilotのcomputer useは、Copilot CLIとGitHub Copilot appがmacOS/Windows上のデスクトップアプリを操作できるようにするpublic previewです。APIやCLI、MCPがないレガシー業務にも届く一方で、画面上の情報を文脈として扱うため、導入判断は権限・承認・対象アプリ・監査の4点で切る必要があります。
結論から言うと、最初に試すべき用途は経費精算、社内ポータル、プレゼン更新、GUI専用管理画面のような低リスクで反復的な作業です。顧客データ、決済、権限変更、本番操作を含むアプリでは、Always allowを避け、毎回承認と作業後レビューを残す運用から始めるのが安全です。
概要：computer useで増えた4つの操作領域
computer useはCopilot CLIとGitHub Copilot appで利用でき、macOSとWindowsのデスクトップアプリを対象にします。Copilotはアクセシビリティ情報や必要に応じた視覚情報を読み取り、クリック、テキスト入力、キー操作、スクロール、ドラッグ、複数アプリをまたぐワークフローの移動を実行できます。
管理者が見るべき操作領域は4つです。第一に「読む」操作、第二に「入力・編集」操作、第三に「アプリ間移動」操作、第四に「承認済みアプリの継続操作」です。特に第四の領域は、Always allowを選ぶと後続セッションでも同じアプリを操作できるため、便利さとリスクが同時に増えます。
仕様表：API・MCP・computer useの使い分け
APIやMCPで完結する処理は、構造化された入力と出力が残りやすく、再現性も高くなります。GitHub Docsでも、API、MCPサーバー、ターミナル、ファイルシステム、専用ブラウザツールで直接完了できるなら、通常はそれらの方が予測可能だと説明されています。computer useは、直接の連携手段がないGUI専用業務を補う最後の接続面と考えるべきです。
使い分けの目安は明確です。データ取得や登録のAPIがあるならAPIを優先します。社内ツールにMCPを立てられるならMCPを優先します。CLIで再現できる運用ならCLIを優先します。それでも人間が画面を開いてクリックするしかない作業だけをcomputer useに渡すと、適用範囲が広がりすぎません。
設定手順：最初の30日PoCで確認すること
PoCは30日で十分です。1週目は対象業務を5件に絞り、経費精算の下書き、通知の要約、プレゼン内テキスト更新、社内ポータルの定型入力、GUI専用ツールからの情報転記のように、失敗しても取り返しやすい作業だけを選びます。2週目はCopilot CLIで /computer on を試し、/computer show で状態確認、/computer off で停止できることを利用者に覚えてもらいます。
3週目はGitHub Copilot app側でComputer Useを有効化し、承認フローを検証します。4週目は誤クリック、入力先の取り違え、画面状態による停止を集め、継続すべきアプリと除外すべきアプリを分けます。
管理者チェック：承認・権限・機密情報の4項目
管理者チェックは4項目です。1つ目は承認です。Copilotがアプリを制御する前に承認を求める設定になっているか、Always allowを許す対象を限定できているかを確認します。2つ目は権限です。macOSではAccessibilityとScreen Recordingが必要になるため、MDMや社内手順で付与条件を明確にします。
3つ目は機密情報です。画面には顧客情報、個人情報、財務情報、他人のメッセージが映る可能性があります。見えている内容をCopilotへ文脈として渡してよいアプリだけを対象にします。4つ目は組織ポリシーです。Enterprise managed settingsでcomputer useを無効化でき、ローカルで有効化しても組織ポリシーは上書きできません。
料金・工数への影響：100人組織の試算
computer useの価値は、削減できる定型作業時間で見ます。100人組織で対象者20人が週2回、1回15分のGUI転記を行うなら月約40時間です。半分を下書き化できるだけでも月20時間を別作業に戻せます。
一方で初月は設定・教育・レビューも必要です。対象アプリ選定とポリシー確認に4時間、利用者説明に3時間、失敗ログ確認に週1時間を見込むと、初月の管理工数は約11時間です。月20時間以上の反復作業が見える部門から始めると判断しやすくなります。
失敗しやすいパターン：Always allowと高インパクト操作
避けたいのは、便利だからという理由で重要アプリをAlways allowにする運用です。GitHub Docsは、機密情報を含むアプリや高インパクト操作を支えるアプリでAlways allowを避けるよう注意しています。経理、権限管理、本番管理画面、顧客対応システムは、毎回承認と人間の最終確認を残す設計が必要です。
もう1つの失敗は、曖昧な指示です。computer useは画面状態、アプリのバージョン、ウィンドウ配置に影響されます。「いい感じに処理して」ではなく、「Safariで経費申請ページを開き、未提出一覧から交通費だけを下書きし、送信前に止まる」のように、対象アプリ、完了条件、禁止操作を明示します。
FAQ：Copilot computer useのよくある質問
Q1. すぐ全社展開してよいですか。A. 低リスクな5業務で30日PoCに留めるのが現実的です。画面操作は強力ですが、誤操作や機密情報の露出リスクがあるため、対象アプリを広げる前に失敗パターンを集めます。
Q2. CLIとappの違いは何ですか。A. どちらもcomputer useを利用できます。CLIでは /computer on、/computer show、/computer off で状態を扱えます。appではSettingsのComputer Useから有効化します。Always allowの保存判断は同じコンピューター上のCLIとappにまたがって影響します。
Q3. 既存のRPAと置き換えるべきですか。A. 最初から置き換えるより、例外処理や少量のGUI業務に使う方が向いています。安定した大量処理はRPAやAPIの方が監査しやすく、computer useはAPI化されていない周辺作業を補完する位置づけが合います。
導入判断：最初に決めるべき社内ルール
導入前に決める社内ルールはシンプルです。対象アプリの一覧、Always allowを禁止するアプリ、承認なしで実行してよい操作、送信・削除・権限変更の前に止めるルール、失敗時にEscまたはStopで中断する手順を1枚にまとめます。
Copilot computer useを社内業務に入れるなら、対象アプリ選定、承認設計、利用者教育、PoC設計をまとめて確認する必要があります。HelloCraftAIでは、AIエージェント導入前の業務整理とガバナンス設計を支援しています。 相談する
