社内に「知っているAI」を作れるか
ChatGPTに自社の規程を聞いても、まともな答えは返ってこない。当然だ。そのAIは自社のことを何も知らない。
「汎用AIと社内知識をつなぐ」という課題を解決するために生まれた技術がRAG（検索拡張生成）だ。ここ1〜2年で急速に注目を集め、大企業のシステム部門だけでなく、中小企業のDX担当者も名前を聞く機会が増えてきた。
ただし、RAGを入れれば解決する、という話ではない。
私たちLat91は複数の企業のAI導入を支援してきたが、「RAGを入れたのに機能しない」という声の方が「うまくいった」という声よりも多い。その理由を突き詰めると、問題はAI技術にあるのではなく、企業の情報管理の構造にある。本稿では、RAGの仕組みから始まり、導入で詰まる会社の共通パターンと、機能させるための条件を整理する。
RAGとは何か：「知っているAI」を作る仕組み
RAGは Retrieval-Augmented Generation（検索拡張生成） の略だ。名前だけ聞くと難解に聞こえるが、やっていることはシンプルだ。
LLM（大規模言語モデル）は、学習時点までの情報しか知らない。ChatGPTに「うちの就業規則の残業申請フローは？」と聞いても答えられない。自社のデータを学習していないからだ。かといって、自社データ全体でLLMを再学習（Fine-tuning）するのは、コストも時間もかかりすぎる。
RAGはこの問題を別のアプローチで解く。LLM自体は変えず、「質問に関連する社内文書を先に検索して、その内容をLLMへの入力に追加する」という仕組みだ。
処理の流れはこうなる。
- 検索（Retrieval）：ユーザーの質問を受け取り、社内ドキュメントの中から関連する箇所を検索する
- 拡張（Augmented）：質問と検索した文書の断片を組み合わせて、LLMへの入力プロンプトを生成する
- 生成（Generation）：LLMが、社内文書の内容を踏まえた回答を生成する
この仕組みにより、LLMは「自社の規程に書いてある通り、残業申請は翌営業日の午前中までに上長承認が必要です」という、固有の情報に基づいた回答ができるようになる。
図1: RAGの処理フロー。検索→拡張→生成の3ステップ
Fine-tuning（追加学習）との違いを簡単に整理しておく。Fine-tuningはLLM自体を自社データで再学習させる手法で、モデルの重みを変える。一方RAGはモデルを変えない。代わりに「毎回、最新の社内文書を参照させる」アプローチだ。これにより、情報の鮮度維持が容易になる。社内規程が改定されたら、ドキュメントを差し替えれば済む。Fine-tuningの場合、改定のたびに再学習が必要になる。
なぜ今、企業AIの中核技術になったのか
RAGが急速に採用されている理由は、コスト・鮮度・制御性の三点でFine-tuningより優れているからだ。
Fine-tuningはGPT-4クラスのモデルで数十万円から数百万円のコストがかかる。それに対してRAGの構築コストは、ベクターデータベースの選定と埋め込みモデルのAPI費用が主で、規模にもよるが数万円台から始められるケースも多い。
実際の用途として定着しているのは以下のようなものだ。
- 社内QAボット：就業規則・経費精算ルール・IT問い合わせ対応
- マニュアル検索：工場の操作手順書や保守ガイドへの自然言語質問
- 契約書レビュー支援：過去の契約書パターンと照合して条項の確認
- カスタマーサポート補助：製品FAQや過去の問い合わせ履歴を参照した回答案生成
海外での先行事例として参照されることが多いのが、金融大手のMorgan Stanleyだ。同社は約10万点の社内調査レポートやFAQをRAGでインデックス化し、ファイナンシャルアドバイザーが自然言語で社内知識を検索できる社内ツールを展開した。2023年のOpenAIとの協業として発表されたこの事例では、ドキュメント検索にかかる時間を大幅に短縮し、アドバイザーが顧客対応に集中できる時間を増やしたと報告されている。
もう一つ注目すべきは、Shopifyのサポートチームの事例だ。商品数が膨大で常に情報が更新されるECプラットフォームにおいて、Fine-tuningではドキュメントの鮮度維持が困難だった。RAGに切り替えることで、サポートエージェントが参照する情報を常に最新状態に保てるようになり、回答精度を維持しながら運用コストを抑えることに成功している。
RAGが機能しない会社の共通点
ここが本稿の核心だ。
「RAGを導入したが使われない」「精度が低くて実用にならない」という状況に陥った組織を見ると、問題の所在がほぼ一致している。ベクターデータベースの選定でもなく、埋め込みモデルの性能でもなく、インデックスに入れたドキュメントの品質だ。
エンジニアの世界に「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」という原則がある。RAGはこの原則がほぼそのまま当てはまる。
失敗パターン1：非構造化・重複だらけのドキュメント
社内ファイルサーバーやSharePointに蓄積されたドキュメントをそのままRAGに突っ込むと、ほぼ確実に精度が落ちる。3年前に作成されたまま更新されていないExcel、バージョン管理されていない複数の規程ファイル、同じ内容が別の言い回しで複数のWordファイルに存在する、といった状態だ。
RAGは検索した文書を「正しい情報」として回答に組み込む。古い情報や矛盾した情報がインデックスに入っていれば、AIは自信満々に誤った答えを出す。
失敗パターン2：「誰が何を知っているか」の不透明さ
組織の重要な知識が、個人のメールや非公式チャットに眠っていることは珍しくない。「あの件はAさんが詳しい」という暗黙知の状態では、RAGでインデックス化する以前に、そもそも情報がどこにもない。
RAGは「存在するドキュメント」しか答えられない。存在しない知識は生成も検索もできない。
失敗パターン3：更新体制が存在しない
最初にドキュメントを整備してRAGを構築した後、誰もメンテナンスしない——これが最も多い失敗パターンだ。ドキュメントは作った瞬間から陳腐化が始まる。半年後には「RAGが出す答えは信用できない」という評判が組織に広まり、誰も使わなくなる。
失敗パターン4：権限管理と情報公開範囲の問題
「人事評価の基準が社員全員にRAGで検索できてしまう」「営業の顧客情報が他部門に漏れる」といった問題は、導入前には見落とされやすい。後から権限管理を後付けで実装しようとすると、RAGのアーキテクチャ全体の再設計が必要になることもある。
図2: 機能するRAGと機能しないRAGの違いは技術よりも情報管理にある
これら4つの失敗パターンに共通するのは、どれもベクターDBやLLMの問題ではなく、組織の情報管理の問題だという点だ。RAGは社内知識を検索可能にする技術だが、「検索可能にする価値のある知識」がなければ何も返せない。
RAGを社内で機能させるための3つの条件
技術的な実装の前に、この3つを整えていない企業でRAGがうまく機能した事例を私たちは見たことがない。
条件1：回答できる知識を「引ける形」にする
ドキュメントのインデックス化には、まず「何に答えるRAGなのか」を絞り込む必要がある。全社のドキュメントを全部入れることから始めるのは失敗への近道だ。
最初のスコープは狭く設定する。「新入社員のよくある質問30件に答える」「特定製品のサポートFAQ対応」など、回答すべき問いと対応する知識の範囲が明確なものから始める。その範囲のドキュメントを徹底的に整備する。重複削除、最終更新日の明記、担当者の明示、この3点は最低限だ。
条件2：検索精度のチューニングに時間をかける
RAGの精度は、ベクトル検索のチューニングに大きく左右される。「チャンクサイズ」（ドキュメントを何文字単位で分割するか）と「ハイブリッド検索」（意味検索と全文検索の組み合わせ）の設計が特に重要だ。
チャンクサイズが大きすぎると、無関係な情報が回答に混入する。小さすぎると、文脈が切れて意味の通らない断片が返ってくる。500〜1000文字前後を基準に、実際の質問パターンで精度を確認しながら調整する。この作業に「1週間で終わる」という期待は捨てた方がいい。質問のバリエーションと実際の回答品質を地道にチェックするプロセスが必要だ。
条件3：更新体制を組み込んでから運用を始める
「とりあえず動くものを作ってから考える」が最も危険なアプローチだ。ドキュメントのオーナーを誰にするか、更新頻度と手順はどうするか、品質チェックは誰がいつやるかを、システム構築と並行して決める。
実用的なやり方として、特定のドキュメントを変更したら自動でRAGのインデックスを再構築するパイプラインを最初から用意しておくと、更新のハードルが大きく下がる。Google DriveやConfluenceからの自動同期を仕組みとして組み込んでいる企業では、更新が習慣化しやすい傾向がある。
月曜日から試せる具体的なステップ
導入を検討している方に向けて、来週すぐに始められる3ステップを示す。
- スコープを1テーマに絞る：「社内QAで最も多い質問は何か」をSlackやメールの過去データから10〜20件抽出する
- 対応ドキュメントを棚卸しする：その質問に答えるドキュメントがどこにあるか、最終更新日はいつか、担当者は誰かを一覧化する
- パイロット環境をNotionやConfluenceで構築する：本格的なベクターDBの前に、まず整理されたドキュメントを一箇所に集めて、ChatGPTのカスタムGPTやClaude.aiのプロジェクト機能で試す。これで「ドキュメントの整備レベルが回答品質にどう影響するか」を実感できる
このステップを踏むと、ほぼ必ずドキュメントの品質問題に気付く。技術的な実装を始める前にそれを発見できれば、後の失敗を大幅に減らせる。
よくある誤解と反論
「RAGは難しくて中小企業には無理では」
この懸念は半分正しく、半分は誤解だ。
確かに、自前でベクターデータベースを構築・運用するにはエンジニアリングの知識が必要だ。ただし、今は「RAGをSaaSで提供する」サービスが急増している。Notionのチームスペースにドキュメントを整備するだけでRAG的な社内検索を構築できるサービスや、Confluenceと連携するAIアシスタントなど、エンジニアなしで試せる選択肢が増えた。
「エンジニアがいないと無理」という状況は、2023年から2024年にかけて大きく変わった。ただし前述の通り、どのツールを使うにしてもドキュメント整備の問題は回避できない。ここは中小企業だろうが大企業だろうが変わらない。
「ChatGPTにPDFを投げれば同じでは」
短期間の一時的な使用なら、実質的に同じことができる場合もある。ChatGPTのドキュメント読み込み機能や、ClaudeのプロジェクトへのPDFアップロードは、小規模なRAGの代替として機能する。
ただし、この方法は以下の状況でスケールしない。
- ドキュメントが100件を超える場合（コンテキストウィンドウの限界）
- 複数人が同時に利用する場合（コスト・レート制限）
- 自動的に最新ドキュメントを参照させたい場合
- 回答の根拠（どのドキュメントの何ページから引用したか）を記録したい場合
「試してみる」フェーズには十分だが、「組織の仕組みとして定着させる」フェーズには専用のRAGアーキテクチャが必要になる。
まとめ：技術の前に情報設計
RAGの本質は検索技術ではなく、企業の知識を「誰でも引けるインデックス」に変える情報設計だ。
ベクターデータベースを導入しても、入れるドキュメントが古くて重複だらけなら、出てくる答えも古くて信頼できない。更新体制がなければ、半年後には「使えないシステム」に変わる。権限設計がなければ、情報漏洩リスクを内包したまま運用することになる。
これらはすべて、RAGという技術の問題ではない。企業が長年向き合ってきた情報管理の問題だ。RAGを入れることで、それらの問題が可視化されるだけだ。
Lat91では、RAGの技術実装と並行して、クライアントの社内ドキュメント整備を支援しながら導入を進めてきた。その経験から言えるのは、「ドキュメント整備に投資した企業ほど、RAGの効果が出るのが早い」という事実だ。技術への投資とドキュメントへの投資を同時に行う覚悟が、RAG導入成功の分岐点になる。
社内AIに関心があり、自社の知識活用を強化したいと考えているなら、まず社内ドキュメントの現状を棚卸しすることから始めることをお勧めします。その棚卸し作業について、私たちに相談いただくことも可能です。