🗂️ 技術調査 - RAGの回答精度を左右する非構造データ継続パイプライン設計

検証日: 2026-06-29

■概要

「Context Data Pipeline for RAG」とは、生成 AI / RAG (Retrieval-Augmented Generation) に渡す文脈データを、社内に散らばる非構造データ (PDF・議事録・メール・ナレッジ記事・図表) から継続的に作り出すデータ加工パイプラインを指します。収集 → クレンジング → 意味付け → ベクトル化 → 同期更新 までを一本化します。

特定プロダクトの名前ではなく、「LLM の素の性能を上げるよりも、LLM に渡す文脈そのものを継続的に整える方が業務 RAG の回答品質に効く」という設計思想に名前を付けたものです。Andrej Karpathy が 2025 年に「Context Engineering」と呼んで一般化させ、Anthropic が公式エンジニアリングブログで体系化しました。同じ時期に、ETL / ELT の延長として「非構造データ向け継続パイプライン」を組み立てる実装側の流れも進み、両者が 2025-2026 年に合流しました。

位置付けを 1 枚で示します。

意味付け (D) と継続供給 (A→B の点線) が、従来の「ファイルを 1 回ベクトル化して終わり」の素朴な RAG と Context Data Pipeline 設計とを分けます。

なぜ 2025-2026 にかけて注目されているか

LLM の競争軸がモデル性能のフロンティアから文脈供給の質へ移行したためです。

Karpathy は 2025 年 6 月の X 投稿で「Context engineering is the delicate art and science of filling the context window with just the right information for the next step.」と述べ、業務 LLM アプリでは prompt より context そのものの設計こそが本質だと位置付けました。Anthropic は公式ブログ「Effective context engineering for AI agents」で「the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference」と定義し、prompt engineering の自然な発展形として体系化しました。

日経クロステック「RAGの精度向上、『AI-Ready』データを作るコンテキストエンジニアリング」、ITmedia の日本ハム事例、note の「社内RAGの回答精度が上がらない本当の理由」など、2026 年前半の国内記事も同じ論点に収束しており、テーマが普及局面に入ったとわかります。

Context Engineering 言説との接続

Karpathy / Anthropic の言う「Context Engineering」は、推論時の context window に何を入れるかを設計します。Context Data Pipeline は、その「入れるべきもの」を事前に作っておく側を担当します。

両者は対立する概念ではなく、上流 (素材作り) と下流 (盛り付け) の関係です。Anthropic が紹介する just-in-time retrieval（必要な瞬間にだけ context へ取り込む）も、素材側の意味付けとメタデータが整っていなければ「取り込むべき適切な単位」を選べません。Context Data Pipeline の品質が、Context Engineering の打ち手の選択肢を広げます。

日本ハム事例から見える典型課題（「薄い回答」の原因分解）

日本ハムは Azure OpenAI Service を用いた社内 AI アシスタント「Smart Generative Chat」と、生活者 1,000 人分のアンケートを 45 分で擬似実行する GC (Generated Customer) 分析を運用しています。この事例と、関連する国内記事 (note 言語理解研究所 / 日経クロステック) を突き合わせ、本稿では「AI が薄い回答を返す」原因を次の 4 つに抽象化して整理します。

note 言語理解研究所の整理に従えば、これらはモデル起因のハルシネーションではなくデータ起因のハルシネーションであり、「日本の企業で RAG の精度が上がらない原因の大半」を占めるとされています。「薄い回答」の正体はモデルの限界ではなくパイプライン上流の意味付け不足であり、ここに Context Data Pipeline の存在意義があります。

■特徴

4-6 工程への分離

Context Data Pipeline の中核は、従来 1 つの「ロード処理」として扱っていた工程を、責務ごとに明確に分離することです。代表的な工程分解は次の 6 段です。

工程を分離すると、「精度が出ない」ときにどの工程の問題かを切り分けられ、最小単位で打ち手を選べます。

静的ロードでなく継続パイプラインであること

素朴な RAG では「初回に全件をベクトル化して終わり」の静的ロードを選びがちですが、業務データは毎日変わるため、数週間で精度が劣化します。Context Data Pipeline は継続パイプラインであることが必須要件です。

特に hash ベースの dedup が重要です。LlamaIndex IngestionPipeline は doc_id と document_hash の対応を保持し、hash が変わったときだけ再処理 + 更新し、変わらなければスキップします。巨大ナレッジベース全体を毎晩再 embed する無駄を避けながら、鮮度を保てます。

semantic enrichment の役割

semantic enrichment は、生テキストに検索可能なメタ情報を付与する工程で、Context Data Pipeline の差別化点そのものです。

Azure AI Search では skillset が enrichment の容れ物となり、OCR・key phrase 抽出・翻訳・カスタムスキルを「パイプラインの中のパイプライン」として差し込めます。LlamaIndex では TitleExtractor などの Transformation として表現し、Unstructured では画像・テーブルの要約を optional enrichment として提供します。

業務文脈（組織固有用語・社内コード・略号）の継続抽出

semantic enrichment の中でも、企業固有の「方言」を継続的に拾い続ける機構が、社内 RAG の精度を最も大きく動かします。

これらは一度作って終わりではありません。新製品・組織改編・新略号の発生に合わせ継続抽出が必要で、ここが「継続パイプライン」と意味付けの結合点です。

他アプローチとの位置付け比較

LLM に文脈を渡す手段は Context Data Pipeline だけではなく、目的と制約に応じて選び分けます。

Context Data Pipeline は単純 RAG と Agentic の中間に位置し、「精度・鮮度・コスト・統制」のバランスを取ります。Anthropic の整理に従えば、agentic just-in-time retrieval の「呼ばれる側」を支える基盤としても機能します。

主要 5 プラットフォーム比較

代表的な 5 つのプラットフォームを Context Data Pipeline の観点で並べます。

選択軸は、「自前で組む自由度（LlamaIndex / LangChain）を取るか、マネージド統合（Bedrock / Azure / Unstructured）を取るか」と、「クラウド（AWS / Azure）との親和性」の 2 軸です。日本ハムのような Azure OpenAI Service ベースの案件では Azure AI Search Indexer + Skillset が自然な選択となり、AWS ベースなら Bedrock Knowledge Bases、マルチクラウド / OSS 寄りなら LlamaIndex + Unstructured の組み合わせが現実的な落とし所です。

■構造

システムコンテキスト図とコンテナ図は汎用構造として示し、コンポーネント図では既存実装（LlamaIndex / Unstructured / LangChain / Bedrock KB / Azure AI Search / Databricks Vector Search 等）を例示します。

●システムコンテキスト図

Context Data Pipeline 本体を中央に置き、人間アクター（役割）・上流データ源カテゴリ・下流の検索 / 生成基盤との関係を表現します。Pipeline は「Knowledge Owner が持つ生の知識」を「RAG Application User が消費可能な検索可能コンテキスト」へ継続的に変換する系です。

アクター

Pipeline 本体

上流カテゴリ（Source Systems）

下流カテゴリ（Retrieval / Generation）

横断要素

●コンテナ図

Context Data Pipeline 本体を 9 つの論理コンテナに分解します。各コンテナは「単一責務 + 明示的なインターフェース契約」を持ち、後段の差し替え（例: 埋め込みモデルの更新、チャンク戦略の刷新）に耐えます。Orchestrator が左右（取込側 / 索引側）を統括し、Quality Evaluator と Lineage / Catalog が横断的にメタ情報を扱う配置です。

取込レーン（Ingest Lane）

横断（Cross-cutting）

境界（Boundary）

●コンポーネント図

主要コンテナの内部構造を、既存実装の役割を例示しながら分解します。中核となる Enrichment Engine と Chunker を最優先で扱い、続いて Source Connector / Embedder + Indexer / Quality Evaluator + Lineage を示します。

Enrichment Engine のドリルダウン

Enrichment Engine は「テキスト自体は変えずに、検索性と説明可能性を上げるメタ層を被せる」工程です。処理は宣言的なスキル（skill）群の DAG として記述され、画像 / テキスト / 表 / コード のメディア種別ごとに別系統を持つのが定石です。Azure AI Search の skillset は典型例で、組込スキルとカスタムスキルの両方を同一実行モデルで扱います。

制御部

Text Skills 群

Image Skills 群

Custom Skills 群

Chunker のドリルダウン

Chunker は「埋め込みの単位」を決める工程で、RAG 全体の精度に最大の影響を与える分岐点です。LangChain の text splitter 分類（長さベース / テキスト構造 / 文書構造 / 意味）と Bedrock KB の戦略（固定長 / 階層 / セマンティック / 無分割）を統合し、ストラテジ選択器を中心に据える設計が定石です。

制御部

Length Based

Structure Based

Semantic Based

Hierarchical

Source Connector のドリルダウン

Source Connector は「上流の変更を漏れなく、かつ重複なく取得する」責務に特化します。LlamaIndex の docstore による doc_id × document_hash の管理、Bedrock KB のフルクロール / 増分同期、Databricks の Delta Sync が代表例です。

Embedder + Indexer のドリルダウン

Embedder と Indexer は密結合で動く局面が多いため一枚で扱います。モデル管理・バッチ最適化・upsert / delete の整合がここで完結することで、上流の戦略変更を下流に波及させずに済みます。

Quality Evaluator + Lineage / Catalog のドリルダウン

Quality Evaluator と Lineage / Catalog は読み取り専用の横断系で、Pipeline の改善ループとガバナンスの両輪を担います。Quality Evaluator は RAGAS 由来の四指標（忠実性 / 回答関連性 / 文脈精度 / 文脈再現率）を継続収集し、Lineage は OpenLineage 互換のイベントを蓄積する設計が広く採られます。

Quality Evaluator

Lineage / Catalog

■データ

Context Data Pipeline for RAG が扱う主要エンティティを、LlamaIndex の Document / Node スキーマ、LangChain の Document スキーマ、Unstructured の Element、AWS Bedrock Knowledge Base のリソース、Azure AI Search の Skillset / Indexer / Index、RAGAS の評価メトリクスから抽出して整理します。実装ごとに名称は異なりますが、抽象化すると同じ役割のエンティティに収れんします。

●概念モデル

パイプラインの構造を主要エンティティの関係として表現します。所有関係（composition / aggregation）を subgraph で、利用関係（use / produce / consume）を矢印で示します。

●情報モデル

各エンティティの主要属性を classDiagram で表現します。型は言語非依存の汎用型（string / int / float / bool / datetime / list / map / set）で記述し、関連には多重度を明示します。属性は一次資料（LlamaIndex / LangChain / Unstructured / Bedrock KB / Azure AI Search / RAGAS）を根拠としています。

実装側で名称が異なる場合（例: Bedrock の IngestionJob = PipelineRun、Unstructured の Element = Chunk、Azure AI Search の Skill = Transformation）は、本概念名にマッピングするとフレームワーク非依存の設計議論ができます。QualityMetric は Pipeline の継続改善ループの起点になり、RAGAS の 4 指標（faithfulness / answer_relevancy / context_precision / context_recall）を最低限の計測対象としつつ、Lineage と組み合わせてどの Chunk・Transformation が劣化要因かを追跡できる構造にします。KnowledgeAsset は組織用語辞書や業務ルールを Transformation や Metadata 付与に注入する役割を担い、汎用 RAG が陥りがちな「自社用語が出てこない・誤検出される」問題への対策として独立エンティティで扱います。

■構築方法

Context Data Pipeline 自体は特定プロダクト名ではないため、ここで示すコードはすべて方法論を実装するパターン例です。参照元の公式ドキュメント URL をコードコメントに明示します。

前提条件

ローカル PoC から段階的に組み上げる前提で、まず Python 仮想環境を準備します。

# Source: https://developers.llamaindex.ai/python/framework/
python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip

インストール（パターン別）

方法論の実装パターンを 4 つに分けて、最小構成のインストール手順を示します。

パターン A: LlamaIndex IngestionPipeline（OSS / pip）

LlamaIndex は Source / Preprocessor / Chunker / Enrichment / Embedder / Indexer を IngestionPipeline の transformations として宣言的に並べる構成です。

# Source: https://developers.llamaindex.ai/python/framework/module_guides/loading/ingestion_pipeline/
pip install llama-index
pip install llama-index-readers-file        # ローカル / fsspec 経由のソース
pip install llama-index-vector-stores-qdrant # Vector DB の例 (Qdrant)
pip install llama-index-embeddings-openai    # 埋め込みモデル

バージョン確認は次のコマンドで行います。

python -c "import llama_index; print(llama_index.__version__)"

パターン B: Unstructured.io（OSS / API）

非構造ファイル（PDF / DOCX / HTML / 画像）を要素（Title / NarrativeText / Table）に分解する Preprocessor を担うパターンです。OSS 版と API 版があります。

# Source: https://docs.unstructured.io/open-source/core-functionality/partitioning
pip install "unstructured[all-docs]"    # OSS 版 (PDF/Office/Image 含む)
# 注: hi_res 戦略を使う場合は別途 tesseract / poppler / libmagic が必要

API 版を使う場合は API キー発行後に次の SDK を入れます。

# Source: https://docs.unstructured.io/api-reference/api-services/sdk
pip install unstructured-client

パターン C: AWS Bedrock Knowledge Bases（マネージド / CDK）

マネージドサービス側に Source Connector / Chunker / Embedder / Indexer / Orchestrator を任せる構成です。Console 操作と CDK / API の 2 ルートがあります。

# Source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-create.html
pip install boto3 aws-cdk-lib constructs
aws --version    # awscli v2 想定
cdk --version    # CDK v2 想定

API リクエストの最小例（公式ドキュメント抜粋）は次のとおりです。

PUT /knowledgebases/ HTTP/1.1
Content-type: application/json

{
  "name": "MyKB",
  "roleArn": "arn:aws:iam::111122223333:role/service-role/AmazonBedrockExecutionRoleForKnowledgeBase_123",
  "knowledgeBaseConfiguration": {
    "type": "VECTOR",
    "vectorKnowledgeBaseConfiguration": {
      "embeddingModelArn": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0"
    }
  },
  "storageConfiguration": {
    "opensearchServerlessConfiguration": {
      "collectionArn": "arn:aws:aoss:us-east-1:111122223333:collection/abcdefghij1234567890",
      "fieldMapping": {"metadataField": "metadata", "textField": "text", "vectorField": "vector"},
      "vectorIndexName": "MyVectorIndex"
    }
  }
}

パターン D: Azure AI Search Indexer + Skillset（マネージド / Bicep）

Indexer（定期 pull + 差分検知）と Skillset（chunk / OCR / embedding / 自然言語処理）を組み合わせる構成です。Bicep / azd / REST いずれでも構築できます。

# Source: https://learn.microsoft.com/en-us/azure/search/search-howto-create-indexers
az --version
azd version
pip install azure-search-documents

Indexer 定義の最小例（Skillset 連携あり）は次のとおりです。

{
  "name": "rag-indexer",
  "dataSourceName": "blob-ds",
  "targetIndexName": "rag-index",
  "skillsetName": "rag-skillset",
  "schedule": { "interval": "PT1H" },
  "parameters": { "configuration": { "indexedFileNameExtensions": ".pdf,.docx" } }
}

バージョン確認コマンド（まとめ）

■利用方法

各工程の典型コード例を、冒頭にコネクタ別必須パラメータを整理した一覧を置いた上で示します。

コネクタ別必須パラメータ（Source Connector 早見表）

1. ソース接続（Source Connector）

LlamaIndex のローカル / S3 接続例です。Source Connector 工程を OSS で実装するパターン例です。

# Source: https://developers.llamaindex.ai/python/framework/module_guides/loading/simpledirectoryreader/
from llama_index.core import SimpleDirectoryReader

# 1) ローカルディレクトリ
documents = SimpleDirectoryReader(input_dir="./corpus").load_data()

# 2) S3 (fsspec 経由)
# pip install s3fs
import s3fs
fs = s3fs.S3FileSystem(anon=False)  # AWS_PROFILE / IAM Role を利用
documents_s3 = SimpleDirectoryReader(
    input_dir="my-bucket/reports/2026/",
    fs=fs,
    recursive=True,
).load_data()

クラウドマネージド側（Bedrock KB）は Console / API でデータソース種別（S3 / SHAREPOINT / CONFLUENCE / SALESFORCE / WEB）を選ぶだけで Connector が自動構築されます。

2. クレンジング・パース（Preprocessor）

Unstructured を使った PDF / HTML パースの例です。要素単位（Title / NarrativeText / Table）で取り出すことで、後段の Chunker / Enrichment に意味的な単位を渡せます。

# Source: https://docs.unstructured.io/open-source/core-functionality/partitioning
from unstructured.partition.auto import partition

elements = partition(
    filename="example.pdf",
    strategy="hi_res",        # OCR / レイアウト解析を行う高精度モード
    languages=["jpn", "eng"],
)

for el in elements:
    print(type(el).__name__, "|", el.text[:80])
# 出力例: Title | 2026 年度経営計画
#         NarrativeText | 本書は当社の中期経営計画を…
#         Table | <html><table>...</table></html>

PII マスクは Preprocessor 工程で次のように適用するパターンが定石です（Microsoft Presidio などの OSS を併用）。

# Source: https://microsoft.github.io/presidio/
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

def mask_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en")
    return anonymizer.anonymize(text=text, analyzer_results=results).text

cleaned = [mask_pii(el.text) for el in elements if el.text]

3. チャンク分割（Chunker）

代表的な 3 つの分割戦略を、Chunker 工程の実装パターン例として示します。

# Source: https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter
from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    length_function=len,
    is_separator_regex=False,
)
chunks = splitter.create_documents([raw_text])

LlamaIndex の Sentence / Token / Semantic Splitter を使い分ける例です。

# Source: https://developers.llamaindex.ai/python/framework/module_guides/loading/node_parsers/modules/
from llama_index.core.node_parser import (
    SentenceSplitter,
    TokenTextSplitter,
    SemanticSplitterNodeParser,
)
from llama_index.embeddings.openai import OpenAIEmbedding

# (a) 文単位 (FAQ・短文向け)
sent = SentenceSplitter(chunk_size=512, chunk_overlap=64)

# (b) トークン単位 (長文・コスト最適化)
tok = TokenTextSplitter(separator=" ", chunk_size=1024, chunk_overlap=128)

# (c) 意味単位 (技術文書・契約書向け)
sem = SemanticSplitterNodeParser(
    buffer_size=1,
    breakpoint_percentile_threshold=95,
    embed_model=OpenAIEmbedding(),
)

Bedrock 側では Console / API で Standard（Default / Fixed-size / No chunking を内包）/ Hierarchical / Semantic / Multimodal を選ぶだけで同等の機能が得られます。

4. 意味付け（Enrichment）

LlamaIndex の Metadata Extractor を Enrichment 工程に組み込む実装パターン例です。

# Source: https://developers.llamaindex.ai/python/framework/module_guides/loading/documents_and_nodes/usage_metadata_extractor/
from llama_index.core.extractors import (
    TitleExtractor,
    QuestionsAnsweredExtractor,
    SummaryExtractor,
    KeywordExtractor,
)
from llama_index.core.node_parser import TokenTextSplitter
from llama_index.core.ingestion import IngestionPipeline

text_splitter = TokenTextSplitter(separator=" ", chunk_size=512, chunk_overlap=128)
title_extractor = TitleExtractor(nodes=5)
qa_extractor = QuestionsAnsweredExtractor(questions=3)
summary_extractor = SummaryExtractor(summaries=["self", "prev"])
keyword_extractor = KeywordExtractor(keywords=10)

pipeline = IngestionPipeline(
    transformations=[
        text_splitter,
        title_extractor,
        qa_extractor,
        summary_extractor,
        keyword_extractor,
    ]
)
nodes = pipeline.run(documents=documents, in_place=True, show_progress=True)

業務用語辞書（シノニム / 略語）で補強する場合は、Extractor の後段でメタデータに synonyms フィールドを足すアプローチが扱いやすくなります。

# 業務用語辞書による補強 (方法論の実装パターン例)
business_glossary = {"KPI": "Key Performance Indicator", "WBS": "Work Breakdown Structure"}

for node in nodes:
    hits = [k for k in business_glossary if k in node.get_content()]
    if hits:
        node.metadata["synonyms"] = {k: business_glossary[k] for k in hits}

5. 埋め込み（Embedder）

埋め込みモデルは差し替え可能な部品として扱います。OpenAI / Bedrock Titan / Cohere の差し替え例です。

# Source: https://developers.llamaindex.ai/python/framework/module_guides/models/embeddings/
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.embeddings.bedrock import BedrockEmbedding
from llama_index.embeddings.cohere import CohereEmbedding

# (a) OpenAI
embed_openai = OpenAIEmbedding(model="text-embedding-3-large")

# (b) AWS Bedrock Titan
embed_titan = BedrockEmbedding(model_name="amazon.titan-embed-text-v2:0")

# (c) Cohere
embed_cohere = CohereEmbedding(model_name="embed-multilingual-v3.0")

差し替えに伴う注意点として、次元数（dimension）が変わると Vector DB のインデックスを作り直す必要がある点を必ず確認します（Pinecone は dimension、Bedrock KB は vector dimensions パラメータ）。

6. インデックス（Indexer）

Pinecone への書き込みの最小例です。

# Source: https://docs.pinecone.io/guides/get-started/quickstart
from pinecone import Pinecone

pc = Pinecone(api_key="YOUR_API_KEY")
index_name = "rag-context"

if not pc.has_index(index_name):
    pc.create_index_for_model(
        name=index_name,
        cloud="aws",
        region="us-east-1",
        embed={"model": "llama-text-embed-v2", "field_map": {"text": "chunk_text"}},
    )

dense_index = pc.Index(index_name)
records = [
    {"id": n.node_id, "chunk_text": n.get_content(), **n.metadata}
    for n in nodes
]
dense_index.upsert_records("default", records)

LlamaIndex の IngestionPipeline に vector_store= を渡すと、ここまでの transformations と Vector DB 書き込みが 1 本のパイプラインになります。

# Source: https://developers.llamaindex.ai/python/framework/module_guides/loading/ingestion_pipeline/
from llama_index.vector_stores.qdrant import QdrantVectorStore
from llama_index.core.storage.docstore import SimpleDocumentStore

vector_store = QdrantVectorStore(client=client, collection_name="rag-context")

pipeline = IngestionPipeline(
    transformations=[text_splitter, title_extractor, embed_openai],
    vector_store=vector_store,
    docstore=SimpleDocumentStore(),   # DocStore を付けると差分検知が効く
)
pipeline.run(documents=documents)

7. 継続供給（Orchestration）

cron（最小構成）

# Source: crontab(5)
# 毎時 5 分に LlamaIndex pipeline を実行
5 * * * * /home/app/.venv/bin/python /home/app/jobs/run_ingestion.py >> /var/log/rag.log 2>&1

run_ingestion.py は前述の pipeline.run(documents=documents) を呼び出すだけです。docstore（LlamaIndex）が hash で差分検知するため、変更ファイルのみが再処理されます。

Airflow（依存とリトライを管理）

# Source: https://airflow.apache.org/docs/apache-airflow/stable/tutorial/fundamentals.html
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta

with DAG(
    dag_id="rag_context_pipeline",
    start_date=datetime(2026, 1, 1),
    schedule="@hourly",
    catchup=False,
    default_args={"retries": 3, "retry_delay": timedelta(minutes=5)},
) as dag:
    ingest = PythonOperator(task_id="ingest", python_callable=run_ingestion)
    enrich = PythonOperator(task_id="enrich", python_callable=run_enrichment)
    index  = PythonOperator(task_id="index",  python_callable=run_indexing)
    ingest >> enrich >> index

AWS Step Functions（Bedrock KB の差分 Sync）

{
  "Comment": "Trigger Bedrock KB ingestion job hourly",
  "StartAt": "StartIngestionJob",
  "States": {
    "StartIngestionJob": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:bedrockagent:startIngestionJob",
      "Parameters": {
        "KnowledgeBaseId": "ABCDEFGHIJ",
        "DataSourceId": "1234567890"
      },
      "End": true
    }
  }
}

EventBridge スケジュールから 1 時間ごとに呼び出すと、Bedrock KB が差分のみを Embedding + Indexing します。

Azure Logic Apps（AI Search Indexer のスケジュール / リセット）

Azure AI Search は Indexer 自体に schedule.interval を持たせるのが定石で、追加 Orchestrator なしでも差分同期が回ります（例: PT1H で 1 時間ごと）。フルリインデックスや Skillset 再実行が必要な時のみ Logic Apps から POST /indexers/{name}/reset や POST /indexers/{name}/run を呼び出します。

POST https://<svc>.search.windows.net/indexers/rag-indexer/run?api-version=2024-07-01
api-key: <admin-key>
# Source: https://learn.microsoft.com/en-us/azure/search/search-howto-run-reset-indexers

差分検知は Blob の LastModified / SQL の rowVersion / Cosmos DB の _ts を Indexer が内部 high water mark として管理します。

■運用

パイプラインの起動・停止・スケジュール管理

定期同期は二通りに大別されます。一つは Bedrock Knowledge Bases のように同期 API（StartIngestionJob）を外部から叩く方式で、もう一つは Azure AI Search Indexer のようにマネージドのインデクサ自身がスケジュールを持つ方式です。

• Bedrock KB の StartIngestionJob は **0.1 req/sec（10 秒に 1 回）**のハードリミットがあります（docs.aws.amazon.com/bedrock/latest/userguide/quotas.html）。EventBridge や S3 通知で連発するとすぐ Throttling になるため、SQS で平準化してから Lambda が逐次キックする構成が現実的な定石です（AWS 公式参考実装: github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases）。
• Azure AI Search Indexer はスケジュール実行（最短 5 分間隔、最長 24 時間間隔）に加え、On-Demand 実行も可能です。連続失敗時はバックオフが 2h〜24h でキャップされるため、ジョブ状態管理は Indexer のステータスを真実とみなすのが安全です。
• LlamaIndex / LangChain で自前構築する場合は Prefect か Dagster に寄せると後段の lineage が活きます。Dagster は asset 中心で「どの chunk が何由来か」を asset graph として持てるため、RAG の素材管理に親和的です。Prefect は Python ネイティブで動的 DAG が組みやすく軽量です。

差分検知 / CDC と再インデックス戦略

差分検知の難しさは「何を unchanged の根拠にするか」を決めることに集約されます。

• オブジェクトストレージ起点: S3 Event Notifications → EventBridge → Lambda → Bedrock KB or 自前 Pipeline、というイベント駆動が低レイテンシで標準的です。Bedrock KB は内部で「前回 sync 以降に追加 / 変更 / 削除されたオブジェクト」のみを処理します。
• RDB 起点: Azure AI Search Indexer の High Water Mark 方式は monotonically increasing なカラム（推奨 rowversion）に対するポインタを持ちます。注意点として、HWM は行削除を検知できません。別途 soft-delete policy を併用するか、SQL Integrated Change Tracking に切り替える必要があります。
• LlamaIndex IngestionPipeline: (node, transformation) ペアの cache と docstore ベースの dedup を持ち、management strategy として upserts / duplicates_only / upserts_and_delete が選べます。フル同期（削除反映含む）には upserts_and_delete を選ぶ必要があります。
• イベント駆動 vs ポーリング: イベント駆動は鮮度に優れる一方で下流の rate limit（Bedrock 0.1 RPS など）を直撃するため、SQS や DynamoDB で必ずバッファします。ポーリングはレイテンシが schedule 間隔分だけ遅れますが、HWM のように削除を検知できない方式と組み合わせると古い chunk が残り続けるリスクがあります。

状態確認（PipelineRun の追跡、件数モニタリング）

• LangSmith は @traceable デコレータで関数を包むだけで retriever / tool call / latency / cost を span として記録します。LangChain 非依存で LlamaIndex / OpenAI SDK / Anthropic SDK にも貼れます。
• LlamaIndex は llama-index-observability-otel で Workflow ステップを OpenTelemetry span として自動出力できます。Langfuse / Arize Phoenix / SigNoz に流して保管するのが定番です。
• Dagster の asset materialization は「どの run でいくつ chunk が作られたか」を asset metadata として自動記録するため、chunk_count / embedding_count / failed_doc_count を運用 KPI に直結できます。

ログ確認（失敗ドキュメントのトリアージ）

失敗ドキュメントは「再試行で復旧するもの」と「パーサ起因で構造的に直らないもの」を分けて扱います。

• リトライ可能（rate limit / 一時的なネットワーク失敗 / モデルの過負荷） → DLQ に積んで指数バックオフで再投入。
• パーサ失敗（壊れた PDF / 暗号化されたファイル / OCR 不能なスキャン） → 別ルートにルーティングし、Azure Document Intelligence や AWS Textract など OCR 強めのパーサに渡し直す手順を運用に組み込みます。

スケール（並列度、エンベディング rate limit）

Embedding は入力を複数文字列で 1 リクエストにまとめるのが最も安価で、asyncio.gather + semaphore で並列度を制御するのが標準パターンです。

バージョン管理（チャンク戦略変更時の再構築 vs 増分）

チャンクサイズ / overlap / splitter を変えた場合、source document の checksum は変わらないので CDC は変化を検知できません。事実上、フル再インデックスが必要になります。Bedrock KB はデータソースを削除して作り直す手順、Pinecone / Weaviate は別 namespace / class に新バージョンを構築して切替える blue-green 戦略が安全です。embedding model を差し替える場合も同様で、インデックス全体を再生成します。

来歴（lineage）と監査ログの保持

• OpenLineage が業界標準で、Job / Run / Dataset を起点に Airflow / Spark / dbt / Debezium（2025-06 から native）と連携します。ただしRAG 専用の facet（chunk / embedding）は標準仕様化されていないため、embedding テーブル / vector index を Dataset としてモデル化するのは各チームの設計責任です。
• vector metadata に doc_id / chunk_id / source_uri / content_hash / embedding_model / embedding_version を必ず格納すると、後段の lineage クエリと「特定モデル版で作った chunk だけ削除」のような運用が成立します。
• 監査ログは「いつ・誰の権限で・どの document が・どの chunk となって・どの index に入り・どの query で検索されたか」を追跡可能にすることが GDPR / SOC2 上の要件になります。

■ベストプラクティス

チャンク戦略

誤解: 「semantic chunking が最強なので fixed-size はもう使わなくていい」。

反証: 複数の chunking 比較ベンチマークでは recursive 512-token splitting が安定して上位を占めます。semantic chunking はチャンク長の分布が暴れて retrieval の calibration を壊す例が報告されています。Anthropic の Contextual Retrieval も Recursive を前提に「各 chunk に 50〜100 トークンの文脈付与」を上乗せする発想で、Recursive 自体を否定はしていません。

推奨:

• 既定は Recursive 256〜512 tokens / overlap 10〜20%。
• 長尺で相互参照のある文書（規程 / RFC / マニュアル）は **Hierarchical（Parent-Document）**で「子で precision、親で context」を分離。
• 異種文書が混ざるコーパスのみ Semantic を試す。
• Contextual Retrieval は適用すれば retrieval failure を 35% 削減、+BM25 で 49%、+reranker で 67% 削減 が報告されていますが、chunk 数 × LLM 呼び出し回数のコスト（prompt caching 前提で約 $1.02 / M doc tokens）を見積もってから判断します。

意味付け（Enrichment）の運用

誤解: 「業務用語辞書を 1 度作れば LLM が解釈してくれる」。

反証: 辞書はメンテされないと「2 年前の組織名が現役」「廃止された商品コードがそのまま」のように汚染源になります。Enrichment LLM 呼び出しは chunk 単位なので 1,000 文書 × 50 chunk = 50,000 呼び出し に容易に膨らみます。

推奨:

• 辞書のオーナーシップを業務部門に置き、レビュー周期（四半期 / プロダクトリリース連動）を契約として明文化します。
• 単一 LLM 呼び出しで複数フィールド（title / summary / entities / topic tags）を一気に抽出する MDKeyChunker パターンでコスト平準化。
• 人手レビューは「上位 retrieval 失敗 query 100 件」の chunk に限定し全数レビューを避けます。

継続供給の設計

誤解: 「夜間バッチで全文洗い替えすれば差分管理は不要」。

反証: 全文洗い替えは大規模化すると embedding API のコストと vector DB のスループットが二重に効いてきて、Bedrock の 0.1 RPS や OpenAI の Tier 1 1M TPM をすぐ超えます。

推奨:

• イベント駆動（S3 Event / Azure Event Grid）をSQS / Event Hub でバッファしてから downstream の rate limit に合わせて消化。
• ポーリングは「削除検知が可能な change-tracking 方式」を選ぶか、別途 soft-delete を実装します。
• Bedrock KB のような managed は incremental sync を持つので、外部 orchestrator はトリガーだけ担当し中身は KB に任せると運用負荷が下がります。

評価メトリクスの継続計測

誤解: 「RAGAS の faithfulness が 0.9 を超えれば本番投入してよい」。

反証: RAGAS / TruLens / Bedrock KB Evaluation は LLM-as-judge が前提で、position bias（順序入替で精度が変動）、verbosity bias（長い回答を好む）、self-preference bias（GPT-4 judge は GPT-4 出力を高評価）が文献化されています（CALM フレームワークによる 12 種類のバイアス包括分析）。RAGAS スコア 5% 未満の差分はノイズと扱うのが安全です。

推奨:

• RAG triad（context relevance / groundedness / answer relevance、TruLens）を最小セットとして CI に組み込みます。
• 評価 judge は2 つ以上のモデルファミリ（例: Claude + GPT）で並走させ、定期的に人手ラベルでキャリブレーション。
• Bedrock KB Evaluation（2025-03 GA、citation coverage / citation precision を追加）はマネージドで完結するので AWS 系では第一候補。

セキュリティ / ガバナンス

誤解: 「ベクトル化したら元の PII は残らない」。

反証: embedding は近傍探索で意味的な復元（embedding inversion attack）が可能とされ、PII 含み chunk の「実質的削除」には raw chunk + embedding 双方を消す必要があります。

推奨:

• 埋め込み前に Microsoft Presidio や AWS Comprehend で PII を pseudonymize（[PERSON_1] 置換）。完全削除より意味保存に優れます。
• アクセス制御は metadata filtering（Bedrock KB の vectorSearchConfiguration / Azure AI Search の security trimming）で行いますが、フィルタ適用はアプリ側責務であり漏洩リスクとして audit 必須です。Defense-in-depth として Amazon Verified Permissions + Cedar policy を併用する AWS 推奨パターンがあります。
• GDPR の right-to-be-forgotten では、Pinecone serverless は delete-by-metadata の扱いに制約がある場合があり（ID prefix 削除での代替を検討し最新ドキュメントで要確認）、Weaviate は delete_many だが QUERY_MAXIMUM_RESULTS 上限まで繰り返す必要があるなど、ベンダ別の落とし穴を把握しておきます。

コスト最適化

誤解: 「vector DB のストレージ費用が支配的」。

反証: ランタイムでは LLM generation コストが 70〜85%、embedding 5〜15%、storage 5% 未満、rerank 5〜10% が業界記事の概算（構成・ワークロード依存）で、リランカや caching を入れることで LLM context が短くなって総コストが下がる 構造です。

推奨:

• Reranker を入れる（最も ROI 高い単一打ち手）。Cohere Rerank 3.5 で金融ドメインの dense retrieval 比 +25% 精度、Voyage rerank-2 で OpenAI v3-large に +13.89% 精度の報告。candidate を 50〜100 に絞ってから cross-encoder にかけ、LLM 入力 chunk 数を 3〜5 まで削ります。
• Semantic cache（GPTCache 等）。hit 率 18〜68.8% / 最大 98.5%、コスト 60〜85% 削減、latency 2.5s → 200〜400ms の報告がありますが、stale hit のリスクとトレードオフです。
• chunk strategy 変更時のフル再 embedding は予算化（数万〜数百万 token の埋め込みコストが一気に発生）。

マルチテナント / マルチドメイン分離

誤解: 「テナント毎に index を分けるのが一番安全」。

反証: 100 テナント超では運用と料金が線形に増え、Pinecone serverless / Weaviate の native multi-tenancy のほうが効率的です。

推奨:

100 テナント未満は metadata filter、1,000 テナント以上 B2B SaaS は Weaviate native MT、強規制のみ index 分離が一般解です。

反証 / 限界 / Caveat

「Context Engineering で全部解決」は誇張

• fine-tuning が優位な領域: 出力スタイル / フォーマット / 分類が固定で、知識が小さく静的な場合は fine-tuning が retrieval なしでも十分です。Menlo Ventures 2024+2025 のエンタープライズ調査では採用順は prompt > RAG > fine-tuning で、fine-tuning は niche に留まりますが、**最先端パターンは「軽い fine-tune + RAG のハイブリッド」**に収束しつつあります。
• long-context が retrieval を不要にする説への反証: Chroma "Context Rot"（2025-07-14、18 frontier models）は**「コンテキストが伸びるほど性能が一様に劣化する」ことを単純タスクですら実証し、特に LongMemEval で「関連箇所だけ 300 tokens」が「全文 113k tokens」を有意に上回る**ことを示しました。1M-token window を持つことが retrieval をスキップしてよい根拠にはなりません。
• lost-in-the-middle（Liu et al., TACL 2024、arXiv プレプリント 2023-07）: 文脈の中央に置かれた関連情報の精度が U 字に落ちます。RAG 設計では best chunk を context 先頭と末尾に置く / k を 5〜10 に絞るが実務的な落とし所です。

評価メトリクス（RAGAS 等）自体のバイアス

• LLM-as-judge は position / verbosity / self-preference bias を構造的に持つことが arXiv で文献化されています。
• RAGAS のスコア絶対値ではなく、同一 judge での相対変化を見ること。差分が 5% 未満ならノイズ範囲とみなす。
• 定期的に人手ラベル（数十件で十分）で calibration し、judge を更新したら過去スコアと比較しないこと（再ベースライン化）。

業務用語辞書の継続更新コスト

• 辞書のオーナーシップを業務部門に置き、レビュー周期を契約として明文化しない限り、辞書は半年で陳腐化します。
• 「辞書 LLM 解釈に任せる」を前提に設計すると、組織変更 / 商品名変更で retrieval 品質が静かに劣化していきます。

ベンダロックイン

• Bedrock KB は incremental sync / 評価機能 / metadata filtering が密結合で快適な反面、ingest job rate limit（0.1 RPS）や同時実行 5 などの制約に運用が縛られます。data source の作り直しでチャンク戦略を変える前提も AWS スタックに閉じています。
• Azure AI Search の skillset（OCR / KeyPhrase / Custom Skill）も独自で、Bedrock や Vertex AI への移植は大幅な書き直しが必要です。
• ロックインを避けたい場合は LlamaIndex / LangChain など OSS フレームワークを抽象層として挟み、vector store を Pinecone / Weaviate / pgvector に分離 する pattern を採るのが現実解です。

"Context Rot" の最大の含意

Chroma の "Context Rot" は**「shuffled haystack のほうが logically coherent な haystack より良い」という反直感的な結果を含み、これは「文脈は構造化すればするほど良い」という素朴な前提を覆します。長文脈を整えるより小さく的確に retrieval するほうが安定するという、「Context Engineering ≠ より多くの context を詰める」**という結論につながっています。

■トラブルシューティング

主要な症状 → 原因 → 対処マトリクス

切り分けの順序

1. retrieval が当たっているかを query log + top-k chunk dump で目視確認します。
2. 当たっていればreranker / prompt / context precisionの問題、当たっていなければchunk / embedding model / hybridの問題、と二分します。
3. 「更新が反映されない」は書き込み時点で freshness 確認（Pinecone LSN, Azure indexer status）→ CDC で削除を拾えているか確認 → cache の stale hit を疑う、の順で進めます。

■まとめ

Context Data Pipeline for RAG は、業務 RAG の「薄い回答」の正体をモデル限界ではなくパイプライン上流の意味付け不足と捉え、収集・クレンジング・意味付け・ベクトル化・差分同期を責務ごとに分離して継続運用する設計思想です。LlamaIndex / Unstructured / Bedrock KB / Azure AI Search といった実装の選び分け、チャンク戦略・enrichment・継続供給・評価・コスト・ガバナンスの各論点を、誤解と反証つきで整理しました。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

■参考リンク

起点・国内事例

• ITmedia ビジネスオンライン: 日本ハム RAG 事例（起点記事）
• 株式会社システムサポート: 日本ハム Smart Generative Chat 事例
• Microsoft Customer Stories: 日本ハム Azure OpenAI Service 活用 GC 分析事例
• 日経クロステック: RAGの精度向上、「AI-Ready」データを作るコンテキストエンジニアリング
• note 言語理解研究所: 社内RAGの回答精度が上がらない本当の理由

Context Engineering 言説

• Anthropic: Effective context engineering for AI agents
• Andrej Karpathy on X: context engineering 提唱投稿
• Anthropic: Contextual Retrieval

LlamaIndex 公式

• LlamaIndex IngestionPipeline
• LlamaIndex Documents and Nodes
• LlamaIndex MetadataExtractor
• LlamaIndex Node Parsers / Splitters
• LlamaIndex SimpleDirectoryReader
• LlamaIndex Document Management Pipeline
• LlamaIndex RAG failure-mode checklist
• LlamaIndex OpenTelemetry observability
• LlamaParse

Unstructured / LangChain 公式

• Unstructured.io: Welcome
• Unstructured.io: Platform Overview
• Unstructured Partitioning
• Unstructured Document Elements
• Unstructured chunking best practices
• LangChain Document overview
• LangChain RecursiveCharacterTextSplitter

AWS Bedrock 公式

• Amazon Bedrock Knowledge Bases
• Bedrock KB - Create a Knowledge Base
• Bedrock KB - Chunking & Parsing
• Bedrock KB - data sources
• Bedrock KB - data ingestion
• Bedrock StartIngestionJob API
• Bedrock quotas
• Bedrock KB Evaluation（RAG eval & LLM-as-judge）
• Bedrock KB auto-sync ref impl
• Bedrock KB access control via metadata
• Bedrock GDPR right-to-be-forgotten

Azure AI Search 公式

• Azure AI Search Indexer Overview
• Azure AI Search AI enrichment 概要
• Azure AI Search Skillset definition
• Azure AI Search Create an Indexer
• Azure AI Search Run / Reset Indexers
• Azure AI Search SQL indexer
• Azure AI Search Blob change/delete
• Azure AI Search document-level access
• Azure AI Search Indexer troubleshooting

Vector DB 公式

• Pinecone Quickstart
• Pinecone upsert / data freshness
• Pinecone database limits
• Pinecone update/delete by metadata
• Pinecone multi-tenancy
• Weaviate data import
• Weaviate delete by filter
• Databricks Vector Search (AI Search) 概要

評価 / Observability / Lineage

• RAGAS Metrics overview
• TruLens RAG Triad
• LangSmith observability
• OpenLineage 公式
• Debezium × OpenLineage native integration
• Confident AI: RAG Evaluation Metrics
• INVRA: How to Evaluate RAG Pipelines with RAGAS

反証 / 限界（一次論文）

• Lewis et al. 2020 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"（NeurIPS 2020、RAG 原典）
• Lost in the Middle: How Language Models Use Long Contexts（Liu et al., TACL 2024 / arXiv 2023-07）
• Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma Research, 2025-07-14）
• Justice or Prejudice? Quantifying Biases in LLM-as-a-Judge（CALM, 12 種類のバイアス包括分析）
• Self-Preference Bias in LLM-as-a-Judge
• From BM25 to Corrective RAG: Benchmarking Retrieval Strategies for Text-and-Table Documents (arXiv:2604.01733)

業界記事 / 実装ノウハウ

• Cohere Rerank 3.5
• Reranking guide（Ranjan Kumar）
• HyDE 解説
• NirDiamant RAG_Techniques repo
• Firecrawl chunking benchmark
• Firecrawl PDF parser 2026 review
• LangCopilot Document chunking guide
• abhs.in: RAG in production cost guide 2026
• Hybrid search for RAG
• Kapa.ai: How to Build a RAG Pipeline from Scratch in 2026
• Cloudian: RAG Architecture 4 Key Components
• NVIDIA Technical Blog: RAG 101

関連既存資産

• 長時間エージェントのコンテキスト設計（context-engineering-agents.md, 2026-06-11）