生成AIの社内教育を始めた。
実例カードも作った。
入力してよい情報、止める場面、確認する人も少しずつ決めた。
では、その後に残った質問や気づきは、どこへ置けばいいのか。
ここで多くの会社が考えるのは、社内FAQです。
よくある質問をまとめる。
回答を作る。
社内ポータルやチャットボットに入れる。
もちろん、それ自体は大事です。
ただ、僕は生成AIの社内ナレッジをいきなりFAQから作ろうとすると、少し危ないと思っています。
なぜなら、FAQは「整理された答え」に見えるからです。
でも、生成AI活用の初期段階で本当に残したいのは、きれいな答えよりも、現場で迷った判断の跡です。
この問い合わせ文は、どこまで伏せればAIに入れてよかったのか。
AIが出した回答案の、どこを人が直したのか。
その修正は、次回のプロンプトに反映した方がいいのか。
似た質問が来たとき、前回の判断を誰が見ればいいのか。
ここを残さずにFAQだけ増やすと、表面上はナレッジが増えたように見えます。
でも、現場ではまた同じところで迷います。
以前、AI活用の効果測定は、成果より先に運用ログから始める で、まず使った業務と結果を残す話を書きました。
その後、AI社内ルールは、改善会議の決定事項から小さく更新する と 生成AIの社内教育は、ルール説明より実例共有から始める で、ログをルールや教育へつなげる流れを整理しました。
今回は、その次です。
AI活用で出てきた迷い、質問、失敗例を、どうやって社内ナレッジとして残すのか。
総務省・経済産業省の AI事業者ガイドライン第1.2版 では、AIの活用に関わる人がリスクや責任を理解し、組織として継続的に取り組む考え方が整理されています。
IPAの AI利用者のためのセキュリティ豆知識 でも、生成AI利用時に利用者が気をつけるべき情報の扱いが、現場に近い形で紹介されています。
経済産業省とIPAの デジタルスキル標準 でも、デジタルを使う人が学び続け、業務に活かす視点が整理されています。
ただ、小さな会社が最初から大きなナレッジ基盤を作る必要はありません。
最初に作るべきなのは、AI活用の実例を、次の人が見返せる小さなメモです。
生成AIの社内ナレッジは、FAQを増やすことより、現場で迷った判断を実例メモとして残すことから始める。
今日は、中小企業や小規模事業者が、AI活用の質問や失敗を社内ナレッジへ変える手順を整理します。
生成AIの社内ナレッジは、FAQを増やすより実例メモから始める
社内ナレッジを作ろうとすると、まずFAQを増やしたくなります。
「AIに個人情報を入れていいですか」
「議事録を要約してもいいですか」
「お客様への返信文をAIに作らせてもいいですか」
「AIの回答はそのまま使っていいですか」
こうした質問に答えるページを作る。
それは確かに必要です。
ただ、生成AI活用の初期段階では、FAQの回答をきれいに書く前に、実際に起きた場面を残した方がいいです。
たとえば、問い合わせ返信で迷った場面があったとします。
お客様の名前、会社名、メールアドレスは伏せた。
でも、問い合わせ内容の中に、契約状況や地域や課題がかなり入っていた。
この状態でAIに入れてよいのか迷った。
そこで今回は、問い合わせ内容をもう少し一般化して、返信の構成案だけを作らせた。
最後は担当者が事実確認し、自社の言葉に直して送った。
この一連の流れこそ、社内ナレッジです。
FAQの回答にすると、「個人情報や機密情報は伏せて利用しましょう」で終わるかもしれません。
でも、それだけでは次の人が判断できません。
どこで迷ったのか。
どこを伏せたのか。
AIには何を頼んだのか。
人はどこを確認したのか。
次回から何を変えるのか。
この実例が残っていると、同じような場面で迷う時間が減ります。
生成AIの社内ナレッジは、完成された教科書ではありません。
最初は、現場の判断メモで十分です。
むしろ、最初からきれいなFAQを作ろうとすると、実務から離れます。
「一般的にはこうです」
「当社では適切に確認します」
こういう文章は、それっぽいけれど使いにくいです。
現場が欲しいのは、次に似た状況が来たときに、どこまで進めてよいかの判断材料です。
だから、最初のナレッジは実例メモでいい。
1つの業務。
1つの迷い。
1つの判断。
1つの次回改善。
この粒度なら、小さな会社でも残せます。
社内FAQは、その実例メモが何件か溜まってから作ればいいです。
FAQは入口。
実例メモは判断の中身。
この順番で考えると、ナレッジが現場に残りやすくなります。
迷った場面を、あとで検索できる質問として残す
実例メモを残すとき、日記のように書くとあとで探しにくくなります。
「今日、問い合わせ対応で少し迷った」
「AIの回答が微妙だった」
「次回は注意する」
これだと、後から検索できません。
社内ナレッジにするなら、迷った場面を質問の形にして残すのがおすすめです。
たとえば、こんな形です。
- 顧客名を伏せた問い合わせ文は、AIに入れてよいのか
- AIが作った返信文が冷たいとき、どこを直せばよいのか
- 会議メモを要約するとき、未決事項をどう分けるのか
- 社内資料をもとにFAQ案を作るとき、どこまで情報を出してよいのか
- AIで作った文章をお客様へ送る前に、誰が何を確認するのか
このように質問の形で残すと、後から同じ言葉で探しやすくなります。
検索するとき、人はきれいな分類名では探しません。
「問い合わせ AI 個人情報」
「AI 返信 冷たい」
「議事録 要約 未決」
「FAQ 社内資料 どこまで」
こんな言葉で探します。
だから、実例メモのタイトルは、現場の人が口にする言葉に寄せた方がいいです。
きれいなカテゴリ名にしすぎると、作った人しか探せません。
「AI利用時の情報管理に関する留意事項」
これも間違いではありません。
でも、現場では少し遠い。
「問い合わせ文をAIに入れる前に、どこを伏せるか」
この方が、次の人が見つけやすいです。
社内ナレッジは、正しい分類である前に、見つけられることが大事です。
見つからないナレッジは、ないのとほぼ同じです。つらい。
最初から完璧なタグ設計をしなくても大丈夫です。
業務名。
迷ったこと。
AIに頼んだこと。
結果。
この4つがタイトルや冒頭に入っていれば、だいぶ探しやすくなります。
たとえば、問い合わせ対応ならこうです。
「問い合わせ返信で、顧客名を伏せてAIに構成案を作らせた例」
議事録ならこうです。
「会議メモから決定事項と未決事項を分けた例」
FAQ作成ならこうです。
「公開済みブログから社内FAQ案を作った例」
これくらいで十分です。
ナレッジを育てる初期段階では、分類より検索性を優先する。
まずは、あとで誰かが探せる質問として残す。
これだけで、AI活用の記録はかなり使いやすくなります。
入力・出力・確認・修正の4点でメモをそろえる
実例メモは、書く人によって粒度がバラバラになりがちです。
ある人はプロンプトだけ残す。
ある人はAIの回答だけ貼る。
ある人は「うまくいった」とだけ書く。
ある人は細かく書きすぎて、次の人が読めない。
これでは、社内ナレッジとして使いにくくなります。
最初にそろえるなら、僕は4点で十分だと思っています。
入力。
出力。
確認。
修正。
この4つです。
入力は、AIに何を渡したかです。
実際の全文をそのまま残す必要はありません。
むしろ、個人情報や機密情報が入るなら残さない方がいいです。
「顧客名、会社名、連絡先を伏せた問い合わせ要約」
「社内会議メモから個人名を抜いたもの」
「公開済みサービスページの文章」
このように、入力の種類を残します。
出力は、AIが何を作ったかです。
返信文の下書き。
議事録の要約。
FAQ候補。
営業資料の構成案。
ブログの見出し案。
ここも全文を残すより、「どんな出力を得たか」が分かれば十分なことがあります。
確認は、人がどこを見たかです。
事実関係。
お客様に出してよい表現か。
自社のトーンに合っているか。
個人情報や機密情報が残っていないか。
専門判断をAIに任せすぎていないか。
ここが一番大事です。
AI活用のナレッジで残すべきなのは、AIが何を出したかだけではありません。
人がどこを見たかです。
修正は、次回に活かすための変更点です。
プロンプトに「結論を先に」と足した。
専門用語を減らす指示を入れた。
返信文の最後に、次のアクションを入れるようにした。
議事録では、決定事項と未決事項を分けるようにした。
FAQ案では、社内向けとお客様向けを分けるようにした。
この修正が残っていると、次の人が同じ失敗を繰り返しにくくなります。
テンプレートは、難しくしなくていいです。
- 業務名
- 迷ったこと
- 入力した情報の種類
- AIに頼んだこと
- 出力で使えたところ
- 人が確認したところ
- 修正したところ
- 次回からの一言ルール
これくらいで十分です。
最初から項目を増やしすぎると、誰も書かなくなります。
ナレッジは、書けることが先です。
完璧な形式より、続く形式。
ここを外すと、社内ナレッジは急に管理仕事になります。
それは、まあまあ続きません。
共有前に、個人情報と機密情報を抜く
AI活用の実例メモを残すとき、必ず気をつけたいのが情報の扱いです。
「実例を残しましょう」と言うと、実際の問い合わせ文、会議メモ、顧客情報、社内資料をそのまま貼ってしまうことがあります。
これは危ないです。
社内ナレッジに残す情報は、次の人が見返すものです。
見返す人が増えるほど、情報の範囲も広がります。
だから、共有前に個人情報と機密情報を抜く工程を入れた方がいいです。
たとえば、問い合わせ対応の実例なら、次のような情報はそのまま残さない方が安全です。
- 氏名
- 会社名
- 電話番号
- メールアドレス
- 住所
- 契約内容
- 見積金額
- 未公開の商談情報
- クレームの具体的な個人特定情報
これらを伏せたうえで、「どんな種類の問い合わせだったか」だけ残します。
具体名ではなく、業務の型として残す。
これがポイントです。
たとえば、実例メモにはこう書けます。
「既存顧客から、契約範囲に関する問い合わせがあった」
「料金に関する確認が含まれていたため、AIには全文を入れず、一般化した要約だけ渡した」
「AIには返信の構成案だけを作らせ、金額や契約判断は担当者が確認した」
これなら、次の人が判断の流れを学べます。
でも、具体的なお客様情報は残りません。
会議メモも同じです。
参加者の個人名。
未公開の人事情報。
取引先名。
契約前の条件。
こうした情報をそのまま実例メモに入れると、ナレッジの共有範囲を広げにくくなります。
「後から社内全体に共有したい」と思っても、情報が重すぎて出せない。
結果として、ナレッジが担当者の手元に閉じます。
それではもったいないです。
AI活用の実例メモは、なるべく業務の判断だけを残す。
固有名詞や具体条件は削る。
必要なら、原本の保存場所と閲覧権限を別で管理する。
この分け方が大事です。
IPAのセキュリティ資料でも、生成AI利用時には入力する情報や出力の扱いに注意する視点が示されています。
小さな会社では、専門的なセキュリティ体制をいきなり作るのは難しいかもしれません。
でも、実例メモを共有する前に「誰の情報が入っているか」「社外秘が残っていないか」を見るだけでも、事故の可能性は下げられます。
ナレッジを増やすことと、情報を広げすぎることは別です。
使いやすいナレッジほど、安全に共有できる形にしておく。
この意識は、AI内製化のかなり大事な土台です。
15分の改善会議で、実例メモをFAQに育てる
実例メモが数件溜まってきたら、そこで初めてFAQに育てます。
順番としては、実例メモが先。
FAQは後です。
理由は、実例メモを見てからでないと、現場で本当に繰り返される質問が分からないからです。
頭の中だけでFAQを作ると、どうしても一般論になります。
「生成AIに個人情報を入れてよいですか」
「AIの回答は信頼できますか」
「プロンプトはどう書けばよいですか」
もちろん大事です。
でも、現場が実際に迷うのは、もっと具体的です。
「問い合わせ文に会社名はないけど、契約内容が分かる場合はどうするのか」
「AIが作った謝罪文が丁寧すぎるとき、どこを直すのか」
「FAQ候補を作ったけれど、社内向けとお客様向けが混ざったときはどう分けるのか」
こういう質問は、実例から出てきます。
だから、改善会議で実例メモを見ます。
時間は15分でいいです。
長くすると重くなります。
会議では、次の3つだけ見ます。
1つ目は、同じ迷いが繰り返されているか。
2つ目は、次回から一言で伝えられるルールがあるか。
3つ目は、FAQにした方がいいか、実例メモのままでいいか。
たとえば、問い合わせ文の匿名化で何度も迷っているなら、FAQにします。
「問い合わせ文をAIに入れる前に、どこを伏せるか」
回答には、伏せる項目、AIに頼んでよい範囲、人が確認するポイントを書きます。
一方で、特殊な商談の判断のように、毎回条件が違うものはFAQにしすぎない方がいいです。
「この条件なら必ずこうする」と書くと危ないことがあります。
その場合は、実例メモとして残し、「判断が必要なケース」として扱います。
FAQにするかどうかの判断も、ナレッジ運用の一部です。
何でもFAQにすると、FAQが膨らみます。
FAQが膨らむと、読む人が探せなくなります。
探せないFAQは、結局使われません。
だから、実例メモを見て、繰り返し使えるものだけFAQにする。
単発の判断は、実例として残す。
この分け方が大事です。
15分の改善会議では、完璧なドキュメントを作る必要はありません。
「これはFAQへ」
「これは実例のまま」
「これはルールへ反映」
この3つに振り分けるだけでも十分です。
AI活用のナレッジは、会議で話して終わりにしない。
話したことを、FAQ、実例メモ、社内ルールのどれかに置く。
ここまでやると、改善が次回に残ります。
30日ごとに、使われなかったナレッジを整理する
社内ナレッジは、増やすことより整えることが難しいです。
最初は少ないので問題ありません。
でも、AI活用が進むと、メモ、FAQ、プロンプト、ルール、教材が増えていきます。
すると、今度は探せなくなります。
どれが最新なのか。
どれを使えばいいのか。
昔のルールが残っていないか。
似たFAQが2つないか。
誰も使っていないメモが増えていないか。
こうなると、ナレッジが重くなります。
ナレッジが重くなると、現場はまた個人判断に戻ります。
だから、30日ごとに小さく整理した方がいいです。
やることは難しくありません。
まず、よく見られたメモやFAQを残します。
次に、同じ内容が重なっているものをまとめます。
古い判断は、今のルールと違っていないか確認します。
使われていないメモは、残す理由があるか見ます。
判断が変わったものは、古い内容を見えにくい場所へ移すか、更新日を明記します。
ここで大事なのは、捨てすぎないことです。
失敗例や迷った例は、すぐには使われなくても、後から役に立つことがあります。
ただし、古いまま残しておくと誤解されます。
だから、「過去の実例」「現在のルール」「FAQ」を分けるといいです。
過去の実例は、判断の経緯を見る場所。
現在のルールは、今やることを見る場所。
FAQは、よくある質問から入口を探す場所。
この3つが混ざると、読みにくくなります。
社内ナレッジの整理は、管理者だけがやる仕事にしない方がいいです。
実際にAIを使った人が、「このメモはもう古い」「このFAQはまだ使う」「このプロンプトは直したい」と言える場が必要です。
それも、15分で十分です。
月末に少し見る。
よく使ったものを残す。
似たものをまとめる。
古いものに印をつける。
次に書くべきメモを1つ決める。
これくらいなら続けやすいです。
生成AIの社内ナレッジは、作った瞬間から古くなります。
ツールも、社内ルールも、業務のやり方も変わるからです。
だから、ナレッジは固定物ではなく、運用品として見る。
30日ごとに軽く整える。
このリズムを作るだけで、社内ナレッジはかなり生き残りやすくなります。
まとめ：社内ナレッジは、判断を次の人へ渡す場所
生成AIの社内ナレッジは、情報をたくさん置く場所ではありません。
判断を次の人へ渡す場所です。
この場面では、AIに何を頼んだのか。
どの情報は入れなかったのか。
AIの出力を、人がどこで止めたのか。
どこを直したのか。
次回から何を変えるのか。
これが残っていると、AI活用は個人の勘だけに戻りにくくなります。
FAQを作ることは大事です。
でも、FAQだけでは判断の細かい揺れまでは残りません。
だから、最初は実例メモから始める。
迷った場面を、あとで検索できる質問として残す。
入力・出力・確認・修正の4点でメモをそろえる。
共有前に、個人情報と機密情報を抜く。
15分の改善会議で、実例メモをFAQに育てる。
30日ごとに、使われなかったナレッジを整理する。
この順番なら、小さな会社でも始めやすいです。
生成AIの内製化は、ツールを入れたら終わりではありません。
使った人の判断が、次の人に渡るようになること。
同じ迷いを、少しずつ減らせること。
失敗や修正が、会社の学習に変わること。
そこまで行くと、AI活用は一部の詳しい人だけのものではなくなります。
社内ナレッジは、立派なシステムから始めなくていいです。
まずは、今日迷った1件を残す。
そのときに、何を入れて、何を出して、どこを人が見て、次に何を直すかを書く。
その小さなメモが、次の人を助けます。
「AIを社内で使い始めたけれど、質問や失敗が個人の中に散らばっている」
「FAQや社内ルールを作りたいけれど、何から残せばいいか分からない」
そんな状態なら、まずは実例メモの型から作るのがおすすめです。
無料相談 では、今の業務、AI活用の状況、社内ルールや教育の有無を聞いたうえで、どんな実例メモから社内ナレッジ化すればよいかを一緒に整理します。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。