LINE受注が朝に集中して追いつかない：応答時間の設定と書き方の統一でさばく手順

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

B2B EC-COLUMN

LINE受注の朝の山はどこで詰まっているのか：時刻・文面・手作業の切り分け

朝にトークを開くと、前の晩から届いた注文が並んでいます。
1件ずつ品目と数量を読んで表に写し、在庫を見て返信しているうちに、新しい注文が届いて未返信のトークが埋もれていきます。
この詰まりは、届く時刻の偏り、注文文面のばらつき、確認・転記・返信の手作業の3つに分けると、打つ手が見えてきます。
LINE公式アカウントの応答時間・応答メッセージ・チャット管理を使えば、時間外の受付返信と対応漏れの見える化までは開発なしで整えられます。
チャットの送受信や自動応答は、通数の課金対象外です¹。
集計表への自動転記にはMessaging APIの受信サーバーが必要なので、まず受付ルールと書き方の統一を1週間試し、残った分だけ仕組み化を考える順をおすすめします。

1件の注文が朝に通る工程

朝の受注処理を1件ずつ追うと、同じ動作を何度も繰り返していることが分かります。
まずトーク一覧から未処理の注文を見つけます。
次に品目・数量・納品日・届け先を読み取り、集計表や出荷表に写し、在庫を確かめます。
最後に、受け付けたことや確定の連絡を返します。
このうちどこに時間がかかっているかは、店によって違います。

朝に詰まる店でも、事情はさまざまです。
前日の夜から少しずつ届いた注文が、朝に一度に見えているだけの店があります。
始業直前に取引先の発注が重なる店もあります。
注文の書き方が取引先ごとに違い、読み取りで手が止まる店もあります。
朝が苦しいことはどの店も同じでも、効く手当ては同じではありません。

届く時刻・文面・手作業の3要因

負担は次の3つに分けて考えると整理しやすくなります。

• 届く時刻の偏り：始業時点でたまっている件数、つまり朝の山の高さを決めます。
• 文面のばらつき：1件を読み取るのにかかる時間と、聞き返しや読み違いの起こりやすさを決めます。
• 確認・転記・返信の手作業：1件あたりの手数で、件数が増えるほどそのまま積み上がります。

3つは互いに重なります。
山が高い朝ほど急いで読むので、ばらついた文面を読み違えやすくなります。
読み違いや聞き返しが出ると1件の処理が長引き、その間に次の注文が届いて、山がなかなか低くなりません。
どれか一つを軽くすれば、ほかの2つの影響も少し和らぎます。
ただし、どれを最初に軽くするかで、必要な準備がまったく違ってきます。

手作業の転記については、公的な資料にも参考になる記述があります。
中小企業庁のミラサポplusは、電話やFAXによる受発注では経理システムへの手入力が必要になり、入力ミスや書類紛失のリスクが生じて、生産性を下げる要因になると説明しています⁷。
これは企業間の電話・FAXの受発注についての記述で、LINEでの受注を測ったものではありません。
それでも、届いた文面を人が読み、別の表に打ち直すという構造は、LINEのトークを集計表へ写す作業と共通しています。
写すたびに入力ミスが入り込む余地が生まれる点も同じです。

自分の詰まりを数えて見分ける

どの要因が重いかは、感覚より数で見分けるほうが確かです。
数えるものは次の3つです。

1. 時刻：前日の受付終了から当日の処理開始までに届いた件数と、その時刻の散らばり方を書き出す。
2. 文面：届いた注文を書き方の型で分け、型がいくつあるかと、聞き返した件数を数える。
3. 手作業：1件を処理するあいだに開く画面と手順の数を、トークを開くところから返信まで順に書き出す。

数えるときは、LINE公式アカウントの管理画面にあるチャット機能が手がかりになります。
チャットは要対応・対応済みに振り分けられます³。
朝の処理を始める時点で要対応がいくつ残っているかを記録すれば、山の高さを毎日同じ物差しで測れます。

数え終えたら、いちばん重いものから手を付けます。
時刻の偏りが目立つなら、受付時刻と締めのルールを決めます。
型が多く聞き返しも多いなら、書き方を統一します。
型は揃っているのに転記の手順が多いなら、仕組み化を検討します。
この3つの手当てのうち、最初の2つはLINE公式アカウントの標準機能で始められます。

▼ 図の内容を文字で読む

• 届く時刻の偏り
  • 数える：前日の受付終了から処理開始までに届いた件数と時刻
  • 手当て：受付時刻と締めのルールを決める
• 文面のばらつき
  • 数える：書き方の型の数と聞き返した件数
  • 手当て：書き方を統一する
• 確認・転記・返信の手作業
  • 数える：開く画面と手順の数
  • 手当て：転記の手順が多ければ仕組み化を検討する

LINE公式アカウントの標準機能でできること：応答時間・応答メッセージ・チャット管理

応答時間と応答メッセージ

LINE公式アカウントの管理画面（LINE Official Account Manager）では、応答時間を設定できます。
応答時間内は、担当者の手動チャットに応答メッセージやAIチャットボット（β）などを組み合わせられます。
応答時間外は、応答メッセージなどが使われます²。
トーク画面に出る応答状況の表示文言も、設定に応じて時間外用に切り替わります²。
スマートフォンのアプリ版では、同じ機能が「営業時間機能」という名前で案内されています²。

応答メッセージは、届いたメッセージに自動で返す文面です。
夜や早朝に注文が届いても、時間外の応答メッセージが「受け取ったこと」と「次に対応する時刻」を返せば、担当者が返信するまで取引先を待たせたままにせずに済みます。
一方、応答時間内は担当者が自分で返す前提にしておけば、在庫を確かめたうえでの確定連絡を人が責任を持って送れます。
時間外は自動で受け止め、時間内は人が確定させる。
この役割分担を、標準機能だけで組めるわけです。

あいさつメッセージにも触れておきます。
友だち追加のときに送るあいさつメッセージは、オフにすると、保存していても配信されません²。
新しい取引先に注文の書き方や受付時刻を最初に伝える場所なので、ルールを変えたときは、ここが古い内容のままになっていないか、オンになっているかを見ておく必要があります。

チャットの要対応・担当者管理

朝の見落としを減らすうえで効くのは、チャットの振り分けです。
チャットは要対応・対応済みに振り分けられます。
担当者が未設定のチャットでは、最初に送信したメンバーが担当者になり、後から変更もできます³。
操作の手順は、Web版とアプリ版で異なります³。

使い方の例を挙げます。
朝はまず要対応のチャットだけを表示して、上から処理します。
確定連絡まで送ったものは対応済みに移します。
開いただけのトークや返信の途中で手が止まったものは、要対応に残しておけば、未処理かどうかを記憶に頼らずに済みます。
担当者が2人以上いる場合は注意が必要です。
最初に返信した人がそのまま担当者になる仕組みなので、受付の返信を誰が送るかを決めておかないと、担当者の割り振りが偶然で決まってしまいます。

補助になる機能もあります。
無料の範囲では、ノートは1チャットルームに1件まで、タグは1個まで（作れる種類は最大5個）で、有料のチャットProオプションで広げられます³。
無料の範囲なら、絞った使い方が合っています。
ノートには取引先ごとの納品先や締めの例外を書き留め、タグは「在庫確認中」のように、朝の処理で止まっている状態を一つだけ示す、といった使い方です。
このほか、定型文を作っておけば文章を入力せずに返信を送れます。
Web版では、チャットルームの中でメッセージを検索できます³。

費用がかかるのは配信であって受信ではない

LINEで注文を受け始めると、メッセージ通数の上限を気にする人がいます。
LINE公式アカウントの料金ページでは、通数は「送った回数×送った友だちの数」で数えるとされています。
また、LINEチャットの送受信や自動応答メッセージは無料で活用できると記載されています¹。
つまり、次のような朝の受注のやり取りそのものは、公式の記載上は通数を消費しません。
取引先から届く注文を受け取ること、担当者がチャットで返信すること、時間外に応答メッセージが自動で返ることです。

通数を使うのは、友だち全員などに向けて送る配信です。
2026年時点の月額固定費と月の無料メッセージ通数は次のとおりです¹。
コミュニケーションプランが0円・200通、ライトプランが5,000円（税別）・5,000通、スタンダードプランが15,000円（税別）・30,000通です。
受付ルールの変更を全取引先へ一斉に配信すると、1回の配信で友だちの数だけ通数が減ります。
朝の受注を整える作業でプランを上げる必要が出てくるのは、受注のやり取りが増えたときではありません。
こうした配信の量が増えたときです。

▼ 図の内容を文字で読む

• 応答時間内
  • 手動チャットに応答メッセージなどを組み合わせる
  • 担当者が在庫を確かめて確定連絡を送る
• 応答時間外
  • 応答メッセージなどで自動で返す
  • 受け取ったことと次に対応する時刻を伝える
  • 応答状況の表示が時間外用に切り替わる

受付時刻・締め・返信目安のルールで朝の山をならす

時間外の自動返信で伝えること

応答時間と応答メッセージを設定すると、夜に届いた注文にも自動で返事が返ります。
ここで大切なのは、自動返信で伝えられるのは「メッセージが届いた」ことと「次にいつ返事が来るか」の案内までだという点です。
在庫があるか、希望日に出せるかは、翌朝に担当者が確かめるまで分かりません。

そのため、時間外の応答メッセージには、注文が確定したと読める言い回しを入れないほうが安全です。
入れておきたいのは次の4点です。

• メッセージを受け取ったこと
• 確認と確定の連絡を送り始める時刻
• 当日出荷に間に合う締め時刻と、締めを過ぎた注文の扱い
• 急ぎの場合や訂正の連絡先

文面の例は次のような形です。
「ご注文のメッセージを受け取りました。
在庫の確認と確定のご連絡は、翌営業日の◯時から順にお送りします。
当日出荷は◯時までのご注文が対象です。」

この返信で変わるのは、担当者が感じる「早く返さなければ」という圧力です。
取引先は注文が届いたことを知っているので、朝いちばんに受付の返事だけを急いで送って回る必要がなくなります。
確定連絡も、1件ずつ落ち着いて作れます。
一方で、朝にたまっている件数、つまり山の高さは、自動返信だけでは変わりません。
山そのものを低くするには、締め時刻の考え方が必要です。

締め時刻を決めるときの考え方

締め時刻は、注文を「今日の処理分」と「次の処理分」に分ける線です。
線を引く位置によって、朝の山の形が変わります。

たとえば、翌朝出荷の分を前日の夕方で締める方法があります。
締めまでに届いた注文は前日のうちに読み取りと在庫確認を済ませられるので、朝に残るのは締め後に届いた分だけになります。
当日出荷の受付を、朝の一定時刻で締める方法もあります。
こちらは朝の処理に終わりの時刻ができるので、締め後の注文を翌日の処理へ落ち着いて回せます。
どちらが合うかは、集荷や配達の時刻、1件の処理にかかる手数、取引先が普段いつ発注しているかで変わります。

取引先の発注時刻は、こちらの都合だけでは動きません。
夜に自分の店を閉めてから発注する取引先にとって、前日夕方の締めは受け入れにくいかもしれません。
締めがどこまで守られるかは取引先しだいで、前もって確かな見通しは立ちません。
そこで、最初から全取引先に厳しい締めを課すのではなく、数えた受信時刻の散らばりを見て、すでに多くの注文が届いている時刻の近くに線を引くことをおすすめします。
そのほうが、取引先の行動を大きく変えずに済みます。

取引先への告知の順序

ルールを変えるときに避けたいのは、ある朝いきなり応答メッセージの内容が変わっていて、取引先がそこで初めて締めの存在を知るという伝わり方です。
次の順で伝えると、取引先が発注の予定を組み直す時間を取れます。

1. 注文の多い取引先へ、変更日・新しい受付時刻と締め・例外の連絡先を、個別のトークで前もって知らせる
2. 変更日に、応答メッセージとあいさつメッセージを新しい内容へ書き換える
3. そのほかの取引先へは、変更後に注文が届いたときの返信に添えるか、必要なら配信で知らせる

個別のトークで送る連絡はチャットの送受信にあたり、料金ページの記載上は通数を使いません¹。
一方、友だち全員に向けた配信は、友だちの数だけ通数を使います。
注文の多い取引先から順に個別に伝え、残りを配信でまとめるというように手段を分ければ、通数の消費も抑えられます。

▼ 図の内容を文字で読む

1. 注文の多い取引先へ個別のトークで知らせる
   • 変更日・新しい受付時刻と締め・例外の連絡先
   • 個別のトークは通数を使わない
2. 変更日に応答メッセージとあいさつメッセージを書き換える
   • 新しい内容に差し替え、オンになっているかも見る
3. そのほかの取引先へ知らせる
   • 変更後の注文への返信に添える
   • 配信は友だちの数だけ通数を使う

注文の書き方を揃える：定型文・リッチメニュー・キーワード応答の使いどころ

書式を決めて、定型文で見本を返す

文面のばらつきが朝の負担の中心なら、手当ては注文の書き方を揃えることです。
ここで混同しやすいのが、チャットの定型文です。
定型文は、担当者が文章を入力せずに送るための機能です³。
取引先に入力の書式を守らせる機能ではありません。
ただし、書式の見本を取引先へ渡す道具としては役に立ちます。

書式は、朝の読み取りで迷う項目から逆算して決めます。
数えたときに聞き返しが多かった項目が、書式で最初に固定したい項目です。
たとえば次のような形です。

【注文】
届け先：
納品希望日：
品目・数量：（1行に1品目）
備考：

「1行に1品目」と決めるだけでも、品目と数量を表へ写すときに、行をそのまま対応させられます。
届け先と納品希望日を独立した行にすれば、複数の届け先を持つ取引先の注文で、どこへいつ出すかを文中から探す手間が減ります。
この見本を定型文に登録しておけば、書式から外れた注文が届いたとき、確定連絡に「次回からこの形でお送りいただけると確認が早くなります」と添えて返せます。
聞き返しのたびに説明を打ち直さずに済みます。
同じ見本をあいさつメッセージにも入れておけば、新しい取引先には最初から届きます。

リッチメニューの動作と制約

トーク画面に常に表示されるメニューを使う方法もあります。
リッチメニューはトーク画面の下部に表示され、タップ領域ごとにポストバックの送信やURLを開くといった動作を割り当てられます⁶。
「注文のしかた」の領域から、書式や受付時刻をまとめたページを開けるようにしておけば、取引先は迷ったときに自分で確かめられます。

注意したいのは、デスクトップ版（macOS、Windows）のLINEではリッチメニューが表示されないことです⁶。
事務所のパソコンから発注する取引先には、メニューに置いた案内が見えません。
パソコンで注文する取引先がいるなら、書式の案内をリッチメニューだけに頼らず、定型文やあいさつメッセージでも同じ内容を届けておく必要があります。

ポストバックは、タップされた内容を受け取った側のプログラムが処理する前提の動作です。
標準機能だけで運用している段階では、URLを開く動作のほうが扱いやすいでしょう。
また、表示されるリッチメニューには優先順位があり、ユーザー単位の設定、Messaging APIで設定した既定、管理画面で設定した既定の順になります⁶。
後でMessaging APIを使い始めたとき、管理画面で作ったメニューが表示されなくなることがあるのはこのためです。

キーワード応答が向く場合・向かない場合

応答メッセージには、届いたメッセージ全体に同じ文面を返す使い方のほかに、特定の言葉に反応して返すキーワード応答があります。
登録した言葉に一致したメッセージに反応させる機能なので、「注文方法」「締め時刻」のように、決まった言い方で聞かれる質問への返事に向いています。
反対に、品目名や数量が毎回違う自由な文面の注文を読み取り、内容に合わせて返す用途には向きません。
注文の中身を読み取る作業は、書式を揃えたうえで人が行うか、次に説明する仕組みに任せることになります。

書き方の統一が効きやすいかどうかは、扱う品目の性質でも変わります。
品目が少なく注文の形が毎回似ている店なら、書式の見本やメニューで揃えやすいでしょう。
一方、品目の組み合わせが多く、単位や規格の指定が細かい注文では、書式を決めても書き方の揺れが残りやすいと考えられます。
揺れが残った部分を人が読み取る負担は、書式だけでは消えません。

受信から集計までを仕組みに任せる：Messaging APIで必要になる準備と運用負担

受信サーバーに必要なもの

書き方を揃えても、トークから集計表への転記が朝の大部分を占めるなら、受信内容を自動で表へ流す仕組みが候補になります。
LINE公式アカウントでは、Messaging APIを使います。
Messaging APIは、外部のプログラムからLINE公式アカウントのメッセージを扱うための仕組みです。
取引先がメッセージを送ると、LINEプラットフォームが指定のWebhook URLへHTTP POSTで通知します⁴。
Webhook URLは、通知を受け取るサーバーの住所にあたるURLです。

用意するものは次のとおりです⁴。

• Messaging APIチャネル
• ボット（受信して処理するプログラム）を動かすサーバー
• HTTPSのWebhook URL（広く信頼された認証局が発行したSSL/TLS証明書が必要で、自己署名証明書は使えない）
• チャネルアクセストークン（APIを呼び出すための認証情報）

Webhook URLに設定できるエンドポイントは1つだけです⁴。
集計表への書き込みに加えて、別の仕組みにも同じ注文を渡したくなったときは、受け取ったサーバーの中で振り分ける設計が必要になります。
また、サーバーが受け取るのは取引先が送った文面そのものです。
それを品目・数量の行に分ける処理は、自分たちで作ることになります。
書式が揃っていないと、この分解が難しくなります。
書き方の統一は、仕組み化の前提でもあるわけです。

重複・順序・再送の扱い

自動で表へ書き込むようになると、人が転記していたときには起きなかった種類の間違いに備える必要が出てきます。
受信の仕様として、次のことが示されています⁵。

• Webhookのイベントは重複して届くことがあり、webhookEventIdで重複を検出できる
• 再送によって届く順序が入れ替わることがあり、timestampで前後を確かめられる
• 再送の機能は初期状態では無効で、有効にしたうえでサーバーが200番台以外の応答を返したときに再送される。
  確実に再送されるとは限らない

これを注文の集計に当てはめると、意味ははっきりしています。
webhookEventIdを記録して照らし合わせなければ、同じ注文が表に2行入る二重登録が起こりえます。
取引先が注文の直後に「さっきの数量を訂正します」と送った場合、届いた順に処理すると訂正が先に入ってしまうかもしれません。
そのため、timestampで前後を判断する必要があります。
再送が無効のままサーバーが止まっていれば、その間の通知は届き直しません。
再送の回数や間隔は公開されておらず、変わることもあります⁵。
再送に頼り切らず、集計表の件数を人の目で突き合わせる確認を当面は残しておくのが現実的です。

自動応答との併用で気をつけること

標準機能で作った時間外の応答メッセージを、そのまま残してよいかも考えておく必要があります。
開発者向けの手引きでは、初めてボットを作るときは、あいさつメッセージと応答メッセージの設定をオフにすることが推奨されています⁴。
両方が動いていると、取引先に届いた返事が管理画面の自動応答から来たのか、自分たちのプログラムから来たのかを見分けにくくなるためと考えられます。

オフにすれば、時間外に「受け取りました、確定は朝に送ります」と返していた働きも止まります。
仕組みに移すときは、切り替えの前に決めておくことがあります。
その受付返信をサーバー側で作り直すのか、どこまでを管理画面の機能に残すのか、という点です。
あいさつメッセージに書いていた書式の見本も同じで、オフにした後は、新しい取引先へどこで伝えるかを決め直す必要があります。

自動集計は人の転記をなくす代わりに、設計と保守の手間を生みます。
具体的には、サーバーの稼働、証明書やトークンの管理、重複と順序の扱いです。
転記の手間が保守の手間に置き換わると考えると、自社で受け持てるかどうかを判断しやすくなります。

▼ 図の内容を文字で読む

1. 取引先が注文を送る
   • 取引先が送った文面そのものが届く
2. LINEプラットフォーム
   • Webhook URLへHTTP POSTで通知する（URLは1つだけ）
   • 再送は初期状態で無効
3. 受信サーバー
   • webhookEventIdで重複を見分ける
   • timestampで前後を確かめる
   • 文面を品目・数量の行に分ける
4. 集計表
   • 件数を人の目で突き合わせる

ルールで足りるか、仕組みが要るか：3系統の選び分け

3系統の比較表

ここまでの手当てを、同じ軸で並べます。
受付ルール、書き方の統一、Messaging APIによる自動集計の3系統について、どれが優れているかではなく、どの要因に効き、何が残るかを比べています。

表で判断が分かれるのは「残る手作業」の行です。
受付ルールと書き方の統一は、どちらも標準機能の設定で始められます。
チャットの送受信や自動応答の範囲であれば、通数の費用も増えません¹。
ただし、転記はどちらでも残ります。
3系統のうち転記を減らせるのは自動集計だけですが、そのためには準備と保守が必要になり、在庫の確認と確定連絡はなお人の仕事として残ります。
受信を自動化しても、在庫の照合まで自動になるわけではありません。

3系統は、順番に積み重ねられる関係にもあります。
受付ルールで山の時刻を整え、書式で文面を揃えたうえで自動集計に進めば、サーバーが受け取る文面も分解しやすくなります。
逆に、書式が揃わないまま自動集計を入れると、表に入った行を人が読み直す作業が残りやすくなります。

仕組み化を検討する4つの判断条件

何件を超えたら仕組み化すべきか、という一般的な基準は示せません。
代わりに、ルールと書式を試したあとで、次の4つを見ます。

1. 締めを設けた後も、朝の処理時間内に終わらない件数が続けて残るか
2. 書式を揃えても、品目や数量の読み取りで迷う注文が残るか
3. 在庫の確認が、転記とは別の作業として重いか
4. 受信サーバーを保守できる人が社内にいるか、保守を任せる先があるか

1つ目と2つ目が続けて当てはまるなら、人の手順を整えるだけでは朝の負担が下がりきっていません。
仕組み化を検討する段階です。
3つ目は、仕組み化の範囲を決める条件です。
在庫確認が重い場合、受信を表へ流すだけでは朝の重い部分が残ります。
在庫表との照合まで設計に含めるのか、在庫確認は人が続けるのかを分けて考える必要があります。

4つ目が当てはまらない場合は慎重に考えます。
自動集計を入れても、止まったときに直せず、重複や取りこぼしの確認がかえって増える恐れがあるためです。
その場合は、ルールと書式の段階で朝をどこまで軽くできるかを先に詰めるほうが確実です。

最初の1週間の試し方と、取引先への伝え方・確かめ方

1週間の進め方

最初から全部を変えずに、1週間で「数える・設定する・試す・数え直す」の流れを回すことをおすすめします。

1. 1日目：前日の受付終了から当日の処理開始までの受信時刻、注文文面の型、1件あたりの手順を数える。
   あわせて、朝の処理時間、見落とした件数、転記を直した件数を記録しておく
2. 2〜3日目：応答時間と時間外の応答メッセージを設定し、あいさつメッセージの内容とオン・オフを見直す
3. 4〜5日目：要対応・対応済みと担当者でチャットを管理し、書式の見本を注文の多い数社に試してもらう
4. 6〜7日目：1日目と同じ項目を数え直し、設定前と比べる

1週間のうちに、新しい締めまで始める必要はありません。
時間外の自動返信は取引先の発注のしかたを変えないので、先に始められます。
締めの変更は、数え直しの結果を見たうえで、告知の順序を踏んでから入れるほうが無理がありません。

取引先への変更も、全社一斉ではなく数社から始めます。
書式の見本を最初に渡す相手には、注文が多く、普段からやり取りの多い取引先が向いています。
受け入れられ方は前もって分からないので、まず試した数社の反応を見ます。
そのうえで見本の項目や締めの時刻を直し、ほかの取引先へ広げる順にすると、全体を変えた後でやり直すより手戻りが小さく済みます。

うまくいったかの確かめ方

比べるのは、1日目に記録した3つの数です。
朝の処理時間は、処理を始めてから要対応がなくなるまでの時間で測ると、毎日同じ物差しになります。
見落とした件数は、昼以降や翌日に気づいた未処理の注文の数です。
転記を直した件数は、集計表や出荷表を後から修正した回数です。
聞き返した件数も、書き方の統一が効いたかを見る手がかりになります。

数が減った項目と減らなかった項目を分けて見ると、次の手当てが決まります。
処理時間が縮んでも転記の修正が減らないなら、文面か転記の手順に原因が残っています。
見落としが減らないなら、要対応のまま放置されたチャットがないか、担当者の割り振りが偶然で決まっていないかを見直します。
1週間の数え直しは、効果を保証するものではありません。
自分の店で何が効き、何が残ったかを確かめるためのものです。
残った部分が転記で、仕組み化の判断条件にも当てはまるなら、そこが仕組み化を考える出発点になります。

朝の詰まりが届く時刻・文面・手作業のどれから来ているかは、受信時刻の記録と転記の手順を並べてみないと判断しにくく、自分だけで数えると見落としが出やすいためです。

数えた受信時刻と注文文面をもとに、応答時間・締め時刻・書式のどこから手を付けるかを一緒に整理できます。無料相談で要件を整理する

要点の整理

軸	基準
朝の山が高い	応答時間と時間外の応答メッセージで受付の返事を自動化し、締め時刻で今日の処理分と次の処理分を分ける
文面がばらつく	聞き返しの多い項目から書式を決め、定型文とあいさつメッセージで見本を渡す。リッチメニューはデスクトップ版LINEでは表示されない
転記が重い	書式が揃ってからMessaging APIを検討する。重複はwebhookEventId、順序はtimestampで扱い、件数の突き合わせを残す
費用	チャットの送受信と自動応答は通数の対象外。一斉配信は送った回数×友だちの数で通数を使う
効果の確かめ方	朝の処理時間・見落とした件数・転記を直した件数を、1日目と6〜7日目で比べる

Messaging APIによる自動集計に進むかどうかは、書式の揃い具合と社内で保守を受け持てるかによって変わり、導入後に設計を直すと手戻りが大きいためです。 自動集計に進む前に、書式の決め方や、重複・順序・取りこぼしへの備えとして何を決めておくべきかを確かめられます。

よくある質問

LINEで注文を受けて返信するだけなら、通数の無料枠は使いますか。

LINE公式アカウントの料金ページでは、LINEチャットの送受信と自動応答メッセージは無料で活用できると記載されています¹。
注文を受け取ってチャットで返信するやり取りは、記載上は通数の対象になりません。
通数は「送った回数×送った友だちの数」で数える配信にかかるため、ルール変更の案内などを友だち全員へ配信したときに減ります。

時間外に届いた注文へ自動で返信しつつ、朝に担当者が個別返信するには、どう設定しますか。

応答時間を営業時間に合わせて設定し、時間外に使う応答メッセージに、受け取ったことと確定連絡を送り始める時刻を書いておきます。
応答時間内は手動チャットを応答メッセージなどと組み合わせられます²。
朝は要対応のチャットを上から開き、在庫を確かめて担当者が確定連絡を返し、済んだものを対応済みに移します。
時間外の自動返信には、注文が確定したと読める言い回しを入れないほうが安全です。

リッチメニューは、パソコン版LINEで注文する取引先にも表示されますか。

表示されません。
リッチメニューはデスクトップ版（macOS、Windows）のLINEでは表示されないためです⁶。
パソコンから注文する取引先には、書式や受付時刻の案内を、定型文での返信やあいさつメッセージでも届けておく必要があります。

Messaging APIで受信を自動化するとき、同じ注文が二重に登録されるのをどう防ぎますか。

Webhookのイベントは重複して届くことがあり、webhookEventIdで検出できます⁵。
受け取ったwebhookEventIdを記録し、集計表へ書き込む前に同じIDがないかを照らし合わせれば、同じ通知による二重登録を防げます。
再送で順序が入れ替わることもあるため、訂正のメッセージを扱うときはtimestampで前後を判断します⁵。
なお、取引先が同じ注文を2回送ってきた場合は別々のイベントになるので、IDでは見分けられません。
内容の確認が別に必要です。

担当者が複数いる場合、注文トークの対応漏れをどう分担して防ぎますか。

チャットには担当者を設定でき、未設定のチャットでは最初に送信したメンバーが担当者になります³。
受付の返信を誰が送るかを決めておかないと、割り振りが偶然で決まってしまいます。
取引先ごとに担当者を先に設定しておくか、朝に要対応の一覧を見て振り分けるかを決めておきます。
担当者は後から変更でき、要対応・対応済みの振り分けと組み合わせれば、未処理のチャットを担当者ごとに追いやすくなります³。

取引先にルール変更を伝えるとき、応答メッセージ以外に何を併用すべきですか。

注文の多い取引先には、変更日・新しい受付時刻と締め・例外の連絡先を、個別のトークで前もって知らせると、取引先が発注の予定を組み直せます。
新しく友だち追加する取引先には、あいさつメッセージが最初の案内になります。
内容を書き換え、オフになっていないかも見ておきます。
オフにすると、保存していても配信されません²。
友だち全員への配信も使えますが、こちらは送った回数×友だちの数で通数を使います¹。

1. 1　出典：LINEヤフー株式会社「LINE公式アカウント 料金プラン」（2026年）
2. 2　出典：LINEヤフー株式会社「LINE Official Account Manager 応答設定マニュアル」（2026年）
3. 3　出典：LINEヤフー株式会社「LINE Official Account Manager チャット マニュアル」（2026年）
4. 4　出典：LINEヤフー株式会社「LINE Developers Messaging API ボットを作成する」（2026年）
5. 5　出典：LINEヤフー株式会社「LINE Developers Messaging API メッセージ（Webhook）を受信する」（2026年）
6. 6　出典：LINEヤフー株式会社「LINE Developers リッチメニューの概要」（2026年）
7. 7　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年公開・2026年更新）