ServiceNow + AI（Now Assist）：あまり語られない本当の話 みんなが

以下の記事の翻訳

---

ServiceNowでのAI活用について話していますが、ここでは比較的成熟した領域、例えばITSM（あるいはそうあるべき領域）を基に考えてみましょう。

しかし、ほとんど誰も触れない本質的なポイントがあります：

AIに構造化されたデータベースがなければ、ただの高価なチャットボットに過ぎない。

Now Assistは自分で知能を生み出すわけではありません。それはプロセス、特にITSM、CSM、HRSDなどを支えるテーブルに直接依存しています。

これらのテーブルが乱雑だったり、間違っていたり、空っぽだったりすると、AIは間違ったことを学びます。

そして、間違った回答を出します。

Now Assistが本当に学んでいる場所

Now Assistは主に以下のテーブルから学びます：

sys_user

ユーザーは誰か

VIPは誰か

エージェントは誰か

→ これが優先度、コンテキスト、回答に影響します。

sys_user_group

サポートグループ

→ AIはこれを使って自動的に適切な割り当てグループを提案します。

これがないと、誤った割り当てになります。

cmdb_ci

Configuration Items（構成項目）

→ ここに最大の価値がありますが、実際にしっかり整備している企業は非常に少ないです。

AIは以下を理解します：

・どのサーバーか

・どのアプリケーションか

・どのサービスが影響を受けたか

→ これにより、原因分析が大幅に高速化されます。

cmdb_ci_service と service_offering

これら2つのテーブルが心臓部です。

AIに対して以下を伝えます：

・どのビジネスサービスが影響を受けているか

これがないと、本当の影響度の把握ができません。

incident

解決済みインシデントの大きな学習源です。

AIは以下から学びます：

・インシデントの説明

・解決方法

・担当グループ

→ これにより以下が可能に：

・自動解決（Auto resolution）

・自動割り当て（Auto assignment）

・要約（Summarization）

kb_knowledge

Now Assistにとって非常に重要で、これも整備している企業は稀です。

ここに企業の知識が蓄積されます（SharePointやConfluenceなどとの統合も可能）。

AIはこれを使って：

・ユーザーへの回答

・解決策の提案

・インシデントの自動解決

知識ベースが弱ければ、AIも弱くなります。

sc_cat_item

カタログアイテムはユーザーの意図を構造化します。

AIはこれを使って：

・適切なリクエスト作成

・不要なインシデントの防止

企業が今犯している最大の間違い

多くの企業が、基本を整理・再構築する前に AIやハイパーオートメーションを導入しようとしています（多くの人がその価値を見ていないか、知らないため）：

サービス、オファリング、アイテム（内部・外部）

ユーザー、サプライヤー、パートナー、グループ

資産とCI（構成項目）

ナレッジ記事

これをやると必ず失敗し、非常に高くつきます。本当に注意してください！

正しい順番はこれ

まず：データを構造化する

次に：プロセスを構造化する

それから：AIを有効化する

逆は絶対にダメです。

Now Assistの本当の最大価値

チャットボットではありません。

本当の価値はこれです：

解決時間の30%削減

インシデント量の40%削減

ユーザー体験の向上

エージェントの生産性向上

しかし、これらはデータがクリーンで、準備され、ガバナンスされている場合にのみ実現します。

新しい現実

ServiceNowはもう単なるテクノロジースタックの1つではなくなりました。

AIを基盤とした意思決定プラットフォームになり得ます。

ただし、AIはあなたの運用成熟度の鏡に過ぎません。

運用が成熟していれば、AIは強力になります。

成熟していなければ、カオスをより早く露呈させるだけです。

まとめとして、考えてみてください

あなたの会社やクライアントは、ServiceNowでAIを使う準備ができていますか？

それとも、まだ基盤を整える段階ですか？

今こそ、データ、テーブル、プロセス、そして戦略、目標、クイックウィンを真剣に見直すタイミングではないでしょうか。

迅速に価値を生み出し、人々にデータの真の重要性を認識させるために。

AIはマネジメントを置き換えるものではありません。増幅するものです。