規制業種のための企業RAG設計（実践ガイド）

要約

規制業種の企業のRAGがしばしば失敗するのは、標準的な解説が雑然とした異種混在のデータと、監査でき決定論的な出力という法令対応の要求を織り込んでいないからです。
本番に耐える仕組みには4層の設計が要ります。構造化されたデータの取り込み、再順位づけを伴う混成の検索、方針に基づくLLMの束ね、そして決定論的な実行の層です。
意味だけの検索では足りません。専門の領域では失敗率が20％に達することもあり、キーワードの検索と再順位づけのモデルを組み合わせることは、正確さのために譲れません。
RAGの洞察と、法令に適合した業務の動きの隔たりを埋めるには、Jinba Flowのような決定論的なワークフロー自動化のツールが、業務のルールを効かせ監査可能性を担保するうえで欠かせません。

何週間もかけてRAGの試作を作った。デモでは見事に動く——融資の方針について尋ねれば、正しい書類を引き当て、答えも切れがいい。そしてそれを銀行や保険会社の本番に載せた途端、すべてが崩れます。

書類は文字化けした結果を返す。検索は一貫しない。コンプライアンスがどう判断されたのかを尋ねても、まともな答えがない。ある技術者は企業のRAGについての実際のRedditのスレッドで率直にこう述べました。「これは解説が思わせるよりずっと難しい。企業の書類の例外的な場面は、ノートパソコンを窓から投げたくなるほどだ」

問題はあなたのRAGの実装ではありません。規制業種における企業のRAGが、解説が示すものとは根本的に別の問題だということです。それを分ける点がふたつあります。

異種混在のデータ。あなたの書類はきれいなPDFではありません。基幹の銀行システムの書き出し、OCRの雑音の乗った読み取り済みの法令対応の帳票、表が埋め込まれた方針のPDF、メールのやり取り、そして旧来の報告書です。「たいていの解説は、PDFが完璧である前提に立つ。現実を見よう。企業の書類はまったくの惨状だ」
確率的な出力は、法令対応上の負債。KYC、融資の審査、規制報告では、判断は再現でき、追跡でき、監査できなければなりません。標準的なRAGの仕組みは、方針の強制、確かめられる証拠の連鎖、判断の監査可能性をしばしば欠いており——いずれも規制当局にとって譲れません。

本ガイドは、本番に耐える企業のRAGの設計を4つの層に分けて解きほぐし、エアギャップの環境で何が変わるかを説明し、本番に出す前の備えの確認表をお渡しします。

第1層：データの取り込みと分割——企業のデータの混沌を手なずける

最初の層こそ、多くの企業のRAGの仕組みが静かに死ぬ場所です。もっとも重要なデータ——基幹の銀行システムの書き出し、法令対応の書類、引受の一式——が、きれいであることはめったにありません。

書類の品質を事前に評価する仕組みを作る

何かがベクトルのデータベースに入る前に、品質の採点の仕組みを作ってください。書類ごとに、OCRの雑音の頻度、文字の抽出の完全さ、構造の一貫性を評価します。実務者が勧めるとおりです。「文字の抽出の質、OCRの雑音、書式の一貫性を見る単純な採点の仕組みを作った。点数に応じて、書類を異なる処理の流れへ振り分ける」

品質の低い書類は、黙って取り込まれて下流の検索の質を汚すのではなく、手作業のレビューや専用の処理の流れへ回されるべきです。

構造をふまえた、適応する分割を使う

素朴な固定長の分割は、文の途中で切れたり、概念的に無関係な内容をまとめたりする塊を生みます。企業のRAGの実務者によれば、本番の仕組みには、見出し、段落の切れ目、節の境界といった書類の構造を尊重する分割の戦略が要ります。境界では塊を重ねて、重要な情報が文脈の窓をまたいで割れないようにしてください。

処理の時間は長くなりますが、現場の共通の見方が確かめているとおりです。「すべてを均一な塊に潰そうとするより、結果ははるかに良い」

表の処理のための専用の流れを作る

表を非構造の文章に潰せば、データを意味あるものにしている関係が壊れます。（空白のパターンと格子の構造を見る）経験則に基づく表の検知を作り、単純な表はCSVに変換し、複雑な表については階層の関係をメタデータに残してください。「表のデータをきちんと扱えないなら、企業の価値の大きな塊を取りこぼしている」

領域に固有のメタデータの設計を、まず先に決める

メタデータは後回しにするものではありません。企業のRAGでは、問い合わせは深く文脈に依存します——コンプライアンスの担当者が「バーゼルIIIの自己資本の要件」について尋ねるとき、書類の種類、法域、版で絞り込まれた結果を期待しています。メタデータの設計は、取り込みが始まる前に作ってください。書類の出どころ、版、作成者、日付、書類の種類、そして法令対応の分類や契約の種類といった領域に固有の印を含めます。領域の専門家を巻き込んでください——利用者が実際に必要とする絞り込みを知っているのは彼らです。

第2層：検索と再順位づけ——素朴な意味検索の先へ

意味だけの検索は、認められている以上によく失敗します。金融サービスや法務のような専門の領域では、15〜20％の失敗率が現実的です——きれいな指標が示唆する5％ではありません。略語の曖昧さがこれを深めます。「CAR」のような語は、信用リスクの方針ではひとつの意味を持ち、保険金の書類ではまったく別の意味を持ち得ます。同じ埋め込みの空間で、まったく違う意味なのです。

混成の検索は譲れない

密な検索（ベクトル／意味の検索）と、疎な検索（BM25のキーワードの検索）を組み合わせてください。意味の検索は「うちのトレーディングの部門の流動性リスクの要件は何か」といった概念的な問いを扱えます。キーワードの検索は、特定の方針の番号や規制の参照の符号のような、正確な識別子に欠かせません。企業のRAGでは、どちらか一方では足りません——両方と、その結果をまとめる融合の段階が要ります。

精度のために、交差符号化器で再順位づけする

混成の検索で上位50件の候補の書類を取ったら、それを交差符号化器の再順位づけのモデルに通してください。交差符号化器は、あらかじめ計算した埋め込みを切り離して比べるのではなく、問いと書類の関連度を一緒に評価するため、最終的に渡す文脈の精度が大きく上がります。この段階では、CohereのRerank 3.5が現時点で最高水準の選択肢です。

自分の規模に合わせてベクトルのデータベースを選ぶ

適切な選択は、データの大きさと遅延の要件によります（DataCampの比較が参考になります）。

pgvector：500万ベクトル未満のデータに向く出発点で、すでにPostgreSQLを使っているならとくに。
Qdrant／Weaviate：100万〜1億の範囲のデータに向き、性能の調整の選択肢も多い。
Milvus：分散の設計で、10億ベクトル規模の展開のために作られています。

第3層：柵を備えたLLMの束ね——生成の層での法令対応

検索は正しい書類を持ってきます。しかし規制業種では、LLMがその書類で何をするか——そして次に何が起きるか——が、統制され、説明でき、記録されている必要があります。

束ねの層で方針を効かせる

RAGは情報を浮かび上がらせますが、それを業務のルールに照らして評価はしません。束ねの層がそれをやらねばなりません。たとえば融資の引受の業務なら、取り出した申込者のデータが、特定の信用の点数のしきい値、収入の要件、規制の条件を満たしているかを確かめる必要があります——その判断を、確率的なLLMの出力に委ねてはいけません。ここで方針を軸としたやり方が決定的になり、事実の取得（RAGの仕事）とルールの評価（束ねの層の仕事）が分かれます。

構造化された出力を必須にする

関数の呼び出しや制約つきの復号を使って、LLMに自由な文章ではなく構造化されたJSONを出力させてください。自由な文章の出力は、検証も、振り分けも、監査も困難です。構造化された出力なら、設計に照らして検証でき、下流のシステムへ直接流し込め、実行のあいだで一貫して比べられます。

確かめられる証拠の連鎖を作る

規制当局は「AIがそう言った」を受け入れません。すべての判断は、特定の出どころまで追跡できる必要があります。あなたの仕組みは、どの書類が取り出されたかだけでなく、どの節の、どのページの、どの記述が使われたのかを記録しなければなりません。これは書類の水準の引用を越えます——文や段落の水準での出どころが要ります。

改変できない監査の記録は必須

すべての問い合わせ、検索の出来事、LLMの呼び出し、下流の動きが、（SSOによる）利用者の身元、時刻、入力、出力とともに記録されなければなりません。この記録は改ざんが分かるものである必要があります。それがなければ、監査の要請に応えることも、適合を示すことも、事後に事象を調べることもできません。

第4層：実行の層——RAGの出力から、監査できる業務の動きへ

これが、多くの企業のRAGの記事が扱わない隙間です。RAGの仕組みが構造化され検証された出力を生んだあと、実際に何が起きるのか。

規制のある文脈では、答えが「人が読んで何かをする」であってはいけません。「LLMが何をするか決める」でもいけません。AIによる洞察を、法令に適合した業務の段階へ翻訳する、決定論的で監査できるワークフローの実行の層が要ります。

それがまさに、Jinba Flowがこの設計の中で担う位置です。

Jinba Flowは、規制対象の金融機関のために専用に設計されたワークフローのビルダーです。RAGの検索の出力と業務の動きのあいだに立ち、束ねの層からの構造化データを受け取って、統治され決定論的なワークフローへ流します。この層にとって重要な主な力は次のとおりです。

設計として決定論的：Jinbaのワークフローはおよそ80％がルールベースであり、実行のたびに一貫し監査できる結果を担保します——本番の判断に確率的なばらつきはありません。
チャットからのフロー生成とビジュアルのエディタ：技術のチームが自然な言葉でワークフローの下書きを生成し、目に見えるフローチャートの画面で磨けます。これにより、コンサル主導の案件では通常何か月もかかることが数日に縮まります。
完全な企業向けの統制：改変できない監査の記録、完全な履歴を伴うバージョン管理、SSOとの連携、そして細かいRBAC——法令対応と情報セキュリティが求める統制がすべてそろっています。
柔軟な展開：ワークフローをAPI、バッチ処理、あるいはMCPのサーバーとして公開し、チームやシステムをまたいで再利用できます。

KYCの分析者、コンプライアンスの担当者、融資の処理の担当者といった非技術系の担当者は、対話型のインターフェースと自動生成された入力フォームを備えたJinba Appから、これらのワークフローを安全に実行します。作る環境と動かす環境は意図的に分けられており、利用者がうっかりロジックを変えたり統制を回避したりする危険を減らします。

エアギャップとオンプレミスの環境では何が変わるか

多くの銀行と保険会社は、クラウドのAIのサービスを使えません。データ所在地の方針、主権の規制、セキュリティの要件により、RAGの構成全体を自社の私有の基盤の内側で動かす必要があります。これは、部品の選定のほぼすべての判断を変えます。

すべての層がオンプレミス展開に対応している必要があります。

埋め込みのモデルは自己ホストが必要です（社内のGPUの基盤でHugging Faceのモデルを動かす、あるいは仮想プライベートクラウド内のAWS Bedrockのような私的なクラウドの選択肢を使うなど）。
ベクトルのデータベースはオンプレミスに展開できる必要があります——QdrantとMilvusはどちらも対応し、PostgreSQLの拡張なら既存のクラスタの内側で動きます。
LLMは現地でホストするか、私的なモデルの接続先を通す必要があります——公開のAPIの呼び出しはなしです。
束ねと実行の層は、完全に社内の網の境界の内側で動く必要があります。

Jinba Flowはオンプレミス展開に対応しており、データが社内の網を出ないエアギャップの金融の環境でも使えます。これは、消費者向けのAIの道具立てのほとんどを検討から外す、意味のある設計上の制約であり——Jinbaのような専用に作られたプラットフォームがこの市場に存在する主な理由でもあります。

引き換えになるのは運用の負担です。基盤も、モデルの更新も、規模の判断も自分で持つことになります。部品を選ぶ前に、この現実を前提に設計の計画を立ててください。

企業のRAGの備えの確認表

作り始める前に、この確認表を通してください。印のつかない項目があれば、先へ進む前に手を打ってください——ここでの穴は、本番の事故になりがちです。

［　］データの出どころを洗い出した：関係する構造化・非構造のデータの出どころをすべて目録にしましたか。その書式、更新の頻度、アクセスの統制を把握していますか。
［　］データの品質を評価した：OCRの雑音、そろわない書式、抽出の質の低い書類への対応の計画がありますか。品質の低い入力を振り分ける戦略はありますか。
［　］領域に固有のメタデータの設計を定めた：正確な絞り込みと文脈をふまえた検索に必要なメタデータの項目を、領域の専門家が確認し承認しましたか。
［　］RBACの方針を定めた：利用者の役割とデータへのアクセスの権限が明確に定義され、実装できる状態ですか。使う道具立ては、ワークフローの水準での強制に対応していますか。
［　］監査の記録と法令対応の計画がある：改変できない記録の基盤は整っていますか。自らの用途について、どの規制の要件を満たさねばならないかを理解していますか。
［　］構造化された出力の設計を検証した：LLMが生むJSONの設計を定め、試しましたか。下流のシステムはそれを受け取る準備ができていますか。
［　］経営と利用者の推進役を見つけた：AIの責任者と業務の責任者の後押しを得ましたか。結果を同僚に見せ、社内で導入を後押しする熱心な利用者を見つけましたか。

本番で実際に動く企業のRAGを築く

規制業種のための本番に耐える企業のRAGの仕組みは、見た目のよい画面を備えた検索の仕組みではありません。書類の品質の採点から実行の層の統治まで、すべての部品が決定論、監査可能性、統制のために設計された、層をなす設計です。

4つの層は互いに働きます。きれいで構造化された取り込みが精度の高い混成の検索を支え、それが統治されたLLMの束ねの層を支え、それが決定論的なワークフローの実行を支えます。どの層でも省いたり近道したりすれば、その仕組みはいずれ、規制当局にとって重大なかたちで失敗します。

上の確認表に穴がある段階にいるなら、あるいはどの用途を先に取り組むべきか見極めようとしているなら、Jinbaのチームが、MUFG銀行を含むおよそ70件のエンタープライズの実装に裏づけられた無料のAI戦略アセスメントを提供しています。データの出どころを描き出し、価値の高い自動化の機会を見つけ、実際に本番へ持っていけるロードマップを作るお手伝いをします——ビッグ4のコンサルティングの案件に典型的な6〜12か月ではなく、数週間で。

無料のAI戦略アセスメントを予約する →

よくある質問

企業のRAGは、標準的なRAGの解説とどう違いますか。

企業のRAGが標準的な解説と根本的に違うのは、データの複雑さと法令対応の要件という2点です。企業のデータは、読み取った書類、表、旧来の書式を含めてしばしば雑然とし異種混在ですが、解説はきれいなデータを前提とします。さらに金融のような規制業種では、RAGの出力が決定論的で、監査でき、特定の出どころまで追跡できて、厳格な法令対応の基準を満たす必要があります。標準的なRAGの仕組みは、それを扱うようには作られていません。

企業のRAGで、混成の検索が欠かせないのはなぜですか。

混成の検索が欠かせないのは、意味だけの検索では、企業の領域の正確で多様な問い合わせにしばしば足りないからです。意味の検索は概念的な問いの理解に長けますが、方針の番号や規制の符号のような具体的な識別子では外し得ます。混成の検索は、意味（ベクトル）の検索とBM25のようなキーワード（疎）の検索を組み合わせ、概念の理解と完全一致の語の精度の両方を担保して、検索の正確さを大きく高めます。

RAGの設計における決定論的な実行の層とは何ですか。

決定論的な実行の層とは、RAGの仕組みからの構造化された出力を受け取り、あらかじめ定めたルールに基づく業務を動かす仕組みのことです。その目的は、最終的な業務の動き（融資の承認、取引への印つけなど）が一貫し、繰り返せ、完全に監査できることを担保することです。Jinba Flowのようなツールがその例で、確率的なAIによる洞察と、規制のある環境で求められる譲れないルールに基づく判断とを分けます。

RAGの出力が法令に適合し、監査できることをどう担保できますか。

RAGで適合と監査可能性を担保するには、層をなすやり方が要ります。まず束ねの層が業務の方針を効かせ、すべての情報を正確な出どころに結びつける、確かめられる証拠の連鎖とともに構造化された出力を生む必要があります。次に、すべての問い合わせ、検索、動きが改変できない監査の記録に残る必要があります。最後に、決定論的な実行の層でRAGの洞察を業務の動きへ翻訳し、判断があらかじめ定めたルールに厳密に従うことを保証します。

雑然とした、あるいは品質の低い書類を、企業はRAGでどう扱うべきですか。

企業は、品質の事前の評価から始まる堅牢なデータの取り込みの流れを実装すべきです。この仕組みが、OCRの質や構造の健全さといった観点で書類を採点し、品質の低い書類を手作業のレビューや専用の処理へ振り分けます。素朴な固定長の分割ではなく、見出しや表といった書類の要素を尊重する構造をふまえた分割を使ってください。表のデータについては、構造の関係を抽出しメタデータとして残す専用の流れを作るべきです。

企業のRAGは、エアギャップやオンプレミスの環境でも動きますか。

はい。企業のRAGは完全にオンプレミスで展開できますが、部品の選定に注意が要ります。埋め込みのモデルとLLMから、ベクトルのデータベースと束ねの層まで、構成のすべての部分が自己ホストか私的なクラウドでの展開に対応している必要があります。これにより公開のクラウドのAPIへの依存がなくなり、データが社内の網を出ないことが担保されます。データ所在地とセキュリティの方針により、これは多くの金融機関にとって決定的な要件です。