生成AIの社内教育を始めた。
実例メモも残し始めた。
質問や失敗例も少しずつ見えてきた。
では、その次に作る社内FAQは、どう運用すればいいのか。
ここでよくあるのが、「よくある質問」を一気に増やして満足してしまうパターンです。
質問を並べる。
AIに回答案を作らせる。
社内ポータルやNotionやGoogleドキュメントに貼る。
これでナレッジ共有ができた気がする。
もちろん、FAQを作ること自体は大事です。
ただ、僕は生成AIの社内FAQほど、「作った後」の設計が大事だと思っています。
なぜなら、生成AIまわりの判断は変わりやすいからです。
使っているツールの仕様が変わる。
社内で扱う情報の範囲が変わる。
お客様からの問い合わせ内容も変わる。
一度OKにした使い方が、後から見直し対象になることもあります。
にもかかわらず、FAQの回答だけが固定されたままだと、現場は古い答えを信じてしまいます。
これ、地味に怖いです。
以前、生成AIの社内教育は、ルール説明より実例共有から始める で、実例を使って判断をそろえる話を書きました。
その後、生成AIの社内ナレッジは、FAQを増やすより実例メモから育てる では、きれいなFAQより先に、現場で迷った判断の跡を残すことを整理しました。
今回は、その次です。
実例メモから社内FAQを作るとき、どうすれば「古くならないFAQ」にできるのか。
総務省・経済産業省の AI事業者ガイドライン第1.2版 では、AI活用を継続的に見直しながら取り組む考え方が整理されています。
IPAの AI利用者のためのセキュリティ豆知識 でも、生成AIを使う人が情報の扱いに注意する必要性が、現場寄りに紹介されています。
経済産業省とIPAの デジタルスキル標準 でも、デジタルを活用する人が学び続け、業務に活かす視点が示されています。
だから、小さな会社が社内FAQを作るときも、最初から完璧な答え集を目指す必要はありません。
必要なのは、あとから見直せる状態にしておくことです。
生成AIの社内FAQは、回答を増やすより、誰が・何を見て・いつ見直すかを決めて育てる。
今日は、中小企業や小規模事業者が、生成AIの社内FAQを作って終わりにせず、AI内製化の土台として育てる手順を整理します。
生成AIの社内FAQは、作って終わりにすると古くなる
社内FAQを作ると、少し安心します。
「これで同じ質問に毎回答えなくて済む」
「社員もここを見れば分かる」
「AI活用のルールも共有できた」
たしかに、その効果はあります。
ただ、生成AIの社内FAQは、普通の業務マニュアルより古くなりやすいです。
たとえば、こんな回答があったとします。
- お客様の問い合わせ文は、名前と連絡先を伏せればAIに入れてよい
- 議事録はAIで要約して、社内共有してよい
- 公開済みブログはAIに読み込ませてSNS投稿案を作ってよい
- AIが作ったFAQ案は、担当者が確認してから公開する
どれも一見よさそうです。
でも、実務ではすぐに条件が変わります。
問い合わせ文の中に、契約内容や病歴や家族情報が入っていたらどうするのか。
議事録の中に、人事や評価の話が混ざっていたらどうするのか。
公開済みブログを使う場合でも、古いサービス内容が含まれていたらどうするのか。
担当者が確認する、と書いてあるけれど、担当者が退職したり異動したりしたら誰が見るのか。
ここまで考えないと、FAQは「それっぽい答え」で止まります。
社内FAQの怖さは、答えがあるように見えることです。
答えがなければ、人は誰かに確認します。
でも、古い答えが残っていると、それを見て進めてしまいます。
だから、生成AIの社内FAQは、作成日よりも更新日が大事です。
最初から完璧に作ることより、あとで直せる形にしておく。
この前提を持っておくと、FAQの作り方が変わります。
「質問と回答」だけではなく、判断元、確認者、最終確認日、次回見直し日までセットで残す。
答えを増やすのではなく、答えを育てる。
この考え方が、AI内製化ではかなり大事です。
回答には、判断元と最終確認日を残す
社内FAQでまず入れたいのは、回答文そのものです。
ただ、生成AIまわりでは、回答だけを置くと危ないことがあります。
その答えが、何をもとに決まったのか分からなくなるからです。
たとえば、FAQにこう書いてあるとします。
「問い合わせ返信の下書き作成にはAIを使ってよい」
これだけだと、判断に必要な情報が足りません。
どの業務の話なのか。
どこまで個人情報を伏せる前提なのか。
AIに入れてよいのは問い合わせ全文なのか、要約した内容なのか。
最終確認は誰がするのか。
この回答を決めたのは、社内ルールなのか、改善会議なのか、外部のガイドライン確認なのか。
ここが抜けると、後から直しにくくなります。
だから、社内FAQの1項目には、最低限この4つを添えるのがおすすめです。
- 回答
- 判断元
- 確認者
- 最終確認日
たとえば、こんな形です。
質問: お客様の問い合わせ文をAIに入れて返信案を作ってよいですか。
回答: 顧客名、連絡先、契約内容、個別事情を伏せたうえで、返信の構成案までなら使えます。送信文は担当者が事実確認し、自社の言葉に直します。
判断元: 社内AI入力ルール、問い合わせ対応ログ、改善会議の決定事項。
確認者: 問い合わせ対応責任者。
最終確認日: 2026年6月27日。
これくらいの粒度で十分です。
大きな規程文書を作る必要はありません。
ただ、判断元が残っていると、あとで見直すときに強いです。
「この回答は、どの会議で決めたんだっけ」
「このルールは、どのガイドラインを見て決めたんだっけ」
「この業務ではOKだけど、別業務でも同じでいいんだっけ」
こういう確認ができます。
生成AIの社内FAQは、正解集ではなく、判断の履歴です。
だから、答えだけでなく、なぜその答えにしたのかを残す。
ここを省くと、FAQは増えても、会社の判断力は育ちません。
更新担当だけでなく、質問が集まる入口を決める
FAQを育てるには、更新担当を決める必要があります。
ただし、更新担当を1人に丸投げすると、すぐに止まります。
担当者だけが質問を集める。
担当者だけが回答を書く。
担当者だけが古いかどうか判断する。
これだと、担当者の記憶と時間に依存します。
小さな会社ほど、これは現実的ではありません。
だから、決めるべきなのは「誰が更新するか」だけではありません。
「質問がどこに集まるか」です。
たとえば、こんな入口を1つ決めます。
- SlackやChatworkの専用スレッド
- Googleフォーム
- Notionやドキュメントの質問メモ欄
- 週次ミーティングの最後5分
- 問い合わせ対応ログの「FAQ候補」欄
入口は何でもいいです。
大事なのは、現場が迷った瞬間に残せることです。
「これはFAQにした方がよさそう」
「前にも同じ質問が出た」
「この回答は古いかもしれない」
そう思ったときに、すぐ置ける場所が必要です。
FAQ更新担当の仕事は、全部の答えを自分で作ることではありません。
質問を拾う。
似た質問をまとめる。
回答が必要なものと、実例メモに残すだけでよいものを分ける。
社内ルールや業務責任者へ確認する。
最後に、読める形へ整える。
この役割です。
現場から質問が集まる入口がなければ、FAQは作った人の頭の中だけで増えていきます。
それだと、実務から離れます。
社内FAQを育てたいなら、FAQページそのものより先に、質問が集まる導線を作る。
これは地味ですが、かなり効きます。
FAQは、更新担当者ががんばって書くものではなく、現場の迷いを集めて整えるものです。
AIに任せるのは下書きまで、人が決める範囲を分ける
社内FAQを作るとき、生成AIはとても便利です。
実例メモを読み込ませて、質問候補を出す。
問い合わせログから、よく出る質問を分類する。
長い回答を、短く読みやすく整える。
社内ルールの文章を、現場向けの言葉に言い換える。
ここはAIの得意領域です。
ただし、FAQの最終判断までAIに任せるのはおすすめしません。
AIは、もっともらしい回答を作るのがうまいからです。
でも、その回答が会社としてOKかどうかは別です。
個人情報をどこまで伏せるのか。
お客様への返信文をどこまでAIに任せるのか。
契約、医療、金融、人事、評価、クレーム対応に近い内容をどう扱うのか。
社内の誰が確認するのか。
これらは、AIが勝手に決めることではありません。
人が決める範囲です。
だから、社内FAQ作成では、AIに任せる範囲を先に分けます。
AIに任せてよいこと。
- 実例メモから質問候補を抽出する
- 似た質問をグルーピングする
- 回答文のたたき台を作る
- 難しい表現をやわらかくする
- 重複しているFAQを見つける
人が決めること。
- その業務でAI利用を許可するか
- 入力してよい情報の範囲
- 外部送信前の確認者
- 回答の責任者
- 古い回答を残すか消すか
この分け方があると、AIを使ってFAQ整備を速くできます。
でも、会社としての判断は人に残せます。
AI活用で大事なのは、全部を自動化することではありません。
AIに下書きを任せて、人が判断する時間を取り戻すことです。
社内FAQも同じです。
AIが作った回答をそのまま貼るのではなく、人が確認する前提で使う。
この一手間が、あとから効きます。
30日ごとに、使われないFAQと重複FAQを整理する
FAQは増やすより、見直す方が難しいです。
最初は5個だったFAQが、気づくと30個、50個になります。
似た質問が増える。
古い回答が残る。
言い方がバラバラになる。
同じことを、別のページでも説明している。
こうなると、FAQは便利な場所ではなく、探すのが面倒な場所になります。
せっかく作ったのに、誰も見ない。
あるあるです。つらい。
だから、生成AIの社内FAQは、30日ごとに軽く見直すくらいでちょうどいいです。
大がかりな会議はいりません。
15分から30分で十分です。
見るポイントは4つです。
- よく見られたFAQはどれか
- 同じ質問が複数に分かれていないか
- もう使っていない業務やツールの回答が残っていないか
- 追加すべき質問より、消した方がよい質問はないか
ここで重要なのは、FAQを増やすことを目的にしないことです。
FAQは多ければよいわけではありません。
現場が探せて、判断に使えて、古くなったら直せることが大事です。
たとえば、似たFAQが3つあれば、1つに統合します。
「AIで議事録を要約してよいですか」
「会議メモをAIに入れてよいですか」
「録音データをAIに入れてよいですか」
これらは、似ているようで条件が違うかもしれません。
テキストメモなのか、録音データなのか。
社内会議なのか、顧客会議なのか。
個人情報や機密情報が入っているのか。
同じFAQにまとめるなら、条件を分けて書く。
別FAQに残すなら、タイトルで違いが分かるようにする。
この整理をしないと、FAQが増えるほど迷います。
30日ごとの見直しでは、きれいに整えすぎなくても大丈夫です。
消す。
まとめる。
確認日を更新する。
次回の確認対象にする。
これだけで十分です。
社内FAQは、倉庫ではなく作業台です。
使いながら片付ける前提で運用した方が、ずっと続きます。
FAQを、教育・ルール・問い合わせ対応へ戻す
社内FAQを育てる目的は、FAQページを立派にすることではありません。
現場の判断を楽にすることです。
だから、更新したFAQは、他の運用へ戻した方がいいです。
まず、社内教育へ戻します。
新しく入った人や、AI活用に慣れていない人へ説明するとき、FAQは教材になります。
「よくある質問」ではなく、「うちの会社で実際に迷った判断」として共有できます。
次に、社内ルールへ戻します。
同じFAQが何度も見られているなら、その内容はルール側にも書いた方がいいかもしれません。
逆に、FAQでしか説明していない重要判断があるなら、ルールへ昇格させる必要があります。
最後に、問い合わせ対応へ戻します。
生成AIのFAQは、社内だけで閉じるものではありません。
お客様から何度も聞かれること。
事前に説明した方がよいこと。
サービスページや問い合わせ前の案内に入れた方がよいこと。
こうした気づきは、ホームページや営業資料にも反映できます。
つまり、FAQは社内ナレッジの終点ではありません。
教育、ルール、問い合わせ対応、ホームページ改善へつなぐ中継地点です。
ここまで回ると、AI内製化は少しずつ会社の中に残ります。
ツールを使える人が増えるだけではありません。
迷ったときの判断が残る。
次の人が見返せる。
古くなったら直せる。
この状態ができると、外部に丸投げしなくても、社内で改善を続けやすくなります。
もちろん、最初から完璧なFAQ運用を作る必要はありません。
最初は、10個以内のFAQで十分です。
回答、判断元、確認者、最終確認日を入れる。
質問が集まる入口を決める。
AIには下書きを任せる。
30日後に見直す。
これだけで、社内FAQはかなり育てやすくなります。
生成AIの社内FAQは、完成版を配って終わりではありません。
使いながら、質問を拾い、答えを直し、教育やルールへ戻していくものです。
カタチ舎では、生成AIの導入だけでなく、業務棚卸し、入力ルール、実例メモ、社内FAQ、改善会議まで含めて、AI内製化の進め方を一緒に整理しています。
「AIを使い始めたけれど、社内に残る形になっていない」
「FAQやルールを作ったものの、更新が止まりそう」
そんな段階なら、まずは今ある質問や実例メモを一緒に見直すところからで大丈夫です。
お問い合わせ から、今の運用状況を教えてください。
社内に残るAI活用の形を、無理なく一緒に整えていきましょう。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。