この記事のポイント
- 基盤モデルは学習時点の一般知識しか持たない。最新のSAP業務データは実行時に検索して渡す（＝RAG）のが基本解
- RAGは「埋め込み→ベクトル類似検索→プロンプト合成→接地された回答」の4段階で、品質の大半はチャンキングとメタデータ設計で決まる
- SAP HANA Cloudのベクトルエンジンなら、REAL_VECTOR型の意味検索と伝票・マスタの結合を同じSQLで扱える
- ハルシネーション低減は7つの打ち手の組み合わせ。「説明は生成AI、確定はAPIと承認」という役割分離が要になる
01WHAT LLMは自社の最新SAPデータを知らない
生成AIの回答品質を決めるのは、モデルの賢さだけではありません。どれだけ高性能な基盤モデルでも、学習が終わった時点より後の出来事や、社内にしか存在しないデータは知りません。昨日登録された購買発注、今朝更新された在庫、先月変更された得意先の与信限度——これらはモデルの中には入っていない、というのが出発点です。
この前提を置かずに「SAPのことに詳しいAIアシスタント」を作ろうとすると、もっともらしいが事実と違う回答（ハルシネーション）が返ってきます。現場で最初にぶつかる壁は、モデルの性能ではなくデータの鮮度と根拠の欠如です。
なぜ基盤モデルは自社データを知らないのか
基盤モデル（Foundation Model）は、公開された大量のテキストで事前学習された汎用モデルです。一般知識と言葉の扱いは非常に得意ですが、特定企業のS/4HANAの中身を覚えてはいません。しかもSAPの業務データは日々動きます。昨日の正解が今日も正解とは限らない世界です。
ここで「社内データを追加学習させればよいのでは」という発想が出ます。ファインチューニングは有効な手段ですが、更新のたびに再学習と再デプロイが必要で、コストとリードタイムがかかります。モデルに覚えさせるのではなく、その都度調べて渡す——この発想の転換がRAGです。
RAGの4段階——埋め込み・ベクトル検索・プロンプト合成・回答
RAG（Retrieval-Augmented Generation）は、質問が来た瞬間に社内の信頼できる情報を検索し、その結果を根拠としてプロンプトに添えてからLLMに答えさせる仕組みです。回答を自社データに接地させる、という意味で「グラウンディング（Grounding）」とも呼ばれます。処理は大きく4段階に分かれます。
- 埋め込み（Embedding）：質問文と社内文書を、意味を表す数値ベクトルに変換する
- ベクトル類似検索：質問ベクトルに近いチャンク（断片）を上位3〜5件取得する
- プロンプト合成：質問＋取得した根拠＋「根拠の範囲で答える」という指示を1つに組み立てる
- 回答生成：LLMが根拠に基づいて説明文を生成し、出典を添えて返す
用語補足：埋め込み（Embedding）とは
テキストを数百〜数千次元の数値の並び（ベクトル）に変換する処理です。意味が近い文章はベクトル空間でも近い位置に置かれるため、キーワードが一致していなくても「意味が近い」検索ができます。「在庫が合わない」という質問で「棚卸差異の原因」の文書が拾えるのはこのためです。
SAP HANA Cloudベクトルストア——SAPデータの隣に置く
RAGの品質を最も左右するのは、モデルの選定よりも「データをどう切って、どこに置くか」です。SAPの場合はSAP HANA Cloudのベクトルエンジンが第一候補になります。REAL_VECTOR型の列に埋め込みを保存し、VECTOR_EMBEDDING()で変換、COSINE_SIMILARITY()で類似度を計算する。CAP側ではcds.Vector型として宣言できます。
最大の利点は、意味検索と業務データの結合を1本のSQLで書けることです。「質問に近い社内文書」と「その文書が対象とする伝票・品目」を別基盤に分けずに済むため、複製・同期・データ所在地の問題が発生しません。SAPの権限設計の延長線上でアクセス制御を考えられる点も、実運用では大きな差になります。
チャンキングは「検索単位」で考える
文書を細かく刻みすぎると文脈が欠け、粗すぎるとノイズが混ざります。300〜800字を目安に、見出し・段落・手順の単位で切り、前後を2割ほど重ねる。そして必ず出典・モジュール・プラント・更新日・権限区分をメタデータとして付けておくと、検索時の絞り込みと権限制御が後から効いてきます。
02POINTS SAP業務データでRAGを組む6ステップ
実際のプロジェクトでは、モデルの選定より先に「どの業務の、どの問いに答えるのか」を固めます。順序を間違えると、精度が出ない原因がデータ側なのかプロンプト側なのか分からなくなります。以下の6ステップで進めるのが現実的です。
- ①ユースケースを「検索で答えられる問い」に絞る「遅延している発注と、その理由を知りたい」のように1文で書ける業務に限定する。雑談・創作・曖昧な相談はRAGの対象外と割り切る。
- ②ナレッジソースを決める根拠になるのはSAP業務データ（伝票・マスタ）か社内文書かを決め、そのデータの所有者・更新頻度・権限区分を確認する。ここが曖昧なまま進めると後工程が必ず詰まる。
- ③チャンキングとメタデータを設計する300〜800字を目安に切り、出典・モジュール・プラント・更新日・権限区分をメタデータとして持たせる。検索の絞り込み条件はここで決まる。
- ④埋め込みモデルとベクトルストアを選ぶSAPデータが中心ならSAP HANA Cloudのベクトルエンジン（REAL_VECTOR型）が最短。意味検索と業務データの結合を同じSQLで書けるため、構成が小さく収まる。
- ⑤検索→プロンプト合成→回答生成を組み立てるSAP AI Core／Generative AI HubのOrchestration Service（Groundingモジュール）を使うと、根拠の注入・データマスキング・コンテンツフィルタリングを設定ベースで扱える。アプリ側はCAPからSDK／RESTで呼び出す。
- ⑥評価と運用を回す正解が分かっている質問を20〜30件用意し、根拠が取れているか・回答が事実と合うかを定期確認する。データ更新時の再インデックスも運用タスクとして先に決めておく。
検索が外れれば回答も外れます。したがって打ち手の中心は「生成を賢くする」ことではなく、「根拠を取りこぼさず、根拠のない断定をさせない」方向に置くのが正解です。
評価用の質問セットを最初に作る
「正解が分かっている質問」を20〜30件、プロジェクト初期に用意してください。回答文ではなく「期待する根拠チャンクが検索上位に入ったか」で見ると、検索側と生成側のどちらを直すべきか切り分けられます。データを追加するたびに同じセットで再評価すれば、劣化にも気づけます。
03INSIGHT RAGが向く用途・向かない用途
RAGは万能ではありません。向くのは「文章として根拠があり、その内容を説明させたい」用途です。逆に、数値の確定や伝票の更新はRAGの守備範囲外で、そこを生成AIに任せると監査に耐えない仕組みになります。判断の目安を整理すると次のとおりです。
| やりたいこと | RAGの適否 | 理由と代替手段 |
|---|---|---|
| 社内規程・手順書・SAP Helpの横断検索 | 向く | 文章が根拠になり、出典を示せる |
| 遅延している発注とその理由の説明 | 向く | 伝票と納入履歴を根拠に要約させられる |
| 過去の障害・問い合わせ履歴の検索 | 向く | 非構造データが中心で、意味検索が効く |
| 在庫数量・金額の確定値を出す | 向かない | 集計はCDSビューやAnalyticsで計算し、LLMには説明だけさせる |
| 発注書の新規作成・納期変更 | 向かない（要注意） | 決定的なトランザクション。OData API＋CAPの検証＋承認が本線 |
| 単純な条件検索・定型レポート | 向かない | 通常のSQLやSAP Queryで足りる。生成AIを挟むと遅く高くつく |
この線引きを一文にすると「説明は生成AI、確定はAPI」です。金額・数量・在庫の確定はOData API・CDSビュー・転記ロジックが担い、更新操作はCAPで業務オブジェクトを検証してから、必要に応じて承認フローに載せる。生成AIには文章を書かせ、数字は計算させない。この分離がテスト可能性と監査対応を担保します。
もう一点、RAG導入の成否を分けるのはデータ整備です。SAPの業務データはすでに構造化され、権限も設定され、更新日時も持っています。この資産をそのまま検索対象にできることが、SAP案件でRAGを組むときの最大の利点です。拡張アプリの土台はSAP BTP CAP入門：Cloud Application Programming Modelで作るS/4HANA拡張アプリで解説しています。
基盤側のAI CoreとGenerative AI Hubの役割分担はSAP AI Core／Generative AI Hubとは？BTP上でLLMを安全に使う仕組みに、機密データを外部に出さない構成はローカルLLMで実現する、安全なSAP×AI活用にまとめています。まずは既存のSAP標準機能とCDSビューでどこまで答えられるかを確認し、その上でRAGを足す順序が安全です。購買データのように構造がはっきりした領域は、SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説のような基礎を押さえておくと、根拠として何を引くべきかが決めやすくなります。
豆知識：RAGという言葉の由来
RAGは2020年に発表された論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で広く知られるようになりました。当時は「モデルのパラメータを増やさずに知識を足す手法」として提案されています。現在は、企業内データを扱う生成AIの標準パターンとして定着しました。
まとめ
- 基盤モデルは学習時点の一般知識しか持たない。最新のSAP業務データは実行時に検索して根拠として渡す
- RAGは「埋め込み→ベクトル類似検索→プロンプト合成→接地された回答」の4段階
- 品質の大半はチャンキングとメタデータ設計で決まる。モデル選定より先にデータを整える
- SAP HANA Cloudのベクトルエンジンなら、意味検索と伝票・マスタの結合を同じSQLで扱える
- ハルシネーション低減は7つの打ち手の組み合わせ。特に高リスク操作の人間承認は必須
- 「説明は生成AI、確定はAPI」。数値計算と更新は決定的なロジックに任せる
04FAQ よくある質問
RAGとファインチューニングはどう使い分けますか？
頻繁に変わる事実（在庫・伝票・マスタ）はRAG、あまり変わらない振る舞いや文体、社内専門用語の扱いを覚えさせたい場合はファインチューニング、という分け方が基本です。両者を併用する構成も一般的ですが、まずRAGで根拠を渡す設計を作り、それでも足りない部分だけを追加学習する順序が安全です。
SAPのデータをそのままベクトル化してよいのでしょうか？
権限設計を先に決めてください。利用者が見られないデータを検索対象に含めると、回答経由で情報が漏れます。メタデータに権限区分を持たせ、検索時に必ず絞り込むことが前提です。氏名や取引先名などの機密情報は、Generative AI Hubのデータマスキングと併用してからLLMに渡します。
HANA Cloud以外のベクトルデータベースでも作れますか？
作れます。ただしSAPの業務データを別基盤に複製することになるため、データ所在地・権限・更新同期の管理コストが増えます。SAPデータが根拠の中心なら、すでにデータがあるSAP HANA Cloud上にベクトルを置くほうが、構成も運用も小さく済みます。
RAGを入れればハルシネーションはゼロになりますか？
ゼロにはなりません。根拠の検索漏れ、古いインデックス、曖昧な質問では誤りが残ります。RAGは「根拠のない回答」を減らす仕組みであり、本記事で挙げた7つの打ち手と人間の承認を組み合わせて初めて業務に耐える水準になります。
出典・参考
- Retrieval Augmented Generation (RAG)（SAP Developers） https://developers.sap.com/concepts/retrieval-augmented-generation/
- SAP AI Core ドキュメント（SAP Help Portal） https://help.sap.com/docs/sap-ai-core
- Generative AI Hub（SAP Developers） https://developers.sap.com/concepts/generative-ai-hub/
- SAP HANA Database Vector Engine（SAP Help Portal） https://help.sap.com/docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-vector-engine-guide/sap-hana-database-vector-engine
- AI（SAP Developers） https://developers.sap.com/ai/
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-21）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。