ストーリー
田
田中VPoE
RAGの全体像、Embedding、ベクトルDB — 基礎理論は一通り学んだ。ここからは実践だ。NetShop社の社内ナレッジ検索システムのRAGアーキテクチャを設計してもらう
あなた
いよいよ設計ですね。具体的な要件はありますか？
あ
田
田中VPoE
もちろんだ。社内の技術文書、議事録、FAQの3種類のドキュメントを対象に、自然言語で質問して的確な回答を返すシステムだ。開発チーム200名が日常的に使う想定だ
あなた
かなりの規模ですね。どこまで精度を求めますか？
あ
田
田中VPoE
「回答の80%以上が正確」をまず目指す。PoCでNaive RAGから始めて、段階的にAdvanced RAGへ進化させる計画を立ててくれ
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | RAGアーキテクチャ設計 |
| 想定時間 | 60分 |
| 成果物 | RAGアーキテクチャ設計書（要件整理 + 技術選定 + 段階的ロードマップ） |
前提条件
NetShop社の社内ナレッジ
| 項目 | 内容 |
|---|---|
| 技術文書 | 約5,000件（Markdown、Confluence） |
| 議事録 | 約30,000件（Google Docs、Notion） |
| FAQ | 約3,000件（社内Wiki） |
| 合計ドキュメント数 | 約38,000件 |
| 平均ドキュメント長 | 約2,000文字 |
| 更新頻度 | 技術文書: 週次、議事録: 日次、FAQ: 月次 |
| 利用者 | 開発チーム200名 |
| 想定クエリ数 | 1日あたり500件 |
| 言語 | 日本語90%、英語10% |
技術制約
| 項目 | 制約 |
|---|---|
| クラウド | AWS利用中 |
| 予算（年間） | 500万円（インフラ + API利用料） |
| 開発チーム | エンジニア3名（6ヶ月） |
| セキュリティ | 社内ネットワーク内で完結（外部データ送信の制限あり） |
Mission 1: 要件定義とアーキテクチャ選定
要件
以下の項目について整理し、RAGアーキテクチャを選定してください。
- 機能要件の整理（検索機能、回答形式、対話機能等）
- 非機能要件の整理（精度、レイテンシ、可用性、セキュリティ）
- RAGアーキテクチャの選定（Naive/Advanced/Modular）とその理由
- 段階的進化計画（Phase 1→Phase 2→Phase 3）
解答例
機能要件
| 要件ID | 機能 | 優先度 |
|---|---|---|
| F-01 | 自然言語による質問・検索 | 必須 |
| F-02 | 回答の根拠ドキュメントの提示 | 必須 |
| F-03 | ドキュメント種別によるフィルタリング | 必須 |
| F-04 | 部門・プロジェクト別の絞り込み | 推奨 |
| F-05 | フォローアップ質問への対応 | 推奨 |
| F-06 | 回答へのフィードバック機能 | 推奨 |
非機能要件
| 要件 | 目標値 | 根拠 |
|---|---|---|
| 回答精度 | 80%以上（Phase 1）、90%以上（Phase 2） | ユーザーの信頼獲得に必要 |
| レイテンシ | 5秒以内 | ユーザー体験の観点 |
| 可用性 | 99.5%（平日営業時間） | 業務利用のため |
| 同時接続 | 50ユーザー | ピーク時の想定 |
| セキュリティ | 社内ネットワーク内完結 | 制約条件 |
アーキテクチャ選定
Phase 1: Naive RAG + Reranking（3ヶ月目標）
選定理由:
- 38,000件は中規模であり、Naive RAGでも十分なベースライン精度が見込める
- Rerankingを追加することで、低コストで精度を向上できる
- 3名チームで3ヶ月という制約内で実装可能
Phase 2: Advanced RAG（6ヶ月目標）
- Pre-Retrieval: Query Rewriting追加
- Post-Retrieval: Cross-Encoder Reranking強化
- ハイブリッド検索（ベクトル + BM25）導入
Phase 3: Modular RAG（12ヶ月目標）
- ドキュメント種別ごとのルーティング
- 自己反省型RAG（Self-RAG）の導入
- 評価・改善の自動化パイプライン
Mission 2: 技術スタック選定
要件
前提条件と制約を踏まえて、以下の技術選定を行ってください。
- Embeddingモデルの選定（理由付き）
- ベクトルDBの選定（理由付き）
- LLMの選定（理由付き）
- フレームワークの選定（LangChain/LlamaIndex等）
- 全体アーキテクチャ図の作成
解答例
技術選定
| コンポーネント | 選定 | 理由 |
|---|---|---|
| Embeddingモデル | text-embedding-3-small（OpenAI） | 日本語対応良好、コスト効率が高い、1536次元 |
| ベクトルDB | Qdrant（セルフホスト on AWS） | 高パフォーマンス、ハイブリッド検索対応、OSSでコスト抑制 |
| LLM | Claude 3.5 Sonnet（Anthropic） | 日本語の回答品質が高い、200Kトークンの長コンテキスト |
| Reranker | Cohere Rerank v3 | 日本語対応、API利用で運用負荷低 |
| フレームワーク | LangChain（Python） | エコシステムが充実、各コンポーネントとの統合が容易 |
| インフラ | AWS ECS + RDS + S3 | 既存AWS環境を活用 |
全体アーキテクチャ図
[ユーザー]
↓ 質問
[API Gateway（FastAPI on ECS）]
↓
[Query Processor]
├── Embedding（OpenAI API）
└── BM25 Index（Qdrant）
↓
[Qdrant（ベクトルDB on EC2）]
↓ Top-20結果
[Reranker（Cohere API）]
↓ Top-5結果
[Prompt Builder]
↓
[LLM（Claude API）]
↓ 回答 + 参照元
[ユーザー]
[バッチ処理（EventBridge + Lambda）]
├── ドキュメント取得（Confluence/Notion/Wiki API）
├── チャンキング + Embedding
└── Qdrant Upsertコスト試算
| 項目 | 月額 | 年額 |
|---|---|---|
| OpenAI Embedding API | 3万円 | 36万円 |
| Cohere Rerank API | 5万円 | 60万円 |
| Anthropic Claude API | 15万円 | 180万円 |
| AWS インフラ（ECS + EC2 + RDS） | 10万円 | 120万円 |
| 合計 | 33万円 | 396万円 |
予算500万円以内に収まる。
Mission 3: リスク分析と対策
要件
以下のリスク分析を行い、対策を立案してください。
- 技術リスク（精度不足、レイテンシ超過等）
- 運用リスク（ドキュメント更新の遅延、コスト超過等）
- セキュリティリスク（データ漏洩、プロンプトインジェクション等）
- 各リスクへの緩和策
解答例
リスク分析表
| リスク | カテゴリ | 影響度 | 発生確率 | 緩和策 |
|---|---|---|---|---|
| 検索精度が目標80%に達しない | 技術 | 高 | 中 | Phase 1で精度測定→ボトルネック特定→チャンキング戦略・Reranking調整で改善 |
| 日本語Embeddingの品質不足 | 技術 | 高 | 低 | multilingual-e5-largeをフォールバックとして検証済みにしておく |
| レイテンシが5秒を超過 | 技術 | 中 | 中 | ベクトルDB側のインデックスチューニング、LLMのストリーミング応答で体感速度改善 |
| ドキュメント更新パイプラインの障害 | 運用 | 中 | 中 | 更新ジョブの監視、障害時のアラート、手動トリガーの用意 |
| API利用料の想定超過 | 運用 | 中 | 中 | 月次コストモニタリング、セマンティックキャッシュの導入検討 |
| 社外へのデータ送信（セキュリティ制約） | セキュリティ | 高 | 低 | Embedding/LLM APIへの送信データの匿名化、社外送信データのログ記録・監査 |
| プロンプトインジェクション | セキュリティ | 高 | 中 | 入力バリデーション、システムプロンプトの分離、出力フィルタリング |
Phase 1のPoC成功基準
| 指標 | 基準値 | 測定方法 |
|---|---|---|
| 回答精度 | 80%以上 | 100件のテスト質問で人手評価 |
| レイテンシ P95 | 5秒以内 | パフォーマンステスト |
| ユーザー満足度 | 4.0/5.0以上 | パイロットユーザーアンケート |
| 日次コスト | 1万円以内 | コストモニタリング |
達成度チェック
| 観点 | 達成基準 |
|---|---|
| 要件定義 | 機能要件・非機能要件が具体的に整理されている |
| アーキテクチャ選定 | 段階的進化計画（Phase 1→2→3）が合理的に設計されている |
| 技術選定 | 各コンポーネントの選定理由が明確で、制約条件を満たしている |
| コスト試算 | 年間予算500万円以内に収まる見積もりが提示されている |
| リスク分析 | 技術・運用・セキュリティの3観点でリスクと緩和策が整理されている |
| PoC基準 | 成功/撤退の判断基準が定量的に定義されている |
推定所要時間: 60分