導入実践チェックリスト
─ SAP × AI 大局観 深堀り版 ─
判断・設計・リスク・ガバナンス の全フェーズをカバーする実践診断ツール
2026年7月 Paddy&Water株式会社
第一章：本書の使い方とスコアリング
1.1 対象読者と活用場面
本書は、SAPを基幹システムとして運用する製造業・流通業・ハイテク企業において「AIエージェントをSAP業務にどう組み込むか」を検討・設計・推進するCIO・DX推進部門・ERPプロジェクトマネージャー・業務改革リーダーを対象とします。既存のSAP環境へのAI付加価値追加から、BTPを介したAIエージェント自律実行基盤の構築まで、導入ライフサイクル全体をカバーします。
| フェーズ | チェックリスト章 | 目的・問い |
| Phase 0：導入判断 | 第二章 | 「そもそも今、AI導入をすべきか？」の経営・現場両面診断 |
| Phase 1：ユースケース選定 | 第三章 | 「どの業務・モジュールからAIを始めるか？」の優先度評価 |
| Phase 2：技術アーキテクチャ設計 | 第四章 | 「SAP BTP・Joule・外部AIをどう組み合わせるか？」の設計診断 |
| Phase 3：データ・セキュリティ | 第五章 | 「AIが扱うSAPデータのガバナンスは整っているか？」 |
| Phase 4：変更管理・人材育成 | 第六章 | 「組織・人はAI活用に対応できる状態か？」 |
| Phase 5：ガバナンス・リスク | 第七章 | 「AIが誤った判断をした場合の制御機構はあるか？」 |
| Phase 6：本番稼働・KPI管理 | 第八章 | 「AIの効果測定と継続改善サイクルは回るか？」 |
1.2 スコアリング方法
| 重要度バッジの読み方 |
|
H（赤）= 高重要度：このチェックがNOの場合、導入リスクが重大。放置したまま進めない M（橙）= 中重要度：このチェックがNOの場合、品質・効果に影響。計画段階での対応を推奨 L（緑）= 低重要度：このチェックがNOの場合、最適化余地あり。運用開始後に改善可能 【スコア集計方法】 Step 1：各フェーズのHチェック項目のうち「□ 未確認・NG」の数をカウント → Hスコア Step 2：全フェーズのHスコア合計で下記マトリクスに照合し、全体判定を行う |
| Hスコア 0〜3：グリーンライト → AIエージェント本格検討フェーズへ進む | Hスコア 4〜7：イエロー → 課題領域を優先解決後に再診断 | Hスコア 8以上：レッドライン → 基盤整備なしのAI導入は高リスク |
第二章：Phase 0 — 導入判断チェック（Should we do AI now？）
2.1 経営・戦略レイヤー
AIエージェント導入の最初の関門は「経営層のコミットメントと業務仮説の有無」です。技術先行・流行追随型の導入が最も失敗率が高い領域です。以下のチェックをOKR・中期経営計画・DX戦略と照合してください。
| 確認 | 経営・戦略レイヤー | 重要度 |
| □ | AIエージェント導入の目的が「コスト削減」「収益向上」「業務品質向上」のいずれか1つ以上に具体的に紐づいている | H |
| □ | CIO / CDO / 事業部長など経営層のスポンサーが明示的に任命されており、予算権限を持っている | H |
| □ | 「AIを使って何をしたいか」が定量的な仮説（例：受注入力工数を月50h削減）として文書化されている | H |
| □ | SAPのRoad Map（S/4HANA移行・ECC保守終了対応）とAI導入計画のタイミングが整合している | M |
| □ | 競合他社のAI導入動向・業界標準を把握した上での意思決定である（流行追随ではない） | M |
| □ | 導入ROIの試算が少なくとも粗算（ラフオーダー）レベルで行われており、投資回収期間のイメージがある | M |
| □ | AIエージェント専用予算（PoC・本番・継続改善を含む3ヶ年）が確保または確保の見通しがある | H |
2.2 現場・業務レイヤー
経営判断が揃っても、現場業務の「AIが入り込める余地」がなければ投資は無駄になります。業務プロセスの標準化度・データ品質・現場の課題感を確認します。
| 確認 | 現場・業務レイヤー | 重要度 |
| □ | AIが自動化・支援しようとしている対象業務が、SAPトランザクションとして標準化・定型化されている | H |
| □ | 対象業務でSAPに入力されているデータの品質（正確性・完全性・鮮度）が一定水準以上である | H |
| □ | 対象業務の担当者（現場ユーザー）がAI導入に前向きか、少なくとも中立的な姿勢を持っている | M |
| □ | 現場から「こういう作業は自動化してほしい」「このデータを自動でとってきてほしい」という声がある | M |
| □ | 対象プロセスで発生するエラー・例外処理の割合が20%未満である（例外だらけの業務はAI化困難） | M |
| □ | AI化した場合に「人間が最終確認する」ステップを設計できる業務フローになっている | H |
| □ | 本番稼働後のAIアウトプット（提案・自動処理）を人間が否認・修正する権限と手順が定義されている | H |
第三章：Phase 1 — ユースケース選定チェック（Where to start？）
3.1 SAP × AI ユースケース候補の全体マップ
SAP環境でAIエージェントが活用できる業務は大きく「データ入力・照合の自動化」「異常検知・アラート」「計画最適化」「自然言語インターフェース（NLI）」「マルチステップ自律実行」の5カテゴリに分類されます。
| AIカテゴリ | 代表ユースケース | 対象SAPモジュール | 成熟度 |
| データ入力・照合 自動化 | 仕入先請求書OCR照合（AI-Invoice） 銀行明細マッチング（AI-Bank） EDI受発注の自動転記 | FI-AP / MM-IV FI-BL SD / MM | ★★★★★ 量産実績豊富 |
| 異常検知・アラート | 支払遅延・与信超過の早期警告 在庫異常（急増/急減）アラート QM検査結果の外れ値検知 | FI-AR / FI-AP MM-IM QM | ★★★★☆ 実用段階 |
| 計画最適化 | AI需要予測（IBP for Demand） MRPパラメータ自動調整 輸送ルート最適化（TM） | IBP / PP PP-MRP TM | ★★★★☆ 実用段階 |
| 自然言語インターフェース （NLI / SAP Joule） | 「先月のAR残高は？」自然言語クエリ 業務画面のAIガイダンス 帳票・メール文面の自動生成 | S/4HANA 全域 Fiori / BTP SuccessFactors | ★★★☆☆ 拡大中 |
| マルチステップ 自律エージェント | 受注→ATP確認→出荷指図を自動実行 保全指図の自動起票→部品発注→スケジュール調整 月次決算アシスタント（仕訳提案→レビュー→転記） | SD+EWM+TM PM+MM FI-GL+CO | ★★☆☆☆ PoC段階が多い |
3.2 ユースケース優先度評価チェック
複数のユースケース候補がある場合、以下の観点でスコアリングし、最初のPoC（概念実証）対象を絞り込みます。「効果が大きく・リスクが小さく・データが揃っている」業務から着手するのが鉄則です。
| 確認 | ユースケース優先度評価 | 重要度 |
| □ | 対象ユースケースで自動化・AI化した場合の定量的効果（工数削減h/月、エラー率低下%等）が試算されている | H |
| □ | 対象業務のSAPトランザクションデータ（過去2年以上）が蓄積されており、AIの学習・検証に使用できる | H |
| □ | 選定したユースケースが「SAP Joule」または「SAP BTP AI Services」の標準機能でカバーできるか確認した | M |
| □ | PoC期間（目安3ヶ月以内）で効果検証が完結できる規模のユースケースに絞り込んでいる | M |
| □ | 「最初に成功を見せる」観点で、組織内で最も課題感が高く・協力的なユーザー部門を選定している | M |
| □ | AIが誤った結果を出しても人命・法令遵守・財務への重大影響が生じないユースケースから開始している | H |
| □ | 選定したユースケースの成功基準（KPI・閾値・判定タイミング）がPoC開始前に合意されている | H |
| □ | 同業他社または類似企業でのAI導入事例・ベンチマークデータを参照している | L |
第四章：Phase 2 — 技術アーキテクチャ設計チェック（How to build？）
4.1 SAP BTP と AI 基盤の設計
SAP環境にAIエージェントを組み込む技術経路は主に3つあります。①SAP Joule（SAP標準AI）、②BTP AI Services（SAP製マイクロサービス）、③外部AI（OpenAI / Azure / Google）とBTP Integration Suite経由でSAPを接続する方式です。各方式の選択根拠とアーキテクチャ整合性を確認します。
| AI組込み方式 | 概要・特徴 | メリット | 注意点 |
| ① SAP Joule （標準AI） | S/4HANA・BTP・SuccessFactors等に SAPが標準提供するAIアシスタント 自然言語クエリ・AI推奨・自動補完 | SAPと疎結合なしで動作 RISE/GROWにAI Units含有 データがSAP外に出ない | 機能範囲はSAP定義 カスタムビジネスロジックの適用に制約 日本語対応はモジュール依存 |
| ② BTP AI Services （SAP製マイクロサービス） | 文書情報抽出（DIE）・ビジネスエンティティマッチング 異常検知・推薦エンジン等のAPI群 BTP上でSAPデータに直接アクセス | SAPコンテキストを保ちながら カスタムAI処理を追加可能 No-code/Low-codeで設定可能 | BTP Creditsの消費量管理が必要 モデルはSAP提供に限定 独自MLモデルの組込みは別途開発 |
| ③ 外部AI + BTP Integration （OpenAI / Azure / Google等） | 外部LLM / MLモデルをBTP経由でSAPと接続 RAG（Retrieval-Augmented Generation）で SAPデータを参照してAIが回答 | 最新・最高性能のAIモデルを活用可能 カスタムドメイン知識の訓練が自由 非SAP系データとの統合が容易 | SAPデータを外部AIに送信するため データ残留・プライバシー要件の精査必須 BTP + 外部AI両方のコスト発生 |
4.2 アーキテクチャ設計チェック
| 確認 | アーキテクチャ設計 | 重要度 |
| □ | AI組込み方式（Joule / BTP AI Services / 外部AI）の選択理由が技術・セキュリティ・コストの観点で文書化されている | H |
| □ | SAP BTP Global Accountが設定済みであり、AI処理に必要なBTP Creditsの消費量見積もりが完了している | H |
| □ | AIエージェントがSAPIE API/oDataを呼び出す際の認証方式（OAuth 2.0 / Basic Auth廃止確認）が設計されている | H |
| □ | AIエージェントのアウトプット（仕訳提案・発注提案等）がSAPに書き込まれる場合、承認ワークフローを経由する設計か確認した | H |
| □ | BTPのIntegration Suite（API Management）を介してAPIレートリミット・監視・ログ収集が設定されている | M |
| □ | SAPのCDS View / OData APIのうち、AIが参照するデータの権限範囲（最小権限の原則）が設計されている | M |
| □ | 本番・検証・開発の3環境でAIモデルのバージョン管理とロールバック手順が定義されている | M |
| □ | AI処理のレイテンシ要件（例：受注画面でのATP確認は2秒以内）が測定・合格基準を満たしている | M |
| □ | 外部AIモデルを利用する場合、SAPデータが学習データとして外部モデルに取り込まれない設定の確認（Zero Data Retention） | H |
| □ | SAPのClean Core方針に沿った拡張（BTP側でのAI機能実装）が徹底されており、S/4HANA本体への直接カスタム開発は最小化 | L |
第五章：Phase 3 — データ・セキュリティ・プライバシーチェック
5.1 AIが扱うSAPデータの品質と権限管理
AIエージェントはSAPデータを「見て・判断して・書き込む」ため、データ品質・アクセス権限・個人情報保護の設計が不完全な場合、AI判断の誤りが連鎖的にSAPデータを汚染するリスクがあります。「Garbage in, Garbage out」の原則はAI導入で一層重大になります。
| 確認 | データ・セキュリティ・プライバシー | 重要度 |
| □ | AIが参照するSAPマスタデータ（品目マスタ・得意先マスタ・仕入先マスタ等）のデータ品質基準が定義され、MDMプロセスが確立されている | H |
| □ | AIの学習・推論に使用する過去トランザクションデータ（発注・受注・仕訳等）に欠損値・外れ値が一定基準以下であることを確認した | H |
| □ | AI処理に使用するSAPデータに個人情報（氏名・住所・口座番号等）が含まれる場合、個人情報保護法・GDPRに準拠した匿名化・仮名化が実施されている | H |
| □ | AIエージェントがSAPに書き込み権限を持つ場合、そのRFCユーザー/テクニカルユーザーの権限が最小権限原則で設計されている | H |
| □ | AIが生成した仕訳・発注書・受注変更等のSAP伝票には「AI生成フラグ」が付与され、監査時に識別できる | H |
| □ | SAPのAudit Log（SM19/SM20）でAIエージェントのSAPアクセス全履歴が記録・保管されている | M |
| □ | AIモデルが参照するSAPデータの鮮度（リアルタイム / バッチ更新の遅延）が業務要件を満たしている | M |
| □ | テスト・PoC環境で本番データを使用する場合、データマスキング・匿名化が完了している | H |
| □ | AIベンダー（SAPまたは外部）との契約にデータの取扱い・保管場所・第三者提供禁止条項が明記されている | H |
5.2 SAP Joule 固有のセキュリティ確認
| SAP Joule をSAP環境で利用する場合の追加確認事項 |
|
① Joule が参照できるSAPオブジェクト・機密フィールドの範囲を確認（給与・与信枠・原価情報等の制御） ② Joule セッションデータがSAP Cloudに保管される期間・削除ポリシーを契約書で確認 ③ RISE / GROW サブスクリプションに含まれるAI Units の上限と超過課金の仕組みを把握 ④ BTP Identity Authentication（IdP）によるJoule へのアクセス制御（MFA・SSO）が設定済みか確認 ⑤ Joule の回答を根拠に重大決定（大型発注・決算計上等）を行う場合の「人間確認」ステップが業務フローに組み込まれているか |
第六章：Phase 4 — 変更管理・人材育成チェック
6.1 組織・人への影響管理
AIエージェントの失敗の多くは「技術的問題」ではなく「変更管理の失敗」です。現場ユーザーがAIの判断を信頼しない・正しく使えない・AIが間違えたときに気づけない状態では、ROIは生まれません。
| 確認 | 変更管理・人材育成 | 重要度 |
| □ | AI導入による業務フロー変更の影響範囲（変更される手順・廃止される作業・新設される確認ステップ）が部門別に文書化されている | H |
| □ | 「AIが提案し、人間が最終判断する」業務と「AIが自動実行し、人間が事後確認する」業務の境界が明確に定義されている | H |
| □ | 現場ユーザー向けに「AIの提案が正しくない場合の拒否・修正・フィードバック方法」のトレーニングが実施されている | H |
| □ | AI導入で業務量が減少・変化する担当者に対し、リスキリング・配置転換の計画が人事部門と連携して準備されている | M |
| □ | AIシステムのダウン時・精度低下時の「人手フォールバック手順（SOP）」が整備・訓練されている | H |
| □ | AI導入後の業務プロセス（As-Is → To-Be）の変更がSAP業務手順書・操作マニュアルに反映される予定がある | M |
| □ | 現場でAIを活用できる「AI推進リーダー（Change Agent）」が各部門に1名以上任命されている | M |
| □ | 経営層・管理職向けにAIの限界・失敗事例・過信リスクについての説明セッションが行われている | M |
| □ | AI導入に関する従業員向けQ&A・懸念事項の収集チャネルが設置されており、定期的に回答・フィードバックがなされている | L |
6.2 SAP Joule × ユーザー教育 チェック
| 確認 | SAP Joule ユーザー教育 | 重要度 |
| □ | Joule の「できること・できないこと」を現場ユーザーが理解しており、過度な信頼（オートメーション・バイアス）が生じていない | H |
| □ | JouleへのプロンプトはSAP標準ガイドラインに沿って設計されており、機密情報（パスワード・個人情報）をプロンプトに含めない運用ルールが徹底されている | H |
| □ | Joule が提示した分析・推奨の根拠（どのSAPデータを参照したか）を担当者が確認できる手順がある | M |
| □ | Joule と他のAIツール（ChatGPT等）を業務で混在利用する場合のガイドライン・禁止事項が明確化されている | M |
第七章：Phase 5 — AI ガバナンス・リスクマネジメントチェック
7.1 AIリスクの分類と制御
SAPに接続したAIエージェントのリスクは「AIモデルリスク（誤判断）」「システムリスク（障害・セキュリティ侵害）」「コンプライアンスリスク（法規制違反）」「運用リスク（ドリフト・劣化）」の4象限に分類されます。各象限の制御機構を事前に設計することが必須です。
| リスク象限 | 代表的リスクシナリオ | SAP環境での影響 | 主な制御手段 |
| AIモデルリスク （誤判断・ハルシネーション） | 需要予測AIが外れ、大量過剰在庫を発注 与信AIが誤判断し、優良顧客の受注をブロック Jouleが誤った会計基準を提示 | MM-IM在庫膨張・FI損失 SD受注機会損失 FI誤仕訳リスク | 人間確認ゲートの必須設置 AI提案に根拠データの添付義務化 閾値超過は必ず人承認 |
| システムリスク （障害・不正アクセス） | BTP AIサービスがダウンしSAP業務が停止 外部AIとの連携APIが侵害され SAPデータが漏洩 | 基幹業務停止 機密データ（原価・与信）流出 | AIサービスのSLA確認（99.9%以上） APIゲートウェイでのレート制限・WAF フォールバック手順の整備 |
| コンプライアンスリスク （法規制・内部統制） | AI自動仕訳が会計基準に違反 個人情報をAIが学習データに使用し GDPR違反 | 決算修正・監査指摘 規制当局からの制裁金 | AI生成伝票のフラグ付与・監査証跡 データ匿名化・Zero Data Retention契約 内部監査によるAI処理の定期レビュー |
| 運用リスク （モデルドリフト・劣化） | 需要パターン変化でAI予測精度が低下 SAP設定変更でAIが参照するCDS Viewが破壊 AIモデルの更新が業務に影響 | 在庫不足・欠品の増加 AIエラーの無検知継続 | 月次精度モニタリングKPI SAPアップグレード前のAIへの影響評価 モデルバージョン管理・ロールバック |
7.2 ガバナンス体制チェック
| 確認 | AIガバナンス体制 | 重要度 |
| □ | AI倫理ポリシー（Responsible AI原則）が社内で策定・承認されており、SAP × AI活用においても適用される | H |
| □ | AIシステムの重大インシデント（誤判断による損害・データ漏洩等）の報告体制・エスカレーション先が明確に定義されている | H |
| □ | AIエージェントが実行できる処理の上限（発注金額の上限・仕訳の種類・承認不要の閾値等）がシステム設定として実装されている | H |
| □ | AIの判断根拠（どのデータを使ったか・なぜその提案か）を事後監査できるExplainability（説明可能性）が確保されている | H |
| □ | AIガバナンスの責任者（AI Risk Owner）とSAP側の責任者（SAP ERP Owner）が連携する定例会議が設定されている | M |
| □ | SAP本番環境でのAI新機能リリースは、変更管理プロセス（CAB / RFC）を経由することが義務化されている | M |
| □ | EU AI Act（2026年以降段階適用）の高リスクAIシステム要件の自社適用範囲について法務・コンプライアンスが確認を完了している | M |
| □ | サードパーティAIベンダー（OpenAI等）のサービス停止・利用規約変更時のコンティンジェンシープランが準備されている | M |
| □ | AI導入後のビジネス影響（良・悪両面）を四半期ごとに経営層へレポートする仕組みが設計されている | L |
第八章：Phase 6 — 本番稼働・KPIモニタリングチェック
8.1 本番稼働前の最終ゲート
| 確認 | 本番稼働前ゲート | 重要度 |
| □ | 本番切替前にUAT（ユーザー受入テスト）でAIの提案精度・誤り率が事前合意した閾値をクリアしている | H |
| □ | AIシステムの障害時にSAP業務が止まらないフォールバック（手動処理への切替）が実際に演習・確認済み | H |
| □ | 本番稼働後の最初の30日間は「AIの提案を表示するが実行は人間」という段階的展開（Shadowing Mode）を採用している | M |
| □ | 本番稼働のロールアウト計画が「パイロット→展開→全社」の段階的アプローチになっており、一気展開ではない | M |
| □ | SAP本番環境でのAIサービスの接続テスト・負荷テストが完了しており、ピーク時の応答性能が確認済み | H |
| □ | AIが使用するSAP権限（RFC Function Module / oData API）が最終本番環境で正しく動作することが確認されている | H |
| □ | 本番稼働後の運用監視体制（AIエラーアラート・BTPモニタリング・SAPシステムログ）が稼働している | H |
8.2 KPI モニタリング設計チェック
AIエージェントの継続的な効果測定には「AI精度KPI」「業務効果KPI」「システム健全性KPI」の3層で指標を設計します。KPIなき導入は「なんとなく使っている」状態に陥り、投資継続の判断もできなくなります。
| KPI層 | 主な指標（例） | SAPでの測定方法 | 評価頻度 |
| AI精度KPI | 予測精度（MAPE / F1スコア） 誤判断率・誤提案率 ハルシネーション発生件数 | IBP分析レポート BTP AI Services ダッシュボード カスタムログ分析 | 週次 / 月次 |
| 業務効果KPI | 工数削減（h/月） エラー件数削減率 処理リードタイム短縮 在庫精度向上 / 欠品率低下 | S/4HANAトランザクション量比較 QM通知件数 MM在庫回転率・サービス率 | 月次 / 四半期 |
| システム健全性KPI | AIサービス稼働率（SLA遵守） BTP Credit消費量vs予算 API応答時間（P95/P99） AIエラー・異常終了件数 | BTP ALM / Cloud Health Monitor BTPコスト管理ダッシュボード API Management監視 | 日次 / 週次 |
| ガバナンスKPI | AI提案を人間が拒否した率 AI生成伝票の事後修正率 監査指摘件数（AI起因） AI関連セキュリティインシデント数 | SAP変更ドキュメント分析 内部監査レポート SM21 / SWI2_FREQ | 月次 / 四半期 |
| 確認 | KPIモニタリング設計 | 重要度 |
| □ | 上記4層のKPIが全て定義され、測定基準・測定方法・評価頻度が合意されている | H |
| □ | KPIが悪化した場合のアクション（AIモデル再学習・パラメータ調整・一時停止）の閾値と手順が定義されている | H |
| □ | AI精度KPIの測定結果が業務担当者にも可視化されており、現場がAI精度を把握できる | M |
| □ | 四半期ごとにAI導入ROIを測定し、投資継続・拡張・縮小の意思決定を行うレビュー会議がある | M |
| □ | AIモデルの精度劣化（ドリフト）を自動検知するアラートが設定されており、閾値を下回ったら通知される | M |
| □ | SAP本番データを用いた定期的なモデル再訓練のスケジュールと承認フローが定義されている | L |
第九章：診断結果 — 重症度マトリクスと次のアクション
9.1 フェーズ別Hスコア集計表
各フェーズのチェックを完了したら、未確認・NGの H（高重要度）項目をカウントして以下の集計表に記入してください。
| フェーズ | H項目数（本書の合計） | NGのH項目数 | フェーズ判定 |
| Phase 0：導入判断（第二章） | 7項目 | 件 | 0=GO / 1-2=CAUTION / 3+=STOP |
| Phase 1：ユースケース選定（第三章） | 4項目 | 件 | 0=GO / 1-2=CAUTION / 3+=STOP |
| Phase 2：アーキテクチャ設計（第四章） | 5項目 | 件 | 0=GO / 1-2=CAUTION / 3+=STOP |
| Phase 3：データ・セキュリティ（第五章） | 6項目 | 件 | 0=GO / 1-2=CAUTION / 3+=STOP |
| Phase 4：変更管理（第六章） | 5項目 | 件 | 0=GO / 1-2=CAUTION / 3+=STOP |
| Phase 5：ガバナンス（第七章） | 4項目 | 件 | 0=GO / 1-2=CAUTION / 3+=STOP |
| Phase 6：本番稼働・KPI（第八章） | 8項目 | 件 | 0=GO / 1-2=CAUTION / 3+=STOP |
| 【全フェーズ合計】 | 39項目 | 件 | 総合Hスコア |
| Hスコア 0〜3：グリーンライト → AIエージェント本格検討フェーズへ進む | Hスコア 4〜7：イエロー → 課題領域を優先解決後に再診断 | Hスコア 8以上：レッドライン → 基盤整備なしのAI導入は高リスク |
9.2 重症度別 推奨アクション
| 総合判定 | Hスコア | 推奨アクション（優先順位順） |
| グリーンライト ★★★ | 0〜3件 | 基盤が整っている。PoC開始を承認し、最初のユースケースでの実証実験に着手 → 90日間のPoC計画を策定し、プロジェクトキックオフを実施 → BTP環境のセットアップと対象モジュールのAI設定を並行して進める |
| イエロー要注意 ⚠ | 4〜7件 | NG項目のH案件を優先対処してから次フェーズへ。焦った導入はリスク大 → NG項目ごとに「課題オーナー・解決期限・解決手段」を定めた課題管理表を作成 → 2〜3ヶ月の基盤整備スプリントを実施後に再診断 → 特に「データ品質」と「変更管理」のNGは軽視しない |
| レッドライン ? | 8件以上 | AI導入の前提条件（SAP標準化・データ品質・ガバナンス体制）が整っていない → まずSAPのClean Core化・マスタデータ整備・組織体制構築を最優先 → AI導入目的の再検討（ROI根拠の再確認）をCIOレベルで行う → 外部専門家（SIパートナー・SAP社）のアセスメントを依頼し客観評価を得る |
9.3 SAP × AI 成熟度ロードマップ
| AI成熟度 4段階ロードマップ（SAP環境） |
|
Level 1：自動化（Automation）— 期間目安：〜6ヶ月 定型業務の自動化。AIによるデータ入力・照合の自動化（FI-AP請求書OCR・MM受発注EDI等） PoC卒業の目安：人手作業を月20h以上削減、エラー率50%以上低下を確認 Level 2：インテリジェント支援（Augmentation）— 期間目安：6ヶ月〜1年 AIが「提案」し人間が「判断・承認」するハイブリッド業務 例：IBP需要予測を参考に人間がMPS確定、aATPのBOP再配分候補をAIが提示 成熟の目安：AIの提案採用率70%以上、人間の否認理由がシステムに記録されている Level 3：自律実行（Autonomous）— 期間目安：1〜2年 AIが特定条件下で自律的に実行。人間は例外・監視に特化 例：閾値以下の発注はAIが自動実行、IBP計画からPPへのFirmed POをAIが自動連携 前提条件：Level 2での信頼実績・ガバナンス体制・監査証跡が揃っていること Level 4：予測型経営（Predictive Enterprise）— 期間目安：2年以上 S/4HANA・IBP・SAC・外部データを統合したAIが経営シナリオを自律生成 経営層は「AI提示シナリオを選択・承認」する意思決定者にシフト 現在2026年時点でLevel 4に到達している製造業は世界でも少数 |
以上