LINE公式アカウントとホームページの連携｜標準機能でできることと開発が必要な範囲

2026年10月20日

アイキャッチ — 上段にホームページの画面と無地の吹き出しを持つスマートフォン、下段に問い合わせを引き継ぐ記録用紙を置き、サイトと窓口をつなぐ構図

LINE公式アカウントを作り、店頭でも友だち追加を案内している。それでもホームページからの問い合わせはメール、LINEは別の担当者が確認していて、情報の整理に手間がかかる。二つをつなぎたいと思っても、どこまで頼めばよいか迷うことがあります。

「LINE連携」は、ボタンから別の画面へ案内する作業から、顧客情報を照合して通知を自動送信する開発までを指します。言葉だけで依頼すると、発注者と制作側で想定する範囲が異なり、費用の比較もしにくくなります。

この記事の結論

まず画面への案内、問い合わせ対応、顧客データの連携、自動通知を分けて、必要なものを決めます。友だち追加ボタンやリッチメニューで目的を満たせるなら、標準機能とホームページの修正から始められます。顧客ごとに情報を出し分けたり、業務の進行に合わせて通知したりする場合は、既製の連携機能を調べたうえで個別開発を検討します。

「連携したい」を、四つの目的に分ける

画面がつながることと、データがつながることの違い

ホームページに友だち追加ボタンを置けば、お客様はLINEへ進めます。ただし、ボタンの設置だけでフォームの送信内容や会員情報まで引き継がれるわけではありません。まず次のどの段階を目指すか確認します。

目的	実現したい状態	依頼時の確認点
友だち追加の導線	サイトを見た人がLINEへ進む	ボタンを置く場所と案内文
問い合わせの受け口	商品やサービスの質問をチャットで受ける	対応する担当者、時間、記録方法
予約や会員情報の連携	顧客ごとの情報を呼び出す	元のデータと利用者を照合する方法
自動通知	受付や発送などの変化を知らせる	送る条件、宛先、失敗時の対応

たとえばクーポンを案内したい場合も、共通のクーポンを配るのか、会員の購入履歴に応じて変えるのかで範囲が異なります。会員証の画面へ案内することと、会員番号を照合して表示することも別の作業です。

予約の仕組みそのものは別記事で整理します。ここでは、すでに使っているページへ案内するのか、予約の状態をLINEに伝えたいのかを分けて考えます。

図解 — 左のホームページと右のスマートフォンの間に、友だち追加の一方向の矢印、問い合わせの往復の矢印を置き、下にある業務データの保管先からスマートフォンへ通知の矢印を伸ばし、画面の移動とデータの受け渡しを別経路で示した関係図

標準機能で足りる範囲を先に確かめる

管理画面で用意できる案内と応答

LINE公式アカウントには、リッチメニュー、応答メッセージ、チャット、クーポンやショップカードなどの機能があります。店舗共通の案内や来店時の特典が目的なら、標準機能で足りるかを先に確認します。機能の概要はLINEヤフーの公式マニュアルで確認できます。

リッチメニューはトーク画面の下部に表示するメニューです。ホームページの商品案内やアクセス、既存の申し込みページへのリンクを設定できます。お客様が毎回URLを探す手間を減らす使い方です。表示される端末などの条件は、LINE Developersのリッチメニューの説明も確認してください。

応答メッセージは、よくある質問への案内などに使えます。営業時間や所在地など、答えが共通する内容から整えると管理しやすくなります。担当者が個別に答えるチャットと併用する場合は、手動で返信する時間帯と、自動応答の設定を実際の端末で確かめます。

既製の連携機能がある場合も、範囲を確認する

現在使っている会員管理などのサービスに、LINEとつなぐ機能が用意されている場合があります。ただし「LINE対応」という表示だけでは判断できません。単にページを開く機能なのか、会員を照合できるのか、通知まで送れるのかを提供元に確認します。

標準機能で作るクーポンやショップカードと、自社の会員データを使う仕組みも区別します。すでに顧客台帳があるなら、情報をどちらで管理するか、二重に入力する作業が発生しないかを見てください。

LINE公式アカウントの料金プランやメッセージ通数の扱いは、公式の料金ページで確認します。使う機能、配信方法、通数によって検討する契約が変わるため、過去に聞いた月額料金だけで予算を決めないようにします。通数の数え方も確認してください。利用者からのメッセージに返す応答（チャットやReply API）は通数に入らず、会社側から送るプッシュ通知は通数に入ります（Messaging APIの料金ページ。2026年10月時点）。上限に達すると通知は送られないので、上限に近づいたときの検知と、別の連絡手段も決めておきます。

図解 — 左側の標準機能の領域にリンクボタン、共通の案内、クーポンのカードを置き、中央に境界線と接続口、右側の連携開発の領域に顧客データの保管先、利用者を照合する鍵、個別の通知の封筒を置いた範囲の比較図

ホームページには、使う理由と別の連絡方法も載せる

友だち追加のボタンは、相談したくなる場所に置く

すべてのページで大きなボタンを出すより、サービス説明や料金を読んだ後など、お客様が相談したくなる場所を選びます。何を受け付ける窓口かが分かるよう、「商品の在庫について相談する」など、用途を添えてください。

友だち追加が目的のボタンなら、その後に相談内容を送る必要があることも案内します。友だち追加と問い合わせの受付は別の行動です。追加した時点でスタッフから必ず連絡が来るような、実際の運用と違う説明は避けます。

サイトとLINEで営業時間、料金、所在地が違っていると、確認の問い合わせが増えます。詳しい情報はホームページに集め、LINE側から該当ページへ案内するなど、更新元を決めておきます。掲載内容の整理は店舗ホームページに必要な情報も参考になります。

フォームと電話の役割を分ける

LINEは短い質問のやり取り、フォームは必要な項目をそろえた依頼、電話は営業中の急ぎの確認というように、実際に対応できる範囲を示します。LINEを使わない人にも連絡先が分かる表示にしてください。

窓口を増やすなら、返信の目安もそれぞれに載せます。「いつでも送れる」と「いつでも返信する」は違います。休業日の送信にどう案内するか、緊急の相談を受け付けるかを決めます。フォームの項目や受付後の案内は問い合わせフォームの作り方で扱っています。

公開前には、サイトのボタンから正しいアカウントへ進めるか、LINEのメニューから正しいページへ戻れるかを確認します。スマートフォンだけでなく、パソコンでホームページを見た人が追加する手順も確認してください。

Messaging APIによる開発は、何を自動化するかで決まる

個別の情報を送るなら、データと宛先の設計が必要

Messaging APIは、システムとLINEの間でメッセージなどをやり取りするための仕組みです。業務システムで受付状況が変わったら通知するなど、標準の案内では満たせない処理で検討します。機能の範囲はMessaging APIの公式概要で確認できます。

APIを使えるだけで、ホームページの顧客とLINEの利用者が自動で一致するわけではありません。誰にどの情報を送るかを決めるには、本人の操作で会員情報と結び付けるなどの設計が必要です。表示名だけで顧客を判断すると、別人に情報を送るおそれがあります。

既存サービスで目的を満たせるなら、その連携機能も候補です。個別開発が必要かどうかは、データを取り出す手段、求める処理、既製機能の制約を調べて判断します。依頼書には次の内容を記載します。

何が起きたら、誰に、どの内容を送るか。送らない条件も示す
データを管理しているサービスと、連携機能があるかどうか
通知の重複や送信失敗をどう確認し、誰が対応するか
利用者とのひも付けや解除、担当者の操作権限をどう扱うか

通知は必ず読まれるものとして扱わず、送れない場合や利用者がブロックした場合の業務も決めます。別の連絡方法へ切り替える条件と、送信の履歴をどこで確認するかまで含めて相談してください。

設定の作業費と、連携するシステムの開発費を分ける

ボタンの設置やメニューの設定と、顧客情報の照合や通知処理の開発では費用の対象が違います。見積もりでは、サイトの修正、アカウントの設定、連携開発、動作確認を分けてもらいます。

LINEのボタン設置に、連携開発と同じ費用がかかるわけではありません。 連携先と処理内容によって見積もりの対象が変わります。

LINEや連携サービスの利用料に加え、公開後のエラー確認、外部サービスの仕様変更への対応、追加改修がどの契約に含まれるかを確認します。送る人数と回数を想定し、配信に関わる費用も試算します。

問い合わせ記録と管理権限を、担当者任せにしない

窓口を増やした後も、対応状況を追えるようにする

LINEのトークが残っていても、別の担当者が受付内容や対応済みかどうかを判断できるとは限りません。会社として引き継ぐ記録を決め、窓口をまたいだ相談も追える状態にします。

受け口	残る記録と、運用で補うこと
LINE	トークを参照し、依頼内容、担当、対応状況を社内で決めた管理先に残す
フォーム	入力内容の保存先と通知先を確認し、その後の回答や対応状況も追記する
電話	日時、相手、用件、折り返しの要否を担当者が記録する

記録は大がかりなシステムでなくても、必要な人が参照できる管理表から始められます。ただし相談に不要な個人情報まで転記せず、閲覧できる担当者や保管のルールを決めます。トークの保存や検索などの利用条件も、契約時に確認してください。

図解 — LINEの吹き出しは会話の履歴へ、フォームの用紙は入力内容の保管先へ、電話の受話器は手書きのメモへそれぞれつながり、三つの経路が担当と対応状況を記録する共通の管理表へ集まる、記録の残り方の比較図

私物アカウントと共有パスワードに頼らない

担当者の私物のLINEアカウントを、お客様からの問い合わせ窓口にすると、退職や端末の変更で引き継ぎが難しくなります。窓口には会社で管理する公式アカウントを使い、必要な担当者へ管理権限を付けます。ログイン情報を全員で使い回す運用も避けます。

外部へ設定を依頼する場合も、自社が管理を引き継げる権限を確保してください。制作会社に渡した権限をいつ見直すか、担当が替わったときに誰が解除するかを決めます。開発に使う認証情報は、問い合わせ用のチャットや一般の共有資料に貼らない扱いにします。

切り替えは、まず用途と担当を決め、標準機能を設定し、社内で試してからサイト上に案内を出す順で進めます。公開後は、受け付けたまま回答していない相談がないかを定期的に確認します。案内から問い合わせまでの見直し方はホームページの問い合わせを増やす改善も参考になります。

よくある質問

友だち追加ボタンを置くにもMessaging APIが必要ですか？: 友だち追加へ案内するボタンの設置だけなら、通常は個別のAPI開発を伴いません。サイトを編集する権限と、案内先の公式アカウントを確認して依頼します。
フォームをなくして、問い合わせをLINEにまとめてもよいですか？: お客様の利用状況と受け付ける内容で判断します。LINEを使わない人の連絡方法、必要事項の確認、社内への引き継ぎが成立するかを確かめてから変更してください。
自動通知のために、最初からすべて開発するべきですか？: まず使っているサービスに目的を満たす連携機能があるか調べます。その範囲では足りない処理を洗い出してから、追加開発の見積もりを取ると判断しやすくなります。