RAGを導入する条件・しない条件：品質・維持費・責任を採否ゲートにする

2026年10月23日確認。RAGのPoCへ予算を付けるかを判断するエンジニア・テックリード向けに、品質・維持費・運用責任を分けた判断表を示します。公開一次資料と、Codexが作成・実行した架空入力のローカル検証に基づく設計案です。著者本人の導入実績や、実際の検索・LLMの性能測定を示すものではありません。

結論：回答が良くなるだけでは導入条件を満たさない

RAGを試す条件は「文書を検索できる」だけではありません。次の条件を満たす対象に絞り、まず人が回答を確認する小規模PoCへ進める、という判断を提案します。

• 正本と更新担当が決まり、検索結果を根拠に回答を評価できる。
• 文書を探すだけでなく、複数の根拠をまとめる必要がある。
• 同じ質問集合で、検索だけの場合より役に立つことを確認できる。
• 権限・鮮度・回答を控える動作を評価でき、維持費と運用担当を引き受けられる。

正本がないなら資料整備を先にします。根拠へのリンクで仕事が終わるなら検索を残します。品質改善や費用が未測定なら追加検証です。この判断はPoCの着手条件であり、本番の自動回答を許可する条件ではありません。

前提：検索と生成の失敗を分けて観察する

対象は、文書を参照して回答候補を作る読み取り専用の仕組みです。申請承認やデータ更新などの実行権限は扱いません。

MicrosoftのRAG評価資料は、検索段階と最終回答を分け、根拠との整合性と必要な情報の網羅性も区別しています。本稿でもこの区分を使います。根拠に沿った回答でも、質問への重要な条件が抜ければ業務には使えないためです。

また、RAGの構成説明では、関連文書の取得、入力長、応答時間、アクセス制御などが課題として挙げられています。以下の採否ゲートと優先順位は、これらを踏まえた本稿独自の設計案です。公式の合格基準ではありません。

現状維持・検索・既製品・自作を同じ条件で比べる

選択肢	採用しやすい条件	見送る条件・残る負担
FAQ整備＋手動対応	問いが少なく、正解が決まっている	質問の変化が多い。FAQ更新と対応担当は必要
キーワード／ベクトル検索だけ	根拠を見つければ人が判断できる	複数文書の照合負担が残る。検索評価は必要
既製のナレッジ回答機能	接続先・権限・監査の条件が合う	削除反映、契約、データ利用条件を確認できない
自作RAG	検索・品質ゲート・停止経路を細かく制御したい	索引更新、回帰評価、障害対応の担当を置けない

RAGは検索と生成を組み合わせるパターンであり、ベクトル検索だけを意味しません。検索方式の選定と「生成を足す必要があるか」は別の判断です。既製品でも自作でも、同じ質問と権限条件で比較します。

次のPoCで集める証拠

以下は未実施の評価計画です。質問ごとに、質問ID、正本文書の版、利用者の権限区分、期待する根拠、期待動作、実際の取得結果・回答、人の判定を残します。機微な本文は通常ログへ出さず、必要な場合だけアクセス制限した評価保管先に保存します。

評価する群	検索だけ／RAGで確認すること	判断への使い方
通常の質問	根拠を発見できたか／根拠に沿って必要条件を答えたか	同一質問での有用性の差を測る
正本に答えがない	無関係な根拠を使わないか／回答を控えるか	推測回答を重大失敗として別集計
文書が矛盾する	矛盾を認識できるか／人へ戻すか	正本の責任者へ確認する経路を検証
更新・削除後	新版を参照し、削除済み文書を返さないか	許容反映時間を事前に決めて測る
権限外の質問	権限外の文書が取得結果にも回答にも出ないか	1件でも漏れれば停止・原因調査

通常群の成功率は「成功件数／通常群の全評価件数」とし、回答を控えた件も分母へ残します。例外群は期待した保留・遮断ができた件数を群別に報告します。重大失敗を総合平均に埋め込みません。少数テストで漏れが0件でも、安全性の証明にはなりません。

改善幅と費用上限は比較の前に決めます。同じ質問で探し終えるまでの時間と、人が確認・修正する時間を測り、回答の品質を落とさず確認負担が減ったかを見ます。本稿にはこの実測値がないため、削減率や採算は示しません。

小さな検証：重大失敗と未測定を採用へ流さない

上の評価結果を受け取る判定部分だけを、Python 3.11.8・標準機能のみで検証しました。有料API、検索エンジン、LLMは呼んでいません。入力の真偽値はすべて架空です。

各項目は、正本準備、要約の必要性、安全テスト合格、検索より有用、費用上限内、担当確保を表します。None は未測定です。safety_passed=True は定義したテストに合格したという入力であり、安全性を保証するものではありません。

次を rag_gate.py に保存して python3 rag_gate.py で再現できます。

def decide(e):
    required = {"source_ready", "needs_synthesis", "safety_passed",
                "better_than_search", "cost_within_limit", "owner_assigned"}
    if set(e) != required:
        raise ValueError("evaluation fields do not match")
    if any(v is not None and type(v) is not bool for v in e.values()):
        raise ValueError("use bool or None")
    # 確認済みの停止理由は、別項目の未測定より優先する。
    if e["safety_passed"] is False:
        return "stop"
    if e["source_ready"] is False:
        return "fix_sources"
    if e["needs_synthesis"] is False:
        return "keep_search"
    if any(e[k] is False for k in
           ("cost_within_limit", "owner_assigned")):
        return "hold"
    if any(v is None for v in e.values()):
        return "collect_evidence"
    if e["better_than_search"] is False:
        return "keep_search"
    return "limited_poc"  # 本番承認ではない。

# 架空の評価入力。検索・LLM・権限検査そのものは実行しない。
ready = dict.fromkeys(("source_ready", "needs_synthesis", "safety_passed",
                       "better_than_search", "cost_within_limit",
                       "owner_assigned"), True)
cases = [
    ("ready", {}, "limited_poc"),
    ("leak_and_unknown_cost", {"safety_passed": False,
                               "cost_within_limit": None}, "stop"),
    ("missing_source", {"source_ready": False}, "fix_sources"),
    ("search_is_enough", {"needs_synthesis": False}, "keep_search"),
    ("no_quality_gain", {"better_than_search": False}, "keep_search"),
    ("cost_unknown", {"cost_within_limit": None}, "collect_evidence"),
    ("over_budget", {"cost_within_limit": False}, "hold"),
    ("no_owner", {"owner_assigned": False}, "hold"),
]
for name, changes, expected in cases:
    actual = decide(ready | changes)
    assert actual == expected, (name, actual, expected)
    print(f"{name}: {actual}")
for bad in ({}, ready | {"safety_passed": "false"},
            ready | {"cost_within_limit": 1}):
    try:
        decide(bad)
    except ValueError:
        pass
    else:
        raise AssertionError("invalid evidence accepted")
print("8 decision cases + 3 invalid inputs: PASS")

実行結果は8つの判定ケースと、不正入力3件の拒否がすべてPASSでした。主な結果は次のとおりです。

架空入力	出力	次の動作
全条件がTrue	limited_poc	人が確認する限定PoCへ
安全テスト失敗＋費用未測定	stop	未測定より停止を優先
正本が未整備	fix_sources	資料整備後に再評価
検索で足りる／有用性の差がない	keep_search	生成を追加しない
費用が未測定	collect_evidence	測定して判断を更新
予算超過／担当不在	hold	条件が変わるまで保留

確認したのは判定の分岐と入力検証だけです。検索精度、生成品質、漏えい防止、更新反映、実際の費用は未検証です。欠落項目を自動で合格へ補わず、不正な評価記録は例外で止めます。stop後も文書や索引を消さず、原因の修正と再評価を経て判断記録を作り直します。

維持費と運用責任を残さない

月間維持費の見積りには、モデル利用料だけでなく、索引・保存・更新処理、人の確認、評価データ更新、障害対応を含めます。単価と件数が未確定なら金額は未確定のままにします。遅延と再試行も利用量を増やすので、上限・タイムアウト・検索への切替条件を決めます。

責任は最低限、次のように割り当てる設計です。

• 文書担当：正本、矛盾、更新・削除を管理する。
• 実装・運用担当：索引の版、評価結果、遅延・エラーを監視し、生成を停止できるようにする。
• 業務判断者：許容品質、費用上限、対象範囲と残るリスクを承認する。

権限外の取得、削除済み情報の再出現、回答を控えるべき質問への断定が見つかったら、対象の生成回答を止めて人へ戻す方針です。検索へ切り替える場合も、検索側の権限・鮮度が確認できる場合に限ります。障害が残る検索を代替経路にはしません。

条件付きの推奨と次の確認

正本があり、検索だけでは不足する仕事があり、比較評価・維持費・担当を確認できるなら、読み取り専用・人の確認付きPoCを推奨します。正本不足なら資料整備、検索で足りるなら生成なしを選びます。

次は同一質問集合で検索のみとRAGを比較し、失敗群別の結果、確認時間、更新反映時間、月間費用の根拠を埋めます。改善が確認できても、本番移行には負荷、障害復旧、継続評価の確認が別途必要です。ローカルの判定コードが通ったことだけで、RAG導入を決定しないのがこの設計の境界です。

参考資料

いずれも2026年10月23日に公開本文を確認。製品を用いた実機検証はしていません。

• Microsoft Learn：RAG evaluators — 検索と回答、根拠整合性と網羅性の区分。
• Microsoft Learn：RAG in Azure AI Search — 検索・生成構成と、アクセス制御等の運用上の課題。

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表。AI × Web × 業務自動化の開発・検証に取り組んでいます。
技術選定・品質・運用の判断材料を、検証範囲と制約を示して発信しています。
AI導入や業務自動化の技術選定・設計整理については、対応できる範囲を確認のうえご相談を承ります。