AWSが発表した内容
AWSは10月29日、Amazon Bedrock AgentCore Gatewayから既存のAWS Step Functions StandardおよびExpress workflowをModel Context Protocol toolとしてAI agentへ公開できる機能を発表しました。Agentはworkflowの開始時点とinputを決め、Step Functionsはoperatorが定義したstate machineを実行します。AWSによると、agentはworkflow runも調査でき、この機能はAgentCore Gatewayを利用できる全AWS Regionで提供されます。
Built-in connectorがMCP tool schemaを生成し、gateway service roleでStep Functionsへ認証するため、teamはLambda adapterや独自MCP serverを書く必要がありません。StartExecution、StartSyncExecution、ListExecutions、DescribeStateMachineの4 operationはstate machineへpinできます。Execution調査、停止、callback完了を含む残り6 operationでは、agentがexecution ARNまたはtask tokenを渡します。
ここまではAWSが公表した機能とavailability statusであり、以下はIneezaの本番運用分析です。このlaunchはagentが選んだinputの信頼性を保証せず、StandardとExpressへ同じexecution guaranteeを与えず、workflowの成功をbusiness authorizationやfinancial finalityへ変えるものでもありません。
固定されたstep順序は開始判断を検証しない
Multi-step processをstate machineへ移すと、agentは定義済みstateをskipしたり並べ替えたりできません。これはprobabilistic planningとdeterministic orchestrationを分離する有効な設計です。一方で、agentはworkflowをいつ呼び出すかを決め、tool schemaで公開されたinput fieldを制御します。
Ineezaの分析: 不可逆なstateへ進む前にworkflow boundaryでinvocationを検証すべきです。Caller、tenant、workflow version、business object、許可されたoperation、input schema、data classification、freshness、approval record、request identifierを結び付けます。Eligibility、approval、creditを常に順番どおり実行するrefund workflowでも、agentがcustomer、invoice、amount、destination、approval contextを差し替えられれば安全ではありません。
PinningとIAMに同じauthorityを表現する
AWSはpinされたstateMachineArnをagent向けtool schemaから除き、上書き要求を拒否します。Execution-level operationは異なります。DescribeExecution、StopExecution、GetExecutionHistoryではagentがARNを渡し、到達可能なexecutionの制限をgateway service roleへ依存します。AWSは一つのgateway上の全targetが同じservice roleを共有することも明記しています。
Ineezaの分析: Pinningはrouting integrity、IAMはauthorization perimeterです。Execution ARNを公開対象state machineへ限定し、agentごとに必要なoperationだけを公開し、workflowのtrust zoneが異なる場合はgatewayを分離すべきです。Cross-tenant ARN、推測したexecution name、stale execution、未認可のstop requestをtestします。正しいstate-machine pinは、unpinned toolへ広すぎるroleを付与した問題を補えません。
Workflow typeでretryとevidence semanticsが変わる
AWSはStandard workflowをlong-runningかつauditableとし、execution historyとexactly-once workflow executionを提供すると説明しています。Express workflowはhigh event rate向けで、stepがat-least-onceで実行される可能性があり、addressableなexecution-history operationも同一ではありません。StartSyncExecutionはExpress、execution ARNによる調査と停止はStandard executionが対象です。
Ineezaの分析: Workflow typeはthroughputや価格だけでなくcorrectnessの判断として選ぶべきです。Service retry、timeout、downstream systemにより不確実な結果が生じ得るため、外部effectには引き続きidempotency keyが必要です。Requested、accepted、running、awaiting approval、succeeded、failed、timed out、stopped、reconciliation pendingなどのstateを明示します。MCP toolがerrorなしで戻ったことをpayment、ledger、fulfillmentのfinalityとみなしてはいけません。
Task tokenは委任されたcompletion capabilityである
ConnectorはSendTaskSuccess、SendTaskFailure、SendTaskHeartbeatを公開し、callback待ちのStandard workflowをagentが再開できるようにします。AWSはこれらのactionにresource-level IAM permissionを設定できず、全resourceへのgrantが必要なため、どのwaiting taskを完了できるかをtask tokenが制御すると説明しています。
Ineezaの分析: 各task tokenをshort-lived bearer capabilityとして扱うべきです。意図したagent instanceだけへ渡し、promptやdurable transcriptへ残さず、callback payloadを元taskとpolicy versionへbindし、一度だけconsumeします。Modelが生成したsuccessはschema validationと独立したcheckを通してからhigh-impact transitionを解除すべきです。Token漏えいは狭いworkflow pauseをcompletion assertionのauthorityへ変えます。
Ineezaの見解
このlaunchが重要なのは、既存のorchestration、approval、retry、audit mechanismを再びmodel toolとして作り直さず、agent向けMCP boundaryの背後へ置ける点です。安全なpatternは単に「processをStep Functionsへ入れる」ことではありません。Invocationを検証し、pinとleast-privilege IAMを一致させ、execution semanticsを意図的に選び、callback capabilityを保護し、effectをidempotentにし、agent requestから完全なworkflowとbusiness outcomeまでを相関させる必要があります。Workflowは作業の進み方を固定しますが、その作業が認可され実際に完了したかを判断するのは周囲のcontrol planeです。