金曜の夕方、タイ人の営業事務担当者が同じ画面を三度開き直していました。顧客からLINEで届いた「PO-24817の出荷はいつですか」という一文に答えるためです。基幹システムで受注番号を引き、生産管理に確認し、出荷担当に折り返す。ここまでで14分。同じ種類の問い合わせが、その日だけで20件を超えています。顧客対応チャットボットの検討は、たいていこの場面から始まります。ただし最初に決めるべきなのは、どこまで答えさせるかではありません。何を答えさせないか、です。
顧客対応チャットボットで最初に決めるのは、答えさせない範囲
社内向けのチャットボットと社外向けのチャットボットは、技術的にはほとんど同じものです。ドキュメントを検索し、生成モデルが要約し、対話形式で返す。使っている部品に大きな違いはありません。
違うのは、間違えたときに何が起きるかです。ここだけが決定的に違います。そして、この違いを設計に落とし込まないまま社外に出したチャットボットは、遅かれ早かれ会社に負債を作ります。
社内向けの誤答は手戻り、社外向けの誤答は約束になる
社内ヘルプデスクのボットが「有給の申請は3営業日前まで」と古い規程を答えたとします。担当者が気づけば訂正できます。損失は、その社員が使った時間と、訂正にかかる手間です。社内向けAIの難しさは主にこの「答えが古くなる」ことにあり、その構造については社内問い合わせ自動化2026｜答えが古くなる4つの版ズレで整理しました。
社外向けは違います。顧客のサイト上でボットが「本件は8月25日に出荷予定です」と答えたとき、顧客はそれを御社の回答として受け取ります。翌日「システムの誤りでした、実際は9月3日です」と訂正しても、顧客はすでに自社の生産計画を8月25日着で組み直したあとかもしれません。訂正は事実を戻せますが、相手の意思決定は戻せません。
つまり、社内向けの誤答は手戻りで済み、社外向けの誤答は約束として扱われます。この一点から設計の起点が変わります。
「AIが言ったこと」は免責にならない
参考になる出来事が、2024年2月にカナダで起きています。航空会社のウェブサイト上のチャットボットが、遺族割引運賃について誤った案内をしました。会社側は「チャットボットは独立した法的主体であり、自らの発言に責任を負う」という趣旨の主張をしましたが、ブリティッシュコロンビア州のCivil Resolution Tribunalはこれを退け、チャットボットは自社ウェブサイトの一部であるとして企業側の責任を認めました。命じられた支払額は合計CAD 812.02で、うち損害賠償は運賃差額のCAD 650.88、残りは判決前利息と審判手数料です（Moffatt v. Air Canada の解説：McCarthy Tétrault、CBC Newsの報道）。
金額は小さく、これはカナダの一裁判所（正確には行政審判機関）の判断です。タイや日本の法制度にそのまま及ぶものではありませんし、本稿は法解釈に踏み込みません。それでも実務上の示唆は明確です。同種の争いが起きたときに、「ボットが言ったことだから」という説明が通るとは限らない。この前提で設計するほうが安全です。
B2Bの製造業では、争いの形はもっと地味に現れます。裁判ではなく、顧客の購買部門との関係の中で起きます。「先月おたくのチャットが8月25日と言ったから、うちはその前提でラインを組んだ」と言われたとき、社内で誰がその発言に責任を持つのか。ここが決まっていない状態で自動化を進めるのは、権限を持たない担当者に見積書の押印権を渡すのと同じことです。
だから設計は「回答権限」から始める
答えさせる範囲を機能で切ってはいけません。「FAQ機能」「注文照会機能」という切り方は、社内の開発都合であって、顧客から見た約束の重さとは関係がないからです。
切るべきなのは回答権限です。その回答を人間が同じ文面でメールに書いたとして、会社として通るか。通るならボットに出させてよい。通らないなら出させてはいけない。判断基準はこれだけです。次章で、この基準を実際に運用できる3つの層に落とします。
回答権限の3層モデル｜L1固定回答・L2台帳参照・L3判断
顧客からの問い合わせを、回答の出典で3つに分けます。出典で分けるのがポイントです。難易度でも、頻度でも、質問文の長さでもありません。その回答がどこから来るのかで分けます。
| 層 | 中身 | 回答の出典 | 誤答したときに起きること |
|---|---|---|---|
| L1 固定回答 | 手続き・書式・営業時間・窓口 | 静的な社内文書 | 相手の手間が増える。訂正すれば済む |
| L2 台帳参照 | 受注番号ごとの納期・在庫・出荷状況・請求書 | 基幹システム（読み取り専用） | 回答が約束になる。訂正しても相手の生産計画は動いたあと |
| L3 判断 | 特急対応の可否・価格・仕様変更の可否・クレーム | 人の判断 | 権限のない者が会社を拘束する |
この3層は、後述するモデル試算でも同じ区分を使います。件数も工数も、この層ごとに数えます。
L1｜静的文書だけを出典にする層
L1は、答えが文書の中に確定して存在する層です。工場の受け入れ時間、必要な書類の様式、輸出書類の提出先、担当窓口の連絡先、支払条件の一般的な説明。これらは変更されるまで一定で、変更されたら文書を差し替えます。
L1でやるべきことは2つです。第一に、出典となる文書を一元管理して、版を管理すること。第二に、回答に必ず出典文書名と最終更新日を添えること。「2026年4月改訂の納入仕様書に基づくと」と一言つくだけで、顧客は自分でも確認できるようになり、ボットの回答が単独の宣言ではなく参照になります。
L1の誤答は基本的に手戻りです。相手が余計な書類を持ってくる、間違った時間に来る。困りますが、訂正すれば復元できます。
L2｜基幹システムを読み取り専用で引く層。ここが本命
L2は、答えが基幹システムの中にある層です。受注番号を渡されたら納期を返す、品番を渡されたら在庫を返す、出荷済みかどうかを返す、請求書番号から支払状況を返す。冒頭の「PO-24817の出荷はいつですか」はここに入ります。
効果が最も大きいのはこの層です。件数が3層で最も多く（540件）、1件あたりの時間も6分のL1より長い。にもかかわらず、人間が持っている付加価値は「システムを見に行って転記する」だけです。判断は入っていません。
L2の設計条件は3つあります。
- 読み取り専用にする。 チャットボットから基幹システムへ書き込ませない。顧客の発言をトリガーに受注データが変わる経路を作らないという意味です。変更は必ず人を経由させます。
- 回答に必ず情報の基準時刻を入れる。 「本日14時30分時点の出荷計画では」と付ける。台帳の値は動きます。何時点の値かを添えないと、顧客はそれを固定された約束だと受け取ります。
- 引けなかったときは黙って推測しない。 受注番号が見つからない、複数該当する、権限が確認できない。このときにボットが「おそらく今週中です」と埋めてしまうのが最悪です。引けなければ人に渡す。これを最優先で作り込みます。
L2の誤答は訂正できません。正確には、事実は訂正できますが、相手がすでに動かした生産計画は戻りません。だからL2は「正しく答える」より先に「間違って答えない」を作ります。
L3｜ボットは受付だけ。可否を答えさせない
L3は、答えが人の頭の中にしかない層です。特急対応を受けられるか、値引きに応じられるか、仕様変更の要求を飲めるか、クレームにどう対応するか。ここは在庫や工程の数字だけでは決まりません。相手との関係、今期の稼働、他の顧客との公平性、原価。人が判断する領域です。
L3にボットを踏み込ませないこと。これが設計の第一条件です。
ただし、L3でボットにできることがないわけではありません。受付ができます。用件、対象品番、希望納期、数量、連絡先、緊急度。これらを構造化して聞き取り、担当者に渡す。担当者は「何の話か分からない転送メール」ではなく、整理済みの依頼書を受け取ります。この時間短縮は実在します。後述の型Cでは、L3の1件あたり8分の短縮として計上しました。
しかし、可否は答えさせません。「特急対応は可能です」も「できません」も、どちらもボットが言ってはいけない言葉です。「担当者が確認して本日中に折り返します」までがボットの領分です。
層をまたいだ質問をどう捌くか
現実の問い合わせは、きれいに1層には収まりません。「PO-24817の納期はいつですか。もし来週以降になるなら、先に100個だけ分納してもらえませんか」という1通のメールには、L2（納期照会）とL3（分納の可否）が同居しています。
ここでの原則は単純です。低い層の答えは返してよいが、高い層が混ざった時点で会話全体を人に渡す。 上の例なら、納期を答えてから「分納のご相談は担当者から折り返します」と続け、同時に担当者へエスカレーションします。
やってはいけないのが、L3部分だけを無視してL2部分に答えて会話を終わらせることです。顧客から見ると「分納は問題ないから触れなかった」と読める余地が残ります。沈黙が同意に見える設計は作らないでください。
もう一つ、エスカレーション先を「問い合わせフォーム」にしないでください。顧客はすでにチャットで用件を書いています。同じことをフォームに書き直させると、自動化前より体験が悪化します。ボットが集めた内容をそのまま担当者のキューに載せる。ここまでを含めてL3受付です。
図に整理したとおり、3つの層は難易度ではなく「誤答の取り返しがつくかどうか」で並んでいます。L1は訂正で戻せる、L2は相手の計画が動いたあと、L3は会社が拘束される。この並びが、そのまま自動化に踏み込む順番になります。
無権限回答率｜自動完結率より先に測る指標
チャットボットの標準的な指標は自動完結率（containment rate、人に引き継がずに完了した割合）です。ベンダーの提案書にもほぼ必ず載ります。社内向けならこれで構いません。社外向けでは、先に測るべき指標が別にあります。
定義と、ログ100件での数え方
無権限回答率 ＝ L3に属する質問に対して、ボットが確定的な回答を返した件数 ÷ 抽出したログ件数。
測定にシステムは要りません。次の手順で足ります。
- 直近の会話ログを100件、無作為に抜き出す。
- 1件ずつ読み、その会話にL3の質問（可否・価格・仕様変更・クレーム）が含まれるかを見る。
- 含まれる場合、ボットの回答が確定的だったか（「できます」「できません」「〜になります」）を見る。
- 判定基準は1つだけ。「この文面を営業担当者がメールで顧客に送ったとして、会社として通るか」。 通らないものに×を付ける。
- ×の件数を100で割る。これが無権限回答率です。
100件を2人で分担して読む、それだけの作業です。月に1度、同じ手順で測ります。特別なツールも、ベンダーのダッシュボードも不要です。エクセルとログのエクスポート機能があれば足ります。
判定に迷うものは必ず出ます。迷ったら×にしてください。社外向けでは、グレーは黒として扱うのが安全側です。
なぜ自動完結率を先に上げてはいけないのか
自動完結率を上げる作業の中身は、「これまで人に渡していた質問に、ボットが答えるようにする」ことです。回答範囲を広げる、確認のステップを減らす、「担当者に確認します」と答える条件を厳しくする。どれも同じ方向を向いています。
無権限回答率が0%でない状態でこれをやると、何が起きるか。会社として通らない回答を出す速度だけが上がります。 100件に1件だった無権限回答が、範囲を広げれば100件に3件になります。ボットが応対した会話の3%です。しかもそれらは、これまで人が止めていたはずのものです。
だから順序を固定します。
- 第1段階：無権限回答率を測る。0%でなければ、範囲を狭める・エスカレーション条件を緩める・確定的な語尾を禁止する、のいずれかで潰す。
- 第2段階：無権限回答率が0%になった状態で、自動完結率を上げにいく。
- 第3段階：上げたら、また無権限回答率を測る。上がっていたら第1段階に戻る。
この順序が本稿の実務上の結論です。逆順で進めると、効果が出ているように見える指標（自動完結率）だけが伸び、リスクは可視化されないまま溜まります。
なお、無権限回答率が0%であることは「ボットが賢い」ことを意味しません。多くの場合、範囲を正しく狭めた結果です。狭いボットは、広くて危ないボットより価値があります。顧客が求めているのは会話の巧みさではなく、正しい情報だからです。
顧客対応チャットボットの費用と回収｜タイ工場のモデル試算
ここからは数字で見ます。前提を置いた試算であり、御社の実数ではありません。ただし、どの数字が効いてどの数字が効かないかは、この構造から読み取れます。
なお本試算は、問い合わせの受け口をチャットに寄せた状態を前提に、層別の件数全体へ自動化率を掛けています。電話での問い合わせが残る場合は、その比率分だけ効果を割り引いて読んでください。
モデル企業の前提と現状コスト（753,300.00 THB/年）
タイ・チョンブリ県の日系自動車部品メーカー。従業員180名、取引顧客50社、営業日24日/月。
| 項目 | 値 |
|---|---|
| 月間の顧客問い合わせ | 1,200件（50件/営業日） |
| L1 固定回答 | 480件（40%）・1件6分 |
| L2 台帳参照 | 540件（45%）・1件14分 |
| L3 判断 | 180件（15%）・1件35分 |
| 月工数 | L1 48.0h ＋ L2 126.0h ＋ L3 105.0h ＝ 279.0h |
| 年工数 | 3,348.0h |
| 営業事務の人件費 | 月給32,000 THB × 法定負担等込み係数1.35 ＝ 43,200 THB/月 |
| 稼働時間 | 8h × 24日 ＝ 192h/月 → 時間単価 225.00 THB/h |
| 年間の顧客対応コスト | 753,300.00 THB |
| FTE換算 | 1.45人（279.0 ÷ 192） |
本稿の効果額は、すべてこの753,300.00 THB/年を唯一のベースラインとして計算しています。効果を初期投資の相殺と毎年の効果の両方に数えることはしません。
L2が1件14分と長いのは、基幹システムを開いて受注番号を引いたうえで、生産管理か出荷担当に確認する往復が入るためです。画面の値をそのまま転記するだけなら、この時間にはなりません。14分の大半は、人に聞きに行っている時間です。
層ごとの重みを見ておきます。L2は件数で45%、工数でも126.0h ÷ 279.0h ＝ 約45%と、ほぼ同じ比率です。L3は件数15%に対して工数105.0h ÷ 279.0h ＝ 約38%を占めます。L1は件数40%に対して工数48.0h ÷ 279.0h ＝ 約17%にとどまります。件数の多いL1は、実は工数をあまり食っていません。 ここを最初に見ておかないと、「一番多いのはFAQだからFAQから」という判断で小さな成果に着地します。
1件あたりのコストに直すと、L1は22.50 THB（6分×225÷60）、L2は52.50 THB、L3は131.25 THBです。なお、チャットボットの見積を比較するときに月額ではなく応答1件あたりで揃えるべき理由はチャットボット費用2026｜比較の単位は月額でなく応答1件に書きました。本稿では費用比較の方法論そのものは扱いません。
型A・型B・型Cの比較
自動化の範囲を3つの型に分けます。
- 型A：L1のみ自動化（L1の70%を自動完結）
- 型B：L1（70%）＋ L2（60%）。基幹システムを読み取り専用で参照
- 型C：L1（70%）＋ L2（75%）＋ L3受付（L3を1件あたり8分短縮。可否は答えない）
| 型A | 型B | 型C | |
|---|---|---|---|
| 月削減工数 | 33.6h | 109.2h | 152.1h |
| 年削減工数 | 403.2h | 1,310.4h | 1,825.2h |
| 粗効果（年） | 90,720.00 | 294,840.00 | 410,670.00 |
| 年間運用費 | 60,000 | 144,000 | 264,000 |
| 純便益（年） | 30,720.00 | 150,840.00 | 146,670.00 |
| 初期投資 | 180,000 | 520,000 | 980,000 |
| 回収年数 | 5.86年 | 3.45年 | 6.68年 |
単位はすべてTHB。回収年数は初期投資 ÷ 純便益（年）です。
読み取れることが3つあります。
第一に、型Aは投資として弱い。年403.2hの削減は年工数3,348.0hの約12%にすぎず、粗効果90,720.00 THBに対して運用費が60,000 THB。純便益は30,720.00 THBしか残らず、回収に5.86年かかります。L1だけの自動化は、費用対効果ではなく「顧客が24時間いつでも書式をダウンロードできる」という体験の話として評価すべきです。
第二に、型Bが最も速い。年1,310.4hの削減は年工数の約39%。純便益150,840.00 THBに対して初期520,000 THBで、回収3.45年。3つの型で唯一、3年台に入ります。
第三に、型Cは削減工数が最大なのに回収が最も遅い。年1,825.2hの削減は年工数の約55%で、粗効果410,670.00 THBは3型で最大です。それでも運用費264,000 THBを引くと純便益146,670.00 THBとなり、型Bの150,840.00 THBを下回ります。初期投資は980,000 THBと型Bの約1.9倍。結果、回収は6.68年です。
図のとおり、初期投資と年間純便益は比例しません。投資を増やしても純便益は型Bで頭打ちになり、型Cではむしろ下がります。次の項でこの理由を分解します。
型Cの増分が回収しない理由
型Bと型Cを別々の選択肢として比べると、判断を誤ります。型Cは型Bを含んでいるので、増やした部分だけを取り出して評価するのが正しい見方です。
| B→Cの増分 | 額 |
|---|---|
| 初期投資 | ＋460,000 THB |
| 年間運用費 | ＋120,000 THB |
| 粗効果（年） | ＋115,830.00 THB |
| 増分の純便益（年） | −4,170.00 THB |
増やした部分は、年あたりマイナスです。回収年数が長いのではありません。回収しません。 初期投資460,000 THBを1バーツも回収しないまま、毎年4,170.00 THBの持ち出しが積み上がります。
増分の中身を確認します。粗効果の＋115,830.00 THBは2つの合計です。L2の自動化率を60%から75%へ引き上げた分が年226.8h（＝51,030.00 THB）、L3受付による1件8分短縮が年288.0h（＝64,800.00 THB）。合わせて年514.8h、金額で115,830.00 THBです。
一方、増えた運用費は年120,000 THBです。削減した514.8hで割ると、1時間あたり約233 THB。営業事務の時間単価225.00 THBを上回っています。人がやるより高い運用費で人の仕事を代替している状態です。
増分が成立する運用費の上限は、粗効果と同額の＋115,830.00 THB/年です。実際の＋120,000 THBは、これを約3.6%超えています。差は年4,170.00 THBで、絶対額としては小さい。だからこそ厄介です。提案書の上では「効果は増える」「削減工数は最大」と正しく書けてしまい、増分がマイナスであることは総額の表からは見えません。
なぜ運用費だけが跳ねるのか。社外向けの追加自動化に乗る費用の中身が、答えを出すための費用ではないからです。
- 監視：出した回答を人が定期的に読み返す作業。無権限回答率の測定はここに含まれます。
- 多言語：日本語・英語・タイ語で回答文面を維持する費用。顧客が増えれば言語も増えます。
- 監査ログ：誰にいつ何を答えたかを、後から取り出せる形で保存する費用。
これらは自動化率に比例しません。範囲の広さに比例します。 L3受付を足した瞬間、監視対象の会話は「事実を返した会話」から「人の判断が絡む会話」に広がり、読み返しの単価が上がります。多言語も、L1のFAQを3言語にするのと、L3の受付ヒアリングを3言語で崩さずに回すのとでは、維持の重さが違います。
したがって型Cを否定しているのではありません。型Cを費用対効果で正当化しようとすると失敗する、というだけです。型Cを選ぶ理由があるとすれば、「顧客の一次応答を24時間化して機会損失を防ぐ」「特急依頼の受付漏れをなくす」といった、この試算に載っていない目的です。その場合は、増分がマイナスであることを承知のうえで、別の効果を定義して測ってください。工数削減の名目で稟議を通すと、2年目に説明できなくなります。
感度分析｜型Bを成立させるのは基幹システム側の引き当て経路
型Bの回収3.45年は、L2の60%が自動完結する前提で出ています。この前提が崩れたときにどうなるかを見ます。
| L2自動化率 | 年削減工数 | 純便益（年） | 回収年数 |
|---|---|---|---|
| 40% | 1,008.0h | 82,800.00 | 6.28年 |
| 50% | 1,159.2h | 116,820.00 | 4.45年 |
| 60% | 1,310.4h | 150,840.00 | 3.45年 |
| 70% | 1,461.6h | 184,860.00 | 2.81年 |
単位はTHB。L1の自動化率70%と、初期520,000 THB・年間運用144,000 THBは固定しています。
60%から40%へ落ちると、回収は3.45年から6.28年へ、2.83年分伸びます。この6.28年は、型Aの5.86年より遅い水準です。投資額が3倍近い型Bが、L2が動かないだけで型Aより回収の遅い選択肢に転落します。
図のカーブが示すとおり、回収年数はL2自動化率に対して直線的には動きません。40%付近では傾きが急で、少しの差が大きく効きます。70%側では傾きが緩やかになります。上振れの余地より、下振れの痛みのほうが大きい形です。
では、L2の自動化率は何で決まるのか。回答の巧みさではありません。顧客が使う番号で、機械が一意に引けるかです。
現場でよく詰まるのは次の3つです。
- 顧客の呼ぶ番号と、社内の番号が違う。 顧客は自社のPO番号を書いてきます。基幹システムは自社の受注番号で管理しています。この対応表がマスタに無ければ、ボットは何も引けません。人間の担当者は経験で紐づけているので、この断絶は日常業務では見えていません。
- 1つの番号に複数の明細がぶら下がる。 PO 1本に複数の品番が乗り、それぞれ納期が違う。「PO-24817の納期は」に一意の答えがありません。ここで「最も遅い日付を返す」のか「明細ごとに列挙する」のかを決めておかないと、ボットは平然と1つだけ返します。
- 出荷状況が基幹システムに載るまでのタイムラグ。 実際には昨日出たのに、システムの反映が翌営業日の朝という運用は珍しくありません。この状態で「まだ出荷されていません」と答えると、事実と違う回答になります。
いずれも、チャットボットの導入プロジェクトではなく、基幹システム側の整備です。ここが先に要ります。 逆に言えば、この3点が既に整っている会社では、型Bは想定より速く立ち上がります。ベンダー選定の前に、自社のマスタとインターフェースを確認してください。
チャネル設計｜タイのLINE、ベトナムのZalo
どのチャネルに載せるかは、機能の話ではなく記録の話です。
一次窓口がLINEである前提で設計する
タイではLINEが事実上の一次窓口です。DataReportalの「Digital 2026: Thailand」によれば、2025年10月時点でLINEの月間アクティブユーザーはタイで5,600万人。総人口7,160万人の78.2%、インターネット利用者6,780万人（人口の94.7%）の82.6%にあたります。
これは消費者向けだけの話ではありません。B2Bでも、購買担当者個人のLINEに直接飛んできます。「メールで送ってください」と案内しても、急ぎの件はLINEに来ます。
本稿のモデル工場でも、チャネル構成はメール55%・電話30%・LINE 15%。LINE経由は月180件です。（3層モデルのL3判断が月180件なのは、1,200件の15%という比率がたまたま一致しているだけで、両者は別の切り口です。混同しないでください。）
チャネル設計で先に決めるべきなのは、載せる順番ではありません。どのチャネルの会話を正本のログに落とすかです。無権限回答率を測るには、ログが1か所に集まっている必要があります。チャネルを増やしてから記録を後追いで統合しようとすると、統合されないチャネルが必ず残ります。
なお、日本語・英語・タイ語の3言語をどう作り分けるか、どこまでを共通にするかはチャットボット導入の費用と進め方｜タイ工場の多言語対応で扱っています。本稿では、多言語が型Cの運用費を押し上げる要因の1つとしてのみ触れました。
個人アカウント宛の会話が記録から外れる問題
LINEに載せると、まず間違いなく起きることがあります。顧客が、公式アカウントではなく担当者個人のLINEに送ってくることです。
そのほうが早いからです。しかも、その担当者は親切に答えます。答えた内容は会社の記録に残りません。担当者が退職すれば、やり取りごと消えます。監査ログの整備に費用をかけている一方で、実際の約束は個人の端末の中にある。珍しくない実態です。
チャットボットを入れると、この問題は解消するどころか、可視化されます。公式アカウントのログには「営業時間の問い合わせ」ばかりが残り、納期の約束は個人LINEにある。無権限回答率を測っても、危ない会話がサンプルに入りません。
対処は技術ではなく運用側です。少なくとも次の3つを決めてください。
- 公式アカウントを一次窓口として顧客に明示する。 名刺・注文請書・メール署名に載せます。
- 個人LINEに来た業務連絡を、担当者が公式側へ転記する運用を決める。 完全には守られませんが、ルールが無い状態よりは残ります。
- 納期・出荷・請求に関する回答は、必ず公式チャネルまたはメールで出す。 個人LINEでは「公式アカウントでご確認ください」と返す。担当者にとっては手間が増えるので、この点は評価制度側の手当てが要ります。
ベトナムに拠点がある場合も、同じ構造の問題が起きます。ベトナムではZaloが同等の位置にあり、VNGの2026年第2四半期業績では月間アクティブ8,130万人、1日あたり22億通のメッセージ、公式アカウントは約3万件と報告されています。プラットフォームは違いますが、「個人アカウント宛の会話が会社の記録から外れる」という問題の形は変わりません。
個人データの取り扱いで先に確認すること
顧客の氏名・連絡先・注文内容をチャットボットが受け取り、それを海外リージョンのLLMに送るなら、越境移転の論点が発生します。
タイのPDPAでは、越境移転に関する2つの告示が2023年12月25日に公布され、2024年3月24日に施行されています（TMI総合法律事務所の解説、Tilleke & Gibbinsの解説）。
本稿は法解釈に踏み込みません。確認すべき論点として存在する、というところまでに留めます。実務上、プロジェクトの早い段階で法務または外部の専門家に確認しておきたいのは次の点です。
- 会話データがどの国のリージョンに保存され、どの国で処理されるのか。ベンダーの回答を口頭ではなく文書で取る。
- 移転の根拠を何に置くのか（適切な保護水準がある国か、契約条項等の手当てか）。
- モデルの学習に会話データが使われない契約になっているか。
- 保存期間と削除の手順。監査ログを長く残すことと、個人データを長く持たないことは、しばしば衝突します。
この確認を後回しにすると、開発が終わったあとにリージョン変更やベンダー変更が必要になり、初期投資の想定が崩れます。要件定義より前に片付けておく類の作業です。
導入前に決めておく7項目（チェックリスト）
ベンダーに声をかける前に、社内で決めておく項目です。ここが決まっていれば、提案の比較は速くなります。
- L3の一覧を作る。 「ボットに答えさせない質問」を具体的な文例で20件書き出します。抽象的な分類ではなく、実際に来た文面で書きます。営業と品証と物流から集めると、部門ごとに認識がずれていることが分かります。
- エスカレーション先と時間を決める。 L3が来たとき、誰のキューに入り、何時間以内に人が返すのか。「担当者が確認します」と言ったまま翌日になるなら、自動化しないほうがましです。
- 正本のログをどこに置くかを決める。 チャネルが複数でも、ログは1か所。無権限回答率の測定はここからサンプリングします。
- 基幹システム側の引き当て経路を確認する。 顧客のPO番号から自社の受注番号を引けるか。1つの番号に複数明細がある場合の返し方を決めたか。出荷実績の反映タイミングは何時間遅れるか。
- 回答に添える定型を決める。 出典文書名と最終更新日（L1）、情報の基準時刻（L2）、折り返し期限（L3）。3つとも文面のテンプレートに埋め込みます。
- 測定の担当者と頻度を決める。 月1回、ログ100件、2人で読む。誰がやるのかを名前で決めます。決めないと2か月で止まります。
- 個人データの取り扱いを法務と確認する。 保存リージョン、移転の根拠、学習利用の可否、保存期間。ベンダー選定の前に確認します。
この7項目のうち、1・2・3・6は社内だけで決められます。ベンダーが決まっていなくても今日から着手できる部分です。
よくある質問
顧客対応チャットボットの費用はどのくらいかかりますか？
本稿のモデル工場（従業員180名、月間問い合わせ1,200件）の試算では、初期投資180,000〜980,000 THB、年間運用費60,000〜264,000 THBの幅になりました。範囲の広さで大きく変わります。ただしこれは前提を置いたモデルであり、御社の見積ではありません。複数社の見積を比べるときは、月額の総額ではなく、応答1件あたりに直して単位を揃えてから比較してください。
納期回答を自動化してよいのでしょうか？
条件付きで可能です。基幹システムを読み取り専用で参照し、回答に情報の基準時刻を添え、引けなかったときは推測せず人に渡す。この3つが実装されているなら、L2として自動化する価値は大きい。本稿の試算でも、運用費を引いたあとの純便益が最も大きく、回収が最も速いのは、このL2を含む型Bでした（削減工数と粗効果そのものが最大なのは型Cです）。逆に、顧客のPO番号から一意に引ける経路が無い状態で始めると、効果が出ないまま運用費だけが残ります。
社内向けと社外向けを1つのチャットボットにまとめられますか？
技術的には可能ですが、指標と運用は分けてください。社内向けは自動完結率で評価してよく、誤答は手戻りで済みます。社外向けは無権限回答率を先に見る必要があり、誤答は約束になります。同じ画面に同じ指標を並べると、社外向けの危険が社内向けの実績で薄まって見えます。まとめる場合は、少なくともログを分けて抽出できる状態にしてください。
タイ語のチャットボットは日本語版から翻訳すれば足りますか？
L1の固定回答については、翻訳して版を揃える運用で回ります。L2以降は、基幹システムから返る値の書式（日付・数量・品名）が言語ごとに崩れないかを個別に確認する必要があります。また多言語は、維持費が範囲の広さに比例して増える項目です。本稿の型Cで運用費が跳ねた要因の1つでもあります。翻訳の一度きりの費用ではなく、文面を改訂するたびに全言語を揃え直す運用の費用として見積もってください。
導入事例はどこを見て判断すればよいですか？
自動完結率や削減時間の数字より、「答えさせなかった範囲」がどう書かれているかを見てください。範囲の記述がない事例は、成功の再現条件が分かりません。加えて、他社の削減率をそのまま自社の効果に当てはめないことです。効果は問い合わせの層別内訳と1件あたり時間で決まるため、同業でも構成が違えば結果は変わります。
外部の予測値は判断材料になりますか？
参考にはなりますが、自社の効果としては使えません。Gartnerは2025年3月5日の発表で、2029年までにエージェント型AIが一般的な顧客サービス問い合わせの80%を人手を介さず解決し、運用コストを30%削減すると予測しています。これは外部機関の市場予測であり、本稿のモデル試算とは無関係の数字です。本稿の型A〜Cの数値と混ぜないでください。
経営層から「早くAIを入れろ」と言われています。どう進めればよいですか？
範囲を狭く切って、測る指標を先に決めてください。Gartnerが2025年9〜10月に321名の顧客サービス責任者に実施した調査（2026年2月18日発表）では、91%が経営層からAI導入の圧力を受けていると回答しています。つまり「やるかどうか」はもはや論点ではなく、圧力の下で範囲をどう決めるかの問題になっています。範囲を決めずに始めると、広く作って止められないボットが残ります。
問い合わせ対応の効率化は、どこから手をつけるべきですか？
まず1か月分の問い合わせをL1・L2・L3に分類し、件数と1件あたり時間を実測してください。本稿のモデルでは、件数の40%を占めるL1が工数では約17%にとどまり、件数15%のL3が工数の約38%を占めました。件数の多い順に手をつけると、小さな効果に着地します。分類が済めば、投資すべき層は自動的に決まります。
まとめ
顧客対応チャットボットの設計は、何に答えさせるかではなく、何に答えさせないかから始まります。本稿の要点を整理します。
- 社内向けの誤答は手戻りで済むが、社外向けの誤答は会社が出した約束として扱われる。「AIが言ったこと」で免れられるとは限らない前提で設計する。
- 回答権限をL1（静的文書）・L2（基幹システムの読み取り）・L3（人の判断）の3層に切り、L3にはボットを踏み込ませない。L3でできるのは受付までで、可否は答えさせない。
- 自動完結率より先に無権限回答率を測る。ログ100件を人が読み、「同じ文面を営業担当がメールで送って会社として通るか」で判定する。0%になるまで自動完結率は上げない。
- モデル試算では、現状の年間顧客対応コスト753,300.00 THBに対し、L1＋L2を自動化する型Bが純便益150,840.00 THB・回収3.45年で最も速い。
- 範囲を最大にした型Cは、削減工数が最大（年1,825.2h）でありながら回収6.68年。B→Cの増分だけを取り出すと年−4,170.00 THBで、増やした部分は回収しない。社外向けの追加自動化には、間違った答えを出さないための費用が範囲の広さに比例して乗る。
- 型Bが成立するかどうかは、顧客が使う番号から納期・在庫・出荷状況を機械が一意に引けるかにかかっている。L2自動化率が40%まで落ちると回収は6.28年となり、型Aの5.86年より遅くなる。
- チャネルはタイならLINE、ベトナムならZaloが一次窓口。載せる前に、どのチャネルの会話を正本のログに落とすかを決める。
- 個人データの越境移転は、要件定義より前に確認しておく論点として存在する。
TOMAS TECHでは、タイの日系製造業向けにシステム開発と業務システムの導入支援を行っています。顧客対応チャットボットについても、いきなり開発の話をする前に、まず1か月分の問い合わせをL1・L2・L3に分類して、どの層にいくら使っているかを一緒に確認するところから始めています。「自社のケースだと型Bの前提が成り立つのか分からない」「基幹システム側で何を用意すればよいか知りたい」といった検討の初期段階でも構いません。お問い合わせフォームからお気軽にご相談ください。日本語・英語・タイ語で対応しています。
参考情報
- Gartner, “Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029″（2025年3月5日）
- Gartner, “Gartner Survey Finds 91% of Customer Service Leaders Under Pressure to Implement AI in 2026″（2026年2月18日発表／2025年9〜10月に321名を調査）
- McCarthy Tétrault, “Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot”
https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot
- CBC News, “Air Canada found liable for chatbot’s bad advice on bereavement rates”
https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416
- DataReportal, “Digital 2026: Thailand”
https://datareportal.com/reports/digital-2026-thailand
- TMI総合法律事務所「タイ個人情報保護法（PDPA）に基づく越境移転規制の告示について」
https://www.tmi.gr.jp/eyes/blog/2024/15449.html
- Tilleke & Gibbins「タイの越境個人データ移転規制」
- VNG / Zalo 利用者数（2026年第2四半期）
https://www.vietnam.vn/en/zalo-dat-81-3-trieu-nguoi-dung-voi-2-2-ty-tin-nhan-moi-ngay
※本稿のモデル試算は、記載した前提条件に基づく計算例です。実際の効果は問い合わせの層別内訳、1件あたり対応時間、基幹システムの整備状況によって変わります。
