1. はじめに：「ドキュメントを整備しよう」と言うが、誰も書かない
「業務の属人化を防ぐために、手順書やナレッジをWikiにまとめましょう」——。 多くの企業のバックオフィス改善プロジェクトで、こういった方針が掲げられます。NotionやConfluenceなどの素晴らしいWikiツールが導入され、テンプレートが用意され、「積極的にドキュメントを残しましょう」という社内周知も行われます。
しかし、数ヶ月後にWikiを見てみると、残っているのは最初に気合を入れて作った数本の記事だけ。その後はほとんど更新されず、情報は古くなり、結局「あの件は〇〇さんに直接聞く」という属人化が元通りになってしまう——。
これは特定の会社の失敗例ではなく、ほぼすべての組織が経験する**「ナレッジ管理の普遍的な失敗パターン」**です。
なぜこうなるのか。答えはシンプルです。「業務を行うこと」と「業務をドキュメント化すること」は、全く別の、追加の作業だからです。忙しい現場では、目の前の業務をこなすだけで精一杯であり、終わった後に「ドキュメントを書く」という余裕は生まれません。
連載第8回は、この根深い**「ナレッジ管理の失敗構造」**を生成AIがどのように解決するかを解説します。キーワードは「書かせるのではなく、AIが自動で抽出する」です。
2. 現場のリアルな課題：ツールを導入しても「書く人がいない」問題の本質
Notionや社内WikiなどのSaaSを「用意すること」と、そこにナレッジが「溜まること」は全く別の話です。 既存のツールが解決できなかった本質的な課題は、以下の3点に集約されます。
課題① ドキュメントを「書く」行為へのハードル
業務の手順や知識を文章にまとめるには、整理する力、文章力、時間の3つが必要です。これは決して軽い作業ではなく、特に日々の業務で多忙な「業務エキスパート」と呼ばれる人たちほど、この作業を後回しにしてしまいます。
課題② 情報が「担当者の頭の中」にしかない
最も価値あるナレッジは、往々にして「担当者の頭の中」にある暗黙知です。例えば「〇〇社との取引は、必ず購買部のAさんを通すこと。法務部のBさんと過去にトラブルがあったので直接話を通してはいけない」といった、手順書には絶対に書かれない「コンテキスト情報」です。この暗黙知は、その人が退職・異動した瞬間に組織から消滅します。
課題③ 書かれたドキュメントが古くなる
仮にドキュメントが書かれたとしても、業務フローやシステムが変わった時に更新されなければ、すぐに「信頼できない古い情報」となり、誰も参照しなくなります。更新の手間が常に担当者に課せられる構造が問題です。
3. 生成AIによるブレイクスルー：「書かせる」から「自動で抽出する」へのパラダイムシフト
このナレッジ管理の構造的な失敗を解決する生成AIのアプローチは、発想の転換が鍵です。 「人間にドキュメントを書かせる」のではなく、**「人間がすでにやっていること（チャット・会議・メール）から、AIが自動でナレッジを抽出する」**のです。
① Slack/Teamsのチャット履歴からの自動抽出
組織の中で日々交わされているSlackやTeamsのやり取りは、実は膨大なナレッジの宝庫です。 「この請求書の処理、どうすればいい？」「こういう場合はこっちのフォームを使ってね」 「あの顧客のシステム、特殊な仕様があって……」 「この対応は、昔〇〇という理由でこう決めたんだよ」
生成AIは指定したチャンネルの会話を定期的にスキャンし、「手順や知識が含まれていそうな会話」を自動で検出し、それをWikiフォーマットの下書きとして整理・出力します。
生成されるドキュメントのイメージ：
【自動生成ドキュメント案】新規仕入れ先への初回支払い手順
作成日：2024-10-15 情報源：#経理-相談チャンネル（10月14日の会話）
手順：
- 経理システムにて「新規仕入れ先登録申請フォーム」を提出する（購買部担当者が実施）
- 経理部にて登録内容を確認後、承認（通常2〜3営業日）
- 承認完了後、初回の請求書を「仕入れ先コード」を付記してシステムに登録する
注意事項： 登録前に支払いを処理すると、システムエラーが発生するため必ず手順①②を先に完了させること。
担当者は、このAIが自動生成した下書きを見て「承認する」か「少し修正して承認する」かを選ぶだけです。ドキュメントをゼロから書く必要は一切ありません。
② 会議の文字起こしデータからのナレッジ抽出
Zoom/Teams等の会議録画から自動で文字起こしされたデータを生成AIに渡すと、その会議で共有された業務ナレッジや決定事項をドキュメントとして整理してくれます。
「定例の引き継ぎミーティング」や「ベテラン社員のノウハウ共有会議」などを録画しておくだけで、その会話の中にあった暗黙知が自動的にWikiに反映されていく、という仕組みが実現します。
③ 既存ドキュメントの自動更新サジェスト
業務フローやシステムが変わった際、チャット上でその変更が周知された場合、AIは関連する既存のWiki記事を検出し、「この記事が古くなっている可能性があります。更新しますか？」とサジェスト（提案）してくれます。これにより、ドキュメントが古くなり続けるという問題にも対応できます。
4. 具体的な業務フローのBefore / After
【Before】「書く人任せ」で属人化が加速する
- 業務が発生：新しい対応手順が口頭・チャットで共有される。
- ドキュメント化のリクエスト：「Wikiにまとめておいてください」と言われるが、誰も時間が取れずに放置。
- 属人化：その業務の知識は、口頭で教えた人の頭の中にしか存在しない。
- 組織的ロス：その人が退職・異動すると、知識が失われ、次の担当者が同じ試行錯誤を一から繰り返す。
【After】AIが日常業務からナレッジを自動蒸留する
- 業務が発生：新しい対応手順がチャットや会議で共有される（従来通り）。
- AIが自動検出・下書き生成：翌日、Wikiの担当者（または発言した当事者）に「このような内容でドキュメント化しますか？」とAIから通知が届く。
- 人間は承認するだけ：内容を確認して「承認」ボタンを押すだけで、Wikiに正式な記事として登録される（所要時間：30秒〜1分）。
- ナレッジが自然に蓄積：担当者が意識しなくても、組織の知識が継続的に更新・蓄積されていく。
5. 導入に向けたステップと注意点
- プライバシーと情報管理のポリシー設計が最重要 Slackの全チャンネルの会話をAIがスキャンする場合、個人情報や機密情報が含まれるメッセージが誤ってドキュメント化されるリスクがあります。スキャン対象のチャンネルを「業務相談系」に限定する、機密指定されたメッセージは除外するなど、情報管理のポリシーを先に設計してください。
- 「承認フロー」を設けてドキュメントの品質を担保する AIが自動生成した下書きをそのままWikiに公開してしまうと、不正確な情報が組織に広がるリスクがあります。必ず担当者（その業務のエキスパート）が内容を確認・承認してから公開するワークフローを設計してください。
- まず小さな範囲でパイロット導入する 最初から全社展開するのではなく、「経理部の業務相談チャンネル」や「情シスのQ&Aチャンネル」など、ナレッジが特に集中する特定のチャンネルに絞ってパイロット導入し、品質と運用フローを検証してから展開範囲を広げるアプローチを推奨します。
6. おわりに
「誰もWikiを書かない」という問題の根本には、「書く」という行為が人間のアクションとして要求されているという構造的な問題があります。 生成AIは、人間が日常的に「すでにやっていること」のデータ（チャット・会議）から、ナレッジを自動的に蒸留・構造化することで、この構造問題そのものを解消します。
次回、第9回は経営企画・総務部門向けに、**【役員会・重要会議の「アクション化」要約】**をテーマにお届けします。「文字起こしツールを導入したのに、結局誰かがまとめ直している」という問題を、生成AIが解決するプロセスを詳しく解説します。お楽しみに！
