AWS Step FunctionsのAgentCore推論ステップとは：AIエージェントをワークフローに組み込む前に確認すべきこと
このテーマをもう少し広げて見るなら、Amazon Bedrock AgentCore RuntimeのInteractive Shellsとは：AIエージェントを端末から調査・デバッグする前に確認すべきこと と AWS MCP Serverのクロスアカウント対応とは：AIコーディングエージェントに複数AWSアカウントを触らせる前に確認すべき権限設計 も合わせて確認してください。Step FunctionsからAgentCore harnessを呼ぶ前後で、Runtime側の調査・デバッグ方法も確認しやすくなります。
3行まとめ
分類、抽出、承認前チェックなどを、Step Functionsの状態遷移の中で扱いやすくなります。
順次実行、並列実行、人間承認、リトライ、実行履歴と組み合わせて設計できます。
Request Responseのみ、15分上限、最終assistant message中心、previewリージョン限定を確認します。
便利さだけでなく、実行時間、出力形式、リージョン、監査導線を同じタイミングで確認します。
AWSは2026年6月3日、AWS Step FunctionsからAmazon Bedrock AgentCoreのmanaged harnessを呼び出し、ワークフロー内にAIエージェントの推論ステップを置ける統合を発表しました。
分類、抽出、承認前チェックのような処理では、Step Functionsの順次実行、並列実行、人間承認、リトライ、実行履歴と、AgentCore harnessのモデル、tools、session、CloudWatch追跡を組み合わせやすくなります。
ただし、統合はRequest Responseのみ、InvokeHarness Task stateは最大15分、返るのは最終assistant message中心、AgentCore harnessはpreviewリージョン限定です。東京リージョン前提の本番導入や長時間ジョブに、そのまま広げて読まないほうが安全です。
今回の需要シグナルはかなりはっきりしています。AWS公式What’s NewがStep FunctionsとAgentCore harnessの最適化統合を発表し、同時期にAgentCoreのHarness、Gateway、MCP、tool連携をめぐる開発者側の関心も続いています。ただし、この記事ではコミュニティ投稿を仕様の根拠には使いません。仕様、対応リージョン、料金、制約はAWS公式発表と開発者ドキュメントで確認します。
Step FunctionsのAgentCore推論ステップで何が変わったのか
- 1入力
業務データやユーザー依頼を受け取り、前処理や検証を行います。
- 2通常Task
LambdaやAWSサービス連携で、決定的に処理できる部分を進めます。
- 3InvokeHarness
AgentCore harnessがモデル、tools、sessionを使い、推論結果を返します。
- 4Choiceと承認
推論結果を条件分岐に戻し、必要なら人間承認を挟みます。
- 5CloudWatch追跡
agent input、output、token usage、duration、turn detailsを運用確認に使います。
AI推論を独立した処理ではなく、既存の業務ワークフローに戻せる1ステップとして扱うのがポイントです。
今回の更新を一言で言えば、Step FunctionsのワークフローからAgentCore harnessをTask stateとして呼び出し、AIエージェントの推論を業務フローの中に置きやすくなった、という話です。
Step Functionsはもともと、AWSサービスやLambda、外部処理を状態遷移としてつなぎ、エラー処理、分岐、並列処理、人間承認を組み立てるサービスです。ここにAgentCore harnessが加わると、単純なAPI呼び出しだけでなく、モデル、tools、memory、session、observabilityを持つagent loopを、ワークフローの途中で使えるようになります。
大事なのは、Step Functionsがエージェントの内部ループを自分で実装するわけではない点です。Step FunctionsはInvokeHarnessでAgentCore harnessを呼び、結果を受け取り、次のChoiceやTaskへ進めます。agent loop、tool selection、multi-turn conversation、memoryなどの実行環境はAgentCore側の責任です。
AI推論をワークフローの1ステップとして扱える
公式発表では、文書分類や非構造フォームからの抽出のような推論タスクをワークフロー内で自動化できる例が示されています。これまでLambdaで前処理し、Bedrockや外部LLMを呼び、結果をパースしてStep Functionsへ戻していた処理の一部を、AgentCore harnessとしてまとめられる可能性があります。
たとえば、問い合わせ本文を分類し、該当部署を選び、リスクが高い場合だけ人間承認に回すようなフローでは、分類部分をAgentCore harnessに任せ、後段の分岐や承認はStep Functionsで維持できます。AIの判断をワークフロー全体に溶かし込むのではなく、どの状態で推論し、どの状態で人間が確認するかを分けて設計できるのがこの統合の読みどころです。
AgentCore harnessがagent loopを受け持つ
AgentCore harnessは、モデルを呼び、toolを選び、結果を戻し、contextやmemoryを扱うagent loopの実行基盤です。AWSのAgentCore harnessドキュメントでは、managed agent harnessが環境、compute、tooling、memory、identity、VPC networking、observabilityを扱うと説明されています。
Step Functions側で見るべきことは、どのharness ARNを呼ぶのか、Workflow StudioのQuick Create Harnessで試すのか、既存harnessを再利用するのか、Taskごとにmodelやsystem promptなどを上書きするのかです。本番導入では、PoCで作ったharnessをそのまま使うより、実行ロール、tool権限、session ID、timeout、監査ログを別途設計したほうがよい場面が多くなります。
既存ワークフローに足す価値が出る処理
向いているのは、決定的な変換よりも、判断前に意味解釈が必要な処理です。文書分類、フォーム抽出、問い合わせ振り分け、承認前の補助判断、複数情報源の照合、例外ケースの要約などが候補になります。
反対に、単純な形式変換、ミリ秒単位の低レイテンシが必要な同期API、長時間の非同期ジョブ、途中のtool実行結果を厳密に分岐条件へ使いたい処理では、今回の統合だけに寄せないほうが無難です。Lambda、通常のBedrock Runtime呼び出し、既存のservice integration、別の非同期設計を残す判断もあります。
既存のAgentCore運用を追っている読者は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-21-agentcore-identity-secrets-manager/" rel="noopener">AgentCore IdentityとSecrets Manager参照の記事</a>もあわせて見ると、外部APIやsecretを使うagentの責任分界を整理しやすくなります。
ワークフロー設計では並列、順次、人間承認をどう使うか
自律化の範囲を広げるほど、料金、ログ量、権限、承認責任も一緒に増えます。
AIエージェントを入れると聞くと、すべてを自律化する話に寄りがちです。しかしStep Functionsとの組み合わせでは、むしろ制御フローを残せることが重要です。どこで推論し、どこで分岐し、どこで人間が承認するかを状態として分けられます。
順次実行は段階的な判断に向く
順次実行が向くのは、推論結果を段階的に絞る処理です。最初のagentで問い合わせ種別を分類し、次のagentで必要項目を抽出し、その後のChoice stateで通常対応、追加確認、人間承認へ分けるような構成です。
この場合、各agentの入力と出力を小さく保つことが大切です。前段の誤判定が後段へ伝わるため、途中に検証用のChoice、Catch、人間確認を置けるかを先に考えます。AI推論を複数段にしたから精度が上がるとは限りません。むしろ、どの段階で失敗したかを追える設計のほうが実務では効きます。
並列実行は複数観点の評価に使える
並列実行は、同じ入力を複数の観点で見るときに使いやすいパターンです。たとえば契約書の一次確認で、1つのagentは支払い条件、別のagentは個人情報やセキュリティ条項、さらに別のagentは例外条項を見る。結果が一致しない場合やリスクが高い場合だけ、人間承認に回します。
ただし、並列agentは推論回数、token usage、tool call、CloudWatchログを増やします。ワークフローとしては見やすくなっても、費用や監査ログは増えます。PoCでは、正答率や作業削減だけでなく、branch数、retry数、token量、ログの追跡しやすさも測るべきです。
人間承認はcritical actionの直前に置く
公式発表でも、critical actionの前に人間承認を追加できることが示されています。AIエージェントが抽出や分類をしても、返金、契約承認、外部通知、権限付与のような処理へ直結させるなら、人間承認を最後の関門として置くほうが自然です。
承認者に見せる情報は、最終assistant message、元の入力、重要な抽出値、Step Functionsの実行履歴、CloudWatchのagent turn detailsへの導線に絞ります。後述する通り、Step Functionsの出力にはtool useやreasoning blockが含まれないため、承認画面や通知文に何を載せるかは別に設計する必要があります。
InvokeHarnessの制約を先に読む
Run a JobやCallback前提の長時間ジョブとは別に設計します。
長いagent loopや多段tool処理は、timeoutの扱いを先に決めます。
後続ステップで使う出力は、最終メッセージから安定して取り出せる形にします。
tool useやreasoning blockをそのまま後続処理の入力にする前提は避けます。
長い説明や大量抽出は、要約や分割処理を含めて検証します。
Step Functions側でtimeoutしても、harness側の処理継続や副作用を確認します。
制約は欠点ではなく、どの処理をワークフロー内に入れるかを決めるための境界線です。
今回の統合で最も見落としたくないのは、できることよりも制約です。InvokeHarnessは便利な入口ですが、Step Functionsのあらゆる統合パターンに対応するわけではありません。
対応パターンはRequest Responseのみ
根拠
Step FunctionsのAgentCore harness統合では、Request Responseパターンのみがサポートされています。Run a Jobの.syncパターンや、Task Tokenを使ったCallbackパターンはサポートされません。
注意点
つまり、長時間のagent実行をStep Functions側がジョブとして待ち続ける設計や、外部システムからCallback tokenで戻す設計にはそのまま使えません。短い分類や抽出なら合いますが、何十分も外部toolを回り続けるagent、複数の人間待ちを含むagent、非同期バッチ処理は、別の構成を考えるべきです。
Task stateの最大実行時間は15分
確認項目
Step Functionsドキュメントでは、InvokeHarness Task stateの最大実行時間は15分、900秒と説明されています。TimeoutSecondsにそれ以上の値を設定しても、この上限を超えることはできません。
失敗時の見方
さらに重要なのは、Task stateがタイムアウトしても、harness側は自身のtimeoutに達するまで実行を続ける可能性がある点です。これは費用と副作用の両方に関わります。外部APIを呼ぶtool、書き込みを伴うtool、BrowserやCode Interpreterのような追加能力を使うagentでは、Step Functions側が失敗として扱った後にharness側で処理が続くリスクを確認しておく必要があります。
出力は最終assistant message中心で読む
根拠
Step Functionsドキュメントでは、レスポンスはConverseに似たJSON構造へ変換され、返るのはagentの最終assistant messageだと説明されています。multi-turn conversationの以前のturnは捨てられ、Output.Message.Contentに含まれるのはtext contentです。tool useやreasoning blockは含まれません。
評価基準
そのため、途中のtool呼び出し結果や推論過程をChoice stateの条件として直接使う設計は避けるべきです。ワークフロー分岐に必要な値は、最終assistant messageに明示的に含めるか、別の検証ステップで構造化する必要があります。業務フローで使うなら、最終出力の形式、失敗時の文言、曖昧な回答の扱いをPoC段階で決めておきます。
token usageとlatencyは全turn集計で見る
レスポンスにはUsageとしてInputTokens、OutputTokens、TotalTokensが入り、Metrics.LatencyMsも返ります。これらは会話全体にまたがる集計値です。
費用見積もりや性能評価には役立ちますが、どのtool呼び出しで遅くなったか、どのturnでtokenが増えたかまでStep Functionsのレスポンスだけで分かるわけではありません。詳細な追跡にはCloudWatchのagent turn detailsや、AgentCore側の観測設計を合わせて見る必要があります。Bedrock系の監視観点は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-19-bedrock-mantle-cloudwatch-metrics/" rel="noopener">Bedrock MantleのCloudWatchメトリクス記事</a>でも整理しています。
Workflow StudioとQuick Create Harnessをどう使うか
- Quick Create Harness
まず小さなPoCで、agent stepの入出力、実行時間、ログの見え方を確認します。
- 既存harness ARNを選択
既存harnessを再利用する場合は、defaultsとTask state側のoverride範囲を確認します。
- 本番harnessを分離
execution role、tool権限、session設計、監査ログを本番用に棚卸しします。
- 表記差も確認
Step Functionsのresource URIとAgentCoreのresource ARNで表記が異なる点に注意します。
PoCで作りやすいことと、本番で安全に運用できることは分けて判断します。
AWSの発表では、Workflow Studioから既存harnessを再利用するか、新しいharnessを作成できると説明されています。Step Functionsのvisual builderでagent stepを置けるのは、PoCにはかなり便利です。
ただし、便利な入口と本番設計は分けたほうがよいです。Quick Create Harnessで試すと、最初の分類や抽出が動くかを早く確認できます。一方で、本番利用ではharnessの実行ロール、toolの接続先、session継続、timeout、CloudWatch、料金配賦、権限レビューを別に設計する必要があります。
PoCではQuick Create Harnessで入口を作る
最初の検証では、Workflow StudioでAgentCore InvokeHarnessを探し、Quick Create Harnessを使って小さなstate machineを作るのが自然です。入力は短いテキスト、出力は分類ラベルや抽出済みフィールドに絞ります。
PoCの成功条件は、期待する最終assistant messageが返ること、Step Functionsの後段TaskやChoiceで扱えること、UsageとMetrics.LatencyMsを確認できること、CloudWatch側でagent turn detailsへ辿れることです。ここでいきなり本番業務データやsecretを渡さないほうがよいでしょう。
既存harnessを再利用する場合は上書き範囲を見る
既存harnessを使う場合、Task stateの定義で一部の設定をinvocationごとに上書きできます。model、system prompt、toolsなどを文脈に合わせて変えられるのは便利ですが、上書きの自由度が高いほど、誰が何を変えてよいかを決める必要があります。
同じharnessを複数ワークフローから呼ぶなら、モデル変更、prompt変更、tool追加の影響範囲を確認します。agentの挙動が変わると、Step Functions側の分岐条件や人間承認の文面にも影響します。
本番ではharness execution roleを別に棚卸しする
Step Functionsの実行ロールと、harnessがtoolsを使うための実行ロールは同じ責任ではありません。Step Functions側はInvokeHarnessを呼べる権限を持ち、harness側はGateway、Browser、Code Interpreter、外部API、メモリ、ファイルなどの能力にアクセスします。
公式ドキュメントでも、harnessが使うtoolsの権限はharness execution role側に設定されると説明されています。ここを混同すると、Step Functionsに必要以上の権限を持たせたり、逆にharness側の権限不足をStep Functionsの問題として追いかけたりしがちです。
観測と監査はCloudWatchまで含めて設計する
観測できる項目は増えますが、業務証跡として何を残すかはワークフロー側で設計します。
今回の統合では、Step Functionsの実行履歴にagent input、output、token usage、durationが表示され、CloudWatchのagent turn detailsへのリンクで追跡できると説明されています。これは本番運用でかなり大きいポイントです。
ただし、CloudWatchで追えることを、完全な説明責任やchain-of-thoughtの取得と混同しないほうがよいです。ワークフローの監査では、Step Functionsで見えるもの、AgentCore responseで返るもの、CloudWatchで追うものを分けます。
Step Functions execution historyで見るもの
確認項目
Step Functions側では、どの入力でTaskが呼ばれたか、成功したか、失敗したか、後段のChoiceやCatchへどう進んだかを見ます。ワークフロー全体の制御を追うにはここが入口です。
評価基準
実務では、AI推論の結果だけを見るのではなく、その前後の状態も合わせて確認します。入力が前段で正しく整形されたか、retryが何回走ったか、Catchでどの例外処理へ流れたか、人間承認がどの条件で発生したかを確認できるようにします。
CloudWatch turn detailsで見るもの
根拠
CloudWatch側では、agentのturn-by-turnの詳細やtool useの追跡が運用上の手がかりになります。なぜ時間がかかったのか、どのtoolを呼んだのか、どの段階で失敗したのかを確認するには、Step Functionsの最終出力だけでは足りません。
注意点
CloudWatchへのリンクがあるからといって、承認者全員が詳細ログを読める設計にする必要はありません。承認者には要約と重要フィールドを見せ、運用者やSREが必要時にCloudWatchへ深掘りできるようにするのが現実的です。
監査ログは権限と費用にもつながる
agentがtoolを使うほど、監査対象は増えます。外部API、Gateway、Browser、Code Interpreter、Identity、Secrets Manager、CloudWatch logsなど、関連するサービスのログと料金を分けて見ます。
Step Functionsの実行履歴だけを残しても、agentの内部で何が起きたかを十分に追えない場合があります。逆に、CloudWatchにすべてを出す設計にすると、ログ費用や個人情報、業務機密の扱いが問題になります。どの情報をログに残し、どの情報をマスクするかはPoC段階で決めるべきです。
権限、tools、session IDで事故を減らす
セキュリティでは単純な勝敗ではなく、呼び出し権限、tool権限、session境界を条件ごとに分けます。
AIエージェント統合で事故が起きやすいのは、モデルそのものよりも周辺の権限とtoolsです。Step Functionsから呼ぶだけなら単純に見えても、harnessが外部toolを持つと、実行できることの範囲が急に広がります。
Step Functions execution roleは呼び出し権限に絞る
Step Functionsの実行ロールには、必要なharnessを呼び出す権限を最小限で付けます。ドキュメントのIAM policy例でも、特定harness ARNを指定する形が示されています。すべてのharnessに広く呼び出し権限を付けると、ワークフローから意図しないagentを呼べる状態になります。
また、開発用、検証用、本番用のharnessを分けるなら、Step Functions側のロールとstate machineも分けるほうが追跡しやすくなります。PoCのために広い権限で動かしたものを、本番へそのまま持ち込まないことが大切です。
harness execution roleはtoolごとに見る
harnessが使うtoolsの権限は、harness execution role側で確認します。AgentCore Gateway、Browser、Code Interpreter、MCP server、外部API、ファイルシステム、memoryを使う場合、それぞれの権限とログを見ます。
外部APIやsecretを扱う場合は、認証情報の保管、rotation、KMS、CloudTrailも関わります。<a href="https://amzn-watch.blog.mo-gmo.com/amzn-21-agentcore-identity-secrets-manager/" rel="noopener">AgentCore Identityが既存Secrets Manager secretを参照できるようになった更新</a>は、この文脈で読むと実務に近いです。
session IDは会話継続と分離の両方に効く
Step FunctionsのTask state定義では、RuntimeSessionIdでconversation sessionを識別します。同じsession IDを使えば会話を継続できます。これは便利ですが、ワークフロー実行ごとの分離や、ユーザーごとの分離を誤ると、文脈が混ざる可能性があります。
分類や抽出のような単発処理では、実行ごとにsessionを分ける設計が自然です。継続会話や長い処理を扱う場合は、どの単位でsessionを再利用するか、いつ破棄するか、個人情報や機密情報が残らないかを確認します。
対応リージョンとpreviewの読み方
米国東部の対象リージョンです。
米国西部の対象リージョンです。
欧州の対象リージョンです。
アジア太平洋ではSydneyが対象として示されています。
東京リージョン前提の本番設計とは分けて読みます。
previewではUI、API、対応リージョン、料金説明が変わる可能性があるため、導入前に公式情報を確認します。
日本の読者にとって最初に見たいのは、東京リージョンで使えるかどうかです。ここは慎重に読む必要があります。
AWSの発表では、Step Functionsのharness統合はAgentCore harness previewが利用できるリージョンで提供されると説明されています。対象として示されているのは、US East (N. Virginia)、US West (Oregon)、Europe (Frankfurt)、Asia Pacific (Sydney)です。2026年6月6日の確認時点で、東京リージョンはこのharness previewの対象としては示されていません。
Sydney対応を東京対応と読まない
Asia PacificにSydneyが含まれるからといって、東京リージョンでも同じように使えるとは限りません。AWSサービスでは、アジア太平洋の中でもリージョンごとに対応状況が異なります。
東京リージョン必須の本番ワークロードでは、今回の発表をそのまま導入可と読むのではなく、AgentCore harnessのリージョン一覧、Step Functionsのリージョン、使うモデル、GatewayやIdentityなど周辺機能の対応を個別に確認します。
previewは本番導入の前提を分ける
AgentCore harnessはpreviewです。previewでは、API、UI、料金説明、対応リージョン、制限、ドキュメントの表現が変わる可能性があります。社内PoCや検証用途で使う価値はありますが、規制要件やSLA、監査が厳しい本番へ入れる場合は、previewの扱いを社内基準と照らす必要があります。
ここでの良い使い方は、東京リージョン本番に急ぐことではなく、agentic reasoning stepをワークフローに置くと何が便利で、どこが危ないかを先に検証することです。
複数リージョン運用ではログとデータ境界を見る
previewリージョンでPoCする場合でも、日本の業務データをそのまま使ってよいとは限りません。入力データ、ログ、CloudWatch、外部tool、モデル呼び出し、権限境界がどのリージョンに置かれるかを確認します。
本番では東京、PoCではSydneyやVirginiaという分け方をするなら、テストデータの匿名化、ログ保持、IAM、データ転送、社内レビューをセットで考えます。AWSの公式ページにリージョン名があるかどうかだけでは、導入判断としては足りません。
料金はStep Functionsだけで見ない
Standard Workflowではstate transition、Express Workflowではrequestとdurationを確認します。
推論回数、入力、出力、複数turnの増え方を見ます。
harnessや周辺capabilityの利用条件を、Bedrock側の料金と分けて読みます。
外部tool、API呼び出し、データ取得が増える場合は個別に見積もります。
ログ、メトリクス、turn detailsの保存量が増える前提で確認します。
agentが呼ぶSaaSや社内APIの従量課金、rate limit、監査費用も含めます。
統合そのものに追加料金がなくても、agentのturn、tool call、ログが増えれば総額は変わります。
公式発表では、Step Functionsの標準料金が適用され、統合そのものの追加料金はないと説明されています。一方で、BedrockやAgentCoreの利用料金は別です。ここを読み違えると、PoC後の見積もりがずれます。
Step Functionsは状態遷移と実行形態を見る
料金確認
Step Functions Standard Workflowsでは、状態遷移ごとに課金されます。retryも追加の状態遷移として扱われます。Express Workflowsでは、request数とdurationが課金軸になります。
注意点
AgentCore推論ステップを入れると、単純なTaskが1つ増えるだけでなく、retry、parallel branch、人間承認、例外処理、ログ確認の設計も増えます。料金を見るときは、agent呼び出し単体ではなく、ワークフロー全体で何回状態が進むかを見ます。
AgentCore harness自体の別料金なしを無料と読まない
根拠
AgentCore pricingでは、harness in AgentCoreはextra chargeなしで、使う基盤リソースに対して支払うと説明されています。これは「harnessという箱に別料金が乗らない」という意味であり、agentの実行全体が無料になるという意味ではありません。
確認項目
モデル推論、AgentCore Runtime、Gateway、Identity、Observability、Browser、Code Interpreter、CloudWatch、外部API、データ転送などは別に確認します。toolを増やすほど、見積もり対象も増えます。
token usageとtool callの増え方をPoCで測る
PoCでは、1実行あたりのInputTokens、OutputTokens、TotalTokens、Metrics.LatencyMs、tool call回数、retry回数、parallel branch数を記録します。sessionを継続する場合は、contextが増えることでtoken量が増えないかも見ます。
コスト削減だけを期待すると判断を誤ります。AI推論で人間の確認時間が減る一方、agentが複数turnやtool callを重ねて、決定的な処理より高く遅くなることもあります。費用、品質、監査、人間承認の負荷を同じ表で見るのが現実的です。
導入前に試す検証シナリオ
最初の検証目的は、AIエージェントが賢いかではなく、業務フローへ戻せる形で安定して返せるかを見ることです。
この統合は、いきなり大きな業務フローへ入れるより、小さな検証から始めるほうが向いています。最初の目的は、AIエージェントが賢いかどうかではなく、Step Functionsの制御フローに戻せる出力を安定して返せるかを見ることです。
文書分類またはフォーム抽出で最小検証する
成功条件
最初のシナリオは、1つのInvokeHarness Taskで文書分類またはフォーム抽出を行うものです。入力は短く、期待する出力も短くします。成功条件は、最終assistant messageが返り、後段のChoice stateやTaskで扱えることです。
観測項目
観測するのは、Step Functionsのinput/output、Usage、Metrics.LatencyMs、CloudWatchのturn details、harnessのtool use、失敗時のCatch分岐です。ここで、timeout、曖昧な回答、想定外の文字列、出力サイズ超過が起きないかを見ます。
並列agentと人間承認を組み合わせる
次に、2つのagentを並列に動かし、結果が一致しない場合は人間承認へ回すシナリオを試します。たとえば、1つはリスク分類、もう1つは必要情報の抜け漏れ確認を行います。
評価するのは、承認者の負荷が減るか、誤承認が増えないか、承認者が必要なログへ辿れるか、parallel branchによる費用増を許容できるかです。AIの判断をcritical actionへ直結させず、人間承認を最後に残す設計を基準にします。
timeoutと権限不足を意図的に起こす
本番前には、うまく動くケースだけでなく、失敗ケースを作ります。harness timeout、Task timeout、tool権限不足、harness ARNの誤り、model overrideの不正、output size超過を試し、Step FunctionsとCloudWatchのどちらに何が出るかを確認します。
この検証で見るべきなのは、失敗が静かに埋もれないか、不要なharness実行が続かないか、運用者がどのログから原因へ辿れるかです。runbookには、Step Functions execution history、CloudWatch turn details、harness execution role、tool権限、料金の確認先を分けて書くと扱いやすくなります。
まとめと次に読むなら
分類、抽出、承認前チェックのように、短時間で結果を返せる小さな処理から始めます。
tools、session、権限、CloudWatch監査、料金の増え方を先に棚卸しします。
東京リージョン前提、長時間agent loop、厳密な監査証跡が必須なら、previewの前提を分けます。
Step Functionsの制御フローに戻せる処理から試し、長時間処理や高権限toolは別設計として扱います。
AWS Step FunctionsのAgentCore推論ステップは、AIエージェントを業務ワークフローへ入れるための強い入口です。特に、分類、抽出、承認前チェック、例外判定のように、決定点の前に推論が必要な処理では試す価値があります。
一方で、Request Responseのみ、15分上限、最終assistant message中心、tool useやreasoning blockの非出力、previewリージョン限定という制約はかなり実務的です。東京リージョン必須の本番運用、長時間非同期ジョブ、途中tool結果を厳密に分岐へ使う設計では、急がず別構成も含めて見たほうがよいでしょう。
Amazon Watch Japanとしては、今回の発表を「AIエージェントを何でも自律化する話」ではなく、「Step Functionsの制御フローに、AgentCore harnessの推論をどこまで安全に差し込めるかを検証する話」と見ています。2026年6月のAWS/Bedrock/AgentCore関連更新は、<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">月次まとめ</a>にも追記していきます。
Amazon Watch JapanはAmazon.com, Inc.、Amazon Web Services, Inc.および各関係会社とは提携していない独立サイトです。本記事は製品・サービス更新の確認を目的としており、投資助言ではありません。
次に読むなら
参照した主な情報源
- AWS What's New「AWS Step Functions adds AgentCore-powered agentic reasoning step」確認日: 2026年6月6日 https://aws.amazon.com/about-aws/whats-new/2026/06/aws-step-functions-agentcore/
- AWS Step Functions Developer Guide「Invoke Amazon Bedrock AgentCore harness with Step Functions」確認日: 2026年6月6日 https://docs.aws.amazon.com/step-functions/latest/dg/connect-bedrockagentcore.html
- Amazon Bedrock AgentCore Developer Guide「AgentCore harness [Preview]」確認日: 2026年6月6日 https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness.html
- AWS Step Functions Pricing 確認日: 2026年6月6日 https://aws.amazon.com/step-functions/pricing/
- Amazon Bedrock AgentCore Pricing 確認日: 2026年6月6日 https://aws.amazon.com/bedrock/agentcore/pricing/
更新履歴
- 2026年6月6日: AWS公式発表、Step Functions Developer Guide、AgentCore harnessドキュメント、料金ページを確認し、Step FunctionsからAgentCore harnessを呼び出す推論ステップの使いどころと制約を整理しました。