LINEのナローキャストが202でも未完了？進行状況と再送前の確認

ナローキャストの送信APIがHTTP 202を返しても、お客様への送信が終わったという意味ではありません。受付後の処理を進行状況APIで確かめ、完了した場合も受信件数を確認します。結果がまだ分からないまま同じ内容を送り直すと、先に届いていた人へ重ねて送るおそれがあります。

この記事は、絞り込んだ対象への配信を確認する担当者と、確認画面を実装する担当者向けです。どの送信方法を使うかはMessaging APIの送信方法の違い、通信失敗時の再試行は再送とリトライキーの確認で別に説明しています。

最初に「受付」と「処理完了」を分ける

公式APIリファレンスの進行状況の説明にあるGET /v2/bot/message/progress/narrowcastへ、送信リクエストの応答ヘッダーで得たrequestIdを渡します。別の配信のIDを使わないよう、送信記録と一緒に確認してください。

返るphaseは、準備中のwaiting、送信中のsending、処理完了のsucceeded、失敗したfailedの4種類です。failedならfailedDescriptionの理由を読みます。succeededだけで、全員が受信した、読んだ、予約したという報告にはできません。

運用画面で「成功」という一語だけを出すと、次の担当が確認を終えたと思ってしまいます。「受付」「準備中」「送信中」「処理完了」「失敗」のように、確認した段階が分かる言葉を選びます。これは画面を設計するときの提案であり、既存のツールにこの表示が備わっていると主張するものではありません。

件数がないときは、0人として埋めない

受信成功数のsuccessCount、受信失敗数のfailureCount、予定人数のtargetCountは、応答に含まれない場合があります。特にwaitingではこれらの件数を取得できません。「未取得」を0へ変えると、誰にも送られなかったように見えます。

succeededでもfailureCountが0でなければ、受信できていない人がいます。一方、集計だけを見て、その人が誰か、どの顧客がブロックしたかを決めつけてはいけません。

たとえば架空の配信確認で、画面に「処理完了」とだけ出ている場合、担当は元の応答と件数の有無を確かめます。次の担当への引き継ぎは「全員に届きました」ではなく、「処理は完了。受信件数の確認は残っています」と、残る作業が分かる形にします。

再送前に見返す確認図

図解画像を開く（保存用）

確認が止まった場所を上から追うための図です。waitingとsendingは二つの進行状態で、担当者の役割や再送の許可を示す分類ではありません。図を手元に置く場合も、取得期限と件数が欠ける条件を本文で確認してください。

14日を過ぎた404は、未送信の証拠にしない

進行状況はacceptedTimeから14日、336時間以上経過すると取得できません。取得時に404が返る理由には、この期限超過と、ナローキャスト以外のリクエストIDの指定があります。

時間が経ってから見つからなかった配信を「送られていない」と扱うのは危険です。まず、そのIDと受付時刻が対象の配信に対応しているかを確認します。取得できるうちに確認結果を残し、後から分からなくなった点は未確認として引き継ぎます。

配信の担当画面には、対象の配信、受付時刻、確認時刻、進行状態、取得できた件数、未確認の理由をまとめると、別々の画面を行き来して判断する負担を減らせます。公開する資料や問い合わせ用のメモへ、アクセストークンや実顧客の情報を貼り付ける必要はありません。

次の行動を担当者まで決める

準備中・送信中なら、誰が次に進行状況を確認するかを決めます。失敗なら原因を実装担当へ渡し、再送が必要かを別に判断します。処理完了なら件数を確認し、届いた配信から来る質問を読める担当を用意します。

LINEの配信結果は、お客様との会話を始めるための確認材料です。送信件数だけを追って、届いた相談への返信が遅れる運用にならないようにします。次にすべきことは同じ配信をもう一度押すことではなく、今の状態と残る確認を一つずつ確かめることです。

※仕様の確認日：2026年10月11日。説明中の運用例は架空です。実際の配信、再送、顧客データの取得は行っていません。