既存のワークフローをMCPツールとしてAIへ公開する新機能
AWSは2026年10月29日、AWS Step FunctionsのワークフローをAmazon Bedrock AgentCore Gateway経由でAIエージェントのツールとして利用できる機能を発表しました。この機能により、すでに運用しているStandardおよびExpressステートマシンを、Model Context Protocol（MCP）に準拠したツールとしてエージェントに公開できます。
今回の仕組みでは、ツールのスキーマ生成とStep Functionsへの認証をAgentCore Gatewayが担う構成です。中継用のLambda関数やMCPサーバーを自作することなく、既存フローをそのまま公開対象として設定できます。
この連携における大きな特徴は、AIエージェントとステートマシンの明確な役割分担です。エージェントは状況に応じてワークフローをいつ起動し、どのような入力パラメータを渡すかを判断します。一方で、実際に実行される処理ステップとその順番はステートマシン側で厳格に定義されており、エージェントが途中の工程を勝手に飛ばしたり順序を入れ替えたりすることはできません。承認や監査の要件を満たす業務プロセスを崩さずにAIを組み込める点が、業務システムと接続する上での大きな利点となります。
起動対象の固定と実行ARNに対するIAM制御
ステートマシンをAIに公開する際は、どの操作を許可し、対象リソースをどう制限するかが安全運用の鍵となります。Amazon Bedrock AgentCoreの開発者ガイドによると、コネクタが提供する操作には、ターゲット作成時に対象ステートマシンを固定（ピン留め）するものと、実行ごとの識別子を受け取るものの2種類が存在します。
ワークフローの開始や一覧取得に関わるStartExecution、StartSyncExecution、ListExecutions、DescribeStateMachineの4つの操作は、ターゲットの設定時に対象ステートマシンのARNを固定します。固定されたステートマシンはツールの入力パラメータから除外されるため、エージェント側で指定できず、呼び出し時に別のステートマシンへ変更することもできません。エージェントが対象を変更しようとしてもGatewayが遮断するため、呼び出し先が意図せず切り替わるリスクを防ぐ仕組みです。
一方で、実行状態の取得や停止を行うDescribeExecution、StopExecution、GetExecutionHistoryなどの操作は、エージェントから渡された実行ARN（Amazon Resource Name）を対象に動作します。ターゲット設定での固定だけではアクセス先を限定できないため、Gatewayに割り当てるサービスロールのIAMポリシー側で、公開対象とするステートマシンの実行ARNに制限をかける設計が欠かせません。
さらに、同一のGatewayに設定されたすべてのターゲットは同じサービスロールを共有します。業務フローごとにIAMの認可境界を厳密に分けたい場合や、部署ごとに閲覧できる実行履歴を分離したい場合は、Gateway自体を個別に分けて構成する配慮が求められます。
履歴照会を伴う試行とStandardワークフローの前提
AIエージェントと既存フローを初めて接続して検証する際は、ワークフローの種別と設定オプションの把握が欠かせません。Step Functionsの開発者向けチュートリアルでは、検証用の構成としてStandardワークフローが指定されています。
Step FunctionsにはStandardとExpressの2種類のワークフローが存在します。ただし、実行一覧を取得するListExecutions、実行詳細を取得するDescribeExecution、イベント履歴を取得するGetExecutionHistoryといった操作は、Expressワークフローの実行には利用できません。エージェントが過去の実行結果を調べて担当者に報告したり、夜間に失敗した箇所の原因を特定したりする用途を試すには、Standardワークフローを対象にする必要があります。一方で、同じ呼び出しの中で実行結果を受け取る同期処理（StartSyncExecution）はExpressのみが対象です。そのため、同じ呼び出しで結果を受け取る必要性と、利用できる履歴照会操作の違いに応じて選択が分かれます。
また、接続条件として、AgentCore Gatewayは自身と同じリージョンにあるStep Functionsのエンドポイントを呼び出す仕様となっています。異なるリージョンに配置されたステートマシンには直接アクセスできないため、検証用環境のリージョン選定には注意が必要です。
実行結果をエージェントに正しく把握させるための設定確認も重要です。DescribeExecutionが返す実行情報の既定値はメタデータのみとなっており、ステートマシンが受け取った入力値や出力データは含まれません。エージェントが前後の文脈を理解して次のアクションを判断するために入出力データが必要な場合は、リクエスト時にincludedDataパラメータへALL_DATAを指定する運用設計を組み込みます。
国内の受注業務を想定した接続範囲と検証の進め方
ここまでの仕組みを踏まえ、国内企業が既存フローへの接続を検討する場面を考えてみます。例えば、国内の卸売企業において、受注確認から在庫引当、出荷登録までの一連の処理をStep Functionsで自動化している状況を仮定します。現場の業務担当者がチャット形式のAIツールから「本日の注文処理でエラーが発生していないか」「特定の注文番号の処理状況はどうなっているか」を照会できるようにする運用がその一例です。
このような連携を試す場合、最初から本番の基幹連携に踏み切るのではなく、小さく安全に確認できる範囲から着手するのが堅実です。まずは現在稼働しているワークフローがStandardかExpressか、どのリージョンで動いているかを確かめます。その上で、検証用のStandardステートマシンを用意し、模擬の受注データを用いた起動テストと、実行ステータスや履歴情報の取得から動作を確かめる手順が適しています。
エージェントに渡す入力項目と、担当者が求めている実行結果の表示範囲を整理し、DescribeExecutionのメタデータで十分なのか、入力値や出力データの取得まで含めるべきかを検証します。あわせて、起動対象が意図したフローに固定されているか、サービスロールのIAMポリシーで無関係な実行ARNの履歴閲覧が遮断されているかを照合します。
注意すべき点として、ステートマシンによって処理ステップの順序が保証されることと、AIから渡された受注データの内容そのものが業務上正しいことや、同一データの二重実行が防止されることは別問題です。既存のワークフロー側で入力検証や冪等性の制御がどのように実装されているかを確認し、不足があれば既存フローや接続API側での改修をあわせて検討する必要があります。
デノフへの相談と業務整理の進め方
既存の業務フローをAIエージェントとつなぎ合わせる際には、ツールの設定だけでなく、どの工程をAIの判断に委ね、どの手順を定義済みフローとして守るべきかという業務プロセスの切り分けが重要になります。
デノフのサービス案内では、Webサイト・業務システムの設計・開発・運用保守とともに、業務の整理からAIを活用する業務の選定、ツール選定、導入後の定着までの支援を行っています。社内の受注管理や既存システムに合わせて、お客様の業務に即した自動化の仕組みを設計・構築することが可能です。
「現在のStep FunctionsフローをAIから呼び出せるようにしたい」「既存の受注管理システムとAIの間にどのような改修が必要かを整理したい」「検証用の自動化構成や運用画面の設計から始めたい」といった段階から、具体的な接続範囲の検討をお手伝いします。自社の業務に合わせたシステム連携やAI導入の進め方については、デノフへの相談窓口よりお気軽にお問い合わせください。
