1. RAGとは: 「調べてから答えるAI」の仕組み
RAG（Retrieval-Augmented Generation／検索拡張生成）は、LLMが回答を生成する前に、関連する文書を検索して読ませる仕組みです。LLM単体は学習時点までの一般知識しか持たず、個々の会社の就業規則や過去の商談メモは知りません。そこで「質問に関係しそうな社内文書を探し、それを参考資料としてLLMに渡してから答えさせる」というのがRAGの基本的な考え方です。人間に例えるなら、「記憶だけで答える」のではなく「資料棚から該当ファイルを引き出して読んでから答える」働き方に近いといえます。
支える3つの基礎技術
- チャンク分割 — 長い文書をそのまま扱うのではなく、数百〜千文字程度の「かたまり（チャンク）」に区切って管理します。どこで区切るかで検索精度が大きく変わるため、後述のとおり実務上の重要な設計ポイントです。
- embedding（埋め込み） — 文章を「意味を表す数値の列（ベクトル）」に変換する技術です。意味が近い文章は近い数値になるため、「有給休暇の申請方法」と「年休の取り方」のように言葉が違っても意味が近い文書を探せるようになります。
- ベクトル検索 — 質問文もembedding化し、あらかじめ数値化しておいた大量のチャンクの中から「意味的に近いもの」を高速に探し出します。キーワード一致ではなく意味の近さで探すのが従来検索との違いです。
流れをまとめると「文書をチャンクに分割→embedding化してデータベースに保存→質問が来たら意味の近いチャンクを検索→見つかったチャンクを添えてLLMに回答させる」となります。仕組み自体はシンプルですが、各段階に設計判断が詰まっています。
2. FDEの現場でどう使うか: 実務の中心は「精度チューニング」
FDE（Forward Deployed Engineer）の典型的な案件のひとつが、顧客の社内文書・ナレッジをLLMに接続するものです。具体的には、社内規程・マニュアル類に答える社内ヘルプデスク、過去の提案書や商談記録を引ける営業支援、技術文書やFAQを参照するカスタマーサポート支援などが挙げられます。国内でも、Sansanが公式テックブログでFDEの業務として「LLM・RAGを含むシステム設計」を挙げており（出典は記事末尾）、RAGはFDEの標準的なスキルになりつつあります。
実務上の重要な点として、RAGを「動かす」だけであれば数日で構築できますが、FDEの業務の大半は「実用に耐える精度に引き上げる」チューニングに費やされます。中心になるのは次の3つです。
①チャンク設計
顧客の文書は、規程集・Excel台帳・議事録・スライドなど形式がばらばらです。「表の途中で切れて意味が壊れる」「見出しと本文が別チャンクに分かれて文脈が消える」といった問題が頻発するため、文書の構造に合わせた分割ルール（見出し単位で切る、表は1チャンクに収める、前後の重なりを持たせる等）を設計し直します。
②検索品質の改善
「経費精算の締め日」を尋ねたのに旅費規程が返ってくる、といった検索ミスへの対処として、ベクトル検索とキーワード検索の併用（ハイブリッド検索）、検索結果を並べ直すリランキング、メタデータ（部署・年度など）での絞り込みといった手法を組み合わせます。
③評価の仕組みづくり
もっとも見落とされがちで、もっとも重要なのが評価です。顧客の実際の質問を集めた評価セット（想定質問と正解のペア）を作り、変更のたびに正答率を測定します。感覚ではなく数字で「先週より良くなった」を示せることが、顧客の信頼とプロジェクトの前進に直結します。この「業務を理解して評価基準に落とす」部分こそ、モデルやツールが進化しても残るFDEの価値です。
3. 今どうやって身につけるか: 公式ドキュメントベースの3ステップ
RAGは商用教材も多い分野ですが、変化が速いため一次情報（公式ドキュメント）を起点にするのが確実です。
Step 1: 公式ドキュメントで仕組みを理解する（目安1〜2週間）
OpenAIとAnthropicの公式ドキュメントには、embeddingsやRAGの考え方を解説したガイドやクックブックが用意されています。まずAPIキーを取得し、公式のサンプルコードを写経して「文章をembedding化して類似度を測る」体験をするところから始めます。英語ですが、この分野の一次情報は英語が基本なので、慣れる意味でも公式に当たる価値があります。
Step 2: OSSフレームワークで最小構成を組む（目安2〜4週間）
LangChainやLlamaIndexといったOSSは、チャンク分割・ベクトルDB接続・検索・生成の定型処理を部品として提供しており、ドキュメントとチュートリアルが充実しています。フレームワークに頼り切るのではなく、「各部品が内部で何をしているか」を確かめながら使うことが重要です。実務では、部品を差し替えたり自作したりする場面が必ず生じます。
Step 3: 自分の文書で作り、評価まで回す（目安1〜2ヶ月）
仕上げは、自分が中身を知っている文書（自社の公開資料、趣味の資料、過去のメモ等）でRAGを組むことです。中身を知っているからこそ「この回答は間違い」と判定でき、評価セットを作ってチャンクサイズや検索方式を変えて精度を比較するという、実務と同じ改善サイクルを体験できます。ここまで取り組めば、ポートフォリオとして選考でも説明できる実績になります。順序立てた計画は未経験からのロードマップも参考にしてください。
なお、RAGとセットで必ず必要になるのがプロンプト設計です。検索したチャンクをどうプロンプトに組み込み、「資料にないことは答えない」ようにどう指示するかについては、プロンプトエンジニアリングはFDEの必須スキルか？で解説しています。
4. FDE Outlook: RAGスキルの現在地と見立て
今見えていること: RAGはFDEの求人・業務内容で名指しされる定番スキルになっています。国内ではSansanが公式テックブログ（2026年1月）で、FDEの仕事を「ビジネス・データ・現場の全てを理解する」役割と位置づけ、LLMやRAGを含むソリューション設計をFDE業務として明示的に紹介しています。FDEになるにはで整理した3スキル（実装力×LLM活用×顧客対話）のうち、「LLM活用」の実績を示す最も具体的な証拠がRAG実装だといえます。
今後の見立て: LLMのコンテキスト長拡大や検索機能の組み込みが進み、基本的なRAGを構築するだけの作業は、今後さらに容易になると考えています。一方で、顧客ごとに異なる文書事情への対応、権限管理を含めた設計、そして業務を理解した評価設計は自動化しにくく、FDEの専門性が発揮される領域として残ると考えられます。「RAGを作れる」ことよりも「RAGを顧客の業務で使える状態に持っていける」ことが重要であり、この違いを意識して学ぶことをおすすめします（断定はできませんが、求人要件の記述もツール名から成果・評価寄りに移る傾向を、当サイトの求人ウォッチで引き続き観測していきます）。