文字数ベースの単純な分割ではなく、GPT・Claude・Geminiなどのトークン換算とオーバーラップ指定に対応。 自然な区切りを優先した分割で、文の途中で意味が切れるのを防ぎます。
分割したいテキスト
0文字入力中
分割設定
分割単位
分割モード
チャンクサイズ（トークン）
オーバーラップ（トークン）
優先する区切り文字
トークン換算モデル
ADVICE
まずはテキストを入力してください。一般的なRAG用途では400〜512トークン程度のチャンクサイズに、10〜20%程度のオーバーラップを設定するのが標準的な出発点です。
RAGのチャンク分割とは？文字数分割との違いと設計のポイント
RAG（Retrieval-Augmented Generation）を構築する際、長い文書をそのままベクトル化することはできず、「チャンク」と呼ばれる小さな単位に分割してから登録するのが一般的です。このチャンク分割の設計は、検索の精度に直結する重要な工程です。
よくある単純な分割ツールは文字数を基準にしていますが、実際にAIモデルが処理する単位はトークンであり、日本語は英語よりトークン消費量が多くなる傾向があるため、文字数だけを基準にすると想定よりチャンクが大きく（または小さく）なってしまうことがあります。本ツールは、トークン数ベースでのチャンクサイズ指定と、チャンク境界での文脈欠落を防ぐオーバーラップ（重複範囲）指定の両方に対応した、RAG構築者向けの分割ツールです。
さらに、句点や改行などの区切り文字を優先して文の途中で意味が切れないように分割する「自然な区切り優先」モードも備えており、分割結果はJSONL形式でそのままダウンロードできます。
こんなシーンで便利です
社内マニュアル・FAQをベクトルDBに登録する前処理として
社内向けのナレッジベースやFAQをRAGで検索できるようにする際、登録前にトークン数ベースで適切なチャンクサイズに分割する用途に使えます。
既存の文字数ベース分割からの移行・比較検証として
これまで文字数ベースで分割していたパイプラインを、トークン数ベースに切り替える前に、どの程度チャンク数や粒度が変わるかを比較検証する用途に使えます。
オーバーラップ設定値をチューニングする実験として
オーバーラップの割合を10%・15%・20%と変えながら、分割結果とチャンク数・重複範囲の変化を目視で確認し、パイプラインに反映する設定値を検討する際に活用できます。
長文の技術文書やマニュアルのチャンク設計を検討する時
コードブロックや手順が長く続く技術文書について、固定サイズ機械分割と自然な区切り優先モードの結果を見比べながら、最適な分割方針を検討する用途にも使えます。
使い方は簡単 4ステップ
- テキストエリアに、RAGに登録したい文書やマニュアル・FAQなどを貼り付けます。
- 分割単位（トークン数／文字数）と、チャンクサイズ・オーバーラップの値を設定します。
- 分割モード（自然な区切り優先／固定サイズ機械分割）と、トークン換算に使うモデルを選びます。
- 分割結果を確認し、必要に応じて「JSONLダウンロード」または「テキストダウンロード」で書き出します。
※入力した文書と分割結果はブラウザ内でのみ処理され、外部のサーバーやAPIへ送信されることはありません。
ご利用時の注意点
- 本ツールが表示するトークン数は、文字種ごとの平均的な比率に基づく概算の目安です。実際に利用する埋め込みモデルの正式なトークナイザーとは異なる場合があります。
- 「自然な区切り優先」モードは、指定した区切り文字を基準に文単位を維持しながら分割しますが、区切り文字がほとんど存在しない文章では固定サイズ機械分割に近い結果になることがあります。
- オーバーラップを大きく設定するほどチャンク数が増え、ベクトルDBへの登録件数や保存容量も増加します。まずは10〜20%程度から試し、検索精度を見ながら調整することをおすすめします。
- 完全無料・安全：入力した文書は一切外部へ送信されない、通信が発生しないブラウザ完結型を採用しています。
用途別・チャンクサイズとオーバーラップの目安表
一般的なRAG構築における目安です。実際の最適値は文書の性質や埋め込みモデル、検索精度の検証結果によって調整してください。
| 用途 | 推奨チャンクサイズ | 推奨オーバーラップ | 備考 |
|---|---|---|---|
| FAQ・QA用途 | 200〜400トークン | 10〜20%（20〜80トークン） | 短い一問一答は無理に分割しないことも重要 |
| 一般的なドキュメント検索 | 400〜512トークン | 10〜20%（50〜100トークン） | 多くのRAGシステムでの標準的な出発点 |
| 技術文書・マニュアル | 1,024〜2,048トークン | 10〜15% | コード例や手順など論理展開が長い文書向け |
| 会話履歴・エージェントメモリ | 256〜512トークン/ターン | 少なめ〜なし | ターン単位や意味のまとまり単位での分割が中心 |
※上表は一般的に紹介されている目安であり、常に最適とは限りません。実際のデータでの検索精度を確認しながら調整することをおすすめします。
RAGのチャンク分割で失敗しないための考え方
文字数ベースの分割とトークン数ベースの分割の違いから、オーバーラップ設計の考え方まで解説します。
結論：チャンク分割の質は、RAG全体の検索精度を左右する
どれだけ高性能な埋め込みモデルやLLMを使っても、チャンクの切り方が悪ければ検索精度は上がりません。
チャンクが小さすぎると文脈が失われて的外れな検索結果になり、大きすぎると無関係な情報まで含まれてノイズになります。
そのため、埋め込みモデルやLLMのチューニングよりも先に、まずチャンク分割の設計を見直すことが、RAG改善において最も費用対効果の高い取り組みの一つとされています。
文字数ベースではなくトークン数ベースで分割すべき理由
埋め込みモデルやLLMのコンテキストウィンドウの上限はトークン数で管理されており、文字数ではありません。
特に日本語は英語よりトークン消費量が多くなる傾向があるため、文字数だけを基準に分割すると、日本語の文書ではチャンクが想定よりトークン数超過になりやすく、逆に英語中心の文書では余裕がありすぎる分割になりがちです。
トークン数ベースで分割することで、モデルの制約に対してより実態に近いチャンクサイズを設計できます。
オーバーラップは「多ければ良い」わけではない
オーバーラップ（重複範囲）は、チャンクの境界で重要な文が分断されるのを防ぐために有効な手法ですが、大きくすればするほど良いわけではありません。
オーバーラップを増やすほど、同じ内容が複数のチャンクに重複して保存されるため、ベクトルDBの保存容量や処理時間が増加し、検索結果に似たようなチャンクが並んでしまうこともあります。
一般的にはチャンクサイズの10〜20%程度を出発点とし、検索精度を見ながら調整することが推奨されています。
区切り文字を優先した分割が有効な場面
固定サイズで機械的に分割すると、文の途中でチャンクが切れてしまい、片方のチャンクだけでは意味が通らなくなることがあります。
句点や改行などの区切り文字を優先して文単位を維持しながらチャンクを組み立てることで、こうした「意味の分断」を減らすことができます。
一方で、区切り文字がほとんど存在しないログデータやコードのようなテキストでは、固定サイズ機械分割のほうがシンプルに扱える場合もあります。
よくある失敗と対策
文字数ベースのまま分割し、想定よりトークン数が超過してしまう
既存の文字数ベースの分割ツールをそのまま使い続け、日本語の文書で想定していたよりもチャンクのトークン数が超過し、埋め込みモデルの上限に引っかかってしまう失敗です。
💡 対策・解決策を見る▼
オーバーラップを設定せず、文脈が分断されたチャンクが生まれる
チャンクサイズだけを設定してオーバーラップを0のままにしてしまい、重要な説明が2つのチャンクにまたがって分断され、どちらのチャンクを検索しても文脈が不完全になってしまうケースです。
💡 対策・解決策を見る▼
オーバーラップを大きくしすぎて、重複コンテンツばかりが検索結果に並ぶ
文脈を手厚く残そうとオーバーラップを50%近くまで大きくした結果、チャンク数が想定以上に増え、検索結果に似たような内容のチャンクばかりが並んでしまう失敗です。
💡 対策・解決策を見る▼
固定サイズ機械分割のまま使い続け、文の途中で意味が切れる
区切り文字を考慮しない固定サイズ機械分割のまま運用してしまい、重要な定義文や手順の説明がチャンクの途中で切れてしまい、検索結果として不完全な内容が返ってくる失敗です。
💡 対策・解決策を見る▼
全ての文書に同じチャンクサイズを一律適用してしまう
FAQのような短い一問一答形式の文書にも、長い技術文書と同じチャンクサイズを一律で適用してしまい、短い文書が不要に分割されて文脈が失われてしまう失敗です。
💡 対策・解決策を見る▼
よくある質問（FAQ）
Q.文字数ベースの分割と、トークン数ベースの分割は何が違いますか
A. 文字数ベースの分割は、単純に指定した文字数ごとに機械的に区切る方法です。一方トークン数ベースの分割は、実際にAIモデルが処理する単位である「トークン」を基準にするため、埋め込みモデルやLLMのコンテキストウィンドウ上限に対して、より実態に近いチャンクサイズで分割できます。特に日本語は英語よりトークン消費量が多くなる傾向があるため、文字数だけを基準にすると想定よりトークン数が超過するケースがあり、トークン数ベースの分割が有効です。
Q.オーバーラップ（重複範囲）はなぜ必要なのですか
A. チャンクの境界で重要な文や説明が分断されてしまうと、検索時にその文脈が正しく取得できなくなることがあります。隣接するチャンク同士に一定の重複（オーバーラップ）を持たせることで、境界をまたぐ内容でも両方のチャンクに含まれるようになり、検索漏れを防ぎやすくなります。一般的にはチャンクサイズの10〜20%程度のオーバーラップが目安とされています。
Q.「自然な区切りを優先」と「固定サイズ機械分割」はどちらを使うべきですか
A. 特別な理由がなければ「自然な区切りを優先」モードをおすすめします。句点や改行などの区切り文字を優先してチャンクを組み立てるため、文の途中で意味が切れにくくなります。「固定サイズ機械分割」は、区切り文字がほとんど存在しないログデータやコードなど、構造的な区切りが期待できないテキストに向いています。
Q.推奨されるチャンクサイズとオーバーラップの目安はありますか
A. 用途によって異なりますが、FAQやQA用途では200〜400トークン程度、一般的なドキュメント検索では400〜512トークン程度、技術文書やマニュアルなど論理展開が長い文書では1,024トークン前後が目安とされています。オーバーラップはいずれの場合もチャンクサイズの10〜20%程度から試すのが一般的な出発点です。
Q.入力した文書は外部に送信されますか
A. 送信されません。本ツールはすべての分割処理とトークン数の目安計算をブラウザ内のJavaScriptだけで完結させており、入力した文書が外部のサーバーやAPIへ送信されることは一切ありません。社外秘のマニュアルや顧客データを含む文書でも安心してご利用いただけます。
Q.分割結果はどのような形式で取り出せますか
A. 画面上で各チャンクをテキストとして確認できるほか、「全チャンクをコピー」でまとめてコピーすることも、chunk_index・start_char・end_char・推定トークン数・本文を含むJSONL形式でダウンロードすることもできます。JSONL形式はベクトルDBへの登録スクリプトにそのまま読み込みやすい形式です。
あなたの声で、
このツールをより鋭く。
「こんな機能が欲しい」「ここを直してほしい」といったご意見や、新しいツールのリクエストを募集しています。エンジニアが直接目を通し、開発の参考にさせていただきます。