【備忘録】Data 360のChunkingをざっくり理解する - Agentforce/RAG時代のSearch Index設計メモ

はじめに

Salesforceの公式Blogに、Data 360におけるChunking（チャンク分割）の記事が出ていて、これはおもろそうだなと思ったので整理します。

この記事は、「Chunkingとは何か」だけではなく、Data 360でSearch Indexを作り、RetrieverやPrompt Builder、Agentforceに文書コンテキストを渡す前に何を考えるべきかをまとめる備忘録です。

先に結論を書くと、Chunkingは「AIを賢くする魔法」ではありません。どちらかというと、AIが検索・参照しやすい単位に文書を分ける設計です。

同じPDFやHTMLを取り込んでも、分割の単位が悪いと、検索結果が「途中から始まる説明」や「複数トピックが混ざった断片」になりやすいです。逆に、質問に答えられる単位で文脈を保てていると、RetrieverやAgentforceに渡す材料として扱いやすくなります。

注: 本記事は2026-08-29時点で確認できたSalesforce公式Blog / Salesforce Developers Docs / Salesforce Helpの記述をもとにした整理です。筆者環境でData 360のSearch Indexを実際に作成・検証したものではありません。Edition、権限、提供条件、日本国内での利用可否は、公開前・導入前に必ず公式Docsと契約内容を確認してください。

この記事で整理すること

• Data 360におけるChunkingの位置づけ
• Chunkingを「回答可能な単位」として考える理由
• Search Index / Retriever / Prompt Builder / Agentforceとの関係
• 良いChunkと悪いChunkのイメージ
• Data Explorerで確認すべき観点
• 実装・検証前のチェックリスト

まずData 360とChunkingの関係をざっくり見る

SalesforceのData 360は、以前のData Cloudを含むデータ基盤として説明されています。公式製品ページでも「Data 360 (Formerly Data Cloud)」という表現が使われています。

今回のテーマであるChunkingは、特にPDF、HTML、FAQ、マニュアル、ナレッジ記事などの非構造化データをAI活用しやすくする文脈で重要になります。

なお、Chunkingの対象は「取り込んだファイル」だけではありません。Unstructured Data Model Object（UDMO）に加えて、テキスト項目を持つ通常のDMOもChunkingの対象になります（Salesforce Knowledge記事などが例として挙げられています）。「PDFを入れるための機能」と捉えると対象範囲を見誤るので、ここは押さえておきたいところです。

ざっくり流れにすると、次のようなイメージです。

PDF / HTML / FAQ / マニュアル
      ↓
Data 360への取り込み
      ↓
Parsing（文書構造の解釈）
      ↓
Chunking（検索・回答に使いやすい単位へ分割）
      ↓
Embedding / Vectorization
      ↓
Search Index
      ↓
Retriever
      ↓
Prompt Builder / Agentforce

なお、Search Index には vector search と hybrid search の2種類があります。hybrid search は意味的な近さとキーワードの両方で拾う構成です。Chunkの設計を考えるときは、「どちらの索引に載せるのか」も一緒に見ておくと判断しやすくなります。

ここで大事なのは、Chunkingは単体で完結する処理ではないという点です。

Chunkingの結果はSearch Indexに入り、Retrieverの検索結果として使われ、最終的にPrompt BuilderやAgentforceが参照する文脈になります。つまり、Chunkingの設計は後段のAI体験にそのまま影響します。

Chunkingは「文書を短くする作業」ではない

Chunkingという言葉だけを見ると、「長い文書を小さく分けること」と理解しがちです。

もちろん分割はします。ただ、Data 360 × AI活用の文脈では、単に短くするだけでは足りません。

自分の理解では、Chunkingで考えるべき単位は、回答可能な単位です。

これは個人的な言い換えというだけではありません。公式Blogでも、有用なChunkとは「解釈に必要な文脈を失わずに、意味のある質問に答えられる一節」として説明されています。つまり「何文字か」ではなく「単体で問いに答えられるか」が基準になります。

たとえば、ある製品マニュアルに次のような情報があるとします。

• 製品名
• 対象バージョン
• エラーコード
• 対処手順
• 注意事項
• 参照元ページ

このとき、エラーの対処手順だけが切り出されて、製品名や対象バージョンが別Chunkに分かれてしまうと、検索結果としては不完全になります。

一方で、製品Aと製品Bの説明、料金、制限事項が1つのChunkに混ざると、今度は余計な情報が多くなります。

悪い例:
[製品Aの概要 + 製品Bの価格 + 注意事項の途中]

良い例:
[製品Aの概要 + 対象条件 + 注意点]
[製品Bの概要 + 対象条件 + 注意点]

Salesforce公式Blogでも、同じ文書を取り込んでもAI応答が変わる理由として、モデルそのものだけでなく、コンテンツがどのように解析・分割・補強・インデックス化・検索されるかが重要だと説明されています。

Chunkingで見たい観点

1. Chunkは質問に答えられる単位か

まず見るべきなのは、Chunk単体で意味が通るかです。

たとえば、社内FAQを取り込む場合、質問文と回答文が別々のChunkに分かれてしまうと、Retrieverが回答だけを拾ったときに何の回答なのか分かりにくくなります。

逆に、FAQの1問1答がまとまっていれば、検索結果として使いやすくなります。

見るポイントは次のようなものです。

• 見出しと本文が一緒に残っているか
• 製品名、プラン名、対象条件が落ちていないか
• 手順の前提条件と実行手順が分断されていないか
• 注意事項だけが単独で出ていないか
• 複数テーマが1つのChunkに混ざりすぎていないか

2. Chunkにメタデータがあるか

Chunkの本文だけではなく、メタデータも重要です。

Salesforce公式Blogでは、検索インデックスやRetriever設定に適切なフィールドを含めることで、似たような文章の区別、検索の絞り込み、トレーサビリティ維持に役立つと説明されています。

たとえば、次のような情報です。

• 文書タイトル
• セクションタイトル
• URLまたはファイルパス
• ページ番号
• 製品、地域、カテゴリ
• 公開日、適用日、更新日
• 議事録や動画文字起こしなら発話者・タイムスタンプ

ここで実務的に効くのが、項目を「索引対象のテキスト」として入れるか、「各Chunkの先頭に付ける」かの使い分けです。公式の説明では、既定でUDMOのテキスト項目が索引対象として選ばれる一方、1語〜数語しか入っていない項目は索引テキストとしては効きにくく、むしろ各Chunkの先頭に付ける（prepend）ほうが検索結果の改善につながるとされています。製品名やカテゴリのような短い項目は、後者で扱うイメージです。

AI回答を業務で使うなら、「どこに書いてあったか」を戻れることはかなり重要です。

特にAgentforceのような業務文脈では、回答本文だけでなく、参照元や根拠を確認できる設計にしておかないと、運用時の不安が残ります。

3. Chunkサイズと重複は目的に合っているか

Chunkが小さすぎると文脈が欠けます。大きすぎると余計な情報が混ざります。

公式Blogでは、情報がChunk境界をまたぐ場合、Chunkの境界を少し重ねることが役立つ場合がある一方、重ねすぎると冗長な結果を生む可能性がある、と説明されています。

ここは「このサイズが正解」と決め打ちするより、実際の質問で検証する方が現実的です。ただし、まったくの手探りで始める必要はありません。次のセクションで、実際に触れる設定項目と、公式に示されている出発点を整理します。

実際に設定できる項目を知っておく

「Chunkingを設計する」と言っても、任意のロジックを最初から書くわけではありません。Search Index の詳細設定で触れる項目は、おおむね次の範囲です。

設定項目	何を決めるか
parsing	文書構造をどう解釈するか
chunking（strategy）	どの単位で区切るか
overlap	Chunk境界をどれだけ重ねるか
prepended fields	各Chunkの先頭に何を付けるか（タイトルなど）
filtering fields	検索時の絞り込みに使う項目
vectorization	どの埋め込みモデルを使うか

前のセクションで書いた「メタデータを残す」は、独立した作業ではなく prepended fields / filtering fields として設定に現れます。

組み込みの chunking strategy がある

Search Index の Advanced Setup には組み込みの chunking strategy が用意されていて、公式Blogでは section-aware chunking と passage extraction が、多くのケースでうまく機能する組み込み方式として挙げられています。

このうち passage extraction は、さらに次の2つが説明されています。

• semantic-based passage extraction: HTMLタグが持つ意味を使って区切る。見出し、リスト、太字などが論理的な境界として働く
• window-based passage extraction: div や p のようなブロック要素、または改行で区切られた素のテキストを使って区切る。段落にHTMLが含まれない場合は文単位で抽出される

「見出しと本文を一緒に残したい」という要望は、実は section-aware や semantic-based を選ぶかどうかの話とかなり重なります。HTMLの構造が素直な文書なら、strategy の選択だけで解決することもあります。

逆に言うと、Custom Chunking に手を出す前に、組み込みの strategy を選び直すという手段があるということです。

Max Token は埋め込みモデルとセットで決める

Max Token について、まず押さえておきたいのは既定値と構成例の値は別物という点です。

• Salesforce Help では、Max Token の既定値として 512 が説明されている
• 1,200 は、Salesforce Developers の「自社WebサイトをAgentforceでgroundingする」構成例で使われている値（後述）

つまり 1,200 は「一般的な推奨値」ではなく、特定の構成例の値です。ここを取り違えると、そのまま社内標準にしてしまいます。

そのうえで、値を動かすときに効いてくるのが埋め込みモデルとの対応です。構成例で 1,200 が使われているのは、同じ構成で選ばれている Salesforce Embedding V2 Small がそのChunkサイズをサポートしているからで、公式も小さいChunkサイズ（512 など）を選ぶならサポートするシーケンス長の短いモデルを使うと説明しています。

つまり Max Token は単独で決める値ではなく、vectorization（どの埋め込みモデルを使うか）とセットで決める値です。「とりあえず大きく／小さく」だけで動かすと、モデル側の想定と噛み合わなくなります。

出発点として示されている構成

自社サイトを対象にした grounding の手順では、次の組み合わせが例として示されています。

• section-aware chunking
• maximum tokens（1,200）
• overlap はゼロ
• title prepending（タイトルを先頭に付ける）
• Salesforce Embedding V2 Small

ここで注目したいのは、overlap がゼロである点です。前のセクションで「境界を少し重ねると役立つ場合がある」と書きましたが、重ねることが常に前提というわけではありません。まずゼロで始めて、境界をまたぐ情報が実際に問題になったときに足す、という順番のほうが素直です。

ただし、この組み合わせはあくまで特定のユースケースの例であって、万能の既定値ではありません。適切な選択は、コンテンツの性質、想定する質問、選んだ埋め込みモデルによって変わります。

設定は「全部回す」ものではない

もうひとつ、公式Blogが書いている進め方が個人的にはかなり実務的でした。要点だけ日本語にすると、目的は使えるすべての設定を調整することではなく、観測された検索の問題に対応する設定を変えること、という趣旨です。

順番としては、何をもって「良い検索結果」とするかを先に決め、生成されたコンテキストを実際に見て、必要なときに設定を直す、という流れです。設定項目が6つあると全部いじりたくなりますが、問題と設定を1対1で対応させるほうが、結果の切り分けができます。

Custom Chunkingは最初から使うものではなく、問題が見えたら検討するもの

Salesforce Developers Docsには、Data 360 Code Extension Guideの中に、Custom Chunking Functionの検証手順が用意されています。

公式Blogの説明では、Data 360 Code Extension を使うと独自のChunking処理を書くことができ、Custom Function は、ベクトル化・インデックス化の前に、文書の要素と利用可能なメタデータを受け取ります。つまり「分割の境界」だけでなく、「どのメタデータを一緒に持たせるか」もコード側で決められる、という位置づけです。

公式Docsの「Verify Custom Chunking Results」では、Search Indexが実行されてReadyになったあと、Custom Chunking Functionが期待したChunkを生成したか確認する流れが説明されています。

ここで重要なのは、Custom Chunkingは「なんとなく高度そうだから使う」ものではないということです。

まずは標準的な構成やIntelligent Contextのような初期設定でSearch Indexを作り、実際の質問に対して次のような問題が出るかを見ます。

• 見出しと本文が分かれてしまう
• 表や箇条書きの意味が崩れる
• 1つの製品説明に別製品の説明が混ざる
• FAQの質問と回答が分断される
• 引用元やページ番号が追いにくい

こうした問題が具体的に見えたときに、Custom Chunking Functionで境界や文脈保持のルールを調整する、という順番がよさそうです。

Custom Chunkingを使った場合にData Explorerで何を確認するか

この節で追うのは、公式Docsの「Verify Custom Chunking Results」＝Custom Chunking Functionを使った場合の検証手順です。 確認先が Chunk Data Model Object になるのはそのためで、たとえば自社Webサイトを対象にした grounding の手順では、Data Explorer の Data Lake Object 側を見る流れが案内されています。どの手順書に沿っているかで見に行く先が変わるので、そこだけ先に断っておきます。

公式Docsに沿うと、確認の流れは概ね次のようになります。

Search Indexを作成・実行
      ↓
Last Run Status が Ready か確認
      ↓
Search Indexレコードで Chunk Data Model Object 名を確認
      ↓
Data Explorerで対象Data Space / Data Model Objectを選択
      ↓
Chunkのtext / sequence number / citationを確認
      ↓
RetrieverやPrompt Builderで検索・回答を確認
      ↓
必要ならChunking設定や対象フィールドを調整

公式Docsの手順に沿うと、Data Explorer での操作は具体的に次のようになります。

1. Search Index のレコードを開き、ページに表示されている Chunk Data Model Object 名を控える
2. Data Cloud から Data Explorer を開く
3. 対象の Data Space を選ぶ
4. Object のドロップダウンで Data Model Object を選ぶ
5. Select an Object で、控えた chunk data model object を選ぶ
6. Data 360 が生成した Chunk の一覧が表示される

なお、Chunkの格納先になるこのオブジェクトは chunk data model object（CDMO） と呼ばれ、元のDMO / UDMOから作られます。「Chunkはどこに行ったのか」を追うときは、この名前で探すことになります。

前提として、そのSearch IndexがCustom Chunking Functionを使っていて、かつ Last Run Status が Ready になっている必要があります。

確認観点を表にすると、こんな感じです。

観点	見ること
text	Chunk本文が途中で切れすぎていないか。質問に答えられる単位か
sequence number	元文書内の順序が追えるか
citation	参照元に戻れる情報が残っているか
context	見出し、製品名、対象条件などが本文と一緒に残っているか
ingestion	そもそも対象文書が正しく取り込まれているか

公式Docsには、より踏み込んだ書き方があります。Chunkingは、そのSearch Indexで選んだソースに正常に取り込まれたコンテンツに対してのみ実行される、というものです。したがって、ある文書からChunkが1つも出てこない場合は、Search Indexが走る前に、その文書がそのデータソースへ正しくアップロード・取り込みされていたかを先に確認することになります。

これは地味ですがかなり大事です。Chunking設定を疑う前に、まず元データがSearch Indexの対象として正しく取り込まれているかを見るべきです。

Retriever / Prompt Builderで見ること

Data ExplorerでChunkの中身を見ただけでは、まだ十分ではありません。

最終的にはRetrieverやPrompt Builderで、実際の質問に対して期待する文脈が取得されるかを確認します。

たとえば、次のようなテスト質問を用意しておくとよさそうです。

• 製品AでエラーE001が出た場合の対処方法は？
• プランBで利用できない機能は？
• 2026年4月以降に適用される制限は？
• この手順を実行する前の前提条件は？
• 参照元ページを確認できるか？

ここで見るべきなのは、「それっぽい回答が返るか」だけではありません。

• Retrieverが正しいChunkを拾っているか
• 回答に必要な前提条件が含まれているか
• 不要な別製品・別地域・旧版の情報が混ざっていないか
• 引用元をたどれるか
• 質問を少し変えても安定して関連Chunkが出るか

このあたりを見ておくと、Chunkingを「設定項目」ではなく「検索品質の設計」として扱いやすくなります。

個人的な設計メモ

ここからは公式Docsそのものというより、自分が記事を書くならこう考える、という整理です。

ChunkingはRAGの前処理ではなく、業務文脈の設計

RAGという言葉だけで見ると、ChunkingはEmbedding前の前処理に見えます。

でもData 360 / Agentforceの文脈では、もう少し業務寄りに考えた方がよさそうです。

• そのChunkは誰の質問に答えるのか
• どの業務条件が一緒に必要なのか
• どの参照元に戻れる必要があるのか
• 古い情報と新しい情報をどう区別するのか
• 地域、プラン、製品、権限で絞る必要があるのか

このあたりは、単なる文字数やToken数だけでは決まりません。

「モデルが悪い」と言う前にChunkを見る

AI回答が微妙なとき、ついモデルやプロンプトを疑いたくなります。

もちろんそれも大事です。ただ、Retrieverに渡っているChunkが不完全なら、Prompt BuilderやAgentforce側で頑張っても限界があります。

まず見る順番としては、次のように考えるとよさそうです。

1. 元文書は取り込まれているか
2. Search IndexはReadyか
3. Chunk本文は意味が通るか
4. citationやメタデータは残っているか
5. Retrieverは期待Chunkを拾っているか
6. Prompt Builder / Agentforceの回答に必要文脈が入っているか

導入前チェックリスト

Data 360で非構造化データをAgentforceやRAG用途に使う前に、次を確認したいです。

• 対象文書の種類を把握しているか（PDF、HTML、FAQ、ナレッジ、議事録など）
• 文書ごとの「回答可能な単位」を定義したか
• 見出し、製品名、条件、注意事項がChunk内に残るか
• 参照元URL、ページ番号、更新日などのメタデータを使うか決めたか
• Search Indexの対象フィールドを確認したか
• Search Index の種類（vector / hybrid）を選んだ理由を説明できるか
• chunking strategy（section-aware / semantic-based / window-based など）を選んだ理由を説明できるか
• 組み込みの strategy を選び直す余地が残っていないか（Custom Chunking の前に確認したか）
• Max Token と overlap の値を、目的にもとづいて決めたか（まず overlap ゼロから始めるか）
• Max Token を既定値（512）から動かすなら、埋め込みモデルのサポートするChunkサイズと噛み合っているか
• prepended fields / filtering fields に何を入れるか決めたか（短い項目は prepend 側で扱うか）
• どの埋め込みモデルを使うか決めたか
• Search IndexのLast Run StatusがReadyになっているか
• Data ExplorerでChunk Data Model Objectを確認したか
• Chunkのtext、sequence number、citationを確認したか
• Retrieverで実際の質問を試す観点を用意したか
• Prompt Builder / Agentforceで回答と根拠を確認するか
• Custom Chunkingが必要な理由を具体的に説明できるか

まとめ

Data 360のChunkingは、単に文書を細切れにする処理ではなく、AIが業務文脈を検索・参照しやすくするための設計ポイントとして見ると理解しやすいです。

特に重要なのは、次の点です。

• Chunkは「短い単位」ではなく「回答可能な単位」として考える（公式Blogの「有用なChunk」の定義もこれに近い）
• Search Index / Retriever / Prompt Builder / Agentforceまでつながる前提で設計する
• 触れる設定項目は決まっている（parsing / chunking strategy / overlap / prepended fields / filtering fields / vectorization）。手探りで始める必要はない
• 組み込みの strategy がある（section-aware chunking / passage extraction）。Custom Chunking はその後に検討する
• overlap は必ず入れるものではない。 公式の例ではゼロから始めている
• Max Token は埋め込みモデルとセットで決める。 既定値は 512、1,200 は公式の構成例で使われている値
• 設定は全部回さない。 観測された問題に対応する設定だけを変える
• Data Explorerで実際のChunkを見て、text / sequence number / citation / contextを確認する

「AIの回答がいまいち」と感じたとき、モデルやプロンプトだけではなく、そもそもAIに渡している検索結果の単位が適切かを見る。

Data 360 × Chunkingは、そのためのかなり実務的なテーマになりそうです。

参考リンク

• Salesforce Blog: From Documents to Context: Designing Effective Chunking in Data 360
• Salesforce Developers: Verify Custom Chunking Results
• Salesforce Developers: Step 3 - Create Search Index and Retriever（Ground Agentforce on Your Own Website）
• Salesforce Help: Optimizing Search Indexes: Field Selection and Chunking
• Salesforce: Data 360 (Formerly Data Cloud)