HigLabo
最新記事
ServiceNowとMicrosoft CopilotのAIエージェント運用は何が違う？ ITSM部門が先に確認すべき監査ログと承認フロー
ServiceNowとMicrosoft Copilotの比較は、まず運用統制から見る
AIエージェントの比較というと、どうしても回答精度や自動化の派手さに目が向きがちです。ですがITSM部門にとって先に見るべきなのは、事故が起きたあとに追跡できるか、危ない処理の前で止められるかです。
この記事では、ServiceNowとMicrosoft Copilotの違いを、監査ログ取得、承認フロー介在、部門展開のしやすさの観点から整理します。機能の優劣ではなく、どちらが自社の統制要件に合うかを判断するための比較として見ていきます。
回答性能より先に、AIの行動を管理できるかを見る
ITSM基盤や社内業務基盤でAIエージェントを本番運用する際は、答えがうまいかどうかより、行動をどこまで管理できるかが重要です。問い合わせ対応だけでなく、チケット更新、ナレッジ参照、申請処理、変更作業の起票など、業務への影響が大きい操作につながるためです。
たとえば、AIがインシデントの優先度を変更したり、申請内容をもとに処理を進めたりする場合、問題になるのは誤動作そのものだけではありません。誰が承認し、どの根拠で動いたかを説明できない状態のほうが、監査や内部統制では深刻です。
再現性と追跡性が求められる点では、AIの便利さより、説明可能な形で運用できるかが問われます。ここが曖昧なままだと、PoCでは好評でも本番展開や部門展開の段階で止まる、という失敗が起こりやすくなります。
ServiceNowは業務フロー中心、Copilotは作業支援中心で設計差を見る
両者の違いを大きく分けるなら、一般的な傾向として、ServiceNowはワークフローと業務実行の中にAIを組み込みやすく、Microsoft 365 Copilotはユーザーの作業支援や情報要約の体験に強いと整理しやすい面があります。機能拡張は進んでおり、Copilot StudioやPower Platform連携を通じて業務フロー実装も可能ですが、代表的な設計の違いを押さえると運用設計がしやすくなります。
ServiceNowは、もともとITSMや業務プロセスの基盤です。そのため、レコード、承認、チケット状態、実行フローといった業務の枠組みの中でAIを動かしやすい特徴があります。
一方のMicrosoft 365 Copilotは、Microsoft 365やTeamsの情報と結びつき、利用者の作業を横断的に補助する強みがあります。Power Platformとの連携を含む業務フロー実装はCopilot StudioやPower Automateを含む構成で検討されることが多く、文章作成、要約、会議整理、データ参照のような領域では、効果が見えやすい設計です。
この違いは、そのまま監査ログ取得や承認フローの設計にもつながります。業務プロセスの中でAIが動くのか、ユーザー操作を補助する形でAIが関わるのかで、残すべき記録と承認の置き場所が変わるからです。
監査ログ取得で先に確認したい3つの観点
監査ログを見るとき、ITSM部門は少なくとも3つの観点で確認したいところです。誰が起点になったか、何に基づいて判断したか、どこまで実行したか。この3点が追えないと、統制設計は不安定になります。
- 誰が起点になったか：ユーザーの指示なのか、システムトリガーなのか、代理実行なのかで、責任の置き方が変わります。
- 何に基づいて判断したか：参照したナレッジ、チケット情報、接続先データ、利用したポリシーやルールが追えるかを確認します。
- どこまで実行したか：単なる提案で終わったのか、フィールド更新まで行ったのか、申請送信や外部連携まで実行したのかで、統制上の意味合いは大きく変わります。
特に重要なのは、会話履歴だけでは足りないという点です。監査ログは、何を話したかだけでなく、何を実行したかまで追える必要があります。
ServiceNowでは、レコード更新やフロー実行との結びつきを確認しやすい場面があります。対してCopilot系では、構成によって異なるものの、プロンプト、参照情報、コネクタ経由の操作、最終的な実行主体の扱いを分けて見ていく必要が出やすくなります。比較時には、各サービスの監査ログ範囲を個別に確認することが重要です。
承認フロー介在は、自動実行と人手介在の境界線から設計する
承認フローで重要なのは、AIをどこで止めるかを先に決めることです。ITSMでは、変更管理、権限付与、重要インシデントのクローズ、外部通知など、ミスの影響が大きい処理ほど、人の承認をどう挟むかが鍵になります。
ServiceNow寄りの設計では、既存の承認・ワークフロー基盤とAIを組み合わせやすいケースがあるため、AIが下書きする、条件一致なら起票する、承認後にだけ実行するといった段階的な統制を置ける場合があります。
一方でCopilot寄りの運用では、ユーザー体験は滑らかでも、どこからが提案で、どこからが実行なのかを明示的に設計しないと、設定次第では現場がそのまま実行してしまうリスクがあります。事故防止の要は製品そのものより、実行権限と承認タイミングをどう分離するかにあります。
現場でありがちなのは、AIが作成した変更要求をそのまま通してしまうケースです。下書き支援としては便利でも、承認責任者が確認すべき項目を省略すると、統制の空洞化が起きます。
導入時は、高リスク処理だけでも必ず人が確認してから次へ進む境界線を定義しておくべきです。
PoC前に固めたい比較表の評価手順と確認項目
PoC前にまず確認したいのは、自社でAIに任せてよい業務の範囲です。問い合わせ要約やナレッジ推薦のような低リスク領域と、権限変更や本番変更のような高リスク領域を分けて考えます。
この整理がないまま製品比較を始めると、評価軸がぶれます。比較の前に、どこまで任せるかを決めることが先です。
次に、監査ログの要件を文章化します。最低限、操作主体、参照根拠、実行結果、承認有無、例外時の記録が残るかは確認しておきたいポイントです。
そのうえで、承認フローを3層に分けると設計しやすくなります。
- 閲覧のみ
- 下書き生成
- 実行
この分け方を使うと、AIができることと、やってよいことを切り分けやすくなります。実務では、PoCの成功条件も「回答が速い」だけで終わらせないことが大切です。
ログが監査部門の期待を満たすか、承認を挟んでも運用が回るか、例外時に人へ戻せるかまで含めて、初めてITSM向けのPoCになります。比較表を作るなら、機能一覧より先に統制一覧を置くほうが実務に合います。
導入判断は、賢さより説明できる運用で決める
ServiceNowとMicrosoft Copilotの違いは、単純な優劣ではありません。一般的な傾向として、自社要件や対象製品による前提はありますが、業務フローの中で統制しやすい環境を重視するならServiceNowが候補になりやすく、日常業務の支援体験やMicrosoft製品との親和性を重視するならMicrosoft 365 Copilotなどが候補になります。
ただし、ITSM部門やITガバナンス担当者が本当に先に確認すべきなのは、AIが何をできるかではなく、何をしたときに記録が残り、どこで人が止められるかです。この2点が曖昧なら、本番運用は長続きしません。
逆に、ここが明確なら、AIエージェントは安全性と生産性の両立に近づきます。迷ったら、監査ログの粒度、承認フローの挿入位置、例外時の手戻し方法の順で見ていくと、製品デモでは見えにくい差が見えてきます。
派手なAI機能ほど注目されがちですが、最後に効くのは地味な運用設計です。導入判断は、機能比較より先に監査ログ取得と承認フロー介在を比較表で整理し、自社の統制要件に合うかで決めるのが実務的です。