Copilotが画面を操作、APIのない旧システムも対象に
2026年10月1日、GitHubはCopilot CLIとGitHub Copilot appに、デスクトップアプリを操作する「computer use」をパブリックプレビューとして追加しました。この記事では、公式の変更履歴とドキュメントで確認できる内容を整理します。そのうえで、APIのないソフトと付き合うことの多い新規事業やシステム開発にとって何が変わりうるかを、事実と編集部の見方を分けて書きます。
GitHub Copilotがデスクトップアプリを操作できるようになった
公式の変更履歴で確認できること
GitHubの変更履歴（Changelog）によると、computer useは、macOSとWindowsのGitHub Copilot CLIとGitHub Copilot appでパブリックプレビューとして使えるようになりました。Copilot CLIは、ターミナル（コマンドを入力する画面）から使うCopilotです。パブリックプレビューは、正式版の前に広く試せる段階を指す言い方です。
操作できる内容は、公式ドキュメントに具体的に書かれています。Copilotは、アプリの内容や画面の見た目を読み取り、ボタンのクリック、文字の入力と編集、キー操作、スクロール、ドラッグを行い、複数のアプリにまたがる作業の流れも進められます。読み取りの方法は、OSのアクセシビリティ（画面の読み上げ用の情報）の仕組み、または、視覚的な情報が必要なときはスクリーンショットとされています。
今回のポイントは、対象の広がりです。変更履歴は、API・コマンドライン・MCP連携のいずれもない、古いソフトや画面操作しかできないソフトの作業も、Copilotが自動化を手伝える範囲に入ると説明しています。MCPは、AIが外部のツールやデータとつながるための共通の取り決めです。公式の例としては、Safariで経費精算の流れをたどる場面が示されています。
動かせる範囲と、止め方
権限まわりの設計も、あわせて確認しておきます。
- computer useは初期状態では無効で、エージェントが使う前に有効にする必要があります。
- アプリを操作する前にCopilotが承認を求め、「常に許可」にしたアプリは見直したりリセットしたりできます。
- 「常に許可」の判断はローカルに保存され、同じコンピューターのCLIとアプリの両方に適用されます。
- 許可の記録を削除しても、すでに動いているセッションに与えた権限は取り消されません。
- ツールを拒否する権限ルールは、自動承認や保存済みの承認より優先されます。
また、セキュリティ面の説明では、computer useを有効にすると、Copilot CLIは作業ディレクトリの範囲の外にあるデスクトップアプリとも対話できるとされています。ファイルの範囲を絞る従来の考え方とは、守る対象が変わる点です。
さらに、公式ドキュメントは、画面に見える内容をCopilotに文脈として渡してよいアプリと作業に限って使うことを案内しています。
「APIがない」ことが、自動化をあきらめる理由ではなくなる
ここからは、事実ではなく、JustFit編集部としての見方です。
見方1：外部のシステムとつなぐ試作の壁が、少し低くなるかもしれない
新規事業では、立ち上げ初期に、すでに使われている業務ソフトや取引先のシステムと、何らかの形でつながりたい場面がよくあります。ところが、相手がAPIを公開していないと、「つなぐための開発」が先に必要になり、事業の検証が始まる前に時間を使ってしまいます。
画面を操作できるAIエージェントが開発の現場に入ると、「まずは画面越しに動かして、事業として成り立つかを見る」という選択肢が生まれます。もちろん、本番の連携として十分かどうかは別の話です。ただ、検証の段階で、つなぎ込みの完成を待たずに動く姿を見られるようになる可能性があります。
見方2：画面を通した動作確認が、開発の一部になりうる
公式の変更履歴は、経費精算の流れのような、画面をたどる作業を例に挙げています。システム開発の側から見ると、「作ったものを実際の画面で触って確かめる」作業にも同じ考え方が使える場面がありそうです。ただし、これは今回の公式発表に書かれている使い方ではなく、私たちの想像です。実際にどこまで安定して使えるかは、試して確かめる必要があります。
見方3：システムが事業そのものになる領域では、「どこまで任せるか」が設計の中心になる
システムが事業そのものになる新規事業では、AIが人の代わりに画面を操作する範囲が、そのままサービスの設計になります。何をAIに任せ、どこで人が確認するかを、要件として早めに決めておく必要が出てきます。要件の考え方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方でも整理しています。
承認の仕組みが用意されていること自体は、安心材料です。一方で、承認の画面に慣れて「常に許可」が増えていくと、確認の意味が薄れていきます。「AIが書いた・動かした」ことより、「誰が何を確認したか」を残せる運用が重要になる、というのが私たちの見方です。この点は、AI開発でも品質には人の確認が必要な理由とも重なります。
同じ週に出た「ワークフロー」との違い
Copilotには同じ10月1日に、別の機能も加わっています。複数のAIエージェントの進め方をコードで定義する「dynamic workflows」です。こちらについては、別の記事のKiro・Copilotのワークフロー｜開発と新規事業への影響で扱いました。
ざっくり分けると、dynamic workflowsは「作業の進め方を決める」機能で、computer useは「AIが触れる相手を増やす」機能です。両方を組み合わせられるかどうかについては、今回確認できた公式情報には書かれていません。そのため、ここでは別々の機能として扱います。
使う前に確かめておきたい点
- プレビュー段階であること：本番の業務で使う前に、挙動と範囲をテスト用の環境で確かめるのが現実的です。
- 対応環境：公式の変更履歴で確認できるのは、macOSとWindowsのCopilot CLIとCopilot appです。
- 画面に映る情報の扱い：ドキュメントが案内しているとおり、画面の内容が文脈としてCopilotに渡されます。個人情報や取引先の情報が映る画面で使うかどうかは、事前に決めておきたい点です。
- 人の確認を置く位置：送信・削除・支払いのような、取り消しにくい操作をAIに任せるかどうかは、承認の設定を見ながら慎重に決める必要があります。
- AIツールの選び方：どのツールが向くかは、作る内容や進め方によって変わります。比較は、AIコーディングツール比較｜特徴と向く使い方｜2026年10月を参考にしてください。
まとめ
GitHub Copilotに加わったcomputer useは、デスクトップアプリの画面を読み取り、クリックや入力を行う機能です。APIのない古いソフトや画面操作しかできないソフトも、自動化を手伝える範囲に入ると公式の変更履歴で説明されています。初期状態では無効で、操作の前に承認を求める仕組みがあり、現時点ではパブリックプレビューです。
新規事業やシステム開発の側から見ると、「APIがないから試せない」という前提が少し動く可能性があります。一方で、AIが触れる範囲が広がるほど、「何を任せ、どこで人が確認するか」を決める作業の重みは増していきます。プレビュー段階の機能は、小さく試して挙動を確かめてから、使う場面を広げていくのが良さそうです。
JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく受託開発サービスです。システムそのものが事業になるような新規事業を得意としていますので、AIが担う範囲を含めて形を考えたいときは、JustFitのサービス紹介もご覧ください。