セマンティックチャンキングとは？意味の切れ目で分ける仕組みと実装・採否判断【2026年版】

社内文書のRAGで検索が当たらないとき、真っ先に候補に挙がる打ち手がセマンティックチャンキングです。文字数で機械的に区切る代わりに、文をベクトル化して隣り合う文の距離を測り、意味の切れ目でだけ分割する手法を指します。本記事では処理の中身から始めて、しきい値を決める4つの方式と既定値、LangChainとLlamaIndexでの引数対応、日本語文書で最初に詰まる文分割の問題、埋め込み呼び出し回数から逆算した費用と時間、そして固定長のままでよい条件までを実装者の目線で整理しました。

まとめ：セマンティックチャンキングの採否基準と、固定長より先に見る箇所

結論を先に置きます。セマンティックチャンキングは、文書を文に割り、各文をベクトルへ変換し、隣り合う文の距離が大きい位置だけを切れ目として採用する前処理です。段落の途中で文脈が断ち切られる問題は減ります。ただし、固定長分割より必ず精度が上がる手法ではありません。

2024年10月に公開され NAACL 2025 のFindingsに採録された論文「Is Semantic Chunking Worth the Computational Cost?」は、3つの検索タスクで固定長分割と比較し、計算コストに見合う一貫した精度向上は確認できなかったと結論づけました。つまり既定値のまま入れて終わり、という部品ではありません。

採用してよいのは、1文書に複数の話題が混在し、かつ段落構造がタグとして取れない場合に限られます。議事録、章立てが崩れたPDFの抽出結果などが該当。見出しタグが生きているHTMLやMarkdownなら、見出しで割るほうが安く速い。手を入れる順番も決まっていて、チャンクの粒度、クエリと文書の前処理の揃い、検索の当て方の3つを先に見ます。それを飛ばしてしきい値をいじっても、埋め込みの呼び出し回数だけが増えます。

セマンティックチャンキングの定義と、埋め込み距離で切れ目を決める内部処理

セマンティックチャンキングの定義と、固定長分割との出力単位の違い

セマンティックチャンキング（semantic chunking）とは、テキストを意味のまとまりで区切る分割手法で、区切り位置を人が決めた文字数ではなく埋め込みベクトルの距離から決める点に特徴があります。日本語では意味単位分割、セマンティック分割とも呼ばれます。

固定長分割との差は出力の揃い方に出ます。固定長は「800字ごと、150字重ねる」といった規則で切るため長さがほぼ一定で、話題の切れ目を無視して途中で切れる。セマンティックチャンキングの出力は長さがばらつき、300字のチャンクと2,500字のチャンクが同じインデックスに並びます。手法全体の見取り図と固定長・再帰的分割の位置づけはチャンク分割とは？チャンクとトークンの違いから代表的な手法まで徹底解説【2026年版】で扱うため、本記事は意味単位で切る側に絞ります。

文ベクトル化からコサイン距離計算までの処理4ステップと注意点

処理は4段階を踏みます。第1に、正規表現で文書を文へ割る。第2に、各文を前後の文と連結して1つの単位にまとめる。第3に、その単位を埋め込みモデルへ通し、隣り合う組のコサイン距離を計算します。第4に、距離の分布からしきい値を出し、それを超えた位置でだけ文書を切ります。

注意すべきは第3段階。ここで測るのは類似度ではなく距離、つまり1から類似度を引いた値で、大きいほど話題が離れていることを示します。距離が0.35という数字そのものに絶対的な意味はなく、同じ文書内の他の位置と比べて相対的に大きいかどうかで判定します。角度から近さを測る計算の中身はコサイン類似度とは？計算式・仕組みと類似検索での実装を実装目線で解説にまとめました。

buffer_sizeで前後文を束ねる理由と、既定値1が効く文書の型

1文だけをベクトル化すると、「はい、そのとおりです。」のような短い文が前後と無関係な座標に飛び、切れ目でない位置に大きな距離が立ちます。これを抑えるのが buffer_size で、LangChainとLlamaIndexのどちらも既定値は1。前1文と後1文を連結した3文分を1単位として埋め込みます。

既定値1が噛み合うのは、1文が40〜80字程度で、話題が段落単位で切り替わる日本語の業務文書です。一問一答が短く並ぶFAQなら2へ上げると質問と回答の対が1単位に収まります。逆に法令や規程のように1文が200字を超える文書では、1のままでも十分な文脈が入るため上げる意味は薄い。なお、ここで使う埋め込みモデルは検索時と同じものを指定してください。別モデルで切ると、切れ目の判定と検索の座標系がずれます。モデルごとの仕様差は埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】で比較しています。

しきい値4方式の違いと、percentile方式とSD方式の使い分け

percentile方式の既定値95と、切れ目の本数が変わる仕組み

LangChainの breakpoint_threshold_type は既定で percentile、しきい値の量は95です。文書内で計算した全距離を並べ、上位5%にあたる大きさを超えた位置だけを切れ目にする、という指定になります。

この方式の性質は、切れ目の本数が文書の長さでほぼ決まる点にあります。距離が200個あれば切れ目は約10本、2,000個あれば約100本。話題が1つしかない文書でも、上位5%は必ず存在するため機械的に切られます。値を90へ下げるとチャンクは細かく短くなり、98へ上げると数本の長いチャンクになります。まず95で流して出力の長さ分布を見て、平均が想定より長ければ下げる、という順で詰めるのが手戻りの少ない進め方です。

SD・IQR・gradient方式の既定値と、それぞれが効く文書の型

percentile以外に3方式が用意されています。既定のしきい値の量は方式ごとに異なり、意味も変わります。

使い分けの軸は、切れ目の本数を文書ごとに変動させたいかどうか。standard_deviation は平均から3σ離れた位置しか切らないため、話題が本当に変わらない文書では切れ目が0本になります。percentileのように必ず一定割合を切る挙動を避けたいならこちらを選びます。interquartile は距離の分布が歪んでいても引きずられにくく、書式の混在したPDF抽出テキストで安定。gradient は距離の変化率を見る方式で、医療や法務のように全文が高い類似度で推移し、絶対値では差が出にくい文書に向きます。

number_of_chunksで分割数を先に決める指定と、その副作用

しきい値ではなく分割数から指定する経路もあります。number_of_chunks に目標のチャンク数を渡すと、その本数になるようしきい値が逆算されます。1文書を必ずN個に割りたい、インデックスの件数を見積りたい、といった要件では扱いやすい指定です。

副作用は、意味の切れ目という前提が薄まること。指定した本数に合わせて距離の小さい位置まで切れ目に採用されるため、話題が1つの文書を10分割すれば、途中で切った固定長分割とほぼ変わらない結果になります。加えて min_chunk_size（既定は指定なし）を併用しないと、極端に短いチャンクが混じる。検索対象として使うなら、数を決め打ちせず、しきい値方式で切ってから短いチャンクを後段で結合する順のほうが安定します。

LangChainとLlamaIndexでの実装手順と、日本語文書で最初に詰まる箇所

LangChainのSemanticChunkerを動かす最小構成と引数の指定

LangChain側の実装は langchain_experimental.text_splitter.SemanticChunker です。パッケージ名のとおり実験的な位置づけで、本体の text-splitters とは別パッケージのインストールが要ります。

最小構成で渡すのは埋め込みモデルのインスタンス1つだけ。残りは既定値で動きます。明示的に触る引数は3つに絞れます。breakpoint_threshold_type で方式を選び、breakpoint_threshold_amount でしきい値の量を指定し、buffer_size で前後何文をまとめるかを決める。この3つ以外は最初から動かす必要はありません。フレームワーク側の全体像と他の部品との組み合わせはLangChainとは？LLMアプリ開発フレームワークの仕組み・できること・採用判断を解説で解説しています。

日本語の文分割が空振りする既定regexと、句点対応への差し替え

日本語文書で最初に詰まるのはここです。sentence_split_regex の既定値は、英文のピリオド・疑問符・感嘆符の直後にある空白で区切る正規表現になっています。日本語は句点で終わり、その後ろに空白を置きません。結果として文書が1文として扱われ、切れ目が1つも立たないまま丸ごと1チャンクで返ります。

厄介なのは、この状態でもエラーが出ない点。処理は正常終了し、インデックスも作られ、検索結果だけが当たらなくなります。切り分けは単純で、分割後のチャンク数と各チャンクの文字数を出力すれば、1文書1チャンクのまま通過していることがすぐ分かる。

対処は sentence_split_regex に句点・感嘆符・疑問符と改行を含めた正規表現を渡すことです。改行も区切りに入れておくと、箇条書きの各項目が個別の文として扱われて距離が立ちます。読点まで含める書き方も見かけますが、単位が細かくなりすぎて距離のばらつきが大きくなるため、まずは句点と改行から始めてください。

LlamaIndexのSemanticSplitterNodeParserとの引数対応

LlamaIndex では llama_index.core.node_parser の SemanticSplitterNodeParser が同じ役割を担います。渡す引数は buffer_size（既定1）、breakpoint_percentile_threshold（既定95）、embed_model（必須）の3つ。

LangChainとの差は選択肢の広さに出ます。LlamaIndex 側はしきい値の指定がパーセンタイル1本に固定されているため、標準偏差や四分位で切りたいなら LangChain を選ぶことになる。逆に、分割結果をそのままノードとしてインデックスへ流す構成では LlamaIndex のほうが後続の配線が短く済みます。守備範囲の違いはLlamaIndexとは？RAG構築の仕組み・LangChainとの違いと採用判断を実装者向けに解説に整理しました。

導入コストの内訳と、埋め込み呼び出し回数から逆算する費用と処理時間

文単位の埋め込み呼び出し回数と、10万文書規模での費用の概算

費用の話は、金額と回数を分けて見ないと判断を誤ります。1文書4,000字、1文50字と置くと文数は80。buffer_size が1なら同じ本文を約3回ずつ送るため、送信トークンは本文の約3倍になり、確定したチャンクを埋め込み直す1回分を加えて概算4倍です。

1万文書・平均4,000字なら本文は4,000万字、日本語ではおおむね同程度のトークン数に収まります。text-embedding-3-small は100万トークンあたり0.02ドルなので、固定長分割の一巡は約0.8ドル、セマンティックチャンキングは約3.2ドル。差額は数百円で、金額は判断材料になりません。

効いてくるのは回数のほうです。固定長なら1文書5回で済む呼び出しが、文単位では80回を超え、1万文書で85万回規模に膨らみます。毎分3,000リクエストの上限が掛かる環境なら、それだけで4時間以上。バッチ処理のAPIに逃がすか、文をまとめて1リクエストへ詰める実装にしないと、初回投入が丸1日仕事になります。

初回インデックス構築の所要時間と、再構築時に増える運用の待ち時間

初回構築は「一度で終わる作業」として見積もられがちですが、実際は繰り返します。しきい値を95から90へ変えるだけで全文書の切れ目が変わり、全チャンクの埋め込みをやり直す必要が生じるからです。固定長もチャンクサイズを変えれば全件やり直しですが、こちらは1文書あたり5回の呼び出しで済む。

差が出るのは調整の回数です。しきい値の妥当な値は文書の型ごとに違うため、社内規程・議事録・製品マニュアルが混在するなら型ごとに詰めることになり、試行のたびに数時間の待ちが発生します。運用に入ってからも文書の追加ごとに文単位の埋め込みが走るため、フォルダ一括で日次同期している構成では日々の処理時間が数倍になる点を先に見込んでおきます。

効果測定の手順と、固定長との比較で見るRecallとコストの釣り合い

質問セット50件で測るRecall@5と、固定長との差の読み方

採否は感覚ではなく数字で決めます。手順は3つ。実際に社内から出た質問を50件集め、それぞれに「この文書のこの箇所が答え」という正解を紐づけ、固定長分割とセマンティックチャンキングの両方でインデックスを作って Recall@5、つまり上位5件に正解箇所が含まれた割合を測ります。

読み方には注意が要ります。50件で測ると、1件の正誤が2ポイント動く。差が4ポイント以内なら誤差の範囲と見て、費用と処理時間が軽いほうを採るのが妥当です。判断を変えるだけの差が出たと言えるのは、10ポイント以上開いた場合に限られます。

生成側まで含めた評価への接続と、Ragasで見る指標の選び方

検索が当たっても、回答が良くなるとは限りません。チャンクが長くなればLLMへ渡す文脈が増え、無関係な記述が混じって回答が薄まることがあります。セマンティックチャンキングは長いチャンクを生みやすいため、この副作用が出やすい側です。

そこで測る指標を2段に分けます。検索側は Recall@5 と、上位に無関係な文書が混じっていないかを見る精度。生成側は、回答が渡した文脈に基づいているかと、質問に答えているかの2つで、Ragas なら faithfulness と answer relevancy が該当します。分割方法を変えると検索側だけが改善して生成側が落ちる組み合わせが起きうるため、両方を並べて比べてください。指標の定義と運用への組み込み方はRAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】にまとめています。

セマンティックチャンキングを採用しない条件と、先に直すべき3つの失敗

論文が示した固定長との差と、費用に見合わないと結論づけた根拠

ここは態度を明確にします。セマンティックチャンキングは、既定で入れるべき前処理ではありません。

arXiv:2410.13070「Is Semantic Chunking Worth the Computational Cost?」（Renyi Qu・Ruixuan Tu・Forrest Bao、2024年10月16日投稿）は、文書検索・根拠検索・検索に基づく回答生成という3タスクで、意味単位の分割と固定長分割を突き合わせました。結論は、意味単位の分割が示す利点は場面によってばらつき、計算コストに見合う一貫した向上とは言えない、というもの。文の境界で切るだけの単純な方法が、処理負荷を大きく減らしたうえで同等に近い結果を出す場面が確認されています。

この結果を実務へ落とすと、初期構成では固定長か文境界での分割を選び、精度が足りないと数字で示された場合にだけ意味単位の分割を検証する、という順番になります。逆順で始めると、効果が測れないまま前処理だけが複雑になります。

採用してよい3条件と、見送るべき文書・予算・運用体制の場面分け

採用してよいのは次の3条件がそろう場合です。第1に、1文書の中で話題が複数回入れ替わること。第2に、見出しタグや章番号といった構造情報が取れず、規則で切る手掛かりが無いこと。第3に、固定長との比較でRecallが10ポイント以上改善したこと。

見送るべき場面のほうがはっきりしています。HTMLやMarkdownで見出しが生きている文書は、見出しで割れば費用ゼロで同等の結果が得られるため採用しません。1文書1テーマで完結する製品カタログやFAQ単票も対象外で、切る必要そのものが無い。日次で数万件が追加される構成も、前掲の逆算どおり同期処理が追いつかず見送り。しきい値を調整して再構築する担当が置けない体制なら、既定値のまま放置されて固定長より悪い結果に落ち着きます。構成段階からの相談はRAG構築支援で受けています。

精度が出ないときに先に直す3つの失敗と、手を付ける実務の優先順位

検索が当たらない原因は、分割方法より手前にあることが多い。頻度の高い順に3つ挙げます。

1. 1文書を丸ごと1チャンクにしている。数万字が1ベクトルへ潰れ、どの質問にも中途半端に近い状態になります。
2. クエリ側と文書側で前処理が揃っていない。片方だけ全角半角を正規化する、片方だけ接頭辞を付ける、といったずれで座標系が食い違います。
3. ベクトル検索だけで型番や条文番号を引こうとしている。完全一致が要る検索はキーワード検索と併用しないと当たりません。

この3つはいずれも既存の埋め込みを作り直さずに手当てでき、効果も分割方法の変更より大きく出ます。順番を守るなら、まず1と2を潰し、次に固定長でチャンクサイズと重なりを2〜3通り試し、それでもRecallが目標に届かないときに意味単位の分割を検証する。ここまで来て初めて、しきい値方式の選択が判断材料になります。

よくある質問

セマンティックチャンキングの導入検討でよく挙がる質問を、実装と運用の観点から5つ整理しました。

セマンティックチャンキングと固定長分割はどちらが精度が高いですか？

文書によります。NAACL 2025 Findingsの論文は3タスクで比較し、意味単位の分割に一貫した優位は確認できなかったと報告しました。話題が頻繁に切り替わる議事録や、構造情報の取れないPDF抽出テキストでは効く場面があります。一方、1文書1テーマのFAQや見出しの生きたマニュアルでは固定長と差が出ません。自社の質問50件でRecall@5を両方測り、10ポイント以上の差が出るかで決めるのが確実です。

セマンティックチャンキングに使う埋め込みモデルは検索用と同じでよいですか？

同じものを指定してください。分割時と検索時で別モデルを使うと、切れ目を判定した座標系と検索の座標系が異なり、意味単位で切った利点が消えます。安いモデルで分割し高いモデルで検索する構成は、切れ目の判定精度が落ちるため推奨しません。費用を抑えたいなら、モデルを変えるのではなく文をまとめて1リクエストへ詰める実装で呼び出し回数を削ります。

しきい値は何から決めればよいですか？

percentile方式の既定値95から始め、出力されたチャンクの文字数分布を見て調整します。平均が2,000字を超えるなら90へ下げ、300字を下回るチャンクが多いなら98へ上げる、という順です。文書の型が混在するなら型ごとに別の値を持たせます。話題が変わらない文書で機械的に切られるのを避けたい場合は、standard_deviation方式（既定3）へ切り替えると、条件を満たさない文書では切れ目が立たなくなります。

日本語の文書でそのまま使えますか？

そのままでは動きません。LangChainのSemanticChunkerは既定で英文の終止符と直後の空白を区切りにするため、句点で終わり空白を置かない日本語では文分割が働かず、文書全体が1チャンクのまま返ります。エラーは出ないので、分割後のチャンク数を必ず出力して確認してください。対処はsentence_split_regexに句点・感嘆符・疑問符と改行を含めた正規表現を渡すことです。

チャンクが長くなりすぎた場合はどう抑えますか？

2段構えにします。まずしきい値を下げて切れ目の本数を増やし、それでも長いチャンクが残るなら、分割後に文字数の上限で再分割する処理を後段へ足す。埋め込みモデルには入力トークンの上限があり超過分は切り捨てられるため、上限を超えたチャンクは末尾が検索対象から外れます。上限の3分の1程度を目安に再分割の閾値を置くと、長さのばらつきを許容しつつ取りこぼしを防げます。短すぎるチャンクはmin_chunk_sizeか後段の結合処理で隣と束ねてください。

関連記事

• チャンク分割とは？チャンクとトークンの違いから代表的な手法まで徹底解説【2026年版】：固定長・再帰的分割まで含めた手法全体の見取り図です
• 埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】：分割と検索に共通で使うモデルの選定基準です
• コサイン類似度とは？計算式・仕組みと類似検索での実装を実装目線で解説：切れ目の判定に使う距離計算の中身です
• LlamaIndexとは？RAG構築の仕組み・LangChainとの違いと採用判断を実装者向けに解説：もう一方の実装系の全体像です
• RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】：分割方法を変えた効果を測る側の解説です