Interaction：問い合わせの入口を1件にまとめる
利用者からの連絡は、いろいろな経路で来ます。電話、チャット、メッセージ、ビデオ会議。それぞれ別の仕組みで受けると、「昨日の電話の件です」と言われたときに履歴が探せません。
ServiceNow の Interaction（interaction）は、この接触そのものを1件のレコードにします。インシデントを起票する前の段階、「まず話を聞いた」という記録です。今回は実際にレコードを作りながら、この仕組みがどう守られているかを確認します。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-26）。本番環境では設定が異なります。
標準では0件
まず件数を数えました。interaction は 0件 です。関連するテーブルも見ました。interaction_wrap_up_code・interaction_wrap_up_configuration・interaction_wrap_up_segment も、すべて0件でした。
インシデントやカタログ品目が最初から入っているのと対照的です。Interaction は「受けたら作る」ものなので、標準データがありません。
そこで、この記事のためにレコードを作ってみます。作る過程でいくつも壁にぶつかり、それがこの機能の設計を教えてくれました。
3つの軸で接触を分類する
Interaction は3つの軸を持ちます。
state（状態）は5つ。New / Work in Progress / On Hold / Closed Complete / Closed Abandoned。最後の Closed Abandoned は「相手が離脱した」を表す状態で、チャットで返事が途切れた場合などに使います。
type（種類）は4つ。Chat / Messaging / Phone / Video。どの手段で接触したかを記録します。
direction（方向）は2つ。Inbound / Outbound。相手から来たのか、こちらから掛けたのか。
この3つを掛け合わせると、「電話で、相手から、対応中」といった状況が1行で表せます。
1件目：電話の受付を作る
まず素直な1件を作りました。type は phone、direction は inbound、state は new。
作成に成功し、番号は IMS0000002 でした。番号の接頭辞が IMS になっています。
この段階では担当者が空です。電話を受けたが、まだ誰が対応するか決まっていない状態を表します。
2件目：ここで403に阻まれる
次に「チャットで、対応中」の1件を作ろうとしました。type は chat、state は work_in_progress。
結果は HTTP 403 です。返ってきたメッセージにはこう書かれていました。
Operation against file 'interaction' was aborted by Business Rule 'Prevent setting unassigned to WIP'
「担当者が決まっていないのに、対応中にはできない」というビジネスルールに止められました。
assigned_to に担当者を指定して作り直すと、今度は成功しました（IMS0000006）。
この挙動は理にかなっています。Work in Progress は「誰かが対応している」状態です。誰も割り当てられていないのに対応中と表示されたら、その問い合わせは宙に浮きます。
3件目：閉じた状態では作れない
3件目は「すでに解決済みの問い合わせ」を作ろうとしました。state を closed_complete にして作成します。
またも HTTP 403 でした。
Operation against file 'interaction' was aborted by Business Rule 'Verify Closed Date'
閉じた日時（closed_at）が無いから拒否された、と読めます。そこで closed_at を明示して再実行しました。
結果は同じく403です。作成時に閉じた状態を指定する経路は、そもそも塞がれていました。
閉じるには「進めて閉じる」
では既存のレコードを閉じるとどうなるか。IMS0000006（Work in Progress）に対して、state を closed_complete へ更新しました。
今度は 成功 です。しかも面白いことが起きました。closed_at に 2026-07-26 07:57:55 が自動で入っていたのです。こちらでは指定していません。
閉じた日時は、閉じる操作の結果として記録されるもの。人が入力する項目ではない、という設計でした。
3つの試行を並べると、Interaction の状態は「順に進める」ことが前提になっていると分かります。いきなり終わった状態を作ることはできません。
20本のビジネスルールが状態を守っている
なぜこうも細かく止められるのか。sys_script を interaction で絞ると、有効なビジネスルールが 20本 ありました。
名前を並べると、これがそのまま状態機械の仕様書になっています。
Set Closed Time on Close（order 50, before）… 閉じたら closed_at を入れる
Verify Closed Date（order 60, before）… 閉じた日時を検証する
Set newly assigned interaction to WIP（order 99, before）… 担当者を割り当てたら対応中へ進める
Prevent setting unassigned to WIP（order 100, before）… 担当者なしの対応中を止める
Prevent re-opening closed interactions（order 100, before）… 閉じたものを開き直させない
Prevent Invalid State Change in Wrap Up（order 100, before）… ラップアップ中の不正な遷移を止める
Set "State changed on" if state changes（order 150, before）… 状態が変わった時刻を残す
実測で受けた403は、このうち2本によるものでした。そして closed_at が自動で入ったのは Set Closed Time on Close の働きです。原因と結果がきれいに対応しています。
order の並びに意味がある
order を見ると、実行の順番が設計されているのが分かります。
50 で closed_at を入れ、60 でそれを検証する。この順番だからこそ、閉じる操作では日時が自動で入り、検証も通ります。逆に新規作成でいきなり閉じた状態にすると、50 の条件（閉じる操作）に当てはまらないため日時が入らず、60 の検証で弾かれる。
99 で「割り当てたら WIP へ」、100 で「割り当てなしの WIP は拒否」。99 が先に走るので、割り当てと同時に WIP へ進む経路は通ります。100 だけを見ると矛盾しそうな2本が、order で共存しています。
状態遷移を図にする
通れる道と通れない道を並べると、設計の意図がはっきりします。
New から Work in Progress へは、担当者の割り当てで進みます。担当者なしでは進めません。Work in Progress からは On Hold へ行き来でき、Closed Complete か Closed Abandoned で終わります。そして閉じたら戻れません。
この一方通行の作りは、Incident や Problem の状態モデルと同じ考え方です。記録として残すものは、後から書き換えにくくしておく。
Interaction とインシデントの違い
Interaction は「接触の記録」で、インシデントは「対応すべき事象の記録」です。
電話がかかってきたが、話を聞いたら操作方法の質問だった。この場合、インシデントを作る必要はありません。Interaction だけを残して閉じます。
いっぽう「メールが送れない」という相談なら、Interaction から Incident を起票します。Interaction には context_table と context_document というフィールドがあり、そこから作った先のレコードを指せる作りでした。
接触は必ず1件残し、必要なものだけ次の記録へ繋ぐ。これが Interaction を挟む理由です。件数を数えれば「何件受けて、そのうち何件が起票に至ったか」が分かります。
この比率は、サービスデスクの実力を測る数字になります。起票に至らず終わった問い合わせが多いほど、一次解決できている。逆に受けた分だけインシデントが増えているなら、その場で答えられていないということです。
Interaction を挟まずインシデントだけを起票していると、この比率が測れません。「操作方法を聞かれただけ」の連絡までインシデントにすると、件数は膨らむのに障害の実態は見えなくなります。かといって記録に残さなければ、対応した事実そのものが消えます。
もうひとつの効き目が、同じ人からの連絡をまとめて見られることです。1週間に5回電話してきた利用者がいれば、その5件が Interaction として並びます。個別のインシデントを追うだけでは気づけない状況が、接触の記録からは見えてきます。
親子で会話をつなげる
parent フィールドは interaction 自身を参照します。1つの会話が別の会話に引き継がれたとき、その関係を残せる作りです。
一次受付が話を聞き、専門チームへ転送する。転送先で新しい Interaction が起票され、その parent に元の1件を指す。こうしておけば、利用者から見れば1つの相談でも、内部では2件の対応記録として残ります。
電話の転送やチャットのエスカレーションは、日常的に起きます。それを1件のレコードに詰め込むと、担当者ごとの対応時間が測れません。分けて親子で結ぶほうが、後から分析できます。
保留の理由も持てる
state_reason という choice 型のフィールドがありました。状態が On Hold のとき、なぜ止まっているのかを記録する項目です。
「利用者の折り返し待ち」「部材の到着待ち」「他部署の回答待ち」。理由を分けて記録しておけば、保留の総数だけでなく「何が原因で止まっているか」が集計できます。
hold_duration という保留時間の項目もあります。対応時間（duration）とは別に、待っていた時間を持つ設計です。SLAを測るとき、こちらの都合で止まっていた時間と相手待ちの時間は分けたい。そのための項目と読めます。
ラップアップは0件だった
interaction_wrap_up_code（ラップアップコード）は0件でした。ラップアップは、対応が終わった直後に「何の用件だったか」を分類する仕組みです。
ビジネスルールには Create wrap_up segment と Close wrap_up segment があり、区間を記録する作りが用意されています。Interaction Wrap Up Timeout というルールもあり、分類を入れずに放置すると自動で締められるようです。
ただしコードも設定も0件なので、この PDI では動きを確認できませんでした。使うなら、まず分類コードを自分で作るところから始まります。
会話の中身も持てる
フィールドを眺めると、会話そのものを保存する項目がいくつもありました。
transcript … 会話の記録
internal_transcript … 内部向けの記録
chat_summary … 会話の要約
recording_url … 録音の場所
caller_phone_number … 発信者番号
分析用の項目もあります。sentiment（感情スコア）、csat_score（満足度）、auto_resolution（自動解決したか）、help_requested（応援を呼んだか）。
チャットボットや電話システムと繋いだときに、これらが自動で埋まる想定と読めます。手で起票する使い方では、多くが空のままになります。
channel_metadata_table と channel_metadata_document という組も目を引きました。接触してきた経路ごとの詳細情報を、別テーブルの1行として指す作りです。電話なら通話記録、チャットならセッション情報。経路が増えても Interaction 本体の列を増やさずに済みます。
同じ発想が context_table と context_document にもあります。参照先のテーブルを固定せず、テーブル名とレコードIDのペアで持つ。この形は ServiceNow のあちこちで使われていて、汎用の入れ物を作るときの定番になっています。
provider_application と channel_user_profile も外部連携用です。どのアプリ経由で来たか、その経路上の利用者IDは何か。社内の sys_user と、外部サービス上のアカウントを結びつけるための項目でした。
実務で気をつけるところ
状態は必ず順に進める
実測のとおり、いきなり閉じた状態のレコードは作れません。データ移行で過去の問い合わせを取り込むとき、この制約が効いてきます。
移行時はビジネスルールを一時的に無効にするか、作成してから更新で閉じる2段階にする必要があります。1回のインポートで完了状態にしようとすると、全件が403で弾かれます。
担当者と状態はセットで動く
「割り当てたら対応中へ進む」ルールがあるので、担当者を入れた時点で state が変わります。逆に担当者を外すと、Interaction - On Un-assigned というルールが動きます。
state を直接操作する処理を書くときは、これらのルールと衝突しないか確認が要ります。
番号は飛ぶ
実測では IMS0000002 の次が IMS0000006 でした。作成に失敗した回でも番号が消費されるためです。
番号が連番であることを前提にした処理は書かないほうが安全です。抜けがあっても異常ではありません。
エラーの本文を読む習慣をつける
今回の403は、どれも原因のビジネスルール名を返してきました。「Prevent setting unassigned to WIP」と書いてあれば、何が足りないかは名前だけで分かります。
ServiceNow の403は、単なる権限エラーではないことが多いのが実情です。ビジネスルールの abortAction によるものなら、必ずルール名が入ります。エラーが出たら、まず本文を最後まで読む。それだけで調査の半分は終わります。
逆に、自分でビジネスルールを書くときも同じです。止めるだけで理由を返さないルールは、後から使う人を困らせます。ルール名を分かりやすくしておくのが、いちばん簡単な親切です。
0件から始める前提で設計する
標準データが無いので、Interaction を使い始めるときは分類の設計から必要です。カテゴリ、ラップアップコード、どの type を使うか。これらを決めずに運用を始めると、後から集計できないデータが溜まります。
どこから触るか
/interaction_list.do … Interaction の一覧
/interaction.do?sys_id=... … 1件のフォーム
/sys_script_list.do?sysparm_query=collection=interaction^active=true … 効いているビジネスルール20本
/interaction_wrap_up_code_list.do … ラップアップコード
/sys_choice_list.do?sysparm_query=name=interaction^element=state … 状態の選択肢
ビジネスルールの一覧は、order 順に並べると読みやすくなります。何が先に走るかで、挙動の理由が説明できます。
まとめ
Interaction は、接触そのものを1件として残すテーブルでした。
状態は5つ、種類は4つ、方向は2つ。標準データは0件で、使うなら自分で作り始めます。実際に作ってみると、担当者なしの対応中と、いきなり閉じた状態の2つが403で拒否されました。
その理由は、有効な20本のビジネスルールにありました。名前を読むだけで、どういう順番で状態が進むべきかが分かります。閉じた日時は自動で入り、閉じたものは開き直せません。
ラップアップは0件で未検証のままですが、区間を記録する仕組みは用意されています。分類コードを決めるところから始める機能でした。
用語
Interaction（interaction） … 利用者との接触そのものを表す1件の記録
state … New / Work in Progress / On Hold / Closed Complete / Closed Abandoned
type … Chat / Messaging / Phone / Video
direction … Inbound（相手から）/ Outbound（こちらから）
ラップアップ … 対応直後に用件を分類する仕組み。コードと区間を持つ
context_table / context_document … この接触から作った先のレコードを指す
自分の環境で確認するときのURL
/interaction_list.do?sysparm_query=ORDERBYnumber（作成した2件）
/interaction.do?sys_id=...（New 状態 / Closed Complete 状態のフォーム）
/sys_script_list.do?sysparm_query=collection=interaction^active=true^ORDERBYorder（ビジネスルール20本）
/interaction_wrap_up_code_list.do（ラップアップコード・0件）
実測の要点（再掲）
interaction は標準0件。ラップアップ系3テーブルも0件
state は5つ、type は4つ、direction は2つ
担当者なしで Work in Progress を作ると 403（Prevent setting unassigned to WIP）
最初から Closed Complete で作ると 403（Verify Closed Date）。closed_at を書いても同じ
既存レコードを更新して閉じると成功し、closed_at が自動で入る（Set Closed Time on Close）
有効なビジネスルールは 20本。order 50 → 60 → 99 → 100 → 150 → 200 の順で走る
番号は IMS で始まり、作成に失敗した回のぶんが飛ぶ（IMS0000002 の次が IMS0000006）
検証範囲とおことわり
件数・選択肢・挙動は PDI（Zurich / OOTB）の実測です。本番環境の設定とは異なります。
この記事のために interaction を2件作成し、1件を閉じました。デモ用のレコードです。
ラップアップは0件のため未検証です。ビジネスルールの存在だけを確認しました。
Virtual Agent やチャットからの自動起票は行っていません。REST での作成のみです。
各ビジネスルールのスクリプト本文は読んでいません。名前・order・when と、実際に返ってきたエラーからの読み取りです。
