21
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【やってみた】Copilot Studio + Power Automate Desktop

21
Last updated at Posted at 2026-06-27

自然言語で Copilot エージェントに指示出して、Outlook からテストメール送信できたぞ・・・

こうつぶやいてしまうくらい驚きを隠せなかったです!えっ・・・何がって?
Gemini_Generated_Image_jozbb5jozbb5jozb.png

RPA のように UI 操作を定義することなく、「文章を書くだけ」でデスクトップアプリを操作できたってこと。

1. はじめに

Copilot Studio から Power Automate Desktop(PAD)などのローカルリソースを呼び出して業務自動化を行う構成は、エンタープライズAIの領域で定番となりつつあります。

今回検証した Copilot Studio の「コンピューターユース(Computer Use)」機能は、これまでの RPA の常識を覆すほどのインパクトを持っています。従来のように「UI 要素(ボタンやテキストボックス)を一つずつ指定してフローを組む」のではなく、「スタートメニューから開いて、宛先を入力して…」といった自然言語の手順を記述するだけで、AI が画面を解釈し、デスクトップアプリ(新しい Outlook)を操作してメールを送信することができました。

注意事項
本記事の内容は、あくまで最新機能を活用した実験的な「やってみた」系の技術検証であり、本番業務やエンタープライズ環境への即時導入を想定した実践的なアプローチではありません。AIによるデスクトップ画面の自動操作は予期せぬ挙動(意図しないアプリの操作や誤送信など)を引き起こすリスクがあるため、実際に試される場合は、必ず影響のないテスト環境にて、すべて自己責任の範疇で実施していただくようお願いいたします。

上記の前提を踏まえた上で、本記事ではこの次世代の自動化アプローチの実装手順と、安全に検証するためのセキュリティ設定の要点、そしてシステムアーキテクチャとしての考察を解説します。

2. アーキテクチャの解説:従来のデスクトップ自動化との決定的違い

従来の RPA(PAD等)を用いた UI 操作と、今回のコンピューターユース機能を用いたアプローチには、根本的な違いがあります。

  • 従来のアプローチ(UI セレクタ依存): PAD のレコーダー機能などを使用し、操作対象のウィンドウやボタンの「UI セレクタ(内部 ID や階層構造)」を正確にキャプチャしてステップを構築します。画面のレイアウトや内部 ID が少しでも変更されると、フローがエラーで止まってしまうという保守性の課題がありました。
  • 今回のアプローチ(AI による動的画面認識): ユーザーの入力と Copilot Studio で定義した「手順(テキスト)」を、Claude Opus 4.6 などの AI モデルが解釈します。AI が現在のデスクトップ画面を認識・推論しながら操作を代行するため、レイアウトの微小な変更に強く、何より「フロー作成工数」が劇的に削減されます。

3. 実装ステップと設定のキモ

それでは、実際に Copilot Studio でエージェントを設定していく手順を見ていきます。

Step 0: ローカルPCとクラウドの紐づけ(事前準備)

AI がローカルのデスクトップアプリを操作するためには、実行対象の PC が Power Automate のクラウド環境とセキュアに接続されている必要があります。

1. Power Automate ポータルの「マシン」メニューから新しいマシンの設定を行います。

画像 (12).png

2. ローカルPC側で「Power Automate machine runtime」というクライアントエージェントアプリを起動し、対象の環境(Environment)に接続・登録しておきます。

画像 (13).png

この準備を済ませておくことで、後述する Copilot Studio のツール設定内(マシンの管理)で、動作させる物理 PC を指定できるようになります。

Step 1: ツールの作成とモデル選択

Copilot Studio のエージェント設定画面から、アクションとして「コンピューターユース」ツールを追加します。
画像 (14).png

モデルには、画面認識と操作に長けたプレビューモデル(例:Claude Opus 4.6)を指定します。
画像 (15).png

Step 2: 入力変数の定義

ツールが実行される際に、AI に渡すパラメータ(変数)を定義します。今回は以下のような変数を設定しました。

  • testMailAddress (宛先1)
  • testMailAddress2 (宛先2 / CC用)
  • suggestedAccount (初期設定時のアカウント名)
  • olkpassword (パスワード)

画像 (16).png

Step 3: 「手順(プロンプト)」の記述

ここが本機能の最大の特徴です。PAD のようにアクションをパズルのように並べるのではなく、以下のように自然言語(日本語)で手順を記述します。
※Microsoft 365 Developer Program の環境(英語)でテストしたので指示する Outlook のボタン名は英語になっています。

WindowsスタートメニューからOutlookを検索し起動します。
初期設定の Welcom to the new Outlook画面が表示される場合は、
Suggested accountに、入力suggestedAccountを入力してContinueボタンを押してください。
パスワードを求められたら、入力olkpasswordを入力してください。

ここから作業
Outlookの初期設定が終わりアプリを利用できる状態になったら
新規メール作成を行い、宛先に
入力testMailAddress
を入力します。
CCに
入力testMailAddress2
を入力します。
「Select an item to read」と「the subjects」ポップアップメッセージが表示されていますが、これは無視して作業を続けます。
「Add a subject」は「テストメール」を入力してください。
メール本文はテストメール用の本文を生成して本文に入力してください。
送信準備が整ったら、Sendボタンでメールを送信してください。

注目すべきは、「初期設定画面が表示される場合は…」「パスワードを求められたら…」といった条件分岐や例外処理すらも、自然言語で記述するだけで AI が画面状態を判断して機能するという点です。

#プロンプト文をタイポしても理解してくれる点がさらに素晴らしい...
#2 行目: Welcom to the new Outlook → Welcome to the new Outlook

Step 4: 【最重要】安全に使うためのアクセス制御(セキュリティ設定)

AI にコンピューターの操作を委ねる本機能は非常に強力ですが、意図しないアプリの起動や Web サイトへのアクセスを防ぐためのガバナンス設定が不可欠です。

ツールの設定画面下部にある「許可された Web サイトとデスクトップ アプリ」セクションで、AI の行動範囲を厳密に制限します。

画像 (17).png

特定のアプリのみに制限:
今回は新しい Outlook を操作するため、以下のコンポーネントを許可リストに追加しています。

  • OUTLOOK
  • msedgewebview2
  • OneDrive / OneDrive (および Outlook)

Tips:
WebView2 の許可が必須 新しい Outlook は Web 技術(WebView2)をベースに動作しています。そのため、本体の OUTLOOK プロセスだけでなく、msedgewebview2 を許可リストに入れておくことが、操作を正常に完了させるための隠れた重要ポイントです。

通信の安全性を担保:
「HTTPS を適用する」をONにし、操作対象をセキュアなエンドポイントに限定します。

Step 5: 実行中のモニタリング(AIの画面認識と推論の可視化)

エージェントのテストをチャットで実行の指示を行うと、Copilot Studio の「活動(Activity)」タブから、AIがどのように画面を操作しているかをリアルタイムで確認できます。
画像 (18).png

非常に興味深いのは、約 10 秒おきに現在のデスクトップのスクリーンショットが取得され、その間に AI が何を認識し、どのような操作を行ったかがテキストで通知される点です。

画像 (19).png

画像 (20).png

例えば「メール本文エリアにカーソルが配置されました...指示通り無視して作業を続けます」といったように、Claude モデルが画面の視覚情報をもとに「推論」しながら作業を進めているプロセスが手に取るようにわかります。これにより、エラー発生時のデバッグも非常に容易になります。

  • 送信されたテストメール
    画像 (21).png

4. システムアーキテクト視点での考察

単に「動いた」というだけでなく、エンタープライズアーキテクチャの観点からこのアプローチを評価してみます。

バックグラウンド(別セッション)での非アテンド型実行の実現

従来のデスクトップ自動化(Attended RPA)において最大の課題だったのが「実行中にPCの画面(マウスやキーボード)を占有されてしまう」という点でした。 しかし今回の検証において、対象のPC上でユーザーがログインして別作業を行っていても、Copilot エージェントは別のアカウントを用いたバックグラウンド処理(独立したセッション)として動作することが確認できました。これにより、ユーザーの日常業務を阻害することなく、裏側でAIにデスクトップアプリの操作を完全に委譲する、真の非アテンド型(Unattended)アーキテクチャを実現できます。

Graph APIアプローチとの使い分け

バックグラウンドで高速かつ確実なメール送信処理が求められるシステム連携であれば、当然 Microsoft Graph API を使用するのがベストプラクティスです。 しかし、本機能は「API が提供されていないレガシーアプリの操作」や「人間の UI 操作プロセスを完全に模倣・テストしたい場合」に真価を発揮します。

5. まとめと現時点での課題

「UI セレクタを一つずつ取得してフローを組む」というこれまでの RPA 開発の常識は、生成 AI の「コンピューターユース」機能によって大きく変わろうとしています。日本語の自然言語指示のみで、条件分岐も含めて柔軟に新しい Outlook を操作できたのは驚きでした。事前のマシンランタイムの設定や、適切なアクセス制御(msedgewebview2の許可など)を施すことで、実務での検証にも耐えうるポテンシャルを秘めています。

一方で、現時点での明確な課題として「実行速度の遅延」が挙げられます。今回の検証では、単にメールを 1 通送信するだけの操作が完了するまでに約 5 ~ 10 分もの時間を要しました。 これは、AI が約 10 秒ごとに画面のスクリーンショットをキャプチャし、視覚情報から状況を推論して次のアクションを決定するというプロセスを繰り返しているためです。従来の RPA や API 連携のような即時性はなく、リアルタイム性が求められる業務への適用は現状では困難と言えます。

当面は、即時性が不要な夜間バッチ的な非同期処理や、テスト自動化といった領域から適用を探りつつ、今後の AI モデルの推論速度向上によるパラダイムシフトに期待したいと思います。

CopilotStudioツールの関連記事

21
17
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
21
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?