Copilot computer useとは｜設定と権限・限界
「APIが無い業務ソフトだけは、どうしても手入力が残る」——AIで事務作業を減らそうとすると、最後にここで止まります。
結論から言うと、GitHub Copilot の computer use はその最後の一手として現実味がある一方、業務の本番ラインに最初から載せる機能ではありません。判断の分かれ目は「速く動くか」ではなく「壊れたときに止まるか」です。
株式会社Fyveは、画面操作による自動化を実際に本番運用し、一部を撤退させて API 経路に作り替えてきました。この記事では公式発表で確認できた事実と、私が自分の運用で踏んだ失敗の両方から、computer use をどう扱うべきかを整理します。
GitHub Copilot の computer use とは
computer use は、Copilot がデスクトップアプリの画面を直接操作できるようにする機能です。2026年10月1日に GitHub の公式 changelog で発表されました。
公式発表で確認できること
GitHub 公式の changelog に書かれている内容は、次の範囲です。
- 提供状態はパブリックプレビュー。対象は Copilot CLI と GitHub Copilot アプリ
- 対応OSは macOS と Windows（Linux は記載なし）
- できる操作は「アクセシブルなアプリの内容と視覚的な文脈の読み取り、コントロールのクリック、テキストの入力と編集、キー入力、スクロール、ドラッグ、アプリをまたいだワークフローの操作」
- 狙いとして「API・コマンドラインインターフェース・MCP 連携を提供しない、レガシーおよびGUIのみのソフトウェアにおけるワークフロー」が明示されている
- アプリを操作する前に Copilot が承認を求める。「常に許可」にしたアプリは後から確認・リセットできる
- macOS ではアクセシビリティと画面収録の権限付与へ誘導される
- 組織管理の設定でこの機能を無効化できる
- 使い方のコツとして「達成したい結果、関係するアプリ、重要な制約を説明したときに最もうまく動く」
有効化の手順も changelog に出ています。Copilot CLI では /computer on で有効化し、/computer show で状態確認、/computer off で無効化します。GitHub Copilot アプリでは設定から「Computer Use」を開き、Enable Computer Use を有効にします。
公式では確認できなかったこと（二次情報との切り分け）
ここは重要なので分けて書きます。解説記事で流通している次の情報は、私が公式 changelog を読んだ範囲では確認できませんでした（2026年10月6日時点）。導入判断に使う場合は、必ず最新の公式ドキュメントで確認してください。
- 必要なプラン・ライセンス：changelog に記載がありません。二次情報では「Copilot CLI は各プランで利用でき、組織提供のアクセスには組織側のCLIポリシーが必要」とされていますが、公式の裏は取れていません
- 既定でオフかどうか：二次情報は「既定で無効」としていますが、changelog は明記していません
- 許可モードの粒度（そのセッションのみ許可／常に許可／アプリの削除といった区分）：二次情報の記述で、公式には承認と「常に許可のリセット」までしか書かれていません
- 管理者のブロックをローカル設定で上書きできないこと：公式は「組織管理の設定で無効化できる」とだけ述べています
- Copilot が API・ファイル操作・MCP・ブラウザ自動化といった直接的な手段を優先するという挙動：二次情報にはありますが、changelog には書かれていません。もし本当にそう実装されているなら設計として妥当で、後述する私の結論とも一致します
他社サービスの仕様は、プレビュー期間中はとくに動きます。社内で説明資料を作るときは、この切り分けをそのまま持ち込むのが安全です。
何が自動化の対象になるのか
computer use が刺さる領域は、changelog の言葉がそのまま答えになっています。API も CLI も MCP も提供していないソフトです。
逆に言えば、API がある相手にこの機能を使う理由はありません。ここを取り違えると、わざわざ壊れやすい経路を選ぶことになります。
建設会社の業務ソフトでぶつかった壁
私が2026年9月に調査した建設会社のケースが、この「API が無い」の実態を示しています。建設業向けのクラウド業務ソフトを使っている会社で、ソフトの連携仕様を調べた結論はこうでした。
出す側（仕訳・帳票・Excel・給与CSV）は揃っているのに、入れる側＝外部からの取り込み口がほぼ無い。確認できた取込口は、建築見積の明細CSVインポートだけ。公開APIはありませんでした。
そして痛みの本体は、ソフトの計算能力ではありませんでした。Excel を見ながら業務ソフトに手入力している——つまり同じ情報が2回、人の手を通っている状態です。請求書を読んで Excel に仕分けし、その Excel を読んで業務ソフトに入力する。入力したあとは自動で計算されるので、痛みは「入力」の一点に閉じていました。
computer use のようなデスクトップ操作が本当に効くのは、まさにこの一点です。画面しか入口が無く、人が同じ値を2回打っている箇所。「AIで何か効率化したい」ではなく「この画面のこの入力を代わりに打ってほしい」まで絞り込めているかが、使えるかどうかの境目になります。
RPA との役割の違いを整理したい場合は、こちらも参考にしてください。
有効化の手順と、macOS で必要になる権限
Copilot CLI の場合
/computer show— 現在の状態を確認する/computer on— 有効化する/computer off— 無効化する
GitHub Copilot アプリの場合
設定を開き、「Computer Use」を選択して Enable Computer Use を有効にします。macOS・Windows の両方でアプリが対象です。
macOS の権限は「あとで剥がれる」前提で考える
macOS では、アクセシビリティと画面収録の権限が必要になります。公式も、その付与手順へ案内すると書いています。
ここで私の失敗を1つ共有します。2026年7月5日、定期実行の仕組み（launchd）から AI のセッションを起動したところ、4時間半、ログに1行も出さずに無言で止まりました。原因はカレントディレクトリの取得でブロックしていたことで、実体は macOS のプライバシー保護（TCC）でした。ユーザーが手で操作していれば同意ダイアログが出る場面なのに、バックグラウンド実行ではダイアログを出せず、永久に待ち続けていたのです。調査から根治まで約40分かかりました。
このとき学んだことが2つあります。
- 「手元で試して動いた」は、無人実行での動作保証にならない。権限の審査主体が変わるため、同じコマンドが同じように動きません
- 実行ファイルに強い権限を与える対処は時限爆弾になる。アップデートでバイナリが差し替わるたびに権限が剥がれます。私は権限を足す代わりに、保護対象の外へ作業場所を移してこの問題クラスごと消しました
computer use はアクセシビリティと画面収録、つまり「画面に映っているものを読み、操作する」権限を要求します。更新で権限が外れる日が来る前提で、止まったことに気づける運用にしておくべき種類の機能です。
権限設計——「常に許可」は思っているより重い
公式は、アプリを操作する前に承認を求める、常に許可したアプリは確認・リセットできる、組織管理の設定で無効化できる、と書いています。プレビュー機能としては妥当な作りです。
ただし運用側の感覚として申し上げると、画面を読んで操作できる権限は、渡すクレデンシャルとしてかなり重い部類です。私は自分の運用で、ログイン済みブラウザのプロファイルを自動化に使う判断をしたとき、これを「本体への完全な操作権限」と評価しました。技術的には投稿も削除もできてしまうからです。そこでガードは機能側ではなく運用側に置きました。
- 公開に至る経路は明示フラグを付けたときだけに限定する
- スキル側の規則に「削除・設定変更などの破壊的操作を行わない」を明記する
- 接続はローカルホストに限定し、ネットワークに開かない
computer use に置き換えるなら、「常に許可」に入れてよいのは、誤操作しても後戻りできるアプリだけです。会計ソフトの確定ボタン、送信ボタン、決済画面は入れてはいけません。組織で使うなら、まず組織管理の設定で既定を止め、対象アプリを決めてから開ける順番が安全です。
AIエージェントに権限を渡す設計を体系的に見たい場合は、こちらで3層に分けて整理しています。
私が画面操作の自動化から一度撤退した理由
ここが、この記事でいちばんお伝えしたい部分です。私は画面操作による自動化を本番で運用し、そのうち複数の経路を畳みました。
2026年5月4日、エディタの仕様変更で止まった
自分の発信基盤への投稿を、ブラウザ自動操作で動かしていました。それが2026年5月4日に停止します。原因は、投稿先のエディタが合成イベント（プログラムが作ったクリックやキー入力）を黙殺するようになったことでした。相手側の仕様変更で、こちらは何も変えていません。
対処として、実際にブラウザを物理的に動かす方式へ全面的に書き直しました。つまり「ちゃんと動いていた自動化が、ある日突然、告知なく死ぬ」のが画面操作の標準的な壊れ方です。
同じ性質の躓きは他にもありました。サムネイル設定でファイル選択ボタンを押すと OS 標準のダイアログが開くのですが、これはブラウザのウィンドウではないので操作できません。別経路でファイルパスを直接渡す方法で回避しました。画面操作は「画面に見えているなら操作できる」ように思えて、実際には扱える境界が細かく割れています。
APIがある経路は、すべてAPIに寄せた
2026年7月、長文記事の投稿をブラウザ自動操作から公式APIの直接呼び出しへ切り替えました。カバー画像も本文の挿絵も、太字やリンクまで API 経由で入ります。速く、確実で、壊れにくい——この差は体感で明確でした。
同じ月、ブラウザ経由で画像生成サービスの画面を操作していた仕組みも退役させました。判断の理由はシンプルで、「ブラウザ操作は手数も失敗率も高く、正規経路にする理由がない」。もう1つ、ブラウザで予約投稿を一括設定する仕組みも畳みましたが、こちらの退役理由は使用実績0回でした。作ったものの、結局一度も常用しなかったのです。
この経験から、私は運用の原則を1行に固定しました。公開APIがある相手にはAPIを使う。無い相手だけ画面操作にする。1つの仕組みに全部を詰め込まない。
速さは出る。問題は壊れ方だった
誤解のないように書きますが、画面操作の自動化は遅くありません。2026年7月3日に予約投稿の自動設定を検証したとき、1本あたり約30秒で通りました。最初の1本で30分ハマってから、56秒まで詰めた記録も残っています。躓いた箇所は3つで、接続の許可、プロファイルの指定、そして画面の読み違いでした。
それでも撤退した決定的な理由は、別にあります。検証中に別のアカウントへ投稿しかける事故が起きかけたのです。そのとき私が書き残した結論が、この記事の芯です。
「動くこと」より「間違ったときに止めること」の方が何倍も大事だと痛感した。アカウント名を毎回確認して想定と違えば止める、みたいな安全装置の方が本体だった。
加えて、精度が上がった今でも細かいUIを触らせる部分が一番壊れやすいという感覚は変わっていません。ここは人が握るか、握れないなら「止まる設計」で守るしかない領域です。
ツールを5つ試して、残ったのは2つだった
補足として、道具選びの経緯も書いておきます。2026年5月の時点で、私は画面操作・ブラウザ操作の自動化ツールを5種類ほど試していました。結果として常用に残ったのは2つだけです。残りは、動くけれど運用に乗らない、という理由で落ちました。
落ちた理由はおおむね共通していて、前提条件の多さです。特定のアプリが起動していること、リモート操作の許可が人の手で与えられていること、画面の表示言語が想定どおりであること——こうした条件が1つでも崩れると止まります。しかも止まったときにエラーが出るとは限らず、「何も起きない」形で失敗することがあります。
computer use を評価するときも、この観点が効きます。デモが動くかどうかではなく、前提条件がいくつあり、そのうち何個を人が毎回守る必要があるかを数えてください。
無人運用にならない、という構造的な制約
もう1つ、業務導入の現場で効いてくる制約があります。デスクトップ操作の自動化は、そのデスクトップアプリが開いていて、画面が存在していないと動きません。私はクライアントの業務自動化を検討する際、「ブラウザ自動化はデスクトップアプリが開いている必要があり無人運用にならない」という理由で、原理的に再現できない項目として分類しています。
夜間バッチのように人のいない時間に回したい処理は、画面操作では設計が成立しません。computer use は「人が席にいる時間の作業を速くする」機能であって、「人のいない時間に仕事をさせる」機能ではないと捉えるのが実務的です。
それでも画面操作が正解になる条件
ここまで厳しく書きましたが、私は画面操作を否定していません。実際に、建設会社の案件では画面操作を選択肢として正式に提示しています。条件を守れば成立する手段です。
順番を間違えない
建設会社に提示した3つの道と、その順番がそのまま判断フレームになります。
- まずベンダーに聞く（CSV取込やAPI提供の予定があるか）。これを最初にやる。1週間あれば答えが返ってきます
- 取込口があればCSVで入れる。指定の書式に自動変換して取り込む
- 取込口が無い画面だけ、画面操作を自動化する。ただし画面変更で止まり得るので、保守とセットにする
そして、どの道を選ぶ場合でも共通の前提が1つあります。渡す側のExcelを「機械が読める形」に整えるのが先です。列を統一し、1行1件にし、値の表記ゆれを揃える。ここが崩れていると、どんな自動化を載せても安定しません。
APIに穴があるときは、画面操作に戻す
API優先は教条ではありません。私は実際に、API から画面操作へ戻した判断を2回しています。
1つは機能の限界です。2026年7月25日、他人の投稿を引用する操作が無料階層のAPIでは許可されておらず、さらにURL埋め込み方式は画像・動画と排他だと分かりました。「引用と画像を同時に含む投稿」はAPIでは原理的に作れない。これは工夫で埋まる差ではないので、ブラウザ経路に戻しました。
もう1つはコストです。2026年9月28日の実測で、該当APIの単価はリンクなし投稿が0.015ドル、本文にURLを含む投稿が0.20ドルでした。毎日5本のツリーを出すと月30ドルになります。ログイン済みブラウザを使えば0ドルなので、こちらを選びました。
APIに穴がある（機能が無い・高すぎる）ときだけ画面操作に戻る。この順序を守れば、画面操作は最後の手段として健全に機能します。
「止まる設計」を納品条件まで持ち上げる
画面操作を業務に載せるなら、失敗の扱いを先に決めておく必要があります。私が実際に契約文面へ入れた一文がこれです。
業務ソフトへは、画面での入力を自動にして入れる。画面のしくみなどで自動で入れられない場合は、入れる一覧が画面の項目どおりにそろうことを完了の条件とし、金額は変えない。
画面操作は成功を約束しない——これを曖昧にせず、代替の完了条件まで書いておく。画面が変わった日に揉めないための設計です。あわせて「読めなかった書類は漏れなく『要確認』として担当者に通知が出る」ことも機能要件に入れました。ごまかさずに人へ渡す経路が、自動化の品質そのものになります。
Copilot を組織で使う際のガバナンス全般については、こちらでも整理しています。
中小企業が computer use を試す前のチェックリスト
導入検討で最初に確認すべき項目を、優先順に並べます。
- 自動化したい操作が1画面・1項目まで絞れているか。「業務を効率化したい」の粒度では評価できません
- 対象ソフトにCSV取込口やAPIが無いことを、ベンダーに確認したか。あるなら computer use を使う理由がありません
- その操作は、間違えても取り返せるか。確定・送信・決済を含む操作は「常に許可」にしない
- 人が席にいる時間に動かす前提で足りるか。無人の夜間実行が要件なら、この経路では設計が成立しません
- 止まったときに誰がどう気づくか。通知の経路を決めてから動かす
- 組織管理の設定で、全社の既定を止められる状態か。先に閉じて、必要な範囲だけ開ける
- 画面が変わって止まった場合の保守を、誰が持つか。ここが空欄なら、まだ本番に載せる段階ではありません
プレビュー機能である点も忘れないでください。まず壊れても困らない作業で試し、効果が確認できてから業務ラインへ寄せるのが順序です。
よくある質問
Linux では使えますか
公式 changelog の記載は macOS と Windows です。Linux についての言及はありません。
どのプランが必要ですか
changelog にはプランやライセンスの条件が書かれていません。二次情報では各プランで使えるとされていますが公式の裏が取れていないため、契約前に最新の公式ドキュメントで確認してください。
会社として一括で禁止できますか
公式に「組織管理の設定でこの機能を無効化できる」と明記されています。全社で止めてから対象を限定して開ける運用が可能です。
RPA の置き換えになりますか
部分的には重なりますが、同じものではありません。RPA は手順を固定して繰り返す前提で、止まり方も予測しやすい設計です。computer use は指示から手順を組み立てるぶん柔軟ですが、同じ指示でも毎回同じ経路を通る保証はありません。定型の大量処理ほど、固定された手順のほうが向きます。
うまく動かすコツはありますか
公式が挙げているのは「達成したい結果、関係するアプリ、重要な制約を説明する」ことです。私の経験を足すと、制約の部分に「この条件に合わなければ止まれ」を明示的に入れると事故が減ります。やってほしいことだけを書くと、想定外の画面でも何かしら操作しようとします。
まとめ
GitHub Copilot の computer use は、2026年10月1日にパブリックプレビューとして公開された、デスクトップアプリを操作する機能です。狙いは公式が明言しているとおり、API・CLI・MCP を持たないレガシーソフトやGUI専用ソフトの自動化にあります。「Excelを見ながら業務ソフトに手入力」が残っている現場には、確かに届く機能です。
一方で、私が画面操作の自動化を本番運用して得た結論は変わりません。相手の仕様変更で予告なく止まり、画面が開いていないと動かず、間違った操作も実行できてしまう。だから評価軸は「動くか」ではなく「止まるか」です。
順番としては、ベンダーに取込口を確認し、無ければCSV、それも無い画面だけを画面操作にする。保守と通知をセットにし、取り返せない操作は「常に許可」に入れない。この形を守れるなら、computer use は手入力の最後の一区画を埋める現実的な手段になります。私たちは、こうした判断の順番そのものを含めた中小企業のAI導入支援に取り組んでいます。
※本記事は2026年10月6日時点の情報です。computer use はパブリックプレビュー段階のため仕様が変更される可能性があります。導入判断の際は GitHub 公式ドキュメントで最新の内容をご確認ください。
御社の業務に合わせたCopilot導入・定着支援
「ライセンスを配ったのに使われない」を終わらせる。
業務の棚卸しから、効く業務の切り分け、社内への定着まで一貫して支援します。