Live Feed / Connect：社内コラボの記録（live_message）
ServiceNow には、社内のちょっとした会話を記録として残す仕組みがあります。名前は Live Feed（ライブフィード）。かつて Connect と呼ばれていた、社内SNSのようなコラボ機能です。インシデントやチェンジといった業務レコードにフィードをぶら下げて、「なぜこの対応にしたのか」というやり取りを、そのレコードの中に残せます。
メールやチャットで交わした相談は、時間が経つと行方が分からなくなりがちです。Live Feed に残しておけば、そのレコードを開いた人が、後から会話の経緯をたどれます。今回は、この機能を支える3つのテーブル（live_group_profile・live_message・live_profile）を、PDI の実データで読み解きます。難しい設定の話ではありません。会話がどうデータになって残るのか、その形を落ち着いて眺めていきましょう。
読み終えると、フィードとチームの違いが、テーブルの言葉で説明できます。レコードに紐づくフィードの仕組みや、返信でスレッドが育つ様子も同じです。運用で「この決定の経緯はどこ？」と聞かれたとき、Live Feed という置き場所を思い出せると助かります。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-20）。本番環境では設定が異なります。
Live Feed とは：会話が「記録」として残る場所
Live Feed は、インスタンスの中に投稿を残して共有する場所です。実データにあった OOTB の説明文が、機能像をよく表していました。「投稿・返信・評価ができる」「特定のレコードが更新されたとき自動メッセージを生成できる」「新しい投稿をメール通知で購読できる」。つまり、掲示板とレコードの活動ログを足したような仕組みだと考えると、イメージが近いです。
ふつうのチャットと違うのは、会話が「テーブルの行」として残る点です。投稿の1件1件がレコードになり、検索できて、どのレコードに紐づくかも分かります。だから流れて消えません。この「消えずに残り、後からたどれる」性質が、Live Feed をコラボの記録として使う理由になります。
3つのテーブルで出来ている
Live Feed の中身は、大きく3つのテーブルに分かれていました。役割を先に押さえると、あとの話が楽になります。
live_group_profile … 会話の「器」。フィードやチームがここに並ぶ（実測17件）
live_message … 投稿の「実体」。本文・投稿者・どの会話か、が入る（実測57件）
live_profile … 参加者の「プロフィール」。誰が話しているかを表す層（実測114件）
図のとおり、ユーザーは live_profile というプロフィールを通して live_message を投稿します。その投稿は group という項目で live_group_profile（会話）に結びつく。返信は reply_to で別の投稿を指します。そしてフィードの一部は、業務レコードと連動します。この4つの線が分かれば、Live Feed のデータ構造はほぼ読めます。参照でつながっているだけなので、慣れれば1枚の絵として頭に入ります。
会話の器 live_group_profile：フィードとチーム
まず器から見ます。live_group_profile には、フィードやチームが1行ずつ登録されています。実画面で一覧を開くと、17件が並んでいました。
列は Name（名前）・Photo（写真）・Short description（短い説明）・Public（公開）。名前を見ると、AngularJS discussions のような話題ベースのものもあります。INC0000003 や CHG0000005 のように業務レコードの番号がそのまま名前になっているものもあります。Public 列には true と false が混在していて、誰でも見られる会話と、限られた人だけの会話が分かれていることが読み取れます。
この器を分類する鍵が type 項目です。選択肢を実測すると、Feed・Team のほか、Connect や Peer、Questions or Answers なども用意されていました。ただし今回の OOTB データに実在したのは Feed と Team の2種類だけで、内訳は Feed が12件、Team が5件でした。残りの選択肢は器としては定義されているものの、レコードは無く、挙動は検証範囲外です。
器そのものにも、公開範囲を決める項目がありました。public_group（公開）と visible_group（一覧に見せるか）の2つです。前者は誰でも参加・閲覧できるか、後者は検索や一覧に表示するかを分けています。名前（name）と短い説明（short_description）は、どちらも100文字までの文字列でした。器は素直な構造でした。名前・説明・公開範囲・タイプという、分かりやすい項目でできています。
フィードとチームの違い
同じ器でも、Feed と Team は役割が少し違います。実測した中身を並べると、その差がはっきりします。
Feed（type=group）は、話題や特定のレコードを中心に、広めに共有するための会話です。実データでは Workflow や IT support from fellow employees のような話題フィードがありました。加えて、インシデントやチェンジに連動したフィードも Feed に含まれていました。一方 Team（type=team）は、Finance や Sales のように、部署や業務の単位で閉じて使う作業スペースでした。5件の Team のうち、レコードに連動したものはありません。
公開の既定にも特徴があります。public_group の初期値は true ですが、実データでは Team の多くが false で、限られたメンバーの議論に使われていました。「広く共有したいならフィード、内輪で固めたいならチーム」。この使い分けが、そのままデータに現れています。
レコードに紐づくフィード：INC・CHG の会話が本体に残る
Live Feed でいちばん実務に効くのが、この「レコード連動フィード」です。live_group_profile には、連動先を指す項目が3つありました。table（連動するテーブル名）、document（連動レコードの sys_id）、document_group（レコード連動フィードかどうかの真偽値）です。
実測で document_group=true の器を数えると、incident が4件、change_request が1件で、合わせて5件ありました。実例を挙げます。INC0000003 のフィードは、table=incident で該当インシデントに連動していました。短い説明も「Wireless access not available on floor 3」で、インシデントの内容そのものです。CHG0000005 のほうは table=change_request に連動する、チェンジのフィードでした。
何がうれしいのか。インシデントを開いたとき、その画面のフィードに書いた会話が、live_group_profile と live_message として残るからです。「この切り分けは誰がどう判断したか」「なぜこの対応にしたか」を、チケット本体の脇に会話として保存できます。後から同じような事象が起きたとき、過去の会話を読めば経緯が分かる。フィードが業務レコードにひもづく、というひと工夫が、記録の価値をぐっと高めています。
仕組みとしては、3つの項目が組みで働いていました。document_group が「これはレコード連動フィードだ」という目印になり、table と document の2つで「どのテーブルの、どのレコードか」を1件に特定します。table はテーブル名を持つ専用の型、document は sys_id を持つドキュメントID型でした。参照(reference)を1本引くのではなく、この2項目でどんなテーブルのレコードでも指せるようにしてある。汎用的に「どんなレコードにもフィードを付けられる」設計だと読み取れます。実データでは incident と change_request にしか付いていませんでしたが、型のうえでは他のテーブルにも広げられる形です。
投稿の実体は live_message
会話の中身は、すべて live_message に入ります。実画面で一覧を開くと、57件の投稿が並んでいました。
表示されている列が、この機能の骨格をよく表しています。Message（本文）、Conversation（どの会話か＝group で live_group_profile を参照）、Profile（投稿者＝live_profile を参照）の3列です。投稿の本文だけでなく「どの会話に、誰が」書いたかが、1行にまとまっています。Application Development using ServiceNow の会話には Ted Bozelle が書いていました。IT support from fellow employees の会話には ITIL User が書いていました。
項目を細かく見ると、機能の広さが分かります。message は最大4095文字の本文、state は既定で published、like_count はいいねの数、reply_to は返信先の投稿を指す参照です。ほかにも添付やリンク、タグの有無を持つフラグ、Connect チャット用の chat_message、ダイレクトメッセージ用の to_profile などが並んでいました。1つの投稿レコードが、これだけの情報を抱えています。
group の入り方も実測しました。57件のうち、特定の会話に属さない投稿が25件、名前付きの会話に属す投稿が32件。25と32を足すと57で、ちゃんと一致します。会話ごとの投稿数は最大6件で、たとえば INC0000005 の連動フィードには6件の投稿がぶら下がっていました。
group が空の25件は、特定のフィードやチームに紐づかない投稿です。全社的なタイムラインへのつぶやきや、初期データに含まれる古い投稿が、ここに入っていました。逆に言えば、投稿は必ずしも器を必要としません。器に属す投稿と、属さない投稿が、同じ live_message テーブルに同居している。group が空かどうかで「会話の中の発言か、単独の投稿か」を見分けられる、と覚えておくと調査で迷いません。
返信でスレッドになる：reply_to と @メンション
Live Feed の会話が「経緯」として読めるのは、返信の構造があるからです。live_message の reply_to は、別の投稿を指す参照でした。ある投稿にぶら下げて返信すると、この項目に親投稿の sys_id が入ります。実測では、57件のうち26件が返信（reply_to が入った投稿）でした。半数近くが、何かへの返信です。
実際のスレッドを1つ見てみます。IT support from fellow employees フィードにあった、こんなやり取りです。
ITIL User:「シングルサインオンのパスワードを変えたら、TIDE インスタンスに直接ログインできなくなった」（親投稿）
System Administrator:「TIDE のログインは SSO と直接連携していない。古いパスワードを使って」（返信）
ITIL User:「ありがとう、うまくいった」（返信）
Pat Hoshaw:「@ITIL User さん、入社時のパスワードを使っていたのかも。新入社員でよくある事象です」（返信）
3件の返信がすべて同じ親投稿を指していて、1本の質問に回答がぶら下がる形になっていました。最後の投稿には @[sys_id:ITIL User] という形のメンションが入っていて、特定の相手に呼びかけていることも実データで確認できました。質問・回答・お礼・補足が1つのスレッドに残る。これが「後から経緯をたどれる」の正体です。
並び順を支える項目も用意されていました。in_reply_to は直前の投稿を指し、order は表示順を決める文字列、last_message はスレッドの最後の投稿かどうかを表す真偽値です。返信が増えても、これらの項目で「どれがどれへの返信で、どの順に読めばよいか」を保てます。だからスレッドが長くなっても、会話が枝分かれして迷子にならずに済みます。データとしての返信構造が、読みやすさをそのまま支えています。
誰の発言か：live_profile というプロフィール層
投稿者は、sys_user を直接は指しません。live_profile という中間の層を経由していました。live_message.profile が参照するのは live_profile です。この live_profile が、document 項目でユーザーなどの本体レコードにひもづきます。実測では114件のプロフィールがありました。
なぜ1枚かませるのか。live_profile には Live Feed 独自の状態が乗っていたからです。follower_count（フォロワー数）、following_count（フォロー数）、joined_feed（フィードに参加したか）などです。SNS的なフォロー関係や参加状態を、ユーザー本体とは別のこの層で持たせている、と読めます。「発言する人格」を Live 用に薄く分けている、という設計です。
作成・参加も記録される：システムメッセージ
投稿の中には、人が書いたものだけでなく、システムが自動で残したものもありました。実データには live_message がいくつか並んでいます。たとえば「System Administrator created the group」「ITIL User joined the group」です。フィードを作った、参加した、というライフサイクルの出来事が、そのまま投稿として記録されているわけです。
これは地味に便利です。「このフィードはいつ、誰が作ったのか」「誰が途中から参加したのか」が、会話の流れの中に時系列で残ります。人の発言と、システムの出来事が、同じ live_message テーブルに時系列で並ぶ。だから会話を上から読むだけで、器の成り立ちまで一緒に追えます。
実データの OOTB 説明文には、もう一歩進んだ使い方も書かれていました。「管理者は、特定のレコードが更新されたときに自動メッセージを生成するよう設定できる」という一文です。つまりレコードの状態が変わったら、その変化をフィードへ自動で流せます。手で書いた会話と、自動で流れてくる更新通知が、1つのフィードにまとまる形になります。実際にレコード更新の自動メッセージを流す設定は今回試していないため、挙動そのものは検証範囲外としました。それでもテーブルとしては、「人の会話」と「自動の記録」を同じ場所に集める器になっている、と読み取れます。この2つが1本の時系列に並ぶからこそ、フィードは「そのレコードに何が起きたか」の物語として読めるわけです。
件数で見る全体像
最後に、実測した数字を並べておきます。数で見ると、この機能の規模感がつかめます。
会話の器（live_group_profile）… 17件（Feed 12・Team 5）
レコード連動フィード（document_group=true）… 5件（incident 4・change_request 1）
投稿（live_message）… 57件（会話に属す32・属さない25）
返信（reply_to あり）… 26件
参加者プロフィール（live_profile）… 114件
器が17、投稿が57。1つの会話に、平均すれば数件の投稿がぶら下がる規模でした。デモ用の OOTB データなので数は控えめですが、テーブルの関係と項目の意味は、本番でもそのまま通じます。まずはこの3テーブルの役割分担を頭に入れておくと、Live Feed まわりの調査で迷いません。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
会話の器 … live_group_profile_list.do（type や Public で絞り込める）
投稿 … live_message_list.do（Conversation や Profile で絞れる）
プロフィール … live_profile_list.do
まとめ
Live Feed は、社内の会話を「消えない記録」として残す仕組みでした。器は live_group_profile（フィードとチーム）、投稿は live_message、話す人は live_profile。この3枚が、group・profile・reply_to という参照でつながっています。
いちばんの勘所は、フィードを業務レコードに連動できることです。インシデントやチェンジの脇に会話を残せば、「なぜこの対応にしたか」がチケットと一緒に保存されます。返信は reply_to でスレッドになり、質問と回答が1本に束ねられる。次に「あの決定の経緯は？」と聞かれたら、Live Feed という置き場所を思い出してください。会話がデータとして残っている、と分かっているだけで、探し方がずいぶん変わります。
その他、実機で確認した記録
用語
Live Feed（旧 Connect） … インスタンス内に投稿を残して共有する社内コラボ機能
live_group_profile … 会話の器。フィードやチームが1行ずつ入る（type で区別）
live_message … 投稿の実体。本文・投稿者・会話・返信先を持つ
live_profile … 参加者のプロフィール層。sys_user とは別にフォロー等の状態を持つ
レコード連動フィード … table + document で業務レコードにひもづくフィード（document_group=true）
調べるときの入口URL（先頭に自分のインスタンスを付ける）
/live_group_profile_list.do（会話の器。Feed / Team / Public で絞れる）
/live_message_list.do?sysparm_query=ORDERBYDESCsys_created_on（投稿を新しい順に）
/live_profile_list.do（参加者プロフィール）
/sys_choice_list.do?sysparm_query=name=live_group_profile^element=type（type の選択肢）
実測の要点（再掲）
live_group_profile 17件 … Feed 12・Team 5（type 別 count）
レコード連動フィード 5件 … incident 4・change_request 1（document_group=true）
live_message 57件 … 会話に属す32・属さない25、返信 26
live_profile 114件 … profile 経由で投稿者を表す
投稿は group（会話）・profile（投稿者）・reply_to（返信先）で関係づく
検証範囲とおことわり
件数・項目・選択肢・サンプル値は PDI（Zurich / OOTB）の REST と実画面での実測です。
Connect Chat（リアルタイムチャット）や購読通知、@メンション通知の実挙動は未実施（検証範囲外）です。
type の Connect / Peer / Questions or Answers などは選択肢として存在しますが、このデータに実レコードは無く、挙動は未確認です。
実クリックでの投稿・返信は行っていません。list.do のURL形式は規約に基づくものです。
