演習：ドキュメント処理パイプラインを構築しよう

ストーリー

田

田中VPoE

ドキュメントローディング、チャンキング、メタデータ、パイプライン — 理論はすべて学んだ。ここからは実際にNetShop社のドキュメント処理パイプラインを設計してもらう

あなた

技術文書、議事録、FAQの3種類ですね

あ

田

田中VPoE

そうだ。しかも各種類でフォーマットが違う。技術文書はMarkdownとConfluence、議事録はGoogle Docs、FAQは社内Wiki。それぞれに最適なチャンキング戦略とメタデータスキーマを設計し、統合パイプラインにまとめてくれ

あなた

かなりの設計ボリュームですね

あ

田

田中VPoE

実際のプロジェクトではこの設計が最も時間がかかる。「とりあえず動く」ではなく「運用で問題が出ない」レベルの設計を期待している

ミッション概要

項目	内容
演習タイトル	ドキュメント処理パイプラインの構築
想定時間	90分
成果物	ドキュメント処理設計書（チャンキング戦略 + メタデータスキーマ + パイプライン設計）

前提条件

ドキュメントソースの詳細

ソース	件数	形式	平均長	更新頻度	特徴
技術文書	5,000件	Markdown（60%）、Confluence（40%）	3,000文字	週次	コードブロック多い、ヘッダー構造あり
議事録	30,000件	Google Docs	1,500文字	日次	日時・参加者情報あり、アクションアイテム含む
FAQ	3,000件	社内Wiki（HTML）	500文字	月次	Q&Aペア形式、カテゴリタグあり

Mission 1: ドキュメント種別ごとのチャンキング戦略設計

要件

3種類のドキュメントそれぞれについて、以下を設計してください。

チャンキング手法の選定と理由
チャンクサイズとオーバーラップの設定
特殊要素の処理方針（コードブロック、テーブル、リスト等）
チャンキングの処理フロー図

解答例

技術文書のチャンキング

項目	設定	理由
手法	構造ベース + 階層的チャンキング	ヘッダー構造が明確、セクション単位が意味的にまとまっている
Parentチャンク	セクション単位（H2レベル）	LLMに渡す際の十分なコンテキスト
Childチャンク	サブセクション単位（H3レベル）、最大500トークン	検索精度の向上
オーバーラップ	10%（構造境界では不要）	構造ベースのため最小限で十分
コードブロック	独立チャンクとして抽出、言語タグをメタデータに付加	コード検索の精度向上
テーブル	Markdownテーブルはテキスト化して本文に含める	テーブルの意味を保持

議事録のチャンキング

項目	設定	理由
手法	固定長チャンキング + 議題ベース分割	構造が一定でない議事録は固定長がベース
チャンクサイズ	400トークン	議事録は短い文が多く、小さめが適切
オーバーラップ	20%	発言の文脈が途切れないように
議題分割	「議題」「アジェンダ」等のキーワードで分割可能なら優先	意味的なまとまりを保持
アクションアイテム	独立チャンクとして抽出	「誰がいつまでに何をする」を検索しやすく

FAQのチャンキング

項目	設定	理由
手法	Q&Aペア単位	質問と回答は分割不可。1ペア=1チャンク
チャンクサイズ	1ペアの全文（上限1000トークン）	FAQは短いため丸ごと格納
オーバーラップ	なし	ペア単位なので不要
関連FAQ	メタデータにリンクを格納	関連質問への誘導

Mission 2: メタデータスキーマ設計

要件

以下のメタデータスキーマを設計してください。

共通メタデータ（全ドキュメント種別で共通）
種別固有メタデータ（技術文書/議事録/FAQ各々）
エンリッチメントメタデータ（LLM生成）
各フィールドの型、必須/任意、用途

解答例

共通メタデータ

フィールド	型	必須	用途
chunk_id	string	必須	チャンクの一意識別子
doc_id	string	必須	元ドキュメントの識別子
doc_type	enum	必須	”技術文書” / “議事録” / “FAQ”
source	string	必須	”confluence” / “google_docs” / “wiki”
source_url	string	必須	元ドキュメントへのリンク
created_at	datetime	必須	作成日時
updated_at	datetime	必須	更新日時
author	string	任意	作者名
department	string	任意	部門名
content_hash	string	必須	コンテンツのハッシュ（冪等性用）

技術文書固有メタデータ

フィールド	型	必須	用途
section_title	string	必須	セクション見出し
breadcrumb	string	必須	パンくずパス
tech_stack	string[]	任意	関連技術（例: “Python”, “AWS”, “Docker”）
has_code	boolean	必須	コードブロックの有無
code_language	string	任意	コードの言語
parent_chunk_id	string	任意	親チャンクのID（階層的チャンキング用）

議事録固有メタデータ

フィールド	型	必須	用途
meeting_date	date	必須	会議日
participants	string[]	任意	参加者一覧
project	string	任意	プロジェクト名
has_action_item	boolean	必須	アクションアイテムの有無
agenda_topic	string	任意	議題

FAQ固有メタデータ

フィールド	型	必須	用途
question	string	必須	質問文
category	string	必須	FAQカテゴリ
related_faqs	string[]	任意	関連FAQのID
view_count	integer	任意	閲覧数（人気度ランキング用）

エンリッチメントメタデータ（全種別共通）

フィールド	型	生成方法	用途
summary	string	LLM要約	検索結果プレビュー
keywords	string[]	LLM抽出	キーワード検索補完
hypothetical_questions	string[]	LLM生成	検索ヒット率向上

Mission 3: 統合パイプライン設計

要件

以下の統合パイプラインを設計してください。

パイプラインのアーキテクチャ図（AWS構成）
バッチ処理と差分更新の設計
エラーハンドリング方針
監視・アラート設計
コスト試算（月額）

解答例

アーキテクチャ図

[ドキュメントソース]
Confluence → Webhook → API Gateway → SQS
Notion     → ポーリング（Lambda Cron） → SQS
S3         → S3 Event → SQS

[処理パイプライン]
SQS → Step Functions
  ├── Step 1: ドキュメント取得（Lambda）
  ├── Step 2: テキスト抽出 + クリーニング（Lambda）
  ├── Step 3: チャンキング（Lambda）
  ├── Step 4: メタデータエンリッチメント（Lambda → OpenAI API）
  ├── Step 5: Embedding生成（Lambda → OpenAI API）
  └── Step 6: Qdrant Upsert（Lambda）

[監視]
CloudWatch Metrics + Logs → アラート → Slack

コスト試算（月額）

項目	算出根拠	月額
OpenAI Embedding API	38,000件 × 平均5チャンク × $0.00002/1Kトークン	約2万円
OpenAI LLM（メタデータ生成）	38,000件 × $0.003/1Kトークン	約5万円
AWS Lambda	実行回数 × 実行時間	約1万円
AWS Step Functions	状態遷移数	約0.5万円
Amazon SQS	メッセージ数	約0.1万円
合計		約8.6万円

差分更新（月間変更分のみ）の場合: 約2万円/月

達成度チェック

観点	達成基準
チャンキング戦略	3種類のドキュメントそれぞれに適切な手法が選定され、理由が明確
メタデータスキーマ	共通/種別固有/エンリッチメントが体系的に設計されている
パイプライン設計	バッチ/差分更新の両方が設計され、AWSサービスが具体的に選定されている
エラーハンドリング	リトライ、スキップ、アラートの方針が定義されている
コスト試算	月額コストが具体的に算出されている
運用考慮	監視、ログ、冪等性が設計に組み込まれている

推定所要時間: 90分