TeamsとSlackで完結するAIサービスデスクの現実
要約
ServiceNowのFlowを起点に、TeamsやSlackで使えるAIサービスデスクの機能と限界を整理します。本人確認、権限操作、有人引き継ぎ、段階導入の進め方まで、社内問い合わせの自動化を検討する際の判断材料を紹介します。
社内問い合わせの窓口を、専用ポータルからTeamsやSlackへ移す動きが海外で議論されています。ServiceNowが打ち出したAIネイティブのサービスデスク「Flow」は、普段の業務ツールから自然言語で依頼する体験を想定したものです。
2026年10月時点で注目されているのは、AIが回答するだけでなく、チケット作成や定型処理まで進める範囲です。便利な窓口を置くだけでは、サービスデスクの運用は自動化できません。
この記事の対象読者
- 社内問い合わせの対応負荷が高い企業
- TeamsやSlackで業務を進める組織
- パスワードリセットを自動化したい企業
- ITサービスデスクの導入費を抑えたい組織
- 生成AIを社内で進めたい企業や組織
Flowが変える問い合わせ窓口
普段のチャットを入口にする設計
海外では、既存のITサービス管理基盤を先に大きく整えなくても使えるAIサービスデスクとして、Flowが議論されています。入口として想定されるのは、社員が日常的に開くTeamsやSlack、メール、専用Web画面です。
- TeamsやSlackで自然文の問い合わせを受け付ける
- 内容に応じてチケットや依頼を作成する
- 定型業務の手順を呼び出して処理を進める
- 処理できない依頼を担当者へ引き継ぐ
この形なら、社員は新しいポータルの場所や操作を覚えずに済みます。問い合わせの入口を普段のチャットへ置くことで、利用開始時のつまずきを減らせる可能性があります。
定型処理と権限操作の境界
自動化の範囲をどこで引くか
Flowのような会話型サービスデスクで期待されるのは、パスワードリセットなどの定型業務を、問い合わせから完了までつなぐことです。単に手順書を返すのではなく、条件を確認して処理を実行する設計が論点になります。
一方で、パスワードリセットは本人以外が依頼するとアカウント保護を弱めます。AIが自然な会話を続けられても、本人確認の強度が十分とは限りません。
- 依頼者が本人かを確認する方法
- AIが実行できる操作の範囲
- 追加認証や承認が必要になる条件
- 操作前後に残すログの内容
- 失敗時に処理を止める条件
導入時は、業務名ではなく操作単位で権限を分けると整理しやすくなります。パスワードリセットは許可しても、権限グループの変更やアカウント新設は有人承認に回す、といった切り分けです。
例外時に残る有人対応
引き継ぎに必要な情報を揃える
AIが処理を完了できない依頼は必ず発生します。本人確認に失敗した場合、申請内容が規程外の場合、外部システムが停止している場合などは、有人対応への切り替えが必要です。
- 社員が何を依頼したか
- AIが確認した情報
- すでに実行した操作
- 処理できなかった理由
- 担当者が次に確認すべき事項
この情報が担当者へ渡らないと、社員は同じ説明を繰り返す羽目になります。AI導入後も有人対応が残る前提で、引き継ぎ画面と責任の所在を決めておくことが必要でしょう。
日本企業が始める業務範囲
最初の対象を絞って検証する
日本企業が会話型の窓口を導入するなら、最初から全社の問い合わせを対象にしない進め方が現実的です。まずはパスワードリセットのように、対象範囲とリスクを限定しやすい業務から検証します。
- 対象業務の受付条件を決める
- 本人確認と実行権限を分ける
- 例外時の有人担当を決める
- 操作ログの確認方法を決める
- 効果と安全性を見て対象業務を広げる
測定する項目は、問い合わせ件数だけに絞らないことが大切です。自己解決率、処理完了までの時間、有人対応への引き継ぎ率、誤操作や再処理の件数を並べると、次の業務へ広げる判断がしやすくなります。
自社導入で詰まりやすい設計
PoCから本番へ移るために整えること
自社で進める場合、TeamsやSlackとの接続より先に、誰が何を依頼できるかを整理する必要があります。本人確認、操作権限、ログ、例外時の担当者が曖昧なままだと、PoC(概念実証)から本番へ移りにくくなるでしょう。
- 既存の本人確認手段とチャットの認証を照合できない
- AIが実行してよい操作と、承認が必要な操作を分けられない
- 有人引き継ぎ後の責任者や対応期限が決まっていない
外部の支援を使う場合は、ツールを先に決めるのではなく、現場の問い合わせと既存手順を確認してから対象範囲を絞るのが現実的です。BinxAI株式会社のみっちゃくんは、提案の前に現場へ入り、課題の整理と現状の診断を済ませてから要件を固めます。
見積は一式でまとめず、要件を整理したうえで詳細を提示。契約後に要件が動いても、決めた範囲の中で優先順位を入れ替えながら、企画や要件整理から開発まで同じ担当が一貫して対応します。
- 課題の整理と現状の診断
- 要件定義と設計
- 開発と本番環境への展開
- 運用の引き継ぎと内製化の支援
- 担当者向けの研修
よくある質問
AIサービスデスクは、回答生成よりも業務の境界設計で成否が分かれます。
FlowはTeamsとSlackだけで使えますか？
TeamsやSlackを含む複数の入口が議論されているところです。ただし、利用できるチャネルや連携範囲は契約条件や環境で変わる可能性があるため、導入前に確認が必要です。
パスワードリセットは完全自動化できますか？
定型処理の自動化は検討できますが、本人確認と実行権限の条件を満たす必要があります。確認に失敗した依頼や規程外の依頼は、有人対応へ切り替える設計が必要です。
既存のITSMを導入していなくても始められますか？
既存のITSM(ITサービス管理)を前提にしない形が議論されています。ただし、問い合わせ履歴や操作ログをどこで管理するかは、別途決めておく必要があるでしょう。
最初に自動化する業務は何が向いていますか？
パスワードリセットのように、処理条件を限定しやすく、実行後の確認方法を決めやすい業務が候補です。権限変更のように影響範囲が広い操作は、初期対象から外すのが無難でしょう。
AIが間違えたときは誰が対応しますか？
あらかじめ決めたサービスデスク担当者が引き受ける形になります。依頼内容、確認情報、実行済み操作、失敗理由を引き継げるようにすると、再確認の負担を抑えやすくなります。
TeamsやSlackを入口にしたAIサービスデスクは、社員の行動を変えずに問い合わせ窓口を近づけられる可能性があります。導入時は、パスワードリセットなどの小さな範囲で本人確認、権限、例外処理、ログを検証し、結果を見ながら広げていく進め方が現実的でしょう。
あわせて読みたい
この記事の分類
同じ分類の記事をまとめて読めます。
次に読む記事
ソフトバンクのAIエージェント事例から学ぶ 申請・問い合わせ業務の設計と効果測定
ソフトバンクが公開したCopilot StudioとPower Automateの事例をもとに、申請判断や社内問い合わせへAIエージェントを組み込む業務設計を整理します。人へ戻す条件、後続処理、削減時間と品質の測り方まで、自社で小さく検証する手順を紹介します。
Salesforceの職種別エージェントが変える業務自動化
Salesforceが示した職種別AIエージェントは、質問に答えるチャットボットから業務を継続実行する仕組みへ広がっています。提供範囲、長期タスク、KPI、権限管理、有人引き継ぎを導入前にどう設計するかを整理します。
実データなしでAIエージェントを試すEra by Eonとは
Era by Eonで仮想企業と業務シナリオを使い、実データを投入する前にAIエージェントを検証する進め方を解説します。複数システムの連携確認や本番移行前の評価項目、失敗時の停止条件まで実務者向けに整理します。
