LINE AIチャットボットのセキュリティ｜個人情報を守る10項目

結論から言うと、LINE AIチャットボットの安全性は「AIに秘密を書かない」だけでは守れません。 収集データの最小化、LINE Webhookの署名検証、顧客IDの確認、RAGの参照権限、ログのマスキング、回答禁止領域、有人切替、削除手順までを1本のデータフローとして設計する必要があります。

この記事は、元LINE株式会社でLINE公式アカウント活用支援に携わり、現在はLINE-FIRST CRM「LYNX」とAI接客プロダクトを開発・運営するLIFE合同会社代表・小川靖人が執筆しています。法的判断が必要な場合は、個人情報保護委員会の最新資料と専門家の確認を前提にしてください。

まずデータフローを1枚にする

ツールの機能表より先に、ユーザーの入力がどこを通り、どこへ保存されるかを書き出します。

LINEユーザー
  ↓
LINE Platform
  ↓ Webhook
受信サーバー
  ↓
会話制御・AI
  ├─ RAGの知識データ
  ├─ CRMの顧客データ
  └─ 有人対応画面
  ↓
監査ログ・分析基盤

各矢印について、送る項目、暗号化、保存期間、閲覧者、削除方法、障害時の代替手段を決めます。SaaSを複数使う場合は、各社へのデータ送信範囲と再学習への利用条件も確認します。

安全設計で確認する10項目

項目	最低限決めること
1. 利用目的	何のために会話データを使うか
2. 収集最小化	回答に不要な住所・電話・健康情報などを入力させない
3. 本人・顧客確認	LINEユーザーと自社会員をどう安全に紐づけるか
4. Webhook検証	LINE Platformから届いた正しいリクエストか確認する
5. 参照権限	RAGやCRMで、そのユーザーが見てよい情報だけ取得する
6. 出力制御	回答禁止・要確認・人へ渡す条件を定める
7. ログ保護	個人情報のマスキング、閲覧権限、保存期間を決める
8. 外部AI管理	送信項目、保存、学習利用、データ所在を確認する
9. 監査・評価	誤回答、漏えい、権限外アクセスを定期テストする
10. 事故対応	停止、調査、通知、削除、再開の責任者を決める

「個人情報を送らないでください」と注意書きを出すだけでは不十分です。入力欄の設計、送信前の検知、保存前のマスキング、運用者の閲覧権限まで重ねて守ります。

LINE Webhookは署名検証を最初に行う

LINEの公式ドキュメントは、Webhookイベントを処理する前にx-line-signatureを検証するよう求めています。HMAC-SHA256を使い、受信した生のリクエストボディを変更する前に検証します。IPアドレスによる許可リストの代わりにはなりません。

実装時の要点は次の通りです。

チャネルシークレットをソースコードへ直接書かない
JSONをパースする前のraw bodyで署名を確認する
不一致または署名なしのリクエストは処理しない
Webhook処理を非同期化し、早く2xxを返せる構成にする
再配信に備え、webhookEventIdで重複処理を防ぐ
シークレット再発行時の切替手順を用意する

詳細はLINE DevelopersのWebhook署名検証とWebhookの受信・再配信で確認できます。

LINEユーザーIDだけで機密情報を返さない

LINEユーザーIDを取得できたことと、自社会員として本人確認できたことは同じではありません。契約内容、予約、購入履歴、請求情報などを返す場合は、LINE Login、LIFF、Messaging APIのアカウント連携など、用途に合う方法で自社会員IDと安全に結びます。

LINE Developersのアカウント連携機能は、1回限りのlink tokenと推測困難なnonceを使う流れを提供しています。また、連携解除をいつでも行える設計が必要です。詳しくはLINEのユーザーアカウント連携とLINE ID連携の設計をご覧ください。

機密性の高い処理では、会話中に得た表示名やユーザーの自己申告だけを本人確認として扱わないでください。

RAGと生成AIには権限境界を持たせる

RAGは回答の根拠を限定できますが、文書を検索できること自体が権限管理を代替するわけではありません。

公開FAQ、社内資料、顧客別データを同じ検索領域へ混在させない
顧客ID・店舗ID・担当者権限で検索対象を絞ってからAIへ渡す
APIキー、接続文字列、個人情報をシステムプロンプトへ書かない
Webページやアップロード資料の命令文を信頼しない
AIが生成したツール実行命令を、認可確認なしで実行しない
高リスクな変更操作は確認画面または人の承認を挟む

OWASPは、外部コンテンツに埋め込まれた命令で挙動を変えるプロンプトインジェクションや、機微情報の開示を生成AIの主要リスクとして挙げています。対策はプロンプト文言だけに依存せず、認証・認可・データ分離・出力検査をアプリケーション側で実装します。参考：OWASP Prompt Injection、OWASP GenAI Security Project

ログは改善に必要な分だけ残す

会話ログは品質改善に有効ですが、保存すればするほど安全になるわけではありません。次の3種類を分けて扱います。

ログ	例	方針
運用ログ	質問分類、回答成否、有人切替	個人を特定しなくても分析できる形を優先
監査ログ	誰がどの顧客情報を見たか	改ざん防止と閲覧制限を重視
会話本文	ユーザーの自由入力、AI回答	マスキングと短い保存期間を検討

氏名、電話番号、メール、会員番号、健康・金融に関する内容などを検知し、分析用途のログから除外または置換します。削除依頼、アカウント連携解除、LINEの送信取消イベントを受けたときに、どのデータをどこまで削除するかも手順化してください。

個人情報の取扱いは、個人情報保護委員会の法令・ガイドラインで最新情報を確認します。

AIが答えない条件と有人切替をテストする

公開前に「正しく答えられるか」だけでなく、「答えてはいけないときに止まれるか」を試します。

他人の氏名・注文番号を指定して情報を求める
社内指示やシステムプロンプトの開示を求める
「前の命令を無視して」と入力する
規約にない返金や値引きを確約させる
医療・法律・金融などの個別判断を迫る
URLや文書内の命令を実行させる
大量の個人情報を入力する

テスト結果は、成功・要修正・人へ切替・重大事故の4段階で記録します。運用開始後も、AIチャットボットのKPI設計に安全性指標を含めて週次で確認してください。

よくある質問（FAQ）

Q: ChatGPTなどの生成AIへLINEの会話を送っても大丈夫ですか？

A: 一律には判断できません。送信するデータ、利用目的、本人への説明、提供先の保存・学習利用条件、自社の契約と安全管理措置を確認し、不要な個人情報は送らない設計にします。

Q: LINE WebhookをHTTPSにすれば署名検証は不要ですか？

A: 不要にはなりません。HTTPSは通信経路を保護しますが、受信したリクエストがLINE Platformから届き改ざんされていないことは、公式手順に沿った署名検証で確認します。

Q: RAGを使えば誤回答や情報漏えいを防げますか？

A: RAGは根拠を絞るために有効ですが、それだけでは防げません。検索前の権限確認、データ分離、回答禁止条件、出力検査、有人承認を組み合わせます。

既存のLINE BotやAI接客について、データフローと安全要件から見直したい方は、LINE AIチャットボット導入支援をご覧いただくか、LINEで相談するからお問い合わせください。