LINE公式アカウントの標準機能はどこまで使えるか。追加開発の判断表

LINE公式アカウントで新しい施策を始めるときは、まず管理画面の機能で必要な運用ができるかを確認します。メッセージ配信だけでなく、チャット、リッチメニュー、オーディエンス、ステップ配信などが用意されています。自社データを使いたいという理由だけで、すぐAPI開発が必要になるわけではありません。

この記事は2026年9月8日に確認した公式マニュアルを基に、標準機能、追加オプション、外部ツール、独自開発の境界を整理します。機能の有無と、希望する運用を無理なく続けられるかは分けて判断します。

「標準機能」と「無料で無制限」を分ける

LINE Official Account Managerのマニュアルには、配信・チャット・分析などに加えて、CRMオプションやAIチャットボットなどの案内も掲載されています。管理画面から使う機能でも、プラン、追加契約、利用条件を確認する必要があります。公式マニュアル一覧

業務	最初に確認する機能	確認すべき運用条件
営業案内を定期的に送る	メッセージ配信・予約配信	対象、承認、配信通数
よくある質問へ案内する	応答メッセージ・チャット	キーワード、有人対応、営業時間
予約サイトへ誘導する	リッチメニュー・プロフィール等	リンク先で予約が完了するか
一部の友だちに案内する	絞り込み・オーディエンス	利用できるデータと人数条件
追加後に順番に案内する	ステップ配信	開始・分岐・待ち時間・停止条件
店頭特典を運用する	クーポン・ショップカード	利用条件、不正利用への対応、確認担当

標準機能で対応できても、初期設定や画像制作、日常の更新作業は発生します。「開発しないから運用費もゼロ」とせず、担当者が何を毎週行うかまで確認します。

自社データの利用と、自動同期は別の要件

公式のオーディエンスには、メッセージのクリック、追加経路、チャットタグ、予約、ユーザーIDアップロードなどの種類があります。自社が適切に取得したIDをアップロードして使う運用も候補です。オーディエンスの公式マニュアル

したがって、「自社会員だけに送るので必ず独自開発」という判断は早い場合があります。一方、毎日変わる会員状態や予約済みの情報を、送信直前に正確に反映したいなら、手作業による更新の限界を検討します。

要件の違い	選択肢の考え方
月に一度、担当者が対象一覧を更新	管理画面やアップロードで運用できるか確認
少人数を会話内容から分類	チャットタグ等の利用条件と更新作業を確認
注文完了後、短い時間で個別に案内	外部システムとの連携・送信処理を検討
取消・退会した人を送信直前に除外	データ同期の遅れと再確認の設計が必要
複数店舗で同じ会員状態を共有	管理主体、権限、更新責任を先に整理

オーディエンスに人数制限や推計値がある場合、細かい条件へ分けすぎて配信できなくなることもあります。希望する対象件数で実現できるかを先に確認します。

ステップ配信は、属性以外の分岐も確認する

標準ステップ配信では、友だち追加やオーディエンスを開始条件にでき、属性とオーディエンスによる条件分岐が用意されています。Messaging APIで作成したオーディエンスも開始条件・分岐に利用できます。標準ステップ配信の公式仕様

「標準では性別・年齢でしか分けられない」という前提でツールを選ぶ必要はありません。ただし、購入した瞬間に止める、予約時刻の直前に送るといった要件では、データ更新と配信時刻の精度を確認します。

標準の配信シナリオを使い、対象の作成だけ外部システムから連携する構成も考えられます。すべて自社で作るか、すべて管理画面に任せるかの二択にしないことが大切です。詳しい条件は標準ステップ配信の記事で扱っています。

リッチメニューは、表示内容と更新方法で判断する

全員共通の予約リンクや営業時間への入口なら、管理画面で作ったリッチメニューが候補になります。会員状態ごとの表示やAPIによる制御が必要なら、APIで作成する方式も比較します。

管理画面とMessaging APIで作成したリッチメニューは、編集や統計を自由に相互利用できるわけではありません。作成方法を変えると、更新担当者の操作や分析の取得先も変わります。リッチメニューの公式比較

APIを選ぶ際には「便利になる機能」だけでなく、画像を誰が変更し、いつ反映し、誤設定をどう戻すかを開発範囲に入れます。毎回開発者へ依頼しなければ変更できない構成が、担当者に合うとは限りません。

実務例：イベント案内を標準機能から始める

架空の地域イベントで、月に一回の開催案内、申込ページへのリンク、問い合わせ対応を始めるとします。初期段階は管理画面の配信と共通リッチメニュー、担当者のチャット対応を組み合わせる案が考えられます。

申込済みの人へ募集を送らない運用を追加する場合は、まず適切に連携できるデータがあるか、担当者が更新可能な頻度かを確認します。申込件数が増えて手作業の更新が追いつかなくなった段階で、申込システムとの同期を検討します。

この順序なら、参加者が実際に使うメニューや問い合わせ内容を把握してから、必要な部分を自動化できます。一方、当初から変更・取消が頻繁な予約業務なら、最初にDB連携を設計した方がよい場合もあります。

追加開発へ進む条件を、回数と影響で書く

「標準機能では足りない」という説明だけでは、外注先が必要な範囲を見積もれません。どの手作業が、どの頻度で、どんな間違いにつながるかを整理します。

困っていること	発注要件にする書き方
対象一覧の更新が大変	どのDBから、何の条件で、いつ更新するか
個別通知が遅れる	何の完了から、どの時間内に送信処理を始めるか
問い合わせが迷子になる	振り分け条件、担当決定、未対応の確認方法
メニューの変更に時間がかかる	誰がどの項目を編集し、誰が公開を承認するか
効果が分からない	取得する集計と、自社側の手続き完了をどう比較するか

外部ツールで満たせるかも同じ表で確認します。ツールが持つ機能を利用する場合は、APIの仕様だけでなく、データ出力、契約終了時の移行、既存Botとの接続範囲も見積依頼に含めます。

導入前の確認表

確認するもの	判断できる状態
現在の機能	現行マニュアルと自社画面で利用条件を確認している
作業担当	原稿登録、対象更新、承認、問い合わせ対応を割り当てている
費用	配信プラン、オプション、外部ツール、運用作業を区分している
データ更新	手作業の頻度と、遅れが許される時間を決めている
失敗時の対応	配信を止める人と業務の確認先がある
開発範囲	標準で続ける部分と追加する処理が具体的になっている

料金は配信通数や利用するオプションによって確認します。機能名だけで無料と断定せず、見積時点のプランを参照してください。公式料金プラン

よくある質問

LINE公式アカウントの標準機能はすべて無料ですか？

標準画面から利用する機能でも、配信通数、プラン、追加オプションなどの条件があります。設定・画像制作・日常運用の作業も含めて費用を確認します。

自社データで配信するならAPI開発が必要ですか？

ユーザーIDアップロードやチャットタグ等で運用できる場合があります。必要なのがデータ利用だけか、頻繁な自動同期や送信直前の状態確認まで含むかを分けて判断します。

標準のステップ配信は属性だけで分岐しますか？

属性に加えてオーディエンスによる分岐も利用できます。Messaging APIで作成したオーディエンスも利用できますが、利用条件や更新のタイミングを確認する必要があります。

外部ツールと独自開発はどう比較しますか？

必要な機能だけでなく、データ更新、担当者の操作、障害時の対応、費用、契約終了時のデータ移行を同じ条件で比較します。標準機能と一部の追加開発を組み合わせる案も検討します。

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

標準機能で始める範囲と、会員・予約システムへ接続する追加開発の範囲を整理したい方は、LINEアプリ開発のサービスをご覧ください。

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