Copilotが退勤後も動く、Autopilot導入前に決める権限の線

|著者: QUASA編集チーム|2 分で読めます| 1
Copilotが退勤後も動く、Autopilot導入前に決める権限の線

Microsoftは2026年9月25日の Copilot刷新の公式発表 で、Home、Code、Autopilotを打ち出し、Autopilotの非公開プレビューを月末に拡大する予定を示した。Autopilotはクラウド上で動き、利用者が退勤した後も任された仕事を続ける設計だ。ただし、一般提供が始まったという発表ではない。

従来のCopilotとの違いは、質問への回答や一件の作業で終わらず、役割と目標を与えられて案件の動きを追い続ける点にある。管理者が決めるべき権限も、資料を読めるかだけでは足りない。本人不在時に何を続け、誰に連絡し、どのデータを変更し、どこまで費用を使えるかを、それぞれ別の境界として扱う必要がある。

Home、Code、Autopilotは何を任せる場所か

HomeはCopilotの入口で、短い質問や下書きに使うChatと、成果物ができるまで作業を委ねるCoworkをまとめる。Word、Excel、PowerPointの文書をCopilot内で作成・編集する機能もここに位置づけられる。Coworkでは利用者が作業を指定し、完了した結果を受け取る。Autopilotでは役割と目標を与え、会話や案件の変化に応じた継続的な働きを任せる。

Codeは自然言語の指示からアプリ、追跡用ツール、自動化などを作る領域だ。生成されたアプリがどのデータや接続先を使えるかという問題と、Autopilotが誰として行動し、いつまで仕事を続けるかという問題は分けて考えられる。Copilotという同じ入口に並んでも、管理する主体と実行の続き方は同じではない。

この違いは費用にも及ぶ。日常的なChatやOfficeアプリでの利用はユーザー単位の契約で扱われる一方、Cowork、Code、Autopilotの長時間に及ぶ作業には利用量に応じた課金が示されている。継続する役割を与える場合、許可した操作だけでなく、その仕事に使う予算も管理対象になる。

独自のIDを持つエージェントは、誰の権限で動くのか

Autopilotは、以前Scoutと呼ばれていたエージェントだ。組織のテナント内に独自のID、記憶、コンピューター、ワークスペースを持つと説明されている。チャンネルの動きを追い、スレッドで確認し、繰り返しの仕事を進め、数日後に案件を再開する。TeamsやOutlookなど、人が日常的に使う場所にも現れる。

示された仕入先レビューの例では、日程と準備を整え、会議後の対応を進め、関係者に更新を求める。これは製品が想定する利用場面であり、顧客環境での成功率を示す実績ではない。それでも、担当者がその場で指示し直さなくても連絡や確認が続くという設計上の違いは明確だ。

独自のIDがあれば、エージェントを人間の担当者と区別して扱える。しかし、IDの存在だけでは、参加できるチャンネル、参照できる資料、送信や変更が許される対象は決まらない。目標を「レビューを進める」と広く与えても、社内の関係者に確認する権限と、組織外へ確定した内容を伝える権限は別である。

継続実行、外部連絡、更新、支出の境界

導入判断では、Autopilotが動き続けることを前提に、次の場面を分けて整理できる。これは発表された動作から導く管理上の確認事項であり、各項目に対応する設定画面や自動停止機能がすべて提供済みだという意味ではない。

  • 本人不在時の実行：監視する会話や案件、継続する期間、仕事を終える条件を決める。担当者が休暇に入ったり、異動したり、案件が終了したりした後も同じ目標で動かすのか。停止や引き継ぎを人が判断するなら、その責任者も必要になる。
  • 外部連絡：Teamsなどでの社内確認と、組織外の相手への連絡を分ける。仕入先レビューで更新を求める場合でも、文面の作成まで任せるのか、送信まで認めるのかで境界は変わる。外部宛ての送信にどの承認手順を適用できるかは、利用するプレビューの実装で確認すべき点だ。
  • データ更新：資料を参照する権限と、共有ファイルや業務データを書き換える権限を分ける。どの記録を正本とし、どの変更に人の確認を要するかが曖昧なら、情報を見つける能力と更新する権限が混同される。発表された仕入先レビューの例だけから、あらゆる業務システムの更新が可能だとは判断できない。
  • 支出：対象部門、利用できる予算、追加クレジットを認める手順を決める。継続する作業では、一回の指示だけを見ても総費用は分からない。残高の表示や利用履歴は判断材料になるが、案件の目的が失われたときに仕事を止める条件とは別に扱う。

これらを一つの「利用許可」にまとめると、読むこと、連絡すること、変更すること、費用を使うことの違いが見えなくなる。管理者に必要なのは、エージェントへ与える目標に対して、利用できる情報と実行できる操作を対応させることだ。特に本人が不在でも動く以上、途中で人の判断へ戻す条件は導入時の論点になる。

Managed Runtimeが管理するのは生成アプリ

Microsoftの Managed Runtimeの公式説明 によると、この基盤は公開プレビューで、Cowork、Code、Copilot Studioなどで作ったアプリをMicrosoft 365のテナント内で動かす。Microsoft Entraによる認証、接続先やデータに適用する組織のポリシー、管理センターでのアプリ一覧と監視が示されている。

ここで管理される主な対象は、生成・配備されたアプリの実行環境だ。管理者はアプリへのアクセス、利用状況、健全性、ポリシーを共通の一覧から確認できる。一方、Autopilotが持つ独自のコンピューターやワークスペースについて、アプリ向けの管理画面がそのまま行為別の承認画面になるとは説明されていない。

したがって、Codeで作った社内ツールを配備する判断と、Autopilotに案件の継続を任せる判断は別に行う必要がある。前者ではアプリの利用者と接続先、後者ではエージェントの活動範囲と人へ戻す条件が中心になる。両方に管理機能があるという説明だけでは、片方の設定がもう片方の行動を制御すると結論づけられない。

費用管理は示されたが、操作別の条件は残る

管理者向けには、支出ポリシーのAPI管理、追加クレジットの申請を既存の承認フローへ送る仕組み、利用者グループごとに使えるモデル群の指定が示されている。利用者が消費量、残高、履歴を確認する機能も発表された。ただし、費用の承認と、Autopilotが個々の連絡や変更を実行する際の承認は同じ仕組みではない。

独立した VentureBeatの報道 も、継続型エージェントへの変更を確認する一方、発表資料には作業ごとの詳細な料金や、行為別の承認方針、失敗した実行への対応が十分に示されていないと指摘している。権限、監査、管理が用意されるという説明を、あらゆる操作の承認条件や自動停止条件が確定したという意味には広げられない。

HomeとCodeはFrontierプログラムで順次展開され、Autopilotは月末に非公開プレビューを拡大する予定だ。現段階で確認できるのは、継続実行する設計と管理・費用管理の方向性までである。実際に設定できる操作の境界と詳細な請求条件は、プレビューで提供される機能と追加の案内を待つ必要がある。

関連記事:

共有:

関連記事

ニュースレターを購読

Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。

0