AWS Step Functionsにおいて、2024年11月にJsonataによるデータ変換が正式にサポートされたことで、サーバーレスアーキテクチャにおけるワークフロー設計の柔軟性が大きく向上しました。これまでLambdaなどに依存していた部分を、より宣言的に表現できるようになります。
Jsonataとは？なぜ注目されているのか
Jsonataは、JSONデータを対象としたクエリ言語・式言語で、XPathのような簡潔な構文で複雑なデータの加工が行えます。AWS Step Functionsでこの言語が使えるようになったことにより、単純な値の抽出だけでなく、以下のような処理がステートマシン内で実現可能になりました。
- 条件によるフィルタリング（例：価格が一定以上の商品だけを抽出）
- 配列のマッピング（例：オブジェクトの一部フィールドのみ抽出）
- 集計や構造の再構築（例：合計金額の計算、階層構造の変換）
これらは従来、Lambda関数で処理せざるを得なかった領域です。
AWS Step Functionsとの統合ポイント
Jsonataが使える場面は限定されており、.foo.$形式で動的に値を設定する構文に対して適用されます。たとえば、ParametersやResultSelectorなど、ステート定義の中でデータ構造を操作するフィールドに対して使うことが可能です。
具体的な利用場面としては、以下が挙げられます：
- Mapステート内での配列フィルタリングや加工処理
- Choiceステートにおける柔軟な分岐条件の構成
- Parallelステート間でのデータ整形や中間結果の統合
これにより、ワークフローのロジックをより「宣言的に」定義できるようになります。
実運用における注意点と設計指針
Step FunctionsにおけるJsonataの活用は強力な一方で、設計上の注意も必要です。
- 式の複雑さに注意：Jsonataは表現力が高いため、複雑な式を書くと可読性が一気に低下します。チームでの運用を前提に、式はできる限り簡潔に保つことが望ましいです。
- 処理の限界を意識する：あくまで補助的な変換手段として使い、重い処理は依然としてLambdaなどに任せるのが無難です。
- 型や存在チェックに注意：Jsonataではキーの存在確認などを自分で書く必要があるため、想定外のデータ構造が来た場合の挙動に留意してください。
Jsonataの式は、AWS公式ドキュメントにあるStep Functions での JSONata を使用したデータの変換を参考に段階的に試すのがよいでしょう。
活用例
Jsonataを活用した例を1つ紹介します。
もともと、あるStep FunctionsのStateMachineにおいて、後続のECSTaskなどにパラメータを渡すためにLambdaを呼び出し、そのLambda内でパラメータを組み立てて返す処理がありました。
そのLambdaは複数のStateMachineから呼び出されるようになっており、各StateMachineの要求を満たすためにコード量も増えて可読性が低いものになっていました。
処理としても無駄であるため、できればStep Functionのみで表現したいと思っていました。
以下はその変更過程の一部を切り出したものです。
"States": {
"define_variables": {
"QueryLanguage": "JSONata",
"Type": "Pass",
"Next": "shops",
"Assign": {
...
"company_id": "{% $states.input.company_id %}",
"shop_ids": "{% $states.input.shop_ids %}",
"execution_id": "{% $states.input.execution_id ? $states.input.execution_id : $uuid() %}",
...
}
},
このStateMachineは呼び出しの際に「execution_idを渡されたらそれを利用し、渡されなければ新規にuuidを発行する」ということが必要でした。
従来であればそのような条件分岐はStep Functionsでは表現できなかったためLambda Functionを作成して呼び出す必要がありましたが、Jsonataが使えるようになってから上記のように1行で表現できるようになりました。
これ以外にもデータ整形などにおいて従来よりかなり柔軟に対応できるようになりました。
今後の活用に向けて
Jsonataの導入により、Step Functionsは単なる状態遷移エンジンから、 よりリッチなデータ制御が可能なDSL（ドメイン特化言語） へと進化しました。クラウドネイティブなワークフローの設計において、記述量の削減、依存の低減、保守性の向上を実現できる新しい選択肢として、ぜひ積極的に検証・導入してみてください。