RAGの書き方を7手順で解説｜サンプルコードと設定例つき入門ガイド

RAG（検索拡張生成）の書き方は、環境構築→データ準備→チャンク分割→ベクトル化→類似度検索→プロンプト拡張→回答生成という7手順に整理できます。まずLangChainなどのライブラリを入れ、社内文書などの知識ベースを分割してEmbeddingでベクトル化し、質問に近い情報を検索してプロンプトに差し込み、LLMに回答させる流れです。この記事はサンプルコードと設定例を添えて、初心者でも最小構成のRAGを自力で動かし、自分のデータへ応用できる状態を目指します。精度チューニングや運用の注意点まで一気通貫で解説します。

RAGの書き方とは？全体像と7手順を先に押さえる

RAGの書き方とは、外部の知識ベースを検索してLLMの回答に反映させる仕組みを、7つの手順として順番に実装することです。最小構成なら、環境構築からデータ準備、分割、ベクトル化、検索、プロンプト拡張、生成までを一本の流れで組み立てられます。

まずは全体像を把握しましょう。RAGはモデルの再学習を行わないため計算コストが抑えられ、比較的簡単に実装・検証できるため最初のステップに向くとされています（ARISE analytics）。次に、7手順を早見表で確認します。

TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・商材・課題に応じてサイトやコンテンツ、検索導線の構造を捉え、ボトルネックを特定して解決策を実行まで伴走する個別設計のコンサルティングを行っています。

この記事で作る最小構成のRAGとは？

この記事で作るのは、用意した文書に基づいて質問へ回答する最小構成のRAGです。追加学習をせずに外部データを参照させるだけで、最新情報や社内固有の内容に沿った回答を得られます。まずはローカルで動く小さな構成から始め、後から本番運用へ拡張する順序が現実的です。RAGの土台を理解すると、生成AIの基礎を業務データへ結び付けやすくなります。

7手順の全体フローはどうなっている？

7手順は「準備」「検索」「生成」の3フェーズに対応します。知識ベースをベクトル化する準備、質問に近い情報を取り出す検索、それを踏まえて答える生成の順で流れます。下の早見表で対応関係を押さえておくと、後の各手順で迷いにくくなります。

手順	作業	フェーズ
手順1	環境構築	準備
手順2	データ準備	準備
手順3	チャンク分割	準備
手順4	ベクトル化と保存	準備
手順5	類似度検索	検索
手順6	プロンプト拡張	生成
手順7	回答生成	生成

必要な前提知識と環境は？

必要なのはPythonの基本操作と、LLMや埋め込みを呼び出すAPIキーです。Python3系とpipが動く環境、そしてOpenAIなどのAPIキーがあれば最小構成のRAGは始められます。無料枠や社内検証用のキーを使い、まずはローカルで小さく動かすと安全です。下のチェックリストで準備状況を確認しましょう。

そもそもRAG（検索拡張生成）とは？仕組みと使う理由

RAGとは、Retrieval-Augmented Generation（検索拡張生成）の略で、検索機能と生成AIを組み合わせた技術です。処理は「知識ベース準備→情報検索→回答生成」の3ステップに分かれます（Qiita）。

なぜ使うのかというと、従来のLLMには弱点があるからです。学習済み情報しか知らず知識更新ができない、ハルシネーションで自信満々に誤答する、情報ソースの透明性がない、という課題をRAGは最新情報の反映と出典の明確化で補います。

TechSuite株式会社の「AI検索パートナーズ」は、生成AIが引用・推薦する仕組みを構造化データや意味的文脈、エンティティ認識の観点から技術的に捉え、LLMO/GEO/AEOを一次情報の設計まで踏み込んで支援しています。

RAGの正式名称と意味は？

RAGはRetrieval-Augmented Generationの略で、日本語では検索拡張生成や取得拡張生成と訳されます。検索で取り出した外部情報を、生成AIの回答に統合する点がRAGの本質です。モデル自体を作り替えず、参照する知識を差し替えるだけで回答内容を更新できる柔軟さが特徴です。

3フェーズで理解する仕組みとは？

RAGの実装はStore・Retrieval・Generationの3フェーズに分解できます。テキストをEmbeddingしてベクトルDBを構築し、質問をベクトル化して上位N件を検索し、抽出情報と質問をLLMに渡して回答を生成します（ARISE analytics）。この3フェーズが、後述する7手順の骨格になります。

図書館の司書のたとえで直感的に理解するには？

RAGは、質問に応じて司書が関連する本を書架から探し、その内容を根拠に答えを組み立てる動きに似ています。丸暗記で答えるのではなく、必要な資料をその都度探して参照するのがRAGの発想です。だからこそ蔵書（知識ベース）の質と、探す精度（検索）が回答の良し悪しを大きく左右します。

使うか迷う場合は、LLMへ知識を与える3つの方法を比較すると判断しやすくなります。プロンプトで情報を与える方式は簡単ですが文字数制限や情報過多で精度が下がり、膨大な社内情報には不向きです。

手法	更新性	コスト	向く場面
プロンプト注入	都度手動	低い	少量の情報
Fine-tuning(LoRA)	再学習が必要	高い(GPU)	口調や形式の固定
RAG	データ差替で即時	中程度	大量の知識参照

Fine-tuningではLoRAがよく使われ、事前学習済モデルの大部分のパラメータを固定して追加学習し計算効率を高めますが、ハイスペックGPUで長時間学習が必要でコストが課題です（ARISE analytics）。更新性とコストの両面で、まずはRAGから試すのが現実的です。

RAGの書き方7手順をサンプルコードで解説

ここからは7手順を、コピーしながらたどれるサンプルコードで解説します。結論として、LangChainのLCEL記法を使えば、検索と生成をパイプで連結して短いコードでRAGを構築できます。

RAGはLangChainを活用して開発されることが多く、モデルの再学習が不要なため検証もしやすい手法です（ARISE analytics）。まずは環境構築から順に進めます。

TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みを「バクヤスAI記事代行」で培っており、その制作エンジンとナレッジを、検索意図や想定質問の分解に沿った知識ベース設計へ転用しています。

手順1と手順2は環境構築とデータ準備をどうする？

まずライブラリを入れ、参照させる文書を読み込みます。pip install langchain langchain-openai langchain-community faiss-cpu でRAGに必要な基本ライブラリを導入できます。APIキーは os.environ[“OPENAI_API_KEY”] のように環境変数へ設定し、コードへ直書きしないのが安全です。データはWebBaseLoaderなどのLoaderでDocumentオブジェクトとして読み込みます。整形段階で余分な記号や重複を除くと後工程の精度が安定します。

手順3と手順4はチャンク分割とベクトル化をどうする？

長い文書はチャンクに分割し、埋め込みモデルでベクトル化してベクトルDBへ保存します。RecursiveCharacterTextSplitter でchunk_size=500・chunk_overlap=50 のように分けると、意味の途切れを抑えつつ検索単位を整えられます。ベクトル化は OpenAIEmbeddings(model=”text-embedding-3-small”) を使い、FAISS.from_documents(docs, embeddings) でセットアップの簡単なベクトルストアを構築できます。日本語重視ならHuggingFaceの日本語対応モデルも選べます。分割の粒度が粗すぎても細かすぎても精度は落ちるため、下表を目安に調整します。

設定	目安	効果
chunk_size	300〜800字	文脈の保持と検索精度の両立
chunk_overlap	10〜20%	境界での情報欠落を防ぐ
埋め込み次元	モデル依存	類似度計算の質を左右

手順5と手順6は検索とプロンプト拡張をどうする？

ベクトルストアをretriever化し、取り出した情報をプロンプトへ差し込みます。vectorstore.as_retriever(search_kwargs={“k”:4}) のように上位4件を取り出し、context としてプロンプトに連結します。PromptTemplateで「参考情報だけを使って回答してください」と指定し、出典明示や簡潔さも指示に含めると回答が安定します。LCELではcontext(retriever)とquestion(RunnablePassthrough())を prompt | model | StrOutputParser() でパイプ連結する書き方が基本です。

手順7は回答生成と動作確認をどうする？

最後にLLMへ渡して回答を生成し、chainを実行して結果を確認します。chain.invoke(“質問文”) を実行し、想定どおり参考情報に基づいた回答が返るかを検証します。StrOutputParser()を繋ぐと出力のAIMessageラップが除かれ、文字列として扱いやすくなります（Zenn）。回答が崩れる場合はプロンプトを微調整し、意図した根拠が引用されているかを都度チェックします。

RAGの精度が上がらない時はどうチューニングする？

精度が上がらない時は、チャンク分割・検索件数k・プロンプトの3点を順に見直すのが基本です。多くのケースは、この3つの調整で回答のブレやハルシネーションが目に見えて減ります。

実際、プロンプトのテンプレートを少し変えるだけで回答が崩れることがあり、冗長化する場合は「回答は簡潔に回答してください」の一文追加で改善したという報告があります（ARISE analytics）。土台のLLMが日本語に十分対応していることも重要です。

TechSuite株式会社の「AI検索パートナーズ」は、自社サイトでAI Share of Voiceが高水準にあり、支援事例でAI Overviewの引用率を改善した実績をもとに、回答に引用されやすい情報設計を検証しながら進めています。

チャンクとk件数はどう見直す？

回答に必要な情報が拾えていないなら、まず分割粒度とk件数を調整します。情報の切り分けは意味の塊で分け、複数の話題をまとめすぎないことが検索ヒット率を高めます（Qiita）。関連情報の取りこぼしが多ければkを増やし、ノイズが多ければkを絞る、という双方向の調整が有効です。

ハルシネーションを減らすには？

誤答を減らす鍵は、参照範囲の限定と出典明示の指示です。参考情報に無い場合は「わかりません」と答えるようプロンプトで明記すると、根拠のない生成を抑えられます。検索でヒットした文と回答の対応が取れているかを確認し、外部知識で穴埋めさせない設計にすると信頼性が上がります。

回答精度や検索ヒット率はどう評価する？

評価は感覚ではなく、質問と正解のセットを用意して指標化します。検索ヒット率と回答の正確性、そして参照元との一致度を分けて測ると改善点が特定しやすくなります。定期的に質問集で回帰テストを行い、データ更新やモデル変更のたびに劣化がないかを確認する運用が望ましいでしょう。

症状	主な原因	調整
情報が拾えない	分割が粗い	chunk縮小・k増加
ノイズ混入	k過多	k削減・再ランク
誤答	指示不足	参照限定を明記
冗長	指示不足	簡潔化を指示

RAGは自作とサービス利用のどちらを選ぶ？

個人検証や自由な設計を求めるなら自作、権限管理やセキュリティを重視するならサービス利用が向きます。判断軸は、社内データの機密度・運用体制・コスト許容度の3つです。

RAG構築に必要な要素はデータソース・ベクトルデータベース・LLMの選定で、社内データ活用には自社開発とサービス活用の両方があります（ChatSense）。導入時は権限管理・検索対象・根拠表示の確認が重要です。RAGを社内活用へ広げるなら、LLMO対策の考え方やAI検索対策の進め方も参考になります。

TechSuite株式会社の「AI検索パートナーズ」では、AI検索経由での受注率が従来のSEO経由の約3倍という成果をふまえ、露出や順位ではなく受注という成果へ直結させる視点で費用対効果を設計しています。

自作とサービス利用の判断軸は？

自作は自由度が高い一方で、開発と運用の工数が継続的にかかります。検証や小規模なら自作、全社利用で権限・監査・可用性が要るならサービス利用が現実的です。まず自作で仕組みを理解し、要件が固まった段階でサービスへ移行する二段構えも有効です。

ノーコードやRAGサービスの選択肢は？

コードを書かずに構築したい場合は、ノーコード系のRAGサービスも選べます。DifyなどのツールはUI上で知識ベースを登録でき、非エンジニアでも社内QAを立ち上げやすい選択肢です。※各ツールの機能や料金は変動するため、導入前に公式情報での確認をおすすめします。

RAGはどんな場面で活用される？

RAGは社内ナレッジの参照が必要な業務で広く活用されます。社内規定やワークフローの質問応答、カスタマーサポート、文書検索・要約などが代表的な用途です（Qiita）。データ品質の管理と段階的な導入、既存検索との併用といったハイブリッド運用が、失敗を避ける定石になります。

比較軸	自作	サービス利用
自由度	高い	制約あり
初期工数	大きい	小さい
権限管理	自前構築	標準搭載が多い
向く規模	検証・小規模	全社利用

よくある質問

RAGの書き方は初心者でも実装できますか？

できます。RAGはモデルの再学習が不要で計算コストも抑えられるため、比較的簡単に実装・検証でき最初のステップに向くとされています。PythonとAPIキーがあれば、7手順に沿って最小構成から始められます。

RAGとファインチューニングはどちらを選ぶべきですか？

知識を頻繁に更新したい場合はRAGが向きます。データを差し替えるだけで反映でき、再学習が不要だからです。口調や出力形式を固定したい場合はFine-tuningが適しますが、GPUと学習時間のコストがかかります。

回答の精度が低いときは何を直せばよいですか？

チャンク分割の粒度、検索件数k、プロンプトの指示を順に見直します。意味の塊で分割し、参照範囲を限定して出典を明示するよう指示すると、取りこぼしや誤答が減ります。日本語対応の強いLLMを使うことも有効です。

ベクトルDBは何を選べばよいですか？

検証段階ではセットアップが簡単なFAISSやChromaが扱いやすい選択肢です。本番でSQLと統合したい場合はpgvectorが候補になります。データ量・運用体制・既存基盤との相性で選ぶとよいでしょう。

まとめ

RAGの書き方は、環境構築・データ準備・チャンク分割・ベクトル化・類似度検索・プロンプト拡張・回答生成の7手順に整理できます。まずは最小構成をローカルで動かし、仕組みを理解してから自分のデータへ差し替えるのが近道です。

精度はチャンク・k件数・プロンプトの調整で安定し、評価は質問集による回帰テストで確認します。機密度や運用体制に応じて、自作かサービス利用かを選びましょう。

社内データ活用や本番運用まで見据えるなら、権限・出典表示・コストの設計が要になります。手順をなぞりながら、自社の用途に合うRAGを育ててください。

参考にした情報源

• RAGとは何か・仕組みとユースケース（Qiita）
• RAGの実装方法と3フェーズ解説（ARISE analytics）
• LCELでRAGを実装する（Zenn）
• RAGの作り方とpgvector活用（Zenn）
• ChatGPTを使ったRAGの構築要素（ChatSense）