LLM に個人情報を渡さずに、CS 問い合わせ対応エージェントを作る

カンリーが開発する福利厚生サービスでは、従業員番号での本人確認という仕組みが生む課題がある。登録時の入力間違いや雇用区分変更による番号変更で、ログインできないユーザーが一定数発生し、その対応がカスタマーサポートの隠れた工数になっていた。個別対応は定型的だが、アカウント確認と顧客企業への往復確認があるため、時間が静かに積み重なっていく典型的なパターンだ。ここに目をつけたのが、LLMを使ったエージェントで「確認と承認」だけに絞るという発想である。

AIの鬼が注目するのは、ここでの制約の引き方だ。LLMに個人情報を渡さないという縛りがあるため、単純に「すべてAIに任せる」という選択肢が消える。そこで仕事の内容を「コードで書けるか、LLMの読解力が必要か」で仕分けるという自律規律が生まれた。診断と検索と更新はコード、分類と文章化だけをLLMに任せるという役割分担だ。この方式だと、診断のルールが明確に書かれるため、あとから監査もできるし、テストも書きやすい。つまり「個人情報を預かるなら送るな」という制約が、むしろシステムの透明性と保守性を高めることになっている。多くの企業は「個人情報の壁があるからAIを導入できない」と諦めがちだが、この事例は「制約を設計の起点にする」という別の道を示している。

中小企業のCSチームが抱える問題はほぼ同じ構造だ。定型的な問い合わせをAIで自動化したいなら、個人情報を渡さない設計を最初に考えることが、長期的には組織の信頼と運用の安定性を両立させる。エージェントに預ける判断基準は「便利さ」ではなく「預けても説明がつくか」に置く。その厳しさが、実は実務で動くシステムを作る。