Chonkieとは？RAGチャンキングライブラリを各Chunkerで実機比較検証

Chonkie（feyninc/chonkie・GitHubスター4,506・MITライセンス）は、RAG（検索拡張生成）のための軽量なチャンキング／インジェスト用Pythonライブラリです。RAGを作っていて、こんな経験はないでしょうか——「ちゃんと検索できているはずなのに、LLMの答えがどこかズレる」。原因の多くは、モデルでもベクトルDBでもなく、その手前の文書の切り方（チャンキング）にあります。意味の途中でぶつ切りにされたチャンクは、検索でヒットしてもLLMに渡る文脈がバラバラで、答えの質を静かに下げます。

この記事の主題は1つです。「Chonkieの何が違い、どのChunker（分割器）をどう使い分けるのか」を、公式READMEの主張を鵜呑みにせず、編集部が実際にライブラリをインストールして同じ文書を各Chunkerに通し、分割境界がどう変わるかを実機で確かめた結果から解説します。汎用的な「RAGのチャンキング」解説は多いので、ここでは Chonkie 固有の挙動に深く踏み込みます。RAGそのものの全体像は、まず RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ で俯瞰しておくと、本記事の位置づけが掴みやすくなります。

Chonkieとは何か——「軽い・速い・堅牢」なRAGインジェストライブラリ

Chonkieを一言で表すと、「RAGの取り込み処理（分割・整形・埋め込み・DB投入）を、薄く速いライブラリ1本でつなぐ道具」です。公式は “The lightweight ingestion library for fast, efficient and robust RAG pipelines”（高速・効率的・堅牢なRAGパイプラインのための軽量インジェストライブラリ）と名乗り、🦛（コビトカバ）をマスコットにしています。

RAGの前処理は、実装するとなると意外に面倒です。文書を読み込み、適切な大きさに割り、必要なら重なりを付け、埋め込みを計算し、ベクトルDBの作法に合わせて投入する——この一連を、LangChainやLlamaIndexのような大きなフレームワークに乗せると依存が膨らみます。Chonkieは逆に「必要なものだけを最小インストールする」思想で、既定インストールのホイールサイズは公称505KB、Recursive や Token など主要なChunkerは追加モデルなしで動くのが売りです。

Chonkieが扱う処理は、分割だけではありません。取り込みから投入までを次の役割に分けて、同じ枠組みで扱えます。

・Chef / Fetcher：ファイルやディレクトリからの読み込み、Markdown・CSV/Excelの前処理
・Chunker：本体。Token/文/再帰/意味/コード/LLMなど11種の分割器
・Refinery：チャンクに「重なり（overlap）」や埋め込みを付けて整形
・Porter：JSONやHugging Face datasets形式で書き出し
・Handshake：Chroma・pgvector・Qdrant・Pinecone・Weaviate・Milvusなど10以上のベクトルDBへ直接投入

では、Chonkieは何を代替できるのでしょうか。多くのRAG実装では、分割は「LangChainやLlamaIndexの一機能」か「自作の素朴なスプリッタ」で済まされています。Chonkieは、数あるテキスト分割 Pythonライブラリの中でも特に軽量な部類で、この「フレームワークの一機能」や「自作スプリッタ」を、より軽く・より多くの分割戦略を選べる専用層に置き換えることができます。全体を作り直す必要はなく、前処理の一段だけを差し替える形で導入できるのが実務的な利点です。

読者の関心はおそらく「結局、何ができて、何を解決するのか」でしょう。Chonkieが解決するのは、「RAGの前処理を、重いフレームワークを抱え込まずに、分割の質を選びながら完結させたい」という需要です。次章から、その中心にあるチャンキングがなぜRAGの精度を左右するのかを見ていきます。

なぜチャンキングでRAGの検索精度が決まるのか

RAGの品質は、しばしば「どのLLMを使うか」「どのベクトルDBが速いか」で語られます。しかし実務でボトルネックになりやすいのは、その手前のチャンキングです。理由はシンプルで、ベクトル検索は「チャンク単位」で行われるからです。チャンクの切り方が悪ければ、検索の入り口の時点で勝負が決まってしまいます。

具体的な失敗はこう起きます。見出しとその直後の段落が別々のチャンクに割れると、「この手順は何のためか」という文脈が失われます。1つの手順の途中でチャンクが切れると、検索では前半だけがヒットし、肝心の後半がLLMに渡りません。逆に、話題の異なる複数のトピックが1つのチャンクに詰め込まれると、埋め込みベクトルが「平均化」されて、どのクエリにも中途半端にしか一致しなくなります。

つまり RAG チャンキングは、RAGパイプラインの中で最も費用対効果の高い改善ポイントになり得ます。モデルを大きくしたりベクトルDBを乗り換えたりする前に、まず「切り方」を変えるだけで検索がまとまることは珍しくありません。実際、RAGの改善で「retrieval（検索）が弱い」と感じたときの多くは、埋め込みモデルの性能不足ではなく、その手前の分割で意味が壊れていることが原因です。ここで問題になるのが、「どう切るのが正解か」は文書の性質によって違うという点です。技術ドキュメント、契約書、ソースコード、チャットログでは、望ましい境界がまったく異なります。だからこそ、複数の分割戦略を手早く試して比較できることに価値があります。それがChonkieの中心的な提供価値です。

なお、分割の前段にある「PDFや表を崩さずにMarkdownへ変換する」工程も検索精度を大きく左右します。取り込み元がPDF主体なら、MinerUでRAGの文書取り込みを高精度化｜PDF・表・数式をLLM対応Markdownに変換 のような高精度パーサでMarkdown化してから、Chonkieで分割する二段構えが有効です。

Chonkieの各Chunkerを同じ文書で実機比較する

ここが本記事の核心です。同じ1つの文書を、Chonkieの代表的な4つのChunkerに通し、分割の結果がどう変わるかを実機で確かめました。使ったのは、日本語と英語が混ざったRAG設計メモ（710文字）です。chunk_size は揃えて（128トークン）、境界の付き方の違いだけを見ます。

まず、Chonkieが備える主なChunkerを一覧にします。名前とエイリアスは公式READMEの表に準拠しています。

そのうえで、TokenChunker・SentenceChunker・RecursiveChunker・SemanticChunker に同じ文書を流した実際のターミナル出力が以下です。

数字で並べると、違いは一目瞭然です。

注目してほしいのは、TokenChunkerの分割境界です。128トークンぴったりで切るため、単語やマルチバイト文字の途中でも容赦なく分割します。実測では、日本語の「マニュアル」が マニュア｜ル に、英単語 “retrieval” が ret｜rieval に割れました。検索の観点では、これは静かな毒です。「マニュアルの手順」を探しても、”マニュア” で終わるチャンクと “ル に基づいた…” で始まるチャンクに分断され、意味的な一致度が落ちます。

一方、SentenceChunker は「社内文書やマニュアルに基づいた回答を作れます。」という文の頭できれいに開始し、RecursiveChunker は “Chunk boundaries matter.” という段落の頭で開始しました。SemanticChunker はさらに踏み込み、「なぜチャンキングが重要か」という節を183トークンでまるごと1チャンクに保ちました。話題が変わる境界で切るので、チャンク数は5と最も少なく、まとまりが良くなります。

分割器の種類と並んで効くのが chunk_size（1チャンクの上限）です。小さすぎると1チャンクの文脈が薄くなり、検索でヒットしても情報が足りません。大きすぎると1チャンクに複数の話題が混ざり、埋め込みが平均化されて一致度が下がります。実務では、まず埋め込みモデルの入力上限とLLMの文脈量から逆算し、256〜512トークン前後を起点に、対象文書で数パターン試して検索精度を比べるのが定石です。Chonkieは分割器も chunk_size も数行で差し替えられるため、この「試して比べる」サイクルを速く回せます。実測でも、同じ128トークン上限でも分割器を変えるだけでチャンク数が5〜7と変わりました。パラメータと分割器の組み合わせを、自分の文書で素早く総当たりできることそのものが、精度チューニングの近道になります。

どのChunkerを選ぶかは、この「境界のクセ」と「コスト」のトレードオフで決めます。早見表にまとめました。

セマンティック チャンクはいつ効くのか——SemanticとLateの違い

固定長や文単位の分割で検索精度が頭打ちになったとき、次の一手がセマンティック チャンク（意味的分割）です。SemanticChunkerは、隣り合う文の埋め込みベクトルの類似度を計算し、「話題が変わった」と判断できる境界でチャンクを切ります。実機で「なぜ重要か」の節がまるごと1チャンクに収まったのは、その節の中では文どうしの意味的な距離が近かったからです。結果として、検索時に「その話題を一度に」引ける確率が上がり、LLMに渡る文脈が途切れにくくなります。

ただし代償があります。第一に、埋め込みモデルが必須で、初回はロードとダウンロードのコストがかかります（実測の約9.4秒の大半がこれで、分割そのものの速度ではありません）。第二に、文書ごとに最適な類似度しきい値が違い、ある程度のチューニングが要ります。LateChunker（late）は少し発想が異なり、先に全体を埋め込んでから分割することで、各チャンクの埋め込み品質を上げることを狙うアプローチです。「まず意味の境界で切りたい」ならSemantic、「チャンク埋め込みの質を優先したい」ならLate、と役割で選びます。どちらも「検索精度を最後のひと押しで伸ばす」ための上位オプションで、まずは軽いRecursiveで土台を作ってから検討するのが順当です。

さらに品質を突き詰めるなら、SlumberChunker（別名 Agentic Chunking）はLLMそのものに「どこで切るべきか」を判断させます。人手に近い自然な境界が得られる一方、チャンクごとにLLMを呼ぶためコストと時間が跳ね上がります。バッチの前処理を一度だけ丁寧に回す、といった限定的な使い方が現実的です。ここでも「品質・速度・コストの三択で、どこを取るか」というトレードオフの構図は変わりません。

インストールとパイプライン——3分でCHONKしてベクトルDBまで

実際に動かすまでは驚くほど短いです。まずインストール。最小構成なら追加の重い依存はありません。

# 最小インストール（Token/文/再帰などは追加モデル不要で動く）
pip install chonkie

# 意味的分割まで使う場合（埋め込みモデルが入る）
pip install "chonkie[semantic]"

# uv を使うとより高速
uv pip install chonkie

最小コードはこれだけです。Chunkerをインポートして、初期化して、テキストを渡すと、チャンクの配列が返ります。各チャンクは本文（text）とトークン数（token_count）を持ちます。

# 使いたいChunkerをインポート
from chonkie import RecursiveChunker

# 初期化（既定はMarkdown対応の再帰分割）
chunker = RecursiveChunker(chunk_size=512)

# テキストを分割
chunks = chunker("あなたの長いドキュメント……")

# チャンクにアクセス
for chunk in chunks:
    print(chunk.text)
    print(chunk.token_count)

Chonkieの本領は、分割の先のパイプラインにあります。Pipeline を使うと、「分割 → 整形（重なり付与・埋め込み）→ 投入」までをチェーンで書けます。次の例は、Markdownレシピで再帰分割し、重なりを付け、埋め込みを付加する流れです（recipe や chunk_size は用途に応じて調整します）。

from chonkie import Pipeline

pipe = (
    Pipeline()
    .chunk_with("recursive", tokenizer="gpt2", chunk_size=2048, recipe="markdown")
    .refine_with("overlap", context_size=128)
    .refine_with("embeddings", embedding_model="sentence-transformers/all-MiniLM-L6-v2")
)

doc = pipe.run(texts="あなたのドキュメント……")
for chunk in doc.chunks:
    print(chunk.text)

さらに、ChonkieはセルフホストのREST APIサーバーとしても動きます（chonkie serve またはDocker）。パイプラインをSQLiteに保存して再利用でき、アプリからHTTPで分割を呼べます。ベクトルDBへの投入は Handshake が担い、Chroma・pgvector・Qdrant・Pineconeなど主要DBへ同じ作法で流し込めます。「分割だけ」から「取り込み～投入まで」へ、必要に応じて範囲を広げられる設計です。

なお、パイプラインの中の Refinery（整形）は地味ですが効きます。overlap（重なり）はチャンクの端に前後の文脈を少し重ねて付ける処理で、境界付近の情報が検索から抜け落ちるのを防ぎます。embeddings はチャンクに埋め込みを付与し、そのままベクトルDBへ渡せる状態にします。分割で「意味の単位」を保ち、Refineryで「境界の欠落」を補い、Handshakeで「投入」まで運ぶ——この3段を1つのパイプラインで宣言的に書けるのが、Chonkie 使い方の勘所です。

日本語文書でのテキスト分割とトークナイザ選び

Python でのテキスト分割を日本語文書で行うとき、見落としがちなのがトークナイザの選択です。Chonkieの既定は文字ベースのトークナイザで、追加依存なしで動く代わりに、実際にLLMへ渡すときのトークン数とはズレます。OpenAI系モデルに合わせるなら tiktoken、Hugging Faceのモデルに合わせるなら tokenizers／transformers のトークナイザを指定し、chunk_size を「そのモデルのトークン単位」に揃えるのが正確です。Chonkieはカスタムのトークンカウンタ（文字列を受け取り整数を返す関数）も受け付けるので、独自の数え方にも対応できます。

日本語では、TokenChunkerの「単語途中でも切る」挙動が特に目立ちます。実測の マニュア｜ル のように意味の単位が割れると、検索での一致度が落ちます。日本語主体のコレクションでは、まず SentenceChunker か RecursiveChunker で「文・段落の境界を保つ」ことを優先し、そのうえで必要なら意味的分割を重ねる順序が無難です。公式は56言語のマルチリンガル対応を掲げていますが、自分の言語・文書で1度は実測して境界を目視するのが、遠回りに見えて最短の検証です。

RAGの全体を自前で組み上げる文脈に興味があれば、分割・埋め込み・検索・生成を一通り手を動かして辿る Langchain RAG From Scratch：ゼロからRAGシステムを構築 と読み比べると、Chonkieが「前処理層をどれだけ薄く肩代わりしてくれるか」がよく分かります。

LangChain・LlamaIndexとの違いと使い分け

「LangChainのtext splitterやLlamaIndexのnode parserがあるのに、なぜ別のライブラリを入れるのか」——当然の疑問です。結論から言うと、役割は重なるが、狙いと重量が違うからです。LangChain/LlamaIndexは「RAGやエージェントの全部入りフレームワーク」で、分割はその一機能。Chonkieは「チャンキング＋インジェストに特化した薄い専用ライブラリ」です。

公式のBENCHMARKS.md（自社計測である点に注意）は、次のような数値を挙げています。あくまでベンダー側の計測条件（Google Colab A100や特定データセット）での主張であり、鵜呑みにはせず「傾向」として読むのが安全です。

数値の大小そのものより、設計思想の違いが使い分けの軸になります。すでにLangChainやLlamaIndexでアプリ全体を組んでいて、分割はその一部で足りているなら、無理に置き換える必要はありません。逆に、「前処理層を軽く保ちたい」「分割戦略を細かく比較・切り替えたい」「分割～ベクトルDB投入までを薄く完結させたい」なら、Chonkieを前処理層として差し込む価値があります。

具体的な移行イメージはこうです。たとえば LangChain の RecursiveCharacterTextSplitter で固定的に切っていたパイプラインで、検索精度が伸び悩んでいるとします。ここで前処理だけを Chonkie に差し替え、まず RecursiveChunker で同等の分割を再現し、次に一部のコレクションを SemanticChunker に切り替えて、検索のヒット精度（想定質問に対する正解チャンクの再現率）を比較する——という段階移行が可能です。アプリの検索・生成部分（プロンプトやLLM呼び出し）はそのままに、「分割器だけを差し替えて効果を測る」ことができるため、リスクを抑えて改善を試せます。合わなければ元に戻すのも、前処理一段の入れ替えなので容易です。実際、Chonkieの埋め込み連携には LangChain 経由でも使える各種プロバイダ（OpenAI・Cohere・Gemini・sentence-transformers等）が揃っており、「Chonkieで分割し、既存のスタックで検索・生成する」という部分採用がしやすい構造です。

知識グラフ型のRAG（エンティティ関係を使って網羅性を上げる系統）とも競合しません。例えば LightRAG｜知識グラフ×デュアルレベル検索でRAGの精度と網羅性を高める仕組み は「検索・推論の構造」を工夫するアプローチで、Chonkieは「その手前の分割の質」を担います。両者はレイヤーが違うため、LightRAGのような検索側の工夫と、Chonkieのような分割側の工夫は併用できると考えるのが自然です。

Chonkieは実務で使えるか——ライセンス・活性度・バス係数を実測

最後に、当サイトが必ず確認する「使えるか」の判定材料を、GitHub APIとPyPIの一次情報で実測しました（いずれも2026年7月19日時点）。誇張も過小評価もせず、数字のまま並べます。

読み解きのポイントはバス係数です。コミットは上位3名にかなり集中しており、しかもこの3名はいずれも Chonkie を開発する企業（Chonkie AI。ホスト版 labs.chonkie.ai を運営）に紐づきます。つまりリスクは、個人OSSにありがちな「作者が飽きてやめる」ではなく、「単一企業がプロジェクトの方向を握っている」継続性リスクとして読むのが正確です。企業バックのOSSは、資金と専任開発者がいる分だけ短期の勢いは強い一方、事業判断で優先度が変わる可能性を抱えます。

もう一点、リポジトリ名の注意です。過去に chonkie-inc/chonkie という名前で知られていましたが、現在は組織がリネームされ、正規のリポジトリは feyninc/chonkie です（GitHub APIは両方を同一リポジトリとして解決します。READMEやバッジには旧 chonkie-inc 表記が残る箇所があります）。ドキュメント（docs.chonkie.ai）とクラウド版（labs.chonkie.ai）も併存する、商用と併走するタイプのOSSである点を踏まえておくと、採用判断がぶれません。

この「OSS本体＋ホスト版クラウド」という構成は、近年よくある持続可能なOSSの形の一つです。ローカルで完結させたいなら pip install chonkie のライブラリ版だけで足り、外部にデータを出す必要はありません。スケールや運用を任せたい場合にクラウド版という選択肢がある、という理解で十分です。少なくとも本記事で検証したチャンキング機能は、すべてローカルのMITライセンス版だけで動きました。ライセンス面でも商用利用に制約はなく、この点は安心して採用できる材料です。

総じて、Chonkieは「RAGの前処理を軽く・選べる形で完結させたい」という明確な需要に、きれいに応えるライブラリです。特に、分割戦略を数行で切り替えて比較できることは、RAGの精度チューニングにおいて実務的な武器になります。一方で、公式の派手なベンチ数値は自社計測として割り引き、バス係数（単一企業依存）とv1系の変更可能性は正直に織り込むべきです。

まとめ——RAGの精度は「切り方」で決まる

RAGの改善というと、つい大きいモデルや高速なベクトルDBに目が向きます。しかし本記事で実機に示したとおり、同じ文書でもChunkerが違えば分割境界はここまで変わり、それが検索のヒット精度を静かに左右します。Chonkieは、その「切り方」を軽量なライブラリで選べる・比べられるようにしてくれます。

・Chonkieの価値＝チャンキング～ベクトルDB投入を薄く速く完結させ、Token/文/再帰/意味など複数の分割戦略を同じAPIで切り替えられること
・使い分けの起点＝まず Recursive を既定に、精度が要る箇所だけ意味系へ、速度が要る箇所は Token/Fast へ
・正直な留保＝公式ベンチは自社計測として割り引き、バス係数は単一企業依存、v1系は破壊的変更の可能性あり——ここを織り込めば、実務投入の判断材料は過不足なく揃う

まずは手元のドキュメントで pip install chonkie を実行し、いつも使っている文書を Recursive と Semantic の両方に通して、チャンク数と境界の違いを自分の目で比べてみてください。今回の実機比較で示したように、その差は「読めば分かる」レベルではっきり現れます。「切り方を変えるだけで検索が締まる」感覚が一度でも掴めれば、RAGチューニングの引き出しが1つ増え、モデルやベクトルDBを乗り換える前に試すべき一手が明確になります。

参照ソース

・feyninc/chonkie（公式リポジトリ・旧 chonkie-inc/chonkie）
・Chonkie 公式ドキュメント（docs.chonkie.ai）
・BENCHMARKS.md（公式・自社計測のベンチマーク）
・chonkie（PyPI・バージョンと対応Pythonの確認）
・RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ