第4回：コンタクトセンターに“座席表”を置いてみる――Windows 365 Link と Windows 365 for Agents

  • Hiroyuki Hikino

    • Cloud Endpoints と呼んでいる、Windows 365 や Azure Virtual Desktop のソリューション エンジニアを務める曳野（ヒキノ）と申します。「SE曳野の仮想デスクトップとAI」と題して、私たちの仮想デスクトップサービスとAIやエージェントの関係性を中心にブログをお届けしています。第4回目のテーマは「コンタクトセンターに“座席表”を置いてみる」です。

    第1回では、エージェントを「どこで動かすか」という問いから、管理された実行環境である Windows 365 for Agents をご紹介しました。第2回では、“社員証”にあたる Microsoft Entra エージェント ID と、“上司”にあたるスポンサーの必要性を。第3回では、人とエージェントの仕事の持ち方を決める “動く座席表” の描き方をお話ししました。ここまではすべて、どの業種にも当てはまる一般論でした。今回は、その座席表を1つの現場に持ち込みます。最初の現場は、コンタクトセンターです。

    執筆者：日本マイクロソフト株式会社　クラウド＆AIソリューション事業本部
    ソリューション エンジニア 曳野 洋幸 | 2026年8月17日

    はじめに：なぜ、最初の現場がコンタクトセンターなのか

    理由はシンプルです。コンタクトセンターは、もともと“座席表の職場”だからです。

    考えてみてください。この現場では、日常会話の中に「席」という言葉が当たり前に登場します。何席用意するか。何席稼働しているか。席の稼働率は何%か。シフトで席をどう回すか。第3回でご紹介した“座席表”という考え方を、比喩ではなく実務の言葉として、すでに持っている数少ない現場です。

    そのうえ、コンタクトセンターには、人とエージェントの設計を考えるうえで難しい条件がそろっています。

    • 繁閑差が大きい：朝の30分と深夜で、必要な席数がまったく違う。
    • 人でなければならない仕事と、そうでない仕事が同居している：お詫びと交渉は人の仕事。一方、システムへの入力や履歴の照会は、必ずしもそうではない。
    • 統制が厳しい：個人情報、通話記録、委託先・BPOのアクセス管理。座席を1つ増やすたびに、統制の設計が要る。
    • 人の入れ替わりが速い：短期要員、季節要員、複数拠点。席は同じでも、座る人は日々変わる。

    つまりコンタクトセンターは、第3回でお話しした「動く座席表」が一番はっきり効く現場なのです。この記事を読み終わる頃には、1本の入電が、人の席とエージェントの席をどう渡り歩くのかを、具体的に思い描けるようになっています。

    まず、1本の電話を作業に分ける

    第3回のステップ2で、「業務を、判断できる大きさまで分ける」とお伝えしました。まずはそれをやってみます。1本の入電は、たとえばこう分解できます。

    「コンタクトセンター業務」とひとまとめにすると、人の仕事にしか見えません。しかし分けてみると、性質のまったく違う作業が並んでいることが分かります。第3回の3つの問い（①正解を客観的に確認できるか、②間違えても戻せるか、③人であることに価値があるか）で席を割り当てると、次のようになります。

    ここで注目していただきたいのは、表の下から2行目です。

    後処理（ACW：After Call Work）は、多くのセンターで1件あたり数分かかり、応対時間と同じくらい席を占有します。しかも、その多くは「今の会話で決まったことを、複数のシステムに正しく書き写す」作業です。件数が多く、手順が安定していて、結果を検証でき、間違えても直せる。 第3回の基準に照らせば、これは典型的なエージェント席の仕事です。

    そして後処理は、人が話している“その最中”に、別の席で並行して進められるという性質を持っています。ここが、コンタクトセンターに座席表を持ち込む最大の勘所です。

    人の席をつくる ― Windows 365 Link と Windows 365 Flex

    座席が決まったら、次はその席を実際に用意します。まずは人の席からです。

    Windows 365 Link ― データもアプリも持たない“席”

    Windows 365 Link は、ユーザーを自分のCloud PCに直接つなぐために設計された、Cloud PC専用のデバイスです。特徴は、できることの少なさにあります。

    • ローカルにデータを保存しません。
    • ローカルアプリを実行しません。
    • ローカルの管理者ユーザーが存在しません。
    • BitLocker、セキュア ブート、仮想化ベースのセキュリティ、厳格なアプリケーション制御が既定で有効です。
    • Microsoft Intune で、他のWindowsデバイスと同じように管理できます。

    そして、コンタクトセンターにとって重要なのが共有を前提にした設計です。初回セットアップ後は、サインイン画面だけが表示され、どのユーザーでも自分のCloud PCに認証して接続できます。サインイン方法としてFIDO2セキュリティキーの利用が推奨されており、NFCのスマートカードリーダーもサポートされています。

    席は共有し、環境は個人のものにする。 シフト交代のたびに端末を初期化したり、持ち出しを心配したりする必要がない――これが、Linkが「人の席」に向いている理由です。

    Windows 365 Flex ― 席を、時間で分け合う

    人の席そのものにも、エフェメラルの考え方は入っています。Windows 365 Flex は、1ライセンスで複数のユーザーがCloud PCを使えるようにする仕組みで、2つのモードがあります。

    Dedicatedモードでは、10ライセンスで最大30台のCloud PCを用意し、そのうち同時に稼働できるのは10台まで、といった使い方ができます。誰かがサインオフすれば、そのセッション枠は次の人へ解放されます。さらに、毎日決まった時間に接続する利用者については、その少し前にCloud PCを起動しておく予測起動（インテリジェント プレスタート）も備えています。

    Sharedモードでは、サインアウトのたびにユーザーデータが削除されます。短期要員や委託先の席として、「使うときだけ現れ、終われば何も残らない」設計をとれます。

    第3回で「エージェントの席は固定しない」とお伝えしましたが、実は人の席も、すでに固定ではなくなっているのです。

    エージェントの席をつくる ― Windows 365 for Agents

    次に、エージェントの席です。Windows 365 for Agents は、エージェント用途のために用意された新しい種類のCloud PCで、Microsoft Entra参加・Intune管理という企業の管理境界の中で動きます。

    管理の単位が、人の席と決定的に違います。管理者が扱うのは個々のデバイスではなく、プールです。エージェントは「あのPCを使わせてほしい」ではなく、「実行できる環境を1つください」と要求します。そして1回のタスクは、次の5つのフェーズをたどります。

    1. Prepare：イメージ・リージョン・サイズを決めて、Cloud PCのプールを用意しておく。
    2. Acquire：エージェントがタスクを始める瞬間に、プールから1台を予約する。
    3. Connect：そのCloud PCへの認証済みの通信路を開く。人が見守る場合は、リアルタイムに画面を共有する別の通信路も同時に開ける。
    4. Act：エージェントが画面を観察し、次の操作を決め、クリック・入力・Web操作・コマンド実行を行う。プラットフォームがその一つひとつを仲介し、記録する。
    5. Release：作業が終わるか、ポリシーで終了するか、無操作が続くと、通信路が閉じ、Cloud PCはリセットされ、実行能力がプールに戻る。

    運用上、押さえておくと便利な性質が3つあります。

    • 最大実行時間の上限はありません。 数秒のタスクも、数日にまたがるワークフローも扱えます。
    • 30分間まったく動きがないセッションは、自動的に回収されます。 席を空けたまま占有し続けることがない仕組みです。
    • セッション内の状態は持ち越されません。 途中経過は外部に保存する前提で設計します。

    課金も、この考え方に沿っています。米国地域の場合、オンデマンドのCloud PCは実際にエージェントタスクを実行した時間に基づく従量課金（1時間単位に切り上げ）で、1時間あたり0.40 USD。低遅延の応答が必要な用途向けに、即座に使える状態を保つ「常時利用可能」オプションがCloud PCあたり月額5 USDで用意されています（いずれも執筆時点の米国地域の価格。地域によって異なります）。

    コンタクトセンターに置き換えると、こうなります。朝のピークの30分は20席、深夜は0席。 席を用意しておくコストではなく、実際に働いた時間のコストになります。

    なお、Copilot Studio の computer use から、この Cloud PC プールを実行先として指定できます（プレビュー）。APIが用意されていない社内システムでも、エージェントが画面を操作して担当できる――第1回でお話しした「実行環境の重要性」が、ここで具体的な形になります。

    1本の入電が、席を渡り歩く

    では、実際に1本の電話を流してみましょう。用件は「引っ越しに伴う住所変更と、回線の移転」とします。

    ① 一次応対（エージェント席）
    AIが受電し、用件を切り分けます。住所変更だけなら、この場で完結します。

    ② 引き継ぎ条件に該当（共同席へ）
    今回は移転工事の日程調整が必要で、お客様も人との対話を希望されました。第3回のステップ4で決めた引き継ぎ条件に該当します。

    ③ 引き継ぎ（“電話を回す”だけではない）
    ここが重要です。Copilot Studio では、お客様が人への引き継ぎを求めたとき、会話全体がエンゲージメントハブへ渡され、担当者は文脈を持った状態で会話を引き継げます。ルーティングに使うコンテキスト変数も一緒に渡ります。Dynamics 365 Contact Center では、エスカレーション時に顧客と案件が自動で特定され、エスカレーションの要約が担当者に提示されます。渡すのは、通話ではなく、文脈です。

    ④ 人の席で応対（人の席）
    担当者はWindows 365 Linkから自分のCloud PCに接続し、要約を読んだ状態で会話を再開します。「もう一度、最初から説明していただけますか」が要らなくなります。

    ⑤ 通話中、裏で手が動く（エージェント席）
    担当者がお客様と話している間、エージェント席では別のエージェントがCloud PCをチェックアウトし、APIのない工事管理システムを画面操作して空き枠を照会します。担当者は、その結果を見ながら日程を提案できます。

    ⑥ 境界に触れたら、止まる（統制）
    重要顧客、特例料金、権限外の操作。あらかじめ決めたしきい値に触れたら、エージェントは自分で突破せず、人に判断を求めます。第1回でお話しした「ガバナンスループ＝ブレーキとハンドル」です。

    ⑦ 後処理（エージェント席）
    通話終了後、応対記録の作成と関連システムへの反映はエージェントが実行し、人は結果を確認して承認します。

    ⑧ 席を返す（Release）
    タスクが完了すると、Cloud PCはリセットされ、実行能力がプールに戻ります。消えるのはセッション。残るのは、応対記録と監査ログと、責任の所在です。

    「見ながら、代われる」という設計

    ⑤と⑥で、少し不安を感じた方がいるかもしれません。「エージェントが画面を操作している最中に、人はどう関われるのか」と。

    Windows 365 for Agents では、同じセッションを人がリアルタイムに観測し、必要に応じて操作を引き取れます。エージェントの接続を切らずに、人がその画面に入れる設計です。別の環境を立ち上げ直す必要はありません。

    これは、第1回でご説明したヒューマン・オン・ザ・ループの実装そのものです。人は毎回のクリックを承認するのではなく、上から見ていて、必要なときだけ手を出す。コンタクトセンターの言葉でいえば、SVによるモニタリングと、割り込みです。

    そしてこの構造は、第2回でお話しした試用期間の考え方とつながります。導入初期は共同席を厚くし、人が見守る。実績が積み上がったら、エージェント席へ移す。自律性は与えるものではなく、実績によって獲得させるものでした。

    席数を、数えてみる

    第3回の「100件の仕事」を、コンタクトセンターの数字に置き換えてみます。1日200件の入電があるセンターを想定します。

    • 120件：AIが一次応対で完結する
    • 60件：AIが受けて、人へ引き継ぐ
    • 20件：最初から人が担当する（重要顧客、苦情、法人の特例）

    人が関わるのは 80件です。1件あたり、通話8分＋後処理6分＝14分とすると、必要な時間は 1,120分。

    ここで、後処理をエージェント席へ移します。すると人の1件は8分になり、必要な時間は 640分へ。480分――およそ1人日分の時間が空きます。

    この480分は、消えてなくなるわけではありません。第3回でお伝えしたとおり、比率とは人を減らすための割り算ではありません。空いた時間は、人の席にしか置けない仕事へ回ります。20件の難しい応対に十分な時間をかける。エージェントの応対品質を評価する。引き継ぎ条件を見直す。第3回で触れた「品質を見て配置を変える席」が、ここで実際に必要になります。

    一方、エージェント席は同時実行数で決まります。ピークの1時間に全体の25%＝50件が集中し、1件あたりのエージェント実行時間が平均3分だとすると、必要な実行量は150分。1時間あたり同時 2.5席、つまり3席分の実行能力を用意すれば足ります。深夜帯は0席です。

    コストの積み方も、人の席とエージェントの席で分けて考えます。

    第3回でお伝えした「考えるコストと、動かすコストは分けて捉える」を、そのまま見積書の行に落とし込む形です。

    統制：消してよいものと、消してはいけないもの

    コンタクトセンターは、個人情報と通話記録を最も多く扱う現場のひとつです。委託先やBPOが入ることも珍しくありません。だからこそ、「消えること」と「残ること」の設計が重要になります。

    第2回でお伝えした「IDのないエージェントは、ログが嘘をつく」という話を思い出してください。委託先の担当者と、その担当者を支援するエージェントが同じ業務を扱うとき、「誰の席で、誰のIDで、何をしたか」が一続きで追えること。それが、コンタクトセンターに座席表を持ち込むための前提条件です。

    座席表を、クローズドループで育てる

    最後に、第1回のエアコンの輪をもう一度回します。コンタクトセンターの場合、測るべき数字はすでに現場にあります。

    1. 測る：自己解決率、人への引き継ぎ率、引き継ぎ後の解決時間、後処理時間、再入電率、エージェント席の同時実行ピーク、1件あたりの実行時間。
    2. 判断する：引き継ぎが多すぎないか。逆に、引き継ぐべき用件をエージェントが抱え込んでいないか。再入電率が上がっていないか。
    3. 動かす：引き継ぎ条件のしきい値、席の割り当て、プールのサイズ、人の配置を変える。
    4. また測る：変更後の結果を確かめる。

    特に見ておきたいのが、自己解決率と再入電率をセットで見ることです。自己解決率だけを追うと、「その場では完結したが、翌日また電話がかかってくる」応対を増やしてしまいます。エージェントを増やすほど、悪い結果も大量に通ってしまう――第3回でお伝えしたとおり、評価の仕組みは、実行能力と同じだけ重要です。

    まとめ：席という言葉を、すでに持っている現場から

    コンタクトセンターは、「席」という言葉を日常的に使っている現場です。だからこそ、人とエージェントの座席表を最初に置く場所として最適でした。

    • 人の席は、Windows 365 Link と Windows 365 Flex で。データを持たない端末と、時間で分け合えるCloud PC。
    • エージェントの席は、Windows 365 for Agents で。プールから借りて、働いて、リセットして返す。
    • 共同席は、引き継ぎ条件の設計で。渡すのは通話ではなく、文脈。
    • そして、消えるのはセッション、残るのは記録と責任。

    第3回の締めくくりで、「必要なときに、必要な席だけを」とお伝えしました。コンタクトセンターは、その言葉が最も素直に成り立つ現場です。

    もしあなたが今、エージェント導入の最初の一歩を探しているなら、後処理（ACW）から始めることをおすすめします。件数が多く、手順が安定していて、結果を検証でき、失敗しても戻せる。そして何より、人がいま最も時間を取られていて、かつ、人でなくてもよい仕事だからです。

    次回は、この座席表を「24時間止まってはいけない現場」――運用・監視のオペレーションへ持っていきます。そして、同じ仕事を繰り返すうちに、エージェントの判断そのものが定型化していく“育つ”仕組みについてお話しします。

    参考リンク

    人の席（Microsoft Learn）

    エージェントの席（Microsoft Learn）

    引き継ぎとコンタクトセンター（Microsoft Learn）

    ID と統制

    モバイルバージョンを終了