LINE APIでできること・できないこと。送信・会員連携の条件を整理【2026年】

LINE APIを使うと、顧客からのメッセージへの自動応答、会員情報との連携、予約や発送の通知などをシステムに組み込めます。ただし、ユーザーを識別できること、送信対象になること、実際にメッセージが届くことは別です。

「LINEログインで取得したIDへ、いつでも通知できる」「送信APIが成功したので顧客が確認済み」といった前提は、業務の取りこぼしにつながります。本記事では、日本向けのLINE連携を発注する際に確認したい機能と条件を整理します。公式仕様の確認日は2026年9月8日です。

まず、どの仕組みが担当する機能かを分ける

LINE APIという名称だけでは、開発範囲は決まりません。公式アカウントからのメッセージにはMessaging API、LINEアカウントによる認証にはLINEログイン、操作画面にはLIFFやLINEミニアプリと、自社のWebシステムを組み合わせます。LINE WORKSは別製品のAPIとして扱います。

実現したいこと	主に使う仕組み	LINE側に任せられない業務
問い合わせへの自動応答	Messaging APIのWebhookとReply	回答内容の管理、対象外の質問の有人引き継ぎ
発送・予約変更などの個別通知	業務システムとPush等	送信対象の決定、通知履歴、未確認時の対応
顧客の条件に応じた配信	自社DBとMessaging APIの送信手段	会員とLINEユーザーの対応付け、抽出条件の管理
会員証・予約・注文の画面	LIFFまたはミニアプリとWebサーバー	会員の権限、空き枠管理、注文や取消の処理
自社会員とのアカウント連携	LINEログイン、またはMessaging APIの連携機能	既存会員の本人確認、重複連携・解除のルール
配信や画面の効果測定	LINEの統計と自社サイトの計測	申込完了との対応、指標の定義、集計条件の統一

部品の関係から確認したい場合はLINE開発の全体地図、LIFFとミニアプリの選択は方式比較を参照してください。ミニアプリのサービスメッセージには独自の認証・用途条件があり、以下のMessaging APIのPush条件をそのまま適用するものではありません。

Pushは「友だちだけ」でも「IDがあれば誰でも」でもない

Messaging APIのPushで送信対象にできるのは、次のいずれかです。

送信元のLINE公式アカウントを友だち追加しているユーザー。
その公式アカウントが参加しているグループトークまたは複数人トーク。
1対1のトークで、その公式アカウントへ7日以内にメッセージを送ったユーザー。

3つ目は、友だち追加をしていないユーザーにも当てはまります。一方、ブロックしたユーザーなどではHTTPステータスが200でもメッセージは届きません。Pushの対象条件と不達時の扱い

この仕様を、業務の判断に置き換えると次のようになります。

顧客の状態	企画上の判断	用意する運用
公式アカウントを友だち追加している	Pushの対象条件に該当する	連絡先として使う目的と通知内容を整理する
友だちではないが、1対1で昨日問い合わせてきた	7日以内の条件に該当する	問い合わせへの対応期間と継続連絡の導線を決める
友だちではなく、3週間後の予約通知を送りたい	過去の問い合わせだけでは継続送信の前提にできない	友だち追加への案内や別の連絡手段を検討する
LINEログインをしただけ	ログインだけではPushの対象になると判断できない	友だち状態と、自社で必要な通知の送信条件を別に確認する
送信APIが200を返した	個別の到達・閲覧の証明にはならない	API受付、顧客の確認、業務完了を分けて記録する

たとえば、予約変更を伝えた後に顧客の承諾が必要な場合は、メッセージの送信だけで「承諾済み」に変更しません。変更内容を確認する画面や返答の受付を用意し、未確認の予約をスタッフが一覧で見られるようにします。これはAPIの機能ではなく、自社の業務として設計する部分です。

Reply・Push・一斉配信を使い分ける

送信方法	向いている場面	設計で気を付ける点
Reply	ユーザーの発言や操作への即時応答	Webhookで受け取る応答トークンが必要。後日の返信用に保管しない
Push	予約確定・発送などの個別通知	対象条件、送信量、重複送信、不達時の扱いを確認
Multicast	指定した複数ユーザーへの同じ案内	対象ユーザーIDの抽出と送信条件を確認。Pushの例外を一律に当てはめない
Narrowcast	属性やオーディエンスによる絞り込み配信	使用できる条件、配信対象規模、処理の進行状況を確認
Broadcast	公式アカウントの友だち全体への同じ案内	全体配信の承認、対象人数と通数の見込みを確認

送信方法の違いは公式の送信ガイドで確認できます。顧客DBを使った配信が、すべてNarrowcastになるわけではありません。会員連携したIDを自社DBから抽出して送る方法と、LINE側の属性やオーディエンスを使う方法を分けて選びます。

Replyの応答トークンは1回のみ利用でき、Webhook受信後1分以内に使う必要があります。1分を超えた場合の動作は保証されません。応答トークンの仕様に合わせ、スタッフが数時間後に承認する処理や、時間が読めない外部システムの処理では、受付応答と後続通知を分けます。再送時を含む運用条件はLINE Botの本番運用で解説しています。

ログイン・友だち追加・会員連携を別の状態として持つ

「LINE連携済み」というフラグ一つでは、ログインできるのか、会員履歴を表示してよいのか、通知対象なのかを判定できません。発注資料では次の3つを区別します。

状態	分かること	それだけでは分からないこと
LINEによるログインが成功	認証されたLINEユーザーを識別できる	自社のどの会員なのか、公式アカウントと友だちなのか
公式アカウントを友だち追加	そのアカウントとの友だち関係	自社の会員番号や、その会員のデータを見る権限
自社会員との連携が完了	自社で確認した会員とLINEユーザーの対応	将来も必ず通知できること、家族など別利用者の権限

LINE公式は、Messaging APIを使ったユーザーアカウントの連携手順を提供しています。この方式では友だち追加が前提です。LINEログインを使う連携方式もあるため、現在のログイン基盤や利用者の入口に合わせて選びます。

LINEユーザーIDは、友だち検索に使うLINE IDや表示名とは異なります。また、プロバイダーが変わると、同じユーザーでも異なるIDが発行されます。ユーザーIDの発行単位を確認し、ログイン用とMessaging API用のチャネルが同じプロバイダーにあるかを調べます。表示名が同じことを根拠に会員を自動で結び付ける設計は避けます。

会員連携の受入条件の例

以下は会員履歴を表示するサービスを想定した設計例です。実機検証済みの手順ではありません。

未連携のユーザーには、会員ログインまたは必要な登録を案内します。
会員として認証できた場合に、対象会員とLINEユーザーの対応を保存します。
連携後は、その会員に許可された履歴だけを表示します。
別会員へ切り替える際は、既存の対応を曖昧に上書きせず、確認と解除のルールに従います。
退会・連携解除後は、履歴の表示と通知対象の両方を見直します。

LIFFの画面からサーバーへ送られたユーザーIDや表示名を、そのまま認証の証拠にはできません。公式は、IDトークンまたはアクセストークンをサーバーで検証し、ユーザー情報を扱う方法を案内しています。LIFFとサーバーでのユーザー情報の扱い

既存の認証基盤との接続を検討する際は、LINEログインとAmazon Cognitoの連携も構成の参考になります。適用する際は、自社の認証・解除・権限の条件に合わせて確認します。

取得できる情報には、権限と取得方法の違いがある

LINEの表示名やプロフィール画像を取れることと、顧客台帳に必要な氏名・住所・電話番号が揃うことは別です。

欲しい情報	確認する条件	得られない場合の設計
ユーザーID・表示名・プロフィール画像	使用API、スコープ、ユーザーの同意	必須情報を絞り、取得できない場合の画面を決める
メールアドレス	LINEログイン等の取得権限の申請と対応する取得方法	自社フォームで登録・確認する方法を用意する
氏名・住所・電話番号	通常のプロフィール取得だけでは揃わない。LINE Profile+や共通プロフィールのクイック入力には契約・申請等の条件がある	自社の会員情報や入力フォームと組み合わせる
顧客の購入履歴・会員ランク	自社システムにあるデータとLINEユーザーの対応付け	未連携の状態では個人の履歴を表示しない

取得方法ごとの情報と申請条件は公式のプロフィール比較表にまとまっています。「APIで電話番号は一切取得できない」と断定するのも、「友だち追加だけで電話番号が分かる」と期待するのも正確ではありません。

発注前には、各入力項目について「何の業務で必要か」「既存DBにあるか」「LINE側から取得する条件を満たすか」を一つずつ確認します。取得できる項目をすべて集めるより、予約や問い合わせに必要な項目を決めた方が、入力画面と運用を整理できます。

履歴・既読・決済で誤解しやすいこと

過去のトーク本文を後から全部取得する仕組みではない

テキストはWebhookのメッセージイベントで受信します。受信後にテキストを改めて取得するAPIはなく、画像などのコンテンツにも保存期間の制約があります。Webhookとコンテンツ取得の仕様

問い合わせ履歴を自社の管理画面で扱いたい場合は、必要な内容を受信時から記録する設計にします。公式アカウントの管理画面にある履歴と、自社システムがAPIで取得・保存する履歴は、同じデータ範囲と決め付けません。受信し損ねたもの、保存期間、送信取消への対応も運用に含めます。

個別顧客の確認を、配信統計で代用しない

Messaging APIには、送信したメッセージの開封やクリックなどを集計する統計機能があります。集計値は、個別顧客が業務上の案内に同意した証拠にはなりません。

また、メッセージに既読をつけるAPIは、ユーザーから公式アカウントへ届いたメッセージに既読を付ける機能です。公式アカウントが送った通知を、どのユーザーが読んだか取得するAPIとは役割が異なります。承諾が必要な業務では、確認ボタンや回答フォームなど、明示的な操作を記録します。

日本向けの新規決済をLINE Pay前提にしない

日本国内のLINE Payは、2025年4月30日までに終了することが公式に案内されています。国内LINE Pay終了のお知らせを踏まえ、新規構築では国内LINE Payを決済手段の前提にしません。

決済を含める場合は、販売するもの、提供する画面、決済サービスの利用条件を別に調査します。売上の確定、決済失敗、二重操作、返金は自社業務と決済サービスの責任範囲を整理し、「LINEから支払える」という画面上の説明だけで発注範囲を決めないようにします。

APIが使えても、無料で無制限に運用できるわけではない

公式アカウントのメッセージ通数にはPush・Multicast・Broadcast・Narrowcastが含まれ、Replyは含まれません。利用プランと追加メッセージの条件は公式料金表で確認します。2026年10月1日の追加メッセージ料金改定が案内されているため、運用開始日と適用料金を合わせて計算してください。

企画時は、対象人数に加えて、1回の業務で何回通知するかを数えます。たとえば、予約確定と前日案内を別々に送る架空の設計では、両方を配信対象の通知として見積もります。販促配信も行うなら、同じアカウントで使う通数に加えます。実際の課金額は、配信方法、到達対象、プラン等によって確定します。

また、APIのレート制限は送信量の月間上限とは別です。短時間に集中する予約開始、キャンペーン、大量データ連携を予定する場合は、使用するエンドポイントの制限と処理待ちの扱いを確認します。固定の数値を全API共通の上限として扱わず、公式リファレンスのレート制限を機能ごとに照合します。

費用を比較する際には、配信料金にサーバー、DB、保守、スタッフの対応を加えます。LINE開発の見積もりの読み方では、費用の区分と総額の比べ方を整理しています。

発注前に、できない場合の動作まで一行で決める

確認項目	記入する内容の例
通知対象	会員連携済みで、通知の目的と送信条件を満たすユーザー
通知後の業務	API受付を記録し、顧客の承諾は別の操作で記録する
通知できない場合	管理画面に未確認として残し、担当者が別の連絡方法を判断する
会員情報が不明な場合	個人の履歴を出さず、会員ログインへ案内する
重複イベントを受けた場合	同じ申込・変更を二重登録しない
不正なWebhookの場合	署名検証に失敗したリクエストから業務を実行しない
連携先が停止した場合	受付と確定を分け、処理が止まった場所を担当者が追えるようにする

Webhookは、受信した本文を加工せず署名検証してから処理する必要があります。署名検証の公式手順を実装条件に含めてください。重複受信や再送、監視などはLINE Botの本番運用で具体化できます。

上表は設計時の確認例で、本文中のAPIを実際に実行した検証記録ではありません。基礎的な実装構成はMessaging APIとPythonの記事を参照し、業務の受入条件はLINE開発の要件定義テンプレートにまとめてください。

よくある質問

友だち追加していないユーザーにもPushで送れますか？

1対1のトークで、その公式アカウントへ7日以内にメッセージを送ったユーザーは対象になります。LINEログインをしただけのユーザーや、任意のLINEユーザー全体へ送れるわけではありません。送信先の状態と各APIの条件を確認します。

LINEログインで取得したユーザーIDを顧客DBに保存すれば連携は完成ですか？

自社のどの会員と対応するかを確認し、権限、連携解除、別会員への切り替えも設計する必要があります。表示名や画面から渡されたIDだけで会員を決めず、認証結果と既存会員の確認に基づいて対応付けます。

PushがHTTP 200なら顧客に届いたと判断できますか？

判断できません。ブロックしたユーザーなど、200でも実際には届かない場合があります。APIの受付結果、顧客が案内を確認した状態、予約や注文の完了を分けて管理します。

LINE APIで電話番号を取得できますか？

通常のMessaging APIのプロフィール取得では電話番号を取得できません。LINE Profile+やミニアプリの共通プロフィールのクイック入力には、契約・申請や取得方法の条件があります。条件を満たさない場合は、自社の会員情報や入力フォームを使う設計を検討します。

後から過去のトーク履歴をすべて取得できますか？

Messaging APIには、受信済みのテキスト本文を後から取り直すAPIはありません。自社で必要な履歴はWebhook受信時から保存する設計にし、取得できなかった内容や保存期間、送信取消時の扱いを決めます。

この記事に関連するサービス

TodoONadaでは、会員・予約・業務システムとの接続や通知の条件を整理します。実現したい処理、現在のシステム、取得したい情報をもとにご相談いただけます。

LINEアプリ開発のサービス・相談窓口を見る