こんにちは！SCSKの野口です。
早速ですが皆さんに質問です。
「業務でRAGを活用していますか？」
本記事は、これからTechHarmoneyでRAGに関する記事をシリーズとして執筆していくにあたり、なぜ書こうと思ったのか、
そして今後どのようなテーマを扱う予定かを最初に整理する”プロローグ”です。
背景：ドキュメントはあるのに、探すのが難しい
私は普段、アプリケーション基盤（AP基盤）チームに所属しており、業務チームから基盤部品に関する質問を受けることがあります。
AP基盤部品は部品の提供だけでなく、方式書や開発ガイドも公開しており、業務チーム側でも参照できる状態です。
それでも、開発ガイドに書いてある内容であるにも関わらず、次のような質問を受けることが少なくありません。
- 「この部品の使い方は？」
- 「この部品のデフォルト設定値は？」
- 「急に動かなくなった」
「質問の前にドキュメントを確認してほしい」という気持ちがある一方で、1つあたり何十～何百ページの資料が複数ある中から、必要箇所をピンポイントで探すのは大変という事情も理解できます。私自身、配属後の研修中は同じように苦労した記憶があります。
つまり問題は、「ドキュメントがない」ではなく、”必要なときに、必要な情報にたどり着きにくい”にあります。
きっかけ：AP基盤ドキュメントをRAGで提供できないか
この課題に対して、AP基盤チーム内で下記の議論を行いました。
- “生成AI”を活用し、質問から関連箇所を検索して提示できれば、問い合わせの往復が減る
- 回答に根拠（引用元資料の章・節）を添えられれば、再現性のあるナレッジ共有になる
- 業務チームの自己解決率が上がれば、AP基盤チームの支援が”説明”から”改善”に寄る
そこで、AP基盤部品のドキュメントをRAGで提供しよう！となったわけです。
本連載は、その取組を進めるうえでの個人的な学習も兼ねて、RAGの理解と実装・運用の勘所を整理していくものです。
本連載で目指すこと
本連載を通じて狙っているのは、次の3点です。
- 社内ドキュメントの”検索体験”を改善するための考え方を整理する
- RAGの設計要素（チャンキング、評価、検索方式など）を分解し、どこで精度が落ちるか / 何を改善すべきかの共通認識を作る
- 最終的に、Amazon Bedrock等を用いた構成で、再利用可能な形の RAGアプリ / RAGエージェント へ展開する
今後のシリーズ
記事は大きく4シリーズを予定しています。加えて、シリーズとは別枠でTips記事も各予定です。
シリーズ1：RAGに関する基本的知識
まずは、RAGの構成要素と設計判断として理解するための土台を作ります。
- RAGとは
- チャンキング（チャンク化）とは
- RAGの評価方法
- ベクトルデータベースについて
- ハイブリッド検索について
- RAGの課題
シリーズ2：Tips（Amazon Knowledge Bases中心を予定）
「公式機能を理解して試す」「構築の手間を減らす」等を主眼に置き、検証記事をまとめる予定です。
- Amazon Knowledge Basesで利用できるチャンク化戦略をすべて試してみる
- Amazon Knowledge Basesのコンソールで簡単にKnowledge Base作成（S3 Vectors）
- MCPサーバー経由でKB呼び出し
※上記は現時点（2026/1/24）での案です。追加検証は随時こちらにも反映していきます。
シリーズ3：RAGアプリケーション構築 + AWSデプロイ
構築対象を明確にし、実用を意識したアプリケーションを組み上げます。
- 構築していく予定のRAGアプリケーションについての説明
- アプリケーション全体アーキテクチャ図についての説明
- RAGアプリ構築（FastAPI編）
- RAGアプリ構築（LibreChat編）
- インフラ構築
シリーズ4：RAGエージェント構築
Strands Agents + Amazon Bedrock AgentCore + Amazon Bedrock Knowledge Basesを利用したRAGエージェント構築を予定しています。
こちらの詳細については現時点でまだ詰め切れていないので、決まり次第更新します。
シリーズ記事とは別に：Tipsも随時まとめます
シリーズは体系立てて理解することを目的としていますが、実際の構築では「細かい詰まりどころ」が出てくると思います。
そのため、シリーズとは別に、RAGやAWS上でRAG環境を構築する際のTips（設定の落とし穴、検証観点、運用メモなど）も随時まとめる予定です。
まとめ
本記事では、AP基盤ドキュメントを扱う中で感じた「必要な情報にたどり着きにくい」という課題を出発点に、RAGを活用して“探すコスト”を下げられないか、という問題意識と、連載として整理していく方針を共有しました。
この連載では、まずシリーズ1でRAGの基本要素（チャンキング、評価、ベクトルDB、検索方式、課題）を分解し、どこが品質を決めるのかを押さえます。その上でシリーズ2〜4で、Amazon Bedrock Knowledge Basesを中心に、検証・構築・デプロイ・エージェント化へと段階的に進めていく予定です。
次回からは、シリーズ1の第1回として、「RAGとは」をテーマに、RAGの定義、なぜ必要か、基本フローを整理していきます。続きもぜひご覧ください。