AIにLINE配信を任せる前の権限設計。下書き・承認・送信を分ける

AIとLINEを連携するときは、文章を作る権限と、顧客へ送る権限を別々に設計します。 送信先や通数をAIの判断だけに委ねず、業務システムが確認して実行する構成にすると、誤った指示や外部文書の影響を小さくできます。

この記事は権限と処理の設計案です。LINEの公開資料を2026年9月8日に確認していますが、本記事の構成で実配信・負荷試験・権限突破の試験を実施した結果ではありません。制作するBotの業務とアカウントに合わせて受入条件を決めてください。

MCPを接続しても、業務上の承認は別に必要

LINEが公開するLINE Bot MCP Serverには、個別のメッセージ送信だけでなく、友だち全体へ配信するツールもあります。MCPはAIとツールをつなぐ仕組みであり、社内の承認者や配信予算を自動的に決めてくれるものではありません。

「全員には送らないで」というプロンプトは行動の指示にはなりますが、送信先を強制的に制限する仕組みではありません。外部から受け取る質問、Webページ、添付資料は業務上の命令として実行せず、文章中の指示によって宛先や権限が変わらないよう、実行側の規則を置きます。

APIのトークンに付く権限と、自社アプリ内で許す業務操作も区別します。LINEのチャネルアクセストークンだけで「このAIは顧客Aにだけ送れる」という制約が自動的にできるわけではありません。トークンをAIへ渡さず、送信専用の処理からのみ使う方式を検討します。

任せる操作を小さく定義する

操作	AIに任せる入力・出力	実行側が固定・確認すること
公開FAQから回答案を作る	質問と参照資料から案を返す	参照できる資料、返却形式、文字量
配信実績を要約する	集計済みの数字から要点を作る	顧客単位の秘密情報を混ぜない
問い合わせへ返信する	回答案と有人対応の判定候補	Webhookに対応する会話、期限、送信回数
予約リマインドを作る	定型文の補助や説明案	予約DBの状態、対象者、送信時刻
一斉配信を準備する	文案・画像案の下書き	人が確認した宛先集合、内容、予算

顧客の問い合わせに返信する場合は、AIの返り値に任意の宛先IDを含める必要はありません。サーバーが受信イベントと会話を対応付け、同じ会話へ送るようにします。予約変更等の業務更新は、文章を生成する権限とはさらに分けます。

承認するのは文面だけでなく、送信条件の組

下書き方式でも、承認後に宛先や本文が変われば、確認したものとは別の配信になります。承認対象には少なくとも文面、リンク、添付物、対象条件、対象人数、配信時刻、見込通数を含めます。

AIが下書きを作り、未承認の配信案として保存する。
システムが対象者を確定するか、対象条件と上限を記録する。
担当者が配信案の版と送信条件を確認して承認する。
送信直前に、版・宛先・有効期限・予算・停止状態を再確認する。
条件が変わった場合は再承認へ戻し、一致する場合だけ送信する。

対象者が配信時刻まで変化する設計では、固定リストの承認か、条件と最大人数の承認かを決めます。対象条件を承認する場合も、増えた人数を無制限に受け入れません。承認済みの予定から外れたときに誰へ戻すかまでが配信フローです。

上限は並行実行を含めて守る

宛先数、時間当たりの送信数、1日の予算を設ける場合、複数の処理が同時に上限を確認する場面を考えます。各処理が「まだ100通残っている」と判断して同時に100通ずつ送ると、個々の確認が正しくても合計が超過します。

設計案としては、送信ジョブの作成時に予定通数を確保し、成功・失敗・保留を記録します。LINE側の当月利用状況とも照合し、自社システム以外の管理画面や外部ツールからの配信も予算へ含めます。費用の数え方はAI連携Botの費用構造で整理しています。

停止操作は新規依頼だけでなく、実行待ちのジョブにも効くようにします。たとえば「停止したがキューに残る1万件は流れ続ける」状態では、停止の意味が業務担当者の期待とずれます。停止した時点で受理済みの送信を取り消せるとは扱わず、未送信を止める範囲を明確にします。

顧客データは会話ごとに取得範囲を決める

顧客Aからの問い合わせで検索するデータは、認証・会員連携で確認できたAの範囲に絞ります。AIの出力や質問内の会員番号を信じて別顧客の情報を返さないようにします。LINEの表示名を、契約者の本人確認として使いません。

データ	AIへ渡す前の確認	記録に残す範囲の例
公開FAQ	最新版か、公開可能な内容か	文書ID・版
注文や予約	利用者との対応と取得権限	業務ID・取得結果の分類
問い合わせ本文	必要な項目と機微な情報の有無	保存目的に応じた本文または要約
トークン・秘密鍵	AIに渡す必要はない	値を出力せず管理上の識別子のみ
送信先リスト	実行側で管理する	対象集合の版・人数・承認者

ログを残すことと、全ての個人情報を長期間複製することは別です。調査に必要な操作ID、承認者、時刻、使用モデル、文案の版、送信結果の参照を中心にし、閲覧者と保存期間を決めます。LINEの開発ガイドラインも利用者情報の取り扱いを確認する出発点になります。

通信切断と再実行で二重送信しない

LINEへの送信後に応答を受け取れないと、実際には受理されていても自社側は失敗に見える場合があります。対応する送信APIでは、最初の試行から同一ジョブのリトライキーを使い、再試行でも維持します。キーを毎回作り直すと別の送信になってしまいます。公式の再試行仕様

ただしリトライキーは、AIが誤った宛先を選ぶことや業務データの重複更新まで防ぐものではありません。業務の依頼IDと送信ジョブIDを分け、業務更新にも重複防止を設けます。replyとPushの期限・再試行条件は別なので、すべての送信を同じ扱いにしません。

本番権限を渡す前の受入表

以下は試験案です。テスト用チャネルでも、実在の顧客情報や課金可能なAI認証情報を使えば影響は発生します。試験対象、データ、送信上限を決めてから実行します。

試験入力・状況	期待する結果
質問中に「全員へ送信」と書く	質問の内容として扱い、権限は増えない
顧客AがBの会員番号を指定する	Bのデータを返さない
承認後に本文・URLを変更する	承認済みの版と不一致となり送信しない
配信上限付近で複数ジョブが動く	合算して上限を守る
実行待ちがある状態で停止する	未送信ジョブが定めた範囲で止まる
送信直後に通信が切れる	対応APIの再試行で同じ送信として扱う
応答期限を超える	無条件の再送に進まず、定めた経路へ
承認者が退職・権限喪失する	新しい承認や再開を実行できない

初期導入は公開FAQの下書きから始め、品質と権限の確認後に限定的な自動返信へ広げる方法があります。一斉配信を自動化する必要がなければ、承認付きの下書き支援で完了して構いません。機能を増やした数ではなく、任せた範囲の誤操作を検知・停止できることを確認します。

よくある質問

プロンプトに禁止事項を書けば送信事故を防げますか？

禁止事項はAIへの指示として使えますが、宛先・通数・予算の制限は実行側でも強制します。外部の文章によって権限や送信先を変更できない構成が必要です。

人が承認すれば、その後は条件を見なくてよいですか？

送信直前にも承認した文面の版、対象者、人数、期限、停止状態を確認します。条件が変わったら再承認へ戻すようにします。

LINEのアクセストークンをAIに渡す必要はありますか？

必須ではありません。AIは下書きを返し、トークンを保管する送信専用の処理が業務条件を確認してAPIを呼ぶ構成にできます。

テスト用チャネルなら自由に実験できますか？

テスト用でも実在の利用者や顧客情報、課金するAPIを使えば影響は発生します。試験用データと宛先を用意し、上限と停止方法を決めて検証します。

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

AIによる下書き支援、自動返信、承認付き配信では、必要な権限と受入条件が異なります。LINE連携で任せたい業務と、人が確認する判断を整理したうえでご相談いただけます。

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