LINE Messaging APIのエンドポイントエラー：末尾のスラッシュを確認

LINE Messaging APIへのリクエストには、公式リファレンスに記載された正確なエンドポイントを使ってください。パスの末尾にスラッシュを追加したり、変更したパスが同じように動くと考えたりしないことが重要です。LINEは、余分な末尾の / を含む不正確なエンドポイントについて、動作を保証しないと明記しています。認証情報や本文、Webhook設定を変える前に、HTTPクライアントが実際に送信するURLを確認しましょう。

要点

• 設定画面のURLだけでなく、最終的な送信メソッド、ホスト、パスを確認します。
• LINEの注意事項は、誤ったパスに対する特定のステータスコードやリダイレクトを保証していません。
• APIの送信先と、自分のWebhook受信URLは別の境界です。
• URLを修正しても、以前タイムアウトしたメッセージが未送信だったとは証明できません。

末尾スラッシュに関するLINEの説明

LINEは2026年8月17日のエンドポイントに関する注意事項で、Messaging APIリファレンスに記載された正確なエンドポイントの使用を求めています。余分な末尾スラッシュも明示的に挙げられています。これはAPIの利用条件の説明であり、特定の障害の報告でも、常に 404 が返るという告知でもありません。

現在のMessaging APIリファレンスには、次のパスが記載されています。

操作	記載されたメソッドとパス	追加しないもの
応答メッセージの送信	POST /v2/bot/message/reply	末尾の /
プッシュメッセージの送信	POST /v2/bot/message/push	末尾の /
メッセージ上限の取得	GET /v2/bot/message/quota	末尾の /

これはパス構文の例であり、操作を相互に置き換えてよいという意味ではありません。各操作の認証と本文の要件を守り、応答リクエストが失敗しただけでプッシュに切り替えないでください。

LINEは、正しいエンドポイントURLを構築するために公式SDKの使用も勧めています。ただし、独自の通信層、プロキシ、アプリケーションのラッパーがある場合は、その最終出力も確認する必要があります。

実際の送信リクエストを点検する

以下は推奨する調査手順であり、確認済みのLINE障害原因の一覧ではありません。

1. 失敗した操作を特定する。 アプリからLINEを呼び出しているのか、LINEからWebhookを受信しているのかを区別します。対象操作のメソッドと公式の送信先を書き出します。
2. URLの組み立てを確認する。 ベースURL設定、パス連結、ノーコードのHTTPノード、自動でスラッシュを補う共通関数を調べます。組み立て後の値をリファレンスと一文字ずつ比較します。
3. 最後に送信するコンポーネントを見る。 送信プロキシやミドルウェアがパスを書き換える場合、その宛先をアプリ側の値と比較します。設定値が正しくても、後段で変更される可能性があります。
4. 機密情報を除いた証拠を残す。 メソッド、ホスト、パス、確認時刻、HTTPステータス、機密情報を除いたエラーレスポンスを保存します。認証ヘッダー、アクセストークン、応答トークン、顧客のメッセージ本文は記録しません。
5. 確認できた差分だけを修正する。 キーの更新、宛先の変更、Webhook URLの交換を同時に行わないでください。再テストが成功しても原因を特定できなくなります。

「すべてのスラッシュを削除する」という共通ルールは作らないでください。ホストの区切りと文書化されたパス構造を保ち、対象操作のURL生成を修正します。

残る症状に合わせて調査先を変える

観測したこと	次の調査
最終パスがリファレンスと異なる	リクエスト生成を修正し、ローカルで出力を確認
メソッドとパスは正しいが拒否される	実際のレスポンス、認証情報、操作固有の本文を確認
LINE DevelopersコンソールのVerifyが失敗	pushの送信先ではなく、自分の受信URLとハンドラーを確認
送信がタイムアウトする	再送前に結果不明として保持

空の検証データを受信ハンドラーが拒否する場合は、LINE Webhook Verifyと空のeventsの解説を参照してください。これは自分のサーバーに届くリクエストの問題であり、LINE APIの送信先に余分なスラッシュを付ける問題とは異なります。

リトライキー対応の送信でタイムアウトした場合は、別のLINEリトライキー手順に従います。LINEのリトライ文書では、対応する操作の最初のリクエストからキーを指定する必要があります。パスを修正しても、キーなしで送った過去の試行を後から保護することはできません。URL形式のテストだけを目的に本番メッセージを再送しないでください。

UnifyPortの送信先は別に扱う

UnifyPortの非公式インターフェースは、接続済みメッセージングアカウント向けの独立したAPIです。テキスト送信リファレンスでは POST /v1/messages を使用し、本文に account_id、to、message を含め、X-Api-Key で認証します。接続先がLINEでも、LINE Messaging APIのエンドポイントではありません。

正確な送信先を確認する原則は両方に有効ですが、LINEのパス、認証情報、リトライ保証をUnifyPortに持ち込まないでください。送信者がLINE公式アカウントである必要がある場合は、公式Messaging APIを使います。別の連携方式に変えても、以前の公式リクエストが受理されたかどうかは分かりません。

回帰チェックとFAQ

余分なスラッシュがあると必ず404になりますか？

LINEの注意事項はそのような保証をしていません。実際のレスポンスを調べ、文書化されたエンドポイントを使ってください。

自分のWebhook URLの末尾スラッシュも削除すべきですか？

この注意事項だけでは判断できません。受信URLは自分のサーバーのルーティングに合わせます。LINEの説明はMessaging APIへのリクエストに関するもので、あらゆるWebサイトやWebhook URLに共通する規則ではありません。

修正の公開前に何をテストしますか？

まず実際には送信せず、各操作の最終メソッドとURLを検証します。末尾スラッシュあり・なしのベース設定、共通HTTPラッパー、本番プロキシ設定を確認します。エンドツーエンドの確認が必要なら、管理下のアカウントで意図したテスト操作を実施します。これらは提案する確認項目であり、実施済みの結果ではありません。

次のステップと出典

失敗した送信リクエストを1件選び、LINE Messaging APIリファレンスと比較してください。独立したUnifyPort連携では、テキスト送信仕様を使います。

公式資料の確認日：2026-11-03。

• LINE：2026年ニュース内の8月17日のエンドポイント注意事項
• LINE：Messaging APIリファレンス
• LINE：失敗したAPIリクエストのリトライ