前回は、知識を格納するための「書庫」であるベクトルデータベースの選び方について議論しました。今回は、その書庫に並べる「本（データ）」そのものを、どのように加工すべきかという、RAG（検索拡張生成）の命運を握る工程について深掘りしていきます。
データの「切れ目」が、診断の「分かれ目」になる
突然ですが、少し想像してみてください。
あなたは今、複雑な病歴を持つ患者さんの、厚さ数センチにも及ぶ診療記録一式を、友人の医師に手渡そうとしています。しかし、その友人には「一度に3行分の文章しか記憶できない」という、極めて特殊な制約があったとしたらどうでしょうか？
そのまま記録を渡しても、彼は情報を処理しきれません。「高血圧の既往あり」と読んだ次の瞬間に、重要な「現在は服薬によりコントロール良好」という記述を忘れてしまうかもしれません。あるいは、「癌の再発は」という文の途中で記憶が途切れ、次のページの「認められない」という結論と結び付けられないかもしれません。
これでは、正しい診断など到底不可能です。
あなたはきっと、情報をそのまま渡すのではなく、「意味のまとまり」ごとにハサミを入れ、付箋を貼り、彼が理解できるサイズに小分けにして渡すはずです。
医療RAGにおける「チャンキング」の本質
実は、RAGシステムにおけるLLM（大規模言語モデル）への情報提供も、これと全く同じ構造を抱えています。
近年のLLMは扱える情報量（コンテキストウィンドウ）が増加していますが、それでも膨大なカルテや医学ガイドラインを丸ごと読ませれば、容量オーバーを起こしたり、あるいは長い文脈の中間にある情報を見落としやすくなる「Lost in the Middle」現象のリスクが高まったりする可能性があります。
そこで不可欠となるのが、文書を適切なサイズと意味の単位に分割する「チャンキング（Chunking）」という技術です。
特に医療文書において、この工程は単なる「文字数による分割」では済みません。
例えば、放射線読影レポートにある「悪性所見は／認められない」という一文が、もし「／」の位置で機械的に分割されてしまったらどうなるでしょうか？
1. なぜ「切り方」が命取りになるのか？：医療特有の「コンテキスト依存性」
「たかがテキストの分割でしょ？」と思われるかもしれません。しかし、医療文書において無造作な分割は、診療支援AIとしての信頼性を根底から覆す致命的なミスにつながります。医療テキストは一般的な文章と異なり、「否定」「条件」「時系列」といったコンテキスト（文脈）への依存度が極めて高いからです。
例えば、以下のような放射線読影レポートの例を考えてみましょう。
所見：
右肺上葉に2cm大の結節影を認める。
...（中略）...
結論：
肺癌の疑いなし。もし、機械的なチャンキングによって「肺癌の疑い」と「なし」の間で分割されてしまったらどうなるでしょうか？
- チャンクA: 「…結論：肺癌の疑い」
- チャンクB: 「なし。…」
この状態で、医師が「この患者に肺癌の疑いはありますか？」と質問したとします。
RAGシステムが検索を行い、チャンクA（「…結論：肺癌の疑い」）だけを抽出して回答生成AI（LLM）に渡した場合、AIは否定語を含む後半（チャンクB）を参照できません。その結果、「はい、肺癌の疑いがあると記載されています」という、事実と正反対の回答を出力してしまう恐れがあります。
本稿では、このようにチャンクの境界で情報の意味的つながりが分断され、AIが誤った解釈をしてしまう現象を、便宜上「コンテキストの分断（Context Fragmentation）」と呼びます。
この問題は否定表現に留まりません。
例えば、「アスピリン投与後に」と「出血傾向が見られた」が分断されれば因果関係が不明になりますし、「2023年の検査では」と「異常なし」が分断されれば、それがいつの結果なのかが消失します。
医療RAGの精度は、生成AI（LLM）の賢さそのものよりも、実はこの「チャンクの品質（情報の切り出し方）」に大きく依存します。
適切なチャンキングは、AIに対する「配膳のマナー」のようなものです。どんなに優秀なシェフ（AI）でも、食材（データ）がバラバラに切り刻まれて元の味がわからなくなっていては、美味しい料理（正しい回答）を作ることはできません。AIが消化しやすく、栄養価の高い（文脈が豊かで完結した）状態で情報を提供することが、医療AI開発者には不可欠なのです。
2. 基本戦略：再帰的文字分割（Recursive Character Text Splitting）
では、コンテキストの分断を防ぎながら、具体的にどう切ればいいのでしょうか？ 現時点で最も標準的かつ効果的なアプローチが「再帰的文字分割（Recursive Character Text Splitting）」です。
これは、単純に「500文字で切る」といった固定長分割（Fixed-size Chunking）の進化版です。
固定長分割が、食材を等間隔に機械的に切断するようなもので、時には細胞（意味）を破壊してしまうのに対し、再帰的分割は「関節（意味の切れ目）」を探して、そこから綺麗に外すような切り方です。
具体的には、以下の優先順位リスト（セパレータ）を用いて、文書が指定サイズ（例：500トークン）に収まるまで分割を試みます。
\n\n（段落の区切り：最も大きなまとまり）\n（行の区切り）。や.（文の区切り）、や,（句読点）- 文字単位（最終手段）
アルゴリズムは、まず最も優先度の高い「段落」で切ろうと試みます。それでも指定サイズより大きければ、次は段落の中の「文」で切ることを検討します。それでもダメなら…と、再帰的に処理を進めていきます。
これにより、可能な限り「文」や「段落」といった意味のまとまり（Semantic Unit）を維持したまま、LLMが処理可能なサイズへと分割することができるのです。
3. 文脈をつなぐ「のりしろ」：オーバーラップ（Chunk Overlap）
再帰的分割は強力な武器ですが、それでも万能ではありません。文と文のつなぎ目や、あるいは非常に長い一文の途中でカットせざるを得ない場合、どうしても文脈が断絶するリスクが残ります。
このリスクを最小化する保険のような仕組みが、「オーバーラップ（Chunk Overlap）」の設定です。
これは、チャンクの境界部分を意図的に重複させる、いわば工作の「のりしろ」のようなものです。前のチャンクの末尾（例えば50〜100トークン程度）を、次のチャンクの冒頭にもコピーして含めます。
数式で表現すると、連続するチャンク \( \text{Chunk}_{i} \) と \( \text{Chunk}_{i+1} \) の関係は以下のようになります。ここで \( k \) はチャンクサイズ、\( \text{overlap} \) は重複させるトークン数を表します。
\[ \begin{aligned} \text{Chunk}_{i} &= [w_{t}, w_{t+1}, \dots, w_{t+k}] \\ \text{Chunk}_{i+1} &= [w_{t+k-\text{overlap}}, \dots, w_{t+k}, \dots] \end{aligned} \]
この「のりしろ」があることで、先ほどの「肺癌の疑い／なし」と分断されてしまった例はどう改善されるでしょうか？
- チャンクA: 「…結論：肺癌の疑い」
- チャンクB（オーバーラップあり）: 「結論：肺癌の疑いなし。…」
このように、チャンクBの冒頭に「肺癌の疑い」という文脈が引き継がれることで、チャンクB単体が検索された場合でも、「この患者は肺癌の疑いがない」という正しい情報をAIが理解できるようになります。
オーバーラップのサイズについては、大きすぎると情報が重複してデータベース容量を圧迫し、小さすぎると文脈が切れるリスクが高まります。Unstructured社などはユースケースごとに最適な値を評価・調整することを推奨していますが、医療RAGの実務的な初期値としては、チャンクサイズの10〜20%程度（例：500トークンのチャンクなら50〜100トークン）から開始するのが一般的なベストプラクティスとされています。
4. 最先端のアプローチ：セマンティックチャンキング（Semantic Chunking）
さらに進んだ手法として近年注目されているのが、「セマンティックチャンキング（Semantic Chunking）」です。
これまでの手法が「文字数」や「記号」という形式的なルールで分割していたのに対し、この手法は「意味（Semantics）の変化」そのものをAIに読み取らせて分割を行います。
人間が文章を読むとき、「あ、ここで話題が変わったな」と直感的に感じる瞬間がありますよね？ 例えば、患者の「現病歴」の話から、急に「既往歴」や「家族歴」の話に切り替わるタイミングなどです。セマンティックチャンキングは、この「話題の切れ目」を計算機的に検出して、そこを分割点とするアプローチです。
仕組み：意味の「距離」を測る
具体的には、まず文章を「文（Sentence）」単位に分解し、それぞれの文を埋め込みモデル（Embedding Model）に通してベクトル化します。そして、隣り合う文同士のコサイン類似度（Cosine Similarity）を測定していきます。
隣接する文 \( S_i \) と \( S_{i+1} \) の類似度は以下の式で計算されます。
\[ \text{Similarity}(S_i, S_{i+1}) = \dfrac{S_i \cdot S_{i+1}}{\|S_i\| \|S_{i+1}\|} \]
話題が連続している間（例：現病歴の詳細が続いている間）は、文ごとの意味が近いため、類似度は高い値（1.0に近い値）を維持します。しかし、話題がガラッと変わる瞬間（例：現病歴 \(\to\) 既往歴）、ベクトルが指す方向が大きく異なるため、類似度はガクンと低下します。
この「類似度の谷（Break Point）」を閾値（Threshold）や統計的手法で検出し、そこをチャンクの境界線としてカットします。
この手法は、すべての文に対してEmbedding計算を行うため、処理コストが高くなるというデメリットがあります。しかし、退院サマリのように「主訴」「現病歴」「検査所見」「治療経過」と、話題が次々に展開していく密度の高い医療文書においては、文脈を分断することなく、非常に質の高い（純度の高い）チャンクを作成できる可能性があります。
5. 医療特有の対策：ヘッダー情報の付与（Context-Aware Chunking）
最後に、医療RAGを構築する上で絶対に欠かせない、ドメイン特有のテクニックを紹介します。それは、「メタデータの注入（Metadata Injection）」、あるいは「コンテキスト認識型チャンキング（Context-Aware Chunking）」と呼ばれる手法です。
電子カルテのテキスト、特に医師の経過記録は、チャンク単体で見ると「主語」や「日時」が消えてしまうことが頻繁にあります。
- 原文の文脈: （Aさんの2026年2月18日の循環器内科の記録）
- テキスト: 「血圧は130/80で安定。」
これをそのままチャンクとして切り出すとどうなるでしょうか？
チャンク：「血圧は130/80で安定。」
これだけでは、「誰の」「いつの」「どの診療科の」データなのかが完全に失われてしまいます。検索システムが「Aさんの最新の血圧」を探そうとしても、このチャンクには引っかかりようがありません。
そこで、分割処理を行う際に、元の文書（Parent Document）が持っていた構造化情報（患者ID、入院日、セクション名など）を、強制的に各チャンクの先頭に付与（Inject）します。
具体的には以下のように加工します。
【処理後のチャンク（AIが見る情報）】
※以下はダミーデータです
(Metadata: Patient_ID=12345, Date=2026-02-18, Section=Assessment)
血圧は130/80で安定。降圧剤の増量は不要と判断。このように加工することで、テキスト自体に検索に必要なインデックス情報が埋め込まれ、検索システムは「2026年2月のPatient 12345のAssessment」という文脈を正確に理解してヒットさせることができるようになります。
この工程は前処理の手間がかかりますが、CLI-RAG（Clinically Structured and Context Aware RAG）のような最新の研究でもその有効性が示されており、実臨床での利用に耐えうる高精度なシステムを作る上では必須の工程と言えるでしょう。
まとめ：『木を見て森を見ず』を防ぐために
今回は、RAGの精度を影で支える「チャンキング（Chunking）」の技術について深掘りしてきました。
繰り返しになりますが、医療文書のチャンキングは、単なるテキストの切り刻み作業ではありません。それは、「断片化されがちな情報の文脈（Context）を、いかにして保存し、AIに正しく伝えるか」という、高度なデータエンジニアリングそのものです。
本稿の要点を、もう一度整理しておきましょう。
- 構造を維持する: 基本は「再帰的文字分割」で、段落や文といった自然なまとまりを壊さないように切る。
- 断絶を防ぐ: 「オーバーラップ（のりしろ）」を設け、否定語や因果関係が境界線で消滅するのを防ぐ。
- 意味で切る: 計算リソースが許せば、「セマンティックチャンキング」で話題の転換点を捉え、純度の高い情報塊を作る。
- 迷子を防ぐ: そして何より重要なのが、「メタデータ（ヘッダー情報）の注入」。誰の、いつの記録なのかを各チャンクに刻印し、検索時の迷子を根絶する。
これらを適切に組み合わせることで、皆様の医療RAGシステムは「単語を拾うだけの検索エンジン」から、「文脈を理解する診療パートナー」へと進化します。
さて、データを正しく「切る」ことができたら、次はいよいよそれを「見つけ出す」工程です。
次回は、作成したチャンクの中から、本当に必要な情報をピンポイントで釣り上げる検索技術、「第33回：リトリーバの高度化：ハイブリッド検索とリランキング」についてお話しします。
キーワード検索とベクトル検索のいいとこ取りをする手法や、AIに「検索結果の並び替え」をさせる最新テクニックなど、実践的な内容満載でお届けします。お楽しみに！
※本記事は情報提供を目的としたものであり、特定の治療法を推奨するものではありません。健康に関するご懸念やご相談は、必ず専門の医療機関にご相談ください。
参考文献
- Liu, N.F., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157–173.
- John Snow Labs. (2026). Why LLM Output Alone Cannot Drive Clinical Decisions: Lessons from Production Deployments. John Snow Labs.
- LangChain. (n.d.). Recursively split by character. LangChain Documentation.
- Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems, 33, 9459–9474.
- Unstructured. (2024). Chunking for RAG: Best practices. Unstructured.
- Superlinked. (2025). Semantic Chunking. VectorHub.
- Kamradt, G. (2024). 5 Levels of Text Splitting. GitHub.
- Madan, K., et al. (2025). CLI-RAG: A Retrieval-Augmented Framework for Clinically Structured and Context Aware Text Generation with LLMs. arXiv preprint.
- Weaviate. (n.d.). Chunking. Weaviate Documentation.
ご利用規約（免責事項）
当サイト（以下「本サイト」といいます）をご利用になる前に、本ご利用規約（以下「本規約」といいます）をよくお読みください。本サイトを利用された時点で、利用者は本規約の全ての条項に同意したものとみなします。
第1条（目的と情報の性質）
- 本サイトは、医療分野におけるAI技術に関する一般的な情報提供および技術的な学習機会の提供を唯一の目的とします。
- 本サイトで提供されるすべてのコンテンツ（文章、図表、コード、データセットの紹介等を含みますが、これらに限定されません）は、一般的な学習参考用であり、いかなる場合も医学的な助言、診断、治療、またはこれらに準ずる行為（以下「医行為等」といいます）を提供するものではありません。
- 本サイトのコンテンツは、特定の製品、技術、または治療法の有効性、安全性を保証、推奨、または広告・販売促進するものではありません。紹介する技術には研究開発段階のものが含まれており、その臨床応用には、さらなる研究と国内外の規制当局による正式な承認が別途必要です。
- 本サイトは、情報提供を目的としたものであり、特定の治療法を推奨するものではありません。健康に関するご懸念やご相談は、必ず専門の医療機関にご相談ください。
第2条（法令等の遵守）
利用者は、本サイトの利用にあたり、医師法、医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律（薬機法）、個人情報の保護に関する法律、医療法、医療広告ガイドライン、その他関連する国内外の全ての法令、条例、規則、および各省庁・学会等が定める最新のガイドライン等を、自らの責任において遵守するものとします。これらの適用判断についても、利用者が自ら関係各所に確認するものとし、本サイトは一切の責任を負いません。
第3条（医療行為における責任）
- 本サイトで紹介するAI技術・手法は、あくまで研究段階の技術的解説であり、実際の臨床現場での診断・治療を代替、補助、または推奨するものでは一切ありません。
- 医行為等に関する最終的な判断、決定、およびそれに伴う一切の責任は、必ず法律上その資格を認められた医療専門家（医師、歯科医師等）が負うものとします。AIによる出力を、資格を有する専門家による独立した検証および判断を経ずに利用することを固く禁じます。
- 本サイトの情報に基づくいかなる行為によって利用者または第三者に損害が生じた場合も、本サイト運営者は一切の責任を負いません。実際の臨床判断に際しては、必ず担当の医療専門家にご相談ください。本サイトの利用によって、利用者と本サイト運営者の間に、医師と患者の関係、またはその他いかなる専門的な関係も成立するものではありません。
第4条（情報の正確性・完全性・有用性）
- 本サイトは、掲載する情報（数値、事例、ソースコード、ライブラリのバージョン等）の正確性、完全性、網羅性、有用性、特定目的への適合性、その他一切の事項について、何ら保証するものではありません。
- 掲載情報は執筆時点のものであり、予告なく変更または削除されることがあります。また、技術の進展、ライブラリの更新等により、情報は古くなる可能性があります。利用者は、必ず自身で公式ドキュメント等の最新情報を確認し、自らの責任で情報を利用するものとします。
第5条（AI生成コンテンツに関する注意事項）
本サイトのコンテンツには、AIによる提案を基に作成された部分が含まれる場合がありますが、公開にあたっては人間による監修・編集を経ています。利用者が生成AI等を用いる際は、ハルシネーション（事実に基づかない情報の生成）やバイアスのリスクが内在することを十分に理解し、その出力を鵜呑みにすることなく、必ず専門家による検証を行うものとします。
第6条（知的財産権）
- 本サイトを構成するすべてのコンテンツに関する著作権、商標権、その他一切の知的財産権は、本サイト運営者または正当な権利を有する第三者に帰属します。
- 本サイトのコンテンツを引用、転載、複製、改変、その他の二次利用を行う場合は、著作権法その他関連法規を遵守し、必ず出典を明記するとともに、権利者の許諾を得るなど、適切な手続きを自らの責任で行うものとします。
第7条（プライバシー・倫理）
本サイトで紹介または言及されるデータセット等を利用する場合、利用者は当該データセットに付随するライセンス条件および研究倫理指針を厳格に遵守し、個人情報の匿名化や同意取得の確認など、適用される法規制に基づき必要とされるすべての措置を、自らの責任において講じるものとします。
第8条（利用環境）
本サイトで紹介するソースコードやライブラリは、執筆時点で特定のバージョンおよび実行環境（OS、ハードウェア、依存パッケージ等）を前提としています。利用者の環境における動作を保証するものではなく、互換性の問題等に起因するいかなる不利益・損害についても、本サイト運営者は責任を負いません。
第9条（免責事項）
- 本サイト運営者は、利用者が本サイトを利用したこと、または利用できなかったことによって生じる一切の損害（直接損害、間接損害、付随的損害、特別損害、懲罰的損害、逸失利益、データの消失、プログラムの毀損等を含みますが、これらに限定されません）について、その原因の如何を問わず、一切の法的責任を負わないものとします。
- 本サイトの利用は、学習および研究目的に限定されるものとし、それ以外の目的での利用はご遠慮ください。
- 本サイトの利用に関連して、利用者と第三者との間で紛争が生じた場合、利用者は自らの費用と責任においてこれを解決するものとし、本サイト運営者に一切の迷惑または損害を与えないものとします。
- 本サイト運営者は、いつでも予告なく本サイトの運営を中断、中止、または内容を変更できるものとし、これによって利用者に生じたいかなる損害についても責任を負いません。
第10条（規約の変更）
本サイト運営者は、必要と判断した場合、利用者の承諾を得ることなく、いつでも本規約を変更することができます。変更後の規約は、本サイト上に掲載された時点で効力を生じるものとし、利用者は変更後の規約に拘束されるものとします。
第11条（準拠法および合意管轄）
本規約の解釈にあたっては、日本法を準拠法とします。本サイトの利用および本規約に関連して生じる一切の紛争については、東京地方裁判所を第一審の専属的合意管轄裁判所とします。
For J³, may joy follow you.
