LINE活用の基礎

LINEで編集した文章がCRMに反映されない?編集イベントと同じメッセージIDの扱い

小川 靖人文・小川 靖人元LINE社員・LIFE合同会社 代表
この記事の執筆者:元LINE株式会社でLINE公式アカウント活用支援チームの立ち上げを推進し、LINE Green Badge試験問題の作成にも関与。バディカダイレクト元COOとしてLINE中心の販売基盤を構築し、AI接客チャットボット「中野愛作」を開発。詳しいプロフィール →
#Messaging API#Webhook#グループトーク#CRM連携
この記事は「LINE公式アカウント完全ガイド」の一部です。全体像はこちらから →

この記事の結論

LINEグループでテキストを編集しても、外部CRMの保存内容が自動で更新されるとは限りません。messageEditedの受信条件、元メッセージとの照合、再送と順序、業務上の確定内容を分けて確認します。

最終更新:2026年10月18日

LINE上の文章が編集されても、外部CRMに取り込んだ内容まで自動で書き換わるとは限りません。Messaging APIの編集イベントを受け取り、元のメッセージに対応する保存内容を更新する処理が必要です。

ただし、編集イベントはすべてのトークで受け取れるわけではありません。まず対象のトークとメッセージの種類を確認し、その後にCRM側の処理を調べます。ここでは独自のCRMや問い合わせ画面を作る担当者向けに、公式仕様と実装上の確認を分けて説明します。

まず、グループのテキスト編集かを確認する

公式のWebhookイベント一覧では、編集イベントを受信できるのはグループトークで、1対1のトークと複数人トークは対象外です。グループトークと、旧来の複数人トークは同じ区分ではありません。

また、編集イベントの定義は、ユーザーがテキストメッセージを編集した場合のものです。写真の差し替えや、送信取消を同じイベントだと扱わないでください。送信取消の取り扱いは、受信した写真・ファイルの扱いも参照できます。

「CRMに編集が反映されない」という報告を受けたら、最初に次の三点をそろえます。

  • 対象がグループトークであるか。
  • ユーザーが編集したのがテキストであるか。
  • 受信側がmessageEditedを処理する設計になっているか。

Webhook全体を受信できていても、イベントの種類をmessageだけに限定した実装では、編集を保存処理へ渡せない可能性があります。

LINEのテキスト編集を外部CRMへ反映する確認図。グループトークのテキスト編集を対象に、messageEditedを受信し、同じmessage.idの保存内容へ照合する。新規の問い合わせとして増やさず、編集後の内容と更新時点を確認する。会話の更新は予約などの確定情報の変更とは別で、手配済みなら担当者が確認する。1対1と複数人トークは編集イベントの対象外。

図:同じ会話の更新を、別の問い合わせや確定済みの手配変更と取り違えないための確認順です。

図解画像を開く(保存用)

元のメッセージIDと照合して、内容を更新する

編集イベントのmessageには、編集後のテキストが含まれます。公式リファレンスでは、編集イベントのmessage.idは元のメッセージイベントと同じ値になると説明されています。この対応を使い、元の会話と編集後の内容を結びます。

元のメッセージと照合できた場合は、担当者が見る本文を更新し、編集されたことを確認できる表示を検討します。表示名が同じ顧客を探して書き換えるのではなく、LINE公式アカウントやトークの所属も含め、対象のメッセージに対応する記録を使ってください。

元の記録が見つからない場合は、新しい問い合わせとして黙って追加する前に、受信漏れ、保存対象の条件、別のトークとの取り違えを調べます。「対応待ちの新規相談」が編集のたびに増えると、担当者は同じ話を別件だと思って返してしまいます。

ここで述べる更新表示や照合待ちは、独自システムの設計例です。LINE標準画面の項目名や、LYNXでの提供済み機能を示すものではありません。

再送されたイベントと、古い内容の上書きを分けて防ぐ

Webhookを再送する設定では、イベントが発生した順と届く順が大きく異なる場合があります。公式の共通プロパティでは、前後関係を確認する必要があるときにtimestampを見るよう案内されています。

保存処理では、同じイベントを二重に処理しないことと、同じメッセージの古い内容へ戻さないことを別々に確認します。前者にはイベントの識別、後者には更新の前後関係の確認が必要です。詳しくはWebhook再送と重複対策を参照してください。

編集イベントには元のイベントとは異なる応答トークンが含まれます。返信する場合は、今回受け取ったイベントと対応するトークンで処理を管理します。すべての編集へ自動返信するかは別の運用判断で、更新確認だけで十分な場面に返信を増やす必要はありません。

文章の訂正と、確定した業務の変更を分ける

以下は架空の運用例です。グループの相談で「水曜に伺います」が「木曜に伺います」へ編集されたとします。CRMの会話本文が更新されても、それだけで予約システムの確定日が木曜になったとは言えません。

既に担当者が予約や手配を確定しているなら、訂正内容を確認し、どの情報を変更するかを担当者が判断できるようにします。会話の更新、業務の変更、相手への確認結果の返答を一つの状態へまとめないでください。

公開前の試験では、テスト用の文章を編集し、元の会話と同じ記録へ反映されることを確認します。続いて、同じイベントの再受信、元の記録がない場合、処理の到着順が逆転した場合も試してください。会話本文やトークンを調査資料へ持ち出さず、照合の成否と必要な処理段階で確認します。

担当交代後も、訂正前の認識のまま案内しないことが目的です。元の会話と現在の確定内容を同じ場所から確かめられるようにし、お客様へ同じ説明をやり直してもらう作業を減らしてください。

※仕様の確認日:2026年10月18日。保存処理・業務確認は設計上の提案で、導入実績や実装済み機能の主張ではありません。

この記事に関連するサービス

関連記事