社内問い合わせを
効率化する方法情シスのAI活用と
FAQ・有人対応

「VPNにつながらない」「アカウントを作ってほしい」。情シスへ繰り返し届く社内問い合わせは、質問ごとに必要な対応が違います。

社内問い合わせを効率化するには、手順の案内、障害の受付、権限変更の申請を分け、AIと担当者の役割を決めます。

この記事は、FAQを整えても問い合わせが減らず、AI活用を検討している情シス責任者向けです。窓口の見直しとVPNの対応例から、既存ツールで足りる範囲を判断できます。

VPNの連携は設計例で、実機検証ではありません。資料の権限・更新はMicrosoftの公式仕様を根拠に解説し、導入前に使える確認表も公開しています。

この記事で分かること

• 全社員に共通する案内、本人だけが見られる照会、担当者が決める承認を分けて考えます
• 答えを固定したい質問はFAQへ、複数の資料から探す質問は文書検索へ振り分けます
• AIが答えられない場合にも、利用者が最初から説明し直さずに済む引継ぎを作ります

FAQを整えても
問い合わせが減らない原因

同じ質問が繰り返されるなら、回答の不足だけでなく、入口と探し方、解決後の記録を見直します。

メール・Teams・個人への連絡が混在している場合は、社員が使う受付窓口を明確にします。緊急障害の連絡先は、通常の質問と分けて表示してください。

「自宅から共有フォルダが開けない」という質問に、FAQの「VPN接続手順」が見つからなければ、用語のずれが問題です。自然な質問から該当手順を探すAIが候補になります。

一方、手順を読んでも解決できない障害や、申請後の承認待ちは、検索だけでは解消しません。担当者への受付や申請状況を確認する仕組みを選ぶ必要があります。

Zendeskの社内問い合わせ向け解説でも、FAQの探しにくさと、担当へ渡す前の情報収集が扱われています。

弊社は、回答AIを足す前に「何を聞かれ、どこで待たせているか」を問い合わせ記録から確かめます。説明の繰り返しと、申請・障害対応の滞りでは、変える工程が異なるためです。

VPN接続の問い合わせ対応例

AIが状況と試した操作を整理し、解決しなければその記録を情シスへ引き継ぎます。

社員がTeamsや社内ポータルから質問する場面を想定します。接続・回答・受付を実行した事例ではなく、導入前に確認するための設計例です。

端末とエラーを確認し、
承認済みの手順を案内する

AIは「会社の端末か」「自宅か社内か」「いつからか」「どんなエラーか」を聞きます。パスワードや認証コードは入力させません。

例えば「会社PC・自宅・今朝から・認証エラー」と回答されたら、利用者が読める現行のVPN手順を探します。

接続先の設定や再認証など、情シスが案内を許可した操作だけを示す設計です。

回答には「VPN接続手順・現行版」と該当箇所へのリンクを付けます。

手順が見つからない場合や端末の条件が違う場合は、一般知識で操作を補いません。

障害と権限変更は、
案内とは別に受け付ける

公開対象の障害案内が出ていれば、その状況と正式な連絡先を返します。同じ質問が増えただけで、AIが全社障害と断定する運用にはしません。

社員が「異動後から使えない」と補足したら、権限変更の申請へ案内します。AIが所属からアクセスを許可せず、承認者と発行担当が確認する流れを残します。

自己解決しない場合は、質問・端末・エラー・試した手順を問い合わせ管理ツールへ送ります。

受付が成功した後で、受付番号と担当窓口を社員へ知らせる設計です。

担当者の対応結果を残し、
繰り返す質問を見直す

対応履歴には、参照した手順の版、受付番号、担当者、解決内容を残します。

未解決なら担当者へ引き継いだ状態で、AIが解決済みにしません。

同じ端末設定の質問が続く場合は、FAQの言葉や端末配布時の案内を見直します。回答した回数を増やすより、繰り返し問い合わせが発生する理由を減らす判断につながります。

手順案内・個人照会・申請の
承認を分ける

全社員に共通する案内、本人だけが見られる照会、担当者が決める承認を分けて考えます。

社内の質問だからといって、一つのチャットにすべての資料と権限を集めないことが出発点です。

最初に対象にしやすいのは、答えの根拠が一つに決まり、間違っても取り消し困難な処理を起こさない質問です。

総務の申請先案内や、情シスの端末設定手順の検索が候補になります。

給与情報や個別の評価、緊急の障害対応を、試作段階から同じ窓口へ混ぜる必要はありません。

AI導入の前に、よく聞かれる質問を実際の表現で並べます。

「VPN」という用語ではなく「自宅から共有フォルダが開けない」と聞かれるなら、その言い方でも手順にたどり着けるかを見るためです。

質問ログを使う場合は、利用目的と閲覧範囲を確認し、個人名や相談内容を不用意に外部サービスへ渡さないようにします。

FAQを整えるか、
文書を検索させるか

答えを固定したい質問はFAQへ、複数の資料から探す質問は文書検索へ振り分けます。

AIを使う場合も、すべての回答を毎回生成させる必要はありません。

決まった案内は、短いFAQにする

問い合わせ先、申請フォーム、添付書類の一覧などは、担当部署が確認した答えを登録できます。

AIには質問の言い換えを受け取る役割を持たせ、表示する回答を固定する方法もあります。

少数の質問とリンクで用が済むなら、通常のFAQページや社内ポータルの整理から始める選択も合理的です。

文書検索は、
出典へ戻れる形にする

手順書や規程が多い場合は、関連部分を検索してから回答を作るRAGという構成が候補です。

回答の横に文書名、適用日、該当箇所へのリンクを置けば、利用者が元の規程へ戻れます。

ただし、引用があるだけでは正答とは限りません。

質問者の所属や対象の制度に、その文書が適用されるかも確認が必要です。

資料には、文書を管理する担当部署、対象者、施行日、廃止日を持たせます。

ファイルの更新日時が新しくても、将来施行の規程かもしれません。

「一番新しいファイルを使う」だけでは、現在有効なルールを選べないためです。

正式版が決まっていない文書は、回答根拠にせず担当部署で整理します。

資料の接続方法と
閲覧権限・更新の違い

製品名だけで選ばず、資料の接続方法ごとに「誰が読めるか」と「変更がいつ届くか」を確認します。

Copilot Studioの公式資料を例にすると、この二つを一括で「社内データ連携」と呼べない理由が分かります。

以下は2026年9月9日に確認した、Copilot Studioの標準実行環境で使う機能の公式仕様です。

別の実行基盤へそのまま当てはめず、導入する環境でも確認してください。

特定製品の推奨や、弊社による動作保証ではありません。

根拠：Microsoftの生成回答ノードへのファイルアップロード、非構造データの権限・同期方式、SharePoint接続の仕様。

「元の資料は
限定公開」だけでは足りない

部長だけが読める資料を、全社員が使うAIへ直接アップロードすれば、元の保存先で付けた制限がそのまま働くとは限りません。

上表の最初の方式と、SharePointへ接続する二つの方式は区別が必要です。

画面の操作が似ていても、アクセスを判断する場所が違います。

そのため、管理者が正常に答えを得られるテストだけで終わらせません。

一般社員と管理者で同じ質問を行い、権限のない側には回答本文、引用、文書名からも機密内容が伝わらないかを確認します。

これは資料の検索精度を測るテストとは別です。

更新・削除と、
閲覧権限の変更は別に試す

Microsoftは、取り込み型のSharePoint接続の同期周期を取り込み完了基準で4〜6時間と説明しています。

一方、権限は質問時に確認する仕様です。

この時間はすべての製品に共通する値でも、変更が必ず反映される保証時間でもありません。

直接検索する方式でも、検索できる状態になるまでを確認します。

ここから分かるのは、「旧規程を削除した後の回答」と「異動で閲覧権限を外した人への回答」を同じ確認にまとめないほうがよい、ということです。

前者は内容の更新、後者は利用者の権限が論点になります。

すぐに変わる締切や障害案内は、新しい回答を確認するまで正式な案内先へ誘導する運用も用意します。

導入前に試す質問と確認表

正しく答える質問だけでなく、答えてはいけない質問と、更新直後の質問を試します。

下表は弊社が公式仕様から整理した確認案です。

顧客案件の記録や、製品の実測結果ではありません。

顧客や社員の実情報を使わず、架空の「備品申請手順」と部署限定資料を用意します。

利用者の権限、文書の状態、期待する対応を先に決め、その後に出力を記録してください。

実際の質問文、未加工の回答、参照先、実行日時を残せば、文章が自然だったという印象だけで判断せずに済みます。

権限変更・新版への更新・旧版の除外では、変更前後に同じ質問を実行して比較します。

変更時刻と回答時刻、接続方式、新しい会話か継続中の会話かを記録し、修正後の再試験も同じ条件で行います。

社内問い合わせAIの導入前確認表をダウンロード（CSV）できます。

判定欄は空欄です。

貴社で使う資料・アカウント・窓口に合わせて書き換えてください。

機密情報が返る不具合は、平均の正答率が高くても公開を止める理由になります。

一方、案内文が長い問題は、回答の要約や見せ方の調整で対応できます。

すべてを「精度不足」と考えず、原因によって修正する場所を変えます。

過去に表示した内容まで権限変更で消せるわけではないため、会話履歴の閲覧範囲と保存・削除も別途確認します。

有人対応と申請受付をつなぐ

AIが答えられない場合にも、利用者が最初から説明し直さずに済む引継ぎを作ります。

質問内容、試したこと、参照した資料、まだ不明な点を窓口へ渡し、受け取る担当部署を決めます。

ただし、質問者が見られない資料や不要な個人情報まで転送しません。

「担当者へ連絡しました」と表示するのは、実際に受付が成功した後です。

転送できなければ、連絡先を表示して利用者自身が連絡できるようにします。

同じ問い合わせを再送した際に重複受付にならないことも、接続先の仕組みに合わせて確かめます。

申請状況の照会や登録機能を足す場合は、誰の権限で動くかを再確認します。

Microsoftのツールの認証設定でも、作成者側の認証情報を使う設定と、利用者自身が認証する設定を区別しています。

資料検索が利用者の権限で動くことは、別の登録機能まで同じ権限で動く証拠にはなりません。

最初は案内だけを公開し、個別照会、受付、承認を段階的に追加すると、どの機能が問題を起こしたか追いやすくなります。

権限を分ける考え方は、AIツールの権限管理と機密情報の扱いでも解説しています。

費用対効果は、
回答数だけで判断しない

問い合わせが解決したかと、情シスの作業時間が減ったかを別々に確認します。

AIの会話数が増えても、人への質問が減らなければ、担当者の負担は残っているかもしれません。

導入前後で、対象の質問、件数、担当者の作業時間を同じ条件で比べます。

「AIが回答した」「利用者が解決した」「担当者へ引き継いだ」は分けて記録してください。

回答が返っただけの会話を自己解決として数えると、効果を大きく見積もってしまいます。

VPNの例なら、手順を表示した件数ではなく「接続できた」「情シスへ受付した」「途中で離脱した」を分けます。有人対応では、状況を聞き直す時間と、受付から担当決定までの待ち時間も比較してください。

回答の修正と資料更新に増えた時間も含めます。

担当者の負担が減らなければ、対象の質問や受付方法を見直します。

費用は、サービス利用料だけでなく、資料整理、接続設定、権限テスト、文書の更新、障害対応を含めて確認します。

すでに契約している環境で要件を満たせるなら、新しい専用システムを作る必要はありません。

複数の保存先を横断する場合や、申請受付までつなぐ場合は、AI開発費用の相場と見積もりの読み方も参考になります。

一つの受付窓口で、
頻出する質問から試す

頻出する質問を一つ選び、回答できないときの受付先まで決めてから試します。

現行の質問記録から、VPNの手順案内など繰り返される用件を選んでください。使う資料の正式版と更新担当を確認し、社員が普段使う画面で案内へたどり着けるかを見ます。

弊社は、FAQ整理で足りる質問まで専用開発に含めず、受付・資料検索・申請のどこに連携が必要かを分けて設計します。情シスが今使っている管理ツールと承認手順を残せるかも判断材料です。

外注先には、通常の回答だけでなく「解決しなかった質問は誰の画面に届くか」「受付に失敗したら社員へ何を知らせるか」を確認してもらいましょう。

権限や資料更新の確認には、公開しているCSVを使えます。相談時は社内資料を送らず、対象の質問・受付窓口・管理ツールを伝えれば、見直す工程を整理できます。