▼ この記事の内容
RAGのチャンクは、AIが参照文書を検索するための情報単位です。サイズや分割方法は固定値で決めず、文書構造、質問粒度、根拠一致率、回答不可制御を評価しながら調整します。社内FAQや規程では、回答根拠が一つの単位で読めるかを先に確認します。
社内ナレッジAIのRAG評価では、既存FAQや問い合わせ履歴から30問程度を選び、根拠一致率・回答不可率・更新鮮度を確認します。チャンク設計は、回答文の自然さよりも正しい根拠を拾えるかを先に見る必要があります。
チャンクサイズだけを調整しても、FAQの質問と回答が分かれたり、古い規程が混ざったりすると回答は安定しません。放置すると、誤回答の原因が分割方法なのかナレッジ運用なのか判断できなくなります。
この記事では、RAGのチャンクの意味、サイズとオーバーラップの考え方、分割方法ごとの向き不向きを整理します。社内ナレッジAIで評価すべき観点までつなげて、導入前に確認すべき論点を明確にします。
読み終えるころには、固定の推奨サイズを探す状態から、自社文書と質問粒度に合わせてチャンク設計を評価する状態へ進めるはずです。 RAGの回答精度を分割だけでなく、ナレッジ整備と運用設計から見直したい方は資料をご確認ください。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
RAGのチャンクとは何か
RAGのチャンクは、AIが参照文書を探し、回答の根拠として扱う情報単位です。分割の仕方は、回答候補、根拠の示しやすさ、誤回答時の確認しやすさに影響します。
チャンクは検索される最小単位である
RAGにおけるチャンクは、文書全体ではなくAIが照合する最小の情報単位です。章、段落、FAQの一問一答などを、回答に使える粒度へ切り出します。
Microsoft LearnのAzure AI Searchに関する解説では、RAGで外部データを検索して生成回答に使う流れを説明しています。チャンクは、その外部データをAIが拾いやすい形へ整える前処理になります。
社内ナレッジAIでは、就業規則の章、FAQの質問と回答、製品マニュアルの手順を別単位で扱います。営業部門なら、提案資料の料金条件と導入手順を混ぜずに分けると根拠を追いやすくなり、AIがどの根拠を見て答えるかも確認しやすくなります。
参考：Retrieval Augmented Generation (RAG) in Azure AI Search｜Microsoft Learn
チャンク分割は回答候補と回答根拠を変える
チャンク分割は、AIが参照する回答候補と、最終回答に付く根拠を変えます。同じ文書でも、切り方が変わると拾われる文脈が変わります。
FAQを質問文と回答文で分けてしまうと、AIは質問だけを拾い、回答根拠を持てない場合があります。反対に、長いマニュアルを章ごと丸ごと渡すと、関係ない条件まで回答に混ざりやすくなります。
情シスやDX推進担当が確認すべき点は、分割後のチャンクを人が読んで根拠として使えるかですが、担当者が根拠を説明できない単位なら、AI回答も業務判断に使いにくくなります。分割は、AIに渡す情報量を減らす作業ではありません。必要な文脈を残しながら、質問に対応する根拠を見つけやすくする作業として扱います。
大きすぎるとノイズが増え、小さすぎると文脈が欠ける
チャンクは大きすぎると関係ない情報を含み、小さすぎると回答に必要な前後関係を失います。固定値ではなく、文書の種類と質問の粒度で調整します。
大きいチャンクは、1つの候補に複数テーマを混ぜやすくなります。料金表、契約条件、導入手順が同じ単位に入ると、AIは質問と関係ない条件まで回答に含めます。
小さいチャンクは、根拠の前後関係を失いやすくなります。規程文書で例外条件だけを切り出すと、対象者、適用範囲、承認者が抜けた回答になります。
チャンク設計で改善できるのは、参照根拠の拾いやすさと文脈の残し方です。RAG全体の仕組みを先に整理したい場合は、RAGの基本とチャンク設計の位置づけも確認すると、次のサイズ調整に進みやすくなります。
営業AI・営業DX RAGとは？仕組み・活用例・導入手順をわかりやすく解説｜社内AI検索の実践法
チャンクサイズとオーバーラップの決め方
チャンクサイズとオーバーラップは、固定の文字数ではなく文書種類、質問粒度、評価結果から決めます。最初は壊してはいけない意味単位で仮決めし、根拠一致率と回答不可率で調整します。
サイズは章・FAQ・表の単位から仮決めする
チャンクサイズは、章、FAQ、表などの意味単位を起点に仮決めします。質問に答える根拠が一つの単位で読める粒度を優先し、固定の文字数だけで決めません。
Microsoft LearnのAzure AI Searchに関する解説では、RAGで外部データを検索し、生成回答の根拠として使う流れが示されています。社内FAQなら質問と回答を一組にし、表では行や列の見出しを切り離さない設計にします。
規程やマニュアルでは、見出し、本文、例外条件を同じ単位に残すかを先に決めます。最初のサイズは仮説でよく、公開前の評価で直す前提にします。次に見るべき点は、前後の文脈をどこまで重ねて残すかです。
参考：Retrieval Augmented Generation (RAG) in Azure AI Search｜Microsoft Learn
オーバーラップは文脈をまたぐ質問に使う
オーバーラップは、前後のチャンクに同じ文脈を一部重ねて残す設計です。手順の前提や例外条件をまたぐ質問では、文脈欠落を減らすために使います。
契約条件の説明で、対象者の定義と例外規定が別々の単位に分かれると、回答は条件を取り違えやすくなります。一方で、重複を増やしすぎると似たチャンクが大量に返り、回答根拠の確認作業も負担が大きくなります。
オーバーラップは、すべての文書に同じ幅で入れるものではありません。FAQでは少なめにし、手順書や規程では前後関係を見て増やします。評価ではサイズと重複を一つずつ調整します。
評価セットで根拠一致率と回答不可率を確認する
チャンク設計は、評価セットで根拠一致率と回答不可率を見て調整します。必要な根拠が返るか、答えられない質問に回答しないかを分けて確認します。
評価セットは、既存FAQや問い合わせ履歴から30問程度を選んで作ります。よくある質問、例外条件を含む質問、文書に答えがない質問を混ぜると、弱点が見えやすくなります。
根拠一致率では、AIの回答ではなく、参照されたチャンクが正しい根拠かを見ます。回答不可率では、文書に答えがない質問へ無理に回答していないかを確認します。分割方法を選ぶ前に、同じ基準で比べます。
分割方法ごとの向き不向き
分割方法は、文書の構造と質問の粒度で使い分けます。固定長、再帰分割、セマンティック分割、構造分割は万能ではなく、評価しやすい条件が異なります。
固定長分割は大量文書の初期処理に向く
固定長分割は、文字数やトークン数で機械的に文書を切る方法です。大量文書をまず処理したい場合に使いやすく、初期検証の速度を上げます。
一方で、意味の切れ目を見ないため、規程の条件やFAQの回答を途中で切る場合があります。営業資料では、課題、解決策、注意点が別チャンクに分かれると根拠が弱くなります。
固定長分割を使う場合は、後から失敗例を見つける前提にします。初期処理で候補を作り、根拠一致率が低い文書から再分割する流れが実務に合います。
再帰分割は見出しや段落構造を残しやすい
再帰分割は、見出し、段落、文などの区切りを順に使って文書を切る方法です。社内マニュアルのように見出しが整っている文書では扱いやすくなります。
見出しが正しく付いていれば、手順や注意事項を同じまとまりに残しやすくなります。営業FAQや業務マニュアルでも、章立てが一定なら初期設定として検討できます。
ただし、元文書の見出し品質に依存します。見出しが古い、階層が崩れている、表だけが貼られている文書では、分割前の整備が実施条件になります。
セマンティック分割は意味のまとまりを優先する
セマンティック分割は、文章の意味の近さを見てチャンクを作る方法です。見出しが弱い文書でも、内容のまとまりを保ちやすい点が特徴です。
問い合わせ履歴や議事録のように、話題が途中で変わる文書では候補になります。文脈の変化を見て切れるため、固定長分割より自然な単位になりやすいです。
実装や計算の負荷は増える場合があります。IBMのRAGチャンク設計に関する解説でも、文書特性に応じた分割戦略の使い分けが示されています。PoCでは、対象文書を絞って固定長分割や再帰分割と比べ、根拠一致率の差を見るのが現実的です。
参考：Chunking｜IBM｜IBM
構造分割はFAQ・規程・マニュアルに向く
構造分割は、FAQの質問と回答、規程の条文、マニュアルの手順などを単位にして切る方法です。壊してはいけない業務単位が明確な文書に向きます。
分割方法の比較では、次の観点で整理すると判断しやすくなります。文書の見た目ではなく、質問に対してどの根拠を返すべきかで選びます。
| 分割方法 | 向く文書 | 向かない文書 | 注意点 | 評価観点 |
|---|---|---|---|---|
| 固定長分割 | 大量の初期投入文書 | 条件や例外が多い規程 | 意味境界を壊しやすいです | 根拠の前後関係 |
| 再帰分割 | 見出しが整ったマニュアル | 階層が崩れた文書 | 元文書の品質に依存します | 見出し単位の一致 |
| セマンティック分割 | 議事録や問い合わせ履歴 | 表中心の文書 | 実装負荷が増える場合があります | 意味のまとまり |
| 構造分割 | FAQ、規程、手順書 | 形式が不統一な文書 | 前処理が必要になりやすいです | 業務単位の保持 |
表で見ると、社内ナレッジAIでは構造分割と再帰分割を軸にしやすいです。次は、分割方法を選んでも起きる失敗を確認します。
チャンク設計で起きる失敗
チャンク設計の失敗は、サイズだけでなく文書構造、情報の鮮度、権限、評価不足から起きます。回答精度を直すには、原因ごとに確認方法と修正方針を分けます。
小さすぎるチャンクは根拠の前後関係を失う
小さすぎるチャンクは、回答に必要な前提と結論を別々に切り離します。RAGが片方だけを拾うと、根拠はあるように見えても判断条件が抜けます。
社内FAQでは、質問文、回答、例外条件、更新日が一体で意味を持ちます。回答文だけを切り出すと、対象部署や適用外の条件を落としたまま回答候補に入ります。
確認方法は、返されたチャンクだけを人が読んで回答できるかを見ることです。そのため、最小単位は文字数ではなく、根拠だけで判断が完結する単位で確認します。
大きすぎるチャンクは関係ない情報を混ぜやすい
大きすぎるチャンクは、質問と関係ない規定やFAQを同じ候補に混ぜます。回答生成時に不要な文が近くにあると、AIが根拠の優先順位を誤ります。
営業マニュアルなら、価格改定の説明と例外承認の手順を同じ塊に入れると危険です。担当者が価格条件だけを聞いた場面でも、承認フローまで混ざって返る場合があります。
修正時は、見出し、目的、対象者、更新責任者が変わる地点で分割します。文脈保持のために大きめに残す場合でも、評価質問で不要情報の混入を確認します。
FAQや表を途中で切ると回答根拠が崩れる
Microsoft Learnのチャンク分割に関する解説でも、表を含む文書では構造を保って分割する考え方が示されています。FAQや表を途中で切る失敗は、回答根拠と条件列の対応を崩します。
失敗は、古い情報、部署別の権限混在、評価不足でも起きます。古いFAQは更新日を持たせ、権限差がある文書は閲覧範囲で分け、返却されたチャンクは評価質問で確認します。
主な失敗は、次の観点で切り分けますが、原因、回答への影響、確認方法、修正方針を同じ表で見れば、サイズ調整だけに原因を寄せずに済みます。インサイトは、FAQや表を守るだけでは足りない点にあります。古い情報、権限混在、評価不足まで点検すると、誤回答の原因をチャンク設計と運用設計に分けられます。
| 失敗パターン | 起きる原因 | 回答への影響 | 確認方法 | 修正方針 |
|---|---|---|---|---|
| 小さすぎるチャンク | 前提と結論を別々に切る | 判断条件が抜ける | 返却チャンクだけで回答できるかを見る | 根拠だけで判断が完結する単位に戻す |
| 大きすぎるチャンク | 質問と関係ない規定やFAQを同じ候補に混ぜる | 不要な条件や例外が回答に混ざる | 返却チャンクに質問と無関係な情報が含まれていないかを見る | 目的、対象者、更新責任者が変わる地点で分割する |
| FAQや表の分断 | FAQや表を途中で切る | 回答根拠と条件列の対応が崩れる | 表の行やFAQの組み合わせが壊れていないか見る | FAQや表の構造を保って分割する |
| 古い情報の混入 | 古いFAQをそのまま使う | 古い情報を根拠にする | 更新日を確認する | 古いFAQは更新日を持たせる |
| 権限混在・評価不足 | 部署別の権限混在、評価不足 | 閲覧範囲外の情報や根拠違いが起きる | 返却されたチャンクを評価質問で確認する | 権限差がある文書は閲覧範囲で分ける |
誤回答の全体像を整理したい場合は、生成AIの根拠違いが起きる原因と対策も合わせて確認できます。チャンク設計で直す範囲と、回答不可制御で抑える範囲を分けて判断します。
営業AI・営業DX 生成AIのハルシネーションとは｜原因・事例と業務利用で防ぐ5つの対策
参考：Chunk large documents for vector search solutions in Azure AI Search｜Microsoft Learn
社内ナレッジAIで評価する手順
社内ナレッジAIのチャンク評価は、既存FAQや問い合わせ履歴から質問を作り、回答根拠の返り方を確認する作業です。回答文の自然さだけでなく、正しい根拠を拾えているかを先に見ます。
既存FAQと問い合わせ履歴から30問程度を選ぶ
評価質問は、既存FAQと問い合わせ履歴から30問程度を選んで作ります。よく聞かれる質問、例外条件を含む質問、答えがない質問を混ぜます。
社内ヘルプデスクなら、休暇、経費、アカウント権限、申請期限などを分けて入れます。営業部門でRAGを使う場合は、提案資料やFAQの参照範囲も変わるため、営業現場でRAGを活用する前提条件も合わせて確認します。
営業AI・営業DX RAGを営業で活用する方法｜効く業務の見極めと失敗しない始め方
実問い合わせを使う場合は、氏名、会社名、個別契約条件を匿名化します。評価質問は多ければよいわけではなく、業務上の判断に直結する質問を優先します。
根拠一致率・回答不可率・更新鮮度で評価する
社内ナレッジAIの評価は、評価質問ごとに根拠一致率、回答不可率、更新鮮度の3つで見ます。正しい文書を拾い、答えられない質問を止め、古い情報を避け、運用品質を確認するためです。
評価項目は、次の3つに分けると原因を切り分けやすくなります。Azure DatabricksのRAG品質評価に関する解説でも、データ品質と評価を分けて確認する考え方が示されています。回答の文章だけを採点せず、参照したチャンクと業務上の判断条件を照合します。
- 根拠一致率: 正解根拠として使うべきチャンクが返っているかを見ます。
- 回答不可率: 文書に答えがない質問へ、無理に回答していないかを見ます。
- 更新鮮度: 最新版のFAQ、規程、手順書を根拠にしているかを見ます。
リストで分けると、チャンクサイズの問題とナレッジ運用の問題を混同しにくくなります。根拠一致率が低ければ分割を見直し、更新鮮度が低ければ文書管理を直します。
参考：RAG アプリケーションの品質データ パイプライン｜Microsoft Learn｜Azure Databricks
自己解決率と有人問い合わせ移管率も補助KPIにする
チャンク評価は、根拠の正しさだけで終わらせません。社内ナレッジAIでは、自己解決率と有人問い合わせ移管率も補助KPIとして見ます。
自己解決率は、利用者が追加問い合わせをせずに目的を終えた割合です。有人問い合わせ移管率は、AI回答だけで扱わず担当者へ渡すべき質問を適切に切り分けた割合です。
精度を説明する場面では、回答候補の一致だけでは業務成果を伝えにくくなります。問い合わせ削減だけを狙うと、判断が必要な質問までAIに抱え込ませるため、移管の質も合わせて確認します。
チャンク調整後も人が確認する運用を残す
チャンクを調整した後も、人が根拠と回答を確認する運用を残します。社内規程、料金条件、契約例外のような領域では、自動回答だけで完結させません。
導入担当者は、調整後の回答ログを定期的に見て、根拠違い、古い情報、回答不可にすべき質問を洗い出します。更新責任者が不在のままでは、最初の評価が良くても精度は維持しにくくなります。
社内説明に必要な評価軸を整理したい段階では、チャンク調整だけで判断せず、運用設計も確認材料に含めます。営業改善プログラム「FAZOM」のサービス全体を確認する入口として、以下の資料を参照できます。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
チャンク設計前に確認すべきこと
RAGのチャンク設計は、分割方法を選ぶ前に参照対象の安全性を固める必要があります。承認済みナレッジ、権限、更新責任者、回答根拠、回答不可制御を先に決めると、調整後の評価がぶれにくくなります。
承認済みナレッジだけを参照対象にする
社内ナレッジAIでは、承認済みナレッジだけをRAGの参照対象にします。未確認のメモや古いFAQを混ぜると、チャンクサイズを調整しても回答根拠が安定しません。
情シスやDX推進担当が最初に見るべき点は、文書の量ではなく承認状態です。営業資料、社内規程、FAQ、問い合わせ履歴を同じ基準で扱うと、未承認情報が回答に混ざります。
社内問い合わせの範囲を整理する場合は、承認済みFAQや問い合わせ導線を先に棚卸しします。関連する社内ヘルプデスクの整理観点も確認すると、参照対象を切り分けやすくなります。
営業AI・営業DX 社内ヘルプデスクとは？業務効率化とAI活用の設計ガイド｜失敗しない運用法
権限と更新責任者をチャンク単位で管理する
権限と更新責任者は、文書単位だけでなくチャンク単位でも管理します。部署限定の規程や価格情報が混ざる場合、検索されたチャンクごとに見せてよい相手を判定する必要があります。
導入前の確認では、次の質問に答えられるかを見ます。答えられない項目が残る場合は、分割方法よりもナレッジ管理の設計を先に見直します。
- 参照対象は承認済みですか
- 閲覧権限を分けられますか
- 更新責任者は決まっていますか
- 回答根拠を表示できますか
- 回答不可を返せますか
- 30問評価セットを作れますか
チェックリストは、RAG導入の可否を決める入口になります。すべてを初回で満たす必要はありませんが、不足項目を残したままチャンク調整だけ進めると評価結果の解釈が難しくなります。
回答不可制御を入れて誤回答を減らす
回答不可制御は、根拠が不足する質問に無理な回答を返さないための設計です。RAGが参照できる情報に該当チャンクがない場合は、推測ではなく回答できない理由を返すほうが運用しやすくなります。
現場では、質問に答えないAIは使いにくいと感じる方も多いです。とはいえ、権限外情報や古い規程を根拠に回答するほうが、後から修正工数と説明責任を増やします。
社内ナレッジAIの運用設計まで整理したい場合は、分割方法だけでなく更新責任と回答不可の扱いも確認します。営業改善プログラム「FAZOM」のサービス全体を確認する材料として、以下の資料を参照できます。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
よくある質問
RAGのチャンクサイズは何文字がよいですか
RAGのチャンクサイズは、固定の文字数で決めません。章、FAQ、表などの意味単位を起点に仮決めし、根拠一致率と回答不可率で調整します。具体的な進め方は組織の現状に応じて調整します。
RAGのオーバーラップとは何ですか
RAGのオーバーラップとは、前後のチャンクに同じ文脈を一部重ねる設計です。手順の前提や例外条件をまたぐ質問で、文脈欠落を減らすために使います。まずは現状の課題を整理することから始めます。
セマンティックチャンクと固定長分割はどう違いますか
固定長分割は文字数やトークン数で機械的に切る方法です。セマンティックチャンクは意味のまとまりを優先するため、議事録や問い合わせ履歴のように話題が途中で変わる文書で候補になります。
まとめ
RAGのチャンク設計は、文書を細かく切る作業ではなく、AIが正しい根拠を検索しやすくする設計です。サイズ、オーバーラップ、分割方法は固定値で決めず、文書構造と質問粒度に合わせて評価します。
社内ナレッジAIでは、承認済みナレッジ、権限、更新責任者、回答根拠、回答不可制御まで確認する必要があります。根拠一致率、回答不可率、更新鮮度を見れば、チャンクの問題と運用の問題を分けて改善しやすくなります。
分割方法だけを調整し続けると、古いFAQや権限外情報が混ざったまま回答精度の原因を見誤ります。担当者は、現場からの誤回答指摘を受けるたびにログを追い、どの文書を直すべきか説明し続けることになります。
RAG改善を社内提案する前に、確認項目を整理したい方は資料をご確認ください。分割設計だけでなく、ナレッジ整備と運用設計を含めて説明しやすくなります。 導入判断の確認項目と具体的な進め方は、以下の資料で詳しく確認できます。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
