こんにちは、セキュリティエンジニアの田所です。
先日参加してきた AWS Summit Japan 2026 からセッションの模様をお届けします。

セッションについて

CNS454 ワークフローオーケストレーターにおける複雑性と非決定性のコントロール

ワークフローにおいて、複数の AWS サービスをまたぐ処理やリトライ・ロールバックが増えていくと、複雑さは見えないまま増殖し、保守性を蝕んでいきます。本セッションでは、制御が難しい複雑性と非決定性のコントロール方法を学びます。前半は、肥大化したワークフローを分解し、複雑さを可視化・構造化する設計パターンを示します。後半は、生成 AI エージェントの「非決定性」という新たな複雑さに踏み込み、決定論的なワークフローと非決定論的なエージェントの組み合わせのパターンを解説します。Step Functions / Lambda durable functions / Amazon MWAA、そして AI Workflows とエージェンティック AI をこのセッションでマスターしましょう。それぞれのトレードオフを理解し、あなたのユースケースに最適な選択を導く判断軸を持ち帰ってください。

AWS Step Functions をはじめとするワークフローオーケストレーターは、統合サービスの種類が増え、柔軟性が増し、機能が高度化しています。
一方で、機能や関わるチームが増え、分岐やサービスをまたぐ処理が積み重なると、複雑さは見えないまま膨らんでいきます。
さらに AI エージェントという非決定的なワークロードをどう組み合わせるか、という比較的新しい論点も登場しています。
そうした 複雑性・非決定性 を「いかにコントロールするか」を軸に据えたブレイクアウトセッションでした。

1. AWS のワークフローオーケストレーター

ワークフローでは、条件分岐やリトライ、並列処理といった制御を扱えます。
またエラー箇所を特定する情報を残せば、その部分だけ再実行する仕組みの実装も簡単です。
これを実装する選択肢として、3 つの AWS サービスが紹介されました。

1 つ目は AWS Step Functions です。
200 を超える AWS サービスと直接統合でき、GUI でワークフローを設計できます。
2024 年 11 月に対応した JSONata により、ステートマシン内でのデータ変換も書きやすくなっています。

2 つ目は AWS Lambda durable functions です。
実行状態を永続化する step、一時停止の wait、外部イベントを待つ waitForCallback を備え、Lambda で長時間のワークフローを実現できます。
慣れた言語やコーディングツールとの相性の良さが魅力です。

3 つ目は Amazon Managed Workflows for Apache Airflow (MWAA) です。
有向非巡回グラフ (DAG) を核とし、コードベースでの開発や AWS 外との接続に向く一方、インフラが必要になります。

使い分けの目安は以下のように整理できます。

  • AWS サービス・システム横断 → Step Functions
  • アプリロジック内に閉じる → Lambda durable functions
  • コードベースで AWS 外とも繋ぐ → MWAA

特に Step Functions と MWAA は、GUI とサーバーレスか、コードベースとインフラ前提か、という点で対照的でした。

2. 肥大化するワークフローの複雑性

ある企業のステートマシンを例に「複雑性がどう増殖するか」の例が紹介されました。
最初はユーザー登録時にレコード作成とメッセージ配信を行うだけの単純なワークフローでしたが、機能と関係者が増えるにつれ、ステート数の肥大化や複雑なロジックの混入、複数チームへのまたがり、開発生産性の低下が起きていきます。
そこそこ多くの方が共感できそうなシナリオですね。

ここでのよくある課題の 1 つ目は、オーケストレーターにロジックが書き込まれてしまうケース です。
メール検証のような複雑な条件がオーケストレーター側に埋め込まれると、検証の抜け漏れやメンテナンスの困難さに繋がります。
これは ロジックを Lambda 側に寄せる ことで解消できます。

2 つ目のよくある課題は、複数のチームに分かれた処理が、一本のフローの中に並んでいるケース です。
この場合、あるチームのエラーが他チームへ波及したり、他チームの出力形式に依存したり、デプロイが煩雑になったりします。
ここでは ワークフローそのものを分割していく ことが打ち手になります。

3 つ目は、類似の処理が至る所に分散して置かれるケース です。
メール通知や Slack 通知のような共通パターンが繰り返されると、コードの重複や修正漏れが発生しやすくなります。
こうした処理は 共通コンポーネントとして切り出す ことが有効です。

3. 複雑性をコントロールする設計原則

「どんなシステムにも、これ以上は減らせない固有の複雑さがある」という複雑性保存の法則が紹介されていました。
そして複雑性そのものが悪いのではなく、コントロールできない複雑性こそが問題だ、という前提も共有されました。
かの有名な Werner Vogels の Simplexity の話に通じるものがあります。

複雑性をコントロールするには、「なぜ・どこで・どのように」分割するかを整理しておくことが重要になります。

「なぜ分割するか」は、複数チームでの保守や分岐の増加によって把握・管理が困難になる前に手を打つため。
「どこで分割するか」は、チーム単位だけでなく、障害範囲やテスト単位といった軸でも考えられます。
そして、分割したフローの間のインターフェースのスキーマを、事前に設計しておくことも大切だとされていました。

また印象的だったのが、複雑なロジックはソースコードへ寄せ、Step Functions はあくまでオーケストレーターに徹するべき、という原則です。
データ整形や簡易な処理はオーケストレーターと JSONata に、ビジネスロジックや複雑な処理はワーカーである Lambda に。
「オーケストラでは指揮者 (オーケストレーター) が演奏してはならない」という比喩 (というか語源) が、役割分担を端的に表していました。

「どのように分割するか」は、責務や結合度によって呼び出し方を変えます。
ネスト呼び出し、非同期呼び出し、タスクトークンによる意図的な待機といった手段が挙げられました。
特にタスクトークンを使えば、呼び出し先を任意のシステムとして疎結合に繋ぎ、その完了を待ってから次の処理へ進められる点が示されていました。

全体を通して、これは結局「疎結合化をどうデザインするか」の話だと感じました。

4. AI エージェントの組み込みと制御

後半は、ここに 「AI エージェントという非決定的なワークロードをどう組み込むか」という話です。
AI エージェントは挙動が非決定的であるがゆえ、リトライが必要になったり、無限ループを処理することになるケースがあります。
そのためリモートエージェントの動作をどう制御するかは、安定・高品質なワークフローのための重要な論点となります。
ここでは決定論的に処理できることは、推論ではなくプログラムで行うことを前提として、その方法論を見ていきました。

今回 AI Agent の制御パターンとして、3 つのパターンが紹介されました。

  • 決定論的なワークフローでエージェントをラップする Outer/Inner Loop パターン
  • 重要な判断を人間が担う Human-in-the-Loop パターン
  • 既存の決定論的なワークフローを AI からツールとして呼び出す Workflow as Tools パターン

中でも気になったのが Workflow as Tools パターン です。
AI の処理の中で、決定論的なワークフローをツールとして呼び出す構成です。
AgentCore Gateway を介し、AWS SDK を使えば Step Functions 固有の状態管理にもアクセスできるとされていました。

このパターンが有効なのはどんな場面でしょうか。

これは私なりの意見ですが、例えば カスタマーサポートのエージェントによる返金対応 が考えられると思います。

お客様との会話から状況を汲み取り、返金してよいかを判断するのは、エージェントが得意とするところです。
一方で実際の返金処理は、注文内容の検証から決済の取り消し、台帳の更新、確認メールの送信まで、順序も正確性も問われる、間違いが起こってはならないステップです。
こうした決まりきった手続きを決定論的なワークフローにツールとして任せ、エージェントは会話と「いつ実行するか」の判断に専念する、という切り分けです。

お金やコンプライアンス、本番リソースの操作を伴う処理ほど、この組み合わせが活きるのではないでしょうか。

まとめ

ワークフローの複雑性と AI の非決定性を、それぞれどうコントロールするかを見てきました。

複雑性は適切な単位での分割と疎結合な設計で、非決定性は決定論的なワークフローで包み込んだり組み合わせたりすることで、扱いやすくなります。
複雑性も非決定性も、それ自体が悪なのではなく、コントロールできているかどうかが大事 だというメッセージが一貫していました。
特に「指揮者は演奏してはならない」という役割分担と、分割を「なぜ・どこで・どのように」デザインするかという視点は、自分の設計を見直すときの軸として持ち帰りたいと感じました。

おしまい