株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
RAGとは何か｜検索した根拠を使って回答する仕組み
RAG（Retrieval-Augmented Generation：検索拡張生成）は、質問に関連する情報を外部の文書やデータから検索し、その結果をLLMに渡して回答を生成する構成です。例えば「出張精算に必要な書類」を尋ねたとき、対象の社内規程を探し、該当箇所を材料として説明します。モデルの学習済み知識だけに依存する回答に、業務固有の根拠を加える考え方です。すべての生成AIが学習情報しか使えないわけではなく、RAGは外部情報を使う構成の一つです。基本用語はRAGの基礎解説でも確認できます。
Amazon Bedrockの公式説明では、情報を検索する処理と、検索結果から回答を生成する処理が分けて説明されています。検索結果そのものを確認する段階を設けると、必要な資料が見つからなかったのか、資料はあるのに回答で条件を落としたのかを切り分けやすくなります。「生成AIを導入したら正しい回答が出る」と一括りにせず、検索と生成のそれぞれに確認点を置くことが大切です。
RAGとファインチューニングの違い
ファインチューニングは追加の訓練によってモデルの重みを調整する手法です。RAGは回答時に参照情報を渡す構成であり、文書を参照するために必ず生成モデルを再訓練する必要はありません。AWSの比較資料は両者の併用も説明しています。更新される規程の参照と、出力形式や特定タスクへの適応は別の課題として考え、評価結果に応じて選びます。RAGが常に安く即日完成する、ファインチューニングは常に高額で不要、といった判断はできません。
できることと残る限界
社内文書を回答に利用でき、出典を示せば利用者が確認しやすくなります。ただし、古い規程の検索、例外条件の取り落とし、根拠にない補足は残り得ます。出典のリンクがあることと、回答全体が正しいことも別です。例えば交通費の上限額を引用できても、適用日や対象社員が違えば誤案内になります。重要な判断では出典の該当箇所と適用条件まで確認し、根拠が不足する質問には回答を保留して担当者へつなぐ方針を決めます。RAGの価値は、根拠を追える業務の流れと合わせて評価します。
RAGの仕組みと構築手順｜3つのステップ
ステップ1：データを準備し、検索できる形にする
対象業務で参照してよい規程・マニュアル・FAQを選び、文書の管理者、版、適用日、公開範囲を整理します。テキスト抽出後は、見出しや条件のまとまりを保ってチャンクという小さな単位に分割します。画像PDFなら文字認識の誤り、表なら列見出しと数値の対応も確認します。小さく切れば必ずよいわけではなく、条件と結論が離れないことが重要です。データの整理はデータ品質管理の解説も参照してください。
ベクトル検索を使う場合は、文書のチャンクを埋め込みモデルで数値表現へ変換し、検索用のインデックスに登録します。Amazon Bedrockの仕組みの説明は、元文書とチャンクの対応を保持する構成を示しています。ページ番号や文書名を残すことは、回答から根拠へ戻る際にも役立ちます。これは代表的な構成であり、すべてのRAGでベクトルデータベースが必須という意味ではありません。
ステップ2：質問に関連する情報を検索する
意味の近さを使うベクトル検索、用語を探すキーワード検索、その両方を組み合わせるハイブリッド検索を、対象文書と質問で比較します。Difyの公式資料でも、ベクトル・全文・ハイブリッド検索などの選択肢が説明されています。「有給休暇」と「年次休暇」のような表現の違いだけでなく、型番や規程番号のように正確な語が重要な質問も用意します。検索件数を増やせば常に改善するわけではありません。必要に応じて候補を並べ直すリランキングも比較し、無関係な文章が混ざる影響を見ます。詳しくはハイブリッド検索の解説につなげます。
ステップ3：検索結果を渡して回答を生成する
質問と関連箇所をLLMへ渡し、回答、根拠、判断できない点を利用者に示します。文書を全部詰め込むのではなく、必要な条件を残して入力の長さを管理します。Google CloudのRAG参照構成も、データ取込・応答処理・品質評価を分けています。一連の処理をつなぐだけで終わらせず、文書や設定を変更した後にも同じ質問で確認できる形にします。
企業での活用方法｜用途を絞って効果を測る
社内FAQ：適用条件と担当窓口を示す
人事・総務・ITの規程や手順を参照し、従業員の疑問を解く用途です。例えば休暇申請なら、申請先だけでなく雇用区分や適用日によって条件が違うかを確認します。根拠が競合する、個別判断が必要、資料がない場合に担当窓口へ渡す流れも用意します。問い合わせ削減は導入しただけで保証される効果ではありません。再問い合わせや誤案内の修正まで含め、利用者が手続きを進められたかを見ます。
ナレッジマネジメント：過去資料を再利用する
議事録、提案書、報告書を横断して、類似の検討や判断根拠を探す用途です。過去の提案が現在も有効とは限らないため、作成時点、確定事項と案、再利用できる範囲を区別します。顧客情報がある資料を全社員向けの検索対象に混ぜないなど、文書単位の範囲も決めます。検索して内容を理解できることと、別案件へ転用する権利があることは別です。関連する社内ナレッジ検索の設計では、利用場面を具体化できます。
カスタマーサポート：回答案と引き継ぎを設計する
製品マニュアルやFAQから、オペレータが確認する回答案を作る用途があります。顧客へ自動で返す場合は、回答を許可する質問の範囲を定め、契約・返金・障害など個別判断が必要な案件の引き継ぎ条件を決めます。速く返答できても、誤った手順を案内すれば対応のやり直しが増えます。最初の検証では、担当者が回答案を見て修正理由を残すなど、改善材料を集められる運用を検討します。
検索品質と回答品質を分けて評価する
Amazon Bedrockの評価指標は、検索された情報の関連性・網羅性と、回答の正確さ・根拠への忠実さ・引用の精度などを区別しています。根拠に忠実でも元資料が古ければ、現在の業務に正しいとは限りません。私たちは、実際に多い質問に加え、例外条件、曖昧な質問、答えのない質問も確認対象にすることを勧めます。文書数に一律の最低基準を置かず、必要な情報のカバー率と誤回答の影響で対象を広げます。PoCの設計と成功基準も使い、回答時間、修正工数、費用、保留の妥当性を同じ条件で比較して、本番へ進む基準を決めます。
導入と運用の注意点｜更新・権限・費用まで設計する
文書の更新・削除を検索結果に反映する
RAGを入れても、文書の改定が自動的に即時反映されるとは限りません。Amazon Bedrockの同期資料では、追加・変更・削除後の同期と再インデックスが説明されています。利用する方式で反映の契機と所要時間を確認し、旧版の失効、削除、取り込み失敗を担当者が把握できるようにします。規程を更新した日に以前の回答が残らないかも、運用上の確認項目です。
検索してよい範囲を利用者ごとに守る
認証した利用者と所属・権限に基づき、参照できる文書だけが検索と生成へ渡る構成を確認します。画面に出さなくても、権限外の本文をモデルへ渡せば、回答に混ざる可能性を残します。検索のメタデータ絞り込みを認可に使う場合は、利用者が条件を自由に変えられないようにする必要があります。また、Difyのナレッジ設定にあるワークスペースの権限を、そのまま公開アプリの利用者ごとの文書権限と同一視しないようにします。元の文書権限、検索、出典リンク、回答履歴の範囲を合わせて確認します。
参照文書に含まれる指示を、処理の権限や情報送信の許可として扱わないことも重要です。AWSのプロンプトインジェクションの説明は、アプリケーション側にも対策の責任があることを示しています。外部ツールを使う構成では、回答の生成と、メール送信やデータ変更の実行条件を分けます。接続先・利用量・記録の管理はLLMゲートウェイの比較・運用も参考になります。
ツール名や初期費用だけで決めない
Amazon Bedrock Knowledge BasesやDifyのナレッジ機能はRAG構築の選択肢ですが、既存機能で満たせる範囲を個別に確認します。予算はデータ整理、文書取込、検索・生成、評価、権限連携、保守を分けて考えます。文書件数だけの一律価格や、独自開発がほぼ不要という前提では判断できません。AI導入の相談前の準備として、対象業務、使える資料、現在の対応工数、誤回答の影響、運用責任者を整理すると検討を進めやすくなります。
RAGを業務で使う仕組みにするには、データと権限の整理から実装後の改善までつなぐ必要があります。renueのFDEサービスでは、現場の要件整理、設計・実装・運用、KPI設計と成果レビューを支援しています。文書検索を既存業務へ組み込みたい場合や、運用の担当体制まで整えたい場合は、支援範囲をご確認ください。