ITSMの変更管理にAIを活用する：自動化すべきことと、CABに残すこと

TL;DR

ITSMの変更管理でAIが力を発揮するのは、承認ではなく書類仕事です。会議の前に、すべての変更要求についてバックアウト計画やテスト結果の欠落をチェックさせ、リスクスコアを分かりやすい言葉で説明させ、そして最も役立つこととして、失敗した変更の後にサービスデスクへ押し寄せるチケットを、原因となった変更に結び付けさせましょう。通常変更も緊急変更も、承認して実行するのは引き続き名前の挙がった担当者です。これはServiceNow、Jira Service Management、Freshserviceが現在構築しているものとも一致します。各社のAIは下書きと提案を行い、変更を自動承認するものはありません。

AIを書類仕事に向ける理由は、調査にあります。GoogleのSREチームは、障害のおよそ70%は稼働中のシステムへの変更が原因だと述べています。またDORAは、委員会による重厚な承認を行うチームは低パフォーマーになる確率が2.6倍高く、それでいて障害率は下がっていないと明らかにしました。ゲートキーパーを賢くしても解決しません。入ってくる要求の質を上げ、問題が起きたときに素早く紐付けられるようにすることが解決策です。

サービスデスクがJira Service ManagementやZendeskで動いているなら、eeselがチケット側のチームメイトになれます。新しいリクエストを読み、最近の変更を検索し、原因の可能性が高い変更を挙げた社内メモを残し、リスクのあるものは人の判断を待つよう保留します。InDebtedのIT責任者は、社内のJSMデスクでの一次対応担当として利用しています。

ITSMの変更管理にAIは役立つか？

はい。ただし、仕事の「正しい半分」に向けることが条件です。変更管理(ITIL 4では変更実現と呼びます)には2つの半分があります。変更を行うべきか判断することと、変更後に起きることへの対処です。AIは、その両方を取り巻く読み取り、突き合わせ、要約が得意です。決める役には向きません。

私はeeselのヘルプデスク連携、Jira Service Management連携も含めて開発しており、他社のITSMキューの中で過ごす時間がとても長くなっています。社内ITデスクで見られるパターンは一貫しています。変更プロセス自体は、書面上はたいてい機能しています。1週間を食いつぶすのは、半端に埋められた変更要求をめぐるやり取りと、「VPNが落ちています」というチケットが30件並んでいるのに、サービスデスクの誰も土曜日にファイアウォールルールが変更されたことを知らない月曜朝です。

この図がすべてを語っています。AIが役立つ3つの段階は、書類と突き合わせの比重が大きいものです。真ん中の2つは判断と実作業であり、人に残ります。

端の段階が中央より重要な理由を、数字が裏付けています。

DORAの結果は、考え方を変えるべきものです。DORAは、正式な承認が変更障害率を下げるという証拠を探しましたが、「この仮説を裏付ける証拠は見つからなかった」としています。つまり、同じ委員会の会議にAIのリスクスコアを足しても、変更を安全にしていなかった手順が速くなるだけです。より良い賭けは、入力(この要求は完全か？)と出力(この変更はどのチケットを生んだか？)にAIを使うことです。

変更のそれぞれの段階で、AIはどこに入るか？

AIが入るのは、受付、リスクの説明、CABの準備、そして変更後のチケットの波です。承認と実施は人のままです。以下は私が使う区分で、各段階について主要なITSMツールが提供しているものも示します。

この表から2つのことが見えてきます。1つ目は、どのベンダーも同じ線で止まっていることです。AIが提案し、人が提出します。2つ目は、「変更後」の行が最も手薄なことです。そこはサービスデスクの現場であり、私が読んだコミュニティのスレッドで痛みの大半が生じている場所でもあります。

CABが見る前に、AIは変更要求をチェックできるか？

はい。私ならここから始めます。リスクが低く、行き来のやり取りを最も減らせるからです。完全性チェックは要求を読み、人が時間をかける前に不足している点を指摘します。

最も完成度の高い形を提供しているのはServiceNowです。変更品質アセッサーは、変更の5つの要素(実施計画、バックアウト計画、テスト計画、リスクと影響の分析、正当性)を「Excellent」から「Incomplete」までの尺度で評価します。最初に自社の変更ポリシー文書を確認し、文書がない場合にのみ、完了済みの類似変更にフォールバックします。この順序が重要です。ポリシーを文書化しておけば、AIは過去の変更がたまたまどうだったかではなく、自社の基準に照らして評価します。

なぜ手間をかけるのか。ロールバックの問いこそ、CAB会議が時間を費やす質問であり、現場の人もそれを知っているからです。

「実際の仕事は何もしていないようなものだよ。1時間の会議に座って、最後に『ロールバック計画はありますか？』と聞くためだけに給料をもらっている人がいるだけさ。」

u/timmyotc, Reddit

要求が提出された瞬間にAIがその質問をしてくれれば、会議でする必要はありません。ServiceNowのない小規模チームでも、同様のことを無料で実現できます。小さな会社のシステム管理者の1人は、変更ドキュメント自体をAIに作らせることを提案しています(「何をするのか、ロールバック計画、リスクなど」)。これはr/sysadminのスレッドにあります。AIが記入するチェックリストも、誰かが読むチェックリストであることに変わりはありません。

実務上の注意点を1つ。前面にヘルプデスクAIを置いているデスクでは、同じチェックを会話の中で行えます。誰かがSlackで「DNSの切り替えの変更はどう起票しますか？」と尋ねたとき、エージェントはConfluenceにある変更ポリシーから回答し、最初にバックアップ計画を尋ねることができるので、要求は完全な形で届きます。これはAI ITヘルプデスクのセルフサービス側を、変更に適用したものです。

AIは変更のリスクをスコア化できるか？

部分的にはできます。役に立つのは、リスクスコアを説明し、その背後にある履歴を引き出す形です。注意すべきなのは、数字だけを渡して信じることを期待する形です。

各ツールが何をしているか、詳しく見てみましょう。

• ServiceNow：リスクスコア自体は、ルールベースのしきい値(0〜25が低、26〜50が中、51以上が高)を持つアンケートから算出されます。AIの層はその上に載っており、類似の変更要求とそれらが引き起こしたインシデントを使ってスコアを説明し、人が提出前に確認できるようリスクの回答を事前入力することもできます。
• Jira Service Management：AIリスク評価は、信頼度スコアと低・中・高の評価を付けた文章の要約を作成します。影響を受けるサービスの未解決インシデント、失敗したデプロイ、過去90日間に同じサービスで却下された変更、テスト計画とロールバック計画の有無を確認します。
• Freshservice：変更リスクポリシーはルールベースで、各要素を0〜10で採点し、任意で重みを付けます。FreddyのAIの役割は過去の類似変更を見つけることで、スコアを出すことではありません。

私の見解は、AIのリスク出力は評決ではなくブリーフィングとして扱うべき、というものです。Jiraのドキュメントはこの点で異例なほど率直です。この機能は「変更を自動的に承認または却下」せず、「保証された、または決定論的な予測を提供」することもありません。CABが頼る前に知っておきたい癖もあります。評価はユーザーごとに、各人が閲覧できる権限に基づいて生成されるため、同じ変更でも2人の承認者に異なる要約が表示されることがあります。

精度についても、現実的な期待を持って臨んでください。ServiceNowのAIが自社の履歴を知るのは、その履歴がServiceNowに、きちんと紐付けられて入っている場合だけです。ある実務者は、デモが本番より良く見える理由をこう説明しています。

「営業が使うデモインスタンスは、うまく仕上げるのが難しいんだ。本当の意味での『過去』データがないから、機械学習モデルに何を_どこへ_割り当てるべきかを教えるものが何もない。」

u/Excited_Idiot, Reddit

逆もまた真です。変更がサービスや構成アイテムに紐付いていなければ、「類似の変更とそのインシデント」の部分は突き合わせる対象を持ちません。Jiraも、競合検出が機能するのは「関連する変更がサービスやアセットに適切に紐付けられ、計画された開始日と終了日を含んでいる場合」だけだとはっきり述べています。

AIは変更諮問委員会を置き換えるべきか？

いいえ。ただしCABが見る対象は絞り込むべきです。ほとんどのCABの本当の問題は、人の判断が下手なことではありません。すべてについて判断するので、すべてを流し読みしてしまうことです。

「大企業で契約の仕事をしていたとき、理論上はこう動くはずだった。でも実際には、技術者たちが部屋いっぱいに座って自分の名前が呼ばれるのを待ち、その後はゴム印を押すだけ。同僚から変更に異議が出たのを見た記憶は一度もないよ。」

u/Unable-Entrance3110, Reddit

二次的なコストもあります。変更を週次の会議にまとめると、変更が一斉に着地することになります。

「CABにかけるべきでないものをCABにかけて一番嫌なのは、同時に起きる変更がひとかたまりになることだ……CAB会議の後にね。何かが壊れたとき、会議の後の15分間に投入された何十もの変更のどれが原因でもおかしくない。」

esikich, Hacker News

DORAの最新ガイダンスである変更承認の合理化も同じ方向を指しています。「すべての変更を同等に扱う」のをやめ、「継続的な分析によりリスクの高い変更を早期に検出して指摘し、追加の精査を受けられるようにする」というものです。これは仕分けの仕事であり、仕分けはAIの得意分野です。役に立つCABの資料は次のようになります。

1. 標準変更はテンプレートで事前承認し、周知のためだけに一覧化します。Jira Service Managementはすでに、自動化ルールで標準変更を自動承認できます。ServiceNowも標準変更を事前承認済みとして扱います。
2. 不完全な要求は会議の前に、不足点を明示して差し戻します。
3. 競合を指摘します。同じウィンドウで同じサービスに2つの変更がある場合や、凍結期間内の変更などです。
4. リスクの高い少数の変更には、それぞれ1段落の要約と、うまくいかなかった類似の過去変更を添えます。

ServiceNowの変更サマリーは、変更の17項目(実施計画、テスト計画、バックアウト計画を含む)を読み取って短いブリーフにまとめ、競合アセッサーは影響を受けるCIをブラックアウト期間やメンテナンス期間と照合します。AtlassianのPrevention Centerは、変更サマリー、依存関係マップ、カレンダー衝突チェックをまとめていますが、まだ公開の早期アクセスプログラムの段階にあるため、これを前提に計画を立てる前にご自身のプランを確認してください。

委員会は、その1時間を4番目の項目に使います。これが、DORAがゲートキーパーではなく「プロセスの設計者であり情報の灯台」と呼ぶCABの姿です。

変更がうまくいかなかった後、サービスデスクでは何が起きるか？

誰かが変更と結び付ける前に、チケットが届きます。ITチームにとって最も重要な段階だと私は考えていますが、ITSMベンダーが最も手薄にしている部分でもあります。

規模は途方もなくなり得ます。2024年7月19日にCrowdStrikeが不具合のあるコンテンツアップデートを配信したとき、同社自身のレビューによれば、元に戻されるまで約78分間稼働しており、Microsoftは850万台のWindowsデバイスに影響したと推定しました。社内の変更の大半ははるかに小さいものですが、サービスデスクで起きる形は同じです。原因は1つなのに、それぞれ違う症状を訴えるチケットが何十件も届きます。

そのデスクを担当する人たちも、同じように語っています。

「参考になるかは分からないけど、僕はサービスデスクにいて、こっちも同じ感じだよ。何かをリリースしたり更新したりするたびに、テストなどに時間をかけているのに、ほぼ直後から火消しを始めることになる。本当に疲れるんだ。」

u/rootpl, Reddit

そして最悪なのは、誰にも知らされなかった変更です。あるr/sysadminのスレッドでは、承認済みの変更が、工場が休業のはずの土曜日に実施されました。生産管理者はその日が二重生産日だとは知らされておらず、投稿者は3時間の停止による損失を150万ドルと見積もっています。

最初の1時間でAIができることは次のとおりです。

1. パターンを見つける。 短い時間に同じサービスについての新規チケットが複数あれば、それはシグナルです。チケットの重複排除と同じ考え方です。
2. そのサービスの最近の変更を調べる。 Jira Service Managementでは変更も課題なので、影響を受けたサービスの過去数日間の変更をJQLで検索すれば、「何か変わったか？」に数秒で答えが出ます。
3. 各チケットに社内メモを残す。 原因の可能性が高い変更キーを記すことで、チケットを引き継ぐ担当者はゼロからではなく原因から始められます。
4. 影響を受けた全員に1通のステータス返信を送る。 下書きは1回、承認も1回です。これはステータスページの更新やメジャーインシデントのコミュニケーションと同じ仕事で、きっかけが変更になるだけです。
5. 変更の担当者に知らせる。 チケット件数を添えることで、ロールバックの判断が証拠をもとに行われます。

最も近いネイティブ機能を持つのはFreshserviceです。起点変更サジェスターは、過去14日間にクローズされた変更のうち、インシデントの原因となった可能性があるものを順位付けし、エージェントが正しいものを手動で紐付けます。早期アクセスで、Copilotアドオンが必要です。

14日間という期間は妥当なガードレールです。先月の変更が今朝のチケットの原因であることはまれで、それでも提案してくるAIはノイズを増やすだけです。

変更管理のAIを備えたITSMツールはどれか？

最も深い機能群を持つのはServiceNow、最も文書化の整ったリスク評価を持つのはJira Service Management、インシデントから変更への紐付けが最も強いのはFreshserviceです。eeselのようなヘルプデスク側のAIは、どのITSMが変更記録を保持していても、チケットの波と依頼者との会話をカバーします。購入者が実際に確認する細部で比較すると次のとおりです。

出典：ServiceNow ITSM packages、Atlassian pricing、Freshservice pricing。Atlassianのページにはチーム規模と請求の切り替えがあるため、席数に応じた最新の金額をご確認ください。

ServiceNow Otto(Now Assist)for ITSM

ServiceNowのドキュメントでは、生成AIアプリを現在「ServiceNow Otto for IT Service Management」と呼んでいますが、料金ページではまだNow Assistと表記されています。8つのエージェント型変更ワークフローが挙げられており、競合評価、品質評価、スケジューリング、CIの提案、対話での変更作成などが含まれます。

良い点は、ガードレールが明示されていることです。デフォルトではすべてのエージェントワークフローのレコードは読み取り専用で、単独で実行するには、複製して有効化し、トリガーを与える必要があります。競合、品質、スケジューリングのエージェントは手動で呼び出します。計画しておくべき点としては、変更管理はFoundationパッケージに含まれず、「AI Agents for ITSM」の項目はPrimeにしか登場しないため、見積もりの相談を見込んでおく必要があります。実務者の評価は分かれており、r/servicenowのある返信はこのAIを「現実よりも営業トーク」と呼び、別の返信は1年以内にはまともになると見ています。費用の詳細はServiceNowの料金の解説をご覧ください。

**私たちの見解：**すでにServiceNow ITSM AdvancedまたはPrimeを使っていて、CMDBがそれなりに整っているなら選ぶ価値があります。品質アセッサーだけでも有効にする価値があります。

Jira Service ManagementとRovo

AtlassianのAIリスク評価はRovo(背後のエージェントは現在Ops Expertと呼ばれます)を搭載し、リンクされたナレッジベース記事、変更の説明にあるURL、接続されたデプロイパイプラインを読み取ります。リスクを技術面と運用面に分け、軽減策を提案します。1つを承認すると、変更に紐付いたフォローアップタスクが作成されます。

良い点は、リンクされたプルリクエストに対して基本的な静的コード解析を実行できることで、変更がデプロイであるチームには大きな利点です。デプロイゲーティングにより、変更が承認されるまでBitbucketやJenkinsのパイプラインを一時停止できます。計画しておくべき点は、2024年10月16日以降、すべての変更機能がPremiumまたはEnterpriseにあること、HIPAAに準拠していないこと、そして出力が権限によってユーザーごとに異なることです。全体像はJira Service ManagementのAIとRovoをご覧ください。

**私たちの見解：**変更の大半がCI/CDから来るチームに最適です。Standardプランをお使いなら、AIリスク評価はツールを乗り換える理由ではなく、Premiumの価格を調べる理由になります。

Freshservice with Freddy AI

Freshserviceの変更AIは予測ではなく履歴に重きを置いています。類似変更サジェスターは、最大6か月前までの一致する変更を、それぞれのリスクレベルと紐付けられたインシデント件数とともに表示します。

良い点は、「この変更は前回2件のインシデントを起こした」という情報が承認者に提示できる最も説得力のある材料であり、それが変更記録にそのまま載ることです。計画しておくべき点は、リスクスコアがルールベースであること、AIリスクアンケートビルダーは稼働中ではなく将来のリリースで予定されていること、そして両方の変更AI機能にCopilotアドオンが必要なことです。プラットフォームを比較中なら、FreshserviceとServiceNow、FreshserviceとJira Service Managementをご覧ください。

**私たちの見解：**すでにProを契約している中規模のITチームに向いています。CSMが有効化できるようになったら、すぐに起点変更サジェスターをオンにしましょう。

サービスデスク側のeesel

eeselはITSMではなく、変更記録も保持しません。ヘルプデスクのキューに参加するAIチームメイトなので、変更管理での役割はチケット側にあります。変更の起票方法を尋ねる人への回答、変更後のチケットの波への対応、変更の担当者への状況共有です。Jira Service ManagementとZendeskにネイティブ接続します。JSMでは、新しいリクエストとコメントを拾い、返信するか社内メモを残し、JQLで課題を検索し、ラベルを付け、担当者を割り当て、ワークフローを進めることができます。Jiraの履歴から学習するのではなく、課題をリアルタイムで読み取り、知識の出どころはConfluenceなどのソースです。

ServiceNowやFreshserviceには、組み込みのコネクタはありません。方法は、Network Access経由でそのツールのAPIを使うか、MCPサーバーがあればそれを使うことですので、自分で設定する準備をしておいてください。詳しくはITSMツール向けAIをご覧ください。

**私たちの見解：**痛みがCABではなくサービスデスクにあるときに追加してください。エージェントの席数ではなく、対応したチケット単位で課金されます。

変更管理のAIはどう設定するか？

最も安価で安全な手順から始めて、外側へ広げていきます。一般的な社内ITチームで私が従う順序で、AIへの信頼を広げていく順序と対応しています。

1. 変更ポリシーを文書にする。 1つの文書に、各変更タイプに必要なもの、良いバックアウト計画とは何か、誰が何を承認するか、凍結期間はいつかを書きます。ServiceNowの品質アセッサーは最初にポリシー文書を読みますし、他のどのAIも文書があった方がうまく動きます。ConfluenceやGoogleドライブのように、AIが読める場所に置きましょう。Google Driveも使えます。
2. 完全性チェックを、提案モードでオンにする。 数週間、何もブロックせずに新規要求の不足をAIに指摘させます。人がAIに同意する頻度を数えます。
3. 変更をサービスと日付に紐付ける。 競合検出、類似変更の突き合わせ、変更後のチケット紐付けは、すべてこれに依存します。残りを機能させる、地味な手順です。
4. サービスデスクを変更記録につなぐ。 Freshserviceのサジェスター、JSMでのJQL検索、ヘルプデスクのエージェントのどれでも、目標は同じです。新しいインシデントを、そのサービスの最近の変更と照合することです。まず過去のチケットで試してください。本番で信頼する前に、直近の失敗した変更のときのチケットで過去チケットを使ったシミュレーションを実行します。
5. 書き込み操作は承認の背後に置く。 全員にメッセージを送る、チケットを遷移させる、変更記録に触れるといった操作は、しばらく正しく動くのを確認するまで、まず人に確認させましょう。eeselでは各アクションが個別に、実行、事前確認、オフのいずれかを選べ、承認はSlackのカードとして届けることもできます。
6. AIへの指示も変更として扱う。 エージェントのルールがチケットの扱い方を変えるなら、バージョン管理して、他の変更と同じように展開します。Swiftregは、eeselの指示をその場で編集せず、番号付きのリリースとして自社の手順で展開しており、これはITチームに望ましい習慣そのものです。
7. 3つの数字を測る。 差し戻した不完全な要求の数、変更障害率(DORAの定義：ホットフィックスやロールバックが必要になったデプロイ)、失敗した変更あたりのチケット数です。3つ目が下がり、CABでロールバック計画を追いかける人がいなくなれば、うまくいっています。サポートレポートの仕組みがあれば、3つ目の数字は簡単に取り出せます。

変更管理でAIが決してやってはいけないことは何か？

このリストは短く保ち、プロンプトだけでなくツールの権限で強制してください。

• 通常変更や緊急変更の承認・却下。 3大ITSMのどれもAIにはさせていませんし、回避策を作るべきでもありません。
• 変更の実行。 スケジュールの提案は構いませんが、本番環境に触れることは認められません。
• インシデントの原因を断定すること。 原因の可能性が高い変更を挙げることはできます。確認するのは人です。
• ロールバックが行われたからといってチケットを解決済みでクローズすること。 依頼者に確認してください。ロールバックでサービスが直っても、ユーザー側の壊れた状態が残ることがあります。
• 変更記録の計画を勝手に編集すること。 ServiceNowの自律的な品質エージェントがここでは良いお手本で、スコアとメモを保存しつつ「変更要求のフィールドに値を設定することはしません」。

共通するのは説明責任です。何か問題が起きたとき、インシデント後のレビューには判断を下した名前の挙がった人が必要で、「AIが承認した」は監査人が受け入れる答えではありません。アクセスレベルについて詳しくは、AIセキュリティレビューガイドをご覧ください。

ITサービスデスクでeeselを試す

変更が混乱したチケットの山となってサービスデスクに届いているなら、eeselがそのキューにチームメイトとして入れます。Jira Service Managementでは、影響を受けたサービスの最近の変更を検索し、新しいチケットごとに原因の可能性が高い変更キーを記した社内メモを残し、人が承認するステータス返信を1通下書きします。Slackでの「変更はどう起票しますか？」という質問にも、自社のポリシーから答えます。InDebtedは社内のJSMデスクで一次対応担当として運用しており、チケットの15%を自力で解決し、目標は55%です。Zendeskでは、Cactus Club Cafeが社内の技術サポートで利用しており、チームのランブックに段階的に従って、1か月で790件の返信を下書きしました。

100クレジットの無料プランがあり、有料プランは月額$299(500クレジット)からで、席ごとの料金はありません。先月の変更関連チケットでeeselを試して、何を指摘できたかを確認してみてください。