ITSM移行とAI対応：プラットフォーム切り替え前にデータに必要な準備

タラス・ヴェリチコによる投稿

2026年7月2日更新

ほとんどの ITSM移行 ガイドにはチェックリストが記載されています。チケットをエクスポートし、ナレッジベースを移行し、移行先でレコード数を確認する、といった内容です。

その移行チェックリストは、2025年にチームが犯す最も高額なミスを防いでくれるものではありません。それは、データがひどく汚染され、不完全で、構造的に一貫性を欠いた状態で最新のAI搭載プラットフォームに移行してしまうことです。そのため、せっかくお金を払って導入したITSMのAI機能がほとんど機能しなくなってしまうのです。.

ITSMプラットフォームは変化したが、チェックリストはそれに追いついていない。.

ServiceNow、 Jira Service Management、 Freshservice、 Zendesk すべて、現在ではAIを標準搭載しています。チケットのトリアージ、インテリジェントなルーティング、エージェントのコパイロット機能、人間が一切関与することなくリクエストタイプ全体を解決するエージェントワークフローなど、これらはプレミアムアドオンではありません。むしろ、プラットフォームを切り替える主な理由となることが多いのです。

しかし、これらの機能はすべてユーザーのデータに基づいて動作します。間違ったデータを使用すると、自動承認リクエストはすべて8か月前に退職したマネージャーに送られてしまいます。チケットは放置され、ユーザーは待たされるばかり。誰もその理由を知りません。.

このガイドでは、ITSMにおけるAIの現状、既存データが移行後もそのまま維持されない可能性がある理由、そしてAIの精度を初日から保護するITSM移行の手順について説明します。.

ITSM AIとは？移行を計画しているITチームのための実践的な解説

ルールベースの自動化からエージェント型AIへ：何が変わったのか

ITSMの自動化は、厳密なif-thenロジックに依存しています。チケットに特定のキーワードが含まれていれば、システムはそれに応じてルーティングします。シンプルですが、基本的なテキストマッチングは常に破綻します。ユーザーはスペルミスをしたり、奇妙な専門用語を使ったり、人間が実際に話すように問題を説明したりするからです。.

この問題を解決するために、ITSM AIは機械学習モデルを使用して、過去のチケットパターン、ナレッジベースの使用状況、解決パス、エージェントの行動をスキャンし、状況に応じた推奨事項を提示します。「ノートパソコンにログインできない」と「エンドポイントでの認証失敗」は恐らく同じ問題であると認識します。この変化により、単に回答を提案するだけでなく、ワークフローを自律的に実行する次世代AI ITSMへの道が開かれました。.

ITSMツールに組み込まれた3種類のAI

おそらくあなたは今、これら3つのレイヤーすべてを評価しているでしょう。それぞれのレイヤーが実際にどのような働きをするのか、そして動作に必要なデータについて、以下に説明します。.

トリアージと予測AI（分類器）

これらのアルゴリズムは、受信したインシデントを分類し、深刻度スコアを割り当て、ビジネスリスクを計算し、適切なチームにチケットを振り分けます。人間のディスパッチャーがチケ​​ットをキューにドラッグ＆ドロップするのを待つ必要はなく、過去のメタデータに基づいて即座に対応します。.

AIは解決済みのチケットに基づいて学習します。過去のデータに一貫性のないカテゴリ、極端な優先順位の変更、または混乱したルーティングが含まれている場合、AIは既存の混乱を修正するのではなく、単に学習して自動化するだけです。.

コパイロット＆生成型AI（アシスタント）

このAIは、エージェントが作業している間、彼らの傍らで待機します。長々と続くインシデントのスレッドを要約し、初期対応案を作成し、類似の解決済みケースを抽出し、解決済みのメモを自動的にナレッジベース記事に変換します。その効果は絶大です。SolarWinds SolarWindsの2025年版ITSM現状レポート インシデント解決時間が6時間短縮されることが分かりました。

副操縦士のアドバイスの質は、あなたの記録された履歴に完全に依存します。もしあなたのエージェントが過去3年間、解決欄に「完了」「修正済み」「通話ごとに解決済み」と入力していたとしたら、副操縦士はそこから有益な情報を得たり、要約したりすることはできません。.

エージェント型AIと自律型エージェント（実行者）

自律型エージェントは、解決策を提案するだけでなく、それを実行します。人間の介入なしに、Active Directoryのパスワードをリセットしたり、仮想マシンを再起動したり、調達ワークフローを開始したりします。.

ここは最も多くのデータを必要とする層であり、データの不備が最も高額な障害を引き起こす場所です。システムは最新の情報と古い情報を区別できず、与えられた情報しか認識できません。.

CMDBに重複した資産タグが含まれている場合、アクティブなインシデント中に自律型エージェントが誤った本番サーバーを再起動してしまう可能性があります。ユーザーディレクトリに18か月前に退職したマネージャーがまだ登録されている場合、自動承認ワークフローは存在しないユーザーに通知してしまうでしょう。マッピングが不適切な資産カテゴリが1つあるだけで、不適切なテキスト候補が表示されるだけでなく、運用ワークフロー全体が機能しなくなる可能性があります。.

ITSMにおけるエージェント型AIがデータに実際に必要とするもの

ほとんどのチームは、これらの条件がどれも一貫して満たされないデータを何年も蓄積しています。これがAIの準備状況の問題です。そして、移行前に誰もこの問題について語りません。ClouderaとHarvard Business Review Analytic Servicesが2026年に実施した調査によると、 46% が、エージェント型AIのスケーリングを阻害する要因としてデータ品質を挙げており、これは前年比で9ポイントの上昇です。これらのシステムを運用している人々のほぼ半数が、同じ壁にぶつかっています。

ITSMプラットフォームを移行する時期が来たことを示す兆候

何かがおかしいことは既にお分かりでしょう。問題は、その問題が現在のシステムで解決できるのか、それとも移行が最善の解決策なのかということです。.

お使いのシステムではAIワークフローをサポートできません

最も明確な兆候は、製品比較資料の中に隠されているわけではありません。それは、ベンダーのAIロードマップが約束する内容と、実際に稼働しているインスタンスが現在提供している内容との間のギャップです。.

自分自身に次の質問を問いかけてみてください。

• 貴社のAI機能を実行するには、別途インフラストラクチャが必要ですか？
• APIのレート制限によって、CMDBやIDプロバイダーとのリアルタイムデータ交換が妨げられていますか？
• 自動化レイヤーには、確率的スコアリングが一切含まれていませんか？
• あなたが本当に必要とするAI機能は、クラウド版にしか存在しないのですか？

もしこれらのうち複数に当てはまるなら、設定の問題ではありません。.

これは建築的な天井です。.

こうした限界が存在する理由はここにあります。従来のプラットフォームは、ルール、フォーム、チケットキューのために構築されたものであり、機械学習のために作られたものではありません。古いリレーショナル databaseにAIを無理やり組み込むことでこのギャップを埋めようとしたベンダーは、基盤となるスキーマが現代のアルゴリズムに必要な意味ベクトル検索を処理できないことに気づきました。結果として、2017年当時の方法で言語を処理するシステムに、エンタープライズ価格を支払うことになるのです。.

Proactivanetの2026年ITSMトレンド分析は 、今後の方向性について率直に述べています。人間の介入なしに分類、提案、解決を行うネイティブAIエー​​ジェントが標準になりつつあります。もしあなたのプラットフォームがこの方向性に沿っていないのであれば、ITSM専用のAIソリューションへの移行は、野心的な選択肢ではなく、唯一の選択肢となるでしょう。

統合負債がチケット解決を遅らせている

よくあるパターンがあります。何年も前に、誰かが監視ツール用のカスタムコネクタを作成しました。次に、人事システム用のコネクタを作成し、さらにIDプロバイダー用のコネクタを作成しました。当時はそれぞれ理にかなっていました。.

現在、これらのコネクタはAPIの更新時に動作しなくなり、専用のメンテナンス期間が必要となり、プラットフォームが本来正常に取り込むように設計されていない形式でデータを渡すようになります。そのため、エージェントは問題解決のたびに、プラットフォームが自動的に表示すべきコンテキストを手動で取得するために、かなりの時間を費やしています。.

測定可能な症状は、人員増加にもかかわらずMTTR（平均修復時間）が改善しないことです。エージェントの作業が遅いのではなく、データ処理システムに問題があるのです。SolarWinds SolarWinds 2025 ITSMレポート では、ルーティング、セルフサービス、AIによる解決など、自動化によってチケット1件あたり平均3時間の時間短縮が可能になると数値で示しています。しかし、断片化された統合スタックでは、こうした時間短縮はほとんど実現できません。

AIは不適切な統合を補うどころか、むしろ悪化させる。重要なコンテキストが欠落したチケットで学習させたモデルは、不完全なデータに基づいて自信満々に意思決定を行うようになる。これはAIを全く使わないよりも悪い結果を招く。.

ライセンス料やサポート費用はもはや正当化されない

実際の数字を算出してください。座席ごとのライセンス料だけではなく、全体像を把握してください。

• 誰も維持管理したがらないインフラに対する専用サポート契約に、実際にはいくら支払っているのですか？
• ベンダーがAPIのアップデートをプッシュするたびに、カスタム統合を維持するために、社内のエンジニアリング部門はどれだけの時間を費やしているのでしょうか？
• アーキテクチャが対応していないために実際には導入できないAI機能に、どれだけの費用を支払っているのでしょうか？

クラウドネイティブプラットフォームは、多くの場合、基本プランにAI機能を搭載しています。エンタープライズ料金を支払っているにもかかわらず、競合他社が標準で提供している機能と同等にするためにさらに3つのモジュールが必要な場合、移行に関する計算はもはや理論上の話ではなくなります。.

SymphonyAIが委託したForresterのTotal Economic Impact調査によると、AIを活用したITSMを導入した組織は、3年間で204%のROI（投資対効果）を達成し、正味現在価値（NPV）は317万5000ドルに達した。この成果は主に、チケット処理の効率化と処理時間の短縮によるものであり、従来のプラットフォームではこれほどの規模で実現することは不可能だった。

数字は移民を正当化する根拠ではなく、移民の存在を裏付ける証拠に過ぎない。.

ITSM移行前に誰も対処しないAI対応の問題

これは、ほとんどの移行ガイドで省略されているセクションです。しかし、新しいプラットフォームでの最初の90日間が成功に終わるか、それとも混乱に陥るかを決定づけるセクションでもあります。.

AI搭載ITSMツールが学習に用いるデータ

新しいITSMインスタンスを起動すると、AIは組織について何も知らない状態で起動します。ベンダーが提供する基本モデルから始まり、お客様のデータに基づいてパーソナライズされます。このパーソナライズは、3つの入力要素によって実現されます。.

ほとんどのチームは、移行が完了するまで、こうした点について深く考えることはありません。 フォレスター社の「2025年版 AI主導型ITマネジメントの未来」レポートは、 この点を plain。データ品質とガバナンスがなければ、AIイニシアチブは高価な概念実証に終わり、拡張性は失われてしまいます。優れた成果を上げているチームは、必ずしもデータ量が最も多いチームではありません。彼らは、レコードを1件も移動する前に、モデルの学習に何を使用しているかを理解していたチームなのです。

フィルタリングされていない過去のチケットデータをインポートすると、AIの精度が低下する理由

5年分のチケットを一括インポートするということは、過去の不要なデータをすべて新しいプラットフォームに移行することを意味します。古い設定の不具合、スパム、テストデータ、そして「修正済み」とだけ書かれた手抜きな解決メモなど、あらゆるものが移行されます。AIがそれらすべてを処理します。.

「サービスを再起動する」ことでカテゴリ：ネットワークのチケットが解決されることを学習します。これは、2017年に誰かが50件のサーバーチケットをネットワークチケットとして誤って分類したにもかかわらず、誰もそれに気づかなかったためです。また、KB記事0047が問題解決に有効であることを学習します。これは、記事の内容が間違っていたため公開を取り消した後、誰もそれらのチケットを低品質としてフラグ付けしなかったためです。.

フィルタリングされていない過去のデータは、AIを賢くするわけではありません。むしろ、多額の費用をかけて導入したシステムにおいて、チームの最悪の習慣を大規模に学習させてしまうだけです。.

IBMのAIデータ品質に関する研究は 、そのメカニズムを裏付けています。つまり、不良データ、古いデータ、汚れたデータはすべて、予測可能な方法でモデルの精度を低下させます。モデルはデータが間違っていることを認識しません。ただ、存在するパターンを学習するだけです。AIは明示的に指示されたことだけを実行するのではなく、見たものから一般化するため、「ゴミを入力すればゴミが出力される」という原則は、ルールベースのシステムよりもAIに深刻に当てはまります。

解決策は、インポートするデータ量を減らすことではありません。適切なデータを、適切な順序で最初にインポートすることです。以下のチェックリストは、そのためのものです。.

ドキュメントの品質がAIのパフォーマンスを左右する理由

すべてのAI ITSMソリューションは、ナレッジベースを主要な検索レイヤーとして使用します。新しいチケットが到着すると、AIは記事の埋め込みを照会し、最も近い一致を表示します。これは、デモでご覧になったすべての推奨記事機能の背後にあるメカニズムです。一見すると素晴らしいように思えますが、結果の質はナレッジベースに実際に格納されている内容に依存することに気づけば、その印象は変わるでしょう。.

そして、ほとんどのナレッジベースはひどい状態だ。誰も削除しなかった古い記事、互いに矛盾する重複エントリ、2019年には意味があったもののそれ以降誰も手を加えていないカテゴリなどがある。.

SolarWinds 2025年レポートによると、生成型AIを使用しているチームと使用していないチームの間でパフォーマンスの差が拡大しており、その差はナレッジベース（KB）の品質と直接相関していることが明らかになった。AIによる問題解決速度で優位に立っているチームはドキュメントに投資しており、苦戦しているチームはそうではなかった。.

3つの具体的な問題が互いに悪影響を及ぼし合っている。.

• ナレッジベースが最も一般的なチケットカテゴリの40%をカバーしている場合、AIは残りの60%に対応できません。「わかりません」とは言わず、最も近い記事を表示しますが、その記事はたいてい間違っていて、担当者の時間を無駄にしてしまいます。.
• 古いコンテンツは、単なる空白よりもたちが悪い。18か月前に置き換えたVPNクライアントに関するナレッジベース記事を表示するAIは、単なる雑音ではない。それは自信満々な口調で注意をそらす行為であり、仕事をなくすどころか、かえって仕事を増やしてしまう。.
• 構造的な不整合は、誰にも気づかれずに検索精度を著しく低下させます。明確なタイトル、正確なカテゴリタグ、段階的な解決策を示すコンテンツを備えた記事は、高い精度で検索されます。曖昧な件名や構造化されていない文章は、埋め込みのマッチング精度を低下させます。AIに曖昧な情報を与えると、曖昧な結果しか返ってきません。.

ナレッジベース監査は、移行後のクリーンアップ作業ではありません。必須事項です。.

ITSMのAI対応移行チェックリスト

4つの段階があり、その順序は作業そのものと同じくらい重要です。.

フェーズ1：何かを移動する前に、実際に何を持っているかを確認する

移行前に未解決のチケットをすべてクローズし、問題を解決してください。.

未解決のチケットは、AI トレーニングのコンテキストでは重荷となります。解決データがないため、モデルに何も学習させることができません。多くの場合、カテゴリ分類スキーマと矛盾する未入力のフィールドが含まれています。また、エージェントが両方のシステムで並行して作業する場合、未解決のチケットは、誰も対応できない調整上の問題を引き起こします。30
日前に厳密な締め切り日を設定してください。処理中のすべてのチケットをトリアージします。エスカレーション、クローズ、またはリダイレクトします。締め切り日までに本当に解決できないものはすべて、未解決のアイテムとして移行し、AI トレーニング パイプラインから除外されるように明示的にタグ付けします。

KBの健全性チェックを厳密に実行してください。.

ナレッジベースの記事一覧をすべて取得してください。各記事について、次の5つの事項を確認する必要があります。最終レビュー日時、新しいプラットフォームがサポートするカテゴリに該当するかどうか、埋め込みリンクが正しく機能するかどうか、回答が矛盾する重複記事が存在するかどうか、そしてエージェントが実際に解決済みのチケットに記事を添付しているかどうかです。アクセス数の少ない記事は、認知度が低いか、正確性に欠けるかのどちらかです。どちらの問題も、記事を除外する理由となります。.

失敗したものはすべて、移行前に更新、統合、または廃止されます。不要なものを移行先に持ち込まず、AIにそこから学習させましょう。.

顧客満足度データについては正直に報告してください。.

3つの質問です。解決済みのチケットのうち、顧客満足度（CSAT）の回答が付いている割合はどのくらいですか？20%未満であれば、情報が少なすぎて役に立ちません。スコアはカテゴリ全体に分散していますか、それとも2つか3つの領域に集中していて、他のすべては評価されていませんか？また、特定のカテゴリで常に個人的なフォローアップを行うチームなど、体系的な偏りはありませんか？

顧客満足度（CSAT）データが疎であったり偏っていたりすることは既知の課題であり、致命的な問題ではありません。この点を文書化し、新しいプラットフォームのAIチームに報告してください。初期トレーニング期間中は、信頼度重み付けを異なる方法で適用する必要があるかもしれません。.

フェーズ2：AIにとって重要なデータを、正しい順序で最初に移動する

ナレッジベースの記事が優先されます。すべてのカテゴリ、すべての言語バージョンが対象です。.

ナレッジベースが充実していれば、AIは新しいシステムに最初に届いたチケットから関連コンテンツを表示できます。利用頻度の低いカテゴリや旧式のカテゴリも無視しないでください。AIはカテゴリ横断的なパターンを使用するため、廃止されたシステムに関する記事には、後継システムに直接引き継がれる解決ロジックが含まれている可能性があります。何が関連性があるかはモデルに判断させましょう。それがAIの役割です。.

複数の言語をサポートする場合は、すべてのバージョンを同時に移行してください。言語対応が不十分だと、AIはユーザー層によって異なるパフォーマンスを発揮します。このようなサービス品質のギャップは、システムが稼働した後では、想像以上に診断が困難です。.

解決済みのチケットを次に紹介します。最近のもので、顧客満足度が高く、タグ付けが完了しているもの。.

ここでは、AIの初期トレーニング基盤を構築しています。この段階では、量よりも質が重要です。過去18～24か月分のデータは、現在のサービスカタログと現在のチームの習慣を反映しています。古いデータは、もはや誰も利用していない廃止されたサービスを表すことが多くなります。CSATスコアが4または5のチケットを優先してください。これらは解決に成功した事例であり、モデルが最初に学習するのに望ましい肯定的な例です。完全なタグ付け（カテゴリ、サブカテゴリ、解決カテゴリ、担当者）が施されたチケットは、部分的にタグ付けされたチケットよりもレコードごとに強いシグナルを提供します。
完全な履歴アーカイブはフェーズ4で追加します。今は、AIが立つためのクリーンな基盤を提供している段階です。

連絡先は最後に残り、関連する連絡先のみが含まれます。.

ユーザーディレクトリ全体を一括移行しないでください。フェーズ2のチケットとナレッジベース記事に関連付けられているユーザーの連絡先レコードのみを取り込んでください。ディレクトリ全体には、元従業員、2022年に1つのプロジェクトに携わった契約社員、チケットを一度も開いたことのないユーザーなどが含まれています。これらをすべて取り込むと、レコードの検証を複雑にするエンティティノイズが発生します。フェーズ2のデータリンクが検証され、システムが実際のトラフィックを処理できるようになってから、連絡先の完全な移行に拡張してください。.

フェーズ3：ユーザーがAIと接する前に、AIの性能を実証する（目標達成率85%）

過去90日間に解決済みのチケットを200件取得します。これらは、新しいプラットフォームであるチケットではまだ確認されていないものです。各チケットの件名と説明を分類エンジンに入力します。分類エンジンが割り当てたカテゴリと優先度を、旧システムで実際にチケットに付与されていたカテゴリと優先度と比較します。.

ナレッジベース（KB）の提案精度についても同様のテストを実行してください。サンプルに含まれる各チケットについて、AIが提案した上位3つの記事の中に、エージェントが実際に解決に使用した記事が含まれているかどうかを確認してください。.

両方の指標で85%の精度を目指してください。旧プラットフォームを廃止したり、エージェントへのフルアクセスを許可したりする前に、異なるチケットサンプルで少なくとも3回連続してこの基準を維持してください。.

トリアージの精度が低い場合、根本原因はほぼ間違いなく、ソースデータの分類の不整合、または特定のカテゴリのデータ量の不足です。切り替え後ではなく、切り替え前に調査してください。ナレッジベース（KB）の提案精度が低い場合は、KBの網羅性または鮮度がボトルネックになっています。フェーズ1に戻ってください。.

スケジュールが遅れているからといって、この段階を急いではいけません。調整が不十分なAIをユーザーに提供してしまうと、2週間の遅延よりもはるかに大きな損失を被ることになります。.

フェーズ4：完全な歴史的移住：その他すべてを慎重に持ち込む

AIの精度検証に合格したら、他のすべてを移行します。この段階を推進する要因は2つあります。

コンプライアンス遵守が 背景にある。医療機関、金融サービス機関、政府機関は、チケット履歴、変更記録、承認チェーンを一定期間保存することを義務付けるデータ保持要件を設けている。これらの記録は、AIの学習価値に関係なく移行される。保存は必須であり、任意ではない。

エージェントのコンテキスト。 経験豊富なエンジニアは、AIによる情報検索だけを使うわけではありません。彼らは検索を行います。2年前に特定の資産で何が起こったかを調べたり、一連のチケットにわたって繰り返し発生するインシデントを追跡したりします。こうした組織的な記憶を取り除いてしまうと、あなたの優秀な人材は、彼らが何を知っているのかさえ知らない新しいシステムに取り残されてしまうでしょう。

この段階では、フェーズ2の品質フィルターより前のレコードにデータ品質フラグを適用します。ほとんどのプラットフォームでは、フラグが付けられたレコードをアクティブなAIトレーニングから除外しつつ、コンプライアンスや手動検索のために完全に検索可能な状態に保つことができます。これが理想的な構成です。つまり、完全な履歴が利用可能で、クリーンなデータでモデルをトレーニングできる状態です。.

強力なAI機能を備えたITSMプラットフォームの選び方

AI対応のITSMソリューションを探すのに、検索エンジンを使えば5分もかかりません。しかし、自社の企業アーキテクチャに最適なITSM向けAIソリューションを見極めるには、徹底的な検証が必要です。デモを見ればきっと感銘を受けるでしょう。いつもそうです。では、そのデモに惑わされず、本当に重要な質問をするにはどうすれば良いのでしょうか？.

AIデータ要件に関する質問事項

が公表している精度ベンチマークは、どの程度のトレーニングデータ量を前提としていますか？
どのベンダーもプレゼンテーション資料に印象的な数値を掲載していますが、それらの数値がどのようなデータ量に基づいて測定されたのかを尋ねてください。もしベンチマークが10万件の解決済みチケットを前提としているのに、貴社が1万2千件しか扱わないのであれば、最初の6か月間の状況について率直な話し合いが必要です。「当社のAIは90%のトリアージ精度を達成」という言葉は、どのデータに基づいて測定されたかによって意味が大きく異なります。

トレーニングデータが不足している場合はどうなるでしょうか？
優れたAI ITSMソリューションには、明確なフォールバック動作が備わっています。例えば、プライバシー制御機能を備えたクロステナントパターンライブラリや、信頼度の高い推奨事項を1つ提示するのではなく、複数の提案を表示する低信頼度モードなどです。実際のインターフェースで低信頼度モードがどのように表示されるかを確認してください。もし表示されていない場合は、重要な情報となります。

再学習の頻度はどのくらいですか？
週単位の再学習であれば、モデルはチームの分類習慣の変化に迅速に対応できます。月単位またはそれ以下の頻度では、モデルが修正する前に初期のミスが積み重なってしまいます。契約前に、どちらのプランを選ぶべきかをしっかり確認してください。

移行はAIモデルの継続性に影響しますか？
一部のベンダーはモデルの移植性を提供しています。これは、自社プラットフォームの別のインスタンスから事前学習済みモデルをインポートできる機能です。同じベンダーのエコシステム内で移行する場合は、既存のAIトレーニングを引き継げるかどうかを確認してください。これにより、コールドスタート期間を省略できます。

AI機能の評価：トリアージ、コパイロット、エージェント

ITSM AIのユースケースを評価する際、トリアージと分類は基本となる機能です。競合するプラットフォームはすべてこの機能を提供しています。ベンダーのデモデータだけで評価するのではなく、自社で解決済みのチケットのサンプルデータを使って概念実証（PoC）を実行してもらうよう依頼してください。それが、真の実情を示す唯一の指標です。.

エージェントコパイロットの機能は、想像以上に多様です。優れた実装では、各ナレッジベース提案の背後にある類似度スコアをエージェントに表示し、提案の根拠となる過去のチケットを具体的に示し、エージェントが提案を評価することでモデルが時間とともに改善されるようにします。plain能力もフィードバックループもないコパイロットは、コパイロットとは言えません。それは、読み込みスピナー付きの提案ボックスに過ぎません。.

エージェント型AI ITSMワークフローは、プラットフォームが真に分離される部分です。ベンダーが自律実行をサポートすると主張する各リクエストタイプについて、次の3つの点を確認してください。エスカレーションのトリガーとなるのは何か？システムは曖昧なリクエストをどのように処理するのか？完了した自律アクションの監査ログはどのようになるのか？

コンプライアンスチームはこれらの監査記録を必要とします。署名する前に、それらが存在していることを確認してください。 フォレスターの2025年IT管理レポート では、データリネージ、アクセス制御、評価指標がサービス運用における信頼の基盤であると述べています。これは哲学的な話ではありません。最初の自動処理でチケットが誤ってクローズされた後、監査チームが要求する内容なのです。

ITSM移行のタイムライン：想定される事項

誰も聞きたくない話だが、現実的で実行可能なタイムラインの方が、2か月後に破綻するような楽観的なタイムラインよりもましだ。.

レコードボリューム別の典型的なフェーズと期間

小規模環境（チケット数5万件未満、記事サイズ500KB未満）：

• フェーズ1 監査：2～3週間
• 第2段階の 選択的移行および 第3段階の AI検証：3～4週間
• フェーズ4の 完全移行：1～2週間

現実的な合計期間： 6～9週間

中規模市場環境（チケット数5万～50万件、記事数500～5,000KB）：

• フェーズ1 監査：3～6週間（ドキュメントの状態が悪い場合は、ナレッジベース監査だけで1ヶ月かかる場合もあります）
• 第2段階の 選択的移行および 第3段階の AI検証：4～6週間
• フェーズ4の 完全移行：2～4週間

現実的な合計期間： 12～16週間

エンタープライズ環境（50万件以上のチケット、複数言語版のナレッジベース、コンプライアンス上のデータ保持要件）：

• フェーズ1 監査：6～12週間
• 第2段階の 選択的移行および 第3段階の AI検証：6～10週間
• フェーズ4の 完全移行（並行実行期間を含む）：8～16週間

現実的な合計期間： 5～9ヶ月

これらの数値は、プロジェクト専用のリソースを前提としています。チームが通常の業務と並行して移行作業を行う場合は、各フェーズに40%～60%を追加してください。.

専門サービスが最適な選択肢となる場合

自分でできる移行作業もありますが、そうでないものもあり、自分でやろうとすると、毎日この作業を行っている専門家を雇うよりも費用がかさむ場合があります。.

次のような場合は、プロの移行サービス（移行先のベンダーまたはHelp Desk Migrationのような専門プロバイダーによるサービス）の利用を検討してください。

• あなたの記録的な販売枚数は20万枚を超えました
• お使いのソースプラットフォームは高度にカスタマイズされたスキーマを使用しており、標準のエクスポートスクリプトでは適切にマッピングできません。
• あなたは、データ転送自体に関する文書化された管理連鎖要件が定められた規制業界で事業を行っています。
• あなたのチームには、移行を主要な作業ストリームとして実行するためのリソースが不足しており、サイドプロジェクトとしてしか実行できません。
• 現在ご利用のプラットフォームのAPIドキュメントが不完全であるか、エクスポートエンドポイントにレート制限が適用されているため、お客様のデータ量ではスクリプト作成が現実的ではありません。

プロフェッショナルサービスは 、スピード以上のものを提供します。移行先のプラットフォームに特化した、テスト済みのフィールドマッピングライブラリ、移行先スキーマ要件に対する自動検証、そして移行中に問題が発生した場合に、稼働中のサポート体制を維持しながら迅速に対応できるロールバック手順など、様々なメリットがあります。

優れたITSM移行パートナーは、データ移行前にAI対応基準を適用します。具体的には、顧客満足度（CSAT）の低いレコードを特定したり、孤立したエンティティ関連付けを特定したり、選択的なインポートフィルタを推奨したりします。これらは、通常であればフェーズ1で手動で行う作業です。移行前にこれらの作業を完了しておくことで、切り替え後に問題を発見する事態を防ぐことができます。.

ITSMにおけるエージェント型AI：新たな標準規格とその移行への影響

これはもはやプレビュー版ではありません。ITSMにおけるエージェント型AIが一般提供開始となりました。そして、データ品質の基準を大幅に引き上げます。.

Agentic ITSMエージェントがデータ基盤に求めるもの

現在、多くの主要プラットフォームが、パスワードリセット、アクセス権限の付与、標準ソフトウェア要求、基本的なインシデントルーティングといった一般的な要求タイプに対応するエージェント機能を搭載しています。エージェント型ITSMエージェントは、これらの要求を人間の介入なしに受付から解決まで処理します。これがその謳い文句です。では、実際に必要なデータについて見ていきましょう。.

機能的なエージェント型ITSMと、単なる負債となるエージェントを分けるのは、その基盤となるデータです。Lansweeper Lansweeper 調査は 、この現実を大規模に証明しています。データ品質はエージェント型AIにとって最大の障壁であり、多くの企業が不安定なインフラストラクチャの上に高度な自動化を構築しようとしているため、拡張性の高い自律型ワークフローの展開がますます困難になっています。

正確なユーザーエンティティレコード。 ソフトウェアアクセスをプロビジョニングするエージェントは、ユーザーを検索し、所属部署と役割を確認し、ライセンスの可用性をチェックし、資産レコードを更新します。重複したレコード、古い部署割り当て、または欠落したユーザー属性は、エージェントの処理速度を低下させるだけでなく、プロビジョニングの誤りや、エラーメッセージなしでの失敗を引き起こします。監視していない状況では、どちらの結果も許容できません。

CMDBをクリーンに保ちましょう。 エージェントのインシデントワークフローでは、影響を受けるシステムを特定し、サービスの依存関係を理解し​​、適切なチームにルーティングするために、正確な構成アイテムレコードが必要です。30%もの古いデータがCMDBにある場合、CIの所有権フィールドが前回の再編成以降更新されていないため、エージェントは誤ったチームにルーティングしてしまう可能性があります。これはAIの問題ではなく、AIが忠実に実行しているデータの問題です。

解決パスを明確に定義する必要があります。 エージェントが処理するすべてのリクエストタイプには、従うべき明確なワークフローが必要です。暗黙の知識や暗黙的なプロセスではなく、新しいプラットフォームが実際に実行できる構造化されたワークフロー定義が必要です。プラットフォームはエージェントレイヤーを構成する前にこれらのパスを構築する必要があるため、移行はこれらのパスを形式化するための有効な強制機能となります。

信頼度較正データ。 エージェントはエスカレーションすべきタイミングを知る必要があります。その較正は、過去のエスカレーションパターン、つまりどのカテゴリで人的介入が行われたか、どのリクエストタイプで再オープン率が高かったか、どのような状況でエージェントがチケットを自動化から取り戻したかといった情報に基づいています。過去のデータにエスカレーション理由コードや再オープンパターンが含まれていない場合、エージェントは安全なしきい値を設定するために必要なシグナルを欠いてしまいます。その結果、すべてをエスカレーションするか、何もエスカレーションしないかのどちらかになり、どちらも役に立ちません。

エージェント層におけるデータの鮮度と系統が重要な理由

ルールベースの自動化は、追跡可能な形で失敗します。ルールが実行されるか、されないかのどちらかです。問題を見つけてルールを修正し、次に進みましょう。.

エージェント型AIの失敗の仕方は独特だ。エージェントは、保有するデータから最も可能性の高い解釈に基づいて行動する。データが古くなっている場合でも、エージェントはそれを検知して警告を発することはない。自信満々に処理を進め、アクションを完了させ、次の処理へと進む。誰かがそれに気づいた時には、既に被害は発生している。.

それを妨げるものが二つある。.

• 最新データ。 ソフトウェアアクセスをプロビジョニングするエージェントは、IDプロバイダーに問い合わせ、ライセンス数を確認し、資産 database 。これは、1回の自動処理で行われます。これらの情報源のいずれかが古い情報を返した場合、エージェントは誤ったアクセスをプロビジョニングしたり、ライセンス制限を見落としたり、既に存在しないシステムのレコードを更新したりする可能性があります。エージェントはそれを認識せず、処理を完了するだけです。
• 明確なデータ履歴。 自律型エージェントが人間のレビューなしにチケットをクローズした場合、最終的には何が起こったのか、そしてなぜ起こったのかを正確に把握する必要があります。エージェントはどのデータを照会したのか？どのような判断を下したのか？エスカレーションせずに処理を進めるために、どのしきい値をクリアしたのか？プラットフォームは、こうしたデータ履歴を自動的に生成し、コンプライアンスチームが必要とする情報を提供します。あらゆるミスを調査対象にしないプラットフォームです。

フォレスター社は している plain、データリネージとアクセス制御はガバナンス上の負担ではなく、真に信頼できるAIを導入するための必須条件であると

移行前に、アクティブ化を予定している各エージェントワークフローにどのデータソースが供給されているかをマッピングしてください。フェーズ3のテストに、それぞれのワークフローに対する検証チェックを組み込んでください。静的データでのテストには合格するものの、稼働中の古いCMDBにクエリを実行すると失敗するエージェントワークフローは、実際にテストされたものではなく、単にリハーサルされただけです。.

ITSMにおけるAIに関するよくある質問