SAP データに AI をつなぐとき、最初に設計すべきはモデルではなく権限と業務文脈

SAP と生成 AI の話になると、議論がすぐに「どのモデルを使うか」に寄りがちです。ですが、企業で本当に事故になりやすいのは、モデルそのものより 誰の権限で、どの業務文脈の中で、どの SAP データを見せるのか という設計です。

特に SAP BTP 上で AI を業務に近づける場合、問題は単なる API 接続では終わりません。権限継承、主データの意味、ワークフローの前後関係、監査証跡、説明可能性まで考えないと、PoC は動いても本番で止まります。

この記事では、SAP データと AI をつなぐときに、なぜ モデル精度より先に権限・文脈・監査 を設計すべきなのかを整理します。

先に結論

まず結論です。SAP データに AI を接続するとき、最初に詰めるべきなのは次の 3 点です。

権限：そのユーザーは本当にそのデータを見てよいのか
業務文脈：そのデータはどのプロセス、どの責任範囲、どの時点の意味を持つのか
監査：AI が何を参照し、何を提案し、誰が承認したかを後から追えるのか

つまり、

モデルをつなぐ前に、見せてよい境界を決める
回答を作る前に、意味が壊れない文脈を揃える
自動化する前に、後から説明できる経路を残す

必要があります。

AI の精度は改善できますが、権限設計を誤ったまま本番に出すと、情報漏えいも誤判断も一気に起きます。

なぜ SAP データ連携の AI 議論は浅くなりやすいのか

理由は単純で、デモでは「答えが返ること」が成果に見えやすいからです。

たとえば、受注残、在庫、得意先、請求、承認履歴のようなデータを AI に渡せば、見た目にはかなり賢く動きます。ですが、本番で問われるのは次のような点です。

営業担当 A が、他部門の受注情報まで見えていないか
AI が参照した価格や在庫が、どの時点のデータか分かるか
回答の根拠が、顧客マスタなのか、受注伝票なのか、承認ワークフローなのか説明できるか
AI が提案したアクションを、誰が承認したのか残っているか

要するに、SAP データは「見えればよいデータ」ではなく、責任と文脈を伴う業務データ です。ここを飛ばしてモデル比較だけしても、話が浅くなります。

BTP 上で問題になる 3 つの論点

SAP BTP で AI を成立させるとき、特に重いのは次の 3 論点です。

1. 権限継承

BTP 側でアプリや AI Agent を動かすとき、S/4HANA や周辺システム側の権限モデルと、完全には同じでないことが多いです。

ここが曖昧だと、アプリの技術ユーザーは見えているが、業務ユーザーとしては見えてはいけない という最悪の状態になります。

2. 主データと業務文脈

得意先コード、品目コード、組織コード、会計期間、承認状態などは、ただの値ではありません。SAP の世界では、その値がどの業務文脈で意味を持つかが重要です。

文脈を落として AI に渡すと、見た目はもっともらしくても、業務判断としてズレた回答を返します。

3. 監査と説明可能性

企業 AI は「当たったかどうか」だけでは足りません。

どのデータを参照したか
どのルールでフィルタしたか
誰が実行したか
どこまで自動で処理したか

を追えないと、監査でも運用でも詰みます。

権限継承を曖昧にすると何が壊れるか

ここは一番わかりやすく事故ります。

例えば、営業マネージャー向けの AI アシスタントを BTP 上で作り、受注残や粗利見込みを返すとします。このとき AI が backend の広い権限でまとめてデータを取りにいくと、利用者本人には見えてはいけない顧客や組織の情報が混ざる可能性があります。

設計観点	雑に実装した場合	ちゃんと設計した場合
データ取得主体	技術ユーザー固定	利用者権限や業務ロールに沿って制御
フィルタ条件	後付けのアプリ側条件	データ取得前提から権限境界を反映
監査	誰向け回答か不明瞭	ユーザー、参照先、応答履歴を追跡可能

例えば、同じ「売上を要約して」と聞いても、事業部長と営業担当で見えてよい範囲は違います。ここを BTP 側で受け止めずに AI を直結すると、便利な要約機能がそのまま情報漏えい装置になります。

主データと業務文脈を失うと回答はどうズレるか

SAP データは、表の列だけ見ても意味が足りないことが多いです。

例えば「在庫があるか」という問い一つでも、

利用可能在庫なのか
検査中在庫なのか
予約済みを含むのか
どのプラント、どの販売組織の話か

で業務判断は変わります。

AI に単にテーブルの値だけを渡すと、こうした意味の差を落としやすいです。すると、回答は文法的には自然でも、業務的には危険になります。

特に Joule、AI Core、あるいは外部 LLM をどう組み合わせるにしても、BTP 側で どの業務プロセスに属する質問か を押さえないと、回答はどんどん一般論に流れます。

監査と説明可能性を後付けにしてはいけない理由

企業で AI を使う以上、「便利だった」で終わることはありません。

後から必ず問われるのは、なぜその回答になったのか です。

例えば、AI が次のような提案をしたとします。

与信超過の可能性がある顧客への出荷停止を勧めた
請求差異の原因候補を提示した
在庫補充の優先順位を提案した

このとき必要なのは、モデル名よりもむしろ、

参照した SAP データの範囲
使ったルールやフィルタ
プロンプトに含めた業務条件
提案を受けて誰が承認したか

です。

例えば監査部門や業務責任者に説明するとき、ここが残っていないと「便利だけど責任が持てない」仕組みになります。そんなものは本番では長続きしません。

導入順序は「モデル選定」から始めない

実務では、次の順で考える方が安全です。

対象業務を決める
- 受注、購買、在庫、請求、承認など、どのプロセスを扱うのか
見せてよいデータ境界を定義する
- 組織、役割、責任範囲、個人情報、機微情報を整理する
文脈情報を整える
- 主データ、状態遷移、時点、承認状況を揃える
監査経路を先に作る
- ログ、参照元、承認者、実行履歴を残す
その上でモデルや AI Core / 外部 LLM を選ぶ

この順序にしておくと、PoC の時点から「本番に持っていけるか」を判断しやすくなります。

試験や提案で迷った時の判断軸

もし「SAP データと AI をつなぎたい」という相談を受けたら、先に次を確認すると外しにくいです。

その AI は 誰の代理で 動くのか
回答や提案は どの業務文脈 に属するのか
参照データは どこまで見せてよい のか
後から 説明・監査・承認 ができるのか

これに答えられない段階でモデル比較を始めるのは、順番が逆です。

まとめ

SAP データと AI の連携で本当に難しいのは、モデル選定ではありません。

権限をどう継承するか
業務文脈 をどう保ったまま渡すか
監査と説明可能性 をどう残すか

この 3 つを BTP 上で先に設計しておかないと、PoC は動いても本番では壊れます。

AI を業務に近づけるほど、求められるのは派手なデモではなく、責任を持てる設計 です。SAP 文脈では、そこを避けて通れません。