LINEのメッセージ検証APIで何が分かる？｜200成功と送信・到達を分ける

LINEのメッセージ検証APIで200が返っても、メッセージを送信したことや、相手に届いたことの確認にはなりません。検証する対象は、送信リクエストのmessagesへ入れるメッセージオブジェクトの配列です。

文面やFlex Messageを変更する開発では、形式の誤りを先に見つけるために使います。その後の実送信と、相手側の表示は別の段階として確認します。送信方式の選択から確認したい場合は、Messaging APIの送信方法を参照してください。

実際に使う送信方法に対応した検証先を選ぶ

公式APIリファレンスには、reply・push・multicast・narrowcast・broadcastそれぞれのメッセージ検証エンドポイントがあります。

たとえば、返信用なら/v2/bot/message/validate/reply、プッシュ用なら/v2/bot/message/validate/pushです。HTTPメソッドはPOSTで、JSONのmessagesに、検証したい配列を指定します。Authorizationには対応するチャネルアクセストークンが必要です。

返信として使うメッセージを検証するなら、返信に対応した検証先を選びます。「別の送信方法で検証が通ったから、どの送信でも使える」とせず、実際の送信方法を先に決める順番です。

確認用のメッセージは、個人情報のない内容で用意します。アクセストークンを画面のスクリーンショットや共有するJSONへ含めないようにします。この記事の説明のために、本番の送信APIを呼び出す必要はありません。

200は形式の検証成功、400は内容の修正が必要な結果

正常な検証では、200と空のJSONオブジェクトが返ります。無効なメッセージオブジェクトが指定された場合は400です。

400の場合は、まず送ろうとした配列とエラーの説明を照合します。複数の吹き出しを組み立てているなら、どのオブジェクトに問題があるかを確認します。修正前後の差が追えるようにし、同じ内容をそのまま繰り返し検証するのではなく、原因を直してから再確認します。

認証や接続のエラーは、メッセージの中身が無効という結果とは分けます。200を受け取っていない処理を、検証済みとして次の段階へ進めないようにします。

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

replyTokenや宛先は、検証の成功で保証されない

公式には、messages以外のプロパティの有効性は検証しないと説明されています。返信のreplyTokenや、プッシュの宛先toまで正しいと判断しないことが必要です。

たとえば、返信文面の検証が通っていても、返信トークンの期限や利用状態に問題があれば、返信は別に失敗し得ます。文面を直す作業と、返信に必要な条件を確認する作業を分けます。期限の確認は返信トークンの記事を使えます。

画像を含む場合も、形式の検証が通ったことだけで、意図した画像がすべての表示環境で見えたとは報告しません。URL、画像仕様、実画面を別に確認します。画像メッセージのURL確認と組み合わせると、形式と画像取得を混同せず調べられます。

変更した配列を、その後のテストでも使う

検証する文面と実送信する文面が違っていては、結果を引き継げません。運用する際は次の順番で確認します。

1. 送信方法と、送信するmessagesの内容を決める。
2. 対応する検証APIで確認し、変更した場合は再検証する。
3. 宛先や返信トークンなど、送信固有の条件を別に確認する。
4. 承認されたテスト先で送信結果と実画面を確認する。

検証成功、送信リクエストの成功、画面での受信確認は、記録でも分けます。プッシュの200と到達の違いはプッシュが届かない場合の確認も参照してください。

担当者には、検証した内容と、まだ確認できていない送信条件を残します。「検証済み」の一言で引き継ぐより、文面の確認が終わったのか、相手の画面まで確かめたのかが分かると、重複した調査や不用意な再送を減らせます。