社内ナレッジAIの精度を上げる作り方｜RAGチャットボットの限界とナレッジグラフエージェント設計

「社内資料を読ませたAIを入れたのに、精度が出ない」。よくある詰まり方です。原因はモデルの性能ではなく、AIに社内ナレッジを参照させる設計にあります。

そして今、その設計の前提が変わりつつあります。質問に似た文書を1回だけ探して答える単純なRAGチャットボットでは、実際の社内ドキュメントの複雑さに精度が追いつかないからです。規程は別の規程を参照し、例外や細則が絡み、部署や承認や期日と結びついている。こうした関係の絡んだ問いに、1回の類似検索は答えられません。

この記事は、精度が業務で通用する社内ナレッジAIの作り方を、ナレッジグラフエージェントを前提に解説します。データ準備から多経路検索、自己チェック、改善ループまで実装者向けに見ていきます。単純なRAGで足りるケースの見極めも最後に示します。

なぜ単純なRAGチャットボットでは精度が頭打ちになるのか

RAG（質問に似た文書を探してLLMに読ませる方式）は、背景や手順を説明させるのは得意です。ところが、次のような問いには構造的に弱い。

• 関係をたどる問い：「この規程は、どの規程の例外にあたる?」。参照や例外のつながりを、似た文章の検索では追えない。
• 数える問い：「未承認のまま残っている申請は?」。個別の文書は引けても、全体を数えて集計するのは苦手。
• 抜けを見つける問い：「承認記録が結びついていない発注は?」。存在しない状態は検索できない。
• 根拠を示す問い：「なぜこの回答なのか」を、たどった経路として残せない。

実際の社内文書は構造が複雑で、これらの問いが日常的に混ざります。だから、単一のベクトル検索だけに頼ったチャットボットは、簡単なFAQ以上を任せた瞬間に精度が崩れます。RAGとGraphRAGの違いはGraphRAGとは？ベクトルRAGとの違いと、根拠付き回答を実現する実装で、AIが実務で間違える4つの壁はAIエージェントの機能を実務レベルに上げる方法で整理しています。

前提を変える：ナレッジグラフエージェントで組む

ナレッジグラフエージェントとは、持続記憶を「関係の形（ナレッジグラフ）」で持ち、そこを検索と事実確認のよりどころにしながら、自分で段取りを組んで動くAIです。社内ナレッジに当てると、規程・部署・承認・製品・不具合といった要素の関係をたどって、点ではなく全体像で答えられます。何段先まで聞かれても関係を正確に追えるので、複雑な社内文書ほど効きます。

ただし「グラフを足せば賢くなる」わけではありません。精度は、次の4つをきちんと組めるかで決まります。データ準備、多経路の検索、事実での自己チェック、そして改善ループです。順に見ていきます。設計思想は機能アップの5つの勘所に、発注者にとっての損得はナレッジグラフは発注者に何の得があるかにまとめています。

1. 精度の大半はデータ準備で決まる

モデルの性能より、ナレッジベースに入れるデータの品質が回答精度を左右します。関係の形（グラフ）を作るにも、まず良質なテキストが要ります。

取り込むデータの種類と前処理

チャンク分割と関係の抽出

長い文書をそのままベクトル化すると検索精度が落ちるため、適切なサイズに分割します。ナレッジグラフエージェントでは、これに加えて文書から「もの」と「つながり」を取り出してグラフに落とす工程が入ります。

• 段落・セクション単位で分割：文の途中で切れないよう、見出しや改行を基準に分ける。
• オーバーラップを持たせる：前後のチャンクと一部を重複させ、文脈の断絶を防ぐ。
• メタデータを付与：各チャンクに「どの文書の何章か」「最終更新日」「機密度」を付ける。
• エンティティと関係を抽出：本文から規程・部署・製品・不具合などの要素と、その参照や例外のつながりを取り出し、グラフのノードとエッジにする。ここの精度がそのまま回答精度に響く。

チャンクサイズの目安は200〜500トークン（日本語で300〜700文字程度）です。抽出工程の限界と、人手で埋める工程はGraphRAGの精度はデータ抽出で決まるで詳しく扱っています。

2. 検索を多経路にする（単一のベクトル検索をやめる）

単一のベクトル検索から、複数の経路を同時に走らせて統合する設計へ切り替えます。それぞれ得意な問いが違うため、組み合わせると穴が減ります。

ハイブリッド検索

ベクトル検索（意味的な類似度）と全文検索（キーワード一致）を組み合わせます。「年次有給休暇」で検索したとき、ベクトル検索は休暇制度全般を拾い、全文検索は「年次有給休暇」を正確に含む文書を拾う。意味の柔軟性とキーワードの正確性を両立できます。

グラフ近傍の探索

ナレッジグラフ上で、質問に関わるノードから関係をたどって周辺を集めます。「規程A、参照、規程B、例外規定、細則C」のように複数文書をまたぐ問いに、正確に答えられるようになります。ベクトル検索が苦手な「関係をたどる問い」を、この経路が補います。

リランキング

検索で上位に来た候補を、別のモデルで再評価して順位を調整します。最初に20件取得し、リランカーで上位5件に絞ると、AIに渡す情報の質が上がります。

クエリ拡張

ユーザーの質問を検索に適した形へ変換します。「有給って何日あるの?」を「年次有給休暇 付与日数 規程」に補う、といった具合です。この変換自体もLLMに行わせられます。

これらを個別に返すのではなく、RRF（Reciprocal Rank Fusion）のような方法で1つの順位に統合すると安定します。複数経路の統合で回答精度を業務レベルに引き上げる方法は生成AIの回答精度を業務レベルに引き上げる方法で解説しています。

3. 事実で自己チェックさせる（ハルシネーション対策）

検索結果をもとにLLMが回答を作る段では、確かな事実と突き合わせる仕組みを組み込みます。プロンプトで縛るだけでなく、回答後の検証まで入れるのが、業務に耐えるかどうかの分かれ目です。

• 回答は検索結果のみに基づく：「参考資料に書かれている内容のみで回答し、記載がなければ『この質問に関する情報は見つかりませんでした』と答える」よう指示する。
• 根拠の明示：参照した資料名とセクションを必ず添えさせる。利用者が裏取りでき、監査にも耐える。
• 略語・固有名詞は推測しない：正式名称は参考資料に明示されている場合のみ記載させ、推測での補完を禁じる。
• 回答後の突き合わせ：生成した回答を、引用元のチャンクやグラフの事実と照合して検証する（Evidence Verification）。食い違えば回答を差し戻す。

4. 使うほど賢くする：評価と書き戻しのループ

チャットボットは作って終わりではありません。精度を測り、改善するサイクルが要ります。ナレッジグラフエージェントでは、新しく分かった関係を記憶に書き戻すことで、使うほど賢くなります。

• 評価データセットの構築：実際の業務で出る質問を50〜100件集め、正解を人が用意して、定期的に精度を計測する。
• ユーザーフィードバックの収集：「役に立った・立たなかった」のボタンを置き、立たなかった回答を分析してナレッジやプロンプトの改善に回す。
• ナレッジの定期更新：社内文書が更新されたらナレッジベースとグラフも更新する。手動は漏れやすいので、可能なら自動同期を組む。
• 発見の書き戻し：調査で判明した新しい関係（この不具合はこの部品が原因、など）を記憶に足す。次から同じ調査を繰り返さずに済む。

どこまでやるか：単純なRAGで十分なケース

すべてをグラフにする必要はありません。1問1答のFAQのように、関係が絡まず単発の文書検索で完結する用途なら、単純なRAGで安く早く済みます。関係をたどる・数える・抜けを探す・根拠を示す、が業務に含まれるときに、ナレッジグラフエージェントの前提が効いてきます。判断軸は「誤答したときのコスト」です。社内AIが定着する条件は社内AIアシスタント導入の成功と失敗パターンも参考にしてください。

Beekleの対応

Beekleは、社内ナレッジAIを単純なRAGチャットボットではなく、精度を優先したナレッジグラフエージェントとして構築しています。あるカスタマーサポート向けの案件では、メタデータ・全文・ベクトル・グラフ近傍・主張（Claim）の複数経路をRRFで統合し、回答後に引用元と突き合わせて検証する構成にしました。ナレッジグラフにはNeo4jを使い、フロント（Laravel＋React）・AIエンジン（Python・FastAPI）・インフラ（Traefik・PostgreSQL・Redis）まで一貫して構築し、実際のデータを追加しながら自社サーバー上で運用しています。扱うデータ量では通常のベクトル検索だけでは精度に限界があったため、この構成を選びました。

まず小さく試して判断したい方は、初期費用0円のゼロスタート（PoC開発・MVP開発）からご相談ください。PDF資料や動画文字起こしの取り込み、グラフ化、インフラ構築まで一気通貫で対応します。

よくある質問（FAQ）

Q. 普通のRAGチャットボットではダメなのですか？

A. 用途しだいです。1問1答のFAQのように関係が絡まない用途なら、単純なRAGで十分です。ただし実際の社内文書は、規程どうしの参照や例外、部署や承認との結びつきが複雑に絡むことが多く、その場合は1回の類似検索では精度が頭打ちになります。関係をたどる問いが混ざるなら、ナレッジグラフエージェントを前提に設計するほうが確実です。

Q. 社内の資料が数百件ありますが、すべて取り込む必要がありますか？

A. 最初は対象業務に関連する資料だけで十分です。問い合わせの多い業務のマニュアル・FAQ・規程から始め、利用状況を見ながら段階的に広げるほうが効率的です。

Q. 動画の文字起こしデータはそのまま使えますか？

A. そのままでは精度が落ちます。話し言葉の冗長さの除去、固有名詞の修正、トピックごとのセクション分割が必要です。特に「スライドの図を参照しながら説明している箇所」は、図の内容をテキストで補う前処理が効きます。

Q. 社内データをグラフ化すると、外部に漏れませんか？

A. 設計しだいで防げます。データを外部に出さないクローズドな構成（自社サーバーやVPS内で完結させる）にし、誰がどの情報にアクセスできるかを関係の形で制御すれば、社外送信も権限外の閲覧も抑えられます。情シス目線の確認ポイントは社内文書を生成AI・RAGで扱う情報漏洩リスクと対策で整理しています。

Q. 「情報が見つかりませんでした」が多い場合はどうすればよいですか？

A. 原因は「ナレッジにデータが不足している」か「検索が質問にマッチしていない」のどちらかです。その質問に答えるデータが存在するか確認し、あれば検索パラメータやグラフの関係を調整、なければデータを追加、という手順で改善します。

Q. 構築費用はどのくらいかかりますか？

A. スコープによります。PoCレベル（1業務領域、数十件の文書）であれば200万円から300万円程度、本番化（UI整備、セキュリティ対策、運用設計）まで含めると400万円から800万円程度が目安です（要件に左右されます）。詳しくは生成AI開発の費用相場を参考にしてください。