総務 問い合わせ 削減を実現するAI設計｜タイ拠点30日PoC

総務 問い合わせ 削減を進めたいものの、誤回答や権限漏れが心配で着手できない企業は少なくありません。成功の起点はチャットボット選びではなく、「誰に、いつ、どの根拠で答えてよいか」を管理できる回答単位を整え、AIが答えない境界まで設計することです。本稿では、タイの日系企業が30日PoCからRFP、受入、運用へ進む実務手順を解説します。

総務の問い合わせ対応を効率化する前に、負荷を測れる形にする

「総務が忙しい」だけでは、対象範囲も投資判断も決められません。最初に必要なのは、過去の問い合わせを個人評価ではなく業務設計の材料として記録することです。メール、Teams等のチャット、電話、窓口、紙の申請を同じ台帳へ寄せ、少なくとも次の項目をそろえます。

台帳では「問い合わせ件数」と「ユニークな質問」を分けます。同じ質問が20回来たなら、答えを1回整備する価値が高い一方、20種類の個別事案なら自動化より受付・振分けの改善が先かもしれません。電話や口頭相談を完全に記録できない場合も、代表期間を決めてサンプルを取り、未観測チャネルがあることを明記すれば開始できます。

ベースラインは平均だけでなく分布で見る

平均処理時間だけを見ると、短い定型質問と長い例外処理が混ざります。カテゴリ×言語×チャネルで、件数、処理時間、待ち時間、再割当、再質問を集計してください。とくに「資料はあるが見つからない」「資料同士が矛盾する」「担当者しか知らない」を分けると、検索改善、コンテンツ改訂、業務標準化のどれが必要かが見えます。

削減対象は問い合わせそのものではなく、不要な探索、同じ説明の再入力、誤所管への転送、状況確認の往復です。従業員が必要な相談まで減らすことを目標にすると、安全報告やハラスメント相談など、声を上げるべき事案を抑制しかねません。KPIには「自動回答率」だけでなく、正しい引継ぎ率、未解決率、再質問率、根拠の鮮度を含めます。

社内FAQチャットボットの中核は「承認済み回答オブジェクト」

AIにフォルダを読ませるだけでは、総務の責任ある回答にはなりません。管理すべき最小単位を、文書ファイルではなく「承認済み回答オブジェクト」として定義します。これは質問例、回答、根拠、適用範囲、例外処理をひとまとまりにした運用レコードです。

この単位なら「回答が正しいか」をテストでき、制度変更時に影響範囲を検索でき、期限切れ回答を止められます。逆に所有者、適用対象、発効日、根拠のない回答は、AIへ渡さず整備待ちキューへ送ります。AIがもっともらしく補完することを許してはいけません。

情報源の優先順位を決める

総務情報は、同じテーマでも性質が違います。推奨する優先順位は、①承認済み規程、②承認済み手順、③現行様式とワークフロー、④有効期間内の公式告知、⑤承認済みFAQです。担当者メモ、過去メール、会議チャットは、回答候補を作る材料にはなっても、そのまま正本にはしません。

• 規程は権利・義務や原則を示す。AIは根拠節と適用範囲を示し、解釈争いを確定しない。
• 手順は「何を、どこで、いつまでに」を示す。画面やフォーム変更に合わせて更新する。
• 様式は最新版へのリンクと提出条件を示す。古い添付ファイルの再配布を防ぐ。
• 告知は期間限定であり、開始日と終了日を持たせる。期限後は規程や手順へ戻す。
• 個人案件データはFAQの正本から分離する。本人確認、権限、目的を満たす制御されたワークフローで扱う。

Microsoft Learnでは、SharePointを根拠にする構成で、認証済み利用者の既存アクセスに沿って情報を検索する実装例が示されています。一方、広いSharePointパスは配下も対象にし得るため、接続しただけで安全とは言えません。対象サイト、ライブラリ、フォルダ、文書権限を絞り、権限の異なるテストアカウントで否定テストを行う必要があります。プラットフォーム名に関係なく、「取得時の権限整合」「回答生成時の引用」「ログでの露出」を別々に検証します。

自動回答・案内・人への引継ぎを分けるルーティング表

問い合わせ対応 効率化では、回答率を最大化するより、間違えたときの影響で経路を分けるほうが重要です。次の表を業務所有者と作り、PoCのシステムプロンプトだけでなく、業務手順と受入テストへ落とします。

「答えられません」で終わると、従業員は別チャネルで同じ質問を始めます。良い引継ぎは、なぜ人へ渡すのか、どの窓口へ、何を準備し、いつ反応が期待できるかを示します。ただし、苦情や通報では相談内容を一般チャットへ再入力させず、専用窓口へ直接誘導します。

所管境界を先に決める

タイ拠点では総務が広い一次窓口を担いがちですが、回答責任まで総務へ集める必要はありません。施設・来客・備品は総務、雇用条件や休暇制度は人事、アカウントはIT、事故・薬品・避難は安全/EHS、契約解釈は法務、精算ルールは経理、ローカル運用は各拠点管理者、といった所有者表を作ります。複合質問は無理に一文で答えず、回答オブジェクトを所管ごとに分け、最後に行動順序をまとめます。

既存の実装パターンを比較したい場合はチャットボット導入事例の比較を、Teamsを入口にする場合の選択肢はTeamsチャットボット／エージェントの設計を参照してください。本稿では製品選定より、どの基盤でも必要になる回答責任と受入条件に焦点を置きます。

就業規則チャットボットを4言語で運用する設計

JA/TH/EN/VI対応は、同じ文を4言語へ翻訳すれば完了する仕事ではありません。言語が等価でも、適用対象や法的・社内的な位置づけが同じとは限らないためです。日本本社の説明文、タイ法人の就業規則、工場の安全手順、駐在員規程を混ぜず、回答オブジェクトに「言語」と「適用対象」を別属性で持たせます。

たとえば日本語質問でも質問者がタイ法人の現地社員なら、表示すべき根拠は日本本社規程ではなく、その人・拠点に適用される承認済み資料です。逆にタイ語話者の委託スタッフには、直接雇用者向け制度を案内してはいけません。言語検出はアクセス権や雇用区分の代替になりません。

Microsoftの言語サポート資料では、日本語、タイ語、英語、ベトナム語が生成回答や利用者言語の対象として掲載されていますが、機能や展開チャネルによって対応段階が異なり得ます。調達時と本番移行時に、使うチャネル、認証方式、検索ソース、音声や添付の有無まで含めて再確認してください。対応言語一覧は品質保証ではありません。

言語別テストセットを作る

原文を機械翻訳しただけの同一セットでは、各言語特有の失敗を見つけにくくなります。言語ごとに現場話者が実際に使う略語、丁寧表現、綴り揺れ、タイ語と英語の混在、日本語の主語省略、ベトナム語の記号なし入力を含めます。

各言語セットには、少なくとも次の型を含めます。

1. 根拠に明記された定型質問。
2. 適用拠点や社員区分が不足した曖昧質問。
3. 古い制度名や旧フォーム名を使う質問。
4. 一つの文に総務、人事、ITが混在する複合質問。
5. 機微情報を含む個別相談。
6. 権限のない文書を狙う誘導質問。
7. 根拠に答えがない質問。
8. 同じ意味の言い換えと、意味が少し違う境界質問。
9. 混合言語、誤字、口語、略語。
10. 緊急性を示す表現。

言語品質は文法だけでなく、行動可能性、用語統一、丁寧さ、誤解しにくさ、現場のフォーム名との一致で評価します。重大な意味の差は翻訳担当だけでなく、各業務所有者が承認します。

権限・個人データ・会話ログを別々に設計する

バックオフィス 問い合わせ 自動化では、検索元に個人情報がなくても、利用者の質問や会話履歴に個人情報が入る可能性があります。Microsoft Learnは、会話トランスクリプトに質問やソース検索結果が含まれ得ることを説明しています。したがって、取得元文書、入力、生成回答、引用、検索結果、評価ログ、運用チケットを一括して「ログ」と見なさず、それぞれの目的、閲覧者、保持期間、削除方法を定めます。

permission-aligned retrievalは、設定して否定テストする実装要件です。「製品が権限漏れを防ぐ」と断定できる保証ではありません。特権利用者、一般社員、派遣、他拠点、未認証状態など複数のテストアカウントで、検索結果、引用、回答、ログのすべてを確認します。

タイの個人データ保護、通知、保持、監視、越境処理、適法な根拠については、この記事で法的結論を示しません。自社のPDPA責任者、法務、情報セキュリティおよび必要な外部専門家へ、具体的なデータフローと契約条件を提示して確認してください。ETDAの生成AIガバナンス資料は、組織がリスク管理やライフサイクル運用を考えるための自主的ガイダンスとして参照できますが、それ自体を法的義務と表現してはいけません。

社内FAQチャットボットの評価・受入基準

生成AIの回答は非決定的で、同じ質問でも表現や判断が変わり、誤りを含み得ます。MicrosoftのFAQとエージェント評価資料も、想定質問、敵対的な質問、反復可能なテスト、言語別評価の必要性を示しています。デモで一度成功したことを受入証拠にせず、固定テストセット、採点基準、実行構成、モデル版、検索設定、日時を記録します。

採点項目を分解する

「正解」という一語だけでは足りません。たとえば申請先は正しくても締切が抜ければ、従業員は再質問します。根拠は正しくても他拠点向けなら危険です。軽微な言い回し差、業務に影響する欠落、重大な誤案内、権限違反を別レベルに分類し、重大項目は平均点で相殺しない合格条件にします。

反復テストと変更時再評価

各重要ケースを複数回実行し、「何回なら十分」という普遍値を置かず、自社のリスクとばらつきを見て回数を決めます。モデル、検索設定、正本、プロンプト、チャネル、認証、言語処理のどれかを変更したら、影響する回帰セットを再実行します。OpenAI Evals APIのように、評価基準とデータスキーマを明示し、構成変更後に再実行できる仕組みは、特定製品に限らず参考になります。

NIST AI RMFとGenerative AI Profileの考え方に沿えば、利用文脈を定義し、役割を割り当て、展開に近い条件で測定し、結果を文書化し、本番を監視する流れが重要です。評価担当には開発者だけでなく、総務、人事、安全、IT、現場の言語話者を含めます。高リスク境界は独立した担当者にも確認してもらいます。

30日PoC：総務問い合わせ削減を小さく安全に確かめる

30日PoCの目的は、全社展開や削減率を約束することではありません。限定された質問群で、回答オブジェクトを維持できるか、権限と引継ぎが働くか、現場測定で事業性を判断できるかを確かめることです。

PoCの範囲例

• 1拠点、限定された従業員グループ。
• 2〜3カテゴリの低リスク反復質問。
• JA/TH/EN/VIのうち、実際に必要な4言語をすべて別テスト。
• 承認済み回答オブジェクトだけを根拠にする。
• 個人案件の回答、承認決裁、緊急通報は対象外。
• 本番業務への自動更新はせず、フォームや担当窓口へ案内する。

以下の日数や件数は説明用の仮定であり、標準値、相場、保証ではありません。自社の準備状況とリスクに置き換えてください。

役割と停止条件

責任者は、業務所有者、コンテンツ管理者、技術責任者、セキュリティ／プライバシー確認者、各言語評価者、サポート窓口、最終Go判断者を明記します。一人が複数を兼ねても、承認責任は曖昧にしません。

停止条件の例は、権限外情報の露出、緊急案件の誤誘導、対象外個人案件への断定回答、現行版より失効版を優先、監査ログが取れない、重大欠陥の再現条件が不明、などです。停止は失敗ではなく、拡大前に危険を見つけるPoCの成果です。修正後は原因、影響範囲、追加テストを記録して再開判断をします。

RFP・FAT・SATに入れる要件

製品名や「AI搭載」だけを比較すると、運用責任が契約後に残ります。RFPではシナリオと証拠を要求します。

RFPで確認する項目

1. 情報源：対象ソース、サブパス、版管理、失効、同期遅延、引用表示。
2. ID・権限：SSO、グループ、サービスアカウント、取得時権限、管理者権限、定期レビュー。
3. 多言語：JA/TH/EN/VIと混在入力、チャネル別機能差、用語集、言語別評価方法。
4. 安全境界：個人案件、緊急、争われた解釈、根拠なし質問の拒否と引継ぎ。
5. ログとデータ：入力、検索結果、回答、引用、トランスクリプト、評価データの保存場所・保持・削除・閲覧者。
6. 評価：テストデータ形式、採点、反復、回帰、モデル・設定変更時の再評価。
7. 運用：監視、アラート、インシデント、コンテンツSLA、変更承認、ロールバック。
8. 可搬性：回答オブジェクト、ログ、評価セット、設定、運用記録のエクスポート。
9. 費用：初期、利用量、連携、環境、監視、サポート、翻訳・評価、教育、終了時費用の計測単位。
10. 証拠：機能説明ではなく、自社ケースでのデモ、設定画面、ログ、テスト結果、制約一覧。

FATとSATを分ける

FAT（Factory Acceptance Test）は提供側または構築環境で、回答オブジェクトの読込、引用、ルーティング、権限設定、ログ、エクスポート、障害時動作を確認します。SAT（Site Acceptance Test）は実際の拠点、ID、ネットワーク、チャネル、言語話者、文書権限に近い条件で確認します。FAT合格はSAT合格を意味しません。

受入ケースには前提、利用者役割、入力、期待する根拠、期待する行動、禁止される結果、合否、証拠保存先を持たせます。「自然に答える」では採点できません。「権限外文書名や内容を出さず、正規窓口へ引き継ぐ」のように観測可能な条件へ変換します。

インシデント・変更・ロールバック

本番では、誤回答の報告ボタン、重大度分類、一次封じ込め、該当回答オブジェクトの停止、影響ログ検索、業務所有者への連絡、修正版承認、回帰テスト、再開を手順化します。権限漏れの疑いがあれば、回答だけを消して終わらせず、取得経路とログ閲覧範囲も確認します。

変更管理では、誰が何をなぜ変えたか、旧版、新版、承認者、発効日、影響テストを残します。ロールバックはモデルだけでなく、プロンプト、検索スコープ、コネクタ、回答オブジェクト、チャネル設定を戻せる単位で準備します。更新担当が休暇でも期限切れ回答を止められる代理承認も必要です。

自社計測だけで作る費用対効果モデル

市場平均の削減率やベンダー相場を置くと、自社業務と合わない精密そうな数字ができます。問い合わせログ、工数、実際の見積、実測利用量だけでモデルを作ります。以下の数値はすべて計算方法を示すための仮定例で、効果保証ではありません。

仮に、対象カテゴリの月間問い合わせが800件、基準の平均実処理時間が6分、PoC後に根拠付き自動完了した比率が25%、自動完了後の監視・更新相当が1件あたり1分、残る問い合わせの追加確認が平均0.5分減った、と仮定します。

• 基準工数 = 800件 × 6分 = 4,800分／月
• 自動完了分の粗削減 = 800件 × 25% × 6分 = 1,200分／月
• 自動完了分の監視・維持 = 800件 × 25% × 1分 = 200分／月
• 残件の検索改善 = 800件 × 75% × 0.5分 = 300分／月
• 例示上の純時間差 = 1,200 − 200 + 300 = 1,300分／月

ここで25%、1分、0.5分は市場値ではなく、説明用仮定です。本番判断では、PoCログから「根拠付きで完了し再質問がないケース」だけを自動完了と数えます。人へ渡しただけのケースや、後で総務が修正したケースを削減へ含めません。

月間便益の一例は、純時間差 ÷ 60 × 対象業務の社内時間単価で計算できます。ただし浮いた時間がそのまま現金化するとは限らないため、残業回避、欠員吸収、応答改善、再作業回避など、どの便益に転換できるかを分けて記録します。

総費用は、初期構築 + 連携 + コンテンツ整備 + 4言語評価 + セキュリティ／法務確認 + 教育 + 月額利用 + 監視運用 + 改訂工数 + インシデント対応 + 終了／移行費用です。見積は単価だけでなく、ユーザー数、メッセージ数、モデル利用量、保存量、環境数、サポート時間など課金単位を合わせます。

単純な回収月数は、初期費用 ÷（月間測定便益 − 月間継続費用）です。分母がゼロ以下なら回収月数を出さず、範囲縮小、運用改善、停止を検討します。上限・基準・下限の3シナリオを自社実測の信頼区間に応じて作り、削減率を都合よく固定しません。

運用開始後に総務へ負債を戻さない仕組み

導入直後に回答できても、制度やフォームが変われば品質は落ちます。社内ヘルプデスクAIで旧版回答を防ぐ方法も参考にしつつ、総務向けには「変更イベントから回答オブジェクトを更新する」仕組みを明確にします。

• 規程改訂、フォーム更新、拠点追加、組織変更、祝日告知、災害対応変更を更新イベントとして登録する。
• 所有者へ期限前通知し、未承認なら自動回答を停止または人へ引き継ぐ。
• 利用者の低評価をそのまま正解扱いせず、根拠不足、表現、検索、所管違いに分類する。
• 月次で高頻度未解決、再質問、誤引継ぎ、期限切れ、権限否定テストをレビューする。
• モデルや連携変更の前後で固定回帰セットを実行する。
• 四半期など自社で決めた周期でアクセス権と管理者権限を棚卸しする。

人事固有の設計は人事問い合わせAIの三層設計へ分け、本システムでは総務が一次受付でも人事の回答所有権を奪わないようにします。FAQを増やすことより、期限切れを止め、所有者不明を可視化し、例外を正しい担当へ届けることが長期的な問い合わせ対応 効率化につながります。

FAQ：総務・社内FAQ・就業規則チャットボット

総務 問い合わせ 削減は何から始めるべきですか？

製品比較ではなく、代表期間の問い合わせログをカテゴリ、言語、チャネル、実処理時間、再質問、再割当、根拠資料の有無で分類してください。その後、低リスクで反復性が高く、承認済み根拠を持つ質問だけをPoC候補にします。個別相談や緊急案件を混ぜないことが重要です。

社内FAQ チャットボットにすべての社内文書を読ませてもよいですか？

推奨しません。広いソース範囲は不要な下位フォルダや権限制限文書を含む可能性があります。正本の優先順位、対象フォルダ、適用拠点、版、失効日を決め、権限の違うアカウントで取得、引用、回答、ログを否定テストしてください。

問い合わせ対応 効率化は自動回答率だけで評価できますか？

できません。誤回答を増やして自動回答率だけ上げても成果ではありません。根拠付き完了、再質問、待ち時間、正しい引継ぎ、未解決、重大誤案内、情報鮮度、コンテンツ更新工数を合わせて評価します。

就業規則 チャットボットは4言語を同じテストで評価できますか？

共通の意図は持てますが、翻訳した同一セットだけでは不十分です。JA/TH/EN/VIごとに現場表現、略語、混合入力、曖昧さを含むテストを作り、言語品質と業務上の意味を別々に確認します。翻訳の等価性は規程の適用等価性を保証しません。

バックオフィス 問い合わせ 自動化で個人情報を扱えますか？

扱う可能性があるなら、FAQ検索と個人案件ワークフローを分離し、本人確認、アクセス、目的、保持、削除、ログ閲覧、越境処理を具体化してください。給与、医療、懲戒、苦情、調査などは自動回答せず、制御された人の窓口へ渡します。適法性は自社のPDPA／法務責任者へ確認が必要です。

30日PoCで本番効果を保証できますか？

保証できません。30日PoCは、限定範囲でデータ、回答オブジェクト、権限、評価、運用負荷を確認する意思決定材料です。削減率やROIは自社の実測値を使い、対象拡大後の変化を継続測定してください。

RFPではベンダーに何を提出してもらうべきですか？

機能一覧だけでなく、自社テストケースに対する回答、引用、権限否定テスト、ログ、構成変更後の再評価、障害時の引継ぎ、データのエクスポート、制約一覧を証拠として求めます。FATとSATの合否条件、重大欠陥、変更・ロールバック手順も契約前に定義します。

まとめ：削減率より、答えてよい単位と境界を作る

総務の問い合わせを安全に減らす中心は、AIモデルではなく、所有者、適用対象、発効日、根拠、例外経路、見直し日を備えた承認済み回答オブジェクトです。ログで負荷を測り、自動回答・フォーム・人への引継ぎ・自動回答禁止を分け、4言語と権限を別々に試験します。30日PoCは万能な効果を約束する場ではなく、自社データでGo／停止を判断できる証拠を作る場です。

タイ拠点での総務FAQ、情報源整理、4言語受入テスト、RFPのどこから始めるべきかを検討中でしたら、構想段階でもTOMAS TECHへご相談ください。現行資料と問い合わせログを基に、対象範囲と人へ残す判断を一緒に整理できます。

参考資料（一次・公式情報）

1. Microsoft Learn, Use SharePoint content for generative answers
2. Microsoft Learn, FAQ for generative answers
3. Microsoft Learn, About agent evaluation
4. Microsoft Learn, Language support
5. Microsoft Learn, Add a generative answers node
6. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
7. NIST AIRC, AI RMF Core
8. ETDA, Generative AI Governance Guideline for Organizations v2
9. ETDA, タイにおけるAIガバナンスの公式概要
10. OpenAI, 評価（Eval）の作成