2026年9月15日 8:00 PM

第6回：全社に増えたエージェント、その座席表は誰が更新するのか

全社の「座席表」を支える Microsoft Agent 365 と Windows 365 for Agents

Cloud Endpointsと呼んでいる、Windows 365やAzure Virtual Desktopのソリューションエンジニアを務める曳野 (ヒキノ) と申します。「SE曳野の仮想デスクトップとAI」と題して、私たちの仮想デスクトップサービスとAIやエージェントの関係性を中心にブログをお届けしています。第6回は、1つの現場で育った座席表を、全社へ広げるお話です。執筆者：日本マイクロソフト株式会社　クラウド＆AIソリューション事業本部　ソリューションエンジニア曳野洋幸 | 2026年9月15日

はじめに：夜勤室の座席表を、全社へ

前回は、運用・監視の夜勤室に、座席表と白紙のノートを置きました。繰り返す判断から手順の候補を見つけ、候補には実行させず、従来の判断と並走させて確かめる。人が承認したものを、次の仕事に使う。作業する席を返しても、そのノートは残ります。

今回は、その座席表を組織全体へ広げます。

ある部門でうまくいけば、隣の部門からも「うちでも使いたい」と声がかかります。席が増え、ノートも増える。ところが、最初に導入した担当者が、すべての席の事情を知っているわけではありません。誰に聞けばよいのか分からない席が、少しずつ生まれます。

第2回の「社員証とスポンサー」が、ここで戻ってきます。社員証を発行しただけでは、その人の異動や担当変更まで面倒を見たことにはなりません。エージェントも同じです。

席を増やすことと、その席の責任を更新し続けることは、別の仕事です。

その仕事を、誰が、いつ、どう引き継ぐか。今回は Microsoft Agent 365 と Windows 365 for Agents を通じて考えます。

隣の部門にも、同じ名前の席ができた

「申請確認エージェントなら、うちでも使っていますよ。」

情報システム部門と総務部門を例にした、架空の場面です。どちらの部門も、申請内容を確認するエージェントを使っています。名前が同じなら、まとめて管理できそうに見えます。

しかし、座席表を近づいて読むと、違いが見えてきます。

名前は同じでも、読む情報も、越えてはいけない線も違います。情報システム部門の手順で「確認済み」とした申請が、総務部門でも同じ意味になるとは限りません。

そして、総務の責任者に聞きたいとき、作った人の名前しか載っていなければ困ります。全社に広げる際に必要なのは、名前を統一することだけではありません。同じ名前の席を、責任と権限で見分けられることです。

全社の座席表には、何を書き足すか

1つの現場なら、「あの席は誰の担当か」を周囲が覚えています。全社では、その暗黙の了解を座席表に書き足す必要があります。

例えば、次の情報です。これは、社内の運用を設計する際にそろえたい項目の提案です。

大切なのは、全部門の申請内容やノート本文を、1枚の表へ集めることではありません。全社で必要な管理情報と、権限のある人だけが開ける業務記録の所在を結ぶことです。

座席表を見れば責任者が分かる。その責任者に確認すれば、必要な記録にたどり着ける。この関係を作っておけば、機密情報を全社へ広げずに、管理の見通しをよくできます。

座席表の置き場に、名前を付ける：Microsoft Agent 365

どの席があり、誰が責任を持ち、どんな活動をしているか。その共通の管理を支えるのが、Microsoft Agent 365 です。

Microsoft 365管理センターのレジストリ、つまりエージェントの登録・管理の仕組みを通じて、管理対象を把握します。さらに、Microsoft EntraによるIDとアクセスの管理、Microsoft Purviewによる情報の保護、Microsoft Defenderによる脅威への対処と組み合わせます。

Microsoft Agent 365の概要では、次の3つが柱として示されています。

Microsoft Agent 365は、2026年5月1日から商用向けに一般提供されています。ただし、個別機能の提供状況やライセンス条件は、それぞれ確認が必要です。

また、対象プラットフォームや連携・設定・ライセンスによって、可視化や保護を適用できる範囲は異なります。 導入時には、使っているエージェントが管理対象に入っているかを確認します。

この記事の「全社の座席表」は説明のための比喩です。先ほど提案した業務上の台帳項目が、すべて製品画面の標準項目として用意されている、という意味ではありません。製品の管理情報と社内の業務記録を結び、運用として完成させます。

社員証の先に、技術担当と業務責任者を置く

社員証を見れば、誰かは分かります。しかし、「この仕事を任せてよいか」と「接続設定を直せるか」は、社員証だけでは決まりません。

第2回でご紹介した Microsoft Entra エージェント ID は、エージェントを識別する基盤です。その管理では、技術的な管理と業務上の責任を分けます。

スポンサーには、エージェントIDの無効化や、復元可能な削除などの限定された権限があります。一方で、アプリの設定変更や、無効化後の再有効化、削除後の復元はできません。必要な場合は所有者や管理者に依頼します。

例えば総務の責任者がスポンサーと手順承認者を兼ねることはあります。それでも、「この席を使い続ける判断」と「この手順を承認する判断」は分けて記録します。 人が代わったとき、何を引き継ぐべきかが分かるからです。

全社で決めること、現場で決めること

全社の座席表を持つと、すべての判断を情報システム部門へ集めたくなるかもしれません。しかし、総務の購入規程に合っているかを、エージェントの管理者だけで決めるのは無理があります。

共通にするのは、判断の中身すべてではなく、責任を持って判断できる状態を作るための基準です。

例えば全社では「責任者の確認なしに利用を延長しない」と決めます。その席が来月も必要かは、現場が判断します。全社管理の担当は、判断が行われたか、未回答を誰へ知らせるかを受け持ちます。

全社管理は、現場の判断を取り上げることでも、各部門の機密ノートを全員に見せることでもありません。

上司が異動したら、誰が引き継ぐか

総務の責任者が異動しました。人の引継書には予算や進行中の案件が載っています。しかし、エージェントのスポンサーを引き継ぐ話は、抜けているかもしれません。

そこで、人の異動・退職の確認項目に、その人が責任を持つエージェントを加えます。

Microsoft Entra ID Governanceには、スポンサーが組織を離れる際、その人の上司（マネージャー）へスポンサーシップを自動移管する仕組みがあります。Lifecycle Workflowsでは、共同スポンサーやスポンサーの上司へ、スポンサー変更に関する通知を行えます。

ただし、異動と退職のすべてが同じ処理になるわけではありません。登録上の移管と、後任が業務を理解して引き受けることも別です。

自動移管を「あらゆる場合に責任者不在を防げる保証」とは扱いません。後任が決まらない場合や通知に応答がない場合も含めて、運用を設計します。引継ぎの完了条件は、名前が書き換わったことだけではないのです。

使わない席は、権限ごと見直す

プロジェクトが終わっても、座席表にはエージェントが残っています。最近は動いていない。けれど、申請データを読める権限は残ったままです。

「使っていないから問題ない」とせず、使う必要がなくなった時点で、その席とアクセスを見直します。

Microsoft Entra ID Governanceでは、エージェントIDに必要なアクセスを、アクセスパッケージとしてまとめて扱えます。申請、承認者、利用期限、延長の条件を設定する枠組みです。

期限付きの割当てでは、スポンサーへの期限通知を受けて、ポリシーで許されていれば延長を申請できます。設定に応じて再承認を求めることもでき、延長しなければ期限日に割当てが終了します。これは、そのパッケージで付与したアクセスの管理であり、別経路の権限も含めた全体の棚卸しは必要です。

棚卸しで見つけた状態	判断・対応の例
業務は続いている	目的、実際の利用、必要な権限を確認して継続する
月末など限られた時期だけ使う	利用回数だけで廃止せず、必要な時期と権限を確認する
業務が終わった	未完了案件を引き継ぎ、不要なアクセスやIDの扱いを決める

このエージェントIDのガバナンス機能には、Microsoft Agent 365に加えてMicrosoft Entraの基礎ライセンスを組み合わせるなど、所定のライセンス要件があります。詳細は公式の概要とライセンス要件を確認してください。

また、IDを無効化しても、外部アプリですでに行った処理や保存済みの承認まで取り消せるわけではありません。止める操作と、その後の業務整理は分けて考えます。

部門のノートを、そのまま全社に配らない

第5回のノートが厚くなってきました。「この申請なら、この順番で確認する」という手順が残っています。隣の部門にも役立ちそうです。

ただ、ノートには手順だけでなく、その現場の前提も書き込まれています。担当者がすぐ応答できる時間帯、参照してよい情報、判断を保留する条件。書かれていない前提もあるでしょう。

ここでいう「ノートが育つ」とは、人が検証し、承認した手順が蓄積することです。モデルの自動再学習や、Microsoft製品による手順の自動生成・自動承認を指すものではありません。

他部門で使う前の再検証

共有するなら、まず業務固有のデータと、再利用できる手順の候補を分けます。そのうえで、受け取る部門の条件で確かめます。

例えば情報システム部門では、必要項目がそろえば担当者へ回せる申請でも、総務部門では金額によって承認先が変わるとします。共通にできるのは「不足を確認する流れ」であって、承認先まで同じにはできません。

受け取る部門で検証用データを用意し、人の判断と並走させます。通常の申請だけでなく、記載不足、判断が分かれるケース、引継ぎ先が不在の場合も確認します。結果を見て、その部門の手順承認者が適用範囲を決めます。

共有するのは、使えるかもしれない手順。任せる許可は、使う現場で確かめ直します。

承認後の見直し

一度承認した手順も、使い続けてよいとは限りません。申請画面が変わる、購入規程が改定される、参照先が変わる。昨日まで正しかった確認が、今日は足りなくなることがあります。

ノートには、少なくとも次を添えます。

添える情報	この例での書き方
版と適用範囲	総務向け第1版。備品申請の必要項目確認だけに使用
承認者と期限	承認した担当者、承認日、次の見直し日を記録
撤回条件	規程や画面の変更、想定外の判定を検知したら対象手順を止める
停止時の引継ぎ	未完了の申請と判断根拠を残し、総務の申請窓口へ渡す

定型化は、確認を不要にすることではありません。承認後も結果を確かめ、前提が変われば適用を止めて再検証します。全社へ紹介するのは再利用候補の概要と管理情報にとどめ、詳細なノートやログの閲覧権限は別に管理します。

実際に動く席を支える：Windows 365 for Agents

ここまでの座席表は、誰が何を担当し、何を任されているかを管理するものです。一方、申請システムのWindows画面を開いて作業するなら、実際に動く場所も必要です。

その場所を提供するのが、Windows 365 for Agents です。エージェント向けのCloud PCを、Microsoft Entra IDとMicrosoft Intuneで管理します。APIなどで完結する処理まで、すべてCloud PCで動かす必要はありません。

見る対象	答える問い	主に支える製品
エージェントと、その責任・アクセス	何のための席か。誰が責任を持つか	Microsoft Agent 365、Microsoft Entra
作業するCloud PCとセッション	どこで動かすか。同時にどれだけ動かすか	Windows 365 for Agents

管理するエージェントIDの数と、同時に必要なCloud PCセッション数は、別の尺度です。 1エージェントに1台を常時固定する前提ではありません。管理者はプールを基に実行環境を管理し、Microsoft Agent 365で利用する際は、エージェント用のプロビジョニングポリシーでチームや業務をまとめます。

作業の流れは、準備し、席を借り、接続して作業し、返す、というものです。返却時には接続が閉じられ、Cloud PCがリセットされ、容量がプールへ戻ります。続きに必要な状態は、外部へ途中経過として保存しておく必要があります。

ここでも、第5回のノートが効きます。承認済み手順、実行結果、未完了案件は、席の中だけに置きません。保存先と閲覧権限を決め、席を返した後も、必要な人が確認できるようにします。

プールを利用できる対象は設定できますが、Cloud PCを使えることと、業務データを読める・書けることは別です。 プールを分けるだけで、データの権限まで自動的に分離されるわけではありません。

人が同じセッションを観察し、必要に応じて引き継ぐこともできます。ただし、ノートの保存先や手順の承認、業務判断の正しさまでCloud PC単体が提供・保証するわけではありません。動く席と、その席を任せる仕組みを、組み合わせます。

2部門への展開を、ひとつ追ってみる

冒頭の架空の例に戻りましょう。情報システム部門で使っていた申請確認の仕組みを、総務部門にも展開します。今回は、責任と権限を分けるため、部門ごとに別のエージェントIDで管理する設計とします。

最初にコピーするのは、元の席の権限一式ではありません。必要項目を確認し、不足があれば担当者に渡す、という仕事の候補です。

段階	この例で行うこと	座席表に残すこと
仕事を分ける	総務では備品申請の確認に限定。購入決裁や発注は人が担う	業務目的、任せる操作、任せない操作
責任とアクセスを決める	総務のスポンサー、技術担当、手順承認者を決め、必要な参照権限を申請する	担当者、承認記録、アクセスの期限
並走して確かめる	金額によって承認先が変わるケースを含め、人の確認結果と比較する	検証結果、総務向け手順の版と適用範囲
運用へ移す	承認後に限定した範囲で実行し、例外は総務の申請窓口へ渡す	開始日、見直し日、停止条件、記録先

Windows画面の操作が必要な部分では、Windows 365 for Agentsの利用対象と実行環境を設定します。同時に必要な席の量は、IDの登録数ではなく、申請が重なる時間帯や作業時間から考えます。

運用中に購入規程が変わったら、総務の手順承認者が影響を確認します。影響する手順を止め、未完了の申請を人へ渡し、修正と再検証を行います。技術担当は必要な設定変更を担い、スポンサーは、その間にどこまで仕事を任せるかを判断します。

情報システム部門の手順まで、理由なく一緒に差し替える必要はありません。変更がどの部門のどの版に及ぶかを、座席表からたどれるようにしておきます。

同じ種類のエージェントを増やしても、責任までコピーしたことにはなりません。新しい席には、その仕事に合った責任と、検証済みのノートを添えます。

全社の座席表も、測って見直す

座席表は、登録した日に完成するものではありません。仕事が変わり、人が異動し、ノートが改訂される。その変化についていけているかを測ります。

次は、製品の標準レポート項目ではなく、運用で追いたい指標の例です。

見るもの	結果を受けて見直すこと
責任者の未確認、引継ぎの未完了	後任確認と、未回答を知らせる経路
期限切れ・不要なアクセスの残存	延長承認、権限の回収、確認対象の漏れ
見直し日を過ぎた手順、撤回後も残る参照	手順の更新と、利用を止める仕組み
誤判定、例外の見逃し、人への引継ぎ遅れ	任せる範囲、停止条件、担当者の配置
作業待ちとCloud PCの利用状況	同時実行容量と、作業を始めるタイミング

例えば、月1回の定期確認に、異動・業務終了・規程改定時の確認を組み合わせる運用が考えられます。頻度は一律の製品要件ではなく、業務の影響に応じて決めます。

「登録したエージェントが増えた」「人への引継ぎが減った」だけでは、うまく運用できているとは言えません。必要なときに止まり、必要な人へ渡せているかも、合わせて確認します。

測る → 責任と権限を見直す → 座席表と手順を更新する → また測る。

まとめ：席を増やすなら、責任を更新する仕組みも

第3回で描いた座席表に、第5回ではノートを添えました。全社へ広げる今回は、そこに「誰が、いつ、何を更新するか」を書き足しました。

Microsoft Agent 365で管理対象を把握し、Microsoft EntraでIDと責任・アクセスを管理する。Windows画面での作業には、Windows 365 for Agentsで動く席を用意する。そして、業務の目的と手順の承認は、担当する人が引き受けます。

最初の一歩は、あなたのチームと隣の部門から、似た仕事をする席を1つずつ選ぶことです。技術担当、スポンサー、手順承認者、権限の期限、次の見直し日を並べてください。空欄があれば、誰がいつ埋めるかを決めます。

全社の座席表を更新するのは、たった1人の管理者ではありません。共通の基準を持つ担当と、仕事を知る現場が、決めた契機で一緒に更新します。

席を増やすなら、その席を任せる責任も、更新し続ける仕組みにする。