製造業のお客様を支援しているソリューションアーキテクトの西田です。 2026 年 10 月 26 日に AWS 麻布台ヒルズオフィスにて「製造業 生成 AI 基盤・活用推進 ラウンドテーブル」を開催しました。本記事ではイベントの概要と当日の様子をお伝えします。 ▲ 会場の様子 開催の背景 製造業のお客様の生成 AI の使い方は、一部の部門で試して効果を確かめる段階から、AI エージェントを基幹業務に組み込み、全社で使える基盤として整える段階に進んできました。この段階では、利用者ごとの権限をどう扱うか、社内のデータをどう整えるか、増えていく AI エージェントの品質とコストをどう管理するかという課題に、どの企業も向き合うことになります。 こうした課題は、サービスの機能だけでは解決せず、各社が自社の組織やデータの状況に合わせて判断を重ねる必要があります。同じ段階にいる企業同士が、判断の根拠や試した結果を率直に交換できる場があれば、各社の検討が早く進むと考え、2026 年 3 月に大阪で開催した 生成 AI ラウンドテーブル に続いて、AI エージェントを全社で使うための基盤づくりをテーマに、製造業のお客様 7 社にお集まりいただきました。 イベント概要 開催日： 2026 年 10 月 26 日（月）13:00 〜 18:10 + 懇親会 会場： AWS 麻布台ヒルズオフィス 形式： クローズド・ラウンドテーブル形式（各社発表 + 質疑応答） 参加者数： 20 名 参加企業（発表順）： 三菱重工業株式会社 ブラザー工業株式会社 株式会社ミスミグループ本社 パナソニック インダストリー株式会社、パナソニック エナジー株式会社 キユーピー株式会社、キユーピーデジタルイノベーション株式会社 株式会社村田製作所 株式会社リコー 各社 30 分の持ち時間で、自社の取り組みと課題を共有し、質疑応答で他社の経験を聞く形式です。 各社の発表テーマ 各社の発表タイトルとご登壇者、取り組みの概要をご紹介します。 権限が増えるほど検索できない？ 〜全社 RAG で遭遇した権限フィルタの制約と分割検索の実践〜 ／ AI 駆動開発の拠点展開とプロトタイプ開発の実践 三菱重工業株式会社 デジタルイノベーション本部 システムインテグレーション部 石田 裕亮 氏、岩渕 宏樹 氏 全社の社内情報検索（RAG）で利用者の閲覧権限を反映させる仕組みの工夫と、各拠点の開発者が担当案件を題材に進める AI 駆動開発のワークショップが紹介されました。 ▲ 三菱重工業株式会社 石田 裕亮 氏、岩渕 宏樹 氏 一つの生成 AI 事例を全社の資産に変える 〜エージェンティック RAG 開発から始まる AI プラットフォーム構想〜 ブラザー工業株式会社 システムプロセス開発部 坂野 雄治 氏、脇本 拓歩 氏、渡邉 航平 氏 技術者の知識に頼ってきたサポート業務に AI エージェントを適用した事例と、その効果を全社に広げる AI プラットフォーム構想が紹介されました。 ▲ ブラザー工業株式会社 脇本 拓歩 氏、渡邉 航平 氏、坂野 雄治 氏 デジタル技術を活用したサービスデスク改善 〜問合せ削減への取り組みについて〜 株式会社ミスミグループ本社 DX プラットフォーム・ハブ グローバル統括 データ分析室 吉田 哲史 氏 株式会社ミスミグループ本社 DX プラットフォーム・ハブ 基幹システム統括 Digital Platform 室 清野 博之 氏 社内サービスデスクの問い合わせを段階的に減らしてきた経緯と、調査と一次回答を AI エージェントが担う仕組みを作っている現在の取り組みが紹介されました。 ▲ 株式会社ミスミグループ本社 吉田 哲史 氏、清野 博之 氏 「名もなき業務」を減らす Agentic BPR とエージェンティックワークフロープラットフォーム パナソニック インダストリー株式会社 DX 戦略センター DX アーキテクチャ構築部 データドリブン基盤課 西村 佳 氏 様々な業務で行われる転記・照合などの細々した「名もなき業務」を全社横断で束ね、AI エージェントが実行するワークフローにして自動化する取り組みが紹介されました。 ▲ パナソニック インダストリー株式会社 西村 佳 氏 生成 AI は「使う」から「業務・経営を変える」段階へ 〜エージェントの価値をどう説明するか？〜 キユーピー株式会社 デジタル推進本部 IT 推進部 データ戦略チーム 内田 海登 氏 購買データなどをもとに人物像を設定した仮想の「生活者エージェント」を商品開発担当者の対話相手にする取り組みと、全社の AI エージェントの稼働状況を一元的に把握する仕組みが紹介されました。 ▲ キユーピー株式会社 内田 海登 氏 村田製作所の AI 活用基盤 株式会社村田製作所 データ戦略推進部 AI イノベーション推進課 鈴木 健太 氏 業務の中で生まれる知識を会社の資産として循環させる考え方と、AI エージェントの権限設計や人の承認を組み込んだ基盤の設計が紹介されました。 ▲ 株式会社村田製作所 鈴木 健太 氏 「AI の活用」から「AI サービスの提供」へ 〜AI エージェント量産に向けた基盤開発と社内実践〜 株式会社リコー DX 本部 データマネージメントセンター デジタル基盤開発室 宮本 篤 氏 業務部門ごとの AI エージェント開発に共通する機能を標準提供する AI エージェント基盤の設計と、社内実践で使えることを確かめながら少人数で進めた工夫が紹介されました。 ▲ 株式会社リコー 宮本 篤 氏 AWS セッションの紹介 Agent 活用環境の構築・運用のための AWS サービスのご紹介 〜統制とセキュリティ・自社の知識（データ / コンテキスト）・品質とコスト〜 アマゾン ウェブ サービス ジャパン合同会社 AI スペシャリスト 石坂 唯、AI スペシャリストソリューションアーキテクト 鯨田 連也 前半では石坂が、AI エージェントを事業で使うには、基幹業務に組み込み、部門ごとに分かれたデータをつなぎ、エージェントに適切な権限を与えることが要点であり、AWS が多くのお客様を支援する中で「統制とセキュリティ」「自社の知識（データとコンテキスト）」「品質とコスト」の 3 つが壁になっていると述べました。後半では鯨田が、AI モデル以外のエージェントの構成要素（Agent Harness）に求められる機能をビルディングブロックとして提供する Amazon Bedrock AgentCore について、前述の 3 つの観点で紹介しました。具体的には、利用者ごとの認証・認可、社内のエージェントと MCP サーバーの統制・管理、MCP を介した社内システム・文書への接続、エージェントの回答品質の評価・改善、レート制限による利用量の制御などを解説しました。 ▲ アマゾン ウェブ サービス ジャパン合同会社 鯨田 連也、石坂 唯 質疑応答では、エージェントが参照するナレッジベースへ利用者の権限をどう引き継ぐか、単一のエージェントが多くのタスクを担う方向と複数のエージェントが連携する方向のどちらに進むのか、という質問をいただきました。前者について登壇者は、AgentCore Gateway のインターセプターで利用者を識別する情報をナレッジベースに渡し、その利用者に許可された文書だけを検索させる方法を紹介しました。この方法は、登壇者が公開している記事「 Bedrock Managed Knowledge Base を MCP Tool として利用する際のテナント分離・アクセス制御まとめ 」で詳しく解説しています。 「ここだけの話」はどうつながったのか？ 各社の発表では、資料には書きにくい失敗や未解決の課題が率直に語られ、質疑応答では「うちも同じところで困っている」「こう割り切った」というやり取りが続き、質問が尽きずに時間で区切ったセッションもありました。ここでは、各社の発表と質疑応答から、複数の企業に共通していた点を 3 つの観点でまとめます。個々の企業の取り組みが分かる書き方は避け、複数の企業に共通していた傾向として書いています。 共通して効果があったこと 共通部品は基盤側で持ち、業務ごとの差分だけを各部門が作る。 認証・認可、ログ、ガードレール、評価の仕組みを基盤として提供し、各部門は業務ごとのワークフローやナレッジだけを作る分担にすると、エージェントが増えても運用の負荷が増えにくいという考え方が、複数の企業の基盤設計で共通していました。 使う人とユースケースを先に決めてから、基盤の要件を固める。 利用部門へのヒアリングで要件を確定し、少人数で範囲を絞って動くものを早く出し、使ってもらいながら直す進め方が「結果的に早かった」と複数の企業から報告されました。 RAG で止まっていた問い合わせが、エージェントで解けるようになった。 文書検索だけでは答えられなかった社内システムの照会や、複数の情報源を組み合わせる質問に、エージェントが検索をやり直したりツールを呼び出したりして答えられるようになった事例が複数ありました。 定着には、利用者が必ず通る導線と、体験の場が効く。 人に問い合わせる前にチャットボットを通す導線を作って自己解決を促す、開発者が自分の担当業務を題材に手を動かすワークショップを開く、社内で活用している人を表彰して見せる。こうした定着の工夫が、それぞれ別の企業から共有されました。 率直に語られた、難しかったこと 権限を検索条件で表現すると、権限が増えるほど検索が難しくなる。 社内文書を検索する RAG では、利用者が閲覧できる文書だけを検索の対象にするために、閲覧権限を検索の絞り込み条件（メタデータのフィルタ）として渡す方式がよく使われます。閲覧できる文書の範囲が広い利用者ほど絞り込み条件が長くなり、検索の回数や処理時間が増えるため、権限の持ち方と検索の設計を合わせて考える必要があるという指摘がありました。アンケートでも認証・認可の設計を最も大きな課題に挙げた参加者が最も多く、質疑でも権限の管理の仕方が繰り返し話題になりました。 最初から全部を生成 AI に任せると、結果が揺らぐ。 定型の事務作業を自動化するとき、処理の組み立てから実行までを生成 AI に任せると出力が揺らぎやすいため、固定できる手順はあらかじめ決めておき、生成 AI には部品の組み合わせや判断が必要な部分だけを任せる形に見直したという経験が共有されました。問い合わせ対応の自動化では、回答の精度より、届いた依頼を AI で答えられる問い合わせと人に引き継ぐべき案件に仕分ける判断の設計が難しいという指摘もありました。 ガードレールと評価の調整に時間がかかる。 不正な利用を防ぐ設定を強くしすぎると、製品の使い方を尋ねる通常の質問まで止めてしまう。新しいモデルに切り替える前に、回答の品質を人が確かめる作業に時間がかかる。回答の精度を上げるために検索と生成を繰り返すと、応答時間と利用料が増える。こうした調整の難しさは、複数の企業に共通していました。 参加企業に共通する、これからの課題 認証・認可と人の関与をどう設計するか。 利用者本人の権限をエージェントとナレッジベースまで引き継ぐこと、書き込みを伴う操作をどこまで許すか、人の承認をどの操作に組み込むか。全社の ID 基盤を管理する部門との調整も含めて、複数の企業がこれからの設計課題として挙げていました。 品質・コスト・成果をどう測るか。 評価データの量と評価者の確保、LLM による評価と人手の評価の分担、利用量とコストの制御、削減時間などの成果を算出して経営に説明する方法。エージェントの価値をどう定量的に説明するかという問いは、複数の企業に共通していました。 データの準備と統制のバランスをどう取るか。 データの準備にかかる時間をどう見込むか、非構造化データのオーナーをどう決めるか、市民開発で生まれるエージェントと CoE の統制をどう両立させるか。AWS のマネージドサービスは機能の追加が速く、自前で作った機能が後からサービスとして提供されることもあるため、基盤はできるだけマネージドサービスで構成して自前で保守する範囲を小さくするという方針も語られました。どれも 1 社では答えが出ない論点として、懇親会まで議論が続きました。 ▲ 参加者の皆様との集合写真 アンケート結果と参加者の声 参加者 20 名全員からアンケートの回答をいただきました。全体の満足度は 5 段階で平均 4.85、各社の発表をめぐる意見交換の満足度は平均 4.9 でした。「他社の取り組みで参考になった発表」というアンケート項目では、1 人あたり平均 3.7 社が選ばれ、7 社すべての発表が複数の参加者から選ばれました。 他社の発表を聞いて、自社の方針を決める参考になったという声が多くありました。 「エージェント導入の前段階のプロセスに各社いろいろなアプローチがあり、感銘を受けた」 「基盤の持ち方や基盤のあるべき形など、今後の方針を決めるうえで大変参考になった」 「各社の実際の課題と、それに対応するアーキテクチャの関係で理解できた」 「エージェント開発の課題と、その乗り越え方や付き合い方が勉強になった」 「各社ともプラットフォームづくりで同じ課題を抱えていることが分かった。孤独な戦いのように感じていたが、勇気をもらえた」 「製造業ではアプローチが違っても似たような悩みがあると分かった。別の業界の話も聞きたくなった」 「いま自社の生成 AI 活用で最も課題に感じていること」というアンケート項目では、認証・認可の設計と、人材と組織の変化がそれぞれ 20 名中 5 名で最も多く、ガバナンス（4 名）が続き、データの整備、コストと投資対効果の説明も複数の方が挙げました。ほかに、エージェント基盤を自社で持つ範囲の見極め、業務での実践先の見つけ方、先進性と全社展開のバランスが挙がっています。 AWS への期待としては、新しいサービスや機能の情報を早めに共有すること、データの源泉から RAG、AI エージェントまで一気通貫で認可を扱える機能、各社の知見を共有する場を続けることが挙がりました。 おわりに 今回のラウンドテーブルを通じて改めて感じたのは、お客様だからこそ答えられるお客様の悩みがあるということです。「この判断をどう割り切ったか」「社内のどこから手を付けたか」という実践知が企業間の対話で共有され、参加各社が次に取り組む判断の材料になっていました。 アンケートには「これだけの企業が同じ悩みを抱えているのに、なぜベストプラクティスが整備されないのか」という率直な問いもありました。認証・認可やガバナンスの設計は、サービスの機能だけでは決まらず、各社の組織とデータの状況に合わせた判断が必要です。その判断の材料を各社が持ち寄り、繰り返し使える形にしていくために、AWS では今後もこうした企業間の対話の場を企画してまいります。 ご参加いただいた皆様に、改めて御礼申し上げます。生成 AI や AI エージェントの活用でお悩みの方は、ぜひ担当のソリューションアーキテクトにご相談ください。 このブログは AWS Japan のソリューションアーキテクト 西田 光彦 が執筆しました。 西田 光彦は、エンタープライズのお客様をご支援しているソリューションアーキテクトです。自動車・製造業を専門領域とし、Generative AI/Physical AI など最新テクノロジーを活用してお客様の組織と業務変革のお手伝いしています。 Kiro と 信頼できる同僚達 に支えられながら仕事しています。

ソフトクリエイトの柾本 彬(本人)です。   Copilot StudioとCopilot Coworkに最近追加されたアプリ作成の機能を使い、仕様決めから業務アプリの作成・共有までを試しましたので、作成レポート的に投稿いたします。 前半はCoworkでAzureサブスクリプション台帳、後半はStudioでナレッジ共有アプリを作る例を記載しています。 今回作ったアプリはこの2つ！

課題 先月、ヨハネスブルグの製造業企業の 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 松本がレビューしました。原文は こちら です。