AWS for SAP MCP Server で実現する SAP へのシングルサインオン・エージェントアクセス

財務アナリストが AI アシスタントに「私の担当する顧客請求書のうち、支払期日を過ぎているものはどれですか？」と尋ね、SAP から直接その答えが返ってくる、そんな場面を想像してみてください。企業はまさにこれを求めていますが、AI エージェントを記録システムに接続する際には難しい問いが生じます。エージェントが SAP にアクセスするとき、そのリクエストを行っているのは誰なのか、という問いです。初期の統合の多くは、すべてのリクエストを 1 つの共有 SAP サービスユーザー経由でルーティングします。これでは、すべてのユーザーの操作が単一のテクニカルユーザーにマッピングされてしまうため、SAP は実際の操作者を認可・監査できなくなり、さらにセキュリティおよびコンプライアンスチームがめったに承認しない静的な SAP 認証情報の保存を強いられます。その結果、有望な AI パイロットが本番稼働に至る前に停滞してしまいます。

完全な ID 伝播は、SAP に至るすべての認証区間を通じて各ユーザーの ID を引き継ぐことでこの問題を解決します。リクエストが指名されたユーザーとして到着すると、SAP はそのユーザー自身の権限を適用し、Security Audit Log にそのユーザーの操作として記録し、共有された恒久的な認証情報を一切保存しません。RFC 8693 のトークン交換で定義されている On-Behalf-Of（OBO）アクセスは、ユーザーの既存トークンを SAP にスコープを絞ったダウンストリームトークンと交換することで、これを可能にします。Microsoft Entra ID や Okta などのエンタープライズ ID プロバイダー（IdP）はこのフローをサポートしているため、ユーザーは 2 度目のログインプロンプトなしで SSO を利用できます。本ブログでは、その体験を構築する方法を解説します。Amazon Quick を使って SAP の販売オーダー、財務、プラント保全について質問し、さらにアクションを実行しながら、AWS for SAP MCP Server と Microsoft Entra ID などのエンタープライズ IdP によって、あなたの ID を SAP まで引き継ぎます。

仕組み

エンドツーエンドのフローには 4 つの構成要素があります。MCP クライアントとして動作する AI エージェント（Amazon Quick）、AWS for SAP MCP Server をホストする Amazon Bedrock AgentCore Runtime、Entra ID、そして SAP システムです。フローを通過するために、Amazon Bedrock AgentCore 内には 2 つの異なる認証境界が設定されます。

• インバウンド: Amazon Quick が、そのユーザーが誰であるかを AgentCore に証明します。AgentCore は Entra ID に対してユーザー ID を検証します。
• アウトバウンド: AgentCore が SAP に受け入れられるトークンを取得します。OBO 交換により、SAP リソースにスコープを絞ったこのトークンが生成されます。

図 1. Amazon Quick、AWS for SAP MCP Server、SAP S/4HANA を統合したシングルサインオンのための高レベルアーキテクチャ。

1. ユーザーは Entra ID ログイン（メールアドレス）またはシングルサインオンを通じて Amazon Quick にサインインします
2. Amazon Quick は OAuth 2.0 を介して Entra ID でこのユーザーを認証し、AWS for SAP MCP Server にアクセスします
3. AgentCore は Entra ID でアクセストークンを検証します
4. AgentCore はすべてのユーザーアクセスを AgentCore Observability に記録します
5. AWS for SAP MCP Server は Entra ID と OBO 交換を実行し、その JSON Web Token（JWT）が SAP への HTTPS API 呼び出しで使用されます
6. Entra ID が提供する JWT は、SAP の OpenID Connect（OIDC）Trust によって検証されます

この設計では、以下に説明する 3 つの Entra ID アプリ登録を使用します。

• Amazon Quick Client App – Quick がユーザーをサインインさせるために使用する OAuth クライアント。
• Inbound / Resource App – インバウンドトークンを検証し、OBO 交換を実行します。AgentCore の認証情報プロバイダーはその client_id を使用し、これは Quick のトークンの aud でもあります。
• Outbound App – SAP アクセススコープを表します。SAP は最終トークンをこのアプリに対して検証します。

Microsoft Entra ID ベースのプロバイダー設定と、関連する構成要素について理解するには、AgentCore Identity のドキュメントを参照してください。

図 2. 3 つの Entra ID アプリ登録にまたがる委任権限のチェーン。

SAP BTP Integration Suite も、OBO（On Behalf Of）トークンチェーンを通じてこのパターンをサポートし、ID フローを次のように拡張します。Amazon Quick → AWS for SAP MCP Server → SAP BTP Integration Suite → SAP S/4HANA。SAP BTP でプリンシパル伝播と呼ばれる ID 伝播は、SAP BTP API Management によって処理されます。SAP ソリューションへの MCP アクセスパターンに関するベストプラクティスについては、SAP のガイダンスを参照してください。

実装の詳細

本セクションでは、Entra ID アプリ登録から SAP ユーザーマッピングまで、エンドツーエンドの設定を構成する手順を説明します。この設定の前提条件は以下のとおりです。

OIDC サポートの最新情報については、SAP のドキュメントを参照してください。

Step 1: インバウンド Entra ID アプリ登録を作成する

インバウンドアプリは、MCP クライアントが AgentCore Runtime に認証するために使用するトークンを発行します。この手順の 2 つの設定が、フローの後半で重要になります。まず、requestedAccessTokenVersion を 2 に設定します。これは OBO 交換と SAP 検証のいずれもが v2.0 トークンを期待するためです。次に、access_as_user 委任スコープを公開します。これは、Quick クライアントアプリがユーザーの代わりにこのアプリを呼び出すために要求する権限です。

TENANT_ID="<your-entra-tenant-id>"
INBOUND_APP_NAME="agentcore-mcp-inbound"

# Create the inbound app registration
az ad app create --display-name "$INBOUND_APP_NAME" --sign-in-audience "AzureADMyOrg"

# Capture the Application (client) ID and Object ID
INBOUND_APP_ID=$(az ad app list --display-name "$INBOUND_APP_NAME" --query "[0].appId" -o tsv)
INBOUND_OBJECT_ID=$(az ad app list --display-name "$INBOUND_APP_NAME" --query "[0].id" -o tsv)

# Require v2.0 tokens and set the Application ID URI
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \
  --body '{"api":{"requestedAccessTokenVersion":2}}'
az ad app update --id "$INBOUND_APP_ID" --identifier-uris "api://${INBOUND_APP_ID}"

# Expose the access_as_user delegated scope
INBOUND_SCOPE_ID=$(uuidgen)
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \
  --body "{\"api\":{\"requestedAccessTokenVersion\":2,\"oauth2PermissionScopes\":[{\"adminConsentDescription\":\"Access AgentCore MCP Server\",\"adminConsentDisplayName\":\"access_as_user\",\"id\":\"${INBOUND_SCOPE_ID}\",\"isEnabled\":true,\"type\":\"User\",\"userConsentDescription\":\"Access AgentCore MCP Server on your behalf\",\"userConsentDisplayName\":\"Access AgentCore MCP\",\"value\":\"access_as_user\"}]}}"

# Create the service principal
az ad sp create --id "$INBOUND_APP_ID"

Step 2: アウトバウンド Entra ID アプリ登録を作成する

アウトバウンドアプリは SAP アクセスを表します。AgentCore Identity はこれを OBO 交換のターゲットとして使用し、SAP は最終トークンをこれに対して検証します。この手順では sap_access スコープを公開し、インバウンドアプリが要求できる対象を用意します。また、インバウンドアプリを既知のクライアントアプリケーションとして事前承認します。これは、ユーザーに同意を求めることなく、Entra ID が 2 つのアプリ間で OBO トークンを発行できるようにする設定です。

OUTBOUND_APP_NAME="agentcore-mcp-obo-sap"

az ad app create --display-name "$OUTBOUND_APP_NAME" --sign-in-audience "AzureADMyOrg"
OUTBOUND_APP_ID=$(az ad app list --display-name "$OUTBOUND_APP_NAME" --query "[0].appId" -o tsv)
OUTBOUND_OBJECT_ID=$(az ad app list --display-name "$OUTBOUND_APP_NAME" --query "[0].id" -o tsv)

# v2.0 tokens + Application ID URI
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \
  --body '{"api":{"requestedAccessTokenVersion":2}}'
az ad app update --id "$OUTBOUND_APP_ID" --identifier-uris "api://${OUTBOUND_APP_ID}"

# Expose the sap_access delegated scope (SAP validates tokens against this)
OUTBOUND_SCOPE_ID=$(uuidgen)
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \
  --body "{\"api\":{\"requestedAccessTokenVersion\":2,\"oauth2PermissionScopes\":[{\"adminConsentDescription\":\"Access SAP on behalf of user\",\"adminConsentDisplayName\":\"sap_access\",\"id\":\"${OUTBOUND_SCOPE_ID}\",\"isEnabled\":true,\"type\":\"User\",\"userConsentDescription\":\"Access SAP on your behalf\",\"userConsentDisplayName\":\"SAP Access\",\"value\":\"sap_access\"}]}}"

az ad sp create --id "$OUTBOUND_APP_ID"

# Pre-authorize the inbound app as a known client application (enables OBO)
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \
  --body "{\"api\":{\"knownClientApplications\":[\"${INBOUND_APP_ID}\"]}}"

Step 3: 権限と管理者同意を構成する

この手順では、インバウンドアプリにアウトバウンドアプリの sap_access スコープへの委任権限を付与し、それを管理者同意します。この付与が OBO チェーンのインバウンドからアウトバウンドへの部分を有効にします。なぜなら、Entra ID は要求元アプリがターゲットスコープへの同意済み委任権限を保持している場合にのみ OBO トークンを発行するためです。

az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \
  --body "{\"requiredResourceAccess\":[{\"resourceAppId\":\"${OUTBOUND_APP_ID}\",\"resourceAccess\":[{\"id\":\"${OUTBOUND_SCOPE_ID}\",\"type\":\"Scope\"}]}]}"

az ad app permission admin-consent --id "$INBOUND_APP_ID"

Step 4: OBO 権限チェーンを構成する

この手順は権限チェーンを完成させるもので、不完全な場合 OBO 交換は失敗します。Entra ID は OBO トークンを発行する前に、次の 4 つを一括で検証します。

• アサーションの aud が交換を行う client_id と一致すること
• クライアントアプリがターゲットスコープへの委任権限を保持していること
• ターゲットアプリの knownClientApplications にクライアントチェーン全体が含まれていること
• サービスプリンシパルに対する oauth2PermissionGrant が存在すること

以下のコマンドは、これらの各要件を構成します。Amazon Quick クライアントアプリを作成済み（前提条件を参照）で、その QUICK_APP_ID、QUICK_OBJECT_ID、およびスコープ ID を取得済みであることを前提とします。

# 1. Add Quick + Inbound to the OUTBOUND app's knownClientApplications
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \
  --body "{\"api\":{\"knownClientApplications\":[\"${INBOUND_APP_ID}\",\"${QUICK_APP_ID}\"]}}"

# 2. Add Quick to the INBOUND app's knownClientApplications
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \
  --body "{\"api\":{\"knownClientApplications\":[\"${QUICK_APP_ID}\"]}}"

# 3. Grant the Quick client delegated access to both scopes, then admin-consent
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${QUICK_OBJECT_ID}" \
  --body "{\"requiredResourceAccess\":[{\"resourceAppId\":\"${INBOUND_APP_ID}\",\"resourceAccess\":[{\"id\":\"${INBOUND_SCOPE_ID}\",\"type\":\"Scope\"}]},{\"resourceAppId\":\"${OUTBOUND_APP_ID}\",\"resourceAccess\":[{\"id\":\"${OUTBOUND_SCOPE_ID}\",\"type\":\"Scope\"}]}]}"
az ad app permission admin-consent --id "$QUICK_APP_ID"

# 4. Create the oauth2PermissionGrant for the INBOUND service principal
INBOUND_SP_ID=$(az ad sp show --id "$INBOUND_APP_ID" --query "id" -o tsv)
OUTBOUND_SP_ID=$(az ad sp show --id "$OUTBOUND_APP_ID" --query "id" -o tsv)
az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants" \
  --body "{\"clientId\":\"${INBOUND_SP_ID}\",\"consentType\":\"AllPrincipals\",\"resourceId\":\"${OUTBOUND_SP_ID}\",\"scope\":\"sap_access\"}"

# 5. Emit the email claim on the OUTBOUND app — this is the only claim SAP uses for user mapping
az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \
  --body '{"optionalClaims":{"accessToken":[{"name":"email","essential":true}]}}'

Step 5: インバウンド Entra ID アプリの詳細を AWS Secrets Manager に保存する

AgentCore Identity は認証情報プロバイダーを通じて OBO 交換を実行します。この手順における以下の選択は必須であり、Entra ID が OBO リクエストを検証する方法から直接導かれます。

AWS_REGION="us-east-1"

# Client secret for the INBOUND app + store it in AWS Secrets Manager
INBOUND_APP_SECRET=[REDACTED_PASSWORD] ad app credential reset --id "$INBOUND_APP_ID" \
  --display-name "obo-exchange-secret" --query "password" -o tsv)
aws secretsmanager create-secret \
  --name "AWSforSAP-MCP-OAuthCredentials-EntraId" \
  --secret-string "{\"clientId\":\"${INBOUND_APP_ID}\",\"clientSecret\":\"${INBOUND_APP_SECRET}\"}" \
  --region "$AWS_REGION"

Step 6: AWS CloudFormation で MCP Server をデプロイする

この手順では、AWS CloudFormation を使って AWS for SAP MCP Server をデプロイします。2 つのパラメーターがサーバーによるリクエスト認証の方法を決定し、CloudFormation は両方の認証コンポーネントをプロビジョニングするため、いずれも手作業で構築する必要はありません。InboundAuthProvider を Entra ID に設定すると、インバウンド認証のために AgentCore Runtime に JWT オーソライザーがアタッチされます。これはランタイム組み込みの JWT オーソライザーであり、Entra ID のディスカバリー URL と許可されたオーディエンスから構成されるもので、別個のカスタムオーソライザーではありません。AuthFlow を ON_BEHALF_OF_TOKEN_EXCHANGE に設定すると、アウトバウンドの OBO 交換を実行する MicrosoftOauth2 認証情報プロバイダーが作成されます。次の表のパラメーターは、サーバーを Entra ID テナントと 2 つのアプリ登録に接続します。

TEMPLATE_URL="https://awsforsap-mcp-server-setup-${AWS_REGION}.s3.${AWS_REGION}.amazonaws.com/cfn-launch-template/latest/AwsForSapMcpServerStack.template.json"

aws cloudformation create-stack \
  --stack-name "sapmcp-${UNIQUE_ID}" \
  --template-url "$TEMPLATE_URL" \
  --parameters \
    ParameterKey=UniqueId,ParameterValue="${UNIQUE_ID}" \
    ParameterKey=SapBaseUrl,ParameterValue="${SAP_BASE_URL}" \
    ParameterKey=SapSystemType,ParameterValue="S4HANA" \
    ParameterKey=InboundAuthProvider,ParameterValue="EntraId" \
    ParameterKey=DiscoveryUrl,ParameterValue="https://login.microsoftonline.com/${TENANT_ID}/v2.0/.well-known/openid-configuration" \
    ParameterKey=AllowedAudiences,ParameterValue="${INBOUND_APP_ID}" \
    ParameterKey=AuthFlow,ParameterValue="ON_BEHALF_OF_TOKEN_EXCHANGE" \
    ParameterKey=SapCredentialsSecret,ParameterValue="AWSforSAP-MCP-OAuthCredentials-EntraId" \
    ParameterKey=SapTokenUrl,ParameterValue="https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
    ParameterKey=OauthScopes,ParameterValue="api://${OUTBOUND_APP_ID}/sap_access" \
    ParameterKey=McpServerVpcSecurityGroup,ParameterValue="${VPC_SG}" \
    ParameterKey=McpServerNetworkSubnets,ParameterValue="${SUBNET_ID}" \
    ParameterKey=McpServerReadEnabled,ParameterValue="true" \
    ParameterKey=McpServerWriteEnabled,ParameterValue="true" \
    ParameterKey=McpServerCreateEnabled,ParameterValue="true" \
    ParameterKey=McpServerUpdateEnabled,ParameterValue="true" \
    ParameterKey=McpServerDeleteEnabled,ParameterValue="true" \
    ParameterKey=McpServerFunctionImportEnabled,ParameterValue="true" \
  --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM \
  --region "$AWS_REGION"

aws cloudformation wait stack-create-complete --stack-name "sapmcp-${UNIQUE_ID}" --region "$AWS_REGION"

# Verify both auth components were created
  aws bedrock-agentcore-control get-oauth2-credential-provider \
    --name "AWSForSAP-MCP-OAuth2-Provider-${UNIQUE_ID}" --region "$AWS_REGION" \
    --query "{vendor:credentialProviderVendor, clientId:oauth2ProviderConfigOutput.microsoftOauth2ProviderConfig.clientId, status:status}"

# Register the CFN-created credential provider's callback URL on the inbound app
  CALLBACK_URL=$(aws bedrock-agentcore-control get-oauth2-credential-provider \
    --name "AWSForSAP-MCP-OAuth2-Provider-${UNIQUE_ID}" --region "$AWS_REGION" \
    --query "callbackUrl" --output text)

  az rest --method PATCH \
    --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \
    --body "{\"web\":{\"redirectUris\":[\"${CALLBACK_URL}\"]}}"

デプロイ後の手順: スタックが正常に作成された後、MCP Server のエンドポイント URL を インバウンドアプリの Identifier URI として登録し（Amazon Quick はこれを resource パラメーターとして送信します）、認証情報プロバイダーのコールバック URL をインバウンドアプリのリダイレクト URI として登録します。

次の表は、各認証コンポーネントとその作成元となるパラメーターをまとめたものです。ランタイム構成の型は customJWTAuthorizer という名前ですが、これは Entra ID の発行者とオーディエンスでパラメーター化された AgentCore Runtime の標準 JWT オーソライザーであり、別個のオーソライザーを記述・デプロイする必要はありません。

Step 7: SAP OIDC トラストとユーザーマッピングを構成する

SAP 側では、トランザクション SOIDC で OIDC トラストを作成し、SAP に Entra ID からのトークンを受け入れるよう指示します。この手順で ID 伝播が実体を持ちます。なぜなら、SAP はトークンをサービスアカウントではなく指名されたユーザーにマッピングするためです。SAP は以下を検証します。

• iss: トークン発行者があなたの Entra ID テナントでなければなりません。
• aud: Outbound App ID と一致しなければなりません。
• 署名: Entra ID が公開する JWKS に対して検証されます。
• ユーザーマッピング: SAP はトークン内の email クレームを個々の SAP ユーザーにマッピングします。

図 3. Entra ID 向けの SAP OIDC 構成

マッピングは email に基づくため、各ユーザーの SAP ビジネスパートナーまたはユーザーレコードが、Entra ID が発行するのと同じメールアドレスを保持していることを確認してください。この一致が、認証済みトークンを MULLERF のような特定の SAP ユーザーに解決するものです。

Step 8: OBO フローをエンドツーエンドでテストする

フローをテストする前に、AWS for SAP MCP Server を Amazon Quick のコネクターとして追加します。これは Entra ID に Amazon Quick クライアントアプリをプロビジョニングする手順でもあります。コネクターを追加するには、次の手順を実行します。

1. Amazon Quick でコネクター（MCP サーバー）設定を開き、新しい MCP コネクターの追加を選択します。
2. Step 6 の CloudFormation スタック出力にある AWS for SAP MCP Server のエンドポイント URL を入力します。
3. 認証（Authenticate）の手順で「User authentication method」を選択し、Auth 構成を「Custom user based OAuth」に設定して、Entra ID テナントの OAuth フィールドを入力します。次を指定します — Client ID として Amazon Quick クライアントアプリの AppID（client）、Public OAuth client はチェックしないまま、Client secret、Authorization URL（https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/authorize）、および Token URL（https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/token）。
4. コネクターを保存し、対話型サインインを一度完了します。Amazon Quick は Entra ID にクライアントアプリケーションを登録します。その QUICK_APP_ID、QUICK_OBJECT_ID、およびスコープ ID を取得し、権限チェーンをまだ完了していない場合は Step 4 を実行します。

コネクターが配置されたら、実際のユーザーとしてサインインし、「私の未処理の販売オーダーを表示して」のような、SAP の読み取りにマッピングされる自然言語の質問をします。テストが成功すると、以下が確認されます。

1. Quick が SAP パスワードのプロンプトなしで Entra ID に対してあなたを認証します。
2. MCP Server が SAP データを返します。
3. SAP では、Security Audit Log（トランザクション SM20）がリクエストをサービスアカウントではなくあなたのユーザーに帰属させます。この最後の点が、ID がエンドツーエンドで伝播したことの証明です。
4. トランザクション SOIDC で、OIDC トラストがトークンの email クレームを個々の SAP ユーザーにマッピングしていることを確認し、コネクターと CloudFormation の構成が SAP サービスアカウントの認証情報を一切保持していないことを検証します（保存される唯一のシークレットは AWS Secrets Manager 内の Entra ID インバウンドアプリのクライアントシークレットです）。これは、アクセスが共有 SAP パスワードではなく ID 伝播によって付与されていることを証明します。

トラブルシューティング

以下の注記は、最も一般的な問題に対処します。

• AADSTS500131（アサーションオーディエンスの不一致）: 認証情報プロバイダーが誤った client_id を使用しています。Quick のトークンの aud と一致する、インバウンドアプリのものでなければなりません。
• AADSTS7000114（OBO が許可されていない）: Step 4 の権限チェーンが不完全です。knownClientApplications、委任権限の付与、管理者同意、および oauth2PermissionGrant を確認してください。
• SAP がトークンを拒否する: SOIDC トラストの iss、aud = Outbound App ID を再確認し、email クレームが存在し（Step 4.5）、SAP ユーザーと一致していることを確認してください。

始めましょう

AI エージェントに SAP へのアクセスを与えることは、ユーザーごとのセキュリティを諦めることを意味しません。Amazon Bedrock AgentCore を基盤とする AWS for SAP MCP Server を使えば、あなたの ID をバックエンドまで完全に保持しながら、Amazon Quick を通じて SAP と対話できます。

このソリューションは 4 つの成果をもたらします。

• 監査証跡が個々のユーザーのアクションを記録します。 SAP は、すべての AI 主導のリクエストを、共有サービスアカウントではなく実在の人物として認証、認可、監査します。
• SAP パスワードを一切保存しません。 OBO 交換は完全にサーバーサイドで実行され、保存される唯一のシークレットは Entra ID インバウンドアプリの認証情報です。
• 最小権限と監査を維持します。 SAP は引き続きユーザー自身のロールを適用し、そのアクションをユーザー自身の ID の下で記録します。
• スコープを分離した設計。 クライアント、インバウンド、アウトバウンドの各アプリを分離し、OBO 交換ではトークンオーディエンスと一致させるためインバウンドアプリの認証情報を使用します。

始めるには、Microsoft Entra ID と AgentCore Identity の On-Behalf-Of トークン交換を用いて AWS for SAP MCP Server をデプロイしてください。これにより、共有 SAP 認証情報なしで、AI エージェントに SAP へのセキュアなユーザーごとのアクセスを提供できます。

Fortescue、PLDT、Harman などのお客様が、どのように AWS for SAP MCP Server を活用してエージェント型 AI の強化を実現しているかについては、AWS for SAP Blog をご覧ください。今すぐ構築を始めましょう。始めるには、AWS for SAP MCP Server のページをご覧ください。AWS が何千もの SAP のお客様にとって選ばれるプラットフォームでありイノベーションの場である理由については、AWS for SAP のページをご覧ください。

著者について

本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文はこちらです。