LINEの画像メッセージが表示されないとき｜原画像・プレビューURLの確認

LINEへ画像メッセージを送って表示されないときは、原画像とプレビュー画像のURLを、別々に確認します。パソコンで画像が見えていても、ログイン済みの担当者にだけ見えるURLかもしれません。

ここではMessaging APIのtype: "image"を扱います。LINEで受け取った添付画像の保存は写真・ファイルの受信と保存を確認してください。リッチメッセージやFlex Messageの画像設定とも区別します。

同じ画像URLでも、役割と上限が違う

公式の画像メッセージの仕様では、原画像をoriginalContentUrl、プレビューをpreviewImageUrlで指定します。どちらもHTTPS、JPEGまたはPNGが対象ですが、最大ファイルサイズは原画像10MB、プレビュー1MBです。

原画像に合わせて大きいファイルを一つ用意し、そのURLを両方へ入れると、プレビュー側の条件を満たさない場合があります。URLの末尾が.pngでも、中身が別の形式なら画像形式を確認できたことにはなりません。実際に取得するデータを見ます。

画像メッセージの二つのURLを確認する図。原画像はJPEGまたはPNGで10MB以下、プレビューはJPEGまたはPNGで1MB以下。両方のURLでHTTPS、画像そのものの取得、ログイン画面でないことを確かめる。重要な案内は画像だけに入れない。

図：原画像とプレビューの条件を分けています。二つとも仕様と実際に返されるデータを確認します。

画像URLを開いたときにHTTP 200が返っても、応答内容がログイン画面や権限エラーのHTMLなら、画像が取得できた確認にはなりません。担当者のブラウザーで見える表示と、画像を取りに行く処理が受け取る内容を分けて調べます。

開発担当へは、次の三つを確認してもらいます。

顧客の写真や注文資料を、表示確認のために公開へ切り替えるのは避けます。検証には個人情報のないダミー画像を使い、機密の画像は承認された閲覧方法を別に設計します。「LINEで画像を送れる」と「誰でも取得できるURLへ出してよい」は別の判断です。

公式仕様では、URLはUTF-8によるパーセントエンコードの対象です。日本語を含むファイル名や、クエリ付きURLを作る場合は、実際の送信値が意図したURLになっているかを確認します。文字を見た目で置き換えるだけではなく、URLとして扱う処理を使います。

差し替え後に古いURLが送られていることもあります。作成画面の新しい画像だけを見るのではなく、送信したメッセージの設定と配信処理の入力を照合してください。URLに秘密値がある場合は、そのまま共有ログへ貼らず、担当者が正規の環境で確認します。

プレビューだけ見える、開くと見えないという場合も、片方だけを確認して終えないようにします。なお、公式には端末の状況によって原画像がプレビューとして使われる場合もあるため、常に同じ表示になると決めつけないでください。

営業時間、予約時刻、持ち物など、行動に必要な内容を画像だけへ入れると、画像が見えない人は次に何をすればよいか分かりません。短い本文にも重要な案内を残し、必要な情報を確認できるページへつなぎます。

問い合わせが来たときは、「画像を再度見てください」で止めず、求められた内容を文章でも返せるようにします。画像の原因調査は担当者の仕事として続け、お客様にログインや画面の往復を何度も求めない導線にします。

公開前の試験は、自社が許可した送信先と範囲で行います。原画像とプレビューが仕様を満たす確認、APIの応答、実際の端末表示を別々に残してください。本稿を読むだけで実送信や端末での表示確認が済むわけではありません。

※仕様の確認日：2026年10月8日。画像の上限と形式は公式資料に基づき、調査・案内の手順は運用の提案です。