社内問い合わせ対応のAI自動化｜情シス・管理部門が何割を任せられるか

どの問い合わせを引き受けられるか

最初に任せられるのは、答えが規程やマニュアルにそのまま書いてある質問です。条件で分岐するもの、個別の状態を見ないと答えられないもの、決裁が絡むものは人が持ちます。

情シスや管理部門に集まる問い合わせは、内容の難しさよりも「同じ質問が繰り返し届く」ことで時間を取ります。答えは規程やマニュアルに書いてあり、担当者は毎回同じ箇所を探して同じ説明を返しています。

一方で、すべてを機械に渡せるわけではありません。個別の契約や権限の状態を見ないと答えられないもの、例外の承認が必要なものは残ります。自動化を検討するときは、まず届いている問い合わせを性質で分けます。

問い合わせの性質	判断の材料	扱い
文書に答えがそのまま書いてある	記述を示せば用が足りる	社内QAチャットで回答する
手順は決まっているが条件で分岐する	分岐の条件が文書化されているか	条件を聞き返して案内し、確定できなければ人へ渡す
個別のデータや権限の状態を見ないと答えられない	参照先が文書ではなくシステム	当面は担当者へ渡す。将来の接続対象として記録する
例外の許可や費用の発生を伴う	決裁が関わる	人が判断する。案内は申請先までにとどめる
前例がなく文書に記述が無い	判断そのものが新しい	人が対応し、決めた内容を文書へ残す

1行目だけが自動化の対象で、2行目以降は人が持つ、という切り方から始めると設計が単純になります。件数の内訳を数えると、1行目が想定より多いことも、逆に少ないことも分かります。数える前に対象を決めると、答えられない質問ばかり届く仕組みができます。

過去の問い合わせがチャットやメールに散っている場合は、直近1か月分を読んで分類するだけで足ります。全期間を集計する必要はありません。

何割を寄せられるかを自社の内訳から出す

他社の比率を当てにしても判断材料になりません。同じ「社内問い合わせ」でも、規程の整備状況と扱う業務で内訳が変わります。自社の数字は上の分類から2つ出せます。

出す数字	計算の仕方	何の判断に使うか
寄せられる上限	文書に答えがある件数 ÷ 全件	着手する価値があるかを決める。低ければ先に文書を整える
実際に寄った割合	チャットで完結した件数 ÷ 全件	公開後の効き方を見る。上限との差が改善の余地

上限は着手前に出せます。直近1か月分を分類して、1行目に入った件数を全件で割るだけです。この値が、仕組みが完全に動いたときに人の手から離れる件数の見込みになります。

実際に寄る割合は必ず上限より低く出ます。入口が使われない、文書に記述はあるが引けない、質問の書き方が想定と違うといった理由で差が生まれます。上限を先に出しておくと、公開後にこの差が何件分あるかを見て、文書側と入口側のどちらを直すかを決められます。上限そのものを上げたい場合は、2行目以降の性質の問い合わせに対応する文書を書き足す作業になり、仕組み側の調整では動きません。

散在する文書を検索できる形に整える

回答の質は、参照する文書の状態でほぼ決まります。文書が整っていない状態で検索の仕組みだけを作っても、答えられない質問が増えるだけです。整える手順は次の順です。

1. 対象を棚卸しする。 規程、マニュアル、申請の手引き、過去の問い合わせへの回答が、どこに何件あるかを一覧にします。この時点で同じ内容の資料が複数の場所にあることが見えます。

2. 正本を1つに決める。 同じ主題の文書が複数あるなら、どれを有効な版とするかを決め、それ以外は検索の対象から外します。ここを飛ばすと、古い版を根拠にした回答が出ます。

3. 検索の単位に分割する。 100ページの規程を丸ごと1件として扱うと、質問に関係のない箇所まで一緒に引かれます。見出し単位で区切り、どの文書のどの節かが分かる形にします。

4. 文書に適用範囲を書く。 対象者、適用される期間、対象外の条件を文書の側に明記します。「誰に当てはまるか」が書かれていない文書は、質問者ごとに違う答えを返せません。

5. 更新の担当を決める。 文書ごとに、内容を直す責任を持つ人を1人決めます。文書の追加より、この割り当てのほうが後々効きます。

表形式の資料や画面の操作手順を画像で説明している資料は、そのままでは検索に乗りません。文章として書き直すか、当面は対象外にするかを決めます。全部を整えてから始めようとすると着手できないため、件数の多い質問に対応する文書から順に進めます。

文書のアクセス権が部署や役職で分かれている場合は、検索の時点で質問者の権限を反映させます。権限を無視して全文書を対象にすると、本来見えない情報が回答として出ます。権限で絞れない文書は、対象から外しておくほうが安全です。

回答の根拠を示す作りにする

社内の問い合わせでは、答えの内容だけでなく「どの規程のどこに書いてあるか」が必要になります。回答を受けた人が自分で確かめられ、後から経緯を追えるためです。回答には次を添えます。

参照した文書の名称と、該当する節へのリンク
引用した箇所そのもの（要約ではなく原文）
文書の最終更新日
該当する記述が見つからなかった場合は、その旨

最後の項目が重要です。根拠が見つからないときに、それらしい文章を返してしまう作りにすると、間違いが混ざったまま社内に流通します。「見つからなかった」と返して人へ渡す動作を、正常な結果として扱います。

回答の言い回しを整えることより、根拠の提示と「答えない」判断のほうが先です。文面の調整は後から効きますが、根拠のない回答は一度出ると信用が戻りません。

人へ渡す境界を決める

境界は質問の難しさではなく、根拠を示せるかどうかで引きます。文書の該当箇所を出せない質問は、答えの見当が付いていても人へ渡します。

答えられない質問を人へ渡す経路を、最初から作り込みます。ここが無いと、答えの出なかった質問がそのまま宙に浮きます。

渡す先が社外になる問い合わせは、同じ考え方でも自動で返してよい範囲が狭くなります。フォームやメールで届く社外からの問い合わせを一次返信し、面談の日程調整まで進める設計は問い合わせの一次返信と面談の日程調整をAIで自動化するで扱っています。

根拠が見つからなかった質問は、人へ渡すのと同時に未回答として記録し、文書側の修正につなげます。

渡すときに決めておくのは3点です。誰に渡るか（担当者個人ではなく、チャネルや窓口に渡す形にする）、渡す情報（質問の文面と、検索で当たった候補まで引き継ぐ）、戻す期限（一定時間で応答が無い場合の扱い）です。

人が答えた内容を文書へ戻す経路も、この段で決めます。戻す仕組みが無いと、同じ質問が翌月も人へ渡ります。回答した本人が文書を直すのか、内容を記録して別の担当が月次でまとめて直すのかを決めておきます。

精度が合わないときの切り分け

公開後に「答えが合わない」という声が出たとき、原因は文書側と検索側のどちらかに寄ります。混ぜて対処すると直し方を間違えます。

起きていること	疑う場所	確かめ方と直し方
記述があるのに「分かりません」と返る	検索側	その文書が検索の対象に入っているかを確認する。分割の単位が粗く該当箇所が埋もれていることが多い
古い内容を根拠に回答する	文書側	旧版が残っている。正本を1つに決め、旧版は対象から外す
質問と関係のない節を引いてくる	検索側	見出し単位で区切り直し、文書名と節をメタ情報として持たせる
略語や社内用語で聞くと当たらない	文書側	呼び方が揃っていない。言い換えの対応表を持たせるか、文書に正式名称と略称を併記する
部署ごとに答えが違うべき質問に一律で答える	文書側	適用範囲が書かれていない。対象者と条件を文書へ明記する
断定的に答えるが文書に根拠がない	作りの問題	根拠が見つからないときは答えない動作にする。回答文の調整では直らない

切り分けの材料になるのは、実際に来た質問と返した回答、そのとき参照した文書を対にして残した記録です。これを残していないと、原因の議論が「精度を上げる」という漠然とした話に流れます。記録は最初から取ります。

直す優先順位は、件数の多い質問から決めます。1件しか来ていない質問に合わせて仕組みを変えると、多くの質問に対する答えが崩れることがあります。

更新が止まった資料をどう扱うか

社内文書を集めると、必ず「いつの内容か分からない資料」が出てきます。数年前に作られ、その後の運用が変わっているかどうかが本人にも分からないものです。これを放置すると、根拠を示した回答が結果的に誤りになります。

扱い方は3つに分かれます。内容が今も有効だと確認できたものは、確認日を記録して対象に残します。有効でないと分かったものは、検索の対象から外します。判断が付かないものが問題です。無理に有効と決めず、対象から外して質問が来たら人へ渡す形にします。「答えられる範囲を狭める」判断は、間違った根拠を出すより安全です。

一定期間更新されていない文書に印を付け、担当者へ確認を促す運用を組んでおくと、判断が付かない文書が増え続けるのを抑えられます。文書の量が多い場合は、実際に参照された回数の多いものから確認します。参照されていない文書を先に整えても、回答は変わりません。

着手の順序

進める順序は次の形になります。

直近1か月分の問い合わせを分類し、文書に答えがあるものが何件かを数える
その件数の多い質問に対応する文書だけを整える。全文書を待たない
根拠の提示と、答えられないときに人へ渡す経路を作る
対象者を限って公開し、質問と回答の記録を取る
記録を見て、文書側と検索側のどちらを直すかを判断する
対象の質問を広げる

3の経路を作る前に公開すると、答えられない質問が行き止まりになり、使われなくなります。4で対象者を限るのは、初期の回答品質が低い段階で全社に開くと、一度離れた人が戻らないためです。

社内で生成AIを使う前提としての入力ルールや利用可否の線引きは、生成AIの社内利用ルールをどう作るかで扱っています。QAチャットは社内文書を扱うため、どの機密度の文書までを対象にするかをここで決めておきます。

検証から本番運用へ進める際の判断基準や見積の考え方は、AIエージェント開発の進め方を参照してください。問い合わせ対応は入口と出口が明確なため、最初の題材にしやすい業務です。

削減できた時間をどう測るかは、AI導入の効果測定と投資判断の考え方が使えます。問い合わせの件数と、人へ渡った割合の推移が判断の材料になります。

まとめ：社内問い合わせをAIに引き受けさせるときの要点

届いている問い合わせを性質で分け、文書に答えがそのまま書いてあるものだけを最初の対象にする
何割を寄せられるかは直近1か月分の内訳から出す。着手前に上限を出し、公開後に実際に寄った割合と比べる
人へ渡す境界は質問の難しさではなく、根拠を示せるかどうかで引く
文書は「棚卸し→正本を決める→検索の単位に分割→適用範囲を書く→更新の担当を決める」の順で整える。全部を整え終える前に着手する
回答には参照した文書と原文、最終更新日を添える。根拠が見つからないときは答えずに人へ渡す
人へ渡す経路は、渡す先と引き継ぐ情報と戻す期限を決めておく。人が答えた内容を文書へ戻す経路も同時に作る
答えが合わないときは文書側と検索側に切り分ける。そのために質問と回答と参照文書の記録を最初から取る
有効か判断が付かない資料は対象から外す。答えられる範囲を狭めるほうが、誤った根拠を出すより安全

Augueでは、社内文書の検索を含むAIエージェントの開発に対応しており、どこまでを自動で回答しどこから人が引き取るかの線引きから一緒に設計できます。自社の問い合わせのどれを対象にできるか判断したい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

社内Wikiの検索機能を強くするのと、AIのQAチャットを作るのはどちらが先ですか？

文書の置き場所が複数に分かれている場合は、正本をどこに置くかを決める作業が先になります。検索の仕組みを変えても、同じ内容の資料が別の場所に残っていれば、どちらが有効か分からないという状態は解消しません。置き場所と更新の担当が決まっていれば、QAチャットの構築と並行して進められます。

従来のキーワード検索型の社内FAQシステムとの違いは何ですか？

キーワード検索は、質問者が使った語が文書に含まれているかで当たり外れが決まります。社内では同じ対象を人によって違う語で呼ぶため、正しい語を知っている人しか探せません。文章で質問できる形にすると、語が一致しなくても意味の近い箇所を引けます。代わりに、引いた箇所が本当に根拠になっているかを確かめる仕組みが必要になります。

導入の費用と期間の目安はどれくらいですか？

一律の金額は出せません。対象文書の量と形式、既存システムとの接続の有無で変わります。見積を比べる材料としては、文書を整える工程が誰の作業として含まれているか、公開後に回答の記録を見て直し続ける費用が入っているかを確認します。この2つが抜けた見積は、動き出したあとで追加になります。

社外のAIサービスに社内文書を渡してよいかは、どう判断しますか？

文書の機密度と、利用するサービスの契約形態を突き合わせて判断します。入力したデータが学習に使われない契約になっているか、保存場所と保存期間がどうなっているかを確認します。最も機密度の高い区分は当面対象から外し、扱える区分だけで始める形が取りやすいです。

チャットを用意したのに、担当者へ直接聞く人が減らない場合は何を見ますか？

見るのは3つです。質問件数がどう推移しているか、回答できずに人へ渡った割合、そして人へ渡ったあとの質問がどんな内容かです。回答できない質問が多いなら文書側の不足、回答はできているのに使われないなら入口の場所か初回の体験に原因があります。切り分けずに機能を足すと、使われないまま残ります。