企業がRAGを導入するとき、成果を左右するのはベクトルデータベースの有無だけではありません。検索対象を業務単位で絞り、元文書の閲覧権限を検索時にも継承し、検索品質と回答品質を分けて評価し、更新・監査・不回答を日常運用へ組み込めるかが重要です。本稿では「RAG 導入 企業」がRFP作成、PoC、セキュリティ、費用、受入試験までを一貫して判断できるよう、90日で検証する実務手順を解説します。最初から全社横断を狙わず、権限境界が明確な1業務・1文書群から始めることが中心方針です。
企業のRAG導入で最初に決めるべきこと
RAG（Retrieval-Augmented Generation、検索拡張生成）は、利用者の質問に関係する情報を社内文書などから検索し、その検索結果を根拠として生成AIに回答させる仕組みです。モデルが学習時に持っていなかった社内規程、製品仕様、作業標準、過去の承認済み資料などを参照できるため、社内データの生成AI活用に向いています。
ただし、RAGは文書を登録すれば自動的に正答する箱ではありません。MicrosoftはRAGの課題として、質問の理解、複数ソースへのアクセス、トークン制約、応答時間、セキュリティとガバナンスを挙げています。Google Cloudも、ベースライン評価を作ったうえで、ソースデータ、レイアウト解析、チャンク分割、質問の改善を繰り返す考え方を示しています。つまり企業のRAG構築は、検索・生成・権限・運用を一体で設計する業務改善プロジェクトです。
最初の企画会議では、技術製品より先に次の4点を決めます。
- 誰のどの業務判断を支援するのか
- 正本となる文書群と、その管理責任者は誰か
- 誰がどの文書を閲覧できるのか
- 何ができればPoC成功と判断し、何が起きれば止めるのか
「全社員がすべての社内文書を自然文で検索できるようにする」は、一見わかりやすい目標です。しかし、対象業務、権限境界、正解の定義、更新責任が曖昧なまま範囲だけが広がります。初期PoCでは、例えば「品質部門が承認済みの品質手順書を検索する」のように、利用者、目的、文書群、責任者を一文で説明できる範囲に絞るべきです。ここでの「例えば」は設計粒度の例であり、特定企業の導入実績を示すものではありません。
RAG・ファインチューニング・長文アップロードの違い
企業内の知識を生成AIに使わせる方法はRAGだけではありません。RAG、ファインチューニング、長文コンテキストへの単純アップロードは、解決する問題が異なります。
| 方式 | 主な目的 | 情報更新への対応 | 根拠確認 | 主な設計課題 |
|---|---|---|---|---|
| RAG | 質問ごとに関連文書を検索し、回答の根拠として渡す | 索引更新で反映する設計が可能 | 検索結果と引用元を提示しやすい | 検索品質、権限、チャンク、更新、監査 |
| ファインチューニング | 出力形式、語調、特定タスクの振る舞いを調整する | 知識更新のたびに再調整する用途には注意が必要 | 学習データのどの箇所を根拠にしたか示す用途とは別 | 学習データ品質、評価、モデル運用 |
| 長文アップロード | 限定された文書をその場で読ませて質問する | セッションごとの投入で対応 | 入力文書内で確認できる | 入力上限、毎回の準備、権限、応答時間 |
RAGは、更新される文書群を継続的に検索し、出典とともに回答させたい場合に適しています。ファインチューニングは「社内文書を記憶させる万能策」ではなく、望ましい回答形式やタスク動作を整える用途として切り分けます。少数の固定文書を一時的に扱うだけなら、単純アップロードで十分な場合もあります。
大切なのは、方式名から入らず、業務要件を次の質問へ分解することです。
- 情報はどの頻度で更新されるか
- 回答時に出典を確認する必要があるか
- 文書ごと、利用者ごとのアクセス制御が必要か
- 一度限りの分析か、継続利用する業務システムか
- 答えが見つからないときに「不明」と返す必要があるか
更新性、出典、細かな権限、継続運用が重要ならRAGの検討価値が高まります。一方で、どの方式を採っても誤回答の可能性は残ります。RAGはハルシネーションを「なくす」仕組みではなく、関連する根拠を回答時に与え、評価と監査をしやすくするための構成です。
RAG構築の成否を決める4つの原則
1. 検索対象を「1業務・1文書群」に絞る
文書数を増やせば回答できる範囲は広がりますが、類似文書、旧版、重複、権限差、用語の揺れも増えます。PoCでは「利用頻度がある」「正解を判定できる」「文書責任者がいる」「権限境界が明確」という条件を満たす文書群を優先します。
対象範囲はフォルダ名だけで決めず、文書台帳に落とします。最低限、文書ID、タイトル、版、発効日、失効日、所有部門、機密区分、閲覧グループ、原本URL、更新頻度、索引更新日時を持たせます。この台帳がなければ、回答が古いのか、検索漏れなのか、原文自体が誤っているのかを切り分けられません。
また、PDF、表計算、スキャン画像、スライドは、見た目が同じ「文書」でも解析条件が違います。表のセル関係、見出し階層、ページをまたぐ注記、画像内文字をどう保持するかを確認します。Google Cloudが挙げるlayout parsingとchunkingの改善は、企業文書では特に重要です。
2. 元文書の権限を検索時にも継承する
RAGに取り込んだ時点で、元システムの権限が自動的に守られるとは限りません。索引へアクセス制御情報を持たせ、質問した利用者の確認済みIDに基づいて検索時フィルターを適用し、許可された文書だけを生成モデルへ渡す必要があります。
Microsoft Azure AI Searchは、文書レベルのsecurity trimming、Microsoft Entra IDの権限メタデータ、query-time filter、private endpointなどの設計要素を示しています。Amazon Bedrock Managed Knowledge Baseにもdocument-level permission filteringがありますが、AWSの文書は、ACL対応フィルタはauthorizationそのものではなく、アプリケーション側でエンドユーザーを認証し、検証済みのidentity contextを渡す必要があると明記しています。
したがって、RFPで「文書ACLに対応」と書くだけでは不十分です。次の流れを受入試験で確認します。
- 利用者を企業のID基盤で認証する
- 認証済みIDと所属グループを取得する
- 検索要求に検証済みの権限条件を渡す
- 検索エンジンが文書メタデータで絞り込む
- 許可された検索結果だけを生成モデルへ渡す
- 質問者、検索条件、参照文書、回答を監査可能な形で記録する
特に重要なのは「回答文に機密情報が出なかった」だけで合格にしないことです。禁止文書が検索結果に含まれたが、たまたま最終回答に出なかった可能性があります。検索ログの段階で禁止文書がゼロ件であることを確認します。
3. 検索と回答を分けて評価する
回答が間違っているとき、原因は少なくとも二つあります。正しい根拠を検索できなかった場合と、正しい根拠を取得したのに生成時に誤って解釈した場合です。この二つを分けないと、プロンプトを直すべきか、索引やチャンクを直すべきか判断できません。
Microsoft Azure Architecture Centerは、retrieval評価とend-to-end評価を分離し、groundedness、completeness、utilization、relevancyなどを評価するよう案内しています。また、ハイパーパラメータと評価結果を記録し、複数の質問で集計することも示しています。
企業の評価台帳では、質問ごとに次を記録します。
| 評価層 | 確認すること | 記録例 |
|---|---|---|
| 検索 | 正解文書・正解箇所が候補に入ったか | 期待文書ID、取得文書ID、順位、フィルター条件 |
| 根拠利用 | 回答が取得箇所を適切に使ったか | 使用した引用、未使用の重要箇所 |
| 最終回答 | 質問に正しく、十分に答えたか | 正確性、完全性、関連性、判定理由 |
| 安全性 | 権限外情報や機密情報を含まないか | 利用者役割、禁止文書、漏えい有無 |
| 運用 | 不明時に適切に不回答・案内できたか | 不回答理由、確認先、エスカレーション先 |
同じ質問集で条件を変え、チャンクサイズ、重なり、検索方式、取得件数、ランキング設定などを比較します。OpenAIのVector Store Search APIでは、file attributesによるfilter、query rewrite、ranking options、最大1〜50件の検索結果数を設定できます。設定できるからといって最大件数が常に良いわけではなく、自社の評価セットで品質、遅延、コストを比べて決めます。
4. 更新・監査・不回答を本番運用へ組み込む
本番RAGは、初回の文書投入で完成しません。Microsoftのadvanced RAG解説は、前処理・後処理、チャンク分割、更新戦略、フィードバック、トレースとログを本番システムの要素として挙げています。assessment pipelineで、正しいチャンクが取得されたか、分割が適切かを検証する考え方も示されています。
運用設計では次の問いに回答できる状態を作ります。
- 原本が更新・失効・削除されたら、索引へいつ反映されるか
- 同期に失敗した文書を誰が検知し、再実行するか
- 回答に使った原文の版と索引時刻を追跡できるか
- 利用者からの低評価を、質問集や改善バックログへどう戻すか
- 根拠が不足するとき、推測せずに不回答へ切り替えられるか
- インシデント時にログを保全し、影響範囲を確認できるか
不回答は失敗ではありません。承認済み根拠がない質問にもっともらしい答えを返すより、「参照できる文書からは確認できない」「担当部門へ確認してほしい」と返す方が、企業利用では安全で有用です。受入基準には回答率だけでなく、答えるべきでない質問を正しく拒否できる割合も含めます。
classic RAG・agentic RAG・運用方式の選び方
RAG構築では、検索方式と運用責任を別の軸で判断します。classic RAGとagentic RAGは検索処理の設計、managedとcustomer-managedは基盤運用の分担です。
| 選択肢 | 仕組み・特徴 | 向く要件 | 注意点 |
|---|---|---|---|
| classic RAG | 典型的にはハイブリッド検索とセマンティックランキングで候補を取得 | 単純な質問、応答速度、構成の理解しやすさ、GA要件を重視 | 複数論点を含む質問では質問変換や追加処理が必要になり得る |
| agentic RAG | 複雑な質問をサブクエリへ分解し、並列検索して統合 | 複数資料・複数論点を横断する質問 | 処理経路、遅延、評価、ログの確認範囲が増える |
| managed | コネクター、取り込み、解析、索引などをクラウド機能として利用 | 運用負担を抑え、標準機能を活用したい | 対応コネクター、権限伝播、リージョン、制約を確認する |
| customer-managed | ベクトルストア、取り込み、解析、索引を自社で管理 | 特殊なデータ処理や統制、詳細な調整が必要 | 設計自由度とともに監視、更新、障害対応の責任も増える |
Microsoftは新規実装でagentic retrievalを推奨しつつ、一般提供要件、単純性、速度を重視する場合はclassic RAGを使い分ける説明をしています。したがって「新しい方式だから常に優れている」とは判断せず、質問の複雑さと受入基準から選びます。
運用方式について、Amazon Bedrock Knowledge Basesのmanaged KBは、S3、SharePoint、Confluence、Google Drive、OneDriveなどのコネクター、文書レベル権限フィルタリング、マルチモーダル解析などを提供します。一方、customer-managed KBでは、ベクトルストア、取り込み、解析、索引を自社管理する選択肢があります。OpenAIにはFile Search、Agent／Chat SDKs、Evalsを組み合わせたKnowledge Retrievalの公式blueprintがあります。これらは候補技術を理解するための一次情報であり、製品名だけで自社への適合性や優位性を断定する材料ではありません。
選定時は、検索精度だけでなく次を比較します。
- 既存のID基盤と文書ACLをどこまで継承できるか
- 文書更新、削除、失効をどの時間幅で反映できるか
- タイ語、日本語、英語が混在する質問と文書をどう検索するか
- 検索ログ、生成ログ、引用、モデル・設定の版を追跡できるか
- データ配置、ネットワーク、秘密情報管理の要件を満たすか
- サービス変更時に文書台帳、評価セット、ログを移行できるか
90日PoC計画：RAG導入を段階的に判定する
90日という期間は、市場標準の保証値ではなく、企画、構築、評価、引継ぎを段階化するための計画枠です。対象文書の状態や社内承認に応じて調整してください。重要なのは、各段階の終わりに継続・修正・中止を判定するexit criteriaを置くことです。
0〜15日：業務範囲と評価セットを固定する
最初の15日では、利用部門へのヒアリング、対象業務の定義、文書台帳作成、権限の可視化、質問集の作成を行います。質問集には、よくある質問だけでなく、曖昧質問、複数文書が必要な質問、正解が存在しない質問、権限外文書を誘導する質問、悪意ある指示を含めます。
この段階のexit criteriaは次の通りです。
- 対象業務、利用者、文書群、除外範囲を一文で説明できる
- 正本の所有者と更新責任者が確定している
- 文書ごとの機密区分と閲覧グループが確認できる
- 期待する根拠と回答を持つ評価質問がレビュー済みである
- PoCで扱ってはいけないデータが明文化されている
条件を満たせなければ、構築を急がず範囲を縮小します。正解セットがないままデモの印象で評価すると、本番投入後の品質低下を検知できません。
16〜35日：取り込み・権限・検索の最小構成を作る
文書解析、メタデータ付与、チャンク分割、索引、認証、検索時フィルターを最小構成で実装します。この時点では画面の完成度より、文書から検索までの追跡可能性を優先します。
確認項目は、原本URLからチャンクまでたどれること、版・発効日・所有部門・ACLを保持すること、削除した文書が検索対象から消えること、許可されない利用者の検索結果に禁止文書が現れないことです。
exit criteriaは「認証済みの複数役割で、許可文書は取得でき、禁止文書は検索結果ゼロ」「更新・削除テストの結果が台帳と一致」「取り込み失敗を検知できる」とします。回答生成の見栄えが良くても、権限試験に失敗した場合は次段階へ進みません。
36〜55日：検索品質と回答品質を別々に改善する
評価質問を一括実行し、検索の成否、根拠利用、最終回答を別の列で採点します。正解文書が取得できない質問は、データ欠落、解析、メタデータ、チャンク、質問変換、検索、ランキングのどこに原因があるか分類します。正解文書が取得できているのに回答が悪い質問は、指示、コンテキスト構成、引用、回答形式、不回答条件を見直します。
設定を変えるたびに、設定値、実行日時、データ版、質問セット版、モデル・検索構成、評価結果を記録します。一つの成功例だけで判断せず、複数質問の集計と失敗パターンを確認します。
exit criteriaは、合意した評価指標がPoC開始時の基準を満たし、権限試験を維持し、重大な失敗が再現可能な形で分類されていることです。具体的なしきい値は業務リスクと質問セットに基づき発注企業が決めます。根拠のない共通相場を置かないことが重要です。
56〜75日：業務画面・監査・不回答・フィードバックを組み込む
利用者が出典を開き、原文の版を確認し、回答へ評価を付け、必要なら担当部門へエスカレーションできる画面を整えます。ログには質問者、日時、検索条件、取得文書、回答、引用、設定版を必要範囲で残します。ログ自体に機密情報が含まれる可能性があるため、閲覧権限と保持期間も決めます。
OWASP Top 10 for LLM and GenAIが扱うprompt injection、sensitive information disclosure、data/model poisoning、vector and embedding weaknessesなどを参考に、安全試験を追加します。外部文書や文書内命令を信頼しすぎないこと、検索結果に含まれる不審な指示が上位命令を上書きしないこと、機密情報を誘導する質問に応じないことを確認します。
exit criteriaは、重大な安全試験に合格し、不回答とエスカレーションが機能し、監査担当者が一つの回答を原本まで追跡できることです。
76〜90日：受入試験・運用引継ぎ・本番可否判定
最終段階では、利用部門、文書所有者、情報セキュリティ、IT運用、必要に応じて法務・個人データ担当が受入試験を行います。評価セットだけでなく、更新、削除、権限変更、同期失敗、サービス障害、ログ確認、問い合わせ対応も試します。
本番移行のexit criteriaは、次のように明文化します。
- 対象業務に対する検索・回答評価が合意基準を満たす
- 権限外文書が検索結果と生成コンテキストに含まれない
- 更新、削除、権限変更が合意した運用時間内に反映される
- 不回答、引用、フィードバック、エスカレーションが機能する
- 監視、障害対応、再索引、評価再実行の担当者が決まっている
- 残存リスクと利用上の注意が承認されている
基準未達なら、全社展開へ進まず対象を限定した継続、設計修正、停止のいずれかを選びます。PoCの目的は成功を演出することではなく、本番投資の判断材料を得ることです。
RAG導入費用は「製品価格」ではなく費用台帳で見る
RAG 導入 費用を調べるとき、単一のライセンス価格だけでは総費用を判断できません。データ整備、権限連携、評価、監視、変更管理など、検索・生成以外の作業が品質と安全性を支えます。市場相場として未確認の金額を置かず、自社要件ごとの数量、単価、頻度、責任範囲を費用台帳へ記録します。
| 費用区分 | 台帳に入れる内容 | 数量を決める主な要因 |
|---|---|---|
| discovery／data inventory | 業務整理、文書棚卸し、正本・所有者・機密区分の確認 | 部門数、文書群数、権限の複雑さ |
| connector & ingestion | 接続、抽出、解析、OCR、メタデータ、同期 | ソース数、形式、更新頻度、失敗処理 |
| retrieval／index | 索引、ベクトル化、ハイブリッド検索、ランキング | 文書量、更新量、検索回数、保持方式 |
| model inference | 質問理解、回答生成、必要な前後処理 | 質問数、入力・出力量、処理経路 |
| identity／ACL | 認証、グループ同期、検索時フィルター、権限試験 | ID基盤、役割数、文書ACLの粒度 |
| evaluation set | 質問作成、正解根拠、採点、回帰試験 | 業務数、言語数、リスク分類、改版頻度 |
| monitoring／logging | トレース、監視、アラート、保持、監査 | 利用量、保持期間、調査要件 |
| operation／change management | 文書責任、教育、問い合わせ、改善、再評価 | 利用部門数、変更頻度、支援体制 |
初期費用と月次費用も分けます。初期には棚卸し、設計、接続、評価セット、受入試験が含まれます。月次にはクラウド利用、同期、監視、問い合わせ、文書更新、評価再実行、改善が含まれます。さらに「発注先が含める作業」と「自社が担当する作業」を列で分けると、見積比較で抜け漏れを発見しやすくなります。
ROIの仮定例：一般相場でも成果保証でもない
以下は計算方法を示すための仮定例です。実在企業の実績、市場相場、導入成果の保証ではありません。
- 月間問い合わせ件数：20,000件
- 現状の情報探索時間：1件あたり6分
- RAG利用後の情報探索時間：1件あたり2分
- 対象人件費：450 THB／時
- RAGの回答を業務で採用できる割合：70%
月間時間削減は、次の式です。
20,000件 × (6分 − 2分) ÷ 60分 × 70% = 933.3時間／月
金額換算は、丸め前の値を使うと次の通りです。
20,000 × 4 ÷ 60 × 0.70 × 450 THB = 420,000 THB／月
この420,000 THBは仮定上の削減余地であり、そのまま利益や予算削減になるとは限りません。質問の難易度、採用回答率、確認作業、例外処理、運用費、品質事故リスクを含めて判断します。PoCでは、探索時間を利用ログや作業観察で測り、採用回答率を利用者の判定で記録し、自社の実測値に置き換えます。
ROI台帳には、効率だけでなく品質面も記録します。参照文書の誤り、旧版利用、権限違反、エスカレーション漏れは、時間削減だけでは評価できません。業務によっては「回答を速くする」より「承認済み根拠へたどり着きやすくする」「監査可能にする」ことが主要価値になります。
企業向けRFPチェックリスト
RFPは「RAGチャットボットを構築してください」ではなく、業務要件、データ、権限、評価、運用の受入条件を伝える文書にします。提案各社が同じ前提で回答できれば、価格だけでなく責任範囲と実現方法を比較できます。
業務・スコープ
- 対象利用者、対象業務、意思決定への使い方
- 対象文書、除外文書、正本、所有部門
- 想定質問、複数文書質問、不回答にすべき質問
- 対応言語と、質問言語・文書言語の組み合わせ
- PoC、限定本番、全社展開の境界
データ・検索
- 対応するソース、形式、表、画像、スキャン文書
- 文書ID、版、発効日、失効日、原本URLの保持方法
- チャンク分割とレイアウト解析の方針
- ハイブリッド検索、ランキング、質問変換の選択肢
- 更新、削除、再索引、同期失敗時の処理
- 検索結果と引用元を追跡する方法
ID・権限・ネットワーク
- エンドユーザー認証と企業ID基盤の連携
- 文書ACLとグループ情報の同期
- 検証済みidentity contextを検索へ渡す方法
- 検索時フィルターと生成モデルへ渡す範囲
- private endpointなどネットワーク分離の要件
- 管理者、開発者、監査者の権限分離
評価・安全性
- 検索評価とend-to-end評価を分ける方法
- 正解質問集、期待文書、期待回答の作成支援
- groundedness、completeness、utilization、relevancyの扱い
- prompt injection、機密情報開示、データ汚染、vector／embedding弱点の試験
- 不回答、引用、エスカレーションの受入条件
- 回帰評価の頻度と設定変更時の承認
運用・契約
- 監視、ログ、アラート、保持期間、監査方法
- 障害、誤回答、権限事故の連絡と調査分担
- 文書更新、モデル・検索設定変更、再評価の責任者
- 初期費用、月次費用、従量項目、自社作業の区分
- 終了時のデータ、評価セット、ログ、設定の取り扱い
- 引継ぎ資料、運用手順、教育の成果物
提案回答には、機能の可否だけでなく「どこで認証するか」「どのログで禁止文書が検索されていないと確認するか」「削除が索引へ反映されたとどう証明するか」といった試験方法を記載してもらいます。
受入試験で確認するべき具体項目
RAGのデモでは、よくできた質問を選べば魅力的な回答を見せられます。受入試験では、正常系と失敗系を同じ重みで確認します。
| 試験分類 | 入力・操作 | 合格条件 |
|---|---|---|
| 正常検索 | 正解が1文書にある質問 | 期待文書・箇所が取得され、回答に出典が付く |
| 複数文書 | 複数資料の統合が必要な質問 | 必要な根拠を区別し、矛盾があれば示す |
| 不回答 | 対象文書に答えがない質問 | 推測せず、不明または確認先を案内する |
| 版管理 | 旧版と現行版がある質問 | 現行版を優先し、版・発効日を確認できる |
| 権限 | 同じ質問を異なる利用者役割で実行 | 許可文書のみ取得し、禁止文書は検索結果ゼロ |
| 権限変更 | 利用者のグループを変更 | 合意時間内に検索結果へ反映する |
| 文書削除 | 原本を削除・失効 | 合意時間内に検索対象から除外する |
| 攻撃的入力 | 文書内命令やprompt injectionを含む質問 | 上位指示・権限・機密保護を破らない |
| ログ | 任意の回答を監査 | 質問、検索条件、取得文書、回答、設定版を追跡できる |
| 障害 | 同期・検索・生成の一部を失敗させる | 誤った成功扱いをせず、検知・通知・再処理できる |
評価者が回答文だけを見るのではなく、検索結果、フィルター、参照チャンク、設定版を確認できるようにします。これにより「たまたま正しい」と「再現可能に正しい」を区別できます。
セキュリティ、PDPA、ガバナンスの実務ポイント
企業RAGでは、入力、索引、検索結果、生成コンテキスト、回答、ログの各段階にデータが存在します。どの段階に何が保存され、誰が閲覧でき、どの期間保持され、どこへ送信されるかをデータフロー図で確認します。
NIST AI 600-1は、生成AI向けの部門横断的かつ任意のリスク管理プロファイルです。法的義務そのものとして扱うのではなく、組織がリスクを特定し、管理策を検討するための参照枠として利用できます。OWASPのLLM／GenAI向けTop 10は、prompt injection、機密情報開示、データ・モデル汚染、vectorとembeddingの弱点など、技術試験を整理する参考になります。
タイのPDPAについて、提供された非公式英訳のSection 37は、データ管理者が不正または違法な紛失、アクセス、利用、変更、開示を防ぐ適切なセキュリティ対策を講じ、必要時または技術の変化に応じて見直す趣旨を示しています。ただし参照先は非公式英訳です。本稿は法務助言ではありません。適用範囲、法的根拠、越境移転、委託先管理、通知、保持などは、自社の個人データ担当者と資格を持つ専門家へ確認してください。
RAGのセキュリティレビューでは、少なくとも次を確認します。
- 収集する個人データと業務上の必要性
- 原本、抽出テキスト、embedding、ログ、バックアップの保存場所
- サービス事業者と委託先がデータをどう扱うか
- 管理者権限、開発者権限、利用者権限、監査権限の分離
- 暗号化、秘密情報管理、ネットワーク制御
- 保存期間、削除、訂正、権限変更を索引へ反映する手順
- インシデントの検知、調査、連絡、再発防止
ACLフィルターを入れたから安全、閉域接続だから安全、ログを取ったから監査可能、と単独の機能で結論づけません。認証済みIDから検索フィルターまでの連鎖、ログ閲覧者の権限、原本削除後の派生データまで、端から端まで試験します。
タイ語・日本語を含む多言語RAGの設計
タイで利用する企業RAGでは、質問が日本語、文書がタイ語、製品名や部品番号が英語という組み合わせが起こり得ます。単に画面を翻訳するだけでは、多言語検索の品質は確認できません。
まず、質問言語と文書言語の組み合わせを評価表にします。「日本語質問→日本語文書」「タイ語質問→タイ語文書」だけでなく、「日本語質問→タイ語文書」「タイ語質問→日本語文書」「英数字の型番を含む質問」も分けます。各組み合わせに期待文書と期待回答を用意し、検索と生成を別々に採点します。
タイ語では単語境界、表記揺れ、略語、部署固有語を確認します。日本語では漢字・かな・英字の表記揺れ、全角半角、製品名、社内略称を確認します。専門用語辞書や同義語は、文書所有者の確認を受けて管理し、誰がいつ変更したか記録します。
翻訳を検索前に行うのか、多言語embeddingを使うのか、複数言語で検索するのかは、自社質問セットで比較します。翻訳する場合、固有名詞、数値、単位、否定、版番号が保持されるかを受入試験に含めます。回答の表示言語を質問言語に合わせる場合でも、引用は原文を示し、必要に応じて翻訳と原文を区別できるようにします。
多言語チャットボットの設計論は、関連記事「タイでの多言語AIチャットボット導入ガイド」も参考にしてください。また、PoCのKPIや効果測定を設計する際は「タイ企業のAI導入効果測定ガイド」で、業務成果と品質指標を分ける考え方を確認できます。
社内データの生成AI活用を本番へつなげる運用体制
RAGの所有者をIT部門だけに置くと、文書の正しさや業務上の回答可否を判断できません。一方、利用部門だけでは認証、ログ、障害対応を継続できません。最低限、次の責任を分けます。
| 役割 | 主な責任 |
|---|---|
| 業務オーナー | 対象業務、利用範囲、KPI、受入基準の承認 |
| 文書オーナー | 正本、版、失効、機密区分、用語の管理 |
| データ／検索担当 | 取り込み、解析、索引、検索評価、更新監視 |
| アプリ／ID担当 | 認証、権限連携、画面、エスカレーション |
| AI評価担当 | 質問セット、回答評価、安全試験、回帰試験 |
| セキュリティ／個人データ担当 | リスク、管理策、ログ、インシデント対応の確認 |
| 運用担当 | 監視、問い合わせ、障害、変更、再評価の実行 |
本番後の変更は、モデル変更だけではありません。文書追加、レイアウト変更、コネクター更新、権限体系変更、チャンク設定変更、検索ランキング変更も品質へ影響します。変更前後で同じ評価セットを実行し、検索と回答の差分を確認します。設定と結果を記録することで、改善が別の質問群を悪化させていないか判断できます。
利用者フィードバックも「役に立った／立たなかった」だけにしない方が改善しやすくなります。候補として「必要な文書が見つからない」「引用は正しいが回答が不十分」「旧版を参照」「権限上見えてはいけない」「質問の意図を誤解」「対象外」を用意し、評価質問へ追加する流れを決めます。
よくある失敗と回避策
文書を大量投入してから用途を考える
対象を増やすほど、重複、旧版、権限差、解析失敗が増えます。先に業務質問と正解文書を決め、必要な文書から登録します。全社横断は、限定業務で権限、評価、更新が運用できてから段階的に広げます。
回答の見た目だけでPoCを評価する
流暢な回答は正しさを保証しません。期待文書が検索されたか、引用が回答を支えるか、必要事項を満たすか、禁止情報が混ざらないかを別々に記録します。
ACLフィルターを認証の代わりにする
ACL情報があっても、質問者のIDを検証していなければ正しい条件を適用できません。アプリケーションで認証し、検証済みidentity contextを検索へ渡し、禁止文書が検索結果に入らないことを試験します。
初期費用だけを比較する
取り込み、索引、モデル利用に加え、評価セット、監視、権限同期、文書更新、問い合わせ、変更管理が継続します。初期・月次、自社・発注先、固定・従量を分けた台帳で比較します。
RAGなら誤回答がなくなると期待する
検索漏れ、古い原本、誤った解析、根拠の誤解は起こり得ます。引用、不回答、監査、評価、エスカレーションを含め、誤りを検知して影響を抑える設計にします。
FAQ：RAG 導入 企業が検討時に確認したい質問
RAG 導入 企業はどの業務から始めるべきですか？
利用頻度があり、正解文書を特定でき、文書所有者がいて、権限境界が明確な1業務・1文書群が適しています。最初から全社横断にせず、評価質問を作れる範囲で検索、権限、更新、不回答を検証します。
RAG 構築とファインチューニングはどう使い分けますか？
更新される社内文書を質問ごとに検索し、出典とともに使うならRAGが候補です。出力形式やタスク上の振る舞いを調整するならファインチューニングを検討します。少数文書の一時的な分析なら長文アップロードで足りる場合もあります。複数方式を組み合わせる場合も、各方式が解決する要件を分けて評価します。
RAG 導入 費用はどのように見積もりますか？
discovery／data inventory、connector & ingestion、retrieval／index、model inference、identity／ACL、evaluation set、monitoring／logging、operation／change managementに分けます。数量、単価、頻度、自社と発注先の責任を台帳化し、初期費用と月次費用を分けて比較してください。未確認の市場相場ではなく、自社の文書、利用量、権限、評価要件から積み上げます。
社内データ 生成AI 活用で最も重要なセキュリティ対策は何ですか？
一つの機能だけで安全性は決まりません。エンドユーザー認証、検証済みidentity context、検索時ACLフィルター、生成モデルへ渡す範囲、監査ログ、更新・削除の反映までを連鎖として設計します。権限外文書が最終回答に出ないことだけでなく、検索結果にも含まれないことを試験します。
ドキュメント 検索 生成AIは回答の誤りをなくせますか？
なくせません。RAGでも、正しい文書を取得できない、古い版を使う、取得した根拠を誤解するといった失敗は起こり得ます。検索と回答を分けた評価、出典表示、不回答、監査、回帰試験、担当者へのエスカレーションでリスクを管理します。
classic RAGとagentic RAGはどちらを選ぶべきですか？
単純な質問、速度、構成の理解しやすさ、一般提供要件を重視するならclassic RAGを評価します。複数論点や複数資料を横断する複雑な質問では、サブクエリ分解と並列検索を行うagentic RAGが候補です。名称で決めず、同じ質問セットで検索品質、回答品質、遅延、ログの追跡性を比較します。
タイ語と日本語が混在してもRAGは使えますか？
構成は可能ですが、言語ごとの評価が必要です。質問言語と文書言語の組み合わせを分け、表記揺れ、固有名詞、型番、数値、否定、版番号が保持されるか確認します。翻訳、多言語embedding、複数言語検索の選択は、自社の質問・文書セットで比較してください。
まとめ
企業のRAG導入は、ベクトルデータベースや生成モデルを選ぶだけのプロジェクトではありません。成功条件は、検索対象を業務単位で絞ること、元文書の権限を検索時にも継承すること、検索と回答を分けて評価すること、更新・監査・不回答を運用に組み込むことです。
まず権限境界が明確な1業務・1文書群を選び、正解質問集と文書台帳を作ります。90日PoCでは、取り込み、権限、検索、回答、安全性、更新、監査を段階ごとのexit criteriaで判定します。費用は製品価格だけでなく、データ棚卸し、接続、ACL、評価、監視、運用を台帳化します。そして本番可否は、印象の良いデモではなく、再現可能な受入試験で決めます。
RAGの対象範囲やRFPの作り方がまだ固まっていない段階でも、TOMAS TECHへのお問い合わせからご相談いただけます。タイ拠点を含む文書・権限・多言語要件を整理し、まず検証すべき1業務を切り出すところから一緒に検討できます。
参考情報
- Microsoft, “RAG and Generative AI in Azure AI Search”
https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview
- Microsoft Azure Architecture Center, “Design and Develop a RAG Solution”
- Microsoft, “Build advanced RAG systems”
https://learn.microsoft.com/en-us/azure/developer/ai/advanced-retrieval-augmented-generation
- Amazon Web Services, “Amazon Bedrock Knowledge Bases overview”
https://docs.aws.amazon.com/en_en/bedrock/latest/userguide/knowledge-base.html
- Amazon Web Services, “Document-level access controls”
https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-ds-custom-acl.html
- OpenAI, “Vector Store Search API”
https://developers.openai.com/api/reference/python/resources/vector_stores/methods/search
- OpenAI, “Knowledge Retrieval blueprint”
https://openai.com/solutions/blueprints/knowledge-retrieval/
- Google Cloud, “What is RAG?”
https://cloud.google.com/use-cases/retrieval-augmented-generation
- NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”
- OWASP, “Top 10 for LLM and GenAI”
https://genai.owasp.org/initiatives/top-10-for-llm-and-genai/
- Thailand PDPA, unofficial English translation（Section 37を参照）
https://pdpa.dmh.go.th/news/files/pdpa.pdf
※本稿は技術・運用上の検討材料を提供するもので、法務助言ではありません。法令の適用は、自社の担当者および資格を持つ専門家へご確認ください。
