テキストの分割は情報設計の問題です
長い文書を分割する最も簡単な方法は、一定の文字数ごとに切り取ることです。また、例から定義を破ったり、その行から表のヘッダーを破ったり、続く文から話者ラベルを破ったり、要約した証拠から結論を破ったりする最も簡単な方法でもあります。
適切な分割では、ローカルな意味が十分に保持されるため、メモリから元のドキュメントを再構築することなく、各チャンクの読み取り、コピー、処理、または再開が可能になります。それには、境界、サイズ、オーバーラップ、ラベル、シーケンス、および受信システムがチャンクをどう処理するかについての決定が必要です。
実際にどのような制限を解決しているのかを把握する
「長すぎる」には、メッセージの文字数の制限、モデルのコンテキスト ウィンドウ、ファイルのアップロードの制限、データベース フィールド、ソーシャル投稿、電子メール クライアント、読者の注意など、さまざまな制約が含まれます。これらは交換可能ではありません。
| Destination | Measure | 実用的な意味 |
|---|---|---|
| メッセージング/ソーシャル プラットフォーム | Characters | ラベルと継続テキストを含む正確な文字数をカウントします。 |
| 言語モデル | Tokens | 指示、事前の会話、ツールの出力、モデルの回答のためのスペースを確保してください。 |
| ファイルのアップロード | Bytes/pages/tokens | システムは、ファイル全体をコンテキストにロードするのではなく、部分のみをインデックス付けまたは取得する場合があります。 |
| データベース/APIフィールド | 文字またはバイト | エンコードとエスケープにより、実際のペイロード サイズが変更される場合があります。 |
| 人間によるレビュー | Sections/time | 技術的な制限がない場合でも、論理ユニットを小さくすると説明責任が向上します。 |
OpenAI のトークナイザーは、英語のテキストはトークンあたり平均約 4 文字であることが多いと指摘していますが、これは経験則にすぎません。コード、URL、数字、英語以外のテキスト、および特殊な書式設定は、異なる方法でトークン化されます。トークンの制限が重要な場合は、誤った精度で文字を変換するのではなく、トークンを測定するか安全マージンを確保してください。
明確な順序で意味上の境界を選択する
階層を使用します。最初に最も強い境界を試してください。ユニットがまだ大きすぎる場合にのみフォールバックしてください。
- ドキュメントまたは章の境界。
- 見出しとそのセクション。
- Paragraph.
- リスト項目、ダイアログターン、テーブル行グループ、またはコードブロック。
- Sentence.
- 最終的なフォールバックとしての句またはハード文字/トークンのカット。
フェンスで囲まれたコード ブロック、HTML タグ ペア、マークダウン テーブル、引用ブロック、または番号付きプロシージャをむやみに分割しないでください。可能な場合は、これらの構造をアトミックとして扱います。 1 つのアトミック単位が制限を超える場合は、構造固有のルールを追加します。たとえば、すべてのチャンクでテーブル ヘッダーを繰り返すか、関数境界でコードを分割します。
受信側ワークフローからチャンク サイズを設定する
チャンクは、メタデータと応答に適合するのに十分な大きさである必要がありますが、過度の断片化を避けるのに十分な大きさである必要があります。普遍的な最適値はありません。
手動メッセージ転送の場合
ラベルや誤った編集がオーバーフローしないように、プラットフォームの制限を下回るターゲットを使用します。 4,000 文字の制限では、3,999 文字ではなく 3,500 ～ 3,700 文字が正当化される場合があります。
AI分析用
システムの指示、タスク、会話履歴、取得した資料、モデルの回答用のスペースを確保します。大きなコンテキストを受け入れるモデルは、すべてのトークンをソース テキストで埋める必要があるという意味ではありません。長いコンテキストの使用に関する研究では、たとえ長い入力用に設計されたモデルであっても、関連情報が途中に埋もれていると使いにくくなる可能性があることがわかりました。
検索またはインデックス作成用
チャンクを小さくすると精度は向上しますが、関係が失われる可能性があります。大きなチャンクはコンテキストを保持しますが、より無関係なマテリアルを取得します。論理的なセクションから始めて、チュートリアルからデフォルトのサイズをコピーするのではなく、実際の質問に基づいて評価します。
依存関係を伝える場合のみオーバーラップを使用する
オーバーラップでは、1 つのチャンクの終わりから次のチャンクの始まりまでの素材が繰り返されます。曖昧になってしまう文、定義、話者、トランジションを保存できます。重複が多すぎるとコンテキストが無駄になり、要約、カウント、または抽出されたレコードが重複する可能性があります。
可能な場合は構造的なオーバーラップを使用します。
- 見出しと一文セクションの目的を繰り返します。
- 段落が切れたら、最後の完全な文を繰り返します。
- 任意の行ではなく、テーブルのヘッダーを繰り返します。
- トランスクリプト内のアクティブな発言者とタイムスタンプを繰り返します。
- コードの継続が必要な場合は、関数/クラスのシグネチャを繰り返します。
通常の散文の場合、小さな重複 (多くの場合 1 つまたは 2 つの文) は、盲目的なパーセンテージよりも解釈しやすいです。下流タスクが繰り返しテキストを 2 回カウントできる場合は、繰り返しテキストにラベルを付けます。
すべてのチャンクに番号を付け、転送マニフェストを含める
番号を付けると、欠落している部分が見えるようになり、中断後に会話やワークフローを再開できるようになります。現在の位置と合計数の両方を使用します。
[DOCUMENT: Customer research notes]
[CHUNK: 03/12]
[SECTION: Cancellation reasons]
[CONTINUES FROM: Chunk 02]
[INSTRUCTION: Store this part. Do not analyze until CHUNK 12/12.]マニフェストでは、ドキュメント、チャンク数、順序、目的、および処理ルールを識別する必要があります。一か八かの転送の場合は、誤った編集を検出できるように、各部分に短いチェックサムまたは文字数を含めます。
最後に、最終チャンク番号と実行するタスクを示す完了メッセージを送信します。予想される合計額が分かっていないのに、「これですべて」に頼らないでください。
再開可能性を考慮した設計
再開可能なチャンクは、受信者が以前の交換に完全にアクセスできなくなった場合でも理解できます。安定した識別子と状態を含めます。
- ID とバージョンを文書化します。
- チャンク数と合計。
- 現在のセクションの見出し。
- テキストがオリジナルであるか、繰り返し重複しているか、または継続しているか。
- すでに完成しているもの。
- 最後のチャンクの後に何が起こるべきか。
長い AI セッションの場合は、バッチごとに取り込み確認を要求します。受信したチャンク ID、欠落している ID、およびまだ分析が行われていない場合です。セッションが中断した場合は、すべてを再送信するのではなく、マニフェストと最後に確認されたチャンクから再開します。
特殊なコンテンツタイプを意図的に処理する
Tables
すべての部分で列ヘッダーを繰り返します。脚注、単位、または凡例を、それらが管理する行から分離しないでください。結果をマージできるように行識別子を保持します。
コードと構成
ファイル、クラス、関数、またはトップレベルのブロック境界で分割します。ファイル名と言語を含めます。インポートと構成の依存関係を表示したままにします。重複して実行可能ステートメントが重複して作成されないようにします。
Transcripts
話者の順番や話題が変わるときに分割します。講演者名、タイムスタンプ範囲、会議 ID、アクティブな議題項目を繰り返します。
研究と引用
引用は、それが裏付ける主張とともに保管してください。セクションレベルの参考文献キーまたは URL をチャンクに組み込みます。参考文献が集中化されている場合は、後で解決できる安定した引用識別子を含めます。
法的文書または政策文書
セクション番号、定義された用語、例外、および相互参照を保持します。 「セクション 8 に規定されている場合を除く」を含むチャンクは、セクション 8 がアドレス可能のままでない限り、自己完結型ではありません。
コンテキスト ウィンドウを大きくしてもチャンキングが解消されない理由
ロングコンテキスト モデルはより多くのテキストを受け入れることができますが、入力容量は、すべての位置に対する信頼性の高い検索と推論と同じではありません。 「Lost in the Middle」調査では、関連する情報が最初または最後近くに表示されるとパフォーマンスが最も高く、途中に表示されるとパフォーマンスが低下することが多いことがわかりました。
チャンク化により、検索が明示的になり、無関係なコンテキストが削減され、タスクが関連テキストの近くに配置され、中間チェックが有効になるため、ワークフローが改善されます。また、障害を回復可能にします。つまり、会話全体を再構築しなくても、1 つの不正な部分を再送信できます。
目標は常にチャンクを小さくすることではありません。それは、モデルが適切なステップで適切なマテリアルを認識するコンテキスト アーキテクチャを構築することです。
実用的なチャンク化アルゴリズム
信頼できるスプリッターは、最初の文字制限でカットするのではなく、予測可能な順序で境界を決定する必要があります。次のプロセスは、手動転送、AI 分析、再開可能なドキュメントのレビューに機能します。
- 入力を正規化します: 行末を標準化し、誤って繰り返される空白行を削除し、意味のあるインデントを保持します。
- アトミック ブロックの保護: 内部で切り取るべきではないコード フェンス、表、引用、引用、リスト項目、見出しをマークします。
- Cセマンティック単位の作成: 最初にセクション見出し、次に段落、次に文、そして単語またはハード文字でのみ分割します。
- 目標までユニットを詰めます: ラベルと重複後の使用可能な予算内に収まる場合にのみ、次の完全なユニットを追加します。
- サイズの大きい単位は意図的に処理します。 巨大な段落は文レベルの分割が必要な場合があります。巨大なコード ブロックの場合は、任意の切り捨てではなく、別の転送方法が必要になる場合があります。
- 依存関係の重複を追加: 次のチャンクを解釈するために必要な最小限の前のマテリアルのみをコピーします。
- シーケンスのラベルとハッシュ: には、ドキュメント ID、チャンク番号、合計チャンク、およびオプションで短いチェックサムまたは最初/最後の行マーカーが含まれます。
- マニフェストを作成します。 は、元のサイズ、チャンク ルール、ターゲット、オーバーラップ、および特別な処理が必要な保護されたブロックを記録します。
このプロセスは貪欲であり、次の意味単位が予算を超えるまでチャンクを埋めていきますが、階層構造により、見出しが最初の段落から分離されたり、引用がサポートする主張から切り離されたりするというよくある失敗が防止されます。
分析が複数のメッセージにまたがる場合に状態パケットを伝送する
逐次的な AI 作業の場合、各チャンクには単にソース テキストが含まれている必要はありません。モデルに作業の位置を伝えるコンパクトな状態パケットが到着する必要があります。有用なパケットには、ドキュメント ID、現在のチャンク、タスク、承認された用語、未解決の質問、実行中の出力の形式が含まれています。
DOCUMENT: policy-review-2026-08
CHUNK: 4 of 11
TASK: identify obligations, deadlines, and ambiguous clauses
APPROVED TERMS: customer, provider, service period
RUNNING OUTPUT: append rows to the obligation table
OPEN QUESTIONS: whether section 8 overrides section 3
INSTRUCTION: acknowledge receipt; do not finalize until chunk 11各チャンクの後に、新鮮な散文の要約ではなく、短く構造化されたチェックポイントを求めます。たとえば、追加された事実、未解決の依存関係、導入された用語、最後に完成したソースの見出しなどです。そのチェックポイントは次の状態パケットに貼り付けられ、中断後に再開するために使用できます。
実行中のサマリーを際限なく拡大させないでください。定期的にそれを安定した決定と未解決の項目に圧縮し、置き換えられたナレーションを破棄します。そうしないと、概要がソースと文脈を競合する別の長い文書になってしまいます。
信頼する前に分割をテストする
スプリッターは変換パイプラインと同様にテストする必要があります。ラベルと意図的な重複を削除した後、チャンクを再組み立てし、結果を正規化されたソースと比較します。テキストは完全で、順序立てられており、偶発的な重複があってはならない。チャンクが読みにくい場合でも、バイトごとの再構成テストは合格する可能性があるため、境界を個別に検査します。
| Check | Question | 故障信号 |
|---|---|---|
| Coverage | 正規化されたソースは再構築できますか? | 文、表の行、コード行、または引用が欠落しています |
| Order | チャンクと内部ユニットはソース順に並んでいますか? | 番号付けのギャップまたは段落の反転 |
| 境界品質 | 各チャンクは理解可能な時点で始まり、終了しますか? | 見出しのみ、文の断片、分割リスト項目 |
| Overlap | 繰り返しの資料は必要であり、明確にマークされていますか? | 大規模な重複セクションまたは矛盾した概要 |
| Budget | ラベル、オーバーラップ、コンテンツはすべて適合していますか? | 受信システムが最終行を切り捨てる |
| Resumption | 任意のチャンクから作業を再開できますか? | ドキュメント ID、チャンク カウント、または以前の状態のチェックポイントがありません |
Jivaro 長いテキストとメッセージ スプリッターを使用する
Long Text & Message Splitter は、番号付きのコピー準備完了チャンクをブラウザーに作成します。ドキュメント、プロンプト、電子メール、スレッド、またはメッセージが宛先制限を超える場合に使用します。
- 元のテキストを貼り付け、コピーはそのままにしておきます。
- 宛先の最大文字数を下回るターゲット文字制限を入力します。
- すべての部品がそれ自体を識別できるように、ラベルと番号を選択します。
- テキストに継続コンテキストが必要な場合にのみオーバーラップを有効にします。
- 見出し、表、コード、引用の境界を確認します。
- チャンクを順番にコピーし、受信を確認します。
- 最終処理命令は、最後のチャンクの後にのみ送信します。
おすすめパターン
| ユースケース | Pattern |
|---|---|
| AI ドキュメント分析 | マニフェスト + セクションベースのチャンク + 待機命令 + 最終合成リクエスト。 |
| チャットまたはソーシャルメッセージ | 文字セーフなチャンク + 1/N ラベル + 文が切り取られない限り重複なし。 |
| Transcript | トピック/発言者の境界 + タイムスタンプの範囲 + 繰り返されるアクティブな議題項目。 |
| Table | ヘッダーとユニットを繰り返し、安定した行 ID を使用し、データ行が重複しないようにします。 |
| Code | ファイル/関数の境界 + ファイル名/言語 + 依存関係のメモ。 |
| マルチセッションプロジェクト | ドキュメント/バージョン ID + チャンク マニフェスト + 受領台帳 + 再開ポインター。 |
チャンク化の最終チェックリスト
- 実際の宛先制限を測定します。
- ラベル、指示、出力用のスペースを確保します。
- ハードカットよりも見出しと段落を優先します。
- 有用なオーバーラップを最小限に抑えます。
- チャンクに番号を付け、合計を示します。
- 表、コード、引用文献、講演者、定義された用語を保存します。
- 受信者に待つか行動するかを伝えます。
- すべての部品が受け取られていることを確認してください。
- 手つかずのオリジナルを保管してください。
- ワークフローを大規模に使用する前に、代表的なドキュメントでワークフローをテストします。
適切にチャンク化すると、順序、コンテキスト、およびリカバリが明確になります。 「これを何とか貼り付け」を制御された転送プロトコルに変えます。
よくある質問
ラベル、指示、会話履歴、応答用のスペースを確保した後、宛先に確実に適合する最大のチャンクを使用します。普遍的なサイズはありません。
依存関係を伝えるのに十分な量だけを使用します (多くの場合、見出しと 1 つまたは 2 つの文)。過剰な重複によりコンテキストが無駄になり、重複したカウントや要約が作成される可能性があります。
宛先で文字制限が課されている場合は、文字を使用します。モデルのコンテキスト制限が重要な場合はトークンを使用し、トークン化は言語やコンテンツ タイプによって異なるため、安全マージンを確保してください。
いいえ。容量はすべての位置の均等な使用を保証するものではありません。チャンク化によっても、取得、順序付け、検証、障害回復が向上します。
マニフェストを送信し、各パーツに番号を付け、最後のパーツまで分析しないようにモデルに指示し、受信した ID を確認し、完全なセットが確認された後にのみ最後のタスクを発行します。
関連するJivaroアプリ
長文を、書記素を壊さない文字数制限またはトークン単位の重なりを使って、X、Discord、Telegram、SMS、AIプロンプト向けのコピーしやすい断片に分割します。
アプリを開く出典と参考文献
- 途中で迷った: 言語モデルが長いコンテキストをどのように使用するかarXiv · プライマリ · 2026-08-01 にアクセス
- OpenAI TokenizerXXQPH0002QXZOpenAI · プライマリ · 2026-08-01 にアクセス
- 長いテキストとメッセージのスプリッターXXQPH0002QXZJivaro · ファーストパーティ · 2026-08-01 にアクセス