レッスン3：チャンキング戦略と埋め込みモデル選定

このレッスンで学ぶこと

チャンキングの目的と、粒度が検索・生成に与える影響を理解する
チャンキング 5 種類（固定長・段落・セマンティック・親子・要約）を状況で使い分けられる
チャンクサイズ・オーバーラップ・セパレータの設計の勘所を持つ
Anthropic Contextual Retrieval（2024 年 9 月）の狙いと位置づけがわかる
埋め込みモデル 4 象限（クローズド／OSS × 多言語／単言語）で選定できる
日本語対応の埋め込みモデル（intfloat/multilingual-e5、cl-nagoya/sup-simcse-ja 系）の選び方の勘所を掴む
次元数とストレージ・検索速度のトレードオフを把握する
再埋め込みコストを見積もれる

前レッスンでは、社内文書の類型・前処理・メタデータ設計・更新戦略を扱いました。本レッスンでは、その集めた文書を「意味のある単位に切り分けて」「数値ベクトルに変換して」ベクトル DB に索引化するまでの、RAG 索引段階の中核を扱います。ここでの設計が、後段の検索精度の天井を決めます。

なぜ「切る」のか——チャンキングの目的

まず、「なぜチャンクに切るのか」を確認します。理由は 3 つあります。

LLM のコンテキスト長を超えないため：長い文書を丸ごと LLM に渡すことはできないため、意味のある単位に切って、質問に関連するものだけを渡す必要がある
検索の粒度を意味に揃えるため：ベクトル検索は「クエリとチャンクのベクトル距離」で近さを測る。1 チャンクに複数の話題が混ざっていると、検索精度が下がる
引用・出典表示のため：ユーザーに「この 300 字の一節を根拠にしています」と示す粒度を作る。丸ごと 1 文書を出典にするのは、あまりに広すぎる

チャンクは細かすぎても、大きすぎても駄目です。細かすぎると文脈を失い、大きすぎると無関係な情報が混ざる。適切な粒度は、文書の性質と質問の性質で変わります。

チャンキング 5 種類

社内 RAG で使われる代表的なチャンキング方式は 5 種類です。

flowchart TB
  C1[固定長チャンク<br/>N 文字ごとに切る]
  C2[段落・見出しチャンク<br/>構造単位で切る]
  C3[セマンティックチャンク<br/>意味の変わり目で切る]
  C4[親子（Parent-Child）チャンク<br/>親と子の 2 階層]
  C5[要約チャンク<br/>親文書＋要約]

1. 固定長チャンク（Fixed-size chunking）

最も単純な方式で、文書を N 文字（あるいは N トークン）ごとに区切ります。例えば 500 文字ごとに 100 文字のオーバーラップを持たせて切る、といった具合です。実装が簡単で、あらゆる文書に適用できるのが利点です。一方で、文の途中や段落の途中で切れるため、文脈が壊れやすいという弱点があります。

2. 段落・見出しベースのチャンク（Structure-based chunking）

見出し（##、### など）・段落・箇条書きといった構造の単位で切る方式です。前レッスンでレイアウト解析を扱ったのは、この方式を可能にするためでもあります。文脈が保たれやすいのが利点で、Wiki・ドキュメント・議事録のように構造が明確な文書に向いています。ただし、章によって長さが極端に異なる場合、大きすぎる章と小さすぎる章が混在します。

3. セマンティックチャンキング（Semantic chunking）

「意味の変わり目」で切る方式です。文を 1 文ずつ埋め込みに変換し、隣り合う文のベクトル距離が閾値を超えた地点をチャンクの境界とします。話題が切り替わる箇所で自動的に区切れるのが利点で、構造が薄い自由記述文（メール・議事録・ブログ・ノート）で威力を発揮します。ただし、埋め込み計算のコストがかかり、閾値のチューニングも必要です。

4. 親子チャンク（Parent-Child chunking、階層チャンク）

同じ文書を「親（大きなチャンク）」と「子（小さなチャンク）」の 2 階層で索引化します。子で検索し、当たった子を含む親を LLM に渡す方式です。「検索は精密に、生成には広い文脈を」を両立できるのが利点で、実務でよく採用される方式の 1 つです。LangChain や LlamaIndex にも組み込みのサポートがあります。

5. 要約チャンク（Summary chunking）

親文書ごとに、LLM で要約を生成し、要約を検索対象にする方式です。「マニュアル・規程・議事録のような長文で、質問と本文の距離が遠い」場合に有効です。要約はチャンクの「見出し」の役割を果たし、当たった要約に紐づく本文を LLM に渡します。要約生成のコストがかかるため、静的な文書向きです。

💡 ポイント 5 種類は排他ではありません。社内 RAG では、複数方式の併用が普通です。例えば「見出し・段落ベースで大きく分け、その中を固定長で分割する」「親子＋要約」といった組み合わせが実務的です。単一方式に固執せず、文書種別ごとに変える発想が有効です。

チャンクサイズ・オーバーラップ・セパレータの設計

チャンキング方式を決めたら、次はパラメータの設計です。3 つの主要パラメータがあります。

チャンクサイズ

200〜400 トークン程度：検索の粒度が細かく、精度が出やすい。ただし、文脈が薄いため、生成には親文書の並記が必要になることが多い
500〜1,000 トークン程度：バランス型。多くの実装のデフォルト。文脈もそこそこ保たれ、検索精度も出しやすい
1,000〜4,000 トークン程度：親子方式の「親」や、要約方式の親文書。LLM のコンテキストに直接渡すのに向く

社内 Wiki のような 1,000〜2,000 字の記事は 500〜800 トークン程度、規程・マニュアルの章単位なら 800〜1,500 トークン程度、議事録の発言単位なら 200〜400 トークン程度、といった目安が実務では使われます。

オーバーラップ

チャンクの終わりが次のチャンクの先頭と重なる範囲です。0〜100 トークン程度が典型的です。オーバーラップを持たせると、境界で切れた文の情報を隣のチャンクからも拾えるようになります。ただし、大きくしすぎるとチャンク数が増えて索引と検索のコストが上がります。

セパレータ

固定長で切るときに「どこで区切るか」の優先順位。多くの実装では「\n\n（段落）→ \n（改行）→ 。（文末）→ 空白」の優先順で切ります。日本語では句読点の扱いに気を配る必要があります。

Anthropic Contextual Retrieval——2024 年 9 月の重要アップデート

2024 年 9 月に Anthropic が公開した「Contextual Retrieval」は、チャンキング周辺の重要な改善策として広く注目されました。単純化すると、各チャンクの手前に「この文書全体の中で、このチャンクは何について述べているか」の短い説明を LLM で生成して付ける、という手法です。この文脈情報を付けたチャンクを索引化することで、検索精度が大幅に上がるという実験結果が示されました。

「1980 年、当社は横浜工場を新設した」というチャンクを、「当社の主要な生産拠点の沿革を述べる文脈で、」という説明を頭に付けて索引化する、といったイメージです。前後の文脈が失われがちなチャンクを救う技法として、社内 RAG でも有効です。

📖 もっと詳しく Contextual Retrieval は「チャンキング方式の刷新」ではなく、「既存のチャンキングに前処理を 1 段追加する」立ち位置です。ハイブリッド検索（次レッスン）と組み合わせることで、さらに効果が上がると Anthropic のブログでは示されています。実装コストは「チャンクごとに LLM 呼び出しが 1 回」で、社内 RAG の規模によっては現実的です。

埋め込みモデル選定 4 象限

チャンクを数値ベクトルに変換する「埋め込みモデル」は、RAG の検索精度を左右する要石です。選定は次の 4 象限で整理できます。

flowchart TB
  subgraph クローズドAPI [クローズド API]
    KA[OpenAI text-embedding-3-large<br/>Cohere embed<br/>Voyage AI<br/>Google Gemini Embedding<br/>Azure OpenAI]
  end
  subgraph OSSモデル [OSS モデル]
    OS[multilingual-e5<br/>bge-m3<br/>sup-simcse-ja<br/>ruri<br/>Instructor]
  end
  subgraph 多言語 [多言語対応]
    ML[Cohere embed-multilingual<br/>OpenAI text-embedding-3<br/>multilingual-e5<br/>bge-m3]
  end
  subgraph 日本語特化 [日本語特化 OSS]
    JA[cl-nagoya/sup-simcse-ja<br/>cl-tohoku/bert-base-japanese<br/>ruri]
  end

クローズド API（OpenAI・Cohere・Voyage・Google・Azure）

強み：セットアップが軽い、性能が高い、日本語も含めた多言語で安定した精度が出る
弱み：ネットワーク越しの呼び出しになるため、機密文書を外部に送る是非を法務・情シスと調整する必要がある。クオータ・料金設計が必要
典型用途：小〜中規模のパイロット、機密度が中程度の全社文書、素早く立ち上げたい社内案件

OSS モデル（multilingual-e5・bge-m3・sup-simcse-ja・ruri など）

強み：オンプレやプライベートクラウドで動かせる。機密度が高い文書でも取り扱える。長期コストが下げられる
弱み：モデルのホスティング（GPU・推論サーバー）が必要。運用の知見が要る
典型用途：金融・医療・防衛・機密度が高い法務や研究開発の社内文書、大規模で長期運用の RAG

多言語モデル vs 単言語モデル

社内文書が日本語中心なら、日本語特化の単言語モデルが精度で有利になることがあります。一方、社内文書に英語資料・多国籍拠点のドキュメントが混ざるなら、多言語モデルが総合的に扱いやすいです。「日本語だけなら日本語特化、混在なら多言語」が基本の判断軸です。

主要な日本語埋め込みモデル（OSS）

intfloat/multilingual-e5：多言語対応、日本語でも安定した精度。small・base・large の 3 サイズが用意され、次元数と精度のバランスで選べる
BAAI/bge-m3：多言語対応、密・疎ハイブリッドの表現が特徴
cl-nagoya/sup-simcse-ja：名古屋大学発、教師あり SimCSE ベースの日本語特化モデル。実務でよく使われる
cl-tohoku/bert-base-japanese：東北大学発、日本語 BERT の定番。埋め込みモデルとしても長く使われている
pkshatech/GLuCoSE-base-ja：PKSHA Technology 発、日本語検索特化
Ruri：日本語検索特化のモデルシリーズ

これらの精度は、HuggingFace の MTEB（Massive Text Embedding Benchmark）Leaderboard の日本語タスク（JMTEB など）で相互比較できます。数字はモデルの更新で変わるため、選定時点で最新を確認します。

⚠️ 注意 ベンチマーク上位のモデルが、社内文書で最も良い成績を出すとは限りません。社内文書のサンプルで比較評価するのが原則です。「MTEB で 1 位」と「社内 RAG で最も適する」は別問題です。評価方法はレッスン 6 で扱います。

次元数とストレージ・検索速度のトレードオフ

埋め込みモデルは、次元数（ベクトルの成分数）が異なります。384・768・1024・1536・3072 といった数値が典型です。

次元数が大きい：情報密度が高く、精度が出やすい。しかし、ストレージ消費が増え、検索速度が下がる
次元数が小さい：ストレージ消費が少なく、検索が速い。しかし、細かい意味の違いを捉えづらい

100 万チャンク × 1536 次元 × 4 バイト（float32）＝約 6GB になります。ここに ANN 索引（HNSW など）のオーバーヘッドが加わります。数千万〜億単位のチャンクを扱う場合、次元圧縮（PCA、Matryoshka Representation Learning のようなモデル固有の圧縮、あるいは量子化）が現実的な選択肢になります。

OpenAI の text-embedding-3-large は、Matryoshka の考え方を採り、次元数を後から縮められる設計になっています。ストレージ・速度・精度のバランスを、モデル選定後にも調整できるのが利点です。

再埋め込みコストを見積もる

埋め込みモデルを差し替えると、既存のチャンクをすべて再埋め込みしないと、モデル間のベクトル空間が違うため検索が壊れます。再埋め込みコストは、モデル選定段階から見積もっておく必要があります。

クローズド API の場合：1M トークンあたりの単価 × チャンク総トークン数、で算出。100 万チャンク × 500 トークン＝ 5 億トークン。単価が仮に $0.02／1M トークンなら $10 程度、$0.13／1M トークンなら $65 程度、といった規模感（2026 年 7 月時点の実際の単価はベンダー公式を参照）
OSS モデルの場合：GPU の時間単価 × 推論時間で算出。ローカル GPU での多くの日本語埋め込みモデルは、100 万チャンク程度なら数時間〜半日で処理可能

再埋め込みが必要になるのは、モデル更新・モデル切り替え・チャンキング方式の変更のときです。頻繁に起きるものではありませんが、「切り替え不能」に陥らないためのコスト見積もりは、初期設計時から意識してください。

中核メッセージの再確認

本レッスンで扱った内容を、中核メッセージに戻して整理します。

RAG の 8 割は LLM の外側で決まる——チャンキング方式と埋め込みモデル選定は、生成段階のプロンプトより検索精度に対して効きが大きい
検索の品質が生成の品質の天井を決める——不適切なチャンクや、社内文書に合わない埋め込みモデルは、その先の生成品質に必ず影を落とす
モデルは 3 か月・フレームワークは 1 年・社内文書は 10 年で動く——埋め込みモデルは 3 か月単位で変わっていくが、切り替えを見越したメタデータとチャンキング方針は、より長い時間軸で設計する

まとめ

チャンキングの目的は「コンテキスト長を超えない」「検索粒度を意味に揃える」「引用の粒度を作る」の 3 つ
5 種類（固定長・段落／見出し・セマンティック・親子・要約）を状況で使い分ける。単一方式にこだわらない
チャンクサイズは 500〜1,000 トークン程度が実務の中央値、社内文書の性質で調整する
Anthropic Contextual Retrieval は、既存チャンキングに前処理を 1 段追加して精度を上げる技法
埋め込みモデル選定は「クローズド API／OSS」「多言語／日本語特化」の 4 象限で整理する
日本語モデルは MTEB（JMTEB）の相互比較を出発点に、社内文書サンプルで最終選定する
次元数はストレージ・検索速度と精度のトレードオフ。Matryoshka 系の圧縮設計は柔軟性が高い
再埋め込みコストは選定段階から見積もっておく

次のレッスンでは、索引化したベクトルを実際に検索する側——ベクトル DB 選定、ハイブリッド検索（BM25＋ベクトル）、リランキング、メタデータフィルタの設計を扱います。

確認クイズ

このレッスンの内容の理解度をチェックしましょう。