背景: 社内の技術文書38,000件が多様なプラットフォームに散在し、開発チーム200名が必要な情報を見つけるのに1日平均30分を費やしている。既存の全文検索では言い換えや意味的な検索に対応できず、結果として「詳しい人に聞く」という非効率な情報共有が常態化している。

提案: RAG（Retrieval-Augmented Generation）技術を活用した社内ナレッジ検索システムを構築する。自然言語で質問すれば、社内の技術文書・議事録・FAQから根拠付きの回答が得られるシステムにより、情報アクセス時間を80%削減する。

投資:

• 初期構築費: 約300万円（開発3名 × 6ヶ月の工数除く）
• 年間ランニングコスト: 約300万円（API利用料 + インフラ費）

効果:

• 情報検索時間の削減: 200名 × 30分 × 80% × 250日 = 年間20,000時間削減
• 人件費換算: 年間約1.2億円の効率化効果
• ROI: 初年度 2,000%超

タイムライン:

• Phase 1（0-3ヶ月）: Naive RAG + Reranking。技術文書対象でPoC
• Phase 2（3-6ヶ月）: Advanced RAG。全ドキュメント対象で本番リリース
• Phase 3（6-12ヶ月）: 精度最適化、利用拡大、高度なパターン導入

アーキテクチャ進化計画:

技術スタック:

チャンキング戦略:

パイプライン:

• トリガー: Webhook（Confluence/Notion） + EventBridge（定期同期）
• 処理: SQS → Step Functions → Lambda
• 冪等性: コンテンツハッシュによる変更検知
• 監視: CloudWatch → Slack通知

パイプラインフロー:

Query → フィルタ抽出(Haiku) → Embedding(OpenAI) → Hybrid Search(Qdrant)
→ RRF統合(Top-15) → Reranking(Cohere, Top-5) → Prompt構築
→ LLM生成(Claude Sonnet) → 回答 + 参照元

ハイブリッド検索: ベクトル検索(alpha=0.6) + BM25(alpha=0.4)、RRF(k=60)で統合

プロンプト設計: コンテキストのみに基づく回答を指示、参照元明示、不明時の対応を定義

A/Bテスト: 評価データセット100件、1週間のA/Bテストで効果検証。Precision@5が10%以上向上をGo基準とする。

評価目標:

運用:

• インデックス更新: 差分更新（日次）+ Blue-Green全量再構築（月次）
• モニタリング: CloudWatch + Grafanaダッシュボード
• コスト: 月30万円以内。セマンティックキャッシュとモデルティアリングで最適化

主要リスク:

ロードマップ:

推進体制:

• PM: 1名（プロジェクト管理、ステークホルダー調整）
• バックエンドエンジニア: 2名（パイプライン、API開発）
• インフラエンジニア: 1名（ベクトルDB、AWS構成）