AIに決済を任せない業務自動化｜Step Functionsで提案・検証・実行を分離する

公開日 2026.09.17 更新日 2026.09.17 AWS Step Functions Amazon Bedrock AgentCore AIエージェント人間承認

AIが「返金した方がよい」と提案することと、実際にお金を返すことは別の権限です。業務自動化で重要なのは、モデルの賢さだけでなく、提案がそのまま本番操作にならない境界を作ることです。

AWSは2026年9月14日、Step FunctionsとBedrock AgentCoreを組み合わせ、AIの提案をコードで検証してから実行する設計を公開しました。新製品の発売日ではなく、公式の実装解説記事の公開日です。AWS公式解説

① AIは候補と説明文を作る。本番更新は専用の実行処理だけが行う。

② 金額・権限・最新データをコードで確認し、例外は人に回す。

③ 再試行、承認待ち、監査保存まで含めて初めて業務フローになる。

背景：チャットの成功と業務の成功は違う

問い合わせへの回答なら、担当者が文章を読んで修正できます。しかし注文変更、返金、発注では、誤りが外部システムに残ります。「JSONで返した」「自信度が高い」だけでは、取引を実行してよい根拠になりません。

従来のルール処理は定型案件に強く、AIは文章や条件の組み合わせから候補を考えるのに向いています。本稿の編集上の提案は、この二つを置き換え合うのではなく、役割分担させることです。

何が注目点か：AIの外に制御を置く

公式例は航空便の欠航対応です。AIが代替便を提案し、コードが予約可能性を検証します。補償の案内文作成と、規則に基づく金額判定も分離されています。予約・支払いを行うのは検証後の決定的な処理で、エージェント自身ではありません。公式設計例

「決定的」とは、同じ入力と同じ規則に対して結果を再現できることです。ただし在庫や規則が変われば結果も変わるため、参照時刻や規則の版も記録する必要があります。

提案が本番操作になるまでの4段階

AIが提案候補ID・理由・案内文。書き込み権限は持たせない。
コードが検証最新データ・金額・権限・規則の版を確認する。
条件で分岐許可済みの範囲だけ自動化。曖昧な案件は人間承認へ。
専用処理が実行重複を防いで更新し、結果と失敗理由を保存する。

不合格 → 実行せず差し戻し。承認期限切れ → 承認扱いにしない。

技術ポイント：混同しやすい三つの制約

15分InvokeHarnessのTask上限。ワークフロー全体の上限ではない。

最大10,000並列Distributed Mapの子実行。下流APIが処理できる速度とは別。

終了後90日Standardの実行履歴保持期間。長期監査は別途保存を設計する。

AgentCore呼び出し。 最適化統合は arn:aws:states:::bedrockagentcore:invokeHarness。Request Responseのみをサポートし、同じTaskに .sync や .waitForTaskToken は付けられません。返るのは最終のアシスタントメッセージで、トークン使用量は会話全体の合計です。統合ドキュメント

さらに、Step FunctionsのTaskを停止してもharnessは停止しません。Task上限は900秒で、harness側のタイムアウトも別に管理します。画面上で失敗になったからモデルの実行・課金も終わった、と考えないことが運用上の落とし穴です。停止とタイムアウトの仕様

並列処理。 Distributed Mapは子ワークフローを作ります。MaxConcurrency を省略、または0にすると最大10,000並列になり得ます。親はStandardが必要です。小規模な試行では大きな値をコピーせず、下流のレート制限から上限を決めましょう。Distributed Mapの仕様

人間承認。 承認待ちはAgentCoreのTaskではなく、SQSなどの別Taskでコールバックを待ちます。このパターンはStandardで使用し、ExpressはRequest Responseのみです。統合パターン一覧

数字は公式ブログと各仕様ページで照合しました。15分・最大10,000並列は性能測定値や推奨設定ではなく、サービスの上限・挙動です。

実践例：返金業務を段階的に自動化する

以下は編集部が考えた汎用的な設計例で、AWSの導入実績や法的な返金基準ではありません。金額や自動承認条件は、自社の規程と契約を確認して決めます。

モデルに任せること／任せないこと
工程	AIの役割	コード・担当者の役割
問い合わせ読解	理由を要約し、注文候補を提示	認証済み顧客と注文の所有者を照合
返金案	候補と説明を生成	支払額・既返金額・通貨・対象商品を確認
例外判断	不足情報を列挙	規程で分岐し、必要なら担当者が承認
実行	決済APIを直接呼ばない	確定した金額で返金し、処理IDを保存
案内	確認済み結果を文章化	処理が未確定なら「完了」と通知しない

導入は次の順序なら、AIの誤りと既存システムの不具合を切り分けやすくなります。

まず更新なしで試す。 過去案件の匿名化データを使い、提案だけ生成する。実決済の資格情報は渡さない。
検証結果を構造化する。 allowed、reason_code、policy_version、checked_at を返す。モデル出力の approved は信用しない。
承認は提案の版に紐付ける。 対象注文・金額・通貨のハッシュを承認記録に入れる。承認後に内容が変わったら再承認する。
実行直前に再確認する。 検証中に別担当者が返金した可能性を考慮し、更新API側でも残額と重複を確認する。
小さく本番化する。 対象業務と並列数を絞り、失敗率・承認待ち件数・1件当たり費用を観測してから広げる。

最も危ないのは「成功したか分からない」再試行

決済APIがタイムアウトしても、返金自体は成功しているかもしれません。単純にもう一度送ると二重処理につながります。

本稿の設計提案は、注文IDと確定した判断IDから冪等性キーを作り、同じ判断の再試行では同じキーを使うことです。冪等性とは、同じ処理を繰り返しても結果を重複させない性質です。キーを付けるだけでなく、受け側が重複排除を保証していることを確認します。非対応のAPIでは台帳・照会・手動確認を含めた別設計が必要です。

開発・保守・運用・コンサルへの影響

開発： モデル選定と同じくらい、検証APIの入力契約、権限分離、失敗状態の定義が重要になります。
保守： 規則変更をプロンプトだけで対応せず、版管理されたルールと回帰テストに反映できます。
運用： 「失敗」「承認待ち」「実行結果不明」を別々に表示し、担当者と対応期限を決められます。
コンサル： 全面自動化の提案より、どの判断を自動承認できるか、誰が例外を引き受けるかを先に整理する価値があります。

これは設計上の期待効果です。公式記事には、この構成による返金業務の工数削減率やROIの実測値は掲載されていません。導入判断では、自社の処理時間・誤処理・手戻りを測定してください。

リスクと限界：検証コードも万能ではない

テストには、存在しない注文、別顧客の注文、負の金額、通貨違い、返金済み注文、承認期限切れ、成功直後の通信断を含めましょう。外部文書に含まれる「検証を省略せよ」という命令も、業務ルールを変更する権限として扱わない設計が必要です。

監査についても、Standardの履歴は実行終了後90日が基本で、無期限保存ではありません。またTask・状態・実行の入出力は256 KiB上限です。長文の問い合わせや資料を丸ごと持ち回らず、参照IDと必要な項目に絞り、長期保存先にはアクセス制御と保持・削除ポリシーを設けます。サービスクォータ

費用は待機時間だけでは判断できません。Standardは状態遷移で課金され、再試行も遷移に含まれます。モデル、Lambda、SQS、ログなどの費用は別です。「承認待ちに計算資源を使わない」を「業務フロー全体が無料」と読み替えないでください。料金体系

今後注目すべき点

運用前には、利用リージョンでharnessと統合が使えるか、必要なモデル・クォータ・IAM権限を確認します。仕様更新では、応答形式、タイムアウト、停止時の挙動、トレースと監査の保存範囲に注目しましょう。

自社の評価指標は「回答の自然さ」だけでなく、提案の検証通過率、人間承認率、結果不明の件数、再試行後の重複件数、1件当たり総費用まで持つことをおすすめします。速く動くAIより、止めるべき場所で止まれる業務フローが、本番では頼りになります。

最終確認日：2026年9月17日（日本時間）。公式解説の公開日：2026年9月14日。導入手順・返金例・評価指標は本稿の編集上の提案で、実測ベンチマークではありません。

参照元

Previous Post Next Post