Retrieval-Augmented Generation（RAG）は，大規模言語モデルに検索機構を接続することにより，外部知識を利用した応答生成を可能にする代表的技術である。しかし，実運用の観点から見ると，RAGは単一の方式ではなく，制約をどのように導入するかによって，その内部構造も利用者にもたらす価値も大きく変化する。本稿は，CDD2の具体的応用例としてRAGを取り上げ，制約をほとんど用いないRAG，一般的な制約付きRAG，そしてCDD2型RAGを比較する。
議論の中心は二つある。第一は，それぞれのRAGがどのようなアーキテクチャを持ち，実装上どこに重心を置くかという点である。第二は，その違いが最終的に利用者にどのような価値の差として現れるかという点である。制約をほとんど使わないRAGは，検索と生成を単純に接続することで高い利便性を実現するが，信頼性や一貫性に弱い。一般的な制約付きRAGは，アクセス制御やガードレールを加えることにより安全性と運用品質を高めるが，なお回答の意味成立条件そのものを扱うわけではない。これに対してCDD2型RAGでは，制約は単なる補助条件ではなく，どの知識を，どの順序で，どの意味で採用するかを決める中核となる。
本稿の主張は，CDD2型RAGにおいて，RAGの中心は単なる \[\text{Query} \rightarrow \text{Retrieval} \rightarrow \text{Generation} \rightarrow \text{Answer}\] という処理連鎖ではなく， \[\text{Query} \rightarrow \text{Constraint Interpretation} \rightarrow \text{Knowledge Selection} \rightarrow \text{Structured Answer}\] という意味選択の過程へと再定義されるという点にある。この再定義によって，RAGは単なる検索補助付き生成系ではなく，制約解釈を伴う知識選択系として理解されるべきであり，利用者には単なる利便性を超えた「説明可能な信頼」を提供しうる。
RAGの基本構造は一般に単純である。利用者の質問が入力され，関連文書が検索され，その検索結果を文脈として大規模言語モデルが回答を生成する。これを最も簡潔に表せば， \[\text{Query} \rightarrow \text{Retrieval} \rightarrow \text{Generation} \rightarrow \text{Answer}\] となる。あるいは，より一般的な情報処理図式として見れば， \[\text{data} \rightarrow \text{processing} \rightarrow \text{result}\] の一例であるとも言える。
しかし，実際のRAGの差異は，この骨格的流れそのものにあるのではない。この流れのどこに，どの深さで，どのような制約を入れるかが本質的な違いを生む。制約をほとんど使わないRAGでは，検索と生成がそのまま中心になる。一般的な制約付きRAGでは，検索と生成の前後にガードやフィルタが加わる。CDD2型RAGでは，制約は周辺的な保護層ではなく，回答の成立条件そのものを決める意味選択条件として働く。したがって，最後のものは単なる安全対策や品質改善ではなく，回答が何に基づいて成立するかという根本を変えている。
本稿は，この三者を比較することにより，CDD2の特徴を具体的に浮かび上がらせることを目的とする。特に，アーキテクチャ的違い，すなわち実装上の違いと，利用者にとっての価値の違いとを対応づけて論じる。
議論を具体化するため，本稿では企業内で用いられるナレッジ検索AIを例に取る。想定するのは，規程類，契約書，社内マニュアル，FAQ，運用メモなどを横断的に検索し，自然言語で回答するAIである。利用者はたとえば次のような質問を行う。
Q: この契約の解約条件は何ですか。
A: 契約書第12条によれば，解約には30日前の書面通知が必要です。
一見すると，これは単純な質問応答に見える。しかし実際には，この短いQ&Aの背後に多くの問題が潜んでいる。たとえば，契約書には改訂版と旧版があるかもしれない。法務部が保持する正式版と，営業部が運用している参考版が矛盾しているかもしれない。ある契約類型では第12条より別紙の例外規定が優先されるかもしれない。また，質問者の所属によって閲覧可能な文書範囲が異なることもある。つまり，利用者が求めているのは単に「それらしい答え」ではなく，「どの知識に基づき，どの優先順位と規則に従ってそう答えたのか」が担保された回答である。
この例は，RAGの比較にきわめて適している。なぜなら，同じ質問に対しても，制約をどこにどう入れるかによって，内部アーキテクチャも最終的な回答の意味も大きく変わるからである。以下では，この企業ナレッジ検索AIの例を通じて，三種類の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日前の場合もあります」といった曖昧な答えを返しうる。ここでは，どちらが正式な根拠かという区別が，アーキテクチャ上ほとんど扱われていない。
利用者の観点から見れば，この方式の価値は主として利便性にある。速く，使いやすく，導入しやすく，とにかく答えが返ってくる。しかしその反面，信頼性，一貫性，説明可能性，組織知の統制という観点では弱い。したがって，利用者にとっては「便利ではあるが，重要業務にそのまま使うには不安が残る」という位置づけになる。
企業利用や組織利用を前提とすると，RAGに何らかの制約を組み込む必要が生じる。ここでいう制約とは，アクセス制御，根拠文書の必須化，新版優先，フィルタ条件，回答フォーマット制約，ガードレールなどである。この場合，アーキテクチャは通常， \[\text{User} \rightarrow \text{Query Filter} \rightarrow \text{Retriever} \rightarrow \text{Document Filter} \rightarrow \text{LLM} \rightarrow \text{Output Validator} \rightarrow \text{Answer}\] のように拡張される。
すなわち，基本RAGの前段・中段・後段に制約層が付加される。前段では，ユーザ権限に応じて検索範囲を制限し，部門別インデックスを切り替え，禁止語や危険質問を判定する。中段では，取得文書の重複除去，新版優先，メタデータにもとづくフィルタリング，信頼文書のみの通過といった処理が行われる。後段では，引用の有無を確認し，禁止出力を除去し，所定のJSONや定型形式に整形する。
企業ナレッジ検索AIの例では，利用者の質問に対して，まずその利用者が法務文書にアクセス可能かどうかが前段でチェックされる。次に検索された候補から旧版を除外し，最新版の契約書だけを残す。さらに回答後には，「契約書第12条」といった根拠が含まれているか，禁止された断定表現がないか，所定の出力形式になっているかが確認される。これにより，「誤って閲覧権限のない文書を参照する」「古い版に基づいて答える」「根拠をまったく示さずに断定する」といったリスクはかなり減少する。
ここで重要なのは，この段階においても中心はなお \[\text{Retrieval} + \text{Generation}\] にあるという点である。制約は処理を制御するルールとして働いているが，それは検索と生成の本体の周囲に置かれた品質保護層である。したがって実装の重心は，フィルタ設計，ガードレール設計，メタデータ管理，ポリシー適用，出力検査といった部分に置かれる。これは企業導入においては非常に現実的であり，実際，権限逸脱の低減，誤引用の抑制，回答形式の安定化，古い文書の混入防止，組織導入の容易化といった大きな効用をもたらす。
利用者にとっても，この方式は単なる利便性に加えて安全性と運用品質を提供する。つまり「便利なAI」から「安全に答えるAI」へと一段進む。しかし，なお限界は残る。なぜなら，ここでの制約はまだ「答えを囲うもの」であって，「答えの意味を作るもの」ではないからである。企業ナレッジ検索AIの例で言えば，正式契約書の第12条では「30日前通知」と規定されている一方，別紙の例外条項では「特定類型については即時解約が可能」とされているかもしれない。また，法務部通達では「原則として契約書本文優先」とある一方，実務マニュアルでは「緊急案件では別紙優先」と書かれているかもしれない。一般的な制約付きRAGは，これらを個別のフィルタや優先ルールで部分的に扱うことはできても，「この質問に対してどの規範が優先されるべきか」「どの例外が適用されるべきか」という意味選択の中心問題を十分には扱えない。
CDD2型RAGにおいて本質的なのは，制約を単なるアクセス制御や出力制御としてではなく，どの知識を，どの順序で，どの意味で採用するかを決める中核として扱う点である。すなわち，制約は検索条件，フィルタ条件，出力条件を超えて，意味選択条件となる。
このとき，アーキテクチャは \[\text{User} \rightarrow \text{Constraint Interpreter} \rightarrow \text{Constraint-aware Retrieval} \rightarrow \text{Evidence Structuring} \rightarrow \text{LLM} \rightarrow \text{Constraint-based Validation} \rightarrow \text{Answer}\] のように変化する。ここで新たに重要となる要素は，Constraint Interpreter，Evidence Structuring，Constraint-based Validation の三つである。
Constraint Interpreter は，質問をそのまま検索語として扱うのではなく，その質問がどの知識領域に属するか，どの規範が優先されるべきか，何を根拠と見なすか，矛盾時にはどの規則で裁定するかを先に決定する。企業ナレッジ検索AIの例で言えば，「この契約の解約条件は何ですか」という問いに対して，まずそれが契約解釈の問いであり，契約書本文，別紙，法務通達，FAQ，運用メモのうちどれを上位根拠とみなすかを決める。たとえば，「正式契約書本文を第一根拠とし，別紙は契約類型が一致する場合のみ優先し，FAQは補足情報にとどめる」といった解釈方針がここで確定される。言い換えれば，この層は質問の意味空間を制約にもとづいて定める。
次に Evidence Structuring は，取得した文書片を単に並べるのではなく，主張，根拠，例外，優先順位，依存関係，矛盾関係として再構造化する。たとえば，契約書本文第12条は「原則30日前通知」という主張，別紙は「特定類型では即時解約可能」という例外，法務通達は「契約書本文優先」という優先規則，FAQは「営業現場でのよくある誤解」を示す補助情報として整理される。この段階で，検索結果は単なる上位\(k\)件の文書断片ではなく，制約にもとづいて秩序づけられた証拠構造へと変換される。
最後に Constraint-based Validation は，単に危険な文でないかを確認するだけではなく，この回答がどの制約に基づいて成立しているか，優先規則に沿っているか，例外条件を落としていないか，知識間の矛盾を未解決のまま隠していないかを検証する。たとえば，最終回答が「原則として解約には30日前の書面通知が必要です。ただし，別紙に定める特定類型では即時解約が可能です」となったとき，その答えが本文優先・例外条件付与という制約に整合しているかが確認される。もし矛盾が解消されない場合には，曖昧さを隠した断定ではなく，「本文と別紙の適用関係の確認が必要です」と明示することが求められる。
この段階に至ると，実装の中心はもはや単なるRAGではない。より正確には，制約解釈器つき知識選択系である。したがって，実装上は少なくとも明示的な制約モデルが必要になる。たとえば，公式文書はFAQより優先され，FAQは社内メモより優先される，新版は旧版より優先される，法務規定は部門ローカル運用より優先される，例外規定には適用条件がある，といった知識上の制約を明示的に持たなければならない。また，単なるベクトル検索だけでは足りず，内部では依存，上位下位，例外，競合，適用条件といった知識関係を扱う必要がある。さらに，回答生成の前処理として，どの根拠を中心に据えるか，どの例外を添えるか，どの矛盾を保留として示すかを決める工程が必要となる。
したがって，実装の重心は「検索の精度改善」から「意味成立条件の管理」へと移る。この移動こそがCDD2型RAGの特徴である。検索精度が重要でなくなるのではない。そうではなく，検索精度に加えて，何を正当な回答と見なすかを制約に基づいて決める層が中心化するのである。企業ナレッジ検索AIの文脈では，これは「契約に関する質問に対して，単に契約らしい断片を探して答える」のではなく，「契約解釈における規範体系に従って知識を選び，回答を組み立てる」ことを意味する。
利用者の観点から見たとき，三者の違いはさらに明確になる。制約をほとんど使わないRAGは，速く，使いやすく，導入しやすく，とにかく答えが返るという点で便利であるが，信頼の根が弱い。一般的な制約付きRAGは，そこに安全性と運用品質を付け加えるため，利用者にはより大きな安心感を与える。しかし，CDD2型RAGが提供する価値は，さらに一段深い。
企業ナレッジ検索AIの例に戻れば，利用者が本当に必要としているのは，「30日前です」とだけ答えるAIではない。正式文書を見ているのか，例外条項を考慮したのか，法務ルールと営業FAQのどちらを優先したのかが分かるAIである。CDD2型RAGでは，利用者は単に「速い」「安全」「それらしい」応答を得るのではない。なぜその答えなのかが分かり，組織ルールや知識の優先順位に沿っており，矛盾や例外を隠さず，重要業務で使いやすく，運用の中で回答品質が安定するという価値を得る。利用者の印象も，「AIが勝手に答えている」から「組織知のルールに従って答えている」へと変わる。ここで生じるのは，単なる利便性や安全性ではなく，説明可能な信頼である。
前節まででは，CDD2型RAGの概念的構造を論じた。本節では議論をさらに具体化するため，企業内ナレッジ検索AIを例として三種類のRAGを比較する。想定する知識源は次のような複数の文書である。
契約書.pdf
社内規程.pdf
FAQ.pdf
運用メモ.pdf
これらは企業知識システムで典型的に見られる情報源であり，それぞれ役割が異なる。契約書は正式な規範文書であり，社内規程は組織ルールを定める。FAQは説明的知識を提供し，運用メモは実務上の補足情報を含む。このような知識集合はしばしば相互に補完し合う一方で，内容が部分的に矛盾することもある。
ここで利用者が次のような質問を行ったとする。
Q: この契約は途中解約できますか。
一見すると単純な質問であるが，実際には複数の知識源が関与する。たとえば契約書には「30日前通知で解約可能」と書かれているかもしれない。一方でFAQには「実務では14日前の場合がある」と記載されている可能性がある。また運用メモには「緊急案件では即時解約が認められる場合がある」と書かれているかもしれない。このような状況では，どの知識を優先するかが回答の意味を決定する。
最も単純なRAGでは，質問はそのまま検索語として処理される。システムは関連文書を検索し，その断片をLLMに渡して回答を生成する。この処理は概念的に
\[User \rightarrow Retrieval \rightarrow LLM \rightarrow Answer\]
と表すことができる。
この場合，検索された文書断片は基本的に同列に扱われる。したがって契約書，FAQ，運用メモなどの情報が混在した状態でLLMに渡される。その結果，回答は次のようになる可能性がある。
契約書では30日前通知による解約が必要です。ただしFAQでは14日前の例があり，運用メモでは緊急案件で即時解約が認められる場合があります。
この回答は情報をまとめているが，どの規則が正式な条件であるのかは明確でない。つまり回答は一見有用であるものの，意味的には曖昧さを残す。
企業導入では，この問題を軽減するために制約を導入することが多い。典型的には
正式文書優先
最新版優先
アクセス権限制御
といったルールである。
この場合，システム構造は
\[User \rightarrow QueryFilter \rightarrow Retrieval \rightarrow DocumentFilter \rightarrow LLM \rightarrow Validator \rightarrow Answer\]
のようになる。
この制約により，たとえば契約書がFAQより優先されるように設定される。すると回答は次のように変化する。
契約書第12条によれば，解約には30日前の書面通知が必要です。
この回答はより明確であり，誤情報も減る。しかしこの方式には限界がある。たとえば利用者が次のように質問した場合である。
Q: 緊急の場合でも30日前ですか。
ここでは契約書と運用メモの関係を解釈する必要がある。しかし一般的な制約付きRAGは主としてフィルタリングを目的として設計されているため，知識間の関係を十分に扱うことが難しい。
CDD2型RAGでは，制約は単なるフィルタではなく，知識選択の中心となる。質問はまず制約解釈器によって分析される。すなわち，この質問が契約解釈に関するものであり，契約書本文を第一根拠とし，例外条件を運用文書から参照する必要があることが判断される。
その結果，検索された文書は次のような構造として整理される。
主張：契約書第12条（30日前通知）
例外：運用メモ（緊急案件）
優先規則：社内規程（契約書優先）
この構造化された証拠にもとづいて回答が生成される。
契約書第12条では解約には30日前の書面通知が必要です。ただし運用メモでは緊急案件において即時解約が認められる場合があります。この例外は通常の契約条件とは別の特別運用として扱われます。
ここで重要なのは，この回答が単に文書を要約したものではなく，制約関係に基づいて知識を整理した結果であるという点である。すなわちCDD2型RAGでは，制約は回答の周辺条件ではなく，回答の成立条件そのものとなる。
以上の例から，三つの方式の違いは明確になる。制約を持たないRAGは便利であるが，回答は曖昧になりやすい。一般的な制約付きRAGは安全性と品質を高めるが，複雑な知識関係を扱うことは難しい。これに対してCDD2型RAGは，制約を知識選択の中心に据えることで，本来であれば解釈が難しい質問にも対応することが可能になる。
この点において，CDD2型RAGは単なる検索拡張生成ではなく，制約解釈にもとづく知識選択システムとして理解することができる。
この比較は，制約の役割が単なる補助条件からアーキテクチャ原理へと変化する過程を示しているとも解釈できる。制約をほとんど用いないRAGでは，アーキテクチャは検索と生成の連鎖によって決まり，制約はほとんど構造に影響しない。一般的な制約付きRAGでは，制約は主としてフィルタやガードレールとして追加され，既存アーキテクチャの周辺で品質を保護する役割を担う。これに対してCDD2型RAGでは，どの知識をどの順序で採用するかという判断そのものが制約によって決定される。
この観点から見ると，システム構造は
\[constraints \rightarrow architecture\]
という関係によって理解することができる。すなわち制約は単に振る舞いを制限する規則ではなく，知識選択と回答生成の構造そのものを形づくる原理となる。この意味でCDD2型RAGは，本稿で提案する Constraint Architecture の具体例として位置づけることができる。
以上の比較を通じて見えてくるのは，RAGにおける制約の位置づけの違いが，そのままアーキテクチャの違いと利用者価値の違いを生むということである。制約をほとんど用いないRAGは，答えを出すことを中心とし，軽量で便利であるが，信頼の基礎は弱い。一般的な制約付きRAGは，答えを安全に出すことを中心とし，ガードレール型の実装を持つが，意味競合や知識優先の深い問題には十分に届かない。これに対してCDD2型RAGは，答えがどのように成立するかを制御することを中心に置き，制約解釈器，知識構造，優先規則を備えることによって，説明可能な信頼を実現する。
したがって，CDD2の応用としてのRAGは，単なる検索補助付き生成系ではなく，制約解釈を伴う知識選択アーキテクチャとして理解されるべきである。そこでは \[\text{Query} \rightarrow \text{Retrieval} \rightarrow \text{Generation} \rightarrow \text{Answer}\] という単純な流れが， \[\text{Query} \rightarrow \text{Constraint Interpretation} \rightarrow \text{Knowledge Selection} \rightarrow \text{Structured Answer}\] という構造へと変換される。この変換こそがCDD2の具体的効用であり，RAGを「便利な応答装置」から「意味統治可能な知識システム」へと押し上げる契機となる。企業ナレッジ検索AIの例で言えば，それは単に解約条件を答えるAIではなく，契約・規程・例外・優先順位の秩序に従って答えるAIへの転換である。