社内の問い合わせは4つの型に分かれる｜AIに渡す線を型で決める

「問い合わせが多すぎて手が回らない」「AIで自動化したいが、どこまで任せてよいか分からない」——情報システム部門からよく上がる2つです。別々の悩みに見えて、行き詰まっている場所は同じです。届いているものを分けないまま、全体を1つの塊として数えていることです。社内の問い合わせは、件数で語れるほど均一ではありません。本当は答えを出すのに何が必要かで4つの型に分かれていて、型ごとにAIへ渡してよい線も、個人情報の扱いも、間違えたときに元へ戻せるかどうかも変わります。この記事では、その4つの型の見分け方と、型ごとに変わる扱いを整理します。

「問い合わせが多い」の前に、届いているものを分けていない

問い合わせの負担を軽くしたいという相談で、最初に出てくるのは月あたりの件数です。ところが件数を聞いても、次の一手は決まりません。件数は、中身が均一な集まりでなければ意味を持たない数字だからです。手順書を開けば終わる質問と、原因を突き止めないと終わらない不具合を同じ1件として足しても、そこから何をすべきかは出てきません。

実際に一覧を開くと、性質のまったく違うものが並んでいます。休暇の残りを聞く質問、印刷ができないという申告、新しい担当者に権限を付けてほしいという依頼、外部のサービスを使ってよいかという相談。これらはかかる時間も、答える人も、間違えたときの被害も違います。同じ列に並んでいるのは、同じ窓口に届いたという理由だけです。

だから最初にやるのは、減らす工夫ではなく分けることです。分けてはじめて「この型は増えているが、こちらは減っている」が見えるようになり、どの型から手を付けるかという議論ができるようになります。分けないまま自動化の話を始めると、いちばん厄介な型を基準にして「AIには無理だ」と結論するか、いちばん簡単な型を基準にして「全部任せられる」と結論するかのどちらかになります。

部門別・システム別に分けても、扱いは決まらない

分類の話をすると、たいてい業務領域別の案が出てきます。情報システム関連、人事関連、経理関連、施設関連。公開されている問い合わせ分析の記事でも、この切り口はよく使われます。実際、集計の単位としては役に立ちます。ただしこの軸で分かるのは誰の担当かということだけで、どう答えるかは決まりません。

システム別も同じです。ある業務システムに関する問い合わせという束の中に、使い方の質問と、その人の端末だけで起きる不具合と、利用者を追加してほしいという申請が全部入ってしまいます。担当が同じでも、答え方が同じとは限らない。だから担当を決める軸と、答え方を決める軸は、別に持つ必要があります。

そこで本記事が使う軸が「答えを出すのに何が必要か」です。文書を見れば足りるのか、その人の状況を聞き出さないと足りないのか、権限を持つ人の手続きが必要なのか、誰かが可否を決めなければならないのか。この問いで分けると、AIに渡してよい範囲がそのまま決まります。担当の軸と組み合わせて、1件に2つの札を付ける形にすると、集計と運用の両方が成立します。

答えを出すのに何が必要かで、4つの型に分かれる

この軸で直近の問い合わせを読んでいくと、社内に届くものはおおむね4つに落ち着きます。名前は社内で通じるものにしてかまいませんが、境目の定義だけは1枚に書いて固定します。境目が人によって動くと、後で数えても比べられなくなります。

型	答えを出すのに必要なもの	よくある中身	答えが1つに定まるか
定型	文書を開くこと	休暇の残り、経費の申請の手順、社内の仕組みへの入り方	定まる
環境に依存	その人の状況を聞き出すこと	つながらない、開けない、印刷できない	人によって変わる
権限が要る	権限を持つ人の手続き	利用者の追加、権限の付与、機器の貸し出し	定まるが、答えでは終わらない
判断が要る	誰かが可否を決めること	新しいサービスの利用可否、外部との共有の可否	前例がなければ定まらない

この4つは、公開されている導入の記録で「効きやすい」とされる問い合わせと「人の判断が要る」とされる問い合わせの分かれ目にもきれいに重なります。頻度が高く回答が定まっているものとして挙がるのは、休暇の残り、経費の申請の手順、端末が起動しないときの最初の確認、社内の仕組みへの入り方。いずれも定型です。一方、全体で起きている不具合、環境に依存する事象、業務要件の確認、安全にかかわる可否——これらは残りの3つの型に散っています。

注意したいのは、型が問い合わせの難しさを表してはいないことです。定型の中にも調べるのが面倒なものはありますし、判断が要る型でも前例があれば数分で終わります。型が表しているのは、答えにたどり着くまでに何を経由するかという道筋です。だから型ごとに、AIに任せられるところと人が出るところが変わります。

型1・定型：答えが文書のどこかに書いてある

定型は、答えが既に文書のどこかに書かれている型です。聞かれているのは新しい情報ではなく、どこに書いてあるかです。この型の特徴は、同じ質問が言い方を変えて何度も届くこと。直近の問い合わせを数十件読むと、同じ内容が3通り4通りの言い方で並んでいるのが見つかります。

この型で問い合わせが減らない原因は、たいてい書いてある側にあります。文書は存在するのに、探し方が分からない。あるいは文書が古くて、書いてある画面と実物が違う。だから聞くほうが速い。聞くほうが速いという状態が続くかぎり、件数は減りません。減らすには、書いてある内容を直すか、たどり着き方を変えるかのどちらかが必要です。

AIに渡してよい範囲も、この型がいちばん広くなります。文書を根拠にして案内するところまでは任せられます。ただし条件が一つあり、根拠にした文書の名前と最終更新の日付を必ず添えさせることです。添えられないなら案内させません。AIは古い手順を自信を持って案内してくるので、日付が見えていれば送る前の人が一目で気づけます。例外の申請や、文書に書かれていない特別な事情が絡む件は、この型から外して扱います。

型2・環境に依存：同じ質問でも答えが人ごとに変わる

環境に依存する型は、聞かれている文面が同じでも答えが人ごとに変わります。つながらない、開けない、印刷できない。文面には「できない」しか書かれていないのに、原因は端末の設定、回線、権限、他の利用者との重複、そもそも全体で起きている不具合まで散らばります。答えを先に出そうとすると必ず外します。

この型で必要なのは答えではなく、状況を聞き出すことです。他の端末でも同じことが起きるか。社外からつなぐ仕組み（VPN）を切っても起きるか。いつから起きているか。直前に何かを入れたり設定を変えたりしたか。この4問で原因の範囲はかなり狭まります。そして聞き出した内容が人に渡るときに一つ残らず引き継がれることが、この型のいちばんの要点です。引き継がれないと担当者が同じ質問をもう一度することになり、次からは窓口を使ってもらえなくなります。

もう一つ、この型には全体で起きている不具合が混ざり込むという特徴があります。同じ文面の申告が短時間に何件も届いたときは、個別の切り分けをしても意味がありません。件数の急な増え方を見て、個別の応答から告知に切り替える手を用意しておきます。公開されている問い合わせ分析でも、週の単位で見ることで急増に早く気づけると整理されています。月にまとめて見る運用だと、気づく前に問い合わせの山が来ます。

型3・権限が要る：聞いているのは答えではなく手続き

権限が要る型は、質問の形で届きますが、求められているのは答えではありません。利用者を追加してほしい、権限を付けてほしい、機器を貸してほしい。相手が欲しいのは説明ではなく、状態が変わることです。ここを取り違えて丁寧な説明だけを返すと、同じ人からもう一度届きます。

この型でAIに任せられるのは、受け付けと不足の確認までです。申請に必要な項目がそろっているか、承認する人の名前が入っているか、期間が書かれているか。そろっていない申請を、そろえてから人に渡すだけで、担当者の手戻りは大きく減ります。逆に、付与そのものは人の手続きとして残します。理由は次の項と、後の「戻せるか」の話でもう一度触れます。

この型には、期限と有効期間という要素が付いてきます。いつから必要か、いつまで必要か。期限のない権限の依頼は、実質的に永久の依頼になります。受け付けの段階で期間を必ず聞く形にしておくと、後から棚卸しをするときの負担がまったく変わります。短期の応援や外部の関係者が絡む依頼では、この項目が抜けやすいので、入力を省略できない形にしておきます。

型4・判断が要る：前例がなく、誰かが決めなければ進まない

判断が要る型は、答えがまだどこにも存在しない型です。この新しいサービスを業務で使ってよいか。この資料を外部と共有してよいか。この機能を有効にしてよいか。文書を探しても答えは出てきません。誰かが決めて、はじめて答えになります。

この型でAIに任せられるのは、判断の材料をそろえるところまでです。過去に似た申請があったか、そのときどう決まったか、社内の規程のどこに関係するか。結論を1語で返させるのをやめて、候補と根拠を並べさせる。この形にすると、人は読むだけで確認でき、判断の速度はかえって上がります。結論だけを返させると、合っているかを人が最初から考え直すことになります。

そして、この型ではAIに結論を出させないという線を明示的に引きます。人の処遇にかかること、お金が動くこと、外部に出ること、元へ戻せないこと。この4種類は、材料の整理までで止めます。あわせて、人が確認する範囲も先に決めておきます。どの申請を誰が読むのか、根拠がそろわなかった件はどう扱うのか。全件を読む前提にすると確認そのものが新しい負担になるので、根拠が付かなかった件だけを必ず読む形にしておくと続きます。

申告の文面から型を当てる、3つの手がかり

型の定義を決めても、届いた文面から型を当てられなければ運用になりません。実際の文面は「例のシステムが動きません、至急お願いします」のように短く、必要な情報が入っていないことが普通です。それでも、手がかりは3つあります。この3つを順に当てるだけで、大半の件は型が決まります。

1つめは、文面に固有の状況が書かれているかどうかです。自分の端末、自分の画面、昨日から、といった語が入っていれば環境に依存する型を疑います。逆に手順や条件を一般形で聞いていれば定型です。2つめは、求めているのが情報か、状態の変化か。追加してほしい、変えてほしい、外してほしいという依頼形なら権限が要る型です。3つめは、社内に前例があるかどうか。新しい名前のサービスや、初めて出てくる相手先が含まれていれば判断が要る型を疑います。

この3つを当てても決まらない件は、必ず出ます。そのときに迷ったものを入れる未分類の枠を用意しておくのが実務の要点です。無理にどれかへ寄せると定義が緩み、後から数えても比べられなくなります。未分類の枠に入った件の割合は、定義の粗さを表す数字として使えます。ここが2割を超えるようなら、型の境目を書き直す合図になります。

型を取り違えると、何が起きるか

型の区分が実務で効くのは、取り違えたときに起きることが型ごとに違うからです。すべての取り違えが同じ重さではありません。軽いもので済む方向と、事故になる方向があります。方向を知っておくと、どこを厚く確認すべきかが決まります。

• 定型として扱った件が、実は判断が要る型だった：前例のない可否に、文書を根拠にした案内が返る。いちばん危ない取り違え
• 定型として扱った件が、実は環境に依存する型だった：本人が的外れな手順を試し、時間だけが失われる
• 環境に依存する型として扱った件が、実は全体の不具合だった：一人ずつ切り分けを始め、告知が遅れる
• 権限が要る型を、定型として扱った：説明だけが返り、状態が変わらないので同じ依頼が繰り返される
• 判断が要る型を、権限が要る型として扱った：可否を決めずに手続きが進み、後から止められなくなる

この5つのうち、確認を厚くすべきなのは1つめと5つめです。どちらも誰も可否を決めていないのに話が前に進んでしまうという共通点があります。逆に2つめと3つめは、時間の損失で止まります。痛いことは痛いのですが、元へ戻せます。取り違えの被害が戻せるかどうかで、確認の重さを変えるのが現実的な配分です。

なお、取り違えは人が分けても起きます。公開されている問い合わせ分析でも、手作業での分類は担当者ごとにばらつくと整理されています。ばらつきを消すために定義を細かくすると、今度は当てるのが難しくなる。だから境目の数は増やさず、迷ったものを受け止める枠を残すほうが安定します。

個人情報の線は、人の属性ではなく型で切る

社内の問い合わせには、氏名、所属、端末の識別子、入退社の予定、体調の事情まで混ざります。だから誰が見てよいかを決める必要がありますが、人の属性で線を引くと運用が破れます。役職や部門で見える範囲を切ると、兼務や異動、期間限定の応援のたびに設定が追いつかなくなるからです。

型で切ると、この問題が起きにくくなります。人の処遇や体調に関わる相談は、そもそも情報システム部門の窓口に入れない。人事や産業医の窓口へ最初から流す。AIに読ませない情報は、設定で隠すより、届かせないほうが確実です。窓口を分けるのは技術の仕事ではなく告知の仕事なので、費用もほとんどかかりません。そして届かないものは、設定の間違いでも漏れません。

型ごとに混ざりやすい情報も違います。定型はほとんど混ざりません。環境に依存する型には端末の識別子や画面の写しが付いてきます。権限が要る型には氏名と所属、入退社の予定が入ります。判断が要る型には取引先の名前や未公開の計画が入ります。型が分かった時点で、その件にどの種類の情報が入っているかも大方分かるので、扱いを型に紐づけておけば個別の判断が要りません。

• 人の処遇、健康、家族の事情に関わる相談は、情報システム部門の窓口に入れない（入口の段階で分ける）
• AIに読ませる範囲は、権限の設定ではなく届く範囲で絞る（届かないものは漏れない）
• 端末の識別子や位置の記録は、単体では誰か分からなくても人に関する情報として扱う
• 外部のサービスに問い合わせの文面を渡す場合は、社内の規程と契約の条件を先に確かめる
• 画面の写しには、隣に開いていた別の資料が写り込む。添付を受け取る型では注意書きを添える

元へ戻せるか戻せないかを、型ごとに振り分ける

型が決まると、もう一つ自動的に決まるものがあります。その件を処理して間違えたときに、元の状態へ戻せるかどうかです。ここは型と一対一ではないので、型の中でさらに二つに割ります。割ってしまえば、どこまでを自動で流してよいかは考えるまでもなく決まります。

型	元へ戻せる側にあるもの	元へ戻せない側にあるもの
定型	案内を送る、資料の場所を伝える	誤った手順を案内し、本人が実行してしまう
環境に依存	確かめる順番を尋ねる、状況を記録する	設定を書き換えてしまう
権限が要る	申請を受け付ける、不足を確かめる	権限を付与する、利用を停止する
判断が要る	過去の事例と根拠を並べる	可否を決めて相手に伝える

表を作ると、戻せない側にあるものの共通点が見えます。相手や仕組みの状態が変わってしまう行為です。案内を送るのは戻せますが、案内どおりに実行されたら戻せません。だから定型でも、実行を伴う案内は戻せない側に置きます。戻せるかどうかは、こちらの操作ではなく相手に起きる変化で判定するのが、外しにくい見方です。

この振り分けを1枚にしておくと、社内の合意が取りやすくなります。「自動で流してよいのは、この表の左側だけ」と1文で言えるからです。そして表に載っていない行為は、左側とも右側とも決まっていないので対象外にします。後から足すときは、また合意を取る。この面倒さが安全弁になります。面倒がないと、気づかないうちに右側の行為が混ざります。

1件に2つの型が混ざるときの扱い

実務でいちばん多い困り方が、1件に複数の型が混ざることです。「新しい担当者が入るので、権限を付けてほしい。あと、あのサービスも使えるようにしてほしい」——前半は権限が要る型、後半は判断が要る型です。この1件を1つの型に押し込むと、必ずどちらかが落ちます。

扱い方は決まっていて、混ざった件は分けます。1件を2件にして、それぞれに型を付ける。手間が増えるように見えますが、押し込んだ場合の手戻りのほうが大きくなります。とくに危ないのは、権限が要る型と判断が要る型が混ざった件を、権限の依頼として処理してしまうこと。可否を誰も決めないまま手続きが進み、後から止められなくなります。

分けるときの原則は、重いほうの型を残して軽いほうを切り出すことです。判断が要る型が混ざっていれば、その部分を独立させて可否の判断に回し、残りを先に処理する。そうすれば、待たせなくてよい部分だけ先に進みます。申告した本人にも、どちらが進んでどちらが止まっているかを伝えられるので、催促の問い合わせも減ります。1件を分けたことは、元の件と結び付けておきます。

型ごとの確認項目一覧

型が決まった時点で、確かめるべきことも決まります。窓口で最初に聞く項目を型ごとに用意しておくと、聞き漏らしがなくなり、人に渡すときの引き継ぎもそろいます。型を判定する前の共通の項目は、申告者と発生の時期だけで足ります。

• 定型：何をしようとしているか／どの手順書を見たか／見た手順書と画面が違っていたか
• 環境に依存：他の端末でも起きるか／社外からつなぐ仕組みを切っても起きるか／いつから起きているか／直前に入れたもの、変えた設定はあるか
• 権限が要る：対象者の氏名と所属／必要な範囲／いつから／いつまで／承認する人の名前
• 判断が要る：対象の正式な名称／使いたい目的／扱う情報の種類／相手先／急ぐ理由と期限
• 全型に共通：申告者と連絡の付く手段／発生または依頼の時期／急ぐかどうかの自己申告
• 混ざっている場合：どの部分を先に進めてよいか（分けるときの判断に使う）

この一覧は、AIに聞き取りを任せるときの台本にもなります。台本があると、聞く順番が人によって変わりません。ただし、項目を増やしすぎると本人が離脱します。環境に依存する型は4問、その他は3問を上限にして、そろわなければ人に渡すという線を先に引いておきます。

項目の中で軽く見られやすいのが、権限が要る型の「いつまで」と、判断が要る型の「扱う情報の種類」です。この2つが空欄のまま流れた件は、後から必ず調べ直しになります。入力を省略できない形にしておくと、聞き直しの往復が消えます。

型の一覧は、作った日から古くなる

型の区分は、一度作れば終わりというものではありません。社内で使う仕組みが増えれば新しい型が要るように見え、業務のやり方が変われば境目が動きます。ところが型の数を増やすほど、当てるのが難しくなります。だから増やすのではなく、分け直す。そのための作り方と、分け直す合図を先に決めておきます。

分け直す合図は、未分類の枠の割合のほかにもう一つあります。ある型の件数が短い期間に急に増えたときです。公開されている問い合わせ分析でも、週の単位で見ると急増に早く気づけると整理されています。急に増えた型は、たいてい中に別の型が混ざり込んでいます。中身を読み直すと、新しい仕組みの導入や仕様の変更が背後にあることが分かります。

逆に、型を増やしたくなる場面には注意します。特定の仕組みの名前を型にしたい、特定の部署の依頼を型にしたい——こうした要望は必ず出ますが、それは担当を決める軸の話です。答え方が同じなら、名前が違っても同じ型に入れます。担当の軸と答え方の軸を混ぜると、一覧はすぐに使えなくなります。

型で分けると、AIに渡す線が自然に決まる

ここまで分けてくると、最初の悩みに戻れます。どこまでAIに任せてよいか。この問いは、型ごとに答えが変わるので、全体で1つの答えを出そうとするから決まらなかったのです。型が決まっていれば、渡してよい範囲は考えるまでもなく決まります。

定型は、文書を根拠にした案内まで。環境に依存する型は、状況を聞き出すところまで。権限が要る型は、受け付けと不足の確認まで。判断が要る型は、過去の事例と根拠を並べるところまで。4つとも共通しているのは、相手や仕組みの状態を変える手前で止まっていることです。状態を変える行為は、元へ戻せない側に入るからです。

人が確認する範囲も、同じように型で決まります。判断が要る型は全件を人が読む。権限が要る型は、期間と対象者が空欄でないかを人が見る。環境に依存する型は、聞き取りが人に渡ったところから人が持つ。定型は、根拠にした文書が古かった件だけを人が読む。全件を読む前提にすると確認そのものが新しい負担になるので、型ごとに読む範囲を変えるのが続けられる形です。そして判断が要る型では、AIに結論を出させず候補と根拠だけを書かせる。この一線は、型の区分と一緒に1枚に書いておきます。

まとめ

社内に届く問い合わせは、件数で語れるほど均一ではありません。部門別やシステム別に分けると誰の担当かは決まりますが、どう答えるかは決まりません。分ける軸に置くのは答えを出すのに何が必要かです。文書を開けば足りる定型、状況を聞き出す必要がある環境に依存する型、権限を持つ人の手続きが要る型、誰かが可否を決めなければ進まない判断が要る型。この4つに分かれます。

型が決まると、扱いが3つ同時に決まります。AIに渡してよい線、その件に混ざる個人情報の種類、そして間違えたときに元へ戻せるかどうか。戻せるかどうかは、こちらの操作ではなく相手に起きる変化で判定する。この見方を取ると、自動で流してよい行為の一覧が1枚で書けます。1件に2つの型が混ざったときは押し込まず、重いほうを残して切り出します。

そして最後に一線を引きます。判断が要る型では、AIに結論を出させない。候補と根拠だけを書かせる。人が確認する範囲は、型ごとに先に決めておく。まずは直近の問い合わせを30件だけ手元に出して、4つの型に振り分けてみてください。どちらとも取れて手が止まった件が、いまの区分の境目が曖昧な場所です。そこから書き始めるのが、いちばん短い道になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。