WEBVTT

00:00:00.000 --> 00:00:04.340
チケット管理は計画上は効率的に見えます 数値化されQが作られダッシュボードで管理されます

00:00:04.340 --> 00:00:08.040
しかし実際にはそのモデルはシステムがすでに破綻した後の苦痛を測定しているにすぎません

00:00:08.040 --> 00:00:14.360
コストが膨らむ問題の発生源は通常はるかに手前にあります 従業員が10分20分と時間を失い最終的に諦めてしまうところから始まります

00:00:14.360 --> 00:00:20.000
彼らはやり直します同僚に尋ねます正しい手順が使えなくなったことで会議に遅れたり 誤ったファイルを共有したりします

00:00:20.000 --> 00:00:26.000
これこそが多くのサポートチームが見落としている部分です 今日の最善の社内サポートモデルはトリアージの高速化ではありません

00:00:26.000 --> 00:00:33.000
トリアージの必要性そのものをなくすことです マイクロソフト365内でコンテキストを監視し摩擦を早期に発見し

00:00:33.000 --> 00:00:41.240
ユーザーがポータルを開こうと考える前に対処する自立型エージェントを想像してください 今回のエピソードではなぜヘルプデスクモデルが破綻するのかそれに変わるものは何か

00:00:41.240 --> 00:00:47.260
そして混乱を招かずにどう管理できるのかを解説します この変化が重要だと感じたらm365fmを登録してください

00:00:47.260 --> 00:00:52.760
なぜならそのさらに奥にある真の問題は9ではなくその背後にあるモデルだからです チケットの終焉

00:00:52.760 --> 00:00:59.620
従来のサポートフローは今も至るところに存在します何かが故障します ユーザーがそれに気づきますユーザーが状況を説明しようと試みます

00:00:59.620 --> 00:01:08.260
it 部門がその説明をカテゴリ優先度割り当てグループなどに変換します 問題が9に入ります誰かがトリアージを行います別の担当者が詳細を尋ねます

00:01:08.260 --> 00:01:16.280
他のチームが関与します実際の作業が止まっている間も時間だけが過ぎていきます 慣れ親しんでいるため正常に感じられますが慣れていることと効率的であることは別物です

00:01:16.280 --> 00:01:24.540
チケットはサポートではありませんチケットはサポートの到着が遅れたという証拠です チケットが作成された時点で従業員はすでに障害に直面し作業のコンテキストを失っています

00:01:24.540 --> 00:01:33.380
彼らはすでに行おうとしていた仕事から注意をそらされています キューはサービスではありませんキューは失敗の記録です大規模なマイクロソフト365環境では手動での

00:01:33.380 --> 00:01:41.080
トリアージが真のボトルネックとなりますこれはサポートチームが怠慢だから起こるわけではありません 環境の規模に合わなくなった業務を人間に求めていることが原因です

00:01:41.080 --> 00:01:49.420
ユーザーデバイスアプリポリシーの数が増えています チームシェアポイントエクスチェンジインチューンエントラをまたぐ複雑なエッジケースが同時に発生しています

00:01:49.420 --> 00:01:56.860
増えているのは量だけではありません組み合わせも複雑化しています そこで従来のモデルが破綻するのです多くのチームは構造をさらに増やすことで対応しようとします

00:01:56.860 --> 00:02:03.920
新たなポータル別のボットさらなるルーティングルールを構築します しかし実際にはそれが従業員と解決策の間にさらなる層を加えているだけなのです

00:02:03.920 --> 00:02:12.300
システムは今もなおユーザーが問題に気づきそれを説明し適切な方法で助けを求めるのを待ち続けています 仕事はサポートポータルで始まるのではありません

00:02:12.300 --> 00:02:21.240
チームでアウトルックで今すぐ必要なドキュメントであるいは30秒後に始まる会議で 始まりますそこにこそ実際のサポートニーズが存在しておりチケット管理モデルはその瞬間から完全に

00:02:21.240 --> 00:02:24.880
切り離されているのです その隠れたコストは旧のレポートに示されるよりもはるかに大きなものです

00:02:24.880 --> 00:02:29.160
人々はコンテキストの切り替えを繰り返しています 重複したインシデントが異なるラベルの下で積み上がっていきます

00:02:29.160 --> 00:02:35.440
ナレッジ記事は陳腐化していきます アナリストは本来の修復作業ではなく分類やルーティング状況確認に1日中追われています

00:02:35.440 --> 00:02:45.020
解決までの時間が延びるのは引き継ぎの度に遅延が発生しその度に本来の文脈が 失われていくからですエージェント型 ai と it 運用に関する調査はいずれも同じ構造的な問題を指摘しています

00:02:45.020 --> 00:02:52.500
少なくとも80%の労力が今もアイティル型のリアクティブな作業に縛られています この数字は重要ですなぜなら労働力がどこに費やされているかを正確に示しているからです

00:02:52.500 --> 00:02:59.380
それはレジリエンス回復力や予防ではなく事後対応に費やされています そう気づけばチケットは運営モデルというよりも症状のように見えてくるはずです

00:02:59.380 --> 00:03:07.520
それは被害が目に見えてからしか反応しないシステムの症状なのです したがって次の問いはいかにチケットを早く処理するかではなくチケットが必要になる前にシステムが何をすべきかになります

00:03:07.520 --> 00:03:15.460
見えない従業員インビジブルエンプロイーモデルですでは何が実際にチケットにとって変わるのでしょうか それは同じ混乱の上に置かれた単なるチャットボットではありませんし当然従来の

00:03:15.460 --> 00:03:24.300
急に見栄えの良い入り口を作っただけのものでもありません この変化はもっと深いものですなぜなら見えない従業員とはマイクロソフト365関係台で働く運用担当者だからです

00:03:24.300 --> 00:03:30.900
このエージェントには独自のIDと明確な業務範囲があり 機能の記憶を持ち何に触れられ何に触れられないかという厳格なルールを備えています

00:03:30.900 --> 00:03:36.980
その違いが重要なのです チャットボットはユーザーの入力を待ちますが見えない従業員は状況の変化を監視します

00:03:36.980 --> 00:03:44.840
それは会話から始まるのではなく文脈から始まります サインインの状態デバイスの健全性ライセンス状況ファイルの共有方法を把握しているため

00:03:44.840 --> 00:03:51.500
問題が起きるのを待つ必要はありません 何かが壊れた後に助けを求めるのではなくバックグラウンドで常に別の問いを投げかけています

00:03:51.500 --> 00:03:57.320
今従業員が業務を遂行するために必要な状態から何が乖離しているのか そこに変化が生まれます

00:03:57.320 --> 00:04:05.260
このモデルは業務そのものに直接組み込まれています 会議に参加した際音声設定に失敗したりゲストが送られたファイルを開けなかったりした場合

00:04:05.260 --> 00:04:11.020
古い世界ではレポートが作成され引き継ぎが行われるだけです 新しいモデルではエージェントはパターンを即座に認識し

00:04:11.020 --> 00:04:15.560
その状況が基地の問題に該当するかを確認した上で修正のための安全な次のアクションを 実行します

00:04:15.560 --> 00:04:21.860
パスのリセットやポリシーチェックの実行あるいはリクエストの経路変更や mfa 多要素認証の要求を行いその修正内容を記録します

00:04:21.860 --> 00:04:27.440
要点はシンプルです 最初の対応において人間が曖昧な説明を読んで何が起きたのかを推測する必要はもうありません

00:04:27.440 --> 00:04:32.980
うまく機能している場合このプロセスは目に見えません 待機室もなければカテゴリーを選択してくださいといったフォームに記入する必要もないからです

00:04:32.980 --> 00:04:40.200
サポートはワークフローが復旧するという形で現れます 従業員はすぐに業務に戻れます多くの場合背後で動いているメカニズムを目にすることさえありません

00:04:40.200 --> 00:04:49.060
これが人員配置の考え方をどう変えるかはすでに明らかでしょう 従来のモデルでは大量の問い合わせを処理しリクエストを仕分けチーム間の断絶したコンテキストを整理するために人を雇っていました

00:04:49.060 --> 00:04:56.620
新しいモデルではトリアージを行う人員は減りガードレールの設計あるべき状態の定義 そしてエージェントの長期的な振る舞いを監督する人員が求められます

00:04:56.620 --> 00:05:04.600
人間はシステムの中に残り続けますが日々の業務のあり方は根元から変わります サポートにおけるエージェント型 ai の研究は一貫してこの方向を示しています

00:05:04.600 --> 00:05:11.160
ルーチン的なサポートは例外ベースの処理へと移行でき環境とポリシーが適切に制限されていれば劇的な効率化が実現します

00:05:11.160 --> 00:05:20.340
最後の一点は極めて重要ですなぜならこれは魔法ではないからです データが貧弱でプロセスが整理されていなければ自立型と呼んだだけでエージェントが賢くなることはありません

00:05:20.340 --> 00:05:26.560
エージェントをソフトウェア機能として捉えるのをやめバッジを持つ人間ではない 従業員として見始めたときすべてが腑に落ちました

00:05:26.560 --> 00:05:33.240
実際の労働者にはアイデンティティ職務記述書権限そして報告すべきマネージャーが必要です エージェントにも全く同じものが必要です

00:05:33.240 --> 00:05:40.680
価値はチャットウィンドウでの気の利いた言葉ではなくシステム内での信頼できるアクションから生まれるからです この見えない従業員は単なるUIのトリックではありません

00:05:40.680 --> 00:05:49.080
これはマイクロソフト365環境全体の摩擦を監視しポリシーの範囲内で行動し 判断が必要な例外のみを人間に委ねる新しいサポート層です

00:05:49.080 --> 00:05:54.780
そのモデルが明確になれば次の疑問は非常に実践的なものになります プリエンプション先制対応は具体的にどう機能するのでしょうか

00:05:54.780 --> 00:05:59.660
プリエンプションのアーキテクチャではマイクロソフト365の中でプリエンプションは実際にどのように 機能するのでしょうか

00:05:59.660 --> 00:06:06.420
シフトの焦点はリクエストと応答からイベントの推論とオーケストレーションへと移ります 専門的に聞こえますが分解してしまえばモデルは単純です

00:06:06.420 --> 00:06:14.660
まず環境内で何かが変化し次にシステムがその変化がリスクやドリフトを意味するかを解釈し 最終的に既存のスタックにあるツールを使って承認されたアクションを実行します

00:06:14.660 --> 00:06:20.000
まずはイベント層から始めましょう マイクロソフト365は常にシグナルを発信しており

00:06:20.000 --> 00:06:29.560
エントラはサインイン動作をインチューンはデバイスの状態とコンプライアンスを監視しています ディフェンダーは不審な動きを監視しチームは会議の失敗や通話品質の低下を正確に把握します

00:06:29.560 --> 00:06:36.180
シェアポイントとエクスチェンジはアクセスパターンやコンテンツの動きを可視化し サービス正常性シグナルはプラットフォーム自体に問題があるかを伝えます

00:06:36.180 --> 00:06:44.820
そこにユーザーの行動を重ね合わせることで絶え間ないコンテキストの流れが生まれます 多くの組織はこれらのシグナルを収集していますがそれをサポートシステムとして活用できている組織はほとんどありません

00:06:44.820 --> 00:06:53.780
単なる生データでは不十分でありノイズから意味を見出すための推論層が必要です ここで見えない従業員は単なる自動化の演出から本物のオペレーターへと進化します

00:06:53.780 --> 00:07:04.800
エージェントはシグナルを観察し現状とあるべき姿を比較してどの程度の対応が安全かを判断します 会議の音声トラブルは危険なサインインとは異なり共有リンクの破損はライセンスの不一致とは全く別物です

00:07:04.800 --> 00:07:10.200
エージェントはまず問題を分類しなければなりません 分類なしにアクションを起こせばかえってミスを増やすだけだからです

00:07:10.200 --> 00:07:15.720
次にオーケストレーションが行われます 問題を理解したエージェントは適切な仕組みを使って対応を開始します

00:07:15.720 --> 00:07:20.980
ワークフローならパワーオートメートロジックならコパイロットスタジオ システム操作やコンテキスト取得ならマイクロソフトグラフが使われます

00:07:20.980 --> 00:07:29.300
ツールも重要ですがそれらがどう連携するかがより大きな意味を持ちます ただ賢いプロンプトを作るのではなく検出判断実行検証を行う連鎖を構築するのです

00:07:29.300 --> 00:07:35.040
最後の検証プロセスは非常によく見落とされます 自己修正システムはアクションを起こして終わりではありません

00:07:35.040 --> 00:07:41.700
問題を検出し条件をテストし修正を適用し 結果を検証して記録するというサイクルを回し続けます

00:07:41.700 --> 00:07:49.280
自己修正ロジックの研究によればこれらのシステムは言語モデルによる単発の回答ではなく フィードバックと修正パターンを通じて機能します

00:07:49.280 --> 00:07:55.920
もし最初のアクションが失敗してもシステムは定義された制限内で次のステップを修正できる よう原因を評価する手段を持っています

00:07:55.920 --> 00:08:04.060
マイクロソフト365の事例を見るとこの仕組みが明確に理解できます ライセンスとポリシー範囲の不一致でユーザーがブロックされるとエージェントは不整合を検知し

00:08:04.060 --> 00:08:11.760
本来の役割プロファイルを称号します 許容された修正を適用しユーザーのアクセスを確認した上で誰にも頼ることなく変更を記録します

00:08:11.760 --> 00:08:17.780
エントラで危険なサインインが発生するとエージェントは直ちにリスクイベントを認識し 条件付きアクセスルールを確認します

00:08:17.780 --> 00:08:24.060
ポリシーに基づき強化された認証を求めるかアクセスを遮断し その結果を後で人間が確認できるよう記録に残します

00:08:24.060 --> 00:08:30.240
シェアポイントで古い共有リンクが何度も失敗する場合 エージェントは現在の権限パスと期待される共有ルールを比較します

00:08:30.240 --> 00:08:35.180
エージェントは破損したルートを承認済みのものに置き換え 修正されたリンクをコンテキスト内に送信します

00:08:35.180 --> 00:08:40.640
これによりヘルプデスクの担当者がアクセスに関する緊急の問題というチケットを読む前に問題を解決できます

00:08:40.640 --> 00:08:48.880
会議サポートも素晴らしい例です 会議開始の数秒前に会議室のデバイスが故障したり接続経路が途切れたりした場合 エージェントはその状況を検知し障害を特定できます

00:08:48.880 --> 00:08:54.180
エージェントはリスクの低い復旧手順を試み チームで主催者に通知して作業が行われているその場でステータスを更新します

00:08:54.180 --> 00:08:59.980
そのコミュニケーションレイヤーは設計の非常に重要な部分です サポートは中断が発生する場所に存在しなければなりません

00:08:59.980 --> 00:09:05.540
あなたの仕事がチームアウトルック m 365ワークスペースで行われているならサポートもそこで回答すべきです

00:09:05.540 --> 00:09:12.940
コンテキスト内で対応できるのであればユーザーを別の場所に誘導する必要はありません これはすべてのタスクを完全に自動化することを意味するわけではありません

00:09:12.940 --> 00:09:18.940
それは無謀だからです リスクの低いアクションは自動実行できますが影響の大きい変更には依然として人の承認が必要です

00:09:18.940 --> 00:09:27.960
その承認プロセスは後から付け足すのではなく最初からアーキテクチャの一部である必要があります エージェントはいつ行動しいつ尋ねいつ正確に停止すべきかを知っておくべきです

00:09:27.960 --> 00:09:36.420
そしてそれをフローに組み込むと会話の内容は自動化機能の話ではなくなります それは制御ガバナンス信頼そしてエージェントのアイデンティティの話になります

00:09:36.420 --> 00:09:45.140
サポートが自律的に動き始めるとすぐに難しい問題が浮上します 実際に作業を行っているのは誰かその答えが曖昧だとモデル全体が崩壊してしまいます

00:09:45.140 --> 00:09:49.540
エージェントは広範なアクセス権を持ち所有者が明確でないような曖昧なヘルパーとして環境内に存在してはなりません

00:09:49.540 --> 00:09:56.780
エントラ内に実在するアイデンティティが必要です 指名された所有者定義されたスコープそして特定の理由で開始終了するライフサイクルが必要です

00:09:56.780 --> 00:10:03.160
もしそのエージェントがデータを読み取ったりワークフローを起動したりユーザーにメッセージを送ったりできるなら テナントのアクティブな参加者として管理しなければなりません

00:10:03.160 --> 00:10:09.600
誰かがオンにして忘れてしまった機能のように扱うことはできません これがシステムにとってエージェントのアイデンティティが非常に重要である理由です

00:10:09.600 --> 00:10:14.620
そのエージェントが正確に何であるかどのシステムに触れられるか そして状況が不安定になった時に誰に連絡が行くかを把握する必要があります

00:10:14.620 --> 00:10:21.420
最小特権がここでの基本原則でなければなりません 広範な利便性に甘んじたり後で権限を厳しくすればいいと自分に言い聞かせたりしてはいけません

00:10:21.420 --> 00:10:27.820
サポートエージェントの影響範囲は完全にその権限に依存するため 権限の設計はサポート設計の中核をなす部分なのです

00:10:27.820 --> 00:10:34.980
エージェント365はこの構成において不可欠な制御レイヤーとして機能します なぜならエージェント全体の状態を明確に可視化できるからです

00:10:34.980 --> 00:10:40.180
これは安全な運用を維持するためのレジストリ 承認ワークフローおよびポリシーテンプレートを提供します

00:10:40.180 --> 00:10:44.840
これらは単なる管理業務のように聞こえるかもしれませんが 巨大な構造的問題を解決するものです

00:10:44.840 --> 00:10:50.880
多くの組織が苦労しているのはAI機能の不足ではなく 環境内で何が稼働しているのかを把握制御できていない点にあります

00:10:50.880 --> 00:10:58.780
この点に関する調査結果は非常に端的です システム内で現在稼働しているすべてのエージェントを完全に把握できている大企業はごく少数にすぎません

00:10:58.780 --> 00:11:03.420
リーダーが自立型サポートの拡張について議論する前に もっと単純な問いに答える必要があります

00:11:03.420 --> 00:11:10.140
私たちはどのエージェントが存在し現在何をしているのかを把握できているでしょうか 監視体制も伴うリスクのレベルに合わせる必要があります

00:11:10.140 --> 00:11:16.300
限定的な範囲で動く個人の生産性向上エージェントと共有コンテンツに触れる コラボレーション型エージェントでは全く性質が異なります

00:11:16.300 --> 00:11:21.340
さらに機密性の高いワークフローで行動を起こすエンタープライズ無形エージェントは また別のリスクカテゴリーに分類されます

00:11:21.340 --> 00:11:28.700
だからこそ個人コラボレーションエンタープライズというリスクゾーンモデルが非常に重要なのです 制御モデルは予測される影響度に応じてレベルを引き上げるべきです

00:11:28.700 --> 00:11:35.200
すべてのエージェントを一律に扱うと低リスクな作業は承認待ちで停滞し 高リスクな作業は不十分な審査で通り抜けてしまいます

00:11:35.200 --> 00:11:39.800
少なくともマイクロソフト365における制御スタックはチームにとって馴染みのあるものであるべきです

00:11:39.800 --> 00:11:44.300
エントラによるID管理パービューによるデータ境界の保護 そしてディフェンダーによる監視を活用します

00:11:44.300 --> 00:11:49.640
条件付きアクセスを通じてアクセス条件を適用し最初から監査機能が組み込まれていることを確認してください

00:11:49.640 --> 00:11:54.460
インシデント発生後推測に頼ることなく何が起きたのかを正確に再現できるようにする必要があります

00:11:54.460 --> 00:11:58.860
人間の監視は機器に瀕してアドリブで行うのではなくロジックの中に設計しておく必要があります

00:11:58.860 --> 00:12:02.360
影響の大きいアクションには常に人間による承認ステップを設けるべきです

00:12:02.360 --> 00:12:05.940
その判断理由は人が実際に確認し理解できる形式で記録される必要があります

00:12:05.940 --> 00:12:10.360
最初の自律的なアクションが実行される前にロールバック切り戻しの経路を確保しておく必要があります

00:12:10.360 --> 00:12:13.200
エージェントがアクセス権を更新したりルーティングポリシーを変更したりした場合

00:12:13.200 --> 00:12:16.240
誰かがその決定を追跡し適切に元に戻せる方法が必要です

00:12:16.240 --> 00:12:19.780
初期のデモが非常に優れているためリーダーがしばしば見落とすもう一つの要素があります

00:12:19.780 --> 00:12:21.680
それは手戻りにかかるコストです

00:12:21.680 --> 00:12:25.780
エージェントがチームのために後片付けのループを生み出すなら予測されていたコスト削減効果は一瞬で消え去ります

00:12:25.780 --> 00:12:27.620
これが手戻りの税金です

00:12:27.620 --> 00:12:30.600
これは不適切な出力を修正したり誤ったアクションを取り消したり

00:12:30.600 --> 00:12:33.080
意図しない副作用を追跡したりするために費やされる時間のことです

00:12:33.080 --> 00:12:38.580
チームが実行時間を10分短縮しても後処理に8分費やしてしまえば実際にはサポートを自動化できていません

00:12:38.580 --> 00:12:41.460
単にプロセスの別の部分に摩擦を移動させただけなのです

00:12:41.460 --> 00:12:44.520
信頼とは洗練されたポリシー資料や代々的な発表から生まれるものではありません

00:12:44.520 --> 00:12:46.380
それは実行時の証拠から生まれるものです

00:12:46.380 --> 00:12:50.420
エージェントが何を見て何を判断しシステムで実際に何が変わったのかを人は確認する必要があります

00:12:50.420 --> 00:12:52.940
それこそが自立型サポートへの信頼を築く方法です

00:12:52.940 --> 00:12:56.540
証明となるのはプロジェクトのブランディングではなくツールの振る舞いです

00:12:56.540 --> 00:13:01.940
ガバナンスの基盤が固まればようやくセキュリティ用語から経営層の言葉へと議論を移せます

00:13:01.940 --> 00:13:04.560
これは最終損益に何をもたらすのでしょうか

00:13:04.560 --> 00:13:07.340
目に見えないサポートの新しいロイ投資利益率です

00:13:07.340 --> 00:13:10.760
リーダーが制御モデルを受け入れると財務的な問いかけが変わり始めます

00:13:10.760 --> 00:13:13.560
旧モデルではサポートの価値はチケット処理数や対応件数

00:13:13.560 --> 00:13:15.960
sla達成率といった目に見える作業で図られていました

00:13:15.960 --> 00:13:19.940
そうした数字も重要ですがそれらは問題への事後対応を表しているにすぎません

00:13:19.940 --> 00:13:21.840
どれだけのトラブルが急に届く前に消えたのか

00:13:21.840 --> 00:13:25.240
問題が早期解決されたことでどれだけの従業員の時間が守られたのかは教えてくれません

00:13:25.240 --> 00:13:27.480
それが会計上の革新的な問題です

00:13:27.480 --> 00:13:30.340
目に見えないサポートは不在を通じて価値を喪失します

00:13:30.340 --> 00:13:31.780
チケットもエスカレーションもなく

00:13:31.780 --> 00:13:35.920
アナリストが不完全なメモから問題を再現するために20分を費やすこともないとき

00:13:35.920 --> 00:13:37.340
その価値が実感されます

00:13:37.340 --> 00:13:41.900
サポートチームの目に見える作業量だけを評価していると本来求めていた成果を見失います

00:13:41.900 --> 00:13:45.120
あなたが求めていたのは中断が少なく安定した業務環境だったはずです

00:13:45.120 --> 00:13:47.800
チケット数は単独では弱い指標にすぎません

00:13:47.800 --> 00:13:52.980
チケットの減少は需要源を意味する場合もありますが環境が健全化しサポート層が賢くなった結果である可能性もあります

00:13:52.980 --> 00:13:54.940
これらは全く異なる意味を持ちます

00:13:54.940 --> 00:13:58.520
経営層にはその違いを見分けられるKPIセットが必要です

00:13:58.520 --> 00:14:01.480
まずは自立解決率を見ることから始めるべきです

00:14:01.480 --> 00:14:04.740
これはボットの会話数ではなく人間が一切関与することなく

00:14:04.740 --> 00:14:07.400
エンドツーエンドで解決されたサポート件数を指します

00:14:07.400 --> 00:14:10.540
また平均解決時間の短縮も追跡する必要があります

00:14:10.540 --> 00:14:15.560
AI駆動型環境では診断作業の多いフローで40から60%の改善が見られることも珍しくありません

00:14:15.560 --> 00:14:19.400
次に解決あたりのコストと取り戻せたユーザー生産性を見ることができます

00:14:19.400 --> 00:14:21.400
最後の指標は見落とされがちです

00:14:21.400 --> 00:14:24.400
標準的なサービスデスクのレポートには綺麗に収まらないからです

00:14:24.400 --> 00:14:27.120
しかしそこにこそ真の価値が宿ることが多いのです

00:14:27.120 --> 00:14:31.820
チケットを切る前の15分間足止めされただけでその人は会社に損失を与えています

00:14:31.820 --> 00:14:35.960
それを会議の中断やアクセス時の摩擦と掛け合わせ大規模なテナント全体で見れば

00:14:35.960 --> 00:14:38.380
潜在的な損失は急で見るよりも遥かに大きくなります

00:14:38.380 --> 00:14:42.120
だからこそビジネスケースにおいては不作為によるコストモデルが重要になるのです

00:14:42.120 --> 00:14:45.960
正式なサポートが始まる前の手作業に費やされた時間を算出するのです

00:14:45.960 --> 00:14:48.260
そこにエラーややり直しのコストを加えます

00:14:48.260 --> 00:14:51.620
すると突然先制的な対応の是非は単なる理論ではなくなります

00:14:51.620 --> 00:14:54.240
単に未来型のサポート層に投資するだけではありません

00:14:54.240 --> 00:14:57.640
長年日々の業務に潜んでいた隠れたコストを取り除くことになるのです

00:14:57.640 --> 00:15:00.580
特定のケースにおける経済性を見ればそれはさらに明らかです

00:15:00.580 --> 00:15:05.440
エージェント型ITサポートの研究では人間による対応は1件あたり約8ドル75セントかかるとされています

00:15:05.440 --> 00:15:10.600
対照的に特定のエージェント処理であればシステム構築後は1件あたり50セント以下に抑えられます

00:15:10.600 --> 00:15:13.360
すべてのサポート業務がそれほど安くなるわけではありません

00:15:13.360 --> 00:15:16.160
リーダーは広範な平均値の扱いに注意が必要です

00:15:16.160 --> 00:15:21.380
テレメトリの品質とガバナンスは常に最終コストに影響しますがトレンドの方向性は間違いありません

00:15:21.380 --> 00:15:25.000
ITが従来のコストセンターという物語から脱却する瞬間です

00:15:25.000 --> 00:15:31.140
サポートがなくなるわけではなくバックグラウンドで従業員の生産性を守る信頼性の層へと変わるのです

00:15:31.140 --> 00:15:35.640
ビジネス側は劇的なサポートイベントではなく業務が円滑に進むことでそれを実感します

00:15:35.640 --> 00:15:40.100
中断は減り復旧は早まりルーティングや確認作業に浪費される労力も削減されます

00:15:40.100 --> 00:15:43.460
とはいえ測定方法を誤れば進歩を簡単に偽装できてしまいます

00:15:43.460 --> 00:15:48.280
テレメトリが弱ければエージェントは障害を実際に防ぐのではなく単に要約を早くするだけになりかねません

00:15:48.280 --> 00:15:52.120
手戻りがダッシュボードに反映されなければロイは実際よりも遥かによく見えてしまいます

00:15:52.120 --> 00:15:56.960
取り戻した時間が低価値な活動に流れてしまえばリーダーは利益を過大評価することになります

00:15:56.960 --> 00:16:01.800
財務上の妥当性は障害の未然防止や手作業の削減といった確実な証拠に基づかなければなりません

00:16:01.800 --> 00:16:04.940
有用な業務に真に戻された時間を測定する必要があります

00:16:04.940 --> 00:16:09.120
適切に測定すればサポート部門は削減すべきオーバーヘッドには見えなくなります

00:16:09.120 --> 00:16:12.720
ビジネスがようやく取り戻せる運用能力として移るようになるのです

00:16:12.720 --> 00:16:15.200
ではサポートチームには何が起きるのでしょうか

00:16:15.200 --> 00:16:17.660
現場のチームに何をもたらすか考えてみてください

00:16:17.660 --> 00:16:22.500
この意向は人員削減のためではなくスタッフの日常業務を根元から変えるためのものだからです

00:16:22.500 --> 00:16:28.560
従来の体制ではサポート能力の大半がパスワードリセットチケットのルーティング終わりのない確認作業に費やされていました

00:16:28.560 --> 00:16:33.040
連携を想定していないシステム間で人間がデータを追いかけ移動させているのです

00:16:33.040 --> 00:16:37.600
そうした作業のどれも環境を安定させるものではなくただ球が溢れるのを防いでいるにすぎません

00:16:37.600 --> 00:16:42.460
予測可能なルーティンワークをエージェントが担えば人間の努力は一段上のレベルへと進みます

00:16:42.460 --> 00:16:47.840
サポートエンジニアは健全な状態の定義や承認ロジックの調整に時間を避けるようになります

00:16:47.840 --> 00:16:54.040
彼らは知識ソースの改善ポリシー動作のテストそしてエージェントが規定の範囲内で機能しているかの確認に注力するのです

00:16:54.040 --> 00:16:59.320
それは1日10件名を眺めてユーザーが何を求めているのか推測する仕事とは全く異なります

00:16:59.320 --> 00:17:02.480
ここがほとんどの導入でプロジェクトが停滞するポイントです

00:17:02.480 --> 00:17:07.680
組織は古い壊れたプロセスを維持したままエージェントを導入し成果の向上を期待してしまいます

00:17:07.680 --> 00:17:12.600
しかしプロセスは依然として受け身のままで引き継ぎは混乱し根本的な知識も不足したままです

00:17:12.600 --> 00:17:15.840
エージェントは崩れかけた壁にペンキを塗り重ねるようなものになってしまいます

00:17:15.840 --> 00:17:19.780
質問への回答は早くなるかもしれませんが遅延を前提としたサポートモデルそのものは修正できません

00:17:19.780 --> 00:17:22.360
より良い方法はまず業務を再設計することです

00:17:22.360 --> 00:17:26.820
判断や繊細なコミュニケーションを要するため人間が担当し続けるタスクを見極める必要があります

00:17:26.820 --> 00:17:31.400
次に結果が予測可能で安全なアクションについては自律的なフローへ移行させる判断をします

00:17:31.400 --> 00:17:34.380
サポートチームはなくならないためこの役割分担が不可欠です

00:17:34.380 --> 00:17:37.700
彼らは単に制御を設計し例外を処理する専門家へと進化するのです

00:17:37.700 --> 00:17:40.220
つまり人材育成の方法も変えなければなりません

00:17:40.220 --> 00:17:44.520
チームは手作業を実行するだけでなくシステムを監視する方法を学ぶ必要があります

00:17:44.520 --> 00:17:49.140
ロールバックの論理や監査レビューそしてエージェントを本番稼働させる前のテスト手法を理解しなければなりません

00:17:49.140 --> 00:17:51.880
またモデルが失敗している兆候を見抜く力も必要です

00:17:51.880 --> 00:17:54.800
自動化された悪いワークフローはやはり悪いワークフローに過ぎないからです

00:17:54.800 --> 00:17:56.780
それは問題をより早く悪化させるだけです

00:17:56.780 --> 00:18:00.700
将来を見据えた採用を行うのであればチケットの取り味を行うゼネラリストはもう必要ないかもしれません

00:18:00.700 --> 00:18:06.340
マイクロソフト365スタック全体でフローを構築しエージェントを適切に制御できる人材が必要です

00:18:06.340 --> 00:18:11.720
サポート需要を積み上げるのではなく環境を改善して需要そのものを減らせる人材を求めているのです

00:18:11.720 --> 00:18:16.500
では数年にわたる巨大な変革プロジェクトにせずにどうやってこれを開始すれば良いのでしょうか

00:18:16.500 --> 00:18:21.760
最善の一手はマイクロソフト365関係台で常に摩擦を生んでいる単一のフローを選ぶことです

00:18:21.760 --> 00:18:27.260
アクセス権の修正は最適な候補の一つですが会議サポートやデバイスコンプライアンスの引き継ぎも検討できます

00:18:27.260 --> 00:18:32.940
頻繁に発生するパターンであり成功の姿が明確であればどれを選んでも構いません

00:18:32.940 --> 00:18:36.980
ターゲットが決まったら徹底した規律を持って基本を定義する必要があります

00:18:36.980 --> 00:18:42.120
何が正常な状態かを理解しどのような事象が軌道から外れているサインなのかを見極める必要があります

00:18:42.120 --> 00:18:46.920
どの行動を自動化しても安全かそしてどの時点で人間によるエスカレーションが必要かを決定してください

00:18:46.920 --> 00:18:52.880
公開前にチケット数や手作業の発生回数ユーザーの平均待ち時間のベースラインを確実に把握しておきましょう

00:18:52.880 --> 00:18:55.820
また初日からガバナンス体制を確立しておく必要があります

00:18:55.820 --> 00:19:00.440
エージェントに固有のIDを与え責任者となる人間を割り当て明確な承認ルールを設定してください

00:19:00.440 --> 00:19:03.540
エージェントが実行するすべての動作は記録される必要があります

00:19:03.540 --> 00:19:09.040
エージェントが引退や再割り当てされる際の計画も立てておき幽霊のような自動化状態にならないようにしましょう

00:19:09.040 --> 00:19:12.980
最初のフローが機能し始めると組織の運用モデル全体が変化し始めます

00:19:12.980 --> 00:19:16.520
サポート部門は問題に対処するだけの受付窓口ではなくなります

00:19:16.520 --> 00:19:20.760
代わりにシステムに直接組み込まれた信頼性のエンジンとして機能し始めます

00:19:20.760 --> 00:19:24.100
サポートの役割は目に見える対応から組み込み型の予防へと移行します

00:19:24.100 --> 00:19:26.160
チケットは決してサービスそのものではありませんでした

00:19:26.160 --> 00:19:28.580
それはサービスの提供が遅すぎたことの証拠だったのです

00:19:28.580 --> 00:19:32.540
今市販機はサポートフローを一つ選び対応型から先回り型へと再設計してみましょう

00:19:32.540 --> 00:19:36.960
M365コパイロット、Azure、セキュリティ、AI運用モデルについて詳しく知りたい方は

00:19:36.960 --> 00:19:39.780
M365FMを購読しレビューをお願いします

00:19:39.780 --> 00:19:43.980
リンクトインで私、ミルコピーテルとつながり今後取り上げて欲しいトピックを教えてください