Amazon Web Services ブログ
CFO は次の四半期に SAP AI の成果を求めている – どこから始めるべきか
課題
先月、ヨハネスブルグの製造業企業の CIO と話をしました。彼は私の話を途中でさえぎり、こう言いました。「『AI トランスフォーメーション』という言葉はやめてください。今四半期だけで 40 回は聞きました。6 週間後の取締役会までに実際に導入できることを 1 つだけ教えてください。」
こうした声は彼だけではありません。私が話をするどの SAP リーダーも同じことを言います。「AI が業務を変革するはずだということは分かっている。しかし実際にどこから始めればよいのか、そして投資の正当性を問われる前にどうやって価値を示せばよいのか。」
CFO は測定可能な ROI を求めています。チームは、ブロックされた購買発注の夜間バックログ、キューで滞留している通関申告、タイムゾーンをまたいで積み上がるベンダーからの問い合わせに追われています。彼らに必要なのは戦略資料ではありません。数週間で実装でき、次の取締役会で提示できるユースケースが 1 つあればよいのです。
それこそが、このシリーズでお届けするものです。
各ユースケースには、ビジネス上の背景、測定可能な価値、アーキテクチャ、実装手順が含まれます。理論ではなく、AWS 上の SAP 環境に合わせて応用できる実践的なパターンです。
ご自身の課題に最も近いユースケースを選び、チームと共有して、最初に何を構築したいかをぜひお聞かせください。
本シリーズの内容
今後の投稿では、Agentic AI エージェントが SAP ワークフローを自律的に実行する 7 つのユースケースを紹介します。各投稿では 2 つのユースケースを取り上げ、まずビジネス上の背景と価値を説明し、その後に技術的な実装を詳しく解説します。
シリーズの構成は次のとおりです。
● 本投稿（ブログ 1）: シリーズの紹介、共通アーキテクチャ、そして最初のユースケースである SAP Global Trade Services による貿易申告の自動化
● ブログ 2: サプライヤー納品のリアルタイム監視とサプライチェーン途絶の分析
● ブログ 3: GRC ユーザー権限付与の自動化と SAP 設定の調査
● ブログ 4: ベンダー支払い問い合わせへの対応と基盤モデルによる需要予測
各投稿は、ビジネス上の背景、提供される価値、アーキテクチャ概要、実装ウォークスルーという同じ形式で構成されています。
SAP ワークフロー実行の現状
現在、多くの組織における SAP プロセスは次のような制約のもとで運用されています。
● タイムゾーンへの依存: 購買発注には人によるレビューが必要で、レビュー担当者が不在の間は承認が滞留します。
● データ整合性の課題: 各地域で手作業により入力されたベンダーマスターデータには、時間とともに不整合が蓄積します。
● 反復作業におけるスケールの限界: 大量の請求書を手作業で照合すると、その量に比例してエラー率が高まります。
● 例外処理の遅れ: 失敗した入庫やブロックされたトランザクションは、次に担当者がいる時間帯まで放置されます。
● バッチ処理に依存した意思決定サイクル: 夜間バッチジョブに依存しているため、業務上の意思決定は数時間前のデータに基づいて行われます。
これらの制約は、各処理ステップに人の関与を必要とするアーキテクチャに本質的に備わったものです。Agentic AI を利用すれば、事前定義されたルールに従うのではなく、ライブの SAP データに基づいて推論する、異なる実行モデルを採用できます。
Agentic AI の動作の仕組み
ルールベースの自動化は、事前に定義されたロジック（条件 X を満たしたらアクション Y を実行する）を実行します。この実行モデルは、予測可能で構造化されたシナリオには効果的です。しかし、データ形式が一定でない場合や、事前定義されたルールの範囲外にある状況に応じた判断には、別のアプローチが必要です。
Agentic AI を利用すると、SAP ワークフローに自律的な推論を組み込めます。エージェントは SAP からライブデータを読み取り、現在の状況に基づいて必要なアクションを判断します。そして、手動の承認を待たずにそれらのアクションを自律的に実行します。
エージェントが信頼度のしきい値を下回るシナリオに遭遇した場合は、人のレビュー担当者にエスカレーションします。エスカレーションには、分析したデータとエージェントが推奨するアクションといった完全なコンテキストが含まれます。
たとえば、調達を監視しているエージェントが午前 2 時にブロックされた購買発注を検出したとします。エージェントはベンダーの取引履歴を照会し、支払いブロックをベンダーマスターデータと照合して検証します。その結果に基づいて、ブロックを自動的に解除するか、人によるレビュー用に構造化されたサマリーを作成します。
SAP における Agentic AI のビジネス価値
SAP ランドスケープ全体に Agentic AI エージェントを導入すると、次の 5 つの測定可能なメリットが得られます。
● 継続的な実行: エージェントは SAP と AWS サービスをまたいで 24 時間 365 日稼働し、プロセス実行からタイムゾーンへの依存をなくします。
● 統合されたデータ処理: 構造化データ（SAP テーブル、ERP レコード）と非構造化データ（メール、PDF、契約書）の両方を単一のワークフロー内で扱えます。
● 手作業による介入の削減: これまで人の作業が必要だった定型業務が自動的に実行され、チームの稼働をより複雑な業務に振り向けられます。
● データ品質の向上: 定期的なレビューの時点ではなく、入力の時点で継続的な自動検証によりエラーを特定して対処します。
● リアルタイムの意思決定支援: バッチ処理されたスナップショットではなくライブデータに基づいてアクションを実行するため、業務への迅速な対応を支援します。
共通アーキテクチャ
本シリーズのすべてのユースケースは、一貫したアーキテクチャパターンに従っています。この共通基盤により、後続の各ユースケースは既に理解しているコンポーネントの上に構築されます。
アーキテクチャは 4 つのレイヤーで構成されます。
取り込みレイヤー: ユースケースに応じて、複数のソースからワークフローにデータが入ります。Amazon S3 に保存されたドキュメント（PDF、メール）、SAP BTP からのイベント、またはユーザーからの直接のリクエストです。ドキュメント処理が必要な場合は、Amazon Bedrock または Amazon Textract によって構造化フィールドの抽出が行われます。
オーケストレーションレイヤー: エージェントは Amazon Bedrock AgentCore Runtime 上で実行され、Amazon Bedrock API を介してモデルにアクセスします。AgentCore Identity は、ユーザーがエージェントへのアクセス権を持つことを検証し、Okta、Entra ID、Ping などの ID プロバイダー（IdP）を通じてアウトバウンド認証を行います。AWS Lambda がオーケストレーションロジックを処理し、ナレッジベース（RAG）がドメイン固有の参照データを提供します。AgentCore Observability がエージェントワークフロー全体を監視します。
アクションレイヤー: エージェントは OData API を通じて SAP S/4HANA に接続し、双方向のデータアクセスを行います。検証のためにマスターデータを取得し、結果を SAP に書き戻します。通知は、コンテキストのサマリーと信頼度スコアとともに Amazon SNS 経由で配信されます。ヒューマンインザループのレビュー担当者は、SAP への変更を承認する前に、完全なコンテキスト、リスク評価、推奨アクションを受け取ります。
オブザーバビリティレイヤー: AgentCore Observability がエージェントワークフロー全体を監視します。アクティビティは Amazon CloudWatch に記録され、ログとアクティビティレコードは Amazon DynamoDB に保存されます。API レベルのアクティビティは AWS CloudTrail で追跡されます。
セキュリティアーキテクチャ
このアーキテクチャでは、すべてのレイヤーにセキュリティ制御を実装しています。
● 通信の暗号化: エージェントと SAP 間の通信には HTTPS を使用します。SAP がサポートしている場合は相互 TLS を適用します。
● 最小権限のアクセス: 各エージェントは、固有のツールとアクションに限定された権限を持つ、専用のスコープ付き AWS Identity and Access Management (IAM) ロールで動作します。マルチエージェントワークフローにおいて、昇格された権限がエージェント間で受け渡されることはありません。
● データの暗号化: 機密データ（ベンダーの支払い詳細、ユーザー権限レコード）は、保存時には AWS KMS、転送時には TLS を使用して暗号化されます。
● ヒューマンインザループの制御: 財務記録、コンプライアンス関連データ、または SAP マスターデータを変更するアクションは、実行前に人による確認が必要です。
● 監査証跡: このワークフローにおけるエージェントのアクションは CloudWatch と DynamoDB に記録され、運用監視とコンプライアンスレポートの両方を支援します。
Amazon Bedrock は、お客様のデータを基盤モデルのトレーニングや改善に使用しません。
ユースケース 1: SAP Global Trade Services による貿易申告の自動化
共通アーキテクチャを確認したところで、このセクションでは最初のユースケースを通じてその実践例を紹介します。
ビジネス上の背景
SAP GTS での輸入申告には、サプライヤーのドキュメント（PDF、メール、Excel ファイル）からのデータが必要ですが、これらは形式がまちまちで、時間を問わず届きます。品目コードが欠落していたり、フィールドの内容が曖昧だったりすると、申告を進められません。その結果、次のような事態が発生します。
● SAP GTS での申告エラーにより、手作業によるレビューサイクルが発生する
● 修正が行われる間、貨物が税関で留め置かれる
● 貨物が保留状態にある時間ごとにコストが積み上がる
● 担当者の勤務時間外にドキュメントが届くと処理が遅れる
必要なデータはサプライヤーのドキュメント内に存在します。技術的な課題は、そのデータを抽出し、貿易規制や SAP マスターデータと照合して検証することです。そのうえでエージェントが、手作業なしで継続的に SAP GTS へ書き込みます。
ビジネス価値
貿易申告に Agentic AI エージェントを利用すると、次の 4 つの領域で価値が得られます。
● 処理スピード: 時間帯に関係なく、サプライヤーのドキュメントが届いた時点で申告が処理されます。標準的な RISE with SAP 環境でのテストでは、処理時間が大幅に短縮されました。午前 2 時に受信したドキュメントも、夜間に人が介入することなく、通常は大幅に短い時間で処理できます。
● データの正確性: エージェントは、このワークフローで抽出したフィールドを SAP マスターデータと貿易規制に照らして検証します。検証が完了してから SAP GTS に書き込むため、手入力によるエラーを排除できます。
● コンプライアンスの確保: このワークフロー内のエージェントのすべてのアクションは完全な監査証跡とともに記録されるため、税関からの問い合わせに対して、使用したデータ、その出所、最終判断を下した人物を含む完全な記録で回答できます。
● 業務の継続性: 貿易コンプライアンスの処理が、タイムゾーンをまたぐ担当者の稼働状況に依存しなくなります。エージェントが定型的な処理量を担い、チームは人の判断を必要とする複雑なケースに集中できます。
アーキテクチャ
次の図は、このユースケースのエンドツーエンドのアーキテクチャを示しています。お客様の AWS アカウントには、取り込み、オーケストレーション、オブザーバビリティのコンポーネントが含まれます。SAP の AWS アカウントには、RISE with SAP VPC 内の SAP S/4HANA が含まれます。
このアーキテクチャは 2 つの AWS アカウントにまたがっています。
お客様の AWS アカウント:
● 取り込み（1–2）: ドキュメントが Amazon S3 に格納され、Amazon Bedrock の LLM が構造化フィールドを抽出します。
● オーケストレーション（3–6）: AgentCore Runtime が抽出されたデータを受け取ります。AgentCore Identity（4a）がアクセスを検証し、IdP（4b）を通じてアウトバウンド呼び出しを認証します。AgentCore Observability（5）がワークフローを監視します。AWS Lambda（6）がオーケストレーションロジックを管理します。
● ナレッジと検証（7a–7b）: Lambda は、貿易規制と品目コードについては Amazon Bedrock Knowledge Bases（7a）へ、マスターデータの検証については SAP GTS OData API（7b）へ分岐します。
● エージェントのアクション（8）: AgentCore Runtime 上の AI エージェントが SAP GTS OData API を呼び出し、貿易申告を作成または更新します。
● ヒューマンインザループ（9–10）: 信頼度が不十分な場合、Amazon SNS が人のレビュー担当者に通知を送信します。
● オブザーバビリティ（11）: Amazon CloudWatch、Amazon DynamoDB、AWS CloudTrail がアクション、監査証跡、API アクティビティを記録します。
SAP の AWS アカウント:
● SAP S/4HANA は、Lambda による検証ステップ（7b）と AI エージェントのアクションステップ（8）の両方から OData API 呼び出しを受け取ります。どちらの呼び出しも、RISE with SAP VPC 内のプライベートサブネットから発信されます。
技術的な実装
エージェントは、サプライヤーのドキュメント受信から SAP GTS の貿易申告完了までのワークフロー全体を自動化します。
ステップ 1: ドキュメントの取り込み。 サプライヤーのドキュメント（PDF、メール、Excel ファイル）は、届いた時点で Amazon S3 に保存されます。S3 はエントリーポイントとして機能し、下流のコンポーネントからアクセスできる耐久性の高いストレージを提供します。
ステップ 2: フィールドの抽出。 Amazon Bedrock が大規模言語モデルを使用してドキュメントを処理します。非構造化コンテンツから、品目コード、数量、出荷日、ベンダー情報といった構造化フィールドを抽出します。
ステップ 3: 貿易規制に基づく検証。 エージェントは、貿易規制と品目コードの参照情報を含む Amazon Bedrock Knowledge Bases を照会します。フィールドが不完全または曖昧な場合、エージェントはエスカレーションする前に検索拡張生成（RAG）を使用して解決を試みます。
ステップ 4: SAP マスターデータの検証。 エージェントは SAP GTS OData API を呼び出し、ベンダー ID、品目コード、その他のフィールドが SAP S/4HANA の既存レコードと一致することを確認します。
ステップ 5: 判断と実行。
· 信頼度が十分な場合、エージェントは人の介入なしに OData API を介して申告を SAP GTS に直接書き込みます。
· 信頼度がしきい値を下回る場合、エージェントは人のレビュー担当者にエスカレーションします。コンテキストのサマリーと信頼度スコアを含む通知を Amazon SNS 経由で送信します。
ステップ 6: ログ記録と監査。 Amazon CloudWatch がアクションとレイテンシーのメトリクスを記録します。Amazon DynamoDB は申告ごとに改ざん不可能な監査証跡を保存し、判断内容、ツール呼び出し、検証結果を記録します。
主な成果
このエージェントは、次の 3 つの具体的な成果をもたらします。
● 輸入申告における手作業のデータ入力ゼロ
● タイムゾーンをまたいだ 24 時間 365 日の処理により、夜間のバックログが発生しない
● 通関期限前のプロアクティブな例外処理。人が対応できる時間的余裕があるうちに、エージェントが完全なコンテキストとともにエスカレーションします
次回の予定
次回の投稿では、次の 2 つのユースケースを取り上げる予定です。
1. インテリジェントな供給サービスモニター: サプライヤーの納品スケジュールをリアルタイムで検証し、各納品の SLA 違反リスクをスコアリングして、問題が倉庫の現場に到達する前に、付加価値を加えた情報を SAP に書き戻すエージェント。
2. サプライチェーン途絶分析エージェント: 外部シグナル（気象イベント、地政学的な変化、物流のボトルネック）を SAP 内の有効な購買発注やサプライヤーデータと関連付け、業務に影響が出る前に途絶リスクを特定するエージェント。
始め方とフィードバックのお願い
Amazon Bedrock AgentCore を詳しく知り、SAP 環境向けのエージェント構築を始めるには、ドキュメントをご覧ください: https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore.html
エージェントの実装サンプルについては、GitHub リポジトリをご覧ください: https://github.com/aws-samples/agentic-ai-for-sap
次回の投稿では、供給監視と途絶分析を取り上げる予定です。どの SAP ワークフローの組み合わせがご自身の環境に最も関連があるか、コメントでお知らせください。
● GRC アクセスの自動化 + SAP 設定の調査: 職務分掌チェックを伴うユーザー権限申請の自動化と、自然言語を使った SPRO 階層のナビゲーションおよびサポートされている設定変更の実行。
● ベンダー支払い問い合わせ + 需要予測: ベンダーからの定型的な支払いに関する質問の自律的な解決と、ライブの SAP データに照らして結果を検証する Amazon Chronos による高度な予測。
お客様の業務にとってどのワークフローが最も重要か、ぜひお聞かせください。このページの「Contact us」リンクから、私たちのチームに直接ご連絡いただけます。
本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文はこちらです。