ひとことで言うと
BedrockとAgentCoreの両方に最適化されたサービス統合を持つ、状態機械（ステートマシン）です。GenAIの文脈では「FM呼び出しをどう並べ、どう失敗に備え、どこで人間を挟むか」を配線する層として出てきます。
要するに、配線図付きの指揮台です。Lambdaが個々の手足だとすれば、Step Functionsはどの手足をどの順番で、失敗したらどう動かすかを決める指揮者です。
BedrockのInvokeModelもAgentCoreのInvokeHarnessも、専用のResource型（arn:aws:states:::bedrock:invokeModel等）として直接呼べます。呼び出しごとにLambdaのグルーコードを書く必要がありません。
なぜ生まれたか
GenAIアプリのオーケストレーションは、単発のFM呼び出しでは終わりません。プロンプトチェーン（前の応答を次の入力に使う）、複数ツールを試すReActループ、失敗したら別モデルにフォールバックする構成、人間の承認を待ってから実行を続ける構成など、「順序・分岐・待機・リトライ」を伴う処理が必ず出てきます。これをアプリのコードに素朴に書くと、状態管理とエラー処理だけで肥大化します。
Step FunctionsはRetry・Catch・Choice・Map・Parallelといった状態をJSON定義で持つことで、この配線をコード外に出します。BedrockとAgentCoreの両方に最適化統合が用意されているのは、GenAIのオーケストレーションがこのサービスの主要な適用先の一つになっているためです。
| 素朴に自作すると肥大化する処理 | Step Functionsの受け皿 |
|---|---|
| モデル呼び出し失敗時のリトライ制御 | Retry（指数バックオフ）・Catch（代替パス） |
| 複数ツールを試すエージェントループ | Choice・Mapによる分岐と並列実行 |
| 人間承認を挟む処理の待機 | .waitForTaskTokenによるコールバック |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| プロンプトチェーン | 前段のInvokeModel結果を次のTask Stateの入力に渡す | D1 |
| エージェントのReActループ | Choiceでツール呼び出しか最終応答かを分岐し、Mapで並列にツールを試す | D2 |
| AgentCoreハーネスの起動 | InvokeHarnessで長時間の多ターン会話・ツール利用を委ねる | D2 |
| サーキットブレーカー・フォールバック | Retryで指数バックオフ、Catchで代替モデルへの切り替えパスに分岐 | D1・D5 |
| 人間承認（HITL） | .waitForTaskTokenでコールバックを待ち、人間の承認後に処理を再開する | D3 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| モデル呼び出し失敗時の継続性 | 一時的な障害に備えたい → Retry＋Catchによるサーキットブレーカー | アプリ側で単純にtry-catchしてリトライし続ける実装（バックオフなし・観測不能） |
| 長時間実行のエージェント処理 | 数分〜数十分のツール利用を伴う → Standardワークフロー（最大1年実行）＋InvokeHarness | Expressワークフロー（最大5分）で長時間セッションを組もうとする案 |
| 承認を経てから機微な操作を実行したい | 人間の判断を挟む → .waitForTaskTokenによるコールバックパターン | Bedrock Guardrailsだけで代替しようとする（Guardrailsは検閲であって承認フローではない） |
| AgentCoreハーネスの呼び出しがタイムアウトする | Task Stateの上限は15分固定（TimeoutSecondsをそれ以上にしても効かない） | TimeoutSecondsを伸ばせば長く待てると考える |
| 高頻度・低レイテンシなストリーミング系処理 | at-least-once・5分以内で完結 → Expressワークフロー | すべてのユースケースにStandardワークフローを一律適用する |
InvokeHarnessは.syncにも.waitForTaskTokenにも対応していません。サポートされるのはRequest Responseパターンのみで、しかもTask State自体の実行時間は15分が上限です（ハーネス側のタイムアウトをそれより長く設定しても、Step Functions側は15分で打ち切ります）。マルチターンの会話でも最後のアシスタント発言だけが返り、途中のターンやツール利用の詳細は破棄されます。エージェントの思考過程を追いたい場合はCloudWatch Transaction Searchでの観測が別途必要です。
実務でどう使うか
InvokeModelのペイロードは256KiBまで。 超える場合はBodyではなくInput/OutputにS3 URIを指定して大きなデータを迂回させます。画像やドキュメントを直接埋め込む設計は上限に当たります- モデルカスタマイズ（
CreateModelCustomizationJob）も.sync統合で待てます。 ファインチューニングジョブの完了をポーリングするコードを自作する必要がありません - IAMポリシーは自動生成されるが、ワイルドカードを避けて特定のモデルARN・ハーネスARNにスコープを絞るのが推奨。 コンソールが自動生成するロールをそのまま使うと過剰な権限になりがちです
- Standard/Expressの選択はGenAIワークロードの性質で決まります。 対話1往復で完結する軽いAPI呼び出しはExpress、複数ターンにまたがるエージェントの実行やHITLを含む長時間フローはStandardが基本線です
| 項目 | Standard | Express |
|---|---|---|
| 最大実行時間 | 1年 | 5分 |
| 実行保証 | exactly-once | at-least-once |
| GenAIでの用途 | 長時間のエージェント実行・HITL | 単発API呼び出し・高頻度ストリーミング |
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Bedrock Prompt Flows | Prompt FlowsはBedrock内で完結するプロンプトチェーン専用のノーコードツール。Step FunctionsはBedrock以外のAWSサービスも横断するオーケストレーションが要る場面で選ぶ |
| AgentCore Runtime単体 | Runtime単体でもエージェントは動くが、**複数エージェント・複数ステップにまたがる制御フロー（承認待ち・条件分岐・他サービス連携）**が要るならStep Functionsで包む |
| EventBridge | EventBridgeはイベントの配送が主役。Step Functionsは手順の実行と状態管理が主役。イベント起点でワークフローを起動する形で併用することが多い |
| Lambda単体でのオーケストレーション実装 | 状態管理・リトライ・可視化をコードで自作するとStep Functionsの再発明になる。分岐やリトライが複雑になった時点で移行を検討する対象 |
想起チェック
Q1. AgentCoreハーネスの呼び出しで、多ターンの会話履歴のうちStep Functionsが受け取れるのはどこまで？
最後のアシスタント発言のみです。途中のターンやツール利用・推論ブロックは応答から破棄されます。詳細な過程を追うにはCloudWatch連携での観測が別途必要です。
Q2. モデル呼び出し失敗時にサーキットブレーカーを実装する標準の組み方は？
Task StateにRetry（指数バックオフ）とCatch（代替パスへの分岐）を定義することです。アプリケーションコード側で独自にリトライループを書くのは、観測性・バックオフ制御の面で劣ります。
Q3. 人間の承認を経てから処理を続けたいときのパターンは？
.waitForTaskTokenによるコールバックパターンです。タスクトークンを発行して待機し、承認担当者（人間）がコールバックAPIを呼ぶまで実行が止まります。