チケット管理は計画上は効率的に見えます 数値化されQが作られダッシュボードで管理されますしかし実際にはそのモデルはシステムがすでに破綻した後の苦痛を測定しているにすぎませんコストが膨らむ問題の発生源は通常はるかに手前にあります 従業員が10分20分と時間を失い最終的に諦めてしまうところから始まります彼らはやり直します同僚に尋ねます正しい手順が使えなくなったことで会議に遅れたり 誤ったファイルを共有したりしますこれこそが多くのサポートチームが見落としている部分です 今日の最善の社内サポートモデルはトリアージの高速化ではありませんトリアージの必要性そのものをなくすことです マイクロソフト365内でコンテキストを監視し摩擦を早期に発見しユーザーがポータルを開こうと考える前に対処する自立型エージェントを想像してください 今回のエピソードではなぜヘルプデスクモデルが破綻するのかそれに変わるものは何かそして混乱を招かずにどう管理できるのかを解説します この変化が重要だと感じたらm365fmを登録してくださいなぜならそのさらに奥にある真の問題は9ではなくその背後にあるモデルだからです チケットの終焉従来のサポートフローは今も至るところに存在します何かが故障します ユーザーがそれに気づきますユーザーが状況を説明しようと試みますit 部門がその説明をカテゴリ優先度割り当てグループなどに変換します 問題が9に入ります誰かがトリアージを行います別の担当者が詳細を尋ねます他のチームが関与します実際の作業が止まっている間も時間だけが過ぎていきます 慣れ親しんでいるため正常に感じられますが慣れていることと効率的であることは別物ですチケットはサポートではありませんチケットはサポートの到着が遅れたという証拠です チケットが作成された時点で従業員はすでに障害に直面し作業のコンテキストを失っています彼らはすでに行おうとしていた仕事から注意をそらされています キューはサービスではありませんキューは失敗の記録です大規模なマイクロソフト365環境では手動でのトリアージが真のボトルネックとなりますこれはサポートチームが怠慢だから起こるわけではありません 環境の規模に合わなくなった業務を人間に求めていることが原因ですユーザーデバイスアプリポリシーの数が増えています チームシェアポイントエクスチェンジインチューンエントラをまたぐ複雑なエッジケースが同時に発生しています増えているのは量だけではありません組み合わせも複雑化しています そこで従来のモデルが破綻するのです多くのチームは構造をさらに増やすことで対応しようとします新たなポータル別のボットさらなるルーティングルールを構築します しかし実際にはそれが従業員と解決策の間にさらなる層を加えているだけなのですシステムは今もなおユーザーが問題に気づきそれを説明し適切な方法で助けを求めるのを待ち続けています 仕事はサポートポータルで始まるのではありませんチームでアウトルックで今すぐ必要なドキュメントであるいは30秒後に始まる会議で 始まりますそこにこそ実際のサポートニーズが存在しておりチケット管理モデルはその瞬間から完全に切り離されているのです その隠れたコストは旧のレポートに示されるよりもはるかに大きなものです人々はコンテキストの切り替えを繰り返しています 重複したインシデントが異なるラベルの下で積み上がっていきますナレッジ記事は陳腐化していきます アナリストは本来の修復作業ではなく分類やルーティング状況確認に1日中追われています解決までの時間が延びるのは引き継ぎの度に遅延が発生しその度に本来の文脈が 失われていくからですエージェント型 ai と it 運用に関する調査はいずれも同じ構造的な問題を指摘しています少なくとも80%の労力が今もアイティル型のリアクティブな作業に縛られています この数字は重要ですなぜなら労働力がどこに費やされているかを正確に示しているからですそれはレジリエンス回復力や予防ではなく事後対応に費やされています そう気づけばチケットは運営モデルというよりも症状のように見えてくるはずですそれは被害が目に見えてからしか反応しないシステムの症状なのです したがって次の問いはいかにチケットを早く処理するかではなくチケットが必要になる前にシステムが何をすべきかになります見えない従業員インビジブルエンプロイーモデルですでは何が実際にチケットにとって変わるのでしょうか それは同じ混乱の上に置かれた単なるチャットボットではありませんし当然従来の急に見栄えの良い入り口を作っただけのものでもありません この変化はもっと深いものですなぜなら見えない従業員とはマイクロソフト365関係台で働く運用担当者だからですこのエージェントには独自のIDと明確な業務範囲があり 機能の記憶を持ち何に触れられ何に触れられないかという厳格なルールを備えていますその違いが重要なのです チャットボットはユーザーの入力を待ちますが見えない従業員は状況の変化を監視しますそれは会話から始まるのではなく文脈から始まります サインインの状態デバイスの健全性ライセンス状況ファイルの共有方法を把握しているため問題が起きるのを待つ必要はありません 何かが壊れた後に助けを求めるのではなくバックグラウンドで常に別の問いを投げかけています今従業員が業務を遂行するために必要な状態から何が乖離しているのか そこに変化が生まれますこのモデルは業務そのものに直接組み込まれています 会議に参加した際音声設定に失敗したりゲストが送られたファイルを開けなかったりした場合古い世界ではレポートが作成され引き継ぎが行われるだけです 新しいモデルではエージェントはパターンを即座に認識しその状況が基地の問題に該当するかを確認した上で修正のための安全な次のアクションを 実行しますパスのリセットやポリシーチェックの実行あるいはリクエストの経路変更や mfa 多要素認証の要求を行いその修正内容を記録します要点はシンプルです 最初の対応において人間が曖昧な説明を読んで何が起きたのかを推測する必要はもうありませんうまく機能している場合このプロセスは目に見えません 待機室もなければカテゴリーを選択してくださいといったフォームに記入する必要もないからですサポートはワークフローが復旧するという形で現れます 従業員はすぐに業務に戻れます多くの場合背後で動いているメカニズムを目にすることさえありませんこれが人員配置の考え方をどう変えるかはすでに明らかでしょう 従来のモデルでは大量の問い合わせを処理しリクエストを仕分けチーム間の断絶したコンテキストを整理するために人を雇っていました新しいモデルではトリアージを行う人員は減りガードレールの設計あるべき状態の定義 そしてエージェントの長期的な振る舞いを監督する人員が求められます人間はシステムの中に残り続けますが日々の業務のあり方は根元から変わります サポートにおけるエージェント型 ai の研究は一貫してこの方向を示していますルーチン的なサポートは例外ベースの処理へと移行でき環境とポリシーが適切に制限されていれば劇的な効率化が実現します最後の一点は極めて重要ですなぜならこれは魔法ではないからです データが貧弱でプロセスが整理されていなければ自立型と呼んだだけでエージェントが賢くなることはありませんエージェントをソフトウェア機能として捉えるのをやめバッジを持つ人間ではない 従業員として見始めたときすべてが腑に落ちました実際の労働者にはアイデンティティ職務記述書権限そして報告すべきマネージャーが必要です エージェントにも全く同じものが必要です価値はチャットウィンドウでの気の利いた言葉ではなくシステム内での信頼できるアクションから生まれるからです この見えない従業員は単なるUIのトリックではありませんこれはマイクロソフト365環境全体の摩擦を監視しポリシーの範囲内で行動し 判断が必要な例外のみを人間に委ねる新しいサポート層ですそのモデルが明確になれば次の疑問は非常に実践的なものになります プリエンプション先制対応は具体的にどう機能するのでしょうかプリエンプションのアーキテクチャではマイクロソフト365の中でプリエンプションは実際にどのように 機能するのでしょうかシフトの焦点はリクエストと応答からイベントの推論とオーケストレーションへと移ります 専門的に聞こえますが分解してしまえばモデルは単純ですまず環境内で何かが変化し次にシステムがその変化がリスクやドリフトを意味するかを解釈し 最終的に既存のスタックにあるツールを使って承認されたアクションを実行しますまずはイベント層から始めましょう マイクロソフト365は常にシグナルを発信しておりエントラはサインイン動作をインチューンはデバイスの状態とコンプライアンスを監視しています ディフェンダーは不審な動きを監視しチームは会議の失敗や通話品質の低下を正確に把握しますシェアポイントとエクスチェンジはアクセスパターンやコンテンツの動きを可視化し サービス正常性シグナルはプラットフォーム自体に問題があるかを伝えますそこにユーザーの行動を重ね合わせることで絶え間ないコンテキストの流れが生まれます 多くの組織はこれらのシグナルを収集していますがそれをサポートシステムとして活用できている組織はほとんどありません単なる生データでは不十分でありノイズから意味を見出すための推論層が必要です ここで見えない従業員は単なる自動化の演出から本物のオペレーターへと進化しますエージェントはシグナルを観察し現状とあるべき姿を比較してどの程度の対応が安全かを判断します 会議の音声トラブルは危険なサインインとは異なり共有リンクの破損はライセンスの不一致とは全く別物ですエージェントはまず問題を分類しなければなりません 分類なしにアクションを起こせばかえってミスを増やすだけだからです次にオーケストレーションが行われます 問題を理解したエージェントは適切な仕組みを使って対応を開始しますワークフローならパワーオートメートロジックならコパイロットスタジオ システム操作やコンテキスト取得ならマイクロソフトグラフが使われますツールも重要ですがそれらがどう連携するかがより大きな意味を持ちます ただ賢いプロンプトを作るのではなく検出判断実行検証を行う連鎖を構築するのです最後の検証プロセスは非常によく見落とされます 自己修正システムはアクションを起こして終わりではありません問題を検出し条件をテストし修正を適用し 結果を検証して記録するというサイクルを回し続けます自己修正ロジックの研究によればこれらのシステムは言語モデルによる単発の回答ではなく フィードバックと修正パターンを通じて機能しますもし最初のアクションが失敗してもシステムは定義された制限内で次のステップを修正できる よう原因を評価する手段を持っていますマイクロソフト365の事例を見るとこの仕組みが明確に理解できます ライセンスとポリシー範囲の不一致でユーザーがブロックされるとエージェントは不整合を検知し本来の役割プロファイルを称号します 許容された修正を適用しユーザーのアクセスを確認した上で誰にも頼ることなく変更を記録しますエントラで危険なサインインが発生するとエージェントは直ちにリスクイベントを認識し 条件付きアクセスルールを確認しますポリシーに基づき強化された認証を求めるかアクセスを遮断し その結果を後で人間が確認できるよう記録に残しますシェアポイントで古い共有リンクが何度も失敗する場合 エージェントは現在の権限パスと期待される共有ルールを比較しますエージェントは破損したルートを承認済みのものに置き換え 修正されたリンクをコンテキスト内に送信しますこれによりヘルプデスクの担当者がアクセスに関する緊急の問題というチケットを読む前に問題を解決できます会議サポートも素晴らしい例です 会議開始の数秒前に会議室のデバイスが故障したり接続経路が途切れたりした場合 エージェントはその状況を検知し障害を特定できますエージェントはリスクの低い復旧手順を試み チームで主催者に通知して作業が行われているその場でステータスを更新しますそのコミュニケーションレイヤーは設計の非常に重要な部分です サポートは中断が発生する場所に存在しなければなりませんあなたの仕事がチームアウトルック m 365ワークスペースで行われているならサポートもそこで回答すべきですコンテキスト内で対応できるのであればユーザーを別の場所に誘導する必要はありません これはすべてのタスクを完全に自動化することを意味するわけではありませんそれは無謀だからです リスクの低いアクションは自動実行できますが影響の大きい変更には依然として人の承認が必要ですその承認プロセスは後から付け足すのではなく最初からアーキテクチャの一部である必要があります エージェントはいつ行動しいつ尋ねいつ正確に停止すべきかを知っておくべきですそしてそれをフローに組み込むと会話の内容は自動化機能の話ではなくなります それは制御ガバナンス信頼そしてエージェントのアイデンティティの話になりますサポートが自律的に動き始めるとすぐに難しい問題が浮上します 実際に作業を行っているのは誰かその答えが曖昧だとモデル全体が崩壊してしまいますエージェントは広範なアクセス権を持ち所有者が明確でないような曖昧なヘルパーとして環境内に存在してはなりませんエントラ内に実在するアイデンティティが必要です 指名された所有者定義されたスコープそして特定の理由で開始終了するライフサイクルが必要ですもしそのエージェントがデータを読み取ったりワークフローを起動したりユーザーにメッセージを送ったりできるなら テナントのアクティブな参加者として管理しなければなりません誰かがオンにして忘れてしまった機能のように扱うことはできません これがシステムにとってエージェントのアイデンティティが非常に重要である理由ですそのエージェントが正確に何であるかどのシステムに触れられるか そして状況が不安定になった時に誰に連絡が行くかを把握する必要があります最小特権がここでの基本原則でなければなりません 広範な利便性に甘んじたり後で権限を厳しくすればいいと自分に言い聞かせたりしてはいけませんサポートエージェントの影響範囲は完全にその権限に依存するため 権限の設計はサポート設計の中核をなす部分なのですエージェント365はこの構成において不可欠な制御レイヤーとして機能します なぜならエージェント全体の状態を明確に可視化できるからですこれは安全な運用を維持するためのレジストリ 承認ワークフローおよびポリシーテンプレートを提供しますこれらは単なる管理業務のように聞こえるかもしれませんが 巨大な構造的問題を解決するものです多くの組織が苦労しているのはAI機能の不足ではなく 環境内で何が稼働しているのかを把握制御できていない点にありますこの点に関する調査結果は非常に端的です システム内で現在稼働しているすべてのエージェントを完全に把握できている大企業はごく少数にすぎませんリーダーが自立型サポートの拡張について議論する前に もっと単純な問いに答える必要があります私たちはどのエージェントが存在し現在何をしているのかを把握できているでしょうか 監視体制も伴うリスクのレベルに合わせる必要があります限定的な範囲で動く個人の生産性向上エージェントと共有コンテンツに触れる コラボレーション型エージェントでは全く性質が異なりますさらに機密性の高いワークフローで行動を起こすエンタープライズ無形エージェントは また別のリスクカテゴリーに分類されますだからこそ個人コラボレーションエンタープライズというリスクゾーンモデルが非常に重要なのです 制御モデルは予測される影響度に応じてレベルを引き上げるべきですすべてのエージェントを一律に扱うと低リスクな作業は承認待ちで停滞し 高リスクな作業は不十分な審査で通り抜けてしまいます少なくともマイクロソフト365における制御スタックはチームにとって馴染みのあるものであるべきですエントラによるID管理パービューによるデータ境界の保護 そしてディフェンダーによる監視を活用します条件付きアクセスを通じてアクセス条件を適用し最初から監査機能が組み込まれていることを確認してくださいインシデント発生後推測に頼ることなく何が起きたのかを正確に再現できるようにする必要があります人間の監視は機器に瀕してアドリブで行うのではなくロジックの中に設計しておく必要があります影響の大きいアクションには常に人間による承認ステップを設けるべきですその判断理由は人が実際に確認し理解できる形式で記録される必要があります最初の自律的なアクションが実行される前にロールバック切り戻しの経路を確保しておく必要がありますエージェントがアクセス権を更新したりルーティングポリシーを変更したりした場合誰かがその決定を追跡し適切に元に戻せる方法が必要です初期のデモが非常に優れているためリーダーがしばしば見落とすもう一つの要素がありますそれは手戻りにかかるコストですエージェントがチームのために後片付けのループを生み出すなら予測されていたコスト削減効果は一瞬で消え去りますこれが手戻りの税金ですこれは不適切な出力を修正したり誤ったアクションを取り消したり意図しない副作用を追跡したりするために費やされる時間のことですチームが実行時間を10分短縮しても後処理に8分費やしてしまえば実際にはサポートを自動化できていません単にプロセスの別の部分に摩擦を移動させただけなのです信頼とは洗練されたポリシー資料や代々的な発表から生まれるものではありませんそれは実行時の証拠から生まれるものですエージェントが何を見て何を判断しシステムで実際に何が変わったのかを人は確認する必要がありますそれこそが自立型サポートへの信頼を築く方法です証明となるのはプロジェクトのブランディングではなくツールの振る舞いですガバナンスの基盤が固まればようやくセキュリティ用語から経営層の言葉へと議論を移せますこれは最終損益に何をもたらすのでしょうか目に見えないサポートの新しいロイ投資利益率ですリーダーが制御モデルを受け入れると財務的な問いかけが変わり始めます旧モデルではサポートの価値はチケット処理数や対応件数sla達成率といった目に見える作業で図られていましたそうした数字も重要ですがそれらは問題への事後対応を表しているにすぎませんどれだけのトラブルが急に届く前に消えたのか問題が早期解決されたことでどれだけの従業員の時間が守られたのかは教えてくれませんそれが会計上の革新的な問題です目に見えないサポートは不在を通じて価値を喪失しますチケットもエスカレーションもなくアナリストが不完全なメモから問題を再現するために20分を費やすこともないときその価値が実感されますサポートチームの目に見える作業量だけを評価していると本来求めていた成果を見失いますあなたが求めていたのは中断が少なく安定した業務環境だったはずですチケット数は単独では弱い指標にすぎませんチケットの減少は需要源を意味する場合もありますが環境が健全化しサポート層が賢くなった結果である可能性もありますこれらは全く異なる意味を持ちます経営層にはその違いを見分けられるKPIセットが必要ですまずは自立解決率を見ることから始めるべきですこれはボットの会話数ではなく人間が一切関与することなくエンドツーエンドで解決されたサポート件数を指しますまた平均解決時間の短縮も追跡する必要がありますAI駆動型環境では診断作業の多いフローで40から60%の改善が見られることも珍しくありません次に解決あたりのコストと取り戻せたユーザー生産性を見ることができます最後の指標は見落とされがちです標準的なサービスデスクのレポートには綺麗に収まらないからですしかしそこにこそ真の価値が宿ることが多いのですチケットを切る前の15分間足止めされただけでその人は会社に損失を与えていますそれを会議の中断やアクセス時の摩擦と掛け合わせ大規模なテナント全体で見れば潜在的な損失は急で見るよりも遥かに大きくなりますだからこそビジネスケースにおいては不作為によるコストモデルが重要になるのです正式なサポートが始まる前の手作業に費やされた時間を算出するのですそこにエラーややり直しのコストを加えますすると突然先制的な対応の是非は単なる理論ではなくなります単に未来型のサポート層に投資するだけではありません長年日々の業務に潜んでいた隠れたコストを取り除くことになるのです特定のケースにおける経済性を見ればそれはさらに明らかですエージェント型ITサポートの研究では人間による対応は1件あたり約8ドル75セントかかるとされています対照的に特定のエージェント処理であればシステム構築後は1件あたり50セント以下に抑えられますすべてのサポート業務がそれほど安くなるわけではありませんリーダーは広範な平均値の扱いに注意が必要ですテレメトリの品質とガバナンスは常に最終コストに影響しますがトレンドの方向性は間違いありませんITが従来のコストセンターという物語から脱却する瞬間ですサポートがなくなるわけではなくバックグラウンドで従業員の生産性を守る信頼性の層へと変わるのですビジネス側は劇的なサポートイベントではなく業務が円滑に進むことでそれを実感します中断は減り復旧は早まりルーティングや確認作業に浪費される労力も削減されますとはいえ測定方法を誤れば進歩を簡単に偽装できてしまいますテレメトリが弱ければエージェントは障害を実際に防ぐのではなく単に要約を早くするだけになりかねません手戻りがダッシュボードに反映されなければロイは実際よりも遥かによく見えてしまいます取り戻した時間が低価値な活動に流れてしまえばリーダーは利益を過大評価することになります財務上の妥当性は障害の未然防止や手作業の削減といった確実な証拠に基づかなければなりません有用な業務に真に戻された時間を測定する必要があります適切に測定すればサポート部門は削減すべきオーバーヘッドには見えなくなりますビジネスがようやく取り戻せる運用能力として移るようになるのですではサポートチームには何が起きるのでしょうか現場のチームに何をもたらすか考えてみてくださいこの意向は人員削減のためではなくスタッフの日常業務を根元から変えるためのものだからです従来の体制ではサポート能力の大半がパスワードリセットチケットのルーティング終わりのない確認作業に費やされていました連携を想定していないシステム間で人間がデータを追いかけ移動させているのですそうした作業のどれも環境を安定させるものではなくただ球が溢れるのを防いでいるにすぎません予測可能なルーティンワークをエージェントが担えば人間の努力は一段上のレベルへと進みますサポートエンジニアは健全な状態の定義や承認ロジックの調整に時間を避けるようになります彼らは知識ソースの改善ポリシー動作のテストそしてエージェントが規定の範囲内で機能しているかの確認に注力するのですそれは1日10件名を眺めてユーザーが何を求めているのか推測する仕事とは全く異なりますここがほとんどの導入でプロジェクトが停滞するポイントです組織は古い壊れたプロセスを維持したままエージェントを導入し成果の向上を期待してしまいますしかしプロセスは依然として受け身のままで引き継ぎは混乱し根本的な知識も不足したままですエージェントは崩れかけた壁にペンキを塗り重ねるようなものになってしまいます質問への回答は早くなるかもしれませんが遅延を前提としたサポートモデルそのものは修正できませんより良い方法はまず業務を再設計することです判断や繊細なコミュニケーションを要するため人間が担当し続けるタスクを見極める必要があります次に結果が予測可能で安全なアクションについては自律的なフローへ移行させる判断をしますサポートチームはなくならないためこの役割分担が不可欠です彼らは単に制御を設計し例外を処理する専門家へと進化するのですつまり人材育成の方法も変えなければなりませんチームは手作業を実行するだけでなくシステムを監視する方法を学ぶ必要がありますロールバックの論理や監査レビューそしてエージェントを本番稼働させる前のテスト手法を理解しなければなりませんまたモデルが失敗している兆候を見抜く力も必要です自動化された悪いワークフローはやはり悪いワークフローに過ぎないからですそれは問題をより早く悪化させるだけです将来を見据えた採用を行うのであればチケットの取り味を行うゼネラリストはもう必要ないかもしれませんマイクロソフト365スタック全体でフローを構築しエージェントを適切に制御できる人材が必要ですサポート需要を積み上げるのではなく環境を改善して需要そのものを減らせる人材を求めているのですでは数年にわたる巨大な変革プロジェクトにせずにどうやってこれを開始すれば良いのでしょうか最善の一手はマイクロソフト365関係台で常に摩擦を生んでいる単一のフローを選ぶことですアクセス権の修正は最適な候補の一つですが会議サポートやデバイスコンプライアンスの引き継ぎも検討できます頻繁に発生するパターンであり成功の姿が明確であればどれを選んでも構いませんターゲットが決まったら徹底した規律を持って基本を定義する必要があります何が正常な状態かを理解しどのような事象が軌道から外れているサインなのかを見極める必要がありますどの行動を自動化しても安全かそしてどの時点で人間によるエスカレーションが必要かを決定してください公開前にチケット数や手作業の発生回数ユーザーの平均待ち時間のベースラインを確実に把握しておきましょうまた初日からガバナンス体制を確立しておく必要がありますエージェントに固有のIDを与え責任者となる人間を割り当て明確な承認ルールを設定してくださいエージェントが実行するすべての動作は記録される必要がありますエージェントが引退や再割り当てされる際の計画も立てておき幽霊のような自動化状態にならないようにしましょう最初のフローが機能し始めると組織の運用モデル全体が変化し始めますサポート部門は問題に対処するだけの受付窓口ではなくなります代わりにシステムに直接組み込まれた信頼性のエンジンとして機能し始めますサポートの役割は目に見える対応から組み込み型の予防へと移行しますチケットは決してサービスそのものではありませんでしたそれはサービスの提供が遅すぎたことの証拠だったのです今市販機はサポートフローを一つ選び対応型から先回り型へと再設計してみましょうM365コパイロット、Azure、セキュリティ、AI運用モデルについて詳しく知りたい方はM365FMを購読しレビューをお願いしますリンクトインで私、ミルコピーテルとつながり今後取り上げて欲しいトピックを教えてください