はじめに

こんにちは！iOSエンジニアをしている高橋です！

生成AIを開発業務に活用する場面が増えるなかで、AIエージェントに社内情報や既存コードベースをどう参照させるかは重要なテーマになっています。

そこで活用される仕組みの一つが、RAGです。

本記事では、RAGの基本的な仕組みから、AIエージェントと組み合わせた場合の考え方、そしてコードベース理解・コード生成・障害対応・コードレビューといった開発現場での活用例までを解説します。

RAGとは

RAG（Retrieval-Augmented Generation）とは「検索拡張生成」の意で、質問に関連する文書をあらかじめ検索し、その内容を根拠としてLLMに回答させる仕組みです。

簡単に言えば、LLMが回答を生成する前に、関連する資料を取得して参照させるアプローチです。

2023年から2024年にかけて、社内文書やPDFを検索して回答できるRAGシステムが急速に広まりました。

一方で、実運用が進むにつれて、単純なベクトル検索だけでは次のような課題が見えてきました。

質問に対して適切な文書を取得できない
古い文書や権限上参照すべきでない文書を取得してしまう
複数の文書・システムをまたぐ複雑な質問に対応しにくい
検索結果が正しくても、LLMが根拠を誤って解釈することがある

そのため近年は、「RAGを使うか・使わないか」ではなく、より正確に必要な情報を取得し、検証し、回答につなげるための設計が重要になっています。

2026年になり、次世代の代表的なアプローチとして、

Hybrid Retrieval：キーワード検索とベクトル検索を組み合わせる
Reranking：取得候補を再評価し、より関連度の高い文書を上位に並べる
GraphRAG：エンティティや関係性を知識グラフとして扱う
Agentic RAG：AIエージェントが必要に応じて検索を繰り返し、追加調査や検証を行う
Context Engineering：モデルに渡す情報の量・順序・形式を設計する

などが注目されてきました。

RAGが必要な理由

LLMを業務で使う際、よくある課題は次の3つです。

社内情報や独自の専門知識を知らない
学習時点以降の最新情報を反映していない
もっともらしい誤情報を生成することがある（ハルシネーション）

たとえば、社員が「出張精算の上限額は？」とAIに尋ねたとします。LLM単体では、一般的な情報からそれらしい回答を作るかもしれません。しかし実際の上限額は、会社ごとの規程や改定日によって異なります。
RAGであれば、AIはまず最新の経費規程を検索し、該当箇所を参照してから回答できます。これにより、回答の正確性・説明可能性を高められます。

RAGの基本的な流れ

RAGは、概ね次のように動きます。

文書を準備する
マニュアル、FAQ、議事録、規程、製品資料、Webページなどを収集します。
文書を分割する
長い文書を、意味のまとまりごとに小さな単位へ分割します。これを「チャンク」と呼びます。
たとえば、100ページの設計書をそのまま1件のデータとして扱うのではなく、章・節・見出し・段落などの単位で分割します。
コードの場合も、ファイル全体だけでなく、クラス・関数・メソッド・モジュール単位などで扱うことがあります。
検索できる形で保存する
各チャンクに対して、意味を数値で表現した埋め込みベクトルを生成し、ベクトルデータベースなどに保存します。
ベクトル検索を使うことで、質問文と完全に同じ単語が書かれていなくても、意味的に近い文書を見つけやすくなります。
質問に近い文書を検索する
ユーザーの質問もベクトル化し、意味的に近いチャンクを探します。
検索結果をLLMに渡して回答を生成する
「以下の資料だけを根拠に答えてください」といった指示とともに、検索された文書をLLMへ渡します。
このとき、次のようなルールを指示することが重要です。

以下の資料だけを根拠に回答してください。
根拠が見つからない場合は、推測せず「不明」と回答してください。
回答には参照した資料を示してください。

これにより、LLMが根拠のない内容を補完してしまうリスクを下げられます。

AIエージェントとRAGを組み合わせると何が変わるのか

通常のRAGでは、ユーザーの質問に対して関連文書を検索し、その検索結果をもとにLLMが回答を生成します。

質問
  ↓
検索
  ↓
検索結果をもとに回答

一方で、実際の開発業務では「一度の検索だけでは答えられない質問」も多くあります。

決済APIのタイムアウト増加について、
直近の変更・関連する監視項目・過去の類似障害を確認し、
優先度順に調査手順を提案して

この質問に答えるには、ソースコード、直近のPR、監視設定、ダッシュボード、障害報告書、ログ仕様など、複数の情報源を横断する必要があります。
AIエージェントとRAGを組み合わせると、AIは単に検索結果を要約するだけでなく、目的に応じて次のような行動を取れるようになります。

質問を複数の調査項目に分解する
コード、ドキュメント、Issue、PR、監視設定などを検索する
情報が足りなければ、追加の検索クエリを組み立てる
必要に応じてログ検索やメトリクス取得などのツールを呼び出す
取得した情報の矛盾や不足を確認する
根拠とともに、調査結果や次のアクションを提示する

活用例

既存コードベースの理解

新しく参加したメンバーが、次のような質問をします。

ユーザー登録からメール送信までの処理の流れを教えて

この場合、AIは次のような情報を検索します。

ルーティング
コントローラー
ユースケースやサービス
データベースアクセス
ジョブキュー
メール送信処理
関連するテストコード

これらをもとに、処理の流れや主要な責務を説明できます。

GitHubの公式ドキュメントでも、リポジトリの目的・構造・主要コンポーネント・実行方法や、特定のファイル・シンボルの役割を尋ねる用途が例示されています。(docs.github.com）

ただし、コードベース理解では、文書と同じようにコードを単純に分割して検索するだけでは不十分な場合があります。

特に、次のような質問には構造的な情報が必要です。

この関数はどこから呼ばれているか？
この変更の影響範囲はどこか？
このAPIの認可チェックはどこで行われているか？

こうした問いに精度高く答えるには、ベクトル検索だけでなく、ファイルパス、シンボル名、参照関係、呼び出しグラフ、型情報、Git履歴などもあわせて扱うことが重要です。

既存の設計に沿ったコード生成

たとえば、次のような依頼です。

既存の注文APIと同じ構成・例外処理・テスト方針で、
返品APIを追加して

この場合、AIは既存の注文APIに関連する以下の情報を取得します。

エンドポイント定義
コントローラーやユースケースの実装
例外クラス
エラー応答の形式
テストコード
OpenAPI定義
コーディング規約
ログ出力の方針

その情報をもとに、プロジェクトの流儀に近いコードを生成させます。

GitHub Copilotでは、リポジトリ固有の構造、コーディング標準、ビルド・テスト方法などを永続的なコンテキストとして与える仕組みも提供されています。(docs.github.com)

ただし、既存コードを参照して生成されたコードであっても、正しさは保証されません。

認可漏れ、トランザクション境界、例外処理、並行実行、パフォーマンス、セキュリティ要件などは、必ず人間がレビューする必要があります。

バグ調査・障害対応の支援

たとえば、以下のようなケースです。

決済APIでタイムアウトが増えている。
関連する処理、過去の類似障害、確認すべきログ項目を整理して

検索対象には、ソースコードだけでなく、次のような情報も含められます。

障害報告書
運用手順書
監視設定
ログ仕様
ダッシュボードの定義
Issue
過去のPull Request
外部サービスの設定情報

AIエージェントであれば、情報が足りない場合に追加検索を行ったり、許可された範囲でログやメトリクスを取得したりすることもできます。

ただし、RAGやAIエージェントの回答だけで障害原因を断定してはいけません。

特に障害対応では、ログ、メトリクス、トレース、実際の設定値、デプロイ履歴などで必ず検証する運用が必要です。

AIは調査の補助者として有用ですが、事実確認の代わりにはなりません。

コードレビューの補助

RAGに設計原則やチーム規約、類似実装を参照させることで、Pull Requestに対して次のような観点を提示できます。

この変更は認可チェックの既存方針と一致しているか？
類似する実装と比較して、テストが不足していないか？
例外処理やログ出力はチームのルールに沿っているか？

ただし、「AIが問題なしと言った」ことは品質保証にはなりません。最終的な設計判断、セキュリティ判断、マージ判断は人間が担うべきです。

社内SDK・社内APIの利用支援

社内に独自の認証基盤、共通ライブラリ、API、デプロイ手順がある場合、開発者は次のような情報を調べるために時間を使いがちです。

どのSDKを使うべきか
認証はどのように実装するか
必要な環境変数は何か
ローカル開発環境をどう構築するか
どの環境にどうデプロイするか
よくあるエラーをどう解決するか

RAGの検索対象に以下を登録しておけば、AIを社内開発ポータルのように使えます。

API仕様書
SDKのリファレンス
サンプル実装
認証・認可の設計書
デプロイ手順
FAQ
よくある障害と対処法

ただし、社内情報を扱う場合は権限管理が欠かせません。

「検索できる情報」と「そのユーザーに見せてよい情報」は別です。RAGを導入する際は、元システムのアクセス権限を考慮し、検索結果にも適切なアクセス制御を適用する必要があります。

RAGで最も嬉しいこと

プログラミングにおけるRAGの本質的な価値は、コードを書く時間そのものよりも、正しい前提や既存の設計意図を探して理解する時間を減らせることです。

特に既存システムの開発では、実装そのものよりも、次のような作業に時間がかかります。

どのファイルを変更すべきか探す
類似実装を探す
設計意図を確認する
APIやデータベースの仕様を確認する
チームのルールを調べる
過去の障害・議論・判断を探す
変更による影響範囲を確認する

RAGは、この「探索」と「文脈の収集」を支援します。

巨大なリポジトリや大量の文書を毎回LLMにすべて渡すのではなく、質問に関係するコードや文書だけを取り出せるため、AIに与えるコンテキストを絞り込みやすい点も利点です。

GitHub Copilotのセマンティック検索も、正確な名前や検索パターンが分からない場合に、意味に基づいて関連コードを見つける用途として説明されています。(docs.github.com)

トークン量と推論コストを抑えられるのか

適切に設計すれば、RAGはLLMに渡すトークン量と推論コストを抑える手段にもなります。

ただし、RAGの第一目的は「正しい・最新の根拠を与えること」であり、導入すれば必ずトークン数やコストが下がるわけではありません。

長大なマニュアルや社内文書を、そのまますべてプロンプトに入れると、その全量が入力トークンになります。

RAGでは、文書をあらかじめ分割し、質問に関連する数個のチャンクだけをLLMに渡します。

たとえば、数百ページの資料のなかから、必要な数段落だけを参照させることが可能です。

これにより、LLMに焦点を絞ったコンテキストを渡しやすくなります。

MicrosoftのRAG解説でも、関連するチャンクのみを返す設計は、モデルに焦点を絞った文脈を渡し、トークン使用量を減らす方法として説明されています。（learn.microsoft.com）。

一方で、RAGには次のようなコストや運用負荷もあります。

文書の収集・整形
チャンク分割
埋め込みベクトルの生成
インデックスの更新
検索処理
再ランキング
検索精度や回答精度の評価
アクセス権限の管理

そのため、単純に入力トークン数だけを見るのではなく、回答精度、応答速度、検索コスト、文書更新頻度、運用負荷を含めて設計することが重要です。

RAGはハルシネーションを完全になくすのか

結論から言えば、RAGを導入してもハルシネーションが完全になくなるわけではありません。

たとえば、次のような問題は残ります。

検索結果そのものが誤っている
必要な情報を検索で取りこぼす
古い文書を参照してしまう
LLMが根拠を誤って解釈する
根拠にない内容をもっともらしく補完する
引用元は正しくても、回答内容を十分に裏付けていない

そのため、RAGを導入する際は次のような対策が重要です。

回答とともに参照元を表示する
参照元が実際に回答内容を裏付けているか確認する
根拠にない内容を回答しないようプロンプトで制約する
十分な根拠がない場合は「不明」と回答させる
文書の更新日や有効期限を管理する
検索精度と回答精度を分けて評価する
高リスクな回答には人による確認を組み込む
文書の権限管理と監査ログを整備する

RAGは「AIを必ず正しくする技術」ではありません。

AIが回答するための根拠を与え、その根拠を人間が確認できるようにする仕組みです。

まとめ

RAGは、LLMに外部の知識を検索・参照させることで、より実務的で信頼性の高い回答を実現する仕組みです。

特に、頻繁に更新される情報や、組織・業界に固有の情報を扱う場面で大きな価値を発揮します。開発現場では、コードベースの理解、既存設計に沿った実装、障害調査、コードレビュー、社内SDKやAPIの利用支援などに活用できます。

また、AIエージェントと組み合わせることで、RAGは単に「資料を検索して答える」ための仕組みではなくなります。AIが質問を分解し、必要な情報を追加で調べ、複数の情報源を横断し、根拠を整理して次のアクションを提案するための知識基盤になります。

ただし、成功の鍵はLLMの性能だけではありません。正しい文書を整備し、更新日・権限・信頼性を管理し、適切に検索し、根拠を確認できる運用を作ることが重要です。

RAGは単なるAI機能ではなく、組織の知識を「探せる・使える・説明できる」形に変えるための基盤といえるでしょう。

関連記事