タイやASEANの製造・販売拠点でチャットボット導入を検討するとき、成否を分けるのは生成AIモデルの名称ではありません。「何を答えさせ、何を答えさせないか」「日本語・英語・タイ語・ベトナム語をどう統制するか」「回答できない案件を誰へ引き継ぐか」を、RFPと受入試験に落とし込めるかです。本稿は、情報システム、業務部門、購買、法務・DPOが同じ基準で発注・導入判断を行うための実務ガイドです。
経営判断要旨：チャットボット導入で最初に決める7項目
チャットボットは「社内検索の画面」から「顧客対応の入口」まで幅があります。対象範囲を曖昧にしたまま見積を取ると、ベンダーごとに前提が異なり、初期費用も運用費も比較できません。経営会議や投資審査では、少なくとも次の7項目を一枚にまとめます。
- 対象ユーザーは従業員、代理店、既存顧客、一般顧客のどれか
- 対象業務は問い合わせ、文書検索、申請案内、障害一次切り分けのどれか
- 利用チャネルはWeb、LINE、Microsoft Teams、社内ポータルのどれか
- 対応言語と、言語ごとの正式な用語管理者は誰か
- 参照可能な知識、個人情報、機密区分、権限境界をどう定義するか
- AIが回答しない条件と、有人担当への引き継ぎ先・受付時間・SLA
- 成功を測る業務KPI、品質KPI、安全KPI、費用KPIは何か
この7項目に合意できない段階では、全社展開の価格交渉より、狭いユースケースでの検証設計を優先すべきです。タイ拠点における生成AIの進め方は、海外拠点の生成AI導入ガイドと、投資判断を小さく始めるタイでのAI PoC費用と成功基準も合わせて参照してください。
Go / Conditional Go / No-Goの判断条件
経営判断は、モデルのデモ映像ではなく制約の確認から始めます。
| 判断 | 条件 | 経営上の扱い |
|---|---|---|
| Go | 情報オーナー、対象文書、権限、エスカレーション、受入基準が合意済み | 90日程度の限定導入へ進む |
| Conditional Go | 効果仮説はあるが、言語品質や個人情報フローが未確定 | 利用者・知識・チャネルを絞ったPoCに限定する |
| No-Go | 正本が不明、担当者不在、機密文書を無差別に投入、AI回答を無監督で外部公開 | 要件を作り直すまで発注しない |
ここでいう「90日」は導入計画の例示であり、保証期間ではありません。接続対象、法務確認、データ整備、利用部門の合意速度に合わせて自社計画へ置き換えます。
従来FAQ bot・検索・RAG・AI agentの違い
同じ「チャットボット」と呼ばれていても、仕組みとリスクは違います。RFPで名称だけを書かず、期待する挙動を定義してください。
| 方式 | 回答の作り方 | 適する用途 | 主な制約 |
|---|---|---|---|
| ルール型FAQ bot | 登録した質問と回答、シナリオ分岐 | 定型案内、申請導線、営業時間案内 | 表現揺れへの対応、保守工数、未登録質問 |
| キーワード／全文検索 | 検索語に一致する文書や箇所を返す | 規程・マニュアルの探索 | 利用者が適切な検索語を知る必要がある |
| RAG | 質問に関連する文書断片を検索し、生成AIが根拠を使って回答 | 複数文書の横断質問、要約、手順案内 | 検索失敗、古い知識、根拠と回答のずれ |
| AI agent | 回答に加え、許可されたツールやAPIを呼び出して処理 | チケット作成、在庫照会、申請状態確認 | 誤操作、権限昇格、重複実行、監査の複雑化 |
RAG（Retrieval-Augmented Generation）は「AIに社内文書を学習させる」ことと同義ではありません。一般には質問時に関連文書を取り出し、その内容を回答の根拠として渡します。したがって、モデル性能だけでなく、文書分割、メタデータ、検索、権限フィルター、引用表示、更新反映の品質が重要です。
AI agentは、検索に加えて外部処理を実行します。読み取り専用の在庫照会と、発注登録や顧客データ更新ではリスクが大きく異なります。最初のチャットボット導入では、回答・検索と更新操作を分離し、更新系は確認画面、明示的な承認、権限再確認、冪等キー、操作ログを備えてから段階的に開放するのが現実的です。
チャットボット導入の対象ユースケースを選別する
価値と実装可能性を別々に評価する
候補業務は、問い合わせ件数だけで優先順位を決めません。「頻度」「対応時間」「回答の標準化度」「知識の整備度」「誤回答時の影響」「権限の複雑さ」「多言語の必要性」を評価します。高頻度でも、回答が個別判断に依存し、損失や安全に直結する業務は初期対象に向きません。
| 候補 | 初期適合度 | 理由と条件 |
|---|---|---|
| ITヘルプデスクの手順案内 | 高 | 正本とエスカレーション先を整えやすい。アカウント操作は別統制が必要 |
| 人事・総務の規程案内 | 中〜高 | 対象国・雇用区分・版の識別が必要。個別労務判断は有人へ |
| 製品仕様・保守マニュアル検索 | 中〜高 | 型式、版、設備番号のメタデータ品質が鍵 |
| 見積・納期の自動回答 | 中 | ERP連携、価格権限、在庫鮮度、対外回答の承認が必要 |
| 品質異常の最終判定 | 低 | 安全・品質責任に関わるため、補助情報の提示に限定 |
| 契約・法務判断 | 低 | 条文検索は可能でも結論の自動化は避け、法務確認へ接続 |
除外条件を先に書く
RFPには「できること」だけでなく「初期リリースでは行わないこと」を記載します。たとえば、医療・安全上の最終判断、従業員の評価判断、未承認の価格提示、支払先変更、削除・承認などの不可逆操作、機微な個人情報を含む自由入力は、明示的な設計と承認ができるまで除外します。
ユースケース台帳には、業務オーナー、対象者、入力例、参照知識、出力形式、禁止回答、例外、引き継ぎ先、想定ピーク、言語、保存期間を記録します。この台帳が、見積範囲、テストケース、運用責任の共通母体になります。
多言語チャットボットとタイ語チャットボットの設計
多言語対応を「画面の言語切替」だけで考えると失敗します。入力言語の検出、検索対象、用語、回答言語、引用元、担当者への転送、ログの分類まで一貫させる必要があります。
localeをユーザー属性・会話・コンテンツで分ける
最低でも次の3種類のlocaleを別フィールドで持ちます。
- user locale：プロフィールやチャネル設定に登録された希望言語
- conversation locale：その会話で現在使用している言語
- content locale：参照する知識文書の言語と国・拠点
タイの利用者が英語の製品型式とタイ語の質問を混ぜる、いわゆるコードスイッチは一般的な入力パターンとして試験します。英語の略語や型式を無理に翻訳せず、回答本文は希望言語、引用は原文と必要に応じた要約を表示する、といったポリシーを決めます。
Microsoft Copilot Studioの言語サポートでは、言語や機能ごとの対応状況が整理され、generative answersやuser languageで日本語・タイ語・ベトナム語が挙げられています。一方、機能ごとに対応段階が異なり、primary languageは作成後に変更できないとされています。製品名ではなく、採用する機能、テナント、リージョン、チャネル、対象言語の組み合わせを発注前に実機確認してください。
また、Microsoftのmultilingual agentsの説明では、生成オーケストレーションで動的な言語切替を扱える一方、classic chatbotは一つの言語を扱い、手動作成トピックの翻訳は作成者側の責任になる旨が説明されています。これは一製品の仕様例ですが、「自動翻訳される範囲」と「人が維持する範囲」をRFPで区別する重要性を示します。
タイ語の表記揺れと辞書
タイ語では、分かち書き、英語由来語の音写と英語表記、社内略語、製品型式、敬語表現の違いが検索品質に影響します。辞書は単語リストではなく、次の列を持つ運用データにします。
| 項目 | 例 | 運用ルール |
|---|---|---|
| concept ID | 製品・制度ごとの不変ID | 言語が変わっても同じ概念を結ぶ |
| 正式語 | 会社承認済みのタイ語表現 | 回答本文とUIで優先 |
| 別名・略語 | 英語、タイ語音写、部門略称 | 検索拡張に使い、誤解しやすい語は除外 |
| 禁止表現 | 法務・ブランド上使わない語 | 生成後チェックにも使う |
| 適用範囲 | 国、法人、工場、製品、期間 | 誤った拠点の規程を返さない |
| 責任者・更新日 | 業務部門と翻訳責任者 | 定期レビューと監査に使う |
翻訳品質は「自然さ」だけでなく、手順が同じか、責任主体が変わっていないか、否定・条件・期限が維持されているかで評価します。安全手順、就業規則、契約条件は、機械翻訳だけを正本にせず、各言語の承認済み文書を優先します。
チャットボット開発の参照アーキテクチャ
実装方式にかかわらず、責任境界を分けます。
- チャネル層：Web、LINE、Teams、ポータルから入力を受ける
- ID・セッション層：利用者、法人、工場、役割、会話状態を識別する
- オーケストレーション層：言語判定、意図分類、検索、ツール呼出し、拒否、転送を制御する
- 知識層：承認済み文書、メタデータ、検索インデックス、版管理を保持する
- モデル層：生成、分類、翻訳、埋め込み等を提供する
- 連携層：CRM、ERP、MES、ITSM、チケット、通知へ接続する
- ガバナンス層：ログ、評価、監視、権限、秘密情報、保存・削除を管理する
RFPでは、各層の提供者、データが通過する国・リージョン、保存場所、再委託先、障害時の責任、変更通知、解約時のデータ返却・削除を明記させます。クラウドサービス、モデルAPI、ベクトルDB、監視基盤を組み合わせる場合、「ベンダーのセキュリティ認証がある」だけではシステム全体のデータフローを説明できません。
RAGの品質を決める知識パイプライン
RAGは投入前後の管理が中心です。
- 収集：SharePoint、ファイルサーバー、Web、DBから対象だけを取得
- 正規化：PDF、表、画像OCR、ヘッダー・フッター、重複を整理
- 分割：章、手順、製品、版を壊さない単位でチャンク化
- メタデータ：言語、法人、拠点、部門、製品、機密区分、施行日、失効日を付与
- 索引：キーワード検索、ベクトル検索、再ランキングを用途に合わせる
- 権限：検索前または検索時にアクセス制御を適用
- 生成：根拠だけで答える、根拠不足なら回答を保留する
- 引用：文書名、版、該当箇所、リンクを表示
- 更新：正本変更から検索反映までを監視し、削除も伝播
文書数を増やすこと自体は品質目標ではありません。矛盾する版、草案、他国規程、期限切れ文書が混ざるほど、もっともらしい誤回答の原因になります。
RFP要件表：見積可能な粒度まで具体化する
以下はRFPに最低限含める項目です。回答形式を「対応可否」だけにせず、標準機能、設定、個別開発、外部サービス、前提、制限、追加費用、証跡URLに分けると比較しやすくなります。
| 要件群 | RFPで確認する内容 | 提出を求める証跡 |
|---|---|---|
| ユースケース | 対象、除外、利用者、ピーク、営業時間、対象国 | ユースケース別の処理図と前提一覧 |
| 多言語 | 検出、切替、コードスイッチ、辞書、翻訳責任、引用言語 | JA/EN/TH/VIの実機デモと制限表 |
| RAG | 取込形式、分割、検索、再ランキング、引用、更新、削除 | 評価結果、検索ログ、版更新デモ |
| ID・権限 | SSO、RBAC、法人・工場・部門境界、ゲスト | 権限マトリクスと否定テスト |
| 個人情報 | 収集目的、同意等の根拠、保存、越境、削除、DSAR | データフロー、処理者一覧、DPA案 |
| 安全性 | prompt injection、機密漏えい、不適切出力、ツール悪用 | 脅威モデル、対策、レッドチーム結果 |
| 連携 | LINE、Teams、Web、ERP、CRM、ITSM | API仕様、署名検証、再試行、冪等設計 |
| 有人対応 | 転送条件、会話要約、キュー、SLA、受付時間 | 画面、通知、失敗時の代替動線 |
| 運用 | 監視、評価、変更管理、障害、バックアップ、終了手順 | RACI、運用手順、月次報告サンプル |
| 商務 | 初期、従量、ライセンス、保守、超過、為替、税、解約 | 3年TCOと単価表、除外事項 |
ベンダーには、同じテストデータとシナリオで回答させます。自由なデモでは、各社が得意な機能だけを見せるため比較になりません。また「対応予定」は、提供日、対象プラン、リージョン、契約上の確約がない限り、現行機能と分けて評価します。
知識・権限・タイPDPAを一つのデータフローで確認する
個人情報を入力・ログ・知識・連携先に分ける
個人情報は知識文書だけに存在するとは限りません。利用者の質問、会話履歴、評価コメント、有人転送のチケット、分析ログ、バックアップ、モデル提供者へのリクエストにも含まれ得ます。データフロー図には、収集点、処理目的、主体、保存場所、受領者、保持期間、削除方法、越境の有無を記載します。
タイのPDPA対応は個別事情で変わるため、本稿は法的助言ではありません。タイPDPCのGPPCおよびGPPC PLUSが示すRoPA、同意管理、漏えい対応、データ主体要求（DSAR）などの実務要素を参考にしつつ、自社DPO・法務と、管理者・処理者の役割、処理の根拠、通知、越境、保持、委託契約、インシデント手順を確認してください。
文書レベルの権限を回答まで維持する
「ログイン済みだから社内文書をすべて検索できる」という設計は避けます。利用者属性と文書メタデータを照合し、検索結果、生成回答、引用リンクのすべてで同じ権限を維持します。特に、人事、給与、顧客価格、未公開製品、品質異常、監査資料は分離します。
否定テストでは、権限のある質問に答えられることだけでなく、権限のない利用者、別工場、別法人、退職者、期限切れセッション、共有端末、推測したURLからアクセスできないことを確認します。権限変更が検索インデックスとキャッシュへ反映される時間も測ります。
モデル提供者のデータ条件を契約単位で確認する
OpenAIのenterprise privacyは、ビジネス向けデータを既定でモデル学習に使わない方針などを説明しています。ただし、保持、ログ、対象サービス、地域、サブプロセッサー、例外は利用する製品と契約で確認する必要があります。
2026年8月19日にOpenAIが公表したZero Data Retentionに関する更新は、データ保持を重視する企業にとって確認対象となる最新例です。ただし、ZDRはすべてのAPI、機能、ログ、契約へ自動適用されるとは限りません。適格なAPI・機能、適用除外、承認手続、契約条件、乱用監視等の扱いを発注時点でベンダーと法務に確認してください。特定の一社を選ぶ根拠ではなく、各候補へ同じ保持・学習・削除質問を行うための比較項目です。
LINE・Teams・Webへの接続要件
LINE webhookは署名、非同期、重複を設計する
LINEを顧客接点に使う場合、インターネットから受けるwebhookをそのままAI処理へ渡してはいけません。LINEのwebhook受信ガイドでは、リクエストを非同期に処理すること、redeliveryや重複を考慮することなどが説明されています。また、署名検証の公式手順に従い、受信した生のリクエストボディに対して署名を検証します。検証前にJSONを整形・再シリアライズすると、正しい署名判定ができない設計になり得ます。
実装では、受信、署名検証、受付応答、キュー投入、重複排除、AI処理、返信を分離します。イベントID等から冪等キーを生成し、再配信が起きてもチケット作成や更新処理を重複実行しないようにします。redeliveryは到達の可能性を高める仕組みであり、業務処理の完了保証として扱わず、監視と再処理キューを用意します。
TeamsとWebではIDの強さを分ける
Teamsや社内ポータルでは、組織ID、グループ、端末条件を使える場合があります。一方、公開Webでは匿名利用が中心です。同じチャットボットでも、匿名ユーザーへ返せる情報と、認証済み従業員へ返せる情報を別ポリシーにします。URLパラメータや自己申告だけで権限を切り替えないでください。
複数チャネルを一つのバックエンドへ接続する場合、会話ID、利用者ID、チャネルID、法人、locale、同意状態、有人対応状態を共通スキーマへ正規化しつつ、チャネル固有の制限を保持します。ログ上で誰の会話か追跡できることと、不要な個人情報を分析担当へ見せないことを両立します。
セキュリティ：生成AI固有と通常のWeb対策を統合する
OWASP Top 10 for LLM Applications 2025は、Prompt InjectionやSensitive Information Disclosureを含む主要リスクを整理しています。また、NIST AI 600-1 Generative AI Profileは、生成AIリスクを組織のAIリスク管理へ組み込むための参照資料です。チェックリストを購入条件として貼るだけでなく、自社ユースケースの脅威モデルへ落とします。
prompt injectionを「禁止文」だけで防がない
「前の指示を無視して」と入力されたら拒否する、といった文面だけでは十分ではありません。直接入力だけでなく、検索したWebページ、PDF、メール、添付ファイルに埋め込まれた間接的な命令も想定します。
- システム指示、ユーザー入力、取得文書、ツール結果を区別する
- 取得文書内の命令を信頼済み指示として扱わない
- ツールごとに最小権限、許可引数、上限、確認を設定する
- 機密情報をモデルの不要なコンテキストへ入れない
- 出力をSQL、HTML、メール、APIへ渡す前に用途別検証を行う
- 攻撃パターンを継続評価し、モデル変更時に回帰試験する
sensitive disclosureと秘密情報
APIキー、webhook secret、接続文字列、個人情報、他部署の文書をプロンプトテンプレートへ直書きしません。秘密情報は専用保管庫から実行時に参照し、ログ、エラー、分析画面ではマスクします。「モデルが学習しない」契約と「アプリケーションがログへ保存しない」設計は別問題です。
signature・idempotency・承認
外部webhookは署名、時刻、送信元、再送を検証します。更新系APIでは、同じイベントを二度受けても結果が増殖しない冪等性を持たせます。発注、返金、顧客情報変更などの高影響操作は、AIが候補を作っても、人または明示的なポリシーエンジンが承認し、実行後に監査可能な記録を残します。
有人エスカレーションを製品機能ではなく業務として設計する
「回答できないときは担当者へ転送」は、転送ボタンだけでは完成しません。誰が、いつ、何を受け取り、返答後にAIがどう振る舞うかを定義します。
転送条件
- 利用者が人との会話を明示的に求めた
- 根拠が取得できない、または複数の正本が矛盾する
- 個人情報、契約、価格、クレーム、安全、品質異常に該当する
- 同じ質問を繰り返し、自己解決できていない兆候がある
- 感情悪化、脅迫、自傷等、定めた高リスク表現を検知した
- 連携APIが失敗、タイムアウト、権限拒否になった
引き継ぐ情報
担当者には、会話全文を無条件で渡すのではなく、利用者の同意と業務上の必要性に応じ、要約、質問、試した手順、参照した文書、根拠、言語、顧客・設備識別子、緊急度を渡します。機密や不要な個人情報は除外・マスクします。担当者が回答した内容をそのまま恒久知識へ自動追加せず、承認フローを通します。
SLAと不在時
営業時間、対応言語、部門キュー、初回応答の目安、営業時間外の案内、通知失敗時の代替手段を表示します。契約時の例示基準として「営業時間内は所定時間以内に受付通知」「重大区分は即時通知」などを置けますが、実時間は人員、チャネル、重要度、既存SLAを測定して決めます。
テストデータと受入基準
正解率一つで合否を決めない
生成回答は表現が変わるため、文字列一致だけでは評価できません。質問セットに、期待する事実、必須引用、禁止事項、許容表現、転送期待、権限、言語を付けます。
| 評価軸 | 測る内容 | 契約時の例示基準の書き方 |
|---|---|---|
| 根拠性 | 回答が承認済み根拠に支持されるか | 重要質問は必須事実をすべて満たし、根拠URLを表示する |
| 検索品質 | 適切な文書・版・拠点を取得したか | Top-k内の取得有無を自社テストセットで測る |
| 拒否品質 | 根拠不足・禁止領域で答えないか | 禁止ケースは回答せず所定の代替動線を出す |
| 権限 | 他部門・他法人の情報を漏らさないか | 否定テストは漏えい0件を必須条件とする |
| 言語 | 意味、条件、否定、用語が維持されるか | 各言語の業務レビュアーが重大誤訳0件を確認 |
| 応答時間 | 利用者が待てる時間で応答するか | p50/p95を対象チャネル・時間帯で自社測定する |
| エスカレーション | 適切な条件で正しいキューへ転送するか | 重大ケースは100%転送を提案条件とする |
| 安全性 | 攻撃入力、機密要求、ツール悪用に耐えるか | 合意した攻撃セットで重大事故0件を必須とする |
上表の「0件」「100%」は、安全・権限・重大転送に対する契約時の例示基準であり、本番実績の主張ではありません。質問母集団とリスク許容度を定義し、自社の受入計画で確定してください。一般質問の品質や応答時間も、業務別の提案値をベースライン測定で補正します。
多言語テストセットの作り方
日本語を機械翻訳しただけのセットでは、現地利用者の入力を再現できません。各市場の担当者から、実際の略語、誤字、丁寧語、口語、英語混在、型式、単位、日付表記を収集します。同じ意味の対訳グループにconcept IDを付け、言語間で結論が一致するか比較します。
テストは少なくとも、通常質問、曖昧質問、複数意図、根拠なし、古い版、矛盾文書、権限なし、個人情報、prompt injection、長文、添付、連携失敗、重複イベント、有人転送を含めます。本番ログから失敗例を追加し、知識、プロンプト、モデル、検索設定、連携を変更するたびに回帰試験を行います。
TCOと見積比較：チャットボット開発費だけを見ない
初期見積は安くても、文書整備、翻訳、評価、監視、有人対応、API従量が後から増える場合があります。3年TCOなど自社の投資期間を決め、次の費用を同じ前提で比較します。
| 費用区分 | 確認項目 | 見落としやすい点 |
|---|---|---|
| 企画・設計 | 業務分析、データフロー、脅威モデル、UX | 法務・DPO・現地部門の工数 |
| 初期開発 | チャネル、RAG、SSO、連携、管理画面 | 標準外コネクタ、ネットワーク、検証環境 |
| データ整備 | 棚卸し、OCR、分割、メタデータ、翻訳 | 古い版の廃棄、図表、スキャン文書 |
| ライセンス | ユーザー、テナント、チャネル、管理者 | 最低契約、環境別費用、ゲスト |
| 従量費 | モデル入力・出力、埋め込み、検索、音声 | 長い会話、再試行、評価用トラフィック |
| 運用 | 監視、評価、更新、問い合わせ、障害対応 | 多言語レビュー、夜間休日、月次報告 |
| セキュリティ | 診断、ログ、SIEM、秘密管理、監査 | 再テスト、保存容量、インシデント対応 |
| 終了・移行 | データ出力、削除証明、再構築、教育 | ベクトル索引や評価データの可搬性 |
ベンダーへは、利用者数だけでなく、月間会話数、平均ターン、平均入力・出力、文書量、更新頻度、ピーク同時数、評価実行量、有人転送数の前提を示します。従量単価は通貨、税、為替、モデル変更、キャッシュ、上限通知、超過時の挙動まで確認します。
比較表には価格と同時に「前提差」を表示します。A社は文書整備込み、B社は顧客作業、C社は翻訳別契約であれば、合計額だけの比較は誤解を生みます。最安値ではなく、必須要件を満たす総費用、変更容易性、データ可搬性、運用責任を評価します。
90日チャットボット導入計画の例
以下は限定導入の例です。法務審査や基幹連携に時間が必要なら、日数を増やします。
Day 1–15：要件とデータ境界
- スポンサー、業務オーナー、情報オーナー、DPO・法務、IT、現地言語レビュアーを任命
- ユースケース、除外範囲、対象チャネル、言語、KPIを合意
- データフロー、権限、保持、越境、委託先を整理
- 正本文書を棚卸しし、版・所有者・機密区分を付与
- 実際の問い合わせから初期テストセットを作成
Day 16–35：RFP・選定・設計
- 同一シナリオ、同一言語、同一制約で候補を比較
- RAG、引用、権限否定、転送、監査ログのデモを確認
- SLA、セキュリティ、データ条件、TCO、終了条件を交渉
- 受入基準と変更管理を契約成果物へ入れる
Day 36–65：構築と評価
- 代表的な文書・利用者・チャネルに限定して構築
- JA/EN/TH/VIの辞書、回答スタイル、引用を調整
- 通常・拒否・権限・攻撃・連携失敗・転送を評価
- 問題をモデルだけでなく、知識、検索、権限、UX、運用へ分類
Day 66–80：限定パイロット
- 対象部門と拠点を絞り、利用者へAIの限界と転送方法を案内
- 会話をサンプリングし、誤回答、検索失敗、未解決、言語問題を日次確認
- 高リスク機能はfeature flagで無効化できる状態にする
- 現地担当者が有人キューと知識更新を運用できるか確認
Day 81–90：受入と展開判断
- 合意した固定テストとパイロットデータで受入評価
- 残余リスク、例外、運用費、未解決事項を経営へ報告
- Go、条件付きGo、延長、停止を判断
- 展開する場合も、国・部門・チャネル・操作権限を段階的に開放
よくある失敗と回避策
1. デモの自然さを精度と誤認する
流暢な回答でも、古い規程や別法人の情報を使えば業務上は誤りです。引用、版、権限、拒否を含む固定テストで比較します。
2. PDFを大量投入して完了とする
文書所有者、施行日、失効、機密区分がないと更新できません。投入件数ではなく、正本率、更新反映、検索失敗を管理します。
3. タイ語対応を自動翻訳へ丸投げする
現地の略語、コードスイッチ、製品名、労務・安全表現を現地担当者が検証します。重大な手順は承認済み現地語文書を根拠にします。
4. AIが答えられない場合の出口がない
拒否だけでは利用者の仕事が止まります。チケット、担当部署、受付時間、必要情報を案内し、会話要約を安全に引き継ぎます。
5. PoCと本番のデータ条件が違う
PoCでは匿名FAQ、本番では個人情報やERPを扱うなら、成功基準は連続しません。本番データフローと権限を前提に再評価します。
6. 従量費と有人費を見積から外す
モデル料金だけでなく、評価、監視、翻訳、知識更新、夜間対応、失敗時の再処理をTCOへ入れます。
7. モデル更新を通常変更として扱わない
モデル、検索、プロンプト、文書分割の変更は回答を変えます。版管理、承認、回帰試験、ロールバックを運用手順へ含めます。
チャットボット導入に関するFAQ
Q1. チャットボット導入の費用はどう比較すべきですか？
初期開発費だけでなく、ライセンス、モデル・検索の従量費、データ整備、翻訳、セキュリティ、監視、知識更新、有人対応、終了・移行までを同じ利用前提で比較します。ベンダーごとの除外事項と顧客作業を金額または工数として可視化してください。
Q2. チャットボット開発はRAGから始めるべきですか？
質問の多くが承認済み文書に基づき、複数文書を横断するならRAGが候補です。固定FAQで足りる案内にRAGを使う必要はありません。逆に、更新操作が目的ならRAGだけでは足りず、API権限、承認、冪等性、監査が必要です。
Q3. 多言語チャットボットでは一つのモデルで十分ですか？
モデルの対応言語だけでは判断できません。検索、埋め込み、OCR、音声、トピック、UI、分析、有人キューが各言語で機能するかを確認します。業務用語と重大手順は現地レビュアーによる受入が必要です。
Q4. タイ語チャットボットの受入試験で重要な点は何ですか？
タイ語だけの整文に加え、英語略語・製品型式との混在、表記揺れ、口語、丁寧語、誤字、短文を含めます。否定、条件、期限、責任主体、単位が維持され、正しいタイ法人・拠点・版の根拠を返すか確認します。
Q5. 生成AIが誤回答した場合、ベンダー責任にできますか？
責任は契約、要件、運用分担によって異なります。「精度保証」という抽象語ではなく、テストセット、重大度、必須拒否、権限漏えい、是正期限、ログ提供、変更通知、停止条件を契約で具体化し、法務確認を受けてください。
Q6. タイPDPA対応はクラウドの認証だけで十分ですか？
十分とは限りません。認証は確認材料の一つです。自社の処理目的、役割、入力・ログ・知識・連携先のデータフロー、越境、保持、削除、DSAR、漏えい対応、委託条件をDPO・法務と確認します。
Q7. LINEチャットボットの重複処理をどう防ぎますか？
生のリクエストで署名を検証し、早く受付応答して非同期処理へ渡します。イベント由来の冪等キーを保存し、同じイベントが再配信されてもチケットや更新を一度だけ実行します。失敗・再処理の状態遷移と監視も必要です。
Q8. 受入精度は何％に設定すべきですか？
一律の正解はありません。高リスク質問、一般FAQ、検索、言語、拒否、権限を分け、自社テストで基準値を決めます。権限漏えいや重大禁止ケースは「テスト上0件」を例示必須条件にできますが、これは本番無事故を保証する数字ではありません。
まとめ
タイ・ASEAN拠点のチャットボット導入は、モデル選びより先に、対象業務、正本、言語、権限、PDPAデータフロー、有人対応、受入試験を定義することが重要です。RFPでは標準機能と個別開発、データ条件、制限、運用責任、3年TCO等を同じ前提で比較します。RAGは根拠と権限を伴う検索システムとして設計し、AI agentの更新操作は署名、最小権限、承認、冪等性、監査を備えて段階的に開放してください。
TOMAS TECHでは、タイ・ASEAN拠点の業務整理、RFP要件化、多言語RAG、LINE・Teams・Web連携、受入テスト設計まで、製品が未確定の検討段階からご相談いただけます。自社のデータ境界や見積比較基準を整理したい場合は、お問い合わせフォームからお知らせください。
参考情報
- Microsoft Copilot Studio: Language support
- Microsoft Copilot Studio: Configure multilingual agents
- NIST AI 600-1: Generative Artificial Intelligence Profile
- OWASP Top 10 for LLM Applications 2025
- OpenAI Enterprise Privacy
- OpenAI: Our commitment to Zero Data Retention
- LINE Developers: Receiving webhook events
- LINE Developers: Verify webhook signature
- Thailand PDPC: GPPC
- Thailand PDPC: GPPC PLUS
