はじめに
この記事は連載の最終回です。これまでの記事では、Jouleのセットアップ手順・各SAP製品との統合・Document Grounding・制約事項を扱いました。
この記事では、SAP Master Data Governance – Business Partner（MDG-BP）とJouleを統合した場合のアーキテクチャ・業務プロセス・運用監視の構造を解説します。
この記事の情報源は、連載の他の記事（SAP公式ドキュメント）とは異なり、SAP Best Practices文書（著者：Hans-G. Emrich、2025年11月）をもとにしています。効率化数値などの推計値は著者の試算であり、SAP公式仕様ではない点に注意してください。
MDG-BPとは
SAP Master Data Governance – Business Partner（MDG-BP）は、ビジネスパートナー（仕入先・得意先など）のマスターデータを中央管理・統制するためのSAPソリューションです。
主な機能は以下のとおりです。
- チェンジリクエスト（CR）ベースのデータ変更管理
- BRFplusルールによる入力値検証・導出
- 重複チェック（Fuzzy Logic / HANA Search）
- DRF（Data Replication Framework）によるS/4・ECC等への配布
- Workflow（承認プロセス）の管理
Jouleと統合することで、ユーザーは自然言語でMDG-BPの操作を行えるようになります。
アーキテクチャの全体像
JouleとMDG-BPの統合は、3つの層で構成されます。
1. SAP Joule（AI インタラクション層）
- 自然言語入力のIntent認識
- エンティティ抽出（名前・住所・法人格・税データなど）
- AI支援によるデータ補完・バリデーション
- MDG-BPとは直接通信せず、BTPを経由する
2. SAP BTP（オーケストレーション層）
- Integration Suite（CPI）によるAPIルーティング・変換
- MDG-BP APIへのデータ転送（SOAP/REST）
- 認証・認可（IAS/IPS）
- ログ管理・コンプライアンス対応
3. SAP MDG-BP（ガバナンス実行層）
- BRFplusルールによる検証・導出
- チェンジリクエスト（CR）の生成・ワークフロー
- DRFによるダウンストリームシステムへのレプリケーション
JouleはMDG-BPと直接通信しません。必ずBTPを経由する構造になっています。
役割分担を一言でまとめると、「Jouleがトリガーし、BTPがオーケストレートし、MDG-BPがガバナンスを実行する」です。
エンドツーエンドフロー
新規ビジネスパートナー作成を例に、8ステップのフローを確認します。
Step 1: ユーザーがJouleに自然言語で入力する
例：「ドイツのGmbHで新規サプライヤーを登録して」
Step 2: JouleがIntentを認識し、エンティティを抽出する
- Intent: 新規BP作成
- 抽出: 国（ドイツ）・法人格（GmbH）・役割（サプライヤー）
Step 3: LLMが情報を補完・検証する（オプション）
外部データソース（VIES・CDQ・商業登記）との照合
Step 4: BTPがMDG-BP APIを呼び出す
Step 5: MDG-BPがチェンジリクエスト（CR）を生成する
- MDG内部チェック（BRFplus・重複チェック）が自動実行される
Step 6: MDGワークフローで検証・承認が行われる
Step 7: DRFがマスターデータをダウンストリームシステムへ配布する
対象：S/4HANA・ECC・Ariba・CFINなど
Step 8: Jouleがユーザーに結果を通知する
例：「サプライヤーが正常に作成されました」
7つのE2Eプロセス
MDG-BPとJouleの統合で実現できる主要な業務プロセスは以下の7つです。
| # | プロセス | Jouleの役割 |
|---|---|---|
| 1 | 新規BP作成 | 自然言語入力からCR生成まで |
| 2 | BPデータ変更・保守 | 変更内容のCRを対話形式で生成 |
| 3 | 重複チェック（CDQと連携） | 重複候補の提示・判断支援 |
| 4 | Ariba SLP経由のBPオンボーディング | SLP→MDG-BPへのデータ橋渡し |
| 5 | バリデーション（CDQ・VIES・商業登記） | 外部ソースとの照合結果を提示 |
| 6 | モニタリング・エラー分析 | 自然言語でのモニタリング問い合わせ |
| 7 | データ配布（MDG→DRF→S/4→後続プロセス） | レプリケーション状況の確認 |
Governance & Securityの設計
統合環境のセキュリティは以下の要素で構成されます。
- OAuth2による認証
- Identity Access Management（IAM）
- 監査ログ（Audit Log）の取得
- 監査対応可能なログ保管
AI支援による意思決定については、以下の情報が監査目的で記録される必要があります。
- どのユーザーが、どのAI支援決定を確定したか
- なぜAIの推奨が却下されたか
- Jouleが事前入力・変更したデータはどれか
監視（Monitoring）の構造
監視対象コンポーネント
SAP Joule側
- Natural Language Interface
- Joule Models / Skills for MDG-BP
- Process & Context Engine
- MDG-BP Connector（OData/REST）
SAP MDG-BP側
- Fiori Apps
- CRワークフロー
- BRFplusルール
- DRF統合
外部システム
- CDQ（住所検証・マッチング）
- SAP Ariba SLP（オンボーディング）
- SAP Integration Suite（CPI）
- ダウンストリームS/4システム
主要な監視指標（KPI）
| カテゴリ | 監視項目 |
|---|---|
| Technical | Jouleプロンプト成功率、API平均応答時間、CPIメッセージステータス |
| Process | CRターンアラウンドタイム、重複件数/日、Joule修正提案数 |
| Quality | 住所検証率、データ品質スコア（DQM）、CDQマッチ信頼度 |
| Compliance | AI推奨却下件数（監査ログ）、承認結果との差異 |
アラートシナリオの例
- Jouleが応答しない（APIタイムアウト・クラウドサービス障害）
- CR生成不可（ODataエラー・権限不足）
- CDQアドレス検証エラー率 > 5%
- 重複チェック：MDGとCDQの結果に矛盾（ファジースコア差 > 25%）
- プロンプトエラー率 > 40%
「Joule Suggestion Override Rate（ユーザーがAI提案を何回修正したか）」は品質の重要指標です。このレートが高い場合（例：35%以上）は、ルール定義やトレーニングデータの見直しが必要なサインとされています。
監視ツール
- SAP Cloud ALM（CALM）: Joule・CPI・SLP
- SAP Application Log: MDG-BP
- Fiori Monitoring Apps（MDG）
- CPI Message Monitor
- DRFLOG
- CDQ API Dashboards
RACI
| 役割 | 責任範囲 |
|---|---|
| MDG-BP Operations | CRプロセス・バリデーションの監視 |
| Data Quality Owner | AI提案と修正の評価 |
| Integration Team（CPI） | SLP/CDQ統合エラー対応 |
| MDG Functional Lead | Joule/BRFplusの差異レビュー |
| SAP Basis/Cloud Team | Joule可用性・パフォーマンス |
統合によって期待される効果
以下の数値は著者の試算であり、SAP公式仕様ではありません。実際の効果は環境・スコープによって異なります。
生産性
- BP作成・保守プロセスの処理速度：40〜70%向上（試算）
- CRプロセスの処理時間：最大50%削減（試算）
データ品質
- 手動入力ミスの大幅減少
- AIマッチングによる重複の削減
UX
- 研修コスト：60〜80%削減（試算）
- 業務部門のMDGトランザクション不要化
統合プロジェクトの規模感
著者の試算によるプロジェクト期間の目安は以下のとおりです（スコープ・外部統合数によって変動）。
Phase 1: 準備・プロジェクト設定（1〜2週目）
Phase 2: アーキテクチャ・設計（2〜4週目）
Phase 3: 技術実装（4〜10週目）
Phase 4: テスト・品質保証（10〜13週目）
Phase 5: 展開・Go-Live（13〜15週目）
Phase 6: ハイパーケア・通常運用移行（15〜18週目）
合計：12〜18週
まとめ
JouleとMDG-BPの統合における技術的なポイントをまとめます。
- JouleはMDG-BPと直接通信せず、必ずBTPを経由する3層アーキテクチャ
- BTPのIntegration Suite（CPI）が、JouleからのリクエストをMDG-BP APIへ変換・ルーティングする
- MDG側のガバナンスロジック（BRFplus・CRワークフロー・DRF）はそのまま維持される
- AI支援の意思決定については、監査対応のためのログ設計が必要
- 監視は「Technical・Process・Quality・Compliance」の4カテゴリで構成する
- 「Joule Suggestion Override Rate」が品質劣化の早期検知指標として機能する
これで連載17本が完結しました。
用語解説
MDG-BP（Master Data Governance – Business Partner）
ビジネスパートナーのマスターデータを中央管理・統制するSAPソリューション。チェンジリクエストベースのガバナンスプロセスを提供する。
チェンジリクエスト（CR）
MDG-BPにおけるデータ変更の管理単位。新規作成・変更いずれも、CRとしてワークフローを経て承認される。
BRFplus（Business Rule Framework plus）
SAPのルールエンジン。MDG-BP内のバリデーション・導出ロジックを定義する。
DRF（Data Replication Framework）
MDG-BPで承認されたマスターデータを、S/4HANA・ECC・Aribaなどのダウンストリームシステムへ配布するフレームワーク。
CDQ
住所検証・企業データマッチング・レジスターデータ提供を行う外部データサービス。MDG-BPとの統合によりリアルタイムの住所検証や重複チェックを強化できる。
SAP Ariba SLP（Supplier Lifecycle Performance）
サプライヤーのオンボーディング・資格管理を行うSAPソリューション。SLPで登録されたサプライヤーデータをMDG-BPに連携するフローがE2Eプロセスの一つとして定義されている。
Joule Suggestion Override Rate
ユーザーがJouleのAI提案を修正した割合。このレートが高い場合、ルール定義やトレーニングデータの品質に問題がある可能性がある。