2026年5月時点の公式情報で押さえるべき結論は、Microsoft Copilot Studioの「computer use」は、APIがないWebアプリやデスクトップアプリでも、エージェントが画面を見て、ボタン選択・メニュー操作・文字入力を実行できる自動化機能だという点です。従来のコネクタやAPI連携だけでは対応しづらかった業務にも使える一方で、認証、実行マシン、アクセス制御、Copilot Credits、プロンプトインジェクション対策を事前に設計しないと、本番展開でリスクが大きくなります。Microsoft Learnの該当ページは、computer useを「Windowsコンピューター上でWebサイトやデスクトップアプリを操作するツール」と説明しており、自然言語で操作手順を指示できる点が特徴です。(Microsoft Learn)
Microsoft Copilot Studioのcomputer useで何が変わるのか
Microsoft Copilot Studioのcomputer useは、エージェントに「画面操作」を任せられる機能です。Webサイトやデスクトップアプリのボタンを選ぶ、メニューを開く、入力欄に文字を入れる、といった操作を、仮想マウスと仮想キーボードで実行します。
大きな変更点は、APIや専用コネクタがないシステムでも、自動化の対象にできることです。たとえば、古い業務アプリ、社内ポータル、取引先のWeb画面、請求書管理画面など、API連携が難しい画面でも、手順を自然言語で記述してエージェントに実行させる選択肢が生まれます。
Microsoftのリリース計画では、この機能は管理者、作成者、マーケティング担当者、アナリスト向けに自動的に有効化される機能として扱われ、パブリックプレビューは2025年5月27日、一般提供は2026年5月とされています。ただし、リリース計画の機能は時期や内容が変更される可能性があるため、導入時は必ず自社テナントの実際の表示と最新の公式情報を確認してください。(Microsoft Learn)
従来の自動化との違い
computer useは「何でも自動化できる魔法の機能」ではありません。API連携、Power Automate Desktop、従来型RPAと比べると、得意な領域が異なります。
| 比較項目 | API・コネクタ連携 | 従来型RPA・デスクトップフロー | computer use |
|---|---|---|---|
| 主な操作対象 | API、クラウドサービス、データ | PC上のアプリ、ブラウザ、固定手順 | Webアプリ、デスクトップアプリのGUI |
| 強み | 安定性、監査性、速度 | 決まった画面操作の反復 | APIがない画面でも自然言語で操作を指示できる |
| 弱み | APIがないと使いづらい | UI変更に弱い場合がある | AI判断に依存するため、結果が毎回完全に同じとは限らない |
| 向いている業務 | データ同期、承認、通知、システム連携 | 定型入力、帳票処理、画面操作 | 画面を見ながら判断する入力・抽出・照合作業 |
| 本番運用の注意点 | 権限とAPI制限 | 画面変更、実行端末、例外処理 | 認証、アクセス制御、専用マシン、監視、人間の確認 |
実務では、安定したAPIがある処理はAPI連携を優先し、APIがない画面操作や、一時的に人手でつないでいる作業にcomputer useを検討するのが現実的です。
影響範囲：誰が何を確認すべきか
computer useの影響は、Copilot Studioでエージェントを作る担当者だけにとどまりません。管理者、開発者、セキュリティ担当、業務部門がそれぞれ確認すべき点があります。
| 立場 | 主な影響 | 最初に確認すべきこと |
|---|---|---|
| Power Platform管理者 | 環境、モデル、外部モデル、マシン管理、課金管理 | 利用リージョン、外部モデル許可、Copilot Credits、DLPや監査方針 |
| Copilot Studio作成者 | エージェントへのツール追加、手順作成、テスト | 目的、入力値、操作対象URL・アプリ名、失敗時の扱い |
| 開発者・自動化担当 | 既存フローやAPI連携との役割分担 | APIで処理すべき部分とGUI操作で補う部分の切り分け |
| セキュリティ担当 | 認証情報、権限、画面キャプチャ、外部モデル利用 | 最小権限、専用端末、許可リスト、ログに残る情報 |
| 業務部門 | 手作業の削減、例外対応、運用ルール変更 | どの作業を任せ、どの判断は人が確認するか |
特に重要なのは、computer useが「人間の代わりに画面を操作する」点です。作成者の権限や保存済み資格情報を使う設計にすると、共有されたエージェントを通じて想定以上の操作ができてしまう可能性があります。公式ドキュメントでも、作成者提供の資格情報を使う設定でエージェントを共有すると、利用者が元の作成者のアクセス権で構成済みマシン上の操作を行える点が警告されています。(Microsoft Learn)
利用前に満たすべき主な要件
computer useを使うには、前提条件を先に確認する必要があります。公式ドキュメントでは、対象環境のリージョンが米国に設定されていること、エージェントでgenerative orchestratorが有効であることが要件として示されています。(Microsoft Learn)
また、エージェントの生成オーケストレーションは、ツール、ナレッジ、トピックなどを説明に基づいて選択できる仕組みです。管理者が環境で生成オーケストレーションを無効にしている場合、その環境のエージェントはクラシックオーケストレーションのみを使うことになります。(Microsoft Learn)
管理者が確認する設定一覧
| 確認項目 | 確認内容 | 見落とすと起きやすい問題 |
|---|---|---|
| 環境リージョン | computer useを使う環境が対応リージョンか | 機能が表示されない、テストできない |
| 生成オーケストレーション | エージェントで有効か、管理者が環境で制限していないか | ツールを期待通り選択できない |
| モデル選択 | OpenAI Computer-Using AgentまたはAnthropic Claude Sonnet 4.5など、利用可能なモデルを確認 | 外部モデル許可が必要なモデルを選べない |
| 外部モデル設定 | Anthropicモデルを使う場合、Power Platform管理センター側の設定を確認 | モデル選択や利用がブロックされる |
| 実行マシン | Hosted browser、Cloud PC pool、Bring-your-own-machineのどれを使うか | 本番で性能、権限、管理範囲が合わない |
| 認証方式 | 作成者資格情報か、エンドユーザー資格情報か | 共有時に過剰権限が発生する |
| 保存済み資格情報 | Power Platform内部ストレージかAzure Key Vaultか | パスワード管理や監査要件を満たせない |
| アクセス制御 | 操作可能なURLやデスクトップアプリを制限するか | エージェントが想定外の画面で操作を試みる |
| 人間による監督 | レビュアー、通知、タイムアウト、対応ルール | 重要な判断をAI任せにしてしまう |
| 課金 | Copilot Creditsの消費見積もり | 試験運用後に利用量が想定より増える |
Anthropicモデルを使う場合は、外部モデル利用の管理設定も確認が必要です。Microsoftの外部言語モデル設定では、環境または環境グループ単位で外部モデルの利用を許可・制御でき、外部モデルはMicrosoftの外部でホストされる場合があると説明されています。(Microsoft Learn)
実行環境の選び方：Hosted browser、Cloud PC pool、Bring-your-own-machine
computer useは、画面を操作するためのWindows環境上で実行されます。公式ドキュメントでは、実行先としてHosted browser、Cloud PC pool、Bring-your-own-machineが示されています。(Microsoft Learn)
Hosted browserは検証向き
Hosted browserは、マシンを準備せずにWeb自動化を試しやすい選択肢です。ただし、プレビュー機能であり、本番利用は推奨されていません。Microsoft管理環境で動作しますが、テナントのMicrosoft Entra参加やIntuneポリシー管理の対象ではなく、企業リソースへのアクセス、カスタムデスクトップアプリ、組織固有のデバイス管理には対応しないと説明されています。(Microsoft Learn)
検証、デモ、限定的なWeb操作のPoCには使いやすい一方で、社内システムや本番業務に直接つなぐ前提なら、別の実行環境を検討すべきです。
Cloud PC poolはスケールと管理を重視する場合に検討
Cloud PC poolは、Windows 365 for Agentsを基盤とする選択肢です。公式情報では、Cloud PCを自動スケールできること、職場または学校アカウント連携でMicrosoft 365、SharePoint、Azureなどの組織リソースにアクセスできること、Entra参加とIntune登録により組織ポリシーで管理できることが説明されています。ただし、こちらもプレビュー扱いのため、本番展開では最新の提供状況と制限を確認してください。(Microsoft Learn)
Bring-your-own-machineは管理責任が明確
Bring-your-own-machineは、自社で所有・管理するWindowsマシンをPower Automateに登録して使う方式です。公式ドキュメントでは、Power Automate for desktopの指定バージョン以降をインストールし、Webブラウザー操作用の拡張機能も含めること、登録後にマシン設定でcomputer useを有効化することが要件として示されています。(Microsoft Learn)
本番に近い検証では、専用マシンを用意するのが基本です。日常業務で使うPCと兼用すると、画面割り込み、ログイン状態の変化、不要なアプリ、権限過多が原因で、失敗や情報漏えいリスクが増えます。
エージェントへの追加手順
Copilot Studioでcomputer useを追加する基本手順は、エージェントのToolsセクションから新しいツールとしてComputer useを選び、Name、Description、Model、Instructionsなどを設定する流れです。公式ドキュメントでは、ツールの説明文がエージェントに「いつこのツールを使うべきか」を伝える役割を持つと説明されています。(Microsoft Learn)
| 手順 | 作業内容 | 実務上のポイント |
|---|---|---|
| 目的を決める | 何を自動化するかを1つの業務に絞る | 最初から複数システム横断にしない |
| ツールを追加する | ToolsからComputer useを追加 | 既存エージェントにも追加可能 |
| 名前と説明を設定する | ツール名、短い説明を入力 | 説明は「このツールを使う条件」まで書く |
| モデルを選ぶ | OpenAI CUAまたは利用可能なモデルを選択 | Anthropic利用時は外部モデル許可を確認 |
| 手順を書く | URL、アプリ名、入力欄、完了条件を明記 | 人に作業を依頼するレベルまで具体化する |
| 追加設定を行う | マシン、資格情報、人間の監督、アクセス制御を設定 | ここを省略すると本番リスクが高い |
| テストする | 実行ログと画面プレビューを見て修正 | 失敗パターンを記録して手順に反映 |
| 公開する | 自動実行型または対話型で運用 | 対話型ではスクリーンショット表示に注意 |
Instructionsは「人に作業を引き継げる粒度」で書く
computer useの成否を大きく左右するのはInstructionsです。公式ドキュメントでも、Webサイトは完全なURL、アプリは正確なアプリ名を指定すること、送信やメール送付などの重要アクションは明示すること、複雑な操作は段階的に書くことが推奨されています。(Microsoft Learn)
悪い例は、次のような指示です。
請求書を確認してフォームに入力してください。
この指示では、どのサイトを開くのか、どの請求書を対象にするのか、入力欄はどれか、送信してよいのかが曖昧です。
実務で使うなら、次のように具体化します。
https://example.com/invoiceを開く。
日付フィルターを「過去24時間」に変更する。
一覧の最上部にある未処理の請求書PDFを開く。
PDF内の請求書番号、取引先名、請求日、金額を読み取る。https://example.com/invoice-entryを新しいタブで開く。
各項目を同名の入力欄に転記する。
入力内容を確認し、金額がPDFと一致している場合のみSubmitを選択する。
最後に、登録した請求書番号と金額をテキストで返す。
ポイントは、画面操作、判断条件、完了条件、戻り値を明確にすることです。後続のメール送信や別ツール連携に使うなら、出力をJSON形式にする指示も有効です。公式ドキュメントでも、抽出した値をプレーンテキストやJSONとして返し、別のツールへ渡す使い方が説明されています。(Microsoft Learn)
認証と資格情報の設計が最重要
computer useでは、画面上のサインインが必要になることがあります。公式ドキュメントでは、Credentials to useとして、作成者提供の資格情報とエンドユーザー資格情報が示されています。作成者提供の資格情報は自律型エージェントに適していますが、共有時には利用者が元の作成者のアクセス権で操作できる可能性があるため注意が必要です。(Microsoft Learn)
作成者資格情報とエンドユーザー資格情報の使い分け
| 認証方式 | 向いているケース | 注意点 |
|---|---|---|
| 作成者提供の資格情報 | バックグラウンドで自律実行する定型業務 | 共有範囲を誤ると、作成者権限で操作される可能性がある |
| エンドユーザー資格情報 | 利用者ごとの権限で処理したい対話型業務 | 各利用者が実行マシンへの適切な資格情報を持つ必要がある |
| 保存済み資格情報 | サイトやアプリへのサインインを自動化したい場合 | パスワード保管、Key Vault利用、監査要件を確認する |
保存済み資格情報は、Power Platform内部ストレージまたはAzure Key Vaultを使う選択肢があります。Azure Key Vaultを使う場合は、サブスクリプションID、リソースグループ名、Key Vault名などを指定し、Power Platform側のリソースプロバイダー登録やKey Vault権限も確認する必要があります。(Microsoft Learn)
また、パスワード入力欄のサポートは多くのWebサイトやWindowsアプリを対象としていますが、Electron、Java、Unity、ゲーム、コマンドライン、Citrix、その他の仮想化環境など、一部のアプリ種別では対応しない可能性があるとされています。該当する業務アプリを使う場合は、早い段階で検証してください。(Microsoft Learn)
アクセス制御は「開けない」ではなく「操作させない」設計で考える
computer useのAccess controlでは、操作対象のWebサイトやデスクトップアプリを制限できます。デフォルトでは任意のWebサイトやアプリを操作できるため、本番展開では許可リスト方式を検討すべきです。(Microsoft Learn)
ただし、重要な注意点があります。公式ドキュメントでは、Access controlは許可リスト外のWebサイトやアプリ上での操作を防ぐものであり、開くこと自体を止めるわけではないと説明されています。たとえばMicrosoft Edgeとmicrosoft.comだけを許可していても、Edgeの検索バーからBingを開くことはできる可能性があり、Bing上での操作は失敗する、という整理です。(Microsoft Learn)
そのため、Access controlだけでなく、次の対策を組み合わせる必要があります。
- 専用マシンを使う
- 利用アカウントを最小権限にする
- ブラウザー側のポリシーでアクセス先を制限する
- 不要なアプリをインストールしない
- 重要操作の前に人間の確認を入れる
- 実行ログと画面プレビューを定期的に確認する
Microsoftも、専用マシンの利用、最小権限、信頼済みWebサイトの許可リスト化、必要なデスクトップアプリだけを利用可能にすることをセキュリティ上の推奨事項として示しています。(Microsoft Learn)
Human supervisionは安全装置ではなく、補助的な確認手段
Human supervisionは、computer useエージェントが確認や追加情報を必要としたとき、設定したレビュアーにエスカレーションできる機能です。確認依頼はOutlookメールやCopilot Studioのアクティビティパネルで処理できます。(Microsoft Learn)
ただし、これを「必ず危険操作を止めてくれる安全装置」と考えるのは危険です。公式ドキュメントでは、人間への確認要求は確率的なAIモデルの挙動に基づくため、人が停止してほしい場面で必ず発生するとは限らず、逆に不要な場面で発生することもあると説明されています。(Microsoft Learn)
レビュアーの運用ルールも重要です。確認依頼への回答には、ユーザー名、パスワード、PIN、クレジットカード情報、社会保障番号のような機密情報を入力しないよう注意が示されています。組織の構成によっては、回答がDataverse環境やPurview監査ログに保持され、権限を持つユーザーから見える可能性があります。(Microsoft Learn)
課金：1回の実行ではなく「ステップ数」で見積もる
computer useの利用量は、Agent action機能を通じて課金され、公式ドキュメントでは5 Copilot Creditsの課金率が示されています。各computer use実行はAIモデルが一連のステップを実行し、クリック、入力、ナビゲーションなどの低レベル操作を含むステップごとに5 Copilot Creditsを消費すると説明されています。(Microsoft Learn)
たとえば、勤怠フォーム入力で次の4ステップを実行する場合、合計20 Copilot Creditsになります。
| ステップ | 操作例 | 消費の考え方 |
|---|---|---|
| 1 | ブラウザーを起動して勤怠ポータルへ移動 | 5 Copilot Credits |
| 2 | 新規勤怠を作成 | 5 Copilot Credits |
| 3 | 開始時刻、終了時刻、プロジェクトコードを入力 | 5 Copilot Credits |
| 4 | 送信ボタンを選択 | 5 Copilot Credits |
本番展開前は、1回あたりの平均ステップ数、1日の実行回数、失敗時の再実行回数を含めて見積もることが重要です。Copilot Studioの課金ページでも、Computer-Using AgentsはAgent actionの課金率で扱われると説明されています。(Microsoft Learn)
失敗しやすいポイントと対策
computer useは便利ですが、AIが画面を見て操作する仕組みである以上、UIの変化や曖昧な指示に影響されます。公式FAQでは、Webベースのタスクでは成功率が比較的高い一方、デスクトップアプリでは大きく下がること、同じタスクでも画面やタイミングの変化で結果が変わること、ドロップダウンや日付ピッカーなど非標準・動的なUIで難しさがあることが既知の制限として挙げられています。(Microsoft Learn)
| よくある失敗 | 主な原因 | 対策 |
|---|---|---|
| 違う画面を操作しようとする | URLやアプリ名が曖昧 | 完全なURL、正確なアプリ名、画面タイトルをInstructionsに入れる |
| 途中でループする | 期待したボタンや入力欄が見つからない | 分岐条件、戻る手順、停止条件を明記する |
| 入力欄を間違える | ラベルが似ている、画面が複雑 | 入力順、項目名、確認条件を具体的に書く |
| 送信してはいけない内容を送信する | 重要アクションの許可条件が曖昧 | 「一致した場合のみSubmit」など条件を書く |
| 認証で止まる | 資格情報やMFAの扱いが未設計 | 認証方式、保存済み資格情報、手動確認フローを整理する |
| 利用量が増える | 1タスクのステップ数が多い | 手順を短くし、APIやフローで置き換えられる部分を分離する |
| セキュリティレビューで止まる | ログ、スクリーンショット、資格情報の扱いが未整理 | 専用マシン、最小権限、監査、データ保持を先に設計する |
特に、採用、医療、金融のようなセンシティブな領域での評価・スコアリング、金融取引、スパムや誤情報など有害な行為、適切な承認なしに組織外へデータを共有する用途は、公式FAQでも意図された利用対象ではないとされています。(Microsoft Learn)
移行・展開時の判断基準
既存の業務をcomputer useへ移すときは、「できるか」ではなく「任せてよいか」で判断する必要があります。
computer useに向いている業務
次の条件を満たす業務は、computer useの候補になります。
- APIやコネクタがない
- 人が画面を見れば判断できる
- 操作手順を文章で説明できる
- 失敗しても取り返しがつく
- 専用マシンや最小権限アカウントで実行できる
- 入力値や出力値を明確に定義できる
- 送信や登録の前に確認条件を置ける
具体例としては、請求書PDFから社内フォームへの転記、在庫管理画面への商品登録、ポータル上の一覧から特定項目を抽出してJSONで返す処理などが考えられます。公式ドキュメントでも、自動データ入力、請求書処理、データ抽出が利用例として挙げられています。(Microsoft Learn)
computer useを避けるべき業務
次のような業務は、少なくとも初期導入では避けた方が安全です。
- 金融取引や支払い実行など、誤操作の影響が大きい業務
- 採用、医療、金融などセンシティブ領域の評価や判断
- 大量の個人情報や機密情報を画面上で扱う業務
- UIが頻繁に変わる業務
- Citrixなど仮想化環境や特殊なアプリでの操作
- 完全な再現性と厳密な監査証跡が求められる処理
- 既に安定したAPIやコネクタで処理できる業務
APIで安定して処理できる部分までcomputer useへ置き換える必要はありません。むしろ、API・Power Automate・デスクトップフロー・computer useを役割分担し、GUI操作が必要な部分だけをcomputer useに任せる設計が現実的です。
開発者が設計時に意識すべきポイント
開発者や自動化担当者は、computer useを単独機能としてではなく、エージェント全体の一部として設計する必要があります。
入力値はInputsで動的に渡す
毎回変わる値は、Instructionsに固定で書くのではなくInputsとして定義します。たとえば、顧客ID、請求書番号、対象日付、商品コードなどを入力として受け取り、実行時にcomputer useの操作に組み込む形です。公式ドキュメントでも、毎回変わる値をInputsで定義し、実行時にInstructionsと入力値を組み合わせる使い方が説明されています。(Microsoft Learn)
出力は後続処理で使いやすい形式にする
データ抽出が目的なら、最終出力をプレーンテキストではなくJSONにする設計が有効です。たとえば、次のように返す形式を指定します。
{
"invoiceNumber": "INV-12345",
"vendorName": "Contoso Ltd",
"invoiceDate": "2026-05-08",
"amount": "120000"
}この形式にしておくと、後続のメール送信、承認フロー、データ登録ツールに渡しやすくなります。公式ドキュメントでも、抽出した情報をJSON形式で返すよう指示できることが説明されています。(Microsoft Learn)
ツールのDescriptionは短くても具体的にする
生成オーケストレーションでは、エージェントがツールやトピックを説明文に基づいて選択します。説明が曖昧だと、別のツールを選んだり、必要な場面でcomputer useを呼び出さなかったりします。Microsoftの生成オーケストレーションの説明でも、ツールやトピックのDescriptionがユーザー意図と適切に結び付ける重要な要素として説明されています。(Microsoft Learn)
悪いDescriptionは次のようなものです。
画面操作をします。
良いDescriptionは、用途と発動条件が分かります。
請求書PDFから請求書番号、取引先名、請求日、金額を読み取り、社内の請求書登録Webフォームへ転記する必要がある場合に使用します。
本番展開前チェックリスト
公開前には、少なくとも次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 対象業務 | APIや既存コネクタで処理できない理由が明確か |
| リージョン | 利用環境がcomputer useの要件を満たしているか |
| オーケストレーション | 生成オーケストレーションが有効か |
| 実行マシン | 専用マシン、Cloud PC、Hosted browserの選択理由が明確か |
| 権限 | 実行アカウントが最小権限になっているか |
| 資格情報 | 作成者資格情報とエンドユーザー資格情報の使い分けを決めたか |
| 保存先 | パスワードをPower Platform内部に置くか、Azure Key Vaultを使うか決めたか |
| アクセス制御 | 許可するURLとアプリを限定したか |
| Instructions | URL、アプリ名、入力項目、判断条件、完了条件を書いたか |
| 出力形式 | テキスト、JSON、後続ツール連携の形式を決めたか |
| 人間の監督 | レビュアー、タイムアウト、回答ルールを決めたか |
| セキュリティ | プロンプトインジェクション、不要アプリ、Webアクセス制限を確認したか |
| 課金 | 1回の平均ステップ数と月間実行回数でCopilot Creditsを試算したか |
| 例外処理 | 失敗時に停止するか、人へ引き継ぐか決めたか |
| ログ確認 | テスト実行の画面プレビューとアクティビティを確認したか |
まずは低リスク業務で小さく検証する
Microsoft Copilot Studioのcomputer useは、APIがない画面操作をエージェントに任せられる強力な機能です。特に、請求書処理、データ入力、Web画面からの情報抽出など、これまで人が画面を見ながら繰り返していた作業に効果が期待できます。
一方で、AIがGUIを操作する以上、曖昧な指示、UI変更、認証、過剰権限、外部モデル利用、課金増加といったリスクがあります。最初から重要業務へ広げるのではなく、低リスクで手順が明確な業務を選び、専用マシン、最小権限、アクセス制御、明確なInstructions、テストログ確認をセットで進めることが重要です。
次に取るべき行動は、社内の手作業リストから「APIがなく、画面操作が定型で、失敗時にやり直せる業務」を1つ選ぶことです。その業務について、操作対象URL、アプリ名、入力値、完了条件、権限、想定ステップ数を書き出せば、computer useを導入すべきか、従来のAPI連携やPower Automateで十分かを判断しやすくなります。
コメント