「LINEにAIチャットボットを実装したものの、リッチメニューのデザインを変更したらAIが動かなくなった」このような経験はないでしょうか。
Webhookを使った構成で、AIへの分岐判定にリッチメニューIDを使う場合、デザインを変更するたびにIDが変わるため、Makeのシナリオも手動で修正しなければなりません。
本記事ではLステップの標準APIを活用し、タグで制御する設計にしたことで、この問題を解決した構築例をご紹介します。
新潟のグルメ情報をLINEで提案するAIボットを題材に、リッチメニューの変更でシナリオが壊れない設計と、パーソナライズ対応のポイントを解説します。
Webhook依存のAIチャットが抱える構造的な問題
AIチャットボットを動かすこと自体は、LINE Webhook → Make → AI → LINE返信という構成で比較的シンプルに実現できます。
AIへの繋ぎ方には「リッチメニューのID」で分岐判定する設計がよく使われますが、実運用を想定するとここに課題があります。
それは、リッチメニューの画像や文言を変更すると、LINE側の内部IDが自動的に変わってしまう点です。
マーケティング担当がデザインを更新するたびに、Makeのシナリオ内の判定IDを手動で修正しなければなりません。修正漏れが発生すれば、AIへの分岐が機能しなくなります。
マーケティング側の施策がシステム側の障害を引き起こす構造的な問題であり、運用コストを継続的に発生させる原因になります。
【解決策】Lステップ標準APIによるタグ制御への移行
この問題を根本から解決するのが、Lステップの標準API（友だち情報取得）を活用したタグ制御の設計です。
リッチメニューIDの代わりに、Lステップのタグ情報をMakeの分岐判定に使用します。
具体的には、ユーザーがリッチメニューの「AIグルメ情報」をタップした際に、Lステップ側で自動的にタグをONにし、Makeはそのタグの有無でAIへの分岐を判定します。チャットを終了すると、タグはOFFに戻る設計です。
この設計の最大のメリットは、リッチメニューIDを一切参照しないため、デザインを変更してもMakeのシナリオが壊れない点です。
Lステップの管理画面でタグを操作するだけで運用変更が完結します。
パーソナライズ変数の注入で回答をユーザーごとに最適化
タグ制御による安定した設計を実現した上で、さらにユーザーごとに異なる回答を返すパーソナライズの仕組みの構築も可能です。
事前に回答フォームで取得しておいた「興味のある地域」などのユーザー属性を、標準API経由でMakeに連携。
DifyのRAGプロンプトに変数として動的に注入することで、同じ質問でもユーザーごとに異なる回答を生成します。
たとえば「お勧めのラーメン屋は？」という同じ質問に対して、新潟市を登録したユーザーには新潟市内のラーメン屋を、長岡市を登録したユーザーには長岡市内のラーメン屋を提案する、といった形です。
ユーザー属性がそのままAIの回答に反映されるため、チャットボットでありながら「自分のために答えてくれている」という体験を実現できます。
まとめ
Lステップの標準APIを活用し、タグ制御に移行することで、デザイン変更でシナリオが壊れない運用を実現できます。
加えて、ユーザー属性をDifyの変数に注入することで、同じ質問でもユーザーごとに異なるパーソナライズされた回答を返す仕組みも構築できます。
「タグ管理はLステップ」「AI制御はMake」「回答生成はDify」と各システムの役割を明確に分離することで、保守・拡張がしやすい設計になるのもこの仕組みの大きな強みです。
LINEとAIの連携については、【Lステップ×AI 外部連携セミナー】（オンライン／参加費無料）も開催していますので、ご興味がある方はぜひ無料セミナーにお越しください。
