LINEの動画メッセージが再生できないとき|送信成功・URL・端末の確認順
この記事の結論
Messaging APIで動画を送信できても、端末で再生できるとは限りません。動画とプレビューのURL、形式と容量、アスペクト比、視聴完了イベントの条件を分けて確認し、同じ動画を再送する前の調べ方を説明します。
最終更新:2026年10月15日
Messaging APIで動画メッセージの送信に成功しても、相手の端末で動画を最後まで再生できたことにはなりません。プレビュー画像が出ない、画像は出るが再生できない、一部だけ表示が欠ける、という症状を分けて調べます。
この記事の対象は、type: videoの動画メッセージです。LINE Official Account Managerからの動画配信や、動画を組み込んだFlex Messageにはそれぞれの仕様があるため、同じ入力項目として扱わないようにします。
動画本体とプレビュー画像を別々に確認する
公式のメッセージタイプの説明では、動画メッセージには動画ファイルとプレビュー画像の二つのURLを指定します。ユーザーがプレビューをタップすると、動画が再生されます。
動画本体を指定するoriginalContentUrlと、トークに出る画像を指定するpreviewImageUrlは役割が異なります。画像だけ表示される場合に、画像URLだけを開いて「動画も正常」と判断しないことが最初の確認です。
それぞれのURLがログイン画面やエラーページではなく、目的のファイルを返すかを確認します。管理者としてログインしたブラウザで開けるだけでは、送信に使うURLの検査として不十分な場合があります。公開してよい確認用素材を使い、顧客の動画を調査のために一般公開する方法は避けます。
形式・容量と、見た目の比率を分ける
動画メッセージのリファレンスで、次の条件を確認できます。2026年10月15日の確認内容です。
| 対象 | 形式・容量 | URLの条件 |
|---|---|---|
| 動画本体 | mp4、最大200MB | HTTPS、TLS 1.2以降 |
| プレビュー | JPEGまたはPNG、最大1MB | HTTPS、TLS 1.2以降 |
URLはどちらも最大2,000文字で、公式のURLエンコードの条件も確認します。拡張子を.mp4に変えただけで動画の中身が対応形式になるわけではありません。
動画とプレビュー画像のアスペクト比も合わせます。比率が違うと、動画の背面にプレビューが見えることがあります。また、極端に縦長・横長の動画は、一部の環境で表示が欠ける場合があります。「画面が欠ける」問題なら、送信のHTTPステータスだけを調べ続けず、素材の比率と実際の表示を照合します。

条件を満たしていても、端末での再生を確認する
公式FAQも、送信に成功した動画がユーザーの端末で正しく再生できない場合があると案内しています。ファイルの条件を満たしたことと、配信先で使えることは分けて確認します。
担当者は、問題が出る端末・OS・LINEのバージョン、プレビューの表示、タップ後の状態、同じ素材が別端末で再生できるかを記録します。全端末で再生できない場合と、一部端末だけの場合を同じ原因にまとめません。調査記録に、動画そのものや顧客の個人情報を入れる必要はありません。
再現できる確認用素材で比較し、一つずつ条件を変えます。短い動画への差し替えで再生したとしても、それだけで元の失敗原因が容量だと断定せず、形式など同時に変わった点を確認します。
視聴完了イベントがないことを「見ていない」と決めない
動画メッセージには任意のtrackingIdを付けられます。公式仕様では、これを付けた動画の視聴が完了すると、動画視聴完了イベントが発生します。ただし、グループトークや複数人トーク宛てには、このプロパティを使えません。
イベントが記録されない場合は、対象のメッセージに識別用のIDを付けたか、送信先が対応するトークか、Webhookを受け取って記録する処理が動いているかを先に確かめます。未設定や取得漏れを含んだ状態で、顧客が動画を見ていないと決めつけないようにします。視聴完了も、説明への同意や申込完了を表すものではありません。
再送前に、代わりに伝える内容を用意する
たとえば商品の使い方を案内する動画が開けない場合は、重要な手順を短い文章や画像でも案内できると、相手の確認を止めずに済みます。これは架空の運用例であり、説明が動画だけに閉じていないかを見直す判断です。
同じ動画を連続で再送する前に、止まった段階と確認した条件を担当者の間で共有します。画像メッセージのURL確認と同様に、素材・表示・受け手の確認を分けることで、顧客に同じ操作を繰り返し頼まずに次の対応を決められます。