「最新のLLMを使っているのに、RAG（検索拡張生成）の回答がいまいち噛み合わない」「検索結果に、欲しい情報の前後の文脈が含まれていない」
顧客体験（CX）の向上と業務効率化の両立を目指すAI導入プロジェクトにおいて、このような壁に直面するケースは決して珍しくありません。
多くのプロジェクトでは、回答精度の向上のために生成モデル自体をChatGPTやClaudeといった高性能なものへ切り替えることに注力しがちです。特に近年は、GPT-4o等のレガシーモデルが廃止され、より長い文脈理解や高度な推論能力を備えた新たな標準モデルへの移行が進んでいます。モデルの進化に合わせてシステムをアップデートすることは重要ですが、実は「データの切り方（チャンキング）」こそが、精度のボトルネックになっているケースが非常に多いのです。
特に、Embedding（ベクトル化）用モデルと生成用LLMで異なるベンダーのモデルを組み合わせる「異種モデル混在環境」では、この問題はより深刻になります。最新のモデルは長い文脈を理解する能力が飛躍的に向上しているものの、検索段階で固定長によって機械的にテキストを切断してしまうと、肝心な文脈が破壊されてしまいます。その結果、どれほど優れたモデルを採用していても、最終的な顧客体験を損なうリスクを孕んでいるのです。
本記事では、意味のまとまりに基づいてテキストを分割する「セマンティック・チャンキング（Semantic Chunking）」の実装手法について、実務で活用できる具体的なアプローチを紐解きます。単にシステムを動かすだけでなく、「なぜその処理が必要なのか」という設計の意図や、運用時のリスク管理、そして最新モデルへの移行を見据えたアーキテクチャの考え方にも触れていきます。手元の環境で検証し、自社のRAGシステムの精度向上、ひいては顧客満足度と業務効率の両立に役立ててください。
1. なぜ「固定長」では失敗するのか：異種モデル混在時のリスク
まず、多くのエンジニアが最初に採用する「固定長チャンキング（Fixed-size Chunking）」が、なぜRAGの精度向上を阻む壁となるのか、その構造的な欠陥について解説します。
Embeddingモデルと生成モデルの「文脈」の捉え方の違い
RAGパイプラインにおいて、通常、2つの異なる「脳」を使っています。
- 検索担当の脳（Embeddingモデル）: テキストをベクトルに変換し、類似度を計算する。
- 回答担当の脳（生成LLM）: 検索されたテキストを読み込み、回答を生成する。
問題は、この2つの脳が「言葉の区切り方（トークナイズ）」において、全く異なる辞書を持っている場合が多いことです。例えば、OpenAIのEmbeddingモデル（text-embedding-3シリーズなど）でベクトル化を行い、生成にはAnthropicの Claude（最新のClaudeモデルなど）を使うようなケースです。
固定長チャンキングで「500トークンごと」に切ったとしても、それはあくまで「ある特定のトークナイザ」基準での500トークンです。別のモデルから見れば、文脈の途中で唐突に切られた不自然なデータに見えることがあります。特に、AIモデルの進化サイクルは非常に早く、特定のバージョン（例：旧世代のClaude 3.5系など）に最適化したトークン分割は、モデルの廃止や移行が発生した際に「負債」となるリスクがあります。
トークン数ベース分割が引き起こす「意味の分断」事故
もっとも恐ろしいのは、重要なキーワードや文脈がチャンクの境界線上で分断される「意味の分断」事故です。
例えば、「A社の製品サポートは、平日10時から19時までです。ただし、緊急時は24時間対応します」という文章があったとします。
固定長で機械的に切った結果、チャンクAが「〜平日10時から19時までです。ただし、」で終わり、チャンクBが「緊急時は24時間対応します」から始まったとしたらどうなるでしょうか。
ユーザーが「夜間の緊急対応について知りたい」と検索した際、ベクトル検索はチャンクBをヒットさせるかもしれませんが、チャンクB単体では「何が」24時間対応なのかという主語が欠落しています。LLMはこれを「文脈不足」と判断し、「情報がありません」と回答するか、最悪の場合は幻覚（ハルシネーション）を起こして誤った情報を補完してしまうかもしれません。これは顧客の自己解決率を低下させ、結果としてコンタクトセンターへのエスカレーションを増やし、業務効率を悪化させる要因となります。
セマンティック・チャンキングが提供する「安心」とは
こうした事故を防ぐためのアプローチが「セマンティック・チャンキング」です。これは、文字数やトークン数で機械的に切るのではなく、「文章の意味的な内容が変わるポイント」をAIに判断させて分割する方法です。
意味の塊（セマンティックなまとまり）ごとにデータを保持しておけば、どのモデルに渡しても「ひとつの完結した情報」として扱われます。これは、将来的に生成AIモデルを最新版（例：GPTシリーズやClaudeシリーズの次世代版）に差し替える際にも、データの再構築（Re-indexing）の手間を減らす「資産としてのデータ品質」を高めることにも繋がります。
2. 実装環境のセットアップと依存関係
それでは、実際にコードを書いていきましょう。今回は、Python環境で LangChain の実験的ライブラリを使用して実装します。実験的機能を使う際は、バージョン変更による影響を受けやすいため、依存関係の管理には十分注意してください。
必要なライブラリの選定理由
今回は以下のライブラリ群を使用します。
langchain: RAG構築のデファクトスタンダード。langchain-experimental: セマンティックチャンキングのような先進的な機能が含まれています。langchain-openai: EmbeddingモデルとしてOpenAIを使用するため。python-dotenv: APIキーを安全に管理するため。
以下のコマンドで環境を準備します。
pip install langchain langchain-experimental langchain-openai python-dotenv matplotlib
安全な検証環境の構築
実務で新しい技術を検証する際、最も注意すべきなのは「意図しないAPIコストの発生」です。特にチャンキングの実験では、ループ処理のミスなどで大量のEmbeddingリクエストが発生するリスクがあります。
必ず .env ファイルでAPIキーを管理し、コード内には直接記述しないようにしましょう。
# .env ファイル
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxx
APIキー管理とコスト上限設定
コードの冒頭では、環境変数の読み込みと同時に、使用するモデルを明示的に指定します。OpenAI側で使用量制限（Usage Limits）を設定しておくことも、重要なリスク管理です。
import os
from dotenv import load_dotenv
# 環境変数の読み込み
load_dotenv()
# APIキーの存在確認（事故防止のためのフェイルセーフ）
if not os.getenv("OPENAI_API_KEY"):
raise ValueError("OPENAI_API_KEYが設定されていません。.envファイルを確認してください。")
print("環境セットアップ完了。安全に実験を開始できます。")
3. 基礎実装：意味の類似度に基づくチャンキング
ここからが本題です。セマンティック・チャンキングの核となるロジックは、「隣り合う文（Sentence）同士の類似度を計算し、類似度がガクンと下がった場所を『話題の転換点』とみなして分割する」というものです。
コサイン類似度を用いた「切れ目」の判定ロジック
LangChain Experimental の SemanticChunker は、以下のプロセスを自動化してくれます。
- 文章を「文（Sentence）」単位に分割する。
- 各文のEmbedding（ベクトル表現）を取得する。
- 隣接する文同士のコサイン類似度を計算する。
- 設定した「しきい値（Threshold）」を下回る箇所でチャンクを分割する。
基本コード：SemanticChunkerの挙動を確認する
まずは、シンプルなテキストデータを使って、どのように分割されるかを確認してみましょう。ここでは、話題が明確に変わるダミーテキストを用意します。
from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings
# 1. Embeddingモデルの初期化
# コストと精度のバランスが良い text-embedding-3-small を推奨
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
# 2. SemanticChunkerの初期化
# breakpoint_threshold_type="percentile" は、類似度の変化の大きさで判断する設定です
text_splitter = SemanticChunker(
embeddings,
breakpoint_threshold_type="percentile",
breakpoint_threshold_amount=95 # 上位95%の類似度を維持（つまり大きく変化したら切る）
)
# 3. テストデータの用意（話題が3つ含まれています）
text = """
チャットボット導入の第一歩は、現状の問い合わせ分析です。過去のログを確認し、頻出する質問を特定しましょう。
これにより、自動化すべき範囲が明確になります。まずはFAQの整備から始めるのが定石です。
次に、感情分析技術について解説します。顧客の声のトーンをAIが判別し、怒っている顧客には有人対応へ即座に切り替えることが可能です。
これにより、二次クレームの発生を防ぐことができます。CS満足度の向上には欠かせない技術です。
最後に、API連携の実装方法です。Pythonのリクエストライブラリを使用して、外部CRMとデータを同期します。
認証キーはヘッダーに含めて送信してください。セキュリティには十分な配慮が必要です。
"""
# 4. チャンキングの実行
try:
docs = text_splitter.create_documents([text])
print(f"分割されたチャンク数: {len(docs)}")
print("-" * 30)
for i, doc in enumerate(docs):
print(f"[Chunk {i+1}] (文字数: {len(doc.page_content)})\n{doc.page_content}\n")
except Exception as e:
print(f"チャンキング処理中にエラーが発生しました: {e}")
しきい値（Threshold）の設定と調整方法
上記のコードで重要なのが breakpoint_threshold_amount です。これを「percentile」モードで使う場合、値を高く設定するほど「少しでも話題が変われば切る（チャンクが細かくなる）」挙動になり、低く設定すれば「大きく話題が変わらない限り切らない（チャンクが大きくなる）」挙動になります。
- 95〜99: 厳密に分割したい場合。細かいトピックの変化も捉えます。
- 60〜80: 大まかなまとまりで分割したい場合。
正解の値はありません。扱うドキュメントの性質（マニュアルなのか、議事録なのか）によって、このパラメータを調整する必要があります。
4. 応用パターン：異種モデル連携時の最適化
基礎実装ではOpenAIのEmbeddingモデルに依存して分割を行いました。しかし、実際のRAGシステムでは、検索後にClaude 3やLlamaといった別のLLMにコンテキストを渡すことになります。
ここで問題になるのが、「セマンティックに切った結果、チャンクサイズが大きくなりすぎてLLMのトークン制限やコンテキストウィンドウを圧迫する」可能性です。
Embeddingモデル特有の「得意な長さ」に合わせる調整
意味で切ると、稀に非常に長いセクション（例：詳細な利用規約など）が1つのチャンクになってしまうことがあります。多くのEmbeddingモデルは、入力トークン数に上限（例：8191トークン）がありますが、検索精度（Retrieval性能）を考えると、500〜1000トークン程度に収めるのが理想的です。
セマンティック分割の結果が長すぎる場合に、強制的に分割するロジックを組み合わせる「ハイブリッドアプローチ」が有効です。
生成モデル（LLM）のコンテキストウィンドウを考慮した統合
以下は、セマンティックチャンキングを行いつつ、長すぎるチャンクには再分割（RecursiveCharacterTextSplitter）を適用する安全策を講じた実装例です。
from langchain.text_splitter import RecursiveCharacterTextSplitter
def safe_semantic_chunking(text, embeddings, max_chunk_size=1000):
"""
セマンティックチャンキングを行い、かつ最大サイズを超過するチャンクは
強制的に再分割する安全な関数
"""
# 1. まず意味で分割
semantic_splitter = SemanticChunker(
embeddings,
breakpoint_threshold_type="percentile"
)
semantic_docs = semantic_splitter.create_documents([text])
final_docs = []
# 2. 長すぎるチャンクがないかチェックし、あれば再分割
# バックアップ用の固定長スプリッター
recursive_splitter = RecursiveCharacterTextSplitter(
chunk_size=max_chunk_size,
chunk_overlap=100
)
for doc in semantic_docs:
if len(doc.page_content) > max_chunk_size:
# 長すぎる場合は再分割してリストに追加
sub_docs = recursive_splitter.create_documents([doc.page_content])
# メタデータを引き継ぐ場合はここで処理
final_docs.extend(sub_docs)
else:
final_docs.append(doc)
return final_docs
# 実行テスト
print("--- 安全策付きチャンキング ---")
safe_docs = safe_semantic_chunking(text, embeddings)
print(f"最終チャンク数: {len(safe_docs)}")
メタデータ付与による検索精度の補強
異種モデル環境では、チャンク自体に「自分がどのドキュメントの、どの部分なのか」という自己紹介（メタデータ）を持たせることが非常に重要です。LLMが文脈を理解する助けになるからです。
例えば、上記のコードの final_docs を生成する際に、元のドキュメントのタイトルやセクション名をメタデータとして付与することで、検索後のLLM（Claudeなど）が「これは『API連携』の章の一部だな」と認識できるようになります。
5. 「見えない」をなくす：チャンキング結果の可視化と検証
システム構築において最も不安なのは、「ブラックボックス化したロジック」です。セマンティック・チャンキングはAI任せの部分が大きいため、意図通りに切れているかを目視確認するプロセスが必須です。
分割位置を視覚的に確認するデバッグ用コード
実務の現場でよく使われる、分割箇所を可視化するための簡易ユーティリティを紹介します。コンソール上で色分けして表示することで、直感的に分割の良し悪しを判断できます。
def visualize_chunks(docs):
"""
チャンクごとに色を変えて表示し、視覚的に確認しやすくする
"""
colors = ["\033[94m", "\033[92m", "\033[93m", "\033[96m"] # 青, 緑, 黄, シアン
reset = "\033[0m"
print("\n--- Visualizing Chunks ---\n")
for i, doc in enumerate(docs):
color = colors[i % len(colors)]
# 改行を可視化するために置換
content = doc.page_content.replace("\n", " [LF] ")
print(f"{color}[Chunk {i}] {content}{reset}")
print(f"{color}{'-'*20}{reset}") # 区切り線
# 先ほどのdocsを可視化
visualize_chunks(safe_docs)
検索漏れを防ぐためのユニットテスト作成
本番運用前には、必ず「想定される質問（クエリ）」に対して、正しいチャンクがヒットするかどうかのテストを行ってください。これを自動化しておくと、モデルのバージョンアップ時にも安心です。
- テスト用ドキュメントを用意する。
- そのドキュメントから回答できるはずの「質問」と「正解チャンクID」のペアを作成する。
- チャンキング後のデータに対してベクトル検索を行い、Top-Kに正解が含まれるか検証する。
この「Retrieval Evaluation」の工程をスキップすると、ユーザーからの「全然関係ない答えが返ってきた」という問い合わせに追われることになり、顧客体験を大きく損ないます。
コストと精度のバランスを監視する
セマンティック・チャンキングは、固定長に比べてEmbeddingのAPIコール回数が増える傾向にあります（分割点の判定のために計算が必要なため）。
実装初期は精度向上に喜びを感じるものですが、運用フェーズに入るとコストが課題になります。ログ基盤（DatadogやCloudWatchなど）に、「ドキュメント1件あたりの処理トークン数」と「生成されたチャンク数」を記録し、異常な分割が発生していないか監視する仕組みを整えておくことを強くお勧めします。適切なKPI設計とモニタリングが、長期的な運用成功の鍵となります。
まとめ
RAGの精度向上において、モデルの選定と同じくらい、あるいはそれ以上に重要なのが「チャンキング戦略」です。特に異種モデルを組み合わせる現代的なアーキテクチャでは、固定長分割による文脈の不整合が致命的なノイズになり得ます。
今回ご紹介したセマンティック・チャンキングは、銀の弾丸ではありませんが、テキストの「意味」を尊重することで、システム全体の堅牢性を大きく向上させる手段です。
- 固定長のリスク: 文脈分断による検索漏れと、それに伴う顧客の自己解決率低下。
- セマンティックの利点: 意味のまとまりを保持し、異種モデル間での情報の受け渡しをスムーズにする。
- 安全な実装: コスト管理、長文対策、そして可視化による検証。
もし、「自社のデータ特有の構造があってうまく切れない」「導入してみたがコストが見合わない気がする」といった具体的な課題がある場合は、専門家に相談することをおすすめします。顧客ジャーニー全体を俯瞰し、データ構造とビジネス要件に合わせた最適なRAGパイプラインを設計することが、カスタマーサービスのAI化による顧客体験向上とコスト削減の両立に繋がります。
コメント