CDD2の具体的応用としてのRAG 制約解釈にもとづく知識選択アーキテクチャの一考察

Abstract

Retrieval-Augmented Generation（RAG）は，大規模言語モデルに検索機構を接続することにより，外部知識を利用した応答生成を可能にする代表的技術である。しかし，実運用の観点から見ると，RAGは単一の方式ではなく，制約をどのように導入するかによって，その内部構造も利用者にもたらす価値も大きく変化する。本稿は，CDD2の具体的応用例としてRAGを取り上げ，制約をほとんど用いないRAG，一般的な制約付きRAG，そしてCDD2型RAGを比較する。

議論の中心は二つある。第一は，それぞれのRAGがどのようなアーキテクチャを持ち，実装上どこに重心を置くかという点である。第二は，その違いが最終的に利用者にどのような価値の差として現れるかという点である。制約をほとんど使わないRAGは，検索と生成を単純に接続することで高い利便性を実現するが，信頼性や一貫性に弱い。一般的な制約付きRAGは，アクセス制御やガードレールを加えることにより安全性と運用品質を高めるが，なお回答の意味成立条件そのものを扱うわけではない。これに対してCDD2型RAGでは，制約は単なる補助条件ではなく，どの知識を，どの順序で，どの意味で採用するかを決める中核となる。

\[\text{Query} \rightarrow \text{Retrieval} \rightarrow \text{Generation} \rightarrow \text{Answer}\] という処理連鎖ではなく， \[\begin{aligned} & \text{Query} \rightarrow \text{Constraint Interpretation} \rightarrow \\ & \text{Knowledge Selection} \rightarrow \text{Structured Answer} \end{aligned}\] という意味選択の過程へと再定義されるという点にある。この再定義によって，RAGは単なる検索補助付き生成系ではなく，制約解釈を伴う知識選択系として理解されるべきであり，利用者には単なる利便性を超えた「説明可能な信頼」を提供しうる。

なお、付録として追加したCognitive RAGは、CDD2ではカバーしない「（状況に応じた）判断を行うための選択肢」を与える。

議論を具体化するため，本稿では企業内で用いられるナレッジ検索AIを例に取る。想定するのは，規程類，契約書，社内マニュアル，FAQ，運用メモなどを横断的に検索し，自然言語で回答するAIである。利用者はたとえば次のような質問を行う。

一見すると，これは単純な質問応答に見える。しかし実際には，この短いQ&Aの背後に多くの問題が潜んでいる。たとえば，契約書には改訂版と旧版があるかもしれない。法務部が保持する正式版と，営業部が運用している参考版が矛盾しているかもしれない。ある契約類型では第12条より別紙の例外規定が優先されるかもしれない。また，質問者の所属によって閲覧可能な文書範囲が異なることもある。つまり，利用者が求めているのは単に「それらしい答え」ではなく，「どの知識に基づき，どの優先順位と規則に従ってそう答えたのか」が担保された回答である。

この例は，RAGの比較にきわめて適している。なぜなら，同じ質問に対しても，制約をどこにどう入れるかによって，内部アーキテクチャも最終的な回答の意味も大きく変わるからである。以下では，この企業ナレッジ検索AIの例を通じて，三種類のRAGを順に検討する。

制約をほとんど使わないRAG

制約をほとんど使わないRAGは，最も素直な構成を持つ。すなわち， \[\text{User} \rightarrow \text{Retriever} \rightarrow \text{LLM} \rightarrow \text{Answer}\] という流れである。実装上は，まずクエリを埋め込み表現へ変換し，ベクトルデータベースから上位\(k\)件の文書片を取得し，その取得結果をLLMに入力し，自然言語としての回答を得るという構成になる。したがって，ここでの主要な関心は，検索精度，埋め込み精度，プロンプトの書き方，そしてLLMの要約能力に向かう。

企業ナレッジ検索AIの例で言えば，利用者が「この契約の解約条件は何ですか」と質問すると，システムは契約書の断片，FAQの断片，場合によっては関連の薄い運用文書まで含めて上位候補として取り出し，それらをまとめてLLMへ渡す。そしてLLMは，その断片群をもとにもっともらしい解答を生成する。ここでは「正式版の契約書を優先するべきである」「FAQは参考情報にすぎない」「同名文書の新版が旧版に優先する」といった規則は，あっても暗黙的な期待にとどまり，構造の中核にはなっていない。

この場合，制約は存在するとしてもほぼ暗黙的である。たとえば「なるべく正確であるべきだ」「可能なら根拠を用いるべきだ」といった期待は存在するが，それが明示的な構成要素として実装に強く組み込まれているわけではない。そのため，この方式の利点は明快である。構成は軽く，立ち上げは速く，PoCを作りやすく，小規模なナレッジ検索であれば実用上十分な場合も多い。

しかし，この単純さはそのまま弱点でもある。検索された文書片は，ほぼそのまま意味資源としてLLMへ渡されるため，無関係文書の混入，権限外文書の混入，旧版と新版の混在，根拠のない生成，さらには矛盾する文書群をそのまま混ぜたもっともらしい回答の生成といった問題が起きやすい。たとえば，正式な契約書の第12条では「30日前通知」と規定している一方，営業向けFAQでは「実務上は14日前で足りる場合がある」と書かれていたとする。制約をほとんど使わないRAGは，この二つを同列の検索結果として取り込み，「通常は14日前ですが，契約によって30日前の場合もあります」といった曖昧な答えを返しうる。ここでは，どちらが正式な根拠かという区別が，アーキテクチャ上ほとんど扱われていない。

利用者の観点から見れば，この方式の価値は主として利便性にある。速く，使いやすく，導入しやすく，とにかく答えが返ってくる。しかしその反面，信頼性，一貫性，説明可能性，組織知の統制という観点では弱い。したがって，利用者にとっては「便利ではあるが，重要業務にそのまま使うには不安が残る」という位置づけになる。

answer(query):
    docs = retrieve(query)
    response = generate_with_llm(query, docs)
    return response

一般的な制約付きRAG

企業利用や組織利用を前提とすると，RAGに何らかの制約を組み込む必要が生じる。ここでいう制約とは，アクセス制御，根拠文書の必須化，新版優先，フィルタ条件，回答フォーマット制約，ガードレールなどである。この場合，アーキテクチャは通常， \[\begin{aligned} & \text{User} \rightarrow \\ & \textbf{Query Filter} \rightarrow \text{Retriever} \rightarrow \\ & \textbf{Document Filter} \rightarrow \text{LLM} \rightarrow \\ & \textbf{Output Validator} \rightarrow \text{Answer} \end{aligned}\] のように拡張される。

すなわち，基本RAGの前段・中段・後段に制約層が付加される。前段では，ユーザ権限に応じて検索範囲を制限し，部門別インデックスを切り替え，禁止語や危険質問を判定する。中段では，取得文書の重複除去，新版優先，メタデータにもとづくフィルタリング，信頼文書のみの通過といった処理が行われる。後段では，引用の有無を確認し，禁止出力を除去し，所定のJSONや定型形式に整形する。

企業ナレッジ検索AIの例では，利用者の質問に対して，まずその利用者が法務文書にアクセス可能かどうかが前段でチェックされる。次に検索された候補から旧版を除外し，最新版の契約書だけを残す。さらに回答後には，「契約書第12条」といった根拠が含まれているか，禁止された断定表現がないか，所定の出力形式になっているかが確認される。これにより，「誤って閲覧権限のない文書を参照する」「古い版に基づいて答える」「根拠をまったく示さずに断定する」といったリスクはかなり減少する。

ここで重要なのは，この段階においても中心はなお \[\text{Retrieval} + \text{Generation}\] にあるという点である。制約は処理を制御するルールとして働いているが，それは検索と生成の本体の周囲に置かれた品質保護層である。したがって実装の重心は，フィルタ設計，ガードレール設計，メタデータ管理，ポリシー適用，出力検査といった部分に置かれる。これは企業導入においては非常に現実的であり，実際，権限逸脱の低減，誤引用の抑制，回答形式の安定化，古い文書の混入防止，組織導入の容易化といった大きな効用をもたらす。

利用者にとっても，この方式は単なる利便性に加えて安全性と運用品質を提供する。つまり「便利なAI」から「安全に答えるAI」へと一段進む。しかし，なお限界は残る。なぜなら，ここでの制約はまだ「答えを囲うもの」であって，「答えの意味を作るもの」ではないからである。企業ナレッジ検索AIの例で言えば，正式契約書の第12条では「30日前通知」と規定されている一方，別紙の例外条項では「特定類型については即時解約が可能」とされているかもしれない。また，法務部通達では「原則として契約書本文優先」とある一方，実務マニュアルでは「緊急案件では別紙優先」と書かれているかもしれない。一般的な制約付きRAGは，これらを個別のフィルタや優先ルールで部分的に扱うことはできても，「この質問に対してどの規範が優先されるべきか」「どの例外が適用されるべきか」という意味選択の中心問題を十分には扱えない。

answer(query, user):
    filtered_query = apply_query_constraints(query, user)
    docs = retrieve(filtered_query)
    docs = filter_documents(docs, user)
    response = generate_with_llm(query, docs)
    response = validate_output(response, docs, user)
    return response

CDD2型RAG

CDD2型RAGにおいて本質的なのは，制約を単なるアクセス制御や出力制御としてではなく，どの知識を，どの順序で，どの意味で採用するかを決める中核として扱う点である。すなわち，制約は検索条件，フィルタ条件，出力条件を超えて，意味選択条件となる。

このとき，アーキテクチャは \[\begin{aligned} & \text{User} \rightarrow \\ & \textbf{Constraint Interpreter} \rightarrow \text{Constraint-aware Retrieval} \rightarrow \\ & \textbf{Evidence Structuring} \rightarrow \text{LLM} \rightarrow \\ & \textbf{Constraint-based Validation} \rightarrow \text{Answer} \end{aligned}\] のように変化する。

Constraint Interpreter は，質問をそのまま検索語として扱うのではなく，その質問がどの知識領域に属するか，どの規範が優先されるべきか，何を根拠と見なすか，矛盾時にはどの規則で裁定するかを先に決定する。企業ナレッジ検索AIの例で言えば，「この契約の解約条件は何ですか」という問いに対して，まずそれが契約解釈の問いであり，契約書本文，別紙，法務通達，FAQ，運用メモのうちどれを上位根拠とみなすかを決める。たとえば，「正式契約書本文を第一根拠とし，別紙は契約類型が一致する場合のみ優先し，FAQは補足情報にとどめる」といった解釈方針がここで確定される。言い換えれば，この層は質問の意味空間を制約にもとづいて定める。

次に Evidence Structuring は，取得した文書片を単に並べるのではなく，主張，根拠，例外，優先順位，依存関係，矛盾関係として再構造化する。たとえば，契約書本文第12条は「原則30日前通知」という主張，別紙は「特定類型では即時解約可能」という例外，法務通達は「契約書本文優先」という優先規則，FAQは「営業現場でのよくある誤解」を示す補助情報として整理される。この段階で，検索結果は単なる上位\(k\)件の文書断片ではなく，制約にもとづいて秩序づけられた証拠構造へと変換される。

最後に Constraint-based Validation は，単に危険な文でないかを確認するだけではなく，この回答がどの制約に基づいて成立しているか，優先規則に沿っているか，例外条件を落としていないか，知識間の矛盾を未解決のまま隠していないかを検証する。たとえば，最終回答が「原則として解約には30日前の書面通知が必要です。ただし，別紙に定める特定類型では即時解約が可能です」となったとき，その答えが本文優先・例外条件付与という制約に整合しているかが確認される。もし矛盾が解消されない場合には，曖昧さを隠した断定ではなく，「本文と別紙の適用関係の確認が必要です」と明示することが求められる。

この段階に至ると，実装の中心はもはや単なるRAGではない。より正確には，制約解釈器つき知識選択系である。したがって，実装上は少なくとも明示的な制約モデルが必要になる。たとえば，公式文書はFAQより優先され，FAQは社内メモより優先される，新版は旧版より優先される，法務規定は部門ローカル運用より優先される，例外規定には適用条件がある，といった知識上の制約を明示的に持たなければならない。また，単なるベクトル検索だけでは足りず，内部では依存，上位下位，例外，競合，適用条件といった知識関係を扱う必要がある。さらに，回答生成の前処理として，どの根拠を中心に据えるか，どの例外を添えるか，どの矛盾を保留として示すかを決める工程が必要となる。

したがって，実装の重心は「検索の精度改善」から「意味成立条件の管理」へと移る。この移動こそがCDD2型RAGの特徴である。検索精度が重要でなくなるのではない。そうではなく，検索精度に加えて，何を正当な回答と見なすかを制約に基づいて決める層が中心化するのである。企業ナレッジ検索AIの文脈では，これは「契約に関する質問に対して，単に契約らしい断片を探して答える」のではなく，「契約解釈における規範体系に従って知識を選び，回答を組み立てる」ことを意味する。

answer(query, user, context):
    constraints = interpret_constraints(query, user, context)
    docs = retrieve_with_constraints(query, constraints)
    evidence = structure_evidence(docs, constraints)
    draft = generate_with_llm(query, evidence)
    answer = validate_by_constraints(draft, evidence, constraints)
    return answer

利用者価値の変化

利用者の観点から見たとき，三者の違いはさらに明確になる。制約をほとんど使わないRAGは，速く，使いやすく，導入しやすく，とにかく答えが返るという点で便利であるが，信頼の根が弱い。一般的な制約付きRAGは，そこに安全性と運用品質を付け加えるため，利用者にはより大きな安心感を与える。しかし，CDD2型RAGが提供する価値は，さらに一段深い。

企業ナレッジ検索AIの例に戻れば，利用者が本当に必要としているのは，「30日前です」とだけ答えるAIではない。正式文書を見ているのか，例外条項を考慮したのか，法務ルールと営業FAQのどちらを優先したのかが分かるAIである。CDD2型RAGでは，利用者は単に「速い」「安全」「それらしい」応答を得るのではない。なぜその答えなのかが分かり，組織ルールや知識の優先順位に沿っており，矛盾や例外を隠さず，重要業務で使いやすく，運用の中で回答品質が安定するという価値を得る。利用者の印象も，「AIが勝手に答えている」から「組織知のルールに従って答えている」へと変わる。ここで生じるのは，単なる利便性や安全性ではなく，説明可能な信頼である。

参考：Cognitive RAG

answer(query, user, context):
    situation = collect_situation(query, user, context)
    constraints = interpret_constraints(query, situation)
    docs = retrieve_with_constraints(
        query,
        constraints,
        sources=["contract.pdf", "policy.pdf", "faq.pdf", "memo.pdf"]
    )
    evidence = structure_evidence(docs, constraints)
    state = reconstruct_state(situation, evidence, constraints)
    affordances = determine_affordances(state, constraints)
    plan = choose_response_or_action(state, affordances, constraints)
    answer = generate_with_llm(query, evidence, plan)
    answer = validate_by_constraints(
        answer,
        evidence,
        affordances,
        constraints
    )
    return answer

例：企業ナレッジ検索AIとしてのRAG

制約をほとんど使わないRAG

一般的な制約付きRAG

CDD2型RAG

利用者価値の変化

参考：Cognitive RAG