社内文書をAIの知識に変えるには？MarkdownからRAGまで

社内文書を使って回答するチャットボットを作ることになったとします。最初の打ち合わせでは、ベクトルデータベースやモデルから決めたくなるかもしれません。けれど、先に決めたいのは、どんな質問にどの文書を根拠として答えるかです。RAGは、モデルが社内の知識をすでに知っていると想定するのではなく、質問に合う資料を探して回答の文脈として渡す仕組みです。検索がうまくいかなかったり文書が古くなったりすれば、回答も不安定になります。

この記事は企業向けRAGシリーズの第1回です。Markdownで知識を整理し、ツールを選ぶときの基準を扱います。続く第2回ではパース・チャンク分割・ハイブリッド検索を設計し、第3回ではアクセス権限とエージェントのメモリーを見ていきます。

RAGが知識を探して回答につなげる仕組み

言語モデルだけに社内規程や製品文書について尋ねても、学習時になかった情報や非公開情報に正確に答えるのは困難です。RAGは質問に関連する文書の一部を検索し、モデルに一緒に渡します。回答に出典を付けて、担当者が原文を確認できるようにすれば、内容を検討しやすくなります。ただし、RAGが幻覚をなくしたり、文書の正しさを保証したりするわけではありません。検索された根拠が誤っていたり、質問と合わなかったりすれば、その限界は回答にも表れます。

ファインチューニングは、例を使ってモデルの重みを調整し、特定の作業や応答のパターンを学習させる方法です。RAGは外部資料を回答時に根拠として検索し、モデルに渡します。新しい事実を反映したい場合はRAGが扱いやすく、繰り返し使う作業形式や表現を覚えさせたい場合はファインチューニングを検討できます。目的に応じて両方を組み合わせることもできます。どちらもデータの品質や検証に取って代わるものではありません。

最初の目標は「社内のあらゆる文書に答えるAI」でなくてもかまいません。たとえば、最新の方針を見つけにくいという課題を選び、関連する方針文書と実際の質問をいくつか集めて、回答に根拠へのリンクが必要かを決めてみましょう。よく寄せられる質問、正解を確認する担当者、誤答した場合の影響も書き出すと、試行の範囲が具体的になります。

Markdownで文書の原本を管理する

Markdownは、見出しやリスト、表などの構造をプレーンテキストで表現します。ファイルを開けば内容を確認しやすく、Gitで変更履歴を残したり、別のツールに移したりするのも比較的簡単です。シンプルなチームWikiや文書の原本を整える段階では、有用な選択肢です。Obsidianのようなエディターで文書同士をリンクし、Gitで変更履歴を管理するところから始める方法もあります。エージェントに要約や新しい文書を書かせる場合は、正式な原本と自動生成した内容を区別し、確認してから反映する流れを用意しましょう。

ただし、Markdownならパースが不要というわけではありません。RAGシステムはファイルを読み込んで構造を解釈し、検索できる単位に分け、見出し・出典・日付などの情報を付けてインデックス化します。見出しの構造が崩れていたり、表が複雑だったりすれば、プレーンテキストでも検索に向かないことがあります。検索結果で文書がどのように分割されたかを直接確認する作業は引き続き必要です。

原本ファイルを知識の基準にするのか、RAG製品内で編集した内容を基準にするのかも決めておきましょう。複数の保存先から文書を取り込むなら、原本がどこにあるか、変更や削除がいつ検索インデックスに反映されるか、失敗を誰が検知するかを定めます。同期間隔や権限の取り消しが反映されるタイミングは、製品の設定やコネクターによって異なります。「接続した」だけで最新状態や削除の反映が保証されるわけではありません。

同期では、原本の一意な文書IDとバージョン、各チャンクが属する文書の情報を残しておくとよいでしょう。Webhookや変更分のポーリングで更新を検知し、新しいバージョンのチャンクが準備できたら検索対象を切り替えます。原本が削除されたり権限が取り消されたりした場合は、まず検索対象から除外し、関連するインデックスやキャッシュを整理します。失敗した処理の再試行と定期的な照合もあれば、反映漏れを見つけやすくなります。

切り替え時期は人数より運用要件で決まる

チームの人数だけで、アーキテクチャを切り替える時期を決めるのは難しいものです。代わりに、同時編集が多いか、原本の保存先が増えているか、フォルダーごとの権限変更を検索にも反映する必要があるか、削除済みの文書をいつ検索結果から消すべきかを見てみましょう。監査記録や障害対応が必要になったときも、運用方法を見直すサインです。

MarkdownファイルをGitで管理すれば変更履歴は明確になりますが、ユーザーがファイルを読めるかを判断する権限管理や、さまざまなシステムとの同期まで自動で解決するわけではありません。ファイル中心の運用からサービスへ移るときは、ユーザー認証、権限変更の反映、検索履歴、文書の削除、バックアップと復旧も一緒に設計する必要があります。

ツールの主な機能と配布条件を比べる

RAGFlowは、文書のパースやチャンク分割、ナレッジ検索を構成し、回答の根拠を扱うRAGエンジンに重点を置いています。スキャン文書や複雑なレイアウトを含む場合は、実際に保有する文書でパース結果を確かめるとよいでしょう。Difyは、ナレッジ検索をアプリのワークフローに組み込み、ほかのステップやツール呼び出しとつなぐことを重視しています。

AnythingLLMは、ワークスペースやユーザーのアクセスを含む、文書ベースのチャット環境を提供します。Open WebUIはチャット画面とナレッジベース機能を備え、知識へのアクセス範囲を設定できます。MaxKBは、文書やウェブサイトを知識として接続するアプリ構築の流れを提供します。機能はバージョンや導入形態によって異なるため、ここでの説明は製品の順位や適合性の保証ではなく、試行候補を選ぶ出発点として活用してください。

「オープンソース」という言葉だけではライセンスはわかりません。2026年10月に確認した各リポジトリでは、RAGFlowはApache-2.0、AnythingLLMはMIT、MaxKBはGPLv3と表示されています。Difyは追加条件を含む修正Apacheライセンスを採用しています。Open WebUIにはバージョンによってブランド表示に関する条件があります。配布や改変したソフトウェアの提供を始める前に、使うバージョンと含まれるコンポーネントのライセンスを確認してください。マネージドAPIやホスティングサービスは、セルフホストするソフトウェアとは契約、費用、データ処理の条件が異なる場合があります。

小さな試行で同期と削除まで確かめる

ツールを試すときは、「回答がもっともらしいか」だけを見ないようにしましょう。実際の質問を集め、根拠となる文書が検索されるか、回答に出典が示されるか、権限のない文書が表示されないかを確かめます。古い文書と最新の改訂版をあえて一緒に置き、どちらが選ばれるかも見てみましょう。同期の失敗や文書の削除が運用画面やログでどう見えるかを確認すれば、導入後の負担を見積もりやすくなります。

基準にするのは、ツールの機能一覧より、社内の文書や質問で実際に動くかどうかです。シリーズの次回は、文書を検索できる単位に分け、韓国語の質問に合わせて検索結果を評価する方法を紹介します。権限とユーザーごとの記憶については最終回で取り上げます。