この記事は、当社が台湾で本番運用している4つの LINE ボットと、いくつかのクライアント案件の記録から書いています。どれも実際に起きたか、実際にクライアントから聞かれたことです。台湾の事例ですが、LINE のプラットフォームの仕様に関わる部分は日本でも同じです。
14項目の一覧
導入前:1. お客様は LINE にいるとは限らない/2. アカウントの名義で、友だちを持ち出せるかが決まる/3. 「少々お待ちください」を先に送ると、回答がプッシュになる/4. AI の利用料を誰が払うか
稼働時:5. 標準の自動応答が先に返事をする/6. 一言を何回かに分けて送ってくる/7. 既存の友だちが QR を読んでも何も起きない
AI の守備範囲:8. 「わからなければ人へ」はクライアントに却下される/9. 会話の記憶に期限がない/10. 返事が遅く、しかも届かないことがある
稼働後:11. 止まっているのに、正常に見える
技術面:12. Webhook で LINE を待たせない/13. 普段使われない予備系は、不要ではない/14. 同じ1件を2回処理する
導入前に知っておくこと
1. お客様は LINE にいるとは限らない
あるコーチから LINE の AI 対応を頼まれました。調べてみると、公式アカウントの友だちは5人だけで、お客様はほぼ全員 Instagram の DM から来ていました。
そこで Instagram を先に対応することにしましたが、Instagram には LINE にない制約があります。こちらからメッセージを送り始めることはできず、お客様のメッセージから24時間を過ぎると返信できなくなります。「3日後のフォロー」は Instagram ではできません。
対策:着手前に、お客様が実際にどの窓口から来ているかを数えます。
2. アカウントの名義で、友だちを持ち出せるかが決まる
LINE が友だち一人ひとりに振る ID(userId)は、プロバイダーごとに別の値になります。同じ人でも、プロバイダーが違えば別の ID です。
そのため、開発会社が自社のプロバイダーで Messaging API を作っていると、将来ほかの会社に乗り換えたとき、新しいシステムが受け取る ID が以前のデータと一致しません。タグや会話の記録も前の会社のデータベースに残ります。
対策:公式アカウントと Messaging API はクライアント様のプロバイダーの下に作り、開発会社は管理者権限だけを持つ。詳しくは LINE 公式アカウントは、誰の名義で作るべきか に書きました。
3. 「少々お待ちください」を先に送ると、回答がプッシュになる
LINE のメッセージには2種類あります。ユーザーからのメッセージに返信する応答メッセージは、LINE 公式アカウントの料金プランのメッセージ通数にカウントされません。システムからユーザーに送るプッシュメッセージは通数にカウントされ、プランの無料メッセージ通数を超えると、プランに応じて追加の費用がかかります。
AI が答えるまでに十数秒かかるとき、先に「少々お待ちください」と返信すると、同じ Reply Token は一度しか使えないため、その後の回答には別の送信方法が必要になります。プッシュメッセージで送る実装にすると、会話のたびに通数を消費します。
対策:考えている間は、Messaging API のローディング表示(入力中のアニメーション)を使い、回答は応答メッセージで返します。見積書には「メッセージ通数の費用はクライアント様の公式アカウントのプランから」と書いておきます。
4. AI の利用料を誰が払うか
当社サイトで実際にあった質問です。同じ方が言い方を変えて3回聞いてきました。「API は自分で申し込むのですか」「トークンの費用はどちらが払うのですか」。
AI は返事をするたびにモデルの提供元に費用が発生します。方法は2つです。
| 方法 | 良い点 | 注意点 |
|---|---|---|
| クライアントが API キーを持つ | 請求が提供元から直接届き透明。開発会社を変えても使える | クライアント自身がクレジットカードを登録し、請求を確認する |
| 開発会社の月額に含める | クライアントは手間がない | 利用量が急に増えたときに誰が負担するかを決めておく |
当社は前者を基本にしています。対策:どちらにしても、誰が払うか、上限はいくらか、超えたらどうするかを見積書に書きます。
稼働時によく止まるところ
5. 標準の自動応答が先に返事をする
プログラムは動いているのに、お客様に届くのは管理画面で設定された定型文。公式アカウントは初期状態で自動応答とあいさつメッセージがオンになっていて、AI と同時に返事をしてしまいます。
対策:稼働前のチェックリストの1行目に「自動応答:オフ」と書いておきます。
6. 一言を何回かに分けて送ってくる
実際の記録です。「13時ごろ行けそうです」、その7秒後に「大丈夫ですか」。1通ずつ別の質問として扱うと、AI は「13時ごろ」に返事をしたあと、前後のつながりがない「大丈夫ですか」にもう一度返事をします。
キーワード応答があるとさらに悪くなります。「料金/予約したい」と送られると、前半で料金表が出て、予約の部分は放置されます。
対策:お客様が打ち終わるのを待ち、1つにまとめてから処理します。当社の設定は、文末に句読点がなければ7秒、句点や疑問符があれば3秒待つ、です。一定の長さを超える文や数字を含む文は、キーワード応答に回さず AI に渡します。日本語では句読点の使い方が中国語と違うため、待ち時間はアカウントごとに調整します。
7. 既存の友だちが QR を読んでも何も起きない
「QR を読む → 友だち追加 → 自動で案内が始まる」という設計はよく使われます。しかしすでに友だちの人が読んでも、友だち追加のイベントは発生しません。画面には何も起きません。
店頭に貼った QR を読むのは、多くの場合すでに来店したことのあるお客様です。
対策:QR はパラメータ付きのリンクにして、すでに友だちの人も流れに入れるようにします。
AI にどこまで任せるか
8. 「わからなければ人へ」はクライアントに却下される
最もよくある慎重な設計で、当社も最初はこれを提案しました。ある駐車場のクライアントには、会議でこう言われました。「何でも人に回すなら、AI の意味がない」。
そこで、その駐車場の担当者が「精算ボタンを押し忘れた」のような問い合わせをどう処理しているかを調べました。担当者も確認をしているわけではなく、何回目まで、いくらまでなら通す、という運用ルールに従っていました。ルールなら、プログラムに書けます。
46種類の問い合わせを整理した結果、27種類は AI がそのまま、10種類はルールを渡せば対応でき、人に残すのは9種類でした。約8割です(設計段階の整理で、稼働後の実測値ではありません)。
対策:「AI が答えられるか」ではなく、「今、人はどう判断しているか」を聞きます。人もルールで判断しているなら、AI に任せられます。
9. 会話の記憶に期限がない
文脈を覚えさせるために、直近の会話を AI に一緒に渡すのが一般的です。しかし時間を見ていないと、3か月前の会話が今日の続きとして扱われます。
対策:記憶に時間の区切りを入れます。当社は12時間で区切っています。翌日「さっきの件」と言われると AI はつながりませんが、そのときは人に回します。これは取捨選択で、不具合ではありません。
10. 返事が遅く、しかも届かないことがある
システムには「最大何秒待つか」の設定が何層もあります。AI 自体、AI が失敗したときの予備のモデル、LINE を受ける層。これを別々に決めると、「LINE を受ける層が65秒で諦めるのに、AI の層はタイムアウトだけで60秒かかり、予備のモデルに切り替わる時間がない」ということが起きます。当社のボットの一つでは、予備のモデルが LINE 上で一度も使われていなかったことに、3層を並べて計算して初めて気づきました。
対策:3層をまとめて計算します。現在の設定は、AI 100秒 + 予備 100秒 < LINE の層 230秒 < リクエスト全体 280秒です。待っている間はローディング表示を出します。
稼働後
11. 止まっているのに、正常に見える
エラーをお客様に見せないために、失敗したときに「担当者にお繋ぎします」のような定型文を返す作りはよくあります。しかしお客様は不具合を報告してくれません。「この AI は使えない」と思うだけです。システム全体が止まっていても、外からは「AI がたまたま答えられなかった」ようにしか見えません。
当社はもっと見えにくい形で経験しました。分割メッセージをまとめる(6番)プログラムが止まり、お客様のメッセージにまったく返事が出なくなりました。それでも LINE には「受信済み」が返り、サイトの監視はすべて正常を示していました。
対策:定型文が出るたびに運用側にも通知します。監視は「サイトが応答するか」ではなく、「メッセージの処理が終わっているか」を見ます。
技術面
12. Webhook で LINE を待たせない
LINE はお客様のメッセージを Webhook に送り、すぐに応答が返ることを期待します。Webhook の中で AI を呼んで待つと、メッセージ1件ごとにサーバーの処理枠が埋まります。当社のサーバーは処理枠が5つで、ほかの6サイトと共用していました。AI によるタロットの解読1回で37〜57秒、1つの枠が埋まります。5人が同時に来ると、サイトごと止まります。
対策:Webhook はメッセージを順番待ちの列に入れて、すぐ「受信した」と返すだけにします。処理は別のプログラムが順に行います(11番でそのプログラムを監視する理由でもあります)。
13. 普段使われない予備系は、不要ではない
当社の AI は主に定額のプランで動かしていて、上限に達すると全サービスが同時に止まります。そこで、上限に達したら従量課金の API に自動で切り替え、1日3ドル・1か月15ドルの費用上限で止まる予備の経路を用意しています。
あるときサーバーを整理していて、「まったく使われていない」予備のサービスを止めました。翌日、お客様の解読が失敗しました。予備系は普段使われないのが正常です。使われないのは、本線が健全だからです。
対策:サービスを止める前に、すべてのサーバーの設定ファイルを検索し、ほかのプログラムが予備として参照していないかを確認します。
14. 同じ1件を2回処理する
ある予約サービスでは、5分ごとに「処理待ち」の予約を取り出して AI に結果を作らせていました。AI が5分以上かかると、次の回でも同じ予約がまだ「処理待ち」で、もう一度取り出されます。同じお客様に、違う結果が2通届きました。
対策:処理を始める前に、データベースで状態を「処理待ち」から「処理中」に変え、変更に成功した側だけが続ける(原子的な取得)。さらにファイルロックを重ねます。先に取ってから、時間のかかる処理をする。
まとめ:見積もりの前に聞く3つの質問
14項目のうち、AI の賢さに関係するのは2つか3つです。残りはアカウント、課金、打ち方、監視といった AI 以外のことです。開発会社を選ぶときは「どのモデルを使いますか」より、次の3つを聞いてみてください。
- 公式アカウントは誰の名義で作りますか?
- メッセージ通数と AI の利用料は誰が払いますか?
- システムが止まったとき、誰が最初に気づきますか?
この3つまで具体的に説明できる会社は、実運用で起こりやすい問題を理解している可能性が高いといえます。
この記事は、当社の中国語記事「不藏私:LINE AI 自動化客服的 15 個坑」(2026年10月)を日本の読者向けに書き直したものです。中国語特有の項目(簡体字の混入)は省いています。