ServiceNowの問い合わせはいつチケットにする？ InteractionからIncidentへ上げる流れを実機で追う
電話やチャットで受けた相談を、いつIncidentに引き上げるべきか迷ったことはないでしょうか。ServiceNowにはInteractionという受付記録があります。そこからIncidentへ変える操作がどこにあるのか、変えた後に何が起きるのかは公式Docsだけでは掴みにくいところです。Zurich PDIで実際にInteractionを1件作り、Service Operations WorkspaceのCreate incidentボタンを押してIncidentへ転換しました。転換の裏で作られる中間テーブルまで、実際の画面を追って確認しています。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：転換はボタン1つ、記録は2か所に残る
転換の入口はService Operations Workspaceの「Create incident」ボタン1つです。従来UIのInteractionフォームには出てきません。
ボタンを押すとIncidentが実際に作成され、interaction_related_recordという中間テーブルに1行できます。同時にIncident側にもorigin_table・origin_idという形で元のInteractionが残ります。片方向ではなく両方向から辿れる作りでした。
元のInteractionは自動では閉じません。 担当者が手動でCompleteを押すまでWork in Progressのまま残ります。自動で閉じる設定も用意されていましたが、このPDIでは無効になっていました。
Interactionのままにするか、Incidentへ上げるか
判断の軸は単純です。その場で答えが返せるか、それとも調査や復旧の作業が発生するか。
パスワードの再設定手順を案内するだけなら、電話を切った時点で用件は終わっています。ノートPCの画面がフリーズして操作できないという相談は、原因を調べて手を動かす作業が続きます。前者はInteraction 1件で完結させ、後者はIncidentへ引き上げる。この線引きが、Interactionを挟む一番の理由です。
もうひとつの軸は、対応する人が変わるかどうかです。電話を受けた本人だけで完結する相談はInteractionのままにして、別チームへの割り当てやSLAの管理が必要になった時点でIncidentに切り替えます。
転換のボタンはワークスペースの中にしかなかった
Interaction画面の右上にCreate incidentが並ぶ
実際にInteractionを1件作り、Service Operations Workspace（/now/sow/record/interaction/<sys_id>）で開きました。type=Phone、direction=Inbound、担当者はあらかじめ割り当てた状態で作成しています。
右上に並ぶボタンはSave・Create incident・Completeの3つでした。このボタンの実体はsys_ui_actionのレコードで、format_for_configurable_workspaceが有効な一方form_buttonは無効になっています。従来のinteraction.doフォームには表示されない、ワークスペース専用のボタンだと読み取れます。
ボタンの表示条件も見ておきます。new GlideRecord("incident").canCreate() && ((current.isNewRecord() && current.canCreate()) || !current.isNewRecord())という式でした。噛み砕くと「Incidentを作成する権限があり、かつ今開いているInteractionが保存済みか、保存前でも作成権限がある」場合にだけボタンが有効になります。Incidentの作成権限を持たないロールでInteractionを開くと、このボタン自体が出てこない、または押しても効かないはずです。権限まわりで問い合わせが来たときは、ロールの割り当てから疑うとよさそうです。
Create incidentを押すと何が起きるか
ボタンを押すと、画面全体は切り替わりません。同じタブの中に新しいサブタブが開き、Incidentのフォームがそのまま表示されました。
短時間の操作で終わっています。Incidentの短い説明はInteractionからそのままコピーされていました。右側の「Origin」パネルには、状態・番号・担当者・種類・短い説明まで、元のInteractionの情報が一式表示されています。Activityのタイムラインには「Incident created from Interaction」という自動の作業メモも残ります。
このボタンのスクリプトを読むと、caller_idにInteractionのopened_forを、short_descriptionをそのままコピーしていました。生成AI系のプラグインが有効で会話の要約（chat_summary）が入っていれば、Incidentのdescriptionにもその要約を渡す作りです。今回は要約が空だったため、descriptionは空のまま作成されています。
転換すると裏で何が作られるか
interaction_related_recordという中間テーブルに1行できる
転換の直後にinteraction_related_recordを調べると、1行できていました。
列はdocument_table・document_idという汎用のペアと、taskという専用の参照の両方を持っていました。今回のIncidentのようにtaskテーブルを継承するレコードならtask列にも同じsys_idが入ります。knowledge_articleという列も並んでいて、ナレッジ記事を関連付けたときも同じテーブルの1行として記録される作りだと分かります。operationには「Created」という文字列が入っていて、後から見ても新規に作られた関連だと分かるようになっていました。
Incident側はassigned_toまで引き継いでいた
Incident側を見ると、origin_tableにinteraction、origin_idにInteractionのsys_idが入っていました。ここまでは想定どおりです。指定していないはずのassigned_toにも、Interactionの担当者がそのまま入っていたのは想定外でした。
原因はIncidentテーブルに設定された別のBusiness Ruleでした。Set assignment from Interactionという名前で、新規作成時にだけ動き、origin_idが入っていれば参照先のInteractionからassigned_toをコピーします。Create incidentのスクリプト自体には担当者を代入する行が無いので、この自動コピーはスクリプトとは別の仕組みで動いていることになります。assignment_groupはコピーされず空のままでした。担当者個人は引き継がれても、グループの割り当ては引き継がれない設計のようです。
後から「どのチケットになったか」を辿る2つの方法
ワークスペースのRelated recordsタブから辿る
Interaction画面にはDetailsと並んでRelated recordsというタブがあります。開くと、Related TasksとInteraction Related Recordsという2つのリストが並び、どちらにも先ほど作ったIncidentが表示されていました。
日常の調査ならこのタブを開くのが一番早い経路です。この問い合わせはどうなったと聞かれたとき、Interactionの番号さえ分かればここから1クリックでIncidentに辿り着けます。
同じRelated recordsタブの左側には、Related TasksとInteraction Related RecordsのほかにUser's InteractionsとUser's Assetsという項目も並んでいました。今回作成した1件だけの環境ではUser's Interactions (0)と表示され、他に紐づくInteractionが無いことも数字で分かります。同じ相談者から繰り返し連絡が来ている場合、ここを開けば同一人物の過去のInteractionをまとめて見返せる作りだと分かりました。転換先を探すだけでなく、相談してきた本人の履歴を辿る入口も同じ画面に用意されています。
Incident一覧をorigin_tableで絞り込む
逆に、Incident側からこれはどの問い合わせから来たものかを大量に洗い出したいこともあります。その場合はorigin_table=interactionで一覧を絞り込みます。
一覧の上部には、絞り込みに使ったOrigin table = interactionの条件がパンくずとして表示されていました。件数が多い環境でも、Interaction経由で起票されたIncidentだけをまとめて洗い出せる作りです。
元のInteractionは自動では閉じない
Completeボタンを押すまでWork in Progressのまま
転換の直後にInteraction（IMS0000008）を確認すると、状態はWork in Progressのまま、activeもtrueのままでした。Incidentを作ったからといって、元のInteractionが自動的に閉じることはありません。
実際にCompleteボタンを押すと、確認のダイアログも出ないまま即座にClosed Completeへ切り替わりました。
Durationには受付から完了までの時間が自動計算され、8分50秒が入っていました。閉じた後はフォームの各項目がグレーアウトされ、Create incidentボタンも無効化されています。同じInteractionから2件目のIncidentを作る経路は、閉じた時点でふさがれる作りでした。
自動で閉じる設定も存在した（このPDIでは無効）
IncidentテーブルにはClose interaction from incidentという名前のBusiness Ruleもありました。Incidentが更新されるたびに動き、条件を満たせば元のInteractionをwrap_upかclosed_completeへ自動的に進めます。
条件は2つの設定がどちらも有効であることでした。
システムプロパティsn_sow_inc.autoclose_origin.interaction
Fallback Timeout for interactions in Wrap Upというスケジュールジョブの有効状態
このPDIではどちらも無効でした。プロパティの説明文には自動でクローズを有効にすると書かれていて、今回Interactionを手動で閉じたのは、この仕組みが働かなかったからだと分かります。有効にすれば、Incidentを解決・クローズした時点で元のInteractionも連動して閉じる運用に変えられそうです。試すなら本番相当の環境で挙動を確認してから切り替えたほうが安全です。
実機で気づいたこと
Close interaction from incidentが動くのは、Incidentを更新したときだけでした。action_insertはfalse、action_updateだけtrueになっています。最初はIncidentを作った瞬間に元のInteractionが閉じる仕組みだろうと考えていましたが、実際には新規作成時には発火しません。Incidentを後から更新したときに効くという条件を見て、設計の意図に気づきました。起票のタイミングでInteractionを閉じてしまうと、作業がまだ終わっていないのに記録上は完結したことになってしまいます。更新のたびに条件を見て、Incidentが本当に片づいたタイミングで閉じる方が理にかなっています。
もうひとつ意外だったのは、origin_table・origin_idという組がInteraction専用ではなかったことです。IncidentテーブルにはSet incident originという別のBusiness Ruleもあり、Change起因で作られたIncidentにはorigin_tableにchange_requestが入ります。同じ2列を使い回して、起票元が何であっても同じ経路で追えるようにしてあります。テーブルを増やさずに済ませる、ServiceNowでよく見る作り方です。
assigned_toだけがコピーされてassignment_groupは空のままだったのも、実際に見るまで分かりませんでした。担当者個人は引き継がれるのに、担当グループは引き継がれません。呼んだ人がそのまま担当者になる想定なのか、割り当てグループは改めて選び直す設計なのかは分かりませんが、全部がコピーされるわけではないという事実は覚えておく価値があります。
実務では何に使えるか
サービスデスクの現場でこの仕組みを使うなら、まずCreate incidentボタンが従来UIには無く、ワークスペースからしか押せないという事実が効いてきます。エージェントに新しい対応フローを教えるとき、Interactionから転換するときはワークスペースを開いてくださいと最初に伝えておかないと、ボタンが見当たらずに戸惑う人が出ます。
トリアージの基準を決める場面では、今回の判断表がそのまま使えます。その場で答えが返せるか、調査や復旧の作業が続くか。この1問をチームの合言葉にしておくと、Interactionで済ませるべき相談まで無理にIncident化してしまう事態を防げます。
問い合わせ数に対してIncidentの起票率が高すぎると感じているなら、interaction_related_recordを集計する価値があります。1件のInteractionから何件のIncidentが生まれているか、逆にInteractionだけで完結した件数はどれくらいかを数えれば、一次対応でどれだけ解決できているかが見えてきます。
自動クローズのプロパティを有効にするかどうかは、運用のポリシー次第です。Incidentを閉じた瞬間にInteractionも自動で閉じてほしいチームには向きますが、Interaction側で別の作業が残っている運用だと、自動で閉じられることが都合の悪さにつながります。有効化する前に、ラップアップの運用と衝突しないかを確認しておく必要があります。
新人のオペレーターを教育する場面でも、この記事の流れがそのまま使えます。電話を受けたらまずInteractionを起票する、その場で終わるならCompleteで閉じる、調査が要るならCreate incidentを押す。この3手順だけを覚えてもらえば、記録の付け方で迷う場面はほとんど無くなります。あとはOriginパネルの見方さえ教えておけば、自分が作ったIncidentがどのInteractionから来たのかを本人が確認できるようになります。
つまずきやすい点
Create incidentボタンは従来UIのInteractionフォームには出ません。ワークスペースを開かずに探すと見つかりません。
Incidentを作っただけでは元のInteractionは閉じません。クローズし忘れたInteractionが溜まっていく可能性があります。
Incidentのassignment_groupは自動で入りません。担当者個人だけが引き継がれるので、グループへの割り当てが必要な運用では手動で設定する手順を用意しておく必要があります。
一度Interactionを閉じると、そこから新しくIncidentを作る経路もふさがれます。追加の対応が必要になった場合は、新しいInteractionを起票し直す運用になります。
自動クローズの仕組みは2つの設定が両方有効でないと動きません。片方だけ有効にしても発火しないので、試すときは両方を確認します。
よくある質問
Q1. Create incidentボタンが見当たりません。どこを確認しますか
従来UI（interaction.do）のフォームには出ません。Service Operations Workspace（/now/sow/record/interaction/<sys_id>）でInteractionを開いているかを確認してください。sys_ui_actionのレコードでformat_for_configurable_workspaceが有効な場合、ワークスペース以外の画面には表示されません。
Q2. Incidentを作ったのに元のInteractionが自動で閉じません。壊れていますか
壊れていません。OOTBの既定では自動クローズは無効です。有効にするにはsn_sow_inc.autoclose_origin.interactionというシステムプロパティと、Fallback Timeout for interactions in Wrap Upというスケジュールジョブの両方を有効にする必要があります。
Q3. IncidentからどのInteractionが起票元か調べる方法はありますか
Incidentのorigin_tableとorigin_idを見ます。origin_table=interactionで一覧を絞り込めば、Interaction経由で作られたIncidentだけをまとめて洗い出せます。
Q4. InteractionからProblemやChangeへも同じように転換できますか
Create Problem・Create Standard Changeというボタンも同じInteraction画面にあり、同じinteraction_related_recordの仕組みを使っていると考えられます。今回はIncidentへの転換だけを実際に試したので、Problem・Changeについては実機で確認していません。
Q5. assigned_toが自動でコピーされるのを止めることはできますか
Set assignment from InteractionというBusiness Ruleが担っています。運用として不要であれば、このBusiness Ruleを無効化すれば自動コピーを止められます。無効化した場合の影響までは今回検証していません。
まとめ
InteractionからIncidentへの転換は、Service Operations WorkspaceのCreate incidentボタン1つで完結していました。押した瞬間にinteraction_related_recordという中間テーブルへ1行が記録され、Incident側にもorigin_table・origin_idという形で起票元が残ります。両方向から辿れる作りなので、後からこの問い合わせはどのチケットになったかも、このチケットはどの問い合わせから来たかも追えます。
元のInteractionは自動では閉じません。手動でCompleteを押すまでWork in Progressのまま残り、閉じた後は同じInteractionから新しいIncidentを作る経路もふさがれます。自動で閉じる設定も用意されていましたが、今回のPDIでは無効になっていました。
判断の軸はシンプルです。その場で答えが返せるならInteractionのまま閉じ、調査や復旧の作業が続くならIncidentへ上げる。この1問を起点に、転換の操作と裏側の記録まで押さえておけば、問い合わせ対応の記録は迷わず追えます。
用語
Interaction（interaction） … 電話・チャットなどの接触そのものを表す1件の記録
interaction_related_record … Interactionから転換・関連付けられた先のレコード（Incidentなど）を指す中間テーブル
origin_table / origin_id … Incidentなど転換先のレコードが持つ、起票元のテーブル名とsys_idの組
Service Operations Workspace（SOW） … Interactionの転換ボタンなど、ワークスペース専用のUI Actionが表示される画面
Create incident … InteractionからIncidentを作成するUI Action（内部名ws_create_incident）
自分の環境で確認するときのURL
Interactionをワークスペースで開く : /now/sow/record/interaction/<sys_id>
interaction_related_recordの一覧 : /interaction_related_record_list.do?sysparm_query=interaction=<sys_id>
Origin tableで絞り込んだIncident一覧: /incident_list.do?sysparm_query=origin_table=interaction
Incidentに設定されたBusiness Rule : /sys_script_list.do?sysparm_query=collection=incident^active=true
自動クローズのプロパティ : /sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_sow_inc.autoclose関連記事
Interaction：問い合わせの入口を1件にまとめる — 前提知識：state・type・directionの3軸とビジネスルールによる状態管理を先に押さえたい人向け
参考リンク
検証環境と未検証範囲
件数・画面はZurich PDI（OOTB）で確認したものです。本番環境やカスタマイズ済みの環境では、ボタンの構成やBusiness Ruleの有効・無効が異なります。
この記事のために、Interactionを1件新規作成しました。Service Operations Workspaceの操作でIncidentを1件作成し、その後Interactionを手動でCompleteしています。作成・更新したレコードはIMS0000008（Interaction）とINC0010459（Incident）の番号です。それ以外のレコードは新規に作っていません。
従来UI（interaction.do）を実際に開いてCreate incidentボタンが表示されないことを画面上で確認したわけではありません。sys_ui_actionのフラグから読み取った内容です。com.snc.incident.create_from_interaction.saveがfalseの場合の挙動（未保存のフォームが開く動き）や、sn_sow_inc.autoclose_origin.interactionを実際に有効化した場合の自動クローズの発火は試していません。設定変更を伴うため今回は見送りました。Problem・Standard Changeへの転換、Associate Recordによる既存レコードとの関連付けは、今回は操作していません。生成AIプラグイン（sn_itsm_gen_ai）によるdescriptionへの要約反映も、chat_summaryが空だったため実質未検証です。
