チャンク分割の設定を発注者自身が決める必要はありますか？

いいえ、チャンクサイズなどの数値そのものを発注者が決める必要はなく、数値の選定はベンダーに委ねて問題ありません。発注者が握るべきは、評価用の質問セットを誰が用意し、何を指標に計測するかという「決め方」の合意です。

「チャンク設計の見直し」という追加見積が出た場合、まず何を確認すればよいですか？

改善見込みが指標と目標値で示されているか、変更前後を同じ質問セットで比較する検証が作業範囲に含まれているか、再登録の費用・停止時間が見積に反映されているかの3点を確認してください。いずれか欠けていれば補ってもらうよう依頼すれば十分です。

4つの分割手法のうち、どれが最も精度が高いのですか？

いいえ、4つの手法に優劣はありません。固定長・オーバーラップ・構造ベース・セマンティックは対象文書の性質によって向き不向きが変わるため、提案書を見る際は手法名よりも、自社の文書特性を踏まえて選ばれているかどうかを判断基準にしてください。

512トークンなどの推奨数値をそのまま自社文書に適用してよいですか？

そのまま適用するのは避けてください。512トークンなどの推奨値は英語文書のベンチマークに由来する初期値にすぎず、日本語はトークン化の特性や単語区切りの違いがあるため、自社文書での検証結果に置き換えて判断する必要があります。

PDF文書のRAG化で工数が膨らみやすいのはなぜですか？

PDFは紙面の見た目を保存する形式で文書の論理構造を保持していないため、表や図を含む文書はテキスト抽出の段階で情報が壊れやすいためです。チャンク分割の前に表を構造化する前処理が必要になり、スキャンPDFではさらにOCR工程も加わります。

チャンク分割とは？RAG発注前に確認したい4つの分割手法

社内文書を対象にした RAG（検索拡張生成）の導入を進めていると、開発会社の見積書や PoC 報告書のなかに「チャンク分割設計」「チャンキングのチューニング」という項目が現れます。金額が計上されているのに、その作業が何をするものなのか、なぜ追加で必要になるのかが分からない。そんな状態で稟議を通さなければならない場面は、決して珍しくありません。

さらに困るのは、PoC の結果が思わしくなかったときです。「回答精度が出なかったのはチャンクの切り方が原因なので、分割設計を見直します」と説明を受けても、それが本当に原因なのか、見直せば直るのか、社内に判断できる人がいない。技術判断はベンダーに委ねるとしても、丸ごと預けてしまうと追加見積のたびに同じ不安が繰り返されます。

一方で、発注者がチャンク分割の実装を理解する必要はありません。必要なのは「どういう仕組みで精度と費用に効くのか」という因果関係と、「良し悪しを何で測るのか」という判断軸です。この 2 つを持っていれば、ベンダーの説明を評価し、追加見積の妥当性を議論できるようになります。

そして重要なのは、チャンク分割に「どの案件でも正しい数値」は存在しないという点です。適切なサイズや手法は、自社が持っている文書の性質によって変わります。だからこそ発注者が握るべきは数値そのものではなく、数値の決め方をベンダーと合意することです。

本記事では、チャンク分割の意味と RAG のなかでの位置づけから始め、精度と費用への影響、4 つの代表的な分割手法の違い、チャンクサイズの目安の扱い方、自社文書のタイプ別の落とし穴、そして開発会社に確認すべき 5 つの質問までを、発注者の立場から順に解説します。

Contents — 目次

チャンク分割とは？RAGが社内文書を小さく切ってから検索する理由
チャンク分割がRAGの回答精度と費用を左右する仕組み
RAGのチャンク分割手法4種類と向き・不向き
チャンクサイズとオーバーラップの目安はどう決めるか
自社文書のタイプ別に見るチャンク分割の落とし穴
チャンク分割について開発会社に確認すべき5つの質問
まとめ｜チャンク分割は数値ではなく決め方を確認する
関連情報

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

AI導入を検討しているが、何から始めればよいか分からない
ベンダーの選び方や費用感がつかめず、判断できない
社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

入力いただいたメールアドレスにPDFをお送りします。

チャンク分割とは？RAGが社内文書を小さく切ってから検索する理由

チャンク分割は、RAG の処理のなかでもっとも上流に位置する前処理です。ここで決めた方針が、後続の検索精度と回答品質の上限を決めてしまうため、見積上は地味な行に見えても、実際にはプロジェクト全体に影響します。

チャンク・チャンキングの意味を1分で整理する

チャンク（chunk）とは「塊」という意味の英語で、RAG の文脈では文書を検索しやすい大きさに切り分けたひとつひとつの断片を指します。そして、その切り分け作業をチャンキング（チャンク分割）と呼びます。

たとえば 80 ページの社内規程 PDF があったとして、これを 1 件のデータとして扱うのではなく、条文や節の単位で数百件の断片に切り分ける。この断片ひとつひとつがチャンクです。

なぜ丸ごと扱わずに切るのか。理由は大きく 3 つあります。

第一に、生成 AI が一度に読み込める文字数（コンテキスト長）には上限があるためです。80 ページの規程をそのまま渡すことは技術的にも費用的にも現実的ではありません。

第二に、検索の単位を作るためです。RAG は「質問に関係のある部分だけを探して AI に渡す」仕組みなので、探す対象となる単位が必要になります。文書全体が 1 単位のままでは「この文書のどこかに書いてある」までしか分からず、必要な箇所を取り出せません。

第三に、無関係な情報の混入を防ぐためです。80 ページ分の内容をまとめて渡すと、質問に関係のない記述まで AI の目に入り、回答が的外れになったり、別の規程の条件を混ぜて答えたりする原因になります。

つまりチャンク分割とは、社内文書を「検索でヒットさせたい単位」に切り分ける設計作業です。見積書に工数が計上されるのは、この「どの単位で切るか」が文書の性質ごとに異なり、機械的に決められないからです。

RAGの処理の流れの中でチャンク分割が置かれる位置

RAG の処理は、大きく次の流れで進みます。

文書の読み込み：PDF・Word・社内 Wiki などからテキストを取り出す
チャンク分割：取り出したテキストを検索単位に切り分ける
ベクトル化：各チャンクを意味を表す数値の並びに変換し、データベースに登録する
検索：利用者の質問に近い意味を持つチャンクを探し出す
回答生成：見つかったチャンクを材料に、生成 AI が回答文を作る

このうち手順 3 のベクトル化は、テキストの意味を数値化して「意味の近さ」で検索できるようにする処理です。本記事はチャンク分割に絞って解説するため、ベクトル化そのものの仕組みについてはエンベディングの解説記事をご覧ください。

ここで押さえておきたいのは、チャンク分割が手順 2 という上流に位置していることです。上流の切り方が悪ければ、どれだけ優秀なベクトル化や検索を組み合わせても、そもそも「正解が含まれた断片」が存在しない状態になります。検索は存在しないものを見つけられません。

そして上流であるということは、あとから変更したときの影響範囲が広いことも意味します。分割方針を変えると、その下流にあるベクトル化とデータベース登録をすべてやり直す必要があります。これがいわゆる再インデックス（再登録）で、文書量によっては相応の処理時間と費用が発生します。「チャンク設計の見直し」に追加工数が計上されやすいのは、設計作業そのものだけでなく、この再インデックスと再評価がセットで必要になるためです。

チャンク分割がRAGの回答精度と費用を左右する仕組み

「チャンクの切り方が悪い」という説明を評価するには、まず切り方の良し悪しがどう症状に現れるかを知る必要があります。ここでは大小のトレードオフを整理したうえで、精度が出ない原因の切り分け方を示します。

チャンクが大きすぎる場合・小さすぎる場合に起きること

チャンクのサイズには「大きければ安心」「小さければ正確」という単純な関係がありません。どちらの方向にも固有の失敗があります。

チャンクが大きすぎる場合、ひとつの断片のなかに複数の話題が同居します。たとえば就業規則の 1 章分をまるごと 1 チャンクにすると、有給休暇の記述と慶弔休暇の記述と特別休暇の記述が同じ断片に入ります。この状態で「慶弔休暇は何日取れますか」と質問すると、検索自体はヒットしますが、AI に渡される材料には有給や特別休暇の日数も混ざっています。結果として、別の休暇の日数を混同した回答が生成されやすくなります。また、渡す文字数が増えるぶん、利用のたびにかかる API 費用も上がります。

チャンクが小さすぎる場合、今度は文脈が切れます。製品仕様書を短く切りすぎると、「本機能は前項の条件下でのみ有効です」という一文だけが独立した断片になってしまい、「前項」が何を指すのか分からなくなります。指示語や見出しとの結びつきが失われた断片は、単独では意味をなさず、検索で見つかっても回答の材料になりません。逆に「同じ表現が短く大量に存在する」状態になるため、どの断片を取るべきかの判断も難しくなります。

業務文書でとくに問題が出やすいのは、条件と結論が離れている文書です。社内規程の「ただし、〜の場合はこの限りでない」という但し書きが本文と別チャンクに分かれると、例外規定を無視した回答が返るようになります。この種の誤りは、利用者から見ると「もっともらしいのに間違っている」形で現れるため、運用開始後の信頼を大きく損ないます。

つまりチャンク分割は、「ノイズの少なさ」と「文脈の保持」のどちらを優先するかのトレードオフであり、自社文書の書かれ方によって最適点が変わる、という性質を持っています。

精度が出ない原因はチャンク分割だけとは限らない

ここが本記事でもっとも重要な部分です。RAG の回答精度が出ないとき、原因はチャンク分割だけとは限りません。にもかかわらず「チャンクの切り方を見直します」という説明だけで追加工数が計上されると、発注者は妥当性を判断できません。

そこで、症状から疑うべき箇所を切り分ける対応表を用意しました。これはベンダーへの反論材料ではなく、打ち合わせで原因を一緒に絞り込むための共通言語として使うことを想定しています。

見えている症状	まず疑うべき箇所
回答が途中で切れる／必要な条件の一部しか含まれない	チャンク分割（サイズが小さい、または境界の位置）
質問と関係のない部署・製品の情報が回答に混ざる	チャンク分割（サイズが大きすぎる）または検索の絞り込み条件
意味は近いのに正しい文書がまったく上位に来ない	ベクトル化に使うモデル（日本語や社内の専門用語への適性）
型番・条文番号・製品コードなど固有の語で検索が当たらない	検索方法（意味検索だけでキーワード検索を併用していない）
検索された文書は正しいのに、回答が要約されすぎる／脱線する	回答生成側の指示文（プロンプト）や生成モデルの設定
文書が存在するのに「情報が見つかりません」と返る	対象範囲の設定（そもそも登録されていない、権限で除外されている）

SCROLL→

この表で分かるのは、「文脈が切れている」系の症状はチャンク分割を疑い、「そもそも見つからない」系の症状は検索側を疑うという大まかな切り分けができることです。とくに型番や条文番号で当たらないケースは、意味の近さで探す検索と語句の一致で探す検索を組み合わせることで改善する場合が多く、チャンクの切り方を変えても解決しません。検索側の仕組みについてはRAGの検索精度を扱った記事で詳しく解説しています。

打ち合わせでは、「今回精度が出なかった質問は、この表でいうとどの症状に当たりますか」と聞くだけで議論の解像度が上がります。ベンダー側も原因を一つに決め打ちしているとは限らず、切り分けの前提を共有できること自体に価値があります。

RAGのチャンク分割手法4種類と向き・不向き

チャンク分割の手法は、細かく数えれば 6 種類にも 7 種類にも分類できます。ただし発注者が提案書を評価するうえでは、そこまでの細分化は判断の助けになりません。ここでは発注判断に必要な粒度として 4 系統に絞って整理します。実装レベルでは細かな派生がありますが、「何を基準に切るか」という観点ではこの 4 つに集約できるためです。

各手法は「何をするか」「実装コスト」「向く文書」「起きやすい失敗」の 4 つの観点で統一して説明します。

固定長チャンク分割 ─ 実装は速いが文脈が切れる

何をするか：文字数やトークン数といった決まった長さで、機械的に文書を区切ります。「500 文字ごとに切る」という単純なルールです。

実装コスト：もっとも低く、最短で構築できます。PoC の初期段階ではまずこの方式で組まれることが多い手法です。

向く文書：文章が均質に続く文書に向きます。マニュアルの本文、議事録の発言記録、社内報のような読み物などです。

起きやすい失敗：文の途中や表の途中で切れます。「有給休暇は年間 20 日付与さ」で 1 チャンクが終わり、次のチャンクが「れる。ただし入社初年度は〜」から始まる、といった状態が起こります。日本語は文の区切りが英語ほど明確でないため、この問題が出やすい傾向があります。

見積書で「まずは固定長で構築し、PoC 後に見直す」という段取りが示されている場合、それ自体は不自然ではありません。ただしその場合、見直し工数が初回見積に含まれているのか、追加になるのかを最初に確認しておく必要があります。

オーバーラップ ─ 境界で情報が切れるのを防ぐ

何をするか：隣り合うチャンク同士で、末尾と先頭を意図的に重複させます。500 文字で切りつつ、直前のチャンクの末尾 100 文字を次のチャンクの先頭にも含める、といった処理です。厳密には独立した手法というより、他の手法と組み合わせて使う補正の仕組みです。

実装コスト：低く、固定長方式に設定値を追加するだけで導入できます。

向く文書：文脈が前後に連続する文書全般に有効です。とくに但し書きや条件節が独立して現れる規程類では効果が出やすくなります。

起きやすい失敗：重複を大きくしすぎると、同じ内容の断片が複数登録されるため、検索結果の上位が実質同じ内容で埋まります。また登録件数が増えるぶん、ベクトル化の費用とデータベースの容量も増えます。重複を取れば取るほど良いわけではない、という点が判断の分かれ目です。

構造ベース・階層的チャンキング ─ 見出しや親子チャンクで文脈を保つ

何をするか：文字数ではなく、文書の構造（見出し・章・条・箇条書き）を基準に切ります。さらに発展形として、「章」という大きな単位と「節」という小さな単位を親子関係で持たせ、検索は小さい単位で行い、AI に渡すときは親の情報も添える、という設計もあります。各チャンクに「どの文書のどの章か」という情報（メタデータ）を付けるのも、この系統の考え方です。

実装コスト：中程度から高めです。文書ごとに構造の取り出し方を設計する必要があり、PDF のように構造情報が失われやすい形式では前処理の工数が加算されます。近年は固定長からこの構造認識型へと設計の主流が移りつつあると整理されています（RAGチャンキング最適化｜構造認識と可変長設計）。

向く文書：見出し構造がはっきりしている文書に強く向きます。社内規程、業務手順書、製品仕様書、マニュアルなど、業務文書の多くがここに該当します。

起きやすい失敗：構造がそもそも整っていない文書では効果が出ません。見出しレベルが担当者ごとにバラバラな社内 Wiki や、体裁が統一されていない議事録では、構造を基準にできず期待した結果になりません。この場合、文書側の整備が先に必要になります。

セマンティックチャンキング ─ 意味のまとまりで区切る

何をするか：文と文の意味的な近さを計算し、話題が切り替わったところで区切ります。「ここから話題が変わった」という判定を機械的に行う方式です。

実装コスト：もっとも高くなります。分割の段階で意味の計算処理が必要になるため、構築時の処理時間と費用が増えます。文書量が多いほど差が開きます。

向く文書：見出しがなく、話題が連続的に切り替わる文書に向きます。議事録の逐語記録、問い合わせ対応の履歴、フリーフォーマットの報告書などです。

起きやすい失敗：コストに見合う精度改善が得られないケースがあります。構造がはっきりしている文書であれば、構造ベースの方式のほうが安く同等以上の結果になることも珍しくありません。「最新の手法だから」という理由だけで提案されている場合は、費用対効果の説明を求める価値があります。

なお、手法の分類とその効果についてはRAGにおけるチャンクとは？チャンキングの効果や分割の手法、注意点でも複数の方式が整理されています。

手法別の比較表と選び方の考え方

4 つの手法を並べると次のようになります。

手法	実装コスト	向く文書	起きやすい失敗
固定長	低	文章が均質に続く読み物・議事録本文	文や表の途中で切れて文脈が失われる
オーバーラップ	低（他手法との併用）	条件と結論が離れる規程・契約書	重複過多で検索結果が同内容で埋まる／費用増
構造ベース・階層的	中〜高	見出しのある規程・手順書・仕様書	構造が整っていない文書では効果が出ない
セマンティック	高	見出しのない議事録・問い合わせ履歴	コストに見合う改善が出ないことがある

SCROLL→

この表から読み取ってほしいのは、手法に優劣の順位はなく、対象文書の性質で選ぶものだということです。実務では単一の手法を選ぶのではなく、「規程類は構造ベース＋オーバーラップ、議事録はセマンティック」のように文書グループごとに使い分ける設計になることもあります。

したがって、提案書に手法名が書かれていたら、確認すべきは名前ではなく「自社文書のどの性質に合わせてその手法を選んだのか」です。この問いに具体的な文書名を挙げて答えられるかどうかで、提案が自社文書を見て作られたものか、汎用のひな型かが判別できます。

チャンクサイズとオーバーラップの目安はどう決めるか

手法を決めたあとに問題になるのが、具体的な数値です。ここは発注者がもっとも「正解を教えてほしい」と感じる部分ですが、結論から言えば正解は自社文書のなかにしかありません。その理由を順に説明します。

よく挙がる数値（512トークン・重複10〜30%）とその位置づけ

RAG のチャンクサイズについて、実務でよく参照される出発点があります。

Microsoft の Azure AI Search のドキュメントでは、チャンクサイズを 512 トークン（およそ 2,000 文字相当）、オーバーラップを 25%（128 トークン） から始めることが推奨の出発点として示されています。あわせて、最適な重複率はコンテンツの種類によって変わり、構造化されたデータは重複を少なく、会話的・叙述的なテキストは多めが向く可能性があるとも記載されています（Chunk Documents - Azure AI Search）。

オーバーラップ率については、チャンクサイズの 10〜20% 程度を定石とする整理も広く見られます。1,024 トークンのチャンクであれば 100〜200 トークンを重複させる、という考え方です（RAGチャンク戦略ガイド｜Recursive/Semantic/Late Chunkingの使い分けと日本語特有の注意点）。

ここで大切なのは、これらの数値の位置づけです。いずれも「推奨の出発点」であって、「この値にすれば精度が出る」という保証値ではありません。ベンダーの提案書にこれらの数値が書かれていること自体は妥当ですが、それは検討の終点ではなく起点だと理解しておく必要があります。

日本語文書で目安がそのまま通用しない理由

流通している数値の多くは、英語文書を中心としたベンチマークに由来します。日本語の業務文書に適用するとき、次の 2 点でずれが生じます。

ひとつは、トークン数と文字数の関係が言語によって変わることです。チャンクサイズを文字数で決めると、使用するモデルのトークン化の方式によって実際のトークン数が想定より膨らむことがあり、日本語はとくに差が出やすいとされています。「500 文字で切る」という設計が、モデルを変えた途端に想定と違う挙動になる、という事態が起こり得ます。

もうひとつは、日本語は単語の区切りが明示されないことです。英語のように単語間にスペースがないため、意味の切れ目を機械的に判定する処理が英語より難しくなります。日本語 RAG では、この特性を踏まえた形態素解析や分割方式の検討が必要になると指摘されています（日本語RAGシステムにおけるチャンクサイズとオーバーラップのベストプラクティス）。

加えて、日本語の業務文書には独特の書き方があります。条文の但し書き、箇条書きの入れ子、「なお」「ただし」で始まる補足、表と本文の相互参照。これらは英語圏のベンチマーク文書とは構造が異なるため、そこで最適とされた数値が自社の規程集でも最適である保証はありません。

結論として、一般的な目安は「試す価値のある初期値」であり、自社文書での検証結果に置き換えるべきものです。この認識をベンダーと共有できているかどうかが、後の議論の質を大きく左右します。

発注者が握るべきは数値ではなく「決め方」

ここまでを踏まえると、発注者が握るべきものが見えてきます。数値そのものではなく、数値を決めるための手続きです。具体的には次の 3 点をベンダーと合意しておくことが有効です。

1. 評価用の質問セットを誰が作るか

RAG の精度を測るには、「実際に社内から来る質問」と「その正解が書かれている文書箇所」の組を用意する必要があります。これは自社にしか作れない情報です。想定質問を 30〜50 件程度、正解の所在とあわせて用意できるかどうかが、検証の可否を決めます。ここを曖昧にしたまま進めると、「精度が出た／出ない」の議論が主観になります。

2. 何を指標として計測するか

「精度」という言葉は曖昧なので、具体的な指標に落とします。実務でよく使われるのは、「正解を含むチャンクが検索結果の上位に入った質問の割合」と「最終的な回答が正しかった質問の割合」の 2 つです。前者は検索段階の良し悪しを、後者は回答生成まで含めた最終品質を測ります。チャンク分割の効果を見るには、少なくとも前者を分けて計測してもらう必要があります。

3. 何と何を比較するか

チャンクサイズや手法を変えたとき、変更前後で同じ質問セットを使って計測し、数値を並べて示してもらいます。「複数の条件を試して比較する」という進め方自体を、契約時点で作業内容に含めておくことが重要です。

この 3 点が合意できていれば、「チャンク設計を見直します」という提案に対して「見直し後にどの指標がどれだけ改善する見込みですか」「比較結果は共有いただけますか」と自然に質問できます。数値の正解を自分で判断する必要はなくなり、判断の材料を出してもらう立場に立てます。

—Free Download / 資料ダウンロード