全社で生成AIを使えるようにする前に、まず決めるべきなのは「どのAIを使うか」だけではありません。
たとえば、情シスの佐藤さん(仮名)のもとには、導入説明会の翌日から、営業、人事、法務、セキュリティ担当から次のような相談が集まり始めました。
「顧客情報は入力してよいのか」「社外向け文書に使ってよいのか」「エラーが出たら誰に聞くのか」
以前は、AI活用のルールを一部の担当者が口頭で説明し、質問が来るたびに個別対応していました。しかし現在は、社内FAQ、問い合わせ窓口、一次切り分け、エスカレーション先を導入前に設計しておくことが、全社導入の重要な準備になっています。
本記事では、サポートデスク・情シス・DX推進担当と、人事・法務・セキュリティなど問い合わせを受ける部門に向けて、導入前に整えるべきFAQ項目と受付体制を整理します。目指すのは、現場の方が不安を抱えたまま使い始めるのではなく、迷ったときに確認先が分かり、担当部門が同じ基準で判断できる状態です。ただし、FAQや窓口を作るだけで全ての不安が消えるわけではありません。運用ルール、教育、定期的な見直しと組み合わせて、自社に合うサポート体制を育てていくことが大切です。
生成AI導入では「問い合わせ設計」が必要になる
生成AIの社内導入では、従来のITツール導入とは異なる種類の問い合わせが発生します。
通常の業務システムであれば、「ログインできない」「権限がない」「ボタンが表示されない」「ファイルが開けない」といった操作面の質問が中心です。一方、生成AIではそれに加えて、「この情報を入力してよいのか」「AIの回答を社外向け文書に使ってよいのか」「間違った出力を使った場合、誰が責任を持つのか」といった判断に関わる質問が増えます。
このため、問い合わせの受け皿は情シスだけでは完結しません。DX推進、情報セキュリティ、法務、人事、営業企画、広報など、複数部門が関わるテーマになります。
窓口や判断基準が決まっていないと、現場では次のようなことが起こりやすくなります。
- 同じ質問が複数部門に届く
- 担当者ごとに回答内容が変わる
- 判断が難しい質問が放置される
- 現場が不安になり、AI利用が進まない
- 反対に、ルールが曖昧なまま利用だけが広がる
生成AIの社内導入では、「どのツールを使うか」と同じくらい、「迷ったときにどこへ聞けばよいか」を設計しておくことが重要です。AI事業者ガイドライン（第1.2版）では、AIの適正な利用に向けたガバナンスやリスク管理の考え方が整理され、チェックリストやワークシートも公開されています。社内FAQや問い合わせ窓口も、一度作って終わりではなく、利用状況や新たなリスクに応じて継続的に見直す仕組みとして位置づけることが重要です。
社内FAQに入れるべき基本項目
社内FAQは、単なる質問集ではありません。現場の判断をそろえるための共通ルールです。
最初から完璧なFAQを作る必要はありません。ただし、生成AIの利用開始前に、少なくとも以下の項目は整理しておくと、問い合わせの混乱を抑えやすくなります。
利用できる業務範囲
最初に必要なのは、「どの業務で生成AIを使ってよいか」の整理です。
| 区分 | 内容 |
|---|---|
| 利用しやすい業務 | メール文案、議事録要約、社内資料のたたき台、アイデア出し、文章の校正 |
| 条件付きで利用する業務 | 顧客向け提案文、契約書の一次確認、社内規程の要約、採用広報文の作成 |
| 利用を避ける業務 | 個人情報、機微情報、未公開財務情報、法的判断を伴う最終判断、人事評価の確定判断 |
ここで大切なのは、「AIに任せてよい作業」と「人が責任を持つ判断」を分けることです。生成AIは下書き、要約、論点整理、比較表の作成などには活用しやすい一方、事実確認、最終判断、対外的な責任を伴う意思決定は人が担う必要があります。
KanataのようにAIチャット、AI要約、eラーニングなどをプロジェクト単位で利用できるツールを使う場合も、機能の便利さだけでなく、「どの業務で使うか」「誰が確認するか」を先に決めておくと、運用が安定しやすくなります。Kanataの操作マニュアルでは、AIチャット・AI要約・eラーニングなどを業務支援プラットフォーム内で扱えること、プロジェクトごとに利用者・データ・アプリを整理できることが説明されています。
入力してよい情報・いけない情報
現場から特に多く出やすいのが、入力データに関する質問です。
「この資料をAIに読ませてもよいですか」
「顧客名を入れても問題ありませんか」
「社員の評価コメントをAIで整えてもよいですか」
こうした質問に毎回個別対応していると、問い合わせ対応がすぐに属人化します。FAQには、情報の種類ごとの扱いを明記しておきます。
想定例としては、次のような分類です。
| 情報の種類 | 扱い |
|---|---|
| 公開情報 | 入力可 |
| 社内一般資料 | 社内環境・権限管理下で入力可 |
| 顧客情報 | 契約・NDA・社内ルールを確認したうえで判断 |
| 個人情報 | 原則として入力を避ける。業務上必要な場合は、利用目的、契約条件、AI事業者によるデータの取扱い、アクセス権限などを確認し、必要に応じてマスキングや社内承認を行う |
| 機微情報 | 原則として入力を避ける。利用するAI環境、契約条件、データの取扱い、アクセス制御などを確認し、自社のルールに基づいて判断する |
| 未公開財務・M&A・人事異動情報 | 原則として入力を避ける。業務上必要な場合は、利用するAI環境、契約条件、データの取扱いを確認し、専門部署の承認を得る |
個人情報保護委員会の注意喚起では、生成AIサービスの利用にあたり、個人情報の適正な取扱いとプライバシー保護への配慮が重要であるとされています。社内FAQでも、個人情報を入力する場合の条件、入力を避ける情報、マスキングの方法に加え、利用するAI環境の契約条件、データの取扱い、アクセス権限などを確認する基準を具体化しておく必要があります。
AI出力の確認ルール
生成AIの回答は自然な文章で返ってくるため、そのまま使えるように見えることがあります。しかし、誤った情報、古い情報、社内ルールと異なる表現が含まれる可能性があります。
FAQには、次のような確認ルールを入れておくとよいでしょう。
- 社外に出す文章は、必ず人が確認する
- 数字、日付、固有名詞、引用は一次情報と照合する
- 契約、法律、労務、セキュリティに関わる内容は専門部署に確認する
- AIの回答を最終判断として扱わない
- 「AIが出したから正しい」と説明しない
- 機密情報や個人情報が意図せず出力されていないか確認する
- 著作権など第三者の権利を侵害するおそれがないか確認する
- 差別的・不適切な表現が含まれていないか確認する
- 重要な判断に利用する場合は、必要に応じて入力、出力、確認者、判断根拠を記録する
AIを業務で使う場合、出力内容の妥当性を検証できる状態にしておくことが重要です。NISTの生成AI向けリスクマネジメント文書でも、生成AI固有のリスクを組織が把握し、管理するための枠組みが示されています。なお、NISTではAI RMF 1.0の改訂も進められているため、関連文書の更新状況を定期的に確認することが重要です。
トラブル時の連絡先
生成AIを全社展開すると、操作面のトラブルも発生します。
たとえば、次のような問い合わせです。
- ログインできない
- 権限がなく、対象機能が表示されない
- ファイルがアップロードできない
- AIの回答が返ってこない
- 期待した回答と違う
- 誤って機密情報を入力してしまった
これらをすべて同じ扱いにすると、対応が遅れます。FAQには、トラブルの種類ごとに連絡先を分けて書いておきましょう。
特に、機密情報や個人情報を誤って入力した場合は、通常の操作問い合わせとは分けて、情報セキュリティ担当や上長にすぐ報告する流れを明記しておく必要があります。
問い合わせ窓口は「入口を一本化し、判断先を分ける」
生成AIの問い合わせ窓口を設計するときに大切なのは、入口と判断先を分けることです。
現場の利用者から見ると、「これは情シスに聞くべきか、法務に聞くべきか、DX推進に聞くべきか」は判断しづらいものです。そのため、最初の問い合わせ入口はできるだけ一本化します。
一方で、裏側の対応は分類しておきます。
| 問い合わせ内容 | 一次対応 | エスカレーション先 |
|---|---|---|
| ログイン・権限・画面表示 | サポートデスク・情シス | 情シス管理者 |
| AIの使い方・プロンプト | DX推進・AI活用推進担当 | 業務部門責任者 |
| 入力データの可否 | 一次窓口 | セキュリティ・法務 |
| 契約書・規約・著作権 | 一次窓口 | 法務 |
| 人事評価・労務情報 | 一次窓口 | 人事 |
| 誤入力・情報漏えい疑い | 一次窓口 | セキュリティ・上長 |
| 社外提出物への利用 | 一次窓口 | 所管部門・法務・広報 |
入口を一本化することで、現場は迷わず相談できます。一方で、裏側の判断先を分けることで、専門部署が必要な案件だけを確認できます。
問い合わせ受付には、フォーム、チャット、メール、チケット管理ツールなど複数の方法があります。どれを使う場合でも、問い合わせ内容、対応者、回答日、判断根拠を後から確認できる形で残すことが重要です。
一次切り分けで確認すべき情報
問い合わせを受けた担当者が最初に確認すべき情報も、あらかじめ決めておくと対応が安定します。
問い合わせフォームやチャット窓口では、以下の項目を入力してもらうとよいでしょう。
- 所属部署
- 利用しているAIツール・機能
- 利用したAIモデル（確認できる場合）
- Web検索・外部連携・ファイル参照などの機能利用有無
- 何をしようとしていたか
- 入力しようとしている情報の種類
- 出力を何に使う予定か
- 社内利用か、社外提出か
- エラーが出た場合は画面キャプチャ
- 発生日時
- 共有範囲・アクセス権
- 問題となった入力・出力を保存しているか
- 緊急度
ただし、最初から詳細な説明を求めすぎないことも大切です。入力項目が多すぎると、現場の方は問い合わせ自体を避けてしまいます。
まずは必要最低限の項目に絞り、判断が必要な場合だけ追加で確認する形が現実的です。利用モデル、外部連携、共有範囲、問題となった入力・出力の保存状況などは、インシデント対応や専門部署へのエスカレーションが必要な場合に追加確認する方法もあります。
たとえば、受付時の必須項目は「部署」「利用目的」「入力予定の情報」「社内利用か社外提出か」「困っている内容」の5項目程度に絞り、詳細確認は一次対応者が行う方法もあります。
エスカレーションシナリオを用意する
生成AIの問い合わせでは、「一次窓口で答えてよい質問」と「専門部署に回すべき質問」を分けておく必要があります。
以下は、社内ルールを作る際の想定例です。実際には、自社の組織体制、セキュリティポリシー、契約条件に合わせて調整してください。
情シスへ回すケース
- ログインできない
- アカウントが発行されていない
- 権限が不足している
- ファイルアップロードができない
- 対象機能が表示されない
- システム障害が疑われる
Kanataのようにプロジェクトや権限で利用範囲を分けられるツールでは、「機能が存在しない」のか「権限がないため表示されていない」のかを切り分けることが重要です。Kanataの操作マニュアルでも、メンバーごとに権限が設定され、権限によってできる操作が異なることが説明されています。
セキュリティへ回すケース
- 個人情報を入力してよいか迷っている
- 機密情報を入力した可能性がある
- 顧客情報をAIで扱わせたい
- 外部サービスとの連携可否を確認したい
- 情報漏えいが疑われる
この領域では、一次窓口が独自判断しないことが重要です。特に、入力してしまった後の相談はインシデント対応に近くなるため、通常のFAQ回答とは分けて扱います。
法務へ回すケース
- 契約書をAIで要約したい
- 利用規約を確認したい
- 著作権が関わる文章や画像を扱いたい
- AI出力を顧客提出文書に使いたい
- 責任範囲や免責表現を確認したい
AIは契約や法律の最終判断者ではありません。法務確認が必要な領域は、FAQで明確に線引きしておきましょう。
人事へ回すケース
- 採用候補者情報を入力したい
- 人事評価コメントをAIで整えたい
- 従業員の相談内容をAIで要約したい
- 労務・休職・健康情報に関わる内容を扱いたい
人事領域では、個人情報や機微な情報が含まれやすくなります。業務効率化のためにAIを使いたい場面でも、入力前に確認するルールが必要です。
社内FAQのテンプレート例
ここでは、導入前に用意しておきたいFAQの例を示します。自社のルールに合わせて、回答文を調整してください。
Q. 生成AIに入力してよい情報は何ですか？
A. 公開情報や、社内で共有が認められている一般的な業務情報は、社内ルールに従って利用できます。ただし、個人情報、機微情報、未公開の財務情報、人事異動、M&A情報、顧客との契約条件などは、原則として入力を避け、業務上必要な場合は、利用目的、利用するAI環境、契約条件、データの取扱い、アクセス権限などを確認したうえで、必要に応じてマスキングや事前承認を行ってください。判断に迷う場合は、入力前に問い合わせ窓口へ確認してください。
Q. 顧客名や個人名を入れてもよいですか？
A. 原則として、顧客名や個人名はマスキングしてください。たとえば、顧客名は「製造業A社」、個人名は「担当者B」、金額は「数千万円規模」などに置き換えます。契約上、顧客情報の外部利用に制限がある場合もあるため、NDAや契約条件の確認が必要です。
Q. AIが出した文章をそのまま社外に送ってよいですか？
A. そのまま送ることは避けてください。社外に出す文章は、担当者が内容を確認し、必要に応じて上長、法務、広報などの確認を受けてください。数字、日付、固有名詞、引用、契約条件などは、必ず一次情報と照合します。
Q. 契約書や社内規程をAIに読ませてもよいですか？
A. 契約書や社内規程は機密性が高い場合があります。利用するAI環境、権限設定、契約上の制限に加え、入力データの保存・学習利用などの取扱いを確認したうえで判断してください。社内専用環境やアクセス制限されたプロジェクトで扱う場合でも、最終的な法的判断は法務担当者が行う必要があります。
Q. AIの回答が間違っていた場合、誰が責任を持ちますか？
A. AI出力を業務に利用する際の確認・承認の責任分担は、自社の職務権限や業務ルールに基づいてあらかじめ定めておきます。AIの回答だけを根拠として重要な判断を確定せず、必要な確認を人が行う運用にしてください。AI利活用時の民事責任については、経済産業省「AI利活用における民事責任の解釈適用に関する手引き〔第1.0版〕」も参照できます。
Q. FAQにない質問をしたいときはどうすればよいですか？
A. 問い合わせ窓口に相談してください。窓口では、内容に応じて情シス、DX推進、セキュリティ、法務、人事などに確認します。よくある質問は、後日FAQに反映します。
FAQは公開して終わりではなく、問い合わせから育てる
社内FAQは、最初から完成度を求めすぎる必要はありません。むしろ、導入後に寄せられた問い合わせをもとに更新していく前提で作ることが大切です。
導入後30日間は、次のような観点で問い合わせを見直すとよいでしょう。
どの部門から問い合わせが多いか どのカテゴリの質問が多いか FAQを読めば解決できた質問はどれか FAQに書いてあるが伝わっていない項目はどれか 判断に時間がかかっている領域はどこか エスカレーション先が曖昧な質問はどれか
数値を扱う場合は、必ず前提を明示します。
たとえば、「導入後30日間で問い合わせ60件を分類したところ、入力データの可否が20件、社外利用の可否が15件、操作トラブルが10件だった」といった形です。この場合、FAQの優先更新対象は、入力データの可否と社外利用の可否になります。
実績がない段階では、無理に効果を数値で断言する必要はありません。まずは問い合わせを分類し、よく聞かれる項目からFAQへ戻していくことが現実的です。
また、問い合わせ件数だけでなく、AIサービスのモデル更新、利用規約の変更、新機能の追加、社内ポリシーの変更、法令・ガイドラインの更新もFAQを見直すきっかけとして定めておくと、内容を最新の状態に保ちやすくなります。
Kanataを使う場合に整理しておきたいこと
社内FAQや問い合わせ対応の仕組みは、特定のツールだけで完結するものではありません。フォーム、チャット、チケット管理ツール、社内ポータル、ナレッジベースなど、複数の選択肢があります。
その中で、Kanataを利用する場合は、AIチャット、AI要約、eラーニング、プロジェクトライブラリといった機能を、社内ナレッジの整理や教育に活用できます。操作マニュアルでは、プロジェクトライブラリにAI設定、プロンプト、学習データを保存し、プロジェクト内のチャットや要約アプリから参照できることが説明されています。
たとえば、次のような使い方が考えられます。
- FAQや社内規程を学習データとして整理する
- よく使う回答方針をプロンプトライブラリに登録する
- 部門ごとにプロジェクトを分け、権限を管理する
- 問い合わせ対応用のAIチャットを用意する
- 研修動画や説明資料をeラーニングとして配信する
ただし、Kanataを含むどのツールを使う場合でも、問い合わせ責任や判断ルールそのものを自動で決められるわけではありません。どの情報を登録するか、誰が更新するか、どの回答を正式なものとするかは、組織側で決める必要があります。
まとめ：生成AIの不安は、問い合わせ設計で拾い上げる
生成AIを全社導入すると、現場からの質問は必ず発生します。
その質問は、単なる操作方法に限りません。入力してよい情報、出力の確認責任、社外利用の可否、トラブル時の報告先など、複数部門の判断が必要になるものも多く含まれます。
だからこそ、導入前に次の4つを整えておくことが重要です。
- 社内FAQ
- 問い合わせ窓口
- 一次切り分け
- エスカレーションシナリオ
目指すべきなのは、問い合わせをゼロにすることではありません。現場の方が不安を抱えたときに、迷わず相談できる状態を作ることです。そして、集まった問い合わせをFAQやルールに反映し、少しずつ運用を育てていくことです。
生成AI導入は、ツールを配るだけでは定着しません。現場の不安を拾い、判断をそろえ、必要なときに専門部署へつなげる体制があって初めて、安心して使える環境に近づきます。
Q&A：生成AI導入前の社内FAQと問い合わせ窓口
生成AI導入前に、最初に決めるべきことは何ですか？最初に決めるべきなのは、「誰が、どの業務で、どの情報を使ってよいか」です。ツール選定だけでなく、利用範囲、入力禁止情報、確認責任、問い合わせ先をセットで整理する必要があります。
問い合わせ窓口は情シスだけでよいですか？情シスだけで完結するケースは限られます。ログインや権限は情シスが中心になりますが、個人情報はセキュリティ、人事情報は人事、契約や著作権は法務の確認が必要です。入口は一本化し、裏側で専門部署へつなぐ設計が現実的です。
社内FAQはどのくらい作り込んでから公開すべきですか？最初から網羅しすぎる必要はありません。導入前には、利用できる業務範囲、入力してよい情報、AI出力の確認ルール、トラブル時の連絡先を最低限用意し、導入後の問い合わせをもとに更新していく形が実務的です。
AIの回答をそのまま社外に出してもよいですか？避けたほうがよいです。社外に出す文章は、人が内容を確認し、数字、日付、固有名詞、引用、契約条件などを一次情報と照合する必要があります。法務、広報、上長の確認が必要な文書もあります。
Kanataを使えば問い合わせ対応は自動化できますか？弊社が提供するKanataは、FAQや社内規程を学習データとして整理したり、プロンプトやナレッジを再利用したりする支援には使えます。ただし、問い合わせ責任、最終判断、エスカレーション基準は組織側で設計する必要があります。ツールは運用を支える手段であり、ルール設計そのものの代替にはなりません。
