はじめに
企業が保有する重要な知識は、業務マニュアルや規程だけに記録されているわけではありません。
現場で起きたトラブルへの対応方法、顧客ごとの注意事項、ベテラン社員が経験から判断している例外処理など、多くの情報は、日報、議事録、社内チャット、メール、個人のメモ、ホワイトボードの書き込みなどに分散しています。
このように、文章として明確に体系化されていない知識を「暗黙知」と呼びます。
生成AIとRAG（Retrieval-Augmented Generation：検索拡張生成）を組み合わせれば、社内に散在する暗黙知を検索可能なナレッジとして活用できます。しかし、PDFや議事録をそのままデータベースへ投入するだけでは、期待した精度は得られません。
元資料でも、社内知識の多くがTeamsやSlack、ホワイトボード、ローカルPCの日報などに散在しており、単純に「テキストの塊」として登録すると、見出しと本文の関係や前提条件が失われることが指摘されています。
RAGの成否を左右するのは、AIモデルの性能だけではありません。
重要なのは、AIが検索しやすく、意味を正しく理解できる形へ、文書をあらかじめ構造化しておくことです。
本記事では、企業の暗黙知をRAGへ統合する際に必要となる、文書構造化、チャンク設計、メタデータ、検索、評価の実務ポイントを解説します。
1．RAGは「資料を読み込ませれば完成」ではない
RAGは、利用者の質問に関連する情報をデータベースから検索し、その情報を生成AIへ渡して回答を作る仕組みです。
一般的には、次の流れで処理されます。
- 社内文書を取り込む
- 文書を一定の単位に分割する
- 分割した文章をベクトル化する
- 質問と意味の近い文章を検索する
- 検索結果を基に生成AIが回答する
この仕組みだけを見ると、社内のPDFやWordファイルをまとめて登録すればよいように感じられます。
しかし、実際の文書には次のような問題があります。
- 見出しと本文が別々に抽出される
- 表の行と列の対応関係が崩れる
- ページをまたいで文章が分断される
- 「この処理」「前述の手順」などの指示語だけが残る
- 古い版と最新版が同時に検索される
- メニューやフッターなど不要な文字が混入する
- 図や画像にしか重要情報が書かれていない
人間には理解できる資料でも、分割された一部分だけを受け取るAIには、意味が通じない場合があります。
したがって、RAG構築では、文書を登録する前の「前処理」が極めて重要です。
2．文書をMarkdownで構造化する
RAG用文書の標準形式として活用しやすいのがMarkdownです。
Markdownでは、見出しを「#」「##」「###」で表現し、箇条書きを「-」で記述できます。
例えば、次のような構造です。
# 出張旅費規程
## 交通費の精算
### 新幹線を利用する場合
- 指定席料金まで精算対象とする
- グリーン車料金は原則として対象外
- 例外申請には部門長の承認が必要この形式にすると、AIは「出張旅費規程の中に、交通費の精算があり、その下に新幹線利用時のルールがある」という階層関係を理解しやすくなります。
元資料でも、Markdownの見出しタグによって親セクションと詳細本文の関係を明示し、箇条書きによって条件や手順を認識させる方法が示されています。
文章は自己完結させる
RAG用の文書では、各段落を単独で読んでも意味が通じるようにします。
例えば、次の文章は適していません。
前述の方法で処理してください。
この文章だけが検索されても、「前述の方法」が何を指しているのか分かりません。
次のように書き換えます。
交通費精算システムで領収書画像を登録し、上長承認を申請してください。
「その処理」「この場合」「上記の方法」などの曖昧な表現を避け、対象となる業務や操作を具体的に書くことが重要です。
3．表や画像をAIが理解できる文章に変換する
RAGが苦手とする代表的なデータが、複雑な表や画面キャプチャです。
例えば、次の表があるとします。
| 製品 | 価格 | 条件 |
|---|---|---|
| 製品A | 100円 | 安価。ただし条件あり |
人間であれば意味を読み取れますが、抽出処理の途中で列の関係が崩れると、AIは正確に理解できません。
そのため、重要な表は次のような文章に変換します。
製品Aの価格は100円です。低価格ですが、利用には所定の条件があります。
操作マニュアルの画像も同様です。
ここをクリックする。
ではなく、
画面右上にある歯車型の設定アイコンをクリックする。
と記載します。
また、現場社員の日報やトラブル対応履歴は、次のようなQ&A形式へ変換すると検索精度を高めやすくなります。
## PCの電源が入らない場合
### 質問
PCの電源ボタンを押しても起動しない場合は、どのように対応しますか。
### 回答
最初に電源ケーブルが本体とコンセントへ接続されているか確認します。
次に、電源タップのスイッチが入っているか確認します。
改善しない場合は、情報システム部門へ連絡します。元資料では、トラブル対応履歴を「事象・原因・対策」やQ&A形式へ変換することで、検索語と回答内容の意味的な距離が近づき、検索精度を向上させられると説明されています。
4．チャンクは文字数だけで分割しない
RAGでは、文書を検索可能な小さな単位へ分割します。この単位を「チャンク」と呼びます。
単純なシステムでは「500文字ごと」といった固定文字数で分割します。しかし、文章の途中で機械的に切ると、質問への回答に必要な前提条件が別のチャンクへ分かれてしまいます。
これを「Lost in the Middle」やコンテキスト喪失と呼びます。
構造認識型チャンク
実務では、文字数よりも文書構造を優先します。
- 見出し単位
- 段落単位
- Q&A単位
- 手順単位
- 表単位
- 規程の条文単位
例えば、「申請条件」と「例外条件」を別々に分けるのではなく、一つの意味のまとまりとして保持します。
オーバーラップを設定する
隣接するチャンクの一部を重複させる方法も有効です。
例えば、400トークンのチャンクに対して、その前後を15～25％程度重複させます。これにより、分割地点付近にある重要な説明が検索から抜け落ちるリスクを減らせます。
親子チャンクを活用する
検索用には短いチャンクが適していますが、回答生成には前後の文脈を含む長い文章が必要です。
そこで有効なのが親子チャンクです。
- 子チャンク：200～300トークン程度で検索する
- 親チャンク：800～1,200トークン程度でAIへ渡す
質問に近い子チャンクを検索し、その子チャンクが所属する親チャンク全体を生成AIへ渡します。
元資料でも、「小さく検索し、大きく回答する」親子チャンク方式により、検索精度と回答の文脈を両立できると整理されています。
5．メタデータで文書の所属と鮮度を管理する
チャンクに分割された文章だけでは、その情報がどの文書に含まれ、誰を対象とし、いつ作成されたものなのか分かりません。
そこで必要になるのがメタデータです。
代表的な項目には、次のものがあります。
| 項目 | 内容 |
|---|---|
| document_id | 文書を識別するID |
| title | 文書タイトル |
| department | 管理部門 |
| category | 規程、FAQ、議事録、日報など |
| target_user | 対象者 |
| created_at | 作成日 |
| updated_at | 更新日 |
| version | 文書の版 |
| confidentiality | 機密区分 |
| approval_status | 承認状態 |
| section_path | 見出し階層 |
| source_url | 元文書の保存場所 |
例えば、同じ「出張」という言葉が含まれていても、営業部門向けの規程と工事部門向けの規程では、適用条件が異なることがあります。
質問者の部署、権限、対象年度などをメタデータで絞り込めば、誤った文書が検索される可能性を低減できます。
さらに、文書タイトルや階層情報をチャンク本文の先頭に付与する「メタデータのプレペンド」も有効です。
文書：2026年度 出張旅費規程
対象：国内全従業員
版：v3.0
階層：第3章 交通費 ＞ 例外事項 ＞ 新幹線グリーン車この情報を本文と一緒にベクトル化することで、AIがチャンクの所属や適用範囲を理解しやすくなります。
元資料では、標準項目と業務固有項目、構造化データと非構造化データ、静的情報と動的情報を分け、メタデータスキーマを設計する必要性が示されています。
6．ベクトル検索だけに依存しない
ベクトル検索は、質問と文章の「意味の近さ」を探すことに優れています。
しかし、次のような情報は見落とす場合があります。
- 製品番号
- 契約番号
- エラーコード
- 法令名
- 固有の略語
- 人名や部署名
- 完全一致が必要な専門用語
そこで、本番環境ではベクトル検索とキーワード検索を組み合わせた「ハイブリッド検索」が有効です。
ベクトル検索
意味が近い文章を検索します。
例：
退職するときに必要な手続きは何ですか。
という質問に対して、「離職時の申請」「退職者のアカウント削除」など、表現の異なる文章も検索できます。
キーワード検索
BM25などを利用し、文字列や単語の一致を重視します。
例：
エラーコードE102
のような完全一致が必要な検索に適しています。
また、「PC」と「パソコン」、「退職」と「離職」など、同じ意味を持つ用語をシノニム辞書へ登録することで、表記揺れによる検索漏れを防止できます。
7．リランキングで検索結果を再評価する
検索エンジンが候補を取得した段階では、検索結果の順番が最適とは限りません。
そこで、上位候補を別のモデルで再評価する「リランキング」を行います。
実務的には、次のような多段階構成が考えられます。
- ベクトル検索とキーワード検索で数百件から候補を抽出
- メタデータで対象年度や部門を絞り込む
- Cross-Encoderで質問と候補文書の関係を再評価
- 業務ルールを適用して最終候補を決定
- 選ばれた情報だけを生成AIへ渡す
Cross-Encoderは高精度ですが、候補すべてに適用すると処理コストと待ち時間が増えます。
そのため、最初の検索で候補を絞り、上位10～20件程度に対して精密な再評価を行う方式が現実的です。
元資料でも、ベクトル検索と全文検索を組み合わせた候補抽出、Cross-Encoderによる精査、メタデータや業務ルールによる最終選定という多段階アーキテクチャが紹介されています。
8．暗黙知は継続的に更新する
暗黙知は、一度登録して終わりではありません。
業務を続ける限り、新しい対応方法、例外処理、顧客からの問い合わせ、制度変更などが発生します。
そのため、次のような更新ループが必要です。
- 日報、議事録、チャットから候補情報を収集する
- AIが事象、原因、対応策を抽出する
- 重複情報や個人情報を除外する
- 業務責任者が内容を確認する
- 承認済み情報だけをナレッジへ登録する
- 古い情報を更新・廃止する
AIによる自動抽出だけに任せるのではなく、部門責任者や業務担当者による承認工程を設けることが重要です。
特に、規程、法務、財務、品質管理、安全管理など、誤回答の影響が大きい領域では、情報の出典と承認状態を必ず管理しなければなりません。
9．回答精度だけでなく、業務成果を評価する
RAGの評価では、質問への正答率だけを確認しても十分ではありません。
実際の業務では、次のような指標も必要です。
- 必要な情報が検索結果に含まれているか
- 根拠のない回答をしていないか
- 最新版の文書を参照しているか
- 回答の出典を提示できているか
- 利用者の問題が解決したか
- 問い合わせ対応時間が短縮したか
- 同じ質問の再問い合わせが減ったか
- 担当者による回答品質の差が縮小したか
また、生成AIの出力形式も管理する必要があります。
例えば、問い合わせ管理システムへ連携する場合は、自由な文章ではなく、次のような項目で出力させます。
{
"answer": "回答本文",
"source": "参照文書",
"department": "管理部",
"confidence": 0.92,
"requires_human_review": false
}元資料では、セッション成功率、一貫性、会話トーンなどを継続的に監視し、回答内容だけでなく出力形式もシステム側で制御する必要性が指摘されています。
10．中小企業が取り組む場合の進め方
最初から全社の文書を対象にすると、文書整理だけでプロジェクトが停滞します。
まずは、問い合わせ件数が多く、回答ルールがある程度決まっている業務から始めます。
対象例としては、次のような分野があります。
- 社内IT問い合わせ
- 経費精算
- 出張申請
- 人事・労務手続き
- 製品トラブル対応
- 顧客からのよくある質問
- 製造現場の不具合対応
- 営業担当者向け商品情報
導入初期には、次の範囲でPoCを行うと進めやすくなります。
- 対象業務：1業務
- 文書数：50～200件
- 想定質問：30～100問
- 利用者：5～10名
- 評価期間：1～2か月
この段階で確認すべきなのは、生成AIが自然な文章を返すかどうかだけではありません。
「必要な情報を検索できているか」「検索できない原因が文書構造、チャンク、メタデータのどこにあるか」を分析し、改善を重ねることが重要です。
まとめ
企業の暗黙知をRAGで活用するためには、PDFや議事録をそのまま読み込ませるだけでは不十分です。
重要なポイントは次のとおりです。
- Markdownで文書の階層を明確にする
- 各段落を単独でも意味が通る文章にする
- 表や画像を文章やQ&A形式へ変換する
- 文字数ではなく意味のまとまりでチャンクを分割する
- 親子チャンクで検索精度と文脈を両立する
- メタデータで所属、対象、版、鮮度を管理する
- ベクトル検索とキーワード検索を組み合わせる
- リランキングで検索結果を再評価する
- 承認を含む継続的な更新ループを設ける
- 回答精度だけでなく業務成果を測定する
RAGの価値は、生成AIに回答させることだけではありません。
属人化していた判断や対応方法を整理し、必要な人が必要なときに利用できる「組織の知識基盤」へ変えることにあります。
暗黙知の整理と文書構造化は、AI導入の前処理ではなく、企業の業務標準化、人材育成、事業継続を支える重要な経営基盤といえるでしょう。
コメント