背景 最近の調査（ McKinsey ）によれば、世界中のエンタープライズ ERP システムでは毎月膨大な数の手作業による介入が発生し、波及しています。たとえば、あるグローバル製造企業では、入金された銀行支払いが請求書と何日も突き合わせられないまま残り、キャッシュフローを悪化させ、売掛金（AR）チームが日々数百件の取引を手作業で消し込むことで売上債権回転日数（DSO）が膨らんでいます。ここで、内部統制マネージャーに「AI がこれらの支払いを自動的に消し込み、計上します」と提案する場面を想像してみてください。返ってくる答えは決まって「間違いを起こさないとどうして分かるのか？」です。複雑な業務プロセスを AI に確実に実行させることへの信頼は、今日多くのユーザーが直面している最大の課題のひとつであり続けています。 SAP のスリーウェイマッチのような高度な組み込み自動化でさえ十分とは言えず、請求書の例外、購買発注（PO）の承認ブロック、月次決算、会社間消し込みなど、ほぼあらゆる業界で手作業の介入が横断的に発生しています。これまでの自動化アプローチも同様でした。ロボティック・プロセス・オートメーション（RPA）は UI のクリック操作を自動化しましたが、画面レイアウトが変わると壊れてしまいました。従来型の機械学習（ML）は例外を予測できても、それを解決することはできませんでした。 お客様の IT ランドスケープは、SAP インスタンス、レガシーシステム、クラウドサービス、サードパーティアプリケーションが入り乱れたパッチワークとなり、それぞれが互換性のないプロトコルと分断されたデータを抱え、ますます複雑化しています。SAP は財務報告の検証済みコアとして機能します。したがって、システム横断的な自動化はいずれも、Sarbanes-Oxley 法（SOX）、ISO、内部監査の要件を満たすために、セキュアなアクセス制御、検証済みのユーザー ID、完全な監査証跡を強制する必要があります。 状況を変えたのは、非構造化された手順を推論し、システム境界を越えてツールを呼び出し、複数ステップのワークフローにわたってコンテキストを維持できる基盤モデル（foundation model）の登場です。 これらの例外を大規模に解決するには、 エージェント型標準作業手順書（Agentic Standard Operating Procedures、SOP） が必要です。これは、ナレッジベースからエンタープライズの手順を解釈し、SAP システムと非 SAP システムをまたいで複数ステップの例外を自律的に解決する、単一かつ統合された AI 駆動エージェントです。判断や承認が必要な箇所では、ヒューマン・イン・ザ・ループ（human-in-the-loop）の制御が働きます。 エージェント型 AI は有望な道を示しますが、新たな課題ももたらします。それは、エージェントがガバナンスの追いつかない速さで増殖していくということです。分断されたシステム間でセキュアに連携するエージェントを構築するのは複雑でコストがかかります。「あらゆる問題に対してエージェントを作る」という無制約なアプローチではなく、段階的に成熟し、各段階で価値を提供し、人間の信頼を漸進的に獲得していく、構造化されたフレームワークが必要です。 本稿では、SAP ユースケース向けの AWS Agentic AI Solutions Framework を紹介します。これは、ヒューマン・イン・ザ・ループ制御による漸進的な信頼、SOP 駆動の統合エージェントアーキテクチャ、決定論的で監査可能なアクションのためのガード付き MCP サーバー、ID を意識したセキュリティとコンプライアンス、監査水準のドキュメンテーションのための永続的な状態管理という 5 つのコア機能に基づいて構築された、プロダクショングレードのアプローチです。続いて、Amazon Bedrock AgentCore を用いて SAP 環境に対してこのフレームワークをデプロイするためのリファレンスアーキテクチャと技術的ベストプラクティスを解説します。 コア機能 さまざまな業界や事業部門のお客様と協働する中で、AWS は、エンタープライズ ERP ランドスケープにおいて安全かつ効果的に稼働するためにお客様のエージェント型 AI システムが備えるべきコア機能のセットに収束しました。次のセクションのリファレンスアーキテクチャは、これらの各機能に対応しています。 リスクを抑えながら段階的に信頼を獲得する： エージェントはまずアドバイザリーモードで開始し、すべてのアクションは人間が実行します。信頼が積み上がるにつれて、エージェントは監督付き実行へと移行し、最終的には、信頼度が定義済みのしきい値を超えた場合にのみ独立して動作する自律的な解決へと進みます。自動化は、信頼を確立した分だけ拡大していきます。 すべてのプロセスに 1 つのエージェントをデプロイする： 業務プロセスごとに別々のエージェントを構築する代わりに、単一のエージェントが、キュレーションされたナレッジベースから SOP を動的に解釈・実行し、例外の種類やプロセスのコンテキストに応じて適切なツールを実行時に呼び出します。お客様の業務チームが SOP を自然言語で作成・所有するため、変更にはコードの再デプロイではなく SOP の更新だけで済みます。エージェントは SOP を厳格なルールではなく推論のコンテキストとして扱い、キュレーションされたプロンプト、構造化されたツールオーケストレーション、ガードレールを通じて、あらゆるステップを決定論的かつ監査可能に保ちます。 一貫した再現性のある結果を得る： 同じ入力は、常に同じ出力を生成しなければなりません。大規模言語モデルは本質的に確率的であるため、決定論（モデルがハルシネーションを起こしたり一貫性のない結果を生成したりするのを防ぐこと）を達成するには意図的な制御が必要です。本ソリューションは、制御されたモデルパラメータ、構造化されたプロンプトエンジニアリング、ハルシネーションを防ぐための信頼できる SOP コンテンツとライブシステムデータからの取得、ポリシーとグラウンディング検証のための実行時ガードレール、アクション実行前に推奨事項をクロス検証するマルチエージェントによる相互検証を通じて、これを強制します。 誰が、いつ、何をしたかを正確に把握する： すべてのエージェントのアクションを適切な ID に帰属させなければなりません。エージェントが自律的に動作する場合は自身のサービスアカウントで認証し、人間が介入する場合はシステムがその人間の検証済み ID に切り替えます。この分離により、コンプライアンスチームはエージェントのアクションと人間が承認したアクションを区別できます。あらゆるツールの呼び出し、データの読み取り、アクションは、SOX、ISO、内部監査の要件を満たす改ざん検知可能な証跡とともにログ記録されます。 初日から監査担当者と運用チームを満足させる： 専用の永続的な状態レイヤーが、例外のライフサイクル全体を記録します。エージェントの推論トレース、認証済み ID を伴うツールの呼び出し、人間へのエスカレーションイベント、解決結果を、すべて不変（immutable）で追記専用（append-only）のレコードとして保持します。リアルタイムのオブザーバビリティがエージェントのパフォーマンスを監視し、振る舞いが想定されるベースラインから逸脱した際に運用チームへ通知します。 リファレンスアーキテクチャ 高いレベルで見ると、本アーキテクチャは ERP の例外をスケジュールに従って検知し、AI エージェントを呼び出して該当する SOP を取得し、SAP および接続されたシステム全体で例外を解決し、監査コンプライアンスのためにあらゆるステップをログ記録します。信頼度が低い場合や承認が必要な場合、エージェントは人間へエスカレーションし、返答を受け取ると再開します。 下記の図 1 は、エンドツーエンドのアーキテクチャを示しています。このアーキテクチャには 3 つの境界があります。お客様の SAP 環境、AWS クラウド、そしてオプションのユーザーインターフェイスです。ここでは、単一の例外が検知から解決までシステム内をどのように流れるかを説明します。 例外検知（Exception Detection）： Amazon EventBridge が、設定可能なスケジュール（デフォルト：5 分ごと）で AWS Lambda 関数をトリガーし、SAP OData サービスをポーリングして新しい例外（ブロックされた請求書、突合できない支払い、欠落した引当金、または SOP が定義する任意の例外タイプ）を検出します。 状態の初期化（State Initialization）： ポーラーは、新しい例外ごとに Amazon DynamoDB の状態テーブルへ status を detected として書き込み、解決に必要な最小限のコンテキスト（PO 番号、総勘定元帳（GL）アカウント、コストセンター）を記録します。重複排除チェックにより、同じ例外が二重に処理されるのを防ぎます。 エージェントの呼び出し（Agent Invocation）： システムは、DynamoDB Streams トリガー経由で自律的に、またはユーザーインターフェイスを通じて手動で、エージェントを呼び出します。エージェントは、AI エージェントの構築・デプロイ・スケーリングのためのフルマネージドサービスである Amazon Bedrock AgentCore 上で稼働し、エージェントフレームワークには AWS のオープンソースのエージェント型 SDK である Strands を使用します。 ツール接続（Tool Connectivity）： カスタム統合コードなしにエージェントへ SAP やその他のシステムへのアクセスを与えるため、マネージドな 2 つの経路のいずれかで接続します。 AgentCore Runtime 上でホストされる MCP サーバー（サンプルコードに含まれています） 大規模でマネージド・ガバナンスされたツールアクセスのための AgentCore Gateway SOP の取得（SOP Retrieval）： すべての解決が承認済みのプロセスに従うことを検証するため、エージェントの最初のツール呼び出しは、エンタープライズコンテンツをインデックス化・チャンク化・取得するフルマネージドの RAG 機能である Amazon Bedrock Knowledge Base から該当する SOP を取得し、処理対象の例外タイプに対する意思決定ツリーを確立します。 SAP の実行（SAP Execution）： ハードコードされた API マッピングを排除し、保守負担を軽減するため、エージェントは SAP OData API 仕様 を含む 2 つ目の Knowledge Base を使用して、正しいエンドポイントとフィールドを実行時に発見し、SAP に対して読み取り・書き込み操作を実行します。これにより、ハルシネーションによる API 呼び出しを防ぎます。エージェントは、ドキュメント内に見つけられるエンドポイントのみを呼び出します。 監査証跡（Audit Trail）： 各ステップで、エージェントは DynamoDB 内の不変な processing_history リストに追記し、以下を記録します。 推論トレース： ステップごとのロジックと取得した SOP のセクション ツールの呼び出し： 入力、出力、タイムスタンプ、認証済み ID 解決結果： 実行された最終アクションと SAP のトランザクション参照 この追記専用ログ（レコードは追加できるが、変更・削除は決してできない）が、SOX と内部監査コンプライアンスのための改ざん検知可能な監査証跡となります。 人間へのエスカレーション（Human Escalation）： 例外が人間の判断を要する場合（金額が重要性のしきい値を超える、またはエージェントの信頼度が定義済みのレベルを下回る場合）、エージェントは Amazon SES 経由で構造化されたエスカレーションメールを送信し、ケースのステータスを awaiting_human_input に更新して停止します。 人間の応答（Human Response）： 人間が返信すると、SES はそのメールを Amazon S3 に保存し、これが Lambda 関数をトリガーします。この関数はメールスレッド全体を解析し、その応答とともにエージェントを再呼び出しします。エージェントは、完全なコンテキストの連続性を保ったまま、中断したところから正確に処理を再開します。 インターフェイスレイヤー（Interface Layer）： ユーザーインターフェイスは意図的に薄く、差し替え可能です。サンプルコードには Streamlit ダッシュボードが同梱されていますが、AgentCore ランタイムのエンドポイントを呼び出せるクライアントであれば何でも動作します。 React またはカスタム Web アプリ ネイティブな SAP 統合のための SAP Fiori タイル Amazon Quick Apps ：ガバナンスされたノーコードの承認体験のため インターフェイスをまったく持たない ：完全に自律的な運用のため 例：購買発注の引当計上を大規模に自動化する。あるグローバル製造企業は、このフレームワークを適用して、1,000 件を超えるアクティブな PO にまたがる 2 億 5,000 万ドル超のカスタム治工具の購買を管理しました。エージェントは該当する SOP を自律的に取得し、各 PO を適切なワークフローで解決し、財務承認のための仮伝票（parked journal entry）を SAP に作成します。以前は 1 決算サイクルあたり 30 日超の手作業を要していたプロセスが、今では PO あたり数分で完了します。 技術的ベストプラクティス デモで動作するエージェント型システムを作るのは簡単です。プロダクショングレードの信頼性、監査可能性、コスト効率には、意図的なエンジニアリング上の選択が求められます。以下のプラクティスは、プロダクション環境でのデプロイから得られたもので、最も一般的なギャップに対処します。 決定論（Determinism） 同じ入力は、同じ出力を生成しなければなりません。これは、単一のメカニズムではなく、階層化された制御によって達成します。 構造化されたプロンプト： 明示的なテンプレート、システムレベルのルール、振る舞いのフック、出力フォーマットの制約を用いて、推論を定義済みのパターンに固定します。 検索拡張生成（RAG）： Amazon Bedrock Knowledge Bases を介して、あらゆる応答を取得した SOP コンテンツとライブシステムデータにグラウンディングし、エージェントがパラメトリックな記憶ではなく信頼できる情報源から推論するようにします。 実行時ガードレール： コンテキストのグラウンディング検証とポリシーベースのコンテンツフィルタリングのために Amazon Bedrock Guardrails を適用します。 マルチエージェントによる相互検証： リスクが高い場合は、スーパーバイザーエージェントを用いて専門のサブエージェントをオーケストレーションし、アクション実行前に推奨事項をクロス検証します。 ID の伝播（Identity Propagation） すべてのエージェントのアクションを適切な ID に帰属させなければなりません。本アーキテクチャは、デュアル ID モデルをサポートします。 自律運用： エージェントは OAuth 2.0 の 2 レッグ（2LO）認証により自身のサービスアカウントで認証し、各ダウンストリームシステムとのマシン間の信頼関係を確立します。 ヒューマン・イン・ザ・ループ運用： AgentCore Identity が OAuth 2.0 の 3 レッグ（3LO）認証へ移行し、人間の検証済み ID をエージェントを通じて対象システムへ伝播します。 この分離により、コンプライアンスチームは監査ログにおいてエージェントが起動したアクションと人間が承認したアクションを明確に区別できます。これは SOX 統制の中核的な要件です。 Cedar ポリシーによるきめ細かな認可 誰が動作しているかを把握することは必要ですが、それだけでは十分ではありません。各 ID が何をできるかも制御する必要があります。 AgentCore Policy は、AWS のオープンソースの認可言語である Cedar を使用し、AgentCore Gateway を経由するすべてのエージェント-ツール間のやり取りに対してきめ細かな権限を強制します。Cedar ポリシーは 4 つの属性を評価します。 プリンシパル ID： ユーザー名、ロール、スコープなどの OAuth クレーム（上記の 2LO/3LO ID モデルから） アクション： 呼び出される具体的なツール（例：invoke_sap_odata_service や send_email） リソース： リクエストがルーティングされる Gateway リクエストコンテキスト： ツールの入力パラメータ。属性ベースのアクセス制御を可能にします（例：書き込み操作を一定の金額しきい値未満の請求書に制限する） システムはデフォルトですべてのアクションを拒否します。ポリシーは Cedar 構文または自然言語で作成します。AgentCore Policy は平易な英語のルールを解釈して候補となる Cedar ポリシーを生成し、自動推論を用いて、強制する前に過度に許容的または制限的なポリシーを検出します。たとえば、「エージェントは任意の PO を読み取ってよいが、仕訳を計上できるのは 50,000 ドル未満に限る」といったルールを、ツール呼び出しが SAP に到達する前に、Gateway レイヤーで決定論的に強制できます。よくあるパターンについては、 AgentCore Policy のドキュメントをご覧ください。 プロンプトの改善（Prompt Improvement） システムプロンプトは、決定論が始まる場所です。特に重要なのは 3 つのパターンです。 明示的なコンプライアンスのフレーミング： 明示的な優先度シグナル（すべて大文字のラベル、必須を示す表現）を用いて、SOP コンプライアンスを交渉の余地のないものとしてフレーミングします。これにより、モデルが手順に違反する形でワークフローを「最適化」してしまう可能性を減らします。 ハルシネーション防止のガードレール： 人間の入力を待ってブロックされている際に、証拠や承認をでっち上げるのではなく、停止してエスカレーションするようエージェントに指示します。これは、エージェント型システムで最も危険な失敗モードのひとつに直接対処します。 実例（Exemplars）： 正しい振る舞いの具体例、日付計算のフォーマット、エスカレーションメールのテンプレート、OData クエリのパターンなどを、プロンプト内に直接含めます。エージェントは、ゼロから生成するよりも参照実装がある方が高いパフォーマンスを発揮します。 実際の例外データを用いてプロンプトを反復改善し、バージョン間で出力品質を追跡します。 評価（Evaluations） エージェント型システムには、複数のレベルでの評価が必要です。 ユニットレベル： 個々のツール呼び出しの正しさをテストします。OData クエリは期待どおりのフィールドを返すか？ メールには適切なコンテキストが含まれているか？ エンドツーエンド： 期待される結果を伴う既知の例外シナリオに対して、ワークフロー全体をテストします。解決済みのケースからリグレッションスイートを構築し、プロンプトや SOP の変更が既存の振る舞いを劣化させないようにします。 運用メトリクス： ビジネスにとって重要な指標を追跡します。解決精度、エスカレーション率、解決までの時間、誤検知率などです。 リアルタイム監視： AgentCore 向けの Amazon CloudWatch の生成 AI オブザーバビリティ機能を使用して、モデル呼び出しのレイテンシ、トークン消費量、ツール呼び出しの成功率、信頼度スコアの分布を監視します。 コスト最適化（Cost Optimization） スケールしても例外あたりのコストを予測可能に保つために： モデルを適切なサイズにする： 定型的な例外には小さいモデルを使い、大きいモデルは複雑なケースのために温存します。 頻繁に取得するコンテンツをキャッシュする： めったに変わらない SOP ドキュメントや API ドキュメントはキャッシュして、Knowledge Base のクエリ量を削減できます。 インテリジェントなプロンプトルーティング： Amazon Bedrock のプロンプトルーティング を使用して、呼び出しごとに最もコスト効率の高いモデルを自動的に選択します。 運用のレジリエンス： ピーク時のボリュームではジッター付きの指数バックオフを実装し、コストの可視化のために例外タイプ別にトークン消費量を追跡します。 オブザーバビリティと状態管理 運用チームと監査担当者の双方を満足させるため、プロダクションのエージェント型システムには 3 つのレイヤーの状態が必要です。 短期セッションメモリ： 単一の解決内でのコンテキスト（会話履歴、ツール呼び出しの結果、中間的な推論）を維持します。 長期メモリ： AgentCore Memory を介して、セッションをまたいで学習したパターンを永続化します。たとえば、既知の PO フォーマットの問題により一貫して例外を発生させるベンダーを認識するなどです。 永続的な監査水準の状態： DynamoDB 内で、例外のライフサイクル全体を不変で追記専用のレコードとして記録します。推論トレース、認証済み ID を伴うツールの呼び出し、エスカレーションイベント、人間の意思決定、解決結果です。 まとめと次のアクション エージェント型 AI は、ERP の例外管理の経済性を根本的に作り変えます。プロセスごとに個別のエージェントを構築・保守する代わりに、組織は、実行時に手順を解釈し、適切なツールを呼び出し、状況が求めるときに人間の判断へエスカレーションできる、単一の SOP 駆動エージェントをデプロイできます。漸進的な導入フレームワークは、自動化が信頼を確立した分だけ拡大することを検証し、ID を意識したアーキテクチャは、エージェントが起動したものであれ人間が承認したものであれ、あらゆるアクションを完全に帰属・監査できることを保証します。 リファレンス実装は、Strands エージェント、SAP OData 統合を備えた MCP サーバー、DynamoDB による状態管理、ヒューマン・イン・ザ・ループのワークフローを含むオープンソースのサンプルコードとして利用可能です。可視化のための Streamlit ダッシュボードも同梱されています。Knowledge Base 内の SOP を更新するだけで、コードを変更することなく、お客様の例外タイプに合わせて適応できます。 まずは、 GitHub リポジトリの ERP 例外管理ソリューション をダウンロードし、SAP OData 統合のための AWS for SAP MCP Server をセットアップしてください。 本稿で参照したサービスをより深く知るには、Amazon Bedrock AgentCore 、 Amazon Bedrock Knowledge Bases 、 Strands Agents SDK をご覧ください。 著者について Sagar は、AWS でエージェント型 AI と生成 AI を活用して業務プロセスを自動化し、レガシーシステムをモダナイズすることで、エンタープライズのデジタルトランスフォーメーションを支援することを専門としています。SAP ワークロードに注力し、お客様が AI を用いて移行・モダナイゼーション・自動化を進めるためのツールとソリューションを構築しています。仕事以外では、テクノロジーへの情熱と、家族と過ごすかけがえのない時間、Formula 1 への深い愛、そして Sachin Tendulkar のクリケットの功績への変わらぬ敬意とのバランスを取っています。 Zach Daniels は、AWS のソリューションアーキテクトで、AWS for SAP を専門とし、ERP 向けのエージェント型 AI アプリケーションに注力しています。お客様と協働して、スケーラブルで Well-Architected な SAP 環境を AWS 上で設計しています。シアトルを拠点とし、スタートアップと技術エンジニアリングでの経験をエンタープライズのお客様との仕事に活かしています。 Abhijeet は、複数の業界にまたがって戦略とデリバリーを主導してきた、20 年以上の SAP テクノファンクショナル経験を持つデータ・AI リーダーです。AWS の SAP データアナリティクス戦略、エージェント型コードモダナイゼーション、AI 駆動のプロセス自動化イニシアチブを牽引しています。コロラドの山でのハイキングとスキーを楽しんでいます。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

本記事は、Accenture の AABG Global Innovation Lead である Amanda Jensen 氏、および Accenture の AABG Lead GenAI Architect である Mike Earley 氏による、AWS との協業に基づくゲスト投稿です。 エグゼクティブサマリーと要点 ある大手企業は、Accenture と協業し、AWS 上にエージェント型 AI（agentic AI）ソリューションを展開することで、Direct Ship（直送）請求業務の変革を実現しました。このソリューションは、手作業による例外処理を、リアルタイムで AI 主導のインサイトとガイダンスに置き換えるものです。その結果、展開からわずか 5 週間で、業務上の摩擦を軽減し、課題解決を加速し、売上の実現（revenue realization）を向上させる、迅速かつビジネス主導の変革がもたらされました。要点は以下のとおりです。 ビジネス成果に整合し、スケーラブルなクラウドインフラストラクチャによって支えられたとき、AI は数か月で測定可能なインパクトをもたらすことができます。これは、企業の再創造（reinvention）に向けた実践的な道筋を示すものです。 エージェント型 AI は、業務を事後対応型の例外管理から、プロアクティブでインサイト主導の意思決定へと転換し、価値の高い案件のより迅速な解決を可能にします。 ナレッジの一元化と対話型インターフェイスは、生産性を高め、専門知識をスケールさせ、手作業のプロセスへの依存を減らして、経験豊富なスタッフの負担を軽減します。 はじめに 大量のトランザクションを扱う企業にとって、エンタープライズリソースプランニング（ERP）システムにおける手作業の例外処理は、重要なビジネスプロセスを遅延させ、最終的にはお客様満足度と収益認識（revenue recognition）に影響を及ぼすボトルネックを生み出します。こうした複雑なビジネスプロセス業務を大規模に管理することは、重大な運用上の課題をもたらします。ERP の例外管理に対する従来型のアプローチでは、絶えず増大するビジネス要求に追いつくことができず、企業には、AI エージェントが自律的に推論し、意思決定を行い、行動できるような、AI 主導のアプローチによって卓越した業務運営を実現することが求められています。本記事では、Accenture が AWS のサービスを用いて、ERP のビジネスプロセス例外管理を変革するエージェント型 AI ソリューションをどのように構築したかをご紹介します。 ERP 業務における課題 Direct Ship（直送）業務は、大企業にとって特有の複雑さを伴います。成熟した ERP ランドスケープにおいてさえ、注文量、プロセス構成の深さ、そして例外シナリオの数の多さから、運用チームが請求上の問題を効率的に特定し、トリアージし、解決することは困難です。 ワークフローが ERP を越えて、インシデント管理、物流、コンプライアンスの各システムにまで広がると、課題はさらに複雑になります。これらの領域では、インターフェイスの障害、データの不整合、引き継ぎ時のギャップが頻繁に発生します。プロセスに関するナレッジは経験豊富なチームメンバーに集中しがちであり、標準作業手順書（SOP）が複数のドキュメントにまたがることも多く、オンボーディングの難しさや解決までの時間の長さを招いています。 海外向けの注文は、通関書類、国ごとの税および関税のルール、付加価値税（VAT）コンプライアンス、通貨の取り扱い、輸出規制などにより、さらに複雑さを増します。その結果として、請求の遅延、収益のギャップ、コンプライアンスリスクが生じます。 エージェント型 AI ソリューション これらの課題に対処するため、Accenture は Amazon Bedrock や Bedrock AgentCore といった AWS サービスを用いてエージェント型 AI ソリューションを開発し、ERP の例外管理を、手作業で労力を要する業務から、自律的でエージェント主導の解決へと転換しました。このソリューションは、オペレーターの体験を変革するために連携して機能する 2 つの主要コンポーネント、すなわち Digital Assistant と、エンタープライズシステムとの統合機能で構成されています。Digital Assistant は、SOP、ジョブエイド、組織内のナレッジを単一のアクセス可能なシステムに一元化する対話型 AI インターフェイスとして機能し、チームメンバーが自然言語で質問し、複雑なシナリオを解決するための文脈に沿ったガイダンスを受け取れるようにします。これは、Direct Ship プロセスに関する深いナレッジを備えた AI 搭載のアシスタントであり、解決策を推奨し、SAP データへのリアルタイムアクセスを提供することで、複数のシステムを行き来する必要性を排除します。エージェントは文脈を処理し、会話履歴を保持し、実行可能なインサイトを提供します。このソリューションは、SAP S/4HANA や認証用の Okta を含む既存のエンタープライズシステムと統合されており、AI エージェントがエンタープライズのセキュリティ基準を維持しながら、リアルタイムの運用データにアクセスできるようになっています。 ソリューションアーキテクチャ 本ソリューションは、6 つの AWS サービスを組み合わせており、それぞれがエンタープライズのセキュリティとスケーラビリティを備えた AI 機能を提供するうえで特定の役割を担うように選定されています。 以下では、これらのサービスが実際にどのように連携して機能するかを説明します。（1）チームメンバーが、請求の例外について Digital Assistant に自然言語で質問します。（2）Strands Agents SDK がリクエストを評価し、どのツールを呼び出すかを判断して、解決ワークフローをオーケストレーションします。（3）AWS Lambda が SAP S/4HANA に安全に接続し、リアルタイムの注文、請求、出荷のデータを取得します。（4）Amazon RDS が、事前にロードされた例外レポートへの高速なアクセスを提供し、エージェントがパターンを相互参照して根本原因を特定できるようにします。（5）Amazon Bedrock AgentCore が、複数ターンにわたるやり取りの会話コンテキストを保持することで、エージェントが以前の質問を記憶します。（6）エージェントがすべてのデータソースを統合し、具体的な解決手順とともに優先順位付けされた推奨事項を返します。 Amazon Bedrock ：単一の API を通じて、主要な AI 企業が提供する高性能な基盤モデルへのアクセスを提供します。本ソリューションでは、Bedrock が Digital Assistant の能力を支え、複雑な請求シナリオの理解、SOP の解釈、文脈に沿った推奨事項の生成を可能にします。 Strands Agents SDK ：エージェントを LLM、ツール、およびネイティブな AWS サービスとシームレスに統合し、基盤モデルの推論能力を用いて、入力の評価、次のステップの判断、ツールの自律的な選択を可能にします。これにより、ハードコードされた意思決定ツリーが不要になり、エージェントが新しいタイプの例外にも対応できるようになります。 Amazon Bedrock AgentCore ：複雑なメモリインフラストラクチャなしに、短期的なワーキングメモリのコンテキストを管理します。これにより、エージェントがセッションの前半で議論した内容を記憶する、自然な複数ターンの会話が可能になります。gateway、runtime、observability といった AgentCore の追加機能により、本ソリューションは将来的に数百の AI エージェントへとスケールできます。 AWS Lambda ：SAP S/4HANA を含むエンタープライズシステムに安全にアクセスするための、サーバーレスなゲートウェイとして機能します。Lambda のイベント駆動型アーキテクチャにより、アイドル時のコストが発生しない一方で、エージェントのクエリに低レイテンシーで応答できます。 Amazon RDS ：事前処理された SAP S/4HANA のレポートデータを保存し、例外の特定やステータス更新のための高速なクエリをサポートします。この分離により、SAP システムの負荷を低く保ちながら、エージェントに運用データへのサブ秒単位のアクセスを提供します。 AWS Step Functions ：データソースからのレポートデータのロードワークフローをオーケストレーションし、エージェントのクエリに対してデータが最新かつ利用可能な状態であることを保証します。組み込みのリトライロジックと視覚的なワークフロー監視により、カスタムのオーケストレーションコードなしで信頼性を提供します。 メリットとビジネス成果 Accenture は AWS との協業により、5 週間で稼働するソリューションを提供し、テクノロジーと SAP のビジネスプロセスにおける実証済みの専門性を示しました。このソリューションは、反復的な管理作業を最小化し、例外管理における手作業の労力を削減しました。エージェントが SAP データへの即時アクセスを提供し、複数のシステムを行き来して切り替える必要性を排除したためです。推奨されるアクションにより、運用チームは請求の例外を事後対応ではなくプロアクティブに処理できるようになり、価値の高い注文が即座に対応され、収益の遅延が削減されます。新しいチームメンバーは、対話的なやり取りを通じて組織内のナレッジに即座にアクセスでき、Digital Assistant が定型的な質問における経験豊富なスタッフへの依存を減らすことで、シニアなチームメンバーが複雑なシナリオに集中できるようになります。SOP やトラブルシューティングガイドは、一元化されたナレッジベースを通じて常に最新かつアクセス可能な状態に保たれ、組織全体で一貫したプロセス実行を維持するのに役立ちます。 企業は、Accenture が AWS サービスを用いて構築したエージェント型 AI ソリューションを通じて、自社のビジネスプロセス業務を変革できます。このソリューションは、明確な目標を、クラウドネイティブな AI 機能や、実証済みの ERP ドメイン専門性を持つパートナーと組み合わせたとき、AI 主導のプロセス変革が、数年ではなく数週間で測定可能なビジネス価値をもたらせることを実証しています。企業が ERP 業務の簡素化と自動化を進め続ける中で、エージェント型 AI は、運用チームを強化しビジネス成果を推進するための効果的なアプローチとなります。今後を見据えると、同じアーキテクチャパターンは、調達、在庫管理、その他の SAP モジュールにも拡張できます。 AWS SAP スペシャリストチーム または Accenture AWS Business Group にお問い合わせいただき、SAP 向けのエージェント型 AI ワークショップを予約して、ERP 管理のモダナイゼーションとビジネス成果の向上に向けた方法をぜひご検討ください。また、 AWS GitHub リポジトリ にある、すべての Bedrock AgentCore サービス向けのすぐに使えるコードサンプルを活用して、開発を素早く開始することもできます。 Accenture AWS パートナースポットライト Accenture は、AWS への移行と AWS 上での運用管理に向けたエンドツーエンドのソリューションを提供する、AWS Premier Tier Services Partner および MSP です。Accenture と AWS の戦略的な協業体制である Accenture AWS Business Group（AABG）と協働することで、差別化された製品やサービスを提供するためのイノベーションのペースを加速できます。 AWS SAP スペシャリストチームにお問い合わせ | Accenture にお問い合わせ <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに 本記事は、2026年3月10日に開催された Elastic{ON} Tokyo での発表「 『定型』を許さない製造業データへの挑戦 」の内容をもとにした連載の第2回です。 第1回：ビジュアル情報を活かす 第2回（本記事）：分断されたデータを繋ぐ 第3回：止めずに進化させる 前回は、製造業の検索に「ビジュアル」が外せないこと、Elasticsearch の kNN 検索を使った類似図面検索について書きました。 今回は、次に立ちはだかる「データ規模と結合」の壁について掘り下げます。複数のデータソースを横断した検索を、どうやって高速に実現しているかという話です。 「探索」に必要なデータ横断 前回も触れた通り、私たちが実現したいのは「探索」です。たとえば調達部門が「より良い発注」を目指す場合、こういうプロセスを一気通貫で回したい。 発注予定の図面に対して、視覚的に似た過去の図面を検索する 見つかった図面に紐づく発注実績をシステム横断で確認する 集まった情報をもとに今回の発注額を適正化する この②「システム横断での実績確認」が、技術的にはかなり重い問題を含んでいます。 製造業データの「分断」 製造業の現場には、PLM、EDI、SCM、CRM といった業務ドメインごとのシステムが並んでいます。それぞれの業務には最適化されていますが、システム間でデータが分断されているのが常です。 この分断を解決するために ERP が導入されてきました。ただ、ERP はあくまで組織の「管理」が目的のシステムです。前回書いた「ビジュアルな情報をビジュアルなまま扱う」という発想にはなっていないので、ERP に実績データが集まっても、現場が判断の拠り所にする「モノの形」とは切り離されたまま。分断は形を変えて残り続けます。 CADDi Drawer は、こうしたバラバラのデータソースを統合し、一つの画面から横断的に探索できるようにするプロダクトです。 データ規模と「結合」の壁 日本の製造業は数十年、時には100年を超える歴史があり、蓄積されたデータは膨大です。図面だけで100万枚以上、受発注実績は1,000万レコード以上。仕様書やトラブル記録などの非定型な文書も含めるとさらに増えます。 これらを統合して扱うとき、RDB のようにテーブルを繋ぎ合わせる素朴な結合をやると、組み合わせは10兆件規模に達します。インデックスがなければ全件走査になるので、対話的な速度は到底出ません。 では、図面と実績をデータ種別ごとに別のインデックスに入れればいいかというと、それだけでは不十分です。片方のインデックスで検索した結果をもう片方と突き合わせる必要があり、突き合わせ側はインデックスが効かず全件走査に落ちるケースが出てきます。クエリの絞り込みが弱い場合や結合キーの値の種類が少なく多対多の組み合わせが膨らむ場合、この突き合わせのコストが支配的になって応答速度が崩れます。 この10兆通りの組み合わせを、検索エンジンが得意な形にどう落とし込むか。ここがアーキテクチャ上の大きな問題でした。 複数インデックス構造による解決 私たちがとったのは、複数のデータソースを統合したうえで、用途別のインデックス群を構築するアプローチです。 万能なインデックスは作れない 私たちも最初は「すべての要件を満たすインデックスをどう設計するか」と考えていましたが、うまくいきませんでした。 データソースごとにインデックスを分けると、前述の通りクエリ時の突き合わせで全件走査が走って遅いという課題があります。その一方で非正規化して複合インデックスにまとめれば検索は速くなりますが、あるデータソースの1レコードを変えただけで紐づく全ドキュメントに波及して大量更新が走る。検索を速くすると更新が重くなるし、その逆もまた然りで、一つのインデックスでは両立しません。 なので発想を変えて、万能なインデックスを作ろうとするのをやめました。代わりに要件を分解して、用途ごとに別のインデックスを持たせています。例えば、データソースごとにオンライン更新が走るインデックスと、データ鮮度には多少の遅延があるもののデータソースを横断して検索できるインデックスを分けて持つ、といった具合です。 動的なインデックス選択 ここで鍵になるのが、クエリ実行時の制御層です。ユーザーから投げられたクエリの内容をシステムが解析し、そのとき最も効率的なインデックスを自動で選択します。 単一データソース内の検索ならそのデータソースのインデックスを使い、複数データソースにまたがる検索なら横断用のインデックスを使う。こうした切り替えが裏側で動いています。 ユーザーから見ると、データがどこにあるか、どのインデックスが使われているかは一切見えません。透過的な検索体験を維持したまま、裏では用途に応じた最適化が走っている、という構成です。 類似検索 × フィルタリングの両立 データソース横断検索の難しさは、「類似検索」と「フィルタリング」を組み合わせたときに顕著になります。 そして現場では、この掛け合わせがないと使い物になりません。「この図面に似た形のもの」を探すだけでなく、「その中で、今取引のある会社に発注したことがあるものだけ」に瞬時に絞り込めなければ、実際の比較検討には使えないからです。 なぜ難しいのか 類似検索（kNN）はベクトル空間上の距離計算、フィルタリングは転置インデックスによる構造化データの絞り込みで、それぞれ背後のデータ構造もアルゴリズムも違います。素朴に組み合わせると、どちらかの速度が犠牲になります。 さらに、フィルタリング対象のデータが別のデータソースに由来する場合（発注実績は ERP、図面はファイルサーバーなど）、結合処理のコストも乗ってきます。 どう解決したか kNN 検索とフィルター条件を同一クエリ内で組み合わせることで、ベクトル検索の結果に対して構造化データの絞り込みをかけています。 加えて、前述の横断検索用インデックスで図面と実績の関連を事前に非正規化しているため、検索時のデータソース間結合は発生しません。 Elasticsearch が kNN とフィルタを同一クエリ内で同時実行できることと、事前結合による非正規化インデックスの組み合わせで、類似検索とデータソース横断のフィルタリングをサブセカンドで安定して返せるようになりました。 アーキテクチャの全体像 データが取り込まれてからユーザーに届くまでの流れを整理します。 PLM、ERP、ファイルサーバーなど複数のデータソースからデータを収集する AI による図面解析、メタデータの抽出、ベクトル化などの処理を行う 用途別のインデックスにデータを振り分ける ユーザーのクエリを解析し、最適なインデックスを動的に選択する サブセカンドで結果を返し、ファセットやハイライトとともに表示する 図面と実績は更新頻度も構造も違うデータですが、探索に最適な形に統合・変換してインデックスし続けることで、ユーザーはデータの所在を意識せずにあらゆる情報を横断できます。 まとめ 製造業のデータを素朴に結合すると10兆件規模の組み合わせになる。これをどう捌くかが今回のテーマでした。 私たちの答えは、用途別に最適化した複数のインデックスと、クエリに応じてそれらを動的に選択する制御層です。特に、非正規化による事前結合で検索時の結合コストをなくしたことと、Elasticsearch が kNN とフィルターをネイティブに統合できることが、類似検索とフィルタリングの両立を可能にしています。 ただ、ここまで作り込んだインデックス構造も、現場の変化に追従できなければ意味がありません。次回の最終回では、このインデックスを「サービスを止めずに進化させ続ける」ための仕組みについて書きます。