AWS Step FunctionsのワークフローがAgentCore Gateway経由でAIエージェントのツールに、手順の順序は状態マシンが決める

AWSは2026年10月29日、AWS Step Functionsのワークフローを、Amazon Bedrock AgentCore Gatewayを通じてAIエージェントのツールとして使えるようにしたと発表した。エージェントがワークフローをいつ実行するか、どんな入力を渡すかを決め、Step Functionsは定義されたとおりに各ステップを実行する。既存のStandardとExpressのワークフローをそのままツールにでき、料金はStep FunctionsとAgentCore Gatewayの標準料金である。

価値は役割分担にある。AgentCore GatewayはModel Context Protocol（MCP）でエージェントとツールをつなぎ、Step Functionsは複数ステップの業務プロセスを決まった順序で実行する。AWSの例では、カスタマーサポートのエージェントが返金ワークフローを起動すると、Step Functionsが資格確認、マネージャー承認、返金処理のステップを順に実行し、すべての返金が方針に従う。運用エージェントはワークフローの実行履歴も照会でき、オンコールのエンジニアに、昨夜どの注文が、どのステップで失敗したかを伝えられる。発表はStep Functionsが220以上のAWSサービスを連携できると述べるが、これはAWS自身の数字である。この機能はAgentCore Gatewayが使えるすべてのリージョンで利用できる。

開発者ガイドは仕組みを説明している。ゲートウェイのターゲットを作るとき、組み込みのStep Functionsコネクタを選ぶ。Lambda関数やMCPサーバーを書く必要も、ツールを自分で定義する必要もない。ゲートウェイがツールのスキーマを作り、エージェントに代わってStep Functionsを呼ぶ。コネクタは10の操作を公開する。うち4つは、ターゲット作成時に固定した状態マシンに対して働く。StartExecution、StartSyncExecution、ListExecutions、DescribeStateMachineだ。エージェントは固定された状態マシンを見ることも変えることもできず、stateMachineArnを渡すとゲートウェイが呼び出しを拒否する。残る6つ、DescribeExecution、StopExecution、GetExecutionHistory、SendTaskSuccess、SendTaskFailure、SendTaskHeartbeatは、エージェントが渡す実行ARNまたはタスクトークンに対して働く。固定した状態マシンには制限されず、ゲートウェイのサービスロールのIAMポリシーだけが制約になる。

権限の境界には注意が要る。ドキュメントは、そのポリシーをできるだけ絞ることを勧めており、たとえばDescribeExecution、StopExecution、GetExecutionHistoryは、公開する状態マシンの実行ARNに限定し、states:*を付与しない。3つのSendTask操作はIAMにリソースレベルの権限がなく、「*」で許可する必要があるため、タスクトークンが唯一の統制手段になり、トークンは秘密として扱うべきだ。固定できる操作にstateMachineArnを設定しないと、ゲートウェイはターゲットを作れるが、ツールは呼び出しのたびに失敗する。

2種類のワークフローでは使える操作が異なる。StartSyncExecutionはExpress専用でStandardでは失敗する。ListExecutionsはStandard専用で、ExpressではStateMachineTypeNotSupportedが返る。DescribeExecution、GetExecutionHistory、StopExecutionはStandardの実行専用で、Expressの実行は開始後にARNで指定できないためだ。StartExecution、DescribeStateMachine、SendTask系は両方で使える。Standardは各ステップを実行履歴に記録し、最長1年動くので、監査や人の承認が要る長い処理に向く。ワークフローは.waitForTaskTokenで一時停止し、トークンをエージェントのアプリに渡し、エージェントが完了後にSendTaskSuccessかSendTaskFailureを呼んで再開させる。ExpressとStartSyncExecutionは同期的な要求と応答に合う。 ここで「両方で使える」のはコネクター操作の話で、.waitForTaskTokenのコールバック自体はStandard専用であり、Expressには対応しない。

チュートリアルはPass状態が1つだけのStandard状態マシンを使い、awscurlでエージェントと同じMCP呼び出しを行う。リソースはすべて同じリージョンに作る必要がある。ゲートウェイは自分のリージョンのStep Functionsを呼ぶからだ。チュートリアルのリソースは削除するまで状態遷移とツール呼び出しの料金が発生する。AWSのページには遅延、規模、顧客の数字はなく、これは性能報告ではなく機能の説明である。実際の価値は、ワークフローがすでによく定義されているか、ゲートウェイのロールをどれだけ絞るかで決まる。