# SAP データと AI 連携で先に設計すべきものは何か

SAP データに AI をつなぐ話になると、多くの議論はモデル選定に集中します。もちろんモデルの性能は重要です。ただし、企業で実際に難しくなるのはそこではありません。

SAP BTP 上で AI を業務に近づけるときに先に設計すべきなのは、権限, 業務文脈, 監査性 です。ここを曖昧にしたまま PoC を進めると、答えは返ってきても本番で止まります。

この記事では、なぜ SAP データと AI の連携でモデルより先に BTP 上の設計論が必要になるのかを整理します。

先に結論

結論はかなり明快です。SAP データと AI を安全に結びつけるには、次の順番で考えるべきです。

  • 誰の権限でそのデータを見るのか
  • その質問や提案がどの業務文脈に属するのか
  • 後から何を根拠にそう��断したかを追えるのか

つまり、

  • モデル接続の前に権限境界を決める
  • 回答生成の前に業務文脈を定義する
  • 自動化の前に監査経路を残す

必要があります。

なぜモデルの話だけでは足りないのか

SAP データは、単に構造化データが並んでいるだけではありません。受注、在庫、請求、承認、与信、購買といった業務責任の中で意味を持つデータです。

そのため、たとえば同じ売上データでも、

  • 誰が見てよいのか
  • どの販売組織の数字なのか
  • 確定値なのか見込み値なのか
  • どの承認状態にあるのか

が分からないまま AI に渡すと、自然な文章は返ってきても業務判断としては危険になります。

例えば「在庫は足りるか」という問いに対しても、利用可能在庫、検査中在庫、引当済み在庫を区別しなければ、答えは簡単にズレます。

BTP で特に重くなる 3 つの論点

1. 権限継承

BTP 側のアプリや AI Agent が backend の SAP データに触るとき、利用者本人の業務権限と技術的な接続権限がズレることがあります。

ここを曖昧にすると、AI は動いても、ユーザーに見せてはいけない顧客情報や部門情報まで要約してしまう可能性があります。

2. 業務文脈

主データやトランザクションデータは、それだけでは意味が足りません。どのプロセスの、どの時点の、どの責任範囲の話かが揃って初めて判断材料になります。

BTP 上で AI を構成するなら、プロンプトや検索対象に業務文脈をどう乗せるかが極めて重要です。

3. 監査と説明可能性

企業 AI は、便利な答えを返すだけでは足りません。

  • どのデータを参照したか
  • どのルールで絞り込んだか
  • 誰が実行し、誰が承認したか
  • 自動実行がどこまで及んだか

を追えないと、業務運用にも監査にも耐えません。

権限を曖昧にしたときの典型的な失敗

例えば、営業マネージャー向けの AI 要約機能を考えます。BTP 上の AI が受注残、粗利、未回収債権をまとめて返す設計です。

このとき backend 接続用の広い技術権限でデータを取得し、後からアプリ側で適当に絞ると、利用者本人には見えてはいけない情報が混ざる恐れがあります。

| 観点 | 問題のある設計 | 望ましい設計 |

|---|---|---|

| データ取得 | 技術ユーザーの広権限で一括取得 | 利用者ロールや責任範囲を前提に取得 |

| 応答制御 | 出力時に後付けで調整 | 入力段階から権限境界を反映 |

| 監査 | 誰向けの回答か曖昧 | ユーザー、参照元、出力内容を追跡可能 |

この違いは PoC では見えにくいですが、本番では一気に効いてきます。

業務文脈を落とすと回答は壊れる

SAP の主データや業務状態は、値そのものより意味づけが重要です。

例えば、得意先コードや品目コードが分かっても、

  • どの会社コードか
  • どのプラントか
  • どの会計期間か
  • どの承認状態か

が抜けるだけで、AI の解釈は簡単にズレます。

Joule、AI Core、外部 LLM のどれを使うにせよ、BTP の役割は単にモデルを呼ぶことではありません。業務文脈を壊さずに AI へ渡す土台を作ること が重要です。

監査を後付けにすると本番で止まる

例えば AI が、

  • 出荷停止を提案した
  • 請求差異の原因候補を示した
  • 補充発注の優先順位を出した

とします。このとき本番で必要なのは、モデル名よりもむしろ、

  • 参照データの範囲
  • フィルタ条件
  • 業務ルール
  • 承認者と実行履歴

です。

後から説明できない提案は、業務部門にとっては責任が持てません。便利でも、そこで止まります。

導入順序はどう考えるべきか

実務では、次の順番が堅実です。

1. 対象業務を絞る

2. データの可視範囲と権限境界を定義する

3. 業務文脈を付与できるデータ設計を行う

4. 監査ログと承認経路を先に設計する

5. その上で AI Core や外部モデルの選定に入る

この順番なら、PoC で終わるか、本番に進めるかを早い段階で判断できます。

まとめ

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

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

この 3 点を BTP 上で先に設計しない限り、AI は賢く見えても企業システムとしては危ういままです。

企業 AI で問われるのは、派手なデモよりも責任を持てる設計です。SAP 文脈では、その順番を外さないことが最も重要です。