チャンク分割とは。RAGの精度と費用を決める4つの設計と、見積書で見る5点

RAG（社内文書を参照して回答する仕組み）の見積書に、「チャンク分割」という行が立っていることはまずない。たいてい「データ前処理」「インデックス構築」といった名前に吸収されている。

それでいて、導入後に「思ったより答えが的外れ」「関係ない文書ばかり引いてくる」となる原因の多くは、この工程の設計にある。しかも設計の選び方は、初期費用にも毎月の運用費にも直接効く。

発注側がコードを読む必要はない。ただ、何を決める工程なのかと、決め方によって費用のどこが動くのかは知っておいたほうがよい。本記事はそのための整理である。

分厚い業務マニュアルが付箋で区切られ、薄い束に切り分けられて書類トレイに並べられている

チャンク分割とは何か

RAG は、社内文書をまるごと AI に読ませているわけではない。文書をあらかじめ小さな単位に切り分け、単位ごとに検索できる形にしてから保存する。この切り分けをチャンク分割（chunking）、切り分けられた一片をチャンクと呼ぶ。

質問が来たときの流れはこうなる。

質問文を数値の並び（ベクトル）に変換する
保存してあるチャンクの中から、意味の近いものを数件選ぶ
選ばれたチャンクだけを質問文と一緒に AI へ渡す
AI がその範囲の中で回答を作る

仕組みそのものは RAGとは何か。仕組み・費用・向く用途を発注者向けに解説とベクトル検索・埋め込みとは。意味で探す仕組みで扱っている。ここで押さえるべきは 3 の「渡すのはチャンクだけ」 という点である。

つまり、切り方が悪ければ、正しい文書を持っているのに正しく答えられない。

規程の「第5条ただし〜」の但し書きだけが別のチャンクに落ちれば、例外条件が回答に出てこない
表の見出し行と数値行が別々に切れれば、数値が何の数値か分からなくなる
1 つのチャンクに 10 ページ分を詰め込めば、検索では引っかかるが、肝心の 2 行が埋もれる

文書が足りないのではなく、切り方で情報が落ちている状態である。追加の文書を投入しても直らない。

なぜ費用の話になるのか

チャンク分割は、費用の 3 か所に同時に効く。

費用	効き方
初期費用（インデックス構築）	ベクトル化の処理はチャンク 1 件ごとに走る。細かく切るほど件数が増える
運用費（毎回の API 利用料）	1 回の回答で渡すチャンク数 × 1 チャンクの大きさが、そのまま入力トークン量になる
運用費（保存と再構築）	チャンク件数はそのまま保存量になる。文書更新時に作り直す範囲も分割設計で決まる

計算例をひとつ挙げる。仮に 1 チャンクを 400 字で切ったとして、A4 で 1,000 ページ分の文書（1 ページ 1,200 字とする）は 3,000 チャンクになる。同じ文書を 800 字で切れば 1,500 チャンクである。件数は半分になるが、1 回の回答で AI に渡す分量は逆に増える。

どちらが安いかは、文書量と質問の頻度のどちらが大きいかで逆転する。質問が多い業務ほど、1 チャンクを小さくしたほうが月額は下がる。逆に文書が膨大で質問が少なければ、細かく切るほど初期費用が膨らむ。

見積書の金額だけを見ても、この判断がどちらに倒れているかは分からない。だからこそ、どちらの前提で組んだのかを聞く必要がある。

設計判断 1. どの単位で切るか

もっとも基本的な判断で、選択肢は大きく 3 つある。

切り方	内容	向く文書
固定長で切る	文字数・トークン数で機械的に切る	形式が揃っていない雑多な文書
構造で切る	見出し・条文・章立ての単位で切る	規程、マニュアル、仕様書
意味の切れ目で切る	話題が変わる位置を判定して切る	議事録、問い合わせ履歴、報告書

下にいくほど精度は出やすく、前処理の工数は増える。3 つ目は判定そのものに AI を使うことが多く、その分の費用も乗る。

ここで費用が跳ねやすいのは、元の文書がきれいな文字データになっていない場合である。スキャンした PDF、段組みのある資料、セルが結合された表などは、切る前に「読み取って構造を復元する」工程が必要になる。AI開発のデータ準備。品質・量・権利の実務で触れているとおり、ここは費用の読み違いが起きやすい箇所である。

設計判断 2. 大きさと重なりをどう取るか

チャンクの大きさに加えて、隣り合うチャンクをどれだけ重ねるか（オーバーラップ）を決める。重なりを持たせると、切れ目にまたがった文が両方のチャンクに入るため、文脈が落ちにくくなる。

代わりに、重ねた分だけチャンクの総量が増える。重なりを 2 割取れば、保存量もベクトル化の回数もおよそ 2 割増えるという関係になる。

設計	精度への影響	費用への影響
チャンクを小さくする	検索は当てやすいが、前後の文脈が落ちる	件数が増え、初期費用と保存量が増える。1 回あたりの入力は減る
チャンクを大きくする	文脈は保たれるが、無関係な部分も一緒に渡る	件数は減るが、1 回あたりの入力トークンが増え、月額に効く
重なりを増やす	切れ目の取りこぼしが減る	総量が増え、初期費用・保存量が増える

なお、1 回に渡せる分量には上限がある。詳しくはコンテキスト長とは。一度に渡せる情報量の制約にまとめている。「上限まで渡せば精度が上がる」ではない点に注意したい。渡す量を増やすほど、関係のない情報も一緒に入る。

設計判断 3. チャンクに何を持たせるか

チャンクは本文だけを持つわけではない。一緒に保存する付帯情報（メタデータ）の設計が、実務ではかなり効く。

出典（どの文書の何ページか）… 回答に根拠を表示できるかどうかが決まる
章立て（どの章のどの節か）… 切り出した断片が何の話なのかを保てる
版数・有効期限（いつ時点の規程か）… 古い版を引かせない制御ができる
閲覧権限（どの部署が見てよいか）… 検索の段階で絞り込める

最後の権限は、費用に大きく効く項目である。部署や個人の単位で見せる範囲を分けるなら、チャンクごとに権限を持たせ、検索時に絞り込む仕組みが要る。RAG・社内検索の費用相場。文書量と権限で何が変わるかで整理したとおり、RAG の金額差は文書量よりも権限要件で開くことが多い。

「根拠を出せること」を要件にするかどうかも、ここで決まる。出典を持たせていなければ、後から表示だけ足すことはできない。

設計判断 4. 文書が更新されたときにどうするか

見落とされやすいのがこれである。社内文書は更新される。そのたびにチャンクとベクトルを作り直す必要がある。

方式	内容	運用費への影響
差分だけ作り直す	変わった文書のチャンクだけ入れ替える	月額は小さく収まる。設計時の作り込みが要る
全体を作り直す	定期的に全文書を再構築する	文書量に比例して毎回費用が発生する

初期構築の見積書は同じ金額でも、この方式の違いで月額は数倍変わりうる。「文書の更新はどう反映されますか」「その作業は月額に含まれますか、都度費用ですか」は、必ず聞いておく質問になる。

見積書で確認する 5 点

技術的な良し悪しを発注側が判定する必要はない。決めたことが書いてあるかを見れば足りる。

確認する点	質問の仕方
切る単位	「文書はどの単位で分割しますか。規程や表はどう扱いますか」
大きさの前提	「1 回の回答で何件くらい参照する想定ですか」
前処理の範囲	「スキャン PDF や結合セルのある表は、今回の範囲に入っていますか」
根拠表示と権限	「回答に出典を出しますか。部署ごとの閲覧制限は必要ですか」
更新の反映	「文書が更新されたとき、誰がどの頻度で反映しますか。月額に含まれますか」

この 5 点に答えが返ってこない見積書は、チャンク分割の設計をまだ決めていない状態である。決めていないこと自体は着手前なら普通だが、その場合は「検証後に確定」と書かれているべきで、金額は変わりうる。安く見える見積書の差が、実はここの前提の違いだった、という事態を避けられる。

受け取った見積書がこの前提を書いているかどうかを確認したい場合は見積書チェックを、これから発注する段階なら費用診断で分野とフェーズごとの目安を出したうえで、この 5 点を質問リストに入れておくとよい。削れる部分と削ってはいけない部分の切り分けは RAG開発を安くする方法と適正価格。どこまで削れるかにまとめている。

まとめ

チャンク分割は、社内文書を検索できる単位に切り分ける工程。RAG では切られた断片だけが AI に渡る
切り方が悪いと、正しい文書を持っていても正しく答えられない。文書を足しても直らない
費用は 3 か所に効く。ベクトル化の件数（初期）・1 回に渡す量（月額）・更新時の作り直し（月額）
決めるのは 4 つ。切る単位 / 大きさと重なり / 付帯情報（出典・権限）/ 更新の反映方法
発注側は技術判断をしなくてよい。その 4 つが見積書に書かれているかを確認すれば足りる