AIを整える
専門RAGチャンク設計を整える。
＝ AIに大量の資料を読ませるときの「分け方」を決める
RAG（検索拡張生成）の文書分割を設計する道具。文書量とチャンクサイズ・オーバーラップから、チャンク数・必要ベクトル数・埋め込みコストを即算出。取り出したチャンクがコンテキスト窓に収まるかも一発判定。入力はブラウザ内だけで完結（送信ゼロ）。
🔰 かんたんに言うと
AIに大量の文書を読ませるときの「分け方（チャンク）」を設計します。
TLDR — 30秒で分かる
文書量とチャンクサイズを入れるだけで、必要なチャンク数・ベクトル数・コストと「文脈窓に収まるか」が即わかる。
主な機能
- 文字数⇄トークン概算（日本語1.2字/token・英語4字/token切替）
- チャンク数・必要ベクトル数・オーバーラップ込み総トークンを自動算出
- chunk×top-k＋余裕が文脈窓（8K/32K/128K）に収まるか判定
- 埋め込みコスト概算（単価手入力＝送信ゼロ）
- 設計のコツ（小さすぎ/大きすぎ/オーバーラップ）の解説
- プリセットでワンクリック・送信ゼロ
長い文書
マニュアル・規程・Wiki
チャンク分割
一定トークンで区切る
チャンク（=ベクトル）
検索できる断片
チャンク置き場
ベクトルDB
top-k 取り出し
質問に近い上位k個
コンテキスト窓
一度に入る上限
STEP 1
※ イメージ図です。下のツールで、あなたの文書量・チャンクサイズから必要な数とコストを見積もれます。
RAG（検索拡張生成）では、長い文書をそのまま AI に渡さず、 検索しやすい大きさ（チャンク）に切り分けてベクトルDBに保存します。 質問が来たら近いチャンクだけ取り出して AI に渡す——その設計を、数字で詰めるツールです。
「100K トークンの社内マニュアルを 1000 トークンずつ刻むと、チャンクは何個？ベクトルDBはいくつ必要？ 取り出した分は 8K の窓に入る？埋め込みコストは？」——を入力するそばから計算します。
文書量を入れる
分割したい文書の大きさ
文字 ⇄ トークン換算に使う言語（文字数モードのとき有効）
プリセット（トークン）
チャンク設計
サイズとオーバーラップ（のりしろ）
1チャンクの大きさ。小さいほど粒度が細かく、大きいほど文脈をまとめて持てます。
隣どうしのチャンクを重ねる量。区切り目で文脈が切れるのを防ぎます。一般に10〜20%が目安。
チャンク数
0
必要ベクトル数
0
総トークン（重複込み）
0
—
文書全体（換算後）
0
トークン
文脈窓に収まる？
取り出したチャンク × top-k ＋ 余裕
質問ごとに取り出すチャンク数。3〜10が定番。
指示・質問・AI の回答ぶんの予約トークン。
—
—
—
埋め込みコスト
任意・単価は手入力
初回インデックス作成コスト（総トークン × 単価）
$0
※ 参考単価：text-embedding-3-small ≒ $0.02 / 1M、3-large ≒ $0.13 / 1M、Voyage / Cohere は別途。 オープンソースモデルを自前で動かせば API コストは $0。最新の正確な単価は各社の料金表でご確認ください。 ここでの計算は初回の全文インデックス作成ぶん（再インデックスや問い合わせ時の埋め込みは別）。
TIPS
チャンク設計のコツ
📏 小さすぎると
文脈が断片化し、1チャンクだけでは意味が通らなくなります。「それ」「この処理」が何を指すか分からず、検索でヒットしても役に立たないことが。FAQ のような独立した一問一答なら小さくてもOK。
🧱 大きすぎると
1チャンクに無関係な話題が混ざり（ノイズ）、検索精度が落ちます。さらに窓を圧迫し、埋め込み・生成コストも上がります。top-k で複数取ると一気に窓を食う点にも注意。
↔ オーバーラップで境界を補う
区切り目をまたぐ文脈（文の途中・表・コード）が切れないよう、隣どうしを10〜20%重ねます。重ねるほど安全ですが、チャンク数・ベクトル数・コストが増えるトレードオフ。
🎯 構造で切るのが理想
固定トークン数より、見出し・段落・文の切れ目で分ける「セマンティック分割」のほうが精度は出やすい。まずは512〜1000トークン＋10〜20%重ねを起点に、検索結果を見て調整を。
FORMULA
計算のしくみ
チャンク数 = ceil( (N − overlap) / (chunkSize − overlap) )
N = 文書全体のトークン数。前進量（stride）= chunkSize − overlap で割って切り上げ。
総トークン（重複込み） = チャンク数 × chunkSize
オーバーラップで重複した分だけ、元の N より増えます。これが埋め込み対象の量。
必要ベクトル数 = チャンク数
1チャンク＝1ベクトル。ベクトルDBの行数の目安。
窓に収まるか ：chunkSize × k ＋ プロンプト余裕 ≦ コンテキスト窓
取り出した top-k 個ぶんと、指示・質問・回答の予約を足して窓と比べます。
埋め込みコスト = 総トークン / 1,000,000 × 単価（$/1M）
単価は手入力。最新は各社の料金表で。
RELATED
あわせて使いたい
- ・埋め込みサイズを整える — ベクトル数が決まったら、必要ストレージ容量を量子化別に
- ・コンテキスト窓を整える — どのモデルの窓に収まるかをモデル別に比較
- ・トークン数を整える — 実際の文書の正確なトークン数を測りたいとき
- ・LLM料金を整える — 取り出したチャンクを LLM に渡す生成コスト
- ・プロンプトを整える — 不要な空白を取ってトークンを節約
よくある質問
Q. チャンク数はどう数えますか？
A. ceil((N − overlap) / (チャンクサイズ − overlap)) です。前進量 stride＝サイズ−重複で割って切り上げます。文書がチャンクより小さければ1になります。
Q. オーバーラップはどのくらいが目安ですか？
A. 一般にチャンクの10〜20%です。区切り目で文脈が切れるのを防ぐ「のりしろ」で、増やすほど安全ですがチャンク数・コストが増えます。
Q. チャンクサイズは何トークンが良いですか？
A. 512〜1000が定番の起点です。FAQなど独立した一問一答は小さく、文脈重視なら大きめに。検索結果を見て調整します。
Q. 「文脈窓に収まる」の判定式は？
A. チャンクサイズ × top-k ＋ プロンプト余裕 ≦ コンテキスト窓、です。例：500×5＋2000＝4500 は8K窓に収まります。
Q. 総トークンが文書より多いのはなぜですか？
A. オーバーラップで隣接チャンクが重複するためです。重複ぶんだけ埋め込み対象が増えます（重複率として表示します）。
Q. トークン数は正確ですか？
A. 概算です。モデルのトークナイザで変わります（日本語≒1〜1.5字/token、英語≒4字/token の平均値）。正確な値は文字数カウントやトークン計測ツールでご確認ください。
入力値はURLの「#」以降に入るためサーバーには送信されません。リンクを開くと同じ状態を復元します。
RELATED TOOLS
続けて整える
