RAGにリアルタイムの在庫・売上・価格を任せない設計｜DB・API直接照会との使い分け

「RAGを入れれば、社内の在庫・売上・価格にも答えられるのではないか」と考える場面は多いでしょう。結論からいうと、規程や商品説明のように“文書を探して説明する”仕事はRAG、現在在庫・確定価格・残高・厳密な集計値のように“いまの状態を確定する”仕事は、その項目の正として定め、鮮度・整合性要件を満たすDBまたは業務APIとして分けて設計することをMojiでは提案します。

これは「RAGは古いから使えない」という意味ではありません。RAGの原論文は、事前学習済みの生成モデルと、検索でアクセスする非パラメトリックな外部メモリを組み合わせる枠組みを示しています。更新される知識を参照しながら説明する設計に使える一方、同論文は在庫・価格の確定値やトランザクション基盤との代替関係を評価したものではありません。RAG原論文

そのため本記事では、在庫・価格・残高・売上などの確定値について、RAGの検索結果を唯一の正とせず、業務上の正として定義された読み取り経路で取得する構成をMojiによる実務上の提案として扱います。DBやAPIも、それだけで常に最新値・唯一の正を返すわけではありません。同期遅延、レプリカ、キャッシュ、権限、集計時点、複数システム間の差異を含め、要件に合う経路を決める必要があります。

この記事で示す判定表、停止基準、設計テンプレートは、特記のない限りMojiによる実務上の提案です。最終的な選択は、利用するモデル、入力データの品質、評価指標、許容できる誤差、業務上の影響によって変わります。

先に結論：RAGは「説明の根拠」、DB・APIは「確定値の取得」に分ける

この分離は、「RAGかAPIか」の二者択一ではありません。多くの業務では、RAGでルールや理由を説明し、APIで現在値を取得し、DBまたは計算処理で合計・判定を確定する併用構成になります。

更新済みRAGでも確認したい、確定値に関する失敗仮説

インデックスを頻繁に更新していることは、鮮度を高める施策の一つです。しかし、それだけで業務上の確定値の要件を満たすかは分かりません。実装前には、次の項目を自社のデータ、同期方式、検索設定、回答画面で検証する失敗仮説として扱います。

1. 取得時点のずれ：文書の作成、同期、索引化、検索、回答表示の時点を記録します。在庫が変わる業務では、検索時点と画面表示時点の差が許容範囲内かを確認します。
2. 検索候補の不足・競合：正しい改定版が候補に入るか、旧版と新版が混在したときに新しい版を選べるか、商品・拠点・通貨などの条件が異なる文書を除外できるかをテストします。
3. 構造と条件の欠落：表の列、注記、適用日、例外条件が分割・抽出後にも必要な関係を保っているかを確認します。検索できた文章断片だけで数値の意味を確定できないケースがないかを見ます。
4. 生成時の変換：LLMは取得文をそのまま返すとは限らず、要約や文章化を行います。NISTは、もっともらしく誤った内容を生成するconfabulationを生成AIのリスクとして整理しています。NIST AI 600-1
5. 集計・演算の条件不足：「今月の売上」であれば、対象期間、タイムゾーン、取消・返品、税、通貨換算、未確定注文を含めるかによって値が変わり得ます。必要な条件が固定されずに複数断片の数値をLLMへ統合させる構成では、条件の取り違えを検出できるかを評価します。

RAGの品質を最終回答だけで判定すると、検索が不足したのか、取得した根拠を回答で使えなかったのかを分けにくくなります。RAGCheckerは、検索モジュールと生成モジュールの双方を対象にした細粒度の診断評価枠組みを提案しています。RAGChecker原論文

したがって、「インデックスを毎分更新しているから在庫照会に使える」とは一律に結論づけません。要求される鮮度、許容誤差、欠品・誤請求時の影響、取得失敗時の扱いをデータ項目ごとに決め、実測で確認してから方式を選びます。

方式を選ぶ4つの判断基準

Mojiでは、データ項目ごとに次の4軸を記入してから実装方式を決めることを提案します。

表は一般的な設計上の目安です。たとえば「在庫数を問い合わせへ案内するだけ」で、最終注文時に必ずカート・在庫APIで再確認するなら、チャット回答へ概算の在庫状態を出す設計が許容される場合もあります。反対に、社内向けでも発注判断へ直結するなら、正として定めたDB・APIの値と取得時刻を表示する方が適切です。

データ種別ごとの使い分け

1. 規程・FAQ・商品説明：RAGを主にする

対象は、返品規程、商品の仕様、障害対応手順、営業ルール、マニュアルなどです。回答には、文書名、改定日、参照箇所へのリンクを添えます。RAGは「答えを知っている仕組み」ではなく、根拠文書を探し、説明し、利用者を原文へ戻す仕組みとして設計してください。RAGの基本構造と導入・評価の全体像は、RAG（検索拡張生成）の解説で確認できます。

2. 現在値：業務APIまたはDBを主にする

対象は、在庫、注文状態、現在価格、ポイント残高、利用枠、配送状況です。ツールの返却値には最低限、value、unit、asOf（取得時刻）、source、scope（拠点・通貨・チャネルなどの条件）を含めます。LLMには、値を再計算・補完するのではなく、検証済みの値を自然言語で説明する役割を担わせます。

業務システムがAPIを提供していない場合でも、LLMへ任意SQLを生成・実行させる前に、読み取り専用のクエリAPIまたは許可済みクエリを用意する構成を検討します。APIとAIエージェントの接続方式の位置づけは、API・MCP・A2Aの違いも参照してください。

3. 合計・比較・閾値判定：DB集計または決定的な計算を主にする

対象は、「今日の店舗別売上合計」「安全在庫を下回るSKU」「値引き後の税込み請求額」「重複を除いた顧客数」です。条件を固定できる計算は、SQL、分析基盤、ルールエンジン、アプリケーションコードなどの決定的な処理で実行します。

PostgreSQLを例にすると、トランザクション分離レベルは、並行処理中にトランザクションが参照できるデータを規定します。現行ドキュメントでは、READ COMMITTEDにおいて各文は、その文が開始する前にコミットされた行を参照すると説明されています。この挙動を他のDBへ一般化することはできませんが、集計値を扱う際には、データ時点と一貫性の要件を対象DB・分析基盤ごとに確認します。PostgreSQL: SET TRANSACTION

LLMは、期間や対象拠点などの不足条件を質問したり、確定した集計結果を読みやすく解説したりする役に置けます。ただし、合計値そのものの正しさをLLMの文章だけで判定しないようにします。

4. 更新・意思決定：LLMの回答と実行を分離する

対象は、値引き確定、発注、返金、在庫引当、顧客への送信、権限変更です。LLMには「何を行うべきか」の候補作成までを任せ、最終実行は業務ルール、認可、承認、冪等性、監査ログを持つAPI側で処理します。OWASPのLLM06:2025は、利用者の認可文脈に沿った最小権限、影響の大きい操作への人の承認、下流システムでの認可の実施を対策として挙げています。OWASP LLM06:2025 Excessive Agency

実行権限・承認・停止・監査の具体的な設計は、AIエージェントのガードレール設計もあわせて確認してください。

推奨構成：RAG＋API＋決定的な計算を直列にする

在庫や価格を含む社内AIでは、次のように役割を直列化すると、どの値を誰が保証するかを分けやすくなります。

1. 質問解析：LLMが「規程の説明」「現在値の取得」「集計」「更新依頼」のどれかを分類する。
2. 条件確認：商品ID、拠点、通貨、対象期間、ユーザー権限など、確定に必要な入力が不足していれば質問する。
3. 情報取得：規程はRAG、現在値は業務API、集計は許可済みDBクエリまたは分析APIへルーティングする。
4. 検証：レスポンスのスキーマ、単位、取得時刻、対象条件、権限、鮮度SLAをアプリケーション側で検査する。
5. 計算・判定：金額計算、閾値判定、重複排除は決定的なロジックで処理する。
6. 回答生成：LLMは検証済みの値とRAGで得た規程を使い、説明文を作る。画面にはデータ時点と根拠を表示する。
7. 操作実行：更新系は、利用者の再確認または業務ルール上の承認を通過してからAPIを呼ぶ。

架空の例：「東京倉庫で商品Aは何個売れるか」という質問に対し、RAGは「引当可能在庫」の定義と出荷ルールを探す役、在庫APIは現在の引当可能数を返す役、計算処理は予約・安全在庫を差し引く役、LLMは最終的な説明を作る役に分けます。RAGの文書に「在庫あり」と書かれていても、その文だけを注文可否の確定根拠にはしません。

実装前に決めるデータ契約テンプレート

以下はMojiによる提案です。データ項目ごとに、このシートを埋めると、RAGへ混ぜてよい情報とツール照会すべき情報が整理しやすくなります。

停止条件：値を返さない・実行しない基準を先に決める

高品質な回答を目指すだけでなく、確定できないときに停止する条件を実装します。少なくとも次のケースでは、推測した数値を返さず、再取得または人への引継ぎへ切り替える設計を検討します。

• API・DB照会が失敗、タイムアウト、または部分成功した。
• 返却値がスキーマ、単位、通貨、対象期間の検証に通らない。
• 取得時刻が鮮度要件を超えている。
• ユーザーの権限、拠点、顧客IDなど、対象範囲を確定できない。
• 複数の正システムが矛盾する、または同期遅延中である。
• RAGの規程とAPI結果が食い違い、例外ルールを自動解釈できない。
• 金銭・在庫・外部送信・権限変更に関わる更新で、必要な承認がない。

停止時の文言も事前に決めます。たとえば「現在の引当可能数を確認できないため、数値を確定して案内できません。担当者による確認へ切り替えます」のように、不明な理由、行わなかった操作、次の担当を示します。「在庫はおそらくある」といった補完は避けます。

評価はRAGとツール照会を分けて行う

評価対象を混ぜると、「回答が不正確だった」ことしか分かりません。Mojiでは、少なくとも次の4層でテストケースを作ることを提案します。

テストには、正常系だけでなく、改定直後、ゼロ在庫、同名商品、複数通貨、時差境界、APIの遅延、権限なし、矛盾データ、更新失敗後の再実行を含めます。RAG評価データの作り方は、RAG評価データセットの作り方で詳しく解説しています。

導入前チェックリスト

• □ 各データ項目に、唯一または優先順位付きの「正となるシステム」を定めた。
• □ 現在値、文書説明、集計、更新操作を同じ経路に混在させていない。
• □ API・DBの返却値に、取得時刻、単位、対象範囲、データ源を含めた。
• □ 期間、タイムゾーン、取消・返品、税、通貨などの集計条件を固定した。
• □ LLMに任意SQLや書き込み権限を直接与えず、許可済みのツール・引数・認可へ制限した。
• □ 鮮度超過、照会失敗、権限不明、矛盾、承認不足で停止する条件を実装した。
• □ 回答テストとは別に、検索、ツール照会、計算、承認・実行を評価した。
• □ 操作系には、利用者または業務ルールに基づく最終確認、冪等性、監査ログを用意した。

まとめ

RAGを「古い情報しか扱えない仕組み」と決めつける必要はありません。更新された規程、商品情報、手順書を検索し、根拠を付けて説明する用途では有力です。一方で、現在の在庫・売上・価格・残高を確定する責任をRAGの検索結果と生成文だけへ持たせるかは、業務要件に照らして別途判断する必要があります。

設計の出発点は、データごとに「正となるシステム」「鮮度」「許容誤差」「計算条件」「失敗時の停止」「更新時の承認」を決めることです。RAGは説明、要件を満たすDB・APIは確定値の取得、決定的な処理は計算、承認と認可は操作統制、と役割を分けることで、AIの会話性を活かしながら、数値と実行の信頼性を管理しやすくなります。