チャンク化とAI検索
AIシステムがページを埋め込み、インデックス登録、検索取得のためにパッセージへ分割する方法を説明します。チャンクサイズ、重複、意味チャンク化、文脈プレフィックスとGoogleのパッセージランキングとの関係を扱います。
言語
チャンク化は、AIシステムが文書を埋め込みと検索取得の前に小さなパッセージへ分ける前処理です。AI検索で検索取得される単位はページではなくチャンクなので、インデックス登録だけでは足りず、特定のクエリに単独で答えるパッセージが必要です。サイズは精度と文脈のトレードオフで、重複は境界を守る一方トークンを重複させます。意味チャンク化が固定サイズより確実に優れるわけではなく、古い文脈プレフィックスは検索を誤らせます。Lost in the Middleは特定の2023年モデルとタスクで測定された位置効果です。特定サイズは最適化できませんが、明確な見出しの下で答えを先に置く自己完結セクションは、RAGとGoogleのパッセージ原理に沿います。
要点 — チャンク化は、AI検索エンジンがページを保存・検索する前に、ページを小さな断片へ切り分ける処理です。クエリはページ全体ではなく、最もよく答える1つのパッセージに照合されます。したがって、インデックス登録だけでは足りず、単独で意味を成し、質問に明確に答えるセクションが必要です。
チャンク化とは
チャンク化は、埋め込みと検索取得のシステム向けに文書を小さな単位へ分ける処理です。 Evidence for this claim Retrieval systems can split files into chunks that are embedded and indexed for later search. Scope: OpenAI's retrieval implementation; chunk sizes, overlap, and indexing behavior are implementation-dependent. Confidence: high · Verified: OpenAI: Retrieval guide チャンクサイズと重複は実装上の選択であり、最適値はコンテンツ、モデル、評価タスクによって変わります。 Evidence for this claim Retrieval-augmented generation combines a generator with retrieved external passages or documents. Scope: The original RAG research architecture; it does not establish one optimal chunking strategy for every production system. Confidence: high · Verified: Lewis et al.: Retrieval-Augmented Generation
従来のGoogle検索ではページが単位でした。ページがランキングされ、読者はクリックして移動します。AIシステムは異なります。ChatGPT、Perplexity、GoogleのAI Overviewsがコンテンツを使う前に、システムはそれをチャンクまたはパッセージと呼ばれる小さなセグメントに分け、個別に保存します。質問を受けると、最もよく一致するチャンクを探し、それらから回答を書きます。
つまり、検索取得の単位はページではありません。ページ内のパッセージです。
なぜ分割するのか
理由は2つあります。
- サイズ制限。 テキストを検索可能な数値に変換する埋め込みモデルは、一度に扱えるテキスト量に上限があります。5 000語のページは単一単位に収まらず、分割されます。
- 精度。 「technical SEO」全体を扱うページは、「what is crawl budget.」のような具体的な質問には曖昧な一致になります。クロールバジェットだけを扱う400語のセクションなら、鋭い一致になります。小さな単位なら、干し草の山ごと渡すのではなく、針を見つけられます。
これが意味すること
AIシステムがコンテンツをどのように切り分けるかは制御できず、制御する必要もありません。代わりに、各セクションが単独で抜き出されても意味を保つように書けます。
- 答えを先に置く。 前置きを3段落続けるのではなく、定義または主要な主張からセクションを始める。
- セクションを集中させる。 見出しごとに1つの話題または質問を扱う。
- 各セクションを自己完結させる。 周囲にある文章なしでこの段落だけ読んでも意味が通るか、自問する。
良い知らせは、これは明快な文章を書くことにほかなりません。Googleは、AIのためにコンテンツを小さな断片へ分ける必要はなく、システム側が分割すると明言しています。アドバンスト版では、チャンクサイズ、重複、研究、そしてこれがGoogleの「パッセージランキング」とどう結び付くかを扱います。
要点 — チャンク化は、文書を埋め込み、インデックス登録、検索取得する前にパッセージへ分ける前処理です。埋め込みモデルとコンテキストウィンドウにはトークン制限があり、ページ単位よりパッセージ単位の検索取得の方が精密です。検索取得の単位はページではなくチャンクです。 チャンクサイズはトレードオフで、小さいチャンクは正確ですが文脈が薄く、大きいチャンクは文脈が豊かですがノイズが増えます。チャンクサイズ、重複幅、分割器のどれも引用を保証しません。重複は境界を守る一方、インデックスサイズと重複を増やします。意味チャンク化が固定サイズより確実に優れるわけではありません。文脈プレフィックスはチャンクを明確にできますが、古いプレフィックスは検索を誤らせます。「Lost in the Middle」は特定の2023年モデルとタスクで測定された位置効果です。特定のチャンクサイズは最適化できず、Googleも小片への分割を試みるべきではないと述べていますが、明確な見出しの下で答えを先に置く自己完結セクションなら、RAGにもGoogleのパッセージランキングにもきれいに対応します。
チャンク化とは、なぜ存在するのか
検索システムはインデックス済みの単位を扱いますが、公開検索エンジンが、サイト運営者の制御できる共通のチャンクサイズを公開しているわけではありません。 Evidence for this claim Retrieval systems can split files into chunks that are embedded and indexed for later search. Scope: OpenAI's retrieval implementation; chunk sizes, overlap, and indexing behavior are implementation-dependent. Confidence: high · Verified: OpenAI: Retrieval guide RAG研究は検索してから生成するパターンを支持しますが、すべてのAI検索製品が同一の仕組みを使うことを証明するものではありません。 Evidence for this claim Retrieval-augmented generation combines a generator with retrieved external passages or documents. Scope: The original RAG research architecture; it does not establish one optimal chunking strategy for every production system. Confidence: high · Verified: Lewis et al.: Retrieval-Augmented Generation
チャンク化とは、文書をチャンクまたはパッセージという小さく独立したセグメントへ分け、埋め込みに変換し、ベクトルインデックスへ保存してから、クエリへの回答で検索取得する処理です。これはRAG(Retrieval-Augmented Generation)パイプラインの基礎であり、クエリ時ではなく取り込み時に起きるため、AI検索SEO担当者が見落としやすい工程です。
2つの問題がチャンク化を必要にします。
- トークン制限の問題。 埋め込みモデルは入力ごとに受け付けるトークン数に上限があります。Microsoftによれば、
text-embedding-3-smallモデルの上限は 8 191トークンで、他のモデルではさらに小さい場合があります。LLMのコンテキストウィンドウも有限です。5 000語の長いページは単一単位に収まらず、分割されます。 - 検索精度の問題。 「technical SEO」についての5 000語のページを1つのベクトルに押し込めると、平均化された曖昧なシグナルになります。「crawl budget」だけを扱う400語のセクションを独立したベクトルにすれば、長く複数テーマを含むページから関連する1つのパッセージを取り出せます。
ここから導かれる最も重要な考えは、AI検索で検索取得される単位はページではなくチャンクであるということです。クロールとインデックス登録は必要ですが、十分ではありません。特定のクエリに単独で明確に答えるチャンクが必要です。オーガニック検索で**#15のページでも、#1**の結果より抽出しやすいパッセージを持っていれば、AIの引用を獲得できます。
チャンク化の全体フロー
A four-stage flow begins with one long document containing several topics. The system splits and embeds focused passages as separate vectors. A query retrieves one or more best-matching passages, and those selected passages enter the model context for answer generation.
© Patrick Stox LLC · CC BY 4.0 ·
- 取り込みと分割。 AIクローラーがページをダウンロードし、チャンク化アルゴリズムが通常は重複を持つセグメントへ分けます。
- 埋め込み。 各チャンクを数値ベクトルに変換し、ベクトルインデックスへ保存します。これが埋め込みの工程です。
- 検索取得と生成。 クエリを埋め込み、ベクトル検索で最も近いチャンクベクトルを取得し、LLMへ渡して引用付きの回答を作ります。
このアーキテクチャ全体は、Karpukhinらの2020年のDense Passage Retrievalにさかのぼります。この研究は、上位20件のパッセージ精度で密ベクトル類似度が旧来のキーワード手法(BM25)を9–19%の絶対差で上回り、特定の質問に答えるには文書単位よりパッセージ単位の検索取得が有効だと示しました。Lewisらの2020年のRAG論文 がこのパターンを名付け、Wikipediaの100-word passages(100語のパッセージ)をチャンクとして使いました。ウェブコンテンツを検索取得するAI検索システムは、いずれもこのパイプラインの変種を実行しています。
チャンク化の戦略
単一のアルゴリズムはありません。システムは複数の方式から選び、時間とともに変更します。
単一のアルゴリズムはありません。システムは複数の方式から選び、時間とともに変更します。
- 固定サイズ — トークン数または文字数で分割し、一部を重複させる最も一般的な方式です。Microsoftの例は、“a fixed size sufficient for semantically meaningful paragraphs (for example, 200 words or 600 characters)” (翻訳)「意味的に意味のある段落を保てる十分な固定サイズ(例えば200語または600文字)」で、重複は10–15%です。
- 文/段落 — 任意のトークン数ではなく自然言語の境界で分け、意味単位を保ちます。
- 意味/内容認識 — 埋め込み類似度で文をまとめ、話題が変わる箇所で分割し、各チャンクを1つの話題に近づけます。
- 階層/再帰(RAPTOR) — 文書→セクション→段落という要約ツリーを作り、クエリに適した抽象度で答えられるようにします。Sarthiらの2024年のRAPTORは、GPT-4と組み合わせた難しいQAベンチマークで 20% absolute accuracy(絶対精度)の向上を報告しました。
- 重複付きスライディングウィンドウ — 隣接するチャンクでトークンを共有し、境界をまたぐ文が失われるのを防ぎます。
- 適応型/クエリ依存(Mix-of-Granularity) — 学習済みルーターがクエリごとにチャンクサイズを選びます。最も高度な方式ですが、商用システムではまだ標準ではありません。
チャンクサイズと重複 — 中心となるトレードオフ
これは誰もが尋ねるレバーですが、正直な答えは「状況による」です。
- 小さいチャンク(128–256トークン): 検索取得はより正確になりますが、答えに必要な周辺文脈を失うことがあります。
- 大きいチャンク(512–1 024トークン): 文脈を多く保てますが、検索取得がノイジーになり、関連箇所以外も一緒に取り込みます。
研究は単一の勝者を決めていません。LlamaIndexの評価では、その設定で1 024トークンが最適でした。Chromaのベンチマークでは200-tokenの再帰的分割器が指標全体で一貫していました。Ravi Thejaの結論は、“Identifying the best chunk size for a RAG system is as much about intuition as it is empirical evidence.” (翻訳)「RAGシステムに最適なチャンクサイズを特定することは、経験的証拠と同じくらい直感にも関わる」というものです。これらの数字は、1つのチームが、1つの文書集合、1つの埋め込みモデル、1つの評価タスクで得た結果であり、普遍的な設定ではありません。チャンクサイズ、重複幅、分割器のどれも、外部AIシステムでの検索取得、引用、ランキング、回答への採用を保証しません。 各プロバイダーのパイプラインが既定値を選び、予告なく変更できます。
重複は、この問題の過小評価されがちな半分です。重複がなければ境界付近の内容が分断されて失われます。Microsoftは、チャンク間の移行を滑らかにするために25%の重複から始めることを推奨し、他の資料は10–15%を提案しています。Microsoftの表現では、“smoother transitions between chunks without excessive duplication” (翻訳)「過度な重複なしにチャンク間をより滑らかに移行」できます。しかし重複は無料ではありません。重複トークンは二重に埋め込まれて保存されるため、インデックスが膨らみ、検索取得セット内にほぼ同じパッセージが隣り合って現れることがあります。原則ではなく、境界が事実を失わせる頻度と、インデックスサイズ・冗長性のコストを比較してください。実務上は、重要な事実をチャンク境界で切れやすい位置に埋めないことが大切です。
では、意味チャンク化は常に勝つのでしょうか。いいえ、そこが不都合な発見です。Vectaraの2024年の研究は、実世界の文書では “performance differences are minimal” (翻訳)「性能差は最小限」だとし、埋め込みモデルの品質の方がチャンク戦略より重要だと報告しました。GPT-4oが回答を生成した場合、方式間の差は “negligible” (翻訳)「無視できるほど小さい」ものでした。この結果は、Vectaraの文書集合、モデル、評価方法に固有のものです。意味チャンク化がどのパイプラインでも役立たないという証明ではなく、確実に勝つ既定値ではないという証拠です。SEO担当者にとっては、正確な構造に固執するより、コンテンツの品質と意味の明確さを重視する方が重要だということです。
チャンクの文脈:プレフィックスで直せること、直せないこと
人間には明確に読めるチャンクでも、周囲の文書から切り離されると検索でうまく扱われないことがあります。所属するセクション、実際に指しているエンティティ、2つ上の見出しで述べた条件が失われるためです。記録されている対策の1つが、埋め込み前に、文書タイトル、所属セクション、チャンクの主題を示す短いチャンク固有の文脈文字列を付ける方法です。Anthropicがcontextual retrievalと呼ぶこの方法なら、孤立したチャンクの曖昧さを減らし、文脈不足による検索漏れを抑えられます。
ただし、その修正自体にも失敗モードがあります。古い、または誤った文脈は役に立たないだけでなく、検索を誤ったチャンクへ積極的に誘導します。ページ再編後もセクションと一致しない見出しから作ったプレフィックスや、チャンクの範囲を誤って述べる文脈要約は、プレフィックスなしより悪い結果になります。文脈の保存は、追加して忘れればよい一方向の改善ではなく、固有のエラーを持つパイプライン設計上の選択です。
Googleのパッセージランキング — チャンク化のSEO上の祖先
Googleは「RAG」という言葉が広まるずっと前から、サブ文書の粒度を使ってきました。2020年のSearch OnでPrabhakar Raghavanはパッセージランキングを発表し、“By better understanding the relevancy of specific passages, not just the overall page, we can find that needle-in-a-haystack information you’re looking for.” (翻訳)「ページ全体だけでなく、特定パッセージの関連性をよりよく理解すれば、探している干し草の山から針のような情報を見つけられる」と述べました。これは米国英語でFebruary 10, 2021(2021年2月10日)に開始され、クエリのおよそ**7%**に影響します。
この仕組みについては2つの誤解があります。
この仕組みについては、2つの点が誤解されがちです。
- 「パッセージランキング」であり「パッセージインデックス登録」ではない。 Googleの最初の発表は「indexing」と表現しましたが、すぐに “this change doesn’t mean we’re indexing individual passages independently of pages.” (翻訳)「この変更は、ページとは独立して個々のパッセージをインデックス登録するという意味ではない」と訂正しました。ページは今も全体としてインデックス登録され、関連パッセージは追加のランキングシグナルです。
- ランキングされるのはページであり、パッセージではない。 John Muellerは、“Passage ranking is not about ranking a specific passage but understanding the content on a really long, not SEO optimized page, and ranking that page (not the passage) for a query where the passage is relevant.” (翻訳)「パッセージランキングは特定のパッセージをランキングするものではなく、とても長くSEO最適化されていないページの内容を理解し、そのパッセージが関連するクエリに対してページ(パッセージではない)をランキングするものだ」と説明しました。
パッセージランキングとRAGチャンク化は、特定のクエリに対して、ページではなく段落を照合するのが適切な場合があるという原理を共有します。しかし結果は異なります。パッセージランキングはページのランキングを引き上げ、RAGチャンク化は生成回答へ渡すチャンクを検索取得します。同じ考え方でも仕組みは別です。Dawn Andersonの報告によれば、技術的な基盤はDeepCTです。これはTF-IDFに代わるBERT由来の文脈的な用語重み付けであり、用語の出現頻度がそのまま関連性を意味するわけではなくなります。
「Lost in the Middle」— 答えの位置が重要
チャンクが検索取得された後も、LLMのコンテキスト内でどこに置かれるかが、モデルが実際に使うかどうかに影響します。Stanfordの「Lost in the Middle」研究(Liuら、2023年)は、“performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts.” (翻訳)「関連情報が入力コンテキストの最初または最後にあると性能が最も高く、長いコンテキストの中央にある関連情報へアクセスしなければならない場合に大きく低下する」と報告しました。
この結果を、すべてのモデルに既定で当てはまるものとして扱ってはいけません。これは、Liuらが2023年にテストした特定のモデル世代について、名前のある複数文書QAとキー・バリュー検索タスクで測定された位置効果です。現在のすべてのモデルがコンテキスト中央の証拠を無視するという証明ではありません。アーキテクチャ、実効コンテキストウィンドウの長さ、新しい学習方法によって効果は狭まることも広がることもあります。固定法則ではなく、設計で対処すべき文書化されたリスクとして扱ってください。
それでもコンテンツ上の含意は具体的で、リスクの低いものです。答えを先に置く。 各セクションの最初の文に定義、主要な発見、直接の答えを置き、4段落目まで埋めないでください。これは人間の流し読みを助ける答え先行(BLUF)の規律であり、同時に、効果が存在するモデルでコンテキストの中央に置かれて脱落するリスクを減らします。
見えない実務上の制約
- Chromeの約30パッセージ制限。 Dan Petrovicの研究では、ChromeのDocumentChunkerは約200語のパッセージでコンテンツを解析し、ページの最初の30パッセージだけを考慮するとされています。意味的なHTMLを上から下へたどるため、重要な内容は10 000語のページの末尾ではなく早い位置に置くべきです。
- チャンク化器は制御できない。 Despina Gavoyannis(Ahrefs)は、“You can’t control how Google, ChatGPT, or Perplexity chunk your content. Their pipelines change based on cost, model, and context.” (翻訳)「Google、ChatGPT、Perplexityがコンテンツをどうチャンク化するかは制御できない。パイプラインはコスト、モデル、コンテキストに応じて変わる」と率直に述べています。また、“Manual ‘chunk optimization’ is impossible in practice.” (翻訳)「手作業による『チャンク最適化』は実務上不可能」とも述べています。
「チャンク最適化」の実態とGoogleの注意点
Googleの2026年AI最適化ガイドは、誇張を省いて次のように述べています。“There’s no requirement to break your content into tiny pieces for AI to better understand it.” (翻訳)「AIがコンテンツをよりよく理解できるように、小さな断片へ分ける必要はありません。」同ガイドは、システムがページ上の複数の話題のニュアンスを理解し、関連する部分をユーザーに表示できるとも説明しています。“are able to understand the nuance of multiple topics on a page and show the relevant piece to users.” (翻訳)「ページ上の複数の話題のニュアンスを理解し、関連する部分をユーザーに表示できます。」したがって、コンテンツを一律の300語ブロックへ書き換えないでください。
しかし、これは構造が無関係だという意味ではありません。Gavoyannisの表現では、“Most SEOs using the term [chunk optimization] are just talking about good content structure.” (翻訳)「chunk optimizationという言葉を使うSEO担当者の多くは、単に優れたコンテンツ構造について話しているだけ」です。バズワードの新しさを膨らませているだけで、下にある助言は妥当です。Duane Forresterの言葉は変化をよく表しています。“If traditional SEO optimized for clicks, GenAI systems optimize for chunks… Structure still wins.” (翻訳)「従来のSEOがクリックを最適化したなら、GenAIシステムはチャンクを最適化する……それでも構造が勝つ。」
では何をするか。チャンク対応のコンテンツを書きます。
- セクションごとに1つの話題。 焦点の合ったH2/H3なら、一貫したチャンクへきれいに対応します。
- 答えを先に。 主張を先に置き、その下で根拠を示します。
- 自己完結したセクション。 単独で表示されてもこの段落が意味を成すか確認します。成さないなら、チャンクとして切り出されたときにも通じません。
- 適切な長さ。 主要セクションを200–500語にすると、256–512トークンのチャンクと自然に整合します。役に立つだけの完全さを保ち、人工的に短くしません。
- 構造化された形式。 表とリストはシステムが検出しやすい明示的な境界を作ります(Onelyの研究では、表が引用率を約2,5xに高めます)。
Mike Kingの表現が、安心材料として適切です。“chunking and writing for users is not mutually exclusive” (翻訳)「チャンク化とユーザー向けの文章作成は両立しないものではありません。」読者の流し読みを助ける構造は、チャンク化もきれいにします。人間を犠牲にしてロボット向けに最適化するのではなく、同じコンテンツを整えるのです。
パッセージランキングとRAGチャンク化 — 比較
| Googleのパッセージランキング | RAGチャンク化 | |
|---|---|---|
| 正体 | ランキングシグナル | 前処理ステップ |
| 粒度 | ページ内のパッセージ | 埋め込み前に分割したチャンク |
| 結果 | ページが上位になる | チャンクが回答へ検索される |
| 実行時点 | ランキング時 | 取り込み時、その後に検索取得 |
| 分割を制御できるか | いいえ | いいえ |
| 共有原理 | サブ文書の粒度。特定質問にはページより段落が一致しやすい | 同じ原理 |
パイプライン内の位置
チャンク化はAI検索取得の最初の動きです。chunk → embed → store → retrieve → generate(チャンク化→埋め込み→保存→検索取得→生成)という流れで進みます。各チャンクがベクトルになる埋め込みを経て、クエリが最も近いチャンクに一致するベクトル検索へ進み、検索取得されたチャンクが回答になるRAGへつながります。上流では、AIクローラーがコンテンツを最初に取り込む方法です。このパイプラインの従来検索版については、検索の仕組みを参照してください。
AI要約
Advanced版を短くまとめると、次のとおりです。
- チャンク化は文書をパッセージへ分ける処理。 埋め込み、インデックス登録、検索取得の前に行われるRAGパイプラインの最初の工程で、クエリ時ではなく取り込み時に起きます。
- 検索取得の単位はページではなくチャンク。 インデックス登録だけでは足りず、特定のクエリに単独で答えられるパッセージが必要です。オーガニック検索で**#15のページでも、パッセージがより抽出しやすければ#1**のページより引用されることがあります。
- なぜ必要か。 埋め込みモデルとコンテキストウィンドウにはトークン制限があり、パッセージ単位の検索取得はページ単位より精密です。
- チャンクサイズはトレードオフ。 小さいチャンク(128–256トークン)は正確ですが文脈が薄く、大きいチャンク(512–1 024トークン)は豊かですがノイズが多い。普遍的な最適値はなく、LlamaIndexは1 024、Chromaは200を最適としましたが、どのサイズも引用を保証しません。 **重複(10–25%)**は境界を守りますが、トークンを重複させてインデックスを膨らませるため、実際の境界損失と比較します。
- 意味チャンク化は固定サイズより確実に優れるわけではない。 Vectaraの2024年の研究(その研究のモデルと文書)では、チャンク戦略より埋め込みモデルの品質が重要でした。
- 文脈プレフィックス。 タイトルやセクションの系譜など、Anthropicの「contextual retrieval」は孤立チャンクを明確にできますが、古いまたは誤ったプレフィックスは検索を積極的に誤らせます。固有の失敗モードを持つ設計上の選択です。
- 「Lost in the Middle」(Liuら、2023年)。 名前のあるタスクと2023年当時のモデルで測定された位置効果であり、現在のすべてのモデルが中央の文脈を無視する証明ではありません。その研究のLLMは文脈の最初と最後を最もよく使ったため、各セクションを答えから始めます。
- Googleのパッセージランキング。 2020/2021年、クエリの約7%に影響した同じサブ文書原理ですが、パッセージを個別に登録するものではなく、ページをランキングするシグナルです。RAGチャンク化はチャンクを検索取得します。
- チャンクサイズは最適化できない。 Googleはコンテンツを小さな断片へ切る必要はないと述べています。できるのは、明確な見出しの下で、答えを先に置く、焦点の合った自己完結セクションを書くことです。それは単に良い構造です。
公式ドキュメント
パッセージ単位の検索取得とチャンク化に関する一次資料です。
- Google検索ランキングシステムのガイド — パッセージランキングを、ウェブページの個々のセクションまたは「パッセージ」を識別するために使う “an AI system we use to identify individual sections or ‘passages’ of a web page.” (翻訳)「ウェブページの個々のセクションまたは『パッセージ』を識別するために使うAIシステム」と定義します。
- 生成AI機能向けにウェブサイトを最適化する — コンテンツを小さな断片へ分ける必要はないというGoogleの立場(最終更新 2026年6月15日)を示します。
- Google検索の仕組みの詳細ガイド — このAI版が拡張する、クロール→インデックス→配信のパイプラインを説明します。
Microsoft / Azure AI Search
- ベクトル検索用に大規模文書をチャンク化する — 大手プロバイダーの中でも最も詳しい公式チャンク化ガイドです。チャンクサイズの既定値(512 tokens)、重複(開始点として25%)、固定・可変・意味方式の表を扱います(最終更新 2026年6月8日)。
OpenSearch
- テキストチャンク化 — ベクトル検索の取り込みパイプラインに組み込まれた機能としてのチャンク化を説明します。
実務者向け参照(ベンダードキュメント)
- Pinecone — チャンク化戦略 — 方式分類の基準となる資料です。中心となるテストは、“If the chunk of text makes sense without the surrounding context to a human, it will make sense to the language model as well.” (翻訳)「周囲の文脈なしで人間に意味が通るテキストチャンクなら、言語モデルにも意味が通る」というものです。
出典からの引用
Googleによる記録された発言です。各リンクは出典ページの引用箇所へ移動します。
Google — パッセージランキングとは何か、何ではないか
- “By better understanding the relevancy of specific passages, not just the overall page, we can find that needle-in-a-haystack information you’re looking for.” (翻訳)「ページ全体だけでなく、特定パッセージの関連性をよりよく理解すれば、探している干し草の山から針のような情報を見つけられる」 — Prabhakar Raghavan、Google SVP、2020年10月(Search Engine Land経由)。 引用へ移動
- “this change doesn’t mean we’re indexing individual passages independently of pages.” (翻訳)「この変更は、ページとは独立して個々のパッセージをインデックス登録するという意味ではない」 — Google、2020年10月20日の説明(Search Engine Land経由)。 引用へ移動
- “passage ranking launched yesterday afternoon Pacific Time for queries in the US in English.” (翻訳)「米国英語の検索クエリで、パッセージランキングは昨日の午後、太平洋時間に開始された」 — @searchliaison、2021年2月11日(Search Engine Land経由)。 報道を読む
Google — パッセージではなくページをランキングする
- “Passage ranking is not about ranking a specific passage but understanding the content on a really long, not SEO optimized page, and ranking that page (not the passage) for a query where the passage is relevant.” (翻訳)「パッセージランキングは特定のパッセージをランキングするものではなく、とても長くSEO最適化されていないページの内容を理解し、そのパッセージが関連するクエリに対してページ(パッセージではない)をランキングするものだ」 — John Mueller、Google Search Advocate(Search Engine Roundtable経由)。 報道を読む
Google — コンテンツをチャンク化すべきか
- “There’s no requirement to break your content into tiny pieces for AI to better understand it.” (翻訳)「AIがコンテンツをよりよく理解できるように、小さな断片へ分ける必要はない」 — Google Search Central、『生成AI機能向けにウェブサイトを最適化する』。 ガイドを読む
Microsoft Azure AI Search — チャンク化が必要な理由
- “Partitioning large documents into smaller chunks can help you stay under the maximum token input limits of chat completion and embedding models.” (翻訳)「大きな文書を小さなチャンクに分割すると、チャット補完モデルと埋め込みモデルの最大入力トークン制限内に収めやすくなる」 — Microsoft Azure AI Searchドキュメント。 ドキュメントを読む
チャンク化 — チートシート
チャンク化戦略の比較
| 戦略 | 分割方法 | 強み | 注意点 |
|---|---|---|---|
| 固定サイズ | トークン/文字数(例:512トークン) | 単純、速く、予測可能 | 重複がないと考えの途中で切れる |
| 文/段落 | 自然言語の境界 | 意味単位を保つ | チャンクサイズが可変で不均一 |
| 意味 | 埋め込み類似度で話題が変わる箇所 | 一貫したチャンク | 高コストで、Vectara 2024では常に優れるわけではない |
| 階層(RAPTOR) | 文書→セクション→段落の要約ツリー | 適切な抽象度で回答 | 構築が複雑 |
| スライディングウィンドウ | 固定チャンクを重複させる | 境界の文脈を守る | 一部の重複 |
| 適応型(Mix-of-Granularity) | ルーターがクエリごとにサイズを選ぶ | 最も柔軟 | 本番システムでは標準ではない |
チャンクサイズ早見表
| サイズ | トークン | 挙動 |
|---|---|---|
| 小 | 128–256 | 正確な検索取得だが、文脈が薄い |
| 中 | 512 | 一般的な既定値(Microsoftの開始点) |
| 大 | 1 024 | 文脈が豊かだがノイズが多い(LlamaIndexのテストで最適) |
| 重複 | 10–25% | 境界での欠落を防ぐ(Microsoftは25%から開始) |
早わかり
- AI検索で検索取得される単位はページではなくチャンクです。
- 埋め込みモデルの上限の例:
text-embedding-3-small= 8 191 tokens(8 191トークン)。 - チャンクサイズ、重複幅、分割器は、検索取得、引用、ランキング、AI回答への採用を保証しません。それらはパイプラインの既定値であり、普遍的な設定ではありません。
- 重複は無料ではありません。重複トークンは二重に保存されるため、インデックスを膨らませ、ほぼ同じパッセージが検索取得されるリスクを高めます。
- 文脈プレフィックス(タイトル、セクションの系譜)はチャンクを明確にできますが、古い、または誤ったプレフィックスは助けるどころか検索を誤らせます。
- 「Lost in the Middle」:2023年の研究対象のタスクとモデルでは、LLMはコンテキストのstart and end(開始と終了)を最もよく使いました。モデルにかかわらず、答えを先に置きます。
- ChromeのDocumentChunkerは、ページあたり最初の約30 passages(約200 wordsずつ)だけを考慮すると報告されています。重要な内容を早く置きます。
- Google:passage ranking ≠ passage indexing。ランキングされるのはページで、パッセージはシグナルです。
- Google:AIのためにコンテンツを小片へ分ける必要はありません。断片化ではなく構造化します。
メンタルモデル
1. 検索取得パイプライン — chunk → embed → store → retrieve → generate。 チャンク化が最初の工程です。コンテンツが引用されないなら、クロールされたか、一貫したチャンクが作られたか、そのチャンクがクエリに一致したか、LLMが使う位置に入ったかを順に確認します。
2. 単位はページではなくチャンク。 「is my page indexed?(ページはインデックス登録されたか)」と考えるのをやめ、“does my page contain a passage that answers this specific query, on its own?” (翻訳)「このページには、特定のクエリに単独で答えるパッセージがあるか」と考えます。インデックス登録は必要ですが、引用を勝ち取るのは抽出可能性です。
3. サイズのトレードオフ — 精度と文脈。 小さいチャンクは鋭いが薄く、大きいチャンクは豊かだがノイズが多い。普遍的な答えはなく、しかもサイズを設定するのはあなたではありません。だから、実際に制御できるもの、つまりどちらの粒度でも機能する一貫したセクションを最適化します。
4. 答えを先に置くことは中央より強い。 「Lost in the Middle」は、コンテキストウィンドウ内の位置が重要だと示します。各セクションを定義または主張から始めることで、読者の要点が、効果が存在するモデルの死角へ入らないようにします。
5. 分断せず構造化する。 Googleはコンテンツを小さな断片へ切る必要はないと述べています。人工的なチャンク化ではなく、明確な見出し階層、セクションごとの1テーマ、自己完結した段落を使います。「チャンク最適化」は、ほとんどの場合、新しい名前で呼んだ良い構造にすぎません。
6. パッセージランキングとRAGチャンク化は別物。 サブ文書粒度という原理は同じですが、結果が異なります。パッセージランキングはページをランキングするシグナルで、RAGチャンク化はチャンクを回答へ検索取得します。SEO時代の概念とAI時代の概念を混同しないでください。
チャンク対応コンテンツのチェックリスト
コンテンツを分割され、検索取得され、文脈から切り出されて引用されても耐えられるようにするための確認です。
- 各H2/H3セクションは1つの話題または質問を扱う。2つを1つに詰め込まない。
- 各セクションは答えから始まる(定義または主要な主張を先に置き、根拠を下に置く)。第3〜4段落まで埋めない。
- 各主要セクションは自己完結している。周囲にあるものがなくても意味が通る。
- セクションは適切な長さ(約200–500語)で、完全であり、人工的に小さく切っていない。
- 最も重要な内容をページの早い位置に置く(Chromeは最初の約30パッセージだけを考慮すると報告されている)。
- 見出し階層を整える(論理的なH1→H2→H3)。これはチャンク化器がたどる構造シグナルの一部です。
- 一緒に保つべき事実を、起こりそうな境界をまたいで分断しない(例えば、主張を1段落、根拠を3段落後に置かない)。
- 本当にリスト状の内容には表/リストを使う(チャンク化器が検出する明示的な境界で、引用率が高くなることがあります)。
- すべてを硬い語数ブロックへ書き換えていない。Googleはそれを求めていません。
複数の意図を1つの巨大セクションに詰める
定義、実装、例外、測定を1つの長いブロックに詰めると、ページとしては便利でも、検索取得されたパッセージにはノイズになります。異なる質問を見出しで分け、各セクションに単独で通じるだけの局所的な文脈を与えてください。
すべての文を個別の見出しにする
小さすぎるチャンクは、条件や文章同士の関係を失うことがあります。想像上のトークン数に合わせて最適化せず、完全な考え、その制約、支える根拠を一緒に保ってください。
文脈のない前方参照で始める
「this,」「it,」「however」で始まるパッセージは、主題を示す文章から切り離されることがあります。重要なセクションは、トピックと答えを特定する直接的な文で始めてください。
重複を強制するために本文を複製する
繰り返した段落は、競合するほぼ同一のパッセージを作り、読書体験を悪化させます。検索システムは内部で重複を追加できます。著者は本文をコピーするのではなく、明確なつなぎと自己完結したセクションを使うべきです。
プロンプト:パッセージの独立性を監査する
Review the article section by section as if each section could be retrieved without its
neighbors. For each heading, state the question it answers, whether the opening sentence
names the subject, what context is missing, whether unrelated intents are mixed, and the
smallest edit that makes the section self-contained. Preserve necessary qualifications
and evidence. Do not target an arbitrary token count or rewrite the author's voice.
Article:
[PASTE ARTICLE WITH HEADINGS]プロンプト:過密なセクションを分割する
This section covers several ideas. Propose a minimal heading structure that groups one
complete intent per section. For each proposed section, write only an answer-first
opening sentence and list which existing paragraphs belong under it. Do not add facts,
remove caveats, duplicate prose, or turn every sentence into a heading.
Section:
[PASTE HEADING AND CONTENT] DevTools Console:長いレンダリングセクションを検出する
記事ページで実行します。文字数しきい値はレビュー補助であり、検索エンジンのチャンク境界ではありません。
console.table([...document.querySelectorAll('main h2, main h3')].map((heading, i, all) => {
let text = '';
for (let node = heading.nextElementSibling; node && !all.includes(node); node = node.nextElementSibling) text += ` ${node.textContent}`;
return { heading: heading.textContent.trim(), characters: text.trim().length };
}).filter(row => row.characters > 2000));Markdownで文脈のないセクション開始を探す正規表現
この複数行パターンは、最初の文章語が一般的な前方参照になっている見出しを検出します。各ヒットを手動で確認します。
^#{2,4}\s+.+\n+(?:\n|>.*\n|\s*)*(This|That|It|They|These|Those|However|Therefore|Also|And|But|So|Then)\b パッセージ品質保証のツール
- ブラウザーのアウトラインまたは文書マップを使うと、無関係な質問を結合した見出しや、長いあいだ小見出しのない区間をすぐに見つけられます。
- ベクトルデータベースや埋め込みプレイグラウンドは、管理された検索テストでチャンクサイズの影響を示せます。ただし、1つのモデルの結果を普遍的なSEO処方へ変えてはいけません。
- Search Consoleと引用追跡はページの結果を測定します。検索プラットフォームが保存した正確な独自チャンクを知ることはできません。
チャンク化向けの書き換えを検証する
| 実行するテスト | 期待結果 | 失敗の解釈 | 監視期間 | ロールバック条件 |
|---|---|---|---|---|
| 隣接部分なしで各編集セクションを読む | 見出しと冒頭が話題と答えを示す | パッセージが欠落文脈に依存 | 編集レビュー | 条件や主題が失われたら文脈を戻す |
| 前後の主張と引用を比較 | 事実、注意点、出典関係が保たれる | 構造編集で意味が変わった | 公開前 | 根拠のない拡張を戻す |
| 旧版と新版をChunk Testerで実行 | 長い、ぶら下がったセクションが人工的分断なしに改善 | 理解ではなくスコアを最適化 | 公開前 | 読みやすさや完全性が悪化したら戻す |
| 小さな版管理済み検索セットをテスト | 意図した質問に関連セクションが検索され例外も失わない | 分割が薄すぎる、または意図混在が残る | 管理システムで公開後 | 重要文脈が繰り返し消えるなら結合または再分割 |
| レンダリング見出し階層を確認 | 見出しが順序、説明、アクセシビリティを保つ | マークアップ変更で文書構造が壊れた | リリースQA | 見出しが利用不能または不正なら戻す |
自分で確認:チャンク化
時間を使う価値のあるリソース
私の関連執筆
- LLM検索の最適化について実際に分かっていること — ChromeのDocumentChunkerが約30パッセージを調べるという知見と、AI検索がコンテンツを実際にどう検索取得するかを扱います。
基礎研究
- Dense Passage Retrieval(Karpukhinら、2020年) — 密なパッセージ検索がキーワード照合を上回る理由と、現代のRAGの基盤となるアーキテクチャを説明します。
- Retrieval-Augmented Generation(Lewisら、2020年) — RAGという名前を付けた論文で、チャンクとして100-wordのWikipediaパッセージを使いました。
- Lost in the Middle(Liuら、2023年) — LLMがコンテキストの最初と最後を最もよく使うことと、答えを先に置く理由を示します。
- RAPTOR(Sarthiら、2024年) — 要約ツリーによる階層的・再帰的なチャンク化を扱います。
- 意味チャンク化はコストに見合うか(Vectara、2024年) — 意味チャンク化が固定サイズより確実に優れるわけではないという研究です。
SEO側からの反論(読むべき資料)
- SEOのチャンク最適化は過大評価されている(Despina Gavoyannis、Ahrefs) — 「チャンク最適化」はほとんど単なる優れたコンテンツ構造であり、システムがどうチャンク化するかは制御できないという主張です。このテーマで最も重要な注意点を扱います。
実務者向けガイド
- Pinecone — チャンク化戦略 — 方式分類の基準となる資料です。
- LlamaIndex — RAGシステムの理想的なチャンクサイズを評価する(Ravi Theja) — 128/256/512/1 024/2 048を比較し、1 024に到達したテストを説明します。
- Databricks — RAGのチャンク化戦略 — ドメイン固有の指針を含む6つの方式を扱います。
業界の資料
- コンテンツチャンク化ガイド(Search Engine Land) — 定義、UXに由来する背景、マクロ/マイクロ/アトミックなチャンク、チャンク化とAI検索の接続を扱います。
- チャンク化、引用、明確化、構築(Benu Aggarwal、Search Engine Land) — AI検索向けの4段階コンテンツフレームワークで、“content now competes in a probability-weighted lottery of answer generation.” (翻訳)「コンテンツは今や、確率で重み付けされた回答生成のくじで競争している」と表現します。
- コンテンツチャンク化:それは何で、気にすべきか(Semrush) — Mike Kingの “chunking and writing for users is not mutually exclusive” (翻訳)「チャンク化とユーザー向けの文章作成は両立しないものではない」という引用と、Q&A形式のテストを含む実務者向けの概要です。
- チャンク化、検索取得、統合(Duane Forrester) — 大きなコンテキストウィンドウでも構造が勝つ理由を元Bing担当者の視点で説明し、“If traditional SEO optimized for clicks, GenAI systems optimize for chunks.” (翻訳)「従来のSEOがクリックを最適化したなら、GenAIシステムはチャンクを最適化する」と述べます。
- LLMに適したコンテンツ(Onely/Bartosz Góralewicz) — 表が引用率を2,5x高めるという知見と、リスト記事がAI引用上位の**50%**を占めるという統計の一次資料です。
- 2025年AI引用・LLM可視性レポート(The Digital Bloom) — ブランド検索量、統計、引用が可視性を高めることを示すLLM引用データです。
- チャンク化戦略の究極ガイド(Agenta.ai) — チャンク化方式の包括的な開発者向け分類と、方式別のChromaベンチマークデータを扱います。
引用する価値のある統計
- 9–19% absolute(絶対差) — Karpukhinらの2020年研究で、密なパッセージ検索(DPR)がBM25キーワード照合を上位20パッセージ精度で上回った差です。意味で検索する根拠になります。Karpukhin et al., 2020
- ~7% of queries(クエリの約7%) — Googleのパッセージランキングが全面展開時に影響するとされた検索クエリの割合です(米国英語では2021年2月10日に開始)。報道
- +20% absolute accuracy(絶対精度+20%) — GPT-4と組み合わせた難しいQAベンチマークでのRAPTORの階層チャンク化の向上です。Sarthi et al., 2024
- Embedding model > chunking strategy(埋め込みモデル>チャンク戦略) — Vectaraが2024年に、意味方式か固定サイズかよりモデル品質が検索取得へ大きく影響し、実文書での差は “minimal” (翻訳)「最小限」だったと報告しました。研究
- First ~30 passages(最初の約30パッセージ) — Dan Petrovicの研究による、ChromeのDocumentChunkerがページごとに考慮すると報告された数(各約200 words)。重要な内容を先に置く根拠です。Ahrefs経由
- ~2,5x citation rate(引用率約2,5倍) — Onelyが、表によってAI引用率が上がり、リスト記事がAI引用上位の約**50%**を占めると報告した結果です。構造が役立ちます。Onely
- 93,67% of Google AI Overviews(Google AI Overviewsの93,67%) — 少なくとも1つの上位10件オーガニック結果を引用した割合です。オーガニックランキングとAI引用の強い相関を示しますが、絶対的な相関ではなく、パッセージレベルの一致が順位を上回ることがあります。The Digital Bloom、2025 AI Citation Report
変更履歴
2026年8月22日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年8月8日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年7月18日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。