はじめに
背景：Vibe Codingで「確認」がボトルネックになった
ここ数か月、GitHub Copilotを使ってVibe Codingをしています。
その中で、最近ちょっと違和感がありました。
コードを書いている時間より、動作を確認している時間の方が長くなっていないか?
というものです。
私が今作っているのは、Windows上で動くアプリケーションです。
基本的な機能はかなり出来てきました。
そうなると、次に必要なのは当然テストです。
例えば設定項目があったとして、
- ONの場合
- OFFの場合
- 設定AがON、設定BがOFFの場合
- 設定Aと設定Bが両方ONの場合
などを確認していきます。
設定項目が増えると、当然組み合わせも増えます。
人が画面を開いて、設定を変えて、ボタンを押して、結果を確認する。
そしてまた設定を変える。
正直、地味です。
そして時間がかかります。
Vibe Codingでは、機能追加そのものはかなり速くなりました。
私自身がコードを全部書いているわけではないので、実装についてはGitHub Copilotがかなり進めてくれます。
ところが。
出来上がったものが、本当に期待した通り動くのか?
これは確認しないといけません。
結果として、開発全体で見ると「作る」より「確認する」に時間を使うようになってきました。
私の感覚では、最近は開発時間のかなりの部分をテストや確認に使っています。
これが今回の記事を書こうと思ったきっかけです。
この記事で試すこと
そして、
この画面操作そのものを、GitHub Copilotにやらせることは出来ないのか?
と考えるようになりました。
この記事で試したいのは、GitHub Copilotを単なるコード生成の支援としてではなく、Shell、Python、PowerShell、MCPなどのToolを組み合わせて、PC上の作業まで進めるAgentとして扱えるかどうかです。
前提と注意事項
この記事は、私が現在試しているGitHub Copilot CLI / GitHub Copilot Chatの使い方を整理したものです。
私個人の見解であり、所属する企業・組織を代表するものではありません。また、GitHub Copilot CLIをRPA製品として使うことを推奨する記事ではありません。
今回のテーマは、GitHub CopilotからShell、Python、PowerShell、MCPなどを組み合わせた場合に、どこまでPC上の作業を任せられるのか、というExperimentです。
OS上でコマンドやアプリケーションを動かす場合、権限の扱いは重要です。
GitHub Copilot CLIにはTool、Path、URLなどに対するPermissionの仕組みがあります。権限を広げる設定もあるため、まずは開発機、検証環境、Sandboxなど、影響範囲を理解できる環境で試す前提で考えます。
--allow-all や --yolo のように広いPermissionを許可する設定を、便利だからという理由だけで常用する前提ではありません。
Local Sandboxを無効にしている場合、Copilotが実行するShell CommandはLocal PC上でUser Accountと同等のAccessを持ちます。重要な環境では、対象Path・Tool・URLを絞り、必要なHuman Approvalを残すことが重要です。
1. GitHub Copilotを「PC作業を進めるAgent」として捉える
ここで一度、整理してみます。
今回の話では、
GitHub Copilot CLIそのものに、一般的なRPA製品と同じGUI操作機能が全部入っている
と考えると、少し話がおかしくなります。
そうではありません。
GitHub Copilot CLIは、Shellやファイル操作などのToolを利用できます。
さらにMCP Serverを追加して、外部ToolやData Sourceへ機能を拡張することもできます。
GitHubの公式ドキュメントでも、MCP Serverの例としてPlaywright MCPを、
npx @playwright/mcp@latest
で追加する例が紹介されています。
つまり、私の理解ではこんな構造です。
Prompt
↓
GitHub Copilot CLI
↓
判断・計画
↓
Shell / Python / PowerShell / MCP / Tool
↓
Browser / File / Application / OS
私は、ここが今回のポイントだと思っています。
GitHub Copilot CLIを「コードを書いてくれるもの」だけとして見ると、利用範囲はSource Codeの周辺になります。
一方、
目的を達成するためにToolを選び、実行するAgent
として見ると、少し見え方が変わります。
1.1 Browser操作はPlaywrightで考える
Web ApplicationのTestであれば、Playwrightがあります。
PlaywrightはChromium、Firefox、WebKitなどのBrowserを操作でき、Web Pageを開いたり、入力したり、Buttonを押したり、Screenshotを取得したりできます。
例えば、
Browserを起動
↓
Web Applicationを開く
↓
入力欄へ値を入力
↓
Buttonを押す
↓
結果を確認
↓
Screenshotを保存
というTestを自動化できます。
GitHub Copilot CLIにPlaywright MCPを追加すれば、
GitHub Copilot CLI
↓
Playwright MCP
↓
Browser
↓
Web Application
という構成も作れます。
これは非常に分かりやすいです。
ただ、私が作っているApplicationはWindowsのDesktop Applicationです。
ここで話が変わります。
PlaywrightはBrowser AutomationのToolです。
Windowsのメモ帳や、一般的なDesktop Applicationをそのまま操作するためのToolではありません。
そこで、
Browserの外の操作も、別のToolを使わせればいいのではないか?
と思いました。
1.2 Repositoryの外とLocal OSへのアクセス
私はしばらくGitHub Copilotについて、
Repositoryの中にあるCodeやFileは操作できるけれど、その外は基本的に触れない
くらいのイメージで使っていました。
でも、GitHub Copilot CLIの仕組みを改めて確認すると、少し違います。
デフォルトではPath Accessが制御されていますが、Repositoryという論理的な境界だけで動いているわけではありません。
GitHub Copilot CLIでは、現在のWorking Directoryとその配下などがデフォルトのAccess範囲ですが、必要なPathを明示的に許可できます。
そしてShell Commandも実行できます。
となると、
GitHub Copilot CLI
↓
PowerShell
↓
Application起動
や、
GitHub Copilot CLI
↓
Python
↓
OS / Application操作
も考えられます。
もちろん、ここから先はGitHub Copilot CLI単体のGUI Automation機能ではありません。
OSや外部Toolとの組み合わせです。
でも、私はむしろそこが面白いと思いました。
1.3 Coding AgentではなくOrchestratorとして見る
普段GitHub Copilotを使っていると、どうしても、
Codeを書いてもらうもの
として見てしまいます。
実際、Software Developmentが主な用途です。
ただ、ShellやMCPを使えるAgentとして考えると、見え方が変わります。
Codeを書くこと自体が目的ではありません。
目的を達成するために必要ならCodeを書く。
必要ならShellを実行する。
必要ならBrowserを操作する。
必要なら別のApplicationを起動する。
つまり、
Applicationを作る
↓
起動する
↓
操作する
↓
結果を見る
↓
問題があれば修正する
↓
再度起動する
↓
Screenshotを撮る
↓
Documentを作る
までを、一つのTaskとして考えられる可能性があります。
実務では、この違いは結構大きいと思っています。
Code Generationだけ速くなっても、その後に人が大量の確認作業をしているのであれば、工程全体としてはそこが次のボトルネックになるからです。
1.4 「OSで動くCode Interpreter」という比喩
ここまで試していて、私の中でGitHub Copilot CLIの見え方がもう一つ変わりました。
これ、ある意味では「OSで動くCode Interpreter」なのではないか?
と思ったんです。
もちろん、GitHub Copilot CLIとOpenAIのCode Interpreterは別の仕組みです。
OpenAI APIにおけるCode Interpreterは、Promptへの応答を生成するためにPython Codeを実行するToolとして提供され、その実行にはContainerが使われます。
一方、GitHub Copilot CLIはローカルPC上で動きます。
でも、私が今回の実験をしている時の動きを見ていると、かなり似た構造に見える場面がありました。
例えば、
私がPromptでやりたいことを書く
↓
GitHub Copilotが方法を考える
↓
Python Codeを作る
↓
そのPythonを実行する
↓
Local PC上のApplicationやFileを操作する
↓
結果を確認する
という動きです。
ここで面白いのは、
Python Codeそのものを私が書いているわけではない
ことです。
私は例えば、
メモ帳を起動して、この文字を入力して保存してください
とか、
Applicationを起動して、この画面を操作してScreenshotを取得してください
といった「やりたいこと」をPromptで書きます。
するとAgent側が、必要に応じてPythonなどを使う方法を考え、Codeを作り、実行する。
もちろんGitHub Copilot CLIはPython専用ではありません。
実際にはPowerShellやShell Command、MCP Toolなどを選択する場合もあります。
ですので、より一般化すると、
Intent
↓
Prompt
↓
Tool / Code Generation
↓
Execution
↓
Result
という構造です。
これは、Code Interpreterを使っている時の感覚に少し似ています。
ただし、大きな違いがあります。
実行場所です。
かなり乱暴に整理すると、
Code Interpreter
Prompt
↓
LLM
↓
Python
↓
Container
に対して、
GitHub Copilot CLI
Prompt
↓
LLM
↓
Python / PowerShell / Shell / MCP / Tool
↓
Local OS
↓
自分がAccessできるResource
という違いがあります。
ここは結構大きいです。
GitHub Copilot CLIのLocal Sandboxを無効にしている場合、Shell Commandは自分のUser Accountと同等のAccessでLocal Machine上に実行されます。逆にLocal Sandboxを有効にすれば、FilesystemやNetworkなどを制限できます。
GitHub Copilot CLI = Code Interpreterという意味ではありません。
これは正式な製品分類ではなく、私が仕組みを理解するための比喩です。
ただ、
Promptから、その場で必要なCodeやToolを選び、それを実行してEnvironmentへ作用させる
と考えると、私にはかなりしっくりきました。
そして「Interpreterが動く場所」を自分のOSまで広げて考えると、対象も変わります。
PythonやShell、CLIなどから扱えるものであれば、
- File
- Process
- Application
- Network
- Browser
- Database
- Local API
- CLI Tool
なども対象になる可能性があります。
すると、
GitHub Copilotに何のCodeを書いてもらおう?
ではなく、
自分のPCでやりたいことを実現するために、Agentに何のToolを使わせよう?
という発想になります。
私は、この違いはかなり大きいと思っています。
1.5 Verificationまで含めてHarnessを設計する
この話を考えていて、Harness Engineeringにもつながりました。
OpenAIが2026年2月に公開したHarness Engineeringの記事では、Engineerの仕事を単にCodeを書くことだけではなく、Agentが仕事をしやすいRepository、Tool、Feedback Loop、Test、Documentationなどの環境を整える方向へ広げて考えています。実際、その事例ではApplication Logicだけではなく、Test、CI、Documentation、Monitoring、Internal ToolまでAgentによって生成されています。
私は「Harness」という言葉を、単なるPromptの書き方とは考えていません。
例えば、
Specification
Tool
Test
Log
Screenshot
Build
CI
Review
Permission
Documentation
などを含めて、
Agentが仕事を進め、結果を確認できる環境
だと理解しています。
Agentに、
Testしてください
とだけ伝えても、Applicationを操作するToolがなければ出来ません。
逆に、AgentがApplicationを起動し、画面を操作し、結果を確認し、Screenshotを保存できるのであれば、TestまでAgentのWorkflowに含められる可能性があります。
これはVibe Codingとも相性がよいと思っています。
ImplementationをAgentに任せるなら、
VerificationもAgentが実行しやすいようにHarnessを作る。
私は、この方が自然です。
2. Computer Useの流れとGitHub Copilotの位置づけ
2.1 Computer Useという流れ自体は、すでに始まっている
この発想自体は、GitHub Copilotだけにあるものではありません。
Anthropicは2024年10月にClaudeのComputer UseをPublic Betaとして公開しました。
Claudeが画面を見て、Cursorを動かし、ButtonをClickし、Keyboard入力するという、人がComputerを使う時に近い操作をModelから行えるものです。
OpenAIも2025年1月にOperatorを公開しました。
Operatorは専用Browserを使ってWeb上の操作を実行するAgentとして登場し、2025年7月にはその主要機能がChatGPT agentへ統合されました。ChatGPT agentはVirtual Browserだけではなく、Code実行や外部Data Sourceなども組み合わせてTaskを実行する仕組みへ広がっています。
Microsoft Edgeにも Browse with Copilot があります。
以前はCopilot Actions in Edgeと呼ばれていたもので、CopilotがBrowser上で選択、Scroll、Typing、Tab Navigationなどを行います。人はその動作を確認し、途中でControlを戻すこともできます。
つまり、
AIが回答する
だけではなく、
AIがToolを使う
さらに、
AIがComputer上で作業する
という方向へ進んでいます。
これはもう、一部の特殊な研究だけの話ではなくなってきています。
2.2 GitHub Copilot CLIで面白いのはLocal PCとの距離
その中で、私がGitHub Copilot CLIに興味を持った理由は、
Local PCとの距離の近さ
です。
Shellがあります。
Fileがあります。
MCPがあります。
既存のCLI Toolも使えます。
PythonやPowerShellも使えます。
そして、必要であればLocal OS上のProcessを起動できます。
この違いは、実務では結構大きいと思っています。
仕事は、Browserだけで全部終わることの方が少ないですよね。
例えば経費精算。
私の場合をかなり単純化すると、
Outlook
↓
予定を確認
Mail
↓
領収書を探す
OneDrive / Local File
↓
画像やPDFを確認
Web
↓
交通費などを確認
Expense Application
↓
情報入力・File添付
という感じです。
一つひとつはそれほど難しい処理ではありません。
ただし、Applicationをまたぎます。
典型的なRPAの対象だと思います。
もちろん経費申請であれば、
金額の判断から最終Submitまで全部Agentへ任せる
というのは別の話です。
私は、まずそこまでやらなくてもよいと思っています。
例えば、
必要な情報を集めて、申請のDraftを作るところまで
でも十分です。
実務では話が変わることが多いです。
100% Automation出来ないから価値がない、ではありません。
人が30分かけていた作業を、5分のReviewに出来れば十分意味があります。
3. Experiment 1：オセロゲームと子ども向けマニュアルを自動作成
3.1 実験の狙い
最初は、小さな実験から始めます。
Web Browserで動くオセロを作ります。
ここまでは普通です。
でも今回は、あえて途中にWindowsのメモ帳を入れています。
やらせたいことは、
オセロを作成
↓
メモ帳を起動
↓
HTMLを貼り付け
↓
index.html として保存
↓
Browserを起動
↓
オセロを操作
↓
Screenshot取得
↓
操作Manual作成
です。
なぜメモ帳を入れたのか。
Browserの中だけで完結させたくなかったからです。
Playwrightだけであれば、Browser内でかなりのことが出来ます。
今回確認したいのは、
Browser Automationではなく、PC上のWorkflow全体をAgentが扱えるのか?
です。
GitHub Copilot Chatに自然言語の作業手順を渡し、デスクトップ操作を含む一連のタスクをどこまで自動化できるか試しました。
3.2 使用したPrompt
以下は実験で使用したPromptの原文です。
再現性を優先し、誤字なども修正せず、実験時のPromptをそのまま掲載しています。
実験で使用したPrompt全文を開く
これらか実行する全ての画面のスクリーンショットを取得して`/screen/{yyyymmdd-hhmm(時間)}-{画面の説明-nn:連番}.png`として保存をしてください。
Webブラウザーで動く、私とあなたが戦うオセロゲームを作成してください。あなたの強さは初級/中級/上級があって、私がそれを選択できるようにしてください。その後で、新規でメモ帳を起動して、作成したオセロゲームのHTMLの文字列を、コピペしてください。その後、それをデスクトップに`index.html`として保存をしてください。メモ帳は起動したままにしてください。
その後で、ブラウザーを起動して、作成した`index.html`を表示させます。起動したブラウザーを使って、初めてオセロをする、5-6歳の子ども向けの「オセロの遊び方」のチュートリアルのドキュメントを、画面のスクリーンショットをとりながら、作成をしてください。作成したマニュアルはデスクトップに`オセロマニュアル`フォルダーを作成して、そこに全て保存をしてください。
3.3 実行結果
今回のゴールは、ブラウザーで遊べるオセロゲームを作り、HTMLをメモ帳経由でデスクトップへ保存し、さらに5〜6歳向けの遊び方チュートリアルまで作成することです。ゲーム生成だけでなく、アプリの起動、ファイル保存、ブラウザー操作、スクリーンショット取得、マニュアル作成までを一つのプロンプトで実行します。
3.3.1 作業フォルダーを準備する
最初にエクスプローラーで C:\Work\GithubCopilotAsRPA を開き、成果物用の GithubCopilotAsRPA-オセロ フォルダーと images フォルダーを作成しました。
3.3.2 指示文をメモ帳からコピーする
デスクトップの GithubCopilot as RPA-Playweight-オセロ.txt をメモ帳で開き、全文を選択してクリップボードへコピーしました。指示には、次の作業が含まれています。
- 初級・中級・上級を選べるオセロゲームの作成
- HTML全文を新しいメモ帳へ貼り付け、デスクトップへ
index.htmlとして保存 - ブラウザーでゲームを起動
- 実際にゲームを操作しながらスクリーンショットを取得
- 5〜6歳向けの「オセロの遊び方」チュートリアルを作成
3.3.3 VS Codeで新しいチャットエディターを開く
Visual Studio Code上部のCopilot Chatメニューから［新しいチャット エディター］を選択しました。通常のサイドバーではなく、エディター領域全体を使えるため、長いプロンプトや実行ログを追いやすくなります。
新しいチャットは、入力欄だけが表示されたシンプルな状態で起動します。
3.3.4 プロンプトを貼り付け、モデルをAutoにする
メモ帳からコピーした全文をチャット入力欄へ貼り付けました。複数段落の指示も、そのまま保持されています。
続いてモデル選択を［Auto］へ切り替えます。これにより、Copilotがタスクに合わせて利用モデルを選択します。
送信すると、チャット名は「オセロゲームとマニュアル作成」に変わり、タスクの解析と実行が始まりました。
3.3.5 生成されたオセロゲーム
Copilotは単一の index.html にHTML、CSS、JavaScriptをまとめたオセロゲームを生成しました。開始画面では、対戦相手の強さを［初級］［中級］［上級］から選択できます。
ゲームには、8×8の盤面、得点表示、着手可能位置の黄色いヒント、パス判定、終局判定が実装されています。プレイヤーは黒、コンピューターは白です。
AIの挙動も難易度ごとに変わります。
- 初級：着手可能な場所からランダムに選択
- 中級：その手で最も多く石を返せる場所を選択
- 上級：盤面評価と深さ4のminimax探索、αβ枝刈りを使用
3.3.6 子ども向けチュートリアルも作成
Copilotはゲームを実際に操作して、開始画面、初期盤面、石を挟んだ場面、コンピューターの応答、ゲーム中盤などを撮影しました。その画像を使い、デスクトップの オセロマニュアル フォルダーへ オセロのあそびかた.html を生成しています。
完成したチュートリアルは、ひらがな中心の文章、大きな文字、色分けされた見出しを使った幼児向けのデザインです。「黄色い丸をクリックする」「相手の石を挟む」といった操作を、段階ごとに説明します。
3.3.7 複数アプリを重ならないように配置
最後に、エクスプローラー、ゲーム画面、チュートリアル、2つのメモ帳、VS Codeを3列×2段へ配置しました。メモ帳は表示倍率を40%に調整し、各画面が重ならず内容も判読できる状態にしています。
3.4 実行して分かったこと
今回の操作では、GitHub Copilot Chatがコード生成だけでなく、次のようなデスクトップ作業を連続して扱えることを確認できました。
- 複数アプリをまたぐ作業手順の理解
- HTML/CSS/JavaScriptによるアプリ生成
- メモ帳への貼り付けとファイル保存
- ブラウザーでの動作確認とゲーム操作
- 画面キャプチャを使った別ドキュメントの作成
- OneDriveへリダイレクトされた実際のデスクトップパスの検出と修正
特に印象的だったのは、途中で狭いブラウザー表示による文字の折り返しを検出し、ウィンドウを広げてスクリーンショットを撮り直した点です。RPAでは画面サイズやDPIの違いが失敗要因になりがちですが、結果を見ながら修正するエージェント型の動作が有効でした。
完成したマニュアル。
3.5 Experiment 1のまとめ
一つの自然言語プロンプトから、オセロゲーム、動作確認、スクリーンショット、子ども向けチュートリアルまでをまとめて作成できました。定型的なクリック操作だけでなく、生成結果を評価し、必要に応じて撮り直しや保存先の修正まで行える点は、従来型RPAとの大きな違いです。
GitHub Copilot Chatを「コードを書くアシスタント」だけでなく、「アプリとデスクトップを横断して成果物を完成させる作業エージェント」として使う可能性を感じる検証となりました。
4. Experiment 2：Machine LearningからGUI、Test、Manualまでやらせる
4.1 実験の狙い
次は、もう少し長いWorkflowです。
Machine Learningの小さなApplicationを作らせます。
題材はNew York City Taxi and Limousine Commission、正式には TLC が公開しているTaxi Trip Record Dataです。
TLCはYellow TaxiやGreen TaxiなどのTrip Record Dataを公開しています。現在の大規模なTrip Record FileはParquet形式で提供され、データは月単位で公開されています。
ここではMachine Learningそのものが主目的ではありません。
見たいのは、その前後です。
Data取得
↓
前処理
↓
Model学習
↓
評価
↓
Model保存
↓
推論Code
↓
GUI Application
↓
Application起動
↓
画面操作
↓
正常系Test
↓
異常系Test
↓
Screenshot
↓
Manual
実務のApplication Developmentは、Modelを作ったところでは終わりません。
End Userが使えるようにする必要があります。
そして動作確認も必要です。
場合によってはManualも必要です。
そこで今回は、
小さなSoftware Development Project全体を一つのTaskとして扱えるのか
を試します。
4.2 使用したPrompt
こちらも実験で使ったPromptを原文のまま掲載します。
Prompt中では NYCT や NYT という表記が混在していますが、正式には NYC Taxi & Limousine Commission（TLC） です。
実験時の再現性を優先し、Prompt本文自体は修正していません。
実験で使用したPrompt全文を開く
これらか実行する全ての画面のスクリーンショットを取得して`/screen/{yyyymmdd-hhmm(時間)}-{画面の説明-nn:連番}.png`として保存をしてください。
C:\Workフォルダーを作業フォルダーとして使用し、そこからVisual Studio Codeを起動してください。
Visual Studio Code上で、Pythonを使用してNYCT（NYC Taxi & Limousine Commission - yellow taxi trip records）が公開しているオープンデータまたは公開APIのデータを取得・分析し、そのデータを利用した機械学習モデルを作成してください。
最初に、今回の機械学習で扱う目的を明確にしてください。NYCTの公開データの中から機械学習に適したデータを選択し、使用するデータの概要、予測対象、説明変数、機械学習の方式を決めてください。
その後、C:\Work配下に今回のプロジェクト用フォルダーを作成し、Visual Studio Codeでそのフォルダーを開いてください。
必要に応じてPythonの仮想環境を作成し、機械学習やデータ処理に必要なPythonパッケージをインストールしてください。また、再現できるように必要なパッケージをrequirements.txtにも保存してください。
次に、NYCTの公開データを取得するPythonコードを作成してください。APIキーなどの認証情報が必要な場合は、ソースコードへ直接埋め込まず、環境変数や.envファイルなどを利用して安全に管理できる構成にしてください。
取得したデータについて、欠損値、データ型、件数、特徴量などを確認し、機械学習で利用できるように前処理してください。
そのデータを学習用データと評価用データに分割し、Pythonの機械学習ライブラリを利用してモデルを学習してください。
学習後はモデルを評価し、使用した評価指標と評価結果を分かりやすく表示してください。また、作成した学習済みモデルをファイルとしてC:\Work配下のプロジェクトフォルダーへ保存してください。
機械学習モデルを作成するコードは、たとえば以下のように役割ごとに分割してください。
- データを取得するコード
- データを前処理するコード
- モデルを学習・評価するコード
- 学習済みモデルを保存するコード
続いて、保存した学習済みモデルを読み込み、新しい入力データに対して予測を行う推論用のPythonコードを作成してください。
推論コードについても実際にVisual Studio Codeのターミナルから実行し、正常にモデルが読み込まれ、サンプルデータに対して推論結果が表示されることを確認してください。
さらに、この推論機能をプログラマーではないエンドユーザーでも利用できるアプリケーションにしてください。
エンドユーザーがPythonコードを直接編集しなくても利用できるように、入力項目、実行ボタン、推論結果の表示領域を備えた分かりやすいユーザーインターフェイスを作成してください。Pythonで実装できる適切なアプリケーションフレームワークを選択して構築してください。
アプリケーションを実際に起動し、以下の一連の操作が正常に行えることを確認してください。
1. アプリケーションを起動する
2. 推論に必要なデータを入力する
3. 推論を実行する
4. 機械学習モデルによる推論結果を確認する
5. 入力内容を変更して再度推論する
6. エラーとなる入力を行った場合に、ユーザーに分かりやすいメッセージが表示されることを確認する
アプリケーションの動作確認が完了したら、初めてこのアプリケーションを利用するエンドユーザー向けの操作マニュアルを作成してください。
マニュアルでは、実際に起動したアプリケーションを操作しながら必要な画面のスクリーンショットを取得し、そのスクリーンショットを使って操作方法を説明してください。
マニュアルには少なくとも以下の内容を含めてください。
- このアプリケーションでできること
- アプリケーションの起動方法
- メイン画面の説明
- 各入力項目の意味
- データの入力方法
- 推論の実行方法
- 推論結果の見方
- 入力例
- 正常な推論結果の例
- エラーが発生した場合の対処方法
- アプリケーションの終了方法
- よくある質問
- 利用上の注意事項
各操作手順について、「どこを操作するのか」がエンドユーザーに分かるように、対応するスクリーンショットを配置して説明してください。
C:\Work配下に「MLアプリケーションマニュアル」フォルダーを作成し、作成したマニュアルとマニュアルで利用するすべてのスクリーンショットを、そのフォルダー内に保存してください。
最終的にC:\Work配下のプロジェクトフォルダーには、少なくとも以下が残るようにしてください。
- NYTのデータを取得するPythonコード
- データ前処理用のPythonコード
- 機械学習モデルを学習するPythonコード
- 推論用のPythonコード
- エンドユーザー向け推論アプリケーションのコード
- 学習済み機械学習モデル
- requirements.txt
- README.md
- MLアプリケーションマニュアル
- マニュアル用スクリーンショット
README.mdには、プロジェクトの目的、使用したNYTデータの概要、フォルダー構成、環境構築方法、必要なPythonパッケージ、APIキーなどが必要な場合の設定方法、モデルの学習方法、推論コードの実行方法、アプリケーションの起動方法を記載してください。
最後に、Visual Studio Codeのターミナルから、データ取得、前処理、モデル学習、モデル保存、推論、エンドユーザー向けアプリケーション起動までの一連の処理を実際に実行し、正常に動作することを確認してください。
実行中にエラーが発生した場合は、原因を調査してコードや設定を修正し、正常に動作するところまで確認してください。
4.3 実行結果
定型的なクリック操作を再生する従来型RPAではなく、自然言語でゴールを渡し、状況に応じて作業内容を判断する「エージェント型RPA」としてGitHub Copilotを使ってみました。
今回の依頼は、NYC TLC（New York City Taxi & Limousine Commission）の公開データを取得し、前処理、モデル学習、推論、Streamlit製GUI、操作マニュアルまで用意して動作確認するというものです。長い指示文をメモ帳からGitHub Copilot Chatへ渡し、モデル選択をAutoにして実行しました。
画面が重ならないよう、Explorer、メモ帳、Visual Studio Codeは操作のたびに対象ウィンドウを最大化しました。撮影画像は論理解像度1920×1280、Windowsの表示スケールを反映した実画像2400×1600で保存しています。
4.3.1 作業フォルダーをExplorerで開く
最初に、OSのExplorerでC:\Work\GithubCopilotAsRPAを開きました。今回の記事とスクリーンショットの保存先であるGithubCopilotAsRPA-MLフォルダーも、この中に作成しています。
4.3.2 メモ帳から依頼文をコピーする
デスクトップのGithubCopilot as RPA-ML-NYT.txtをメモ帳で開き、本文をすべて選択してクリップボードへコピーしました。依頼文には、次の作業が含まれています。
- NYC TLCの公開データ取得とデータ確認
- 欠損値処理、特徴量作成、学習・評価データへの分割
- 機械学習モデルの学習、評価、保存
- 保存済みモデルを使うCLI推論
- 非プログラマー向けGUIアプリ
- 正常系、再推論、異常入力の動作確認
- READMEとスクリーンショット付き操作マニュアル
なお、原文ではNYCTやNYTという表記も混在していましたが、Copilotは文脈から正しい公開元であるNYC TLCを特定しました。
4.3.3 C:\WorkからVisual Studio Codeを起動する
C:\Workを作業フォルダーとして、新しいVisual Studio Codeウィンドウを起動しました。画面下部のターミナルでもカレントディレクトリがC:\Workであることを確認できます。
4.3.4 新しいチャットエディターを開く
Visual Studio Codeのバージョンによってメニュー構成は変わります。今回の環境では、通常の「ファイル」メニュー内に「新しいチャット エディター」はありませんでした。
また、座標だけに頼ったGUI操作では、WindowsのDPIスケーリングによって意図した場所からずれ、コマンドセンターが開く場面もありました。これは画面認識や操作後の状態確認が、RPAに欠かせない理由をよく示しています。
GUI Automationでは、座標だけでなく、操作後の画面状態やアクティブウィンドウを確認する仕組みが重要です。
この環境での正しい入口は、タイトルバー上部にあるチャットアイコン横のドロップダウンです。ここから「新しいチャット エディター」を選択しました。
新しいチャットがエディター領域に開き、長い依頼文を扱える状態になりました。
4.3.5 プロンプトを貼り付ける
メモ帳でコピーした依頼文を、チャットエディター下部の入力欄へ貼り付けました。送信前に末尾まで入っていることも確認しています。
4.3.6 モデルをAutoにする
入力欄下部のモデル名をクリックすると、利用可能なモデル一覧が表示されます。今回は先頭のAutoを選びました。
モデル欄がAutoに変わったことを確認してから送信します。個別モデルを固定せず、GitHub Copilotにタスクに適したモデル選択を任せる設定です。
4.3.7 プロンプトを実行する
青い送信ボタンを押すと、チャット名が「機械学習アプリケーション作成」に変わり、Copilotが処理を開始しました。停止ボタンが表示されているため、実行中であることも分かります。
4.3.8 Copilotが確認した成果
今回の環境にはC:\Work\RPA_nyc-taxi配下に既存成果物がありました。Copilotは無条件に作り直すのではなく、内容を調査し、CLI推論とStreamlit起動を再実行して、要件を満たしていることを確認しました。これは再実行しても成果物を壊しにくい、エージェント型自動化の利点です。
最終画面で確認できた内容は次の通りです。
- データ: NYC TLC Yellow Taxi Trip Records（2024年1月、APIキー不要）
- 予測対象:
fare_amount（運賃） - 方式:
RandomForestRegressorによる回帰 - 学習データ: 最大20万件のサンプル
- 評価結果: MAE 1.97 USD、RMSE 4.27 USD、$R^2=0.936$
- CLI推論: サンプル入力に対して20.74 USDを出力
- GUI: Streamlitが
http://localhost:8501で正常起動 - 実装:
data_fetch.py、preprocess.py、train.py、predict.py、app.py - 成果物: 学習済みモデル、
requirements.txt、README.md - マニュアル: 操作マニュアルと5枚のアプリ画面
完成した、エンドユーザー向けマニュアル。
4.4 GitHub CopilotをRPAとして使って分かったこと
4.4.1 ゴールを渡せる
従来型RPAではクリック位置、入力順、待機時間を細かく定義します。一方、GitHub Copilotには「データを選び、モデルを作り、アプリとマニュアルまで完成させる」というゴールを渡せます。途中の調査、ファイル確認、コマンド実行、再検証はエージェント側が組み立てます。
4.4.2 既存状態に応じて動作を変えられる
今回、対象フォルダーには既に成果物がありました。Copilotは重複作成を避け、要件との照合と動作再検証へ切り替えました。固定シナリオの再生ではなく、現在状態から次の行動を選べる点が特徴です。
4.4.3 GUI操作には状態確認が必要
Windowsのフォーカス保護やDPIスケーリングがあるため、単純な座標クリックだけでは誤操作が起こり得ます。各操作後に画面やアクティブウィンドウを確認し、通知やダイアログが出た場合は先に閉じる設計が重要です。今回、作業を妨げる通知は表示されませんでした。
4.4.4 長い依頼ほど検証条件を具体化する
「作ってください」だけでなく、使用データ、評価指標、保存ファイル、正常系・異常系テスト、マニュアル項目まで指定したことで、完了判定が明確になりました。RPAとして安定運用するなら、成果物だけでなく「どう確認すれば完了か」もプロンプトへ含めるのがコツです。
4.5 Experiment 2のまとめ
GitHub Copilot Chatのエージェント機能は、Visual Studio Code内の開発作業を対象にしたRPAとして利用できます。特に、複数ファイルの作成、環境構築、コマンド実行、デバッグ、動作確認、ドキュメント作成まで連続するタスクと相性が良好です。
一方で、曖昧な指示を完全に放置するのではなく、作業フォルダー、必要成果物、テスト条件、認証情報の扱いを明示し、最後に人が結果をレビューすることが大切です。GitHub Copilotは「クリックを代行するRPA」から、「目的を理解して作業を進めるRPA」への変化を実感できるツールでした。
5. 実験から見えた実務での設計原則
5.1 Application Testにはかなり相性が良さそう
私自身、一番興味があるのはこちらです。
ApplicationのSystem Testです。
例えば、
Application起動
↓
設定変更
↓
Data入力
↓
処理実行
↓
画面結果確認
↓
Database確認
↓
Screenshot保存
です。
これまで人が行っていた「手当たりテスト」に近い部分を減らせるかもしれません。
特にVibe Codingでは、Codeを書く速度が上がります。
Code Generationが速くなれば、変更回数も増えます。
変更回数が増えれば、確認する回数も増えます。
つまり、
開発のボトルネックがCodingからVerificationへ移る
のは、それほど不思議ではありません。
であれば、
AgentにCodingだけではなくVerification側のToolも渡す。
私はこの方向が自然だと思っています。
5.2 Manual作成も同じ
Manual作成も面白いです。
Manualで面倒なのは、文章を書くことだけではありません。
むしろScreenshotです。
正しい画面を開いて、
正しい状態にして、
Screenshotを撮って、
File名を付けて、
Documentに貼って、
その画面の説明を書く。
Applicationの仕様が変われば、Screenshotも撮り直します。
これは結構大変です。
AgentがApplicationを操作できるなら、
操作
↓
Screenshot
↓
説明文生成
↓
Document
を一つのFlowとして扱える可能性があります。
Applicationが変われば、もう一度実行する。
ここまで出来るようになると、Documentationも開発工程の一部として扱いやすくなります。
今回の2つのPromptで、あえてScreenshotとManual作成まで要求しているのはこのためです。
5.3 API / CLIを優先し、GUI Automationは必要な場所だけ使う
ここは少し大事です。
画面操作が出来るようになると、
何でも画面から操作させればいい
と思いたくなります。
でも、私はそうではないと思っています。
例えば、
GUI Automation
API
CLI
Database
File
が選べるなら、一般的にはAPIやCLIなど構造化されたInterfaceの方が安定します。
GUIは、
- ApplicationのVersion
- Window Size
- Dialogの表示
- Layout変更
- Focus
- Timing
などに影響されやすいからです。
ですので、
GUI操作が出来るからGUIを使う、ではなく、次の優先順位で考える方が現実的です。
APIがあるならAPI
CLIがあるならCLI
Fileで済むならFile
BrowserならPlaywright
最後にGUI Automation
RPA的に使える可能性があることと、全部RPAで作るべきということは別です。
5.4 Security：PermissionとHuman Approvalを設計する
ここは当然あります。
Browserの中だけではなく、OS側のToolまで使える。
ということは、
便利になった分だけ影響範囲も広がります。
--allow-all や --yolo のように承認を大幅に緩める設定は、隔離された検証環境など、影響範囲を限定できる場所で扱う前提にします。
GitHub Copilot CLIでは、Tool、Path、URLなどに対してAllow / Denyを設定できます。
一方で --allow-all や --yolo を使えば、Tool、Path、URLの承認を大幅に緩めることもできます。
GitHubはこれらを隔離環境だけで利用することを強く推奨しています。
さらにLocal Sandboxを使えば、
- Filesystem
- Network
- Credential
などへのAccessを制御できます。
ここで、
危ないから全部禁止
というのも一つの判断です。
一方で、
便利だから全部Allow
も違うと思っています。
現実的には、その間です。
例えば、
開発専用PC / Sandboxを使う
↓
対象Folderを限定する
↓
必要なToolだけAllowする
↓
不要なPath / URLを制限する
↓
重要操作にはHuman Approvalを残す
↓
Log / Screenshotを残す
↓
問題が起きた時の影響範囲を限定する
くらいから始める。
Zero Trustの考え方も参考になります。
Microsoftが整理しているZero Trustの基本原則は、
- Verify explicitly
- Use least privilege access
- Assume breach
です。
Agentだから突然まったく新しいSecurity思想が必要になったというより、
これまで使ってきたSecurityの原則をAgentにも適用する
と考える方が分かりやすいと思っています。
まずはここまでで十分です。
5.5 ここまでの整理
ここまで長くなったので、一度整理します。
5.5.1 良い点
- GitHub Copilot CLIをCodingだけではなくOrchestratorとして扱える可能性がある
- Shell、Python、PowerShell、MCP、既存Toolなどを組み合わせられる
- Browserだけでは終わらないWorkflowへ広げられる可能性がある
- Test、Screenshot、Manualなど、実装後の作業にもAgentを利用できる可能性がある
- Vibe Codingで増えたVerificationの負荷を減らせる可能性がある
- Promptを「Code Generationの指示」ではなく「やりたい仕事の記述」として考えられる
5.5.2 注意点
- GitHub Copilot CLIそのものがDesktop RPA製品というわけではない
- GUI操作には別のToolやScriptが必要になる
- 「OSで動くCode Interpreter」は私なりの比喩であり、正式な製品分類ではない
- Local Sandboxが無効なら、Shell CommandはLocal Userの権限で動く
- Agentの誤操作は普通に考慮する必要がある
- Productionや重要業務で、いきなり全面自動化する話ではない
- 最終承認を人に残した方がよい処理も多い
5.5.3 限界
- GUI操作は画面状態やApplication更新の影響を受けやすい
- 長いWorkflowほど途中失敗の可能性が増える
- Agentが「出来た」と言うことと、実際に正しく出来たことは別
- 再現性を確保するにはTest Result、Log、ScreenshotなどのEvidenceが必要
- APIやCLIを利用した方が安定する処理も多い
- Permissionを広げれば便利になる一方で、Riskも広がる
特に最後から2つは重要だと思っています。
AgentにPCを操作させること自体が目的ではありません。
仕事全体の中で、人とAgentとToolをどう組み合わせるか
が大事です。
6. まとめ
最初は、
「Windows ApplicationのTestを自動化出来ないかな」
くらいの話でした。
Playwrightを見ていて、
Browserならかなり出来る。
でも自分のApplicationはBrowserではない。
そこでGitHub Copilot CLIがShellやToolを利用できることを改めて考えて、
これ、Browserの外にも出られるのでは?
と思った。
そこがスタートでした。
さらに実際に試していると、
PromptからPython Codeなどを生成して、それをLocal PC上で実行する。
その動きを見て、
「OSで動くCode Interpreterみたいだな」
という見方も出てきました。
もちろん正式には違います。
でも、この比喩を使うと、
Prompt
↓
Code / Tool
↓
Execution
↓
Local Environment
という構造が分かりやすくなりました。
すると、これはApplication Testだけの話ではなくなります。
Coding
↓
Build
↓
Run
↓
Operate
↓
Verify
↓
Document
この一連の工程をAgentへどう渡すか、という話になります。
Vibe Codingによって「Codeを書く」部分が速くなるほど、その前後が気になります。
Test。
Review。
Validation。
Documentation。
Operations。
私はこのあたりが、次にかなり面白くなると思っています。
とはいえ、万能ではありません。
PCを操作できるAgentが出来たから、すべての仕事を任せる。
そんな極論でもありません。
まずは、
今、自分が毎回手でやっている作業を一つ選ぶ。
そして、Agentが安全に実行するためには、何のTool、何のPermission、何のEvidenceが必要なのかを考える。
ここから始めるくらいで十分だと思っています。
APIやCLIで出来ることなら、そちらを使う。
どうしても画面操作が必要な部分だけGUI Automationを使う。
重要な判断やSubmitは人に残す。
必要なAccessだけ許可する。
実務で考えると、そのくらいの落としどころが現実的ではないかと思っています。
今回掲載した2つのPromptも、そのためのExperimentです。
実際にGitHub Copilotで動かした結果については、この記事に追記します。
成功したところだけではなく、
- 止まったところ
- Agentが勘違いしたところ
- 人が介入したところ
- Toolを追加したところ
- Permissionで止まったところ
- 再実行で改善したところ
も含めて残したいと思っています。
おそらく、そこに実務で使うためのヒントが一番多くあるはずです。