LINE受発注で注文が集中したときの運用｜ルール・標準機能・連携の使い分け

◆監修・編集責任者　小園 将隆　2026年10月29日

B2B EC-COLUMN

LINE注文が集中すると、どこで処理が詰まるのか

締め切り前や朝の時間帯に、取引先からのLINE注文が文章・画像・スタンプ混じりで一気に届くと、どのトークを処理し終えたのか分からなくなり、転記漏れや聞き返しが起きます。
LINEをやめなくても、変えられることはあります。
まず、混乱が注文の届き方から来ているのか、転記・確認・返信という処理側から来ているのかを切り分けます。
次に、書式と受付締切を決め、受領返信と確定返信を分けます。
そのうえでLINE公式アカウントのチャットの要対応・対応済み・担当者・タグ・ノートで未処理を見える化します。
ルーム単位で追えない注文が増えたら、フォーム誘導やAPI連携を検討します。

届き方の問題と処理側の問題を切り分ける

LINEで届いた注文を処理するとき、担当者の手元では作業がいくつも続いています。
トークを読み、品名と数量を拾い、台帳や販売管理の画面へ写し、在庫と納期を確かめ、取引先へ返信します。
注文が少ないうちは、この流れを一人が頭の中でつないでいても回ります。
締め切り前や朝に注文がまとまって届くと、どこまで進めたかを覚えておく余裕がなくなります。
途中で止まったトークは他の新着に埋もれ、見落としにつながります。

詰まりの原因の一つは、注文の届き方です。
品名の書き方が取引先ごとに違う、「いつもの」とだけ書かれている、手書きの発注書を撮った画像が送られてくる、了解のスタンプだけで追加の意図が分からない、といった注文があります。
こうした注文は読む段階で時間がかかり、聞き返しが増えます。
1通に納品日の違う注文がまとめて書かれていることもあります。
訂正が別のメッセージで後から届くこともあります。
そうなると、どれが最新の内容かを判断する手間も加わります。

もう一つは処理側です。
中小企業庁のミラサポplusは、電話やFAXによる受発注について整理しています。
経理システムへの手入力の転記が必要なため、ミスや書類紛失のリスクがあり、中小企業の生産性を下げる原因になっているという整理です⁵。
これは電話・FAXを対象にした説明で、LINEの注文を直接調べたものではありません。
ただ、LINEで受けた注文も、トークを見ながら別の画面へ手で打ち直しているなら、転記という同じ工程が残っています。
誰がどのトークを受け持っているかが決まっていなければ、同じ注文を二人が入力したり、誰も返信しなかったりすることも起こりえます。
届き方を整えても、転記、在庫確認、返信の順番が担当者の記憶に頼っている限り、集中時の漏れは処理側からも起こりえます。

どちらが主な原因かは、忙しかった日の注文を後から並べてみると見えてきます。
注文ごとに、次のことを書き出します。
必要な項目がそろっていたか、聞き返したか、転記のあとで直したか、受信から返信までどれくらい待たせたかです。
聞き返しの多くが品名や数量、納品日の抜けから来ているなら、届き方を変える効果が大きいと考えられます。
内容はそろっていたのに返信が漏れた、同じ注文を二度入力した、というものが多いなら、処理側の見える化が先になります。
両方が混ざっている場合は、件数の多いほうから手を付ける順番を決める材料として使います。

受領と確定を分けて見る

切り分けの際にもう一つ見ておきたいのが、「受け取った」と「引き受けた」の区別です。
集中時には、見たことだけでも伝えようとして「承知しました」と返すことがあります。
担当者は受信の合図のつもりでも、取引先はその言葉で注文が通ったと受け取るかもしれません。
あとで在庫が足りないと分かったとき、どの時点で何を約束したのかが曖昧になり、確認のやり取りが余計に増えます。

注文の状態は、少なくとも三つに分けて見ます。
「届いたが未確認」「受領を伝え、在庫と納期を確認中」「内容を確定して伝えた」の三つです。
こう分けると、集中時に何が止まっているかを言い分けられます。
未確認が溜まっているなら読む段階、確認中が溜まっているなら在庫や納期の確認で止まっています。
この区別が、返信のルールとチャットでの状態管理の両方の土台になります。

▼ 図の内容を文字で読む

• 届き方：自由文・画像・「いつもの」
  • 聞き返しが増える
  • 読む段階で時間がかかる
• 届き方：1通に複数の注文・後から訂正
  • どれが最新か判断する手間
• 処理側：手入力の転記
  • 二重入力
  • 転記ミス
• 処理側：受け持ちと未処理が決まっていない
  • 見落とし
  • 返信遅れ

書式・締切・受領返信・確定の基準で、集中をどこまで抑えられるか

注文の書式と受付締切

届き方の側でまず効くのは、取引先に送ってもらう注文の並びを決めることです。
たとえば「取引先名／品名／数量と単位／納品希望日／納品先」の順に1行ずつ書いてもらうと、担当者は毎回同じ位置を見て拾えます。
納品先が一つしかない取引先なら省き、規格や色で品物が分かれるなら品名の後に入れる、というように、自社の品目に合わせて項目を絞ります。
項目を増やしすぎると取引先が書かなくなります。
聞き返しの原因になっている項目を優先して残すのが現実的です。

書式は取引先にとっての手間でもあります。
TemplateメッセージやFlexメッセージのような形式のメッセージを、利用者がLINEアプリから送ることはできません⁴。
そのため、取引先が送ってくる注文は基本的に文章や画像になります。
書式は「この順に書いてください」という見本を共有する形になります。
見本の文面をLINE公式アカウントの定型文に登録しておけば、聞き返すたびに打ち直さずに済みます。
定型文はチャットの基本機能で、有料のオプションがなくても使えます²。

1通に1件の注文を書いてもらうことも決めておくと、後の管理が楽になります。
納品日の違う注文が1通にまとまっていると、一部だけ確定した状態を表しにくくなるからです。
訂正も、元の注文を引用するなど、どの注文を直すのかが分かる書き方で送ってもらいます。
そうすれば、どれを直すのかで迷いません。

受付締切は、注文の量そのものを減らすものではありません。
変わるのは、どの注文をいつの便で扱うかの線引きです。
たとえば「前日17時までの注文は翌日納品、それ以降は翌々日扱い」と決めて案内しておきます。
締切直後に届いた注文を急いで処理するか迷う時間がなくなり、取引先への返信も一定の文面で済みます。
締切を案内するときは、訂正やキャンセルの受付期限も一緒に決めておきます。
確定後の変更をどこまで受けるかで、やり取りがこじれにくくなります。

受領返信と確定返信の分け方

処理側で決めたいのは、返信を二段階に分けることです。
受領返信は、注文が届いて担当者が見たことを伝える返信で、内容の約束はしません。
「ご注文を受け付けました。在庫と納期を確認し、本日14時までに確定のご連絡をします。」のように、次の連絡の時刻を添えます。
取引先は待てばよいと分かるので、催促のメッセージが減ることが期待できます。
確定返信は、在庫と納期を確かめたあとに送る返信です。
品名・数量・納品日を復唱して「以上の内容で確定します」と伝えます。

復唱を入れる理由は、担当者が転記した内容と取引先が送った内容のずれを、取引先側にも見てもらうためです。
数量の桁違いや品名の取り違えは、転記した本人が見直すより、注文した側が見たほうが気づきやすいことがあります。
受領返信と確定返信の文面をそれぞれ定型文にしておけば、集中時でも打つ手間は大きく増えません。

どの返信をもって注文が確定したと扱うかは、取引先と合意して、案内文や取り決めの書面に残しておきます。
返信の文言が法的にどう評価されるかは、取引の内容や当事者間の取り決めによって判断が分かれます。
返信の言葉だけで決まるとは言い切れません。
運用としてできるのは、受領返信には「確認中」であることを、確定返信には「確定」であることを、誤解のない言葉で書き分けることです。
取引基本契約などで受注確定の方法を定めている取引先には、その定めと返信のルールを食い違わないように合わせます。

効果の確かめ方

ルールを決めたら、1週間ほど同じ項目を数えてみます。
数えるのは四つです。
聞き返した件数、受信から受領返信までの時間、受領返信から確定返信までの時間、確定後に内容を直した件数です。
ルールを入れる前の1週間と比べると、どこが変わり、どこが変わらなかったかが分かります。

聞き返しが減り、受領返信までの時間も短くなったなら、届き方の対策が効いています。
聞き返しは減ったのに、確定返信が遅れる、返信し忘れたトークが見つかる、という状態が続くこともあります。
その場合はルールの問題ではなく、未処理のトークを見失っている可能性があります。
ルールの見直しを重ねるより、チャットの画面で未処理を見分ける仕組みに進んだほうが、漏れの原因に直接手が届きます。

▼ 図の内容を文字で読む

1. 届いたが未確認
   • 要対応に並ぶ
   • 担当者を先に設定
2. 受領返信を送る
   • 内容は約束しない
   • 確定連絡の時刻を添える
3. 在庫と納期を確認中
   • 要対応のまま
4. 確定返信を送る
   • 品名・数量・納品日を復唱
5. 対応済みに切り替える

LINE公式アカウントの標準機能で、受注管理をどこまで補えるか

要対応・対応済み・担当者の使い方

LINE公式アカウントのチャットでは、チャットリストを「要対応」「対応済み」「担当」で絞り込めます¹。
先ほどの三つの状態に当てはめると、次のような使い方ができます。
受領返信を送ったあと、確定返信を送るまでは要対応のままにしておき、確定返信を送った時点で対応済みに切り替えます。
ただし、未確認の新着と確認中の注文は、どちらも要対応に並びます。
受領返信を送ったかどうかは、トークの最後の返信を見るか、タグで区別します。

担当者は、チャットごとに割り当てられます。
注意したいのは、担当者が設定されていないチャットでは、最初にそのチャットへ送信したメンバーが担当者になる点です¹。
集中時に、手の空いた人が目についたトークへ受領返信だけ送ると、その人が担当者になります。
在庫確認を別の人が進めていても、画面上は前の人の担当のまま残ります。
担当の決め方は、取引先ごとに固定する、午前と午後で分ける、といった形で先に決めておきます。
受領返信を送る前に担当者を設定しておけば、絞り込みの「担当」が実際の担当と一致します。

タグとノートの上限

要対応と対応済みだけでは、確認中の理由までは分かりません。
そこでタグとノートを使いますが、無料で使える範囲には上限があります。
タグは作成できるのが5種類まで、1ユーザーに付けられるのは1個、ノートは1ルームにつき1件です¹。

タグを1個しか付けられないので、「在庫確認中」や「納期調整中」のような状態のタグを付けると、拠点や担当を示すタグは同時に付けられません。
5種類の使い道も、状態を表すものに絞ることになります。
ノートも1件なので、未確定の注文の内容をメモしておくと、次の注文が来たときに同じノートを書き換えることになります。
前の注文の経過は残りにくくなります。

ここで押さえておきたいのは、要対応・対応済み、担当者、タグ、ノートのいずれも、チャットのルーム、つまり取引先ごとに付く情報だという点です。
公式マニュアルの機能説明から読み取れる範囲では、注文1件ごとに状態を持たせる仕組みではありません。
たとえば取引先Aから火曜納品の注文と木曜納品の注文が続けて届き、火曜分だけ確定したとします。
ルームを対応済みにすると木曜分の未確定が見えなくなり、要対応のままにすると火曜分が終わったことが画面から分かりません。
1通1注文のルールや受領返信の文面で区別しても、ルームの状態は一つしかないという点は変わりません。

取引先が少なく、1社から同時に未確定の注文が重なることがまれなら、ルーム単位の管理で十分に回ります。
同じ取引先から複数の注文が並行して動くことが日常的なら、補いが必要になります。
ノートに未確定の注文を一覧で書く、別の台帳で注文ごとの状態を持つ、といった方法です。

チャットProオプションで広がる範囲

チャットProオプションは、LINE公式アカウントのオプションで、月額費用は3,000円（税別）です²。
利用中の月額プランに関係なく契約できます²。
この金額は2026年10月時点で表示されている、LINEヤフーのこのオプションの料金です。
受注管理の専用ツールの費用の目安になるものではありません。

Proを契約すると、作成できるタグが300個まで増え²、1ユーザーに付けられるタグは30個になります¹。
ノートはチャットルームごとに1,000件まで保存できます²。
状態のタグと、担当や納品先のタグを重ねて付けられます。
ノートを注文1件ごとに分けて書けるので、無料範囲で感じた「一つしか持てない」窮屈さはかなり緩みます。
カスタムフィルターとチャット履歴のダウンロードも、Proの購入者だけが使える機能です¹。
AIチャットボット（β）も追加されます²。

履歴の保存期間も変わります。
無料範囲では半年、Proでは5年間で、対象は2024年1月1日以降の履歴です¹。
ただし、グループや複数人のトークでは、画像・動画は2週間、ファイルは1週間と、保存期間が短く設定されています¹。
取引先の店舗スタッフを集めたグループで発注書の写真を受けているなら、確定した注文の内容を台帳など別の場所へ写しておかないと、後から確かめられなくなります。

一方で、Proで増えるのは記録の置き場所と絞り込みの手段です。
トークから台帳や販売管理へ打ち直す作業はそのまま残ります。
機能説明を見る限り、状態がルームに付くという点もProで変わるものではありません。
ノートを注文ごとに分けて未確定を追うことはできても、注文の一覧を出荷や請求の作業へつなぐには、別の台帳への転記が必要です。
集中時の詰まりが「どれが未処理か分からない」ことにあるなら、Proで改善できる余地は大きいといえます。
「転記が追いつかない」ことにあるなら、次の選択肢まで視野に入れることになります。

▼ 図の内容を文字で読む

• ルームに付く情報（取引先ごとに一つ）
  • 要対応・対応済み
  • 担当者
  • タグ
  • ノート
• ルームの下の注文（取引先Aの例）
  • 火曜納品の注文：確定済み
  • 木曜納品の注文：確認中
• ルームの状態を一つにすると
  • 対応済みにすると木曜分の未確定が見えなくなる
  • 要対応のままだと火曜分が終わったことが分からない

ルームの管理で足りない場合の選択肢を、条件別に比べる

条件別の比較（注文量・取引先数・担当人数・既存の管理方法）

ここまでの話を、取れる選択肢として並べると三つになります。
運用ルールと無料範囲のチャット機能で回す方法、チャットProオプションで記録と絞り込みを広げる方法、注文の入口をフォームに移すかMessaging APIで外部の仕組みへつなぐ方法です。
どれが合うかは、注文量、取引先数、担当人数、既存の管理方法の四つで分かれます。

注文量で効いてくるのは、件数そのものより、集中の山で一人が読み切れるかどうかです。
山の時間に担当者が新着を読み、受領返信を送り、確認中の注文を思い出せるうちは、ルールと状態の切り替えで足ります。
読むだけで手一杯になり、転記が昼過ぎまで押すようになったら、打ち直しの作業そのものを減らす方法を考える段階です。

取引先数が増えると、チャットリストのスクロールとタグの種類が問題になります。
無料範囲のタグ5種類で状態だけを表しているうちはよくても、拠点や配送ルートでも分けたくなったら、Proの上限が意味を持ちます。
担当人数が増えると、担当者の設定と引き継ぎが要になります。
一人で処理しているなら記憶で補える部分も、二人以上になると、ノートやタグに残っていない情報は、他の人にとって無いのと同じになります。

最後に、既存の管理方法です。
受注を紙やExcelの台帳で管理しているなら、LINEの記録を整えるだけで済む範囲は広くなります。
Proの履歴ダウンロードで、後から台帳と照合する使い方も考えられます。
販売管理や在庫管理のシステムに受注を入れているなら、詰まりの中心はそこへの打ち直しにあります。
注文の入口をフォームに移して項目をそろえれば、システムへ取り込める形で注文を受けられる可能性があります。
Messaging APIで受け取ったメッセージをシステムへ渡す方法もあります。
どこまで自動で取り込めるかは、使うフォームや受注管理の仕組み次第です。
導入前に、そのサービスの仕様で項目の対応と取り込みの方法を確かめます。

フォームへの誘導は、取引先の手間を一つ増やします。
LINEで慣れた取引先にとっては、トークを開いてそのまま書くほうが楽です。
フォームのリンクを開いて入力し直すのは、負担に感じられるかもしれません。
受ける側には、必須項目がそろう、注文ごとに1件のデータになる、という利点があります。
その利点と取引先の慣れとの釣り合いは、取引先への段階的な案内で調整します。

API連携で必要になる前提

Messaging APIは、LINE公式アカウントに届いたメッセージを、自社や委託先のサーバーで受け取るための仕組みです。
取引先がメッセージを送ると、LINEプラットフォームから、あらかじめ登録したWebhook URL（メッセージが届いたことを知らせる受け口）へイベントが送られます³。
受け取った文章を受注台帳へ書き込めば、担当者がトークを見ながら打ち直す工程は減ります。
取引先が送った画像やファイルも取得できますが、一定期間後に自動で削除されます³。
受け取った時点で保存する処理を組んでおく必要があります。

連携で気をつけたいのは、同じ注文が二度入ることと、届くはずの注文が入らないことです。
ネットワークの事情で、同じイベントが複数回届くことがあります⁴。
受け取る側では、webhookEventIdで重複を見分け、timestampで順序を判定するよう案内されています⁴。
この判定を組まずに受け取ったものをそのまま台帳へ書き込むと、手入力をやめたのに二重入力と同じことが起こりえます。
訂正のメッセージが元の注文より先に処理される、といった順序の入れ替わりにも、時刻での判定が効きます。

取りこぼしの側では、Webhookの再送設定を確認します。
再送は初期設定ではオフで、コンソールで有効にでき、受け取る側のサーバーが2xx以外の応答を返したときに働きます⁴。
回数と間隔は公開されておらず、配信も保証されていません⁴。
サーバーが止まっていた時間帯の注文が抜けている可能性を前提にしておきます。
毎日、チャットの画面と台帳の件数を突き合わせる確認を、手作業で残しておくと安心です。

連携しても残る作業もあります。
自由文や画像の注文を、品名・数量・納品日の項目に分けて読み取れるかどうかは、連携するサービスの仕様次第です。
読み取れない場合は、台帳へ届いた文章を人が読んで項目に分ける作業が残ります。
減るのは、画面を行き来してコピーする部分にとどまります。
書式のルールを先に浸透させておくと、機械で項目に分けやすくなり、人が読む場合も速くなります。
ルールの整備は、連携の準備としても無駄になりません。

受領返信を自動で送る場合は、送り方にも違いがあります。
返信メッセージは対話中のユーザーへの応答として送り、プッシュメッセージは任意のタイミングで送ります³。
無料で送れる数は、月ごと・料金プランごとに決まっています³。
確認を終えてから送る確定返信まで自動にするなら、どの送り方になり、月の送信数がどれくらいになるかを、契約中のプランと照らしておきます。

▼ 図の内容を文字で読む

• 運用ルール＋無料範囲のチャット機能
  • 集中の山でも担当者が新着を読み切れる
  • 取引先が少なく、未確定の注文が並行することがまれ
  • 受注を紙やExcelの台帳で管理している
• チャットProオプション
  • 状態・担当・納品先のタグを重ねたい
  • 注文ごとにノートを分けたい
  • 担当者が複数で引き継ぎが要る
• フォーム誘導・Messaging API連携
  • 転記が集中の山を越えて押す
  • 販売管理や在庫管理のシステムへ受注を入力している
  • 重複と順序の判定や突き合わせを用意できる

取引先への案内と、移行期間の混在の管理

案内の順序

方式を決めたら、取引先に案内します。
いきなりフォームや新しい受け方に切り替えるより、段階を分けたほうが、取引先の戸惑いと受ける側の混乱の両方を抑えやすくなります。

進め方の一例は次のとおりです。
第1段階では、全取引先に注文ルールだけを案内します。
内容は、注文の書式の見本、受付締切と訂正の期限、受領返信と確定返信の意味の三点です。
第2段階では、注文の多い取引先や、1社から並行して注文が動く取引先など、効果が見込める先に絞って、フォームや連携を試してもらいます。
第3段階では、試した取引先での聞き返しや入力の戸惑いを見て、案内文や項目を直してから対象を広げます。

案内では、取引先にとっての利点を先に伝えます。
「確定のご連絡を何時までにお送りします」「確定返信に内容を復唱するので、数量違いをその場で確かめられます」のように示します。
取引先が待つ時間と確かめられることが分かれば、ルールが受ける側の都合だけではないと伝わります。
急ぎの注文や締切後の相談をどう受けるかを書いておかないと、取引先は従来どおり自由文で送るしかなくなります。
例外の窓口も一緒に示します。

混在期間の記録の仕方

新しい方式を案内しても、しばらくは従来の書き方の注文が混ざります。
このとき困るのは、注文がフォームとLINEのトークに分かれて、どちらを見れば全部か分からなくなることです。
そこで混在期間は、どの方式で届いた注文も最終的に一つの台帳へ集める、と決めておきます。

従来の自由文で届いた注文は、チャットのタグで「旧方式」と分かるようにし、ノートに注文内容を写したうえで台帳へ入れます。
無料範囲でタグを1個しか付けられない場合は、状態のタグと重なります。
旧方式かどうかはノートの先頭に書くなど、置き場所を決めておきます。
フォームや連携で届いた注文でも、取引先との連絡をLINEで続けるなら、確定返信はチャットから送り、ルームの要対応・対応済みも同じルールで切り替えます。
入口が二つあっても、状態を見る場所と記録の行き先を一本にしておけば、集中時に二か所を見比べる手間は減らせます。

移行が進んでいるかは、取引先ごとに、新しい方式で届いた注文の割合と、聞き返しの件数の推移を見ます。
割合が上がらない取引先には、案内が届いていないのか、方式が合っていないのかを、先方の発注担当者に一言聞いてみると分かります。
割合が上がっているのに聞き返しが減らないなら、書式やフォームの項目が自社の品目に合っていない可能性があります。
旧方式の受付をいつ終えるかは、こうした数字を見ながら、取引先と相談して決めることになります。

自社の詰まりが注文の届き方と処理側のどちらにあるかは、実際の注文と転記・返信の流れを並べてみないと判断しにくいためです。

いまの注文の届き方と処理の流れを一緒に整理し、ルールと標準機能で足りるのか、連携まで考える段階なのかを確かめられます。無料相談で要件を整理する

LINE受発注の運用方式が合う条件

注文量・取引先数・担当人数・既存の管理方法の4つの条件で、それぞれの方式が合う場面を並べた

• 運用ルール＋無料範囲のチャット機能：集中の山でも担当者が新着を読み切れる注文量で、取引先が少なく、1社から未確定の注文が並行することがまれ。担当が一人か少人数で、受注を紙やExcelの台帳で管理している場合

• チャットProオプション：取引先が増えて、状態・担当・納品先のタグを重ねたい場合や、注文ごとにノートを分けたい場合。担当者が複数で引き継ぎが要る場合や、履歴を長く残してダウンロードで照合したい場合

• フォーム誘導・Messaging API連携：転記が集中の山を越えて押す注文量で、販売管理や在庫管理のシステムへ受注を入力しており、注文1件ごとのデータで管理したい場合。重複と順序の判定や、チャット画面との突き合わせを用意できることが前提

受領返信までは早いのに確定返信が漏れるならProで状態の記録を広げ、転記が集中の山を越えて押すなら入口や連携を見直す、というように詰まりの場所が移ったときが切り替えの目安です。

要点の整理

軸	基準
原因の切り分け	聞き返しが多ければ届き方、内容はそろうのに漏れや二重入力が出るなら処理側
返信	受領返信は内容を約束せず確定の予定時刻を伝え、確定返信で品名・数量・納品日を復唱
チャットの状態	確定返信までは要対応、確定後に対応済み。担当者は受領返信の前に設定
無料範囲の限界	タグは5種類・1ユーザー1個、ノートは1ルーム1件。状態は取引先のルーム単位
Proの範囲	月額3,000円（税別）。タグ・ノート・履歴は広がるが、台帳への転記は残る
連携の前提	webhookEventIdで重複、timestampで順序を判定し、再送設定と毎日の突き合わせを用意

連携や移行を考える段階では、既存の受注管理との項目の対応や、重複・取りこぼしへの備えなど、導入前に詰める点が増えるためです。 現在の管理方法と注文量に照らして、どの方式から試すか、移行期間の記録をどう一本化するかを確かめられます。

よくある質問

LINEの注文で「受領しました」と返信すれば、契約は成立したことになるのですか。

返信の文言だけで法的な成立時期が決まるとは言い切れず、取引の内容や当事者間の取り決めによって判断が分かれます。
運用としてできるのは、受領返信には在庫と納期を確認中であることを、確定返信には確定であることを書き分けることです。
そのうえで、どの返信を確定として扱うかを取引先と合意して残しておきます。
取引基本契約で受注確定の方法を定めている場合はその定めに合わせ、法的な扱いが問題になりそうな取引は専門家に相談してください。

画像で届いた注文は、チャットの履歴にいつまで残りますか。

チャット履歴の保存期間は、無料範囲で半年、チャットProオプションで5年間で、対象は2024年1月1日以降の履歴です¹。
グループや複数人のトークでは、画像・動画は2週間、ファイルは1週間と短く設定されています¹。
Messaging APIで受け取った画像も、一定期間後に自動で削除されます³。
写真で受けた注文は、確定した時点で内容を台帳などへ写しておくと、後から確かめられます。

担当者を決めずに複数人でチャットを見ていると、誰が担当になりますか。

担当者が設定されていないチャットでは、最初にそのチャットへ送信したメンバーが担当者になります¹。
集中時に受領返信だけを送った人が、意図せず担当者になることがあります。
取引先ごとや時間帯ごとに担当を決め、受領返信の前に担当者を設定しておくと、「担当」での絞り込みが実際の分担と一致します。

1通のトークに複数の注文が入っているとき、未処理をどう管理すればよいですか。

チャットの要対応・対応済みはルームごとに一つなので、注文ごとの状態は表せません。
まず取引先に1通1注文で送ってもらうよう案内します。
それでも複数の注文が入った場合は、確定返信を注文ごとに分けて復唱し、未確定の注文をノートに書き出します。
無料範囲のノートはルームに1件なので一覧で書き、チャットProオプションならノートを注文ごとに分けられます。
並行する注文が日常的なら、注文ごとの状態を持つ台帳を別に用意します。

API連携をするとき、二重入力を防ぐために何を確認すればよいですか。

同じWebhookイベントが複数回届くことがあるため、受け取る側でwebhookEventIdによる重複の判定と、timestampによる順序の判定を組んでいるかを確認します⁴。
再送は初期設定でオフで、有効にしても配信は保証されないので⁴、チャット画面と台帳の件数を突き合わせる確認も残します。
連携を始めたあとに担当者が手入力も続けると同じ注文が2件入るので、どの経路の記録を正とするかも決めておきます。

1. 1　出典：LINEヤフー株式会社「LINE公式アカウント チャット（公式マニュアル）」（2026年10月閲覧）
2. 2　出典：LINEヤフー株式会社「LINE公式アカウント チャットProオプション」（2026年10月閲覧）
3. 3　出典：LINEヤフー株式会社「LINE Developers Messaging API 概要」（2026年10月閲覧）
4. 4　出典：LINEヤフー株式会社「LINE Developers Messaging API メッセージ（Webhook）の受信」（2026年10月閲覧）
5. 5　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）