あなたの会社で、こんな場面を見たことはないだろうか。

ベテランが退職する。引継ぎ書は渡した。しかし3ヶ月後、後任者は困るたびに退職したその人に電話をかけている。マニュアルは存在する。SharePointにも入っている。でも誰も読まない。「あの件、どこに書いてありましたっけ」という会話が、毎日どこかで発生している。

これは日本企業だけの問題ではない。国を問わず、業種を問わず、規模を問わず、30年間繰り返されてきた構造的な問題だ。

そしてその30年の歴史を知らなければ、RAGを正しく評価することはできない。

1990年代：「知識を資産に変える」という壮大な夢

「ナレッジマネジメント（KM）」という言葉が世界の経営界を席巻したのは1990年代後半のことだ。

野中郁次郎と竹内弘高が1995年に発表した『知識創造企業』は「暗黙知を形式知に変換せよ」という概念を提唱し、McKinseyやDeloitte、アクセンチュアといったグローバルコンサルがこれを経営戦略のキーワードとして採用した。世界中の企業に「ベストプラクティスを記録し、組織知として共有する仕組みを構築しましょう」という提案が持ち込まれた。

高価なKMシステムが売れた。コンサルティングフィーが積み上がった。プロジェクトが立ち上がった。

そして3年後、どうなったか。

システムだけが残り、データは腐っていた。

入力してくれる人間がいなかったのだ。ベテランの仕事は忙しい。顧客からの電話が来る。会議がある。障害対応がある。「ナレッジを入力する」作業は常に後回しになった。「余裕ができたら書きます」——その余裕は、どこの組織でも来なかった。

この時代の数少ない「成功事例」として語られるのは、コンサルファーム自身の知識データベースだ。

McKinseyやアクセンチュアが自社内で構築したKMシステムは、確かに機能したとされている。しかし冷静に考えると、これは特殊なケースだ。コンサルタントにとって「過去の案件事例」「アプローチの再利用」「知識の共有」は、直接的に売上と評価に直結する。入力しなければ自分が損をする。この構造があって初めて、KMは機能した。

しかも「成功した」と言っているのは、そのコンサルファーム自身だ。成功と主張することがブランドになる立場の組織の自己申告を、額面通りに受け取るべきかどうかは慎重に考えた方がいい。

同時期、もう一つの「成功例」として研究機関の文献管理システムがある。大学や研究所が構築した「研究樹木ツリー」——論文・研究プロジェクト・研究者の関係性を体系化したデータベースだ。これも機能したが、理由は明快だ。研究者にとって「誰が何を研究しているか」「どの論文が引用されているか」は予算獲得と評価に直結する。やはり、インセンティブが構造に組み込まれていた。

一般企業でKMが失敗し続け、コンサルファームと研究機関でかろうじて機能した——この対比が示しているのは、知識管理の成否を決めるのは「技術の優劣」ではなく「インセンティブ設計」だという事実だ。

2000年代：「タグ付けすれば機械が理解できる」という幻想

KMブームが一段落した2000年代、次のアプローチが登場した。セマンティック・ウェブだ。

「すべての情報にメタデータ（意味タグ）を付与すれば、コンピューターが情報の意味を理解できるようになる」——W3Cのティム・バーナーズ＝リーが提唱したこのビジョンは、当時の技術者と経営者を熱狂させた。

エンタープライズ向けにも多くのベンダーが参入した。「弊社のオントロジーエンジンを使えば、社内文書が意味的に整理され、自動的に関連情報が紐付けられます」——そういう提案が横行した。PoC（概念実証）段階では動いて見えた。モデルケースとなる文書を数百件、精緻にタグ付けすれば、検索精度が劇的に上がる。デモとしては完璧だった。

しかし本番に進んだ途端に崩壊した。

数万件・数十万件の社内文書に、正確なタグを人間が付け続けることは不可能だった。タグの付け方が人によって異なる。定義がずれる。新しい業務領域が生まれてもオントロジーが追いつかない。3年後には「精度の高いタグが付いた数百件」と「タグなしの数万件」という状態になっていた。

同じ時期、SharePointやLotus Notesによる「全社ポータル構築」プロジェクトが日本中の企業で走った。「情報をここに集約すれば、誰でも検索できる」。しかし集約された情報は更新されず、ポータルは「過去の情報の墓場」と化した。検索しても古い情報しか出てこない。誰も信用しなくなった。

この時代の失敗の本質は、「情報を整理するコストを、全員に・継続的に負わせようとした」ことにある。

2010年代前半：エンタープライズ検索と「中身のない箱」

2010年代に入ると、Elasticsearchをはじめとする高性能な全文検索エンジンが登場した。大量の文書を高速にインデックス化し、キーワードで瞬時に検索できる。技術としては十分に成熟していた。

しかし「社内で使える」とはならなかった。

キーワード検索の根本的な限界がある。「有給申請の方法が知りたい」と思った人が「休暇届 PDF 手続き」と検索するとは限らない。「休み申請どうやって」と入力するかもしれない。単語が一致しなければヒットしない。結局、「どう検索すればいいか知っている人だけが使えるシステム」になった。

さらに深刻な問題があった。「まず文書を整理してから検索基盤を構築しよう」という話が、どこの組織でも終わらなかったのだ。文書が整理されていなければ、何を検索してもゴミが出てくる。ゴミを出さないために文書を整理しようとすると、それ自体が巨大なプロジェクトになり、本来の目的を忘れる。こうして「文書整理プロジェクト」は永遠に終わらない前工程として組織に居座り続けた。

2010年代後半：チャットボット地獄

2015年頃から「AIチャットボット」が流行し始めた。「よくある質問にAIが自動で答えます」というソリューションがコールセンターやヘルプデスクを中心に急速に普及した。

この時代のベンダー提案の定番フレーズは「AIが自動学習します」だった。しかし実態はほぼすべての場合、手作業のQAペア管理だった。「質問文→回答文」のペアを数百件から数千件、人間が作成・登録・更新し続ける。AIが「自動学習」するのは、そのQAペアのパターンマッチングだ。

半年後のパターンはどこでも同じだった。立ち上げ当初は担当者が熱心にQAを整備する。しかし業務は変わる。規程は改訂される。新しい制度が始まる。チャットボットの回答は古くなっていくが、更新するコストは重く、担当者は疲弊し、気がつけばボットは誰も信用しない「古い情報を自信満々に答える機械」になっていた。

同じ頃、より本格的な「AI活用」として機械学習を使った文書分類・自動タグ付けも登場した。これはセマンティック・ウェブの反省を踏まえ、「タグは人間が付けるのではなくAIに推定させる」という発想の転換だった。精度は改善したが、「AIの推定が間違えたとき、誰が正す責任を持つか」という問題が組織設計として解決されなかった。結果として「AIの出力を信用できないから結局人間が確認する」という運用になり、効率化の恩恵が消えた。

なぜ、すべて失敗したのか

ここで一歩引いて考えると、1990年代から2010年代までのすべての試みに共通する失敗原因が見えてくる。

「人間が情報を完璧に管理することを前提とした設計」——これが根本的な間違いだった。

KMは「人間がベストプラクティスを入力する」ことを前提にした。セマンティック・ウェブは「人間が正確にタグを付ける」ことを前提にした。エンタープライズ検索は「人間が文書を整理する」ことを前提にした。チャットボットは「人間がQAを更新し続ける」ことを前提にした。

どの前提も、現実の業務の中では維持できなかった。

唯一例外として機能したのは、「それをやらないと自分が直接損をする」構造が組み込まれたケースだけだ。コンサルタントの知識データベース、研究者の文献管理システム——これらは継続できた。一般企業の業務部門では、KMへの入力や文書整理は常に「やらなくても直接自分の評価には影響しない作業」として後回しにされ続けた。

インセンティブのない場所に、継続的な行動は生まれない。これは人間の問題ではなく、構造の問題だ。

2020年代：RAGが変えたもの

2020年、Meta AI ResearchのPatrick Lewisらが「Retrieval-Augmented Generation」——検索拡張生成（RAG）——を発表した。

RAGの本質的な革新は、技術の話ではない。 「人間が100点の構造化をする必要がなくなった」という設計思想の転換だ。

RAG以前のすべてのアプローチは、「まず情報を完璧に整理してから活用する」という順序を前提にしていた。RAGはその前提を捨てた。60点の形式知化——きれいに整理されていなくても、タグが完璧でなくても、構造が統一されていなくても——AIが意味的に近い情報を引き出し、それを根拠として回答を生成する。

「60点でいい」という割り切りが、30年間解けなかった問題の構造を変えた。

しかし注意が必要だ。RAGが登場したことで、新しいパターンの失敗が始まっている。

「RAGを導入すれば組織知が活用できます」という提案が、今まさに横行している。PoCを3ヶ月で作り、「動きました」と見せる。しかし本番稼働後、精度が上がらない、回答が信用できない、セキュリティ上の問題が発覚する——30年前のKMブームと、構造が同じ失敗の再演が始まっている。

歴史は繰り返す。技術が変わっても、「なぜ失敗するのか」という根本を理解しないまま導入すれば、結果は変わらない。

「設計判断の根拠」が問われている

RAGは道具だ。正しく使えば、30年間解決できなかった問題に近づける。間違って使えば、また同じ場所に戻る。

道具を正しく使うためには、「なぜその構造なのか」「なぜその設計が崩壊するのか」「誰がどの責任を持つのか」という設計判断の根拠を理解することが先に必要だ。

技術の手順書より先に、この「根拠」を理解することが、30年の失敗の歴史を繰り返さないための唯一の方法だと考えている。

『AIの核心組織知と検索拡張生成理論編：RAGで実現するナレッジマネジメント～なぜその設計か？導入・評価・ガバナンスの判断軸を学ぶ～』は、RAGの技術的な仕組みだけでなく、「なぜ組織への導入が失敗するのか」「どう設計すれば崩壊しないのか」「誰がどのガバナンスを担うのか」という設計判断の根拠を論じた一冊です。エンジニアだけでなく、DX推進担当・PMO・経営幹部・監査担当者を読者として想定しています。