ITSMの音声AIエージェント(AI Phone Agent):OOTBの定義の確認
検証環境:Now Assist デモ環境(Australia Patch 5)/ 2026-10-02 確認
電話で「パスワードを忘れた」と伝えると、AI がリセットのリンクを SMS で送る。「インシデントを作りたい」と伝えると、AI が起票まで進める。ITSM の標準には、そう動く音声 AI エージェントが6件入っています。今回のデモ環境(日本語表示)で定義を確かめたところ、6件の構成はすべて無効でした。ツールの割り当て18件は、すべて実行モードが自律です。この記事は定義の確認までで、電話は1本もかけていません。
定義の確認でわかったこと
ITSM の音声 AI エージェントは6件。エージェント型ワークフローは0件で、単体のエージェントとして入っている
6件の構成(sn_aia_agent_config)はすべて無効。有効化には、エージェントの有効化に加えて、電話の受け口になる音声アシスタントが要る
ツールの割り当ては18件(実体は16件)で、すべて自律。インシデント作成、申請の発行、コメント追加、緊急度の引き上げも承認なしで実行する定義
メールと SMS でリンクを送るツールが5件ある
この環境では、音声の認証で多要素を必須にするプロパティが false。単一要素でも通る設定になっている
試行は定義の確認に限ります。AI Agent Studio の定義にあたるテーブルと、システムプロパティを読み取り専用で取得しました。電話の発信と、ITSM の音声エージェントの設定の変更は0件です。製品全体の評価ではなく、有効化の前に確かめる観点を洗い出すケーススタディです。
ITSMの音声AIエージェントの一覧
ITSM の音声 AI エージェントは、パッケージ「IT Service Management AI voice agent collection」(スコープ sn_itsm_voice_aia)に6件入っています。種別(agent_type)は AI Phone Agent です。公式ドキュメントでは、AI voice agents を「電話の支援業務で自然な会話をさせる生成 AI のエージェント」と説明しています。

表の内容を文字でも書き出します。
Password reset with voice AI agent(音声によるパスワードリセット AI エージェント):パスワードリセットの要望を受け、リンクをメールか SMS で送る。ツール3件、すべて自律
Request catalog item with voice AI agent(音声によるカタログアイテム依頼 AI エージェント):カタログアイテムを探し、ソフトウェア以外はリンクを送り、ソフトウェアは注文を作る。ツール7件、すべて自律
Submit account unlock catalog with voice AI agent(音声によるアカウントロック解除カタログ申請 AI エージェント):アカウントロック解除の申請を出す。ツール1件、自律
Troubleshoot outlook issue with voice AI agent(音声による Outlook 問題のトラブルシューティング AI エージェント):Outlook のナレッジを検索して案内し、求められればメールで記事を送る。ツール2件、すべて自律
Create incident with voice AI agent(音声 AI エージェントでインシデントを作成):発信者の問題からインシデントを1件作る。ツール1件、自律
Manage ticket with voice AI agent(音声 AI エージェントでチケットを管理):自分の有効なチケットの照会、コメント追加、緊急度の引き上げ。ツール4件、すべて自律
日本語名は、画面に表示される名前です。最後の2件だけは、エージェント自体の名前が日本語で登録されていました。ほかの4件は、日本語表示の画面に出る訳を使っています。
ITSM 以外にも、電話エージェントは入っています。標準と判定できた12件を、提供元別に並べます。

表の内容を文字でも書き出します。
HR Voice AI Agents:8件、構成が有効なのは6件。例は HR case creator voice agent、Time off request voice AI agent。Employee Details Updater と Retrieve worker profile は無効
CSM(顧客サービス):3件、すべて有効。Create Case Voice Agent、Update Case Voice Agent、Case Status Voice Agent
注文運用管理:1件、有効。Order Exception Voice AI Agent
ITSM 6件とこの12件を合わせて18件で、標準の電話エージェントの総数と一致します。sys_id を指定して読めた電話エージェントは22件ありました。残る4件は標準の一覧に含まれないため、数えていません。標準かどうかの判定は、過去記事と同じ基準(パッケージとスコープ、デモでの追加分と判定保留の除外)です。
起動のきっかけから結果までの流れは、次の図のとおりです。電話の受け口にあたる部分は、今回確かめていません。

起点は電話の発信者の発話、緑はナレッジの検索と案内、橙はメール・SMS の送信、赤は承認なしでのレコードの作成・更新、灰色の点線は今回確認していない経路
灰色の点線にあたる電話事業者の接続・音声アシスタント・発信者の認証は、この環境では読んでいません。
図の内容を文字でも書き出します。
起点は電話の発信者の発話。電話事業者の接続、音声アシスタント、発信者の認証は今回確認していない
ナレッジの検索と案内:Troubleshoot outlook issue と Password reset
リンク・記事をメールか SMS で送信:Troubleshoot outlook issue、Password reset、Request catalog item
承認なしでインシデント・申請・コメント・緊急度を作成・更新:Request catalog item、Submit account unlock catalog、Create incident、Manage ticket
AI Agent「Create incident with voice AI agent」の定義確認
発信者が新しい問題を伝えたときに、インシデントを1件作るエージェントです。ツールは Create incident flow action の1件で、種類はフローアクション、実行モードは自律です。
次の画像は、定義画面(日本語表示では「音声 AI エージェントでインシデントを作成」)のツール欄です。①がエージェント名、②がツール名、③が実行モードです。

ツールの説明には、入力の対応が書かれています。短い説明には発信者が述べた問題を1文で入れ、緊急度は申告があればそれを使う。申告がなければ重大度から推測し、情報が足りなければ低(3)にする。緊急度は尋ねない指示です。通話ごとの会話 ID も入力に含まれます。
エージェントの指示には、次の3点があります。
既存のインシデントを検索しない
トラブルシューティングをしない
作成の直前に要約を1回だけ行う
公式ドキュメントの手順も同じ流れで、追加の質問は最大3つ、一度に1つです。
AI Agent「Manage ticket with voice AI agent」の定義確認
自分の有効なチケット(インシデントと申請アイテム)を照会し、コメントを足し、緊急度を上げるエージェントです。ツールは4件で、すべて自律です。
Get all active tickets:発信者に紐づく有効なチケットの一覧を取る
Get ticket details via number:番号を決めたあと詳細を取る。コメントは古い順に読み上げ、5件を超えると要約する指示がある
Add comment to ticket:利用者に見えるコメントを追加する。番号とコメント文を発信者に確認し、クローズ済みやキャンセル済みには追加しない指示
Escalate ticket:緊急度を引き上げる。下げる、または高(1)を超える変更はしない指示
書き込みのツールが2件あります。指示文の上では確認を求めていますが、実行モードは自律で、承認の画面で止まる定義ではありません。
AI Agent「Request catalog item with voice AI agent」の定義確認
カタログアイテムを探して届けるエージェントです。ソフトウェア以外は、リンクをメールか SMS で送ります。ソフトウェアは、変数を集めて注文を作ります。ツールは7件で、すべて自律です。
探す・集める:Get relevant Catalog Items(検索取得)、Gather catalog item variables(フローアクション)
送る:Send catalog link to email、Send catalog link to SMS(サブフロー)
注文を作る:Modify catalog item(注文中の変数の修正)、Create catalog item order(REQ と RITM を作成)
補助:Assist with catalog request form(リンク送信の直後に入力を手伝う)
エージェントの役割文には、カタログアイテム自体は作成・変更・削除しないとあります。これはカタログの定義を指す文で、注文の作成は別です。Create catalog item order の説明は、REQ と RITM を作り、現在の通話のインタラクションに関連づける内容でした。
AI Agent「Submit account unlock catalog with voice AI agent」の定義確認
ツールは Submit Account Unlock Catalog Order の1件だけで、アカウントロック解除のカタログ申請を出します。説明文は「アカウントロック解除の申請を出す」の1文です。エージェントの説明は、発信者がアカウントロック解除を明示したときに使うとしています。
公式ドキュメントの手順は、対象のアカウント名を確かめ、発信者と一緒に確認してから申請する流れです。ツール側には、対象を確かめる処理の記述はありません。確認は、エージェントの指示に頼る形です。
AI Agent「Password reset with voice AI agent」の定義確認
パスワードリセットの要望を受け、リンクをメールか SMS で送るエージェントです。ツールは3件で、すべて自律です。
Get relevant knowledge articles:ナレッジを検索する
Send password reset link to email、Send password reset link to SMS:リンクを送る
ツール欄では、ナレッジ検索の Get relevant knowledge articles と、メールと SMS でリンクを送る2つのサブフローが並びます。3つとも自律です。

エージェントの役割文は、パスワードを直接リセットせず、資格情報も変更せず、承認された経路(メール・SMS)だけで動くと書いています。公式ドキュメントには、リンクを声で読み上げる方法も載っています。この環境の割り当てには、読み上げ専用のツールはありません。
AI Agent「Troubleshoot outlook issue with voice AI agent」の定義確認
Outlook の問題だけを扱うエージェントです。ツールは search outlook KB articles(検索取得)と Send outlook troubleshooting email(サブフロー)の2件で、どちらも自律です。
指示には、次の3点があります。
質問や手順を読んだら、必ず発信者の返事を待つ
メールは、求められたときだけ提案する
通話は短くする
メール送信は、発信者の問題の説明を一字一句そのまま渡す入力になっています。
書き込みと送信を伴うツールの一覧
6件のエージェントのうち、記録を書き込むツールと、メールや SMS を送るツールを並べると次のとおりです。

表の内容を文字でも書き出します。
Create incident(Create incident flow action):発信者の問題を1文にして、インシデントを1件作る
Request catalog item(Create catalog item order):ソフトウェアの注文を出し、REQ と RITM を作る
Submit account unlock catalog(Submit Account Unlock Catalog Order):アカウントロック解除の申請を出す
Manage ticket(Add comment to ticket):利用者に見えるコメントを自分のチケットに追加する
Manage ticket(Escalate ticket):自分のチケットの緊急度を引き上げる
Password reset ほか3件(リンク・記事の送信、5件):発信者へメールか SMS で送る
起動の前提は、プラグイン・音声アシスタント・認証の3つ
公式ドキュメントによると、ITSM の音声 AI エージェントを使うには、次の3つを順にそろえます。
プラグイン:ITSM の音声エージェントは「IT Service Management AI voice agent collection」(sn_itsm_voice_aia)で入る。基盤は ServiceNow Otto for Platform(sn_genai_platform)に含まれる Voice Agents のアプリ。インストールには sn_aia_admin のロールが要る
音声アシスタント:Assistant Designer で「音声のみ」のアシスタントを作り、その中に AI voice agent を載せる。電話事業者の接続はここで選ぶ。対応は Twilio、Genesys、Amazon Connect、3CLogic、Five9、NICE CXone、カスタムの SIP と、モバイル向けの WebRTC。作成には virtual_agent_admin か admin のロールが要る
発信者の認証:発信者を特定する識別と、本人確認の認証を設定する。使える要素は Soft PIN、TOTP、SMS OTP、メール OTP、Okta Verify のプッシュ、KBA

起点は電話、青は公式の3つの前提、橙はこの環境で有効になっていない段、緑は動き出す機能
図の内容を文字でも書き出します。
① プラグイン:IT Service Management AI voice agent collection(sn_itsm_voice_aia)。基盤は ServiceNow Otto for Platform の Voice Agents。インストールに sn_aia_admin が要る
② 音声アシスタント:Assistant Designer で「音声のみ」を作り、AI voice agent を載せる。電話事業者の接続はここで選ぶ
③ 発信者の認証:識別と本人確認。Soft PIN・TOTP・SMS OTP・メール OTP・Okta Verify・KBA が使える
構成の有効化:Define availability 画面で Status を有効にする。ITSM の6件はこの環境ではすべて無効
動き出すのは音声 AI エージェント(ITSM 6件)。ナレッジ検索・メールや SMS の送信・記録の作成と更新を行う
この環境で読めた前提の設定
3つの前提のうち、この環境で読めた範囲は次のとおりです。
プラグイン「sn-common-voice-ui」と「Notify - Twilio Direct Driver」は有効。Twilio Direct Driver の説明には、Twilio との別契約が必要とある。音声アシスタントの作成状況と電話事業者の接続は読んでいない
音声エージェント向けのロールは sn_voice_aia.admin、sn_voice_aia.guest、sn_voice_aia.integration、sn_hr_voice_aia.admin が存在する
プロパティ glide.voice.authenticate.mfa_mandatory は false。説明には「デフォルト = true:MFA は必須」とある。値の更新者は admin で、出荷時の値かは区別できなかった
プロパティ glide.voice.authenticate.allow_kba_as_only_factor は false。true にすると、安全性の低い KBA だけで認証できるようになる。説明は、false のままにする推奨を書いている
プロパティ sn_voice_aia.usage_threshold_in_seconds は30。音声エージェントの通話が課金の対象になるまでの秒数を決める
公式ドキュメントによると、各エージェントを使えるロールは snc_internal です。データへのアクセスのロールは、Password reset が public、ほかの5件が nobody です。この値は公式ドキュメントの記載で、実機のレコードでは確かめていません。
有効にする前に決めることは、機能の種類ごとに違う
ここからは、試していない部分を含む筆者の推奨案です。判断の軸は、機能の種類ごとに、電話の受け口・本人確認・書き込みの範囲に置きます。種類は次の3つです。
案内とリンク送信だけをする機能:例は Troubleshoot outlook issue と Password reset。決めること=送信元と宛先のメール・SMS の設定、案内の元になるナレッジ
記録を作る機能:例は Create incident と Submit account unlock catalog。決めること=誰として起票するか、緊急度の扱い、申請の承認
既存のチケットを照会・更新する機能:例は Manage ticket。決めること=本人確認の強さ、コメントを足す範囲、緊急度を上げられる範囲
案内とリンクを送る機能は、送信の経路と宛先を決める
パスワードのリセットリンクは、送り先を間違えるとアカウントの乗っ取りにつながります。Password reset のツールは、メールか SMS の宛先を発信者の申告から受け取る作りかを、今回は確かめていません。登録済みの連絡先だけに送る設定を候補にします。ただし試しておらず、そうなるかは未確認です。
記録を作る機能は、本人確認と起票者を決める
Create incident は、発信者の問題を1文で入れ、緊急度を推測して起票します。誰からの電話かを確かめないまま起票すると、起票者の欄の扱いが決まりません。まず、発信者の識別と認証の強さを決めます。この環境の mfa_mandatory は false なので、単一要素でも通る設定です。MFA を必須に戻すことを候補にします。戻したあとの動きは確かめていません。
チケットを照会・更新する機能は、認証の強さを一段上げる
Manage ticket は、自分の有効なチケットを読み、利用者に見えるコメントを足し、緊急度を上げる機能です。チケットの内容が電話で読み上げられるので、KBA だけの認証では不足と考えます。公式ドキュメントも、KBA を単独の要素にして機密性の高い操作へ使うのは避けるよう勧めています。
通話の録音と個人情報は、有効にする前に法務と確認する
公式ドキュメントの Deploy AI voice agents には、録音の同意や通信傍受の法令を守っていることを利用者が確認する、という趣旨の注意があります。データについても、インスタンスから ServiceNow の集中環境へ転送され、第三者のクラウドを経由する場合がある、と書かれています。電話の音声と文字起こしが、どこにどれだけ残るかは今回確かめていません。有効にする前に、録音の扱いと個人情報の保存先を決めます。
導入前の確認リスト
案内とリンクを送る機能
□ 送信元と宛先(メール・SMS)の設定を確認した
□ リセットリンクの送り先を、登録済みの連絡先に限るか決めた
記録を作る機能
□ 発信者の識別と認証の要素を決めた
□ 起票者の扱いと緊急度の既定を決めた
チケットを照会・更新する機能
□ 認証の強さ(MFA の必須)を決めた
□ コメント追加と緊急度の引き上げを任せるか決めた
共通
□ 電話事業者と音声アシスタントの設定を確認した
□ 録音と個人情報の扱いを法務と確認した
実機で気づいたこと
構成はすべて無効で、有効化は2段階になる
ITSM の6件はすべて構成が無効でした。公式ドキュメントも、有効化には「Define availability」画面で Status を有効にすると書いています。さらに電話の受け口がなければ呼び出されません。ITSM の標準に音声のエージェントが入っていても、有効にする操作は別に必要です。
承認で止まるツールは、18件中0件だった
ワークフロー型のエージェントと違い、音声の6件は単体のエージェントで、ツールの割り当て18件はすべて自律です。電話の会話では、承認の画面で止める手段が取りにくい点は想像できます。ただし根拠は定義だけです。コメント追加や緊急度の引き上げを実行前に止めたいなら、実行モードを切り替えられるかを、検証用の環境で確かめます。
パスワードリセットのエージェントは、ロール欄でリセットリンクの送信を担う役割を定めています。パスワードの直接のリセットは、対象外とする内容です。

公式ドキュメントと実機の構成が、少し違っていた
公式ドキュメントの Password reset は、アプリケーションを検索して確認する手順で、リンクの読み上げも挙げています。実機の割り当ては、ナレッジの検索と、メール・SMS の送信の3件でした。ドキュメントの版と実機の版が違うのか、別のツールを使うのかは確かめていません。有効化する前に、実機の定義とドキュメントを突き合わせます。
用語
AI Phone Agent:電話の会話で動く AI エージェントの種別。音声アシスタントに載せて使う
音声アシスタント:電話事業者と AI voice agent をつなぐ受け口。Assistant Designer で作る
実行モード:ツールごとの設定。自律はそのまま実行し、監視中は実行前に人の承認で止まる
付録:自分の環境で確認するときのURL
エージェント:/sn_aia_agent_list.do?sysparm_query=agent_type=ai_phone_agent(種別の内部値は環境で確認してください)
エージェントの構成(有効状態):/sn_aia_agent_config_list.do
ツールの割り当て(実行モード):/sn_aia_agent_tool_m2m_list.do
認証のプロパティ:/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.voice.authenticate
音声エージェントのロール:/sys_user_role_list.do?sysparm_query=nameSTARTSWITHsn_voice_aia
公式ドキュメント(ServiceNow Docs):
検証範囲とおことわり
2026-10-02に、Australia(Patch 5)のNow Assistデモ環境で、日本語表示のみ確認しました。取得したのは、エージェント・エージェント構成・ツールの割り当てとツール・プラグイン・ロール・システムプロパティで、すべて読み取り専用です。一部のテーブルは行レベルのアクセス制御で一覧が返らないことがあり、ITSM の6件と他の電話エージェントは sys_id を指定して1件ずつ読みました。記事のタイトルにある「OOTBの定義の確認」は、定義の確認を指し、通話した結果に基づく利用可否の判定は含みません。
電話の発信は0件です。検証用に音声アシスタントを1件作成して Manage ticket を割り当てたあと削除しており、ITSM の音声エージェントの構成は変更していません。通話テストは、この環境では完了していません。
未確認のこと:
電話事業者の接続(未設定のまま)と、通話が成立する条件
発信者の識別・認証の実際の設定
実際の通話での動き、音声の品質、録音と文字起こしの保存先
ツールの実行モードを切り替えたときの動き
公式ドキュメントのロール(snc_internal など)が実機のレコードと一致するか
英語表示での画面