チャットに流れた知見を消さない。ログを組織のナレッジに変える

Slackのような社内のチャットには、顧客対応で得た知見やトラブルの原因と対処、判断の理由といった価値の高い情報が流れています。
会議の議事録より実務的な情報が、チャットのほうに残っていることも少なくありません。
ところがそれはスクロールに流れて二度と参照されず、検索しても当時の文脈が分からないまま使えなくなります。

今回は、このログの蓄積について書いていきます。
社内ナレッジの基盤そのものは社内ナレッジをAIで活用する方法。ツール導入・RAG・手持ちのAIの選び方にまとめてあります。

良い議論は、スクロールの奥に消えていきます

なぜ流れてしまうのでしょうか？
理由は、時系列でしか並ばない点、検索が効きにくい点、誰も整理しない点の3つに集約されます。

テーマ別に整理されていないので、後から探せません。
単語で検索しても大量の会話が出てくるだけで文脈までは拾えず、整理する担当も動機もないままログだけが伸びていきます。
「あのとき誰かが書いていた」という記憶だけが残り、探しても見つからないまま、同じ質問をもう一度することになります。

蓄積の価値も整理しておくと、過去の対処を探せる、判断の経緯を追える、よくある質問が分かるの3点に加え、顧客の声が集まる、業務の実態が見える効果も続きます。
なかでも効くのは、よくある質問が分かることで、同じ質問が5回来ていると分かれば手順書を1枚作るだけで済みます。

蓄積は「小さく集めて、育てる」の順で効きます

導入も段階を踏むもので、最初から全部を集めようとすると続きません。

最初は蓄積で、主要なチャンネルのログを定期的に表へ貯めていきます。
「全部を集めない」のが要点で対象を絞り、目安は業務の相談が流れるチャンネル、顧客対応の情報が流れるチャンネル、技術的な議論が流れるチャンネルの3つです。
雑談のチャンネルや個人間のやり取り、人事や経営に関わるチャンネルは対象から外します。

記録する項目は日時、チャンネル、発言者、本文、元の発言へのリンクの5つで、なかでも「元の発言へのリンク」を残すのが要点になります。
文脈を確認したいときに元の会話へ戻れるように、最初は2〜3チャンネルで始めます。
全チャンネルを対象にすると量が多すぎて、次の段階に進めなくなります。

蓄積したものは週次で要約して配信し、その週に議論された話題、解決した問題とその対処、未解決のまま流れた質問の3つを入れます。
なかでも効くのは未解決のまま流れた質問で、誰かが質問して誰も答えないまま流れた問いを拾うと、放置されていた困りごとが解消されます。
配信先はそのチャンネルに参加していない関係部署にし、「他の部門で何が起きているか」が分かる経路にします。

分量は10行程度に決めておかないと、長いものは読まれません。
この段階の効果は部門間の情報の流通にあり、会議を減らした場合の代わりの経路にもなります。

蓄積が数か月分たまったら参照先として使い、「テーマごとに分ける」のがコツで、全部を1つの参照先にすると精度が落ちます。
技術的な議論、顧客対応、業務の手順というように分けておきます。

最も効くのはトラブルの対処で、「このエラーは過去にどう対処したか」に実際の記録から答えられ、手順書に書かれていない実務の知見がそこにあります。

もう一つが「よくある質問」の抽出で、繰り返し出ている質問を集計して上位10個について手順書を作ると、質問そのものが減ります。
会話からFAQを作る話は現場の会話からFAQを作る。商談ログとチャットログを資産化するにまとめてあります。

注意したいのはログには誤った情報も含まれることで、「Aだと思う」という推測が確定した情報として参照されるおそれがあります。
ただ、参照するときはそれが議論の記録であることを明示しておきます。
回避策のナレッジ化はAIが「できません」と返す時。回避策を社内ナレッジにするで扱っています。

プライバシーの整理は、技術より先に済ませます

この領域は扱いに注意が必要で、何を確認しておけばいいのでしょうか？
蓄積の周知、個人間のやり取りの除外、発言者の名前の記録、保存期間の4つを見ていきます。

「このチャンネルのログは蓄積されます」と明示しておかないと、黙って集めることになり信頼を失います。
ダイレクトメッセージは対象外にし、ここは明確に線を引くところです。
発言者の名前を記録すると誰が何を言ったかがあとから追えるので、議論の記録としては必要な一方、監視の道具にもなり得ます。

最も判断が要るのはこの発言者名の扱いで、現実的なのは発言者を記録しつつ参照するときは名前を出さない形です。
「過去にこう対処した記録があります」という形で答え、誰が言ったかは元の発言へのリンクから確認できるようにしておきます。

保存期間は、いつまで残すかを先に決めておきます。

蓄積の失敗は、監視だと受け取られた瞬間に始まります

発言者の記録の話の続きで、蓄積が監視だと受け取られると何が起きるでしょうか？
チャットの発言そのものが減り、蓄積の価値が失われます。

やることは目的を明示する、集計を個人単位で出さない、対象外のチャンネルを認めるの3つです。
「過去の対処を探せるようにするため」「同じ質問を繰り返さないため」というように、個人の発言量を評価するためではないと明言しておきます。
集計はチャンネル単位・テーマ単位で出し、「誰が何回発言したか」は出しません。

「このチャンネルは蓄積しないでほしい」という要望は受け入れ、強制すると別の場所で会話が始まってしまいます。
なかでも効くのはこの対象外を認めることで、逃げ場があると蓄積されるチャンネルでの発言が減りません。
ツールが複数に分かれている場合の扱いは複数のチャットツールが混在する組織で、情報を横断的に扱うにまとめてあります。

つまずきやすいのは、全チャンネルを対象にする、元の発言へのリンクを残さない、蓄積を周知しない、個人間のやり取りを含める、個人単位で集計を出す、ログを確定した情報として参照させる、対象外のチャンネルを認めないの7つです。
どれも2〜3チャンネルから始め、リンクを残し、先に周知し、線を引き、チャンネル単位で集計し、議論の記録だと明示し、逃げ場を認めれば防げます。

蓄積したログは、部門を越えて引けて初めて資産になります

ここまでは蓄積の仕組みの話で、難しいのは蓄積したものが実際に使われる状態を作ることです。

表に数万件のログがたまっても通して読む人はおらず、必要なのは「引ける状態」です。
つまり「この種類のトラブルの過去の対処」「この顧客について過去に出た話」といった問いに、答えられる状態にしておくという設計です。
部門を越えて引けることも重要で、技術的な対処の記録は他のチームにも価値がありますし、顧客の反応の記録はマーケティングにも価値があります。

ところが部門のチャンネルに閉じたログは、他部門からは見えません。
また、蓄積したログは他のナレッジと一緒に扱えると価値が上がり、議事録、手順書、商談の記録が別々の場所にあると探す場所が複数になってしまいます。

チャットと並ぶもうひとつの流れである会議の記録については、会議と議事録のAI化。準備から共有・タスク化までの設計で一通り整理しています。

当社の組織のAIポータル「AI Portalize」では、ログをもとに作ったGemini NotebookやGemを登録すると全社に公開され、ほかのナレッジと同じ場所で検索できます。
蓄積は始めたが使われていない、という状態で止まっている場合は、考え方の参考になるかもしれません。

チャットのログは、消える前提ではなく残す前提に変えます

チャットの情報が流れるのは、時系列でしか並ばない、検索が効きにくい、誰も整理しないという3つが理由で、会議の議事録より実務的な情報がここにあります。

蓄積すると、過去の対処を探せる、判断の経緯を追える、よくある質問が分かる、顧客の声が集まる、業務の実態が見えるようになり、なかでも効くのはよくある質問が分かることです。
進め方は3段階で、2〜3チャンネルの蓄積から始め、週次で要約を配信し、テーマごとに分けて参照先にします。
プライバシーの整理は先に済ませ、周知、個人間のやり取りの除外、発言者の記録の扱い、保存期間の4点を見ておきます。

監視だと受け取られると発言が減り蓄積の価値そのものが失われるので、目的の明示、個人単位で出さない集計、対象外のチャンネルを認めることの3つで防ぎ、なかでも効くのは対象外を認めることです。
ログには誤った情報も含まれるので、参照するときは議論の記録であることを明示しておきます。

業務の相談が流れるチャンネルで、蓄積はもう始まっているでしょうか。