Cloud Endpoints と呼んでいる、Windows 365 や Azure Virtual Desktop のソリューション エンジニアを務める曳野（ヒキノ）と申します。「SE曳野の仮想デスクトップとAI」と題して、私たちの仮想デスクトップサービスとAIやエージェントの関係性を中心にブログをお届けしています。第3回目のテーマは「あなたのチームに、エージェントは何体必要か」です。
第1回では、エージェントを「どこで動かすか」という問いから、管理された実行環境である Windows 365 for Agents をご紹介しました。第2回では、“社員証”にあたる Microsoft Entra エージェント ID と、“上司”にあたるスポンサーの必要性をお話ししました。職場があり、社員証があり、上司もいる。では、もうチームとして働き始められるでしょうか。実は、もう一枚だけ必要なものがあります。それが、人とエージェントの“座席表”です。ただし、紙に印刷して固定する座席表ではありません。ゴールと需要に応じて必要な席が現れ、仕事が終われば戻っていく――そんな“動く座席表”です。
執筆者：日本マイクロソフト株式会社 クラウド＆AIソリューション事業本部 ソリューション エンジニア 曳野 洋幸 | 2026年8月1日
はじめに：正解は「人1人に対してエージェント3体」ではない
前回の最後に、こんな問いを残しました。
あなたの部門に、エージェントは何体必要なのか？
「人1人に対してエージェント3体」「10人のチームなら30体」。そんな分かりやすい基準を期待されたかもしれません。しかし、最初に結論をお伝えすると、全社共通で使える“正解の比率”はありません。
Microsoft の 2025 Work Trend Index でも、これからの組織には 人とエージェントの比率（human-agent ratio） という新しい指標が必要になる一方、その比率は役割・業務・プロジェクトごとに決める タスク固有のものだと説明しています。
そもそも、「1体」をどう数えるかも一通りではありません。目的の異なるエージェントの役割数を数えるのか、繁忙時に同時稼働するセッション数を数えるのか。それとも、1人の人間が監督できるエージェントの運用上の受け持ち数を数えるのか。これらは別の数字です。この区別が、後ほどご紹介するエフェメラル（短命）な配置を理解する鍵になります。
だから、エージェントの数から考え始めてはいけません。先に考えるべきなのは、誰が、どの仕事を、どこまで受け持つかです。
この記事を読み終わる頃には、単に「何体導入するか」ではなく、あなたのチームの最初の“座席表”を描くための考え方を説明できるようになっています。
座席表に書くのは、人数ではなく「仕事の持ち方」
学校やオフィスの座席表を思い浮かべてください。座席表を見れば、誰がどこにいて、誰の隣で、困ったときに誰へ声をかければよいかが分かります。
人とエージェントの座席表にも、同じ3つを描きます。
- 担当：その仕事の主担当は、人か、エージェントか。
- 引き継ぎ：どの条件になったら、隣の席へ仕事を渡すか。
- 監督：品質を誰が確認し、最終的な責任を誰が持つか。
業務を分解すると、座席は大きく3種類に分かれます。
| 座席 | 向いている仕事 | 仕事の進め方 |
|---|---|---|
| エージェント席 | 件数が多い、手順が安定している、結果を客観的に確認できる、失敗しても戻せる | エージェントが端から端まで実行し、人は全体を監督 |
| 共同席 | 文脈や確認が必要だが、準備・調査・下書きは定型化できる | エージェントが準備し、人が判断・承認して完成 |
| 人の席 | 共感、交渉、倫理的判断、高額な決裁、やり直せない判断が必要 | 人が主担当となり、エージェントは必要に応じて支援 |
ここで大切なのは、「エージェントにできるか」だけで席を決めないことです。技術的には自動化できても、顧客が人との対話を望む場面があります。処理精度が高くても、社会や会社が人に責任を求める判断もあります。
反対に、人が長時間かけている仕事でも、入力と正解が明確で、失敗を検知してやり直せるなら、エージェント席に移しやすい仕事です。
つまり座席を決める基準は、能力だけではありません。効率、人の選好、そして判断の責任を合わせて考えます。
「エージェントが増えるほど、人は減る」とは限らない
2026 Work Trend Index では、人とAIの働き方を考える際に、2つの“つまみ”を別々に見る考え方が示されています。
- エージェントの関与度：AIがどれだけ多くの調査・推論・ツール操作・実行を担うか。
- 人の関与度：人がどれだけ深く考え、確認し、方向を修正し、結果に責任を持つか。
この2つは、シーソーのような反比例ではありません。どちらも同時に高くなり得ます。
| エージェントの関与度：低い | エージェントの関与度：高い | |
|---|---|---|
| 人の関与度：高い | 人が主導し、AIを必要な場面だけで使う | エージェントが広く実行し、人が深く評価・判断する |
| 人の関与度：低い | ルール化・簡素化・廃止も含めて仕事自体を見直す | 定型業務をエージェントに委任し、人は例外時に入る |
たとえば、重要な提案書では、エージェントが大量の資料を読み、複数案を作り、論点を整理する一方、人も顧客の背景を考え、表現を吟味し、最終判断を下します。エージェントの仕事量が増えても、人の思考まで薄くなるわけではありません。
一方、定型的なデータ照合では、エージェントの関与度を高くし、人は異常が起きたときだけ入る方が合理的です。
人とエージェントの比率は、人を減らすための割り算ではなく、両者の力をどこで濃く使うかを決める設計なのです。
最初の座席表を描く、5つのステップ
では、実際に座席表を描いてみましょう。現在の組織図からではなく、ひとつの業務から小さく始めます。
ステップ1：人数ではなく「達成したい結果」を決める
「5人の仕事を自動化する」ではなく、「申請を24時間以内に処理する」「入力ミスを半減させる」のように、先に成果を決めます。人員削減を起点にすると、いまの非効率な手順をそのままエージェントへ移しかねません。
ステップ2：業務を、判断できる大きさまで分ける
「申請処理」の一言でまとめず、受付、内容の読み取り、不備確認、システム入力、承認、申請者への連絡、例外対応というように分けます。
業務全体では人の判断が必要でも、途中の読み取りや照合はエージェントに任せられるかもしれません。職種単位ではなく、仕事の流れ単位で見ることがポイントです。
ステップ3：3つの問いで席を割り当てる
各作業について、次の3つを確認します。
- 正解を客観的に確認できるか。 完了条件や品質基準を数値・ルールで示せるか。
- 間違えても戻せるか。 やり直し、取り消し、影響範囲の限定ができるか。
- 人であることに価値があるか。 共感、交渉、信頼関係、倫理や責任を伴うか。
1と2が「はい」で、3が「いいえ」に近いほどエージェント席へ。答えが混ざるなら共同席へ。3が強い、または取り返しがつかないなら人の席へ置きます。
ステップ4：「どこで人に渡すか」を先に決める
エージェントに任せる仕事を決めたら、同じくらい具体的に引き継ぎ条件を決めます。
- 必須情報が不足している
- 判断の確信度が基準を下回る
- 金額や影響範囲がしきい値を超える
- 顧客が人との対話を希望する
- 禁止操作やポリシー境界に近づいた
「困ったら人へ」では運用できません。何をもって“困った”とするかを、観測できる条件にします。
第2回でご紹介したスポンサーは、エージェントの目的とライフサイクルに責任を持つ人です。日々の業務ではそれに加えて、例外を引き取る担当者、品質を評価する担当者、停止や権限変更を判断できる担当者も座席表に置きます。
ステップ5：3つの数字を測り、比率を更新する
最初から「1人対10体」と固定するのではなく、まず次の数字を測ります。
- 自動完了率：人に渡さず、エージェントが完了できた割合
- 人への引き継ぎ率：例外・承認・再作業として人へ渡った割合と、その処理時間
- 同時実行量：繁忙時間に、いくつの仕事を並行して処理する必要があるか
自動完了率は、エージェントにどこまで任せられるかを示します。引き継ぎ率と処理時間は、人の監督席が何席必要かを示します。同時実行量は、必要なエージェント実行環境の規模を示します。
ここで初めて、「何体相当の実行能力が必要か」「それを何人で監督できるか」という比率を、実績に基づいて考えられるようになります。
100件の仕事で考えてみる
ある申請受付チームが、1日に100件を処理しているとします。業務を分けて座席を割り当てたところ、次のようになりました。
- 60件：条件が明確で、エージェントが受付から登録まで完了できる
- 30件：エージェントが内容を整理し、人が確認・承認する
- 10件：交渉や例外判断が必要で、人が最初から担当する
さらに、エージェントが完了する60件のうち5%が、情報不足などで人へ引き継がれるとします。すると、エージェントは90件に関わり、人は少なくとも43件の判断に関わります。
共同席の30件 ＋ 人の席の10件 ＋ 引き継ぎの3件 ＝ 人が扱う43件
この数字から分かるのは、「人対エージェントは1対何」という答えではありません。分かるのは、人の席に1日43件分の判断能力が必要であり、エージェント席には最大90件を、繁忙の波に合わせて処理する実行能力が必要だということです。
同じ90件でも、1日を通して均等に届くのか、朝の30分に集中するのかで、必要な同時実行数は変わります。同じ43件でも、1件30秒の承認なのか、20分の交渉なのかで、必要な人の数は変わります。
だから比率は、単純な“体数”ではなく、仕事量 × 処理時間 × 例外率 × ピークで設計します。そして最初の座席表は、正解ではなく、検証するための仮説です。
座席表は固定しない――必要なときだけ席を出す
人間の組織では、10人を採用すれば、原則として10席を継続的に用意します。しかしエージェントの席まで、同じように固定する必要はありません。
たとえばオンデマンド型の設計なら、月末の申請が集中する時間には20席、通常時は2席、仕事がなければ実行セッションは0席。新しいゴールが与えられたら、その達成に必要な実行能力だけを確保し、タスクが終われば実行環境を返す。タスク用のアクセス権も、期限切れや失効によって必要以上に残さないよう設計します。ここでいう エフェメラル（ephemeral） とは、こうした必要なときだけ現れる、短命な実行単位を指します。
これは、すべての構成を常に0席まで縮めるという意味ではありません。Windows 365 for Agentsには、タスクごとに用意して実行時間に応じて利用するオンデマンド型と、低遅延が必要な処理に備えてCloud PCを待機させる常時利用可能型があります。ワークロードに応じて使い分けることが重要です。
ただし、何もかも消すわけではありません。残すものと、短命にするものを分けます。
| 残すもの | 必要なときだけ用意するもの |
|---|---|
| エージェントの目的・役割 | 実行セッション（必要に応じてワーカーエージェント） |
| エージェント ID とスポンサー | 実行セッションとCloud PCの割り当て |
| ポリシー・品質基準・予算上限 | タスクに限定した期限付きアクセス |
| 実行結果と監査記録 | ピークに合わせた同時実行枠 |
この分離が重要です。責任や記録まで消してしまえば、誰が何をしたか追えません。反対に、実行する席を常に最大数で持ち続ければ、使われない能力とコストを抱えることになります。責任は持続させ、実行能力は需要に合わせて伸び縮みさせる。 それが動く座席表の基本です。
Microsoft Entra ID Governanceでは、エージェントにも承認フローを伴う期限付き・監査可能なアクセスを提供できます。なお、エージェント向けのIdentity Governance機能は、本稿執筆時点ではプレビューです。
コストの面でも意味があります。ただし、考えるコストと動かすコストは分けて捉える必要があります。Azure OpenAIなどのトークン従量課金型サービスでは、LLMによる推論に入力・出力トークンの利用料がかかります。一方、Windows 365 for AgentsのオンデマンドCloud PCは、実際にエージェントタスクを実行した時間に基づく別の利用料です。すべての席で常にLLMを動かすのではなく、判断が必要な瞬間だけ知性を呼び出し、必要な数の実行席だけを動かす。知性と実行能力の両方を、実際の仕事量へ近づけます。
“動く座席表”を成立させる、頭・手・統制
では、誰がゴールを読み解き、必要な席を決め、立ち上げ、終わったら戻すのでしょうか。動く座席表には、3つの機能が必要です。私はこれを、「頭・手・統制」と呼んでいます。
これはMicrosoftの製品名や公式分類ではなく、本記事で実行基盤の要件を整理するための表現です。ただし、Microsoftの公式ドキュメントでも、モデルやオーケストレーション層が「何をするか」を決め、Windows 365 for Agentsが実行層を担い、Agent 365とMicrosoft Entra、Microsoft Purview、Microsoft Defenderなどが観測・統制・保護を担う、という役割分担が示されています。
- 頭：ゴールを理解し、仕事を分解し、必要な役割・同時実行数・手段を決める。ルールで処理するのか、LLMに考えさせるのか、人へ渡すのかも選ぶ。
- 手：頭が決めた計画に沿って、アプリ、ブラウザー、ファイル、業務システムを実際に操作する。
- 統制：誰の責任で、どの権限・予算・品質基準の範囲なら実行してよいかを定め、承認、記録、監視、停止を担う。
ゴールを受け取る → 頭が座組みを決める → 必要な数の手が動く → 統制が見守る → 結果を確かめる → 席を増減・解放する
頭だけでは計画で止まり、手だけでは目的や境界を見失い、統制だけでは仕事が進みません。3つがそろって初めて、エフェメラルな実行セッションやワーカーを安全に増減できます。固定された「エージェント30体」ではなく、ゴールごとに最適なチームを組成し、終われば解散する。これが、フロンティア企業における座席表の姿です。
座席表そのものを、クローズドループで育てる
第1回で、自律の基本をエアコンになぞらえて、測る → 判断する → 運転を変える → また測るとご説明しました。同じ輪を、チームの座席表にも適用します。
- 測る：品質、自動完了率、引き継ぎ率、再作業、処理時間、インシデントを記録する。
- 判断する：エージェントに任せすぎていないか、人が確認しすぎて詰まっていないかを見る。
- 動かす：権限、承認条件、担当範囲、同時実行数、人の配置を変える。
- また測る：変更後の結果を確かめる。
導入初期は、共同席を多めにして、人が成果を確認します。実績が積み上がり、失敗の型と戻し方が分かってきたら、一部をエージェント席へ移します。逆に、品質が下がったり、業務条件が変わったりしたら、人の確認を増やします。
これは、第2回でお話しした「自律性は、最初から与えるものではなく、実績によって獲得させるもの」という考え方の、チーム設計版です。
エージェントを増やすほど、人の評価は不要になるのではありません。むしろ、大量の処理が一気に進むからこそ、悪い結果を大量に通さないための評価の仕組みが重要になります。座席表には、仕事をする席だけでなく、品質を見て配置を変える席も必要なのです。
2種類の働き手には、2種類の“席”がある
ここまで描いた座席表を、最後に実際の働く環境へ置き換えてみます。
- 人の席では、人が管理されたCloud PCへ安全にアクセスし、エージェントから引き継いだ例外や、共感・判断が必要な仕事を受け持つ。
- エージェントの席では、AIエージェントが管理された実行環境でアプリやブラウザーを操作し、定型処理を担う。
- 共同席では、同じ業務を両者が受け渡すため、ID、権限、記録、引き継ぎ条件が一続きで設計されている。
人が Windows 365 Cloud PC へ直接接続するための専用デバイスが Windows 365 Link。エージェントが Cloud PC 上で業務を実行するための基盤が Windows 365 for Agents です。Windows 365 for Agentsでは、エージェントがタスクを実行するときにCloud PCをチェックアウトし、完了後にチェックインします。するとCloud PCはリセットされ、実行能力がプールへ戻ります。目的やIDは維持しながら、セッションは状態を持ち越さない――Microsoftの公式ドキュメントが ephemeral compute と表現する、“動く座席表”の実装です。
この2つを同じ業務の座席表に置いたとき、何が起きるのか。次回は、ここまでの考え方を最も具体的に描きやすい現場へ持っていきます。
まとめ：エージェントを増やす前に、座席表を描こう
人とエージェントの比率とは、単なる人数の割り算ではありません。
どのゴールに対して、どの仕事を誰が持ち、どの条件で引き継ぎ、どれだけの人の判断とエージェントの実行能力を、いつまで配置するか。
これを決めるのが、チームの“座席表”です。
まずゴールを決め、仕事を分ける。頭が座組みを考え、必要な数の手を動かし、統制の下で実行する。エージェント席、共同席、人の席は固定せず、自動完了率・引き継ぎ率・同時実行量を測りながら増減させます。仕事が終われば、実行する席は解放します。
エージェントを、数え始める前に。まず、ゴールと仕事を数えましょう。そして、必要なときに、必要な席だけを。
次回は「その座席表をコンタクトセンターに当てはめるとどうなるか」――Windows 365 Link と Windows 365 for Agents を使った、人とエージェントの協働を具体的にお届けします。
参考リンク
人とエージェントのチーム設計（Microsoft WorkLab）
- 2025 Work Trend Index: The year the Frontier Firm is born
- 2026 Work Trend Index: Agents, human agency, and the opportunity for every organization
エージェントと人の実行環境（Microsoft Learn）
- What is Windows 365 for Agents?
- Agent session lifecycle
- Identity security overview
- Pricing for Windows 365 for Agents
- Windows 365 for Agents in Agent 365
- What is Windows 365 Link?
- Microsoft Entra エージェント ID
- Microsoft Entra エージェント IDの管理関係（所有者、スポンサー、マネージャー）
- Microsoft Entra ID Governance（エージェント向け機能はプレビュー）
- Plan to manage costs for Azure OpenAI
本資料は情報提供のみを目的としており、作成時点でのマイクロソフトの見解を示したものです。仕様・提供状況は変更される場合があります。© Microsoft 2026. All rights reserved.