Microsoft 365 Copilotを業務システム連携に使っている組織にとって、今回のポイントは「AIエージェントが画面を見て操作するUI自動化を、Copilot Studioのワークフローに組み込めるようになる」ことです。APIがないWebサイトや古い業務アプリでも自動化対象にしやすくなる一方で、認証情報、操作できるWebサイト、実行用マシン、環境単位の有効化を管理しないと、意図しない代理操作や運用トラブルにつながります。
Microsoft 365ロードマップの項目「Microsoft Copilot Studio: Supercharge your workflows with computer use」は、Copilot Studioのcomputer use toolsにより、AIを使った回復力のあるUI自動化をワークフローへ直接追加する更新です。公式API上の作成・更新日時は2026-05-15T18:00:35で、日本時間では2026年5月16日未明に相当します。パブリックプレビューは2026年4月、一般提供は2026年10月予定、対象はMicrosoft Copilot StudioとMicrosoft Copilot（Microsoft 365）、プラットフォームはWeb、クラウドはWorldwide（Standard Multi-Tenant）です。(Microsoft)
Microsoft 365 CopilotのCopilot Studio更新で何が変わるのか
今回の更新は、Copilot Studioのエージェントやワークフローに「computer use」というUI操作型のツールを追加するものです。computer useは、Windowsコンピューター上でWebサイトやデスクトップアプリを操作し、ボタン選択、メニュー操作、テキスト入力などを実行します。APIが用意されていないシステムでも、人が画面を操作するような手順をエージェントに任せられる点が大きな特徴です。(Microsoft Learn)
従来の自動化では、API、Power Platformコネクタ、Power Automate Desktop、RPAスクリプトなどを組み合わせる必要がありました。computer useは、画面の変化をAIが解釈して操作するため、ボタン位置や画面構成が多少変わっても壊れにくい自動化を目指せます。ただし「壊れにくい」は「必ず正しく動く」という意味ではありません。業務で使う場合は、対象画面、許可URL、認証方式、レビュー担当、失敗時の戻し方まで設計する必要があります。(Microsoft Learn)
変更点を一言で整理
| 観点 | これまで課題になりやすかったこと | 今回の更新で期待できること |
|---|---|---|
| APIがない業務システム | 連携できず、手作業やRPAに頼りがち | 画面操作ベースで自動化できる可能性が広がる |
| UI変更への耐性 | セレクタや画面構成の変更で自動化が失敗しやすい | AIが画面を解釈し、変更に適応しやすい |
| 作成者の負担 | スクリプト、セレクタ、例外処理の知識が必要 | 自然言語の指示でツールを構成しやすい |
| 管理者の統制 | どこまで自動操作を許可するかが課題 | 環境設定、アクセス制御、実行環境の管理で統制しやすい |
| 展開判断 | 便利だがセキュリティリスクが見えにくい | hosted browser、Cloud PC pool、BYO machineを用途別に選べる |
computer useは「AI版RPA」だが、RPAの置き換えとは限らない
computer useはRPAに近い使い方ができますが、単純に「Power Automate Desktopの後継」と考えると誤解しやすい機能です。RPAは決まった手順を高い再現性で実行するのに向いています。一方、computer useはAIが画面を見ながら判断するため、UI変更への柔軟性や自然言語での設定が強みです。
業務での判断基準は、次のように考えると分かりやすくなります。
| 自動化したい処理 | 向いている選択肢 |
|---|---|
| APIがあり、処理結果を確実に制御したい | API、Power Platformコネクタ、HTTP要求 |
| 複数システムを決まった順序で処理したい | Power Automate、agent flow、RPA |
| APIがなく、Web画面やデスクトップアプリを操作する必要がある | computer use |
| UIが変わりやすく、従来RPAが壊れやすい | computer useの検証対象 |
| 監査性や例外処理を厳密に作り込みたい | API連携またはPower Automate中心の設計 |
実務では、computer useだけで完結させるよりも、「APIで取れる情報はAPIで取得し、APIがない最後の画面操作だけcomputer useに任せる」構成のほうが安定します。たとえば請求書処理なら、ファイル取得や承認通知はPower Automate、外部ポータルへの入力だけcomputer use、最終結果の保存はDataverseやSharePointという分担が現実的です。
対象サービス、展開時期、提供範囲
公式ロードマップでは、対象製品にMicrosoft Copilot（Microsoft 365）とMicrosoft Copilot Studio、リリースフェーズにPreviewとGeneral Availability、ステータスにIn developmentが示されています。つまり、現時点では全テナントで本番利用できる完成機能として扱うのではなく、プレビューから検証し、2026年10月予定の一般提供に向けて展開計画を作る段階です。(Microsoft)
| 項目 | 内容 |
|---|---|
| ロードマップID | 562220 |
| 更新名 | Microsoft Copilot Studio: Supercharge your workflows with computer use |
| 対象 | Microsoft Copilot Studio、Microsoft Copilot（Microsoft 365） |
| プラットフォーム | Web |
| クラウド | Worldwide（Standard Multi-Tenant） |
| ステータス | In development |
| パブリックプレビュー | 2026年4月予定 |
| 一般提供 | 2026年10月予定 |
| 主な管理要素 | アクセス制御、hosted browser管理、環境レベルの権限 |
Microsoft 365ロードマップの情報は予定であり、Microsoft自身も商用機能のリリース予定日や説明は変更される可能性があると明記しています。公開時点のスケジュールを前提にしつつ、社内展開ではメッセージセンター、Microsoft Learn、Power Platform管理センターの実表示を確認してから進めるべきです。(Microsoft)
影響を受けるユーザーと管理者
この更新の影響は、Copilot Studioの作成者だけに限られません。Microsoft 365 Copilotを業務に展開している組織では、管理者、開発者、セキュリティ担当、現場部門の利用者まで確認が必要です。
作成者への影響
作成者は、Copilot Studioのエージェントにcomputer useをツールとして追加し、名前、説明、モデル、指示文を設定します。追加設定として、実行マシン、認証情報、人による監督、保存済み資格情報、アクセス制御なども構成できます。(Microsoft Learn)
特に重要なのは、指示文の品質です。「経費システムにログインして処理して」では不十分です。どのアプリを開くのか、どの画面で何を選ぶのか、入力値はどこから取得するのか、送信前に確認するのかまで書く必要があります。
悪い例:
経費申請を処理して
良い例:
経費申請一覧を開き、ステータスが「承認待ち」の申請だけを確認する。申請者、金額、勘定科目、添付ファイルの有無を取得し、金額が10万円未満で添付ファイルがあるものだけ承認候補として一覧化する。承認ボタンは押さず、結果をJSON形式で返す。
最初から「送信」「承認」「削除」などの不可逆操作を任せるのは避け、まずは読み取り、転記、候補作成、下書きまでに制限すると安全です。
管理者への影響
管理者は、computer useを環境単位で無効化できます。Power Platform管理センターの環境設定からComputer useのトグルをオフにする方法に加え、Power Platform CLIで iscomputeruseinmcsenabled をfalseに設定する方法も案内されています。(Microsoft Learn)
また、hosted browserはテナント設定から無効化できます。Power Platform管理センターのTenant settingsで「Hosted browser in computer use」を開き、トグルをオフにして保存する流れです。(Microsoft Learn)
展開前に確認したい管理ポイントは次の通りです。
| 確認項目 | 見るべきポイント |
|---|---|
| どの環境で有効にするか | 個人開発環境では制限し、検証用・本番用環境を分ける |
| 誰が作成できるか | Environment Makerや専用セキュリティロールを最小限にする |
| 誰の資格情報で実行するか | 作成者の資格情報か、実行ユーザーの資格情報かを明確にする |
| どのURL・アプリを操作できるか | allow listを設定し、不要なサイトやアプリを対象外にする |
| どのマシンで実行するか | hosted browser、Cloud PC pool、BYO machineを用途別に選ぶ |
| 監査・確認方法 | 実行履歴、画面スクリーンショット、担当者レビューを確認する |
Copilot Studioのセキュリティガイダンスでは、Microsoft Entra IDグループによるライセンス割り当て、環境アクセス管理、Dataverseセキュリティロール、不要なコネクタをブロックするデータポリシー、開発・テスト・本番を分けたゲート付きリリースが推奨されています。computer useでも同じ考え方が重要です。(Microsoft Learn)
開発者・内製化チームへの影響
開発者は、computer useを「最後の手段」として使うか、「UI変更に強い新しい自動化手段」として積極活用するかを見極める必要があります。Copilot Studioには、Power Platformコネクタ、HTTP要求、agent flows、Bot Framework skills、MCPなど複数の統合パターンがあります。APIやコネクタで安定して処理できる部分までcomputer useに任せると、テストや監査が難しくなります。(Microsoft Learn)
開発者が最初に設計すべきなのは、ツール選択の基準です。
| 判断基準 | 推奨 |
|---|---|
| 公式APIがある | APIまたはコネクタを優先 |
| APIはあるが仕様変更が多い | MCPや共通ラッパーで管理 |
| APIがないが画面操作は安定している | computer useを検証 |
| 画面操作に承認・送金・削除が含まれる | 人による確認を必須にする |
| 失敗時に業務影響が大きい | 本番前に手動リカバリー手順を作る |
実行環境は3種類。hosted browserを本番前提にしない
computer useは、Windowsマシン上でWebサイトやアプリを操作します。実行環境として、hosted browser、Cloud PC pool、Bring-your-own-machine（BYO machine）の選択肢があります。(Microsoft Learn)
hosted browserは検証向け
hosted browserは、マシンを用意せずにすばやく始められるMicrosoft管理環境です。Microsoft Edgeを使ったWeb自動化や組み込みWindowsアプリへのアクセスができます。ただし、Microsoft Entraに参加しておらず、Intuneポリシーでも管理されません。エンタープライズリソース、カスタムデスクトップアプリ、組織固有のデバイス管理には対応しないため、本番利用には向きません。(Microsoft Learn)
さらに、hosted browserは需要に応じてスロットリングされる可能性があり、1ユーザーにつき同時に1つのアクティブセッションに制限される場合があります。本番処理で「実行できない時間帯がある」「並列処理できない」と困る業務には使わないほうが安全です。(Microsoft Learn)
Cloud PC poolは組織管理しやすい
Cloud PC poolは、Windows 365 for Agentsを基盤にした仮想マシンのプールです。Microsoft Entra参加とIntune登録に対応し、Microsoft 365、SharePoint、Azureなど組織リソースへのアクセスにも対応しやすい構成です。自社で物理マシンを準備せずに、管理された実行基盤を用意したい場合に向いています。(Microsoft Learn)
一方で、Cloud PC poolもプレビュー文書の対象であり、課金、前提条件、Microsoft EntraとIntuneの構成、RDP関連の設定を確認する必要があります。Microsoft Learnでは、Cloud PC poolの利用に従量課金メーターを使うことや、評価用に一定の無料枠が用意されることも説明されていますが、料金や条件は変更される可能性があるため、展開時点の公式情報で確認してください。(Microsoft Learn)
BYO machineは本番用途で検討しやすい
Bring-your-own-machineは、自社で所有・管理するWindowsマシンをPower Automateに登録して使う方法です。Microsoft Learnでは、Power Automate for desktopの指定バージョン以降をインストールし、Webブラウザー操作用のPower Automate拡張機能を含めること、登録後にmachine settingsでcomputer useを有効にすることが要件として示されています。(Microsoft Learn)
BYO machineを使う場合は、専用マシンを用意するのが基本です。通常業務で使うPCを兼用すると、ユーザー操作とAI操作が衝突したり、画面に表示された機密情報を意図せず処理したりするリスクがあります。
認証情報とアクセス制御で失敗しやすいポイント
computer useの導入で最も注意すべきなのは、資格情報の扱いです。認証方式には、作成者の資格情報を使う「Maker-provided credentials」と、エージェントを利用する人の資格情報を使う「End user credentials」があります。Microsoft Learnでは、作成者の資格情報を使う設定でエージェントを共有すると、利用者が元の作成者のアクセス権で対象マシン上の操作を実行できる可能性があると警告しています。(Microsoft Learn)
これは、便利さよりも先に統制を考えるべきポイントです。たとえば、経理担当者が作成したエージェントを営業部門にも共有した場合、営業部門のユーザーが経理担当者の権限で会計システムを操作できる構成になっていないかを確認する必要があります。
資格情報の選び方
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| Maker-provided credentials | バックグラウンドで決まった処理を自動実行する | 共有範囲を誤ると作成者権限で代理操作される |
| End user credentials | 利用者本人の権限で処理させたい | 各ユーザーが対象マシンやアプリへの権限を持つ必要がある |
| Stored credentials | サイトやアプリへのログイン情報をツール側で管理したい | Power Platform内部ストレージまたはAzure Key Vaultの設計が必要 |
| Human supervision | 危険な指示や曖昧な判断を人が確認したい | レビュー担当者が実行内容を確認できる権限と文脈を持つ必要がある |
また、computer useは既定では任意のWebサイトやアプリを操作できるため、アクセス制御で許可URLや許可アプリを定義することが重要です。ただし、allow listは未許可サイトでの操作を止めるものであり、開くこと自体を完全に防ぐ仕組みではない点にも注意が必要です。(Microsoft Learn)
管理者が展開前に確認すべき設定
本番展開前には、少なくとも以下を確認してください。
| 項目 | 確認内容 | 推奨アクション |
|---|---|---|
| 環境設定 | computer useがどの環境で有効か | 開発・検証・本番を分け、本番は承認後に有効化 |
| テナント設定 | hosted browserが有効か | 本番前提で不要なら無効化を検討 |
| 作成者権限 | 誰がCopilot Studioでエージェントを作れるか | Entra IDグループとセキュリティロールで制限 |
| データポリシー | 利用できるコネクタや知識ソース | 不要なコネクタ、匿名利用、不要チャネルをブロック |
| マシン管理 | 実行マシンが専用か、Intune管理下か | 兼用PCを避け、専用実行環境を用意 |
| 認証方式 | 誰の権限で操作するか | 共有範囲と最小権限を必ず確認 |
| 操作範囲 | どのURL・アプリを操作できるか | allow listで対象を絞る |
| 監査 | 実行履歴やスクリーンショットを確認できるか | テスト実行、ログ確認、レビュー手順を標準化 |
Power Platform管理センターでは、Copilot Studio authoringの対象セキュリティグループや、hosted browser in computer useなどのテナント設定が管理対象として示されています。環境単位の設定だけでなく、テナント全体の作成者制御もあわせて確認してください。(Microsoft Learn)
移行・展開時の考え方
今回のロードマップ項目は、既存のMicrosoft 365 Copilot利用者に一律で作業変更を強制するものではありません。既存のエージェントやワークフローへ自動的にcomputer useが追加されるのではなく、Copilot Studioでツールとして追加し、設定・テスト・公開する形で使います。ツール追加時には、Machine、Credentials to use、Human supervision、Stored credentials、Access controlなどの追加設定を確認できます。(Microsoft Learn)
移行というより、「手作業や既存RPAの一部を置き換えられるかを検証する」進め方が現実的です。おすすめは次の順序です。
小さく始める展開ステップ
| ステップ | やること | 成功基準 |
|---|---|---|
| 業務棚卸し | APIがない手作業、壊れやすいRPA、転記作業を洗い出す | 候補を3〜5件に絞る |
| リスク分類 | 読み取り、下書き、登録、承認、削除に分類する | 承認・削除系は初期対象から外す |
| 検証環境作成 | 専用のPower Platform環境とテストデータを用意する | 本番データに触れずに再現できる |
| hosted browserで試作 | 手順と指示文を作る | 期待結果が安定して返る |
| Cloud PC poolまたはBYO machineで検証 | 組織管理された実行基盤に移す | 認証、ログ、権限が管理できる |
| 人による確認を追加 | 危険操作や曖昧な判断をレビュー対象にする | 誤操作時に止められる |
| 本番公開 | 対象ユーザーを限定して公開する | 障害時の戻し手順がある |
特に、既存のPower Automate Desktopフローをすぐに置き換える必要はありません。安定稼働しているRPAは残し、UI変更で頻繁に壊れる箇所や、人が画面を見ながら判断している箇所から検証するほうが効果を出しやすいです。
具体的な活用シーン
computer useが向いているのは、API連携が難しく、画面操作を避けられない業務です。
請求書・経費処理
PDFやメールから取り出した情報を、外部の請求書ポータルや経費システムに入力するケースです。最初は「入力候補を作る」「画面に転記するが送信しない」までに留め、送信や承認は人が確認する構成が安全です。
レガシーWebシステムへの定型入力
古い業務システム、取引先ポータル、管理画面など、APIが提供されていないシステムへの入力に向いています。ただし、画面構成が頻繁に変わる、CAPTCHAがある、多要素認証が毎回必要になるといったケースでは安定運用が難しくなります。
データ抽出とレポート作成
管理画面から数値を読み取り、Microsoft 365 CopilotやPower Automateの後続処理へ渡す用途です。Microsoft Learnでは、computer useで取得した値をテキストやJSONで返し、別のツールに渡す使い方も説明されています。(Microsoft Learn)
社内ポータルの確認作業
ステータス確認、在庫確認、申請一覧のチェックなど、結果を読み取るだけの処理は初期検証に向いています。削除、送金、契約締結、公開設定変更のような操作は、最初から自動化しないほうが安全です。
失敗しやすいポイントと対策
指示文があいまいで、意図しない操作をする
computer useは自然言語で設定できますが、自然言語だからこそ曖昧さが残ります。画面名、操作順、入力値、禁止操作、完了条件を具体的に書いてください。長い手順は箇条書きにし、「送信前に停止する」「削除しない」「承認ボタンは押さない」などの禁止事項も明記します。(Microsoft Learn)
hosted browserを本番で使って失敗する
hosted browserはすぐ試せる点が魅力ですが、Microsoft Entra参加やIntune管理に対応せず、本番利用には推奨されません。需要に応じたスロットリングもあるため、業務時間中に安定実行したい処理にはCloud PC poolやBYO machineを検討してください。(Microsoft Learn)
作成者権限のまま共有してしまう
Maker-provided credentialsは便利ですが、共有したユーザーが作成者のアクセス権で操作できる可能性があります。社内共有前に、実行権限、共有範囲、対象マシン、対象システムの権限を確認してください。特権アカウントや管理者アカウントでの実行は避けるべきです。(Microsoft Learn)
MFAや既存セッションで実行が止まる
トラブルシューティング文書では、MFA要求、切断された既存セッション、すでに実行中の自動化、テスト機能の挙動などが失敗要因として示されています。初期検証では、実行アカウント、リモートデスクトップ設定、セッション終了手順、再試行ルールを事前に決めておくと運用しやすくなります。(Microsoft Learn)
セキュリティ面での実務的なチェックリスト
本番展開前に、以下を満たしているか確認してください。
- 専用の実行マシンまたは管理されたCloud PC poolを使っている
- 実行アカウントは最小権限になっている
- 操作できるURLとアプリをallow listで制限している
- 作成者の資格情報で実行する場合、共有範囲を限定している
- 送信、承認、削除、公開などの操作には人による確認を入れている
- テストデータで複数回実行し、失敗時の挙動を確認している
- 実行履歴、スクリーンショット、チャット上の表示内容を確認している
- 開発環境、テスト環境、本番環境を分けている
- データポリシーで不要なコネクタやチャネルをブロックしている
- 利用者向けに「エージェントに任せてよい作業」と「任せてはいけない作業」を明文化している
Microsoft Learnでは、computer use用マシンを専用化すること、利用アカウントの権限を最小化すること、信頼済みWebサイトだけを許可すること、必要なデスクトップアプリだけを許可することが推奨されています。(Microsoft Learn)
今すぐ管理者・開発者がやるべきこと
今回の更新は、Microsoft 365 Copilotの活用範囲を「文書作成や要約」から「画面操作を含む業務実行」へ広げる重要な動きです。ただし、AIが画面を操作するという性質上、便利さとリスクが同時に増えます。
まず管理者は、Power Platform管理センターでCopilot Studioの作成者、対象環境、hosted browser、computer useの有効化方針を確認してください。次に開発者・内製化チームは、API化できない手作業を棚卸しし、読み取り中心の低リスク業務から検証を始めるのが現実的です。最後に、利用部門には「自動化できる作業」と「人の承認を残す作業」を分けて説明し、いきなり本番の承認・削除・送信処理を任せない運用ルールを作りましょう。
Microsoft 365 CopilotとCopilot Studioの価値は、AIに何でも任せることではなく、人が判断すべき部分とAIに任せられる反復作業を切り分けることで最大化します。computer useは、その切り分けを進めるための強力な選択肢です。2026年10月予定の一般提供に向けて、今のうちに環境設計、権限設計、対象業務の選定を進めておくと、公開後の展開がスムーズになります。
コメント